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@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@arbor.net>