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