NANOG Digest, Vol 89, Issue 8

Mon Jun 8 16:07:46 UTC 2015

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