draft-ietf-6man-stable-privacy-addresses-15.txt   draft-ietf-6man-stable-privacy-addresses-16.txt 
IPv6 maintenance Working Group (6man) F. Gont IPv6 maintenance Working Group (6man) F. Gont
Internet-Draft SI6 Networks / UTN-FRH Internet-Draft SI6 Networks / UTN-FRH
Intended status: Standards Track November 26, 2013 Intended status: Standards Track December 10, 2013
Expires: May 30, 2014 Expires: June 13, 2014
A Method for Generating Semantically Opaque Interface Identifiers with A Method for Generating Semantically Opaque Interface Identifiers with
IPv6 Stateless Address Autoconfiguration (SLAAC) IPv6 Stateless Address Autoconfiguration (SLAAC)
draft-ietf-6man-stable-privacy-addresses-15 draft-ietf-6man-stable-privacy-addresses-16
Abstract Abstract
This document specifies a method for generating IPv6 Interface This document specifies a method for generating IPv6 Interface
Identifiers to be used with IPv6 Stateless Address Autoconfiguration Identifiers to be used with IPv6 Stateless Address Autoconfiguration
(SLAAC), such that addresses configured using this method are stable (SLAAC), such that addresses configured using this method are stable
within each subnet, but the Interface Identifier changes when hosts within each subnet, but the Interface Identifier changes when hosts
move from one network to another. This method is meant to be an move from one network to another. This method is meant to be an
alternative to generating Interface Identifiers based on hardware alternative to generating Interface Identifiers based on hardware
addresses (e.g., IEEE LAN MAC addresses), such that the benefits of addresses (e.g., IEEE LAN MAC addresses), such that the benefits of
skipping to change at page 1, line 41 skipping to change at page 1, line 41
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 May 30, 2014. This Internet-Draft will expire on June 13, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2013 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
skipping to change at page 7, line 31 skipping to change at page 7, line 31
expression below MUST be included when generating an Interface expression below MUST be included when generating an Interface
Identifier. Identifier.
1. Compute a random (but stable) identifier with the expression: 1. Compute a random (but stable) identifier with the expression:
RID = F(Prefix, Net_Iface, Network_ID, DAD_Counter, secret_key) RID = F(Prefix, Net_Iface, Network_ID, DAD_Counter, secret_key)
Where: Where:
RID: RID:
Random (but stable) Identifier Random (but stable) Identifier
F(): F():
A pseudorandom function (PRF) that MUST NOT be computable A pseudorandom function (PRF) that MUST NOT be computable from
from the outside (without knowledge of the secret key). the outside (without knowledge of the secret key). F() MUST
F() MUST also be difficult to reverse, such that it resists also be difficult to reverse, such that it resists attempts to
attempts to obtain the secret_key, even when given samples obtain the secret_key, even when given samples of the output
of the output of F() and knowledge or control of the other of F() and knowledge or control of the other input parameters.
input parameters. F() SHOULD produce an output of at least F() SHOULD produce an output of at least 64 bits. F() could
64 bits. F() could be implemented as a cryptographic hash be implemented as a cryptographic hash of the concatenation of
of the concatenation of each of the function parameters. each of the function parameters. MD5 [RFC1321] and SHA-1
MD5 [RFC1321] and SHA-1 [FIPS-SHS] are two possible options [FIPS-SHS] are two possible options for F().
for F().
Prefix: Prefix:
The prefix to be used for SLAAC, as learned from an ICMPv6 The prefix to be used for SLAAC, as learned from an ICMPv6
Router Advertisement message, or the link-local IPv6 Router Advertisement message, or the link-local IPv6 unicast
unicast prefix [RFC4291]. prefix [RFC4291].
Net_Iface: Net_Iface:
An implementation-dependent stable identifier associated with
the network interface for which the RID is being generated.
An implementation-dependent stable identifier associated An implementation MAY provide a configuration option to select
with the network interface for which the RID is being the source of the identifier to be used for the Net_Iface
generated. An implementation MAY provide a configuration parameter. A discussion of possible sources for this value
option to select the source of the identifier to be used (along with the corresponding trade-offs) can be found in
for the Net_Iface parameter. A discussion of possible Appendix A.
sources for this value (along with the corresponding trade-
offs) can be found in Appendix A.
Network_ID: Network_ID:
Some network specific data that identifies the subnet to Some network specific data that identifies the subnet to which
which this interface is attached. For example the IEEE this interface is attached. For example the IEEE 802.11
802.11 Service Set Identifier (SSID) corresponding to the Service Set Identifier (SSID) corresponding to the network to
network to which this interface is associated. This which this interface is associated. This parameter is
parameter is OPTIONAL. OPTIONAL.
DAD_Counter: DAD_Counter:
A counter that is employed to resolve Duplicate Address A counter that is employed to resolve Duplicate Address
Detection (DAD) conflicts. It MUST be initialized to 0, Detection (DAD) conflicts. It MUST be initialized to 0, and
and incremented by 1 for each new tentative address that is incremented by 1 for each new tentative address that is
configured as a result of a DAD conflict. Implementations configured as a result of a DAD conflict. Implementations
that record DAD_Counter in non-volatile memory for each that record DAD_Counter in non-volatile memory for each
{Prefix, Net_Iface, Network_ID} tuple MUST initialize {Prefix, Net_Iface, Network_ID} tuple MUST initialize
DAD_Counter to the recorded value if such an entry exists DAD_Counter to the recorded value if such an entry exists in
in non-volatile memory. See Section 6 for additional non-volatile memory. See Section 6 for additional details.
details.
secret_key: secret_key:
A secret key that is not known by the attacker. The secret A secret key that is not known by the attacker. The secret
key MUST be initialized to a pseudo-random number (see key MUST be initialized to a pseudo-random number (see
[RFC4086] for randomness requirements for security) at [RFC4086] for randomness requirements for security) at
operating system installation time or when the IPv6 operating system installation time or when the IPv6 protocol
protocol stack is initialized for the first time. An stack is initialized for the first time. An implementation
implementation MAY provide the means for the the system MAY provide the means for the the system administrator to
administrator to change or display the secret key. change or display the secret key.
2. The Interface Identifier is finally obtained by taking as many 2. The Interface Identifier is finally obtained by taking as many
bits from the RID value (computed in the previous step) as bits from the RID value (computed in the previous step) as
necessary, starting from the least significant bit. necessary, starting from the least significant bit.
We note that [RFC4291] requires that, the Interface IDs of We note that [RFC4291] requires that, the Interface IDs of all
all unicast addresses (except those that start with the unicast addresses (except those that start with the binary
binary value 000) be 64-bit long. However, the method value 000) be 64-bit long. However, the method discussed in
discussed in this document could be employed for generating this document could be employed for generating Interface IDs
Interface IDs of any arbitrary length, albeit at the of any arbitrary length, albeit at the expense of reduced
expense of reduced entropy (when employing Interface IDs entropy (when employing Interface IDs smaller than 64 bits).
smaller than 64 bits).
The resulting Interface Identifier SHOULD be compared against the The resulting Interface Identifier SHOULD be compared against the
Subnet-Router Anycast [RFC4291] and the Reserved Subnet Anycast reserved IPv6 Interface Identifiers [RFC5453]
Addresses [RFC2526], and against those Interface Identifiers [IANA-RESERVED-IID], and against those Interface Identifiers
already employed in an address of the same network interface and already employed in an address of the same network interface and
the same network prefix. In the event that an unacceptable the same network prefix. In the event that an unacceptable
identifier has been generated, this situation SHOULD be handled identifier has been generated, this situation SHOULD be handled
in the same way as the case of duplicate addresses (see in the same way as the case of duplicate addresses (see
Section 6). Section 6).
This document does not require the use of any specific PRF for the This document does not require the use of any specific PRF for the
function F() above, since the choice of such PRF is usually a trade- function F() above, since the choice of such PRF is usually a trade-
off between a number of properties (processing requirements, ease of off between a number of properties (processing requirements, ease of
implementation, possible intellectual property rights, etc.), and implementation, possible intellectual property rights, etc.), and
skipping to change at page 14, line 43 skipping to change at page 14, line 39
10. Acknowledgements 10. Acknowledgements
The algorithm specified in this document has been inspired by Steven The algorithm specified in this document has been inspired by Steven
Bellovin's work ([RFC1948]) in the area of TCP sequence numbers. Bellovin's work ([RFC1948]) in the area of TCP sequence numbers.
The author would like to thank (in alphabetical order) Mikael The author would like to thank (in alphabetical order) Mikael
Abrahamsson, Ran Atkinson, Karl Auer, Steven Bellovin, Matthias Abrahamsson, Ran Atkinson, Karl Auer, Steven Bellovin, Matthias
Bethke, Ben Campbell, Brian Carpenter, Tassos Chatzithomaoglou, Tim Bethke, Ben Campbell, Brian Carpenter, Tassos Chatzithomaoglou, Tim
Chown, Alissa Cooper, Dominik Elsbroek, Eric Gray, Brian Haberman, Chown, Alissa Cooper, Dominik Elsbroek, Eric Gray, Brian Haberman,
Bob Hinden, Christian Huitema, Ray Hunter, Jouni Korhonen, Eliot Bob Hinden, Christian Huitema, Ray Hunter, Jouni Korhonen, Suresh
Lear, Jong-Hyouk Lee, Andrew McGregor, Tom Petch, Michael Richardson, Krishnan, Eliot Lear, Jong-Hyouk Lee, Andrew McGregor, Tom Petch,
Mark Smith, Dave Thaler, Ole Troan, James Woodyatt, and He Xuan, for Michael Richardson, Mark Smith, Dave Thaler, Ole Troan, James
providing valuable comments on earlier versions of this document. Woodyatt, and He Xuan, 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).
The author would like to thank CPNI (http://www.cpni.gov.uk) for The author would like to thank CPNI (http://www.cpni.gov.uk) for
their continued support. their continued support.
11. References 11. References
11.1. Normative References 11.1. Normative References
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, December 1998. (IPv6) Specification", RFC 2460, December 1998.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2526] Johnson, D. and S. Deering, "Reserved IPv6 Subnet Anycast
Addresses", RFC 2526, March 1999.
[RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C.,
and M. Carney, "Dynamic Host Configuration Protocol for and M. Carney, "Dynamic Host Configuration Protocol for
IPv6 (DHCPv6)", RFC 3315, July 2003. IPv6 (DHCPv6)", RFC 3315, July 2003.
[RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure [RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure
Neighbor Discovery (SEND)", RFC 3971, March 2005. Neighbor Discovery (SEND)", RFC 3971, March 2005.
[RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)",
RFC 3972, March 2005. RFC 3972, March 2005.
skipping to change at page 15, line 52 skipping to change at page 15, line 46
"Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
September 2007. September 2007.
[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
Address Autoconfiguration", RFC 4862, September 2007. Address Autoconfiguration", RFC 4862, September 2007.
[RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy
Extensions for Stateless Address Autoconfiguration in Extensions for Stateless Address Autoconfiguration in
IPv6", RFC 4941, September 2007. IPv6", RFC 4941, September 2007.
[RFC5453] Krishnan, S., "Reserved IPv6 Interface Identifiers", RFC
5453, February 2009.
[I-D.ietf-6man-ug] [I-D.ietf-6man-ug]
Carpenter, B. and S. Jiang, "Significance of IPv6 Carpenter, B. and S. Jiang, "Significance of IPv6
Interface Identifiers", draft-ietf-6man-ug-05 (work in Interface Identifiers", draft-ietf-6man-ug-05 (work in
progress), November 2013. progress), November 2013.
11.2. Informative References 11.2. Informative References
[RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321,
April 1992. April 1992.
skipping to change at page 17, line 13 skipping to change at page 17, line 9
[I-D.ietf-6man-ipv6-address-generation-privacy] [I-D.ietf-6man-ipv6-address-generation-privacy]
Cooper, A., Gont, F., and D. Thaler, "Privacy Cooper, A., Gont, F., and D. Thaler, "Privacy
Considerations for IPv6 Address Generation Mechanisms", Considerations for IPv6 Address Generation Mechanisms",
draft-ietf-6man-ipv6-address-generation-privacy-00 (work draft-ietf-6man-ipv6-address-generation-privacy-00 (work
in progress), October 2013. in progress), October 2013.
[HDMoore] HD Moore, , "The Wild West", Louisville, Kentucky, U.S.A, [HDMoore] HD Moore, , "The Wild West", Louisville, Kentucky, U.S.A,
September 2012, <https://speakerdeck.com/hdm/derbycon-2012 September 2012, <https://speakerdeck.com/hdm/derbycon-2012
-the-wild-west>. -the-wild-west>.
[IANA-RESERVED-IID]
Reserved IPv6 Interface Identifiers, ,
"http://www.iana.org/assignments/ipv6-interface-ids/
ipv6-interface-ids.xml", .
[Gont-DEEPSEC2011] [Gont-DEEPSEC2011]
Gont, , "Results of a Security Assessment of the Internet Gont, , "Results of a Security Assessment of the Internet
Protocol version 6 (IPv6)", DEEPSEC 2011 Conference, Protocol version 6 (IPv6)", DEEPSEC 2011 Conference,
Vienna, Austria, November 2011, <http:// Vienna, Austria, November 2011,
www.si6networks.com/presentations/deepsec2011/fgont- <http://www.si6networks.com/presentations/deepsec2011/
deepsec2011-ipv6-security.pdf>. fgont-deepsec2011-ipv6-security.pdf>.
[Broersma] [Broersma]
Broersma, R., "IPv6 Everywhere: Living with a Fully Broersma, R., "IPv6 Everywhere: Living with a Fully
IPv6-enabled environment", Australian IPv6 Summit 2010, IPv6-enabled environment", Australian IPv6 Summit 2010,
Melbourne, VIC Australia, October 2010, <http:// Melbourne, VIC Australia, October 2010,
www.ipv6.org.au/10ipv6summit/talks/Ron_Broersma.pdf>. <http://www.ipv6.org.au/10ipv6summit/talks/
Ron_Broersma.pdf>.
[IAB-PRIVACY] [IAB-PRIVACY]
IAB, , "Privacy and IPv6 Addresses", July 2011, <http:// IAB, , "Privacy and IPv6 Addresses", July 2011,
www.iab.org/wp-content/IAB-uploads/2011/07/IPv6-addresses- <http://www.iab.org/wp-content/IAB-uploads/2011/07/
privacy-review.txt>. IPv6-addresses-privacy-review.txt>.
[CPNI-IPv6] [CPNI-IPv6]
Gont, F., "Security Assessment of the Internet Protocol Gont, F., "Security Assessment of the Internet Protocol
version 6 (IPv6)", UK Centre for the Protection of version 6 (IPv6)", UK Centre for the Protection of
National Infrastructure, (available on request). National Infrastructure, (available on request).
[FIPS-SHS] [FIPS-SHS]
FIPS, , "Secure Hash Standard (SHS)", Federal Information FIPS, , "Secure Hash Standard (SHS)", Federal Information
Processing Standards Publication 180-4, March 2012, <http: Processing Standards Publication 180-4, March 2012,
//csrc.nist.gov/publications/fips/fips180-4/ <http://csrc.nist.gov/publications/fips/fips180-4/
fips-180-4.pdf>. fips-180-4.pdf>.
Appendix A. Possible sources for the Net_Iface parameter Appendix A. Possible sources for the Net_Iface parameter
The following subsections describe a number of possible sources for The following subsections describe a number of possible sources for
the Net_Iface parameter employed by the F() function in Section 5. the Net_Iface parameter employed by the F() function in Section 5.
The choice of a specific source for this value represents a number of The choice of a specific source for this value represents a number of
trade-offs, which may vary from one implementation to another. trade-offs, which may vary from one implementation to another.
A.1. Interface Index A.1. Interface Index
 End of changes. 21 change blocks. 
72 lines changed or deleted 76 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/