Multiple Interfaces Problem Statement

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 , DHCPv6 , PPP and IPv6 Router Advertisements . 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.

A multi-homed host may have one of its interfaces facing a DNS service which resolves private names and addresses, as stated in . 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.

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 and , 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.

An address selection policy 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 , 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.

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.

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.

This document has no actions for IANA.

TBD

NAMES have provided input and suggestions to this document.

This document is intended to define the problem space discussed in the mif@ietf.org mailing list.