Subject: Re: FAST_IPSEC [was Re: ipv6 source address selection]
To: None <firstname.lastname@example.org>
From: Christos Zoulas <email@example.com>
Date: 09/26/2007 23:50:25
In article <20070926215247.GA7048@Amilo.at.home>,
Arnaud Degroote <firstname.lastname@example.org> wrote:
>On Wed, Sep 26, 2007 at 10:22:31AM -0700, email@example.com 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
>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.