In article <20070926215247.GA7048@Amilo.at.home>,
Arnaud Degroote  <degroote@netbsd.org> wrote:
>On Wed, Sep 26, 2007 at 10:22:31AM -0700, jonathan@dsg.stanford.edu wrote:
>> 
>> In message <20070926083708.GA6092@Amilo.at.home>Arnaud Degroote writes
>> >On Tue, Sep 25, 2007 at 02:52:06PM -0700, Stone wrote:
>> >> In message <20070925211032.GA6028@serpens.de>Michael van Elst writes
>> >> >On Tue, Sep 25, 2007 at 01:55:26PM -0700, Jonathan Stone wrote:
>> >In NetBSD-4, you can use FAST_IPSEC and IPv6. I have pullup most of the
>> >current change into NetBSD-4 a long time ago.  There are still some
>> >issues in the implementation (the implementation doesn't work correctly
>> >with extension header in transport mode). Of course, the code needs to
>> >be tested, tested and retested in real configuration and I wait for any
>> >feedback good or bad :).
>> 
>> Thanks for the update and correction.
>> 
>> Are there other known gotchas besides the extension header in
>> transport mode?  Any Big/little endian issues?  I ask because one way
>> to get the testing would be to get people turning on FAST_IPSEC in
>> -current.
>
>For moment, I only have tested on le boxes. I will try to find a sparc64
>box to test FAST_IPSEC.  There are still some pr about FAST_IPSEC but I
>hope that I can fix most of them before NetBSD-4.
>
>I think we will get more feedback when NetBSD-4 will be released (and it
>is the reason why I pulled the IPv6 changes in NetBSD-4). I don't think
>IPSEC is really used by developpers on current.
>
>> There has also been talk of turning on FAST_IPSEC by default.  But the
>> consensus was that before doing that, we should measure send and
>> receive packet rates both with and without IPsec configured; and make
>> sure there's negligible difference in packet rates.  (On a CPU-limited
>> or memory-limited system, needless to say.  send/receive rates on
>> 10GbE would be one interesting way to measure :-))
>
>There are two questions : 
>  - can we replace Kame IPSEC by FAST_IPSEC (and so drop Kame IPSEC from
>    src). I think FAST_IPSEC is not far from Kame IPSEC about features
>    (-current has IPSEC_NAT_T support for FAST_IPSEC for example). But
>    the FAST_IPSEC stack need to be more used/tested for that.

I think that we should. There is little to gain by supporting 2 different
IPSEC stacks and there is the cost of maintaining them.

>  - can we enable FAST_IPSEC in GENERIC ? What is the impact on kernel
>    size and on the performance of network stack. I will do some
>    benchmarks later but for moment, I prefer focussing on bug fixes.
>    We have time before 5.0 ... :)

There were two reasons for not enabling IPSEC in generic.
1. performance. It would be nice to have a flag to globally enable or disable
it, so that the ip path does not slow down a lot when IPSEC is enabled but
there are no IPSEC policies.
2. the crypto/export issues. I don't think that this is an issue anymore.

christos