Hijacked Network Ranges
alexb at ripe.net
Mon Feb 6 04:47:23 CST 2012
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:
Then you can log in on a public Juniper here:
telnet username: rpki
Try commands such as:
- show validation session detail
- show validation statistics
- show validation database
- show route protocol bgp 188.8.131.52/17
- show route protocol bgp validation-state valid
You can also log into a public Cisco here:
telnet username: ripe
Try commands such as:
- sh ip bgp rpki table
- sh ip bgp rpki server
- sh ip bgp 184.108.40.206/24
- sh ip bgp ipv6 unicast rpki table
- sh ip bgp ipv6 unicast 2001:630::/32
Both routers are configured along these lines:
and talk to the RIPE NCC RPKI Validator service available here:
Try it out, and give feedback!
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
>> 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
> Well, given validation information will be available within
> a network, one may use it in non-obvious ways to implement
>> 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.
More information about the NANOG