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] [thread-next>] [day] [month] [year] [list]

Message-ID: <4B97D34C.4020509@gmail.com>
Date:	Thu, 11 Mar 2010 02:13:48 +0900
From:	YOSHIFUJI Hideaki <hideaki.yoshifuji@...il.com>
To:	Shan Wei <shanwei@...fujitsu.com>
CC:	Patrick McHardy <kaber@...sh.net>,
	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,
	"yoshfuji@...ux-ipv6.org >> YOSHIFUJI Hideaki" 
	<yoshfuji@...ux-ipv6.org>
Subject: Re: [RFC PATCH net-next 0/7 v2]IPv6:netfilter: defragment

Hi,

Shan Wei wrote:
>  This patch-set solves the problem that an end host with IPv6 connection track enable
> can't send an ICMP "Fragment Reassembly Timeout" message when defaging timeout.
> And supports MIB counter about fragments reassembly e.g. Ip6ReasmTimeout, Ip6ReasmReqds,
> Ip6ReasmOKs, Ip6ReasmFails.

Well, because the context of defragment are different
from standard ones (e.g., In netfilter, defragment can
happen even on forwarding path, and the result is always
thrown away anyway), I think it is not a good idea to
touch standard MIB here. However I'm okay to increment
other stats like InDiscards, OurDiscards and netfilter
specific stats.
On the other hand, I'd even say we should NOT send
icmp here (at least by default) because standard routers
never send such packet.

Regards,

--yoshfuji

> patch-1,2,3： Introduce net namespace to conntrack and share netns_frags with IPv6 stack.  
>           But, IPv6 conntrack and IPv6 stack still keep separate fragment queue.
>           Like IPv4, proc parameters of ip6frag_low_thresh, ip6frag_time and ip6frag_high_thresh
>           manage numbers and memory thresh size of both IPv6 conntrack fragment queue and 
>           IPv6 stack fragment queue.
> 
> patch-4: Send an ICMP "Fragment Reassembly Timeout" message and record MIB counter 
>          when defraging timeout.
> 
> patch-5,6,7: According to RFC4293, record MIB counter about fragments reassembly.
> 
> 
> This patch-set has been tested using IPv6 Ready Logo Phase-2 tool under host and router type.
> 
> ---
> Shan Wei <shanwei@...fujitsu.com> (7):
>       IPv6:netfilter: defrag: Handle sysctls about IPv6 conntrack defragment per-netns
>       IPv6:netfilter: defrag: Introduce per-netns to conntrack and kill nf_init_frags
>       IPv6:netfilter: defrag: Disable button half when reassembling a fragment 
>       IPv6:netfilter: Send an ICMPv6 "Fragment Reassembly Timeout" message when enabling connection track
>       IPv6:netfilter: Record MIB counter when reassembling all fragments
>       IPv6:netfilter: Record MIB counter after a fragment reached
>       IPv6:netfilter: Add IPSTATS_MIB_REASMFAILS MIB counter value when evicting fragment queue
> 
>  Documentation/feature-removal-schedule.txt     |   19 ++
>  include/linux/skbuff.h                         |    5 +
>  include/net/netns/ipv6.h                       |    1 +
>  net/ipv6/netfilter/nf_conntrack_l3proto_ipv6.c |    7 +-
>  net/ipv6/netfilter/nf_conntrack_reasm.c        |  221 +++++++++++++++++++-----
>  net/ipv6/route.c                               |    1 +
>  6 files changed, 208 insertions(+), 46 deletions(-)
> --
> 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

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