DDoS auto-mitigation best practices (for eyeball networks)

Sun Sep 20 01:22:22 UTC 2015

On 20 Sep 2015, at 2:54, Frank Bulk wrote:

> - minimum traffic volume before responding (for volumetric attacks)
> - minimum time to wait before responding

These are situationally-specific.

> - filter percentage: 100% of the traffic toward target (or if 
> volumetric,
> just a certain percentage)?

If one has flowspec capabilities, mitigating only the attack traffic is 
preferred, if at all possible.  If one only has S/RTBH, blocking the 
attack sources is preferred, if at all possible.

Some operators resort to D/RTBH (thereby completing the DDoS) because 
they don't have layer-4 granularity in their mitigation tools (e.g., 
flowspec), or even if they have S/RTBH, the number of sources can be 
daunting in relation to their hardware capabilities.  I'm not a big fan 
of this approach, as it completes the DDoS on the victim, but understand 
why some operators do this.

> - time before mitigation is automatically removed

This is situationally-specific.

> - and if the attack should recur shortly thereafter, time to respond 
> and remove again

This is situationally-specific.  Some operators keep track of the 
frequency, and will 'fire' customers who're attack-magnets.  I'm not a 
big fan of this approach, either, but understand why some operators do 
it (simple economics).

> - use of an upstream provider(s) mitigation services versus one's own 
> mitigation tools

This is situationally-specific.  Some operators take advantage of these 
services when on-offer.

> - network placement of mitigation (presumably upstream as possible)

Peering/transit edges, generally.  Some do it on upstream networks which 
provide such a service, as you indicated.

> - and anything else

There's no one-size-fits-all answer for most of these questions; your 
capabilities and tolerances may be very different from those of another 
operator.  Network infrastructure-based techniques, such as S/RTBH, 
D/RTBH, and flowspec are generally what's used in these situations, in 
addition to QoS (see below).

A great deal (not all) of the operationally-significant attacks against 
individual broadband users these days seem to be UDP 
reflection/amplification attacks.  Policing non-timesync ntp at one's 
edges via QoS is pretty straightforward and minimizes the risk of 
overblocking, as there's a packet-size to use as an additional 
classifier beyond protocol/port.  Some operators, as Jared Mauch has 
mentioned here previously, are policing common UDP port-pairs used in 
other flavors of UDP reflection/amplification attacks at their edges, as 
well (Jared is pleased with the results on his network).  It might be 
possible to get this sort of thing instituted on one's upstreams.

-----------------------------------
Roland Dobbins <rdobbins at arbor.net>