ietf
[Top] [All Lists]

Re: On the IAB technical advice on the RPKI

2010-03-21 20:07:30

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,
Thanks for your comments here, not surprisingly, they're spot on...  

Additionally, it might be worth stating that the primary purpose of the
RPKI and most of the SIDR work to date hasn't been as much about secure
routing as it has been about providing a cryptographically verifiable
authoritative infrastructure describing who holds what number resources
(IPv4, IPv6 and ASNs).  Amazingly, this hasn't existed in any coherent
form until now, and it is necessary before any type of secure routing on
the Internet can happen - it's just that the folks who allocate those
resources haven't had a clear incentive to invest in such an
infrastructure until now.  The best any network operator generating any
type of routing policy derived from allocation information can do today
is hope for Internet Routing Registry (IRR) hooks some Regional Internet
Registries (RIRs) might provide that tie prefix allocations to origin
ASNs (e.g., RIPE's stuff), and hope that those (and all other) IRRs
employ authenticated update mechanisms.  There's very little to no
inter-provider filtering today on the Internet, and it's actually in
worse condition than it was 15 years ago -- while infrastructure
availability is far more critical.  

Enabling secure routing mechanisms, be they in dynamic inter-domain
routing protocols (e.g,. SBGP), computed offline and used for
<prefix,asn(s)> lists or other statically configured routing policy, or
something completely different, is simply one application of an RPKI.
 And certainly, most folks paying attention to this work realize that
you first need a database describing who holds what resources and who is
authorized to originate route announcement associated with a given
resource.  Naturally, alignment of who allocates those resources (e.g.,
IANA->RIRs->...) provides operational simplicity and simplifies
collision avoidance.  Once that exists, you can perform origin
validation, and then look for ways to perform path validation (much more
difficult in practice, but absolutely necessary), and then perhaps
employ that same infrastructure to enable inter-domain feasible path
anti-spoofing techniques.

The statement from the IAB is referring to the global RPKI bits, and at
the end of the day relying parties are going to employ systems and
capabilities such as those being defined in SIDR and enabled by RPKI in
a manner which allows them to comply with corporate or national security
objectives, and discussions that have taken place in that working group
are clearly sensitive to this.  

I'm quite certain that the folks involved with SIDR would welcome any
participation from folks here if you have feasible ideas..

-danny (speaking as an individual)
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf

<Prev in Thread] Current Thread [Next in Thread>