| Network Working Group | M. Blanchet |
| Internet-Draft | Viagenie |
| Intended status: Informational | P. Seite |
| Expires: November 10, 2011 | France Telecom - Orange |
| May 09, 2011 |
Multiple Interfaces and Provisioning Domains Problem Statement
draft-ietf-mif-problem-statement-15.txt
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, others are local to the interface. Issues such as selecting the wrong interface to send trafic happen when conflicting node-scoped configuration objects are received and inappropriately used. Moreover, other issues are the result of simulatenous 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 single interface nodes situation.
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."
This Internet-Draft will expire on November 10, 2011.
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.
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, a 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 servers IP addresses, and address selection policies, herein named "node-scoped".
When the received node-scoped configuration objects have different values from each provisioning domains, such as different DNS servers 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 simulatenous 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, the scope of this work, describe related work, list issues and then summarize the underlying problems.
A companion document [I-D.ietf-mif-current-practices] discusses some current practices of various implementations dealing with MIF.
Administrative domain
Provisioning domain
Reference to IP version
This section describes existing related work and defines the scope of the problem.
Some types of interfaces have link layer characteristics which may be used in determining how multiple provisioning domain issues will be dealt with. For instance, link layers may have authentication and encryption characteristics which 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 current problem statement. Furthermore, link aggregation done under IP where a single interface is shown to the IP stack is also out of scope.
A MIF node has the following characteristics:
The requirements for Internet Hosts [RFC1122] describe 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.
The requirements states that The node maintains a route cache table where each entry contains the local IP address, the destination IP address, Differentiated Services Code Point and 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 these informations.
[RFC1122] defines two host models:
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, but only the destination IP address and the Differentiated Services Code Point.
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, multi-homing, 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], [I-D.ietf-mptcp-architecture].
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 sessions on the new interface. The problem of the interface selection is within the MIF scope and may leverage specific node functions (Section 3.8). However, if transfer of IP session is required, IP mobility mechanisms, such as [RFC3775], shall be used.
The Default Address Selection specification [RFC3484] defines algorithms for source and destination IP address selections. It is mandatory to be implemented 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 being defined [I-D.ietf-6man-addr-select-sol] to update the policy table.
Issues on using the Default Address Selection were found in [RFC5220] and [RFC5221] in the context of multiple prefixes on the same link.
Interactive Connectivity Establishment (ICE [RFC5245]) is a technique for NAT traversal for UDP-based (and TCP) media streams established by the offer/answer model. The multiplicity of IP addresses, ports and transport in 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 itself 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 [I-D.carpenter-referral-ps] and [I-D.ietf-shim6-app-refer].
In a MIF context, the node may handle simultaneously 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 recommendation 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):
However, [TS23.234] is designed for a specific multiple-interfaces use-case. A generic way to handle these characteristics is yet to be defined.
Some implementations, specially in the mobile world, rely on higher-level session manager, also named 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 to the applications, or tackle with complex issues such as policies conflict resolution (Section 4.3). As discussed previously 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 purpose. Such link-layer interface may not provide all required services to make a proper decision (e.g. interface selection). Some OS, or terminals, already implement session managers [I-D.ietf-mif-current-practices] and vendor-specific platforms sometimes provides specific socket API (Section 3.9) a session manager can use. However, the generic architecture of a session manager and its associated API are not currently standardized, so session management behavior may differ between OS and platforms.
Multiple interfaces management sometimes relies on a virtual interface. For instance, virtual interface allows to support multi-homing, inter-technology handovers and IP flow mobility in a Proxy Mobile IPv6 network [I-D.ietf-netext-logical-interface-support]. This virtual interface allows a multiple-interfaces node sharing a set of IP addresses on multiple physical interfaces and can also add benefits to multi-access scenarios such as 3GPP Multi Access PDN Connectivity [TS23.402]. In most cases, the virtual interface will map several physical network interfaces and the session manager should control both, the configuration of each one of these virtual and physical interfaces, as well as the mapping between the virtual and the sub-interfaces.
In multiple interfaces situation, active application sessions should survive to path failures. Here, the session manager may come into play but only relying on existing mechanisms to manage multipath (MPTCP [I-D.ietf-mptcp-architecture]) or failover (MIP6 [RFC3775], SHIM6 [RFC5533]). Description of interaction between these mechanisms and the session manager is out of the scope of this document.
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 similar issues to MIF. For instance, [RFC5014] defines an API to influence the default address selection mechanism by specifying attributes of the source addresses it prefers. [I-D.ietf-shim6-multihome-shim-api] gives another example, in a multihoming context, by defining a socket API enabling interactions between applications and the multihoming shim layer for advanced locator management, and access to information about failure detection and path exploration.
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 results in wrong domain selection, addressing or naming space overlaps. They occur, for example, when:
A MIF node (M1) has 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). S1 serves with some private 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:
Some networks requires 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 issue described above may occur. When the user has not authenticated, any of the following situations may occur:
A MIF node (M1) has 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:
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 decision regarding which interface to use. For instance, a user on such multihomed node might want a local policy to influence which interface will be used based on various conditions. Some SDOs have defined policy-based routing selection mechanisms. For instance, the Access Network Discovery and Selection Function (ANDSF) [TS23.402] provides inter-systems routing policies to terminals with both a 3GPP 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 lower layer may not provide all required hints to the selection (e.g. information on interface quality).
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 reconciliate 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.
The distribution of configuration policies (e.g. address selection, routing, DNS selection…) to end nodes is being discussed (e.g. ANDSF in [TS23.402], [I-D.ietf-mif-dhcpv6-route-option]). If implemented in multiple provisioning domains, such mechanisms may conflict and bring issues to 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:
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, the Internet connectivity is not available. The problem could be due to the following reasons:
In this situation, the session management 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) has 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 and if the node implements the weak host model [RFC1122], the TCP connection breaks as next hop changes. In order to continue communicating with the correspondent node, M1 should try to re-connect the server via N2. In some situation, it could be preferable to maintain current sessions on N1 while new sessions start on N2.
When a node using a single interface is connected to multiple networks, such as different default routers, similar issues as described above 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 domain. 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.
This section lists the underlying problems, and their causes, which 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 API. They are shown as below:
The problems discussed in this document have security implications, such as when the 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 bring 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.
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.
This document has no actions for IANA.
This document is a joint effort with authors of the MIF requirements draft [I-D.yang-mif-req]. The authors of this document, in alphabetical order, include: Marc Blanchet, Jacqni Qin, Pierrick Seite, Carl Williams and Peny Yang.
The initial Internet-Drafts prior to the MIF working group and the discussions during the MIF BOF meeting and on the mailing list around the MIF charter scope on the mailing list brought very good input to the problem statement. This draft steals a lot of text from these discussions and initial drafts (e.g. [I-D.yang-mif-req], [I-D.hui-ip-multiple-connections-ps], [I-D.ietf-mif-dns-server-selection]). Therefore, the editor would like to acknowledge the following people (in no specific order), from which some text has been taken from: 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, Rémi Denis-Courmont, Alexandru Petrescu, Zhen Cao, Gaetan Feige, Telemaco Melia and Juan-Carlos Zuniga. Sorry if some contributors have not been named.