From owner-freebsd-ipfw@FreeBSD.ORG  Tue May 25 02:17:40 2010
Return-Path: <owner-freebsd-ipfw@FreeBSD.ORG>
Delivered-To: freebsd-ipfw@freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34])
	by hub.freebsd.org (Postfix) with ESMTP id 089571065676
	for <freebsd-ipfw@freebsd.org>; Tue, 25 May 2010 02:17:40 +0000 (UTC)
	(envelope-from mjl@luckie.org.nz)
Received: from zombie.scms.waikato.ac.nz (mail.scms.waikato.ac.nz
	[130.217.241.36])
	by mx1.freebsd.org (Postfix) with ESMTP id C9CDB8FC19
	for <freebsd-ipfw@freebsd.org>; Tue, 25 May 2010 02:17:39 +0000 (UTC)
Received: from sorcerer.cs.waikato.ac.nz ([130.217.250.39])
	by zombie.scms.waikato.ac.nz with esmtps (TLSv1:AES256-SHA:256)
	(Exim 4.69) (envelope-from <mjl@luckie.org.nz>) id 1OGjNh-0002ri-PS
	for freebsd-ipfw@freebsd.org; Tue, 25 May 2010 13:56:33 +1200
Message-ID: <4BFB2E51.1000800@luckie.org.nz>
Date: Tue, 25 May 2010 13:56:33 +1200
From: Matthew Luckie <mjl@luckie.org.nz>
User-Agent: Thunderbird 2.0.0.23 (X11/20091127)
MIME-Version: 1.0
To: freebsd-ipfw@freebsd.org
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: IPFW flaws with IPv6 fragments
X-BeenThere: freebsd-ipfw@freebsd.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IPFW Technical Discussions <freebsd-ipfw.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw>,
	<mailto:freebsd-ipfw-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-ipfw>
List-Post: <mailto:freebsd-ipfw@freebsd.org>
List-Help: <mailto:freebsd-ipfw-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw>,
	<mailto:freebsd-ipfw-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Tue, 25 May 2010 02:17:40 -0000

Hi

I'm just wondering if I can interest anyone in an IPFW PR with a tested 
patch, which I submitted a few weeks ago.

http://www.freebsd.org/cgi/query-pr.cgi?pr=145733

The flaws that the patch fixes:

  - Rejection of packets with an IPv6 Fragmentation header if the packet
    is not actually fragmented (offset and mf both zero).  This type of
    packet is allowed by RFC 2460.

  - Rejection of fragments with offset != 0 if they are small (because
    the code tries to pullup a transport layer header which isn't there)

  - No check of the transport layer fields with for the first fragment
    offset zero because the mf bit is masked into the offset field.

I'm happy to address any concerns with the patch if there are any.

Thanks,

Matthew