Before declaring victory, lets see if anyone actually uses it to validate any data. X.509v3 is a proven technology in the field of authentication. Attempts to make it do more than authentication do not have a good record. If a RIR makes an unintentional error, it will be due to a software error. That can just as well occur in the X.509 path math as anywhere else. If the fault is at IANA rather than a RIR, it could cause entire superblocks of IP address allocations to suddenly be regarded as bogons. All that any mechanism can hope to achieve here is to make errors detectable and possibly correctable. Claiming that one architecture or another prevents error is bogus. Let us imagine that an IANA employee manages to corrupt the main data file so that the superblocks enclosing the A, F and J roots for the DNS are misallocated. The corresponding IP addresses would suddenly fall out of the routing tables and the remaining load would probably overwhelm the remainder in a short time. That would represent the nearest thing to a 'kill switch' for the Internet. There are better ways to address the problem than at the RIRs. We would probably want ISPs to continue to treat the main DNS roots as special cases when it comes to accepting routing information regardless of what 'secure' BGP might be telling them. But the idea that concentrating authority at one node of a system makes things more stable or more secure is bogus. On Thu, Mar 18, 2010 at 1:28 PM, Stephen Kent <kent@xxxxxxx> wrote: > At 9:15 PM -0500 3/13/10, Phillip Hallam-Baker wrote: >> >> So what has me annoyed about the IAB advice is that they gave advice >> about a particular means where they should have instead specified a >> requirement. > > Phil, > > I am not commenting on your proposal, but I do want to make a few > observations that are relevant to this discussion. > > I believe that the point the IAB was making is that if each RIR acts as a > TA, any one of them could make an error (or suffer a compromise) that would > allow for conflicting certs to be issued below the affected RIR. The certs > used for the RPKI include RFC 3779 extensions. If IANA acts as the only TA, > then it will issue certs to the RIRs representing their allocations from > IANA. Unless IANA makes an error in this cert issuance procedure (which > should be aligned with its allocation of address space to the RIRs), then > there can be no (undetected) conflicts among the RIRs re resource holdings. > Also recall that IANA needs to act as a TA anyway, for unallocated, legacy, > and reserved address space. So the choice the IAB was addressing was one TA > vs. six. > > You commented that using X.509 certs in this context requires "completely > new path validation semantics." The semantics are well-defined in RFC 3779, > which was issued in June 2004. I also observe that OpenSSL already supports > cert path validation using 3779 extensions, and has done so for at least a > couple of years. Note also that the RPs here are primarily ISPs. They will > use software that yields outputs consistent with their goals of origin AS > validation. Based on the SIDR WG activities, this means validating ROAs, > using EE resource certs (which contain 3779 extensions). This is not a > context where browsers or other commodity cert processing software will be > used. I know of at least two independently-developed, open source > implementations of RP software that deal validate ROAs using resource certs. > There may be 1 or 2 more implementations in process. Four of the five RIRs > have working CA software that issues resource certs, and several of them > have adopted the offline/online CA model to which you refer. So concerns > about the difficulty of using X.509 certs here seem unfounded. > > Given these observations, the public declaration last year by the NRO that > all 5 RIRs will offer RPKI service as of 1/1/11, and the ongoing SIDR WG > efforts, most of this discussion seems OBE at this stage. > > Steve > -- -- New Website: http://hallambaker.com/ View Quantum of Stupid podcasts, Tuesday and Thursday each week, http://quantumofstupid.com/ _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf