On Jan 5, 2010, at 12:19 PM, Rick Ernst wrote:
> 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 strongly disagree with this, except for properties which are under sustained attack 24/7. If one has constructed one's detection/classification/traceback/mitigation system properly, one always knows at a glance the state of the system.
Otherwise, whenever there's any issue whatsoever with the properties under protection, one must try and prove a negative - i.e., that the mitigation solution isn't causing the problem. Happens every time, heh.
> 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.
Not if it's legit, you don't, or if the attacker is spoofing, say, the IPs of the root nameservers, or the TLDs, or an e-commerce/supply-chain partner . . . or if the attack is originating behind a broadband mega-proxy, or a mobile CGN.
;>
Also, if you've a variety of tools at your disposal, like S/RTBH and/or flow-spec, and then more sophisticated (and expensive) tools like IDMS, the freedom to choose the least intrusive/most situationally-appropriate tool to mitigate a given attack is essential for resource preservation and the ability to oversubscribe the more sophisticated tools.
> 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."
Absolutely, which is where the situationally-specific selection of tools/modes comes into play.
-----------------------------------------------------------------------
Roland Dobbins <rdobbins at arbor.net> // <http://www.arbornetworks.com>
Injustice is relatively easy to bear; what stings is justice.
-- H.L. Mencken