Re: conntrack DoS

[Henrik Nordstrom <hno@marasystems.com>]

Jozsef Kadlecsik wrote:

> > The good news is that second case can be detected by detecting a long term
> > uni-directional packet flow, and we probably do not need to care about the
> > first..
> 
> How could be such connections (second case) sorted out from
> legitimate uni-directional (even half-closed) connections?

A running TCP packet flow (even for a "half-closed" uni-directional TCP)
is never uni-directional. If there is data in flowing in one direction
then there is ACKs in the other direction.

Idea on how conntrack could deal with such connections: If several
retransmissions (lets say 5) is seen in one direction and no ACKs in the
other within a reasonable timeframe (lets say 10 minutes) then the TCP
is most likely dead and a low inactivity timeout can be assigned (lets
say 20 minutes) to have it cleaned out from conntrack.

At a first glance this can be simplified into a RETRANSMIT/ACK timeout
state machinery, but there is a significant race window making a simple
packet driven state machine unsuitable. Must not trigger on a delayed
retransmission followed by a lost ACK, or delayed retransmissions not
resulting in ACK (out of window).

Regards
Henrik