Re: Hijacked Network Ranges

[Alex Band <alexb () ripe net>]

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.