idnits 2.17.1 draft-kkb-mpvd-dhcp-support-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 : ---------------------------------------------------------------------------- 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 (February 13, 2014) is 3697 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 199, but not defined == Unused Reference: 'RFC4122' is defined on line 336, but no explicit reference was found in the text == Unused Reference: 'RFC4282' is defined on line 340, but no explicit reference was found in the text ** Downref: Normative reference to an Informational draft: draft-anipko-mif-mpvd-arch (ref. 'I-D.anipko-mif-mpvd-arch') ** 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 (~~), 4 warnings (==), 1 comment (--). 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: August 17, 2014 Broadcom 6 S. Bhandari 7 Cisco Systems 8 February 13, 2014 10 Support for multiple provisioning domains in DHCPv6 11 draft-kkb-mpvd-dhcp-support-01 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 August 17, 2014. 39 Copyright Notice 41 Copyright (c) 2014 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 . . . . . . . . . . 4 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 . . . . . . . . . . . 6 65 8. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 66 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8 67 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8 68 11. Normative References . . . . . . . . . . . . . . . . . . . . . 8 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 | 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 145 o PVD identity information: The provisioning domain identity. 146 The contents of this field is defined in 147 a separate document [PVDIDS]. 149 5. PVD Authentication and Authorization option 151 The PVD authentication and authorization option contains information 152 that could be used by the DHCPv6 client to verify whether the 153 configuration information provided was not tampered with by the 154 DHCPv6 server as well as establishing that the DHCPv6 server was 155 authorized to advertise the information on behalf of the PVD per 156 OPTION_PVD basis. The contents of the authentication/authorization 157 information is provided by the owner of the provisioning domain and 158 is completely opaque to the DHCPv6 server that passes along the 159 information unmodified. Every OPTION_PVD option SHOULD contain at 160 most one OPTION_PVD_AUTH option. The OPTION_PVD_AUTH option MUST be 161 the last option inside the OPTION_PVD option. 163 0 1 2 3 164 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 165 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 166 | OPTION_PVD_AUTH | option-length | 167 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ <+ 168 | name-type | key-hash : | 169 +-+-+-+-+-+-+-+-+ : | 170 : : 171 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Auth 172 : : info 173 : digital-signature : | 174 : : | 175 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ <+ 177 Figure 3: PVD Auth Option 179 o option-code: OPTION_PVD_AUTH (TBA3) 181 o option-length: Length of the Auth info 183 o name-type: Names the algorithm used to identify a specific 184 X.509 certificate using the method defined for the Subject Key 185 Identifier (SKI) extension for the X.509 certificates. The 186 usage and the Name Type registry aligns with the mechanism 187 defined for SeND [RFC6494][RFC6495]. Name Type values starting 188 from 3 are supported and an implementation MUST at least support 189 SHA-1 (value 3). 191 o key-hash: A hash of the public key using the algorithm 192 identified by the Name Type. The procedure how the Key Hash is 193 calculated is defined in [RFC3971] and [RFC6495] 195 o digital-signature: A signature calculated over the encapsulating 196 OPTION_PVD including all option data from the beginning of the 197 option while setting the digital-signature field to zero. The 198 procedure of calculating the signature is identical to the one 199 defined for SeND [RFC3971]. 201 [TODO: There may be some alignment considerations here for some 202 implementations as DHCPv6 options are not aligned.] 204 6. Set of allowable options 206 The PVD container option MAY be used to encapsulate any allocated 207 DHCPv6 options but MUST NOT be used to encapsulate another OPTION_PVD 208 option. [TODO: Should we add any other exclusions?] 210 7. Behaviour of DHCPv6 entities 212 This section describes role of DHCPv6 entities involved in requesting 213 and receiving DHCPv6 configuration or prefix and address allocation. 215 7.1. Client and Requesting Router Behavior 217 DHCPv6 client or requesting router can request for configuration from 218 provisioning domain in the following ways: 220 o In the SOLICIT message it MAY include OPTION_PVD_ID requesting 221 configuration for the specific PVD ID indicated in the 222 OPTION_PVD_ID option. It can include multiple OPTION_PVD_ID 223 options to indicate its preference for more than one provisioning 224 domain. The PVD ID it requests is learnt via configuration or any 225 other out of band mechanism not defined in this document. 226 o In the SOLICIT message include an OPTION_ORO option with the 227 OPTION_PVD option code to request configuration from all the PVDs 228 that the DHCPv6 server can provide. 229 The client or requesting router parses OPTION_PVD options in the 230 response message. The Client or Requesting router MUST then include 231 all or subset of the received OPTION_PVD options in the REQUEST 232 message so that it will be responsible for the configuration 233 information selected. 235 If DHCPv6 client or requesting router receives OPTION_PVD options but 236 does not support PVD, it SHOULD ignore the received option(s). 238 7.2. Server and Delegating Router Behavior 240 If the Server or Delegating router supports PVD and it is configured 241 to provide configuration data in one or more provisioning domains, it 242 selects configuration for the PVD based allocation in the following 243 way: 245 o If OPTION_PVD option code within OPTION_ORO is not present in the 246 request, it MUST NOT include provisioning domain based 247 configuration. It MAY select configuration and prefix allocation 248 from a default PVD defined. 250 o If OPTION_PVD_ID is included, it selects information to be offered 251 from that specific PVD if available. 252 o If OPTION_PVD option code within OPTION_ORO is included, then 253 based on its configuration and policy it MAY offer configuration 254 from the available PVD(s). 255 When PVD information and configuration are selected for address and 256 prefix allocation the server or delegating router responds with an 257 ADVERTISE message after populating OPTION_PVD. 259 If OPTION_PVD is not included, then the server or delegating router 260 MAY allocate the prefix and provide configuration as specified in 261 [RFC3315] and[RFC3633] and MUST NOT include OPTION_PVD option in the 262 response. 264 If OPTION_ORO option includes the OPTION_PVD option code but the 265 server or delegating router does not support PVD, then it SHOULD 266 ignore the OPTION_PVD and OPTION_PVD_ID options received. 268 If both client/requesting router and server/delegating router support 269 PVD but cannot offer configuration with PVD for any other reason, it 270 MUST respond to client/requesting router with appropriate status code 271 as specified in [RFC3315] and [RFC3633]. 273 8. Security Considerations 275 An attacker may attempt to modify the information provided inside the 276 PVD container option. These attacks can easily be prevented by using 277 the DHCPv6 AUTH option [RFC3315] that would detect any form of 278 tampering with the DHCPv6 message contents. 280 A compromised DHCPv6 server or relay agent may insert configuration 281 information related to PvDs it is not authorized to advertise. e.g. 282 A coffee shop DHCPv6 server may provide configuration information 283 purporting to be from an enterprise and may try to attract enterprise 284 related traffic. The only real way to avoid this is that the PvD 285 container contains embedded authentication and authorization 286 information from the owner of the PvD. Then, this attack can be 287 detected by the client by verifying the authentication and 288 authorization information provided inside the PVD container option 289 after verifying its trust towards the PvD owner (e.g. a certificate 290 with a well-known/common trust anchor). 292 A compromised configuration source or an on-link attacker may try to 293 capture advertised configuration information and replay it on a 294 different link or at a future point in time. This can be avoided by 295 including some replay protection mechanism such as a timestamp or a 296 nonce inside the PvD container to ensure freshness of the provided 297 information. 299 9. IANA Considerations 301 This document defines three new DHCPv6 options to be allocated out of 302 the registry at http://www.iana.org/assignments/dhcpv6-parameters/ 304 OPTION_PVD (TBA1) 305 OPTION_PVD_ID (TBA2) 306 OPTION_PVD_AUTH (TBA3) 308 10. Acknowledgements 310 The authors would like to thank the members of the MIF architecture 311 design team for their comments that led to the creation of this 312 draft. 314 11. Normative References 316 [I-D.anipko-mif-mpvd-arch] 317 Anipko, D., "Multiple Provisioning Domain Architecture", 318 draft-anipko-mif-mpvd-arch-05 (work in progress), 319 November 2013. 321 [PVDIDS] Krishnan, S., Korhonen, J., Bhandari, S., and S. 322 Gundavelli, "Identification of provisioning domains", 323 draft-kkbg-mpvd-id-00 (work in progress), February 2014. 325 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 326 Requirement Levels", BCP 14, RFC 2119, March 1997. 328 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 329 and M. Carney, "Dynamic Host Configuration Protocol for 330 IPv6 (DHCPv6)", RFC 3315, July 2003. 332 [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic 333 Host Configuration Protocol (DHCP) version 6", RFC 3633, 334 December 2003. 336 [RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally 337 Unique IDentifier (UUID) URN Namespace", RFC 4122, 338 July 2005. 340 [RFC4282] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The 341 Network Access Identifier", RFC 4282, December 2005. 343 [RFC6494] Gagliano, R., Krishnan, S., and A. Kukec, "Certificate 344 Profile and Certificate Management for SEcure Neighbor 345 Discovery (SEND)", RFC 6494, February 2012. 347 [RFC6495] Gagliano, R., Krishnan, S., and A. Kukec, "Subject Key 348 Identifier (SKI) SEcure Neighbor Discovery (SEND) Name 349 Type Fields", RFC 6495, February 2012. 351 Authors' Addresses 353 Suresh Krishnan 354 Ericsson 355 8400 Decarie Blvd. 356 Town of Mount Royal, QC 357 Canada 359 Phone: +1 514 345 7900 x42871 360 Email: suresh.krishnan@ericsson.com 362 Jouni Korhonen 363 Broadcom Communications 364 Porkkalankatu 24 365 FIN-00180 Helsinki 366 Finland 368 Email: jouni.nospam@gmail.com 370 Shwetha Bhandari 371 Cisco Systems 372 Cessna Business Park, Sarjapura Marathalli Outer Ring Road 373 Bangalore, KARNATAKA 560 087 374 India 376 Phone: +91 80 4426 0474 377 Email: shwethab@cisco.com