Re: PF - netgraph integration
- From: Max Laier <max@xxxxxxxxxxxxxx>
- Date: Mon, 18 Dec 2006 03:20:30 +0100
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@xxxxxxxxxxx
\ / Max Laier | ICQ #67774661
X http://pf4freebsd.love2party.net/ | mlaier@EFnet
/ \ ASCII Ribbon Campaign | Against HTML Mail and News
Attachment:
pgpNGm1mm39tx.pgp
Description: PGP signature
- References:
- PF - netgraph integration
- From: Ermal Luçi
- PF - netgraph integration
- Prev by Date: PF - netgraph integration
- Next by Date: maximum connections for mpd
- Previous by thread: PF - netgraph integration
- Next by thread: maximum connections for mpd
- Index(es):
Relevant Pages
|
|
