idnits 2.17.1 draft-jiang-csi-dhcpv6-cga-ps-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 3 instances of too long lines in the document, the longest one being 1 character in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 3315 (Obsoleted by RFC 8415) ** Obsolete normative reference: RFC 4242 (Obsoleted by RFC 8415) Summary: 3 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Sheng Jiang 2 Internet Draft Sean Shen 3 Intended status: Standards Track Huawei Technologies Co., Ltd 4 Expires: July 12, 2009 January 8th, 2009 6 DHCPv6 and CGA Interaction: Problem Statement 8 draft-jiang-csi-dhcpv6-cga-ps-01.txt 10 Status of this Memo 12 This Internet-Draft is submitted to IETF in full conformance with the 13 provisions of BCP 78 and BCP 79. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet-Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six months 20 and may be updated, replaced, or obsoleted by other documents at any 21 time. It is inappropriate to use Internet-Drafts as reference 22 material or to cite them other than as "work in progress." 24 The list of current Internet-Drafts can be accessed at 25 http://www.ietf.org/ietf/1id-abstracts.txt 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html 30 This Internet-Draft will expire on July 12, 2009. 32 Abstract 34 This document presents a problem statement for the possible 35 interactions between DHCPv6 and CGA. Firstly, in order to support the 36 co-existing scenarios of DHCPv6 and CGA, Some operations are 37 clarified for the interaction of DHCPv6 servers and CGA-associated 38 hosts. Then, some extended scenarios are also discussed in this 39 document, including using CGAs in DHCPv6 operations to enhance the 40 security features and using DHCPv6 to serve the CGA generation. 42 Table of Contents 44 1. Introduction................................................2 45 2. Terminology.................................................2 46 3. Co-existing of DHCPv6 and CGA................................2 47 4. What DHCPv6 can do for CGA...................................3 48 5. What CGA can do for DHCPv6...................................4 49 6. Security Considerations......................................5 50 7. IANA Considerations.........................................5 51 8. Solution Requests...........................................5 52 9. References..................................................5 53 9.1. Normative References....................................5 54 9.2. Informative References..................................6 55 Author's Addresses.............................................7 56 Copyright Notice...............................................8 58 1. Introduction 60 Dynamic Host Configuration Protocol for IPv6 (DHCPv6) [RFC3315] can 61 assign addresses statefully. Although there are other ways to assign 62 IPv6 address [RFC4862, RFC4339], DHCPv6 is still useful when 63 administrator desire more control over addressing. Besides, DHCPv6 64 also be used to distribute other information when dialog state is 65 critical [RFC4242]. 67 Cryptographically Generated Addresses (CGA) [RFC3972] are IPv6 68 addresses for which the interface identifiers are generated by 69 computing a cryptographic one-way hash function from a public key and 70 auxiliary parameters. By using the associate public & private keys as 71 described in SEcure Neighbor Discovery (SEND) [RFC3971], CGA can 72 protect Neighbor Discovery Protocol (NDP) [RFC4861], i.e. it provides 73 address validation and integrity protection for NDP messages. 75 This document presents a problem statement for the possible 76 interactions between DHCPv6 and CGA. Firstly, in order to support the 77 co-existing scenarios of DHCPv6 and CGA, Some operations are 78 clarified for the interaction of DHCPv6 servers and CGA-associated 79 hosts. Then, some extended scenarios are also discussed in this 80 document, including using CGAs in DHCPv6 operations to enhance the 81 security features and using DHCPv6 to serve the CGA generation. 83 2. Terminology 85 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 86 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 87 document are to be interpreted as described in RFC-2119 [RFC2119]. 89 3. Co-existing of DHCPv6 and CGA 91 As an important IPv6 technique, CGA is used efficiently on the 92 stateless address configuration of IPv6 address [RFC4862]. The public 93 key system associated with CGA address provides message origin 94 validation and integrity protection without negotiation and 95 transportation of key materials. 97 The current CGA specifications does not mandate which device 98 generates a CGA address. In many cases, a CGA address is generated by 99 the associated key pair owner, which normally is also the host that 100 will use the CGA address. 102 However, in a DHCPv6-managed network, hosts should obtain IPv6 103 addresses only from a DHCPv6 server. This difference of roles needs 104 to be carefully considered during the interaction of CGA and DHCPv6. 106 Operations, as clarified in the next paragraph, support the co- 107 existing of CGA's host self-generate address mechanism and DHCPv6 108 managed address mechanism. 110 This can be solved by validation procedure, which has been defined in 111 the current DHCPv6. A node requests DHCPv6 server to grant a CGA 112 generated by the node itself, listing the CGA addresses in IA options, 113 which has been defined in [RFC3315]. According to whether the CGA 114 matches the CGA-related configuration parameters of the network, the 115 DHCPv6 server sends an acknowledgement to the node, grant the usage 116 of the CGA or indicate the node that it must generate a new CGA with 117 the CGA-related configuration parameters of the network. In the 118 meantime, the DHCPv6 server has had the opportunity to log the 119 address/host combination. 121 4. What DHCPv6 can do for CGA 123 In the current CGA specifications, there is a lack of procedures to 124 enable proper management of CGA generation. Administrators should be 125 able to configure parameters used to generate CGA. For example, 126 DHCPv6 server should be able to assign subnet prefix or certificates 127 to CGA address owner. In some scenarios, the administrator may 128 further want to enforce some parameters, particularly, the demanded 129 security related parameters such as SEC value. 131 In the CGA generation procedure, the large computational consumption 132 is needed to generate the Modifier field of a CGA address. This CPU 133 intensive operation can represent time and/or battery consumption 134 problems for end hosts (i.e. mobile devices) with limited computing 135 ability and/or restricted battery power. In these cases, a mechanism 136 to delegate the computation of the modifier should be provided. It is 137 possible that the whole CGA generation procedure is delegated to the 138 DHCPv6 server. 140 Generating a key pair, which will be used to generate CGA, also 141 requires large computation. Generation and distribution of a key pair 142 can also be done by DHCPv6 server. 144 DHCPv6 can help on these issues by providing more relevant functions. 146 New DHCPv6 options may be defined to carry management parameters from 147 DHCPv6 server to the client. A new DHCPv6 prefix assignment option 148 may be define to propagate a subnet prefix. More DHCPv6 options may 149 be defined to propagate more CGA-relevant configuration information, 150 such as SEC value, certification information, SEND proxy information, 151 etc. 153 New interaction behavior between DHCPv6 server and client with a set 154 of new DHCPv6 options may be defined to allow computation delegation. 155 A node may initiate a DHCPv6 request to the DHCPv6 server for the 156 computation of the Modifier or the CGA address. The server either 157 computes by itself, or redirects the computation require to another 158 server. Once the server obtains the modifier or the CGA address, it 159 responds to the node with the modifier or the resulting address and 160 the corresponding CGA Parameters Data Structure. 162 New DHCPv6 options may be defined to support the interactions that a 163 DHCPv6 server generates a key pair for hosts. 165 5. What CGA can do for DHCPv6 167 DHCPv6 is vulnerable to various attacks particularly fake attack. In 168 the basic DHCPv6 specifications, regular IPv6 addresses are used. It 169 is possible for a malicious attacker to use a fake address to spoof 170 or launch an attack. A malicious fake DHCPv6 server can provide 171 incorrect configuration to the client in order to divert the client 172 to communicate with malicious services, like DNS or NTP. It may also 173 mount a denial of service attack through mis-configuration of the 174 client that causes all network communication from the client to fail. 175 Fake DHCPv6 server may also collect some critical information from 176 the client. Attackers may be able to gain unauthorized access to some 177 resources, such as network access. 179 The usage of CGA can efficiently improve the security of DHCPv6. Thus 180 the address of a DHCP message sender, which can be a DHCP server, a 181 reply agent or a client, can be verified by a receiver. It improves 182 communication security of DHCPv6 interaction. This mechanism is 183 applicable in environments where physical security on the link is not 184 assured (such as over wireless) or where available security 185 mechanisms are not sufficient, and attacks on DHCPv6 are a concern. 187 Of course, as an assumption, the advantage of CGA can be taken only 188 when CGA addresses are used in DHCPv6 communications. 190 6. Security Considerations 192 As Section 5 of this document has discussed, CGA can provide 193 additional security features for DHCPv6. When one defines solution 194 using the DHCPv6 to configure CGA, which has been mentioned in 195 Section 4 of this document, more consideration should be taken to 196 evaluate whether the new mechanism bring in security vulnerabilities. 198 7. IANA Considerations 200 There are no IANA considerations in this document. 202 8. Solution Requests 204 As we discussed through this document, CGA and DHCPv6 can provide 205 additional service or security features for each other. Solutions 206 that define the details of abovementioned interactions are worthy 207 exploring. 209 9. References 211 9.1. Normative References 213 [RFC3315] R. Droms, et al., "Dynamic Host Configure Protocol for 214 IPv6", RFC3315, July 2003. 216 [RFC3971] J. Arkko, J. Kempf, B. Zill, P. Nikander, "SEcure Neighbor 217 Discovery (SEND) ", RFC 3971, March 2005. 219 [RFC3972] T. Aura, "Cryptographically Generated Address", RFC3972, 220 March 2005. 222 [RFC4242] S. Venaas, T. Chown, B. Volz, "Information Refresh Time 223 Option for Dynamic Host Configuration Protocol for IPv6 224 (DHCPv6)", RFC4242, November 2005. 226 [RFC4861] T. Narten, E. Nordmark, W. Simpson, H. Soliman, "Neighbor 227 Discovery for IP version 6 (IPv6)", RFC4861, September 2007. 229 [RFC4862] S. Thomson, T. Narten, "IPv6 Stateless Address 230 Autoconfiguration", RFC4862, September 2007. 232 9.2. Informative References 234 [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate 235 Requirement Levels", RFC2119, March 1997. 237 [RFC4339] J. Jeong, Ed., "IPv6 Host Configuration of DNS Server 238 Information Approaches", RFC4339, February 2006. 240 Author's Addresses 242 Sheng Jiang 243 Huawei Technologies Co., Ltd 244 KuiKe Building, No.9 Xinxi Rd., 245 Shang-Di Information Industry Base, Hai-Dian District, Beijing 100085 246 P.R. China 247 Phone: 86-10-82836774 248 Email: shengjiang@huawei.com 250 Sean Shen 251 Huawei Technologies Co., Ltd 252 KuiKe Building, No.9 Xinxi Rd., 253 Shang-Di Information Industry Base, Hai-Dian District, Beijing 100085 254 P.R. China 255 Phone: 86-10-82836072 256 Email: sshen@huawei.com 258 Copyright Notice 260 Copyright (c) 2009 IETF Trust and the persons identified as the 261 document authors. All rights reserved. 263 This document is subject to BCP 78 and the IETF Trust's Legal 264 Provisions Relating to IETF Documents 265 (http://trustee.ietf.org/license-info) in effect on the date of 266 publication of this document. Please review these documents 267 carefully, as they describe your rights and restrictions with respect 268 to this document.