idnits 2.17.1 draft-ietf-mif-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 (March 1, 2015) is 3337 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 150, but not defined == Missing Reference: 'RFC3971' is mentioned on line 203, but not defined == Unused Reference: 'RFC4122' is defined on line 350, but no explicit reference was found in the text == Unused Reference: 'RFC4282' is defined on line 354, 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) == Outdated reference: A later version (-11) exists of draft-ietf-mif-mpvd-arch-10 Summary: 3 errors (**), 0 flaws (~~), 6 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: September 2, 2015 Broadcom Corporation 6 S. Bhandari 7 Cisco Systems 8 March 1, 2015 10 Support for multiple provisioning domains in DHCPv6 11 draft-ietf-mif-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 September 2, 2015. 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 . . . . . . . . . . . . . . . . . . . . . . . . . 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. Relay Agent Behavior . . . . . . . . . . . . . . . . . . . 6 65 7.3. Server and Delegating Router Behavior . . . . . . . . . . . 7 66 8. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 67 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8 68 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8 69 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 70 11.1. Normative References . . . . . . . . . . . . . . . . . . . 8 71 11.2. Informative References . . . . . . . . . . . . . . . . . . 9 72 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 74 1. Introduction 76 The MIF working group is producing a solution to solve the issues 77 that are associated with nodes that can be attached to multiple 78 networks based on the Multiple Provisioning Domains (MPVD) 79 architecture work [I-D.ietf-mif-mpvd-arch]. One part of the solution 80 requires associating configuration information with provisioning 81 domains. This document describes a DHCPv6 mechanism for explicitly 82 indicating provisioning domain information along with any 83 configuration that will be provided. The proposed mechanism uses a 84 DHCPv6 option that indicates the identity of the provisioning domain 85 and encapsulates the options that contain the configuration 86 information as well as any accompanying authentication/authorization 87 information. 89 2. Terminology 91 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 92 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 93 document are to be interpreted as described in [RFC2119]. 95 3. PVD Container option 97 The PVD container option is used to encapsulate and group together 98 all the configuration options that belong to the explicitly 99 identified provisioning domain. The PVD container option MUST 100 encapsulate exactly one OPTION_PVD_ID. The PVD container option MAY 101 occur multiple times in the same message, but each of these PVD 102 container options MUST have a different PVD identity specified under 103 its PVD identity option. The PVD container option SHOULD contain 104 exactly one OPTION_PVD_AUTH. 106 0 1 2 3 107 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 108 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 109 | OPTION_PVD | option-length | 110 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 111 | | 112 + encapsulated-options (variable length) . 113 . . 114 +---------------------------------------------------------------+ 116 Figure 1: PVD Container Option 118 o option-code: OPTION_PVD (TBA1) 120 o option-length: Length of encapsulated options 122 o encapsulated-options: options associated with this provisioning 123 domain. 125 4. PVD Identity option 127 The PVD identity option is used to explicitly indicate the identity 128 of the provisioning domain that is associated with the configuration 129 information encapsulated by the PVD container option. 131 0 1 2 3 132 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 133 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 134 | OPTION_PVD_ID | option-length | 135 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 136 | PVD identity information | 137 + (variable length) + 138 + + 139 . . 140 +---------------------------------------------------------------+ 142 Figure 2: PVD ID Option 144 o option-code: OPTION_PVD_ID (TBA2) 146 o option-length: Length of PVD identity information 148 o PVD identity information: The provisioning domain identity. 149 The contents of this field is defined in 150 a separate document [I-D.ietf-mif-mpvd-id]. 152 5. PVD Authentication and Authorization option 154 The PVD authentication and authorization option contains information 155 that could be used by the DHCPv6 client to verify whether the 156 configuration information provided was not tampered with by the 157 DHCPv6 server as well as establishing that the DHCPv6 server was 158 authorized to advertise the information on behalf of the PVD per 159 OPTION_PVD basis. The contents of the authentication/authorization 160 information is provided by the owner of the provisioning domain and 161 is completely opaque to the DHCPv6 server that passes along the 162 information unmodified. Every OPTION_PVD option SHOULD contain at 163 most one OPTION_PVD_AUTH option. The OPTION_PVD_AUTH option MUST be 164 the last option inside the OPTION_PVD option. 166 0 1 2 3 167 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 168 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 169 | OPTION_PVD_AUTH | option-length | 170 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ <+ 171 | name-type | key-hash : | 172 +-+-+-+-+-+-+-+-+ : | 173 : : 174 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Auth 175 : : info 176 : digital-signature : | 177 : : | 178 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ <+ 180 Figure 3: PVD Auth Option 182 o option-code: OPTION_PVD_AUTH (TBA3) 184 o option-length: Length of the Auth info 186 o name-type: Names the algorithm used to identify a specific 187 X.509 certificate using the method defined for the Subject Key 188 Identifier (SKI) extension for the X.509 certificates. The 189 usage and the Name Type registry aligns with the mechanism 190 defined for SeND [RFC6494][RFC6495]. 191 Name Type values starting 192 from 3 are supported and an implementation MUST at least support 193 SHA-1 (value 3). 195 o key-hash: A hash of the public key using the algorithm 196 identified by the Name Type. The procedure how the Key Hash is 197 calculated is defined in [RFC3971] and [RFC6495]. 199 o digital-signature: A signature calculated over the encapsulating 200 OPTION_PVD including all option data from the beginning of the 201 option while setting the digital-signature field to zero. The 202 procedure of calculating the signature is identical to the one 203 defined for SeND [RFC3971]. 205 6. Set of allowable options 207 The PVD container option MAY be used to encapsulate any allocated 208 DHCPv6 options but MUST NOT be used to encapsulate another OPTION_PVD 209 option. [TODO: Should we add any other exclusions?] 211 7. Behaviour of DHCPv6 entities 213 This section describes role of DHCPv6 entities involved in requesting 214 and receiving DHCPv6 configuration or prefix and address allocation. 216 7.1. Client and Requesting Router Behavior 218 DHCPv6 client or requesting router can request for configuration from 219 provisioning domain in the following ways: 221 o In the SOLICIT message it MAY include OPTION_PVD_ID requesting 222 configuration for the specific PVD ID indicated in the 223 OPTION_PVD_ID option. It can include multiple OPTION_PVD_ID 224 options to indicate its preference for more than one provisioning 225 domain. The PVD ID it requests is learnt via configuration or any 226 other out of band mechanism not defined in this document. 227 o In the SOLICIT message include an OPTION_ORO option with the 228 OPTION_PVD option code to request configuration from all the PVDs 229 that the DHCPv6 server can provide. 230 The client or requesting router parses OPTION_PVD options in the 231 response message. The Client or Requesting router MUST then include 232 all or subset of the received OPTION_PVD options in the REQUEST 233 message so that it will be responsible for the configuration 234 information selected. 236 If DHCPv6 client or requesting router receives OPTION_PVD options but 237 does not support PVD, it SHOULD ignore the received option(s). 239 7.2. Relay Agent Behavior 241 If the relay agent supports both the Relay-Supplied DHCP Option 242 (RSOO) [RFC6422] and the PVD, and it is configured to request 243 configuration data for clients in one or more provisioning domains, 244 then the relay agent MAY include the RSOO in the Relay-Forward 245 message. The RSOO MAY contain zero or more OPTION_PVD options. The 246 relay agent MUST NOT include any OPTION_PVD options into the RSOO 247 unless the client has indicated support for the PVD as described in 248 Section Section 7.1. 250 7.3. Server and Delegating Router Behavior 252 If the Server or Delegating router supports PVD and it is configured 253 to provide configuration data in one or more provisioning domains, it 254 selects configuration for the PVD based allocation in the following 255 way: 257 o If OPTION_PVD option code within OPTION_ORO is not present in the 258 request, it MUST NOT include provisioning domain based 259 configuration. It MAY select configuration and prefix allocation 260 from a default PVD defined. 261 o If OPTION_PVD_ID is included, it selects information to be offered 262 from that specific PVD if available. 263 o If OPTION_PVD option code within OPTION_ORO is included, then 264 based on its configuration and policy it MAY offer configuration 265 from the available PVD(s). 266 When PVD information and configuration are selected for address and 267 prefix allocation the server or delegating router responds with an 268 ADVERTISE message after populating OPTION_PVD. 270 If OPTION_PVD is not included, then the server or delegating router 271 MAY allocate the prefix and provide configuration as specified in 272 [RFC3315] and[RFC3633] and MUST NOT include OPTION_PVD option in the 273 response. 275 If OPTION_ORO option includes the OPTION_PVD option code but the 276 server or delegating router does not support PVD, then it SHOULD 277 ignore the OPTION_PVD and OPTION_PVD_ID options received. 279 If both client/requesting router and server/delegating router support 280 PVD but cannot offer configuration with PVD for any other reason, it 281 MUST respond to client/requesting router with appropriate status code 282 as specified in [RFC3315] and [RFC3633]. 284 Similarly, if the OPTION_PVD is received in the RSOO from the relay 285 agent the above described procedures apply for including the PVD 286 specific configuration information back to the client. 288 8. Security Considerations 290 An attacker may attempt to modify the information provided inside the 291 PVD container option. These attacks can easily be prevented by using 292 the DHCPv6 AUTH option [RFC3315] that would detect any form of 293 tampering with the DHCPv6 message contents. 295 A compromised DHCPv6 server or relay agent may insert configuration 296 information related to PVDs it is not authorized to advertise. e.g. 298 A coffee shop DHCPv6 server may provide configuration information 299 purporting to be from an enterprise and may try to attract enterprise 300 related traffic. The only real way to avoid this is that the PVD 301 container contains embedded authentication and authorization 302 information from the owner of the PVD. Then, this attack can be 303 detected by the client by verifying the authentication and 304 authorization information provided inside the PVD container option 305 after verifying its trust towards the PVD owner (e.g. a certificate 306 with a well-known/common trust anchor). 308 A compromised configuration source or an on-link attacker may try to 309 capture advertised configuration information and replay it on a 310 different link or at a future point in time. This can be avoided by 311 including some replay protection mechanism such as a timestamp or a 312 nonce inside the PVD container to ensure freshness of the provided 313 information. 315 9. IANA Considerations 317 This document defines three new DHCPv6 options to be allocated out of 318 the registry at http://www.iana.org/assignments/dhcpv6-parameters/ 320 OPTION_PVD (TBA1) 321 OPTION_PVD_ID (TBA2) 322 OPTION_PVD_AUTH (TBA3) 324 This document also adds OPTION_PVD (TBA1) into the "Options Permitted 325 in the Relay-Supplied Options Option" registry at 326 http://www.iana.org/assignments/dhcpv6-parameters/ 328 10. Acknowledgements 330 The authors would like to thank the members of the MIF architecture 331 design team for their comments that led to the creation of this 332 draft. The authors would also thank Ian Farrer for his reviews and 333 comments. 335 11. References 337 11.1. Normative References 339 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 340 Requirement Levels", BCP 14, RFC 2119, March 1997. 342 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 343 and M. Carney, "Dynamic Host Configuration Protocol for 344 IPv6 (DHCPv6)", RFC 3315, July 2003. 346 [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic 347 Host Configuration Protocol (DHCP) version 6", RFC 3633, 348 December 2003. 350 [RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally 351 Unique IDentifier (UUID) URN Namespace", RFC 4122, 352 July 2005. 354 [RFC4282] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The 355 Network Access Identifier", RFC 4282, December 2005. 357 [RFC6422] Lemon, T. and Q. Wu, "Relay-Supplied DHCP Options", 358 RFC 6422, December 2011. 360 [RFC6494] Gagliano, R., Krishnan, S., and A. Kukec, "Certificate 361 Profile and Certificate Management for SEcure Neighbor 362 Discovery (SEND)", RFC 6494, February 2012. 364 [RFC6495] Gagliano, R., Krishnan, S., and A. Kukec, "Subject Key 365 Identifier (SKI) SEcure Neighbor Discovery (SEND) Name 366 Type Fields", RFC 6495, February 2012. 368 11.2. Informative References 370 [I-D.ietf-mif-mpvd-arch] 371 Anipko, D., "Multiple Provisioning Domain Architecture", 372 draft-ietf-mif-mpvd-arch-10 (work in progress), 373 February 2015. 375 Authors' Addresses 377 Suresh Krishnan 378 Ericsson 379 8400 Decarie Blvd. 380 Town of Mount Royal, QC 381 Canada 383 Phone: +1 514 345 7900 x42871 384 Email: suresh.krishnan@ericsson.com 385 Jouni Korhonen 386 Broadcom Corporation 387 3151 Zanker Road 388 San Jose, CA 95134 389 USA 391 Email: jouni.nospam@gmail.com 393 Shwetha Bhandari 394 Cisco Systems 395 Cessna Business Park, Sarjapura Marathalli Outer Ring Road 396 Bangalore, KARNATAKA 560 087 397 India 399 Phone: +91 80 4426 0474 400 Email: shwethab@cisco.com