doc: Add RFC documents

1 files changed, 1123 insertions, 0 deletions

diff --git a/doc/rfc/rfc7739.txt b/doc/rfc/rfc7739.txt
new file mode 100644
index 0000000..3a2a82e
--- /dev/null
+++ b/doc/rfc/rfc7739.txt
@@ -0,0 +1,1123 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF)                           F. Gont
+Request for Comments: 7739                           Huawei Technologies
+Category: Informational                                    February 2016
+ISSN: 2070-1721
+
+
+  Security Implications of Predictable Fragment Identification Values
+
+Abstract
+
+   IPv6 specifies the Fragment Header, which is employed for the
+   fragmentation and reassembly mechanisms.  The Fragment Header
+   contains an "Identification" field that, together with the IPv6
+   Source Address and the IPv6 Destination Address of a packet,
+   identifies fragments that correspond to the same original datagram,
+   such that they can be reassembled together by the receiving host.
+   The only requirement for setting the Identification field is that the
+   corresponding value must be different than that employed for any
+   other fragmented datagram sent recently with the same Source Address
+   and Destination Address.  Some implementations use a simple global
+   counter for setting the Identification field, thus leading to
+   predictable Identification values.  This document analyzes the
+   security implications of predictable Identification values, and
+   provides implementation guidance for setting the Identification field
+   of the Fragment Header, such that the aforementioned security
+   implications are mitigated.
+
+Status of This Memo
+
+   This document is not an Internet Standards Track specification; it is
+   published for informational purposes.
+
+   This document is a product of the Internet Engineering Task Force
+   (IETF).  It represents the consensus of the IETF community.  It has
+   received public review and has been approved for publication by the
+   Internet Engineering Steering Group (IESG).  Not all documents
+   approved by the IESG are a candidate for any level of Internet
+   Standard; see Section 2 of RFC 5741.
+
+   Information about the current status of this document, any errata,
+   and how to provide feedback on it may be obtained at
+   http://www.rfc-editor.org/info/rfc7739.
+
+
+
+
+
+
+
+
+
+Gont                          Informational                     [Page 1]
+
+RFC 7739        Implications of Predictable Fragment IDs   February 2016
+
+
+Copyright Notice
+
+   Copyright (c) 2016 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.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
+   3.  Security Implications of Predictable Fragment Identification
+       Values  . . . . . . . . . . . . . . . . . . . . . . . . . . .   3
+   4.  Constraints for the Selection of Fragment Identification
+       Values  . . . . . . . . . . . . . . . . . . . . . . . . . . .   7
+   5.  Algorithms for Selecting Fragment Identification Values . . .   8
+     5.1.  Per-Destination Counter (Initialized to a Random Value) .   8
+     5.2.  Randomized Identification Values  . . . . . . . . . . . .   9
+     5.3.  Hash-Based Fragment Identification Selection Algorithm  .  10
+   6.  Security Considerations . . . . . . . . . . . . . . . . . . .  12
+   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  13
+     7.1.  Normative References  . . . . . . . . . . . . . . . . . .  13
+     7.2.  Informative References  . . . . . . . . . . . . . . . . .  14
+   Appendix A.  Information Leakage Produced by Vulnerable
+                Implementations  . . . . . . . . . . . . . . . . . .  16
+   Appendix B.  Survey of Fragment Identification Selection
+                Algorithms Employed by Popular IPv6 Implementations   18
+   Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .  20
+   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  20
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Gont                          Informational                     [Page 2]
+
+RFC 7739        Implications of Predictable Fragment IDs   February 2016
+
+
+1.  Introduction
+
+   IPv6 specifies the Fragment Header, which is employed for the
+   fragmentation and reassembly mechanisms.  The Fragment Header
+   contains an "Identification" field that, together with the IPv6
+   Source Address and the IPv6 Destination Address of a packet,
+   identifies fragments that correspond to the same original datagram,
+   such that they can be reassembled together by the receiving host.
+   The only requirement for setting the Identification field is that its
+   value must be different than that employed for any other fragmented
+   datagram sent recently with the same Source Address and Destination
+   Address.
+
+   The most trivial algorithm to avoid reusing Identification values too
+   quickly is to maintain a global counter that is incremented for each
+   fragmented datagram that is transmitted.  However, this trivial
+   algorithm leads to predictable Identification values that can be
+   leveraged to perform a variety of attacks.
+
+   Section 3 of this document analyzes the security implications of
+   predictable Identification values.  Section 4 discusses constraints
+   in the possible algorithms for selecting Identification values.
+   Section 5 specifies a number of algorithms that could be used for
+   generating Identification values that mitigate the issues discussed
+   in this document.  Finally, Appendix B contains a survey of the
+   algorithms employed by popular IPv6 implementations for generating
+   the Identification values.
+
+2.  Terminology
+
+   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].
+
+3.  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
+
+
+
+Gont                          Informational                     [Page 3]
+
+RFC 7739        Implications of Predictable Fragment IDs   February 2016
+
+
+   o  perform Denial-of-Service (DoS) attacks, or
+
+   o  perform data injection attacks against transport or application
+      protocols
+
+   The security implications introduced by predictable Identification
+   values in IPv6 are very similar to those of predictable
+   Identification values in IPv4.
+
+   NOTE:
+      [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] explained how the IPv4 Identification
+      field could 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).  [Zalewski2003] originally envisioned the exploitation
+      of IP fragmentation/reassembly for performing data injection
+      attacks against upper-layer protocols.  [Herzberg2013] explores
+      the use of IPv4/IPv6 fragmentation and predictable Identification
+      values for performing DNS cache poisoning attacks in great detail.
+      [RFC6274] covers the security implications of the IPv4 case in
+      detail.
+
+   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 present only in those packets that carry a
+   Fragment Header.  As a result, successful exploitation of the
+   Identification field depends on two different factors:
+
+   o  vulnerable Identification generators, and
+
+   o  the ability of an attacker to trigger the use of IPv6
+      fragmentation for packets sent from/to the victim node
+
+   The scenarios in which an attacker may successfully perform the
+   aforementioned attacks depend on the specific attack type.  For
+   example, in order to perform a DoS attack on communications between
+   two hosts, an attacker would need to know the IPv6 addresses employed
+   by the aforementioned two nodes.  Such knowledge may be readily
+   available if the target of the attack is the communication between
+
+
+
+Gont                          Informational                     [Page 4]
+
+RFC 7739        Implications of Predictable Fragment IDs   February 2016
+
+
+   two specific BGP peers, two specific SMTP servers, or one specific
+   primary DNS server and one of its secondary DNS servers, but may not
+   be easily available if the goal is a DoS attack on all communications
+   between arbitrary IPv6 hosts (e.g., the goal is to perform a DoS
+   attack on all communications involving one specific node with
+   arbitrary/unknown hosts).  Other attacks, such as performing stealth
+   port scans to a third party or determining the packet rate at which a
+   given system is transmitting information, only require the attacker
+   to know the IPv6 address of a vulnerable implementation.
+
+   As noted in Section 1, some implementations have been known to use
+   predictable Identification values.  For instance, Appendix B of this
+   document shows that recent versions of a number of popular IPv6
+   implementations employ predictable values for the Identification
+   field of the Fragment Header.
+
+   Additionally, we note that [RFC2460] states that when an ICMPv6
+   Packet Too Big (PTB) error message advertising a Maximum Transfer
+   Unit (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.  This triggers the use of the so-
+   called IPv6 "atomic fragments" [RFC6946]: IPv6 fragments with a
+   Fragment Offset equal to 0, and the "M" ("More fragments") bit clear.
+   [DEPGEN] documents the motivation of deprecating the generation of
+   IPv6 atomic fragments in [RFC2460].
+
+   Thus, an attacker can usually cause a victim host to "fragment" its
+   outgoing packets by sending it a forged ICMPv6 Packet Too Big (PTB)
+   error message that advertises an MTU smaller than 1280 bytes.
+
+   There are a number of aspects that should be considered, though:
+
+   o  All the implementations the author is aware of record the Path-MTU
+      information on a per-destination basis.  Thus, an attacker can
+      only cause the victim to enable fragmentation for those packets
+      sent to the Source Address of IPv6 packet embedded in the payload
+      of the ICMPv6 PTB message.  However, we note that Section 5.2 of
+      [RFC1981] notes that an implementation could maintain a single
+      system-wide Path MTU (PMTU) value to be used for all packets sent
+      to that node.  Clearly, such implementations would exacerbate the
+      problem of any attacks based on Path MTU Discovery (PMTUD)
+      [RFC5927] or IPv6 fragmentation.
+
+   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 employ
+      fragmentation for its outgoing packets.  However, many current
+
+
+
+Gont                          Informational                     [Page 5]
+
+RFC 7739        Implications of Predictable Fragment IDs   February 2016
+
+
+      implementations fail to enforce these validation checks.  For
+      example, Linux 2.6.38-8 does not even require received ICMPv6
+      error messages to correspond to an ongoing communication instance.
+
+   o  Some implementations (notably Linux) have already been updated
+      according to [DEPGEN] such that ICMPv6 PTB messages do not result
+      in the generation of IPv6 atomic fragments.
+
+   Implementations that employ predictable Identification values and
+   also fail to enforce validation checks on ICMPv6 error messages
+   become vulnerable to the same type of attacks that can be exploited
+   with IPv4 fragmentation, discussed earlier in this section.
+
+   One possible way in which predictable Identification values could be
+   leveraged for performing a DoS attack is as follows: Let us assume
+   that Host A is communicating with Host B, and that an attacker wants
+   to perform a DoS attack such communication.  The attacker would learn
+   the Identification value currently in use by Host A, possibly by
+   sending any packet that would elicit a fragmented response (e.g., an
+   ICPMv6 echo request with a large payload).  The attacker would then
+   send a forged ICMPv6 PTB error message to Host A (with the IPv6
+   Source Address of the embedded IPv6 packet set to the IPv6 address of
+   Host A, and the Destination Address of the embedded IPv6 packet set
+   to the IPv6 address of a Host B), such that any subsequent packets
+   sent by Host A to Host B include a Fragment Header.  Finally, the
+   attacker would send forged IPv6 fragments to Host B, with their IPv6
+   Source Address set to that of Host A, and Identification values that
+   would result in collisions with the Identification values employed
+   for the legitimate traffic sent by Host A to Host B.  If Host B
+   discards fragments that result in collisions of Identification values
+   (e.g., such fragments overlap, and the host implements [RFC5722]),
+   the attacker could simply trash the Identification space by sending
+   multiple forged fragments with different Identification values, such
+   that any subsequent packets from Host A to Host B are discarded at
+   Host B as a result of the malicious fragments sent by the attacker.
+
+   NOTE:
+      For example, Linux 2.6.38-10 is vulnerable to the aforementioned
+      issue.
+
+      [RFC6946] describes an improved processing of these packets that
+      would eliminate this specific attack vector, at least in the case
+      of TCP connections that employ the Path-MTU Discovery mechanism.
+
+   The aforementioned attack scenario is simply included to illustrate
+   the problem of employing predictable Identification values.  We note
+   that regardless of the attacker's ability to cause a victim host to
+
+
+
+
+Gont                          Informational                     [Page 6]
+
+RFC 7739        Implications of Predictable Fragment IDs   February 2016
+
+
+   employ fragmentation when communicating with third parties, use of
+   predictable Identification values makes communication flows that
+   employ fragmentation vulnerable to any fragmentation-based attacks.
+
+4.  Constraints for the Selection of Fragment Identification Values
+
+   The Identification field of the Fragment Header is 32-bits long.
+   However, when translators (e.g.  [RFC6145]) are employed, the high-
+   order 16 bits of the Identification field are effectively ignored.
+
+   NOTE:
+      [RFC6145] notes that, when translating in the IPv6-to-IPv4
+      direction, "if there is a Fragment Header in the IPv6 packet, the
+      last 16 bits of its value MUST be used for the IPv4 identification
+      value".
+
+      Additionally, Section 3.3 of [RFC6052] encourages operators to use
+      a Network-Specific Prefix (NSP) that maps the IPv4 address space
+      into IPv6.  Thus, when an NSP is being used, IPv6 addresses
+      representing IPv4 nodes (reached through a stateless translator)
+      are indistinguishable from native IPv6 addresses.
+
+   Thus, when translators are employed, the "effective" length of the
+   Identification field is 16 bits and, as a result, at least during the
+   IPv6/IPv4 transition/co-existence phase, it is probably safer to
+   assume that only the low-order 16 bits of the Identification field
+   are of use to the destination system.
+
+   Regarding the selection of Identification values, the only
+   requirement specified in [RFC2460] is that the Identification value
+   must be different than that of any other fragmented packet sent
+   recently with the same Source Address and Destination Address.
+   Failure to comply with this requirement could lead to the
+   interoperability problems discussed in [RFC4963].
+
+   From a security standpoint, unpredictable Identification values are
+   desirable.  However, this is somewhat at odds with the "reuse"
+   requirements specified in [RFC2460], that specifies that an
+   Identification value must be different than that employed for any
+   other fragmented packet sent recently with the same Source Address
+   and Destination Address.
+
+   Finally, since Identification values need to be selected for each
+   outgoing datagram that requires fragmentation, the performance impact
+   should be considered when choosing an algorithm for the selection of
+   Identification values.
+
+
+
+
+
+Gont                          Informational                     [Page 7]
+
+RFC 7739        Implications of Predictable Fragment IDs   February 2016
+
+
+5.  Algorithms for Selecting Fragment Identification Values
+
+   There are a number of algorithms that may be used for setting the
+   Identification field such that the security issues discussed in this
+   document are avoided.  This section presents three of those.
+
+   The algorithm in Section 5.1 typically leads to a low Identification
+   reuse frequency at the expense of keeping per-destination state; this
+   algorithm only uses a Pseudorandom Number Generator (PNRG) when the
+   host communicates with a new destination.  The algorithm in
+   Section 5.2 may result in a higher Identification reuse frequency.
+   It also uses a PRNG for each datagram that needs to be fragmented.
+   Hence, the algorithm in Section 5.1 will likely result in better
+   performance properties.  Finally, the algorithm in Section 5.3
+   achieves a similar Identification reuse frequency to that of the
+   algorithm in Section 5.1 without the need of keeping state, but
+   possibly at the expense of lower per-packet performance.
+
+   NOTE:
+      Since the specific algorithm to be employed for the PRNGs in
+      Section 5.1 and Section 5.2, and the specific algorithms to be
+      employed for the hash functions in Section 5.3 have not been
+      specified, it is impossible to provide a quantitative performance
+      comparison of the algorithms described in this section.
+
+5.1.  Per-Destination Counter (Initialized to a Random Value)
+
+   This algorithm consists of the following steps:
+
+   1.  Whenever a packet must be sent with a Fragment Header, the
+       sending host should look up in the Destination Cache an entry
+       corresponding to the Destination Address of the packet.
+
+   2.  If such an entry exists, it contains the last Identification
+       value used for that Destination Address.  Therefore, such a value
+       should be incremented by 1 and used for setting the
+       Identification field of the outgoing packet.  Additionally, the
+       updated value should be recorded in the corresponding entry of
+       the Destination Cache [RFC4861].
+
+   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 fragmented datagram.
+
+
+
+
+
+
+Gont                          Informational                     [Page 8]
+
+RFC 7739        Implications of Predictable Fragment IDs   February 2016
+
+
+   The advantages of this algorithm are:
+
+   o  It is simple to implement, with the only complexity residing in
+      the PRNG used to initialize the Identification value contained in
+      each entry of the Destination Cache.
+
+   o  The Identification reuse frequency will typically be lower than
+      that achieved by a global counter (when sending traffic to
+      multiple destinations), since this algorithm uses per-destination
+      counters (rather than a single system-wide counter).
+
+   o  It has good performance properties (once the corresponding entry
+      in the Destination Cache has been created and initialized, each
+      subsequent Identification value simply involves the increment of a
+      counter).
+
+   The possible drawbacks of this algorithm are:
+
+   o  If, as a result of resource management, an entry of the
+      Destination Cache must be removed, the last Identification value
+      used for that Destination will be lost.  Thus, subsequent traffic
+      to that destination would cause that entry to be recreated and
+      reinitialized to random value, thus possibly leading to
+      Identification "collisions".
+
+   o  Since the Identification values are predictable by the destination
+      host, a vulnerable host might possibly leak to third parties the
+      Identification values used by other hosts to send traffic to it
+      (i.e., Host B could leak to Host C the Identification values that
+      Host A is using to send packets to Host B).  Appendix A describes
+      one possible scenario for such leakage in detail.
+
+5.2.  Randomized Identification Values
+
+   Clearly, use of a Pseudorandom Number Generator for selecting the
+   Identification would be desirable from a security standpoint.  With
+   such a scheme, the Identification of each fragmented datagram would
+   be selected as:
+
+                  Identification = random()
+
+   where "random()" is the PRNG.
+
+   The specific properties of such scheme would clearly depend on the
+   specific PRNG employed.  For example, some PRNGs may result in higher
+   Identification reuse frequencies than others, in the same way that
+   some PRNGs may be more expensive (in terms of processing requirements
+   and/or implementation complexity) than others.
+
+
+
+Gont                          Informational                     [Page 9]
+
+RFC 7739        Implications of Predictable Fragment IDs   February 2016
+
+
+   Discussion of the properties of possible PRNGs is considered out of
+   the scope of this document.  However, we do note that some PRNGs
+   employed in the past by some implementations have been found to be
+   predictable [Klein2007].  Please see [RFC4086] for randomness
+   requirements for security.
+
+5.3.  Hash-Based Fragment Identification Selection Algorithm
+
+   Another alternative is to implement a hash-based algorithm similar to
+   that specified in [RFC6056] for the selection of transport port
+   numbers.  With such a scheme, the Identification value of each
+   fragmented datagram would be selected with the expression:
+
+   Identification = F(Src IP, Dst IP, secret1)  +
+                    counter[G(Src IP, Dst Pref, secret2)]
+
+   where:
+
+   Identification:
+      Identification value to be used for the fragmented datagram.
+
+   F():
+      Hash function.
+
+   Src IP:
+      IPv6 Source Address of the datagram to be fragmented.
+
+   Dst IP:
+      IPv6 Destination Address of the datagram to be fragmented.
+
+   secret1:
+      Secret data unknown to the attacker.  This value can be
+      initialized to a pseudo-random value during the system
+      bootstrapping sequence.  It should remain constant at least while
+      there could be previously sent fragments still in the network or
+      at the fragment reassembly buffer of the corresponding destination
+      system(s).
+
+   counter[]:
+      System-wide array of 32-bit counters (e.g. with 8K elements or
+      more).  Each counter should be initialized to a pseudo-random
+      value during the system bootstrapping sequence.
+
+   G():
+      Hash function.  It may or may not be the same hash function as
+      that used for F().
+
+
+
+
+
+Gont                          Informational                    [Page 10]
+
+RFC 7739        Implications of Predictable Fragment IDs   February 2016
+
+
+   Dst Pref:
+      IPv6 "Destination Prefix" of the datagram to be fragmented (can be
+      assumed to be the first eight bytes of the Destination Address of
+      such packet).  Note: the "Destination Prefix" (rather than
+      Destination Address) is used, such that the ability of an attacker
+      of searching the "increments" space by using multiple addresses of
+      the same subnet is reduced.
+
+   secret2:
+      Secret data unknown to the attacker.  This value can be
+      initialized to a pseudo-random value during the system
+      bootstrapping sequence.  It should remain constant at least while
+      there could be previously sent fragments still in the network or
+      at the fragment reassembly buffer of the corresponding destination
+      system(s).
+
+   NOTE:
+      counter[G(src IP, Dst Pref, secret2)] should be incremented by one
+      each time an Identification value is selected.
+
+   The output of F() will be constant for each (Src IP, Dst IP) pair.
+   Similarly, the output of G() will be constant for each (Src IP, Dst
+   Pref) pair.  Thus, the resulting Identification value will be the
+   result of a random offset plus a linear function (provided by
+   counter[]), therefore resulting in a monotonically increasing
+   sequence of Identification values for each (src IP, Dst IP) pair.
+
+   NOTE:
+      F() essentially provides the unpredictability (by off-path
+      attackers) of the resulting Identification values, while counter[]
+      provides a linear function such that the Identification values are
+      different for each fragmented packet while the Identification
+      reuse frequency is minimized.
+
+   The advantages of this algorithm are:
+
+   o  The Identification reuse frequency will typically be lower than
+      that achieved by a global counter (when sending traffic to
+      multiple destinations), since this algorithm uses multiple system-
+      wide counters (rather than a single system-wide counter).  The
+      extent to which the reuse frequency will be lower depends on the
+      number of elements in counter[], and the number of other active
+      flows that result in the same value of G() (and hence cause the
+      same counter to be incremented for each datagram that is
+      fragmented).
+
+
+
+
+
+
+Gont                          Informational                    [Page 11]
+
+RFC 7739        Implications of Predictable Fragment IDs   February 2016
+
+
+   o  It is possible to implement the algorithm such that good
+      performance is achieved.  For example, the result of F() could be
+      stored in the Destination Cache (such that it need not be
+      recomputed for each packet that must be sent) along with the
+      computed index/argument for counter[].
+
+      NOTE:
+         If this implementation approach is followed, and an entry of
+         the Destination Cache must be removed as a result of resource
+         management, the last Identification value used for that
+         Destination will *not* be lost.  This is an improvement over
+         the algorithm specified in Section 5.1.
+
+   The possible drawbacks of this algorithm are:
+
+   o  Since the Identification values are predictable by the destination
+      host, a vulnerable host could possibly leak to third parties the
+      Identification values used by other hosts to send traffic to it
+      (i.e., Host B could leak to Host C the Identification values that
+      Host A is using to send packets to Host B).  Appendix A describes
+      a possible scenario in which that information leakage could take
+      place.  We note, however, that this algorithm makes the
+      aforementioned attack less reliable for the attacker, since each
+      counter could be possibly shared by multiple traffic flows (i.e.,
+      packets destined to other destinations might cause the same
+      counter to be incremented).
+
+   This algorithm might be preferable (over the one specified in
+   Section 5.1) in those scenarios in which a node is expected to
+   communicate with a large number of destinations, and thus it is
+   desirable to limit the amount of information to be maintained in
+   memory.
+
+   NOTE:
+      In such scenarios, if the algorithm specified in Section 5.1 were
+      implemented, entries from the Destination Cache might need to be
+      pruned frequently, thus increasing the risk of Identification
+      "collisions".
+
+6.  Security Considerations
+
+   This document discusses the security implications of predictable
+   Identification values, and provides implementation guidance such that
+   the aforementioned security implications can be mitigated.
+
+
+
+
+
+
+
+Gont                          Informational                    [Page 12]
+
+RFC 7739        Implications of Predictable Fragment IDs   February 2016
+
+
+   A number of possible algorithms are described, to provide some
+   implementation alternatives to implementers.  We note that the
+   selection of such an algorithm usually implies a number of trade-offs
+   (security, performance, implementation complexity, interoperability
+   properties, etc.).
+
+7.  References
+
+7.1.  Normative References
+
+   [RFC1981]  McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery
+              for IP version 6", RFC 1981, DOI 10.17487/RFC1981, August
+              1996, <http://www.rfc-editor.org/info/rfc1981>.
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119,
+              DOI 10.17487/RFC2119, March 1997,
+              <http://www.rfc-editor.org/info/rfc2119>.
+
+   [RFC2460]  Deering, S. and R. Hinden, "Internet Protocol, Version 6
+              (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460,
+              December 1998, <http://www.rfc-editor.org/info/rfc2460>.
+
+   [RFC4086]  Eastlake 3rd, D., Schiller, J., and S. Crocker,
+              "Randomness Requirements for Security", BCP 106, RFC 4086,
+              DOI 10.17487/RFC4086, June 2005,
+              <http://www.rfc-editor.org/info/rfc4086>.
+
+   [RFC4861]  Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
+              "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
+              DOI 10.17487/RFC4861, September 2007,
+              <http://www.rfc-editor.org/info/rfc4861>.
+
+   [RFC5722]  Krishnan, S., "Handling of Overlapping IPv6 Fragments",
+              RFC 5722, DOI 10.17487/RFC5722, December 2009,
+              <http://www.rfc-editor.org/info/rfc5722>.
+
+   [RFC6052]  Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X.
+              Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052,
+              DOI 10.17487/RFC6052, October 2010,
+              <http://www.rfc-editor.org/info/rfc6052>.
+
+   [RFC6056]  Larsen, M. and F. Gont, "Recommendations for Transport-
+              Protocol Port Randomization", BCP 156, RFC 6056,
+              DOI 10.17487/RFC6056, January 2011,
+              <http://www.rfc-editor.org/info/rfc6056>.
+
+
+
+
+
+Gont                          Informational                    [Page 13]
+
+RFC 7739        Implications of Predictable Fragment IDs   February 2016
+
+
+   [RFC6145]  Li, X., Bao, C., and F. Baker, "IP/ICMP Translation
+              Algorithm", RFC 6145, DOI 10.17487/RFC6145, April 2011,
+              <http://www.rfc-editor.org/info/rfc6145>.
+
+   [RFC6946]  Gont, F., "Processing of IPv6 "Atomic" Fragments",
+              RFC 6946, DOI 10.17487/RFC6946, May 2013,
+              <http://www.rfc-editor.org/info/rfc6946>.
+
+7.2.  Informative References
+
+   [RFC4963]  Heffner, J., Mathis, M., and B. Chandler, "IPv4 Reassembly
+              Errors at High Data Rates", RFC 4963,
+              DOI 10.17487/RFC4963, July 2007,
+              <http://www.rfc-editor.org/info/rfc4963>.
+
+   [RFC5927]  Gont, F., "ICMP Attacks against TCP", RFC 5927,
+              DOI 10.17487/RFC5927, July 2010,
+              <http://www.rfc-editor.org/info/rfc5927>.
+
+   [RFC6274]  Gont, F., "Security Assessment of the Internet Protocol
+              Version 4", RFC 6274, DOI 10.17487/RFC6274, July 2011,
+              <http://www.rfc-editor.org/info/rfc6274>.
+
+   [DEPGEN]   Gont, F., Liu, S., and T. Anderson, "Generation of IPv6
+              Atomic Fragments Considered Harmful", Work in Progress,
+              draft-ietf-6man-deprecate-atomfrag-generation-05, January
+              2016.
+
+   [Bellovin2002]
+              Bellovin, S., "A Technique for Counting NATted Hosts",
+              IMW'02 Nov. 6-8, 2002, Marseille, France,
+              DOI 10.1145/637201.637243, 2002.
+
+   [Fyodor2004]
+              Lyon, G., "TCP Idle Scan", from Chapter 5 of "Nmap Network
+              Scanning", 2004,
+              <http://www.insecure.org/nmap/idlescan.html>.
+
+   [Herzberg2013]
+              Herzberg, A. and H. Shulman, "Fragmentation Considered
+              Poisonous", Technical Report 13-03, March 2013,
+              <http://u.cs.biu.ac.il/~herzbea/security/13-03-frag.pdf>.
+
+   [Klein2007]
+              Klein, A., "OpenBSD DNS Cache Poisoning and Multiple O/S
+              Predictable IP ID Vulnerability", 2007,
+              <http://www.trusteer.com/files/OpenBSD_DNS_Cache_Poisoning
+              _and_Multiple_OS_Predictable_IP_ID_Vulnerability.pdf>.
+
+
+
+Gont                          Informational                    [Page 14]
+
+RFC 7739        Implications of Predictable Fragment IDs   February 2016
+
+
+   [Sanfilippo1998a]
+              Sanfilippo, S., "Subject: about the ip header id", message
+              to Bugtraq mailing list, 14 December 1998,
+              <http://diswww.mit.edu/menelaus.mit.edu/bt/8704>.
+
+   [Sanfilippo1998b]
+              Sanfilippo, S., "Subject: new tcp scan method", message
+              to Bugtraq mailing list, 18 December 1998,
+              <http://diswww.mit.edu/menelaus.mit.edu/bt/8736>.
+
+   [Sanfilippo1999]
+              Sanfilippo, S., "Subject: more about IP ID", message
+              to Bugtraq mailing list, 20 November 1999,
+              <http://diswww.mit.edu/menelaus.mit.edu/bt/12686>.
+
+   [SI6-IPv6] SI6 Networks, "SI6 Networks' IPv6 Toolkit",
+              <http://www.si6networks.com/tools/ipv6toolkit>.
+
+   [Zalewski2003]
+              Zalewski, M., "Subject: A new TCP/IP blind data injection
+              technique?", message to Bugtraq mailing list, 11 December
+              2003, <http://lcamtuf.coredump.cx/ipfrag.txt>.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Gont                          Informational                    [Page 15]
+
+RFC 7739        Implications of Predictable Fragment IDs   February 2016
+
+
+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 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 attack scenario, 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 Identification value in use
+   by a third-party host (Host B) to send fragmented datagrams from Host
+   B to Host A.
+
+   NOTE:
+      For the most part, this section is included to illustrate how a
+      vulnerable implementation might be leveraged to leak out the
+      Identification value of an otherwise non-vulnerable
+      implementation.
+
+   The following scenarios assume:
+
+   Host A:
+      An IPv6 host that implements the algorithm specified in
+      Section 5.1, implements [RFC5722], but does not implement
+      [RFC6946].
+
+   Host B:
+      Victim node.  Selects the 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 Identification value of a host.  We note
+   that while the figures show only one packet for the ICMPv6 Echo
+   Request and the ICMPv6 Echo Reply packets, each of those packets will
+   typically comprise two fragments, such that the corresponding
+   unfragmented datagram is larger than the MTU of the networks to which
+   Host B and Host C are attached.  Additionally, the following
+   scenarios assume that Host A employs a Fragment Header when sending
+   traffic to Host B (typically the so-called "IPv6 atomic fragments"
+   [RFC6946]): this behavior may be triggered by forged ICMPv6 PTB
+   messages that advertise an MTU smaller than 1280 bytes (assuming the
+   victim still generates atomic fragments [DEPGEN]).
+
+
+
+Gont                          Informational                    [Page 16]
+
+RFC 7739        Implications of Predictable Fragment IDs   February 2016
+
+
+   In lines #1-#2 (and lines #7-#8), the attacker samples the current
+   Identification value at Host B.  In line #3, the attacker sends a
+   forged TCP SYN segment to Host A.  In line 4, the attacker sends a
+   forged TCP segment to Host B as an incomplete IPv6 fragmented
+   datagram (e.g., a single fragment with Fragment Offset=0, More
+   fragments=1).  If corresponding TCP port is closed, and the attacker
+   fails when trying to produce a collision of Identification values
+   (see line #4), the following packet exchange might take place:
+
+       A                          B                              C
+
+   #1                              <------ Echo Req #1 -----------
+   #2                              --- Echo Repl #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                              <-------- Echo Req #2 ---------
+   #8                              --- Echo Repl #2, FID=5002 --->
+
+   The RST segment in line #6 is elicited by the SYN/ACK segment from
+   line #5 (illegitimately elicited by the SYN segment from line #3).
+   The packet from line #4, sent as an incomplete IPv6 datagram,
+   eventually times out.
+
+   On the other hand, if the attacker succeeds to produce a collision of
+   Identification values, the following packet exchange could take
+   place:
+
+       A                          B                              C
+
+   #1                              <------- Echo Req #1 ----------
+   #2                              --- Echo Repl #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 Repl #2, FID=5001 -->
+
+   Clearly, the Identification value sampled from the second ICMPv6 Echo
+   Reply packet ("Echo Repl #2") implicitly indicates whether the
+   Identification value in the forged SYN/ACK (see line #4 in both
+   figures) was the current Identification value in use by Host A.
+
+   As a result, the attacker could employ this technique to learn the
+   current Identification value used by host A to send packets to host
+   B, even when Host A itself has a non-vulnerable implementation.
+
+
+
+Gont                          Informational                    [Page 17]
+
+RFC 7739        Implications of Predictable Fragment IDs   February 2016
+
+
+Appendix B.  Survey of Fragment Identification Selection Algorithms
+             Employed by Popular IPv6 Implementations
+
+   This section includes a survey of the Identification selection
+   algorithms employed by some popular operating systems.
+
+   NOTE:
+      The survey was produced with the SI6 Networks' IPv6 toolkit
+      [SI6-IPv6].
+
+   +------------------------------+------------------------------------+
+   |       Operating System       |             Algorithm              |
+   +------------------------------+------------------------------------+
+   |        Cisco IOS 15.3        |    Predictable (Global Counter,    |
+   |                              |          Init=0, Incr=1)           |
+   +------------------------------+------------------------------------+
+   |         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        |   Unpredictable (Random, SKIP32)   |
+   +------------------------------+------------------------------------+
+   |          Solaris 10          |   Predictable (Per-dst Counter,    |
+   |                              |          Init=0, Incr=1)           |
+   +------------------------------+------------------------------------+
+   |        Windows XP SP2        |    Predictable (Global Counter,    |
+   |                              |          Init=0, Incr=2)           |
+   +------------------------------+------------------------------------+
+   |   Windows XP Professional    |    Predictable (Global Counter,    |
+   |          32bit, SP3          |          Init=0, Incr=2)           |
+   +------------------------------+------------------------------------+
+   |  Windows Vista (Build 6000)  |    Predictable (Global Counter,    |
+   |                              |          Init=0, Incr=2)           |
+   +------------------------------+------------------------------------+
+   |    Windows Vista Business    |    Predictable (Global Counter,    |
+   |          64bit, SP1          |          Init=0, Incr=2)           |
+   +------------------------------+------------------------------------+
+   |    Windows 7 Home Premium    |    Predictable (Global Counter,    |
+   |                              |          Init=0, Incr=2)           |
+   +------------------------------+------------------------------------+
+   |    Windows Server 2003 R2    |    Predictable (Global Counter,    |
+   |     Standard 64bit, SP2      |          Init=0, Incr=2)           |
+
+
+
+Gont                          Informational                    [Page 18]
+
+RFC 7739        Implications of Predictable Fragment IDs   February 2016
+
+
+   +------------------------------+------------------------------------+
+   | Windows Server 2008 Standard |    Predictable (Global Counter,    |
+   |          32bit, SP1          |          Init=0, Incr=2)           |
+   +------------------------------+------------------------------------+
+   |    Windows Server 2008 R2    |    Predictable (Global Counter,    |
+   |     Standard 64bit, SP1      |          Init=0, Incr=2)           |
+   +------------------------------+------------------------------------+
+   | Windows Server 2012 Standard |    Predictable (Global Counter,    |
+   |            64bit             |          Init=0, Incr=2)           |
+   +------------------------------+------------------------------------+
+   |    Windows 7 Home Premium    |    Predictable (Global Counter,    |
+   |          32bit, SP1          |          Init=0, Incr=2)           |
+   +------------------------------+------------------------------------+
+   |  Windows 7 Ultimate 32bit,   |    Predictable (Global Counter,    |
+   |             SP1              |          Init=0, Incr=2)           |
+   +------------------------------+------------------------------------+
+   | Windows 8 Enterprise 32 bit  |  Unpredictable (Alg. from Section  |
+   |                              |                5.3)                |
+   +------------------------------+------------------------------------+
+
+   Table 1: Fragment Identification algorithms employed by different OSs
+
+   NOTE:
+      In the text above, "predictable" should be taken as "easily
+      guessable by an off-path attacker, by sending a few probe
+      packets".
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Gont                          Informational                    [Page 19]
+
+RFC 7739        Implications of Predictable Fragment IDs   February 2016
+
+
+Acknowledgements
+
+   The author would like to thank Ivan Arce for proposing the attack
+   scenario described in Appendix A.
+
+   The author would like to thank Ivan Arce, Stephen Bensley, Ron
+   Bonica, Tassos Chatzithomaoglou, Guillermo Gont, Brian Haberman, Bob
+   Hinden, Sheng Jiang, Tatuya Jinmei, Merike Kaeo, Will Liu, Juan
+   Antonio Matos, Simon Perreault, Hosnieh Rafiee, Meral Shirazipour,
+   Mark Smith, Dave Thaler, and Klaas Wierenga, for providing valuable
+   comments on earlier draft versions of this document.
+
+   This document is based on work performed by Fernando Gont on behalf
+   of the UK Centre for the Protection of National Infrastructure
+   (CPNI).
+
+   The author would like to thank Buffy for her love and support.
+
+Author's Address
+
+   Fernando Gont
+   Huawei Technologies
+   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                          Informational                    [Page 20]
+