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