Hi, folks. For a while folks have asked me to add an aggregated ACL, prefix-list, or black hole routes to the various templates on my site. I've avoided this for a variety of reasons, and decided to create the best of all worlds - the bogon list. :) This list includes the bogons, in both aggregated and non-aggregated form. The list includes bit notation, dotted decimal, and Cisco ACL styles. This is handy for blocking the bogons, egress and ingress, at your borders. Take a peek at it here: http://www.cymru.com/Documents/bogon-list.html Comments and feedback are VERY welcome! Be the first in your ASN to join the CREDITS section. :) Thanks! Rob. -- Rob Thomas http://www.cymru.com ASSERT(coffee != empty);
On Tue, Jun 04, 2002 at 10:30:33AM -0500, Rob Thomas wrote:
For a while folks have asked me to add an aggregated ACL, prefix-list, or black hole routes to the various templates on my site. I've avoided this for a variety of reasons, and decided to create the best of all worlds - the bogon list. :)
This list includes the bogons, in both aggregated and non-aggregated form. The list includes bit notation, dotted decimal, and Cisco ACL styles. This is handy for blocking the bogons, egress and ingress, at your borders. Take a peek at it here:
http://www.cymru.com/Documents/bogon-list.html
Comments and feedback are VERY welcome! Be the first in your ASN to join the CREDITS section. :)
The problem with bogon lists is that they change on a fairly regular basis, for example each time a registry is given a new /8 to allocate from. This makes the role of maintaining an "offical" list of bogons somewhat important, and the job of updating them somewhat annoying. :) But, most of your list looks like RFC1918, link-local, and the /8's that havn't been allocated. This is pretty simple to obtain, but not very comprehensive. Off hand just in the reserved section, I see missing: 128.0.0.0/16 191.255.0.0/16 192.0.0.0/17 And probably lots more if you go mine the database (and assuming you're willing to make a committment for life to continue watching the database for when they stop being reserved :P). Then we come to the extra bogons like exchange point allocations. Can't forget them. :) I'd suggest you try to work on a database of the bogons with various flags so people can make their own policy decisions. For example, I would agree with filtering all of these from my routing table, but not with filtering RFC1918 space or exchange point routes (at least not on the border device connecting to it :P) from source addresses. -- Richard A Steenbergen <ras@e-gerbil.net> http://www.e-gerbil.net/ras PGP Key ID: 0x138EA177 (67 29 D7 BC E8 18 3E DA B2 46 B3 D8 14 36 FE B6)
On Tuesday, June 4, 2002, at 12:48 , Barry Raveendran Greene wrote:
Then we come to the extra bogons like exchange point allocations. Can't forget them. :)
I've never heard anyone refer to the IXP allocations as "bogons." Plus, I've not heard of anyone filtering the IXP prefixes on their ingress peering filters. Egress peering filters - yes.
Depending on your internal routing policy, it may well be important not to learn routes to exchange points to which you connect. A straightforward example is when people accidentally propagate the prefixes 195.66.224.0/24 and 195.66.225.0/24. Interfaces on the LINX exchange fabric are currently numbered within 195.66.224.0/23, so if my LINX router learns the longer prefix routes from somewhere else, my EBGP sessions across the exchange get hijacked. Without the prefix length aspect the effect is less obviously serious, but it can still cause issues. Subnets numbering interfaces on exchange point subnets, for exchange points at which I participate, can hence generally be considered bogonish by me. For exchange points at which I do not participate this need not be the case. The list of EP-derived bogons is, following this logic, operator-specific. Joe
I agree with Joe on this. At one time we were filtering 198.32/16 from our peers but ran into things like ep.net (198.32.6.31) breaking. We now only filter on IXP blocks for which we participate. While on the subject of IXP blocks, we also ended up redistributing the IXP blocks and sending them to our BGP customers (who do not receive a default) so that traceroutes and such from Looking Glasses do not break. They can then choose to filter them as they wish. -Dave Joe Abley wrote:
On Tuesday, June 4, 2002, at 12:48 , Barry Raveendran Greene wrote:
Then we come to the extra bogons like exchange point allocations. Can't forget them. :)
I've never heard anyone refer to the IXP allocations as "bogons." Plus, I've not heard of anyone filtering the IXP prefixes on their ingress peering filters. Egress peering filters - yes.
Depending on your internal routing policy, it may well be important not to learn routes to exchange points to which you connect.
A straightforward example is when people accidentally propagate the prefixes 195.66.224.0/24 and 195.66.225.0/24. Interfaces on the LINX exchange fabric are currently numbered within 195.66.224.0/23, so if my LINX router learns the longer prefix routes from somewhere else, my EBGP sessions across the exchange get hijacked. Without the prefix length aspect the effect is less obviously serious, but it can still cause issues.
Subnets numbering interfaces on exchange point subnets, for exchange points at which I participate, can hence generally be considered bogonish by me. For exchange points at which I do not participate this need not be the case. The list of EP-derived bogons is, following this logic, operator-specific.
Joe
On Tue, Jun 04, 2002 at 11:04:40AM -0700, David McGaugh wrote:
I agree with Joe on this. At one time we were filtering 198.32/16 from our peers but ran into things like ep.net (198.32.6.31) breaking. We now only filter on IXP blocks for which we participate.
While on the subject of IXP blocks, we also ended up redistributing the IXP blocks and sending them to our BGP customers (who do not receive a default) so that traceroutes and such from Looking Glasses do not break. They can then choose to filter them as they wish.
Exchange point blocks SHOULDN'T be transited by anyone, therefore you should not hear them from your peers. -- Richard A Steenbergen <ras@e-gerbil.net> http://www.e-gerbil.net/ras PGP Key ID: 0x138EA177 (67 29 D7 BC E8 18 3E DA B2 46 B3 D8 14 36 FE B6)
On Tuesday, June 4, 2002, at 03:47 , Richard A Steenbergen wrote:
Exchange point blocks SHOULDN'T be transited by anyone, therefore you should not hear them from your peers.
Unless an exchange point includes such a restriction in the agreements with their participants, isn't this a private matter between a transit provider and their transit customers? If the customers want to see the prefixes, and the transit provider's not breaching any agreements by sending them, why not send them? Messy traceroutes make the helpdesk phone ring. Joe
On Tue, Jun 04, 2002 at 04:17:04PM -0400, Joe Abley wrote:
On Tuesday, June 4, 2002, at 03:47 , Richard A Steenbergen wrote:
Exchange point blocks SHOULDN'T be transited by anyone, therefore you should not hear them from your peers.
[snip]
Messy traceroutes make the helpdesk phone ring.
How does the absence of an IXP route affect traceroutes -through- it? The IXP device has a route back to the source of the trace, so it can reply. The traceroute packets are addressed to the ultimate destination, so they don't need the IXP route. -c
On Tue, Jun 04, 2002 at 01:24:04PM -0700, Clayton Fiske wrote:
How does the absence of an IXP route affect traceroutes -through- it? The IXP device has a route back to the source of the trace, so it can reply. The traceroute packets are addressed to the ultimate destination, so they don't need the IXP route.
Quite a few GUI traceroute products expect to be able to ping each hop, and produce statistics based on that...definitely a bad approach, particularly utilizing ICMP, but that's the common practice. I cannot count the number of tickets I've seen opened because someone didn't know how to properly interpret traceroute data. --msa
On Tue, Jun 04, 2002 at 11:04:40AM -0700, David McGaugh wrote:
I agree with Joe on this. At one time we were filtering 198.32/16 from our peers but ran into things like ep.net (198.32.6.31) breaking. We now only filter on IXP blocks for which we participate.
While on the subject of IXP blocks, we also ended up redistributing the IXP blocks and sending them to our BGP customers (who do not receive a default) so that traceroutes and such from Looking Glasses do not break. They can then choose to filter them as they wish.
Exchange point blocks SHOULDN'T be transited by anyone, therefore you should not hear them from your peers.
Agreed. But these are the IXP micro allocations - not "bogons." How you filter the IXP blocks depends on each ISP and the IXP contracts. So that would be something you would add to Rob's template.
In a message written on Tue, Jun 04, 2002 at 03:47:00PM -0400, Richard A Steenbergen wrote:
Exchange point blocks SHOULDN'T be transited by anyone, therefore you should not hear them from your peers.
I would say this the other way around, all exchange point blocks should be transited by someone. Back in the day, things like the mae-east FDDI were originated by a half dozen AS's. Why? If you had "full routes", but didn't connect to the mae, you could traceroute but not ping it, and things of that nature. It confused people. Of course, the inconsistent announcements were also an issue. The right thing is for each exchange point to be announced by one AS. I'm not sure if I favor having one AS per exchange, or one AS for all exchanges, but the point is the same. The AS should announce the route. The AS should get transit (possibly over the exchange) from one or more players. The exchange operator should run the box "announcing" the exchange. -- 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, Jun 04, 2002 at 04:47:51PM -0400, Leo Bicknell wrote:
In a message written on Tue, Jun 04, 2002 at 03:47:00PM -0400, Richard A Steenbergen wrote:
Exchange point blocks SHOULDN'T be transited by anyone, therefore you should not hear them from your peers.
I would say this the other way around, all exchange point blocks should be transited by someone.
Back in the day, things like the mae-east FDDI were originated by a half dozen AS's. Why? If you had "full routes", but didn't connect to the mae, you could traceroute but not ping it, and things of that nature. It confused people. Of course, the inconsistent announcements were also an issue.
Am I right that I don't see a reason why IX blocks should be transited other than traceroute should work? I can think of a couple of reasons why the blocks SHOULDN'T be transitted by anyone. Adi
as peers do not give eachother transit, you don't need to announce the IX to eachother to get traceroute to work. you just carry it in your own network. randy
On Tue, Jun 04, 2002 at 02:02:36PM -0700, Randy Bush wrote:
as peers do not give eachother transit, you don't need to announce the IX to eachother to get traceroute to work. you just carry it in your own network.
Weren't they talking about customers at a "downstream" ISPs which don't connect directly to the exchange? Adi
as peers do not give eachother transit, you don't need to announce the IX to eachother to get traceroute to work. you just carry it in your own network. Weren't they talking about customers at a "downstream" ISPs which don't connect directly to the exchange?
one gives transit customers the IX route. just don't give it to or accept it from peers. randy
We announce the IXP blocks to customers and not peers for IXs which we participate. Additionally we don't filter our peers if they were to announce an IXP block so long as it is not an IXP block for an IX which we participate. (grammar?) This way we can continue to learn routes for things like l.root-servers.net and www.ep.net. -Dave Aditya wrote:
On Tue, Jun 04, 2002 at 02:02:36PM -0700, Randy Bush wrote:
as peers do not give eachother transit, you don't need to announce the IX to eachother to get traceroute to work. you just carry it in your own network.
Weren't they talking about customers at a "downstream" ISPs which don't connect directly to the exchange?
Adi
In a message written on Tue, Jun 04, 2002 at 01:54:07PM -0700, Aditya wrote:
Am I right that I don't see a reason why IX blocks should be transited other than traceroute should work? I can think of a couple of reasons why the blocks SHOULDN'T be transitted by anyone.
Traceroute to www.foo.com, see it goes through an exchange. Ping the router on the far end of the exchange, "host unreachable". Traceroute to it, "host unreachable" at the first default free router. Not only will this confuse your customers, but often first level support staff. Also, you buy service from your favorite default free network. They aren't present at an exchange. You want to traceroute/ping a host on that lan. You can't, unless someone tranists the exchange. So, I consider it important _ALL_ exchange lans get transit from one or more providers (preferably from their own AS). If you're not a transit provider, don't send it to peers. Regardless, filter all the exchanges you are present at on _all_ inbound BGP sessions. Only use your local route. -- 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, 4 Jun 2002, Richard A Steenbergen wrote:
Exchange point blocks SHOULDN'T be transited by anyone, therefore you should not hear them from your peers.
The combination of not having a globaly routable ixp-block and using (perhaps the non-cisco equivalent of) ip verify unicast reverse-path can brake pmtu discovery. Imagine a router sending a fragment-needed from its ixp-address to a client and a router inbetween discarding the packet because it doesn't have a route for it. -- Sabri Berisha "I route, therefore you are" ~ my own opinions etc ~ Join Megabit LAN in open air! http://www.megabit.nl
Then we come to the extra bogons like exchange point allocations. Can't forget them. :)
I've never heard anyone refer to the IXP allocations as "bogons." Plus, I've not heard of anyone filtering the IXP prefixes on their ingress peering filters. Egress peering filters - yes.
At some IX:es that is more or less a must.... Best regards, - kurtis -
Hi, Richard. ] The problem with bogon lists is that they change on a fairly regular ] basis, for example each time a registry is given a new /8 to allocate Actually no, they don't. That is the surprising part; the rate of change is quite low. Still, I have put in place code to ensure that my various documents (Secure [BGP|IOS|BIND] Template) do not black hole a legitimate network. :) ] And probably lots more if you go mine the database (and assuming you're ] willing to make a committment for life to continue watching the database ] for when they stop being reserved :P). I already have. My social life is proof of that. :) Thanks! Rob. -- Rob Thomas http://www.cymru.com ASSERT(coffee != empty);
The problem with bogon lists is that they change on a fairly regular basis, for example each time a registry is given a new /8 to allocate from. This makes the role of maintaining an "official" list of bogons somewhat important, and the job of updating them somewhat annoying. :)
Ingress peering filters have to be maintained. That comes with the territory. If you use Net Police filtering (i.e. explicit permit - only allow the RIR's blocks), you'll need to modify the list as the RIR's get new blocks allocated to them. If you use Bogon filtering (i.e. explicit deny - denying bogons and allowing everything else), you'll need to modify the list as the RIR's get new blocks allocated to them. Doing neither increases the risk of your network to BGP garbage attacks (i.e. incidents like the AS7007 fun). All Rob did is make it easier for those who do not like the Net Police filtering techniques. Now you have some templates to help get started with a bogon based ingress filter.
participants (12)
-
Aditya -
Barry Raveendran Greene -
Clayton Fiske -
David McGaugh -
Joe Abley -
Kurt Erik Lindqvist -
Leo Bicknell -
Majdi S. Abbas -
Randy Bush -
Richard A Steenbergen -
Rob Thomas -
Sabri Berisha