Re: [MIPSHOP-MIH-DT] PS doc -- 01 version
Subir Das <subir@research.telcordia.com> Mon, 30 April 2007 15:47 UTC
Return-path: <mipshop-mih-dt-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HiY6P-0004wK-Ej; Mon, 30 Apr 2007 11:47:49 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HiY6O-0004w6-Fn for mipshop-mih-dt@ietf.org; Mon, 30 Apr 2007 11:47:48 -0400
Received: from thumper.research.telcordia.com ([128.96.41.1]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HiY6L-0003Ac-6F for mipshop-mih-dt@ietf.org; Mon, 30 Apr 2007 11:47:48 -0400
Received: from mailee.research.telcordia.com (mailee [192.4.16.29]) by thumper.research.telcordia.com (8.13.6/8.13.5) with ESMTP id l3UFlY9e024363; Mon, 30 Apr 2007 11:47:34 -0400 (EDT)
Received: from [128.96.58.238] (vpntnlA238 [128.96.58.238]) by mailee.research.telcordia.com (8.9.3/8.9.3) with ESMTP id LAA28447; Mon, 30 Apr 2007 11:47:19 -0400 (EDT)
Message-ID: <46360F7C.4030109@research.telcordia.com>
Date: Mon, 30 Apr 2007 11:47:08 -0400
From: Subir Das <subir@research.telcordia.com>
User-Agent: Thunderbird 1.5.0.10 (Windows/20070221)
MIME-Version: 1.0
To: Telemaco Melia <telemaco.melia@netlab.nec.de>
Subject: Re: [MIPSHOP-MIH-DT] PS doc -- 01 version
References: <462F854D.2040609@netlab.nec.de> <4631A288.5010906@netlab.nec.de>
In-Reply-To: <4631A288.5010906@netlab.nec.de>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Spam-Score: 2.3 (++)
X-Scan-Signature: 1459dca363a7eac530b0f3f218abff0f
Cc: mipshop-mih-dt@ietf.org
X-BeenThere: mipshop-mih-dt@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: MIPSHOP Media Independent Handover Design Team List <mipshop-mih-dt.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/mipshop-mih-dt>, <mailto:mipshop-mih-dt-request@ietf.org?subject=unsubscribe>
List-Archive: <https://www1.ietf.org/mailman/private/mipshop-mih-dt>
List-Post: <mailto:mipshop-mih-dt@ietf.org>
List-Help: <mailto:mipshop-mih-dt-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/mipshop-mih-dt>, <mailto:mipshop-mih-dt-request@ietf.org?subject=subscribe>
Errors-To: mipshop-mih-dt-bounces@ietf.org
Tele, Sorry for the delay. Hope it is not too late. Inserted below with a few comments/suggestions. Search by my name. thanks, -Subir Telemaco Melia wrote: > 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 >> Subir>comment; I would say more than just access network above. Suggestion: Either we delete "(access)" or add "(access or core)" >> 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 >> Subir> Comment: Do we need both "common" and "different" above? >> 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. >> Subir>Suggestion: I would say "the delivery of information for mobility services" instead of "delivery of information for MIH services" >> >> >> >> >> >> >> 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 >> Subir> editorial: add (MSTP) after 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. Subir> comment: why not both node and service discovery? I understand the service discovery is not our scope but the first statement is generic. >> 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, Subir> editorial: may add "node" after mobility services above... >> 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: >> Subir> Comment: In general the following approaches fall into solution category. Do we need them in the problem statement document? May be I made this comment earlier. However, if the group feels that it will improve the clarity, I am fine. >> * 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. >> Subir> editorial: (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. >> Subir> The last part of the above sentence is not clear to me. Are we saying either mutual or one way authentication? >> Security association management: A common security association >> negotiation method, independent of any specific MSTP user, must be >> implemented. Subir>comment: I am not sure whether we can say "must be implemented"? In some cases, security association may be needed. suggestion: should is better. Or else, we should say if SAs are required, it should use the common one... >> 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. >> Subir> comment: 'must' have is too strong here. I am not sure how easy it will be to prevent DoS? Suggestion: 'Should' >> >> >> 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. Subir> comment: How do we conclude the above? The authorization part is not clear to me. Also having message authentication is a good idea but I am not sure if we need to say 'must' if they are mobile. suggestion; 'Should' is better. >> 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. Subir> editorial; may change above to "mobility services" instead of MIH 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 > ------------------------------------------------------------------------ > > _______________________________________________ > MIPSHOP-MIH-DT mailing list > MIPSHOP-MIH-DT@ietf.org > https://www1.ietf.org/mailman/listinfo/mipshop-mih-dt > _______________________________________________ MIPSHOP-MIH-DT mailing list MIPSHOP-MIH-DT@ietf.org https://www1.ietf.org/mailman/listinfo/mipshop-mih-dt
- [MIPSHOP-MIH-DT] PS doc -- 01 version Telemaco Melia
- Re: [MIPSHOP-MIH-DT] PS doc -- 01 version Telemaco Melia
- RE: [MIPSHOP-MIH-DT] PS doc -- 01 version Sam Xia
- RE: [MIPSHOP-MIH-DT] PS doc -- 01 version Robert Hancock
- RE: [MIPSHOP-MIH-DT] PS doc -- 01 version Zuniga, Juan Carlos
- Re: [MIPSHOP-MIH-DT] PS doc -- 01 version Subir Das
- Re: [MIPSHOP-MIH-DT] PS doc -- 01 version Telemaco Melia
- Re: RE: [MIPSHOP-MIH-DT] PS doc -- 01 version Heejin Jang
- Re: [MIPSHOP-MIH-DT] PS doc -- 01 version Telemaco Melia