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(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf