[RFC] alternative to conntrack ID
azez at ufomechanic.net
Wed May 18 09:24:30 CEST 2005
Patrick McHardy wrote:
>Amin Azez wrote:
>>KOVACS Krisztian wrote:
>>> Probably Patrick was referring to a possible problem where the
>>>following happens: a new connection is established and destroyed in a
>>>very short time. If a new connection with the same tuple is created
>>>before the timestamp increases (which is perfectly possible IMHO if you
>>>have some slow embedded HW with no high precision timer available)
>>After further reading I think this scenario is highly unlikely.
>Unlikely is still enough reason to handle it properly in an API.
By unlikely I didn't mean it would rarely happen I meant the hardware
with which it could ever happen is surely unlikely. (A different order
of unlikiness) However I guess your comment below still holds.
>Otherwise anything you build on top of it has to take this into
>account for any guarantees it would like to give. And so far, I
>haven't even seen a suggestion how to notice it - which would
>also be fine with me.
One such suggestion is: IFF the conntrack is to be destroyed in the same
clock tick as it was created, to instead destroy the conntrack one clock
tick later through death-by-timeout. Then the new conntrack would have
to be created (although the same clock tick) with a different internal
The costs of this would only be borne when such unusual hardware was in
use, and when the problem case came up, but the internal conntrack id
could then be used in conjunction with the timestamp to form a unique
qualifier that (takes deep breath) could be used with the tuple to
recognize a specific conntrack instance. It would require no extra
storage but increase the amount of data sent though the netlink socket.
This would still offer some slight benefit over a public conntrack
serial number in that it would also allow conntrack creation time
matching in iptables rules.
I do point out and wonder about the possibilities of a denial of service
though queueing lots of conntracks to be destroyed by timeout 1 tick
later but think this is hardly any worse than without a timeout in practice.
Another hacky "policy" fix would be to drop the SYN packet that would
re-create the conntrack in the same tick as its original creation and
let it be sent again. Its barely normal behaviour to do such a thing,
such packets deserve to be dropped (for the sins of their parents? Hmm)
Would such packets get re-sent via a loopback interface? But then again
device that abuses themselves in such a way beyond the resolution of
their own timers are surely on drugs?
More information about the netfilter-devel