draft-ietf-6man-rfc4941bis-07.txt   draft-ietf-6man-rfc4941bis-08.txt 
IPv6 Maintenance (6man) Working Group F. Gont IPv6 Maintenance (6man) Working Group F. Gont
Internet-Draft SI6 Networks / UTN-FRH Internet-Draft SI6 Networks / UTN-FRH
Obsoletes: rfc4941 (if approved) S. Krishnan Obsoletes: rfc4941 (if approved) S. Krishnan
Intended status: Standards Track Ericsson Research Intended status: Standards Track Ericsson Research
Expires: August 29, 2020 T. Narten Expires: September 28, 2020 T. Narten
IBM Corporation IBM Corporation
R. Draves R. Draves
Microsoft Research Microsoft Research
February 26, 2020 March 27, 2020
Privacy Extensions for Stateless Address Autoconfiguration in IPv6 Temporary Address Extensions for Stateless Address Autoconfiguration in
draft-ietf-6man-rfc4941bis-07 IPv6
draft-ietf-6man-rfc4941bis-08
Abstract Abstract
Nodes use IPv6 stateless address autoconfiguration to generate This document describes an extension that causes nodes to generate
addresses using a combination of locally available information and global scope addresses with randomized interface identifiers that
information advertised by routers. Addresses are formed by combining change over time. Changing global scope addresses over time limits
network prefixes with an interface identifier. This document the window of time during which eavesdroppers and other information
describes an extension that causes nodes to generate global scope collectors may trivially perform address-based network activity
addresses with randomized interface identifiers that change over correlation when the same address is employed for multiple
time. Changing global scope addresses over time makes it more transactions by the same node. Additionally, it reduces the window
difficult for eavesdroppers and other information collectors to of exposure of a node via an addresses that becomes revealed as a
identify when different addresses used in different transactions result of active communication. This document obsoletes RFC4941.
correspond to the same node. This document obsoletes RFC4941.
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 https://datatracker.ietf.org/drafts/current/. Drafts is at https://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 August 29, 2020. This Internet-Draft will expire on September 28, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2020 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
(https://trustee.ietf.org/license-info) in effect on the date of (https://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 2, line 38 skipping to change at page 2, line 38
3. Protocol Description . . . . . . . . . . . . . . . . . . . . 6 3. Protocol Description . . . . . . . . . . . . . . . . . . . . 6
3.1. Design Guidelines . . . . . . . . . . . . . . . . . . . . 6 3.1. Design Guidelines . . . . . . . . . . . . . . . . . . . . 6
3.2. Assumptions . . . . . . . . . . . . . . . . . . . . . . . 7 3.2. Assumptions . . . . . . . . . . . . . . . . . . . . . . . 7
3.3. Generation of Randomized Interface Identifiers . . . . . 8 3.3. Generation of Randomized Interface Identifiers . . . . . 8
3.3.1. Simple Randomized Interface Identifiers . . . . . . . 8 3.3.1. Simple Randomized Interface Identifiers . . . . . . . 8
3.3.2. Hash-based Generation of Randomized Interface 3.3.2. Hash-based Generation of Randomized Interface
Identifiers . . . . . . . . . . . . . . . . . . . . . 9 Identifiers . . . . . . . . . . . . . . . . . . . . . 9
3.4. Generating Temporary Addresses . . . . . . . . . . . . . 10 3.4. Generating Temporary Addresses . . . . . . . . . . . . . 10
3.5. Expiration of Temporary Addresses . . . . . . . . . . . . 12 3.5. Expiration of Temporary Addresses . . . . . . . . . . . . 12
3.6. Regeneration of Temporary Addresses . . . . . . . . . . . 12 3.6. Regeneration of Temporary Addresses . . . . . . . . . . . 12
3.7. Implementation Considerations . . . . . . . . . . . . . . 14 3.7. Implementation Considerations . . . . . . . . . . . . . . 13
3.8. Defined Constants . . . . . . . . . . . . . . . . . . . . 14 3.8. Defined Constants . . . . . . . . . . . . . . . . . . . . 14
4. Implications of Changing Interface Identifiers . . . . . . . 15 4. Implications of Changing Interface Identifiers . . . . . . . 15
5. Significant Changes from RFC4941 . . . . . . . . . . . . . . 16 5. Significant Changes from RFC4941 . . . . . . . . . . . . . . 15
6. Future Work . . . . . . . . . . . . . . . . . . . . . . . . . 16 6. Future Work . . . . . . . . . . . . . . . . . . . . . . . . . 16
7. Security Considerations . . . . . . . . . . . . . . . . . . . 17 7. Security Considerations . . . . . . . . . . . . . . . . . . . 17
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 18
9.1. Normative References . . . . . . . . . . . . . . . . . . 18 9.1. Normative References . . . . . . . . . . . . . . . . . . 18
9.2. Informative References . . . . . . . . . . . . . . . . . 19 9.2. Informative References . . . . . . . . . . . . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21
1. Introduction 1. Introduction
Stateless address autoconfiguration (SLAAC) [RFC4862] defines how an Stateless address autoconfiguration (SLAAC) [RFC4862] defines how an
IPv6 node generates addresses without the need for a Dynamic Host IPv6 node generates addresses without the need for a Dynamic Host
Configuration Protocol for IPv6 (DHCPv6) server. The security and Configuration Protocol for IPv6 (DHCPv6) server. The security and
privacy implications of such addresses have been discussed in great privacy implications of such addresses have been discussed in detail
detail in [RFC7721],[RFC7217], and RFC7707. This document specifies in [RFC7721],[RFC7217], and RFC7707. This document specifies an
an extension for SLAAC to generate temporary addresses, such that the extension for SLAAC to generate temporary addresses, that can help
aforementioned issues are mitigated. This is a revision of RFC4941, mitigate some of the aforementioned issues. This is a revision of
and formally obsoletes RFC4941. Section 5 describes the changes from RFC4941, and formally obsoletes RFC4941. Section 5 describes the
[RFC4941]. changes from [RFC4941].
The default address selection for IPv6 has been specified in The default address selection for IPv6 has been specified in
[RFC6724]. The determination as to whether to use stable versus [RFC6724]. The determination as to whether to use stable versus
temporary addresses can in some cases only be made by an application. temporary addresses can in some cases only be made by an application.
For example, some applications may always want to use temporary For example, some applications may always want to use temporary
addresses, while others may want to use them only in some addresses, while others may want to use them only in some
circumstances or not at all. An Application Programming Interface circumstances or not at all. An Application Programming Interface
(API) such as that specified in [RFC5014] can enable individual (API) such as that specified in [RFC5014] can enable individual
applications to indicate a preference for the use of temporary applications to indicate a preference for the use of temporary
addresses. addresses.
Section 2 provides background information on the issue. Section 3 Section 2 provides background information. Section 3 describes a
describes a procedure for generating temporary addresses. Section 4 procedure for generating temporary addresses. Section 4 discusses
discusses implications of changing interface identifiers (IIDs). implications of changing interface identifiers (IIDs). Section 5
Section 5 describes the changes from [RFC4941]. describes the changes from [RFC4941].
1.1. Terminology 1.1. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
The terms "public address", "stable address", "temporary address", The terms "public address", "stable address", "temporary address",
skipping to change at page 5, line 25 skipping to change at page 5, line 25
as the concern that this document addresses. Specifically, all nodes as the concern that this document addresses. Specifically, all nodes
within a home could be grouped together for the purposes of within a home could be grouped together for the purposes of
collecting information. If the network contains a very small number collecting information. If the network contains a very small number
of nodes, say, just one, changing just the interface identifier will of nodes, say, just one, changing just the interface identifier will
not enhance privacy, since the prefix serves as a constant not enhance privacy, since the prefix serves as a constant
identifier. identifier.
One of the requirements for correlating seemingly unrelated One of the requirements for correlating seemingly unrelated
activities is the use (and reuse) of an identifier that is activities is the use (and reuse) of an identifier that is
recognizable over time within different contexts. IP addresses recognizable over time within different contexts. IP addresses
provide one obvious example, but there are more. Many nodes also provide one obvious example, but there are more.
have DNS names associated with their addresses, in which case the DNS
name serves as a similar identifier. Although the DNS name
associated with an address is more work to obtain (it may require a
DNS query), the information is often readily available. In such
cases, changing the address on a machine over time would do little to
address the concerns raised in this document, unless the DNS name is
changed as well (see Section 4).
Web browsers and servers typically exchange "cookies" with each other For example, web browsers and servers typically exchange "cookies"
[RFC6265]. Cookies allow web servers to correlate a current activity with each other [RFC6265]. Cookies allow web servers to correlate a
with a previous activity. One common usage is to send back targeted current activity with a previous activity. One common usage is to
advertising to a user by using the cookie supplied by the browser to send back targeted advertising to a user by using the cookie supplied
identify what earlier queries had been made (e.g., for what type of by the browser to identify what earlier queries had been made (e.g.,
information). Based on the earlier queries, advertisements can be for what type of information). Based on the earlier queries,
targeted to match the (assumed) interests of the end-user. advertisements can be targeted to match the (assumed) interests of
the end-user.
The use of a constant identifier within an address is of special The use of a constant identifier within an address is of special
concern because addresses are a fundamental requirement of 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. Consequently, if a addresses in packet headers appear in the clear. Consequently, if a
mobile host (e.g., laptop) accessed the network from several mobile host (e.g., laptop) accessed the network from several
different locations, an eavesdropper might be able to track the different locations, an eavesdropper might be able to track the
movement of that mobile host from place to place, even if the upper movement of that mobile host from place to place, even if the upper
layer payloads were encrypted. layer payloads were encrypted.
Changing global scope addresses over time limits the time window over
which eavesdroppers and other information collectors may trivially
correlate network activity when the same address is employed for
multiple transactions by the same node. Additionally, it reduces the
window of exposure of a node via an address that gets revealed as a
result of active communication.
The security and privacy implications of IPv6 addresses are discussed The security and privacy implications of IPv6 addresses are discussed
in detail in [RFC7721], [RFC7707], and [RFC7217]. in detail in [RFC7721], [RFC7707], and [RFC7217].
Using temporary addresses alone is not sufficient to prevent all
forms of tracking. It is however clear that temporary addresses are
useful to improve user privacy.
2.2. Possible Approaches 2.2. Possible Approaches
One approach, compatible with the stateless address autoconfiguration One approach, compatible with the stateless address autoconfiguration
architecture, would be to change the interface identifier portion of architecture, would be to change the interface identifier portion of
an address over time. Changing the interface identifier can make it an address over time. Changing the interface identifier can make it
more difficult to look at the IP addresses in independent more difficult to look at the IP addresses in independent
transactions and identify which ones actually correspond to the same transactions and identify which ones actually correspond to the same
node, both in the case where the routing prefix portion of an address node, both in the case where the routing prefix portion of an address
changes and when it does not. changes and when it does not.
skipping to change at page 15, line 38 skipping to change at page 15, line 34
networks on which multicast is expensive (e.g. networks on which multicast is expensive (e.g.
[I-D.ietf-mboned-ieee802-mcast-problems]). [I-D.ietf-mboned-ieee802-mcast-problems]).
The use of temporary addresses may cause unexpected difficulties with The use of temporary addresses may cause unexpected difficulties with
some applications. For example, some servers refuse to accept some applications. For example, some servers refuse to accept
communications from clients for which they cannot map the IP address communications from clients for which they cannot map the IP address
into a DNS name. That is, they perform a DNS PTR query to determine into a DNS name. That is, they perform a DNS PTR query to determine
the DNS name, and may then also perform an AAAA query on the returned the DNS name, and may then also perform an AAAA query on the returned
name to verify that the returned DNS name maps back into the address name to verify that the returned DNS name maps back into the address
being used. Consequently, clients not properly registered in the DNS being used. Consequently, clients not properly registered in the DNS
may be unable to access some services. As noted earlier, however, a may be unable to access some services. However, a node's DNS name
node's DNS name (if non-changing) serves as a constant identifier. (if non-changing) would serve as a constant identifier. The wide
The wide deployment of the extension described in this document could deployment of the extension described in this document could
challenge the practice of inverse-DNS-based "authentication," which challenge the practice of inverse-DNS-based "validation", which has
has little validity, though it is widely implemented. In order to little validity, though it is widely implemented. In order to meet
meet server challenges, nodes could register temporary addresses in server challenges, nodes could register temporary addresses in the
the DNS using random names (for example, a string version of the DNS using random names (for example, a string version of the random
random address itself). address itself), albeit at the expense of increased complexity.
In addition, some applications may not behave robustly if temporary In addition, some applications may not behave robustly if temporary
addresses are used and an address expires before the application has addresses are used and an address expires before the application has
terminated, or if it opens multiple sessions, but expects them to all terminated, or if it opens multiple sessions, but expects them to all
use the same addresses. use the same addresses.
5. Significant Changes from RFC4941 5. Significant Changes from RFC4941
This section summarizes the changes in this document relative to RFC This section summarizes the changes in this document relative to RFC
4941 that an implementer of RFC 4941 should be aware of. 4941 that an implementer of RFC 4941 should be aware of.
skipping to change at page 16, line 25 skipping to change at page 16, line 20
multiple prefixes (see [RAID2015] and [RFC7721] for further multiple prefixes (see [RAID2015] and [RFC7721] for further
details). details).
o Allows hosts to employ only temporary addresses: o Allows hosts to employ only temporary addresses:
[RFC4941] assumed that temporary addresses were configured in [RFC4941] assumed that temporary addresses were configured in
addition to stable addresses. This document does not imply or addition to stable addresses. This document does not imply or
require the configuration of stable addresses, and thus require the configuration of stable addresses, and thus
implementations can now configure both stable and temporary implementations can now configure both stable and temporary
addresses, or temporary addresses only. addresses, or temporary addresses only.
o Recommends that temporary addresses be enabled by default: o Removes the recommendation that temporary addresses be disabled by
Enabling temporary addresses by default is in line with BCP188 default:
([RFC7258]), and also with BCP204 ([RFC7934]). This is in line with BCP188 ([RFC7258]), and also with BCP204
([RFC7934]).
o Reduces the default Valid Lifetime for temporary addresses: o Reduces the default Valid Lifetime for temporary addresses:
The default Valid Lifetime for temporary addresses has been The default Valid Lifetime for temporary addresses has been
reduced from 1 week to 2 days, decreasing the typical number of reduced from 1 week to 2 days, decreasing the typical number of
concurrent temporary addresses from 7 to 2. This reduces the concurrent temporary addresses from 7 to 2. This reduces the
possible stress on network elements (see Section 4 for further possible stress on network elements (see Section 4 for further
details). details).
o Addresses all errata submitted for [RFC4941]. o Addresses all errata submitted for [RFC4941].
skipping to change at page 17, line 9 skipping to change at page 17, line 9
information is available in control blocks. For UDP-based information is available in control blocks. For UDP-based
applications, it may be the case that only the applications have applications, it may be the case that only the applications have
knowledge about what addresses are actually in use. Consequently, an knowledge about what addresses are actually in use. Consequently, an
implementation generally will need to use heuristics in deciding when implementation generally will need to use heuristics in deciding when
an address is no longer in use. an address is no longer in use.
7. Security Considerations 7. Security Considerations
If a very small number of nodes (say, only one) use a given prefix If a very small number of nodes (say, only one) use a given prefix
for extended periods of time, just changing the interface identifier for extended periods of time, just changing the interface identifier
part of the address may not be sufficient to address-based network part of the address may not be sufficient to mitigate address-based
activity correlation, since the prefix acts as a constant identifier. network activity correlation, since the prefix acts as a constant
The procedures described in this document are most effective when the identifier. The procedures described in this document are most
prefix is reasonably non static or is used by a fairly large number effective when the prefix is reasonably non static or is used by a
of nodes. fairly large number of nodes. Additionally, if a temporary address
is used in a session where the user authenticates, any notion of
"privacy" for that address is compromised.
While this document discusses ways of obscuring a user's IP address, While this document discusses ways of obscuring a user's IP address,
the method described is believed to be ineffective against the method described is believed to be ineffective against
sophisticated forms of traffic analysis. To increase effectiveness, sophisticated forms of traffic analysis. To increase effectiveness,
one may need to consider the use of more advanced techniques, such as one may need to consider the use of more advanced techniques, such as
Onion Routing [ONION]. Onion Routing [ONION].
Ingress filtering has been and is being deployed as a means of Ingress filtering has been and is being deployed as a means of
preventing the use of spoofed source addresses in Distributed Denial preventing the use of spoofed source addresses in Distributed Denial
of Service (DDoS) attacks. In a network with a large number of of Service (DDoS) attacks. In a network with a large number of
 End of changes. 16 change blocks. 
62 lines changed or deleted 62 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/