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
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
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_________