From owner-freebsd-hackers Tue May 6 20:09:07 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id UAA26681 for hackers-outgoing; Tue, 6 May 1997 20:09:07 -0700 (PDT) Received: from cheops.anu.edu.au (avalon@cheops.anu.edu.au [150.203.76.24]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id UAA26675 for ; Tue, 6 May 1997 20:09:04 -0700 (PDT) Message-Id: <199705070309.UAA26675@hub.freebsd.org> Received: by cheops.anu.edu.au (1.37.109.16/16.2) id AA013204428; Wed, 7 May 1997 13:07:08 +1000 From: Darren Reed Subject: Re: divert still broken? To: danny@panda.hilink.com.au (Daniel O'Callaghan) Date: Wed, 7 May 1997 13:07:08 +1000 (EST) Cc: freebsd-hackers@FreeBSD.ORG In-Reply-To: from "Daniel O'Callaghan" at May 7, 97 12:53:19 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk In some mail from Daniel O'Callaghan, sie said: > > > > On Wed, 7 May 1997, Darren Reed wrote: > > > In some mail from Archie Cobbs, sie said: > > > > > > Ah, now I see.. remembering that FO is stored in bytes/8 (as you pointed > > > out), it's not possible for a UDP header to be split across fragments > > > in any way (since it's only 8 bytes long)... correct? > > > > Tell me, what does ipfw do with a packet that says "more fragments" but > > the packet has no data (i.e. _no_ header at all), and is UDP ? > > Nothing, AFAIK. "nothing" ? Maybe you should walk through the checking routine with such a packet. I'm pretty sure it will get treated as if it is normal length (but I don't have source handy). > > Best thing, I think for ipfw to do, is drop any packets where the header(s) > > are split across multiple packets (i.e. aren't all in the one you have). > > With the TCP flags problem you could send complete headers in the first > packet, and overwrite the flags in the second. Yes yes yes....who do you think discovered this problem, two years ago ? ;) > A UDP packet which has no data at all, is an interesting thought, but > what use would it be? A follow-up fragment would have to have FO=0, > which indicates a new packet. If the ip_id field is the same then it is the same packet. > > I don't recall ipfw doing any ICMP filtering to worry about that. > > Can you elaborate on the dangers a bit, please. I guess it might be a If you are expecting all of the ICMP header to be there, then again you have to worry about whether or not a short fragment is what you have. > way of tying up kernel resources, by sending lots of fragments which say > "more fragments coming", and never send them. Oh, that's a well known denial of service attack.