idnits 2.17.00 (12 Aug 2021) /tmp/idnits7004/draft-anipko-mif-mpvd-arch-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 == Line 90 has weird spacing: '...uration and/o...' == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (July 23, 2013) is 3223 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: draft-ietf-6man-addr-select-opt has been published as RFC 7078 Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MIF Working Group D. Anipko 3 Internet-Draft Microsoft Corporation 4 Intended status: Informational July 23, 2013 5 Expires: January 22, 2014 7 Multiple Provisioning Domain Architecture 8 draft-anipko-mif-mpvd-arch-01 10 Abstract 12 This document is a product of the work of MIF architecture design 13 team. It outlines a solution framework for some of the issues, 14 experienced by nodes that can be attached to multiple networks. The 15 framework defines the notion of a Provisioning Domain (PVD) - a 16 consistent set of network configuration information, and PVD-aware 17 nodes - nodes which learn PVDs from the attached network(s) and/or 18 other sources and manage and use multiple PVDs for connectivity 19 separately and consistently. 21 Status of this Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on January 22, 2014. 38 Copyright Notice 40 Copyright (c) 2013 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents (http://trustee.ietf.org/ 45 license-info) in effect on the date of publication of this document. 46 Please review these documents carefully, as they describe your rights 47 and restrictions with respect to this document. Code Components 48 extracted from this document must include Simplified BSD License text 49 as described in Section 4.e of the Trust Legal Provisions and are 50 provided without warranty as described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 55 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 56 2. Definitions and types of PVDs . . . . . . . . . . . . . . . . 3 57 2.1. Explicit and implicit PVDs . . . . . . . . . . . . . . . . 4 58 2.2. Relationship between PVDs and interfaces . . . . . . . . . 5 59 2.3. PVD identity/naming . . . . . . . . . . . . . . . . . . . 5 60 2.4. Relationship to dual-stack networks . . . . . . . . . . . 5 61 2.5. Elements of PVD . . . . . . . . . . . . . . . . . . . . . 6 62 3. Example network configurations and number of PVDs . . . . . . 6 63 4. Reference model of PVD-aware node . . . . . . . . . . . . . . 6 64 4.1. Constructions and maintenance of separate PVDs . . . . . . 6 65 4.2. Consistent use of PVDs for network connections . . . . . . 6 66 4.2.1. Name resolution . . . . . . . . . . . . . . . . . . . 6 67 4.2.2. Next-hop and source address selection . . . . . . . . 7 68 4.3. Connectivity tests . . . . . . . . . . . . . . . . . . . . 7 69 4.4. Relationship to interface management and connection manager 7 70 5. PVD support in APIs . . . . . . . . . . . . . . . . . . . . . 7 71 5.1. Basic . . . . . . . . . . . . . . . . . . . . . . . . . . 7 72 5.2. Intermediate . . . . . . . . . . . . . . . . . . . . . . . 7 73 5.3. Advanced . . . . . . . . . . . . . . . . . . . . . . . . . 8 74 6. PVD-aware nodes trust to PVDs . . . . . . . . . . . . . . . . 8 75 6.1. Untrusted PVDs . . . . . . . . . . . . . . . . . . . . . . 8 76 6.2. Trusted PVDs . . . . . . . . . . . . . . . . . . . . . . . 8 77 6.2.1. Authenticated PVDs . . . . . . . . . . . . . . . . . . 9 78 6.2.2. PVDs trusted by attachment . . . . . . . . . . . . . . 9 79 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 80 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 81 9. Security Considerations . . . . . . . . . . . . . . . . . . . 9 82 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 83 10.1. Normative References . . . . . . . . . . . . . . . . . . 9 84 10.2. Informative References . . . . . . . . . . . . . . . . . 9 85 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 10 87 1. Introduction 89 Nodes attached to multiple networks may encounter problems due to 90 conflict of the networks configuration and/or simultaneous use of 91 the multiple available networks. While existing implementations 92 apply various techniques ([RFC6419]) to tackle such problems, in many 93 cases the issues may still appear. The MIF problem statement 94 document [RFC6418] describes the general landscape as well as 95 discusses many specific issues details. 97 Across the layers, problems enumerated in [RFC6418] can be grouped 98 into 3 categories: 100 1. Lack of consistent and distinctive management of configuration 101 elements, associated with different networks. 103 2. Inappropriate mixed use of configuration elements, associated 104 with different networks, in the course of a particular network 105 activity / connection. 107 3. Use of a particular network, not consistent with the intent of 108 the scenario / involved parties, leading to connectivity failure 109 and / or other undesired consequences. 111 As an illustration: an example of (1) is a single node-scoped list of 112 DNS server IP addresses, learned from different networks, leading to 113 failures or delays in resolution of name from particular namespaces; 114 an example of (2) is use of an attempt to resolve a name of a HTTP 115 proxy server, learned from a network A, with a DNS server, learned 116 from a network B, likely to fail; an example of (3) is a use of 117 employer-sponsored VPN connection for peer-to-peer connections, 118 unrelated to employment activities. 120 This architecture describes a solution to these categories of 121 problems, respectively, by: 123 1. Introducing a formal notion of the PVD, including PVD identity, 124 and ways for nodes to learn the intended associations among 125 acquired network configuration information elements. 127 2. Introducing a reference model for a PVD-aware node, preventing 128 inadvertent mixed use of the configuration information, which may 129 belong to different PVDs. 131 3. Providing recommendations on PVD selection based on PVD identity 132 and connectivity tests for common scenarios. 134 1.1. Requirements Language 136 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 137 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 138 document are to be interpreted as described in RFC 2119 [RFC2119]. 140 2. Definitions and types of PVDs 142 Provisioning Domain: a consistent set of network configuration 143 information. Classically, the entire set available on a single 144 interface is provided by a single source, such as network 145 administrator, and can therefore be treated as a single provisioning 146 domain. In modern IPv6 networks, multihoming can result in more than 147 one provisioning domain being present on a single link. In some 148 scenarios, it is also possible for elements of the same domain to be 149 present on multiple links. 151 Typical examples of information in a provisioning domain, learned 152 from the network, are: source address prefixes, to be used by 153 connections within the provisioning domain, IP address of DNS server, 154 name of HTTP proxy server if available, DNS suffixes associated with 155 the network etc. 157 In some cases, other sources, such as e.g., node local policy, user 158 input or other out of band mechanisms may be used to either construct 159 a PVD entirely (analogously to static IP configuration of an 160 interface), or supplement with particular elements all or some PVDs 161 learned from the network. 163 As an example, node administrator could inject a not ISP-specific DNS 164 server into PVDs for any of the networks the node could become 165 attached to. Such creation / augmentation of PVD(s) could be static 166 or dynamic. The particular implementation mechanisms are outside of 167 the scope of this document. 169 PVD-aware node: a node that supports association of network 170 configuration information into PVDs, and using the resultant PVDs to 171 serve requests for network connections in a way, consistent with 172 recommendations of this architecture. 174 2.1. Explicit and implicit PVDs 176 A node may receive explicit information from the network and/or other 177 sources, about presence of PVDs and association of particular network 178 information with a particular PVD. PVDs, constructed based on such 179 information, are referred to in this document as "explicit". 181 Protocol changes/extensions will likely be required to support the 182 explicit PVDs. As an example, one could think of one or several DHCP 183 options, defining a PVD identity and elements. A different approach 184 could be to introduce a DHCP option, which only introduces identity 185 of a PVD, while the association of network information elements with 186 that identity, is implemented by the respective protocols - such as 187 e.g., with a Router Discovery [RFC4861] option declaring association 188 of an address range with a particular PVD. 190 Specific, existing or new, features of networking protocols to enable 191 delivery of PVD identity and association with various network 192 information elements will be defined in companion design documents. 194 It is likely that for a long time there may be networks which do not 195 advertise any explicit PVD information, since deployment of any new 196 features in networking protocols is a relatively slow process. When 197 connected to such networks, PVD-aware nodes may still provide 198 benefits to their users, compared to non-PVD aware nodes, by creating 199 separate PVDs for configuration received on different interfaces. 200 Such PVDs are referred to in this document as "implicit". This 201 allows the node to manage and use network information from different 202 interfaces separately and consistently use the configuration to serve 203 network connection requests. 205 In the mixed mode, where e.g. multiple networks are available on the 206 link the interface is attached to, and only some of the networks 207 advertize PVD information, the PVD-aware node shall create explicit 208 PVDs based on explicitly learned PVD information, and associate the 209 rest of the configuration with an implicit PVD created for that 210 interface. 212 It shall be possible for networks to communicate that some of their 213 configuration elements could be used within a context of other 214 networks/PVDs. Based on such declaration and their policies, PVD- 215 aware nodes may choose to inject such elements into some or all other 216 PVDs they connect to. 218 2.2. Relationship between PVDs and interfaces 220 Implicit PVDs are limited to network configuration information 221 received on a single interface. Explicit PVDs, in practice will 222 often also be scoped to a configuration related to a particular 223 interface, however per this architecture there is no such requirement 224 or limitation and as defined in this architecture, explicit PVDs may 225 include information related to more than one interfaces, if the node 226 learns presence of the same PVD on those interfaces and the 227 authentication of the PVD ID meets the level required by the node 228 policy. 230 2.3. PVD identity/naming 232 For explicit PVDs, PVD ID (globally unique ID, that possibly is 233 human-readable) is received as part of that information. For 234 implicit PVDs, the node assigns a locally generated globally unique 235 ID to each implicit PVD. 237 PVD-aware node may use these IDs to choose a PVD with matching ID for 238 special-purpose connection requests, in accordance with node policy 239 or choice by advanced applications, and/or to present human-readable 240 IDs to the end-user for selection of Internet-connected PVDs. 242 2.4. Relationship to dual-stack networks 244 When applied to dual-stack networks, the PVD definition allows for 245 multiple PVDs to be created, where each PVD contain information for 246 only one address family, or for a single PVD that contains 247 information about multiple address families. This architecture 248 requires that accompanying design documents for accompanying protocol 249 changes must support PVDs containing information from multiple 250 address families. PVD-aware nodes must be capable of dealing with 251 both single-family and multi-family PVDs. 253 Nevertheless, for explicit PVDs, the choice of either of the 254 approaches is a policy decision of a network administrator and/or 255 node user/administrator. Since some of the IP configuration 256 information that can be learned from the network can be applicable to 257 multiple address families (for instance DHCP address selection option 258 [I-D.ietf-6man-addr-select-opt]), it is likely that dual-stack 259 networks will deploy single PVDs for both address families. 261 For implicit PVDs, by default PVD-aware nodes shall including 262 multiple IP families into single implicit PVD created for an 263 interface. 265 A PVD-aware node that provides API to use / enumerate / inspect PVDs 266 and/or their properties shall provide ability to filter PVDs and/or 267 their properties by address family. 269 2.5. Elements of PVD 271 3. Example network configurations and number of PVDs 273 4. Reference model of PVD-aware node 275 4.1. Constructions and maintenance of separate PVDs 277 4.2. Consistent use of PVDs for network connections 279 PVDs enable PVD-aware nodes to use consistently a correct set of 280 configuration elements to serve the specific network requests from 281 beginning to end. This section describes specific examples of such 282 consistent use. 284 4.2.1. Name resolution 286 When PVD-aware node needs to resolve a name of the destination used 287 by a connection request, the node could decide to use one, or 288 multiple PVDs for a given name lookup. 290 The node shall chose one PVD, if e.g., the node policy required to 291 use a particular PVD for a particular purpose (e.g. to download an 292 MMS using a specific APN over a cellular connection). To make the 293 choice, the node could use a match of the PVD DNS suffix or other 294 form of PVD ID, as determined by the node policy. 296 The node may pick multiple PVDs, if e.g., they are general purpose 297 PVDs providing connectivity to the Internet, and the node desires to 298 maximize chances for connectivity in Happy Eyeballs style. In this 299 case, the node could do the lookups in parallel, or in sequence. 300 Alternatively, the node may use for the lookup only one PVD, based on 301 the PVD connectivity properties, user choice of the preferred 302 Internet PVD, etc. 304 In either case, by default the node uses information obtained in a 305 name service lookup to establish connections only within the same PVD 306 from which the lookup results were obtained. 308 For simplicity, when we say that name service lookup results were 309 obtained from a PVD, what we mean is that the name service query was 310 issued against a name service the configuration of which is present 311 in a particular PVD. In that sense, the results are "from" that 312 particular PVD. 314 4.2.2. Next-hop and source address selection 316 For the purpose of this discussion, let's assume the preceding name 317 lookup succeeded in a particular PVD. For each obtained destination 318 address, the node shall perform a next-hop lookup among routers, 319 associated with that PVD. As an example, such association could be 320 determined by the node via matching the source address prefixes/ 321 specific routes advertized by the router against known PVDs, or 322 receiving explicit PVD affiliation advertized through a new Router 323 Discovery [RFC4861] option. 325 For each destination, once the best next-hop is found, the node 326 selects best source address according to the [RFC6724] rules, but 327 with a constraint that the source address must belong to a range 328 associated with the used PVD. If needed, the node would use the 329 prefix policy from the same PVD for the best source address selection 330 among multiple candidates. 332 When destination/source pairs are identified, then they are sorted 333 using the [RFC6724] destination sorting rules and the prefix policy 334 table from the used PVD. 336 4.3. Connectivity tests 338 4.4. Relationship to interface management and connection managers 340 5. PVD support in APIs 342 In all cases changes in available PVDs must be somehow exposed, 343 appropriately for each of the approaches. 345 5.1. Basic 347 Applications are not PVD-aware in any manner, and only submit 348 connection requests. The node performs PVD selection implicitly, 349 without any otherwise applications participation, and based purely on 350 node-specific administrative policies and/or choices made by the user 351 in a user interface provided by the operating environment, not by the 352 application. 354 5.2. Intermediate 355 Applications indirectly participate in selection of PVD by specifying 356 hard requirements and soft preferences. The node performs PVD 357 selection, based on applications inputs and policies and/or user 358 preferences. Some / all properties of the resultant PVD may be 359 exposed to applications. 361 5.3. Advanced 363 PVDs are directly exposed to applications, for enumeration and 364 selection. Node polices and/or user choices, may still override the 365 application preferences and limit which PVD(s) can be enumerated and/ 366 or used by the application, irrespectively of any preferences which 367 application may have specified. Depending on the implementation, 368 such restrictions, imposed per node policy and/or user choice, may or 369 may not be visible to the application. 371 6. PVD-aware nodes trust to PVDs 373 6.1. Untrusted PVDs 375 Implicit and explicit PVDs for which no trust relationship exists are 376 considered untrusted. Only PVDs, which meet the requirements in 377 Section 6.2, are trusted; any other PVD is untrusted. 379 In order to avoid various forms of misinformation that can be 380 asserted when PVDs are untrusted, nodes that implement PVD separation 381 cannot assume that two explicit PVDs with the same identifier are 382 actually the same PVD. A node that did make this assumption would be 383 vulnerable to attacks where for example an open Wifi hotspot might 384 assert that it was part of another PVD, and thereby might draw 385 traffic intended for that PVD onto its own network. 387 Since implicit PVD identifiers are synthesized by the node, this 388 issue cannot arise with implicit PVDs. 390 Mechanisms exist (for example, [RFC6731]) whereby a PVD can provide 391 configuration information that asserts special knowledge about the 392 reachability of resources through that PVD. Such assertions cannot 393 be validated unless the node has a trust relationship with the PVD; 394 assertions of this type therefore must be ignored by nodes that 395 receive them from untrusted PVDs. Failure to ignore such assertions 396 could result in traffic being diverted from legitimate destinations 397 to spoofed destinations. 399 6.2. Trusted PVDs 401 Trusted PVDs are PVDs for which two conditions apply. First, a 402 trust relationship must exist between the node that is using the PVD 403 configuration and the source that provided that configuration; this 404 is the authorization portion of the trust relationship. Second, 405 there must be some way to validate the trust relationship. This is 406 the authentication portion of the trust relationship. Two 407 mechanisms for validating the trust relationship are defined. 409 6.2.1. Authenticated PVDs 411 One way to validate the trust relationship between a node and the 412 source of a PVD is through the combination of cryptographic 413 authentication and an identifier configured on the node. In some 414 cases, the two could be the same; for example, if authentication is 415 done with a shared secret, the secret would have to be associated 416 with the PVD identifier. Without a (PVD Identifier, shared key) 417 tuple, authentication would be impossible, and hence authentication 418 and authorization are combined. 420 However, if authentication is done using some public key mechanism 421 such as a TLS cert or DANE, authentication by itself isn't enough, 422 since theoretically any PVD could be authenticated in this way. In 423 addition to authentication, the node would need to be configured to 424 trust the identifier being authenticated. Validating the 425 authenticated PVD name against a list of PVD names configured as 426 trusted on the node would constitute the authorization step in this 427 case. 429 6.2.2. PVDs trusted by attachment 431 In some cases a trust relationship may be validated by some means 432 other than described in Section 6.2.1, simply by virtue of the 433 connection through which the PVD was obtained. For instance, a 434 handset connected to a mobile network may know through the mobile 435 network infrastructure that it is connected to a trusted PVD, and 436 whatever mechanism was used to validate that connection constitutes 437 the authentication portion of the PVD trust relationship. 438 Presumably such a handset would be configured from the factory, or 439 else through mobile operator or user preference settings, to trust 440 the PVD, and this would constitute the authorization portion of this 441 type of trust relationship. 443 7. Acknowledgements 445 8. IANA Considerations 447 This memo includes no request to IANA. 449 9. Security Considerations 451 All drafts are required to have a security considerations section. 453 10. References 455 10.1. Normative References 457 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 458 Requirement Levels", BCP 14, RFC 2119, March 1997. 460 10.2. Informative References 462 [I-D.ietf-6man-addr-select-opt] 463 Matsumoto, A., Fujisaki, T. and T. Chown, "Distributing 464 Address Selection Policy using DHCPv6", Internet-Draft 465 draft-ietf-6man-addr-select-opt-10, April 2013. 467 [RFC4861] Narten, T., Nordmark, E., Simpson, W. and H. Soliman, 468 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 469 September 2007. 471 [RFC6418] Blanchet, M. and P. Seite, "Multiple Interfaces and 472 Provisioning Domains Problem Statement", RFC 6418, 473 November 2011. 475 [RFC6419] Wasserman, M. and P. Seite, "Current Practices for 476 Multiple-Interface Hosts", RFC 6419, November 2011. 478 [RFC6724] Thaler, D., Draves, R., Matsumoto, A. and T. Chown, 479 "Default Address Selection for Internet Protocol Version 6 480 (IPv6)", RFC 6724, September 2012. 482 [RFC6731] Savolainen, T., Kato, J. and T. Lemon, "Improved Recursive 483 DNS Server Selection for Multi-Interfaced Nodes", RFC 484 6731, December 2012. 486 Author's Address 488 Dmitry Anipko 489 Microsoft Corporation 490 One Microsoft Way 491 Redmond, WA 98052 492 USA 494 Phone: +1 425 703 7070 495 Email: dmitry.anipko@microsoft.com