Bogon filtering (don't ban me)

Mailman List Mirror (Read Only)
1

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?

2

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

3

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

4

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

5

In Ciscoland its called Autosecure (IOS 12.3):
Networking, Cloud, and Cybersecurity Solutions - Cisco

"Blocks all IANA reserved IP address blocks"

The actual doc:
<http://niatec.info/mediacontent/cisco/media/targets/resources_mod07/7_1_2_AutoSecure.pdf&gt;

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

6

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

7

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

8

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.

9

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?

10

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

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

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

11

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

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

12

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