Date: Mon, 27 Apr 1998 00:38:19 -0700 (PDT) From: Julian Elischer <julian@whistle.com> To: hackers@FreeBSD.ORG Subject: RFC: IPFW/DIVERT change suggestion. Message-ID: <Pine.BSF.3.95.980427001717.21604K-100000@current1.whistle.com>
next in thread | raw e-mail | index | archive | help
When we write the DIVERT facility we made a rather foolish design decision and I'd like to suggest a change that would alter the semantics of DIVERT/IPFW to fix it.. here is the problem: If you divert a packet out to a utility (e.g.NATD) then when it re-injects the packet, it is given an 'immunity' to that firewall rule, so that it won't be REDIVERTED again. this is because reinjected packets are resubmitted to the firewall. This precludes the use of more than one DIVERT filter. consider: A packet is diverted by rule 100 to utility A (e.g. natd). On reinjection, it bypassed rule 100 and is diverted at rule 200 to utility Y (e.g. cryptd). On reinjection again, it has lost it's Immunity to rule 100 so it's diverted to utility X (which will probably throw it away). Either one of the filters will discard it, or it will enter an infinite loop. What can we do about this? 1/ change the semantics of reinjection so that the number presently used to indicate the rule to be immune to, is interpretted as the rule after which processing should restart. '1' would indicate "start again at the beginning. returning the same number as reported by the utility on reception (we would report the rule number rather than the port number) would make processing restart at the next rule after the divert. By specifying the correct number you could make processed packets jump into a special set of rules (for example). All present programs need to set the value to that they received, which they transparently pass because if they didn't they would get rediversion. thus all existing programs would get teh behaviour of continuing the examination of packets at the next rule after the divert. This does tie ipfw and divert closer together. 2/ remember the last N packets diverted, and assign each an ID which can be associated with the returned packet, and which could be use to track where in the filter it was. (I'm not crazy about this one, but it could be done) The ONE positive point for this would be that it might be possible to store a 'stack' for each packet so that we could add 'gosub' (heh) to ipfw.. (just seeing if you're reading) (any other ideas?) julian To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.3.95.980427001717.21604K-100000>