idnits 2.17.1 draft-ietf-mif-mpvd-id-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 == Line 122 has weird spacing: '...ication in oc...' -- The document date (October 19, 2015) is 3102 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: 'RFC4193' is mentioned on line 163, but not defined -- Possible downref: Non-RFC (?) normative reference: ref. 'OID' ** Obsolete normative reference: RFC 3315 (Obsoleted by RFC 8415) ** Obsolete normative reference: RFC 4282 (Obsoleted by RFC 7542) == Outdated reference: A later version (-02) exists of draft-ietf-mif-mpvd-dhcp-support-01 == Outdated reference: A later version (-03) exists of draft-ietf-mif-mpvd-ndp-support-01 Summary: 2 errors (**), 0 flaws (~~), 5 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 mif 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 S. Gundavelli 9 Cisco 10 October 19, 2015 12 Identification of provisioning domains 13 draft-ietf-mif-mpvd-id-02 15 Abstract 17 The MIF working group is producing a solution to solve the issues 18 that are associated with nodes that can be attached to multiple 19 networks. This document describes several methods of generating 20 identification information for provisioning them and a format for 21 carrying such identification in configuration protocols. 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 April 21, 2016. 40 Copyright Notice 42 Copyright (c) 2015 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. Provisioning domain identity format . . . . . . . . . . . . . 2 60 4. Security Considerations . . . . . . . . . . . . . . . . . . . 3 61 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 62 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 4 63 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 4 64 7.1. Normative References . . . . . . . . . . . . . . . . . . 4 65 7.2. Informative References . . . . . . . . . . . . . . . . . 5 66 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 5 68 1. Introduction 70 The MIF working group is producing a solution to solve the issues 71 that are associated with nodes that can be attached to multiple 72 networks based on the Multiple Provisioning Domains (MPVD) 73 architecture work [RFC7556]. This document describes a format for 74 carrying identification information along with a few alternatives for 75 reasonable sources for Provisioning Domain (PVD) identification. 76 Since the PVD identities (PVD ID) are expected to be unique, the 77 identification sources provide some level of uniqueness using either 78 a hierarchical structure (e.g. FQDNs and OIDs) or some form of 79 randomness (e.g. UUID and ULAs). Any source that does not provide 80 either guaranteed or probabilistic uniqueness is probably not a good 81 candidate for identifying provisioning domains. 83 2. Terminology 85 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 86 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 87 document are to be interpreted as described in [RFC2119]. 89 3. Provisioning domain identity format 91 The identity of the PVD is independent of the configuration protocol 92 used to communicate it. Furthermore, the PVD identity SHOULD only 93 contain information related to the identification purposes and not 94 encode additional provisioning domain specific configuration 95 information. The configuration protocol used and its extensions are 96 meant for that purpose [I-D.ietf-mif-mpvd-dhcp-support] 98 [I-D.ietf-mif-mpvd-ndp-support]. The PVD identity is formatted as 99 follows. 101 0 1 2 3 102 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 103 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 104 | id-type | id-length | | 105 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 106 + PVD identity information + 107 . (variable length) . 108 +---------------------------------------------------------------+ 110 PVD ID Option 112 o id-type: Describes the type of identification information. 113 This document defines six types of PVD identity information 114 0x01: UUID [RFC4122] 115 0x02: UTF-8 string 116 0x03: OID [OID] 117 0x04: NAI Realm [RFC4282] 118 0x05: FQDN [RFC1035] 119 0x06: ULA Prefix [RFC4193] 120 Further types can be added by IANA action. 122 o id-length: Length of the PVD identification in octets 123 not including the id-type and id-length fields. The length 124 of the PVD identity is dependent on the id-type and is 125 defined by the document that specifies that kind of ID. 127 o PVD identity information: The PVD identification that is 128 based on the id-typ.The format of the PVD identity is 129 dependent on the id-type and is defined by the document that 130 specifies that kind of ID. 132 4. Security Considerations 134 An attacker may attempt to modify the PVD identity provided in a 135 configuration protocol. These attacks can be prevented by using the 136 configuration protocol mechanisms such as SEND [RFC3971] and DHCPv6 137 AUTH option [RFC3315] that detect any form of tampering with the 138 configuration. 140 A compromised configuration source, on the other hand, cannot easily 141 be detected by a configuration client. The only real way to avoid 142 this is that the PVD identification is directly associable to some 143 form of authentication and authorization information from the owner 144 of the PVD (e.g. an FQDN can be associated with a DANE cert). Then, 145 this attack can be detected by the client by verifying the 146 authentication and authorization information provided inside the PVD 147 container option (such as the OPTION_PVD_AUTH inside OPTION_PVD 148 [I-D.ietf-mif-mpvd-dhcp-support] or the Key Hash and Digital 149 Signature inside PVD_CO [I-D.ietf-mif-mpvd-ndp-support]) verifying 150 its trust towards the PVD owner (e.g. a certificate with a well-known 151 /common trust anchor that). 153 5. IANA Considerations 155 This document creates a new registry for PVD id types. The initial 156 values are listed below 158 0x01: UUID [RFC4122] 159 0x02: UTF-8 string 160 0x03: OID [OID] 161 0x04: NAI Realm [RFC4282] 162 0x05: FQDN [RFC1035] 163 0x06: ULA Prefix [RFC4193] 165 6. Acknowledgements 167 The authors would like to thank the members of the MIF architecture 168 design team, Ted Lemon, Brian Carpenter, Bernie Volz and Alper Yegin 169 for their contributions to this draft. The authors also thank Ian 170 Farrer, Erik Kline, Dave Thaler and Steven Barth for their reviews 171 and comments that improved this draft. 173 7. References 175 7.1. Normative References 177 [OID] IANA, "PRIVATE ENTERPRISE NUMBERS", SMI Network Management 178 Private Enterprise Codes, http://www.iana.org/assignments/ 179 enterprise-numbers/enterprise-numbers, March 2013. 181 [RFC1035] Mockapetris, P., "Domain names - implementation and 182 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 183 November 1987, . 185 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 186 Requirement Levels", BCP 14, RFC 2119, March 1997. 188 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 189 and M. Carney, "Dynamic Host Configuration Protocol for 190 IPv6 (DHCPv6)", RFC 3315, July 2003. 192 [RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure 193 Neighbor Discovery (SEND)", RFC 3971, March 2005. 195 [RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally 196 Unique IDentifier (UUID) URN Namespace", RFC 4122, DOI 197 10.17487/RFC4122, July 2005, 198 . 200 [RFC4282] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The 201 Network Access Identifier", RFC 4282, DOI 10.17487/ 202 RFC4282, December 2005, 203 . 205 7.2. Informative References 207 [I-D.ietf-mif-mpvd-dhcp-support] 208 Krishnan, S., Korhonen, J., and S. Bhandari, "Support for 209 multiple provisioning domains in DHCPv6", draft-ietf-mif- 210 mpvd-dhcp-support-01 (work in progress), March 2015. 212 [I-D.ietf-mif-mpvd-ndp-support] 213 Korhonen, J., Krishnan, S., and S. Gundavelli, "Support 214 for multiple provisioning domains in IPv6 Neighbor 215 Discovery Protocol", draft-ietf-mif-mpvd-ndp-support-01 216 (work in progress), February 2015. 218 [RFC7556] Anipko, D., Ed., "Multiple Provisioning Domain 219 Architecture", RFC 7556, DOI 10.17487/RFC7556, June 2015, 220 . 222 Authors' Addresses 224 Suresh Krishnan 225 Ericsson 226 8400 Decarie Blvd. 227 Town of Mount Royal, QC 228 Canada 230 Phone: +1 514 345 7900 x42871 231 Email: suresh.krishnan@ericsson.com 232 Jouni Korhonen 233 Broadcom Corporation 234 3151 Zanker Road 235 San Jose, CA 95134 236 USA 238 Email: jouni.nospam@gmail.com 240 Shwetha Bhandari 241 Cisco Systems 242 Cessna Business Park, Sarjapura Marathalli Outer Ring Road 243 Bangalore, KARNATAKA 560 087 244 India 246 Phone: +91 80 4426 0474 247 Email: shwethab@cisco.com 249 Sri Gundavelli 250 Cisco 251 170 West Tasman Drive 252 San Jose, CA 95134 253 USA 255 Email: sgundave@cisco.com