rewars/benefit bogon filters

Mon Jul 8 14:58:48 UTC 2002

jnelson wrote:

> Bogon lists? How effective are they? DDoS scripts are abundant to
> those who seek them. Am I going to reep any rewards by taxing my
> edge routers an extra 25 lines of ACL?

If you're using 'access-list compiled', you're not adding any load
whatsoever, since there should be an existing and extremely important
access list there denying all incoming over your edge (peer || transit)
links for your own network blocks and single-homed customers [possibly
multi-homed ones as well, that's more debatable though], to prevent
spoofing.

Warning though, there appears to be a bogus bogon in the current list.
See my post of a few minutes back.

> Who out there has some stats I can look at?

Unfortunately nothing useful.  The usefulness of the bogon lists is
rather proportional to how badly configured people's networks are
though.  If everyone was using unicast verify reverse-path or
explicit ingress filtering on their customers and applying egress
filtering where appropriate[1] then the bogon list would be pointless.
But we all know that's not happening.

> And by posting this, am I diminishing its value?

Yes, although only slightly.

I never publically post full details of how I protect the IRC server
on our network that was DDoS'd a number of times, since posting all
the details would negate about half the defences (the defences are
based on knowing the attacks, but if the attackers knew the defences,
and are sufficiently skilled, they could most likely find a way work
around them; and the latest attacks [that we noticed at least - some
months back now - we added more defences after them and every now
and then I notice "oh someone tried to attack the IRC server again"]
were based on knowing that we use Cisco routers which can be
overloaded in a particular way, and attacking the infrastructure
rather than the IRC server).

David.

[1] egress filtering can be a pain on upstream links.  If the upstream
    lets you off lightly by not ingress filtering you, sometimes there's
    a reason to not egress filter.  The most common one is this:

       say you have a customer who advertises x.x.0.0/16 to you - a
       large multinational.  but an upstream advertises x.x.x.0/24 to
       you.  now your peer, an ISP who can't afford to run a full table
       (in Australia a lot of ISPs run the ~6000 route Australian BGP
       table or ~2000 route "Australian peering" BGP table) sees
       x.x.0.0/16 and quite legitimately routes traffic for x.x.x.0/24
       to you, not knowing of the off-shore route for x.x.x.0/24.
       if you egress filter, you break the affected peer(s) ability to
       access off-shore subnets of x.x.x.0/24.  note you can avoid them
       abusing other routes in your network by not having a default
       route in your peering router, but still let this traffic pass
       unharmed.

       this is actually a very common problem in Australia with mid-sized
       ISPs and can't simply be fixed by "fix the (customer || peer)".
       there is a solution which is based on MPLS VPNs (having the internet
       as one MPLS VPN and a separate MPLS VPN for peers, with defined
       route/traffic exchange between the VPNs) but compilicates
       trouble-shooting of the network.