NANOG Digest, Vol 90, Issue 1

Fri Jul 17 15:12:48 UTC 2015

To Ramy,

Thank you for the acknowledgement. DDoS Mitigation service providers,
regardless if its pure cloud, hybrid cloud, or CPE only, all face these
challenges when it comes to DDoS Attacks.

Can you restate your question again or rephrase it for the forum? Seems
there is some confusion or maybe people didn't grasp it.

My understanding of the question RAMY asked was around DDoS mitigation
providers and during the Time-to-Detect, Time-to-Start-to-Mitigate. How do
businesses protect themselves when attack traffic is NOT stopped at
first?.IE: Defense in depth

NOTE: Some DDoS mitigation providers offer Time-to-stop-the-attack SLA's.

Its all moot though. These types of solutions do not guarantee up time
during the initial attack start time, PERIOD!

How can anyone guarantee up-time during a 40Gbps attack and lets say - all
you have are 2 x 1GB CAT5E links over multi-homed BGP providers. Having
larger port capacity (IE: 10GB ports) only gives you minutes/hours to react
and redirect to a Cloud Provider.

The time to start mitigation (average industry time) 30 - 45 minutes. What
is happening to your WAN infrastructure when there is 40Gbps of attack on
your doorstep.

Will your 2Gbps worth of aggregated ISP bandwidth keep sessions up? No, it
will get saturated, BGP will flap and any GRE connections or any other
traffic will be lost. This means, even with local CPE mitigation, things
will bounce. This is 1 scenario of 1000's.

There are positive security models that you can employ as as stop gap to
prevent these types of scenario's, but mostly its on the Service Providers
best practices or traffic posture model. IE: On-Demand, On-Demand with
monitoring, Always-On monitoring, Always-On monitoring and mitigation.

Having local mitigation for DDoS attacks is a loosing battle in my opinion.
Its only buying you time to redirect. It does solve problems like attacks
that are low in scale that you can consume with your port capacity or quick
to hit and run attacks (1-2min durations). But then you need
auto-mitigation enabled and that leads to collateral damage most of the
times for legitimate traffic.

Pretty sure other SP's will offer different opinion. This is my technical
opinion, not representing Akamai or any other companies official position.

>From an engineering perspective, assume when an advisory targets your
business and they have 1/2 way decent attacking nodes, expect an outage.
Message that to the board but explain that you have every capability to
mitigate these risks. Given the SP you go with has enough staff, resources,
capacity, technology, SLA, and knowledge/experience in the attack vector
hitting you.

If you want to "learn more", keep up the engagements with the market DDoS
providers you are communicating with and ask these tough questions. If
anyone "sells" you the perfect solution, they are LIEING to you!

On a personal note, thank you for reaching out privately in email and
explaining who you are talking too. Trust me when I tell you, I know the
organization VERY WELL from the other competitor you are looking at and i
will offer you my candid opinion of them, if you'd like. My friend runs
their SOC over there, an old colleague of mine from when i was in the SOC
blocking attacks.

Love this topic!

Dennis

On Wed, Jul 8, 2015 at 12:00 PM, Roland Dobbins <rdobbins at arbor.net> wrote:

>
> On 8 Jul 2015, at 22:26, Roland Dobbins wrote:
>
>  Hardware-based GRE processing is required on both ends for anything other
>> than trivial speeds; in general, the day of software-based Internet
>> routers is long gone, and any organization still running software-based
>> routers on their transit/peering edges at risk.
>>
>
> To clarify, I'm referring to GRE processing on routers; hardware
> processing is pretty much a requirement on routers.  Other types of devices
> can often handle GRE at significantly higher rates than software-based
> routers.
>
>
>
> -----------------------------------
> Roland Dobbins <rdobbins at arbor.net>
>