V6OPS B. Liu
Internet-Draft S. Jiang
Intended status: Informational Huawei Technologies
Expires: August 8, 2016 X. Gong
W. Wang
BUPT University
E. Rey
ERNW GmbH
February 5, 2016

DHCPv6/SLAAC Interaction Problems on Address and DNS Configuration
draft-ietf-v6ops-dhcpv6-slaac-problem-06

Abstract

The IPv6 Neighbor Discovery (ND) Protocol includes an ICMPv6 Router Advertisement (RA) message. The RA message contains three flags, indicating the availability of address auto-configuration mechanisms and other configuration such as DNS-related configuration. These are the M, O, and A flags, which by definition are advisory, not prescriptive.

This document describes divergent host behaviors observed in popular operating systems. It also discusses operational problems that the divergent behaviors might cause.

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

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 August 8, 2016.

Copyright Notice

Copyright (c) 2016 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 (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

IPv6 [RFC2460] hosts could invoke Neighbor Discovery (ND) [RFC4861] to to discover which auto-configuration mechanisms are available to them. There are two auto-configuration mechanisms in IPv6:

ICMPv6-based [RFC4443] Router Advertisement (RA) message. Routers periodically multicast the RA messages to all on-link nodes. They also unicast RA messages in response to solicitations. The RA message contains (but not limited to):

ND specifies an

The M and O flags are advisory, not prescriptive. For example, the M flag indicates that addresses are available from DHCPv6, but It does not indicate that hosts are required to acquire addresses from DHCPv6. Similar statements can be made about the O flag. (A flag is also advisory by definition in standard, but it is quite prescriptive in implementations according to the test results in the appendix.)

Because of the advisory definition of the flags, in some cases different operating systems appear divergent behaviors. This document analyzes possible divergent host behaviors might happen (most of the possible divergent behaviors are already observed in popular operating systems) and the operational problems might caused by divergent behaviors.

2. The M, O and A Flags

This section briefly reviews how the M, O and A flags are defined in ND[RFC4861] and SLAAC[RFC4862].

2.1. Flags Definition

2.2. Flags Relationship

Per [RFC4861], "If the M flag is set, the O flag is redundant and can be ignored because DHCPv6 will return all available configuration information.".

There is no explicit description of the relationship between A flag and the M/O flags.

3. Behavior Ambiguity Analysis

The ambiguity of the flags definition means that when interpreting the same messages, different hosts might behave differently. The ambiguity space is analyzed as the following aspects.

1) Dependency between DHCPv6 and RA

In standards, behavior of DHCPv6 and Neighbor Discovery protocols is specified respectively. But it is not clear that whether there should be any dependency between them. More specifically, it is unclear whether RA (with M=1) is required to trigger DHCPv6; in other words, It is unclear whether hosts should initiate DHCPv6 by themselves if there are no RAs at all.

2) Overlapping configuration between DHCPv6 and RA

When address and DNS configuration are both available from DHCPv6 and RA, it is not clear how to deal with the overlapping information. Should the hosts accept all the information? If the information conflicts, which one should take higher priority?
For DNS configuration, [RFC6106] clearly specifies "In the case where the DNS options of RDNSS and DNSSL can be obtained from multiple sources, such as RA and DHCP, the IPv6 host SHOULD keep some DNS options from all sources" and "the DNS information from DHCP takes precedence over that from RA for DNS queries" (Section 5.3.1 of [RFC6106]). But for address configuration, there's no such guidance.

3) Interpretation on Flags Transition

-
Impact on SLAAC/DHCPv6 on and off
-
Impact on address lifetime

4) Relationship between the Flags

As described above, the relationship between A flag and M/O flags is unspecified.
It could be reasonably deduced that M flag should be independent from A flag. In other words, the M flag only cares DHCPv6 address configuration, while the A flag only cares SLAAC.
But for A flag and O flag, ambiguity could possibly happen. For example, when A is FALSE (when M is also FALSE) and O is TRUE, it is not clear whether the host should initiate a stand-alone stateless DHCPv6 session.

Divergent behaviors on all these aspects have been observed among some popular operating systems as described in Section 4 below.

4. Observed Divergent Host Behaviors

The authors tested several popular operating systems in order to determine what behaviors the M, O and A flag elicit. In some cases, the M, O and A flags elicit divergent behaviors. The table below characterizes those cases. For test details, please refer to Appendix A.

Operation diverges in two ways: one is regarding to address auto-configuration; the other is regarding to DNS configuration.

4.1. Divergent Behavior on Address Auto-Configuration

Divergence 1-1

Divergence 1-2

Divergence 1-3

4.2. Divergent Behavior on DNS Configuration

Divergence 2-1

Divergence 2-2

(This divergence is only for those operations systems which support[RFC6106].)

Divergence 2-3

(This divergence is only for those operations systems which support[RFC6106].)

Divergence 2-4

(This divergence is only for those operations systems which support[RFC6106].)

5. Operational Problems

This section is not a full collection of the potential problems. It is some operational issues that the authors could see at current stage.

5.1. Standalone Stateless DHCPv6 Configuration not available

It is impossible for some hosts to acquire stateless DHCPv6 configuration unless addresses are acquired from either DHCPv6 or SLAAC (Which requires M flag or A flag is TURE).

5.2. Renumbering Issues

According to [RFC6879] a renumbering exercise can include the following steps:

Ideally, these steps could be initiated by multicasting RA messages onto the link that is being renumbered. Sadly, this is not possible, because the RA messages may elicit a different behavior from each host.

6. Security Considerations

An attacker, without having to install a rogue router, can install a rogue DHCPv6 server and provide IPv6 addresses to Windows 8.1 systems. This can allow her to interact with these systems in a different scope, which, for instance, is not monitored by an IDPS system.

If an attacker wants to perform MiTM (Man in The Middle) using a rogue DNS while legitimates RAs with the O flag set are sent to enforce the use of a DHCPv6 server, the attacker can spoof RAs with the same settings with the legitimate prefix (in order to remain undetectable) but advertising the attacker's DNS using RDNSS. In this case, Fedora 21, Centos 7 and Ubuntu 14.04 will use the rogue RDNSS (advertised by the RAs) as a first option.

Fedora 21 and Centos 7 behaviour cannot be explored for a MiTM attack using a rogue DNS information either, since the one obtained by the RAs of the first router has a higher priority.

The behaviour of Fedora 21, Centos 7 and Windows 7 can be exploited for DoS purposes. A rogue IPv6 router not only provides its own information to the clients, but it also removes the previous obtained (legitimate) information. The Fedora and Centos behaviour can also be exploited for MiTM purposes by advertising rogue RDNSS by RAs which include RDNSS information.

(Note: the security considerations for specific operating systems are based on the detailed test results as described in Appendix A.)

7. IANA Considerations

This draft does not request any IANA action.

8. Acknowledgements

The authors wish to acknowledge BNRC-BUPT (Broad Network Research Centre in Beijing University of Posts and Telecommunications) for their testing efforts. Special thanks to Xudong Shi, Longyun Yuan and Xiaojian Xue for their extraordinary effort.

Special thanks to Ron Bonica who made a lot of significant contribution to this draft, including draft editing and presentations which dramatically improved this work.

The authors also wish to acknowledge Brian E Carpenter, Ran Atkinson, Mikael Abrahamsson, Tatuya Jinmei, Mark Andrews and Mark Smith for their helpful comments.

9. References

9.1. Normative References

[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, December 1998.
[RFC4443] Conta, A., Deering, S. and M. Gupta, "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification", RFC 4443, DOI 10.17487/RFC4443, March 2006.
[RFC4861] Narten, T., Nordmark, E., Simpson, W. and H. Soliman, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, DOI 10.17487/RFC4861, September 2007.
[RFC4862] Thomson, S., Narten, T. and T. Jinmei, "IPv6 Stateless Address Autoconfiguration", RFC 4862, DOI 10.17487/RFC4862, September 2007.
[RFC6106] Jeong, J., Park, S., Beloeil, L. and S. Madanapalli, "IPv6 Router Advertisement Options for DNS Configuration", RFC 6106, DOI 10.17487/RFC6106, November 2010.

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, DOI 10.17487/RFC3315, July 2003.
[RFC3736] Droms, R., "Stateless Dynamic Host Configuration Protocol (DHCP) Service for IPv6", RFC 3736, DOI 10.17487/RFC3736, April 2004.
[RFC6879] Jiang, S., Liu, B. and B. Carpenter, "IPv6 Enterprise Network Renumbering Scenarios, Considerations, and Methods", RFC 6879, DOI 10.17487/RFC6879, February 2013.

Appendix A. Test Results

The authors from two orgnizations tested different scenarios independent of each other. The following text decribes the two test sets respectively.

A.1. Test Set 1

A.1.1. Test Environment

The test environment was replicated on a single server using VMware. For simplicity of operation, only one host was run at a time. Network elements were as follows:

A.1.2. Address Auto-configuration Behavior in the Initial State

The bullet list below describes host behavior in the initial state, when the host has not yet acquired any auto-configuration information. Each bullet item represents an input and the behavior elicited by that input.

As showed above, four inputs result in divergent behaviors.

A.1.3. Address Auto-configuration Behavior in State Transitions

The bullet list below describes behavior elicited during state transitions. The value x can represents both 0 and 1.

A.2. Test Set 2

A.2.1. Test Environment

This test was built on real devices. All the devices are located on the same link.

A.2.2. Address/DNS Auto-configuration Behavior of Using Only One IPv6 Router and a DHCPv6 Server

In these scenarios there is two one router and, unless otherwise specified, one DHCPv6 server on the same link. The behaviour of the router and of the DHCPv6 server remain unchanged during the tests.

Case 1: One Router with the Management Flag not Set and a DHCPv6 Server

Case 2: One Router with Conflicting Parameters and a DHCPv6 Server

Case 3: Same as Case 2 but Without a DHCPv6 Server

Case 4: All Flags are Set and a DHCPv6 Server is Present

Case 5: All Flags are Set and There is No DHCPv6 Server is Present

Case 6: A Prefix is Advertised by RAs but the 'A' flag is not Set

A.2.3. Address/DNS Auto-configuration Behavior of Using Two IPv6 Router and a DHCPv6 Server

these scenarios there are two routers on the same link. At first, only one router is present (resembling the "legitimate router)", while the second one joins the link after the clients first configured by the RAs of the first router. Our goal is to examine the behaviour of the clients during the interchange of the RAs from the two different routers.

Case 7: Router 1 Advertising M=0, O=0 and RDNSS, and then Router 2 advertising M=1, O=1 while DHCPv6 is Present

Case 8: (Router 2) Initially M=1, O=1 and DHCPv6, then 2nd Router (Router 1) Rogue RAs Using M=0, O=0 and RDNSS Provided

Authors' Addresses

Bing Liu Huawei Technologies Q14, Huawei Campus, No.156 Beiqing Road Hai-Dian District, Beijing, 100095, P.R. China EMail: leo.liubing@huawei.com
Sheng Jiang Huawei Technologies Q14, Huawei Campus, No.156 Beiqing Road Hai-Dian District, Beijing, 100095, P.R. China EMail: jiangsheng@huawei.com
Xiangyang Gong BUPT University No.3 Teaching Building Beijing University of Posts and Telecommunications (BUPT) No.10 Xi-Tu-Cheng Rd. Hai-Dian District, Beijing, P.R. China EMail: xygong@bupt.edu.cn
Wendong Wang BUPT University No.3 Teaching Building Beijing University of Posts and Telecommunications (BUPT) No.10 Xi-Tu-Cheng Rd. Hai-Dian District, Beijing, P.R. China EMail: wdwang@bupt.edu.cn
Enno Rey ERNW GmbH EMail: erey@ernw.de