At 03:14 AM 25-02-08 -0500, Paul Wall wrote:
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. -Hank
Changed the subject line a little... On Mon, 25 Feb 2008, Hank Nussbacher wrote:
At 03:14 AM 25-02-08 -0500, Paul Wall wrote:
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: http://www.ietf.org/mail-archive/web/sidr/current/msg00201.html -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
On Feb 25, 2008, at 6:08 AM, Pekka Savola wrote:
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: http://tinyurl.com/3y3pzl -danny
On Mon, 25 Feb 2008, Danny McPherson wrote:
(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. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
<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
On Mon, 25 Feb 2008 15:29:01 EST, Randy Epstein said:
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
participants (6)
-
Arnd Vehling -
Danny McPherson -
Hank Nussbacher -
Pekka Savola -
Randy Epstein -
Valdis.Kletnieks＠vt.edu