The connection establishment of IKEv2 is optimized to require as few consecutive messages as possible. Therefore, different logical parts of the connection establishment are transmitted together.
Unlike IKEv1, there is only a single variant of the connection establishment and no alternatives or different modes.
In the first step of establishing the IKE_SA, the encryption algorithms to be used, the so-called proposals, are negotiated. The party that initiates the connection establishment (initiator) sends a list of combinations of encryption algorithms it desires, sorted in descending order of preference. The peer (responder) picks the first combination from this list that it also accepts. This combination is then used.
The party responding to the request (responder) only sees the list of desired encryption algorithm combinations. It does not know which connection is to be established at this moment. The required IKE IDs are transmitted later. If a static IP is configured for the peer, this can be used to select the configured encryption algorithms. For all connections with unknown or dynamic IPs, the only option is to define a common set of encryption algorithm combinations.
At the same time, the Diffie-Hellman method is also used to agree on a session key. This session key protects the rest of the IKE protocol, but not the actual user data.
Next is the exchange of IKE IDs and authentication. Each of the two parties must mandatory authenticate itself to its peer.
If authentication by certificate is configured, the appropriate certificates are selected and transmitted to the peer. For the actual authentication, a random number is taken, encrypted with the public key of the peer and sent. Only the holder of the private key can decrypt this and thus correctly answer the authentication request.
With authentication by pre-shared key, a random number is taken and encrypted with the pre-shared key. Unlike IKEv1, the IKE IDs are not encrypted with the pre-shared key. The IKEv1 problem of selecting the correct pre-shared key therefore does not exist in IKEv2.
Simultaneously with authentication, a list of desired tunnels and the combination of desired encryption algorithms (proposals) is already sent. Authentication, the negotiation of encryption algorithms for the user data, and the negotiation of tunnels therefore take place simultaneously and are inseparable from each other.
A tunnel always consists of the combination of source and destination network, each including the network mask. The peer compares these tunnels with its own existing configuration. The configuration of a tunnel does not have to be identical on both sides. It is also possible for one of the two parties to accept only a part of the offered network and thus narrow the tunnel (the so-called narrowing).
At the same time, the peer picks the first combination of the sent encryption algorithms that it accepts. It then derives further session keys for the tunnels from the previously agreed session key and confirms the tunnel to the peer.
Since authentication, negotiation of encryption algorithms, and the tunnel take place simultaneously, all three points are either successful together or fail together. A precise cause of the error cannot be recognized by the protocol progress, but only by specific error messages.
Only 4 consecutive messages are required for the negotiation of IKE_SA and CHILD_SA together.
The previously negotiated session keys are used to encrypt the actual user data. This data is transmitted via the ESP protocol (Encapsulating Security Payload, IP protocol no. 50). If NAT traversal was activated to bridge a NAT router, the user data is packed into UDP packets on port 4500. This results in a larger protocol overhead than with ESP.
Both IKE_SAs and CHILD_SAs are renewed regularly. For IKE_SAs, this is done to renew the session keys and to ensure that both peers are still authorized to establish the connection. For CHILD_SAs, this is done to regularly negotiate new session keys. If the same session keys were used for too long, attacks on the encryption using statistical patterns might otherwise be possible.
The lifetime for IKE_SAs is usually significantly longer than that of CHILD_SAs. Typical lifetimes for IKE_SAs range from several hours to one day. Usual lifetimes for CHILD_SAs, on the other hand, range from 30 minutes to 3 hours.
The first establishment of a CHILD_SA always takes place simultaneously with authentication, and at this moment the negotiation of the session keys is protected by the Diffie-Hellman key agreement that took place immediately before. Therefore, no additional key agreement is required during the first establishment of a CHILD_SA.
This is different for later renewals of CHILD_SAs. If Perfect Forward Secrecy is desired here, a further Diffie-Hellman key agreement is necessary. If both sides disagree on whether and with which algorithm this should be done in the configuration, the renewal of the CHILD_SA may fail and, as a result, the connection may be interrupted.
If it is configured that the connection should always be online, the connection monitoring recognizes the interruption and re-establishes the connection after a short time. These short interruptions then repeat regularly. Since they may not be noticed immediately, particular attention should be paid to the Diffie-Hellman group or Perfect Forward Secrecy setting for the CHILD_SAs during configuration.
Since IKE_SAs and CHILD_SAs are always established together, CHILD_SAs are always firmly linked to an IKE_SA. CHILD_SAs can be renewed using the existing IKE_SA. A complete renewal of the IKE_SA (= re-authentication), on the other hand, means that the associated CHILD_SAs must also be re-established.
Depending on the implementation, this re-authentication of the IKE_SA may therefore lead to short interruptions of the connection. For this reason, the alternative "" variant is available, in which only the session keys used for the IKE_SA are renewed, but no new authentication is performed. Since a connection would practically exist forever without new authentication despite an expired certificate of the peer, the Intra2net system monitors the time of certificate expiration and actively disconnects affected connections.
For VPN clients, it is recommended for security reasons to require regular re-authentication, so that the client must regularly prove that it has full access to the private key. This increases security, especially in connection with the use of hardware security tokens or smart cards and the entry of the associated PIN code.
For network-to-network connections, the stability of the connection is usually more important, and at the same time the IPSec router on the peer usually has direct access to the key and does not require the entry of a PIN or similar. Therefore, the use of rekeying is recommended for this use case.
If offline detection, also called Dead-Peer-Detection (DPD), is activated, the IKE_SA is used to regularly check whether the peer still responds. DPD requests are then sent regularly. If there is no longer any response to these, the connection is recognized as interrupted after some time. Depending on the configuration, an attempt is then made to re-establish it.
IKEv2 optionally supports the MOBIKE function. This allows changing the external IP address of one of the peers of a connection during operation and without a new IKE negotiation. This is helpful, for example, when changing the access medium.
However, the peer affected by the IP change must recognize this change and then start the IP change via MOBIKE on its own. If the change of the access medium does not take place directly on the VPN client system, but, for example, on a router in front of it, the VPN client may not necessarily notice this in time.