[feature request] Fixed timeout for conntrack entry

[feature request] Fixed timeout for conntrack entry

[Eric Leblond]

[-- Attachment #1: Type: text/plain, Size: 1938 bytes --]

Hi,

The current libconntrack is for now able to set the standard conntrack
timeout. I think it should be useful to be able to set a fixed conntrack
timeout from userspace to be able to define an efficient connection
expiration policy.

What do you think of this idea ?

Expanded version :

When working on NuFW (http://www.nufw.org), we had to use libconntrack
to kill some entry at a given time. In fact, we use it to be able to
have connections that expire at a given time. At the same time we use
event handling system to be warned of connections that were closed
before their expiration by the users.

This works well but there is a synchronisation problem because when the
NuFW daemon restart you have to synchronise to handle events that have
occur during shutdown :
Let's have a connection and let it die when the daemon is off. When
daemon restart, it could ask kernel to close this connection but it
could then be another existing connection (with the same IPV4 or id
parameters). Arghh ...

Even if it can be done with current functionnalities of conntrack
(dumping conntrack table to daemon at start), it seems that this is not
the cleanest way to do.

In fact, connection expiration is often a user requested feature
(independantly of userspace system) and it could be great to have it
hard wired in the kernel. For example, an iptables match and target
could use it.

From a developpement point of view it seems that this is a "small"
modification of code. It could be done by adding a test when refreshing
standard connection entry timeout (when receiving a packet) and testing
if the connection must be destroy and destroy it if needed ?

Here's some questions :
      * Is this a good idea ?
      * Is there anyone interested in coding it ? (If not I can try to
        do it myself)
      * Is there a chance to have into mainstream ?

BR,
-- 
Eric Leblond <eric@inl.fr>

[-- Attachment #2: Ceci est une partie de message numériquement signée --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [feature request] Fixed timeout for conntrack entry

[Pablo Neira Ayuso]

Hi Eric,

Eric Leblond wrote:
> When working on NuFW (http://www.nufw.org), we had to use libconntrack
> to kill some entry at a given time. In fact, we use it to be able to
> have connections that expire at a given time. At the same time we use
> event handling system to be warned of connections that were closed
> before their expiration by the users.
> 
> This works well but there is a synchronisation problem because when the
> NuFW daemon restart you have to synchronise to handle events that have
> occur during shutdown :
> Let's have a connection and let it die when the daemon is off. When
> daemon restart, it could ask kernel to close this connection but it
> could then be another existing connection (with the same IPV4 or id
> parameters). Arghh ...

That's very unlikely to happen. If a new connection is opened with the
same IP information, the ID will be different than the old connection.
So such problem is unlikely to happen. Unless the daemon is so slow that
a wraparound happened to the global ID, eg. 2^32 connections were opened
at the time that the daemon was restarting. That would be really slow :)

> Even if it can be done with current functionnalities of conntrack
> (dumping conntrack table to daemon at start), it seems that this is not
> the cleanest way to do.
> 
> In fact, connection expiration is often a user requested feature
> (independantly of userspace system) and it could be great to have it
> hard wired in the kernel. For example, an iptables match and target
> could use it.
> 
> From a developpement point of view it seems that this is a "small"
> modification of code. It could be done by adding a test when refreshing
> standard connection entry timeout (when receiving a packet) and testing
> if the connection must be destroy and destroy it if needed ?

I think that we could add support for permanent conntracks, eg.
conntracks that never expire. So the userspace program could have their
own timers and kill it whenever it wants to. The problem is that the
userspace program must behave correctly, otherwise we could get tons of
zombie conntracks that never expire.

-- 
Pablo

Re: [feature request] Fixed timeout for conntrack entry

[Amin Azez]

Pablo Neira Ayuso wrote:
> I think that we could add support for permanent conntracks, eg.
> conntracks that never expire. So the userspace program could have their
> own timers and kill it whenever it wants to. The problem is that the
> userspace program must behave correctly, otherwise we could get tons of
> zombie conntracks that never expire.

Maybe it could be the user process that resets the timeout so that it 
never expires. If the user process fails to do this, then it is an 
un-cared for zombie and so the kernel should kill it rather than fill 
the conntrack hash full of zombies.

Naturally the user process can kill the contrack when the user process 
thinks it should have expired.

Sam

Re: [feature request] Fixed timeout for conntrack entry

[Eric Leblond]

Pablo Neira Ayuso wrote:
> Hi Eric,
> 
> Eric Leblond wrote:
> 
>>When working on NuFW (http://www.nufw.org), we had to use libconntrack
>>to kill some entry at a given time. In fact, we use it to be able to
> 
> That's very unlikely to happen. If a new connection is opened with the
> same IP information, the ID will be different than the old connection.
> So such problem is unlikely to happen. Unless the daemon is so slow that
> a wraparound happened to the global ID, eg. 2^32 connections were opened
> at the time that the daemon was restarting. That would be really slow :)

Yes ;-) but that's mean you need to know the conntrack ID. Thus
userspace programs needs to fetch the ID.
Let's assume this, in the scope of NuFW, this will cost some more
kernel<->userspace exchanges but it could be done because at we only
interfere with kernel when we accept the packet with nfnetlink_queue.

But I don't think this is the main point.

>>From a developpement point of view it seems that this is a "small"
>>modification of code. It could be done by adding a test when refreshing
>>standard connection entry timeout (when receiving a packet) and testing
>>if the connection must be destroy and destroy it if needed ?
> 
> 
> I think that we could add support for permanent conntracks, eg.
> conntracks that never expire. So the userspace program could have their
> own timers and kill it whenever it wants to. The problem is that the
> userspace program must behave correctly, otherwise we could get tons of
> zombie conntracks that never expire.

Personnally, I don't think that trust userspace for something like that
is not a good idea. A userspace daemon could be stopped, and this will
be the night of the living dead.

Furthermore, this does not introduce the capability to do this from
kernel space which could be really interesting. From an iptables point
of view we could have something like :
iptables -A FORWARD -m state --state NEW -m time --time 08h-18h \\
	-m expiration -j ACCEPT --expire-at 18h
I mean, accept connection creation between 08h and 18h and destroy
connection from conntrack at 18h. This is a policy that we have been
asked quiet frequently.

Is there some theoritical limit in current Netfilter code to implement
such a thing ?

BR,
--
Eric Leblond