Date: Sun, 3 Sep 2000 17:32:00 -0700 From: Dragos Ruiu <dr@kyx.net> To: Bill Fumerola <billf@chimesnet.com>, Darren Reed <avalon@coombs.anu.edu.au> Cc: Robert Watson <rwatson@FreeBSD.ORG>, cjclark@alum.mit.edu, "Crist J . Clark" <cjclark@reflexnet.net>, Nicolas <list@rachinsky.de>, freebsd-security@FreeBSD.ORG Subject: Re: ipfw and fragments Message-ID: <0009031819571V.20066@smp.kyx.net> In-Reply-To: <20000903173136.S33771@jade.chc-chimes.com> References: <Pine.NEB.3.96L.1000903094614.69440A-100000@fledge.watson.org> <200009032010.HAA15013@cairo.anu.edu.au> <20000903173136.S33771@jade.chc-chimes.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, 03 Sep 2000, Bill Fumerola wrote: > On Mon, Sep 04, 2000 at 07:10:46AM +1100, Darren Reed wrote: > > > It never reassembles and doesn't hold them in a buffer until they're > > all received either. > > Which I still think is the proper behavior for both ipfw and ipfilter. > You don't have to buffer until they're reassembled. If you want to be rigorous, you may have to buffer in the case when you don't receive the first segment first (in which case you would have to buffer until you received the first fragment with the headers that will let the firewall decide if it should let the fragments through or not) but in practice this is an extreme corner case, so imho, you can cheat a little and use a heuristic and say you won't buffer and if you don't receive the first frag first too bad (because in practice mis-sequencing almost never occurs in the wild) - I don't know if there are any RFC rules regarding this anyway, so you may even be able to declare this correct behaviour. :-) The only thing you have to store is which fragment addresses you've decided to let through. There is no actual reassembly (or buffering) necessary at the firewall level, just an additional lookup for fragments(and only fragments) but there is a need for some context and state through that lookup. I've been looking at fragmentation for IDSes and my belief is that the performance impact of this feature can be similarly minimized or made negligible if designed correctly into firewalls too. Otherwise, we might as well try to change IP and ban IP level fragmentation, but who knows what breaks then.... And let me paint a scenario of why this might be important because the future may see more fragmentation being used: To achieve high throughput rates without a ridiculous amount of packet overhead on the hosts for high speed networks (think 10GigE) many vendors are talking about increasing max ethernet frame sizes to 64k (I think some already support it). When dealing with monstergrams like that, being able to implement IP level fragmentation is a win for reducing implementation cost and translation. It's conjecture, but it may even become _necessary_ to use fragmentation for achieving high thoughput (use large packet sizes) bridged over legacy smaller ethernet packets at the client interface. I think that firewalls should deal with fragments correctly, because it may become more important in the future, and because the RFCs are written that way today. I'm planning on making sure the next firewall I build (which looks like it's going to be ipf based from what I've learned here) works correctly with regard to this, as to what the remainder of the net does... (But if any patches arise, I'll be glad to provide them to anyone else that shares my opinion about this. :-) cheers, --dr -- dursec.com ltd. / kyx.net - we're from the future pgp fingerprint: 18C7 E37C 2F94 E251 F18E B7DC 2B71 A73E D2E8 A56D pgp key: http://www.dursec.com/drkey.asc 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?0009031819571V.20066>