draft-ietf-6man-stable-privacy-addresses-05.txt		draft-ietf-6man-stable-privacy-addresses-06.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 March 22, 2013		Intended status: Standards Track April 12, 2013
	Expires: September 23, 2013		Expires: October 14, 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-05		draft-ietf-6man-stable-privacy-addresses-06
	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 September 23, 2013.		This Internet-Draft will expire on October 14, 2013.
	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 3, line 44		skipping to change at page 3, line 44
	"privacy addresses" [RFC4941] do not eliminate the use of fixed		"privacy addresses" [RFC4941] do not eliminate the use of fixed
	identifiers for server-like functions, they only *partially*		identifiers for server-like functions, they only *partially*
	mitigate the correlation of host activities (see Appendix A for		mitigate the correlation of host activities (see Appendix A for
	some example attacks that are still possible with privacy		some example attacks that are still possible with privacy
	addresses). Therefore, it is vital that the privacy		addresses). Therefore, it is vital that the privacy
	characteristics of "stable" addresses are improved such that the		characteristics of "stable" addresses are improved such that the
	ability of an attacker correlating host activities across networks		ability of an attacker correlating host activities across networks
	is reduced.		is reduced.
	Another important aspect not mitigated by "Privacy Addresses"		Another important aspect not mitigated by "Privacy Addresses"
	[RFC4941] is that of host scanning. Since IPv6 addresses that		[RFC4941] is that of IPv6 address scanning. Since IPv6 addresses
	embed IEEE identifiers have specific patterns, an attacker could		that embed IEEE identifiers have specific patterns, an attacker
	leverage such patterns to greatly reduce the search space for		could leverage such patterns to greatly reduce the search space
	"live" hosts. Since "privacy addresses" do not eliminate the use		for "live" hosts. Since "privacy addresses" do not eliminate the
	of IPv6 addresses that embed IEEE identifiers, host scanning		use of IPv6 addresses that embed IEEE identifiers, address
	attacks are still feasible even if "privacy extensions" are		scanning attacks are still feasible even if "privacy extensions"
	employed [Gont-DEEPSEC2011] [CPNI-IPv6]. This is yet another		are employed [Gont-DEEPSEC2011] [CPNI-IPv6]. This is yet another
	motivation to improve the privacy characteristics of "stable"		motivation to improve the privacy characteristics of "stable"
	addresses (currently embedding IEEE identifiers).		addresses (currently embedding IEEE identifiers).
	Privacy/temporary addresses can be challenging in a number of areas.		Privacy/temporary addresses can be challenging in a number of areas.
	For example, from a network-management point of view, they tend to		For example, from a network-management point of view, they tend to
	increase the complexity of event logging, trouble-shooting, and		increase the complexity of event logging, trouble-shooting, and
	enforcing access controls and quality of service, etc. As a result,		enforcing access controls and quality of service, etc. As a result,
	some organizations disable the use of privacy addresses even at the		some organizations disable the use of privacy addresses even at the
	expense of reduced privacy [Broersma]. Also, they result in		expense of reduced privacy [Broersma]. Also, they result in
	increased complexity, which might not be possible or desirable in		increased complexity, which might not be possible or desirable in
	skipping to change at page 4, line 27		skipping to change at page 4, line 27
	identifiers, and this is yet another case in which it is also vital		identifiers, and this is yet another case in which it is also vital
	that the privacy characteristics of these stable addresses are		that the privacy characteristics of these stable addresses are
	improved.		improved.
	We note that in most (if not all) of those scenarios in which		We note that in most (if not all) of those scenarios in which
	"Privacy Extensions" are disabled, there is usually no actual desire		"Privacy Extensions" are disabled, there is usually no actual desire
	to negatively affect user privacy, but rather a desire to simplify		to negatively affect user privacy, but rather a desire to simplify
	operation of the network (simplify the use of ACLs, logging, etc.).		operation of the network (simplify the use of ACLs, logging, etc.).
	This document specifies a method to generate interface identifiers		This document specifies a method to generate interface identifiers
	that are stable/constant within each subnet, but that change as hosts		that are stable/constant for each network interface within each
	move from one network to another, thus keeping the "stability"		subnet, but that change as hosts move from one network to another,
	properties of the interface identifiers specified in [RFC4291], while		thus keeping the "stability" properties of the interface identifiers
	still mitigating host-scanning attacks and preventing correlation of		specified in [RFC4291], while still mitigating address-scanning
	the activities of a node as it moves from one network to another.		attacks and preventing correlation of the activities of a node as it
			moves from one network to another.
			We note that this method is incrementally deployable, since it does
			not pose any interoperability implications when deployed on networks
			where other nodes do not implement or employ it.
	This document does not update or modify IPv6 StateLess Address Auto-		This document does not update or modify IPv6 StateLess Address Auto-
	Configuration (SLAAC) [RFC4862] itself, but rather only specifies an		Configuration (SLAAC) [RFC4862] itself, but rather only specifies an
	alternative algorithm to generate Interface IDs. Therefore, the		alternative algorithm to generate Interface IDs. Therefore, the
	usual address lifetime properties (as specified in the corresponding		usual address lifetime properties (as specified in the corresponding
	Prefix Information Options) apply when IPv6 addresses are generated		Prefix Information Options) apply when IPv6 addresses are generated
	as a result of employing the algorithm specified in this document		as a result of employing the algorithm specified in this document
	with SLAAC [RFC4862]. Additionally, from the point of view of		with SLAAC [RFC4862]. Additionally, from the point of view of
	renumbering, we note that these addresses behave like the traditional		renumbering, we note that these addresses behave like the traditional
	IPv6 addresses (that embed a hardware address) resulting from SLAAC		IPv6 addresses (that embed a hardware address) resulting from SLAAC
	skipping to change at page 6, line 40		skipping to change at page 6, line 40
	other addresses.		other addresses.
	o The aforementioned interface identifiers are meant to be an		o The aforementioned interface identifiers are meant to be an
	alternative to those based on e.g. IEEE identifiers, such as		alternative to those based on e.g. IEEE identifiers, such as
	those specified in [RFC2464].		those specified in [RFC2464].
	We note that of use of the algorithm specified in this document is		We note that of use of the algorithm specified in this document is
	(to a large extent) orthogonal to the use of "Privacy Extensions"		(to a large extent) orthogonal to the use of "Privacy Extensions"
	[RFC4941]. Hosts that do not implement/use "Privacy Extensions"		[RFC4941]. Hosts that do not implement/use "Privacy Extensions"
	would have the benefit that they would not be subject to the host-		would have the benefit that they would not be subject to the host-
	tracking and host scanning issues discussed in the previous section.		tracking and address scanning issues discussed in the previous
	On the other hand, in the case of hosts employing "Privacy		section. On the other hand, in the case of hosts employing "Privacy
	Extensions", the method specified in this document would prevent host		Extensions", the method specified in this document would prevent
	scanning attacks and correlation of node activities across networks		address scanning attacks and correlation of node activities across
	(see Appendix A).		networks (see Appendix A).
	3. Algorithm specification		3. Algorithm specification
	IPv6 implementations conforming to this specification MUST generate		IPv6 implementations conforming to this specification MUST generate
	interface identifiers using the algorithm specified in this section		interface identifiers using the algorithm specified in this section
	in replacement of any other algorithms used for generating "stable"		in replacement of any other algorithms used for generating "stable"
	addresses (such as that specified in [RFC2464]). The aforementioned		addresses (such as that specified in [RFC2464]). The aforementioned
	algorithm MUST be employed for generating the interface identifiers		algorithm MUST be employed for generating the interface identifiers
	for all of the IPv6 addresses configured with SLAAC for a given		for all of the IPv6 addresses configured with SLAAC for a given
	interface, including IPv6 link-local addresses.		interface, including IPv6 link-local addresses.
	skipping to change at page 9, line 17		skipping to change at page 9, line 17
	the attacker may simply search the entire secret-key space to find		the attacker may simply search the entire secret-key space to find
	matches. To protect against this, the secret key should be of a		matches. To protect against this, the secret key should be of a
	reasonable length. Key lengths of at least 128 bits should be		reasonable length. Key lengths of at least 128 bits should be
	adequate. The secret key is initialized at system installation time		adequate. The secret key is initialized at system installation time
	to a pseudo-random number, thus allowing this mechanism to be		to a pseudo-random number, thus allowing this mechanism to be
	enabled/used automatically, without user intervention.		enabled/used automatically, without user intervention.
	Including the SLAAC prefix in the PRF computation causes the		Including the SLAAC prefix in the PRF computation causes the
	Interface ID to vary across networks that employ different prefixes,		Interface ID to vary across networks that employ different prefixes,
	thus mitigating host-tracking attacks and any other attacks that		thus mitigating host-tracking attacks and any other attacks that
	benefit from predictable Interface IDs (such as host scanning).		benefit from predictable Interface IDs (such as address scanning).
			The Interface Index is expected to remain constant across system
			reboots and other events. However, we note that it might change upon
			removal or installation of a network interface (typically one with a
			smaller value for the Interface Index, when such a naming scheme is
			used). When such change occurs, the IPv6 addresses resulting from
			this algorithm for the corresponding interface will change, thus
			affecting the stability property of this method. We note that we
			expect these scenarios to be unusual. Some implementations are known
			to provide configuration knobs to set the Interface Index for a given
			interface. Such configuration knobs could be employed to prevent the
			Interface Index from changing (e.g. as a result of the removal of a
			network interface).
	Including the optional Network_ID parameter when computing the RID		Including the optional Network_ID parameter when computing the RID
	value above would cause the algorithm to produce a different		value above would cause the algorithm to produce a different
	Interface Identifier when connecting to different networks, even when		Interface Identifier when connecting to different networks, even when
	configuring addresses belonging to the same prefix. This means that		configuring addresses belonging to the same prefix. This means that
	a host would employ a different Interface ID as it moves from one		a host would employ a different Interface ID as it moves from one
	network to another even for IPv6 link-local addresses or Unique Local		network to another even for IPv6 link-local addresses or Unique Local
	Addresses (ULAs).		Addresses (ULAs).
			The DAD_Counter parameter provides the means to intentionally cause
			this algorithm produce a different IPv6 addresses (all other
			parameters being the same). This could be necessary to resolve
			Duplicate Address Detection (DAD) conflicts, as discussed in detail
			in Section 4.
	4. Resolving Duplicate Address Detection (DAD) conflicts		4. Resolving Duplicate Address Detection (DAD) conflicts
	If as a result of performing Duplicate Address Detection (DAD)		If as a result of performing Duplicate Address Detection (DAD)
	[RFC4862] a host finds that the tentative address generated with the		[RFC4862] a host finds that the tentative address generated with the
	algorithm specified in Section 3 is a duplicate address, it SHOULD		algorithm specified in Section 3 is a duplicate address, it SHOULD
	resolve the address conflict by trying a new tentative address as		resolve the address conflict by trying a new tentative address as
	follows:		follows:
	o DAD_Counter is incremented by 1.		o DAD_Counter is incremented by 1.
	skipping to change at page 13, line 12		skipping to change at page 13, line 12
	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, Tassos		Steven Bellovin, Matthias Bethke, Brian Carpenter, Tassos
	Chatzithomaoglou, Dominik Elsbroek, Bob Hinden, Christian Huitema,		Chatzithomaoglou, Dominik Elsbroek, Brian Haberman, Bob Hinden,
	Ray Hunter, Jong-Hyouk Lee, Michael Richardson, and Ole Troan, for		Christian Huitema, Ray Hunter, Jong-Hyouk Lee, Michael Richardson,
	providing valuable comments on earlier versions of this document.		Mark Smith, and Ole Troan, 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 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 17, line 39		skipping to change at page 17, line 39
	can tell whether it is the same device providing some function in two		can tell whether it is the same device providing some function in two
	different networks, at two different points in time).		different networks, at two different points in time).
	The scheme proposed in this document prevents such information		The scheme proposed in this document prevents such information
	leakage by causing nodes to generate different Interface-IDs when		leakage by causing nodes to generate different Interface-IDs when
	moving to one network to another, thus mitigating this kind of		moving to one network to another, thus mitigating this kind of
	privacy attack.		privacy attack.
	A.2. Address scanning attacks		A.2. Address scanning attacks
	While it is usually assumed that address-scanning attacks are		While it is usually assumed that IPv6 address-scanning attacks are
	unfeasible, an attacker could leverage patterns in IPv6 addresses to		unfeasible, an attacker could leverage patterns in IPv6 addresses to
	greatly reduce the search space [I-D.ietf-opsec-ipv6-host-scanning]		greatly reduce the search space [I-D.ietf-opsec-ipv6-host-scanning]
	[Gont-BRUCON2012].		[Gont-BRUCON2012].
	As noted earlier in this document, privacy/temporary addresses do not		As noted earlier in this document, privacy/temporary addresses do not
	eliminate the use of IPv6 addresses that embed IEEE identifiers, and		eliminate the use of IPv6 addresses that embed IEEE identifiers, and
	hence such hosts would still be vulnerable to address-scanning		hence such hosts would still be vulnerable to address-scanning
	attacks. The method specified in this document eliminates such		attacks. The method specified in this document eliminates such
	patterns and would thus mitigate the aforementioned address-scanning		patterns and would thus mitigate the aforementioned address-scanning
	attacks.		attacks.
End of changes. 10 change blocks.
	26 lines changed or deleted		51 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/