Re: Data on latency and loss-rates during congestion DDoS attacks

[Amir Herzberg <amir.lists () gmail com>]

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