At Fri, 26 Jun 2009 09:40:48 +0200 (CEST), Hubert Feyrer
<hubert%feyrer.de@localhost> wrote:
Subject: running PFIL_HOOKS on decapsulated IPsec packets, too [was: Re:
reverse processing order: NAT, IPsec ?]
>
> On Thu, 25 Jun 2009, Greg A. Woods wrote:
> > After seeing the ultimately simple fix Hubert posted to re-enable PFIL
> > hooks for IPsec de-encapsulated packets I had a deja vu moment and I
> > think I can say this silliness has caused problems in other contexts as
> > well.
>
> I don't understand - do you mean it's silly to run PFIL hooks on
> de-encapsulated packets?
Sorry about the confusion. No, it's silly not to run PFIL hooks on
de-encapsulated IPsec packets.
The problem though is of course that PFIL users must have some way to
know that whether a packet has been de-encapsulated or not. This is
straight forward for when tunnel-mode IPsec is used because PFIL users
can distinguish which interface the packet is currently associated with.
However for connectionless IPsec the determination must be made based on
whether the authentication header has been removed or not. (IIUC IPF
rules, for example, could use "proto 51" to test whether the
authentication header was still present or not)
> Comments? Anyone familiar with the code? :)
I don't think an option of any kind _should_ be necessary provided that
all PFIL users always do have some way to make use of the MBUF tags you
mentioned or some other appropriate indicator. Presumably IPF and PF
both have the necessary functionality -- is that enough?
In any case though for backward compatibility purposes it may still be
necessary to preserve the existing semantics by default since folks with
existing IPF/PF rule sets will not necessarily have all the appropriate
conditions in place to distinguish encapsulated and de-encapsulated
packets, even if they are using tunnel-mode IPsec.
Personally I would also prefer a runtime control option if there is to
be one, rather than just a compile time option.
--
Greg A. Woods
Planix, Inc.
<woods%planix.com@localhost> +1 416 218-0099 http://www.planix.com/
Attachment:
pgpAgetwoiEZE.pgp
Description: PGP signature