[149488] in North American Network Operators' Group
Re: Hijacked Network Ranges
daemon@ATHENA.MIT.EDU (Alex Band)
Mon Feb 6 05:48:25 2012
From: Alex Band <alexb@ripe.net>
In-Reply-To: <201202061559.32377.mtinka@globaltransit.net>
Date: Mon, 6 Feb 2012 11:47:23 +0100
To: mtinka@globaltransit.net
Cc: nanog@nanog.org
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
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:=20
- 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=20
> wrote:
>=20
>> 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.
>=20
> No, we don't have customers with 10,000-long prefix lists,=20
> but we have planned to implement automation (either using=20
> the IRR Toolset or home-grown solutions) to make this=20
> possible as a means to scaling, should that time arise.
>=20
> As it is now, throwing NOC staff at the problem for the=20
> volumes we have works well enough. But this is, by no means,=20
> a panacea as we scale up.
>=20
> Heck, one must even worry whether a some router=20
> configurations can take that many lines. But there are other=20
> ways around that.
>=20
>> 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!
>=20
> Well, given validation information will be available within=20
> a network, one may use it in non-obvious ways to implement=20
> policy.
>=20
>> 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.)
>=20
> Well, we have all seen how doing this with DNSSEC, IPv6 and=20
> 4-byte ASN's worked out.
>=20
> We need to understand that different operators and different=20
> customers will have varying reasons as to why they can't yet=20
> "do the right thing". There is abundant evidence of this=20
> with other similar initiatives.
>=20
> Adoption will have to be incremental. During that time, the=20
> Internet must not break.
>=20
>> sure... it's not working so well though :(
>=20
> Not for lack of having some kind of solution.
>=20
> What we have today may not be the best, most scalable=20
> option, but it is one nonetheless. Automating it (like what=20
> RPSL does) is how you can make it scale to some extent, but=20
> it's still the same solution.
>=20
> We can't just sit around waiting for RPKI. There will be=20
> some reason why some of us can't deploy it, while someone=20
> else is thinking up its successor. Rinse, repeat.
>=20
> Mark.
