DDoS Mitigation Survey

Mailman List Mirror (Read Only)
1

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

University of Oregon

2

Peace,

3

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.

4

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

5

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

6

Peace,

7

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>:

8

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.

9

Where can we find public information on how to use S/RTBH

and which providers support it.

Thanks
Jean

10

This .pdf preso on mitigation techniques describes how it works:

<https://app.box.com/s/xznjloitly2apixr5xge>

11

uRPF loose or strict.

Which ISP supports it?

So far, I found none through public information.

12

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.

13

With all IPv4 space converging to being allocated, loose uRPF is almost useless at this point, or will be soon.

Rubens

14

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

15

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.