IPsec Security

Security Analysis of IKEv2

IKEv2 security is analyzed here.

IKEv2 closes security loopholes of IKE and improves key negotiation security. In addition, IKEv2 requires that all messages should exist in the format of request/reply pairs, effectively improving reliability of UDP used as a transmission layer protocol.

The following describes the security of IKEv2.

• Defense against man-in-the-middle attacks

  The man-in-the-middle attack is a kind of proactive attack. During the attack, the attacker eavesdrops on the communications parties to capture the messages. After inserting data into the messages, or deleting or changing the information in the messages, the attacker returns the changed messages to the sender, or replays or redirects the original messages. This is the most harmful attack. In IKEv2, the mechanism and methods for defending against man-in-the-middle attacks is as follows:

  • Modes for generating key materials

    The key materials of IKEv2 are different from those of IKE in that the encryption key and the authentication key used for follow-up interactions are different. These keys are extracted from the PRF + output traffic one by one. Therefore, it is more difficult for the attacker to guess the keys. As a result, the keys are less likely to be disclosed, transmission becomes safer, and to a certain extent, man-in-the-middle attacks are prevented.

  • Authentication

    IKEv2 performs authentication by using pre-shared keys and digital signatures. The authentication is two-way authentication. The negotiation parties authenticate each other. In addition, the authentication is symmetrical. The negotiation parties use the same mechanism and method to authenticate each other. The two-way authentication can effectively defend against man-in-the-middle attacks. In addition, IKEv2 defines extended authentication. That is, the negotiation parties authenticate each other through the method described in EAP. The extended authentication supports asymmetrical two-way authentication, further improving the flexibility of authentication and expansibility of negotiations.

  • Message exchange

    IKEv2 reduces the six messages of IKE in main mode to four messages and sends the SA payload, IKE payload, and nonce payload together. So, the messages contain the nonce values. When an attacker returns the messages to their senders, the senders can decide whether the messages are real. This can prevent replay attacks to a certain extent. Each IKEv2 message header contains a message ID, which is used for matching the corresponding request and reply messages, and identifying replay attacks. When a request is sent or received, the message ID must be increased in number order. Moreover, except the IKE_SA_INIT interaction, the message ID is protected through encryption and the integrity of the message ID is protected to prevent replay. IKEv2 introduces the sliding window mechanism so that interactions can effectively resist replay attacks.

• Defense against DoS attacks

  In IKEv2, the mechanism and methods for defending against DoS attacks are as follows:

  • SPI value

    In the header of an IKEv2 message, there are the initiator SPIi and the responder SPIr. The SPIi and the SPIr are random 8-byte values generated by the kernel to identify the SA and a pair of nodes for exchanging messages. Only one of the requests with the same SPI value is processed, excluding retransmission messages. Other requests are discarded as repeated data. This mechanism can prevent DoS attacks to a certain extent.

  • Interactions with cookies

    IKEv2 defends against DoS attacks through auxiliary exchanges during which the Notify payload carries cookies. During communications, when the responder deems that it is suffering from DoS attacks, it can request a stateless cookie from the initiator.

    When the responder receives the first message from the initiator, it does not perform the IKE_SA_INIT interaction immediately. Instead, it generates a new cookie, encapsulates it into a notice payload, and then sends it to the initiator. If the initiator is not an attacker, it can receive this message, and then resume the negotiation. Moreover, it encapsulates the cookie from the responder into the message and keeps the other contents in the payload unchanged.

  • Retransmission convention

    All messages of IKEv2 come in pairs. In each pair of messages, the initiator is responsible for retransmission events. The responder does not retransmit the response message unless it receives a retransmission request from the initiator. In this way, the two parties do not both initiate retransmission, and therefore resources are not wasted. In addition, attackers cannot capture the messages for sending retransmission messages repeatedly to exhaust the resources of the parties of the negotiation.

  • Discarding half-open connections

    When using IKEv2, one negotiation party decides whether the other party expires in two ways. One way is to repeatedly try to contact the other party until the response times out. The other way is that it receives the encrypted Initial Contact notices of different IKE SAs from the other party. The initiator allows multiple responders to respond to the first message and in turn responds to all the responders by regarding them as legal. After sending some messages, once the initiator receives a valid encrypted response message, it ignores all the other response messages and discards all the other invalid half-open connections. In this way, DoS attacks are avoided at the beginning of the negotiation.

• Perfect forward secrecy (PFS)

  PFS allows individual keys to decrypt only data protected by them. Therefore, even if the attacker obtains one key, it can only decrypt the data protected by the key. For IPsec VPNs, PFS means that the encryption key used during IKE negotiation uses different materials from that of the key used during IPsec negotiation. As a result, when an attacker obtains the key for IKE negotiation, it cannot decrypt messages encrypted through IPsec.

  The key materials used to generate keys for the initial IKEv2 interaction are not used to generate keys for IPsec SAs. Instead, new key materials are generated by introducing available IKE payloads during the CREATE_IPsec_SA interaction.

Anti-Replay

In replay attacks, attackers send a large number of packets that have been received by destination hosts. These packets consume a large number of system resources and may exhaust CPU resource.

IPsec implements anti-replay using the sequence number and sliding window. The Sequence Number field in the AH and ESP headers of IPsec packets is specially used for anti-replay.

When an IPsec SA is negotiated by both parties, the Sequence Number field is set to 0. The value is increased by 1 each time the sender sends a packet. An anti-replay sliding window and a database storing sequence numbers of the received packets are configured for the receiver.

• If a packet with a sequence number is not received before and the sequence number is within the anti-replay window, the receiver accepts the packet. If the packet with the sequence number has been received, the receiver considers that it is a replay attack packet and discards it.
• If the sequence number is on the left of the anti-replay window (the sequence number is less than the minimum value of the anti-replay window), the receiver considers that the packet has been received and discards it.
• If the sequence number is on the right of the anti-replay window (the sequence number is larger than the minimum value of the anti-replay window), the receiver considers that the packet is not received, accepts it normally, and moves the anti-replay window to the right.

Figure 1 shows the schematic diagram of anti-replay.

Figure 1 Schematic diagram of anti-replay

• As shown in Figure 1 (a), the range of the initial anti-replay window is [0-63]. Packets with sequence numbers within this range are normally received. If the sequence number of a packet is larger than 63, the receiver accepts the packet and moves the anti-replay window to the right. If packets with sequence numbers within [0-63] are received again, the receiver considers that the packets are replay attack packets and rejects to accept the packets.

• If a packet with sequence number 66 is received, the receiver moves the anti-replay window to [3-66]. Packets with sequence numbers larger than 66 are normally received, as shown in Figure 1 (b). At this time [0-2] are not within the anti-replay window range. If packets with these sequence numbers are received, the receiver considers that the packets are replay attack packets and rejects to accept the packets.

• As shown in Figure 1 (c), if packets are out of order and the receiver receives the packet with sequence number 67 first, the receiver moves the anti-replay window to [4-67]. When the packet with sequence number 3 arrives, although this packet is not received before, the receiver still discards this packet because the sequence number is beyond the range of the anti-replay window. In case of out-of-order packet transmission, the larger the range of the anti-replay window, the lower the incorrect packet dropping probability; the smaller the range of the anti-replay window, the higher the incorrect packet dropping probability.

Lifetime of SAs

For the lifetime of the IPsec SA: If the lifetime reaches the specified time or the processed traffic reaches the specified limit, the IPsec SA becomes invalid. Before the IPsec SA becomes invalid, IKE performs SA negotiation and establishes a new IPsec SA. The new IPsec SA is ready before the old IPsec SA becomes invalid. Before the new IPsec SA negotiation is complete, the old IPsec SA is still used. After the new IPsec SA is established, the new IPsec SA immediately takes effect.

In addition, to facilitate the lifetime configuration of the IPsec SA, the system provides the per-SA lifetime and global lifetime configuration modes. In per-SA lifetime mode, you can set the lifetime for a specified SA. In global lifetime mode, you can set the lifetime for all IPsec SAs. When IKE negotiates an SA, if the lifetime is not configured for the adopted policy, IKE uses the global lifetime to negotiate the SA with the peer end. If the lifetime is configured for the policy, IKE uses this lifetime to negotiate the SA with the peer end.