NANOG Digest, Vol 90, Issue 1

Watson, Bob Bob.Watson at wwt.com
Fri Jul 17 17:58:29 UTC 2015


P

Bob Watson 


> On Jul 17, 2015, at 10:14 AM, Dennis B <infinityape at gmail.com> wrote:
> 
> 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>
>> 



More information about the NANOG mailing list