draft-ietf-6man-stable-privacy-addresses-02.txt		draft-ietf-6man-stable-privacy-addresses-03.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 December 30, 2012		Intended status: Standards Track January 27, 2013
	Expires: July 3, 2013		Expires: July 31, 2013
	A method for Generating Stable Privacy-Enhanced Addresses with IPv6		A method for Generating Stable Privacy-Enhanced Addresses with IPv6
	Stateless Address Autoconfiguration (SLAAC)		Stateless Address Autoconfiguration (SLAAC)
	draft-ietf-6man-stable-privacy-addresses-02		draft-ietf-6man-stable-privacy-addresses-03
	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. The aforementioned method is meant		move from one network to another. The aforementioned method is meant
	to be an alternative to generating Interface Identifiers based on		to be an alternative to generating Interface Identifiers based on
	IEEE identifiers, such that the benefits of stable addresses can be		IEEE identifiers, such that the benefits of stable addresses can be
	skipping to change at page 1, line 38		skipping to change at page 1, line 38
	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 July 3, 2013.		This Internet-Draft will expire on July 31, 2013.
	Copyright Notice		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.		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
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	skipping to change at page 8, line 35		skipping to change at page 8, line 35
	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 at system installation time to a		key MUST be initialized at system installation time to a
	pseudo-random number (see [RFC4086] for randomness		pseudo-random number (see [RFC4086] for randomness
	requirements for security). An implementation MAY provide the		requirements for security). An implementation MAY provide the
	means for the user to change the secret key.		means for the user to change the secret key.
	2. The Interface Identifier is finally obtained by taking the		2. The Interface Identifier is finally obtained by taking the
	leftmost 64 bits of the RID value computed in the previous step,		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.		and setting bit 6 (the leftmost bit is numbered 0) to zero. This
	This creates an interface identifier with the universal/local bit		creates an interface identifier with the universal/local bit
	indicating local significance only. The resulting Interface		indicating local significance only. The resulting Interface
	Identifier should be compared against a list of reserved		Identifier should be compared against the list of reserved
	interface identifiers and to those already employed in an address		interface identifiers [IANA-RESERVED-IID], and to those interface
	of the same network interface and the same network prefix. In		identifiers already employed in an address of the same network
	the event that an unacceptable identifier has been generated,		interface and the same network prefix. In the event that an
	this situation should be handled in the same way as the case of		unacceptable identifier has been generated, this situation should
	duplicate addresses (see Section 4).		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		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
	since the best possible choice for F() might be different for		since the best possible choice for F() might be different for
	different types of devices (e.g. embedded systems vs. regular		different types of devices (e.g. embedded systems vs. regular
	servers) and might possibly change over time.		servers) and might possibly change over time.
	Note that the result of F() in the algorithm above is no more secure		Note that the result of F() in the algorithm above is no more secure
	skipping to change at page 12, line 38		skipping to change at page 12, line 38
	We note that this algorithm is meant to be an alternative to		We note that this algorithm is meant to be an alternative to
	interface identifiers such as those specified in [RFC2464], but is		interface identifiers such as those specified in [RFC2464], but is
	not meant as an alternative to temporary Interface IDs (such as those		not meant as an alternative to temporary Interface IDs (such as those
	specified in [RFC4941]). Clearly, temporary addresses may help to		specified in [RFC4941]). Clearly, temporary addresses may help to
	mitigate the correlation of activities of a node within the same		mitigate the correlation of activities of a node within the same
	network, and may also reduce the attack exposure window (since		network, and may also reduce the attack exposure window (since
	privacy/temporary addresses are short-lived when compared to the		privacy/temporary addresses are short-lived when compared to the
	addresses generated with the method specified in this document). We		addresses generated with the method specified in this document). We
	note that implementation of this algorithm would still benefit those		note that implementation of this algorithm would still benefit those
	hosts employing "Privacy Addresses", since it would mitigate host-		hosts employing "Privacy Addresses", since it would mitigate host-
	tracking vectors still present when privacy addresses are used		tracking vectors still present when privacy addresses are used (see
	(Appendix A, and would also mitigate host-scanning techniques that		Appendix A), and would also mitigate host-scanning techniques that
	leverage patterns in IPv6 addresses that embed IEEE identifiers.		leverage patterns in IPv6 addresses that embed IEEE identifiers.
	Finally, we note that the method described in this document may		Finally, we note that the method described in this document may
	mitigate most of the privacy concerns arising from the use of IPv6		mitigate most of the privacy concerns arising from the use of IPv6
	addresses that embed IEEE identifiers, without the use of temporary		addresses that embed IEEE identifiers, without the use of temporary
	addresses, thus possibly offering an interesting trade-off for those		addresses, thus possibly offering an interesting trade-off for those
	scenarios in which the use of temporary addresses is not feasible.		scenarios in which the use of temporary addresses is not feasible.
	7. Acknowledgements		7. 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) Karl Auer,		The author would like to thank (in alphabetical order) Karl Auer,
	Steven Bellovin, Matthias Bethke, Brian Carpenter, Dominik Elsbroek,		Steven Bellovin, Matthias Bethke, Brian Carpenter, Tassos
	Bob Hinden, Christian Huitema, Ray Hunter, Jong-Hyouk Lee, Michael		Chatzithomaoglou, Dominik Elsbroek, Bob Hinden, Christian Huitema,
	Richardson, and Ole Troan, for providing valuable comments on earlier		Ray Hunter, Jong-Hyouk Lee, Michael Richardson, and Ole Troan, for
	versions of this document.		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 CPNI (http://www.cpni.gov.uk) for		Fernando Gont would like to thank CPNI (http://www.cpni.gov.uk) for
	their continued support.		their continued support.
	8. References		8. References
	skipping to change at page 14, line 49		skipping to change at page 14, line 49
	[RFC3542] Stevens, W., Thomas, M., Nordmark, E., and T. Jinmei,		[RFC3542] Stevens, W., Thomas, M., Nordmark, E., and T. Jinmei,
	"Advanced Sockets Application Program Interface (API) for		"Advanced Sockets Application Program Interface (API) for
	IPv6", RFC 3542, May 2003.		IPv6", RFC 3542, May 2003.
	[I-D.ietf-opsec-ipv6-host-scanning]		[I-D.ietf-opsec-ipv6-host-scanning]
	Gont, F. and T. Chown, "Network Reconnaissance in IPv6		Gont, F. and T. Chown, "Network Reconnaissance in IPv6
	Networks", draft-ietf-opsec-ipv6-host-scanning-00 (work in		Networks", draft-ietf-opsec-ipv6-host-scanning-00 (work in
	progress), December 2012.		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-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, <http://
	www.si6networks.com/presentations/deepsec2011/		www.si6networks.com/presentations/deepsec2011/
	fgont-deepsec2011-ipv6-security.pdf>.		fgont-deepsec2011-ipv6-security.pdf>.
	[Gont-BRUCON2012]		[Gont-BRUCON2012]
	Gont, "Recent Advances in IPv6 Security", BRUCON 2012		Gont, "Recent Advances in IPv6 Security", BRUCON 2012
	Conference, Ghent, Belgium, September 2012, <http://		Conference, Ghent, Belgium, September 2012, <http://
End of changes. 10 change blocks.
	20 lines changed or deleted		25 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/