Subject: Re: Status of the Ipsec6 SoC
To: Alwe MainD'argent <firstname.lastname@example.org>
From: Jonathan A. Kollasch <email@example.com>
Date: 08/26/2006 11:19:26
Content-Type: text/plain; charset=us-ascii
On Fri, Aug 25, 2006 at 10:00:47PM +0200, Alwe MainD'argent wrote:
> Hi list.
> I want to give you a little overview of what I have done during this=20
> So first the cool news :
> - Ipcomp now works on fast_ipsec
> - basic ipv6 traffic works on fast_ipsec ( with ah, esp, ipcomp or md5=
> tcp )
> But there are still some caveats. The biggest caveat is that
> fast_ipsec doesn't support extented header . The second is that there
> are no support for ipsec_nat_t too.
> So there are some improvements compared to the fast_ipsec in the tree
> but it doesn't support all the stuff that Kame stack supports.
> Now, it would be nice if some people can test the fast_ipsec ipv6 code
> in some more real situation. I have done some tests on emuled network
> but it is not the reality :). You can retrieve all the information
> about how to get a fast_ipsec6 kernel on my web page
> http://netbsd-soc.sourceforge.net/projects/ipsec6/ .
> Please give me all your feedback, positive and not :)
> I will continue to work on the code, to add the extended header
> support but I think it will need some big changes in the code, so I
> will post some notes about it on the list before to do anything.
I'm testing between a 3.99.21 KAME IPSEC, and a 3.0.1 userland
with a kernel with this new code (a GENERIC.FAST_IPSEC). I've
done some earlier tests of AH, ESP and IPcomp with two KAME
peers, ISTR it working well (except perhaps for IPv6, I'd have
to test it again to be sure). Anyway, when I try this with this
code, it does not work as I believe it should.
Here are my SPDs:
spdadd B A any -P in ipsec
spdadd A B any -P out ipsec
spdadd A B any -P in ipsec
spdadd B A any -P out ipsec
(duplicated with a -4 and a -6)
Racoon associates successfully. The problem is that this code
is unable to decapsulate a `ping -s 3856 FAST-IPSEC-host`, anything
smaller will work. Also, when it does work, the reply comes back
in multiple fragments, at what seems to be uncompressed size.
I had successfully done at least a `-s 5000` successfully w/ KAME.
And that's just IPv4. IPv6 is worse. The KAME peer will send
an appropriately sized packet. No matter what the size of the
incoming packet, the packet is not decapsulated. At least the
output path sort of works. Again the compression is apparently
not in use, but stuff does get sent, as is a reply from the
Oh well, I suppose I should turn on debugging and do some more
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (NetBSD)
-----END PGP SIGNATURE-----