netgraph related question

[Rajkumar S]

On 9/25/06, Max Laier <max at love2party.net> wrote:

> I'd like to work on both of these problems, provided there is enough
> interest and we can come up with a proper sollution for the hook-point
> problem.
>
> Any ideas?

I posted about this couple of days ago, posting it here again for
discussion. Here instead of a rule extension, I am suggesting adding a
new rule action. I am suggesting a new rule action because a pf
netgraph node also can deny/allow a packet, just like pass/block. This
also goes well with general pf syntax, such as keep state, log and
state full tracking options.

The netgraph link is established via a rule like:

queue in  on dc0 from 192.168.0.0/24 to 192.168.0.1

Where the packet will be passed to a netgraph node with full state
information about the TCP stream. If the packet is dropped in netgraph
then it's as good as a block, other wise it's a pass.

The packet should be passed to the netgrpah node with a tag
identifying the session to which this packet belongs, ie all packets
belonging to a single TCP session should have the same tag. This
session tracking is important because that can help in identifying
patterns that span multiple packets in userspace easily. The pf
netgraph node can then set tags as well as assign the packet to a
particular queue, for example slow down kazaa.

I guess there is tremendous interest in having L7 capabilities in pf,
as normal port based access control is in adequate to deal with
problems like skype and other p2p.

I have no idea about the implementation of what I have just said, so I
hope this makes some sense :)

raj