of the data carried in this fragment is stored as the fragment length—in this fragment, the length is 1480. This is the 8-byte ICMP header followed by the first 1472 bytes of the ICMP data.
The Fragment Dining Car
Take a look at Figure 3.6 to focus on the next fragment in the fragment train. An IP header is cloned from the "original" header with an identical fragment identification number, and most of the other data in the IP header (such as the source and destination numbers) is replicated for the new header. Embedded after this new IP header is 1480 ICMP data bytes. As you can see, the second fragment has an offset of 1480 and a length of 1480 bytes; and because one more fragment follows, the More Fragments flag is set.
Figure 3.6. The fragment dining car.
Continuing with fragmentation in Figure 3.7, you can examine the IP datagram carrying the second fragment. As with all fragments in this fragment train, it requires a 20-byte IP header. Again, the protocol in the header indicates ICMP. The fragment identification number remains 21223. And, the More Fragments flag is turned on because another fragment follows. The offset is 1480 bytes into the data portion of the original ICMP message data. The preceding fragment occupied the first 1480 bytes. This fragment is 1480 bytes long as well, and it is composed entirely of ICMP data bytes.
Figure 3.7. The guts of the fragment dining car.
It is worth repeating that the ICMP header in the first fragment does not get cloned along with the ICMP data. This means that if you were to examine this fragment alone, you could not tell the type of the ICMP message—in this case, an ICMP echo request. This becomes an important issue with regard to packet-filtering devices (as discussed later in this chapter).
The Fragment Caboose
Examine the final fragment in the fragment train in Figure 3.8. Again, an IP header is cloned from the "original" header with an identical fragment identification number, and other fields are replicated for the new header. The final 1048 ICMP data bytes are embedded in this new IP datagram. You see the third fragment has an offset of 2960 and a length of 1048 bytes; and because no more fragments follow, the More Fragments flag is 0.
Figure 3.8. The fragment caboose.
Figure 3.9 depicts the last fragment in the fragment train. Again, 20 bytes are reserved for the IP header. The remaining ICMP data bytes are carried in the data portion of this fragment. The fragment ID is 21223, and the More Fragments flag is not set because this is the last fragment. The offset is 2960 (the sum of the two 1480-byte previous fragments). Only 1048 data bytes are carried in this fragment comprised entirely of the remaining ICMP message bytes. This fragment, like the second one, has no ICMP header and therefore no ICMP message type to reflect that this is an ICMP echo request.
Figure 3.9. The guts of the fragment caboose.
Viewing Fragmentation Using TCPdump
Take a look at the following TCPdump output. As you can see, the three different records represent the three fragments discussed earlier. This means that the host running TCPdump
has collected the ICMP echo request after the fragmentation occurred. Here are the records: ping.com > myhost.com: icmp: echo request (frag 21223:1480@0+)
ping.com > myhost.com: (frag 21223:1480@1480+) ping.com > myhost.com: (frag 21223:1048@2960
The first line shows ping.com sending an ICMP echo request to myhost.com. The reason that TCPdump can identify this as an ICMP echo request is because the first fragment contains the 8-byte ICMP header that identifies this as an ICMP echo request. Now, look at the fragmentation notation at the right side of the record. TCPdump convention for displaying fragmented output is that the word frag appears, followed by the fragment ID (21223, in this example), followed by a colon. The length of data in the current fragment follows, 1480, followed by an at (@) sign, and then you see the offset into the data (0, because this is the first fragment). The plus (+) sign indicates that the More Fragments flag is set. This fragment knows the purpose of the traffic, knows it is the first fragment, knows that more fragments follow, but doesn't know what or how many follow.
The second record differs somewhat. Notice that there is no ICMP echo request label. This is because there is no ICMP header to tell what kind of ICMP traffic this is. The IP header will still have the protocol field set to ICMP, but that is all you can tell looking at this fragment alone. You see the TCPdump output lists the fragment ID of 21223, the current data length of 1480, and the offset of 1480. The plus sign signifies that the More Fragments flag is set. This fragment has an affiliation, a follower, and a sense of placement, but is essentially clueless about its purpose—sounds like freshman year at college.
The last line is very similar to the second one in format. It shows the same fragment ID of 21223, it has a length of 1048, and a displacement of 2960. No More Fragments flag appears in the final record, however, as you would expect. This fragment has an affiliation, no sense of purpose, and no followers.
How the Fragment Offset Is Stored
Although TCPdump nicely computes the fragment offset for you, it is stored in the packet differently. Be forewarned that if you ever examine a fragment offset in a packet—perhaps from a TCPdump hex dump—you will need to do some manipulation before arriving at the actual byte offset.
The fragment offset is found in part of the sixth byte and the entire seventh byte offset of the IP header. It is a 13-bit field that can represent a maximum value of 8191 (213 – 1). Yet, theoretically, though rarely indicative of normal fragmentation, the offset can be greater than 8191 because the maximum datagram size is 65,535 (216 – 1) bytes. To represent the offset value found in the packet as bytes, multiply it by 8. For those of you who want to know the mathematical origin of this, 65,536 (216) divided by 8192 (213) is 8.
Fragmentation and Packet-Filtering Devices
This section covers fragmentation and how a packet-filtering device, such as a router or firewall, might deal with it. The problem arises when such a device attempts to block fragmented traffic.
Because only the first fragment of a fragment train will contain any kind of protocol header such as TCP, UDP, or ICMP, only this fragment is prevented from entry into the network guarded by a packet-filtering device incapable of examining state of a header field. What I mean by state is it appears obvious to you that any fragment sharing the fragment ID of the blocked one should also be blocked. But, some packet-filtering devices don't maintain this information. They myopically look at each fragment as an individual entity and don't connect it with previous or subsequent packets. Intuitively enough, this is not a particularly good architecture, so why is it used? Think about the overhead required to maintain state. It means
that each fragment must be examined and stored; this is expensive in terms of time, processing, and memory. Eventually, fragments must be allowed or rejected access and that too consumes more resources. It is far simpler to have an atomic architecture that scrutinizes on a per-packet basis.
If a particular packet doesn't match the blocking criteria, in this instance, because of the absence of a protocol header, it is allowed into the network. Fragmented TCP or UDP datagrams might contain their respective header information in the first fragment only. Blocking decisions are often based on header information, such as TCP or UDP destination ports. This means that fragmented TCP and UDP are susceptible to the same shortcomings of a stateless packet-filtering device.
One final point to remember is that IP is not a reliable protocol, and it is very possible for the first fragment that contains the protocol header information to be lost. When this occurs, the packet-filtering device has an even more difficult job of allowing or denying traffic. In fact, if
one of the fragments does not arrive at the destination, all must be resent.
The Don't Fragment Flag
In some of the TCPdump output you have looked at, you might have seen the letters DF in parentheses. This means the Don't Fragment flag is set. No sur-prises here; as the name implies, if this flag is set, fragmentation will not be done on the datagram. If this flag is set and the datagram crosses a network where fragmentation is required, the router discovers this, discards the datagram, and sends an ICMP "unreachable—need to frag" error message back to the sending host.
The ICMP error message contains the MTU of the network that required fragmentation. Some hosts intentionally send an initial datagram across the network with the DF flag set as a way to discover the path MTU for a particular source to destination host. If the ICMP error message is returned with the smaller MTU, the host then packages all datagrams bound for that destination in small enough units to avoid fragmentation. This is often used with TCP because TCP requires a lot of overhead. Fragmentation can introduce ineffi-ciency because if one fragment is lost, all must be sent again; that is one reason it is desirable to avoid fragmentation. As you can surmise, a malicious user also can use this mechanism to discover the MTU of a segment of your network to be used later for fragmentation exploits. The user could craft datagrams with different lengths and the DF flag set and observe when an ICMP error message is received. This assumes that the targeted network doesn't disable the ICMP error message from being sent. The following TCPdump output shows an ICMP message in which a router discovered that fragmentation was necessary, but the Don't Fragment flag was
set.
router.ru > mail.mysite.com: icmp: host.ru unreachable - need to frag (mtu 308) (DF)
The stimulus for this reply was that mail.mysite.com attempted to send a datagram larger than 308 bytes to host.ru with the DF flag set before this packet was sent. router.ru finds that the datagram must traverse a smaller network with an MTU of 308 bytes and fragmentation is necessary.
When router.ru examines the record, it finds that the Don't Fragment flag is set and an ICMP message is sent back to mail.mysite.com informing it of the problem. Now, mail.mysite.com either must package the datagrams to be smaller than the MTU of 308 so that fragmentation doesn't occur or it must remove the DF flag so that fragmentation can occur and then resend the datagram.