RFC 5996 Compliance
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).
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.
Integrity with Combined Mode Ciphers
RFC 5996 makes changes in specifications to allow negotiation of combined mode ciphers. Combined mode ciphers are algorithms that support integrity and encryption in a single encryption algorithm. RFC 5996 makes negotiation for the integrity algorithm optional if combined mode cipher is used. In RFC 4306 the integrity algorithm was mandatory in the SA payload.
StarOS does not support the combined mode cipher. Staros IKEv2 has been enhanced to identify a currently defined combined cipher. If a proposal for combined mode cipher is received, StarOS responds with NO_PROPOSAL_CHOSEN if no other proposal matches.
Negotiation Parameters in CHILDSA REKEY
On rekeying of a CHILD SA the traffic selectors and algorithms match the ones negotiated during the set up of the child SA. StarOS IKEv2 does not send any new parameters in CREATE_CHILD_SA for a child SA being rekeyed.
StarOS supports a CLI command to enable sending and receiving HTTP method for hash-and-URL lookup with CERT/CERTREQ payloads.
If configured and if a peer requests CERT using encoding type as "Hash and URL of X.509 certificate" and send HTTP_CERT_LOOKUP_SUPPORTED using notify payload in the first IKE_AUTH, StarOS sends the URL in the CERT payload instead of sending the entire certificate in the payload.
If not configured and CERTREQ is received with encoding type as "Hash and URL for X.509 certificate", StarOS responds with entire certificate as it in release 14.1, even if peer had sent HTTP_CERT_LOOKUP_SUPPORTED.
If configured for Hash and URL while sending the CERTREQ request, StarOS sends the request with encoding type as "Hash and URL of X.509 certificate" and sends notify payload HTTP_CERT_LOOKUP_SUPPORTED. However, also sends another CERTREQ with encoding type as X.509 certificate (as in release 14.1) and accepts the entire certificate coming in the CERT payload. If CERT payload is received with encoding type as hash and URL, StarOS fetches the certificate using the URL.
Multiple Traffic Selectors
During traffic selector negotiation, the gateway should be able to narrow down the UE's request for a range of traffic selectors in accordance with RFC 5996.