GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc7739

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]

/data/webs/external/dokuwiki/data/pages/rfc/rfc7739.txt · Last modified: 2016/02/03 01:42 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki