How do tiny-fragment and overlapping-fragment attacks use IPv4 fragmentation to slip past packet filters, and how are they blocked?
answer
- filters judge the first fragment
- 8 data bytes hold only ports
- later data overwrites earlier
- drop TCP fragments at offset 1
- RFC 1858, then RFC 3128
basics
~20 sA stateless filter judges only the first fragment. A tiny first fragment pushes TCP's flags into the second; an overlapping later fragment rewrites the header at reassembly. Filters drop TCP fragments at offset 1 and too-short first fragments (RFC 1858, RFC 3128).
solid answer
~50 sA stateless packet filter can only apply port and flag rules to the **first fragment**, because later fragments carry no transport header; it lets them pass, reasoning that without fragment zero the destination cannot reassemble. The **tiny-fragment attack** (RFC 1858) makes fragment zero carry only 8 data bytes, enough for TCP's ports and sequence number but not its flags, so a rule such as "drop SYN without ACK" never sees the flags. The **overlapping-fragment attack** sends an innocent fragment zero, then a later fragment whose offset overlaps the TCP header; if the receiver lets later data overwrite earlier data, the reassembled header is one the filter would have refused. RFC 1858's rule drops TCP fragments with offset 1; RFC 3128 showed that alone fails against two forged offset-zero fragments, so filters must also drop offset-zero TCP fragments too short to hold the header fields they check.
go deeper
Recall that only the first fragment carries the transport header, so a filter that looks at ports or flags can really judge only that fragment.
Explain both attacks step by step: a fragment zero too small to hold the TCP flags, and a later fragment whose overlapping bytes rewrite the header at reassembly.
Show you know the defences and their history: the offset-1 rule from RFC 1858, why RFC 3128 found it incomplete, and when a filter must reassemble or track fragments instead.
Weigh stateless filtering against stateful reassembly at the edge: one is cheap and evadable, the other costs memory and becomes an exhaustion target itself.
## Why fragments defeat stateless filters A **stateless packet filter** decides on each packet by itself, using fields such as addresses, the `Protocol` number, transport ports and TCP flags. Fragmentation breaks that model: - Only the fragment at **offset 0** contains the transport header. Later fragments carry raw data, so the filter has no ports or flags to match. - RFC 1858 describes the usual compromise: apply the rules to **fragment zero** and let later fragments through. The reasoning is sound for honest traffic: if fragment zero is blocked, the destination can never reassemble the datagram and discards the rest. - The receiver, not the filter, decides what the reassembled datagram looks like. The attacks below exploit the gap between what the filter judged and what the destination rebuilds. ## The tiny-fragment attack (RFC 1858) RFC 791 lets fragments be as small as **8 data bytes**. An attacker sends a TCP connection request fragmented so that: 1. Fragment zero carries 8 data bytes: the TCP **source and destination ports** and the **sequence number**. 2. The next fragment, at offset 1 (8 bytes in), carries the acknowledgement number, data offset and the **control flags** (`SYN`, `ACK` and the rest). 3. A rule such as "drop incoming TCP with `SYN` set and `ACK` clear" finds no flags in fragment zero, and does not check the later fragment, so the connection request passes. RFC 1858 noted that, as of 1995, only TCP was exposed this way, because the fields filters care about in other common transport protocols lie in their first 8 bytes. ## The overlapping-fragment attack (RFC 1858) RFC 791's example reassembly lets **newly arrived data overwrite** overlapping data already received, and no standard required an overlap-safe algorithm. The attack: 1. Fragment zero is fully legal, for example a TCP segment with `ACK` set to a permitted port. It passes the filter. 2. A later fragment, at offset 1, overlaps the TCP header and carries different flags, such as `SYN` set and `ACK` clear. It is not fragment zero, so the filter passes it. 3. The destination reassembles, the second fragment's bytes win, and it receives a connection request the filter would have rejected. Sending the fragments in the other order works against receivers that let earlier data win instead. ## The tiny overlapping fragment attack (RFC 3128) RFC 1858 proposed an **indirect** defence: drop any TCP fragment with offset exactly 1, since honest fragmentation never produces one. RFC 3128 (2001) showed a forged set that never uses offset 1: | Fragment | Offset | Content | |---|---|---| | A | 0 | A full, legal header: a connection to a permitted port | | B | 0 | Only 8 bytes: the same ports, except the destination port is a forbidden one | | C | 2 or more | The rest of the data, so reassembly cannot finish early | Depending on the receiver's reassembly, fragment B overwrites the start of A, and the result is a connection to the forbidden port. ## Defences | Rule at the filter | What it blocks | Source | |---|---|---| | Drop TCP fragments whose offset is 1 | Overlaps that reach the flags, and tiny fragments whose next piece sits at offset 1 | RFC 1858 | | Drop offset-zero TCP fragments shorter than the header fields the rules inspect | Tiny fragments, including forged offset-zero pairs | RFC 1858, RFC 3128 | | Reassemble, or track fragments, before deciding | Every variant that relies on judging fragment zero alone | Stateful filters, at a memory cost | The value behind the offset-1 rule: RFC 1858 wants any non-zero-offset TCP fragment to start at least **16 bytes** into the TCP header, so the flags always travel in fragment zero. ## Beyond filter evasion RFC 8900 lists further fragmentation attacks: - **Resource exhaustion**: many datagrams each missing one fragment fill the receiver's reassembly buffers until the timer expires; flushing buffers under pressure helps, at the cost of legitimate fragments. - **Predictable Identification values**, which let an attacker forge fragments that spoil reassembly of real datagrams. - **Intrusion-detection evasion**, where the monitor and the destination reassemble ambiguous fragments differently. IPv6 closed the overlap hole in the specification: RFC 5722 has receivers discard a datagram whose fragments overlap. In IPv4, protection depends on how the receiver and the filters are built.
- Why is dropping TCP fragments with offset 1 safe for legitimate IPv4 traffic?Offset 1 means a fragment starting 8 bytes into the transport header, which honest fragmentation produces only if an earlier fragment carried just 8 data bytes. RFC 1858 points out that would require fragmenting down to the 8-byte minimum, which only a 68-byte MTU with a 60-byte header forces; with a typical 20-byte header such a link still fits 48 data bytes. No real sender does it, so the rule costs nothing.
- Why does RFC 1858's offset-1 rule fail against the attack described in RFC 3128?The rule assumes that pushing the flags out of fragment zero creates a fragment at offset 1. A forger is not bound by that: RFC 3128 sends a complete legal fragment at offset 0, a second 8-byte fragment also at offset 0 that rewrites the destination port, and the rest at offset 2 or higher. No fragment has offset 1, so the filter must also drop too-short offset-zero TCP fragments.
- How can fragments hurt an IPv4 host without slipping anything past a filter?Reassembly is state in an otherwise stateless protocol. An attacker sends many datagrams that each lack one fragment; the receiver holds every partial datagram until its reassembly timer expires, which RFC 1122 recommends setting between 60 and 120 seconds. Buffers fill and legitimate fragmented traffic is starved. RFC 8900 suggests flushing reassembly buffers when necessary, accepting the loss of some legitimate fragments.
saying these in an interview costs you the question
- A filter that checks the first fragment has checked the whole datagram.
- Every IPv4 stack must discard overlapping fragments by standard.
- Dropping TCP fragments at offset 1 stops every fragmentation attack.
- Tiny-fragment attacks hide UDP ports just as easily as TCP flags.
- Fragment attacks need the attacker to control a router on the path.