a fragmentation considered vulnerable - biuu.cs.biu.ac.il/~herzbea/security/12-03...

A

Fragmentation Considered VulnerableBIU Dept. of CS, Network Security Group Technical Report 12-03 (Sept. 2012)

Yossi Gilad† and Amir Herzberg‡Department of Computer Science, Bar-Ilan University†[email protected], ‡[email protected]

We show that fragmented IPv4 and IPv6 traffic is vulnerable to effective interception and denial-of-service

(DoS) attacks by an off-path attacker. Specifically, we demonstrate a weak attacker intercepting more than

80% of the data between peers and causing over 94% loss rate.We show that our attacks are practical through experimental validation on popular industrial and open-

source products, with realistic network setups that involve NAT or tunneling and include concurrent legiti-mate traffic as well as packet losses. The interception attack requires a zombie agent behind the same NAT

or tunnel-gateway as the victim destination; the DoS attack only requires a puppet agent, i.e., a sandboxed

applet or script running in web-browser context.The complexity of our attacks depends on the predictability of the IP Identification (ID) field which is

typically implemented as one or multiple counters, as allowed and recommended by the IP specifications. The

attacks are much simpler and more efficient for implementations, such as Windows, which use one ID counterfor all destinations. Therefore, much of our focus is on presenting effective attacks for implementations, such

as Linux, which use per-destination ID counters.

We present practical defenses for the attacks presented in this paper, the defenses can be deployed onnetwork firewalls without changes to hosts or operating system kernel.

Categories and Subject Descriptors: C.2.2 [Computer-Communication Networks]: Network Protocols

General Terms: Security

Additional Key Words and Phrases: IP Fragmentation, Denial of Service

ACM Reference Format:ACM Trans. Info. Syst. Sec. V, N, Article A (January YYYY), 37 pages.DOI = 10.1145/0000000.0000000 http://doi.acm.org/10.1145/0000000.0000000

1. INTRODUCTIONThe Internet Protocol (IP) is one of the most important and well-known communicationprotocols. The protocol has two standard versions: IPv4 [Postel 1981b] and IPv6 [Deer-ing and Hinden 1998]. IP packets are often not cryptographically protected; there-fore, a Man-in-the-Middle (MitM) attacker, e.g., on the path between two parties, canusually eavesdrop and modify packets. Despite significant possible threats, a commonassumption is that MitM capabilities are difficult to obtain; this assumption is demon-strated by OWASP’s list of top ten security risks [The Open Web Application SecurityProject (OWASP) 2010] where the majority of attacks do not require MitM capabilities.

Even without cryptography, network protocols should be secure against weaker -but common - off-path (spoofing) attackers. Off-path attackers are weaker than MitMattackers since they cannot eavesdrop to packets sent to others; however, they cansend ‘spoofed’ packets, i.e., packets containing fake source IP address.

Permission to make digital or hard copies of part or all of this work for personal or classroom use is grantedwithout fee provided that copies are not made or distributed for profit or commercial advantage and thatcopies show this notice on the first page or initial screen of a display along with the full citation. Copyrightsfor components of this work owned by others than ACM must be honored. Abstracting with credit is per-mitted. To copy otherwise, to republish, to post on servers, to redistribute to lists, or to use any componentof this work in other works requires prior specific permission and/or a fee. Permissions may be requestedfrom Publications Dept., ACM, Inc., 2 Penn Plaza, Suite 701, New York, NY 10121-0701 USA, fax +1 (212)869-0481, or [email protected]© YYYY ACM 1094-9224/YYYY/01-ARTA $10.00

DOI 10.1145/0000000.0000000 http://doi.acm.org/10.1145/0000000.0000000

ACM Transactions on Information and System Security, Vol. V, No. N, Article A, Publication date: January YYYY.

A:2 Y. Gilad and A. Herzberg

Mostly due to ingress filtering [Killalea 2000; Ferguson and Senie 2000; Baker andSavola 2004] IP spoofing is less commonly available than before, but still possible,see [Advanced Network Architecture Group 2012; Beverly et al. 2009; Ehrenkranzand Li 2009]. Furthermore, with the growing concern of cyberwarfare, some ISPs mayintentionally support spoofing. Apparently, there is still a significant number (18%-22%) of ISPs that do not perform ingress filtering [Advanced Network ArchitectureGroup 2012; Beverly et al. 2009], allowing their clients to spoof an arbitrary, routablesource address. Since there is a significant portion of ‘spoofing-supporting’ ISPs, theattacker can choose one of them as her provider; hence, the off-path, spoofing attackermodel is realistic.

In this paper, we present vulnerabilities in both IPv4 and IPv6 fragmentation mech-anisms, allowing exploits by off-path, spoofing attackers. Our attacks exploit predictionof the IP Identification (IP-ID) field that is specified in the IPv4 header and in the IPv6fragment header. The purpose of this field is to allow correct reassembly of fragmentedpackets: all fragments of the same packet have the same reassembly four tuple, seeDefinition 1.1. The IP-ID field differs between fragments of different packets with thesame source and destination addresses and over the same transport protocol.

Definition 1.1. IP fragments are associated to one (larger) packet according to fourparameters specified in the IP header which are the source and destination IP ad-dresses, the transport layer protocol and the IP-ID; we refer to these fields as thereassembly four tuple of a packet.

1.1. Choosing the IP Identifier: Specifications and ImplementationsIn this paper we exploit the fact that many systems use counters for choosing IP-IDs.Does this weakness lay in the a specification of the IP protocols or is it just a result ofweak implementations?

The IPv4 specification only requires that ‘in-flight’ packets will have a unique re-assembly four-tuple, i.e., the IP-ID must be unique for every packet with the samesource and destination and over the same transport-layer protocol until it reaches thedestination; this implicitly allows predictable implementations. The IPv6 specificationaddresses the issue of choosing the IP-ID and specifically suggests using a counterIP-ID to satisfy the ‘uniqueness’ requirement ([Deering and Hinden 1998], top of page19). The specification leaves the implementation to choose the exact flavor: either aglobally incrementing ID or a per-destination incrementing ID.

Systems that deploy a globally incrementing IP-ID maintain a single counter thatis incremented when sending a packet (regardless of its destination). Systems thatdeploy a per-destination incrementing IP-ID maintain a table of the ID values usedfor each of the recent destinations. When sending a packet to a destination in thetable, the current ID value in the table is incremented and used. Otherwise (destina-tion not in table), a pseudo-random value is used for the ID and stored in the table.Per-destination incrementing IP-IDs initialized to pseudo-random values are a recom-mended practice [Gont 2011], and categorized as ‘unpredictable’ in the IETF draft ofthe relevant IPv6 recommendation [Gont 2012].

In this paper we present off-path attacks for systems that implement either of thetwo variants above. These systems include the Windows family and FreeBSD1 whichuse globally incrementing IP-ID; as well as Linux and Linux-based systems (e.g., An-droid) which use per destination incrementing IP-ID.

1FreeBSD in default configuration, we discuss a different configuration in Section 9 when presenting de-fenses.


Fragmentation Considered Vulnerable A:3

1.2. Our Attacks and ContributionsWe present off-path attacks against fragmented IP traffic in common, standard net-work settings. The attacker can efficiently intercept traffic and cause packet loss. Theattacks are effective: the packet interception attack has a success rate of over 80%, andthe packet-discard attacks (DoS) cause loss rates of over 94%.

We present practical defenses against the attacks presented in this paper. The de-fenses can be deployed on network firewalls, without changes to hosts or operatingsystems.

1.2.1. Required Malicious Agents. Our traffic modification and interception attacks re-quire a zombie machine controlled by the adversary, e.g., compromised by malware,in the victim’s network. Although it is hard to evaluate their exact numbers, the por-tion of zombies in all IP addresses seems to be significant; e.g., see [Cooke et al. 2005;Greengard 2012]. There have been many attacks that show how an attacker who con-trols a machine inside the network can manipulate traffic. Most of these attacks usethe zombie machine to send spoofed traffic; for example, one of the most well-knownattacks is ARP cache poisoning [Steve Gibson 2005] which allows the adversary to in-tercept traffic by sending phony ARP responses. However, attacks that use the zombieto spoof packets are typically detected and blocked by network devices. In particular,many switches detect and block the spoofed ARP responses, e.g., [Cisco Systems 2006].In contrast, our attacks use the zombie only to read the raw headers of packets sent tothe zombie machine; this use cannot be detected by network monitors.

Our denial of service attack uses a weaker puppet agent [Antonatos et al. 2008].Puppets are malicious scripts or applets running in web-browser sandbox. Therefore,these attacks require that a client in the victim network ‘surfs’ to the attacker’s web-site, enabling the adversary to run such a script; puppets are easier to obtain thanzombies since the victim need not download or run malware. The victim machine is notcompromised when it runs a puppet due to sandbox-enforced limitations. In particular,the only communication mechanism available to the script or applet (received fromuntrusted website) is via TCP; it only allows to request HTTP objects and read HTTPdata (no access to raw packet headers, cf. to zombie).

1.2.2. IP-ID Prediction. We present new techniques that allow an off-path adversary topredict the IP-ID in different scenarios; we use the predicted IP-ID to perform ourattacks. A globally incrementing IP-ID is simple to predict if the attacker can com-municate with the victim and observe the IP-ID that she receives. Therefore, in thispaper we focus on the other common type of IP-ID, a per-destination counter. We showhow attackers can predict the IP-ID in per-destination incrementing IP-ID implemen-tations, albeit usually via more complex methods.

Specifically, we show how to predict the IP-ID, when the attacker only has a puppetbehind the same NAT or tunnel gateway as the victim Bob; see Figures 1-2. Thesenetwork settings are common, e.g., [Maier et al. 2011] found that 90% out of 20,000DSL lines (from a major European ISP) were located behind NAT devices.

Bob

Alice

Internet LANAgent

Mallory

NAT

id = i id = i

id = i + 1 id = i + 1

Fig. 1. Victim behind a NAT with adversarial agent.

BobAlice

GWB

GWA

Internet

S

LANA LAN

B

Mallory

TunnelAgent

Fig. 2. An IP-in-IP tunnel. Attacker has an adversar-ial agent behind one tunnel gateway.



Table I. Our results.

Exploit Setting Concurrent Traffic Packet Loss Malicious Agent SectionInterception NAT Yes Yes Zombie 3

Denial of Service

Tunnel/NAT No No Zombie 4Tunnel/NAT No No Puppet 5Tunnel/NAT Yes No Puppet 6Tunnel/NAT Yes Yes Puppet 8

1.2.3. Attacks. We first present the fragment interception attack which requires azombie machine in the victim’s network. The following sections present the IP-ID pre-diction technique and DoS attack; each section relaxes a different assumption of IDprediction, the final technique requires a puppet agent and works with concurrenttraffic and packet losses on network links. Table I summarizes our results.

1.3. Related WorksOur work builds on previous research on exploitation of the IP-ID field and the frag-mentation mechanism in general.

We extend two previous DoS attacks on fragmented traffic. The first is fragmentcache overflow [Kaufman et al. 2003], where the victim’s cache, which holds receivedfragments until reassembly, is exhausted with spoofed fragments; this causes the vic-tim to discard existing fragments in the cache. This technique is hard to exploit sincein order to cause packet loss, the adversary must exhaust the victim’s cache in theshort time between the packet’s first and last fragments arrive. The second attack isfragment mis-association [Heffner et al. 2007], where the adversary sends to the vic-tim spoofed fragments which remain in the victim’s cache. If later the victim receives afragment of a packet with the same reassembly four-tuple (see Definition 1.1) as one ofthe spoofed fragments which already reside in the cache, then the two fragments willbe mis-associated, i.e., reassembled together. However, the cache size does not allowthe adversary to save many fragments (specify much of the IP-ID space); this attackhas a very small impact - the maximal loss rate that we found reported was less than0.1%.

Fragment Cache Overflow Attack. Kaufman et al. [Kaufman et al. 2003] identified thateach fragment must be saved to allow later assembly of the IP packet. In their cacheoverflow attack, arbitrary fragments are sent to the victim. These are saved at thecache we described in the previous subsection. Eventually, enough fragments will becached in and overflow the recipient’s cache, causing genuine fragments be discarded.Exhausting the recipient’s resources with such fragments does not even require theattacker to send spoofed packets, since packets from all sources are saved in a sharedmemory pool.

The effect of this attack depends on the fragment cache management paradigm.Particularly, Linux machines discard fragments according to an LRU paradigm (aswe described above). Namely, when the resources are consumed, aging fragments areremoved first. Thus, the attacker must send enough fragments from the time the firstfragment of a packet reaches the decapsulator to the time the last fragment reachesthe decapsulator to exhaust its resources, see illustration in Figures 3-5.

Under default Linux configurations, the attack requires sending 256KB(ipfrag high thresh) and must be repeated between every two fragments of a packetthe attacker wishes to deny. If the difference in arrival times of the fragments (of thelegitimate packet) at the destination is small, e.g. 1ms, then the attacker needs to sendtraffic at a particularly high rate, approximately 1.5Gb/s. Furthermore, the attackeris required to estimate when the first fragment of a packet would reach the victim,otherwise he is required to send additional packets (more than the minimal required



to cause damage). The attacker’s high bandwidth should usually allow a less sophisti-cated clogging attack.

FragmentA

packetBob

Alice

FragmentAFragmentB

Fig. 3. Fragment cache over-flow attack. Alice’s packet ex-ceeds the minimal MTU on thepath to Bob; thus, some routerfragments it to two fragments.Bob receives the first fragmentand saves it until the second onearrives.

FragmentnBob

Mallory

Fragment1Fragmentn

...

FragmentA

Fragment1

.

.

.

Threshold

Fig. 4. Fragment cache over-flow attack. Mal sends Bobforged fragments that exhausthis memory. The oldest frag-ment, i.e. the one of Alice’spacket is discarded.

BobAlice

FragmentB

Fragment1FragmentB

FragmentA

.

.

.Threshold

Fig. 5. Fragment cache over-flow attack. The second frag-ment of the original packet sentfrom Alice reaches Bob. It issaved but the first fragment isalready discarded. The packetcannot be reassembled.

Fragment Mis-association Attack. Mathis et al. [Heffner et al. 2007] identified that bysending crafted IP fragments, a blind, but spoofing adversary is able to invalidate legit-imate packets. The key observation lays on the reassembly process at the destination:if an adversary is able to cache-in, in advance, a forged (single) fragment that speci-fies the source and destination addresses, protocol and IP identifier matching anotherfragmented packet, the forged fragment will be used for reassembly instead of the gen-uine one, i.e. mis-association. The reassembled packet will most likely be dropped byan upper layer because of incorrect checksum. Figures 6-7 illustrate the attack.

Fragment id = nBob

Mallory

Src Alice. Fragment id = n...

.

.

.

Src Alice. Fragment id = 1

Fragment id = 1

Fig. 6. Fragment mis-association attack. First, Malsends n spoofed fragments to Bob specifying Alice assource.

FragmentA id = k

packetBob

Alice

FragmentB id = kFragmentA id = k

FragmentB id = n...

FragmentB id = 1

FragmentB id = kReassembled packet

.

.

.

Fig. 7. Fragment mis-association attack. Second, Al-ice sends a packet that is fragmented by some routeron the path to Bob to two fragments with IP identifi-cation k.

However, at least for Linux, the mis-association attack does not produce much dam-age, as concluded by an experiment result in [Heffner et al. 2007] (and our experi-ments); the packet loss ratio is measured to be a few hundreds of a percent. The reasonis that the cache is much smaller than the space of identifiers, which does not allowMal to cache in a significant portion of forged fragments at the same time

.The attacks in this paper learn the value of the IP-ID counter. There have been pre-

vious works on sequence number prediction. Some of the notable works use weaknessin the pseudo-random generator (used to generate the initial counter value), e.g., [Za-lewski 2001], other works use malicious agents on the victim machine, e.g., [Qian andMao 2012; Qian et al. 2012]. Our attacks avoid these assumptions.

The attacks that we present in this paper exploit NATs and tunnel gateways influ-ence on traffic. Network middle-boxes sometimes reduce security as shown in previousattacks, e.g., firewall filtering rules that allow off-path TCP injections [Qian and Mao2012] and NAT port allocation algorithms that allow DNS poisoning [Herzberg andShulman 2012b].

A preliminary version of this paper appeared in [Gilad and Herzberg 2011].



1.3.1. Exploits of IP-Fragmentation and Predictable IDs. Several vulnerabilities related toIP fragmentation, such as Ping of Death [Kenney 1996], Teardrop [CERT 1997] andRose [Hollis 1997], are due to implementation bugs, and can be exploited for effectiveDoS attacks. However, these have been patched long ago and may still exist only inrelic systems. In contrast to such implementation vulnerabilities, this paper focuseson specification vulnerabilities.

The well-known idle (stealth) scan attack [Zalewski 2005; Lyon 2009] exploits glob-ally incrementing IP-IDs used by third-party machines to identify open (i.e., ‘TCP lis-tening’) server ports. The globally incrementing IP-ID algorithm reveals a machine’ssending rate [Sanfilippo 1998]; it allows network monitors to automatically detectprobing events, infer on the scanning strategy and learn whether probing is site spe-cific [Li et al. 2009]. Globally incrementing IP-IDs were also exploited for traffic anal-ysis [Gilad and Herzberg 2012]. In contrast to these exploits, in this paper we focus onpredicting and exploiting the per-destination incrementing IP-ID.

Predictable IP-IDs also allow an eavesdropping attacker to count the number ofhosts behind a NAT device [Bellovin 2002]. However, the adversary model in this paperis non-eavesdropping.

The idea of exploiting fragmentation for traffic injection was presented by Zalewski[Zalewski 2003]. He observed that global counter IP-IDs, as in Windows, allow an off-path attacker to modify the second fragment of a TCP packet. This allows to inject datato a TCP stream without requiring to guess the sequence number which is specified inthe first fragment. However, such ‘blind injection’ typically fails in practice since TCPusually performs path MTU discovery [Mogul and Deering 1990; McCann et al. 1996]and avoids fragmentation. Furthermore, this attack usually results only in packet loss(instead of packet injection) since the TCP checksum of the modified packet (specifiedin the first fragment) is incorrect after replacing the second fragment.

In order to mitigate ‘predictable IP-ID’ related attacks, some systems (e.g., NetBSD,Darwin) use pseudo-random IP-IDs2. Klein found that these implementations usedweak pseudo-random generators (PRNG), allowing attackers able to receive somepackets from the victim to predict the IP-ID field for all destinations [Klein 2007].

In this paper we improve and complete Zalewski’s idea by showing how to predictthe IP-ID for the case of per-destination counter and how the attacker can also mod-ify the first packet fragment and intercept packets. We show how to predict the per-destination IP-ID without observing any IP-ID values and under the assumption thatIP-IDs for different destinations are not correlated (i.e., vulnerability not in PRNG).

1.3.2. Denial of Service Attacks. In this paper we present a DoS attack against frag-mented traffic, our empirical evaluation shows over 94% loss rate without flood-ing network links. There have been previous works that investigate DoS attacks bybandwidth-limited adversaries.

In reflection denial of service attacks [Paxson 2001] the adversary sends short re-quests to some network services (e.g., DNS) and specifies a spoofed victim source. Theservices’ long responses clog the victim’s link. In contrast, our attack does not clog thevictim’s link.

In the TCP low rate attack [Kuzmanovic and Knightly 2003] the adversary sendsbursts of traffic while maintaining a low average transmission rate. This attack ex-ploits TCP congestion control mechanism by causing packet loss at specific times tosubstantially reduce TCP throughput. This attack targets TCP communication, andwill cause very limited damage to communication protocols that do not employ conges-tion control, e.g., protocols running over UDP. In contrast, the attack that we present

2However, this defense may degrade performance as we discuss later in Section 9 (‘Defense Mechanisms’).



in this paper targets fragmented traffic regardless of the transmission protocol. Sincefragmentation is rare for TCP packets, our attacks usually hinder TCP flows only ifthey are encapsulated, e.g., with IPsec, and then fragmented. Furthermore, our at-tacks do not require the attacker to clog a network link for packet loss (even briefly)and can be employed by adversaries with strictly bounded bandwidth. We note thatthe idea from [Kuzmanovic and Knightly 2003] of exploiting congestion control mecha-nisms to greatly reduce performance by causing packet loss at ‘strategic’ intervals canimprove our technique when the targeted flow employs congestion control.

The Opt-Ack DoS attack [Sherwood et al. 2005] exploits TCP congestion control aswell. In this attack the client sends future acknowledgments for packets that the serversends, causing the server to send at high rates and clog its own link to the network.This attack requires a privileged malicious agent (i.e., a zombie), that is capable ofsending raw packets (false TCP ACKs). In contrast, the DoS attack in this work usesa very limited sandboxed script (i.e., a puppet) for communicating with the server.Furthermore, the Opt-Ack attack has a limited effect in practice since servers usuallyapply transmission quotas to connections with clients, thereby avoiding transmissionin extremely high rates and clogging their own channels.

1.4. OrganizationSection 2 surveys the status of IP fragmentation both in the specifications and re-ality. Section 3 describes practical scenarios where an off-path adversary can easilylearn the IP identifier and presents the interception attack. Section 4 presents a tech-nique to expose the IP identifier between two tunnel gateways when the attacker hasa zombie machine behind one of these gateways; in this section we make two lenientassumptions: (a) while exposing the ID there is no concurrent traffic in the tunnel and(b) no loss on network channels. In Section 5 we show how to perform ID-exposingwhen the adversarial agent is a puppet instead of a zombie. Sections 6 and 8 presentand evaluate modifications to allow ID exposing with concurrent traffic and unreliablenetwork channels. Section 7 presents the continual deny and expose attack, showinghow after exposing the IP-ID, the off-path adversary can cause significant packet lossto fragmented traffic, i.e., denial of service. Section 9 presents defense mechanisms.Lastly, Section 10 presents our conclusions and future research directions.

2. FRAGMENTATION IN IPV4, IPV6 AND REALITYIn this section we attempt to answer the following question: ‘do attacks on fragmentedtraffic have a practical impact?’. We survey the status of IP fragmentation: present thedifferences in the specification of the IP protocols, discuss the cases that IP fragmen-tation is used in practice and present empirical measurements.

2.1. Specification Differences in IPv4 and IPv6 FragmentationThere are two main differences in the specification of IPv4 and IPv6 fragmentationmechanisms: (1) the length of the IP identifier and (2) where on the route packets arefragmented.

The first difference is that the IPv4 16-bit identifier is lengthened to 32 bits in IPv6.As a result, in most of the scenarios that we consider, prediction of the IPv6 identifierrequires the attacker to send more packets to the network than in the IPv4 versionof the attack. However, despite the substantially longer field, we show by experimentsthat our attacks are feasible even for IPv6.

The second difference regards to the question ‘who can fragment an oversizedpacket?’: in IPv4 any router along the path can fragment the packet, unless the senderspecifies ‘do not fragment’. In contrast, IPv6 only allows the sender to fragment thepacket. The motivation for this change was provided by the seminal work in [Kent



and Mogul 1987], which mainly addressed performance and reliability concerns whenhandling fragmented traffic.

2.2. Is Fragmentation Significantly Used?Fragmentation is still used, especially for UDP and tunneled traffic.

Fragmentation is used for UDP traffic since UDP is stateless and hence, usuallyavoids path MTU discovery [Mogul and Deering 1990]; instead, many UDP applica-tions rely on either short packets or IP fragmentation. When a UDP application sendsa buffer that is longer than the sender’s egress link, the sender fragments the packet(i.e., fragmentation occurs both in IPv4 and in IPv6). In particular, protocols that runover UDP and use asymmetric cryptography, such as IKE [Kaufman et al. 2010] andDNSSEC [Arends et al. 2005], are likely to use fragmentation since they typically sendlong packets which specify public keys and cryptographic signatures.

The second common case that fragmentation occurs is between two tunnel endpoints.The reason is that tunnels attach new headers to encapsulated packets, increasingtheir length which often then exceeds the minimal MTU in the tunnel; in this case,relaying on IP fragmentation provides an easy solution. In particular, the IPsec spec-ification allows implementations to rely on fragmentation (see Sections 6-7 of [Kentand Seo 2005]). In the tunnel scenario, the encapsulating end-point (e.g., IPsec gate-way) is the source of the encapsulated packet; therefore, it may fragment the packetsin IPv4 and IPv6. Note that fragmentation in the tunnel scenario is independent of theunderlying transport layer protocol, i.e., possible for TCP as well as UDP traffic.

2.2.1. ‘Natural’ IP-Fragmentation. There have been several works presenting statisticson fragmented traffic, e.g., [Shannon et al. 2002; John and Tafvelin 2007]; these worksindeed show that fragmentation is mostly employed for UDP and tunnel communica-tion. We now provide more recent statistics from analysis of the public CAIDA Internettraces datasets (from an Internet tier-1 router) [CAIDA 2012] to learn how common IP-fragmentation is in IPv4 and IPv6 today.

Our results show that fragmentation rates are lower in IPv6, however, not greatly.The statistics in brackets are for IPv6. We found that 0.15% (0.11%) of sampled packetsare fragmented. Fragmenation is mostly common for UDP packets 1.1% (0.8%). Oneimportant UDP applications is IKE; we found that over 15% (12%) of IKE negotiationsbefore establishing an IPsec tunnel utilize fragmentation. This was exploited in thepast to deny IPsec protection [Kaufman et al. 2003] (see Section 1.3). We have alsofound that tunneling protocols such as GRE [Farinacci et al. 2000] and IPsec [Kentand Seo 2005] messages are fragmented, approximately 1% (1%) of each protocol.

2.2.2. ‘Attacker-Triggered’ IP-Fragmentation. Natural fragmentation is rare; however, off-path attackers can often trigger fragmentation and then exploit it, e.g., using the tech-niques that we present in this paper. In particular, an adversary can spoof ICMP frag-mentation needed/packet too big messages ([Postel 1981a; Conta et al. 2006]) to per-suade the tunnel encapsulation point to send fragmented traffic. Even if the tunnelprovides an authentication service, such ICMP error-messages are sent by intermedi-ate routers and therefore, often cannot be validated. A spoofed ICMP message mightmaliciously effect communication; however, if a legitimate ICMP feedback is discarded,then communication might break. This dilemma is described in [Savola 2006] as wellas in the IPsec specification [Kent and Seo 2005] (Section 6.1.1) which explicitly allowseither form of ICMP-message handling (process or discard). In particular, three of thefour commercial and open-source implementations that we checked resort to sendingfragmented traffic after receiving such spoofed ICMP message3.

3Product names and versions are available from the authors.



Other protocols may allow other tricks. For example, in a follow-up work IP-fragmentation is exploited to perform DNS poisoning [Herzberg and Shulman 2012a].Here, the adversary queries for a long domain name, causing the authoritative DNSserver to send a fragmented response to the attacker’s resolver. The techniques thatwe present in this work allow the attacker to spoof part of the authoritative server’sresponse.

One of our conclusions from this work (also presented in Section 10) is that protocoldesigners and implementors should carefully consider when to resort to fragmentation.In these cases they should ensure that proper defenses were deployed against theattacks presented in this paper (e.g., as suggested in Section 9).

3. TRAFFIC MODIFICATION AND INTERCEPTION ATTACKIn this section we consider the network setting in Figure 1 where the adversarial agentis a zombie. In this setting, predicting per-destination incrementing IP-IDs is almostas easy as predicting globally-incrementing IP-ID: Alice uses the same destination IPaddress (of the NAT) when sending packets to Bob and to the zombie; hence, she alsouses the same IP-ID counter for both of them, allowing the attacker to learn (via thezombie) the ID in packets that she sends to Bob.

A NAT must be able to handle fragmented packets that it receives from the net-work and forward them to the end-host behind it [Audet and Jennings 2007; Huston2004]. Forwarding is performed according to a binding between the IP addresses andtransport layer ports. However, the transport layer header is only available in the firstfragment of a packet; therefore, NATs handle fragmented traffic in either of two ways:(1) attempt packet reassembly as if they were the end-host, and perform the NATtranslation only when the original IP packet has been reassembled; or (2) do not at-tempt packet reassembly, but rely on a stored packet fragment translation state thatdirects the translation to be performed on subsequent packet fragments after the ini-tial packet header translation has been performed on the initial IP packet fragment.

Our attacks in this paper assume that the NAT reassembles the packet fragments.We believe that this is also the more common implementation choice; the reason is thenetwork-layers architecture: since NATs observe the transport layer (L4) port, theyare typically involved in routing only after the packet is handled by the network IPlayer (L3), i.e., after IP packet reassembly. Moreover, the second implementation choice(NAT does not reassemble the packet) is problematic when out-of-order fragments ar-rive, i.e., when following fragments are received by the NAT prior to the initial IPpacket fragment. In such cases the NAT often has little choice but to silently discardthe out-of-order fragment as untranslatable.

We present in Subsection 3.1 an attack that allows the adversary to intercept allbut the first fragment of a packet. Subsection 3.2 presents a variant of the attack thatallows interception of all but the last fragments of a packet. Subsection 3.3 providesan empirical evaluation.

3.1. All-But-First Fragment Injection and InterceptionIn the fragment interception attack, illustrated in Figure 8, Mallory, the off-path at-tacker, sends a spoofed fragment that overwrites the transport header of a fragmentedpacket; as we explained above, this allows changing the destination host (behind theNAT). Specifically, by changing the destination port from eB , the port that the NATassigns to packets sent between Alice and Bob, to eZ , a port that the NAT assigns topackets sent between Alice and the zombie, the modified packet will reach the zombie.We now explain how this is done.

In the first step of the attack Mallory sends to the NAT a spoofed fragment thatmatches the reassembly four tuple of Alice’s packet, see step 1 in Figure 8; Mallory per-



forms this step sometime before Alice sends the corresponding packet4. The spoofedfragment specifies Offset = MTU, where MTU is the maximal transfer unit betweenAlice and the NAT excluding IP header length, and MF, the more-fragments flag,equals to 0. The zombie performs path MTU discovery to Alice to find the correct offset.These parameters make the spoofed packet appear as the second and last fragment ofa packet; the purpose of this fragment is to extract Alice’s first fragment from the cachewhen it later arrives, this by ‘completing’ a packet with it (mis-associated reassembly).The value of MTU need not be exact. Since the purpose of this fragment is to extractAlice’s first fragment from the cache, its offset can also overlap with the Alice’s firstfragment (i.e., offset < first fragment length). In this case, the IPv6 RFC specifies thatboth fragments should be discarded; the IPv4 RFC specifies that overlapped bytes aretaken from the fragment that arrives later, in this case a mis-associated packet willstill complete, as long as the data in Mallory’s fragment is not completely contained inAlice’s first fragment.

Next, Mallory waits for Alice’s packet fragments to arrive; we present the usual casewhere they arrive in order5. In step 2 in Figure 8 Alice’s first fragment arrives, the NATimmediately reassembles it with the cached spoofed fragment that Mallory had sent;both fragments appear to complete a packet, they are forwarded and removed fromthe NAT’s cache (host probably discards due to incorrect transport-layer checksum).

As a result, when the other fragments of Alice’s packet arrive, they stay in the cachesince reassembly cannot complete until the first fragment arrives; step 3 in Figure 8.

When Mallory assumes that all of Alice’s fragments arrived at the NAT, she sends aspoofed ‘first’ fragment (i.e., Offset = 0, MF = 1) that specifies a new transport layerheader; this header changes the external destination port of the reassembled packetfrom eB to eZ ; step 4 in Figure 8. Thereby causing the NAT to forward the packet tothe zombie rather than to Bob; step 5 in Figure 8. We next explain how the attackerfinds the value of eZ to use it in this attack.

Step Alice Mallory

NATExtPort IP:PorteB IPB : PBeZ IPZ : PZ

ZombieIPZ : PZ

BobIPB : PB

1MF = 0, Offset = MTU //

cached to mis− associate with first frag.

2

MF = 1, Offset = 0,IP-Data-Len = MTU, Dst-Port = eB //

mis− associated; evicted from cache and discarded (invalid checksum)//

3MF = 0, Offset = MTU //

cached

4

MF = 1, Offset = 0, Dst-Port = eZ ,IP-Data-Len = MTU, csum = 0

//mis− associated; destination port changed

5Dst = IPZ : PZ //

Fig. 8. All-But-First fragment interception attack.

4Mallory receives the IP-ID from the zombie (see discussion in the preface of this section) and can learn theNAT’s IP-address by observing any packet that the zombie sends her.5If fragments arrive in reverse order, the attack is simpler: Mallory sends the spoofed first fragment inadvance and waits for the reassembled packet to reach the zombie.



3.1.1. Revealing eZ . Mallory learns the value eZ , the port to which she should directthe reassembled packet, by sending spoofed packets (with Alice specified as source) tothe NAT device. Each packet specifies a different destination port; if the port of somepacket is the one assigned to the zombie (i.e., port is eZ), then he will receive the packetand notify Mallory (packet data can specify the external destination port)6.

3.1.2. Transport Layer Checksums. Although NAT devices are not required to validatethe packet checksum (see specification [Srisuresh and Egevang 2001]), we found thatsome do, e.g., Linux IP-tables NATs. In this case the final checksum in the packet (afterreassembly with Mallory’s spoofed fragment) must be valid or the NAT will discard thepacket. Since Mallory rewrites the transport header, she can modify the checksum. Forthe common case of fragmented UDP communication, modifying the checksum allowsa simple solution: by zeroing the UDP checksum Mallory cancels its validation (step 4in Figure 8)7 (see [Postel 1980]).

3.1.3. Long-Term Interception. Once Mallory receives the current value of the identifiercounter from the zombie (i) she caches multiple fragments simultaneously; i.e., sendsthe first packet of the attack (step 1 Figure 8) with identifiers i, . . . , i + x, where x >0 is the maximal value that the cache-size allows, the interval [i, i + x] is Mallory’s‘interception window’. Every short time interval Mallory sends for every IP-ID in theinterception window the corresponding packet for step 4 of the attack (see Figure 8).The zombie feedbacks Mallory with the highest IP-ID in the packets that he receives, i′,i.e., the current value of the counter. Mallory then restarts the attack with the updatedIP-ID (i′).

3.2. All-But-Last Fragment InterceptionIn this subsection we present a variant of the fragment interception attack that allowsMallory to capture the first fragment instead of the last fragment (cf. to the attack vari-ant above). In this version Mallory overwrites the last fragment and (only) the transportlayer header specified in Alice’s first fragment. This attack requires sending a spoofedfragment that overlaps with only the beginning of the genuine first fragment (thatspecifies the transport layer header); Since IPv6 does not allow fragment overlaps wefocus on IPv4.

In case of two overlapping IPv4 fragments, the overlapped data for the reassembledpacket is ‘taken’ from the fragment that begins in the lower offset. However, Mallorycannot specify a lower offset than that of the first fragment (offset is 0). If the offsetsof the two overlapping fragments (Alice and Mallory’s) are equal, then the overlappeddata is obtained from the fragment that arrived at the destination last.

Hence, in order to overwrite the transport layer header, Mallory should (1) send thespoofed overlapping fragment after the first genuine fragment arrives at the destina-tion machine (NAT); but (2) before the packet is reassembled (typically, this is whenall other fragments arrive). In the attack below Mallory first ensures that the NAT willdiscard the last fragment of Alice’s packet (that specifies MF = 0). Therefore, reassem-bly of Alice’s packet will not complete, providing Mallory time (dozens of seconds) tosend a fragment that specifically overwrites the transport layer header even after allAlice’s fragments arrive at the NAT.

To persuade the NAT to discard the original last fragment, we exploit another prop-erty of the reassembly mechanism: once a destination receives a last fragment of a

6Many NATs use counters to allocate ports, which allows more efficient search paradigms, e.g., see [Herzbergand Shulman 2012b].7We did not find that firewalls filter UDP packets without checksum; in particular, Microsoft and Linuxfirewalls in default configurations, allow these packets.



packet it computes the total length (by adding the last fragment length to its off-set); the destination discards last fragments ‘duplicates’ that indicate a different totallength.

Figure 9 illustrates the all-but-last fragment interception attack, we now present itstep by step. We assume for simplicity of the discussion that Alice’s packet has onlytwo fragments, but the attack is also applicable in the general case.

(1) Mallory sends an initial fragment and specifies that it is the last fragment of thepacket. Let l be the length of the first fragment of Alice’s packet, and let L > ldenote its total length. Mallory’s fragment starts at offset x > l and is of length l.Hence, it indicates that the length of the reassembled packet is x+ l = L such that,L 6= L; i.e., Mallory specifies a different total length of the reassembled packet. Notethat Mallory uses the zombie to find l (by path MTU discovery) as in the previousvariant.

(2) The first fragment of Alice’s packet arrives at the NAT. The fragment specifies thetransport layer header and a destination port, eB , that indicates the destinationhost behind the NAT. The length of this fragment is l, creating a gap of x − l >0 bytes in the reassembled packet (between Alice’s and Mallory’s fragments). Thepacket is not yet reassembled.

(3) The last fragment of Alice’s packet arrives and indicates that the length of thereassembled packet is L which differs from L, the previously computed length.Thus, the genuine last fragment is discarded.

(4) Mallory sends a short spoofed first fragment (offset is 0). We use a short fragmentto specifically overwrite the transport layer header; we assume the common casethat the packet is UDP; hence, this spoofed fragment is only 8 byes long8. Sincethis fragment arrived later than the genuine first fragment, it overwrites the over-lapped bytes. Mallory specifies a new destination port eZ that the NAT maps tothe zombie. The specified checksum is 0 to disable possible checksum validation atthe NAT (see above). Mallory sends this fragment only after a certain delay, whenshe assumes that Alice had already sent her packet (e.g., when she identifies thatAlice’s IP-ID counter incremented).

(5) Mallory sends a fragment that starts at offset l to fill up the gap of x − l bytes thatis between the spoofed fragment that she sent in step (1) and Alice’s first fragment(see step 2). This step completes the reassembly process.

(6) The NAT sends the reassembled packet to the zombie.

3.3. Empirical Evaluation3.3.1. Setup. Figure 1 illustrates the network topology for the evaluation; the LAN

(network ‘behind’ the NAT) consists of one switch (Linksys SE1500). Mallory andAlice are connected to the outer network (Internet) interface of the NAT (NetgearWNDR3700); Alice, Bob and the NAT run Linux (Alice and Bob: kernel version 2.6.35,the NAT-box: kernel 2.6.22). All bandwidths are 10mbps, except Mallory’s, who’s band-width varies between measurements (see below). Alice sends to Bob one 2000 byteUDP packet every 5 milliseconds (which is fragmented at the IP-layer by Alice her-self). The interception attack is not effected by the IP version9; our setup uses IPv4addresses.

8For interception of TCP fragments, such short fragments may be discarded [Ziemba et al. 1995; Miller2001]. In this case the attacker should send a somewhat longer fragment.9The only technical difference is that in IPv6 the zombie learns the IP-ID from the fragment header inpackets that he receives, cf. to the IP header in version 4.



Step Alice Mallory

NATExtPort IP:PorteB IPB : PBeZ IPZ : PZ

ZombieIPZ : PZ

BobIPB : PB

1

MF = 0, Offset = x > l,IP-Data-Len = l > 0, L 6= L

//cached

2

MF = 1, Offset = 0, IP-Data-Len = l,Dst-Port = eB //

cached

3

MF = 0, Offset = l,IP-Data-Len = L− l > 0

//frag discarded (bad length)

//

4

MF = 1, Offset = 0, Dst-Port = eZ ,IP-Data-Len = 8, csum = 0

//overwrite

5

MF = 1, Offset = l,IP-Data-Len = x− l

//reassembled

6Dst = IPZ : PZ //

Fig. 9. All-but-last fragment interception attack.

We compare two scenarios, which differ in the number of fragments that Mallorycan simultaneously cache at the NAT. We use typical Linux values: in order to avoidcollisions in the relatively short IP-ID field, recent Linux kernels (version 2.6.16 andonwards) allow up to 64 IPv4 fragments from the same source. For IPv6 several thou-sands of fragments are allowed, a similar limitation holds for IPv4 in older kernels(still likely used in embedded systems); in our evaluation we limit the number ofcached fragments in this scenario to 1024, but more fragments are allowed. We ex-tensively discuss the cache size restriction in the following section where it has a sig-nificant impact on our results.

3.3.2. Evaluation. We evaluate the long-term success rate of the fragment interceptionattack by measuring the portion of packets that Alice sends Bob whose fragmentsMallory manages to intercept. In these attacks Mallory receives periodic updates on theIP-ID from the zombie (to maintain synchronization) and caches-in multiple spoofedfragments (in the ‘interception-window’).

Our results, illustrated in Figure 10, show that Mallory is able to intercept a signif-icant amount of traffic even with relatively low bandwidths. In both scenarios for at-tacker bandwidths greater than 5mbs, most of the traffic that was not intercepted wasdenied; only less than 5% of Alice’s packets reached Bob’s application layer. The illus-trated results are average of 20 runs, where in each iteration Alice sends 10MB fromto Bob (in approximately 30 seconds). For attacker bandwidths greater than 5mbps wewere also able to intercept traffic over several minutes without losing synchronizationof Alice’s IP-ID.

The success rates are similar in both scenarios for most attacker bandwidths; weobserve that even the tight 64 fragments cache limitation allows effective long termfragment interception.

4. IP-ID EXPOSING TECHNIQUE



00.10.20.30.40.50.60.70.80.9

1

0 20 40 60 80 100

Fra

gmen

t Int

erce

ptio

n R

ate

Attacker Bandwidth (mbps)

All-but-first, 1024 frag. cache limitAll-but-first, 64 frag. cache limit

All-but-last, 1024 frag. cache limitAll-but-last, 64 frag. cache limit

Fig. 10. Portion of packets whose fragments reachthe zombie as a function of Mallory’s bandwidth. Errorbars mark the standard deviation values (for readabil-ity, some error-bars were omitted).

This section presents the ID-exposingtechnique; the off-path attacker learnsthe sender’s per-destination IP-IDcounter value and neither the attackernor her agent can receive the IP-ID (cf.to Section 3).

In the ID-exposing process Mallory re-ceives some feedback on lost packets;this allows her to efficiently learn theidentifier. In order to provide such feed-back, we require an adversarial agent,PuZo, in either the receiver or sender’snetwork. In contrast to the fragment in-terception attack which requires a zom-bie, here PuZo can be a puppet (see Section 1.2.1).

ID-exposing works in the NAT scenario as in Figure 1 and also in two additionalcommon scenarios: when the puppet runs on Bob’s machine, and when Alice and Bobare connected via a tunnel as in Figure 2. For simplicity, we refer only to the tunnelingscenario in following discussions, but the technique is identical for all three cases.

In this section present the basic ID-exposing technique. We make lenient assump-tions and in the following sections we modify our technique to eliminate them:

(1) PuZo is a zombie and not a puppet (eliminated in Section 5).(2) no background traffic during ID-exposing (eliminated in Section 6).(3) network channels are reliable, i.e., no packet loss (eliminated in Section 8).

In the tunnel scenario the agent receives ‘post-decapsulation’ packets. Therefore,even a privileged agent (i.e., a ‘zombie’) cannot observe the IP-ID of the encapsulatedtraffic, e.g., on the Internet, since it has a different IP header. We present a more com-plex technique that uses the following observation: if Mallory sends to GWB (see Figure2) a spoofed fragment with the source IP of GWA and IP-ID i, then PuZo will not receivelegitimate fragmented packets sent via the tunnel (i.e., from GWA to GWB), if they usethe same IP-ID i. This happens since Mallory’s fragment will be mis-associated withthe legitimate fragments and reassemble to a corrupt packet, which will be discardedat the gateway (GWB) upon decapsulation.

We assume that PuZo is able to communicate with a server, S, at the other side ofthe tunnel. Furthermore, we assume that PuZo is able to identify the sending order ofpackets that he receives from S, and a packet loss when it occurs; a zombie agent canobserve sequential IP-IDs or TCP sequence numbers to identify sending order and loss.The following discussions in this section assume that PuZo observes per-destinationincrementing IP-IDs. In Section 5 we describe a modified version of ID-exposing forthe case that PuZo is a puppet which can not read TCP/IP headers.

This section presents two versions of the ID-exposing technique: in Subsection 4.1,we show a naive technique that requires sending/receiving O(n) packets, where n isthe number of possible identifiers (n = 216 for IPv4). In Subsection 4.2, we improve theID-exposing technique using a meet in the middle paradigm; in the improved versiononly O(

√n) packets are sent/received. This modification allows ID-exposing for IPv6

(n = 232), as we show in experiments. Subsection 4.3 shows how to extend ID-exposingto learn the IP-ID of both gateways. Lastly, Subsection 4.4 provides a brief empiricalevaluation (extended in following sections).



4.1. Naive ID-ExposingIn this basic version of the ID-exposing technique, that is illustrated in Figure 11,Mallory caches-in one spoofed fragment at GWB; PuZo receives packets from the otherend of the network (e.g., from S) until he identifies that one of them was lost (mis-associated with Mallory’s spoofed fragment).

ID-exposing begins with an initialization phase, denoted by ‘Clear-Frag-Cache’,where Mallory removes existing fragments from GWB’s cache (step 1 in Figure 11). Inthis phase she sends large spoofed fragments, that specify a source different than GWA.These new fragments exhaust the cache space and suppress the fragments already inthe cache. This phase is similar to the fragment cache overflow attack [Kaufman et al.2003] discussed in our related works.

After the initialization phase Mallory sends one small spoofed fragment of an encap-sulated packet to PuZo’s gateway, GWB in Figure 2; this fragment stays in cache untilreassembly (or timeout, IP specifications recommend 30 seconds). The fragment spec-ifies GWA as source (i.e., spoofed), offset = MTU10,MF = 0 with an arbitrary IP-IDvalue (step 2 in Figure 11, ID = 2222). The parameters and purpose of this fragmentare similar to those of the the fragment that Mallory sends in the first step of the in-terception attack presented earlier; namely, this fragment is to mis-associate with agenuine fragment that GWA sends GWB.

Thereafter, Mallory orders PuZo to send a request to S, a server at the other end ofthe tunnel, for a large file or data. This causes S to send at least n packets (step 3 inFigure 11). Before encapsulation, S’s packets have sequential IP identifiers (since theyare all sent to the same destination, PuZo), 1111, 1112, 1113, . . . in Figure 2. S’s packetsreach GWA where they are encapsulated: GWA attaches a new IP header that speci-fies the gateways as source and destination (GWA and GWB, i.e., gateway to gatewaytunnel), and includes a different IP-ID. All the encapsulated packets have sequentialIP-IDs as well (since they have the same source and destination), 2221, 2222, 2223, . . .in Figure 11. We assume that these encapsulated packets exceed the tunnel MTU andare fragmented after encapsulation.

Since in this section we assume no background traffic on the tunnel and losslessnetwork channels, exactly one of the first n packets that S sends to PuZo is corrupted(mis-associated with Mallory’s spoofed fragment); in Figure 11, this is the packet withIP-ID=2222. PuZo receives all other packets and learns x, the missing IP identifier ofthe encapsulated packet that does not arrive.

Let x be the IP identifier of the last packet that PuZo received; PuZo computes i =x−x (mod n), this is the number of packets PuZo received from S after the lost packet.PuZo sends i to Mallory (step 4 in Figure 11) who computes the next identifier: id =2222 + i+ 1 (mod n).

4.2. Meet in the Middle ID-ExposingIn this subsection we revise the ID-exposing technique to generate O(

√n) packets (in-

stead of O(n)). The revised version has three phases: first, an initialization phase asin the basic version of the attack. Second, a meet in the middle phase that narrowsthe number of possible IP identifiers to

√n. Third, an exhaustive search phase where

Mallory the correct IP-ID from these√n identifiers.

In the meet in the middle phase, illustrated in Figure 12, Mallory sends√n fragments

that specify IP-IDs {j√n}√n−1

j=0 . In this version of ID-exposing S sends√n packets to

PuZo; the encapsulated version of one of these packets specifies an IP identifier thatMallory sent and therefore, does not reach PuZo (mis-associated, as in the previous

10The maximal transfer unit in the tunnel excluding IP header length (typically 1480 bytes).



Step S GWA Mallory GWB PuZo

1Clear-Frag-Cache: {MF = 1, Src 6= GWA}

suppress existing frags in GWB′s cache

//

2SRC = GWA , Offset = MTU, MF = 0, ESP, ID=2222

cached; will mis− associate with future packet//

3Begin //

Get Fileoo

ID=1111 // MF = 1, ESP, ID=2221

MF = 0, ESP, ID=2221// ID=1111 //

ID=1112 // MF = 1, ESP, ID=2222

MF = 0, ESP, ID=2222 mis− associated and discarded//

ID=1113 // MF = 1, ESP, ID=2223

MF = 0, ESP, ID=2223// ID=1113 //

. . . . . . . . . . . . . . .

ID=1110 // MF = 1, ESP, ID=2220

MF = 0, ESP, ID=2220// ID=1110 //

4i=1110−1112=−2 (mod n)oo

Fig. 11. Naive ID-exposing withO(n) packets. Notice that since S sends n packets to PuZo, the IP identifier(counter) overflows. ESP is an example of a tunneling protocol (IPsec).

version). PuZo computes i, the number of packets sent after the lost packet, and sendsit to Mallory. Since Mallory sent

√n spoofed fragments (i.e.,

√n ‘traps’), then after the

meet in the middle phase, she learns a list of√n possible identifiers. Algorithm 1

summarizes Mallory’s logic above.

. . . .0 n 2n 3n 4 n

. . .

3nk 4 n 4 nk−1

. . .

Fig. 12. Abstract view of GWB fragment cache during meet in the middle phase. Mallory sends√n spoofed

fragments that specify IP-IDs {i√n}√n−1

i=0 ; thereby, laying√n ‘traps’. When GWA encapsulates a packet for

PuZo with the identifier 4√n, a multiple of

√n, it will be lost.

Next begins the exhaustive search phase, where Mallory searches for the correct iden-tifier in a divide and conquer methodology. Namely, at round rMallory sends

√n

2r spoofed



Input: n - the number of possible IP identifiers; n = 216 for IPv4, n = 232 for IPv6.Output: IDs - an array of

√n possible values of the current identifier.

for j = 0 to√n− 1 do

Send-Spoofed-Fragment(j√n);

end/* PuZo requests

√n packets from S and identifies i, the number of

packets sent after a loss */Order-PuZo(‘ID-Exposing, meet in the middle’);i← Get-PuZo-Response();for j = 0 to

√n− 1 do

IDs[j]← j√n+ i+ 1 (mod n);

endreturn IDs;

Algorithm 1: ID-exposing, meet in the middle phase. Mallory learns a list of√n pos-

sible identifiers for packets that reach PuZo’s network (LANB in Figure 2) via thetunnel.

fragments that match√n

2r possible identifiers. These fragments are saved at the recip-ient’s fragments cache (GWB in Figure 2). Thereafter, PuZo sends a request to S whosends (at least) one packet in response. If the packet does not reach PuZo, then thecurrent identifier is one of those sent by Mallory at this round of the search; otherwise,it is one of the remaining identifiers. Mallory continues this process, which eliminateshalf of the possible identifiers in each round, until she learns the current IP-ID thatGWA uses for GWB. Algorithm 2 summarizes the exhaustive search phase.

Input: IDs - an array of√n possible values for the next identifier.

Output: the next identifier.begin← 0, end←

√n− 1;

while begin 6= end dofor i = begin to

⌊ end2

⌋do

Send-Spoofed-Fragment(IDs[i]);endOrder-PuZo(‘ID-Exposing, exhaustive search’);packetReceived← Get-PuZo-Response();if packetReceived = True then

end←⌊ end

2

⌋;

elsebegin←

⌊ end2

⌋;

end/* Account for the packet S sent PuZo. */Inc(IDs);

endreturn id← A[begin];

Algorithm 2: ID-exposing, exhaustive search phase. Given a list of possible identi-fiers performs an exhaustive search to learn the correct one. The function ‘Inc’ in-creases every element of its array parameter by 1.



4.2.1. Generalized Scheme - Coping with Small Cache Size. The gateway receiving Mallory’sspoofed fragments may not allow to cache enough fragments to perform meet in themiddle ID-exposing scheme as we described above. The typical cache size allows sev-eral thousands of fragments, but a tighter limit may exist for IPv4 to avoid collisionsin the short identifier field; e.g., in recent versions of the Linux kernel, Mallory can onlycache up to 64 IPv4 fragments.

A low limitation presents a problem for the attacker since ID-exposing using meetin the middle paradigm requires to cache a significant number of fragments simulta-neously. In order to cope with a tight limitation we increase d, the distance betweenidentifiers of sequential spoofed fragments that Mallory sends in the meet in the mid-dle phase (d =

√n is a ‘full’ meet in the middle). The generalized version presents a

trade-off: the higher d is, the fewer the fragments that are kept in the cache simulta-neously, but the more packets that PuZo needs to receive from S. Therefore we choosed = max{

√n, n

# frags allowed}.In recent versions of Linux d = 210 for IPv4 and d = 219 for IPv6 (in default kernel

configurations).

4.2.2. Analysis. During the meet in the middle phase Mallory sends nd packets to GWA

and S sends d packets to PuZo. In the exhaustive search phase, Mallory sends at therth round n

d·2r packets, and PuZo and S send one; i.e., Mallory sends∑log2

nd

i=1nd·2r = n

dpackets, PuZo and S send log2 d packets each.

We now compute the amount of data that each peer sends. In the computationsbellow we use the values n = 216, d = 210 for IPv4 and n = 232, d = 219 for IPv6.

Mallory sends 2nd very short fragments; the minimal fragment size is 21B for IPv4and 49B for IPv6. Mallory sends 2.5KB in IPv4 and 330KB in IPv6 ID-exposing.

The packets that S sends are long enough to be fragmented; assume that their size isthe typical 1500B MTU and that they are fragmented due to addition of tunnel headers.S sends 1.5MB during an IPv4 and 750MB during an IPv6 ID-exposing.PuZo’s requests are few and short for ID-exposing in either IP version, less than

10KB.

4.3. IP-ID Exposing For Both DirectionsWe now briefly describe how to modify the ID-exposing technique such that Mallorylearns the IP-ID used by GWB for packets that he sends to GWA. The modification is asfollows: first, Mallory sends the spoofed fragments to GWA, i.e., S’s gateway (cf. to PuZo’sgateway). Second, PuZo sends to S long request packet, such that the requests will befragmented after encapsulation. A request that has the same IP-ID as one of Mallory’sfragments is discarded by GWA (does not reach S) and therefore, PuZo will not receivea response (until PuZo resends the request). Say that the requests that PuZo sends arenumbered 1, . . . , x, and x is the index of the lost request, PuZo’s feedback to Mallory isi = x− x, and the attack continues as in Section 4.2.

Note that in many cases it is easy to send a long request packet that yields a re-sponse. For instance, if S is a web-server, then a long get request for a non-existingpage yields a HTTP 404 response.

4.4. Empirical EvaluationIn this subsection we provide a brief empirical evaluation for the ID-exposing tech-nique. We provide extensive experiments, measurements and discussions in the fol-lowing sections where we gradually improve our technique.

4.4.1. Setup. Figure 2 illustrates our network topology. LANA and LANB consist of oneswitch (Linksys SE1500) and two hosts that run Linux (kernel version 2.6.35). We



perform our evaluation on two, commercial and open source, extensively used IPsecgateway implementations. An off-path attacker can trigger IP-fragmentation in bothimplementations by sending the gateway a spoofed ICMP message, announcing lowMTU (see extensive discussion in Section 2.2.2); after resorting to IP-fragmentation,tunnel communication becomes vulnerable to our attacks11. The bandwidth of all par-ties was 10mbps and the round trip time between Mallory, GWA to GWB was 100 mil-liseconds.

4.4.2. Evaluation. We tested ID-exposing in both directions using the meet in the mid-dle paradigm. We performed 20 iterations of ID-exposing for each IPsec implementa-tion; in each iteration we exposed both IP-IDs. The average time for each iteration wasroughly 9.2 seconds (standard deviation 1.7 seconds) for IPv4 and 32.5 minutes (stan-dard deviation 4 minutes) for IPv6. Note that ID-exposing in one direction is roughlyhalf the time, i.e., 5 seconds and 16 minutes for IPv4 and IPv6 respectively.

While IPv6 ID-exposing requires significantly longer time to execute, it is feasible.Run-time should improve in the future as network-link capacities grow.

5. ID-EXPOSING WITH A PUPPETIn the previous section we devised an ID-exposing technique where a zombie (namedPuZo) identifies a packet loss by observing the IP-ID field in packets that he receives.This section presents modifications that allow ID-exposing for the case that PuZo is apuppet. By employing these modifications, Mallory can launch ID-exposing when a userin the network enters her website (we extensively discuss the puppet agent model inSection 1.2.1).

The challenge is that a puppet PuZo needs to identify when a packet is lost, but canonly use TCP socket services and cannot observe the TCP and IP headers. This meansthat our earlier approach of observing IP-ID (or TCP sequence numbers) discontinu-ities in packets that PuZo receives will not work. A TCP connection is reliable, thisinduces another difficulty: Mallory may be able to cause a packet loss, but that packetwill be re-transmitted until its data reaches the recipient (PuZo). It is therefore harderto detect a packet loss with a puppet that can observe only the application layer.

In order to implement ID-exposing using only a puppet, we use timing to detecta packet loss. Namely, PuZo requests resources from S (e.g., images) and times theresponse. Mallory either causes GWA to discard requests that PuZo sends, or GWB todiscard S’s responses, depending which of the two IP-IDs she tries to expose (see sub-section 4.3). When either the request or response packet is lost, the time until PuZoreceives the response (i.e., when request completes) is delayed by at least one S-PuZoround trip time (RTT), and often more.

A puppet can measure the time that a request completes in resolution of millisec-onds12. If the RTT between PuZo and S is significant (e.g., a hundred milliseconds ason the Internet), and network jitter is not too high (e.g., several milliseconds as typicalfor the Internet), then PuZo is able to detect a packet loss by measuring the time eachresponse takes to complete.

5.1. ImplementationPuppets, that run by the browser in context of an attacker’s site, are restricted bythe same origin policy [Ruderman 2001] and can communicate with a web-server inanother domain, such as S, only in very limited ways. In particular, puppets cannot

11Product names and versions of the implementations are available from the authors on request.12In Internet Explorer below version 9, Java Script code can only measure time in resolution of 1

64of a

second, i.e., roughly 15.5 milliseconds.



send to S HTTP GET or HTTP POST requests directly. However, a puppet is ableto use the HTML img and iframe tags to perform indirect requests for images andHTML pages. For example, if the adversary wishes to expose the IP-ID that GWB

uses in packets for GWA, then the puppet (e.g., running Java Script) updates thecurrent HTML page (displayed to the user, or within a small/zero-sized iframe) toalso include the following image tag: <imgsrc="http://s.com/long-object-name.jpg"onerror="TimeResponse()"/>. The long object name produces a request that exceedsthe MTU, the request is fragmented by the encapsulating gateway (GWB). If the objectis not available on S, then once the puppet receives HTTP 404 response (object notfound) the onerror event triggers the function TimeResponse, to allow the puppet tocomplete the measurement.

5.2. Empirical EvaluationIn this subsection we evaluate the success rate of IPv4 and IPv6 ID-exposing as afunction of the RTT between S and PuZo.

5.2.1. Setup. The network setup in this set of measurements is identical to the onepresented in Section 4.4. We implemented a Java Script that allows Mallory to exposethe IP-ID that GWB uses to send packets to GWA as described above. When the clientconnects to Mallory’s website he receives an HTML page with the script that executesautomatically, i.e., becomes Mallory’s puppet (PuZo).

We have added delays to the network at the gateways’ egress links. For each packetthe delay is chosen according to the normal distribution, with expectancy µ, whichvaries between measurements, and standard deviation that equals√µ (e.g., for RTT =128ms, we set µ = 64ms in both gateways).

00.10.20.30.40.50.60.70.80.9

1

4 8 16 32 64 128 256

ID-E

xpos

ing

Suc

cess

Rat

e

Puppet-Server RTT (milliseconds, log scale)

IPv4: Internet Explorer (v9)IPv4: Firefox (v9.0.1)IPv6: Internet Explorer (v9)IPv6: Firefox (v9.0.1)

Fig. 13. ID-exposing success rate for puppets run-ning on IE and Firefox as a function of PuZo-S RTT.Each IPv4, IPv6 measurement is the average of 50, 20samples respectively; error-bars mark standard devi-ations.

5.2.2. Evaluation. Figure 13 illustratesthe success rate of ID-exposing as afunction of the average RTT betweenthe puppet and the server (i.e., µ). Thegreater this RTT is, the higher the delayin response that a packet loss producesand the easier it is to detect this event.We compare the results when the puppetruns from different browsers.

In both IPv4 and IPv6, we observe a‘step function’: the attacker learns thecorrect IP-ID if the RTT is greater thana threshold, which is the minimal RTTthat allows the puppet to identify packetloss (with low probability for error). The reason that for IPv6 ID-exposing the thresh-old is greater than in the IPv4 version is that in IPv6 ID-exposing the puppet receivesmuch more packets; hence, the probability for an error due to delayed packet increasesand the threshold RTT increases correspondingly.

6. ID-EXPOSING IN THE PRESENCE OF BACKGROUND TRAFFICThe ID-exposing technique presented in Sections 4 and 5 assumes that there is nocommunication to or from PuZo’s network via the tunnel (depending on the IP-ID thatMallory tries to expose). In this section we investigate how to modify the ID-exposingtechnique to handle background traffic. We identify two types of errors that may occur:

(1) A packet sent to a host in PuZo’s network (other than PuZo) is encapsulated withthe IP identifier that Mallory had specified in one of the spoofed fragments. In this



case PuZo does not detect a packet loss and cannot provide a hint to Mallory regard-ing the current identifier (i.e., perform step 4 in Figure 11).

(2) Assume that PuZo identifies that a packet, p, was lost and notifies Mallory. WhenMallory performs the following exhaustive search iteration she must consider thenumber of packets that were sent to/from other hosts in PuZo’s network after p inorder to estimate the current identifier.

0.25

1

4

16

64

256

1024

4096

10% 20% 30% 40% 50% 60% 70% 80% 90% 100%

Pac

kets

Per

Sec

ond

(log

scal

e)

Percentile of IPsec Tunnels by Traffic Volumes

Avarage Standard DeviationAvarage Traffic Volume

Fig. 14. Average mid-day IPsec traffic volumes andstandard deviations by percentiles. Measurementsfrom [CAIDA 2012].

The probability for these errors ismostly effected by the standard devia-tion (or variance) of traffic volumes andnot their average: if traffic volumes areeasily anticipated (e.g., constant-rate,say π packets every second), then Malloryand PuZo can account for the traffic (addπ to IP-ID computations); the standarddeviation quantifies the ‘level of uncer-tainty’ in the number of independent IP-ID increments. In Figure 14 we providestatistics about IPsec tunnel traffic vol-umes, extracted from several samplesfrom a backbone router [CAIDA 2012]. The graph shows that the traffic volume and itsvariance are highly correlated, the correlation coefficient is ρ = 0.994. We observe thatwhile the average traffic volume and variance are very high for the top 10% of tunnels,the median values (denoted by 50% in Figure 14) are modest: the average number ofpackets per second is 5.3 and the standard deviation is 16. We empirically show thatour technique works well for these values.

The modified ID-exposing technique approximates the IP-ID: instead of a singleidentifier, the result is an interval of ‘likely next identifiers’. Our technique presentsa trade-off between the length of the interval, and the probability that ID-exposingsucceeds (i.e., the next IP-ID is one of those in the interval). In this section we assumethat network channels are lossless; Section 8 describes further extensions to avoid thisassumption as well. We only describe how to expose the IP-ID sent from GWA to GWB

(i.e., IP-ID of tunnel traffic to PuZo’s gateway); modifications for exposing the IP-ID ofthe other direction are similar to those described in Section 4.3 for ID-exposing withno traffic.

Once ID-exposing completes, Mallory learns the interval [b, e] and starts the continualdeny and expose attack as follows: she initializes the attack assuming that the currentidentifier is e; i.e., sends two sequences of spoofed fragments starting at id = e (seeSection 7). PuZo then starts receiving packets via the tunnel until he first identifiesa loss and informs Mallory that the current identifier matches to one of the spoofedfragments that she had sent (see Figure 20); the denial of service attack continues aspresented in Section 7.

In Subsection 6.1, we present and evaluate the modified version of the ID-exposingtechnique; this discussion assumes that the distribution (D) of the number of packetssent to PuZo’s network is known (to Mallory). In Subsection 6.2 we present and empiri-cally evaluate a technique that approximates D.

6.1. ID-Exposing Technique RevisitedThe ID-exposing technique (presented in Section 4) has two phases: meet in the mid-dle and exhaustive search (the latter consists of several iterations). We now describemodifications for each phase.



6.1.1. Meet in the Middle Phase. In this phase PuZo receives packets from S until heidentifies a packet loss (this event terminates the meet in the middle phase). Sincethere is background traffic, the phase does not surely terminate after receiving d pack-ets (where d is the difference between two sequential fragments, see Section 4.2.1);this is due to error type (1) described above.

The expected number of packets that PuZo receives during this phase is dω , where

ω denotes the ratio between the packets that he receives to the overall traffic (via thetunnel) to his network. The higher ω is, the shorter this phase.

6.1.2. Exhaustive Search Phase. In the exhaustive search phase Mallory has a list ofpossible IP-IDs. In each iteration, she sends spoofed fragments that specify half theidentifiers in the list and tests whether PuZo receives the following packet (see Algo-rithm 2). The modified version of the exhaustive search works similarly; however, sincethe IP-ID increments according to the distribution D (rather than remains constant),error types (1) and (2) above might occur. In order to handle these errors, Mallory sendsseveral spoofed fragments instead of one to test each IP-ID. These fragments specifyIP-IDs that cover intervals which are likely to include the next tunnel IP-ID.

In order to compute the intervals of IP-IDs to send in each iteration, Mallory esti-mates the number of packets sent over the tunnel since the initiation of the exhaustivesearch. The estimation is provided by computing a confidence interval: in iteration iMallory measures τi, the time elapsed since exhaustive search initiated and sets thedesired success probability, pi. Given the packet distribution D, she computes [b, e]: aninterval that includes, with probability pi, the number of packets sent over the tunnelafter τi seconds. In order to test a particular id, Mallory sends spoofed fragments withIP-IDs in the interval [id + b, id + e].

The probability that ID-Exposing with traffic succeeds is∏log n

xi=1 pi.

Let x denote the number of exhaustive search iterations; in iteration i of the modifiedversion, Mallory sends n

2i+x sequences of spoofed fragments (c.f. to n2i+x fragments in

Algorithm 2).In the modified version of the exhaustive search the adversary uses the packet dis-

tribution (D) and desired success probability (p) to compute the length of a confidenceinterval, for each iteration, an interval of IP-IDs such that the probability that thecurrent tunnel IP-ID is one of those in the interval is p 1

x . We use a confidence interval.Let δ denote the (estimation of) time to complete one exhaustive search iteration.

The length of the sequences in the ith iteration, denoted ci, depends on τi = δ · i, theestimated time to elapse from the start of the exhaustive search phase and until theend of the ith iteration.

Let λ denote the expected number of incoming packets per second (according to thedistribution D). Let πi denote the number of packets sent to PuZo during the exhaus-tive search phase until the start of iteration i (π1 = 0), Mallory knows the value of πi(for every i). At the beginning of each iteration, the identifier is expected to have in-cremented by µi = λτi + πi since the start of the exhaustive search. The greater τi is,the higher the variance of the number of packets sent to PuZo’s network and, sincethe estimation of µi is less accurate, the length of sequences that need to be sent isincreased.

Let Πi ≥ πi denote the number of packets sent to PuZo’s network during the exhaus-tive search phase until the start of iteration i (not just to PuZo, cf. to πi). Let p be theoverall success probability parameter and let p′ = p

1x . At the beginning of iteration i,

Mallory computes ci: the minimal integer such that Pr[µi − ci2 ≥ Πi ≥ µi + ci

2 ] ≥ p′;computation of ci is possible since D is known. In order to check IP-ID j, Mallory sends



spoofed fragments with IP-IDs in the interval [j + µi − ci2 , j + µi + ci

2 ] and continue theattack as in the basic version (eliminating half the possible IP-IDs in each iteration).

The probability for success in each iteration (the current ID is within the interval[µi − ci

2 , µi + ci2 ]), given success in the previous iteration, is at least p′. The probability

that after the last iteration only a single sequence remains that contains the currentidentifier (i.e., ID-exposing succeeds) is at least (p′)x = p (all iterations are successful)as required.

6.1.3. Adaptations for Small Cache Size. It may be impractical, due to cache size limi-tations, to cache in all of the IDs in the confidence intervals during the exhaustivesearch. Therefore, Mallory only sends one of every k > 1 IP-IDs in each tested interval.We increase the probability that PuZo detects a packet loss when it occurs (fragmentmis-association) by receiving m > 1 packets instead of just one for every iteration ofthe search. This technique somewhat resembles a meet in the middle paradigm. Figure15 illustrates the modified exhaustive search.

Algorithm 3 summarizes the attack presented in this subsection.

IDs that Mallory sends

confidence intervalid + b id + e

Fig. 15. Abstract view of GWB ’s cache during an exhaustive search iteration (with background traffic).Mallory sends spoofed fragments that specify one of every k = 5 IP-IDs in the computed ‘likely’ (confidence)interval. In black are IDs that GWA assigns to legitimate packets sent to LANB; in stripes are IDs assignedto packets that PuZo receives (m = 6). The dashed arrow denotes the ‘hit’ index (iteration ends).

6.1.4. Empirical Evaluation. Setup. In this section we re-evaluate the ID-exposing tech-nique in the background traffic scenario (see Algorithm 3). The setup is as describedin Section 4.4, except we modified the link bandwidth to 100mbps (cf. to 10mbs) to re-duce the runtime for each measurement. The round trip time (RTT) between all peerswas 100 milliseconds. All experiments assume the default Linux restrictions on thenumber of cached fragments (see Section 4.2.1).

Evaluation. We evaluate the success rate of the ID-exposing attack while Alice sendsBob packets according to the normal distribution with expectancy µ, variance σ2. InFigure 16 we measure the success rate of the attack for IPv4 and IPv6 as a functionof the traffic distribution in the tunnel13. Our measurements are for the ten classes oftraffic distributions illustrated by the echelons in Figure 14.

We set the probabilities {pi} such that∏pi = 0.5 (the probability for success); the

values k,m vary between measurements. The results show that our success rates arevery close to 0.5 for all traffic classes except for the last three, where ID-exposing typ-ically fails. The reason is that in these classes the variance of traffic volumes is veryhigh, which increases the size of the computed confidence interval, i.e., the number offragments that Mallory needs to cache, which is not always feasible. We believe that thereason that the success rates (for 70% of tunnels) is slightly below 50% is due to theadaptations for the limited cache size described above. Note the attacker can repeatID-exposing when it fails.

Additionally, we measured the accuracy of ID-exposing. Figure 17 illustrates thesize of the returned IP-ID interval (after successful ID-exposing) as a function of the

13A successful run is one that returns an interval which contains the next IP-ID.



Input: n - number of possible identifiers. d - the distance between two meet in themiddle IP-IDs. D - distribution of packets per second. {pi} - desired successprobabilities for exhaustive search iterations. m - number of packets sentto PuZo during one exhaustive search iteration. k - the difference betweenevery two IDs in the one interval sent by Mallory during this exhaustivesearch iteration.

Output: estimated interval of the next identifier./* Send spoof fragments covering n IP-IDs with ‘jumps’ of d; PuZo

receives packets until he identifies packet loss. */IDs← Attack-Meet-In-The-Middle(n, d);startTime← Time()for i = 1 to log2(nd ) do

τi = Time()− startT ime;/* Given the distribution (D), elapsed time (τi) and success

probability (pi), compute the a confidence interval estimating thenumber of packets sent since beginning of exhaustive search. */

[b, e] = Compute-Confidence-Interval(D, τi, pi)/* For every id ∈ IDs in even indices, cover [id + b, id + e] with ‘jumps’

of k. PuZo receives m packets. */identified-packet-loss← Attack-Exhaustive-Search(IDs, b, e, k,m);if identified-packet-loss then

Eliminate-Even(IDs);else

Eliminate-Odd(IDs);end

endreturn [IDs[0] + b, IDs[0] + e]

Algorithm 3: ID-exposing with background traffic.

traffic-class. The estimated interval is less than 0.01% of the search space size (i.e.,return interval lennumber of IP-IDs ) for most IPv4 and IPv6 tunnels. We also see that the accuracy is corre-

lated with the standard deviation (also shown in Figure 17); e.g., for zombie agent andan IPv4 tunnel scenario, the correlation coefficient is 0.96.

ID-exposing is possible with realistic traffic volumes. Our experiments show that thetraffic volumes of 70% of IPsec tunnels allow the attacker to learn the IP-ID with highaccuracy.

0

0.1

0.2

0.3

0.4

0.5

0.6

0.7

10% 20% 30% 40% 50% 60% 70% 80% 90% 100%

Suc

cess

Rat

e


Zombie (IPv4)Puppet (IPv4, runs on Firefox)Zombie (IPv6)Puppet (IPv6, runs on Firefox)

Fig. 16. Success rate as a function of traffic volumepercentile in the tunnel (see Figure 14). Each IPv4,IPv6 measurement is the average of 50, 20 iterations(respectively). Error-bars mark the standard devia-tions.

1248

163264

128256512

1024

10% 20% 30% 40% 50% 60% 70% 80% 90%

Fin

al In

terv

al L

engt

h (lo

g sc

ale)


Zombie (IPv4)Puppet (IPv4, runs on Firefox)


Traffic Volume Standard Deviation

Fig. 17. Length of the final IP-ID interval as a func-tion of traffic volume percentile in the tunnel (see Fig-ure 14). Error-bars mark the standard deviations.



6.2. Approximating Packet Transmission-Rate DistributionIn this subsection we show how to approximate the distribution D, which describes thenumber of packets per second sent from LANA to LANB. We collect samples of the rateof packets in the tunnel; the distribution of the average rate converges to the normaldistribution (the central limit theorem). Therefore, we focus on approximating the nor-mal distribution parameters: the expectancy (µ) and variance (σ2). The approximationtechnique depends on three variables:

(1) l - length of a spoofed fragments sequence.(2) d - distance between two sequences.(3) T - the time allocated to collect the measurements.

The algorithm begins similarly to the meet in the middle phase of ID-exposing:Mallory sends spoofed fragments which specify IP identifiers that are d apart. Addi-tionally, she sends for each of these spoofed fragments a pad of l − 1 fragments thatspecify the successive identifiers, creating n

d sequences of spoofed fragments (n is thenumber of possible identifiers, as in previous sections). Next, PuZo sends a request tothe server S at the remote end of the tunnel and starts receiving packets.

PuZo collects each measurement as follows: let t0 be the time that he receives thefirst packet after a packet loss; t0 is the time that the current IP-ID is ‘after’ one of thespoofed fragments sequences that Mallory had sent. PuZo counts the number of packetsthat he receives from the time t0 until time t1, when he identifies that another packetwas lost; i.e., when the current identifier is specified in Mallory’s spoofed fragments.Figure 18 illustrates the value of the current IP-ID in time t0 and t1.

frags

i+di

initial id

l frags

i+2d

l fragsl

id at t0

id at t1

Fig. 18. Abstract view of GWB ’s cache while Mallory learns µ.

Consider the scenario that there is no other traffic; in this scenario PuZo receivesR =nd − l packets during the time interval [t0, t1]. Since in our scenario there is backgroundtraffic which increments the IP-ID, the number of packets that PuZo actually receivesduring [t0, t1], denoted by r, may differ from R.

Normally, r ≤ R; if r > R, then there exists at least one sequence of spoofed frag-ments between the IP-ID in the packet that PuZo received at time t0 and the one thathe received at time t1. In this case PuZo restarts the measurement process. Otherwise(r ≤ R), PuZo estimates the number of packets that were sent to others in his networkby R − r. We conclude the measurement of µ to be R−r

t1−t0 . PuZo collects measurementsuntil timeout, i.e., until T seconds elapse; the average measurement, denoted by µ,is the estimation of µ. Similarly, we compute the standard deviation of the measure-ments, σ, and use it as an approximation of σ.

The higher l is, the greater the probability that PuZo identifies two consecutive se-quences of spoofed fragments. The greater d is, the longer it takes to collect each mea-surement, however, each measurement samples a longer time period and therefore,characterizes better the traffic volume. The constraint for d and l is that l · nd , the num-ber of fragments that Mallory caches, is allowed in the cache; see details on the cachesize limitation in Section 4.2.1. We note reasonable values for IPv4 and IPv6 in defaultLinux configuration in our evaluation below.



Algorithm 5 summarizes the logic for approximating µ. Algorithms 4 and 5 summa-rize the logic for estimating µ.

Input: n - the number of possible IP identifiers. d - difference between the IP-IDthat begins each sequence. l - the pad length. T - time to collect themeasurements.

Output: µ - an approximation of µ.i← 0;/* Cache the sequences of spoofed fragments. */while i < n do

j ← i;for j < i+ l do

Send-Spoofed-Fragment(j);endi← i+ d

end/* Call to Algorithm 5. */return µ← Approximate-µ(n, l, T );

Algorithm 4: Mallory obtains an approximation of µ.

6.2.1. Empirical Evaluation. Setup. We used the same setup as in Section 6.1.4 to eval-uate the approximation technique. We used different parameters for IPv4 and IPv6:T = 5 minutes, l = 4 and d = 212 for IPv4; T = 30 minutes, l = 2 and d = 220 for IPv6.

Evaluation. We evaluate the accuracy of our estimation for different traffic patterns,representing the traffic-volume echelons in Figure 14. During the experiment Alicesends Bob every second a number of packets chosen according to the normal distribu-tion with expectancy and standard deviation that correspond to an IPsec traffic volumeechelon in Figure 14.

Figure 19 illustrates the error in approximation; for readability we only present theerror in the approximated expectancy i.e., µ−µ. However, errors for standard deviation(σ − σ) are similar; the high correlation between µ and σ also implies this result (seediscussion in the preface of this section).

-30

-20

-10

0

10

20

30

10% 20% 30% 40% 50% 60% 70% 80% 90%100%

Err

or


Zombie (IPv4)Puppet (IPv4, runs on Firefox)Zombie (IPv6)Puppet (IPv6, runs on Firefox)

Fig. 19. Error in Approximation of number of ex-pected packets per second as a function of the trafficpattern. Each measurement is the average of 10 iter-ations. Error-bars mark the standard deviations.

We observe that the accuracy is highfor most traffic classes, but also that ourtechnique often under-estimates µ. Thereason is that when PuZo ‘misses’ thefollowing sequence of spoofed fragmentsthat Mallory had sent, he does not al-ways detect the error and restarts themeasurement; as a result the number ofpackets that PuZo receives (r) is greaterthan it should be, which decreases themeasurement result and µ (see how wecompute the measurement above).

The higher the traffic volume is, thegreater the probability for errors and torestart the measurement; i.e., the number of collected measurements until timeoutdecreases and inaccuracy in approximation grows. We also see that our method failsfor the top echelon of tunnel traffic volumes, the reason is due to the very high variance



Input: d - difference between the IP-ID that begins each sequence. l - pad length.T - time to collect the measurements.

Output: An approximation of µ.i← 0;R← d− l;begin← Current-Time();while Current-Time()− begin < T do

Send-Request();Wait-Until(response packet arrives, but previous response packet was lost);t0 ← Current-Time();r ← 0;Send-Request();/* Count the packets received until the next sequence. */while True do

Wait-For-Response-Packet();if response arrives then

r ← r + 1;else

break;end

end/* Conclude the measurement. */if r ≤ R then

t1 ← Current-Time();M [i]← (R−r)

t1−t0 ;i← i+ 1

endendreturn

∑M

length(M) ;Algorithm 5: Approximate-µ.

in such traffic (average standard deviation is above 500 packets per second); the highvariance is also the reason that ID-exposing fails for this traffic class (see Figure 16).

7. CONTINUAL DENY AND EXPOSE ATTACKIn Sections 4-6 we introduced the ID-exposing technique, where Mallory learns the IP-ID attached to encapsulated traffic by a gateway, say GWA, to a tunnel endpoint, GWB.Given the identifier, Mallory can execute an improved version of the fragment mis-association attack (see [Heffner et al. 2007] and our related works) to deny fragmentedtraffic in the tunnel even for the typically limited cache size. However, it is difficult forMallory to maintain long term synchronization with the current IP-ID value since it isincremented for every packet that GWA sends to GWB.

In this section we present the continual deny and expose attack, where given an ini-tial value for the IP-ID, Mallory maintains a short interval of possible ‘current’ IP-IDsat any given time. This allows her to launch a long-lasting fragment mis-associationattack. The attack works in a similar setting to that of ID-exposing (illustrated in Fig-ure 2). We present empirical measurements of this attack on two extensively deployed,commercial and open source, Linux based IPsec implementations.



7.1. Attack ProcessMallory begins the continual deny and expose attack after the ID-exposing process (seeSections 4,5) where she learns i, the next IP-ID that GWA will use for sending a packetto GWB.

During the attack Mallory keeps two sequences of spoofed fragments with consecutiveidentifiers cached at GWB; between these sequences there is a small gap of identifiersthat Mallory does not send. Figure 20 illustrates GWB’s cache; a packet that Alice sendsto Bob (two hosts in Figure 2) that arrives fragmented at GWB, reaches Bob only ifit specifies an IP identifier that is not in one of Mallory’s sequences. The small gapbetween the two sequences allows PuZo to monitor increments of the IP-ID by testingwhether he can receive (fragmented) packets via the tunnel.

Furthermore, the division into two sequences provides Mallory early notifications toupdate the cached fragments. Namely, Mallory has time to send a new sequence ofspoofed fragments until the second sequence, that is already cached at GWB, becomesobsolete. These two characteristics allow attackers with relatively low bandwidths tocause high loss rates for fragmented traffic, see experiments in next subsection.

i+m2

−1i imc−1i+m2

+c

Current id

gap

Fig. 20. Abstract view of GWB ’s cache during the continual deny and expose attack. Mallory keeps twosequences of spoofed fragments cached-in. A fragmented packet with IP-ID j arrives at its destination if: (1)j is in the gap; or (2) j < i ∨ j ≥ i+m+ c.

The continual deny and expose attack, summarized in Algorithms 6 and 7, includesan initialization phase where Mallory sends to GWB the first two sequences of spoofedfragments. Let m be the maximal number of fragmented packets from a single sourceaddress that may be cached simultaneously at GWB. Each of the two sequences thatMallory sends is composed of m

2 (spoofed) fragments with consecutive identifiers. Thefragments in the first and second sequences specify the identifiers in the intervals[i, i+ m

2 −1], [i+ m2 + c, i+m+ c−1] respectively, where c is the inter-sequence gap size;

see Figure 20. After caching the initial spoofed fragments, Mallory updates i← i+m+2c,and orders PuZo to begin his role in the attack. This completes the initialization phase.

When PuZo receives Mallory’s message, he begins sending a request every τ secondsto a server, S, at the other end of the tunnel (see Figure 2); S sends in response asingle or few long packets (which are fragmented after encapsulation). The length ofthe gap (c) must be sufficiently large to allow PuZo to receive a packet given the requestinterval (τ ). However, the gap should be small such that only few legitimate packetswill pass through during the ‘in-gap’ period.

When one of S’s packets reaches PuZo, he concludes that the current IP-ID is in thegap between the two sequences and notifies Mallory who then sends the next sequenceof identifiers (see Algorithms 6, 7); i.e., identifiers in the interval [i, i + m

2 − 1], andupdates the current index: i ← i + m

2 + c. The new sequence of fragments that Mallorysends supersedes the first of the two sequences that she has previously sent since thecache management paradigm is ‘remove least recently used’.

When the identifier is in the gap, legitimate traffic is not disrupted; therefore, PuZomakes frequent requests and generates response traffic from S to himself (withoutwaiting between requests). Each response packet increments the IP-ID counter untilit is after the gap. At this time GWA’s IP-ID equals to that of a spoofed fragment inthe second sequence that Mallory cached at GWB. PuZo identifies this event when a



Input: i - the next identifier that GWA will use for GWB. m - maximal number ofspoofed fragments in GWB’s cache. c - the length of the gap betweenfragment sequences that Mallory sends.

/* Initialization phase */for j = 1 to 2 do

Send-Spoofed-Frag-Sequence(i, m2 );i← i+ m

2 + c;endOrder-PuZo(‘DoS’);/* Continual Deny and Expose */while True do

Wait-For-PuZo-Notification();Send-Spoofed-Frag-Sequence(i, m2 );i← i+ m

2 + c;end

Algorithm 6: Continual Deny and Expose DoS attack. Mallory’s logic.

Input: τ - time in seconds between requests. c - gap length.Wait-For-DoS-Request();tq ← τ ;/* Send a request every query seconds (performed in the background). */Send-Request-Every-Interval(tq);while True do

/* Flow continues when IP-ID is in the ‘gap’ */Wait-Until(response packet arrives);Notify-Mal(), change request interval to ‘frequent’, e.g., tq ← τ

4 ;/* Flow continues when IP-ID is after the ‘gap’ */Wait-Until(response packet lost or c packets received);tq ← τ ;

endAlgorithm 7: Continual Deny and Expose DoS attack. PuZo’s logic.

response packet is again lost, i.e., assumes that mis-association occurred, and returnsto sending a request every τ seconds14.

We note that continual deny and expose works similarly for both a ‘zombie’ and a‘puppet’ PuZo. The reason is that in this DoS attack PuZo only needs to indicate whenhe receives a packet (rather than to identify a loss, as in ID-exposing). In case thatPuZo is a puppet, he makes an HTTP request (e.g., to S) and waits for the answer,allowing the TCP implementation to automatically resend the request when it is lost;the puppet can use connections with several servers to support frequent queries. Oncesome response arrives, the IP-ID is ‘in-gap’. The rate that a puppet can send requeststo the server is usually limited by the browser who limits the number of differentconnections and parallel requests on each connection. Hence, the puppet version of theattack requires a larger gap (greater c) than the zombie version.

7.2. Empirical Evaluation7.2.1. Setup. The network setup in this set of experiments is identical to the one in

Section 4.4; the round-trip time between PuZo and the server is 100 milliseconds. We

14PuZo also quits the ‘frequent request’ mode when he assumes that S sent him c or more packets.



evaluate the ID-exposing attack both for zombie and puppet agent. In this set of ex-periments, Alice sends Bob 200 packets per second (average rate). Since the continualdeny and expose attack is not effected by the IP version (given the initial identifier isknown), our evaluation is only on IPv4 IPsec tunnels.

7.2.2. Evaluation. We performed the continual deny and expose attack on two, com-mercial and open-source, IPsec implementations and measured its impact on TCP andUDP traffic as a function of Mallory’s bandwidth. In case that PuZo is a zombie, he re-ceives a packet from S every 10 milliseconds. In case that PuZo is a puppet, he opens10 connections to servers in LANA

15 and sends to each server a request when the pre-vious request to that server completes (receives a response or times out); in our setupthe puppet sends one request (new or retransmission) approximately every 30 millisec-onds. Our experiments assume that Mallory can cache at most 64 fragments at GWB.

00.10.20.30.40.50.60.70.80.9

1

0 20 40 60 80 100

Pac

ket L

oss

Rat

eAttacker Bandwidth (mbps)

Open-Source, ZombieCommercial, Zombie

Open-Source, PuppetCommercial, Puppet

Fig. 21. Continual Deny and Expose attack evalua-tion. Each measurement is the average of 5 iterationsof a 5 minute attack, error bars mark the standarddeviations. Puppet runs on Firefox (v9.0.1).

The length of the gap between two con-secutive sequences that Mallory sends(i.e., c), is 4 in case that PuZo is a zom-bie, and 16 in case that he is a puppet.

For most attacker bandwidths, TCPcommunication (encapsulated in theIPsec tunnel) was completely blocked;the reason is that TCP’s congestioncontrol rapidly decreases the transmis-sion rate when it identifies a packetloss. Figure 21 shows the loss rates forUDP traffic that Mallory is able to pro-duce for different available bandwidths.For low bandwidths (less than 5mbps)Mallory cannot keep the attack ‘alive’,and quickly loses synchronization with the current IP-ID value. For other attackerbandwidths (i.e., greater or equal 5mbps) continual deny and expose appears very ef-fective, e.g., loss rates induced when using a zombie agent are over 90%.

8. ID-EXPOSING WITH NETWORK-LINK PACKET LOSSThe ID-exposing technique and the following continual deny and expose attack, thatwe presented in the previous sections, assume reliable network channels. In this sec-tion, we extend our techniques to handle packet losses on network links. In the fol-lowing two subsections we separately discuss how to cope with loss of Mallory’s spoofedfragments and loss of packets sent by or to PuZo. If those of the former types are lost,then mis-association might not occur when it should; if those of the latter type arelost, then PuZo might provide a false indication for mis-association. We conclude thissection with an empirical evaluation, measuring the success rate of ID-exposing withdifferent probabilities for loss.

The probability for packet loss, ε ,depends on the geographic location of the twopeers; a recent study shows that in most cases, this probability no more than 0.5%[Wang et al. 2009]. In the numeric examples of the subsections below we use this value,i.e., ε = 0.5%, to provide intuition for the effect of the packet loss rate on our attack.Our emperical evaluation considers other values as well. For simplicity, our analysisand evaluation assume that all packet loss events are independent.

15The maximal number of connections that a puppet can open is usually a few dozens (default configuration).



8.1. Loss of Mallory’s Spoofed FragmentMallory sends three types of fragments: the first are for cache cleanup operations, thesecond are spoofed fragments for ID-exposing and the third are during the continualdeny and expose attack. We separately discuss how to handle packet loss for each type.

8.1.1. Cache Cleanup Fragments. Mallory sends these fragments to clean the victim’scache (see step 1 in Figure 11). In this case we only need to ensure that enough frag-ments reach the victim to overflow his cache. In case that packet loss occurs, sendingcache size

MTU fragments of MTU bytes (as described in Figure 11) does not result in thevictim actually receiving a total of cache size bytes (cache does not overflow).

In order to cope with this problem Mallory sends additional η fragments, the proba-bility that the victim receives at least cache size bytes is

∑ηi=0 (1− ε) cache size

MTU +iεη−i. Fordefault Linux configurations and typical MTU = 1500 bytes, ε = 0.5%, η = 4, the suc-cess probability is over 0.999.

8.1.2. ID-Exposing Fragments. Mallory sends these fragments with specific identifiers,to cause mis-association and receive feedback from PuZo. PuZo does not identify mis-association in case that a packet is sent to him with the particular identifier specifiedin a lost spoofed fragment sent by Mallory.

Mis-association should occur exactly once during the meet-in-the-middle phase, andon average 4 (IPv4) or 8 (IPv6) during the exhaustive search. For ε = 0.5%, the prob-ability for error is 2.5% for IPv4 and 4.5% for IPv6. These numbers can be further re-duced by sending the fragments of the later iterations of the exhaustive search phaseseveral times: increasing the probability that at least one copy arrives while not incur-ing high overhead (since in these iterations there are only few fragments to send). Forexample, by sending four times the last four exhaustive search iterations, the proba-bility for error is reduced to 1% (IPv4) and 2.5% (IPv6).

8.1.3. Continual Deny and Expose Fragments. Mallory sends these fragments to cause re-peated, long-term, mis-association. If one of the fragments is lost, then the correspond-ing packet (with the same IP-ID) will arrive to its destination: either a host in LANB orPuZo (see Figure 2). In the former case, some legitimate traffic will pass. In the lattercase, PuZo will notify Mallory to send a new block of spoofed fragments and the currentblock will be over-ridden with the new one; legitimate traffic will temporarily pass(until the following block of spoofed fragments is reached, see Algorithm 6). The prob-ability that this error occurs, for each block that Mallory sends is 1− (1− ε)m (where mis the block size). For ε = 0.5% and typical block size, e.g., m = 32, the probability thatthis error occurs is 14%, however, its damage to the attack is temporary and limited:at most one block size each time.

8.2. Loss of Traffic to/from PuZo

A packet loss may cause PuZo to falsely detect fragment mis-association and providea misleading indication to Mallory. This error causes failure if during ID-exposing, andloss of synchronization if during continual deny and expose ‘gap-period’ (see Figure20).

8.2.1. ID-Exposing Packet Loss. The probability for this error depends on the numberof fragments that PuZo receives or sends (depending on the direction of ID-exposing,see Section 4). The significant majority of these packets are for the meet in the middlephase; in order to handle these errors, Mallory adds padding for each of the spoofedfragments and PuZo notifies for mis-association only if several sequential packets werelost. In the exhaustive search phase, PuZo receives (or sends) relatively few packets;we leave this phase unmodified.



For example, sending an additional fragment with the sequential IP-ID for eachfragment during the meet in the middle and PuZo notifies for mis-association only iftwo sequential packets were lost. Reduces the probability for error in this step from73% to less than 1% (IPv4) for ε = 0.5%.

8.2.2. Continual Deny and Expose, ‘Gap-Period’ Packet Loss. We increase the probabilitythat PuZo receives a packet during the ‘gap period’. Our general approach is to increasethe number of packets that are sent to PuZo during this phase, this is by reducing thequery interval (τ ), i.e., PuZo receives packets more often; and increasing the gap length(c) lengthening the ‘gap period’. See Section 7.1 for description of these parameters andthe attack process.

8.3. Empirical EvaluationIn this subsection we provide an evaluate for the entire attack, i.e., ID-exposing andthen continual deny and expose, as a function of the packet loss rate.

8.3.1. Setup. Our setup is similar to the one described in Section 6.1.4. In our evalu-ation, we deploy a traffic controller on each of the interfaces directed to the ‘Internet’in Figure 2 (our network topology); the traffic controller drops egress traffic with aconstant (configurable) probability (i.e., ε).

For simplicity, our evaluation considers only the traffic pattern of the median IPsectraffic-volume echelon, that is marked by %50 in Figure 14.

8.3.2. Evaluation. Figure 22 illustrates the success rate of ID-exposing as a functionof the probability for packet loss (compare with the measurements in Section 6.1.4).We use the parameters considered in the sections above: (1) send four extra fragmentsto overflow the victim’s cache. (2) Send double-length sequences of spoofed fragmentsin the four last exhaustive search iterations. (3) Send sequences of 32 fragments dur-ing the continual deny and expose attack (the parameter m). (4) Send the ‘sequentialfragment’ for each spoofed fragment sent during meet in the middle phase. (5) doublethe length of the gap between two spoofed-fragment blocks during continual deny andexpose.

9. DEFENSE MECHANISMS

0

0.1

0.2

0.3

0.4

0.5

0.6

0.0025 0.005 0.01 0.02 0.04

Suc

cess

Rat

e

Packet-Loss Probability (log-scale)


Fig. 22. ID-exposing with concurrent traffic and un-reliable links. Each measurement is the average of 50runs, error-bars mark the standard deviations.

In this paper we presented attacks onfragmented traffic; this section investi-gates mitigations for those attacks. Sub-section 9.1 presents approaches to mit-igate fragmented traffic. Subsection 9.2evaluates techniques that modify the IP-ID selection algorithm and Subsection9.3 presents a new randomized IP-ID se-lection algorithm that is more scalable.

9.1. Mitigating Fragmented TrafficA basic mitigation for the attacks in thispaper is to avoid IP fragmentation asmuch as possible.

In TCP communication IP Fragmentation is rare since senders usually employ pathMTU discovery [Mogul and Deering 1990] and do not send larger packets than whatthe route allows. Although path MTU discovery is extensively used, this technique hassome known problems [Lahey 2000].



IPv6 takes an additional step to mitigate fragmentation, allowing only source frag-mentation; yet, fragmented packets are still likely to appear in tunnels and connec-tionless applications (e.g., running over UDP). Additionally, despite the long (32-bit)IPv6 identifier field, the IPv6 specification recommends a counter identifier [Deeringand Hinden 1998] which allows the attacks in this paper. See further discussion onIPv6 fragmentation and empirical measurements in Section 2.

Some tunnels use ‘pre-fragmentation’ methodology. Packets whose size will exceed,after encapsulation, the minimal MTU in the tunnel are first fragmented and theneach fragment is encapsulated separately; e.g., see [Cisco Systems 2007]. This tech-nique avoids sending fragmented packets over the tunnel; however, after decapsulationtraffic still appears fragmented which may allow a variant of our attacks (dependingon the network topology).

9.2. Changing IP-ID SelectionThe following countermeasures modify the IP-ID field in a packet. These proposalscan be integrated into firewalls (instead of hosts) since the IP identifier is used (only)in reassembly to match packet fragments. Hence, the sender’s firewall can modify theIP-ID field without any implications on the sender or recipient (even if the packet willbe fragmented later on the route). Note that when a packet arrives at the firewallalready in fragments, then the firewall must map its fragments (which specify thesame reassembly four tuple, see Definition 1.1) to the same identifier. Deployment onfirewalls, that are external to the core of the system, is easier. We now to discuss howfirewalls should modify the IP-ID.

The first, intuitively appealing direction seems to be using random identifiers. How-ever, this alternative is not recommended, at least for IPv4: according to the birthdayparadox, in roughly 1.2

√216 =

⌈1.2 · 28

⌉= 307 packets, there will be a repetition (since

the IPv4 ID field is 16 bits long), which would cause fragments of one packet to be‘naturally’ mis-associated with those of another packet and reduce performance.

FreeBSD supports a variant of the random identifier methodology for IPv416: whenthe host sends a packet, it assigns a random IP-ID that was not specified in one of therecent (8192) packets that were sent. Assignment does not regard the source, destina-tion or transport protocol (the other reassembly parameters). This is not the defaultconfiguration of FreeBSD which uses a globally incrementing IP-ID (initialized to zeroat boot time).

This FreeBSD solution is simple, protects from the attacks presented in this paperand also avoids the performance problem in choosing completely random IDs. However,this solution may not scale well, especially when deployed on a network gateway ratherthan a host. Since networks behind a firewall may be large, if the firewall changes theIP-ID field without regarding the source and destination of the packet, then IP-IDs forthe same source, destination and protocol may quickly repeat. Modifying this solutionto use a different ID pool for every <source, destination, protocol> tuple is simple, butmay require excessive memory since the firewall must keep for every different tuplethe recent IP-IDs that were used in its context17.

9.3. Scalable Randomized IP-ID Selection AlgorithmIn this subsection we propose an IP-ID selection algorithm designed to deploy at thefirewall of a network. Our algorithm uses a pseudo-random permutation to compute a

16FreeBSD also allows fully randomized IPv6 IDs. The IPv6 ID field is long enough so that birthday paradoxwill not significantly reduce performance.17Firewall state includes a 216 bit map that specifies which of the IP-IDs was recently used and a queue ofthe recent IP-IDs; roughly 80 KB per < sIP, dIP, protocol > tuple.



new IP-ID field when a packet leaves the network (i.e., ‘on the fly’ modification); thepermutation ensures that values do not often collide. The only state-keeping requiredis a per <source, destination, protocol> secret key and counter; hence, this solutionhas modest memory requirements.

Our goals are roughly similar to those of FreeBSD ‘random ID’ option:

— Do not frequently repeat the same IP-ID for the same <source, destination,protocol> triplet to avoid collisions (and resulting packet losses).

— The value of IP-ID in every packet should be unpredictable (pseudo-random) from alarge set of different potential IP-IDs.

Denote by η the length in bits of the IP-ID field (η = 16 in IPv4 and η = 32 in IPv6).Specifically, the approach below repeats an IP-ID at most twice in every sequence of2η−1 packets of the same <source, destination, protocol> triplet; and there are at least2η−1 possibilities for the next IP-ID at any given time.

We use a Feistel network [Luby and Rackoff 1988] to build a pseudo-random permu-tation. For every source address s, destination d and protocol p, the firewall keeps asingle key ks,d,p. Let fks,d,p be a pseudo-random function whose input and output are ηbits18. We use f as the round function for the Feistel network, πks,d,p .

When the firewall receives a packet to forward with the following reassembly tuple(s, d, p, id) the firewall updates the IP-ID field to πks,d,p(id). The construction uses aFeistel network to ensure that π is a permutation; we perform 3 rounds in the Feistelnetwork to guarantee that the result is pseudo-random (see [Luby and Rackoff 1988]).

This construction ensures that if two packets specify different reassembly tuples,then they will not collide after modifying the IP-ID, even if they specify the samesource, destination and protocol. Similarly, if two packets specify identical reassemblytuples (i.e., are fragments of one packet), then they will have the same IP-ID after themodification.

The firewall updates ks,d,p every 2η−1 packets such that an attacker will not be ableto learn the pseudo-random permutation by observing all of its values19.

10. CONCLUSIONS AND FUTURE WORKWe presented practical attacks against fragmented IPv4 and IPv6 packets. The attackscan be launched by off-path attackers, and result in packet interception, modificationand loss.

Our main conclusion is the need to improve the specifications and validation of com-mon networking protocols such as IP, following (and motivating) [Gont 2011]. We be-lieve that new protocol specifications and implementations should carefully considerwhen to resort to fragmentation. As a more immediate conclusion, we believe thatimplementations of IPv4, IPv6, IPsec and other tunnels, should be carefully testedagainst the vulnerabilities described in this paper and in particular modify their IP-ID selection algorithm.

Furthermore, it is advisable that erratas be issued for the relevant specifications.Finally, since many implementations may be impractical to fix in timely fashion, ap-propriate defenses should be added to firewalls and IDS/IPS devices.

This work leaves several directions for future work:

18Given a pseudo-random function Fk whose input and output are at least as f (e.g., Fk is a keyed hashfunction), construct fks,d,p as follows: fks,d,p (x) = Fks,d,p (x) mod 2η .19It is possible that a fragmented packet whose fragments arrive before and after changing the key will belost. This is avoided by keeping an additional small cache mapping the reassembly tuples of fragmentedpackets arriving in the short period before changing the key to the IP-ID that the firewall assigned to them.When a fragment arrives and matches one of this tuples, the IP-ID specified in the cache is used.



Fragmentation in Other Protocols. Most of this work focused on fragmentation in a tun-neling scenario. We believe that one can identify other protocols where the adversarycan ‘trigger’ and exploit fragmentation.

Large-Scale Experiments. The empirical evaluation of the attacks in this paper wereperformed in a small controlled-lab environment. It would be interesting to evaluatethe attacks over the Internet.

Analysis for Attack Parameters. In this work we presented the intuition behind the choiceof each attack parameter; some of the values that we used for empirical testing wereresult of trial and error experiments. Careful analysis may improve our results.

ACKNOWLEDGMENTS

This work is based on preliminary research by Roman Yakirevich, who identified (other) problems in han-dling of IP fragments in IPsec implementations; many thanks to Roman for his assistance, also in helpingto test our attacks. Ari Trachtenberg, Amit Klein and Charlie Kaufman gave us invaluable comments andencouragement; many thanks!

This research was supported by grant 1354/11 from the Israeli Science Foundation (ISF).

REFERENCESADVANCED NETWORK ARCHITECTURE GROUP. 2012. ANA Spoofer Project.

http://spoofer.csail.mit.edu/summary.php.ANTONATOS, S., AKRITIDIS, P., THE LAM, V., AND ANAGNOSTAKIS., K. G. 2008. Puppetnets: Misusing

Web Browsers as a Distributed Attack Infrastructure. ACM Transactions on Information and SystemSecurity 12, 2.

ARENDS, R., AUSTEIN, R., LARSON, M., MASSEY, D., AND ROSE, S. 2005. DNS Security Introduction andRequirements. RFC 4033 (Proposed Standard). Updated by RFC 6014.

AUDET, F. AND JENNINGS, C. 2007. Network Address Translation (NAT) Behavioral Requirements for Uni-cast UDP. RFC 4787 (Best Current Practice).

BAKER, F. AND SAVOLA, P. 2004. Ingress Filtering for Multihomed Networks. RFC 3704 (Best CurrentPractice).

BELLOVIN, S. M. 2002. A Technique for Counting Natted Hosts. In Internet Measurement Workshop. ACM,267–272.

BEVERLY, R., BERGER, A., HYUN, Y., AND KC CLAFFY. 2009. Understanding the Efficacy of DeployedInternet Source Address Validation Filtering. In Internet Measurement Conference, A. Feldmann andL. Mathy, Eds. ACM, 356–369.

CAIDA. 2012. Anonymized Internet Traces 2012 Dataset. http://www.caida.org/data/passive/passive_2012_dataset.xml.

CERT. 1997. Teardrop DoS Attack. http://www.cert.org/advisories/CA-1997-28.html.CISCO SYSTEMS. 2006. Configuring Dynamic ARP Inspection. http://www.cisco.com/en/US/docs/

switches/lan/catalyst4500/12.1/19ew/configuration/guide/dynarp.html.CISCO SYSTEMS. 2007. Pre-Fragmentation for IPsec VPNs. http://www.ciscosystems.cd/en/US/docs/

ios/sec_secure_connectivity/configuration/guide/sec_pre_frag_vpns.pdf.CONTA, A., DEERING, S., AND GUPTA, M. 2006. Internet Control Message Protocol (ICMPv6) for the Inter-

net Protocol Version 6 (IPv6) Specification. RFC 4443 (Draft Standard). Updated by RFC 4884.COOKE, E., JAHANIAN, F., AND MCPHERSON, D. 2005. The Zombie Roundup: Understanding, Detecting,

and Disrupting Botnets. In USENIX Workshop on Steps to Reducing Unwanted Traffic on the Internet(STRUTI). 39–44.

DEERING, S. AND HINDEN, R. 1998. Internet Protocol, Version 6 (IPv6) Specification. RFC 2460 (DraftStandard). Updated by RFCs 5095, 5722, 5871, 6437.

EHRENKRANZ, T. AND LI, J. 2009. On the State of IP Spoofing Defense. ACM Transactions on InternetTechnology (TOIT) 9, 2.

FARINACCI, D., LI, T., HANKS, S., MEYER, D., AND TRAINA, P. 2000. Generic Routing Encapsulation(GRE). RFC 2784 (Proposed Standard). Updated by RFC 2890.

FERGUSON, P. AND SENIE, D. 2000. Network Ingress Filtering: Defeating Denial of Service Attacks whichEmploy IP Source Address Spoofing. RFC 2827.



GILAD, Y. AND HERZBERG, A. 2011. Fragmentation Considered Vulnerable: Blindly Intercepting and Dis-carding Fragments. In Proc. USENIX Workshop on Offensive Technologies.

GILAD, Y. AND HERZBERG, A. 2012. Spying in the Dark: TCP and Tor Traffic Analysis. In Privacy Enhanc-ing Technologies, S. Fischer-Hubner and M. Wright, Eds. Lecture Notes in Computer Science Series,vol. 7384. Springer, 100–119.

GONT, F. 2011. Security Assessment of the Internet Protocol Version 4. RFC 6274 (Informational).GONT, F. 2012. Security Implications of Predictable Fragment Identification Values. Internet-Draft of the

IETF IPv6 maintenance Working Group (6man). Expires September 30, 2012.GREENGARD, S. 2012. The War Against Botnets. Communications of the ACM 55, 2, 16–18.HEFFNER, J., MATHIS, M., AND CHANDLER, B. 2007. IPv4 Reassembly Errors at High Data Rates. RFC

4963 (Informational).HERZBERG, A. AND SHULMAN, H. 2012a. Fragmentation Considered Poisonous. Tech. Rep.

arXiv:1205.4011.HERZBERG, A. AND SHULMAN, H. 2012b. Security of patched DNS. In ESORICS, S. Foresti, M. Yung, and

F. Martinelli, Eds. Lecture Notes in Computer Science Series, vol. 7459. Springer, 271–288.HOLLIS, K. 1997. The Rose Attack Explained.

http://digital.net/~gandalf/Rose_Frag_Attack_Explained.htm.HUSTON, G. 2004. Anatomy: A Look Inside Network Address Translators. The Internet Protocol Journal 7, 3.

http://www.cisco.com/web/about/ac123/ac147/archived_issues/ipj_7-3/anatomy.html.JOHN, W. AND TAFVELIN, S. 2007. Analysis of Internet Backbone Traffic and Header Anomalies Observed.

In Proceedings of the 7th ACM SIGCOMM, C. Dovrolis and M. Roughan, Eds. ACM, 111–116.KAUFMAN, C., HOFFMAN, P., NIR, Y., AND ERONEN, P. 2010. Internet Key Exchange Protocol Version 2

(IKEv2). RFC 5996 (Proposed Standard). Updated by RFC 5998.KAUFMAN, C., PERLMAN, R., AND SOMMERFELD, B. 2003. DoS Protection for UDP-Based Protocols. In

Proceedings of the 10th ACM Conference on Computer and Communication Security (CCS-03), V. Atluriand P. Liu, Eds. ACM Press, New York.

KENNEY, M. 1996. Ping o’ Death. http://www.insecure.org/sploits/ping-o-death.html.KENT, C. A. AND MOGUL, J. C. 1987. Fragmentation Considered Harmful. Research Report 87/3, Western

Research Lab. dec. See also abbreviated version in proceedings of ACM SIGCOMM, 390–401, 1987.KENT, S. AND SEO, K. 2005. Security Architecture for the Internet Protocol. RFC 4301 (Proposed Standard).KILLALEA, T. 2000. Recommended Internet Service Provider Security Services and Procedures. RFC 3013

(Best Current Practice).KLEIN, A. 2007. OpenBSD DNS Cache Poisoning and Multiple O/S Predictable IP ID Vulnerability. http:

//www.trusteer.com/docs/dnsopenbsd.html.KUZMANOVIC, A. AND KNIGHTLY, E. W. 2003. Low-Rate TCP-Targeted Denial of Service Attacks: the Shrew

vs. the Mice and Elephants. In SIGCOMM ’03: Proceedings of the 2003 conference on Applications,technologies, architectures, and protocols for computer communications. ACM, New York, NY, USA, 75–86.

LAHEY, K. 2000. TCP Problems with Path MTU Discovery. RFC 2923 (Informational).LI, Z., GOYAL, A., CHEN, Y., AND PAXSON, V. 2009. Automating Analysis of Large-Scale Botnet Probing

Events. In ASIACCS, W. Li, W. Susilo, U. K. Tupakula, R. Safavi-Naini, and V. Varadharajan, Eds. ACM,11–22.

LUBY, M. AND RACKOFF, C. 1988. How to Construct Pseudorandom Permutations from PseudorandomFunctions. SIAM Journal on Computing 17, 2, 373–386.

LYON, G. 2009. Nmap Network Scanning: The Official Nmap Project Guide to Network Discovery and Secu-rity Scanning. http://nmap.org/book/.

MAIER, G., SCHNEIDER, F., AND FELDMANN, A. 2011. NAT Usage in Residential Broadband Networks. InPassive and Active Measurement. Springer, 32–41.

MCCANN, J., DEERING, S., AND MOGUL, J. 1996. Path MTU Discovery for IP version 6. RFC 1981 (DraftStandard).

MILLER, I. 2001. Protection Against a Variant of the Tiny Fragment Attack (RFC 1858). RFC 3128 (Infor-mational).

MOGUL, J. AND DEERING, S. 1990. Path MTU Discovery. RFC 1191 (Draft Standard).PAXSON, V. 2001. An Analysis of Using Reflectors for Distributed Denial-of-Service Attacks. Computer Com-

munication Review 31, 3, 38–47.POSTEL, J. 1980. User Datagram Protocol. RFC 768 (Standard).POSTEL, J. 1981a. Internet Control Message Protocol. RFC 792 (Standard). Updated by RFCs 950, 4884.



POSTEL, J. 1981b. Internet Protocol. RFC 791 (Standard). Updated by RFC 1349.QIAN, Z. AND MAO, Z. M. 2012. Off-Path TCP Sequence Number Inference Attack. In IEEE Symposium on

Security and Privacy.QIAN, Z., MAO, Z. M., AND XIE, Y. 2012. Collaborative TCP Sequence Number Inference Attack - How to

Crack Sequence Number Under A Second. In ACM Computers and Communications Security Conference(ACM-CCS).

RUDERMAN, J. 2001. Same Origin Policy for JavaScript.https://developer.mozilla.org/En/Same_origin_policy_for_JavaScript.

SANFILIPPO, S. 1998. About the IP Header ID. http://www.kyuzz.org/antirez/papers/ipid.html.SAVOLA, P. 2006. MTU and Fragmentation Issues with In-the-Network Tunneling. RFC 4459 (Informa-

tional).SHANNON, C., MOORE, D., AND CLAFFY, K. C. 2002. Beyond Folklore: Observations on Fragmented Traffic.

IEEE/ACM Transactions on Networking 10, 6, 709–720.SHERWOOD, R., BHATTACHARJEE, B., AND BRAUD, R. 2005. Misbehaving TCP Receivers Can Cause

Internet-Wide Congestion Collapse. In Proceedings of the 12th ACM Conference on Computer and Com-munications Security, C. Meadows and P. Syverson, Eds. ACM Press, pub-ACM:adr, 383–392.

SRISURESH, P. AND EGEVANG, K. 2001. Traditional IP Network Address Translator (Traditional NAT).RFC 3022 (Informational).

STEVE GIBSON. 2005. ARP Poisoning Report. http://www.grc.com/nat/arp.htm.THE OPEN WEB APPLICATION SECURITY PROJECT (OWASP). 2010. OWASP Top 10 for 2010. http://

owasptop10.googlecode.com/files/OWASP%20Top%2010%20-%202010.pdf.WANG, A., HUANG, C., LI, J., AND ROSS, K. W. 2009. Queen: Estimating packet loss rate between arbitrary

internet hosts. In PAM, S. B. Moon, R. Teixeira, and S. Uhlig, Eds. Lecture Notes in Computer ScienceSeries, vol. 5448. Springer, 57–66.

ZALEWSKI, M. 2001. Strange Attractors and TCP/IP Sequence Number Analysis.http://lcamtuf.coredump.cx/newtcp/.

ZALEWSKI, M. 2003. A New TCP/IP Blind Data Injection Technique? BugTraq mailing list post,http://lcamtuf.coredump.cx/ipfrag.txt.

ZALEWSKI, M. 2005. Silence on the Wire: A Field Guide to Passive Reconnaissance and Indirect Attacks. NoStarch Press.

ZIEMBA, G., REED, D., AND TRAINA, P. 1995. Security Considerations for IP Fragment Filtering. RFC 1858(Informational). Updated by RFC 3128.


a fragmentation considered vulnerable - biuu.cs.biu.ac.il/~herzbea/security/12-03...

Documents