Subject: Re: Status of the Ipsec6 SoC
To: Alwe MainD'argent <alwe.maindargent@gmail.com>
From: Jonathan A. Kollasch <jakllsch@kollasch.net>
List: tech-net
Date: 08/26/2006 11:19:26
--z6Eq5LdranGa6ru8
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Fri, Aug 25, 2006 at 10:00:47PM +0200, Alwe MainD'argent wrote:
> Hi list.
>=20
> I want to give you a little overview of what I have done during this=20
> project.
>=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=
=20
>   tcp )
>=20
> 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.
>=20
> 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.
>=20
> 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/ .
>=20
> Please give me all your feedback, positive and not :)
>=20
> 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:

node A:

spdadd B A any -P in ipsec
ah/transport//require
esp/transport//require
ipcomp/transport//require;

spdadd A B any -P out ipsec
ipcomp/transport//require
esp/transport//require
ah/transport//require;


node B:

spdadd A B any -P in ipsec
ah/transport//require
esp/transport//require
ipcomp/transport//require;

spdadd B A any -P out ipsec
ipcomp/transport//require
esp/transport//require
ah/transport//require;


(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
destination.

Oh well, I suppose I should turn on debugging and do some more
tests.

	Jonathan Kollasch

--z6Eq5LdranGa6ru8
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (NetBSD)

iD8DBQFE8HSOOjx1ye3hmokRAhgCAJ9ab/bdRdV5UQP/CUlR7GT+rVEF1QCfeasW
94P2CqhxQhyrKgTK1nB5Ey8=
=NL0W
-----END PGP SIGNATURE-----

--z6Eq5LdranGa6ru8--