D/DoS mitigation hardware/software needed.

Tue Jan 5 05:39:37 UTC 2010

I think you, Roland, and I are all agreeing on the same argument.

The (my) confusion entered with the statement of, "The key is to not be
inline all the time, but only inline *when needed*.
I inferred a topological or physical path change from that.

Redirecting traffic (which is really just an extension of RTBH; a scrubber
destination rather than Null0) is an understandable state.

Rick

On Mon, Jan 4, 2010 at 9:34 PM, Stefan Fouant <sfouant at shortestpathfirst.net
> wrote:

> > -----Original Message-----
> > From: Rick Ernst [mailto:nanog at shreddedmail.com]
> > Sent: Tuesday, January 05, 2010 12:19 AM
> >
> > 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."
>
> Almost all of the scalable DDoS mitigation architectures deployed in
> carriers or other large enterprises employ the use of an offramp method.
> These devices perform a lot better when you can forward just the subset of
> the traffic through as opposed to all.  It just a simple matter of using
> static routing / RTBH techniques / etc. to automate the offramp.
>
> Stefan Fouant, CISSP, JNCIE-M/T
> www.shortestpathfirst.net
> GPG Key ID: 0xB5E3803D
>
>