Re: ip contrack problem, not strictly followed RFC, DoS very much possible

[gj <gj@pointblue.com.pl>]

On Mon, 6 Dec 2004 at 20:48:45, Valdis.Kletnieks@vt.edu wrote:

> On Mon, 06 Dec 2004 14:54:59 +0100, Grzegorz Piotr Jaskiewicz said:
> 
> > There is little bug, eversince, no author would agree to correct it 
> > (dunno why) in ip_conntrack_proto_tcp.c:91:
> > unsigned long ip_ct_tcp_timeout_established =   5 DAYS;
> 
> If you so desire, you can probably workaround this by doing:
> 
> echo 100 >
> /proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_timeout_established
> 
> Of course, then if you don't type in an SSH window for 5 minutes, it
> evaporates
> on you - and even SSH keepalives don't help if a router takes a nose dive
> and
> it takes 2 minutes for our NOC to slap it upside the head.  This is a case
> *against* keepalives there - if a router hiccups and drops a keepalive on
> an
> otherwise idle session, you nuke a perfectly good idle session for reasons
> totally contrary to the original purpose of TCP, namely to *survive* such a
> router burp.

Shouldn't it be protocols thingie to take care about connections ?
Ussualy some protocols are sending ping packet to peer. 
This value as it is now, keeps too many connections in memory, which often leads
to conntrack overflow, that blocks litteraly whole machine up. That is nothing
more than DoS, and besides, there is no fallback routine, something that uppon
error would react. Like, flush very likely to be dead connections, etc.



-- 
Grzegorz Jaskiewicz
K4 Labs