Re: NANOG Digest, Vol 89, Issue 8
On 8 Jun 2015, at 17:57, Ramy Hashish wrote:
a BGP session has to be established over a GRE tunnel over the internet between the ISP/NSP/DC and the cloud scrubbing center,
This is incorrect.
In most cloud overlay DDoS mitigation scenarios (e.g., end-customer obtains service from an MSSP which isn't providing them with transit), a) there is no BGP relationship whatsoever between the end-customer and the MSSP, and b) the GRE tunnel is used strictly for re-injection of clean traffic (i.e., post-mitigation) to the end-customer.
In some scenarios, DNS is also used in place of/in addition to BGP-based diversion.
But GRE is used for re-injection only.
Roland, I am talking about the case where the ISP/NSP is having their own DDoS mitigation solution -to protect their NW infrastructure- and then providing the service to their end customers. However I have some concerns on your comments: Even if the transit provider won't be involved in the mitigation process and the GRE tunnel is used only for injecting the traffic back to the end customer, the customer's dirty traffic will pass through some congestion points (most likely near the IGWs) throughout the transit provider network. And concerning point b) as per Arbor representatives in my region, Arbor's system takes up to five minutes to mitigate the attack (starting from the hit of the first dirty packet), so there will be a period of time where the dirty traffic (or at least some of it) will be coming down all the way to the end customer until you completely mitigate the attack. I hope now it become more clear. Ramy
On 8 Jun 2015, at 22:18, Ramy Hashish wrote:
Even if the transit provider won't be involved in the mitigation process and the GRE tunnel is used only for injecting the traffic back to the end customer, the customer's dirty traffic will pass through some congestion points (most likely near the IGWs) throughout the transit provider network.
The Internet is a best-effort network (of networks). People with operational experience understand this and don't find it remarkable, nor do they make unfounded general assertions.
And concerning point b) as per Arbor representatives in my region, Arbor's system takes up to five minutes to mitigate the attack (starting from the hit of the first dirty packet), so there will be a period of time where the dirty traffic (or at least some of it) will be coming down all the way to the end customer until you completely mitigate the attack.
All the commercial IDMS systems from various vendors of which I'm aware have operator-configured latency values for both detection/classification/traceback and for mitigation activation; these functions are intended to allow the operator to find the right balance between rapidity in responding to operationally-significant events and not being deluged with alerts/mitigations regarding events with little or no operational significance. Different operators with different customer bases in different situations tend to tune them differently, depending upon their situationally-specific priorities, operational practices, etc. It isn't appropriate for a vendor employee like me to get into a vendor-specific discussion on the NANOG list; if you'd like to understand how a) the above assertion about '5 minutes' is incorrect and b) how DDoS mitigation in general focused on minimizing both underblocking and overblocking, rather than on the failed 'IPS' model, contact those Arbor representatives of whom you speak and have them engage me in joint discussions. ----------------------------------- Roland Dobbins <rdobbins@arbor.net>
participants (2)
-
Ramy Hashish -
Roland Dobbins