Subject: [MIPSHOP-MIH-DT] Current version -- Fri 07

From: Telemaco Melia <[email-masked]>
Date: Fri, 07 Sep 2007 18:01:58 +0200

Guys,

This is the latest version while I am still working on it.
Section is still incomplete. Also I need you contact info and the input 
for the IANA section.
Please go thought the doc and send me any comment/change to be applied.

thanks
tele

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

              Mobility Services Transport Protocol Design
                   draft-xxx-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 January 25, 2008.

Copyright Notice

   Copyright (C) The IETF Trust (2007).

Melia, et al.           Expires January 25, 2008                [Page 1]

Internet-Draft                    MSTP                         July 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 . . . . . . . . . . . . . . . . . . . . .  3
   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  . . . . . . . . . . . .  8
     5.2.  MoS Discovery in the local network and Services are
           local  . . . . . . . . . . . . . . . . . . . . . . . . . .  8
     5.3.  MOS Discovery in a roaming Network and Services are at
           Home . . . . . . . . . . . . . . . . . . . . . . . . . . .  9
     5.4.  MoS discovery in a remote network  . . . . . . . . . . . . 10
   6.  MIH Transport  . . . . . . . . . . . . . . . . . . . . . . . . 11
     6.1.  MIH Message size . . . . . . . . . . . . . . . . . . . . . 11
     6.2.  MIH Message rate . . . . . . . . . . . . . . . . . . . . . 12
     6.3.  Retransmission . . . . . . . . . . . . . . . . . . . . . . 12
     6.4.  NAT Traversal  . . . . . . . . . . . . . . . . . . . . . . 13
     6.5.  General guidelines . . . . . . . . . . . . . . . . . . . . 13
   7.  Operation Flows  . . . . . . . . . . . . . . . . . . . . . . . 13
   8.  Security Considerations  . . . . . . . . . . . . . . . . . . . 16
   9.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 17
   10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17
   11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
     11.1. Normative References . . . . . . . . . . . . . . . . . . . 17
     11.2. Informative References . . . . . . . . . . . . . . . . . . 18
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18
   Intellectual Property and Copyright Statements . . . . . . . . . . 21

Melia, et al.           Expires January 25, 2008                [Page 2]

Internet-Draft                    MSTP                         July 2007

1.  Introduction

   This document proposes a solution to the issues indetified 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 succesfull
   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

   MIHFID  Media Independent Handover Function Identifier

   MoS  As defined in the problem statement documetn 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

3.  Deployment Scenarios

   The following scenarios have been identified:

Melia, et al.           Expires January 25, 2008                [Page 3]

Internet-Draft                    MSTP                         July 2007

   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 Visisted 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 January 25, 2008                [Page 4]

Internet-Draft                    MSTP                         July 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
      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 January 25, 2008                [Page 5]

Internet-Draft                    MSTP                         July 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 follwoing 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 recommentdation to the IEEE
      802.21 WG is to restrict to only these two.

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

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

   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
   dynamilcally 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 succesfull 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 January 25, 2008                [Page 6]

Internet-Draft                    MSTP                         July 2007

    +--------------------------+
    |           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 preconfigured, 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 protcol level.  However, security can be
   provided either at the transport or IP layer where it is necessary.
   Section Section 8 provides some guidelines and recommedations 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
   than home network.

Melia, et al.           Expires January 25, 2008                [Page 7]

Internet-Draft                    MSTP                         July 2007

5.1.  MoS Discovery in the home network

   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 preconfigured 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.

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

                             (a) using DNS Query

                            +-----+      +------+
               +----+       |NAS/ |      |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
      [draft-ietf-dhc-dhcpv6-opt-dnsdomain].

Melia, et al.           Expires January 25, 2008                [Page 8]

Internet-Draft                    MSTP                         July 2007

   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 [RFC3489] 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.

   Figure 7 provides such model.

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

                      (a) MOS Discovery using DHCP options

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

                       (b) Reverse DNS Query

         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 authnetication (e.g.  DHCP/AAA).  MN SHOULD use the dhcp
   options for MoS discovery [I-D.bajko-mos-dhcp-options] immediately
   after the network access authentication.  Figure 8 describes the such
   a model.

Melia, et al.           Expires January 25, 2008                [Page 9]

Internet-Draft                    MSTP                         July 2007

                           Visited             |          Home
                                               |
                                               |
                           +-------+           |        +-------+
                           |       |           |        |       |
                           |AAAV   |-----------|--------|AAAH   |
                           |       |           |        |       |
                           |       |           |        |       |
                           +-------+           |        +-------+
                               |               |
                               |               |
                               |               |
                               |               |
                               |               |       +--------+
                               |               |       |        |
                               |               |       |  MoSh  |
                           +-----+    +------+ |       +--------+
               +----+      |     |    |DHCP  | |
               | MN |------| NAS/|----|Server| |
               +----+      |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 can not be used.  The MN MAY attempt to first discover an
   MoS in either the local or home network 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.  Alternatively, the MN MAY query an
   MoS previously known to learn the domain name of the desired network
   (e.g., via an IS Query).  Figure 9 shows the presented mechanism.

Melia, et al.           Expires January 25, 2008               [Page 10]

Internet-Draft                    MSTP                         July 2007

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

                    (a) using DNS Query

                              +------------+
               +----+         |            |
               |    |         |Information |
               | MN |-------->| Server     |
               |    |         |(previously |
               +----+         |  Known)    |
                              +------------+
                    (b) Using IS query

   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
   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

Melia, et al.           Expires January 25, 2008               [Page 11]

Internet-Draft                    MSTP                         July 2007

   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.

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.  For UDP, the MIH ACK provides a certain level of
   reliability and the maximum retransmission is set to 2.  The MIHF has
   control over the retransmission timeout, which SHOULD be set greater
   than RTT.  Recommendations in [RFC1536], [RFC2988] and
   [I-D.ietf-tsvwg-udp-guidelines] about estimating the RTT when using
   UDP apply.

   Also, retransmitting at the MIHF by using UDP in combination with MIH
   acknowledgements allows having a better control and knowledge of

Melia, et al.           Expires January 25, 2008               [Page 12]

Internet-Draft                    MSTP                         July 2007

   these retransmissions.  For instance, in case of retransmitting ES
   messages such as measurements, the MIHF could decide whether to
   retransmit the same old measurement information or to transmit an
   updated measurement in case that this new measurement is already
   available.

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

Melia, et al.           Expires January 25, 2008               [Page 13]

Internet-Draft                    MSTP                         July 2007

                           MIH ENABLED MN
        +---------------+     +-------------+
        |  DHCP SERVER  |     | DHCP CLIENT |
        +---------------+     +------|------+
                |                    |
                |    DHCP DISCOVER   |
                |<===================|DHCP DISCOVER
                |                    |WITH MoS option
                |                    |
                |    DHCP OFFER      |
                |===================>|DHCP OFFER
                |                    |WITH MoS
                |   DHCP REQUEST     |
                |<===================|
                |     DHCPACK        |
                |===================>|
                |                    |

               Using DHCP 4-way handshake

                    Figure 10: Discovering MoS function

   Upon layer-two network attachement the MN broadcasts DHCP DISCOVER
   messages according to standard [RFC2132].  According to standard
   behavior the MN can wait to receive multiple replies from DHCP
   servers.  In any case the MN adds the MoS option to the discover
   message.  The DHCP offer message will then contain the IP address of
   the MoS.

Melia, et al.           Expires January 25, 2008               [Page 14]

Internet-Draft                    MSTP                         July 2007

                             MIH ENABLED MN
       +---------------+     +-------------+
       |  DHCP SERVER  |     | DHCP CLIENT |
       +---------------+     +------|------+
               |                    |
               |    DHCP INFORM     |
               |<===================|DHCP INFORM
               |                    |WITH MoS option
               |     DHCPACK        |
               |===================>|
               |                    |

             Using DHCP 2-way handshake

                Figure 11: Discovering MoS Function (MIHF)

   Figure 11shows the 2 way handshake operation with MoS option enabled.

   For DHCPv6 based solutions we should distinguish between having
   stateless autoconfiguration and DHCP two messages based exchange or
   stateful configuration, thus four messages based exchange.  The
   follwoing figure shows how discovery of the MoS can be done through
   the first method.

      +--------------+     +--------------+
      |  DHCP CLIENT |     |  DHCP SERVER |
      +------|-------+     +-------|------+
             |                     |
             |                     |
             | INFORMATION-REQUEST |
             |====================>|
             |                     |
             |   REPLY             |
             |<====================|
             |                     |
             |                     |

                  Figure 12: DHCPv6 two messages exchange

   The INFORMATION REQUEST message is sent to the multicast FF02::1:2
   address containing an "Option Request" option.  Based on the "Client
   identifier" option the DHCP server can send a REPLY message including
   the option requested by the client.  In this case the option will
   refer to the MoS IP address being discovered.

   Figure 10, Figure 11and (Figure 12) meet the requirements imposed by
   scenarios S1 and S2.  S3 needs tight interaction with the AAA
   infrastructure and Figure 13 captures such a case.

Melia, et al.           Expires January 25, 2008               [Page 15]

Internet-Draft                    MSTP                         July 2007

   +-----------+        +----------------+   +----------+    +----------------+
   |    MN     |        |Access Gateway/ |   |  DHCP    |    |                |
   |DHCP Client|        |DHCP Relay      |   |  Server  |    |Home AAA Server |
   +----|------+        +------|---------+   +----|------+   +-------|--------+
        |                      |                  |                  |
        | Access Authentication| Access Authentica|tion Request      |
        |  Request with NAI    | forwarded to Home| Domain           |
        |=====================>|==================|=================>|
        |                      |                  |                  |
        |                      | Access Autneticat|ion success       |
        |Authentication Success| with MoS informat|ion               |
        |<=====================|<=================|==================|
        |                      |                  |                  |
        |    DHCP DISCOVER     |                  |                  |
        |  with MOS option     |                  |                  |
        |=====================>|=================>|                  |
        |                      |                  |                  |
        |    DHCP OFFER        |                  |                  |
        | with MOS information |                  |                  |
        |<=====================|<=================|                  |
        |                      |                  |                  |
        |   DHCP REQUEST       |                  |                  |
        |======================|=================>|                  |
        |                      |                  |                  |
        |   DHCPACK            |                  |                  |
        |<=====================|==================|                  |
        |                      |                  |                  |
        |                      |                  |                  |

      Figure 13: Discovering MoS Function (MIHF) coupled with Network
                           Access Authentication

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 [refer PS draft]

   In case where DHCP is used for node discovery and authentication of
   the source and content of DHCP messages are required, it is
   receommended 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 the IP address of the MIHF
   and mobility services and data origin authentication and data

Melia, et al.           Expires January 25, 2008               [Page 16]

Internet-Draft                    MSTP                         July 2007

   integrity are required it is recommended that DNS service providers
   should use the Domain Name System Security Extensions (DNSSEC) as
   decsribed in [RFC4033].  Readers may also refer to
   [I-D.ietf-dnsop-dnssec-operational-practices] to consider the aspects
   of DNSSEC Operational Practices.

9.  IANA Considerations

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

   discard XXX/mih Discard YY:ZZZ

10.  Acknowledgements

   ....

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.

   [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-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-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-02
              (work in progress), July 2007.

Melia, et al.           Expires January 25, 2008               [Page 17]

Internet-Draft                    MSTP                         July 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.

   [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.

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

   [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

   Phone:
   Fax:
   Email:
   URI:

Melia, et al.           Expires January 25, 2008               [Page 18]

Internet-Draft                    MSTP                         July 2007

   Sam Xia
   Huawei

   Phone:
   Fax:
   Email:
   URI:

   Nada Golmie
   NIST

   Phone:
   Fax:
   Email:
   URI:

   Subir Das
   Telcordia

   Phone:
   Fax:
   Email:
   URI:

   Gabor Bajko
   Nokia

   Phone:
   Fax:
   Email:
   URI:

Melia, et al.           Expires January 25, 2008               [Page 19]

Internet-Draft                    MSTP                         July 2007

   Juan Carlos Zuniga
   InterDigital

   Phone:
   Fax:
   Email:
   URI:

Melia, et al.           Expires January 25, 2008               [Page 20]

Internet-Draft                    MSTP                         July 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 January 25, 2008               [Page 21]


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

---

From: <[email-masked]>
Date: Fri, 7 Sep 2007 15:59:36 -0500

A few issues:

- the diagrams in 5.1 do not seem to have too much value
- something does not make sense to me around 5.2 and 5.3: did you want
to say that the MN may discover MoS locally or in its home network while
roaming? If yes, then I guess in fig 8 the dhcp server box has to be in
the home network.
- in 5.4 figure 9a is not right. You either show all the steps, ie the
MN queries the DNS to find an MoS locally, then queries that MoS to find
the domain name of a network at a specific location and then gets to the
dns based MoS discovery, or you don't show any.

- I just realised that we did not address transport security. We should
have some text recommending the usage of TSL/DTLS depending on the
transport.

- figures 10, 11, 12 do not have much value. 

- figure 13: the figure is not good, because it does not tell in which
network the dhcp server is: local or home. There is also no explanation
on why auth happens and why the whole discovery is coupled with NAA.

- security considerations: it only addresses the security regarding
discovery. Let's re-formulate this part: "In case where DNS is used for
discovering the IP address of the MIHF and mobility services and data
origin authentication and data ..." to "In case where DNS is used for
discovering MoS, fake DNS responses may cause DoS and the inability of
the MN to perform a proper handover. Where networks are exposed to such
DoS, it is RECOMMENDED that DNS service providers use the Domain Name
System Security Extensions (DNSSEC) as decsribed in [RFC4033].  Readers
may also refer to [I-D.ietf-dnsop-dnssec-operational-practices] to
consider the aspects of DNSSEC Operational Practices. " The previous two
paragraphs are ok.

- the transport layer security recommandations could be added either to
the security section or to the transport section (section 6).

- none of the examples show user data flows.

- most of the added references are not referenced anywhere in the draft.
It has to be either referenced or removed from the references section.

- I would remove those phone, fax, uri lines from the author's
addresses.

I do not see a need for a teleconf before we fix these issues. Tele,
could you produce a new version capturing as much as you can from the
above during the weekend or should I do it?

- gabor

-----Original Message-----
From: ext Telemaco Melia [mailto:[email-masked]] 
Sent: Friday, September 07, 2007 9:02 AM
To: [email-masked]
Subject: [MIPSHOP-MIH-DT] Current version -- Fri 07

Guys,

thanks
tele

---

From: Subir Das <[email-masked]>
Date: Fri, 07 Sep 2007 17:59:53 -0400

Gabor,
My comments inline.

thanks,
_Subir

> - the diagrams in 5.1 do not seem to have too much value
     Fig 5.1 is just a representation of text. If it does not add value, 
we can delete it.
> roaming? If yes, then I guess in fig 8 the dhcp server box has to be in
    In 5.2 it is discovering MoS locally. In 5.3, it is discovering 
locally but MoS is assigned by home. I do not
    understand your point of having DHCP server at the home. NAS 
receives the MoS address from
    home AAA during access authentication. DHCP relay needs to have an 
option similar to MIPv6 HA
   option to pass the information to DHCP Server along with DHCP 
request. I think Tele had an earlier
   question, do we need to have this integrated scenario? If so, we need 
to define additional options.
> dns based MoS discovery, or you don't show any.
     I agree. We need to add one more step here.
> have some text recommending the usage of TSL/DTLS depending on the
     Yes, I was supposed to send some texts on this. Will do that.
> - figures 10, 11, 12 do not have much value. 
     I thought you all have agreed upon to keep the protocol operation 
flows and move it to Section 7 during
     last telecon.
> on why auth happens and why the whole discovery is coupled with NAA.
    As mentioned earlier, DHCP server is not in the home. It is in the 
visited network. We can explain
    the steps. However, we need to define some additional DHCP options 
to support this case.
> consider the aspects of DNSSEC Operational Practices. " The previous two
   Fine.
> the security section or to the transport section (section 6).
    We can keep all security related recommendations in section 8.
> - none of the examples show user data flows.
    Are you referring to MIH users?
> It has to be either referenced or removed from the references section.
    We need to fix it.
> - I would remove those phone, fax, uri lines from the author's
     Fine with me.

---

From: <[email-masked]>
Date: Fri, 7 Sep 2007 17:24:33 -0500

Subir,
My comments inline: 

-----Original Message-----
From: ext Subir Das [mailto:[email-masked]] 
Sent: Friday, September 07, 2007 3:00 PM
To: Bajko Gabor (Nokia-SIR/MtView)
Cc: [email-masked]; [email-masked]
Subject: Re: [MIPSHOP-MIH-DT] Current version -- Fri 07

Gabor,
My comments inline.

thanks,
_Subir

> to say that the MN may discover MoS locally or in its home network 
> while roaming? If yes, then I guess in fig 8 the dhcp server box has 
> to be in the home network.
>   

<gabor> ok, I am closer to understand now. But we need to include this
kind of explanation into the draft. We write a document for broader
audience, not a puzzle :)
Also, the use case or benefit of such thing should be added there.

> MN queries the DNS to find an MoS locally, then queries that MoS to 
> find the domain name of a network at a specific location and then gets

> to the dns based MoS discovery, or you don't show any.
>   
> - I just realised that we did not address transport security. We 
> should have some text recommending the usage of TSL/DTLS depending on 
> the transport.
>   

> network the dhcp server is: local or home. There is also no 
> explanation on why auth happens and why the whole discovery is coupled
with NAA.

<gabor> what dhcp options do we need and why? I thought you said earlier
that you want the MoS address be sent using AAA signalling.
Could you clarify this scenario with all its dirty details? I am not
familiar with this AAA--NAS--DHCP staff. Is there some similar solution
available yet or are we inventing a brand new thing here?

> discovery. Let's re-formulate this part: "In case where DNS is used 
> for discovering the IP address of the MIHF and mobility services and 
> data origin authentication and data ..." to "In case where DNS is used

> for discovering MoS, fake DNS responses may cause DoS and the 
> inability of the MN to perform a proper handover. Where networks are 
> exposed to such DoS, it is RECOMMENDED that DNS service providers use 
> the Domain Name System Security Extensions (DNSSEC) as decsribed in 
> [RFC4033].  Readers may also refer to 
> of DNSSEC Operational Practices. " The previous two paragraphs are ok.
>   
   Fine.
> - the transport layer security recommandations could be added either 
> to the security section or to the transport section (section 6).
>   
<gabor> yes

    We need to fix it.
     Fine with me.
> Section is still incomplete. Also I need you contact info and the 
> input for the IANA section.

---

From: Subir Das <[email-masked]>
Date: Sun, 09 Sep 2007 12:13:31 -0400

One point was not addressed in my earlier mail. When you say MIH users
call flows are you thinking to describe MIH protocol flow as well? 

-Subir

[email-masked] wrote:
>> - most of the added references are not referenced anywhere in the
>>     
> draft.
>   
>> Please go thought the doc and send me any comment/change to be
>>     
> applied.
>   
>> thanks
>> tele
>>

---

From: Telemaco Melia <[email-masked]>
Date: Mon, 10 Sep 2007 13:55:05 +0200

I am on Gabor's notes right now....answers will follow  later...
tele

-- 
Dr. Telemaco Melia			[email-masked]
Senior Research Staff Member		Tel: +49 (0) 6221 4342- 142
NEC Europe Ltd.
NEC Laboratories Europe
Network Division			
Kurfürsten-Anlage 36		
69115 Heidelberg
GERMANY	  

NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London W3 6BL | Registered in England 2832014

---

From: Telemaco Melia <[email-masked]>
Date: Mon, 10 Sep 2007 14:26:48 +0200

> call flows are you thinking to describe MIH protocol flow as well?
I agree that the MIH users should appear in the message flows. I ll work 
on this.

tele

---

From: Subir Das <[email-masked]>
Date: Mon, 10 Sep 2007 09:14:49 -0400

Here is Transport Security text and it should go in Section 8.

In case where reliable transport protocol such as  TCP is used for 
transport connection between two MIHF peers, TLS (RFC 4346) 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 RFC 4366 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, no transport layer security 
is currently available. In such cases if message confidentiality and 
data integrity become important, it should use IP layer security such as 
IPSec (RFC 2401). IPSec provides message authentication in addition to 
message confidentiality and data integrity.

Telemaco Melia wrote:
>> From: ext Telemaco Melia [mailto:[email-masked]] Sent: 
>> Friday, September 07, 2007 9:02 AM

---

From: Subir Das <[email-masked]>
Date: Mon, 10 Sep 2007 09:20:18 -0400

Ok, thanks.

Telemaco Melia wrote:
> I agree that the MIH users should appear in the message flows. I ll 
> work on this.
>
> tele