Where are static bogon filters appropriate? was: 188.8.131.52/16 Bogons
Barry Greene (bgreene)
bgreene at cisco.com
Sun Mar 4 15:46:12 UTC 2007
> -----Original Message-----
> From: owner-nanog at merit.edu [mailto:owner-nanog at merit.edu] On
> Behalf Of Chris L. Morrow
> Sent: Thursday, March 01, 2007 6:23 AM
> To: Jon Lewis
> Cc: Eric Ortega; nanog at merit.edu
> Subject: Where are static bogon filters appropriate? was:
> 184.108.40.206/16 Bogons
> On Thu, 1 Mar 2007, Jon Lewis wrote:
> > On Wed, 28 Feb 2007, Eric Ortega wrote:
> > > I'd like to thank the group for the responses and help with this
> > > issue. I find it ironic that Randy's study actually uses 96 space.
> > The amazing/sad thing is that people have been facing and
> fixing the
> > same problem for more than 4 years. How many times does a network
> > have to fix their static bogon filters before coming to the
> > realization that those filters are a bad idea?
> So, where are static bogon filters appropriate? (loaded
> question perhaps) I ask because just about every 'security
> expert' and 'security whitepaper'
> or 'security suggestions' has some portion that speaks to
> "why it's a grand idea to have acl-lines/firewall-policy tp
> block 'bogon' ip space"
> (for some definition of 'bogon' of course).
Agreed. This "security experts copying each other - without knowing what
they are really talking about" started to happen 4 years ago. Which is
why some people working with SP all over moved evolving work of
Bogon/DUSA prefix filtering to two places, CYMRU's sponsored "Bogon"
project and RIPE (work like
http://www.ripe.net/ripe/docs/ripe-351.html). Both places allow for
policy practice suggestions to evolve. And they have evolved - working
with operators who are working to institute policies and practices in
their organization which is resistant to operational entropy.
For example, http://www.cymru.com/Bogons/index.html describes the static
policies for people to get started. Static is not the way to go.
Operators who understand the impact of "operational entropy" (OPEX
growth) want dynamic tools. Hence, they spend time find a tool which is
a multipurpose dynamic prefix policy system (i.e. something that does
their customer's prefixes, anti-spoofing, DUSA, Bogon, Black Hole, and
Hijack). This is why the Bogon reference page has grown over the years
adding tricks and tools to build prefix filters dynamically:
-> The Bogon Route Server Project
(http://www.cymru.com/BGP/bogon-rs.html) allows SPs to take a feed or
build their own.
-> RIPE NCC
-> DNS Bogon Tracking
-> E-mail Bogon Tracking
To 'globally' monitor, we have
http://www.cidr-report.org/ and http://www.routeviews.org/ and
(Steve B, you were looking for data, here are your sources. I'm sure
Geoff might be persuaded to do a historical graph on the 'Possible
To organizationally monitor, J & C both have the ability to count the
prefix drops. It was operators who taught me both of these tricks -
which allow them to put in prefix filters which included bogons, then
count the packets originating from those filters prefixes get dropped --
one pulling all that data via SNMP and plugged it into MRTG so they know
the count of packets coming from their peers whose source is in the
Just remember the real reason we do this. 7007 demonstrated an
operational risk to networks. That risk is a cascading risk (prefix
advertisements moving from one network to another). Jump on a miscreant
shopping mall, buy a bunch of BGP speaking "owned" routers, check out
which ones do not have any upstream prefix filters, and have fun. The
two reasons why this has not happened is 1) enough SPs do ingress prefix
filters with their peers to disrupt this attack vector and 2) there is
no way to 'extort' money from the Internet (Miscreant principle #3 -
never to anything for free).
Has this risk gone away? When it has been demonstrated to NOT be a risk,
organizations will change their prefix filter policies. In the mean
time, each organization on the Internet who have perceived operational
risk mitigation benefits from ingress prefix filtering will keep on
More information about the NANOG