< draft-gont-6man-predictable-fragment-id-01.txt   draft-gont-6man-predictable-fragment-id-02.txt >
IPv6 maintenance Working Group (6man) F. Gont IPv6 maintenance Working Group (6man) F. Gont
Internet-Draft UK CPNI Internet-Draft UK CPNI
Updates: 2460, 5722 (if approved) March 3, 2012 Updates: 2460, 5722 (if approved) March 29, 2012
Intended status: Standards Track Intended status: Standards Track
Expires: September 4, 2012 Expires: September 30, 2012
Security Implications of Predictable Fragment Identification Values Security Implications of Predictable Fragment Identification Values
draft-gont-6man-predictable-fragment-id-01 draft-gont-6man-predictable-fragment-id-02
Abstract Abstract
IPv6 specifies the Fragment Header, which is employed for the IPv6 specifies the Fragment Header, which is employed for the
fragmentation and reassembly mechanisms. The Fragment Header fragmentation and reassembly mechanisms. The Fragment Header
contains an "Identification" field which, together with the IPv6 contains an "Identification" field which, together with the IPv6
Source Address and the IPv6 Destination Address of the packet, Source Address and the IPv6 Destination Address of the packet,
identifies fragments that correspond to the same original datagram, identifies fragments that correspond to the same original datagram,
such that they can be reassembled together at the receiving host. such that they can be reassembled together at the receiving host.
The only requirement for setting the "Identification" value is that The only requirement for setting the "Identification" value is that
skipping to change at page 1, line 47 skipping to change at page 1, line 47
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 4, 2012. This Internet-Draft will expire on September 30, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
skipping to change at page 2, line 26 skipping to change at page 2, line 26
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Security Implications of Predictable Fragment 2. Security Implications of Predictable Fragment
Identification values . . . . . . . . . . . . . . . . . . . . 4 Identification values . . . . . . . . . . . . . . . . . . . . 4
3. Updating RFC 2460 . . . . . . . . . . . . . . . . . . . . . . 7 3. Updating RFC 2460 . . . . . . . . . . . . . . . . . . . . . . 7
4. Constraints for the selection of Fragment Identification 4. Constraints for the selection of Fragment Identification
Values . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 Values . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
5. Algorithms for Selecting Fragment Identification Values . . . 9 5. Algorithms for Selecting Fragment Identification Values . . . 9
5.1. Recommended algorithm . . . . . . . . . . . . . . . . . . 9 5.1. Per-destination counter (initialized to a random value) . 9
5.2. Randomized Identification values . . . . . . . . . . . . . 10 5.2. Randomized Identification values . . . . . . . . . . . . . 10
5.3. Hash-based Fragment Identification selection algorithm . . 10 5.3. Hash-based Fragment Identification selection algorithm . . 10
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
7. Security Considerations . . . . . . . . . . . . . . . . . . . 14 7. Security Considerations . . . . . . . . . . . . . . . . . . . 14
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
9.1. Normative References . . . . . . . . . . . . . . . . . . . 16 9.1. Normative References . . . . . . . . . . . . . . . . . . . 16
9.2. Informative References . . . . . . . . . . . . . . . . . . 16 9.2. Informative References . . . . . . . . . . . . . . . . . . 16
Appendix A. Information leakage produced by vulnerable Appendix A. Information leakage produced by vulnerable
implementations . . . . . . . . . . . . . . . . . . . 18 implementations . . . . . . . . . . . . . . . . . . . 18
Appendix B. Changes from previous versions of the document Appendix B. Changes from previous versions of the document
(to be removed by the RFC Editor before (to be removed by the RFC Editor before
publication of this document as a RFC) . . . . . . . 20 publication of this document as a RFC) . . . . . . . 20
B.1. Changes from draft-gont-6man-predictable-fragment-id-00 . 20 B.1. Changes from draft-gont-6man-predictable-fragment-id-01 . 20
B.2. Changes from draft-gont-6man-predictable-fragment-id-00 . 20
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 21 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 21
1. Introduction 1. Introduction
IPv6 specifies the Fragment Header, which is employed for the IPv6 specifies the Fragment Header, which is employed for the
fragmentation and reassembly mechanisms. The Fragment Header fragmentation and reassembly mechanisms. The Fragment Header
contains an "Identification" field which, together with the IPv6 contains an "Identification" field which, together with the IPv6
Source Address and the IPv6 Destination Address of the packet, Source Address and the IPv6 Destination Address of the packet,
identifies fragments that correspond to the same original datagram, identifies fragments that correspond to the same original datagram,
such that they can be reassembled together at the receiving host. such that they can be reassembled together at the receiving host.
skipping to change at page 7, line 12 skipping to change at page 8, line 5
that employ fragmentation vulnerable to any fragmentation-based that employ fragmentation vulnerable to any fragmentation-based
attacks. attacks.
3. Updating RFC 2460 3. Updating RFC 2460
Hereby we update RFC 2460 [RFC2460] as follows: Hereby we update RFC 2460 [RFC2460] as follows:
The Identification value of the Fragment Header MUST NOT be The Identification value of the Fragment Header MUST NOT be
predictable by an off-path attacker. predictable by an off-path attacker.
Section 5 specifies the RECOMMENDED algorithm for setting the
Identification value of the Fragment Header.
4. Constraints for the selection of Fragment Identification Values 4. Constraints for the selection of Fragment Identification Values
the "Identification" field of the Fragmentation Header is 32-bits the "Identification" field of the Fragmentation Header is 32-bits
long. However, when translators [RFC6145] are employed, the long. However, when translators [RFC6145] are employed, the
"effective" length of the IPv6 Fragment Identification field is 16 "effective" length of the IPv6 Fragment Identification field is 16
bits. bits.
[RFC6145] notes that, when translating in the IPv6-to-IPv4 [RFC6145] notes that, when translating in the IPv6-to-IPv4
direction, "if there is a Fragment Header in the IPv6 packet, the 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 last 16 bits of its value MUST be used for the IPv4 identification
skipping to change at page 9, line 7 skipping to change at page 9, line 7
desirable. However, this is somewhat at odds with the "re-use" desirable. However, this is somewhat at odds with the "re-use"
requirements specified in [RFC2460]. requirements specified in [RFC2460].
Finally, since Fragment Identification values need to be selected for Finally, since Fragment Identification values need to be selected for
each outgoing datagram that requires fragmentation, the performance each outgoing datagram that requires fragmentation, the performance
aspect should be considered when choosing an algorithm for the aspect should be considered when choosing an algorithm for the
selection of Fragment Identification values. selection of Fragment Identification values.
5. Algorithms for Selecting Fragment Identification Values 5. Algorithms for Selecting Fragment Identification Values
Section 5.1 specifies the RECOMMENDED algorithm for setting the This section specifies a number of algorithms that MAY be used for
Fragment Identification field. Section 5.2 and Section 5.3 describes selecting Fragment Identification values.
other algorithms that MAY alternatively be employed.
5.1. Recommended algorithm
This section specifies the RECOMMENDED algorithm for the selection of 5.1. Per-destination counter (initialized to a random value)
Fragment Identification values.
1. Whenever a packet must be sent with a Fragment Header, the 1. Whenever a packet must be sent with a Fragment Header, the
sending host should perform a look-up in the Destinations Cache sending host should perform a look-up in the Destinations Cache
an entry corresponding to the intended Destination Address. an entry corresponding to the intended Destination Address.
2. If such an entry exists, it contains the last Fragment 2. If such an entry exists, it contains the last Fragment
Identification value used for that Destination. Therefore, such Identification value used for that Destination. Therefore, such
value should be incremented by 1, and used for setting the value should be incremented by 1, and used for setting the
Fragment Identification value of the outgoing packet. Fragment Identification value of the outgoing packet.
Additionally, the updated value should be recorded in the Additionally, the updated value should be recorded in the
skipping to change at page 9, line 36 skipping to change at page 9, line 32
3. If such an entry does not exist, it should be created, and the 3. If such an entry does not exist, it should be created, and the
"Identification" value for that destination should be initialized "Identification" value for that destination should be initialized
with a random value (e.g., with a pseudorandom number generator), with a random value (e.g., with a pseudorandom number generator),
and used for setting the Identification field of the Fragment and used for setting the Identification field of the Fragment
Header of the outgoing packet. Header of the outgoing packet.
The advantages of this algorithm are: The advantages of this algorithm are:
o It is simple to implement, with the only complexity residing in o It is simple to implement, with the only complexity residing in
the PRNG used to initialize the "Identification" value contained the Pseudo-Random Number Generator (PRNG) used to initialize the
in each entry of the Destinations Cache "Identification" value contained in each entry of the Destinations
Cache.
o The "Identification" re-use frequency will typically be lower than o The "Identification" re-use frequency will typically be lower than
that achieved by a global counter (when sending traffic to that achieved by a global counter (when sending traffic to
multiple destinations), since this algorithm uses per-destination multiple destinations), since this algorithm uses per-destination
counters (rather than a single system-wide counter). counters (rather than a single system-wide counter).
o It has good performance properties (once the corresponding entry o It has good performance properties (once the corresponding entry
in the Destinations Cache has been created, each subsequent in the Destinations Cache has been created, each subsequent
"Identification" value simply involves the increment of a "Identification" value simply involves the increment of a
counter). counter).
skipping to change at page 10, line 21 skipping to change at page 10, line 18
parties the Fragment Identification values used by other hosts to parties the Fragment Identification values used by other hosts to
send traffic to it (i.e., Host B could leak to Host C the Fragment send traffic to it (i.e., Host B could leak to Host C the Fragment
Identification values that Host A is using to send packets to Host Identification values that Host A is using to send packets to Host
B). B).
Appendix A describes a scenario in which that information Appendix A describes a scenario in which that information
leakage could take place. leakage could take place.
5.2. Randomized Identification values 5.2. Randomized Identification values
Clearly, use of a Pseudo-Random Number Generator (PRNG) for selecting Clearly, use of a Pseudo-Random Number Generator for selecting the
the Fragment Identification could be desirable from a security Fragment Identification could be desirable from a security
standpoint. With such a scheme, the Fragment Identification of each standpoint. With such a scheme, the Fragment Identification of each
fragmented datagram would be selected as: fragmented datagram would be selected as:
Identification = random() Identification = random()
where "random()" is the PRNG. where "random()" is the PRNG.
The specific properties of such scheme would clearly depend on the The specific properties of such scheme would clearly depend on the
specific PRNG algorithm used. For example, some PRNGs may result in specific PRNG algorithm used. For example, some PRNGs may result in
higher Fragment Identification reuse frequencies than others, in the higher Fragment Identification reuse frequencies than others, in the
skipping to change at page 12, line 7 skipping to change at page 12, line 5
o The "Identification" re-use frequency will typically be lower than o The "Identification" re-use frequency will typically be lower than
that achieved by a global counter (when sending traffic to that achieved by a global counter (when sending traffic to
multiple destinations), since this algorithm uses multiple system- multiple destinations), since this algorithm uses multiple system-
wide counters (rather than a single system-wide counter). The wide counters (rather than a single system-wide counter). The
extent to which the re-use frequency will be lower will depend on extent to which the re-use frequency will be lower will depend on
the number of elements in counter[], and the number of other the number of elements in counter[], and the number of other
active flows that result in the same value of G() (and hence cause active flows that result in the same value of G() (and hence cause
the same counter to be incremented for each fragmented datagram the same counter to be incremented for each fragmented datagram
that is sent). that is sent).
o
o It is possible to implement the algorithm such that good o It is possible to implement the algorithm such that good
performance is achieved. For example, the result of F() could be performance is achieved. For example, the result of F() could be
stored in the Destinations Cache (such that it need not be stored in the Destinations Cache (such that it need not be
recomputed for each packet that must be sent) along with computed recomputed for each packet that must be sent) along with computed
*index* for counter[]. *index* for counter[].
It should be noted that if this implementation approach is It should be noted that if this implementation approach is
followed, and an entry of the Destinations Cache must be followed, and an entry of the Destinations Cache must be
removed as a result of resource management, the last Fragment removed as a result of resource management, the last Fragment
Identification value used for that Destination will *not* lost. Identification value used for that Destination will *not* lost.
skipping to change at page 12, line 38 skipping to change at page 12, line 34
Identification values that Host A is using to send packets to Host Identification values that Host A is using to send packets to Host
B). B).
Appendix A describes a scenario in which that information Appendix A describes a scenario in which that information
leakage could take place. We note, however, that this leakage could take place. We note, however, that this
algorithm makes the aforementioned attack less reliable for the algorithm makes the aforementioned attack less reliable for the
attacker, since each counter could be possibly shared by attacker, since each counter could be possibly shared by
multiple traffic flows (i.e., packets destined to other multiple traffic flows (i.e., packets destined to other
destinations might cause the counter to be incremented). destinations might cause the counter to be incremented).
This algorithm might be preferable (over the RECOMMENDED algorithm This algorithm might be preferable (over the one specified in
specified in Section 5.1) in those scenarios in which a node is Section 5.1) in those scenarios in which a node is expected to
expected to communicate with a large number of destinations, and thus communicate with a large number of destinations, and thus it is
it is desirable to limit the amount of information to be maintained desirable to limit the amount of information to be maintained in
in memory. memory.
In such scenarios, if the algorithm specified in Section 5.1 were In such scenarios, if the algorithm specified in Section 5.1 were
implemented, entries from the Destinations Cache might need to be implemented, entries from the Destinations Cache might need to be
pruned frequently, thus increasing the risk of fragment pruned frequently, thus increasing the risk of fragment
Identification collisions. Identification collisions.
6. IANA Considerations 6. IANA Considerations
There are no IANA registries within this document. The RFC-Editor There are no IANA registries within this document. The RFC-Editor
can remove this section before publication of this document as an can remove this section before publication of this document as an
RFC. RFC.
7. Security Considerations 7. Security Considerations
This document describes the security implications of predictable This document discusses the security implications of predictable
Fragment Identification values, and updates RFC 2460 such that the Fragment Identification values, and updates RFC 2460 such that
Fragment Identification values employed are unpredictable by off-path Fragment Identification values are required to be unpredictable by
attackers, and hence the aforementioned security implications are off-path attackers, hence mitigating the aforementioned security
mitigated. implications.
While a specific algorithm is RECOMMENDED, other possible algorithms A number of possible algorithms are specified, to provide some
are described, since the selection of a Fragment-Identification implementation alternatives to implementers. However, the selection
selection algorithm represents a number of trade-offs (security, of an specific algorithm that complies with Section 3 is left to
performance, implementation complexity, interoperability properties, implementers. We note that the selection of such an algorithm
etc.). usually implies a number of trade-offs (security, performance,
implementation complexity, interoperability properties, etc.).
8. Acknowledgements 8. Acknowledgements
The author would like to thank Ivan Arce for proposing the attack The author would like to thank Ivan Arce for proposing the attack
scenario described in Appendix A, and for providing valuable comments scenario described in Appendix A, and for providing valuable comments
on earlier versions of this document. on earlier versions of this document.
The author would like to thank Dave Thaler for providing valuable
comments on earlier versions of this document.
This document is based on the technical report "Security Assessment This document is based on the technical report "Security Assessment
of the Internet Protocol version 6 (IPv6)" [CPNI-IPv6] authored by of the Internet Protocol version 6 (IPv6)" [CPNI-IPv6] authored by
Fernando Gont on behalf of the UK Centre for the Protection of Fernando Gont on behalf of the UK Centre for the Protection of
National Infrastructure (CPNI). National Infrastructure (CPNI).
Fernando Gont would like to thank the UK CPNI Fernando Gont would like to thank the UK CPNI
(http://www.cpni.gov.uk) for their continued support. (http://www.cpni.gov.uk) for their continued support.
9. References 9. References
skipping to change at page 20, line 9 skipping to change at page 20, line 9
Host A. Host A.
As a result, the attacker could employ this technique to learn the As a result, the attacker could employ this technique to learn the
current Fragment Identification value used by host A to send packets current Fragment Identification value used by host A to send packets
to host B. to host B.
Appendix B. Changes from previous versions of the document (to be Appendix B. Changes from previous versions of the document (to be
removed by the RFC Editor before publication of this removed by the RFC Editor before publication of this
document as a RFC) document as a RFC)
B.1. Changes from draft-gont-6man-predictable-fragment-id-00 B.1. Changes from draft-gont-6man-predictable-fragment-id-01
o Recommendation of a specific algorithm has been removed. Nodes
are just required to select the Fragment Identification values
such that they are not easily predictable by off-path attackers.
B.2. Changes from draft-gont-6man-predictable-fragment-id-00
o The constraints for the possible Fragment-Identification selection o The constraints for the possible Fragment-Identification selection
algorithm are now described in more detail (e.g., the I-D now algorithm are now described in more detail (e.g., the I-D now
mentioned that translators only use the last 16 bits of the IPv6 mentioned that translators only use the last 16 bits of the IPv6
Fragment Identification). Fragment Identification).
o The I-D now provides a discussion of possible Fragment- o The I-D now provides a discussion of possible Fragment-
Identification selection algorithms, and analyzes the trade-offs. Identification selection algorithms, and analyzes the trade-offs.
Author's Address Author's Address
 End of changes. 17 change blocks. 
38 lines changed or deleted 41 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/
X-Generator: pyht 0.35