Bug 1721081

Created attachment 1581383 [details]
On Success

Created attachment 1581385 [details]
On Failure

Created attachment 1582029 [details]
libreswan log

Created attachment 1582030 [details]
openssl.cnf

The test fails to properly run due to the certificates being used:

Jun 19 10:29:01.847895: "ikev2" #1: initiating v2 parent SA
Jun 19 10:29:01.847919: "ikev2": constructed local IKE proposals for ikev2 (IKE SA initiator selecting KE): 1:IKE:ENCR=3DES;PRF=HMAC_SHA1;INTEG=HMAC_SHA1_96;DH=MODP1024
Jun 19 10:29:01.848253: "ikev2" #1: STATE_PARENT_I1: sent v2I1, expected v2R1
Jun 19 10:29:01.880022: "ikev2": constructed local ESP/AH proposals for ikev2 (IKE SA initiator emitting ESP/AH proposals): 1:ESP:ENCR=3DES;INTEG=HMAC_SHA1_96;DH=NONE;ESN=DISABLED
Jun 19 10:29:01.880095: "ikev2" #2: STATE_PARENT_I2: sent v2I2, expected v2R2 {auth=IKEv2 cipher=3DES_CBC_192 integ=HMAC_SHA1_96 prf=HMAC_SHA1 group=MODP1024}
Jun 19 10:29:01.934599: "ikev2" #2: loading root certificate cache
Jun 19 10:29:01.935250: "ikev2" #2: Certificate CN=CA,OU=IPv6,O=IOL,L=Durham,ST=New Hampshire,C=US failed IPsec verification
Jun 19 10:29:01.935261: "ikev2" #2: ERROR: The certificate was signed using a signature algorithm that is disabled because it is not secure.
Jun 19 10:29:01.935267: "ikev2" #2: X509: Certificate rejected for this connection
Jun 19 10:29:01.935270: "ikev2" #2: X509: CERT payload bogus or revoked
Jun 19 10:29:02.380762: "ikev2" #2: STATE_PARENT_I2: retransmission; will wait 0.5 seconds for response

What happens is that libreswan sends out IKE_INIT, when it receives a response it goes into building the IKE_AUTH packet, but encounters a fatal certificate error.

It then mistakenly retransmits the IKE_INIT packet. It should just give up.

You should fixup the certificates. You might need to enable plutodebug=all to see more details about why the certificate was rejected, but most likely the CA or EE certificate was signed with SHA1 or MD5 ?

I dont think this has anything to do with the kernel or fragmentation

sorry, it does send IKE_AUTH and on the IKE_AUTH reply cannot use the certificate and does a retransmit

This is sending IKE_INIT:                     Jun 19 10:29:01.848253: "ikev2" #1: STATE_PARENT_I1: sent v2I1, expected v2R1
This is sending IKE_AUTH:                     Jun 19 10:29:01.880095: "ikev2" #2: STATE_PARENT_I2: sent v2I2, expected v2R2
This is the bad resending of IKE_AUTH:        Jun 19 10:29:02.380762: "ikev2" #2: STATE_PARENT_I2: retransmission; will wait 0.5 seconds for response

bogus IKE_AUTH retransmit fixed in upstream commit https://github.com/libreswan/libreswan/commit/028406e63e0251e63c83d5953a12b330f7ad9396

This will be released upstream in libreswan 3.30.

the certificates have a few issues based on the openssl.cnf

default_bits		= 1024

Change default_bits to 2048

digests		= md5, sha1		# Acceptable message digests (mandatory)

Change the digests to use sha2 instead

Jianwen, Paul,

Is this still a blocker for 8.1? 

Thanks!
Sushil

not a blocker. I moved it to 8.2.0

upstream tests: ikev2-impair-04-corrupt-auth-sk-payload

Hi Paul,

is it really fixed? Your upstream test passes on the new version, but I tried to reproduce it based on AC from comment 28 and I see exactly the same behaviour in version 3.29 and 3.32. After autentication fails, it tries to do it again and again.

libreswan-3.29-7.el8_2:

pluto[67781]: "test" #2: STATE_PARENT_I2: sent v2I2, expected v2R2 {auth=IKEv2 cipher=AES_GCM_16_256 integ=n/a prf=HMAC_SHA2_512 group=DH19}
pluto[67781]: "test" #2: IKE SA authentication request rejected by peer: AUTHENTICATION_FAILED
pluto[67781]: "test" #2: scheduling retry attempt 1 of an unlimited number, but releasing whack
pluto[67781]: "test" #2: STATE_PARENT_I2: suppressing retransmits; will wait 59.991 seconds for retry


libreswan-3.32-3.el8:

pluto[68210]: "test" #2: STATE_PARENT_I2: sent v2I2, expected v2R2 {auth=IKEv2 cipher=AES_GCM_16_256 integ=n/a prf=HMAC_SHA2_512 group=DH19}
pluto[68210]: "test" #2: IKE SA authentication request rejected by peer: AUTHENTICATION_FAILED
pluto[68210]: "test" #2: scheduling retry attempt 1 of an unlimited number, but releasing whack
pluto[68210]: "test" #2: STATE_PARENT_I2: suppressing retransmits; will wait 59.99681 seconds for retry

Based on the AC, it should not try reconnect, but it does.

I think you are mixing up two processes

1) In an IKE exchange, when we send IKE_AUTH and we receive an IKE_AUTH that causes us to cannot continue, abort the entire exchange attempt.

2) If an exchange fails, but a connection is supposed to be up, keep trying keyingtries= to start a new exchange from scratch (starting with IKE_SA_INIT)


You are seeing 2) now.

The bug was within 1) where if we received an IKE_AUTH reply, we would re-send an IKE_AUTH message in the hope of a "better reply" (but that cannot happen, because any newly transmited different IKE_AUTH would have the same msgid and get rejected before we even would parse the exchange payloads)

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory (libreswan bug fix and enhancement update), and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHEA-2020:4722