--- 1/draft-ietf-ipv6-privacy-addrs-v2-00.txt 2006-02-05 00:03:07.000000000 +0100 +++ 2/draft-ietf-ipv6-privacy-addrs-v2-01.txt 2006-02-05 00:03:07.000000000 +0100 @@ -1,20 +1,21 @@ + IPv6 Working Group T. Narten Internet-Draft IBM Corporation -Expires: March 16, 2005 R. Draves +Expires: April 22, 2005 R. Draves Microsoft Research S. Krishnan Ericsson - September 15, 2004 + October 22, 2004 Privacy Extensions for Stateless Address Autoconfiguration in IPv6 - draft-ietf-ipv6-privacy-addrs-v2-00 + draft-ietf-ipv6-privacy-addrs-v2-01 Status of this Memo By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that @@ -25,97 +26,101 @@ 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." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. - This Internet-Draft will expire on March 16, 2005. + This Internet-Draft will expire on April 22, 2005. Copyright Notice Copyright (C) The Internet Society (2004). All Rights Reserved. Abstract Nodes use IPv6 stateless address autoconfiguration to generate - addresses without the necessity of a Dynamic Host Configuration - Protocol (DHCP) server. Addresses are formed by combining network - prefixes with an interface identifier. On interfaces that contain - embedded IEEE Identifiers, the interface identifier is typically - derived from it. On other interface types, the interface identifier - is generated through other means, for example, via random number - generation. This document describes an extension to IPv6 stateless - address autoconfiguration for interfaces whose interface identifier - is derived from an IEEE identifier. Use of the extension causes - nodes to generate global scope addresses from interface identifiers - that change over time, even in cases where the interface contains an - embedded IEEE identifier. Changing the interface identifier (and the - global scope addresses generated from it) over time makes it more - difficult for eavesdroppers and other information collectors to - identify when different addresses used in different transactions - actually correspond to the same node. + addresses using a combination of locally available information and + information advertised by routers. Addresses are formed by combining + network prefixes with an interface identifier. On interfaces that + contain embedded IEEE Identifiers, the interface identifier is + typically derived from it. On other interface types, the interface + identifier is generated through other means, for example, via random + number generation. This document describes an extension to IPv6 + stateless address autoconfiguration for interfaces whose interface + identifier is derived from an IEEE identifier. Use of the extension + causes nodes to generate global scope addresses from interface + identifiers that change over time, even in cases where the interface + contains an embedded IEEE identifier. Changing the interface + identifier (and the global scope addresses generated from it) over + time makes it more difficult for eavesdroppers and other information + collectors to identify when different addresses used in different + transactions actually correspond to the same node. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 - 1.1 Conventions used in this document . . . . . . . . . . . . 3 - 2. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 4 - 2.1 Extended Use of the Same Identifier . . . . . . . . . . . 4 - 2.2 Address Usage in IPv4 Today . . . . . . . . . . . . . . . 5 - 2.3 The Concern With IPv6 Addresses . . . . . . . . . . . . . 6 - 2.4 Possible Approaches . . . . . . . . . . . . . . . . . . . 7 - 3. Protocol Description . . . . . . . . . . . . . . . . . . . . . 9 - 3.1 Assumptions . . . . . . . . . . . . . . . . . . . . . . . 9 - 3.2 Generation Of Randomized Interface Identifiers . . . . . . 11 - 3.2.1 When Stable Storage Is Present . . . . . . . . . . . . 11 - 3.2.2 In The Absence of Stable Storage . . . . . . . . . . . 12 - 3.2.3 Alternate approaches . . . . . . . . . . . . . . . . . 13 - 3.3 Generating Temporary Addresses . . . . . . . . . . . . . . 13 + 1.1 Problem Statement . . . . . . . . . . . . . . . . . . . . 4 + 1.2 Conventions used in this document . . . . . . . . . . . . 4 + 2. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 5 + 2.1 Extended Use of the Same Identifier . . . . . . . . . . . 5 + 2.2 Address Usage in IPv4 Today . . . . . . . . . . . . . . . 6 + 2.3 The Concern With IPv6 Addresses . . . . . . . . . . . . . 7 + 2.4 Possible Approaches . . . . . . . . . . . . . . . . . . . 8 + 3. Protocol Description . . . . . . . . . . . . . . . . . . . . . 10 + 3.1 Assumptions . . . . . . . . . . . . . . . . . . . . . . . 10 + 3.2 Generation Of Randomized Interface Identifiers . . . . . . 12 + 3.2.1 When Stable Storage Is Present . . . . . . . . . . . . 12 + 3.2.2 In The Absence of Stable Storage . . . . . . . . . . . 13 + 3.2.3 Alternate approaches . . . . . . . . . . . . . . . . . 14 + 3.3 Generating Temporary Addresses . . . . . . . . . . . . . . 14 3.4 Expiration of Temporary Addresses . . . . . . . . . . . . 15 - 3.5 Regeneration of Randomized Interface Identifiers . . . . . 15 - 3.6 Deployment Considerations . . . . . . . . . . . . . . . . 16 - 4. Implications of Changing Interface Identifiers . . . . . . . . 18 - 5. Defined Constants . . . . . . . . . . . . . . . . . . . . . . 19 - 6. Future Work . . . . . . . . . . . . . . . . . . . . . . . . . 20 - 7. Significant Changes from RFC 3041 . . . . . . . . . . . . . . 21 - 8. Security Considerations . . . . . . . . . . . . . . . . . . . 22 - 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 23 - 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 23 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 24 - Intellectual Property and Copyright Statements . . . . . . . . 26 + 3.5 Regeneration of Randomized Interface Identifiers . . . . . 16 + 3.6 Deployment Considerations . . . . . . . . . . . . . . . . 17 + 4. Implications of Changing Interface Identifiers . . . . . . . . 19 + 5. Defined Constants . . . . . . . . . . . . . . . . . . . . . . 20 + 6. Future Work . . . . . . . . . . . . . . . . . . . . . . . . . 21 + 7. Significant Changes from RFC 3041 . . . . . . . . . . . . . . 22 + 8. Changes from version 00 . . . . . . . . . . . . . . . . . . . 23 + 9. Security Considerations . . . . . . . . . . . . . . . . . . . 24 + 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 25 + 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 26 + 11.1 Normative References . . . . . . . . . . . . . . . . . . . . 26 + 11.2 Informative References . . . . . . . . . . . . . . . . . . . 26 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 27 + Intellectual Property and Copyright Statements . . . . . . . . 29 1. Introduction Stateless address autoconfiguration [ADDRCONF] defines how an IPv6 - node generates addresses without the need for a DHCP server. Some + node generates addresses without the need for a DHCPv6 server. Some types of network interfaces come with an embedded IEEE Identifier (i.e., a link-layer MAC address), and in those cases stateless address autoconfiguration uses the IEEE identifier to generate a 64- bit interface identifier [ADDRARCH]. By design, the interface identifier is likely to be globally unique when generated in this fashion. The interface identifier is in turn appended to a prefix to form a 128-bit IPv6 address. All nodes combine interface identifiers (whether derived from an IEEE identifier or generated through some other technique) with the reserved link-local prefix to generate link-local addresses for their attached interfaces. Additional addresses can then be created by combining prefixes advertised in Router Advertisements via Neighbor Discovery [DISCOVERY] with the interface identifier. Not all nodes and interfaces contain IEEE identifiers. In such cases, an interface identifier is generated through some other means - (e.g., at random), and the resultant interface identifier is not + (e.g., at random), and the resultant interface identifier may not be globally unique and may also change over time. The focus of this document is on addresses derived from IEEE identifiers, as the concern being addressed exists only in those cases where the interface identifier is globally unique and non-changing. The rest of this document assumes that IEEE identifiers are being used, but the techniques described may also apply to interfaces with other types of globally unique and/or persistent identifiers. This document discusses concerns associated with the embedding of non-changing interface identifiers within IPv6 addresses and @@ -123,21 +128,48 @@ help mitigate those concerns for individual users and in environments where such concerns are significant. Section 2 provides background information on the issue. Section 3 describes a procedure for generating alternate interface identifiers and global scope addresses. Section 4 discusses implications of changing interface identifiers. The term "global scope addresses" is used in this document to collectively refer to "Global unicast addresses" as defined in [ADDRARCH] and "Unique local addresses" as defined in [ULA] -1.1 Conventions used in this document +1.1 Problem Statement + + Addresses generated using Stateless address autoconfiguration + [ADDRCONF]contain an embedded 64-bit interface identifier, which + remains constant over time. Anytime a fixed identifier is used in + multiple contexts, it becomes possible to correlate seemingly + unrelated activity using this identifier. + + The correlation can be performed by + o An attacker who is in the path between the node in question and + the peer(s) it is communicating to, and can view the IPv6 + addresses present in the datagrams. + o An attacker who can access the communication logs of the peers + with which the node has communicated. + + Since the identifier is embedded within the IPv6 address, which is a + fundamental requirement of communication, it cannot be easily hidden. + This document proposes a solution to this issue by generating + interface identifiers which vary over time. + + Please note that an attacker, who is on path, may be able to perform + significant correlation based on + o The payload contents of the packets on the wire + o The characteristics of the packets such as packet size and timing + Use of temporary addresses will not prevent such payload based + correlation + +1.2 Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 2. Background This section discusses the problem in more detail, provides context for evaluating the significance of the concerns in specific environments and makes comparisons with existing practices. @@ -147,21 +179,33 @@ The use of a non-changing interface identifier to form addresses is a specific instance of the more general case where a constant identifier is reused over an extended period of time and in multiple independent activities. Anytime the same identifier is used in multiple contexts, it becomes possible for that identifier to be used to correlate seemingly unrelated activity. For example, a network sniffer placed strategically on a link across which all traffic to/ from a particular host crosses could keep track of which destinations a node communicated with and at what times. Such information can in some cases be used to infer things, such as what hours an employee - was active, when someone is at home, etc. + was active, when someone is at home, etc. Although it might appear + that changing an address regularly in such environments would be + desirable to lessen privacy concerns, it should be noted that the + network prefix portion of an address also serves as a constant + identifier. All nodes at (say) a home, would have the same network + prefix, which identifies the topological location of those nodes. + This has implications for privacy, though not at the same granularity + as the concern that this document addresses. Specifically, all nodes + within a home could be grouped together for the purposes of + collecting information. If the network contains a very small number + of nodes, say just one, changing just the interface identifier will + not enhance privacy at all, since the prefix serves as a constant + identifier. One of the requirements for correlating seemingly unrelated activities is the use (and reuse) of an identifier that is recognizable over time within different contexts. IP addresses provide one obvious example, but there are more. Many nodes also 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 @@ -182,57 +226,45 @@ other parties. Even when higher layers encrypt their payloads, addresses in packet headers appear in the clear. Consequently, if a mobile host (e.g., laptop) accessed the network from several different locations, an eavesdropper might be able to track the movement of that mobile host from place to place, even if the upper layer payloads were encrypted. 2.2 Address Usage in IPv4 Today Addresses used in today's Internet are often non-changing in practice - for extended periods of time, especially in non-home environments - (e.g., corporations, campuses, etc.). In such sites, addresses are - assigned statically and typically change infrequently. Over the last - few years, sites have begun moving away from static allocation to - dynamic allocation via DHCP [DHCP]. In theory, the address a client - gets via DHCP can change over time, but in practice servers often - return the same address to the same client (unless addresses are in - such short supply that they are reused immediately by a different - node when they become free). Thus, even within sites using DHCP, - clients frequently end up using the same address for weeks to months - at a time. + for extended periods of time. In an increasing number of sites, + addresses are assigned statically and typically change infrequently. + Over the last few years, sites have begun moving away from static + allocation to dynamic allocation via DHCP [DHCP]. In theory, the + address a client gets via DHCP can change over time, but in practice + servers often return the same address to the same client (unless + addresses are in such short supply that they are reused immediately + by a different node when they become free). Thus, even within sites + using DHCP, clients frequently end up using the same address for + weeks to months at a time. For home users accessing the Internet over dialup lines, the situation is generally different. Such users do not have permanent connections and are often assigned temporary addresses each time they connect to their ISP (e.g., AOL). Consequently, the addresses they use change frequently over time and are shared among a number of different users. Thus, an address does not reliably identify a particular device over time spans of more than a few minutes. A more interesting case concerns always-on connections (e.g., cable modems, ISDN, DSL, etc.) that result in a home site using the same address for extended periods of time. This is a scenario that is just starting to become common in IPv4 and promises to become more of a concern as always-on internet connectivity becomes widely - available. Although it might appear that changing an address - regularly in such environments would be desirable to lessen privacy - concerns, it should be noted that the network prefix portion of an - address also serves as a constant identifier. All nodes at (say) a - home, would have the same network prefix, which identifies the - topological location of those nodes. This has implications for - privacy, though not at the same granularity as the concern that this - document addresses. Specifically, all nodes within a home would be - grouped together for the purposes of collecting information. This - issue is difficult to address, because the routing prefix part of an - address contains topology information and cannot contain arbitrary - values. + available. Finally, it should be noted that nodes that need a (non-changing) DNS name generally have static addresses assigned to them to simplify the configuration of DNS servers. Although Dynamic DNS [DDNS] can be used to update the DNS dynamically, it is not yet widely deployed. In addition, changing an address but keeping the same DNS name does not really address the underlying concern, since the DNS name becomes a non-changing identifier. Servers generally require a DNS name (so clients can connect to them), and clients often do as well (e.g., some servers refuse to speak to a client whose address cannot be @@ -254,22 +286,21 @@ user's address could contain an interface identifier that remains the same from one dialup session to the next, even if the rest of the address changes. The way PPP is used today, however, PPP servers typically unilaterally inform the client what address they are to use (i.e., the client doesn't generate one on its own). This practice, if continued in IPv6, would avoid the concerns that are the focus of this document. A more troubling case concerns mobile devices (e.g., laptops, PDAs, etc.) that move topologically within the Internet. Whenever they - move (in the absence of technology such as mobile IP [MOBILEIP]), - they form new addresses for their current topological point of + move they form new addresses for their current topological point of attachment. This is typified today by the "road warrior" who has Internet connectivity both at home and at the office. While the node's address changes as it moves, however, the interface identifier contained within the address remains the same (when derived from an IEEE Identifier). In such cases, the interface identifier can be used to track the movement and usage of a particular machine. For example, a server that logs usage information together with a source addresses, is also recording the interface identifier since it is embedded within an address. Consequently, any data-mining technique that correlates activity based on addresses could easily be extended @@ -283,23 +314,30 @@ In summary, IPv6 addresses on a given interface generated via Stateless Autoconfiguration contain the same interface identifier, regardless of where within the Internet the device connects. This facilitates the tracking of individual devices (and thus potentially users). The purpose of this document is to define mechanisms that eliminate this issue, in those situations where it is a concern. 2.4 Possible Approaches - One way to avoid some of the problems discussed above is to use DHCP - for obtaining addresses. With DHCP, the DHCP server could arrange to - hand out addresses that change over time. + One way to avoid some of the problems discussed above is to use + DHCPv6 [DHCPV6] for obtaining addresses. The DHCPv6 server could be + configured to hand out addresses that change over time. But DHCPv6 + will solve the privacy issue only if it frequently handed out + constantly changing addresses to the nodes. Since this does not + happen automatically, and is difficult to configure manually, DHCPv6 + is not a self contained alternative for solving the privacy issues + addressed by this document. However, in the absence of stateless + address autoconfiguration, DHCPv6 can be used for distributing + temporary addresses to clients. Another approach, compatible with the stateless address autoconfiguration architecture, would be to change the interface id portion of an address over time and generate new addresses from the interface identifier for some address scopes. Changing the interface identifier can make it more difficult to look at the IP addresses in independent transactions and identify which ones actually correspond to the same node, both in the case where the routing prefix portion of an address changes and when it does not. @@ -366,61 +404,69 @@ multicast groups a host must join. Nodes join the solicited-node multicast address for each unicast address they support, and solicited-node addresses are dependent only on the low-order bits of the corresponding address. This default behaviour was made to address the concern that a node that joins a large number of multicast groups may be required to put its interface into promiscuous mode, resulting in possible reduced performance. A node highly concerned about privacy MAY use different interface identifiers on different prefixes, resulting in a set of global - addresses that cannot be easily tied to each other. This may be - useful, for example, to a mobile node using multiple wireless - interfaces to connect to multiple independent networks. + addresses that cannot be easily tied to each other. For example + a node MAY create different interface identifiers I1,I2, and I3 + for use with different prefixes P1,P2, and P3 on the same + interface. 3.1 Assumptions The following algorithm assumes that each interface maintains an associated randomized interface identifier. When temporary addresses are generated, the current value of the associated randomized interface identifier is used. The actual value of the identifier changes over time as described below, but the same identifier can be used to generate more than one temporary address. The algorithm also assumes that for a given temporary address, an - implementation can determine the corresponding public address from - which it was generated. When a temporary address is deprecated, a - new temporary address is generated. The specific valid and preferred - lifetimes for the new address are dependent on the corresponding - lifetime values in the public address. + implementation can determine the prefix from which it was generated. + When a temporary address is deprecated, a new temporary address is + generated. The specific valid and preferred lifetimes for the new + address are dependent on the corresponding lifetime values set for + the prefix from which it was generated. Finally, this document assumes that when a node initiates outgoing communication, temporary addresses can be given preference over - public addresses, when the device is configured to do so. This is - consistent with on-going work that addresses the topic of - source-address selection in the more general case [ADDR_SELECT] and - also means that all connections initiated by the node can use - temporary addresses without requiring application-specific - enablement. This document also assumes that an API will exist that - allows individual applications to indicate whether they prefer to use - temporary or public addresses and override the system defaults. + public addresses, when the device is configured to do so. + [ADDR_SELECT] mandates implementations to provide a mechanism, which + allows an application to configure its preference for temporary + addresses over public addresses. It also allows for an + implementation to prefer temporary addresses by default, so that the + connections initiated by the node can use temporary addresses without + requiring application-specific enablement. This document also + assumes that an API will exist that allows individual applications to + indicate whether they prefer to use temporary or public addresses and + override the system defaults. 3.2 Generation Of Randomized Interface Identifiers We describe two approaches for the generation and maintenance of the randomized interface identifier. The first assumes the presence of stable storage that can be used to record state history for use as input into the next iteration of the algorithm across system restarts. A second approach addresses the case where stable storage is unavailable and there is a need to generate randomized interface identifiers without previous state. + The random interface identifier generation algorithm, as described in + this document, uses MD5 as the hash algorithm. The node MAY use + another algorithm instead of MD5 to produce the random interface + identifier. + 3.2.1 When Stable Storage Is Present The following algorithm assumes the presence of a 64-bit "history value" that is used as input in generating a randomized interface identifier. The very first time the system boots (i.e., out-of-the- box), a random value SHOULD be generated using techniques that help ensure the initial value is hard to guess [RANDOM]. Whenever a new interface identifier is generated, a value generated by the computation is saved in the history value for the next iteration of the algorithm. @@ -487,140 +534,113 @@ vary from one machine to another), append some random data and compute the MD5 digest as before. 3.2.3 Alternate approaches Please note that there are other approaches to generate random interface identifiers, albeit with different goals and applicability. One such approach is CGA [CGA], which generates a random interface identifier based on the public key of the node. The goal of CGAs is to prove ownership of an address and to prevent spoofing and stealing - of existing IPv6 addresses. The CGA random interface identifier + of existing IPv6 addresses. They are used for securing neighbor + discovery using [SEND]. The CGA random interface identifier generation algorithm may not be suitable for privacy addresses because of the following properties o It requires the node to have a public key. This means that the node can still be identified by its public key o The random interface identifier process is computationally intensive and hence discourages frequent regeneration 3.3 Generating Temporary Addresses [ADDRCONF] describes the steps for generating a link-local address when an interface becomes enabled as well as the steps for generating addresses for other scopes. This document extends [ADDRCONF] as follows. When processing a Router Advertisement with a Prefix Information option carrying a global scope prefix for the purposes of address autoconfiguration (i.e., the A bit is set), the node MUST perform the following steps: 1. Process the Prefix Information Option as defined in [ADDRCONF], either creating a new public address or adjusting the lifetimes - of existing addresses, both public and temporary. When adjusting - the lifetime of an existing temporary address, there are two - cases to consider: - A. In some cases, the lifetimes in a received option will be - shorter than the lifetimes of an existing temporary addresses - derived from the prefix given in the option. This - corresponds to the case where the lifetimes have been - reconfigured by a system administrator to have a shorter - lifetime. Perform the following procedure to determine how - to update the lifetime of the temporary address: - B. - + If the received Valid Lifetime is greater than 2 hours - update the lifetime of the temporary address to the - received lifetime. - + If the RemainingLifetime of the temporary address is less - than or equal to 2 hours ignore the received option. - + Otherwise set the valid lifetime to 2 hours. - C. These steps are necessary to prevent a denial of service - attack where a bogus advertisement contains prefixes with - very small Valid Lifetimes - D. In many cases, the lifetime of a received option will extend - the lifetime of a public address. For example, a site might - advertise short lifetimes (on the order of hours or minutes) - that are effectively extended with each new RA. In such - cases, the lifetimes of temporary addresses should be - extended, subject to the overall constraint that no temporary - addresses should ever remain "valid" or "preferred" for a - time longer than (TEMP_VALID_LIFETIME-DESYNC_FACTOR) or + of existing addresses, both public and temporary. If a received + option will extend the lifetime of a public address, the + lifetimes of temporary addresses should be extended, subject to + the overall constraint that no temporary addresses should ever + remain "valid" or "preferred" for a time longer than + (TEMP_VALID_LIFETIME-DESYNC_FACTOR) or (TEMP_PREFERRED_LIFETIME-DESYNC_FACTOR) respectively. The configuration variables TEMP_VALID_LIFETIME and TEMP_PREFERRED_LIFETIME correspond to approximate target lifetimes for temporary addresses. - One way an implementation can satisfy the above constraints is to + 2. One way an implementation can satisfy the above constraints is to associate with each temporary address a creation time (called CREATION_TIME) that indicates the time at which the address was created. When updating the preferred lifetime of an existing temporary address, it would be set to expire at whichever time is earlier: the time indicated by the received lifetime or (CREATION_TIME + TEMP_PREFERRED_LIFETIME - DESYNC_FACTOR). A similar approach can be used with the valid lifetime. - 2. When a new public address is created as described in [ADDRCONF] + + 3. When a new public address is created as described in [ADDRCONF] (because the prefix advertised does not match the prefix of any address already assigned to the interface, and the Valid Lifetime in the option is not zero), the node SHOULD also create a new temporary address. - 3. When creating a temporary address, the lifetime values MUST be - derived from the corresponding public address as follows: + 4. When creating a temporary address, the lifetime values MUST be + derived from the corresponding prefix as follows: * Its Valid Lifetime is the lower of the Valid Lifetime of the public address or TEMP_VALID_LIFETIME * Its Preferred Lifetime is the lower of the Preferred Lifetime - of the public address or - TEMP_PREFERRED_LIFETIME-DESYNC_FACTOR. - 4. A temporary address is created only if this calculated Preferred + of the prefix or TEMP_PREFERRED_LIFETIME-DESYNC_FACTOR. + 5. A temporary address is created only if this calculated Preferred Lifetime is greater than REGEN_ADVANCE time units. In particular, an implementation MUST NOT create a temporary address with a zero Preferred Lifetime. - 5. New temporary addresses MUST be created by appending the + 6. New temporary addresses MUST be created by appending the interface's current randomized interface identifier to the prefix - that was used to generate the corresponding public address. - 6. The node MUST Perform duplicate address detection (DAD) on the + that was received. + 7. The node MUST Perform duplicate address detection (DAD) on the generated temporary address. If DAD indicates the address is already in use, the node MUST generate a new randomized interface identifier as described in Section 3.2 above, and repeat the - previous steps as appropriate up to 5 times. If after 5 - consecutive attempts no non-unique address was generated, the - node MUST log a system error and MUST NOT attempt to generate - temporary addresses for that interface. Note that DAD MUST be - performed on every unicast address generated from this randomized - interface identifier. + previous steps as appropriate up to TEMP_IDGEN_RETRIES times. If + after TEMP_IDGEN_RETRIES consecutive attempts no non-unique + address was generated, the node MUST log a system error and MUST + NOT attempt to generate temporary addresses for that interface. + Note that DAD MUST be performed on every unicast address + generated from this randomized interface identifier. 3.4 Expiration of Temporary Addresses When a temporary address becomes deprecated, a new one MUST be generated. This is done by repeating the actions described in Section 3.3, starting at step 3). Note that, except for the transient period when a temporary address is being regenerated, in - normal operation at most one temporary address corresponding to a - public address should be in a non-deprecated state at any given time. + normal operation at most one temporary address per prefix should be + in a non-deprecated state at any given time on a given interface. Note that if a temporary address becomes deprecated as result of processing a Prefix Information Option with a zero Preferred - Lifetime, then a new temporary address MUST NOT be generated. The - Prefix Information Option will also deprecate the corresponding - public address. To insure that a preferred temporary address is - always available, a new temporary address SHOULD be regenerated - slightly before its predecessor is deprecated. This is to allow - sufficient time to avoid race conditions in the case where generating - a new temporary address is not instantaneous, such as when duplicate - address detection must be run. The node SHOULD start the address - regeneration process REGEN_ADVANCE time units before a temporary - address would actually be deprecated. + Lifetime, then a new temporary address MUST NOT be generated.To + ensure that a preferred temporary address is always available, a new + temporary address SHOULD be regenerated slightly before its + predecessor is deprecated. This is to allow sufficient time to avoid + race conditions in the case where generating a new temporary address + is not instantaneous, such as when duplicate address detection must + be run. The node SHOULD start the address regeneration process + REGEN_ADVANCE time units before a temporary address would actually be + deprecated. As an optional optimization, an implementation MAY remove a deprecated temporary address that is not in use by applications or - upper-layers. For TCP connections, such information is available in - control blocks. For UDP-based applications, it may be the case that - only the applications have knowledge about what addresses are - actually in use. Consequently, one may need to use heuristics in - deciding when an address is no longer in use (e.g., the default - TEMP_VALID_LIFETIME suggested above). + upper-layers as detailed in Section 6 3.5 Regeneration of Randomized Interface Identifiers The frequency at which temporary addresses changes depends on how a device is being used (e.g., how frequently it initiates new communication) and the concerns of the end user. The most egregious privacy concerns appear to involve addresses used for long periods of time (weeks to months to years). The more frequently an address changes, the less feasible collecting or coordinating information keyed on interface identifiers becomes. Moreover, the cost of @@ -649,47 +669,59 @@ same time. When the preferred lifetime expires, a new temporary address MUST be generated using the new randomized interface identifier. Because the precise frequency at which it is appropriate to generate new addresses varies from one environment to another, implementations SHOULD provide end users with the ability to change the frequency at which addresses are regenerated. The default value is given in TEMP_PREFERRED_LIFETIME and is one day. In addition, the exact time at which to invalidate a temporary address depends on how - applications are used by end users. Thus, the default value given of - one week (TEMP_VALID_LIFETIME) may not be appropriate in all + applications are used by end users. Thus, the suggested default + value of one week (TEMP_VALID_LIFETIME) may not be appropriate in all environments. Implementations SHOULD provide end users with the ability to override both of these default values. Finally, when an interface connects to a new link, a new randomized interface identifier SHOULD be generated immediately together with a new set of temporary addresses. If a device moves from one ethernet to another, generating a new set of temporary addresses from a different randomized interface identifier ensures that the device uses different randomized interface identifiers for the temporary addresses associated with the two links, making it more difficult to correlate addresses from the two different links as being from the - same node. The process by which a node can determine whether a link - change has occurred is described by Detecting Network Attachment - [DNA] + same node. The node MAY follow any process available to it, to + determine that the link change has occurred. One such process is + described by Detecting Network Attachment [DNA] 3.6 Deployment Considerations Devices implementing this specification MUST provide a way for the end user to explicitly enable or disable the use of temporary addresses. In addition, a site might wish to disable the use of - temporary addresses in order to simply network debugging and + temporary addresses in order to simplify network debugging and operations. Consequently, implementations SHOULD provide a way for trusted system administrators to enable or disable the use of temporary addresses. + Additionally, sites might wish to selectively enable or disable the + use of temporary addresses for some prefixes. For example, a site + might wish to disable temporary address generation for "Unique local" + [ULA] prefixes while still generating temporary addresses for all + other global prefixes. Another site might wish to enable temporary + address generation only for the prefixes 2001::/16 and 2002::/16 + while disabling it for all other prefixes. To support this behavior, + implementations SHOULD provide a way to enable and disable generation + of temporary addresses for specific prefix subranges. This + per-prefix setting SHOULD override the global settings on the node + with respect to the specified prefix subranges. + The use of temporary addresses may cause unexpected difficulties with some applications. As described below, some servers refuse to accept communications from clients for which they cannot map the IP address into an DNS name. In addition, some applications may not behave robustly if temporary addresses are used and an address expires before the application has terminated, or if it opens multiple sessions, but expects them to all use the same addresses. Consequently, the use of temporary addresses SHOULD be disabled by default in order to minimize potential disruptions. Individual applications, which have specific knowledge about the normal duration @@ -730,21 +762,21 @@ The wide deployment of the extension described in this document could challenge the practice of inverse-DNS-based "authentication," which has little validity, though it is widely implemented. In order to meet server challenges, nodes could register temporary addresses in the DNS using random names (for example a string version of the random address itself). Use of the extensions defined in this document may complicate debugging and other operational troubleshooting activities. Consequently, it may be site policy that temporary addresses should - not be used. Consequently, implementations must provide a method for + not be used. Consequently, implementations MUST provide a method for the end user or trusted administrator to override the use of temporary addresses. 5. Defined Constants Constants defined in this document include: TEMP_VALID_LIFETIME -- Default value: 1 week. Users should be able to override the default value. @@ -753,46 +785,48 @@ REGEN_ADVANCE -- 5 seconds MAX_DESYNC_FACTOR -- 10 minutes. Upper bound on DESYNC_FACTOR. DESYNC_FACTOR -- A random value within the range 0 - MAX_DESYNC_FACTOR. It is computed once at system start (rather than each time it is used) and must never be greater than (TEMP_VALID_LIFETIME - REGEN_ADVANCE). + TEMP_IDGEN_RETRIES -- Default value: 3 + 6. Future Work An implementation might want to keep track of which addresses are being used by upper layers so as to be able to remove a deprecated temporary address from internal data structures once no upper layer protocols are using it (but not before). This is in contrast to current approaches where addresses are removed from an interface when they become invalid [ADDRCONF], independent of whether or not upper layer protocols are still using them. For TCP connections, such information is available in control blocks. For UDP-based applications, it may be the case that only the applications have knowledge about what addresses are actually in use. Consequently, an implementation generally will need to use heuristics in deciding when - an address is no longer in use (e.g., as is suggested in Section - 3.4). + an address is no longer in use. The determination as to whether to use public vs. temporary addresses can in some cases only be made by an application. For example, some applications may always want to use temporary addresses, while others may want to use them only in some circumstances or not at all. Suitable API extensions will likely need to be developed to enable individual applications to indicate with sufficient granularity their needs with regards to the use of temporary addresses. Recommendations on DNS practices to avoid the problem described in Section 4 when reverse DNS lookups fail may be - needed. + needed. [DNSOP] contains a more detailed discussion of the DNS + related issues. While this document discusses ways of obscuring a user's permanent IP address, the method described is believed to be ineffective against sophisticated forms of traffic analysis. To increase effectiveness, one may need to consider use of more advanced techniques, such as Onion Routing [ONION]. Open Issues 1) Implementations should allow system administrators to configure @@ -830,104 +864,136 @@ addresses as described in this document 7. Removed references to site-local addresses 8. Added a check for denial of service attacks using low valid lifetimes in router advertisements 9. Changed the document to use RFC2119 language 10. The node is now allowed to generate different interface identifiers for different prefixes, if it so desires. 11. DAD is now performed on all unicast addresses created from the same interface identifier instead of just the first one -8. Security Considerations +8. Changes from version 00 - Ingress filtering is being deployed as a means of preventing the use - of spoofed source addresses in Distributed Denial of Service(DDoS) - attacks. In a network with a large number of nodes, new temporary - addresses are created at a fairly high rate. This might make it - difficult for ingress filtering mechanisms to distinguish between - legitimately changing temporary addresses and spoofed source - addresses which "in-prefix"(They use a topologically correct prefix - and non-existent interface ID). This can be addressed by using - access control mechanisms on a per address basis on the network - egress point. + This section summarizes the changes from version 00 of this draft + 1. The algorithm used for generating random interface identifiers is + no longer restricted to just MD5 + 2. Added a problem statement + 3. Classified the references into normative and informative + 4. Reduced default number of retries to 3 from 5 and added a + configuration variable + 5. Removed text about RA processing which is duplicated from + [ADDRCONF] + 6. Added text about the privacy implications of a non-changing + prefix + 7. Added a per-prefix enable/disable setting + 8. Added text about the means of correlation + 9. Clarified text about DHCPv6 + 10. Added reference to dnsop issues draft -9. Acknowledgements +9. Security Considerations + + Ingress filtering has been and is being deployed as a means of + preventing the use of spoofed source addresses in Distributed Denial + of Service(DDoS) attacks. In a network with a large number of nodes, + new temporary addresses are created at a fairly high rate. This + might make it difficult for ingress filtering mechanisms to + distinguish between legitimately changing temporary addresses and + spoofed source addresses, which are "in-prefix"(They use a + topologically correct prefix and non-existent interface ID). This + can be addressed by using access control mechanisms on a per address + basis on the network egress point. + +10. Acknowledgements The authors would like to acknowledge the contributions of the ipv6 working group and, in particular, Ran Atkinson, Matt Crawford, Steve Deering, Allison Mankin, Peter Bieringer, Jari Arkko, Pekka Nikander, Pekka Savola, and Francis Dupont for their detailed comments. -10 References +11. References + +11.1 Normative References [ADDRARCH] - Hinden, R. and S. Deering, "IP Version 6 Addressing - Architecture", RFC 2373, July 1998. + Hinden, R. and S. Deering, "Internet Protocol Version 6 + (IPv6) Addressing Architecture", RFC 3513, April 2003. [ADDRCONF] - Thomson, S. and T. Narten, "IPv6 Stateless Address - Autoconfiguration", RFC 2462, December 1998. + Thomson, S., Narten, T. and T. Jinmei, "IPv6 Stateless + Address Autoconfiguration", draft-ietf-ipv6-rfc2462bis-06 + (work in progress), September 2004. [ADDR_SELECT] Draves, R., "Default Address Selection for Internet Protocol version 6 (IPv6)", RFC 3484, February 2003. + [DISCOVERY] + Narten, T., Nordmark, E., Simpson, W. and H. Soliman, + "Neighbor Discovery for IP version 6 (IPv6)", + draft-ietf-ipv6-2461bis-00 (work in progress), July 2004. + + [IPSEC] Kent, S. and R. Atkinson, "Security Architecture for the + Internet Protocol", RFC 2401, November 1998. + + [MD5] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, + April 1992. + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", RFC 2119, March 1997. + + [RFC2526] Johnson, D. and S. Deering, "Reserved IPv6 Subnet Anycast + Addresses", RFC 2526, March 1999. + +11.2 Informative References + [CGA] Aura, T., "Cryptographically Generated Addresses (CGA)", draft-ietf-send-cga-06 (work in progress), April 2004. [COOKIES] Kristol, D. and L. Montulli, "HTTP State Management Mechanism", RFC 2965, October 2000. [DDNS] Vixie, P., Thomson, S., Rekhter, Y. and J. Bound, "Dynamic Updates in the Domain Name System (DNS UPDATE)", RFC 2136, April 1997. [DHCP] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March 1997. - [DISCOVERY] - Narten, T., Nordmark, E. and W. Simpson, "Neighbor - Discovery for IP Version 6 (IPv6)", RFC 2461, December - 1998. + [DHCPV6] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C. and + M. Carney, "Dynamic Host Configuration Protocol for IPv6 + (DHCPv6)", RFC 3315, July 2003. [DNA] Choi, J. and G. Daley, "Detecting Network Attachment in IPv6 Goals", draft-ietf-dna-goals-01 (work in progress), September 2004. - [IPSEC] Kent, S. and R. Atkinson, "Security Architecture for the - Internet Protocol", RFC 2401, November 1998. + [DNSOP] Durand, A., Ihren, J. and P. Savola, "Operational + Considerations and Issues with IPv6 DNS", + draft-ietf-dnsop-ipv6-dns-issues-09 (work in progress), + August 2004. [ISATAP] Templin, F., Gleeson, T., Talwar, M. and D. Thaler, "Intra-Site Automatic Tunnel Addressing Protocol (ISATAP)", draft-ietf-ngtrans-isatap-22 (work in progress), May 2004. - [MD5] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, - April 1992. - - [MOBILEIP] - Perkins, C., "IP Mobility Support", RFC 2002, October - 1996. - [ONION] Reed, MGR., Syverson, PFS. and DMG. Goldschlag, "Proxies for Anonymous Routing", Proceedings of the 12th Annual Computer Security Applications Conference, San Diego, CA, December 1996. [RANDOM] Eastlake, D., Crocker, S. and J. Schiller, "Randomness Recommendations for Security", RFC 1750, December 1994. - [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate - Requirement Levels", RFC 2119, March 1997. - - [RFC2526] Johnson, D. and S. Deering, "Reserved IPv6 Subnet Anycast - Addresses", RFC 2526, March 1999. + [SEND] Arkko, J., Kempf, J., Sommerfeld, B., Zill, B. and P. + Nikander, "SEcure Neighbor Discovery (SEND)", + draft-ietf-send-ndopt-06 (work in progress), July 2004. [ULA] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast Addresses", draft-ietf-ipv6-unique-local-addr-05 (work in progress), June 2004. Authors' Addresses Thomas Narten IBM Corporation P.O. Box 12195