idnits 2.17.1 draft-ietf-mif-mpvd-ndp-support-03.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 25, 2016) is 2980 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) No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MIF J. Korhonen 3 Internet-Draft Broadcom Limited 4 Intended status: Standards Track S. Krishnan 5 Expires: August 28, 2016 Ericsson 6 S. Gundavelli 7 Cisco Systems 8 February 25, 2016 10 Support for multiple provisioning domains in IPv6 Neighbor Discovery 11 Protocol 12 draft-ietf-mif-mpvd-ndp-support-03 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 August 28, 2016. 40 Copyright Notice 42 Copyright (c) 2016 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 58 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2 59 3. PVD Container option . . . . . . . . . . . . . . . . . . . . 3 60 4. Set of allowable options . . . . . . . . . . . . . . . . . . 5 61 5. Security Considerations . . . . . . . . . . . . . . . . . . . 6 62 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 63 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 64 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 65 8.1. Normative References . . . . . . . . . . . . . . . . . . 6 66 8.2. Informative References . . . . . . . . . . . . . . . . . 7 67 Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 7 68 A.1. One implicit PVD and one explicit PVD . . . . . . . . . . 8 69 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 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 [RFC7556]. One part of the solution requires 77 associating configuration information with Provisioning Domains 78 (PVD). This document describes an IPv6 Neighbor Discovery Protocol 79 (NDP) [RFC4861] mechanism for explicitly indicating provisioning 80 domain information along with any configuration which is associated 81 with that provisioning domain. The proposed mechanism uses an NDP 82 option that indicates the identity of the provisioning domain and 83 encapsulates the options that contain the configuration information 84 as well as optional authentication/authorization information. The 85 solution defined in this document aligns as much as possible with the 86 existing IPv6 Neighbor Discovery security, namely with Secure 87 Neighbor Discovery (SeND) [RFC3971]. 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 (PVD_CO) is used to encapsulate the 98 configuration options that belong to the explicitly identified 99 provisioning domain. The PVD container option always encapsulates 100 exactly one PVD identity. The PVD container option MAY occur 101 multiple times in a Router Advertisement (RA) message. In this case 102 each PVD container MUST belong to a different provisioning domain. 103 The PVD container options MUST NOT be nested. The PVD Container 104 option is defined only for the RA NDP message. 106 Since implementations are required to ignore any unrecognized options 107 [RFC4861], the backward compatibility and the reuse of existing NDP 108 options is implicitly enabled. Implementations that do not recognize 109 the PVD container option will ignore it, and any PVD container option 110 "encapsulated" NDP options without associating them into any 111 provisioning domain (since the implementation has no notion of 112 provisioning domains). For example, the PVD container could 113 "encapsulate" a Prefix Information Option (PIO), which would mark 114 that this certain advertised IPv6 prefix belongs and originates from 115 a specific provisioning domain. However, if the implementation does 116 not understand provisioning domains, then this specific PIO is also 117 skipped and not configured on the interface. 119 The optional security for the PVD container is based on X.509 120 certificates [RFC6487] and reuses mechanisms already defined for SeND 121 [RFC3971] [RFC6495]. However, the use of PVD containers does not 122 assume or depend on SeND being deployed or even implemented. The PVD 123 containers SHOULD be signed per PVD certificates, which provides both 124 integrity protection and proves that the configuration information 125 source is authorized for advertising the given information. See 126 [RFC6494] for discussion how to enable deployments where the 127 certificates needed to sign PVD containers belong to different 128 administrative domains i.e., to different provisioning domains. 130 0 1 2 3 131 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 132 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 133 | Type=PVD_CO | Length | Name Type | r | Sec 134 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 135 Length | ID Length | Key Hash (optional) ~ 136 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 137 ~ Digital Signature (optional) ~ 138 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 139 | PVD Identity ~ 140 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 141 ~ Possible zero padding to ensure 8 octets alignment | 142 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 143 ~ Zero or more "encapsulated" NDP options ~ 144 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 146 Figure 1: PVD Container Option 148 Type 150 PVD Container; Set to TBD1. 152 Length 154 Length of the PVD_CO. The actual length depends on the number of 155 "encapsulated" NDP options, length of the PVD Identity, and the 156 optional Key Hash/Digital Signature/Padding. 158 Name Type 160 Names the algorithm used to identify a specific X.509 certificate 161 using the method defined for the Subject Key Identifier (SKI) 162 extension for the X.509 certificates. The usage and the Name 163 Type registry aligns with the mechanism defined for SeND 164 [RFC6495]. Name Type values starting from 3 are supported and an 165 implementation MUST at least support SHA-1 (value 3). Note that 166 if Sec Length=0 the Name field serves no use and MUST be set to 167 0. 169 r 171 Reserved. MUST be set to 0 and ignored when received. 173 Sec Length 175 11-bit length of the Key Hash and Digital Signature in a units of 176 1 octet. When no security is enabled the Sec Length MUST be set 177 to value of 0. 179 ID Length 181 11-bit length of the PVD Identity in a units of 1 octet. The ID 182 Length MUST be greater than 0. 184 Key Hash 186 This field is only present when Sec Length>0. A hash of the 187 public key using the algorithm identified by the Name Type. The 188 procedure how the Key Hash is calculated is defined in [RFC3971] 189 and [RFC6495]. 191 Digital Signature 193 This field is only present when Sec Length>0. A signature 194 calculated over the PVD_CO option including all option data from 195 the beginning of the option until to the end of the container. 196 The procedure of calculating the signature is identical to the 197 one defined for SeND [RFC3971]. During the signature calculation 198 the contents of the Digital Signature option MUST be treated as 199 all zero. 201 PVD Identity 203 The provisioning domain identity. The contents of this field is 204 defined in a separate document [I-D.ietf-mif-mpvd-id]. 206 Implementations MUST ensure that the PVD container option meets the 8 207 octets NDP option alignment requirement as described in [RFC4861]. 209 If the PVD_CO does not contain a digital signature, then other means 210 to secure the integrity of the NDP message SHOULD be provided, such 211 as utilizing SeND. However, the security provided by SeND is for the 212 entire NDP message and does not allow verifying whether the sender of 213 the NDP message is actually authorized for the information for the 214 provisioning domain. 216 If the PVD_CO contains a signature and the verification fails, then 217 the whole PVD_CO option MUST be silently ignored and the event SHOULD 218 be logged. 220 4. Set of allowable options 222 The PVD container option MAY be used to encapsulate any allocated 223 IPv6 NDP options, which may appear more than once in a NDP message. 224 The PVD container option MUST NOT be used to encapsulate other PVD_CO 225 option(s). 227 5. Security Considerations 229 An attacker may attempt to modify the information provided inside the 230 PVD container option. These attacks can easily be prevented by using 231 SeND [RFC3971] or per PVD container signature that would detect any 232 form of tampering with the IPv6 NDP message contents. 234 A compromised router may advertise configuration information related 235 to provisioning domains it is not authorized to advertise. e.g. A 236 coffee shop router may provide configuration information purporting 237 to be from an enterprise and may try to attract enterprise related 238 traffic. The only real way to avoid this is that the provisioning 239 domain container contains embedded authentication and authorization 240 information from the owner of the provisioning domain. Then, this 241 attack can be detected by the client by verifying the authentication 242 and authorization information provided inside the PVD container 243 option after verifying its trust towards the provisioning domain 244 owner (e.g. a certificate with a well-known/common trust anchor). 246 A compromised configuration source or an on-link attacker may try to 247 capture advertised configuration information and replay it on a 248 different link or at a future point in time. This can be avoided by 249 including some replay protection mechanism such as a timestamp or a 250 nonce inside the PVD container to ensure freshness of the provided 251 information. This specification does not define a replay protection 252 solution. Rather it is assumed that if replay protection is 253 required, the access network and hosts also deploy existing security 254 solutions such as SeND [RFC3971]. 256 6. IANA Considerations 258 This document defines two new IPv6 NDP options into the "IPv6 259 Neighbor Discovery Option Formats" registry. Option TBD1 is 260 described in Section 3. 262 7. Acknowledgements 264 The authors would like to thank the members of the MIF architecture 265 design team for their comments that led to the creation of this 266 draft. 268 8. References 270 8.1. Normative References 272 [I-D.ietf-mif-mpvd-id] 273 Krishnan, S., Korhonen, J., Bhandari, S., and S. 274 Gundavelli, "Identification of provisioning domains", 275 draft-ietf-mif-mpvd-id-02 (work in progress), October 276 2015. 278 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 279 Requirement Levels", BCP 14, RFC 2119, 280 DOI 10.17487/RFC2119, March 1997, 281 . 283 [RFC3971] Arkko, J., Ed., Kempf, J., Zill, B., and P. Nikander, 284 "SEcure Neighbor Discovery (SEND)", RFC 3971, 285 DOI 10.17487/RFC3971, March 2005, 286 . 288 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 289 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 290 DOI 10.17487/RFC4861, September 2007, 291 . 293 [RFC6494] Gagliano, R., Krishnan, S., and A. Kukec, "Certificate 294 Profile and Certificate Management for SEcure Neighbor 295 Discovery (SEND)", RFC 6494, DOI 10.17487/RFC6494, 296 February 2012, . 298 [RFC6495] Gagliano, R., Krishnan, S., and A. Kukec, "Subject Key 299 Identifier (SKI) SEcure Neighbor Discovery (SEND) Name 300 Type Fields", RFC 6495, DOI 10.17487/RFC6495, February 301 2012, . 303 8.2. Informative References 305 [RFC6487] Huston, G., Michaelson, G., and R. Loomans, "A Profile for 306 X.509 PKIX Resource Certificates", RFC 6487, 307 DOI 10.17487/RFC6487, February 2012, 308 . 310 [RFC7556] Anipko, D., Ed., "Multiple Provisioning Domain 311 Architecture", RFC 7556, DOI 10.17487/RFC7556, June 2015, 312 . 314 Appendix A. Examples 315 A.1. One implicit PVD and one explicit PVD 317 Figure 2 shows how the NDP options are laid out in an RA for one 318 implicit provisioning domain and one explicit provisioning domain. 319 The example does not include security (and signing of the PVD 320 container). The assumption is the PVD identity consumes total 18 321 octets (for example encoding a NAI Realm string "dana.example.com"). 323 The explicit provisioning domain contains a specific PIO for 324 2001:db8:abad:cafe::/64 and the MTU of 1337 octets. The implicit 325 provisioning domain configures a prefix 2001:db8:cafe:babe::/64 and 326 the link MTU of 1500 octets. There are two cases: 1) the host 327 receiving the RA implements provisioning domains and 2) the host does 328 not understand provisioning domains. 330 1. The host recognizes the PVD_CO and "starts" a provisioning domain 331 specific configuration. Security is disabled, thus there are no 332 Key Hash or Digital Signature fields to process. The prefix 333 2001:db8:abad:cafe::/64 is found and configured on the interface. 334 Once the PVD_ID option is located the interface prefix 335 configuration for 2001:db8:abad:cafe::/64 and the MTU of 1337 336 octets can be associated to the provisioning domain found in the 337 PVD_CO option. 339 The rest of the options are parsed and configured into the 340 implicit provisioning domain since there is no encapsulating 341 provisioning domain. The interface is configured with prefix 342 2001:db8:cafe:babe::/64. The implicit provisioning domain uses 343 the link MTU of 1500 octets, whereas the "dana.example.com" 344 provisioning domain uses the MTU of 1337 octets (this means when 345 packets are sourced using 2001:db8:abad:cafe::/64 prefix the link 346 MTU is different than when sourcing packets using 347 2001:db8:cafe:babe::/64 prefix). 349 2. The host ignores the PVD_CO and ends up configuring one prefix on 350 its interface ( 2001:db8:cafe:babe::/64) with a link MTU of 1500 351 octets. 353 0 1 2 3 354 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 355 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 356 | 134 | 0 | Checksum | 357 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 358 | Cur Hop Limit |0|1| Reserved | Router Lifetime | 359 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 360 | Reachable Time | 361 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 362 | Retrans Timer | 363 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ <+ 364 | Type=PVD_CO | 8 | 0 | 0 | 0 ~ | 365 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 366 ~ | 18 | PVD_ID consuming 18 octets | | 367 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 368 | 3 | 4 | 64 |1|1| Reserved1 | | 369 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 370 | Valid Lifetime | P 371 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ V 372 | Preferred Lifetime | D 373 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 374 | Reserved2 | | 375 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 376 | 2001:db8:abad:cafe:: ~ | 377 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 378 | 5 | 1 | Reserved | | 379 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 380 | 1337 | | 381 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ <+ 382 | 3 | 4 | Prefix Length |1|1| Reserved1 | 383 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 384 | Valid Lifetime | 385 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 386 | Preferred Lifetime | 387 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 388 | Reserved2 | 389 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 390 | 2001:db8:cafe:babe:: ~ 391 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 392 | 5 | 1 | Reserved | 393 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 394 | 1500 | 395 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 397 Figure 2: An RA with one implicit PVD and one explicit PVD 399 Authors' Addresses 401 Jouni Korhonen 402 Broadcom Limited 403 3151 Zanker Road 404 San Jose, CA 95134 405 USA 407 Email: jouni.nospam@gmail.com 409 Suresh Krishnan 410 Ericsson 411 8400 Decarie Blvd. 412 Town of Mount Royal, QC 413 Canada 415 Phone: +1 514 345 7900 x42871 416 Email: suresh.krishnan@ericsson.com 418 Sri Gundavelli 419 Cisco Systems 420 170 West Tasman Drive 421 San Jose, CA 95134 422 USA 424 Email: sgundave@cisco.com