Cisco Cisco Packet Data Interworking Function (PDIF)
IKEv2 RFC 5996 Compliance
▀ RFC 5996 Compliance
▄ IPSec Reference, StarOS Release 17
158
RFC 5996 Compliance
Overview
Staros currently complies with RFC 4306 – Internet Key Exchange (IKEv2) Protocol. Staros IKEv2 has been enhanced
to comply with RFC 5996 – Internet Key Exchange Protocol Version 2 (IKEv2).
to comply with RFC 5996 – Internet Key Exchange Protocol Version 2 (IKEv2).
RFC 5996 introduces two new notification payloads using which certain conditions of the sender can be notified to the
receiver. The IANA assigned numbers for these payloads are as follows:
receiver. The IANA assigned numbers for these payloads are as follows:
TEMPORARY_FAILURE – IANA Assigned Number = 43
CHILD_SA_NOT_FOUND – IANA Assigned Number = 44
StarOS sends the above payloads only in collision scenarios as mentioned in RFC 5996 Section 2.25.
TEMPORARY_FAILURE
A TEMPORARY_FAILURE notification should be sent when a peer receives a request that cannot be completed due to
a temporary condition. When StarOS receives this notification type, it waits (50% of the remaining time of the
IKESA/Child SA) and then retries a maximum of eight times until the hard lifetimer expires. A retry is initiated only if
50% of the remaining time is greater than or equal to two minutes. If it continues to receive TEMPORARY_FAILURE
for all the retries initiated, no further retry is done and the IKESA/Child SA is deleted after its hard lifetime expiry.
a temporary condition. When StarOS receives this notification type, it waits (50% of the remaining time of the
IKESA/Child SA) and then retries a maximum of eight times until the hard lifetimer expires. A retry is initiated only if
50% of the remaining time is greater than or equal to two minutes. If it continues to receive TEMPORARY_FAILURE
for all the retries initiated, no further retry is done and the IKESA/Child SA is deleted after its hard lifetime expiry.
When TEMPORARY_FAILURE is received, retry is done only for an exchange corresponding to REKEYS. If
temporary failure is received for a non-rekey exchange, the temporary failure is considered as failed for the exchange.
temporary failure is received for a non-rekey exchange, the temporary failure is considered as failed for the exchange.
CHILD_SA_NOT_FOUND
A CHILD_SA_NOT_FOUND notification should be sent when a peer receives a request to rekey a Child SA that does
not exist. If StarOS receives this notification, it silently deletes the Child SA.
not exist. If StarOS receives this notification, it silently deletes the Child SA.
On receipt of CHILD_SA_NOT_FOUND, the CHILDSA for which REKEY was initiated is terminated. If the
CHILDSA is the only CHILDSA under the IKESA, the IKESA is terminated and a DELETE request is sent to the peer
for the same.
CHILDSA is the only CHILDSA under the IKESA, the IKESA is terminated and a DELETE request is sent to the peer
for the same.
Exchange Collisions
In IKEv2 exchange collisions may happen when both peers start an exchange for an IKE SA at the same time. For
example UE starts CHILDSA REKEY using CREATE_CHILD_SA and a security gateway also starts CHILDSA
REKEY when SA soft lifetime has expired in both at the same time.
example UE starts CHILDSA REKEY using CREATE_CHILD_SA and a security gateway also starts CHILDSA
REKEY when SA soft lifetime has expired in both at the same time.
RFC 5996 defines a framework to resolve this collision so that only one of the exchanges succeeds. The collision
handling mechanism supported in StarOS complies with the mechanism defined in RFC 5996.
handling mechanism supported in StarOS complies with the mechanism defined in RFC 5996.