You should also create a bogons list for your BGP routes which you accept from your upstream. Block all RFC1918 space and unassigned public addresses too. Just keep on top of it when new allocations are put into use. We see all kinds of crazy things which people try to announce (and successfully too - up to our borders anyway.)
-Robert
Tellurian Networks - Global Hosting Solutions Since 1995 http://www.tellurian.com | 888-TELLURIAN | 973-300-9211
"Well done is better than well said." - Benjamin Franklin
We just maintain our own. I remember hearing about one a while ago, but we don't use it so I don't know any details.
-Robert
Tellurian Networks - Global Hosting Solutions Since 1995 http://www.tellurian.com | 888-TELLURIAN | 973-300-9211
"Well done is better than well said." - Benjamin Franklin
I'd strongly advise against folks doing it statically.. there seems to be ongoing issues with stale filters each time new address space is released. Even with the best of intentions folks change role or employer and things can get left unmanaged.
The craziest stuff that gets announced isnt in the reserved/unallocated realm anyway so the effort seems to be disproportional to the benefits... and most issues I read about with reserved space is packets coming FROM them not TO them....
You should also create a bogons list for your BGP routes which you
accept from your upstream. Block all RFC1918 space and unassigned
public addresses too. Just keep on top of it when new allocations
are put into use. We see all kinds of crazy things which people
try to announce (and successfully too - up to our borders anyway.)
Is there a somewhat-reliable bogon BGP feed that can be subscribed
to these days?
We just maintain our own. I remember hearing about one a while ago,
but we don't use it so I don't know any details.
I'd strongly advise against folks doing it statically.. there seems
to be ongoing issues with stale filters each time new address space
is released. Even with the best of intentions folks change role or
employer and things can get left unmanaged.
The craziest stuff that gets announced isnt in the
reserved/unallocated realm anyway so the effort seems to be
disproportional to the benefits... and most issues I read about with
reserved space is packets coming FROM them not TO them....
Steve's 100% spot-on here. I don't have bogon filters at all and it
hasn't hurt me in the least. I think the notion that this is somehow
a good practice needs to be quashed.
Some people don't use condoms with hookers either. Just because they
haven't caught anything yet doesn't make it a smart practice.
* rs@seastrom.com (Robert E. Seastrom) [Thu 09 Nov 2006, 16:02 CET]:
[..]
Steve's 100% spot-on here. I don't have bogon filters at all and it hasn't hurt me in the least. I think the notion that this is somehow a good practice needs to be quashed.
Yeah! This "Principle of minimal privilege" is totally not applicable to real, live networks...
Steve's 100% spot-on here. I don't have bogon filters at all and it
hasn't hurt me in the least. I think the notion that this is somehow
a good practice needs to be quashed.
Some people don't use condoms with hookers either. Just because they
haven't caught anything yet doesn't make it a smart practice.
Sorry I have to agree with Steve as well. I know I've left networks with Bogon lists in place and then gotten calls a year or more later asking why traffic can't isn't coming in from XYZ new client. Turns out the new admin never updated the bogon list.
If this was done through a central repository and updated daily, or required the list to be refreshed periodically otherwise it timed out- fine. The problem is people leave these lists in and forget about them.
If you are going to keep on top of them, and make sure to remove them when you leave- then that's great. But if you are going to do it half way- please don't bother.
To answer a slightly different question, I was actually thinking about the issues of address space hijacking. So this is where address space that has been legitimately allocated and is properly maintained in routing registries is announced unauthorized by a third party.
Theres nothing weird about the BGP announcement or the address space, except your Yahoo traffic seems to traceroute to North Korea rather than California.....
Less nasty things would be caused by fat fingers, typos in prefixes, accidental announcment of supernets or subnets....
What I'm getting at here is that if someone announces 1.0.0.0/16 then when I spot it I'll raise an issue and alert whoever screwed up but does it break anything? Not normally. But if I accidentally redistribute my static routes to google.com into BGP my phone's going to get busy PDQ!
Steve's 100% spot-on here. I don't have bogon filters at all and it
hasn't hurt me in the least. I think the notion that this is somehow
a good practice needs to be quashed.
Some people don't use condoms with hookers either. Just because they
haven't caught anything yet doesn't make it a smart practice.
On the other hand, compulsive hand washing has never been shown to
keep disease away, and may actually cause dry skin and other
unintended side effects.
Steve's 100% spot-on here. I don't have bogon filters at all and it
hasn't hurt me in the least. I think the notion that this is somehow
a good practice needs to be quashed.
Some people don't use condoms with hookers either. Just because they
haven't caught anything yet doesn't make it a smart practice.
On the other hand, compulsive hand washing has never been shown to
keep disease away, and may actually cause dry skin and other
unintended side effects.
Speaking as someone with a degree in Molecular Biology (gasp!) the dry/damaged skin can actually be a way to increase the susceptibility to bacterium/virons.
As for bogon filtering...when there is a perfectly good, perfectly responsible bogon source you can BGP peer with that is rigorous in its maintenance of good data... why fight it? Sanity check their feed, call it a day. Maintaining your own bogon list is a nightmare.
Someone (years ago) said... why would I want to pay to move bogon traffic across my network when its only going to get dropped by the next hop anyway -- as a justification for filtering bogons.
* rs@seastrom.com (Robert E. Seastrom) [Thu 09 Nov 2006, 16:02 CET]:
[..]
Steve's 100% spot-on here. I don't have bogon filters at all and it
hasn't hurt me in the least. I think the notion that this is
somehow a good practice needs to be quashed.
Yeah! This "Principle of minimal privilege" is totally not applicable
to real, live networks...
I'm not sure what principle of minimal privilege has to do with
filtering addresses that are known unissued. Seems to me that the
principle of minimal privilege would allow connections only from
addresses from which you are specifically expecting them, not from
"the internet at large minus a few blocks that aren't issued".
Particularly in the case of spam abatement, where the vast majority of
spam comes from compromised Windows hosts (which are probably *not*
residing on unissued space), I can't see the point. We could get into
some kind of meta-discussion about DoS attacks and the like, but at
that point you probably want your upstream doing the filtering for you
before it clogs your links. Bottom line: my gut feeling is that the
threat that unissued "bogon" space poses pales in comparison to the
Bad Neighborhood that is the Internet. I would welcome a pointer to
some kind of actual research that shows this to be incorrect.
Of course, bogon filtering is a fine security blanket for those whose
scope of knowledge is not sufficient to perform a meaningful
threat/risk assessment. As for me, I prefer to rivet horseshoes (open
end up, to catch the good luck falling from above) to the cable tray
above my racks. Oh yeah, religiously adhering to BCP-38 as well, that
brings luck too.
automatic systems are fine if you decide you want to do them, i was specifically responding to the author who suggested he would build the filters himself, my point was that this seemingly good intention is in fact causing real operational problems on The Internet right now as anyone receiving addresses from newly allocated blocks will attest to
Since I am the OP, I never said that filtering bogons was a miracle cure all. If we put static bogon filters on customer routers, I would agree that would be stupid and would cause maintenance and routing problems. As an ISP several assignments from formerly bogon blocks, I agree and understand your point. However, we are religious about updating our bogon filters and we never block legitimate traffic or announcements. Bogon filtering is just one thing among many which I think should be done. Following BCP38 and filtering what comes in from customers and transit/peer connections all help to ensure that you aren't part of the problem to the community or to your own clients. The original poster who I replied to stated that it appeared that some traffic of unknown origin on a private address was being routed across his network between routers and he didn't have any routes for that network in his routing tables. My response was that those announcements and traffic should be filtered at his edge. This turned into a thread about whether filtering was a good thing or not which in my mind is absurd. However, if you run a network and want to accept traffic from bogon and RFC1918 space over your customer, peering, and transit connections then that's your problem. I just choose to not make it mine.
-Robert
Tellurian Networks - Global Hosting Solutions Since 1995 http://www.tellurian.com | 888-TELLURIAN | 973-300-9211
"Well done is better than well said." - Benjamin Franklin
BGP filtering using bogon lists affects the routes you receive and hence whether or not you are willing to send traffic TO that space.
If you want to not 'accept traffic FROM bogon and RFC1918 space' then you need to apply acls or rpf.
My issue with BGP filtering is primarily related to manually built filters, there is evidence that this practice is harmful. Whether automatically built filters is a good idea is up to you, the current feeling seems to be yes altho personally I dont implement it.
WRT acls, I would suggest any acl is a bad idea and only a dynamic system such as rpf should be used, this is because manual filters that deny bogons has the same issue as BGP filtering in that it can go stale and you drop newly allocated space. I still would advise tho that there is a lot of address space in use but ot announced on the internet, add to that the use of RFC1918 on internal network links and the potential to break things such as pmtu by dropping icmps is real.
> The craziest stuff that gets announced isnt in the
> reserved/unallocated realm anyway so the effort seems to be
> disproportional to the benefits... and most issues I read about with
> reserved space is packets coming FROM them not TO them....
Steve's 100% spot-on here. I don't have bogon filters at all and it
hasn't hurt me in the least. I think the notion that this is somehow
a good practice needs to be quashed.
I think there is a terminology problem here. People think
that "bogons" means "bogus routes". From that they infer
that bogus routes should be filtered and use the Cymru feed
because it seems to be a no-brainer.
The problem arises because the Cymru feed only contains
the low-hanging fruit. It only refers to address ranges
that *might* be bogus and which are easy to identify.
The problem is that if you pick this fruit, it soon goes
rotten and you end up filtering address ranges which are
in use and almost certainly not bogus.
If there were some way to have a feed of real bogons,
i.e. address prefixes that are *KNOWN* to be bogus at
the point in time they are in the feed, that would be
useful for filtering. And it would likely be a best practice
to use such a feed.
But at the present time, such a feed does not exist.
Also, I think that anyone contemplating creating a new
feed should give some thought to what they are doing.
It would be very useful to have a feed or database which
can assign various attributes to address ranges. When there
is only one possible attribute, bogon, then the meaning
of the attribute gets stretched and the feed becomes useless.
But if there are many attributes such as
UNALLOCATED, UNASSIGNED, DOS-SOURCE, SPAM-SOURCE,
RIR-REGISTERED then it starts to look interesting.
Some networks might like to filter based on several
attributes, others will just filter those with the
DOS-SOURCE attribute.
Obviously, it would require lots of cooperation for
some of these such as UNASSIGNED, but perhaps the Internet
needs to move towards more cooperation between network
operators.