Subject: [MIPSHOP-MIH-DT] Version 20th Sept

From: Telemaco Melia <[email-masked]>
Date: Thu, 20 Sep 2007 19:44:53 +0200

Guys,

I removed section 6.6 since it is still controversial.
I would post if this fine with you.
tele

Mipshop WG                                                 T. Melia, Ed.
Internet-Draft                                                       NEC
Intended status: Standards Track                                G. Bajko
Expires: March 21, 2008                                            Nokia
                                                                  S. Das
                                                               Telcordia
                                                               N. Golmie
                                                                    NIST
                                                                  S. Xia
                                                                  Huawei
                                                              JC. Zuniga
                                                            InterDigital
                                                      September 18, 2007

              Mobility Services Transport Protocol Design
                  draft-melia-mipshop-mstp-solution-00

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 March 21, 2008.

Copyright Notice

   Copyright (C) The IETF Trust (2007).

Melia, et al.            Expires March 21, 2008                 [Page 1]

Internet-Draft                    MSTP                    September 2007

Abstract

   To be edited.

Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [RFC2119].

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  3
   3.  Deployment Scenarios . . . . . . . . . . . . . . . . . . . . .  4
   4.  Solution Overview  . . . . . . . . . . . . . . . . . . . . . .  6
     4.1.  Architecture . . . . . . . . . . . . . . . . . . . . . . .  6
     4.2.  MIHF Identifiers (FQDN, NAI) . . . . . . . . . . . . . . .  7
   5.  MoS Discovery  . . . . . . . . . . . . . . . . . . . . . . . .  7
     5.1.  MoS Discovery in the home network while attached to
           the home link  . . . . . . . . . . . . . . . . . . . . . .  8
     5.2.  MoS Discovery in the local network and Services are
           local  . . . . . . . . . . . . . . . . . . . . . . . . . .  9
     5.3.  MOS Discovery in a roaming Network and Services are at
           Home . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
     5.4.  MoS discovery in a remote network  . . . . . . . . . . . . 11
   6.  MIH Transport  . . . . . . . . . . . . . . . . . . . . . . . . 12
     6.1.  MIH Message size . . . . . . . . . . . . . . . . . . . . . 13
     6.2.  MIH Message rate . . . . . . . . . . . . . . . . . . . . . 13
     6.3.  Retransmission . . . . . . . . . . . . . . . . . . . . . . 14
     6.4.  NAT Traversal  . . . . . . . . . . . . . . . . . . . . . . 14
     6.5.  General guidelines . . . . . . . . . . . . . . . . . . . . 14
   7.  Operation Flows  . . . . . . . . . . . . . . . . . . . . . . . 14
   8.  Security Considerations  . . . . . . . . . . . . . . . . . . . 16
   9.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 17
   10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17
   11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
     11.1. Normative References . . . . . . . . . . . . . . . . . . . 17
     11.2. Informative References . . . . . . . . . . . . . . . . . . 19
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19
   Intellectual Property and Copyright Statements . . . . . . . . . . 21

Melia, et al.            Expires March 21, 2008                 [Page 2]

Internet-Draft                    MSTP                    September 2007

1.  Introduction

   This document proposes a solution to the issues identified in the
   problem statement document [I-D.ietf-mipshop-mis-ps] for the
   transport of IEEE 802.21 MIH protocols.

   The MIH Layer 3 transport problem is divided in two main parts: the
   discovery of mobility services (MoS) and the transport of the
   information between MN and MoS.  The discovery process is required
   for MIH function located in the MN to discover the peer MIHF (e.g.
   the IP address) of the MoS in the network (e.g. the Point of Service,
   PoS) either during attachment or during handover.  Upon successful
   discovery, the MIH peers can then exchange information in the form of
   MIH messages.

   This document considers firstly standard track IETF-based solutions
   for the design and recommendations of the discovery and transport
   protocol components.

2.  Terminology

   The following terminology is being used:

   MIH  Media Independent Handover

   MIHF  Media Independent Handover Function

   MIHF USER  MIH client initiating and terminating MIH signalling

   MIHFID  Media Independent Handover Function Identifier

   MoS  As defined in the problem statement document it includes IS, CS,
      ES services defined by the IEEE 802.21 standard.

   MoSh  Mobility Services assigned in the Home Network

   MoSv  Mobility Services assigned in the Visited Network

   MoS3  Mobility Services assigned in a 3rd Party Network

   MN Mobile Node

   NN Network Node

Melia, et al.            Expires March 21, 2008                 [Page 3]

Internet-Draft                    MSTP                    September 2007

3.  Deployment Scenarios

   The following scenarios have been identified:

   S1 Home Network MoS, the MN and the services are located in the home
      network.  We refer to this as MoSh as in Figure 1.

   +--------------+  +====+
   | HOME NETWORK |  |MoSh|
   +--------------+  +====+
        /\
        ||
        \/
   +--------+
   |   MN   |
   +--------+

                      Figure 1: MoS in the Home network

   S2 Visited Network MoS, MN is in the visited network and mobility
      services are also provided by the visited network.  We refer to
      this as MoSv ans in Figure 2.

             +--------------+
             | HOME NETWORK |
             +--------------+
                   /\
                   ||
                   \/
    +====+ +-----------------+
    |MoSv| | VISITED NETWORK |
    +====+ +-----------------+
                   /\
                   ||
                   \/
               +--------+
               |   MN   |
               +--------+

                    Figure 2: MoSV in the Visited Network

   S3 Roaming MoS, MN is in the visited network and all services are
      provided by the home network.

Melia, et al.            Expires March 21, 2008                 [Page 4]

Internet-Draft                    MSTP                    September 2007

    +====+   +--------------+
    |MoSh|   | HOME NETWORK |
    +====+   +--------------+
                   /\
                   ||
                   \/
          +-----------------+
          | VISITED NETWORK |
          +-----------------+
                   /\
                   ||
                   \/
               +--------+
               |   MN   |
               +--------+

             Figure 3: MoS provided by the home while in visited

   S4 Third party MoS, MN is in home or visited network and services are
      provided by a 3rd party network.  We refer to this as MoS3 as in
      Figure 4

                                      +--------------+
                                      | HOME NETWORK |
   +====+    +--------------+         +--------------+
   |MoS3|    | THIRD PARTY  |  <===>        /\
   +====+    +--------------+               ||
                                            \/
                                    +-----------------+
                                    | VISITED NETWORK |
                                    +-----------------+
                                            /\
                                            ||
                                            \/
                                        +--------+
                                        |   MN   |
                                        +--------+

                       Figure 4: MoS form a third party

   MoS can be provided independently and there is no strict relationship
   between ES, CS and IS.  However, while IS contain more a static sort
   of information, ES and CS are services of a dynamic nature and
   sometimes some relationships between them could be expected, e.g. a
   handover command could be issued upon reception of a link event.
   Hence, while in theory services can be implemented in different
   locations, it is expected that ES and CS will be collocated, whereas
   IS can either be collocated with ES/CS or not.  Therefore, having the

Melia, et al.            Expires March 21, 2008                 [Page 5]

Internet-Draft                    MSTP                    September 2007

   flexibility at the MSTP to discover different services in different
   locations is an important feature

4.  Solution Overview

   As mentioned in section Section 1 the solution space is being divided
   in discovery and transport.  The following assumptions have been
   made:

   o  The solution is aimed at supporting 802.21 MIH services, namely
      Information Services (IS), Event Services (ES), and Command
      Services (CS).

   o  If the MIHFID is available, FQDN or NAI's realm is used for
      mobility service discovery.  The recommendation to the IEEE 802.21
      WG is to restrict to only these two.

   o  The solutions are chosen to cover all possible deployment
      scenarios as described in section Section 3.

   o  MIHF discovery can be performed during initial network attachment
      or thereafter.

   For the discovering the location of an MoS, the MN could either be
   pre-configured with the address of the MoS, or this address could be
   dynamically assigned through DHCP or DNS by the network.  The dynamic
   assignation methods are described in section Section 5.

   The configuration of the MoS could be executed either upon network
   attachment or after successful IP configuration.  The methodology to
   be used depends on the considered deployment scenario.

   Once the MIHF peer has been discovered, MIH information can be
   exchanged between peers over UDP and TCP.  The usage of these
   protocols is described in section Section 6.

4.1.  Architecture

   The following Figure 5 depicts the MSTP reference model and its
   components within a node.

Melia, et al.            Expires March 21, 2008                 [Page 6]

Internet-Draft                    MSTP                    September 2007

    +--------------------------+
    |       MIHF USER          |
    +--------------------------+
                 ||
    +--------------------------+
    |           MIHF           |
    +--------------------------+
        ||         ||       ||
    +---------+ +------+ +-----+
    | TCP/UDP | | DHCP | | DNS |
    +---------+ +------+ +-----+

                            Figure 5: MN stack

   As it can be seen, the MIHF relies on the services provided by TCP
   and UDP for transport, as well as DHCP and DNS for peer discovery.
   In cases where peer MIHF IP address is not pre-configured, source
   MIHF needs to discover it either via DHCP or DNS or using a
   combination of both as described in Section 5.  Once peer MIHF is
   discovered, MIHF must exchange messages with its peer over either UDP
   or TCP.  Specific recommendations on choice of transport protocols
   are provided in section Section 6.

   The above reference architecture however does not provide the model
   for other services such as, fragmentation and security.  Depending
   upon the MIH services (e.g., ES, CS and IS) the message size can be
   very large.  In cases where underlying layer does not support
   fragmentation, this may be an issue.  There is no security available
   currently at the MIH protocol level.  However, security can be
   provided either at the transport or IP layer where it is necessary.
   Section Section 8 provides some guidelines and recommendations for
   security.

4.2.  MIHF Identifiers (FQDN, NAI)

   An MIHFID is an identifier required to uniquely identify the MIHF end
   points for delivering the mobility services (MoS).  Thus an MIHF
   identifier needs to be unique within a domain whereby mobility
   services are provided and invariant to interface IP addresses.  An
   MIHFID MUST be represented either in the form of an FQDN [RFC2181] or
   NAI [RFC2486].  An MIHFID can be pre-configured or discovered through
   the discovery methods as described in Section Section 5.

5.  MoS Discovery

   The MoS discovery method depends on whether the MN wants to discover
   an MoS in the local network, home network or a remote network other

Melia, et al.            Expires March 21, 2008                 [Page 7]

Internet-Draft                    MSTP                    September 2007

   than home network.

   In case MoS is provided locally (scenarios S1 and S2)
   [I-D.bajko-mos-dhcp-options] and [I-D.bajko-mos-dns-discovery] could
   be used to transfer MoS information from the network to the MN (via
   DHCP or DNS).  In case MoS is provided in the home while the MN is
   attached in visited (scenario S3) an interaction between the DHCP and
   AAA infrastructure is required similarly to what specified in
   [I-D.ietf-mip6-bootstrapping-integrated-dhc].  It is assumed
   therefore that MoS assignment is performed during access
   authentication and authorization.  In case MoS is provided in a
   remote network other than visited or home (scenario S4) only DNS
   based methods apply.

5.1.  MoS Discovery in the home network while attached to the home link

   To discover an MoS in the home network, the MN SHOULD use the DNS
   based MoS discovery method described in
   [I-D.bajko-mos-dns-discovery].  In order to use that, the MN MUST
   first find out the domain name of its home network.  Home domains are
   usually pre-configured in the MNs, thus the MN can simply read its
   configuration data to find out the home domain name (scenario S1).
   Alternatively, the MN MAY use the DHCP options for MoS
   discovery[I-D.bajko-mos-dhcp-options].  Figure 6 provides such model.

Melia, et al.            Expires March 21, 2008                 [Page 8]

Internet-Draft                    MSTP                    September 2007

                              +-------+
               +----+         |Domain |
               | MN |-------->|Name   |
               +----+         |Server |
                              +-------+
                [email-masked]

                             (a) using DNS Query

                            +-----+      +------+
               +----+       |     |      |DHCP  |
               | MN |<----->| DHCP|<---->|Server|
               +----+       |Relay|      |      |
                            +-----+      +------+

                             (b)  Using DHCP Option

    Figure 6: MOS Discovery (a) Using DNS query, (b) using DHCP option

5.2.  MoS Discovery in the local network and Services are local

   To discover an MoS in the visited network, the MN SHOULD attempt to
   use the DHCP options for MoS discovery [I-D.bajko-mos-dhcp-options].
   If the DHCP method fails, the MN SHOULD attempt to use the DNS based
   MoS discovery method described in [[I-D.bajko-mos-dns-discovery].  In
   order to use that, the MN MUST first learn the domain name of the
   local network.  There are a number of ways how the domain name of a
   network can be learned:

   DHCP --  In order to find out the domain name of the local network,
      the MN SHOULD use the dhcpv4 option 15 for learning the domain
      name [RFC1533].  Similar solution is available for dhcpv6
      [I-D.ietf-dhc-dhcpv6-opt-dnsdomain] .

   Reverse dns query --  When DHCP does not provide the required domain
      name, the MN MAY use reverse DNS (DNS PTR record) to find the
      domain name associated with the IP address it is using in the
      local network.  Note, that when a NAT device exists between the MN
      and the local network, the MN will first need to find out the
      external IP address of the NAT device.  Some possible methods for
      determining the NAT's external IP address are STUN [RFC3849] or
      UPnP [UPnP_IDG_DCP].  Once the MN determined the external IP
      address of the NAT device, it MUST use that address in the reverse
      DNS query.

Melia, et al.            Expires March 21, 2008                 [Page 9]

Internet-Draft                    MSTP                    September 2007

   Figure 7 provides such model.

                         +-----+      +------+
            +----+       |     |      |DHCP  |
            | MN |<----->| DHCP|<---->|Server|
            +----+       |Relay|      |      |
                         +-----+      +------+

                   (a) MOS Discovery using DHCP options

                           +-------+
            +----+         |Domain |
            | MN |-------->|Name   |
            +----+         |Server |
                           +-------+

                    (b) Reverse DNS Query (starting from the IP address)

         Figure 7: Discovery (a) using DHCP option, (b) Using DNS

5.3.  MOS Discovery in a roaming Network and Services are at Home

   To discover an MoS in the roaming network when services are provided
   by the home network MN SHOULD use the DHCP option along with network
   access authentication.  Upon network access authentication and
   interaction with the NAS the AAAh verifies in the AAA profile that
   the MN is allowed to use the MoS in home.  The AAAh assigns the MoS
   in the home and sends back the information to the NAS.  MN sends a
   DHCP information request as per [RFC3315] containing Home Network
   Identifier Option indicating the need to allocate the MoS in the
   home.  The relay agent intercepts the Information request from the MN
   and it forwards to the DHCP server inserting the MIH Relay Agent
   Option containing the info received by the AAAh.  The DHCP server can
   then reply to the MN by sending the Home Network Information Option.
   The MN receives the MoS address.

   It should be noted that the AAAh does not know what are the
   preferences of the MN, i.e. whether the MoS should be allocated in
   the home or in visited.  The MoS info is stored at the relay agent
   and forwarded to the MN according to the flags in the Home Network
   Identifier Option.  Figure 8 describes such a model.

Melia, et al.            Expires March 21, 2008                [Page 10]

Internet-Draft                    MSTP                    September 2007

                           Visited             |          Home
                                               |
                                               |
                           +-------+           |        +-------+
                           |       |           |        |       |
                           |AAAV   |-----------|--------|AAAH   |
                           |       |           |        |       |
                           |       |           |        |       |
                           +-------+           |        +-------+
                               |               |
                               |               |
                               |               |
                               |               |
                               |               |       +--------+
                               |               |       |        |
                               |               |       |  MoSh  |
                           +-----+    +------+ |       +--------+
               +----+      |     |    |DHCP  | |
               | MN |------| NAS/|----|Server| |
               +----+      | DHCP|    |      | |
                           |Relay|    |      | |
                           +-----+    +------+ |
                                               |

          AAAv -- Visited AAA
          AAAH -- Home AAA
          NAS  -- Network Access Server

   Figure 8: MOS Discovery using Network Access Authentication and DHCP
                                  options

5.4.  MoS discovery in a remote network

   To discover an MoS in a remote network other than home network, the
   MN MUST use the DNS based MoS discovery method described in
   [I-D.bajko-mos-dns-discovery].  In order to use that, the MN MUST
   first learn the domain name of the network it is looking for an MoS
   in.  If the MN does not yet know the domain name of the network,
   learning it may require more than one operation, as pre-configuration
   and DHCP methods can not be used.  The MN MAY attempt to first
   discover an MoS in either the local or home network (as in Figure 9
   part (a)) and query that MoS to find out the domain name of a
   specific network or the domain name of a network at a specific
   location (as in Figure 9 part (b)).  Alternatively, the MN MAY query
   an MoS previously known to learn the domain name of the desired
   network (e.g., via an IS Query).  Finally the MN can use DNS queries
   to find MoS in the remote network as inFigure 9 part(c).  It should

Melia, et al.            Expires March 21, 2008                [Page 11]

Internet-Draft                    MSTP                    September 2007

   be noted that step c can only be performed upon obtaining the domain
   name of the remote network.

                                   +-------+
                    +----+         |DHCP   |
                    | MN |-------->|       |
                    +----+         |Server |
                                   +-------+
                     [email-masked]

           (a) Discover MoS in local network with DHCP
                               +------------+
                +----+         |            |
                |    |         |Information |
                | MN |-------->| Server     |
                |    |         |(previously |
                +----+         |discovered) |
                               +------------+

      (b) Using IS query to find the FQDN on the remote network

                                 +-------+
                  +----+         |Domain |
                  | MN |-------->|Name   |
                  +----+         |Server |
                                 +-------+
                   [email-masked]

            (c) using DNS Query in the remote network

   Figure 9: MOS Discovery using (a) DNS Query, (b) IS Query to a known
                                  Server

6.  MIH Transport

   Once the Mobility Services have been discovered, MIH peers MUST
   exchange information over either TCP or UDP.  While either protocol
   can provide the basic transport functionality required, there are
   performance trade-offs and unique characteristics with each that need
   to be considered in the context of the MIH services for different
   network loss and congestion conditions.  Thus, the objectives of this
   section are to discuss these trade-offs for different MIH settings
   such as the MIH message size and rate, and the retransmission
   parameters.  In addition, factors such as NAT traversal are also
   discussed.  Given the reliability requirements for the MIH transport,
   it is assumed in this discussion that the MIH ACK mechanism is to be
   used in conjunction with UDP, while it is preferred to avoid using

Melia, et al.            Expires March 21, 2008                [Page 12]

Internet-Draft                    MSTP                    September 2007

   with TCP since TCP includes a similar functionality.

6.1.  MIH Message size

   Although the MIH message size varies widely from about 30 bytes (for
   a broadcast capability discovery request) to around 65000 bytes (for
   an IS MIH_Get_Information response primitive), a typical MIH message
   size for the ES/CS service ranges between 50 to100 bytes.  Thus,
   considering the effects of the MIH message size on the performance of
   the transport protocol brings us to discussing two main issues,
   related to fragmentation of long messages in the context of UDP and
   the concatenation of short messages in the context of TCP.  Since
   transporting long MIH messages may require fragmentation that is not
   available in UDP, using UDP a limit MUST be set on the size of the
   MIH message, unless fragmentation functionality is added to the MIH
   layer or IP layer fragmentation is used instead.  In this latter
   case, the loss of an IP fragment leads to the retransmission of an
   entire MIH message, which in turn leads to poor end-to-end delay
   performance in addition to wasted bandwidth utilization.  Additional
   recommendations in [I-D.ietf-tsvwg-udp-guidelines] apply for limiting
   the size of the MIH message when using UDP and assuming IP layer
   fragmentation.  In terms of dealing with short messages, TCP has the
   capability to concatenate very short messages in order to reduce the
   overall bandwidth overhead.  However, this reduced overhead comes at
   the cost of additional delay to complete an MIH transaction, which
   may not be acceptable for CS and ES services.

6.2.  MIH Message rate

   The frequency of MIH messages varies according to the MIH service
   type.  It is expected that CS/ES message arrive at a rate of one in
   hundreds of milliseconds in order to capture quick changes in the
   environment and/ or process handover commands.  On the other hand, IS
   messages are exchanged mainly every time a new network is visited
   which may be in order of hours or days.  Therefore a burst of either
   short CS/ES messages or long IS message exchanges (in the case of
   multiple MIH nodes requesting information) may lead to network
   congestion.  While the built-in rate-limiting controls available in
   TCP may be well suited for dealing with these congestion conditions,
   this may result in large transmission delays that may be unacceptable
   for the timely delivery of ES/CS messages.  On the other hand, if UDP
   is used, a rate-limiting effect similar to the one obtained with TCP
   may be obtained by adequately adjusting the token bucket parameters
   defined in the MIH specifications.  Recommendations for parameter
   settings are specific to the scenario considered.

Melia, et al.            Expires March 21, 2008                [Page 13]

Internet-Draft                    MSTP                    September 2007

6.3.  Retransmission

   For TCP, the retransmission timeout is adjusted according to the
   measured RTT.  However due to the exponential backoff mechanism, the
   retransmission timeouts may increase significantly with increased
   packet loss.

6.4.  NAT Traversal

   There are no known issues for NAT traversal when using TCP.  The
   default connection timeout of 24 hours is considered adequate for MIH
   transport purposes.  However, issues with NAT traversal using UDP are
   documented in [I-D.ietf-tsvwg-udp-guidelines].  Communication
   failures are experienced when middleboxes destroy the per-flow state
   associated with an application session during periods when the
   application does not exchange any UDP traffic.  Hence, communication
   between the MN and the MoS SHOULD be able to gracefully handle such
   failures and implement mechanisms to re-establish their UDP sessions.
   In addition and in order to avoid such failures, MIH messages MAY be
   sent periodically, similarly to keep-alive messages, to attempt to
   refresh middlebox state (e.g.  ES reports could be used for this
   purpose).  As [RFC4787] requires a minimum state timeout of two
   minutes or more, MIH messages using UDP as transport SHOULD be sent
   once every two minutes.

6.5.  General guidelines

   Since ES and CS messages are small in nature and have tight latency
   requirements, UDP in combination with MIH acknowledgement SHOULD be
   used for transporting ES and CS messages.  On the other hand, IS
   messages are more resilient in terms of latency constraints and some
   long IS messages could exceed the MTU of the path to the destination.
   Therefore, TCP SHOULD be used for transporting IS messages.  For both
   UDP and TCP cases, if a port number is not explicitly assigned (e.g.
   by the DNS SRV), MIH messages sent over UDP or TCP MUST use the
   default port number.

7.  Operation Flows

   Following Figure 10 gives an example operation flow between MIHF
   peers when an MIH user requests for an IS service.  Scenario 1 is
   chosen whereby DHCP is used for MoS discovery and TCP is used for
   establishing a transport connection.  When MOS is not pre-configured,
   MIH user needs to discover the IP address of MOS to communicate with
   the remote MIHF.  Therefore MIH user requests the local MIHF via a
   discovery message as defined in IEEE 802.21.

Melia, et al.            Expires March 21, 2008                [Page 14]

Internet-Draft                    MSTP                    September 2007

   In this example, we assume that MoS discovery is performed before a
   transport connection is established with the remote MIHF and the DHCP
   client process is invoked via some internal APIs.  DHCP Client sends
   DHCP INFORM message according to standard DHCP and with the MoS
   option as defines in [I-D.bajko-mos-dhcp-options].  DHCP server
   replies via DHCP ACK message with the IP address of the MoS.  The MOS
   address is then passed to the MIHF locally via some internal APIs.
   MIHF generates the discovery response message and passes it on to the
   corresponding MIH user.  MIH user then generates an IS query
   addressed to the remote MoS.  MIHF invokes the underlying TCP client
   which then establishes a transport connection with the remote peer.
   Once transport connection is available, MIHF sends the IS query via
   MIH protocol REQUEST message.  The message arrives to the destination
   MIHF and MIH user respectively.  MIH user responds to the
   corresponding IS query and the remote MIHF sends the IS response via
   MIH protocol RESPONSE message.  Thus it arrives to the source MIHF
   which passes it on to the corresponding MIH user.

                   MN                                             MoS
|======================================|    |======|   |======================|
+------+   +-----+   +------+  +------+     +------+   +------+  +----+  +----+
| MIH  |   |MIHF |   | TCP  |  |DHCP  |     |DHCP  |   | TCP  |  |MIHF|  |MIH |
| User |   |     |   |Client|  |Client|     |Server|   |Server|  |    |  |User|
+------+   +-----+   +------+  +------+     +------+   +------+  +----+  +----+
    |         |          |         |            |          |        |       |
    |Discovery|          |         |            |          |        |       |
    | Request |Invoke DHCP Client  |DHCP INFORM |          |        |       |
    |========>|===================>|===========>|          |        |       |
    |         |  (internal process)| with MOS   |          |        |       |
    |         |          |         | option     |          |        |       |
    |         |          |         |            |          |        |       |
    |         |          |         |   DHCP ACK |          |        |       |
    |         |          |         |<===========|          |        |       |
    |         | Inform MoS address |            |          |        |       |
    |         |<===================|            |          |        |       |
    |         | (internal process) |            |          |        |       |
    |Discovery|          |         |            |          |        |       |
    |response |          |         |            |          |        |       |
    |<========|          |         |            |          |        |       |
    |         |          |         |            |          |        |       |
    |IS Query |          |         |            |          |        |       |
    |========>|          |         |            |          |        |       |
    |         |          |         |            |          |        |       |
    |         |Invoke TCP|         |            |          |        |       |
    |         |=========>|         |            |          |        |       |
    |         | client   |    TCP connection established    |        |       |
    |         |          |<===============================>|        |       |
    |         |          |         |            |          |        |       |

Melia, et al.            Expires March 21, 2008                [Page 15]

Internet-Draft                    MSTP                    September 2007

    |         |          |         |            |          |        |       |
    |         |          |         |            |          |        |       |
    |         |          | IS  QUERY REQUEST (via MIH protocol)     |       |
    |         |====================================================>|       |
    |         |          |         |             |         |        |IS     |
    |         |          |         |             |         |        |QUERY  |
    |         |          |         |             |         |        |REQUEST|
    |         |          |         |             |         |        |======>|
    |         |          |         |             |         |        |       |
    |         |          |         |             |         |        |QUERY  |
    |         |          |         |             |         |        |RESPONSE
    |         |          |         |             |         |        |<======|
    |         |          |         |             |         |        |       |
    |         |          |  IS QUERY RESPONSE (via MIH protocol)    |       |
    |         |<====================================================|       |
    |         |          |         |             |         |        |       |
    |    IS   |          |         |             |         |        |       |
    |RESPONSE |          |         |             |         |        |       |
    |<========|          |         |             |         |        |       |
    |         |          |         |             |         |        |       |
    |         |          |         |             |         |        |       |

          Figure 10: Example Flow of Operation Involving MIH User

8.  Security Considerations

   There are a number of security issues that need to be taken into
   account during node discovery and information exchange via a
   transport connection [I-D.ietf-mipshop-mis-ps]

   In case where DHCP is used for node discovery and authentication of
   the source and content of DHCP messages are required, it is
   recommended that network administrators should use DHCP
   authentication option described in [RFC3118].  This will also protect
   the denial of service attacks to DHCP server.[RFC3118] provides
   mechanisms for both entity authentication and message authentication.

   In case where DNS is used for discovering MoS, fake DNS requests and
   responses may cause DoS and the inability of the MN to perform a
   proper handover, respectively.  Where networks are exposed to such
   DoS, it is recommended that DNS service providers use the Domain Name
   System Security Extensions (DNSSEC) as described in [RFC4033].
   Readers may also refer to
   [I-D.ietf-dnsop-dnssec-operational-practices] to consider the aspects
   of DNSSEC Operational Practices.

   In case where reliable transport protocol such as TCP is used for

Melia, et al.            Expires March 21, 2008                [Page 16]

Internet-Draft                    MSTP                    September 2007

   transport connection between two MIHF peers, TLS [RFC4346] should be
   used for message confidentiality and data integrity.  In particular,
   TLS is designed for client/server applications and to prevent
   eavesdropping, tampering, or message forgery.  Readers should also
   follow the recommendations in [RFC4366] that provides generic
   extension mechanisms for the TLS protocol suitable for wireless
   environments.

   In case where unreliable transport protocol such as UDP is used for
   transport connection between two MIHF peers, DTLS [RFC4347] should be
   used for message confidentiality and data integrity.  The DTLS
   protocol is based on the Transport Layer Security (TLS) protocol and
   provides equivalent security guarantees.

   Alternatively, generic IP layer security, such as IPSec [RFC2401] may
   be used instead of a specific transport layer secuity for a specific
   transport.

9.  IANA Considerations

   This document registers the following TCP and UDP port(s) with IANA:

 Keyword        Decimal    Description
 -------        -------    -----------
 ieee-mih-IS    XXX/tcp    IEEE Media Independent Handover (MIH)Protocol
 ieee-mih-IS    XXX/udp    IEEE Media Independent Handover (MIH)Protocol
 ieee-mih-ES    XXX/tcp    IEEE Media Independent Handover (MIH)Protocol
 ieee-mih-ES    XXX/udp    IEEE Media Independent Handover (MIH)Protocol
 ieee-mih-CS    XXX/tcp    IEEE Media Independent Handover (MIH)Protocol
 ieee-mih-CS    XXX/udp    IEEE Media Independent Handover (MIH)Protocol

10.  Acknowledgements

   The authors would like to thank Patrick Stupar for his valuable
   comments and fruitful discussions.

11.  References

11.1.  Normative References

   [I-D.bajko-mos-dhcp-options]
              Bajko, G., "Dynamic Host Configuration Protocol (DHCPv4
              and DHCPv6) Options for Mobility  Servers (MoS)",
              draft-bajko-mos-dhcp-options-00 (work in progress),
              August 2007.

Melia, et al.            Expires March 21, 2008                [Page 17]

Internet-Draft                    MSTP                    September 2007

   [I-D.bajko-mos-dns-discovery]
              Bajko, G., "Locating Mobility Servers",
              draft-bajko-mos-dns-discovery-00 (work in progress),
              August 2007.

   [I-D.ietf-dhc-dhcpv6-opt-dnsdomain]
              Yan, R., "Domain Suffix Option for DHCPv6",
              draft-ietf-dhc-dhcpv6-opt-dnsdomain-04 (work in progress),
              June 2007.

   [I-D.ietf-dnsop-dnssec-operational-practices]
              Gieben, R. and O. Kolkman, "DNSSEC Operational Practices",
              draft-ietf-dnsop-dnssec-operational-practices-08 (work in
              progress), March 2006.

   [I-D.ietf-mip6-bootstrapping-integrated-dhc]
              Chowdhury, K. and A. Yegin, "MIP6-bootstrapping for the
              Integrated Scenario",
              draft-ietf-mip6-bootstrapping-integrated-dhc-05 (work in
              progress), July 2007.

   [I-D.ietf-mipshop-mis-ps]
              Melia, T., "Mobility Services Transport: Problem
              Statement", draft-ietf-mipshop-mis-ps-03 (work in
              progress), August 2007.

   [I-D.ietf-tsvwg-udp-guidelines]
              Eggert, L. and G. Fairhurst, "UDP Usage Guidelines for
              Application Designers", draft-ietf-tsvwg-udp-guidelines-03
              (work in progress), September 2007.

   [RFC1533]  Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor
              Extensions", RFC 1533, October 1993.

   [RFC1536]  Kumar, A., Postel, J., Neuman, C., Danzig, P., and S.
              Miller, "Common DNS Implementation Errors and Suggested
              Fixes", RFC 1536, October 1993.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC2132]  Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor
              Extensions", RFC 2132, March 1997.

   [RFC2181]  Elz, R. and R. Bush, "Clarifications to the DNS
              Specification", RFC 2181, July 1997.

   [RFC2401]  Kent, S. and R. Atkinson, "Security Architecture for the

Melia, et al.            Expires March 21, 2008                [Page 18]

Internet-Draft                    MSTP                    September 2007

              Internet Protocol", RFC 2401, November 1998.

   [RFC2486]  Aboba, B. and M. Beadles, "The Network Access Identifier",
              RFC 2486, January 1999.

   [RFC2988]  Paxson, V. and M. Allman, "Computing TCP's Retransmission
              Timer", RFC 2988, November 2000.

   [RFC3118]  Droms, R. and W. Arbaugh, "Authentication for DHCP
              Messages", RFC 3118, June 2001.

   [RFC3315]  Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C.,
              and M. Carney, "Dynamic Host Configuration Protocol for
              IPv6 (DHCPv6)", RFC 3315, July 2003.

   [RFC3849]  Huston, G., Lord, A., and P. Smith, "IPv6 Address Prefix
              Reserved for Documentation", RFC 3849, July 2004.

   [RFC4033]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
              Rose, "DNS Security Introduction and Requirements",
              RFC 4033, March 2005.

   [RFC4346]  Dierks, T. and E. Rescorla, "The Transport Layer Security
              (TLS) Protocol Version 1.1", RFC 4346, April 2006.

   [RFC4347]  Rescorla, E. and N. Modadugu, "Datagram Transport Layer
              Security", RFC 4347, April 2006.

   [RFC4366]  Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J.,
              and T. Wright, "Transport Layer Security (TLS)
              Extensions", RFC 4366, April 2006.

   [RFC4787]  Audet, F. and C. Jennings, "Network Address Translation
              (NAT) Behavioral Requirements for Unicast UDP", BCP 127,
              RFC 4787, January 2007.

11.2.  Informative References

Authors' Addresses

   Telemaco Melia (editor)
   NEC

   Email: [email-masked]

Melia, et al.            Expires March 21, 2008                [Page 19]

Internet-Draft                    MSTP                    September 2007

   Gabor Bajko
   Nokia

   Email: [email-masked]

   Subir Das
   Telcordia

   Email: [email-masked]

   Nada Golmie
   NIST

   Email: [email-masked]

   Sam Xia
   Huawei

   Email: [email-masked]

   Juan Carlos Zuniga
   InterDigital

   Email: [email-masked]

Melia, et al.            Expires March 21, 2008                [Page 20]

Internet-Draft                    MSTP                    September 2007

Full Copyright Statement

   Copyright (C) The IETF Trust (2007).

   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
   [email-masked].

Acknowledgment

   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).

Melia, et al.            Expires March 21, 2008                [Page 21]


_______________________________________________
MIPSHOP-MIH-DT mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mipshop-mih-dt

---

From: <[email-masked]>
Date: Thu, 20 Sep 2007 14:07:45 -0500

Looks fairly good to me. Could you please submit it?

THANKS!
- gabor 

-----Original Message-----
From: ext Telemaco Melia [mailto:[email-masked]] 
Sent: Thursday, September 20, 2007 10:45 AM
To: [email-masked]
Subject: [MIPSHOP-MIH-DT] Version 20th Sept

Guys,

---

From: "Zuniga, Juan Carlos" <[email-masked]>
Date: Thu, 20 Sep 2007 15:12:08 -0400

Thanks Tele!

Just one minor editorial improvement:

9.  IANA Considerations

 Keyword        Decimal    Description
 -------        -------    -----------
 ieee-mih-IS    XXX/tcp    Media Independent Handover Information
Services
 ieee-mih-IS    XXX/udp    Media Independent Handover Information
Services
 ieee-mih-ES    XXX/tcp    Media Independent Handover Event Services
 ieee-mih-ES    XXX/udp    Media Independent Handover Event Services
 ieee-mih-CS    XXX/tcp    Media Independent Handover Command Services
 ieee-mih-CS    XXX/udp    Media Independent Handover Command Services

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Thursday, September 20, 2007 9:08 AM
To: [email-masked]; [email-masked]
Subject: RE: [MIPSHOP-MIH-DT] Version 20th Sept

THANKS!
- gabor 

-----Original Message-----
From: ext Telemaco Melia [mailto:[email-masked]] 
Sent: Thursday, September 20, 2007 10:45 AM
To: [email-masked]
Subject: [MIPSHOP-MIH-DT] Version 20th Sept

Guys,

---

From: Subir Das <[email-masked]>
Date: Thu, 20 Sep 2007 15:24:15 -0400

Fine with me too. If we find additional issues, we can always submit
another version before the IETF deadline.

Thanks,
-Subir

Telemaco Melia wrote:
> ------------------------------------------------------------------------
>

---

From: Nada Golmie <[email-masked]>
Date: Thu, 20 Sep 2007 15:38:11 -0400

Looks good to me...
-Nada

-- 
Nada Golmie, Ph.D. 
Manager, High Speed Network Technologies Group
National Institute of Standards and Technology
100 Bureau Dr. Stop 8920
Gaithersburg, MD 20899
Email: [email-masked]
Phone: (301) 975-4190
Fax:   (301) 590-0932
Web: http://w3.antd.nist.gov

---

From: Sam Xia <[email-masked]>
Date: Fri, 21 Sep 2007 08:46:59 +0800

fine. some editorial issues should be updated next verion.

 Best Regards, Sam Xia 

> From: Zuniga, Juan Carlos [mailto:[email-masked]] 
> Sent: Friday, September 21, 2007 3:12 AM
> To: [email-masked]; [email-masked]; [email-masked]

---

From: <[email-masked]>
Date: Thu, 20 Sep 2007 21:12:06 -0500

I presented some design principles today in .21, and I got a few
comments:

- the term MoS is not good, we need to find a better one
- scenario 4 only applies to IS, not to ES/CS, we should point this out
- scenario 3 is similar to the integrated scenario. Terminology should
be aligned with it. We should consider the split scenario as well (ie
when there is no AAA infra).
- for security and transport, we should not only recommend, but mandate
one, at least for the server side (eg mandate TCP and TLS for IS).
- some reasons why we chose to recommend (D)TLS. Eg, middlebox traversal
- we should not exclude any transport, but allow transport discovery and
the use of any transport (maybe not applicable for the use of UDP for
IS)

Subir, JC, anything else I did not capture?

- gabor

---

From: "Zuniga, Juan Carlos" <[email-masked]>
Date: Thu, 20 Sep 2007 22:29:38 -0400

- The 100ms message rate for ES/CS seems to be high and we should
clarify that it is only during critical phases (e.g. HO) that this would
happen.

- The power save issues imposed by the middlebox traversal (i.e. NAT)
applies not only to UDP but also to TCP and SCTP

- Not clear to some people why scenario 3 cannot be solved with DNS

Jc

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: September 20, 2007 4:12 PM
To: [email-masked]
Subject: [MIPSHOP-MIH-DT] Comments to the design of the drafts so far

- gabor