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.

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.

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.

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.

To enable the sending and receiving of TEMPORARY_FAILURE and CHILD_SA_NOT_FOUND notifications, use one of the following configuration sequences.

For a crypto map the configuration sequence is:

configure 
   context ctxt_name 
      crypto map template_name { ikev2-ipv4 | ikev2-ipv6 } 
         ikev2-ikesa 
            policy use-rfc5996-notification 

For a crypto template the configuration sequence is:

configure 
   context ctxt_name 
      crypto template template_name ikev2-dynamic 
         ikev2-ikesa 
            policy use-rfc5996-notification 

Refer to the Command Line Interface Reference for a complete description of these commands and their keywords.

Use the following configuration to add Hash and URl encoding of certificates.

Refer to the Command Line Interface Reference for a complete description of these commands and their keywords.

To support multiple traffic selectors, the tsr start-address command has been modified to process both IPv4 and IPv6 addresses.

configure 
   context context_name 
      crypto templatetnplt_name ikev2-dynamic 
         payload payload_name match childsa match any 
            tsr start-address ipv4v6_address end-address ipv4v6_address 
            end