With regards to RPKI, I'd like to point out what is possible now, and what the maturity is of the implementations. All RIRs have a system up an running. As John Curran pointed out in an earlier message, ARIN will have a production system up this year, but right now you can already gain experience with their testbed: https://www.arin.net/resources/rpki.html
If you create your ROAs there, there are actually quite some parties who will already validate this information. Of course, basing an actual routing decision on this is a second step; for that we'll need more and better quality data. As it stands there are about 1400 IPv4 and 300 IPv6 announcements that have a ROA associated with them. There are some public test beds up that will give a valid route a higher pref, and an invalid one a lower pref. So create a ROA for your announcements, and then watch it show up on actual RPKI-capable Cisco and Juniper routers: EuroTransit have made their instance of the RIPE NCC RPKI Validator public, so you can easily verify the validity of your announcement here by searching for it: http://rpki01.fra2.de.euro-transit.net:8080/bgp-preview Then you can log in on a public Juniper here: 193.34.50.25, 193.34.50.26 telnet username: rpki password: testbed Try commands such as: - show validation session detail - show validation statistics - show validation database - show route protocol bgp 204.127.128.0/17 - show route protocol bgp validation-state valid You can also log into a public Cisco here: rpki-rtr.ripe.net telnet username: ripe no password Try commands such as: - sh ip bgp rpki table - sh ip bgp rpki server - sh ip bgp 93.175.146.0/24 - sh ip bgp ipv6 unicast rpki table - sh ip bgp ipv6 unicast 2001:630::/32 Both routers are configured along these lines: https://www.ripe.net/certification/router-configuration and talk to the RIPE NCC RPKI Validator service available here: https://www.ripe.net/certification/tools-and-resources Try it out, and give feedback! Cheers, Alex P.S. RFCs 6480-6493 have been published. A big thank you goes out to all the people who made that possible. On 6 Feb 2012, at 08:59, Mark Tinka wrote: > On Monday, February 06, 2012 03:06:24 PM Christopher Morrow > wrote: > >> do you have customers with 10k long prefix lists? it gets >> hard when the lists get long, or the data is for >> downstream folks of your customer. Good that someone's >> checking though, I'd love to see this part automated. > > No, we don't have customers with 10,000-long prefix lists, > but we have planned to implement automation (either using > the IRR Toolset or home-grown solutions) to make this > possible as a means to scaling, should that time arise. > > As it is now, throwing NOC staff at the problem for the > volumes we have works well enough. But this is, by no means, > a panacea as we scale up. > > Heck, one must even worry whether a some router > configurations can take that many lines. But there are other > ways around that. > >> RPKI doesn't necessarily mean that the router knows >> anything about certificates in the short-term. I think >> there's a time when 'the resource certification system' >> (which is really, today, the rpki) holds cert/roa data >> that you could use to filter what the IRR tells you for >> a customer. You could even do this in any automated >> manner! > > Well, given validation information will be available within > a network, one may use it in non-obvious ways to implement > policy. > >> The time between the previous and next paragraphs though >> is when all isp's will need to beat the drums with their >> customers saying: "Hey, you REALLY need to get that shit >> into the 'resource certification system' (rpki), NOW." >> (because shortly we'll stop accepting your "invalid" >> routes... and then the interwebs won't be able to find >> you, and we'll all be sad.) > > Well, we have all seen how doing this with DNSSEC, IPv6 and > 4-byte ASN's worked out. > > We need to understand that different operators and different > customers will have varying reasons as to why they can't yet > "do the right thing". There is abundant evidence of this > with other similar initiatives. > > Adoption will have to be incremental. During that time, the > Internet must not break. > >> sure... it's not working so well though :( > > Not for lack of having some kind of solution. > > What we have today may not be the best, most scalable > option, but it is one nonetheless. Automating it (like what > RPSL does) is how you can make it scale to some extent, but > it's still the same solution. > > We can't just sit around waiting for RPKI. There will be > some reason why some of us can't deploy it, while someone > else is thinking up its successor. Rinse, repeat. > > Mark.