technical tests on netfiler under 2.4.0-test2

[Jozsef Kadlecsik]

On Sun, 16 Jul 100 bof@oknodo.bof.de wrote:

> using the same testing methodology as in my previous mail, I just tested
> the 3way handshake patch Jozsef Kadlecsik sent some days ago. I applied
> it to a "vanilla" 2.4.0-test5-pre1 kernel (without additional netfilter
> patches); it applied with some offset, but fine.
> 
> Doing my echo connection from a blackhole-routed client, I now see
> an ESTABLISHED [UNREPLIED] conntrack with a nice short timeout.
> Great!

The problem is that the nice short timeout is due to a bug in my patch
and not a feature: I forgot to update the timeout value of the connection
entry. :-(

For nice short timeouts at the SYN SENT/RECEIVED sates, the TCP state
transition table and timeout values must be revised - and those are
complex!

> However - but probable here I'm confused, when in that situation, and I remove
> the blackhole route, the client retransmits the SYN, and tells me it is
> connected now, but the conntrack stays in the above state until I really
> send the first segment of data from client to server; then it properly
> becomes fully ESTABLISHED with 5 day timeout. Hope it also does that when
> the server sends data first.

The server must not send data (i.e. ACK-only packets) until the 3way
handshake isn't finished.

The point of the patch was that don't enter the established state until
the 3way handshake isn't really finished. The side effect of it -
which was in my mind - that under DOS attack, when the maximal connection
count is reached, the non-established connections are the candidates for
early dropping from the connections table.

Regards,
Jozsef
-
E-mail  : kadlec@blackhole.kfki.hu, kadlec@sunserv.kfki.hu
WWW-Home: http://www.kfki.hu/~kadlec
Address : KFKI Research Institute for Particle and Nuclear Physics
          H-1525 Budapest 114, POB. 49, Hungary