Thanks & Let's Prevent this in the Future.
Jon Lewis
jlewis at lewis.org
Wed Feb 1 17:51:58 UTC 2012
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_________
More information about the NANOG
mailing list