> > 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@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf