[Swan] Cisco IOS XE Interoperability with Libreswan

[Paul Wouters]

On Wed, 15 Aug 2018, Reuben Farrelly wrote:

> 1. The documentation in the man page states that "the default IKE proposal 
> depends on the version of libreswan used".  The page also states that I can 
> look up the ipsec_spi(8) man page for values of --ike.

I'll remove that from the man page. It is wrong and the tool is a KLIPS
only tool.

> Finding out this information is entirely unfriendly to someone who is just 
> trying to get things to work.  Can the default proposals please be spelt out 
> in release notes or in a table in the FAQ so that this is easy to determine?

It would be more useful to be able to query for this in the code you
have, in case there are changes. I'll look into this.

> Assuming I want to hard set the Libreswan side, what should I be using in 
> this case?
>
> Cisco defaults as of IOS-XE 16.9.1 are:
>
> router-2#show crypto ikev2 proposal
> IKEv2 proposal: default
>      Encryption : AES-CBC-256
>      Integrity  : SHA512 SHA384
>      PRF        : SHA512 SHA384
>      DH Group   : DH_GROUP_256_ECP/Group 19 DH_GROUP_2048_MODP/Group 14 
> DH_GROUP_521_ECP/Group 21 DH_GROUP_1536_MODP/Group 5
> router-2#

We don't allow yet to specify IKEv2 style transform elements, so the
easiest would be to just pick a few common matchings from those lists
of elements. eg:

 	ikev2=insist
 	ike=aes256-sha2_512;dh19,aes256-sha2_512;dh14

>
> router-2#show crypto ipsec transform-set
> Transform set AES_GCM_256: { esp-gcm 256  }
>    will negotiate = { Transport,  },
>
> Transform set AES_CBC_256_HMAC_SHA1: { esp-256-aes esp-sha-hmac  }
>    will negotiate = { Transport,  },
>
> Transform set AES_CBC_128_HMAC_SHA1: { esp-aes esp-sha-hmac  }
>    will negotiate = { Transport,  },
>
> Transform set default: { esp-aes esp-sha-hmac  }
>    will negotiate = { Transport,  },
>
 	phase2alg=aes_gcm256,aes256-sha1
 	type=transport

> router-2#
>
> How do I represent that in my libreswan config file?  This this correct?
>
>         ike=aes_cbc256-sha2_512;dh19
>         phase2alg=aes_gcm256
>
> [The documentation doesn't give any examples of sha2_512 - I'm hoping that 
> that is the same as SHA512 in the Cisco default?)

Yes.

> 3. Following on from this, if I do not hard set my proposal at all on either 
> end, then I would expect some out-of-the-box negotiation of some fairly 
> strong ciphers to be negotiated instead.

Yes, aes, aes_gcm and sha2 as well as dh14 are surely in the default
proposal list for IKEv2, so I would expect it to work.

> However in practice this doesn't work for either classic IOS or IOS-XE.
>
> Debugs show:

> Aug 14 23:42:30.350745: | remote proposal 1 matches local proposal 3

You have a match.

> Aug 14 23:42:30.350754: packet from 1.129.98.157:585: proposal 
> 1:IKE:ENCR=AES_CBC_256;PRF=HMAC_SHA2_512;INTEG=HMAC_SHA2_512_256;DH=MODP2048 
> chosen from remote proposals 
> 1:IKE:ENCR=AES_CBC_256;PRF=HMAC_SHA2_512;PRF=HMAC_SHA2_384;INTEG=HMAC_SHA2_512_256;INTEG=HMAC_SHA2_384_192;DH=ECP_256;DH=MODP2048;DH=ECP_521;DH=MODP1536[first-match]

You picked aes256-sha2_512;dh14

> Aug 14 23:42:30.350763: | accepted IKE proposal ikev2_proposal: 
> 1:IKE:ENCR=AES_CBC_256;PRF=HMAC_SHA2_512;INTEG=HMAC_SHA2_512_256;DH=MODP2048
> Aug 14 23:42:30.350773: | converting proposal to internal trans attrs
> Aug 14 23:42:30.350783: packet from 1.129.98.157:585: initiator guessed wrong 
> keying material group (ECP_256); responding with INVALID_KE_PAYLOAD 
> requesting MODP2048

On the first IKE_INIT packet, the initiator has to guess the DH for the
KE payload. The Cisco guessed dh19 but libreswan picked dh14. So it
sends back INVALID_KE and the Cisco should come back again but now use
a KE payload that matches dh14

> Which of course is all rather broken and leads to IKEv2 not finishing 
> negotiation at all.

You didn't show me what happened next, so I cannot tell. It all looks
healthy up to here. You can avoid the extra roundtrip by of INVALID_KE
by using: ike=aes256-sha2_512;dh19

> 4. In the Linux kernel there are a number of options relating to encryption 
> ciphers which I can compile in support for.  Are these used by Libreswan or 
> the kernel in this case or does it not matter?

Yes. libreswan only pushes ESP/AH keys into the kernel. The kernel does
the encryption/authentication parts. So you must enable those algorithms
in the kernel too.

> Do I need to match the kernel options with at the very least to include the 
> encryption ciphers I am intending to use in my IPSec sessions?
>
> Examples:
>
> CONFIG_CRYPTO_SHA1_MB=y
> CONFIG_CRYPTO_SHA256_MB=y
> CONFIG_CRYPTO_SHA512_MB=y
> CONFIG_CRYPTO_SHA256=y
> CONFIG_CRYPTO_SHA512=y

Yes.

Paul