idnits 2.17.1 draft-anipko-mif-mpvd-arch-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 91 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 26, 2013) is 3926 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'I-D.ietf-6man-addr-select-opt' is defined on line 524, but no explicit reference was found in the text == Outdated reference: A later version (-13) exists of draft-ietf-6man-addr-select-opt-10 Summary: 0 errors (**), 0 flaws (~~), 5 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 26, 2013 5 Expires: January 25, 2014 7 Multiple Provisioning Domain Architecture 8 draft-anipko-mif-mpvd-arch-02 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 25, 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. Incremental deployment of explicit PVDs . . . . . . . . . 5 59 2.3. Relationship between PVDs and interfaces . . . . . . . . . 5 60 2.4. PVD identity/naming . . . . . . . . . . . . . . . . . . . 6 61 2.5. Relationship to dual-stack networks . . . . . . . . . . . 6 62 2.6. Elements of PVD . . . . . . . . . . . . . . . . . . . . . 7 63 3. Example network configurations and number of PVDs . . . . . . 7 64 4. Reference model of PVD-aware node . . . . . . . . . . . . . . 7 65 4.1. Constructions and maintenance of separate PVDs . . . . . . 7 66 4.2. Consistent use of PVDs for network connections . . . . . . 7 67 4.2.1. Name resolution . . . . . . . . . . . . . . . . . . . 7 68 4.2.2. Next-hop and source address selection . . . . . . . . 8 69 4.3. Connectivity tests . . . . . . . . . . . . . . . . . . . . 8 70 4.4. Relationship to interface management and connection manager 8 71 5. PVD support in APIs . . . . . . . . . . . . . . . . . . . . . 8 72 5.1. Basic . . . . . . . . . . . . . . . . . . . . . . . . . . 8 73 5.2. Intermediate . . . . . . . . . . . . . . . . . . . . . . . 9 74 5.3. Advanced . . . . . . . . . . . . . . . . . . . . . . . . . 9 75 6. PVD-aware nodes trust to PVDs . . . . . . . . . . . . . . . . 9 76 6.1. Untrusted PVDs . . . . . . . . . . . . . . . . . . . . . . 9 77 6.2. Trusted PVDs . . . . . . . . . . . . . . . . . . . . . . . 10 78 6.2.1. Authenticated PVDs . . . . . . . . . . . . . . . . . . 10 79 6.2.2. PVDs trusted by attachment . . . . . . . . . . . . . . 10 80 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 81 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 82 9. Security Considerations . . . . . . . . . . . . . . . . . . . 11 83 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 84 10.1. Normative References . . . . . . . . . . . . . . . . . . 11 85 10.2. Informative References . . . . . . . . . . . . . . . . . 11 86 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 11 88 1. Introduction 90 Nodes attached to multiple networks may encounter problems due to 91 conflict of the networks configuration and/or simultaneous use of 92 the multiple available networks. While existing implementations 93 apply various techniques ([RFC6419]) to tackle such problems, in many 94 cases the issues may still appear. The MIF problem statement 95 document [RFC6418] describes the general landscape as well as 96 discusses many specific issues and scenarios details, and are not 97 listed in this document. 99 Across the layers, problems enumerated in [RFC6418] can be grouped 100 into 3 categories: 102 1. Lack of consistent and distinctive management of configuration 103 elements, associated with different networks. 105 2. Inappropriate mixed use of configuration elements, associated 106 with different networks, in the course of a particular network 107 activity / connection. 109 3. Use of a particular network, not consistent with the intent of 110 the scenario / involved parties, leading to connectivity failure 111 and / or other undesired consequences. 113 As an illustration: an example of (1) is a single node-scoped list of 114 DNS server IP addresses, learned from different networks, leading to 115 failures or delays in resolution of name from particular namespaces; 116 an example of (2) is use of an attempt to resolve a name of a HTTP 117 proxy server, learned from a network A, with a DNS server, learned 118 from a network B, likely to fail; an example of (3) is a use of 119 employer-sponsored VPN connection for peer-to-peer connections, 120 unrelated to employment activities. 122 This architecture describes a solution to these categories of 123 problems, respectively, by: 125 1. Introducing a formal notion of the PVD, including PVD identity, 126 and ways for nodes to learn the intended associations among 127 acquired network configuration information elements. 129 2. Introducing a reference model for a PVD-aware node, preventing 130 inadvertent mixed use of the configuration information, which may 131 belong to different PVDs. 133 3. Providing recommendations on PVD selection based on PVD identity 134 and connectivity tests for common scenarios. 136 1.1. Requirements Language 138 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 139 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 140 document are to be interpreted as described in RFC 2119 [RFC2119]. 142 2. Definitions and types of PVDs 144 Provisioning Domain: a consistent set of network configuration 145 information. Classically, the entire set available on a single 146 interface is provided by a single source, such as network 147 administrator, and can therefore be treated as a single provisioning 148 domain. In modern IPv6 networks, multihoming can result in more than 149 one provisioning domain being present on a single link. In some 150 scenarios, it is also possible for elements of the same domain to be 151 present on multiple links. 153 Typical examples of information in a provisioning domain, learned 154 from the network, are: source address prefixes, to be used by 155 connections within the provisioning domain, IP address of DNS server, 156 name of HTTP proxy server if available, DNS suffixes associated with 157 the network etc. 159 It is assumed that normally, configuration information contained in a 160 single PVD, shall be sufficient for a node to fulfill a network 161 connection request by an application, and hence there should be no 162 need to attempt to merge information across different PVDs. 163 Nevertheless, even when a PVD lack some parts of the configuration, 164 merging of information from different PVD(s) shall not be done 165 automatically, since typically it would lead to issues described in 166 [RFC6418]. 168 A node may use other sources, such as e.g., node local policy, user 169 input or other mechanisms, not defined by IETF, to either construct a 170 PVD entirely (analogously to static IP configuration of an 171 interface), or supplement with particular elements all or some PVDs 172 learned from the network, or potentially merge information from 173 different PVDs, if such merge is known to the node to be safe, based 174 on explicit policies. 176 As an example, node administrator could inject a not ISP-specific DNS 177 server into PVDs for any of the networks the node could become 178 attached to. Such creation / augmentation of PVD(s) could be static 179 or dynamic. The particular implementation mechanisms are outside of 180 the scope of this document. 182 Link-specific and/or vendor-proprietary mechanisms for discovery of 183 PVD information, different from the IETF-defined mechanisms, can be 184 used by the nodes separately from or together with IETF-defined 185 mechanisms, as long as they allow to discover necessary elements of 186 the PVD(s). In all cases, by default nodes must ensure that the 187 lifetime of all dynamically discovered PVD configuration is 188 appropriately limited by the relevant events - for example, if an 189 interface media state change was indicated, the previously discovered 190 information may no longer be valid and needs to be re-discovered or 191 confirmed. 193 PVD-aware node: a node that supports association of network 194 configuration information into PVDs, and using the resultant PVDs to 195 serve requests for network connections in ways, consistent with 196 recommendations of this architecture. 198 2.1. Explicit and implicit PVDs 200 A node may receive explicit information from the network and/or other 201 sources, about presence of PVDs and association of particular network 202 information with a particular PVD. PVDs, constructed based on such 203 information, are referred to in this document as "explicit". 205 Protocol changes/extensions will likely be required to support the 206 explicit PVDs by IETF-defined mechanisms. As an example, one could 207 think of one or several DHCP options, carrying PVD identity and / or 208 its elements. A different approach could be to introduce a DHCP 209 option, which only carries identity of a PVD, while the association 210 of network information elements with that identity, is implemented by 211 the respective protocols - such as e.g., with a Router Discovery 212 [RFC4861] option associating an address range with a PVD. 214 Specific, existing or new, features of networking protocols to enable 215 delivery of PVD identity and association with various network 216 information elements will be defined in companion design documents. 218 It shall be possible for networks to communicate that some of their 219 configuration elements could be used within a context of other 220 networks/PVDs. Based on such declaration and their policies, PVD- 221 aware nodes may choose to inject such elements into some or all other 222 PVDs they connect to. 224 When connected to networks, which don't advertise explicit PVD 225 information, PVD-aware shall automatically create separate PVDs for 226 configuration received on different interfaces. Such PVDs are 227 referred to in this document as "implicit". 229 2.2. Incremental deployment of explicit PVDs 231 It is likely that for a long time there may be networks which do not 232 advertise explicit PVD information, since deployment of any new 233 features in networking protocols is a relatively slow process. In 234 such environments, PVD-aware nodes may still provide benefits to 235 their users, compared to non-PVD aware nodes, by using network 236 information from different interfaces separately and consistently to 237 serve network connection requests. 239 In the mixed mode, where e.g., multiple networks are available on the 240 link the interface is attached to, and only some of the networks 241 advertise PVD information, the PVD-aware node shall create explicit 242 PVDs based on explicitly learned PVD information, and associate the 243 rest of the configuration with an implicit PVD created for that 244 interface. 246 2.3. Relationship between PVDs and interfaces 248 Implicit PVDs are limited to network configuration information 249 received on a single interface. Explicit PVDs, in practice will 250 often also be scoped to a configuration related to a particular 251 interface, however per this architecture there is no such requirement 252 or limitation and as defined in this architecture, explicit PVDs may 253 include information related to more than one interfaces, if the node 254 learns presence of the same PVD on those interfaces and the 255 authentication of the PVD ID meets the level required by the node 256 policy. 258 2.4. PVD identity/naming 260 For explicit PVDs, PVD ID (globally unique ID, that possibly is 261 human-readable) is received as part of that information. For 262 implicit PVDs, the node assigns a locally generated globally unique 263 ID to each implicit PVD. 265 PVD-aware node may use these IDs to choose a PVD with matching ID for 266 special-purpose connection requests, in accordance with node policy 267 or choice by advanced applications, and/or to present human-readable 268 IDs to the end-user for selection of Internet-connected PVDs. 270 A single network provider may operate multiple networks, including 271 networks at different locations. In such cases, the provider may 272 chose whether to advertise single or multiple PVD identities at all 273 or some of those networks, as it suits their business needs. This 274 architecture doesn't impose specific requirements in this regard. 276 When multiple nodes are connected to the same link, where one or more 277 explicit PVDs are available, this architecture assumes that the 278 information about all available PVDs is advertized by the networks to 279 all the connected nodes. At the same time, the connected nodes may 280 have different heuristics, policies and/or other settings, including 281 configured set of their trusted PVDs, which may lead to different 282 PVDs actually being used by different nodes for their connections. 284 Possible extensions, where different sets of PVDs may be advertised 285 by the networks to different connected nodes, are out of scope for 286 this document. 288 2.5. Relationship to dual-stack networks 290 When applied to dual-stack networks, the PVD definition allows for 291 multiple PVDs to be created, where each PVD contain information for 292 only one address family, or for a single PVD that contains 293 information about multiple address families. This architecture 294 requires that accompanying design documents for accompanying protocol 295 changes must support PVDs containing information from multiple 296 address families. PVD-aware nodes must be capable of dealing with 297 both single-family and multi-family PVDs. 299 For explicit PVDs, the choice of either of the approaches is a policy 300 decision of a network administrator and/or node user/administrator. 301 Since some of the IP configuration information that can be learned 302 from the network can be applicable to multiple address families (for 303 instance DHCP address selection option [I-D.ietf-6man-addr-select- 304 opt]), it is likely that dual-stack networks will deploy single PVDs 305 for both address families. 307 For implicit PVDs, by default PVD-aware nodes shall including 308 multiple IP families into single implicit PVD created for an 309 interface. At the time of writing of this document in dual-stack 310 networks it appears to be a common practice for configuration of both 311 address families to be provided by a single source. 313 A PVD-aware node that provides API to use / enumerate / inspect PVDs 314 and/or their properties shall provide ability to filter PVDs and/or 315 their properties by address family. 317 2.6. Elements of PVD 319 3. Example network configurations and number of PVDs 321 4. Reference model of PVD-aware node 323 4.1. Constructions and maintenance of separate PVDs 325 4.2. Consistent use of PVDs for network connections 327 PVDs enable PVD-aware nodes to use consistently a correct set of 328 configuration elements to serve the specific network requests from 329 beginning to end. This section describes specific examples of such 330 consistent use. 332 4.2.1. Name resolution 334 When PVD-aware node needs to resolve a name of the destination used 335 by a connection request, the node could decide to use one, or 336 multiple PVDs for a given name lookup. 338 The node shall chose one PVD, if e.g., the node policy required to 339 use a particular PVD for a particular purpose (e.g. to download an 340 MMS using a specific APN over a cellular connection). To make the 341 choice, the node could use a match of the PVD DNS suffix or other 342 form of PVD ID, as determined by the node policy. 344 The node may pick multiple PVDs, if e.g., they are general purpose 345 PVDs providing connectivity to the Internet, and the node desires to 346 maximize chances for connectivity in Happy Eyeballs style. In this 347 case, the node could do the lookups in parallel, or in sequence. 348 Alternatively, the node may use for the lookup only one PVD, based on 349 the PVD connectivity properties, user choice of the preferred 350 Internet PVD, etc. 352 In either case, by default the node uses information obtained in a 353 name service lookup to establish connections only within the same PVD 354 from which the lookup results were obtained. 356 For simplicity, when we say that name service lookup results were 357 obtained from a PVD, what we mean is that the name service query was 358 issued against a name service the configuration of which is present 359 in a particular PVD. In that sense, the results are "from" that 360 particular PVD. 362 Some nodes may support transports and/or APIs, which provide an 363 abstraction of a single connection, aggregating multiple underlying 364 connections. MPTCP [RFC6182] is an example of such transport 365 protocol. For the connections provided by such transports/APIs, a 366 PVD-aware node may use different PVDs for servicing of that logical 367 connection, provided that all operations on the underlying 368 connections are done consistently within their corresponding PVD(s). 370 4.2.2. Next-hop and source address selection 372 For the purpose of this discussion, let's assume the preceding name 373 lookup succeeded in a particular PVD. For each obtained destination 374 address, the node shall perform a next-hop lookup among routers, 375 associated with that PVD. As an example, such association could be 376 determined by the node via matching the source address prefixes/ 377 specific routes advertized by the router against known PVDs, or 378 receiving explicit PVD affiliation advertized through a new Router 379 Discovery [RFC4861] option. 381 For each destination, once the best next-hop is found, the node 382 selects best source address according to the [RFC6724] rules, but 383 with a constraint that the source address must belong to a range 384 associated with the used PVD. If needed, the node would use the 385 prefix policy from the same PVD for the best source address selection 386 among multiple candidates. 388 When destination/source pairs are identified, then they are sorted 389 using the [RFC6724] destination sorting rules and the prefix policy 390 table from the used PVD. 392 4.3. Connectivity tests 394 4.4. Relationship to interface management and connection managers 396 5. PVD support in APIs 398 In all cases changes in available PVDs must be somehow exposed, 399 appropriately for each of the approaches. 401 5.1. Basic 402 Applications are not PVD-aware in any manner, and only submit 403 connection requests. The node performs PVD selection implicitly, 404 without any otherwise applications participation, and based purely on 405 node-specific administrative policies and/or choices made by the user 406 in a user interface provided by the operating environment, not by the 407 application. 409 As an example, such PVD selection can be done at the name service 410 lookup step, by using the relevant configuration elements, such as 411 e.g., those described in [RFC6731]. As another example, the PVD 412 selection could be done based on application identity or type (i.e., 413 a node could always use a particular PVD for a VOIP application). 415 5.2. Intermediate 417 Applications indirectly participate in selection of PVD by specifying 418 hard requirements and soft preferences. The node performs PVD 419 selection, based on applications inputs and policies and/or user 420 preferences. Some / all properties of the resultant PVD may be 421 exposed to applications. 423 5.3. Advanced 425 PVDs are directly exposed to applications, for enumeration and 426 selection. Node polices and/or user choices, may still override the 427 application preferences and limit which PVD(s) can be enumerated and/ 428 or used by the application, irrespectively of any preferences which 429 application may have specified. Depending on the implementation, 430 such restrictions, imposed per node policy and/or user choice, may or 431 may not be visible to the application. 433 6. PVD-aware nodes trust to PVDs 435 6.1. Untrusted PVDs 437 Implicit and explicit PVDs for which no trust relationship exists are 438 considered untrusted. Only PVDs, which meet the requirements in 439 Section 6.2, are trusted; any other PVD is untrusted. 441 In order to avoid various forms of misinformation that can be 442 asserted when PVDs are untrusted, nodes that implement PVD separation 443 cannot assume that two explicit PVDs with the same identifier are 444 actually the same PVD. A node that did make this assumption would be 445 vulnerable to attacks where for example an open Wifi hotspot might 446 assert that it was part of another PVD, and thereby might draw 447 traffic intended for that PVD onto its own network. 449 Since implicit PVD identifiers are synthesized by the node, this 450 issue cannot arise with implicit PVDs. 452 Mechanisms exist (for example, [RFC6731]) whereby a PVD can provide 453 configuration information that asserts special knowledge about the 454 reachability of resources through that PVD. Such assertions cannot 455 be validated unless the node has a trust relationship with the PVD; 456 assertions of this type therefore must be ignored by nodes that 457 receive them from untrusted PVDs. Failure to ignore such assertions 458 could result in traffic being diverted from legitimate destinations 459 to spoofed destinations. 461 6.2. Trusted PVDs 463 Trusted PVDs are PVDs for which two conditions apply. First, a 464 trust relationship must exist between the node that is using the PVD 465 configuration and the source that provided that configuration; this 466 is the authorization portion of the trust relationship. Second, 467 there must be some way to validate the trust relationship. This is 468 the authentication portion of the trust relationship. Two 469 mechanisms for validating the trust relationship are defined. 471 6.2.1. Authenticated PVDs 473 One way to validate the trust relationship between a node and the 474 source of a PVD is through the combination of cryptographic 475 authentication and an identifier configured on the node. In some 476 cases, the two could be the same; for example, if authentication is 477 done with a shared secret, the secret would have to be associated 478 with the PVD identifier. Without a (PVD Identifier, shared key) 479 tuple, authentication would be impossible, and hence authentication 480 and authorization are combined. 482 However, if authentication is done using some public key mechanism 483 such as a TLS cert or DANE, authentication by itself isn't enough, 484 since theoretically any PVD could be authenticated in this way. In 485 addition to authentication, the node would need to be configured to 486 trust the identifier being authenticated. Validating the 487 authenticated PVD name against a list of PVD names configured as 488 trusted on the node would constitute the authorization step in this 489 case. 491 6.2.2. PVDs trusted by attachment 493 In some cases a trust relationship may be validated by some means 494 other than described in Section 6.2.1, simply by virtue of the 495 connection through which the PVD was obtained. For instance, a 496 handset connected to a mobile network may know through the mobile 497 network infrastructure that it is connected to a trusted PVD, and 498 whatever mechanism was used to validate that connection constitutes 499 the authentication portion of the PVD trust relationship. 500 Presumably such a handset would be configured from the factory, or 501 else through mobile operator or user preference settings, to trust 502 the PVD, and this would constitute the authorization portion of this 503 type of trust relationship. 505 7. Acknowledgements 507 8. IANA Considerations 509 This memo includes no request to IANA. 511 9. Security Considerations 513 All drafts are required to have a security considerations section. 515 10. References 517 10.1. Normative References 519 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 520 Requirement Levels", BCP 14, RFC 2119, March 1997. 522 10.2. Informative References 524 [I-D.ietf-6man-addr-select-opt] 525 Matsumoto, A., Fujisaki, T. and T. Chown, "Distributing 526 Address Selection Policy using DHCPv6", Internet-Draft 527 draft-ietf-6man-addr-select-opt-10, April 2013. 529 [RFC4861] Narten, T., Nordmark, E., Simpson, W. and H. Soliman, 530 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 531 September 2007. 533 [RFC6182] Ford, A., Raiciu, C., Handley, M., Barre, S. and J. 534 Iyengar, "Architectural Guidelines for Multipath TCP 535 Development", RFC 6182, March 2011. 537 [RFC6418] Blanchet, M. and P. Seite, "Multiple Interfaces and 538 Provisioning Domains Problem Statement", RFC 6418, 539 November 2011. 541 [RFC6419] Wasserman, M. and P. Seite, "Current Practices for 542 Multiple-Interface Hosts", RFC 6419, November 2011. 544 [RFC6724] Thaler, D., Draves, R., Matsumoto, A. and T. Chown, 545 "Default Address Selection for Internet Protocol Version 6 546 (IPv6)", RFC 6724, September 2012. 548 [RFC6731] Savolainen, T., Kato, J. and T. Lemon, "Improved Recursive 549 DNS Server Selection for Multi-Interfaced Nodes", RFC 550 6731, December 2012. 552 Author's Address 553 Dmitry Anipko 554 Microsoft Corporation 555 One Microsoft Way 556 Redmond, WA 98052 557 USA 559 Phone: +1 425 703 7070 560 Email: dmitry.anipko@microsoft.com