Network Working Group M. Blanchet Ed. Internet-Draft Viagenie Intended status: Informational P. Seite Expires: April 29, 2010 France Telecom October 26, 2009 Multiple Interfaces Problem Statement draft-ietf-mif-problem-statement-01.txt Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. 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." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on April 29, 2010. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. Blanchet Ed. & Seite Expires April 29, 2010 [Page 1] Internet-Draft Multiple Interfaces Problem Statement October 2009 This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Abstract A multihomed host receives node configuration information from each of its provisioning domain. Some configuration objects are global to the node, some are local to the interface. Various issues arise when multiple conflicting node-scoped configuration objects are received on multiple interfaces. Similar situations also happen with single interface host connected to multiple networks. This document describes these issues. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Scope and Existing Work . . . . . . . . . . . . . . . . . . . 4 3.1. Below IP Interaction . . . . . . . . . . . . . . . . . . . 4 3.2. Hosts Requirements . . . . . . . . . . . . . . . . . . . . 4 3.3. Mobility and other IP protocols . . . . . . . . . . . . . 5 3.4. Address Selection . . . . . . . . . . . . . . . . . . . . 5 3.5. Interactive Connectivity Establishment (ICE) . . . . . . . 5 3.6. Socket API . . . . . . . . . . . . . . . . . . . . . . . . 6 3.7. Above IP Layers . . . . . . . . . . . . . . . . . . . . . 6 4. Symptoms . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 4.1. DNS resolution issues . . . . . . . . . . . . . . . . . . 6 4.2. Routing . . . . . . . . . . . . . . . . . . . . . . . . . 7 4.3. Address Selection Policy . . . . . . . . . . . . . . . . . 8 4.4. Single Interface on Multiple Networks . . . . . . . . . . 9 5. Problems . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 6. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 7. Security Considerations . . . . . . . . . . . . . . . . . . . 10 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 9. Authors . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 11. Discussion home for this draft . . . . . . . . . . . . . . . . 10 12. Informative References . . . . . . . . . . . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 Blanchet Ed. & Seite Expires April 29, 2010 [Page 2] Internet-Draft Multiple Interfaces Problem Statement October 2009 1. Introduction A multihomed host 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 automatic or manual tunnels. Current laptops and smartphones typically have multiple access network interfaces and, thus, may be simultaneously connected to different provisioning domains. A multihomed host receives node configuration information from each of its access networks, through various mechanims 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. 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 it will use or how it will merge them. Several issues regarding how the node-scoped configuration objects are used in a multihomed node environment have been raised. The following sections define the MIF host and the scope of this document, describe related work, list the symptoms and then the underlying problems. A companion document [I-D.mrw-mif-current-practices] discusses current practices. 2. Terminology A MIF host is defined as: o A [RFC1122] IPv4 and/or [RFC4294] IPv6 compliant host o Configured with more than one IP addresses (excluding loopback, link-local) o On one or more provisioning domains, as presented to the IP stack. o The interfaces may be logical, virtual or physical. o The IP addresses come from more than one administrative domains. o The IP addresses may be from the same or from different address families, such as IPv4 and IPv6. Blanchet Ed. & Seite Expires April 29, 2010 [Page 3] Internet-Draft Multiple Interfaces Problem Statement October 2009 o Communications using these IP addresses may happen simultaneously and independently. o Communications using these IP addresses may be tied on all the possible provisioning domains, or, at least, on a limited number of provisioning domains. o While the MIF host may forward packets between its interfaces, forwarding packets is not taken into account in this definition. When a protocol keyword such as IP, PPP, DHCP is used 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 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. Below IP Interaction Network discovery and selection on lower layers as defined by [RFC5113] is out of scope of this document. Moreover, lower layer interaction such as IEEE 802.21 is also out of scope. Proxy MIP allows sharing a single IP address across multiple interfac es (e.g., WiMAX and CDMA, LTE and HSPA, etc) to disparate networks. 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. Furthermore, link aggregation done under IP where a single interace is shown to the IP stack is also out of scope. 3.2. Hosts Requirements The requirements for Internet Hosts [RFC1122] describe the multihomed host 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 host maintains a route cache table where each entry contains the local IP address, the destination IP address, Type-of-Service 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. As per [RFC1122], two models are defined: Blanchet Ed. & Seite Expires April 29, 2010 [Page 4] Internet-Draft Multiple Interfaces Problem Statement October 2009 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 host 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 Type-of-Service. Under the weak model, the source IP address is not used, but only the destination IP address and the Type-of-Service. 3.3. Mobility and other IP protocols This document assumes hosts only implementing [RFC1122] for IPv4 and [RFC4294] for IPv6, and not using any kind of new transport protocols. It is not required for the host to support additional IP mobility or multihoming protocols, such as SHIM6, SCTP, Mobile IP, HIP, RRG, LISP or else. Moreover, the peer of the connection is also not required to use these mechanisms. 3.4. Address Selection The Default Address Selection [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. Provisions are made to change or update the policy table, however, no mechanism is defined. Issues on using the Default Address Selection were found [RFC5112] in the context of multiple prefixes on the same link. New work [I-D.chown-addr-select-considerations] discusses the multiple attached networks scenarios and how to update the policy table. 3.5. Interactive Connectivity Establishment (ICE) Interactive Connectivity Establishment (ICE [I-D.ietf-mmusic-ice]) is a technique for NAT traversal for UDP-based (and TCP) media streams established by the offer/answer model. The multiplicity of IP addresses and ports 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. Blanchet Ed. & Seite Expires April 29, 2010 [Page 5] Internet-Draft Multiple Interfaces Problem Statement October 2009 ICE does not solve the MIF issues, such as the incompatible configuration objects received on different interfaces. However, ICE may be of use for address selection if the application is ICE- enabled. 3.6. Socket API Application Programming Interface (API) may expose objects that user applications may use for the MIF purpose. For example, [RFC3542] shows how an application using the Advanced sockets API can specify the interface or the source IP address, through simple bind() operation or IPV6_PKTINFO socket option. An API is also defined [RFC5014] to influence the default address selection mechanism by specifying attributes of the source addresses it prefers. 3.7. Above IP Layers The MIF issues discussed in this document assume no changes in transport protocols or applications. However, fixing the issues might involve these layers. 4. Symptoms This section describes the various symptoms found using a MIF host that has already received configuration objects from its various provisioning domains. These situations are also described in [I-D.savolainen-6man-fqdn-based-if-selection], [I-D.yang-mif-req] and [RFC4477]. 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 host (H1) 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: Blanchet Ed. & Seite Expires April 29, 2010 [Page 6] Internet-Draft Multiple Interfaces Problem Statement October 2009 1. H1 stack, based on its routing table, uses I2 to reach S1 to resolve "a.private.example.com". H1 never reaches S1. The name is not resolved. 2. H1 keeps only one set of DNS server addresses from the received configuration objects and kept S2 address. H1 sends the DNS A query for a.private.example.com to S2. S2 responds with an error for an non-existant domain (NXDOMAIN). The name is not resolved. 3. H1 keeps only one set of DNS server addresses from the received configuration objects and kept S2 address. H1 sends the DNS A query for a.private.example.com to S2. S2 asks its upstream DNS and gets an IP address for a.private.example.com. However, the IP address is not the right one S1 would have given. Therefore, the application tries to connect to the wrong destination host, which may imply security issues. 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. IPv4 source address selection may face challenges, as due address overlapping the source/destination IP addresses do not necessarily provide enough information for making proper address selection decisions. 5. H1 has resolved an FQDN to locally valid IP address when connected to N1. After movement from N1 to N2, the host tries to connect to the same IP address as earlier, but as the address was only locally valid, connection setup fails. 6. H1 requests AAAA record from a DNS server on a network that uses protocol translators and DNS64 [I-D.ietf-behave-dns64]. If the H1 receives synthesized AAAA record, it is quaranteed to be valid only on the network it was learned from. If the H1 uses synthesized AAAA on an network interface it is not valid on, the packets will be dropped by the network. 4.2. Routing A MIF host (H1) 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: 1. For the IP1 address family, H1 has one default route (R1, R2) per network (N1, N2). IP1 is only reachable by N2. H1 stack uses R1 and tries to send through I1. IP1 is never reached or is not the right target. 2. For the IP1 address family, H1 has one default route (R1, R2) per network (N1, N2). IP1 is reachable by both networks, but N2 path has better characterictics, such as better round-trip time, least cost, better bandwidth, etc.... These preferences could be defined by user, by the provider, by discovery or else. H1 stack uses R1 and tries to send through I1. IP1 is reached but the service would be better by I2. Blanchet Ed. & Seite Expires April 29, 2010 [Page 7] Internet-Draft Multiple Interfaces Problem Statement October 2009 3. For the IP1 address family, H1 has a default route (R1), a specific X.0.0.0/8 route R1B (eg. 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, H1 stack sends through I2 and never reach the target. A MIF host 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. For example, as discussed in [I-D.savolainen-6man-fqdn-based-if-selection], [I-D.hui-ip-multiple-connections-ps] and [I-D.yang-mif-req], a service provider might want to influence the routing table of the host connecting to its network. A host usually has a node-scoped routing table. Therefore, when a MIF host is connected to multiple provisioning domains where each service provider wants to influence the routing table of the host, then conflicts might arise from the multiple routing information being pushed to the host. A user on such multihomed host might want a local policy to influence which interface will be used based on various conditions. On a MIF host, 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 host. If the source address is not chosen appropriately, then sent packets might be filtered in the path if source address filtering is in place ([RFC2827],[RFC3704]) and reply packets might never come back to the source. 4.3. Address Selection Policy A MIF host (H1) 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: 1. H1 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 H1 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. 2. TBD: add more Merging address selection policies may have important impacts on routing. Blanchet Ed. & Seite Expires April 29, 2010 [Page 8] Internet-Draft Multiple Interfaces Problem Statement October 2009 4.4. Single Interface on Multiple Networks When a MIF host using a single interface is connected to multiple networks with different default routers, similar issues as described above happen. 5. Problems This section tries to list the underlying problems corresponding to the issues discussed in the previous section. 1. Routing tables are usually node-scoped. 2. DNS server addresses and other configuration objects (NTP servers, ...) are usually node-scoped. 3. Same configuration objects (eg DNS server addresses, NTP server addresses, ..) received from multiple provisioning domains are usually overwritten. 4. Default Address Selection policies are usually node-scoped. 5. Default Address Selection policies may differ when received on different provisioning domains. 6. Host implementations usually do not implement the [RFC1122] strong model where the source address is in the routing table. 7. Host implementations usually do not implement the [RFC1122] model where the Type-of-Service are in the routing table. 8. Host implementations usually do not keep path characteristics, user or provider preferences in the routing table. 9. Applications usually do not use advanced APIs to specify the source IP address or to set preferences on the address selection policies. 10. DNS answers are usually not kept with the interface from which the answer comes from. 11. Host implementations usually do not keep separate network configuration (such as DNS server addresses) per provisioning domain. 6. Summary A MIF host receives node configuration information from each of its provisioning domains. Some configuration objects are global to the node, some are local to the interface. Various issues arise when multiple conflicting node-scoped configuration objects are received via multiple provisioning domains. Similar situations also happen with single interface host connected to multiple networks. Therefore, there is a need to define the appropriate behavior of an IP stack and possibly define protocols to manage these cases. Blanchet Ed. & Seite Expires April 29, 2010 [Page 9] Internet-Draft Multiple Interfaces Problem Statement October 2009 7. Security Considerations 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. Moreover, the undetermined behavior of IP stacks in the multihomed context bring additional threats where an interface on a multihomed host might be used to conduct attacks targeted to the networks connected by the other interfaces. 8. IANA Considerations This document has no actions for IANA. 9. Authors 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. 10. Acknowledgements 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 the initial drafts. 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, Teemu Savolainen, Christian Vogt, Lars Eggert, Margaret Wasserman, Hui Deng, Ralph Droms, Ted Hardie, Christian Huitema, Remi Denis-Courmont. Sorry if some contributors have not been named. 11. Discussion home for this draft This document is intended to define the problem space discussed in the mif@ietf.org mailing list. 12. Informative References [I-D.chown-addr-select-considerations] Blanchet Ed. & Seite Expires April 29, 2010 [Page 10] Internet-Draft Multiple Interfaces Problem Statement October 2009 Chown, T., "Considerations for IPv6 Address Selection Policy Changes", draft-chown-addr-select-considerations-03 (work in progress), July 2009. [I-D.hui-ip-multiple-connections-ps] Hui, M. and H. Deng, "Problem Statement and Requirement of Simple IP Multi-homing of the Host", draft-hui-ip-multiple-connections-ps-02 (work in progress), March 2009. [I-D.ietf-behave-dns64] Bagnulo, M., Sullivan, A., Matthews, P., and I. Beijnum, "DNS64: DNS extensions for Network Address Translation from IPv6 Clients to IPv4 Servers", draft-ietf-behave-dns64-01 (work in progress), October 2009. [I-D.ietf-mmusic-ice] Rosenberg, J., "Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols", draft-ietf-mmusic-ice-19 (work in progress), October 2007. [I-D.mrw-mif-current-practices] Wasserman, M., "Current Practices for Multiple Interface Hosts", draft-mrw-mif-current-practices-02 (work in progress), March 2009. [I-D.savolainen-6man-fqdn-based-if-selection] Savolainen, T., "Domain name based network interface selection", draft-savolainen-6man-fqdn-based-if-selection-00 (work in progress), October 2008. [I-D.yang-mif-req] Yang, P., Seite, P., Williams, C., and J. Qin, "Requirements on multiple Interface (MIF) of simple IP", draft-yang-mif-req-00 (work in progress), March 2009. [RFC1122] Braden, R., "Requirements for Internet Hosts - Communication Layers", STD 3, RFC 1122, October 1989. [RFC1661] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, RFC 1661, July 1994. [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, February 1996. Blanchet Ed. & Seite Expires April 29, 2010 [Page 11] Internet-Draft Multiple Interfaces Problem Statement October 2009 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March 1997. [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. [RFC3315] Droms, R., 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., "IPv6 Node Requirements", RFC 4294, April 2006. [RFC4477] Chown, T., Venaas, S., and C. Strauf, "Dynamic Host Configuration Protocol (DHCP): IPv4 and IPv6 Dual-Stack Issues", RFC 4477, May 2006. [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, September 2007. [RFC5014] Nordmark, E., Chakrabarti, S., and J. Laganier, "IPv6 Socket API for Source Address Selection", RFC 5014, September 2007. [RFC5112] Garcia-Martin, M., "The Presence-Specific Static Dictionary for Signaling Compression (Sigcomp)", RFC 5112, January 2008. [RFC5113] Arkko, J., Aboba, B., Korhonen, J., and F. Bari, "Network Discovery and Selection Problem", RFC 5113, January 2008. Blanchet Ed. & Seite Expires April 29, 2010 [Page 12] Internet-Draft Multiple Interfaces Problem Statement October 2009 Authors' Addresses Marc Blanchet Viagenie 2600 boul. Laurier, suite 625 Quebec, QC G1V 4W1 Canada Email: Marc.Blanchet@viagenie.ca URI: http://www.viagenie.ca Pierrick Seite France Telecom 4, rue du Clos Courtel, BP 91226 Cesson-Sevigne 35512 France Email: pierrick.seite@orange-ftgroup.com Blanchet Ed. & Seite Expires April 29, 2010 [Page 13]