Re: [RFC PATCH net-next 0/7 v2]IPv6:netfilter: defragment

[YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>]

(2010/03/24 5:10), Jozsef Kadlecsik wrote:

> On Wed, 24 Mar 2010, YOSHIFUJI Hideaki wrote:
>
>>> In this case without conntrack, IPv6 would send an ICMPv6 message,
>>> so in my opinion the transparent thing to do would be to still send
>>> them. Of course only if reassembly is done on an end host.
>>
>> Well, no.  conntrack should just forward even uncompleted fragments
>> to next process (e.g. core ipv6 code), and then the core would send
>> ICMP error back.  ICMP should be sent by the core ipv6 code according
>> to decision of itself, not according to netfilter.
>
> But what state could be associated by conntrack to the uncompleted
> fragments but the INVALID state? In consequence, in any sane setup, the
> uncompleted fragments will be dropped silently by a filter table rule
> and no ICMP error message will be sent back.
>
> Therefore I think iff the destination of the fragments is the host
> itself, then conntrack should generate an ICMP error message. But that
> error message must be processed by conntrack to set its state and then
> the fate of the generated packet can be decided by a rule.

Well.... no.

First of all. in "sane" setup, people should configure according
to their own requirements.  They may or may not want send back
icmp packet.  And, even if the core is to send icmp back, the
state would be correctly assigned.

We cannot (and should not) do something "cleaver" (excluding
packet drops) in conntrack in PRE_ROUTING chain.

One reason is that in PRE_ROUTING context, we can NOT determine
if the address we see in the IP header is really the final
destination.  The overall situation is the same even if the
routing entry corresponding the "current" destination points
the node itself, or even if the node is configured as host.

It might seems that we could do something in the "filter"
table in LOCAL_IN, FORWARD or LOCAL_OUT (after routing header
process).

But well, we unfortunately cannot do this (at least
automatically) because even in LOCAL_IN, the final
destination has not been decided until we process all
of extension headers.

Sending ICMP in netfilter (especially in conntrack) is too
patchy, and is not right.  If we do the right thing (and
I believe we should do so),  I'd propose to have hooks
around handlers inside ip6_input_finish().

...I remember that I was thinking about this before.

For my conclusion, first option is just to drop
uncompleted fragments as we do today.  Second option
would be  to forward them to the next process so that
core code could send ICMPv6 etc. or, we could have
new code to send ICMPV6_TIME_EXCEED in REJECT target.
In longer term, I think it is better to introduce
per-exthdr hooks.

Regards,

--yoshfuji