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@arbor.net>