Subject: Re: FAST_IPSEC [was Re: ipv6 source address selection]
To: None <email@example.com>
From: Arnaud Degroote <firstname.lastname@example.org>
Date: 09/26/2007 23:52:47
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.
- 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 ... :)