WANTED: ISPs with DDoS defense solutions

Tue Aug 5 06:13:08 UTC 2003

On Tue, 5 Aug 2003, Paul Vixie wrote:

>
> chris at UU.NET ("Christopher L. Morrow") writes:
>
> > There are many cases in which the backbone can't determine the 'proper'
> > traffic an edge is sending in.
>
> i'd like to discuss these, or see them discussed.  networks have edges,
> even if some networks are "edge networks" and some are "backbone networks."
> bcp38 talks about various kinds of "loose" rpf, for example not accepting
> a source for which there's no corresponding nondefault route.

Sure, rpf (or something akin to it) is included in BCP38... though there
are plenty of equipment vendors who's equipment isn't capable of
performing even loose-rpf :( Some folks are saddled with such hardware.
However, at the lan edge, almost every piece of hardware is capable of
filtering with a very simple acl (or urpf even in strict mode). The
default configuration placed by CPE users should have this included. This
is the right place for these restrictions, beyond the lan edge the
decisions about routing become much more complex.

>
> >                             Not to mention the problems of filtering on
> > an edge device with 100's or 1000's of interfaces. The proper and simple
> > place for this filtering  is as close to the end device as possible.
> > Backbones just aren't made to filter traffic, edge networks are.
>
> so, the problem is transitive.  you might have a multihomed customer whose

Yes, its transitive.

>
> but they might have the same situation with their downstream.  and you're
> not requiring them to do edge filtering as a contract/peering term, nor are
> you requiring them to require their downstreams to do so.  this means the

Certianly.. I don't write contracts or make sales... though I'm sure
someone in the sales department, or likely 'contracts' or 'legal' would be
happy to entertain this idea. I can say that the technology is, and has
been for 2 years, included in basic customer CPE configs when they are
sent out by our install group. (for UUNET atleast) Other providers might
do the same, I've got little visibility into that arena.

> problem goes from "transitive" to "laundered" in about one AS hop or so.  i
> don't consider this a healthy situation, and i'd like to hear you list
> the kinds of rpf you know of and why none can be used on a "backbone".

1) by access-list (strict this is called by some?)
ip verify unicast reverse-path <100-199>

without knowing all networks the customer has this has problems :( you
don't HAVE to know all networks your customer owns, some they might not
want transiting your network :(

2) by interface   (strict I'd call this too)
ip verify unicast source reachable-via rx

This has the same problems as 1... again, perhaps your customer doesn't
want to return transit traffic across your network for this?

3) loose mode
ip verify unicast source reachable-via any

This is more workable, though some providers use 1918 space internally so
this won't help these networks, nor will it help if you are using that
dead ip space for other purposes :( It's helpful for blackholing sources
and getting backscatter though :)

Note, all urpf have the same problems on some platforms, places where the
urpf is done as a process-switched solution are a problem (e0 cards on
cisco 12000's for example). There are still ALOT of problematic hardware
platforms out there, and as near as I can tell this is only really
supported on cisco and juniper gear, no?

-Chris