Date: Mon, 15 Nov 1999 14:55:09 -0800 (PST) From: "Eric J. Schwertfeger" <ejs@bfd.com> To: cjclark@home.com Cc: ipfw@FreeBSD.ORG Subject: Re: TOS support for FreeBSD Message-ID: <Pine.BSF.4.10.9911151422410.35089-100000@harlie.bfd.com> In-Reply-To: <199911141756.MAA57969@cc942873-a.ewndsr1.nj.home.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, 14 Nov 1999, Crist J. Clark wrote: > Hmmm... Personally, I would feel somewhat hesitant about adding it to > IPFW. I'm not usually one to worry much about "slippery slopes," but > once we add something to IPFW that actually modifies packets, where > does it end? To my knowledge, none of the IPFW options in presently in > existence change the contents of a packet. IPFW > accepts/drops/forwards/diverts a packet, but it does not change > it. To me, this simple set of abilities is a nice way to partition off > what IPFW does. We do not want rampant featurism in a kernel module > (not that adding this one thing would be, but it would be nice to > rewrite destinations of forwarded packets, and it'd be nice to...) > > The trouble is, where would you add this TOS rewrite?... Maybe a tool > that IPFW diverts the packets of interest to? > > Just MHO and $0.02. As long as we're discussing the future of ipfw, there's a few things I'd like to be able to do, that may be able to be used by somebody else. I use FreeBSD and KAME IPSec to create VPNs. However, I've found a few minor problems. Some of which are out of the scope of IPFW, unless you want to change the way KAME integrates into the FreeBSD stack. On the other hand, one very useful ability, which seems like it would be non-obtrusive enough, is the ability to use mbuf flags in addition to the existing packet options. The reason I say this is because both KAME IPSec and SKIP use mbuf flags to indicate that they've already seen a given packet. This is important, because on our firewalls that wind up in an environment where you can't depend on anything about the outside traffic (such as a cable-modem environment, where other users can and do send arbitrary packets to other computers just to see what happens), our first ipfw rule is usually to reject anything that isn't coming in to our specific address. People that have never dealt with cablemodems probably wouldn't believe the amount of... crap that arrives supposedly for your computer. Pings to network addresses, UDP packets to network addresses with the port set to one of the UDP-small services ports, etc. Until the local Cable Co started segmenting their traffic, 95% of the traffic that came into the computer via the ethernet cable was stuff unrelated to that computer, and that isn't even in promiscuous mode, which would be worse, since the cable modems are dumb bridges. VPN breaks this, because on the second pass around, we have no way of knowing that packet X, which appears to be coming in to a "protected address" came in through a VPN connection. Being able to bypass this check only for packets with the appropriate flag in the mbuf structure would let us feel better, because we could put that rule back in. Now, for a total change of scope, I've got some rather pie-in-the-sky ideas that I don't even know are possible, along the lines of an ipfw rule that says "do IPSec/VPN translations now" so that IPSec/SKIP reinjection of the packet back into the IP stack isn't necessary. This would definitely be something more like what you're discussing here, some way to pass the packet off to a kernel module or such, and continuing on when the module returns a resulting packet, similar to how IPDIVERT works now, but in kernel space. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ipfw" 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.4.10.9911151422410.35089-100000>