[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits] [IPR]

Versions: 00 01 02 draft-ietf-dhc-cga-config-dhcpv6

Network Working Group                                     Sheng Jiang
Internet Draft                                        Sam(Zhongqi) Xia
Intended status: Standards Track          Huawei Technologies Co., Ltd
Expires: February 24, 2011                             August 24, 2010

  Configuring Cryptographically Generated Addresses (CGA) using DHCPv6
                draft-jiang-dhc-cga-config-dhcpv6-01.txt


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 February 24, 2011.

Copyright Notice

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












Jiang & Xia           Expires February 24, 2011               [Page 1]


Internet-Draft draft-jiang-dhc-cga-config-dhcpv6-01.txt     August 2010




Abstract

   A Cryptographically Generated Address is an IPv6 addresses binding
   with a public/private key pair. However, the current CGA
   specifications are lack of procedures to enable proper management of
   CGA generation. Administrators should be able to configure parameters
   used to generate CGA. The Dynamic Host Configuration Protocol for
   IPv6 (DHCPv6), which enables network management to dynamically
   configure hosts, can be used in the CGA configuration. This document
   defines the process using DHCPv6 to configure CGA in detail, include
   configuration CGA parameters and that a DHCPv6 server grants the CGA
   usage. Two new DHCPv6 options are defined accordingly.

Table of Contents

   1. Introduction................................................3
   2. Terminology.................................................3
   3. CGA Configure Process Using DHCPv6...........................3
      3.1. Configuration of the parameters required for the generation
      of CGA......................................................4
      3.2. Node requests CGA Approved to the DHCPv6 server..........5
   4. DHCPv6 CGA Sec Option........................................6
   5. DHCPv6 Address Grant Option..................................7
   6. Security Considerations......................................7
   7. IANA Considerations.........................................8
   8. Acknowledgments.............................................8
   9. References..................................................8
      9.1. Normative References....................................8
      9.2. Informative References..................................9
   Author's Addresses.............................................9
















Jiang & Xia           Expires February 24, 2011               [Page 2]


Internet-Draft draft-jiang-dhc-cga-config-dhcpv6-01.txt     August 2010




1. Introduction

   Cryptographically Generated Addresses (CGA, [RFC3972]) provide means
   to verify the ownership of IPv6 addresses without requiring any
   security infrastructure such as a certification authority.  The use
   of CGAs allows identity verification in different protocols, such as
   SEure Neighbor Discovery (SEND, [RFC3971]), Enhanced Route
   Optimization for MIPv6 [RFC4866] or Site Multihoming by IPv6
   Intermediation (SHIM6 [RFC5533]).

   However, as [I-D.ietf-csi-dhcpv6-cga-ps] analyses, in the current
   specifications, there is a lack of procedures to enable proper
   management of CGA generation, in particular, in the configuration of
   the parameters that define the security properties of the addresses.
   Administrators should be able to configure parameters used to
   generate CGA. The Dynamic Host Configuration Protocol for IPv6
   (DHCPv6), which enables network management to dynamically configure
   hosts, can be used in the CGA configuration. For example, DHCPv6
   server should be able to assign certain level of CGA Sec value or
   other relevant parameters to CGA address owner.

   This draft provides detailed solutions for CGA configuration. Two
   existing DHCPv6 options are re-used. Two new DHCPv6 options, CGA Sec
   Option and Address Grant Option, are also defined in this document.

2. Terminology

   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 RFC2119 [RFC2119].

3. CGA Configure Process Using DHCPv6

   The CGA specifications [RFC3972] define the procedure to generate a
   CGA. However, it assumes that hosts decide by itself or have been
   preconfigured all CGA relevant parameters. In reality, network
   management MAY want to assign/enforcement some parameters to hosts.

   Among the mechanisms in which configuration parameters could be
   pushed to the end hosts and/or CGA related information sent back to a
   central administration, we discuss the stateful configuration
   mechanism based on DCHPv6 in this document. Other mechanisms may also
   provide similar functions, but out of scope.




Jiang & Xia           Expires February 24, 2011               [Page 3]


Internet-Draft draft-jiang-dhc-cga-config-dhcpv6-01.txt     August 2010


   In this section, configuration CGA parameters and that a DHCPv6
   server grants the CGA usage are described in details.

3.1. Configuration of the parameters required for the generation of CGA

   Each CGA is associated with a CGA Parameters data structure, which is
   formed by all input parameters [RFC3972] except for Sec value that is
   embedded in the CGA. The CGA associated Parameters used to generate a
   CGA includes:

     - a Public Key,

     - a Subnet Prefix,

     - a 3-bit security parameter, Sec. Additionally, it should be noted
     that the hash algorithm to be used in the generation of the CGA is
     also defined by the Sec value [RFC4982],

     - any Extension Fields that could be used.

     - Note: the modifier and the Collision Count value in the CGA
     Parameter data structure are generated during the CGA generation
     process. They do NOT need to be configured.

   A node may initiate a request for the relevant CGA configuration
   information needed to the DHCPv6 server. The server responds with the
   configuration information for the node. The Option Request Option,
   defined in Section 22.7 in [RFC3315], can be used for node to
   indicate which options the client requests from the server. For
   response, the requested Option should be included. The server MAY
   also initiatively push these parameters by attaching these option in
   the response messages which are initiated for other purposes.

     The Public/Private key pair is generated by hosts themselves and
     considered not suitable for network transmission for security
     reasons. The configuration of the client key pair or certificate is
     out of scope.

     Currently, there are convenient mechanisms for allowing an
     administrator to configure the subnet prefix for a host, by Router
     Advertisement [RFC4861, RFC4862]. However, this does not suitable
     for the DHCP-managed network. To propagate the prefix through DHCP
     interactions, DHCPv6 Prefix Delegation Option [RFC3633] MAY be used.
     However, this option was designed to assign prefix block for
     routers. A new Prefix Assignment Option MAY need to be defined.
     Since alternative approach is existing and there are debates



Jiang & Xia           Expires February 24, 2011               [Page 4]


Internet-Draft draft-jiang-dhc-cga-config-dhcpv6-01.txt     August 2010


     whether a new Prefix Assignment Option MAY is necessary, this
     document does not define it.

     A new DHCPv6 CGA Sec Option is defined in Section 4.

     Although there is an optional Extension Fields in CGA Parameter
     data structure, there is NO any defined extension fields. Future
     specification may define more options to carry CGA-related
     configuration parameters.

   Upon reception of the CGA relevant parameters from DHCPv6 server, the
   end hosts SHOULD generate addresses compliant with the received
   parameters. If the parameters change, the end hosts SHOULD generate
   new addresses compliant with the parameters propagated.

3.2. Node requests CGA Approved to the DHCPv6 server

   A CGA address is generated by the associated key pair owner, normally
   an end host. However, in a DHCPv6-managed network, hosts should use
   IPv6 global addresses only from a DHCPv6 server. The process
   described below allows a host, also DHCPv6 client, uses self-
   generated CGAs in a DHCPv6-managed environment, by requesting the
   granting from a DHCPv6 server.

   The client sends a CGA, which is generated by itself, to a DHCPv6
   server, and requests the DHCP server to determine whether the
   generated CGA satisfies the requirements of the network configuration,
   wherein the network configuration comprises a CGA security level set
   by the DHCP; and generates a new CGA if the generated CGA does not
   satisfy the requirements of the network configuration.

   Client initiation behavior

   In details, a DHCPv6 client SHOULD send a DHCPv6 Request message to
   initiate the CGA granting process.

   This DHCPv6 Request message MUST include an Option Request option,
   which requests Address Grant Option, defined in Section 5 in this
   document, to indicate the DHCPv6 server responses with the address
   granting decision. The Addr_Grant field in the embedded Address Grant
   Option should be set 0.

   The client MUST include one or more IA Options, either IA_NA or IA_TA,
   in the Request message. Each IA Option MUST include one or more IA
   Address Options. CGAs are carried in the IA Address Options.

   Server behavior


Jiang & Xia           Expires February 24, 2011               [Page 5]


Internet-Draft draft-jiang-dhc-cga-config-dhcpv6-01.txt     August 2010


   Upon reception of the Request message, the DHCPv6 server SHOULD
   verify whether the client's CGAs satisfy the CGA-related
   configuration parameters of the network. The DHCPv6 server then send
   an acknowledgement, a Reply message, to the client to either grant
   the use of the CGA or to indicate that the node must generate a new
   CGA with the correct CGA-related configuration parameters of the
   network. The Addr_Grant field sets 1 indicating that the requested
   address is granted; The Addr_Grant field sets 2 indicating that the
   requested address is declined, defined in Section 5 in this document.
   When the requested CGA is declined, the DHCPv6 server may attach CGA-
   relevant parameters in the Reply message to indicate the client
   generates a new CGA accordingly.

   In the meantime, the DHCPv6 server MAY log the requested CGA
   addresses. This information MAY later be used by other network
   functions, such as ACL.

   Client receiving behavior

   Upon reception of the acknowledgement from server, the client can
   legally use the granted CGAs. If the server declines the requested
   CGA, the client MUST generate a new CGA. If the server replies with
   CGA-relevant parameters, the client SHOULD generate a new CGA
   accordingly.

4. DHCPv6 CGA Sec Option

   DHCPv6 CGA Sec Option is used to carry a Sec value, the parameters
   associated with CGA generation on a client. After receiving the CGA
   Sec Option, the client SHOULD generate a CGA using a Sec value that
   is not lower than the option indicated.

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |       OPTION_CGA_SEC          |       option-len              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    CGA SEC    |
   +-+-+-+-+-+-+-+-+

       option-code     OPTION_CGA_SEC (TBA1).

       option-len      1.

       CGA SEC        a digit between 0 and 7, the SEC level.




Jiang & Xia           Expires February 24, 2011               [Page 6]


Internet-Draft draft-jiang-dhc-cga-config-dhcpv6-01.txt     August 2010


   Note: On receiving the CGA Sec Option, the client MAY choose to
   generate a CGA using a lower sec value. It MAY cause that the client
   is not able to use full network capabilities.

5. DHCPv6 Address Grant Option

   DHCPv6 Address Grant Option is used to indicate the DHCPv6 client
   whether the requested address is granted or not.

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |       OPTION_ADDR_GRANT       |       option-len              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Addr Grant  |
   +-+-+-+-+-+-+-+-+

       option-code     OPTION_ADDR_GRANT (TBA2).

       option-len      1.

       Addr Grant      The Addr_Grant field sets 0 when a client
                       requests granting from server. It sets 1
                       indicating that the requested Address is granted;
                       it sets 2 indicating that the requested Address
                       is declined.

6. Security Considerations

   The mechanisms based on DHCPv6 are all vulnerable to attacks to the
   DHCP client, such as request for CGA generation with a high Sec value.
   Proper use of DHCPv6 autoconfiguration facilities [RFC3315], such as
   AUTH option or Secure DHCP [I-D.ietf-dhc-secure-dhcpv6] can prevent
   these threats, provided that a configuration token is known to both
   the client and the server.

   Note that, as expected, it is not possible to provide secure
   configuration of CGA without a previous configuration of security
   information at the client (either a trust anchor, a DHCPv6
   configuration token...). However, considering that the values of
   these elements could be shared by the nodes in the network segment,
   these security elements can be configured more easily in the end
   nodes than its addresses.

   Regarding to the configuration of the Sec parameter, one risk is that
   a malicious node could propagate a Sec value providing less
   protection than intended by the network administrator, facilitating a


Jiang & Xia           Expires February 24, 2011               [Page 7]


Internet-Draft draft-jiang-dhc-cga-config-dhcpv6-01.txt     August 2010


   brute force attack against the hash, or the selection of the weakest
   hash algorithm available for CGA definition. However, even in the
   worst case, if the hash algorithm cannot be inverted, the expected
   number of iterations required for a brute force attack is O(2^59) in
   order to find a CGA Parameters data structure that matches a given
   CGA. Another risk is the use of a Sec, higher than intended by the
   administrator, which would require a large number of resources of the
   client to compute the modifier, requiring a long time before the
   device can communicate. This can be considered a kind of DOS attack.
   A variation of this attack is the propagation of different Sec values.
   This kind of attack may be prevented by protected DHCPv6 interactions.

7. IANA Considerations

   This document defines two new DHCPv6 [RFC3315] options, which must be
   assigned Option Type values within the option numbering space for
   DHCPv6 messages:

   The DHCPv6 CGA Sec Option (TBA1), described in Section 4.

   The DHCPv6 Address Grant Option (TBA2), described in Section 5.

8. Acknowledgments

   The authors would like to thank Marcelo Bagnulo Braun and Alberto
   Garcia-Martinez from Universidad Carlos III de Madrid for been
   involved in the early requirement identification. Valuable comments
   from Bernie Volz, Cisco and Dujuan Gu, Huawei are appreciated.

9. References

9.1. Normative References

   [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate
             Requirement Levels", RFC2119, March 1997.

   [RFC3315] R. Droms, Ed., "Dynamic Host Configure Protocol for IPv6",
             RFC3315, July 2003.

   [RFC3633] O. Troan and R. Droms, "IPv6 Prefix Options for Dynamic
             Host Configuration Protocol (DHCP) version 6", RFC 3633,
             December 2003.

   [RFC3971] J. Arkko, J. Kempf, B. Zill and P. Nikander, "SEcure
             Neighbor Discovery (SEND) ", RFC 3971, March 2005.




Jiang & Xia           Expires February 24, 2011               [Page 8]


Internet-Draft draft-jiang-dhc-cga-config-dhcpv6-01.txt     August 2010


   [RFC3972] T. Aura, "Cryptographically Generated Address", RFC3972,
             March 2005.

   [RFC4861] T. Narten, et al., "Neighbor Discovery for IP version 6
             (IPv6)", RFC 4861, September 2007.

   [RFC4862] S. Thomson, T. Narten and T. Jinmei, "IPv6 Stateless
             Address Autoconfiguration", RFC4862, September 2007.

   [RFC4866] J. Arkko, C. Vogt and W. Haddad, "Enhanced Route
             Optimization for Mobile IPv6", RFC4866, May 2007.

   [RFC4982] M. Bagnulo, "Support for Multiple Hash Algorithms in
             Cryptographically Generated Addresses (CGAs) ", RFC4982,
             July 2007.

   [RFC5533] E. Nordmark and M. Bagnulo, "Shim6: Level 3 Multihoming
             Shim Protocol for IPv6" FRC 5533, June 2009.

9.2. Informative References

   [I-D.ietf-csi-dhcpv6-cga-ps]
             S. Jiang, S. Shen and T. Chown, "DHCPv6 and CGA Interaction:
             Problem Statement", draft-ietf-csi-dhcpv6-cga-ps (work in
             progress), June, 2010.

   [I-D.ietf-dhc-secure-dhcpv6]
             S. Jiang and S. Shen, "Secure DHCPv6 Using CGAs", draft-
             ietf-dhc-secure-dhcpv6 (work in progress), June 2010.

Author's Addresses

   Sheng Jiang
   Huawei Technologies Co., Ltd
   Huawei Building, No.3 Xinxi Rd.,
   Shang-Di Information Industry Base, Hai-Dian District, Beijing 100085
   P.R. China
   Email: shengjiang@huawei.com


   Sam(Zhongqi) Xia
   Huawei Technologies Co., Ltd
   Huawei Building, No.3 Xinxi Rd.,
   Shang-Di Information Industry Base, Hai-Dian District, Beijing 100085
   P.R. China
   Email: xiazhongqi@huawei.com



Jiang & Xia           Expires February 24, 2011               [Page 9]


Html markup produced by rfcmarkup 1.129c, available from https://tools.ietf.org/tools/rfcmarkup/