One document matched: draft-bi-dhc-sec-option-00.txt
DHC E. Bi
Internet-Draft S. Manning
Intended status: Standards Track M. Wong
Expires: March 24, 2012 Huawei Technologies
September 21, 2011
Security option extension for DHCPv4
draft-bi-dhc-sec-option-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 option 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 is an option definition extension for DHCPv4
which should be included in [RFC 2132].
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 March 24, 2012.
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
Bi Expires March 24, 2012 [Page 1]
Internet-Draft DHCP Security Option Extension September 2011
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.
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 . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. DHCP Security Specific Configuration Option . . . . . . . . . . 3
4. Security Considerations . . . . . . . . . . . . . . . . . . . . 7
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8
6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 8
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8
7.1. Normative References . . . . . . . . . . . . . . . . . . . 8
7.2. Informative References . . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9
Bi Expires March 24, 2012 [Page 2]
Internet-Draft DHCP Security Option Extension September 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
extension. 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. This document defines a new security DHCP
option,DHCP Security Specific Configuration Option,which is used to
exchange the security information and related parameters.
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].
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
Bi Expires March 24, 2012 [Page 3]
Internet-Draft DHCP Security Option Extension September 2011
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:
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Bi Expires March 24, 2012 [Page 4]
Internet-Draft DHCP Security Option Extension September 2011
Figure 1. The format of DHCP security specific configuration option
option-code: DHCP security-specific option code (TBD).
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.
Additionallyif 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.
Bi Expires March 24, 2012 [Page 5]
Internet-Draft DHCP Security Option Extension September 2011
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
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 host, 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.
Bi Expires March 24, 2012 [Page 6]
Internet-Draft DHCP Security Option Extension September 2011
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
uniformly. The security-specific attribute information indicated the
security information type. For example, a DHCP client indicates
security configurations with the same code number that can be
interpreted by different DHCP servers. 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 DHCPREQUESTmessages. And DHCP server MUST
allocate all the request configuration attribute values according to
the received attribute type and format in the DHCP response messages.
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. Security Considerations
This document defines a new security option used by DHCP servers and
DHCP clients to exchange security configuration information. And, if
the additional configuration information is sensitive in nature,
consideration needs to be taken on how to protect it.
Bi Expires March 24, 2012 [Page 7]
Internet-Draft DHCP Security Option Extension September 2011
5. IANA Considerations
There may be IANA consideration for taking additional value for the
option. The value of the protocol field needed to be assigned from
the numbering space.
6. Acknowledgments
Thanks to Serge Manning, Marcus Wong, Eric Chen, Xiangsong Cui and
Rock Xie who contributed actively to this document.
7. References
7.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.
7.2. Informative References
[3GPP.33.310]
3GPP, "Network Domain Security (NDS); Authentication
Framework (AF)", 3GPP TS 33.310 10.3.0, June 2011.
[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.
Bi Expires March 24, 2012 [Page 8]
Internet-Draft DHCP Security Option Extension September 2011
Authors' Addresses
Emily Bi
Huawei Technologies
Huawei Building, Xinxi Road No.3
Haidian District, Beijing 100085
P. R. China
Phone: +86-10-59723229
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 March 24, 2012 [Page 9]
| PAFTECH AB 2003-2026 | 2026-04-24 04:15:35 |