MIF Current Practice Analysis
draft-cao-mif-analysis-00

Abstract

This document presents the analysis of the problems encountered by a multi-homed host and the gap analysis of current solutions

Status of this Memo

This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and 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 September 3, 2010.

Copyright Notice

Copyright (c) 2010 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 BSD License.

Table of Contents

1.  Introduction
2.  Problem Analysis
    2.1.  Problems w.r.t. Naming and Addressing
    2.2.  Problems w.r.t. Routing
    2.3.  Problems w.r.t. Domain Selection
    2.4.  Problems w.r.t. Address Selection
    2.5.  Problems w.r.t. Configuration and Policy
3.  Security Considerations
4.  IANA Considerations
5.  Normative References
§  Authors' Addresses

1.  Introduction

A multihomed host have multiple provisioning domains via physical and/or virtual interfaces. A multihomed host receives node configuration information from each of its access networks, through various mechanisms such as DHCP, PPP and IPv6 Router Advertisements. When the received node-scoped configuration objects have different values from each administration 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.

Issues regarding how the multi-homed host uses the configuration objects have been addresses in [I.D‑MIF‑PS] (Blanchet, M. and P. Seite, “Multiple Interfaces Problem Statement,” Oct 2009.). Current practices of how the various implementations handle these problems are introduced in [I.D‑MIF‑CP] (Wasserman, M., “Current Practices for Multiple Interface Hosts,” December 2009.). This document presents the analysis of those problems as well as the gap analysis of the current practices.

2.  Problem Analysis

We divide the problems raised in [I.D‑MIF‑PS] (Blanchet, M. and P. Seite, “Multiple Interfaces Problem Statement,” Oct 2009.) into five categories as below.

2.1.  Problems w.r.t. Naming and Addressing

Problems with respect to naming and addressing are listed as below:

o

DNS server addresses and other configuration objects (NTP servers, ...) are usually node-scoped.

Note: DNS server addresses are domain scoped: (provided by e.g. DHCP) is only reachable as per routing entries from one provisioning domain and/or using source address from same provisioning domain. A solution is introduced in [I.D‑MIF‑DNS] (Savolainen, T., “DNS Server Selection on Multi-Homed Hosts,” February 2010.)

o

DNS answers are usually not kept with the interface from which the answer comes from.

Note: DNS answers are domain scoped: give addresses that are only reachable as per routing entries from one provisioning domain and/or using source address from same provisioning domain.

o

RFC1918 addresses are domain scoped.

Note: Nodes assumes global scope for IPv4 addresses: node assume that there's a single IPv4 addressing space while in reality there are many overlapping RFC1918 address spaces. Such RFC1918 addresses should be provisioning domain scoped when used as source or destination address. For examples it should be possible that a host has the same RFC1918 address assigned to two different interfaces (e.g., on two PDP context connected to two different APNs.)

2.2.  Problems w.r.t. Routing

Configuration with respect to routing is another issue for multiple homed hosts.

o

Routing tables are usually node-scoped, introducing the following problems:

a.

Routing tables are domain scoped: nodes have node-scoped or interface-scoped routing tables. This causes issues when node has two entries for same destination with same metric. There are also interactions with Addressing/a above in case there’s a route to an RFC1918 prefix e.g., 192.168.0.0/24.

b.

Ingress filtering: is an issue where connectivity is restricted to use of given source addresses from the provisioning domain

c.

Domain-scoped connectivity: many nodes assumes there is such a thing as internet connectivity, i.e., a default route on an interface allows to reach any destination. However there are walled gardens and APNs in the cellular world where connectivity through one provisioning domain is restricted to a set of destination and barred to others.

o

Host implementations usually do not implement the [RFC1122] model where the Type-of-Service are in the routing table.

Note: What would be needed is domain scoped routing tables.

o

Host implementations usually do not keep path characteristics, user or provider preferences in the routing table.

Note: Path characteristics would be useless absent an interface that let applications specify their QoS requirement. As to user/provider preferences, that can be done today in a routing table by playing with the routing metric.

2.3.  Problems w.r.t. Domain Selection

Application usually does not specify domain, how to select it? Is it per host default, or more dynamic selection based on e.g., result from name resolution and route lookup across multiple domains, and final selection based on what works?

Note: Some applications require domain affinity. There should be some way to set it either by the application itself or by the system on behalf of the application. Therefore the system should be cognizant of domains.

2.4.  Problems w.r.t. Address Selection

Address selection is issue for MIF-enabled nodes, including:

o

Default Address Selection policies are usually node-scoped.

Note: What would be needed it seems is domain scoped policies.

o

Default Address Selection policies may differ when received on different provisioning domains.

Note: What would be needed it seems is domain scoped policies.

o

Host implementations usually do not implement the [RFC1122] strong model where the source address is in the routing table.

Note: Having the source address in the routing table would avoid issues with ingress filtering. But this seems chicken and egg. Currently the source address selection occurs as a result of a route lookup. So it seems it makes more sense to first select a domain, then lookup the route in the domain-scoped route, and finally perform source address selection as per this domain policies.

o

Applications usually do not use advanced APIs to specify the source IP address or to set preferences on the address selection policies.

Note: having application specify source IP address is overkill. An application is primarily interested on connecting to a destination, thus it needs a connectivity provider. Once the connectivity provider has been selected the source address can be picked automatically as a result of the route lookup.

2.5.  Problems w.r.t. Configuration and Policy

Problems with respect to configuration and policy include:

o

Same configuration objects (e.g., DNS server addresses, NTP server addresses, ..) received from multiple provisioning domains are usually overwritten.

o

Host implementations usually do not keep separate network configuration (such as DNS server addresses) per provisioning domain.

o

There’s no way yet to handle multiple policies coming from different domains. E.g., corporate node usage typically means that the corporation issues some policy on that Wi-Fi interface (and others as well). In this case, the carrier and corporation domains and their policies will overlap over the Wi-Fi interface. Having a common policy language might help to detect and reason about such conflicts, but conflict resolution is another problem. Ultimately, the issue are the different authorities on these domains (e.g., “user” at home, admin at corporation and carrier for wireless broadband) and how they resolve their conflicts in the overlap situations.

Note: Domains and their policies may span multiple interfaces. There is a fixed hierarchy of domains and their authorities, but the top authority may decide to delegate to others certain parts of the system and to their policies, as long as these don't conflict with his. A conflict resolution that respects the hierarchy is needed.

3.  Security Considerations

TBD.

4.  IANA Considerations

This document does not require any IANA actions.

5. Normative References

Authors' Addresses