RFC 6311

Protocol Support for High Availability of IKEv2/IPsec

📅 published July 2011, from ietf

Protocol Support for High Availability of IKEv2/IPsec 🎀

(Part 1 of 6)

The header facts, bestie: this is RFC 6311, published in July 2011 under the IETF (Internet Engineering Task Force) 🌸. It's a Standards Track document, so it's a real spec people build against, not just an idea. The editor is R. Singh, and the co-authors are G. Kalyani (Cisco), Y. Nir (Check Point), Y. Sheffer (Porticor), and D. Zhang (Huawei). The ISSN is 2070-1721 💜. The header doesn't have an Obsoletes or Updates line, so this doc doesn't replace or patch any older RFC 🙈.

Abstract ✨

okay so IPsec is basically the backbone for business-critical traffic 💼, and companies want it to be highly available, scalable, and able to survive failures 🔥. That's why people run IPsec as HA clusters. The problem is that clustering IPsec, especially IKEv2 (Internet Key Exchange version 2) clustering, comes with a lot of messy issues 😭. An earlier document, "IPsec Cluster Problem Statement", lists all the problems in IKEv2/IPsec HA clusters. This doc fixes them with the least possible change to the protocol 💅.

It defines an IKEv2 extension that solves the main issues from that problem statement for the super common hot standby cluster, and it also gives implementation advice for the other stuff 🧚. The big wins are syncing the IKEv2 Message ID counters and the IPsec replay counters between cluster members. Iconic 👑.

Status of This Memo 🌈

This is an Internet Standards Track document.

This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.

Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6311.

Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

Table of Contents 🦋

1. Introduction ....................................................3
2. Terminology .....................................................5
3. Issues Resolved from IPsec Cluster Problem Statement ............7
   3.1. Large Amount of State ......................................8
   3.2. Multiple Members Using the Same SA .........................9
   3.3. Avoiding Collisions in SPI Number Allocation ...............9
   3.4. Interaction with Counter Modes .............................9
4. The IKEv2/IPsec SA Counter Synchronization Problem .............10
5. SA Counter Synchronization Solution ............................11
   5.1. Processing Rules for IKE Message ID Synchronization .......13
   5.2. Processing Rules for IPsec Replay Counter
        Synchronization ...........................................14
6. IKEv2/IPsec Synchronization Notification Payloads ..............14
   6.1. The IKEV2_MESSAGE_ID_SYNC_SUPPORTED Notification ..........15
   6.2. The IPSEC_REPLAY_COUNTER_SYNC_SUPPORTED Notification ......15
   6.3. The IKEV2_MESSAGE_ID_SYNC Notification ....................16
   6.4. The IPSEC_REPLAY_COUNTER_SYNC Notification ................16
7. Implementation Details .........................................17
8. IKE SA and IPsec SA Message Sequencing .........................18
   8.1. Handling of Pending IKE Messages ..........................18
   8.2. Handling of Pending IPsec Messages ........................18
   8.3. IKE SA Inconsistencies ....................................19
9. Step-by-Step Details ...........................................19
10. Interaction with Other Specifications .........................20
11. Security Considerations .......................................21
12. IANA Considerations ...........................................21
13. Acknowledgements ..............................................22
14. References ....................................................22
   14.1. Normative References .....................................22
   14.2. Informative References ...................................22
Appendix A. IKEv2 Message ID Sync Examples ........................24
  A.1. Normal Failover -- Example 1 ...............................24
  A.2. Normal Failover -- Example 2 ...............................24
  A.3. Normal Failover -- Example 3 ...............................25
  A.4. Simultaneous Failover ......................................25

1. Introduction ✨

The IPsec protocol suite, including IKEv2 (Internet Key Exchange version 2), is a major building block for VPNs (virtual private networks) 🔐. To make those VPNs highly available, more scalable, and failure-resistant, people run them as IKEv2/IPsec Highly Available (HA) clusters. But there are lots of issues with the IKEv2/IPsec HA cluster 😭. Sections 3 and 4 below dig into the issues around the IKEv2/IPsec HA cluster solution. These issues were first described in the problem statement [6].

So here's the setup for a hot standby cluster of IKEv2/IPsec-based VPNs 💖. The IKEv2/IPsec session gets set up first between the peer and the active member of the cluster. After that, the active member keeps syncing and updating the IKE and IPsec security association (SA) state over to the standby member. This primary SA state sync-up happens every time an SA is brought up and/or rekeyed 🔄. Syncing the SA state for every single IKE and IPsec message is super expensive, so it normally happens periodically instead ⏰.

Here's the catch, though: when a failover happens, the standby member is the first to notice, and it might take a while before it becomes the active member 😬. During this failover process, the peer has no idea a failover happened. It keeps sending IKE requests and IPsec packets to the cluster, and it's totally allowed to do that because of the IKEv2 windowing feature 🪟. Once the newly active member starts up, it notices a mismatch in the IKE Message ID values and the IPsec replay counters, and it has to fix that situation 🛠️. See Section 4 for more on the problem.

This document defines an extension to the IKEv2 protocol that solves the main issues of IKE Message ID synchronization and IPsec SA replay counter synchronization. It also gives implementation advice for the other issues 🧚. Here's a quick summary of the solutions:

  • IKEv2 Message ID synchronization: the expected send and receive Message ID values get synced up with the peer, and the newly active cluster member updates its values to match ✨.
  • IPsec replay counter synchronization: the cluster's outgoing SA replay counter values get incremented by a "large" number. On top of that, the newly active member asks the peer to increment the replay counter values it uses for the peer's outgoing traffic 💅.

This document describes the IKEv2 Message ID and IPsec replay counter synchronization in the context of an IPsec HA cluster. But the solution is generic, so it can be used in other scenarios where IKEv2 Message ID or IPsec SA replay counter synchronization is needed 🌸.

Implementations don't all agree on whether they need to synchronize the IKEv2 Message ID and/or the IPsec replay counters 🤷‍♀️. So these two problems are handled separately, each with its own notification for each capability. That gives implementers the flexibility to do either one or both 🫶.

2. Terminology ✨

Okay so, let's get the vocab straight 💅 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this doc mean exactly what [1] says they mean 🫶

"SA Counter Synchronization" is the informational exchange this doc defines to sync the IKEv2/IPsec SA counter info between one member of the cluster and the peer 🔄

Some of the terms below are borrowed from [6], but we've clarified them for this doc 🎀

  • "Hot Standby Cluster", or "HS Cluster", is a cluster where only one member is active at any one time 👑 That member is also called the "active" member, and the others are called "standby" members. The Virtual Router Redundancy Protocol (VRRP) [7] is one method of building one of these clusters. The goal of a hot standby cluster is to create the illusion of a single virtual gateway to the peer(s) ✨
  • "Active Member" is the primary member in the hot standby cluster. It's responsible for forwarding packets on behalf of the virtual gateway 🦋
  • "Standby Member" is the primary backup member. This member takes control (aka becomes the active member) after the failover event 🌸
  • "Peer" is an IKEv2/IPsec endpoint that keeps an IPsec connection with the hot standby cluster. The peer identifies the cluster by the cluster's (single) IP address. If a failover event happens, the standby member becomes active, and the peer normally doesn't notice that failover took place 🙈 Even though we treat the peer as a single entity, it may also be a cluster 🧚
  • "Multiple failover" is when, in a cluster with three or more members, multiple failover events happen in rapid succession, e.g., from M1 to M2, and then to M3 🔥 Our goal is that the implementation can handle this, meaning it can handle the new failover event even if it's still processing the old one 💪
  • "Simultaneous failover" is when two clusters have an IPsec connection between them, and failover happens at both ends at the same time 😭 Our goal is that implementations can handle simultaneous failover too 🫶
  • "IPsec replay counter" is the Encapsulating Security Payload (ESP) Sequence Number or Extended Sequence Number (Section 2.2 of [2]), or the respective field in the Authentication Header (AH) protocol (Section 2.5 of [3]) 🍓

The generic term "IKEv2/IPsec SA Counters" shows up all over this doc 🌈 It covers both IKEv2 Message ID counters and IPsec replay counters. Per the IPsec standards, the IKEv2 Message ID counter is mandatory, and it's used to ensure reliable delivery and to protect against message replay in IKEv2. The IPsec SA replay counters are optional, and they're used to provide the IPsec anti-replay feature 💜

Here's the architecture diagram with some of these terms in action 👀

                                                   +---------------+
                                                   |               |
                                                   | Hot Standby   |
                                                   |   Cluster     |
                                                   |               |
                                                   |   +---------+ |
                                                   |   |         | |
                                                   |   | Active  | |
                                                   |   |         | |
                                                   |   | Member  | |
                                                   |   |         | |
                                                   |   +---------+ |
                                                   |          ^    |
       +---------+                                 |  Synch   |    |
       |         |                                 |  Channel |    |
       |  IPsec  |       IKE/IPsec Traffic         |          |    |
       |         | <=============================> |          |    |
       |   Peer  |                                 |          |    |
       |         |                                 |          |    |
       +---------+                                 |          |    |
                                                   |          v    |
                                                   |   +---------+ |
                                                   |   |         | |
                                                   |   | Standby | |
                                                   |   |         | |
                                                   |   | Member  | |
                                                   |   |         | |
                                                   |   +---------+ |
                                                   +---------------+

                       An IPsec Hot Standby Cluster

3. Issues Resolved from IPsec Cluster Problem Statement 🧚

"IPsec Cluster Problem Statement" [6] lists all the problems IPsec clusters raise 📋 The table below shows which of the problem statement's sections this doc resolves:

  • 3.2. A Lot of Long-Lived State
  • 3.3. IKE Counters
  • 3.4. Outbound SA Counters
  • 3.5. Inbound SA Counters
  • 3.6. Missing Synch Messages
  • 3.7. Simultaneous Use of IKE and IPsec SAs by Different Members
    • 3.7.1. Outbound SAs Using Counter Modes
  • 3.8. Different IP Addresses for IKE and IPsec
  • 3.9. Allocation of SPIs

The main problem areas get solved by the protocol extension defined below, starting with Section 5 ✨ Plus, this section gives implementation advice for other issues in the subsections that follow. Implementers should note that these subsections include a number of new security-critical requirements 🔐 Seriously, pay attention to these 😭

3.1. Large Amount of State

Section 3.2 of the problem statement [6] says a lot of state needs to be synchronized for a cluster to be transparent 🫧 How much data that actually is depends heavily on the implementation, and even within the same implementation, the amounts can vary wildly 🎢 For example, an IPsec gateway doing inter-domain VPN with a dozen other gateways, and with SAs rekeyed every 8 hours, will need way less synchronization traffic than a similar gateway used for remote access supporting 10,000 clients 💀 That's because counter synchronization scales with the number of SAs and needs very little data, while setting up an SA takes a lot of data 🧠 Also, remote access IKE and IPsec SA setup tends to happen at a particular time of day, so that 10,000-client gateway might see 30-50 IKE SA setups per second at 9:00 AM ⏰ That would mean super heavy synchronization traffic in that short window 😵‍💫

If a large volume of traffic is necessary, it may be advisable to use a dedicated high-speed network interface for synch traffic 🚀 When packet loss can be made extremely low, it may be advisable to use a stateless transport such as UDP, to minimize network overhead 🌬️

If these methods aren't enough, it may be prudent to not synchronize the entire state for some SAs. Instead, only an indication of the SA's existence gets synchronized 🫥 This, combined with a sticky solution (as described in Section 3.7 of the problem statement [6]), makes sure that traffic from a particular peer doesn't reach a different member before an actual failover happens 🧲 When that does happen, the method described in [8] can be used to quickly force the peer to set up a new SA ⚡

3.2. Multiple Members Using the Same SA

In a load-sharing cluster of the "duplicate" variety (see Section 3.7 of the problem statement [6]), multiple members may need to send traffic with the same selectors 🎭 To actually use the same SA, the cluster would have to synchronize the replay counter after every single packet, and that would put unreasonable demands on the synch connection 😩

A far better solution is to not synchronize the outbound SA, and to create multiple outbound SAs, one for each member 🙌 The catch is that the peer might see these multiple parallel SAs as redundant and tear down all but one of them 😬

Section 2.8 of [4] specifically allows multiple parallel SAs, but the reason given is to have multiple SAs with different Quality of Service (QoS) attributes 🎀 So while this isn't a new requirement for IKEv2 implementations working with QoS, we're repeating it here: IPsec peers MUST accept the long-term existence of multiple parallel SAs, even when QoS mechanisms aren't in use 🫶💅

3.3. Avoiding Collisions in SPI Number Allocation

Section 3.9 of the problem statement [6] describes the problem of two cluster members allocating the same Security Parameter Index (SPI) number for two different SAs 😱 That behavior would violate Section 4.4.2.1 of [5]. There are several schemes that help implementations avoid these collisions, like partitioning the SPI space, a request-response over the synch channel, and locking mechanisms 🔒 We think these are robust enough and available enough that we don't need to make an exception to the rules in Section 4.4.2.1 of RFC 4301 [5], so we can leave this problem for implementations to solve 🧁 Cluster members must not generate multiple inbound SAs with the same SPI 🚫

3.4. Interaction with Counter Modes

For SAs involving counter mode ciphers such as Counter Mode (CTR) [9] or Galois/Counter Mode (GCM) [10], there's yet another complication 🌀 The initial vector for these modes MUST NOT be repeated, and senders may use methods such as counters or linear feedback shift registers (LFSRs) to make sure this property holds 🧩 For an SA shared between multiple active members (the load-sharing cases), implementations MUST ensure that no initial vector is ever repeated 🔁 Similar concerns apply to an SA failing over from one member to another 🦋 See [11] for a discussion of this problem in another context 📚

Just like the SPI collision problem, there are ways to avoid a collision of initial vectors, and that's left up to implementations 🌈 In the context of load sharing, parallel SAs are a simple solution to this problem as well ✨

4. The IKEv2/IPsec SA Counter Synchronization Problem ✨

okay bestie, so IKEv2 [4] has this rule, and it's giving strict 💅: "An IKE endpoint MUST NOT exceed the peer's stated window size for transmitted IKE requests" 🙅

Every IKEv2 message has to follow a request-response vibe. The initiator of an IKEv2 request MUST retransmit that request until it gets a response from the peer 🔁. IKEv2 has a windowing mechanism, so several requests can be outstanding at the same time, but the sender's window should not move until the oldest message it sent gets acknowledged. Lose even one message and you get repeated retransmissions, and if they all go unacknowledged, the IKEv2 SA gets torn down 💀.

Now the drama. An IPsec hot standby cluster is required to make sure that when failover happens, the standby member becomes active immediately ⚡. The standby is expected to have the exact Message ID counter value the active member had before failover. Even if you do your best to update the Message ID values from the active member to the standby, the standby's values can still be stale 😭, for two reasons:

  • The standby member doesn't know about the last message that was received and acknowledged by the previously active member, because the failover could have happened before the standby got updated.
  • The standby member has no info about the ongoing unacknowledged requests the previously active member sent. So after failover, the newly active member can't retransmit those requests.

When a standby takes over, it can only initialize its Message ID values from the previously updated ones. That means it can reject requests from the peer when those values are stale 🙈. Or the standby might reuse a stale Message ID value, and then the peer drops the request. Honestly, there's a high probability that the IKEv2 and IPsec SAs get torn down over a temporary Message ID mismatch and some retransmissions, which kills the whole point of the high-availability cluster even with periodic updates between members 💔.

Anti-replay counters have the same problem 🫠. If anti-replay protection is enabled (which is commonly the case), the ESP and AH SA counters might be perfectly synchronized from the active to the standby member, and the standby can still end up with stale counter values. It then uses those stale values when sending IPsec packets, and the peer drops them, because with anti-replay protection on, using a counter twice is not allowed. Note that IPsec does let the sender skip some counter values and keep sending with higher ones ✨.

So we conclude that we need a mechanism to make sure the standby has correct Message ID and IPsec counter values when it becomes active, so sessions don't get torn down because of mismatched counters 🎀.

5. SA Counter Synchronization Solution 🌸

This document defines two separate approaches for fixing mismatched IKE Message ID values and IPsec counter values.

  • For IKE Message ID values, the newly active cluster member and the peer negotiate a new pair of values, so future IKE messages won't get dropped 🫶.
  • For IPsec counter values, the newly active member and the peer both increment their own counter values, "skipping forward" by a big number, so no IPsec counter ever gets reused 🚀.

Even though they're conceptually separate, the two synchronization processes would typically happen at the same time 👯.

First, the peer and the active member negotiate whether they can support IKEv2 Message ID synchronization, IPsec replay counter synchronization, or both. They do this by exchanging one or both of the IKEV2_MESSAGE_ID_SYNC_SUPPORTED and IPSEC_REPLAY_COUNTER_SYNC_SUPPORTED notifications during the IKE_AUTH exchange. When negotiating these capabilities, the responder MUST NOT assert support for a capability unless the initiator asserted it first. Only a capability that both parties asserted can be used during the lifetime of the SA. The peer's capabilities for this extension are part of the IKEv2 SA state, so they MUST be shared between the cluster members 🧚.

This per-IKE SA information is shared with the other cluster members 💜.

   Peer                                                  Active Member
   - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
   HDR, SK {IDi, [CERT], [CERTREQ], [IDr], AUTH,
        [N(IKEV2_MESSAGE_ID_SYNC_SUPPORTED),]
        [N(IPSEC_REPLAY_COUNTER_SYNC_SUPPORTED),]
        SAi2, TSi, TSr} ---------->

   <-------- HDR, SK {IDr, [CERT+], [CERTREQ+], AUTH,
                  [N(IKEV2_MESSAGE_ID_SYNC_SUPPORTED),]
                  [N(IPSEC_REPLAY_COUNTER_SYNC_SUPPORTED),]
                  SAr2, TSi, TSr}

After a failover event, the standby member MAY use the IKE Message ID and/or IPsec replay counter synchronization capability when it becomes the active member, as long as support for the capabilities being used was negotiated. After that, the peer MUST respond to any synchronization message it receives from the newly active cluster member, subject to the rules below 🙌.

After the failover event, when the standby becomes active, it has to synchronize its SA counters with the peer. There are four possible cases 👀:

  1. The cluster member only wants to do IKE Message ID value synchronization. In that case, it starts an Informational exchange with Message ID zero and the sole notification IKEV2_MESSAGE_ID_SYNC.
  2. If the newly active member only wants IPsec replay counter synchronization, it generates a regular IKEv2 Informational exchange using the current Message ID values, containing the IPSEC_REPLAY_COUNTER_SYNC notification.
  3. If both counters need synchronizing, the cluster member generates a zero-Message ID message like in case 1, and includes both notifications in that message.
  4. Lastly, the peer might not support this extension. The newly active member knows this, because the cluster members have to share this info, as mentioned earlier. This is the existing IKEv2 behavior, and the IKE and IPsec SAs may or may not survive the failover, depending on the exact state of the peer and the cluster member 😬.

This figure shows the IKE message exchange used for SA counter synchronization. The following subsections describe how the sender and receiver process each message 📝.

   Standby [Newly Active] Member                            Peer
   - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
   HDR, SK {N(IKEV2_MESSAGE_ID_SYNC),
        [N(IPSEC_REPLAY_COUNTER_SYNC)]} -------->

                <--------- HDR, SK {N(IKEV2_MESSAGE_ID_SYNC)}

If you only want IPsec replay counter synchronization, a normal Informational exchange is used instead, where the Message ID is non-zero 💫:

   Standby [Newly Active] Member                            Peer
   - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
   HDR, SK{N(IPSEC_REPLAY_COUNTER_SYNC)} -------->

                <--------- HDR

5.1. Processing Rules for IKE Message ID Synchronization 🔐

The newly active member sends a request containing two counter values, one for itself and one for the peer, plus a random nonce. We call these M1 and P1. The peer responds with a message containing two counter values, M2 and P2 (note that the values appear in the opposite order in the notification's payload). The goal of the rules below is to stop an attacker from replaying a synchronization message and thereby invalidating IKE messages that are currently in process 🛡️.

  • M1 is the next sender's Message ID to be used by the member. M1 MUST be chosen so that it is larger than any value known to have been used. It is RECOMMENDED to increment the known value at least by the size of the IKE sender window.
  • P1 SHOULD be 1 more than the last Message ID value received from the peer, but it may be any higher value.
  • The member SHOULD communicate the sent values to the other cluster members, so that if a second failover event happens, the synchronization message is not replayed. Such a replay would result in the eventual deletion of the IKE SA (see below) 💀.
  • The peer MUST silently drop any received synchronization message if M1 is lower than or equal to the highest value it has seen from the cluster. This includes any previously received synchronization messages.
  • M2 MUST be at least the higher of the received M1 and one more than the highest sender value received from the cluster. This includes any previously received synchronization messages.
  • P2 MUST be the higher of the received P1 value and one more than the highest sender value used by the peer.
  • The request contains a Nonce field. This field MUST be returned in the response, unchanged. A response MUST be silently dropped if the received nonce doesn't match the one that was sent.
  • Both the request and the response MUST NOT contain any additional payloads, other than an optional IPSEC_REPLAY_COUNTER_SYNC notification in the request.
  • The request and the response MUST both be sent with a Message ID value of zero.

5.2. Processing Rules for IPsec Replay Counter Synchronization 🦋

Upon failover, the newly active member MUST increment its own replay counter (the counter used for outgoing traffic), so the peer doesn't drop its traffic as a replay. We note that IPsec allows the replay counter to skip forward by any amount. The estimate is based on the outgoing IPsec bandwidth and how often the cluster members synchronize. In implementations where this value is hard to estimate, the counter can be incremented by a very large number, e.g., 2**30. In that latter case, a rekey SHOULD follow shortly afterwards, to make sure the counter never wraps around 🔄.

Next, the cluster member estimates how many incoming messages it might have missed, using similar logic. The member then sends out an IPSEC_REPLAY_COUNTER_SYNC notification, either on its own or together with an IKEV2_MESSAGE_ID_SYNC notification.

If IPSEC_REPLAY_COUNTER_SYNC is included in the same message as IKEV2_MESSAGE_ID_SYNC, the peer MUST process the Message ID notification first (which might cause the entire message to be dropped as a replay). Then it MUST increment the replay counters for all Child SAs associated with the current IKE SA by the amount the cluster member requested 🎉.

6. IKEv2/IPsec Synchronization Notification Payloads 🍓

This section lists the new notification payload types defined by this extension.

All multi-octet fields representing integers are laid out in big endian order (also known as "most significant byte first", or "network byte order") 🧠.

6.1. The IKEV2_MESSAGE_ID_SYNC_SUPPORTED Notification ✨

okay so this notification payload gets tucked into the IKE_AUTH request/response to say "hey, I speak the IKEv2 Message ID synchronization mechanism this doc describes" 💖 it's giving handshake bestie energy

                        1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Next Payload  |C|  RESERVED   |         Payload Length        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |Protocol ID(=0)| SPI Size (=0) |      Notify Message Type      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

so the Next Payload, Payload Length, Protocol ID, SPI Size, and Notify Message Type fields work exactly like they do in Section 3 of [4] 🎀 the SPI Size field MUST be set to 0 to say the SPI isn't present in this message, and the Protocol ID MUST be set to 0 🌸 that's because the notification isn't tied to any one security association, so it's not specific to a particular SA. the Payload Length is the length in octets of the entire payload, generic payload header included 🧚 and the Notify Message Type is set to IKEV2_MESSAGE_ID_SYNC_SUPPORTED (16420). there's no data attached to this one, so it's just vibes 🫶

6.2. The IPSEC_REPLAY_COUNTER_SYNC_SUPPORTED Notification 🦋

this one also rides in the IKE_AUTH request/response, and it's basically saying "I'm down for the IPsec SA replay counter synchronization mechanism in this doc" 💅

                        1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Next Payload  |C|  RESERVED   |         Payload Length        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |Protocol ID(=0)| SPI Size (=0) |      Notify Message Type      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

the Next Payload, Payload Length, Protocol ID, SPI Size, and Notify Message Type fields are the same as in Section 3 of [4] . the SPI Size field MUST be set to 0 (no SPI here, periodt) 💖 and the Protocol ID MUST be set to 0 too, since the notification isn't specific to a particular security association 🌈 the Payload Length covers the whole payload, including the generic payload header 🍓 and the Notify Message Type is set to IPSEC_REPLAY_COUNTER_SYNC_SUPPORTED (16421). no data associated with this notification either 🎀

6.3. The IKEV2_MESSAGE_ID_SYNC Notification 🔥

this notification payload type (16422) exists to sync up the IKEv2 Message ID values between the newly active (formerly standby) cluster member and the peer. it's the main event of the Message ID drama 👑

                        1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Next Payload  |C|  RESERVED   |         Payload Length        |

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |Protocol ID(=0)| SPI Size (=0) |      Notify Message Type      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   |             Nonce Data                                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |             EXPECTED_SEND_REQ_MESSAGE_ID                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |             EXPECTED_RECV_REQ_MESSAGE_ID                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

it carries the following data, so pay attention 👀

  • Nonce Data (4 octets): the random nonce data. the data should be identical in the synchronization request and response 🫶
  • EXPECTED_SEND_REQ_MESSAGE_ID (4 octets): the sender of this notification uses this field to say which Message ID it'll use in the next request it sends to the other protocol peer 💜
  • EXPECTED_RECV_REQ_MESSAGE_ID (4 octets): the sender uses this one to say which Message ID it's expecting in the next request to be received from the other protocol peer 🦋

6.4. The IPSEC_REPLAY_COUNTER_SYNC Notification 🌸

this notification payload type (16423) is defined to sync the IPsec SA replay counters between the newly active (formerly standby) cluster member and the peer. ngl this one is clever: there can be a ton of IPsec SAs under a single IKE SA, so we don't sync each one individually 🧠 instead, a delta value gets sent, and every replay counter for the Child SAs of this IKE SA gets incremented by that same value ✨ but here's the catch: this solution requires that either all Child SAs use Extended Sequence Numbers (ESNs) or else that no Child SA uses ESNs 😭 and this notification is only sent by the cluster 🔥

                        1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Next Payload  |C|  RESERVED   |         Payload Length        |

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |Protocol ID(=0)| SPI Size (=0) |      Notify Message Type      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                 Incoming IPsec SA delta value                 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

the notification payload contains the following data 💅

  • Incoming IPsec SA delta value (4 or 8 octets): the sender requests that the peer should increment all the Child SA replay counters for the sender's incoming (the peer's outgoing) traffic by this value. the size of this field depends on the ESN bit associated with the Child SAs: if the ESN bit is 1, the field's size is 8 octets; otherwise, it is 4 octets. we note that this constrains the Child SAs of each IKE SA to either all have the ESN bit on or off, so no mixing and matching 🙈

7. Implementation Details 🧚

this protocol does not change any of the existing IKEv2 rules regarding Message ID values. no rewriting the rulebook here, we're just adding to the group chat 💖

the standby member can initiate the synchronization of IKEv2 Message IDs under different circumstances:

  • when it receives a problematic IKEv2/IPsec packet, i.e., a packet outside its expected receive window.
  • when it has to send the first IKEv2/IPsec packet after a failover event.
  • when it has just received control from the active member and wishes to update the values proactively, so that it need not start this exchange later, when sending or receiving the request.

to clarify the first alternative: the normal IKE behavior of rejecting out-of-window messages is not changed 🛑 but such messages can still be a valid trigger for the exchange defined in this document ✨ to avoid denial-of-service (DoS) attacks resulting from replayed messages, the peer MUST NOT initiate counter synchronization for any particular IKE SA more than once per failover event 🔥 that's the anti-spam rule and it's non-negotiable, bestie 🙅‍♀️

the standby member can initiate the synchronization of IPsec SA replay counters when:

  • there has been traffic using the IPsec SA in the recent past and the standby member suspects that its replay counter may be stale.

since there can be a large number of sessions at the standby member, and sending synchronization exchanges for all of them may result in overload, the standby member can choose to initiate the exchange in a "lazy" fashion: only when it has to send or expects to receive traffic from each peer 🦋 in general, the standby member is free to initiate this exchange at its discretion 💜 implementation considerations include the ability to survive a certain amount of traffic loss, and the capacity of a cluster member to initiate counter synchronization simultaneously with a large number of peers 🌈

8. IKE SA and IPsec SA Message Sequencing 🎀

okay so the straightforward definitions of message sequence numbers, retransmissions, and replay protection in IPsec and IKEv2 get kinda strained by the failover scenarios in this document 😭 this section covers some policy choices implementations need to make in this setting. it's giving "you have to pick your battles" 💅

8.1. Handling of Pending IKE Messages 🫶

after sending its "receive" counter, the cluster member MUST reject (silently drop) any incoming IKE messages that are outside its declared window 🛑 a similar rule applies to the peer. local policies vary, and strict implementations will reject any incoming IKE message arriving before Message ID synchronization is complete 🔒

8.2. Handling of Pending IPsec Messages 🌸

for IPsec, there's often a trade-off between security and reliability of the protected protocols 🥺 here again, there's some leeway for local policy. some implementations might accept incoming traffic that's outside the replay window for some time after the failover event, and until the counters had been synchronized 🌊 strict implementations will only accept traffic that's inside the "safe" window 🛡️

8.3. IKE SA Inconsistencies 💀

IKEv2 is normally a reliable protocol. as long as an IKE SA is valid, both peers share a single, consistent view of the IKE SA and all associated Child SAs 🧸 but failover situations like the ones described in this document may involve forced deletion of IKE messages, which can cause inconsistencies, such as Child SAs that exist on only one of the peers 😬 those SAs might cause an INVALID_SPI to be returned when used by that peer. note that Section 1.5 of [4] allows but does not mandate sending an INVALID_SPI notification in this case 🙃

the IPsecME Working Group discussed at some point a proposed set of rules for dealing with such situations. however, we believe these situations should be rare in practice 🤞 so the "default" behavior of tearing down the entire IKE SA is preferred over the complexity of dealing with a multitude of edge cases. honestly? iconic restraint 👑

9. Step-by-Step Details ✨

okay so this section walks through a typical failover, step by step, in the case where IKEv2 Message ID values are synchronized 🎀

  • the active cluster member and the peer set up the session 🤝 they both say "hey, I can sync counters!" by sending the IKEV2_MESSAGE_ID_SYNC_SUPPORTED notification in the IKE_AUTH exchange 💖
  • later on, the active member dies 💀 and a standby member takes over ✨ the standby sends its own idea of the IKE Message IDs (both incoming and outgoing) to the peer in an Informational message exchange with Message ID zero 🧚
  • the peer authenticates the message first 🔐 then it compares the received values with its local ones and picks the higher value 👑 it updates its Message IDs to those higher values and proposes the same values in its response 💅
  • the peer should not wait for any pending responses while it's responding with the new Message ID values 🙈 for example, say the window size is 5 and the peer's window is 3-7, and the peer has sent requests 3, 4, 5, 6, and 7, but only got responses for 4, 5, 6, and 7 (not 3) 😭 then it should put 8 in its EXPECTED_SEND_REQ_MESSAGE_ID payload and stop waiting for a response to message 3, period 🫶
  • same energy for incoming requests 🦋 the peer should also not wait for pending (incoming) requests 🌸 for example, with the same window size of 5 and window of 3-7, if the peer got requests 4, 5, 6, and 7 but not 3, it should send 8 in the EXPECTED_RECV_REQ_MESSAGE_ID payload and not expect to receive message 3 anymore 🚫

10. Interaction with Other Specifications

the usage scenario here is an IKEv2 SA that's been set up between the active member of a hot standby cluster and a peer, then a failover happens and the standby becomes active 🌈 this solution also assumes the IKEv2 SA state was continuously synced between the active and standby members before the failover, so the standby isn't starting from scratch 🧠

  • session resumption [12] assumes the peer (client or initiator) notices it needs to re-establish the session 📱 but in IKEv2/IPsec SA counter synchronization, it's the newly active member (a gateway or responder) that notices it needs to sync the SA counter after failover 👀 also, in a hot standby cluster, the peer sets up the IKEv2/IPsec session with one IP address that stands for the whole cluster 🏰 so the peer usually doesn't even notice a failover, unless the standby takes too long to become active and the IKEv2 SA times out through the IKEv2 liveness check mechanism ⏰ so basically, session resumption and SA counter sync after failover are mutually exclusive 🙅‍♀️ they're not expected to be used together, but both features can live in the same implementation without messing with each other 💜
  • the IKEv2 Redirect mechanism for load balancing [13] can be used either during the early stages of SA setup (the IKE_SA_INIT and IKE_AUTH exchanges) or after the session is established 🔀 SA counter sync is only useful after the IKE SA is established and a failover has happened 🎯 so unlike Redirect, it's irrelevant during the first two exchanges 🤷‍♀️ Redirect after the session is up is mostly useful for timed or planned shutdown/maintenance 🛠️ a real failover can't be detected by the active member ahead of time 😬 so using Redirect after session establishment isn't possible when it comes to failover 🚫 which means Redirect and SA counter sync after failover are mutually exclusive, in the sense described above 💅
  • IKEv2 Failure Detection [8] solves a similar problem, where the peer can quickly detect that a cluster member has crashed based on a token 🪙 but it's unrelated to this scenario, because in failover the goal is for the peer to not notice that a failure happened at all 🥷

11. Security Considerations

⚠️ this part is seriously important, bestie, so read it carefully 🫶

since Message ID synchronization messages have to be sent with Message ID zero, they're potentially vulnerable to replay attacks 😱 because of how this protocol works, these can only be denial-of-service (DoS) attacks, and we're aware of two variants 🚨

  • replay of a Message ID synchronization request: this is countered by the requirement that the Send counter sent by the cluster member should always be monotonically increasing 📈 the peer enforces that by silently dropping any messages that contradict it 🤫
  • replay of the Message ID synchronization response: this is countered by sending the nonce data along with the synchronization payload 🎲 the same nonce data has to come back in the response 🔁 so the standby member will only accept a reply for the current request 🎯 after it gets a valid response, it MUST NOT process the same response again, and it MUST discard any additional responses 🗑️

as mentioned in Section 7, triggering counter synchronization with out-of-window, potentially replayed messages could open a DoS vulnerability 😭 this risk is mitigated by the solution described in that section 🛡️ stay safe out there 💖

12. IANA Considerations

this document introduces four new IKEv2 Notification Message types, as described in Section 6 🎀 the new Notify Message Types got these values assigned:

          +-------------------------------------+-------+
          | Name                                | Value |
          +-------------------------------------+-------+
          | IKEV2_MESSAGE_ID_SYNC_SUPPORTED     | 16420 |
          | IPSEC_REPLAY_COUNTER_SYNC_SUPPORTED | 16421 |
          | IKEV2_MESSAGE_ID_SYNC               | 16422 |
          | IPSEC_REPLAY_COUNTER_SYNC           | 16423 |
          +-------------------------------------+-------+

13. Acknowledgements 🙌

big thank yous to Pratima Sethi and Frederic Detienne for their review comments and super valuable suggestions on the initial version of the document 💜

we'd also like to thank these people (in alphabetical order) for their review comments and valuable suggestions: Dan Harkins, Paul Hoffman, Steve Kent, Tero Kivinen, David McGrew, and Pekka Riikonen 🌸 you all are literally the best 🫶

14. References 📚

14.1. Normative References

  • [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
  • [2] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005.
  • [3] Kent, S., "IP Authentication Header", RFC 4302, December 2005.
  • [4] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, "Internet Key Exchange Protocol Version 2 (IKEv2)", RFC 5996, September 2010.
  • [5] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.

14.2. Informative References

  • [6] Nir, Y., "IPsec Cluster Problem Statement", RFC 6027, October 2010.
  • [7] Nadas, S., Ed., "Virtual Router Redundancy Protocol (VRRP) Version 3 for IPv4 and IPv6", RFC 5798, March 2010.
  • [8] Nir, Y., Ed., Wierbowski, D., Detienne, F., and P. Sethi, "A Quick Crash Detection Method for the Internet Key Exchange Protocol (IKE)", RFC 6290, June 2011.
  • [9] Housley, R., "Using Advanced Encryption Standard (AES) Counter Mode With IPsec Encapsulating Security Payload (ESP)", RFC 3686, January 2004.
  • [10] Viega, J. and D. McGrew, "The Use of Galois/Counter Mode (GCM) in IPsec Encapsulating Security Payload (ESP)", RFC 4106, June 2005.
  • [11] McGrew, D. and B. Weis, "Using Counter Modes with Encapsulating Security Payload (ESP) and Authentication Header (AH) to Protect Group Traffic", RFC 6054, November 2010.
  • [12] Sheffer, Y. and H. Tschofenig, "Internet Key Exchange Protocol Version 2 (IKEv2) Session Resumption", RFC 5723, January 2010.
  • [13] Devarapalli, V. and K. Weniger, "Redirect Mechanism for the Internet Key Exchange Protocol Version 2 (IKEv2)", RFC 5685, November 2009.

Appendix A. IKEv2 Message ID Sync Examples 🧁

this (non-normative) section has some examples showing how the IKEv2 Message ID values get synced 🎀 we use a tuple notation, where the two counters EXPECTED_SEND_REQ_MESSAGE_ID and EXPECTED_RECV_REQ_MESSAGE_ID on each protocol party are written as (EXPECTED_SEND_REQ_MESSAGE_ID, EXPECTED_RECV_REQ_MESSAGE_ID) 🔢

quick tip-off 👀 if the IKE message counters are already synced (like in the first example), the numbers come out reversed between the two sides 🔄 so if one party plans to send the next request as 4, the other one expects the next received request to be 4 💭

A.1. Normal Failover -- Example 1 🌷

   Standby (Newly Active) Member                            Peer
   - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
   Sync Request (0, 5) -------->

                             Peer has the values (5, 0), so it sends
                <------------- (5, 0) as the Sync Response

in this one, the peer most recently sent an IKE request with Message ID 4, and has never received a request 📨 so the peer's expected values for the next pair of messages are (5, 0) 💫 those are the same values the member sent, so they go back as-is ✨

A.2. Normal Failover -- Example 2 🦋

   Standby (Newly Active) Member                            Peer
   - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
   Sync Request (2, 3) -------->

                             Peer has the values (4, 5), so it sends
                <------------- (4, 5) as the Sync Response

here the peer most recently sent an IKE message with Message ID 3, and received one with ID 4 📬 so the peer's expected values for the next pair are (4, 5) 🧮 both of those are higher than the matching values just received from the member (the order of tuple members is reversed for this comparison, so pay attention 👀), which means they get sent as-is 💖

A.3. Normal Failover -- Example 3 🌈

   Standby (Newly Active) Member                            Peer
   - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
   Sync Request (2, 5) -------->

                             Peer has the values (2, 4), so it sends
                <-------------(5, 4) as the Sync Response

in this example, the newly active member expects to send the next IKE message with ID 2 🆕 it sends an expected receive value of 5, which is higher than the last ID it has seen from the peer, because it thinks some incoming messages may have gotten lost 😬 the peer last sent a message with ID 1, and received one with ID 3, which shows that a couple of messages sent by the previously active member never got synced over to the other member 🫠 so the peer's next expected (send, receive) values are (2, 4) 💅 the peer replies with the maximum of the received and expected value for both the send and receive counters: (max(2, 5), max(4, 2)) = (5, 4) 👑 iconic, periodt ✨

A.4. Simultaneous Failover 💥

okay so this one is giving chaos 😭 when failover happens on both sides at the same time, they each send a synchronization request at once. ✨ The end result is that the higher counter values win 👑, so everyone ends up on the bigger numbers. the figure below shows how it plays out 🦋

   Standby (Newly Active) Member                            Peer
   - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

   Sync Request (4,4)     ----->

                    <-------------- Sync Request (5,5)

   Sync Response (5,5)    ---->

                        <--------  Sync Response (5,5)

Authors' Addresses 🎀

Raj Singh (editor) Cisco Systems, Inc. Divyashree Chambers, B Wing, O'Shaugnessy Road Bangalore, Karnataka 560025 India

Phone: +91 80 4301 3320 EMail: rsj@cisco.com

Kalyani Garigipati Cisco Systems, Inc. Divyashree Chambers, B Wing, O'Shaugnessy Road Bangalore, Karnataka 560025 India

Phone: +91 80 4426 4831 EMail: kagarigi@cisco.com

Yoav Nir Check Point Software Technologies Ltd. 5 Hasolelim St. Tel Aviv 67897 Israel

EMail: ynir@checkpoint.com

Yaron Sheffer Porticor Cloud Security

EMail: yaronf.ietf@gmail.com

Dacheng Zhang Huawei Technologies Ltd.

EMail: zhangdacheng@huawei.com

🌈 that's the whole squad, bestie, the people who made this happen 💖

📦 where this page comes from