Internet Engineering Task Force R. Hancock Internet-Draft J. Manner (ed.) Expires: April, 2004 C. Shen October, 2003 Interactions of Routing and Mobility on NTLP and NSLP Status of this Memo This document is a submission to Next Steps in Signaling Working Group. Comments should be submitted to the nsis@ietf.org mailing list. Distribution of this memo is unlimited. This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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 in April, 2004. Copyright Notice Copyright (C) The Internet Society (2003). All Rights Reserved. Abstract IP packet routing and changes in routes can have major influence on protocols and services that set state in network nodes. Routing may change, for example, due to node failure within the network, need for load balancing, multihoming or due to end-host or even network mobility. This draft is a first step in helping us to decide on how these problems should be handled and how interactions with other protocols should be handled and a stimulus to further security work. Hancock et al Expires April 2004 [Page 1] Internet-Draft Routing and Mobility in NSIS October 2003 Table of Contents 1 Introduction ................................................. 2 2 Short Problem Statement ...................................... 3 3 Session Path Change .......................................... 4 3.1 Problem Statement .......................................... 4 3.2 Possible Scenarios for Session Path Change ................. 5 3.2.1 Cases corresponding to a NNE as UCOR ..................... 6 3.2.2 Cases corresponding to a PNE as UCOR ..................... 8 3.2.3 Cases corresponding to a FNE as UCOR ..................... 10 3.3 Detection of Session Path Change ........................... 12 3.4 Response to Route Change caused Session Path Change ........ 13 3.4.1 Network Monitoring based UCOR detection .................. 13 3.4.2 Data Packet Monitoring based UCOR detection .............. 14 3.4.3 Signaling packet Monitoring based DCOR detection ......... 14 3.5 Other cases ................................................ 15 3.6 QoS routing Considerations ................................. 15 3.7 Response to Mobility Caused Session Path Change ............ 15 4 IP Mobility and Multihoming .................................. 15 4.1 Comparison with Route Changes .............................. 15 4.2 Analysis Overview .......................................... 17 4.3 MN-Terminating Session ..................................... 19 4.3.1 CN (Sender) Initiated Setup and Teardown ................. 19 4.3.2 MN (Receiver) Initiated Setup and Teardown ............... 21 4.4 MN-Originating Session ..................................... 25 4.4.1 MN (Sender) Initiated Setup and Teardown ................. 25 4.4.2 CN (Receiver) Initiated Setup and Teardown ............... 27 4.5 Summary of the Analysis .................................... 29 4.6 Further Interactions with Fast Handover Protocols .......... 31 5 Security Considerations ...................................... 33 6 Contributors ................................................. 34 7 Acknowledgments .............................................. 34 8 Informative References ....................................... 34 9 Author's Addresses ........................................... 34 1. Introduction This draft addresses Mobility related considerations for NSIS. Given the scope of mobility, it is helpful to discuss it together with two other closely related topics, namely, route change and IP address changes. Generally speaking, the relationship among the three is: 1. All mobility necessarily incurs route change, usually at edge of the network. But route change may also be caused by reasons other than mobility, such as routing protocol adaptation in response to varying network conditions. The latter type of route changes usually occurs in the middle of the network. 2. Normal IP mobility (i.e., Macro-mobility) involves change of MN IP addresses. Micro mobility usually does not cause change of IP addresses. Hierarchical mobility contains both macro-mobility and micro-mobility scenarios and thus limits the effect of IP address change into a smaller scale than that of macro-mobility. Since IP Hancock et al Expires April 2004 [Page 2] Internet-Draft Routing and Mobility in NSIS October 2003 address is usually part of the flow identifier, change of IP addresses implies change of flow identifier. A route change triggered by host mobility may or may not involve changes in IP addresses. Some Local Mobility Management (LMM) mechanisms may change the IP address assigned to the mobile node within the access network, for example, mechanisms based on a hierarchy of mobility handling routers. Some protocols either use tunneling to forward packets towards the new location of the mobile node, or set and update per-host routing entries in the network, as for instance, ad-hoc routing protocols. Issues that also affect the state management in NSIS are host multihoming, the actual routing path created by mobility management protocols, whether the routing is optimal or triangular, the use of a context transfer framework, and who and when notices the need for updating states. This latter involves noticing the need to update states, for example, whether it is the sender or the receiver of the data stream, or some intermediary router. Moreover, whole mobile networks will need to be studied in more depth in the context of NSIS. 2. Short Problem Statement The various services that may make use of the forthcoming NSIS protocols set state within network nodes and routers. There are various issues that must be handled carefully when the NSIS protocols are used in non-static environments, as for instance, mobile nodes in wireless access networks. The following list is a short summary of the main issues that must be considered when the NTLP and NSLP protocols are used in dynamic environments: - Interactions with session state information and routing information (=IP address) - If session states are set for single unicast communications, state on the obsolete path must be removed quickly after the routing changes. - Changes in states and routing should only be signaled within the affect part of the network, and, thus, should not require end-to-end signaling. This may not always be possible, if, for example, the IP address of the sender or receiver changes. - Possibility to keep signaling local, or within an identified scope. This would be useful, especially in mobile networks, to be able to reserve only local resources. This feature would require that the node terminating the NSIS signaling must be a different node than the one receiving the user data. - Various LMM mechanisms use tunneling or affect routing table entries. These changes, and tunnels in general, affect the way NSIS protocols are able to set state on the same path as the user data, Hancock et al Expires April 2004 [Page 3] Internet-Draft Routing and Mobility in NSIS October 2003 and are able to identify the original IP packets carrying user data. - Route changes noticed by NTLP, or some other entity within an NSIS router, should be propagated to NSLP, and or NTLP, respectively. This is similar to the operation of RSVP, where routing changes noticed by the router are propagated to the RSVP process running on the router. - Interactions of NTLP/NSLP and Mobile IP need to be taken into account. - Interactions with NTLP/NSLP and CARD and CT need to be studied. - Slow wireless links may require additional considerations within NSIS, for example, state refreshes, and any other NSIS-related signaling, should be sent less frequent over the wireless link than within the wired network. - Issues in discovering the cross-over router to find the limit of the affected path. - A critical issue is also the security of the signaling, AAA and encryption. When a node moves or routing changes happen within the network, how can the new peer, for example, a new access router, authenticate and decrypt protected NTLP/NSLP messages? 3. Session Path Change 3.1. Problem Statement In this document session path change is used to refer to the common aspect of route change and mobility. Path change is further divided into downstream path change and upstream path change: In NSIS context, a downstream path change occurs when the outgoing interface for a session has changed; an upstream path change occurs when the incoming interface for a session has changed. Path change results in divergence of packets in data plane and/or in control plane. We refer to the node where this divergence starts as the Upstream Cross- Over Router (UCOR) and the node where this divergence ends as a Downstream Cross-Over Router (DCOR). It should be noted that: 1. It is possible to adopt a more NSIS-aware UCOR/DCOR definition rather than this strict "route splitting point" definition. For example, in cases where the route splitting point is not NSIS capable, the UCOR/DCOR could be defined as the NTLP/NSLP node downstream or upstream of it. 2. Although this definition is meant to refer to routers (as the name suggests). It is also possible and interesting to extend it to include end nodes especially in Mobility and Multi-homing scenarios. For example, in sender mobility case, the MN *could* view the result of its mobility functions (change of IP address) as similar to a Hancock et al Expires April 2004 [Page 4] Internet-Draft Routing and Mobility in NSIS October 2003 downstream routing change event (it needs intelligence to do that) and be defined as a UCOR. In multi-homing case, the MN *could* view the result of its multi-homing functions (change of outgoing interface) as similar to a downstream routing change event and be defined as a UCOR. We consider a mixed signaling configuration scenario outlined in Figure 1 (copied from [1]), i.e., not all routers in the path are NSIS Entities (NEs); All NEs support NTLP; but not all NEs support all NSLPs. We use NSLP1 as an example in the description below. We refer to the three types of nodes seen by a particular session as: Full-NSIS Entity or FNE (supports NTLP and the specific NSLP1), Partial NSIS Entity or PNE (supports NTLP but not the specific NSLP1); Non-NSIS Entity (NNE) (supports neither NTLP nor NSLP1). +-----------+ +----+ +----+ +----+ +-----------+ |Application|---->| R1 |---->| R2 |---->| R3 |---->|Application| | +--+ | |+--+| |+--+| +----+ | +--+ | | |NE|====|=====||NE||=====||NE||================|===|NE| | | +--+ | |+--+| |+--+| | +--+ | +-----------+ +----+ +----+ +-----------+ Figure 1(a): Simple Signaling and Data Flows +------+ +------+ +------+ +------+ | NE | | NE | | NE | | NE | |+----+| | | |+----+| |+----+| ||NSLP|| | | ||NSLP|| ||NSLP|| || 1 || | | || 2 || || 1 || |+----+| | | |+----+| |+----+| | || | | | | | | || | |+----+| |+----+| |+----+| |+----+| ====||NTLP||====||NTLP||====||NTLP||====||NTLP||==== |+----+| |+----+| |+----+| |+----+| +------+ +------+ +------+ +------+ Figure 1(b): Signaling with Heterogeneous NSLPs 3.2. Possible Scenarios for Session Path Change Session path change can be caused by either route change or mobility. The main difference of these two cases, in terms of UCOR and DCOR can be summarized as follows: In case of route change, usually both UCOR and DCOR exist and they form a loop; In case of mobility, Sender mobility will create a DCOR, Receiver mobility will create a UCOR. If the MN is both sending and receiving, there will be both UCOR and DCOR, they may or may not be in the same physical node depending on the routing symmetry. Session path changes caused by mobility are analyzed in more detail in Section 4.1. Hancock et al Expires April 2004 [Page 5] Internet-Draft Routing and Mobility in NSIS October 2003 Since either UCOR or DCOR can be any of the FNE, PNE or NNE, we have 9 possible UCOR/DCOR combinations for route change and 6 possible cases for sender/receiver mobility. From topology point of view, the 6 mobility cases are actually simplified versions of corresponding route change cases. However, mobility also involves other aspects not present in route change, such as mobility signaling and change of Flow Identifiers. In the following, we illustrate the 9 route change scenarios. 3.2.1. Cases corresponding to a NNE as UCOR The following Figure 2 shows an example network before path change: +------+ +------+ +------+ +------+ | R1 | | R2 | | R3 | | R4 | | |L1A L2A | | |+----+| |+----+| | |---> ... ---->| |--->||NSLP||--->||NSLP||---> | | | | || 2 || || 1 || +------+ +------+ |+----+| |+----+| | | | || | |+----+| |+----+| ===========> ... ==================>||NTLP||====||NTLP||===> |+----+| |+----+| +------+ +------+ Figure 2: Case A: UCOR is an NNE, The following three figures show the three possibilities after path change for the example network: Hancock et al Expires April 2004 [Page 6] Internet-Draft Routing and Mobility in NSIS October 2003 +------+ +------+ +------+ +------+ | R1 | | R2 | | R3 | | R4 | | | | | |+----+| |+----+| | |---> | |--->||NSLP||--->||NSLP||---> | | | | || 2 || || 1 || +------+ +------+ |+----+| |+----+| | || | | | | || | | || | |+----+| |+----+| | || | ||NTLP||====||NTLP||===> | || | |+----+| |+----+| | || | +------+ +------+ | || | || | ===============...================= | | ------------->...---------- Figure 3a: Case A.I DCOR is an NNE +------+ +------+ +------+ +------+ | R1 | | R2 | | R3 | | R4 | | | | | |+----+| |+----+| | |---> | | ||NSLP||--->||NSLP||---> | | | | || 2 || || 1 || +------+ +------+ |+----+| |+----+| | || | | | || | | || |+----+| |+----+| | || ||NTLP||====||NTLP||===> | || |+----+| |+----+| | || +------+ +------+ | || || | | ===============...================ | | | ------------->...----------------------- Figure 3b: Case A.II DCOR is an PNE +------+ +------+ +------+ +------+ | R1 | | R2 | | R3 | | R4 | | | | | |+----+| |+----+| | |---> | | ||NSLP|| ||NSLP||---> | | | | || 2 || || 1 || +------+ +------+ |+----+| |+----+| | || | | | || | | || |+----+| |+----+| | || ||NTLP|| ||NTLP||===> | || |+----+| |+----+| | || +------+ +------+ | || || | | ===============...============================ | | | --------------------------...----------------------- Figure 3c: Case A.III: DCOR is an FNE Hancock et al Expires April 2004 [Page 7] Internet-Draft Routing and Mobility in NSIS October 2003 3.2.2. Cases corresponding to a PNE as UCOR The following Figure 4 shows an example network before path change: +------+ +------+ +------+ +------+ | R1 | | R2 | | R3 | | R4 | |+----+|L1A L2A | | |+----+| |+----+| ||NSLP||---> ... ----> | |--->||NSLP||--->||NSLP||---> || 2 || | | || 2 || || 1 || |+----+| +------+ |+----+| |+----+| | | | | | || | |+----+| |+----+| |+----+| ====||NTLP||===> ... ==================>||NTLP||====||NTLP||===> |+----+| |+----+| |+----+| +------+ +------+ +------+ Figure 4: Case B: UCOR is a PNE The following three figures show the three possibilities after path change for the example network: Hancock et al Expires April 2004 [Page 8] Internet-Draft Routing and Mobility in NSIS October 2003 +------+ +------+ +------+ +------+ | R1 | | R2 | | R3 | | R4 | |+----+| | | |+----+| |+----+| ||NSLP||---> | |--->||NSLP||--->||NSLP||---> || 2 || | | || 2 || || 1 || |+----+| +------+ |+----+| |+----+| | | ^ | | | || | |+----+| | |+----+| |+----+| ====||NTLP||===> | ||NTLP||====||NTLP||===> |+----+| | |+----+| |+----+| +------+ | +------+ +------+ | || | || | ==============...=============== | | |------------>...------- Figure 5a: Case B.I: DCOR is an NNE +------+ +------+ +------+ +------+ | R1 | | R2 | | R3 | | R4 | |+----+| | | |+----+| |+----+| ||NSLP||---> | | ||NSLP||--->||NSLP||---> || 2 || | | || 2 || || 1 || |+----+| +------+ |+----+| |+----+| | | | | | || | |+----+| |+----+| |+----+| ====||NTLP|| ||NTLP||====||NTLP||===> |+----+| |+----+| |+----+| +------+ +------+ +------+ | || ||^ | ==============...================= | | | ---------------------------------------- Figure 5b: Case B.II: DCOR is a PNE +------+ +------+ +------+ +------+ | R1 | | R2 | | R3 | | R4 | |+----+| | | |+----+| |+----+| ||NSLP||---> | | ||NSLP||--->||NSLP||---> || 2 || | | || 2 || || 1 || |+----+| +------+ |+----+| |+----+| | | | | | || | |+----+| |+----+| |+----+| ====||NTLP||===> ||NTLP||====||NTLP||===> |+----+| |+----+| |+----+| +------+ +------+ +------+ | || || ^ | ==============...============================ | | | --------------------------...----------------------- Figure 5c: Case B.III: DCOR is a FNE Hancock et al Expires April 2004 [Page 9] Internet-Draft Routing and Mobility in NSIS October 2003 3.2.3. Cases corresponding to a FNE as UCOR The following Figure 6 shows an example network before path change: +------+ +------+ +------+ +------+ | R1 | | R2 | | R3 | | R4 | |+----+|L1A L2A | | |+----+| |+----+| ||NSLP||---> ... ------>| |--->||NSLP||--->||NSLP||---> || 1 || | | || 2 || || 1 || |+----+| +------+ |+----+| |+----+| | || | | | | || | |+----+| |+----+| |+----+| ====||NTLP||===> ... ==================>||NTLP||====||NTLP||===> |+----+| |+----+| |+----+| +------+ +------+ +------+ Figure 6: Case C: UCOR is a FNE The following three figures show the three possibilities after path change for the example network: Hancock et al Expires April 2004 [Page 10] Internet-Draft Routing and Mobility in NSIS October 2003 +------+ +------+ +------+ +------+ | R1 | | R2 | | R3 | | R4 | |+----+|L1A L2A| | |+----+| |+----+| ||NSLP||---> ---->| |--->||NSLP||--->||NSLP||---> || 1 || | | || 2 || || 1 || |+----+| +------+ |+----+| |+----+| | || | ^ | | | || | |+----+| | |+----+| |+----+| ====||NTLP||===> |L2B ||NTLP||====||NTLP||===> |+----+| | |+----+| |+----+| +------+ | +------+ +------+ | || | || | ==============...================= | | ------------->...---------- Figure 7a: Case C.I: DCOR is a NNE +------+ +------+ +------+ +------+ | R1 | | R2 | | R3 | | R4 | |+----+| | | |+----+| |+----+| ||NSLP||---> | | ||NSLP||--->||NSLP||---> || 1 || | | || 2 || || 1 || |+----+| +------+ |+----+| |+----+| | || | | | | || | |+----+| |+----+| |+----+| ====||NTLP||===> ||NTLP||====||NTLP||===> |+----+| |+----+| |+----+| +------+ +------+ +------+ | || || ^ | ==============...================= | | | |------------>...----------------------| Figure 7b: Case C.II: DCOR is a PNE +------+ +------+ +------+ +------+ | R1 | | R2 | | R3 | | R4 | |+----+| | | |+----+| |+----+| ||NSLP||---> | | ||NSLP||--->||NSLP||---> || 1 || | | || 2 || || 1 || |+----+| +------+ |+----+| |+----+| | || | | | | || | |+----+| |+----+| |+----+| ====||NTLP||===> ||NTLP||====||NTLP||===> |+----+| |+----+| |+----+| +------+ +------+ +------+ | || || ^ | ===============...============================ | | | |-------------------------...------------------------ Figure 7c: Case C.III: DCOR is a FNE Hancock et al Expires April 2004 [Page 11] Internet-Draft Routing and Mobility in NSIS October 2003 Following is a summary of the above 9 cases with their indexes (UCOR- DCOR). o A.I NNF - NNF o A.II NNF - PNF o A.III NNF - FNF o B.I PNF - NNF o B.II PNF - PNF o B.III PNF - FNF o C.I FNF - NNF o C.II FNF - PNF o C.III FNF - FNF In all above 9 cases, route change will affect the NTLP/NSLP peer relationship of the UCOR and DCOR depending on the number of NEs in the old path and new path between the UCOR and DCOR. The 6 mobility cases as simplified versions of the route change cases may be derived from above figures by taking away either UCOR or DCOR appropriately. So similar changes in NTLP/NSLP peer relationship of UCOR/DCOR can be expected. 3.3. Detection of Session Path Change By default the time until some action may be taken to tackle the path divergence depends on when the next signaling action (e.g. NTLP refresh or NSLP refresh, if applicable) is scheduled. Path change detection may be used to shorten this period. The detection mechanism is also related to its causes: route change or mobility. In this section we only discuss route change detection. Note that mobility caused path change would usually be triggered by node movement. Movement detection is part of the mobility scheme and out of scope of this document. A summary of route change detection methods are provided in [1]. (a) monitoring changes in local interface state (b) monitoring topology changes in a link-state routing protocol (c) inference from changes in data packet TTL (d) inference from loss of packet stream in a flow-aware router (e) inference from changes in signaling packet TTL (f) changed route of an end-to-end addressed signaling packet (g) changed route of a specific end-to-end addressed probe packet These methods can be categorized as being based on network monitoring (method a-b), based on data packet monitoring (method c-d) and based on monitoring signaling protocol messages (method e-g). Hancock et al Expires April 2004 [Page 12] Internet-Draft Routing and Mobility in NSIS October 2003 Whatever method is used, the detection function needs to be mapped to NTLP, NSLP and the corresponding routing related module. Network monitoring based approach is applicable in all NNE, PNE and FNEs. It is usually used to detect downstream route change. Data packet monitoring is in theory possible in all NE types. In reality it would only ever be done on FNEs. This is because in order to monitor the data flow right, the NE needs to be told about its characteristics, and only an FNE would have this information. Signaling protocol message based monitoring is usually applicable only in PNE and FNEs, but not in NNEs. It is usually used to detect upstream route change. From Signaling application point of view, if the detection is not done by itself, there are normally two methods it can learn about path change from the actual detection function: polling or asynchronous notification. 3.4. Response to Route Change caused Session Path Change In this section we look at responses of nodes that detect path changes (refer to as detection nodes below) upon a session path change event. The main focus here is to identify the UCOR/DCOR and take appropriate local repair actions. Local repair essentially tries to achieve the following as fast (and secure) as possible: Installation of state on the new path; and removal of state on the old path. Under the layer split concept, we will probably have local repair problem in both layers. It is important to note that, generally speaking, to do any of these route change procedures, an involved node has to have per-flow state ('be a stateful node' in Westberg-speak). 3.4.1. Network Monitoring based UCOR detection Network Monitoring may be used to identify UCOR. It is important to note that in case of route change, a chain of routers between the actual UCOR and DCOR, inclusive, may detect the route to a destination has changed. But only the first router where the session traffic actually starts to diverge should be identified as UCOR. It is still an open question how these routers may decide locally whether they are indeed the UCOR or not. If this kind of decision can be made, those Detection Routers other than the UCOR or DCOR may do the following depending on its NSIS capability: do nothing (NNE); delete the existing session state (FNE) and delete related NTLP state only if the connection is also no longer used by any other session (PNE and FNE). Alternatively, the Detection Routers other than UCOR or DCOR may do nothing but waiting for explicit state teardown or timeout. The action taken by UCOR also depends on its type. Hancock et al Expires April 2004 [Page 13] Internet-Draft Routing and Mobility in NSIS October 2003 If UCOR is a NNE (case A.I-A.III), there is nothing much we can do. If UCOR is a PNE (case B.I-B.III), an NTLP level local repair is invoked. This may involve: if a "rediscovery timer" (such as in [2] similar to the route pinning effect) is used, stop it immediately (un-pin the route) and construct a discovery message for an immediate peer discovery. The discovery result will tell the NTLP whether its peer has changed or not. If a new peer is discovered, NTLP may create an association with the new peer and teardown its original association with the old peer (if that connection is no longer used by any application sessions). In either case (NTLP peer changed or not), subsequent NSLP refresh for this session will be able to use updated peer information without delay. If UCOR is a FNE (case C.I-C.III) A NSLP local repair may follow the NTLP local repair. In these cases, the NTLP may deliver a signal to NSLP that causes NSLP to start a local repair for downstream route change. An example procedure could involve: NSLP sends "RESERVE" refresh (as in terminology of [3])immediately, without waiting for the refresh timer timeout. This message will be forwarded by NTLP towards its updated peer and thus setup necessary states in any newly added NSLP nodes up to the DCOR. Explicit teardown of orphaned states in the obsolete path might be initiated by messages from UCOR, DCOR or even those routers themselves. If NSLP level local repair is desired in the case when UCOR is a PNE, the NSLP needs to maintain a reverse routing state vs. flow id. The PNE noticed a routing change for a given flow id, and knows any NSLP- aware nodes that can handle the route change must be upstream of it. So it looks up the reverse routing state table and notifies its upstream neighbor, and then the upstream neighbor (which may be another PNE) has to repeat the process until an FNE is reached. (What is hard is for the upstream node to know whether or not to forward this notification any further.) 3.4.2. Data Packet Monitoring based UCOR detection These two methods could give some idea of upstream route change, but do not tell exactly where the change is. Also there could be many detection nodes but hard to tell which one is the Action Node. It might be costly to ask each of them to do local repair. But if they indeed do, the process might be similar to that in the next section. 3.4.3. Signaling packet Monitoring based DCOR detection Signaling Packet Monitoring may be used to detect upstream route changes. As mentioned above, this approach requires that the DCOR be signaling aware so these cases correspond to cases A.III, B.III, C.III. In a way similar to that of RSVP, NSLP can identify DCOR by comparing the SII contained in the signaling message. For example, if the "RESERVE" message for the same session is found to have arrived from a node with a different SII, upstream route change is assumed. Hancock et al Expires April 2004 [Page 14] Internet-Draft Routing and Mobility in NSIS October 2003 The main action DCOR needs to take is the removal of orphaned state in the obsolete path. (Only applicable when those routers between UCOR and DCOR cannot delete the state themselves earlier). This also requires the NTLP to support explicit routing based on SII. The DCOR issues a teardown message towards the old peer's SII, this message will be routed peer to peer in the reversed direction along the obsolete segment and tear down any related state inside the segment. This teardown message might also contain some flag indicating it is a local repair teardown to facilitate them being identified by the UCOR. UCOR should terminate the local repair teardown messages when they arrive. 3.5. Other cases There are several cases that the above discussion does not cover, including case A.I,A.II, B.I,B.II, C.I,C.II, when the DCOR is not FNE. In fact, it seems that if the Detection Routers between UCOR and DCOR do not require an explicit state teardown message, these cases will be fine as far as DCOR is concerned. Otherwise, more analysis is needed. 3.6. QoS routing Considerations The above discussion applies to normal routing mechanisms which do not differentiate route selection for signaling packets or data packets. In the presence of QoS routing, it is important to make sure signaling packets and data packets of the same session will select the same route for path-coupled operation. If route pinning is used, the route should be unpinned immediately whenever a route change is detected or notified. Other than that, the process should be similar to that of the above. 3.7. Response to Mobility Caused Session Path Change Mobility caused session path change can be divided into path change with or without change of Flow ID. The case without change of Flow ID usually falls into the Micro-mobility category. The analysis of this case will be provided in a later version of this document. 4. IP Mobility and Multihoming 4.1. Comparison with Route Changes The basic case of route change processing for a single flow can be extended to the more complex situations of IP layer mobility and multihoming. These have several aspects in common with the route change case, specifically: a) the significance of upstream and downstream crossover routers (including how to find them, especially in heterogeneous signaling Hancock et al Expires April 2004 [Page 15] Internet-Draft Routing and Mobility in NSIS October 2003 application environments) b) the possibility that the characteristics of the two path segments may be very different (for example, with different resource availabilities, or even supporting totally different resource negotiation capabilities) c) the possibility that the different paths may traverse different administrative domains, so that authorization status for one path may be inapplicable to the other. However, there are several features of the IP mobility and multihoming situations which lead to additional requirements on the signaling, or suggest that alternative signaling designs may be appropriate. The most important of these are as follows: 1. IP mobility and multihoming introduce a new address for the mobile or multihomed node, and this address will lead to a new flow identification. This new flow identification will (generally) have to be communicated to the correspondent (so it can update transport or application layer state to recognize the new flow), and also to intermediate nodes on the path (so they can update packet classifiers to recognize the new flow). In contrast, in the route change case, it may be possible to hide the signaling entirely between the UCOR and DCOR, especially if path characteristics and authorization properties do not change. 2. The 'new' flow may persist for some time in parallel with the old. This is certainly true in the multihoming case, and can also be case with IP mobility. Indeed, the most important initial usage of IP mobility may be mainly in inter-technology, inter-system scenarios, where the actual 'handover' process takes a long time to complete, and so make-before-break is actually necessary to achieve any form of session continuity. The signaling solution therefore has to manage these two flows 'side-by-side', as compared to the route change case where a very rapid flow path modification is the goal. 3. Conversely, in the IP mobility case, it is also likely that at some stage the 'old' flow involving the old IP address has resources which are to be released, but that the old flow path is not physically available to send signaling messages on (and even that the old IP address is not even valid). This can make explicit teardown of such resources much harder; however, since this includes scarce resources on access links, it may be that long refresh times are in use (to minimize signaling overhead) and so explicit teardown is of additional importance. In the route change case, the UCOR and DCOR are typically reachable even after the route change, at least by some path. 4. Mobility events and multihoming configurations are generally known (and in fact initially only known) to the flow endpoints and cannot be independently detected in the network infrastructure (except in the micro mobility scenarios mentioned in section TBD 3.7). Therefore, crossover router discovery has to be done as a side effect Hancock et al Expires April 2004 [Page 16] Internet-Draft Routing and Mobility in NSIS October 2003 of NSIS signaling exchanges, often end to end ones. Discovery is therefore a more time consuming process, but less vulnerable to the complex case where multiple nodes believe they are the crossover router, which can occur in the route change case with local signaling repair being triggered by direct interactions with the routing process. 5. Finally, the most significant difference is that in the mobility and multihoming case, the network infrastructure is asked to perform joint operations on two different flows which are only associated by their session identifier. However, only the flow endpoints have any reason to accept assertions about the relationship between such flows: the signaling initiator is actually responsible for choosing the session identifier for each flow, and its correspondent will have been updated (somehow, presumably securely) at the transport or application layer. In contrast, nodes within the network have no reason to accept that a new flow is related in any way to the old; we have to prevent the situation that any node in the Internet can send a signaling message into the network with a session identifier which effectively 'steals' resources at any node it crosses which has a flow with a matching session identifier. These and other security issues with the session identifier have been analyzed in more detail in [4]. In the route change case, the flow identifier is constant and flow identifier spoofing is difficult in practice because of the constraints imposed by the routing system. Decoupling the session identification from these constraints is the signaling equivalent of breaking the connection between locators and identifiers, which is well known to lead to a large of number of interesting security issues; an excellent overview of these issues in the context of Mobile IP is provided in [5]. 4.2. Analysis Overview In what follows, we consider the impact of these mobility and multihoming specific considerations on a set of four basic scenarios, similar to the route change analysis of the previous section. The requirements on session identifier behavior are outlined, as well as the implications for overall signaling behavior and consequences for signaling update latency. These 'call flows' can be used as a starting point for deriving requirements on detailed NSIS functionality to support mobile or multihoming operation; some of these are mentioned during the analysis. We consider here only a simplified set of possible scenarios. Specifically, we initially only have four. In what follows we use the term MN for the mobile or multihomed node, and CN for its correspondent. *) There is a choice of whether the session (i.e. the paired flows) is inbound or outbound from the MN; Hancock et al Expires April 2004 [Page 17] Internet-Draft Routing and Mobility in NSIS October 2003 *) There is an independent choice of whether the MN or CN has initiated the signaling. In addition, for each scenario, we consider the cases of setup of the new flow and the teardown of the old (of course, these two could be carried out simultaneously). This is still a highly simplified set of possibilities. Our main restriction is that there is a hop-by-hop authorization procedure, where each node requests resources or other state manipulations from its direct NSIS neighbor, and this request propagates from one end of the flow (the initiator) to the other (the responder). Clearly, more complex authorization scenarios are possible, and this would have a major impact on the analysis. It turns out that the hop-by-hop authorization assumption, while a very natural approach (and possibly the only one which is operationally feasible), has a strong influence on what exchanges are necessary and restricts how much these can be optimized. Further discussion of the NSIS authorization problem, specifically in the case of QoS, is contained in [6]. In addition to this simplification, we only consider homogeneous signaling environments, where the single signaling application is supported on all the nodes we care about (i.e. every node considered below is an FNE, including MN and CN). Also, for this mobility analysis, we have not attempted to distinguish precisely between NSLP and NTLP functionality, except in separating the concept of setting up reverse path state and installing signaling application state (the former being basic NTLP functionality and the latter being the role of the NSLP, along with authorization aspects). In the teardown case, it is still somewhat open whether a tear can propagate in the opposite direction to the original state setup. This would correspond to a node removing state which it did not install, and therefore might not be consistent with a strict viewpoint on authorization. However, in a soft-state protocol, the same effect can in any case be simulated by having nodes unilaterally reduce their state refresh period to some small time and notify their initiating peer of this fact in case the state still needs to be retained for some reason. We call this process 'accelerated expiration'. (If this whole discussion seems absurdly finicky, simply replace the phrase 'accelerated expiration' by 'teardown by the responder'.) One of the main goals of this signaling is to avoid double reservations on the shared path segment. Influenced by the QoS use case, we refer to this as 'state sharing' (e.g. a resource reservation can be used by packets for either flow). In reality, the correct processing depends on the specifics of the signaling application, for which the concept of sharing might not even apply, but some form of merging or joint processing still would. Hancock et al Expires April 2004 [Page 18] Internet-Draft Routing and Mobility in NSIS October 2003 4.3. MN-Terminating Session In the case where the session is terminating at the MN, we have the situation shown diagrammatically in Figure 8. +--+ +---+ new flow new |MN|<<<<<<<<<<|NAR|<<<<<<<<<<<<<^ address +--+ +---+ ^ ^ +----+ +--+ | |UCOR|<<<<<<<<<<|CN| | | |<<<<<<<<<<| | | +----+ +--+ | +--+ +---+ V shared original |MN|<<<<<<<<<<|OAR|<<<<<<<<<<<< + add-IP (end to end) | | <-----<-----<------<------<------<------<------- | Flow NSIS setup (hop by hop) | Setup (discovers UCOR) | | <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< + Traffic -----------------------------------------------> + delete-IP | Flow | Tear <-----<-----<------<------<------<------<------- | (1) NSIS teardown + ------>----->------>------>------>------>------> + NSIS teardown & delete-IP | (accelerated expiration) | | Flow <------<------<------- | Tear NSIS teardown on old | (2) segment if upstream | message was sent via NAR + Figure 9: CN(Sender)-Initiated MN-Terminating Flows Session Identifier Security Considerations: In this particular case, there are no interesting requirements on the session identifier. This is because all signaling state modification requests are either 'fresh' (and so no optimizations were possible with it anyway), or because the requests come from the same peers as the state was originally installed by, and the initial request comes from the initiator itself. (It will be seen that all the other cases are rather more complex.) 4.3.2. MN (Receiver) Initiated Setup and Teardown The receiver initiated case is more complex than the sender initiated case, for both setup and teardown. For the setup case, the process begins the same as with sender initiation, with an end-to-end add-IP message. Even though the CN is not controlling the overall signaling process, its NSIS function must still be triggered by this to send a downstream NSIS message whose sole purpose is to discover the UCOR and set up reverse routing state on the new path. In principal this should be no different from what was needed to set up reverse routing state for the original flow; however, the NSIS message needs to include the same signaling Hancock et al Expires April 2004 [Page 21] Internet-Draft Routing and Mobility in NSIS October 2003 application identifier and session identifier as used for the signaling for the original flow. This may have some implications for how the session identifier values are managed. There are then two cases for how the actual state installation should take place. This has to be done by signaling messages flowing in the MN-CN direction. 1. The downstream message goes all the way to the MN on the new path; this is followed by a setup message in the upstream direction. This is processed normally on the new path segment, and once it reaches the UCOR state merging can take place on the shared segment. 2. The downstream message reaches the UCOR, and this is immediately able to begin state merging on the shared segment. In the meantime, the downstream message continues to the MN and causes state setup on the new path segment (but this only needs to carry on up to the UCOR). These two options are illustrated in Figure 10. There are different options for when traffic can be sent from the CN, depending on whether the CN waits to see that state has been installed before using the new path. In particular, if the CN wants a guarantee that state has been installed end to end, the timing optimization of option (2) is not actually exploited in reality. The two options differ in what requirements are placed on the session identifier so far as implied authorization is concerned, and these are discussed at the end of this subsection. Hancock et al Expires April 2004 [Page 22] Internet-Draft Routing and Mobility in NSIS October 2003 MN UCOR CN -----------------------------------------------> + add-IP (end to end) | | <-----<-----<------<------<------<------<------- | NSIS path state setup (hop by hop) | <<<<<<<<<<<<<<<<<< | Traffic start | (optimistic CN) | Flow | Setup ------>----->------>------>------>------>------> | (1) NSIS signaling state setup | (or sharing from UCOR to CN) | <<<<<<<<<<<<<<<<<< | Traffic start | (pessimistic CN) | + -----------------------------------------------> + add-IP (end to end) | | <-----<-----<------<------<------<------<------- | . NSIS path state setup (hop by hop) | . . <<<<<<<<<<<<<<<<<< | . . Traffic start | . . (optimistic CN) | . . | . .------>------>------> | . NSIS shared state | Flow . setup from UCOR | Setup . <<<<<<<<<<<<<<<<<< | (2) . Traffic start | . (fairly optimistic CN) | . | .----->----->------>------. | NSIS new state setup .------>------>------> | from MN to UCOR Notification of | setup complete | (optional) | <<<<<<<<<<<<<<<<<< | Traffic start | (pessimistic CN) + Figure 10: MN(Receiver)-Initiated MN Terminating Flows (Setup cases) The teardown case can be handled in two ways also. If the route via the OAR is still available (directly or via the NAR), the MN can send an upstream hop-by-hop NSIS message which removes state on the old path and can carry delete-IP as a payload. If the route is unavailable, this message has to be sent upstream using the reverse path state of the new flow; from the UCOR to the CN it is handled as Hancock et al Expires April 2004 [Page 23] Internet-Draft Routing and Mobility in NSIS October 2003 normal, and at the UCOR it is turned round and used to remove the old path state via accelerated expiration. The same possibilities for a race condition exist as in the CN(sender) initiated case. These sequences are shown in Figure 11. MN UCOR CN + ------>----->------>------>------>------>------> | Flow NSIS teardown & delete-IP | Tear | (1) + + -------------------------->------>------>------> | NSIS teardown & delete-IP | | <------<------<------- | Flow NSIS teardown on old | Tear segment if upstream | (2) message was sent via NAR | (accelerated expiration) | + Figure 11: MN(Receiver)-Initiated MN Terminating Flows (Teardown cases) Session Identifier Security Considerations: For this receiver initiated case, we have two security issues for the session identifier, and which ones are relevant depends on which setup message sequence is used. *) The 'Different Peer' Issue: When the UCOR sets up the sharing of signaling state for the two flows on the path back to the CN, it is essentially saying: "the state which I previously installed on behalf of my downstream peer on the old path [e.g. maybe the OAR] can now also be used on behalf of my downstream peer on the new path [e.g. maybe the NAR]". In other words, the UCOR has to reason that the two downstream peers (who could be in different administrative domains and may have no knowledge of each other) are happy to have their independent requests for upstream state use shared resources solely on the basis that the session identifiers match, and hence (presumably) that they originated with the same MN. A legalistic downstream peer on the old path might claim that the resources it had reserved and paid for on the shared segment had just been been stolen. This assumption is needed for both setup cases. *) The 'Indirect Initiator' Issue: In addition, when the 'speeded up' setup approach (case 1) is used, where the UCOR begins to install state sharing on the upstream path as soon as it has seen the downstream path state message with an existing session identifier for a new flow, the UCOR is doing this without having received any signaling message originating (directly or indirectly) from the MN Hancock et al Expires April 2004 [Page 24] Internet-Draft Routing and Mobility in NSIS October 2003 which actually initiated the signaling. In other words, the UCOR is saying "I believe that the new flow I am being told about for this session identifier is one which is for the same MN as the existing flow, and I therefore believe that MN will be happy for state to be shared between the two flows". If the UCOR is only willing to proceed after verifying this information by a signaling exchange which involves the MN itself, this reduces to the simpler case 1 setup approach, i.e. with no latency saving. Note that no additional considerations apply from the teardown case, because either signaling comes from the MN like a normal teardown or accelerated expiration is used. 4.4. MN-Originating Session In the case where the session is originating at the MN, we have the situation shown diagrammatically in Figure 12. +--+ +---+ new flow new |MN|>>>>>>>>>>|NAR|>>>>>>>>>>>>>V address +--+ +---+ V ^ +----+ +--+ | |DCOR|>>>>>>>>>>|CN| | | |>>>>>>>>>>| | | +----+ +--+ | +--+ +---+ ^ shared original |MN|>>>>>>>>>>|OAR|>>>>>>>>>>>>>^ segment address +--+ +---+ original flow MN acts as UCOR Figure 12: Session from MN to CN The general treatment of the MN originating session is simpler than the MN terminating case, because the node which has moved can also directly generate the signaling which discovers the COR - there is no need to involve the CN in this process. However, we still expect there to be an end to end add-IP message, if only to inform the CN of the new address (without which traffic sent from this new address will probably be ignored or filtered). This message can be sent as soon as the new IP address is active, and traffic can be sent as soon as the add-IP procedure is complete. The remaining discussion differs between the MN- and CN-initiated cases. 4.4.1. MN (Sender) Initiated Setup and Teardown The setup case is relatively simple here. The MN originates an NSIS signaling state setup message for the new flow with the same session identifier as for the existing flow (which it chose anyway). This has to be sent on the new path (via the NAR) and state is set up from Hancock et al Expires April 2004 [Page 25] Internet-Draft Routing and Mobility in NSIS October 2003 the MN to DCOR in the normal way. The DCOR can be identified when it processes this message, and the remainder of the state is set up shared with the existing flow from the DCOR to the CN. For the teardown case, no delete-IP message is strictly needed (the MN just stops using the old address when it feels like it). If the NSIS teardown message can be sent using the old path (via the OAR), state teardown is done in the usual way (once the state for the new flow has been set up, i.e. to avoid losing the state completely on the shared segment). If only the new path is available, the message has to be sent via the DCOR and use accelerated expiration on the upstream segment from the DCOR towards the OAR. This is basically the same set of possibilities as for receiver-initiated MN-terminating flows (which is reasonable, since in each case it is the MN which is managing the signaling process). All these message sequences are shown in Figure 13. MN DCOR CN + ------>----->------>------>------>------>------> | NSIS path state setup (hop by hop) | Flow (possibly including add-IP as payload) | Setup | >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> | Traffic start | + + ------>----->------>------>------>------>------> | Flow NSIS teardown & delete-IP | Tear | (1) + -------------------------->------>------>------> + NSIS teardown & delete-IP | | <------<------<------- | Flow NSIS teardown on old | Tear segment if upstream | (2) message was sent via NAR | (accelerated expiration) | + Figure 13: MN(Receiver)-Initiated MN Terminating Flows Session Identifier Security Considerations: The 'Different Peer' security issue applies to state sharing on the shared path segment identically as in the other MN initiated case. However, since all state manipulation messages originate at the MN, the 'Indirect Initiator' issue does not arise. Hancock et al Expires April 2004 [Page 26] Internet-Draft Routing and Mobility in NSIS October 2003 4.4.2. CN (Receiver) Initiated Setup and Teardown The setup case here has to install reverse path state to allow the signaling state manipulation messages to propagate upstream from the CN. Note that the reverse path state is being installed for the new flow, and at the DCOR this will be different from the reverse path state for the existing flow for that session. Therefore, the reverse path state must be indexed by the flow identification, rather than the session identification. Once reverse path state has been installed, signaling state installation can be done by two methods, similar to the other receiver initiated case. The difference is that the 'early' setup can take place on the new path segment rather than on the shared path segment. Teardown is quite simple in this case. A delete-IP message is needed to inform the CN that the old flow is no longer active; however, once this has been received, the teardown can be initiated from the CN with normal signaling (the necessary reverse path state already exists to route this signaling). All these signaling exchanges are shown in Figure 14 below. Hancock et al Expires April 2004 [Page 27] Internet-Draft Routing and Mobility in NSIS October 2003 MN DCOR CN ------>----->------>------>------>------>------> + NSIS path state setup (hop by hop) | (including add-IP as payload) | >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> | Traffic start (optimistic MN) | | Flow <-----<-----<------<------<------<------<------- | Setup NSIS signaling state setup | (1) (or sharing from DCOR to CN) | >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> | Traffic start (pessimistic MN) | + + ------>----->------>------>------>------>------> | NSIS path state setup (hop by hop) . | (including add-IP as payload) . | >>>>>>>>>>>>>>>>>> . . | Traffic start . . | (optimistic MN) . . | . . | <-----<-----<------<------. . | NSIS new state setup . | Flow from DCOR to MN . | Setup >>>>>>>>>>>>>>>>>> . | (2) Traffic start .------<------<------. | fairly optimistic MN) . NSIS shared state | . setup to DCOR | . | <-----<-----<------<------. | Notification of | setup complete | (optional) | >>>>>>>>>>>>>>>>>> | Traffic start (pessimistic MN) | + + -----------------------------------------------> | delete-IP | Flow | Tear <-----<-----<------<------<------<------<------- | NSIS teardown | + Figure 14: CN(Receiver)-Initiated CN Terminating Flows Session Identifier Security Considerations: In this case, the shared path segment has both flows initiated by the same endpoint. Therefore, the 'Different Peer' issue does not arise. However, the 'Indirect Initiator' issue arises in the second flow setup case, where the DCOR attempts to install state on the new path segment Hancock et al Expires April 2004 [Page 28] Internet-Draft Routing and Mobility in NSIS October 2003 before any signaling messages have arrived from the CN. As before, any confirmation exchange between the CN and DCOR reduces this case to the simpler setup exchange. 4.5. Summary of the Analysis The most significant conclusion of the analysis is that the interaction with the authorisation model has extremely important impacts on the message flows. In many cases, the information needed to complete the mobility processing (updates on the shared path or installation/teardown on the new and old segments) is available at the crossover router quite early in the message exchange, but the crossover router may be unable to use it because it comes from an unknown neighbour or from the 'wrong direction'. This is therefore an authorisation issue. Authorisation interactions are sometimes considered as an 'add-on' during design, especially if some sophisticated special purpose authorisation protocol is being used. However, even the filtering that is done on messages to ensure they come from an appropriate source can be considered as an authorisation issue; ignoring these issues when designing the basic message flows is liable to mean that the protocol design ends up being fundemantally incapable of being secured against theft-of-service attacks and other abuses. Because the authorisation constraints arise from the hop-by-hop authorisation assumption, it might be that a more flexible or powerful authorisation model would make mobility handling much easier. For example, if the signaling initiator had a direct authorisation relationship with the COR, most of these problems would be eliminated. However, the consequence of routing is that in general the COR can be anywhere in the network, and the precise location of the COR depends on what handover has taken place and the flow direction. Therefore, in general, to have a prior authorisation relationship with the COR means in practice that the signaling initiator must have this relationship with every NSIS node along the flow path; this is likely to be operationally infeasible. Two different session id security issues were identified, the 'Different Peer' and 'Indirect Initiator' issues. The applicability of these issues is shown in the following table (which has some pleasing structural symmetries). Hancock et al Expires April 2004 [Page 29] Internet-Draft Routing and Mobility in NSIS October 2003 Table 1: Applicability of Session Id Issues to Various Scenarios +--------------+------------+----------------+----------------+ | Mobile | Sender or | Different Peer | Indirect | | originating | receiver | issue | Initiator | | or | initiated? | | issue | | terminating? | | | | +--------------+------------+----------------+----------------+ | Terminating | Sender | N/A | N/A | | (inbound) | | | | +--------------+------------+----------------+----------------+ | Terminating | Receiver | Applies to | Applies only | | (inbound) | | resource | if accelerated | | | | sharing on | setup on | | | | shared segment | shared segment | | | | | is done from | | | | | UCOR | +--------------+------------+----------------+----------------+ | Originating | Sender | Applies to | N/A | | | | resource | | | | | sharing on | | | | | shared segment | | +--------------+------------+----------------+----------------+ | Originating | Receiver | N/A | Applies only | | | | | if accelerated | | | | | setup on new | | | | | segment is | | | | | done from DCOR | +--------------+------------+----------------+----------------+ The indirect initiator issue applies in 50% of the cases, but only if speedup up state installation is needed from the COR. This case needs to be analysed from two perspectives: *) Whether the speedup is actually valuable. Clearly, in some cases (e.g. multihoming) it is probably not; on the other hand, if one is attempting to achieve a seamless hard IP handover, every speedup is valuable. Techniques such as those in [Thomas] could be used to model whether signalling is on the critical time path in the overall setup process. *) Whether the threat is real, and what form of session identifier protection mitigates it best. The different peer issue also applies in 50% of the cases, but is unavoidable in those cases. Whether it is a problem depends again on finer details of the authorisation model. For example, one approach would be for the second flow on the shared segment to be given a lower priority (if this concept is applicable to the signalling application in use); this prevents it from stealing resources from the first flow, only using resources that the first flow is not using. In slow time, the new peer would take over the session completely (e.g. after the first flow is deleted). This would be perfectly applicable for QoS signalling for example, but might be Hancock et al Expires April 2004 [Page 30] Internet-Draft Routing and Mobility in NSIS October 2003 very dangerous for middlebox control. The analysis also exposes some interesting protocol interactions in the end system, especially concerning how and when addresses are allocated and released and used for traffic, and how and when session identifiers are allocated and coordinated. Race conditions could be commonplace and additional end-to-end or end-to-COR acknowledgements might be needed to handle them. This requires further call flow analysis, but can probably only be completed once the allocation of mobility functionality to different layers of the NSIS protocol stack has been defined in more detail. A topic that has not yet been considered is the use of network internal mobility proxies (e.g. as are used in several local mobility management schemes). These have several properties which are very relevant to the issues analysed here, in particular: *) they may be able to hide the end system address change (making it look more like a routing change); *) they may provide a fixed internal node which will always be the COR for a local mobility event, or at least allow the COR to be pre- authorisation between the MN and proxy, which could address both of the session id security issues (especially the indirect initiator one). Further analysis of such LMM solutions is needed to determine whether there is a common signalling approach to each of them, and whether signalling interactions with them can be constrained inside the network or whether it would require different behaviour in MN or (even worse) CN to exploit them. 4.6. Further Interactions with Fast Handover Protocols In the context of mobility between different access routers, it is common to consider additional local performance optimizations in two areas: selection of the best access router to handover to, and transfer of state information between the access routers to avoid having to regenerate it in the new access router after handover. The Seamoby working group is developing protocols solutions for these functions (CARD and CT respectively) but the following considerations apply to these functions in general, regardless of which particular protocol is used to implement them. Detailed solutions are not proposed here, but rather a discussion of the way in which these functions should interact with NSIS signaling. In addition, signaling should be able to operate independently of these protocols (and this is the assumption for the main mobility analysis earlier in this document). However, significant performance gains could be achieved if they could be made to cooperate. In addition, the resource signaling aspects of these CARD/CT and NSIS protocols could profitably use a common set of resource types and definitions, since they will probably be supporting the same overall Hancock et al Expires April 2004 [Page 31] Internet-Draft Routing and Mobility in NSIS October 2003 signaling application. The question arises, what the mode of interaction should be: independent operation, NSIS triggering access router discovery and state transfer, or vice versa. The questions for the two cases seem to be independent. For access router discovery, a typical model of operation is that the mobile carries out an information gathering exercise about a range of capabilities. In addition, where those capabilities relate purely to the AR and mobile, there is no role for NSIS (its special functionality is not relevant). However, considering resource aspects, one aspect of the AR 'capability' is resource availability on the path between it and the correspondent, and NSIS should be able to fulfill this part. Indeed, this is effectively precisely the application considered in [7], where it is a sort of special case of resource signaling during handover. This means that CARD should be able to trigger some of the NSIS signalling, maybe discovering COR location and checking admission control status on the new path, before the handover has actually taken place. Therefore, a possible model of access router discovery/NSIS relationship is that some entity in a candidate AR triggers NSIS using resource and reservation information (including session id) from the current AR to find out about what would be available on the new path. Note that this should be a query rather than an actual state setup; this semantic could be included either in the service definition or the signalling itself. The case of state transfer is more complex. There are two obvious options, corresponding to whether one transfers just signaling application state or NSIS protocol state as well: 1. "State transfer triggering NSIS": A state transfer process passes the to request that resource. 2. "NSIS using state transfer": NSIS transfers its own state information from the old to the new AR. It can then carry out the same update signaling as though it was a single 'virtual AR' which had just had a topology change towards the correspondent. (This is essentially the conceptual model of [8].) The first model is simpler, and maybe more in line with the basic state transfer expectation; however, it seems hard to avoid double reservations since the two NSIS protocol instances are not coordinated (if we regard the session identifier as part of NSIS protocol state rather than signaling application state). In addition, NSIS protocol state may itself be time consuming to set up (for example, if it requires peer-peer authentication before actual signaling messages can be transferred.) Therefore, the second model seems more appropriate. An advantage of the 'virtual AR' model is that it ensures that the impact of the interaction is limited to the NSIS instances at ARs themselves, since the rest of the network must be able to handle a topology change anyway: the scenario looks more Hancock et al Expires April 2004 [Page 32] Internet-Draft Routing and Mobility in NSIS October 2003 like a route change with an IP address change rather than a full mobility event. Note that there is an open issue of who is responsible between the mobile and AR to decide that the state transfer procedures have not happened for whatever reason - e.g. because they were not even implemented - and take recovery action to have the mobile refresh reservations promptly. It appears this has to be an NSIS responsibility in the AR, and probably requires a custom notification message for this circumstance. 5. Security Considerations This draft discusses signaling flows to handle route change and mobility events and multihoming scenarios. Many security considerations apply to such signaling flows; in particular, all the issues of message protection, denial of service protection, theft and abuse of service, authorisation and so on that apply to the 'normal' signaling case continue to apply here also. Some special considerations arise from the route change/mobility issues discussed in this draft. In particular, authorisation for path change (for flows) and more particularly for flow change (for sessions) needs to be considered carefully. The latter is extensively discussed in section 4, and section 4.5 in particular. A second special issue is the need to do rapid signaling exchanges during or after handovers. This is not a security issue itself, but it does impose new performance constraints on the security mechanisms that are used to protect signaling in general. Specifically, in the case of a MN attaching to a new AR, the need for time consuming node authentication procedures before signaling information can be exchanged should be minimised; this might be a motivation for context transfer of such authentication state. It appears that there are few or no new basic denial of service attacks that arise in these scenarios (or rather, any attack that could be mounted in these scenarios could also be mounted in the normal case). Instead, the new problem is that signaling flows which might have been seen as denial of service attacks in the normal case (such as signaling messages for a flow arriving from a previously unknown peer) now have to be treated as potentially legitimate and secured by other means. Once the functionality described in this document has been allocated to specific components in the NSIS protocol suite, a more complete security analysis of the overall protocol behaviours will be required. In the meantime, consideration of the scenarios described here may be helpful in refining the view of what are the realistic security goals for NSIS signaling as a whole. Hancock et al Expires April 2004 [Page 33] Internet-Draft Routing and Mobility in NSIS October 2003 6. Contributors This draft initially written by Robert Hancock, Jukka Manner, and Charles Q. Shen. 7. Acknowledgments Acknowledgments go to Xiaoming Fu, Eleanor Hepworth, Cornelia Kappler, Georgios Karagiannis, Andrew McDonald, Henning Schulzrinne, Hannes Tschofenig. 8. Informative References [1] R. Hancock, et al., "Next Steps in Signaling: Framework". Internet Draft (work in progress), draft-ietf-nsis-fw-04 [2] H. Schulzrinne, "CASP - Cross-Application Signaling Protocol". Internet Draft (work in progress), draft-schulzrinne-nsis-casp-01 [3] S. van den Bosch, et al., "NSLP for Quality-of-Service Signaling". Internet Draft (work in progress), draft-ietf-nsis-qos- nslp-00 [4] H. Tschofenig, et al., "Security Implications of the Session Identifier". Internet Draft (work in progress), draft-tschofenig- nsis-sid-00 [5] P. Nikander, et al., "Mobile IP version 6 Route Optimization Security Design Background". Internet Draft (work in progress), draft-nikander-mobileip-v6-ro-sec-01 [6] H. Tschofenig, et al., "QoS NSLP Authorization Issues". Internet Draft (work in progress), draft-tschofenig-nsis-qos-authz-issues-00 [7] X. Fu, et al., "QoS-Conditionalized Binding Update in Mobile IPv6". Internet Draft (work in progress), draft-tkn-nsis-qosbinding- mipv6-00 [8] M. Thomas, "Analysis of Mobile IP and RSVP Interactions". Internet Draft (work in progress), draft-thomas-nsis-rsvp-analysis-00 9. Author's Addresses Questions about this document may be directed to: Robert Hancock Roke Manor Research Ltd Romsey, Hants, SO51 0ZN United Kingdom Voice: +44-1794-833601 Hancock et al Expires April 2004 [Page 34] Internet-Draft Routing and Mobility in NSIS October 2003 Fax: +44-1794-833434 E-Mail: robert.hancock@roke.co.uk Jukka Manner Department of Computer Science University of Helsinki P.O. Box 26 (Teollisuuskatu 23) FIN-00014 HELSINKI Finland Voice: +358-9-191-44210 Fax: +358-9-191-44441 E-Mail: jmanner@cs.helsinki.fi Charles Q. Shen Department of Electrical Engineering Columbia University 500 West 120th Street New York, NY 10027 USA Voice: +1-212-854-5599 Fax: +1-212-932-9421 E-Mail: charles@ee.columbia.edu Hancock et al Expires April 2004 [Page 35] Internet-Draft Routing and Mobility in NSIS October 2003 Full Copyright Statement Copyright (C) The Internet Society (2003). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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. Hancock et al Expires April 2004 [Page 36]