idnits 2.17.00 (12 Aug 2021) /tmp/idnits5744/draft-anipko-mif-mpvd-arch-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 91 has weird spacing: '...uration and/o...' == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (October 18, 2013) is 3136 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'REF ANDSF' is mentioned on line 453, but not defined == Unused Reference: 'I-D.ietf-6man-addr-select-opt' is defined on line 597, but no explicit reference was found in the text == Outdated reference: draft-ietf-6man-addr-select-opt has been published as RFC 7078 Summary: 0 errors (**), 0 flaws (~~), 6 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MIF Working Group D. Anipko 3 Internet-Draft Microsoft Corporation 4 Intended status: Informational October 18, 2013 5 Expires: April 19, 2014 7 Multiple Provisioning Domain Architecture 8 draft-anipko-mif-mpvd-arch-04 10 Abstract 12 This document is a product of the work of MIF architecture design 13 team. It outlines a solution framework for some of the issues, 14 experienced by nodes that can be attached to multiple networks. The 15 framework defines the notion of a Provisioning Domain (PVD) - a 16 consistent set of network configuration information, and PVD-aware 17 nodes - nodes which learn PVDs from the attached network(s) and/or 18 other sources and manage and use multiple PVDs for connectivity 19 separately and consistently. 21 Status of this Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on April 19, 2014. 38 Copyright Notice 40 Copyright (c) 2013 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents (http://trustee.ietf.org/ 45 license-info) in effect on the date of publication of this document. 46 Please review these documents carefully, as they describe your rights 47 and restrictions with respect to this document. Code Components 48 extracted from this document must include Simplified BSD License text 49 as described in Section 4.e of the Trust Legal Provisions and are 50 provided without warranty as described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 55 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 56 2. Definitions and types of PVDs . . . . . . . . . . . . . . . . 3 57 2.1. Explicit PVDs . . . . . . . . . . . . . . . . . . . . . . 4 58 2.2. Implicit PVDs and incremental adoption of the explicit PVDs 5 59 2.3. Relationship between PVDs and interfaces . . . . . . . . . 5 60 2.4. PVD identity/naming . . . . . . . . . . . . . . . . . . . 5 61 2.5. Relationship to dual-stack networks . . . . . . . . . . . 6 62 2.6. Elements of PVD . . . . . . . . . . . . . . . . . . . . . 7 63 3. Example network configurations and number of PVDs . . . . . . 7 64 4. Reference model of PVD-aware node . . . . . . . . . . . . . . 7 65 4.1. Constructions and maintenance of separate PVDs . . . . . . 7 66 4.2. Consistent use of PVDs for network connections . . . . . . 7 67 4.2.1. Name resolution . . . . . . . . . . . . . . . . . . . 7 68 4.2.2. Next-hop and source address selection . . . . . . . . 8 69 4.3. Connectivity tests . . . . . . . . . . . . . . . . . . . . 9 70 4.4. Relationship to interface management and connection manager 9 71 5. PVD support in APIs . . . . . . . . . . . . . . . . . . . . . 10 72 5.1. Basic . . . . . . . . . . . . . . . . . . . . . . . . . . 10 73 5.2. Intermediate . . . . . . . . . . . . . . . . . . . . . . . 10 74 5.3. Advanced . . . . . . . . . . . . . . . . . . . . . . . . . 10 75 6. PVD-aware nodes trust to PVDs . . . . . . . . . . . . . . . . 11 76 6.1. Untrusted PVDs . . . . . . . . . . . . . . . . . . . . . . 11 77 6.2. Trusted PVDs . . . . . . . . . . . . . . . . . . . . . . . 11 78 6.2.1. Authenticated PVDs . . . . . . . . . . . . . . . . . . 11 79 6.2.2. PVDs trusted by attachment . . . . . . . . . . . . . . 12 80 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 81 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 82 9. Security Considerations . . . . . . . . . . . . . . . . . . . 12 83 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 84 10.1. Normative References . . . . . . . . . . . . . . . . . . 12 85 10.2. Informative References . . . . . . . . . . . . . . . . . 12 86 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 13 88 1. Introduction 90 Nodes attached to multiple networks may encounter problems due to 91 conflict of the networks configuration and/or simultaneous use of 92 the multiple available networks. While existing implementations 93 apply various techniques ([RFC6419]) to tackle such problems, in many 94 cases the issues may still appear. The MIF problem statement 95 document [RFC6418] describes the general landscape as well as 96 discusses many specific issues and scenarios details, and are not 97 listed in this document. 99 Across the layers, problems enumerated in [RFC6418] can be grouped 100 into 3 categories: 102 1. Lack of consistent and distinctive management of configuration 103 elements, associated with different networks. 105 2. Inappropriate mixed use of configuration elements, associated 106 with different networks, in the course of a particular network 107 activity / connection. 109 3. Use of a particular network, not consistent with the intent of 110 the scenario / involved parties, leading to connectivity failure 111 and / or other undesired consequences. 113 As an illustration: an example of (1) is a single node-scoped list of 114 DNS server IP addresses, learned from different networks, leading to 115 failures or delays in resolution of name from particular namespaces; 116 an example of (2) is use of an attempt to resolve a name of a HTTP 117 proxy server, learned from a network A, with a DNS server, learned 118 from a network B, likely to fail; an example of (3) is a use of 119 employer-sponsored VPN connection for peer-to-peer connections, 120 unrelated to employment activities. 122 This architecture describes a solution to these categories of 123 problems, respectively, by: 125 1. Introducing a formal notion of the PVD, including PVD identity, 126 and ways for nodes to learn the intended associations among 127 acquired network configuration information elements. 129 2. Introducing a reference model for a PVD-aware node, preventing 130 inadvertent mixed use of the configuration information, which may 131 belong to different PVDs. 133 3. Providing recommendations on PVD selection based on PVD identity 134 and connectivity tests for common scenarios. 136 1.1. Requirements Language 138 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 139 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 140 document are to be interpreted as described in RFC 2119 [RFC2119]. 142 2. Definitions and types of PVDs 144 Provisioning Domain: a consistent set of network configuration 145 information. Classically, the entire set available on a single 146 interface is provided by a single source, such as network 147 administrator, and can therefore be treated as a single provisioning 148 domain. In modern IPv6 networks, multihoming can result in more than 149 one provisioning domain being present on a single link. In some 150 scenarios, it is also possible for elements of the same domain to be 151 present on multiple links. 153 Typical examples of information in a provisioning domain, learned 154 from the network, are: source address prefixes, to be used by 155 connections within the provisioning domain, IP address of DNS server, 156 name of HTTP proxy server if available, DNS suffixes associated with 157 the network etc. 159 PVD-aware node: a node that supports association of network 160 configuration information into PVDs, and using the resultant PVDs to 161 serve requests for network connections in ways, consistent with 162 recommendations of this architecture. 164 2.1. Explicit PVDs 166 A node may receive explicit information from the network and/or other 167 sources, about presence of PVDs and association of particular network 168 information with a particular PVD. PVDs, constructed based on such 169 information, are referred to in this document as "explicit". 171 Protocol changes/extensions will likely be required to support the 172 explicit PVDs by IETF-defined mechanisms. As an example, one could 173 think of one or several DHCP options, carrying PVD identity and / or 174 its elements. A different approach could be to introduce a DHCP 175 option, which only carries identity of a PVD, while the association 176 of network information elements with that identity, is implemented by 177 the respective protocols - such as e.g., with a Router Discovery 178 [RFC4861] option associating an address range with a PVD. 180 Specific, existing or new, features of networking protocols to enable 181 delivery of PVD identity and association with various network 182 information elements will be defined in companion design documents. 184 Link-specific and/or vendor-proprietary mechanisms for discovery of 185 PVD information, different from the IETF-defined mechanisms, can be 186 used by the nodes separately from or together with IETF-defined 187 mechanisms, as long as they allow to discover necessary elements of 188 the PVD(s). In all cases, by default nodes must ensure that the 189 lifetime of all dynamically discovered PVD configuration is 190 appropriately limited by the relevant events - for example, if an 191 interface media state change was indicated, the previously discovered 192 information may no longer be valid and needs to be re-discovered or 193 confirmed. 195 It shall be possible for networks to communicate that some of their 196 configuration elements could be used within a context of other 197 networks/PVDs. Based on such declaration and their policies, PVD- 198 aware nodes may choose to inject such elements into some or all other 199 PVDs they connect to. 201 In some network topologies, the network infrastructure elements may 202 need to advertise multiple PVDs. The details of how this is done 203 generally will be defined in the individual companion design 204 documents. However, where different design choices are possible, the 205 choice that requires smaller number of packets shall be preferred for 206 efficiency. 208 2.2. Implicit PVDs and incremental adoption of the explicit PVDs 210 It is likely that for a long time there may be networks which do not 211 advertise explicit PVD information, since deployment of any new 212 features in networking protocols is a relatively slow process. 214 When connected to networks, which don't advertise explicit PVD 215 information, PVD-aware shall automatically create separate PVDs for 216 configuration received on multiple interfaces. Such PVDs are 217 referred to in this document as "implicit". 219 With implicit PVDs,PVD-aware nodes may still provide benefits to 220 their users, compared to non-PVD aware nodes, by using network 221 information from different interfaces separately and consistently to 222 serve network connection requests, following best practices described 223 in Section 4. 225 In the mixed mode, where e.g., multiple networks are available on the 226 link the interface is attached to, and only some of the networks 227 advertise PVD information, the PVD-aware node shall create explicit 228 PVDs based on explicitly learned PVD information, and associate the 229 rest of the configuration with an implicit PVD created for that 230 interface. 232 2.3. Relationship between PVDs and interfaces 234 Implicit PVDs are limited to network configuration information 235 received on a single interface. Explicit PVDs, in practice will 236 often also be scoped to a configuration related to a particular 237 interface, however per this architecture there is no such requirement 238 or limitation and as defined in this architecture, explicit PVDs may 239 include information related to more than one interfaces, if the node 240 learns presence of the same PVD on those interfaces and the 241 authentication of the PVD ID meets the level required by the node 242 policy. 244 It is an intent of this architecture to support such scenarios among 245 others. Hence, it shall be noted that no hierarchical relationship 246 exists between interfaces and PVDs: it is possible for multiple PVDs 247 to be simultaneously accessible over one interface, as well as single 248 PVD to be simultaneously accessible over multiple interfaces. 250 2.4. PVD identity/naming 252 For explicit PVDs, PVD ID (globally unique ID, that possibly is 253 human-readable) is received as part of that information. For 254 implicit PVDs, the node assigns a locally generated globally unique 255 ID to each implicit PVD. 257 PVD-aware node may use these IDs to choose a PVD with matching ID for 258 special-purpose connection requests, in accordance with node policy 259 or choice by advanced applications, and/or to present human-readable 260 IDs to the end-user for selection of Internet-connected PVDs. 262 A single network provider may operate multiple networks, including 263 networks at different locations. In such cases, the provider may 264 chose whether to advertise single or multiple PVD identities at all 265 or some of those networks, as it suits their business needs. This 266 architecture doesn't impose specific requirements in this regard. 268 When multiple nodes are connected to the same link, where one or more 269 explicit PVDs are available, this architecture assumes that the 270 information about all available PVDs is advertized by the networks to 271 all the connected nodes. At the same time, the connected nodes may 272 have different heuristics, policies and/or other settings, including 273 configured set of their trusted PVDs, which may lead to different 274 PVDs actually being used by different nodes for their connections. 276 Possible extensions, where different sets of PVDs may be advertised 277 by the networks to different connected nodes, are out of scope for 278 this document. 280 2.5. Relationship to dual-stack networks 282 When applied to dual-stack networks, the PVD definition allows for 283 multiple PVDs to be created, where each PVD contain information for 284 only one address family, or for a single PVD that contains 285 information about multiple address families. This architecture 286 requires that accompanying design documents for accompanying protocol 287 changes must support PVDs containing information from multiple 288 address families. PVD-aware nodes must be capable of dealing with 289 both single-family and multi-family PVDs. 291 For explicit PVDs, the choice of either of the approaches is a policy 292 decision of a network administrator and/or node user/administrator. 293 Since some of the IP configuration information that can be learned 294 from the network can be applicable to multiple address families (for 295 instance DHCP address selection option [I-D.ietf-6man-addr-select- 296 opt]), it is likely that dual-stack networks will deploy single PVDs 297 for both address families. 299 For implicit PVDs, by default PVD-aware nodes shall including 300 multiple IP families into single implicit PVD created for an 301 interface. At the time of writing of this document in dual-stack 302 networks it appears to be a common practice for configuration of both 303 address families to be provided by a single source. 305 A PVD-aware node that provides API to use / enumerate / inspect PVDs 306 and/or their properties shall provide ability to filter PVDs and/or 307 their properties by address family. 309 2.6. Elements of PVD 311 3. Example network configurations and number of PVDs 313 4. Reference model of PVD-aware node 315 4.1. Constructions and maintenance of separate PVDs 317 It is assumed that normally, configuration information contained in a 318 single PVD, shall be sufficient for a node to fulfill a network 319 connection request by an application, and hence there should be no 320 need to attempt to merge information across different PVDs. 322 Nevertheless, even when a PVD lack some parts of the configuration, 323 merging of information from different PVD(s) shall not be done 324 automatically, since typically it would lead to issues described in 325 [RFC6418]. 327 A node may use other sources, such as e.g., node local policy, user 328 input or other mechanisms, not defined by IETF, to either construct a 329 PVD entirely (analogously to static IP configuration of an 330 interface), or supplement with particular elements all or some PVDs 331 learned from the network, or potentially merge information from 332 different PVDs, if such merge is known to the node to be safe, based 333 on explicit policies. 335 As an example, node administrator could inject a not ISP-specific DNS 336 server into PVDs for any of the networks the node could become 337 attached to. Such creation / augmentation of PVD(s) could be static 338 or dynamic. The particular implementation mechanisms are outside of 339 the scope of this document. 341 4.2. Consistent use of PVDs for network connections 343 PVDs enable PVD-aware nodes to use consistently a correct set of 344 configuration elements to serve the specific network requests from 345 beginning to end. This section describes specific examples of such 346 consistent use. 348 4.2.1. Name resolution 349 When PVD-aware node needs to resolve a name of the destination used 350 by a connection request, the node could decide to use one, or 351 multiple PVDs for a given name lookup. 353 The node shall chose one PVD, if e.g., the node policy required to 354 use a particular PVD for a particular purpose (e.g. to download an 355 MMS using a specific APN over a cellular connection). To make the 356 choice, the node could use a match of the PVD DNS suffix or other 357 form of PVD ID, as determined by the node policy. 359 The node may pick multiple PVDs, if e.g., they are general purpose 360 PVDs providing connectivity to the Internet, and the node desires to 361 maximize chances for connectivity in Happy Eyeballs style. In this 362 case, the node could do the lookups in parallel, or in sequence. 363 Alternatively, the node may use for the lookup only one PVD, based on 364 the PVD connectivity properties, user choice of the preferred 365 Internet PVD, etc. 367 In either case, by default the node uses information obtained in a 368 name service lookup to establish connections only within the same PVD 369 from which the lookup results were obtained. 371 For simplicity, when we say that name service lookup results were 372 obtained from a PVD, what we mean is that the name service query was 373 issued against a name service the configuration of which is present 374 in a particular PVD. In that sense, the results are "from" that 375 particular PVD. 377 Some nodes may support transports and/or APIs, which provide an 378 abstraction of a single connection, aggregating multiple underlying 379 connections. MPTCP [RFC6182] is an example of such transport 380 protocol. For the connections provided by such transports/APIs, a 381 PVD-aware node may use different PVDs for servicing of that logical 382 connection, provided that all operations on the underlying 383 connections are done consistently within their corresponding PVD(s). 385 4.2.2. Next-hop and source address selection 387 For the purpose of this discussion, let's assume the preceding name 388 lookup succeeded in a particular PVD. For each obtained destination 389 address, the node shall perform a next-hop lookup among routers, 390 associated with that PVD. As an example, such association could be 391 determined by the node via matching the source address prefixes/ 392 specific routes advertized by the router against known PVDs, or 393 receiving explicit PVD affiliation advertized through a new Router 394 Discovery [RFC4861] option. 396 For each destination, once the best next-hop is found, the node 397 selects best source address according to the [RFC6724] rules, but 398 with a constraint that the source address must belong to a range 399 associated with the used PVD. If needed, the node would use the 400 prefix policy from the same PVD for the best source address selection 401 among multiple candidates. 403 When destination/source pairs are identified, then they are sorted 404 using the [RFC6724] destination sorting rules and the prefix policy 405 table from the used PVD. 407 4.3. Connectivity tests 409 Although some PVDs may appear as valid candidates for PVD selection 410 (e.g. good link quality, consistent connection parameters, etc.), 411 they may provide limited or no connectivity to the desired network or 412 the Internet. For example, some PVDs provide limited IP connectivity 413 (e.g., scoped to the link or to the access network), but require the 414 node to authenticate through a web portal to get full access to the 415 Internet. This may be more likely to happen for PVDs, which are not 416 trusted by the given PVD-aware node. 418 An attempt to use such PVD may lead to limited network connectivity 419 or connection failures for applications. To prevent the latter, a 420 PVD-aware node may perform connectivity test for the PVD, before 421 using it to serve network connection requests of the applications. 422 In current implementations, some nodes do that, for instance, by 423 trying to reach a dedicated web server (e.g., see [RFC6419]). 425 Per Section 4.2, a PVD-aware node shall maintain and use multiple 426 PVDs separately. The PVD-aware node shall perform connectivity test 427 and, only after validation of the PVD, consider using it to serve 428 application connections requests. Ongoing connectivity tests are 429 also required, since during the IP session, the end-to-end 430 connectivity could be disrupted for various reasons (e.g. poor L2, 431 IP QoS issues); hence a connectivity monitoring function is needed to 432 check the connectivity status and remove the PVD from the set of 433 usable PVDs if necessary. 435 There may be cases where a connectivity test for PVD selection may be 436 not appropriate and should be complemented, or replaced, by PVD 437 selection based on other factors. This could be realized e.g., by 438 leveraging some 3GPP and IEEE mechanisms, which would allow to expose 439 some PVD characteristics to the node (e.g. 3GPP Access Network 440 Discovery and Selection Function (ANDSF) [REF ANDSF], IEEE 802.11u/ 441 ANQP [REF 802.11u]). 443 4.4. Relationship to interface management and connection managers 444 Current devices such as mobile handsets make use of proprietary 445 mechanisms and custom applications to manage connectivity in 446 environments with multiple interfaces and multiple sets of network 447 configurations. These mechanisms or applications are commonly known 448 as connection managers [RFC6419]. 450 Connection managers sometimes rely on policy servers to allow the 451 node, connected to multiple networks, perform the network selection. 452 They can also make use of routing guidance from the network (e.g. 453 3GPP ANDSF [REF ANDSF]). Although connection managers solve some 454 connectivity problems, they rarely address the network selection 455 problems in a comprehensive manner. With proprietary solutions, it 456 is challenging to present a coherent behaviour to the end user of the 457 device, as different platforms present different behaviours even when 458 connected to the same network, with the same type of interface, and 459 for the same purpose. 461 5. PVD support in APIs 463 In all cases changes in available PVDs must be somehow exposed, 464 appropriately for each of the approaches. 466 5.1. Basic 468 Applications are not PVD-aware in any manner, and only submit 469 connection requests. The node performs PVD selection implicitly, 470 without any otherwise applications participation, and based purely on 471 node-specific administrative policies and/or choices made by the user 472 in a user interface provided by the operating environment, not by the 473 application. 475 As an example, such PVD selection can be done at the name service 476 lookup step, by using the relevant configuration elements, such as 477 e.g., those described in [RFC6731]. As another example, the PVD 478 selection could be done based on application identity or type (i.e., 479 a node could always use a particular PVD for a VOIP application). 481 5.2. Intermediate 483 Applications indirectly participate in selection of PVD by specifying 484 hard requirements and soft preferences. The node performs PVD 485 selection, based on applications inputs and policies and/or user 486 preferences. Some / all properties of the resultant PVD may be 487 exposed to applications. 489 5.3. Advanced 491 PVDs are directly exposed to applications, for enumeration and 492 selection. Node polices and/or user choices, may still override the 493 application preferences and limit which PVD(s) can be enumerated and/ 494 or used by the application, irrespectively of any preferences which 495 application may have specified. Depending on the implementation, 496 such restrictions, imposed per node policy and/or user choice, may or 497 may not be visible to the application. 499 6. PVD-aware nodes trust to PVDs 501 6.1. Untrusted PVDs 503 Implicit and explicit PVDs for which no trust relationship exists are 504 considered untrusted. Only PVDs, which meet the requirements in 505 Section 6.2, are trusted; any other PVD is untrusted. 507 In order to avoid various forms of misinformation that can be 508 asserted when PVDs are untrusted, nodes that implement PVD separation 509 cannot assume that two explicit PVDs with the same identifier are 510 actually the same PVD. A node that did make this assumption would be 511 vulnerable to attacks where for example an open Wifi hotspot might 512 assert that it was part of another PVD, and thereby might draw 513 traffic intended for that PVD onto its own network. 515 Since implicit PVD identifiers are synthesized by the node, this 516 issue cannot arise with implicit PVDs. 518 Mechanisms exist (for example, [RFC6731]) whereby a PVD can provide 519 configuration information that asserts special knowledge about the 520 reachability of resources through that PVD. Such assertions cannot 521 be validated unless the node has a trust relationship with the PVD; 522 assertions of this type therefore must be ignored by nodes that 523 receive them from untrusted PVDs. Failure to ignore such assertions 524 could result in traffic being diverted from legitimate destinations 525 to spoofed destinations. 527 6.2. Trusted PVDs 529 Trusted PVDs are PVDs for which two conditions apply. First, a 530 trust relationship must exist between the node that is using the PVD 531 configuration and the source that provided that configuration; this 532 is the authorization portion of the trust relationship. Second, 533 there must be some way to validate the trust relationship. This is 534 the authentication portion of the trust relationship. Two 535 mechanisms for validating the trust relationship are defined. 537 It shall be possible to validate the trust relationship for all 538 advertised elements of a trusted PVD, irrespectively of whether the 539 PVD elements are communicated as a whole, e.g. in a single DHCP 540 option, or separately, e.g. in supplementary RA options. Whether or 541 not this is feasible to provide mechanisms to implement trust 542 relationship for all PVD elements, will be determined in the 543 respective companion design documents. 545 6.2.1. Authenticated PVDs 546 One way to validate the trust relationship between a node and the 547 source of a PVD is through the combination of cryptographic 548 authentication and an identifier configured on the node. In some 549 cases, the two could be the same; for example, if authentication is 550 done with a shared secret, the secret would have to be associated 551 with the PVD identifier. Without a (PVD Identifier, shared key) 552 tuple, authentication would be impossible, and hence authentication 553 and authorization are combined. 555 However, if authentication is done using some public key mechanism 556 such as a TLS cert or DANE, authentication by itself isn't enough, 557 since theoretically any PVD could be authenticated in this way. In 558 addition to authentication, the node would need to be configured to 559 trust the identifier being authenticated. Validating the 560 authenticated PVD name against a list of PVD names configured as 561 trusted on the node would constitute the authorization step in this 562 case. 564 6.2.2. PVDs trusted by attachment 566 In some cases a trust relationship may be validated by some means 567 other than described in Section 6.2.1, simply by virtue of the 568 connection through which the PVD was obtained. For instance, a 569 handset connected to a mobile network may know through the mobile 570 network infrastructure that it is connected to a trusted PVD, and 571 whatever mechanism was used to validate that connection constitutes 572 the authentication portion of the PVD trust relationship. 573 Presumably such a handset would be configured from the factory, or 574 else through mobile operator or user preference settings, to trust 575 the PVD, and this would constitute the authorization portion of this 576 type of trust relationship. 578 7. Acknowledgements 580 8. IANA Considerations 582 This memo includes no request to IANA. 584 9. Security Considerations 586 All drafts are required to have a security considerations section. 588 10. References 590 10.1. Normative References 592 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 593 Requirement Levels", BCP 14, RFC 2119, March 1997. 595 10.2. Informative References 597 [I-D.ietf-6man-addr-select-opt] 598 Matsumoto, A., Fujisaki, T. and T. Chown, "Distributing 599 Address Selection Policy using DHCPv6", Internet-Draft 600 draft-ietf-6man-addr-select-opt-10, April 2013. 602 [RFC4861] Narten, T., Nordmark, E., Simpson, W. and H. Soliman, 603 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 604 September 2007. 606 [RFC6182] Ford, A., Raiciu, C., Handley, M., Barre, S. and J. 607 Iyengar, "Architectural Guidelines for Multipath TCP 608 Development", RFC 6182, March 2011. 610 [RFC6418] Blanchet, M. and P. Seite, "Multiple Interfaces and 611 Provisioning Domains Problem Statement", RFC 6418, 612 November 2011. 614 [RFC6419] Wasserman, M. and P. Seite, "Current Practices for 615 Multiple-Interface Hosts", RFC 6419, November 2011. 617 [RFC6724] Thaler, D., Draves, R., Matsumoto, A. and T. Chown, 618 "Default Address Selection for Internet Protocol Version 6 619 (IPv6)", RFC 6724, September 2012. 621 [RFC6731] Savolainen, T., Kato, J. and T. Lemon, "Improved Recursive 622 DNS Server Selection for Multi-Interfaced Nodes", RFC 623 6731, December 2012. 625 Author's Address 627 Dmitry Anipko 628 Microsoft Corporation 629 One Microsoft Way 630 Redmond, WA 98052 631 USA 633 Phone: +1 425 703 7070 634 Email: dmitry.anipko@microsoft.com