A Taxonomy and Comparative Analysis of IPv4 Identifier Selection Correctness, Security, and Performance

TL;DR

This paper investigates IPv4 IPID selection across a $16$-bit identifier, surveying a $25$-year history of IPID-based exploits and cataloging seven selection methods. It presents a unifying mathematical model to evaluate correctness, security, and performance, revealing that globally incrementing IPIDs can be the most robust choice under high traffic, contrary to common wisdom. The authors advocate a configurable, multi-method approach enabling users or administrators to tune IPID generation to their workload, mitigating attacks while maintaining performance. The findings have practical implications for DNS, NAT, and TCP/IP stack robustness, and call for configurable IPID strategies to balance competing security and efficiency needs in real-world networks.

Abstract

The battle for a more secure Internet is waged on many fronts, including the most basic of networking protocols. Our focus is the IPv4 Identifier (IPID), an IPv4 header field as old as the Internet with an equally long history as an exploited side channel for scanning network properties, inferring off-path connections, and poisoning DNS caches. This article taxonomizes the 25-year history of IPID-based exploits and the corresponding changes to IPID selection methods. By mathematically analyzing these methods' correctness and security and empirically evaluating their performance, we reveal recommendations for best practice as well as shortcomings of current operating system implementations, emphasizing the value of systematic evaluations in network security.

Figures (11)

• Figure 1: Anatomy of an IPv4 Packet Header. The 16-bit Identification field is the packet's IPID. The Flags and Fragment Offset fields are also used in IP fragmentation and reassembly.
• Figure 2: Timeline of IPID Measurements, Attacks, and Selection Methods. Each OS implementation of IPID selection varies over time in response to disclosed measurements and attacks (Section \ref{['sec:attacks']}), categorized either as probe comparisons (circles) or fragment injections (squares). Since 2000, Linux has implemented two methods, one for atomic packets (per-connection) and one for non-atomic packets (per-destination or per-bucket). FreeBSD has implemented various PRNG-based methods (dashed lines) but always disables them by default. Minor patches that did not change selection methods (e.g., a different hash function in per-bucket selection or Linux's fixes for specific packet types) are not shown.
• Figure 3: Idle Scan Execution. In an idle scan, a measurer $M$ is testing whether a target port on another machine $T$ is open. Measurer $M$ first probes the zombie machine $Z$'s current IPID, $x$. It then spoofs a SYN packet to the target machine $T$ that appears to have come from $Z$. (a) If the target port on $T$ is closed (red X), then $T$ does not respond and $M$'s final probe of $Z$'s IPID is $x+1 \bmod 2^{16}$. (b) Otherwise, if the target port on $T$ is open (blue circle), the resulting interaction between $T$ and $Z$ causes $M$'s final probe of $Z$'s IPID to be $x+2 \bmod 2^{16}$.
• Figure 4: Canary Fragments Execution. If a server $S$ uses a sequentially incrementing counter for its IPIDs, a measurer $M$ can count packets sent from $S$ to a client $C$ by planting canary fragments with a range of guessed IPIDs in the reassembly buffer of $C$ and later querying whether they were evicted.
• Figure 5: DNS Cache Poisoning Execution. In this attack, an attacker $A$ is redirecting traffic for a specific domain (e.g., abc.xyz.org) to an IP address of its choosing. First, $A$ probes the DNS name server $S$'s current IPID, $x$. It then spoofs a DNS response fragment containing its chosen IP address to the DNS resolver $R$ that appears to have originated from $S$; critically, this fragment's IPID must match whatever IPID $f(x)$ that $S$ will use in its later DNS response. When $S$ responds to a DNS request for abc.xyz.org, its fragment containing the authentic IP address will be discarded in favor of the spoofed fragment with the same IPID already in $R$'s reassembly buffer, causing the reassembled DNS response to contain the attacker's chosen IP address.