[address-policy-wg] New Draft Document: De-boganising New AddressBlocks

Rob Thomas wrote:
> 
> Hi, team.
> 
> ] Andre is right, the best solution is definitely not to filter bogons.
> 
> Best solution for what problem, exactly?  :)

That is the biggest question.  It seems to be a moving target.  The
first problem mentioned was nasty spammers announcing prefixes from
IANA reserved netblocks.  Now you open a second one with stating that
address spoofing from bogon ranges is a problem.

> Bogon filtering does help, though it can be accomplished in a variety
> of ways (e.g. bogon route-servers, ACLs, uRPF with prefix filtering).

Positive bogon filtering is exactly the wrong thing to do.  It simply
doesn't scale.  You don't want to get packets with non-routed source
addresses.  This again is very much different from bogons.  There are
many prefixes out of the allocated netblocks which are not routed in
the global routing system.  The only real fix you apply here is to
check the source address of a packet if it is routeable.  If not, just
drop it.  That alone is saving you any traffic from any kind of bogus
prefix or netblock.  And the best of it is it automagically takes care
of adjusting to new netblocks without any operator invention!

Summary: Bogon filtering based on the IANA reserved listings is very
much bogus in itself.

> Take a peek at my study entitled "60 Days of Basic Naughtiness" for
> some data points on bogon address usage.
> 
>    <http://www.cymru.com/Presentations/60Days.zip>
>    <http://www.cymru.com/Presentations/60Days.ppt>
> 
> Others see more or less of this depending on what they host or
> transit.  One thing we have seen in our darknet monitoring is a
> decrease in the use of bogon source addresses.  Why?  Because they
> are less effective (thankfully).  Ah, but read on!

I'd say you see less bogon source addresses because there are less...
The RIRs have been opening a couple of fresh /8s recently.

> Does this *solve* the problems of DDoS, hacking, scanning?  No, of
> course not.  The miscreants have multiple methods in their toolkits,
> with spoofing being only one.  In fact spoofing applies to allocated
> and routed space as much as it applies to unallocated (aka bogon)
> space.  What we are attempting to do is to reduce the effectiveness
> of one particular set of badness.

Your and some others problem is using/promoting the wrong solution
to the [right]* problem.

[]* depending on what the problem de jour is.

> Defense in depth works, and every little bit helps.  Just as many
> folks do not rely on a single provider for Internet access, we
> shouldn't rely on a single method to mitigate or block malevolent
> flows.

Yes, I fully agree.  But do it really right.  Two wrongs don't make
a right.

> I love the idea of the RIRs and IANA providing the service!  We at
> Team Cymru are happy to help them in any way towards that goal.
> Once those mechanisms are in place and tested, we're happy to turn
> down our service in deference to their authoritative service.  That
> is a ways off, I suspect, so don't take that as a formal statement
> or plan.  :)

There is absolutely no service for the RIRs or IANA to provide.  You
have got all tools you need already.  If the source address is not
routed, then don't route it.  Very easy, very fast, very stable, no
maintainance overhead, nothing that can go wrong.  Just perfect.

-- 
Andre