Charon-Pluto IKEv1 Interoperability » History » Version 14

« Previous - Version 14/24 (diff) - Next » - Current version
Andreas Steffen, 20.06.2012 20:42
Added missing features

Charon-Pluto IKEv1 Interoperability

Migration from Pluto to Charon

We've tried hard to support most pluto configurations in charon. But please keep in mind that IKEv1 in charon is a completely new implementation and that it might behave differently than IKEv1 in pluto.

Obsolete keywords

The ipsec.conf config setup section ceased to support any of the pluto specific keywords as well as plutostart and charonstart. NAT-Traversal is always enabled in charon, for both IKEv1 and IKEv2. The IKEv2 eap keyword has been removed.

Deprecated, but still supported keywords

The authby and xauth keywords are still supported, but deprecated. Please migrate your installation to the leftauth / rightauth keywords. XAuth is configured as multiple rounds using leftauth2 / rightauth2 keywords (i.e. leftauth=pubkey, leftauth2_=xauth). To configure the new Hybrid Mode, define _leftauth=xauth and rightauth=pubkey.

Perfect Forward Secrecy (PFS)

The pfs option has been removed and the default for IKEv1 has been changed from enabled to disabled. To enable PFS both IKEv1 and IKEv2 now use the same syntax, namely listing a Diffie-Hellman group in the ESP proposal, esp=aes128-sha1-modp2048.

Smartcards and PKCS#11

IKEv1 can use the same PKCS#11 backend as IKEv2, all pluto specific PKCS#11 options are obsolete.

Narrowing with rightsubnetwithin

The IKEv1 responder narrowing keyword rightsubnetwithin is not supported anymore, but is an alias for rightsubnet. The leftsubnet / rightsubnet definitions are automatically narrowed if required. Please be aware that IKEv1 does actually not support narrowing, and returning a smaller subnet than requested might confuse the initiator (but works fine with charon). To interoperate with other implementations, make sure your subnet definitions match exactly.

Missing Features

  • IKEv1 Mode Config Push Mode is not implemented yet. This might be an issue with Cisco Access Concentrators which usually force Mode Config Push Mode in the absence of XAUTH-based authentication.
  • Support of Cisco some quirks consisting of the Cisco-Unity vendor ID and tolerating surplus zero bytes in IKEv1 messages.
  • Support of X.509 attribute certificates defining group memberships or roles for both IKEv1 and IKEv2 is not completed yet, although most of the necessary code is alread in place.