RE: Thanks & Let's Prevent this in the Future.

[Jon Lewis <jlewis () lewis org>]

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_________