Sorry for the subject change, it seems now we're talking about something perhaps more relevant to me (security and routing stuff) On Wed, Jan 5, 2011 at 5:32 PM, Randy Bush <randy@psg.com> wrote:
i have a rumor that arin is delaying and possibly not doing rpki that seems to have been announced on the ppml list (to which i do not
I have heard this as well ... the message in the archive is: (arin-announce actually, not ppml) <http://lists.arin.net/pipermail/arin-announce/2010-December/001107.html> Essentially the note says that Kosters & crew are delaying until Q2-2011 the deployment of RPKI services (nebulous 'other features need to be implemented due to security concerns' is the stated reason)
subscribe). as it has impact on routing, not address policy, across north america and, in fact the globe, one would think it would be announced and discussed a bit more openly and widely.
I agree... so, what is the RPKI for and why should ops/security folks care? (and should we care enough to poke our local ARIN constabulary in the eye with a sharp stick?) I'm of the belief that if we (ops/security folks) feel the need to have a more secure routing infrastructure so we can hope to avoid incidents like: (quick examples, there are many others like these) o AS7007 full-table re-announce + re-originate o ConEdison "hijack" + re-originate o Pakistan/YT hijack + re-originate o "Pilosov/Kapela" hijacks/manipulations o Christmas TurkTelecom leak/hijack o PRC network leakages/hijacks/etc of April 2010 (Note: let's not debate if the above incidents are one/the-other hijack/mistake/etc, the simple fact is traffic was diverted and some better filtering/control would have avoided these failures in our system) We need at least these things to exist: o an accurate mapping of resource (netblock/asn) to authorized-entity (RIR/NIR/LIR/Customer/...) o a system to manage this data for our routing equipment o protocol enhancements that can be used to help propagate the mapping information or at the least help a router programmaticly understand if a resource is being used by the authorized entity o routing software that can digest the enhanced data o routing hardware that won't crumple under the weight of (what seems like) heavier weight routing protocol requirements I believe the lynch-pin in this is the accurate mapping of resources to authorized users, I believe that is supposed to be the RPKI system. I believe that the RPKI will tell me, an end-operator, that 63.0.0.0/9 was handed from IANA to ARIN to UUNET/VerizonBusiness and that this is being properly announced with an Origin-AS of 701. Having the service run by these organizations seems reasonable to me... IANA signs down to the RIR (ARIN in my example) and ARIN signs to VZB who can choose to sign down to their customers if necessary. Today there is a very loose, in all regions not just ARIN's, association with lots of cruft and inaccuracies. The RPKI, operated by RIR's, would provide some solid linkage and authority between resources and owners, it should help to enforce cruft management as well as provide mechanical (and relatively simple) management of the data and associated filtering/etc on devices. There is, of course, some risk with this model and we should take the time to accept/discuss that as well. Danny has had lots of good input on this topic, I'd hope that other folks who've been through longer term ops battles with filtering (jared, shane, charles gucker, rs, ras, ...) and the like can take some time to think about this problem. I'd love it if we could have some reasoned discussion here as well. Finally, everyone should go poke their ARIN corporate representative(s) (or email the BoT or AC folks directly even?) with their thoughts on whether or not the RPKI system and Routing Security are important items for ARIN (as one RIR) to pursue for the health of the Internet and Ops Sanity. The BoT folks are listed at: <https://www.arin.net/about_us/bot.html> (with email addresses even!) The AC folks are listed at: <https://www.arin.net/about_us/ac.html> -Chris