PF - netgraph integration

[Max Laier]

On Monday 18 December 2006 00:03, Ermal Luçi wrote:
> i am writing a netgraph module to make PF communicate with netgraph
> subsystem and was wondering which method is better of handling PF tags
> on netgraph part, since they use strings for matching.
>
> Is it better patch ng_tag to handle strings too, like setting the type
> of hook to either PF tags compatible or normal(tag_id/current) one?
> Or just make an kinda aliasing of tag_id in ng_pf(the module i am
> writing) so when tags come from PF -> netgraph we assign a
> tag_id(consistent through netgraph) to the specified PF_tag, user
> configurable, and then revert to PF_tag when communicating from
> netgraph -> PF?

I think names are essential.  pf_ioctl.c has all the tools to handle the 
name -> u_int16_t translation and ref counting, so why not use that?

> Another issue is the way to handle rule parsing in PF when packets
> return from netgraph. Since PF cannot guarantee rule position/number
> to be the same after a reload of its ruleset.

There is a big conceptual difference between pf and ipfw in this respect.  
In my mind we only want to know that the packet has been through netgraph 
and pass or deny it - we hardly want to re-evaluate the ruleset.  I might 
be missing a point here, however.

>                                               One i have thought about 
> is use reinjecting the packet on the rules with one of M_PROTO[1-5]
> flags so we can distinguish if the packet have been sent once to
> netgraph(although i don't know if this is safe since other
> protocols/applications might use this flags)! Maybe intodruce a
> M_NETGRAPH_TO_PF flag like M_SKIP_FIREWALL, but i know this is not a
> preferable one since it inserts a special case to the kernel?!
> One forced solution is to create a 'static' anchor where rules about
> such packets can be created?!
> The last choice, maybe, is to pass the according rule to netgraph and
> refind it when sending the pakcket back to PF so it continues to the
> next rule, after the one we saved, but this seems really not
> efficent?!

This is tricky, as it taps into all kind of ref counting trouble.  I think 
the easiest is to extend "struct pf_tag" (or what ever other m_tag we 
will be using) to have an additional flags field which can be used to 
carry the information that the packet has been through netgraph already.

One other thing to think about is stateful filtering.  I think it can be 
interesting to pass all packets matchin a certain state to netgraph.  In 
addition you would want to be able to remove a state as netgraph 
identifies a connection as bad (think bittorrent e.g.).  Again the flag 
field could be used to carry that kind of information.

> Please can you help out with these issues i am trying to find a good
> solution but ideas would be welcomed :).

Find me off-list for more discussion, I'm very interested in this.  I 
might want to do one more vendor import before we put FreeBSD centric in, 
but your work is almost completely orthogonal to this (% pfctl syntax, 
maybe).

-- 
/"\  Best regards,                      | mlaier at freebsd.org
\ /  Max Laier                          | ICQ #67774661
 X   http://pf4freebsd.love2party.net/  | mlaier at EFnet
/ \  ASCII Ribbon Campaign              | Against HTML Mail and News
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-net/attachments/20061218/880324dc/attachment.pgp