1. What is IP Fragmentation?
IP fragmentation is the process of dividing a large IPv4 datagram into multiple smaller IP fragments so that the fragments can be transmitted across a network whose Maximum Transmission Unit (MTU) is smaller than the size of the original datagram.
For example:
Original IPv4 Datagram
+---------------------------------------------+
| Large IP Datagram |
+---------------------------------------------+
↓ Fragmentation
+------------------+ +------------------+ +------------------+
| Fragment 1 | | Fragment 2 | | Fragment 3 |
| | | | | |
+------------------+ +------------------+ +------------------+
The fragments together represent the original IP datagram.
Primary source: Wenliang Du, Computer & Internet Security: A Hands-on Approach, 2nd ed., material on The Internet Protocol (IP) and Attacks — IP Fragmentation.
2. Why is Fragmentation Needed?
Different networks can support different maximum packet sizes.
This maximum frame/packet size is associated with the network's:
MTU = Maximum Transmission Unit
For example, Du's material discusses Ethernet MTU values such as:
Ethernet MTU ≈ 1500 bytes
If an IPv4 datagram is larger than the MTU of the outgoing network, fragmentation may be required.
Conceptually:
Large IP Datagram
|
| larger than MTU
v
+--------------------+
| Router / IP layer |
+--------------------+
|
v
Fragmentation
|
+--------+
| |
v v
Fragment 1 Fragment 2 ...
Source: Wenliang Du, The Internet Protocol (IP) and Attacks, section "Why do we need fragmentation?" and IP fragmentation material.
3. Where Does Fragmentation Happen?
For IPv4, an IP datagram can be fragmented when it encounters a network whose MTU cannot accommodate the datagram.
The important idea is:
Large datagram
|
v
Network with smaller MTU
|
v
IP fragmentation
The resulting fragments are treated as IP packets and can be routed toward the destination.
Du's material states that each fragment has the same general IP-header format as an IP datagram and that the fragments are routed independently.
Source: Wenliang Du, The Internet Protocol (IP) and Attacks, IP Fragmentation, pp. 5–6 of the published lecture material.
4. Important IPv4 Fragmentation Fields
IPv4 uses three important pieces of information to identify and position fragments:
Identification
Flags
Fragment Offset
These fields allow the destination to determine:
-
Which fragments belong together
-
Where each fragment's data belongs
-
Whether more fragments are expected
5. Identification Field
The Identification (ID) field identifies the original IP datagram.
All fragments belonging to the same original datagram use the same identification value.
Example:
Original Datagram
ID = 1234
Fragment 1 → ID = 1234
Fragment 2 → ID = 1234
Fragment 3 → ID = 1234
Therefore:
Same ID
+
Same source
+
Same destination
+
Same protocol
can be used to associate fragments with the same original datagram during reassembly.
The key point from Du's material is:
Fragments belonging to the same IP datagram carry the same identification value.
Source: Du, IP Fragmentation, "IDENT: unique number to identify an IP datagram."
6. Fragment Offset
The Fragment Offset tells the receiver where the fragment's payload belongs within the original datagram.
The value stored in the IPv4 header is not the offset in bytes directly.
Instead:
Actual offset=Fragment Offset field×8
Therefore:
Offset field = 0
Actual offset = 0 bytes
Offset field = 50
Actual offset = 50 × 8 = 400 bytes
This is why fragment offsets are multiples of 8 bytes.
Source: Du, IP Fragmentation, "FRAGMENT OFFSET", and exercise N3.2.
7. More Fragments (MF) Flag
The IPv4 More Fragments (MF) flag indicates whether additional fragments follow.
Conceptually:
Fragment 1
MF = 1
↓
More fragments follow
Fragment 2
MF = 1
↓
More fragments follow
Fragment 3
MF = 0
↓
This is the last fragment
The last fragment is therefore identified by:
MF = 0
Du explains why the MF flag is necessary:
The Total Length field in each fragment describes the size of that fragment, not the size of the complete original datagram.
Therefore, without the last-fragment indication, the receiver would not know the original datagram's final boundary.
Source: Du, IP Fragmentation, "FLAGS" and exercise N3.3.
8. Don't Fragment (DF) Flag
IPv4 also contains a Don't Fragment (DF) flag.
The purpose is to indicate that the datagram should not be fragmented.
Conceptually:
DF = 1
|
v
Do not fragment
If a packet is too large for the next network and fragmentation is prohibited, the packet cannot simply be fragmented there.
Nmap's network-scanning material also discusses the DF bit, explaining that when a packet is too large and the DF bit is set, the packet is dropped and ideally an ICMP "destination unreachable, fragmentation needed" response is returned.
Source: Gordon Lyon, Nmap Network Scanning, OS Detection / IP Don't Fragment bit (DF).
9. Example of Fragmentation
Du provides an example using:
Header + 400 + 400 + 400
Suppose the original IP payload is divided into three fragments, each carrying 400 bytes.
The fragments use:
Fragment 1:
Offset = 0
MF = 1
Fragment 2:
Offset = 400 / 8 = 50
MF = 1
Fragment 3:
Offset = 800 / 8 = 100
MF = 0
Conceptually:
Original data:
0 1200
|----------------------------------------|
| 400 | 400 | 400 |
| Fragment 1 | Fragment 2 | Frag 3 |
| | | |
The receiver reconstructs the original ordering using the fragment offsets.
Source: Du, IP Fragmentation, example "Header + 400 + 400 + 400."
10. Fragment Reassembly
Fragmentation occurs so that smaller fragments can travel through the network.
Eventually, the fragments must be reassembled into the original IP datagram.
Du's material states that:
All fragments of a datagram are assembled before the datagram is delivered to the layers above IP.
The important architectural point is:
Fragment 1
|
Fragment 2
|
Fragment 3
|
v
+----------------------+
| Destination host |
| |
| IP reassembly |
+----------------------+
|
v
Original IP Datagram
|
v
Transport layer
The material specifically states that reassembly occurs at the destination, rather than at intermediate routers.
Source: Du, IP Fragmentation, "How are IP fragments reassembled?"
11. Fragment Reassembly Timer
Reassembly cannot wait indefinitely for a missing fragment.
Du's material states that IP reassembly uses a timer.
Conceptually:
Fragment 1 ──┐
Fragment 2 ──┤
├── waiting for missing fragment
Fragment 3 ──┘
|
v
Timer
|
+---------+---------+
| |
fragment arrives timer expires
| |
v v
reassemble discard
If the timer expires while fragments are still missing, the fragments are discarded.
Source: Du, IP Fragmentation, "IP reassembly uses a timer."
12. Why Fragmentation Creates Security Problems
Fragmentation creates a stateful reassembly problem.
The receiver has to remember partial information until all necessary fragments arrive.
That raises several security questions.
Du explicitly identifies these malicious situations:
Missing fragments
Fragment 1
Fragment 2
Fragment 3 → never arrives
The system must decide how long to retain the partial packet.
Overlapping fragments
Two fragments may describe overlapping portions of the original datagram.
Fragment 1:
|----------------------|
Fragment 2:
|----------------------|
The overlap creates ambiguity about what the reconstructed packet should contain.
Oversized reassembled packet
The fragments may describe a reassembled packet larger than the maximum legal IP packet size.
Du explicitly lists these as malicious situations that an IP implementation must consider.
Source: Du, IP Fragmentation, security questions immediately following reassembly.
13. Important Constraint: Maximum IPv4 Packet Size
The IPv4 Total Length field is 16 bits.
Therefore the maximum value representable is:
216−1=655352^{16}-1 = 65535
bytes.
Thus:
Maximum IPv4 packet size = 65,535 bytes
Du explicitly asks whether it is possible to spoof a packet whose apparent total size exceeds 65,535 bytes and uses this boundary when discussing fragmentation attacks.
Source: Du, exercise N3.5, "The Internet Protocol (IP) and Attacks."
14. Fragmentation Attack Concept
A fragmentation attack attempts to exploit the rules or implementation of IP fragmentation/reassembly.
The attack can target:
Fragment parsing
↓
Offset calculation
↓
Length calculation
↓
Reassembly
↓
Memory management
A vulnerable implementation may incorrectly handle:
-
Very large apparent packets
-
Invalid offsets
-
Overlapping fragments
-
Missing fragments
-
Fragment reassembly boundaries
The result can be:
Malformed fragments
↓
Incorrect reassembly
↓
Implementation error
↓
Crash / denial of service
Primary source: Du, "The Internet Protocol (IP) and Attacks", discussion of malicious situations in IP fragmentation.
15. Ping of Death
The Ping of Death is a fragmentation-based denial-of-service attack discussed in Du's IP-attack material.
The basic idea is to construct fragments which, when reassembled, describe an IP packet whose apparent total size exceeds the normal maximum IP packet size.
The maximum legal IPv4 packet length is:
65,535 bytes
The attack exploits implementations that incorrectly handled such oversized reassembled packets.
Conceptually:
Fragment 1
|
Fragment 2
|
Fragment 3
|
v
+----------------------------+
| Reassembled packet |
| |
| > 65,535 bytes |
+----------------------------+
|
v
Vulnerable IP stack
|
v
Crash / DoS
The important point is that the malicious condition is created during reassembly, rather than necessarily being present as an ordinary single oversized packet on the wire.
Du's exercises explicitly ask students to create two packets to emulate a Ping-of-Death attack.
Source: Wenliang Du, The Internet Protocol (IP) and Attacks, exercise N3.10.
16. Teardrop Attack
The Teardrop attack exploits malformed overlapping IP fragments.
Du gives the attack structure explicitly.
The first fragment has:
Offset = 0
Payload size = N
MF = 1
A second fragment is constructed so that:
MF = 0
and:
second offset + second payload size < N
Therefore the second fragment lies partly or entirely within the data range described by the first fragment.
Conceptually:
Fragment 1
Offset 0
|------------------------------------|
| |
| Fragment 1 |
| |
|------------------------------------|
Fragment 2
|------------------|
| Fragment 2 |
|------------------|
The two fragments overlap.
A vulnerable operating system's IP reassembly logic may mishandle this overlap.
Du's material states that when the operating system attempts to combine these fragments, the system can crash.
Source: Du, IP Fragmentation, "Attack 2: TearDrop."
17. Ping of Death vs Teardrop
These attacks exploit different fragmentation conditions.
| Attack | Malicious condition | Main problem |
|---|---|---|
| Ping of Death | Reassembled packet exceeds legal maximum size | Oversized reassembled packet |
| Teardrop | Fragment ranges overlap | Incorrect/ambiguous reassembly |
Ping of Death
Fragments
↓
Total reconstructed size > 65,535
↓
Implementation failure
Teardrop
Fragments
↓
Overlapping offsets/ranges
↓
Incorrect reassembly handling
↓
Implementation failure
Source: Du, The Internet Protocol (IP) and Attacks, IP fragmentation attack material and exercises N3.9–N3.10.
18. Fragmentation and Firewalls
Fragmentation creates another security problem: a firewall may inspect packets individually.
Suppose a firewall's rule depends on the TCP header.
A normal packet might look like:
+-------------+----------------+
| IP header | TCP header |
+-------------+----------------+
But fragmentation can split the IP payload:
Fragment 1:
+-------------+----------+
| IP header | TCP part |
+-------------+----------+
Fragment 2:
+-------------+----------+
| IP header | TCP rest |
+-------------+----------+
If a firewall examines only the first fragment or does not properly reconstruct the original packet, the TCP header may not be fully available when the filtering decision is made.
Du explicitly identifies this as a security issue.
Source: Du, "Overlapping attacks against firewalls" and "Tiny Fragment Attack."
19. Tiny Fragment Attack
Du describes a Tiny Fragment Attack based on the assumption that a firewall only examines the packet with:
Fragment Offset = 0
The attacker fragments the packet so that important portions of the TCP header are pushed outside the first fragment.
Conceptually:
Original packet:
IP Header | TCP Header | Data
^^^^^^^^^^^
firewall wants
to inspect
After fragmentation:
Fragment 1:
IP Header | TCP part
Fragment 2:
IP Header | TCP remainder | Data
If the firewall expects to find the complete TCP header in the first fragment, the filtering decision may fail.
Source: Du, "Overlapping attacks against firewalls", including Tiny Fragment Attack.
20. Overlapping Fragment Attack
Overlapping fragments can also be used against firewalls and IDSs.
The fundamental issue is:
The firewall and the destination host may not interpret the fragments in exactly the same way.
Conceptually:
Firewall interpretation:
Fragment A
|--------------------|
Fragment B
|-------------|
Destination interpretation:
Fragment A
|--------------------|
+
Fragment B
|-------------|
Different fragment-reassembly behavior can potentially result in different reconstructed packets.
Du identifies overlapping fragments as a malicious situation and discusses overlapping attacks against firewalls.
21. Nmap and IP Fragmentation
Nmap contains an important practical discussion of IP fragmentation.
The official Nmap documentation explains that fragmented packets can cause problems for packet filters and intrusion-detection systems because the filtering device may need to reassemble the fragments.
Nmap describes a -f option that causes probes to be sent as small IP fragments.
Conceptually:
Normal probe:
+-------------+--------------------------+
| IP header | TCP header + data |
+-------------+--------------------------+
Fragmented probe:
+-------------+--------+
| IP header | TCP |
+-------------+--------+
+-------------+--------+
| IP header | TCP |
+-------------+--------+
+-------------+--------+
| IP header | data |
+-------------+--------+
The official documentation states that Nmap normally places eight bytes or fewer of data into each fragment when -f is used once.
Source: Gordon Lyon, Nmap Network Scanning, "Firewall/IDS Evasion and Spoofing" — Fragment packets.
22. Why Fragmentation Can Bypass Simple Filtering
Suppose a firewall expects:
Fragment 1
↓
IP header
+
complete TCP header
But the TCP header has been split between fragments.
The firewall may not see the transport information it expects in the first fragment.
Firewall sees:
Fragment 1
+-----------+---------+
| IP header | TCP |
+-----------+---------+
^
incomplete
Actual complete TCP header:
+---------------------------+
| TCP header |
+---------------------------+
^
split between
fragments
Nmap explicitly discusses this as a reason fragmented packets can cause problems for packet filters.
Source: Nmap, "Bypassing Firewall Rules — Fragmentation."
23. Fragment Reassembly Is Resource Intensive
Fragmentation creates additional state and processing.
The system may have to:
Receive fragment
↓
Identify datagram
↓
Store fragment
↓
Track offset
↓
Wait for additional fragments
↓
Reassemble
↓
Validate resulting packet
This is particularly important for IDS/firewall systems.
Nmap explicitly notes that:
Fragment assembly can be resource intensive.
Source: Gordon Lyon, Nmap Network Scanning, Subverting Intrusion Detection Systems — Fragment packets.
24. Out-of-Order Fragments
Fragments do not necessarily have to arrive in the original order.
For example:
Sent:
Fragment 1
Fragment 2
Fragment 3
Received:
Fragment 3
Fragment 1
Fragment 2
The receiver uses the fragment identification and offset information to determine where each fragment belongs.
Nmap discusses fragmented packets and notes that fragment handling can become complicated when packets are received in unusual patterns.
Source: Nmap, fragmentation discussion in Chapter 10 / Firewall and IDS evasion.
25. Missing Fragments
Consider:
Fragment 1
Fragment 2
Fragment 3
but Fragment 2 never arrives.
The receiver cannot reconstruct the complete original datagram.
According to Du:
Fragments arrive
↓
Reassembly starts
↓
Missing fragment
↓
Timer runs
↓
Timer expires
↓
Fragments discarded
This behavior is important because an attacker can deliberately create incomplete fragment sets.
Source: Du, IP Fragmentation, reassembly timer discussion.
26. Fragment Overlap
Consider two fragments:
Fragment 1:
Offset = 0
Length = 1000
Range:
0 ------------------ 1000
Fragment 2:
Offset = 800
Length = 500
Range:
800 -------- 1300
The ranges overlap:
0 ------------------ 1000
800 ---------------- 1300
^^^^^^^^
overlap
An IP implementation must decide how to handle this.
Du explicitly identifies overlapping fragments as a malicious situation.
The Teardrop attack exploits this type of abnormal fragment arrangement.
27. Fragmentation Attack Categories
From the material in Du and the fragmentation discussion in Nmap, fragmentation-related attacks can be understood in several ways.
Oversized Reassembly
Fragments
↓
Reassembled size > maximum
↓
Implementation vulnerability
Example: Ping of Death
Overlapping Fragments
Fragments
↓
Overlapping byte ranges
↓
Reassembly ambiguity/error
↓
Potential crash
Example: Teardrop
Fragmented Header / Filtering Evasion
TCP header
↓
split across fragments
↓
firewall/IDS sees incomplete information
↓
filtering ambiguity
Examples: Tiny Fragment Attack and overlapping firewall attacks.
Incomplete Fragment Set
Fragment 1
Fragment 2
Fragment 3 → missing
↓
reassembly state retained
↓
timer / resource consumption
This is one of the malicious situations Du explicitly asks an implementation to consider.
28. IPv4 Fragmentation Fields — Revision Table
| Field | Purpose |
|---|---|
| Identification | Associates fragments with the same original datagram |
| DF | Indicates that the datagram should not be fragmented |
| MF | Indicates whether additional fragments follow |
| Fragment Offset | Identifies where fragment data belongs in the original datagram |
| Total Length | Length of the individual fragment |
| Protocol | Identifies the upper-layer protocol carried by the IP payload |
Source: Du, IP Fragmentation and IP header material.
29. Fragmentation Example
Suppose:
Original payload = 1200 bytes
Fragment payloads:
Fragment 1 = 400 bytes
Fragment 2 = 400 bytes
Fragment 3 = 400 bytes
Then:
Fragment 1
Offset = 0
MF = 1
Fragment 2
Offset = 400 / 8
= 50
MF = 1
Fragment 3
Offset = 800 / 8
= 100
MF = 0
Reconstruction:
Offset 0
|
v
+---------+
| Frag 1 | 400 bytes
+---------+
Offset 400
|
v
+---------+
| Frag 2 | 400 bytes
+---------+
Offset 800
|
v
+---------+
| Frag 3 | 400 bytes
+---------+
Result:
0 → 400 → 800 → 1200
Source: Du, IP fragmentation example.
30. Ping of Death — Mental Model
Fragmented IP packet
|
+---------+---------+
| | |
v v v
Fragment Fragment Fragment
\ | /
\ | /
+-------+-------+
|
v
Reassembly
|
v
Apparent packet size
> 65,535
|
v
Vulnerable IP stack
|
v
DoS
Source: Du, exercise N3.10 and IP fragmentation attack material.
31. Teardrop — Mental Model
Fragment 1
Offset = 0
Length = N
MF = 1
+-------------------------------+
| |
| Fragment 1 |
| |
+-------------------------------+
Fragment 2
Offset + Length < N
+----------------+
| Fragment 2 |
+----------------+
↑
|
overlaps
Fragment 1
Then:
Malformed fragments
↓
Reassembly
↓
Overlapping ranges
↓
Vulnerable implementation
↓
Crash / DoS
Source: Du, Attack 2: TearDrop.
32. Ping of Death vs Teardrop vs Tiny Fragment
| Attack | Exploited condition | Target |
|---|---|---|
| Ping of Death | Reassembled size exceeds IPv4 maximum | IP-stack implementation |
| Teardrop | Overlapping fragment ranges | IP reassembly implementation |
| Tiny Fragment Attack | Important transport header split across fragments | Firewall filtering |
| Overlapping firewall attack | Different interpretations of overlapping fragments | Firewall / IDS / destination interpretation |
33. Fragmentation and Security — Core Idea
Normal fragmentation:
Large packet
↓
Split into valid pieces
↓
Transmit
↓
Reassemble
↓
Original packet
Malicious fragmentation:
Craft unusual fragments
↓
Exploit parser/reassembler
↓
Incorrect state
↓
Incorrect reconstruction
↓
Crash / DoS / filtering bypass
The fundamental security boundary is therefore:
Fragment creation
↓
Fragment transmission
↓
Fragment storage
↓
Fragment reassembly
↓
Transport-layer delivery
Every step must handle malformed input correctly.
34. Netfilter / iptables and Fragments
Purdy's Linux iptables Pocket Reference provides an especially useful practical detail.
The IP protocol match includes:
-f
which matches:
the second or further fragment of a packet that has undergone fragmentation.
Purdy explains that connection tracking performs automatic defragmentation, which is why the fragment match is not often useful when connection tracking is being used.
Conceptually:
Fragments
|
v
Connection Tracking
|
| automatic defragmentation
v
Reassembled packet
|
v
Further processing
Without connection tracking, fragment-specific filtering can be performed using the fragment match.
Source: Gregor N. Purdy, Linux iptables Pocket Reference, Internet Protocol match options, Table 36.
35. Why This Matters for Firewall Design
Suppose a firewall rule examines:
TCP destination port
But the packet is fragmented.
The first fragment may contain:
IP Header
+
only part of TCP header
while a later fragment contains additional TCP header information.
Therefore a filtering device has to consider fragment reassembly when making decisions based on transport-layer information.
This is exactly the type of issue discussed by Du and Nmap.
36. Kurose & Ross — Edition Note
There is an important issue with the 8th edition.
The Kurose & Ross 8th-edition IP material states that detailed IP fragmentation was removed from the main 8th-edition textbook.
Their official IP Wireshark Lab says:
"we've removed the topic of IP fragmentation from the 8th edition of our textbook"
and directs readers to the earlier edition for detailed fragmentation material.
Therefore, for these notes:
Kurose & Ross 8th ed.
↓
IP architecture / IPv4 context
↓
Not used as the detailed source for fragmentation mechanics
The detailed fragmentation information here comes from Wenliang Du, with Nmap and Purdy providing practical security/filtering context.
Source: Kurose & Ross, Wireshark Lab: IP v8.1, 8th-edition supplement.
37. Nmap — Role in Fragmentation
Nmap is useful for understanding how fragmentation interacts with network security devices.
Its official documentation explains:
Fragmentation
↓
Packet filters may need
to reassemble fragments
↓
Additional complexity
↓
Potential filtering problems
Nmap also discusses:
-
tiny fragments
-
fragment offsets
-
MTU
-
fragmented TCP probes
-
IDS/firewall handling
-
fragment reassembly
-
overlapping fragments
Sources:
-
Nmap, "Bypassing Firewall Rules — Fragmentation".
-
Nmap, "Subverting Intrusion Detection Systems — Fragment packets".
38. What Each of Your Five Books Contributes
| Book | Fragmentation contribution |
|---|---|
| Kurose & Ross 8th ed. | IPv4/network-layer context; detailed fragmentation removed from 8th-edition main text |
| Lyon — Nmap | Fragmented packets, MTU, DF, fragment offsets, firewall/IDS implications |
| Forshaw — Attacking Network Protocols | General network-protocol attack/analysis perspective; not used here for named fragmentation attacks |
| Purdy — iptables Pocket Reference | Linux iptables handling of fragments and connection-tracking defragmentation |
| Wenliang Du — Computer & Internet Security | Detailed IPv4 fragmentation, reassembly, malformed fragments, Ping of Death, Teardrop, firewall fragmentation attacks |
39. Things You Should Memorize
IP FRAGMENTATION
================
Why?
Packet > outgoing network MTU
Important fields:
Identification
Flags
Fragment Offset
Total Length
Fragment Offset:
Actual offset = field × 8
MF:
MF = 1 → more fragments
MF = 0 → last fragment
DF:
DF = 1 → do not fragment
Reassembly:
Done at destination
Uses a timer
Missing fragments → discard after timer expires
Maximum IPv4 packet:
65,535 bytes
PING OF DEATH
=============
Fragments
↓
Reassembled packet > 65,535 bytes
↓
Vulnerable implementation
↓
Crash / DoS
TEARDROP
========
Overlapping IP fragments
↓
Invalid / ambiguous reassembly
↓
Vulnerable implementation
↓
Crash / DoS
TINY FRAGMENT
=============
TCP header split across fragments
↓
Firewall sees incomplete header
↓
Filtering can be bypassed
OVERLAPPING FIREWALL ATTACK
===========================
Overlapping fragments
↓
Firewall and destination may interpret
fragments differently
↓
Filtering ambiguity
NETFILTER / IPTABLES
====================
-f
↓
matches second or later fragments
Connection tracking
↓
automatic defragmentation
40. Final Mental Model
The entire topic can be reduced to:
IPv4 DATAGRAM
|
|
Size > MTU
|
v
FRAGMENTATION
|
+--------------+--------------+
| | |
v v v
Fragment 1 Fragment 2 Fragment 3
| | |
+--------------+--------------+
|
v
NETWORK
|
v
DESTINATION
|
v
REASSEMBLY
|
+----------+----------+
| | |
v v v
Valid Missing Malformed
fragments fragment fragments
| | |
v v v
Original Timer Attack
datagram expires
| |
v v
Discard Crash / DoS
The most important security insight is:
Fragmentation itself is legitimate. The vulnerability comes from incorrect handling of fragmented input.
That is why Ping of Death, Teardrop, and fragmentation-based firewall/IDS evasion are fundamentally different attacks even though they all exploit the IP fragmentation mechanism.
41. Exact Sources
Wenliang Du
Wenliang Du, Computer & Internet Security: A Hands-on Approach, 2nd ed.
Primary source for this note
The Internet Protocol (IP) and Attacks
Relevant material:
-
Why do we need fragmentation?
-
Fragmentation fields
-
Identification
-
Fragment Offset
-
Flags / MF
-
IP fragment reassembly
-
Reassembly timer
-
Malicious fragmentation situations
-
Denial-of-Service attack using abnormal fragment offsets
-
TearDrop attack
-
Overlapping attacks against firewalls
-
Tiny Fragment Attack
-
Exercises N3.1–N3.10
The author's accompanying exercise document explicitly asks:
N3.1 Why do we need fragmentation?
N3.2 Why is fragment offset multiplied by 8?
N3.3 How does the receiver know which fragment is last?
N3.4 Can total original size be known before last fragment?
N3.5 Can a packet larger than 65,535 bytes be spoofed?
N3.9 Create packets to emulate Teardrop.
N3.10 Create packets to emulate Ping-of-Death.
This is a direct source for the fragmentation and attack material in these notes.
Gordon Lyon — Nmap
Gordon Lyon, Nmap Network Scanning: The Official Nmap Project Guide to Network Discovery and Security Scanning, Nmap Project, 2009
Relevant sections:
Firewall/IDS Evasion and Spoofing
Fragment packets
Covers:
-
IP packet fragmentation
-
-f -
--mtu -
fragment size
-
fragment offsets
-
firewall/IDS handling
-
connection tracking
-
defragmentation
Bypassing Firewall Rules
Fragmentation
Covers:
-
firewall handling of fragments
-
reassembly
-
tiny fragments
-
overlapping fragments
-
different fragment paths
Subverting Intrusion Detection Systems
Fragment packets
Covers:
-
fragment assembly
-
resource requirements
-
unusual fragment behavior
-
IDS difficulties
OS Detection
IP Don't Fragment bit (DF)
Covers:
-
DF bit
-
oversized packets
-
fragmentation-needed ICMP response
Gregor N. Purdy
Gregor N. Purdy, Linux iptables Pocket Reference, O'Reilly Media, 2004
Relevant source:
Internet Protocol Match Options — Table 36
The -f / --fragments match identifies:
Second or further fragment
of a fragmented packet
Purdy also explains that:
Connection tracking
↓
Automatic defragmentation
This is directly relevant to how Linux packet filtering interacts with fragmented IPv4 packets.
J. F. Kurose & K. W. Ross
James F. Kurose and Keith W. Ross, Computer Networking: A Top-Down Approach, 8th ed., Pearson, 2020
The 8th edition does not contain the detailed IPv4-fragmentation discussion that appeared in previous editions.
The authors' official Wireshark Lab: IP v8.1 explicitly says that IPv4 fragmentation was removed from the 8th-edition textbook and points readers to the 7th-edition material.
Therefore:
Kurose & Ross 8th
↓
IPv4/network-layer background
Du
↓
Detailed fragmentation + attacks
Nmap
↓
Fragmentation + firewall/IDS behavior
Purdy
↓
Linux/iptables fragment handling
Source: Kurose & Ross, official 8th-edition IP Wireshark Lab.