IP Fragmentation Attacks - Fragmentation Process

Fragmentation Process

IP datagrams are encapsulated in datalink frames, and, therefore, the link MTU affects larger IP datagrams and forces them to be split into pieces equal to or smaller than the MTU size.

This can be accomplished by several approaches:

• To set the IP datagram size equal or smaller than the directly attached medium (in our case 802.3) and delegate all further fragmentation of datagrams to routers, meaning that routers decide if the current datagram should be re-fragmented or not. This offloads a lot of work on to routers, and can also result in packets being segmented by several IP routers one after another, resulting in very peculiar fragmentation.
• To preview all links between source and destination and select the smallest MTU in this route, assuming there is a unique route. This way we make sure that the fragmentation is done by the sender, using a packet-size smaller than the selected MTU, and there is no further fragmentation en-route. This solution, called Path MTU Discovery, allows a sender to fragment/segment a long Internet packet, rather than relying on routers to perform IP-level fragmentation. This is more efficient and more scalable. It is therefore the recommended method in the current Internet. The problem with this approach is that each packet is routed independently; they may well typically follow the same route, but they may not, and so a probe packet to determine fragmentation may follow a path different from paths taken by later packets.

Three fields in the IP header are used to implement fragmentation and reassembly. The "Identification", "Flags" and "Fragment Offset" fields.

Flags:

A 3 bit field which says if the datagram is a part of a fragmented data frame or not.

Bit 0: reserved, must be zero (unless datagram is adhering to RFC 3514)

Bit 1: (AF) 0 = May Fragment, 1 = Don't Fragment.

Bit 2: (AF) 0 = Last Fragment, 1 = More Fragments.

Fragment Offset specifies the fragment's position within the original Datagram, measured in 8-byte units.

Accordingly, every fragment except the last must contain a multiple of 8 bytes of data. It is obvious that Fragment Offset can hold 8192 (2^13) units but the datagram can't have 8192 * 8 = 65536 bytes of data because "Total Length" field of IP header records the total size including the header and data. An IP header is at least 20 bytes long, so the maximum value for "Fragment Offset" is restricted to 8189, which leaves room for 3 bytes in the last fragment.

Because an IP internet can be connectionless, fragments from one datagram may be interleaved with those from another at the destination. The "Identification field" uniquely identifies the fragments of a particular datagram.

The source system sets "Identification" field in each datagram to a unique value for all datagrams which use the same source IP address, destination IP address, and "Protocol" values, for the lifetime of the datagram on the internet. This way the destination can distinguish which incoming fragments belong to a unique datagram and buffer all of them until the last fragment is received. The last fragment sets the "More Fragment" bit to 0 and this tells the receiving station to start reassembling the data if all fragments have been received.

The following is a real-life fragmentation example:

The following was obtained using the Ethereal protocol analyzer to capture ICMP echo request packets. To simulate this open up a terminal and type ping ip_dest -n 1 -l 65000.

The results are as follows:

The first packet details:

Frame 1 (1514 bytes on wire, 1514 bytes captured) Ethernet II, Src: OmronTat_00:00:00 (00:00:0a:00:00:00), Dst: 40:0f:20:00:0c:00 (40:0f:20:00:0c:00) Internet Protocol, Src: 87.247.163.96 (87.247.163.96), Dst: 66.94.234.13 (66.94.234.13) Internet Control Message Protocol

The second packet details:

Frame 2 (1514 bytes on wire, 1514 bytes captured) Ethernet II, Src: OmronTat_00:00:00 (00:00:0a:00:00:00), Dst: 40:0f:20:00:0c:00 (40:0f:20:00:0c:00) Internet Protocol, Src: 87.247.163.96 (87.247.163.96), Dst: 66.94.234.13 (66.94.234.13) Data (1480 bytes)

Note that only the first fragment contains the ICMP header and all remaining fragments are generated without the ICMP header.

Two important points here:

• In some datalink protocols such as Ethernet, only the first fragment contains the full upper layer header, meaning that other fragments look like beheaded datagrams.
• Additional overhead imposed over network because all fragments contains their own IP header. Additional overhead = (number_of_fragments - 1) * (ip_header_len);