A radical restructuring of IPsec...

[Robert Watson]

On Sat, 7 Apr 2007, Kris Kennaway wrote:

> On Fri, Apr 06, 2007 at 04:49:01PM +0200, Ivan Voras wrote:
>> gnn at freebsd.org wrote:
>>
>>> The patch removes Kame derived IPsec from the tree, and adds v6 support to 
>>> FAST_IPSEC.  The IPSEC kernel option is removed, but the FAST_IPSEC option 
>>> remains. This is a test patch and has a known problem with routing packets 
>>> through a node.  Nodes can operate in a host mode, that is they are the 
>>> endpoint of a tunnel.
>>
>> Just a quick question: Is the reason for this simplification, performance, 
>> cleanup (I see spl...() functions removed), or something else?
>
> KAME IPSEC is both giant-locked and lower performance than fast IPSEC (which 
> also integrates with crypto hardware devices).  The missing piece from the 
> latter is what George has implemented, namely IPv6 support.

Just to be specific here -- while most of the network stack is MPSAFE, there 
are a few straggling components that, when compiled into the kernel, require 
the entire network stack to run with the Giant lock.  KAME IPSEC is one of 
those components, so if you compile KAME IPSEC into your kernel, you see a 
significant performance loss.  The FAST_IPSEC implementation has been MPSAFE 
since inception, I believe.

Eliminating the support infrastructure for non-MPSAFE protocols is a goal for 
7.x, but may not be one we reach.  Some of the other straggling components 
are:

- i4b
- netatm (Skip Ford is working on this)
- IPX over IP tunneling (I have a patch, but no volunteers to test it)

Of these, i4b is the most worrying since, to date, no one has expressed 
interest in eliminating its Giant dependency.  This means that its future is 
not bright.

Robert N M Watson
Computer Laboratory
University of Cambridge