RFC 7383

Internet Key Exchange Protocol Version 2 (IKEv2) Message Fragmentation

📅 published November 2014, from ietf

RFC 7383: IKEv2 Message Fragmentation 💖

Okay bestie, RFC 7383 is by V. Smyslov from ELVIS-PLUS, published in November 2014 as a Standards Track document (ISSN 2070-1721) 🎀. It doesn't obsolete or update any other RFCs, so it's a clean new spec. The whole point is about IKEv2 message fragmentation, which is how IKEv2 keeps its own big messages from getting chopped up at the IP level 🦋.

Abstract ✨

Okay so the abstract is literally the whole pitch 💅. This doc describes a way to dodge IP fragmentation for big Internet Key Exchange Protocol version 2 (IKEv2) messages. The payoff is that IKEv2 messages can get through network devices that won't let IP fragments pass 🫶.

Status of This Memo

This is an Internet Standards Track document 🌸.

It's a product of the Internet Engineering Task Force (IETF), it reflects the consensus of the IETF community, it got public review, and the Internet Engineering Steering Group (IESG) approved it for publication. If you want more on Internet Standards, check Section 2 of RFC 5741. Info about its current status, errata, and how to send feedback lives at http://www.rfc-editor.org/info/rfc7383 🔥.

Copyright (c) 2014 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, which you can find at http://trustee.ietf.org/license-info as they stood on the publication date. Please read these carefully, because they spell out your rights and restrictions for this doc 🙈. Code Components pulled out of this document 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 ....................................................2
   1.1. Problem Description ........................................2
   1.2. Proposed Solution ..........................................3
   1.3. Conventions Used in This Document ..........................4
2. Protocol Details ................................................4
   2.1. Overview ...................................................4
   2.2. Limitations ................................................4
   2.3. Negotiation ................................................5
   2.4. Using IKE Fragmentation ....................................5
   2.5. Fragmenting Message ........................................6
        2.5.1. Selecting Fragment Size .............................8
        2.5.2. PMTU Discovery ......................................9
        2.5.3. Fragmenting Messages Containing Unprotected
               Payloads ...........................................11
   2.6. Receiving IKE Fragment Message ............................11
        2.6.1. Replay Detection and Retransmissions ...............13
3. Interaction with Other IKE Extensions ..........................14
4. Transport Considerations .......................................14
5. Security Considerations ........................................15
6. IANA Considerations ............................................16
7. References .....................................................16
   7.1. Normative References ......................................16
   7.2. Informative References ....................................16
Appendix A. Design Rationale ......................................19
Appendix B. Correlation between IP Datagram Size and Encrypted
            Payload Content Size ..................................19
Acknowledgements ..................................................20
Author's Address ..................................................20

1. Introduction ✨

1.1. Problem Description

Okay so IKEv2, which is specified in [RFC7296], sends its messages over UDP 💖. Most IKEv2 messages are pretty tiny, usually under a few hundred bytes. The exception is the IKE_AUTH exchange, which needs much bigger messages, up to several KB, especially when certificates are being transferred 🌈.

Here's the drama: when an IKE message is bigger than the path MTU, it gets fragmented at the IP level. Some network devices, specifically some NAT boxes, don't let IP fragments through. That means IKE communication can get blocked completely, and then peers can't set up an IPsec Security Association (SA) 💀. Section 2 of [RFC7296] talks about how IP fragmentation affects IKEv2 and admits this is a problem.

Carrier-Grade NATs (CGNs) make things even messier 🔥. [RFC6888] lays out requirements for CGNs. It says CGNs must comply with Section 11 of [RFC4787], which requires NATs to support receiving IP fragments (REQ-14). In real life, meeting that requirement is a lot of extra memory work, especially for high-capacity CGN gear. People deploying IKE found that more and more ISPs use equipment that drops IP fragments, which breaks that requirement 🙈.

Security researchers keep finding attacks that rely on IP fragmentation 👑. For those reasons, and also as laid out in [FRAGDROP], lots of network operators filter all IPv6 fragments. Plus, many firewalls in the wild discard IPv6 fragments by default.

One recent study [BLACKHOLES] had two researchers use a measurement network to check fragment filtering. They sent packets fragmented to the minimum MTU of 1280 to 502 IPv6-enabled, reachable probes. During any given trial period, ten percent of the probes never received the fragmented packets 😭.

So yeah, this problem is real for both IPv4 and IPv6, and it can come from either network device deficiencies or operator choices 🦋.

1.2. Proposed Solution

The fix in this document is for IKEv2 to fragment big messages itself and swap them out for a series of smaller messages 🧚. That way, the resulting IP datagrams are small enough that IP-level fragmentation never happens.

The main goal is to let IKEv2 work in environments that might block IP fragments 💅. The goal doesn't assume IP fragmentation should be avoided completely. It only matters in cases where fragmentation gets in the way of IKE operations. This solution could still be used to avoid IP fragmentation in every situation where fragmentation within IKE is applicable, as recommended in Section 3.2 of [RFC5405]. Avoiding IP fragmentation would help IKEv2 in general 🫶.

The Security Considerations section of [RFC7296] names exhaustion of IP reassembly buffers as one of the possible attacks on the protocol 😈. [DOSUDPPROT] goes through several ways attacks on IKE using IP fragmentation can work, and one defense it proposes is to fragment within IKE, which is basically what this document does 👑.

1.3. Conventions Used in This Document

Here's the key words bit 🎀. 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].

2. Protocol Details 🦋

2.1. Overview

The big idea is to split large IKEv2 messages into a bunch of smaller ones, called IKE Fragment messages 💖. Fragmentation happens before the original message gets encrypted and authenticated, so every IKE Fragment message gets its own individual protection 🔒. On the receiving end, the IKE Fragment messages get collected, verified, decrypted, and merged back together into the original message from before encryption. Check Appendix A for the design rationale, it's a good read ✨.

2.2. Limitations

Since IKE Fragment messages are cryptographically protected, SK_a and SK_e must already be calculated 🔐. Generally speaking, the original message can be fragmented if and only if it contains an Encrypted payload.

That means messages in the IKE_SA_INIT exchange can't be fragmented 🙈. Most of the time that's fine, since IKE_SA_INIT messages are usually small enough to dodge IP fragmentation. But sometimes they get big, like when someone advertises a badly structured, super long list of algorithms or uses large Modular Exponentiation (MODP) groups. In those cases, IP fragmentation can still happen, and this solution won't help 💀.

Among existing IKEv2 extensions, messages from an IKE_SESSION_RESUME exchange, as defined in [RFC5723], can't be fragmented either. Check Section 3 for the details 🧚.

One more limitation: the smallest IP datagram carrying an IKE Fragment message is about 100 bytes, depending on the algorithms used. According to [RFC0791], the minimum IPv4 datagram size that's guaranteed not to be fragmented further is 68 bytes. So even the tiniest IKE Fragment messages could still get fragmented at the IP level in some situations. But super tiny Path MTU (PMTU) sizes are very rare in real life 🌸.

2.3. Negotiation

Okay so the initiator says it supports IKE fragmentation and wants to use it by including a Notification payload of type IKEV2_FRAGMENTATION_SUPPORTED in its IKE_SA_INIT request message 💅. If the responder also supports this extension and is up for using it, it includes the same notification in its response message 🫶.

Initiator                   Responder
-----------                 -----------
HDR, SAi1, KEi, Ni,
   [N(IKEV2_FRAGMENTATION_SUPPORTED)]  -->

                    <--   HDR, SAr1, KEr, Nr, [CERTREQ],
                               [N(IKEV2_FRAGMENTATION_SUPPORTED)]

The Notify payload is formatted 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(=0)| SPI Size (=0) |      Notify Message Type      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Here's what each field needs 👑:

  • Protocol ID (1 octet) - MUST be 0.
  • SPI Size (1 octet) - MUST be 0, meaning no Security Parameter Index (SPI) is present.
  • Notify Message Type (2 octets) - MUST be 16430, the value assigned for the IKEV2_FRAGMENTATION_SUPPORTED notification.

This notification contains no data 🌈. Okay, that's the first chunk, so more is coming in the next part 💖✨

2.4. Using IKE Fragmentation ✨

okay so IKE fragmentation MUST NOT be used unless both peers have said they support it 🫶 once that's sorted, the initiator of each exchange gets to decide whether to actually use it 💅 the responder usually replies in the same form as the request, but other considerations might override that, so don't get too comfy 🙈

the initiator can pick from a bunch of policies here 🦋 it could try sending an unfragmented message first and only resend it fragmented if no complete response shows up even after several retransmissions 💜 or it could always send fragmented messages (but see Section 3 🎀), or it might only fragment the big messages and the ones that are expected to trigger big responses 🔥

these general guidelines apply:

  • ok this one is a big deal 👑 if either peer has info that part of the transaction will probably get fragmented at the IP layer and mess up the IKE exchange, that peer SHOULD use IKE fragmentation 😭 the info could come from a lower layer, from configuration, or from heuristics 🧚 examples of heuristics are no complete response after several retransmissions for the initiator, and getting repeated retransmissions of the request for the responder 🌸
  • if either peer knows IKE fragmentation was already used in an earlier exchange in the context of the current IKE SA, that peer SHOULD keep using it for messages bigger than the current fragmentation threshold (see Section 2.5.1 ✨)
  • IKE fragmentation SHOULD NOT be used where IP-layer fragmentation of both the request and the response is unlikely 💀 like, there's zero point in fragmenting liveness check messages, bestie 🙄
  • if none of the above apply, the responder SHOULD respond in the same form (fragmented or not) as the request it's answering 🍓 the other guidelines can still override this, though, because of info or heuristics the responder has access to 🌈

in most cases, IKE fragmentation will be used in the IKE_AUTH exchange, especially if certificates are involved 🔥🔥

2.5. Fragmenting Message

okay real talk, only messages that contain an Encrypted payload are subject to IKE fragmentation 💖 to build the IKE Fragment messages, the original (unencrypted) content of the Encrypted payload gets split into chunks ✨ the content is treated as a binary blob, so it gets split no matter where the inner payloads start and stop 🦋 each chunk is then treated as the original content of an Encrypted Fragment payload and gets encrypted and authenticated 💜 so the Encrypted Fragment payload carries a chunk of the original content, just in encrypted form 🔐 the crypto processing is identical to what's described in Section 3.14 of [RFC7296], plus any documents that update it for particular algorithms or modes, like [RFC5282] 🎀

same deal as the Encrypted payload: if an Encrypted Fragment payload is present in a message, it MUST be the last payload in that message 👑

the Encrypted Fragment payload is written as SKF{...}, and its payload type is 53 🌸 it's also called the "Encrypted and Authenticated Fragment" payload, which is a whole mouthful, so we're keeping it iconic and short 💅

                        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        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |        Fragment Number        |        Total Fragments        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     Initialization Vector                     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   ~                      Encrypted content                        ~
   +               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |               |             Padding (0-255 octets)            |
   +-+-+-+-+-+-+-+-+                               +-+-+-+-+-+-+-+-+
   |                                               |  Pad Length   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   ~                    Integrity Checksum Data                    ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                        Encrypted Fragment Payload

here's the breakdown of the fields 🧚

  • Next Payload (1 octet): in the very first fragment (with Fragment Number equal to 1), this field MUST be set to the payload type of the first inner payload, same as for the Encrypted payload 🔥 in the rest of the Fragment messages (with Fragment Number greater than 1), this field MUST be set to zero 💀
  • Fragment Number (2 octets, unsigned integer): the current Fragment message number, starting from 1 ✨ this field MUST be less than or equal to the next field (Total Fragments) 🫶 and it MUST NOT be zero 🙅‍♀️
  • Total Fragments (2 octets, unsigned integer): the number of Fragment messages the original message was divided into 🍓 this field MUST NOT be zero 💜 and with PMTU discovery, it plays an additional role, so see Section 2.5.2 for the deets 🦋

the other fields are identical to the ones in Section 3.14 of [RFC7296] 🌈

when you prepend the IKE header to the IKE Fragment messages, it MUST be taken intact from the original message, except for the Length and Next Payload fields 🎀 the Length field gets adjusted to match the length of the IKE Fragment message being built, and the Next Payload field is set to the payload type of the first payload in that message (usually that's the Encrypted Fragment payload 👑) after you prepend the IKE header and any payloads that come before the Encrypted payload in the original message (if there are any, see Section 2.5.3 ✨), the resulting messages get sent to the peer 💖

here's an example of fragmenting a message 🌸

   HDR(MID=n), SK(NextPld=PLD1) {PLD1 ... PLDN}

                             Original Message


   HDR(MID=n), SKF(NextPld=PLD1, Frag#=1, TotalFrags=m) {...},
   HDR(MID=n), SKF(NextPld=0, Frag#=2, TotalFrags=m) {...},
   ...
   HDR(MID=n), SKF(NextPld=0, Frag#=m, TotalFrags=m) {...}

                           IKE Fragment Messages

2.5.1. Selecting Fragment Size ✨

when you split the content of an Encrypted payload into chunks, the sender SHOULD choose the size so the resulting IP datagrams end up smaller than some fragmentation threshold 🦋 implementations can work out the threshold from various sources of info 💜

if the sender has info about the PMTU size, it SHOULD use it 🔥 the responder in the exchange may use the maximum size of the received IKE Fragment message IP datagrams as a threshold when it builds a fragmented response 🧚 and successful completion of previous exchanges (including the ones that can't use IKE fragmentation, like IKE_SA_INIT 🙈) might be a sign that the fragmentation threshold can be set to the size of the largest message already sent in those exchanges 🌈

otherwise, for messages going over IPv6, a maximum IP datagram size of 1280 bytes is RECOMMENDED ([RFC2460]) 💖 for messages going over IPv4, a maximum IP datagram size of 576 bytes is RECOMMENDED 🎀 tunnels on the path may reduce these values 🌸 implementations may use other values if they're appropriate for the current environment 🍓

okay so here's the tea ☕ according to [RFC0791], the minimum IPv4 datagram size guaranteed not to be further fragmented is 68 bytes, but it's basically impossible to use a value that small for the solution in this document 💀 576 bytes is a compromise: big enough for the solution, small enough to avoid IP fragmentation in most situations 🫶 several other UDP-based protocols (Syslog, DNS, etc.) use 576 bytes as a safe low limit for IP datagram size too 👑

see Appendix B for the correlation between IP datagram size and Encrypted payload content size 🦋

2.5.2. PMTU Discovery 🦋

okay so the amount of traffic an IKE endpoint sends during an IKE SA's lifetime is honestly pretty modest 💅. It's usually under 100 KB over several hours. Most of it is tiny, usually under a few hundred bytes. The only time endpoints really send messages several KB big is IKE SA establishment, and often each side sends exactly one of those ✨.

For the reasons I already spilled, implementing PMTU discovery in IKE is OPTIONAL 🫶. It's believed that using the values recommended in Section 2.5.1 as a fragmentation threshold will be enough in most cases. Yes, using them could lead to suboptimal fragmentation, but that's acceptable given how little traffic IKE makes, so it's giving "good enough" 🌸. Implementations may support PMTU discovery if there are good reasons to do it (for example, if they're meant for environments where the MTU size might be less than the values listed in Section 2.5.1).

PMTU discovery in IKE follows the recommendations in Section 10.4 of [RFC4821], with some changes caused by the distinctive IKE features listed above. The big difference is that the PMTU search goes downward, while [RFC4821] goes upward 🔥. Why? IKE usually sends large messages only during SA establishment, and often there's just one. If the probing went upward, that message would get fragmented at the smallest allowable threshold. Everything else is usually small enough to avoid IP fragmentation anyway, so continued probing would be pointless 💀.

The initiator is the one who does PMTU discovery 👑. It does this by probing several fragmentation threshold values. Implementations MUST be prepared to probe in every exchange that uses IKE fragmentation, so they can handle changes in path MTU over time. While probing, it MUST start from larger values and refragment the original message using the next smaller threshold if it didn't get a response in a reasonable time after several retransmissions. The exact number of retransmissions and the timeout lengths aren't covered in this spec, because they don't affect interoperability. The timeout is still supposed to be relatively short, so failed probes don't hold up IKE too much. A few retries within several seconds per probe seems appropriate, but different environments may need different rules ⏱️. When starting a new probe, the node MUST reset its retransmission timers, so that if it uses exponential back-off, the timers start over. After reaching the smallest allowed fragmentation threshold, an implementation MUST continue retransmitting until the exchange either completes or times out, using a timeout interval as discussed in Section 2.4 of [RFC7296].

PMTU discovery in IKE is supposed to be coarse-grained 🧚. That means a node will only try a few fragmentation thresholds, so it doesn't waste time on failed probes. If path MTU info isn't available yet, the endpoint may use the link MTU size when it starts probing. In later exchanges, the node should start with the current fragmentation threshold value.

If an implementation can receive ICMP error messages, it can also use the classic PMTU discovery methods from [RFC1191] and [RFC1981] 🌈. Specifically, if the initiator gets a Packet Too Big error in response to a probe, and the value in it is smaller than the current fragmentation threshold, the initiator SHOULD stop retransmitting that probe. It SHOULD also pick a new threshold that is less than or equal to the value from the ICMP message and meets the requirements listed below.

The Total Fragments field is how you tell different sets of fragments apart, meaning the sets made by fragmenting the original message with different thresholds 🍓. The sender starts with larger fragments and makes them smaller, so the Total Fragments value goes up with every new probe. When picking the next smaller threshold, the sender MUST make sure Total Fragments really increased. That shouldn't be a problem, because coarse-grained probing means the gap between thresholds is usually significant anyway. Telling the sets apart is vital for the receiver 🫶. Getting a valid fragment from a newer set means it has to restart reassembly and not mix fragments from different sets.

2.5.3. Fragmenting Messages Containing Unprotected Payloads 🎀

Right now, no IKEv2 exchanges define messages that contain both unprotected payloads and payloads protected by the Encrypted payload. BUT IKEv2 doesn't prohibit that kind of message 👀. So if a future IKEv2 extension defines one and it needs fragmenting, all unprotected payloads MUST go in the first fragment (the one with Fragment Number equal to 1). They go there along with the Encrypted Fragment payload, which MUST be present in every IKE Fragment message and must be the last payload in it.

Here's an example of a message that has both protected and unprotected payloads, before and after fragmenting:

   HDR(MID=n), PLD0, SK(NextPld=PLD1) {PLD1 ... PLDN}

                             Original Message


   HDR(MID=n), PLD0, SKF(NextPld=PLD1, Frag#=1, TotalFrags=m) {...},
   HDR(MID=n), SKF(NextPld=0, Frag#=2, TotalFrags=m) {...},
   ...
   HDR(MID=n), SKF(NextPld=0, Frag#=m, TotalFrags=m) {...}

                           IKE Fragment Messages

Note that the size of each IP datagram carrying IKE Fragment messages should not exceed the fragmentation threshold, including the first one, which holds the unprotected payloads. This shrinks the Encrypted Fragment payload content in the first IKE Fragment message so it has room for all the unprotected payloads 🧩. In an extreme case, the Encrypted Fragment payload will contain no data, but it still must be present in the message. That's because only its presence lets the receiver tell that the sender used IKE fragmentation.

2.6. Receiving IKE Fragment Message 📬

The receiver spots an IKE Fragment message by the presence of an Encrypted Fragment payload. In most cases it's the first and only payload in the message. This might not be true for some hypothetical IKE exchanges (see Section 2.5.3) 🙈.

When an IKE Fragment message comes in, these actions happen:

  • Check message validity. Basically, check whether the values in the Fragment Number and Total Fragments fields of the Encrypted Fragment payload are valid. These tests need to be performed:
    • check that Fragment Number and Total Fragments contain non-zero values
    • check that the value in Fragment Number is less than or equal to the value in Total Fragments
    • if reassembling has already started, check that the value in Total Fragments is equal to or greater than the Total Fragments value in the fragments already stored in the reassembling queue

If any of these tests fail, the message MUST be silently discarded.

  • Check that this IKE Fragment message is new for the receiver and not a replay. If an IKE Fragment message with the same Message ID, Fragment Number, and Total Fragments is already in the reassembling queue, this message counts as a replay and MUST be silently discarded 🚫.
  • Verify the IKE Fragment message's authenticity by checking the Integrity Check Value (ICV) in the Encrypted Fragment payload. If the ICV check fails, the message MUST be silently discarded.
  • If reassembling isn't finished yet, and the Total Fragments value in the received fragment is greater than the Total Fragments value in the fragments in the reassembling queue, the receiver MUST discard all received fragments. Then it starts the reassembly process over with just the received IKE Fragment message 🔄.
  • Store the message in the reassembling queue while waiting for the rest of the fragments to show up.

Once all IKE Fragment messages have arrived (as indicated by Total Fragments), the decrypted content of all the Encrypted Fragment payloads gets merged together. That rebuilds the content of the original Encrypted payload, and therefore, along with the IKE header and unprotected payloads (if any), the original message ✨. Then it's processed as if it had been received, verified, and decrypted as a regular IKE message.

If the receiver doesn't get every IKE fragment it needs to reassemble the original message within a timeout interval, it MUST discard all IKE Fragment messages it has received so far for that exchange. What happens next depends on the receiver's role in the exchange ⏳.

  • The initiator acts as described in Section 2.1 of [RFC7296]. It either retransmits the fragmented request message, or it deems the IKE SA to have failed and deletes it. The number of retransmits and the timeout lengths for the initiator aren't covered in this spec, since they're assumed to be the same as in a regular IKEv2 exchange and are discussed in Section 2.4 of [RFC7296].
  • The responder, in this case, acts as if no request message was received 🙃. It deletes any memory of the incomplete request message and doesn't treat it as an IKE SA failure. It is RECOMMENDED that the reassembling timeout for the responder be equal to the time interval the implementation waits before completely giving up when it's acting as the initiator of an exchange. Section 2.4 of [RFC7296] gives recommendations for choosing that interval. Implementations can use a shorter timeout to conserve memory 🧠.

2.6.1. Replay Detection and Retransmissions 🔁

According to Section 2.2 of [RFC7296], the Message ID is used, in particular, to identify retransmissions of IKE messages. Each request or response message, sent by either side, must have a unique Message ID, or else it gets treated as a retransmission. [RFC6311] has already updated this logic, deliberately allowing any number of messages with a zero Message ID. This document also updates the logic for situations where IKE fragmentation is in use 🌸.

If an incoming message contains an Encrypted Fragment payload, the values of Fragment Number and Total Fragments MUST be used along with the Message ID to detect retransmissions and replays 🕵️‍♀️.

If the responder receives a retransmitted fragment of a request after it has already processed that request and sent back a response, that event MUST only trigger a retransmission of the response message (fragmented or not) if Fragment Number in the received fragment is set to 1. Otherwise, it MUST be ignored 💅.

3. Interaction with Other IKE Extensions ✨

Okay so IKE fragmentation vibes with most IKE extensions 💖, like IKE Session Resumption ([RFC5723]), the Quick Crash Detection Method ([RFC6290]), and so on. It doesn't change how they work, and they don't change how it works 🫶. It's believed that IKE fragmentation will also play nicely with future IKE extensions, as long as those follow the general principles of formatting, sending, and receiving IKE messages described in [RFC7296] 🌸.

Bestie, here's the tea 🍵. When IKE fragmentation is used with IKE Session Resumption ([RFC5723]), messages in an IKE_SESSION_RESUME exchange cannot be fragmented, because they don't contain an Encrypted payload 💀. Those messages can end up pretty big because of the ticket size. To avoid IP fragmentation in this situation, it is recommended that smaller tickets be used, e.g., by using a "ticket by reference" approach instead of "ticket by value" 🎀.

Protocol Support for High Availability of IKEv2/IPsec, described in [RFC6311], needs special care when you're deciding whether to fragment an IKE message 🙈. It deliberately lets any number of synchronization exchanges use the same Message ID, namely zero, so the usual IKEv2 replay detection (which is based on checking the Message ID) doesn't apply to those messages. The receiver has to check the message content to detect replays instead 😭. So when you implement IKE fragmentation along with [RFC6311], IKE Message ID Synchronization messages MUST NOT be sent fragmented, to keep the receiver's replay-detection job simple. Fortunately, these messages are small, so there's no point fragmenting them anyway 🦋.

4. Transport Considerations 🚚

With IKE fragmentation, if even one IKE Fragment message gets lost, the receiver becomes unable to reassemble the original message 😬. So, in general, using IKE fragmentation means a higher chance that the message won't reach the peer. In most network environments the difference is insignificant, but on some lossy networks it can become noticeable 📉. When using IKE fragmentation, implementations MAY use longer timeouts and do more retransmits than usual before they consider the peer dead 🧚.

Also, Fragment messages are not individually acknowledged 👀. The response Fragment messages are all sent back together only once every fragment of the request has been received, and the original request message has been reassembled and successfully processed ✨.

5. Security Considerations 💀

Most of the security considerations for IKE fragmentation are the same as the ones for the base IKEv2 protocol described in [RFC7296] 💅. This extension introduces the Encrypted Fragment payload to protect the content of an IKE Message Fragment. That means the receiver can check the authenticity of each fragment on its own, which protects peers from DoS attacks 🛡️.

The Security Considerations section of [RFC7296] mentions a possible attack on IKE where an attacker could stop an exchange from completing by exhausting the IP reassembly buffers 😱. The mechanism described in this document lets IKE avoid IP fragmentation, so it's more robust against DoS attacks 💪.

Now the spicy part 🌶️. The following attack is possible with IKE fragmentation. An attacker can start an IKE_SA_INIT exchange, complete it, compute SK_a and SK_e, and then send a large but still incomplete set of IKE_AUTH fragments. These fragments will pass the ICV check and get stored in reassembly buffers. But since the set is incomplete, reassembly will never succeed and will eventually time out. If the set is large, this attack could potentially exhaust the receiver's memory resources 🥀.

⚠️ Warning, bestie: this one is serious. An incomplete set of fragments can quietly eat up memory until the receiver runs out.

To mitigate the impact of this attack, it is RECOMMENDED that the receiver limit the number of fragments it stores in the reassembling queue, so that the sum of the sizes of Encrypted Fragment payload contents (after decryption) for fragments already placed into the reassembling queue is less than some value that is reasonable for the implementation 🧠. If the peer sends so many fragments that the above condition isn't met, the receiver can consider this situation to be either an attack or a broken sender implementation 🤷‍♀️. Either way, the receiver SHOULD drop the connection and discard all the received fragments 🚫.

This value can be predefined, can be a configurable option, or can be calculated dynamically, depending on the receiver's memory load 🍓. Some care should be taken when choosing it, because if it's too small it might stop a legitimate peer from establishing an IKE SA, if the messages it sends are bigger than this value 😩. It is NOT RECOMMENDED for this value to exceed 64 KB, because any IKE message before fragmentation would likely be shorter than that 📏.

If IKE fragments arrive in order, it is possible, but not advised, for the receiver to parse the beginning of the message being reassembled and extract the payloads that are already available, before reassembly is complete 🙅‍♀️. It can be dangerous to act on the content of those payloads, because fragments not yet received might contain payloads that change their meaning (or even make the whole message invalid), and an attacker could exploit that 😈. It's important to address this threat by making sure all the fragments are received before the reassembled message is parsed, as described in Section 2.6 🔒.

6. IANA Considerations 📋

This document defines a new payload in the "IKEv2 Payload Types" registry:

  53       Encrypted and Authenticated Fragment      SKF

This document also defines a new Notify Message Type in the "IKEv2 Notify Message Types - Status Types" registry:

  16430       IKEV2_FRAGMENTATION_SUPPORTED

7. References 📚

7.1. Normative References

[RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
           Requirement Levels", BCP 14, RFC 2119, March 1997,
           <http://www.rfc-editor.org/info/rfc2119>.

[RFC7296]  Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T.
           Kivinen, "Internet Key Exchange Protocol Version 2
           (IKEv2)", STD 79, RFC 7296, October 2014,
           <http://www.rfc-editor.org/info/rfc7296>.

[RFC6311]  Singh, R., Kalyani, G., Nir, Y., Sheffer, Y., and D.
           Zhang, "Protocol Support for High Availability of IKEv2/
           IPsec", RFC 6311, July 2011,
           <http://www.rfc-editor.org/info/rfc6311>.

7.2. Informative References

[RFC0791]  Postel, J., "Internet Protocol", STD 5, RFC 791,
           September 1981, <http://www.rfc-editor.org/info/rfc791>.

[RFC1191]  Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191,
           November 1990, <http://www.rfc-editor.org/info/rfc1191>.

[RFC1981]  McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery
           for IP version 6", RFC 1981, August 1996,
           <http://www.rfc-editor.org/info/rfc1981>.

[RFC2460]  Deering, S. and R. Hinden, "Internet Protocol, Version 6
           (IPv6) Specification", RFC 2460, December 1998,
           <http://www.rfc-editor.org/info/rfc2460>.

[RFC4787]  Audet, F. and C. Jennings, "Network Address Translation
           (NAT) Behavioral Requirements for Unicast UDP", BCP 127,
           RFC 4787, January 2007,
           <http://www.rfc-editor.org/info/rfc4787>.

[RFC4821]  Mathis, M. and J. Heffner, "Packetization Layer Path MTU
           Discovery", RFC 4821, March 2007,
           <http://www.rfc-editor.org/info/rfc4821>.

[RFC5282]  Black, D. and D. McGrew, "Using Authenticated Encryption
           Algorithms with the Encrypted Payload of the Internet Key
           Exchange version 2 (IKEv2) Protocol", RFC 5282,
           August 2008, <http://www.rfc-editor.org/info/rfc5282>.

[RFC5405]  Eggert, L. and G. Fairhurst, "Unicast UDP Usage Guidelines
           for Application Designers", BCP 145, RFC 5405,
           November 2008, <http://www.rfc-editor.org/info/rfc5405>.

[RFC5723]  Sheffer, Y. and H. Tschofenig, "Internet Key Exchange
           Protocol Version 2 (IKEv2) Session Resumption", RFC 5723,
           January 2010, <http://www.rfc-editor.org/info/rfc5723>.

[RFC6290]  Nir, Y., Wierbowski, D., Detienne, F., and P. Sethi, "A
           Quick Crash Detection Method for the Internet Key Exchange
           Protocol (IKE)", RFC 6290, June 2011,
           <http://www.rfc-editor.org/info/rfc6290>.

[RFC6888]  Perreault, S., Yamagata, I., Miyakawa, S., Nakagawa, A.,
           and H. Ashida, "Common Requirements for Carrier-Grade NATs
           (CGNs)", BCP 127, RFC 6888, April 2013,
           <http://www.rfc-editor.org/info/rfc6888>.

[FRAGDROP] Jaeggli, J., Colitti, L., Kumari, W., Vyncke, E., Kaeo,
           M., and T. Taylor, "Why Operators Filter Fragments and
           What It Implies", Work in Progress, draft-taylor-v6ops-
           fragdrop-02, December 2013.

[BLACKHOLES]
           De Boer, M. and J. Bosma, "Discovering Path MTU black
           holes on the Internet using RIPE Atlas", July 2012,
           <http://www.nlnetlabs.nl/downloads/publications/
           pmtu-black-holes-msc-thesis.pdf>.

[DOSUDPPROT]
           Kaufman, C., Perlman, R., and B. Sommerfeld, "DoS
           protection for UDP-based protocols", ACM Conference on
           Computer and Communications Security, October 2003.

Appendix A. Design Rationale 🎀

Okay, so the simplest way to do IKE fragmentation would have been to fragment a message that's fully formed and ready to go 📦. But if a message got fragmented after being encrypted and authenticated, that could make a simple DoS attack possible 😤. The attacker could now and then send forged but valid-looking fragments into the network, and some of those fragments would get pulled into the receiver's reassembling queue. The receiver couldn't tell forged fragments from real ones, and it would only find out some of them were fake after the whole message was reassembled and its authenticity check failed 💀.

To stop this kind of attack, and to reduce exposure to some other DoS attacks too, the decision was made to fragment before applying cryptographic protection to the message 🔐. That way, each Fragment message gets individually encrypted and authenticated. This lets the receiver spot forged fragments and keep them out of the reassembling queue 👑✨.

Appendix B. Correlation between IP Datagram Size and Encrypted Payload Content Size 🧚

okay bestie, this last bit is about how the actual encrypted stuff compares to the whole IP datagram it rides in. spoiler: the datagram is always bigger, and the gap is a whole calculation 💅

For IPv4, the content size of the Encrypted Payload is less than the IP datagram size by the sum of these:

  • IPv4 header size (typically 20 bytes, up to 60 if IP options are present) 🌸
  • UDP header size (8 bytes)
  • non-ESP (Encapsulating Security Payload) marker size (4 bytes if present)
  • IKE header size (28 bytes)
  • Encrypted payload header size (4 bytes)
  • initialization vector (IV) size (variable)
  • padding and its size (at least 1 byte)
  • ICV size (variable)

The sum may be estimated as 61..105 bytes + IV + ICV + padding. Math is giving a range, lowkey iconic 🎀

For IPv6, the content size of the Encrypted Payload is less than the IP datagram size by the sum of these:

  • IPv6 header size (40 bytes)
  • IPv6 extension headers (optional; size varies)
  • UDP header size (8 bytes)
  • non-ESP marker size (4 bytes if present)
  • IKE header size (28 bytes)
  • Encrypted payload header size (4 bytes)
  • IV size (variable)
  • padding and its size (at least 1 byte)
  • ICV size (variable)

If no extension header is present, the sum may be estimated as 81..85 bytes + IV + ICV + padding. If extension headers are present, the payload content size gets reduced even further, by the sum of the size of the extension headers 🦋 The length of each extension header can be calculated as 8 * (Hdr Ext Len) bytes, except for the fragment header, which is always 8 bytes in length. The fragment header is the one exception, always 8 bytes, no notes 💜

Acknowledgements ✨

The author wants to thank Tero Kivinen, Yoav Nir, Paul Wouters, Yaron Sheffer, Joe Touch, Derek Atkins, Ole Troan, and others for their reviews and valuable comments. The whole crew showed up for this one 🫶

Thanks to Ron Bonica for contributing text to the Introduction section. Thanks to Paul Hoffman and Barry Leiba for improving text clarity. Honestly the people who make the text readable are the real MVPs 👑🌈

Author's Address 💌

Valery Smyslov
ELVIS-PLUS
PO Box 81
Moscow (Zelenograd)  124460
Russian Federation

Phone: +7 495 276 0211
EMail: svan@elvis.ru
📦 where this page comes from