IPv6 maintenance Working Group (6man)                            F. Gont
Internet-Draft                                                   UK CPNI
Updates: 2460, 5722 (if approved)                      December 15, 2011
Intended status: Standards Track
Expires: June 17, 2012


  Security Implications of Predictable Fragment Identification Values
               draft-gont-6man-predictable-fragment-id-00

Abstract

   IPv6 specifies the Fragment Header, which is employed for the
   fragmentation and reassembly mechanisms.  The Fragment Header
   contains an "Identification" field which, together with the IPv6
   Source Address and the IPv6 Destination Address of the packet,
   identifies fragments that correspond to the same original datagram,
   such that they can be reassembled together at the receiving host.
   The only requirement for setting the "Identification" value is that
   it must be different than that of any other fragmented packet sent
   recently with the same Source Address and Destination Address.  Some
   implementations simply use a global counter for setting the Fragment
   Identification field, thus leading to predictable values.  This
   document analyzes the security implications of predictable
   Identification values, and updates RFC 2460 specifying additional
   requirements for setting the Fragment Identification, such that the
   aforementioned security implications are mitigated.

Status of this Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.  This document may not be modified,
   and derivative works of it may not be created, and it may not be
   published except as an Internet-Draft.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on June 17, 2012.

Copyright Notice



Gont                      Expires June 17, 2012                 [Page 1]

Internet-Draft  Implications of Predictable Fragment IDs   December 2011


   Copyright (c) 2011 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Security Implications of Predictable Fragment
       Identification values  . . . . . . . . . . . . . . . . . . . .  4
   3.  Countermeasures  . . . . . . . . . . . . . . . . . . . . . . .  7
     3.1.  Updating RFC 2460  . . . . . . . . . . . . . . . . . . . .  7
     3.2.  Recommended algorithm for selecting Fragment
           Identification values  . . . . . . . . . . . . . . . . . .  7
   4.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  8
   5.  Security Considerations  . . . . . . . . . . . . . . . . . . .  9
   6.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10
   7.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
     7.1.  Normative References . . . . . . . . . . . . . . . . . . . 11
     7.2.  Informative References . . . . . . . . . . . . . . . . . . 11
   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 13





















Gont                      Expires June 17, 2012                 [Page 2]

Internet-Draft  Implications of Predictable Fragment IDs   December 2011


1.  Introduction

   IPv6 specifies the Fragment Header, which is employed for the
   fragmentation and reassembly mechanisms.  The Fragment Header
   contains an "Identification" field which, together with the IPv6
   Source Address and the IPv6 Destination Address of the packet,
   identifies fragments that correspond to the same original datagram,
   such that they can be reassembled together at the receiving host.
   The only requirement for setting the "Identification" value is that
   it must be different than that of any other fragmented packet sent
   recently with the same Source Address and Destination Address.

   The most trivial algorithm to avoid reusing Fragment Identification
   values too quickly is to maintain a global counter that is
   incremented for each fragmented packet that is sent.  However, this
   trivial algorithm leads to predictable Identification values, which
   can be leveraged for performing a variety of attacks.

   Section 2 of this document analyzes the security implications of
   predictable Identification values.  Section 3.1 updates RFC 2460 by
   adding the requirement that Identification values not be predictable
   by an off-path attacker.  Finally, Section 3.2 specifies a
   recommended algorithm for generating Identification values.

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [RFC2119].
























Gont                      Expires June 17, 2012                 [Page 3]

Internet-Draft  Implications of Predictable Fragment IDs   December 2011


2.  Security Implications of Predictable Fragment Identification values

   Predictable Identification values result in an information leakage
   that can be exploited in a number of ways.  Among others, they may
   potentially be exploited to:

   o  determine the packet rate at which a given system is transmitting
      information,

   o  perform stealth port scans to a third-party,

   o  uncover the rules of a number of firewalls,

   o  count the number of systems behind a middle-box, or,

   o  perform a Denial of Service (DoS) attack

   While we are not aware of any existing research on the security
   implications of the Identification field of the Fragment Header, its
   potential security implications are very similar to those of the
   Identification field of IPv4 packets.

      [Sanfilippo1998a] originally pointed out how the IPv4
      Identification field could be examined to determine the packet
      rate at which a given system is transmitting information.  Later,
      [Sanfilippo1998b] described how a system with such an
      implementation could be used to perform a stealth port scan to a
      third (victim) host.  [Sanfilippo1999] explained how to exploit
      this implementation strategy to uncover the rules of a number of
      firewalls.  [Bellovin2002] explains how the IPv4 Identification
      field can be exploited to count the number of systems behind a
      NAT.  [Fyodor2004] is an entire paper on most (if not all) the
      ways to exploit the information provided by the Identification
      field of the IPv4 header (and these results apply in a similar way
      to IPv6).

   One key difference between the IPv4 case and the IPv6 case is that in
   IPv4 the Identification field is part of the fixed IPv4 header (and
   thus usually set for all packets), while in IPv6 the Identification
   field is set only in those packets that employ a Fragment Header.  As
   a result, successful exploitation of the Identification field depends
   on two different factors:

   o  IPv6 implementations using predictable Identification values, and,

   o  the ability of the attacker to cause the victim host to fragment
      packets destined to other nodes




Gont                      Expires June 17, 2012                 [Page 4]

Internet-Draft  Implications of Predictable Fragment IDs   December 2011


   As noted in the previous section, some implementations are known to
   use predictable identification values.

      For example, Linux 2.6.38-8 sets the Identification field
      according to a global counter that is incremented by one for each
      datagram that is sent with a fragment header (either a single
      fragment or as multiple fragments).

   On the other hand, an attacker could cause a victim host to fragment
   its outgoing packets by sending it a forged ICMPv6 'Packet Too Big'
   error message with the Source Address set to that the node with which
   the victim is communicating.  There are two issues that should be
   considered, though:

   o  An attacker can only cause the victim to enable fragmentation on a
      per-destination basis.  That is, the victim will use fragmentation
      only for those packets sent to the IPv6 Source Address of the
      ICMPv6 Packet Too Big error message.

   o  The Path-MTU Discovery specification states that nodes must not
      increase the assumed Path-MTU in response to an ICMPv6 Packet Too
      Big error message (i.e., such error messages only cause the Path-
      MTU to be decreased).  As a result, the MTU advertised in the
      ICMPv6 error message should be smaller than the current Path-MTU
      for that address.

   o  If the victim node implements some of the counter-measures for
      ICMP attacks described in RFC 5927 [RFC5927], it might be
      difficult for an attacker to cause the victim node to use
      fragmentation for its outgoing packets.

      In order to make sure that the forged ICMPv6 Packet Too Big error
      message triggers fragmentation at the victim host, the attacker
      could set the MTU field of the error message to a value smaller
      than 1280 bytes.  Since the minimum IPv6 MTU is 1280 bytes, such
      value would always be smaller than the Path- MTU in use for that
      destination.  It should be noted that RFC 1981 [RFC1981] states
      that when an ICMPv6 Packet Too Big error message with an MTU
      smaller than 1280 bytes is received, the receiving host is not
      required to reduce the Path-MTU for the corresponding destination
      address, but must simply include a Fragment Header in all
      subsequent packets sent to that destination.  Section 6.1.6
      describes an improved processing of these packets that would
      eliminate this attack vector at least in the case of TCP
      connections that employ the Path-MTU Discovery mechanism.






Gont                      Expires June 17, 2012                 [Page 5]

Internet-Draft  Implications of Predictable Fragment IDs   December 2011


      Some implementations do not incorporate countermeasures for
      attacks based on ICMPv6 error messages.  For example, Linux
      2.6.38-8 does not even require received ICMPv6 error messages to
      correspond to ongoing communication instances.

   Implementations that employ predictable Identification values and
   also fail to include countermeasures against attacks based on ICMPv6
   error messages will be vulnerable to attacks similar to those based
   on the IPv4 Identification field for IPv4 networks, such as the
   stealth port-scanning technique described in [Sanfilippo1998b].

   Finally, one possible way in which predictable Identification values
   could be leveraged for performing a Denial of Service (DoS) attack is
   as follows: once the Identification value currently in use at the
   victim host has been learned, the attacker would send a forged ICMPv6
   Packet Too Big error message to the victim host, with its IPv6 Source
   Address set to that of a third-party host with which the victim is
   communicating.  This ICMPv6 Packet Too Big error message would cause
   any packets sent from the victim to the third-party host to include a
   Fragment Header.  The attacker would then send forged IPv6 fragments
   to the third-party host, with their IPv6 Source Address set to that
   of the victim host, and with the Identification field of the forged
   fragments set to values that would result in collisions at the third-
   party host.  If the third-party host discards fragments that result
   in collisions of Identification values, the attacker could simply
   trash the Identification space by sending multiple forged fragments
   with different Identification values, such that any subsequent
   packets from the victim host are discarded at the third-party host as
   a result of the malicious fragments sent by the attacker.

      For example, Linux 2.6.38-10 is vulnerable to the aforementioned
      issue.



















Gont                      Expires June 17, 2012                 [Page 6]

Internet-Draft  Implications of Predictable Fragment IDs   December 2011


3.  Countermeasures

3.1.  Updating RFC 2460

   Hereby we update RFC 2460 [RFC2460] as follows:

   The Identification value of the Fragment Header MUST NOT be
   predictable by an off-path attacker.

   Section 3.2 specifies a RECOMMENDED algorithm for setting the
   Identification value of the Fragment Header.

3.2.  Recommended algorithm for selecting Fragment Identification values

   This section specifies a RECOMMENDED algorithm for setting the
   Fragment Identification field.

   1.  Whenever a packet must be sent with a Fragment Header, the
       sending host should perform a look-up in the Destinations Cache
       an entry corresponding to the intended Destination Address.

   2.  If such an entry exists, it contains the last Fragment
       Identification value used for that Destination.  Therefore, such
       value should be incremented by 1, and used for setting the
       Fragment Identification value of the outgoing packet.
       Additionally, the updated value should be recorded in the
       corresponding entry of the Destination Cache.

   3.  If such an entry does not exist, it should be created, and the
       "Identification" value for that destination should be initialized
       with a random value (e.g., with a pseudorandom number generator),
       and used for setting the Identification field of the Fragment
       Header of the outgoing packet.


















Gont                      Expires June 17, 2012                 [Page 7]

Internet-Draft  Implications of Predictable Fragment IDs   December 2011


4.  IANA Considerations

   There are no IANA registries within this document.  The RFC-Editor
   can remove this section before publication of this document as an
   RFC.














































Gont                      Expires June 17, 2012                 [Page 8]

Internet-Draft  Implications of Predictable Fragment IDs   December 2011


5.  Security Considerations

   This document describes the security implications of predictable
   Fragment Identification values, and updates RFC 2460 such that the
   aforementioned security implications are mitigated.














































Gont                      Expires June 17, 2012                 [Page 9]

Internet-Draft  Implications of Predictable Fragment IDs   December 2011


6.  Acknowledgements

   This document is based on the technical report "Security Assessment
   of the Internet Protocol version 6 (IPv6)" [CPNI-IPv6] authored by
   Fernando Gont on behalf of the UK Centre for the Protection of
   National Infrastructure (CPNI).

   Fernando Gont would like to thank CPNI (http://www.cpni.gov.uk) for
   their continued support.










































Gont                      Expires June 17, 2012                [Page 10]

Internet-Draft  Implications of Predictable Fragment IDs   December 2011


7.  References

7.1.  Normative References

   [RFC1981]  McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery
              for IP version 6", RFC 1981, August 1996.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC2460]  Deering, S. and R. Hinden, "Internet Protocol, Version 6
              (IPv6) Specification", RFC 2460, December 1998.

   [RFC4443]  Conta, A., Deering, S., and M. Gupta, "Internet Control
              Message Protocol (ICMPv6) for the Internet Protocol
              Version 6 (IPv6) Specification", RFC 4443, March 2006.

   [RFC5722]  Krishnan, S., "Handling of Overlapping IPv6 Fragments",
              RFC 5722, December 2009.

7.2.  Informative References

   [RFC5927]  Gont, F., "ICMP Attacks against TCP", RFC 5927, July 2010.

   [RFC6274]  Gont, F., "Security Assessment of the Internet Protocol
              Version 4", RFC 6274, July 2011.

   [Bellovin2002]
              Bellovin, S., "A Technique for Counting NATted Hosts",
              IMW'02 Nov. 6-8, 2002, Marseille, France, 2002.

   [CPNI-IPv6]
              Gont, F., "Security Assessment of the Internet Protocol
              version 6 (IPv6)",  UK Centre for the Protection of
              National Infrastructure, (available on request).

   [Fyodor2004]
              Fyodor, "Idle scanning and related IP ID games", 2004,
              <http://www.insecure.org/nmap/idlescan.html>.

   [PREDICTABLE-ID]
              Gont, F., "Security Implications of Predictable Fragment
              Identification Values", Work in Progress, December 2011.

   [Sanfilippo1998a]
              Sanfilippo, S., "about the ip header id", Post to Bugtraq
              mailing-list, Mon Dec 14 1998,
              <http://www.kyuzz.org/antirez/papers/ipid.html>.



Gont                      Expires June 17, 2012                [Page 11]

Internet-Draft  Implications of Predictable Fragment IDs   December 2011


   [Sanfilippo1998b]
              Sanfilippo, S., "Idle scan", Post to Bugtraq mailing-list,
              1998, <http://www.kyuzz.org/antirez/papers/dumbscan.html>.

   [Sanfilippo1999]
              Sanfilippo, S., "more ip id", Post to Bugtraq mailing-
              list, 1999,
              <http://www.kyuzz.org/antirez/papers/moreipid.html>.











































Gont                      Expires June 17, 2012                [Page 12]

Internet-Draft  Implications of Predictable Fragment IDs   December 2011


Author's Address

   Fernando Gont
   UK CPNI

   Email: fgont@si6networks.com
   URI:   http://www.cpni.gov.uk












































Gont                      Expires June 17, 2012                [Page 13]