Date: Wed, 7 May 1997 13:07:08 +1000 (EST) From: Darren Reed <avalon@coombs.anu.edu.au> To: danny@panda.hilink.com.au (Daniel O'Callaghan) Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: divert still broken? Message-ID: <199705070309.UAA26675@hub.freebsd.org> In-Reply-To: <Pine.BSF.3.91.970507124619.4479y-100000@panda.hilink.com.au> from "Daniel O'Callaghan" at May 7, 97 12:53:19 pm
next in thread | previous in thread | raw e-mail | index | archive | help
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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199705070309.UAA26675>