HPE FlexNetwork MSR Series Comware 5 Security Configuration Guide

220
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)
IKEv2 configuration task list
Determine the following parameters prior to IKEv2 configuration:
• The strength of the algorithms for IKEv2 negotiation, namely the security protection level,
including the encryption algorithms, integrity protection algorithms, PRF algorithms, and DH
groups. Different algorithms provide different levels of protection. A stronger algorithm means
better resistance to decryption of protected data but requires more resources. Generally, the
longer the key, the stronger the algorithm.

HPE FlexNetwork MSR Series Specifications

General

Brand	HPE
Model	FlexNetwork MSR Series
Category	Network Router
Language	English