D/DoS mitigation hardware/software needed.

Rick Ernst nanog at shreddedmail.com
Mon Jan 4 23:19:16 CST 2010


On Mon, Jan 4, 2010 at 9:08 PM, Dobbins, Roland <rdobbins at arbor.net> wrote:

>
> On Jan 5, 2010, at 12:05 PM, Rick Ernst wrote:
>
> >
> > A solution preferably that integrates with NetFlow and RTBH.  An in-line
> solution obviously requires an appliance, or at least special/additional
> hardware.
>
> The key is to not be inline all the time, but only inline *when needed*.
>  This removes operational complexity, provides the ability to oversubscribe,
> and simplifies the routine troubleshooting matrix.
>


I'd argue just the opposite.  If your monitoring/mitigation system changes
dependent on the situation (normal vs under attack), you are adding
complexity to the system.  "What mode is the system in right now? Is this
customer having connectivity issues because of a state change in the
network? etc."



>
> > I'm looking at taking the first whack at immediate mitigation at the
> border/edge (upstream) via uRPF and RTBH.
>
> Good plan.
>
> > Additional mitigation would be  via manual or automatic RTBH or
> security/[email protected] involvement with upstreams.
>
> Automagic is generally bad, as it can be gamed.
>

I know you said "generally", but if I'm seeing 200Kpps from a.b.c.d, I don't
care if a.b.c.d is spoofed. I want the traffic blocked from the guts of my
network.

Note that my original question was in the context of "a D/DoS composed of
lots of itty-bitty packets".  Other attack mechanisms do not necessarily
lend themselves to "chop 'em off at the knees."
Rick



More information about the NANOG mailing list