New Features In Ikev2; Protocols And Standards; Ikev2 Configuration Task List - HP FlexNetwork 10500 Series Security Configuration Manual

New features in IKEv2

DH guessing
In the IKE_SA_INIT exchange, the initiator guesses the DH group that the responder is most likely to
use and sends it in an IKE_SA_INIT request message. If the initiator's guess is correct, the
responder responds with an IKE_SA_INIT response message and the IKE_SA_INIT exchange is
finished. If the guess is wrong, the responder responds with an INVALID_KE_PAYLOAD message
that contains the DH group that it wants to use. The initiator then uses the DH group selected by the
responder to reinitiate the IKE_SA_INIT exchange. The DH guessing mechanism allows for more
flexible DH group configuration and enables the initiator to adapt to different responders.
Cookie challenging
Messages for the IKE_SA_INIT exchange are in plain text. An IKEv1 responder cannot confirm the
validity of the initiators and must maintain half-open IKE SAs, which makes the responder
susceptible to DoS attacks. An attacker can send a large number of IKE_SA_INIT requests with
forged source IP addresses to the responder, exhausting the responder's system resources.
IKEv2 introduces the cookie challenging mechanism to prevent such DoS attacks. When an IKEv2
responder maintains a threshold number of half-open IKE SAs, it starts the cookie challenging
mechanism. The responder generates a cookie and includes it in the response sent to the initiator. If
the initiator initiates a new IKE_SA_INIT request that carries the correct cookie, the responder
considers the initiator valid and proceeds with the negotiation. If the carried cookie is incorrect, the
responder terminates the negotiation.
The cookie challenging mechanism automatically stops working when the number of half-open IKE
SAs drops below the threshold.
IKEv2 SA rekeying
For security purposes, both IKE SAs and IPsec SAs have a lifetime and must be rekeyed when the
lifetime expires. An IKEv1 SA lifetime is negotiated. An IKEv2 SA lifetime, in contrast, is configured. If
two peers are configured with different lifetimes, the peer with the shorter lifetime always initiates the
SA rekeying. This mechanism reduces the possibility that two peers will simultaneously initiate a
rekeying. Simultaneous rekeying results in redundant SAs and SA status inconsistency on the two
peers.
IKEv2 message retransmission
Unlike IKEv1 messages, IKEv2 messages appear in request/response pairs. IKEv2 uses the
Message ID field in the message header to identify the request/response pair. If an initiator sends a
request but receives no response with the same Message ID value within a specific period of time,
the initiator retransmits the request.
It is always the IKEv2 initiator that initiates the retransmission, and the retransmitted message must
use the same Message ID value.

Protocols and standards

•
RFC 2408, Internet Security Association and Key Management Protocol (ISAKMP)
•
RFC 4306, Internet Key Exchange (IKEv2) Protocol
•
RFC 4718, IKEv2 Clarifications and Implementation Guidelines
•
RFC 2412, The OAKLEY Key Determination Protocol
•
RFC 5996, Internet Key Exchange Protocol Version 2 (IKEv2)

IKEv2 configuration task list

Determine the following parameters prior to IKEv2 configuration:
337