Olaf Kolkman: an IP root for the GRS
From IUCG - Internet Users Contributing Group
IAB Chair <iab-chair@ietf.org> 12 février 2010 11:55
IAB statement on the RPKI.
RPKI as a prerequisite for improving the security of the global routing system
To date, the Internet has operated without a secure means to certify the allocation of Internet number resources, particularly Autonomous System (AS) numbers and IP addresses. The pending exhaustion of the IPv4 address space, coupled with a pressing need to improve the security of the global Internet routing system, has given impetus to the development of a resource certification infrastructure for the Internet. A consistent shared view around the world of which number resources are allocated to whom is essential for the reliable operation of the Internet as it continues to grow. The IETF Secure Inter-domain Routing (SIDR) Working Group (WG) has been working with the various stakeholders to specify a Resource Public Key Infrastructure (RPKI) system that can be used to certify these resource allocations in order to substantially improve the security of the routing system.
The IAB considers a properly designed and deployed RPKI to be an absolute prerequisite to having a secure global routing system, which is in turn a prerequisite to having a reliable worldwide Internet. In its absence, there is no formally verifiable authoritative source to determine the allocation for any Internet number resource. Consequently, before originating, propagating, or accepting an IP address prefix, each routing domain must individually assess the consistency of that prefix with whatever information can be obtained about actual allocations. This loose "routing by rumor" approach provides considerable flexibility to each routing domain, but the negative consequences are severe. The global routing system is vulnerable to large-scale disruptions through both misconfiguration and malice. These vulnerabilities can be substantially reduced through the use of an RPKI. Through proper design and wide-scale deployment, an RPKI enables network operators to generate their routing policies from securely verifiable allocation data, providing much higher confidence in the authenticity of routing information.
Technical considerations with respect to the design of the PKI
For any PKI, a certification hierarchy must exist that allows parties to ascertain the validity of a given certificate. The SIDR architecture uses a certification hierarchy, and relying parties must explicitly place trust in the top-level of the hierarchy, commonly called a trust anchor. The SIDR architecture and protocols have been designed to support a single trust anchor as well as multiple trust anchors. The IAB however, is in strong agreement with the Number Resource Organization (NRO) (made up of the five Regional Internet Registries (RIRs)) regarding the number of trust anchors as well as what and whom they represent:
- 1. the RPKI should have a single authoritative trust anchor
- 2. this trust anchor should be aligned with the registry of the root of the allocation hierarchy
The reasoning is of a technological nature and is as follows. A single root for the certification hierarchy significantly reduces the risk of two or more parties accidentally (or maliciously) issuing conflicting certifications for the same address block, because a single authoritative entity at the top-level of the allocation hierarchy is authoritative for both (a) the allocation of the address block and (b) the cryptographic certification of the fact that it did indeed allocate that address block.
Thus, the IAB strongly recommends a single root aligned with the root of the address allocation hierarchy (now part of the IANA function). Doing so will minimize unnecessary complexity in the system, in particular virtually eliminating the possibility of resource conflicts in the system, reducing substantially the likelihood of errors as the allocation and certificate generation can be done together by the same operator.
Implementation considerations
The notion of having a certification hierarchy with multiple equally trusted roots may be appealing from a social and political perspective because of 'fairness' and 'equality' arguments. But that notion allows different organizations to make inconsistent and conflicting assertions about to whom a particular address block has been allocated. In the case of conflicting assertions, the conflict would need to be solved by each relying party, requiring each relying party to have their own security policy and the associated increased complexity. Such an approach does not provide any guarantee that the outcome would lead to a globally coherent view of which resources have been allocated to whom.
It should be noted that mistakes in and attacks on the allocation process are possible, and that sensible caution and fallback plans still remain necessary. Therefore, architecturally, the set of trust anchors employed by a relying party application remains strictly a local matter. In practice relying parties will likely employ local policy files (e.g., for local address spaces such as RFC 1918 spaces used internally) and trust anchors that reflect local security decisions. Therefore the existence of a single root for the certification hierarchy does not give that root unilateral control over the Internet. Individual network operators choose to trust the information given by that root, based on operational experience that the information given by that root is trustworthy. If they find it to be untrustworthy, they are free to ignore it and instead enforce policy based on what they believe to be more appropriate data. The fact that the relying parties choose to trust the root only so long as it proves itself to be trustworthy gives the organization operating the root a strong incentive to ensure that the information they give is accurate and correct, thereby making it rare for network operators to have any reason to distrust it.
Mechanisms to support local decisions about trust anchors, while still maintaining compatibility with RFC 3779 certificate processing, are currently being considered by the SIDR working group. This statement is not to be interpreted as in conflict with these goals; rather, it is concerned solely with the structure of the RPKI certification hierarchy, as represented in the public repository system and aligned with the Internet number resource allocation hierarchy.
Concluding remarks
The IAB commends the RIRs for their investment and leadership in developing an RPKI system that can be used for digital certification of Internet number resources, as well as enabling a foundation upon which a secure Internet routing system can be developed.
Mr. James W. Laferriere <babydr@baby-dragons.com> 12 février 2010 22:44
I for one do not see the need for a 'Single' point of failure nor a placement of another financial gaining point for some large company/government or what have you .
There are protocols which can be used and some are in discussion which would be far better than this particular methodology .
The only way this could be even fathomable would be for a World wide orginasation to be formed that manages & monitors this AND we all know where that will head the minute it gets started .
May I ask where this statements intent(s) were discussed in an open manner on the ietf list ? I'd very greatly like to review those discussions in their entirety .
SM <sm@resistor.net> 14 février 2010 10:54
Hello, At 02:55 12-02-10, IAB Chair wrote:
RPKI as a prerequisite for improving the security of the global routing system.
It would be preposterous of me to disagree with the opinion of the learned members of the IAB.
Implementation considerations
The most important factor in choosing a security mechanism is the threat model. That is, who may be expected to attack what resource, using what sorts of mechanisms? (RFC 3631).
What follows is a work of fiction.
The taller man shut the folder and smiled. "This is a wonderful statement. Just Perfect."
"Thank you," said the white-haired man seated across from him. "The author is a very good writer." He shifted slowly, uncrossing his legs. He leaned forward, causing the leather seat to groan. "Along with this afternoon's briefing, this is really going to accelerate matters. You know that, don't you?"
"Of course," the taller man said. He put his coffee mug on a small table, rose, and walked to the fireplace. He picked up a poker. "Does that scare you?"
"A little," the white-haired man admitted.
"Why?" the taller man asked as he threw the folder into the flames". It caught fire quickly. "Our tracks are covered."
"It is not us I'm worried about. There will be a price," the white-haired man said sadly.
"We've discussed this before," the taller man said. "The policy people will love it."
This is an edited version of the text from Divide and conquer written by Jeff Rovin, Tom Clancy and Steve R. Pieczenik. The quoted text should not be considered as an IETF Contribution as the author of this message does not control the rights to the material.
Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp> 15 février 2010 01:50
The most important factor in choosing a security mechanism is the threat model.
Right.
That is, who may be expected to attack what resource, using what sorts of mechanisms? (RFC 3631).
Perhaps, a threat will be by an ISP trying to advertise someone else's address range as its own.
However, protections against the threat does not prevent the ISP advertise the range as someone elses'.
That is, the ISP can attach its own AS number to a legitimate AS path for the range. Then, the ISP can capture packets destined to addresses within the range, against which, there is no protection.
SM <sm@resistor.net> 16 février 2010 01:01
Perhaps, a threat will be by an ISP trying to advertise someone else's address range as its own.
Quoting Sandra Murphy [1]:
"Political and business fears don't have to be rooted in technical truth, unfortunately."
At 19:48 14-02-10, Phillip Hallam-Baker wrote
I don't think that any member of the IAB would claim that their expertise in the PKI field precluded debate.
Your message did not make it to the IETF mailing list.
I am not privy to all the details to argue against an IAB statement. This should not be read as a licence to kill. :-)
This is not a technical issue, it is a political issue. IANA and ICANN have a really, really bad record when it comes to setting up root authorities. Any plan that requires their involvement is going to take considerably more time and effort than one where their involvement is optional.
Any long-term consequence will be of a political nature. It goes beyond the IANA function and ICANN. The conventional world is used to having some form of authority for regulation. The "routing by rumor" approach does not fit that view. Some considerations may seem far-fetched. I'll leave it as such.
There are five RIRs, this number is not going to increase in the short term. Participation of the RIRs is critical for an authoritative system. Participation of ICANN is not.
It's up to the interested parties to work out the details.
The risk of including ICANN is that misguided or not, there are lots of people who have concerns as to the power that the US exercises over the Internet through their defacto control of ICANN. One common concern is that the US could use such control to ensure that US ISPs were favored in the distribution of the remaining IPv4 blocks.
I don't think that the distribution of the remaining IPv4 blocks is that much of an issue.
I would not draw parallels between DNS and IDR as the dynamics are different. I don't assume that the goal is always about wrecking havoc. These are classic threats that RPKI can address.
David Conrad <drc@virtualized.org> 16 février 2010 01:19
At 19:48 14-02-10, Phillip Hallam-Baker wrote: IANA and ICANN have a really, really bad record when it comes to setting up root authorities.
Oh? Examples please.
David Conrad <drc@virtualized.org> 16 février 2010 01:45
On Feb 15, 2010, at 4:40 PM, Phillip Hallam-Baker wrote:
- PEM (Five years and counting before the project faded away without a definitive declaration of failure)
- DNSEC (Ten years and counting)
So, you're blaming IANA and/or ICANN for the failure to deploy both PEM and DNSSEC.
Seriously?
David Conrad <drc@virtualized.org> 16 février 2010 03:11
On Feb 15, 2010, at 5:21 PM, Phillip Hallam-Baker wrote: It is now generally accepted that PEM was undeployable because the single root model is not workable.
And this is the fault of IANA and/or ICANN how?
ICANN was well aware that the lack of opt-out would prevent deployment of DNSSEC in .com as early as 2000.
Even if "ICANN" was aware (doubtful), do you really think the DNSEXT working group would value ICANN's position more than, say, VeriSign's?
They had a responsibility to tell the IETF that this was a non-negotiable requirement and that failure to meet it would mean that ICANN would be unable to deploy DNSSEC.
Do you honestly believe ICANN can dictate to the IETF community (or anybody else with the exception of contracted parties) how to do much of anything? You have a very odd view of how ICANN works.
Ten years later the only part of ICANN that seems to interest them is the idea that they will have sole control of the root zone
You are aware, of course, that ICANN isn't even the party that is going to be signing the root zone, right? And how the root KSK is being managed?
Sounds to me like you just want to bash ICANN. This gets boring after a while.
Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp> 16 février 2010 06:05
There are two separate functions in the routing layer. There are security issues in both cases.
"interdomain routing security", for which SIDR WG was scoped, is the second one, though its charter is totally confused.
The second problem is a much harder one to address using PKI. It is quite possible that PKI is not the right tool at all.
PKI is not, which means it is confirmed again that IETF, including IAB, is brain dead.
It's not an issue specific to IANA or ICANN and IPv6 is a better evidence than PEM or DNSSEC.
Patrik Fältström <paf@cisco.com> 16 février 2010 07:46
It is now generally accepted that PEM was undeployable because the single root model is not workable. --> And this is the fault of IANA and/or ICANN how?
Philip, yes, because people did not think strongly enough on how to create the one single root. Because a single root among other things created a problem for the various business models out there.
For domain names and IP addresses, we already have a root, so that problem does not exist. And that is exactly what IAB states.
