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

[Telemaco Melia <[e-mail]>]

Fine. I ll update the doc following your suggestions.
Robert any chance to formalize the comments you had?
I plan to have the doc ready for submission by Monday noon.

Tele

Heejin Jang wrote:
> I agree.
>  
> As some of folks already  know, there has been some proposal regarding pre-authentication in 802.21
> and a study group for security may be created in 802.21.
> I think we'd rather not mandate the IP-layer security mechanism.
> (Hope it's not too late. :-) )
>  
> - Regards
> Heejin.
>  
>
> ------- Original Message -------
> Sender : Zuniga, Juan Carlos<[e-mail]>
> Date   : 2007-04-28 02:29
> Title  : RE: [MIPSHOP-MIH-DT] PS doc -- 01 version
>
> v\:* {behavior:url(#default#VML);}o\:* {behavior:url(#default#VML);}w\:* {behavior:url(#default#VML);}.shape {behavior:url(#default#VML);}st1\:*{behavior:url(#default#ieooui) }     Hello, Thanks for the good work Tele.  The only question that I have is if wecould relax the security requirements from &#8220;must&#8221; to &#8220;couldor may&#8221;.  In 802.21 there are talks about carryingout some security tasks in the future, so I think that is best if we do notreinforce it here, in case that the function is carried out elsewhere (i.e. inthe MIH itself). This is how it reads now: In 5.2:       The security mechanism must provide mutual authentication of MN and NN      and it may provide one way authentication of either of MN and NN.  In 6:    Information Services may not require authorization of the client, but   both event and command services must authenticate message sources,   particularly if they are mobile.   Anyone else from 21 would like to commenton this? Besides that, it looks fine to me. Regards, Jc From: Robert Hancock [mailto:[e-mail]] 
> Sent: April 27, 2007 11:32 AM
> To: 'Sam Xia'; 'Telemaco Melia'
> Cc: [e-mail]
> Subject: RE: [MIPSHOP-MIH-DT] PSdoc -- 01 version tele, we have some minor comments. i can'tformalise them right now but will try to send something over the weekend. r. From: Sam Xia[mailto:[e-mail]] 
> Sent: 27 April 2007 14:19
> To: 'Telemaco Melia'
> Cc: [e-mail]
> Subject: RE: [MIPSHOP-MIH-DT] PSdoc -- 01 versionhi, tele, i have 3 comments as follows: 1: there is typos error in the paragraphabout discovery requirement. "dscovery" is duplicated. 2: i think that the list of requirementsis not arranged in order. for example, we should put transportationrequirements togeter, security requirements together, discovery requriementtogethter, just as .21 does. 3:  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.  i think how to deliver the mobilityservice information is determined by the MIH user. the MSTP must providesecurity mechanism to protect service information. but this does not mean thatthe mobility service information must be delivered securely. 
>  BestRegards, Sam Xia   From: TelemacoMelia [mailto:[e-mail]] 
> Sent: Friday, April 27, 2007 3:13PM
> To: [e-mail]
> Subject: Re: [MIPSHOP-MIH-DT] PSdoc -- 01 versionHi folks,
>
> Sorry to insist but we need to push this forward.
> Can we get consensus soon (today?) about the introduced changes, especiallysection 5.2?
>
> telemaco
>
> Telemaco Melia wrote: Hi all, 
>
> Please find attached a revised version of the PS document. Comments from peopleshould be hopefully  reflected. 
> I told Stefano that a final version for submission will be ready by Friday, soplease send comments with proposed text to avoid lengthly discussions. 
> Please pay particular attention to section 5.2 (see Yoshi's email). Also thetitle of the doc is changed according to Alper's comment (it is in line withthe terminology agreed in Prague).
>
> cheers, 
> telemaco 
>
>
>
>
>     MIPSHOP                                                         T. MeliaInternet-Draft                                                       NECIntended status: Informational                               E. HepworthExpires: 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: [phone]   Email: [e-mail]     Eleanor Hepworth   Siemens Roke Manor Research   Roke Manor   Romsey,   SO51 5RE   UK    Email: [e-mail]     Srivinas Sreemanthula   Nokia Research Center   6000 Connection Dr.   Irving,   TX 75028   USA    Email: [e-mail]         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: [e-mail]     Vivek Gupta   Intel Corporation   2111 NE 25th Avenue   Hillsboro, OR  97124   USA    Phone: [phone]   Email: [e-mail]     Jouni Korhonen   TeliaSonera Corporation.   P.O.Box 970   FIN-00051 Sonera   FINLAND    Phone: [phone]   Email: [e-mail]     Rui L.A. Aguiar   Instituto de Telecomunicacoes Universidade de Aveiro   Aveiro  3810   Portugal    Phone: [phone]   Email: [e-mail]     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: [phone]   Email: [e-mail]     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   [e-mail].  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 [e-mail]://www1.ietf.org/mailman/listinfo/mipshop-mih-dt  
>
>
> -- Dr. Telemaco Melia                 [e-mail] Research Staff Member               Tel: [phone]NEC Europe Ltd.                            Fax: [phone]Network Laboratories                       Web: http://www.netlab.nec.deKurfuersten-Anlage 36                             69115 HeidelbergGERMANY    NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London W3 6BL | Registered in England 2832014  


-- 
Dr. Telemaco Melia			[e-mail]
Senior Research Staff Member		Tel: [phone]
NEC Europe Ltd.				Fax: [phone]
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 



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