Yes, I've tried that too.. But what I am thinking of doing is, using a route-map/bgp-announcement based version of building 'prefix-list' or 'distribute-list' to decide whether to accept route or not.. But as you said, I don't think that is possible heh.. Thanks! -hc -- Sincerely, Haesu C. TowardEX Technologies, Inc. WWW: http://www.towardex.com E-mail: haesu@towardex.com Cell: (978) 394-2867 On Mon, Aug 25, 2003 at 02:57:57PM -0400, ww@styx.org wrote:

I don't think what you are suggesting is directly possible, although I can think of something that accomplishes the same thing, and only requires extra configuration on the peering session with the route server.

For prefixes recieved from the bogon route server, apply a route map that will (1) send traffic to a Null0 bit sink and (2) set the local preference for these routes to a value suitably large so that the same prefixes learned from other peers never get used.

-w

On Mon, 25 Aug 2003 14:39:59 -0400, Haesu wrote

...

Hi all,

Wondering if anyone would know whether such feature in IOS exists or not...

Most of the time, people use route-maps on bgp neighbors or peer- groups to set an attribute,etc on a prefix that is being announced OUTbound or INbound.

However: On prefixes being announced to me INBOUND, is there a feature to set in route-map so that it checks whether the advertised prefix is already existing in local RIB?

Like for example, I am one of the users who receive bogon advertisements from Rob's route-server.

Now, when I receive prefixes either from my upstream AS or my customers doing bgp with me, I can setup a route-map on the neighbor so that it compares the prefix being announced by neighborAS with existing Rob's bogon prefix in the RIB with bogon route-server community 65333:888.

If the prefix being announced gets a match with existing prefix with 65333:888 already in the router, the route-map would cause a DENY. Thus, making Rob's bogon announcement from his route-server, a bogon route filtering list for me to use on my customers/peers..

If you are not understanding what I am saying, feel free to yell at me to clear up..

This would make it much easier to create dynamic bgp-based route filtering list in my opinion... I am not here to discuss the feasibility of whether doing or inventing this dynamic method of filtering bgp routes; I am rather asking this question to see if anyone is doing something similar to this as it may be useful.

Thanks!

-hc

-- Sincerely, Haesu C. TowardEX Technologies, Inc. WWW: http://www.towardex.com E-mail: haesu@towardex.com Cell: (978) 394-2867

Of course; since there isn't a feature, let's propose another idea: an option to enable "le 24" or "le 32/whatever" to cover specific announcements. -hc -- Sincerely, Haesu C. TowardEX Technologies, Inc. WWW: http://www.towardex.com E-mail: haesu@towardex.com Cell: (978) 394-2867 On Mon, Aug 25, 2003 at 03:30:01PM -0400, Matt Levine wrote:

On Monday, August 25, 2003, at 3:00 PM, Haesu wrote:

...

Yes, I've tried that too.. But what I am thinking of doing is, using a route-map/bgp-announcement based version of building 'prefix-list' or 'distribute-list' to decide whether to accept route or not..

But as you said, I don't think that is possible heh..

Except that what you are proposing would allow your customer to announce 2 /16's just fine from within one of rob's bogon /8's, as the 2 /16's wouldn't be in your rib.

...

Thanks! -hc

-- Sincerely, Haesu C. TowardEX Technologies, Inc. WWW: http://www.towardex.com E-mail: haesu@towardex.com Cell: (978) 394-2867

On Mon, Aug 25, 2003 at 02:57:57PM -0400, ww@styx.org wrote:

...

I don't think what you are suggesting is directly possible, although I can think of something that accomplishes the same thing, and only requires extra configuration on the peering session with the route server.

For prefixes recieved from the bogon route server, apply a route map that will (1) send traffic to a Null0 bit sink and (2) set the local preference for these routes to a value suitably large so that the same prefixes learned from other peers never get used.

-w

On Mon, 25 Aug 2003 14:39:59 -0400, Haesu wrote

...

Hi all,

Wondering if anyone would know whether such feature in IOS exists or not...

Most of the time, people use route-maps on bgp neighbors or peer- groups to set an attribute,etc on a prefix that is being announced OUTbound or INbound.

However: On prefixes being announced to me INBOUND, is there a feature to set in route-map so that it checks whether the advertised prefix is already existing in local RIB?

Like for example, I am one of the users who receive bogon advertisements from Rob's route-server.

Now, when I receive prefixes either from my upstream AS or my customers doing bgp with me, I can setup a route-map on the neighbor so that it compares the prefix being announced by neighborAS with existing Rob's bogon prefix in the RIB with bogon route-server community 65333:888.

If the prefix being announced gets a match with existing prefix with 65333:888 already in the router, the route-map would cause a DENY. Thus, making Rob's bogon announcement from his route-server, a bogon route filtering list for me to use on my customers/peers..

If you are not understanding what I am saying, feel free to yell at me to clear up..

This would make it much easier to create dynamic bgp-based route filtering list in my opinion... I am not here to discuss the feasibility of whether doing or inventing this dynamic method of filtering bgp routes; I am rather asking this question to see if anyone is doing something similar to this as it may be useful.

Thanks!

-hc

-- Sincerely, Haesu C. TowardEX Technologies, Inc. WWW: http://www.towardex.com E-mail: haesu@towardex.com Cell: (978) 394-2867

-- Matt Levine <matt@deliver3.com> "The Trouble with doing anything right the first time is that nobody appreciates how difficult it was." -BIX

On Mon, Aug 25, 2003 at 03:00:45PM -0400, Haesu wrote:

Yes, I've tried that too.. But what I am thinking of doing is, using a route-map/bgp-announcement based version of building 'prefix-list' or 'distribute-list' to decide whether to accept route or not..

But as you said, I don't think that is possible heh..

Foundry supports a feature called Cooperative BGP4 Route Filtering (http://www.foundrynetworks.com/services/documentation/ecmg/BGP4.html#63462) Some digging around at juniper.net reveals that Juniper also supports ORFs but only on the ERX platform (http://www.juniper.net/techpubs/software/erx/erx50x/swconfig-routing-vol2/ht... +bgp-config9.html). Cisco also supports it since 12.0 (http://www.cisco.com/en/US/products/sw/iosswrel/ps1612/products_feature_guid... +186a008008088c.html) It basically sends filters defined in prefix-lists in route refresh messages. A more formal definition of it can be found in the following draft (http://www.ietf.org/internet-drafts/draft-ietf-idr-route-filter-09.txt) -- Cliff Albert | RIPE: CA3348-RIPE | https://oisec.net/ cliff@oisec.net | 6BONE: CA2-6BONE | PGP Fingerprint = 9ED4 1372 5053 937E F59D B35F 06A1 CC43 9A9B 1C5A

On Mon, 25 Aug 2003, Leo Bicknell wrote:

This reminds me of something I've wanted to bring up to the community for a long time. I'd like to see a "route programming language" that gets implemented in a multi-vendor way. No, I'm not talking about like RPSL, but rather, let me give some examples:

http://bird.network.cz/ does pretty much what you want. -Dan -- [-] Omae no subete no kichi wa ore no mono da. [-]

Hello, The reason for me to come up with this idea/question was so that IRR information can be used on a seperate box acting as a "Prefix-list server", which would be basically a route server that distributes prefixes that should be filtered on inbound announcements.. It would be great for integration with RPSL perhaps; RtConfig already does it, but need something that's distributed/dynamic/automated; publishing filtering information over BGP sounds interesting to me.. -hc -- Sincerely, Haesu C. TowardEX Technologies, Inc. WWW: http://www.towardex.com E-mail: haesu@towardex.com Cell: (978) 394-2867 On Mon, Aug 25, 2003 at 04:02:22PM -0400, Leo Bicknell wrote:

This reminds me of something I've wanted to bring up to the community for a long time. I'd like to see a "route programming language" that gets implemented in a multi-vendor way. No, I'm not talking about like RPSL, but rather, let me give some examples:

1) Pull out session details via "variables":

route-statement foo { if ($route has community(1234:$session{'asn'})) { set_asprepend($route, "1234 1234") } }

2) Check for the route in other routing tables:

route-statement bar { if ($route in ospf) { set_localpref($route, 10) } if ($route in bgp && $route has communty(1234:666)) drop($route) } set_localpref($route, 100) }

3) Scan other route tables:

route-statement baz { if ($route supernet-in bgp) { drop($route); } }

4) Other weird stuff:

route-statement hack { if ($route = "1.2.3.0/24") { announce_route("1.2.3.10/32", "192.168.1.1") } }

Basically all the data on the box would be made available via global variables (eg, session IP, session ASN, bgp version, etc), and all dynamic data would have interfaces (eg scan other routing tables, acl's, etc). You'd write a "function" which would get passed a route object, and act on it. Functions could further pass that route on calling other functions (allowing you to create common policy).

Sadly, while I can think of many cool things you could do, I know little about how to really design a languge. I also have no idea how bad other people want this, how hard it would be to get vendors to implement, etc. Feel free to add your support, or call me a crackpot.

-- Leo Bicknell - bicknell@ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - tmbg-list-request@tmbg.org, www.tmbg.org

Hi, NANOGers. ] If folks were to implement explicit prefix filtering ] *everywhere* it wouldn't be necessary to filter only ] bogons and other miscellany explicitly. Agreed! Simple edge filters make this problem go away. While I and the rest of Team Cymru are happy to provide this service, we will gladly find other things to do if folks ubiquitously employ edge prefix filters. :) We attempt to convey this sort of thing in our templates. If folks need assistance building their filters, feel free to ping on us. We charge only the occasional cup of coffee. :) <http://www.cymru.com/Documents/secure-bgp-template.html> <http://www.qorbit.net/documents/junos-bgp-appnote.htm> ] ...no offense Rob, I'm pretty sure our beliefs are aligned here :-). None taken, I completely agree. Thanks, Rob, not just the "bogon guy." :) -- Rob Thomas http://www.cymru.com ASSERT(coffee != empty);

On Monday, 25 August 2003, at 19:08PM, Haesu wrote:

You ARE correct. If everyone employs IRR and put explicit filters everywhere, it'd be the perfect world..

... if everybody used the IRR to build explicit filters everywhere, if everybody kept their objects in the IRR up-to-date, and if there was some appropriate authorisation scheme in place to allow you to trust the data in the IRR implicitly, it'd be a perfect world. The IRR is currently a reasonable tool to use to avoid listening to routes which are advertised by mistake from peers who populate the IRR accurately. It's not a reasonable tool for avoiding maliciously bogus routes, since sticking maliciously bogus information in the IRR is trivial. Joe

On Monday, August 25, 2003, at 07:32 PM, Jared Mauch wrote:

You of course are correct with the trusting of the data, but we are in a somewhat of a chicken and egg situation. If people don't trust the IRR, they don't filter on it, and then the data is allowed to get out of date. But people who maliciously add bogus (or excessive route objects for example) are easy to track down. This is what the maintainer objects are for and why the IRR software keeps logs of the messages (including headers) that are submitted.

I fully agree with the cart/horse chicken/egg analogy. If SPs began employing IRRs more fully and more work went into commercialization of IRR infrastructure and tools (and perhaps some RIR feedback loop were created) they'd improve. Instead, folks are running about designing new protocols far more complex than BGP already is, that *still* require some "authority". When in reality, 99% of the vulnerabilities could have been solved with what was in place 10 years ago. Folks are striving for "perfect security", which is fine, but they've ignored the reasons why we don't even have "crappy" security. -danny

In a message written on Mon, Aug 25, 2003 at 04:22:24PM -0600, Danny McPherson wrote:

If folks want to filter, please, please, PLEASE, employ IRR infrastructure and filter customers *AND* peers explicitly. If your vendors have issues with this, push them to fix it. Then you don't have to worry about bogons, max-prefixes, route hijacking, de-aggregation, or... [snip] Is it really that hard?

Yes, it is that hard. Sadly, almost everyone I see push the IRR works for a small ISP. And at least half of those work for a small ISP in Europe. The fundamental problem with the "IRR Everywhere" notion is simple. If everyone filtered everyone, then, drum roll please: Every ISP on the planet would have to reconfigure their filters for /EVERY/ customer change worldwide. Now, you can pontificate all you want about the things that would be better if you could filter every session, but the problems are going to be quite similar to the problems of scaling BGP. BGP gets the routes to where they need to go today. Any filtering system is going to move roughly the same data, and needs to move it roughly as quick (surely you don't think customers are going to wait three days for their internet access to work, do you?). Just as we've had to do with BGP over the years, that's going to mean other built in safeguards a la dampening on the IRR infrastructure. Plus of course, the IRR is actually /FAR WORSE/ than BGP. Why? Well, with BGP there may be 20 possible routes between you and the destination, however only the best is in everyone's tables, with most of the backup routes "pruned" near the "edge" of the routing domain. However with filters that doesn't work. If I can hear a route from two providers I have to put it in both provider's filter lists all the time, or else when it fails and BGP switches over I'll reject the route, which is no good. While filtering is very important on the customer edge, it breaks down for the same reasons when you talk about provider to provider filtering. If UUNet can't trust Sprint to send it good, valid routes on the average there is a much deeper problem than filtering will ever solve. In a message written on Tue, Aug 26, 2003 at 03:13:11AM +0100, Ian Mason wrote:

The trick is for IXPs and NAPs to have terms that *require* people to:- 1) put their routes in an IRR 2) keep them accurate

The LINX in London does (1) as a joining requirement and contractual obligation, and applies pressure where (2) cause a problem. How many others follow similar practices?

I'm going to pick on this example. The LINX is interesting in that it is one of the most successful public fabrics worldwide. That cannot be denied. There own statistics https://stats.linx.net/cgi-pub/combined?log=combined.bits show about 23 Gig of traffic moves through there on a daily basis. That said, the LINX is a drop in the bucket. Top ISP's have individual customers with 10 Gig contracts. Public peering in total is non-interesting to backbone providers, which is why so many of them don't do it. To put this in perspective my own employer, AboveNet, who's agressive on public peering as large ISP's go does more traffic to our single largest peer than we do across all the public exchanges worldwide combined. Even if IXP's and NAP's were able to ensure 100% filtering of the public participants it wouldn't make a measurable difference in the global internet. Indeed, I suspect it would only serve to drive more medium sized player away from exchange points and to private interconnects with only the largest players. Almost everyone filters customers. The large ISP's all have the same opinion, if small to medium sized players abuse the system they get depeered and become someone's customer aggressively filtered. The large ISP's then trust each other to do that aggressive filtering. So be careful if you advocate filtering. The IRR, with everyone doing an update for every customer worldwide does not scale, but depeering all the smaller peers and letting a few big guys sort it out does. I don't think that's the result most people pushing filtering want. -- Leo Bicknell - bicknell@ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - tmbg-list-request@tmbg.org, www.tmbg.org

On Tue, Aug 26, 2003 at 09:35:57AM -0400, Leo Bicknell wrote:

In a message written on Mon, Aug 25, 2003 at 04:22:24PM -0600, Danny McPherson wrote:

...

If folks want to filter, please, please, PLEASE, employ IRR infrastructure and filter customers *AND* peers explicitly. If your vendors have issues with this, push them to fix it. Then you don't have to worry about bogons, max-prefixes, route hijacking, de-aggregation, or... [snip] Is it really that hard?

Yes, it is that hard. Sadly, almost everyone I see push the IRR works for a small ISP. And at least half of those work for a small ISP in Europe.

C&W, Level3, Global Crossing and NTT/Verio are small isps? http://infopage.cary.cw.net/Routing_Registry/mainpage.html http://info.us.bb.verio.net/routing.html#VRR http://www.irr.net/docs/list.html#LEVEL3 http://www.irr.net/docs/list.html#FGC (you need to replace gctr.net with gblx.net) I'm not able to give you the skitter related metric for the "core of the internet" as i'm getting connref from http://as-rank.caida.org/cgi-bin/main.pl but please do review it and comb the rest of the list at irr.net to get an idea of how much of the internet actually is doing this and then think about if you're in the majority or the minority.

The fundamental problem with the "IRR Everywhere" notion is simple. If everyone filtered everyone, then, drum roll please:

Every ISP on the planet would have to reconfigure their filters for /EVERY/ customer change worldwide.

Exactly. And this is a bad thing how? You can't plan ahead and register route objects 24 hours in advance of a customer being installed?

Now, you can pontificate all you want about the things that would be better if you could filter every session, but the problems are going to be quite similar to the problems of scaling BGP. BGP gets the routes to where they need to go today. Any filtering system is going to move roughly the same data, and needs to move it roughly as quick (surely you don't think customers are going to wait three days for their internet access to work, do you?). Just as we've had to do with BGP over the years, that's going to mean other built in safeguards a la dampening on the IRR infrastructure.

Plus of course, the IRR is actually /FAR WORSE/ than BGP. Why? Well, with BGP there may be 20 possible routes between you and the destination, however only the best is in everyone's tables, with most of the backup routes "pruned" near the "edge" of the routing domain. However with filters that doesn't work. If I can hear a route from two providers I have to put it in both provider's filter lists all the time, or else when it fails and BGP switches over I'll reject the route, which is no good.

If you misuse the IRR data as you state here, yeah, your network will break. Same thing will happen if you do other bad things in configuring your network policy. This is why network operations are not for those armchair geeks, you can easily cause significant unexpected problems as it relates to this.

While filtering is very important on the customer edge, it breaks down for the same reasons when you talk about provider to provider filtering. If UUNet can't trust Sprint to send it good, valid routes on the average there is a much deeper problem than filtering will ever solve.

Yeah, but that's not what we're attempting to discuss here, we're asking what hurdles (that are not self-errected due to improper policy decisions) that honestly are preventing you from deploying irr type filtering. (or that's what I think danny was trying to ask yesterday)

In a message written on Tue, Aug 26, 2003 at 03:13:11AM +0100, Ian Mason wrote:

...

The trick is for IXPs and NAPs to have terms that *require* people to:- 1) put their routes in an IRR 2) keep them accurate

The LINX in London does (1) as a joining requirement and contractual obligation, and applies pressure where (2) cause a problem. How many others follow similar practices?

I'm going to pick on this example. The LINX is interesting in that it is one of the most successful public fabrics worldwide. That cannot be denied. There own statistics

https://stats.linx.net/cgi-pub/combined?log=combined.bits

show about 23 Gig of traffic moves through there on a daily basis.

That said, the LINX is a drop in the bucket. Top ISP's have individual customers with 10 Gig contracts. Public peering in total is non-interesting to backbone providers, which is why so many of them don't do it. To put this in perspective my own employer, AboveNet, who's agressive on public peering as large ISP's go does more traffic to our single largest peer than we do across all the public exchanges worldwide combined.

Even if IXP's and NAP's were able to ensure 100% filtering of the public participants it wouldn't make a measurable difference in the global internet. Indeed, I suspect it would only serve to drive more medium sized player away from exchange points and to private interconnects with only the largest players.

Hmm.. you are missing some of the benifits that I see associated with this. If I have a list of all the prefixes that I could get sourced from MFN/above.net in a easily queryable format, I can install anti-spoofing filters. There are also other uses for this data. you could build max-prefix numbers off of the irr data (for example). - jared -- Jared Mauch | pgp key available via finger from jared@puck.nether.net clue++; | http://puck.nether.net/~jared/ My statements are only mine.

On Tue, Aug 26, 2003 at 10:10:57AM -0400, Leo Bicknell wrote:

In a message written on Tue, Aug 26, 2003 at 09:55:30AM -0400, Jared Mauch wrote:

...

...

Yes, it is that hard. Sadly, almost everyone I see push the IRR works for a small ISP. And at least half of those work for a small ISP in Europe.

C&W, Level3, Global Crossing and NTT/Verio are small isps?

Please correct me if I'm wrong, but they all use the IRR to filter customers. That's a fine application of the IRR, and one I encourage. I don't think any of them use the IRR to filter peers. Indeed, I can provde they don't filter certian big peers due to the fact they don't register thier routes at all. :)

I'd have to imagine all those proxy registered routes for sprint prefixes that you see in the LEVEL3 rr are used for something other than consuming disk space.

My rant is on peer-to-peer filtering. Customers should always be filtered by every ISP. Period. ISP's should automate that as much as possible for their customers, and using the IRR is a fine solution.

...

...

Every ISP on the planet would have to reconfigure their filters for /EVERY/ customer change worldwide.

Exactly. And this is a bad thing how? You can't plan ahead and register route objects 24 hours in advance of a customer being installed?

It's a bad thing because it doesn't scale. It's not a matter of before or not, it's that there is a linear relationship between the size of the internet and the processing needed to be done by each ISP. That doesn't scale.

...

Hmm.. you are missing some of the benifits that I see associated with this. If I have a list of all the prefixes that I could get sourced from MFN/above.net in a easily queryable format, I can install anti-spoofing filters.

No, you couldn't. Please go back and take routing 101 again.

Yes I could, if you and your customers had all the routes they sourced packest from registered. This has nothing to do with routing 101, this has to do with filtering customers and having anti-spoofing filters as well as route objects for any prefix you will source packets from.

Internet routing is asymetrical, the source of the packet has nothing to do with where the return route points in the core. If it were that simple we could just use Unicast RPF on all peering links and spoofing would be a thing of the past.

Actually, it sounds like you're not that clued on how Juniper handles unicast-rpf at all (for example). It allows you to do unicast-rpf on a per-interface basis for all routes that you receive regardless of if they're installed for forwarding. this means that people could use this and set the necessary community so it doesn't leave the peer router (no-export + no-advertise), or prepended so much it's not used and use that to perform filtering. If best-path for returning the packet is not across the link, it will still not drop this. This is a nice feature on the part of Juniper. http://www.juniper.net/techpubs/software/junos/junos60/swconfig60-interfaces... I suggest you (and others) take a look at these features and use them where possible to mitigate spoofed DoS attacks from your network. - jared -- Jared Mauch | pgp key available via finger from jared@puck.nether.net clue++; | http://puck.nether.net/~jared/ My statements are only mine.

On Tue, 26 Aug 2003, Leo Bicknell wrote:

In a message written on Tue, Aug 26, 2003 at 10:43:00AM -0400, Jared Mauch wrote:

...

Yes I could, if you and your customers had all the routes they sourced packest from registered. This has nothing to do with routing 101, this has to do with filtering customers and having anti-spoofing filters as well as route objects for any prefix you will source packets from.

___T1 to Verio, With BGP____Verio______ / \ Customer UUnet \ / ---T1 to Sprint, No BGP-----Sprint-----

Now, the customer, over their two T1 transit circuits does the following:

as-path access-list 1 deny .*

neighbor verio filter-list 1 in

ip route 0.0.0.0 0.0.0.0 sprint

Should the customer have to register a route with Sprint to make this work? How does UUNet, who only received a route from Verio, know incoming packets from Sprint aren't spoofed? Note also, even if these cases are in the IRR, UUNet's filter for Sprint will be larger than the number of routes currently received, since there is no route for this prefix that needs to be in the filter.

[Note, I don't suggest this configuration is common or useful on its own, but rather it's a simple enough case it can be used for discussion in e-mail.]

Hmm this isnt a real world scenario tho.. if you multihome there should be BGP on both paths.. In the example above Sprint arent accepting or sourcing a route so there is no issue on routes being passed into Sprint or UUNET and we're talking here about spoofing of routes not packets Steve

Someone on this list had mentioned a network card for the Max TNT that made it immune to the nachia worm ping issue. Is that the 4 port (3 ethernet, 1 fast ether) card or the single port card with the dongle thing or something else? Has anyone seen a fix from Lucent yet? (besides the filters that have been posted) Geo.

Once upon a time, Geo. <georger@getinfo.net> said:

Has anyone seen a fix from Lucent yet? (besides the filters that have been posted)

Based on suggestions here, I have limited the size of the TNT route cache on our affected TNTs and that seems to have fixed the problem. read ip-glob set iproute-cache-size = 50 wr -- Chris Adams <cmadams@hiwaay.net> Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble.

On Tue, Aug 26, 2003 at 11:29:17AM -0400, Matt Levine wrote:

In a real world scenario, I bumped into Verio's RPF peer filters yesterday.

Due to the large outage at 200 paul, the /19 that one of my /24's is out of went away. Obviously due to prefix filtering policies, verio didn't have my /24. I had several people complain who were multihomed, and did have the /24 from their other carrier(s). Unfortunately, my best path to these customers was via verio, who's rpf promptly blocked my return traffic :(

Speaking about this specific issue, since there was no return path in our RIB/FIB, we dropped the packets, yes. If you were annoucing the /19 or something that fit our filtering policy (in your alternate locations) you would not have had issues. - Jared -- Jared Mauch | pgp key available via finger from jared@puck.nether.net clue++; | http://puck.nether.net/~jared/ My statements are only mine.

During my tenure at a medium-sized ISP, I found that one of the more painful experiences was trying to assist small or first-time BGP customers in setting themselves up in the IRR and registering their routes. While I would take issue with some posters' comments that maintaining edge filters does not scale, I would certainly support the statement that providing IRR 101 tutorials definitely doesn't scale. For smaller sites, I feel that explicit permit prefix filters are the way to go. At the same time a filter is updated, if the customer was assigned space from one of our blocks, off go both a SWIP and a proxy IRR object. If the space is PA space from another provider, we'd submit a route object after verifying the assignment. In the case of PI space, we *might* take the trouble to give the IRR 101 training if the customer seemed trainable. Somewhere in the growth curve along which a customer increases in both size and credibility, I think there is a case for migrating them from prefix filtering to as-path filtering with a prefix limit. While not preventing any possibility of an illegitimate announcement, it does prevent a 7007 type incident along with scalability.

On Tue, Aug 26, 2003 at 10:10:57AM -0400, Leo Bicknell wrote:

In a message written on Tue, Aug 26, 2003 at 09:55:30AM -0400, Jared Mauch wrote:

...

...

Yes, it is that hard. Sadly, almost everyone I see push the IRR works for a small ISP. And at least half of those work for a small ISP in Europe.

C&W, Level3, Global Crossing and NTT/Verio are small isps?

Please correct me if I'm wrong, but they all use the IRR to filter customers. That's a fine application of the IRR, and one I encourage. I don't think any of them use the IRR to filter peers. Indeed, I can provde they don't filter certian big peers due to the fact they don't register thier routes at all. :)

Global Crossing doesn't use the IRR to filter their BGP speaking customers, every prefix-list update gets touched by a human. While their response time is good, and they're generally friendly people, they do have a tendancy to prove that they are human by forgetting or typoing a random route with nearly every other update. When you start getting into the hundreds of routes, personally I will go through the trouble to maintain IRR entries any day vs letting humans break stuff. -- Richard A Steenbergen <ras@e-gerbil.net> http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)

--On Tuesday, August 26, 2003 9:35 AM -0400 Leo Bicknell <bicknell@ufp.org> wrote:

Almost everyone filters customers. The large ISP's all have the same opinion, if small to medium sized players abuse the system they get depeered and become someone's customer aggressively filtered. The large ISP's then trust each other to do that aggressive filtering. So be careful if you advocate filtering. The IRR, with everyone doing an update for every customer worldwide does not scale, but depeering all the smaller peers and letting a few big guys sort it out does. I don't think that's the result most people pushing filtering want.

If this is true, then why do the european NAP mailing lists (which push IRR filtering) have an almost constant stream of "oops, our customer announced everything to us and we leaked it". Filtering peers is not the way to go. Filtering customers and "trusting" peers to do the same is. (Whether that trust explictly mentioned in a peering agreement or whatever). Just a shame that not everyone filters their customers. And although it has been a while, I know I've seen a route-leak from 6461 at AMS-IX. (Probably last year sometime)

--On Wednesday, August 27, 2003 9:36 AM -0400 Leo Bicknell <bicknell@ufp.org> wrote:

In a message written on Wed, Aug 27, 2003 at 12:15:18AM -0400, John Payne wrote:

...

If this is true, then why do the european NAP mailing lists (which push IRR filtering) have an almost constant stream of "oops, our customer announced everything to us and we leaked it".

Because European naps have more smaller and clueless players. I know more than a few people (because they ask for peering) who have an IRR entry that is 1 prefix for the "ISP", and 1 prefix for their only BGP customer. It should be of no surprise they get that customer configured wrong. It should also be of no surprise that most of the real ISP's would never consider peering with those types of networks.

CAIS (or whatever they're called today - BtNAccess/PCCW) is a small and clueless player? Then why is 6461 peering with 3491? (yeah, that was a customer route leak in July. I tend to just delete such emails, but I'd be surprised if there weren't more in August from ISPs that don't fit into "small and clueless") Not everyone filters their customers, and saying that everyone that counts does doesn't make it so.

6461 filters all customers by prefix list. Note too, filtering customers does not eliminate route leaks, it just removes the most obvious and often cause.

Really? So how was I able to advertise a new netblock to one of your customers just now and see 6461 <their AS> <my AS> on route-views.oregon-ix.net within 2 minutes and without telling a soul what I was doing? You must have some pretty broad prefix lists. (And no, it doesn't make me happy that I was able to do this... there are 2 places that are missing filters in that path). At least I *think* that they are your customer, if not, then you're leaking routes to Sprint and opentransit and telia amongst other places.

--On Tuesday, August 26, 2003 9:35 AM -0400 Leo Bicknell <bicknell@ufp.org> wrote:

...

Almost everyone filters customers. The large ISP's all have the same opinion, if small to medium sized players abuse the system I wish this was true but it is not!!!

From above everything starting with 11 was faked and once this was realized Qwest security was notified and they even said the ip block will be filtered and indeed it was for 1 day!!! But appearently they just started advertising smaller 138.252.0.0/21 ip block from exactly same Qwest POP in Burbank, CA but with new faked traceroute:

In particular I call your attention to Qwest. Their customer in LA with AS29809 was announcing ip block 138.252.0.0/16, which is hijacked ip block, see details at http://www.completewhois.com/hijacked/files/138.252.0.0.txt It took us a little time to find out who to report it to because amount of abuse was small and all traceroutes were faked, here is part of it as it was several days ago: 8 204.255.169.138 (204.255.169.138) 33.299 ms 28.885 ms 30.188 ms 9 bur-core-01.inet.qwest.net (205.171.13.9) 35.992 ms 28.280 ms 10 bux-edge-01.inet.qwest.net (205.171.13.174) 32.468 ms 30.766 ms 11 tbr1-p012201.la2ca.ip.att.net (12.123.28.130) 40.104 ms <-- Faked here 12 gbr4-p20.sffca.ip.att.net (12.122.2.69) 51.680 ms 52.195 ms 50.259 13 gbr6-p70.sffca.ip.att.net (12.122.5.153) 62.751 ms 61.256 ms 14 ar2-p3110.sfcca.ip.att.net (12.123.195.81) 71.827 ms 71.376 ms 15 12.119.200.38 (12.119.200.38) 83.024 ms 82.612 ms 82.004 ms 16 203.148.164.170 (203.148.164.170) 89.747 ms 92.942 ms 87.614 ms 17 203.148.164.228 (203.148.164.228) 103.087 ms 99.536 ms 99.910 ms 18 svoa-bkk.a-net.net.th (203.148.200.145) 1104.594 ms 1098.491 ms 19 138.252.0.1 (138.252.0.1) 33.634 ms 33.220 ms 32.514 ms" And that is when "sh ip bgp" was showing: 8001 7911 209 29809 6395 1239 209 29809 5650 1239 209 29809 traceroute to 138.252.0.10 (138.252.0.10), 30 hops max, 38 byte packets ... 5 qwest.sjc03.atlas.psi.net (154.54.10.154) 1.988 ms 1.264 ms 1.243 ms 6 svl-core-01.inet.qwest.net (20r.171.214.41) 2.526 ms 2.229 ms 2.383 ms 7 sbur-core-02.inet.qwest.net (205.171.5.217) 9.491 ms 9.519 ms 9.494 ms 8 bux-edge-01.inet.qwest.net (205.171.13.178) 9.514 ms 9.860 ms 9.467 ms 9 * * * 10 obl-rou-1003.NL.eurorings.net (134.222.229.238) 22.436 ms 18.489 ms 11 ffm-s1-rou-1002.DE.eurorings.net (134.222.230.30) 40.087 ms 47.130 12 ksrh-s1-rou-1071.DE.eurorings.net (134.222.227.86) 39.634 ms 38.361 13 ksrh-s1-rou-1072.DE.eurorings.net (134.222.227.74) 40.083 ms 42.067 14 r1-ka.strato.cust.eurorings.net (134.222.102.18) 39.853 ms 39.022 ms 15 81.169.144.22 (81.169.144.22) 39.770 ms 43.874 ms 39.956 ms 16 81.169.144.38 (81.169.144.38) 60.088 ms 59.179 ms 60.091 ms 17 lb1.webmailer.de (192.67.198.246) 70.123 ms 76.9934ms 69.991 ms router#sh ip bgp 138.252.0.1 BGP routing table entry for 138.252.0.0/21, version 10503636 Paths: (2 available, best #1, not advertised outside local AS) 16631 174 209 29809 216.151.223.17 (metric 65) from 216.151.223.17 Origin IGP, metric 1000000, localpref 100, weight 500, valid, internal, best Community: 16631:1000 local-AS 6347 701 209 29809 209.144.160.89 from 209.144.160.89 (209.83.159.23) Origin IGP, localpref 100, weight 10, valid, external Community: 6347:1023 6347:5000 6347:5001 local-AS I'm pretty sure Qwest is doing something wrong by allowing such an open BGP annoncements from their customers without checking what they would be announcing. Instead of putting filters as "allow all" and then adding filtering only 138.252.0.0/16 when they were contacted, they instead should have filtered all announcement except for specific ones customer asked and was authorized. And I do hope there is somebody from Qwest here who can deal with this issue and educate on proper filtering whoever is responsible for their bgp router in Burbank. Also as for this particular case, I'll strongly advise to just filter AS29809 entirely, I have serious doubts about whoever controls this asn and have done the research on it (see above referenced file) and it appears the addresses at ARIN are all wrong (I have some doubts about Trimeda being located on the grounds of Mormon Temple for example...) and has been recently changed from completely different set of addresses and besides it would have been enough that AS29809 only advertises this particular hijacked ip block (and nothing else!) and they on purpose fake traceroute to their AS to move blame away from themselve.

Just a shame that not everyone filters their customers. And although it has been a while, I know I've seen a route-leak from 6461 at AMS-IX. (Probably last year sometime)

Indeed it really is a shame, especially when its large players like Qwest who do not filter their customers, how can you expect it from smaller European networks where peering seems is a lot easier to setup... -- William Leibzon Elan Networks william@elan.net

On Mon, 25 Aug 2003, Joe Abley wrote:

On Monday, 25 August 2003, at 19:08PM, Haesu wrote:

...

You ARE correct. If everyone employs IRR and put explicit filters everywhere, it'd be the perfect world..

The IRR is currently a reasonable tool to use to avoid listening to routes which are advertised by mistake from peers who populate the IRR accurately. It's not a reasonable tool for avoiding maliciously bogus routes, since sticking maliciously bogus information in the IRR is trivial.

Maybe, however you can fix that.. RIPE for example uses hierarchical authorisation so you cant add a route on a block you are not allocated, the broken part here is that the non-European IRRs are not run by the registry and therefore accept anything.. Steve

That is true, although distributed route-servers that serve specific region may be easier dealing with emergencies (i.e. local POP(s) having emergency situation etc) -hc -- Sincerely, Haesu C. TowardEX Technologies, Inc. WWW: http://www.towardex.com E-mail: haesu@towardex.com Cell: (978) 394-2867 On Tue, Aug 26, 2003 at 12:36:09PM -0400, Edward Lewis wrote:

At 19:08 -0400 8/25/03, Haesu wrote:

...

Managing a filter list on one or a few route-servers rather than an AS with hundred edge routers is so much time saving and less humanerror-prone.

But balance that with keep the path from filter list to route-server short too - because if you need to adjust a filter list in response to a network (or utility) emergency, you want to make sure the data is available.

(Based on experience with a project researching DDOS response. We relied on certificates distributed by a DNS server. When the flood was released, accessing DNS became impossible - the security system drowned in the flood.) -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer

Sponge Bob Square Pants? I'm still trying to figure out the Macarena.

If folks want to filter, please, please, PLEASE, employ IRR infrastructure and filter customers *AND* peers explicitly. If your vendors have issues with this, push them to fix it. Then you don't have to worry about bogons, max-prefixes, route hijacking, de-aggregation, or...

Then we can worry about IRR infrastructure hardening and accuracy and derive explicit data plane filters from the output, as well as other tangible benefits.

Is it really that hard?

I can see not filtering peers if the hardware can't handle it, but there doesn't appear to be such a good excuse for not edge filtering. If Barry Green is listening out there, I'd be interested to hear how successful he and his team have been at convincing ISPs to do this. I know he's been on his ISP Security Best Practices world tour for quite a while now, and am curious if he's found it more difficult to get edge filtering implemented vs. other security measures (and if so, why) or if it's just security in general that's difficult to get ISPs to do. Also, are recommendations given for how edge filters should be maintained? This was discussed here a short while ago but I don't think a broad consensus was reached. The mere existence of the filters is nice to prevent AS7007-like incidents but does little to prevent other bad things such as address hijacking if the customer (or someone posing as the customer?) can call the ISP and get holes punched in a filter for address blocks that he/she has no business announcing. It seems that a common practice amongst ISPs who do filter on the edge is to blindly punch holes in these filters when asked without somehow "validating" the request. Does this negate a significant portion of the advantages gained by edge filtering or are we primarily concerned with accidental/malicious route table leaking at this point? -Terry