One document matched: draft-jiang-csi-dhcpv6-cga-ps-01.txt
Differences from draft-jiang-csi-dhcpv6-cga-ps-00.txt
Network Working Group Sheng Jiang
Internet Draft Sean Shen
Intended status: Standards Track Huawei Technologies Co., Ltd
Expires: July 12, 2009 January 8th, 2009
DHCPv6 and CGA Interaction: Problem Statement
draft-jiang-csi-dhcpv6-cga-ps-01.txt
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-Drafts.
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."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
This Internet-Draft will expire on July 12, 2009.
Abstract
This document presents a problem statement for the possible
interactions between DHCPv6 and CGA. Firstly, in order to support the
co-existing scenarios of DHCPv6 and CGA, Some operations are
clarified for the interaction of DHCPv6 servers and CGA-associated
hosts. Then, some extended scenarios are also discussed in this
document, including using CGAs in DHCPv6 operations to enhance the
security features and using DHCPv6 to serve the CGA generation.
Table of Contents
1. Introduction................................................2
2. Terminology.................................................2
3. Co-existing of DHCPv6 and CGA................................2
4. What DHCPv6 can do for CGA...................................3
Jiang & Shen Expires July 12, 2009 [Page 1]
Internet-Draft draft-jiang-csi-dhcpv6-cga-ps-01.txt January 2009
5. What CGA can do for DHCPv6...................................4
6. Security Considerations......................................5
7. IANA Considerations.........................................5
8. Solution Requests...........................................5
9. References..................................................5
9.1. Normative References....................................5
9.2. Informative References..................................6
Author's Addresses.............................................7
Copyright Notice...............................................8
1. Introduction
Dynamic Host Configuration Protocol for IPv6 (DHCPv6) [RFC3315] can
assign addresses statefully. Although there are other ways to assign
IPv6 address [RFC4862, RFC4339], DHCPv6 is still useful when
administrator desire more control over addressing. Besides, DHCPv6
also be used to distribute other information when dialog state is
critical [RFC4242].
Cryptographically Generated Addresses (CGA) [RFC3972] are IPv6
addresses for which the interface identifiers are generated by
computing a cryptographic one-way hash function from a public key and
auxiliary parameters. By using the associate public & private keys as
described in SEcure Neighbor Discovery (SEND) [RFC3971], CGA can
protect Neighbor Discovery Protocol (NDP) [RFC4861], i.e. it provides
address validation and integrity protection for NDP messages.
This document presents a problem statement for the possible
interactions between DHCPv6 and CGA. Firstly, in order to support the
co-existing scenarios of DHCPv6 and CGA, Some operations are
clarified for the interaction of DHCPv6 servers and CGA-associated
hosts. Then, some extended scenarios are also discussed in this
document, including using CGAs in DHCPv6 operations to enhance the
security features and using DHCPv6 to serve the CGA generation.
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 RFC-2119 [RFC2119].
3. Co-existing of DHCPv6 and CGA
As an important IPv6 technique, CGA is used efficiently on the
stateless address configuration of IPv6 address [RFC4862]. The public
key system associated with CGA address provides message origin
Jiang & Shen Expires July 12, 2009 [Page 2]
Internet-Draft draft-jiang-csi-dhcpv6-cga-ps-01.txt January 2009
validation and integrity protection without negotiation and
transportation of key materials.
The current CGA specifications does not mandate which device
generates a CGA address. In many cases, a CGA address is generated by
the associated key pair owner, which normally is also the host that
will use the CGA address.
However, in a DHCPv6-managed network, hosts should obtain IPv6
addresses only from a DHCPv6 server. This difference of roles needs
to be carefully considered during the interaction of CGA and DHCPv6.
Operations, as clarified in the next paragraph, support the co-
existing of CGA's host self-generate address mechanism and DHCPv6
managed address mechanism.
This can be solved by validation procedure, which has been defined in
the current DHCPv6. A node requests DHCPv6 server to grant a CGA
generated by the node itself, listing the CGA addresses in IA options,
which has been defined in [RFC3315]. According to whether the CGA
matches the CGA-related configuration parameters of the network, the
DHCPv6 server sends an acknowledgement to the node, grant the usage
of the CGA or indicate the node that it must generate a new CGA with
the CGA-related configuration parameters of the network. In the
meantime, the DHCPv6 server has had the opportunity to log the
address/host combination.
4. What DHCPv6 can do for CGA
In the current CGA specifications, there is a lack of procedures to
enable proper management of CGA generation. Administrators should be
able to configure parameters used to generate CGA. For example,
DHCPv6 server should be able to assign subnet prefix or certificates
to CGA address owner. In some scenarios, the administrator may
further want to enforce some parameters, particularly, the demanded
security related parameters such as SEC value.
In the CGA generation procedure, the large computational consumption
is needed to generate the Modifier field of a CGA address. This CPU
intensive operation can represent time and/or battery consumption
problems for end hosts (i.e. mobile devices) with limited computing
ability and/or restricted battery power. In these cases, a mechanism
to delegate the computation of the modifier should be provided. It is
possible that the whole CGA generation procedure is delegated to the
DHCPv6 server.
Jiang & Shen Expires July 12, 2009 [Page 3]
Internet-Draft draft-jiang-csi-dhcpv6-cga-ps-01.txt January 2009
Generating a key pair, which will be used to generate CGA, also
requires large computation. Generation and distribution of a key pair
can also be done by DHCPv6 server.
DHCPv6 can help on these issues by providing more relevant functions.
New DHCPv6 options may be defined to carry management parameters from
DHCPv6 server to the client. A new DHCPv6 prefix assignment option
may be define to propagate a subnet prefix. More DHCPv6 options may
be defined to propagate more CGA-relevant configuration information,
such as SEC value, certification information, SEND proxy information,
etc.
New interaction behavior between DHCPv6 server and client with a set
of new DHCPv6 options may be defined to allow computation delegation.
A node may initiate a DHCPv6 request to the DHCPv6 server for the
computation of the Modifier or the CGA address. The server either
computes by itself, or redirects the computation require to another
server. Once the server obtains the modifier or the CGA address, it
responds to the node with the modifier or the resulting address and
the corresponding CGA Parameters Data Structure.
New DHCPv6 options may be defined to support the interactions that a
DHCPv6 server generates a key pair for hosts.
5. What CGA can do for DHCPv6
DHCPv6 is vulnerable to various attacks particularly fake attack. In
the basic DHCPv6 specifications, regular IPv6 addresses are used. It
is possible for a malicious attacker to use a fake address to spoof
or launch an attack. A malicious fake DHCPv6 server can provide
incorrect configuration to the client in order to divert the client
to communicate with malicious services, like DNS or NTP. It may also
mount a denial of service attack through mis-configuration of the
client that causes all network communication from the client to fail.
Fake DHCPv6 server may also collect some critical information from
the client. Attackers may be able to gain unauthorized access to some
resources, such as network access.
The usage of CGA can efficiently improve the security of DHCPv6. Thus
the address of a DHCP message sender, which can be a DHCP server, a
reply agent or a client, can be verified by a receiver. It improves
communication security of DHCPv6 interaction. This mechanism is
applicable in environments where physical security on the link is not
assured (such as over wireless) or where available security
mechanisms are not sufficient, and attacks on DHCPv6 are a concern.
Jiang & Shen Expires July 12, 2009 [Page 4]
Internet-Draft draft-jiang-csi-dhcpv6-cga-ps-01.txt January 2009
Of course, as an assumption, the advantage of CGA can be taken only
when CGA addresses are used in DHCPv6 communications.
6. Security Considerations
As Section 5 of this document has discussed, CGA can provide
additional security features for DHCPv6. When one defines solution
using the DHCPv6 to configure CGA, which has been mentioned in
Section 4 of this document, more consideration should be taken to
evaluate whether the new mechanism bring in security vulnerabilities.
7. IANA Considerations
There are no IANA considerations in this document.
8. Solution Requests
As we discussed through this document, CGA and DHCPv6 can provide
additional service or security features for each other. Solutions
that define the details of abovementioned interactions are worthy
exploring.
9. References
9.1. Normative References
[RFC3315] R. Droms, et al., "Dynamic Host Configure Protocol for
IPv6", RFC3315, July 2003.
[RFC3971] J. Arkko, J. Kempf, B. Zill, P. Nikander, "SEcure Neighbor
Discovery (SEND) ", RFC 3971, March 2005.
[RFC3972] T. Aura, "Cryptographically Generated Address", RFC3972,
March 2005.
[RFC4242] S. Venaas, T. Chown, B. Volz, "Information Refresh Time
Option for Dynamic Host Configuration Protocol for IPv6
(DHCPv6)", RFC4242, November 2005.
[RFC4861] T. Narten, E. Nordmark, W. Simpson, H. Soliman, "Neighbor
Discovery for IP version 6 (IPv6)", RFC4861, September 2007.
[RFC4862] S. Thomson, T. Narten, "IPv6 Stateless Address
Autoconfiguration", RFC4862, September 2007.
Jiang & Shen Expires July 12, 2009 [Page 5]
Internet-Draft draft-jiang-csi-dhcpv6-cga-ps-01.txt January 2009
9.2. Informative References
[RFC2119] S. Bradner, "Key words for use in RFCs to Indicate
Requirement Levels", RFC2119, March 1997.
[RFC4339] J. Jeong, Ed., "IPv6 Host Configuration of DNS Server
Information Approaches", RFC4339, February 2006.
Jiang & Shen Expires July 12, 2009 [Page 6]
Internet-Draft draft-jiang-csi-dhcpv6-cga-ps-01.txt January 2009
Author's Addresses
Sheng Jiang
Huawei Technologies Co., Ltd
KuiKe Building, No.9 Xinxi Rd.,
Shang-Di Information Industry Base, Hai-Dian District, Beijing 100085
P.R. China
Phone: 86-10-82836774
Email: shengjiang@huawei.com
Sean Shen
Huawei Technologies Co., Ltd
KuiKe Building, No.9 Xinxi Rd.,
Shang-Di Information Industry Base, Hai-Dian District, Beijing 100085
P.R. China
Phone: 86-10-82836072
Email: sshen@huawei.com
Jiang & Shen Expires July 12, 2009 [Page 7]
Internet-Draft draft-jiang-csi-dhcpv6-cga-ps-01.txt January 2009
Copyright Notice
Copyright (c) 2009 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.
Jiang & Shen Expires July 12, 2009 [Page 8] | PAFTECH AB 2003-2026 | 2026-04-23 06:06:58 |