TCP_CONNTRACK_ESTABLISHED 5days

TCP_CONNTRACK_ESTABLISHED 5days

[Mogens Valentin]

(Sent this to the linux-net list; seems this list is more appropriate. 
Sorry for any inconvenient xposting)

I fail to understand why TCP_CONNTRACK_ESTABLISHED has to be 5 days.
It's not configurable from /proc, but I see nothing wrong in changing 
the source to, say, 1 day.
Would someone educate me, pls.

/usr/src/linux/net/ipv4/netfilter/ip_conntrack_proto_tcp.c :

static unsigned long tcp_timeouts[]
= { 30 MINS,    /*      TCP_CONNTRACK_NONE,     */
    5 DAYS,     /*      TCP_CONNTRACK_ESTABLISHED,      */
    2 MINS,     /*      TCP_CONNTRACK_SYN_SENT, */
    60 SECS,    /*      TCP_CONNTRACK_SYN_RECV, */
    2 MINS,     /*      TCP_CONNTRACK_FIN_WAIT, */
    2 MINS,     /*      TCP_CONNTRACK_TIME_WAIT,        */
    10 SECS,    /*      TCP_CONNTRACK_CLOSE,    */
    60 SECS,    /*      TCP_CONNTRACK_CLOSE_WAIT,       */
    30 SECS,    /*      TCP_CONNTRACK_LAST_ACK, */
    2 MINS,     /*      TCP_CONNTRACK_LISTEN,   */
};

-- 
Kind regards,
Mogens Valentin

Re: TCP_CONNTRACK_ESTABLISHED 5days

[Mogens Valentin]

Mogens Valentin wrote:
> (Sent this to the linux-net list; seems this list is more appropriate. 
> Sorry for any inconvenient xposting)
> 
> I fail to understand why TCP_CONNTRACK_ESTABLISHED has to be 5 days.
> It's not configurable from /proc, but I see nothing wrong in changing 
> the source to, say, 1 day.
> Would someone educate me, pls.
> 
> /usr/src/linux/net/ipv4/netfilter/ip_conntrack_proto_tcp.c :
> 
> static unsigned long tcp_timeouts[]
> = { 30 MINS,    /*      TCP_CONNTRACK_NONE,     */
>    5 DAYS,     /*      TCP_CONNTRACK_ESTABLISHED,      */
>    2 MINS,     /*      TCP_CONNTRACK_SYN_SENT, */
>    60 SECS,    /*      TCP_CONNTRACK_SYN_RECV, */
>    2 MINS,     /*      TCP_CONNTRACK_FIN_WAIT, */
>    2 MINS,     /*      TCP_CONNTRACK_TIME_WAIT,        */
>    10 SECS,    /*      TCP_CONNTRACK_CLOSE,    */
>    60 SECS,    /*      TCP_CONNTRACK_CLOSE_WAIT,       */
>    30 SECS,    /*      TCP_CONNTRACK_LAST_ACK, */
>    2 MINS,     /*      TCP_CONNTRACK_LISTEN,   */
> };
> 

Sorry, I had missed
/proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_timeout_established

Moritz, thanks for pointing that out.
Your suggested 10 minutes seems a bit short, though..

If we keep, say, a browser connection open longer than those 10m, it's 
supposed to either use keepalive, or an established session will simply 
be setup for another 10m, right?
Won't that create some additional load for a busy server, i.e. something 
else that this thought-of browser session?

To the maintainer of ip_conntrack_proto_tcp.c (Paul Russell?):
Wouldn't it be fair to change TCP_CONNTRACK_ESTABLISHED permanently?

-- 
Kind regards,
Mogens Valentin

Re: TCP_CONNTRACK_ESTABLISHED 5days

[Moritz Gartenmeister]

> Moritz, thanks for pointing that out.
> Your suggested 10 minutes seems a bit short, though..
> 
> If we keep, say, a browser connection open longer than those 10m, it's 
> supposed to either use keepalive, or an established session will simply 
> be setup for another 10m, right?

hm... depends on a few factors.
a normal browser session should be closed after GET has delivered all data, there is no need to keep 
the connection established.
e.g. online-banking should use keepalive not only for this purpose.
and it depends on your other firewall settings (syn flag etc).

i got 500 clients, nobody claimed any troubles so far.

> Won't that create some additional load for a busy server, i.e. something 
> else that this thought-of browser session?

hm... there may exist some application, which need this, but i never saw one.

> To the maintainer of ip_conntrack_proto_tcp.c (Paul Russell?):
> Wouldn't it be fair to change TCP_CONNTRACK_ESTABLISHED permanently?

the question is, what would be a good value?
everyone can change this value in a easy way.

Re: TCP_CONNTRACK_ESTABLISHED 5days

[Taylor, Grant]

> Moritz, thanks for pointing that out.
> Your suggested 10 minutes seems a bit short, though..

I would not set ip_conntrack_tcp_timeout_established to any thing lower than tcp_fin_timeout.  I would be tempted to set ip_conntrack_tcp_timeout_established to approximately double what tcp_fin_timeout is set to.  I don't know of any reason that conntrack would need to keep things for twice tcp_fin_timeout, but I'd rather be safe than sorry.  Besides even double of tcp_fin_timeout is CONSIDERABLY less than 5 days.



Grant. . . .

Re: TCP_CONNTRACK_ESTABLISHED 5days

[Mogens Valentin]

Taylor, Grant wrote:
>> Moritz, thanks for pointing that out.
>> Your suggested 10 minutes seems a bit short, though..
> 
> 
> I would not set ip_conntrack_tcp_timeout_established to any thing lower 
> than tcp_fin_timeout.  I would be tempted to set 
> ip_conntrack_tcp_timeout_established to approximately double what 
> tcp_fin_timeout is set to.  I don't know of any reason that conntrack 
> would need to keep things for twice tcp_fin_timeout, but I'd rather be 
> safe than sorry.  Besides even double of tcp_fin_timeout is CONSIDERABLY 
> less than 5 days.

Hmm, dunno if various distros set tcp_fin_timeout differently.
With 2.6.10, it's 60 secs (not a distro kernel, and I didn't set this).
Are you saying that Mouritz' 10mins will in some (distro?) cases violate
   ip_conntrack_tcp_timeout_established >= tcp_fin_timeout * 2 ?


Anyway, /usr/src/linux/Documentation/filesystems/proc.txt says

tcp_fin_timeout
---------------
The length of time in seconds it takes to receive a final FIN before the 
socket is always closed.  This is strictly a violation of the TCP
specification, but required to prevent denial-of-service attacks.


I'm having trouble understanding the 'strictly a violation' part.
Is it a (iana) crime to define tcp_fin_timeout?

-- 
Kind regards,
Mogens Valentin

Re: TCP_CONNTRACK_ESTABLISHED 5days

[Taylor, Grant]

> Hmm, dunno if various distros set tcp_fin_timeout differently.
> With 2.6.10, it's 60 secs (not a distro kernel, and I didn't set this).
> Are you saying that Mouritz' 10mins will in some (distro?) cases violate
>   ip_conntrack_tcp_timeout_established >= tcp_fin_timeout * 2 ?

No, not at all.  I'm merely stating that I see no reason to have ip_conntrack_tcp_timeout_established any higher than tcp_fin_timeout safe for some small head room.  Seeing as how the time was for 5 days, I see no reason to hold it open for twice the tcp_fin_timeout period for safe head room.  Any thing beyond tcp_fin_timeout and your local TCP stack will have closed the connection any way.  As soon as I type this I start wondering about systems behind a firewall.  Hmm...  Something to think about.

> Anyway, /usr/src/linux/Documentation/filesystems/proc.txt says
> 
> tcp_fin_timeout
> ---------------
> The length of time in seconds it takes to receive a final FIN before the 
> socket is always closed.  This is strictly a violation of the TCP
> specification, but required to prevent denial-of-service attacks.
> 
> 
> I'm having trouble understanding the 'strictly a violation' part.
> Is it a (iana) crime to define tcp_fin_timeout?

I have not (recently) read (enough) of the TCP specification to know for sure what is in violation, but I would be willing to bet that a TCP ""conversation is to remain in the open state (Syn, Syn-Ack, Ack-Ack...) state until both sides close the connection gracefully or see a reset.  Thus if we artificially close the connection we are violating the TCP specification by doing such.  Seeing as how this is usually not a problem...  This is sort of like what the TARPIT target is targeting.  TARPIT will take a TCP connection to the established state and release all resources but not honor a close of the connection.  This failure to close the connection causes the sending system to get stuck in the TARPIT (hens the name) until it is willing to forcefully close the connection from it's end via  timeout.



Grant. . . .

Re: TCP_CONNTRACK_ESTABLISHED 5days

[Mohamed Eldesoky]

On 5/2/05, Mogens Valentin <monz@danbbs.dk> wrote:
> Taylor, Grant wrote:
> >> Moritz, thanks for pointing that out.
> >> Your suggested 10 minutes seems a bit short, though..
> >
> >
> > I would not set ip_conntrack_tcp_timeout_established to any thing lower
> > than tcp_fin_timeout.  I would be tempted to set
> > ip_conntrack_tcp_timeout_established to approximately double what
> > tcp_fin_timeout is set to.  I don't know of any reason that conntrack
> > would need to keep things for twice tcp_fin_timeout, but I'd rather be
> > safe than sorry.  Besides even double of tcp_fin_timeout is CONSIDERABLY
> > less than 5 days.
> 
> Hmm, dunno if various distros set tcp_fin_timeout differently.
> With 2.6.10, it's 60 secs (not a distro kernel, and I didn't set this).
> Are you saying that Mouritz' 10mins will in some (distro?) cases violate
>    ip_conntrack_tcp_timeout_established >= tcp_fin_timeout * 2 ?
> 

In debian3.1 it is 5 days too !!!

The question now, what troubles would happen if we kep it/changed it !?!?!

> Anyway, /usr/src/linux/Documentation/filesystems/proc.txt says
> 
> tcp_fin_timeout
> ---------------
> The length of time in seconds it takes to receive a final FIN before the
> socket is always closed.  This is strictly a violation of the TCP
> specification, but required to prevent denial-of-service attacks.
> 
> I'm having trouble understanding the 'strictly a violation' part.
> Is it a (iana) crime to define tcp_fin_timeout?
> 
> --
> Kind regards,
> Mogens Valentin
> 
> 


-- 
Mohamed Eldesoky
www.eldesoky.net
RHCE

Re: TCP_CONNTRACK_ESTABLISHED 5days

[Mogens Valentin]

Mohamed Eldesoky wrote:
> On 5/2/05, Mogens Valentin <monz@danbbs.dk> wrote:
> 
>>Taylor, Grant wrote:
>>
>>>>Moritz, thanks for pointing that out.
>>>>Your suggested 10 minutes seems a bit short, though..
>>>
>>>
>>>I would not set ip_conntrack_tcp_timeout_established to any thing lower
>>>than tcp_fin_timeout.  I would be tempted to set
>>>ip_conntrack_tcp_timeout_established to approximately double what
>>>tcp_fin_timeout is set to.  I don't know of any reason that conntrack
>>>would need to keep things for twice tcp_fin_timeout, but I'd rather be
>>>safe than sorry.  Besides even double of tcp_fin_timeout is CONSIDERABLY
>>>less than 5 days.
>>
>>Hmm, dunno if various distros set tcp_fin_timeout differently.
>>With 2.6.10, it's 60 secs (not a distro kernel, and I didn't set this).
>>Are you saying that Mouritz' 10mins will in some (distro?) cases violate
>>   ip_conntrack_tcp_timeout_established >= tcp_fin_timeout * 2 ?
>>
> 
> 
> In debian3.1 it is 5 days too !!!

Yes, it's kernel defined, distros doesn't set it any differently, AFAIK.

> The question now, what troubles would happen if we kep it/changed it !?!?!

None. When sessions timeout, so be it. When need be, a new session will 
be setup. Works fine for me now.

-- 
Kind regards,
Mogens Valentin


Horse dropping have an easy life,
they don't have to work and can smoke..
   -- Mogens Valentin