Date: Mon, 18 Dec 2006 03:20:30 +0100 From: Max Laier <max@love2party.net> To: freebsd-pf@freebsd.org Cc: freebsd-net@freebsd.org, Ermal =?iso-8859-1?q?Lu=E7i?= <ermal.luci@gmail.com> Subject: Re: PF - netgraph integration Message-ID: <200612180320.36956.max@love2party.net> In-Reply-To: <9a542da30612171503r2b032072j2acd1f48537081e1@mail.gmail.com> References: <9a542da30612171503r2b032072j2acd1f48537081e1@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
--nextPart1357570.rb6ijLCaO4 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Monday 18 December 2006 00:03, Ermal Lu=E7i 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=20 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. = =20 In my mind we only want to know that the packet has been through netgraph=20 and pass or deny it - we hardly want to re-evaluate the ruleset. I might=20 be missing a point here, however. > One i have thought about=20 > 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= =20 the easiest is to extend "struct pf_tag" (or what ever other m_tag we=20 will be using) to have an additional flags field which can be used to=20 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=20 interesting to pass all packets matchin a certain state to netgraph. In=20 addition you would want to be able to remove a state as netgraph=20 identifies a connection as bad (think bittorrent e.g.). Again the flag=20 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 :). =46ind me off-list for more discussion, I'm very interested in this. I=20 might want to do one more vendor import before we put FreeBSD centric in,=20 but your work is almost completely orthogonal to this (% pfctl syntax,=20 maybe). =2D-=20 /"\ Best regards, | mlaier@freebsd.org \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | mlaier@EFnet / \ ASCII Ribbon Campaign | Against HTML Mail and News --nextPart1357570.rb6ijLCaO4 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (FreeBSD) iD8DBQBFhfr0XyyEoT62BG0RAunpAJ0YbN4avMH/KLDNtHdt6p0ommyLmQCfR77v RjBlHJ9KH9sf+ohrcuqeyMA= =a+6l -----END PGP SIGNATURE----- --nextPart1357570.rb6ijLCaO4--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200612180320.36956.max>