-----Original Message----- From: owner-nanog@merit.edu [mailto:owner-nanog@merit.edu] On Behalf Of Chris L. Morrow Sent: Thursday, March 01, 2007 6:23 AM To: Jon Lewis Cc: Eric Ortega; nanog@merit.edu Subject: Where are static bogon filters appropriate? was: 96.2.0.0/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).
-Chris
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. -> RADb -> RIPE NCC -> DNS Bogon Tracking -> E-mail Bogon Tracking To 'globally' monitor, we have http://www.cymru.com/BGP/robbgp-bogon.html and http://www.cymru.com/BGP/asnbogusrep.html and http://www.cidr-report.org/ and http://www.routeviews.org/ and http://www.completewhois.com/bogons/active_bogons.htm. (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 Bogons.') 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 Bogon/DUSA list. 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 doing it.