Network Working Group S. Sreemanthula (Ed.) Internet-Draft Nokia Expires: September 7, 2006 G. Daley Panasonic S. Faccin Nokia E. Hepworth Siemens/Roke Manor Research S. Das Telcordia March 06, 2006 Requirements for a Handover Information Service draft-faccin-mih-infoserv-02.txt 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 September 7, 2006. Copyright Notice Copyright (C) The Internet Society (2006). Abstract Handover Information Services may be used to assist handovers between Sreemanthula (Ed.), et al. Expires September 7, 2006 [Page 1] Internet-Draft Requirements for an IS March 2006 one network to another network or within a network, based on stored network knowledge. Information Services can be used to provide essential network related information e.g. topology and channel information which may allow a moving host to select an appropriate link-layer connection to make, amongst available networks, whether using the same technology or heterogeneous technologies. This document is an effort to describe use cases and transport requirements for handover information services, when they are transported over IP networks. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Information Services . . . . . . . . . . . . . . . . . . . 3 1.2. Scope of work on information services . . . . . . . . . . 3 2. 802.21 Media Independent Information Services . . . . . . . . 4 3. Information Service Reference Model . . . . . . . . . . . . . 4 4. Scenarios for IS Transported over IP . . . . . . . . . . . . . 5 5. Protocol Development Scope . . . . . . . . . . . . . . . . . . 8 5.1. Information Service Interfaces . . . . . . . . . . . . . . 9 5.2. Message Exchanges . . . . . . . . . . . . . . . . . . . . 10 5.3. Information Service Discovery . . . . . . . . . . . . . . 11 5.4. Transport-Layer Issues . . . . . . . . . . . . . . . . . . 12 5.5. Security Association Negotiation . . . . . . . . . . . . . 13 6. Requirements for Transport over IP . . . . . . . . . . . . . . 13 7. Security Considerations . . . . . . . . . . . . . . . . . . . 15 7.1. Attacks against service entities . . . . . . . . . . . . . 15 7.2. Attacks against information . . . . . . . . . . . . . . . 16 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 9.1. Normative References . . . . . . . . . . . . . . . . . . . 17 9.2. Informative References . . . . . . . . . . . . . . . . . . 17 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20 Intellectual Property and Copyright Statements . . . . . . . . . . 22 Sreemanthula (Ed.), et al. Expires September 7, 2006 [Page 2] Internet-Draft Requirements for an IS March 2006 1. Introduction Handover services are a class of network services, which aim to assist the quality of handovers available to wireless devices. In order to support more intelligent handover services it is often necessary to be able to exchange information between mobile and fixed nodes within the network. A comprehensive description of the problem related to this aspect can be found in [2]. Information Services (IS) are one part of handover services used to provide network related information about the current or neighboring networks with same or different access link technology. This allows the network or host to make informed decisions of which network to handover to or handover operations to undertake either in response to certain events, or when planning controlled or commanded handovers. The Information Services work complementary to the mobility management protocols in the capacity that they are utilized before making decisions for handovers. While the IETF is primarily interested in how handover services can be used to assist mobility signaling protocols, and interactions between handover services and network/transport layers, other groups have been taking a more generally applicable view (see Section 2). 1.1. Information Services Information Services are considered to be an important component of handover services, for providing local network information to wireless devices in a non-real-time fashion [1]. Information services provide additional information about the environment a mobile device is operating in. These services typically require one or more servers within a set of access networks, which distribute knowledge that can assist hosts performing handovers between cells. Information provided varies dependent on the purpose and operation of the information service, but may consist of: wireless channel state, adjacent base-station channel occupation, neighboring network information or upper-layer mobility service information. While each of these is possible, it is important to note that information services described in this document have a restricted scope described below in Section 1.2. This scope is limited in order to achieve timely outcomes for document development and standardization. 1.2. Scope of work on information services The development of information services covered in this document Sreemanthula (Ed.), et al. Expires September 7, 2006 [Page 3] Internet-Draft Requirements for an IS March 2006 assume a set of models compatible with IEEE 802.21's descriptions of a Handover Information Service,as described in Section 2. In this context, a system would need to provide discovery, security association bootstrap and transport of information services over IP, in a variety of deployment scenarios. These scenarios are described in Section 4. The extent of protocol development work to be undertaken is elaborated on in Section 5. Initial specification of use cases will focus on delivery services required by the existing client (802.21), in the hope that the scheme is general enough to be of use in the other cases [1]. 2. 802.21 Media Independent Information Services IEEE is currently working on Information Services as part of 802.21 Media Independent Handover Services (MIHS). Amongst media independent handover services, information services are most readily deployed over IP [1]. In the 802.21 case, link-layer oriented information would then be distributed over IP and upper- layer protocols. For these information services, it is possible that network information may be either centrally stored on a server or distributed in each individual access network. Presumably, an L2 or L3 based mechanism to identify or discover a valid information server would be required. Such scenarios are described in more detail in Section 4. In order to accomplish this, it will be necessary to describe IS discovery and specify transport services over IP. Interactions with IP in delivering handover services over IP therefore need consideration in the IETF, both for use with 802.21 and for other instances of handover services [22]. 3. Information Service Reference Model Entities involved with handover information services perform the roles of an Information Services client (IS client), Information Services Proxy and an Information Services server (IS-Server). Relative positions of client and server, and the interfaces between them may produce different requirements, depending on the type of communication. Essentially, they fall under the category of i) user to network communications (UNC) or ii) network to network communications (NNC). Figure 1 presents a reference model for both for single and mutihop Sreemanthula (Ed.), et al. Expires September 7, 2006 [Page 4] Internet-Draft Requirements for an IS March 2006 communication of Information Services. The reference model shows both client-server, client-proxy-server and client-server-server models. The IS-Proxy role is to forward or route the IS communications to the intended destination IS-Server. IS-Server terminated IS communications, however it may initiate a new IS communications with another IS-Server. It is possible that IS-Proxy may present server-server communication path. The IS-Proxy and the IS-Server may reside either within its administrative domain, or in another domain. ------------ ----------- | IS-client|<-------|------>|IS-Server| ------------ UNC ----------- ------------ ----------- ----------- | IS-Client|<-------|------>|IS-Proxy | <-----|------> | IS-Server| ------------ UNC ----------- NNC ----------- ------------ ----------- ----------- | IS-Client|<-------|------>|IS-Server| <-----|------> | IS-Server| ------------ UNC ----------- NNC ----------- Figure 1: Information Services Reference Model and Interfaces In order to support the above models, an Information Service system would need to provide more services than just a transport functions such as, discovery of proxy and Information servers, security association between client-server, client-proxy-server, proxy-server and server-server in a variety of deployment scenarios. 4. Scenarios for IS Transported over IP In the general case, Information Services delivery over IP may be applicable to more than just media independent handovers. What is likely to be held in common are deployment scenarios, which detail particular challenges dealt with by the information service, and the consequent requirements from these services. The models described above for information services allow deployment of IS Information Servers anywhere within the visited network domain. In this section example scenarios are described indicating where Sreemanthula (Ed.), et al. Expires September 7, 2006 [Page 5] Internet-Draft Requirements for an IS March 2006 information services are likely to be deployed. Descriptions of particular characteristics of these deployments are made, especially where the deployments place requirements on any information service transportation deployed over IP. In each of the diagrams (Figure 2 and Figure 3) below, a mobile device is currently connected to a particular wireless cell, serviced by an Access Point. In order to gain information about other wireless cells in the vicinity, it contacts an information server within the fixed network. If IP is used for information services transport, for example, in (Figure 2), the server is co-located in the router. There the router has access to the upper layer information required to assist handovers [1][22]. While information services delivery in this scenario is partly addressed by experimental information services in CARD and FMIPv6, the authors consider a fresh look at these issues are warranted, particularly to establish the applicability of security association establishment mechanisms in these and other environments [21][22]. /--------\ I / \ ----- -------- -------- /----/ \----\ |[ ]| | |--+--| ---- |---/ \ |ooo|<----------------------->|IS| | / \ |ooo| | | | | ---- | \ / ----- -------- | -------- \ / Host Access | Router \----\ /----/ Point | \ / | -------- / \--------/ +--| ---- | / Distribution | |IS| |-------/ Network | ---- | -------- Router Figure 2: IS-Server on Subnet Router Information service servers deployed outside the mobile node's subnet present both advantages and challenges. As illustrated in Figure 3, an IS-Server outside a subnet doesn't require explicit support from devices the mobile's link. Therefore the server is able to be deployed in networks which are not able to be modified easily. Additionally, the server is in a position to serve many access subnets simultaneously, which reduces administrative overheads. Sreemanthula (Ed.), et al. Expires September 7, 2006 [Page 6] Internet-Draft Requirements for an IS March 2006 Conversely, network support for discovering the IS-Server becomes critically important. Since a mobile device may roam within a domain though, it may not be necessary to discover the server each time it changes subnet, so long as the mobile remains in the set of networks covered by the server. Discovery mechanisms are covered in more detail in Section 5.3. Additionally, the location of information services addressable outside the subnet has security implications which are described in Section 7. /--------\ I / \ ----- -------- -------- /----/ -------- \----\ |[ ]| | |-----| |---/ | ---- | \ |ooo|<----------------------------------------->| |IS| | \ |ooo| | | | | \ | ---- | / ----- -------- -------- \ -------- / Host Access Router \----\ Information/----/ Point \ Server / -------- -------- / \--------/ | |-----| | / Distribution | | | |-------/ Network | | | | -------- -------- Access Router Point Figure 3: Standalone IS-Server As described in [1], information services may potentially retrieve different types of data from different sources. Where this data is also used for different purposes within the recipient host, it may be useful to segregate the discovery and operation of information services for different classes of data onto separate servers. At discovery time, the discovery operation could then respond with service advertisements describing which services are provided on which servers, potentially indicating that one information class is available on one server and one on another. While this scenario is not explicitly supported in 802.21, where service discovery is provided over IP networks, it is feasible to request/identify if an information server has a particular service. The scenario is illustrated below: Sreemanthula (Ed.), et al. Expires September 7, 2006 [Page 7] Internet-Draft Requirements for an IS March 2006 /--------\ I -------- / -------- \ ----- | | /----/ | ---- | \----\ |[ ]|<------------------------------------------->|IS| | \ |ooo| | ---- | / | ---- | \ |ooo|<----------------------|>|IS| |--\ | | / ----- | ---- | \ -------- / Host -------- \----\ Network /----/ Router \ Server / / \--------/ -------- / Distribution | | / Network |Router|------/ | | -------- Figure 4: Separation of Information Content Option In Figure 4, separate information classes are shown on the different servers. Discovery of services may indicate that a current SA and communication channel to the IS may be reused (for example to the central server), while link or access-specific information services would be accessed for local information services. This is to be contrasted with the previous unified information services deployment model from deploying the information server at one of the particular locations in or Figure 3. If information services are deployed in multiple servers, it may require additional operations to discover all required services. Also, it could lead to additional signalling and computation expenses in bootstrapping security associations for each communication. As development of information services over IP proceeds, it may be valuable to deploy the same discovery and security association bootstrap mechanisms for subsequent non-link-layer oriented services. In this case, the discovery mechanism would need to be flexible enough to accommodate additional information services, or combinations of services. 5. Protocol Development Scope This section describes the areas requiring investigation or standardization to provide transport of information services over IP. Sreemanthula (Ed.), et al. Expires September 7, 2006 [Page 8] Internet-Draft Requirements for an IS March 2006 5.1. Information Service Interfaces Entities involved with handover information services perform the roles of an Information Services client (IS client) or an Information Services server (IS-Server). Relative positions of client and server, and the interfaces between them produce different requirements, depending on the type of communication. Illustrated in Figure 5, are a number of devices participating in information services exchanges. On the left-hand side of the figure, a mobile IS client contacts an IS-Server in a network device. If this server requires additional information, it may contact another IS-Server by becoming a client itself. This new IS-Server may reside either within its administrative domain, or in another domain. --------- ----------- ----------- | | |IS-Proxy/| | | |mobile |-------->|IS-Server|-------->|IS-Server| --------- ----------- ----------- | domain A | - - - - - - - - - - - -|- - - - - - - - - - - - - domain B | V ----------- ----------- |IS-Proxy/| | | |IS-Server|-------->|IS-Server| ----------- ----------- Figure 5: Relationships between Information Service entities The mobile to IS-Proxy/IS-Server (UNI) interface is the primary interface requiring standardization by IETF. Initially, an information server must be discovered, as the mobile device will not be preconfigured with the server identity. Subsequently, secured communications are established. This security association may allow the mobile to be anonymous, but in some environments, mobile device authentication may be used to prevent resource exhaustion attacks. In any case, message authentication needs to be provided. To ensure the validity of data, the IS-Server itself needs to authenticate itself to the mobile. This proves that it is the origin of the messages, and prevents man-in-the-middle attacks. After security association establishment, information requests and responses are exchanged. Sreemanthula (Ed.), et al. Expires September 7, 2006 [Page 9] Internet-Draft Requirements for an IS March 2006 The IS-Proxy to IS-Server or the IS-Server to IS-Server (NNI) interface is required if information servers need to retrieve additional information from each other. For this interface, message formats are the same as the UNI interface. The lifetime of the security association may change though, especially in environments where servers each act as a requester and a responder. If this is the case, mutual authentication is required between the servers. Discovery is considered to be out-of-scope, as in many networks, this will be under the control of other network management systems. 5.2. Message Exchanges On the mobile/IS-Server interface a series of steps are required before information is able to be delivered back to the mobile node. In Figure 6, the steps are illustrated. The mobile device is involved in all exchanges, although dependent on the discovery scheme developed for Information Services, it may contact a separate directory service in order to locate the IS-Server's address. The figure is shown only as an illustration and not all steps may be required for handover information queries. / \ ----------- | 1) IS-Server Discovery | |Directory| | ----------------------> \ | or | | 2) IS-Server Address / | Group | | <---------------------- | ----------- -------------- | / | Mobile | | |Information | / | Service | \ 3) IS-Server Contact \ | Client | | ----------------------------> | -------------- | 4) Build Security Associations | ------------- | <============================> \ |Information| | 5) Information Request / | Service | | -----------------------------> | | Server | | 6) Information Response | ------------- \ <----------------------------- / Figure 6: Message exchanges required for Information Service Operation 1. IS-Server Discovery - A message from the mobile to either a multicast/anycast group, or a directory service which can be used to find an IS-Server. Sreemanthula (Ed.), et al. Expires September 7, 2006 [Page 10] Internet-Draft Requirements for an IS March 2006 2. IS-Server Address - The response from either a member of a multicast/anycast group or the directory server, indicating the address of the IS-Server. 3. IS-Server Contact - The initial contact operation where the mobile tests if the IS-Server is reachable. This may occur within the first message used for Security Association (SA) bootstrap. 4. Optionally, build Security Associations - Messages exchanged to bootstrap SAs with which to protect the data exchange. 5. Information Request - The data query packets typically sent from the mobile to the IS-Server, protected by the SAs. 6. Information Response - A responding set of response packets sent from the IS-Server to the requester. This message is protected by the SAs already negotiated. Where the direct requester was an IS-Server, the response goes back to the requester rather than a mobile. Discovery exchanges (1 and 2) rely upon the underlying discovery protocol, as described in Section 5.3. Subsequently, secure communications are established (steps 3/4). This should make use of an existing applicable, dependent on the transport required for information request and responses (steps 5 and 6). Transport layer requirements for information exchanges are described in Section 5.4, and additional considerations for security association negotiation are provided in Section 5.5. 5.3. Information Service Discovery Discovery by the mobile device of the IS-Server either requires Information Server participation in a discovery protocol, network entity discovery support or use of a directory service. The directory service can then refer mobiles to an appropriate server for their location. Discovery mechanisms need to provide IP layer contact information for the IS-Server. Such a discovery system should provide protection against spoofing, to prevent attackers substituting bogus information servers. In IP networks, numerous directory and configuration services already exist. Use of these services either requires support from locally Sreemanthula (Ed.), et al. Expires September 7, 2006 [Page 11] Internet-Draft Requirements for an IS March 2006 discoverable resources within the same IP hop [5][16][19], or rely on prior configuration of the unicast address of the directory service [13][14][18]. Prior configuration itself may be performed dynamically, along with other host services [5][16]. Network entity discovery, such as Router Discovery [10] could allow discovery of an IS server during routing configuration operations. If server discovery can be achieved through existing configuration discovery procedures, no additional packet exchanges would be required to perform discovery. Strict procedures for modifying packet formats with these primitive discovery mechanisms may limit the applicability of these techniques though. Other non-directory discovery methods require participation by the IS-Server in multicast or anycast communication [13]. In this case, the access network needs to support this form of routing, although it is not aware of the content. Multicast routing itself requires additional routing protocols. These protocols, while simple to operate in constrained domains such as this, are not yet deployed on all access routers. Where the IS server is not on the first IP, this prevents discovery protocol operation. 5.4. Transport-Layer Issues The existing ready use of IETF developed transport layer protocols is a compelling reason to develop information services transported over IP. Particularly, it is valuable to determine if IS requirements match existing transport models and protocols. While information services are non-real time, in some scenarios (IS- Server within a subnet), the lifetimes of communications with a particular server are short. As such, the sequenced delivery of packets using TCP may be too complicated for this application heavy handed [3]. TCP fast recovery relies upon delivery of additional packets to stimulate additional transmissions of acknowledgements from a receiver back to a transmitter. Where packet exchanges are short and sporadic, loss of a packet may not be detected except using long retransmission timeouts [4][11][12][15]. Where existing transport protocols do not incorporate their own congestion control and rate limitation, basic mechanisms for network protection and congestion recovery may need to be added to IS application protocols. Additionally, the rich development of security mechanisms which work with TCP and other stream oriented communications, encourage its use [6]. Recent developments allowing similar session oriented security services for datagrams may allow either stream oriented services or Sreemanthula (Ed.), et al. Expires September 7, 2006 [Page 12] Internet-Draft Requirements for an IS March 2006 datagram oriented services to be used or the mobile node's preference [26]. 5.5. Security Association Negotiation Security is important in IP networks, since there is a danger that attacking devices can attempt to adopt roles as information service devices. Such bogus devices could cause service degradation through spurious message exchanges, or by providing false information to mobile devices. IS-Servers need both to protect themselves from attack, and to provide mobile clients provable trust, in order that they can make handover decisions without fear of malicious inaccuracies or mischief. Therefore, before exchanging information requests with a new information server, a set of Security Associations (SAs) are established. Each SA must to provide message authentication, and should provide encryption, for the purposes of mobile device anonymity from eavesdroppers. The exact SA negotiation mechanism described depends on the transport layer used, and security services required. For example, TLS may be applicable if upper layer protocols use TCP, while ESP using IPSec/ IKE will work in most situations, regardless of the upper layer protocol, so long as the IS protocol identifiers are handled by IKE [6][7][8]. Other considerations related to flexibility and ease of use at the application layer may also play a role in the choice. While a mobile device moves within an area serviced by the same IS- Server, it can continue to use the same security association, so long as the clients IP address doesn't change. Where the IS-Server is not on the same LAN as the mobile, the mobile may move between IP networks covered by the same server. In this case, the IP address of the mobile changes. If the mobile's address changes, it may be possible to reuse an existing SA by updating the addresses to use for communication endpoint addresses using Mobile IPv6 Route Optimization, or IKEv2 session mobility [20][24]. If address update services are not available, then it will be necessary to reestablish the security association each time the mobile device's address changes. 6. Requirements for Transport over IP Sreemanthula (Ed.), et al. Expires September 7, 2006 [Page 13] Internet-Draft Requirements for an IS March 2006 o Provide an information service transport mechanism which works whether IS-Server is on the same subnet, or deep in the network belonging to same or different administrative domain. o Provide an information service transport mechanism which works with both IPv6 and IPv4. o Distinguish between the packet source and query source (allow proxies). o Provide transport of information services through NAT for IPv4. o Provide transport of information services through firewall for IPv4. o Provide transport of information services through firewall for IPv6. o Optionally allow for multiple queries per transport session. o Optionally ensure compatibility between the information services transport, and those required for Event and Command Services. o Describe an information service discovery mechanism for IPv6 hosts. o Describe an information service discovery mechanism for IPv4 hosts. o Provide a common discovery method regardless of whether the IS- Server is on the same subnet, or deep within the network. o Information services discovery should be protected from discovery service impersonation and exchange modification attacks. o Optionally ensure compatibility between the information services discovery mechanisms, and those required for Event and Command Services over IP. o Allow for distinct classes Information Servers to be discovered. o Allow for more than one Information Server to be discovered at a time. o Allow for context sensitive IS server discovery (per visited Subnet, per Mobile). Sreemanthula (Ed.), et al. Expires September 7, 2006 [Page 14] Internet-Draft Requirements for an IS March 2006 o Optionally allow discovery messages being transported through NAT. In this case, support for requester specific knowledge needs to use both the NAT source address and the query original address. o Provide a common SA negotiation method regardless of whether the IS-Server is on the same subnet, or deep within the network. o Protect against IS-Server and wireless device impersonation (with authentication). o Protect against data insertion and modification (provide message authentication). o Protect against replay attacks. o Provide confidentiality of query and response contents. o Protect the identity of a querier against eavesdroppers. o Protect IS-Server and discovery resources against denial of service. o Minimize computational and transmission resources for mobile clients. o Provide compatibility with Address or Security Association Mobility management, to allow use of an IS server after host movements without renegotiating an SA. o Allow for security services to be disabled. o Changes to the IS payload should not affect the security mechanisms defined in the underlying transport mechanism to ensure protocol modifications and evolutions defined in payload. o Enable fast SA setup to handle address mobility. 7. Security Considerations Exchange of Link-layer and handover related information over upper- layer protocols such as IP has the potential effect of widening the scope of attacks against both the information service's interfaces within the network, and the information itself. 7.1. Attacks against service entities Attacks upon information services may prevent one or more devices Sreemanthula (Ed.), et al. Expires September 7, 2006 [Page 15] Internet-Draft Requirements for an IS March 2006 being able to receive handover related information. As such this may cause degradation in handover performance. New attacks against information services become possible where link- layer information which would otherwise be limited to only one medium or bridge span, is subsequently available through an arbitrarily large IP subnet. Additionally, where information service packets may be requested or supplied from beyond the boundaries of a single routed hop, the potential scope for attack upon either of the (client or server) IS entities is Internet-wide. Discovery of the information server is implied as a requirement in providing information services transported over IP. Where the server is indicated through link-layer signaling, the robustness of the discovery mechanism is largely based on the security of the existing link-layer signaling mechanisms. Where the server discovery is performed over IP, special care needs to be taken to ensure that discovery may not be hijacked, especially since the underlying wireless medium may in some cases be considered vulnerable to such attack. Link-local scope signaling for either discovery, or both discovery and client-server communications reduce the origin of attacks to those who are on-link [9]. This may provide a mechanism which mitigates the effect of external attacks, but will require service entities to exist on every subnet. 7.2. Attacks against information Attacks against the information exchanged between the information server and the information client may potentially modify the behavior and trust of the client protocol stack. Where the integrity and origin of the information delivered to the client is not verifiable, the value of the information is degraded, as hosts are less able to rely upon the data received. Where the client's request is spoofed or modified, additional information may be sent to the IS client. As the mobile node is typically upon a lower bandwidth medium than the server, there exists potential to deny service to devices on that medium. Additionally, spoofed responses may be acted upon instead of legitimate information. This may lead to handover toward undesirable networks, or erratic connectivity. Systems which ensure data origin authentication and message integrity Sreemanthula (Ed.), et al. Expires September 7, 2006 [Page 16] Internet-Draft Requirements for an IS March 2006 may be able to remove or mitigate some of these effects, by ensuring that data arrives as intended back to the client. It may be difficult, though, to bootstrap some types of security association considering a potential lack of keying material, computation and network bandwidth resources from mobile devices. Any specified integrity protection mechanism therefore needs to be deployable on low-powered battery-operated devices which are commonly deployed in wireless environments. 8. Acknowledgements Many thanks to Qiaobing Xie for participating in early discussions, James Kempf and Jari Arkko for an informed and thorough review of this document and IEEE 802.21 WG for providing MIIS transport requirements to IETF. 9. References 9.1. Normative References [1] "Draft IEEE Standard for Local and Metropolitan Area Networks: Media Independent Handover Services", IEEE LAN/MAN Draft IEEE P802.21/D00.05, January 2006. 9.2. Informative References [2] Hepworth, E., "Media Independent Handovers: Problem Statement", draft-hepworth-mipshop-mih-problem-statement-01 (work in progress), March 2006. [3] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981. [4] Stevens, W., "TCP Slow Start, Congestion Avoidance, Fast Retransmit, and Fast Recovery Algorithms", RFC 2001, January 1997. [5] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March 1997. [6] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, January 1999. [7] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload (ESP)", RFC 2406, November 1998. Sreemanthula (Ed.), et al. Expires September 7, 2006 [Page 17] Internet-Draft Requirements for an IS March 2006 [8] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998. [9] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998. [10] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery for IP Version 6 (IPv6)", RFC 2461, December 1998. [11] Allman, M., Paxson, V., and W. Stevens, "TCP Congestion Control", RFC 2581, April 1999. [12] Floyd, S. and T. Henderson, "The NewReno Modification to TCP's Fast Recovery Algorithm", RFC 2582, April 1999. [13] Guttman, E., Perkins, C., Veizades, J., and M. Day, "Service Location Protocol, Version 2", RFC 2608, June 1999. [14] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for specifying the location of services (DNS SRV)", RFC 2782, February 2000. [15] Floyd, S., Mahdavi, J., Mathis, M., and M. Podolsky, "An Extension to the Selective Acknowledgement (SACK) Option for TCP", RFC 2883, July 2000. [16] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003. [17] Perkins, C., "IP Mobility Support for IPv4", RFC 3344, August 2002. [18] Hodges, J. and R. Morgan, "Lightweight Directory Access Protocol (v3): Technical Specification", RFC 3377, September 2002. [19] Droms, R., "Stateless Dynamic Host Configuration Protocol (DHCP) Service for IPv6", RFC 3736, April 2004. [20] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004. [21] Liebsch, M., Singh, A., Chaskar, H., Funato, D., and E. Shim, "Candidate Access Router Discovery (CARD)", RFC 4066, July 2005. [22] Koodli, R., "Fast Handovers for Mobile IPv6", RFC 4068, Sreemanthula (Ed.), et al. Expires September 7, 2006 [Page 18] Internet-Draft Requirements for an IS March 2006 July 2005. [23] Yegin, A., "Link-layer Event Notifications for Detecting Network Attachments", draft-ietf-dna-link-information-02 (work in progress), July 2005. [24] Kivinen, T. and H. Tschofenig, "Design of the MOBIKE protocol", draft-ietf-mobike-design-01 (work in progress), January 2005. [25] Williams, M., "Directions in Media Independent Handover", IEICE Transactions on Fundamentals Special Section on Multi- dimensional Mobile Information Networks, July 2005. [26] Rescorla, E., "Datagram Transport Layer Security", draft-rescorla-dtls-02 (work in progress), December 2004. [27] Brickley, D. and R. Guha, "RDF Vocabulary Description Language 1.0: RDF Schema", W3C Recommendation http://www.w3.org/TR/rdf-schema, February 2004. [28] Prudhommeaux, E. and A. Seaborne, "SPARQL Query Language for RDF", W3C Working Draft http://www.w3.org/TR/2004/WD-rdf-sparql-query-20041012, October 2004. Sreemanthula (Ed.), et al. Expires September 7, 2006 [Page 19] Internet-Draft Requirements for an IS March 2006 Authors' Addresses Srinivas Sreemanthula Nokia 6000 Connection Dr. Irving, Texas 75039 USA Phone: +1 972 894 4356 Email: Srinivas.Sreemanthula@nokia.com Greg Daley Panasonic Digital Networking Laboratory 2 Research Way Princeton, New Jersey 08540 USA Phone: +1 609 734 7334 Email: greg.daley@research.panasonic.com Stefano Faccin Nokia 6000 Connection Dr Irving, TX 75229 USA Phone: +1 973 894 5000 Email: stefano.faccin@nokia.com Eleanor Hepworth Siemens/Roke Manor Research Roke Manor Romsey SO51 0ZN UK Phone: Email: eleanor.hepworth@roke.co.uk Sreemanthula (Ed.), et al. Expires September 7, 2006 [Page 20] Internet-Draft Requirements for an IS March 2006 Subir Das Telcordia RRC 1B 229 One Telcordia Drive Piscataway, NJ 08854 US Phone: +1-732-699-2483 Email: subir@research.telcordia.com Sreemanthula (Ed.), et al. Expires September 7, 2006 [Page 21] Internet-Draft Requirements for an IS March 2006 Intellectual Property Statement 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. Disclaimer of Validity 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 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. Copyright Statement Copyright (C) The Internet Society (2006). 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. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Sreemanthula (Ed.), et al. Expires September 7, 2006 [Page 22]