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. http://www.ietf.org/mail-archive/web/ietf-announce/current/msg07028.html " 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." It is not necessary for the IAB to state any more than that it is desirable to prevent accidental conflicting certifications. It should not attempt to state anything more. It is not an expert body on X.509 infrastructure, it is a body which typically has one or at most two experts in that field. As it happens, having a single root does nothing to prevent accidental conflicting certifications, not a sausage, nada, zip, nihil. The only way to prevent accidental collisions is to have a validation mechanism that checks signed data issued by IANA with signed data issued by the RIRs. Now you can conflate that with an X.509 PKI, but doing so means that you have created completely new path validation semantics. So you have all the disadvantages of using an existing PKI specification and none of the advantages. It is not going to be possible to use existing X.509 processing code without modification. Worse yet, attempting to use path constraints to control conflicts means that the RIRs are going to find it very difficult to apply the type of online/offline key management we would want them to use. It is a design I have seen before, the customer ended up expressing regret for the consequences (but not enough regret to change to the alternative I had proposed originally). I find it very hard to believe that a system that is so tightly coupled to the technology is going to prove sufficiently flexible to be practical. My experience is that when you deploy crypto in a situation that has not previously had crypto you suddenly discover a wide range of unexpected deviations from the pattern expected. Taking another look at this problem, I think I have found a solution that dramatically reduces the deployment cost and risk for all parties, eliminates the use of 'exotic' X.590v3 application and most importantly, eliminates the need for most IP block holders to obtain a signature key. One of the important side benefits of this scheme is that the resilience of the Internet routing layer is greatly enhanced. The risk of BGP redirection through remapping of the IP-AS mapping is eliminated for a large number of endpoints without any effort being required on their part. If we do get to a point where there is a major Internet meltdown due to kinetic attack, it is possible to re-establish a major portion of the routing tables from static data. Here is how I would issue signed ownership statements for IP address blocks: IANA, and the 5 RIRs establish standards based, independent PKIX pkis with themselves as root authority (cost circa $40K if outsourced) The 6 root PKIs cross certify. This means that at the end of the process any of the six may be regarded as a root. IANA and the 5 RIRs maintain a machine readable log of their actions in both a consolidated and delta format. These are signed using online keys that are generated at periodic (e.g. 1 year) intervals and signed using the offline keys. Every 24 hours (1 hour if necessary) a new delta file of the machine readable log is signed and distributed Every 7 days a new consolidated file is signed and distributed. [Note here that the technical requirements imposed on the RIRs and IANA are limited to the type of operation that can be reasonably be performed with very minimal deviation from their current practice. It may well be desirable for the format to support pre-dated transactions so that block reassignments can be advertised in advance] IANA signing statements allocate an entire block of IP addresses to a RIR. RIR signing statements allocate a block of IP addresses to an AS number OF RECORD, this need not be the actual assignment as far as BGP is concerned Unless we are in a 'defection' condition the validation rules for determining if a signing statement is valid is to verify that the RIR statement has a corresponding IANA allocation statement. Cross references in the machine readable format may facilitate this. In the unlikely case we are in a defection condition then an event has occurred such that one or more of the RIRs no longer accepts the authority of IANA. The scheme outlined is designed to 'soft-fail' in this circumstance, effectively ensuring that a stalemate is achieved until the RIRs and IANA are back in agreement. The purpose of including this particular condition is not because IANA is not trusted but because any single point of failure may be coerced. Alternatively, any system that involves online crypto may be subject to a physical attack. Rather than deploy $5 million plus worth of physical protection, it is safer to establish a situation where there is no single point of failure. Note here that one significant advantage of this architecture is that IP block holders do not need to obtain keys unless they wish to reassign their blocks to another party on a temporary basis, use anycast or perform similar activities. This is important for deployment as it greatly reduces the number of parties that require a key. or the use of secure BGP. Only the larger and more sophisticated parties need establish an AS holder key and deploy signature technology for the purpose of authenticating IP block to AS number bindings. I am leaving out the issue of routing table generation as that is a very different set of issues. The parties that do need to establish a signature key would cross certify with one or other of the RIRs or IANA using a set of practices that ensure that the holdership of the corresponding AS number is validated. Again, an online/offline configuration is to be preferred. Cross certification events would be noted in the RIR machine readable log. The way that I would manage a transition would be to advertise a series of cut-off dates. * On the first cut-off date any IP address block that had not been observed as being allocated to an AAS number other than the AS number of record would be flagged as 'locked' and could only then be assigned to another AS number by means of a signed BGP request. * On the second cut-off date, all IP address blocks would be marked locked * On the third cutoff date, backbone routers would cease forwarding unsigned BGP mappings for IP blocks. If we adopted this plan it would be the first time that we had ever transitioned an entire chunk of Internet infrastructure from an insecure state to a state where security was now a requirement. Unlike the IAB scheme, this one does not disrupt the existing trust relationships between IANA and the RIRs. It does not create inter-governmental concerns of increasing 'dominance'. Nor does it create an incentive for someone to enter a SOC with a gun and tell someone to hand over the crypto. There can be a timetable for deployment, and that timetable can be credibly short. -- 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