idnits 2.17.1 draft-kk-mpvd-ndp-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 : ---------------------------------------------------------------------------- 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 (July 4, 2014) is 3584 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) == Outdated reference: A later version (-11) exists of draft-ietf-mif-mpvd-arch-01 Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IPv6 Maintenance J. Korhonen 3 Internet-Draft Broadcom 4 Intended status: Standards Track S. Krishnan 5 Expires: January 5, 2015 Ericsson 6 S. Gundavelli 7 Cisco Systems 8 July 4, 2014 10 Support for multiple provisioning domains in IPv6 Neighbor Discovery 11 Protocol 12 draft-kk-mpvd-ndp-support-02 14 Abstract 16 The MIF working group is producing a solution to solve the issues 17 that are associated with nodes that can be attached to multiple 18 networks. One part of the solution requires associating 19 configuration information with provisioning domains. This document 20 details how configuration information provided through IPv6 Neighbor 21 Discovery Protocol can be associated with provisioning domains. 23 Status of this Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on January 5, 2015. 40 Copyright Notice 42 Copyright (c) 2014 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 3. PVD Container option . . . . . . . . . . . . . . . . . . . . . 3 60 4. PVD Identity option . . . . . . . . . . . . . . . . . . . . . 6 61 5. Set of allowable options . . . . . . . . . . . . . . . . . . . 7 62 6. Security Considerations . . . . . . . . . . . . . . . . . . . 7 63 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 64 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8 65 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 66 9.1. Normative References . . . . . . . . . . . . . . . . . . . 8 67 9.2. Informative References . . . . . . . . . . . . . . . . . . 8 68 Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 8 69 A.1. One implicit PVD and one explicit PVD . . . . . . . . . . 9 70 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 72 1. Introduction 74 The MIF working group is producing a solution to solve the issues 75 that are associated with nodes that can be attached to multiple 76 networks based on the Multiple Provisioning Domains (MPVD) 77 architecture work [I-D.ietf-mif-mpvd-arch]. One part of the solution 78 requires associating configuration information with Provisioning 79 Domains (PVD). This document describes an IPv6 Neighbor Discovery 80 Protocol (NDP) [RFC4861] mechanism for explicitly indicating 81 provisioning domain information along with any configuration that 82 will be provided. The proposed mechanism uses an NDP option that 83 indicates the identity of the provisioning domain and encapsulates 84 the options that contain the configuration information as well as any 85 accompanying authentication/authorization information. The solution 86 defined in this document aligns as much as possible with the existing 87 IPv6 Neighbor Discovery security, namely with Secure Neighbor 88 Discovery (SeND) [RFC3971]. 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 (PVD_CO) is used to mark the start of the 99 configuration options that belong to the explicitly identified 100 provisioning domain. The PVD container option MUST encapsulate 101 exactly one PVD identifier option (PVD_ID, see Section 4). The PVD 102 container option MAY occur multiple times in the same NDP message but 103 each of these PVD container options MUST have a different PVD 104 identity specified under its PVD identity option. The PVD container 105 options MUST NOT be nested. 107 A PVD container is intended to be used in IPv6 Router Advertisement 108 (RA) NDP messages. However, including a PVD container or identity 109 options inside a Router Solicitation (RS) NDP messages is also 110 possible (actually, in this way a host can solicit for information 111 from a specific provisioning domain). The PVD container option MUST 112 NOT be included in a NDP message without accompanying PVD identity 113 option (see Section 4). If, for some reason, the NDP message does 114 not include the accompanying PVD identity option, then the 115 implementation MUST ignore the PVD container option and SHOULD log 116 the event. The PVD container MUST NOT be fragmented i.e., should the 117 IPv6 packet be fragmented, the PVD container and the accompanying PVD 118 identity MUST both be inside the same fragment. 120 Since implementations are required to ignore any unrecognized options 121 [RFC4861], the backward compatibility and the reuse of existing NDP 122 options is implicitly enabled. Implementations that do not recognize 123 the PVD container option plain ignore it and also skip PVD container 124 option "encapsulated" NDP options normally without associating them 125 into any provisioning domain (since the implementation has no notion 126 of provisioning domains). For example, the PVD container could 127 "encapsulate" a Prefix Information Option (PIO), which would mark 128 that this certain advertised IPv6 prefix belongs and originates from 129 a specific provisioning domain. However, if the implementation does 130 not understand provisioning domains, then this specific PIO is also 131 skipped and not configured to the interface. 133 The optional security for the PVD container is based on X.509 134 certificates [RFC6487] and reuses mechanisms already defined for SeND 135 [RFC3971] [RFC6495]. However, the use of PVD containers does not 136 assume or depend on SeND being deployed or even implemented. The PVD 137 containers SHOULD be signed per PVD certificates, which provides both 138 integrity protection and proves that the configuration information 139 source is authorized for advertising the given information. See 140 [RFC6494] for discussion how to enable deployments where the 141 certificates needed to sign PVD containers) belong to different 142 administrative domains i.e. to different provisioning domains. 144 0 1 2 3 145 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 146 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 147 | Type=PVD_CO | Length |S| Reserved | Name Type | 148 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 149 : : 150 : Key Hash (optional) : 151 : : 152 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 153 : : 154 : Digital Signature (optional) : 155 : : 156 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 157 | Possible zero padding to ensure 8 octets alignment | 158 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 160 Figure 1: PVD Container Option 162 Type 164 PVD Container; Set to TBD1. 166 Length 168 Length of the PVD_CO. The actual length depends on the number of 169 "encapsulated" NDP options, the length of the PVD identifier 170 option and the optional Key Hash/Digital Signature/Padding. 172 S 174 Security enabled/disabled flag. If S=0 then security (signing) 175 of the PVD_CO is disabled. If S=1 then security (signing) is 176 enabled. 178 Name Type 180 Names the algorithm used to identify a specific X.509 certificate 181 using the method defined for the Subject Key Identifier (SKI) 182 extension for the X.509 certificates. The usage and the Name 183 Type registry aligns with the mechanism defined for SeND 184 [RFC6495]. Name Type values starting from 3 are supported and an 185 implementation MUST at least support SHA-1 (value 3). Note that 186 if S=0 the Name field serves no use. 188 Key Hash 190 This field is only present when S=1. A hash of the public key 191 using the algorithm identified by the Name Type. The procedure 192 how the Key Hash is calculated is defined in [RFC3971] and 193 [RFC6495]. 195 Digital Signature 197 This field is only present when S=1. A signature calculated over 198 the PVD_CO option including all option data from the beginning of 199 the option until to the end of the container. The procedure of 200 calculating the signature is identical to the one defined for 201 SeND [RFC3971]. During the signature calculation the contents of 202 the Digital Signature option MUST be treated as all zero. 204 Implementations MUST ensure that the PVD container option meets the 8 205 octets NDP option alignment requirement. This MAY imply adding 206 padding zero octets to the tail of the PVD container option until the 207 alignment requirement has been met. The padding is independent of 208 the 'S' flag setting. 210 If the PVD_CO does not contain a digital signature, then other means 211 to secure the integrity of the NDP message SHOULD be provided, such 212 as utilizing SeND. However, the security provided by SeND is for the 213 entire NDP message and does not allow verifying whether the sender of 214 the NDP message is actually authorized for the information for the 215 provisioning domain. 217 If the PVD_CO contains a signature and the verification fails, then 218 the whole PVD_CO, PVD_ID and other NDP options MUST be silently 219 ignored and the event SHOULD be logged. 221 4. PVD Identity option 223 The PVD identity option (PVD_ID) is used to explicitly indicate the 224 identity of the provisioning domain that is associated with the 225 configuration information encapsulated by the PVD container option. 226 A PVD container option MUST have exactly one PVD identity option. 227 However, the PVD identity option MAY also be included in a NDP 228 message without the PVD container option. In this case it merely 229 serves as a hint of provisioning domain and could, for example, be 230 used in an RS message to solicit information from specific 231 provisioning domains. 233 0 1 2 3 234 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 235 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 236 | Type=PVD_ID | Length | Identity ~ 237 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 239 Figure 2: PVD_ID Option 241 Type 243 PVD identifier; Set to TBD2. 245 Length 247 Length of the PVD_ID. 249 Identity 251 The provisioning domain identity. The contents of this field is 252 defined in a separate document [I-D.kkbg-mpvd-id]. Note that the 253 Identity field may need to be zero padded at the tail to meets 254 the natural NDP options' alignment. 256 If the receiver of the PVD identity option does not understand any of 257 the ID-Types, then anything belonging to this provisioning domain 258 MUST be silently discarded. This would mean the PVD identity option, 259 the PVD container option and all other options. 261 5. Set of allowable options 263 The PVD container option MAY be used to encapsulate any allocated 264 IPv6 NDP options, which may appear more than once in a NDP message. 265 The PVD container option MUST NOT be used to encapsulate other PVD_CO 266 option(s). 268 6. Security Considerations 270 An attacker may attempt to modify the information provided inside the 271 PVD container option. These attacks can easily be prevented by using 272 SeND [RFC3971] or per PVD container signature that would detect any 273 form of tampering with the IPv6 NDP message contents. 275 A compromised router may advertise configuration information related 276 to provisioning domains it is not authorized to advertise. e.g. A 277 coffee shop router may provide configuration information purporting 278 to be from an enterprise and may try to attract enterprise related 279 traffic. The only real way to avoid this is that the provisioning 280 domain container contains embedded authentication and authorization 281 information from the owner of the provisioning domain. Then, this 282 attack can be detected by the client by verifying the authentication 283 and authorization information provided inside the PVD container 284 option after verifying its trust towards the provisioning domain 285 owner (e.g. a certificate with a well-known/common trust anchor). 287 A compromised configuration source or an on-link attacker may try to 288 capture advertised configuration information and replay it on a 289 different link or at a future point in time. This can be avoided by 290 including some replay protection mechanism such as a timestamp or a 291 nonce inside the PVD container to ensure freshness of the provided 292 information. This specification does not define a replay protection 293 solution. Rather it is assumed that if replay protection is 294 required, the access network and hosts also deploy existing security 295 solutions such as SeND [RFC3971]. 297 7. IANA Considerations 299 This document defines two new IPv6 NDP options into the "IPv6 300 Neighbor Discovery Option Formats" registry. The options TBD1 and 301 TBD2 are described in Section 3 and Section 4. 303 8. Acknowledgements 305 The authors would like to thank the members of the MIF architecture 306 design team for their comments that led to the creation of this 307 draft. 309 9. References 311 9.1. Normative References 313 [I-D.kkbg-mpvd-id] 314 Krishnan, S., Korhonen, J., Bhandari, S., and S. 315 Gundavelli, "Identification of provisioning domains", 316 draft-kkbg-mpvd-id-00 (work in progress), February 2014. 318 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 319 Requirement Levels", BCP 14, RFC 2119, March 1997. 321 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 322 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 323 September 2007. 325 [RFC6494] Gagliano, R., Krishnan, S., and A. Kukec, "Certificate 326 Profile and Certificate Management for SEcure Neighbor 327 Discovery (SEND)", RFC 6494, February 2012. 329 [RFC6495] Gagliano, R., Krishnan, S., and A. Kukec, "Subject Key 330 Identifier (SKI) SEcure Neighbor Discovery (SEND) Name 331 Type Fields", RFC 6495, February 2012. 333 9.2. Informative References 335 [I-D.ietf-mif-mpvd-arch] 336 Anipko, D., "Multiple Provisioning Domain Architecture", 337 draft-ietf-mif-mpvd-arch-01 (work in progress), May 2014. 339 [RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure 340 Neighbor Discovery (SEND)", RFC 3971, March 2005. 342 [RFC6487] Huston, G., Michaelson, G., and R. Loomans, "A Profile for 343 X.509 PKIX Resource Certificates", RFC 6487, 344 February 2012. 346 Appendix A. Examples 347 A.1. One implicit PVD and one explicit PVD 349 Figure 3 shows how the NDP options are laid out in an RA for one 350 implicit provisioning domain and one explicit provisioning domain. 351 The example does not include security (and signing of the PVD 352 container). The assumption is the PVD identity consumes 14 octets. 354 The explicit provisioning domain ("starducks.example.com" in a NAI 355 Realm format) contains a specific PIO for 2001:db8:abad:cafe::/64 and 356 the MTU of 1337 octets. The implicit provisioning domain configures 357 a prefix 2001:db8:cafe:babe::/64 and the link MTU of 1500 octets. 358 There are two cases: 1) the host receiving the RA implements 359 provisioning domains and 2) the host does not understand provisioning 360 domains. 362 1. The host recognizes the PVD_CO and "starts" a provisioning domain 363 specific configuration. Security is disabled, thus there are no 364 Key Hash or Digital Signature fields to process. The prefix 365 2001:db8:abad:cafe::/64 is found and configured on the interface. 366 Once the PVD_ID option is located the interface prefix 367 configuration for 2001:db8:abad:cafe::/64 and the MTU of 1337 368 octets can be associated to the provisioning domain found in the 369 PVD_ID option. 371 The rest of the options are parsed and configured into the 372 implicit provisioning domain since there is no encapsulating 373 provisioning domain. The interface is configured with prefix 374 2001:db8:cafe:babe::/64. The implicit provisioning domain uses 375 the link MTU of 1500 octets, whereas the "starducks.example.com" 376 provisioning domain uses the MTU of 1337 octets (this means when 377 packets are sourced using 2001:db8:abad:cafe::/64 prefix the link 378 MTU is different than when sourcing packets using 2001:db8:cafe: 379 babe::/64 prefix). 381 2. The host ignores the PVD_CO (including the PVD_ID and other 382 options) and ends up configuring one prefix on its interface ( 383 2001:db8:cafe:babe::/64) with a link MTU of 1500 octets. 385 0 1 2 3 386 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 387 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 388 | 134 | 0 | Checksum | 389 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 390 | Cur Hop Limit |0|1| Reserved | Router Lifetime | 391 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 392 | Reachable Time | 393 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 394 | Retrans Timer | 395 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ <+ 396 | Type=PVD_CO | 10 |0| Reserved | 0 | | 397 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 398 | 0 | | 399 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 400 | 3 | 4 | 64 |1|1| Reserved1 | | 401 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 402 | Valid Lifetime | P 403 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ V 404 | Preferred Lifetime | D 405 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 406 | Reserved2 | | 407 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 408 | 2001:db8:abad:cafe:: ~ | 409 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 410 | Type=PVD_ID | 4 | id-type=4 | 21 | | 411 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 412 ~ "starducks.example.com",'\0','\0','\0','\0','\0','\0','\0' | | 413 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 414 | 5 | 1 | Reserved | | 415 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 416 | 1337 | | 417 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ <+ 418 | 3 | 4 | Prefix Length |1|1| Reserved1 | 419 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 420 | Valid Lifetime | 421 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 422 | Preferred Lifetime | 423 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 424 | Reserved2 | 425 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 426 | 2001:db8:cafe:babe:: ~ 427 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 428 | 5 | 1 | Reserved | 429 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 430 | 1500 | 431 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 432 Figure 3: An RA with one implicit PVD and one explicit PVD 434 Authors' Addresses 436 Jouni Korhonen 437 Broadcom 438 Porkkalankatu 24 439 FIN-00180 Helsinki 440 Finland 442 Email: jouni.nospam@gmail.com 444 Suresh Krishnan 445 Ericsson 446 8400 Decarie Blvd. 447 Town of Mount Royal, QC 448 Canada 450 Phone: +1 514 345 7900 x42871 451 Email: suresh.krishnan@ericsson.com 453 Sri Gundavelli 454 Cisco Systems 455 170 West Tasman Drive 456 San Jose, CA 95134 457 USA 459 Email: sgundave@cisco.com