<div dir="ltr"><div dir="ltr">On Sat, Jan 25, 2020 at 2:12 AM Saku Ytti <<a href="mailto:saku@ytti.fi">saku@ytti.fi</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Sat, 25 Jan 2020 at 05:30, Amir Herzberg <<a href="mailto:amir.lists@gmail.com" target="_blank">amir.lists@gmail.com</a>> wrote:<br>
<br>DDoS is very very cheap, if there is a single global egress for given<br>
interface then the DDoS traffic can easily be 100 times the egress<br>
capacity (1GE egress, 100GE DDoS). </blockquote><div><br></div><div>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. </div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">I'm very skeptical if FEC will<br>
help, I think this is case of cat and mouse</blockquote><div><br></div><div>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. </div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">, based on data you see now<br>
it may seem reasonable, but now is only result of minimum viable ddos,<br>
which is trivial to increase should need occur. </blockquote><div><br></div><div>I still think evaluation should preferably compare to attacks reported in reality, with potential additional analysis of projections of potential attacks. </div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Similarly DDoS attacks<br>
are excessive dumb often, like dumb UDP ports which are easy drop, but<br>
should we solve protection well for these, it's trivial to make it<br>
proper HTTPS TCP SYN.<br></blockquote><div><br></div><div>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). </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Backbone device interface can add hundreds of milliseconds during<br>
congestion, but more commonly we're talking about tens of milliseconds<br>
during congestion and low microseconds to high nanoseconds outside<br>
congestion.<br>
Backbone device buffer space is highly googlable, BRCM<br>
trident/tomahawk styte boxes have very little, but they are more<br>
intended for DC/LAN scenarios, than WAN. Nokia FP, Huawei Solar,<br>
EZchip, Cisco nPower, Cisco Silicon One, Juniper Trio, Juniper<br>
Paradise, Broadcom Jericho all will buffer high tens of milliseconds<br>
to low hundreds.<br></blockquote><div><br></div><div>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. </div><div><br></div><div>tks! Amir </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
-- <br>
  ++ytti<br>
</blockquote></div></div>