Re: RFC: netfilter: xtables: add CT target

[Patrick McHardy <kaber@trash.net>]

Jozsef Kadlecsik wrote:
> On Wed, 20 Jan 2010, Patrick McHardy wrote:
> 
>> Jozsef Kadlecsik wrote:
>>> On Tue, 19 Jan 2010, Patrick McHardy wrote:
>>>
>>>> Adding an event mask to the ecache extension also looks unproblematic.
>>>> You could then use a rule like this:
>>>>
>>>> iptables -t raw .. -j CT --ctevents new,related,protoinfo,helper
>>>>
>>>> or something like that. Are the existing event types fine grained
>>>> enough for this?
>>> The possible events were cut back strongly and now the conntrack state 
>>> changes ASSURED and SEEN_REPLY cannot be distinguished. In my opinion 
>>> either SEEN_REPLY should not trigger an event at all or IPCT_ASSURED 
>>> should be put back.
>> I think it makes sense to generate an event for SEEN_REPLY since
>> its a synchronizable event (ctnetlink can also set the SEEN_REPLY
>> bit). I'm not opposed to add back IPCT_ASSURED, but I'm wondering,
>> in what case would userspace be interested in only one of both
>> updates?
> 
> I have only one case, but I think that's worth it: "sparse" conntrack 
> replication. Start replicating the conntrack entry after it reached the 
> ASSURED state and that way it's SYN-flood resistant. (Of course conntrack 
> could filter out the NEW/SEEN_REPLY state changes and wait for ASSURED, 
> but then the events are just sent unnecessarily.)

Sounds reasonable :) I'll add back the IPCT_ASSURED bit and will
post the entire series for review.