Internet DRAFT - draft-gont-v6ops-slaac-issues-with-duplicate-macs
draft-gont-v6ops-slaac-issues-with-duplicate-macs
IPv6 Operations Working Group (v6ops) F. Gont
Internet-Draft Huawei Technologies
Intended status: Informational October 15, 2012
Expires: April 18, 2013
Interoperability Problems of StateLess Address Auto-Configuration
(SLAAC) Arising from Duplicate Link-layer Addresses
draft-gont-v6ops-slaac-issues-with-duplicate-macs-00
Abstract
Traditional Stateless Address Auto-Configuration (SLAAC) typically
involves producing a Modified-EU64 format identifier to be employed
as the Interface-ID of the resulting address. In the case of
Ethernet network interface cards, such identifier derived from the
corresponding IEEE 802 address. IEEE 802 addresses are generally
expected to be globally unique, thus resulting in non-duplicate
addresses. However, in many real-world scenarios, these identifiers
fail to be unique, thus resulting in duplicate IPv6 addresses. This
document discusses the interoperability problems arising from
duplicate IEEE 802 addresses with IPv6 Stateless Address Auto-
Configuration (SLAAC), and how some popular implementations react
when the such problems arise. Finally, it discusses possible
mitigations for the aforementioned issue.
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 April 18, 2013.
Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the
Gont Expires April 18, 2013 [Page 1]
Internet-Draft VPN traffic leakages October 2012
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(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. Duplicate IEEE 802 addresses in the real world . . . . . . . . 4
3. IEEE-derived Modified EUI-64 format identifiers . . . . . . . 5
4. Duplicate Address Detection (DAD) implementations . . . . . . 6
5. Mitigations to the problem of SLAAC failures due to
duplicate IEEE 802 addresses . . . . . . . . . . . . . . . . . 7
5.1. Implementing some DAD-failure recovery algorithm . . . . . 7
5.2. Replacing Modified EUI-64 format identifiers based on
IEEE 802 addresses . . . . . . . . . . . . . . . . . . . . 7
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
7. Security Considerations . . . . . . . . . . . . . . . . . . . 9
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
9.1. Normative References . . . . . . . . . . . . . . . . . . . 11
9.2. Informative References . . . . . . . . . . . . . . . . . . 11
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 12
Gont Expires April 18, 2013 [Page 2]
Internet-Draft VPN traffic leakages October 2012
1. Introduction
IPv6 Stateless Address Auto-Configuration (SLAAC) [RFC4862] for
Ethernet network interface cards typically involves generating a
Modified EUI64 format identifier derived from the IEEE 802 address of
the underlying in network interface card. Such Modified EUI-64
format identifier is then employed as the Interface-ID part of the
resulting IPv6 address. Since the IEEE 802 addresses are generally
expected to be globally-unique, the aforementioned algorithm is
expected to result in unique addresses.
In any case, in order to prevent two systems from configuring the
same address on the same network segment, [RFC4862] specifies a
mechanism called "Duplicate Address Detection" (DAD), which employs
Neighbor Solicitation and Neighbor Advertisement messages to detect
whether a candidate IPv6 address is already in use on the local
network. DAD is meant only to *detect* an address conflict: it is up
to the implementation what to do if/once such a conflict is detected
-- and the current SLAAC specification [RFC4862] essentially leaves
possible algorithms to resolve the aforementioned DAD failure
unspecified.
In practice, virtually all implementation do not employ any algorithm
for resolving duplicate address conflicts, and therefore such event
leads to a failure of IPv6 stateless address configuration.
Section 2 discusses the occurrence of duplicate IEEE 802 addresses in
some detail. Section 3 analyzes the pros and cons of generating
Modified EUI-64 format identifiers by essentially embedding a IEEE
802 address in the aforementioned identifier. Section 4 provides
some details regarding how different implementations behave in the
presence of DAD failures. Finally, Section 5 discusses possible
mitigations for the aforementioned issue.
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 April 18, 2013 [Page 3]
Internet-Draft VPN traffic leakages October 2012
2. Duplicate IEEE 802 addresses in the real world
IEEE 802 addresses are, in principle, not necessarily unique: the U/L
bit the in the IEEE Organizational Unique Identifier (OUI) implies,
when clear, a globally-unique IEEE 802 address, but indicates a non-
unique ("local") address when set. However, most products ship with
IEEE 802 addresses that have the U/L bit set, thus implying globally-
unique IEEE 802 addresses.
However, in practice, even if when the U/L bit is clear, the
corresponding IEEE 802 address might be non-unique. There are a
number of reasons for which duplicate IEEE 802 addresses might exist
in a given network:
o Some vendors have been found to simply "reuse" IEEE 802 addreses
o Virtualization technologies, such as VirtualBox, essentially
select IEEE 802 addresses randomly, from a specific IEEE OUI
[VirtualBox]. This means that it is possible for two virtual
machines to end up employing the same IEEE 802 address for their
respective virtual interfaces.
Besides any assessment of whether duplicate IEEE 802 addresses are
the product of poor engineering choices or not, truth is that
deployed systems might already be employing duplicate addresses, and
hence it is desirable that such scenarios are gracefully handled.
Gont Expires April 18, 2013 [Page 4]
Internet-Draft VPN traffic leakages October 2012
3. IEEE-derived Modified EUI-64 format identifiers
One might argue that the only motivation for producing Modified
EUI-64 format identifiers as specified in [RFC2464] are:
o In theory, it is a simple algorithm to produce globally-unique
Modified EUI-64 format identifiers.
o Until recently, it was the only algorithm to produce stable
Interface-IDs that had so far been standardized.
The privacy extensions specified in [RFC4941] are meant to be
employed *in addition* to traditional SLAAC addresses, while
[I-D.ietf-6man-stable-privacy-addresses] is a recent
standardization effort.
Given that IEEE 802 addresses have been found to fail the uniqueness
criteria assumed above, IEEE-derived Modified EUI-64 format
identifiers will also fail the same uniqueness criteria.
Additionally, IEEE-derived identifiers have been found to result in
addresses that are trivial to scan
[I-D.gont-opsec-ipv6-host-scanning], and that negatively affect the
privacy of users [I-D.ietf-6man-stable-privacy-addresses] [RFC4941].
While it is true producing modified EUI64 format identifiers is the
only scheme that has so far been fully standardized, there is ongoing
work at the 6man wg to standardize an alternative scheme for
producing stable modified EUI-64 format identifiers, which does not
suffer from any of the drawbacks of modified EUI-64 format
identifiers based on IEEE-identifiers.
At lest discussions in IETF circles seem to indicate that the
drawbacks of modified EUI-64 format identifiers based on IEEE-
identifiers are well-understood, and that there seems to be agreement
that "they should be replaced with some alternative scheme".
Gont Expires April 18, 2013 [Page 5]
Internet-Draft VPN traffic leakages October 2012
4. Duplicate Address Detection (DAD) implementations
Different IPv6 stacks differ in some DAD implementations details,
and, most importantly, on how they handle DAD failures. For example,
different IPv6 stacks may send a different number of DAD probes
before DAD is considered to have succeeded. Additionally, they
typically differ on how they handle DAD failures. For example, in
the Linux IPv6 stack, if DAD fails for a link-local address, it
results in a "permanent" SLAAC failure that requires the admin to
reboot the system in order for SLAAC to be re-attempted. On the
other hand, DAD failure for non-link-local addresses is more of a
"soft failure", and hence SLAAC might succeed some time later when a
new Router Advertisement message that triggers SLAAC is received.
Gont Expires April 18, 2013 [Page 6]
Internet-Draft VPN traffic leakages October 2012
5. Mitigations to the problem of SLAAC failures due to duplicate IEEE
802 addresses
5.1. Implementing some DAD-failure recovery algorithm
One simple algorithm to resolve DAD failures could be such that, in
the event of such failures, simply generates a new IPv6 tentative
address by incrementing the Interface-ID of the tentative IPv6
address that previously failed DAD.
5.2. Replacing Modified EUI-64 format identifiers based on IEEE 802
addresses
A different approach to solve the problems arising from DAD failures
would be to realize that there are a number of factors that make
modified EUI64 format identifiers based on IEEE 802 addresses
undesirable, and hence recommend the implementation of
[I-D.ietf-6man-stable-privacy-addresses] in replacement of the IEEE-
derived modified EUI-64 format identifiers.
Gont Expires April 18, 2013 [Page 7]
Internet-Draft VPN traffic leakages October 2012
6. IANA Considerations
This document has no actions for IANA.
Gont Expires April 18, 2013 [Page 8]
Internet-Draft VPN traffic leakages October 2012
7. Security Considerations
This document discusses an interoperability problem that may arise as
a result of employing duplicate IEEE 802 addresses in the same
network segment. Failure to gracefully handle DAD failures may allow
an attacker to perform a Denial of Service attack against the victim
implementation.
Such attacks could be readily performed with packet-crafting tools
such as [SI6-Toolkit] and [THC-IPv6].
A more resilient approach might be to perform DAD for some maximum
number of tentative IPv6 addresses, and to not perform DAD at all for
the last of those address.
Obviously, this might lead to undesirable results if such "last"
address was a real duplicate of an address currently in use at the
local network.
In any case, as noted earlier in this document, IEEE-derived modified
EUI64 format identifiers have undesirable properties in the areas of
host tracking and host privacy, and hence the interoperability
problem discussed in this document could be considered as yet another
reason to replace such identifiers with some alternative scheme, such
as that specified in [I-D.ietf-6man-stable-privacy-addresses]
Gont Expires April 18, 2013 [Page 9]
Internet-Draft VPN traffic leakages October 2012
8. Acknowledgements
This documents has benefited from the input of a number of people in
a discussion of this topic on the v6ops wg mailing-list [V6OPS-LIST].
Gont Expires April 18, 2013 [Page 10]
Internet-Draft VPN traffic leakages October 2012
9. References
9.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet
Networks", RFC 2464, December 1998.
[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.
9.2. Informative References
[I-D.ietf-6man-stable-privacy-addresses]
Gont, F., "A method for Generating Stable Privacy-Enhanced
Addresses with IPv6 Stateless Address Autoconfiguration
(SLAAC)", draft-ietf-6man-stable-privacy-addresses-01
(work in progress), October 2012.
[I-D.gont-opsec-ipv6-host-scanning]
Gont, F., "Network Reconnaissance in IPv6 Networks",
draft-gont-opsec-ipv6-host-scanning-01 (work in progress),
July 2012.
[VirtualBox]
VirtualBox, "Oracle VM VirtualBox User Manual, version
4.1.2", August 2011, <http://www.virtualbox.org>.
[V6OPS-LIST]
"V6OPS WG mailing-list",
https://www.ietf.org/mailman/listinfo/v6ops.
[SI6-Toolkit]
"SI6 Networks' IPv6 toolkit",
<http://www.si6networks.com/tools/ipv6toolkit>.
[THC-IPv6]
"The Hacker's Choice IPv6 Attack Toolkit",
<http://www.thc.org/thc-ipv6/>.
Gont Expires April 18, 2013 [Page 11]
Internet-Draft VPN traffic leakages October 2012
Author's Address
Fernando Gont
Huawei Technologies
Evaristo Carriego 2644
Haedo, Provincia de Buenos Aires 1706
Argentina
Phone: +54 11 4650 8472
Email: fgont@si6networks.com
URI: http://www.si6networks.com
Gont Expires April 18, 2013 [Page 12]
