draft-ietf-6man-ipv6-address-generation-privacy-03.txt		draft-ietf-6man-ipv6-address-generation-privacy-04.txt
	Network Working Group A. Cooper		Network Working Group A. Cooper
	Internet-Draft Cisco		Internet-Draft Cisco
	Intended status: Informational F. Gont		Intended status: Informational F. Gont
	Expires: July 19, 2015 Huawei Technologies		Expires: August 27, 2015 Huawei Technologies
	D. Thaler		D. Thaler
	Microsoft		Microsoft
	January 15, 2015		February 23, 2015
	Privacy Considerations for IPv6 Address Generation Mechanisms		Privacy Considerations for IPv6 Address Generation Mechanisms
	draft-ietf-6man-ipv6-address-generation-privacy-03.txt		draft-ietf-6man-ipv6-address-generation-privacy-04.txt
	Abstract		Abstract
	This document discusses privacy and security considerations for		This document discusses privacy and security considerations for
	several IPv6 address generation mechanisms, both standardized and		several IPv6 address generation mechanisms, both standardized and
	non-standardized. It evaluates how different mechanisms mitigate		non-standardized. It evaluates how different mechanisms mitigate
	different threats and the trade-offs that implementors, developers,		different threats and the trade-offs that implementors, developers,
	and users face in choosing different addresses or address generation		and users face in choosing different addresses or address generation
	mechanisms.		mechanisms.
	Status of this Memo		Status of This Memo
	This Internet-Draft is submitted in full conformance with the		This Internet-Draft is submitted in full conformance with the
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and BCP 79.
	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 19, 2015.		This Internet-Draft will expire on August 27, 2015.
	Copyright Notice		Copyright Notice
	Copyright (c) 2015 IETF Trust and the persons identified as the		Copyright (c) 2015 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
	described in the Simplified BSD License.		described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
	2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5		2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
	3. Weaknesses in IEEE-identifier-based IIDs . . . . . . . . . . . 6		3. Weaknesses in IEEE-identifier-based IIDs . . . . . . . . . . 4
	3.1. Correlation of activities over time . . . . . . . . . . . 6		3.1. Correlation of activities over time . . . . . . . . . . . 5
	3.2. Location tracking . . . . . . . . . . . . . . . . . . . . 7		3.2. Location tracking . . . . . . . . . . . . . . . . . . . . 6
	3.3. Address scanning . . . . . . . . . . . . . . . . . . . . . 7		3.3. Address scanning . . . . . . . . . . . . . . . . . . . . 6
	3.4. Device-specific vulnerability exploitation . . . . . . . . 8		3.4. Device-specific vulnerability exploitation . . . . . . . 7
	4. Privacy and security properties of address generation		4. Privacy and security properties of address generation
	mechanisms . . . . . . . . . . . . . . . . . . . . . . . . . . 9		mechanisms . . . . . . . . . . . . . . . . . . . . . . . . . 7
	4.1. IEEE-identifier-based IIDs . . . . . . . . . . . . . . . . 11		4.1. IEEE-identifier-based IIDs . . . . . . . . . . . . . . . 9
	4.2. Static, manually configured IIDs . . . . . . . . . . . . . 11		4.2. Static, manually configured IIDs . . . . . . . . . . . . 10
	4.3. Constant, semantically opaque IIDs . . . . . . . . . . . . 11		4.3. Constant, semantically opaque IIDs . . . . . . . . . . . 10
	4.4. Cryptographically generated IIDs . . . . . . . . . . . . . 12		4.4. Cryptographically generated IIDs . . . . . . . . . . . . 10
	4.5. Stable, semantically opaque IIDs . . . . . . . . . . . . . 12		4.5. Stable, semantically opaque IIDs . . . . . . . . . . . . 10
	4.6. Temporary IIDs . . . . . . . . . . . . . . . . . . . . . . 12		4.6. Temporary IIDs . . . . . . . . . . . . . . . . . . . . . 11
	4.7. DHCPv6 generation of IIDs . . . . . . . . . . . . . . . . 13		4.7. DHCPv6 generation of IIDs . . . . . . . . . . . . . . . . 12
	4.8. Transition/co-existence technologies . . . . . . . . . . . 13		4.8. Transition/co-existence technologies . . . . . . . . . . 12
	5. Miscellaneous Issues with IPv6 addressing . . . . . . . . . . 15		5. Miscellaneous Issues with IPv6 addressing . . . . . . . . . . 12
	5.1. Network Operation . . . . . . . . . . . . . . . . . . . . 15		5.1. Network Operation . . . . . . . . . . . . . . . . . . . . 12
	5.2. Compliance . . . . . . . . . . . . . . . . . . . . . . . . 15		5.2. Compliance . . . . . . . . . . . . . . . . . . . . . . . 13
	5.3. Intellectual Property Rights (IPRs) . . . . . . . . . . . 15		5.3. Intellectual Property Rights (IPRs) . . . . . . . . . . . 13
	6. Security Considerations . . . . . . . . . . . . . . . . . . . 16		6. Security Considerations . . . . . . . . . . . . . . . . . . . 13
	7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17		7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
	8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18		8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13
	9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19		9. References . . . . . . . . . . . . . . . . . . . . . . . . . 13
	9.1. Normative References . . . . . . . . . . . . . . . . . . . 19		9.1. Normative References . . . . . . . . . . . . . . . . . . 13
	9.2. Informative References . . . . . . . . . . . . . . . . . . 20		9.2. Informative References . . . . . . . . . . . . . . . . . 15
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16
	1. Introduction		1. Introduction
	IPv6 was designed to improve upon IPv4 in many respects, and		IPv6 was designed to improve upon IPv4 in many respects, and
	mechanisms for address assignment were one such area for improvement.		mechanisms for address assignment were one such area for improvement.
	In addition to static address assignment and DHCP, stateless		In addition to static address assignment and DHCP, stateless
	autoconfiguration was developed as a less intensive, fate-shared		autoconfiguration was developed as a less intensive, fate-shared
	means of performing address assignment. With stateless		means of performing address assignment. With stateless
	autoconfiguration, routers advertise on-link prefixes and hosts		autoconfiguration, routers advertise on-link prefixes and hosts
	generate their own interface identifiers (IIDs) to complete their		generate their own interface identifiers (IIDs) to complete their
	skipping to change at page 6, line 38		skipping to change at page 5, line 25
	the order of years, compared to days for DHCP.		the order of years, compared to days for DHCP.
	As [RFC4941] explains,		As [RFC4941] explains,
	"[t]he use of a non-changing interface identifier to form		"[t]he use of a non-changing interface identifier to form
	addresses is a specific instance of the more general case where a		addresses is a specific instance of the more general case where a
	constant identifier is reused over an extended period of time and		constant identifier is reused over an extended period of time and
	in multiple independent activities. Anytime the same identifier		in multiple independent activities. Anytime the same identifier
	is used in multiple contexts, it becomes possible for that		is used in multiple contexts, it becomes possible for that
	identifier to be used to correlate seemingly unrelated activity.		identifier to be used to correlate seemingly unrelated activity.
	... The use of a constant identifier within an address is of		... The use of a constant identifier within an address is of
	special concern because addresses are a fundamental requirement of		special concern because addresses are a fundamental requirement of
	communication and cannot easily be hidden from eavesdroppers and		communication and cannot easily be hidden from eavesdroppers and
	other parties. Even when higher layers encrypt their payloads,		other parties. Even when higher layers encrypt their payloads,
	addresses in packet headers appear in the clear."		addresses in packet headers appear in the clear."
	IP addresses are just one example of information that can be used to		IP addresses are just one example of information that can be used to
	correlate activities over time. DNS names, cookies [RFC6265],		correlate activities over time. DNS names, cookies [RFC6265],
	browser fingerprints [Panopticlick], and application-layer usernames		browser fingerprints [Panopticlick], and application-layer usernames
	can all be used to link a host's activities together. Although IEEE-		can all be used to link a host's activities together. Although IEEE-
	identifier-based IIDs are likely to last at least as long or longer		identifier-based IIDs are likely to last at least as long or longer
	skipping to change at page 8, line 15		skipping to change at page 7, line 8
	value (0xff, 0xfe) used to form a Modified EUI-64 Interface		value (0xff, 0xfe) used to form a Modified EUI-64 Interface
	Identifier, greatly help to reduce the search space, making it easier		Identifier, greatly help to reduce the search space, making it easier
	for an attacker to scan for individual addresses using widely-known		for an attacker to scan for individual addresses using widely-known
	popular OUIs. This erases much of the protection against address		popular OUIs. This erases much of the protection against address
	scanning that the larger IPv6 address space was supposed to provide		scanning that the larger IPv6 address space was supposed to provide
	as compared to IPv4.		as compared to IPv4.
	3.4. Device-specific vulnerability exploitation		3.4. Device-specific vulnerability exploitation
	IPv6 addresses that embed IEEE identifiers leak information about the		IPv6 addresses that embed IEEE identifiers leak information about the
	device (Network Interface Card vendor, or even Operating System		device (Network Interface Card vendor, or even Operating System and/
	and/or software type), which could be leveraged by an attacker with		or software type), which could be leveraged by an attacker with
	knowledge of device/software-specific vulnerabilities to quickly find		knowledge of device/software-specific vulnerabilities to quickly find
	possible targets. Attackers can exploit vulnerabilities in hosts		possible targets. Attackers can exploit vulnerabilities in hosts
	whose IIDs they have previously obtained, or scan an address space to		whose IIDs they have previously obtained, or scan an address space to
	find potential targets.		find potential targets.
	4. Privacy and security properties of address generation mechanisms		4. Privacy and security properties of address generation mechanisms
	Analysis of the extent to which a particular host is protected		Analysis of the extent to which a particular host is protected
	against the threats described in Section 3 depends on how each of a		against the threats described in Section 3 depends on how each of a
	host's addresses is generated and used. In some scenarios, a host		host's addresses is generated and used. In some scenarios, a host
	skipping to change at page 12, line 24		skipping to change at page 10, line 50
	public key and the chosen modifier block, since it is possible to		public key and the chosen modifier block, since it is possible to
	rotate modifier blocks without generating new public keys. Because		rotate modifier blocks without generating new public keys. Because
	the cryptographic hash of the host's public key uses the subnet		the cryptographic hash of the host's public key uses the subnet
	prefix as an input, even if the host does not generate a new public		prefix as an input, even if the host does not generate a new public
	key or modifier block when it moves to a different network, its		key or modifier block when it moves to a different network, its
	location cannot be tracked via the IID. CGAs do not allow device-		location cannot be tracked via the IID. CGAs do not allow device-
	specific exploitation or address scanning attacks.		specific exploitation or address scanning attacks.
	4.5. Stable, semantically opaque IIDs		4.5. Stable, semantically opaque IIDs
	[RFC7217] specifies a mechanism that generates a unique random IID		[RFC7217] specifies an algorithm that generates, for each network
	for each network. A host that stays connected to the same network		interface, a unique random IID per network. The aforementioned
	could therefore be tracked at length, whereas a mobile host's		algorithm is employed not only for global unicast addresses, but also
	activities could only be correlated for the duration of each network		for unique local unicast addresses and link-local unicast addresses,
	connection. Location tracking is not possible with these addresses.		since these addresses may leak out via application protocols (e.g.,
	They also do not allow device-specific exploitation or address		IPv6 addresses embedded in email headers).
	scanning attacks.
			A host that stays connected to the same network could therefore be
			tracked at length, whereas a mobile host's activities could only be
			correlated for the duration of each network connection. Location
			tracking is not possible with these addresses. They also do not
			allow device-specific exploitation or address scanning attacks.
	4.6. Temporary IIDs		4.6. Temporary IIDs
	A host that uses only a temporary address mitigates all four threats.		A host that uses only a temporary address mitigates all four threats.
	Its activities may only be correlated for the lifetime a single		Its activities may only be correlated for the lifetime a single
	temporary address.		temporary address.
	A host that configures both an IEEE-identifier-based IID and		A host that configures both an IEEE-identifier-based IID and
	temporary addresses makes the host vulnerable to the same attacks as		temporary addresses makes the host vulnerable to the same attacks as
	if temporary addresses were not in use, although the viability of		if temporary addresses were not in use, although the viability of
	skipping to change at page 19, line 26		skipping to change at page 14, line 13
	Autoconfiguration", RFC 2462, December 1998.		Autoconfiguration", RFC 2462, December 1998.
	[RFC2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet		[RFC2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet
	Networks", RFC 2464, December 1998.		Networks", RFC 2464, December 1998.
	[RFC3041] Narten, T. and R. Draves, "Privacy Extensions for		[RFC3041] Narten, T. and R. Draves, "Privacy Extensions for
	Stateless Address Autoconfiguration in IPv6", RFC 3041,		Stateless Address Autoconfiguration in IPv6", RFC 3041,
	January 2001.		January 2001.
	[RFC3314] Wasserman, M., "Recommendations for IPv6 in Third		[RFC3314] Wasserman, M., "Recommendations for IPv6 in Third
	Generation Partnership Project (3GPP) Standards",		Generation Partnership Project (3GPP) Standards", RFC
	RFC 3314, September 2002.		3314, September 2002.
	[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.
	[RFC3484] Draves, R., "Default Address Selection for Internet		[RFC3484] Draves, R., "Default Address Selection for Internet
	Protocol version 6 (IPv6)", RFC 3484, February 2003.		Protocol version 6 (IPv6)", RFC 3484, February 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.
	[RFC4380] Huitema, C., "Teredo: Tunneling IPv6 over UDP through		[RFC4380] Huitema, C., "Teredo: Tunneling IPv6 over UDP through
	Network Address Translations (NATs)", RFC 4380,		Network Address Translations (NATs)", RFC 4380, February
	February 2006.		2006.
	[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.
	[RFC5991] Thaler, D., Krishnan, S., and J. Hoagland, "Teredo		[RFC5991] Thaler, D., Krishnan, S., and J. Hoagland, "Teredo
	Security Updates", RFC 5991, September 2010.		Security Updates", RFC 5991, September 2010.
	[RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265,		[RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265,
	April 2011.		April 2011.
	skipping to change at page 20, line 22		skipping to change at page 15, line 8
	[RFC7136] Carpenter, B. and S. Jiang, "Significance of IPv6		[RFC7136] Carpenter, B. and S. Jiang, "Significance of IPv6
	Interface Identifiers", RFC 7136, February 2014.		Interface Identifiers", RFC 7136, February 2014.
	[RFC7217] Gont, F., "A Method for Generating Semantically Opaque		[RFC7217] Gont, F., "A Method for Generating Semantically Opaque
	Interface Identifiers with IPv6 Stateless Address		Interface Identifiers with IPv6 Stateless Address
	Autoconfiguration (SLAAC)", RFC 7217, April 2014.		Autoconfiguration (SLAAC)", RFC 7217, April 2014.
	9.2. Informative References		9.2. Informative References
	[Broersma]		[Broersma]
	Broersma, R., "IPv6 Everywhere: Living with a Fully IPv6-		Broersma, R., "IPv6 Everywhere: Living with a Fully
	enabled environment", Australian IPv6 Summit 2010,		IPv6-enabled environment", Australian IPv6 Summit 2010,
	Melbourne, VIC Australia, October 2010, October 2010, <htt		Melbourne, VIC Australia, October 2010, October 2010,
	p://www.ipv6.org.au/10ipv6summit/talks/Ron_Broersma.pdf>.		<http://www.ipv6.org.au/10ipv6summit/talks/
			Ron_Broersma.pdf>.
	[CGA-IPR] IETF, "Intellectual Property Rights on RFC 3972", 2005.		[CGA-IPR] IETF, "Intellectual Property Rights on RFC 3972", 2005.
	[I-D.ietf-dhc-stable-privacy-addresses]		[I-D.ietf-dhc-stable-privacy-addresses]
	Gont, F. and W. Will, "A Method for Generating		Gont, F. and W. Will, "A Method for Generating
	Semantically Opaque Interface Identifiers with Dynamic		Semantically Opaque Interface Identifiers with Dynamic
	Host Configuration Protocol for IPv6 (DHCPv6)",		Host Configuration Protocol for IPv6 (DHCPv6)", draft-
	draft-ietf-dhc-stable-privacy-addresses-00 (work in		ietf-dhc-stable-privacy-addresses-01 (work in progress),
	progress), October 2014.		February 2015.
	[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-04 (work in		Networks", draft-ietf-opsec-ipv6-host-scanning-06 (work in
	progress), June 2014.		progress), February 2015.
	[KAME-CGA]		[KAME-CGA]
	KAME, "The KAME IPR policy and concerns of some		KAME, "The KAME IPR policy and concerns of some
	technologies which have IPR claims", 2005,		technologies which have IPR claims", 2005,
	<http://www.kame.net/newsletter/20040525/>.		<http://www.kame.net/newsletter/20040525/>.
	[Microsoft]		[Microsoft]
	Microsoft, "IPv6 interface identifiers", 2013, <target='ht		Microsoft, "IPv6 interface identifiers", 2013, <target='ht
	tp://www.microsoft.com/resources/documentation/windows/xp/		tp://www.microsoft.com/resources/documentation/windows/xp/
	all/proddocs/en-us/sag_ip_v6_imp_addr7.mspx?mfr=true>.		all/proddocs/en-us/sag_ip_v6_imp_addr7.mspx?mfr=true>.
	[Panopticlick]		[Panopticlick]
	Electronic Frontier Foundation, "Panopticlick", 2011,		Electronic Frontier Foundation, "Panopticlick", 2011,
	<http://panopticlick.eff.org>.		<http://panopticlick.eff.org>.
	[RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J.,		[RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J.,
	Morris, J., Hansen, M., and R. Smith, "Privacy		Morris, J., Hansen, M., and R. Smith, "Privacy
	Considerations for Internet Protocols", RFC 6973,		Considerations for Internet Protocols", RFC 6973, July
	July 2013.		2013.
	[RFC7421] Carpenter, B., Chown, T., Gont, F., Jiang, S., Petrescu,		[RFC7421] Carpenter, B., Chown, T., Gont, F., Jiang, S., Petrescu,
	A., and A. Yourtchenko, "Analysis of the 64-bit Boundary		A., and A. Yourtchenko, "Analysis of the 64-bit Boundary
	in IPv6 Addressing", RFC 7421, January 2015.		in IPv6 Addressing", RFC 7421, January 2015.
	Authors' Addresses		Authors' Addresses
	Alissa Cooper		Alissa Cooper
	Cisco		Cisco
	707 Tasman Drive		707 Tasman Drive
End of changes. 16 change blocks.
	57 lines changed or deleted		63 lines changed or added
This html diff was produced by rfcdiff 1.42. The latest version is available from http://tools.ietf.org/tools/rfcdiff/