doc: Add RFC documents

1 files changed, 563 insertions, 0 deletions

diff --git a/doc/rfc/rfc7943.txt b/doc/rfc/rfc7943.txt
new file mode 100644
index 0000000..d5cd9b0
--- /dev/null
+++ b/doc/rfc/rfc7943.txt
@@ -0,0 +1,563 @@
+
+
+
+
+
+
+Independent Submission                                           F. Gont
+Request for Comments: 7943                        SI6 Networks / UTN-FRH
+Category: Informational                                           W. Liu
+ISSN: 2070-1721                                      Huawei Technologies
+                                                          September 2016
+
+
+A Method for Generating Semantically Opaque Interface Identifiers (IIDs)
+     with the Dynamic Host Configuration Protocol for IPv6 (DHCPv6)
+
+Abstract
+
+   This document describes a method for selecting IPv6 Interface
+   Identifiers that can be employed by Dynamic Host Configuration
+   Protocol for IPv6 (DHCPv6) servers when leasing non-temporary IPv6
+   addresses to DHCPv6 clients.  This method is a DHCPv6 server-side
+   algorithm that does not require any updates to the existing DHCPv6
+   specifications.  The aforementioned method results in stable
+   addresses within each subnet, even in the presence of multiple DHCPv6
+   servers or DHCPv6 server reinstallments.  It is a DHCPv6 variant of
+   the method specified in RFC 7217 for IPv6 Stateless Address
+   Autoconfiguration.
+
+IESG Note
+
+   A predecessor to this document was earlier a working group document
+   in the DHC WG.  The WG decided to stop further work in this area
+   because such work was not considered useful.
+
+   The proposal described in this document has an unaddressed failure
+   case that makes it unsuitable for use as the mechanism to provide the
+   claimed failover features for DHCPv6 servers.  Specifically, when a
+   DHCPv6 client DECLINEs a provided address there is no recovery
+   mechanism described that will result in the DHCPv6 client obtaining a
+   working IPv6 address.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Gont & Liu                    Informational                     [Page 1]
+
+RFC 7943           Stable and Opaque IIDs with DHCPv6     September 2016
+
+
+Status of This Memo
+
+   This document is not an Internet Standards Track specification; it is
+   published for informational purposes.
+
+   This is a contribution to the RFC Series, independently of any other
+   RFC stream.  The RFC Editor has chosen to publish this document at
+   its discretion and makes no statement about its value for
+   implementation or deployment.  Documents approved for publication by
+   the RFC Editor are not a candidate for any level of Internet
+   Standard; see Section 2 of RFC 7841.
+
+   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/rfc7943.
+
+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.
+
+Table of Contents
+
+   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
+   2.  Applicability and Design Goals  . . . . . . . . . . . . . . .   3
+   3.  Method Specification  . . . . . . . . . . . . . . . . . . . .   4
+   4.  Security Considerations . . . . . . . . . . . . . . . . . . .   8
+   5.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   8
+     5.1.  Normative References  . . . . . . . . . . . . . . . . . .   8
+     5.2.  Informative References  . . . . . . . . . . . . . . . . .   8
+   Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .  10
+   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  10
+
+
+
+
+
+
+
+
+
+
+
+
+Gont & Liu                    Informational                     [Page 2]
+
+RFC 7943           Stable and Opaque IIDs with DHCPv6     September 2016
+
+
+1.  Introduction
+
+   The benefits of stable IPv6 addresses are discussed in [RFC7721].
+   Providing address stability across server reinstallations or when a
+   database of previous DHCPv6 address leases is unavailable is of use
+   not only when a DHCPv6 server must be reinstalled or the address-
+   lease database becomes corrupted, but is also of use when
+   implementation constraints (e.g., a DHCPv6 server implementation on
+   an embedded device) make it impossible for a DHCPv6 server
+   implementation to maintain a database of previous DHCPv6 address
+   leases.  Additionally, [RFC7031] describes scenarios where multiple
+   DHCPv6 servers are required to run in such a way as to provide
+   increased availability in case of server failures.
+
+   This document describes a method for selecting IPv6 Interface
+   Identifiers that can be employed by DHCPv6 servers when leasing non-
+   temporary IPv6 addresses to DHCPv6 clients (i.e., to be employed with
+   IA_NA options).  This method is a DHCPv6 server-side algorithm that
+   does not require any updates to the existing DHCPv6 specifications.
+   The aforementioned method has the following properties:
+
+   o  The resulting IPv6 addresses remain stable within each subnet for
+      the same network interface of the same client, even when different
+      DHCPv6 servers (implementing this specification) are employed.
+
+   o  Predicting the IPv6 addresses that will be generated by the method
+      specified in this document, even with knowledge of the IPv6
+      addresses generated for other nodes within the same network,
+      becomes very difficult.
+
+   The method specified in this document achieves the aforementioned
+   properties by means of a calculated technique as opposed to, e.g.,
+   state sharing among DHCPv6 servers.  This approach has already been
+   suggested in [RFC7031].  We note that the method described in this
+   document is essentially a DHCPv6 version of the "Method for
+   Generating Semantically Opaque Interface Identifiers with IPv6
+   Stateless Address Autoconfiguration (SLAAC)" specified in [RFC7217].
+
+2.  Applicability and Design Goals
+
+   This document simply describes one possible approach for selecting
+   IPv6 Interface Identifiers to be employed by DHCPv6 servers when
+   leasing non-temporary IPv6 addresses to DHCPv6 clients, with the
+   following properties:
+
+   o  The resulting IPv6 addresses remain stable within each subnet for
+      the same network interface of the same client.
+
+
+
+
+Gont & Liu                    Informational                     [Page 3]
+
+RFC 7943           Stable and Opaque IIDs with DHCPv6     September 2016
+
+
+   o  The resulting IPv6 addresses cannot be predicted by an attacker
+      without knowledge of a secret key.
+
+   o  The resulting IPv6 addresses remain stable across DHCPv6 server
+      reinstallations, or even if a database of previous DHCPv6 address
+      leases is not available.
+
+   o  The resulting IPv6 addresses remain stable when different DHCPv6
+      servers (implementing this specification) are employed on the same
+      network.
+
+   We note that the algorithm specified in this document employs a
+   (lightweight) calculated technique (as opposed to, e.g., state
+   sharing among DHCPv6 servers) to achieve address stability in
+   scenarios where multiple DHCPv6 servers are required to run in such a
+   way as to provide increased availability, without the need of an
+   additional protocol to synchronize the lease databases of DHCPv6
+   servers.
+
+   Finally, we note that the algorithm in this document is only meant to
+   mitigate IPv6 address-based location tracking, device-specific
+   vulnerability exploitation, and host scanning (please see [RFC7721]).
+   There are a number of ways in which DHCPv6 affects user privacy,
+   which the algorithm specified in this document does not mitigate (and
+   does not intend to).  Please see [RFC7844] for a comprehensive
+   discussion of how DHCPv6 may affect user privacy.
+
+3.  Method Specification
+
+   Implementations should provide the means for a system administrator
+   to enable or disable the use of this algorithm for generating IPv6
+   addresses.
+
+   A DHCPv6 server implementing this specification must select the IPv6
+   addresses to be leased with the following algorithm:
+
+   1.  Compute a random (but stable) identifier with the expression:
+
+       RID = F(Prefix | Client_DUID | IAID | Counter | secret_key)
+
+       Where:
+
+       RID:
+          Random (but stable) Identifier
+
+
+
+
+
+
+
+Gont & Liu                    Informational                     [Page 4]
+
+RFC 7943           Stable and Opaque IIDs with DHCPv6     September 2016
+
+
+       F():
+          A Pseudorandom Function (PRF) that must not be computable from
+          the outside (without knowledge of the secret key).  F() must
+          also be difficult to reverse, such that it resists attempts to
+          obtain the secret key, even when given samples of the output
+          of F() and knowledge or control of the other input parameters.
+          F() should produce an output of at least 64 bits.  F() could
+          be implemented as a cryptographic hash of the concatenation of
+          each of the function parameters.  The default algorithm to be
+          employed for F() should be SHA-256 [FIPS-SHS].  An
+          implementation may provide the means for selecting other
+          algorithms.  Note: Message Digest 5 (MD5) [RFC1321] is
+          considered unacceptable for F() [RFC6151].
+
+       Prefix:
+          The prefix employed for the local subnet, as a 128-bit
+          unsigned integer in network byte order (with the unused bits
+          set to 0).  If multiple servers operate on the same network to
+          provide increased availability, all such DHCPv6 servers must
+          be configured with the same Prefix.  It is the administrator's
+          responsibility that the aforementioned requirement is met.
+
+       |:
+          An operator representing "concatenation".
+
+       Client_DUID:
+          The DHCPv6 Unique Identifier (DUID) value contained in the
+          Client Identifier option received in the DHCPv6 client
+          message.  The DUID can be treated as an array of 8-bit
+          unsigned integers.
+
+       IAID:
+          The Identity Association Identifier (IAID) value contained in
+          the IA_NA option received in the client message.  It must be
+          interpreted as a 32-bit unsigned integer in network byte
+          order.
+
+       secret_key:
+          A secret key configured by the DHCPv6 server administrator,
+          which must not be known by the attacker.  It must be encoded
+          as an array of 8-bit unsigned integers.  An implementation of
+          this specification must provide an interface for viewing and
+          changing the secret key.  All DHCPv6 servers leasing addresses
+          from the same address range must employ the same secret key.
+
+
+
+
+
+
+
+Gont & Liu                    Informational                     [Page 5]
+
+RFC 7943           Stable and Opaque IIDs with DHCPv6     September 2016
+
+
+       Counter:
+          A 32-bit unsigned integer in network byte order that is
+          employed to resolve address conflicts.  It must be initialized
+          to 0.
+
+   2.  A candidate IPv6 address (IPV6_ADDR) to be leased is obtained by
+       concatenating as many bits as necessary from the RID value
+       computed in the previous step (starting from the least
+       significant bit) to the Prefix employed in the equation above, as
+       follows:
+
+        IPV6_ADDR = IPV6_ADDR_LOW +
+                    RID % (IPV6_ADDR_HI - IPV6_ADDR_LOW + 1)
+
+       where:
+
+       IPV6_ADDR:
+          The candidate IPv6 address to be leased.
+
+       IPV6_ADDR_HI:
+          An IPv6 address specifying the upper boundary of the IPv6
+          address pool from which the DHCPv6 server leases IPv6
+          addresses.  If an address range is not explicitly selected,
+          IPV6_ADDR_HI must be set to the IPv6 address from the Prefix
+          (see the expression above) that has all of the bits of the
+          Interface Identifier set to 1.
+
+       IPV6_ADDR_LOW:
+          An IPv6 address specifying the lower boundary of the IPv6
+          address pool from which the DHCPv6 server leases IPv6
+          addresses.  If an address range is not explicitly selected,
+          IPV6_ADDR_LOW must be set to the IPv6 address from the Prefix
+          (see the expression above) that has all of the bits of the
+          Interface Identifier set to 0.
+
+   3.  The Interface Identifier of the selected IPv6 address must be
+       compared against the reserved IPv6 Interface Identifiers
+       [RFC5453] [IANA-RESERVED-IID].  In the event that an unacceptable
+       identifier has been generated, the Counter variable should be
+       incremented by 1, and a new IPv6 address should be computed with
+       the updated Counter value.
+
+   4.  If the resulting address is not available (e.g., there is a
+       conflicting binding), the DHCPv6 server should increment the
+       Counter variable, and a new Interface Identifier and IPv6 address
+       should be computed with the updated Counter value.
+
+
+
+
+
+Gont & Liu                    Informational                     [Page 6]
+
+RFC 7943           Stable and Opaque IIDs with DHCPv6     September 2016
+
+
+   This document requires that SHA-256 be the default function to be
+   used for F(), such that (all other configuration parameters being the
+   same) different implementations of this specification result in the
+   same IPv6 addresses.
+
+   Including the Prefix in the PRF computation causes the Interface
+   Identifier to be different for each address from a different prefix
+   leased to the same client.  This mitigates the correlation of
+   activities of multihomed nodes (since each of the corresponding
+   addresses will employ a different Interface Identifier), host
+   tracking (since the network prefix, and therefore the resulting
+   Interface Identifier, will change as the node moves from one network
+   to another), and any other attacks that benefit from predictable
+   Interface Identifiers [RFC7721].
+
+   As required by [RFC3315], an IAID is associated with each of the
+   client's network interfaces and is consistent across restarts of the
+   DHCPv6 client.
+
+   The Counter parameter provides the means to intentionally cause this
+   algorithm to produce different IPv6 addresses (all other parameters
+   being the same).  This can be of use to resolve address conflicts
+   (e.g., the resulting address having a conflicting binding).
+
+   Note that the result of F() in the algorithm above is no more secure
+   than the secret key.  If an attacker is aware of the PRF that is
+   being used by the DHCPv6 server (which we should expect), and the
+   attacker can obtain enough material (i.e., addresses generated by the
+   DHCPv6 server), the attacker may simply search the entire secret-key
+   space to find matches.  To protect against this, the secret key
+   should be of at least 128 bits.  Key lengths of at least 128 bits
+   should be adequate.
+
+   Providing a mechanism to display and change the secret_key is crucial
+   for having different DHCPv6 servers produce the same IPv6 addresses
+   and for causing a replacement system to generate the same IPv6
+   addresses as the system being replaced.  We note that since the
+   privacy of the scheme specified in this document relies on the
+   secrecy of the secret_key parameter, implementations should constrain
+   access to the secret_key parameter to the extent practicable (e.g.,
+   require superuser privileges to access it).  Furthermore, in order to
+   prevent leakages of the secret_key parameter, it should not be used
+   for any other purposes than being a parameter to the scheme specified
+   in this document.
+
+
+
+
+
+
+
+Gont & Liu                    Informational                     [Page 7]
+
+RFC 7943           Stable and Opaque IIDs with DHCPv6     September 2016
+
+
+   We note that all of the bits in the resulting Interface Identifiers
+   are treated as "opaque" bits [RFC7136].  For example, the universal/
+   local bit of Modified EUI-64 format identifiers is treated as any
+   other bit of such identifier.
+
+4.  Security Considerations
+
+   The method specified in this document results in IPv6 Interface
+   Identifiers (and hence IPv6 addresses) that do not follow any
+   specific pattern.  Thus, attacks that rely on predictable Interface
+   Identifiers (such as [RFC7707]) are mitigated.
+
+   The method specified in this document neither mitigates nor
+   exacerbates the security considerations for DHCPv6 discussed in
+   [RFC3315] and does not mitigate a range of other privacy implications
+   associated with DHCPv6.  Please read [RFC7844] for a comprehensive
+   assessment of the privacy implications of DHCPv6.
+
+   Finally, we note that an attacker that is able to attach to each of
+   the links to which the victim attaches would still be able to
+   correlate the activities of the victim across networks.
+
+5.  References
+
+5.1.  Normative References
+
+   [RFC3315]  Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins,
+              C., and M. Carney, "Dynamic Host Configuration Protocol
+              for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July
+              2003, <http://www.rfc-editor.org/info/rfc3315>.
+
+   [RFC5453]  Krishnan, S., "Reserved IPv6 Interface Identifiers",
+              RFC 5453, DOI 10.17487/RFC5453, February 2009,
+              <http://www.rfc-editor.org/info/rfc5453>.
+
+   [RFC7136]  Carpenter, B. and S. Jiang, "Significance of IPv6
+              Interface Identifiers", RFC 7136, DOI 10.17487/RFC7136,
+              February 2014, <http://www.rfc-editor.org/info/rfc7136>.
+
+5.2.  Informative References
+
+   [FIPS-SHS]
+              Federal Information Processing Standards (FIPS), "Secure
+              Hash Standard (SHS)", FIPS 180-4, August 2015,
+              <http://csrc.nist.gov/publications/fips/fips180-4/
+              fips-180-4.pdf>.
+
+
+
+
+
+Gont & Liu                    Informational                     [Page 8]
+
+RFC 7943           Stable and Opaque IIDs with DHCPv6     September 2016
+
+
+   [IANA-RESERVED-IID]
+              IANA, "Reserved IPv6 Interface Identifiers",
+              <http://www.iana.org/assignments/ipv6-interface-ids>.
+
+   [RFC1321]  Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321,
+              DOI 10.17487/RFC1321, April 1992,
+              <http://www.rfc-editor.org/info/rfc1321>.
+
+   [RFC6151]  Turner, S. and L. Chen, "Updated Security Considerations
+              for the MD5 Message-Digest and the HMAC-MD5 Algorithms",
+              RFC 6151, DOI 10.17487/RFC6151, March 2011,
+              <http://www.rfc-editor.org/info/rfc6151>.
+
+   [RFC7031]  Mrugalski, T. and K. Kinnear, "DHCPv6 Failover
+              Requirements", RFC 7031, DOI 10.17487/RFC7031, September
+              2013, <http://www.rfc-editor.org/info/rfc7031>.
+
+   [RFC7217]  Gont, F., "A Method for Generating Semantically Opaque
+              Interface Identifiers with IPv6 Stateless Address
+              Autoconfiguration (SLAAC)", RFC 7217,
+              DOI 10.17487/RFC7217, April 2014,
+              <http://www.rfc-editor.org/info/rfc7217>.
+
+   [RFC7707]  Gont, F. and T. Chown, "Network Reconnaissance in IPv6
+              Networks", RFC 7707, DOI 10.17487/RFC7707, March 2016,
+              <http://www.rfc-editor.org/info/rfc7707>.
+
+   [RFC7721]  Cooper, A., Gont, F., and D. Thaler, "Security and Privacy
+              Considerations for IPv6 Address Generation Mechanisms",
+              RFC 7721, DOI 10.17487/RFC7721, March 2016,
+              <http://www.rfc-editor.org/info/rfc7721>.
+
+   [RFC7844]  Huitema, C., Mrugalski, T., and S. Krishnan, "Anonymity
+              Profiles for DHCP Clients", RFC 7844,
+              DOI 10.17487/RFC7844, May 2016,
+              <http://www.rfc-editor.org/info/rfc7844>.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Gont & Liu                    Informational                     [Page 9]
+
+RFC 7943           Stable and Opaque IIDs with DHCPv6     September 2016
+
+
+Acknowledgements
+
+   This document is based on [RFC7217], authored by Fernando Gont.
+
+   The authors would like to thank Marc Blanchet, Stephane Bortzmeyer,
+   Tatuya Jinmei, Andre Kostur, Tomek Mrugalski, Hosnieh Rafiee, Jim
+   Schaad, Jean-Francois Tremblay, Tina Tsou, and Bernie Volz for
+   providing valuable comments on earlier draft versions of this
+   documents.
+
+   The authors would like to thank Ted Lemon, who kindly answered some
+   DHCPv6-related questions, and Nevil Brownlee for his guidance while
+   pursuing this document.
+
+   Fernando Gont would like to thank Nelida Garcia and Guillermo Gont
+   for their love and support, and Diego Armando Maradona for his magic
+   and inspiration.
+
+Authors' Addresses
+
+   Fernando Gont
+   SI6 Networks / UTN-FRH
+   Evaristo Carriego 2644
+   Haedo, Provincia de Buenos Aires  1706
+   Argentina
+
+   Phone: +54 11 4650 8472
+   Email: fgont@si6networks.com
+   URI:   http://www.si6networks.com
+
+
+   Will (Shucheng) Liu
+   Huawei Technologies
+   Bantian, Longgang District
+   Shenzhen  518129
+   China
+
+   Email: liushucheng@huawei.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+Gont & Liu                    Informational                    [Page 10]
+