Dear NANOG members, I am a senior Ph.D. student at the University of Oregon (UO). We are seeking your help to understand DDoS mitigation techniques toward volumetric link flooding attacks. With our preliminary survey so far, DDoS mitigation approaches in the real world include 1) DDoS mitigation service providers (e.g., Akamai, Cloudflare), 2) Remotely-Triggered Black Hole (RTBH), 3) BGP FlowSpec, and 4) direct contact with upstream providers for traffic filtering. We also realize the traffic filtering space in hardware routers is limited as router vendors use CAM/TCAM to implement packet matching and access control lists at line rate. We believe that many routers on the Internet today may not have the necessary capacity to perform fine-grained traffic filtering, especially when facing a large-scale DDoS attack with or without IP spoofing. To this end, we ask that you kindly participate in our short and anonymized survey at https://oregon.qualtrics.com/jfe/form/SV_03aPeCIGiyUt6st. The purpose of this survey is to understand 1) the frequency and scale of DDoS attacks, 2) the DDoS mitigation methods commonly used by the edge network operators, and 3) the capability of the mitigation methods. We plan to collect responses for three months, and we will report the survey result back to you. This study is part of our on-going research project, the Catch-22 attack, and you can view our poster paper at https://luminshi.github.io/assets/papers/catch22.pdf. Regards, Lumin Shi Center for Cyber Security and Privacy <https://ccsp.uoregon.edu/> University of Oregon
Peace, On Tue, Jan 14, 2020, 10:22 PM Lumin Shi <luminshi@cs.uoregon.edu> wrote:
With our preliminary survey so far, DDoS mitigation approaches in the real world include 1) DDoS mitigation service providers (e.g., Akamai, Cloudflare), 2) Remotely-Triggered Black Hole (RTBH), 3) BGP FlowSpec, and 4) direct contact with upstream providers for traffic filtering.
What about customer-premises equipment, like Arbor or Radware? -- Töma
Hi Töma, Thank you for the feedback (that is a good point)! In our study, we lump both cloud/anycast-based and customer-premise mitigation solutions together as solutions from DDoS mitigation service providers. And we believe if you are well-provisioned with such equipment, you are not subject to the attack that we mentioned in the end of the original email. Best, Lumin On Tue, Jan 14, 2020 at 12:37 PM Töma Gavrichenkov <ximaera@gmail.com> wrote:
Peace,
On Tue, Jan 14, 2020, 10:22 PM Lumin Shi <luminshi@cs.uoregon.edu> wrote:
With our preliminary survey so far, DDoS mitigation approaches in the real world include 1) DDoS mitigation service providers (e.g., Akamai, Cloudflare), 2) Remotely-Triggered Black Hole (RTBH), 3) BGP FlowSpec, and 4) direct contact with upstream providers for traffic filtering.
What about customer-premises equipment, like Arbor or Radware?
-- Töma
Peace, On Wed, Jan 15, 2020, 2:35 AM Lumin Shi <luminshi@cs.uoregon.edu> wrote:
Thank you for the feedback (that is a good point)!
In our study, we lump both cloud/anycast-based and customer-premise mitigation solutions together as solutions from DDoS mitigation service providers. And we believe if you are well-provisioned with such equipment, you are not subject to the attack that we mentioned in the end of the original email.
You may want to consider the next email in the thread, sent by Roland Dobbins. It may help to advance your research from the practical point of view. In any case, feel free to contact me directly if you have any questions or concerns, though I feel your research is sorta too early to reach NANOG or the likes. -- Töma
On 14 Jan 2020, at 1:56, Lumin Shi wrote:
We believe that many routers on the Internet today may not have the necessary capacity to perform fine-grained traffic filtering, especially when facing a large-scale DDoS attack with or without IP spoofing.
There are literally decades of information on these topics available publicly. Router and switch ACLs (both static and dynamically-updated via flow spec), D/RTBH, S/RTBH, intelligent DDoS mitigation systems (IDMSes; full disclosure, I work for a a vendor of such systems), et. al. are all used to mitigate DDoS attacks. Your comments about routers not having the 'capacity' (I think you mean capability) to filter traffic due to a lack of granularity are demonstrably inaccurate. While it's always useful to be able to parse into packets as deeply as practicable in hardware, layer-4 granularity has been and continues to be useful in mitigating DDoS attacks on an ongoing basis. Whether or not the traffic in question is spoofed is irrelevant, in this particular context. Here are some .pdf presentations on the general topic of DDoS mitigation: <https://app.box.com/s/4h2l6f4m8is6jnwk28cg> There are lots of write-ups and videos of presentations given at conferences like NANOG which address these issues; they can easily be located via the use of search engines. -------------------------------------------- Roland Dobbins <roland.dobbins@netscout.com>
Hi Roland, Thank you for your comments and resources. I think you may have misunderstood our email (we could've made our email more clear -- apologies). The following is our explanation if we interpreted your email correctly. What we meant by "may not have necessary capacity" is that routers do not have enough CAM/TCAM space to deploy/install ACLs, BGP FlowSpec rules against large-scale DDoS attacks without 1) incurring major collateral damage (e.g., deploy /16 source-based rules instead of /32 so that more DDoS traffic can be filtered while using less CAM/TCAM space), or 2) performance penalties that are introduced by deploying more filters than a router's data plane can support (i.e., data plane to control plane I/O limitation). We believe DDoS mitigation based on layer 3 and/or 4 information can be fine-grain. As a matter of fact, when we referred to fine-grained traffic filtering in our original email, we meant DDoS mitigation based on layer 3 and 4 information. I hope this addresses your concerns. Best, Lumin On Tue, Jan 14, 2020 at 2:31 PM Dobbins, Roland <Roland.Dobbins@netscout.com> wrote:
On 14 Jan 2020, at 1:56, Lumin Shi wrote:
We believe that many routers on the Internet today may not have the necessary capacity to perform fine-grained traffic filtering, especially when facing a large-scale DDoS attack with or without IP spoofing.
There are literally decades of information on these topics available publicly. Router and switch ACLs (both static and dynamically-updated via flow spec), D/RTBH, S/RTBH, intelligent DDoS mitigation systems (IDMSes; full disclosure, I work for a a vendor of such systems), et. al. are all used to mitigate DDoS attacks.
Your comments about routers not having the 'capacity' (I think you mean capability) to filter traffic due to a lack of granularity are demonstrably inaccurate. While it's always useful to be able to parse into packets as deeply as practicable in hardware, layer-4 granularity has been and continues to be useful in mitigating DDoS attacks on an ongoing basis. Whether or not the traffic in question is spoofed is irrelevant, in this particular context.
Here are some .pdf presentations on the general topic of DDoS mitigation:
<https://app.box.com/s/4h2l6f4m8is6jnwk28cg>
There are lots of write-ups and videos of presentations given at conferences like NANOG which address these issues; they can easily be located via the use of search engines.
-------------------------------------------- Roland Dobbins <roland.dobbins@netscout.com>
On 15 Jan 2020, at 6:37, Lumin Shi wrote:
What we meant by "may not have necessary capacity" is that routers do not have enough CAM/TCAM space to deploy/install ACLs, BGP FlowSpec rules against large-scale DDoS attacks without 1) incurring major collateral damage (e.g., deploy /16 source-based rules instead of /32 so that more DDoS traffic can be filtered while using less CAM/TCAM space), or 2) performance penalties that are introduced by deploying more filters than a router's data plane can support (i.e., data plane to control plane I/O limitation).
We can agree that nothing is infinite, nothing is free. TANSTAAFL. Nevertheless, despite the fact that TCAM space is neither infinite nor free, and while they aren't free in terms of performance, ACLs — whether installed statically or dynamically via flowspec rules — are used every second of every minute of every hour of every day to mitigate large-scale DDoS attacks on large networks. Features do indeed contend for TCAM space, and of course operators want as much as is practicable. LOU expansion can affect how much TCAM space a given ACL consumes on a given ASIC/linecard/platform. On hardware platforms from major vendors, TCAM space can often be carved to allocate features, and operators do this in order to allocate more space for ACL stanzas, or flowspec rules, or whatever. However, as demonstrated above, your thesis as stated is overbroad and directly contradicted by operational reality. A key point is that operators must understand the performance envelopes and characteristics of their infrastructure gear, so that they can avoid causing issues by overtaxing it. Here is a particular .pdf presentation which discusses issues of this nature: <https://app.box.com/s/xznjloitly2apixr5xge> You are not wrong to posit that hardware capacity and capabilities are neither infinite nor free. But that has been well-understood in the operational community for a long time, and is neither novel nor particularly insightful. It certainly isn't a topic that one would imagine merits formal academic investigation, given that it's a commonplace amongst those involved in the operational community. It just isn't an interesting topic, in and of itself. Something broader in terms of operator perception of gaps across the gamut of required DDoS mitigation capabilities at scale would potentially be of more value. Please feel free to contact me 1:1 to discuss further, if you like. -------------------------------------------- Roland Dobbins <roland.dobbins@netscout.com>
Where can we find public information on how to use S/RTBH and which providers support it. Thanks Jean On 2020-01-14 17:31, Dobbins, Roland wrote:
There are literally decades of information on these topics available publicly. Router and switch ACLs (both static and dynamically-updated via flow spec), D/RTBH, S/RTBH
On 20 Jan 2020, at 19:59, Jean | ddostest.me via NANOG wrote:
Where can we find public information on how to use S/RTBH
This .pdf preso on mitigation techniques describes how it works: <https://app.box.com/s/xznjloitly2apixr5xge> -------------------------------------------- Roland Dobbins <roland.dobbins@netscout.com>
uRPF loose or strict. Which ISP supports it? So far, I found none through public information. On 2020-01-20 10:38, Dobbins, Roland wrote:
On 20 Jan 2020, at 19:59, Jean | ddostest.me via NANOG wrote:
Where can we find public information on how to use S/RTBH This .pdf preso on mitigation techniques describes how it works:
<https://app.box.com/s/xznjloitly2apixr5xge>
-------------------------------------------- Roland Dobbins <roland.dobbins@netscout.com>
On 20 Jan 2020, at 22:49, Jean | ddostest.me wrote:
uRPF loose or strict.
Either.
Which ISP supports it?
Some operators use it themselves. I don't know of any who allow customer-triggered S/RTBH; several offer customer-triggered D/RTBH. -------------------------------------------- Roland Dobbins <roland.dobbins@netscout.com>
Exactly, so one of the best option to fight DDoS is not available through public information. @Lumin: You should start your investigation with uRPF loose. Best regards, Jean On 2020-01-20 11:31, Dobbins, Roland wrote:
On 20 Jan 2020, at 22:49, Jean | ddostest.me wrote:
uRPF loose or strict. Either.
Which ISP supports it? Some operators use it themselves. I don't know of any who allow customer-triggered S/RTBH; several offer customer-triggered D/RTBH.
-------------------------------------------- Roland Dobbins <roland.dobbins@netscout.com>
On 20 Jan 2020, at 23:34, Jean | ddostest.me wrote:
so one of the best option to fight DDoS is not available through public information.
I just posted a link to a public presentation which describes how to enable it on one's own network. Giving end-customers the ability to block using S/RTBH on an upstream transit network can be challenging because of the risk of overblocking. It's easy to constrain D/RTBH to the end-customer's own prefixes. -------------------------------------------- Roland Dobbins <roland.dobbins@netscout.com>
On Mon, Jan 20, 2020 at 12:49 PM Jean | ddostest.me via NANOG < nanog@nanog.org> wrote:
uRPF loose or strict.
Which ISP supports it?
So far, I found none through public information.
With all IPv4 space converging to being allocated, loose uRPF is almost useless at this point, or will be soon. Rubens
I gave up on completing the survey because too many wrong assumptions are made. I am unable to convey what we actually do. Which of course is none of the choices given. We, or rather our customers, are frequently hit by low scale volumetric attacks. The primary way to deal with it is to have enough capacity on our transit links that the attack does not saturate the links. The target customer is probably going down but everyone else are unaffected. By the way, the question about tier is rubbish. You should be asking about what our business is instead of how cool we believe ourselves to be. In this case we sell internet service to homes and small businesses. Our answers are going to be completely different from what one of our customers would fill in. Yet both we and all of our customers are tier 3. Regards Baldur tir. 14. jan. 2020 20.21 skrev Lumin Shi <luminshi@cs.uoregon.edu>:
Dear NANOG members,
I am a senior Ph.D. student at the University of Oregon (UO). We are seeking your help to understand DDoS mitigation techniques toward volumetric link flooding attacks.
With our preliminary survey so far, DDoS mitigation approaches in the real world include 1) DDoS mitigation service providers (e.g., Akamai, Cloudflare), 2) Remotely-Triggered Black Hole (RTBH), 3) BGP FlowSpec, and 4) direct contact with upstream providers for traffic filtering.
We also realize the traffic filtering space in hardware routers is limited as router vendors use CAM/TCAM to implement packet matching and access control lists at line rate. We believe that many routers on the Internet today may not have the necessary capacity to perform fine-grained traffic filtering, especially when facing a large-scale DDoS attack with or without IP spoofing.
To this end, we ask that you kindly participate in our short and anonymized survey at https://oregon.qualtrics.com/jfe/form/SV_03aPeCIGiyUt6st. The purpose of this survey is to understand 1) the frequency and scale of DDoS attacks, 2) the DDoS mitigation methods commonly used by the edge network operators, and 3) the capability of the mitigation methods.
We plan to collect responses for three months, and we will report the survey result back to you. This study is part of our on-going research project, the Catch-22 attack, and you can view our poster paper at https://luminshi.github.io/assets/papers/catch22.pdf.
Regards,
Lumin Shi
Center for Cyber Security and Privacy <https://ccsp.uoregon.edu/>
University of Oregon
participants (6)
-
Baldur Norddahl -
Dobbins, Roland -
Jean | ddostest.me -
Lumin Shi -
Rubens Kuhl -
Töma Gavrichenkov