reassembly or perform it correctly and therefore do not detect or block activity where the signature is split over multiple datagrams. Availability or denial-of-service attacks use highly fragmented traffic to exhaust system resources. These are some of the reasons you might want to learn about fragmentation and some of the topics covered in this chapter.
By understanding how this facet of IP works, you will be equipped to detect and analyze fragmented traffic and discover whether it is normal fragmentation versus fragmentation used for other purposes. Fragmentation can be a naturally occurring effect of traffic traveling through networks of varying sized maximum transmission units (MTU). The theory and composition of normal fragmentation is discussed first in this chapter to acquaint you with how it should operate.
Theory of Fragmentation
Fragmentation occurs when an IP datagram traveling on a network has to traverse a network with a maximum transmission unit that is smaller than the size of the datagram. For instance, the MTU or maximum size for an IP datagram for Ethernet is 1500 bytes. If a datagram is larger than 1500 bytes and needs to traverse an Ethernet network, it requires fragmentation by a router directing it to the Ethernet network. Fragmentation can also occur when a host needs to put a datagram on the network that exceeds its own network's MTU.
Fragments continue on to their destination, where the destination host reassembles them. Fragments can even become further fragmented if they cross an MTU smaller than the fragment size. Although fragmentation is a perfectly normal event, it is possible to craft fragments for the purposes of avoiding detection by routers and intrusion-detection systems that don't deal well with fragmentation.
What kind of information must the fragments carry for the destination host to reassemble them back to the original unfragmented state? The following list answers this question:
●All fragments from the same datagram must be associated with each other fragment by using a common fragment identification number. This is cloned from a field in the IP header known as the IP identification number, also called the fragment ID.
●Each fragment must carry what its place or offset is in the original unfragmented packet.
●Each fragment must tell the length of the data carried in the fragment.
●Finally, each fragment must know if more fragments follow it. This is done using the More Fragments (MF) flag.
The Fragment ID Number/IP Identification Number
The IP identification value is a 16-bit field found in the IP header of all datagrams. This uniquely identifies each datagram sent by the host. Typically, this value increases by one for each datagram sent by that host.
When the datagram becomes fragmented, all fragments created from this datagram contain this same IP identification number, or fragment ID. The following TCPdump
output shows an IP identification number of 202 for this unfragmented output: ping.com > 192.168.244.2: icmp: echo request (ttl 240, id 202)
If this datagram were to become fragmented on the way to its destination, all fragments created from this datagram would share a fragment ID of 202. This TCPdump output was generated using the -vv option. This is a verbose option that says to list the time-to-live (TTL) value and the IP identification values at the end of the standard output.
This information is contained in the IP header. The IP header is placed in an IP datagram followed by an encapsulated fragment. As you have learned, all TCP/IP traffic must be
wrapped within IP because IP is the protocol responsible for getting the packet delivered.
Visualizing Fragmentation: Seeing Is Understanding
This discussion uses Ethernet as the example link layer medium to demonstrate the packaging of datagrams. Figure 3.1 depicts the configuration of a datagram that is not fragmented. As previously mentioned, a datagram traveling on Ethernet has an MTU of 1500 bytes. Each datagram must have an IP header, which is typically 20 bytes, but can be more if IP options, such as source routing, are included.
Figure 3.1. Ethernet datagram packaging.
As a quick refresher, recall that the IP header contains information such as the source and destination IP numbers. It is considered the "network" portion of the IP datagram because routers use the information found in the IP header to direct the datagram toward its destination. Some kind of data is encapsulated after the IP header. This data can be an IP protocol such as TCP, UDP, or ICMP. If this data were TCP, for instance, it would include a TCP header and TCP data.
Figure 3.2 shows a datagram of 4028 bytes. This is an ICMP echo request bound for an Ethernet network that has an MTU of 1500. This is an abnormally large ICMP echo request that is not representative of normal traffic, but it is used to illustrate how fragmentation occurs. So, the 4028 byte datagram will have to be divided into fragments of 1500 bytes or less. Each of these 1500-byte fragmented packets will have a 20-byte IP header like the initial fragment, leaving 1480 bytes maximum for data for each fragment. Figure 3.3 examines this same datagram, but shows the allocation of bytes per fragment. The following sections examine the contents of each of the individual three fragments.
Figure 3.2. Original 4028 byte fragment broken into three fragments of 1500 bytes or less.
Figure 3.3. Byte allocations per fragment.
All Aboard the Fragment Train
Turn your concentration to the initial fragment in the fragment train shown in Figure 3.4. The "original" IP header will be cloned to contain the identical fragment identification numbers for the first and remaining fragments.
Figure 3.4. The fragment engine.
The first fragment is the only one that will carry with it the ICMP message header. This header is not cloned in subsequent associated fragments and this concept of the first fragment alone identifying the nature of the fragment is significant, as you will soon learn. The first fragment has a 0 offset, a length of 1480 bytes of length, 1472 bytes of data, and 8 bytes of ICMP header; and because more fragments follow, the More Fragments flag is set.
Figure 3.5 explains the configuration of the first fragment in the fragment train. The first 20 bytes of the 1500 bytes are the IP header. The next 8 bytes are the ICMP header. Remember that this was an ICMP echo request that has an 8-byte header in its original packet. The remaining 1472 bytes are for ICMP data.
Figure 3.5. The guts of the fragment engine.
In addition to the normal fields carried in the IP header, such as source and destination IP and protocol (in this instance of ICMP), there are fields specifically for fragmentation. The fragment ID with a value of 21223 is the common link for all the fragments in the fragment train. There is a field known as the More Fragments flag, which indicates that another fragment follows the current one. In this first fragment, the flag is set to 1 to indicate that more fragments do follow. Also, the offset of the data contained in this fragment relative to the data of the whole unfragmented datagram must be stored. For the first record, the offset is 0. Finally, the length