|
|
|
|
|
|
|
|
|
|
|
|
| home | help | back | first | fref | pref | prev | next | nref | lref | last | post |
X-Original-To: nanog@nanog.org From: "Watson, Bob" <Bob.Watson@wwt.com> To: Dennis B <infinityape@gmail.com> Date: Fri, 17 Jul 2015 17:58:29 +0000 In-Reply-To: <CAPr+j8J1UMoGw2oC30MqFVJqxc==cXuacrCXRPajYd64+6TVWQ@mail.gmail.com> Cc: "nanog@nanog.org" <nanog@nanog.org>, Ramy Hashish <ramy.ihashish@gmail.com> Errors-To: nanog-bounces@nanog.org P Bob Watson=20 > On Jul 17, 2015, at 10:14 AM, Dennis B <infinityape@gmail.com> wrote: >=20 > To Ramy, >=20 > 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. >=20 > Can you restate your question again or rephrase it for the forum? Seems > there is some confusion or maybe people didn't grasp it. >=20 > My understanding of the question RAMY asked was around DDoS mitigation > providers and during the Time-to-Detect, Time-to-Start-to-Mitigate. How d= o > businesses protect themselves when attack traffic is NOT stopped at > first?.IE: Defense in depth >=20 > NOTE: Some DDoS mitigation providers offer Time-to-stop-the-attack SLA's. >=20 > Its all moot though. These types of solutions do not guarantee up time > during the initial attack start time, PERIOD! >=20 > How can anyone guarantee up-time during a 40Gbps attack and lets say - al= l > 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 rea= ct > and redirect to a Cloud Provider. >=20 > The time to start mitigation (average industry time) 30 - 45 minutes. Wha= t > is happening to your WAN infrastructure when there is 40Gbps of attack on > your doorstep. >=20 > Will your 2Gbps worth of aggregated ISP bandwidth keep sessions up? No, i= t > 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. >=20 > 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 Provider= s > best practices or traffic posture model. IE: On-Demand, On-Demand with > monitoring, Always-On monitoring, Always-On monitoring and mitigation. >=20 > Having local mitigation for DDoS attacks is a loosing battle in my opinio= n. > 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 qui= ck > 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. >=20 > Pretty sure other SP's will offer different opinion. This is my technical > opinion, not representing Akamai or any other companies official position= . >=20 > 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, resource= s, > capacity, technology, SLA, and knowledge/experience in the attack vector > hitting you. >=20 > 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! >=20 > 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. >=20 > Love this topic! >=20 > Dennis >=20 >=20 >=20 >=20 >=20 >=20 >=20 >> On Wed, Jul 8, 2015 at 12:00 PM, Roland Dobbins <rdobbins@arbor.net> wro= te: >>=20 >>=20 >> On 8 Jul 2015, at 22:26, Roland Dobbins wrote: >>=20 >> Hardware-based GRE processing is required on both ends for anything othe= r >>> 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. >>=20 >> To clarify, I'm referring to GRE processing on routers; hardware >> processing is pretty much a requirement on routers. Other types of devi= ces >> can often handle GRE at significantly higher rates than software-based >> routers. >>=20 >>=20 >>=20 >> ----------------------------------- >> Roland Dobbins <rdobbins@arbor.net> >>=20
|
|
|
|
|
|
|
|
|
|
|
|
| home | help | back | first | fref | pref | prev | next | nref | lref | last | post |