On Thu, 25 Mar 2010, YOSHIFUJI Hideaki wrote: > (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. I meant the state of the fragmented packets. If we let the uncompleted fragments to enter conntrack, as far as I see their state will be INVALID. Or should we add an exception and set their state to UNTRACKED in conntrack? > We cannot (and should not) do something "cleaver" (excluding > packet drops) in conntrack in PRE_ROUTING chain. Actually, I have to agree with you. > 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. I agree with your conclusion too, except a few question. It is unclear for me how can you forward the packets to the next process: above you pointed out that in defrag/reassembly before conntrack we do not know yet whether the packets are destined to the host or not. So again, how would you let through the fragments on conntrack then? I don't know how could the REJECT target help in any way. This is not a simple case at all and I have to think that the "best" way just to drop the packets as we currently do. Best regards, Jozsef - E-mail : kadlec@xxxxxxxxxxxxxxxxx, kadlec@xxxxxxxxxxxx PGP key : http://www.kfki.hu/~kadlec/pgp_public_key.txt Address : KFKI Research Institute for Particle and Nuclear Physics H-1525 Budapest 114, POB. 49, Hungary -- To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
