Re: DDoS Mitigation Survey

[Dobbins, Roland]

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 

Re: DDoS Mitigation Survey

[Rubens Kuhl]

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

Re: DDoS Mitigation Survey

[Jean | ddostest.me via NANOG]

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 

Re: DDoS Mitigation Survey

[Dobbins, Roland]

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 

Re: DDoS Mitigation Survey

[Jean | ddostest.me via NANOG]

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:




Roland Dobbins 

Re: DDoS Mitigation Survey

[Dobbins, Roland]

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:




Roland Dobbins 

Re: DDoS Mitigation Survey

[Jean | ddostest.me via NANOG]

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

Re: DDoS Mitigation Survey

[Lumin Shi]

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

Re: DDoS Mitigation Survey

[Lumin Shi]

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

> Peace,
>
> On Tue, Jan 14, 2020, 10:22 PM Lumin Shi  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
>

Re: DDoS Mitigation Survey

[Dobbins, Roland]

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:



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 

Re: DDoS Mitigation Survey

[Baldur Norddahl]

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 :

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

Re: DDoS Mitigation Survey

[Töma Gavrichenkov]

Peace,

On Wed, Jan 15, 2020, 2:35 AM Lumin Shi  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

>

Re: DDoS Mitigation Survey

[Dobbins, Roland]

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:



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 

Re: DDoS Mitigation Survey

[Töma Gavrichenkov]

Peace,

On Tue, Jan 14, 2020, 10:22 PM Lumin Shi  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