From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc6418.txt | 1235 +++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 1235 insertions(+) create mode 100644 doc/rfc/rfc6418.txt (limited to 'doc/rfc/rfc6418.txt') diff --git a/doc/rfc/rfc6418.txt b/doc/rfc/rfc6418.txt new file mode 100644 index 0000000..9dcdf90 --- /dev/null +++ b/doc/rfc/rfc6418.txt @@ -0,0 +1,1235 @@ + + + + + + +Internet Engineering Task Force (IETF) M. Blanchet +Request for Comments: 6418 Viagenie +Category: Informational P. Seite +ISSN: 2070-1721 France Telecom - Orange + November 2011 + + + Multiple Interfaces and Provisioning Domains Problem Statement + +Abstract + + This document describes issues encountered by a node attached to + multiple provisioning domains. This node receives configuration + information from each of its provisioning domains, where some + configuration objects are global to the node and others are local to + the interface. Issues such as selecting the wrong interface to send + traffic happen when conflicting node-scoped configuration objects are + received and inappropriately used. Moreover, other issues are the + result of simultaneous attachment to multiple networks, such as + domain selection or addressing and naming space overlaps, regardless + of the provisioning mechanism. While multiple provisioning domains + are typically seen on nodes with multiple interfaces, this document + also discusses situations involving single-interface nodes. + +Status of This Memo + + This document is not an Internet Standards Track specification; it is + published for informational purposes. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Not all documents + approved by the IESG are a candidate for any level of Internet + Standard; see Section 2 of RFC 5741. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + http://www.rfc-editor.org/info/rfc6418. + + + + + + + + + + + + +Blanchet & Seite Informational [Page 1] + +RFC 6418 Multiple Interfaces Problem Statement November 2011 + + +Copyright Notice + + Copyright (c) 2011 IETF Trust and the persons identified as the + document authors. All rights reserved. + + This document is subject to BCP 78 and the IETF Trust's Legal + Provisions Relating to IETF Documents + (http://trustee.ietf.org/license-info) in effect on the date of + publication of this document. Please review these documents + carefully, as they describe your rights and restrictions with respect + to this document. Code Components extracted from this document must + include Simplified BSD License text as described in Section 4.e of + the Trust Legal Provisions and are provided without warranty as + described in the Simplified BSD License. + +Table of Contents + + 1. Introduction ....................................................3 + 2. Terminology .....................................................4 + 3. Scope and Existing Work .........................................4 + 3.1. Interactions Below IP ......................................4 + 3.2. MIF Node Characterization ..................................5 + 3.3. Host Requirements ..........................................5 + 3.4. Mobility and Other IP Protocols ............................6 + 3.5. Address Selection ..........................................6 + 3.6. Finding and Sharing IP Addresses with Peers ................7 + 3.7. Provisioning Domain Selection ..............................7 + 3.8. Session Management .........................................8 + 3.9. Sockets API ................................................9 + 4. MIF Issues ......................................................9 + 4.1. DNS Resolution Issues ......................................9 + 4.2. Node Routing ..............................................12 + 4.3. Conflicting Policies ......................................13 + 4.4. Session Management ........................................14 + 4.5. Single Interface on Multiple Provisioning Domains .........14 + 5. Underlying Problems and Causes .................................15 + 6. Security Considerations ........................................17 + 7. Contributors ...................................................18 + 8. Acknowledgements ...............................................18 + 9. Informative References .........................................18 + + + + + + + + + + + +Blanchet & Seite Informational [Page 2] + +RFC 6418 Multiple Interfaces Problem Statement November 2011 + + +1. Introduction + + A multihomed node may have multiple provisioning domains (via + physical and/or virtual interfaces). For example, a node may be + simultaneously connected to a wired Ethernet LAN, an 802.11 LAN, a 3G + cell network, one or multiple VPN connections, or one or multiple + tunnels (automatic or manual). Current laptops and smartphones + typically have multiple access network interfaces and, thus, are + often connected to different provisioning domains. + + A multihomed node receives configuration information from each of its + attached networks, through various mechanisms such as DHCPv4 + [RFC2131], DHCPv6 [RFC3315], PPP [RFC1661], and IPv6 Router + Advertisements [RFC4861]. Some received configuration objects are + specific to an interface, such as the IP address and the link prefix. + Others are typically considered by implementations as being global to + the node, such as the routing information (e.g., default gateway), + DNS server IP addresses, and address selection policies, herein + referred to as "node-scoped". + + When the received node-scoped configuration objects have different + values from each provisioning domain, such as different DNS server IP + addresses, different default gateways, or different address selection + policies, the node has to decide which one to use or how it will + merge them. + + Other issues are the result of simultaneous attachment to multiple + networks, such as addressing and naming space overlaps, regardless of + the provisioning mechanism. + + The following sections define the multiple interfaces (MIF) node and + the scope of this work, describe related work, list issues, and then + summarize the underlying problems. + + A companion document, [RFC6419], discusses some current practices of + various implementations dealing with MIF. + + + + + + + + + + + + + + + +Blanchet & Seite Informational [Page 3] + +RFC 6418 Multiple Interfaces Problem Statement November 2011 + + +2. Terminology + + Administrative domain + + A group of hosts, routers, and networks operated and managed by a + single organization [RFC1136]. + + Provisioning domain + + A set of consistent configuration information (e.g., default + router, network prefixes, DNS) and the corresponding interface. + One administrative domain may have multiple provisioning domains. + Successful attachment to the provisioning domain implies that the + terminal attaches to the corresponding interface with appropriate + configuration information. + + Reference to IP version + + When a protocol keyword such as IP, PPP, or DHCP is used in this + document without any reference to a specific IP version, then it + implies both IPv4 and IPv6. A specific IP version keyword such as + DHCPv4 or DHCPv6 is meant to be specific to that IP version. + +3. Scope and Existing Work + + This section describes existing related work and defines the scope of + the problem. + +3.1. Interactions Below IP + + Some types of interfaces have link-layer characteristics that may be + used in determining how multiple provisioning domain issues will be + dealt with. For instance, link layers may have authentication and + encryption characteristics that could be used as criteria for + interface selection. However, network discovery and selection on + lower layers as defined by [RFC5113] is out of scope of this + document. Moreover, interoperability with lower-layer mechanisms + such as services defined in IEEE 802.21, which aims at facilitating + handover between heterogeneous networks [MIH], is also out of scope. + + Some mechanisms (e.g., based on a virtual IP interface) allow sharing + a single IP address over multiple interfaces to networks with + disparate access technologies. From the IP-stack view on the node, + there is only a single interface and single IP address. Therefore, + this situation is out of scope of this problem statement. + Furthermore, link aggregation done under IP where a single interface + is shown to the IP stack is also out of scope. + + + + +Blanchet & Seite Informational [Page 4] + +RFC 6418 Multiple Interfaces Problem Statement November 2011 + + +3.2. MIF Node Characterization + + A MIF node has the following characteristics: + + o A MIF node is an [RFC1122] IPv4- and/or [RFC4294] IPv6-compliant + node. + + o A MIF node is configured with more than one IP address (excluding + loopback and link-local). + + o A MIF node can attach to more than one provisioning domain, as + presented to the IP stack. + + o The interfaces may be virtual or physical. + + o Configuration objects come from one or more administrative + domains. + + o The IP addresses may be from the same or different address + families, such as IPv4 and IPv6. + + o Communications using these IP addresses may happen simultaneously + and independently. + + o Some communications using these IP addresses are possible on all + the provisioning domains, while some are only possible on a + smaller set of the provisioning domains. + + o While the MIF node may forward packets between its interfaces, the + forwarding of packets is not taken into account in this definition + and is out of scope for this document. + +3.3. Host Requirements + + "Requirements for Internet Hosts -- Communication Layers" [RFC1122] + describes the multihomed node as if it has multiple IP addresses, + which may be associated with one or more physical interfaces + connected to the same or different networks. + + Section 3.3.1.3 of [RFC1122] states that the node maintains a route + cache table where each entry contains the local IP address, the + destination IP address, Type(s) of Service (superseded by the + Differentiated Services Code Point [RFC2474]), and the next-hop + gateway IP address. The route cache entry would have data about the + properties of the path, such as the average round-trip delay measured + by a transport protocol. Nowadays, implementations are not caching + this information. + + + + +Blanchet & Seite Informational [Page 5] + +RFC 6418 Multiple Interfaces Problem Statement November 2011 + + + [RFC1122] defines two host models: + + o The "strong" host model defines a multihomed host as a set of + logical hosts within the same physical host. In this model, a + packet must be sent on an interface that corresponds to the source + address of that packet. + + o The "weak" host model describes a host that has some embedded + gateway functionality. In the weak host model, the host can send + and receive packets on any interface. + + The multihomed node computes routes for outgoing datagrams + differently, depending on the model. Under the strong model, the + route is computed based on the source IP address, the destination IP + address, and the Differentiated Services Code Point. Under the weak + model, the source IP address is not used; only the destination IP + address and the Differentiated Services Code Point are used. + +3.4. Mobility and Other IP Protocols + + The scope of this document is only about nodes implementing [RFC1122] + for IPv4 and [RFC4294] for IPv6 without additional features or + special-purpose support for transport layers, mobility, multihoming, + or identifier-locator split mechanisms. Dealing with multiple + interfaces with such mechanisms is related but considered as a + separate problem and is under active study elsewhere in the IETF + [RFC4960] [RFC5206] [RFC5533] [RFC5648] [RFC6182]. + + When an application is using one interface while another interface + with better characteristics becomes available, the ongoing + application session could be transferred to the newly enabled + interface. However, in some cases, the ongoing session shall be kept + on the current interface while initiating the new session on the new + interface. The problem of interface selection is within the MIF + scope and may leverage specific node functions (Section 3.8). + However, if transfer of an IP session is required, IP mobility + mechanisms, such as [RFC6275], shall be used. + +3.5. Address Selection + + "Default Address Selection for Internet Protocol version 6 (IPv6)" + [RFC3484] defines algorithms for source and destination IP address + selections. Default address selection as defined in [RFC3484] is + mandatory to implement in IPv6 nodes, which also means dual-stack + nodes. A node-scoped policy table managed by the IP stack is + defined. Mechanisms to update the policy table are defined in + [ADDR-SELECT-SOL]. + + + + +Blanchet & Seite Informational [Page 6] + +RFC 6418 Multiple Interfaces Problem Statement November 2011 + + + Issues on using default address selection were found in [RFC5220] and + [RFC5221] in the context of multiple prefixes on the same link. + +3.6. Finding and Sharing IP Addresses with Peers + + Interactive Connectivity Establishment (ICE) [RFC5245] is a technique + for NAT traversal for UDP-based (and TCP-based) media streams + established by the offer/answer model. The multiplicity of IP + addresses, ports, and transport mechanisms in Session Description + Protocol (SDP) offers are tested for connectivity by peer-to-peer + connectivity checks. The result is candidate IP addresses and ports + for establishing a connection with the other peer. However, ICE does + not solve issues when incompatible configuration objects are received + on different interfaces. + + Some application protocols do referrals of IP addresses, port + numbers, and transport for further exchanges. For instance, + applications can provide reachability information to themselves or to + a third party. The general problem of referrals is related to the + multiple-interface problem, since, in this context, referrals must + provide consistent information depending on which provisioning domain + is used. Referrals are discussed in [REFERRAL-PS] and + [SHIM6-APP-REFER]. + +3.7. Provisioning Domain Selection + + In a MIF context, the node may simultaneously handle multiple domains + with disparate characteristics, especially when supporting multiple + access technologies. Selection is simple if the application is + restricted to one specific provisioning domain: the application must + start on the default provisioning domain if available; otherwise, the + application does not start. However, if the application can be run + on several provisioning domains, the selection problem can be + difficult. + + There is no standard method for selecting a provisioning domain, but + some recommendations exist while restricting the scope to the + interface selection problem. For example, [TS23.234] proposes a + default mechanism for the interface selection. This method uses the + following information (non-exhaustive list): + + o preferences provided by the user + + o policies provided by the network operator + + o quality of the radio link + + + + + +Blanchet & Seite Informational [Page 7] + +RFC 6418 Multiple Interfaces Problem Statement November 2011 + + + o network resource considerations (e.g., available Quality of + Service (QoS), IP connectivity check) + + o the application QoS requirements in order to map applications to + the best interface + + However, [TS23.234] is designed for a specific multiple-interfaces + use case. A generic way to handle these characteristics is yet to be + defined. + +3.8. Session Management + + Some implementations, especially in the mobile world, rely on a + higher-level session manager, also called a connection manager, to + deal with issues brought by simultaneous attachment to multiple + provisioning domains. Typically, the session manager may deal with + the selection of the interface, and/or the provisioning domain, on + behalf of the applications, or tackle complex issues such as how to + resolve conflicting policies (Section 4.3). As discussed in + Section 3.7, the session manager may encounter difficulties because + of multiple and diverse criteria. + + Session managers usually leverage the link-layer interface to gather + information (e.g., lower-layer authentication and encryption methods; + see Section 3.1) and/or for control purposes. Such a link-layer + interface may not provide all required services to make a proper + decision (e.g., interface selection). Some OSes or terminals already + implement session managers [RFC6419], and vendor-specific platforms + sometimes provide a specific sockets API (Section 3.9) that a session + manager can use. However, the generic architecture of a session + manager and its associated API are not currently standardized, so + session manager behavior may differ between OSes and platforms. + + Management of multiple interfaces sometimes relies on a virtual + interface. For instance, a virtual interface allows support of + multihoming, inter-technology handovers, and IP flow mobility in a + Proxy Mobile IPv6 network [LOGICAL-IF-SUPPORT]. This virtual + interface allows a multiple-interface node sharing a set of IP + addresses on multiple physical interfaces and can also add benefits + to multi-access scenarios such as Third Generation Partnership + Project (3GPP) Multi Access Packet Data Network (PDN) Connectivity + [TS23.402]. In most cases, the virtual interface will map several + physical network interfaces, and the session manager should control + the configuration of each one of these virtual and physical + interfaces, as well as the mapping between the virtual and + sub-interfaces. + + + + + +Blanchet & Seite Informational [Page 8] + +RFC 6418 Multiple Interfaces Problem Statement November 2011 + + + In a situation involving multiple interfaces, active application + sessions should survive path failures. Here, the session manager may + come into play but only relying on existing mechanisms to manage + multipath TCP (MPTCP) [RFC6182] or failover (Mobile IPv6 (MIP6) + [RFC6275], Shim6 [RFC5533]). A description of the interaction + between these mechanisms and the session manager is out of scope of + this document. + +3.9. Sockets API + + An Application Programming Interface (API) may expose objects that + user applications or session managers use for dealing with multiple + interfaces. For example, [RFC3542] defines how an application using + the advanced sockets API specifies the interface or the source IP + address through a simple bind() operation or with the IPV6_PKTINFO + socket option. + + Other APIs have been defined to solve issues similar to MIF. For + instance, [RFC5014] defines an API to influence the default address + selection mechanism by specifying attributes of the source addresses + it prefers. [RFC6316] gives another example, in a multihoming + context, by defining a sockets API enabling interactions between + applications and the multihoming shim layer for advanced locator + management, and access to information about failure detection and + path exploration. + +4. MIF Issues + + This section describes the various issues when using a MIF node that + has already received configuration objects from its various + provisioning domains, or when multiple interfaces are used and result + in wrong domain selection, addressing, or naming space overlaps. + They occur, for example, when: + + 1. one interface is on the Internet and one is on a corporate + private network. The latter may be through VPN. + + 2. one interface is on one access network (i.e., WiFi) and the other + one is on another access network (3G) with specific services. + +4.1. DNS Resolution Issues + + A MIF node (M1) has an active interface (I1) connected to a network + (N1), which has its DNS servers (S1 as primary DNS server) and + another active interface (I2) connected to a network (N2), which has + its DNS servers (S2 as primary DNS server). S1 serves some private + + + + + +Blanchet & Seite Informational [Page 9] + +RFC 6418 Multiple Interfaces Problem Statement November 2011 + + + namespace, "private.example.com". The user or the application uses a + name "a.private.example.com", which is within the private namespace + of S1 and only resolvable by S1. Any of the following situations may + occur: + + 1. The M1 stack, based on its routing table, uses I2 to reach S1 to + resolve "a.private.example.com". M1 never reaches S1. The name + is not resolved. + + 2. M1 keeps only one set of DNS server addresses from the received + configuration objects. Let us assume that M1 keeps S2's address + as the primary DNS server. M1 sends the forward DNS query for + a.private.example.com to S2. S2 responds with an error for a + nonexistent domain (NXDOMAIN). The name is not resolved. This + issue also arises when performing a reverse DNS lookup. In the + same situation, the reverse DNS query fails. + + 3. M1 keeps only one set of DNS server addresses from the received + configuration objects. Let us assume that M1 keeps S2's address. + M1 sends the DNS query for a.private.example.com to S2. S2 + queries its upstream DNS and gets an IP address for + a.private.example.com. However, the IP address is not the same + one that S1 would have given. Therefore, the application tries + to connect to the wrong destination node, or to the wrong + interface, which may imply security issues or result in lack of + service. + + 4. S1 or S2 has been used to resolve "a.private.example.com" to an + [RFC1918] address. Both N1 and N2 are [RFC1918]-addressed + networks. If addresses overlap, traffic may be sent using the + wrong interface. This issue is not related to receiving multiple + configuration objects, but to an address overlap between + interfaces or attaching networks. + + 5. M1 has resolved a Fully Qualified Domain Name (FQDN) to a locally + valid IP address when connected to N1. If the node loses + connection to N1, the node may try to connect, via N2, to the + same IP address as earlier, but as the address was only locally + valid, connection setup fails. Similarly, M1 may have received + NXDOMAIN for an FQDN when connected to N1. After detachment from + N1, the node should not assume the FQDN continues to be + nonexistent on N2. + + + + + + + + + +Blanchet & Seite Informational [Page 10] + +RFC 6418 Multiple Interfaces Problem Statement November 2011 + + + 6. M1 requests a AAAA record from a DNS server on a network that + uses protocol translators and DNS64 [RFC6147]. If M1 receives a + synthesized AAAA record, it is guaranteed to be valid only on the + network from which it was learned. If M1 uses synthesized AAAA + on any other network interface, traffic may be lost, dropped, or + forwarded to the wrong network. + + Some networks require the user to authenticate on a captive web + portal before providing Internet connectivity. If this redirection + is achieved by modifying the DNS reply, specific issues may occur. + Consider a MIF node (M1) with an active interface (I1) connected to a + network (N1), which has its DNS server (S1), and another active + interface (I2) connected to a network (N2), which has its DNS server + (S2). Until the user has not authenticated, S1 is configured to + respond to any A or AAAA record query with the IP address of a + captive portal, so as to redirect web browsers to an access control + portal web page. This captive portal can be reached only via I1. + When the user has authenticated to the captive portal, M1 can resolve + an FQDN when connected to N1. However, if the address is only + locally valid on N1, any of the issues described above may occur. + When the user has not authenticated, any of the following situations + may occur: + + 1. M1 keeps only one set of DNS server addresses from the received + configuration objects and kept S2 address. M1 sends the forward + DNS query for a.example.com to S2. S2 responds with the correct + answer, R1. M1 attempts to contact R1 by way of I1. The + connection fails. Or, the connection succeeds, bypassing the + security policy on N1, possibly exposing the owner of M1 to + prosecution. + + 2. M1 keeps only one set of DNS server addresses from the received + configuration objects and kept S1 address. M1 sends the DNS + query for a.example.com to S1. S1 provides the address of its + captive portal. M1 attempts to contact this IP address using I1. + The application fails to connect, resulting in lack of service. + Or, the application succeeds in connecting but connects to the + captive portal rather than the intended destination, resulting in + lack of service (i.e., an IP connectivity check issue, as + described in Section 4.4). + + + + + + + + + + + +Blanchet & Seite Informational [Page 11] + +RFC 6418 Multiple Interfaces Problem Statement November 2011 + + +4.2. Node Routing + + Consider a MIF node (M1) with an active interface (I1) connected to a + network (N1) and another active interface (I2) connected to a network + (N2). The user or the application is trying to reach an IP address + (IP1). Any of the following situations may occur: + + 1. For IP1, M1 has one default route (R1) via network (N1). To + reach IP1, the M1 stack uses R1 and sends through I1. If IP1 is + only reachable by N2, IP1 is never reached or is not the right + target. + + 2. For the IP1 address family, M1 has one default route (R1, R2) per + network (N1, N2). IP1 is reachable by both networks, but the N2 + path has better characteristics, such as better round-trip time, + least cost, better bandwidth, etc. These preferences could be + defined by the user, provisioned by the network operator, or + otherwise appropriately configured. The M1 stack uses R1 and + tries to send through I1. IP1 is reached, but the service would + be better via I2. + + 3. For the IP1 address family, M1 has a default route (R1), a + specific X.0.0.0/8 route R1B (for example, but not restricted to + an [RFC1918] prefix) to N1, and a default route (R2) to N2. IP1 + is reachable by N2 only, but the prefix (X.0.0.0/8) is used in + both networks. Because of the most specific route R1B, the M1 + stack sends packets through I2, and those packets never reach the + target. + + A MIF node may have multiple routes to a destination. However, by + default, it does not have any hint concerning which interface would + be the best to use for that destination. The first-hop selection may + leverage on local routing policy, allowing some actors (e.g., network + operator or service provider) to influence the routing table, i.e., + make a decision regarding which interface to use. For instance, a + user on such a multihomed node might want a local policy to influence + which interface will be used based on various conditions. Some + Standards Development Organizations (SDOs) have defined policy-based + routing selection mechanisms. For instance, the Access Network + Discovery and Selection Function (ANDSF) [TS23.402] provides + inter-system routing policies to terminals with both a 3GPP interface + and non-3GPP interfaces. However, the routing selection may still be + difficult, due to disjoint criteria as discussed in Section 3.8. + Moreover, information required to make the right decision may not be + available. For instance, interfaces to a lower layer may not provide + all required hints concerning the selection (e.g., information on + interface quality). + + + + +Blanchet & Seite Informational [Page 12] + +RFC 6418 Multiple Interfaces Problem Statement November 2011 + + + A node usually has a node-scoped routing table. However, a MIF node + is connected to multiple provisioning domains; if each of these + domains pushes routing policies to the node, then conflicts between + policies may happen, and the node has no easy way to merge or + reconcile them. + + On a MIF node, some source addresses are not valid if used on some + interfaces. For example, an [RFC1918] source address might be + appropriate on the VPN interface but not on the public interface of + the MIF node. If the source address is not chosen appropriately, + then packets may be filtered in the path if source address filtering + is in place ([RFC2827], [RFC3704]), and reply packets may never come + back to the source. + +4.3. Conflicting Policies + + The distribution of configuration policies (e.g., address selection, + routing, DNS selection) to end nodes is being discussed (e.g., ANDSF + in [TS23.402], [DHCPv6-ROUTE-OPTIONS]). If implemented in multiple + provisioning domains, such mechanisms may conflict and create issues + for the multihomed node. Considering a MIF node (M1) with an active + interface (I1) connected to a network (N1) and another active + interface (I2) connected to a network (N2), the following conflicts + may occur: + + 1. M1 receives from both networks (N1 and N2) an update of its + default address selection policy. However, the policies are + specific to each network. The policies are merged by the M1 + stack. Based on the merged policy, the chosen source address is + from N1, but packets are sent to N2. The source address is not + reachable from N2; therefore, the return packet is lost. Merging + address selection policies may have important impacts on routing. + + 2. A node usually has a node-scoped routing table. However, each of + the connected provisioning domains (N1 and N2) may push routing + policies to the node; conflicts between policies may then happen, + and the node has no easy way to merge or reconcile them. + + 3. M1 receives from one of the networks an update of its access + selection policy, e.g., via the 3GPP/ANDSF [TS23.402]. However, + the policy is in conflict with the local policy (e.g., user- + defined or default OS policy). Assuming that the network + provides a list of overloaded access networks, if the policy sent + by the network is ignored, the packet may be sent to an access + network with poor quality of communication. + + + + + + +Blanchet & Seite Informational [Page 13] + +RFC 6418 Multiple Interfaces Problem Statement November 2011 + + +4.4. Session Management + + Consider that a node has selected an interface and managed to + configure it (i.e., the node obtained a valid IP address from the + network). However, Internet connectivity is not available. The + problem could be due to the following reasons: + + 1. The network requires a web-based authentication (e.g., the access + network is a WiFi hot spot). In this case, the user can only + access a captive portal. For instance, the network may perform + HTTP redirection or modify DNS behavior (Section 4.1) until the + user has not authenticated. + + 2. The IP interface is configured as active, but Layer 2 is so poor + (e.g., poor radio condition) that no Layer 3 traffic can succeed. + + In this situation, the session manager should be able to perform IP + connectivity checks before selecting an interface. + + Session issues may also arise when the node discovers a new + provisioning domain. Consider a MIF node (M1) with an active + interface (I1) connected to a network (N1) where an application is + running a TCP session. A new network (N2) becomes available. If N2 + is selected (e.g., because of better quality of communication), M1 + gets IP connectivity to N2 and updates the routing table priority. + So, if no specific route to the correspondent node is in place, and + if the node implements the weak host model [RFC1122], the TCP + connection breaks as the next hop changes. In order to continue + communicating with the correspondent node, M1 should try to reconnect + to the server via N2. In some situations, it could be preferable to + maintain current sessions on N1 while new sessions start on N2. + +4.5. Single Interface on Multiple Provisioning Domains + + When a node using a single interface is connected to multiple + networks, such as different default routers, similar issues to those + described above will happen. Even with a single interface, a node + may wish to connect to more than one provisioning domain: that node + may use more than one IP source address and may have more than one + default router. The node may want to access services that can only + be reached using one of the provisioning domains. In this case, it + needs to use the right outgoing source address and default gateway to + reach that service. In this situation, that node may also need to + use different DNS servers to get domain names in those different + provisioning domains. + + + + + + +Blanchet & Seite Informational [Page 14] + +RFC 6418 Multiple Interfaces Problem Statement November 2011 + + +5. Underlying Problems and Causes + + This section lists the underlying problems, and their causes, that + lead to the issues discussed in the previous section. The problems + can be divided into five categories: 1) configuration, 2) DNS + resolution, 3) routing, 4) address selection, and 5) session + management and APIs. They are shown below: + + 1. Configuration. In a MIF context, configuration information + specific to a provisioning domain may be ignored because: + + A. Configuration objects (e.g., DNS servers, NTP servers) are + node-scoped. So, the IP stack is not able to maintain the + mapping between configuration information and the + corresponding provisioning domain. + + B. The same configuration objects (e.g., DNS server addresses, + NTP server addresses) received from multiple provisioning + domains may be overwritten. + + C. Host implementations usually do not keep separate network + configurations (such as DNS server addresses) per + provisioning domain. + + 2. DNS resolution + + A. Some FQDNs can be resolvable only by sending queries to the + right server (e.g., intranet services). However, a DNS query + could be sent to the wrong interface because DNS server + addresses may be node-scoped. + + B. A DNS answer may be only valid on a specific provisioning + domain, but applications may not be aware of that mapping + because DNS answers may not be kept with the provisioning + from which the answer comes. + + 3. Routing + + A. In the MIF context, routing information could be specific to + each interface. This could lead to routing issues because, + in current node implementations, routing tables are node- + scoped. + + B. Current node implementations do not take into account the + Differentiated Services Code Point or path characteristics in + the routing table. + + + + + +Blanchet & Seite Informational [Page 15] + +RFC 6418 Multiple Interfaces Problem Statement November 2011 + + + C. Even if implementations take into account path + characteristics, the node has no way to properly merge or + reconcile the provisioning domain preferences. + + D. A node attached to multiple provisioning domains could be + provided with incompatible selection policies. If the + different actors (e.g., user and network operator) are + allowed to provide their own policies, the node has no way to + properly merge or reconcile multiple selection policies. + + E. The problem of first-hop selection could not be solved via + configuration (Section 3.7), and may leverage on + sophisticated and specific mechanisms (Section 3.8). + + 4. Address selection + + A. Default address selection policies may be specific to their + corresponding provisioning domain. However, a MIF node may + not be able to manage address selection policies per + provisioning domain, because default address selection + policies are node-scoped. + + B. On a MIF node, some source addresses are not valid if used on + some interfaces or even on some default routers on the same + interface. In this situation, the source address should be + taken into account in the routing table, but current node + implementations do not support such a feature. + + C. Source address or address selection policies could be + specified by applications. However, there are no advanced + APIs that support such applications. + + 5. Session management and APIs + + A. Some implementations, especially in the mobile world, have + higher-level APIs and/or session managers (aka connection + managers) to address MIF issues. These mechanisms are not + standardized and do not necessarily behave the same way + across different OSes and/or platforms in the presence of MIF + problems. This lack of consistency is an issue for the user + and operator, who could experience different session manager + behaviors, depending on the terminal. + + + + + + + + + +Blanchet & Seite Informational [Page 16] + +RFC 6418 Multiple Interfaces Problem Statement November 2011 + + + B. Session managers usually leverage on an interface to the link + layer to gather information (e.g., lower-layer authentication + and encryption methods) and/or for control purposes. + However, such a link-layer interface may not provide all + required services (e.g., may not provide all information that + would allow a proper interface selection). + + C. A MIF node can support different session managers, which may + have contradictory ways of solving MIF issues. For instance, + because of different selection algorithms, two different + session managers could select different domains in the same + context. Or, when dealing with different domain selection + policies, one session manager may give precedence to user + policy while another could favor mobile operator policy. + + D. When host routing is updated and if the weak host model is + supported, ongoing TCP sessions may break if routes change + for these sessions. When TCP sessions should be bound to the + interface, the strong host model should be used. + + E. When provided by different actors (e.g., user, network, + default OS), policies may conflict and, thus, need to be + reconciled at the host level. Policy conflict resolution may + impact other functions (e.g., naming, routing). + + F. Even if the node has managed to configure an interface, + Internet connectivity could be unavailable. This could be + due to an access control function coming into play above + Layer 3, or because of poor Layer 2 conditions. An IP + connectivity check should be performed before selecting an + interface. + +6. Security Considerations + + The problems discussed in this document have security implications, + such as when packets sent on the wrong interface might be leaking + some confidential information. Configuration parameters from one + provisioning domain could cause a denial of service on another + provisioning domain (e.g., DNS issues). Moreover, the undetermined + behavior of IP stacks in the multihomed context brings additional + threats where an interface on a multihomed node might be used to + conduct attacks targeted to the networks connected by the other + interfaces. Corrupted provisioning domain selection policy may + induce a node to make decisions causing certain traffic to be + forwarded to the attacker. + + + + + + +Blanchet & Seite Informational [Page 17] + +RFC 6418 Multiple Interfaces Problem Statement November 2011 + + + Additional security concerns are raised by possible future mechanisms + that provide additional information to the node so that it can make a + more intelligent decision with regards to the issues discussed in + this document. Such future mechanisms may themselves be vulnerable + and may not be easy to protect in the general case. + +7. Contributors + + This document is a joint effort with the authors of the MIF + requirements document [MIF-REQ]. This includes, in alphabetical + order: Jacni Qin, Carl Williams, and Peng Yang. + +8. Acknowledgements + + The documents written prior to the existence of the MIF working + group, and the discussions during the MIF Birds of a Feather (BOF) + meeting and around the MIF charter scope on the mailing list, brought + very good input to the problem statement. This document steals a lot + of text from these discussions and initial documents (e.g., + [MIF-REQ], [IP-MULTIPLE-CONN], [MIF-DNS-SERVER-SELECT]). Therefore, + the authors would like to acknowledge the following people (in no + specific order), from whom some text has been taken: Jari Arkko, + Keith Moore, Sam Hartman, George Tsirtsis, Scott Brim, Ted Lemon, + Bernie Volz, Giyeong Son, Gabriel Montenegro, Julien Laganier, Teemu + Savolainen, Christian Vogt, Lars Eggert, Margaret Wasserman, Hui + Deng, Ralph Droms, Ted Hardie, Christian Huitema, Remi Denis- + Courmont, Alexandru Petrescu, Zhen Cao, Gaetan Feige, Telemaco Melia, + and Juan-Carlos Zuniga. Apologies to any contributors who have + inadvertently not been named. + +9. Informative References + + [ADDR-SELECT-SOL] + Matsumoto, A., Fujisaki, T., and R. Hiromi, "Solution + approaches for address-selection problems", Work + in Progress, March 2010. + + [DHCPv6-ROUTE-OPTIONS] + Dec, W., Ed., Mrugalski, T., Sun, T., and B. Sarikaya, + "DHCPv6 Route Options", Work in Progress, September 2011. + + [IP-MULTIPLE-CONN] + Hui, M. and H. Deng, "Problem Statement and Requirement of + Simple IP Multi-homing of the Host", Work in Progress, + March 2009. + + + + + + +Blanchet & Seite Informational [Page 18] + +RFC 6418 Multiple Interfaces Problem Statement November 2011 + + + [LOGICAL-IF-SUPPORT] + Melia, T., Ed., and S. Gundavelli, Ed., "Logical Interface + Support for multi-mode IP Hosts", Work in Progress, + October 2011. + + [MIF-DNS-SERVER-SELECT] + Savolainen, T., Kato, J., and T. Lemon, "Improved DNS + Server Selection for Multi-Interfaced Nodes", Work + in Progress, October 2011. + + [MIF-REQ] Yang, P., Seite, P., Williams, C., and J. Qin, + "Requirements on multiple Interface (MIF) of simple IP", + Work in Progress, February 2009. + + [MIH] IEEE, "IEEE Standard for Local and Metropolitan Area + Networks - Part 21: Media Independent Handover Services", + IEEE LAN/MAN Std. 802.21-2008, January 2009. + + [REFERRAL-PS] + Carpenter, B., Jiang, S., and Z. Cao, "Problem Statement + for Referral", Work in Progress, February 2011. + + [RFC1122] Braden, R., Ed., "Requirements for Internet Hosts - + Communication Layers", STD 3, RFC 1122, October 1989. + + [RFC1136] Hares, S. and D. Katz, "Administrative Domains and Routing + Domains: A model for routing in the Internet", RFC 1136, + December 1989. + + [RFC1661] Simpson, W., Ed., "The Point-to-Point Protocol (PPP)", + STD 51, RFC 1661, July 1994. + + [RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G., + and E. Lear, "Address Allocation for Private Internets", + BCP 5, RFC 1918, February 1996. + + [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", + RFC 2131, March 1997. + + [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, + "Definition of the Differentiated Services Field (DS + Field) in the IPv4 and IPv6 Headers", RFC 2474, + December 1998. + + [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: + Defeating Denial of Service Attacks which employ IP Source + Address Spoofing", BCP 38, RFC 2827, May 2000. + + + + +Blanchet & Seite Informational [Page 19] + +RFC 6418 Multiple Interfaces Problem Statement November 2011 + + + [RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, + C., and M. Carney, "Dynamic Host Configuration Protocol + for IPv6 (DHCPv6)", RFC 3315, July 2003. + + [RFC3484] Draves, R., "Default Address Selection for Internet + Protocol version 6 (IPv6)", RFC 3484, February 2003. + + [RFC3542] Stevens, W., Thomas, M., Nordmark, E., and T. Jinmei, + "Advanced Sockets Application Program Interface (API) for + IPv6", RFC 3542, May 2003. + + [RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed + Networks", BCP 84, RFC 3704, March 2004. + + [RFC4294] Loughney, J., Ed., "IPv6 Node Requirements", RFC 4294, + April 2006. + + [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, + "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, + September 2007. + + [RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol", + RFC 4960, September 2007. + + [RFC5014] Nordmark, E., Chakrabarti, S., and J. Laganier, "IPv6 + Socket API for Source Address Selection", RFC 5014, + September 2007. + + [RFC5113] Arkko, J., Aboba, B., Korhonen, J., Ed., and F. Bari, + "Network Discovery and Selection Problem", RFC 5113, + January 2008. + + [RFC5206] Nikander, P., Henderson, T., Ed., Vogt, C., and J. Arkko, + "End-Host Mobility and Multihoming with the Host Identity + Protocol", RFC 5206, April 2008. + + [RFC5220] Matsumoto, A., Fujisaki, T., Hiromi, R., and K. Kanayama, + "Problem Statement for Default Address Selection in + Multi-Prefix Environments: Operational Issues of RFC 3484 + Default Rules", RFC 5220, July 2008. + + [RFC5221] Matsumoto, A., Fujisaki, T., Hiromi, R., and K. Kanayama, + "Requirements for Address Selection Mechanisms", RFC 5221, + July 2008. + + + + + + + +Blanchet & Seite Informational [Page 20] + +RFC 6418 Multiple Interfaces Problem Statement November 2011 + + + [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment + (ICE): A Protocol for Network Address Translator (NAT) + Traversal for Offer/Answer Protocols", RFC 5245, + April 2010. + + [RFC5533] Nordmark, E. and M. Bagnulo, "Shim6: Level 3 Multihoming + Shim Protocol for IPv6", RFC 5533, June 2009. + + [RFC5648] Wakikawa, R., Ed., Devarapalli, V., Tsirtsis, G., Ernst, + T., and K. Nagami, "Multiple Care-of Addresses + Registration", RFC 5648, October 2009. + + [RFC6147] Bagnulo, M., Sullivan, A., Matthews, P., and I. van + Beijnum, "DNS64: DNS Extensions for Network Address + Translation from IPv6 Clients to IPv4 Servers", RFC 6147, + April 2011. + + [RFC6182] Ford, A., Raiciu, C., Handley, M., Barre, S., and J. + Iyengar, "Architectural Guidelines for Multipath TCP + Development", RFC 6182, March 2011. + + [RFC6275] Perkins, C., Ed., Johnson, D., and J. Arkko, "Mobility + Support in IPv6", RFC 6275, July 2011. + + [RFC6316] Komu, M., Bagnulo, M., Slavov, K., and S. Sugimoto, Ed., + "Sockets Application Program Interface (API) for + Multihoming Shim", RFC 6316, July 2011. + + [RFC6419] Wasserman, M. and P. Seite, "Current Practices for + Multiple-Interface Hosts", RFC 6419, November 2011. + + [SHIM6-APP-REFER] + Nordmark, E., "Shim6 Application Referral Issues", Work + in Progress, July 2005. + + [TS23.234] + 3GPP, "3GPP system to Wireless Local Area Network (WLAN) + interworking", TS 23.234, December 2009. + + [TS23.402] + 3GPP, "Architecture enhancements for non-3GPP accesses", + TS 23.402, December 2010. + + + + + + + + + +Blanchet & Seite Informational [Page 21] + +RFC 6418 Multiple Interfaces Problem Statement November 2011 + + +Authors' Addresses + + Marc Blanchet + Viagenie + 2875 boul. Laurier, suite D2-630 + Quebec, QC G1V 2M2 + Canada + + EMail: Marc.Blanchet@viagenie.ca + URI: http://viagenie.ca + + + Pierrick Seite + France Telecom - Orange + 4, rue du Clos Courtel, BP 91226 + Cesson-Sevigne 35512 + France + + EMail: pierrick.seite@orange.com + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Blanchet & Seite Informational [Page 22] + -- cgit v1.2.3