Hi,
I've recently been able to upgrade my router hardware from a Cisco IOS
based router to an IOS XE based router and am running into what I think
are interoperability issues between the two.
I'm tracking libreswan git master at the moment so hopefully picking up
all the most recent fixes (and bugs).
Basically what I am experiencing is IPSec sessions are not establishing
and I think there are multiple problems, so I'm trying to break it down
into smaller discrete problems which may make it easier to solve.
The first issue is the negotiation of ikev2 and ipsec algorithms.
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.
Unfortunately that seemingly dated man page just states various
arguments of which there doesn't even appear to be an --ike option at
all and it's certainly not obvious what option I should be using to show
a list if valid ciphers or defaults.
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?
2. Cisco IOS and IOS XE both defaults to using supposedly secure
algorithms by default, which means that I don't (shouldn't) need to
specifically configure anything on the IOS/IOS-XE device for a variety
of algorithms to be presented and something in common matched with
Libreswan.
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#
and
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, },
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?)
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.
However in practice this doesn't work for either classic IOS or IOS-XE.
Debugs show:
Aug 14 23:42:30.350605: | remote proposal 1 transform 6 (DH=MODP2048)
matches local proposal 1 type 4 (DH) transform 0
Aug 14 23:42:30.350612: | remote proposal 1 transform 6 (DH=MODP2048)
matches local proposal 2 type 4 (DH) transform 0
Aug 14 23:42:30.350618: | remote proposal 1 transform 6 (DH=MODP2048)
matches local proposal 3 type 4 (DH) transform 0
Aug 14 23:42:30.350625: | remote proposal 1 transform 6 (DH=MODP2048)
matches local proposal 4 type 4 (DH) transform 0
Aug 14 23:42:30.350631: | *****parse IKEv2 Transform Substructure Payload:
Aug 14 23:42:30.350638: | last transform: v2_TRANSFORM_NON_LAST (0x3)
Aug 14 23:42:30.350644: | length: 8 (0x8)
Aug 14 23:42:30.350650: | IKEv2 transform type: TRANS_TYPE_DH (0x4)
Aug 14 23:42:30.350656: | IKEv2 transform ID: OAKLEY_GROUP_ECP_521 (0x15)
Aug 14 23:42:30.350662: | *****parse IKEv2 Transform Substructure Payload:
Aug 14 23:42:30.350669: | last transform: v2_TRANSFORM_LAST (0x0)
Aug 14 23:42:30.350674: | length: 8 (0x8)
Aug 14 23:42:30.350680: | IKEv2 transform type: TRANS_TYPE_DH (0x4)
Aug 14 23:42:30.350686: | IKEv2 transform ID: OAKLEY_GROUP_MODP1536 (0x5)
Aug 14 23:42:30.350694: | remote proposal 1 proposed transforms:
ENCR+PRF+INTEG+DH; matched: ENCR+PRF+INTEG+DH; unmatched: none
Aug 14 23:42:30.350707: | comparing remote proposal 1 containing
ENCR+PRF+INTEG+DH transforms to local proposal 1; required: ENCR+PRF+DH;
optional: INTEG; matched: PRF+DH
Aug 14 23:42:30.350716: | remote proposal 1 does not match local
proposal 1; unmatched transforms: ENCR+INTEG; missing transforms: ENCR
Aug 14 23:42:30.350723: | comparing remote proposal 1 containing
ENCR+PRF+INTEG+DH transforms to local proposal 2; required: ENCR+PRF+DH;
optional: INTEG; matched: PRF+DH
Aug 14 23:42:30.350730: | remote proposal 1 does not match local
proposal 2; unmatched transforms: ENCR+INTEG; missing transforms: ENCR
Aug 14 23:42:30.350738: | comparing remote proposal 1 containing
ENCR+PRF+INTEG+DH transforms to local proposal 3; required:
ENCR+PRF+INTEG+DH; optional: none; matched: ENCR+PRF+INTEG+DH
Aug 14 23:42:30.350745: | remote proposal 1 matches local proposal 3
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]
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
Aug 14 23:42:30.350791: | sending INVALID_KE back with MODP2048(14)
Aug 14 23:42:30.350799: packet from 1.129.98.157:585: responding to
SA_INIT message (ID 0) from 1.129.98.157:585 with unencrypted
notification INVALID_KE_PAYLOAD
Aug 14 23:42:30.350805: | Opening output PBS unencrypted notification
Aug 14 23:42:30.350816: | **emit ISAKMP Message:
Aug 14 23:42:30.350823: | initiator cookie:
Aug 14 23:42:30.350828: | f3 98 56 bb 01 87 9e 48
Aug 14 23:42:30.350834: | responder cookie:
Aug 14 23:42:30.350839: | 00 00 00 00 00 00 00 00
Aug 14 23:42:30.350845: | first contained payload type:
ISAKMP_NEXT_NONE (0x0)
Aug 14 23:42:30.350852: | ISAKMP version: IKEv2 version 2.0
(rfc4306/rfc5996) (0x20)
Aug 14 23:42:30.350857: | exchange type: ISAKMP_v2_SA_INIT (0x22)
Aug 14 23:42:30.350864: | flags: ISAKMP_FLAG_v2_MSG_RESPONSE (0x20)
Aug 14 23:42:30.350873: | message ID: 00 00 00 00
Aug 14 23:42:30.350892: | next payload type: saving message location
'ISAKMP Message'.'first contained payload type'
Aug 14 23:42:30.350906: | Adding a v2N Payload
Which of course is all rather broken and leads to IKEv2 not finishing
negotiation at all.
Is this likely to be a Libreswan problem or an IOS problem? Looks a
little like IOS-XE is negotiating one group but trying to use another.
And lastly:
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?
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
Thanks,
Reuben
_______________________________________________
Swan mailing list
[email protected]
https://lists.libreswan.org/mailman/listinfo/swan
