idnits 2.17.1 draft-kkb-mpvd-dhcp-support-00.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 21, 2013) is 3832 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC3971' is mentioned on line 210, but not defined == Outdated reference: A later version (-05) exists of draft-anipko-mif-mpvd-arch-04 ** Downref: Normative reference to an Informational draft: draft-anipko-mif-mpvd-arch (ref. 'I-D.anipko-mif-mpvd-arch') -- Possible downref: Non-RFC (?) normative reference: ref. 'OID' ** Obsolete normative reference: RFC 3315 (Obsoleted by RFC 8415) ** Obsolete normative reference: RFC 3633 (Obsoleted by RFC 8415) ** Obsolete normative reference: RFC 4282 (Obsoleted by RFC 7542) Summary: 4 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DHC Working Group S. Krishnan 3 Internet-Draft Ericsson 4 Intended status: Standards Track J. Korhonen 5 Expires: April 24, 2014 Broadcom 6 S. Bhandari 7 Cisco Systems 8 October 21, 2013 10 Support for multiple provisioning domains in DHCPv6 11 draft-kkb-mpvd-dhcp-support-00 13 Abstract 15 The MIF working group is producing a solution to solve the issues 16 that are associated with nodes that can be attached to multiple 17 networks. One part of the solution requires associating 18 configuration information with provisioning domains. This document 19 details how configuration information provided through DHCPv6 can be 20 associated with provisioning domains. 22 Status of this Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on April 24, 2014. 39 Copyright Notice 41 Copyright (c) 2013 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 3. PVD Container option . . . . . . . . . . . . . . . . . . . . . 3 59 4. PVD Identity option . . . . . . . . . . . . . . . . . . . . . . 4 60 5. PVD Authentication and Authorization option . . . . . . . . . . 5 61 6. Set of allowable options . . . . . . . . . . . . . . . . . . . 6 62 7. Behaviour of DHCPv6 entities . . . . . . . . . . . . . . . . . 6 63 7.1. Client and Requesting Router Behavior . . . . . . . . . . . 6 64 7.2. Server and Delegating Router Behavior . . . . . . . . . . . 7 65 8. Security Considerations . . . . . . . . . . . . . . . . . . . . 8 66 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8 67 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 68 11. Normative References . . . . . . . . . . . . . . . . . . . . . 9 69 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 71 1. Introduction 73 The MIF working group is producing a solution to solve the issues 74 that are associated with nodes that can be attached to multiple 75 networks based on the Multiple Provisioning Domains (MPVD) 76 architecture work [I-D.anipko-mif-mpvd-arch]. One part of the 77 solution requires associating configuration information with 78 provisioning domains. This document describes a DHCPv6 mechanism for 79 explicitly indicating provisioning domain information along with any 80 configuration that will be provided. The proposed mechanism uses a 81 DHCPv6 option that indicates the identity of the provisioning domain 82 and encapsulates the options that contain the configuration 83 information as well as any accompanying authentication/authorization 84 information. 86 2. Terminology 88 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 89 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 90 document are to be interpreted as described in [RFC2119]. 92 3. PVD Container option 94 The PVD container option is used to encapsulate and group together 95 all the configuration options that belong to the explicitly 96 identified provisioning domain. The PVD container option MUST 97 encapsulate exactly one OPTION_PVD_ID. The PVD container option MAY 98 occur multiple times in the same message, but each of these PVD 99 container options MUST have a different PVD identity specified under 100 its PVD identity option. The PVD container option SHOULD contain 101 exactly one OPTION_PVD_AUTH. 103 0 1 2 3 104 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 105 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 106 | OPTION_PVD | option-length | 107 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 108 | | 109 + encapsulated-options (variable length) . 110 . . 111 +---------------------------------------------------------------+ 113 Figure 1: PVD Container Option 115 o option-code: OPTION_PVD (TBA1) 117 o option-length: Length of encapsulated options 119 o encapsulated-options: options associated with this provisioning 120 domain. 122 4. PVD Identity option 124 The PVD identity option is used to explicitly indicate the identity 125 of the provisioning domain that is associated with the configuration 126 information encapsulated by the PVD container option. 128 0 1 2 3 129 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 130 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 131 | OPTION_PVD_ID | option-length | 132 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 133 | id-type | PVD identity information | 134 +-+-+-+-+-+-+-+-+ (variable length) + 135 + + 136 . . 137 +---------------------------------------------------------------+ 139 Figure 2: PVD ID Option 141 o option-code: OPTION_PVD_ID (TBA2) 143 o option-length: Length of PVD identity information + 1 145 o id-type: Describes the type of identification information. 146 This document defines four types of PVD identity information 147 0x01: UUID [RFC4122] 148 0x02: UTF-8 string 149 0x03: OID [OID] 150 0x03: NAI Realm [RFC4282] 152 Further types can be added by IANA action. 154 o PVD identity information: The PVD identification that is 155 based on the id-type. 157 5. PVD Authentication and Authorization option 159 The PVD authentication and authorization option contains information 160 that could be used by the DHCPv6 client to verify whether the 161 configuration information provided was not tampered with by the 162 DHCPv6 server as well as establishing that the DHCPv6 server was 163 authorized to advertise the information on behalf of the PVD per 164 OPTION_PVD basis. The contents of the authentication/authorization 165 information are completely opaque to the DHCPv6 server that passes 166 along the information. Every OPTION_PVD option SHOULD contain at 167 most one OPTION_PVD_AUTH option. The OPTION_PVD_AUTH option MUST be 168 the last option inside the OPTION_PVD option. 170 0 1 2 3 171 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 172 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 173 | OPTION_PVD_AUTH | option-length | 174 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 175 | name-type | key-hash : 176 +-+-+-+-+-+-+-+-+ : 177 : : 178 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 179 : : 180 : digital-signature : 181 : : 182 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 184 Figure 3: PVD Auth Option 186 o option-code: OPTION_PVD_AUTH (TBA3) 188 o option-length: Length of the auth information 190 o authentication/authorization information: This information is 191 provided by the owner of the provisioning domain and is passed 192 on unmodified by the DHCPv6 server. 194 o name-type: Names the algorithm used to identify a specific 195 X.509 certificate using the method defined for the Subject Key 196 Identifier (SKI) extension for the X.509 certificates. The 197 usage and the Name Type registry aligns with the mechanism 198 defined for SeND [RFC6494][RFC6495]. Name Type values starting 199 from 3 are supported and an implementation MUST at least support 200 SHA-1 (value 3). 202 o key-hash: A hash of the public key using the algorithm 203 identified by the Name Type. The procedure how the Key Hash is 204 calculated is defined in [RFC3971] and [RFC6495] 206 o digital-signature: A signature calculated over the encapsulating 207 OPTION_PVD including all option data from the beginning of the 208 option while setting the digital-signature field to zero. The 209 procedure of calculating the signature is identical to the one 210 defined for SeND [RFC3971]. 212 [TODO: There may be some alignment considerations here for some 213 implementations as DHCPv6 options are not aligned.] 215 6. Set of allowable options 217 The PVD container option MAY be used to encapsulate any allocated 218 DHCPv6 options but MUST NOT be used to encapsulate another OPTION_PVD 219 option. [TODO: Should we add any other exclusions?] 221 7. Behaviour of DHCPv6 entities 223 This section describes role of DHCPv6 entities involved in requesting 224 and receiving DHCPv6 configuration or prefix and address allocation. 226 7.1. Client and Requesting Router Behavior 228 DHCPv6 client or requesting router can request for configuration from 229 provisioning domain in the following ways: 231 o In the SOLICIT message it MAY include OPTION_PVD_ID requesting 232 configuration for the specific PVD ID indicated in the 233 OPTION_PVD_ID option. It can include multiple OPTION_PVD_ID 234 options to indicate its preference for more than one provisioning 235 domain. The PVD ID it requests is learnt via configuration or any 236 other out of band mechanism not defined in this document. 237 o In the SOLICIT message include an OPTION_ORO option with the 238 OPTION_PVD option code to request configuration from all the PVDs 239 that the DHCPv6 server can provide. 240 The client or requesting router parses OPTION_PVD options in the 241 response message. The Client or Requesting router MUST then include 242 all or subset of the received OPTION_PVD options in the REQUEST 243 message so that it will be responsible for the configuration 244 information selected. 246 If DHCPv6 client or requesting router receives OPTION_PVD options but 247 does not support PVD, it SHOULD ignore the received option(s). 249 7.2. Server and Delegating Router Behavior 251 If the Server or Delegating router supports PVD and it is configured 252 to provide configuration data in one or more provisioning domains, it 253 selects configuration for the PVD based allocation in the following 254 way: 256 o If OPTION_PVD option code within OPTION_ORO is not present in the 257 request, it MUST NOT include provisioning domain based 258 configuration. It MAY select configuration and prefix allocation 259 from a default PVD defined. 260 o If OPTION_PVD_ID is included, it selects information to be offered 261 from that specific PVD if available. 262 o If OPTION_PVD option code within OPTION_ORO is included, then 263 based on its configuration and policy it MAY offer configuration 264 from the available PVD(s). 265 When PVD information and configuration are selected for address and 266 prefix allocation the server or delegating router responds with an 267 ADVERTISE message after populating OPTION_PVD. 269 If OPTION_PVD is not included, then the server or delegating router 270 MAY allocate the prefix and provide configuration as specified in 271 [RFC3315] and[RFC3633] and MUST NOT include OPTION_PVD option in the 272 response. 274 If OPTION_ORO option includes the OPTION_PVD option code but the 275 server or delegating router does not support PVD, then it SHOULD 276 ignore the OPTION_PVD and OPTION_PVD_ID options received. 278 If both client/requesting router and server/delegating router support 279 PVD but cannot offer configuration with PVD for any other reason, it 280 MUST respond to client/requesting router with appropriate status code 281 as specified in [RFC3315] and [RFC3633]. 283 8. Security Considerations 285 An attacker may attempt to modify the information provided inside the 286 PVD container option. These attacks can easily be prevented by using 287 the DHCPv6 AUTH option [RFC3315] that would detect any form of 288 tampering with the DHCPv6 message contents. 290 A compromised DHCPv6 server or relay agent may insert configuration 291 information related to PvDs it is not authorized to advertise. e.g. 292 A coffee shop DHCPv6 server may provide configuration information 293 purporting to be from an enterprise and may try to attract enterprise 294 related traffic. The only real way to avoid this is that the PvD 295 container contains embedded authentication and authorization 296 information from the owner of the PvD. Then, this attack can be 297 detected by the client by verifying the authentication and 298 authorization information provided inside the PVD container option 299 after verifying its trust towards the PvD owner (e.g. a certificate 300 with a well-known/common trust anchor). 302 A compromised configuration source or an on-link attacker may try to 303 capture advertised configuration information and replay it on a 304 different link or at a future point in time. This can be avoided by 305 including some replay protection mechanism such as a timestamp or a 306 nonce inside the PvD container to ensure freshness of the provided 307 information. 309 9. IANA Considerations 311 This document defines three new DHCPv6 options to be allocated out of 312 the registry at http://www.iana.org/assignments/dhcpv6-parameters/ 314 OPTION_PVD (TBA1) 315 OPTION_PVD_ID (TBA2) 316 OPTION_PVD_AUTH (TBA3) 318 This document creates a new registry for PVD id types. The initial 319 values are listed below 321 0x01: UUID [RFC4122] 322 0x02: UTF-8 string 323 0x03: OID [OID] 324 0x03: NAI Realm [RFC4282] 326 10. Acknowledgements 328 The authors would like to thank the members of the MIF architecture 329 design team for their comments that led to the creation of this 330 draft. 332 11. Normative References 334 [I-D.anipko-mif-mpvd-arch] 335 Anipko, D., "Multiple Provisioning Domain Architecture", 336 draft-anipko-mif-mpvd-arch-04 (work in progress), 337 October 2013. 339 [OID] IANA, "PRIVATE ENTERPRISE NUMBERS", SMI Network Management 340 Private Enterprise Codes, http://www.iana.org/ 341 assignments/enterprise-numbers/enterprise-numbers. 343 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 344 Requirement Levels", BCP 14, RFC 2119, March 1997. 346 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 347 and M. Carney, "Dynamic Host Configuration Protocol for 348 IPv6 (DHCPv6)", RFC 3315, July 2003. 350 [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic 351 Host Configuration Protocol (DHCP) version 6", RFC 3633, 352 December 2003. 354 [RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally 355 Unique IDentifier (UUID) URN Namespace", RFC 4122, 356 July 2005. 358 [RFC4282] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The 359 Network Access Identifier", RFC 4282, December 2005. 361 [RFC6494] Gagliano, R., Krishnan, S., and A. Kukec, "Certificate 362 Profile and Certificate Management for SEcure Neighbor 363 Discovery (SEND)", RFC 6494, February 2012. 365 [RFC6495] Gagliano, R., Krishnan, S., and A. Kukec, "Subject Key 366 Identifier (SKI) SEcure Neighbor Discovery (SEND) Name 367 Type Fields", RFC 6495, February 2012. 369 Authors' Addresses 371 Suresh Krishnan 372 Ericsson 373 8400 Decarie Blvd. 374 Town of Mount Royal, QC 375 Canada 377 Phone: +1 514 345 7900 x42871 378 Email: suresh.krishnan@ericsson.com 380 Jouni Korhonen 381 Broadcom Communications 382 Porkkalankatu 24 383 FIN-00180 Helsinki 384 Finland 386 Email: jouni.nospam@gmail.com 388 Shwetha Bhandari 389 Cisco Systems 390 Cessna Business Park, Sarjapura Marathalli Outer Ring Road 391 Bangalore, KARNATAKA 560 087 392 India 394 Phone: +91 80 4426 0474 395 Email: shwethab@cisco.com