On Sat, Jan 25, 2020 at 2:12 AM Saku Ytti <[email protected]> wrote: > On Sat, 25 Jan 2020 at 05:30, Amir Herzberg <[email protected]> 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 >
