D/DoS mitigation hardware/software needed.
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
> 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
> > 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
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."
More information about the NANOG