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.

Table of Contents

1.  Introduction
2.  Split DNS
3.  Routing
4.  Address Selection Policy
5.  Summary
6.  Security Considerations
7.  IANA Considerations
8.  Authors
9.  Acknowledgements
10.  Discussion home for this draft
11.  Informative References
§  Author's Address
§  Intellectual Property and Copyright Statements

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] (Droms, R., “Dynamic Host Configuration Protocol,” March 1997.), DHCPv6 [RFC3315] (Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, “Dynamic Host Configuration Protocol for IPv6 (DHCPv6),” July 2003.), PPP [RFC1661] (Simpson, W., “The Point-to-Point Protocol (PPP),” July 1994.) and IPv6 Router Advertisements [RFC4861] (Narten, T., Nordmark, E., Simpson, W., and H. Soliman, “Neighbor Discovery for IP version 6 (IPv6),” September 2007.). 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] (Savolainen, T., “Domain name based network interface selection,” October 2008.). 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.

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] (Savolainen, T., “Domain name based network interface selection,” October 2008.) and [I‑D.hui‑ip‑multiple‑connections‑ps] (Hui, M. and H. Deng, “Problem Statement and Requirement of Simple IP Multi-homing of the Host,” March 2009.), 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] (Draves, R., “Default Address Selection for Internet Protocol version 6 (IPv6),” February 2003.) 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] (Hinden, R. and S. Deering, “IP Version 6 Addressing Architecture,” February 2006.), 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 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

Author's Address

Full Copyright Statement

Copyright © 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.