Additional Child SAs

Each additional Child SA is established using a single CREATE_CHILD_SA exchange, as illustrated in Figure 1.

Figure 1. IKEv2 CREATE_CHILD_SA exchange

A child SA is established using CREATE_CHILD_SA exchange. In this diagram, the initiator server A exchanges two messages with the responder server B. A sends the CREATE_CHILD_SA request to B including proposed SAs, keying information, nonce, and traffic selectors. A receives the CREATE_CHILD_SA response from B including accepted SAs, keying information, nonce, and traffic selectors. All the messages must be encrypted.

The initiator sends a CREATE_CHILD_SA request, containing a list of acceptable proposals for the Child SA. Each proposal defines an acceptable combination of attributes for the Child SA that is being negotiated (AH or ESP SA). The responder picks a proposal that is acceptable and returns the choice to the initiator in the CREATE_CHILD_SA response. The attributes that can be negotiated include the following:

Protocol (AH or ESP)
Authentication algorithm (for example, HMAC-MD5 or HMAC-SHA)
Encapsulation mode (tunnel or transport)
Encryption algorithm (for example, DES, 3DES or AES)
Diffie-Hellman group information (for example, group 1, group 2, group 5 or group 14)

Unlike IKEv1, the Child SA life time and life size are not negotiated between the two IKEv2 peers. Each peer manages its own independent value of life time and life size for each Child SA.

An optional Diffie-Hellman exchange may occur during the CREATE_CHILD_SA exchange. When the Diffie-Hellman exchange is to take place, the initiator includes a Diffie-Hellman public value in the CREATE_CHILD_SA request, and the responder includes a Diffie-Hellman public value in the CREATE_CHILD_SA response. The key generated from this Diffie-Hellman exchange is used in the calculation that generates the keying material for the Child SA. The Diffie-Hellman exchange provides perfect forward secrecy (PFS), which ensures the Child SA keys are derived independently from the IKE SA keys.

Traffic selectors that describe the traffic to be protected by the SA are also negotiated during the CREATE_CHILD_SA exchange. The initiator sends a set of proposed traffic selectors in the CREATE_CHILD_SA request, and the responder can narrow the traffic selection by sending a subset of the initiator's proposed traffic selectors on the CREATE_CHILD_SA response.

As with IKE_SA_INIT, in some cases, negotiation of these attributes may require more than one CREATE_CHILD_SA exchange. The initiator makes a guess as to which proposal the responder will choose, and sends a Diffie-Hellman value that corresponds to that guess. If the responder chooses a different proposal, it rejects the CREATE_CHILD_SA, and includes an indication in the response that identifies its chosen proposal. The initiator learns the correct choice from the CREATE_CHILD_SA response, and initiates a new CREATE_CHILD_SA exchange with the responder's chosen proposal and corresponding Diffie-Hellman value