netdev - Re: [PATCH v2]IP: Send an ICMP "Fragment Reassembly Timeout" message when enabling connection track

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: <201001250057.o0P0v8E7021320@toshiba.co.jp>
Date:	Mon, 25 Jan 2010 09:57:06 +0900 (JST)
From:	Yasuyuki KOZAKAI <yasuyuki.kozakai@...hiba.co.jp>
To:	kaber@...sh.net
Cc:	shanwei@...fujitsu.com, davem@...emloft.net, kuznet@....inr.ac.ru,
	pekkas@...core.fi, jmorris@...ei.org, yoshfuji@...ux-ipv6.org,
	eric.dumazet@...il.com, david@...e-labs.org, jorge@...2.net,
	opurdila@...acom.com, netdev@...r.kernel.org,
	netfilter-devel@...r.kernel.org
Subject: Re: [PATCH v2]IP: Send an ICMP "Fragment Reassembly Timeout"
 message when enabling connection track


Hi,

From: Patrick McHardy <kaber@...sh.net>
Date: Fri, 22 Jan 2010 12:48:20 +0100

> Shan Wei wrote:
> > [PATCH v2]IP: Send an ICMP "Fragment Reassembly Timeout" message when enabling connection track
> > 
> > No matter whether connection track is enabled, an end host should send 
> > an ICMPv4 "Fragment Reassembly Timeout" message when defrag timeout. 
> > The reasons are following two points:  
> > 
> > 1. RFC 792 says:
> >    >>>> >> > >   If a host reassembling a fragmented datagram cannot complete the
> >    >>>> >> > >   reassembly due to missing fragments within its time limit it
> >    >>>> >> > >   discards the datagram, and it may send a time exceeded message.
> >    >>>> >> > > 
> >    >>>> >> > >   If fragment zero is not available then no time exceeded need be
> >    >>>> >> > >   sent at all.
> >    >>>> >> > > 
> >    >>>> >> > > Read more: http://www.faqs.org/rfcs/rfc792.html#ixzz0aOXRD7Wp
> > 
> > 2. Patrick McHardy also agrees with this opinion.   :-)   
> >    About the discussion of this opinion, refer to http://patchwork.ozlabs.org/patch/41649
> > 
> > The patch fixed the problem like this:
> > When enabling connection track, fragments are received at PRE_ROUTING HOOK.
> > If they are failed to reassemble, ip_expire() will be called. 
> > Before sending an ICMP "Fragment Reassembly Timeout" message, 
> > the patch searches router table to get the destination entry only for host type.
> > 
> > The patch has been tested on both host type and route type.
> 
> Looks good to me. Would you mind adding a similar change to IPv6
> (net/ipv6/netfilter/nf_conntrack_reasm.c)?

It sounds good. Please take care that IPv6 router does not reassemble
fragmented packets. IIRC the current nf_conntrack_{ipv6,reasm}.c
reassembles the cloned skbs for tracking, discard the cloned skbs after
tracking and forward the original skbs to IPv6 stack to keep the size of
fragmented packets.

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