On Sat, Jan 25, 2020 at 2:12 AM Saku Ytti <saku@ytti.fi> wrote:
On Sat, 25 Jan 2020 at 05:30, Amir Herzberg <amir.lists@gmail.com> wrote:

DDoS is very very cheap, if there is a single global egress for given
interface then the DDoS traffic can easily be 100 times the egress
capacity (1GE egress, 100GE DDoS).

Thanks. However, my question is about statistics of attacks actually seen `in the wild' - and not just the `worst' but also more common attacks. Furthermore, I'm asking about the _outcome_ of the congestion - mainly, loss-rates and latency - and not about the _amount_ of DDoS traffic. DDoS traffic often gets lost itself in different intermediate routers, so its ultimate impact is not trivial to estimate. 
 
I'm very skeptical if FEC will
help, I think this is case of cat and mouse

hmm, I don't think so; it is more a matter of justification, and also, obviously, amount of over-capacity - which is still, obviously, a basic thing anybody concerned about congestion would worry about. Let me be extreme and simplify... Suppose idd attacker can send 100 times the capacity of a (say, single) router, resulting in 99% loss rate. Then FEC should work - but, of course, with high overhead, let's even simplify and say it requires 100 times redundancy (although it's actually not as bad as that). Still, this can be Ok if I have 100 times overcapacity - which for many critical applications, is not even a big deal, as crazy as it sounds (and is) for general applications. 
 
, based on data you see now
it may seem reasonable, but now is only result of minimum viable ddos,
which is trivial to increase should need occur.

I still think evaluation should preferably compare to attacks reported in reality, with potential additional analysis of projections of potential attacks. 
 
Similarly DDoS attacks
are excessive dumb often, like dumb UDP ports which are easy drop, but
should we solve protection well for these, it's trivial to make it
proper HTTPS TCP SYN.

hmm, tcp-syn is already a different story (and we have pretty good defenses against it and many other attacks on the end host). I do work on some of these attacks (and defenses) too but in this specific case I'm focusing on bandwidth-DoS attacks (network congestion).  I'm further focusing in this work on a defense which may involves a transport (end to end) protocol, of course I'm aware of network-based defenses, it's just not focus of this work (think of customer with no ability to `fix' the network service). 

Backbone device interface can add hundreds of milliseconds during
congestion, but more commonly we're talking about tens of milliseconds
during congestion and low microseconds to high nanoseconds outside
congestion.
Backbone device buffer space is highly googlable, BRCM
trident/tomahawk styte boxes have very little, but they are more
intended for DC/LAN scenarios, than WAN. Nokia FP, Huawei Solar,
EZchip, Cisco nPower, Cisco Silicon One, Juniper Trio, Juniper
Paradise, Broadcom Jericho all will buffer high tens of milliseconds
to low hundreds.

Thanks again, but I'm not looking for data on particular devices; the latency during congestion attacks may be impacted by multiple devices along the path. So again my interest is mainly in measured values under real attacks. 

tks! Amir 

--
  ++ytti