From owner-freebsd-security Sun Sep 3 10:28:14 2000 Delivered-To: freebsd-security@freebsd.org Received: from ns.yogotech.com (ns.yogotech.com [206.127.123.66]) by hub.freebsd.org (Postfix) with ESMTP id 806D437B423; Sun, 3 Sep 2000 10:28:12 -0700 (PDT) Received: from nomad.yogotech.com (nomad.yogotech.com [206.127.123.131]) by ns.yogotech.com (8.9.3/8.9.3) with ESMTP id LAA16320; Sun, 3 Sep 2000 11:27:47 -0600 (MDT) (envelope-from nate@nomad.yogotech.com) Received: (from nate@localhost) by nomad.yogotech.com (8.8.8/8.8.8) id LAA03881; Sun, 3 Sep 2000 11:27:46 -0600 (MDT) (envelope-from nate) Date: Sun, 3 Sep 2000 11:27:46 -0600 (MDT) Message-Id: <200009031727.LAA03881@nomad.yogotech.com> From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Robert Watson Cc: Dragos Ruiu , cjclark@alum.mit.edu, "Crist J . Clark" , Bill Fumerola , Nicolas , freebsd-security@FreeBSD.ORG Subject: Re: ipfw and fragments In-Reply-To: References: <0009030256211M.20066@smp.kyx.net> X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid Reply-To: nate@yogotech.com (Nate Williams) Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > My recollection was that fragments can be created that do not contain all > of the transport-layer headers. For example, although it should not > occur, ``naturally,'' it is possible to fragment a packet immediately > after the IP header but before the TCP-level port information is include. > Similarly, later fragments may begin at arbitrary points in the datagram, > based on how the PMTU caused the fragmentation at various points on the > path. Actually, isn't the purpose of PMTU to avoid the need to fragment the packet at intermediate routers? Since PMTU involves both endpoints of the link, thus allowing the originator to determine *if* a packet of a particular size can make it all the way from one end to the other w/out fragmentation. It seems that fragmentation is a real problem for stateless firewalls, but is a real problem that should be considered, especially since our existing IPFW is semi-stateful now. :) Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message