Subject: [MIPSHOP-MIH-DT] draft-melia-mipshop-mstp-solution-01a.txt

From: Telemaco Melia <[email-masked]>
Date: Tue, 13 Nov 2007 18:01:53 +0100

Guys,

I started the editorial work considering the APs agreed last AC.
I summarize in the following the list of issues and mark them as solved/open.
I ll be in the office still for a while. Let me know if you wan the xml to directly edit the text.

- Do not mandate anything to .21 on the use of MIHFIDs: SOLVED
The text has been removed accordingly

- mandate both TCP/UDP server side and leave it optional for MN" SOLVED
Text has been added at the end of section 6. 

- Gabor to update the DNS draft to reflect previous point: OPEN

- Gabor to revise section 5: OPEN
Text has been proposed and the section adjusted. Still work needed.

- Gabor to update DHCP option draft for scenario 3: OPEN
I added the reference to the draft the integrated bootstrapping ID refers to (draft-ietf-mip6-hiopt-08.txt)
I think the DHCP option document should contain something similar.

- me/Subir to suggest AAA extensions based on draft-ietf-dime-mip6-integrated-06.txt: OPEN
I did not touch this yet. We can simply refer to it for the time being.

- Subir to revise the flow example: SOLVED

- Nada to revise the terminology section: SOLVED
I already integrated the text David proposed.

- Subir to propose some text for L2 security for DHCP: OPEN

- Subir to propose text discussing the issue when DHCP authentication is not available: OPEN

- Subit to clarify with Yoshi about DTLS/TLS: OPEN

- Tele to expand section 5.3: OPEN

- Tele to add text that scenario 5.4 only holds for IS: OPEN

- No need to change MoS to PoS: SOLVED

- Nada to check with David for additional flows: OPEN

Tele

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

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

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 May 3, 2008.

Copyright Notice

   Copyright (C) The IETF Trust (2007).

Melia, et al.              Expires May 3, 2008                  [Page 1]

Internet-Draft                    MSTP                      October 2007

Abstract

   This document describes a design solution for the IEEE 802.21 Media
   Independent Handover (MIH) protocol that addresses identified issues
   associated with the transport of MIH messages.  The document
   describes mechanisms for mobility service (MoS) discovery and
   transport layer mechanisms for the reliable delivery of MIH messages.

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 . . . . . . . . . . . . . . . . . . . . . . . . .  4
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  4
   3.  Deployment Scenarios . . . . . . . . . . . . . . . . . . . . .  7
     3.1.  Scenario S1: Home Network MoS  . . . . . . . . . . . . . .  7
     3.2.  Scenario S2: Visited Network MoS . . . . . . . . . . . . .  7
     3.3.  Scenario S3: Roaming MoS . . . . . . . . . . . . . . . . .  8
     3.4.  Scenario S4: Third party MoS . . . . . . . . . . . . . . .  8
   4.  Solution Overview  . . . . . . . . . . . . . . . . . . . . . .  9
     4.1.  Architecture . . . . . . . . . . . . . . . . . . . . . . . 10
     4.2.  MIHF Identifiers (FQDN, NAI) . . . . . . . . . . . . . . . 11
   5.  MoS Discovery  . . . . . . . . . . . . . . . . . . . . . . . . 11
     5.1.  MoS Discovery when MN and MoSh are in the home network
           (Scenario S1)  . . . . . . . . . . . . . . . . . . . . . . 12
     5.2.  MoS Discovery when MIN is in visited network and MoSv
           is also in visited network (Scenario S2) . . . . . . . . . 13
     5.3.  MOS Discovery when the MN is in a visited Network and
           Services are at the Home network (Scenario S3) . . . . . . 14
     5.4.  MoS discovery when MIH services are in a 3rd party
           remote network (scenario S4) . . . . . . . . . . . . . . . 16
   6.  MIH Transport Options  . . . . . . . . . . . . . . . . . . . . 17
     6.1.  MIH Message size . . . . . . . . . . . . . . . . . . . . . 18
     6.2.  MIH Message rate . . . . . . . . . . . . . . . . . . . . . 18
     6.3.  Retransmission . . . . . . . . . . . . . . . . . . . . . . 19
     6.4.  NAT Traversal  . . . . . . . . . . . . . . . . . . . . . . 19
     6.5.  General guidelines . . . . . . . . . . . . . . . . . . . . 19
   7.  Operation Flows  . . . . . . . . . . . . . . . . . . . . . . . 20
   8.  Security Considerations  . . . . . . . . . . . . . . . . . . . 22
   9.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 23
   10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 23
   11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23
     11.1. Normative References . . . . . . . . . . . . . . . . . . . 23

Melia, et al.              Expires May 3, 2008                  [Page 2]

Internet-Draft                    MSTP                      October 2007

     11.2. Informative References . . . . . . . . . . . . . . . . . . 25
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 25
   Intellectual Property and Copyright Statements . . . . . . . . . . 27

Melia, et al.              Expires May 3, 2008                  [Page 3]

Internet-Draft                    MSTP                      October 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 layer 3
   transport of IEEE 802.21 MIH protocols.

   The MIH Layer 3 transport problem is divided in two main parts: the
   discovery of a node that supports specific Mobility Services (MoS)
   and the transport of the information between a mobile node (MN) and
   the discovered node.  The discovery process is required for the MN to
   obtain the information needed for MIH protocol communication with a
   peer node.  The information includes the transport address (e.g., the
   IP address) of the peer node and the types of MoS provided by the
   peer node.

   This document lists the major MoS deployment scenarios.  It next
   describes the solution architecture, including the MSTP reference
   model and MIHF identifiers.  A description follows of MoS discovery
   procedures when the MN is in a home or remote network.  The remainder
   of the document describes the MIH transport architecture, example
   message flows for several signaling scenarios, and security issues.

2.  Terminology

   The following acronyms and terminology are used in this document:

   MIH  Media Independent Handover: the handover support architecture
      defined by the IEEE 802.21 working group that consists of the MIH
      Function (MIHF), MIH Network Entities, MIH Event messages, and MIH
      command messages.

   MIHF  Media Independent Handover Function: a cross-layer function
      that provides handover services including the Event Service (ES),
      Information Service (IS), and Command Service (CS), through
      service access points (SAPs) defined by the IEEE 802.21 working
      group.

   MIHF User  an MIH client that uses the MIH SAPs to access MIHF
      services, and which is responsible for initiating and terminating
      MIH signaling

   MIHFID  Media Independent Handover Function Identifier: an identifier
      required to uniquely identify the MIHF endpoints for delivering
      mobility services (MoS); it is implemented as either a FQDN or
      NAI.

Melia, et al.              Expires May 3, 2008                  [Page 4]

Internet-Draft                    MSTP                      October 2007

   MoS  Mobility Services: those services, as defined in the MIH problem
      statement document [I-D.ietf-mipshop-mis-ps] , which include the
      MIH IS, CS, and ES services defined by the IEEE 802.21 standard.

   MoSh  Mobility Services assigned in the mobile node's Home Network

   MoSv  Mobility Services assigned in the Visited Network, which is any
      network other than the mobile node's home network

   MoS3  Mobility Services assigned in a 3rd Party Network, which is a
      network that is neither the Home Network nor the current Visited
      Network.

   MN Mobile Node: an Internet device whose location changes, along with
      its point of connection to the network.

   NN Network Node: an Internet device whose location and network point
      of attachment do not change

   MSTP  Mobility Services Transport Protocol: a protocol that is used
      to deliver MIH signaling messages from an MIHF to other MIH-aware
      nodes in a network.

   IS Information Service: a MoS that originates at the lower or upper
      layers and sends information to the local or remote upper or lower
      layers.  It can use secure or insecure ports to transport
      information elements (IEs) and information about various
      neighboring nodes.  Its architecture is outside the scope of the
      IEEE 802.21 draft document.

   ES Event Service: a MoS that originates at a remote MIHF or the lower
      layers and sends information to the local MIHF or local higher
      layers.  The purpose of the ES is to report changes in link status
      (e.g.  Link Going Down messages) and transmission status.

   CS Command Service: a MoS that sends commands from the remote MIHF or
      local upper layers to the local lower layers to switch links or to
      get link status.

   FQDN  Fully-Qualified Domain Name: a complete domain name for a host
      on the Internet, consisting of a host name followed by a domain
      name (e.g. hostname.domain.org)

   NAI  Network Access Identifier: the user ID that a user submits
      during PPP authentication.  For mobile users, the NAI identifies
      the user and helps to route the authentication request message.

Melia, et al.              Expires May 3, 2008                  [Page 5]

Internet-Draft                    MSTP                      October 2007

   NAT  Network Address Translator: A device that implements the Network
      Address Translation function described in [RFC3022], in which
      local or private network layer addresses are mapped to valid
      network addresses and port numbers.

   DHCP  Dynamic Host Configuration Protocol: a protocol described in
      [RFC2131] that allows Internet devices to obtain IP addresses,
      subnet masks, default gateway addresses, and other IP
      configuration information from DHCP servers.

   DNS  Domain Name System: a protocol described in [RFC1035] that
      translates domain names to IP addresses.

   AAA  Authentication, Authorization and Accounting: a set of network
      management services that respectively determine the validity of a
      user's ID, determine whether a user is allowed to use network
      resources, and track users' use of network resources.

   AAA home  AAA server: an AAA server located on the MN's home network

   AAA visited  AAA server: an AAA server located a visited network that
      is not the MN's home network

   MIH ACK  MIH Acknowledgement Message: a MIH signaling message that a
      MIHF sends in response to an MIH message from a sending MIHF, when
      UDP is used as the MSTP.

   PoS  Point of Service, a network-side MIHF instance that exchanges
      MIH messages with a MN-based MIHF

   NAS  Network Access Server: a server to which a MN initially connects
      when it is trying to gain a connection to a network and which
      determines whether the MN is allowed to connect to the NAS's
      network

   UDP  Network Access Server: a server to which a MN initially connects
      when it is trying to gain a connection to a network and which
      determines whether the MN is allowed to connect to the NAS's
      network

   TCP  Transmission Control Protocol: a stream-oriented transport layer
      protocol that provides a reliable delivery service with congestion
      control, defined in RFC 793.

   RTT  Round-Trip Time: a estimation of the time required for a segment
      to travel from a source to a destination and an acknowledgement to
      return to the source that is used by TCP in connection with timer
      expirations to determine when a segment is considered lost and

Melia, et al.              Expires May 3, 2008                  [Page 6]

Internet-Draft                    MSTP                      October 2007

      should be resent.

   MTU  Maximum Transmission Unit: the largest size packet that can be
      sent on a network without requiring fragmentation [RFC1191].

   TLS  Transport Layer Security Protocol: an application layer protocol
      that assures privacy and data integrity between two communicating
      network entities [RFC4346].

3.  Deployment Scenarios

   This section describes the various possible deployment scenarios for
   the MN and the MoS.  The relative positioning of MN and MoS affects
   resource discovery as well as the performance of the MIH signaling
   service.

3.1.  Scenario S1: Home Network MoS

   In this scenario, the MN and the services are located in the home
   network.  We refer to this set of services as MoSh as in Figure 1.
   The MoSh can be located at the access point the MN uses to connect to
   the home network, or it can be located elsewhere.

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

                     Figure 1: MoS in the Home network

3.2.  Scenario S2: Visited Network MoS

   In this scenario, the MN is in the visited network and mobility
   services are also provided by the visited network.  We refer to this
   as MoSv as shown in Figure 2.

Melia, et al.              Expires May 3, 2008                  [Page 7]

Internet-Draft                    MSTP                      October 2007

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

                   Figure 2: MoSV in the Visited Network

3.3.  Scenario S3: Roaming MoS

   In this scenario, the MN is located in the visited network and all
   MIH services are provided by the home network, as shown in Figure 3.

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

            Figure 3: MoS provided by the home while in visited

3.4.  Scenario S4: Third party MoS

   In this scenario, the MN is in its home network or in a visited
   network and services are provided by a 3rd party network.  We refer
   to this situation as MoS3 as shown in Figure 4

Melia, et al.              Expires May 3, 2008                  [Page 8]

Internet-Draft                    MSTP                      October 2007

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

                     Figure 4: MoS form a third party

   Different types of MoS can be provided independently of other types
   and there is no strict relationship between ES, CS and IS, nor is
   there a requirement that the entities that provide these types be co-
   located.  However, while IS tends to involve large amounts of static
   information, ES and CS are dynamic services and some relationship
   between them can be expected, e.g. a handover command (CS) could be
   issued upon reception of a link event (ES).  Hence, while in theory
   MoS can be implemented in different locations, it is expected that ES
   and CS will be co-located, whereas IS can be co-located with ES/CS or
   located elsewhere.  Therefore, having the flexibility at the MSTP to
   discover different services in different locations is an important
   feature that can be used to optimize handover performance.  Resource
   discovery is discussed in more detail in Section 5.

4.  Solution Overview

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

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

   o  If the MIHFID is available, FQDN or NAI's realm is used for
      mobility service discovery.

Melia, et al.              Expires May 3, 2008                  [Page 9]

Internet-Draft                    MSTP                      October 2007

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

   o  MoS 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 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 MIH peers over a trasnport protocol such as UDP or
   TCP.  The usage of transport protocols is described in Section 6.

4.1.  Architecture

   Figure 5 depicts the MSTP reference model and its components within a
   node.  The topmost layer is the MIHF user.  This set of applications
   consists of one or more MIH clients that are responsible for such
   operations as maintaining MIH databases associated with the IS,
   processing Layer 2 triggers as part of the ES, and initiating and
   carrying out handover operations as part of the CS.  Beneath the MIHF
   user set is the MIHF itself.  This function is responsible for MoS
   discovery, as well as creating, maintaining, modifying, and
   destroying MIH signaling associations with other MIHFs located in MIH
   peer nodes.  Below the MIHF are various transport layer protocols as
   well as address resolution functions.

Melia, et al.              Expires May 3, 2008                 [Page 10]

Internet-Draft                    MSTP                      October 2007

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

                            Figure 5: MN stack

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

   The above reference architecture however does not include other
   services such as message fragmentation and security.  Depending upon
   the MIH service type (e.g., ES, CS and IS) the message size can be
   very large.  In case where the underlying layers do not support
   fragmentation, this may be an issue.  There are no security features
   currently defined as part of the MIH protocol level.  However,
   security can be provided either at the transport or IP layer where it
   is necessary.  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 where 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
   [RFC4282].  An MIHFID can be pre-configured or discovered through the
   discovery methods described in Section 5.

5.  MoS Discovery

   The MoS discovery method depends on whether the MN attempts to
   discover an MoS in the home network, in the visited network, or in a

Melia, et al.              Expires May 3, 2008                 [Page 11]

Internet-Draft                    MSTP                      October 2007

   3rd party remote network that is neither the home network nor the
   visited network.

   In case MoS is provided locally (scenarios S1 and S2) , the discovery
   techniques described in [I-D.bajko-mos-dhcp-options] and
   [I-D.bajko-mos-dns-discovery] are both applicable and either one MAY
   be used to discover the MoS.

   In case MoS is provided in the home network while the MN is in the
   visited network (scenario S3), the DNS based discovery described in
   [I-D.bajko-mos-dns-discovery] is applicable, while the DHCP based
   discovery method would require an interaction between the DHCP and
   the AAA infrastructure, similarly to what specified in
   [I-D.ietf-mip6-bootstrapping-integrated-dhc] .  This latter case
   assumes that MoS assignment is performed during access authentication
   and authorization.

   In case MoS is provided in a remote network other than visited or
   home network (scenario S4), only the DNS based discovery method
   described in [I-D.bajko-mos-dns-discovery] is applicable.

5.1.  MoS Discovery when MN and MoSh are in the home network (Scenario
      S1)

   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 mechanism, 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).  The DNS query option is shown in Figure 6b.
   Alternatively, the MN MAY use the DHCP options for MoS
   discovery[I-D.bajko-mos-dhcp-options] as shown inFigure 6a.

Melia, et al.              Expires May 3, 2008                 [Page 12]

Internet-Draft                    MSTP                      October 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 when MIN is in visited network and MoSv is also in
      visited network (Scenario S2)

   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]
   as shown in Figure 7a.  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] as shown in Figure 7b.  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].  A 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
      visited network.  Note, that when a NAT device exists between the
      MN and the visited 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 has determined the external IP
      address of the NAT device, it MUST use that address in the reverse

Melia, et al.              Expires May 3, 2008                 [Page 13]

Internet-Draft                    MSTP                      October 2007

      DNS query.

                         +-----+      +------+
            +----+       |     |      |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 when the MN is in a visited Network and Services are
      at the Home network (Scenario S3)

   To discover an MoS in the visited network when MIH services are
   provided by the home network, both the DNS based discovery method
   described in [I-D.bajko-mos-dns-discovery] and the DHCP based
   discovery method described in [I-D.bajko-mos-dhcp-options] are
   applicable.

   To discover the MoS at home while in a visited network using DNS, the
   MN SHOULD use the procedures described in section Section 5.1

   Alternatively, the MN MAY also use the DHCP based discovery method.
   Using the DHCP based discovery may be required in deployments where
   the usage of MoS located in the home network is enforced and included
   in the subscription profile.  Similarly to
   [I-D.ietf-mip6-bootstrapping-integrated-dhc] in this integrated
   scenario the mobile node utilizes network access authentication
   process to bootstrap MIH services.  It is assumed that the access
   service authorizer is mobility service aware.  This allows for MoS
   discovery at the time of access authentication and authorization.
   Also, the mechanism defined in this document requires the NAS to
   support MIH specific AAA attributes and a collocated DHCP relay
   agent.

Melia, et al.              Expires May 3, 2008                 [Page 14]

Internet-Draft                    MSTP                      October 2007

   In these deployment scenarios the AAAH sends the MoS at home address
   to the AAAV during the network access authentication.  This procedure
   is shown in Figure 8.  Upon network access authentication and
   interaction with the NAS the home AAA (AAAh) verifies in the AAA
   profile that the MN is allowed to use the MoS in the home network.
   The AAAh assigns the MoS in the home network and sends back the
   information to the NAS.  The MN sends a DHCP information request as
   per [RFC3315] containing Home Network Identifier Option as in
   [I-D.ietf-mip6-hiopt] indicating the need to allocate the MoS in the
   home network.  The relay agent in the visited network intercepts the
   Information request from the MN and it forwards to the DHCP server
   inserting the MIH Relay Agent Option [I-D.bajko-mos-dhcp-options]
   containing the info received by the AAAh.  The DHCP server can then
   reply to the MN by sending the Home Network Information Option
   [I-D.ietf-mip6-hiopt].  The MN receives the MoSh address.

   It should be noted that the AAAh does not know 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.

Melia, et al.              Expires May 3, 2008                 [Page 15]

Internet-Draft                    MSTP                      October 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 when MIH services are in a 3rd party remote network
      (scenario S4)

   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].  The MN MUST first learn the domain
   name of the network containing the MoS it is searching for.  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

Melia, et al.              Expires May 3, 2008                 [Page 16]

Internet-Draft                    MSTP                      October 2007

   network as inFigure 9 part(c).  It should 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) DHCP Options, (b) IS Query to a
                        known Server, (c) DNS Query

6.  MIH Transport Options

   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 associated with
   each that need to be considered in the context of the MIH services
   for different network loss and congestion conditions.  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

Melia, et al.              Expires May 3, 2008                 [Page 17]

Internet-Draft                    MSTP                      October 2007

   mechanism is to be used in conjunction with UDP, while it is
   preferred to avoid using MIH ACKs with TCP since TCP includes
   acknowledgement and retransmission 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 [IEEE80221].
   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, if MIH is 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.  Note also that TCP is a stream
   oriented protocol and measures data flow in terms of bytes, not
   messages.  Thus it is possible to split messages across multiple TCP
   segments if they are long enough.  Even short messages can be split
   across two segments.  This can also cause unacceptable delays,
   especially if the link quality is severely degraded as is likely to
   happen when the MN is exiting a wireless access coverage area.

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,

Melia, et al.              Expires May 3, 2008                 [Page 18]

Internet-Draft                    MSTP                      October 2007

   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 parameters of a token
   bucket regulator as defined in the MIH specifications [IEEE80221].
   Recommendations for tocken bucket 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
   delay associated with retransmission timeouts may increase
   significantly with increased packet loss.

   If UDP is being used to carry MIH messages, MIH MUST use MIH ACKs.
   An MIH message is retransmitted if its corresponding MIH ACK is not
   received by the generating node within a timeout interval set by the
   MIHF.  This approach does not include an exponential backoff and
   therefore tends to degrade more gracefully than TCP when the packet
   loss rate becomes large, in the sense that the expected delay does
   not increase exponentially.  The number of retransmissions is
   limited, which reduces head-of-line blocking of other MIH messages,
   but this can cause important ES/CS messages to be lost.

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

Melia, et al.              Expires May 3, 2008                 [Page 19]

Internet-Draft                    MSTP                      October 2007

   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.

   It is mandatory the use of UDP and TCP as defualt transport
   mechanisms implemented in the server side.  The MN SHOULD discover
   server transport options.  The MN can choose oen of the mandated
   transport protocols.  It is optional the use of SCTP both for server
   and MN.

7.  Operation Flows

   Figure 10 gives an example operation flow between MIHF peers when an
   MIH user requests for an IS service.  Scenario 1 is in effect, i.e.
   the MoS and the MN are both in the MN's home network.  Thus DHCP is
   used for MoS discovery and TCP is used for establishing a transport
   connection to carry the IS messages.  When MOS is not pre-configured,
   the MIH user needs to discover the IP address of MOS to communicate
   with the remote MIHF.  Therefore the MIH user sends a discovery
   request message to the local MIHF as defined in [IEEE80221]

   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 defined 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.  The MIH user generates an IS query addressed
   to the remote MoS.  MIHF invokes the underlying TCP client which
   establishes a transport connection with the remote peer.  Once the
   transport connection is established, MIHF sends the IS query via MIH
   protocol REQUEST message.  The message and query arrive at the
   destination MIHF and MIH user respectively.  The MoS MIH user
   responds to the corresponding IS query and the MoS MIHF sends the IS
   response via MIH protocol RESPONSE message.  The message arrives to
   the source MIHF which passes the IS response on to the corresponding
   MIH user.

                    MN                                             MoS
|======================================+|     |======|   |========================|
+------------------+                                              +--------------+
|+------+   +-----+|   +------+  +------+     +------+   +------+ |+----+  +----+|

Melia, et al.              Expires May 3, 2008                 [Page 20]

Internet-Draft                    MSTP                      October 2007

|| MIH  |   |MIHF ||   | TCP  |  |DHCP  |     |DHCP  |   | TCP  | ||MIHF|  |MIH ||
|| User |   |     ||   |Client|  |Client|     |Server|   |Server| ||    |  |User||
|+------+   +-----+|   +------+  +------+     +------+   +------+ |+----+  +----+|
+------------------+                                              +--------------+
        |                 |         |            |          |                |
        |MIH Discovery    |         |            |          |                |
        |Request          |         |            |          |                |
        |(MIH User-> MIHF)|         |            |          |                |
        |======>          |         |            |          |                |
        |                 |         |            |          |                |
        |Invoke DHCP Client         |            |          |                |
        |(Internal process with MoS)|DHCP INFORM |          |                |
        |==========================>|===========>|          |                |
        |                 |         |            |          |                |
        |                 |         |            |          |                |
        |                 |         |   DHCP ACK |          |                |
        |                 |         |<===========|          |                |
        |    Inform MoS address     |            |          |                |
        |<==========================|            |          |                |
        |    (internal process)     |            |          |                |
        |                           |            |          |                |
        |Discovery        |         |            |          |                |
        |Response         |         |            |          |                |
        |<======          |         |            |          |                |
        |(MIH User<- MIHF)|         |            |          |                |
        |                 |         |            |          |                |
        |IS Query         |         |            |          |                |
        |=======>         |         |            |          |                |
        |(MIH User-> MIHF)|         |            |          |                |
        |                 |         |            |          |                |
        |Invoke TCP Client|         |            |          |                |
        |================>|         |            |          |                |
        |(Internal process|         |            |          |                |
        |with MOS)        |         |            |          |                |
        |                 |         |            |          |                |
        |                 |   TCP connection established    |                |
        |                 |<===============================>|                |
        |                 |         |            |          |                |
        |                 |         |            |          |                |
        |                 |         |            |          |                |
        |                  IS  QUERY REQUEST (via MIH protocol)              |
        |===================================================================>|
        |                 |         |            |          |                |
        |                 |         |            |          |                |
        |                 |         |            |          |                |
        |                 |         |            |          |        IS QUERY|
        |                 |         |            |          |         REQUEST|
        |                 |         |            |          |         ======>|

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

        |                 |         |            |          |(MIHF-> MIH User)
        |                 |         |            |          |                |
        |                 |         |            |          |           QUERY|
        |                 |         |            |          |        RESPONSE|
        |                 |         |            |          |         <======|
        |                 |         |            |          |(MIHF <-MIH User)
        |                 |         |            |          |                |
        |                 |  IS QUERY RESPONSE (via MIH protocol)            |
        |<===================================================================|
        |                 |         |            |          |                |
        |    IS           |         |            |          |                |
        |RESPONSE         |         |            |          |                |
        |<========        |         |            |          |                |
        |(MIH User <-MIHF)|         |            |          |                |
        |                 |         |            |          |                |

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

Melia, et al.              Expires May 3, 2008                 [Page 22]

Internet-Draft                    MSTP                      October 2007

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

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.

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

Melia, et al.              Expires May 3, 2008                 [Page 23]

Internet-Draft                    MSTP                      October 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-mip6-hiopt]
              Jang, H., "DHCP Option for Home Information Discovery in
              MIPv6", draft-ietf-mip6-hiopt-08 (work in progress),
              November 2007.

   [I-D.ietf-mipshop-mis-ps]
              Melia, T., Hepworth, E., Sreemanthula, S., Ohba, Y.,
              Gupta, V., Korhonen, J., and Z. Xia, "Mobility Services
              Transport: Problem Statement",
              draft-ietf-mipshop-mis-ps-04 (work in progress),
              November 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.

   [IEEE80221]
              "Draft IEEE Standard for Local and Metropolitan Area
              Networks: Media Independent Handover Services", IEEE LAN/
              MAN Draft  IEEE P802.21/D07.00, 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.

Melia, et al.              Expires May 3, 2008                 [Page 24]

Internet-Draft                    MSTP                      October 2007

   [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
              Internet Protocol", RFC 2401, November 1998.

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

   [RFC4282]  Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The
              Network Access Identifier", RFC 4282, December 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

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

Authors' Addresses

   Telemaco Melia (editor)
   NEC

   Email: [email-masked]

   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 May 3, 2008                 [Page 26]

Internet-Draft                    MSTP                      October 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 May 3, 2008                 [Page 27]


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

---

From: Nada Golmie <[email-masked]>
Date: Tue, 13 Nov 2007 13:06:02 -0500

Hi Tele,

Telemaco Melia wrote:
> - me/Subir to suggest AAA extensions based on 
> draft-ietf-dime-mip6-integrated-06.txt: OPEN
This should be solved as David did not have any strong opinions about it 
and neither did the people on the call last week.

-Nada
>
>
>
> Tele
>
>
> ------------------------------------------------------------------------
>

---

From: Subir Das <[email-masked]>
Date: Tue, 13 Nov 2007 14:05:40 -0500

tele,
I have reflected Yoshi's comments in Security section, Waiting for his 
review.
Will send you as soon a I finish discussing with him.  Will look into 
the AAA
extension draft and will refer it for the time being.

-Subir

---

From: Subir Das <[email-masked]>
Date: Tue, 13 Nov 2007 18:02:55 -0500

Tele,
Here is the updated Security section that is fine with Yoshi. However, he
suggests to add the capability to know the security protocol of choice 
at the
server side during discovery. I discussed with Gabor and he will look into
this and find if it can be done by defining a new NAPTR, otherwise I 
will discuss
with Yoshi again and update to you.

   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
   to use either DHCP authentication option described in [RFC3118], where
   available or rely upon link layer security.  This will also protect the
   denial of service attacks to DHCP server.[RFC3118] provides mechanisms
   for both entity authentication and message authentication.

   Alternatively, generic IP layer security, such as IPSec [RFC2401] may
   be used where neither transport layer security for a specific transport
   is available nor server only authentication is required

Telemaco Melia wrote:
> Guys,
> file:///C:/Documents%20and%20Settings/subir/Desktop/GDQ%20Corporate%20Directory.lnk 
> <cid:[email-masked]>

---

From: <[email-masked]>
Date: Wed, 14 Nov 2007 16:28:16 -0600

Some inline: 

-----Original Message-----
From: ext Telemaco Melia [mailto:[email-masked]] 
Sent: Tuesday, November 13, 2007 9:02 AM
To: [email-masked]
Subject: [MIPSHOP-MIH-DT] draft-melia-mipshop-mstp-solution-01a.txt

Guys,

I started the editorial work considering the APs agreed last AC.
I summarize in the following the list of issues and mark them as
solved/open.
I ll be in the office still for a while. Let me know if you wan the xml
to directly edit the text.

- Do not mandate anything to .21 on the use of MIHFIDs: SOLVED The text
has been removed accordingly

<Gabor> I can not mandate the support for it in the DNS draft, that has
to be done in this mstp-solution draft.  What I will do is to
additionally define an application tag for SCTP.

The current text in section 6 says that "MIH peers MUST exchange
information over either TCP or UDP". I do not think this is right based
on the discussions we had. The MIH peers MAY exchange information using
any other transport supported by both MIH end points, and whether the
server supports it or not, can be discovered using the DNS discovery.
Suggested text: "MIH peers MAY exchange information over TCP, UDP or any
other transport supported by both the server and client. The client MAY
use the DNS discovery mechanism to discover which transport protocols
are supported by the server in addition to TCP and UDP".
Regarding the usage of ACK: the text should say "MIH ACK mechanism MAY
only be used with unreliable transport mechanisms, like UDP" 
Section 6.3: "If UDP is being used to carry MIH messages, MIH MUST use
MIH ACKs." I propose relaxing this to "If UDP is being used to carry MIH
messages, MIH SHOULD use MIH ACKs."
Section 6.5: "MIH messages sent over UDP or TCP MUST use the default
port number." to be changed to "MIH messages sent over UDP, TCP or other
supported transport MUST use the default port number defined for that
particular transport."

<GABOR> I have done my part, I thought the rest can be addressed by you
guys.
Issues:
6.2 Header: change MIN to MN
Section 5.3, 2nd paragraph: word "section" is duplicated.

I am writing the DHCP options draft. We defined the options: "MoS
Identifier Option", "MIP6 Relay Agent MoS Option" and "MoS Information
Option" and those should be used instead of the options defined in
[I-D.ietf-mip6-hiopt] (and also draft-bajko-dhcp-discovery referenced
instead of the hiopt one).

This text: "   It should be noted that the AAAh does not know 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."
Should be modified to "It should be noted that the AAAh does not know
the preferences of the MN at the time of authentication, i.e. whether
the MoS in the home or in the local network is to be sent to the MN. The
MoS information will anyway be sent to the AAAV, then stored in the
relay agent and ultimately sent to the MN if the MN asks for it, using
the procedures defined in [draft-bajko-dhcp-discovery]"

- Gabor to update DHCP option draft for scenario 3: OPEN I added the
reference to the draft the integrated bootstrapping ID refers to
(draft-ietf-mip6-hiopt-08.txt) I think the DHCP option document should
contain something similar.

I am working on the DHCP options draft. It got a bit complicated because
we now want to use it for both local and home MoS discovery. But I'll
finish it before the deadline.

Thanks,
- gabor

- me/Subir to suggest AAA extensions based on
draft-ietf-dime-mip6-integrated-06.txt: OPEN I did not touch this yet.
We can simply refer to it for the time being.

- Nada to revise the terminology section: SOLVED I already integrated
the text David proposed.

- Subir to propose text discussing the issue when DHCP authentication is
not available: OPEN

Tele

---

From: Telemaco Melia <[email-masked]>
Date: Thu, 15 Nov 2007 16:37:47 +0100

Guys here it goes -01b.

Log change from version -01a:
-- input posted on the list included
-- section 5.3 added with more text (pleas read and check consistency)
-- added an appendix for the diameter extensions to convey MoS 
information from AAAh to the NAS.

Subir, with the appendix, the intention is to describe the options 
required and to show to the WG that we have everything in place.
We can submit a separate draft later on and explain to the WG already in 
Vancouver what are our plans.
What do you think?

Let me know your comments asap...we ll be able to implement your changes 
only on Monday morning though (still here for few hours).

Tele

-- 

Mipshop WG                                                 T. Melia, Ed.
Internet-Draft                                                       NEC

Status of this Memo

Copyright Notice



Abstract

Requirements Language



Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  4
   3.  Deployment Scenarios . . . . . . . . . . . . . . . . . . . . .  7
     3.1.  Scenario S1: Home Network MoS  . . . . . . . . . . . . . .  7
     3.2.  Scenario S2: Visited Network MoS . . . . . . . . . . . . .  7
     3.3.  Scenario S3: Roaming MoS . . . . . . . . . . . . . . . . .  8
     3.4.  Scenario S4: Third party MoS . . . . . . . . . . . . . . .  8
   4.  Solution Overview  . . . . . . . . . . . . . . . . . . . . . .  9
     4.1.  Architecture . . . . . . . . . . . . . . . . . . . . . . . 10
     4.2.  MIHF Identifiers (FQDN, NAI) . . . . . . . . . . . . . . . 11
   5.  MoS Discovery  . . . . . . . . . . . . . . . . . . . . . . . . 11
     5.1.  MoS Discovery when MN and MoSh are in the home network
           (Scenario S1)  . . . . . . . . . . . . . . . . . . . . . . 12
     5.2.  MoS Discovery when MIN is in visited network and MoSv
           is also in visited network (Scenario S2) . . . . . . . . . 13
     5.3.  MOS Discovery when the MN is in a visited Network and
           Services are at the Home network (Scenario S3) . . . . . . 14
     5.4.  MoS discovery when MIH services are in a 3rd party
           remote network (scenario S4) . . . . . . . . . . . . . . . 17
   6.  MIH Transport Options  . . . . . . . . . . . . . . . . . . . . 18
     6.1.  MIH Message size . . . . . . . . . . . . . . . . . . . . . 19
     6.2.  MIH Message rate . . . . . . . . . . . . . . . . . . . . . 19
     6.3.  Retransmission . . . . . . . . . . . . . . . . . . . . . . 20
     6.4.  NAT Traversal  . . . . . . . . . . . . . . . . . . . . . . 20
     6.5.  General guidelines . . . . . . . . . . . . . . . . . . . . 20
   7.  Operation Flows  . . . . . . . . . . . . . . . . . . . . . . . 21
   8.  Security Considerations  . . . . . . . . . . . . . . . . . . . 23
   9.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 24
   10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 24
   11. Appendix . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
     11.1. Attribute Value Pair Definitions . . . . . . . . . . . . . 24
       11.1.1.  MoS Info  . . . . . . . . . . . . . . . . . . . . . . 24
       11.1.2.  MIH-MoS-Address AVP . . . . . . . . . . . . . . . . . 25
       11.1.3.  MIH-MoS-FQDN AVP  . . . . . . . . . . . . . . . . . . 25
       11.1.4.  MoS Capability  . . . . . . . . . . . . . . . . . . . 25
   12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26
     12.1. Normative References . . . . . . . . . . . . . . . . . . . 26
     12.2. Informative References . . . . . . . . . . . . . . . . . . 28
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 28
   Intellectual Property and Copyright Statements . . . . . . . . . . 30



1.  Introduction

2.  Terminology







      should be resent.

3.  Deployment Scenarios

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



             +--------------+
             | HOME NETWORK |
             +--------------+
                   /\
                   ||
                   \/

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



                                      +--------------+
                                      | HOME NETWORK |

4.  Solution Overview



4.1.  Architecture



                            Figure 5: MN stack

5.  MoS Discovery





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

                             (a) using DNS Query

                            +-----+      +------+
               +----+       |     |      |DHCP  |

                             (b)  Using DHCP Option



      DNS query.

                         +-----+      +------+
            +----+       |     |      |DHCP  |

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

   agent.  In order to provide the mobile node with information about



   the assigned MoS the AAAh conveys the assigned MoS's information to
   the NAS via AAA protocol similarly to [I-D.ietf-dime-mip6-integrated]
   and described in Section 11.

   In these deployment scenarios the AAAh sends the MoS address at home
   to the AAAv during the network access authentication.  The relation
   beween functional components supporting such procedure is shown in
   Figure 8.

   The mobile node executes the network access authentication procedure
   (e.g., IEEE 802.11i/802.1X) and it interacts with the NAS.  The NAS
   is in the visited and it interacts with the AAAh to authenticate the
   mobile node.  In the process of authorizing the mobile node the AAAh
   verifies in the AAA profile that the mobile node is allowed to use
   MoS service.  The AAAh assigns the MoS in the home and returns this
   information to the NAS.  The NAS may keep the received information
   for a configurable duration or it may keep the information for as
   long as the MN is connected to the NAS.

   The mobile node sends a DHCPv6 Information Request message [RFC3315]
   to the All_DHCP_Relay_Agents_and_Servers multicast address.  In this
   message the mobile node (DHCP client) SHALL include the Option Code
   for MoS Identifier Option [I-D.bajko-mos-dhcp-options] in the
   OPTION_ORO, MoS Identifier Option with id-type set to 1 and the MoS
   Identifier field set to the network realm of the home.  The mobile
   node SHALL also include the OPTION_CLIENTID to identify itself to the
   DHCP server.

   The Relay Agent intercepts the Information Request from the mobile
   node and forwards it to the DHCP server.  The Relay Agent also
   includes the received MoS information from the AAAh in the MIH Relay
   Agent Option [I-D.bajko-mos-dhcp-options].  If a NAS implementation
   does not store the received information as long as the MN's session
   remains in the visited, and if the MN delays sending DHCP request,
   the NAS/DHCP relay does not include the MIH Relay Agent Option in the
   Relay Forward message.

   The DHCP server identifies the client by looking at the DUID for the
   client in the OPTION_CLIENTID.  The DHCP server also determines that
   the mobile node is requesting MoS information in the home by looking
   at the MoS Identifier Option (id-type 1).  The DHCP server determines
   that the home agent is allocated by the AAAh by looking at the MIH
   sub-option in the MIH Relay Agent Option.  The DHCP server extracts
   the allocated home agent information from the MIH Relay Agent Option
   and includes it in the MoS Information Option
   [I-D.bajko-mos-dhcp-options] in the Reply Message.  If the requested
   information is not available in the DHCP server, it follows the
   behavior described in [I-D.bajko-mos-dhcp-options].



   The Relay Agent relays the Reply Message from the DHCP server to the
   mobile node.  At this point, the mobile node has the home agent
   information that it requested.

   It should be noted that the AAAh does not know the preferences of the
   MN at the time of authentication, i.e. whether the MoS in the home or
   in the local network is to be sent to the MN.  The MoS information
   will anyway be sent to the AAAV, then stored in the relay agent and
   ultimately sent to the MN if the MN asks for it, using the procedures
   defined in [I-D.bajko-mos-dhcp-options].

                           Visited             |          Home
                                               |
                                               |
                           +-------+           |        +-------+
                           |       |           |        |       |

          AAAv -- Visited AAA
          AAAH -- Home AAA





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

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

6.  MIH Transport Options

   Once the Mobility Services have been discovered, MIH peers MAY
   exchange information over TCP, UDP or any other transport supported
   by both the server and client.  The client MAY use the DNS discovery
   mechanism to discover which transport protocols are supported by the
   server in addition to TCP and UDP.  While either protocol can provide
   the basic transport functionality required, there are performance
   trade-offs and unique characteristics associated with each that need
   to be considered in the context of the MIH services for different
   network loss and congestion conditions.  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



   MIH ACKs with TCP since TCP includes acknowledgement and
   retransmission functionality

6.1.  MIH Message size

6.2.  MIH Message rate



6.3.  Retransmission

   If UDP is being used to carry MIH messages, MIH SHOULD use MIH ACKs.

6.4.  NAT Traversal

6.5.  General guidelines



   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, TCP or other supported
   transport MUST use the default port number defined for that
   particular transport..

   It is mandatory the use of UDP and TCP as default transport
   mechanisms implemented in the server side.  The MN SHOULD discover
   server transport options.  The MN can choose one of the mandated
   transport protocols.  It is optional the use of SCTP both for server
   side and MN side.

7.  Operation Flows

                    MN                                             MoS



|| MIH  |   |MIHF ||   | TCP  |  |DHCP  |    |DHCP  |   | TCP  | ||MIHF|  |MIH ||
|| User |   |     ||   |Client|  |Client|    |Server|   |Server| ||    |  |User||
|+------+   +-----+|   +------+  +------+    +------+   +------+ |+----+  +----+|
+------------------+                                             +--------------+
        |                 |         |           |          |                |
        |MIH Discovery    |         |           |          |                |
        |Request          |         |           |          |                |
        |(MIH User-> MIHF)|         |           |          |                |
        |======>          |         |           |          |                |
        |                 |         |           |          |                |
        |Invoke DHCP Client         |           |          |                |
        |(Internal process with MoS)|DHCP INFORM|          |                |
        |==========================>|==========>|          |                |
        |                 |         |           |          |                |
        |                 |         |           |          |                |
        |                 |         |  DHCP ACK |          |                |
        |                 |         |<==========|          |                |
        |    Inform MoS address     |           |          |                |
        |<==========================|           |          |                |
        |    (internal process)     |           |          |                |
        |                           |           |          |                |
        |Discovery        |         |           |          |                |
        |Response         |         |           |          |                |
        |<======          |         |           |          |                |
        |(MIH User<- MIHF)|         |           |          |                |
        |                 |         |           |          |                |
        |IS Query         |         |           |          |                |
        |=======>         |         |           |          |                |
        |(MIH User-> MIHF)|         |           |          |                |
        |                 |         |           |          |                |
        |Invoke TCP Client|         |           |          |                |
        |================>|         |           |          |                |
        |(Internal process|         |           |          |                |
        |with MOS)        |         |           |          |                |
        |                 |         |           |          |                |
        |                 |  TCP connection established    |                |
        |                 |<==============================>|                |
        |                 |         |           |          |                |
        |                 |         |           |          |                |
        |                 |         |           |          |                |
        |                 IS  QUERY REQUEST (via MIH protocol)              |
        |==================================================================>|
        |                 |         |           |          |                |
        |                 |         |           |          |                |
        |                 |         |           |          |                |
        |                 |         |           |          |        IS QUERY|
        |                 |         |           |          |         REQUEST|
        |                 |         |           |          |         ======>|



        |<==================================================================|

   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], where available or rely
   upon link layer security.  This will also protect the denial of
   service attacks to DHCP server.[RFC3118] provides mechanisms for both
   entity authentication and message authentication.



   Alternatively, generic IP layer security, such as IPSec [RFC2401] may
   be used where neither transport layer security for a specific
   transport is available nor server only authentication is required.

9.  IANA Considerations

10.  Acknowledgements

11.  Appendix

   This appendix contains AAA specifications to convey MoS realted
   information from the AAAh to the NAS for scenario 3.  Due to lack of
   time we did not post a separate ID.

11.1.  Attribute Value Pair Definitions

11.1.1.  MoS Info

   The MoS-Info AVP (AVP code TBD) is type of Grouped and contains
   necessary information to assign a MoS to the MN.  When the MoS-Info
   AVP is present in a message, it MUST contain either a MIH-MoS-Address
   AVP or a MIH-MoS-FQDN AVP, but not both.  The grouped AVP has the



   following grammar:

   artwork <MoS-Info> ::= < AVP Header: TBD >
                                [ MIH-MoS-Address ]
                                [ MIH-MoS-FQDN ]
                              * [ AVP ]

11.1.2.  MIH-MoS-Address AVP

   The MIH-MoS-Address AVP (AVP Code TBD) is of type Address and
   contains the MoS address.  The Diameter server MAY decide to assign a
   MoS to the MN that is in close proximity to the point of attachment
   (e.g., determined by the NAS-Identifier AVP).  There may be other
   reasons for dynamically assigning MoSs to the MN, for example to
   share the traffic load.

   This AVP MAY also be attached by the NAS when sent to the Diameter
   server in a request message as a hint of a locally assigned MoS
   address.

11.1.3.  MIH-MoS-FQDN AVP

   The MIH-MoS-FQDN AVP (AVP Code TBD) is of type UTF8String and
   contains the FQDN of a MoS.  The usage of this AVP is equivalent to
   the MIH-MoS-Address AVP but offers an additional level of indirection
   via the DNS infrastructure.

11.1.4.  MoS Capability

   The MoS-Capability AVP (AVP Code TBD) is of type Unsigned64 and
   contains a 64 bits flags field of supported capabilities of the NAS/
   ASP.  Sending and receiving the MoS-Capability AVP with value 0 MUST
   be supported.

   The NAS MAY include this AVP to indicate capabilities of the NAS/ASP
   to the Diameter server.  For example, the NAS may indicate that a
   local MoS can be provided.  Similarly, the Diameter server MAY
   include this AVP to inform the NAS/ASP about which of the NAS/ASP
   indicated capabilities are supported or authorized by the ASA/MSA(/
   MSP).

   The following capabilities are defined in this document:

   o  MOBILITY_CAPABILITY (0x0000000000000000) -- The MoS-Capability AVP
      MAY contain value 0 (zero) with the semantics that are defined in
      this document for the Mobile IPv6 bootstrapping functionality.
      This 'zero' flag is always implicitly set when the MoS AVP is
      used.



   o  LOCAL_HOME_AGENT_ASSIGNMENT (0x0000000000000001) -- This flag is
      set by the NAS/ASP when a local MoS can be assigned to the MN.
      This flag is set by the ASA/MSA(/MSP) when the use of a local MoS
      is authorized.

12.  References

12.1.  Normative References

   [I-D.ietf-dime-mip6-integrated]
              Korhonen, J., Bournelle, J., Tschofenig, H., Perkins, C.,
              and K. Chowdhury, "Diameter Mobile IPv6: Support for
              Network Access Server to Diameter Server  Interaction",
              draft-ietf-dime-mip6-integrated-06 (work in progress),
              November 2007.

   [I-D.ietf-mip6-hiopt]



   [IEEE80221]



12.2.  Informative References

Authors' Addresses

   Telemaco Melia (editor)
   NEC

   Gabor Bajko
   Nokia

   Subir Das
   Telcordia

Melia, et al.              Expires May 3, 2008                 [Page 28]


   Nada Golmie
   NIST

   Sam Xia
   Huawei

   Juan Carlos Zuniga
   InterDigital

Melia, et al.              Expires May 3, 2008                 [Page 29]


Full Copyright Statement

Intellectual Property

Acknowledgment

Melia, et al.              Expires May 3, 2008                 [Page 30]

---

From: Telemaco Melia <[email-masked]>
Date: Thu, 15 Nov 2007 16:43:09 +0100

Telemaco Melia wrote:
> We can submit a separate draft later on and explain to the WG already 
> in Vancouver what are our plans.
> What do you think?
>
> Let me know your comments asap...we ll be able to implement your 
> changes only on Monday morning though (still here for few hours).
>
> Tele
Forgot to say: seeking volunteers for review...

tele

---

From: Nada Golmie <[email-masked]>
Date: Thu, 15 Nov 2007 13:13:14 -0500

Hello All,

Juan-Carlos and I worked on this last paragraph in section 6. We believe that section 6 is OK
with the following change: 

1) Replace this paragraph:

with this one:

The server side MUST support both UDP and TCP for MIH transport, and the MN MAY support either UDP or TCP. 
Additionally, the server and MN MAY support additional transport mechanisms.
The MN SHOULD discover the server's preferred transport mechanism to use in each service as defined in [I-D.bajko-mos-dns-discovery].

2) Add the following sentence at the end of last paragraph of section 6.3:

Additionally, instead of retransmitting an unacknowledged message, the MIH may choose to update the information and transmit a new message.

3) Add the following reference to the end of first sentence of section 6:

Once the Mobility Services have been discovered, MIH peers MAY
   exchange information over TCP, UDP or any other transport supported
   by both the server and client, as described in [I-D.draft-rahman-
mipshop-mih-transport].

4) Add the following reference

[I-D.draft-rahman-mipshop-mih-transport]Rahman, A., Olvera-Hernandez, U., Zuniga, JC., Wafta, M., and Kim,
H.W., “Transport of Media Independent Handover Messages Over IP,” draft-rahmanmipshop-mih-transport-03 (work in progress), July 2007.

Any comments?

-Nada and Juan-Carlos

---

From: <[email-masked]>
Date: Thu, 15 Nov 2007 12:55:51 -0600

A few issues:

Change the proposed sentence: "The MN SHOULD discover the server's
preferred transport mechanism to use in each service as defined in
[I-D.bajko-mos-dns-discovery]." to:

"The MN MAY use the procedures defined in [I-D.bajko-mos-dns-discovery]
to discover additional transport protocols supported by the server."

The sentence "Additionally, instead of retransmitting an unacknowledged
message, the MIH may choose to update the information and transmit a new
message." is out of context. We should talk about transport issues, and
not MIH level decisions. I would prefer NOT to add that sentence into
the draft.

- gabor 

-----Original Message-----
From: ext Nada Golmie [mailto:[email-masked]] 
Sent: Thursday, November 15, 2007 10:13 AM
To: Telemaco Melia
Cc: Zuniga, Juan Carlos; [email-masked]
Subject: Re: [MIPSHOP-MIH-DT] draft-melia-mipshop-mstp-solution-01a.txt

Hello All,

Juan-Carlos and I worked on this last paragraph in section 6. We believe
that section 6 is OK with the following change: 

with this one:

The server side MUST support both UDP and TCP for MIH transport, and the
MN MAY support either UDP or TCP. 
Additionally, the server and MN MAY support additional transport
mechanisms.
The MN SHOULD discover the server's preferred transport mechanism to use
in each service as defined in [I-D.bajko-mos-dns-discovery].

2) Add the following sentence at the end of last paragraph of section
6.3:

Additionally, instead of retransmitting an unacknowledged message, the
MIH may choose to update the information and transmit a new message.

3) Add the following reference to the end of first sentence of section
6:

[I-D.draft-rahman-mipshop-mih-transport]Rahman, A., Olvera-Hernandez,
U., Zuniga, JC., Wafta, M., and Kim, H.W., "Transport of Media
Independent Handover Messages Over IP,"
draft-rahmanmipshop-mih-transport-03 (work in progress), July 2007.

Any comments?

-Nada and Juan-Carlos

---

From: Nada Golmie <[email-masked]>
Date: Thu, 15 Nov 2007 14:02:26 -0500

Hi Gabor,

> to discover additional transport protocols supported by the server."
That's fine.
> not MIH level decisions. I would prefer NOT to add that sentence into
I agree with you. However, this is only pointing out that letting the 
MIH handle retransmissions has the additional benefit of not having to
retransmit the same information. It can be part of the trade-off 
analysis discussion.

-Nada

---

From: Sam Xia <[email-masked]>
Date: Fri, 16 Nov 2007 09:34:11 +0800

Hi all, 

i am carefully reviewing this new version draft. at first glance, i am
surprised at seeing so many well-known terminology listed section 2, such as
UDP, TCP, MTU etc. moreover, UDP definition is wrong.

 Best Regards, Sam Xia

---

From: Subir Das <[email-masked]>
Date: Fri, 16 Nov 2007 07:54:30 -0500

Tele,
In general I support the approach of adding in an appendix for the time 
being.
There were some typos. So pl. use the following text but I did not 
understand the
last part and see my comments below.

-Subir

11. Appendix

11.1.1.  MoS Info



   following grammar:

   reasons for dynamically assigning MoS to the MN, for example to
   share the traffic load.

11.1.3.  MIH-MoS-FQDN AVP

   The MIH-MoS-FQDN AVP (AVP Code TBD) is of type UTF8 String and
   contains the FQDN of a MoS.  The usage of this AVP is equivalent to
   the MIH-MoS-Address AVP but offers an additional level of indirection
   via the DNS infrastructure.

11.1.4.  MoS Capability

   The MoS-Capability AVP (AVP Code TBD) is of type Unsigned64 and
   contains a 64 bits flag field of supported capabilities of the NAS/
   ASP.  Sending and receiving the MoS-Capability AVP with value 0 MUST
   be supported.



Subir> What are these above two flags?. Looks to me that these are left over
from MIpv6 draft. Either we change the MOBILITY_CAPABILITY as MOS Service
capability like ES, CS and IS and add three flags or delete it for the 
time being. Similarly
LOCAL_HA_ASSIGNEMENT should be LOCAL_MOS_ASSIGNMENT.

Telemaco Melia wrote:
>> From: ext Telemaco Melia [mailto:[email-masked]] Sent: Tuesday, 
>> November 13, 2007 9:02 AM
>> only be used with unreliable transport mechanisms, like UDP" Section 
>> 6.3: "If UDP is being used to carry MIH messages, MIH MUST use

---

From: <[email-masked]>
Date: Sat, 17 Nov 2007 17:20:42 -0600

Tele,

If you could implement the changes suggested by Nada and myself (3
different mails), I think the document is good to go. We will have some
terminology and procedure fixes for section 5.3, to align it with the
dhcp draft, but that could be done for version -02. The dhcp draft is
still not ready, as the usage of dhcp to discover MoS both in visited
and home complicated the situation a lot, we had to completely rewrite
the whole draft and probably submit it incomplete because of lack of
time to finalize it.

Thanks,
- gabor

-----Original Message-----
From: ext Telemaco Melia [mailto:[email-masked]] 
Sent: Thursday, November 15, 2007 7:43 AM
To: [email-masked]
Subject: Re: [MIPSHOP-MIH-DT] draft-melia-mipshop-mstp-solution-01a.txt

tele

---

From: <[email-masked]>
Date: Sun, 18 Nov 2007 20:59:40 -0600

Tele, Subir,

Please note that  [I-D.ietf-dnsop-dnssec-operational-practices] is
RFC4641, so please refer to this RFC number instead. And add the RFC to
the informative references section.

- gabor

-----Original Message-----
From: ext Subir Das [mailto:[email-masked]] 
Sent: Tuesday, November 13, 2007 3:03 PM
To: Telemaco Melia
Cc: [email-masked]
Subject: Re: [MIPSHOP-MIH-DT] draft-melia-mipshop-mstp-solution-01a.txt

Tele,
Here is the updated Security section that is fine with Yoshi. However,
he suggests to add the capability to know the security protocol of
choice at the server side during discovery. I discussed with Gabor and
he will look into this and find if it can be done by defining a new
NAPTR, otherwise I will discuss with Yoshi again and update to you.

   In case where DHCP is used for node discovery and authentication of
   the source and content of DHCP messages are required, it is
recommended
   to use either DHCP authentication option described in [RFC3118],
where
   available or rely upon link layer security.  This will also protect
the
   denial of service attacks to DHCP server.[RFC3118] provides
mechanisms
   for both entity authentication and message authentication.

transport

Telemaco Melia wrote:
> Guys,
> file:///C:/Documents%20and%20Settings/subir/Desktop/GDQ%20Corporate%20
> Directory.lnk <cid:[email-masked]>
> - Do not mandate anything to .21 on the use of MIHFIDs: SOLVED The 
> text has been removed accordingly
>
> - mandate both TCP/UDP server side and leave it optional for MN" 
> SOLVED Text has been added at the end of section 6.

---

From: Subir Das <[email-masked]>
Date: Mon, 19 Nov 2007 13:39:54 -0500

Gabor,
Thanks. I will update it if not done by Tele already.

-Subir