Network Working Group M. Blanchet Internet-Draft Viagenie Intended status: Informational December 9, 2008 Expires: June 12, 2009 Multiple Interfaces Problem Statement draft-blanchet-mif-problem-statement-00.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. 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 June 12, 2009. Abstract A multi-homed host receives node configuration information from each of its access networks. Some configuration objects are global to the node, some are local to the interface. Various issues arise when multiple configuration objects that are global to the node are received on the many interfaces the multi-homed host has. This document describes these issues. Blanchet Expires June 12, 2009 [Page 1] Internet-Draft Multiple Interfaces Problem Statement December 2008 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Split DNS . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Routing . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 4. Address Selection Policy . . . . . . . . . . . . . . . . . . . 4 5. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 8. Authors . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 5 10. Discussion home for this draft . . . . . . . . . . . . . . . . 5 11. Informative References . . . . . . . . . . . . . . . . . . . . 5 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 6 Intellectual Property and Copyright Statements . . . . . . . . . . 7 Blanchet Expires June 12, 2009 [Page 2] Internet-Draft Multiple Interfaces Problem Statement December 2008 1. Introduction A multi-homed host has multiple network interfaces (physical and/or virtual). For example, a node may be 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. In this document, the multi-homed host does not forward any packet between its interfaces. Therefore forwarding devices are out of scope of this document. A multi-homed 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 (default gateway), DNS servers IP addresses and address selection policies. When the received node-scoped configuration objects have different values from each access network, 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. A document discusses (TBD: reference MRW doc) how some current implementations manage these cases. Several issues regarding how the node-scoped configuration objects are used in a multi-homed node environment have been raised. The following sections describe the issues regarding DNS, routing and address selection policy. 2. Split DNS A multi-homed host may have one of its interfaces facing a DNS service which resolves private names and addresses, as stated in [I-D.savolainen-6man-fqdn-based-if-selection]. This split DNS may occur when a VPN connection to an enterprise network is setup or in a service provider's network for subscribers-only services. These private names and addresses are only relevant to a specific interface. Therefore the traffic related to these names and addresses has to go through the right interface. However, a typical IP stack does not maintain a binding of the origin of the DNS name resolution with its routing table. Therefore the trafic might go to the wrong interface and never reach the destination. Blanchet Expires June 12, 2009 [Page 3] Internet-Draft Multiple Interfaces Problem Statement December 2008 3. Routing A multi-homed 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] and [I-D.hui-ip-multiple-connections-ps], a service provider might want to influence the routing table of the host connecting to its network. (TBD: expand) A host usually has a node-scoped routing table. Therefore, when a multi-homed host is connected to multiple networks and 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 multi-homed host might want a local policy to influence which interface will be used based on various conditions. On a multi-homed 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 multi-homed 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 and reply packets might never come back to the source. 4. Address Selection Policy An address selection policy [RFC3484] is used to choose the right source and destination address for a new connection. It is implemented globally in the node IP stack. As discussed in [RFC4291], a multi-homed host with IPv4 and IPv6 connectivity might need to receive an update of its default address selection policy. However, that policy is only valid within the context of the interface it received it from. Each network on which the node is connected might have a different address policy to push to the connecting nodes" The received policies might be conflicting. There is currently no standard mechanism to determine what should be the behavior of the stack in such case. 5. Summary A multi-homed host receives node configuration information from each Blanchet Expires June 12, 2009 [Page 4] Internet-Draft Multiple Interfaces Problem Statement December 2008 of its access networks. Some configuration objects are global to the node, some are local to the interface. Various issues arise when multiple configuration objects that are global to the node are received on the many interfaces the multi-homed host has. Therefore, there is a need to define the appropriate behavior of an IP stack and possibly define protocols to manage these cases. 6. Security Considerations The problems discussed in this document have direct security implications, since the packets that are sent on the wrong interface might be leaking some confidential information. Moreover, the undetermined behavior of IP stacks in the multi-homed context bring additional threats where an interface on a multi-homed host might be used to conduct attacks targeted to the networks connected by the other interfaces. 7. IANA Considerations This document has no actions for IANA. 8. Authors TBD 9. Acknowledgements NAMES have provided input and suggestions to this document. 10. Discussion home for this draft This document is intended to define the problem space discussed in the mif@ietf.org mailing list. 11. Informative References [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-01 (work in progress), November 2008. Blanchet Expires June 12, 2009 [Page 5] Internet-Draft Multiple Interfaces Problem Statement December 2008 [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. [RFC1661] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, RFC 1661, July 1994. [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March 1997. [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. [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, February 2006. [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, September 2007. Author's Address Marc Blanchet Viagenie 2600 boul. Laurier, suite 625 Quebec, QC G1V 4W1 Canada Email: Marc.Blanchet@viagenie.ca URI: http://www.viagenie.ca Blanchet Expires June 12, 2009 [Page 6] Internet-Draft Multiple Interfaces Problem Statement December 2008 Full Copyright Statement Copyright (C) The IETF Trust (2008). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Blanchet Expires June 12, 2009 [Page 7]