Re: Bogon filtering (don't ban me)

[Patrick W Gilmore]

On Dec 6, 2004, at 6:30 AM, [EMAIL PROTECTED] wrote:
The point is that the bogon feed doesn't
need to be hooked directly into your routers.
This is what Patrick Gilmore does, i.e.
he takes the bogon feed into a managenment
system, generates an ACL and then periodically
applies the ACL to his routers. Presumably
that ACL gets checked by a clueful person
before it goes out.
Just to be clear, I did not say that is what I did, or any organization 
I work for did.  It was just a possible suggestion, not a requirement 
or a statement of fact.

I'm just interested in cleaning up the cruft on the 'Net.  Useless 
deaggregates, bogons, spoofed source, etc.  You know, the things YOU 
can do with YOUR network and YOUR customers so _I_ do not have to deal 
with it.

Given how much time and effort has been spent on things like "filtering 
on allocation boundaries" because some big networks do not want to take 
some /24s when little guys multi-home, you would think everyone would 
get behind this and push really hard.  Just seems like a much bigger 
win with far fewer religious questions.

But, of course, that wouldn't be nearly as fun. :)
--
TTFN,
patrick

RE: Bogon filtering (don't ban me)

[Jeff Rosowski]

Just thinking out loud, but is there any reason that this
route-server methodology couldn't be applied to other 'undesirable'
destinations, such as the world's top spammers, phishing web sites, etc?
Maybe break them up into different communities, so subscribers can pick
which ones they want to filter.
Sounds like a good idea, though with the administrative overhead of 
managing such a project, as much as I'd like to see something like that 
offered for free, it would most likely have to be a subscription based 
service.

You're also talking a hell of a lot more information in your routing 
table, since at this point we're talking some pretty granular routes.  I 
mean if people complain about 150K+ routes now?

Re: Bogon filtering (don't ban me)

[Michael . Dillon]

> The whole point that started this discussion is that bogon filtering is 
> HARMFUL a good part of the time. 

This may be so, but there are things that you
can do with an up to date bogon feed other
than filtering. That's why I suggested that
BGP may not be the best form for the feed but
for some reason LDAP is feared by people who
don't run mailservers or large LANs.

For instance, if you reflect all incoming
BGP announcements into a management system
then that system could compare them with 
an up-to-date bogin feed and alert the ops
staff when questionable announcements are
seen. Or it could trigger additional data
collection to be used in network forensics.

The point is that the bogon feed doesn't
need to be hooked directly into your routers.
This is what Patrick Gilmore does, i.e.
he takes the bogon feed into a managenment
system, generates an ACL and then periodically
applies the ACL to his routers. Presumably
that ACL gets checked by a clueful person
before it goes out.

Perhaps what we really need here is a BCP
document that describes the ways in which
a bogon feed can be integrated into network
operations. If you do RPF, then maybe it's not
needed for blocking traffic but you still
might like to know who is trying to announce
these bogon blocks to you.

--Michael Dillon

Re: Bogon filtering (don't ban me)

[Rob Thomas]

Hi, Sean.

] Unless you are a professional router driver, using Team Cymru's
] suggested router configuration will hurt most average users.  Which is
] a problem because a lot of the Team Cymru recommendations are good
] router hygenie.  But I can't in good faith recommend people use the Team
] Cymru, because of those dangerous inclusions.

This is one of the reasons why we offer the list in a wide variety
of colors and models.  :)  Take a peek at the RADb entries, which
do differentiate based on type:

   
- fltr-unallocated
- fltr-martian
- fltr-bogons

I hope this helps!  We could also divide the list in our text and
HTML offerings, and add separate communities for special use and
unallocated.  I'm always sorry to hear that folks can't use our
projects, especially if they don't convey to us why.  Suggestions
are always welcome!

Thanks,
Rob.
-- 
Rob Thomas
http://www.cymru.com
ASSERT(coffee != empty);

Re: Bogon filtering (don't ban me)

[Sean Donelan]

On Sun, 5 Dec 2004, Rob Thomas wrote:
> In a study of one oft' scanned and attacked site, we found that
> 66.85% of the source IPs were bogon (RFC1918, unallocated, etc.).
> You can read about it at the following URL:
>
>

One of the more annoying things has been Team Cymru munged "Unallocated"
and "Martian" addresses together to create "Bogons."  As your 2001
presentation indicates, 53.39% were from Class D and E space, which
means about 13% were from "Unallocated" space.  And of course about
34% from "Allocated" space.

Protocol hygenie is good.  Keeping martians out of the routing table and
dropping packets with never valid source addresses is good.  Unless the
RFCs are changed, those IP addresses are extremely stable.

The unfortunate use of the word "Bogon" has lead some less technical
people to believe everything in the Team Cymru lists are the same.  The
problems with the Team Cymru lists occur because they include unallocated
space in the same list in a recommended static router configuration file.
For most users, router configuration files are very static.  The
configurations are created when they install the router, and rarely
updated.

Car commercials say "Do not attempt.  Professional driver on closed
course."

Unless you are a professional router driver, using Team Cymru's
suggested router configuration will hurt most average users.  Which is
a problem because a lot of the Team Cymru recommendations are good
router hygenie.  But I can't in good faith recommend people use the Team
Cymru, because of those dangerous inclusions.

Re: Bogon filtering (don't ban me)

[Iljitsch van Beijnum]

On 5-dec-04, at 22:06, Cliff Albert wrote:
So filtering at the /8 level as in the document linked above isn't 
really going to buy you much in practice.

/8 le /32 still stands for /8 and more-specifics as I remember ? :)
You don't say... What will they come up with next??
My point is that if there is even a small part of a /8 in use, then the 
/8 isn't in the bogon list. For instance, 191.0.0.0/8 isn't there, 
although AFAIK this space isn't used, it's just that 191.255.0.0/16 is 
"reserved".

Secondly not everything is about security but also about keeping 
routing
tables clean and useful, as more people noticed today.
If only we could...
Filtering bogons away is just an extra step in making sure that you
transport real traffic instead of bogus traffic of which you are 100%
sure that it's *useless* traffic. uRPF will fix it for your own 
network,
Right. So there is no need to use bogon lists.
but filtering bogon routes away in BGP will also make your downstream
a happier place.
You are assuming that there are significant bogon routes in the routing 
table. I'm sure there is bad stuff in the global routing table from 
time to time that Rob's bogon list will catch, but I seriously doubt 
it's very much. Injecting bogon routes so you can get past uRPF doesn't 
make sense (except maybe for the first hop AS) and for any other 
(ab)use such as spamming selecting something that isn't as obvious is 
much more useful.

(In any case, ISPs accepting bogon routes from their customers is 
completely unacceptable. Filtering routes from peers isn't always 
feasible, and even lack of source address filtering on ingress from 
customers can be excusable at times, but filtering BGP advertisements 
from customers is every ISP's sacred duty.)

The only argument from you I have seen against bogon filtering is the
fact that the lists aren't updated by certain parties.
I've never felt that it's useful. So one argument against is more than 
sufficient.

However, allow me to contradict myself by taking the position that it's 
better for us network operators to do bogon filtering so our customers 
don't have to, rather than have any fool with an ipfw or similar shoot 
himself in the foot. The preferred way to do this would be uRPF.

Re: Bogon filtering (don't ban me)

[Cliff Albert]

On Sun, Dec 05, 2004 at 09:52:02PM +0100, Iljitsch van Beijnum wrote:

> > 
> 
> Note though that so far, nobody has tried to inject bogon routes into 
> the global routing table just so packets from bogon sources wouldn't be 
> filtered. The reason we want this is because of address space hijacking 
> (such as done by spammers) and configuration mistakes. So filtering at 
> the /8 level as in the document linked above isn't really going to buy 
> you much in practice.

/8 le /32 still stands for /8 and more-specifics as I remember ? :)

Secondly not everything is about security but also about keeping routing
tables clean and useful, as more people noticed today.

Filtering bogons away is just an extra step in making sure that you
transport real traffic instead of bogus traffic of which you are 100%
sure that it's *useless* traffic. uRPF will fix it for your own network,
but filtering bogon routes away in BGP will also make your downstream
a happier place. 

The only argument from you I have seen against bogon filtering is the
fact that the lists aren't updated by certain parties.

-- 
Cliff Albert <[EMAIL PROTECTED]>

Re: Bogon filtering (don't ban me)

[Paul Vixie]

> > Just thinking out loud, but is there any reason that this
> > route-server methodology couldn't be applied to other 'undesirable'
> > destinations, such as the world's top spammers, phishing web sites,
> > etc?  Maybe break them up into different communities, so subscribers
> > can pick which ones they want to filter.
> 
> You are a few years late with that Idea - Paul Vixie had it first, quite
> some time back.

indeed.  and i believe it's still up and running, see .
-- 
Paul Vixie

Re: Bogon filtering (don't ban me)

[Joe Abley]

On 5 Dec 2004, at 13:31, william(at)elan.net wrote:
On Sun, 5 Dec 2004, william(at)elan.net wrote:
On Sun, 5 Dec 2004, Joe Abley wrote:
With OpenBSD 3.6 running pf and bgpd, you can apply a filter rule to
BGP updates received from individual peers which updates a pf radix
table with the network received:
PF and bgpd with local filter table is good when you're expecting 
those
filtered ip routes to change often. But this is not true about bogons
Ok, I guess I did not read original post closely enough. PF is for
reinjecting routes that match local rules back into bgp, right?
No -- pf is a packet filter, and in this case the rules for what 
filters to packet are being driven by BGP updates instead of static 
config. Nothing is being re-introduced from pf into BGP.

It's very true that the routes received from the bogon servers don't 
change very often. However, I still very much like the idea of 
outsourcing the job of keeping my firewalls' bogon filters up-to-date 
to team cymru, rather than having to worry about doing it myself.

For looking at active routes and seeing which ones match the rules I
personally use "hacked" bird daemon, but it is not ready for public
testing...
I'm sure there are many ways to skin this particular house pet.
OpenBSD 3.6 let me do all this stuff out-of-the-box, without installing 
a single other package. I find that I like that; not having to compile 
and tweak stuff makes me happy. I guess I'm getting old.

Joe

Re: Bogon filtering (don't ban me)

[Iljitsch van Beijnum]

On 5-dec-04, at 20:03, Rob Thomas wrote:
] - That's only some 40% of all address space, so you need to be able 
to
] deal with the other 60% anyway. Why wouldn't whatever mechanism that
] deals with the 60% be unable to deal with the additional 40%?

In a study of one oft' scanned and attacked site, we found that
66.85% of the source IPs were bogon (RFC1918, unallocated, etc.).
Well, I didn't keep a running total, but I'd say that in the attacks 
that I've dealt with 80%+ used real addresses or something 
indistinguishable. I understand this is what most people see. So unless 
someone has data that indicates otherwise, I'll assume your experiences 
are an exception.

Filtering out bogons removes yet one more potential source of
badness.
...while at the same time introducing a new one: the risk of filters 
going un-updated. (Generally speaking. For a BGP feed from you this 
isn't much of a risk.)

] - (Loose) uRPF will buy you the exact same functionality and more
] without any upkeep.

Even with uRPF one needs to keep the RIB clean.
Yes, but how do you do that without an authoritative prefix->AS 
mapping? (And good tools. I know there are some, but I find them too 
hard to work with.)

 
Note though that so far, nobody has tried to inject bogon routes into 
the global routing table just so packets from bogon sources wouldn't be 
filtered. The reason we want this is because of address space hijacking 
(such as done by spammers) and configuration mistakes. So filtering at 
the /8 level as in the document linked above isn't really going to buy 
you much in practice.

Re: Bogon filtering (don't ban me)

[Patrick W Gilmore]

On Dec 5, 2004, at 3:08 PM, Mikael Abrahamsson wrote:
On Sun, 5 Dec 2004, Jørgen Hovland wrote:
Blocking bogons will result in that attackers use existing netblocks
instead. This will again result in more insecureness since any attack 
will
If the people making attack code would stay out of 224.0.0.0/4 space 
(both
for dest and src) it would be a big improvement.
And if the people making attack code were forced to use real IP 
address, or, put another way, if you could guarantee that the source IP 
address on an attack packet was the actual source of the attack, it 
would help in tracking attacks.

Before you say "we know where bot-net attacks are originating, but 
cannot get them to stop", that is another problem.  As Rob said, 
problems are solved in steps, not with one wave of the magic wand.  And 
saying "step one won't solve the problem so we shouldn't even start" is 
not, IMHO, a good idea.

--
TTFN,
patrick

Re: Bogon filtering (don't ban me)

[Mikael Abrahamsson]

On Sun, 5 Dec 2004, Jørgen Hovland wrote:

> Blocking bogons will result in that attackers use existing netblocks
> instead. This will again result in more insecureness since any attack will

If the people making attack code would stay out of 224.0.0.0/4 space (both 
for dest and src) it would be a big improvement.

-- 
Mikael Abrahamssonemail: [EMAIL PROTECTED]

Re: Bogon filtering (don't ban me)

[Jørgen Hovland]

On Sun, 5 Dec 2004, Rob Thomas wrote:

>
> Hi, NANOGers.

Hello,

>
> ] - That's only some 40% of all address space, so you need to be able to
> ] deal with the other 60% anyway. Why wouldn't whatever mechanism that
> ] deals with the 60% be unable to deal with the additional 40%?
>
> In a study of one oft' scanned and attacked site, we found that
> 66.85% of the source IPs were bogon (RFC1918, unallocated, etc.).
> You can read about it at the following URL:
>
>
>
> Filtering out bogons removes yet one more potential source of
> badness.  Does it remove all badness?  Of course not.  We win
> by degrees.  Removing any tool from the bad persons' toolkit is
> useful.
>

Does it really?
When I perform any type of change the most important thing for me isn't
what it will prevent/help for but the opposite; What it will not prevent/help.
Blocking bogons will result in that attackers use existing netblocks
instead. This will again result in more insecureness since any attack will
have source addresses within valid space and some people will find it
harder to determine the real sources, atleast in the beginning.
So any type of bogon filter like that seems to me a total waste of time.
It does not really prevent anything in the long run.

You may have taken the can-opener away from this bad person, but you don't
really need a can-opener to open the beer anyway... correct me if I'm
wrong.

Joergen Hovland ENK

Re: Bogon filtering (don't ban me)

[James]

On Sun, Dec 05, 2004 at 07:38:06PM +0100, Cliff Albert wrote:
> 
> On Sun, Dec 05, 2004 at 12:36:08PM -0600, Rob Thomas wrote:
> 
> > ] I have one question regarding the CYMRU bogon route-server. What good is
> > ] it if more-specific bogons are going around in the BGP table ?
> > 
> > At present, none.  We have feature requests into some major router
> > vendors to make this more useful.  The goal is to provide a syntax
> > similar to prefix-list that would permit you to filter on a prefix
> > and anything more specific.  Stay tuned!
> 
> Indeed, that's the biggest problem at the moment. I have seen some folks
> feature requesting this at juniper, but seems they all got a big NO
> back.
> 
> -- 
> Cliff Albert <[EMAIL PROTECTED]>

Just FYI --

Team Cymru also provides IRR objects for those using automated BGP policies
with ease. Using IRR objects, dependent on how *you* set it up, you should be
able to filter out specifics.

Their object is fltr-bogons on whois.radb.net:
filter-set:   fltr-bogons
descr:All bogon IPv4 prefixes.
filter:   fltr-unallocated OR fltr-martian
tech-c:   RTH32-ARIN
admin-c:  RTH32-ARIN
mnt-by:   MAINT-BOGON-FILTERS
changed:  [EMAIL PROTECTED] 20040420
source:   RIPE

Example for filtering bogons from transit:

import:  from AS209  accept ANY and not fltr-bogons

I make use of these objects for configuring BGP for customers who are multihomed
to different ISP's, so far with great success.

Hope this helps,

-J

-- 
James JunTowardEX Technologies, Inc.
Technical Lead  Boston IPv4/IPv6 Web Hosting, Colocation and
[EMAIL PROTECTED]Network design/consulting & configuration services
cell: 1(978)-394-2867   web: http://www.towardex.com , noc: www.twdx.net

Re: Bogon filtering (don't ban me)

[Rob Thomas]

Hi, NANOGers.

] - That's only some 40% of all address space, so you need to be able to
] deal with the other 60% anyway. Why wouldn't whatever mechanism that
] deals with the 60% be unable to deal with the additional 40%?

In a study of one oft' scanned and attacked site, we found that
66.85% of the source IPs were bogon (RFC1918, unallocated, etc.).
You can read about it at the following URL:

   

Filtering out bogons removes yet one more potential source of
badness.  Does it remove all badness?  Of course not.  We win
by degrees.  Removing any tool from the bad persons' toolkit is
useful.

Those who track backscatter (the detritus of a spoofed source
attack) are still seeing a healthy bit of traffic.  While
spoofing is less popular than it once was, it still remains a
viable attack feature.  Tools such as bang.c depend entirely on
the ability to spoof.  Not all spoofing uses bogon IP space.
That's fine, we can reduce the alternatives bit by bit.

Dealing with the other sources of badness is an exercise for
other ideas.  The Darknet Project is one such way to spot that
badness.

   

How you choose to respond to that badness (report it to the
source, report it to their upstreams, null route them, do
nothing) is of course up to you.

] - (Loose) uRPF will buy you the exact same functionality and more
] without any upkeep.

Even with uRPF one needs to keep the RIB clean.  That means the
use of filtering.  We and others provide those as well:

 
 
 

Thanks,
Rob.
-- 
Rob Thomas
http://www.cymru.com
ASSERT(coffee != empty);

Re: Bogon filtering (don't ban me)

[Iljitsch van Beijnum]

On 5-dec-04, at 19:29, Joe Maimon wrote:
I think that a BGP mechanism to tag routes as "ignore all more 
specifics" would solve this problem nicely. (and perhaps a whole lot 
others -- such as needless deaggregation)
Yeah, like people who are needlessly deaggregating are going to send 
out an aggregate with this tag on it...

What you want is a way to inject filters into a box remotely with live 
updating. So this is what the vendors should build.

As far as router vendors such as Cisco autosecure, I do not think 
there is any way to make default access lists lossless. They should 
step up to the plate and offer md5 by system serial number keyed 
multihop BGP bogons in the manner of cymru. Its their responsibility.
Why?
Why should anyone bother?
Why are we even discussing this?
The whole point that started this discussion is that bogon filtering is 
HARMFUL a good part of the time. And it doesn't really do anything 
useful to begin with! You get to reject packets from dark address 
space, but:

- That's only some 40% of all address space, so you need to be able to 
deal with the other 60% anyway. Why wouldn't whatever mechanism that 
deals with the 60% be unable to deal with the additional 40%?

- (Loose) uRPF will buy you the exact same functionality and more 
without any upkeep.

Re: Bogon filtering (don't ban me)

[Ian Dickinson]

Cliff Albert wrote:
On Sun, Dec 05, 2004 at 12:41:32PM -0500, Joe Abley wrote:
>>
I have one question regarding the CYMRU bogon route-server. What good 
is it if more-specific bogons are going around in the BGP table ?
With OpenBSD 3.6 running pf and bgpd, you can apply a filter rule to 
BGP updates received from individual peers which updates a pf radix 
table with the network received:
Nice - anyone know of anything equivalent for ipf/pfil on Solaris?
Interesting, but no option on Juniper/IOS boxes/foundry boxen. 
Since 12.0(29)S and 12.2(25)S, this feature:
BGP Support for IP Prefix Import from Global Table into a VRF Table
http://www.cisco.com/univercd/cc/td/doc/product/software/ios120/120newft/120limit/120s/120s29/cs_bgivt.htm
does the trick nicely, as long as you trust builds that new,
and your linecards are new enough.  Worked fine in my testing.
This is effectively a way of populating a VRF and then pointing uRPF at
it.  I think it was aimed at feasible path uRPF, but can do the bogon
stuff as well.
--
Ian Dickinson
Development Engineer
PIPEX
[EMAIL PROTECTED]
http://www.pipex.net
This e-mail is subject to: http://www.pipex.net/disclaimer.html

Re: Bogon filtering (don't ban me)

[william(at)elan.net]

On Sun, 5 Dec 2004, Joe Maimon wrote:

> >PF and bgpd with local filter table is good when you're expecting those
> >filtered ip routes to change often. 
> >  
> I dont understand this attitude. Automating everything that is safely 
> automatable is the only right way to do things. Its always worth it and 
> it is always good. Everyone has always professed to believe in this.

I completely agree about automatic updates. I just want to point out that
for data that rarely changes and where such changes can easily be 
accomodated when distributed within 24 hours using BGP (which is
designed for rapid updates of routing data) is an overkill.

> In this case this is the exact cause of the problem the thread started 
> addressing: Manual updates that dont keep up.
> 
> Once upon  a time this was the argument of sendmail access database V. 
> dnsbls. Once upon a time you were expected to manually update virus 
> definitions. Once upon a time you were expected to etc.. the list goes on.

And look at virus defenitions - they do not get distributed immediatly 
to end-sites like BGP, instead local systems check with remote server
once/day or once/week and automaticly download new definitions.

> Every "weekly" task an admin takes on manually adds up. It may be great 
> job insurance but it starts to suck quick for anyone with half a brain.

Look at the webpage I listed, it mentiones several times that updates
must be made automaticly (or otherwise you should not bother) and includes 
scripts that automaticly recreate firewall scripts every week or every
day from the downloaded ip list.

> As far as router vendors such as Cisco autosecure, I do not think there 
> is any way to make default access lists lossless. They should step up to 
> the plate and offer md5 by system serial number keyed multihop BGP 
> bogons in the manner of cymru. Its their responsibility. Also good that 
> it makes them eat even more of their own dogfood which is probably ill 
> suited to this kind of thing.

Or they could offer service to update relevent ios security config 
(including access-list) from remote server once/day/week. This would
be a lot easier then forcing everyone who needs this do bgp feed
and it also takes care of security updates that require more then
just updating one specific access-list.

-- 
William Leibzon
Elan Networks
[EMAIL PROTECTED]

Re: Bogon filtering (don't ban me)

[Cliff Albert]

On Sun, Dec 05, 2004 at 12:36:08PM -0600, Rob Thomas wrote:

> ] I have one question regarding the CYMRU bogon route-server. What good is
> ] it if more-specific bogons are going around in the BGP table ?
> 
> At present, none.  We have feature requests into some major router
> vendors to make this more useful.  The goal is to provide a syntax
> similar to prefix-list that would permit you to filter on a prefix
> and anything more specific.  Stay tuned!

Indeed, that's the biggest problem at the moment. I have seen some folks
feature requesting this at juniper, but seems they all got a big NO
back.

-- 
Cliff Albert <[EMAIL PROTECTED]>

Re: Bogon filtering (don't ban me)

[Rob Thomas]

Hi, Cliff.

] I have one question regarding the CYMRU bogon route-server. What good is
] it if more-specific bogons are going around in the BGP table ?

At present, none.  We have feature requests into some major router
vendors to make this more useful.  The goal is to provide a syntax
similar to prefix-list that would permit you to filter on a prefix
and anything more specific.  Stay tuned!

Thanks,
Rob.
-- 
Rob Thomas
http://www.cymru.com
ASSERT(coffee != empty);

Re: Bogon filtering (don't ban me)

[Joe Maimon]

william(at)elan.net wrote:
On Sun, 5 Dec 2004, Joe Abley wrote:
 

On 5 Dec 2004, at 06:50, Cliff Albert wrote:
   

I have one question regarding the CYMRU bogon route-server. What good 
is
it if more-specific bogons are going around in the BGP table ?
 

With OpenBSD 3.6 running pf and bgpd, you can apply a filter rule to 
BGP updates received from individual peers which updates a pf radix 
table with the network received:
   

PF and bgpd with local filter table is good when you're expecting those
filtered ip routes to change often. 
 

I dont understand this attitude. Automating everything that is safely 
automatable is the only right way to do things. Its always worth it and 
it is always good. Everyone has always professed to believe in this.

In this case this is the exact cause of the problem the thread started 
addressing: Manual updates that dont keep up.

Once upon  a time this was the argument of sendmail access database V. 
dnsbls. Once upon a time you were expected to manually update virus 
definitions. Once upon a time you were expected to etc.. the list goes on.

Every "weekly" task an admin takes on manually adds up. It may be great 
job insurance but it starts to suck quick for anyone with half a brain.

Now to throw some whacky ideas out instead of opinions.
I think that a BGP mechanism to tag routes as "ignore all more 
specifics" would solve this problem nicely. (and perhaps a whole lot 
others -- such as needless deaggregation)

As far as router vendors such as Cisco autosecure, I do not think there 
is any way to make default access lists lossless. They should step up to 
the plate and offer md5 by system serial number keyed multihop BGP 
bogons in the manner of cymru. Its their responsibility. Also good that 
it makes them eat even more of their own dogfood which is probably ill 
suited to this kind of thing.

They should ask team cymru to help them do it and give them a nice fat 
check while they are at it.

Failing that they could offer radius/tacaccs loading of that access 
list. Anything else is negligence.

And using BGP for /32 blacklist routes probably has very limited 
scalability. Any one have any relevant numbers?

Everybody who posts lists of static access lists should seriously 
consider stopping. If not that, offer an email subscription to announce 
updates.

(think I beat the S:N? --even if my S is nonsense?)
Joe

Re: Bogon filtering (don't ban me)

[william(at)elan.net]

On Sun, 5 Dec 2004, william(at)elan.net wrote:

> On Sun, 5 Dec 2004, Joe Abley wrote:
> 
> > On 5 Dec 2004, at 06:50, Cliff Albert wrote:
> > 
> > > I have one question regarding the CYMRU bogon route-server. What good 
> > > is
> > > it if more-specific bogons are going around in the BGP table ?
> > 
> > With OpenBSD 3.6 running pf and bgpd, you can apply a filter rule to 
> > BGP updates received from individual peers which updates a pf radix 
> > table with the network received:
> 
> PF and bgpd with local filter table is good when you're expecting those
> filtered ip routes to change often. But this is not true about bogons

Ok, I guess I did not read original post closely enough. PF is for 
reinjecting routes that match local rules back into bgp, right?
If so I apologize, I though it was talking about taking bgp data
and using it to filter local servers

For looking at active routes and seeing which ones match the rules I 
personally use "hacked" bird daemon, but it is not ready for public
testing...

---
William Leibzon, Elan Networks:
 mailto: [EMAIL PROTECTED]
Anti-Spam and Email Security Research Worksite:
 http://www.elan.net/~william/emailsecurity/

Re: Bogon filtering (don't ban me)

[william(at)elan.net]

On Sun, 5 Dec 2004, Joe Abley wrote:

> On 5 Dec 2004, at 06:50, Cliff Albert wrote:
> 
> > I have one question regarding the CYMRU bogon route-server. What good 
> > is
> > it if more-specific bogons are going around in the BGP table ?
> 
> With OpenBSD 3.6 running pf and bgpd, you can apply a filter rule to 
> BGP updates received from individual peers which updates a pf radix 
> table with the network received:

PF and bgpd with local filter table is good when you're expecting those
filtered ip routes to change often. But this is not true about bogons
which for cymru IANA-only data changes couple times a year and for 
completewhois full RIR bogon changes once/day. Both of those are not 
often enough that updating firewall filters from active bgp session is 
worth it, its easier to just download list of bogons once/day or once/week 
from web or ftp and update local rules.

Completewhois webpage on how to use our bogon data has all the scripts for
doing bogon firewall filtering on Linux, FreeBSD and OpenBSD machines, 
see http://www.completewhois.com/bogons/using_bogon_lists.htm

---
William Leibzon, Elan Networks:
 mailto: [EMAIL PROTECTED]
Anti-Spam and Email Security Research Worksite:
 http://www.elan.net/~william/emailsecurity/

Re: Bogon filtering (don't ban me)

[Cliff Albert]

On Sun, Dec 05, 2004 at 12:41:32PM -0500, Joe Abley wrote:

> >I have one question regarding the CYMRU bogon route-server. What good 
> >is
> >it if more-specific bogons are going around in the BGP table ?
> 
> With OpenBSD 3.6 running pf and bgpd, you can apply a filter rule to 
> BGP updates received from individual peers which updates a pf radix 
> table with the network received:

Interesting, but no option on Juniper/IOS boxes/foundry boxen. 

> This is an answer that is probably not useful for the average ISP 
> backbone, but I tried it out a week or so ago on my home network 
> firewall/router boxes, and it works very nicely. It's a good solution 
> for (say) an enterprise network whose external traffic falls within the 
> bounds of what an OpenBSD box can handle (or boxes, if you do stateful 
> failover with CARP and pfsync).

Indeed, for such purposes it's a nice solutions.

-- 
Cliff Albert <[EMAIL PROTECTED]>

Re: Bogon filtering (don't ban me)

[Joe Abley]

On 5 Dec 2004, at 06:50, Cliff Albert wrote:
I have one question regarding the CYMRU bogon route-server. What good 
is
it if more-specific bogons are going around in the BGP table ?
With OpenBSD 3.6 running pf and bgpd, you can apply a filter rule to 
BGP updates received from individual peers which updates a pf radix 
table with the network received:

  # team cymru bogon route servers
  group "bogons" {
remote-as 65333
local-address A.B.C.D
multihop 64
announce none
max-prefix 1000
tcp md5sig password "xxsomethingxx"
neighbor E.F.G.H
neighbor I.J.K.L
  }
  # cymru set 65333:888 on bogon routes
  allow from any community 65333:888 set pftable "bogons"
  allow from any community 65333:888 set nexthop blackhole
This allows you to block inbound/outbound packets in the packet filter, 
and not just rely on blackhole routing (I left the "nexthop blackhole" 
policy statement in there to provide some coverage in case I 
accidentally disable pf one day due to caffeine deficiency). The pf 
config bits are:

  table  persist
  # no bogon sources or destinations
  block quick from  to any
  block quick from any to 
This seems to work very nicely, and neatly accommodates the problem of 
what to do with packets which follow more-specific routes of the cymru 
bogon supernets. The rules above would probably need to be loosened 
somewhat for a network which used 1918 addresses and NAT, since the 
1918 addresses are included in the bogon feed.

This is an answer that is probably not useful for the average ISP 
backbone, but I tried it out a week or so ago on my home network 
firewall/router boxes, and it works very nicely. It's a good solution 
for (say) an enterprise network whose external traffic falls within the 
bounds of what an OpenBSD box can handle (or boxes, if you do stateful 
failover with CARP and pfsync).

Joe

RE: Bogon filtering (don't ban me)

[Neil J. McRae]

> Rob,
> 
>   Just thinking out loud, but is there any reason that 
> this route-server methodology couldn't be applied to other 
> 'undesirable'
> destinations, such as the world's top spammers, phishing web 
> sites, etc?
> Maybe break them up into different communities, so 
> subscribers can pick which ones they want to filter. 
> 

Won't work - you assume that the clue level of the netabuser/spammer
is equal to the clue level of an AOL user. 

Neil.
 

Re: Bogon filtering (don't ban me)

[Suresh Ramasubramanian]

Church, Chuck wrote:
	Just thinking out loud, but is there any reason that this
route-server methodology couldn't be applied to other 'undesirable'
destinations, such as the world's top spammers, phishing web sites, etc?
Maybe break them up into different communities, so subscribers can pick
which ones they want to filter. 
You are a few years late with that Idea - Paul Vixie had it first, quite 
some time back.

RE: Bogon filtering (don't ban me)

[Church, Chuck]

Rob,

Just thinking out loud, but is there any reason that this
route-server methodology couldn't be applied to other 'undesirable'
destinations, such as the world's top spammers, phishing web sites, etc?
Maybe break them up into different communities, so subscribers can pick
which ones they want to filter. 


Chuck Church
Lead Design Engineer
CCIE #8776, MCNE, MCSE
Netco Government Services - Design & Implementation Team
1210 N. Parker Rd.
Greenville, SC 29609
Home office: 864-335-9473
Cell: 703-819-3495
[EMAIL PROTECTED]
PGP key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x4371A48D 


-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of
Rob Thomas
Sent: Saturday, December 04, 2004 7:22 PM
To: NANOG
Subject: RE: Bogon filtering (don't ban me)


Hi, Hank.

] I do as well, but does this scale?  Can Team CYMRU handle 2,000 BGP
] sessions?  20K?  200K?   -Hank

We can handle quite a lot of sessions, and already do, thanks to
the distributed nature of the Bogon route-server project.  We
have several routers deployed, and are prepared to deploy more
if necessary.

By the way we recommend that folks peer with at least two of the
Bogon route-servers.

Thanks,
Rob.
-- 
Rob Thomas
http://www.cymru.com
ASSERT(coffee != empty);

Re: Bogon filtering (don't ban me)

[Cliff Albert]

On Sat, Dec 04, 2004 at 06:22:00PM -0600, Rob Thomas wrote:

> ] I do as well, but does this scale?  Can Team CYMRU handle 2,000 BGP
> ] sessions?  20K?  200K?   -Hank
> 
> We can handle quite a lot of sessions, and already do, thanks to
> the distributed nature of the Bogon route-server project.  We
> have several routers deployed, and are prepared to deploy more
> if necessary.
> 
> By the way we recommend that folks peer with at least two of the
> Bogon route-servers.

Hi Rob,

I have one question regarding the CYMRU bogon route-server. What good is
it if more-specific bogons are going around in the BGP table ?

-- 
Cliff Albert <[EMAIL PROTECTED]>


signature.asc
Description: Digital signature

RE: Bogon filtering (don't ban me)

[Rob Thomas]

Hi, Hank.

] I do as well, but does this scale?  Can Team CYMRU handle 2,000 BGP
] sessions?  20K?  200K?   -Hank

We can handle quite a lot of sessions, and already do, thanks to
the distributed nature of the Bogon route-server project.  We
have several routers deployed, and are prepared to deploy more
if necessary.

By the way we recommend that folks peer with at least two of the
Bogon route-servers.

Thanks,
Rob.
-- 
Rob Thomas
http://www.cymru.com
ASSERT(coffee != empty);

RE: Bogon filtering (don't ban me)

[Hank Nussbacher]

On Fri, 3 Dec 2004, Mark Segal wrote:

I do as well, but does this scale?  Can Team CYMRU handle 2,000 BGP
sessions?  20K?  200K?   -Hank

> Then you could also just get a connection to team cymru's bogon servers.
> Works Perfectly for us.  I have been peering with them from our sink
> hole/black hole trigger router, for a while now, and I no longer need to
> manually update the files.
>
> More info here.
> http://www.cymru.com/BGP/bogon-rs.html

Re: Bogon filtering (don't ban me either)

[Jerry Pasker]

On Fri, 3 Dec 2004, Hank Nussbacher wrote:
 "Blocks all IANA reserved IP address blocks"
 The actual doc:

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

Re: Bogon filtering (don't ban me)

[Jon Lewis]

On Fri, 3 Dec 2004, Hank Nussbacher wrote:

> "Blocks all IANA reserved IP address blocks"
>
> The actual doc:
> 

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_

RE: Bogon filtering (don't ban me)

[Mark Segal]

Then you could also just get a connection to team cymru's bogon servers.
Works Perfectly for us.  I have been peering with them from our sink
hole/black hole trigger router, for a while now, and I no longer need to
manually update the files.

More info here.
http://www.cymru.com/BGP/bogon-rs.html

Regards,
Mark

--
Mark Segal 
Director, Network Planning
FCI Broadband 
Tel: 905-284-4070 
Fax: 416-987-4701 
http://www.fcibroadband.com


> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On 
> Behalf Of David Barak
> Sent: December 3, 2004 10:08 AM
> To: J. Oquendo; [EMAIL PROTECTED]
> Subject: Re: Bogon filtering (don't ban me)
> 
> 
> 
> --- "J. Oquendo" <[EMAIL PROTECTED]> 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
> 
> 

Re: Bogon filtering (don't ban me)

[David Barak]

--- "J. Oquendo" <[EMAIL PROTECTED]> 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

Re: Bogon filtering (don't ban me)

[Jeroen Massar]

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



signature.asc
Description: This is a digitally signed message part

Re: Bogon filtering (don't ban me)

[Hank Nussbacher]

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:


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

Re: Bogon filtering (don't ban me)

[Christopher L. Morrow]

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

Re: Bogon filtering (don't ban me)

[william(at)elan.net]

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 . orghttp://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"