Home page logo
/

nanog logo nanog mailing list archives

Re: Hijacked Network Ranges
From: Alex Band <alexb () ripe net>
Date: Mon, 6 Feb 2012 11:47:23 +0100

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.



  By Date           By Thread  

Current thread:
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]