[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

packet filtering as a virtual machine

Has anyone thought of modeling packet filtering/translation/queueing
as a virtual machine?  I have been thinking about how to generalize
some of the current operations, and it seems to me that a virtual
machine with operations tuned for common packet judo would be a handy
unifying architecture.  I'm imagining something like the state machine
in a bpf, with the ability to match as well as alter a packet, and
modify its metadata (tag, queue, etc.)
The current operations could be easily generalized; for example,
remapping a src IP via nat becomes a "IP remap" operation, which can
work on both src or dst, both in and out, etc.  Additionally, you
could have string or regex match operations*, equal-length replacement
operations, maybe even unmatched-length replacement opcodes. 
Assigning to a queue or assigning a tag could be conditional based on
prior opcodes, seperating the semantics of matching and assignment.
[*] Let's not get into a flame war over packet-by-packet string match.
 I'm well aware it won't do to TCP segments what some people want, but
we can't be worse off by having more powers, however imperfect they
may be.
Of course, tapping this power would be a challenge; the
generalizations that it suggests will tax simple config file
languages; to that end, different filter languages could spring up,
with traditional pf.conf being one of them retained for backwards
compatibilty reasons and also because it's pretty good already.
We already have an example of how to code such a virtual machine in
the bpf code.  If we really want to get fancy, we can examine the
structure of more complex virtual machines such as the JVM or mono. 
There is undoubtedly a fair amount of work in this area which could be
brought to bear.
There might be some performance penalty of course, and perhaps
selection between the monolithic packet filter and a virtual machine
could be a compile-time kernel option.  However, I think the
flexibility this would allow would outstrip performance concerns; see
the quote in my signature for how I feel about performance.  In the
end, simple virtual machine programs may be able to out-perform
data-driven monolithic configs by not going through as many failed
conditionals, but that is strictly conjecture and the devil is in the
One exciting advantage of adopting a virtual machine model is that we
could even implement JIT compilation for packet filter rules! 
Additionally, performing optimizing transformations on virtual machine
instructions would probably be more straightforward than on
data-driven execution of C code since the execution path is explicitly
encoded within them.
http://www.lightconsulting.com/~travis/  -><-
"We already have enough fast, insecure systems." -- Schneier & Ferguson
GPG fingerprint: 50A1 15C5 A9DE 23B9 ED98 C93E 38E9 204A 94C2 641B