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