Internet DRAFT - draft-gont-6man-managing-slaac-policy
draft-gont-6man-managing-slaac-policy
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]