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