Date: Sun, 3 Sep 2000 20:51:08 -0400 (EDT) From: Robert Watson <rwatson@FreeBSD.ORG> To: Nate Williams <nate@yogotech.com> Cc: Dragos Ruiu <dr@kyx.net>, cjclark@alum.mit.edu, "Crist J . Clark" <cjclark@reflexnet.net>, Bill Fumerola <billf@chimesnet.com>, Nicolas <list@rachinsky.de>, freebsd-security@FreeBSD.ORG Subject: Re: ipfw and fragments Message-ID: <Pine.NEB.3.96L.1000903204401.74864E-100000@fledge.watson.org> In-Reply-To: <200009031727.LAA03881@nomad.yogotech.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, 3 Sep 2000, Nate Williams wrote: > > 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. You're thinking of PMTU discovery :-). PMTU is the Pathwise Maximum Transmission Unit. Assuming only single-path routing and a path in a particular direction between two nodes, it's the least member of the set of MTUs traversed between the two hosts. PTMU discovery allows nodes to determine the largest packet size they can send without undergoing fragmentation. It's an estimate as the real PMTU is subject to routing an configuration changes, as well as the vaguarities of multi-path routing. My use of the term PMTU refers to the fact that although you can, in practice, treat the PMTU as constant, if a packet is sent that is too large, it may undergo multiple fragmentation in potentially fairly arbitrary ways, allowing no predictions to be made purely on knowledge of the PMTU. > 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. :) Fragmentation is a problem for all firewalls, in as much as (a) ambiguities in the IP spec can cause problems, and (b) without reassembly, it's not clear how policies should apply to fragments. For application proxy firewalls with reassembly, fragmentation is generally not a serious problem, except from the DoS perspective. From the perspective of packet filters, fragmentation can have a variety of nasty effects, ranging from information leakage (refered to by the original poster) to fragmentation attacks that allow the attacker to pass straight through the firewall regardless of policy on the firewall. Many traditional packet filtering firewall products have simply passed fragments un-hindered, relying on filtering on the first fragment to determine policy, assuming the host on the inside of the firewall will be able to handle all remaining cases. In practice, this works very poorly, and for an adequately knowledgeable attacker, is essentially like tissue paper from the protective perspective :-). Robert N M Watson robert@fledge.watson.org http://www.watson.org/~robert/ PGP key fingerprint: AF B5 5F FF A6 4A 79 37 ED 5F 55 E9 58 04 6A B1 TIS Labs at Network Associates, Safeport Network Services To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.NEB.3.96L.1000903204401.74864E-100000>