Cisco Cisco Packet Data Gateway (PDG)

 

▄  IPSec Reference, StarOS Release 18 

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). 

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: 



 

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.  

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. 

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. 

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. 

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.  

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. 

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.