Skip to main content

Security Implications of Predictable Fragment Identification Values
draft-ietf-6man-predictable-fragment-id-01

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft that was ultimately published as RFC 7739.
Expired & archived
Author Fernando Gont
Last updated 2014-11-10 (Latest revision 2014-04-29)
Replaces draft-gont-6man-predictable-fragment-id
RFC stream Internet Engineering Task Force (IETF)
Formats
Reviews
Additional resources Mailing list discussion
Stream WG state WG Document
Document shepherd (None)
IESG IESG state Became RFC 7739 (Informational)
Consensus boilerplate Unknown
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-ietf-6man-predictable-fragment-id-01
Appendix A.  Information leakage produced by vulnerable implementations

   Section 3 provides a number of references describing a number of ways
   in which a vulnerable implementation may reveal the Fragment
   Identification values to be used in subsequent packets, thus opening
   the door to a number of attacks.  In all of those scenarios, a
   vulnerable implementation leaks/reveals its own Identification
   number.

   This section presents a different case, in which a vulnerable
   implementation leaks/reveals the Identification number of a non-
   vulnerable implementation.  That is, a vulnerable implementation
   (Host A) leaks the current Fragment Identification value in use by a
   third-party host (Host B) to send fragmented datagrams from Host B to
   Host A.

      For the most part, this section is included to illustrate how a
      vulnerable implementation might be leveraged to leak-out the

Gont                    Expires November 1, 2014               [Page 13]
Internet-Draft  Implications of Predictable Fragment IDs      April 2014

      Fragment Identification value of an otherwise non-vulnerable
      implementation.  This section might be removed in future revisions
      of this document.

   The following scenarios assume:

   Host A:
      Is an IPv6 host that implements the recommended Fragment
      Identification algorithm (Section 6.1), implements [RFC5722], but
      does not implement [RFC6946].

   Host B:
      Victim node.  Selected the Fragment Identification values from a
      global counter.

   Host C:
      Attacker.  Can forge the IPv6 Source Address of his packets at
      will.

   In the following scenarios, large ICMPv6 Echo Request packets are
   employed to "sample" the Fragment Identification value of a host.  We
   note that while the figures show only one packet for the ICMPv6 Echo
   Request and the ICMPv6 Echo Response, each of those packets will
   typically comprise two fragments, such that the resulting datagram is
   larger than the MTU of the networks to which Host B and Host C are
   attached.

   In the lines #1-#2 (and lines #8-#9), the attacker samples the
   current Fragment Identification value.  In line #3, the attacker
   sends a forged TCP SYN segment to Host A. If corresponding TCP port
   is closed, and the attacker fails when trying to produce a collision
   of Fragment Identifications (see line #4), the following packet
   exchange might take place:

       A                          B                               C

   #1                              <------ Echo Req #1 -----------
   #2                              --- Echo Resp #1, FID=5000 --->
   #3  <------------------- SYN #1, src= B -----------------------
   #4                              <--- SYN/ACK, FID=42 src = A---
   #5  ---- SYN/ACK, FID=9000 --->
   #6  <----- RST, FID= 5001 -----
   #7  <----- RST, FID= 5002 -----
   #8                              <-------- Echo Req #2 ---------
   #9                              --- Echo Resp #2, FID=5003 --->

Gont                    Expires November 1, 2014               [Page 14]
Internet-Draft  Implications of Predictable Fragment IDs      April 2014

   On the other hand, if the attacker succeeds to produce a collision of
   Fragment Identification values, the following packet exchange could
   take place:

       A                          B                              C

   #1                              <------- Echo Req #1 ----------
   #2                              --- Echo Resp #1, FID=5000 --->
   #3  <------------------- SYN #1, src= B -----------------------
   #4              <-- SYN/ACK, FID=9000 src=A ---
   #5  ---- SYN/ACK, FID=9000 --->
                           ... (RFC5722) ...
   #6                              <------- Echo Req #2 ----------
   #7                              ---- Echo Resp #2, FID=5001 -->

   Clearly, the Fragment Identification value sampled by from the second
   ICMPv6 Echo Response packet ("Echo Resp #2") implicitly indicates
   whether the Fragment Identification in the forged SYN/ACK (see line
   #4 in both figures) was the current Fragment Identification in use by
   Host A.

   As a result, the attacker could employ this technique to learn the
   current Fragment Identification value used by host A to send packets
   to host B, even when Host A itself has a non-vulnerable
   implementation.

Appendix B.  Survey of Fragment Identification selection algorithms
             employed by popular IPv6 implementations

   This section includes a survey of the Fragment Identification
   selection algorithms employed in some popular operating systems.

      The survey was produced with the SI6 Networks IPv6 toolkit
      [SI6-IPv6].

Gont                    Expires November 1, 2014               [Page 15]
Internet-Draft  Implications of Predictable Fragment IDs      April 2014

   +-----------------------+-------------------------------------------+
   |    Operating System   |                 Algorithm                 |
   +-----------------------+-------------------------------------------+
   |      FreeBSD 9.0      |           Unpredictable (Random)          |
   +-----------------------+-------------------------------------------+
   |     Linux 3.0.0-15    |    Predictable (Global Counter, Init=0,   |
   |                       |                  Incr=1)                  |
   +-----------------------+-------------------------------------------+
   |     Linux-current     |      Unpredictable (Per-dest Counter,     |
   |                       |            Init=random, Incr=1)           |
   +-----------------------+-------------------------------------------+
   |       NetBSD 5.1      |           Unpredictable (Random)          |
   +-----------------------+-------------------------------------------+
   |    OpenBSD-current    |              Random (SKIP32)              |
   +-----------------------+-------------------------------------------+
   |       Solaris 10      |   Predictable (Per-dst Counter, Init=0,   |
   |                       |                  Incr=1)                  |
   +-----------------------+-------------------------------------------+
   |     Windows XP SP2    |    Predictable (Global Counter, Init=0,   |
   |                       |                  Incr=2)                  |
   +-----------------------+-------------------------------------------+
   |  Windows Vista (Build |    Predictable (Global Counter, Init=0,   |
   |         6000)         |                  Incr=2)                  |
   +-----------------------+-------------------------------------------+
   |     Windows 7 Home    |    Predictable (Global Counter, Init=0,   |
   |        Premium        |                  Incr=2)                  |
   +-----------------------+-------------------------------------------+

     Table 1: Fragment Identification algorithms employed by different
                                   OSes

      In the text above, "predictable" should be taken as "easily
      guessable by an off-path attacker, by sending a few probe
      packets".

Author's Address

   Fernando Gont
   SI6 Networks / UTN-FRH
   Evaristo Carriego 2644
   Haedo, Provincia de Buenos Aires  1706
   Argentina

   Phone: +54 11 4650 8472
   Email: fgont@si6networks.com
   URI:   http://www.si6networks.com

Gont                    Expires November 1, 2014               [Page 16]