Seeking Feedback on Mitigation of New BGP-driven Attack
Hello, Our research lab at the University of Tennessee (volsec.org) has recently completed a study on channeling link-flooding attack (transit link DDoS) flows via BGP poisoning: the Maestro attack. We are seeking feedback on mitigation (see below). A brief summary from the abstract: "Executed from a compromised or malicious Autonomous System (AS), Maestro advertises specific-prefix routes poisoned for selected ASes to collapse inbound traffic paths onto a single target link. A greedy heuristic fed by publicly available AS relationship data iteratively builds the set of ASes to poison. Given a compromised BGP speaker with advantageous positioning relative to the target link in the Internet topology, an adversary can expect to enhance flow density by more than 30%. For a large botnet (e.g., Mirai), the bottom line result is augmenting a DDoS by more than a million additional infected hosts. Interestingly, the size of the adversary-controlled AS plays little role in this amplification effect. Devastating attacks on core links can be executed by small, resource-limited ASes." We are seeking feedback from operators on the attack and the proposed mitigations we have identified. While we have worked with our campus BGP operators, we are reaching out to the broader community for additional insights. Other than general notes/comments, we have two specific questions that we would like to include feedback for in the final paper soon to be submitted: 1) Do you already filter poisoned/path prepend advertisements? This would mitigate the attack. 2) After seeing this attack, would you consider adding poison filtering or some other Day mitigation? The preprint is available at: tiny.utk.edu/maestro. See Section 7 on defenses. Please reply with any thoughts. Thank you in advance for comments, insight, and general feedback. Best, Tyler McDaniel, Jared Smith, and Max Schuchard UT Computer Security Lab volsec.org
Dear Jared, This was a very interesting read. Thank you for sharing it with us. 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. Can you clarify what the definition of a “link” is? Is it the logical interconnection between two ASNs (many pairs of ASNs interconnect in many places), or is it a reference to a specific physical interconnection between two routers, each in a different ASN? The paper mentions that if the top 20 transit-free (“tier-1”) networks protect each other against poisoning, the Maestro attack is drastically reduced in effectiveness. I have good news, amongst this set of networks, there already is a widely deployed anti poisoning mechanism, sometimes referred to as “Peerlock”. https://www.youtube.com/watch?v=CSLpWBrHy10 / https://www.nanog.org/sites/default/files/Snijders_Everyday_Practical_Bgp.pd... . I think this paper suggests the Peerlock practice should be promoted more, and perhaps automated. Kind regards, Job On Fri, 10 May 2019 at 15:27, Jared Smith <jms@vols.utk.edu> wrote:
Hello,
Our research lab at the University of Tennessee (volsec.org) has recently completed a study on channeling link-flooding attack (transit link DDoS) flows via BGP poisoning: the Maestro attack. We are seeking feedback on mitigation (see below). A brief summary from the abstract:
"Executed from a compromised or malicious Autonomous System (AS), Maestro advertises specific-prefix routes poisoned for selected ASes to collapse inbound traffic paths onto a single target link. A greedy heuristic fed by publicly available AS relationship data iteratively builds the set of ASes to poison. Given a compromised BGP speaker with advantageous positioning relative to the target link in the Internet topology, an adversary can expect to enhance flow density by more than 30%. For a large botnet (e.g., Mirai), the bottom line result is augmenting a DDoS by more than a million additional infected hosts. Interestingly, the size of the adversary-controlled AS plays little role in this amplification effect. Devastating attacks on core links can be executed by small, resource-limited ASes."
We are seeking feedback from operators on the attack and the proposed mitigations we have identified. While we have worked with our campus BGP operators, we are reaching out to the broader community for additional insights.
Other than general notes/comments, we have two specific questions that we would like to include feedback for in the final paper soon to be submitted:
1) Do you already filter poisoned/path prepend advertisements? This would mitigate the attack.
2) After seeing this attack, would you consider adding poison filtering or some other Day mitigation?
The preprint is available at: tiny.utk.edu/maestro. See Section 7 on defenses.
Please reply with any thoughts. Thank you in advance for comments, insight, and general feedback.
Best, Tyler McDaniel, Jared Smith, and Max Schuchard UT Computer Security Lab volsec.org
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@netscout.com>
participants (3)
-
Dobbins, Roland -
Jared Smith -
Job Snijders