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
_______________________________________________
Swan mailing list
Swan@lists.libreswan.org
https://lists.libreswan.org/mailman/listinfo/swan