Copy to NANOG for those who aren't on ARIN lists but may be interested in this info.
FYI.
/John
thanks john. your consideration to the ops community is appreciated.
ARIN continues its preparations for offering production-grade resource
certification services for Internet number resources in the region.
ARIN recognizes the importance of Internet number resource
certification in the region as a key element of further securing
Internet routing, and plans to rollout Resource Public Key
Infrastructure (RPKI) at the end of the second quarter of 2011 with
support for the Up/Down protocol for those ISPs who wish to certify
their subdelegations via their own RPKI infrastructure.
way cool. and there are open source tool-sets the isps can run to
handle their resources, generate roas, ...
ARIN continues to evaluate offering a Hosting Resource Certification
service for this purpose (as an alternative to organizations having to
run their own RPKI infrastructure), but at this time it remains under
active consideration and is not committed. We look forward to
discussing the need for this type of service and the organization
implications atour upcoming ARIN Members Meeting in April in San Juan,
PR.
i understand fearing holding others' private keys and critical data. no
blame there.
<separate subject>
but out of curiousity, how reality based are arin's general liability
fears? in the last few years, how many times has arin been a named
defendant in a law suit? how many times a [principal] plaintiff?
randy
How many times has the operational integrity of ARIN's infrastructure
influenced actual routing on the Internet in the past? Seems like
well-placed concern on behalf of the ARIN BoT, IMO.
<separate subject>
Beginning to wonder why, with work like DANE and certificates in DNS
in the IETF, we need an RPKI and new hierarchical shared dependency
system at all and can't just place ROAs in in-addr.arpa zone files that are
DNSSEC-enabled.
--but very happy we have some progress for Internet number resource
certification.
-danny
Beginning to wonder why, with work like DANE and certificates in DNS
in the IETF, we need an RPKI and new hierarchical shared dependency
system at all and can't just place ROAs in in-addr.arpa zone files
that are DNSSEC-enabled.
let's wind the wayback machine to 1998
draft-bates-bgp4-nlri-orig-verif-00
randy
Yep, read that way back when it was posted initially, and again
a short while back, makes good sense, methinks.
And now that DNSSEC is deployed and DANE is happening,
you could even include certificates there in the event that relying
parties want to employ them for dynamic secure routing in the
future and we wouldn't have to build (or deal with the operational
and political hurdles that are sure to arise) with RPKI at all.
-danny
And now that DNSSEC is deployed
and you are not sharing what you are smoking
and DANE is happening
see above
randy
root and .arpa are signed, well on the way, particularly relative
to RPKI.
Incremental cost of signing in-addr.arpa using a deployed DNS
system as opposed to continuing development, deployment and
operationalizing and dealing with all the political issues with
deploying a new RPKI system -- hrmm.
And again, I'm not opposed to RPKI and know we REQUIRE
number resource certification before we can secure the routing
system. I just don't like the notion of deploying a brand new
system with data that at the end of the day is going to look an
awful lot like the existing in-addr.arpa delegation system that's
deployed, and introduce new hierarchical shared dependencies
that don't exist today. Keep it simple?
-danny
In the case where (say)
RIR allocates 10.0.0.0/8 to A
A allocates 10.1.0.0/16 to B
B allocates 10.1.1.0/24 to C
there's a clear path of delegations in the DNS under IN-ADDR.ARPA from RIR -> A -> B -> C and this matches the chain of address assignments. If you adopt the convention that a secure delegation (a signed DS RRSet) is analogous to an RPKI signature over a customer certificate, then this seems vaguely usable.
But what about this case?
RIR allocates 10.0.0.0/8 to A
A allocates 10.0.0.0/16 to B
B allocates 10.0.0.0/24 to C
In this case the DNS delegations go directly from RIR to C; there's no opportunity for A or B to sign intermediate zones, and hence no opportunity for them to indicate the legitimacy of the allocation.
As a thought experiment, how would you see this working?
Joe
IN-ADDR.ARPA will be signed relatively soon, as part of the work described here:
http://in-addr-transition.icann.org/
Timeline to follow, here and other similar lists, some time relatively soon. But I'm curious about your thoughts on the case I mentioned in my last message. I don't think the existence of a secure delegation chain from the root down to operator of the last sub-allocated address block is all that is required, here.
Joe
Right - so, the macro point here is that in order to make use of rPKI so as to ensure the integrity of the global routing system, the presupposition is that there's already sufficient integrity in said routing global system for the rPKI tree to be successfully walked in the first place, given that it's all in-band, right?
And since it's all in-band, anyways, with the recursive dependencies that implies, why not make use of another, pre-existing inband hierarchical system which is explicitly designed to ensure the integrity of its answers, and which is already in the initial stages of its deployment - i.e., DNSSEC?
Note I'm not advocating this position, per se, just being sure I understand the argument for purposes of discussion.
I just don't like the notion of deploying a brand new system
you want certificates etc? or did you plan to reuse dns keys?
if the former, than all you are discussing is changing the transport to
make routing security rely on dns and dns security. not a really great
plan.
if the latter, then you have the problem that the dns trust model is not
congruent with the routing and address trust model.
randy
New prefix-based RRs? And perhaps even a new .arpa or
in-addr.arpa subdomain, the draft Randy referenced even
discussed the latter, IIRC.
-danny
It's in-band only in the sense of delivery. The worst that a
corruption of the underlying network can do to you is deny you
updates; it can't convince you that a route validates when it
shouldn't. And even denying updates to your RPKI cache isn't that
bad, since the update process doesn't really need to be real-time.
Things will stay the same until you start hitting expiration times.
The ultimate worst case is that everything expires and there are no
RPKI-validated routes ... just like today.
--Richard
The more you have to invent, though, the more this sounds like a
bike-shed discussion.
s/DNSSEC/X.509/g
s/delegating reverse "prefix" zone/signing RPKI delegation certificate/g
you want certificates etc? or did you plan to reuse dns keys?
I suspect the former, reusing much of the SIDR machinery
perhaps, although....
if the former, than all you are discussing is changing the transport to
make routing security rely on dns and dns security. not a really great
plan.
Right, I've heard the circular dependency arguments. So, are
you suggesting the RPKI isn't going to rely on DNS at all?
I'm of the belief RPKI should NOT be on the critical path, but instead
focus on Internet number resource certification - are you suggesting
otherwise?
if the latter, then you have the problem that the dns trust model is not
congruent with the routing and address trust model.
That could be easily fixed with trivial tweaks and transitive trust/
delegation graphs that are, I suspect.
-danny
Right, I've heard the circular dependency arguments. So, are you
suggesting the RPKI isn't going to rely on DNS at all?
correct. it need not.
I'm of the belief RPKI should NOT be on the critical path, but instead
focus on Internet number resource certification - are you suggesting
otherwise?
<channeling steve kent>
see the word 'certification'? guess where that leads. pki. add
resources and stir.
if the latter, then you have the problem that the dns trust model is
not congruent with the routing and address trust model.That could be easily fixed with trivial tweaks and transitive trust/
delegation graphs that are, I suspect.
not bloody likely. the folk who sign dns zones are not even in the same
building as the folk who deal with address space. in large isps, not
even in the same town.
randy
In terms of organic, real-time route validation performed by routers - which it is assumed is an ultimate goal of rPKI, at some point in the future - one should hope this wouldn't be the case, yes?
I think the idea is to effectuate de-siloing in this space to the point that the DNS folks would make the appropriate delegations to the addressing folks, who would then proceed to create/administer their RRs/certs without further day-to-day reference to the DNS folks.
the folk who sign dns zones are not even in the same building as the
folk who deal with address space.I think the idea is to effectuate de-siloing in this space to the
point that the DNS folks would make the appropriate delegations to the
addressing folks, who would then proceed to create/administer their
RRs/certs without further day-to-day reference to the DNS folks.
read more carefully. i was responding to danny taking my bait of using
dns keying for resource keys.
randy
The difference is that we don't have an operational RPKI system, we
do have an operational DNS one.
It's most certainly NOT a bike shed discussion - at least with respect
to how I'd configure my routers.
I suspect I've sufficiently chummed the waters, I'll kick back and absorb
all the reasons this is a whack idea 
-danny