Fragmentation is a normal process on packet-switched networks. It occurs when a large packet is received and the corresponding outbound interface’s MTU size is too small. Fragmentation dissects the IP packet into smaller packets prior to transmission. The receiving host performs fragment reassemble and passes the complete IP packet up the protocol stack. Fragmentation is an IP process, TCP and other layers above IP have no involvement.
[stextbox id=”black” color=”000000″ ccolor=”000000″ bgcolor=”FFFFFF” cbgcolor=”FFFFFF” bgcolorto=”F7F7F7″ cbgcolorto=”F7F7F7″ image=”null”]Fragmentation occurs in networks when you have varying sizes of MTU’s.[/stextbox]
In an IPv4 world, a number of flags and fields control the fragmentation process, including the Fragment Offset, Don’t Fragment (DF) bit and More Fragments (MF) flags. All fragmentation information is contained in the IPv4 header. The fragment offset tells the receiving device where exactly in the overall message should the fragment be placed. The DF bit is used to tell hosts not to fragment. If set and fragmentation along the path is required, packets are simply dropped. This mechanism is used for Path MTU Discovery to determine the maximum MTU size on the network. It is set automatically with host software or manually with command-line tools. Finally, when an IP packet undergoes fragmentation, the MF bit is set for all datagrams except the last one. For unfragmented packets, the MF flag is cleared.
The process of fragmentation in networks can lead to IP security issues. Fragmentation can be exploited for a variety of different attacks such as fingerprinting, IPS insertion/evasion, firewall evasion, and remote code execution. Now, as we move to IPv6, are we exposed to the same type of attacks?
In an IPv6 world, the IPv6 header length is limited to 40 bytes yet the IPv4 header has a max of 60 bytes. The main IPv6 header remains a fixed size. IPv6 has the concept of extension headers to add optional IP layer information. Special handling with IPv4 was controlled by “IP options” but there are no IP options in IPv6. All options are moved to different types of extension headers. IPv6 has many extension headers, including IPv6 header, Hop-by-hop Options header, Destination options header, Routing header, Fragment header, Authentication header, ESP header, Destination Option header, and finally Upper-layer header. We now have a fragment header that governs fragmentation. The fragment header contains information that helps the receiving host reassemble the original IP packet. With IPv4, all this was contained in the IPv4 header. There is no separate fragment header in IPv4 and the fragments fields in the IPv4 header are moved to the IPv6 fragment header. The “Don’t fragment” bit (DF) is totally removed, intermediate routers are not allowed to fragment. They decided to allow only end stations to create and reassemble fragments (RFC 2460), not intermediate routers. The design decision stems from the performance hit that fragmentation imposes on nodes.
[stextbox id=”black” color=”000000″ ccolor=”000000″ bgcolor=”FAFAFA” cbgcolor=”FAFAFA” bgcolorto=”FCFCFC” cbgcolorto=”FCFCFC” image=”null”]If link fragmentation and reassembly are needed it must be provided at a layer below IPv6. [/stextbox]
Routers are no longer required to perform packet fragmentation and reassembly, resulting in packets larger than the router’s interface MTU being dropped. IPv6 hosts perform PMTU to determine the maximum packet size for the entire path. When a packet hits an interface with a smaller MTU, the routers send back an ICMPv6 type 2 error, known as Packet Too Big to the sending host. The sending host receives the error message, reduces the size of the sending packet, and tries again.
One of the main issues of fragmentation is the first fragment may not have the required upper-layer (TCP and UDP) information. Security devices require this information to determine if the packet complies with its configured policies and rules. Fragmentation can obfuscate the data, allowing it to pass security devices. By default, routers and non-stateful devices usually only look at the first fragment containing the header information.
Many small fragments are used by to hide or DoS attack a node. The attacker dissects the packet into many small fragmented packets, bypassing security devices. Every small fragment looks legitimate but once reassembled the entire packet is used to launch an attack. The attacker is hiding his real intention by pushing the contents of the attack into many small fragments. These might be passed and unseen by devices that only look at the unfragmented part.
Other types of attacks include overlapping fragments, incomplete set of fragments, fragments inside a tunnel, and nested fragments. Nested fragments are packets that have multiple sets of fragment headers, which should never occur in normal IP networks. The source only creates one fragment header. Overlapping fragments can be used for O/S fingerprinting and IPS/IDS evasions. Fragmentation attacks may be used to DoS an end host. If hosts cannot process fragmented packets correctly, attackers can send many fragmented packets, which will be processed by kernel memory, exhausting the kernel from processing legitimate fragments. There are many tools out there that can craft these types of packets, such as Whisker, Fragrouter, and Scapy.
Proper Handling of IPv6 Fragments
IPv6 attempts to minimize the use of fragmentation by supporting the minimum IPv6 datagram size of 1280 bytes. The minimum datagram size in IPv4 is 576 bytes (not to be confused with the minimum MTU for both IP versions). This removes the severe restriction on data size that we had with IPv4 and should minimize the need for fragmentation. Antonios Atlasis carried out a “Attacking IPv6 using fragmentation” webinar for Black Hat Europe. It included a number of O/S such as Ubuntu, FreeBSD, OpenBSD, and W2K7. Scapy, a packet manipulation tool, was used to test if the O/S responded to tiny fragments. For Upper-layer protocol, ICMPv6 was used to send Echo Requests. All of the major O/S accepted tiny fragments and sent an ECHO-REPLY in response to the ECHO REQUEST. There are consequences of accepting tiny fragments unless Deep Packet Inspection (DPI) is performing complete IP datagram reassembly before forwarding. However, without proper DPI it could lead to firewall evasion. A similar problem exists with IPv4.
RFC 5722 recommends that overlapping fragments should be disallowed. The RFC states that if an IPv6 host is performing reassembling and contains a fragment that is determined to be overlapping, then the entire datagram is silently discarded. No error message is sent back to the sending host. Test carried out by Antonios Atlasis prove that none of the O/S are RFC 5722 compliant.
Similar to the IPv4 world, IPv6 security features consist of ACL with the “fragments” keyword. The ACL matches non-initial IPv6 fragments. The initial fragment contains the Layer 3 and Layer 4 information. Cisco IOS has a feature known as Virtual Reassembly, which inspects fragmented packets. It is secondary to an input ACL, meaning the input ACL has the first chance to check incoming packets. It reassembles fragmented packets, examines any out-of sequence fragments, puts them back in proper sequence, and sends up the protocol stack.