Mobility for IP: Performance, R. Hancock Signaling and Handoff Optimization E. Hepworth Internet-Draft RMR Expires: December 21, 2006 June 19, 2006 Supporting Media Independent Handover Protocols with GIST draft-hancock-mipshop-gist-for-mih-00 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 December 21, 2006. Copyright Notice Copyright (C) The Internet Society (2006). Abstract The MIPSHOP working group is working on common functionality necessary for the support of media independent handover (MIH) protocols, initially focussing on the architectures being developed with the 802.21 working group of the IEEE. A problem statement draft describing the context and scope of the common functionality is already in progress, and a second draft has been prepared that describes the main protocol design issues that have to be taken into consideration. Although the common functionality (relating to Hancock & Hepworth Expires December 21, 2006 [Page 1] Internet-Draft GIST for MIH June 2006 transport and security requirements) is mainly standard, there is still a significant element of protocol design to integrate them with the MIH service itself, including in particular secure peer discovery and capability negotiation. This draft presents a solution for the common protocol functionality based on the use of the General Internet Signaling Transport (GIST) protocol, which has been developed in the NSIS working group. GIST can already satisfy the bulk of the protocol requirements in its current form, and this draft explains how this existing GIST functionality fits into the MIH problem space. The main special requirements for MIH relate to signalling node discovery and message routing, and this draft outlines three options for supporting these requirements within the GIST framework. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Functionality Overview . . . . . . . . . . . . . . . . . . . . 4 2.1. Discovery and Routing . . . . . . . . . . . . . . . . . . 4 2.2. Message Transport . . . . . . . . . . . . . . . . . . . . 5 2.3. State Management . . . . . . . . . . . . . . . . . . . . . 5 2.4. Multiplexing and Extensibility . . . . . . . . . . . . . . 6 2.5. Network Layer Interactions . . . . . . . . . . . . . . . . 6 2.6. Message Security . . . . . . . . . . . . . . . . . . . . . 7 2.7. Overload Management . . . . . . . . . . . . . . . . . . . 8 2.8. Failure Handling . . . . . . . . . . . . . . . . . . . . . 9 3. Extended Message Routing Methods . . . . . . . . . . . . . . . 9 3.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 9 3.2. A Message Routing Method for MIH Services . . . . . . . . 10 3.3. Multi-MIH Service Discovery . . . . . . . . . . . . . . . 12 4. MIH Service Development . . . . . . . . . . . . . . . . . . . 13 5. Security Considerations . . . . . . . . . . . . . . . . . . . 15 6. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 16 7. Informative References . . . . . . . . . . . . . . . . . . . . 17 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 18 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20 Intellectual Property and Copyright Statements . . . . . . . . . . 21 Hancock & Hepworth Expires December 21, 2006 [Page 2] Internet-Draft GIST for MIH June 2006 1. Introduction The MIPSHOP working group is currently working on common functionality necessary for the support of media independent handover (MIH) protocols, initially focussing on the architectures being developed with the 802.21 working group of the IEEE. MIH protocols are used to exchange information between terminals and networks to convey information about radio conditions, available resources and other handover requirements in order to allow optimised handover decisions to be taken and executed in heterogeneous wireless environments (that is, environments where more than one type of radio access technology is available or in use at any one time). Thus, although the MIH protocols carry link layer information, the protocols themselves are not tightly bound to any specific link layer. Instead, they can be carried at the network layer, both within the radio access infrastructure and over the air. A problem statement describing the context and scope of the common functionality is already in progress [1]. This draft describes a decomposition of the overall MIH protocol problem into a common part, and a set of specific users or MIH services which is layered over it. This structure is consistent with the architecture defined by 802.21 [2], where the services in question have been identified as the Event, Command and Information Services (ES/CS/IS). The problem statement itself outlines a division of functionality between the common part and the individual services, with the intention that the common part will be generally useful even in non-802.21 architectures. The expectation is that the MIPSHOP working group will develop a solution for the common part which meets the 802.21 requirements as expressed in the problem statement draft. A second draft outlining more detailed design considerations for the common part has also been prepared [3], which formalises some of the open issues the scope of the common functionality, and lists the key design choices that have to be made and the criteria that should be taken into account in doing so. Although [3] refers to components of possible solutions as examples, it is not a solution proposal in its own right. While the common functionality (relating to transport and security requirements) is mainly standard, there is still a significant element of protocol design to integrate them with the MIH service itself, in particular secure peer discovery and capability negotiation. This draft presents an outline solution for the common protocol functionality, based on the use of the General Internet Signaling Transport (GIST) protocol [4]. GIST has been developed in the NSIS working group to provide common protocol support for a diverse set of signalling applications, such as resource reservation [5] and middlebox control [6]. Within the overall NSIS protocol Hancock & Hepworth Expires December 21, 2006 [Page 3] Internet-Draft GIST for MIH June 2006 suite, GIST has responsibility for the discovery (implicit or explicit) of the signalling peers that should take part in a transaction, and the actual transfer of the signalling messages between them (including security and transport issues). In this sense, it is already aligned at a high level with the requirements for the MIH support, especially so far as message transfer functionality is concerned. For discovery, the initial use cases for GIST have followed the 'path-coupled' signalling paradigm, where the signalling peers are assumed to lie on the path taken by a flow in the network; however, GIST has the concept of modular message routing methods to implement alternative discovery paradigms, and this flexibility can be used to develop a simple extension of GIST for the MIH problem space if this turns out to be necessary. This draft is structured as follows. Section 2 provides an overview of how GIST can be used to support the various functional requirements for the MIH support; in most cases, there is a single natural approach and only a brief discussion is required. The case of routing and discovery is more complex; this is discussed in more detail in Section 3, which outlines three possible design options and their advantages and disadvantages. Section 4 describes the process of implementing an MIH service within such a protocol framework. Security considerations are discussed in Section 5, and finally Section 6 summarises the open issues and provides conclusions and recommendations. 2. Functionality Overview This section follows the structure of section 3 of [3] in addressing each design consideration in turn. 2.1. Discovery and Routing Discovery and routing are the most MIH-specific parts of the signalling problem. The considerations of [3] imply that this functionality should be integrated as part of the GIST layer at least to some extent, for example because it interacts very strongly with the re-use of standard security and transport protocols which are the basis of GIST functionality. The current GIST specification includes one routing method that could be used to allow the MIH services to specify the signalling peer address directly, and this could be used as a fallback method. However, it is likely that a GIST extension to support a different type of message routing will provide better performance. This issue is therefore discussed in more detail in Section 3. Hancock & Hepworth Expires December 21, 2006 [Page 4] Internet-Draft GIST for MIH June 2006 2.2. Message Transport All the standard message transport requirements can be supported by GIST, by virtue of it being able to negotiate the use of standard transport protocols. The baseline GIST specification supports a minimal unreliable mode (using UDP), and reliable, congestion controlled and flow controlled transport over TCP, which is also the only mode to allow large messages. As an implementation and policy issue, GIST is allowed to create multiple TCP connections to avoid head of line blocking or to support differential transmission priorities. Between two peers, messages may be transported reliably, unreliably, or any mixture of the two. Note that the MIH services would not directly select between these various possibilities; they just indicate the transmission requirements for a particular message and rely on GIST to transport it accordingly. It is not forseen that additional transport protocols would be needed for the support of MIH services. Services that intermittently required a large volume of unreliably transported real-time data (e.g. for measurement reporting) could benefit from the use of DCCP, although careful service design and implementation would be needed to avoid saturating the radio links with reporting data. A GIST extension to use SCTP has already been proposed [7], which would allow a single transport connection to support multiple priority streams as well as mixing reliable and unreliable data, which would lead to efficiency savings; however, support for SCTP in mobile nodes is not currently widespread. 2.3. State Management Conceptually, GIST provides a stateless service to the upper layers (MIH services). It is up to the MIH service to define its own transaction structure; whether or not transactions nest or overlap or how a transaction structure is even indicated at all is left open. Also, there is no hard binding or dependency between state at the GIST level and state at the MIH service level: they can be managed largely independently. For example, the opening or closing of a TCP connection within GIST has no significance to an MIH service - transport connection state can be managed separately. In particular, if the MIH service needs to refresh state periodically at a peer or tear it down, this is done with explicit messages at the service level rather than implicitly by configuration operations on GIST. GIST does have a concept of signalling sessions; however, a signalling session is simply a group of signalling messages with a common session identifier (SID). It is left to the signalling application to generate SIDs and assign them to individual messages or groups of messages. The main significance of SID selection is Hancock & Hepworth Expires December 21, 2006 [Page 5] Internet-Draft GIST for MIH June 2006 that messages for a single session that are delivered reliably will be delivered in order. (In addition, GIST maintains a separate copy of the routing state for each signalling session that it is aware of, although this is to handle certain security considerations rather than in the expectation that routing state will be SID dependent.) In the MIH context, it is likely that only a small number of sessions (e.g. 1) will need to be created by an MIH service while it is operating for any single mobile node. GIST will automatically maintain its internal state to ensure that MIH messages can continue to be transported. MIH services can provide timing information on how long it will require such state to be kept for. GIST can provide hints to the MIH service that the state of peer node may have changed (see Section 2.8), but it is up to the MIH service itself to verify the exact situation and take appropriate recovery actions. 2.4. Multiplexing and Extensibility GIST supports multiple signalling applications. Messages for different signalling applications are transported independently, and a single identifier distinguishes which application in a node should receive the message. The identifier is the NSIS Signalling Layer Protocol Identifier (NSLPID), which is a two byte field managed by IANA (see section 9 of [4]). MIH services could use a single NSLPID, with further demultiplexors defined inside the signalling application payload, or a set of NSLPIDs could be allocated. Because the routing of a message depends on the NSLPID, the choice has implications for the design of the routing and discovery functionality, see Section 3 below. The minimal approach would be to request a new NSLPID for each MIH service, but more sophisticated options are possible. General guidelines on the extensibility of the NSIS protocol suite as a whole are contained in [8]. 2.5. Network Layer Interactions The signalling messages themselves have to pass through the network infrastructure, and thus are subject to the same problems with middlebox (NAT and firewall) traversal as all other types of data traffic. The signalling also has to operate in both IPv4 and IPv6 environments and also possibly in transition scenarios. Most of these issues have to be handled in the GIST layer. Since this uses standard transport encapsulations (currently UDP and TCP) for all its data, NAT traversal should not be a problem. (The transport connections are initiated from the terminal, which in most Hancock & Hepworth Expires December 21, 2006 [Page 6] Internet-Draft GIST for MIH June 2006 cases will be on the 'private' side of any NAT, which is the same scenario as typical host-initiated client-server interactions.) The UDP exchanges use a specific well-known port which firewalls would have to be configured to pass. The transport protocol negotiation allows agile port numbers to be used for the TCP connections, so this would either require GIST-awareness in the firewall to open the correct ports, or pinning the port to be offered in the GIST layers in the signalling nodes themselves. GIST is IP version neutral because it uses transport protocols which can operate equally over IPv4 or IPv6. Special problems arise if the signalling application data, i.e. the messages defined for the MIH services, contain embedded IP addresses for third party nodes (i.e. other than the addresses of the signalling nodes themselves). If this is the case, these payloads may need to be translated in an application specific way as the message passes through a NAT. Whether this is actually necessary depends on a more detailed analysis of the MIH services themselves; if it is, it is potentially a source of considerable complexity because it requires the signalling to be aware of the address realm topology over a potentially wide area. It would be ideal if it was possible to express any IP addressing information at the MIH service level in terms of a single addressing realm (for example, the addressing as seen by the terminals themselves). The current 802.21 [2] draft does include payloads with such data, and further analysis would be needed to understand whether these need to be carried explicitly as addresses or simply as references to nodes in the signalling exchange. 2.6. Message Security GIST is able to negotiate the use of channel security protocols to protect the messages between adjacent signalling peers. (Here, the term 'adjacent' means two nodes supporting the same signalling application, without any other node for that signalling application between them. There could be one or several IP hops between the peers.) In principle, any channel security protocol can be negotiated; in the initial GIST specification, the single mandatory- to-implement mechanism is TLS over TCP, with TLS authentication using certificates. Further security options could be added within the GIST framework with relatively simple extensions, such as: o TLS over other transports (DTLS over UDP, TLS over SCTP) o Other TLS authentication mechanisms o IPsec using IKE or KINK for authentication and key exchange Hancock & Hepworth Expires December 21, 2006 [Page 7] Internet-Draft GIST for MIH June 2006 The main motivation for defining additional security options would be to re-use existing security (authentication) infrastructures with existing deployed sets of credentials. It would be natural to carry out such extensions to GIST itself, rather than building something MIH specific into the signalling application level. In particular, GIST already includes a protocol negotiation capability which can support the addition of further options, and designing such a negotiation which is secure against bidding-down and denial of service attacks is not trivial. The operation of the channel security mechanism chosen can be made largely invisible to the MIH services. For any specific message they simply have to indicate to GIST that security protection is required. The authenticated identifier of the peer can be checked before the message is sent, and this is also available at the receiver. The initial negotiation process (what to offer, what to accept and what to demand) is policy driven, and it may be appropriate for MIH services to require a particular security policy to ensure that appropriate security associations are actually created. 2.7. Overload Management The basic requirement for overload management within GIST is to avoid causing network layer congestion in the Internet (between signalling nodes). This is achieved mainly by using congestion-controlled transport protocols for the bulk of signalling data transfer, coupled with rate control for the unreliable message transfer and exponential backoff for the initial discovery transactions. These also serve to handle processing overload within the GIST layer itself. GIST simplifies the process of writing overload-controlled signalling applications by providing a flow controlled transport service between them. The flow control runs directly between the signalling application nodes; if the receiving node is not able to accept signalling data fast enough from GIST, the sending node will be flow controlled. Overload adaptation mechanisms are left entirely to the application: possibilities include discarding messages at the receiver after minimal processing, discarding messages at the sender when overload is detected, or adapting transaction timers (e.g. refresh rates) at the sender. As well as overload caused by excessive volumes of (legitimate) signalling application data, there is a related problem of overload caused by malicious injection of signalling application data as part of a denial of service attack. GIST includes a two-stage defence against this type of attack. Firstly, the initial discovery process incorporates a cookie exchange which forces the initiator of the discovery process to create local state before a signalling Hancock & Hepworth Expires December 21, 2006 [Page 8] Internet-Draft GIST for MIH June 2006 relationship can be created. Once this has been done, if channel security is used this is an efficient mechanism to reject messages from non-authenticated peers. 2.8. Failure Handling As part of the discovery process, GIST is responsible for detecting when there is no signalling support for a particular service in the network. Detection would result from failure to receive a response to a query after some number of retries with an exponential timer backoff; the number of retries can be configured as part of local GIST policy, and has to be set as a tradeoff between resilience and timeliness. Once a signalling node has been discovered, GIST does not perform application liveness monitoring itself, but it is able to provide hints to the application that an error condition may have occurred if indications from the network or transport layer suggest this. 3. Extended Message Routing Methods 3.1. Overview A key aspect of the operation of any signalling protocol is how the peers in the message exchange are defined and discovered. Distinct from typical application protocols, the correct peer will not be defined in terms of some global identifier (e.g. a specific DNS name or IP address), but will rather be a function of two variables: o The type of signalling to be done (be it for resource reservation, middlebox control, MIH services, or whatever) o The network context within which the signalling takes place For example, for the MIH Event Service, the destination for a message from a terminal can be abstractly stated in some form like "the ES server for the network to which I am currently attached". In the NSIS protocol suite, the responsibility for routing messages is placed on GIST, which takes the abstract destination specification and turns it into message delivery towards a concrete node. This may be done either by transmitting the message directly with a special encapsulation so it is intercepted at the correct node without prior communication setup; or, by using the first technique to discover the peer node explicitly and then send messages point to point. A related element of functionality is that GIST is responsible for monitoring the local network state and determine when the peer node has or might have changed. (This is generically referred to as route change handling, because a change in the local topology is the Hancock & Hepworth Expires December 21, 2006 [Page 9] Internet-Draft GIST for MIH June 2006 commonest cause for such a peer change; however, the same functionality handles other situations, such as changes in the capability of a signalling node itself.) Note that discovery is the responsibility of the initiator of the signalling exchange, but once it has taken place, further transactions can be started by either peer (i.e. the association is symmetric); in the following we assume that the initiator in MIH scenarios is always the terminal. The combination of functions need to perform message routing (including peer discovery and route change handling) in GIST is referred to as a 'Message Routing Method' (MRM). An MRM defines a specific set of data items on which the message is routed, the Message Routing Information (MRI). Two MRMs are defined in the base GIST protocol; it needs to be decided whether to base MIH support on one of these, or whether a new MRM should be defined. The current MRMs are: Flow-coupled: The signalling message is defined to pass along the same set of nodes as the packets of a specific flow; the flow is defined by a header N-tuple, which makes up the MRI itself. This MRM is not applicable in the MIH context, because the signalling messages are not associated with particular flows. (This MRM is primarily aimed at resource reservation signalling applications.) Loose-end: The signalling message is sent in the direction of a particular destination identified by its IP address, but is expected to be intercepted at a network boundary on the way. It would be possible to use the loose-end MRM for MIH support, thereby essentially pushing the discovery responsibility into the signalling application (MIH service). The signalling application could use any of a number of IP layer discovery techniques to determine the destination IP address for a particular MIH service, such as DHCP [9][10], SLP [11], mDNS [12], or even link-specific techniques, and then use that address directly as the signalling destination in the loose-end MRM. Although such techniques are not favoured (for reasons discussed more extensively in [3]), this approach can always be used as a fall-back if required. 3.2. A Message Routing Method for MIH Services An alternative approach is to create a new MRM, where the message routing information includes precisely the identifiers that are needed to select between the possible peers to take part in a signalling exchange. Defining the set of identifiers requires further analysis of the set of MIH services, but could include: Hancock & Hepworth Expires December 21, 2006 [Page 10] Internet-Draft GIST for MIH June 2006 o The MIH service identifier (if this is not already provided by the NSLPID itself). o Some information about the terminal, such as the realm id of the home network (for example if the information service is proxied back to nodes in the home network). o Some information about the terminal type or capability. Note that the information should be strictly limited to that which is necessary for message routing; any other MIH specific information can be carried in the service payload itself. The terminal sends signalling messages with this routing information towards its first-hop IP access router (AR). Here we are assuming that IP connectivity is already available; the case where IP connectivity is not available is already handled by lower layer protocols in the 802.21 model [2], and would be out of scope for other MIH work in the IETF. An operator deploying MIH services in a wireless network is required to configure the ARs so they either support the MIH services directly, or know how to forward signalling messages to nodes that do. There are at least two options here: 1. The AR is able to parse the GIST message including the MRI, and consult local routing information to forward the message on to the actual MIH serving node. The routing information has to be installed by the network operator, which could typically be done using network management or network autoconfiguration techniques (as discussed above) - the actual method is not visible to the terminal. The end result will be that the terminal will peer directly with the correct signalling node. The same technique can be used to forward the signalling exchange upwards through a chain of proxies. This mode of operation is conceptually similar to the forwarding of AAA messages in AAA protocols such as RADIUS[13] or Diameter [14], where the analogue of the message routing information is the realm part of the NAI. A further refinement would be to define a default lookup mechanism in the AR which could be overridden by specific manual configuration. 2. A second technique which requires less GIST-specific processing in the AR is to configure the AR to intercept the discovery messages at the IP/UDP level and forward them directly to a dedicated node which performs the MIH-specific routing. The format of the GIST encapsulation of discovery messages means that this is possible on most standard routers (in an implementation specific way). Similar techniques are described for the purpose of carrying out a type of off-path signalling in [15]. Hancock & Hepworth Expires December 21, 2006 [Page 11] Internet-Draft GIST for MIH June 2006 The benefit of this approach compared to putting the discovery responsibility into the MIH service is that the terminal requirements are minimised and that considerable freedom is left for the internal configuration of the network. The terminal can issue signalling messages as soon as IP connectivity is available without waiting for a separate discovery process (e.g. DHCP or SLP) to complete; this is particularly valuable in the post-handoff stage where the terminal could verify whether the MIH serving nodes have changed within a single round trip. There is also no need to select a single discovery protocol, which would be mandatory-to-implement for all terminals and network environments, including those in which no such protocols are automatically expected to be used (e.g. IPv6 with stateless autoconfiguration). Indeed, it may be possible to generalise this method to the case where direct layer 2 transport is being used before full IP connectivity is available at all. If discovery is handled within the GIST layer in this way, GIST can also take responsibility for tracking the correctness of the routing state by periodically re-probing the network to find if conditions have changed. A further advantage is that the denial of service properties of the signalling connection setup can be analysed in an integrated way, rather than being a property of the discovery protocol selected by the MIH service, the transport protocol it uses, and the interaction between them. 3.3. Multi-MIH Service Discovery The above approaches to signalling node discovery require a query- response transaction for each different MIH signalling node that the terminal wishes to communicate with. Because each MIH service could conceptually be implemented on a different node, GIST requires a query-response exchange for each MIH service. This would be the behaviour if the approach of using a single NSLPID for each MIH service was used, as discussed in Section 2.4. However, one requirement that has been discussed during various stages of the 802.21 developments is that it would be desirable to be able to carry out multiple discovery operations in a single message exchange. One solution to this conflict is to reject the requirement. It is in any case a performance optimisation rather than a fundamental goal. Whether this is acceptable depends on whether there are many MIH services with strong time constraints on the discovery phase. If there are several such services, then there are two ways to aggregate them under a single NSLPID, which is an absolute requirement to be able to discover multiple service endpoints with a single GIST query. (Please note that familiarity with the GIST design [4] is a prerequisite for understanding the content of this section.) Hancock & Hepworth Expires December 21, 2006 [Page 12] Internet-Draft GIST for MIH June 2006 1. To carry the required set of service identifiers as piggybacked NSLP data in the query message. The first receiver of the Query message can respond on behalf of the services that it supports, and forward a modified Query to another node or nodes for the remainder. Although this is conceptually possible, it would be very hard to fit into a standard GIST implementation, because the GIST stack in the initiating terminal would see multiple responses to a single Query, with no information visible at the GIST layer to distinguish between them. Also, for subsequent messages, there is no information visible at the GIST layer about which service is being invoked, so there would be no method to distinguish which peer to send the message to. Therefore, this method is not favoured. 2. To carry the required set of service identifiers as part of the message routing information (for example, as a capability bitmap). Again, the first receiver generates a response for the subset of services that it supports, and re-forwards the Query with a reduced set of service identifiers. Each response creates a separate item of GIST routing state for a specific subset of supported services. Subsequent messages would indicate a particular service identifier and be matched against the routing state for it. The second technique is conceptually feasible and does fit into the GIST layer model relatively naturally. It would require some analysis of the GIST state machine behaviour to ensure that necessary modifications can be confined to the MRM specification. (The current definition of the routing state machine assumes that there is a single response to any given Query. One simple way to handle the extension is to require the initiating node to clone the state machine when it receives a partial response, which mimics the same behaviour as would occur if multiple Queries had been sent in the first place.) Analysis would also be needed of the NAT traversal behaviour; however, it is already a requirement that this has to be able to allow multiple responses for the same query (because of retransmissions). It requires further analysis to decide whether the additional complexity of such a solution is merited by the performance improvement that is gained. Note that similar problems arise with any type of discovery mechanism, where there are potentially multiple (and an unknown number) of responses to a single message. 4. MIH Service Development On the assumption that GIST is used to provide the common MIH support Hancock & Hepworth Expires December 21, 2006 [Page 13] Internet-Draft GIST for MIH June 2006 functions, the process of formalising the way that an MIH service would use it is relatively simple. If the MIH service is already defined as a sequence of message exchanges, the formalisation mainly consists of a description of how the MIH service requires GIST to be configured and how it invokes GIST to transport each message in turn. 1. NSLPIDs for the MIH service need to be chosen; there may be one or several (see Section 2.4). Typically any single message would be associated with a single specific NSLPID unless there is some type of aggregation concept, which seems not to be applicable here. 2. The invocation of GIST to transfer a messase is modelled in terms of an abstract API (section B of [4]). The originator invokes SendMessage() and the receiver processes it with RecvMessage(). The actual message payload is defined by the MIH specification and is opaque to GIST. Further parameters influence the message transfer process, and the MIH service needs to define how these will be used: A. The MIH service needs to decide how messages are to be assigned to signalling sessions (see Section 2.3). B. The MIH service needs to provide message routing information (see the discussion above in Section 3). This includes the option to require the message to be routed explicitly to the same peer that took part in a previous exchange (this can be used, for example, for explicit state teardown). C. The MIH service can specify additional security and transport attributes (whether channel security is required and whether the message needs to be reliably delivered). D. The MIH service may also provide hints about the message priority, timeouts on how long delivery should be attempted, and how to be notified about error conditions relating to the message, although all of these only affect local processing within the node rather than end to end behaviour. 3. If a new MRM is needed to support the MIH routing and discovery requirements, this also needs to be specified as a GIST extension in parallel to the MIH specification itself (see Section 3 above). Part of this includes the definition of how to detect and react to route change events, which can also result in notifications over the API between GIST and the MIH services. 4. If additional authentication methods or security protocols need to be defined (compared to the baseline of TLS + certificates) to Hancock & Hepworth Expires December 21, 2006 [Page 14] Internet-Draft GIST for MIH June 2006 ease MIH deployment in particular environments, these should also be defined as GIST extensions. In addition, the criterial for security policies for the use of GIST for MIH will need to be developed, and a security analysis of the combined (MIH service + GIST) solution. These issues are discussed in the security considerations section below, Section 5. 5. Security Considerations This document proposes to address the MIH requirements within a layered protocol model, within which some security functionality is provided in a generic way by a lower layer (GIST). It is important to note that not all the MIH security requirements can be met by GIST, nor can the applicability of GIST security for MIH be analysed in isolation from other parts of the MIH solution. In particular, whether the end result is secure depends on how GIST is used (what features are used and how they are invoked). In addition, GIST is completely neutral to certain security requirements, specifically in the area of authorisation, and these must be handled by the correct implementation and configuration of the MIH services that run over it. A discussion of general threats to signalling (with a partial focus on QoS and on-path routing) can be found in [16]; most of these issues can be extended to the MIH problem space. Therefore, the approach taken here is to describe the security functionality provided by GIST, and indicate how it could be used as part of a more complete security solution. The main functions are as follows (details are given in Section 2.6): Message protection: GIST can negotiate the use of a standard channel security mechanism (initially TLS) to provide confidentiality and integrity protection for messages passing between adjacent signalling nodes. It cannot provide security for messages over greater scope than one signalling hop, nor can it assert whether the message originator has the right to request whatever actions the message implies (i.e. authorisation). These issues must be addressed within the MIH service itself. Peer authentication: GIST uses the authentication mechanism within the channel security protocol to provide per-peer authentication. The default in the current version is limited to TLS authentication based on certificates; the authenticated peer identities are visible to the MIH service and may be used as part of an authorisation decision. It may be desirable to extend the set of authentication mechanisms to improve the applicability and Hancock & Hepworth Expires December 21, 2006 [Page 15] Internet-Draft GIST for MIH June 2006 ease of deployment in the MIH problem space. Security protocol selection: GIST provides a handshake which can negotiate one option from a set of security protocols, in a way which is secure against bidding-down attacks and denial-of-service attacks. (This is distinct from any option negotiation within the possible security protocols themselves.) Normally the details of this negotiation would be invisible to MIH services; however, there may be a need for specific security policies to ensure that the level of protection negotiated is appropriate. Denial of service mitigation: GIST includes mechanisms to mitigate denial of service (flooding) attacks within the GIST layer, and can also negotiate channel protection to enable the rejection of signalling messages from unauthenticated peers. An MIH service using GIST in this way only needs to care about flooding or other DoS attacks launched by authenticated peers. An MIH service designed to run over GIST needs to specify the required security policy that should be imposed at the GIST level, and also needs to define how authorisation is defined and denial of service attacks are prevented at the service level. These latter problems are clearly closely related. 6. Conclusions This draft has presented an outline solution for supporting common MIH signalling functions using GIST. Most of the required functionality is already present in GIST; some options for GIST extensions were also identified. Most of the functionality of GIST is obtained by the integration of existing security and transport protocols, and conceptually it would be possible to design MIH services so they just re-use these protocols directly. Compared to this, the advantages of a GIST-based approach include: o integrated negotiation of which security and transport protocols to use, including protocol options and port numbers (no need to fix on a particular choice); o negotiation which is resistant to denial of service and bidding down attacks; o peer discovery and protocol negotiation take place in a single round trip, minimising latency; Hancock & Hepworth Expires December 21, 2006 [Page 16] Internet-Draft GIST for MIH June 2006 o ability to support a mixture of transport and security attributes under a common API; o optimised discovery of multiple signalling endpoints in a single message exchange (with some GIST extensions). Further development of a GIST-based solution depends on some more detailed analysis of the MIH problem space. Issues which have been noted in this draft include: o whether additional security protocol support will ease deployment in typical MIH environments; o what are the more detailed scenarios for signalling endpoint location (with implications for how much sophistication is needed in the discovery process); and o how to fit the MIH service structure into the overall NSIS protocol suite framework, for example as one or several signalling applications. 7. Informative References [1] Hepworth, E., "Media Independent Handovers: Problem Statement", draft-hepworth-mipshop-mih-problem-statement-01 (work in progress), March 2006. [2] IEEE 802.16, "Draft IEEE Standard for Local and Metropolitan Area Networks: Media Independent Handover Services", March 2006. [3] Hepworth, E., "Design Considerations for MIH Transport", draft-hepworth-mipshop-mih-design-considerations-00 (work in progress), March 2006. [4] Schulzrinne, H. and R. Hancock, "GIST: General Internet Signaling Transport", draft-ietf-nsis-ntlp-09 (work in progress), February 2006. [5] Manner, J., "NSLP for Quality-of-Service Signaling", draft-ietf-nsis-qos-nslp-10 (work in progress), March 2006. [6] Stiemerling, M., "NAT/Firewall NSIS Signaling Layer Protocol (NSLP)", draft-ietf-nsis-nslp-natfw-11 (work in progress), April 2006. [7] Fu, X., "General Internet Signaling Transport (GIST) over Hancock & Hepworth Expires December 21, 2006 [Page 17] Internet-Draft GIST for MIH June 2006 SCTP", draft-fu-nsis-ntlp-sctp-01 (work in progress), February 2006. [8] Loughney, J., "NSIS Extensibility Model", draft-loughney-nsis-ext-02 (work in progress), March 2006. [9] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March 1997. [10] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003. [11] Guttman, E., Perkins, C., Veizades, J., and M. Day, "Service Location Protocol, Version 2", RFC 2608, June 1999. [12] Cheshire, S. and M. Krochmal, "Multicast DNS", draft-cheshire-dnsext-multicastdns-05 (work in progress), July 2005. [13] Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000. [14] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. Arkko, "Diameter Base Protocol", RFC 3588, September 2003. [15] Hancock, R., "A Problem Statement for Partly-Decoupled Signalling in NSIS", draft-hancock-nsis-pds-problem-03 (work in progress), March 2006. [16] Tschofenig, H. and D. Kroeselberg, "Security Threats for Next Steps in Signaling (NSIS)", RFC 4081, June 2005. Appendix A. Acknowledgements The authors would like to thank the participants in the NSIS and MIPSHOP working groups in the IETF and 802.21 in the IEEE for many discussions on signalling protocols in general, and MIH services in particular, which have informed the content of this draft. Robert Hancock and Eleanor Hepworth are partly funded by Ambient Networks, a research project supported by the European Commission under its Sixth Framework Program. The views and conclusions contained herein are those of the authors and should not be interpreted as necessarily representing the official policies or endorsements, either expressed or implied, of the Ambient Networks Hancock & Hepworth Expires December 21, 2006 [Page 18] Internet-Draft GIST for MIH June 2006 project or the European Commission. Hancock & Hepworth Expires December 21, 2006 [Page 19] Internet-Draft GIST for MIH June 2006 Authors' Addresses Robert Hancock Roke Manor Research Old Salisbury Lane Romsey, Hampshire SO51 0ZN UK Email: robert.hancock@roke.co.uk Eleanor Hepworth Roke Manor Research Old Salisbury Lane Romsey, Hampshire SO51 0ZN UK Email: eleanor.hepworth@roke.co.uk Hancock & Hepworth Expires December 21, 2006 [Page 20] Internet-Draft GIST for MIH June 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. Hancock & Hepworth Expires December 21, 2006 [Page 21]