--- 1/draft-ietf-6man-stable-privacy-addresses-02.txt 2013-01-30 04:21:44.303791712 +0100 +++ 2/draft-ietf-6man-stable-privacy-addresses-03.txt 2013-01-30 04:21:44.327793091 +0100 @@ -1,19 +1,19 @@ IPv6 maintenance Working Group (6man) F. Gont Internet-Draft SI6 Networks / UTN-FRH -Intended status: Standards Track December 30, 2012 -Expires: July 3, 2013 +Intended status: Standards Track January 27, 2013 +Expires: July 31, 2013 A method for Generating Stable Privacy-Enhanced Addresses with IPv6 Stateless Address Autoconfiguration (SLAAC) - draft-ietf-6man-stable-privacy-addresses-02 + draft-ietf-6man-stable-privacy-addresses-03 Abstract This document specifies a method for generating IPv6 Interface Identifiers to be used with IPv6 Stateless Address Autoconfiguration (SLAAC), such that addresses configured using this method are stable within each subnet, but the Interface Identifier changes when hosts move from one network to another. The aforementioned method is meant to be an alternative to generating Interface Identifiers based on IEEE identifiers, such that the benefits of stable addresses can be @@ -27,25 +27,25 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on July 3, 2013. + This Internet-Draft will expire on July 31, 2013. Copyright Notice - Copyright (c) 2012 IETF Trust and the persons identified as the + Copyright (c) 2013 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 @@ -283,29 +283,30 @@ secret_key: A secret key that is not known by the attacker. The secret key MUST be initialized at system installation time to a pseudo-random number (see [RFC4086] for randomness requirements for security). An implementation MAY provide the means for the user to change the secret key. 2. The Interface Identifier is finally obtained by taking the leftmost 64 bits of the RID value computed in the previous step, - and and setting bit 6 (the leftmost bit is numbered 0) to zero. - This creates an interface identifier with the universal/local bit + and setting bit 6 (the leftmost bit is numbered 0) to zero. This + creates an interface identifier with the universal/local bit indicating local significance only. The resulting Interface - Identifier should be compared against a list of reserved - interface identifiers and to those already employed in an address - of the same network interface and the same network prefix. In - the event that an unacceptable identifier has been generated, - this situation should be handled in the same way as the case of - duplicate addresses (see Section 4). + Identifier should be compared against the list of reserved + interface identifiers [IANA-RESERVED-IID], and to those interface + identifiers already employed in an address of the same network + interface and the same network prefix. In the event that an + unacceptable identifier has been generated, this situation should + be handled in the same way as the case of duplicate addresses + (see Section 4). 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- off between a number of properties (processing requirements, ease of implementation, possible intellectual property rights, etc.), and since the best possible choice for F() might be different for different types of devices (e.g. embedded systems vs. regular servers) and might possibly change over time. Note that the result of F() in the algorithm above is no more secure @@ -402,40 +403,40 @@ We note that this algorithm is meant to be an alternative to interface identifiers such as those specified in [RFC2464], but is not meant as an alternative to temporary Interface IDs (such as those specified in [RFC4941]). Clearly, temporary addresses may help to mitigate the correlation of activities of a node within the same network, and may also reduce the attack exposure window (since privacy/temporary addresses are short-lived when compared to the addresses generated with the method specified in this document). We note that implementation of this algorithm would still benefit those hosts employing "Privacy Addresses", since it would mitigate host- - tracking vectors still present when privacy addresses are used - (Appendix A, and would also mitigate host-scanning techniques that + tracking vectors still present when privacy addresses are used (see + Appendix A), and would also mitigate host-scanning techniques that leverage patterns in IPv6 addresses that embed IEEE identifiers. Finally, we note that the method described in this document may mitigate most of the privacy concerns arising from the use of IPv6 addresses that embed IEEE identifiers, without the use of temporary addresses, thus possibly offering an interesting trade-off for those scenarios in which the use of temporary addresses is not feasible. 7. Acknowledgements 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) Karl Auer, - Steven Bellovin, Matthias Bethke, Brian Carpenter, Dominik Elsbroek, - Bob Hinden, Christian Huitema, Ray Hunter, Jong-Hyouk Lee, Michael - Richardson, and Ole Troan, for providing valuable comments on earlier - versions of this document. + Steven Bellovin, Matthias Bethke, Brian Carpenter, Tassos + Chatzithomaoglou, Dominik Elsbroek, Bob Hinden, Christian Huitema, + Ray Hunter, Jong-Hyouk Lee, Michael Richardson, and Ole Troan, for + providing valuable comments on earlier versions of this document. This document is based on the technical report "Security Assessment of the Internet Protocol version 6 (IPv6)" [CPNI-IPv6] authored by Fernando Gont on behalf of the UK Centre for the Protection of National Infrastructure (CPNI). Fernando Gont would like to thank CPNI (http://www.cpni.gov.uk) for their continued support. 8. References @@ -475,20 +476,24 @@ [RFC3542] Stevens, W., Thomas, M., Nordmark, E., and T. Jinmei, "Advanced Sockets Application Program Interface (API) for IPv6", RFC 3542, May 2003. [I-D.ietf-opsec-ipv6-host-scanning] Gont, F. and T. Chown, "Network Reconnaissance in IPv6 Networks", draft-ietf-opsec-ipv6-host-scanning-00 (work in progress), December 2012. + [IANA-RESERVED-IID] + Reserved IPv6 Interface Identifiers, "http://www.iana.org/ + assignments/ipv6-interface-ids/ipv6-interface-ids.xml". + [Gont-DEEPSEC2011] Gont, "Results of a Security Assessment of the Internet Protocol version 6 (IPv6)", DEEPSEC 2011 Conference, Vienna, Austria, November 2011, . [Gont-BRUCON2012] Gont, "Recent Advances in IPv6 Security", BRUCON 2012 Conference, Ghent, Belgium, September 2012,