One document matched: draft-bi-dhc-opextensions-00.txt




DHC                                                                E. Bi
Internet-Draft                                                S. Manning
Intended status: Standards Track                                 M. Wong
Expires: December 17, 2011                           Huawei Technologies
                                                           June 15, 2011



                      Option Extensions for DHCPv4
                    draft-bi-dhc-opextensions-00.txt

Abstract

   This document defines a new option that can be used by DHCP servers
   to exchange with DHCP clients specific security configuration
   information.  This new options also defines a standard parameter
   format and code so that there will be no ambiguity in interoperating
   the information being exchanged and that there will be no issues
   related to interoperability.  It also defines some other options that
   may be used in enterprise networks but not included in [RFC2132].

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 December 18, 2011.

Copyright Notice

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



Bi                      Expires December 18, 2011               [Page 1]


Internet-Draft  DHCP Options and BOOTP Vendor extensions       June 2011


   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

   This document may contain material from IETF Documents or IETF
   Contributions published or made publicly available before November
   10, 2008.  The person(s) controlling the copyright in some of this
   material may not have granted the IETF Trust the right to allow
   modifications of such material outside the IETF Standards Process.
   Without obtaining an adequate license from the person(s) controlling
   the copyright in such materials, this document may not be modified
   outside the IETF Standards Process, and derivative works of it may
   not be created outside the IETF Standards Process, except to format
   it for publication as an RFC or to translate it into languages other
   than English.


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Terminology used in this document  . . . . . . . . . . . . . .  3
   3.  DHCP Security Specific Configuration option . . . . . . . . . . 4
   4.  Other options can be used for enterprise network . . . . . . .  8
   5.  Security Considerations  . . . . . . . . . . . . . . . . . . .  9
   6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 10
   7.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 10
   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
     8.1.  Normative References . . . . . . . . . . . . . . . . . . . 10
     8.2.  Informative References . . . . . . . . . . . . . . . . . . 10
   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 11






















Bi                      Expires December 18, 2011               [Page 2]


Internet-Draft  DHCP Options and BOOTP Vendor extensions       June 2011


1.  Introduction

   DHCP provides a framework for passing network configuration
   information to hosts on a TCP/IP network.  Some configuration
   parameters and control information can be carried in DHCP options
   which are defined in [RFC2132], [RFC3046], [RFC3118], [RFC4030], etc.
   When a host that acts as a DHCP client booting up, it can be
   configured with some security policy, e.g., due to the security
   concern, all the configuration packets to and from a client must be
   transported via a secure channel which is established with the server
   or administrator.  Some scenarios that require this kind of secure
   booting are when DHCP clients are in wireless base stations attaching
   to a wireless network infrastructure as defined in [3GPP.33.310].
   Otherwise, the packets may be dropped by nodes in the network such as
   a firewall or security gateway.  So it is important for the host to
   obtain a set of security information, which is configured in the DHCP
   server prior to the establishment of the security tunnel.  Currently,
   some implementations exchange this security information through DHCP
   vendor-specific options.  However, this has the usual limitations of
   requiring the client and server to understand these vendor specific
   extensions.  Since most of the parameters that make up the security
   information are common across most clients and servers, having a
   standardized set of options and procedures would be a huge benefit to
   interoperability.  Some implementations need additional options that
   are not yet defined in [RFC2132] and therefore create
   interoperability issues among implementations by different vendors.
   This document defines a new set of common DHCP options used to
   exchange the security information and related parameters.

   The four newly defined options are as follows:

   Option X1: DHCP Security Specific Configuration option

   Option X2: Proxy Server option

   Option X3: Local Print Server option

   Option X4: Local File Server option


2.  Terminology used in this document

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






Bi                      Expires December 18, 2011               [Page 3]


Internet-Draft  DHCP Options and BOOTP Vendor extensions       June 2011


3.  DHCP Security Specific Configuration option

   A DHCP server can use this option to indicate to the DHCP client
   specific configuration information, such as the IP address of the
   security gateway that is used to establish IPsec tunnel within the
   enterprise network, or multiple IP addresses of the client that are
   used within the enterprise network.  The information contained in the
   specific configuration area of this option includes one or more
   attribute values that are assigned by IANA.  The information which is
   contained in these attribute data fields of this option contains the
   detailed specific configuration information for the DHCP client.

   This option may be used wherever DHCP options may be used, as
   specified in [RFC2131]and [RFC2132].  It is most meaningful in the
   messages between DHCP client and DHCP server, such as, DHCPOFFER and
   DHCPACK.  The format of the option X1 is as follows:



































Bi                      Expires December 18, 2011               [Page 4]


Internet-Draft  DHCP Options and BOOTP Vendor extensions       June 2011


       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 56 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  option-code  |  option-len   | C-IP Address   |   data-len1  |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      +                    Client IP address Data                     |
      /                                                               /
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  Se-GW ID     | data-len2   |      Security-GW ID Data        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                                |
      +                     Security-GW ID Data                        |
      /                                                                /
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  ACL policy   | data-len3   |      ACL Policy Data            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                                |
      +                     ACL Policy Data                            |
      /                                                                /
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  PKI IP Add   | data-len4   |      PKI IP Address Data         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                                |
      +                     PKI IP Address Data                        |
      /                                                                /
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  OAM IP Add   | data-len5   |      OAM IP Address Data         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                                |
      +                     OAM IP Address Data                        |
      /                                                                /
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  OCSP IP Add   | data-len6   |     OCSP IP Address Data        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                                |
      +                    OCSP IP Address Data                        |
      /                                                                /
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                              RSV                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                              Private                           |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


   Figure 1.  The format of DHCP security specific configuration option

   option-code: DHCP security specific configuration option code (TBD).




Bi                      Expires December 18, 2011               [Page 5]


Internet-Draft  DHCP Options and BOOTP Vendor extensions       June 2011


   option-len: Total length of all following option data in octets.

   Security-specific attribute N: Security-specific attribute type code
   (TBD).

   If the DHCP client is required to securely boot, the address or FQDN
   of Security gateway for IPsec establishment is required.
   Additionally if the security policy dictates, the ACL policy and
   multiple IP address of the DHCP client for different usage are also
   required.

   In this document, the minimum set of security-specific attribute is
   specified.

   IP address of the DHCP client: it indicates the IP address of the
   DHCP client.  In current specification defined in [RFC2131], the IP
   address of client is allocated in yiaddr field, but only one address
   can be obtain.  If multiple IP addresses are needed, such as,
   transport IP, service IP and OM IP or public interface IP address and
   enterprise network IP address, this option can be used.  The
   security-specific attribute data comprise the different separate
   items.  The definition of the sub-security-specific is listed as
   follows.

   Public interface IP: it indicates the public interface IP address of
   the DHCP client.

   Enterprise IP: it indicates the IP address of the DHCP client used
   within the enterprise network.Each of the attributes is optional and
   available according to local policy.

   Security-gateway ID: it indicates the security information of the
   security gateway.  If the client is configured with security policy,
   the value is mandatory to use.  Else, it cannot obtain the Security
   gateway information to establish IPsec tunnel.  And it mainly used
   with IPsec.

   IP address: it indicates the IP address of the security gateway.

   FQDN: it indicates the FQDN of the security gateway

   Either of these two sub-security-specific attributes can be contained
   according to local policy.

   ACL policy: it indicates the ACL policy attribute.  And six elements
   of the ACL policy are contained in the series of sub-security-
   specific attributes.  The six elements which contains IP address,
   transport port number, protocol, and DSCP.  The client will be



Bi                      Expires December 18, 2011               [Page 6]


Internet-Draft  DHCP Options and BOOTP Vendor extensions       June 2011


   configured with an ACL to filter potentially dangerous packets.  Only
   packets that match the ACL parameters are allowed to pass.

   RA/CA IP: it indicates the IP address of RA/CA

   OMA IP: it indicates the IP address of OAM

   OCSP IP: it indicates the IP address of OCSP

   For these three attributes, a 3GPP base station as a DHCP client
   needs to obtain the operator certificate for certificate based
   authentication as defined in [3GPP.33.310] in wireless network.

   RSV: If is not used, it should be set to zero.

   Private: It is for private use.

   These attributes are for the client, the configuration of all of base
   stations are the same when initially dispatched from the factory,
   when the server receive the client ID, the server will know whether
   the client needs to be configured with security, and then it will
   send the security information to the client.  For the client, it MUST
   identify the option.


    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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  sub-sec-spec | data-len2    |      sub-sec-spec Data         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      +                   sub-security -specific-data                 |
      /                                                               /
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


   Figure 2.  The format of Sub-security-specific option

   Sub-security-specific attribute type: type code of the sub-security-
   specific attribute, i.e., for security-specific attribute3, it
   includes the source IP address, destination address, source port
   number, destination port number, protocol and DSCP in order.  The
   data-len is one octet long and specifies the length of the sub-
   security-specific data.

   This option contains the information corresponding to one or more
   security-specific code number.  Multiple instances of this option may
   be present and must be concatenated in accordance with [RFC3396].
   The definition of the information carried in this option is defined



Bi                      Expires December 18, 2011               [Page 7]


Internet-Draft  DHCP Options and BOOTP Vendor extensions       June 2011


   uniformly.  The security-specific attribute information indicated the
   security information type. As the security-specific code is uniform and 
   standard, no ambiguity interpretation can occur.  A security-specific 
   code number is unique and only occur once in the option and should be 
   treated independently.  This option can also contains one or more 
   encapsulated options that defined in [RFC2132].

   DHCP client can request the configuration information from DHCP
   server by sending DHCP request message.  DHCP server allocates the
   configuration information to DHCP client according to the client ID.
   i.e., DHCP server can know whether this connecting client needs to be
   configured security configuration by client ID, which can be carried
   in option 60 specified in [RFC2132].  If the security configuration
   is needed, the defined security-specific option will be sent back to
   the client from DHCP server in DHCPOFFER.  If this option is used,
   different DHCP clients implemented by different vendors have good
   interoperability.  The DHCP server needs only to support one
   standardized format which reduces complexity and enhances
   performance.

   If the DHCP client is configured with a security policy, all of the
   attributes listed in the figure MUST be carried in the newly defined
   option in DHCPDISCOVER or DHCPREQUEST messages.  And DHCP server 
   allocate the configuration attribute values according to local policy,
   the DHCP client MUST has the capability to identify the option.

   Use of security-specific information allows enhanced operation,
   utilizing additional features in a DHCP implementation.  Servers not
   equipped to interpret the security-specific information sent by a
   client MUST ignore it.  Clients that do not receive desired security-
   specific information MUST ignore it and initiate another DHCP
   operation.


4.  Other options can be used for enterprise network

   Some other options can be used for enterprise networks.

   X.2.  Proxy Servers Option

   This option specifies a list of IP addresses indicating proxy servers
   available to the client.  Servers SHOULD be listed in order of
   preference.

   The code for this option is X2.  Its minimum length is 4, and the
   length MUST be a multiple of 4.



Bi                      Expires December 18, 2011               [Page 8]


Internet-Draft  DHCP Options and BOOTP Vendor extensions       June 2011


       Code   Len         Address 1               Address 2
      +-----+-----+-----+-----+-----+-----+-----+-----+--
      |  X   |  n  |  a1 |  a2 |  a3 |  a4 |  a1 |  a2 |  ...
      +-----+-----+-----+-----+-----+-----+-----+-----+--



   Figure 3.  X.2 Proxy Servers Option

   This option specifies a list of IP addresses indicating local print
   servers available to the client.  Servers SHOULD be listed in order
   of preference.

   The code for this option is X3.  Its minimum length is 4, and the
   length MUST be a multiple of 4.


       Code   Len         Address 1               Address 2
      +-----+-----+-----+-----+-----+-----+-----+-----+--
      |  X   |  n   |  a1 |  a2  |  a3 |  a4  |  a1 |  a2  |  ...
      +-----+-----+-----+-----+-----+-----+-----+-----+--



   Figure 4.  X.3 Local Print Servers Option

   This option specifies a list of IP addresses indicating local file
   servers available to the client.  Servers SHOULD be listed in order
   of preference.

   The code for this option is X4.  Its minimum length is 4, and the
   length MUST be a multiple of 4.


       Code   Len         Address 1               Address 2
      +-----+-----+-----+-----+-----+-----+-----+-----+--
      |  X   |  n  |  a1 |  a2 |  a3 |  a4 |  a1 |  a2 |  ...
      +-----+-----+-----+-----+-----+-----+-----+-----+--



   Figure 5.  X.4.  Local File Servers Option


5.  Security Considerations

   This document defines a few some options used by DHCP servers and
   DHCP clients to exchange the additional configuration information.



Bi                      Expires December 18, 2011               [Page 9]


Internet-Draft  DHCP Options and BOOTP Vendor extensions       June 2011


   And, if the additional configuration information is sensitive in
   nature, consideration needs to be taken on how to protect it.


6.  IANA Considerations

   There may be IANA consideration for taking additional value for these
   options.  The values of the protocol field needed to be assigned from
   the numbering space.


7.  Acknowledgments

   Thanks to Eric Chen, Xiangsong Cui and Rock Xie who contributed actively
   to this document.


8.  References

8.1.  Normative References

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

   [RFC2131]  Droms, R., "Dynamic Host Configuration Protocol",
              RFC 2131, March 1997.

   [RFC2132]  Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor
              Extensions", RFC 2132, March 1997.

   [RFC3118]  Droms, R. and W. Arbaugh, "Authentication for DHCP
              Messages", RFC 3118, June 2001.

   [RFC3046]  Patrick, M., "DHCP Relay Agent Information Option",
              RFC 3046, January 2001.

   [RFC3396]  Lemon, T. and S. Cheshire, "Encoding Long Options in the
              Dynamic Host Configuration Protocol (DHCPv4)", RFC 3396,
              November 2002.

   [RFC4030]  Stapp, M. and T. Lemon, "The Authentication Suboption for
              the Dynamic Host Configuration Protocol (DHCP) Relay Agent
              Option", RFC 4030, March 2005.

8.2.  Informative References

   [3GPP.33.310]
              3GPP, "Network Domain Security (NDS); Authentication
              



Bi                      Expires December 18, 2011              [Page 10]


Internet-Draft  DHCP Options and BOOTP Vendor extensions       June 2011


              Framework (AF)", 3GPP TS 33.310 6.2.0, September 2004.

              


Author's Address

   Emily Bi
   Huawei Technologies
   Huawei Building, Xinxi Road No.3
   Haidian District, Beijing  100085
   P. R. China

   Phone: +86-10-82881907
   Email: bixiaoyu@huawei.com

   Serge Manning
   Huawei Technologies

   Phone: 001-9725435324
   Email: serge.manning@huawei.com

   Marcus Wong
   Huawei Technologies

   Phone: 001-908-5413505
   Email: mwong@huawei.com




































Bi                      Expires December 18, 2011              [Page 11]


PAFTECH AB 2003-20262026-04-24 04:15:02