Re: [RFC] alternative to conntrack ID

[Pablo Neira <pablo@eurodev.net>]

Hi Jozsef,

Jozsef Kadlecsik wrote:
>>Pablo Neira wrote:
>>
>>>I'd definitely like to have such accuracy, but I still see this incident
>>>unlikely. I think that such TCP stack must be broken if it starts a
>>>brand new connection using the same source/destination ports that it's
>>>recently used.
>>
>>Forget this, this can happen in an attempt to reopen a closed
>>connection, and such case is likely. We need such ID in order to achieve
>>accuracy. I think that it must be the user who has to choose if he wants
>>accuracy or not, in such case we have to provide the corresponding
>>methods to achieve it. A user could kill a conntrack by means of:
>>
>>a) the tuples, if he doesn't want accuracy
>>b) the tuples + the id, if he does.
> 
> 
> I share your feelings about giving complete accurate access to the users
> over conntrack entries. Still, I'm not completely convinced about the
> practical usefulness of such accuracy. Let's therefore look at it again:
> 
> a. Policy changed and admin wants to enforce the new policy on the living
>    conntrack entries as well: here the id does not buy anything, tuples
>    are just sufficient.
> b. Admin wants to kill a "stuck" conntrack entry, in order to make
>    possible to build up a new connection. In my opinion that's just not
>    the proper way to deal with the problem, conntrack should be able to
>    handle such cases automatically. And I believe we worked very hard
>    and that part is highly polished in conntrack in the recent 2.6
>    tree, so that it's just a theoretical example ;-)
> c. conntrack table is full and admin wants to get rid of a bunch of
>    entries manually. Somehow I don't think id would be very useful here
>    either.
> 
> Other possibilities?
> 
> I do not think users should poke conntrack without very good reason, at
> their whim.

Agreed, those scenarios look pretty realistic.

But if the ID goes out, I'll have another concern. 
ctnetlink_dump_table[_w] currently uses the ID to know where it's 
stopped dumping the conntrack table, netlink dumping is not atomic. I 
could increase the conntrack refcount and hold a pointer to it but if 
timeout expires while returning data to user space, the conntrack won't 
be in hashes anymore, so it couldn't continue the travel through the 
conntrack table.

I thought about freezing the conntrack timer and active it once I 
continue traversing the list. That could result in problems since 
netlink dumping is not atomic, someone could interrupt the dumping and 
that conntrack will be stuck there forever. Moreover, I don't like it.

All the things I've though so far are burned by something. The cleanest 
way to do this looks the ID. Any other ideas?

P.D: Thanks to Krisztian Kovacs for the feedback.

--
Pablo