Incorrect. Some do filter and do it well. Problem is that it is in general a minority - many of which can be found here on NANOG.
-Hank
Changed the subject line a little...
Results were planned to be presented at the next NANOG, but they
shouldn't be a surprise to anyone in the industry: nobody filters.Incorrect. Some do filter and do it well. Problem is that it is in general a minority - many of which can be found here on NANOG.
In a lot of this dialogue, many say, "you should prefix filter". However, I'm not seeing how an ISP could easily adopt such filtering.
Let's consider the options:
1) manually maintained prefix-filters. OK for small ISPs or small
users where the prefix churn is minimal.
2) build the filters based on IRR data. But which IRRs to use?
some points here:
a) only RIPE IRR uses a sensible security model [1], so if you use
others, basically anyone can add route objects to the registry.
How exactly would this model be useful?
b) use your own IRR where you require your customers to add the
route objects and verify that they're OK. This means a lot of
work for you and even more for your customers.
So, this is no excuse for not doing prefix filtering if you only do business in the RIPE region, but anywhere else the IRR data is pretty much useless, incorrect, or both.
(Yeah, we prefix filter all our customers. Our IPv6 peers are also prefix filtered, based on RIPE IRR data (with one exception). IPv4 peers' advertisements seem to be too big a mess, and too long filters, to fix this way.)
[1] Joe Abley's explanation on SIDR list on 20 Jun 2007:
In a lot of this dialogue, many say, “you should prefix filter”. However, I’m not seeing how an ISP could easily adopt such filtering.
So, this is no excuse for not doing prefix filtering if you only do business in the RIPE region, but anywhere else the IRR data is pretty much useless, incorrect, or both.
Agreed.
(Yeah, we prefix filter all our customers. Our IPv6 peers are also prefix filtered, based on RIPE IRR data (with one exception). IPv4 peers’ advertisements seem to be too big a mess, and too long filters, to fix this way.)
Do you explicitly filter routes from your upstream or transit providers?
E.g., if one were to announce, say, a more specific of one of your
customer’s routes to you would you accept it? What about someone
else’s address space?
The only full set of prefix filtering I’ve ever seen implemented (i.e.,
BGP customers AND peers) was b y ANS during my days at iMCI
~95. It was extremely painful at times, even for us, if we wanted to
advertise new address space we had to update IRR objects and
wait on their nightly push of updated routing policies at ANS. We
generated our own routing policies automatically off our IRR, which
mirrored others as well, and explicitly prefix filtered customers with
some fixed prefix and AS path-based policies applied to peers. If it
became really urgent, then we’d call ANS and have them manually
update their policy, and subsequently ‘bounce’ the route
announcement to trigger transmission of a new update.
This was long before incrementally updated filters and things like
BGP route refresh ever existed. Prefixes and AS-MACROs had to
be right in the IRRs or the policies wouldn’t be updated. It’s to bad
other folks didn’t follow suit.
As for this event, a slightly different spin here:
-danny
(Yeah, we prefix filter all our customers. Our IPv6 peers are also prefix filtered, based on RIPE IRR data (with one exception). IPv4 peers' advertisements seem to be too big a mess, and too long filters, to fix this way.)
Do you explicitly filter routes from your upstream or transit providers?
E.g., if one were to announce, say, a more specific of one of your
customer's routes to you would you accept it? What about someone
else's address space?
Our own or our singlehomed customers' address space -- we would reject such an advertisement. The same inbound consistency check applies to peers and upstreams/transits.
If it's someone else's or a more specific or the same prefix as our multihomed customers -- we accept it. There isn't anything else we can do in practise which would not hurt legitimate routing..
It was extremely painful at times, even for us, if we wanted to
advertise new address space we had to update IRR objects and
wait on their nightly push of updated routing policies at ANS. We
generated our own routing policies automatically off our IRR, which
mirrored others as well, and explicitly prefix filtered customers with
some fixed prefix and AS path-based policies applied to peers. If it
became really urgent, then we'd call ANS and have them manually
update their policy, and subsequently 'bounce' the route
announcement to trigger transmission of a new update.
Sounds like a procedure that should be applied today (whether or not you want to use IRR and/or autogenerated configs is a matter of taste) but the principle seems sound.
<clip>
Our own or our singlehomed customers' address space -- we would reject
such an advertisement. The same inbound consistency check applies to
peers and upstreams/transits.If it's someone else's or a more specific or the same prefix as our
multihomed customers -- we accept it. There isn't anything else we
can do in practise which would not hurt legitimate routing..
<clip>
What do you do when one of your multi-homed customers on your IP space has
an outage on their connection to your network? How would your customers
then reach that customer?
Although this wouldn't be THAT BIG of a deal for small networks, if say a
larger or a Tier-1 provider practiced this (AFAIK, the only somewhat large
network to do this is, believe it or not, PCCW), your customer would
experience a major outage.
There must be a better way. 
Pekka Savola
Regards,
Randy
> Our own or our singlehomed customers' address space -- we would reject
^^^^^^^^^^^
> such an advertisement. The same inbound consistency check applies to
> peers and upstreams/transits.
What do you do when one of your multi-homed customers on your IP space has
an outage on their connection to your network? How would your customers
then reach that customer?
He explicitly said "single-homed". Of course, multi-homed requires different
handling, because you may hear their other home announce them (although again,
you probably shouldn't listen to *THAT* announcement either if *your* link to
them is up). And I posit that if you don't know if your customer is single or
multi-homed, you have *bigger* issues to deal with.
Valdis wrote:
He explicitly said "single-homed". Of course, multi-homed requires
different handling, because you may hear their other home announce them
(although again, you probably shouldn't listen to *THAT* announcement
either if *your* link to them is up). And I posit that if you don't know
if your customer is single or multi-homed, you have *bigger* issues to
deal with.
My bad, I misread his multi-homed comment. From what I understand (and have
seen in practice) PCCW does not listen to their address space from their
peers no matter what the status of the connection to their customer is. I
find this policy flat out flawed.
Randy
Hi,
In a lot of this dialogue, many say, "you should prefix filter".
However, I'm not seeing how an ISP could easily adopt such filtering.Let's consider the options:
[..]
a) only RIPE IRR uses a sensible security model [1], so if you use
others, basically anyone can add route objects to the registry.
How exactly would this model be useful?
[..]
So, this is no excuse for not doing prefix filtering if you only do
business in the RIPE region, but anywhere else the IRR data is pretty
much useless, incorrect, or both.
this is all true and leads us to the question why ARIN, for example,
DOESNT USE A SENSIBLE SECURITY MODEL?!!!!
Actually i asking this myself for a couple of years. IMHO ARIN _should_
either improve their RR software or, better, use the RIPE DB software so
ISPS can build prefix-filters for the ARIN region.
So: Why dont they do it?!!!
Arnd