idnits 2.17.00 (12 Aug 2021) /tmp/idnits46721/draft-anipko-mif-mpvd-arch-05.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 97 has weird spacing: '...uration and/o...' -- The document date (November 04, 2013) is 3113 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'REF ANDSF' is mentioned on line 566, but not defined == Unused Reference: 'I-D.ietf-6man-addr-select-opt' is defined on line 743, but no explicit reference was found in the text == Outdated reference: draft-ietf-6man-addr-select-opt has been published as RFC 7078 -- 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 (~~), 5 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MIF Working Group D. Anipko 3 Internet-Draft Microsoft Corporation 4 Intended status: Informational November 04, 2013 5 Expires: May 06, 2014 7 Multiple Provisioning Domain Architecture 8 draft-anipko-mif-mpvd-arch-05 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 May 06, 2014. 38 Copyright Notice 40 Copyright (c) 2013 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents (http://trustee.ietf.org/ 45 license-info) in effect on the date of publication of this document. 46 Please review these documents carefully, as they describe your rights 47 and restrictions with respect to this document. Code Components 48 extracted from this document must include Simplified BSD License text 49 as described in Section 4.e of the Trust Legal Provisions and are 50 provided without warranty as described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 55 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 56 2. Definitions and types of PVDs . . . . . . . . . . . . . . . . 3 57 2.1. Explicit PVDs . . . . . . . . . . . . . . . . . . . . . . 4 58 2.2. Implicit PVDs and incremental adoption of the explicit PVDs 5 59 2.3. Relationship between PVDs and interfaces . . . . . . . . . 5 60 2.4. PVD identity/naming . . . . . . . . . . . . . . . . . . . 6 61 2.5. Relationship to dual-stack networks . . . . . . . . . . . 6 62 2.6. Elements of PVD . . . . . . . . . . . . . . . . . . . . . 7 63 3. Conveying PVD information using DHCPv6 and Router Advertisement 7 64 3.1. Separate messages or one message . . . . . . . . . . . . . 7 65 3.2. Securing the PVD information . . . . . . . . . . . . . . . 7 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 . . . . . . . . . . . . . . 9 72 5.1. Constructions and maintenance of separate PVDs . . . . . . 9 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.3. Connectivity tests . . . . . . . . . . . . . . . . . . . . 11 77 5.4. Relationship to interface management and connection manage 12 78 6. PVD support in APIs . . . . . . . . . . . . . . . . . . . . . 12 79 6.1. Basic . . . . . . . . . . . . . . . . . . . . . . . . . . 12 80 6.2. Intermediate . . . . . . . . . . . . . . . . . . . . . . . 13 81 6.3. Advanced . . . . . . . . . . . . . . . . . . . . . . . . . 13 82 7. PVD-aware nodes trust to PVDs . . . . . . . . . . . . . . . . 13 83 7.1. Untrusted PVDs . . . . . . . . . . . . . . . . . . . . . . 13 84 7.2. Trusted PVDs . . . . . . . . . . . . . . . . . . . . . . . 13 85 7.2.1. Authenticated PVDs . . . . . . . . . . . . . . . . . . 14 86 7.2.2. PVDs trusted by attachment . . . . . . . . . . . . . . 14 87 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14 88 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 89 10. Security Considerations . . . . . . . . . . . . . . . . . . . 15 90 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 91 11.1. Normative References . . . . . . . . . . . . . . . . . . 15 92 11.2. Informative References . . . . . . . . . . . . . . . . . 15 93 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 16 95 1. Introduction 96 Nodes attached to multiple networks may encounter problems due to 97 conflict of the networks configuration and/or simultaneous use of 98 the multiple available networks. While existing implementations 99 apply various techniques ([RFC6419]) to tackle such problems, in many 100 cases the issues may still appear. The MIF problem statement 101 document [RFC6418] describes the general landscape as well as 102 discusses many specific issues and scenarios details, and are not 103 listed in this document. 105 Across the layers, problems enumerated in [RFC6418] can be grouped 106 into 3 categories: 108 1. Lack of consistent and distinctive management of configuration 109 elements, associated with different networks. 111 2. Inappropriate mixed use of configuration elements, associated 112 with different networks, in the course of a particular network 113 activity / connection. 115 3. Use of a particular network, not consistent with the intent of 116 the scenario / involved parties, leading to connectivity failure 117 and / or other undesired consequences. 119 As an illustration: an example of (1) is a single node-scoped list of 120 DNS server IP addresses, learned from different networks, leading to 121 failures or delays in resolution of name from particular namespaces; 122 an example of (2) is use of an attempt to resolve a name of a HTTP 123 proxy server, learned from a network A, with a DNS server, learned 124 from a network B, likely to fail; an example of (3) is a use of 125 employer-sponsored VPN connection for peer-to-peer connections, 126 unrelated to employment activities. 128 This architecture describes a solution to these categories of 129 problems, respectively, by: 131 1. Introducing a formal notion of the PVD, including PVD identity, 132 and ways for nodes to learn the intended associations among 133 acquired network configuration information elements. 135 2. Introducing a reference model for a PVD-aware node, preventing 136 inadvertent mixed use of the configuration information, which may 137 belong to different PVDs. 139 3. Providing recommendations on PVD selection based on PVD identity 140 and connectivity tests for common scenarios. 142 1.1. Requirements Language 144 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 145 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 146 document are to be interpreted as described in RFC 2119 [RFC2119]. 148 2. Definitions and types of PVDs 150 Provisioning Domain: a consistent set of network configuration 151 information. Classically, the entire set available on a single 152 interface is provided by a single source, such as network 153 administrator, and can therefore be treated as a single provisioning 154 domain. In modern IPv6 networks, multihoming can result in more than 155 one provisioning domain being present on a single link. In some 156 scenarios, it is also possible for elements of the same domain to be 157 present on multiple links. 159 Typical examples of information in a provisioning domain, learned 160 from the network, are: source address prefixes, to be used by 161 connections within the provisioning domain, IP address of DNS server, 162 name of HTTP proxy server if available, DNS suffixes associated with 163 the network etc. 165 PVD-aware node: a node that supports association of network 166 configuration information into PVDs, and using the resultant PVDs to 167 serve requests for network connections in ways, consistent with 168 recommendations of this architecture. 170 2.1. Explicit PVDs 172 A node may receive explicit information from the network and/or other 173 sources, about presence of PVDs and association of particular network 174 information with a particular PVD. PVDs, constructed based on such 175 information, are referred to in this document as "explicit". 177 Protocol changes/extensions will likely be required to support the 178 explicit PVDs by IETF-defined mechanisms. As an example, one could 179 think of one or several DHCP options, carrying PVD identity and / or 180 its elements. A different approach could be to introduce a DHCP 181 option, which only carries identity of a PVD, while the association 182 of network information elements with that identity, is implemented by 183 the respective protocols - such as e.g., with a Router Discovery 184 [RFC4861] option associating an address range with a PVD. 186 Specific, existing or new, features of networking protocols to enable 187 delivery of PVD identity and association with various network 188 information elements will be defined in companion design documents. 190 Link-specific and/or vendor-proprietary mechanisms for discovery of 191 PVD information, different from the IETF-defined mechanisms, can be 192 used by the nodes separately from or together with IETF-defined 193 mechanisms, as long as they allow to discover necessary elements of 194 the PVD(s). Another example of a delivery mechanism for PVDs are key 195 exchange ortunneling protocols, such as IKEv2 [RFC5996] that allow 196 transporting host configuration information. In all cases, by 197 default nodes must ensure that the lifetime of all dynamically 198 discovered PVD configuration is appropriately limited by the relevant 199 events - for example, if an interface media state change was 200 indicated, the previously discovered information may no longer be 201 valid and needs to be re-discovered or confirmed. 203 It shall be possible for networks to communicate that some of their 204 configuration elements could be used within a context of other 205 networks/PVDs. Based on such declaration and their policies, PVD- 206 aware nodes may choose to inject such elements into some or all other 207 PVDs they connect to. 209 In some network topologies, the network infrastructure elements may 210 need to advertise multiple PVDs. The details of how this is done 211 generally will be defined in the individual companion design 212 documents. However, where different design choices are possible, the 213 choice that requires smaller number of packets shall be preferred for 214 efficiency. 216 2.2. Implicit PVDs and incremental adoption of the explicit PVDs 218 It is likely that for a long time there may be networks which do not 219 advertise explicit PVD information, since deployment of any new 220 features in networking protocols is a relatively slow process. 222 When connected to networks, which don't advertise explicit PVD 223 information, PVD-aware shall automatically create separate PVDs for 224 configuration received on multiple interfaces. Such PVDs are 225 referred to in this document as "implicit". 227 With implicit PVDs,PVD-aware nodes may still provide benefits to 228 their users, compared to non-PVD aware nodes, by using network 229 information from different interfaces separately and consistently to 230 serve network connection requests, following best practices described 231 in Section 5. 233 In the mixed mode, where e.g., multiple networks are available on the 234 link the interface is attached to, and only some of the networks 235 advertise PVD information, the PVD-aware node shall create explicit 236 PVDs based on explicitly learned PVD information, and associate the 237 rest of the configuration with an implicit PVD created for that 238 interface. 240 2.3. Relationship between PVDs and interfaces 242 Implicit PVDs are limited to network configuration information 243 received on a single interface. Explicit PVDs, in practice will 244 often also be scoped to a configuration related to a particular 245 interface, however per this architecture there is no such requirement 246 or limitation and as defined in this architecture, explicit PVDs may 247 include information related to more than one interfaces, if the node 248 learns presence of the same PVD on those interfaces and the 249 authentication of the PVD ID meets the level required by the node 250 policy. 252 It is an intent of this architecture to support such scenarios among 253 others. Hence, it shall be noted that no hierarchical relationship 254 exists between interfaces and PVDs: it is possible for multiple PVDs 255 to be simultaneously accessible over one interface, as well as single 256 PVD to be simultaneously accessible over multiple interfaces. 258 2.4. PVD identity/naming 260 For explicit PVDs, PVD ID (globally unique ID, that possibly is 261 human-readable) is received as part of that information. For 262 implicit PVDs, the node assigns a locally generated globally unique 263 ID to each implicit PVD. 265 PVD-aware node may use these IDs to choose a PVD with matching ID for 266 special-purpose connection requests, in accordance with node policy 267 or choice by advanced applications, and/or to present human-readable 268 IDs to the end-user for selection of Internet-connected PVDs. 270 A single network provider may operate multiple networks, including 271 networks at different locations. In such cases, the provider may 272 chose whether to advertise single or multiple PVD identities at all 273 or some of those networks, as it suits their business needs. This 274 architecture doesn't impose specific requirements in this regard. 276 When multiple nodes are connected to the same link, where one or more 277 explicit PVDs are available, this architecture assumes that the 278 information about all available PVDs is advertized by the networks to 279 all the connected nodes. At the same time, the connected nodes may 280 have different heuristics, policies and/or other settings, including 281 configured set of their trusted PVDs, which may lead to different 282 PVDs actually being used by different nodes for their connections. 284 Possible extensions, where different sets of PVDs may be advertised 285 by the networks to different connected nodes, are out of scope for 286 this document. 288 2.5. Relationship to dual-stack networks 290 When applied to dual-stack networks, the PVD definition allows for 291 multiple PVDs to be created, where each PVD contain information for 292 only one address family, or for a single PVD that contains 293 information about multiple address families. This architecture 294 requires that accompanying design documents for accompanying protocol 295 changes must support PVDs containing information from multiple 296 address families. PVD-aware nodes must be capable of dealing with 297 both single-family and multi-family PVDs. 299 For explicit PVDs, the choice of either of the approaches is a policy 300 decision of a network administrator and/or node user/administrator. 301 Since some of the IP configuration information that can be learned 302 from the network can be applicable to multiple address families (for 303 instance DHCP address selection option [I-D.ietf-6man-addr-select- 304 opt]), it is likely that dual-stack networks will deploy single PVDs 305 for both address families. 307 For implicit PVDs, by default PVD-aware nodes shall including 308 multiple IP families into single implicit PVD created for an 309 interface. At the time of writing of this document in dual-stack 310 networks it appears to be a common practice for configuration of both 311 address families to be provided by a single source. 313 A PVD-aware node that provides API to use / enumerate / inspect PVDs 314 and/or their properties shall provide ability to filter PVDs and/or 315 their properties by address family. 317 2.6. Elements of PVD 319 3. Conveying PVD information using DHCPv6 and Router Advertisements 321 DHCPv6 and Router Advertisements are the two most common methods of 322 configuring hosts and they would need to be extended to convey 323 explicit PVD information. There are several things that need to be 324 considered before finalizing a mechanism to augment DHCPv6 and RAs 325 with PvD information. 327 3.1. Separate messages or one message 329 When information from several PVDs is available at the same 330 configuration source, there are two possibilities regarding how to 331 send these out. One way is to send information from different 332 provisioning domains in separate messages. The other is to combine 333 information from several PVDs onto one message. The latter method 334 has the advantage of being more efficient but could have issues due 335 to authentication and authorization issues as well as potential 336 issues with accommodating common information and information not 337 tagged with any PVD information. 339 3.2. Securing the PVD information 341 DHCPv6 and RAs both provide some form of authentication that ensures 342 the identity of the source as well as the integrity of the contents 343 that have been secured. While this is useful, the authenticity of 344 the information provides no information whether the configuration 345 source is actually allowed to provide information from a given PVD. 346 In order to do be able to do this, there must be a mechanism for the 347 owner of the PVD to attach some form of authorization token to the 348 configuration information that is delivered. 350 3.3. Backward compatibility 352 The extensions to RAs and DHCPv6 should be defined in such a manner 353 than unmodified hosts (i.e. hosts not aware of PvDs) will continue 354 to function as well as they did before the PvD information got added. 355 This could imply that some information may need to be duplicated in 356 order to be conveyed to legacy hosts. Similarly PvD aware hosts need 357 to be able to handle legacy configuration sources which do not 358 provide PvD information. There are also several initiatives ongoing 359 that are aimed at adding some form of additional information to 360 prefixes [refs to draft-bhandari and draft-korhonen] and any new 361 mechanism should try to consider co-existence with these existing 362 mechanisms. 364 3.4. Selective propagation 366 When a configuration source has information regarding several PvDs it 367 is not clear whether it should provide information about all of them 368 to any host that requests info from it. While it may be reasonable 369 in some cases, this might become an unreasonable burden once the 370 number of PvDs starts increasing. One way to restrict the 371 propagation of useless information is for the host to select the PvD 372 information they desire in their request to the configuration source. 373 One way this could be accomplished is by using an ORO with the PvDs 374 that are of interest. The configuration source can then respond with 375 only the requested information. 377 By default, a configuration source SHOULD provide information related 378 to all provisioning domains without expecting the client to select 379 the PvD(s) it requires. This is necessary to ensure that hosts that 380 do not support requesting selective PvD information will continue to 381 work. Also note that IPv6 neighbor discovery does not provide any 382 functionality analogous to the DHCPv6 ORO. 384 In this case, when a host receives PvD information it does not 385 require, the information can simply be discarded. Also, in 386 constrained networks such as LLNs, the amount of configuration 387 information needs to be restricted to ensure that the load on the 388 hosts is bearable while keeping the information identical across all 389 the hosts. 391 In case selective propogation is required, some form of PvD discovery 392 mechanism needs to be specified so that hosts/applications can be 393 pre-provisioned to request a specific PvD. Alternately, the set of 394 PvDs that the network can provide to the host can be propogated to 395 the host using RAs or stateless DHCPv6. The discovery mechanism may 396 potentially support the discovery of available PvDs on a per-host 397 basis. 399 3.5. Retracting/updating PvD information 401 After the PvD information is provided to the host it may be outdated 402 or updated with newer information before the hosts would normally 403 request updates. Thos would require the mchanism to be able to 404 update and/or withdraw all (or some subset) of information related to 405 a given PvD. For efficiency reasons, there should be a way to specify 406 that all the information from the PvD needs to be reconfigured 407 instead of individually updating each item associated with the PvD. 409 3.6. Conveying configuration information using IKEv2 411 Internet Key Exchange protocol version 2 (IKEv2) [RFC5996] [RFC5739] 412 is another widely used and a popular method of configuring IP 413 information in a host. In the case of IKEv2 the provisioning domain 414 could actually be implicitly learnt from the Identification - 415 Responder (IDr) payloads the IKEv2 initiator and the responder inject 416 during the IKEv2 exchange. The IP configuration may depend on the 417 named IDr. Another possibility could be adding specific provisioning 418 domain identifying payload extensions to IKEv2. All of the 419 considerations listed above for DHCPv6 and RAs potentialy apply to 420 IKEv2 as well. 422 4. Example network configurations and number of PVDs 424 5. Reference model of PVD-aware node 426 5.1. Constructions and maintenance of separate PVDs 428 It is assumed that normally, configuration information contained in a 429 single PVD, shall be sufficient for a node to fulfill a network 430 connection request by an application, and hence there should be no 431 need to attempt to merge information across different PVDs. 433 Nevertheless, even when a PVD lack some parts of the configuration, 434 merging of information from different PVD(s) shall not be done 435 automatically, since typically it would lead to issues described in 436 [RFC6418]. 438 A node may use other sources, such as e.g., node local policy, user 439 input or other mechanisms, not defined by IETF, to either construct a 440 PVD entirely (analogously to static IP configuration of an 441 interface), or supplement with particular elements all or some PVDs 442 learned from the network, or potentially merge information from 443 different PVDs, if such merge is known to the node to be safe, based 444 on explicit policies. 446 As an example, node administrator could inject a not ISP-specific DNS 447 server into PVDs for any of the networks the node could become 448 attached to. Such creation / augmentation of PVD(s) could be static 449 or dynamic. The particular implementation mechanisms are outside of 450 the scope of this document. 452 5.2. Consistent use of PVDs for network connections 454 PVDs enable PVD-aware nodes to use consistently a correct set of 455 configuration elements to serve the specific network requests from 456 beginning to end. This section describes specific examples of such 457 consistent use. 459 5.2.1. Name resolution 461 When PVD-aware node needs to resolve a name of the destination used 462 by a connection request, the node could decide to use one, or 463 multiple PVDs for a given name lookup. 465 The node shall chose one PVD, if e.g., the node policy required to 466 use a particular PVD for a particular purpose (e.g. to download an 467 MMS using a specific APN over a cellular connection). To make the 468 choice, the node could use a match of the PVD DNS suffix or other 469 form of PVD ID, as determined by the node policy. 471 The node may pick multiple PVDs, if e.g., they are general purpose 472 PVDs providing connectivity to the Internet, and the node desires to 473 maximize chances for connectivity in Happy Eyeballs style. In this 474 case, the node could do the lookups in parallel, or in sequence. 475 Alternatively, the node may use for the lookup only one PVD, based on 476 the PVD connectivity properties, user choice of the preferred 477 Internet PVD, etc. 479 In either case, by default the node uses information obtained in a 480 name service lookup to establish connections only within the same PVD 481 from which the lookup results were obtained. 483 For simplicity, when we say that name service lookup results were 484 obtained from a PVD, what we mean is that the name service query was 485 issued against a name service the configuration of which is present 486 in a particular PVD. In that sense, the results are "from" that 487 particular PVD. 489 Some nodes may support transports and/or APIs, which provide an 490 abstraction of a single connection, aggregating multiple underlying 491 connections. MPTCP [RFC6182] is an example of such transport 492 protocol. For the connections provided by such transports/APIs, a 493 PVD-aware node may use different PVDs for servicing of that logical 494 connection, provided that all operations on the underlying 495 connections are done consistently within their corresponding PVD(s). 497 5.2.2. Next-hop and source address selection 499 For the purpose of this discussion, let's assume the preceding name 500 lookup succeeded in a particular PVD. For each obtained destination 501 address, the node shall perform a next-hop lookup among routers, 502 associated with that PVD. As an example, such association could be 503 determined by the node via matching the source address prefixes/ 504 specific routes advertized by the router against known PVDs, or 505 receiving explicit PVD affiliation advertized through a new Router 506 Discovery [RFC4861] option. 508 For each destination, once the best next-hop is found, the node 509 selects best source address according to the [RFC6724] rules, but 510 with a constraint that the source address must belong to a range 511 associated with the used PVD. If needed, the node would use the 512 prefix policy from the same PVD for the best source address selection 513 among multiple candidates. 515 When destination/source pairs are identified, then they are sorted 516 using the [RFC6724] destination sorting rules and the prefix policy 517 table from the used PVD. 519 5.3. Connectivity tests 521 Although some PVDs may appear as valid candidates for PVD selection 522 (e.g. good link quality, consistent connection parameters, etc.), 523 they may provide limited or no connectivity to the desired network or 524 the Internet. For example, some PVDs provide limited IP connectivity 525 (e.g., scoped to the link or to the access network), but require the 526 node to authenticate through a web portal to get full access to the 527 Internet. This may be more likely to happen for PVDs, which are not 528 trusted by the given PVD-aware node. 530 An attempt to use such PVD may lead to limited network connectivity 531 or connection failures for applications. To prevent the latter, a 532 PVD-aware node may perform connectivity test for the PVD, before 533 using it to serve network connection requests of the applications. 534 In current implementations, some nodes do that, for instance, by 535 trying to reach a dedicated web server (e.g., see [RFC6419]). 537 Per Section 5.2, a PVD-aware node shall maintain and use multiple 538 PVDs separately. The PVD-aware node shall perform connectivity test 539 and, only after validation of the PVD, consider using it to serve 540 application connections requests. Ongoing connectivity tests are 541 also required, since during the IP session, the end-to-end 542 connectivity could be disrupted for various reasons (e.g. poor L2, 543 IP QoS issues); hence a connectivity monitoring function is needed to 544 check the connectivity status and remove the PVD from the set of 545 usable PVDs if necessary. 547 There may be cases where a connectivity test for PVD selection may be 548 not appropriate and should be complemented, or replaced, by PVD 549 selection based on other factors. This could be realized e.g., by 550 leveraging some 3GPP and IEEE mechanisms, which would allow to expose 551 some PVD characteristics to the node (e.g. 3GPP Access Network 552 Discovery and Selection Function (ANDSF) [REF ANDSF], IEEE 802.11u/ 553 ANQP [REF 802.11u]). 555 5.4. Relationship to interface management and connection managers 557 Current devices such as mobile handsets make use of proprietary 558 mechanisms and custom applications to manage connectivity in 559 environments with multiple interfaces and multiple sets of network 560 configurations. These mechanisms or applications are commonly known 561 as connection managers [RFC6419]. 563 Connection managers sometimes rely on policy servers to allow the 564 node, connected to multiple networks, perform the network selection. 565 They can also make use of routing guidance from the network (e.g. 566 3GPP ANDSF [REF ANDSF]). Although connection managers solve some 567 connectivity problems, they rarely address the network selection 568 problems in a comprehensive manner. With proprietary solutions, it 569 is challenging to present a coherent behaviour to the end user of the 570 device, as different platforms present different behaviours even when 571 connected to the same network, with the same type of interface, and 572 for the same purpose. 574 6. PVD support in APIs 576 In all cases changes in available PVDs must be somehow exposed, 577 appropriately for each of the approaches. 579 6.1. Basic 581 Applications are not PVD-aware in any manner, and only submit 582 connection requests. The node performs PVD selection implicitly, 583 without any otherwise applications participation, and based purely on 584 node-specific administrative policies and/or choices made by the user 585 in a user interface provided by the operating environment, not by the 586 application. 588 As an example, such PVD selection can be done at the name service 589 lookup step, by using the relevant configuration elements, such as 590 e.g., those described in [RFC6731]. As another example, the PVD 591 selection could be done based on application identity or type (i.e., 592 a node could always use a particular PVD for a VOIP application). 594 6.2. Intermediate 596 Applications indirectly participate in selection of PVD by specifying 597 hard requirements and soft preferences. The node performs PVD 598 selection, based on applications inputs and policies and/or user 599 preferences. Some / all properties of the resultant PVD may be 600 exposed to applications. 602 6.3. Advanced 604 PVDs are directly exposed to applications, for enumeration and 605 selection. Node polices and/or user choices, may still override the 606 application preferences and limit which PVD(s) can be enumerated and/ 607 or used by the application, irrespectively of any preferences which 608 application may have specified. Depending on the implementation, 609 such restrictions, imposed per node policy and/or user choice, may or 610 may not be visible to the application. 612 7. PVD-aware nodes trust to PVDs 614 7.1. Untrusted PVDs 616 Implicit and explicit PVDs for which no trust relationship exists are 617 considered untrusted. Only PVDs, which meet the requirements in 618 Section 7.2, are trusted; any other PVD is untrusted. 620 In order to avoid various forms of misinformation that can be 621 asserted when PVDs are untrusted, nodes that implement PVD separation 622 cannot assume that two explicit PVDs with the same identifier are 623 actually the same PVD. A node that did make this assumption would be 624 vulnerable to attacks where for example an open Wifi hotspot might 625 assert that it was part of another PVD, and thereby might draw 626 traffic intended for that PVD onto its own network. 628 Since implicit PVD identifiers are synthesized by the node, this 629 issue cannot arise with implicit PVDs. 631 Mechanisms exist (for example, [RFC6731]) whereby a PVD can provide 632 configuration information that asserts special knowledge about the 633 reachability of resources through that PVD. Such assertions cannot 634 be validated unless the node has a trust relationship with the PVD; 635 assertions of this type therefore must be ignored by nodes that 636 receive them from untrusted PVDs. Failure to ignore such assertions 637 could result in traffic being diverted from legitimate destinations 638 to spoofed destinations. 640 7.2. Trusted PVDs 641 Trusted PVDs are PVDs for which two conditions apply. First, a 642 trust relationship must exist between the node that is using the PVD 643 configuration and the source that provided that configuration; this 644 is the authorization portion of the trust relationship. Second, 645 there must be some way to validate the trust relationship. This is 646 the authentication portion of the trust relationship. Two 647 mechanisms for validating the trust relationship are defined. 649 It shall be possible to validate the trust relationship for all 650 advertised elements of a trusted PVD, irrespectively of whether the 651 PVD elements are communicated as a whole, e.g. in a single DHCP 652 option, or separately, e.g. in supplementary RA options. Whether or 653 not this is feasible to provide mechanisms to implement trust 654 relationship for all PVD elements, will be determined in the 655 respective companion design documents. 657 7.2.1. Authenticated PVDs 659 One way to validate the trust relationship between a node and the 660 source of a PVD is through the combination of cryptographic 661 authentication and an identifier configured on the node. In some 662 cases, the two could be the same; for example, if authentication is 663 done with a shared secret, the secret would have to be associated 664 with the PVD identifier. Without a (PVD Identifier, shared key) 665 tuple, authentication would be impossible, and hence authentication 666 and authorization are combined. 668 However, if authentication is done using some public key mechanism 669 such as a TLS cert or DANE, authentication by itself isn't enough, 670 since theoretically any PVD could be authenticated in this way. In 671 addition to authentication, the node would need to be configured to 672 trust the identifier being authenticated. Validating the 673 authenticated PVD name against a list of PVD names configured as 674 trusted on the node would constitute the authorization step in this 675 case. 677 7.2.2. PVDs trusted by attachment 679 In some cases a trust relationship may be validated by some means 680 other than described in Section 7.2.1, simply by virtue of the 681 connection through which the PVD was obtained. For instance, a 682 handset connected to a mobile network may know through the mobile 683 network infrastructure that it is connected to a trusted PVD, and 684 whatever mechanism was used to validate that connection constitutes 685 the authentication portion of the PVD trust relationship. 686 Presumably such a handset would be configured from the factory, or 687 else through mobile operator or user preference settings, to trust 688 the PVD, and this would constitute the authorization portion of this 689 type of trust relationship. 691 8. Acknowledgements 693 9. IANA Considerations 694 This memo includes no request to IANA. 696 10. Security Considerations 698 There are at least three different form of attacks that can be 699 performed using configuration sources that use multiple provisioning 700 domains. 702 Tampering with configuration information provided An attacker may 703 attempt to modify the information provided inside the PVD 704 container option. These attacks can easily be prevented by using 705 the message integrity features provided by the underlying protocol 706 used to carry the configuration information. e.g. SEND [RFC3971] 707 would detect any form of tampering with the RA contents and the 708 DHCPv6 [RFC3315] AUTH option that would detect any form of 709 tampering with the DHCPv6 message contents. This attack can also 710 be performed by a compromised configuration source by modifying 711 information inside a specific , in which case the mitigations 712 proposed in the next subsection may be helpful. 714 Rogue configuration source A compromised configuration source such as 715 a router or a DHCPv6 server may advertise information about PvDs 716 that it is not authorized to advertise. e.g. A coffee shop may 717 advertise configuration information purporting to be from an 718 enterprise and may try to attract enterprise related traffic. The 719 only real way to avoid this is that the PvD related configuration 720 container contains embedded authentication and authorization 721 information from the owner of the PvD. Then, this attack can be 722 detected by the client by verifying the authentication and 723 authorization information provided inside the PVD container option 724 after verifying its trust towards the PvD owner (e.g. a 725 certificate with a well-known/common trust anchor). 727 Replay attacks A compromised configuration source or an on-link 728 attacker may try to capture advertised configuration information 729 and replay it on a different link or at a future point in time. 730 This can be avoided by including some replay protection mechanism 731 such as a timestamp or a nonce inside the PvD container to ensure 732 freshness of the provided information. 734 11. References 736 11.1. Normative References 738 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 739 Requirement Levels", BCP 14, RFC 2119, March 1997. 741 11.2. Informative References 743 [I-D.ietf-6man-addr-select-opt] 744 Matsumoto, A., Fujisaki, T. and T. Chown, "Distributing 745 Address Selection Policy using DHCPv6", Internet-Draft 746 draft-ietf-6man-addr-select-opt-10, April 2013. 748 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C. and 749 M. Carney, "Dynamic Host Configuration Protocol for IPv6 750 (DHCPv6)", RFC 3315, July 2003. 752 [RFC3971] Arkko, J., Kempf, J., Zill, B. and P. Nikander, "SEcure 753 Neighbor Discovery (SEND)", RFC 3971, March 2005. 755 [RFC4861] Narten, T., Nordmark, E., Simpson, W. and H. Soliman, 756 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 757 September 2007. 759 [RFC5739] Eronen, P., Laganier, J. and C. Madson, "IPv6 760 Configuration in Internet Key Exchange Protocol Version 2 761 (IKEv2)", RFC 5739, February 2010. 763 [RFC5996] Kaufman, C., Hoffman, P., Nir, Y. and P. Eronen, "Internet 764 Key Exchange Protocol Version 2 (IKEv2)", RFC 5996, 765 September 2010. 767 [RFC6182] Ford, A., Raiciu, C., Handley, M., Barre, S. and J. 768 Iyengar, "Architectural Guidelines for Multipath TCP 769 Development", RFC 6182, March 2011. 771 [RFC6418] Blanchet, M. and P. Seite, "Multiple Interfaces and 772 Provisioning Domains Problem Statement", RFC 6418, 773 November 2011. 775 [RFC6419] Wasserman, M. and P. Seite, "Current Practices for 776 Multiple-Interface Hosts", RFC 6419, November 2011. 778 [RFC6724] Thaler, D., Draves, R., Matsumoto, A. and T. Chown, 779 "Default Address Selection for Internet Protocol Version 6 780 (IPv6)", RFC 6724, September 2012. 782 [RFC6731] Savolainen, T., Kato, J. and T. Lemon, "Improved Recursive 783 DNS Server Selection for Multi-Interfaced Nodes", RFC 784 6731, December 2012. 786 Author's Address 788 Dmitry Anipko 789 Microsoft Corporation 790 One Microsoft Way 791 Redmond, WA 98052 792 USA 794 Phone: +1 425 703 7070 795 Email: dmitry.anipko@microsoft.com