[Updated post] - The DF Bit Playground

[Ofir Arkin <ofir () ITCON-LTD COM>]

* This is an update post for the post i have sent to Bugtraq on September 13
*

RFC 791 defines a three bits field used for various control flags in the IP
Header.

Bit 0 is the reserved flag, and must be zero.

Bit 1, is called the Don’t Fragment flag, and can have two values. A value
of zero
(not set) is equivalent to May Fragment, and a value of one is equivalent to
Don't
Fragment. If this flag is set than the fragmentation of this packet at the
IP level
is not permitted, otherwise it is.

Bit 2, is called the More Fragments bit. It can have two values. A value of
zero
is equivalent to (this is the) Last Fragment, and a value of 1 is equivalent
to
More Fragments (are coming).

The next field in the IP header is the Fragment Offset field, which
identifies the
fragment location relative to the beginning of the original un-fragmented
datagram
(RFC 791, bottom of page 23).

A close examination of the ICMP Query replies would reveal that some
operating
systems would set the DF bit with their replies.

The tcpdump trace below illustrates the reply a Sun Solaris 2.7 box produced
for
an ICMP Echo Request:


17:10:19.538020 if 4  > y.y.y.y > x.x.x.x : icmp: echo request (ttl 255, id
13170)
                         4500 0024 3372 0000 ff01 9602 yyyy yyyy
                         xxxx xxxx 0800 54a4 8d04 0000 cbe7 bc39
                         8635 0800
17:10:19.905254 if 4  < x.x.x.x > y.y.y.y : icmp: echo reply (DF) (ttl 233,
id 24941)
                         4500 0024 616d 4000 e901 3e07 xxxx xxxx
                         yyyy yyyy 0000 5ca4 8d04 0000 cbe7 bc39
                         8635 0800

ICMP Query replies for an operating system maintains the same behavioral
patterns.
Either they set the DF bit on all ICMP query reply types or they do not.

The DF bit would be set by default with ICMP Query replies with Sun Solaris.
With HP-UX
10.30, & 11.0x, and with AIX 4.3.x setting the DF Bit will vary from one
queried host to
another (explanation coming). It may be set with the first ICMP Query reply
onwards, or
after a number of ICMP Query replies. This detail will help us to
distinguish between
Sun Solaris, HP-UX 10.30 & 11.0x, and AIX 4.3.x operating systems.


Why HP-UX 10.30 / 11.0 & AIX 4.3.x operating systems act this way?
HP claims to have a proprietary method in order to determine the PMTU with
HP-UX v10.30,
and HP-UX v11.0x using ICMP Echo requests. AIX 4.3.x do exactly the same.

The next trace will help understanding the process taken by HPUX 10.30 &
11.0x and
AIX 4.3.x. Here I have sent an ICMP Echo request to an HP-UX 11.0 machine:

00:27:56.884147 ppp0 > y.y.y.y > x.x.x.x: icmp: echo request (ttl 255, id
13170)
                         4500 0024 3372 0000 ff01 7c51 yyyy yyyy
                         xxxx xxxx 0800 5238 6d04 0000 dce5 c339
                         8b7d 0d00
00:27:57.165620 ppp0 < x.x.x.x > y.y.y.y : icmp: echo reply (ttl 236, id
41986)
                         4500 0024 a402 0000 ec01 1ec1 xxxx xxxx
                         yyyy yyyy 0000 5a38 6d04 0000 dce5 c339
                         8b7d 0d00

The first pair of ICMP Echo request and ICMP Echo reply was pretty usual. My
computer
has sent an ICMP Echo request and has received an ICMP Echo reply from the
probed
machine. One notable detail – the DF bit is not set in the ICMP Echo reply.

Than something that was not expectable has happened:

00:27:57.435620 ppp0 < x.x.x.x > y.y.y.y : icmp: echo request (DF) (ttl 236,
id 41985)
                         4500 05dc a401 4000 ec01 d909 xxxx xxxx
                         yyyy yyyy 0800 7e52 9abc def0 0000 0000
                         0000 0000 0000 0000 0000 0000 0000 0000
                         0000 0000 0000 0000 0000 0000 0000 0000
                         0000 0000 0000 0000 0000 0000 0000 0000
                         0000 0000 0000 0000 0000 0000 0000 0000
                         ...

00:27:57.435672 ppp0 > y.y.y.y > x.x.x.x: icmp: echo reply (ttl 255, id 53)
                         4500 05dc 0035 0000 ff01 a9d6 yyyy yyyy
                         xxxx xxxx 0000 8652 9abc def0 0000 0000
                         0000 0000 0000 0000 0000 0000 0000 0000
                         0000 0000 0000 0000 0000 0000 0000 0000
                         0000 0000 0000 0000 0000 0000 0000 0000
                         0000 0000 0000 0000 0000 0000 0000 0000
                         ...

The machine I have queried pinged me back. The ICMP Echo request size was
1500 bytes.
It was the maximum transfer unit my Internet Connection was allowed to
process. The
request was sent with the DF bit set. Any router along the way, trying to
fragment
the request because the MTU of the destined network was smaller than the
datagram’s
size would fail and send an ICMP Error message back stating a fragmentation
was required
but the don’t fragment bit was set. It would allow the sending machine to
send a smaller
sized datagram according to its PMTU discovery process/algorithm with ICMP.
If for this
ICMP Echo request an ICMP Echo reply would be received, than the PMTU is
discovered.

00:27:57.885662 ppp0 > y.y.y.y > x.x.x.x : icmp: echo request (ttl 255, id
13170)
                         4500 0024 3372 0000 ff01 7c51 yyyy yyyy
                         xxxx xxxx 0800 5832 6d04 0100 dde5 c339
                         8383 0d00
00:27:58.155627 ppp0 < x.x.x.x > y.y.y.y : icmp: echo reply (DF) (ttl 236,
id 41987)
                         4500 0024 a403 4000 ec01 debf xxxx xxxx
                         yyyy yyyy 0000 6032 6d04 0100 dde5 c339
                         8383 0d00

The following ICMP Echo Request sent from my machine to the queried HP-UX
11.0 just
milliseconds after my reply to the HP-UX’s query was sent. It has resulted
in an ICMP
Echo reply coming back from the queried machine. This time the DF bit was
set with the
ICMP Echo reply. Rather than sending an ICMP datagram that will be
fragmented somewhere
along the way to the destination machine, it is more beneficial from
performance perspective,
to fragment the ICMP datagram on sending. Setting the DF bit on the
following replies
would help to maintain the PMTU between the two systems, if for any reason,
the PMTU
would be decreased. For example, because the datagram have used another
route to the
destined system.

Sending immediately another ICMP Query message type to this particular HP-UX
11.0x operating
system based machine, will not result in the PMTU discovery process to be
repeated. The
DF Bit would be set within the ICMP Query reply. Expect a threshold to be
maintained by
the HP-UX 11.0x. When reached the next time we query this host with any type
of
communication, the process of determining the PMTU using ICMP Echo requests
will begin
again.

This gives us the ability to distinguish between Sun Solaris machines, HP-UX
11.0x/10.30, and
AIX 4.3.x based machines.

In my opinion Sun Solaris sets the DF bit with the ICMP Query replies the
operating system
answers for, in order to support its global PMTU discovery process. If the
networking link will
not let the ICMP Query reply to get back to the querying host, because the
MTU used is higher
than the allowed and fragmentation is not allowed (the DF Bit is set), than
the size of the MTU
used should be lowered. There is no active measures with Sun Solaris as far
as I know.

This is a simple operating system fingerprinting method, which does not
require additional or
unusual patterns to be set.

The following operating systems where queries and checked for this kind of
behavior:
Linux Kernel 2.4 test 2,4,5,6; Linux Kernel 2.2.x; FreeBSD 4.0, 3.4; OpenBSD
2.7,2.6;
NetBSD 1.4.1,1.4.2; BSDI BSD/OS 4.0,3.1; Solaris 2.6,2.7,2.8; HP-UX 10.20,
11.0x;
Compaq Tru64 5.0; Aix 4.1,3.2; Irix 6.5.3, 6.5.8; Ultrix 4.2 – 4.5; OpenVMS
v7.1-2;
Novel Netware 5.1 SP1, 5.0, 3.12; Microsoft Windows 98/98SE/ME, Microsoft
Windows NT
WRKS SP6a, Microsoft Windows NT Server SP4, Microsoft Windows 2000 Family.

Avoidance
With HP-UX 10.30, & 11.0 , one of the ndd command option is the
ip_pmtu_strategy. The
variable settings for this option are either 1 or 2. If this bit value is 2,
than the
Path MTU Discovery Process is used with ICMP Echo Requests. This is the
default value.
If this bit value equals 1, than the HP-UX machines will not use the ICMP
echo-request
PMTU discovery strategy, and will not set the DF bit after determining the
accurate PMTU.

To turn off ip_path_mtu_discovery on a Sun Solaris machine use the following
command
as root:

# ndd -set  /dev/ip  ip_path_mtu_discovery 0

Than when the ICMP Echo Reply is sent (this example) the DF bit is not set:

# SING v1.0beta7 initiated on Host_Address at Thu Sep 14 10:01:02 2000
# Command line:
# -> sing -c 1 -L Host_Address
SINGing to Host_Address (IP_Address): 16 data bytes
16 bytes from 10.13.57.20: icmp_seq=0 ttl=254 TOS=0 time=1.578 ms

--- Host_Address sing statistics ---
1 packets transmitted, 1 packets received, 0% packet loss
round-trip min/avg/max = 1.578/1.578/1.578 ms
# SING finished at Thu Sep 14 10:01:02 2000

This was tested against Solaris 2.5.1, Solaris 2.6 and Solaris 2.7, all
SPARC boxes.

With Sun Solaris turning this option off, will turn off the PMTU discovery
process
with TCP as well. This is not recommended because of performance issues.


Ofir Arkin  [ofir () itcon-ltd com]
Senior Security Analyst
Chief of Grey Hats
ITcon, Israel.
http://www.itcon-ltd.com

Personal Web page: http://www.sys-security.com

"Opinions expressed do not necessarily
represent the views of my employer."