Project

General

Profile

Issue #3133

ESP rekey fail during interoperability test with srx1400

Added by Janusz Gil over 1 year ago. Updated about 1 month ago.

Status:
Closed
Priority:
Normal
Category:
interoperability
Affected version:
5.6.3
Resolution:
No feedback

Description

We are using StrongSwan 5.6.3 and srx1400 (JUNOS Software Release [12.3X48-D75.4]) as remote security gateway.
There are short SA lifetimes configured on Juniper as following: IKE lifetime==180 seconds; IPSEC lifetime==180 seconds.

We observed after several hours of operation, it is impossible to ping remote inner host (behind srx1400).
In failing scenario the delete of the old Child SA is done on old IKE SA and in successful case the delete of the old Child SA is done on new IKE SA.
Additionally, please find extracted pcap file in attachments.

Failing scenario:
[SS] < ---------- [srx SEGW] CREATE_CHILD_SA ESP Rekey Request {Initiator SPI: c0596ad316ca24d2 Responder SPI: a32201d75da988ac}
[SS] ---------- > [srx SEGW] CREATE_CHILD_SA ESP Rekey Response {Initiator SPI: c0596ad316ca24d2 Responder SPI: a32201d75da988ac}
[SS] < ---------- [srx SEGW] CREATE_CHILD_SA IKE Rekey Request {Initiator SPI: c0596ad316ca24d2 Responder SPI: a32201d75da988ac}
[SS] ---------- > [srx SEGW] CREATE_CHILD_SA IKE Rekey Response {Initiator SPI: c0596ad316ca24d2 Responder SPI: a32201d75da988ac}
[SS] < ---------- [srx SEGW] Delete ESP SA with old IKE SPI Request *{Initiator SPI: c0596ad316ca24d2 Responder SPI: a32201d75da988ac}*
[SS] ---------- > [srx SEGW] BB generates some INFORMATIONAL response {Initiator SPI: c0596ad316ca24d2 Responder SPI: a32201d75da988ac}
[SS] < ---------- [srx SEGW] Delete old IKE SA request {Initiator SPI: c0596ad316ca24d2 Responder SPI: a32201d75da988ac}
[SS] ---------- > [srx SEGW] Delete old IKE SA Response {Initiator SPI: c0596ad316ca24d2 Responder SPI: a32201d75da988ac}

And we can see below in the logs:
"[8]<peer3|4861> received packet: from 10.90.93.21500 to 10.90.93.18500 (80 bytes)"
"[8]<peer3|4861> parsed INFORMATIONAL request 4 [ D ]"
"[8]<peer3|4861> received DELETE for unknown ESP CHILD_SA with SPI c2389e7e"
"[8]<peer3|4861> CHILD_SA closed"
"[8]<peer3|4861> generating INFORMATIONAL response 4 [ ]"
"[8]<peer3|4861> sending packet: from 10.90.93.18500 to 10.90.93.21500 (80 bytes)"

Correct scenario, ping is working ok:
[SS] < ---------- [srx SEGW] CREATE_CHILD_SA ESP Rekey Request {Initiator SPI: 09e8d18cf7236667 Responder SPI: 827661b56d01d5a0 }
[SS] ---------- > [srx SEGW] CREATE_CHILD_SA ESP Rekey Response {Initiator SPI: 09e8d18cf7236667 Responder SPI: 827661b56d01d5a0 }
[SS] < ---------- [srx SEGW] CREATE_CHILD_SA IKE Rekey Request {Initiator SPI: 09e8d18cf7236667 Responder SPI: 827661b56d01d5a0 }
[SS] ---------- > [srx SEGW] CREATE_CHILD_SA IKE Rekey Response {Initiator SPI: 09e8d18cf7236667 Responder SPI: 827661b56d01d5a0 }
[SS] < ---------- [srx SEGW] Delete rekeyed ESP SA with new IKE SPI Request {Initiator SPI: c3145bb8240ba952 Responder SPI: c162226e4cb7b444}
[SS] ---------- > [srx SEGW] Delete rekeyed ESP IKE SA with new IKE SPI Response {Initiator SPI: c3145bb8240ba952 Responder SPI: c162226e4cb7b444
[SS] < ---------- [srx SEGW] Delete old IKE SA Request {Initiator SPI: 09e8d18cf7236667 Responder SPI: 827661b56d01d5a0 }
[SS] ---------- > [srx SEGW] Delete old IKE SA Response {Initiator SPI: 09e8d18cf7236667 Responder SPI: 827661b56d01d5a0 }

Can you please take a look in the case of any issues on StrongSwan side?

Regards
Janusz

rekey_transaction.txt (8.32 KB) rekey_transaction.txt Janusz Gil, 30.07.2019 14:06

History

#1 Updated by Tobias Brunner about 1 year ago

  • Status changed from New to Feedback

There are short SA lifetimes configured on Juniper as following: IKE lifetime==180 seconds; IPSEC lifetime==180 seconds.

Why? Just for testing?

We observed after several hours of operation, it is impossible to ping remote inner host (behind srx1400).
In failing scenario the delete of the old Child SA is done on old IKE SA and in successful case the delete of the old Child SA is done on new IKE SA.

There is a clear relationship between IKE_SAs and CHILD_SAs, that is, when an IKE_SA is rekeyed all CHILD_SAs, whether they are rekeyed or not, are inherited by the new IKE_SA. Afterwards only the new IKE_SA must be used to manage the CHILD_SAs (the only thing sent on the old IKE_SA is a DELETE for itself). If the Juniper box sends deletes for CHILD_SAs on the rekeyed IKE_SA that's incorrect (it might even be nicer to delete the old CHILD_SA first, before initiating the IKE_SA rekeying as the RFC explicitly specifies the rekeying/deletion of a CHILD_SA and the request to rekey an IKE_SA as a possible collision point between the two peers).

#2 Updated by Janusz Gil about 1 year ago

Hello Tobias,

Thank you for confirmation we have an issue with Juniper box in this case. Yes those short lifetimes was configured for manual/happy testing purposes. Problem is hardly reproduced even for such short timings.
We will try to contact Juniper for further help and clarifications.

Thanks,
Janusz

#3 Updated by Tobias Brunner about 1 month ago

  • Status changed from Feedback to Closed
  • Assignee set to Tobias Brunner
  • Resolution set to No feedback

Also available in: Atom PDF