RFC 6290

A Quick Crash Detection Method for the Internet Key Exchange Protocol (IKE)

📅 published June 2011, from ietf

A Quick Crash Detection Method for the Internet Key Exchange Protocol (IKE) 💖

Hey bestie, here's the title block 🎀 This one is RFC 6290, published in June 2011 as a Standards Track doc with ISSN 2070-1721. Y. Nir (Ed.) from Check Point is the lead editor, with D. Wierbowski from IBM and F. Detienne and P. Sethi from Cisco. The header doesn't list anything it obsoletes or updates, so it's a clean slate 🧚

Abstract ✨

okay so this doc adds an extension to IKEv2 (Internet Key Exchange version 2) that lets peers spot a Security Association (SA) desynchronization way faster, using a saved token 🦋

the problem: when an IPsec tunnel between two IKEv2 peers drops because one of them restarted, the other peer can take as much as several minutes to realize the reboot happened 😭 that delay is the whole issue, and this extension is built to let recovery start right after the restart 💅

Status of This Memo 🎀

this is an Internet Standards Track document 💜

it's a product of the Internet Engineering Task Force (IETF), it represents the consensus of the IETF community, it got public review, and the Internet Engineering Steering Group (IESG) approved it for publication. for more on Internet Standards, check Section 2 of RFC 5741 🌸

info on the current status, any errata, and how to send feedback lives at http://www.rfc-editor.org/info/rfc6290 🧚

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

this doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as they stand on the publication date. please actually read those, because they spell out your rights and restrictions for this doc 📖

if you pull Code Components out of this document, they must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions, and they come with no warranty, as the Simplified BSD License describes 🔥

Table of Contents 🎀

1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
  1.1.  Conventions Used in This Document  . . . . . . . . . . . .  3
2.  RFC 5996 Crash Recovery  . . . . . . . . . . . . . . . . . . .  4
3.  Protocol Outline . . . . . . . . . . . . . . . . . . . . . . .  5
4.  Formats and Exchanges  . . . . . . . . . . . . . . . . . . . .  6
  4.1.  Notification Format  . . . . . . . . . . . . . . . . . . .  6
  4.2.  Passing a Token in the AUTH Exchange . . . . . . . . . . .  7
  4.3.  Replacing Tokens after Rekey or Resumption . . . . . . . .  8
  4.4.  Replacing the Token for an Existing SA . . . . . . . . . .  9
  4.5.  Presenting the Token in an Unprotected Message . . . . . .  9
5.  Token Generation and Verification  . . . . . . . . . . . . . . 10
  5.1.  A Stateless Method of Token Generation . . . . . . . . . . 11
  5.2.  A Stateless Method with IP Addresses . . . . . . . . . . . 11
  5.3.  Token Lifetime . . . . . . . . . . . . . . . . . . . . . . 12
6.  Backup Gateways  . . . . . . . . . . . . . . . . . . . . . . . 12
7.  Interaction with Session Resumption  . . . . . . . . . . . . . 13
8.  Operational Considerations . . . . . . . . . . . . . . . . . . 14
  8.1.  Who Should Implement This Specification  . . . . . . . . . 14
  8.2.  Response to Unknown Child SPI  . . . . . . . . . . . . . . 15
9.  Security Considerations  . . . . . . . . . . . . . . . . . . . 16
  9.1.  QCD Token Generation and Handling  . . . . . . . . . . . . 16
  9.2.  QCD Token Transmission . . . . . . . . . . . . . . . . . . 17
  9.3.  QCD Token Enumeration  . . . . . . . . . . . . . . . . . . 18
10. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 18
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19
  12.1. Normative References . . . . . . . . . . . . . . . . . . . 19
  12.2. Informative References . . . . . . . . . . . . . . . . . . 19
Appendix A.  The Path Not Taken  . . . . . . . . . . . . . . . . . 20
  A.1.  Initiating a New IKE SA  . . . . . . . . . . . . . . . . . 20
  A.2.  SIR  . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
  A.3.  Birth Certificates . . . . . . . . . . . . . . . . . . . . 20
  A.4.  Reducing Liveness Check Length . . . . . . . . . . . . . . 21

1. Introduction ✨

okay so IKEv2, as described in [RFC5996] and its predecessor RFC 4306, already has a way to recover when one peer reboots 🌸 as long as traffic is flowing in both directions, the rebooted peer should bring the tunnels back up right away 💖

but here's the catch 😭 a lot of the time, the rebooted peer is a VPN gateway that only protects servers, so all the traffic is inbound. other times, the peer that didn't reboot has a dynamic IP address, so the rebooted one can't start IKE because it doesn't know that address. in those cases, the rebooted peer just can't re-establish the tunnels. Section 2 walks through how recovery works under RFC 5996 and why it can take several minutes 🫠

so here's the fix 🦋 the method sends an octet string called a "QCD token" in the IKE_AUTH exchange that sets up the tunnel. the token gets stored on the peer as part of the IKE SA. after a reboot, the rebooted implementation can regenerate the token and send it to the peer, so the old IKE SA gets deleted. deleting that IKE SA means the new IPsec tunnels get set up quickly 🚀 this is covered in Section 3.

1.1. Conventions Used in This Document 🎀

the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 📖

"token" means an octet string that an implementation can generate using only the properties of a protected IKE message (such as IKE Security Parameter Indexes (SPIs)) as input. a conforming implementation MUST be able to generate the same token from the same input even after rebooting 💜

"token maker" is an implementation that generates a token and sends it to the peer as this document specifies 🧚

"token taker" is an implementation that stores such a token, or a digest of it, so it can check that a new token it receives matches the old one it stored 🔍

"non-volatile storage" means a data storage module that persists across restarts of the token maker. examples include an internal disk, an internal flash memory module, an external disk, and an external database 💾 a small non-volatile storage module is required for a token maker, but a larger one can be used to boost performance, as Section 8.2 describes 🌈

2. RFC 5996 Crash Recovery 💅

when one peer loses state or reboots, the other peer doesn't get any notification 😳 so unidirectional IPsec traffic can still flow. the rebooted peer can't decrypt it, though, and the only fix is to send an unprotected INVALID_SPI notification, as described in Section 3.10.1 of [RFC5996]. that same section describes how the recipient should process one of these:

If this Informational Message is sent outside the context of an IKE_SA, it should be used by the recipient only as a "hint" that something might be wrong (because it could easily be forged).

so INVALID_SPI can only ever be a hint 🫣 the non-rebooted peer still has to figure out whether the IPsec SA, and the parent IKE SA, are actually still valid. Section 2.4 of [RFC5996] covers how to do that. the method is called a "liveness check": you send a protected, empty INFORMATIONAL message and wait for a response. people sometimes call this "Dead Peer Detection" or DPD 🕵️‍♀️

Section 2.4 doesn't say how many times the liveness check message should be retransmitted, or for how long, but it does suggest this:

It is suggested that messages be retransmitted at least a dozen times over a period of at least several minutes before giving up on an SA...

those "at least several minutes" are a time when both peers are active, but IPsec can't be used 😭

especially after a reboot (rather than a fail-over or an administrative clearing of state), the peer doesn't recover right away. a reboot can take anywhere from a few seconds to a few minutes, depending on the system 🕰️ so at first the peer just goes silent, meaning it neither sends nor responds to any messages. IKEv2 implementations can detect this and follow the rules in Section 2.4:

If there has only been outgoing traffic on all of the SAs associated with an IKE SA, it is essential to confirm liveness of the other endpoint to avoid black holes. If no cryptographically protected messages have been received on an IKE SA or any of its Child SAs recently, the system needs to perform a liveness check in order to prevent sending messages to a dead peer.

[RFC5996] doesn't set any time limits 🙈 but the peer might start liveness checks before the other end even starts sending INVALID_SPI notifications, because it noticed that the other end stopped sending packets while it was still rebooting or recovering.

so the several-minute recovery window overlaps with the other peer's actual recovery time 🤯 if the security gateway takes several minutes to boot up after a crash, the other peers will already have finished their liveness checks before the crashed peer even gets a chance to send INVALID_SPI notifications. main character problem, honestly 💀

some peers lose state and can recover immediately. in those cases, it can still take several minutes to recreate the IPsec SAs 🌸

also, the IKEv2 specification gives no guidance on the number of retries or the length of timeouts, because those don't affect interoperability ✨ that means implementations are allowed to use the hints from INVALID_SPI messages to shorten those timeouts. different environments and situations can call for different rules 🧠

some existing IKEv2 implementations already do this. they shorten timeouts or limit retries based on those hints, and they start liveness checks quickly after the other end goes silent 🔥 but Appendix A.4 explains why that may not be enough 👀

Part 1 of 4 is done 🎀 the rest of the doc (Section 3 onward) is coming up next, so stay tuned 💖

3. Protocol Outline ✨

Supporting implementations send a notification called a "QCD token" 🎀 (see Section 4.1) in the first IKE_AUTH exchange messages. Those are the first IKE_AUTH request and the final IKE_AUTH response, the ones carrying the AUTH payloads. How a token gets generated is up to each implementation, and Section 5 has the considerations. Implementations that send these tokens are called "token makers" 💅.

A supporting implementation that receives a token MUST store it (or a digest of it) along with the IKE SA. Implementations that support this part of the protocol are called "token takers" 🦋. Section 8.1 covers which implementations need to be token takers and which should be token makers. Implementations that aren't token takers will just silently ignore QCD tokens 🙈.

When a token maker gets a protected IKE request with unknown IKE SPIs, it SHOULD generate a new token that's identical to the previous one. It then sends that token back to the requesting peer in an unprotected IKE message, as described in Section 4.5 🌸.

When a token taker gets the QCD token in an unprotected notification, it MUST verify that the TOKEN_SECRET_DATA matches the token stored with the matching IKE SA. If the verification fails, or if the IKE SPIs in the message don't match any existing IKE SA, it SHOULD log the event 👀. If it succeeds, it MUST silently delete the IKE SA tied to the IKE_SPI fields, plus all dependent child SAs. This event MAY also be logged. The token taker MUST accept these tokens from any IP address and port combination, so that different kinds of high-availability setups for the token maker can work 🫶.

A supporting token taker MAY immediately create new SAs using an Initial exchange. Or it may wait for subsequent traffic to trigger the creation of new SAs ✨.

See Section 7 for a quick chat about how this extension plays with IKEv2 Session Resumption ([RFC5723]) 💜.

4. Formats and Exchanges 🌈

4.1. Notification Format

The notification payload called "QCD token" is laid out like this 🍓:

                        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  !   SPI Size    ! QCD Token Notify Message Type !
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   !                                                               !
   ~                       TOKEN_SECRET_DATA                       ~
   !                                                               !
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Here's the breakdown, field by field 💖:

  • Protocol ID (1 octet) MUST be 1, since this message is related to an IKE SA.
  • SPI Size (1 octet) MUST be zero, per Section 3.10 of [RFC5996].
  • QCD Token Notify Message Type (2 octets) MUST be 16419, the value assigned for QCD token notifications.
  • TOKEN_SECRET_DATA (variable) holds a generated token, as described in Section 5.

4.2. Passing a Token in the AUTH Exchange

To keep things brief, only the Extensible Authentication Protocol (EAP) version of an AUTH exchange gets shown here. The non-EAP version is very similar 🧚. The figures below are based on Appendix C.3 of [RFC5996].

 first request       --> IDi,
                         [N(INITIAL_CONTACT)],
                         [[N(HTTP_CERT_LOOKUP_SUPPORTED)], CERTREQ+],
                         [IDr],
                         [N(QCD_TOKEN)]
                         [CP(CFG_REQUEST)],
                         [N(IPCOMP_SUPPORTED)+],
                         [N(USE_TRANSPORT_MODE)],
                         [N(ESP_TFC_PADDING_NOT_SUPPORTED)],
                         [N(NON_FIRST_FRAGMENTS_ALSO)],
                         SA, TSi, TSr,
                         [V+]

 first response      <-- IDr, [CERT+], AUTH,
                         EAP,
                         [V+]

                   / --> EAP
 repeat 1..N times |
                   \ <-- EAP

 last request        --> AUTH

 last response       <-- AUTH,
                         [N(QCD_TOKEN)]
                         [CP(CFG_REPLY)],
                         [N(IPCOMP_SUPPORTED)],
                         [N(USE_TRANSPORT_MODE)],
                         [N(ESP_TFC_PADDING_NOT_SUPPORTED)],
                         [N(NON_FIRST_FRAGMENTS_ALSO)],
                         SA, TSi, TSr,
                         [N(ADDITIONAL_TS_POSSIBLE)],
                         [V+]

Quick heads-up 🚨: the QCD_TOKEN notification is marked as optional, because this spec doesn't require every implementation to be both a token maker and a token taker. If only one peer sends the QCD token, then a reboot of the other peer won't be recoverable with this method. That might be totally fine if traffic usually starts from the other peer 🤷‍♀️.

Either way, the lack of a QCD_TOKEN notification MUST NOT be read as a sign that the peer doesn't support this standard. On the flip side, if a peer doesn't understand this notification, it'll just ignore it. So a peer can send this notification freely, even if it isn't sure whether the other side supports it 💅.

The QCD_TOKEN notification is related to the IKE SA. It should come right after the AUTH payload, and before the Configuration payload and all payloads related to the child SA 🎀.

4.3. Replacing Tokens after Rekey or Resumption

After you rekey an IKE SA, the IKE SPIs get replaced, so the new SA needs a token too 🔁. If only the responder in the rekey exchange is a token maker, this can happen within the CREATE_CHILD_SA exchange. If the initiator is a token maker, then we need an extra INFORMATIONAL exchange.

The following figure shows the CREATE_CHILD_SA exchange for rekeying the IKE SA. Only the responder sends a QCD token:

   request             --> SA, Ni, [KEi]

   response            <-- SA, Nr, [KEr], N(QCD_TOKEN)

If the initiator is also a token maker, it SHOULD start an INFORMATIONAL exchange right after the CREATE_CHILD_SA exchange, like this:

   request             --> N(QCD_TOKEN)

   response            <--

For session resumption, as specified in [RFC5723], it's a similar situation 🌙. The responder is necessarily the peer that crashed, so it SHOULD send a new ticket within the protected payload of the IKE_SESSION_RESUME exchange. If the Initiator is also a token maker, it needs to send a QCD_TOKEN in a separate INFORMATIONAL exchange.

The INFORMATIONAL exchange described in this section can also be used if QCD tokens need to be replaced because of a key rollover. Heads up though: token takers are required to verify at least 4 QCD tokens, so this only becomes necessary if secret QCD keys roll over more than four times as often as IKE SAs get rekeyed. Section 5.1 has an example method that uses secret keys which might need rollover 🔑.

4.4. Replacing the Token for an Existing SA

With some token generation methods, such as the one described in Section 5.2, a QCD token can sometimes go invalid even though the IKE SA is still perfectly valid 😤.

In that case, the token maker MUST send the new token in a protected message under that IKE SA. That exchange could be a simple INFORMATIONAL, like the one in the last figure of the previous section. Or it can be part of a MOBIKE INFORMATIONAL exchange, like the one in the following figure. That figure is taken from Section 2.2 of [RFC4555] and modified by adding a QCD_TOKEN notification 🦋:

 (IP_I2:4500 -> IP_R1:4500)
 HDR, SK { N(UPDATE_SA_ADDRESSES),
           N(NAT_DETECTION_SOURCE_IP),
           N(NAT_DETECTION_DESTINATION_IP) }  -->

                       <-- (IP_R1:4500 -> IP_I2:4500)
                           HDR, SK { N(NAT_DETECTION_SOURCE_IP),
                                N(NAT_DETECTION_DESTINATION_IP) }

                       <-- (IP_R1:4500 -> IP_I2:4500)
                           HDR, SK { N(COOKIE2), [N(QCD_TOKEN)] }

 (IP_I2:4500 -> IP_R1:4500)
 HDR, SK { N(COOKIE2), [N(QCD_TOKEN)] }  -->

A token taker MUST accept these gratuitous QCD_TOKEN notifications, as long as they're carried in protected exchanges. A token maker SHOULD NOT generate them unless it can no longer generate the old QCD_TOKEN 🙅‍♀️.

4.5. Presenting the Token in an Unprotected Message

This QCD_TOKEN notification is unprotected. It gets sent as a response to a protected IKE request that uses an IKE SA that's unknown 👻.

        message             --> N(INVALID_IKE_SPI), N(QCD_TOKEN)+

If child SPIs are persistently mapped to IKE SPIs as described in Section 8.2, a token taker might get the following unprotected message in response to an Encapsulating Security Payload (ESP) or Authentication Header (AH) packet 🧩:

        message             --> N(INVALID_SPI), N(QCD_TOKEN)+

The QCD_TOKEN and INVALID_IKE_SPI notifications are sent together, so that both implementations that follow this spec and ones that don't can understand them 🫶. Similar to the description in Section 2.21 of [RFC5996], the IKE SPI and message ID fields in the packet headers are copied from the protected IKE request.

To support a periodic rollover of the secret used for token generation, the token taker MUST support at least four QCD_TOKEN notifications in a single packet. The token counts as verified if any of the QCD_TOKEN notifications matches. The token maker MAY generate up to four QCD_TOKEN notifications, based on several generations of keys 🔐.

If the QCD_TOKEN verifies OK, the receiver MUST silently discard the IKE SA and all associated child SAs. If the QCD_TOKEN can't be validated, a response MUST NOT be sent, though the event may be logged. Section 5 defines token verification 📜.

5. Token Generation and Verification 🔐

No token generation method is mandated by this document 🙌. Two methods are documented in the following sub-sections, but they're only examples.

Here are the requirements for a token generation mechanism 💜:

  • Tokens MUST be at least 16 octets long, and no more than 128 octets long, to make storage and transmission easier. Tokens SHOULD be indistinguishable from random data ✨.
  • It should not be possible for an external attacker to guess the QCD token an implementation generates. Cryptographic mechanisms such as a pseudo-random number generator (PRNG) and hash functions are RECOMMENDED 🛡️.
  • The token maker MUST be able to re-generate or retrieve the token based on the IKE SPIs, even after it reboots 🔄.
  • The method of token generation MUST be such that a collision of QCD tokens between different pairs of IKE SPI is highly unlikely 🎲.

For verification, the token taker does a bitwise comparison of the token stored with the IKE SA against the token sent in the unprotected message. Multihomed takers might flip back and forth between several addresses, and have their tokens replaced as described in Section 4.4 🌊. To help avoid the case where the latest stored token doesn't match the address used after the maker lost state, the token taker MAY store several earlier tokens associated with the IKE SA. It can then silently discard the SA if any of them matches 🦋.

5.1. A Stateless Method of Token Generation ✨

Okay bestie, let's talk about the stateless way to make a token 🧚. Here "stateless" means no per-tunnel state gets stored, though you do need a tiny bit of non-volatile storage. 💅

  • At installation or right after the token maker's very first boot, 32 random octets get generated using a secure random number generator or a PRNG 🎲.
  • Those 32 bytes, called the "QCD_SECRET", get stored in non-volatile storage on the machine and kept indefinitely 🔐.
  • If key rollover is required by policy, the implementation MAY periodically generate a new QCD_SECRET and keep up to 3 previous generations. When sending an unprotected QCD_TOKEN, as many as 4 notification payloads may be sent, each from a different QCD_SECRET. this part is giving multiple secrets, iykyk 🌈
  • The TOKEN_SECRET_DATA is calculated as follows:
            TOKEN_SECRET_DATA = HASH(QCD_SECRET | SPI-I | SPI-R)

5.2. A Stateless Method with IP Addresses

This method is basically the same vibe as the one before, except the IP address of the token taker also gets tossed into the block being hashed 🦋. The downside is that the token needs to be replaced (as described in Section 4.4) whenever the token taker changes its address. Not ideal, bestie 😭

See Section 9.2 for a discussion of a use-case for this method. When using this method, the TOKEN_SECRET_DATA field is calculated like this:

         TOKEN_SECRET_DATA = HASH(QCD_SECRET | SPI-I | SPI-R | IPaddr-T)

The IPaddr-T field specifies the IP address of the token taker. Secret rollover considerations are similar to those in the previous section.

Now, if the token taker is multihomed, the QCD token only matches one of its IP addresses 👀. Usually that's not a problem, since packets sent to the token maker come out the same IP address. If for some reason that changes, the token maker can replace the token as described in Section 4.4. If IKEv2 Mobility and Multihoming (MOBIKE) is used, replacing the tokens SHOULD be piggybacked on the INFORMATIONAL exchange with the UPDATE_SA_ADDRESSES notifications. 🎀

Corner case alert 🚨: the token taker starts using a new IP address (because of multihoming, roaming, or normal network operations) and the token maker loses state before it replaces the token. The token maker will send a correct QCD token, but the token taker still has the old one. The extension won't work in that situation, and the peers will revert to RFC 5996 recovery. Not the glow-up we wanted 💀

5.3. Token Lifetime

The token is associated with a single IKE SA and SHOULD be deleted by the token taker when that SA gets deleted or expires 🗑️. More formally, the token is associated with the pair (SPI-I, SPI-R). Simple, clean, iconic ✨

6. Backup Gateways ✨

Making crash detection and recovery quick is a worthy goal 💖. But rebooting a gateway takes a non-zero amount of time, so lots of implementations keep a standby gateway ready to take over the second the primary fails for any reason 🫶. [RFC6027] describes considerations for these clusters of gateways with synchronized state, but the rest of this section still applies even when there's no synchronized state.

If a configuration like that is available, it is RECOMMENDED that the standby gateway be able to generate the same token as the active gateway. If the method described in Section 5.1 is used, this means the QCD_SECRET field is identical on both gateways. The payoff is that crash recovery is available immediately 🚀.

Quick distinction though: this section is about "high-availability" setups, where only one gateway is active at any given moment 👑. That's different from "load sharing" setups, where more than one gateway is active at the same time. For load sharing configurations, please see Section 9.2 for security considerations 🔍.

7. Interaction with Session Resumption ✨

Session resumption, specified in [RFC5723], lets you set up a new IKE SA while using way fewer computing resources 🧠. This is especially useful for a remote access gateway with tons of tunnels. If that gateway fails, all those remote access clients need an IKE SA again, either with the rebooted gateway or a backup. All that re-establishing happens in a short window, which is a real burden on the gateway 😩. Session resumption fixes this by having the clients store an encrypted derivative of the IKE SA for quick re-establishment.

What session resumption does NOT fix is detecting that the peer gateway has failed 🙈. A failed gateway can go undetected for an arbitrarily long time, because IPsec has no packet acknowledgement and applications can't tell the IPsec layer that the tunnel "does not work". Section 2.4 of RFC 5996 doesn't say how long an implementation needs to wait before starting a liveness check. It only says "not recently" (see the full quote in Section 2). In practice, some mobile devices wait a very long time before starting a liveness check, so parts of the device can stay in low-power modes and the battery lasts longer 🔋.

QCD tokens help detect the peer's failure in the case where a liveness check hasn't ended yet (or hasn't begun) 💜.

A remote access client that conforms to both specs will store QCD tokens, plus the Session Resumption ticket if the gateway provides one. A remote access gateway that conforms to both specs will generate a QCD token for the client. When the gateway reboots, the client finds out in one of two ways:

  1. The client does regular liveness checks, or else the time for some other IKE exchange has come. Since the gateway is still down, the IKE exchange times out after several minutes. In this case, QCD does not help 😬.
  2. Either the primary gateway or a backup gateway (see Section 6) is ready and sends a QCD token to the client. In that case, the client quickly re-establishes the IPsec tunnel, either with the rebooted primary gateway or the backup gateway as described in this document 🎉.

The full combined protocol looks like this 🌸:

        Initiator                Responder
        -----------              -----------
       HDR, SAi1, KEi, Ni  -->

                           <--    HDR, SAr1, KEr, Nr, [CERTREQ]

       HDR, SK {IDi, [CERT,]
       [CERTREQ,] [IDr,]
       AUTH, N(QCD_TOKEN)
       SAi2, TSi, TSr,
       N(TICKET_REQUEST)}  -->
                           <--    HDR, SK {IDr, [CERT,] AUTH,
                                  N(QCD_TOKEN), SAr2, TSi, TSr,
                                  N(TICKET_LT_OPAQUE) }

                ---- Reboot -----

       HDR, {}             -->
                           <--  HDR, N(QCD_TOKEN)

       HDR, [N(COOKIE),]
       Ni, N(TICKET_OPAQUE)
       [,N+]               -->
                           <--  HDR, Nr [,N+]

8. Operational Considerations ✨

8.1. Who Should Implement This Specification 💅

Throughout this document, reboot time has been used to mean two things: the moment the implementation crashes, and the moment it's ready to process IPsec packets and IKE exchanges 🔄. Depending on the hardware, software, and cause of the reboot, rebooting can take anywhere from a few seconds to several minutes ⏳. If the implementation is down for a long time, the benefit of this protocol extension shrinks. So for critical systems, backup gateways as described in Section 6 are the move 🫶.

Implementing the "token maker" side of QCD makes sense for IKE implementations where protected connections originate from the peer, like inter-domain VPNs and remote access gateways 🏰. Implementing the "token taker" side makes sense for IKE implementations where protected connections originate, like inter-domain VPNs and remote access clients 📱.

To clarify, bestie:

  • For remote-access clients it makes sense to implement the token taker role.
  • For remote-access gateways it makes sense to implement the token maker role.
  • For inter-domain VPN gateways it makes sense to implement both roles, because it can't be known in advance where the traffic originates.
  • It is perfectly valid to implement both roles in any case, for example, when using a single library or a single gateway to perform several roles.

To limit the effects of Denial-of-Service (DoS) attacks, a token taker SHOULD limit the rate of QCD_TOKENs verified from a particular source 🚫.

If excessive amounts of IKE requests protected with unknown IKE SPIs arrive at a token maker, the IKE module SHOULD revert to the behavior described in Section 2.21 of [RFC5996] and either send an INVALID_IKE_SPI notification or ignore it entirely 🙅‍♀️.

Section 9.2 requires that token makers never send a QCD token in the clear for a valid IKE SA, and it describes some configurations where that could happen 😳. Implementations that may be installed in such configurations SHOULD automatically detect this and disable the extension in unsafe configurations, and they MUST allow the user to control whether the extension is enabled or disabled. The user is always in charge, periodt 👑.

8.2. Response to Unknown Child SPI ✨

After a reboot, an implementation is more likely to receive IPsec packets than IKE packets 📦. In that case, the rebooted implementation sends an INVALID_SPI notification, which triggers a liveness check. The token only gets sent in response to that liveness check, so it takes an extra round trip 😤.

To avoid that, an implementation with access to enough non-volatile storage MAY store a mapping of child SPIs to owning IKE SPIs, or to generated tokens 🗂️. If such a mapping is available and persistent across reboots, the rebooted implementation SHOULD respond to the IPsec packet with an INVALID_SPI notification, along with the appropriate QCD_TOKEN notifications. A token taker SHOULD verify the QCD token that arrives with an INVALID_SPI notification the same way it would if it had arrived with the IKE SPIs of the parent IKE SA ✅.

Plot twist: a persistent storage module might not get updated in a timely manner, so it could hold tokens for IKE SPIs that have already been rekeyed 🌀. A token taker MUST NOT take an invalid QCD token sent along with an INVALID_SPI notification as evidence that the peer is either malfunctioning or attacking. It SHOULD still limit the rate at which those notifications get processed 🚦.

9. Security Considerations 🔐

Serious security moment, bestie 😤: the extension described in this document must not reduce the security of IKEv2 or IPsec. Specifically, an eavesdropper must not learn any non-public information about the peers. No leaks, no drama 🤐.

The proposed mechanism should be secure against attacks by a passive man in the middle (MITM) (eavesdropper) 🕵️‍♀️. Such an attacker must not be able to disrupt an existing IKE session, either by resetting the session or by introducing significant delays ⛔. This requirement is especially significant, because this document introduces a new way to reset an IKE SA. So yeah, this one matters a LOT 💜.

The mechanism need not be similarly secure against an active MITM, since this type of attacker is already able to disrupt IKE sessions 🥀.

9.1. QCD Token Generation and Handling ✨

okay bestie, security time and it is SERIOUS 😭🔒 Tokens MUST be hard to guess. This is critical, because if an attacker can guess the token tied to an IKE SA, they can tear down that IKE SA and its tunnels whenever they want 💀. When the token shows up in the IKE_AUTH exchange, it's encrypted 🫶. When it gets sent again in an unprotected notification, it is NOT encrypted, but that is the last time this token is ever used, so it's giving one-time-use 🦋.

An aggregation of some tokens made by one maker, together with the related IKE SPIs, MUST NOT give an attacker the ability to guess other tokens 🚫. Specifically, if one taker doesn't properly secure the QCD tokens and an attacker gets access to them, that attacker MUST NOT be able to guess other tokens generated by the same maker. This is the reason the QCD_SECRET in Section 5.1 needs to be sufficiently long 💪.

The token taker MUST store the token in a secure manner 🔐. No attacker should be able to gain access to a stored token. Main character security energy fr fr.

The QCD_SECRET MUST be protected from access by other parties 👑. Anyone who gets their hands on this value will be able to delete all the IKE SAs for this token maker. Not me being dramatic but this is the whole ballgame 😭.

The QCD token is sent by the rebooted peer in an unprotected message. A message like that is subject to modification, deletion, and replay by an attacker 🙈. However, these attacks will not compromise the security of either side. Modification is meaningless because a modified token is just an invalid token 🥲. Deletion will only cause the protocol not to work, which means a delay in tunnel re-establishment as described in Section 2 ⏳. Replay is also meaningless, because the IKE SA has already been deleted after the first transmission 🧚.

9.2. QCD Token Transmission 🎀

A token maker MUST NOT send a valid QCD token in an unprotected message for an existing IKE SA 🚫💅.

This requirement is obvious and easy when there's only a single gateway. But some implementations use a load balancer to split the load between several physical gateways, and it MUST NOT be possible, even in that kind of setup, to trick one gateway into sending a valid QCD token for an IKE SA that is valid on another gateway 🙅‍♀️. This is true whether the attempt to trick the gateway uses the token taker's IP address or a different IP address 🌸.

IPsec failure detection is not applicable to deployments where the QCD secret is shared by multiple gateways and the gateways can't assess whether the token can legitimately be sent in the clear, while another gateway may still actually own the SAs 🤷‍♀️. Load balancing configurations typically fall into this category. For a load balancing configuration of IPsec gateways to support this specification, all members MUST be able to tell whether a particular IKE SA is active anywhere in the cluster 📡. One way to do this is to synchronize a list of active IKE SPIs among all the cluster members 🧠.

Because it includes the token taker's IP address in the token generation, the method in Section 5.2 can (under certain conditions) prevent revealing the QCD token for an existing pair of IKE SPIs to an attacker using a different IP address, even in a load-sharing cluster without state synchronization ✨. That method does NOT prevent revealing the QCD token to an active attacker who is spoofing the token taker's IP address 😤. That attacker may try to direct messages to a cluster member other than the one responsible for the IKE SA, hoping to trick that gateway into sending a QCD token for a valid IKE SA 🕵️‍♀️. That method SHOULD NOT be used unless the load balancer guarantees that IKE packets from the same source IP address always go to the same cluster member 🍓.

9.3. QCD Token Enumeration 🧚‍♀️

An attacker may try to attack QCD if the generation algorithm described in Section 5.1 is used 😬. The attacker sends several fake IKE requests to the gateway under attack, receiving and recording the QCD tokens in the responses. This lets the attacker build a dictionary of IKE SPIs to QCD tokens, which can later be used to tear down any IKE SA 💀.

Three factors mitigate this threat 🛡️:

  • The space of all possible IKE SPI pairs is huge: 2^128, so making such a dictionary is impractical 🌌. Even if we assume that one implementation always generates predictable IKE SPIs, the space is still at least 2^64 entries, so making the dictionary is extremely hard 🥵. To ensure this, token makers MUST generate unpredictable IKE SPIs by using a cryptographically strong pseudo-random number generator 🎲.
  • Throttling the number of QCD_TOKEN notifications sent out, as discussed in Section 8.1, especially when it's not soon after a crash, will limit the attacker's ability to build a dictionary 🚦.
  • The methods in Section 5.1 and Section 5.2 allow for a periodic change of the QCD_SECRET. Any such change invalidates the entire dictionary 🗑️✨.

10. IANA Considerations 📋

IANA has assigned a notify message type (16419) from the status types range (16406-40959) of the "IKEv2 Notify Message Types" registry with the name "QUICK_CRASH_DETECTION" 🎉.

11. Acknowledgements 🫶

We would like to thank Hannes Tschofenig and Yaron Sheffer for their comments about Session Resumption 💜. Others who contributed valuable comments are, in alphabetical order, Lakshminath Dondeti, Paul Hoffman, Tero Kivinen, Scott C Moonen, Magnus Nystrom, and Keith Welter 👑🌈.

12. References 📚

12.1. Normative References

[RFC2119]   Bradner, S., "Key words for use in RFCs to Indicate
            Requirement Levels", BCP 14, RFC 2119, March 1997.

[RFC4555]   Eronen, P., "IKEv2 Mobility and Multihoming Protocol
            (MOBIKE)", RFC 4555, June 2006.

[RFC5996]   Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen,
            "Internet Key Exchange Protocol Version 2 (IKEv2)",
            RFC 5996, September 2010.

12.2. Informative References

[RFC5723]   Sheffer, Y. and H. Tschofenig, "Internet Key Exchange
            Protocol Version 2 (IKEv2) Session Resumption", RFC 5723,
            January 2010.

[RFC6027]   Nir, Y., "IPsec Cluster Problem Statement", RFC 6027,
            October 2010.

[recovery]  Detienne, F., Sethi, P., and Y. Nir, "Safe IKE Recovery",
            Work in Progress, July 2009.

Appendix A. The Path Not Taken 🛤️

A.1. Initiating a New IKE SA 🆕

Instead of sending a QCD token, we could have the rebooted implementation start an Initial exchange with the peer, including the INITIAL_CONTACT notification. This would have the same effect, instructing the peer to erase the old IKE SA, as well as establishing a new IKE SA with fewer rounds 🏃‍♀️.

The disadvantage here is that in IKEv2, an authentication exchange MUST have a piggybacked Child SA set up 🚧. Since our use case is such that the rebooted implementation doesn't have traffic flowing to the peer, there are no good selectors for such a Child SA 😩.

Additionally, when authentication is asymmetric, such as when EAP is used, it is not possible for the rebooted implementation to initiate IKE 🙅‍♀️.

A.2. SIR 🔍

Another proposal considered for this work item is the SIR extension, which is described in [recovery]. Under that proposal, the non-rebooted peer sends a non-protected query to the possibly rebooted peer, asking whether the IKE SA exists. The peer replies with either a positive or negative response, and the absence of a positive response, along with the existence of a negative response, is taken as proof that the IKE SA has really been lost 🧐.

The working group preferred the QCD proposal to this one 💖.

A.3. Birth Certificates 📜

Birth Certificates is a method of crash detection that has never been formally defined. Bill Sommerfeld suggested this idea in a mail to the IPsec mailing list on August 7, 2000, in a thread discussing methods of crash detection 💌:

If we have the system sign a "birth certificate" when it reboots (including a reboot time or boot sequence number), we could include that with a "bad spi" ICMP error and in the negotiation of the IKE SA.

We believe that this method would have some problems. First, it requires Alice to store the certificate, so as to be able to compare the public keys. That requires more storage than does a QCD token. Additionally, the public key operations needed to verify the self-signed certificates are more expensive for Alice 💸.

We believe that a symmetric-key operation such as the one proposed here is more light-weight and simple than what's implied by the Birth Certificate idea 🪶.

A.4. Reducing Liveness Check Length ⏱️

Some implementations require fewer retransmissions over a shorter period of time for liveness checks started because of an INVALID_SPI or INVALID_IKE_SPI notification 🏎️.

We believe that the default retransmission policy should represent a good balance between the need for timely discovery of a dead peer and a low probability of false detection. We expect the policy to be set to take the shortest time such that this probability achieves a certain target. Therefore, we believe that reducing the elapsed time and retransmission count may create an unacceptably high probability of false detection, and this can be triggered by a single INVALID_IKE_SPI notification 😬.

Additionally, even if the retransmission policy is reduced to, say, one minute, it is still a very noticeable delay from a human perspective, from the time the gateway has come up (i.e., is able to respond with an INVALID_SPI or INVALID_IKE_SPI notification) until the tunnels are active, or from the time the backup gateway has taken over until the tunnels are active. The use of QCD tokens can reduce this delay 🌷.

Authors' Addresses 🖊️

Yoav Nir (editor)
Check Point Software Technologies, Ltd.
5 Hasolelim st.
Tel Aviv  67897
Israel

EMail: ynir@checkpoint.com


David Wierbowski
International Business Machines
1701 North Street
Endicott, New York  13760
United States

EMail: wierbows@us.ibm.com


Frederic Detienne
Cisco Systems, Inc.
De Kleetlaan, 7
Diegem  B-1831
Belgium

Phone: +32 2 704 5681
EMail: fd@cisco.com


Pratima Sethi
Cisco Systems, Inc.
O'Shaugnessy Road, 11
Bangalore, Karnataka  560027
India

Phone: +91 80 4154 1654
EMail: psethi@cisco.com

That's the whole RFC, bestie! 🌈✨ You made it through all of IKE crash detection 👑💖

📦 where this page comes from