Re: reverse processing order: NAT, IPsec ?

[David Young <dyoung%pobox.com@localhost>]

On Fri, Jun 12, 2009 at 03:35:29PM -0400, Thor Lancelot Simon wrote:
> On Fri, Jun 12, 2009 at 02:18:41PM -0500, David Young wrote:
> > <soapbox>
> > These difficulties sound like a symptom of the design flaw in NetBSD's
> > IPsec that we should not repeat: hard-coding hooks in the IP input
> > and output routines.  A design that re-used existing abstractions
> > to provide building blocks to the operator---for example, an IPsec
> > pseudo-interface where the IPsec processing occurs---would be more
> > versatile and transparent, and it would spare us some complexity in the
> > IP code.
> 
> OpenS/WAN did it this way on Linux.  It came with its own whole set of
> nastinesses, notably a huge profusion of interfaces on any kind of busy
> IPsec gateway.  I'm not sure it's really much better.

I don't see why there should be a profusion of interfaces if there isn't
a profusion already for other reasons, such as a profusion of tunnel
interfaces.

I think that the "nastiness" of a profusion of interfaces is more or
less a matter of taste.  The idea of a profusion of interfaces perturbs
me no more than a profusion of routes or policies or flows.

I'm open to other ideas of how to relieve the NetBSD IPsec operator of
the current design's inflexibility and opacity as compared with other
parts of our network stack.

Dave

-- 
David Young             OJC Technologies
dyoung%ojctech.com@localhost      Urbana, IL * (217) 278-3933