MIF Working Group J. Laganier
Internet-Draft Qualcomm Inc.
Intended status: Informational G. Montenegro
Expires: September 2, 2010 Microsoft
J. Korhonen
Nokia Siemens Networks
T. Savolainen
Nokia
Z. Cao
China Mobile
March 1, 2010
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 2, 2010.
Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved.
Laganier, et al. Expires September 2, 2010 [Page 1]
Internet-Draft MIF Solution Analysis March 2010
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 . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Problem Analysis . . . . . . . . . . . . . . . . . . . . . . . 4
2.1. Problems w.r.t. Naming and Addressing . . . . . . . . . . 4
2.2. Problems w.r.t. Routing . . . . . . . . . . . . . . . . . 4
2.3. Problems w.r.t. Domain Selection . . . . . . . . . . . . . 5
2.4. Problems w.r.t. Address Selection . . . . . . . . . . . . 5
2.5. Problems w.r.t. Configuration and Policy . . . . . . . . . 6
3. Security Considerations . . . . . . . . . . . . . . . . . . . 8
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
5. Normative References . . . . . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11
Laganier, et al. Expires September 2, 2010 [Page 2]
Internet-Draft MIF Solution Analysis March 2010
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]. Current practices of
how the various implementations handle these problems are introduced
in [I.D-MIF-CP]. This document presents the analysis of those
problems as well as the gap analysis of the current practices.
Laganier, et al. Expires September 2, 2010 [Page 3]
Internet-Draft MIF Solution Analysis March 2010
2. Problem Analysis
We divide the problems raised in [I.D-MIF-PS] 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]
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
Laganier, et al. Expires September 2, 2010 [Page 4]
Internet-Draft MIF Solution Analysis March 2010
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.
Laganier, et al. Expires September 2, 2010 [Page 5]
Internet-Draft MIF Solution Analysis March 2010
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.
Laganier, et al. Expires September 2, 2010 [Page 6]
Internet-Draft MIF Solution Analysis March 2010
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.
Laganier, et al. Expires September 2, 2010 [Page 7]
Internet-Draft MIF Solution Analysis March 2010
3. Security Considerations
TBD.
Laganier, et al. Expires September 2, 2010 [Page 8]
Internet-Draft MIF Solution Analysis March 2010
4. IANA Considerations
This document does not require any IANA actions.
Laganier, et al. Expires September 2, 2010 [Page 9]
Internet-Draft MIF Solution Analysis March 2010
5. Normative References
[I.D-MIF-CP]
Wasserman, M., "Current Practices for Multiple Interface
Hosts", December 2009,
<draft-ietf-mif-current-practices-00.txt (work in
progress)>.
[I.D-MIF-DNS]
Savolainen, T., "DNS Server Selection on Multi-Homed
Hosts", February 2010,
<draft-savolainen-mif-dns-server-selection-02.txt (work in
progress)>.
[I.D-MIF-PS]
Blanchet, M. and P. Seite, "Multiple Interfaces Problem
Statement", Oct 2009,
<draft-ietf-mif-problem-statement-01.txt (work in
progress)>.
Laganier, et al. Expires September 2, 2010 [Page 10]
Internet-Draft MIF Solution Analysis March 2010
Authors' Addresses
Julien Laganier
Qualcomm Incorporated
5775 Morehouse Drive
San Diego, CA 92121
USA
Phone: +1 858 858 3538
Email: julienl@qualcomm.com
Gabriel Montenegro
Microsoft
Email: gmonte@microsoft.com
Jouni Korhonen
Nokia Siemens Networks
Linnoitustie 6
FI-02600 Espoo
FINLAND
Email: jouni.nospam@gmail.com
Teemu Savolainen
Nokia
Hermiankatu 12 D
FI-33720 Tampere
FINLAND
Email: teemu.savolainen@nokia.com
Zhen Cao
China Mobile
Email: zehn.cao@chinamobile.com
Laganier, et al. Expires September 2, 2010 [Page 11]