IP Fragmentation Lab – Overview and Setup
This lab focused on exploring the behavior and structure of IP fragmentation. The exercises require close analysis of fragmented IP packets using either Wireshark or tcpdump.
Exercise 1 – Analyzing the First Two IP Fragments
Look at the first two records. They are related fragments and are the only ones associated with this pair of fragments. What do you think happens when they are sent?
After identifying the first two packets as related IP fragments, I needed to confirm whether the full set of fragments was present. I used the following tcpdump command to examine fragmentation details more closely:
Both packets showed more fragments flag set (flags [+]), but neither was marked as the last fragment (with offset and MF flag = 0). This means that the packet reassembly could not be completed, as at least one fragment was missing from the set.
To see how the system reacts to this failed reassembly, I looked for an ICMP error message that might be triggered by this condition. I ran:
Sure enough, shortly after the two fragment packets, I found an ICMP “Time Exceeded – Fragment Reassembly Time Exceeded” message. This type of ICMP error is sent when the receiver cannot finish reassembling a fragmented IP packet within the allowed time window.
The error response appeared in record 14, indicating the network’s handling of incomplete fragmentation and how it alerts the sender when reassembly fails.
Why didn’t records 3 and 4 (a different pair of related fragments) generate the same type of ICMP error message?
To answer this, I examined the fragmentation details of records 3 and 4. Although they represent another pair of related fragments, neither one has a fragment offset of 0. The packet corresponding to the third record has an offset of 1480. This is important because only the first fragment (offset 0) contains the protocol field, which identifies the embedded protocol (like ICMP, TCP, etc.).
Without that first fragment, the receiving system can’t determine what protocol the original datagram was using. As a result, it doesn’t send an ICMP “Fragment Reassembly Time Exceeded” message, since it lacks the context needed to generate one.
Exercise 2 – Identifying Fragment Overlap and Suspicious Packet Behavior
In this exercise, I analyzed packets 5, 6, and 7, which appeared to be related fragments. At first glance, they looked like they might belong to a single fragmented IP packet, but something unusual stood out.
Fragment Overlap Issue
Packets 5 and 6 both have a fragment offset of 0, meaning they are both marked as the first fragment. However, they have different total lengths, which would cause them to overlap if processed together. Packet 7 appears to be the final fragment in this set, but it overlaps with packet 6 based on its offset and length.
This kind of fragment overlap can be interpreted differently depending on the operating system, making it a potential tactic for evasion or exploitation. Some systems may discard the entire packet, while others may accept whichever version arrives first or last.
Suspicious IP Options
I also noticed that all three packets contained IP options, which are uncommon in typical traffic and can signal malicious activity. Specifically, the packets include type 131 IP options, which are often used to route packets through specific network paths. This could be an attempt to bypass firewalls, intrusion detection systems, or route traffic through an attacker-controlled device.
Exercise 3 – Spotting Crafted Fragment Sets
What makes you believe that the set of fragments in records 8–13 (IP ID 31026) have been crafted? Identify five abnormal traits.
Upon analyzing these packets, it became clear that these fragments were likely intentionally crafted rather than the result of legitimate fragmentation. I identified several suspicious traits that support this conclusion:
- The second packet does not have a More Fragment flag which would indicate that this is the last packet of this fragment train when in fact there are more packets that are part of this train following this packet.
- The second to last packet does not have the same payload size a nd total length size as the fragments before him. All fragments should be the exact same size outside of the last fragment.
- The 4th and 5th fragments are overlapping (they have the same offset of 24).
- All the packets have payloads of size 8 and 16 bytes and total length of 28 and 36 bytes. There should be no MTU that small and causing fragmentation to occur.
- There is a fragment missing before the last fragment. We go from offset 24 to offset 48 while the payload size is only of 8 bytes. We should have a fragment with an offset 32 that is missing.
Exercise 4 – Filtering for ICMP Echo Request Fragments
In this exercise, I used a tcpdump filter to try and identify all fragments related to ICMP echo requests (type 8). The command provided was:
Why don’t we see all the fragments associated with the echo requests ?
Only fragments with an offset of 0 include the ICMP header (which contains the type field). Subsequent fragments—those with a non-zero offset—contain only payload data, not the protocol header. As a result, the filter doesn’t match those fragments, because the ICMP type field isn’t present in their portion of the packet.
To capture all fragments of a given ICMP echo request, I would need to filter by IP ID (the identifier field) rather than by protocol fields. That’s because all fragments of a packet share the same IP ID, allowing me to track the complete set regardless of whether they include the ICMP header.
