IPv6 maintenance Working Group (6man) F. Gont Internet-Draft UK CPNI Updates: 4861 (if approved) December 15, 2011 Intended status: Standards Track Expires: June 17, 2012 Managing the Address Generation Policy for Stateless Address Autoconfiguration in IPv6 draft-gont-6man-managing-slaac-policy-00 Abstract This document describes an operational problem that arises due to the impossibility of managing the address generation policy employed by hosts participating in IPv6 Stateless Address Autoconfiguration (SLAAC). Additionally, it specifies a new field in the Prefix Information option of Router Advertisement messages, such that routers can advertise, for each network prefix included in a Router Advertisement message, the desired address generation policy to be used for SLAAC. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. This document may not be modified, and derivative works of it may not be created, and it may not be published except as an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months 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." This Internet-Draft will expire on June 17, 2012. Copyright Notice Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents Gont Expires June 17, 2012 [Page 1]
Internet-Draft Managing the Address Generation Policy December 2011 (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Updating the Prefix Information option . . . . . . . . . . . . 5 3. Router specification . . . . . . . . . . . . . . . . . . . . . 7 3.1. Router configuration . . . . . . . . . . . . . . . . . . . 7 3.2. Router operation . . . . . . . . . . . . . . . . . . . . . 7 4. Host specification . . . . . . . . . . . . . . . . . . . . . . 8 4.1. Host configuration . . . . . . . . . . . . . . . . . . . . 8 4.2. Host Operation . . . . . . . . . . . . . . . . . . . . . . 8 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 6. Privacy Considerations . . . . . . . . . . . . . . . . . . . . 11 7. Security Considerations . . . . . . . . . . . . . . . . . . . 12 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 9.1. Normative References . . . . . . . . . . . . . . . . . . . 14 9.2. Informative References . . . . . . . . . . . . . . . . . . 14 Appendix A. Changes from previous versions of the document (to be removed by the RFC Editor before publication of this document as a RFC . . . . . . . . 16 A.1. Changes from draft-gont-6man-managing-privacy-extensions-01 . . . . . . 16 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 17 Gont Expires June 17, 2012 [Page 2]
Internet-Draft Managing the Address Generation Policy December 2011 1. Introduction [RFC4862] specifies the Stateless Address Autoconfiguration (SLAAC) for IPv6, which typically results in hosts configuring one or more addresses composed of a network prefix advertised by a local router, and an Interface Identifier (IID) that typically embeds a hardware address (using the Modified EUI-64 Format [RFC4291]. Since the identifiers (e.g. Ethernet MAC addresses) typically used for those addresses are usually globally unique, the IPv6 addresses generated as specified in [RFC4291] can be leveraged to track and correlate the activity of a node, thus negatively affecting the privacy of users. The "Privacy Extensions for Stateless Address Autoconfiguration in IPv6" [RFC4941] were introduced to difficult the task of eavesdroppers and other information collectors to correlate the activities of a node, and basically result in random Interface Identifiers that are typically more difficult to leverage than their Modified EUI-64 Format counterpart. Some flavor of these "Privacy Extensions" have been implemented in a variety of systems, some of which (notably Microsoft Windows Vista and Microsoft Windows 7) enable them by default. The impossibility of managing the address generation policy employed for SLAAC poses a problem when a site desires or requires a specific policy for the generation of IPv6 addresses. For example, some operating systems (notably FreeBSD) implement "Privacy Extensions", but do not enable them by default. And since there is currently no mechanism in IPv6 to convey the desired address-generation policy, administrators have no option other than manual configuration to enable such extensions. On the other hand, some implementations (notably Windows Vista and Windows 7) that enable "Privacy Extensions" by default might need to be deployed on sites that require the use of stable addresses (e.g. those resulting from Modified EUI-64 Format Identifiers [RFC4291]), for the ease of correlating network activities or enforcing simple access controls. However, since there is currently no mechanism to convey the desired address-generation policy for SLAAC, an administrator would need to manually-configure each of the attached nodes such that they employ the desired address generation policy. Depending on manual configuration for enabling a specific and homogeneous address-generation policy may result in a lot of work on the side of the administrator, but may also be difficult to implement, particularly when considering mobile nodes such as laptops and mobile phones [Broersma]. Additionally, the lack of a mechanism for conveying address-generation policy information might preclude Gont Expires June 17, 2012 [Page 3]
Internet-Draft Managing the Address Generation Policy December 2011 the use of some technologies, such as "Privacy Extensions" [RFC4941], which are desirable in most general environments (e.g., a typical home network, or an Internet cafe), but are currently only enabled as a result of manual configuration. This document specifies a new field in the Prefix Information option of Router Advertisement messages, such that routers can advertise, for each network prefix to be used for SLAAC, the desired policy for the generation of IPv6 addresses. The policy information is simply "advisory" information, in the sense that hosts still have the final word on which address generation policy they use. The aforementioned policy information basically indicates whether "stable" or "temporary" addresses are desired. We note that while the only address generation policies that have so far been standardized by the IETF are those based on e.g. IEEE identifiers and "Privacy Extensions for SLAAC", other address generation policies are possible. For example, [STABLE-PRIV] describes an address generation policy which results in interface identifiers that are stable for each prefix used for SLAAC, but that change from one autoconfiguration prefix to another. 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 RFC 2119 [RFC2119]. Gont Expires June 17, 2012 [Page 4]
Internet-Draft Managing the Address Generation Policy December 2011 2. Updating the Prefix Information option The syntax of the Prefix Information option is updated as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Prefix Length |L|A|R|AGP|Rsvd1| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Valid Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Preferred Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Prefix + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ An additional field, the two-bit "AGP" (Address Generation Policy) field, is specified for the Prefix Information option. The semantics of each of the possible values are: 00: No specific advice is provided for the generation of addresses for this prefix. 01: When generating addresses for this prefix, the resulting addresses SHOULD be stable (i.e., not temporary). The resulting stable addresses may be based on Modified EUI-64 Format Identifiers [RFC4291], the stable private identifiers proposed in [STABLE-PRIV], or any other address generation policy specified in the future which results in IPv6 addresses that are stable/ constant for that autoconfiguration prefix/subnet. 10: When generating addresses for this prefix, temporary addresses SHOULD be employed. The resulting addresses may be based on "Privacy Extensions for SLAAC" [RFC4941], or on any other policy which results in temporary Interface Identifiers. Address generation policies that result in stable addresses (such as those Gont Expires June 17, 2012 [Page 5]
Internet-Draft Managing the Address Generation Policy December 2011 specified in [RFC4941] and [STABLE-PRIV]) SHOULD NOT be used for this prefix. 11: Unused (reserved for future use). The special value "11" is reserved for future extensions, and MUST NOT be set by routers implementing this specification. Hosts that implement this specification MUST interpret the special value "11" in the same way as "00" (i.e., no specific advice is provided for address generation). Note: The "R" bit was specified by [RFC3775]. The Rsvd1 field corresponds to the remaining reserved bits, and thus MUST be set to zero by the sender of this option, and ignored by the receiver. Since the "AGP" bits correspond to a previously "reserved" field, implementations that predate this specification should be setting the AGP field to "00" when sending the option, and ignoring the AGP bits upon receipt. Gont Expires June 17, 2012 [Page 6]
Internet-Draft Managing the Address Generation Policy December 2011 3. Router specification 3.1. Router configuration This section specifies a variable that routers implementing this specification MUST support: DesiredAddressPolicy: This variable specifies the desired address generation policy for IPv6 addresses resulting from SLAAC. As of this specification, possible values are: "Default", "TemporaryAddresses", and "StableAddresses". This variable SHOULD default to "Default". 3.2. Router operation A router sending a Prefix Information option MUST set the AGP bits according to the value of the variable DesiredAddressPolicy. The following table specifies which values must be used for the AGP field depending on the value of the DesiredAddressPolicy variable. +----------------------+-----------+ | DesiredAddressPolicy | AGP field | +----------------------+-----------+ | Default | 00 | +----------------------+-----------+ | StableAddresses | 01 | +----------------------+-----------+ | TemporaryAddresses | 10 | +----------------------+-----------+ Table 1: Correspondence between DesiredAddressPolicy and AGP bits Gont Expires June 17, 2012 [Page 7]
Internet-Draft Managing the Address Generation Policy December 2011 4. Host specification 4.1. Host configuration This section specifies two new variables that hosts implementing this specification MUST support: AddressPolicyConfiguration: This variable specifies whether the host should honor the advice conveyed in the AGP field of the received Prefix Information options. There are two possible values for this variable: "Enabled" and "Disabled". This variable SHOULD default to "Enabled". DefaultAddressPolicy: This variable specifies the default IPv6 address generation policy that will be employed if AddressPolicyConfiguration is set to "Disabled", or if "AddressPolicyConfiguration" is set to "Enabled" but the AGP field of the received Prefix Information option is set to "00" (i.e., no specific advice is provided for the generation of addresses for this prefix). As of this specification, possible values are "TemporaryAddresses" (e.g. for [RFC4941]) and "StableAddresses" (for [RFC4291] or [STABLE-PRIV]). This variable SHOULD default to "TemporaryAddresses". A host willing to ignore the advice of the router regarding which policy to use to generate IPv6 addresses MAY do so by setting AddressPolicyConfiguration to "Disabled". It should be noted that the aforementioned variables might have different granularities. For example, a host could specify a set of EnableAddressPolicy and DefaultAddressPolicy variables on a global basis, on a "per network interface type" basis, on a "per wireless network" basis, etc. 4.2. Host Operation When generating addresses for the prefix contained in a "Prefix Information Option", hosts implementing this specification MUST proceed as follows: o If AddressPolicyConfiguration is set to "Enabled", the host SHOULD employ only the policy specified by the AGP field when generating addresses for this prefix. If no specific advice is provided (i.e., the AGP field is set to "00"), the host SHOULD employ only the policy specified by the DefaultAddressPolicy variable when generating addresses for this prefix. Gont Expires June 17, 2012 [Page 8]
Internet-Draft Managing the Address Generation Policy December 2011 o If AddressPolicyConfiguration is Disabled, the host SHOULD employ only the policy specified by the DefaultAddressPolicy variable when generating addresses for this prefix. Gont Expires June 17, 2012 [Page 9]
Internet-Draft Managing the Address Generation Policy December 2011 5. IANA Considerations There are no IANA registries within this document. The RFC-Editor can remove this section before publication of this document as an RFC. Gont Expires June 17, 2012 [Page 10]
Internet-Draft Managing the Address Generation Policy December 2011 6. Privacy Considerations As discussed in [RFC4941], IPv6 addresses generated using the Modified EUI-64 Format Identifiers [RFC4291] allow tracking of nodes across networks, since the resulting Interface-ID is a globally- unique value that will remain constant across all networks that the node may connect to. As specified in Section 3 and Section 4 of this document, the default value for the AGP bits of a Prefix Information option is "01" (no specific advice is provided for the generation of addresses for this prefix), and the default address generation policy (DefaultAddressPolicy) for hosts is set to "TemporaryAddresses". This means that, unless the router or host default settings are overridden, the default settings resulting from this specification will enable the use of "temporary addresses" (such as those specified in [RFC4941]). Nevertheless, it should be noted that the mechanism specified in this document simply provides the means for a router to convey *advisory* information regarding the desired policy for generating IPv6 addresses when SLAAC is employed: this specification allows hosts to ignore the aforementioned advice when deemed appropriate (by setting AddressPolicyConfiguration to "Disabled"). For example, hosts very concerned with the privacy implications of using interface identifiers that remain constant across networks may set AddressPolicyConfiguration to "Disabled" and DefaultAddressPolicy to "TemporaryAddresses" when connecting to untrusted networks, such that Temporary Addresses (such as those specified in [RFC4941]) are always employed (despite the advice provided by the local router). Finally, we note that the value and effectiveness of some variants of Temporary Addresses (such as that specified in [RFC4941]) have been questioned in a number of studies [I-D.dupont-ipv6-rfc3041harmful] [Escudero] [CPNI-IPv6]. However, this document does not take a stance about their value and effectiveness. Gont Expires June 17, 2012 [Page 11]
Internet-Draft Managing the Address Generation Policy December 2011 7. Security Considerations An attacker could exploit the mechanism specified in this document to cause hosts in a given subnet to disable "Temporary Addresses", thus usually leading to the generation of Interface Identifiers that embed the underlying hardware address (e.g. using Modified EUI-64 Format Identifiers), instead. Thus, in such cases, the privacy of the victim hosts that would have enabled the Privacy Extensions could possibly be reduced. However, some considerations should be made about such possible attack. Firstly, such an attack would require from an attacker the same effort as any other Neighbor Discovery attack based on crafted Router Advertisement messages [RFC3756] [CPNI-IPv6], most of which would be far more interesting for an attacker than this possible attack vector. For example, a (possibly malicious) router could still cause a host to use Modified EUI-64 Format Identifiers if DHCPv6 [RFC3315] is required for address configuration, and the DHCPv6 server selects the IPv6 addresses to be leased to hosts based on e.g. the source link-layer address of the DHCP requests. Secondly, while the the only policy for generating stable IPv6 addresses that has so far been standardized by the IETF is that based on e.g. IEEE identifiers, there are other possible policies, such as that proposed in [STABLE-PRIV], that lead to stable addresses. That is, use of "stable" identifiers does not necessarily imply that such identifiers remain stable/constant across networks. In those cases in which the network itself is trusted, but users connected to the same network are not, the possible options for mitigating this and other attack vectors based on crafted Router Advertisement messages include the deployment of the so-called "Router Advertisement guard" mechanism [RFC6104], with the implementation guidelines described in [I-D.gont-v6ops-ra-guard-evasion]. Additionally, SEND (SEcure Neighbor Discovery) [RFC3971] could be potentially deployed to mitigate these and other Neighbor Discovery attacks. However, a number of issues (such as the requirement for Public Key Infrastructure) difficult the deployment of SEND in most general network scenarios [CPNI-IPv6]. Gont Expires June 17, 2012 [Page 12]
Internet-Draft Managing the Address Generation Policy December 2011 8. Acknowledgements The author would like to thank (in alphabetical order) Mikael Abrahamsson, Ran Atkinson, Brian Carpenter, Christian Huitema, Mark Smith, Mark Townsley, and James Woodyatt, for providing valuable comments on [I-D.gont-6man-managing-privacy-extensions], on which this document is based. Fernando Gont would like to thank CPNI (http://www.cpni.gov.uk) for their continued support. Gont Expires June 17, 2012 [Page 13]
Internet-Draft Managing the Address Generation Policy December 2011 9. References 9.1. Normative References [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004. [RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure Neighbor Discovery (SEND)", RFC 3971, March 2005. [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, February 2006. [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, September 2007. [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless Address Autoconfiguration", RFC 4862, September 2007. [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy Extensions for Stateless Address Autoconfiguration in IPv6", RFC 4941, September 2007. [RFC6104] Chown, T. and S. Venaas, "Rogue IPv6 Router Advertisement Problem Statement", RFC 6104, February 2011. 9.2. Informative References [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003. [RFC3756] Nikander, P., Kempf, J., and E. Nordmark, "IPv6 Neighbor Discovery (ND) Trust Models and Threats", RFC 3756, May 2004. [I-D.gont-v6ops-ra-guard-evasion] Gont, F. and U. CPNI, "IPv6 Router Advertisement Guard (RA-Guard) Evasion", draft-gont-v6ops-ra-guard-evasion-01 (work in progress), June 2011. Gont Expires June 17, 2012 [Page 14]
Internet-Draft Managing the Address Generation Policy December 2011 [I-D.gont-6man-managing-privacy-extensions] Gont, F. and R. Broersma, "Managing the Use of Privacy Extensions for Stateless Address Autoconfiguration in IPv6", draft-gont-6man-managing-privacy-extensions-01 (work in progress), March 2011. [I-D.dupont-ipv6-rfc3041harmful] Dupont, F. and P. Savola, "RFC 3041 Considered Harmful", draft-dupont-ipv6-rfc3041harmful-05 (work in progress), June 2004. [STABLE-PRIV] Gont, F., "A method for Generating Stable Privacy-Enhanced Addresses with IPv6 Stateless Address Autoconfiguration (SLAAC)", Work in Progress, December 2011, <http:// tools.ietf.org/html/ draft-gont-6man-stable-privacy-addresses>. [Broersma] Broersma, R., "IPv6 Everywhere: Living with a Fully IPv6- enabled environment", Australian IPv6 Summit 2010, Melbourne, VIC Australia, October 2010, <http://www.ipv6.org.au/summit/talks/Ron_Broersma.pdf>. [Escudero] Escudero, A., "PRIVACY EXTENSIONS FOR STATELESS ADDRESS AUTOCONFIGURATION IN IPV6 - "REQUIREMENTS FOR UNOBSERVABILITY", RVK02, Stockholm, 2002, <http://web.it.kth.se/~aep/PhD/docs/paper3-rvk2002.pdf>. [CPNI-IPv6] Gont, F., "Security Assessment of the Internet Protocol version 6 (IPv6)", UK Centre for the Protection of National Infrastructure, (available on request). Gont Expires June 17, 2012 [Page 15]
Internet-Draft Managing the Address Generation Policy December 2011 Appendix A. Changes from previous versions of the document (to be removed by the RFC Editor before publication of this document as a RFC A.1. Changes from draft-gont-6man-managing-privacy-extensions-01 o The address-generation policy information has been changed from "'Modified EUI-64' vs. 'Privacy Addresses'" to "'stable addresses' vs. 'temporary addresses'", thus noting that more than one possible policy exists for each category. o The appendix on possible alternative specifications for the AGP bits has been removed. o The document now focuses on a mechanism that would enable increased use of "temporary addresses" (such as "Privacy Extensions"). Gont Expires June 17, 2012 [Page 16]
Internet-Draft Managing the Address Generation Policy December 2011 Author's Address Fernando Gont UK CPNI Email: fgont@si6networks.com URI: http://www.cpni.gov.uk Gont Expires June 17, 2012 [Page 17]