Cisco ASA GCM Integrity=NONE issue

[Liran]

Greetings everyone,

I'm seeking your expertise to assist in troubleshooting an intricate issue with an IPSEC tunnel configuration involving a Cisco ASA and Libreswan.

The issue is when the ASA sends IKE rekey while phase 2 being configured to use gcm encryption, the ASA sends the rekey with the integrity- INTEG=NONE.
Libreswan is working like the RFC which doesn’t allow INTEG=NONE to be specified so it result in all the TCP sessions running through the IPSEC to drop.

It is weird for me that Cisco doesn’t apply to the RFC and sends the INTEG=NONE instead of not sending INTEG info at all.
AEAD encryption types are not allowed to specify an "integrity" algorithm (or specify integrity algorithm "none").
reference:
https://libreswan.org/wiki/Cipher_suites_and_algorithm_support

Also attached here is a text file of the packet capture of the rekey.

Your contributions and expertise will be greatly appreciated,
Liran

[Rob Ingram]

@Liran AES-GCM provides encryption and integrity, so you do not need to specify an integrity algorthim such as SHA, hence why integrity=none.

The logs indicate - no local proposal matches remote proposals - what proposals have you configured on the remote side?

[Liran]

Hi @Rob Ingram,
The proposals I have configured on the remote side are all the same as my Cisco ASA.
Remote side: "aes_gcm256-null"

But Cisco's ASA sending integrity=none is not how it is specified by the RFC.
Cisco ASA should send rekey with no info at all under integrity, please check my referenced link.

[tvotna]

Really?

Combined-mode ciphers include
   both integrity and encryption in a single encryption algorithm, and
   MUST either offer no integrity algorithm or a single integrity
   algorithm of "NONE", with no integrity algorithm being the
   RECOMMENDED method.

RFC7296.

[tvotna]

@Liran, Quick question: does it make any difference if you configure just "protocol esp encryption aes-gcm", which places the default value for integrity into the ASA running-config: "protocol esp integrity sha-256" vs explicitly-configured integrity: "protocol esp encryption aes-gcm" + "protocol esp integrity null".

If ASA sends NONE (0) in both cases, this looks more like an ASA bug than a feature, although TAC will most likely tell you that libreswan behavior is incorrect and there is a bug in RFC 8247 too. Indeed, since RFC 8247 updates RFC 7296 (which allows integrity "NONE", although does not recommend it), it should contain "MUST NOT BE USED" instead of current

When an AEAD
   algorithm (see Section 2.1) is proposed, this algorithm transform
   type is not in use 

[Liran]

Hi @tvotna,

Thank you for responding.

Just so that I have order in my mind, you say that currently according to the most recent RFC (8247) the integrity can allow being "NONE" but it should contain "MUST NOT BE USED" instead of the current "NONE" that the ASA sends?

I'm just trying to understand to who can I address in order to raise the problem and search for solution, is it the Libreswan for not accepting "NONE" like the updated RFC (8247) or is it Cisco TAC for not using the recommend value for integrity.

Liran

[tvotna]

Hi @Liran . RFC 7296 definitely allows NONE and RFC 8247 is a bit vague. It uses strict language (MUST, MUST NOT, etc.) in many places, but not in this one, so it becomes obvious that authors overlooked the fact that implementation can interpret RFC in different ways.

I fully agree with @Karsten Iwen 

[Karsten Iwen]

Based on the RFC, I would say that the ASAs implementation doesn't play nice, but the Libreswan implementation is incorrect.

I would raise a support case with both in the hope the Cisco Case gets turned into an enhancement request. By the way: Did you test it with recent versions on both sides?

[Liran]

@Karsten Iwen Thank for your response.

I'm using most updated versions on both sides, ASA version is 9.19

Liran

[tvotna]

@Liran, did you receive a response from Cisco TAC?

One small note: We're migrating to AES-GCM from AES-CBC and use various clients. What I noticed is that strongSwan Android client doesn't fail CREATE_CHILD_SA with ASA. It ignores INTEG = NONE (0) in ASA Responder Request and completely omits INTEG transform in its Initiator Response. Ideally all clients should behave like this, but we're still testing.