Internet Engineering Task Force Roland Bless Internet-Draft Xiaoming Fu Expires: July, 2004 Robert Hancock Seong-Ho Jeong Cornelia Kappler Sung-Hyuck Lee Jukka Manner, Ed. Paulo Mendes Hannes Tschofenig January, 2004 Mobility and Internet Signaling Protocols 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. Copyright Notice Copyright (C) The Internet Society (2004). All Rights Reserved. Abstract IP mobility, which in its simplest form includes routing changes, can have major influence e.g. on the protocols designed within the NSIS Working Group. This draft is a first step in helping us to decide on how the problems caused by mobility should be handled within Internet signaling protocols, and a stimulus to further security work. Manyfolks et al Expires July 2004 [Page 1] Internet-Draft Mobility and Internet Signaling January 2004 Table of Contents 1 Introduction ................................................. 3 2 Terminology .................................................. 4 3 Framework .................................................... 6 3.1.1 Global Mobility .......................................... 7 3.1.2 Other Global Mobility Approaches ......................... 8 3.1.3 Global Mobility Procedures ............................... 8 3.2 Local Mobility Management .................................. 9 3.3 Context Transfer and Candidate Access Router Discovery ..... 9 3.4 Examples of handovers ...................................... 10 3.5 Short Problem Statement .................................... 13 4 Cross-over Node Discovery and Path Update .................... 14 4.1 Background ................................................. 14 4.2 Crossover Node Discovery ................................... 15 4.2.1 Types of Crossover Node .................................. 15 4.2.2 Determination of Crossover Node .......................... 16 4.3 Path update ................................................ 19 4.3.1 State Setup and Update ................................... 19 4.3.2 State Teardown ........................................... 20 4.4 Effect of generic routing changes .......................... 21 4.4.1 CRN discovery ............................................ 21 4.4.2 Path Update .............................................. 22 4.5 Open Issues ................................................ 22 5 Dead Peer Discovery (DPD) .................................... 23 5.1 Overview ................................................... 23 5.2 Failure Cases and Impact of Dead Peers ..................... 23 5.2.1 Failure Cases ............................................ 23 5.2.2 Impact of Dead Peers ..................................... 24 5.3 DPD procedures in NTLP ..................................... 25 6 Case Examples ................................................ 26 6.1 NSIS in the hard-handover case ............................. 26 6.1.1 Signaling on the Unchanged Path .......................... 28 6.1.2 Signaling on the New Path ................................ 28 6.1.3 Signaling on the Old Path ................................ 28 6.1.4 Interaction between NTLP and NSLP Signaling .............. 29 6.1.5 Routing of NTLP messages ................................. 29 6.2 Example of Signaling of an Anticipated Handover ............ 31 7 Multihoming-related Issues ................................... 32 8 Interactions with Mobility Signaling ......................... 32 8.1 Mobility Management Protocols .............................. 32 8.2 Interactions with Seamoby Protocols ........................ 35 9 Additional issues ............................................ 36 9.1 Both End-Hosts are Mobile .................................. 36 9.2 Uni- and Bi-directional State Establishment ................ 37 9.3 State Management ........................................... 37 9.4 State establishment in Network Mobility .................... 38 10 Guidelines for Designers of new NSLPs ....................... 39 11 Summary of Split of functionality ........................... 40 12 Security Considerations ..................................... 40 12.1 MN as data sender ......................................... 40 12.1.1 MN is authorizing entity ................................ 41 12.1.2 CN is authorizing entity ................................ 43 12.1.3 MN and CN are authorized ................................ 46 Manyfolks et al Expires July 2004 [Page 2] Internet-Draft Mobility and Internet Signaling January 2004 12.2 CN as data sender ......................................... 46 12.2.1 CN is authorizing entity ................................ 47 12.2.2 MN is authorizing entity ................................ 48 12.3 Multi-homing Scenarios .................................... 48 12.3.1 MN as data sender ....................................... 48 12.3.2 CN as data sender ....................................... 49 12.4 Context Transfer .......................................... 49 12.5 Proxy Scenario ............................................ 50 12.6 Implications for the costs of a QoS reservation ........... 51 12.6.1 Missing Cost Control .................................... 51 12.6.2 Implications for Price Determination .................... 52 12.7 Conclusion ................................................ 52 13 Contributors ................................................ 54 14 Acknowledgments ............................................. 54 15 Informative References ...................................... 54 16 Author's Addresses .......................................... 56 1. Introduction The mobility of IP-based nodes incurs route change, usually at edge of the network. Route change may also be caused by reasons other than mobility, such as routing protocol adaptation in response to varying network conditions, or host multihoming. Normal IP mobility (i.e., Macro-mobility) also involves change of mobile node IP addresses. Since IP addresses are usually part of flow identifiers, change of IP addresses implies change of flow identifier. Micro mobility usually does not cause change of the global IP addresses, but affects the routing paths within the local access network. 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. This draft addresses mobility-related considerations for NSIS. The goals of this draft are to analyze the effects of mobility on the NSIS Transport Layer Protocol (NTLP) and on the NSIS Signaling Layer Protocol (NSLP), and to make sure there are no initial design mistakes that break the protocols in mobile environments. The NTLP is an application independent protocol to transport service-related information between nodes in a network. Each specific service has its own NSLP protocol. The goals of this draft are not to suggest a design for a separate mobility-specific NSIS protocol or to intentionally delay the current work. We expect that this study will actually speed-up the current work on the NSIS protocols. We do not intend to present specific implementation issues in this document, but rather propose how the NSIS protocols should be designed to work in a mobile environment. Manyfolks et al Expires July 2004 [Page 3] Internet-Draft Mobility and Internet Signaling January 2004 A further goal of this draft is to give guidance to people proposing new NSLP protocols. The guidelines in this draft would help those people make sure their NSLP protocols truly work in wired and wireless/mobile environments. Moreover, a goal is to stimulate further discussions related to the security and authentication issues in a mobile environment making use of the NSIS protocols. We expect there to be a common (minimal) set of functions that the NTLP and NSLP need to support. Furthermore, we intend to capture any additional issues that would need specific precautions, e.g. in future NSLPs. The discussion is divided into two parts. The first part discusses the very basic functionality needed within the NTLP and NSLP protocols. We expect these features to be from most parts already available within the NSIS protocols, or at least can be added with little effort. The second part takes the discussions to more specific scenarios, including support for multihoming and inter-working issues with a number of mobility-related protocols. These functions would be looked at once the first versions of the NSIS protocols are finished. 2. Terminology For terminology related to wireless and mobile networking, we refer to [Seamoby-terms]. Session A single application layer flow of information between end points that occur during the span of a single connection for which some network control state information is to be manipulated or monitored. IP mobility may cause the mapping between sessions and flows to change, and IP multihoming may mean there is more than one flow for a given session. Session Identifier The identifier used to relate signaling messages to a specific session. Flow A sequence of packets sent from a particular source to a particular (unicast or multicast) destination for which special handling is provided by the combination of header fields. Only unicast, unidirectional flows are considered in this document. Flow Identifier The identifier used to uniquely identify a particular data flow for which the specific service is requested from the network. All packets associated with the same flow will be assigned the same Manyfolks et al Expires July 2004 [Page 4] Internet-Draft Mobility and Internet Signaling January 2004 flow identifier by the source. The flow identifier contains information about the flow which should receive a particular treatment, and it may consist of a combination of the typical 5-tuple or, for example, source IP address, destination IP address, and flow label in IPv6-based networks. See [I-D.ietf-n sis-fw] for more information. Crossover Node (CRN) A Crossover Node is a node that for a given function is a merging point of two or more separate sets of state information, and not only a physical route splitting point. In the context of this draft, we can distinguish several logical (but not necessarily physically) different CRNs: NTLP CRN, after a routing change, the node closest to the end host from which the NTLP state information towards the CN does not change. NSLP CRN, after a routing change, the node closest to the end host from which the NSLP state information towards the CN does not change. The NSLP CRN may be different for different NSLPs. NSIS CRN, either an NTLP CRN or an NSLP CRN. Upstream CRN, after a handover, the node closest to the data receiver from which the state information towards the data sender does not change. Downstream CRN, after a handover, the node closest to the data sender from which the state information towards the data receiver does not change. Mobility CRN, node at which from the point of view of mobility mgmt old and new paths merge, e.g. MAPs in HMIPv6. Note in general: mobility CRN is may or may not be equal neither to NSLP CRN nor to NTLP CRN. Routing CRN, node at which, using normal routing, old and new paths merge. In case of HMIP, mobility CRN is also routing CRN. However, in case of "normal" MIP with optimized routing, mobility mgmt doesn't know a CRN, whereas routing does. Depending on the location of nodes, the routing CRN may or may not be equal to the NSLP CRN or to NTLP CRN. Path Update The procedure for the re-establishment of NSIS state on the new path, the teardown of NSIS state on the old path, and the update of NSIS state on the common path due to route change or mobility. This is used to improve mobility handling for the affected flows. Upstream Path Update: Path Update for the upstream signaling which is initiated by a signaling initiator on the common path Manyfolks et al Expires July 2004 [Page 5] Internet-Draft Mobility and Internet Signaling January 2004 (e.g., a CN, a HA, or a GFA/MAP). Downstream Path Update: Path Update for downstream signaling which is triggered by a signaling initiator on the new path (e.g., MN, mobile agent, or an AR). Dead Peer Discovery (DPD) The procedure for finding a dead NSIS peer due to a link or node failure and due to a mobile node moving away. Downlink The direction from the CN towards the mobile node. Uplink The direction from the mobile node towards the CN. Receiver The node in the network which is receiving the data packets in a flow. Sender The node in the network which is sending the data packets in a flow. NSIS Transport-Layer Protocol (NTLP) Description... NSIS Signaling-Layer Protocol (NSLP) Description Downstream direction Direction from a data source to the destination. Upstream direction Direction from data destination towards its source. 3. Framework This section describes various mobility scenarios for the detailed discussions of mobility issues in NSIS signaling, using basic mobile IP (v4 and v6) handover as a starting point... Our assumptions in this document and the framework are: Manyfolks et al Expires July 2004 [Page 6] Internet-Draft Mobility and Internet Signaling January 2004 Session-ID is used to index state Even if a mobile node has a permanent IP address (its home address), this cannot be used to index state in the network since the home address may not easily be visible to interior nodes. Other types of mobile nodes (e.g. using SIP or other application layer techniques) may not have permanent addresses at all. After a movement it obtains a new CoA, which is the basis for routing its data. If signaling-associated state is indexed based on some temporary data plane information, such as CoA, the state indexed by previous CoAs might be inaccessible for the signaling after most handover procedures. Double state installation in the unchanged path should be avoided. This can only be done by establishing a relationship between the old and the new flow. This is essentially the same problem faced to tear down state in the old path. Routing may be asymmetric IP packets arriving to and leaving the MN may be routed differently. This may be due to the basic triangular routing of MIPv4, or due to the operation of an LMM protocol, or due to asymmetric routing caused by the basic operation of the IP routing protocols themselves. The CN is not a mobile device We may later add text to consider a mobile CN, too. 3.1.1. Global Mobility Each mobile node is always identified by its home address, regardless of its current point of attachment to the Internet. In basic mobile IP, while situated away from its home, a mobile node is also associated with a care-of-address, which provides information about the mobile node's current location. After a mobile node registers its (primary) care-of address with a router on its home link, known as ``home agent'', data packets addressed to the mobile node's home address are routed to its care-of-address using IP-in-IP encapsulation in the home agent (known as "mobile IP tunneling"). A mobile node can also register with the corresponding node, and then data packets addressed to the mobile node's home address are either IP-in-IP encapsulated (in mobile IPv4) or routed using routing header to its care-of-address (in mobile IPv6). Data packets sent by the mobile node to the corresponding node can be either directly routed to the destination's IP address, or routed through the home agent via a reverse tunnel (if reverse tunnel is used). Here, the following characteristics are important for support of NSIS signaling: Manyfolks et al Expires July 2004 [Page 7] Internet-Draft Mobility and Internet Signaling January 2004 3.1.2. Other Global Mobility Approaches Other approaches to provide global mobility work in the same generic way as MIP, but having a globally unique identifier for the MN, and then using an out-of-band signaling mechanism to provide the current location of the MN to the requesting party. For example, approaches based on DNS updates provide the globally unique DNS name, and the an up-to-date physical location of the MN. Another example is SIP, where users have globally unique identifiers, e.g. names, and the system is able to provide to the caller the current physical location of the called party. 3.1.3. Global Mobility Procedures 1) A flow associated with a mobile node, either sent or received by the mobile node, may continue to desire signaling services after a mobile IP handover. NSIS needs to be able to signal for such flows upon a mobile node's movements. 2) Either the sender or the receiver of a mobile node's flow can initialize an NSIS signaling. It is essential to require the NSIS signaling initiator to be authorized to initialize the signaling. Note that nodes within the network may also initiate NSIS signaling for the given session, for example, to handle route changes in the middle of the network, or to support seamless handovers. 3) The paths for a mobile node's outgoing traffic to the corresponding node and incoming traffic from the corresponding node may differ from each other. 4) Data traffic, in either direction between a mobile node and the corresponding node, can be routed directly, routed indirectly using a routing header, or IP-in-IP encapsulated, or the combination of them in different segments of the data transmission, depending on the mobility mode (route optimization or triangle routing; use reverse tunneling or not; mobile IPv4 or IPv6; whether LMM is used; etc.). 5) A mobile node's handover can be either intra-domain (inside one access network domain) or inter-domain (from one access network domain to another), which mainly concerns with topology information exchange, authorization and accounting issues. This is elaborated in Section 10.7 in [nsis-req]. 6) A mobile node can support multiple care-of-addresses at one time, if it is connected to multiple access networks simultaneously. Although only one primary care-of-address will be used for routing traffic from the corresponding node to the mobile node, this multi-homing feature potentially can be used to enhance the NSIS signaling performance. Manyfolks et al Expires July 2004 [Page 8] Internet-Draft Mobility and Internet Signaling January 2004 3.2. Local Mobility Management Localized mobility management [lmm] mechanisms reduces the latency in mobility management signaling upon Care of Address change. These schemes, such as fast handover [fmip] and hierarchical mobile IPv6 [hmipv6], complicates the features identified in Section 3.1, for example, by associating new scoped care-of-addresses for a mobile node, and introducing one or more IP-in-IP encapsulated segment(s) in the path traversed by the communicating traffic. The additional CoA and IP-in-IP tunnels have implications for both the NTLP and NSLP. For example, NTLP needs to decide to perform tunnel handling when such tunnels exist in the same path that NTLP messages also traverse, while NSLP states may be updated according to the updated CoA in the localized domain. A discussion of these advanced characteristics is detailed in Section 11. 3.3. Context Transfer and Candidate Access Router Discovery The NSIS protocol suite should be able to operate independently of Seamoby protocols such as Context Transfer Protocol (CTP) and Candidate Access Router Discovery (CARD). Significant performance gains can be achieved if NSIS signaling can interact with such protocols. When a mobile node has a choice of Candidate Access Routers (CARs) to perform handover, the Candidate Access Router Discovery (CARD) procedure can be used to identify those CARs along with their capabilities (for instance, QoS resource availability). In NSIS terminology, CARD can be used to find an appropriate NSLP-aware New AR (NAR), and the path leading to the node, where the NSLP state could be installed. The Context Transfer Protocol (CTP) is used to transfer the NSLP state from the Previous AR (PAR) to NAR. When CTP is used, service- aware contexts could be quickly re-established in the NAR without requiring the MN to explicitly perform all protocol flows for those services from scratch. NSLP information, such as QoS state, can be transferred using CTP. However, this also concerns the NTLP because the context transfer for NSLP states takes place between PAR and NAR, which is vertical to the direction of normal NSIS signaling (which is between MN and CN). With the help of CARD and CTP, NSIS signaling can quickly re- establish the NSLP state on the new path by reducing the state re- setup delay. However, making use of the CARD and CT protocols requires the ability from NTLP/NSLP to do (at that stage) off-path signaling on-behalf of the MN; this has implications on the authorization of signaling. Manyfolks et al Expires July 2004 [Page 9] Internet-Draft Mobility and Internet Signaling January 2004 3.4. Examples of handovers The discussions in this document focus on the effects a mobile end host can have on NSIS signaling. The fundamental concern in handover events is how the signaling can be localized in order to minimize the latency of setting up resources on a new path. Here one of the critical issues is the location and operation of a cross-over node. This section seeks to identify the various scenarios that emerge in different types of handovers and network setups. There are several issues that affect how resources are set up in a mobile environment: 1. Is the access router (AR) running a) NTLP, b) NTLP and the NSLP being signaled about, or c) neither of the two protocols? 2. Where are the a) NTLP CRN, b) NSLP CRN, c) mobility CRN, and d) routing CRN? 3. Does the interface at a given CRN routing towards the MN a) change after a handover, or b) remains the same? 4. Are the incoming and outgoing packets from the MN a) routed through the same routing path (symmetric), or b) through different paths (asymmetric routing)? Note here, that the NSLP protocol can not be run without the transport part of the protocol, the NTLP. Figure 3.1 presents possible setups in an access network that supports NTLP and NSLPs. It is assumed that all MNs in this draft are NSLP aware node. To provide examples of the issues mentioned above, consider the following scenarios: - MN is connected to AR 1 and makes a handover to AR2. If incoming packets are arriving through Path A, the NTLP CRN is router a (RTRa) and its interface changes, and the NSLP CRN is RTRb and its interface does not change. If resources are set up for outgoing packets and the outgoing path changes to Path B due to the network routing table, resources must be set up on this new path, and possibly removed on the old Path A. - MN is connected to AR 2 and makes a handover to AR 3. If packets were flowing, and will still continue to flow, on both directions, through Path B, the NTLP and NSLP nodes after the AR do not change, that is, the interface towards the MN at the NTLP and NSLP CRNs does not change. Manyfolks et al Expires July 2004 [Page 10] Internet-Draft Mobility and Internet Signaling January 2004 - MN is connected to AR 8 and makes a handover to AR 7. If data was flowing through Path F before the handover and now flows through Path E, the CRNs are not visible in the figure; RTRj is the first-hop NTLP and NSLP node from the MN and CRNs are somewhere else. If data flows through Path F before and after the handover, there is no NTLP or NSLP CRNs, as RTRm remains the first-hop NTLP and NSLP node. Manyfolks et al Expires July 2004 [Page 11] Internet-Draft Mobility and Internet Signaling January 2004 ------ [MN] |NSLP| | |AR 1|\ | ------ \ ------ ------ | \|NTLP| |NSLP| | /|RTRa| --------|RTRb| ------- Path A --- | ------ / ------ ------ V |NSLP|/ |AR 2|\ ------ \ ------ ------ \------ |NTLP| |NSLP| |RTRc| -- |RTRd| -- |RTRe| -- Path B --- /------ ------ ------ ------ / |NSLP|/ |AR 3|\ ------ \ ------ ------ \|NSLP| ------- |NSLP| /|RTRf| |RTRg| ------- Path C --- ------ / ------ ------ |NTLP|/ |AR 4| ------ Administrative Domain 1 - - - - - - - - - - - - - - - - - - - ------ Administrative Domain 2 |AR 5|\ ------ \ ------ ------ \|NTLP| |NSLP| /|RTRh| ------- |RTRi| ------- Path D --- / ------ ------ ------/ |AR 6| ------\ \ ------ ------ \|NSLP| |NSLP| /|RTRj| ------- |RTRk| ------- Path E --- / ------ ------ ------/ |AR 7| ^ ------\ ------ | \------ |NSLP| | |RTRl| ------- |RTRm| ------- Path F --- | /------ ------ | ------/ | |AR 8| 'AR': Access Router [MN] ------ 'RTRx': Router with id 'x' 'NSLP': Node running NTLP and NSLP 'NTLP': Node running only NTLP Figure 3.1: Examples of network architectures Manyfolks et al Expires July 2004 [Page 12] Internet-Draft Mobility and Internet Signaling January 2004 3.5. Short Problem Statement Based on the discussion in this section, we can highlight some critical issues that need to be solved to allow NSIS protocols to work in a mobile and wireless environment. There are a number of existing signaling protocols [nsis-analysis], however most of them do not support signaling in mobility scenarios, or the support is insufficient. RSVP [RFC2205], for example, relies on flow's fixed source and destination IP addresses, and ports information to identify signaling sessions and how signaling messages are routed. RSVP also lacks an overall consideration of mobile IP features. An NSIS signaling protocol in mobility scenarios needs to consider the following issues: o Change of route and possibly change of MN IP address Topology changes entail the change of routes for data packets sent to or from the mobile node and may lead to a change of host IP addresses. o Latency of route change This change of routing and IP addresses is typically much faster than traditional route change (for example, those due to failure, adding or removal of nodes/links), which makes existing signaling protocols to be either unable to handle or at least create an additional overhead. o Explicit routes Moreover, MIPv6 adds the possibility to define explicit routers, which creates further issues with routing paths. o IP-in-IP encapsulation The possible use of IP-in-IP encapsulation segments in the end-to-end path for routing traffic from the corresponding node to the mobile node (vice versa), associated with a route change of the same mobility behavior, makes signaling in mobility scenarios more complicated. o Localization of state teardown In the case of MN movement, only NSIS state between (former point of attachment of) MN and the NSIS CRN needs to be torn down: The NSIS state between CRN and CN may have to be updated e.g. to reflect a new Flow ID, but in any event it is still needed. Besides, tearing it down may necessitate re-authentication and re- authorization. Complication is added because the NSIS CRN is only known once the NSIS signaling along the new path is completed. o Ping-pong type handover Manyfolks et al Expires July 2004 [Page 13] Internet-Draft Mobility and Internet Signaling January 2004 In a ping-pong type handover, the MN returns to the previous AR after staying with the new AR only for a short while. On the one hand, NSIS should remove quickly in order to free resources. On the other hand, in the case of ping-pong type handover, state would need to be reestablished soon again, also adding overhead. O Upstream local repair vs downstream local repair Since upstream and downstream path need not be equal, upstream and downstream CRNs need not be equal, either. In fact, local repair needs to be handled independently for upstream and downstream flows, including, e.g. discovery of upstream and downstream CRN. In summary, NSIS signaling needs to work with basic mobility which is an extension of general route (topology) change, and typically also includes IP address changes, supports mobile IP tunnels and multihoming. Path repair should be localized, and handled independently for upstream and downstream flows. 4. Cross-over Node Discovery and Path Update This section discusses how to discover the crossover node (CRN) in general and the role of the CRN (especially in Path Update). This section also discusses how the NAT/FW NSLP affects the CRN discovery. 4.1. Background Route change and main characteristics of mobile IP system described in Section 3.5 cause the session path to be changed, and therefore NSIS state needs to be re-established along the new path. In this case, the exiting protocols which do not support signaling in dynamic environment where route change or mobility event occurs can cause the following basic problems: * Double reservation Problem Since the state on the old path still remains as it is after re- establishing the state along the new path due to route change or mobility, the double reservation problem occurs. Although the existing state on the old path can be torn down by timeout of soft state, the refresh timer value in the core or wired network is quite long (e.g., 30 seconds in RSVP). As a result, in case of QoS- NSLP, the double reservation problem leads to the waste of resources and call blocking (especially in mobility scenarios). Therefore, the state along the old path should be removed immediately after state is set up on the new path. * End-to-end signaling Problem End-to-end signaling has to be considered as the issue-must-be- avoided in mobility scenarios, because it causes most problems related to service quality, signaling performance, and resource Manyfolks et al Expires July 2004 [Page 14] Internet-Draft Mobility and Internet Signaling January 2004 availability. The route change caused by mobility, which complicates QoS signaling more, may result in the change of flow identifier. The change of flow identifier requires state update along the entire path to reflect the physical location of the MN: end-to-end signaling. This also incurs a long state setup delay, signaling overhead, and double reservation which affects network performance. Ultimately, the long state setup delay will particularly gives rise to the service blackout or degradation for multimedia application in the mobility environment. To quickly re-establish NSIS state and improve scalability of NSIS signaling when route change and mobility event occurs, NSIS signaling should be localized, and the localized signaling procedure is referred to as path update (see the terminology section). This is because, although NSLP messages are initiated by an MN or CN and sent to the opposite terminating point of the path, the path in the wireless access network usually changes only partially. Therefore, the NSLP/NTLP should limit the scope of signaling information to a local section of the signaling path. The most appropriate node to do path update can be the CRN which is not a simple route splitting point, but an NSLP-aware merging point where the old and new session paths meet. To minimize the impact on seamless service, the CRN should be discovered by the NTLP as quickly as possible (see Section 4.2.2 for details), and afterward the involved NSLP should be triggered by the NTLP for necessary actions, for example, path update in case of QoS-NSLP. 4.2. Crossover Node Discovery 4.2.1. Types of Crossover Node There can be various types of CRN according to normal route change, mobility management, signaling states, and flow direction. In the context of NSIS, this section mainly discusses the types of CRN according to NSIS signaling states and flow direction. From the perspective of NSIS states (i.e., NSLP and NTLP sates), the types of CRN are basically divided as follows. First, from the NSLP's point of view, the CRN is a signaling application-aware node in the network where the signaling flows meet. Second, from the NTLP's point of view, it is a network node where more than one NTLP states (e.g., messaging association in [ntlp]). are stored. Although there can be various types of CRN according to state information, the CRN required for QoS-NSLP operation is NSLP CRN which has the corresponding signaling application information to perform the path update. Therefore, the CRN for the path update should be a logical NSLP-aware merging point rather than just a physical route splitting point. This implies that the CRN should not only be NTLP-aware but also NSLP- aware even if a CRN is detected by the NTLP. In this process, the NTLP should know the corresponding signaling application (e.g. QoS- NSLP) at the NSLP layer. Manyfolks et al Expires July 2004 [Page 15] Internet-Draft Mobility and Internet Signaling January 2004 The path change of a specific NSLP session flows can be caused by either route change or mobility, so basically there are two different types of merging point in the network according to the direction of signaling flows. The path change of downstream signaling flows may result in forming a downstream crossover node (DCRN) where the logical incoming interfaces start to converge, and the path change of upstream signaling flows may result in forming a upstream crossover node (UCRN) where the logical outgoing interface begins to diverge. Therefore, in general, the path change causes convergence or divergence of packets in data plane and/or in control plane (e.g., considering 3G/4G networks). There are some differences between route change and mobility in forming DCRN and UCRN, and the asymmetric characteristics of routing adds complexity to the CRN discovery. When a generic route change occurs, the path change of signaling flows results in forming a chain of two CRNs, which is referred to as a divergence and convergence pair (see Section 4.4.1). When a mobility event occurs, the asymmetric characteristics of routing between downstream and upstream directions can affect the location of the CRN. For instance, the handover of an MN (as an NI) will create a DCRN, and the handover of an MN (as an NR) will form a UCRN. However, the DCRN and the UCRN may be the same merging point in the network or may be different due to the asymmetric characteristics of routing although a CN is the same. The CRN will be temporarily formed for path update, and how long the CRN will be involved in the path update depends on the period and method of re-establishing NSIS states in mobility scenarios. If sates, for example, are pre-established during handover to support multimedia applications seamlessly, candidate NEs can be ferreted out by interacting with Seamoby protocols. In this case, the candidate CRN(s) also is (are) discovered to localize the signaling to obtain performance gains in the network (see Section 4.2.2). 4.2.2. Determination of Crossover Node A CRN can be discovered at both NTLP and NSLP layers. The CRN discovery at the NSLP layer can be done by NSLP signaling messages sent from the signaling initiator. For example, NSLP can realize it is a CRN by comparing the Source Identification Information (SII) contained in the incoming signaling message to that of previously stored in the node. However, in particular, the CRN would want to delete NTLP state when a particular NSLP is not supported there and NTLP state is not needed any more. Therefore, CRN discovery can be considered as an extension to the peer discovery at the NTLP level (e.g., using GIMPS query-response [ntlp]). In general, GIMPS message has message routing state information such as flow/session/signaling application identifier, so signaling application can be identified at the NTLP level. For example, in the connection mode of NTLP, when NTLP establishes messaging association between two adjacent peers, the NTLP peers exchange message routing state information through Manyfolks et al Expires July 2004 [Page 16] Internet-Draft Mobility and Internet Signaling January 2004 GIMPS query and response messages. Therefore, although CRN is discovered at the NTLP level, the discovered CRN is actually NSLP- aware node which has a involved signaling application. There can also be two different approaches in CRN discovery according as whether the discovery is coupled with signaling message or not: Coupled approach and separated approach. In this case, the CRN discovery at each NSIS level depends on the used approach (see Section 6.1.4). For CRN discovery, some session information such as the flow identifier and session identifier can be used. In addition, incoming/outgoing interfaces (e.g., Logical Interface Number: LIN) may also be used together with the session information. The CRN discovery can be further divided into UCRN discovery and DCRN discovery according to which node is a signaling initiator. The session identifier in the GIMPS message is used to easily identify the involved session because it remains the same while the flow identifier may (or may not) change due to handover. The flow identifier is used to specify the relationship between the address information and the state re-establishment (e.g., QoS-NSLP state re- establishment). That is, the changed flow identifier indicates topological changes (i.e., old path, new path, and common path) and so the state re-establishment is required. The logical interface number (LIN) can be used to establish or delete NSIS associations between peers. This identifier is also used to determine the CRN. NSIS entities may be able to use the interface number to locally distinguish each logical interface identifier between adjacent NTLP peers. Note that the LIN can be included in the NSIS message, but it can also be considered as an implementation issue. In general, when a route change due to mobility occurs, CRN can be recognized by comparing the existing session information (e.g., the session and flow identifiers) with the session information included in the peer discovery message initiated by an NI (e.g., an MN or a CN) through a different LIN (e.g., an incoming/outgoing LIN). If the session identifier is still the same and the flow identifier and LIN has been changed, the current NSLP-aware node realizes it is the CRN. Note that the node which performs the CRN discovery should check whether the CRN has been discovered or not before realizing it is the CRN. Optionally, a mobility object can also be used to indicate that the MN has experienced a handover and a route change has occurred [Jeong01] [Lee01]. In this case, the NSIS protocol (or node) may need to interact with mobility protocols to detect the CRN immediately. For example, the CRN discovery may need to be triggered in parallel with the transmission of the binding update (BU) message (of MIP). The mobility object may be defined in the NTLP message (e.g., GIMPS payload) to notify any mobility event explicitly, and it contains Manyfolks et al Expires July 2004 [Page 17] Internet-Draft Mobility and Internet Signaling January 2004 various mobility-related fields such as handover_init field and mobility_event_counter field. The handover_init field can be used to explicitly inform that a handover is initiated for fast state re- establishment. The mobility_event_counter field can be used to detect the latest handover event to avoid confusion about where to send a confirmation message which indicates that the CRN has been found. This type of confirmation may be needed when the MN moves toward the second new AR immediately after it undergoes a handover to the first new AR from the old AR, because the CRN discovery message from the second new AR may arrive earlier than from the first new AR. The mobility object may also be defined in the NSLP in a similar way. In this case, there should be some relationship between the mobility objects of the NTLP and the NSLP. If an MN is an NI when a route change due to mobility occurs, the MN begins to transmit signaling messages toward a CN in the downstream direction. In this case, an NSLP-aware node recognizes that the session paths converge, and then this node performs the comparison of session information checking the incoming LIN. After determining that the CRN has not been discovered yet, the NSLP-aware node realizes it is the DCRN. When an MN (as an NR) undergoes handover, the UCRN can be determined by checking the outgoing LIN of signaling flow from a CN. In this case, the UCRN should be the first node where the signaling flow begins to diverge. Since UCRN is determined by whether outgoing path diverges or not, the UCRN discovery is more complex than the DCRN discovery. If NSIS operates with HMIPv6 and an MAP is an NSIS-aware node, the UCRN can be locally discovered in an access network by the method above. If the UCRN is discovered between the MN and the MAP, the path update can be actually localized for upstream flows. However, note that when interworking with HMIPv6, it is still an open question how these nodes decide locally whether they are indeed the UCRN. The CRN discovery may also be initiated during handover (i.e., before handover is completed). However, in this case, a more efficient mechanism is needed to find a candidate CRN. For example, after a mobility event is detected by the NTLP, the current AR may use CARD to transfer the context for fast QoS-NSLP state re-establishment. After the candidate AR is found, CTP can be used to transfer the context which includes the QoS-NSLP session information for fast QoS- NSLP state re-establishment. If an appropriate AR is found and the context transfer is completed, a candidate CRN can be discovered easily since the candidate CRN discovery is basically the same as above. In some cases, however, it may not be always possible to use mobility-related protocols such as CT and CARD. In this case, the MN can initiate the CRN discovery only after it changes the point of attachment. To expedite the discovery process, it may be useful to transmit the peer discovery message (by the NTLP) and the first binding update message at the same time. Manyfolks et al Expires July 2004 [Page 18] Internet-Draft Mobility and Internet Signaling January 2004 4.3. Path update This section discusses possible procedures for path update according to the direction of signaling flows. As discussed in Section 4.1, the CRN can be a crucial point for path update, since the CRN is the NSLP-aware merging point of the old and new paths. From the perspective of path update, the CRN plays the role of initiating re- installation on the new path, teardown on the old path, and update of NSIS state on the common path. In mobility scenarios, the flow identifier for NSIS signaling may Change. Since the flow identifier is used to identify the signaling state installed along the path, the procedures for path update should include state update along the entire path to reflect the topological change of the MN. The CRN discovery is different according to the direction of signaling flow in mobility scenarios, and the DCRN operates independently of the UCRN although DCRN and UCRN can be simultaneously ferreted in bi-directional state establishment. Therefore, the procedures for path update may differ according to the direction of signaling flows. For downstream signaling, path update is triggered by the MN (or mobile agent) or an AR, which is referred to as Downstream Path Update. For the upstream signaling, path update is initiated by a CN, a HA, or a GFA/MAP, which is referred to as Upstream Path Update. In this case, each signaling initiator has to be authorized for secure signaling. 4.3.1. State Setup and Update In both types of path update, NSIS protocol needs to interact with mobility signaling and the Seamoby protocols (during or posterior handover) to obtain performance gains through fast re-establishment of the NSIS states along the new path. In this case, NSIS needs to monitor for detecting the movement through several methods [nsis-fw]. After detecting a mobility event, the NSIS protocol can check resource availability on the new path (or new candidate path) through CARD or other mechanisms during handover in order to check the possibility of state re-establishment on the new path in advance. In the downstream path update, if resource availability is assured, an MN initiates the NSIS signaling for state setup toward a CN along the new path. The DCRN discovery is implicitly done by this type of signaling initiated by the MN. In this case, the node where old and new logical session paths converge realizes that it is the DCRN, and afterward the DCRN sends a response message toward the MN to notify of NSLP state installed (e.g., in QoS-NSLP) or installs the NSLP states as responding the NSLP signaling initiated by the MN (e.g., as in RSVP). In the downstream path update, the sender-initiated approach (e.g., QoS-NSLP) leads to faster setup than the receiver- initiated approach as RSVP. And then, the DCRN sends a refresh message toward the signaling destination to update the changed flow identifier on the common path and also sends a teardown message toward the old AR to delete the NSIS states along the obsolete path. Manyfolks et al Expires July 2004 [Page 19] Internet-Draft Mobility and Internet Signaling January 2004 In the case of upstream path update, the CN (or a HA/ a GFA/MAP) sends a refresh message toward the MN to perform path update. UCRN is discovered implicitly by the CN-initiated signaling along the shared path, and the node from which the common path begins to diverge into the old and new logical session paths realizes that it is the UCRN. In this case, the CN should be informed of the movement event using an NSIS signaling message sent by the MN or monitoring the mobility signaling. After the UCRN is determined as described in Section 4.2.2, it may send a refresh message to the MN along the new path while establishing the NSIS association between the updated peers, and afterward the UCRN may send a teardown message toward the old AR to delete the NSIS state on the obsolete path. The state update in control plane on the shared/common path to reflect the changed flow identifier brings issues on the end-to-end signaling. Although the state update does not give rise to re-process AAA and admission control, it may lead to the signaling overhead. If NSIS protocol interacts with Hierarchical Mobile IPv6 scheme, the NSIS session only has the changed flow identifier between an MAP/GFA and an MN. However, whether the update of the flow identifier for the session can be considered only between an MN and an MAP to avoid end- to-end signaling is still an open issue. One of the goals of path update is to avoid double reservations (in case of QoS signaling) on the shared path described in Section 4.1. The double reservation problem may be solved by establishing a signaling association using the unique session identifier. That is, NSLP state can be shared even if different flow identifiers changes. For example, QoS-NSLP state (for resource reservation) can be used by packets for either flow. 4.3.2. State Teardown After re-establishment of the NSIS state along the new path, the state on the obsolete path should be quickly removed by path update mechanism to prevent the waste of resources due to double reservation (and resource allocation problem by call blocking) and to reduce the cost of using the resources in the access network as described in Section 4.1. Although the release of the existing state on the old path can be accomplished by timeout of soft state, the refresh timer value may be quite long and the maintenance of the NSIS state on the obsolete path may not be necessary. Therefore, the transmission of a teardown message is particularly preferred to the use of refresh timer to quickly delete the old state. The CRN is an appropriate point to initiate the teardown toward the old AR after re-establishment of the state along the new path. In this case, the release of old state on the obsolete path can be accomplished by comparing outgoing LINs and through reverse routing using SII. This can prevent the teardown message from being forwarding toward along the common path. However, whether the teardown message can be sent toward the opposite direction to the state initiating node is still an open question. This also leads to Manyfolks et al Expires July 2004 [Page 20] Internet-Draft Mobility and Internet Signaling January 2004 authorization problem because a node which does not initiate signaling for establishing the NSIS state can delete the state. To avoid the waste of resources, the resources on the old path should be removed as soon as possible after re-establishing the state along the new path. However, this may not be appropriate for fast handover of a ping-pong type where an MN may return to the previous AR after staying at a new AR for a short while. When to delete the state along the obsolete path remains still an open issue. If the old AR is the last node due to handover, its NSLP may trigger an error message to indicate that NSLP messages cannot be forwarded any further. This error message may cause the removal of the old states. However, although the error message is initiated, the state on the old path should not be deleted before re-establishing the state along the new path. This issue can be solved by using the handover_init field of mobility object mentioned in Section 4.2.2. When an MN, for example, detects a handover, the QoS-NSLP of the MN constitutes the MOBILITY object (the handover_init field) in the QoS- NSLP signaling message and send it to the current AR (the old AR), which prevent the current AR from initiating the error message indicating the dealt with more detail in Section 5. 4.4. Effect of generic routing changes 4.4.1. CRN discovery In case of generic route change, the CRN can be a node which detects the change of a data flow in the network. When the downstream or upstream data flow begins to travel, a node can detect the route change by interacting with NSIS, routing protocol, and detection method based on network monitoring, data packet monitoring, or signaling message monitoring [nsis-fw]. The node detecting the route change starts to discover the next peer via the NTLP peer discovery message exchanges and continues to do the peer discovery until discovering a node which already has the involved NSLP states. Whenever a new peer is discovered, NSIS creates as an association with the previous peer using the LINs. In case of downstream data flow, the first NSLP-aware node where the signaling flow starts to diverge can be considered as a diverging DCRN, and the first NSLP-aware node where the signaling flow begins to converge can be identified as a converging DCRN. As mentioned in Section 4.2.1, the route change of signaling flows results in forming a chain of divergence and convergence CRN pair in the network. For upstream signaling flow, the first NSLP-aware node where the signaling flow diverges can be considered as a diverging UCRN, and the first NSLP-aware node where the signaling flow converges can be identified as a converging UCRN. However, How an NSLP-aware node identified itself whether the first node which converges and diverges is CRN is still an open question. Manyfolks et al Expires July 2004 [Page 21] Internet-Draft Mobility and Internet Signaling January 2004 4.4.2. Path Update In generic route change, since the flow identifier does not change, state update along the common path is not performed. Therefore, state re-establishment along the new path and teardown along the old path are only carried out. There is also no difference between downstream signaling and upstream signaling compared to mobility scenarios because the diverging CRN should interact with the converging CRN for each signaling flow. In downstream path update, the diverging and converging DCRN pair is discovered after route change as described in Section 4.4.1. In this case, the diverging DCRN initiates signaling to establish NSLP states on the new path toward the converging DCRN by sending the RESERVE message [QoS-NSLP]. Note that in the coupled approach, peer discovery is done simultaneously with state re-establishment (see Section 6.1.4), and so a diverging node and a converging node are implicitly identified as DCRN. If each node between the diverging DCRN and the converging DCRN can not delete their NSLP state for itself (i.e., refresh timer), the converging DCRN can trigger the removal of the obsolete state by interworking with the diverging DCRN. Therefore, the converging DCRN begins to delete the NSIS states on the obsolete path in the reverse direction (e.g., toward the diverging DCRN) after installing state on the new path. In this case, the diverging DCRN should be able to identify that the teardown message (e.g., RESERVE message in [QoS- NSLP]) from the converging DCRN should not be delivered beyond the diverging DCRN. For this purpose, the teardown message may have a "Path Update (PU)" flag in its header field, or the destination address of the teardown message may be that of the diverging DCRN, and converging DCRN should know the reverse routing information to send the teardown message toward diverging DCRN (e.g., using SII in [QoS-NSLP]). For example, the diverging DCRN can prevent the teardown message from being forwarded toward a sender by discerning the í—PUí˜ flag. However, whether the teardown message can be sent toward the opposite direction to the original state initiator is still an open question. This also leads to authorization problem because a node which does not initiate signaling for establishing the NSIS state may delete the state. For the upstream path update, the divergence and convergence UCRN pair also follows the same procedure as above. 4.5. Open Issues There are some open issues that should be discussed in the later version of this document, and they are summarized as follows. - In the Interworking with HMIPv6, how can the nodes decide locally whether they are indeed the UCRN? - Can the update of the flow identifier for the session when interworking with HMIPv6 be considered only between an MN Manyfolks et al Expires July 2004 [Page 22] Internet-Draft Mobility and Internet Signaling January 2004 and an MAP to avoid end-to-end signaling? - Can the teardown message be sent toward the opposite direction of the state initiator? - When is the right time to delete the state along the obsolete path for fast handover of a ping-pong type? - How can the crossover node be discovered in the specific multicasting/multihoming cases? - How does the NAT/FW NSLP affect the CRN discovery? 5. Dead Peer Discovery (DPD) 5.1. Overview A dead peer can occur either because a link or a network node, including the MN and CRN, failed, or because the mobile node moved away without informing NSLP/NTLP (it is recommended to link mobility- and nsis signaling such that this does not happen). Hence, DPD is the fall-back mechanism for dealing with mobility which is not currently hooked into the NSIS protocol suite. The procedures for handling DPD should be the same no matter why a peer is dead, because an NE discovering a dead peer cannot judge the specific reason. That is, DPD due to a link or node failure, and DPD due to an MN moving away should trigger the same reaction. In any case, dead peers should be discovered as soon as possible to minimize service interruption. Subsequently, NSIS needs to find a different path interacting with the routing protocol. Thereby, NSIS needs to take into account the possibility that no path to the dead peer exists. Once the new path is found, NSIS state needs to be set up along the new path, and NSIS state needs to be torn down along the old path. However, care must be taken to terminate teardown at the CRN since the NSIS state on the common path should not be deleted. 5.2. Failure Cases and Impact of Dead Peers 5.2.1. Failure Cases Dead peers of interest in mobility scenarios include CRN, MN, and AR. In general, it is possible that only NSIS functions (i.e., NTLP/NSLP) of the node may fail, or the physical hardware. As mentioned above, an MN may either fail or move. When it fails, it becomes a dead peer. When it moves, it either changes or retains its IP address (e.g., CoA). If it moves and changes its IP address without notifying NSLP/NTLP, it also becomes a dead peer. If it moves and keeps its IP address, we need to solve a rerouting problem rather Manyfolks et al Expires July 2004 [Page 23] Internet-Draft Mobility and Internet Signaling January 2004 than a dead peer problem. 5.2.2. Impact of Dead Peers The failure of a (potential) NSIS CRN may result in incomplete state re- establishment on the new path and incomplete teardown of the old path after handover. In this case, a new CRN should be discovered immediately by the CRN discovery mechanism described in Section 4. The failure or movement of an MN may cause the 'invalid NR' problem [draft- lee-nsis-nslp-mobility-01.txt] where the NR is the MN. [the following text could be added for clarification: If the MN moves, an error message, e.g., can-not- be-forwarded-further, should be generated by the MN, since this message may prevent the teardown of NSIS state on the old path before NSIS state is re-established on the new path]. We may need to also consider the case where the MN is not the NR, but a router in the access network (possibly the AR) is proxying for the MN instead. If the MN moves without changing its IP address, usually this is a micro mobility scenario. Two basic ways for handling micro mobility are currently used: - By source node routing [HMIPv6] towards the MN, i.e. coding the new route explicitly in each packet. It is difficult to do nsis-signaling for such a scenario, except by also source-node routing signaling messages. - By changing the so-called Regional CoA, which is not visible outside the micro mobility region. Packets destined to the MN are always addressed to the Mobility CRN. The Mobility CRN tunnels the packet to the MN [HMIPv4, HMIPv6]. Mobility in this case is not noticed by NSIS, because NSIS signaling is tunneled the same way as data packets. A separate NSIS state needs to be set up for the tunnel, and the NSIS state for the old tunnel needs to be torn down. Micro mobility with unchanged IP address is also handled in ad-hoc routing protocols in which per-host routing entries are changed in the routing tables. Hence in this case, mobility results in rerouting, just as when an intermediate node or link fails. If the MN moves with a changed IP address, the MN reappears somewhere else and tries to set up NSIS state along the new path. The requirements derived from this scenario contradict those derived from a true MN failure, where the MN does not reappear: - In the case of MN movement, teardown of NSIS state should be terminated at the NSIS CRN (cf Sec. 3.5) However, the NSIS CRN is only known once the NSIS signaling along the new path is completed. Therefore, state along the new path needs to be established first, and only then the old state should be torn down. (See also discussion in Sec. 4). Manyfolks et al Expires July 2004 [Page 24] Internet-Draft Mobility and Internet Signaling January 2004 In contrast, in case of MN failure, NSIS state should be removed along the entire path as quickly as possible. A CRN does not exist. Recall it is impossible for the NE discovering a dead peer to distinguish these two cases. We therefore need to settle on a single mechanism for handling both. The failure of an AR may make the interactions with Seamoby protocols (such as CARD and CT) impossible. In this case, the neighboring peer closest to the dead AR may need to interact with CARD and CT. 5.3. DPD procedures in NTLP The procedures of how to do DPD should be handled by the NTLP. In fact, the DPD can be considered as an extension to the GIMPS peer discovery. The transmission of peer discovery messages may be separated from the transmission of regular signaling messages. It is also possible to combine both types of messages for efficiency in message delivery. For example, the detection of an NSIS peer and the establishment of an NSIS state can be performed using an NSIS message at the same time. There are cases where an NE does not deliver signaling messages successfully to its NSIS peer along the signaling path, for example, when an NF (or NR) was disconnected from the network due to one of the failures described above, causing a change of signaling path in the network. Such dead peers which are no longer reachable should be detected. Some possible DPD procedures are described below. A peer discovery message can be periodically transmitted to the neighboring peer (e.g., responding node in [GIMPS]), and the responding node can send a response message. To determine if the peer is alive, the use of a timer may be helpful. For example, the response message may need to be received by the sender (e.g., querying node in [GIMPS]) of the peer discovery message before the timer expires. Otherwise, the responding node can be considered dead. It is important to check the validity of the peer discovery messages for security protection. For example, it may be necessary to determine if the peer discovery message has been received from the authorized peer. Cookies such as query-cookie and response-cookie [GIMPS] may be useful for this purpose. According to the [GIMPS], the NTLP itself does not provide for teardown of NTLP state because, as opposed to NSLP state, it is not very expensive. NTLP instead relies on time-out. Upon DPD, NTLP informs the local NSLPs about it, and may even send a notification to other NTLP peers upstream to inform other NSLPs which it does not support locally. It is an open question when to stop propagating this information [GIMPS], which is not specific to mobility. Local NSLPs (e.g., QoS-NSLP) could either initiate a teardown of the corresponding NSLP state upstream, i.e., in the direction opposite to Manyfolks et al Expires July 2004 [Page 25] Internet-Draft Mobility and Internet Signaling January 2004 the dead peer (possibly accelerated expiration as described in [GIMPS] if the node is not authorized to do this) or send a notification upstream which might result in the NI to take action. Actually in [QoS-NSLP] it is not fixed yet what must happen. A dead peer may lead to rerouting, or sometimes, as sometimes in the case of a dead NR, no new route being discovered. Rerouting may be noticed by more than one NE using one of the detection mechanisms described in [GIMPS]. Furthermore, more than one NE may be able to reroute around the situation (see Fig. 8 in [GIMPS]). The NE closest to the flow sender should become the NSLP CRN. Finding the new path and establishing state can be done as described in Section 4. The relative timing of state teardown and re- establishment is still an open question as discussed in Section 5.2.2. 6. Case Examples The movement of end-hosts leads to changes in the data path due to the change of their point of attachment in the network. This results in the original data path between a sender and a receiver to be divided into three paths, all of which intersect at a CRN: the unchanged path from the CN until the crossover router, the new path from the crossover router until the new location of the MN and the old path from the crossover router until the old location of the MN. Due to rerouting of data packets after handovers, signaling- associated states need to be updated or removed. This concerns with which information is needed for indexing states and where and when a creation, update or removal of these states is required. If signaling-associated state is indexed based on flow-Ids, the state indexed by the flow-ID referred to the old path might be inaccessible for the signaling after most handover procedures. Hence, it is assumed that signaling-associated state is indexed by session-IDs. This section provides concrete examples of the signaling done in a handover situation. 6.1. NSIS in the hard-handover case This example is called hard-handover, or break-before-make handover, in which the NSIS signaling, required to update the MN path, happens only after the MN is attached to the new access point. To update the path between the CN and the MN, state needs to be installed in the new path, released from the old one and updated in the unchanged path. The NSIS signaling required for this operation may be triggered by the mobile node, mobility agent(s), or by the access router at which the mobile node is attached to. In any situation, the CRN is the starting point or finish point of the NSIS signaling messages. Manyfolks et al Expires July 2004 [Page 26] Internet-Draft Mobility and Internet Signaling January 2004 Since we have to assume that the MN can be a sender as well as a receiver, the first difficulty to find a CRN is posed by the asymmetric characteristic of routing, as mentioned in Section 4.2. Due to routing asymmetry there is no reason for the UCRN and the DCRN to be the same in the, even for the same correspondent node. Therefore the NSIS signaling sequence required to update the path depends on the role of the MN, which is the one detecting the attachment to a new network. Figures 6.1 and 6.2 illustrate the signaling needed to update the MN path in the upstream and downstream direction when the MN is a sender or a receiver. In both figures, the "r", "s", and "u" indicate NSIS messages to remove state in the old path, set state in the new path and update state in the unchanged path. The "t" in Figure 2 represents the triggering message that the MN sends to the CN. This triggering message can be for instance a mobility-binding message. +---+ [MN] |AR1|| | | (a) MIPv6: MN-->CN, no reverse tunnel MN HA CN |IPv6(tunnel)| | |----------->| IPv6(normal) | | |--------------------->| | | | (b) MIPv6: MN-->CN, with reverse tunnel Fig. 8.1: Implications for flows under different mobility scenarios Manyfolks et al Expires July 2004 [Page 33] Internet-Draft Mobility and Internet Signaling January 2004 CN MN | | | MIPv6(RH Type 2) | |--------------------------------->| | | (c) MIPv6: CN-->MN, route optimization CN HA MN |IPv6(normal)| | |----------->| | | | MIPv6(tunnel) | | |----------------------->| | | | (d) MIPv6: CN-->MN, no route optimization CN HA MAP nAR(MN) | | | | | IPv6 | | | |---------->| | | | (normal) | | | | | MIPv6 | | | |----------->| | | | (tunnel) | | | | |HMIPv6 | | | |-------->| | | |(tunnel) | (e) HMIPv6: CN-->MN, no route optimization CN pAR nAR MN | | | | |MIPv6(normal-HA-tunnel) | | |----------------------->| | | | | | | | FMIPv6 | | | |<-----------| | | | (tunnel) | | | | FMIPv6 (tunnel) | | |---------------------->| | | | | (f) FMIPv6: CN-->MN, no route optimization Fig. 8.1: Implications for flows under different mobility scenarios Manyfolks et al Expires July 2004 [Page 34] Internet-Draft Mobility and Internet Signaling January 2004 8.2. Interactions with Seamoby Protocols Although the NSIS protocol suite operates in a path-coupled way, the interactions between NSIS and Seamoby protocols have an effect on parts that are out of the signaling path. In the context of handovers between old and new access routers, there can be performance optimization issues in the following two areas: selection the optimal access router to handover to and transfer of state information between the old and new 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 CTP respectively), but a discussion of the way in which these functions interact with NSIS signaling is necessary. As mentioned in Section 3.3, significant performance gains can be achieved if NSIS signaling can interact with such protocols although they can operate independently. In this case, some questions arise: which scenario these protocols can be used in, or what the mode of interaction should be: pre-establishment and re-establishment approaches or passive triggering mode where NSIS is triggered by CARD/CTP and active triggering mode where NSIS triggers these protocols. In general, CARD is required to identify candidate ARs (CARs) for handover and find capabilities of these CARs prior to the initiation of the IP-layer handover. CTP is used to quickly re-establish context transfer-candidate services without processing for those services from scratch and additionally to provide an interoperable solution that supports various layer 2 radio access technologies. However, in the pre-establishment using NSIS, CARD/CTP can interact with the NSIS protocol suite to ferret NSIS-aware candidate AR where an MN will move and establish NSIS state before the completion of handover. That is, the interaction between NSIS and CARD/CTP prevents resources from being excessively pre-reserved. In this approach, for the fast setup of NSIS state, path update along the candidate NEs may also be achieved simultaneously with (or through) discovering a candidate CRN. When a handover, for example, is initiated, the current AR receiving the movement detection information (e.g., 'RtSolPr' message in FMIPv6 [FMIP] if NSIS also interacts with this mobility protocol) from an MN may interact with the CARD to ferret an appropriate (NSIS-aware) access router (or a few candidate access routers (CARs) may be found). In this process, the NTLP of the current AR should be able to recognize whether the CAR is an NSIS-aware node after sending the 'capability reply' message (of CARD). The QoS-NSLP of the AR may need to be interaction with the CTP to transfer the QoS-NSLP state information to the newly discovered NSIS-aware candidate AR. After receiving the context, the NTLP of the candidate AR may be able to begin to trigger the discovery of a candidate CRN using the QoS-NSLP state information in the coupled approach or separated approach. QoS and context transfer issues have already been considered already some time ago in [I-D.thomas-nsis-rsvp-analysis]. More recently [CTP- Interop] and [Lee01] present ways and some open issues for Manyfolks et al Expires July 2004 [Page 35] Internet-Draft Mobility and Internet Signaling January 2004 interoperation between NSIS and CTP in both predictive mode and non- predictive mode. In the re-establishment approach, CARD can be used to only check admission control status on the new path before handover is completed, and CTP can be used to transfer NSIS state (e.g., QoS-NSLP state) to a CAR to quickly re-establish the state along the new path after handover. The main objective of interaction in this approach is to reduce state setup delay and packet losses due to handover. In case of passive triggering mode, CARD/CTP may use NSIS signaling to check the admission control status of CAR and pre-establish NSIS state on the candidate path and discover a candidate CRN in the pre- establishment approach. In this case, resource availability on the path between the AR and CN should also be discovered using NSIS signaling. A possible example is that some entity in a candidate AR can trigger NSIS using resource and reservation information from the current AR to find out about how much resources would be available on the new path. In the context of NSIS, the NSIS protocol generally can trigger the CARD/CTP to transfer its own state information from the current AR to CAR: active triggering mode where the NSIS protocol should monitor the operation of these protocols. Note that the NSIS protocol, in the first place, should interact with mobility protocols (i.e., usually with FMIPv6), or be coupled with movement detection mechanisms to timely initiate the CARD/CTP in both reservation approaches. If NSIS does not consider interworking with CARD/CTP or it is not possible to use these protocols, NSIS protocol in itself may be able to discover the CAR as an extension of NTLP peer discovery mechanism in the separated approach, and to check whether resources on the candidate path is available or not before the completion of handover. However, this also makes NSIS protocol perform path-decoupled signaling, and whether these functions in NSIS can be implicitly developed is an open issue. 9. Additional issues This section highlights some important issues not discussed earlier in this draft. 9.1. Both End-Hosts are Mobile Considerations about signaling between two mobile devices. Until now, we are assuming a non-mobile corresponding node. Problems can show up if both devices start to signal at the same time. Manyfolks et al Expires July 2004 [Page 36] Internet-Draft Mobility and Internet Signaling January 2004 9.2. Uni- and Bi-directional State Establishment It should be possible to support unidirectional NSIS state establishment in both sender- and receiver-oriented modes. For example, in case of QoS-NSLP, the MN (as a sender) can initiate a reservation setup for its outgoing flows in the sender-initiated mode. With the receiver-initiated approach, the MN (as a sender) requests the receiver to make a reservation, thus allowing the receiver to initiate a reservation for the flow. After handover of the MN (as a sender) to a new AR, the state re-establishment should be performed in the similar way. In addition to the unidirectional NSIS state establishment above, bidirectional state establishment can also be supported. In the basic case, bidirectional NSIS signaling can simply use a separate instance of the same signaling mechanism in each direction. Although the bidirectional data flows have the same end points, the paths in the two directions do not need to be the same. Therefore, the CRN of the downstream path may be different from that of the upstream path in mobility scenarios. As a matter of course, the Session ID in the downstream reservation should be different from that of the upstream reservation. If the routes (i.e., upstream and downstream paths) are symmetric, an NSIS single signaling message can be used to install state in both directions. If the routes are asymmetric, an NSIS signaling message from the originator (e.g., MN or CN) can trigger an independent signaling message from the responder. 9.3. State Management The main objective of NSIS is to manage state information along the path taken by a data flow. For state management, the NSIS protocol suite normally use a soft-state approach to manage state in NEs where the state created by the NSIS message has to be periodically refreshed. At the NTLP layer, the state is maintained through the exchange of GIMPS query/response messages between adjacent peers [ntlp]. In this case, the peer relationship is maintained using a timer which implies how long the association between the peers can be considered valid. That is, if it has not been refreshed until the timer expires (e.g., after 30 seconds as a default value), the peer relationship is removed. The management of state (i.e., routing state and messaging association) can be controlled in this way. At the NSLP layer, the peer-to-peer refresh messages can also be used for state management. In case of QoS-NSLP, states should be set up and maintained for the reservation of desired resources. In this context, the operation of QoS-NSLP is similar to that of RSVP [RFC 2205]. An example of state management at the QoS-NSLP layer is as follows. Upon receiving a RESERVE message, an NE (specifically the QoS-NSLP) sets up state for QoS reservation. This state will be deleted unless it is refreshed by a RESERVE message before the refresh timer expires. The peer-to-peer based refreshment allows the Manyfolks et al Expires July 2004 [Page 37] Internet-Draft Mobility and Internet Signaling January 2004 QoS-NSLP to appropriately select the refresh time by considering the current network environment. For example, it may set the refresh timer value in the mobile/wireless (access) network to a smaller value than that in the core (wired) network [QoS-NSLP]. Note that, however, unlike the QoS-NSLP, the refresh time of NTLP state doesn't need to be adjusted according to the type of the network from the perspective of resource utilization. In case of QoS-NSLP, the main objective of the adjustment of the refresh time is to minimize the waste of resources due to double reservation. Setting the refresh time in the access network differently from that of the backbone network can be done by manual configuration or an adaptive technique. A possible example of such adaptive techniques is to use a field, e.g., 'REFRESH' field of the mobility object (or Refresh object). The 'REFRESH' field may consist of 'M' bit for indicating the type of the network (e.g., the mobility-supporting access network) and 'PRE' bit for fast QoS re- establishment (e.g., pre-reservation). The refresh timer value of pre-reservation state should be maintained for a short period of time. In mobile and wireless networks, the QoS-NSLP (rather than the NTLP) should be able to set the refresh timer value depending on the part of the network (e.g., an access network or backbone network) or the reservation style (e.g., pre-establishment or re-establishment). For example, in case of pre-reservation, upon receiving the mobility object during handover, the QoS-NSLP of the NE which is supposedly involved in the QoS signaling can set the 'PRE' bit of the outgoing QoS-NSLP message. In this case, if the refresh timer value of 'PRE' bit is set to a little higher value than the estimated handover latency, the MN can be provided with seamless QoS service using the pre-reserved resources, and the resources which are pre-reserved but unused will be timely released after handover. Note that after handover, QoS-NSLP should restore the original refresh timer value in order to avoid the overhead due to the frequent transmissions of the refresh message (e.g., 'PRE' bit is reset to null and 'M' bit is kept to be 1). Note that, however, procedure for computing the refresh time is not part of the NSIS protocol. Thus, how to set the refresh timer value of the 'M' and 'PRE' bits according to mobility scenarios is also an implementation issue. 9.4. State establishment in Network Mobility The network mobility (NEMO) Working Group is focusing on managing the mobility of a mobile network (e.g., a leaf network) which changes its point of network attachment as a unit through one or more mobile routers (MRs). In this case, the leaf network consists of one or more MNs and/or fixed hosts, and it may include multiple heterogeneous network interfaces. An MR basically has a Home Agent (HA) and bi- directional tunneling between the MR and HA to preserve session continuity while the MR moves into other point of network attachment. The MR as a single node obtains a CoA as in the MIP mechanism, which allows nesting of mobile networks. However, the nested mobile Manyfolks et al Expires July 2004 [Page 38] Internet-Draft Mobility and Internet Signaling January 2004 networks cause the pinball routing problem because flows of each mobile network may transit multiple HAs through multiple bi- directional tunnelings. A mobile network can also have multihoming- related issues through either a single MR which has multiple interfaces to the network, or multiple MRs which attach the mobile networks to the network. The solutions in the NEMO WG will support preservation of route aggregation in the network when flows of MNs (and/or fixed hosts) in a mobile network are sent to the same CN. In this case, aggregate state installation, e.g., for aggregate reservation (or group reservation), should be considered to guarantee resources along the aggregated route between the MR of the mobile network and the CN. This aggregate state installation issue also requires careful consideration in view of mobility related issues in NSIS. To deal with aggregate state installation in network mobility, issues such as multihoming and pinball routing problem caused by the nested mobile network and various scenarios for network mobility should be considered. However, it is recommended that such issues be handled in liaison with NEMO WG which is still at its early stage in developing solutions for the route optimization problem. Therefore, it is premature to specify details on the aggregate state installation in this draft. 10. Guidelines for Designers of new NSLPs This section presents issues that must be taken into account when designing a new NSLP for a mobile and wireless environment. The main issues are: - IP addresses of the communicating nodes can change during the lifetime of the session, - The bandwidth of the last-hop link may be limited and vary drastically, - Routing may be asymmetric, - There may be tunnels that hide the original IP packet header, - an NE before establishing new state should check whether is already has state with the same session ID but a different flow ID. If this is the case it needs to find out whether it is CRN and act accordingly (details to be spelled out). - path repair should be localized - procedures for handling DPD should be the same independent of whether a peer is truly dead or just changed its IP address because of handover. 12. Security Considerations This section describes authorization issues for mobility scenarios in NSIS. It tries to raise additional questions beyond those discussed in [SID]. For the discussion of various authorization problems we assume that initial authorization is strongly coupled to authorization handling in subsequent message interactions. Making this assumption, as we see in the subsequent text, has some implication to the signaling message behavior. It is certainly possible that the entities who grant the initial reservation and those who subsequently cause modifications are not the same entities. Please also note that NSIS does not mandate a single model for the initial authorization step (such as receiver has to provide authorization as in RSVP). Hence it is necessary to consider more combinations. As argued in [NSIS-AAA] it is necessary to consider cases where the sender, the receiver or both are authorizing a reservation. The reader should keep in mind that these signaling message exchanges are not only applicable for QoS reservations but also for other NSLP applications such as NAT/Firewall signaling. The concept of sender- and receiver-initiated reservations is very vague in case of NAT/Firewall signaling. There a concept of delayed authorization is suggested with requires both, the sender and the receiver, to authorize packet and NAT binding establishment. Subsequently, we will consider the case where the mobile node acts as a data sender followed by a discussion of the CN as a data sender. Each scenario is separated into more individual scenarios. 12.1. MN as data sender Figure 12.1 describes a scenario with the MN as a data sender which moves from one point of attachment to another. The two flows are merged at the DCOR. The path between the DCOR and the CN is referred as the shared segment. Along the shared segment it might be necessary to update the flow identifier but not the NSLP state itself. Manyfolks et al Expires July 2004 [Page 40] Internet-Draft Mobility and Internet Signaling January 2004 new segment +--+ +---+ new flow new |MN|>>>>>>>>>>|NAR|>>>>>>>>>>>>>V address +--+ +---+ V ^ +----+ +--+ | |DCOR|>>>>>>>>>>|CN| | | |>>>>>>>>>>| | | +----+ +--+ | +--+ +---+ ^ shared original |MN|>>>>>>>>>>|OAR|>>>>>>>>>>>>>^ segment address +--+ +---+ original flow MN acts old segment as UCOR ========================= DATA ===================================> Legend: >>>>>>>: denotes signaling message flow the direction of the arrow shows the direction of the initial signaling flow direction <------: movement <======: data flow (direction indicated with arrow) Figure 12.1: MN as data sender We will start with the initial flow setup triggered by the MN and also authorized by the MN. 12.1.1. MN is authorizing entity This scenario considers the initial flow setup executed by the MN whereby the MN provides authorization for the initial flow setup. The initial setup might be used to create state for subsequent authorization actions by the MN. It is obvious that the authorization for the NSLP application (e.g., QoS NSLP) has to provided. Depending on the underlying authorization model it might be either peer-to-peer or end-to-middle. This authorization decision can possibly be treated independent of the authorization issues discussed in this section MN CN ------>----->------>------>------>------>------> + ACTION (MN is authz) | | <-----<-----<------<------<------<------<------- | Flow ACK | Setup | ===============================================> + Traffic Figure 12.2: Initial MN authorized flow setup Manyfolks et al Expires July 2004 [Page 41] Internet-Draft Mobility and Internet Signaling January 2004 The following questions seem to be interesting: - Should the MN indicate that it is the authorizing entity for subsequent actions to all entities along the path? - What information should be used for this purpose? - Who should add this information? Should the visited network of the MN add something to the signaling message during the initial flow setup? - How do other entities along the path learn this information? Scenario: The MN authorizes DCOR The movement of the mobile node after the initial flow setup requires authorization. Various session ownership authorization issues are illustrated in the [SID] draft itself. We will not repeat these issues in this document again. MN DCOR CN + E.g. ------>----->------>------>------>------>------> | Movement ACTION | with state | creation at <-----<-----<------<------<------<------<------- + new path ACK Figure 12.3: MN authorizes DCOR The following questions are of interest: - Why should DCOR execute something on behalf of the MN? (i.e., why should it trust the MN and what information can the DCOR use for verification?) As an example, the DCOR might delete state along the old segment. - Should the DCOR alone be able to start signaling (the DCOR might be a designed node in some mobility protocols (e.g., MAP)) since it is the node which has more information that other nodes based on the mobility signaling protocols? - How should other nodes between the MN and the DCOR and between the DCOR and the CN know that the DCOR is now acting on behalf of the MN? Scenario: The CN triggers action CN wants to tear-down flow or it wants to trigger an action in the network Manyfolks et al Expires July 2004 [Page 42] Internet-Draft Mobility and Internet Signaling January 2004 MN DCOR CN <~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + TRIGGER | E.g. | Tear | Down ------>----->------>------>------>------>------> | ACTION | | <-----<-----<------<------<------<------<------- + ACK Figure 12.4: CN triggers action Questions: - Why should the MN trust the trigger? - Is it possible to specify the security properties of the trigger message in more detail? (If this is an NSIS message then we could argue that hop-by-hop trust does not always replace end-to-end security.) - (see for example the discussion in with regard to an indicator which entity to charge for the reservation. - Should the CN restrict the actions of the MN (e.g., delete, update, create)? On the shared segment it might, for example, be possible to restrict the allowed action to a flow identifier update. 12.1.2. CN is authorizing entity This scenario is quite similar to the CN triggering in Section 1.1.1. Two slightly different protocol variations will be considered. Authorizing some actions in the reverse data flow direction is more difficult as it can easily be seen in Figure 12.5. Variant 1: CN asks MN to trigger action (on behalf of the CN) In Figure 12.5 the CN authorizes the MN to start signaling after, for example, a movement. After receiving the trigger message (and some authorization information) the mobile node starts signaling along the new segment and automatically discovers the DCOR. The message travels along the shared segment to the CN and updates the flow identifier (if necessary). The MN might additionally allow the DCOR to delete the reservation along the old segment. Manyfolks et al Expires July 2004 [Page 43] Internet-Draft Mobility and Internet Signaling January 2004 MN DCOR CN <~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + TRIGGER | | ------>----->------>------>------>------>------> | ACTION (CN is authz; MN on behalf of CN) | +-----------------+ +-----------------+ | | Action: | | Action: | | | 'create' along)| | 'update' along)| | | new segment) | | shared segment)| | Action +-----------------+ +-----------------+ | <------<------<------- | +-----------------+ | | Action: | | | 'delete' along)| | | old segment) | | +-----------------+ | <-----<-----<------<------<------<------<------- | ACK | | | ===============================================> | Traffic + Figure 12.5: CN asks MN to trigger an action (on behalf of the CN) Questions: - How should the "delegation" mechanism work such that intermediate nodes believe the MN that it is acting on behalf of the CN? - Is it possible to carry this information with the Trigger message from the CN and the MN? Variant 2: CN uses installed state to route message backward As a second variant the CN uses NSIS installed state to route a signaling message backward along the path. In some rare cases the DCOR node might be known already. In this case it is possible to stop the update process along the shared segment and to possibly mark installed state along the old segment for deletion. When the MN receives the message it again has to install state along the new segment towards the DCOR. The mobile node might also trigger the deletion of resources along the old segment together with this state creation (pessimistic delete). The optimistic delete operation is certainly more error prone. As it can easily be seen from the description many assumptions have to be made in order for this signaling exchange to work. Hence, as a generic solution this approach is certainly not suggested. We included this scenario for completeness. Manyfolks et al Expires July 2004 [Page 44] Internet-Draft Mobility and Internet Signaling January 2004 MN DCOR CN [ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~> ] + [ TRIGGER (e.g., MIP) ] | | ------<-----<------<------<------<------<------< | ACTION (CN is authz) | +--------------------+ +-----------------+ | | Action:optimistic | | Action: | | | 'delete' along | | 'update' along)| | | old segment) | | shared segment)| | +--------------------+ +-----------------+ | >------>------>----------->------>------>------- | +-----------------+ ACK | | Action: | | Action | 'create' along)| | | new segment) | | +-----------------+ | <------<------<------- | +-------------------+ | | Action:pessimistic| | | 'delete' along) | | | old segment) | | +-------------------+ | | ===============================================> | Traffic + Figure 12.6: CN uses installed state to route message backward Questions: - Similarly as before the security properties of the trigger message need to be evaluated. - It is not always possible to route the message backward from the CN to the MN: a) state at the new path might not be established (hence the signaling message cannot travel backward) b) the signaling message might not reach the MN via the old segment. In the multi-homing case where the mobile node can be reached via more than two paths it is possible to execute this exchange. The same might be true for some local repair cases. - The messages triggered by the MN (namely create state along the new segment and the pessimistic 'delete along the old segment) still need to be executed on behalf of the CN. Compared to the first variant there might be some room for optimization since the first message was transmitted by the CN. Manyfolks et al Expires July 2004 [Page 45] Internet-Draft Mobility and Internet Signaling January 2004 12.1.3. MN and CN are authorized If we argue that the authorization at the NSLP layer is somehow tight to the authorization issues discussed in this section (i.e., authorization for certain protocol actions) then we also have to consider the case where both nodes (MN and CN) have to contribute their part to the authorization decision. This situation appears for example in the NAT/Firewall signaling case but also in the area of QoS reservation where both parties might need to share costs. If both end hosts are authorized then some signaling message exchanges are less difficult since the trigger message does not need to include authorization information. Some problems, however, do not disappear such as the session ownership problem and additional problems might be caused by certain solution approaches. Since this section does not discuss solutions the reader is referred to the [sid] draft which lists a few strawman proposals for addressing the session ownership problem. 12.2. CN as data sender In this section we consider the scenarios where the CN acts as a data sender. Except for some minor issues we believe that the requirements caused by the signaling exchanges are mostly discussed in Section 1.3 already. new segment +--+ +---+ new flow new |MN|<<<<<<<<<<|NAR|<<<<<<<<<<<<<^ address +--+ +---+ ^ ^ +----+ +--+ | |UCOR|<<<<<<<<<<|CN| | | |<<<<<<<<<<| | | +----+ +--+ | +--+ +---+ V shared original |MN|<<<<<<<<<<|OAR|<<<<<<<<<<<<----->----->------>------>------>------>------> | ACK (along new path) | | <=============================================== + Traffic Figure 12.8: CN as data sender is authorized Since the mobile node first detects the route change. A trigger to the CN allows the CN to quickly react on the route change. There are two variants: 1) The MN sends a trigger to CN and CN starts signaling flow as shown in Figure 12.8. 2) The MN routes the message back along the reverse path using the previously established state along the old route. This mechanism only works if the MN is able to send messages along the old path. As a generic mechanism this is not suggested. 3) An intermediate node act on its own. This might be possible that the UCOR is an entity which participates in the mobility signaling (e.g., MAP) exchange. Depending on the message exchange it needs to be studied whether the signaling message provides sufficient Manyfolks et al Expires July 2004 [Page 47] Internet-Draft Mobility and Internet Signaling January 2004 authorization to trigger the NSIS exchange. 12.2.2. MN is authorizing entity In this scenario we consider the case where the CN is the data sender but the MN authorizes actions. The considerations are similar to those elaborated in Section 1.3.2 where the MN is the data sender but the CN is the authorizing entity. 12.3. Multi-homing Scenarios Multi-homing scenarios have the property that the more than one path belongs to a signaling session. In Figure 12.9 the MN uses two interfaces to route NSIS message towards the CN. Both individual sessions are tight together with the same session identifier. The MN needs to indicate that both reservations need to be kept alive (and the DCOR should not delete a reservation). At the shared segment only a single reservation is stored. From an authorization point of view the session ownership issues is applicable since the DCOR needs to merge the two reservation into a single one along the shared segment. 12.3.1. MN as data sender This section shows the multi-homing scenario with the MN as a data sender. segment 2 +---+ ^>>>>>>>>>>>>>>>| AR|>>>>>>>>>>>>>V ^ +---+ V +----+ +----+ +--+ | MN | |DCOR|>>>>>>>>>>|CN| |UCOR| | |>>>>>>>>>>| | +----+ +----+ +--+ v +---+ ^ shared v>>>>>>>>>>>>>>>| AR|>>>>>>>>>>>>>^ segment +---+ segment 1 ===============================================================> Traffic Figure 12.9: Multi-homed MN as data sender If the MN is the authorizing entity then the session ownership problem needs to be solved. Without solving this type of authorization problem it is possible for an adversary to "join" the reservation at the shared segment. Furthermore, it is an open issue whether reservation merging is allowed only for cases where one flow identifier is used at different interfaces or even with different Manyfolks et al Expires July 2004 [Page 48] Internet-Draft Mobility and Internet Signaling January 2004 flow identifiers. If the CN is the authorizing entity then, again, some message needs to be sent from the CN to the MN to trigger the exchange or to route the request backward along the established path. The MN is reachable via the two paths. Mobility handling might be smoother since it is possible that only one interface experiences an IP address change with all the previously discussed implications. 12.3.2. CN as data sender This section shows the multi-homing scenario with the CN as a data sender. The scenario is simpler (for the CN authorizing case) than the one described in Section 1.5.1 since the signaling message along the shared segment travels the previously established path. This scenario is similar to the route change scenario. At the mobile node itself the two paths merge which again leads to a session ownership problem. How should the MN know whether a signaling message with the same session identifier appearing at a new interface belongs to the indicated session authorized by the CN. If the MN is the authorizing entity then again communication between the end hosts is required as a trigger. Reverse routing might, in some cases, also be possible. segment 2 +---+ v<<<<<<<<<<<<<<<| AR|<<<<<<<<<<<<<^ v +---+ ^ +----+ +----+ +--+ | MN | |UCOR|<<<<<<<<<<|CN| |DCOR| | |<<<<<<<<<<| | +----+ +----+ +--+ ^ +---+ v shared ^<<<<<<<<<<<<<<<| AR|<<<<<<<<<<<< ----\ +--+ | Router(pAR)| < \ | +------------+ +-------------+ | moving ^ IP |Correspondent| | |NSIS-CTP Core |Node (CN) | V | Network +-------------+ v / +------------+ / +--+ | new | NSIS < / |MN| ---------- | Access | ------ > ----/ +--+ | Router(nAR)| < +------------+ Figure 12.11: Context Transfer For the signaling message exchange in the predictive and non- predictive CT mode it can be seen that the assumption is made that the MN is the authorizing entity. A communication with the CN does not take place and would certainly increase the complexity of the protocol exchange. The authorization properties of the Context Transfer procedure (and some micro-mobility schemes) need to be studied in more detail to see their implications for security. The context transfer procedure seems to provide a simple solution for some session ownership problems (in case that the MN is authorized). 12.5. Proxy Scenario The proxy scenarios refers to those cases where one of the end hosts or even both end hosts are not NSIS aware. Two security implications need to be studied. First, there is an authorization issue with regard to the NSLP application. For QoS signaling the end host (and the user) has to authorize the QoS reservation since the reservation might require the user is charged for it. Since the end host is not NSIS aware some Manyfolks et al Expires July 2004 [Page 50] Internet-Draft Mobility and Internet Signaling January 2004 other mechanism or protocol needs to be available with provides this functionality. For NAT/Firewall signaling delayed authorization assures that both end hosts authorize the packet filter creation at their local networks (particularly in case of missing trust relationship between intermediate networks). Second, the authorization issues which relate to the session ownership problem also need to be studied. Since the session ownership issues are a related to the signaling participating nodes and not to the users or the true end points we think that it does not lead to complications. This is, however, only true if we assume that authorization at the NSLP and authorization decisions for the signaling message handling is decoupled. 12.6. Implications for the costs of a QoS reservation It is obvious that mobility support within NSIS raises security issues. A number of mobility scenarios with impacts on security are discussed in Section 7 of [NSIS-AAA]. Even if the signaling message exchange is restarted from scratch (i.e., using a new flow-ID), security handling within NSIS is affected. This type of processing is, however, mostly not a topic for this draft. 12.6.1. Missing Cost Control A large number of service providers (e.g., wireless LAN hot spots) with complex roaming agreements create a non-transparent cost structure. In a traditional subscription-based scenario, users are subscribed to their home network and use this trust relationship to dynamically establish a financial settlement between the visited network and the home network. Additionally, security associations are dynamically established as part of this procedure. This is the typical AAA deployment scenario. In these scenarios users do not learn the identity of the access network as part of a regular authentication and key exchange protocol message exchange. The identity of the access network is possibly never revealed (in a secure fashion). The user is therefore only authenticated to the home network (and hopefully vice versa). While issuing a QoS reservation request to the next NSIS peer (for example in the access network), the end host is typically unaware of the cost of such an end-to-end QoS reservation. Without knowing the costs it is not possible to reject a too expensive QoS reservation. Currently there is no standardized protocol available which allows users to communicate cost limits, to request cost information for network resources or to learn already accumulated costs for a particular reservation. Especially in mobility environments - where an end host is likely to have access to different networks within a short time period - cost control is even more complicated. Manyfolks et al Expires July 2004 [Page 51] Internet-Draft Mobility and Internet Signaling January 2004 Some protocol proposals try to merge existing mobility protocols with QoS signaling (i.e., a form of in-band signaling). Thereby the access network is queried (towards the crossover router or the MAP) for the possibility of making a QoS reservation (without actually making the reservation itself). Without a query mechanism, a user cannot take reservation costs into account when choosing between different access networks (or different access routers). Hence, the user might be able to refuse a more expensive service provider. The ability to allow a user to choose between different providers might be required - not only because of the availability of different access technologies (e.g., IEEE 802.1x, Bluetooth, UTRAN) and different service quality offered, but also for cost reasons. Although real-time notifications of QoS reservation costs (cost control) to the user are out of the scope of NSIS, some interaction might be required. 12.6.2. Implications for Price Determination The problem of determining the price of a QoS reservation has been mentioned in [NSIS-AAA] and closely relates to integrating the end host into the process of authorization. Even if the end host is aware of the price of a QoS reservation during reservation setup the price might change for a number of reasons: o First, mobility in general causes a different path to be chosen and might therefore require a new price determination. End host mobility is visible to the end host itself, therefore the appropriate actions can be triggered by the end host to always determine the correct price. o Route changes somewhere along the path, e.g., mobility in NEMO networks or even mobility in ad-hoc networks, create more problems, since the route change might not be visible for the end host. If price determination is based on the number of networks traversed and intermediate nodes which contribute to the total price of a QoS reservation, then a periodic price query is necessary. Discussions at the NEMO mailing list already point to this problem [Nemo-ML]. If the price of QoS reservation is associated with the authorization itself, then a periodic re-authorization based on the change of prices or on the accumulated costs is necessary. 12.7. Conclusion This security considerations section illustrates the importance of authorization for NSIS in a mobility environment. Performance is important in mobility environments. Proper security handling accounts for a high percentage of the total performance. It is important to consider this aspect in the analysis of mobility proposals. From the scenarios we can observe the following issues: Manyfolks et al Expires July 2004 [Page 52] Internet-Draft Mobility and Internet Signaling January 2004 - Signaling in the direction of the data path is simpler than in the opposite direction. - There are many similarities between the scenarios in Section X (MN as data sender) and Section Y (CN as data sender) particularly if we include multi-homing scenarios. - Most issues are related to authorization problems that appear after the initial flow setup took place. In this case we speak about the following problem: "Is an entity allowed to perform the indicated action." Only a few problems are related to authorization problems which already appear during the initial signaling message exchange. - If the data sender triggers the signaling message exchange and also provides authorization then the complexity can be kept fairly low. - NSLP authorization decisions should be treated separately from authorization decisions which affect the signaling message exchange. In the [SID] draft we tried to raise the question of a possible security goal. We list a few variations of this goal: Version 1: An off-path adversary MUST NOT be able to inject messages which are then accepted by NSIS nodes along the path. An NSIS node which once was along the data path is not treated as an adversary. Version 2: Only end points MUST be able to create messages and intermediate NSIS nodes MUST be able to verify them. Version 3: Only the session creator MUST be able to create messages which are then successfully verifiable by intermediate NSIS nodes. Based on the first version of the goal it might be necessary to differentiate between NSIS nodes which are currently part of the signaling chain (i.e., nodes which are currently part of the NSIS signaling message processing) and NSIS nodes which previously were part of this chain. Furthermore, it might be useful to differentiate between different messages: - Refresh, delete or update messages: I assume that these messages are not idempotent and hence previous state along some nodes has to be established already. To provide security for the 'different peer' case it might still be required to provide some security for the session identifier. This issue is, however, not as dangerous as the threat described in the SID draft. Manyfolks et al Expires July 2004 [Page 53] Internet-Draft Mobility and Internet Signaling January 2004 - Create messages: This message is particularly dangerous since it requires (in case of a sender-initiated message) no previous state. The threat description in the SID draft is immediately applicable. A receiver-initiated signaling message is, from a session identifier point of view, better since previously created state can be used. This might provide some security, although not too much considering the limited capabilities of the responder to truly provide some additional authorization capabilities (due to missing end-to-end security protection or in case of signaling proxies). - Query alike messages: These message types require little protection since they do little harm to the state. They still might allow an adversary to gain information about the reserved resources. - Error messages: These messages are also sensitive but are typically returned after a request was submitted. This is, however, not true for asynchronous error messages. Still some state has to be created to allow routing along the established path. Currently, this analysis does not consider the different message types. As a final conclusion we must state that more discussion is necessary to address security and mobility handling in an appropriate way. Particularly, the expected NSIS signaling behavior must be described. The improvements due to mobility functionality within NSIS must be compared with the increased complexity. Careful analysis and performance evaluations are necessary. 13. Contributors This draft initially written by Roland Bless, Xiaoming Fu, Robert Hancock, Seong-Ho Jeong, Cornelia Kappler, Sung-Hyuck Lee, Jukka Manner, Paulo Mendes, and Hannes Tschofenig. 14. Acknowledgments This draft is based on four earlier drafts by (in alphabetical order) Jongho Bang, Roland Bless, Xiaoming Fu, Robert Hancock, Seong-Ho Jeong, Cornelia Kappler, Sung-Hyuck Lee, Byoung-Joon Lee, Jukka Manner, Paulo Mendes, Henning Schulzrinne, Charles Q. Shen, and Hannes Tschofenig. 15. Informative References [mipv4] Perkins, C., "IP Mobility Support for IPv4," RFC 3344, Aug. 2002. [mipv6] Johnson, D., Perkins, C. and J. Arkko, Mobility Support in IPv6, draft-ietf-mobileip-ipv6-24 (work in progress), June 2003. Manyfolks et al Expires July 2004 [Page 54] Internet-Draft Mobility and Internet Signaling January 2004 [lmm] Carl Williams, "Localized Mobility Management Requirements", draft-ietf-mipshop-lmm-requirements-00 (work in progress), Oct 2003. [fmip] Koodli, R., "Fast Handovers for Mobile IPv6", draft-ietf-mipshop-fast-mipv6-00 (work in progress), Oct 2003. [hmipv6] Soliman, H., Castelluccia, C., Malki, K. and L. Bellier, "Hierarchical Mobile IPv6 mobility management (HMIPv6)", draft-ietf-mipshop-hmipv6-00 (work in progress), Oct. 2003. [nsis-fw] Hancock, R. and et al., "Next Steps in Signaling: Framework", draft-ietf-nsis-fw-04 (work in progress), Sept 2003. [ntlp] Schulzrinne, H. and R. Hancock, "GIMPS: General Internet Messaging Protocol for Signaling", draft-ietf-nsis-ntlp-00 (work in progress), Oct. 2003. [nsis-req] Brunner, M., "Requirements for Signaling Protocols", draft-ietf-nsis-req-09 (work in progress), August 2003. [nsis-analysis] Manner, J., Fu, X. and P. Pan, "Analysis of Existing Quality of Service Signaling Protocols", draft-ietf-nsis-signalling-analysis-03 (work in progress), Oct 2003. [RFC2205] Braden, R., Zhang, L., Berson, S., Herzog, S. and S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", RFC 2205, Sep 1997. [RFC2746] Terzis, A., Wroclawski, J. and L. Zhang, "RSVP Operation Over IP Tunnels", RFC 2746, January 2000. [RFC3583] Chaskar, H., "Requirements of a Quality of Service (QoS) Solution for Mobile IP", RFC 3583, September 2003. [manner02] Manner, J., Lopez, A., Mihailovic, A., Velayos, H., Hepworth, E. and Y. Khouaja, "Evaluation of mobility and QoS interaction", Computer Networks vol.38, no.2, pp.137-163, February 2002. [Seamoby-terms] Jukka Manner, Markku Kojo (editors) Mobility Related Terminology Internet Draft (work in progress), November, 2003. [RFC2961] Berger, L., Gan, D., Swallow, G., Pan, P., Tommasi, F. and S. Molendini, "RSVP Refresh Overhead Reduction Extensions", RFC 2961, April 2001. [I-D.schulzrinne-nsis-casp] Schulzrinne, H. and et al., "CASP - Cross-Application Signaling Protocol", draft-schulzrinne-nsis-casp-01 (work in progress), March 2003. [fu03] Fu, X., Schulzrinne, H. and H. Tschofenig, "Mobility Support for Next-Generation Internet Signaling Protocols", Proceedings of IEEE Vehicular Technology Conference 2003-Fall, October 2003. Manyfolks et al Expires July 2004 [Page 55] Internet-Draft Mobility and Internet Signaling January 2004 [I-D.ietf-nsis-qos-nslp] Van den Bosch, S. and et al., "NSLP for Quality-of-Service signaling", draft-iet f-nsis-qos-nslp-00 (work in progress), September 2003. [I-D.westphal-nsis-qos-mobileip] Westphal, C. and H. Chaskar, "QoS Signaling Framework for Mobile IP", draft-westphal-nsis-qos-mobileip-00 (work in progress), June 2002. [SID] Tschofenig, H. et al.: "Security Implications of the Session Identifier", , (work in progress), June 2003. [CTP-Interop] "A Framework for Interoperation between NSIS and CTP", , (work in progress), October, 2003. [NSIS-AAA] Tschofenig, H., et al.: "NSIS Authentication, Authorization and Accounting Issues", , (work in progress), March 2003. [NSIS-Authz] Tschofenig, H., et al.: "QoS NSLP Authorization Issues", , (work in progress), June 2003. [Nemo-ML] Alper, Y., "[nemo] AAA and NEMO", discussion in the IETF Nemo Mailing List (available at: http://www.nal.motlabs.com/pipermail/nemo/2003-February/000271.html), February 2003. [Lee01] S.-H. Lee, and et al., "Mobility Functions in the QoS NSLP", Internet Draft, Work in progress, October 2003. [Jeong01] S.-H. Jeong, and et al., "Mobility Functions in the NTLP", Internet Draft, Work in progress, October 2003. [I-D.thomas-nsis-rsvp-analysis] Thomas, M., "Analysis of Mobile IP and RSVP Interactions", draft-thomas-nsis-rsvp-analysis-00 (work in progress), November 2002. 16. Author's Addresses Questions about this document may be directed to: Roland Bless Institute of Telematics, Universitaet Karlsruhe (TH) Zirkel 2 76128 Karlsruhe Germany EMail: bless@tm.uka.de URI: http://www.tm.uka.de/~bless/ Manyfolks et al Expires July 2004 [Page 56] Internet-Draft Mobility and Internet Signaling January 2004 Xiaoming Fu University of Goettingen Telematics Group Lotzestr. 16-18 Goettingen 37083 Germany E-Mail: fu@cs.uni-goettingen.de Robert Hancock Siemens/Roke Manor Research Ltd Romsey, Hants, SO51 0ZN United Kingdom Voice: +44-1794-833601 Fax: +44-1794-833434 E-Mail: robert.hancock@roke.co.uk Seong-Ho Jeong Hankuk University of FS 89 Wangsan, Mohyun Yongin-si, Gyeonggi-do 449-791 Korea Phone: +82 31 330 4642 E-Mail: shjeong@hufs.ac.kr Cornelia Kappler Siemens AG Siemensdamm 62 Berlin 13627 Germany EMail: cornelia.kappler@siemens.com Sung-Hyuck Lee SAMSUNG Advanced Institute of Technology San 14-1, Nongseo-ri, Giheung-eup Yongin-si, Gyeonggi-do 449-712 KOREA Voice: +82-31-280-9585 Fax: +82-31-280-9569 E-Mail: starsu.lee@samsung.com 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 Paulo Mendes DoCoMo Communications Laboratories Europe GmbH Landsberger Str. 312 80687 Munich, Germany Manyfolks et al Expires July 2004 [Page 57] Internet-Draft Mobility and Internet Signaling January 2004 Voice: +49-89-56824-226 Fax: +49-89-56824-300 E-mail: mendes@docomolab-euro.com Hannes Tschofenig Siemens AG Otto-Hahn-Ring 6 81739 Munich Germany EMail: Hannes.Tschofenig@siemens.com 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. Manyfolks et al Expires July 2004 [Page 58]