idnits 2.17.1 draft-ietf-mif-mpvd-arch-11.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 2) being 60 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 17, 2015) is 3290 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 normative reference: RFC 3315 (Obsoleted by RFC 8415) ** Obsolete normative reference: RFC 5996 (Obsoleted by RFC 7296) ** Obsolete normative reference: RFC 6555 (Obsoleted by RFC 8305) Summary: 4 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). 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 March 17, 2015 5 Expires: September 16, 2015 7 Multiple Provisioning Domain Architecture 8 draft-ietf-mif-mpvd-arch-11 10 Abstract 12 This document is a product of the work of the Multiple Interfaces 13 Architecture Design team. It outlines a solution framework for some 14 of the issues experienced by nodes that can be attached to multiple 15 networks simultaneously. The framework defines the concept of a 16 Provisioning Domain (PvD) which is a a consistent set of network 17 configuration information. PvD aware nodes learn PvD specific 18 information from the networks they are attached to and / or other 19 sources. PvDs are used to enable separation and configuration 20 consistency in presence of 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 September 16, 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 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 55 2. Definitions and Types of PvDs . . . . . . . . . . . . . . . . 3 56 2.1. Explicit PvDs . . . . . . . . . . . . . . . . . . . . . . 4 57 2.2. Implicit PvDs and Incremental Adoption of Explicit PvDs . 5 58 2.3. Relationship Between PvDs and Interfaces . . . . . . . . . 5 59 2.4. PvD Identity / Naming . . . . . . . . . . . . . . . . . . 6 60 2.5. The Relationship to Dual-Stack Networks . . . . . . . . . 7 61 3. Conveying PvD information . . . . . . . . . . . . . . . . . . 7 62 3.1. Separate Messages or One Message? . . . . . . . . . . . . 8 63 3.2. Securing PvD Information . . . . . . . . . . . . . . . . . 8 64 3.3. Backward Compatibility . . . . . . . . . . . . . . . . . . 8 65 3.4. Retracting / Updating PvD Information . . . . . . . . . . 8 66 3.5. Conveying Configuration Information using IKEv2 . . . . . 9 67 4. Example Network Configurations . . . . . . . . . . . . . . . . 9 68 4.1. A Mobile Node . . . . . . . . . . . . . . . . . . . . . . 9 69 4.2. A Node with a VPN Connection . . . . . . . . . . . . . . . 10 70 4.3. A Home Network and a Network Operator with Multiple PvDs . 11 71 5. Reference Model for the PvD-aware Node . . . . . . . . . . . . 12 72 5.1. Constructions and Maintenance of Separate PvDs . . . . . . 12 73 5.2. Consistent use of PvDs for Network Connections . . . . . . 12 74 5.2.1. Name Resolution . . . . . . . . . . . . . . . . . . . 13 75 5.2.2. Next-hop and Source Address Selection . . . . . . . . 14 76 5.2.3. Listening Applications . . . . . . . . . . . . . . . . 14 77 5.2.3.1. Processing of Incoming Traffic . . . . . . . . . . 15 78 5.2.3.1.1. Connection-oriented APIs . . . . . . . . . . . 15 79 5.2.3.1.2. Connectionless APIs . . . . . . . . . . . . . 15 80 5.2.4. Enforcement of Security Policies . . . . . . . . . . . 15 81 5.3. Connectivity Tests . . . . . . . . . . . . . . . . . . . . 16 82 5.4. Relationship to Interface Management and Connection Manage 16 83 6. PvD support in APIs . . . . . . . . . . . . . . . . . . . . . 17 84 6.1. Basic . . . . . . . . . . . . . . . . . . . . . . . . . . 17 85 6.2. Intermediate . . . . . . . . . . . . . . . . . . . . . . . 17 86 6.3. Advanced . . . . . . . . . . . . . . . . . . . . . . . . . 18 87 7. PvD Trust for PvD-Aware Node . . . . . . . . . . . . . . . . . 18 88 7.1. Untrusted PvDs . . . . . . . . . . . . . . . . . . . . . . 18 89 7.2. Trusted PvDs . . . . . . . . . . . . . . . . . . . . . . . 18 90 7.2.1. Authenticated PvDs . . . . . . . . . . . . . . . . . . 19 91 7.2.2. PvDs Trusted by Attachment . . . . . . . . . . . . . . 19 92 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 19 93 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 19 94 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 95 11. Security Considerations . . . . . . . . . . . . . . . . . . . 20 96 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21 97 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 22 99 1. Introduction 101 Nodes attached to multiple networks may encounter problems from 102 conflicting configuration between the networks, or attempts to 103 simultaneously use more than one network. While various techniques 104 are currently used to tackle these problems ([RFC6419]), in many 105 cases issues may still appear. The Multiple Interfaces problem 106 statement document [RFC6418] describes the general landscape and 107 discusses many of the specific issues and scenario details. 109 Problems, enumerated in [RFC6418], can be grouped into 3 categories: 111 1. Lack of consistent and distinctive management of configuration 112 elements associated with different networks. 114 2. Inappropriate mixed use of configuration elements associated with 115 different networks during a particular network activity or 116 connection. 118 3. Use of a particular network that is not consistent with the 119 intended use of the network, or the intent of the communicating 120 parties, leading to connectivity failure and / or other undesired 121 consequences. 123 An example of (1) is a single, node-scoped list of DNS server IP 124 addresses learned from different networks leading to failures or 125 delays in resolution of names from particular namespaces; an example 126 of (2) is an attempt to resolve the name of an HTTP proxy server 127 learned from network A using a DNS server learned from network B; an 128 example of (3) is the use of an employer-provided VPN connection for 129 peer-to-peer connectivity unrelated to employment activities. 131 This architecture provides solutions to these categories of problems, 132 respectively, by: 134 1. Introducing the formal notion of PvDs, including identity for 135 PvDs, and describing mechanisms for nodes to learn the intended 136 associations between acquired network configuration information 137 elements. 139 2. Introducing a reference model for PvD-aware nodes that prevents 140 the inadvertent mixed use of configuration information which may 141 belong to different PvDs. 143 3. Providing recommendations on PvD selection based on PvD identity 144 and connectivity tests for common scenarios. 146 2. Definitions and Types of PvDs 148 Provisioning Domain: 149 A consistent set of network configuration information. 150 Classically, all of the configuration information available on a 151 single interface is provided by a single source (such as a network 152 administrator) and can therefore be treated as a single 153 provisioning domain. In modern IPv6 networks, multihoming can 154 result in more than one provisioning domain being present on a 155 single link. In some scenarios, it is also possible for elements 156 of the same PvD to be present on multiple links. 158 Typical examples of information in a provisioning domain learned 159 from the network are: 161 * Source address prefixes for use by connections within the 162 provisioning domain 164 * IP address(es) of DNS server(s) 166 * Name of HTTP proxy server (if available) 168 * DNS suffixes associated with the network 170 * Default gateway address 172 PvD-aware node: 173 A node that supports the association of network configuration 174 information into PvDs and the use of these PvDs to serve requests 175 for network connections in ways consistent with the 176 recommendations of this architecture. 178 PvD-aware application: 179 An application, that contains code and / or application-specific 180 configuration information explicitly aware of the notion of PvD 181 and / or specific types of PvD elements or properties. 183 2.1. Explicit PvDs 185 A node may receive explicit information from the network and / or 186 other sources conveying the presence of PvDs and the association of 187 particular network information with a particular PvD. PvDs that are 188 constructed based on such information are referred to as "explicit" 189 in this document. 191 Protocol changes or extensions will likely be required to support 192 explicit PvDs through IETF-defined mechanisms. As an example, one 193 could think of one or more DHCP options carrying PvD identity and / 194 or its elements. 196 A different approach could be the introduction of a DHCP option which 197 only carries the identity of a PvD. Here, the associations between 198 network information elements with the identity is implemented by the 199 respective protocols, for example with a Router Discovery [RFC4861] 200 option associating an address range with a PvD. Additional discussion 201 can be found in Section 3. 203 Another example of a delivery mechanism for PvDs are key exchange or 204 tunneling protocols, such as IKEv2 [RFC5996] that allow the 205 transport of host configuration information. 207 Specific, existing or new features of networking protocols that 208 enable the delivery of PvD identity and association with various 209 network information elements will be defined in companion design 210 documents. 212 Link-specific and / or vendor-proprietary mechanisms for the 213 discovery of PvD information (differing from IETF-defined mechanisms) 214 can be used by nodes either separate from, or in conjunction with, 215 IETF-defined mechanisms; providing they allow the discovery of the 216 necessary elements of the PvD(s). 218 In all cases, nodes must by default ensure that the lifetime of all 219 dynamically discovered PvD configuration is appropriately limited by 220 relevant events. For example, if an interface media state change is 221 indicated, previously discovered information relevant to that 222 interface may no longer be valid and so need to be confirmed or re- 223 discovered. 225 It is expected that the way a node makes use of PvD information is 226 generally independent of the specific mechanism / protocol that the 227 information was received by. 229 In some network topologies, network infrastructure elements may need 230 to advertise multiple PvDs. Generally, the details of how this is 231 performed will be defined in companion design documents. 233 2.2. Implicit PvDs and Incremental Adoption of Explicit PvDs 235 For the foreseeable future, there will be networks which do not 236 advertise explicit PvD information, because deployment of new 237 features in networking protocols is a relatively slow process. 239 When connected to networks which don't advertise explicit PvD 240 information, a PvD-aware node shall automatically create separate 241 PvDs for received configuration. Such PvDs are referred to in this 242 document as "implicit". 244 Through the use of implicit PvDs, PvD-aware nodes may still provide 245 benefits to their users (when compared to non-PvD aware nodes) by 246 following the best practices described in Section 5. 248 PvD-aware nodes shall treat network information from different 249 interfaces, which is not identified as belonging explicitly to some 250 PvD, as belonging to separate PvDs, one per interface. 252 Implicit PvDs can also occur in a mixed mode, i.e., where of multiple 253 networks that are available on an attached link, only some advertise 254 PvD information. In this case, the PvD-aware node shall create 255 explicit PvDs from information explicitly labeled as belonging to 256 PvDs. It shall associate configuration information not labeled with 257 an explicit PvD with implicit PvD(s) created for that interface. 259 2.3. Relationship Between PvDs and Interfaces 260 By default, implicit PvDs are limited to the network configuration 261 information received on a single interface and by default one such 262 PvD is formed for each interface. If additional information is 263 available to the host (through mechanisms out of scope of this 264 document), the host may form implicit PvDs with different 265 granularity. For example, PvDs spanning multiple interfaces such a 266 home network with a router that has multiple internal interfaces, or 267 multiple PvDs on a single interface such as a network that has 268 multiple uplink connections. 270 In the simplest case, explicit PvDs will be scoped for configuration 271 related only to a specific interface. However, there is no 272 requirement in this architecture for such a limitation. Explicit 273 PvDs may include information related to more than one interface if 274 the node learns the presence of the same PvD on those interfaces and 275 the authentication of the PvD ID meets the level required by the node 276 policy (authentication of a PvD ID may be also required in scenarios 277 involving only one connected interface and / or PvD; for additional 278 discussion of PvD Trust see Section 7). 280 This architecture supports such scenarios. Hence, no hierarchical 281 relationship exists between interfaces and PvDs: it is possible for 282 multiple PvDs to be simultaneously accessible over one interface, as 283 well as a single PvD to be simultaneously accessible over multiple 284 interfaces. 286 2.4. PvD Identity / Naming 288 For explicit PvDs, the PvD ID is a value that is, or has a high 289 probability of being globally unique, and is received as part of PvD 290 information. It shall be possible to generate a human-readable form 291 of the PvD ID to present to the end-user, either based on the PvD ID 292 itself, or using meta-data associated with the ID. For implicit PvDs, 293 the node assigns a locally generated ID with a high probability of 294 being globally unique to each implicit PvD. 296 We say that a PvD ID should be, or should have a high probability of 297 being globally unique. The purpose of this is to make it unlikely 298 that any individual node will ever accidentally see the same PvD name 299 twice if it is not actually referring to the same PvD. Protection 300 against deliberate attacks involving name clashes require that the 301 name be authenticated (see Section 7.2.1). 303 A PvD-aware node may use these IDs to select a PvD with a matching ID 304 for special-purpose connection requests in accordance with node 305 policy, as chosen by advanced applications, or to present a human- 306 readable representation of the IDs to the end-user for selection of 307 PvDs. 309 A single network provider may operate multiple networks, including 310 networks at different locations. In such cases, the provider may 311 chose whether to advertise single or multiple PvD identities at all 312 or some of those networks as it suits their business needs. This 313 architecture does not impose any specific requirements in this 314 regard. 316 When multiple nodes are connected to the same link with one or more 317 explicit PvDs available, this architecture assumes that the 318 information about all available PvDs is made available by the 319 networks to all the connected nodes. At the same time, connected 320 nodes may have different heuristics, policies and / or other 321 settings, including their configured sets of trusted PvDs. This may 322 lead to different PvDs actually being used by different nodes for 323 their connections. 325 Possible extensions, whereby networks advertise different sets of 326 PvDs to different connected nodes are out of scope of this document. 328 2.5. The Relationship to Dual-Stack Networks 330 When applied to dual-stack networks, the PvD definition allows for 331 multiple PvDs to be created whereby each PvD contains information 332 relevant to only one address family, or for a single PvD containing 333 information for multiple address families. This architecture 334 requires that accompanying design documents describing PvD-related 335 protocol changes must support PvDs containing information from 336 multiple address families. PvD-aware nodes must be capable of 337 creating and using both single-family and multi-family PvDs. 339 For explicit PvDs, the choice of either of these approaches is a 340 policy decision for the network administrator and / or the node user/ 341 administrator. Since some of the IP configuration information that 342 can be learned from the network can be applicable to multiple address 343 families (for instance DHCP Address Selection Policy Opt [RFC7078]), 344 it is likely that dual-stack networks will deploy single PvDs for 345 both address families. 347 By default for implicit PvDs, PvD-aware nodes shall include multiple 348 IP families into a single implicit PvD created for an interface. At 349 the time of writing, in dual-stack networks it appears to be common 350 practice for the configuration of both address families to be 351 provided by a single source. 353 A PvD-aware node that provides an API to use, enumerate and inspect 354 PvDs and / or their properties shall provide the ability to filter 355 PvDs and / or their properties by address family. 357 3. Conveying PvD information 359 DHCPv6 and Router Advertisements are the two most common methods of 360 configuring hosts. To support the architecture described in this 361 document, these protocols would need to be extended to convey 362 explicit PvD information. The following sections describe topic 363 which must be considered before finalizing a mechanism to augment 364 DHCPv6 and RAs with PvD information. 366 3.1. Separate Messages or One Message? 368 When information related to several PvDs is available from the same 369 configuration source, there are two possible ways of distributing 370 this information: One way is to send information from each different 371 provisioning domain in separate messages. The second method is 372 combining the information from multiple PvDs into a single message. 373 The latter method has the advantage of being more efficient but could 374 have problems with to authentication and authorization, as well as 375 potential issues with accommodating information not tagged with any 376 PvD information. 378 3.2. Securing PvD Information 380 DHCPv6 [RFC3315] and RAs [RFC3971] both provide some form of 381 authentication to ensure the identity of the source as well as the 382 integrity of the secured message content. While this is useful, 383 determining authenticity does not tell a node whether the 384 configuration source is actually allowed to provide information from 385 a given PvD. To resolve this, there must be a mechanism for the PvD 386 owner to attach some form of authorization token or signature to the 387 configuration information that is delivered. 389 3.3. Backward Compatibility 391 The extensions to RAs and DHCPv6 should be defined in such a manner 392 than unmodified hosts (i.e., hosts not aware of PvDs) will continue 393 to function as well as they did prior to PvD information being added. 394 This could imply that some information may need to be duplicated in 395 order to be conveyed to legacy hosts. Similarly, PvD aware hosts 396 need to be able to correctly utilize legacy configuration sources 397 which do not provide PvD information. There are also several 398 initiatives that are aimed at adding some form of additional 399 information to prefixes [I-D.bhandari-dhc-class-based-prefix] and 400 [I-D.korhonen-dmm-prefix-properties] and any new mechanism should try 401 to consider co-existence with such deployed mechanisms. 403 3.4. Retracting / Updating PvD Information 404 After PvD information is provisioned to a host, it may become 405 outdated or superseded by updated information before the hosts would 406 normally request updates. To resolve this requires that the 407 mechanism be able to update and / or withdraw all (or some subset) of 408 the information related to a given PvD. For efficiency reasons, there 409 should be a way to specify that all information from the PvD needs to 410 be reconfigured instead of individually updating each item associated 411 with the PvD. 413 3.5. Conveying Configuration Information using IKEv2 415 Internet Key Exchange protocol version 2 (IKEv2) [RFC5996] [RFC5739] 416 is another widely used method of configuring host IP information. 417 For IKEv2, the provisioning domain could be implicitly learned from 418 the Identification - Responder (IDr) payloads that the IKEv2 419 initiator and responder inject during their IKEv2 exchange. The IP 420 configuration may depend on the named IDr. Another possibility could 421 be adding a specific provisioning domain identifying payload 422 extensions to IKEv2. All of the considerations for DHCPv6 and RAs 423 listed above potentially apply to IKEv2 as well. 425 4. Example Network Configurations 427 4.1. A Mobile Node 429 Consider a mobile node with two network interfaces: one to the mobile 430 network, the other to the Wi-Fi network. When the mobile node is 431 only connected to the mobile network, it will typically have one PvD, 432 implicit or explicit. When the mobile node discovers and connects to 433 a Wi-Fi network, it will have zero or more (typically one) additional 434 PvD(s). 436 Some existing OS implementations only allow one active network 437 connection. In this case, only the PvD(s) associated with the active 438 interface can be used at any given time. 440 As an example, the mobile network can explicitly deliver PvD 441 information through the PDP context activation process. Then, the 442 PvD aware mobile node will treat the mobile network as an explicit 443 PvD. Conversely, the legacy Wi-Fi network may not explicitly 444 communicate PvD information to the mobile node. The PvD aware mobile 445 node will associate network configuration for the Wi-Fi network with 446 an implicit PvD in this case. 448 The following diagram illustrates the use of different PvDs in this 449 scenario: 451 <----------- Wi-Fi 'Internet' PvD -------> 452 +---------+ 453 | +-----+ | +-----+ _ __ _ _ 454 | |Wi-Fi| | | | ( ` ) ( ` )_ 455 | |-IF + |----+ |---------------------------( `) 456 | | | | |Wi-Fi| ( ) ( Internet ) 457 | +-----+ | | AP | ( ) ( ) 458 | | | | ( Service ) ( ) 459 | | +-----+ ( Provider's ) ( ) 460 | | ( Networks - ( ) 461 | +----+ | `_ ) ( ) 462 | |CELL| | ( ) ( ) 463 | |-IF +--|-------------------------------------( ) 464 | | | | (_ __) (_ _) 465 | +----+ | `- -- `- __ _) - 466 +---------+ 467 <------- Mobile 'Internet' PvD -----------> 469 An example of PvD use with Wi-Fi and mobile interfaces. 471 4.2. A Node with a VPN Connection 473 If the node has established a VPN connection, zero or more (typically 474 one) additional PvD(s) will be created. These may be implicit or 475 explicit. The routing to IP addresses reachable within this PvD will 476 be set up via the VPN connection, and the routing of packets to 477 addresses outside the scope of this PvD will remain unaffected. If a 478 node already has N connected PvDs, after the VPN session has been 479 established typically there will be N+1 connected PvDs. 481 The following diagram illustrates the use of different PvDs in this 482 scenario: 484 <----------- 'Internet' PvD ------> 485 +--------+ 486 | +----+ | +----+ _ __ _ _ 487 | |Phy | | | | ( ` ) ( ` )_ 488 | |-IF +-|----+ |--------------------( `) 489 | | | | | | ( ) (_ Internet _) 490 | +----+ | | | ( ) `- __ _) - 491 | | |Home| ( Service ) || 492 | | |gate| ( Provider's ) || 493 | | |-way| ( Network - || 494 | +----+ | | | `_ ) +---------+ +------------+ 495 | |VPN | | | | ( ) | VPN | | | 496 | |-IF +-|----+ |---------------------+ Gateway |--+ Private | 497 | | | | | | (_ __) | | | Services | 498 | +----+ | +----+ `- -- +---------+ +------------+ 499 +--------+ 500 <-------------- Explicit 'VPN' PvD -----> 502 An example of PvD use with VPN. 504 4.3. A Home Network and a Network Operator with Multiple PvDs 506 An operator may use separate PvDs for individual services which they 507 offer to their customers. These may be used so that services can be 508 designed and provisioned to be completely independent of each other, 509 allowing for complete flexibility in combinations of services which 510 are offered to customers. 512 From the perspective of the home network and the node, this model is 513 functionally very similar to being multihomed to multiple upstream 514 operators: Each of the different services offered by the service 515 provider is its own PvD with associated PvD information. In this 516 case, the operator may provide a generic / default PvD (explicit or 517 implicit), which provides Internet access to the customer. 518 Additional services would then be provisioned as explicit PvDs for 519 subscribing customers. 521 The following diagram illustrates this, using video-on-demand as a 522 service-specific PvD: 524 <------ Implicit 'Internet' PvD ------> 525 +----+ +----+ _ __ _ _ 526 | | | | ( ` ) ( ` )_ 527 | PC +-----+ |--------------------------( `) 528 | | | | ( ) (_ Internet _) 529 +----+ | | ( ) `- __ _) - 530 |Home| ( Service ) 531 |gate| ( Provider's ) 532 |-way| ( Network - 533 +-----+ | | `_ ) +---------+ 534 | Set | | | ( ) |ISP Video| 535 | Top +----+ |---------------------------+on Demand| 536 | Box | | | (_ __) | Service | 537 +-----+ +----+ `- -- +---------+ 538 <-- Explicit 'Video-on-Demand' PvD --> 540 An example of PvD use within a home network. 542 In this case, the number of PvDs that a single operator could 543 provision is based on the number of independently provisioned 544 services which they offer. Some examples may include: 546 o Real-time packet voice 548 o Streaming video 549 o Interactive video (n-way video conferencing) 551 o Interactive gaming 553 o Best effort / Internet access 555 5. Reference Model for the PvD-aware Node 557 5.1. Constructions and Maintenance of Separate PvDs 559 It is assumed that normally, the configuration information contained 560 in a single PvD shall be sufficient for a node to fulfill a network 561 connection request by an application, and hence there should be no 562 need to attempt to merge information across different PvDs. 564 Nevertheless, even when a PvD lacks some necessary configuration 565 information, merging of information associated with different PvD(s) 566 shall not be done automatically as this will typically lead to the 567 issues described in [RFC6418]. 569 A node may use other sources, for example: node local policy, user 570 input or other mechanisms not defined by the IETF for any of the 571 following: 573 o Construction of a PvD in its entirety (analogous to statically 574 configuring IP on an interface) 576 o Supplementing some, or all learned PvDs with particular 577 configuration elements 579 o Merging of information from different PvDs (if this is explicitly 580 allowed by policy) 582 As an example, a node administrator could configure the node to use a 583 specific DNS resolver on a particular interface, or for a particular 584 named PvD. In the case of a per-interface DNS resolver, this might 585 override or augment the DNS resolver configuration for PvDs that are 586 discovered on that interface. Such creation/augmentation of PvD(s) 587 could be static or dynamic. The specific mechanism(s) for 588 implementing this are outside of scope of this document. Such a 589 merging or overriding of DNS resolver configuration might be contrary 590 to the policy that applies to a special-purpose connection, such as 591 for example those discussed in Section 5.2.1 and Section 5.2.4. In 592 such cases, either the special-purpose connection should not be used, 593 or the merging/overriding should not be performed. 595 5.2. Consistent use of PvDs for Network Connections 597 PvDs enable PvD-aware nodes to consistently use the correct set of 598 configuration elements to serve specific network requests from 599 beginning to end. This section provides examples of such use. 601 5.2.1. Name Resolution 603 When a PvD-aware node needs to resolve the name of the destination 604 for use by a connection request, the node could use one, or multiple 605 PvDs for a given name lookup. 607 The node shall chose a single PvD if, for example, the node policy 608 required the use of a particular PvD for a specific purpose (e.g., to 609 download an MMS message using a specific APN over a cellular 610 connection or to direct traffic of enterprise applications to a VPN 611 connection to the enterprise network). To make this selection, the 612 node could use a match between the PvD DNS suffix and an FQDN which 613 is being resolved or match of PvD ID, as determined by the node 614 policy. 616 The node may pick multiple PvDs, if for example, the PvDs are for 617 general purpose Internet connectivity, and the node is attempting to 618 maximize the probability of connectivity similar to the Happy 619 Eyeballs [RFC6555] approach. In this case, the node could perform 620 DNS lookups in parallel, or in sequence. Alternatively, the node may 621 use only one PvD for the lookup, based on the PvD connectivity 622 properties, user configuration of preferred Internet PvD, etc. 624 If an application implements an API that provides a way of explicitly 625 specifying the desired interface or PvD, that interface or PvD should 626 be used for name resolution (and the subsequent connection attempt), 627 provided that the host's configuration permits this. 629 In either case, by default a node uses information obtained via a 630 name service lookup to establish connections only within the same PvD 631 as the lookup results were obtained. 633 For clarification, when it is written that the name service lookup 634 results were obtained "from a PvD", it should be understood to mean 635 that the name service query was issued against a name service which 636 is configured for use in a particular PvD. In that sense, the 637 results are "from" that particular PvD. 639 Some nodes may support transports and / or APIs which provide an 640 abstraction of a single connection, aggregating multiple underlying 641 connections. MPTCP [RFC6182] is an example of such a transport 642 protocol. For connections provided by such transports/APIs, a PvD- 643 aware node may use different PvDs for servicing that logical 644 connection, provided that all operations on the underlying 645 connections are performed consistently within their corresponding 646 PvD(s). 648 5.2.2. Next-hop and Source Address Selection 650 For the purpose of this example, let us assume that the preceding 651 name lookup succeeded in a particular PvD. For each obtained 652 destination address, the node shall perform a next-hop lookup among 653 routers associated with that PvD. As an example, the node could 654 determine such associations via matching the source address prefixes/ 655 specific routes advertised by the router against known PvDs, or 656 receiving an explicit PvD affiliation advertised through a new Router 657 Discovery [RFC4861] option. 659 For each destination, once the best next-hop is found, the node 660 selects the best source address according to rules defined in 661 [RFC6724], but with the constraint that the source address must 662 belong to a range associated with the used PvD. If needed, the node 663 would use prefix policy from the same PvD for selecting the best 664 source address from multiple candidates. 666 When destination / source pairs are identified, they are sorted using 667 the [RFC6724] destination sorting rules and prefix policy table from 668 the used PvD. 670 5.2.3. Listening Applications 672 Consider a host connected to several PvDs, running an application 673 that opens a listening socket / transport API object. The 674 application is authorized by the host policy to use a subset of 675 connected PvDs that may or may not be equal to the complete set of 676 the connected PvDs. As an example, in the case where there are 677 different PvDs on the Wi-Fi and cellular interfaces, for general 678 Internet traffic the host could use only one, preferred PvD at a time 679 (and accordingly, advertise to remote peers the host name and 680 addresses associated with that PvD), or it could use one PvD as the 681 default for outgoing connections, while still allowing use of the 682 other PvDs simultaneously. 684 Another example is a host with an established VPN connection. Here, 685 security policy could be used to permit or deny application's access 686 to the VPN (and other) PvD(s). 688 For non-PvD aware applications, the operating system has policies 689 that determine the authorized set of PvDs and the preferred outgoing 690 PvD. For PvD-aware applications, both the authorized set of PvDs and 691 the default outgoing PvD can be determined as the common subset 692 produced between the OS policies and the set of PvD IDs or 693 characteristics provided by the application. 695 Application input could be provided on per-application, per- 696 transport-API-object or per-transport-API-call basis. The API for 697 application input may have an option for specifying whether the input 698 should be treated as a preference instead of a requirement. 700 5.2.3.1. Processing of Incoming Traffic 702 Unicast IP packets are received on a specific IP address associated 703 with a PvD. For multicast packets, the host can derive the PvD 704 association from other configuration information, such as an explicit 705 PvD property or local policy. 707 The node OS or middleware may apply more advanced techniques for 708 determining the resultant PvD and / or authorization of the incoming 709 traffic. Those techniques are outside of scope of this document. 711 If the determined receiving PvD of a packet is not in the allowed 712 subset of PvDs for the particular application / transport API object, 713 the packet should be handled in the same way as if there were no 714 listener. 716 5.2.3.1.1. Connection-oriented APIs 718 For connection-oriented APIs, when the initial incoming packet is 719 received, the packet PvD is remembered for the established connection 720 and used for handling of outgoing traffic for that connection. While 721 typically, connection-oriented APIs use a connection-oriented 722 transport protocol, such as TCP, it is possible to have a connection- 723 oriented API that uses a generally connectionless transport protocol, 724 such as UDP. 726 For APIs/protocols that support multiple IP traffic flows associated 727 with a single transport API connection object (for example, multi 728 path TCP), the processing rules may be adjusted accordingly. 730 5.2.3.1.2. Connectionless APIs 732 For connectionless APIs, the host should provide an API that PvD- 733 aware applications can use to query the PvD associated with the 734 packet. For outgoing traffic on this transport API object, the OS 735 should use the selected outgoing PvDs, determined as described in 736 Section 5.2.1 and Section 5.2.2. 738 5.2.4. Enforcement of Security Policies 740 By themselves, PvDs do not define, and cannot be used for 741 communication of, security policies. When implemented in a network, 742 this architecture provides the host with information about connected 743 networks. The actual behavior of the host then depends on the host's 744 policies (provisioned through mechanisms out of scope of this 745 document), applied taking received PvD information into account. In 746 some scenarios, e.g., a VPN, such policies could require the host to 747 use only a particular VPN PvD for some / all of the application's 748 traffic (VPN 'disable split tunneling' also known as 'force 749 tunneling' behavior), or apply such restrictions only to selected 750 applications and allow the simultaneous use of the VPN PvD together 751 with the other connected PvDs by the other or all applications (VPN 752 'split tunneling' behavior). 754 5.3. Connectivity Tests 756 Although some PvDs may appear as valid candidates for PvD selection 757 (e.g., good link quality, consistent connection parameters, etc.), 758 they may provide limited or no connectivity to the desired network or 759 the Internet. For example, some PvDs provide limited IP connectivity 760 (e.g., scoped to the link or to the access network), but require the 761 node to authenticate through a web portal to get full access to the 762 Internet. This may be more likely to happen for PvDs which are not 763 trusted by a given PvD-aware node. 765 An attempt to use such a PvD may lead to limited network connectivity 766 or application connection failures. To prevent the latter, a PvD- 767 aware node may perform a connectivity test for the PvD before using 768 it to serve application network connection requests. In current 769 implementations, some nodes already implement this e.g., by trying to 770 reach a dedicated web server (see [RFC6419]). 772 Section 5.2 describes how a PvD-aware node shall maintain and use 773 multiple PvDs separately. The PvD-aware node shall perform a 774 connectivity test and, only after validation of the PvD, consider 775 using it to serve application connections requests. Ongoing 776 connectivity tests are also required, since during the IP session, 777 the end-to-end connectivity could be disrupted for various reasons 778 (e.g., L2 problems, IP QoS issues); hence, a connectivity monitoring 779 function is needed to check the connectivity status and remove the 780 PvD from the set of usable PvDs if necessary. 782 There may be cases where a connectivity test for PvD selection may 783 not be appropriate and should be complemented, or replaced, by PvD 784 selection based on other factors. For example, this could be 785 realized by leveraging some 3GPP and IEEE mechanisms, which would 786 allow the exposure of some PvD characteristics to the node (e.g., 787 3GPP Access Network Discovery and Selection Function (ANDSF) 788 [TS23402], IEEE 802.11u [IEEE802.11u]/ANQP). 790 5.4. Relationship to Interface Management and Connection Managers 792 Current devices, such as mobile handsets make use of proprietary 793 mechanisms and custom applications to manage connectivity in 794 environments with multiple interfaces and multiple sets of network 795 configuration. These mechanisms or applications are commonly known 796 as connection managers [RFC6419]. 798 Connection managers sometimes rely on policy servers to allow a node 799 that is connected to multiple networks to perform network selection. 800 They can also make use of routing guidance from the network (e.g., 801 3GPP ANDSF [TS23402]). Although connection managers solve some 802 connectivity problems, they rarely address network selection problems 803 in a comprehensive manner. With proprietary solutions, it is 804 challenging to present coherent behavior to the end user of the 805 device, as different platforms present different behaviors even when 806 connected to the same network, with the same type of interface, and 807 for the same purpose. The architecture described in this document 808 should improve the hosts behavior by providing the hosts with tools 809 and guidance to make informed network selection decisions. 811 6. PvD support in APIs 813 For all levels of PvD support in APIs described in this chapter, it 814 is expected that the notifications about changes in the set of 815 available PvDs are exposed as part of the API surface. 817 6.1. Basic 819 Applications are not PvD-aware in any manner and only submit 820 connection requests. The node performs PvD selection implicitly, 821 without any application participation, based purely on node-specific 822 administrative policies and / or choices made by the user from a user 823 interface provided by the operating environment, not by the 824 application. 826 As an example, PvD selection can be done at the name service lookup 827 step by using the relevant configuration elements, such as those 828 described in [RFC6731]. As another example, PvD selection could be 829 made based on application identity or type (i.e., a node could always 830 use a particular PvD for a VOIP application). 832 6.2. Intermediate 834 Applications indirectly participate in PvD selection by specifying 835 hard requirements and soft preferences. As an example, a real time 836 communication application intending to use the connection for the 837 exchange of real time audio / video data may indicate a preference or 838 a requirement for connection quality, which could affect PvD 839 selection (different PvDs could correspond to Internet connections 840 with different loss rates and latencies). 842 Another example is the connection of an infrequently executed 843 background activity, which checks for application updates and 844 performs large downloads when updates are available. For such 845 connections, a cheaper or zero cost PvD may be preferable, even if 846 such a connection has a higher relative loss rate or lower bandwidth. 847 The node performs PvD selection based on applications' inputs and 848 policies and / or user preferences. Some / all properties of the 849 resultant PvD may be exposed to applications. 851 6.3. Advanced 853 PvDs are directly exposed to applications for enumeration and 854 selection. Node polices and / or user choices may still override the 855 applications' preferences and limit which PvD(s) can be enumerated 856 and / or used by the application, irrespective of any preferences 857 which the application may have specified. Depending on the 858 implementation, such restrictions (imposed by node policy and / or 859 user choice) may or may not be visible to the application. 861 7. PvD Trust for PvD-Aware Node 863 7.1. Untrusted PvDs 865 Implicit and explicit PvDs for which no trust relationship exists are 866 considered untrusted. Only PvDs which meet the requirements in 867 Section 7.2 are trusted; any other PvD is untrusted. 869 In order to avoid the various forms of misinformation that could 870 occur when PvDs are untrusted, nodes that implement PvD separation 871 cannot assume that two explicit PvDs with the same identifier are 872 actually the same PvD. A node that makes this assumption will be 873 vulnerable to attacks where, for example, an open Wi-Fi hotspot might 874 assert that it was part of another PvD and thereby attempt to draw 875 traffic intended for that PvD onto its own network. 877 Since implicit PvD identifiers are synthesized by the node, this 878 issue cannot arise with implicit PvDs. 880 Mechanisms exist (for example, [RFC6731]) whereby a PvD can provide 881 configuration information that asserts special knowledge about the 882 reachability of resources through that PvD. Such assertions cannot be 883 validated unless the node has a trust relationship with the PvD; 884 therefore, assertions of this type must be ignored by nodes that 885 receive them from untrusted PvDs. Failure to ignore such assertions 886 could result in traffic being diverted from legitimate destinations 887 to spoofed destinations. 889 7.2. Trusted PvDs 891 Trusted PvDs are PvDs for which two conditions apply: First, a trust 892 relationship must exist between the node that is using the PvD 893 configuration and the source that provided that configuration; this 894 is the authorization portion of the trust relationship. Second, 895 there must be some way to validate the trust relationship. This is 896 the authentication portion of the trust relationship. Two mechanisms 897 for validating the trust relationship are defined. 899 It shall be possible to validate the trust relationship for all 900 advertised elements of a trusted PvD, irrespective of whether the PvD 901 elements are communicated as a whole, e.g., in a single DHCP option, 902 or separately, e.g., in supplementary RA options. The feasibility of 903 mechanisms to implement a trust relationship for all PvD elements 904 will be determined in the respective companion design documents. 906 7.2.1. Authenticated PvDs 908 One way to validate the trust relationship between a node and the 909 source of a PvD is through the combination of cryptographic 910 authentication and an identifier configured on the node. 912 If authentication is done using a public key mechanism such as PKI 913 certificate chain validation or DANE, authentication by itself is not 914 enough since theoretically any PvD could be authenticated in this 915 way. In addition to authentication, the node would need 916 configuration to trust the identifier being authenticated. 917 Validating the authenticated PvD name against a list of PvD names 918 configured as trusted on the node would constitute the authorization 919 step in this case. 921 7.2.2. PvDs Trusted by Attachment 923 In some cases, a trust relationship may be validated by some means 924 other than those described in Section 7.2.1 simply by virtue of the 925 connection through which the PvD was obtained. For instance, a 926 handset connected to a mobile network may know through the mobile 927 network infrastructure that it is connected to a trusted PvD. 928 Whatever mechanism was used to validate that connection constitutes 929 the authentication portion of the PvD trust relationship. 930 Presumably, such a handset would be configured from the factory (or 931 else through mobile operator or user preference settings) to trust 932 the PvD, and this would constitute the authorization portion of this 933 type of trust relationship. 935 8. Contributors 937 The following individuals contributed to this document (listed in no 938 specific order): Alper Yegin (alper.yegin@yegin.org), Aaron Yi Ding 939 (yding@cs.helsinki.fi), Zhen Cao (caozhenpku@gmail.com), Dapeng Liu 940 (liudapeng@chinamobile.com), Dave Thaler (dthaler@microsoft.com), 941 Dmitry Anipko (dmitry.anipko@microsoft.com), Hui Deng 942 (denghui@chinamobile.com), Jouni Korhonen (jouni.nospam@gmail.com), 943 Juan Carlos Zuniga (JuanCarlos.Zuniga@InterDigital.com), Konstantinos 944 Pentikousis (k.pentikousis@huawei.com), Marc Blanchet 945 (marc.blanchet@viagenie.ca), Margaret Wasserman 946 (margaretw42@gmail.com), Pierrick Seite (pierrick.seite@orange.com), 947 Suresh Krishnan (suresh.krishnan@ericsson.com), Teemu Savolainen 948 (teemu.savolainen@nokia.com), Ted Lemon (ted.lemon@nominum.com) and 949 Tim Chown (tjc@ecs.soton.ac.uk). 951 9. Acknowledgments 952 The authors would like to thank (in no specific order) Ian Farrer, 953 Markus Stenberg and Mikael Abrahamsson for their review and comments. 955 10. IANA Considerations 957 This memo does not include any IANA requests. 959 11. Security Considerations 961 There are at least three different forms of attacks that can be 962 performed using configuration sources that support multiple 963 provisioning domains. 965 Tampering with provided configuration information: An attacker may 966 attempt to modify information provided inside the PvD container 967 option. These attacks can easily be prevented by using message 968 integrity features provided by the underlying protocol used to 969 carry the configuration information. E.g., SEND [RFC3971] would 970 detect any form of tampering with the RA contents and the DHCPv6 971 [RFC3315] AUTH option that would detect any form of tampering with 972 the DHCPv6 message contents. This attack can also be performed by 973 a compromised configuration source by modifying information inside 974 a specific PvD, in which case the mitigations proposed in the next 975 subsection may be helpful. 977 Rogue configuration source: A compromised configuration source, such 978 as a router or a DHCPv6 server, may advertise information about 979 PvDs that it is not authorized to advertise. E.g., a coffee shop 980 WLAN may advertise configuration information purporting to be from 981 an enterprise and may try to attract enterprise related traffic. 982 This may also occur accidentally if two sites choose the same 983 identifier (e.g., "linsky"). 985 In order to detect and prevent this, the client must be able to 986 authenticate the identifier provided by the network. This means 987 that the client must have configuration information that maps the 988 PvD identifier to an identity, and must be able to authenticate 989 that identity. 991 In addition, the network must provide information the client can 992 use to authenticate the identity. This could take the form of a 993 PKI-based or DNSSEC-based trust anchor, or a key remembered from a 994 previous leap-of-faith authentication of the identifier. 996 Because the PvD-specific information may come to the network 997 infrastructure with which the client is actually communicating 998 from some upstream provider, it is necessary in this case that the 999 PvD container and its contents be relayed to the client unchanged, 1000 leaving the upstream provider's signature intact. 1002 Replay attacks: A compromised configuration source or an on-link 1003 attacker may try to capture advertised configuration information 1004 and replay it on a different link, or at a future point in time. 1005 This can be avoided by including a replay protection mechanism 1006 such as a timestamp or a nonce inside the PvD container to ensure 1007 the validity of the provided information. 1009 12. References 1011 [I-D.bhandari-dhc-class-based-prefix] 1012 Systems, C., Halwasia, G., Gundavelli, S., Deng, H., 1013 Thiebaut, L., Korhonen, J. and I. Farrer, "DHCPv6 class 1014 based prefix", Internet-Draft draft-bhandari-dhc-class- 1015 based-prefix-05, July 2013. 1017 [I-D.korhonen-dmm-prefix-properties] 1018 Korhonen, J., Patil, B., Gundavelli, S., Seite, P. and D. 1019 Liu, "IPv6 Prefix Mobility Management Properties", 1020 Internet-Draft draft-korhonen-dmm-prefix-properties-03, 1021 October 2012. 1023 [IEEE802.11u] 1024 IEEE, "IEEE Standard 802.11u-2011 (Amendment 9: 1025 Interworking with External Networks)", 2011. 1027 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C. and 1028 M. Carney, "Dynamic Host Configuration Protocol for IPv6 1029 (DHCPv6)", RFC 3315, July 2003. 1031 [RFC3971] Arkko, J., Kempf, J., Zill, B. and P. Nikander, "SEcure 1032 Neighbor Discovery (SEND)", RFC 3971, March 2005. 1034 [RFC4861] Narten, T., Nordmark, E., Simpson, W. and H. Soliman, 1035 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 1036 September 2007. 1038 [RFC5739] Eronen, P., Laganier, J. and C. Madson, "IPv6 1039 Configuration in Internet Key Exchange Protocol Version 2 1040 (IKEv2)", RFC 5739, February 2010. 1042 [RFC5996] Kaufman, C., Hoffman, P., Nir, Y. and P. Eronen, "Internet 1043 Key Exchange Protocol Version 2 (IKEv2)", RFC 5996, 1044 September 2010. 1046 [RFC6182] Ford, A., Raiciu, C., Handley, M., Barre, S. and J. 1047 Iyengar, "Architectural Guidelines for Multipath TCP 1048 Development", RFC 6182, March 2011. 1050 [RFC6418] Blanchet, M. and P. Seite, "Multiple Interfaces and 1051 Provisioning Domains Problem Statement", RFC 6418, 1052 November 2011. 1054 [RFC6419] Wasserman, M. and P. Seite, "Current Practices for 1055 Multiple-Interface Hosts", RFC 6419, November 2011. 1057 [RFC6555] Wing, D. and A. Yourtchenko, "Happy Eyeballs: Success with 1058 Dual-Stack Hosts", RFC 6555, April 2012. 1060 [RFC6724] Thaler, D., Draves, R., Matsumoto, A. and T. Chown, 1061 "Default Address Selection for Internet Protocol Version 6 1062 (IPv6)", RFC 6724, September 2012. 1064 [RFC6731] Savolainen, T., Kato, J. and T. Lemon, "Improved Recursive 1065 DNS Server Selection for Multi-Interfaced Nodes", RFC 1066 6731, December 2012. 1068 [RFC7078] Matsumoto, A., Fujisaki, T. and T. Chown, "Distributing 1069 Address Selection Policy Using DHCPv6", RFC 7078, January 1070 2014. 1072 [TS23402] 3GPP, "3GPP TS 23.402; Architecture enhancements for non- 1073 3GPP accesses; release 12", 2014. 1075 Author's Address 1077 Dmitry Anipko, editor 1078 Unaffiliated 1080 Phone: +1 425 442 6356 1081 Email: dmitry.anipko@gmail.com