idnits 2.17.1 draft-ietf-mif-mpvd-dhcp-support-02.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 2 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 date (October 19, 2015) is 3111 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: 'I-D.ietf-mif-mpvd-id' is mentioned on line 151, but not defined == Missing Reference: 'RFC3971' is mentioned on line 205, but not defined == Unused Reference: 'RFC4122' is defined on line 379, but no explicit reference was found in the text == Unused Reference: 'RFC4282' is defined on line 384, but no explicit reference was found in the text ** 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 (~~), 5 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: April 21, 2016 Broadcom Corporation 6 S. Bhandari 7 Cisco Systems 8 October 19, 2015 10 Support for multiple provisioning domains in DHCPv6 11 draft-ietf-mif-mpvd-dhcp-support-02 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 21, 2016. 39 Copyright Notice 41 Copyright (c) 2015 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 57 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2 58 3. PVD Container option . . . . . . . . . . . . . . . . . . . . 3 59 4. PVD Identity option . . . . . . . . . . . . . . . . . . . . . 3 60 5. PVD Authentication and Authorization option . . . . . . . . . 4 61 5.1. Authentication is optional . . . . . . . . . . . . . . . 5 62 6. Set of allowable options . . . . . . . . . . . . . . . . . . 5 63 7. Behaviour of DHCPv6 entities . . . . . . . . . . . . . . . . 5 64 7.1. Client and Requesting Router Behavior . . . . . . . . . . 5 65 7.2. Relay Agent Behavior . . . . . . . . . . . . . . . . . . 6 66 7.3. Server and Delegating Router Behavior . . . . . . . . . . 6 67 8. Redistributing configuration information . . . . . . . . . . 7 68 9. Security Considerations . . . . . . . . . . . . . . . . . . . 7 69 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 70 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 71 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 72 12.1. Normative References . . . . . . . . . . . . . . . . . . 8 73 12.2. Informative References . . . . . . . . . . . . . . . . . 9 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 76 1. Introduction 78 The MIF working group is producing a solution to solve the issues 79 that are associated with nodes that can be attached to multiple 80 networks based on the Multiple Provisioning Domains (MPVD) 81 architecture work [RFC7556]. One part of the solution requires 82 associating configuration information with provisioning domains. 83 This document describes a DHCPv6 mechanism for explicitly indicating 84 provisioning domain information along with any configuration that 85 will be provided. The proposed mechanism uses a DHCPv6 option that 86 indicates the identity of the provisioning domain and encapsulates 87 the options that contain the configuration information as well as any 88 accompanying authentication/authorization information. 90 2. Terminology 92 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 93 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 94 document are to be interpreted as described in [RFC2119]. 96 3. PVD Container option 98 The PVD container option is used to encapsulate and group together 99 all the configuration options that belong to the explicitly 100 identified provisioning domain. The PVD container option MUST 101 encapsulate exactly one OPTION_PVD_ID. The PVD container option MAY 102 occur multiple times in the same message, but each of these PVD 103 container options MUST have a different PVD identity specified under 104 its PVD identity option. The PVD container option SHOULD contain at 105 most one (i.e. zero or one) OPTION_PVD_AUTH. 107 0 1 2 3 108 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 109 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 110 | OPTION_PVD | option-length | 111 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 112 | | 113 + encapsulated-options (variable length) . 114 . . 115 +---------------------------------------------------------------+ 117 Figure 1: PVD Container Option 119 o option-code: OPTION_PVD (TBA1) 121 o option-length: Length of encapsulated options 123 o encapsulated-options: options associated with this provisioning 124 domain. 126 4. PVD Identity option 128 The PVD identity option is used to explicitly indicate the identity 129 of the provisioning domain that is associated with the configuration 130 information encapsulated by the PVD container option. 132 0 1 2 3 133 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 134 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 135 | OPTION_PVD_ID | option-length | 136 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 137 | PVD identity information | 138 + (variable length) + 139 + + 140 . . 141 +---------------------------------------------------------------+ 143 Figure 2: PVD ID Option 145 o option-code: OPTION_PVD_ID (TBA2) 147 o option-length: Length of PVD identity information 149 o PVD identity information: The provisioning domain identity. 150 The contents of this field is defined in 151 a separate document [I-D.ietf-mif-mpvd-id]. 153 5. PVD Authentication and Authorization option 155 The PVD authentication and authorization option contains information 156 that could be used by the DHCPv6 client to verify whether the 157 configuration information provided was not tampered with by the 158 DHCPv6 server as well as establishing that the DHCPv6 server was 159 authorized to advertise the information on behalf of the PVD per 160 OPTION_PVD basis. The contents of the authentication/authorization 161 information is provided by the owner of the provisioning domain and 162 is completely opaque to the DHCPv6 server that passes along the 163 information unmodified. Every OPTION_PVD option SHOULD contain at 164 most one (i.e. zero or one) OPTION_PVD_AUTH option. If present, the 165 OPTION_PVD_AUTH option MUST be the last option inside the OPTION_PVD 166 option. 168 0 1 2 3 169 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 170 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 171 | OPTION_PVD_AUTH | option-length | 172 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ <+ 173 | name-type | key-hash : | 174 +-+-+-+-+-+-+-+-+ : | 175 : : 176 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Auth 177 : : info 178 : digital-signature : | 179 : : | 180 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ <+ 182 Figure 3: PVD Auth Option 184 o option-code: OPTION_PVD_AUTH (TBA3) 186 o option-length: Length of the Auth info 188 o name-type: Names the algorithm used to identify a specific 189 X.509 certificate using the method defined for the Subject Key 190 Identifier (SKI) extension for the X.509 certificates. The 191 usage and the Name Type registry aligns with the mechanism 192 defined for SeND [RFC6494][RFC6495]. 193 Name Type values starting 194 from 3 are supported and an implementation MUST at least support 195 SHA-1 (value 3). 197 o key-hash: A hash of the public key using the algorithm 198 identified by the Name Type. The procedure how the Key Hash is 199 calculated is defined in [RFC3971] and [RFC6495]. 201 o digital-signature: A signature calculated over the encapsulating 202 OPTION_PVD including all option data from the beginning of the 203 option while setting the digital-signature field to zero. The 204 procedure of calculating the signature is identical to the one 205 defined for SeND [RFC3971]. 207 5.1. Authentication is optional 209 The OPTION_PVD_AUTH will be sent only if it is requested in the 210 ORO.If the client does not request this option, it will not get a 211 signed PVD option. Clients that request the OPTION_PVD with the 212 intention of redistributing configuration information to other 213 clients (e.g. CPE routers) SHOULD NOT request the OPTION_PVD_AUTH in 214 the ORO. This allows them to send out a subset of the received 215 options to their clients and also allows them to support PVD unaware 216 clients by sending out the options without PVD information. 218 6. Set of allowable options 220 The PVD container option MAY be used to encapsulate any allocated 221 DHCPv6 options but MUST NOT be used to encapsulate another OPTION_PVD 222 option. 224 7. Behaviour of DHCPv6 entities 226 This section describes role of DHCPv6 entities involved in requesting 227 and receiving DHCPv6 configuration or prefix and address allocation. 229 7.1. Client and Requesting Router Behavior 231 DHCPv6 client or requesting router can request for configuration from 232 provisioning domain in the following ways: 234 o In the SOLICIT message it MAY include OPTION_PVD_ID requesting 235 configuration for the specific PVD ID indicated in the 236 OPTION_PVD_ID option. It can include multiple OPTION_PVD_ID 237 options to indicate its preference for more than one provisioning 238 domain. The PVD ID it requests is learnt via configuration or any 239 other out of band mechanism not defined in this document. 241 o In the SOLICIT message include an OPTION_ORO option with the 242 OPTION_PVD option code to request configuration from all the PVDs 243 that the DHCPv6 server can provide. 245 The client or requesting router parses OPTION_PVD options in the 246 response message. The Client or Requesting router MUST then include 247 all or subset of the received OPTION_PVD options in the REQUEST 248 message so that it will be responsible for the configuration 249 information selected. 251 If DHCPv6 client or requesting router receives OPTION_PVD options but 252 does not support PVD, it SHOULD ignore the received option(s). 254 7.2. Relay Agent Behavior 256 If the relay agent supports both the Relay-Supplied DHCP Option 257 (RSOO) [RFC6422] and the PVD, and it is configured to request 258 configuration data for clients in one or more provisioning domains, 259 then the relay agent MAY include the RSOO in the Relay-Forward 260 message. The RSOO MAY contain zero or more OPTION_PVD options. The 261 relay agent MUST NOT include any OPTION_PVD options into the RSOO 262 unless the client has indicated support for the PVD as described in 263 Section Section 7.1. 265 7.3. Server and Delegating Router Behavior 267 If the Server or Delegating router supports PVD and it is configured 268 to provide configuration data in one or more provisioning domains, it 269 selects configuration for the PVD based allocation in the following 270 way: 272 o If OPTION_PVD option code within OPTION_ORO is not present in the 273 request, it MUST NOT include provisioning domain based 274 configuration. It MAY select configuration and prefix allocation 275 from a default PVD defined. 277 o If OPTION_PVD_ID is included, it selects information to be offered 278 from that specific PVD if available. 280 o If OPTION_PVD option code within OPTION_ORO is included, then 281 based on its configuration and policy it MAY offer configuration 282 from the available PVD(s). 284 When PVD information and configuration are selected for address and 285 prefix allocation the server or delegating router responds with an 286 ADVERTISE message after populating OPTION_PVD. 288 If OPTION_PVD is not included, then the server or delegating router 289 MAY allocate the prefix and provide configuration as specified in 290 [RFC3315] and[RFC3633] and MUST NOT include OPTION_PVD option in the 291 response. 293 If OPTION_ORO option includes the OPTION_PVD option code but the 294 server or delegating router does not support PVD, then it SHOULD 295 ignore the OPTION_PVD and OPTION_PVD_ID options received. 297 If both client/requesting router and server/delegating router support 298 PVD but cannot offer configuration with PVD for any other reason, it 299 MUST respond to client/requesting router with appropriate status code 300 as specified in [RFC3315] and [RFC3633]. 302 Similarly, if the OPTION_PVD is received in the RSOO from the relay 303 agent the above described procedures apply for including the PVD 304 specific configuration information back to the client. 306 8. Redistributing configuration information 308 Clients that redistribute configuration information further to legacy 309 clients (e.g. homenet CPEs) after stripping out the PVD information 310 need to exercise caution when removing information from the PVD 311 containers and distributing them as top level options. Configuration 312 information that is consistent within a PVD container may not work 313 equally well when mixed with other top level configuration 314 information or information from other PVD containers. e.g. Using DNS 315 server information from one PVD container while using address/prefix 316 from another may lead to unexpected results. 318 9. Security Considerations 320 An attacker may attempt to modify the information provided inside the 321 PVD container option. These attacks can easily be prevented by using 322 the DHCPv6 AUTH option [RFC3315] that would detect any form of 323 tampering with the DHCPv6 message contents. 325 A compromised DHCPv6 server or relay agent may insert configuration 326 information related to PVDs it is not authorized to advertise. e.g. A 327 coffee shop DHCPv6 server may provide configuration information 328 purporting to be from an enterprise and may try to attract enterprise 329 related traffic. The only real way to avoid this is that the PVD 330 container contains embedded authentication and authorization 331 information from the owner of the PVD. Then, this attack can be 332 detected by the client by verifying the authentication and 333 authorization information provided inside the PVD container option 334 after verifying its trust towards the PVD owner (e.g. a certificate 335 with a well-known/common trust anchor). 337 A compromised configuration source or an on-link attacker may try to 338 capture advertised configuration information and replay it on a 339 different link or at a future point in time. This can be avoided by 340 including some replay protection mechanism such as a timestamp or a 341 nonce inside the PVD container to ensure freshness of the provided 342 information. 344 10. IANA Considerations 346 This document defines three new DHCPv6 options to be allocated out of 347 the registry at http://www.iana.org/assignments/dhcpv6-parameters/ 349 OPTION_PVD (TBA1) 350 OPTION_PVD_ID (TBA2) 351 OPTION_PVD_AUTH (TBA3) 353 This document also adds OPTION_PVD (TBA1) into the "Options Permitted 354 in the Relay-Supplied Options Option" registry at http://www.iana.org 355 /assignments/dhcpv6-parameters/ 357 11. Acknowledgements 359 The authors would like to thank the members of the MIF architecture 360 design team for their comments that led to the creation of this 361 draft. The authors would also thank Ian Farrer and Steven Barth for 362 their reviews and comments. 364 12. References 366 12.1. Normative References 368 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 369 Requirement Levels", BCP 14, RFC 2119, March 1997. 371 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 372 and M. Carney, "Dynamic Host Configuration Protocol for 373 IPv6 (DHCPv6)", RFC 3315, July 2003. 375 [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic 376 Host Configuration Protocol (DHCP) version 6", RFC 3633, 377 December 2003. 379 [RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally 380 Unique IDentifier (UUID) URN Namespace", RFC 4122, DOI 381 10.17487/RFC4122, July 2005, 382 . 384 [RFC4282] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The 385 Network Access Identifier", RFC 4282, DOI 10.17487/ 386 RFC4282, December 2005, 387 . 389 [RFC6422] Lemon, T. and Q. Wu, "Relay-Supplied DHCP Options", RFC 390 6422, DOI 10.17487/RFC6422, December 2011, 391 . 393 [RFC6494] Gagliano, R., Krishnan, S., and A. Kukec, "Certificate 394 Profile and Certificate Management for SEcure Neighbor 395 Discovery (SEND)", RFC 6494, DOI 10.17487/RFC6494, 396 February 2012, . 398 [RFC6495] Gagliano, R., Krishnan, S., and A. Kukec, "Subject Key 399 Identifier (SKI) SEcure Neighbor Discovery (SEND) Name 400 Type Fields", RFC 6495, DOI 10.17487/RFC6495, February 401 2012, . 403 12.2. Informative References 405 [RFC7556] Anipko, D., Ed., "Multiple Provisioning Domain 406 Architecture", RFC 7556, DOI 10.17487/RFC7556, June 2015, 407 . 409 Authors' Addresses 411 Suresh Krishnan 412 Ericsson 413 8400 Decarie Blvd. 414 Town of Mount Royal, QC 415 Canada 417 Phone: +1 514 345 7900 x42871 418 Email: suresh.krishnan@ericsson.com 420 Jouni Korhonen 421 Broadcom Corporation 422 3151 Zanker Road 423 San Jose, CA 95134 424 USA 426 Email: jouni.nospam@gmail.com 427 Shwetha Bhandari 428 Cisco Systems 429 Cessna Business Park, Sarjapura Marathalli Outer Ring Road 430 Bangalore, KARNATAKA 560 087 431 India 433 Phone: +91 80 4426 0474 434 Email: shwethab@cisco.com