idnits 2.17.1 draft-ietf-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 102 has weird spacing: '...uration and/o...' -- The document date (May 03, 2014) is 3645 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'IEEE802.11u' is defined on line 862, 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: 0 errors (**), 0 flaws (~~), 3 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 May 03, 2014 5 Expires: November 02, 2014 7 Multiple Provisioning Domain Architecture 8 draft-ietf-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 November 02, 2014. 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 . . . . . . . . . . . . . . . . . . . . . . . . . 2 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 5. Reference model of PVD-aware node . . . . . . . . . . . . . . 10 72 5.1. Constructions and maintenance of separate PVDs . . . . . . 10 73 5.2. Consistent use of PVDs for network connections . . . . . . 10 74 5.2.1. Name resolution . . . . . . . . . . . . . . . . . . . 10 75 5.2.2. Next-hop and source address selection . . . . . . . . 11 76 5.2.3. Listening applications . . . . . . . . . . . . . . . . 12 77 5.2.3.1. Processing of incoming traffic . . . . . . . . . . 12 78 5.2.3.1.1. Connection-oriented APIs . . . . . . . . . . . 13 79 5.2.3.1.2. Connection-less APIs . . . . . . . . . . . . . 13 80 5.2.4. Enforcement of security policies . . . . . . . . . . . 13 81 5.3. Connectivity tests . . . . . . . . . . . . . . . . . . . . 13 82 5.4. Relationship to interface management and connection manage 14 83 6. PVD support in APIs . . . . . . . . . . . . . . . . . . . . . 14 84 6.1. Basic . . . . . . . . . . . . . . . . . . . . . . . . . . 15 85 6.2. Intermediate . . . . . . . . . . . . . . . . . . . . . . . 15 86 6.3. Advanced . . . . . . . . . . . . . . . . . . . . . . . . . 15 87 7. PVD-aware nodes trust to PVDs . . . . . . . . . . . . . . . . 15 88 7.1. Untrusted PVDs . . . . . . . . . . . . . . . . . . . . . . 15 89 7.2. Trusted PVDs . . . . . . . . . . . . . . . . . . . . . . . 16 90 7.2.1. Authenticated PVDs . . . . . . . . . . . . . . . . . . 16 91 7.2.2. PVDs trusted by attachment . . . . . . . . . . . . . . 17 92 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17 93 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 94 10. Security Considerations . . . . . . . . . . . . . . . . . . . 17 95 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 96 11.1. Normative References . . . . . . . . . . . . . . . . . . 18 97 11.2. Informative References . . . . . . . . . . . . . . . . . 18 98 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 19 100 1. Introduction 101 Nodes attached to multiple networks may encounter problems due to 102 conflict of the networks configuration and/or simultaneous use of 103 the multiple available networks. While existing implementations 104 apply various techniques ([RFC6419]) to tackle such problems, in many 105 cases the issues may still appear. The MIF problem statement 106 document [RFC6418] describes the general landscape as well as 107 discusses many specific issues and scenarios details. 109 Problems, enumerated in [RFC6418], can be grouped into 3 categories: 111 1. Lack of consistent and distinctive management of configuration 112 elements, associated with different networks. 114 2. Inappropriate mixed use of configuration elements, associated 115 with different networks, in the course of a particular network 116 activity / connection. 118 3. Use of a particular network, not consistent with the intent of 119 the scenario / involved parties, leading to connectivity failure 120 and / or other undesired consequences. 122 An example of (1) is a single node-scoped list of DNS server IP 123 addresses, learned from different networks, leading to failures or 124 delays in resolution of names from particular namespaces; an example 125 of (2) is use of an attempt to resolve a name of a HTTP proxy server, 126 learned from a network A, with a DNS server, learned from a network 127 B, that is likely to fail; an example of (3) is use of an employer- 128 sponsored VPN connection for peer-to-peer connectivity, unrelated to 129 employment activities. 131 This architecture describes a solution to these categories of 132 problems, respectively, by: 134 1. Introducing a formal notion of the PVD, including PVD identity, 135 and ways for nodes to learn the intended associations among 136 acquired network configuration information elements. 138 2. Introducing a reference model for a PVD-aware node, preventing 139 inadvertent mixed use of the configuration information, which may 140 belong to different PVDs. 142 3. Providing recommendations on PVD selection based on PVD identity 143 and connectivity tests for common scenarios. 145 1.1. Requirements Language 147 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 148 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 149 document are to be interpreted as described in RFC 2119 [RFC2119]. 151 2. Definitions and types of PVDs 153 Provisioning Domain: a consistent set of network configuration 154 information. Classically, the entire set available on a single 155 interface is provided by a single source, such as network 156 administrator, and can therefore be treated as a single provisioning 157 domain. In modern IPv6 networks, multihoming can result in more than 158 one provisioning domain being present on a single link. In some 159 scenarios, it is also possible for elements of the same domain to be 160 present on multiple links. 162 Typical examples of information in a provisioning domain, learned 163 from the network, are: source address prefixes that can be used by 164 connections within the provisioning domain, IP address of DNS server, 165 name of HTTP proxy server if available, DNS suffixes associated with 166 the network, default gateway address etc. 168 PVD-aware node: a node that supports association of network 169 configuration information into PVDs, and using these PVDs to serve 170 requests for network connections in ways, consistent with 171 recommendations of this architecture. 173 2.1. Explicit PVDs 175 A node may receive explicit information from the network and/or other 176 sources, about presence of PVDs and association of particular network 177 information with a particular PVD. PVDs, constructed based on such 178 information, are referred to in this document as "explicit". 180 Protocol changes/extensions will likely be required to support the 181 explicit PVDs by IETF-defined mechanisms. As an example, one could 182 think of one or several DHCP options, carrying PVD identity and / or 183 its elements. A different approach could be to introduce a DHCP 184 option, which only carries identity of a PVD, while the association 185 of network information elements with that identity, is implemented by 186 the respective protocols - such as e.g., with a Router Discovery 187 [RFC4861] option associating an address range with a PVD. 189 Specific, existing or new, features of networking protocols to enable 190 delivery of PVD identity and association with various network 191 information elements will be defined in companion design documents. 193 Link-specific and/or vendor-proprietary mechanisms for discovery of 194 PVD information, different from the IETF-defined mechanisms, can be 195 used by the nodes separately from or together with IETF-defined 196 mechanisms, as long as they allow to discover necessary elements of 197 the PVD(s). Another example of a delivery mechanism for PVDs are key 198 exchange or tunneling protocols, such as IKEv2 [RFC5996] that allow 199 transporting host configuration information. In all cases, by 200 default nodes must ensure that the lifetime of all dynamically 201 discovered PVD configuration is appropriately limited by the relevant 202 events - for example, if an interface media state change was 203 indicated, the previously discovered information may no longer be 204 valid and needs to be re-discovered or confirmed. 206 It is expected, that how the host makes use of the PVD information, 207 generally is independent of the specific particular mechanism/ 208 protocol that was used to receive the information. 210 It shall be possible for sources of PVD information to communicate 211 that some of their configuration elements could be used within a 212 context of other networks/PVDs. PVD-aware nodes, based on such 213 declaration and their policies, may choose to inject such elements 214 into some or all other PVDs they connect to. 216 In some network topologies, the network infrastructure elements may 217 need to advertise multiple PVDs. The details of how this is done 218 generally will be defined in the individual companion design 219 documents. However, where different design choices are possible, the 220 choice that requires smaller number of packets shall be preferred for 221 efficiency. 223 2.2. Implicit PVDs and incremental adoption of the explicit PVDs 225 It is likely that for a long time there may be networks which do not 226 advertise explicit PVD information, since deployment of any new 227 features in networking protocols is a relatively slow process. 229 When connected to networks, which don't advertise explicit PVD 230 information, PVD-aware node shall automatically create separate PVDs 231 for received configuration. Such PVDs are referred to in this 232 document as "implicit". 234 With implicit PVDs, PVD-aware nodes may still provide benefits to 235 their users as compared to non-PVD aware nodes, by using network 236 information from different interfaces separately and consistently to 237 serve network connection requests, following best practices described 238 in Section 5. 240 In the mixed mode, where e.g., multiple networks are available on the 241 link the interface is attached to, and only some of the networks 242 advertise PVD information, the PVD-aware node shall create explicit 243 PVDs based on explicitly learned PVD information, and associate the 244 rest of the configuration with an implicit PVD created for that 245 interface. 247 2.3. Relationship between PVDs and interfaces 249 By default, implicit PVDs are limited to network configuration 250 information received on a single interface. If additional 251 information is available to the host through mechanisms out of scope 252 of this document, the host may form implicit PVDs with different 253 granularity, such as e.g. spanning multiple interfaces (an example 254 scenario, where this may be useful, is a Homenet with a router that 255 has multiple internal interfaces). 257 Explicit PVDs, in practice will often also be scoped to a 258 configuration related to a particular interface, however per this 259 architecture there is no such requirement or limitation and as 260 defined in this architecture, explicit PVDs may include information 261 related to more than one interfaces, if the node learns presence of 262 the same PVD on those interfaces and the authentication of the PVD ID 263 meets the level required by the node policy (generally, 264 authentication of a PVD ID may be also required in scenarios, 265 involving only one connected interface and/or PVD). 267 It is an intent of this architecture to support such scenarios among 268 others. Hence, it shall be noted that no hierarchical relationship 269 exists between interfaces and PVDs: it is possible for multiple PVDs 270 to be simultaneously accessible over one interface, as well as single 271 PVD to be simultaneously accessible over multiple interfaces. 273 2.4. PVD identity/naming 275 For explicit PVDs, PVD ID (globally unique ID, that possibly is 276 human-readable) is received as part of that information. For 277 implicit PVDs, the node assigns a locally generated with a high 278 probability of being globally unique ID to each implicit PVD. 280 PVD-aware node may use these IDs to choose a PVD with matching ID for 281 special-purpose connection requests, in accordance with node policy 282 or choice by advanced applications, and/or to present human-readable 283 representation of the IDs to the end-user for selection of Internet- 284 connected PVDs. 286 A single network provider may operate multiple networks, including 287 networks at different locations. In such cases, the provider may 288 chose whether to advertise single or multiple PVD identities at all 289 or some of those networks, as it suits their business needs. This 290 architecture doesn't impose specific requirements in this regard. 292 When multiple nodes are connected to the same link, where one or more 293 explicit PVDs are available, this architecture assumes that the 294 information about all available PVDs is advertized by the networks to 295 all the connected nodes. At the same time, the connected nodes may 296 have different heuristics, policies and/or other settings, including 297 configured set of their trusted PVDs, which may lead to different 298 PVDs actually being used by different nodes for their connections. 300 Possible extensions, where different sets of PVDs may be advertised 301 by the networks to different connected nodes, are out of scope of 302 this document. 304 2.5. Relationship to dual-stack networks 306 When applied to dual-stack networks, the PVD definition allows for 307 multiple PVDs to be created, where each PVD contain information for 308 only one address family, or for a single PVD that contains 309 information about multiple address families. This architecture 310 requires that accompanying design documents for the PVD-related 311 protocol changes must support PVDs containing information from 312 multiple address families. PVD-aware nodes must be capable of 313 dealing with both single-family and multi-family PVDs. 315 For explicit PVDs, the choice of either of the approaches is a policy 316 decision of a network administrator and/or node user/administrator. 317 Since some of the IP configuration information that can be learned 318 from the network can be applicable to multiple address families (for 319 instance DHCP address selection option [RFC7078]), it is likely that 320 dual-stack networks will deploy single PVDs for both address 321 families. 323 For implicit PVDs, by default PVD-aware nodes shall including 324 multiple IP families into single implicit PVD created for an 325 interface. At the time of writing of this document in dual-stack 326 networks it appears to be a common practice for configuration of both 327 address families to be provided by a single source. 329 A PVD-aware node that provides API to use / enumerate / inspect PVDs 330 and/or their properties shall provide ability to filter PVDs and/or 331 their properties by address family. 333 2.6. Elements of PVD 335 3. Conveying PVD information using DHCPv6 and Router Advertisements 337 DHCPv6 and Router Advertisements are the two most common methods of 338 configuring hosts and they would need to be extended to convey 339 explicit PVD information. There are several things that need to be 340 considered before finalizing a mechanism to augment DHCPv6 and RAs 341 with PvD information. 343 3.1. Separate messages or one message 345 When information from several PVDs is available at the same 346 configuration source, there are two possibilities regarding how to 347 send these out. One way is to send information from different 348 provisioning domains in separate messages. The other is to combine 349 information from several PVDs onto one message. The latter method 350 has the advantage of being more efficient but could have issues due 351 to authentication and authorization issues as well as potential 352 issues with accommodating common information and information not 353 tagged with any PVD information. 355 3.2. Securing the PVD information 357 DHCPv6 and RAs both provide some form of authentication that ensures 358 the identity of the source as well as the integrity of the contents 359 that have been secured. While this is useful, the authenticity of 360 the information provides no information whether the configuration 361 source is actually allowed to provide information from a given PVD. 362 In order to do be able to do this, there must be a mechanism for the 363 owner of the PVD to attach some form of authorization token to the 364 configuration information that is delivered. 366 3.3. Backward compatibility 368 The extensions to RAs and DHCPv6 should be defined in such a manner 369 than unmodified hosts (i.e. hosts not aware of PvDs) will continue 370 to function as well as they did before the PvD information got added. 371 This could imply that some information may need to be duplicated in 372 order to be conveyed to legacy hosts. Similarly PvD aware hosts need 373 to be able to handle legacy configuration sources which do not 374 provide PvD information. There are also several initiatives ongoing 375 that are aimed at adding some form of additional information to 376 prefixes [refs to draft-bhandari and draft-korhonen] and any new 377 mechanism should try to consider co-existence with these existing 378 mechanisms. 380 3.4. Selective propagation 382 When a configuration source has information regarding several PvDs it 383 is not clear whether it should provide information about all of them 384 to any host that requests info from it. While it may be reasonable 385 in some cases, this might become an unreasonable burden once the 386 number of PvDs starts increasing. One way to restrict the 387 propagation of useless information is for the host to select the PvD 388 information they desire in their request to the configuration source. 389 One way this could be accomplished is by using an ORO with the PvDs 390 that are of interest. The configuration source can then respond with 391 only the requested information. 393 By default, a configuration source SHOULD provide information related 394 to all provisioning domains without expecting the client to request 395 the PvD(s) it requires. This is necessary to ensure that hosts that 396 do not support requesting selective PvD information will continue to 397 work. Also note that IPv6 neighbor discovery does not provide any 398 functionality analogous to the DHCPv6 ORO. 400 In this case, when a host receives PvD information it does not 401 require, the information can simply be discarded. Also, in 402 constrained networks such as LLNs, the amount of configuration 403 information needs to be restricted to ensure that the load on the 404 hosts is bearable while keeping the information identical across all 405 the hosts. 407 In case selective propogation is required, some form of PvD discovery 408 mechanism needs to be specified so that hosts/applications can be 409 pre-provisioned to request a specific PvD. Alternately, the set of 410 PvDs that the network can provide to the host can be propogated to 411 the host using RAs or stateless DHCPv6. The discovery mechanism may 412 potentially support the discovery of available PvDs on a per-host 413 basis. 415 3.5. Retracting/updating PvD information 417 After the PvD information is provided to the host it may be outdated 418 or updated with newer information before the hosts would normally 419 request updates. Thos would require the mchanism to be able to 420 update and/or withdraw all (or some subset) of information related to 421 a given PvD. For efficiency reasons, there should be a way to specify 422 that all the information from the PvD needs to be reconfigured 423 instead of individually updating each item associated with the PvD. 425 3.6. Conveying configuration information using IKEv2 427 Internet Key Exchange protocol version 2 (IKEv2) [RFC5996] [RFC5739] 428 is another widely used and a popular method of configuring IP 429 information in a host. In the case of IKEv2 the provisioning domain 430 could actually be implicitly learnt from the Identification - 431 Responder (IDr) payloads the IKEv2 initiator and the responder inject 432 during the IKEv2 exchange. The IP configuration may depend on the 433 named IDr. Another possibility could be adding specific provisioning 434 domain identifying payload extensions to IKEv2. All of the 435 considerations listed above for DHCPv6 and RAs potentialy apply to 436 IKEv2 as well. 438 4. Example network configurations and number of PVDs 440 5. Reference model of PVD-aware node 442 5.1. Constructions and maintenance of separate PVDs 444 It is assumed that normally, configuration information contained in a 445 single PVD, shall be sufficient for a node to fulfill a network 446 connection request by an application, and hence there should be no 447 need to attempt to merge information across different PVDs. 449 Nevertheless, even when a PVD lack some parts of the configuration, 450 merging of information from different PVD(s) shall not be done 451 automatically, since typically it would lead to issues described in 452 [RFC6418]. 454 A node may use other sources, such as e.g., node local policy, user 455 input or other mechanisms, not defined by IETF, to either construct a 456 PVD entirely (analogously to static IP configuration of an 457 interface), or supplement with particular elements all or some PVDs 458 learned from the network, or potentially merge information from 459 different PVDs, if such merge is known to the node to be safe, based 460 on explicit policies. 462 As an example, node administrator could inject a not ISP-specific DNS 463 server into PVDs for any of the networks the node could become 464 attached to. Such creation / augmentation of PVD(s) could be static 465 or dynamic. The particular implementation mechanisms are outside of 466 the scope of this document. 468 5.2. Consistent use of PVDs for network connections 470 PVDs enable PVD-aware nodes to use consistently a correct set of 471 configuration elements to serve the specific network requests from 472 beginning to end. This section describes specific examples of such 473 consistent use. 475 5.2.1. Name resolution 477 When PVD-aware node needs to resolve a name of the destination used 478 by a connection request, the node could decide to use one, or 479 multiple PVDs for a given name lookup. 481 The node shall chose one PVD, if e.g., the node policy required to 482 use a particular PVD for a particular purpose (e.g. to download an 483 MMS using a specific APN over a cellular connection). To make the 484 choice, the node could use a match of the PVD DNS suffix or other 485 form of PVD ID, as determined by the node policy. 487 The node may pick multiple PVDs, if e.g., they are general purpose 488 PVDs providing connectivity to the Internet, and the node desires to 489 maximize chances for connectivity in Happy Eyeballs style. In this 490 case, the node could do the lookups in parallel, or in sequence. 491 Alternatively, the node may use for the lookup only one PVD, based on 492 the PVD connectivity properties, user choice of the preferred 493 Internet PVD, etc. 495 In either case, by default the node uses information obtained in a 496 name service lookup to establish connections only within the same PVD 497 from which the lookup results were obtained. 499 For simplicity, when we say that name service lookup results were 500 obtained from a PVD, what we mean is that the name service query was 501 issued against a name service the configuration of which is present 502 in a particular PVD. In that sense, the results are "from" that 503 particular PVD. 505 Some nodes may support transports and/or APIs, which provide an 506 abstraction of a single connection, aggregating multiple underlying 507 connections. MPTCP [RFC6182] is an example of such transport 508 protocol. For the connections provided by such transports/APIs, a 509 PVD-aware node may use different PVDs for servicing of that logical 510 connection, provided that all operations on the underlying 511 connections are done consistently within their corresponding PVD(s). 513 5.2.2. Next-hop and source address selection 515 For the purpose of this discussion, let's assume the preceding name 516 lookup succeeded in a particular PVD. For each obtained destination 517 address, the node shall perform a next-hop lookup among routers, 518 associated with that PVD. As an example, such association could be 519 determined by the node via matching the source address prefixes/ 520 specific routes advertized by the router against known PVDs, or 521 receiving explicit PVD affiliation advertized through a new Router 522 Discovery [RFC4861] option. 524 For each destination, once the best next-hop is found, the node 525 selects best source address according to the [RFC6724] rules, but 526 with a constraint that the source address must belong to a range 527 associated with the used PVD. If needed, the node would use the 528 prefix policy from the same PVD for the best source address selection 529 among multiple candidates. 531 When destination/source pairs are identified, then they are sorted 532 using the [RFC6724] destination sorting rules and the prefix policy 533 table from the used PVD. 535 5.2.3. Listening applications 537 Consider a host, connected to several PVDs and running an application 538 that opens a listening socket/transport API object, where the 539 application authorized by the host policy to use a subset connected 540 PVDs, that may or may not be equal to the complete set of the 541 connected PVDs. For example, in case there are different PVDs on a 542 Wi-Fi and a cellular interfaces, for general internet traffic the 543 host could decide to use only one preferred PVD at a time (and 544 accordingly, advertise to remote peers the host name and addresses 545 associated with that PVD), or it could decide to use one PVD as a 546 preferred one by default for outgoing connections, while still 547 allowing use of the other PVDs simultaneously. Another example is 548 where a host established a VPN connection. Depending on the security 549 policies provisioned on the host, all or some applications may or may 550 not be allowed to use the VPN PVD and/or other PVDs. 552 For non-PVD aware applications, the OS policies determine the 553 authorized set of PVDs and the preferred outgoing PVD. For PVD-aware 554 applications, both the authorized set of PVDs and the default 555 outgoing PVD can be determined as a meet of the subset produced by 556 the OS policies and the set of PVD IDs or characteristics, provided 557 by the application. The application input could be provided on per- 558 application, per-transport-API-object or per-transport-API-call 559 basis. The API for application input may have an option for to 560 specify whether the input should be treated as a preference instead 561 of a requirement. 563 5.2.3.1. Processing of incoming traffic 565 Unicast IP packets are received on a specific IP address, associated 566 with a PVD. For multicast packets, the host can derive the 567 association with a PVD from other configuration information, such as 568 an explicit PVD property or local policy. (Note - do we need to be 569 more specific? If yes, what would be be a good method?). 571 Similarly to strong-host and weak-host models, the host may apply 572 cross-PVD filtering, where subject to host policies a packet may be 573 permitted to be received packets in a PVD different from the PVD 574 packet came from. Such filtering may be straightforward to implement 575 in the case where the PVDs are associated with different interface. 576 For multiple PVDs on a single interface, the host may apply the 577 reverse path next hop consistency check within the identified PVD for 578 the packet source IP address and link-layer addresses. (Note - is 579 there a better way?) 581 If the determined receiving PVD of the packet is not in the allowed 582 subset of PVDs for the particular app/transport API object, the 583 packet should be handled in the same way as if there were no listener 584 (alternatives - error message 'administratively prohibited', or just 585 refer to pre-PVD behavior for legacy behavior for interface-scoped 586 binds). 588 5.2.3.1.1. Connection-oriented APIs 590 For connection-oriented APIs, when the initial incoming packet is 591 received, the packet PVD is remembered for the established 592 connection, and used for handling of the outgoing traffic for that 593 connection. While typically the connection-oriented APIs use 594 connection-oriented transport protocol, such as TCP, it is possible 595 to have a connection-oriented API, which uses generally connection- 596 less transport protocol, such as UDP. For APIs/protocols, which 597 support multiple IP traffic flows associated with a single transport 598 API connection object (such as e.g. multi path TCP), the processing 599 rules may be adjusted accordingly. 601 5.2.3.1.2. Connection-less APIs 603 For connection-less APIs, the host should provide an API, which PVD- 604 aware applications could use to query the PVD associated with the 605 packet. For outgoing traffic on this transport API object, the OS 606 should use the selected outgoing PVDs, determined as described above. 608 5.2.4. Enforcement of security policies 610 PVDs by themselves don't define and can't be used for communication 611 of security policies. When implemented in a network, this 612 architecture provides the host with information about the connected 613 networks. The actual behavior of the host then depends on the host 614 policies (provisioned through mechanisms out of scope of this 615 document), applied taking received PVD information into account. In 616 some scenarios, such as e.g . VPN, such policies could require the 617 host to use only a particular VPN PVD for some/all of the 618 applications' traffic (VPN 'disable split tunneling' also known as 619 'force tunneling' behavior), or apply such restrictions only to 620 select applications and allow simultaneous use of the VPN PVD 621 togetheer with the other connected PVDs by the other or all 622 applications (VPN 'split tunneling' behavior). 624 5.3. Connectivity tests 626 Although some PVDs may appear as valid candidates for PVD selection 627 (e.g. good link quality, consistent connection parameters, etc.), 628 they may provide limited or no connectivity to the desired network or 629 the Internet. For example, some PVDs provide limited IP connectivity 630 (e.g., scoped to the link or to the access network), but require the 631 node to authenticate through a web portal to get full access to the 632 Internet. This may be more likely to happen for PVDs, which are not 633 trusted by the given PVD-aware node. 635 An attempt to use such PVD may lead to limited network connectivity 636 or connection failures for applications. To prevent the latter, a 637 PVD-aware node may perform connectivity test for the PVD, before 638 using it to serve network connection requests of the applications. 639 In current implementations, some nodes do that, for instance, by 640 trying to reach a dedicated web server (e.g., see [RFC6419]). 642 Per Section 5.2, a PVD-aware node shall maintain and use multiple 643 PVDs separately. The PVD-aware node shall perform connectivity test 644 and, only after validation of the PVD, consider using it to serve 645 application connections requests. Ongoing connectivity tests are 646 also required, since during the IP session, the end-to-end 647 connectivity could be disrupted for various reasons (e.g. poor L2, 648 IP QoS issues); hence a connectivity monitoring function is needed to 649 check the connectivity status and remove the PVD from the set of 650 usable PVDs if necessary. 652 There may be cases where a connectivity test for PVD selection may be 653 not appropriate and should be complemented, or replaced, by PVD 654 selection based on other factors. This could be realized e.g., by 655 leveraging some 3GPP and IEEE mechanisms, which would allow to expose 656 some PVD characteristics to the node (e.g. 3GPP Access Network 657 Discovery and Selection Function (ANDSF) [TS23.402], IEEE 802.11u 658 [IEEE802.11u]/ANQP). 660 5.4. Relationship to interface management and connection managers 662 Current devices such as mobile handsets make use of proprietary 663 mechanisms and custom applications to manage connectivity in 664 environments with multiple interfaces and multiple sets of network 665 configurations. These mechanisms or applications are commonly known 666 as connection managers [RFC6419]. 668 Connection managers sometimes rely on policy servers to allow the 669 node, connected to multiple networks, perform the network selection. 670 They can also make use of routing guidance from the network (e.g. 671 3GPP ANDSF [TS23.402]). Although connection managers solve some 672 connectivity problems, they rarely address the network selection 673 problems in a comprehensive manner. With proprietary solutions, it 674 is challenging to present a coherent behaviour to the end user of the 675 device, as different platforms present different behaviours even when 676 connected to the same network, with the same type of interface, and 677 for the same purpose. 679 6. PVD support in APIs 681 In all cases changes in available PVDs must be somehow exposed, 682 appropriately for each of the approaches. 684 6.1. Basic 686 Applications are not PVD-aware in any manner, and only submit 687 connection requests. The node performs PVD selection implicitly, 688 without any otherwise applications participation, and based purely on 689 node-specific administrative policies and/or choices made by the user 690 in a user interface provided by the operating environment, not by the 691 application. 693 As an example, such PVD selection can be done at the name service 694 lookup step, by using the relevant configuration elements, such as 695 e.g., those described in [RFC6731]. As another example, the PVD 696 selection could be done based on application identity or type (i.e., 697 a node could always use a particular PVD for a VOIP application). 699 6.2. Intermediate 701 Applications indirectly participate in selection of PVD by specifying 702 hard requirements and soft preferences. As an example, a real time 703 communication application, intending to use the connection for 704 exchange of real time audio/video data, may indicate a preference or 705 a requirement for connection quality, which could affect PVD 706 selection (different PVDs could correspond to Internet connections 707 with different loss rates and latencies). Another example is a 708 connection of an infrequently executed background activity, which 709 checks for availability of applications updates and performs large 710 downloads - for such connections, a cheaper or zero cost PVD may be 711 preferrable, even if such connection will have a higher relative loss 712 rate or lower bandwidth. The node performs PVD selection, based on 713 applications inputs and policies and/or user preferences. Some / all 714 properties of the resultant PVD may be exposed to applications. 716 6.3. Advanced 718 PVDs are directly exposed to applications, for enumeration and 719 selection. Node polices and/or user choices, may still override the 720 application preferences and limit which PVD(s) can be enumerated and/ 721 or used by the application, irrespectively of any preferences which 722 application may have specified. Depending on the implementation, 723 such restrictions, imposed per node policy and/or user choice, may or 724 may not be visible to the application. 726 7. PVD-aware nodes trust to PVDs 728 7.1. Untrusted PVDs 730 Implicit and explicit PVDs for which no trust relationship exists are 731 considered untrusted. Only PVDs, which meet the requirements in 732 Section 7.2, are trusted; any other PVD is untrusted. 734 In order to avoid various forms of misinformation that can be 735 asserted when PVDs are untrusted, nodes that implement PVD separation 736 cannot assume that two explicit PVDs with the same identifier are 737 actually the same PVD. A node that did make this assumption would be 738 vulnerable to attacks where for example an open Wifi hotspot might 739 assert that it was part of another PVD, and thereby might draw 740 traffic intended for that PVD onto its own network. 742 Since implicit PVD identifiers are synthesized by the node, this 743 issue cannot arise with implicit PVDs. 745 Mechanisms exist (for example, [RFC6731]) whereby a PVD can provide 746 configuration information that asserts special knowledge about the 747 reachability of resources through that PVD. Such assertions cannot 748 be validated unless the node has a trust relationship with the PVD; 749 assertions of this type therefore must be ignored by nodes that 750 receive them from untrusted PVDs. Failure to ignore such assertions 751 could result in traffic being diverted from legitimate destinations 752 to spoofed destinations. 754 7.2. Trusted PVDs 756 Trusted PVDs are PVDs for which two conditions apply. First, a 757 trust relationship must exist between the node that is using the PVD 758 configuration and the source that provided that configuration; this 759 is the authorization portion of the trust relationship. Second, 760 there must be some way to validate the trust relationship. This is 761 the authentication portion of the trust relationship. Two 762 mechanisms for validating the trust relationship are defined. 764 It shall be possible to validate the trust relationship for all 765 advertised elements of a trusted PVD, irrespectively of whether the 766 PVD elements are communicated as a whole, e.g. in a single DHCP 767 option, or separately, e.g. in supplementary RA options. Whether or 768 not this is feasible to provide mechanisms to implement trust 769 relationship for all PVD elements, will be determined in the 770 respective companion design documents. 772 7.2.1. Authenticated PVDs 774 One way to validate the trust relationship between a node and the 775 source of a PVD is through the combination of cryptographic 776 authentication and an identifier configured on the node. In some 777 cases, the two could be the same; for example, if authentication is 778 done with a shared secret, the secret would have to be associated 779 with the PVD identifier. Without a (PVD Identifier, shared key) 780 tuple, authentication would be impossible, and hence authentication 781 and authorization are combined. 783 However, if authentication is done using some public key mechanism 784 such as a TLS cert or DANE, authentication by itself isn't enough, 785 since theoretically any PVD could be authenticated in this way. In 786 addition to authentication, the node would need to be configured to 787 trust the identifier being authenticated. Validating the 788 authenticated PVD name against a list of PVD names configured as 789 trusted on the node would constitute the authorization step in this 790 case. 792 7.2.2. PVDs trusted by attachment 794 In some cases a trust relationship may be validated by some means 795 other than described in Section 7.2.1, simply by virtue of the 796 connection through which the PVD was obtained. For instance, a 797 handset connected to a mobile network may know through the mobile 798 network infrastructure that it is connected to a trusted PVD, and 799 whatever mechanism was used to validate that connection constitutes 800 the authentication portion of the PVD trust relationship. 801 Presumably such a handset would be configured from the factory, or 802 else through mobile operator or user preference settings, to trust 803 the PVD, and this would constitute the authorization portion of this 804 type of trust relationship. 806 8. Acknowledgements 808 This document was created as a product of a MIF architecture design 809 team. 811 9. IANA Considerations 813 This memo includes no request to IANA. 815 10. Security Considerations 817 There are at least three different form of attacks that can be 818 performed using configuration sources that use multiple provisioning 819 domains. 821 Tampering with configuration information provided An attacker may 822 attempt to modify the information provided inside the PVD 823 container option. These attacks can easily be prevented by using 824 the message integrity features provided by the underlying protocol 825 used to carry the configuration information. e.g. SEND [RFC3971] 826 would detect any form of tampering with the RA contents and the 827 DHCPv6 [RFC3315] AUTH option that would detect any form of 828 tampering with the DHCPv6 message contents. This attack can also 829 be performed by a compromised configuration source by modifying 830 information inside a specific , in which case the mitigations 831 proposed in the next subsection may be helpful. 833 Rogue configuration source A compromised configuration source such as 834 a router or a DHCPv6 server may advertise information about PvDs 835 that it is not authorized to advertise. e.g. A coffee shop may 836 advertise configuration information purporting to be from an 837 enterprise and may try to attract enterprise related traffic. The 838 only real way to avoid this is that the PvD related configuration 839 container contains embedded authentication and authorization 840 information from the owner of the PvD. Then, this attack can be 841 detected by the client by verifying the authentication and 842 authorization information provided inside the PVD container option 843 after verifying its trust towards the PvD owner (e.g. a 844 certificate with a well-known/common trust anchor). 846 Replay attacks A compromised configuration source or an on-link 847 attacker may try to capture advertised configuration information 848 and replay it on a different link or at a future point in time. 849 This can be avoided by including some replay protection mechanism 850 such as a timestamp or a nonce inside the PvD container to ensure 851 freshness of the provided information. 853 11. References 855 11.1. Normative References 857 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 858 Requirement Levels", BCP 14, RFC 2119, March 1997. 860 11.2. Informative References 862 [IEEE802.11u] 863 IEEE, "IEEE Standard 802.11u-2011 (Amendment 9: 864 Interworking with External Networks)", 2011. 866 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C. and 867 M. Carney, "Dynamic Host Configuration Protocol for IPv6 868 (DHCPv6)", RFC 3315, July 2003. 870 [RFC3971] Arkko, J., Kempf, J., Zill, B. and P. Nikander, "SEcure 871 Neighbor Discovery (SEND)", RFC 3971, March 2005. 873 [RFC4861] Narten, T., Nordmark, E., Simpson, W. and H. Soliman, 874 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 875 September 2007. 877 [RFC5739] Eronen, P., Laganier, J. and C. Madson, "IPv6 878 Configuration in Internet Key Exchange Protocol Version 2 879 (IKEv2)", RFC 5739, February 2010. 881 [RFC5996] Kaufman, C., Hoffman, P., Nir, Y. and P. Eronen, "Internet 882 Key Exchange Protocol Version 2 (IKEv2)", RFC 5996, 883 September 2010. 885 [RFC6182] Ford, A., Raiciu, C., Handley, M., Barre, S. and J. 886 Iyengar, "Architectural Guidelines for Multipath TCP 887 Development", RFC 6182, March 2011. 889 [RFC6418] Blanchet, M. and P. Seite, "Multiple Interfaces and 890 Provisioning Domains Problem Statement", RFC 6418, 891 November 2011. 893 [RFC6419] Wasserman, M. and P. Seite, "Current Practices for 894 Multiple-Interface Hosts", RFC 6419, November 2011. 896 [RFC6724] Thaler, D., Draves, R., Matsumoto, A. and T. Chown, 897 "Default Address Selection for Internet Protocol Version 6 898 (IPv6)", RFC 6724, September 2012. 900 [RFC6731] Savolainen, T., Kato, J. and T. Lemon, "Improved Recursive 901 DNS Server Selection for Multi-Interfaced Nodes", RFC 902 6731, December 2012. 904 [RFC7078] Matsumoto, A., Fujisaki, T. and T. Chown, "Distributing 905 Address Selection Policy Using DHCPv6", RFC 7078, January 906 2014. 908 [TS23.402] 909 3GPP, "3GPP TS 23.402; Architecture enhancements for non- 910 3GPP accesses; release 12", . 912 Author's Address 914 Dmitry Anipko, editor 915 Microsoft Corporation 916 One Microsoft Way 917 Redmond, WA 98052 918 USA 920 Phone: +1 425 703 7070 921 Email: dmitry.anipko@microsoft.com