idnits 2.17.1 draft-ietf-mif-mpvd-arch-08.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 -- The document date (January 10, 2015) is 3394 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-05) exists of draft-korhonen-dmm-prefix-properties-03 -- Obsolete informational reference (is this intentional?): RFC 3315 (Obsoleted by RFC 8415) -- Obsolete informational reference (is this intentional?): RFC 5996 (Obsoleted by RFC 7296) -- Obsolete informational reference (is this intentional?): RFC 6555 (Obsoleted by RFC 8305) Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 4 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 Unaffiliated 4 Intended status: Informational January 10, 2015 5 Expires: July 12, 2015 7 Multiple Provisioning Domain Architecture 8 draft-ietf-mif-mpvd-arch-08 10 Abstract 12 This document is a product of the work of the 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 15 simultaneously. The framework defines the concept of a Provisioning 16 Domain (PvD) which is a a consistent set of network configuration 17 information. PvD aware nodes learn PvD specific information from the 18 networks they are attached to and / or other sources. PvDs are used 19 to enable separation and configuration consistency in presence of 20 multiple concurrent connections. 22 Status of this Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on July 12, 2015. 39 Copyright Notice 41 Copyright (c) 2015 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents (http://trustee.ietf.org/ 46 license-info) in effect on the date of publication of this document. 47 Please review these documents carefully, as they describe your rights 48 and restrictions with respect to this document. Code Components 49 extracted from this document must include Simplified BSD License text 50 as described in Section 4.e of the Trust Legal Provisions and are 51 provided without warranty as described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 57 2. Definitions and Types of PvDs . . . . . . . . . . . . . . . . 4 58 2.1. Explicit PvDs . . . . . . . . . . . . . . . . . . . . . . 4 59 2.2. Implicit PvDs and Incremental Adoption of Explicit PvDs . 5 60 2.3. Relationship Between PvDs and Interfaces . . . . . . . . . 6 61 2.4. PvD Identity / Naming . . . . . . . . . . . . . . . . . . 6 62 2.5. The Relationship to Dual-Stack Networks . . . . . . . . . 7 63 3. Conveying PvD information using DHCPv6 and Router Advertisement 8 64 3.1. Separate Messages or One Message? . . . . . . . . . . . . 8 65 3.2. Securing PvD Information . . . . . . . . . . . . . . . . . 8 66 3.3. Backward Compatibility . . . . . . . . . . . . . . . . . . 8 67 3.4. Selective Propagation . . . . . . . . . . . . . . . . . . 9 68 3.5. Retracting / Updating PvD Information . . . . . . . . . . 9 69 3.6. Conveying Configuration Information using IKEv2 . . . . . 9 70 4. Example Network Configurations . . . . . . . . . . . . . . . . 10 71 4.1. A Mobile Node . . . . . . . . . . . . . . . . . . . . . . 10 72 4.2. A Node with a VPN Connection . . . . . . . . . . . . . . . 11 73 4.3. A Home Network and a Network Operator with Multiple PvDs . 12 74 5. Reference Model for the PvD-aware Node . . . . . . . . . . . . 12 75 5.1. Constructions and Maintenance of Separate PvDs . . . . . . 13 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 . . . . . . . . . . . . . . . . 15 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. Connectionless APIs . . . . . . . . . . . . . 16 83 5.2.4. Enforcement of Security Policies . . . . . . . . . . . 16 84 5.3. Connectivity Tests . . . . . . . . . . . . . . . . . . . . 16 85 5.4. Relationship to Interface Management and Connection Manage 17 86 6. PvD support in APIs . . . . . . . . . . . . . . . . . . . . . 17 87 6.1. Basic . . . . . . . . . . . . . . . . . . . . . . . . . . 17 88 6.2. Intermediate . . . . . . . . . . . . . . . . . . . . . . . 18 89 6.3. Advanced . . . . . . . . . . . . . . . . . . . . . . . . . 18 90 7. PvD Trust for PvD-Aware Node . . . . . . . . . . . . . . . . . 18 91 7.1. Untrusted PvDs . . . . . . . . . . . . . . . . . . . . . . 18 92 7.2. Trusted PvDs . . . . . . . . . . . . . . . . . . . . . . . 19 93 7.2.1. Authenticated PvDs . . . . . . . . . . . . . . . . . . 19 94 7.2.2. PvDs Trusted by Attachment . . . . . . . . . . . . . . 20 95 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 20 96 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 20 97 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 98 11. Security Considerations . . . . . . . . . . . . . . . . . . . 20 99 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21 100 12.1. Normative References . . . . . . . . . . . . . . . . . . 21 101 12.2. Informative References . . . . . . . . . . . . . . . . . 21 102 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 23 104 1. Introduction 106 Nodes attached to multiple networks may encounter problems from 107 conflicting configuration between the networks, or attempts to 108 simultaneously use more than one network. While various techniques 109 are currently used to tackle these problems ([RFC6419]), in many 110 cases issues may still appear. The MIF problem statement document 111 [RFC6418] describes the general landscape and discusses many of the 112 specific issues and scenario 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 with 120 different networks during a particular network activity or 121 connection. 123 3. Use of a particular network that is not consistent with the 124 intended use of the network, or the intent of the communicating 125 parties, leading to connectivity failure and / or other undesired 126 consequences. 128 An example of (1) is a single, node-scoped list of DNS server IP 129 addresses learned from different networks leading to failures or 130 delays in resolution of names from particular namespaces; an example 131 of (2) is an attempt to resolve the name of an HTTP proxy server 132 learned from network A using a DNS server learned from network B; an 133 example of (3) is the use of an employer-provided VPN connection for 134 peer-to-peer connectivity unrelated to employment activities. 136 This architecture provides solutions to these categories of problems, 137 respectively, by: 139 1. Introducing the formal notion of PvDs, including identity for 140 PvDs, and describing mechanisms for nodes to learn the intended 141 associations between acquired network configuration information 142 elements. 144 2. Introducing a reference model for PvD-aware nodes that prevents 145 the inadvertent mixed use of configuration information which may 146 belong to different PvDs. 148 3. Providing recommendations on PvD selection based on PvD identity 149 and connectivity tests for common scenarios. 151 1.1. Requirements Language 153 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 154 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 155 document are to be interpreted as described in RFC 2119 [RFC2119]. 157 2. Definitions and Types of PvDs 159 Provisioning Domain: 160 A consistent set of network configuration information. 161 Classically, all of the configuration information available on a 162 single interface is provided by a single source (such as a network 163 administrator) and can therefore be treated as a single 164 provisioning domain. In modern IPv6 networks, multihoming can 165 result in more than one provisioning domain being present on a 166 single link. In some scenarios, it is also possible for elements 167 of the same PvD to be present on multiple links. 169 Typical examples of information in a provisioning domain learned 170 from the network are: 172 * Source address prefixes for use by connections within the 173 provisioning domain 175 * IP address(es) of DNS server(s) 177 * Name of HTTP proxy server (if available) 179 * DNS suffixes associated with the network 181 * Default gateway address 183 PvD-aware node: 184 A node that supports the association of network configuration 185 information into PvDs and the use of these PvDs to serve requests 186 for network connections in ways consistent with the 187 recommendations of this architecture. 189 2.1. Explicit PvDs 191 A node may receive explicit information from the network and / or 192 other sources conveying the presence of PvDs and the association of 193 particular network information with a particular PvD. PvDs that are 194 constructed based on such information are referred to as "explicit" 195 in this document. 197 Protocol changes or extensions will likely be required to support 198 explicit PvDs through IETF-defined mechanisms. As an example, one 199 could think of one or more DHCP options carrying PvD identity and / 200 or its elements. 202 A different approach could be the introduction of a DHCP option which 203 only carries the identity of a PvD. Here, the associations between 204 network information elements with the identity is implemented by the 205 respective protocols, for example with a Router Discovery [RFC4861] 206 option associating an address range with a PvD. 208 Another example of a delivery mechanism for PvDs are key exchange or 209 tunneling protocols, such as IKEv2 [RFC5996] that allow the 210 transport of host configuration information. 212 Specific, existing or new features of networking protocols that 213 enable the delivery of PvD identity and association with various 214 network information elements will be defined in companion design 215 documents. 217 Link-specific and / or vendor-proprietary mechanisms for the 218 discovery of PvD information (differing from IETF-defined mechanisms) 219 can be used by nodes either separate from, or in conjunction with, 220 IETF-defined mechanisms; providing they allow the discovery of the 221 necessary elements of the PvD(s). 223 In all cases, nodes must by default ensure that the lifetime of all 224 dynamically discovered PvD configuration is appropriately limited by 225 relevant events. For example, if an interface media state change is 226 indicated, previously discovered information relevant to that 227 interface may no longer be valid and so need to be confirmed or re- 228 discovered. 230 It is expected that the way a node makes use of PvD information is 231 generally independent of the specific mechanism / protocol that the 232 information was received by. 234 In some network topologies, network infrastructure elements may need 235 to advertise multiple PvDs. Generally, the details of how this is 236 performed will be defined in companion design documents. 238 2.2. Implicit PvDs and Incremental Adoption of Explicit PvDs 240 For the foreseeable future, there will be networks which do not 241 advertise explicit PvD information, because deployment of new 242 features in networking protocols is a relatively slow process. 244 When connected to networks which don't advertise explicit PvD 245 information, a PvD-aware node shall automatically create separate 246 PvDs for received configuration. Such PvDs are referred to in this 247 document as "implicit". 249 Through the use of implicit PvDs, PvD-aware nodes may still provide 250 benefits to their users (when compared to non-PvD aware nodes) by 251 following the best practices described in Section 5. 253 PvD-aware nodes shall treat betwork information from different 254 interfaces, which is not identified as belonging explicitly to some 255 PvD, as belonging to separate PvDs, one per interface. 257 Implicit PvDs can also occur in a mixed mode, i.e., where of multiple 258 networks that are available on an attached link, only some advertise 259 PvD information. In this case, the PvD-aware node shall create 260 explicit PvDs from information explicitly labeled as beloinging to 261 PvDs. It shall associate configuration information not labeled with 262 an explicit PvD with implicit PvD(s) created for that interface. 264 2.3. Relationship Between PvDs and Interfaces 266 By default, implicit PvDs are limited to the network configuration 267 information received on a single interface and by default one such 268 PvD is formed for each interface. If additional information is 269 available to the host (through mechanisms out of scope of this 270 document), the host may form implicit PvDs with different 271 granularity. For example, PvDs spanning multiple interfaces such a 272 home network with a router that has multiple internal interfaces, or 273 multiple PvDs on a single interface such as a network that has 274 multiple uplink connections. 276 In the simplest case, explicit PvDs will be scoped for configuration 277 related only to a specific interface. However, there is no 278 requirement in this architecture for such a limitation. Explicit 279 PvDs may include information related to more than one interface if 280 the node learns the presence of the same PvD on those interfaces and 281 the authentication of the PvD ID meets the level required by the node 282 policy (authentication of a PvD ID may be also required in scenarios 283 involving only one connected interface and / or PvD). 285 This architecture supports such scenarios. Hence, no hierarchical 286 relationship exists between interfaces and PvDs: it is possible for 287 multiple PvDs to be simultaneously accessible over one interface, as 288 well as a single PvD to be simultaneously accessible over multiple 289 interfaces. 291 2.4. PvD Identity / Naming 293 For explicit PvDs, the PvD ID is a value that is, or has a high 294 probability of being globally unique, and is received as part of PvD 295 information. It shall be possible to generate a human-readable form 296 of the PvD ID to present to the end-user, either based on the PvD ID 297 itself, or using meta-data associated with the ID. For implicit PvDs, 298 the node assigns a locally generated ID with a high probability of 299 being globally unique to each implicit PvD. 301 A PvD-aware node may use these IDs to select a PvD with a matching ID 302 for special-purpose connection requests in accordance with node 303 policy, as chosen by advanced applications, or to present a human- 304 readable representation of the IDs to the end-user for selection of 305 PvDs. 307 A single network provider may operate multiple networks, including 308 networks at different locations. In such cases, the provider may 309 chose whether to advertise single or multiple PvD identities at all 310 or some of those networks as it suits their business needs. This 311 architecture does not impose any specific requirements in this 312 regard. 314 When multiple nodes are connected to the same link with one or more 315 explicit PvDs available, this architecture assumes that the 316 information about all available PvDs is made available by the 317 networks to all the connected nodes. At the same time, connected 318 nodes may have different heuristics, policies and / or other 319 settings, including their configured sets of trusted PvDs. This may 320 lead to different PvDs actually being used by different nodes for 321 their connections. 323 Possible extensions, whereby networks advertize different sets of 324 PvDs to different connected nodes are out of scope of this document. 326 2.5. The Relationship to Dual-Stack Networks 328 When applied to dual-stack networks, the PvD definition allows for 329 multiple PvDs to be created whereby each PvD contains information 330 relevant to only one address family, or for a single PvD containing 331 information for multiple address families. This architecture 332 requires that accompanying design documents describing PvD-related 333 protocol changes must support PvDs containing information from 334 multiple address families. PvD-aware nodes must be capable of 335 creating and using both single-family and multi-family PvDs. 337 For explicit PvDs, the choice of either of these approaches is a 338 policy decision for the network administrator and / or the node user/ 339 administrator. Since some of the IP configuration information that 340 can be learned from the network can be applicable to multiple address 341 families (for instance DHCP Address Selection Policy Opt [RFC7078]), 342 it is likely that dual-stack networks will deploy single PvDs for 343 both address families. 345 By default for implicit PvDs, PvD-aware nodes shall include multiple 346 IP families into a single implicit PvD created for an interface. At 347 the time of writing, in dual-stack networks it appears to be common 348 practice for the configuration of both address families to be 349 provided by a single source. 351 A PvD-aware node that provides an API to use, enumerate and inspect 352 PvDs and / or their properties shall provide the ability to filter 353 PvDs and / or their properties by address family. 355 3. Conveying PvD information using DHCPv6 and Router Advertisements 357 DHCPv6 and Router Advertisements are the two most common methods of 358 configuring hosts. To support the architecture described in this 359 document, these protocols would need to be extended to convey 360 explicit PvD information. The following sections describe topic 361 which must be considered before finalizing a mechanism to augment 362 DHCPv6 and RAs with PvD information. 364 3.1. Separate Messages or One Message? 366 When information related to several PvDs is available from the same 367 configuration source, there are two possible ways of distributing 368 this information: One way is to send information from each different 369 provisioning domain in separate messages. The second method is 370 combining the information from multiple PvDs into a single message. 371 The latter method has the advantage of being more efficient but could 372 have problems with to authentication and authorization, as well as 373 potential issues with accommodating information not tagged with any 374 PvD information. 376 3.2. Securing PvD Information 378 DHCPv6 and RAs both provide some form of authentication to ensure the 379 identity of the source as well as the integrity of the secured 380 message content. While this is useful, determining authenticity does 381 tell a node whether the configuration source is actually allowed to 382 provide information from a given PvD. To resolve this, there must be 383 a mechanism for the PvD owner to attach some form of authorization 384 token or signature to the configuration information that is 385 delivered. 387 3.3. Backward Compatibility 389 The extensions to RAs and DHCPv6 should be defined in such a manner 390 than unmodified hosts (i.e. hosts not aware of PvDs) will continue 391 to function as well as they did prior to PvD information being added. 392 This could imply that some information may need to be duplicated in 393 order to be conveyed to legacy hosts. Similarly, PvD aware hosts 394 need to be able to correctly utiilize legacy configuration sources 395 which do not provide PvD information. There are also several 396 initiatives that are aimed at adding some form of additional 397 information to prefixes [I-D.bhandari-dhc-class-based-prefix] and 398 [I-D.korhonen-dmm-prefix-properties] and any new mechanism should try 399 to consider co-existence with such deployed mechanisms. 401 3.4. Selective Propagation 403 When a configuration source has information regarding several PvDs, 404 it is currently unclear whether the source should provide information 405 about all PvDs to any host that requests this information. While 406 this may be reasonable in some cases, it might become an unreasonable 407 burden once the number of PvDs starts increasing. One way to 408 restrict the propagation of information which is of no use to a 409 specific host is for the host to indicate the PvD information they 410 require within their configuration request. One way this could be 411 accomplished is by using a DHCPv6 ORO containing the PvDs that are of 412 interest. The configuration source can then respond with only the 413 requested information. 415 By default, a configuration source SHOULD provide information related 416 to all provisioning domains without expecting the client to request 417 the PvD(s) it requires. This is necessary to ensure that hosts that 418 do not support a selective PvD information request mechanism will 419 work. Also, note that IPv6 neighbor discovery does not provide any 420 functionality analogous to the DHCPv6 ORO. 422 In this case, when a host receives superfluous PvD information, it 423 can simply be discarded. Also, in constrained networks such as LLNs, 424 the amount of configuration information needs to be restricted to 425 ensure that the load on the hosts is bearable while keeping the 426 information identical across all the hosts. 428 If selective propagation is required, some form of PvD discovery 429 mechanism needs to be specified so that hosts / applications can be 430 pre-provisioned to request a specific PvD. Alternately, the set of 431 PvDs that the network can provide to the host can be propagated to 432 the host using RAs or stateless DHCPv6. The discovery mechanism may 433 potentially support the discovery of available PvDs on a per-host 434 basis. 436 3.5. Retracting / Updating PvD Information 438 After PvD information is provisioned to a host, it may become 439 outdated or superseded by updated information before the hosts would 440 normally request updates. To resolve this requires that the 441 mechanism be able to update and / or withdraw all (or some subset) of 442 the information related to a given PvD. For efficiency reasons, there 443 should be a way to specify that all information from the PvD needs to 444 be reconfigured instead of individually updating each item associated 445 with the PvD. 447 3.6. Conveying Configuration Information using IKEv2 448 Internet Key Exchange protocol version 2 (IKEv2) [RFC5996] [RFC5739] 449 is another widely used method of configuring host IP information. 450 For IKEv2, the provisioning domain could be implicitly learned from 451 the Identification - Responder (IDr) payloads that the IKEv2 452 initiator and responder inject during their IKEv2 exchange. The IP 453 configuration may depend on the named IDr. Another possibility could 454 be adding a specific provisioning domain identifying payload 455 extensions to IKEv2. All of the considerations for DHCPv6 and RAs 456 listed above potentially apply to IKEv2 as well. 458 4. Example Network Configurations 460 4.1. A Mobile Node 462 Consider a mobile node with two network interfaces: one to the mobile 463 network, the other to the Wi-Fi network. When the mobile node is 464 only connected to the mobile network, it will typically have one PvD, 465 implicit or explicit. When the mobile node discovers and connects to 466 a Wi-Fi network, it will have zero or more (typically one) additional 467 PvD(s). 469 Some existing OS implementations only allow one active network 470 connection. In this case, only the PvD(s) associated with the active 471 interface can be used at any given time. 473 As an example, the mobile network can explicitly deliver PvD 474 information through the PDP context activation process. Then, the 475 PvD aware mobile node will treat the mobile network as an explicit 476 PvD. Conversely, the legacy Wi-Fi network may not explicitly 477 communicate PvD information to the mobile node. The PvD aware mobile 478 node will associate network configuration for the Wi-Fi network with 479 an implicit PvD in this case. 481 The following diagram illustrates the use of different PvDs in this 482 scenario: 484 <----------- Wi-Fi 'Internet' PvD -------> 485 +--------+ 486 | +----+ | +----+ _ __ _ _ 487 | |WiFi| | | | ( ` ) ( ` )_ 488 | |-IF +-|----+ |--------------------------( `) 489 | | | | |WiFi| ( ) (_ Internet _) 490 | +----+ | | AP | ( ) `- __ _) - 491 | | | | ( Service ) 492 | | +----+ ( Provider's ) 493 | | ( Networks - 494 | +----+ | `_ ) _ _ 495 | |CELL| | ( ) ( ` )_ 496 | |-IF +-|-------------------------------------( `) 497 | | | | (_ __) (_ Internet _) 498 | +----+ | `- -- `- __ _) - 499 +--------+ 500 <------- Mobile 'Internet' PvD -----------> 502 An example of PvD use with Wi-Fi and mobile interfaces. 504 4.2. A Node with a VPN Connection 506 If the node has established a VPN connection, zero or more (typically 507 one) additional PvD(s) will be created. These may be implicit or 508 explicit. The routing to IP addresses reachable within this PvD will 509 be set up via the VPN connection, and the routing of packets to 510 addresses outside the scope of this PvD will remain unaffected. If a 511 node already has N connected PvDs, after the VPN session has been 512 established typically there will be N+1 connected PvDs. 514 The following diagram illustrates the use of different PvDs in this 515 scenario: 517 <----------- 'Internet' PvD ------> 518 +--------+ 519 | +----+ | +----+ _ __ _ _ 520 | |Phy | | | | ( ` ) ( ` )_ 521 | |-IF +-|----+ |--------------------( `) 522 | | | | | | ( ) (_ Internet _) 523 | +----+ | | | ( ) `- __ _) - 524 | | |Home| ( Service ) || 525 | | |gate| ( Provider's ) || 526 | | |-way| ( Network - || 527 | +----+ | | | `_ ) +---------+ +------------+ 528 | |VPN | | | | ( ) | VPN | | | 529 | |-IF +-|----+ |---------------------+ Gateway |--+ Private | 530 | | | | | | (_ __) | | | Services | 531 | +----+ | +----+ `- -- +---------+ +------------+ 532 +--------+ 533 <-------------- Explicit 'VPN' PvD -----> 535 An example of PvD use with VPN. 537 4.3. A Home Network and a Network Operator with Multiple PvDs 539 An operator may use separate PvDs for individual services which they 540 offer to their customers. These may be used so that services can be 541 designed and provisioned to be completely independent of each other, 542 allowing for complete flexibility in combinations of services which 543 are offered to customers. 545 From the perspective of the home network and the node, this model is 546 functionally very similar to being multihomed to multiple upstream 547 operators: Each of the different services offered by the service 548 provider is its own PvD with associated PvD information. In this 549 case, the operator may provide a generic / default PvD (explicit or 550 implicit), which provides Internet access to the customer. 551 Additional services would then be provisioned as explicit PvDs for 552 subscribing customers. 554 The following diagram illustrates this, using video-on-demand as a 555 service-specific PvD: 557 <------ Implicit 'Internet' PvD ------> 558 +----+ +----+ _ __ _ _ 559 | | | | ( ` ) ( ` )_ 560 | PC +-----+ |--------------------------( `) 561 | | | | ( ) (_ Internet _) 562 +----+ | | ( ) `- __ _) - 563 |Home| ( Service ) 564 |gate| ( Provider's ) 565 |-way| ( Network - 566 +-----+ | | `_ ) +---------+ 567 | Set | | | ( ) |ISP Video| 568 | Top +----+ |---------------------------+on Demand| 569 | Box | | | (_ __) | Service | 570 +-----+ +----+ `- -- +---------+ 571 <-- Explicit 'Video-on-Demand' PvD --> 573 An example of PvD use within a home network. 575 In this case, the number of PvDs that a single operator could 576 provision is based on the number of independently provisioned 577 services which they offer. Some examples may include: 579 o Real-time packet voice 581 o Streaming video 583 o Interactive video (n-way video conferencing) 585 o Interactive gaming 587 o Best effort / Internet access 589 5. Reference Model for the PvD-aware Node 590 5.1. Constructions and Maintenance of Separate PvDs 592 It is assumed that normally, the configuration information contained 593 in a single PvD shall be sufficient for a node to fulfill a network 594 connection request by an application, and hence there should be no 595 need to attempt to merge information across different PvDs. 597 Nevertheless, even when a PvD lacks some necessary configuration 598 information, merging of information associated with different PvD(s) 599 shall not be done automatically as this will typically lead to the 600 issues described in [RFC6418]. 602 A node may use other sources, for example: node local policy, user 603 input or other mechanisms not defined by the IETF for any of the 604 following: 606 o Construction of a PvD in its entirety (analogous to statically 607 configuring IP on an interface) 609 o Supplementing some, or all learned PvDs with particular 610 configuration elements 612 o Merging of information from different PvDs (if this is explicitly 613 allowed by policy) 615 As an example, a node administrator could inject a DNS server which 616 is not ISP-specific into PvDs for use on any of the networks that the 617 node could attach to. Such creation / augmentation of PvD(s) could 618 be static or dynamic. The specific mechanism(s) for implementing 619 this are outside of scope of this document. 621 5.2. Consistent use of PvDs for Network Connections 623 PvDs enable PvD-aware nodes to consistently use the correct set of 624 configuration elements to serve specific network requests from 625 beginning to end. This section provides examples of such use. 627 5.2.1. Name Resolution 629 When a PvD-aware node needs to resolve the name of the destination 630 for use by a connection request, the node could use one, or multiple 631 PvDs for a given name lookup. 633 The node shall chose a single PvD if, for example, the node policy 634 required the use of a particular PvD for a specific purpose (e.g. to 635 download an MMS message using a specific APN over a cellular 636 connection). To make this selection, the node could use a match 637 between the PvD DNS suffix and an FQDN which is being resolved or 638 match of PvD ID, as determined by the node policy. 640 The node may pick multiple PvDs, if for example, the PvDs are for 641 general purpose Internet connectivity, and the node is attempting to 642 maximize the probability of connectivity similar to the Happy 643 Eyeballs [RFC6555] approach. In this case, the node could perform 644 DNS lookups in parallel, or in sequence. Alternatively, the node may 645 use only one PvD for the lookup, based on the PvD connectivity 646 properties, user configuration of preferred Internet PvD, etc. 648 If an application implements an API that provides a way of explicitly 649 specifying the desired interface or PvD, that interface or PvD should 650 be used for name resolution (and the subsequent connection attempt), 651 provided that the host's configuration permits this. 653 In either case, by default a node uses information obtained via a 654 name service lookup to establish connections only within the same PvD 655 as the lookup results were obtained. 657 For clarification, when it is written that the name service lookup 658 results were obtained "from a PvD", it should be understood to mean 659 that the name service query was issued against a name service which 660 is configured for use in a particular PvD. In that sense, the 661 results are "from" that particular PvD. 663 Some nodes may support transports and / or APIs which provide an 664 abstraction of a single connection, aggregating multiple underlying 665 connections. MPTCP [RFC6182] is an example of such a transport 666 protocol. For connections provided by such transports/APIs, a PvD- 667 aware node may use different PvDs for servicing that logical 668 connection, provided that all operations on the underlying 669 connections are performed consistently within their corresponding 670 PvD(s). 672 5.2.2. Next-hop and Source Address Selection 674 For the purpose of this example, let us assume that the preceding 675 name lookup succeeded in a particular PvD. For each obtained 676 destination address, the node shall perform a next-hop lookup among 677 routers associated with that PvD. As an example, the node could 678 determine such associations via matching the source address prefixes/ 679 specific routes advertized by the router against known PvDs, or 680 receiving an explicit PvD affiliation advertized through a new Router 681 Discovery [RFC4861] option. 683 For each destination, once the best next-hop is found, the node 684 selects the best source address according to rules defined in 685 [RFC6724], but with the constraint that the source address must 686 belong to a range associated with the used PvD. If needed, the node 687 would use prefix policy from the same PvD for selecting the best 688 source address from multiple candidates. 690 When destination / source pairs are identified, they are sorted using 691 the [RFC6724] destination sorting rules and prefix policy table from 692 the used PvD. 694 5.2.3. Listening Applications 696 Consider a host connected to several PvDs, running an application 697 that opens a listening socket / transport API object. The 698 application is authorized by the host policy to use a subset of 699 connected PvDs that may or may not be equal to the complete set of 700 the connected PvDs. As an example, in the case where there are 701 different PvDs on the Wi-Fi and cellular interfaces, for general 702 Internet traffic the host could use only one, preferred PvD at a time 703 (and accordingly, advertise to remote peers the host name and 704 addresses associated with that PvD), or it could use one PvD as the 705 default for outgoing connections, while still allowing use of the 706 other PvDs simultaneously. 708 Another example is a host with an established VPN connection. Here, 709 security policy could be used to permit or deny application's access 710 to the VPN (and other) PvD(s). 712 For non-PvD aware applications, the operating system has policies 713 that determine the authorized set of PvDs and the preferred outgoing 714 PvD. For PvD-aware applications, both the authorized set of PvDs and 715 the default outgoing PvD can be determined as the common subset 716 produced between the OS policies and the set of PvD IDs or 717 characteristics provided by the application. 719 Application input could be provided on per-application, per- 720 transport-API-object or per-transport-API-call basis. The API for 721 application input may have an option for specifying whether the input 722 should be treated as a preference instead of a requirement. 724 5.2.3.1. Processing of Incoming Traffic 726 Unicast IP packets are received on a specific IP address associated 727 with a PvD. For multicast packets, the host can derive the PvD 728 association from other configuration information, such as an explicit 729 PvD property or local policy. 731 The node OS or middleware may apply more advanced techniques for 732 determining the resultant PvD and / or authorization of the incoming 733 traffic. Those techniques are outside of scope of this document. 735 If the determined receiving PvD of a packet is not in the allowed 736 subset of PvDs for the particular application / transport API object, 737 the packet should be handled in the same way as if there were no 738 listener. 740 5.2.3.1.1. Connection-oriented APIs 742 For connection-oriented APIs, when the initial incoming packet is 743 received, the packet PvD is remembered for the established connection 744 and used for handling of outgoing traffic for that connection. While 745 typically, connection-oriented APIs use a connection-oriented 746 transport protocol, such as TCP, it is possible to have a connection- 747 oriented API that uses a generally connectionless transport protocol, 748 such as UDP. 750 For APIs/protocols that support multiple IP traffic flows associated 751 with a single transport API connection object (for example, multi 752 path TCP), the processing rules may be adjusted accordingly. 754 5.2.3.1.2. Connectionless APIs 756 For connectionless APIs, the host should provide an API that PvD- 757 aware applications can use to query the PvD associated with the 758 packet. For outgoing traffic on this transport API object, the OS 759 should use the selected outgoing PvDs, determined as described above. 761 5.2.4. Enforcement of Security Policies 763 By themselves, PvDs do not define, and cannot be used for 764 communication of, security policies. When implemented in a network, 765 this architecture provides the host with information about connected 766 networks. The actual behavior of the host then depends on the host's 767 policies (provisioned through mechanisms out of scope of this 768 document), applied taking received PvD information into account. In 769 some scenarios, e.g. a VPN, such policies could require the host to 770 use only a particular VPN PvD for some / all of the application's 771 traffic (VPN 'disable split tunneling' also known as 'force 772 tunneling' behavior), or apply such restrictions only to selected 773 applications and allow the simultaneous use of the VPN PvD together 774 with the other connected PvDs by the other or all applications (VPN 775 'split tunneling' behavior). 777 5.3. Connectivity Tests 779 Although some PvDs may appear as valid candidates for PvD selection 780 (e.g. good link quality, consistent connection parameters, etc.), 781 they may provide limited or no connectivity to the desired network or 782 the Internet. For example, some PvDs provide limited IP connectivity 783 (e.g., scoped to the link or to the access network), but require the 784 node to authenticate through a web portal to get full access to the 785 Internet. This may be more likely to happen for PvDs which are not 786 trusted by a given PvD-aware node. 788 An attempt to use such a PvD may lead to limited network connectivity 789 or application connection failures. To prevent the latter, a PvD- 790 aware node may perform a connectivity test for the PvD before using 791 it to serve application network connection requests. In current 792 implementations, some nodes already implement this e.g., by trying to 793 reach a dedicated web server (see [RFC6419]). 795 Section 5.2 describes how a PvD-aware node shall maintain and use 796 multiple PvDs separately. The PvD-aware node shall perform a 797 connectivity test and, only after validation of the PvD, consider 798 using it to serve application connections requests. Ongoing 799 connectivity tests are also required, since during the IP session, 800 the end-to-end connectivity could be disrupted for various reasons 801 (e.g. L2 problems, IP QoS issues); hence, a connectivity monitoring 802 function is needed to check the connectivity status and remove the 803 PvD from the set of usable PvDs if necessary. 805 There may be cases where a connectivity test for PvD selection may 806 not be appropriate and should be complemented, or replaced, by PvD 807 selection based on other factors. For example, this could be 808 realized by leveraging some 3GPP and IEEE mechanisms, which would 809 allow the exposure of some PvD characteristics to the node (e.g. 810 3GPP Access Network Discovery and Selection Function (ANDSF) 811 [TS23402], IEEE 802.11u [IEEE802.11u]/ANQP). 813 5.4. Relationship to Interface Management and Connection Managers 815 Current devices, such as mobile handsets make use of proprietary 816 mechanisms and custom applications to manage connectivity in 817 environments with multiple interfaces and multiple sets of network 818 configuration. These mechanisms or applications are commonly known 819 as connection managers [RFC6419]. 821 Connection managers sometimes rely on policy servers to allow a node 822 that is connected to multiple networks to perform network selection. 823 They can also make use of routing guidance from the network (e.g. 824 3GPP ANDSF [TS23402]). Although connection managers solve some 825 connectivity problems, they rarely address network selection problems 826 in a comprehensive manner. With proprietary solutions, it is 827 challenging to present coherent behavior to the end user of the 828 device, as different platforms present different behaviors even when 829 connected to the same network, with the same type of interface, and 830 for the same purpose. The architecture described in this document 831 should improve the hosts behavior by providing the hosts with tools 832 and guidance to make informed network selection decisions. 834 6. PvD support in APIs 836 For all levels of PvD support in APIs described in this chapter, it 837 is expected that the notifications about changes in the set of 838 available PvDs are exposed as part of the API surface. 840 6.1. Basic 841 Applications are not PvD-aware in any manner and only submit 842 connection requests. The node performs PvD selection implicitly, 843 without any application participation, based purely on node-specific 844 administrative policies and / or choices made by the user from a user 845 interface provided by the operating environment, not by the 846 application. 848 As an example, PvD selection can be done at the name service lookup 849 step by using the relevant configuration elements, such as those 850 described in [RFC6731]. As another example, PvD selection could be 851 made based on application identity or type (i.e., a node could always 852 use a particular PvD for a VOIP application). 854 6.2. Intermediate 856 Applications indirectly participate in PvD selection by specifying 857 hard requirements and soft preferences. As an example, a real time 858 communication application intending to use the connection for the 859 exchange of real time audio / video data may indicate a preference or 860 a requirement for connection quality, which could affect PvD 861 selection (different PvDs could correspond to Internet connections 862 with different loss rates and latencies). 864 Another example is the connection of an infrequently executed 865 background activity, which checks for application updates and 866 performs large downloads when updates are available. For such 867 connections, a cheaper or zero cost PvD may be preferable, even if 868 such a connection has a higher relative loss rate or lower bandwidth. 869 The node performs PvD selection based on applications' inputs and 870 policies and / or user preferences. Some / all properties of the 871 resultant PvD may be exposed to applications. 873 6.3. Advanced 875 PvDs are directly exposed to applications for enumeration and 876 selection. Node polices and / or user choices may still override the 877 applications' preferences and limit which PvD(s) can be enumerated 878 and / or used by the application, irrespective of any preferences 879 which the application may have specified. Depending on the 880 implementation, such restrictions (imposed by node policy and / or 881 user choice) may or may not be visible to the application. 883 7. PvD Trust for PvD-Aware Node 885 7.1. Untrusted PvDs 887 Implicit and explicit PvDs for which no trust relationship exists are 888 considered untrusted. Only PvDs which meet the requirements in 889 Section 7.2 are trusted; any other PvD is untrusted. 891 In order to avoid the various forms of misinformation that could 892 occur when PvDs are untrusted, nodes that implement PvD separation 893 cannot assume that two explicit PvDs with the same identifier are 894 actually the same PvD. A node that makes this assumption will be 895 vulnerable to attacks where, for example, an open Wifi hotspot might 896 assert that it was part of another PvD and thereby attempt to draw 897 traffic intended for that PvD onto its own network. 899 Since implicit PvD identifiers are synthesized by the node, this 900 issue cannot arise with implicit PvDs. 902 Mechanisms exist (for example, [RFC6731]) whereby a PvD can provide 903 configuration information that asserts special knowledge about the 904 reachability of resources through that PvD. Such assertions cannot be 905 validated unless the node has a trust relationship with the PvD; 906 therefore, assertions of this type must be ignored by nodes that 907 receive them from untrusted PvDs. Failure to ignore such assertions 908 could result in traffic being diverted from legitimate destinations 909 to spoofed destinations. 911 7.2. Trusted PvDs 913 Trusted PvDs are PvDs for which two conditions apply: First, a trust 914 relationship must exist between the node that is using the PvD 915 configuration and the source that provided that configuration; this 916 is the authorization portion of the trust relationship. Second, 917 there must be some way to validate the trust relationship. This is 918 the authentication portion of the trust relationship. Two mechanisms 919 for validating the trust relationship are defined. 921 It shall be possible to validate the trust relationship for all 922 advertised elements of a trusted PvD, irrespective of whether the PvD 923 elements are communicated as a whole, e.g., in a single DHCP option, 924 or separately, e.g., in supplementary RA options. The feasibility of 925 mechanisms to implement a trust relationship for all PvD elements 926 will be determined in the respective companion design documents. 928 7.2.1. Authenticated PvDs 930 One way to validate the trust relationship between a node and the 931 source of a PvD is through the combination of cryptographic 932 authentication and an identifier configured on the node. In some 933 cases, the two could be the same; for example, if authentication is 934 by a shared secret, the secret would have to be associated with the 935 PvD identifier. Without a PvD Identifier / shared key tuple, 936 authentication would be impossible, and hence authentication and 937 authorization are combined. 939 However, if authentication is done using a public key mechanism such 940 as a TLS certificate or DANE, authentication by itself is not enough 941 since theoretically any PvD could be authenticated in this way. In 942 addition to authentication, the node would need configuration to 943 trust the identifier being authenticated. Validating the 944 authenticated PvD name against a list of PvD names configured as 945 trusted on the node would constitute the authorization step in this 946 case. 948 7.2.2. PvDs Trusted by Attachment 950 In some cases, a trust relationship may be validated by some means 951 other than those described in Section 7.2.1 simply by virtue of the 952 connection through which the PvD was obtained. For instance, a 953 handset connected to a mobile network may know through the mobile 954 network infrastructure that it is connected to a trusted PvD. 955 Whatever mechanism was used to validate that connection constitutes 956 the authentication portion of the PvD trust relationship. 957 Presumably, such a handset would be configured from the factory (or 958 else through mobile operator or user preference settings) to trust 959 the PvD, and this would constitute the authorization portion of this 960 type of trust relationship. 962 8. Contributors 964 The following individuals contributed to this document (listed in no 965 specific order): Alper Yegin (alper.yegin@yegin.org), Aaron Yi Ding 966 (yding@cs.helsinki.fi), Zhen Cao (caozhenpku@gmail.com), Dapeng Liu 967 (liudapeng@chinamobile.com), Dave Thaler (dthaler@microsoft.com), 968 Dmitry Anipko (dmitry.anipko@microsoft.com), Hui Deng 969 (denghui@chinamobile.com), Jouni Korhonen (jouni.nospam@gmail.com), 970 Juan Carlos Zuniga (JuanCarlos.Zuniga@InterDigital.com), Konstantinos 971 Pentikousis (k.pentikousis@huawei.com), Marc Blanchet 972 (marc.blanchet@viagenie.ca), Margaret Wasserman 973 (margaretw42@gmail.com), Pierrick Seite (pierrick.seite@orange.com), 974 Suresh Krishnan (suresh.krishnan@ericsson.com), Teemu Savolainen 975 (teemu.savolainen@nokia.com), Ted Lemon (ted.lemon@nominum.com) and 976 Tim Chown (tjc@ecs.soton.ac.uk). 978 9. Acknowledgments 980 The authors would like to thank (in no specific order) Ian Farrer, 981 Marcus Stenberg and Mikael Abrahamsson for their review and comments. 983 10. IANA Considerations 985 This memo does not include any IANA requests. 987 11. Security Considerations 989 There are at least three different forms of attacks that can be 990 performed using configuration sources that support multiple 991 provisioning domains. 993 Tampering with provided configuration information: An attacker may 994 attempt to modify information provided inside the PvD container 995 option. These attacks can easily be prevented by using message 996 integrity features provided by the underlying protocol used to 997 carry the configuration information. E.g. SEND [RFC3971] would 998 detect any form of tampering with the RA contents and the DHCPv6 999 [RFC3315] AUTH option that would detect any form of tampering with 1000 the DHCPv6 message contents. This attack can also be performed by 1001 a compromised configuration source by modifying information inside 1002 a specific PvD, in which case the mitigations proposed in the next 1003 subsection may be helpful. 1005 Rogue configuration source: A compromised configuration source, such 1006 as a router or a DHCPv6 server, may advertise information about 1007 PvDs that it is not authorized to advertise. e.g. A coffee shop 1008 WLAN may advertise configuration information purporting to be from 1009 an enterprise and may try to attract enterprise related traffic. 1010 The only real way to prevent this is is for the PvD related 1011 configuration container to contain embedded authentication and 1012 authorization information from the owner of the PvD. This provides 1013 the client with a way of detecting the attack by verifying the 1014 authentication and authorization information provided inside the 1015 PvD container option, after verifying its trust of the PvD owner 1016 (e.g. a certificate with a well-known / common trust anchor). In 1017 order to not be vulnerable to this attack, the clients should be 1018 configured to peform verification of the provided authentication 1019 and authorization information. 1021 Replay attacks: A compromised configuration source or an on-link 1022 attacker may try to capture advertised configuration information 1023 and replay it on a different link, or at a future point in time. 1024 This can be avoided by including a replay protection mechanism 1025 such as a timestamp or a nonce inside the PvD container to ensure 1026 the validity of the provided information. 1028 12. References 1030 12.1. Normative References 1032 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1033 Requirement Levels", BCP 14, RFC 2119, March 1997. 1035 12.2. Informative References 1037 [I-D.bhandari-dhc-class-based-prefix] 1038 Systems, C., Halwasia, G., Gundavelli, S., Deng, H., 1039 Thiebaut, L., Korhonen, J. and I. Farrer, "DHCPv6 class 1040 based prefix", Internet-Draft draft-bhandari-dhc-class- 1041 based-prefix-05, July 2013. 1043 [I-D.korhonen-dmm-prefix-properties] 1044 Korhonen, J., Patil, B., Gundavelli, S., Seite, P. and D. 1045 Liu, "IPv6 Prefix Mobility Management Properties", 1046 Internet-Draft draft-korhonen-dmm-prefix-properties-03, 1047 October 2012. 1049 [IEEE802.11u] 1050 IEEE, "IEEE Standard 802.11u-2011 (Amendment 9: 1051 Interworking with External Networks)", 2011. 1053 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C. and 1054 M. Carney, "Dynamic Host Configuration Protocol for IPv6 1055 (DHCPv6)", RFC 3315, July 2003. 1057 [RFC3971] Arkko, J., Kempf, J., Zill, B. and P. Nikander, "SEcure 1058 Neighbor Discovery (SEND)", RFC 3971, March 2005. 1060 [RFC4861] Narten, T., Nordmark, E., Simpson, W. and H. Soliman, 1061 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 1062 September 2007. 1064 [RFC5739] Eronen, P., Laganier, J. and C. Madson, "IPv6 1065 Configuration in Internet Key Exchange Protocol Version 2 1066 (IKEv2)", RFC 5739, February 2010. 1068 [RFC5996] Kaufman, C., Hoffman, P., Nir, Y. and P. Eronen, "Internet 1069 Key Exchange Protocol Version 2 (IKEv2)", RFC 5996, 1070 September 2010. 1072 [RFC6182] Ford, A., Raiciu, C., Handley, M., Barre, S. and J. 1073 Iyengar, "Architectural Guidelines for Multipath TCP 1074 Development", RFC 6182, March 2011. 1076 [RFC6418] Blanchet, M. and P. Seite, "Multiple Interfaces and 1077 Provisioning Domains Problem Statement", RFC 6418, 1078 November 2011. 1080 [RFC6419] Wasserman, M. and P. Seite, "Current Practices for 1081 Multiple-Interface Hosts", RFC 6419, November 2011. 1083 [RFC6555] Wing, D. and A. Yourtchenko, "Happy Eyeballs: Success with 1084 Dual-Stack Hosts", RFC 6555, April 2012. 1086 [RFC6724] Thaler, D., Draves, R., Matsumoto, A. and T. Chown, 1087 "Default Address Selection for Internet Protocol Version 6 1088 (IPv6)", RFC 6724, September 2012. 1090 [RFC6731] Savolainen, T., Kato, J. and T. Lemon, "Improved Recursive 1091 DNS Server Selection for Multi-Interfaced Nodes", RFC 1092 6731, December 2012. 1094 [RFC7078] Matsumoto, A., Fujisaki, T. and T. Chown, "Distributing 1095 Address Selection Policy Using DHCPv6", RFC 7078, January 1096 2014. 1098 [TS23402] 3GPP, "3GPP TS 23.402; Architecture enhancements for non- 1099 3GPP accesses; release 12", 2014. 1101 Author's Address 1103 Dmitry Anipko, editor 1104 Unaffiliated 1106 Phone: +1 425 442 6356 1107 Email: dmitry.anipko@gmail.com