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 details. 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
