Date: Thu, 03 May 2001 16:06:01 +0000 From: Gunther Schadow <gunther@aurora.regenstrief.org> To: thorpej@zembu.com Cc: Fulvio Risso <risso@polito.it>, Luigi Rizzo <luigi@info.iet.unipi.it>, Darren Reed <darrenr@reed.wattle.id.au>, snap-users@kame.net, julian@elischer.org, freebsd-net@freebsd.org, ipfilter@coombs.anu.edu.au, altq@csl.sony.co.jp Subject: Re: [altq 839] Re: The future of ALTQ, IPsec & IPFILTER playing together ... Message-ID: <3AF181E9.1B73B69E@aurora.regenstrief.org> References: <200105030750.JAA44246@info.iet.unipi.it> <DAEBKLBDIOIBBIFCOHNKAEFNDLAA.risso@polito.it> <20010503083049.B17582@dr-evil.shagadelic.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Jason R Thorpe wrote: > > On Thu, May 03, 2001 at 10:15:36AM +0200, Fulvio Risso wrote: > > > Not only. > > BPF does not support: > > - stateful inspection > > - multiple return values (only 1/0) > > - multiple outputs (I want to know, for example the amount of traffic IP > > *and* TCP) > > My solution to this is to use the classifier as a "tool" for another > application. Logically, it looks like this: > > BPF > | > PACE > | > +----+----+ > | | > ALTQ PFIL > > I.e. you build a "Packet Filter" application on top of the classifier, > and ALTQ on top of the classifier, and the classifier is built on BPF. > The classifier provides some infrastructure that BPF does not, and BPF > itself remains simple, used only has the packet matching core. Hmm, so you are arguing gainst multiple return values and stateful inspection? I like simplicity, but wouldn't this impede the ability to produce high-performance classifiers? What about adding a state memory to the BPF VM and allowing the BPF VM to return an arbitrary long integer value. That value would index the action to take for filters, mutators, encapsulators, forwarders and queuers. Basically BPF would then become a finite state automaton. It is also conceivable that BPF would be allowed to edit the packet data. The BPF machine already seems to support that (can't you ST a value just as you can LD it?) This would be the basis for doing NAT or other things. That way, BPF could also communicate its "return value" by SToring a value in a field that's tagged on to the packet's mbuf that BPF accesses. This field would live with the packet buffer until the packet is pushed out to the device. That way, filters, NATers, ENCapsulaters and AHutethenticators and ALTQueuers could use that lable wherever they sit in the process, not requiring any reclassification. The only thing that needs to be done then is that either the BPF core finds a way to stich the carious altq.conf, ipf.conf, ipnat.conf, SPD rules + all dynamic rules invoked by NATers, ip_encap and other agents together (late binding, if you will), or we move towards maintaining all those static rules in one compilation unit (put cpp in front of it to have macros and #includes.) From my application/deployment/user perspective, I would *very* much appreciate the whole shabang of filter, NAT, encapsulation and queuing rules to be maintained in one consistent compilation unit rather than having a different end for each that I cannot make to really work together. This is sort of what I like about FreeBSD's IPFW (good work Luigi). But I would like to have the great BPF, ALTQ and IPF and SPD play together in that manner (because each of those has it's unique strengths in what they do -- do one thing, do it right.) regards -Gunther PS: just to be consistent with my "great unification theory" I would throw the packet routing machine into the game. Let BPF++ rules manage the router as well (what's a router different than a forwarder anyway?) Sorry for being radical :-) -- Gunther Schadow, M.D., Ph.D. gschadow@regenstrief.org Medical Information Scientist Regenstrief Institute for Health Care Adjunct Assistent Professor Indiana University School of Medicine tel:1(317)630-7960 http://aurora.regenstrief.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3AF181E9.1B73B69E>