R2511-HP MSR Router Series Security Configuration Guide(V5)

223
New features in IKEv2
DH guessing
At the IKE_SA_INIT exchange phase, the initiator guesses the DH group that the responder is most likely
to use and sends it in the first message, and the responder uses the guessed DH group to respond. If the
initiator's guess is correct, the IKE_SA_INIT exchange is finished at the cost of two messages. If the
guess is wrong, the responder will respond with an INVALID_KE_PAYLOAD message, indicating the DH
group that it wants to use. Then, the initiator uses the DH group selected by the responder to initiate
another negotiation. This 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. If an attacker exploits a large number of
addresses to send IKE_SA_INIT requests, IKEv1 responders cannot determine whether the messages are
from a forged address and must maintain half-open IKE SAs, eventually exhausting its resources.
IKEv2 defends against such attacks by using the cookie challenging mechanism. When an IKEv2
responder maintains a threshold number of half-open IKE SAs, it starts the cookie challenging
mechanism. The cookie challenging mechanism generates a cookie and includes it in the response sent
to initiators. If the initiator can initiate a new IKE_SA_INIT request that carries the correct cookie, the
responder considers the initiator valid and proceeds with the negotiation.
The cookie challenging mechanism automatically stops working when the number of half-open IKE SAs
drops down below the threshold
IKEv2 SA rekeying
For security, both IKE SAs and IPsec SAs have a lifetime and expire when the lifetime value is reached,
triggering rekeying of new IKE SAs and IPsec SAs. An IKEv1 SA lifetime is negotiated. An IKEv2 SA
lifetime, in contrast, is configured. Between two peers, the one with the shorter lifetime always initiates
the SA rekeying, if the two peers have different lifetime settings. This mechanism reduces the possibility
that two peers will simultaneously initiate a rekeying resulting in redundant SAs and leaving
corresponding SAs in different states.
IKEv2 message retransmission
Unlike from IKEv1 messages, IKEv2 messages appear in request-response pairs. IKEv2 uses the Message
ID field in a 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 the specified 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)