Bogon filtering (don't ban me)
Considering the talk of banning going on, I was reluctant to post this, anyhow, I wondered how many (if any) have ever thought about the aspect of vendors deciding to implement some form of default bogon filtering on their products. With all of the talk about DoS botnets, and issues surrounding allocated address ranges (for whatever the purpose), I'm curious to know why a vendor like Juniper, or Cisco, or whomever doesn't implement a mechanism to automatically do the filtering. Wouldn't this minimize a vast amount of issues surrounding DoS attacks?
From an admin/user perspective, I would not mind having my equipment implement this as long as it was manageable to add/remove addresses on the fly. Perhaps a command line syntax:
ip bogon add add.res.s/8 or ip bogon remove add.res.s/8 How much would easier would it be for a NAP (per-se) to have their entire network configured properly to avoid having their network send malicious traffic out of their net. I thought about it over and over, and wonder why this hasn't been done. Any care to beat me with a clue stick or two. I can understand the arguments of not wanting a vendor to have control of some aspect of my business, or control over my network, but correct me if I am wrong, wouldn't this solve a heck of a lot of issues concerning network based attacks, spam, scumware/spyware/fooware/$*something? =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ J. Oquendo GPG Key ID 0x51F9D78D Fingerprint 2A48 BA18 1851 4C99 CA22 0619 DB63 F2F7 51F9 D78D http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x51F9D78D sil @ politrix . org http://www.politrix.org sil @ infiltrated . net http://www.infiltrated.net "How can we account for our present situation unless we believe that men high in this government are concerting to deliver us to disaster?" Joseph McCarthy "America's Retreat from Victory"
On Fri, 3 Dec 2004, J. Oquendo wrote:
Considering the talk of banning going on, I was reluctant to post this, anyhow, I wondered how many (if any) have ever thought about the aspect of vendors deciding to implement some form of default bogon filtering on their products. With all of the talk about DoS botnets, and issues surrounding allocated address ranges (for whatever the purpose), I'm curious to know why a vendor like Juniper, or Cisco, or whomever doesn't implement a mechanism to automatically do the filtering. Wouldn't this minimize a vast amount of issues surrounding DoS attacks?
From an admin/user perspective, I would not mind having my equipment implement this as long as it was manageable to add/remove addresses on the fly. Perhaps a command line syntax:
ip bogon add add.res.s/8
or
ip bogon remove add.res.s/8
do you mean like using uRPF and null routes of the bogon/unallocated networks to drop traffic on input? cause that's already there...
I thought about it over and over, and wonder why this hasn't been done. Any care to beat me with a clue stick or two. I can understand the
it has been done... see any of the several past nanog presentations on security that Barry Greene, Tim Battles, Wayne Gustavus have given (and Joe S from Juniper... I'd butcher his spelling, sorry joe!) I think the arguements have gone against 'default blocking' becuase 'default for the internet' is not 'default for enterprise Z'. -Chris
We've proposed what vendors need to better support bogon filtering, even wrote a draft: http://arneill-py.sacramento.ca.us/draft-py-idr-redisfilter-01.txt but last time I talked to cisco ios person (which was just two weeks ago at IPv6 Summit), it still has not been done. Perhaps couple more people who buy their hardware asking them about it will make a difference ... On Fri, 3 Dec 2004, J. Oquendo wrote:
Considering the talk of banning going on, I was reluctant to post this, anyhow, I wondered how many (if any) have ever thought about the aspect of vendors deciding to implement some form of default bogon filtering on their products. With all of the talk about DoS botnets, and issues surrounding allocated address ranges (for whatever the purpose), I'm curious to know why a vendor like Juniper, or Cisco, or whomever doesn't implement a mechanism to automatically do the filtering. Wouldn't this minimize a vast amount of issues surrounding DoS attacks?
From an admin/user perspective, I would not mind having my equipment implement this as long as it was manageable to add/remove addresses on the fly. Perhaps a command line syntax:
ip bogon add add.res.s/8
or
ip bogon remove add.res.s/8
How much would easier would it be for a NAP (per-se) to have their entire network configured properly to avoid having their network send malicious traffic out of their net.
I thought about it over and over, and wonder why this hasn't been done. Any care to beat me with a clue stick or two. I can understand the arguments of not wanting a vendor to have control of some aspect of my business, or control over my network, but correct me if I am wrong, wouldn't this solve a heck of a lot of issues concerning network based attacks, spam, scumware/spyware/fooware/$*something?
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ J. Oquendo GPG Key ID 0x51F9D78D Fingerprint 2A48 BA18 1851 4C99
CA22 0619 DB63 F2F7 51F9 D78D http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x51F9D78D
sil @ politrix . org http://www.politrix.org sil @ infiltrated . net http://www.infiltrated.net
"How can we account for our present situation unless we believe that men high in this government are concerting to deliver us to disaster?" Joseph McCarthy "America's Retreat from Victory"
In Ciscoland its called Autosecure (IOS 12.3): http://www.cisco.com/warp/public/cc/pd/iosw/prodlit/cas11_ds.htm "Blocks all IANA reserved IP address blocks" The actual doc: <http://niatec.info/mediacontent/cisco/media/targets/resources_mod07/7_1_2_AutoSecure.pdf> Problem is, I still do not see that Cisco has a way of auto-updating a router that has used autosec_complete_bogon or autosec_iana_reserved_block. -Hank
We've proposed what vendors need to better support bogon filtering, even wrote a draft: http://arneill-py.sacramento.ca.us/draft-py-idr-redisfilter-01.txt but last time I talked to cisco ios person (which was just two weeks ago at IPv6 Summit), it still has not been done. Perhaps couple more people who buy their hardware asking them about it will make a difference ...
On Fri, 2004-12-03 at 09:23 +0200, Hank Nussbacher wrote:
In Ciscoland its called Autosecure (IOS 12.3): http://www.cisco.com/warp/public/cc/pd/iosw/prodlit/cas11_ds.htm
"Blocks all IANA reserved IP address blocks"
The actual doc: <http://niatec.info/mediacontent/cisco/media/targets/resources_mod07/7_1_2_AutoSecure.pdf>
Problem is, I still do not see that Cisco has a way of auto-updating a router that has used autosec_complete_bogon or autosec_iana_reserved_block.
The most likely have not (could not find it in above docs at least). The thing with below draft is that it can also be used to spread your own filters into the network and thus use it for eg blackholing features and quite a number of other odd occasions. A full auto-distribution of configs (inc. filters etc) is most likely more interresting though.
-Hank
We've proposed what vendors need to better support bogon filtering, even wrote a draft: http://arneill-py.sacramento.ca.us/draft-py-idr-redisfilter-01.txt but last time I talked to cisco ios person (which was just two weeks ago at IPv6 Summit), it still has not been done. Perhaps couple more people who buy their hardware asking them about it will make a difference ...
I will most likely add this to the BGP part of the upcoming new ecmh. Greets, Jeroen
On Fri, 3 Dec 2004, Hank Nussbacher wrote:
"Blocks all IANA reserved IP address blocks"
The actual doc: <http://niatec.info/mediacontent/cisco/media/targets/resources_mod07/7_1_2_AutoSecure.pdf>
Surprise, surprise. The examples in that document are already out of date and filtering as bogons perfectly good IP space ARIN is handing out to members. The idea of a "default static bogon filter" being made part of IOS is a horrible idea. It's bad enough getting the places that went to the trouble of setting up bogon filters to update them. If everyone had them by default, that would likely break the Internet for signifigant numbers of people. How many customer routers do you have on your networks that were installed years ago and never upgraded? How out of date would their default bogon filters be now? ---------------------------------------------------------------------- Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________
On Fri, 3 Dec 2004, Hank Nussbacher wrote:
"Blocks all IANA reserved IP address blocks"
The actual doc:
<http://niatec.info/mediacontent/cisco/media/targets/resources_mod07/7_1_2_AutoSecure.pdf>
Surprise, surprise. The examples in that document are already out of date and filtering as bogons perfectly good IP space ARIN is handing out to members.
The idea of a "default static bogon filter" being made part of IOS is a horrible idea. It's bad enough getting the places that went to the trouble of setting up bogon filters to update them. If everyone had them by default, that would likely break the Internet for signifigant numbers of people. How many customer routers do you have on your networks that were installed years ago and never upgraded? How out of date would their default bogon filters be now?
---------------------------------------------------------------------- Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________
Isn't the path to hell is paved with good intentions? It's not the first time Cisco routes have shipped with out of date software in them, or known bugs/issues that pop up later to cause problems. ;-) Seriously, I'm not knocking Cisco, I'm just telling it like it is. If someone knows what they're doing they won't get burned on it. There are a lot of other IOS commands/options that can be turned on to screw networks up much worse. I don't fault Cisco for giving people the option. It should have a warning though, when enabled that it is out of date and will break things. Just thinking out loud here: If Cisco wanted to do something related to bogon filtering, they should make routes that expire/self delete after a certain date. Routes with a time to live. (NTP optional, but a set clock required to use the TTL routes). Also, bogon lists, especially the ones that have been prepared by hand by someone so they can be cut/pasted into a router, should start with a remark line that says something along the lines of **WARNING DELETE AFTER FEB 2005! ** (Or, current date+ 4 months). I realize a lot of things can't be remarked, but any attempt to remark it, seems like it would be a good idea. Some people don't read all the stuff in the web page before they scroll down, and copy the bogon list. Some people don't heed the warnings. Some people leave their job after they put in bogons. Some people are router consultants, and never see that router again. Some people are too busy putting out fires and forget that 8 months have passed since they checked their bogons. And some people are just stupid. ;-) A remark could go a long way to solving/preventing the problem when the next person takes a look at the router's configuration. The perfect solution to the bogon issue is constant diligence. Getting a route feed is a good seccond choice. The third choice is to not use bogon filters at all. In a perfect world, those in charge of allowing routes in to the global internet wouldn't allow bogons, because they would only allow announcements that they've checked out ahead of time. And just like packet ingress filtering, it's a solution that probably won't happen any time soon. -Jerry
On Fri, 2004-12-03 at 00:53 -0500, J. Oquendo wrote:
Considering the talk of banning going on, I was reluctant to post this, anyhow, I wondered how many (if any) have ever thought about the aspect of vendors deciding to implement some form of default bogon filtering on their products. With all of the talk about DoS botnets, and issues surrounding allocated address ranges (for whatever the purpose), I'm curious to know why a vendor like Juniper, or Cisco, or whomever doesn't implement a mechanism to automatically do the filtering. Wouldn't this minimize a vast amount of issues surrounding DoS attacks?
Let people first use RPF, when they are doing that we can see what the next step is. That next step is in the direction of what Team Cymru is doing... redist-filter could help there a lot. There is one thing though which is somewhat a problem with these setups, one has to trust the source of the filters, they are technically controlling your network, who you talk to and who not. And this little technical issue can be a huge political issue. I personally would really like to see a 'valid prefixes' feed from the RIR's. Then again, the amount of 'crap' coming from un-assigned/illegal prefixes is minimal compared to the vast DDoS nets around and for the latter there are some solutions available if you contact the correct people... Greets, Jeroen PS: Why would this be a 'bannable' subject? It is about _network operations_ isn't it? And otherwise I am quite sure that the ones in check of the rules will be so nice to point out differently, if one on the otherhand already thinks it is a wrong subject, then why post at all.... but that is an IMO ;)
There is one thing though which is somewhat a problem with these setups, one has to trust the source of the filters, they are technically controlling your network, who you talk to and who not. And this little technical issue can be a huge political issue.
This change control issue is an important one because, as we have seen with many other technical great ideas, operations folks cannot just go ahead and implement every great idea. There are management people to convince that this great idea will not disrupt the operation of the network, either directly or indirectly through unwarranted cost increases. In my opinion, these type of feeds should not be made available in BGP format, because, as you say, this puts the external party in control of your routing policy. I think that these feeds should be considered "advisory information" and made available in a format that can easily be integrated into a change control system where humans can check and validate the data. I really do think that LDAP would be the ideal protocol for doing this. As for oversight of Cymru's bogon list and trust issues... well, this is what the RIR system was developed for. We don't technically need RIRs to allocate IP addresses. But we do need them to provide oversight and trust of the whole IP allocation process. At this point, most people have no idea who Cymru is other than Rob Thomas and while he appears to be a very clued and trustworthy individual, he is operating a service that does not have community oversight in the same way as the RIRs. In a sense, Rob is a hacker who has installed his rootkit into the IANA/RIR system. He was only able to do so because the IANA and RIRs were not paying enough attention to their interfaces, thus creating a grey area which Cymru is filling. --Michael Dillon
Hi, NANOGers. ] In a sense, Rob is a hacker who has installed his ] rootkit into the IANA/RIR system. He was only able ] to do so because the IANA and RIRs were not paying ] enough attention to their interfaces, thus creating ] a grey area which Cymru is filling. Wow! I've at last achieved mad leet status. Thanks. :) We have consistently stated that we would happily hand over the sundry bogon filtering projects to the RIRs if they wanted to take over the tasks. We are filling a niche, and will continue to do so as long as the need exists and others (the RIRs) aren't interested in doing so. Team Cymru now has four full time members, all of whom are smarter and more clueful than I. :) They are all equally adept at managing our sundry projects, which ensures that the projects don't succumb to a single point of failure in gear, location, or personnel. You can see our mug shots here: <http://www.cymru.com/About/> As for oversight, we are entirely beholden to our customers. Who are our customers? YOU! Folks who work with us regularly know that we aim to be very responsive to you, and regularly modify our projects to make your lives easier. A bit of common sense and open dialogue keeps us in tune with what you need. It's not so very formal, and it has worked quite well. We can't do everything, of course, so our projects are all collaborative efforts and partnerships with great folks in this community. We are particularly thankful to the following: <http://www.cymru.com/About/thanks.html> We try to get to all of your suggestions, but please remember that even our supply of coffee is exhausted from time to time. :) As for trust, it's really all we have to offer. Our credibility is our only real asset. We work to earn your trust with each project. I think we've done a fair job of that. Suggestions and feedback (along with coffee) are always welcome! Thanks, Rob, not the only member of Team Cymru. :) -- Rob Thomas http://www.cymru.com Shaving with Occam's razor since 1999.
On Dec 3, 2004, at 1:36 PM, Rob Thomas wrote:
] In a sense, Rob is a hacker who has installed his ] rootkit into the IANA/RIR system. He was only able ] to do so because the IANA and RIRs were not paying ] enough attention to their interfaces, thus creating ] a grey area which Cymru is filling.
Wow! I've at last achieved mad leet status. Thanks. :)
You were that WAAAAAY long ago! And with all due respect to Michael (hi, Michael, long time no type :), you are neither a hacker nor a threat. First: The Internet runs on trust. We Trust Team Cymru. Secondly (especially for those who are .. uh .. uninitiated enough to trust team Cymru), it is much easier to protect our trust in the bogon filter than, say, large peers. Everyone talks about registering routes, but how many people actually do it? Not enough. So, people peer at their borders and allow 10s or even 100s of outside ASes "control" their routing. With the bogon filters, one can take today's snapshot, create a filter list and apply. As bogons go away (CIDRs get allocated), the BGP feed will still work. But if Cymru "messes up" and slips a full feed into the bogon feed, nothing bad will happen. (In fact, you might want to put a sample cisco & Juniper ACL from today's feed on the web site - just a suggestion, I'm sure most people here can do it themselves.) Also, I _LIKE_ getting the information through BGP. The Border Gateway Protocol was specifically designed to allow separate (autonomous) entities to pass routing data. That is _exactly_ what we are doing with the bogon feed. Just my $0.00002. (And I won't even ask not to be banned. :) -- TTFN, patrick
--- "J. Oquendo" <sil@politrix.org> wrote:
I thought about it over and over, and wonder why this hasn't been done. Any care to beat me with a clue stick or two. I can understand the arguments of not wanting a vendor to have control of some aspect of my business, or control over my network, but correct me if I am wrong, wouldn't this solve a heck of a lot of issues concerning network based attacks, spam, scumware/spyware/fooware/$*something?
Vendor C has something similar, in their "autosecure" feature. However, the trouble is that the list of bogon networks is static, and in fact includes 70/8 among many others. This is (I'm certain) contributing to the reachability issues that those folks with new netblocks experience. A better implementation would be for vendors to include a "bogon-subscribe server x.x.x.x" feature, which would simply allow a router to talk to a centralized bogon server. However, the complexity of setting up the real-time BGP bogon feeds is not that hard - anyone who would use the above command could do it - so I'm not sure that this requires any new tools. ===== David Barak -fully RFC 1925 compliant- __________________________________ Do you Yahoo!? Yahoo! Mail - now with 250MB free storage. Learn more. http://info.mail.yahoo.com/mail_250
participants (11)
-
Christopher L. Morrow -
David Barak -
Hank Nussbacher -
J. Oquendo -
Jeroen Massar -
Jerry Pasker -
Jon Lewis -
Michael.Dillon＠radianz.com -
Patrick W Gilmore -
Rob Thomas -
william(at)elan.net