idnits 2.17.1 draft-ietf-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: ---------------------------------------------------------------------------- == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 3) being 60 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 22 instances of too long lines in the document, the longest one being 13 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 107 has weird spacing: '...uration and/o...' -- The document date (July 03, 2014) is 3578 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'IEEE802.11u' is defined on line 986, but no explicit reference was found in the text -- Obsolete informational reference (is this intentional?): RFC 3315 (Obsoleted by RFC 8415) -- Obsolete informational reference (is this intentional?): RFC 5996 (Obsoleted by RFC 7296) Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MIF Working Group D. Anipko, Ed. 3 Internet-Draft Microsoft Corporation 4 Intended status: Informational July 03, 2014 5 Expires: January 02, 2015 7 Multiple Provisioning Domain Architecture 8 draft-ietf-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 02, 2015. 38 Copyright Notice 40 Copyright (c) 2014 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 . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 56 2. Definitions and types of PVDs . . . . . . . . . . . . . . . . 4 57 2.1. Explicit PVDs . . . . . . . . . . . . . . . . . . . . . . 4 58 2.2. Implicit PVDs and incremental adoption of the explicit PVDs 5 59 2.3. Relationship between PVDs and interfaces . . . . . . . . . 6 60 2.4. PVD identity/naming . . . . . . . . . . . . . . . . . . . 6 61 2.5. Relationship to dual-stack networks . . . . . . . . . . . 7 62 2.6. Elements of PVD . . . . . . . . . . . . . . . . . . . . . 7 63 3. Conveying PVD information using DHCPv6 and Router Advertisement 7 64 3.1. Separate messages or one message . . . . . . . . . . . . . 8 65 3.2. Securing the PVD information . . . . . . . . . . . . . . . 8 66 3.3. Backward compatibility . . . . . . . . . . . . . . . . . . 8 67 3.4. Selective propagation . . . . . . . . . . . . . . . . . . 8 68 3.5. Retracting/updating PvD information . . . . . . . . . . . 9 69 3.6. Conveying configuration information using IKEv2 . . . . . 9 70 4. Example network configurations and number of PVDs . . . . . . 9 71 4.1. A mobile node . . . . . . . . . . . . . . . . . . . . . . 9 72 4.2. A node with a VPN connection . . . . . . . . . . . . . . . 10 73 4.3. A home network and a network operator with multiple PvDs . 11 74 5. Reference model of PVD-aware node . . . . . . . . . . . . . . 12 75 5.1. Constructions and maintenance of separate PVDs . . . . . . 12 76 5.2. Consistent use of PVDs for network connections . . . . . . 13 77 5.2.1. Name resolution . . . . . . . . . . . . . . . . . . . 13 78 5.2.2. Next-hop and source address selection . . . . . . . . 14 79 5.2.3. Listening applications . . . . . . . . . . . . . . . . 14 80 5.2.3.1. Processing of incoming traffic . . . . . . . . . . 15 81 5.2.3.1.1. Connection-oriented APIs . . . . . . . . . . . 15 82 5.2.3.1.2. Connection-less APIs . . . . . . . . . . . . . 15 83 5.2.4. Enforcement of security policies . . . . . . . . . . . 15 84 5.3. Connectivity tests . . . . . . . . . . . . . . . . . . . . 16 85 5.4. Relationship to interface management and connection manage 16 86 6. PVD support in APIs . . . . . . . . . . . . . . . . . . . . . 17 87 6.1. Basic . . . . . . . . . . . . . . . . . . . . . . . . . . 17 88 6.2. Intermediate . . . . . . . . . . . . . . . . . . . . . . . 17 89 6.3. Advanced . . . . . . . . . . . . . . . . . . . . . . . . . 18 90 7. PVD-aware nodes trust to PVDs . . . . . . . . . . . . . . . . 18 91 7.1. Untrusted PVDs . . . . . . . . . . . . . . . . . . . . . . 18 92 7.2. Trusted PVDs . . . . . . . . . . . . . . . . . . . . . . . 18 93 7.2.1. Authenticated PVDs . . . . . . . . . . . . . . . . . . 19 94 7.2.2. PVDs trusted by attachment . . . . . . . . . . . . . . 19 95 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19 96 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 97 10. Security Considerations . . . . . . . . . . . . . . . . . . . 19 98 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 99 11.1. Normative References . . . . . . . . . . . . . . . . . . 20 100 11.2. Informative References . . . . . . . . . . . . . . . . . 20 102 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 21 104 1. Introduction 106 Nodes attached to multiple networks may encounter problems due to 107 conflict of the networks configuration and/or simultaneous use of 108 the multiple available networks. While existing implementations 109 apply various techniques ([RFC6419]) to tackle such problems, in many 110 cases the issues may still appear. The MIF problem statement 111 document [RFC6418] describes the general landscape as well as 112 discusses many specific issues and scenarios details. 114 Problems, enumerated in [RFC6418], can be grouped into 3 categories: 116 1. Lack of consistent and distinctive management of configuration 117 elements, associated with different networks. 119 2. Inappropriate mixed use of configuration elements, associated 120 with different networks, in the course of a particular network 121 activity / connection. 123 3. Use of a particular network, not consistent with the intent of 124 the scenario / involved parties, leading to connectivity failure 125 and / or other undesired consequences. 127 An example of (1) is a single node-scoped list of DNS server IP 128 addresses, learned from different networks, leading to failures or 129 delays in resolution of names from particular namespaces; an example 130 of (2) is use of an attempt to resolve a name of a HTTP proxy server, 131 learned from a network A, with a DNS server, learned from a network 132 B, that is likely to fail; an example of (3) is use of an employer- 133 sponsored VPN connection for peer-to-peer connectivity, unrelated to 134 employment activities. 136 This architecture describes a solution to these categories of 137 problems, respectively, by: 139 1. Introducing a formal notion of the PVD, including PVD identity, 140 and ways for nodes to learn the intended associations among 141 acquired network configuration information elements. 143 2. Introducing a reference model for a PVD-aware node, preventing 144 inadvertent mixed use of the configuration information, which may 145 belong to different PVDs. 147 3. Providing recommendations on PVD selection based on PVD identity 148 and connectivity tests for common scenarios. 150 1.1. Requirements Language 152 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 153 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 154 document are to be interpreted as described in RFC 2119 [RFC2119]. 156 2. Definitions and types of PVDs 158 Provisioning Domain: a consistent set of network configuration 159 information. Classically, the entire set available on a single 160 interface is provided by a single source, such as network 161 administrator, and can therefore be treated as a single provisioning 162 domain. In modern IPv6 networks, multihoming can result in more than 163 one provisioning domain being present on a single link. In some 164 scenarios, it is also possible for elements of the same domain to be 165 present on multiple links. 167 Typical examples of information in a provisioning domain, learned 168 from the network, are: source address prefixes that can be used by 169 connections within the provisioning domain, IP address of DNS server, 170 name of HTTP proxy server if available, DNS suffixes associated with 171 the network, default gateway address etc. 173 PVD-aware node: a node that supports association of network 174 configuration information into PVDs, and using these PVDs to serve 175 requests for network connections in ways, consistent with 176 recommendations of this architecture. 178 2.1. Explicit PVDs 180 A node may receive explicit information from the network and/or other 181 sources, about presence of PVDs and association of particular network 182 information with a particular PVD. PVDs, constructed based on such 183 information, are referred to in this document as "explicit". 185 Protocol changes/extensions will likely be required to support the 186 explicit PVDs by IETF-defined mechanisms. As an example, one could 187 think of one or several DHCP options, carrying PVD identity and / or 188 its elements. A different approach could be to introduce a DHCP 189 option, which only carries identity of a PVD, while the association 190 of network information elements with that identity, is implemented by 191 the respective protocols - such as e.g., with a Router Discovery 192 [RFC4861] option associating an address range with a PVD. 194 Specific, existing or new, features of networking protocols to enable 195 delivery of PVD identity and association with various network 196 information elements will be defined in companion design documents. 198 Link-specific and/or vendor-proprietary mechanisms for discovery of 199 PVD information, different from the IETF-defined mechanisms, can be 200 used by the nodes separately from or together with IETF-defined 201 mechanisms, as long as they allow to discover necessary elements of 202 the PVD(s). Another example of a delivery mechanism for PVDs are key 203 exchange or tunneling protocols, such as IKEv2 [RFC5996] that allow 204 transporting host configuration information. In all cases, by 205 default nodes must ensure that the lifetime of all dynamically 206 discovered PVD configuration is appropriately limited by the relevant 207 events - for example, if an interface media state change was 208 indicated, the previously discovered information may no longer be 209 valid and needs to be re-discovered or confirmed. 211 It is expected, that how the node makes use of the PVD information, 212 generally is independent of the specific particular mechanism/ 213 protocol that was used to receive the information. 215 It shall be possible for sources of PVD information to communicate 216 that some of their configuration elements could be used within a 217 context of other networks/PVDs. PVD-aware nodes, based on such 218 declaration and their policies, may choose to inject such elements 219 into some or all other PVDs they connect to. 221 In some network topologies, the network infrastructure elements may 222 need to advertise multiple PVDs. The details of how this is done 223 generally will be defined in the individual companion design 224 documents. However, where different design choices are possible, the 225 choice that requires smaller number of packets shall be preferred for 226 efficiency. 228 2.2. Implicit PVDs and incremental adoption of the explicit PVDs 230 It is likely that for a long time there may be networks which do not 231 advertise explicit PVD information, since deployment of any new 232 features in networking protocols is a relatively slow process. 234 When connected to networks, which don't advertise explicit PVD 235 information, PVD-aware node shall automatically create separate PVDs 236 for received configuration. Such PVDs are referred to in this 237 document as "implicit". 239 With implicit PVDs, PVD-aware nodes may still provide benefits to 240 their users as compared to non-PVD aware nodes, by using network 241 information from different interfaces separately and consistently to 242 serve network connection requests, following best practices described 243 in Section 5. 245 In the mixed mode, where e.g., multiple networks are available on the 246 link the interface is attached to, and only some of the networks 247 advertise PVD information, the PVD-aware node shall create explicit 248 PVDs based on explicitly learned PVD information, and associate the 249 rest of the configuration with an implicit PVD created for that 250 interface. 252 2.3. Relationship between PVDs and interfaces 254 By default, implicit PVDs are limited to network configuration 255 information received on a single interface. If additional 256 information is available to the host through mechanisms out of scope 257 of this document, the host may form implicit PVDs with different 258 granularity, such as e.g. spanning multiple interfaces (an example 259 scenario, where this may be useful, is a Homenet with a router that 260 has multiple internal interfaces). 262 Explicit PVDs, in practice will often also be scoped to a 263 configuration related to a particular interface, however per this 264 architecture there is no such requirement or limitation and as 265 defined in this architecture, explicit PVDs may include information 266 related to more than one interfaces, if the node learns presence of 267 the same PVD on those interfaces and the authentication of the PVD ID 268 meets the level required by the node policy (generally, 269 authentication of a PVD ID may be also required in scenarios, 270 involving only one connected interface and/or PVD). 272 It is an intent of this architecture to support such scenarios among 273 others. Hence, it shall be noted that no hierarchical relationship 274 exists between interfaces and PVDs: it is possible for multiple PVDs 275 to be simultaneously accessible over one interface, as well as single 276 PVD to be simultaneously accessible over multiple interfaces. 278 2.4. PVD identity/naming 280 For explicit PVDs, PVD ID (globally unique ID, that possibly is 281 human-readable) is received as part of that information. For 282 implicit PVDs, the node assigns a locally generated with a high 283 probability of being globally unique ID to each implicit PVD. 285 PVD-aware node may use these IDs to choose a PVD with matching ID for 286 special-purpose connection requests, in accordance with node policy 287 or choice by advanced applications, and/or to present human-readable 288 representation of the IDs to the end-user for selection of Internet- 289 connected PVDs. 291 A single network provider may operate multiple networks, including 292 networks at different locations. In such cases, the provider may 293 chose whether to advertise single or multiple PVD identities at all 294 or some of those networks, as it suits their business needs. This 295 architecture doesn't impose specific requirements in this regard. 297 When multiple nodes are connected to the same link, where one or more 298 explicit PVDs are available, this architecture assumes that the 299 information about all available PVDs is advertized by the networks to 300 all the connected nodes. At the same time, the connected nodes may 301 have different heuristics, policies and/or other settings, including 302 configured set of their trusted PVDs, which may lead to different 303 PVDs actually being used by different nodes for their connections. 305 Possible extensions, where different sets of PVDs may be advertised 306 by the networks to different connected nodes, are out of scope of 307 this document. 309 2.5. Relationship to dual-stack networks 311 When applied to dual-stack networks, the PVD definition allows for 312 multiple PVDs to be created, where each PVD contain information for 313 only one address family, or for a single PVD that contains 314 information about multiple address families. This architecture 315 requires that accompanying design documents for the PVD-related 316 protocol changes must support PVDs containing information from 317 multiple address families. PVD-aware nodes must be capable of 318 dealing with both single-family and multi-family PVDs. 320 For explicit PVDs, the choice of either of the approaches is a policy 321 decision of a network administrator and/or node user/administrator. 322 Since some of the IP configuration information that can be learned 323 from the network can be applicable to multiple address families (for 324 instance DHCP address selection option [RFC7078]), it is likely that 325 dual-stack networks will deploy single PVDs for both address 326 families. 328 For implicit PVDs, by default PVD-aware nodes shall including 329 multiple IP families into single implicit PVD created for an 330 interface. At the time of writing of this document in dual-stack 331 networks it appears to be a common practice for configuration of both 332 address families to be provided by a single source. 334 A PVD-aware node that provides API to use / enumerate / inspect PVDs 335 and/or their properties shall provide ability to filter PVDs and/or 336 their properties by address family. 338 2.6. Elements of PVD 340 3. Conveying PVD information using DHCPv6 and Router Advertisements 342 DHCPv6 and Router Advertisements are the two most common methods of 343 configuring hosts and they would need to be extended to convey 344 explicit PVD information. There are several things that need to be 345 considered before finalizing a mechanism to augment DHCPv6 and RAs 346 with PvD information. 348 3.1. Separate messages or one message 350 When information from several PVDs is available at the same 351 configuration source, there are two possibilities regarding how to 352 send these out. One way is to send information from different 353 provisioning domains in separate messages. The other is to combine 354 information from several PVDs onto one message. The latter method 355 has the advantage of being more efficient but could have issues due 356 to authentication and authorization issues as well as potential 357 issues with accommodating common information and information not 358 tagged with any PVD information. 360 3.2. Securing the PVD information 362 DHCPv6 and RAs both provide some form of authentication that ensures 363 the identity of the source as well as the integrity of the contents 364 that have been secured. While this is useful, the authenticity of 365 the information provides no information whether the configuration 366 source is actually allowed to provide information from a given PVD. 367 In order to do be able to do this, there must be a mechanism for the 368 owner of the PVD to attach some form of authorization token to the 369 configuration information that is delivered. 371 3.3. Backward compatibility 373 The extensions to RAs and DHCPv6 should be defined in such a manner 374 than unmodified hosts (i.e. hosts not aware of PvDs) will continue 375 to function as well as they did before the PvD information got added. 376 This could imply that some information may need to be duplicated in 377 order to be conveyed to legacy hosts. Similarly PvD aware hosts need 378 to be able to handle legacy configuration sources which do not 379 provide PvD information. There are also several initiatives ongoing 380 that are aimed at adding some form of additional information to 381 prefixes [refs to draft-bhandari and draft-korhonen] and any new 382 mechanism should try to consider co-existence with these existing 383 mechanisms. 385 3.4. Selective propagation 387 When a configuration source has information regarding several PvDs it 388 is not clear whether it should provide information about all of them 389 to any host that requests info from it. While it may be reasonable 390 in some cases, this might become an unreasonable burden once the 391 number of PvDs starts increasing. One way to restrict the 392 propagation of useless information is for the host to select the PvD 393 information they desire in their request to the configuration source. 394 One way this could be accomplished is by using an ORO with the PvDs 395 that are of interest. The configuration source can then respond with 396 only the requested information. 398 By default, a configuration source SHOULD provide information related 399 to all provisioning domains without expecting the client to request 400 the PvD(s) it requires. This is necessary to ensure that hosts that 401 do not support requesting selective PvD information will continue to 402 work. Also note that IPv6 neighbor discovery does not provide any 403 functionality analogous to the DHCPv6 ORO. 405 In this case, when a host receives PvD information it does not 406 require, the information can simply be discarded. Also, in 407 constrained networks such as LLNs, the amount of configuration 408 information needs to be restricted to ensure that the load on the 409 hosts is bearable while keeping the information identical across all 410 the hosts. 412 In case selective propogation is required, some form of PvD discovery 413 mechanism needs to be specified so that hosts/applications can be 414 pre-provisioned to request a specific PvD. Alternately, the set of 415 PvDs that the network can provide to the host can be propogated to 416 the host using RAs or stateless DHCPv6. The discovery mechanism may 417 potentially support the discovery of available PvDs on a per-host 418 basis. 420 3.5. Retracting/updating PvD information 422 After the PvD information is provided to the host it may be outdated 423 or updated with newer information before the hosts would normally 424 request updates. Thos would require the mchanism to be able to 425 update and/or withdraw all (or some subset) of information related to 426 a given PvD. For efficiency reasons, there should be a way to specify 427 that all the information from the PvD needs to be reconfigured 428 instead of individually updating each item associated with the PvD. 430 3.6. Conveying configuration information using IKEv2 432 Internet Key Exchange protocol version 2 (IKEv2) [RFC5996] [RFC5739] 433 is another widely used and a popular method of configuring IP 434 information in a host. In the case of IKEv2 the provisioning domain 435 could actually be implicitly learnt from the Identification - 436 Responder (IDr) payloads the IKEv2 initiator and the responder inject 437 during the IKEv2 exchange. The IP configuration may depend on the 438 named IDr. Another possibility could be adding specific provisioning 439 domain identifying payload extensions to IKEv2. All of the 440 considerations listed above for DHCPv6 and RAs potentialy apply to 441 IKEv2 as well. 443 4. Example network configurations and number of PVDs 445 4.1. A mobile node 446 As an example, consider a mobile node that has two network 447 interfaces: one is a mobile network interface, the other is a Wi-Fi 448 network interface. When the mobile node connects only to the mobile 449 network, it will typically have one PvD, implicit or explicit. Then 450 when the mobile node discovers and connects to a Wi-Fi network, it 451 will have zero or more (typically - one) additional PvD(s). 453 Some of the existing OS implementations only allow one active network 454 connection. In that case, only the PVD(s) associated with that 455 interface will be connected PvD at any given time. 457 As an example, the mobile network can explicitly deliver the PvD 458 information through the PDP context activation process. Then the PvD 459 aware mobile node will treat the mobile network as an explicit PvD. 460 Conversely, the legacy Wi-Fi network may not explicitly communicate 461 the PvD information to the mobile node. The PvD aware mobile node 462 will treat the network configuration of the Wi-Fi network as 463 associated with an implicit PvD in this case. 465 The following diagram illustrates the use of different PvDs in this 466 scenario: 468 <------ Wi-Fi 'Internet' PvD ------> 469 +--------+ 470 | +----+ | +----+ _ __ _ _ 471 | |WiFi| | | | ( ` ) ( ` )_ 472 | |-IF +-|----+ |--------------------------( `) 473 | | | | |WiFi| ( ) (_ Internet _) 474 | +----+ | | AP | ( ) `- __ _) - 475 | | | | ( Service ) 476 | | +----+ ( Provider's ) 477 | | ( Networks - 478 | +----+ | `_ ) _ _ 479 | |CELL| | ( ) ( ` )_ 480 | |-IF +-|-------------------------------------( `) 481 | | | | (_ __) (_ Internet _) 482 | +----+ | `- -- `- __ _) - 483 +--------+ 484 <------- Mobile 'Internet' PvD -----------> 486 An example PvD use with Wi-Fi and mobile interfaces. 488 4.2. A node with a VPN connection 490 If the node has established a VPN connection, zero or more (typically 491 - one) additional PvD(s) will be created. These may be implicit or 492 explicit PvD(s). The routing to the IP addresses within this PvD 493 will be set up via the VPN connection, and the routing to addresses 494 outside the scope of this PvD will remain unaffected. If there were 495 already N connected PvDs on the node prior to establishing VPN 496 connection, once a VPN session is connected typically the number of 497 PvDs will become N+1. 499 The following diagram illustrates the use of different PvDs in this 500 scenario: 502 <------ 'Internet' PvD ------> 503 +--------+ 504 | +----+ | +----+ _ __ _ _ 505 | |Phy | | | | ( ` ) ( ` )_ 506 | |-IF +-|----+ |--------------------------( `) 507 | | | | | | ( ) (_ Internet _) 508 | +----+ | | | ( ) `- __ _) - 509 | | |Home| ( Service ) || 510 | | |gate| ( Provider's ) || 511 | | |-way| ( Network - || 512 | +----+ | | | `_ ) +---------+ +------------+ 513 | |VPN | | | | ( ) | VPN | | | 514 | |-IF +-|----+ |---------------------------+ Gateway |--+ Private | 515 | | | | | | (_ __) | | | Services | 516 | +----+ | +----+ `- -- +---------+ +------------+ 517 +--------+ 518 <------------- Explicit 'VPN' PvD -----------> 520 An example PvD use with VPN. 522 4.3. A home network and a network operator with multiple PvDs 524 An operator may use separate PvDs for individual services which they 525 offer to their customers. This may be used so that services can be 526 designed and provisioned to be completely independent of each other 527 allowing for complete flexibility in combinations of services which 528 are offered to customers. 530 From the perspective of the home network and the node, this model is 531 functionally very similar to being multihomed to multiple upstream 532 operators: Each of the different services offered by the service 533 provider is its own PvD with associated PvD information. In this 534 case, the operator may provide a generic/default PvD (explicit or 535 implicit), which provides Internet access to the customer. 536 Additional services would then be provisioned as explicit PvDs for 537 subscribing customers. 539 The following diagram illustrates this, using video-on-demand as a 540 service-specific PvD: 542 <------ Implicit 'Internet' PvD ------> 543 +----+ +----+ _ __ _ _ 544 | | | | ( ` ) ( ` )_ 545 | PC +-----+ |--------------------------( `) 546 | | | | ( ) (_ Internet _) 547 +----+ | | ( ) `- __ _) - 548 |Home| ( Service ) 549 |gate| ( Provider's ) 550 |-way| ( Network - 551 +-----+ | | `_ ) +---------+ 552 | Set | | | ( ) |ISP Video| 553 | Top +----+ |---------------------------+on Demand| 554 | Box | | | (_ __) | Service | 555 +-----+ +----+ `- -- +---------+ 556 <-- Explicit 'Video-on-Demand' PvD --> 558 An example PvD use with a homet network. 560 In this case, the number of PVDs that a single operator could 561 provision is based on the number of independently provisioned 562 services which they offer. Some examples may include: 564 o Real-time packet voice 566 o Streaming video 568 o Interactive video (n-way video conferencing) 570 o Interactive gaming 572 o Best effort / Internet access 574 5. Reference model of PVD-aware node 576 5.1. Constructions and maintenance of separate PVDs 578 It is assumed that normally, configuration information contained in a 579 single PVD, shall be sufficient for a node to fulfill a network 580 connection request by an application, and hence there should be no 581 need to attempt to merge information across different PVDs. 583 Nevertheless, even when a PVD lack some parts of the configuration, 584 merging of information from different PVD(s) shall not be done 585 automatically, since typically it would lead to issues described in 586 [RFC6418]. 588 A node may use other sources, such as e.g., node local policy, user 589 input or other mechanisms, not defined by IETF, to either construct a 590 PVD entirely (analogously to static IP configuration of an 591 interface), or supplement with particular elements all or some PVDs 592 learned from the network, or potentially merge information from 593 different PVDs, if such merge is known to the node to be safe, based 594 on explicit policies. 596 As an example, node administrator could inject a not ISP-specific DNS 597 server into PVDs for any of the networks the node could become 598 attached to. Such creation / augmentation of PVD(s) could be static 599 or dynamic. The particular implementation mechanisms are outside of 600 the scope of this document. 602 5.2. Consistent use of PVDs for network connections 604 PVDs enable PVD-aware nodes to use consistently a correct set of 605 configuration elements to serve the specific network requests from 606 beginning to end. This section describes specific examples of such 607 consistent use. 609 5.2.1. Name resolution 611 When PVD-aware node needs to resolve a name of the destination used 612 by a connection request, the node could decide to use one, or 613 multiple PVDs for a given name lookup. 615 The node shall chose one PVD, if e.g., the node policy required to 616 use a particular PVD for a particular purpose (e.g. to download an 617 MMS using a specific APN over a cellular connection). To make the 618 choice, the node could use a match of the PVD DNS suffix or other 619 form of PVD ID, as determined by the node policy. 621 The node may pick multiple PVDs, if e.g., they are general purpose 622 PVDs providing connectivity to the Internet, and the node desires to 623 maximize chances for connectivity in Happy Eyeballs style. In this 624 case, the node could do the lookups in parallel, or in sequence. 625 Alternatively, the node may use for the lookup only one PVD, based on 626 the PVD connectivity properties, user choice of the preferred 627 Internet PVD, etc. 629 In either case, by default the node uses information obtained in a 630 name service lookup to establish connections only within the same PVD 631 from which the lookup results were obtained. 633 For simplicity, when we say that name service lookup results were 634 obtained from a PVD, what we mean is that the name service query was 635 issued against a name service the configuration of which is present 636 in a particular PVD. In that sense, the results are "from" that 637 particular PVD. 639 Some nodes may support transports and/or APIs, which provide an 640 abstraction of a single connection, aggregating multiple underlying 641 connections. MPTCP [RFC6182] is an example of such transport 642 protocol. For the connections provided by such transports/APIs, a 643 PVD-aware node may use different PVDs for servicing of that logical 644 connection, provided that all operations on the underlying 645 connections are done consistently within their corresponding PVD(s). 647 5.2.2. Next-hop and source address selection 649 For the purpose of this discussion, let's assume the preceding name 650 lookup succeeded in a particular PVD. For each obtained destination 651 address, the node shall perform a next-hop lookup among routers, 652 associated with that PVD. As an example, such association could be 653 determined by the node via matching the source address prefixes/ 654 specific routes advertized by the router against known PVDs, or 655 receiving explicit PVD affiliation advertized through a new Router 656 Discovery [RFC4861] option. 658 For each destination, once the best next-hop is found, the node 659 selects best source address according to the [RFC6724] rules, but 660 with a constraint that the source address must belong to a range 661 associated with the used PVD. If needed, the node would use the 662 prefix policy from the same PVD for the best source address selection 663 among multiple candidates. 665 When destination/source pairs are identified, then they are sorted 666 using the [RFC6724] destination sorting rules and the prefix policy 667 table from the used PVD. 669 5.2.3. Listening applications 671 Consider a host, connected to several PVDs and running an application 672 that opens a listening socket/transport API object, where the 673 application authorized by the host policy to use a subset connected 674 PVDs, that may or may not be equal to the complete set of the 675 connected PVDs. For example, in case there are different PVDs on a 676 Wi-Fi and a cellular interfaces, for general internet traffic the 677 host could decide to use only one preferred PVD at a time (and 678 accordingly, advertise to remote peers the host name and addresses 679 associated with that PVD), or it could decide to use one PVD as a 680 preferred one by default for outgoing connections, while still 681 allowing use of the other PVDs simultaneously. Another example is 682 where a host established a VPN connection. Depending on the security 683 policies provisioned on the host, all or some applications may or may 684 not be allowed to use the VPN PVD and/or other PVDs. 686 For non-PVD aware applications, the OS policies determine the 687 authorized set of PVDs and the preferred outgoing PVD. For PVD-aware 688 applications, both the authorized set of PVDs and the default 689 outgoing PVD can be determined as a meet of the subset produced by 690 the OS policies and the set of PVD IDs or characteristics, provided 691 by the application. The application input could be provided on per- 692 application, per-transport-API-object or per-transport-API-call 693 basis. The API for application input may have an option for to 694 specify whether the input should be treated as a preference instead 695 of a requirement. 697 5.2.3.1. Processing of incoming traffic 699 Unicast IP packets are received on a specific IP address, associated 700 with a PVD. For multicast packets, the host can derive the 701 association with a PVD from other configuration information, such as 702 an explicit PVD property or local policy. 704 The node OS or middleware may apply more advanced techniques for 705 determination of the resultant PVD and/or authorization of the 706 incoming traffic. Those techniques are outside of scope of this 707 document. 709 If the determined receiving PVD of the packet is not in the allowed 710 subset of PVDs for the particular app/transport API object, the 711 packet should be handled in the same way as if there were no 712 listener. 714 5.2.3.1.1. Connection-oriented APIs 716 For connection-oriented APIs, when the initial incoming packet is 717 received, the packet PVD is remembered for the established 718 connection, and used for handling of the outgoing traffic for that 719 connection. While typically the connection-oriented APIs use 720 connection-oriented transport protocol, such as TCP, it is possible 721 to have a connection-oriented API, which uses generally connection- 722 less transport protocol, such as UDP. For APIs/protocols, which 723 support multiple IP traffic flows associated with a single transport 724 API connection object (such as e.g. multi path TCP), the processing 725 rules may be adjusted accordingly. 727 5.2.3.1.2. Connection-less APIs 729 For connection-less APIs, the host should provide an API, which PVD- 730 aware applications could use to query the PVD associated with the 731 packet. For outgoing traffic on this transport API object, the OS 732 should use the selected outgoing PVDs, determined as described above. 734 5.2.4. Enforcement of security policies 735 PVDs by themselves don't define and can't be used for communication 736 of security policies. When implemented in a network, this 737 architecture provides the host with information about the connected 738 networks. The actual behavior of the host then depends on the host 739 policies (provisioned through mechanisms out of scope of this 740 document), applied taking received PVD information into account. In 741 some scenarios, such as e.g . VPN, such policies could require the 742 host to use only a particular VPN PVD for some/all of the 743 applications' traffic (VPN 'disable split tunneling' also known as 744 'force tunneling' behavior), or apply such restrictions only to 745 select applications and allow simultaneous use of the VPN PVD 746 togetheer with the other connected PVDs by the other or all 747 applications (VPN 'split tunneling' behavior). 749 5.3. Connectivity tests 751 Although some PVDs may appear as valid candidates for PVD selection 752 (e.g. good link quality, consistent connection parameters, etc.), 753 they may provide limited or no connectivity to the desired network or 754 the Internet. For example, some PVDs provide limited IP connectivity 755 (e.g., scoped to the link or to the access network), but require the 756 node to authenticate through a web portal to get full access to the 757 Internet. This may be more likely to happen for PVDs, which are not 758 trusted by the given PVD-aware node. 760 An attempt to use such PVD may lead to limited network connectivity 761 or connection failures for applications. To prevent the latter, a 762 PVD-aware node may perform connectivity test for the PVD, before 763 using it to serve network connection requests of the applications. 764 In current implementations, some nodes do that, for instance, by 765 trying to reach a dedicated web server (e.g., see [RFC6419]). 767 Per Section 5.2, a PVD-aware node shall maintain and use multiple 768 PVDs separately. The PVD-aware node shall perform connectivity test 769 and, only after validation of the PVD, consider using it to serve 770 application connections requests. Ongoing connectivity tests are 771 also required, since during the IP session, the end-to-end 772 connectivity could be disrupted for various reasons (e.g. poor L2, 773 IP QoS issues); hence a connectivity monitoring function is needed to 774 check the connectivity status and remove the PVD from the set of 775 usable PVDs if necessary. 777 There may be cases where a connectivity test for PVD selection may be 778 not appropriate and should be complemented, or replaced, by PVD 779 selection based on other factors. This could be realized e.g., by 780 leveraging some 3GPP and IEEE mechanisms, which would allow to expose 781 some PVD characteristics to the node (e.g. 3GPP Access Network 782 Discovery and Selection Function (ANDSF) [TS23.402], IEEE 802.11u 783 [IEEE802.11u]/ANQP). 785 5.4. Relationship to interface management and connection managers 786 Current devices such as mobile handsets make use of proprietary 787 mechanisms and custom applications to manage connectivity in 788 environments with multiple interfaces and multiple sets of network 789 configurations. These mechanisms or applications are commonly known 790 as connection managers [RFC6419]. 792 Connection managers sometimes rely on policy servers to allow the 793 node, connected to multiple networks, perform the network selection. 794 They can also make use of routing guidance from the network (e.g. 795 3GPP ANDSF [TS23.402]). Although connection managers solve some 796 connectivity problems, they rarely address the network selection 797 problems in a comprehensive manner. With proprietary solutions, it 798 is challenging to present a coherent behaviour to the end user of the 799 device, as different platforms present different behaviours even when 800 connected to the same network, with the same type of interface, and 801 for the same purpose. 803 6. PVD support in APIs 805 In all cases changes in available PVDs must be somehow exposed, 806 appropriately for each of the approaches. 808 6.1. Basic 810 Applications are not PVD-aware in any manner, and only submit 811 connection requests. The node performs PVD selection implicitly, 812 without any otherwise applications participation, and based purely on 813 node-specific administrative policies and/or choices made by the user 814 in a user interface provided by the operating environment, not by the 815 application. 817 As an example, such PVD selection can be done at the name service 818 lookup step, by using the relevant configuration elements, such as 819 e.g., those described in [RFC6731]. As another example, the PVD 820 selection could be done based on application identity or type (i.e., 821 a node could always use a particular PVD for a VOIP application). 823 6.2. Intermediate 825 Applications indirectly participate in selection of PVD by specifying 826 hard requirements and soft preferences. As an example, a real time 827 communication application, intending to use the connection for 828 exchange of real time audio/video data, may indicate a preference or 829 a requirement for connection quality, which could affect PVD 830 selection (different PVDs could correspond to Internet connections 831 with different loss rates and latencies). Another example is a 832 connection of an infrequently executed background activity, which 833 checks for availability of applications updates and performs large 834 downloads - for such connections, a cheaper or zero cost PVD may be 835 preferrable, even if such connection will have a higher relative loss 836 rate or lower bandwidth. The node performs PVD selection, based on 837 applications inputs and policies and/or user preferences. Some / all 838 properties of the resultant PVD may be exposed to applications. 840 6.3. Advanced 842 PVDs are directly exposed to applications, for enumeration and 843 selection. Node polices and/or user choices, may still override the 844 application preferences and limit which PVD(s) can be enumerated and/ 845 or used by the application, irrespectively of any preferences which 846 application may have specified. Depending on the implementation, 847 such restrictions, imposed per node policy and/or user choice, may or 848 may not be visible to the application. 850 7. PVD-aware nodes trust to PVDs 852 7.1. Untrusted PVDs 854 Implicit and explicit PVDs for which no trust relationship exists are 855 considered untrusted. Only PVDs, which meet the requirements in 856 Section 7.2, are trusted; any other PVD is untrusted. 858 In order to avoid various forms of misinformation that can be 859 asserted when PVDs are untrusted, nodes that implement PVD separation 860 cannot assume that two explicit PVDs with the same identifier are 861 actually the same PVD. A node that did make this assumption would be 862 vulnerable to attacks where for example an open Wifi hotspot might 863 assert that it was part of another PVD, and thereby might draw 864 traffic intended for that PVD onto its own network. 866 Since implicit PVD identifiers are synthesized by the node, this 867 issue cannot arise with implicit PVDs. 869 Mechanisms exist (for example, [RFC6731]) whereby a PVD can provide 870 configuration information that asserts special knowledge about the 871 reachability of resources through that PVD. Such assertions cannot 872 be validated unless the node has a trust relationship with the PVD; 873 assertions of this type therefore must be ignored by nodes that 874 receive them from untrusted PVDs. Failure to ignore such assertions 875 could result in traffic being diverted from legitimate destinations 876 to spoofed destinations. 878 7.2. Trusted PVDs 880 Trusted PVDs are PVDs for which two conditions apply. First, a 881 trust relationship must exist between the node that is using the PVD 882 configuration and the source that provided that configuration; this 883 is the authorization portion of the trust relationship. Second, 884 there must be some way to validate the trust relationship. This is 885 the authentication portion of the trust relationship. Two 886 mechanisms for validating the trust relationship are defined. 888 It shall be possible to validate the trust relationship for all 889 advertised elements of a trusted PVD, irrespectively of whether the 890 PVD elements are communicated as a whole, e.g. in a single DHCP 891 option, or separately, e.g. in supplementary RA options. Whether or 892 not this is feasible to provide mechanisms to implement trust 893 relationship for all PVD elements, will be determined in the 894 respective companion design documents. 896 7.2.1. Authenticated PVDs 898 One way to validate the trust relationship between a node and the 899 source of a PVD is through the combination of cryptographic 900 authentication and an identifier configured on the node. In some 901 cases, the two could be the same; for example, if authentication is 902 done with a shared secret, the secret would have to be associated 903 with the PVD identifier. Without a (PVD Identifier, shared key) 904 tuple, authentication would be impossible, and hence authentication 905 and authorization are combined. 907 However, if authentication is done using some public key mechanism 908 such as a TLS cert or DANE, authentication by itself isn't enough, 909 since theoretically any PVD could be authenticated in this way. In 910 addition to authentication, the node would need to be configured to 911 trust the identifier being authenticated. Validating the 912 authenticated PVD name against a list of PVD names configured as 913 trusted on the node would constitute the authorization step in this 914 case. 916 7.2.2. PVDs trusted by attachment 918 In some cases a trust relationship may be validated by some means 919 other than described in Section 7.2.1, simply by virtue of the 920 connection through which the PVD was obtained. For instance, a 921 handset connected to a mobile network may know through the mobile 922 network infrastructure that it is connected to a trusted PVD, and 923 whatever mechanism was used to validate that connection constitutes 924 the authentication portion of the PVD trust relationship. 925 Presumably such a handset would be configured from the factory, or 926 else through mobile operator or user preference settings, to trust 927 the PVD, and this would constitute the authorization portion of this 928 type of trust relationship. 930 8. Acknowledgements 932 This document was created as a product of a MIF architecture design 933 team and includes contributions from the MIF working group 934 participants. 936 9. IANA Considerations 938 This memo includes no request to IANA. 940 10. Security Considerations 941 There are at least three different form of attacks that can be 942 performed using configuration sources that use multiple provisioning 943 domains. 945 Tampering with configuration information provided An attacker may 946 attempt to modify the information provided inside the PVD 947 container option. These attacks can easily be prevented by using 948 the message integrity features provided by the underlying protocol 949 used to carry the configuration information. e.g. SEND [RFC3971] 950 would detect any form of tampering with the RA contents and the 951 DHCPv6 [RFC3315] AUTH option that would detect any form of 952 tampering with the DHCPv6 message contents. This attack can also 953 be performed by a compromised configuration source by modifying 954 information inside a specific , in which case the mitigations 955 proposed in the next subsection may be helpful. 957 Rogue configuration source A compromised configuration source such as 958 a router or a DHCPv6 server may advertise information about PvDs 959 that it is not authorized to advertise. e.g. A coffee shop may 960 advertise configuration information purporting to be from an 961 enterprise and may try to attract enterprise related traffic. The 962 only real way to avoid this is that the PvD related configuration 963 container contains embedded authentication and authorization 964 information from the owner of the PvD. Then, this attack can be 965 detected by the client by verifying the authentication and 966 authorization information provided inside the PVD container option 967 after verifying its trust towards the PvD owner (e.g. a 968 certificate with a well-known/common trust anchor). 970 Replay attacks A compromised configuration source or an on-link 971 attacker may try to capture advertised configuration information 972 and replay it on a different link or at a future point in time. 973 This can be avoided by including some replay protection mechanism 974 such as a timestamp or a nonce inside the PvD container to ensure 975 freshness of the provided information. 977 11. References 979 11.1. Normative References 981 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 982 Requirement Levels", BCP 14, RFC 2119, March 1997. 984 11.2. Informative References 986 [IEEE802.11u] 987 IEEE, "IEEE Standard 802.11u-2011 (Amendment 9: 988 Interworking with External Networks)", 2011. 990 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C. and 991 M. Carney, "Dynamic Host Configuration Protocol for IPv6 992 (DHCPv6)", RFC 3315, July 2003. 994 [RFC3971] Arkko, J., Kempf, J., Zill, B. and P. Nikander, "SEcure 995 Neighbor Discovery (SEND)", RFC 3971, March 2005. 997 [RFC4861] Narten, T., Nordmark, E., Simpson, W. and H. Soliman, 998 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 999 September 2007. 1001 [RFC5739] Eronen, P., Laganier, J. and C. Madson, "IPv6 1002 Configuration in Internet Key Exchange Protocol Version 2 1003 (IKEv2)", RFC 5739, February 2010. 1005 [RFC5996] Kaufman, C., Hoffman, P., Nir, Y. and P. Eronen, "Internet 1006 Key Exchange Protocol Version 2 (IKEv2)", RFC 5996, 1007 September 2010. 1009 [RFC6182] Ford, A., Raiciu, C., Handley, M., Barre, S. and J. 1010 Iyengar, "Architectural Guidelines for Multipath TCP 1011 Development", RFC 6182, March 2011. 1013 [RFC6418] Blanchet, M. and P. Seite, "Multiple Interfaces and 1014 Provisioning Domains Problem Statement", RFC 6418, 1015 November 2011. 1017 [RFC6419] Wasserman, M. and P. Seite, "Current Practices for 1018 Multiple-Interface Hosts", RFC 6419, November 2011. 1020 [RFC6724] Thaler, D., Draves, R., Matsumoto, A. and T. Chown, 1021 "Default Address Selection for Internet Protocol Version 6 1022 (IPv6)", RFC 6724, September 2012. 1024 [RFC6731] Savolainen, T., Kato, J. and T. Lemon, "Improved Recursive 1025 DNS Server Selection for Multi-Interfaced Nodes", RFC 1026 6731, December 2012. 1028 [RFC7078] Matsumoto, A., Fujisaki, T. and T. Chown, "Distributing 1029 Address Selection Policy Using DHCPv6", RFC 7078, January 1030 2014. 1032 [TS23.402] 1033 3GPP, "3GPP TS 23.402; Architecture enhancements for non- 1034 3GPP accesses; release 12", . 1036 Author's Address 1038 Dmitry Anipko, editor 1039 Microsoft Corporation 1040 One Microsoft Way 1041 Redmond, WA 98052 1042 USA 1044 Phone: +1 425 703 7070 1045 Email: dmitry.anipko@microsoft.com