Home page logo
/

nanog logo nanog mailing list archives

RE: Thanks & Let's Prevent this in the Future.
From: Jon Lewis <jlewis () lewis org>
Date: Wed, 1 Feb 2012 12:51:58 -0500 (EST)

On Wed, 1 Feb 2012, George Bonser wrote:

One problem is the number of routing registries and the requirements differ for them. The nefarious operator can enter routes in an IRR just as easily as a legitimate operator. There was a time when some significant networks used the IRRs for their filtration policy. I'm not sure how many still do.

A few do, but IRR data really can't be trusted as a means of authenticating authority to advertise IP space. It's a nice system for automating route filter updates (between the customer and provider...i.e. I add data to an IRR, and Level3 auto-updates my prefix filter), but when anyone can put anything into the IRR dbs, obviously everyone using the IRR dbs isn't going to stop someone from hijacking someone else's space.

As a regional ISP / hosting provider, my policy for accepting BGP routes from customers has been to check RIR whois data, make sure the space appears to be owned by the customer, and if there's any question, ask for clarification and/or an LOA from the customer showing that they are authorized to use the space. Every customer gets a prefix filter that allows them to announce only what we've verified they're authorized to announce.

Level3, I suppose, just trusts customers won't announce space they shouldn't. The alternative, which I've dealt with with some other "Tier 1's" is that they require customers to provide an LOA every time they want to add a CIDR to their prefix filter. That's more paper work for me and for them, and tends to be slower, as someone has to manually approve (maybe manually apply) the change request.

Given what we have available today, there's security or convenience...pick one.

It seems like the IRR thing could reasonably easily be solved if the RIRs got more deeply involved.

Suppose, as an ARIN member, I used ARIN's IRR. I'd start out by registering my maintainer object, my ASN, my routes, and an as-set. Then, when I wanted to add customer ASNs to my as-set, the system wouldn't allow me to do so unless the customer had already registered their ASN with my ASN as an approved provider/path. The customer, if they had no ASN, would be responsible for updating their route (PI or PA) in the IRR db, stating my ASN is a valid origin for their route. This would solve the problem of larger providers like Level3 blindly accepting my as-set because all the authentication/authorization would already have been done before the data went into the IRR db. Things get a little more complicated when I pick up a customer who has "out of region" objects, i.e. RIPE IPs/ASN, but if all the RIRs worked together and standardized how the information is maintained, it could work. i.e. When I try to add the RIPE ASN to my as-set, ARIN's system would check RIPE's system to see if that ASN's owner had set my ASN as a valid provider/path for their ASN.

This seems so simple, either it should have been implemented a decade or more ago, or perhaps I'm overlooking something. It wouldn't stop route advertisements from providers who don't care / don't filter, but it would make systems like Level3's more secure...and if all the "Tier 1's" adopted similar automated filter generators based on the RIR IRR dbs, it would stop unauthorized announcements from getting far.

The problem of email spam is an interesting one that has been battled for a very long time and is probably better discussed on a list dedicated to that topic.

Definitely...but the issue here is ownership/authorization to use IP space, and how stop unauthorized BGP announcements when providers don't or won't filter their BGP customers.

----------------------------------------------------------------------
 Jon Lewis, MCP :)           |  I route
 Senior Network Engineer     |  therefore you are
 Atlantic Net                |
_________ http://www.lewis.org/~jlewis/pgp for PGP public key_________


  By Date           By Thread  

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