Date: Mon, 9 Feb 1998 23:28:11 +1100 (EDT) From: Darren Reed <avalon@coombs.anu.edu.au> To: marcs@znep.com (Marc Slemko) Cc: archie@whistle.com, jonny@coppe.UFRJ.br, freebsd-hackers@FreeBSD.ORG Subject: Re: ipfw logs ports for fragments Message-ID: <199802091229.EAA21762@hub.freebsd.org> In-Reply-To: <Pine.BSF.3.95.980209002024.18733a-100000@alive.znep.com> from "Marc Slemko" at Feb 9, 98 00:27:11 am
next in thread | previous in thread | raw e-mail | index | archive | help
In some mail from Marc Slemko, sie said: > > > In the case of divert, count, skipto, etc. rules... what's the > > right answer?? There isn't one unless the kernel keeps track of > > all the fragments flying by, and matches them up with their > > corresponding initial fragments, and whether that initial fragment > > matched or not.. i.e., keeping a lot of extra information around. > > Even if it did that, it can't do it right. Not necessarily. It can do it right, but for it to happen right, the first fragment seen should be at offset 0. [...] > I have reservations about passing fragments, but that is the normal way > most filters do it in my experience so it is probably ok for a default. IP Filter doesn't do it that way, although you have to explicitly match on fragments in a rule to apply a result because it is a fragment. If you don't specify in your rule that a packet should (not) be a fragment then it shouldn't matter unless you are trying to compare your rule to data which can't be reasonably assumed to be in the fragment. [...] > > Come to think of it, the latter approach would not be that hard > > since the kernel is doing this already for locally routed packets, > > that is, reassembling packet fragments in a fragment queue. Moreover, > > "most" packets don't get fragmentized. It would spread more ugliness > > into ip_input.c, but at least the behavoir of the ipfw code would > > then be semantically correct... > > Reassembly sucks. If you have different parts of the fragment following > different paths, you lose bigtime. It probably violates any number of TCP > specs. I would have to think about it to decide if I hate it enough to > say it shouldn't be implemented at all or if there should just be a knob > to disable it. > > I think some of the Linux firewall code does reassembly, and there have > been numerous problems with it because of this. OTOH, some people also > like it because of this. Right. There are reasons that reassembly is done at "endpoints" rather than wherever it might be convienient. Darren To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199802091229.EAA21762>