Exactly what I have been doing for last week 2 weeks now.
Thanks,
Majid
This is a multi-part message in MIME format.
Have fun 
I hate to say it, but that is the only way.
You aren't dealing with a single bogon blocking list, you're dealing with a
whole lot of providers who are way behind the times and you just have to go on
contacting them one at a time.
srs
Its not even just providers. If it were, it'd be relatively easy to just
find and call each NOC. You're likely to have bogon issues with few large
providers. It's mostly smaller providers and end user networks...some of
which are quite large or high profile.
Do what I did and give people a way to test connectivity from both
affected and unaffected space and setup a 'hall of shame' page listing the
IPs/networks that are behind broken filters.
If someone will lend me appropriate /24's, I'll copy 69box.atlantic.net
into 70box, 71box, etc. and come up with a large (fairly comprehensive)
list of IPs behind broken bogon filters.
Can someone identify the *benefits* of using bogon lists for unallocated
space? It appears that it only hurts connectivity, but does not help in
any significant way to enhance security.
Possibly, whoever are the vendors of software that recommends this
practice (and authors of security handbooks) should be show the error of
their ways?
-alex
alex@pilosoft.com wrote:
Can someone identify the *benefits* of using bogon lists for
unallocated space? It appears that it only hurts connectivity, but
does not help in any significant way to enhance security.Possibly, whoever are the vendors of software that recommends this
practice (and authors of security handbooks) should be show the error
of their ways?
Is this where we restart the BCP38 thread and then argue that if everybody implemented BCP38, people wouldn't need to use this?
srs
Can someone identify the *benefits* of using bogon lists for unallocated
space? It appears that it only hurts connectivity, but does not help in
any significant way to enhance security.
It makes people feel like they're more secure. It may cut down slightly
on junk traffic entering their networks, but I suspect thats an
insignifigantly small amount / benefit.
Possibly, whoever are the vendors of software that recommends this
practice (and authors of security handbooks) should be show the error of
their ways?
Unfortunately, there are many sources that advocate/demonstrate how to do
these filters, some of which still have their examples out of date wrt
current IANA assignments. The problem isn't so much the idea, but the
implementation. Static unmaintained filters pretty much guaranteed to
become a problem at some point.
And yeah, if nobody could spoof, and everyone filtered customer BGP
announcements, there'd be no need at all (not that there really is one
now) for these filters.
I dare to say that even without wholesale BCP38 implementation, benefit of
bogon-filtering unallocated space is tiny compared to cost of lost
connectivity due to the filters that aren't updated.
-alex
> Its not even just providers. If it were, it'd be relatively easy to
> just find and call each NOC. You're likely to have bogon issues with
> few large providers. It's mostly smaller providers and end user
> networks...some of which are quite large or high profile.
>
> Do what I did and give people a way to test connectivity from both
> affected and unaffected space and setup a 'hall of shame' page listing
> the IPs/networks that are behind broken filters.
Can someone identify the *benefits* of using bogon lists for unallocated
space? It appears that it only hurts connectivity, but does not help in
any significant way to enhance security.
It might be a way to proactively keep your part of the network 'cleaner'
than the other parts... 'managed' properly and 'updated' regularly (when
changes dictate an update is required) it might even be seemless to your
userbase.
The devil here is, as always, in the details. Once you move beyond some
number of devices or acls or 'parts', making changes on a wide scale and
keeping things up to date becomes more difficult. Change management and
the number of hands in the pot seem to make these things much more
challenging.
Possibly, whoever are the vendors of software that recommends this
practice (and authors of security handbooks) should be show the error of
their ways?
if they did they'd lose part of their punch 
And lose some of their
readerbase... and who'd call you to complain?
It makes people feel like they're more secure.
aka "airport security". Inconvenience the users, and achieve nothing
useful.
It may cut down slightly on junk traffic entering their networks,
but I suspect thats an insignifigantly small amount / benefit.
s/junk//
Why not just block 0/0 and be done with it?
> > Possibly, whoever are the vendors of software that recommends this
> > practice (and authors of security handbooks) should be show the error
> > of their ways?
Never heard of a particular software vendor nor security author
disctating it, but then perhaps that's because some of us set
things up based on real experience and don't always see those
who come after.
I dare to say that even without wholesale BCP38 implementation,
benefit of bogon-filtering unallocated space is tiny compared to
cost of lost connectivity due to the filters that aren't updated.
That's a change mgmt complaint, not a bogon filter complaint. There
are many many many of us who experience concrete benefits and zero
problems WRT bogon filters. I suspect those stating there's no
benefit never actually used them.
Vote with your wallet, etc etc.
I've never been a fan of bogon packet filtering (bogon route filtering is more useful), but it occurs to me that it's probably better for us network opertors to do this rather than have each and every firewall admin do it for themselves.
I.e., in networks that do proper BCP38 filtering towards their customers and bogon filtering on the edges to other networks, customers will never see packets from bogon sources, making it unnecessary for them to filter those themselves and thereby improving the plight of those who get address space that was recently allocated to a RIR by the IANA.
>> Can someone identify the *benefits* of using bogon lists for
>> unallocated
>> space? It appears that it only hurts connectivity, but does not help
>> in
>> any significant way to enhance security.> It might be a way to proactively keep your part of the network
> 'cleaner'
> than the other parts... 'managed' properly and 'updated' regularly
> (when
> changes dictate an update is required) it might even be seemless to
> your
> userbase.> The devil here is, as always, in the details. Once you move beyond some
> number of devices or acls or 'parts', making changes on a wide scale
> and
> keeping things up to date becomes more difficult.I've never been a fan of bogon packet filtering (bogon route filtering
is more useful), but it occurs to me that it's probably better for us
network opertors to do this rather than have each and every firewall
admin do it for themselves.
be it 'route' filtering or packet filtering' the end result is the same in
this case, eh? (no route back means packet drop). Being the internet's
firewall is a dangerous proposition, ask those that dropped ICMP on large
backbones during welchia...
Anyway, the problem from the requestor is only going to be remedied by him
contacting all the 'bad' people, or their users contacting their providers
to get to his interesting content Another poster pointed out that
static filters are just a bad plan, that reminds me I need to automate
updates to the filters on some other things I'll bet I'm blocking the
original poster's access to some places too
I.e., in networks that do proper BCP38 filtering towards their
customers and bogon filtering on the edges to other networks, customers
will never see packets from bogon sources, making it unnecessary for
them to filter those themselves and thereby improving the plight of
those who get address space that was recently allocated to a RIR by the
IANA.
To some extent this is correct, but these users really need to learn to
effectively protect themselves. In the long term atleast.
http://puck.nether.net/~jared/papers/69-paper.html
I can rewrite this slightly and post it on slashdot and other
places again..
- jared
I've never been a fan of bogon packet filtering (bogon route filtering
is more useful), but it occurs to me that it's probably better for us
network opertors to do this rather than have each and every firewall
admin do it for themselves.
be it 'route' filtering or packet filtering' the end result is the same in
this case, eh?
Well, with uRPF you can turn route filtering into packet filtering, but otherwise they're different. There is nothing bad that a packet with a bogon source can do that a packet with a non-bogon source can't do too. But spammers and the like can hijack unused address space to do untracable nastiness if these routes aren't filtered.
Being the internet's firewall is a dangerous proposition, ask those that dropped ICMP on large backbones during welchia...
There are two big difference between filtering packets with bogon sources and firewalling in general: the bogon stuff can be done just by looking at the source address, and these packets never serve any useful purpose, so they can be filtered anywhere, anytime without problems. (While with ICMP some crazy people actually like to get the port unreachables rather than having to wait for a timeout, or for PMTUD to work.)
To some extent this is correct, but these users really need to learn to
effectively protect themselves. In the long term atleast.
Never teach a pig to sing: it wastes your time and annoys the pig.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
> If someone will lend me appropriate /24's, I'll copy
> 69box.atlantic.net into 70box, 71box, etc. and come up with a
> large (fairly comprehensive) list of IPs behind broken bogon
> filters.I can rewrite this slightly and post it on slashdot and
other places again..
I think it would be useful. The "Bogon Team" implemented several
changes after 69/8 to make "change management" easier. This included
maintain objects at Merit RADB, RIPE NCC RADB, and a way to track via
DNS (see the details on http://www.cymru.com/Bogons/index.html).
Of course the biggest service CYRMU added to help people with "change
management" was the Bogon Route Server
(http://www.cymru.com/BGP/bogon-rs.html).
So with all these "change management" tools done for the operations
community, it looks like we still need some "policing" service. Note
from mine and Hank's "CIDR Police" Experiment, we know that have a
"list of shame" is not effective. The only way it works is if you
have people who act as 'police,' use the list of shame, and knock on
people's door. 90% of the time, people eventually respond and make
the changes. But the impact only remains as long as you have people
to go knocking on the doors.
I've always wondered whether said pig needs pilot training when it gets
the RFC1925 rocket packs attached.....
The lack of adequate pilot and flight safety training for the victims(*) is a
deployment issue for any reasonable firewall/security scheme - either it really
*does* have to be "victim is along for the ride", or we're going to be sitting in
the control tower talking them through the landing....
(*) victims - sometimes the users, sometimes the ISP....
I'll write up a new version of this. Can those of you that
are having problems in the 70/8 and 71/8 space write me a snippet
in private email saying how this is impacting them? One paragraph
please, also include your full name and employer or whom you
represent.
this way i can include the impact seen in it so people *may*
wake up and realize the impact of lack of maintence of these filters.
- jared