[Docs] [txt|pdf|xml|html] [Tracker] [Email] [Nits]

Versions: 00 01

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]


Html markup produced by rfcmarkup 1.129c, available from https://tools.ietf.org/tools/rfcmarkup/