RFC 7739

Security Implications of Predictable Fragment Identification Values

📅 published February 2016, from ietf

RFC 7739 📜 Security Implications of Predictable Fragment Identification Values 🦋

  • Authors: F. Gont, Huawei Technologies 💖
  • Series: IETF, Request for Comments: 7739 🌸
  • Category: Informational ✨
  • Date: February 2016 🎀
  • ISSN: 2070-1721
  • Obsoletes / Updates: The title block doesn't list anything this one obsoletes or updates 🧚

Abstract ✨

okay so IPv6 has this thing called the Fragment Header 🎀, and it's used for fragmentation and reassembly. Inside it is an "Identification" field that, together with the IPv6 Source Address and Destination Address of a packet, tells the receiving host which fragments belong to the same original datagram so they can be stitched back together 🧩. The only requirement for setting that field is that its value must be different from the one used for any other fragmented datagram sent recently with the same Source and Destination Addresses. Some implementations just use a simple global counter, which makes the values predictable 👀. This document looks at the security implications of predictable Identification values and gives implementation guidance for setting the field so those implications get mitigated 💅.

Status of This Memo 🌈

This document is not an Internet Standards Track specification. It's published for informational purposes only 📖.

It's a product of the Internet Engineering Task Force (IETF) and represents the consensus of the IETF community 🫶. It has had public review and was approved for publication by the Internet Engineering Steering Group (IESG). Not every IESG-approved document is a candidate for any level of Internet Standard, so check out Section 2 of RFC 5741 if you want the details 🤓.

For info on the current status of this document, any errata, and how to send feedback, head to http://www.rfc-editor.org/info/rfc7739 🔗.

Copyright (c) 2016 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) as in effect on the date of publication. Please read these carefully, because they spell out your rights and restrictions for 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 they come without warranty as described in the Simplified BSD License 🍓.

Table of Contents 🗺️

1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
3.  Security Implications of Predictable Fragment Identification
    Values  . . . . . . . . . . . . . . . . . . . . . . . . . . .   3
4.  Constraints for the Selection of Fragment Identification
    Values  . . . . . . . . . . . . . . . . . . . . . . . . . . .   7
5.  Algorithms for Selecting Fragment Identification Values . . .   8
  5.1.  Per-Destination Counter (Initialized to a Random Value) .   8
  5.2.  Randomized Identification Values  . . . . . . . . . . . .   9
  5.3.  Hash-Based Fragment Identification Selection Algorithm  .  10
6.  Security Considerations . . . . . . . . . . . . . . . . . . .  12
7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  13
  7.1.  Normative References  . . . . . . . . . . . . . . . . . .  13
  7.2.  Informative References  . . . . . . . . . . . . . . . . .  14
Appendix A.  Information Leakage Produced by Vulnerable
             Implementations  . . . . . . . . . . . . . . . . . .  16
Appendix B.  Survey of Fragment Identification Selection
             Algorithms Employed by Popular IPv6 Implementations   18
Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .  20
Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  20

1. Introduction 🌷

okay bestie, so IPv6 specifies the Fragment Header, which handles fragmentation and reassembly 🧩. That header has an "Identification" field that, combined with the IPv6 Source Address and Destination Address of a packet, marks which fragments come from the same original datagram, so the receiving host can reassemble them together 🎀. The only requirement for setting the Identification field is that its value must be different from the value used for any other fragmented datagram sent recently with the same Source Address and Destination Address ✨.

The most basic approach to avoid reusing Identification values too fast is to keep a global counter that goes up by one for every fragmented datagram you send 🔢. But this trivial approach creates predictable Identification values, and attackers can totally exploit that to pull off all kinds of attacks 😭💀.

Section 3 of this document analyzes the security implications of predictable Identification values 🕵️. Section 4 talks about the constraints on the possible algorithms for selecting Identification values 📏. Section 5 specifies a bunch of algorithms that could be used to generate Identification values that deal with the issues covered here 🛠️. And finally, Appendix B is a survey of the algorithms popular IPv6 implementations use to generate Identification values 👑.

2. Terminology 🧚

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 RFC 2119 [RFC2119] 💅.

3. Security Implications of Predictable Fragment Identification Values 🔐

okay bestie, this section is where we talk about why predictable Identification values are a whole problem 😭 they leak info, and attackers can use that info in a bunch of sneaky ways 🕵️‍♀️ they may potentially be exploited to:

  • determine the packet rate at which a given system is transmitting information
  • perform stealth port scans to a third party
  • uncover the rules of a number of firewalls
  • count the number of systems behind a middle-box
  • perform Denial-of-Service (DoS) attacks, or
  • perform data injection attacks against transport or application protocols

the security implications in IPv6 are very similar to the ones in IPv4 🫶 same vibe, same drama

NOTE: [Sanfilippo1998a] originally pointed out how the IPv4 Identification field could be examined to determine the packet rate at which a given system is transmitting information. Later, [Sanfilippo1998b] described how a system with such an implementation could be used to perform a stealth port scan to a third (victim) host. [Sanfilippo1999] explained how to exploit this implementation strategy to uncover the rules of a number of firewalls. [Bellovin2002] explained how the IPv4 Identification field could be exploited to count the number of systems behind a NAT. [Fyodor2004] is an entire paper on most (if not all) the ways to exploit the information provided by the Identification field of the IPv4 header (and these results apply in a similar way to IPv6). [Zalewski2003] originally envisioned the exploitation of IP fragmentation/reassembly for performing data injection attacks against upper-layer protocols. [Herzberg2013] explores the use of IPv4/IPv6 fragmentation and predictable Identification values for performing DNS cache poisoning attacks in great detail. [RFC6274] covers the security implications of the IPv4 case in detail.

okay the NOTE is a whole reading list 📚💅 the research on this goes back a long way, and the IPv4 side has been picked apart in detail.

One key difference between IPv4 and IPv6 is that in IPv4, the Identification field is part of the fixed IPv4 header (so it's usually set for every packet 📦), while in IPv6 the Identification field only shows up in packets that carry a Fragment Header 🧩 so exploiting it depends on two things:

  • vulnerable Identification generators, and
  • the ability of an attacker to trigger the use of IPv6 fragmentation for packets sent from/to the victim node

whether an attacker can pull this off depends on the attack type 🎯 for example, to DoS the communication between two hosts, the attacker would need to know the IPv6 addresses of those two nodes. that info can be super easy to get if the target is the link between two specific BGP peers, two specific SMTP servers, or one primary DNS server and one of its secondary DNS servers 🍓 but it's way harder if the goal is to DoS all communications between arbitrary IPv6 hosts (like, all traffic involving one specific node with arbitrary or unknown hosts) 😵‍💫 other attacks, like stealth port scans to a third party or figuring out the packet rate of a system, only need the attacker to know the IPv6 address of a vulnerable implementation ✨

As noted in Section 1, some implementations have been known to use predictable Identification values 👀 for instance, Appendix B of this document shows that recent versions of a number of popular IPv6 implementations use predictable values for the Identification field of the Fragment Header. bestie this is the receipts section 💅

Now for the ICMPv6 part, which is kind of a plot twist 🌀 we note that [RFC2460] says that when an ICMPv6 Packet Too Big (PTB) error message advertising a Maximum Transfer Unit (MTU) smaller than 1280 bytes is received, the receiving host is not required to reduce the Path-MTU for the corresponding Destination Address, but must simply include a Fragment Header in all subsequent packets sent to that destination. that triggers the so-called IPv6 "atomic fragments" [RFC6946]: IPv6 fragments with a Fragment Offset equal to 0, and the "M" ("More fragments") bit clear. [DEPGEN] documents the motivation for deprecating the generation of IPv6 atomic fragments in [RFC2460].

so basically, an attacker can usually make a victim host "fragment" its outgoing packets just by sending it a forged ICMPv6 Packet Too Big (PTB) error message that advertises an MTU smaller than 1280 bytes 😳 not it.

there are a few things to keep in mind though 🧐

  • all the implementations the author is aware of record the Path-MTU information on a per-destination basis. so an attacker can only make the victim turn on fragmentation for packets sent to the Source Address of the IPv6 packet embedded in the payload of the ICMPv6 PTB message. however, we note that Section 5.2 of [RFC1981] notes that an implementation could maintain a single system-wide Path MTU (PMTU) value to be used for all packets sent to that node. clearly, those implementations would make the problem worse for any attacks based on Path MTU Discovery (PMTUD) [RFC5927] or IPv6 fragmentation.
  • if the victim node implements some of the counter-measures for ICMP attacks described in RFC 5927 [RFC5927], it might be hard for an attacker to make the victim use fragmentation for its outgoing packets. however, many current implementations fail to enforce these validation checks. for example, Linux 2.6.38-8 does not even require received ICMPv6 error messages to correspond to an ongoing communication instance.
  • some implementations (notably Linux) have already been updated according to [DEPGEN] so that ICMPv6 PTB messages do not result in the generation of IPv6 atomic fragments ✅

implementations that use predictable Identification values AND fail to enforce validation checks on ICMPv6 error messages become vulnerable to the same kinds of attacks that can be exploited with IPv4 fragmentation, which we covered earlier in this section 🔁

here's one possible way predictable Identification values could be used for a DoS attack 🎬 let's say Host A is talking to Host B, and an attacker wants to DoS that communication. the attacker would learn the Identification value Host A is currently using, possibly by sending any packet that would make Host A send back a fragmented response (for example, an ICPMv6 echo request with a large payload). the attacker would then send a forged ICMPv6 PTB error message to Host A (with the IPv6 Source Address of the embedded IPv6 packet set to Host A's IPv6 address, and the Destination Address of the embedded IPv6 packet set to Host B's IPv6 address), so that any later packets Host A sends to Host B include a Fragment Header. finally, the attacker would send forged IPv6 fragments to Host B, with their IPv6 Source Address set to Host A's, and Identification values that collide with the ones used for the legitimate traffic from Host A to Host B. if Host B throws away fragments that have colliding Identification values (for example, such fragments overlap, and the host implements [RFC5722]), the attacker could just trash the Identification space by sending lots of forged fragments with different Identification values. then any later packets from Host A to Host B get discarded at Host B because of those malicious fragments 💀

NOTE: For example, Linux 2.6.38-10 is vulnerable to the aforementioned issue. [RFC6946] describes an improved processing of these packets that would eliminate this specific attack vector, at least in the case of TCP connections that employ the Path-MTU Discovery mechanism.

the attack scenario above is just there to show the problem with predictable Identification values 🧁 no matter whether an attacker can make a victim fragment its traffic with third parties, using predictable Identification values makes any communication flow that uses fragmentation vulnerable to any fragmentation-based attack. period 💜

4. Constraints for the Selection of Fragment Identification Values 🧮

the Identification field of the Fragment Header is 32 bits long 🔢 BUT when translators (for example, [RFC6145]) are in use, the high-order 16 bits of the Identification field are effectively ignored. plot twist, again 🙃

NOTE: [RFC6145] notes that, when translating in the IPv6-to-IPv4 direction, "if there is a Fragment Header in the IPv6 packet, the last 16 bits of its value MUST be used for the IPv4 identification value". Additionally, Section 3.3 of [RFC6052] encourages operators to use a Network-Specific Prefix (NSP) that maps the IPv4 address space into IPv6. so when an NSP is being used, IPv6 addresses representing IPv4 nodes (reached through a stateless translator) look exactly the same as native IPv6 addresses 🫠

so when translators are involved, the "effective" length of the Identification field is 16 bits 🎀 and at least during the IPv6/IPv4 transition/co-existence phase, it's probably safer to assume that only the low-order 16 bits of the Identification field are useful to the destination system.

now, about picking Identification values: the only requirement [RFC2460] puts on that is that the Identification value must be different from the value used for any other fragmented packet sent recently with the same Source Address and Destination Address ✨ if you don't follow that, you could run into the interoperability problems discussed in [RFC4963].

from a security standpoint, unpredictable Identification values are the move 🔐 but that's kinda at odds with the "reuse" requirements in [RFC2460], which say that an Identification value must be different from the one used for any other fragmented packet sent recently with the same Source Address and Destination Address. so the security goal and the reuse rule are kind of pulling in opposite directions 😩

last but not least, Identification values need to be picked for every outgoing datagram that needs fragmentation, so the performance impact should be considered when you choose an algorithm for selecting them 🏎️💨

5. Algorithms for Selecting Fragment Identification Values ✨

Okay so, there are a bunch of ways to pick the Identification field so the security issues from this doc don't happen 💅 This section walks through three of them, and they each have their own vibe 🦋

Section 5.1 usually gives a low Identification reuse frequency, but it costs you per-destination state 🧚 It only uses a Pseudorandom Number Generator (PNRG) when the host talks to a new destination. Section 5.2 can end up with a higher Identification reuse frequency, and it uses a PRNG for every datagram that needs fragmenting. So Section 5.1 will likely perform better 📈 Then there's Section 5.3, which gets a similar reuse frequency to Section 5.1 without keeping any state, but its per-packet performance might be worse 🥲

NOTE: Since the specific algorithm for the PRNGs in Section 5.1 and Section 5.2, and the specific algorithms for the hash functions in Section 5.3, haven't been specified, it's impossible to give a quantitative performance comparison of the algorithms in this section 🤷‍♀️

5.1. Per-Destination Counter (Initialized to a Random Value) 🎀

Here's how this one goes, step by step:

  1. Whenever a packet must be sent with a Fragment Header, the sending host should look up the Destination Cache entry that matches the packet's Destination Address 👀
  2. If that entry exists, it holds the last Identification value used for that Destination Address. So you increment that value by 1 and use it for the Identification field of the outgoing packet. The updated value also gets saved in the matching Destination Cache entry [RFC4861] 💕
  3. If the entry doesn't exist, it should be created, and its Identification value should be initialized with a random value (for example, from a Pseudorandom Number Generator). That value is then used for the Identification field of the Fragment Header on the outgoing fragmented datagram 🌸

The advantages are honestly so good:

  • It's simple to implement. The only real complexity is the PRNG that initializes the Identification value in each Destination Cache entry 🧠
  • The Identification reuse frequency is usually lower than what a global counter gets when you're sending traffic to multiple destinations, because this algorithm uses per-destination counters instead of one system-wide counter 🙌
  • It performs well. Once the Destination Cache entry has been created and initialized, every later Identification value is just a counter increment ⚡

The drawbacks, tho 😬

  • If resource management forces an entry out of the Destination Cache, the last Identification value used for that Destination is lost. Later traffic to that destination recreates the entry and reinitializes it to a random value, which could lead to Identification "collisions" 💀
  • The Identification values are predictable by the destination host, so a vulnerable host might leak the Identification values that other hosts use to send traffic to it to third parties. For example, Host B could leak to Host C the Identification values that Host A is using to send packets to Host B. Appendix A describes one possible scenario for this leakage in detail 🙈

5.2. Randomized Identification Values 🦋

Honestly, using a Pseudorandom Number Generator to pick the Identification would be ideal from a security standpoint 🔐 With this scheme, the Identification of each fragmented datagram would be selected like this:

Identification = random()

where "random()" is the PRNG.

How this scheme behaves really depends on the PRNG you pick. For example, some PRNGs can give higher Identification reuse frequencies than others, and some PRNGs are more expensive (in terms of processing requirements and/or implementation complexity) than others 🧐

Talking about the properties of possible PRNGs is out of scope for this document. Still, it's worth noting that some PRNGs used in the past by some implementations have been found to be predictable [Klein2007]. For randomness requirements for security, please see [RFC4086] 🔍

5.3. Hash-Based Fragment Identification Selection Algorithm 🧚‍♀️

Another option is a hash-based algorithm, kind of like the one specified in [RFC6056] for picking transport port numbers 💜 With this scheme, the Identification value of each fragmented datagram would be selected with this expression:

Identification = F(Src IP, Dst IP, secret1)  +
                 counter[G(Src IP, Dst Pref, secret2)]

Here's what each piece means:

  • Identification: the Identification value to be used for the fragmented datagram 🎀
  • F(): a hash function 🔮
  • Src IP: the IPv6 Source Address of the datagram to be fragmented 📮
  • Dst IP: the IPv6 Destination Address of the datagram to be fragmented 📬
  • secret1: secret data unknown to the attacker. It can be initialized to a pseudo-random value during the system bootstrapping sequence. It should stay constant at least for as long as previously sent fragments could still be in the network or in the fragment reassembly buffer of the corresponding destination system(s) 🤫
  • counter[]: a system-wide array of 32-bit counters (for example, with 8K elements or more). Each counter should be initialized to a pseudo-random value during the system bootstrapping sequence 🔢
  • G(): a hash function. It may or may not be the same hash function as the one used for F() 🔮
  • Dst Pref: the IPv6 "Destination Prefix" of the datagram to be fragmented. It can be assumed to be the first eight bytes of the Destination Address of such packet. Note: the "Destination Prefix" (rather than the Destination Address) is used, so an attacker's ability to search the "increments" space by using multiple addresses from the same subnet is reduced 🕵️‍♀️
  • secret2: secret data unknown to the attacker. It can be initialized to a pseudo-random value during the system bootstrapping sequence. It should stay constant at least for as long as previously sent fragments could still be in the network or in the fragment reassembly buffer of the corresponding destination system(s) 🤫
NOTE: counter[G(src IP, Dst Pref, secret2)] should be incremented by one each time an Identification value is selected ➕

The output of F() is constant for each (Src IP, Dst IP) pair, and the output of G() is constant for each (Src IP, Dst Pref) pair. So the resulting Identification value is a random offset plus a linear function (provided by counter[]), which gives a monotonically increasing sequence of Identification values for each (src IP, Dst IP) pair 📈

NOTE: F() basically provides the unpredictability (against off-path attackers) of the resulting Identification values. Meanwhile, counter[] provides a linear function, so the Identification values differ for each fragmented packet while the Identification reuse frequency stays minimized 🦋

The advantages are:

  • The Identification reuse frequency is usually lower than what a global counter gets when you're sending traffic to multiple destinations, because this algorithm uses multiple system-wide counters instead of one. How much lower depends on the number of elements in counter[], and on how many other active flows produce the same value of G() (and therefore cause the same counter to be incremented for each fragmented datagram) 🙌
  • You can implement it so it performs well. For example, the result of F() could be stored in the Destination Cache (so it doesn't need to be recomputed for every packet that must be sent), along with the computed index/argument for counter[] 💨
NOTE: If you go with this implementation approach and a Destination Cache entry has to be removed because of resource management, the last Identification value used for that Destination will not be lost. This is an improvement over the algorithm in Section 5.1 🎉

The drawbacks are:

  • The Identification values are predictable by the destination host, so a vulnerable host could possibly leak to third parties the Identification values that other hosts use to send traffic to it. For example, Host B could leak to Host C the Identification values that Host A is using to send packets to Host B. Appendix A describes a possible scenario where this information leakage could happen. That said, this algorithm makes the attack less reliable for the attacker, since each counter could be shared by multiple traffic flows (packets destined to other destinations might cause the same counter to be incremented) 🫣

This algorithm might be preferable (over the one in Section 5.1) in scenarios where a node is expected to communicate with a large number of destinations, and it's desirable to limit how much information has to be kept in memory 🧠

NOTE: In those scenarios, if the algorithm in Section 5.1 were implemented, Destination Cache entries might need to be pruned frequently, which increases the risk of Identification "collisions" 😭

6. Security Considerations 🔒

This document talks about the security implications of predictable Identification values, and it gives implementation guidance so those implications can be mitigated. Please take this part seriously, bestie 😤

A number of possible algorithms are described here, so implementers have some alternatives to choose from. We note that picking an algorithm usually comes with a bunch of trade-offs (security, performance, implementation complexity, interoperability properties, and so on) ⚖️

7. References 📚

7.1. Normative References

Okay, these are the docs the spec leans on the hardest, so they're the foundation of the whole thing 📚✨

7.2. Informative References

These ones are the extra reading: the research, the attack write-ups, and the tools people have poked at over the years 🔍🦋

Appendix A. Information Leakage Produced by Vulnerable Implementations 🕵️🌸

Okay, so Section 3 gives a bunch of references describing the different ways a vulnerable implementation can spill the Identification values it's about to use in later packets, and that opens the door to a whole lot of attacks 😬. In every one of those scenarios, the vulnerable implementation leaks/reveals its own Identification number.

This section is about a different (and kinda sneaky) scenario 🫣. Here, a vulnerable implementation leaks/reveals the Identification number of a non-vulnerable implementation. Basically, a vulnerable implementation (Host A) leaks the current Identification value in use by a third-party host (Host B) to send fragmented datagrams from Host B to Host A.

NOTE: For the most part, this section is included to illustrate how a vulnerable implementation might be leveraged to leak out the Identification value of an otherwise non-vulnerable implementation.

The following scenarios assume:

  • Host A: An IPv6 host that implements the algorithm specified in Section 5.1, implements [RFC5722], but does not implement [RFC6946].
  • Host B: Victim node. Selects the Identification values from a global counter.
  • Host C: Attacker. Can forge the IPv6 Source Address of his packets at will.

In the following scenarios, large ICMPv6 Echo Request packets are employed to "sample" the Identification value of a host. While the figures only show one packet for the ICMPv6 Echo Request and the ICMPv6 Echo Reply packets, each of those packets will typically comprise two fragments, so the corresponding unfragmented datagram is larger than the MTU of the networks to which Host B and Host C are attached. ✨

Also, the following scenarios assume that Host A employs a Fragment Header when sending traffic to Host B (typically the so-called "IPv6 atomic fragments" [RFC6946]). This behavior may be triggered by forged ICMPv6 PTB messages that advertise an MTU smaller than 1280 bytes (assuming the victim still generates atomic fragments [DEPGEN]). 💅

In lines #1-#2 (and lines #7-#8), the attacker samples the current Identification value at Host B. In line #3, the attacker sends a forged TCP SYN segment to Host A. In line 4, the attacker sends a forged TCP segment to Host B as an incomplete IPv6 fragmented datagram (e.g., a single fragment with Fragment Offset=0, More fragments=1). If the corresponding TCP port is closed, and the attacker fails when trying to produce a collision of Identification values (see line #4), the following packet exchange might take place:

    A                          B                              C

#1                              <------ Echo Req #1 -----------
#2                              --- Echo Repl #1, FID=5000 --->
#3  <------------------- SYN #1, src= B -----------------------
#4                              <--- SYN/ACK, FID=42 src=A ----
#5  ---- SYN/ACK, FID=9000 --->
#6  <----- RST, FID= 5001 -----
#7                              <-------- Echo Req #2 ---------
#8                              --- Echo Repl #2, FID=5002 --->

The RST segment in line #6 is elicited by the SYN/ACK segment from line #5 (illegitimately elicited by the SYN segment from line #3). The packet from line #4, sent as an incomplete IPv6 datagram, eventually times out. 🥲

On the other hand, if the attacker succeeds in producing a collision of Identification values, the following packet exchange could take place: 😳

    A                          B                              C

#1                              <------- Echo Req #1 ----------
#2                              --- Echo Repl #1, FID=5000 --->
#3  <------------------- SYN #1, src= B -----------------------
#4                              <-- SYN/ACK, FID=9000 src=A ---
#5  ---- SYN/ACK, FID=9000 --->
                        ... (RFC5722) ...
#6                              <------- Echo Req #2 ----------
#7                              ---- Echo Repl #2, FID=5001 -->

Clearly, the Identification value sampled from the second ICMPv6 Echo Reply packet ("Echo Repl #2") implicitly indicates whether the Identification value in the forged SYN/ACK (see line #4 in both figures) was the current Identification value in use by Host A. 🔍

As a result, the attacker could employ this technique to learn the current Identification value used by Host A to send packets to Host B, even when Host A itself has a non-vulnerable implementation. 🌈💀

okay bestie, this part is a fun one 🦋 we're looking at how some popular operating systems actually pick their Fragment Identification values in the real world. spoiler: some of them are giving very predictable energy 💀

Here's the survey 👀

NOTE: The survey was produced with the SI6 Networks' IPv6 toolkit [SI6-IPv6].
+------------------------------+------------------------------------+
|       Operating System       |             Algorithm              |
+------------------------------+------------------------------------+
|        Cisco IOS 15.3        |    Predictable (Global Counter,    |
|                              |          Init=0, Incr=1)           |
+------------------------------+------------------------------------+
|         FreeBSD 9.0          |       Unpredictable (Random)       |
+------------------------------+------------------------------------+
|        Linux 3.0.0-15        |    Predictable (Global Counter,    |
|                              |          Init=0, Incr=1)           |
+------------------------------+------------------------------------+
|        Linux-current         |  Unpredictable (Per-dest Counter,  |
|                              |        Init=random, Incr=1)        |
+------------------------------+------------------------------------+
|          NetBSD 5.1          |       Unpredictable (Random)       |
+------------------------------+------------------------------------+
|       OpenBSD-current        |   Unpredictable (Random, SKIP32)   |
+------------------------------+------------------------------------+
|          Solaris 10          |   Predictable (Per-dst Counter,    |
|                              |          Init=0, Incr=1)           |
+------------------------------+------------------------------------+
|        Windows XP SP2        |    Predictable (Global Counter,    |
|                              |          Init=0, Incr=2)           |
+------------------------------+------------------------------------+
|   Windows XP Professional    |    Predictable (Global Counter,    |
|          32bit, SP3          |          Init=0, Incr=2)           |
+------------------------------+------------------------------------+
|  Windows Vista (Build 6000)  |    Predictable (Global Counter,    |
|                              |          Init=0, Incr=2)           |
+------------------------------+------------------------------------+
|    Windows Vista Business    |    Predictable (Global Counter,    |
|          64bit, SP1          |          Init=0, Incr=2)           |
+------------------------------+------------------------------------+
|    Windows 7 Home Premium    |    Predictable (Global Counter,    |
|                              |          Init=0, Incr=2)           |
+------------------------------+------------------------------------+
|    Windows Server 2003 R2    |    Predictable (Global Counter,    |
|     Standard 64bit, SP2      |          Init=0, Incr=2)           |
+------------------------------+------------------------------------+
| Windows Server 2008 Standard |    Predictable (Global Counter,    |
|          32bit, SP1          |          Init=0, Incr=2)           |
+------------------------------+------------------------------------+
|    Windows Server 2008 R2    |    Predictable (Global Counter,    |
|     Standard 64bit, SP1      |          Init=0, Incr=2)           |
+------------------------------+------------------------------------+
| Windows Server 2012 Standard |    Predictable (Global Counter,    |
|            64bit             |          Init=0, Incr=2)           |
+------------------------------+------------------------------------+
|    Windows 7 Home Premium    |    Predictable (Global Counter,    |
|          32bit, SP1          |          Init=0, Incr=2)           |
+------------------------------+------------------------------------+
|  Windows 7 Ultimate 32bit,   |    Predictable (Global Counter,    |
|             SP1              |          Init=0, Incr=2)           |
+------------------------------+------------------------------------+
| Windows 8 Enterprise 32 bit  |  Unpredictable (Alg. from Section  |
|                              |                5.3)                |
+------------------------------+------------------------------------+

Table 1: Fragment Identification algorithms employed by different OSs

NOTE: In the text above, "predictable" should be taken as "easily guessable by an off-path attacker, by sending a few probe packets".

Acknowledgements 💖

The author would like to thank Ivan Arce for proposing the attack scenario described in Appendix A. 🫶

The author would like to thank Ivan Arce, Stephen Bensley, Ron Bonica, Tassos Chatzithomaoglou, Guillermo Gont, Brian Haberman, Bob Hinden, Sheng Jiang, Tatuya Jinmei, Merike Kaeo, Will Liu, Juan Antonio Matos, Simon Perreault, Hosnieh Rafiee, Meral Shirazipour, Mark Smith, Dave Thaler, and Klaas Wierenga, for providing valuable comments on earlier draft versions of this document. 🌸 so many legends in one list, it's giving the whole networking hall of fame ✨

This document is based on work performed by Fernando Gont on behalf of the UK Centre for the Protection of National Infrastructure (CPNI). 👑

The author would like to thank Buffy for her love and support. 🧚💜

Author's Address 🎀

Fernando Gont Huawei Technologies Evaristo Carriego 2644 Haedo, Provincia de Buenos Aires 1706 Argentina

Phone: +54 11 4650 8472 Email: fgont@si6networks.com URI: http://www.si6networks.com

And that's the whole spec, bestie 🌈 periodt. Go put those predictable counters on the naughty list 💅

📦 where this page comes from