| < draft-ietf-mif-mpvd-arch-10.txt | draft-ietf-mif-mpvd-arch-11.txt > | |||
|---|---|---|---|---|
| MIF Working Group D. Anipko, Ed. | MIF Working Group D. Anipko, Ed. | |||
| Internet-Draft Unaffiliated | Internet-Draft Unaffiliated | |||
| Intended status: Informational February 09, 2015 | Intended status: Informational March 17, 2015 | |||
| Expires: August 11, 2015 | Expires: September 16, 2015 | |||
| Multiple Provisioning Domain Architecture | Multiple Provisioning Domain Architecture | |||
| draft-ietf-mif-mpvd-arch-10 | draft-ietf-mif-mpvd-arch-11 | |||
| Abstract | Abstract | |||
| This document is a product of the work of the MIF Architecture Design | This document is a product of the work of the Multiple Interfaces | |||
| team. It outlines a solution framework for some of the issues | Architecture Design team. It outlines a solution framework for some | |||
| experienced by nodes that can be attached to multiple networks | of the issues experienced by nodes that can be attached to multiple | |||
| simultaneously. The framework defines the concept of a Provisioning | networks simultaneously. The framework defines the concept of a | |||
| Domain (PvD) which is a a consistent set of network configuration | Provisioning Domain (PvD) which is a a consistent set of network | |||
| information. PvD aware nodes learn PvD specific information from the | configuration information. PvD aware nodes learn PvD specific | |||
| networks they are attached to and / or other sources. PvDs are used | information from the networks they are attached to and / or other | |||
| to enable separation and configuration consistency in presence of | sources. PvDs are used to enable separation and configuration | |||
| multiple concurrent connections. | consistency in presence of multiple concurrent connections. | |||
| Status of this Memo | Status of this Memo | |||
| This Internet-Draft is submitted in full conformance with the | This Internet-Draft is submitted in full conformance with the | |||
| provisions of BCP 78 and BCP 79. | provisions of BCP 78 and BCP 79. | |||
| Internet-Drafts are working documents of the Internet Engineering | Internet-Drafts are working documents of the Internet Engineering | |||
| Task Force (IETF). Note that other groups may also distribute | Task Force (IETF). Note that other groups may also distribute | |||
| working documents as Internet-Drafts. The list of current Internet- | working documents as Internet-Drafts. The list of current Internet- | |||
| Drafts is at http://datatracker.ietf.org/drafts/current/. | Drafts is at http://datatracker.ietf.org/drafts/current/. | |||
| Internet-Drafts are draft documents valid for a maximum of six months | Internet-Drafts are draft documents valid for a maximum of six months | |||
| and may be updated, replaced, or obsoleted by other documents at any | and may be updated, replaced, or obsoleted by other documents at any | |||
| time. It is inappropriate to use Internet-Drafts as reference | time. It is inappropriate to use Internet-Drafts as reference | |||
| material or to cite them other than as "work in progress." | material or to cite them other than as "work in progress." | |||
| This Internet-Draft will expire on August 11, 2015. | This Internet-Draft will expire on September 16, 2015. | |||
| Copyright Notice | Copyright Notice | |||
| Copyright (c) 2015 IETF Trust and the persons identified as the | Copyright (c) 2015 IETF Trust and the persons identified as the | |||
| document authors. All rights reserved. | document authors. All rights reserved. | |||
| This document is subject to BCP 78 and the IETF Trust's Legal | This document is subject to BCP 78 and the IETF Trust's Legal | |||
| Provisions Relating to IETF Documents (http://trustee.ietf.org/ | Provisions Relating to IETF Documents (http://trustee.ietf.org/ | |||
| license-info) in effect on the date of publication of this document. | license-info) in effect on the date of publication of this document. | |||
| Please review these documents carefully, as they describe your rights | Please review these documents carefully, as they describe your rights | |||
| skipping to change at page 2, line 8 ¶ | skipping to change at page 2, line 4 ¶ | |||
| This document is subject to BCP 78 and the IETF Trust's Legal | This document is subject to BCP 78 and the IETF Trust's Legal | |||
| Provisions Relating to IETF Documents (http://trustee.ietf.org/ | Provisions Relating to IETF Documents (http://trustee.ietf.org/ | |||
| license-info) in effect on the date of publication of this document. | license-info) in effect on the date of publication of this document. | |||
| Please review these documents carefully, as they describe your rights | Please review these documents carefully, as they describe your rights | |||
| and restrictions with respect to this document. Code Components | and restrictions with respect to this document. Code Components | |||
| extracted from this document must include Simplified BSD License text | extracted from this document must include Simplified BSD License text | |||
| as described in Section 4.e of the Trust Legal Provisions and are | as described in Section 4.e of the Trust Legal Provisions and are | |||
| provided without warranty as described in the Simplified BSD License. | provided without warranty as described in the Simplified BSD License. | |||
| Table of Contents | Table of Contents | |||
| 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 | 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 | |||
| 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 | 2. Definitions and Types of PvDs . . . . . . . . . . . . . . . . 3 | |||
| 2. Definitions and Types of PvDs . . . . . . . . . . . . . . . . 4 | ||||
| 2.1. Explicit PvDs . . . . . . . . . . . . . . . . . . . . . . 4 | 2.1. Explicit PvDs . . . . . . . . . . . . . . . . . . . . . . 4 | |||
| 2.2. Implicit PvDs and Incremental Adoption of Explicit PvDs . 5 | 2.2. Implicit PvDs and Incremental Adoption of Explicit PvDs . 5 | |||
| 2.3. Relationship Between PvDs and Interfaces . . . . . . . . . 6 | 2.3. Relationship Between PvDs and Interfaces . . . . . . . . . 5 | |||
| 2.4. PvD Identity / Naming . . . . . . . . . . . . . . . . . . 6 | 2.4. PvD Identity / Naming . . . . . . . . . . . . . . . . . . 6 | |||
| 2.5. The Relationship to Dual-Stack Networks . . . . . . . . . 7 | 2.5. The Relationship to Dual-Stack Networks . . . . . . . . . 7 | |||
| 3. Conveying PvD information using DHCPv6 and Router Advertisement 8 | 3. Conveying PvD information . . . . . . . . . . . . . . . . . . 7 | |||
| 3.1. Separate Messages or One Message? . . . . . . . . . . . . 8 | 3.1. Separate Messages or One Message? . . . . . . . . . . . . 8 | |||
| 3.2. Securing PvD Information . . . . . . . . . . . . . . . . . 8 | 3.2. Securing PvD Information . . . . . . . . . . . . . . . . . 8 | |||
| 3.3. Backward Compatibility . . . . . . . . . . . . . . . . . . 8 | 3.3. Backward Compatibility . . . . . . . . . . . . . . . . . . 8 | |||
| 3.4. Retracting / Updating PvD Information . . . . . . . . . . 8 | 3.4. Retracting / Updating PvD Information . . . . . . . . . . 8 | |||
| 3.5. Conveying Configuration Information using IKEv2 . . . . . 9 | 3.5. Conveying Configuration Information using IKEv2 . . . . . 9 | |||
| 4. Example Network Configurations . . . . . . . . . . . . . . . . 9 | 4. Example Network Configurations . . . . . . . . . . . . . . . . 9 | |||
| 4.1. A Mobile Node . . . . . . . . . . . . . . . . . . . . . . 9 | 4.1. A Mobile Node . . . . . . . . . . . . . . . . . . . . . . 9 | |||
| 4.2. A Node with a VPN Connection . . . . . . . . . . . . . . . 10 | 4.2. A Node with a VPN Connection . . . . . . . . . . . . . . . 10 | |||
| 4.3. A Home Network and a Network Operator with Multiple PvDs . 11 | 4.3. A Home Network and a Network Operator with Multiple PvDs . 11 | |||
| 5. Reference Model for the PvD-aware Node . . . . . . . . . . . . 11 | 5. Reference Model for the PvD-aware Node . . . . . . . . . . . . 12 | |||
| 5.1. Constructions and Maintenance of Separate PvDs . . . . . . 12 | 5.1. Constructions and Maintenance of Separate PvDs . . . . . . 12 | |||
| 5.2. Consistent use of PvDs for Network Connections . . . . . . 12 | 5.2. Consistent use of PvDs for Network Connections . . . . . . 12 | |||
| 5.2.1. Name Resolution . . . . . . . . . . . . . . . . . . . 12 | 5.2.1. Name Resolution . . . . . . . . . . . . . . . . . . . 13 | |||
| 5.2.2. Next-hop and Source Address Selection . . . . . . . . 13 | 5.2.2. Next-hop and Source Address Selection . . . . . . . . 14 | |||
| 5.2.3. Listening Applications . . . . . . . . . . . . . . . . 14 | 5.2.3. Listening Applications . . . . . . . . . . . . . . . . 14 | |||
| 5.2.3.1. Processing of Incoming Traffic . . . . . . . . . . 14 | 5.2.3.1. Processing of Incoming Traffic . . . . . . . . . . 15 | |||
| 5.2.3.1.1. Connection-oriented APIs . . . . . . . . . . . 15 | 5.2.3.1.1. Connection-oriented APIs . . . . . . . . . . . 15 | |||
| 5.2.3.1.2. Connectionless APIs . . . . . . . . . . . . . 15 | 5.2.3.1.2. Connectionless APIs . . . . . . . . . . . . . 15 | |||
| 5.2.4. Enforcement of Security Policies . . . . . . . . . . . 15 | 5.2.4. Enforcement of Security Policies . . . . . . . . . . . 15 | |||
| 5.3. Connectivity Tests . . . . . . . . . . . . . . . . . . . . 15 | 5.3. Connectivity Tests . . . . . . . . . . . . . . . . . . . . 16 | |||
| 5.4. Relationship to Interface Management and Connection Manage 16 | 5.4. Relationship to Interface Management and Connection Manage 16 | |||
| 6. PvD support in APIs . . . . . . . . . . . . . . . . . . . . . 16 | 6. PvD support in APIs . . . . . . . . . . . . . . . . . . . . . 17 | |||
| 6.1. Basic . . . . . . . . . . . . . . . . . . . . . . . . . . 17 | 6.1. Basic . . . . . . . . . . . . . . . . . . . . . . . . . . 17 | |||
| 6.2. Intermediate . . . . . . . . . . . . . . . . . . . . . . . 17 | 6.2. Intermediate . . . . . . . . . . . . . . . . . . . . . . . 17 | |||
| 6.3. Advanced . . . . . . . . . . . . . . . . . . . . . . . . . 17 | 6.3. Advanced . . . . . . . . . . . . . . . . . . . . . . . . . 18 | |||
| 7. PvD Trust for PvD-Aware Node . . . . . . . . . . . . . . . . . 17 | 7. PvD Trust for PvD-Aware Node . . . . . . . . . . . . . . . . . 18 | |||
| 7.1. Untrusted PvDs . . . . . . . . . . . . . . . . . . . . . . 17 | 7.1. Untrusted PvDs . . . . . . . . . . . . . . . . . . . . . . 18 | |||
| 7.2. Trusted PvDs . . . . . . . . . . . . . . . . . . . . . . . 18 | 7.2. Trusted PvDs . . . . . . . . . . . . . . . . . . . . . . . 18 | |||
| 7.2.1. Authenticated PvDs . . . . . . . . . . . . . . . . . . 18 | 7.2.1. Authenticated PvDs . . . . . . . . . . . . . . . . . . 19 | |||
| 7.2.2. PvDs Trusted by Attachment . . . . . . . . . . . . . . 18 | 7.2.2. PvDs Trusted by Attachment . . . . . . . . . . . . . . 19 | |||
| 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 19 | 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 19 | |||
| 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 19 | 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 19 | |||
| 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 | 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 | |||
| 11. Security Considerations . . . . . . . . . . . . . . . . . . . 19 | 11. Security Considerations . . . . . . . . . . . . . . . . . . . 20 | |||
| 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 | 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21 | |||
| 12.1. Normative References . . . . . . . . . . . . . . . . . . 20 | ||||
| 12.2. Informative References . . . . . . . . . . . . . . . . . 20 | ||||
| Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 22 | Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 22 | |||
| 1. Introduction | 1. Introduction | |||
| Nodes attached to multiple networks may encounter problems from | Nodes attached to multiple networks may encounter problems from | |||
| conflicting configuration between the networks, or attempts to | conflicting configuration between the networks, or attempts to | |||
| simultaneously use more than one network. While various techniques | simultaneously use more than one network. While various techniques | |||
| are currently used to tackle these problems ([RFC6419]), in many | are currently used to tackle these problems ([RFC6419]), in many | |||
| cases issues may still appear. The MIF problem statement document | cases issues may still appear. The Multiple Interfaces problem | |||
| [RFC6418] describes the general landscape and discusses many of the | statement document [RFC6418] describes the general landscape and | |||
| specific issues and scenario details. | discusses many of the specific issues and scenario details. | |||
| Problems, enumerated in [RFC6418], can be grouped into 3 categories: | Problems, enumerated in [RFC6418], can be grouped into 3 categories: | |||
| 1. Lack of consistent and distinctive management of configuration | 1. Lack of consistent and distinctive management of configuration | |||
| elements associated with different networks. | elements associated with different networks. | |||
| 2. Inappropriate mixed use of configuration elements associated with | 2. Inappropriate mixed use of configuration elements associated with | |||
| different networks during a particular network activity or | different networks during a particular network activity or | |||
| connection. | connection. | |||
| skipping to change at page 3, line 49 ¶ | skipping to change at page 3, line 42 ¶ | |||
| associations between acquired network configuration information | associations between acquired network configuration information | |||
| elements. | elements. | |||
| 2. Introducing a reference model for PvD-aware nodes that prevents | 2. Introducing a reference model for PvD-aware nodes that prevents | |||
| the inadvertent mixed use of configuration information which may | the inadvertent mixed use of configuration information which may | |||
| belong to different PvDs. | belong to different PvDs. | |||
| 3. Providing recommendations on PvD selection based on PvD identity | 3. Providing recommendations on PvD selection based on PvD identity | |||
| and connectivity tests for common scenarios. | and connectivity tests for common scenarios. | |||
| 1.1. Requirements Language | ||||
| The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | ||||
| "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this | ||||
| document are to be interpreted as described in RFC 2119 [RFC2119]. | ||||
| 2. Definitions and Types of PvDs | 2. Definitions and Types of PvDs | |||
| Provisioning Domain: | Provisioning Domain: | |||
| A consistent set of network configuration information. | A consistent set of network configuration information. | |||
| Classically, all of the configuration information available on a | Classically, all of the configuration information available on a | |||
| single interface is provided by a single source (such as a network | single interface is provided by a single source (such as a network | |||
| administrator) and can therefore be treated as a single | administrator) and can therefore be treated as a single | |||
| provisioning domain. In modern IPv6 networks, multihoming can | provisioning domain. In modern IPv6 networks, multihoming can | |||
| result in more than one provisioning domain being present on a | result in more than one provisioning domain being present on a | |||
| single link. In some scenarios, it is also possible for elements | single link. In some scenarios, it is also possible for elements | |||
| skipping to change at page 4, line 38 ¶ | skipping to change at page 4, line 25 ¶ | |||
| * DNS suffixes associated with the network | * DNS suffixes associated with the network | |||
| * Default gateway address | * Default gateway address | |||
| PvD-aware node: | PvD-aware node: | |||
| A node that supports the association of network configuration | A node that supports the association of network configuration | |||
| information into PvDs and the use of these PvDs to serve requests | information into PvDs and the use of these PvDs to serve requests | |||
| for network connections in ways consistent with the | for network connections in ways consistent with the | |||
| recommendations of this architecture. | recommendations of this architecture. | |||
| PvD-aware application: | ||||
| An application, that contains code and / or application-specific | ||||
| configuration information explicitly aware of the notion of PvD | ||||
| and / or specific types of PvD elements or properties. | ||||
| 2.1. Explicit PvDs | 2.1. Explicit PvDs | |||
| A node may receive explicit information from the network and / or | A node may receive explicit information from the network and / or | |||
| other sources conveying the presence of PvDs and the association of | other sources conveying the presence of PvDs and the association of | |||
| particular network information with a particular PvD. PvDs that are | particular network information with a particular PvD. PvDs that are | |||
| constructed based on such information are referred to as "explicit" | constructed based on such information are referred to as "explicit" | |||
| in this document. | in this document. | |||
| Protocol changes or extensions will likely be required to support | Protocol changes or extensions will likely be required to support | |||
| explicit PvDs through IETF-defined mechanisms. As an example, one | explicit PvDs through IETF-defined mechanisms. As an example, one | |||
| could think of one or more DHCP options carrying PvD identity and / | could think of one or more DHCP options carrying PvD identity and / | |||
| or its elements. | or its elements. | |||
| A different approach could be the introduction of a DHCP option which | A different approach could be the introduction of a DHCP option which | |||
| only carries the identity of a PvD. Here, the associations between | only carries the identity of a PvD. Here, the associations between | |||
| network information elements with the identity is implemented by the | network information elements with the identity is implemented by the | |||
| respective protocols, for example with a Router Discovery [RFC4861] | respective protocols, for example with a Router Discovery [RFC4861] | |||
| option associating an address range with a PvD. | option associating an address range with a PvD. Additional discussion | |||
| can be found in Section 3. | ||||
| Another example of a delivery mechanism for PvDs are key exchange or | Another example of a delivery mechanism for PvDs are key exchange or | |||
| tunneling protocols, such as IKEv2 [RFC5996] that allow the | tunneling protocols, such as IKEv2 [RFC5996] that allow the | |||
| transport of host configuration information. | transport of host configuration information. | |||
| Specific, existing or new features of networking protocols that | Specific, existing or new features of networking protocols that | |||
| enable the delivery of PvD identity and association with various | enable the delivery of PvD identity and association with various | |||
| network information elements will be defined in companion design | network information elements will be defined in companion design | |||
| documents. | documents. | |||
| skipping to change at page 6, line 18 ¶ | skipping to change at page 5, line 53 ¶ | |||
| benefits to their users (when compared to non-PvD aware nodes) by | benefits to their users (when compared to non-PvD aware nodes) by | |||
| following the best practices described in Section 5. | following the best practices described in Section 5. | |||
| PvD-aware nodes shall treat network information from different | PvD-aware nodes shall treat network information from different | |||
| interfaces, which is not identified as belonging explicitly to some | interfaces, which is not identified as belonging explicitly to some | |||
| PvD, as belonging to separate PvDs, one per interface. | PvD, as belonging to separate PvDs, one per interface. | |||
| Implicit PvDs can also occur in a mixed mode, i.e., where of multiple | Implicit PvDs can also occur in a mixed mode, i.e., where of multiple | |||
| networks that are available on an attached link, only some advertise | networks that are available on an attached link, only some advertise | |||
| PvD information. In this case, the PvD-aware node shall create | PvD information. In this case, the PvD-aware node shall create | |||
| explicit PvDs from information explicitly labeled as beloinging to | explicit PvDs from information explicitly labeled as belonging to | |||
| PvDs. It shall associate configuration information not labeled with | PvDs. It shall associate configuration information not labeled with | |||
| an explicit PvD with implicit PvD(s) created for that interface. | an explicit PvD with implicit PvD(s) created for that interface. | |||
| 2.3. Relationship Between PvDs and Interfaces | 2.3. Relationship Between PvDs and Interfaces | |||
| By default, implicit PvDs are limited to the network configuration | By default, implicit PvDs are limited to the network configuration | |||
| information received on a single interface and by default one such | information received on a single interface and by default one such | |||
| PvD is formed for each interface. If additional information is | PvD is formed for each interface. If additional information is | |||
| available to the host (through mechanisms out of scope of this | available to the host (through mechanisms out of scope of this | |||
| document), the host may form implicit PvDs with different | document), the host may form implicit PvDs with different | |||
| granularity. For example, PvDs spanning multiple interfaces such a | granularity. For example, PvDs spanning multiple interfaces such a | |||
| home network with a router that has multiple internal interfaces, or | home network with a router that has multiple internal interfaces, or | |||
| multiple PvDs on a single interface such as a network that has | multiple PvDs on a single interface such as a network that has | |||
| multiple uplink connections. | multiple uplink connections. | |||
| In the simplest case, explicit PvDs will be scoped for configuration | In the simplest case, explicit PvDs will be scoped for configuration | |||
| related only to a specific interface. However, there is no | related only to a specific interface. However, there is no | |||
| requirement in this architecture for such a limitation. Explicit | requirement in this architecture for such a limitation. Explicit | |||
| PvDs may include information related to more than one interface if | PvDs may include information related to more than one interface if | |||
| the node learns the presence of the same PvD on those interfaces and | the node learns the presence of the same PvD on those interfaces and | |||
| the authentication of the PvD ID meets the level required by the node | the authentication of the PvD ID meets the level required by the node | |||
| policy (authentication of a PvD ID may be also required in scenarios | policy (authentication of a PvD ID may be also required in scenarios | |||
| involving only one connected interface and / or PvD). | involving only one connected interface and / or PvD; for additional | |||
| discussion of PvD Trust see Section 7). | ||||
| This architecture supports such scenarios. Hence, no hierarchical | This architecture supports such scenarios. Hence, no hierarchical | |||
| relationship exists between interfaces and PvDs: it is possible for | relationship exists between interfaces and PvDs: it is possible for | |||
| multiple PvDs to be simultaneously accessible over one interface, as | multiple PvDs to be simultaneously accessible over one interface, as | |||
| well as a single PvD to be simultaneously accessible over multiple | well as a single PvD to be simultaneously accessible over multiple | |||
| interfaces. | interfaces. | |||
| 2.4. PvD Identity / Naming | 2.4. PvD Identity / Naming | |||
| For explicit PvDs, the PvD ID is a value that is, or has a high | For explicit PvDs, the PvD ID is a value that is, or has a high | |||
| probability of being globally unique, and is received as part of PvD | probability of being globally unique, and is received as part of PvD | |||
| information. It shall be possible to generate a human-readable form | information. It shall be possible to generate a human-readable form | |||
| of the PvD ID to present to the end-user, either based on the PvD ID | of the PvD ID to present to the end-user, either based on the PvD ID | |||
| itself, or using meta-data associated with the ID. For implicit PvDs, | itself, or using meta-data associated with the ID. For implicit PvDs, | |||
| the node assigns a locally generated ID with a high probability of | the node assigns a locally generated ID with a high probability of | |||
| being globally unique to each implicit PvD. | being globally unique to each implicit PvD. | |||
| We say that a PvD ID should be, or should have a high probability of | ||||
| being globally unique. The purpose of this is to make it unlikely | ||||
| that any individual node will ever accidentally see the same PvD name | ||||
| twice if it is not actually referring to the same PvD. Protection | ||||
| against deliberate attacks involving name clashes require that the | ||||
| name be authenticated (see Section 7.2.1). | ||||
| A PvD-aware node may use these IDs to select a PvD with a matching ID | A PvD-aware node may use these IDs to select a PvD with a matching ID | |||
| for special-purpose connection requests in accordance with node | for special-purpose connection requests in accordance with node | |||
| policy, as chosen by advanced applications, or to present a human- | policy, as chosen by advanced applications, or to present a human- | |||
| readable representation of the IDs to the end-user for selection of | readable representation of the IDs to the end-user for selection of | |||
| PvDs. | PvDs. | |||
| A single network provider may operate multiple networks, including | A single network provider may operate multiple networks, including | |||
| networks at different locations. In such cases, the provider may | networks at different locations. In such cases, the provider may | |||
| chose whether to advertise single or multiple PvD identities at all | chose whether to advertise single or multiple PvD identities at all | |||
| or some of those networks as it suits their business needs. This | or some of those networks as it suits their business needs. This | |||
| skipping to change at page 7, line 27 ¶ | skipping to change at page 7, line 23 ¶ | |||
| When multiple nodes are connected to the same link with one or more | When multiple nodes are connected to the same link with one or more | |||
| explicit PvDs available, this architecture assumes that the | explicit PvDs available, this architecture assumes that the | |||
| information about all available PvDs is made available by the | information about all available PvDs is made available by the | |||
| networks to all the connected nodes. At the same time, connected | networks to all the connected nodes. At the same time, connected | |||
| nodes may have different heuristics, policies and / or other | nodes may have different heuristics, policies and / or other | |||
| settings, including their configured sets of trusted PvDs. This may | settings, including their configured sets of trusted PvDs. This may | |||
| lead to different PvDs actually being used by different nodes for | lead to different PvDs actually being used by different nodes for | |||
| their connections. | their connections. | |||
| Possible extensions, whereby networks advertize different sets of | Possible extensions, whereby networks advertise different sets of | |||
| PvDs to different connected nodes are out of scope of this document. | PvDs to different connected nodes are out of scope of this document. | |||
| 2.5. The Relationship to Dual-Stack Networks | 2.5. The Relationship to Dual-Stack Networks | |||
| When applied to dual-stack networks, the PvD definition allows for | When applied to dual-stack networks, the PvD definition allows for | |||
| multiple PvDs to be created whereby each PvD contains information | multiple PvDs to be created whereby each PvD contains information | |||
| relevant to only one address family, or for a single PvD containing | relevant to only one address family, or for a single PvD containing | |||
| information for multiple address families. This architecture | information for multiple address families. This architecture | |||
| requires that accompanying design documents describing PvD-related | requires that accompanying design documents describing PvD-related | |||
| protocol changes must support PvDs containing information from | protocol changes must support PvDs containing information from | |||
| skipping to change at page 8, line 6 ¶ | skipping to change at page 8, line 5 ¶ | |||
| By default for implicit PvDs, PvD-aware nodes shall include multiple | By default for implicit PvDs, PvD-aware nodes shall include multiple | |||
| IP families into a single implicit PvD created for an interface. At | IP families into a single implicit PvD created for an interface. At | |||
| the time of writing, in dual-stack networks it appears to be common | the time of writing, in dual-stack networks it appears to be common | |||
| practice for the configuration of both address families to be | practice for the configuration of both address families to be | |||
| provided by a single source. | provided by a single source. | |||
| A PvD-aware node that provides an API to use, enumerate and inspect | A PvD-aware node that provides an API to use, enumerate and inspect | |||
| PvDs and / or their properties shall provide the ability to filter | PvDs and / or their properties shall provide the ability to filter | |||
| PvDs and / or their properties by address family. | PvDs and / or their properties by address family. | |||
| 3. Conveying PvD information using DHCPv6 and Router Advertisements | 3. Conveying PvD information | |||
| DHCPv6 and Router Advertisements are the two most common methods of | DHCPv6 and Router Advertisements are the two most common methods of | |||
| configuring hosts. To support the architecture described in this | configuring hosts. To support the architecture described in this | |||
| document, these protocols would need to be extended to convey | document, these protocols would need to be extended to convey | |||
| explicit PvD information. The following sections describe topic | explicit PvD information. The following sections describe topic | |||
| which must be considered before finalizing a mechanism to augment | which must be considered before finalizing a mechanism to augment | |||
| DHCPv6 and RAs with PvD information. | DHCPv6 and RAs with PvD information. | |||
| 3.1. Separate Messages or One Message? | 3.1. Separate Messages or One Message? | |||
| skipping to change at page 8, line 29 ¶ | skipping to change at page 8, line 28 ¶ | |||
| this information: One way is to send information from each different | this information: One way is to send information from each different | |||
| provisioning domain in separate messages. The second method is | provisioning domain in separate messages. The second method is | |||
| combining the information from multiple PvDs into a single message. | combining the information from multiple PvDs into a single message. | |||
| The latter method has the advantage of being more efficient but could | The latter method has the advantage of being more efficient but could | |||
| have problems with to authentication and authorization, as well as | have problems with to authentication and authorization, as well as | |||
| potential issues with accommodating information not tagged with any | potential issues with accommodating information not tagged with any | |||
| PvD information. | PvD information. | |||
| 3.2. Securing PvD Information | 3.2. Securing PvD Information | |||
| DHCPv6 and RAs both provide some form of authentication to ensure the | DHCPv6 [RFC3315] and RAs [RFC3971] both provide some form of | |||
| identity of the source as well as the integrity of the secured | authentication to ensure the identity of the source as well as the | |||
| message content. While this is useful, determining authenticity does | integrity of the secured message content. While this is useful, | |||
| not tell a node whether the configuration source is actually allowed | determining authenticity does not tell a node whether the | |||
| to provide information from a given PvD. To resolve this, there must | configuration source is actually allowed to provide information from | |||
| be a mechanism for the PvD owner to attach some form of authorization | a given PvD. To resolve this, there must be a mechanism for the PvD | |||
| token or signature to the configuration information that is | owner to attach some form of authorization token or signature to the | |||
| delivered. | configuration information that is delivered. | |||
| 3.3. Backward Compatibility | 3.3. Backward Compatibility | |||
| The extensions to RAs and DHCPv6 should be defined in such a manner | The extensions to RAs and DHCPv6 should be defined in such a manner | |||
| than unmodified hosts (i.e. hosts not aware of PvDs) will continue | than unmodified hosts (i.e., hosts not aware of PvDs) will continue | |||
| to function as well as they did prior to PvD information being added. | to function as well as they did prior to PvD information being added. | |||
| This could imply that some information may need to be duplicated in | This could imply that some information may need to be duplicated in | |||
| order to be conveyed to legacy hosts. Similarly, PvD aware hosts | order to be conveyed to legacy hosts. Similarly, PvD aware hosts | |||
| need to be able to correctly utiilize legacy configuration sources | need to be able to correctly utilize legacy configuration sources | |||
| which do not provide PvD information. There are also several | which do not provide PvD information. There are also several | |||
| initiatives that are aimed at adding some form of additional | initiatives that are aimed at adding some form of additional | |||
| information to prefixes [I-D.bhandari-dhc-class-based-prefix] and | information to prefixes [I-D.bhandari-dhc-class-based-prefix] and | |||
| [I-D.korhonen-dmm-prefix-properties] and any new mechanism should try | [I-D.korhonen-dmm-prefix-properties] and any new mechanism should try | |||
| to consider co-existence with such deployed mechanisms. | to consider co-existence with such deployed mechanisms. | |||
| 3.4. Retracting / Updating PvD Information | 3.4. Retracting / Updating PvD Information | |||
| After PvD information is provisioned to a host, it may become | After PvD information is provisioned to a host, it may become | |||
| outdated or superseded by updated information before the hosts would | outdated or superseded by updated information before the hosts would | |||
| normally request updates. To resolve this requires that the | normally request updates. To resolve this requires that the | |||
| skipping to change at page 10, line 6 ¶ | skipping to change at page 10, line 6 ¶ | |||
| PvD aware mobile node will treat the mobile network as an explicit | PvD aware mobile node will treat the mobile network as an explicit | |||
| PvD. Conversely, the legacy Wi-Fi network may not explicitly | PvD. Conversely, the legacy Wi-Fi network may not explicitly | |||
| communicate PvD information to the mobile node. The PvD aware mobile | communicate PvD information to the mobile node. The PvD aware mobile | |||
| node will associate network configuration for the Wi-Fi network with | node will associate network configuration for the Wi-Fi network with | |||
| an implicit PvD in this case. | an implicit PvD in this case. | |||
| The following diagram illustrates the use of different PvDs in this | The following diagram illustrates the use of different PvDs in this | |||
| scenario: | scenario: | |||
| <----------- Wi-Fi 'Internet' PvD -------> | <----------- Wi-Fi 'Internet' PvD -------> | |||
| +--------+ | +---------+ | |||
| | +----+ | +----+ _ __ _ _ | | +-----+ | +-----+ _ __ _ _ | |||
| | |WiFi| | | | ( ` ) ( ` )_ | | |Wi-Fi| | | | ( ` ) ( ` )_ | |||
| | |-IF +-|----+ |--------------------------( `) | | |-IF + |----+ |---------------------------( `) | |||
| | | | | |WiFi| ( ) (_ Internet _) | | | | | |Wi-Fi| ( ) ( Internet ) | |||
| | +----+ | | AP | ( ) `- __ _) - | | +-----+ | | AP | ( ) ( ) | |||
| | | | | ( Service ) | | | | | ( Service ) ( ) | |||
| | | +----+ ( Provider's ) | | | +-----+ ( Provider's ) ( ) | |||
| | | ( Networks - | | | ( Networks - ( ) | |||
| | +----+ | `_ ) _ _ | | +----+ | `_ ) ( ) | |||
| | |CELL| | ( ) ( ` )_ | | |CELL| | ( ) ( ) | |||
| | |-IF +-|-------------------------------------( `) | | |-IF +--|-------------------------------------( ) | |||
| | | | | (_ __) (_ Internet _) | | | | | (_ __) (_ _) | |||
| | +----+ | `- -- `- __ _) - | | +----+ | `- -- `- __ _) - | |||
| +--------+ | +---------+ | |||
| <------- Mobile 'Internet' PvD -----------> | <------- Mobile 'Internet' PvD -----------> | |||
| An example of PvD use with Wi-Fi and mobile interfaces. | An example of PvD use with Wi-Fi and mobile interfaces. | |||
| 4.2. A Node with a VPN Connection | 4.2. A Node with a VPN Connection | |||
| If the node has established a VPN connection, zero or more (typically | If the node has established a VPN connection, zero or more (typically | |||
| one) additional PvD(s) will be created. These may be implicit or | one) additional PvD(s) will be created. These may be implicit or | |||
| explicit. The routing to IP addresses reachable within this PvD will | explicit. The routing to IP addresses reachable within this PvD will | |||
| be set up via the VPN connection, and the routing of packets to | be set up via the VPN connection, and the routing of packets to | |||
| skipping to change at page 12, line 29 ¶ | skipping to change at page 12, line 37 ¶ | |||
| o Construction of a PvD in its entirety (analogous to statically | o Construction of a PvD in its entirety (analogous to statically | |||
| configuring IP on an interface) | configuring IP on an interface) | |||
| o Supplementing some, or all learned PvDs with particular | o Supplementing some, or all learned PvDs with particular | |||
| configuration elements | configuration elements | |||
| o Merging of information from different PvDs (if this is explicitly | o Merging of information from different PvDs (if this is explicitly | |||
| allowed by policy) | allowed by policy) | |||
| As an example, a node administrator could inject a DNS server which | As an example, a node administrator could configure the node to use a | |||
| is not ISP-specific into PvDs for use on any of the networks that the | specific DNS resolver on a particular interface, or for a particular | |||
| node could attach to. Such creation / augmentation of PvD(s) could | named PvD. In the case of a per-interface DNS resolver, this might | |||
| be static or dynamic. The specific mechanism(s) for implementing | override or augment the DNS resolver configuration for PvDs that are | |||
| this are outside of scope of this document. | discovered on that interface. Such creation/augmentation of PvD(s) | |||
| could be static or dynamic. The specific mechanism(s) for | ||||
| implementing this are outside of scope of this document. Such a | ||||
| merging or overriding of DNS resolver configuration might be contrary | ||||
| to the policy that applies to a special-purpose connection, such as | ||||
| for example those discussed in Section 5.2.1 and Section 5.2.4. In | ||||
| such cases, either the special-purpose connection should not be used, | ||||
| or the merging/overriding should not be performed. | ||||
| 5.2. Consistent use of PvDs for Network Connections | 5.2. Consistent use of PvDs for Network Connections | |||
| PvDs enable PvD-aware nodes to consistently use the correct set of | PvDs enable PvD-aware nodes to consistently use the correct set of | |||
| configuration elements to serve specific network requests from | configuration elements to serve specific network requests from | |||
| beginning to end. This section provides examples of such use. | beginning to end. This section provides examples of such use. | |||
| 5.2.1. Name Resolution | 5.2.1. Name Resolution | |||
| When a PvD-aware node needs to resolve the name of the destination | When a PvD-aware node needs to resolve the name of the destination | |||
| for use by a connection request, the node could use one, or multiple | for use by a connection request, the node could use one, or multiple | |||
| PvDs for a given name lookup. | PvDs for a given name lookup. | |||
| The node shall chose a single PvD if, for example, the node policy | The node shall chose a single PvD if, for example, the node policy | |||
| required the use of a particular PvD for a specific purpose (e.g. to | required the use of a particular PvD for a specific purpose (e.g., to | |||
| download an MMS message using a specific APN over a cellular | download an MMS message using a specific APN over a cellular | |||
| connection). To make this selection, the node could use a match | connection or to direct traffic of enterprise applications to a VPN | |||
| between the PvD DNS suffix and an FQDN which is being resolved or | connection to the enterprise network). To make this selection, the | |||
| match of PvD ID, as determined by the node policy. | node could use a match between the PvD DNS suffix and an FQDN which | |||
| is being resolved or match of PvD ID, as determined by the node | ||||
| policy. | ||||
| The node may pick multiple PvDs, if for example, the PvDs are for | The node may pick multiple PvDs, if for example, the PvDs are for | |||
| general purpose Internet connectivity, and the node is attempting to | general purpose Internet connectivity, and the node is attempting to | |||
| maximize the probability of connectivity similar to the Happy | maximize the probability of connectivity similar to the Happy | |||
| Eyeballs [RFC6555] approach. In this case, the node could perform | Eyeballs [RFC6555] approach. In this case, the node could perform | |||
| DNS lookups in parallel, or in sequence. Alternatively, the node may | DNS lookups in parallel, or in sequence. Alternatively, the node may | |||
| use only one PvD for the lookup, based on the PvD connectivity | use only one PvD for the lookup, based on the PvD connectivity | |||
| properties, user configuration of preferred Internet PvD, etc. | properties, user configuration of preferred Internet PvD, etc. | |||
| If an application implements an API that provides a way of explicitly | If an application implements an API that provides a way of explicitly | |||
| skipping to change at page 13, line 44 ¶ | skipping to change at page 14, line 13 ¶ | |||
| connections are performed consistently within their corresponding | connections are performed consistently within their corresponding | |||
| PvD(s). | PvD(s). | |||
| 5.2.2. Next-hop and Source Address Selection | 5.2.2. Next-hop and Source Address Selection | |||
| For the purpose of this example, let us assume that the preceding | For the purpose of this example, let us assume that the preceding | |||
| name lookup succeeded in a particular PvD. For each obtained | name lookup succeeded in a particular PvD. For each obtained | |||
| destination address, the node shall perform a next-hop lookup among | destination address, the node shall perform a next-hop lookup among | |||
| routers associated with that PvD. As an example, the node could | routers associated with that PvD. As an example, the node could | |||
| determine such associations via matching the source address prefixes/ | determine such associations via matching the source address prefixes/ | |||
| specific routes advertized by the router against known PvDs, or | specific routes advertised by the router against known PvDs, or | |||
| receiving an explicit PvD affiliation advertized through a new Router | receiving an explicit PvD affiliation advertised through a new Router | |||
| Discovery [RFC4861] option. | Discovery [RFC4861] option. | |||
| For each destination, once the best next-hop is found, the node | For each destination, once the best next-hop is found, the node | |||
| selects the best source address according to rules defined in | selects the best source address according to rules defined in | |||
| [RFC6724], but with the constraint that the source address must | [RFC6724], but with the constraint that the source address must | |||
| belong to a range associated with the used PvD. If needed, the node | belong to a range associated with the used PvD. If needed, the node | |||
| would use prefix policy from the same PvD for selecting the best | would use prefix policy from the same PvD for selecting the best | |||
| source address from multiple candidates. | source address from multiple candidates. | |||
| When destination / source pairs are identified, they are sorted using | When destination / source pairs are identified, they are sorted using | |||
| skipping to change at page 15, line 29 ¶ | skipping to change at page 15, line 40 ¶ | |||
| For APIs/protocols that support multiple IP traffic flows associated | For APIs/protocols that support multiple IP traffic flows associated | |||
| with a single transport API connection object (for example, multi | with a single transport API connection object (for example, multi | |||
| path TCP), the processing rules may be adjusted accordingly. | path TCP), the processing rules may be adjusted accordingly. | |||
| 5.2.3.1.2. Connectionless APIs | 5.2.3.1.2. Connectionless APIs | |||
| For connectionless APIs, the host should provide an API that PvD- | For connectionless APIs, the host should provide an API that PvD- | |||
| aware applications can use to query the PvD associated with the | aware applications can use to query the PvD associated with the | |||
| packet. For outgoing traffic on this transport API object, the OS | packet. For outgoing traffic on this transport API object, the OS | |||
| should use the selected outgoing PvDs, determined as described above. | should use the selected outgoing PvDs, determined as described in | |||
| Section 5.2.1 and Section 5.2.2. | ||||
| 5.2.4. Enforcement of Security Policies | 5.2.4. Enforcement of Security Policies | |||
| By themselves, PvDs do not define, and cannot be used for | By themselves, PvDs do not define, and cannot be used for | |||
| communication of, security policies. When implemented in a network, | communication of, security policies. When implemented in a network, | |||
| this architecture provides the host with information about connected | this architecture provides the host with information about connected | |||
| networks. The actual behavior of the host then depends on the host's | networks. The actual behavior of the host then depends on the host's | |||
| policies (provisioned through mechanisms out of scope of this | policies (provisioned through mechanisms out of scope of this | |||
| document), applied taking received PvD information into account. In | document), applied taking received PvD information into account. In | |||
| some scenarios, e.g. a VPN, such policies could require the host to | some scenarios, e.g., a VPN, such policies could require the host to | |||
| use only a particular VPN PvD for some / all of the application's | use only a particular VPN PvD for some / all of the application's | |||
| traffic (VPN 'disable split tunneling' also known as 'force | traffic (VPN 'disable split tunneling' also known as 'force | |||
| tunneling' behavior), or apply such restrictions only to selected | tunneling' behavior), or apply such restrictions only to selected | |||
| applications and allow the simultaneous use of the VPN PvD together | applications and allow the simultaneous use of the VPN PvD together | |||
| with the other connected PvDs by the other or all applications (VPN | with the other connected PvDs by the other or all applications (VPN | |||
| 'split tunneling' behavior). | 'split tunneling' behavior). | |||
| 5.3. Connectivity Tests | 5.3. Connectivity Tests | |||
| Although some PvDs may appear as valid candidates for PvD selection | Although some PvDs may appear as valid candidates for PvD selection | |||
| (e.g. good link quality, consistent connection parameters, etc.), | (e.g., good link quality, consistent connection parameters, etc.), | |||
| they may provide limited or no connectivity to the desired network or | they may provide limited or no connectivity to the desired network or | |||
| the Internet. For example, some PvDs provide limited IP connectivity | the Internet. For example, some PvDs provide limited IP connectivity | |||
| (e.g., scoped to the link or to the access network), but require the | (e.g., scoped to the link or to the access network), but require the | |||
| node to authenticate through a web portal to get full access to the | node to authenticate through a web portal to get full access to the | |||
| Internet. This may be more likely to happen for PvDs which are not | Internet. This may be more likely to happen for PvDs which are not | |||
| trusted by a given PvD-aware node. | trusted by a given PvD-aware node. | |||
| An attempt to use such a PvD may lead to limited network connectivity | An attempt to use such a PvD may lead to limited network connectivity | |||
| or application connection failures. To prevent the latter, a PvD- | or application connection failures. To prevent the latter, a PvD- | |||
| aware node may perform a connectivity test for the PvD before using | aware node may perform a connectivity test for the PvD before using | |||
| it to serve application network connection requests. In current | it to serve application network connection requests. In current | |||
| implementations, some nodes already implement this e.g., by trying to | implementations, some nodes already implement this e.g., by trying to | |||
| reach a dedicated web server (see [RFC6419]). | reach a dedicated web server (see [RFC6419]). | |||
| Section 5.2 describes how a PvD-aware node shall maintain and use | Section 5.2 describes how a PvD-aware node shall maintain and use | |||
| multiple PvDs separately. The PvD-aware node shall perform a | multiple PvDs separately. The PvD-aware node shall perform a | |||
| connectivity test and, only after validation of the PvD, consider | connectivity test and, only after validation of the PvD, consider | |||
| using it to serve application connections requests. Ongoing | using it to serve application connections requests. Ongoing | |||
| connectivity tests are also required, since during the IP session, | connectivity tests are also required, since during the IP session, | |||
| the end-to-end connectivity could be disrupted for various reasons | the end-to-end connectivity could be disrupted for various reasons | |||
| (e.g. L2 problems, IP QoS issues); hence, a connectivity monitoring | (e.g., L2 problems, IP QoS issues); hence, a connectivity monitoring | |||
| function is needed to check the connectivity status and remove the | function is needed to check the connectivity status and remove the | |||
| PvD from the set of usable PvDs if necessary. | PvD from the set of usable PvDs if necessary. | |||
| There may be cases where a connectivity test for PvD selection may | There may be cases where a connectivity test for PvD selection may | |||
| not be appropriate and should be complemented, or replaced, by PvD | not be appropriate and should be complemented, or replaced, by PvD | |||
| selection based on other factors. For example, this could be | selection based on other factors. For example, this could be | |||
| realized by leveraging some 3GPP and IEEE mechanisms, which would | realized by leveraging some 3GPP and IEEE mechanisms, which would | |||
| allow the exposure of some PvD characteristics to the node (e.g. | allow the exposure of some PvD characteristics to the node (e.g., | |||
| 3GPP Access Network Discovery and Selection Function (ANDSF) | 3GPP Access Network Discovery and Selection Function (ANDSF) | |||
| [TS23402], IEEE 802.11u [IEEE802.11u]/ANQP). | [TS23402], IEEE 802.11u [IEEE802.11u]/ANQP). | |||
| 5.4. Relationship to Interface Management and Connection Managers | 5.4. Relationship to Interface Management and Connection Managers | |||
| Current devices, such as mobile handsets make use of proprietary | Current devices, such as mobile handsets make use of proprietary | |||
| mechanisms and custom applications to manage connectivity in | mechanisms and custom applications to manage connectivity in | |||
| environments with multiple interfaces and multiple sets of network | environments with multiple interfaces and multiple sets of network | |||
| configuration. These mechanisms or applications are commonly known | configuration. These mechanisms or applications are commonly known | |||
| as connection managers [RFC6419]. | as connection managers [RFC6419]. | |||
| Connection managers sometimes rely on policy servers to allow a node | Connection managers sometimes rely on policy servers to allow a node | |||
| that is connected to multiple networks to perform network selection. | that is connected to multiple networks to perform network selection. | |||
| They can also make use of routing guidance from the network (e.g. | They can also make use of routing guidance from the network (e.g., | |||
| 3GPP ANDSF [TS23402]). Although connection managers solve some | 3GPP ANDSF [TS23402]). Although connection managers solve some | |||
| connectivity problems, they rarely address network selection problems | connectivity problems, they rarely address network selection problems | |||
| in a comprehensive manner. With proprietary solutions, it is | in a comprehensive manner. With proprietary solutions, it is | |||
| challenging to present coherent behavior to the end user of the | challenging to present coherent behavior to the end user of the | |||
| device, as different platforms present different behaviors even when | device, as different platforms present different behaviors even when | |||
| connected to the same network, with the same type of interface, and | connected to the same network, with the same type of interface, and | |||
| for the same purpose. The architecture described in this document | for the same purpose. The architecture described in this document | |||
| should improve the hosts behavior by providing the hosts with tools | should improve the hosts behavior by providing the hosts with tools | |||
| and guidance to make informed network selection decisions. | and guidance to make informed network selection decisions. | |||
| skipping to change at page 18, line 9 ¶ | skipping to change at page 18, line 27 ¶ | |||
| 7.1. Untrusted PvDs | 7.1. Untrusted PvDs | |||
| Implicit and explicit PvDs for which no trust relationship exists are | Implicit and explicit PvDs for which no trust relationship exists are | |||
| considered untrusted. Only PvDs which meet the requirements in | considered untrusted. Only PvDs which meet the requirements in | |||
| Section 7.2 are trusted; any other PvD is untrusted. | Section 7.2 are trusted; any other PvD is untrusted. | |||
| In order to avoid the various forms of misinformation that could | In order to avoid the various forms of misinformation that could | |||
| occur when PvDs are untrusted, nodes that implement PvD separation | occur when PvDs are untrusted, nodes that implement PvD separation | |||
| cannot assume that two explicit PvDs with the same identifier are | cannot assume that two explicit PvDs with the same identifier are | |||
| actually the same PvD. A node that makes this assumption will be | actually the same PvD. A node that makes this assumption will be | |||
| vulnerable to attacks where, for example, an open Wifi hotspot might | vulnerable to attacks where, for example, an open Wi-Fi hotspot might | |||
| assert that it was part of another PvD and thereby attempt to draw | assert that it was part of another PvD and thereby attempt to draw | |||
| traffic intended for that PvD onto its own network. | traffic intended for that PvD onto its own network. | |||
| Since implicit PvD identifiers are synthesized by the node, this | Since implicit PvD identifiers are synthesized by the node, this | |||
| issue cannot arise with implicit PvDs. | issue cannot arise with implicit PvDs. | |||
| Mechanisms exist (for example, [RFC6731]) whereby a PvD can provide | Mechanisms exist (for example, [RFC6731]) whereby a PvD can provide | |||
| configuration information that asserts special knowledge about the | configuration information that asserts special knowledge about the | |||
| reachability of resources through that PvD. Such assertions cannot be | reachability of resources through that PvD. Such assertions cannot be | |||
| validated unless the node has a trust relationship with the PvD; | validated unless the node has a trust relationship with the PvD; | |||
| skipping to change at page 19, line 33 ¶ | skipping to change at page 20, line 4 ¶ | |||
| (denghui@chinamobile.com), Jouni Korhonen (jouni.nospam@gmail.com), | (denghui@chinamobile.com), Jouni Korhonen (jouni.nospam@gmail.com), | |||
| Juan Carlos Zuniga (JuanCarlos.Zuniga@InterDigital.com), Konstantinos | Juan Carlos Zuniga (JuanCarlos.Zuniga@InterDigital.com), Konstantinos | |||
| Pentikousis (k.pentikousis@huawei.com), Marc Blanchet | Pentikousis (k.pentikousis@huawei.com), Marc Blanchet | |||
| (marc.blanchet@viagenie.ca), Margaret Wasserman | (marc.blanchet@viagenie.ca), Margaret Wasserman | |||
| (margaretw42@gmail.com), Pierrick Seite (pierrick.seite@orange.com), | (margaretw42@gmail.com), Pierrick Seite (pierrick.seite@orange.com), | |||
| Suresh Krishnan (suresh.krishnan@ericsson.com), Teemu Savolainen | Suresh Krishnan (suresh.krishnan@ericsson.com), Teemu Savolainen | |||
| (teemu.savolainen@nokia.com), Ted Lemon (ted.lemon@nominum.com) and | (teemu.savolainen@nokia.com), Ted Lemon (ted.lemon@nominum.com) and | |||
| Tim Chown (tjc@ecs.soton.ac.uk). | Tim Chown (tjc@ecs.soton.ac.uk). | |||
| 9. Acknowledgments | 9. Acknowledgments | |||
| The authors would like to thank (in no specific order) Ian Farrer, | The authors would like to thank (in no specific order) Ian Farrer, | |||
| Markus Stenberg and Mikael Abrahamsson for their review and comments. | Markus Stenberg and Mikael Abrahamsson for their review and comments. | |||
| 10. IANA Considerations | 10. IANA Considerations | |||
| This memo does not include any IANA requests. | This memo does not include any IANA requests. | |||
| 11. Security Considerations | 11. Security Considerations | |||
| There are at least three different forms of attacks that can be | There are at least three different forms of attacks that can be | |||
| performed using configuration sources that support multiple | performed using configuration sources that support multiple | |||
| provisioning domains. | provisioning domains. | |||
| Tampering with provided configuration information: An attacker may | Tampering with provided configuration information: An attacker may | |||
| attempt to modify information provided inside the PvD container | attempt to modify information provided inside the PvD container | |||
| option. These attacks can easily be prevented by using message | option. These attacks can easily be prevented by using message | |||
| integrity features provided by the underlying protocol used to | integrity features provided by the underlying protocol used to | |||
| carry the configuration information. E.g. SEND [RFC3971] would | carry the configuration information. E.g., SEND [RFC3971] would | |||
| detect any form of tampering with the RA contents and the DHCPv6 | detect any form of tampering with the RA contents and the DHCPv6 | |||
| [RFC3315] AUTH option that would detect any form of tampering with | [RFC3315] AUTH option that would detect any form of tampering with | |||
| the DHCPv6 message contents. This attack can also be performed by | the DHCPv6 message contents. This attack can also be performed by | |||
| a compromised configuration source by modifying information inside | a compromised configuration source by modifying information inside | |||
| a specific PvD, in which case the mitigations proposed in the next | a specific PvD, in which case the mitigations proposed in the next | |||
| subsection may be helpful. | subsection may be helpful. | |||
| Rogue configuration source: A compromised configuration source, such | Rogue configuration source: A compromised configuration source, such | |||
| as a router or a DHCPv6 server, may advertise information about | as a router or a DHCPv6 server, may advertise information about | |||
| PvDs that it is not authorized to advertise. E.g., a coffee shop | PvDs that it is not authorized to advertise. E.g., a coffee shop | |||
| WLAN may advertise configuration information purporting to be from | WLAN may advertise configuration information purporting to be from | |||
| an enterprise and may try to attract enterprise related traffic. | an enterprise and may try to attract enterprise related traffic. | |||
| This may also occur accidentally if two sites choose the same | This may also occur accidentally if two sites choose the same | |||
| identifier (e.g., "linsky"). | identifier (e.g., "linsky"). | |||
| In order to detect and prevent this, the client must be able to | In order to detect and prevent this, the client must be able to | |||
| authenticate the identifier provided by the network. This means | authenticate the identifier provided by the network. This means | |||
| that the client must have configuration information that maps the | that the client must have configuration information that maps the | |||
| PvD identifier to an authenticatable identity, and must be able to | PvD identifier to an identity, and must be able to authenticate | |||
| authenticate that identity. | that identity. | |||
| In addition, the network must provide information the client can | In addition, the network must provide information the client can | |||
| use to authenticate the identity. This could take the form of a | use to authenticate the identity. This could take the form of a | |||
| PKI-based or DNSSEC-based trust anchor, or a key remembered from a | PKI-based or DNSSEC-based trust anchor, or a key remembered from a | |||
| previous leap-of-faith authentication of the identifier. | previous leap-of-faith authentication of the identifier. | |||
| Because the PvD-specific information may come to the network | Because the PvD-specific information may come to the network | |||
| infrastructure with which the client is actually communicating | infrastructure with which the client is actually communicating | |||
| from some upstream provider, it is necessary in this case that the | from some upstream provider, it is necessary in this case that the | |||
| PvD container and its contents be relayed to the client unchanged, | PvD container and its contents be relayed to the client unchanged, | |||
| skipping to change at page 20, line 51 ¶ | skipping to change at page 21, line 14 ¶ | |||
| Replay attacks: A compromised configuration source or an on-link | Replay attacks: A compromised configuration source or an on-link | |||
| attacker may try to capture advertised configuration information | attacker may try to capture advertised configuration information | |||
| and replay it on a different link, or at a future point in time. | and replay it on a different link, or at a future point in time. | |||
| This can be avoided by including a replay protection mechanism | This can be avoided by including a replay protection mechanism | |||
| such as a timestamp or a nonce inside the PvD container to ensure | such as a timestamp or a nonce inside the PvD container to ensure | |||
| the validity of the provided information. | the validity of the provided information. | |||
| 12. References | 12. References | |||
| 12.1. Normative References | ||||
| [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | ||||
| Requirement Levels", BCP 14, RFC 2119, March 1997. | ||||
| 12.2. Informative References | ||||
| [I-D.bhandari-dhc-class-based-prefix] | [I-D.bhandari-dhc-class-based-prefix] | |||
| Systems, C., Halwasia, G., Gundavelli, S., Deng, H., | Systems, C., Halwasia, G., Gundavelli, S., Deng, H., | |||
| Thiebaut, L., Korhonen, J. and I. Farrer, "DHCPv6 class | Thiebaut, L., Korhonen, J. and I. Farrer, "DHCPv6 class | |||
| based prefix", Internet-Draft draft-bhandari-dhc-class- | based prefix", Internet-Draft draft-bhandari-dhc-class- | |||
| based-prefix-05, July 2013. | based-prefix-05, July 2013. | |||
| [I-D.korhonen-dmm-prefix-properties] | [I-D.korhonen-dmm-prefix-properties] | |||
| Korhonen, J., Patil, B., Gundavelli, S., Seite, P. and D. | Korhonen, J., Patil, B., Gundavelli, S., Seite, P. and D. | |||
| Liu, "IPv6 Prefix Mobility Management Properties", | Liu, "IPv6 Prefix Mobility Management Properties", | |||
| Internet-Draft draft-korhonen-dmm-prefix-properties-03, | Internet-Draft draft-korhonen-dmm-prefix-properties-03, | |||
| End of changes. 46 change blocks. | ||||
| 103 lines changed or deleted | 109 lines changed or added | |||
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ | ||||