Seeking Feedback on Mitigation of New BGP-driven Attack

Sat May 11 08:53:58 UTC 2019

On 11 May 2019, at 11:29, Job Snijders wrote:

> The paper contained new information for me, if I hope I summarize it 
> correctly: by combining AS_PATH poisoning and botnets, the botnet’s 
> firing power can be more precisely aimed at a specific target.

That's my takeaway; it's utilizing illicit traffic engineering 
mechanisms to explicitly steer DDoS traffic, and peer-locking would 
frustrate this goal.

The authors of the paper should be aware that in large volumetric 
attacks, the natural topological convergence of attack traffic as it 
progresses towards the intended target can fill up peering links, core 
links, et. al., greatly increasing the collateral damage of such attacks 
as bystander traffic traversing those links is crowded out.

We've seen this happen many times over the last couple of decades, it 
isn't new or rare or unique as the paper seems to imply (apologies if 
that is not what the authors intended to convey).  It's such a common 
aspect of DDoS attacks that overloading 'LFA' to try and invent an 
acronym for it (in network engineering terminology, 'LFA' = 'loop-free 
alternate'; see RFCs 5286 & 8518) isn't really necessary or helpful; 
it's actually confusing.

Sometimes attackers consciously choose this as a tactic, sometimes they 
just hurl as much traffic as they can at the target and don't really 
care about the details, as long as it works — which all too often is 
the case when the defenders aren't adequately prepared.

Quantity has a quality all its own. DDoS attacks are attacks against 
capacity and/or state; in this very common scenario, link capacity is 
adversely affected.

The authors of the paper should also understand that commercial DDoS 
mitigation centers are not necessarily topologically adjacent to the 
properties being protected, as they seem to be asserting in the paper 
(again, apologies if this interpretation is incorrect); this is true in 
some models, but in other models they are topologically distant, 
sometimes being one or more ASNs away from said protected properties.

We've observed what appeared to be the deliberate use of relatively 
topologically-adjacent bots and/or reflectors/amplifiers on a couple of 
occasions. We speculate that the attackers in those instances were 
attempting to maximize the amount of traffic-on-target; seeking to avoid 
detection/classification/traceback by avoiding crossing instrumented 
macro-level administrative boundaries (i.e., peering edges, the 
incorrect assumption on the part of the attacker being that all 
operators only instrument said peering edges); and/or to complicate 
diversion into peering edge- or topologically-distant DDoS mitigation 
centers.  To date, we've not encountered illicit traffic engineering 
utilized during an attack, as described in the paper.

While it's recently become trendy in the confidentiality and integrity 
arenas to give various exploits somewhat abstract names, this sort of 
thing isn't really helpful in the availability space, where the specific 
mechanisms and techniques employed matter a great deal to operators 
working in real time to defend against DDoS attacks.  Rather than 
calling this a 'Maestro' attack, which carries no useful intrinsic 
meaning, perhaps an appellation such as 'topological forcing' or 
'traffic steering' would be more appropriate.  As in, 'a 
topologically-forced volumetric DDoS attack' or 'a traffic-steered 
volumetric DDoS attack'.

n.b. — neological acronyms such as as TFVDDoS or TSVDDoS should be 
avoided, as this further unhelpfully fragments the terminology space.

--------------------------------------------
Roland Dobbins <roland.dobbins at netscout.com>