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

Re: userland packet filtering

In message <20010530185331.A11387@arl.psu.edu>, Brandin L Claar writes:
>There's always bpf and tun, but I'm not sure they would be ideal in 
>the long run.  If anyone can explain otherwise, please do.  

Actually, bpf is not too horrible an idea if we get the one-copy BPF
stuff in the tree. The advantage is that all you have to do is turn
forwarding off, and start tapping all interfaces. No other kernel
support needed.

The other advantage of this is that a userland packet filter can be
implemented mostly independently and in parallel with any specialized
pseudo-device that'd provide potentially better support.

That said, writing such a device is a matter of less than 500 lines of
code (having done it twice, in different contexts). One that uses
memory mapping for data transfers is larger, but not too horrible.

>I think the development of userland firewall code would spur interest
>in developing more sophisticated features.  If efficiency truly became
>an issue, then time could be spent to port the code back into the 

A while ago, JI and I worked on an application layer firewall that
could look into RPC and NFS (among other things). Ugly hack, but it
worked. One way for speeding it up was to have an in-kernel rules

Nota benne: porting a userland filter to the kernel is not as trivial
as you might think at first, if only because you don't have to deal
with mbufs in userland (and one tends to "cheat" in those
circumstances, by using indices in the packet etc.) Not
insurmountable, but you have to keep that in mind.