<?xml version="1.0" encoding="US-ASCII"?>
<?rfc toc="yes"?>
<?rfc compact="yes"?>
<?rfc tocdepth="6"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc autobreaks="no"?>
<?rfc subcompact="no"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY rfc3315 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3315.xml">
<!ENTITY rfc5280 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5280.xml">
<!ENTITY rfc7258 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7258.xml">
<!ENTITY rfc7435 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7435.xml">
]>

<rfc category="info" docName="draft-li-dhc-secure-dhcpv6-deployment-03" ipr="trust200902">

<front>
  <title abbrev="secure DHCPv6 deployment">secure DHCPv6 deployment</title>

    <author fullname="Lishan Li" initials="L." surname="Li">
      <organization>Tsinghua University</organization>

      <address>
        <postal>
          <street/>

          <city>Beijing</city>

          <code>100084</code>

          <country>P.R.China</country>
        </postal>

        <phone>+86-15201441862</phone>

        <email>lilishan48@gmail.com</email>
      </address>
    </author>

	<author fullname="Yong Cui" initials="Y." surname="Cui">
      <organization>Tsinghua University</organization>

      <address>
        <postal>
          <street/>

          <city>Beijing</city>

          <code>100084</code>

          <country>P.R.China</country>
        </postal>

        <phone>+86-10-6260-3059</phone>

        <email>yong@csnet1.cs.tsinghua.edu.cn</email>
      </address>
    </author>
	
	<author fullname="Jianping Wu" initials="J." surname="Wu">
      <organization>Tsinghua University</organization>

      <address>
        <postal>
          <street/>

          <city>Beijing</city>

          <code>100084</code>

          <country>P.R.China</country>
        </postal>

        <phone>+86-10-6278-5983</phone>

        <email>jianping@cernet.edu.cn</email>
      </address>
    </author>
	
	<author fullname="Sheng Jiang" initials="S." surname="Jiang">
      <organization>Huawei Technologies Co., Ltd</organization>

      <address>
        <postal>
          <street>Q14, Huawei Campus, No.156 Beiqing Road</street>

          <city>Hai-Dian District, Beijing, 100095</city>

          <country>CN</country>
        </postal>

        <email>jiangsheng@huawei.com</email>
      </address>
    </author>	
  <date year="2016"/>

  <workgroup>DHC Working Group</workgroup>

  <abstract>
    <t>Secure DHCPv6 provides authentication and encryption mechanisms 
	for DHCPv6. This draft analyses DHCPv6 threat model and provides 
	guideline for secure DHCPv6 deployment.</t>
  </abstract>                                                                     
</front>

<middle>
    <section title="Introduction">
	  <t>The Dynamic Host Configuration Protocol for IPv6 <xref target="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 <xref target="I-D.ietf-dhc-sedhcpv6"/> provides
	  authentication and encryption mechanisms for DHCPv6.</t>
	
	  <t>This document analyses DHCPv6 threat model and provides some 
	  guideline for secure DHCPv6 deployment. For secure DHCPv6 deployment,
	  we mainly consider two different scenarios: roaming client with loose
      security policy and static client with strict security policy.</t>
    </section>
	
	<section title="DHCPv6 Threat Model">	
	  <t>DHCPv6 privacy consideration <xref target="I-D.ietf-dhc-dhcpv6-privacy"/>
	  analyses the privacy problem for DHCPv6, listing the various DHCPv6 
	  options containing the privacy information and the possible attacks 
	  to DHCPv6.</t>
	
	  <t>Most of the privacy considerations for DHCPv6 focus on the client 
	  privacy protection. As the public service infrastructures, the privacy 
	  protection of the DHCPv6 server and relay agent is less important.</t> 
	
	  <t>The attack specific to a DHCPv6 client is the possibility of the 
      injection attack, MitM attack, spoofing attack. 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. <xref target="RFC7258"/> claims that pervasive monitoring 
	  should be mitigated in the design of IETF protocols, where possible.</t>
	  
	  <t>For the static clients, such as the devices in enterprise network,
	  they are always assumed to connect to exactly one network. The static 
	  client can be easily pre-configured with the certificates of the local 
	  DHCPv6 servers. According to the pre-configured information, the static 
	  client can detect the spoofing attack. The typical attack is MitM attack.
	  An intruder connects to the network and uses DHCP spoofing to install 
	  itself as a MitM. Because of the MitM attack, the client's privacy 
	  information may be modified or gleaned by the MitM. For the roaming 
	  clients, the typical attack is spoofing attack. Because of the rogue 
	  server which masquerades as valid server, the client is configured 
	  with the incorrect configuration information.</t>

	  <t>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.</t>
	</section>
			
	<section title="Secure DHCPv6 Mechanism Deployment">
		<section title="Secure DHCPv6 Overview">
	      <t>Secure DHCPv6 <xref target="I-D.ietf-dhc-sedhcpv6"/> provides the 
	      authentication and encryption mechanisms for DHCPv6. The Information-request 
		  and Reply messages are exchanged to achieve DHCPv6 server authentication. 
		  Then the DHCPv6 client authentication is achieved through the first 
		  encrypted DHCPv6 message sent from the client to the server, which contains 
		  the client's certificate information. Once the mutual authentication, the 
		  subsequent DHCPv6 messages are all encrypted with the recipient's public 
		  key.</t>		
		
		  <t>DHCPv6 server authentication protects the DHCPv6 client from injection 
		  attack, spoofing attack, and MitM attack. DHCPv6 client authentication 
		  protects the DHCPv6 server from Dos attack. DHCPv6 encryption protects 
		  DHCPv6 from passive attack, such as pervasive monitoring.</t>
		</section>
		
		<section title="Secure DHCPv6 Deployment Difficulties">
		  <t>Because of DHCPv6's specific property, the deployment of Secure DHCPv6 
		  mechanism is faced with some specific difficulties. The DHCPv6 server
		  is always assumed to be pre-configured with the trusted clients' certificates
		  or the trusted CAs' certificates to verify the clients' identity. The difficulty 
		  of Secure DHCPv6 deployment is that it is hard for the client to verify the 
		  server's identity without access to the network. According to the client's 
		  capability and security requirement, different schemes for secure DHCPv6 
		  deployment are applied.</t>		
		</section>
		
		<section title="Roaming Client with Loose Security Policy">
	      <t>In the scenario where the DHCPv6 clients are roaming and have loose 
          security requirement, opportunistic security plays a role. Opportunistic 
		  security provides DHCPv6 encryption even when the mutual authentication 
		  is not available. Based on the roaming client's capability, the DHCPv6 
		  configuration process is either authenticated and encrypted, or 
		  non-authenticated and encrypted.</t> 

		  <t>If the client is pre-configured with the trusted servers' certificates
		  or the trusted CAs' certificates, it has the capability to achieve server 
		  authentication. If the client is pre-configured with its own CA-signed 
		  certificate, it sends the CA-signed certificate to the DHCPv6 server for 
		  client authentication. When the client has been pre-configured with these
          certificate information, the DHCPv6 configuration process is authenticated 
		  and encrypted, which protects the DHCPv6 transaction from passive and 
		  active attacks.</t> 
		
		  <t>If the client is not pre-configured with these certificate information, 
		  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 CA-signed certificate. 
		  For the DHCPv6 encryption, after the mutual public key communication 
		  process, the DHCPv6 message is encrypted with the recipient's public 
		  key.</t>
	    </section>
		
		<section title="Static Client with Strict Security Policy">
		  <t>In the scenario where the DHCPv6 clients are static and have strict 
		  security requirement, the PKI plays a role. Then the default security 
		  policy is that DHCPv6 configuration communication must be authenticated 
		  and encrypted. The static clients, such as the desktop in enterprise 
		  network, are pre-configured with the trusted servers' certificates or 
		  the trusted CAs' certificates which form the certificate path. Through 
		  the pre-configured information, the client has the capability to achieve
          server authentication locally according to the rule defined in <xref target="RFC5280"/>. 
		  For client authentication, the client sends the CA-signed certificate to 
		  the server for client authentication. For DHCPv6 encryption, the DHCPv6 
		  message is encrypted with the recipient's public key contained in the 
		  certificate.</t>
		
		  <t>In some scenarios, the roaming client may also have strict security 
		  requirement, such as the byod in enterprise network. Because of the 
		  strict security policy, the DHCPv6 configuration process is authenticated
		  and encrypted. Although the roaming client is not pre-configured with the 
		  certificates information, the trusted server's certificate and its own 
		  certificate can be obtained out of band, such as by scanning a QR code. 
		  Through the obtained certificate information, the DHCPv6 client and the 
		  DHCPv6 server can achieve the mutual authentication. And then the 
		  subsequent DHCPv6 messages are encrypted with the recipient's public 
		  key.</t>
		</section>
	</section>	
	
    <section title="Security Considerations">
      <t>Opportunistic encryption is used for secure DHCPv6 deployment in the 
	  scenario where the security policy is loose. Downgrade attacks cannot be 
	  avoided if nodes can accept the un-authenticated and encrypted DHCPv6 
	  configuration.</t>
    </section>
	
</middle>

<back>

  <references title="Normative References">
    <?rfc include="reference.I-D.ietf-dhc-sedhcpv6" ?>
	&rfc3315;
	&rfc5280;
	&rfc7435;
  </references>

  <references title="Informative References">
	<?rfc include='reference.RFC.7258'?>
	<?rfc include="reference.I-D.ietf-dhc-dhcpv6-privacy" ?>

  </references>
  
</back>
</rfc>

