Date: Wed, 7 May 1997 07:51:30 +1000 (EST) From: Darren Reed <avalon@coombs.anu.edu.au> To: archie@whistle.com (Archie Cobbs) Cc: zbs@softec.sk, freebsd-hackers@FreeBSD.ORG Subject: Re: divert still broken? Message-ID: <199705062157.OAA07869@hub.freebsd.org> In-Reply-To: <199705061827.LAA16912@bubba.whistle.com> from "Archie Cobbs" at May 6, 97 11:27:57 am
next in thread | previous in thread | raw e-mail | index | archive | help
In some mail from Archie Cobbs, sie said: > > >I'm doing some more work on ipfw and divert to solve a need we have... > > >and planning on making these changes (how much gets checked in to be > > >determined later by group consensus, but patch will be available): > > > > While you are at it, would you please have a look at > > fragmented packets processing. Currently (2.2.1-RELEASE) > > IP packets with fragment offset > 0 can match TCP and UDP > > source port and destination port rules (but not TCP flags). > > This is clearly wrong, since TCP and UDP ports are always > > in the first fragment of a fragmented packet. > > Yes.. I'll fix this. > > But it brings up another question.. how should we defend against > UDP packets that are fragmented into a very small fragment (that > doesn't contain the whole header) followed by the rest of the packet? > > Note this is not a problem for TCP, thanks to our implementing the > recommendation of RFC 1858. > > Should ipfw be able enforce a "minimum" initial fragment length? > What is the best strategy here? > > Or maybe I'm missing something obvious that makes this not a problem. So long as the packet is a fragment, is at offset 0, then for UDP, it is either not going to have any header data (ip_len == ip_hl << 2) or it will have at least both ports (first 4 bytes of the header) - well it should as fragmenting of data is done on 8 byte boundaries. The problem with TCP is getting to the th_flags field... Darren
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199705062157.OAA07869>