[Swan] Cisco IOS XE Interoperability with Libreswan

Tue Aug 14 14:03:30 UTC 2018

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