From owner-freebsd-hackers Thu Jul 10 17:17:23 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id RAA06120 for hackers-outgoing; Thu, 10 Jul 1997 17:17:23 -0700 (PDT) Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id RAA06115 for ; Thu, 10 Jul 1997 17:17:19 -0700 (PDT) Received: (from daemon@localhost) by alpo.whistle.com (8.8.5/8.8.5) id RAA05614; Thu, 10 Jul 1997 17:16:14 -0700 (PDT) Received: from current1.whistle.com(207.76.205.22) via SMTP by alpo.whistle.com, id smtpd005612; Fri Jul 11 00:16:13 1997 Message-ID: <33C57AAB.42877E5C@whistle.com> Date: Thu, 10 Jul 1997 17:13:31 -0700 From: Julian Elischer Organization: Whistle Communications X-Mailer: Mozilla 3.0Gold (X11; I; FreeBSD 2.2-CURRENT i386) MIME-Version: 1.0 To: Archie Cobbs CC: owensc@enc.edu, freebsd-hackers@FreeBSD.ORG, ari.suutari@ps.carel.fi Subject: RFC: IPFW-DIVERT change. WAS:[ipfw rules processing order..] References: <199707102329.QAA04387@bubba.whistle.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk 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