DDOS, IDS, RTBH, and Rate limiting
peter.phaal at gmail.com
Fri Nov 21 16:41:41 UTC 2014
>> Actually, sFlow from many vendors is pretty good (per your points about
>> burstiness and delays), and is good enough for dDoS detection. Not for
>> security forensics, or billing at 99.99% accuracy, but good enough for
>> traffic visibility, peering analytics, and (d)DoS detection.
> Well, if it is available, except hardware limitations, there is second
> software licensing cost. On latest JunOS, for example on EX2200, you need
> to purchase license (EFL), and if am not wrong it is $3000 for 48port units.
> So if only sFlow feature is on stake, it worth to think, to purchase
> or to purchase server.
Juniper no longer charges for sFlow on the EX2200 (as of Junos 11.2):
I am not aware of any vendor requiring an additional license to enable sFlow.
sFlow (packet sampling) works extremely well for the DDoS flood
detection / mitigation use case. The measurements are build into low
cost commodity switch hardware and can be enabled operationally
without adversely impacting switch performance. A flood attack
generates high packet rates and sampling a 10G port at 1-in-10,000
will reliably detect flood attacks within seconds.
For most use cases, it is much less expensive to use switches to
perform measurement than to attach taps / mirror port probes. If your
switches don't already support sFlow, you can buy a 10G capable white
box switch for a few thousand dollars that will let you monitor 1.2
Terabits/sec. If you go with an open platform such as Cumulus Linux,
you could even run your DDoS mitigation software on the switch and
dispense with the external server. Embedded instrumentation is simple
to deploy and reduces operational complexity and cost when compared to
add on probe solutions.
More information about the NANOG