Re: [MIPSHOP-MIH-DT] PS doc -- 01 version

Hi folks,

Sorry to insist but we need to push this forward.
Can we get consensus soon (today?) about the introduced changes, 
especially section 5.2?

telemaco

Telemaco Melia wrote:
> Hi all,
>
> Please find attached a revised version of the PS document. Comments 
> from people should be hopefully  reflected.
> I told Stefano that a final version for submission will be ready by 
> Friday, so please send comments with proposed text to avoid lengthly 
> discussions.
> Please pay particular attention to section 5.2 (see Yoshi's email). 
> Also the title of the doc is changed according to Alper's comment (it 
> is in line with the terminology agreed in Prague).
>
> cheers,
> telemaco
>
>
>
> ------------------------------------------------------------------------
>
>
>
>
> MIPSHOP                                                         T. Melia
> Internet-Draft                                                       NEC
> Intended status: Informational                               E. Hepworth
> Expires: October 27, 2007                    Siemens Roke Manor Research
>                                                          S. Sreemanthula
>                                                    Nokia Research Center
>                                                                  Y. Ohba
>                                                                  Toshiba
>                                                                 G. Vivek
>                                                                    Intel
>                                                              J. Korhonen
>                                                              TeliaSonera
>                                                                R. Aguiar
>                                                                       IT
>                                                        Sam(Zhongqi). Xia
>                                                                   HUAWEI
>                                                           April 25, 2007
>
>
>              Mobility Services Transport: Problem Statement
>                       draft-ietf-mipshop-mis-ps-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 October 27, 2007.
>
> Copyright Notice
>
>
>
> Melia, et al.           Expires October 27, 2007                [Page 1]
> 
> Internet-Draft         Mobility Services Transport            April 2007
>
>
>    Copyright (C) The IETF Trust (2007).
>
> Abstract
>
>    There are on-going activities in the networking community to develop
>    solutions that aid in IP handover mechanisms between heterogeneous
>    wired and wireless access systems including, but not limited to, IEEE
>    802.21.  Intelligent access selection, taking into account link layer
>    attributes, requires the delivery of a variety of different
>    information types to the terminal from different sources within the
>    network and vice-versa.  The protocol requirements for this
>    signalling have both transport and security issues that must be
>    considered.  The signalling must not be constrained to specific link
>    types, so there is at least a common component to the signalling
>    problem which is within the scope of the IETF.  This draft presents a
>    problem statement for this core problem.
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> Melia, et al.           Expires October 27, 2007                [Page 2]
> 
> Internet-Draft         Mobility Services Transport            April 2007
>
>
> Table of Contents
>
>    1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
>    2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  4
>    3.  Definition of Mobility Services  . . . . . . . . . . . . . . .  5
>    4.  Deployment Scenarios for MoS . . . . . . . . . . . . . . . . .  5
>      4.1.  End-to-End Signalling and Transport over IP  . . . . . . .  6
>      4.2.  End-to-End Signalling and Partial Transport over IP  . . .  6
>      4.3.  End-to-End Signalling with a Proxy . . . . . . . . . . . .  7
>      4.4.  End-to-End Network-to-Network Signalling . . . . . . . . .  7
>    5.  MoS Transport Protocol Splitting . . . . . . . . . . . . . . .  8
>      5.1.  Payload Formats and Extensibility Considerations . . . . .  9
>      5.2.  Requirements on the Mobility Service Transport Layer . . .  9
>    6.  Security Considerations  . . . . . . . . . . . . . . . . . . . 14
>    7.  Conclusions  . . . . . . . . . . . . . . . . . . . . . . . . . 15
>    8.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
>    Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16
>    Intellectual Property and Copyright Statements . . . . . . . . . . 18
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> Melia, et al.           Expires October 27, 2007                [Page 3]
> 
> Internet-Draft         Mobility Services Transport            April 2007
>
>
> 1.  Introduction
>
>    This Internet Draft provides a problem statement for the exchange of
>    information to support handover in heterogeneous link environments.
>    This mobility support service allows more sophisticated handover
>    operations by making available information about network
>    characteristics, neighboring networks and associated characteristics,
>    indications that a handover should take place, and suggestions for
>    suitable target networks to which to handover.  The mobility support
>    services work complementarily with IP mobility mechanisms to enhance
>    the overall performance and usability perception.
>
>    There are two key attributes to the handover support service problem
>    for inter-technology handovers:
>
>    1.  The Information: the information elements being exchanged.  The
>        messages could be of different nature, such as Information,
>        Command or Event, potentially being defined following a common
>        structure.
>
>    2.  The Underlying Transport: the transport mechanism to support
>        exchange of the information elements mentioned above.  This
>        transport mechanism includes information transport, discovery of
>        peers, and the securing of this information over the network.
>
>    This draft has been motivated by on-going work within IEEE 802.21
>    [1], but the following description intentionally describes the
>    problem from a more general perspective.  This document represents
>    the views of the authors, and does not represent the official view of
>    IEEE 802.21.
>
>    The structure of this document is as follows.  Section 3 defines
>    mobility services.  Section 4 provides a simple model for the
>    protocol entities involved in the signalling and their possible
>    relationships.  Section 5 describes a decomposition of the signalling
>    problem into service specific parts and a generic transport part.
>    Section 5.2 describes more detailed requirements for the transport
>    component.  Section 6 provides security considerations, and Section 7
>    summarizes the conclusions and open issues.
>
>
> 2.  Terminology
>
>    The following abbreviations are used in the document:
>
>    o  MIH: media independent handover
>
>
>
>
>
> Melia, et al.           Expires October 27, 2007                [Page 4]
> 
> Internet-Draft         Mobility Services Transport            April 2007
>
>
>    o  MN: mobile node
>
>    o  NN: network node, intended to represent some device in the network
>       (the location of the node e.g. in the access network, home network
>       is not specified, and for the moment it is assumed that they can
>       reside anywhere).
>
>    o  EP: endpoint, intended to represent the terminating endpoints of
>       the transport protocol used to support the signalling exchanges
>       between nodes.
>
>
> 3.  Definition of Mobility Services
>
>    As mentioned in the introduction mobility (handover) support in
>    heterogeneous wireless environments requires functional components
>    located either in the mobile terminal or in the (access) network to
>    exchange information and eventually to take decisions upon this
>    information exchange.  For instance traditional host-based handover
>    solutions could be complemented with more sophisticated network-
>    centric solutions reducing terminal complexity.  Also, neighborhood
>    discovery, potentially a complex operation in heterogeneous wireless
>    scenarios, can result in a more simple step if implemented with an
>    unified interface towards the access network.
>
>    In this document the different supporting functions for media
>    independent handover (MIH) management are generally referred as
>    Mobility Services (MoS) having in common different requirements for
>    the transport protocol.  These requirements and associated
>    functionalities are the focus of this document
>
>
> 4.  Deployment Scenarios for MoS
>
>    The deployment scenarios are outlined in the following sections.
>    Note: while MN-to-MN signalling exchanges are theoretically possible,
>    these are not currently being considered.
>
>    The following scenarios are discussed for understanding the overall
>    problem of transporting MIH protocol.  Although these are all
>    possible scenarios and MIH services can be delivered through link-
>    layer specific solutions and/or through a "layer 3 or above"
>    protocol, this problem statement focuses on the delivery of
>    information for MIH services for the latter case only.
>
>
>
>
>
>
>
> Melia, et al.           Expires October 27, 2007                [Page 5]
> 
> Internet-Draft         Mobility Services Transport            April 2007
>
>
> 4.1.  End-to-End Signalling and Transport over IP
>
>    In this case, the end-to-end signalling used to exchange the handover
>    information elements (the Information Exchange) runs end-to-end
>    between MN and NN.  The underlying transport is also end-to-end
>
>            +------+                              +------+
>            |  MN  |                              |  NN  |
>            | (EP) |                              | (EP) |
>            +------+                              +------+
>                         Information Exchange
>                <------------------------------------>
>
>                /------------------------------------\
>               <          Transport over IP           >
>                \------------------------------------/
>
>                Figure 1: End-to-end Signalling and Transport
>
> 4.2.  End-to-End Signalling and Partial Transport over IP
>
>    As before, the Information Exchange runs end-to-end between the MN
>    and the second NN.  However, in this scenario, some other transport
>    means than IP is used from the MN to the first NN, and the transport
>    over IP is used only between NNs.  This is analogous to the use of
>    EAP end-to-end between Supplicant and Authentication Server, with an
>    upper-layer multihop protocol such as RADIUS used as a backhaul
>    transport protocol between an Access Point and the Authentication
>    Server.
>
>
>            +------+           +------+           +------+
>            |  MN  |           |  NN  |           |  NN  |
>            |      |           | (EP) |           | (EP) |
>            +------+           +------+           +------+
>                         Information Exchange
>                <------------------------------------>
>
>                 (Transport over  /------------------\
>                <--------------->< Transport over IP  >
>                     e.g. L2)     \------------------/
>
>                         Figure 2: Partial Transport
>
>
>
>
>
>
>
>
> Melia, et al.           Expires October 27, 2007                [Page 6]
> 
> Internet-Draft         Mobility Services Transport            April 2007
>
>
> 4.3.  End-to-End Signalling with a Proxy
>
>    In the final case, a number of proxies are inserted along the path
>    between the two transport endpoints.  The use of proxies is possible
>    in both cases 1 and 2 above, but distinguished here as there are a
>    number of options as to how the proxy may behave with regard to the
>    transport and end-to-end signalling exchange.
>
>    In this case, the proxy performs some processing on the Information
>    Exchange before forwarding the information on.  This can be viewed as
>    concatenating signalling exchanges between a number of EPs.
>
>            +------+         +---------+          +------+
>            |  MN  |         | ProxyNN |          |  NN  |
>            | (EP) |         |   (EP)  |          | (EP) |
>            +------+         +---------+          +------+
>                        Information Exchange
>               ------------------>
>                                 ------------------->
>                                 <-------------------
>               <------------------
>               /---------------\     /----------------\
>              <    Transport    >   <    Transport     >
>               \---------------/     \----------------/
>
>                   Figure 3: Information Exchange Approach
>
>    The Proxy NN might process all layers of the protocol suite in the
>    same way as an ordinary EP.
>
>    There is a possibility for realizing other proxy scenarios.
>
> 4.4.  End-to-End Network-to-Network Signalling
>
>    In this case NN to NN signalling is envisioned.  Such model should
>    allow different network components to gather information from each
>    other.  This is useful for instance in conditions where network
>    components need to take decisions and instruct mobile terminals of
>    operation to be executed.
>
>
>
>
>
>
>
>
>
>
>
>
> Melia, et al.           Expires October 27, 2007                [Page 7]
> 
> Internet-Draft         Mobility Services Transport            April 2007
>
>
>                  +------+          +------+
>                  |  NN  |          |  NN  |
>                  | (EP) |          | (EP) |
>                  +------+          +------+
>                     Information Exchange
>                     ------------------->
>                     <-------------------
>
>                     /----------------\
>                    <    Transport     >
>                     \----------------/
>
>             Figure 4: Information Exchange between different NN
>
>    Network nodes exchange information about connected terminals status.
>
>
> 5.  MoS Transport Protocol Splitting
>
>    Figure 5 shows a model where the Information Exchanges are
>    implemented by a signalling protocol specific to a particular
>    mobility service, and these are relayed over a generic transport
>    layer (the Mobility Service Transport Layer).
>
>
>                           +----------------+          ^
>                           |Mobility Support|          |
>                           |   Service 2    |          |
>        +----------------+ |                |          | Mobility Service
>        |Mobility Support| +----------------+          |    Signaling
>        |    Service 1   |    +----------------+       |      Layer
>        |                |    |Mobility Support|       |
>        +----------------+    |   Service 3    |       |
>                              |                |       |
>                              +----------------+       V
>      ================================================
>         +---------------------------------------+     ^ Mobility Service
>         |  Mobility Service Transport Protocol  |     |    Transport
>         +---------------------------------------+     V      Layer
>      ================================================
>         +---------------------------------------+
>         |                   IP                  |
>         +---------------------------------------+
>
>                     Figure 5: Handover Services over IP
>
>    The Mobility Service Transport Layer provides certain functionality
>    (outlined in Section 5.2) to the higher layer mobility support
>
>
>
> Melia, et al.           Expires October 27, 2007                [Page 8]
> 
> Internet-Draft         Mobility Services Transport            April 2007
>
>
>    services in order to support the exchange of information between
>    communicating mobility service functions.  The transport layer
>    effectively provides a container capability to mobility support
>    services, as well as any required transport and security operations
>    required to provide communication without regard to the protocol
>    semantics and data carried in the specific mobility services.
>
>    The Mobility Support Services themselves may also define certain
>    protocol exchanges to support the exchange of service specific
>    Information Elements.  It is likely that the responsibility for
>    defining the contents and significance of the Information Elements is
>    the responsibility of other standards bodies other than the IETF.
>    Example mobility services include the Information Services, Event and
>    Command services.
>
> 5.1.  Payload Formats and Extensibility Considerations
>
>    The format of the Mobility Service Transport Protocol is as follows:
>
>    +----------------+----------------------------------------+
>    |Mobility Service|           Opaque Payload               |
>    |Transport Header|     (Mobility Support Service)         |
>    +----------------+----------------------------------------+
>
>                        Figure 6: Protocol Structure
>
>    The opaque payload encompasses the Mobility Support Service
>    information that is to be transported.  The definition of the
>    Mobility Service Transport Header is something that is best addressed
>    within the IETF.  MSTP does not inspect the payload and any required
>    information will be provided by the MSTP users.
>
> 5.2.  Requirements on the Mobility Service Transport Layer
>
>    The following section outlines some of the general transport
>    requirements that should be supported by the Mobility Service
>    Transport Protocol.  Analysis has suggested that at least the
>    following need to be taken into account:
>
>    Discovery:  Discovery: MNs need the ability to either discover nodes
>       that support certain services, or discover services provided by a
>       certain node.  The service discovery can be dealt with messages as
>       defined in [1].  This section refers to node-discovery in either
>       scenario.  There are no assumptions about the location of these
>       mobility services within the network, therefore the discovery
>       mechanism needs to operate across administrative boundaries.
>       Issues such as speed of discovery, protection against spoofing,
>       when discovery needs to take place, and the length of time over
>
>
>
> Melia, et al.           Expires October 27, 2007                [Page 9]
> 
> Internet-Draft         Mobility Services Transport            April 2007
>
>
>       which the discovery information may remain valid all need to be
>       considered.  Approaches include:
>
>       *  Hard coding information into the MN, indicating either the IP
>          address of the NN, or information about the NN that can be
>          resolved onto an IP address.  The configuration information
>          could be managed dynamically, but assumes that the NN is
>          independent of the access network to which the MN is currently
>          attached.
>
>       *  Pushing information to the MN, where the information is
>          delivered to the MN as part of other configuration operations,
>          for example, in a Router Discovery exchange.  The benefit of
>          this approach is that no additional exchanges with the network
>          would be required, but the limitations associated with
>          modifying these protocols may limit applicability of the
>          solution.
>
>       *  MN dynamically requesting information about a node, which may
>          require both MN and NN support for a particular service
>          discovery mechanism.  This may require additional support by
>          the access network (e.g. multicast or anycast) even when it may
>          not be supporting the service directly itself.
>
>       Numerous directory and configuration services already exist, and
>       reuse of these mechanisms may be appropriate.  There is an open
>       question about whether multiple methods of discovery would be
>       needed, and whether NNs would also need to discover other NNs.
>       The definition of a service also needs to be determined, including
>       the granularity of the description (for example, should the MN
>       look for an "IS" service, or "IS-local information", and "IS-home
>       network information" services.
>
>    Information from a trusted source:  The MN uses the Mobility Service
>       information to make decisions about what steps to take next.  It
>       is essential that there is some way to ensure that the information
>       received is from a trustworthy source.  This requirement should
>       reuse trust relationships that have already been established in
>       the network, for example, on the relationships established by the
>       AAA infrastructure after a mutual authentication, or on the
>       certificate infrastructure required to support SEND [9].  The
>       security mechanism must provide mutual authentication of MN and NN
>       and it may provide one way authentication of either of MN and NN.
>
>    Security association management:  A common security association
>       negotiation method, independent of any specific MSTP user, must be
>       implemented.  The solution must also work in case on MN mobility.
>
>
>
>
> Melia, et al.           Expires October 27, 2007               [Page 10]
> 
> Internet-Draft         Mobility Services Transport            April 2007
>
>
>    Low latency:  Some of the Mobility Services generate time sensitive
>       information.  Therefore, there is a need to deliver the
>       information over quite short timescales, and the required lifetime
>       of a connection might be quite short lived.  For reliable
>       delivery, short-lived connections could be set up as and when
>       needed, although there is a connection setup latency associated
>       with this approach.  Alternatively, a long-lived connection could
>       be used, but this requires advanced warning of being needed and
>       some way to maintain the state associated with the connection.  It
>       also assumes that the relationships between devices supporting the
>       mobility service are fairly stable.  Another alternative is
>       connectionless operation, but this has interactions with other
>       requirements such as reliable delivery.
>
>    Reliability:  Reliable delivery for some of the mobility services may
>       be essential, but it is difficult to trade this off against the
>       low latency requirement.  It is also quite difficult to design a
>       robust, high performance mechanism that can operate in
>       heterogeneous environments, especially one where the link
>       characteristics can vary quite dramatically.  There are two main
>       approaches that could be adopted:
>
>       1.  Assume the transport cannot be guaranteed to support reliable
>           delivery.  In this case, the Mobility Support Service itself
>           will have to provide some sort of reliability mechanism to
>           allow communicating endpoints to acknowledge receipt of
>           information.
>
>       2.  Assume the underlying transport will deal with most error
>           situations, and provide a very basic acknowledgement mechanism
>           that (if no acknowledgement is received) will indicate that
>           something more serious has occurred than a packet drop (since
>           these other types of error conditions are dealt with at the
>           transport layer).
>
>    Congestion Control:  A Mobility Service may optionally wish to
>       transfer large amounts of data, placing a requirement for
>       congestion control in the transport.  There is an interaction
>       between this requirement and that of the requirement for low
>       latency since ways to deal with timely delivery of smaller
>       asynchronous messages around the larger datagrams is required
>       (mitigation of head of line blocking etc.).
>
>    Secure delivery:  The Mobility Service information must be delivered
>       securely (integrity and confidentiality) between trusted peers,
>       where the transport may pass though untrusted intermediate nodes
>       and networks.  The Mobility Service information must also be
>       protected against replay attacks and denial of service attacks.
>
>
>
> Melia, et al.           Expires October 27, 2007               [Page 11]
> 
> Internet-Draft         Mobility Services Transport            April 2007
>
>
>    Multiplexing:  The transport service needs to be able to support
>       different mobility services.  This may require multiplexing and
>       the ability to manage multiple discovery operations and peering
>       relationships in parallel.
>
>    Multihoming:  For some information services exchanged with the MN,
>       there is a possibility that the request and response messages can
>       be carried over two different links e.g. a handover command
>       request is on the current link while the response could be
>       delivered on the new link.  Depending on the IP mobility
>       mechanism, there is some impact on the transport option for the
>       mobility information services.  This may potentially have some
>       associated latency and security issues, for example, if the
>       transport is over IP there is some transparency but Mobile IP may
>       introduce additional delay and both TCP and UDP must use the
>       permanent address of the MN.
>
>    IPv4 and IPv6 support:  The MSTP must support both IPv4 and IPv6
>       including NAT traversal for IPv4 networks and firewall pass-
>       through for IPv4 and IPv6 networks.
>
>    In addition to the above, it may be necessary for the transport to
>    support multiple applications (or modes of operation) to support the
>    particular requirements of the Information Exchange being carried out
>    between nodes.  This may require the ability to multiplex multiple
>    information exchanges into a single transport exchange (see figure
>    Figure 7) .
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> Melia, et al.           Expires October 27, 2007               [Page 12]
> 
> Internet-Draft         Mobility Services Transport            April 2007
>
>
> +==================================+
> |                                  |
> | +------------+  +-----------+    |
> | |    MIH     |  |   MIH     |    |
> | |   User 1   |  |  User 2   |... |
> | |  e.g. MIP  |  |  e.g. SIP |    |
> | ++++++++++++++  +++++++++++++    |  _    ..............
> |      \                /          |   \__ :    MIH     :
> |       \              /           |  _/   :Multiplexing:
> |     +++++++++++++++++++++        |       :............:
> |     |   MIH Function    |        |
> |     |    (e.g. MIS)     |        |
> |     +++++++++++++++++++++        |
> |               /\                 |
> |               ||                 |          ..............
> |               ||                 |          : Transport  :
> |               \/                 |          :Multiplexing:
> |     +++++++++++++++++++++        |          :............:    +---------+
> |     |     Transport     |        |               ____/\____   |   MIH   |
> |     | (e.g. TCP, UDP)   |        |              /          \  |.........|
> |     +++++++++++++++++++++        |                            |Transport|
> |               /\                 |                            |.........|
> |               ||                 |                       _____|   IP    |
> |               ||                 |                      /     +=========+
> |               ||                 |                     /
> |               \/                 |    ^+++++++++^     /       +---------+
> |     +++++++++++++++++++++        |   /           \   /        |   MIH   |
> |     |         IP        |--------|--<  Internet   > -----     |.........|
> |     +++++++++++++++++++++        |   \           /   |   \    |Transport|
> |                                  |    v+++++++++v    |    \   |.........|
> |                                  |                   |     \__|   IP    |
> +==================================+                   |        +=========+
>                                                        |             :
>                                                        |             :
>                                                        |        +---------+
>                                                        |        |   MIH   |
>                                                        |        |.........|
>                                                        |        |Transport|
>                                                        |        |.........|
>                                                        |________|   IP    |
>                                                                 +=========+
>
>                       Figure 7: Multiplexing examples
>
>
>
>
>
>
>
>
> Melia, et al.           Expires October 27, 2007               [Page 13]
> 
> Internet-Draft         Mobility Services Transport            April 2007
>
>
> 6.  Security Considerations
>
>    Network supported mobility services aim at improving decision making
>    and management of dynamically connected hosts.  The control and
>    maintenance of mobile nodes becomes challenging where authentication
>    and authorization credentials used to access a network are
>    unavailable for the purpose of bootstrapping a security association
>    for handover services.
>
>    Information Services may not require authorization of the client, but
>    both event and command services must authenticate message sources,
>    particularly if they are mobile.  Network side service entities will
>    typically need to provide proof of authority to serve visiting
>    devices.  Where signalling or radio operations can result from
>    received messages, significant disruption may result from processing
>    bogus or modified messages.  The effect of processing bogus messages
>    depends largely upon the content of the message payload, which is
>    handled by the handover services application.  Regardless of the
>    variation in effect, message delivery mechanisms need to provide
>    protection against tampering, and spoofing.
>
>    Sensitive and identifying information about a mobile device may be
>    exchanged during handover service message exchange.  Since handover
>    decisions are to be made based upon message exchanges, it may be
>    possible to trace an user's movement between cells, or predict future
>    movements, by inspecting handover service messages.  In order to
>    prevent such tracking, message confidentiality should be available.
>    This is particularly important since many mobile devices are
>    associated with only one user, as divulgence of such information may
>    violate the user's privacy.  Additionally, identifying information
>    may be exchanged during security association construction.  As this
>    information may be used to trace users across cell boundaries,
>    identity protection should be available if possible, when
>    establishing SAs.
>
>    In addition, the user should not have to disclose its identity to the
>    network (any more than it needed to during authentication) in order
>    to access the Mobility Support Services.  For example, if the local
>    network is just aware that an anonymous user with a subscription to
>    operatorXYX.com is accessing the network, the user should not have to
>    divulge their true identity in order to access the Mobility Support
>    Services available locally.
>
>    Finally, the network nodes themselves will potentially be subject to
>    denial of service attacks from MNs and these problems will be
>    exacerbated if operation of the mobility service protocols imposes a
>    heavy computational load on the NNs.  The overall design has to
>    consider at what stage (e.g. discovery, transport layer
>
>
>
> Melia, et al.           Expires October 27, 2007               [Page 14]
> 
> Internet-Draft         Mobility Services Transport            April 2007
>
>
>    establishment, service specific protocol exchange) denial of service
>    prevention or mitigation should be built in.
>
>
> 7.  Conclusions
>
>    This Internet draft outlined a broad problem statement for the
>    signalling of information elements across a network to support media
>    independent handover services.  In order to enable this type of
>    signalling service, a need for a generic transport solution with
>    certain transport and security properties were outlined.  Whilst the
>    motivation for considering this problem has come from work within
>    IEEE 802.21, a desirable goal is to ensure that solutions to this
>    problem are applicable to a wider range of mobility services.
>
>    It would be valuable to establish realistic performance goals for the
>    solution to this common problem (i.e. transport and security aspects)
>    using experience from previous IETF work in this area and knowledge
>    about feasible deployment scenarios.  This information could then be
>    used as an input to other standards bodies in assisting them to
>    design mobility services with feasible performance requirements.
>
>    Much of the functionality required for this problem is available from
>    existing IETF protocols or combination thereof.  This document takes
>    no position on whether an existing protocol can be adapted for the
>    solution or whether new protocol development is required.  In either
>    case, we believe that the appropriate skills for development of
>    protocols in this area lie in the IETF.
>
>
> 8.  References
>
>    [1]  "Draft IEEE Standard for Local and Metropolitan Area Networks:
>         Media Independent Handover Services", IEEE LAN/MAN Draft  IEEE
>         P802.21/D05.00, April 2007.
>
>    [2]  Aboba, B., "Architectural Implications of Link Indications",
>         draft-iab-link-indications-10 (work in progress), March 2007.
>
>    [3]  Perkins, C., "IP Mobility Support for IPv4", RFC 3344,
>         August 2002.
>
>    [4]  Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in
>         IPv6", RFC 3775, June 2004.
>
>    [5]  Moskowitz, R. and P. Nikander, "Host Identity Protocol (HIP)
>         Architecture", RFC 4423, May 2006.
>
>
>
>
> Melia, et al.           Expires October 27, 2007               [Page 15]
> 
> Internet-Draft         Mobility Services Transport            April 2007
>
>
>    [6]  Eronen, P., "IKEv2 Mobility and Multihoming Protocol (MOBIKE)",
>         RFC 4555, June 2006.
>
>    [7]  3GPP, "3GPP system architecture evolution (SAE): Report on
>         technical options and conclusions", 3GPP TR 23.882 0.10.1,
>         February 2006.
>
>    [8]  Koodli, R., "Fast Handovers for Mobile IPv6", RFC 4068,
>         July 2005.
>
>    [9]  Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure
>         Neighbor Discovery (SEND)", RFC 3971, March 2005.
>
>
> Authors' Addresses
>
>    Telemaco Melia
>    NEC Europe Network Laboratories
>    Kufuerstenanlage 36
>    Heidelberg  69115
>    Germany
>
>    Phone: +49 6221 90511 42
>    Email: telemaco.melia@netlab.nec.de
>
>
>    Eleanor Hepworth
>    Siemens Roke Manor Research
>    Roke Manor
>    Romsey,   SO51 5RE
>    UK
>
>    Email: eleanor.hepworth@roke.co.uk
>
>
>    Srivinas Sreemanthula
>    Nokia Research Center
>    6000 Connection Dr.
>    Irving,   TX 75028
>    USA
>
>    Email: srinivas.sreemanthula@nokia.com
>
>
>
>
>
>
>
>
>
> Melia, et al.           Expires October 27, 2007               [Page 16]
> 
> Internet-Draft         Mobility Services Transport            April 2007
>
>
>    Yoshihiro Ohba
>    Toshiba America Research, Inc.
>    1 Telcordia Drive
>    Piscateway  NJ 08854
>    USA
>
>    Email: yohba@tari.toshiba.com
>
>
>    Vivek Gupta
>    Intel Corporation
>    2111 NE 25th Avenue
>    Hillsboro, OR  97124
>    USA
>
>    Phone: +1 503 712 1754
>    Email: vivek.g.gupta@intel.com
>
>
>    Jouni Korhonen
>    TeliaSonera Corporation.
>    P.O.Box 970
>    FIN-00051 Sonera
>    FINLAND
>
>    Phone: +358 40 534 4455
>    Email: jouni.korhonen@teliasonera.com
>
>
>    Rui L.A. Aguiar
>    Instituto de Telecomunicacoes Universidade de Aveiro
>    Aveiro  3810
>    Portugal
>
>    Phone: +351 234 377900
>    Email: ruilaa@det.ua.pt
>
>
>    Sam(Zhongqi) Xia
>    Huawei Technologies Co.,Ltd
>    HuaWei Bld., No.3 Xinxi Rd. Shang-Di Information Industry Base,Hai-Dian District Beijing
>    100085
>    P.R. China
>
>    Phone: +86-10-82836136
>    Email: xiazhongqi@huawei.com
>
>
>
>
>
> Melia, et al.           Expires October 27, 2007               [Page 17]
> 
> Internet-Draft         Mobility Services Transport            April 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
>    ietf-ipr@ietf.org.
>
>
> Acknowledgment
>
>    Funding for the RFC Editor function is provided by the IETF
>    Administrative Support Activity (IASA).
>
>
>
>
>
> Melia, et al.           Expires October 27, 2007               [Page 18]
> 
>
>   
> ------------------------------------------------------------------------
>
> _______________________________________________
> MIPSHOP-MIH-DT mailing list
> MIPSHOP-MIH-DT@ietf.org
> https://www1.ietf.org/mailman/listinfo/mipshop-mih-dt
>   

-- 
Dr. Telemaco Melia			telemaco.melia@netlab.nec.de
Senior Research Staff Member		Tel: +49 (0) 6221 4342- 142
NEC Europe Ltd.				Fax: +49 (0) 6221 4342- 155
Network Laboratories			Web: http://www.netlab.nec.de
Kurfuersten-Anlage 36			       
69115 Heidelberg
GERMANY   

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