Network Working Group G. Daley Internet-Draft Monash University CTIE Expires: April 15, 2006 S. Faccin Nokia E. Hepworth Siemens/Roke Manor Research Q. Xie Motorola October 12, 2005 Some Requirements for a Handover Information Service draft-faccin-mih-infoserv-01.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 April 15, 2006. Copyright Notice Copyright (C) The Internet Society (2005). Abstract Handover Information Services may be used to assist handovers between wireless cells, based on stored network knowledge. Information Services can be used to provide topology and channel information Daley, et al. Expires April 15, 2006 [Page 1] Internet-Draft Some Requirements for an IS October 2005 which may allow a moving host to select an appropriate link-layer connection to make, amongst available networks, whether using the same technology or between heterogeneous technologies. This document is an effort to describe use cases and problem statements for information services, when they are transported and discovered over IP networks. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1 Information Services . . . . . . . . . . . . . . . . . . . 4 1.2 Scope of work on information services . . . . . . . . . . 5 2. Relationship to 802.21 . . . . . . . . . . . . . . . . . . . . 5 2.1 802.21 Media Independent Information Services . . . . . . 5 3. Scenarios for IS Transported over IP . . . . . . . . . . . . . 6 3.1 Information Service Scenarios . . . . . . . . . . . . . . 6 3.2 Further Scenario Considerations . . . . . . . . . . . . . 9 3.3 Specific Use Information Services . . . . . . . . . . . . 10 4. Protocol Development Scope . . . . . . . . . . . . . . . . . . 11 4.1 Information Service Interfaces . . . . . . . . . . . . . . 11 4.2 Messages Exchanges . . . . . . . . . . . . . . . . . . . . 12 4.3 Information Service Discovery . . . . . . . . . . . . . . 14 4.4 Transport-Layer Issues . . . . . . . . . . . . . . . . . . 15 4.5 Security Association Negotiation . . . . . . . . . . . . . 15 5. Requirements for Transport over IP . . . . . . . . . . . . . . 16 5.1 Summary of requirements . . . . . . . . . . . . . . . . . 16 6. Outstanding Issues . . . . . . . . . . . . . . . . . . . . . . 18 6.1 Transport Issues . . . . . . . . . . . . . . . . . . . . . 18 6.2 Discovery Issues . . . . . . . . . . . . . . . . . . . . . 19 6.3 Security Issues . . . . . . . . . . . . . . . . . . . . . 20 7. Security Considerations . . . . . . . . . . . . . . . . . . . 21 7.1 Attacks against service entities . . . . . . . . . . . . . 21 7.2 Attacks against information . . . . . . . . . . . . . . . 22 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 22 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22 9.1 Normative References . . . . . . . . . . . . . . . . . . . 22 9.2 Informative References . . . . . . . . . . . . . . . . . . 23 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 25 A. 802.21 Media Independent Handover Services . . . . . . . . . . 25 A.1 802.21 Handover Service Classification . . . . . . . . . . 26 A.2 802.21 MIHS SAP Relations . . . . . . . . . . . . . . . . 26 A.3 802.21 MIIS Message Processing . . . . . . . . . . . . . . 27 A.4 Information flows in 802.21 . . . . . . . . . . . . . . . 28 A.5 802.21 MIIS Information Classes . . . . . . . . . . . . . 29 Intellectual Property and Copyright Statements . . . . . . . . 31 Daley, et al. Expires April 15, 2006 [Page 2] Internet-Draft Some Requirements for an IS October 2005 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. At this time, three broad classes of services for handover assistance are under consideration within the IEEE 802.21 Working Group. They require passing of information within hosts, as well as between them: 1. Event Services (ES) provide indications from lower layers about changes in the connectivity state. This is particularly relevant to wireless interfaces [22]. 2. Command Services (CS) provide mechanisms for controlling handovers. They provide mechanisms to establish, redirect, or remove state in either the network or mobile terminal, so that handovers occur smoothly. 3. Information Services (IS) are used to provide additional handover-related information. This allows the network or host to make informed decisions of which handover operations to undertake either in response to an event, or when planning controlled or commanded handovers. As shown in Figure 1, one or more handover services may exist in a node, including services which aren't yet described. Each service may require communication with peer services on other nodes, and this communication may be transported transport over IP, to communicate with peer services on other nodes. The diagram transfers data over a mobility service transport protocol. This protocol provides transparent message delivery, as well as server discovery and security association configuration. As such, it may encompass multiple layers of the TCP/IP protocol model. Daley, et al. Expires April 15, 2006 [Page 3] Internet-Draft Some Requirements for an IS October 2005 +-------------+ ^ | Mobility | | | Service 2 | | +------------| (e.g. ES) | | Mobility Service | Mobility +-------------+ | Signaling | Service 1 | +-------------+ | Layer | (e.g. IS) | | Mobility | | +--------------+ | Service 3 | | | (other) | | +-------------+ V ================================================ +---------------------------------------+ ^ Mobility Service | Mobility Service Transport Protocol | | Transport +---------------------------------------+ V Layer ================================================ +---------------------------------------+ | IP | +---------------------------------------+ Figure 1: Handover Services over IP A current focus for handover services over IP is on Information Services delivery and transport. This document is primarily focused on this issue. 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). This document provides a view of the authors, and doesn't represent the official view of either IEEE 802.21 or an IETF WG. Assistance is sought to improve this document, in order to reflect consensus viewpoints from the appropriate groups. 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 Daley, et al. Expires April 15, 2006 [Page 4] Internet-Draft Some Requirements for an IS October 2005 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 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 3. The extent of protocol development work to be undertaken is elaborated on in Section 4. Further descriptions of information services are possible, for example it may be possible to describe information services and FMIPv6 interaction [21]. Having a single framework for FMIPv6 network discovery is important for compatability, though, so it may be valuable for FMIPv6 development not depend on that of a generalized IS. 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. Relationship to 802.21 IEEE 802.21 is currently developing Media Independent Handover Services (MIHS). These services are aimed at providing a common framework for handover assistance regardless of the underlying technology. The 802.21 framework is aimed to be deployed in a number of different scenarios, where additional specification will be required. This draft provides an incomplete description of the 802.21's progress, and people are encouraged to read the 802.21 draft themselves [1]. 2.1 802.21 Media Independent Information Services IEEE is currently working on Information Services as part of 802.21 Media Independent Handover Services (MIHS). Daley, et al. Expires April 15, 2006 [Page 5] Internet-Draft Some Requirements for an IS October 2005 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 3.1. 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 [21]. This document describes a distillation of the requirements from the current draft for 802.21's media independent information service, in order describe uses for handover information services, and start describing requirements for alike information services transported over IP. As synergies exist between this work and existing work within the IETF, the authors of this document aim to exchange knowledge amongst participants of IEEE 802 and IETF. This may allow specification of information services transport over IP, which would be suitable for 802.21's MIIS, as well as other compatible information services. 3. 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. In Section 3.1 below, these scenarios are detailed, along with the implications of particular topologies. The union of these requirements are then described in Section 4. 3.1 Information Service Scenarios 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 information services are likely to be deployed. Descriptions of Daley, et al. Expires April 15, 2006 [Page 6] Internet-Draft Some Requirements for an IS October 2005 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, Figure 3 and Figure 4) 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. In Figure 2, the information service has been deployed on a wireless Access Point. This is considered to be a likely scenario, as wireless devices themselves may be aware of local channel conditions, and may have information about administratively adjacent devices (such as first-hop routers) and base stations within the same subnet. In this scenario, transport of information services over IP isn't strictly necessary, as the IS-Server is the MAC peer of the wireless host. If information services over IP are deployed though, no changes to the link-layer protocol are required. Conversely, if transport of information services over IP is required, the host is still has to discover the server's IP address and presence. This discovery requires transmission IS discovery queries to a known address, group, or directory service. /--------\ I / \ ----- -------- -------- /----/ \----\ |[ ]| | ---- |--+--| |---/ \ |ooo|<---------->|IS| | | | | / \ |ooo| | ---- | | | | \ / ----- -------- | -------- \ / Host Access | Router \----\ /----/ Point | \ / | -------- / \--------/ +--| | / Distribution | |-------/ Network | | -------- Router Figure 2: IS-Server on Access Point When an IS-Server is placed within the access network,once again it may be possible to run information services without using IP. No advantage is gained from omitting IP, though, as server discovery Daley, et al. Expires April 15, 2006 [Page 7] Internet-Draft Some Requirements for an IS October 2005 still needs to occur. If IP is used for information services transport, For example, in (Figure 3), the server is co-located in the router. There the router has access to the upper layer information required to assist handovers [1][21]. 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 [20][21]. /--------\ I / \ ----- -------- -------- /----/ \----\ |[ ]| | |--+--| ---- |---/ \ |ooo|<----------------------->|IS| | / \ |ooo| | | | | ---- | \ / ----- -------- | -------- \ / Host Access | Router \----\ /----/ Point | \ / | -------- / \--------/ +--| ---- | / Distribution | |IS| |-------/ Network | ---- | -------- Router Figure 3: IS-Server on Subnet Router Information service servers deployed outside the mobile node's subnet present both advantages and challenges. As illustrated in Figure 4, 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. 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 4.3. Additionally, the location of information services addressable Daley, et al. Expires April 15, 2006 [Page 8] Internet-Draft Some Requirements for an IS October 2005 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 4: Standalone IS-Server 3.2 Further Scenario Considerations The IS needs to be in a position to provide useful information to hosts about their current visited environments. In many cases, the network side infrastructure is in a position to store overall network information, such as neighborhood cell lists and the location of mobile devices. The wide variation in potential locations for Information Servers though, makes their discovery challenging. Description of information services transported over IP requires detailed analysis of potential Security Association building techniques, and identification of anchors for trust. It also requires determination of IS discovery mechanisms which are deployable in today's networks. In some scenarios, link-layer devices may be modified sufficiently to provide discovery services for IS servers contactable over the internet. In this case, the discovery operations can be abbreviated in all scenarios where transport over IP is provided, if the link- layer mechanism is sufficiently secured against advertisement spoofing. Daley, et al. Expires April 15, 2006 [Page 9] Internet-Draft Some Requirements for an IS October 2005 3.3 Specific Use Information Services As described in Appendix A.5, 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: /--------\ I -------- -------- / -------- \ ----- HLSI | | | | /----/ | ---- | \----\ |[ ]|<------------------------------------------->|IS| | \ |ooo| | ---- | | | / | ---- | \ |ooo|<---------->|IS| |-----| |--\ | | / ----- LLI | ---- | | | \ -------- / Host -------- -------- \----\ Network /----/ Access Router \ Server / Point / \--------/ -------- -------- / Distribution | ---- | | | / Network | |IS| |-----| |------/ | ---- | | | -------- -------- Figure 5: Separation of Information Content Option In Figure 5, separate information classes are shown on the different servers. Link-layer services are serviced by access-points or other local devices, while topological and network information is serviced by a centrally located device. 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-specific information services would be accessed for local information services. This is to be contrasted with the previous unified information Daley, et al. Expires April 15, 2006 [Page 10] Internet-Draft Some Requirements for an IS October 2005 services deployment model from deploying the information server at one of the particular locations in Figure 2, Figure 3 or Figure 4. 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 accomodate additional information services, or combinations of services. At this stage, no intention to follow a multiple information-server design is inferred. The scenario is illustrated to elicit feedback about the desirability of specific use information services over IP, for either use with 802.21 or further development of information services. 4. Protocol Development Scope This section describes the areas requiring investigation or standardization to provide transport of information services over IP. At this stage, significant feedback is required from both MIPSHOP working group and 802.21 Task Group, to confirm the validity of the scenarios from Section 3, and develop the descriptions in the subsections below. Once these are more stable, a summary of requirements can be produced in Section 5.1. 4.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 6, 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. Daley, et al. Expires April 15, 2006 [Page 11] Internet-Draft Some Requirements for an IS October 2005 --------- ----------- ----------- |mobile |-------->|IS-Server|-------->|IS-Server| --------- ----------- ----------- | domain A | - - - - - - - - - - - -|- - - - - - - - - - - - - domain B | V ----------- ----------- |IS-Server|-------->|IS-Server| ----------- ----------- Figure 6: Relationships between Information Service entities The mobile/IS-Server 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. The IS-Server/IS-Server interface is required if information servers need to retrieve additional information from each other. For this interface, message formats are the same as the mobile/IS-Server 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. 4.2 Messages 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 7, 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 Daley, et al. Expires April 15, 2006 [Page 12] Internet-Draft Some Requirements for an IS October 2005 directory service in order to locate the IS-Server's address. / \ ----------- | 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 7: 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. 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. 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. Daley, et al. Expires April 15, 2006 [Page 13] Internet-Draft Some Requirements for an IS October 2005 Discovery exchanges (1 and 2) rely upon the underlying discovery protocol, as described in Section 4.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 4.4, and additional considerations for security association negotiation are provided in Section 4.5. 4.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 discoverable resources within the same IP hop [4][15][18], or rely on prior configuration of the unicast address of the directory service [12][13][17]. Prior configuration itself may be performed dynamically, along with other host services [4][15]. Network entity discovery, such as Router Discovery [9] 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 [12]. 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. Daley, et al. Expires April 15, 2006 [Page 14] Internet-Draft Some Requirements for an IS October 2005 4.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 [2]. 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 [3][10][11][14]. 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. Alternatively, the rich development of security mechanisms which work with TCP and other stream oriented communications, encourage its use [5]. Recent developments allowing similar session oriented security services for datagrams may allow either stream oriented services or datagram oriented services to be used, dependent on the handover service required (for example, both ES and CS may be datagram oriented) or the mobile node's preference [25]. 4.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. Daley, et al. Expires April 15, 2006 [Page 15] Internet-Draft Some Requirements for an IS October 2005 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 [5][6][7]. 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 [19][23]. 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. 5. Requirements for Transport over IP At this stage feedback is sought on the preceding sections before development of a complete recommendation summary. The summary below is to be considered as a starting point for discussion. 5.1 Summary of requirements o Provide an information service transport mechanism which works with both IPv6 and IPv4. o Allow multiple packet responses to queries. o Allow fragmented message responses to queries. o Provide robust query and response delivery over wireless networks. o Distinguish between the packet source and query source (allow proxies). o Provide transport of information services through NAT for IPv4. o Optionally allow for multiple queries per transport session o Optionally ensure compatability between the information services transport, and those required for Event and Command Services. Daley, et al. Expires April 15, 2006 [Page 16] Internet-Draft Some Requirements for an IS October 2005 o Describe an information service discovery mechansism for IPv6 hosts o Describe an information service discovery mechansism for IPv4 hosts o Provide a common discovery method regardless of whether the IS- Server is the adjacent AP, 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 compatability between the information services discovery mechansisms, 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 AP, per visited Subnet, per Mobile). 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 the adjacent AP, on the same subnet, or deep within the network. o Protect against IS-Server impersonation. 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 compatability with Address or Security Association Mobility management, to allow use of an IS server after host movements without renegotiating an SA. Daley, et al. Expires April 15, 2006 [Page 17] Internet-Draft Some Requirements for an IS October 2005 6. Outstanding Issues At this stage, there are a wide range of possible scenarios for information services. Below are a set of questions which may limit the range of potential deployed ISs, to an achievable subnet. The following subsections describe issues to resolve which may allow development of information services with applicability to 802.21. Each is outlined by an issue task which needs to be resolved in order to develop an IS protocol. Therefore it is felt that this process may to assist shaping the requirements for IETF standardization processes. As design choices are made, they will be cataloged here, and this section may eventually move to an appendix. 6.1 Transport Issues The following design issues impact on the choice of transport mechanisms for Information systems. o Response timing constraints o Stream or datagram oriented service o Reliability in transport layer or above Task: Determine what delivery and timing constraints exist (in absolute time or proportional to maximum wireless medium RTT) If IS applications have inbuilt timing constraints, it is necessary to determine what these are. This is because existing transfer mechanisms may delay new transfers of data for multiple seconds in packet loss situations (for example TCP [3]). As such, protocols which don't meet these constraints may be ruled out-of-scope for development. Task: Determine if Stream or Datagram oriented services are required for IS. It's necessary to determine which of stream and datagram oriented services are required. This is because choices of services impact on the security and packet delivery services are needed (or available) at the transport layer. Additionally, it may be useful to make use of a generalized transport model, not only for IS, but also for event or command services. In that case, the union of the requirements would need to be supported. Daley, et al. Expires April 15, 2006 [Page 18] Internet-Draft Some Requirements for an IS October 2005 Task: Determine if reliability is required at transport layer. Even if TCP isn't being used, an IS may still require reliable packet transfer [2]. If the messages exchanged for the information service are assumed to be processed in-order for particular exchanges, reordering of packets over the Internet may cause problems for IS function. In that case, transport-layer reliability services may be required. Alternatively, where message sequence numbers are incorporated into the Information Service messages, ordering of packets may be possible using application-layer information. In this case, it may also be possible to provide message reliability, on top of a datagram oriented transport service. 6.2 Discovery Issues The following design issues impact on the choice of discovery of IS- Servers. o Single or multiple methods of discovery o Information Server participation in discovery o IS-Servers' use of discovery o Only one Server or allow one Server per class Task: Determine how many discovery methods are required. Having multiple discovery mechanisms allows for deployment flexibility, but requires hosts to test all possible mechanisms for IS-Server discovery, when hosts are not constrained to use only one discovery mechanism. It is necessary to determine whether any discovery systems will be mandatory-to-deploy, which may allow optimization of discovery processes. Task: Determine if Information Server itself needs to participate in discovery If the information service is able to be discovered using an existing directory service, then it may not be necessary for the IS-Server itself to participate in discovery. If there's no directory service preconfigured in the mobile host, it is necessary for the server to understand discovery messages and Daley, et al. Expires April 15, 2006 [Page 19] Internet-Draft Some Requirements for an IS October 2005 respond on its own behalf. Task: Determine if IS-Servers are required to discover further IS- Servers. If IS-Servers can be assumed to be preconfigured with information about which IS-Servers hold relevant information to service queries, they can avoid performing discovery processes to find the servers. Task: Identify if separate servers for different information services should be supported Servers for multiple classes allow additional flexibility, but potentially incur additional signalling costs. This issue is described in Section 3.3. 6.3 Security Issues The following issues impact on the design of security mechanisms for communications between IS entities. o Mutual authentication requirements o Do IS-Server to IS-Server communications require mutual authentication? o Rate limitation of queries and responses o Session or host based SAs Task: Determine if mutual (strong or shared key) authentication is required for the SAs. If mutual authentication is required, then the mobile needs to have credentials verifiable in the network (using an AAA server, or PKI for example). If the Mobile is allowed to be anonymous, additional requirements for protection of resources may be required. Task: Determine if the Server-to-Server interface requires mutual authentication. If the mobile devices don't require mutual authentication, servers may still do so, due to differences in the trust accorded servers. In that case additional requirements on infrastructure are needed, as described above. Task: Determine rate limitation requirements for information requests and responses. Daley, et al. Expires April 15, 2006 [Page 20] Internet-Draft Some Requirements for an IS October 2005 Rate limitation of queries on clients allow a server to delay or ignore queries from clients which exceed valid query rates, Similarly, rate limitation of server responses can help protect wireless media, but can also be used to deny service. Task: Determine if session based or host based SAs are required. Typically, layer 3 security such as IPsec is host based, where all users of a device are given the same authentication. Alternatively, a session based authentication (often tied to a user's own privileges) is used for transport and upper-layer security. Different assumptions about numbers of users may apply on the mobile and the information server. Since servers may be shared by many users, session based mobility may prevent abuse of security mechanisms by attackers co-located at the server. 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 with the network, and the information itself. 7.1 Attacks against service entities Attacks upon information services may prevent one or more devices 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 Daley, et al. Expires April 15, 2006 [Page 21] Internet-Draft Some Requirements for an IS October 2005 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 [8]. 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 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 James Kempf for an informed and thorough review of this document. 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.01, July 2005. Daley, et al. Expires April 15, 2006 [Page 22] Internet-Draft Some Requirements for an IS October 2005 9.2 Informative References [2] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981. [3] Stevens, W., "TCP Slow Start, Congestion Avoidance, Fast Retransmit, and Fast Recovery Algorithms", RFC 2001, January 1997. [4] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March 1997. [5] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, January 1999. [6] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload (ESP)", RFC 2406, November 1998. [7] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998. [8] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998. [9] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery for IP Version 6 (IPv6)", RFC 2461, December 1998. [10] Allman, M., Paxson, V., and W. Stevens, "TCP Congestion Control", RFC 2581, April 1999. [11] Floyd, S. and T. Henderson, "The NewReno Modification to TCP's Fast Recovery Algorithm", RFC 2582, April 1999. [12] Guttman, E., Perkins, C., Veizades, J., and M. Day, "Service Location Protocol, Version 2", RFC 2608, June 1999. [13] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for specifying the location of services (DNS SRV)", RFC 2782, February 2000. [14] Floyd, S., Mahdavi, J., Mathis, M., and M. Podolsky, "An Extension to the Selective Acknowledgement (SACK) Option for TCP", RFC 2883, July 2000. [15] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003. Daley, et al. Expires April 15, 2006 [Page 23] Internet-Draft Some Requirements for an IS October 2005 [16] Perkins, C., "IP Mobility Support for IPv4", RFC 3344, August 2002. [17] Hodges, J. and R. Morgan, "Lightweight Directory Access Protocol (v3): Technical Specification", RFC 3377, September 2002. [18] Droms, R., "Stateless Dynamic Host Configuration Protocol (DHCP) Service for IPv6", RFC 3736, April 2004. [19] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004. [20] Liebsch, M., Singh, A., Chaskar, H., Funato, D., and E. Shim, "Candidate Access Router Discovery (CARD)", RFC 4066, July 2005. [21] Koodli, R., "Fast Handovers for Mobile IPv6", RFC 4068, July 2005. [22] Yegin, A., "Link-layer Event Notifications for Detecting Network Attachments", draft-ietf-dna-link-information-02 (work in progress), July 2005. [23] Kivinen, T. and H. Tschofenig, "Design of the MOBIKE protocol", draft-ietf-mobike-design-01 (work in progress), January 2005. [24] Williams, M., "Directions in Media Independent Handover", IEICE Transactions on Fundamentals Special Section on Multi- dimensional Mobile Information Networks, July 2005. [25] Rescorla, E., "Datagram Transport Layer Security", draft-rescorla-dtls-02 (work in progress), December 2004. [26] Brickley, D. and R. Guha, "RDF Vocabulary Description Language 1.0: RDF Schema", W3C Recommendation http://www.w3.org/TR/rdf-schema, February 2004. [27] 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. Daley, et al. Expires April 15, 2006 [Page 24] Internet-Draft Some Requirements for an IS October 2005 Authors' Addresses Greg Daley Centre for Telecommunications and Information Engineering Department of Electrical and Computer Systems Engineering Monash University Clayton, Victoria 3800 Australia Phone: +61 3 9905 4655 Email: greg.daley@eng.monash.edu.au 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 Qiaobing Xie Motorola, Inc. 1501 W. Shure Drive, 2-F9 Arlington Heights, IL 60004 US Phone: +1-847-632-3028 Email: qiaobing.xie@motorola.com Appendix A. 802.21 Media Independent Handover Services The union of the Media Independent Information Service, the Media Independent Event Serviced and the Media Independent Command Service compose a Media Independent Handover Service. Daley, et al. Expires April 15, 2006 [Page 25] Internet-Draft Some Requirements for an IS October 2005 Certain characteristics are shared amongst all three services. Of particular note to IETF are the common SAPs, and information flows. Appendix A.1 802.21 Handover Service Classification Information exchanges in 802.21 classified as either Event, Command or Information services. The Media Independent Event Service (MIES) provides timely communications of wireless environment information, through an event delivery service. Both events generated from local link-layer devices, and remote events from by a peer Media Independent Handoff Function (MIHF) on the other end of the link-layer, are supported. An example event would indicate that it is now possible to send generic upper-layer frames. The Media Independent Command Service (MICS) provides instructions which change state of the wireless link, or a host's point-of- attachment. Commands can be sent to entities within the local host, or to a device on the other end of the link-layer medium. Such command mechanisms may cause further event generation, either from the local MIHF, or on the peer. As an example, a command may be able to instruct a station to handover to another network. The Media Independent Information Service (MIIS) distinguishes itself from the other mechanisms in that the messages are typically larger and do not have the same time critical delivery requirements. It provides several classes of handover service related information to hosts including Link-Layer and Network-Layer status information. These service classifications have been adopted throughout this document, It provides several classes of handover service related information to hosts including Link-Layer and Network-Layer status information. as the basis for ES, CS and IS descriptions. Of importance to 802.21 is the fact that the endpoint for remote communication may be a directly adjacent link-layer peer or another device. As described in the 802.21 draft, in this case, it is believed an upper-layer protocol could be used to deliver information. In the current context, this means delivery over IP, and related transport services. Appendix A.2 802.21 MIHS SAP Relations The 802.21 Media Independent Handover Function (MIHF) provides a unified SAP for its component services to upper layers such as IPv6, or mobility management applications, like MIPv6 [8][9][19]. These applications are saved the difficulty of dealing with individual Daley, et al. Expires April 15, 2006 [Page 26] Internet-Draft Some Requirements for an IS October 2005 Link-layer modules for handover control and monitoring. Within the MIHS, each of the entities is able to interface to media dependent operations in order to gain information from or provide control over the physical medium and MAC. In the diagram below, the MIIS is shown as being able to interface to upper layer protocols, in order to provide information service data transport. +-----------+--------------------+------------+ Upper Layer | Other | | | Services |Upper Layer| IPv4 | IPv6 | | ^ | ^ | ^ | | | | | | | | | \----------------+----------------+--------\ | | | | \ | /-------+--------------------+--------\ | | +--+ MIH SAP +--+ | | \-------------------------------------/ | | | | | | Media Independent Handover Function | | | | | | +----------+ +-----------+ +----------+ | | | | | | | | | | / | | MIES | | MICS | | MIIS ?------/ | | | | | | | | | +----------+ +-----------+ +----------+ | | | +---------+-----------+-----------+-----------+ Media | | | | | Depend | 802.16 | 802.11 | 802.11 | UMTS | Handover | | | | | Services | | | | | +---------+-----------+-----------+-----------+ Figure 8: Abstraction using the MIH SAP, showing delivery of MIIS services over IP Communications are primarily up/down the stack, although transport of information services over IP, breaks this model by relying in turn upon existing configuration of IP connectivity in order to receive MIIS messages. Appendix A.3 802.21 MIIS Message Processing The Information Service is primarily a request/response based system. The information server processes queries containing a set of filter Daley, et al. Expires April 15, 2006 [Page 27] Internet-Draft Some Requirements for an IS October 2005 constraints on the response, as specified by the requester. It then composes a response and sends it back to the requester. Given the size and non-real time nature of the response, more than one packet of data may be required to transport all the information required. Upon reception at the MIHF of the querier, information may be filtered for content, and then passed through MIH SAPs to interested upper-layer protocols. While content of IS messages is considered out of scope in development of generic IS transport over IP, the message formats and SAP contents are further described in [1]. Appendix A.4 Information flows in 802.21 As mentioned earlier, there are different incarnations of the Information Service depending on whether information is being passed between two link-layer peers, or is stored on a server accessible over an upper-layer protocol. While this document is concerned solely with IS transport over IP networks, the information flow for both of 802.21's L2 and L3 based exchanges are presented for comparison: STA (Client) AP/BS MIH SAP MAC MAC MIH SAP | | | | Request |MIH_Info. | |MIH_Info. | info from | request| | indication| peer |--------->|------------------->|----------->| | |Information REQUEST | | | | | | | | | |Neighbor Map | | | |Report Gen |MIH_Info. | |MIH_Info. | | confirm| | response| Neighbor |<---------|<-------------------|<-----------| Map Report | |Information RESPONSE| | | | | | Figure 9: L2-based MIIS information flow from 802.21 Note that the primary logical differences between the information flows at the link-layer and upper layers are the endpoints for message transport. The use of a particular mechanism should be transparent to systems interfacing to the MIH Service Access Point. Daley, et al. Expires April 15, 2006 [Page 28] Internet-Draft Some Requirements for an IS October 2005 STA (Client) AR/Server MIH SAP T'sport/IP T'sport/IP MIH SAP | | | | Request |MIH_Info. | |MIH_Info. | info from | request| | indication| peer |--------->|------------------->|----------->| | |Information REQUEST | | | | | | | | | |Neighbor Map | | | |Report Gen |MIH_Info. | |MIH_Info. | | confirm| | response| Neighbor |<---------|<-------------------|<-----------| Map Report | |Information RESPONSE| | | | | | Figure 10: Example L3-based MIIS information flow In information services deployment over IP, the topological location of the IS-Server doesn't modify the message exchange. In fact, 802.21 allows the server to be present either within the access network or core network of a service provider. [1]. Implications for a generic handover services delivery mechanism are that a variety of topologies are required to be supported for IS transport over IP, while message containers are likely to remain unmodified, so long as the channel used for communications is secured. Appendix A.5 802.21 MIIS Information Classes The media independent information service provides three classes of data to mobile hosts. These classes of data are related to different origins and use of data: 1. General Network Information (GNI): A general overview of the network and its nearby Points of Attachment. 2. Link Layer Information (LLI): Link-layer specific information useful to identify capabilities of a specific network. 3. Higher Layer Information (HLI): Information about upper layer protocols like IPv4 and IPv6, configuration systems such as DHCP and mobility management applications like MIPv4 [4][16]. Information from each of these classes may be queried from an Daley, et al. Expires April 15, 2006 [Page 29] Internet-Draft Some Requirements for an IS October 2005 information server, with different filters applied for each data set. As such, it may be possible to configure different aspects of information service queries, for example, an 802.11 handover management subsystem may only be interested in Link-Layer Information. It is notable that Link-Layer information is likely to be gathered most readily at the edge of the network where devices are directly involved in wireless communications, whereas Higher-Layer information will be available to devices which have IP layer configuration. As such it is not entirely implausible to use different information servers for local link-layer oriented information, and for wider- region topological information. This issue is described in Section 3.3 This may imply a useful role for interaction between IS- Servers in order to configure or update held information. Daley, et al. Expires April 15, 2006 [Page 30] Internet-Draft Some Requirements for an IS October 2005 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 (2005). 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. Daley, et al. Expires April 15, 2006 [Page 31]