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.
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.
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.
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.
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.
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:
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
> 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
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.
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
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.
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
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:
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.