Date: Thu, 10 Jul 1997 17:13:31 -0700 From: Julian Elischer <julian@whistle.com> To: Archie Cobbs <archie@whistle.com> Cc: owensc@enc.edu, freebsd-hackers@FreeBSD.ORG, ari.suutari@ps.carel.fi Subject: RFC: IPFW-DIVERT change. WAS:[ipfw rules processing order..] Message-ID: <33C57AAB.42877E5C@whistle.com> References: <199707102329.QAA04387@bubba.whistle.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Archie Cobbs wrote: > > > > > This is somewhat counter-intuitive to me. If this how it works, what is > > > > the reason for this design, since, as I think about it, there must be a > > > > performance penalty to this approach (multiple passes of rules). I had > > > > > > There are two reasons for this... > > > > > > 1. The new packet (post-diversion) may be different from the old packet > > > (pre-diversion), so it should be checked again to insure that it > > > doesn't avoid any rules that apply to it. This is a legitimate reason I guess.. not this against what I have to say below: > > Just to be devil's advocate, ;-) > > I think it could start processing at the next higher number > > after the one it was diverted from.. > > in other words it could have an implicit 'skipto (N+1)' rule > > > > the 'divert' word to me suggests that it should come back to the same > > place it left from. :) > > Yes! ``It could start processing at the next higher number.'' > I agree with that :-) > > The problem is that when the packet returns to the kernel from > user-land, that bit of state that says "this packet has already > seen rules 1-2000 (or whatever)" is lost, and you can't retrieve > it. The only way to do this would be for the user-land process > to send back some additional info that says "skip to rule 2000". > > Doable, but .. not very pretty? the divert sockets at the moment return from recvfrom() with a sockaddr containing: 1/ the IP address of the interface the packet came in from, and 2/ the ipdivert port number. sendto() needs a sockaddr with 1/ the interface ip addr to say it came from, and 2/ the ipdivert socket to NOT send it to (for loop avoidance) we could change the semantics to be: instead of the divert port number (the process knows thin information anyway), the rule number from which the diversion occured. Also, on sendto() the port number could represent the rule number to restart processing from. in other words, if the number was 1000, processing would begin at 1001. this would allow a divert process to leave the same number there that it received, and to avoid loops in that way because the process ing would start at the NEXT rule. present programs probably just copy this number across, so I guess it would be a transparent change to most of them. does it leave us open to security holes that were blocked before? (see the reason archie gave above)? is this a real threat? can it be proven to (not be)/(be) a threat? I think this would be an easy change to make. what do the USERS think (divert users). (I'd make the change if it seemed reasonable to everyone) divert sockets are still in their infancy (some hope they will die) so it' still a possible change. of course it ties them closer to ipfw and makes it less likely that ipfilter could ever be made to work with them. julian > ___________________________________________________________________________ > Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?33C57AAB.42877E5C>