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: <4B42D1C3.3020207@trash.net>
Date:	Tue, 05 Jan 2010 06:44:35 +0100
From:	Patrick McHardy <kaber@...sh.net>
To:	Shan Wei <shanwei@...fujitsu.com>
CC:	David Miller <davem@...emloft.net>,
	netfilter-devel@...r.kernel.org,
	"netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: Re: [RFC][PATCH] IP: Send a fragment reassembly time exceeded packet
 when enabling connection track

Shan Wei wrote:
> Default, a host may send a fragment reassembly time exceeded packet
> (ICMP Time Exceeded Message with code value of 1) when defraging fragments timeout.
> But, when enabling connection track, a host can't send the packet.
> 
> Because, the module of nf_defrag_ipv4 selected by connection track is registered 
> in PRE_ROUTING HOOK and assembles all accepted fragments(here, not begin to routing).
> After defrag timeout, the host can't send fragment reassembly time exceeded packet, 
> because of lack of router information.
> 
> 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
> 
> So, the patch try to fix it with filling router information before sending fragment reassembly
> time exceeded packet when defrag timeout.

I guess the question is whether we really want to send an ICMP
message in this case. The above quote applies to end hosts,
while conntrack is also (probably more commonly) used on routers,
which normally shouldn't attempt reassembly. I can see no real
downside to this though except that it makes it quite easy to
discover firewalls, but that shouldn't be a real problem.
--
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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ