(usagi-users 01321) Re: First quick interop results between IABG's IPv6 enabled FreeSWAN and 6WIND Edge Device / FreeBSD

[Gerhard Gessler <gessler@xxxxxxx>]

Kazunori Miyazawa schrieb:
> 
> Hi,
> 
> Thank you for your announcement.
> 
> On Fri, 15 Mar 2002 11:28:54 +0100
> Gerhard Gessler <gessler@xxxxxxx> wrote:
> 
> > Hi all,
> >
> > IABG is pleased to announce that we have successfuly done first interop
> > tests between our IPv6 enabled FreeSWAN (1.91 based) and a 6WIND Edge
> > Device. Also interop tests between FreeBSD (4.3) and our IPv6 enabled
> > FreeSWAN have been successful.
> >
> That's nice. Our kernel and modefied pluto can also exchange the keys and
> communicate over IPv6 IPsec with KAME.
> However they can only use tranport mode yet. :-<
> 
> Additionally we have the problem that if USAGI and KAME hosts are on same
> link and configured address base policy, they fail to do neighbour discovery.
> Because KAME expect that neighbour discovery packet are also applied IPsec
> but USAGI cannot apply IPsec to NA packet, NS pacekt. We can avoid the problem
> with address and protocol based policy.
> We try to fix it.
> 

Ah, that might be the reason why we had to exchange pings before seting
up the SA's in order to let the ISAKMP negotiation take place. We
thought that this might be caused ba the rather ancient 4.3 FreeBSD we
used. But with your explanation, the seen behaviour makes sense. We
never digged into FreeBSD kernel to find more about this problem, as we
are very much Linux-based here :-)

> > The used scenario was an automatic keyed secured Subnet-to-Subnet
> > communication with 3DES for encryption and SHA1 for authentication (via
> > ESP).
> >
> > More detailed testresults, also with other configurations will follow.
> >
> 
> Does your kernel have the addresses as SA which are ends of tunnel?

Yes. We use the same semantic as FreeSWAN uses for IPv4. That means,
that we create entries in the SADB for every type (AH, ESP, IPIP) and we
group the together. Well, actually we don't create a special entry for
IPIP, but we store the given information within the AH and ESP entry.

One problem on our side is (this is, in my opinion, caused by our close
relationship to FreeSWAN), that we only receive information about the
outgoing flow. I.e. we know for the outgoing SA what subnet traffic
needs to be processed by it, but not for the incoming SA, because Pluto
generates this information only for outgoing SA's (with a SADB_X_ADDFLOW
message).

Best Regards,

	Gerhard


-- 
---------------------------------------------------
Gerhard Geßler

Communication Networks, IABG mbH
Einsteinstr. 20
85521 Ottobrunn, Germany

Telefon: +49 89 6088 - 2021
Fax: +49 89 6088 - 2845

E-Mail: gessler@xxxxxxx