secure DHCPv6 deployment
draft-li-dhc-secure-dhcpv6-deployment-02

Abstract

Secure DHCPv6 provides authentication and encryption mechanisms for DHCPv6. This draft analyses the DHCPv6 threat model and provides guideline for secure DHCPv6 deployment.

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 June 18, 2016.

Copyright Notice

Copyright (c) 2015 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
• 2. DHCPv6 threat model
• 3. Secure DHCPv6 mechanism deployment
• 3.1. Secure DHCPv6 Overview
• 3.2. Secure DHCPv6 Deployment Difficulties
• 3.3. Scenario with Loose Security Policy
• 3.4. Scenario with Strict Security Policy
• 4. Security Considerations
• 5. References
• 5.1. Normative References
• 5.2. Informative References
• Authors' Addresses

1. Introduction

The Dynamic Host Configuration Protocol for IPv6 [RFC3315] enables DHCPv6 servers to configure network parameters dynamically. Due to the unsecured nature of DHCPv6, the various critical identifiers in DHCPv6 are vulnerable to several types of attacks. Secure DHCPv6 [I-D.ietf-dhc-sedhcpv6] provides the authentication and encryption mechanisms for DHCPv6.

This document analyses the DHCPv6 threat model and provides some guideline for secure DHCPv6 deployment. For the secure DHCPv6 deployment, we mainly consider two different scenarios: public coffee room with loose security policy and enterprise network with strict security policy.

2. DHCPv6 threat model

DHCPv6 privacy consideration [I-D.ietf-dhc-dhcpv6-privacy] analyses the privacy problem for DHCPv6, listing the various DHCPv6 options containing the privacy information and the possible attack to the DHCPv6.

Most of the privacy considerations for DHCPv6 focus on the client privacy protection. As the public service infrastructures, the privacy protection of DHCPv6 server and relay agent is less important. The attack specific to a DHCPv6 client is the possibility of the injection attack, spoofing attack, and rogue server. Because of the above attacks, the client may be configured with the incorrect configuration information, such as invalid IPv6 address. In addition, the client is also faced up with passive attacks, such as pervasive monitoring. Pervasive monitoring may glean the privacy information of the IPv6 host, which is used to find location information, previously visited networks and so on. [RFC7258] claims that pervasive monitoring should be mitigated in the design of IETF protocols, where possible.

The attack specific to a DHCPv6 server is the possibility of "denial of service" (Dos) attack. Invalid clients may masquerade as valid clients to request IPv6 addresses continually. The attack may cause the exhaustion of valid IPv6 addresses, CPU and network bandwidth. In addition, it also causes problem for the maintenance and management of the large tables on the DHCPv6 servers.

3. Secure DHCPv6 mechanism deployment

3.1. Secure DHCPv6 Overview

Secure DHCPv6 [I-D.ietf-dhc-sedhcpv6] provides the authentication and encryption mechanisms for DHCPv6. The Information-request and Reply messages are exchanged to achieve the server authentication. Then the DHCPv6 client authentication is achieved through the first message sent from client to server, which contains the client's certificate information. Once the mutual authentication, the following DHCPv6 messages are all encrypted with the recipient's public key.

The DHCPv6 server authentication protects the DHCPv6 client from injection attack, spoofing attack, and rogue server. The DHCPv6 client authentication protects the DHCPv6 server from Dos attack. The DHCPv6 encryption protects the DHCPv6 from passive attack, such as pervasive monitoring.

3.2. Secure DHCPv6 Deployment Difficulties

Because of the DHCPv6's specific property, the deployment of secure DHCPv6 mechanism faces some specific difficulties. The DHCPv6 server is always assumed to have connectivity to authorized CA and able to verify the client's certificate. The difficulty of deployment is that it is hard for the client to obtain itself certificate signed by CA or verify the server's identity without access to the network. According to the different DHCPv6 security requirement and the client's pre-configured information, different schemes for secure DHCPv6 deployment are used.

3.3. Scenario with Loose Security Policy

In the scenario where the security policy is loose, such as public coffee room, the opportunistic security policy plays a role. Opportunistic security provides DHCPv6 encryption even when the mutual authentication is not available.

In such scenario, the client is mobile and connects to random networks. Based on the client's capability, the DHCPv6 configuration process is either authenticated and encrypted, or non-authenticated and encrypted.

When the client is pre-configured with the certificate signed by CA and the information for server's identity verification, it has the capability to achieve the DHCPv6 client and server authentication. The DHCPv6 configuration process is authenticated and encrypted, which protects the DHCPv6 transaction from passive and active attacks.

When the client is not pre-configured with the certificate signed by CA or the information for server's identify verification, the communication is non-authenticated and encrypted. Non-authenticated and encrypted communication is better than cleartext, which defends against pervasive monitoring and other passive attacks. Although the client is not capable of verifying the server's identity, the client can obtain the server's public key through the server's certificate. For the client authentication, the client can send the self-signed certificate to the server if the client is not configured with the certificate signed by CA. For the DHCPv6 encryption, after the mutual public key communication process, the DHCPv6 message is encrypted with the recipient's public key.

3.4. Scenario with Strict Security Policy

In the scenario where the security policy is strict, such as enterprise network, the local default security policy is that the DHCPv6 configuration communication must be authenticated and encrypted. Then the local security policy supersedes the opportunistic security policy. Besides, the client is always stable terminal device, which is pre-configured with the trusted servers' certificates or the trusted CA certificates which forms the certificate path. Through the pre-configured information, the client achieves the server authentication locally according to the rule defined in [RFC5280]. For the client authentication, the client sends the CA signed certificate to server for client authentication. For the DHCPv6 encryption, the DHCPv6 message is encrypted with the recipient's public key contained in the certificate.

For the byod in enterprise network, the device is not pre-configured with the server authentication information to verify the server's identity. In this case, the trusted server's certificate can be obtained out of band, such as QR code and other methods. Out of band method is also suitable for the public coffee shops where the DHCPv6 client has strict security requirement.

4. Security Considerations

Opportunistic encryption is used for the secure DHCPv6 deployment in the scenario where the security policy is loose. The DHCPv6 configuration process is non-authenticated but encryption if the client is not pre-configured with the trusted servers' certificates or trusted CAs' certificates. Downgrade attacks cannot be avoided if the client is set the local policy that the DHCPv6 configuration process must be authenticated and encrypted.

5. References

5.1. Normative References

5.2. Informative References

Authors' Addresses