Project

General

Profile

Bug #876

IKE SA rekeying collisions aren't correctly resolved when the two peers don't immediately agree on the proposed Diffie Hellman values

Added by Nancy Baird over 3 years ago. Updated over 2 years ago.

Status:
Closed
Priority:
Normal
Category:
libcharon
Target version:
Start date:
04.03.2015
Due date:
Estimated time:
Affected version:
5.1.3
Resolution:
Fixed

Description

IKE SA rekeying collisions aren't correctly resolved when the two peers don't immediately agree to the proposed Diffie Hellman values.

I am describing primarily from the client viewpoint. Using 5.1.3 at our client, and 4.5.2 at the SeGW (a test machine). Using ikev2.

Case 1.
- SeGW rejects client's first rekey attempt with N(INVAL_KE): client supports MODP_2048 and MODP_1024, and proposes MODP_2048 for the rekey, while the SeGW supports only MODP_1024.
- client loses the collision resolution (SeGW's decision)

Case 2.
- client rejects SeGW's first rekey attempt with N(INVAL_KE): client supports MODP_2048; the SeGW supports MODP_1536 and MODP_2048, and proposes MODP_1536.
- client loses the collision resolution (client's decision)

=========================
Case 1 observed behavior.

- The client and the SeGW begin rekeying at the same time.

- The client responds successfully to the CREATE_CHILD_SA request it receives from the SeGW. The SeGW responds with N(INVAL_KE) to the client's request since it asks for MODP_2048 which the SeGW doesn't support.

- When the client receives the CREATE_CHILD_SA response containing N(INVAL_KE), it immediately sends a new CREATE_CHILD_SA request for MODP_1024 (even though it knows the SeGW has initiated a rekey).

- In the meantime the SeGW has received the client's successful CREATE_CHILD_SA response to the SeGW's proposed rekey. The SeGW decides it has won the collision and sends an INFORMATIONAL message to delete the original IKE SA. It has not seen the client's second CREATE_CHILD_SA request yet.

- When the client receives the INFORMATIONAL delete, it deletes not only the original IKE SA, but also both replacements, proposed by itself (to which it has received no second response yet) and proposed by the SeGW (but not yet accepted by the client, since it needs its own second response to resolve the rekey collision), and does not invoke the updown script to give notification of the state change. The tunnel is down and does not recover.

Perhaps the client should not send any new CREATE_CHILD_SA request after receiving the CREATE_CHILD_SA response with N(INVAL_KE), since it has received a request to rekey that is not yet completed. This would seem to be proposed in RFC5996 section 1.3.2: "Once a peer receives a request to rekey an IKE SA or sends a request to rekey an IKE SA, it SHOULD NOT start any new CREATE_CHILD_SA exchanges on the IKE SA that is being rekeyed."

I would think that upon receiving the INFORMATIONAL delete, the client should delete the original IKE SA and the replacement it proposed, but keep the replacement proposed by the SeGW; the INFORMATIONAL delete may have resulted from the SeGW not having received the client's second CREATE_CHILD_SA request. As per RFC5996 section 2.8.2: "If the peer that did notice the simultaneous rekey gets the delete request from the other peer for the old IKE SA, it knows that the other peer did not detect the simultaneous rekey, and the first peer can forget its own rekey attempt."

=========================
Case 2 observed behavior.

- The client and the SeGW begin rekeying at the same time.

- The SeGW responds successfully to the CREATE_CHILD_SA request it receives from the client. The client responds with N(INVAL_KE) to the SeGW's request since it asks for MODP_1536 which the client doesn't support, but it keeps alive the proposed new IKE_SA it created upon first receiving the rejected request; I will call this the 'phantom' IKE_SA. (This behavior is different from receiving a rekey request from SeGW with MODP_1536 when no rekey is being done already by the client. In that case, the IKE SA created at receipt of CREATE_CHILD_SA is destroyed when the N(INVAL_KE) response is sent.)

- When the client receives the successful CREATE_CHILD_SA response to its rekey request, it evaluates the winner/loser of the collision even though it has rejected the SeGW's rekey parameters. When in this case it decides that the client has lost, it deletes its own proposed new SA and keeps the 'phantom' IKE_SA. The client now has two SAs, the original one which it is waiting for the SeGW to delete, and the phantom one that it believes is the successor to the original SA; it is only waiting for the SeGW to delete the original SA, and the rekey will be complete.

- Meanwhile, the SeGW sends a new CREATE_CHILD_SA request to rekey the original SA this time with an acceptable MODP value, and the client accepts this request and creates a new IKE_SA to be successor to the original IKE_SA. The SeGW now deletes the original SA to complete the rekey.

- Going forward, DPD is performed by the client on both the phantom and the successor IKE SAs. DPD fails on the phantom IKE SA. When retransmits are exhausted, the client sends a new IKE_SA_INIT request to replace the phantom, which is unnecessary since the successor SA has taken over the function of the original IKE SA.

Associated revisions

Revision 95a5806a
Added by Tobias Brunner over 2 years ago

Merge branch 'exchange-collisions'

Improves the handling of IKEv2 exchange collisions in several corner
cases. TEMPORARY_FAILURE and CHILD_SA_NOT_FOUND notifies that were defined
with RFC 7296 are now handled and sent as appropriate.

The behavior in these situations is tested with new unit tests.

Fixes #379, #464, #876, #1293.

History

#1 Updated by Tobias Brunner over 2 years ago

  • Tracker changed from Issue to Bug
  • Status changed from New to Assigned
  • Assignee set to Tobias Brunner
  • Priority changed from High to Normal
  • Target version set to 5.5.0

#2 Updated by Tobias Brunner over 2 years ago

  • Subject changed from IKE SA rekeying collisions aren't correctly resolved when the two peers don't immediately agree to the proposed Diffie Hellman values. to IKE SA rekeying collisions aren't correctly resolved when the two peers don't immediately agree on the proposed Diffie Hellman values
  • Category set to libcharon
  • Status changed from Assigned to Closed
  • Resolution set to Fixed

Also available in: Atom PDF