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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <4BAB6FE1.7030304@linux-ipv6.org>
Date:	Thu, 25 Mar 2010 23:14:57 +0900
From:	YOSHIFUJI Hideaki <yoshfuji@...ux-ipv6.org>
To:	Jozsef Kadlecsik <kadlec@...ckhole.kfki.hu>
CC:	Patrick McHardy <kaber@...sh.net>,
	Shan Wei <shanwei@...fujitsu.com>,
	YOSHIFUJI Hideaki <hideaki.yoshifuji@...il.com>,
	David Miller <davem@...emloft.net>,
	Alexey Dobriyan <adobriyan@...il.com>,
	Yasuyuki KOZAKAI <yasuyuki.kozakai@...hiba.co.jp>,
	"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
	netfilter-devel@...r.kernel.org,
	YOSHIFUJI Hideaki <yoshfuji@...ux-ipv6.org>
Subject: Re: [RFC PATCH net-next 0/7 v2]IPv6:netfilter: defragment

(2010/03/25 18:23), Jozsef Kadlecsik wrote:

>> 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?

Got it.  INVALID seems fine to me so far
while further consideration might be needed.

>> 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.

Argh, more explanation.

If you unconditionally send ICMPv6, behavior would be
broken.

If you do really want to send ICMP in netfilter,
you could pretend additional rules in filter table.
For example, ICMP to be sent back only if other exthdrs
do not exist, and other packets to be silently dropped.

This cannot be our clean/final/full answer, so I said it'd
be better to introduce per-exthdr hooks in longer term.

Regards,

--yoshfuji
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html