From owner-freebsd-ipfw Mon Nov 15 13:55:46 1999 Delivered-To: freebsd-ipfw@freebsd.org Received: from cc942873-a.ewndsr1.nj.home.com (cc942873-a.ewndsr1.nj.home.com [24.2.89.207]) by hub.freebsd.org (Postfix) with ESMTP id 0FA631513E; Mon, 15 Nov 1999 13:55:04 -0800 (PST) (envelope-from cjc@cc942873-a.ewndsr1.nj.home.com) Received: (from cjc@localhost) by cc942873-a.ewndsr1.nj.home.com (8.9.3/8.9.3) id MAA57969; Sun, 14 Nov 1999 12:56:49 -0500 (EST) (envelope-from cjc) From: "Crist J. Clark" Message-Id: <199911141756.MAA57969@cc942873-a.ewndsr1.nj.home.com> Subject: Re: TOS support for FreeBSD In-Reply-To: from Brian Fundakowski Feldman at "Nov 13, 1999 09:50:35 pm" To: green@FreeBSD.ORG (Brian Fundakowski Feldman) Date: Sun, 14 Nov 1999 12:56:49 -0500 (EST) Cc: kris@hub.freebsd.org (Kris Kennaway), bvi@rucus.ru.ac.za (Barry Irwin), ipfw@FreeBSD.ORG Reply-To: cjclark@home.com X-Mailer: ELM [version 2.4ME+ PL54 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-ipfw@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Brian Fundakowski Feldman wrote, > On Sat, 13 Nov 1999, Kris Kennaway wrote: > > > On Sat, 13 Nov 1999, Barry Irwin wrote: > > > > > TOS is type-of-service, and is determined by bits 8->15 in the IP Header. [snip] > > > Linux ipchanis allows one to modify the tos bits on a packet providing it > > > matches certain rules, this is the functionality I was wondering was > > > avaliable in FreeBSD [snip] > For a modest price for time, I could have this in IPFW easily if you > give me a description of what functionality is that which you want. > Otherwise, I could put it on my list of things to add to the new IPFW > (damn, I really need to write that paper!) when I work on that; or, > I could get to it whenever I next get really bored :) 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. -- Crist J. Clark cjclark@home.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ipfw" in the body of the message From owner-freebsd-ipfw Mon Nov 15 14:55:18 1999 Delivered-To: freebsd-ipfw@freebsd.org Received: from horst.bfd.com (horst.bfd.com [12.9.219.10]) by hub.freebsd.org (Postfix) with ESMTP id 561E11519B for ; Mon, 15 Nov 1999 14:55:11 -0800 (PST) (envelope-from ejs@bfd.com) Received: from HARLIE.bfd.com (bastion.bfd.com [12.9.219.14]) by horst.bfd.com (8.9.3/8.9.3) with ESMTP id OAA02250; Mon, 15 Nov 1999 14:55:10 -0800 (PST) (envelope-from ejs@bfd.com) Date: Mon, 15 Nov 1999 14:55:09 -0800 (PST) From: "Eric J. Schwertfeger" To: cjclark@home.com Cc: ipfw@FreeBSD.ORG Subject: Re: TOS support for FreeBSD In-Reply-To: <199911141756.MAA57969@cc942873-a.ewndsr1.nj.home.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-ipfw@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG 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 From owner-freebsd-ipfw Mon Nov 15 15:12:20 1999 Delivered-To: freebsd-ipfw@freebsd.org Received: from pedigree.cs.ubc.ca (pedigree.cs.ubc.ca [142.103.6.50]) by hub.freebsd.org (Postfix) with ESMTP id 0B03614D98 for ; Mon, 15 Nov 1999 15:12:15 -0800 (PST) (envelope-from mjmccut@cs.ubc.ca) Received: (from ean@localhost) by pedigree.cs.ubc.ca (8.8.8/8.6.9) id PAA01161 for freebsd-ipfw@freebsd.org; Mon, 15 Nov 1999 15:12:13 -0800 (PST) X400-Received: by /PRMD=ca/ADMD=telecom.canada/C=ca/; Relayed; Mon, 15 Nov 1999 15:12:12 UTC-0800 Date: Mon, 15 Nov 1999 15:12:12 UTC-0800 X400-Originator: mjmccut@cs.ubc.ca X400-Recipients: non-disclosure:; X400-Content-Type: P2-1984 (2) X400-MTS-Identifier: [/PRMD=ca/ADMD=telecom.canada/C=ca/;991115151212] Content-Identifier: 16582 From: Mark McCutcheon To: freebsd-ipfw@freebsd.org Message-ID: <"16582*mjmccut@cs.ubc.ca"@MHS> Subject: Re: TOS support for FreeBSD MIME-Version: 1.0 (Generated by Ean X.400 to MIME gateway) Sender: owner-freebsd-ipfw@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sun, 14 Nov 1999 12:56:49 UTC-0500 Crist J. Clark wrote: > The trouble is, where would you add this TOS rewrite?... Maybe a > tool that IPFW diverts the packets of interest to? You're right, this functionality does NOT belong in ipfw. TOS-mediated preferential service for flows is a diffserv per-hop behaviour, and should be implemented as a queuing discipline. By good fortune, it already has been; this is one of the modes of CBQ (class-based queuing) as it appears in v2.0 of Kenjiro Cho's ALTQ package: http://www.csl.sony.co.jp/person/kjc/programs.html v2.0 runs mostly on ethernet and ATM NICs, but there is a new PPP link version (see website). Since wildcards may be used in the CBQ configuration filters, a flow may consist of just a protocol type and TOS mask. ALTQ is intended for UNIX-based router forwarding research, so it may seem a bit heavy-weight for a single user wanting to give minimum delay to telnet. On the other hand, it's not all that hard to set up, seems to work as advertised, and puts the queue control where it belongs. Caveat: I haven't used ALTQ in the common home-use scenario of a FreeBSD PC running ipfw and natd, so can't say whether there could be any adverse interaction between ALTQ and natd. Mark McCutcheon | UBC High-Speed Networking | To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ipfw" in the body of the message