Subject: Re: Non-IPSec Processing Point for ipf
To: Greg Troxel <gdt@ir.bbn.com>
From: Bill Studenmund <wrstuden@netbsd.org>
List: tech-net
Date: 04/22/2003 13:45:55
On 18 Apr 2003, Greg Troxel wrote:

>   So I was talking with Darren about NetBSD's inability to use ipf on
>   packets from another host if you're doing IPSec with that host, and we
>   eventually came round to the idea of adding another ipf processing point
>   before (on output) or after (on input) IPSec processing. This could
>   fairly easily be specified as another interface (though of course it
>   wouldn't really be an interface that you could assign an IP address to).
>
> I would be hesitant to model it as an additional interface, but I like
> the notion of an interface having two pfil hook places.  Another
> approach is to have 2 incoming (and outgoing) rulesets, where one is
> run before IPsec and the other after.

While we're at it, how about the ability to have rulesets for both before
and after NAT translation? While I don't care if packets come from outside
my net for boxes inside if we're _after_ NAT, but I _really_ care if they
are for the inside _before_ NAT.

> I don't see how having a way to specify ex0/wire-side-of-IPsec and and
> ex0/host-side-of-IPsec would break any v6 scoping rules, although I
> don't really understand the rules.  I would envision no creation of
> pseudo-interfaces, and no changing of rcvif.  One would add a pfil
> call somewhere in esp_input, perhaps adding a flag to specify that
> this is the host-side check.  I think this sidesteps all the issues
> about v6 scoping and the creation of extra interfaces.

...

> Here, there are a number of filter points:
>
>   I/W: input, wire side of IPsec
>   I/H: input, host side of IPsec
>   I/F: input, before forwarding
>   I/host: input, before delivery to host via a pcb

Add NAT to that too. :-)

Take care,

Bill