[120825] in North American Network Operators' Group
Re: D/DoS mitigation hardware/software needed.
daemon@ATHENA.MIT.EDU (Rick Ernst)
Tue Jan 5 00:42:29 2010
In-Reply-To: <005101ca8dc8$c418dda0$4c4a98e0$@net>
Date: Mon, 4 Jan 2010 21:39:37 -0800
From: Rick Ernst <nanog@shreddedmail.com>
To: Stefan Fouant <sfouant@shortestpathfirst.net>
Cc: NANOG list <nanog@nanog.org>
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
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@shortestpathfirst.net
> wrote:
> > -----Original Message-----
> > From: Rick Ernst [mailto:nanog@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
>
>
