IP Behavior II Frag mentation

4-1
IP Behavior II – SANS GIAC LevelTwo
- ©2000, 2001
1
IP Behavior II
Frag men ta tion
Hello, my name is Judy Novak, I work for Jacob and Sundstrom in the Computer Security and
Incident Response Team at the Army Research Lab as a security analyst. Stephen Northcutt invited me
to develop this talk because fragmentation is so important to understand if you are responsible for
computer and network security. I’d like to take a moment to give credit and gratitude to my technical
editor, Bill Ralph of the Naval Surface Warfare Center Shadow team.
Attackers use fragmentation to mask their probes and exploits. Some intrusion detection systems do
not support packet reassembly and therefore do not detect activity where the signature is split over
multiple datagrams. There are availability, or denial of service attacks such as ssping, that use highly
fragmented traffic to exhaust system resources. Finally, some sophisticated persons of mal-intent use
fragmentation to try to circumvent filtering routers. These are all reasons that you may want to learn
about fragmentation, the topic of the webcast.
By understanding how this facet of IP works, you will be equipped to detect and analyze fragmented
traffic and discover if it is normal fragmentation or fragmentation used for other purposes.
4-2
IP Behavior II – SANS GIAC LevelTwo
- ©2000, 2001
2
Objectives
• Discuss fragmentation concepts
• Examine “normal” fragmentation
• Examine “abnormal” fragmentation
We will look at fragmentation to see what is happening at the datagram level. We need to be aware
of “normal” fragmentation before we can identify “abnormal”; we’ll examine both of these in
today’s webcast.
4-3

IP Behavior II – SANS GIAC LevelTwo
- ©2000, 2001
3
Normal Fragmentation
Fragmentation can be a very normal and naturally occurring effect of traffic travelling among
variously sized networks. We will consider the theory and composition of normal fragmentation first
to acquaint you with how it should operate.
4-4
IP Behavior II – SANS GIAC LevelTwo
- ©2000, 2001
4
Fragmentation Theory
• Occurs when maximum transmission unit (MTU) smaller
than datagram
• Reassembled by destination host
• Can be used to bypass routers or intrusion detection
systems
The next slide is titled “Fragmentation theory”. Fragmentation occurs when an IP datagram
travelling on a network has to traverse a network with a maximum transmission unit (MTU) that is
smaller than the size of the datagram. For instance, for Ethernet, the maximum transmission unit or
maximum size for an IP datagram is 1500 bytes. If a datagram needs to traverse an Ethernet network
and is larger than 1500 bytes, it will have to be fragmented by a router that is directing it to the
Ethernet network. Fragmentation can also occur when a host needs to put a datagram on the network
that exceeds the MTU; in some instances this will be fragmented.
Fragments will continue on to their destination where they will be reassembled by the destination
host. It is even possible for fragments to become further fragmented if they cross an MTU smaller
than the fragment size. While fragmentation is a perfectly normal and naturally occurring 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.
4-5

IP Behavior II – SANS GIAC LevelTwo
- ©2000, 2001
5
More Fragmentation Theory
• Reassembled by the receiving host
• All fragments:
– Must share a common fragment identification number
– Must tell what offset in original unfragmented datagram
– Must tell length of data payload
– Must tell whether another fragment follows this one
• Each fragment encapsulated in IP datagram
Continuing with concepts on slide “More fragmentation theory”, we examine what kind of
information the fragments must carry for the destination host to reassemble them back to the original
unfragmented state. This information is:
• 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 say 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, the fragment must know whether more fragments follow this one
This information will be contained in the IP header. The IP header will be placed in an IP datagram
followed by an encapsulated fragment. All TCP/IP traffic must be wrapped within IP because IP is
the protocol responsible for getting the packet delivered.
4-6
IP Behavior II – SANS GIAC LevelTwo
- ©2000, 2001
6
The Fragment ID
• Each fragment has identifying number - fragment ID
• Taken from IP identification field
• Value set by a host sending datagram

• Value usually increases by 1 for each new datagram sent
• tcpdump output of unfragmented datagram IP
identification value:
ping.com > 192.168.244.2: icmp: echo request (ttl 240, id 202)
Slide “The fragment ID” examines the origin of the field that identifies fragments. 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 is incremented by 1 for each datagram sent by
that host.
When the datagram becomes fragmented, all fragments created from this datagram will contain this
same IP identification number, or the fragment ID. The tcpdump output in this slide shows an IP
identification number of 202 for a datagram that is not fragmented. If this datagram were to be
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 which says to list
the time to live value and the IP identification values along with normal output.
4-7
IP Behavior II – SANS GIAC LevelTwo
- ©2000, 2001
7
Ethernet Datagram Packaging
Ethernet (MTU = 1500)
20 byte IP
header
1480 bytes of embedded data
Turning to the slide “Ethernet datagram packaging”, we see that a datagram travelling on Ethernet
has a maximum transmission unit of 1500 bytes. Each datagram must have an IP header which is
typically 20 bytes, but can be more if IP options are included.
If you recall, the IP header contains information such as the source and destination IP numbers. It is
considered the “network” portion of the IP datagram since routers use the information found in the
IP header to direct the datagram towards its destination. Encapsulated after the IP header is some

kind of data. This data can be an IP protocol such as tcp, udp or ICMP. For instance, if this data
were tcp, it would include a tcp header and tcp data.
4-8
IP Behavior II – SANS GIAC LevelTwo
- ©2000, 2001
8
Fragmentation using ICMP
echo request
ICMP data
IP header
ICMP
header
20 8 4000 bytes of ICMP data
4028 total bytes in IP datagram
Ethernet MTU = 1500
1500 bytes 1500 bytes 1068 bytes
(ICMP echo request)
Original 4028 byte fragment broken into 3 fragments of 1500 bytes or less
On slide “Fragmentation using an ICMP echo request”, we have a datagram of 4028 bytes. This
is an ICMP echo request bound for an Ethernet network that has an MTU of 1500. 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 so that leaves 1480 bytes maximum for data for
each fragment. Let’s examine what each of the individual three fragments looks like.
Normally, you shouldn’t encounter a 4,000+ byte echo request. And, if you do, examine it until you
become cross-eyed because something isn’t kosher. The reason that this was used for the example
and for instructive purposes is that in the Windows ping, there is a -l switch that allows you to say
how big you want the echo request to be. This allowed the generation and capture by tcpdump of the
packets you see in the upcoming several slides to validate all the information delivered to you is
correct.
4-9

IP Behavior II – SANS GIAC LevelTwo
- ©2000, 2001
9
The Breakdown
ICMP data
20 8 4000 bytes of ICMP data
4028 total bytes in pre-fragmented IP datagram
1472 ICMP data 1480 ICMP data 1048
1500 1500 1068
1472 + 1480 + 1048 = 4000 bytes of ICMP data
= 20 byte IP header
Looking at the slide, “The Breakdown”, let’s see how each fragment is actually formed. Before the
IP datagram is sent on the link that has an MTU of 1500 bytes, we see that is has a total of 4028
bytes total.
What we have seen is that this IP datagram will be divided into three separate fragments each with a
cloned IP header. The original header is paired with the first fragment and two new headers of 20
bytes each have to be created for the second and third fragments. So, we really need a total of 4068
bytes to send all of this traffic.
The first fragment gets the original IP header, along with the 8 bytes of the ICMP header for a
running total of 28 bytes. With a maximum datagram size of 1500 bytes, 1472 bytes remain for
ICMP data. The second fragment gets a cloned IP header of 20 bytes, and has the remaining 1480
bytes for ICMP data. The final fragment again gets a 20 byte IP header and carries the final 1048
bytes of ICMP data. As a cross check, we see that we have 1500 + 1500 + 1068 bytes of data sent
for a total of 4068 bytes.
4-10
IP Behavior II – SANS GIAC LevelTwo
- ©2000, 2001
10
The first fragment
IP header

ICMP header
ICMP echo
request
20 8 1472
Offset = 0
Length = 1480
More Fragments = 1
ICMP data
IP Header
1500 total bytes
ICMP dataIP Header
20 8 1472
Looking at the slide “The first fragment” we turn our concentration to the initial fragment in the
fragment train. The “original” IP header will be cloned to contain the identical fragment
identification numbers for the first and remaining fragments. Remember, all fragments must be
carried in an IP datagram. An IP datagram requires an IP header to direct it to its destination.
The first fragment is the only one that will carry with it the ICMP message pseudo-header.
As we see, the first fragment has a 0 offset, a length of 1480 bytes, 1472 bytes of data and 8 of ICMP
header, and more fragments follow so that more fragments flag is set.
4-11
IP Behavior II – SANS GIAC LevelTwo
- ©2000, 2001
11
Composition of the first fragment
First fragment 1500 total bytes in IP datagram
20 8 1472 ICMP data bytes
Protocol = ICMP
Fragment ID = 21223
More Fragments Flag = 1
Fragment Offset = 0

Data Length = 1480
IP Header
ICMP pseudo-header
Type = ICMP echo request
Slide “Composition of the first fragment” 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 occupied
by the ICMP pseudo-header. Recall that this was an ICMP echo request that has an 8 byte pseudo-
header in its original packet. The remaining 1472 bytes are for ICMP data.
In addition to the normal fields carried in the IP header such as source and destination IP and
protocol, in this instance, ICMP, there are fields that are specifically for fragmentation. The
fragment ID with a value of 21223 will be the common link for all the fragments in the fragment
train. There is a field known as the more fragments flag that indicates that another fragment follows
the current one. In this first fragment, the flag will be 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 whole datagram
must be stored. For the first record, the offset will be 0. Finally, the length of the data carried in this
fragment will be stored as the fragment length – in this fragment, the length will be 1480. This is the
8 byte ICMP pseudo-header followed by the first 1472 bytes of the ICMP data.
4-12
IP Behavior II – SANS GIAC LevelTwo
- ©2000, 2001
12
The second fragment
1480
Offset = 1480
Length = 1480
More Fragments = 1
ICMP data
IP Header ICMP data
20 1480
1500 total bytes

Looking at the slide “The second fragment” we focus on the next fragment in the fragment train.
An IP header will be 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 will
be replicated for the new header. Embedded after this new IP header will be 1480 ICMP data bytes.
As we see, the second fragment has an offset of 1480, a length of 1480 bytes, and one more fragment
follows so the more fragments flag is set.
4-13
IP Behavior II – SANS GIAC LevelTwo
- ©2000, 2001
13
Composition of the second
fragment
Second fragment 1500 total bytes in IP datagram
20 1480 ICMP data bytes
Protocol = ICMP
Fragment ID = 21223
More Fragments Flag = 1
Fragment Offset = 1480
Data Length = 1480
IP Header
Continuing with fragmentation on slide “Composition of the second fragment”, we examine the
IP datagram carrying the second fragment. As with all fragments, it requires a 20 byte IP header.
Again, the protocol in the header will indicate ICMP. The fragment identification number will
remain 21223. And, the more fragments flag will be turned on because another fragment follows.
The offset is 1480 bytes into the data portion of the original ICMP message data. The previous
fragment occupied the first 1480 bytes. This fragment will be 1480 bytes long as well and it is
composed entirely of ICMP data bytes.
It is worth noting that the ICMP pseudo-header in the first fragment doesn’t get cloned along with
the ICMP data. This means if you were to examine this fragment alone, you could not tell what the
ICMP message type is – in this case ICMP echo request. This becomes an important issue when we

discuss filtering devices in a while.
4-14
IP Behavior II – SANS GIAC LevelTwo
- ©2000, 2001
14
The third fragment
1048
Offset = 2960
Length = 1048
More Fragments = 0
IP Header
20 1048
1068 total bytes
ICMP data
ICMP data
Looking at the slide “The third fragment” we examine the final fragment in the fragment train.
Again, an IP header will be cloned from the “original” header with an identical fragment
identification number, and other fields will be replicated for the new header. Embedded in this new
IP datagram will be the final 1048 ICMP data bytes.
As we see, the third fragment has an offset of 2960, a length of 1048 bytes, and no more fragments
follow so the more fragments flag is 0.
4-15
IP Behavior II – SANS GIAC LevelTwo
- ©2000, 2001
15
Composition of the final
fragment
Third fragment 1068 total bytes in IP Datagram
20 1048 ICMP data bytes
Protocol = ICMP

Fragment ID = 21223
More Fragments Flag = 0
Fragment Offset = 2960
Data Length = 1048
IP Header
Slide “Composition of the final fragment” 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, the more fragments flag is not set because this is
the last fragment. The offset is 2960 (this is the sum of the two 1480 byte previous fragments).
There are only 1048 data bytes carried in this fragment comprised entirely of the remaining ICMP
message bytes.
This fragment, like the second one will have no ICMP pseudo-header and therefore no ICMP
message type to reflect that this is an ICMP echo request.
4-16
IP Behavior II – SANS GIAC LevelTwo
- ©2000, 2001
16
tcpdump output of
fragmentation
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)
fragment
ID
Number of data
bytes in current
fragment
Offset into the
data that this
fragment falls

More fragments to
follow
Examining the tcpdump output on slide ”tcpdump output of fragmentation”, we see the three
different records representing the three fragments we’ve discussed. This means that the host running
tcpdump has collected the ICMP echo request after the fragmentation occurred.
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
pseudo-header which identifies this as an ICMP echo request. Now, let’s look at fragmentation
notation at the right side of the record. tcpdump convention for displaying fragmented output is the
word “frag” appears followed by the fragment ID, 21223, in our example, followed by a colon. The
length of data in the current fragment follows, 1480, followed by an @ sign, and then you see the offset
into the data, 0, since this is the first fragment. The plus sign indicates that the more fragments flag is
set.
The second record is somewhat different. Notice that there is no ICMP echo request label. This is
because there is no ICMP pseudo-header to tell what kind of ICMP traffic this is. The IP header will
still have the protocol field set to ICMP, yet that is all you can tell looking at this fragment alone. We
see the tcpdump output lists the fragment ID of 21223, the current data length is 1480 and the offset is
1480. The plus sign signifies that the more fragments flag is set.
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. But, there is no more fragments flag in the final
record, as we would expect.