idnits 2.17.00 (12 Aug 2021) /tmp/idnits9093/draft-manyfolks-signaling-protocol-mobility-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. == There is 1 instance of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 2676: '...f-path adversary MUST NOT be able to i...' RFC 2119 keyword, line 2682: '... Only end points MUST be able to creat...' RFC 2119 keyword, line 2683: '... nodes MUST be able to verify them....' RFC 2119 keyword, line 2687: '... session creator MUST be able to creat...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 1346 has weird spacing: '...^ uuuu u t...' == Line 1347 has weird spacing: '...+--+sss uuu...' == Line 1362 has weird spacing: '...+--+sss uuu...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'MN' is mentioned on line 1364, but not defined == Missing Reference: 'QoS-NSLP' is mentioned on line 1890, but not defined == Missing Reference: 'HMIPv6' is mentioned on line 1194, but not defined == Missing Reference: 'HMIPv4' is mentioned on line 1194, but not defined == Missing Reference: 'GIMPS' is mentioned on line 1278, but not defined == Missing Reference: 'FMIP' is mentioned on line 1772, but not defined == Unused Reference: 'RFC2746' is defined on line 2785, but no explicit reference was found in the text == Unused Reference: 'RFC3583' is defined on line 2788, but no explicit reference was found in the text == Unused Reference: 'I-D.schulzrinne-nsis-casp' is defined on line 2803, but no explicit reference was found in the text == Unused Reference: 'I-D.westphal-nsis-qos-mobileip' is defined on line 2815, but no explicit reference was found in the text == Unused Reference: 'NSIS-Authz' is defined on line 2832, but no explicit reference was found in the text -- No information found for draft-iet - is the name correct? Summary: 4 errors (**), 0 flaws (~~), 17 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force Roland Bless 2 Internet-Draft Xiaoming Fu 3 Expires: July, 2004 Robert Hancock 4 Seong-Ho Jeong 5 Cornelia Kappler 6 Sung-Hyuck Lee 7 Jukka Manner, Ed. 8 Paulo Mendes 9 Hannes Tschofenig 10 January, 2004 12 Mobility and Internet Signaling Protocols 13 15 Status of this Memo 17 This document is a submission to Next Steps in Signaling Working 18 Group. Comments should be submitted to the nsis@ietf.org mailing 19 list. 21 Distribution of this memo is unlimited. 23 This document is an Internet-Draft and is in full conformance with 24 all provisions of Section 10 of RFC2026. Internet-Drafts are working 25 documents of the Internet Engineering Task Force (IETF), its areas, 26 and its working groups. Note that other groups may also distribute 27 working documents as Internet-Drafts. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 The list of current Internet-Drafts can be accessed at 35 http://www.ietf.org/ietf/1id-abstracts.txt. 37 The list of Internet-Draft Shadow Directories can be accessed at 38 http://www.ietf.org/shadow.html. 40 Copyright Notice 42 Copyright (C) The Internet Society (2004). All Rights Reserved. 44 Abstract 46 IP mobility, which in its simplest form includes routing changes, can 47 have major influence e.g. on the protocols designed within the NSIS 48 Working Group. This draft is a first step in helping us to decide on 49 how the problems caused by mobility should be handled within Internet 50 signaling protocols, and a stimulus to further security work. 52 Table of Contents 54 1 Introduction ................................................. 3 55 2 Terminology .................................................. 4 56 3 Framework .................................................... 6 57 3.1.1 Global Mobility .......................................... 7 58 3.1.2 Other Global Mobility Approaches ......................... 8 59 3.1.3 Global Mobility Procedures ............................... 8 60 3.2 Local Mobility Management .................................. 9 61 3.3 Context Transfer and Candidate Access Router Discovery ..... 9 62 3.4 Examples of handovers ...................................... 10 63 3.5 Short Problem Statement .................................... 13 64 4 Cross-over Node Discovery and Path Update .................... 14 65 4.1 Background ................................................. 14 66 4.2 Crossover Node Discovery ................................... 15 67 4.2.1 Types of Crossover Node .................................. 15 68 4.2.2 Determination of Crossover Node .......................... 16 69 4.3 Path update ................................................ 19 70 4.3.1 State Setup and Update ................................... 19 71 4.3.2 State Teardown ........................................... 20 72 4.4 Effect of generic routing changes .......................... 21 73 4.4.1 CRN discovery ............................................ 21 74 4.4.2 Path Update .............................................. 22 75 4.5 Open Issues ................................................ 22 76 5 Dead Peer Discovery (DPD) .................................... 23 77 5.1 Overview ................................................... 23 78 5.2 Failure Cases and Impact of Dead Peers ..................... 23 79 5.2.1 Failure Cases ............................................ 23 80 5.2.2 Impact of Dead Peers ..................................... 24 81 5.3 DPD procedures in NTLP ..................................... 25 82 6 Case Examples ................................................ 26 83 6.1 NSIS in the hard-handover case ............................. 26 84 6.1.1 Signaling on the Unchanged Path .......................... 28 85 6.1.2 Signaling on the New Path ................................ 28 86 6.1.3 Signaling on the Old Path ................................ 28 87 6.1.4 Interaction between NTLP and NSLP Signaling .............. 29 88 6.1.5 Routing of NTLP messages ................................. 29 89 6.2 Example of Signaling of an Anticipated Handover ............ 31 90 7 Multihoming-related Issues ................................... 32 91 8 Interactions with Mobility Signaling ......................... 32 92 8.1 Mobility Management Protocols .............................. 32 93 8.2 Interactions with Seamoby Protocols ........................ 35 94 9 Additional issues ............................................ 36 95 9.1 Both End-Hosts are Mobile .................................. 36 96 9.2 Uni- and Bi-directional State Establishment ................ 37 97 9.3 State Management ........................................... 37 98 9.4 State establishment in Network Mobility .................... 38 99 10 Guidelines for Designers of new NSLPs ....................... 39 100 11 Summary of Split of functionality ........................... 40 101 12 Security Considerations ..................................... 40 102 12.1 MN as data sender ......................................... 40 103 12.1.1 MN is authorizing entity ................................ 41 104 12.1.2 CN is authorizing entity ................................ 43 105 12.1.3 MN and CN are authorized ................................ 46 106 12.2 CN as data sender ......................................... 46 107 12.2.1 CN is authorizing entity ................................ 47 108 12.2.2 MN is authorizing entity ................................ 48 109 12.3 Multi-homing Scenarios .................................... 48 110 12.3.1 MN as data sender ....................................... 48 111 12.3.2 CN as data sender ....................................... 49 112 12.4 Context Transfer .......................................... 49 113 12.5 Proxy Scenario ............................................ 50 114 12.6 Implications for the costs of a QoS reservation ........... 51 115 12.6.1 Missing Cost Control .................................... 51 116 12.6.2 Implications for Price Determination .................... 52 117 12.7 Conclusion ................................................ 52 118 13 Contributors ................................................ 54 119 14 Acknowledgments ............................................. 54 120 15 Informative References ...................................... 54 121 16 Author's Addresses .......................................... 56 123 1. Introduction 125 The mobility of IP-based nodes incurs route change, usually at edge 126 of the network. Route change may also be caused by reasons other than 127 mobility, such as routing protocol adaptation in response to varying 128 network conditions, or host multihoming. Normal IP mobility (i.e., 129 Macro-mobility) also involves change of mobile node IP addresses. 130 Since IP addresses are usually part of flow identifiers, change of IP 131 addresses implies change of flow identifier. 133 Micro mobility usually does not cause change of the global IP 134 addresses, but affects the routing paths within the local access 135 network. Some Local Mobility Management (LMM) mechanisms may change 136 the IP address assigned to the mobile node within the access network, 137 for example, mechanisms based on a hierarchy of mobility handling 138 routers. Some protocols either use tunneling to forward packets 139 towards the new location of the mobile node, or set and update per- 140 host routing entries in the network, as for instance, ad-hoc routing 141 protocols. 143 This draft addresses mobility-related considerations for NSIS. The 144 goals of this draft are to analyze the effects of mobility on the 145 NSIS Transport Layer Protocol (NTLP) and on the NSIS Signaling Layer 146 Protocol (NSLP), and to make sure there are no initial design 147 mistakes that break the protocols in mobile environments. The NTLP is 148 an application independent protocol to transport service-related 149 information between nodes in a network. Each specific service has its 150 own NSLP protocol. 152 The goals of this draft are not to suggest a design for a separate 153 mobility-specific NSIS protocol or to intentionally delay the current 154 work. We expect that this study will actually speed-up the current 155 work on the NSIS protocols. We do not intend to present specific 156 implementation issues in this document, but rather propose how the 157 NSIS protocols should be designed to work in a mobile environment. 159 A further goal of this draft is to give guidance to people proposing 160 new NSLP protocols. The guidelines in this draft would help those 161 people make sure their NSLP protocols truly work in wired and 162 wireless/mobile environments. Moreover, a goal is to stimulate 163 further discussions related to the security and authentication issues 164 in a mobile environment making use of the NSIS protocols. We expect 165 there to be a common (minimal) set of functions that the NTLP and 166 NSLP need to support. Furthermore, we intend to capture any 167 additional issues that would need specific precautions, e.g. in 168 future NSLPs. 170 The discussion is divided into two parts. The first part discusses 171 the very basic functionality needed within the NTLP and NSLP 172 protocols. We expect these features to be from most parts already 173 available within the NSIS protocols, or at least can be added with 174 little effort. 176 The second part takes the discussions to more specific scenarios, 177 including support for multihoming and inter-working issues with a 178 number of mobility-related protocols. These functions would be looked 179 at once the first versions of the NSIS protocols are finished. 181 2. Terminology 183 For terminology related to wireless and mobile networking, we refer 184 to [Seamoby-terms]. 186 Session 188 A single application layer flow of information between end points 189 that occur during the span of a single connection for which some 190 network control state information is to be manipulated or 191 monitored. IP mobility may cause the mapping between sessions and 192 flows to change, and IP multihoming may mean there is more than 193 one flow for a given session. 195 Session Identifier 197 The identifier used to relate signaling messages to a specific 198 session. 200 Flow 202 A sequence of packets sent from a particular source to a 203 particular (unicast or multicast) destination for which special 204 handling is provided by the combination of header fields. Only 205 unicast, unidirectional flows are considered in this document. 207 Flow Identifier 209 The identifier used to uniquely identify a particular data flow 210 for which the specific service is requested from the network. All 211 packets associated with the same flow will be assigned the same 212 flow identifier by the source. The flow identifier contains 213 information about the flow which should receive a particular 214 treatment, and it may consist of a combination of the typical 215 5-tuple or, for example, source IP address, destination IP 216 address, and flow label in IPv6-based networks. See [I-D.ietf-n 217 sis-fw] for more information. 219 Crossover Node (CRN) 221 A Crossover Node is a node that for a given function is a merging 222 point of two or more separate sets of state information, and not 223 only a physical route splitting point. In the context of this 224 draft, we can distinguish several logical (but not necessarily 225 physically) different CRNs: 227 NTLP CRN, after a routing change, the node closest to the end 228 host from which the NTLP state information towards the CN does 229 not change. 231 NSLP CRN, after a routing change, the node closest to the end 232 host from which the NSLP state information towards the CN does 233 not change. The NSLP CRN may be different for different NSLPs. 235 NSIS CRN, either an NTLP CRN or an NSLP CRN. 237 Upstream CRN, after a handover, the node closest to the data 238 receiver from which the state information towards the data 239 sender does not change. 241 Downstream CRN, after a handover, the node closest to the data 242 sender from which the state information towards the data 243 receiver does not change. 245 Mobility CRN, node at which from the point of view of mobility 246 mgmt old and new paths merge, e.g. MAPs in HMIPv6. Note in 247 general: mobility CRN is may or may not be equal neither to 248 NSLP CRN nor to NTLP CRN. 250 Routing CRN, node at which, using normal routing, old and new 251 paths merge. In case of HMIP, mobility CRN is also routing CRN. 252 However, in case of "normal" MIP with optimized routing, 253 mobility mgmt doesn't know a CRN, whereas routing does. 254 Depending on the location of nodes, the routing CRN may or may 255 not be equal to the NSLP CRN or to NTLP CRN. 257 Path Update 259 The procedure for the re-establishment of NSIS state on the new 260 path, the teardown of NSIS state on the old path, and the update 261 of NSIS state on the common path due to route change or mobility. 262 This is used to improve mobility handling for the affected flows. 264 Upstream Path Update: Path Update for the upstream signaling 265 which is initiated by a signaling initiator on the common path 266 (e.g., a CN, a HA, or a GFA/MAP). 268 Downstream Path Update: Path Update for downstream signaling 269 which is triggered by a signaling initiator on the new path 270 (e.g., MN, mobile agent, or an AR). 272 Dead Peer Discovery (DPD) 274 The procedure for finding a dead NSIS peer due to a link or node 275 failure and due to a mobile node moving away. 277 Downlink 279 The direction from the CN towards the mobile node. 281 Uplink 283 The direction from the mobile node towards the CN. 285 Receiver 287 The node in the network which is receiving the data packets in a 288 flow. 290 Sender 292 The node in the network which is sending the data packets in a 293 flow. 295 NSIS Transport-Layer Protocol (NTLP) 297 Description... 299 NSIS Signaling-Layer Protocol (NSLP) 301 Description 303 Downstream direction 305 Direction from a data source to the destination. 307 Upstream direction 309 Direction from data destination towards its source. 311 3. Framework 313 This section describes various mobility scenarios for the detailed 314 discussions of mobility issues in NSIS signaling, using basic mobile 315 IP (v4 and v6) handover as a starting point... 317 Our assumptions in this document and the framework are: 319 Session-ID is used to index state 321 Even if a mobile node has a permanent IP address (its home 322 address), this cannot be used to index state in the network since 323 the home address may not easily be visible to interior nodes. 324 Other types of mobile nodes (e.g. using SIP or other application 325 layer techniques) may not have permanent addresses at all. After 326 a movement it obtains a new CoA, which is the basis for routing 327 its data. If signaling-associated state is indexed based on some 328 temporary data plane information, such as CoA, the state indexed 329 by previous CoAs might be inaccessible for the signaling after 330 most handover procedures. 332 Double state installation in the unchanged path should be 333 avoided. This can only be done by establishing a relationship 334 between the old and the new flow. This is essentially the same 335 problem faced to tear down state in the old path. 337 Routing may be asymmetric 339 IP packets arriving to and leaving the MN may be routed 340 differently. This may be due to the basic triangular routing of 341 MIPv4, or due to the operation of an LMM protocol, or due to 342 asymmetric routing caused by the basic operation of the IP 343 routing protocols themselves. 345 The CN is not a mobile device 347 We may later add text to consider a mobile CN, too. 349 3.1.1. Global Mobility 351 Each mobile node is always identified by its home address, regardless 352 of its current point of attachment to the Internet. In basic mobile 353 IP, while situated away from its home, a mobile node is also 354 associated with a care-of-address, which provides information about 355 the mobile node's current location. After a mobile node registers its 356 (primary) care-of address with a router on its home link, known as 357 ``home agent'', data packets addressed to the mobile node's home 358 address are routed to its care-of-address using IP-in-IP 359 encapsulation in the home agent (known as "mobile IP tunneling"). A 360 mobile node can also register with the corresponding node, and then 361 data packets addressed to the mobile node's home address are either 362 IP-in-IP encapsulated (in mobile IPv4) or routed using routing header 363 to its care-of-address (in mobile IPv6). Data packets sent by the 364 mobile node to the corresponding node can be either directly routed 365 to the destination's IP address, or routed through the home agent via 366 a reverse tunnel (if reverse tunnel is used). Here, the following 367 characteristics are important for support of NSIS signaling: 369 3.1.2. Other Global Mobility Approaches 371 Other approaches to provide global mobility work in the same generic 372 way as MIP, but having a globally unique identifier for the MN, and 373 then using an out-of-band signaling mechanism to provide the current 374 location of the MN to the requesting party. For example, approaches 375 based on DNS updates provide the globally unique DNS name, and the an 376 up-to-date physical location of the MN. Another example is SIP, where 377 users have globally unique identifiers, e.g. names, and the system is 378 able to provide to the caller the current physical location of the 379 called party. 381 3.1.3. Global Mobility Procedures 383 1) A flow associated with a mobile node, either sent or received by 384 the mobile node, may continue to desire signaling services after a 385 mobile IP handover. NSIS needs to be able to signal for such flows 386 upon a mobile node's movements. 388 2) Either the sender or the receiver of a mobile node's flow can 389 initialize an NSIS signaling. It is essential to require the NSIS 390 signaling initiator to be authorized to initialize the 391 signaling. Note that nodes within the network may also initiate 392 NSIS signaling for the given session, for example, to handle route 393 changes in the middle of the network, or to support seamless 394 handovers. 396 3) The paths for a mobile node's outgoing traffic to the 397 corresponding node and incoming traffic from the corresponding 398 node may differ from each other. 400 4) Data traffic, in either direction between a mobile node and the 401 corresponding node, can be routed directly, routed indirectly 402 using a routing header, or IP-in-IP encapsulated, or the 403 combination of them in different segments of the data 404 transmission, depending on the mobility mode (route optimization 405 or triangle routing; use reverse tunneling or not; mobile IPv4 or 406 IPv6; whether LMM is used; etc.). 408 5) A mobile node's handover can be either intra-domain (inside one 409 access network domain) or inter-domain (from one access network 410 domain to another), which mainly concerns with topology 411 information exchange, authorization and accounting issues. This is 412 elaborated in Section 10.7 in [nsis-req]. 414 6) A mobile node can support multiple care-of-addresses at one time, 415 if it is connected to multiple access networks 416 simultaneously. Although only one primary care-of-address will be 417 used for routing traffic from the corresponding node to the mobile 418 node, this multi-homing feature potentially can be used to enhance 419 the NSIS signaling performance. 421 3.2. Local Mobility Management 423 Localized mobility management [lmm] mechanisms reduces the latency in 424 mobility management signaling upon Care of Address change. These 425 schemes, such as fast handover [fmip] and hierarchical mobile IPv6 426 [hmipv6], complicates the features identified in Section 3.1, for 427 example, by associating new scoped care-of-addresses for a mobile 428 node, and introducing one or more IP-in-IP encapsulated segment(s) in 429 the path traversed by the communicating traffic. The additional CoA 430 and IP-in-IP tunnels have implications for both the NTLP and NSLP. 431 For example, NTLP needs to decide to perform tunnel handling when 432 such tunnels exist in the same path that NTLP messages also traverse, 433 while NSLP states may be updated according to the updated CoA in the 434 localized domain. A discussion of these advanced characteristics is 435 detailed in Section 11. 437 3.3. Context Transfer and Candidate Access Router Discovery 439 The NSIS protocol suite should be able to operate independently of 440 Seamoby protocols such as Context Transfer Protocol (CTP) and 441 Candidate Access Router Discovery (CARD). Significant performance 442 gains can be achieved if NSIS signaling can interact with such 443 protocols. 445 When a mobile node has a choice of Candidate Access Routers (CARs) to 446 perform handover, the Candidate Access Router Discovery (CARD) 447 procedure can be used to identify those CARs along with their 448 capabilities (for instance, QoS resource availability). In NSIS 449 terminology, CARD can be used to find an appropriate NSLP-aware New 450 AR (NAR), and the path leading to the node, where the NSLP state 451 could be installed. 453 The Context Transfer Protocol (CTP) is used to transfer the NSLP 454 state from the Previous AR (PAR) to NAR. When CTP is used, service- 455 aware contexts could be quickly re-established in the NAR without 456 requiring the MN to explicitly perform all protocol flows for those 457 services from scratch. NSLP information, such as QoS state, can be 458 transferred using CTP. However, this also concerns the NTLP because 459 the context transfer for NSLP states takes place between PAR and NAR, 460 which is vertical to the direction of normal NSIS signaling (which is 461 between MN and CN). 463 With the help of CARD and CTP, NSIS signaling can quickly re- 464 establish the NSLP state on the new path by reducing the state re- 465 setup delay. However, making use of the CARD and CT protocols 466 requires the ability from NTLP/NSLP to do (at that stage) off-path 467 signaling on-behalf of the MN; this has implications on the 468 authorization of signaling. 470 3.4. Examples of handovers 472 The discussions in this document focus on the effects a mobile end 473 host can have on NSIS signaling. The fundamental concern in handover 474 events is how the signaling can be localized in order to minimize the 475 latency of setting up resources on a new path. Here one of the 476 critical issues is the location and operation of a cross-over node. 477 This section seeks to identify the various scenarios that emerge in 478 different types of handovers and network setups. 480 There are several issues that affect how resources are set up in a 481 mobile environment: 483 1. Is the access router (AR) running 484 a) NTLP, 485 b) NTLP and the NSLP being signaled about, or 486 c) neither of the two protocols? 488 2. Where are the 489 a) NTLP CRN, 490 b) NSLP CRN, 491 c) mobility CRN, and 492 d) routing CRN? 494 3. Does the interface at a given CRN routing towards the MN 495 a) change after a handover, or 496 b) remains the same? 498 4. Are the incoming and outgoing packets from the MN 499 a) routed through the same routing path (symmetric), or 500 b) through different paths (asymmetric routing)? 502 Note here, that the NSLP protocol can not be run without the 503 transport part of the protocol, the NTLP. 505 Figure 3.1 presents possible setups in an access network that 506 supports NTLP and NSLPs. It is assumed that all MNs in this draft are 507 NSLP aware node. To provide examples of the issues mentioned above, 508 consider the following scenarios: 510 - MN is connected to AR 1 and makes a handover to AR2. If incoming 511 packets are arriving through Path A, the NTLP CRN is router a (RTRa) 512 and its interface changes, and the NSLP CRN is RTRb and its interface 513 does not change. If resources are set up for outgoing packets and the 514 outgoing path changes to Path B due to the network routing table, 515 resources must be set up on this new path, and possibly removed on 516 the old Path A. 518 - MN is connected to AR 2 and makes a handover to AR 3. If packets 519 were flowing, and will still continue to flow, on both directions, 520 through Path B, the NTLP and NSLP nodes after the AR do not change, 521 that is, the interface towards the MN at the NTLP and NSLP CRNs does 522 not change. 524 - MN is connected to AR 8 and makes a handover to AR 7. If data was 525 flowing through Path F before the handover and now flows through Path 526 E, the CRNs are not visible in the figure; RTRj is the first-hop NTLP 527 and NSLP node from the MN and CRNs are somewhere else. If data flows 528 through Path F before and after the handover, there is no NTLP or 529 NSLP CRNs, as RTRm remains the first-hop NTLP and NSLP node. 531 ------ 532 [MN] |NSLP| 533 | |AR 1|\ 534 | ------ \ ------ ------ 535 | \|NTLP| |NSLP| 536 | /|RTRa| --------|RTRb| ------- Path A --- 537 | ------ / ------ ------ 538 V |NSLP|/ 539 |AR 2|\ 540 ------ \ ------ ------ 541 \------ |NTLP| |NSLP| 542 |RTRc| -- |RTRd| -- |RTRe| -- Path B --- 543 /------ ------ ------ 544 ------ / 545 |NSLP|/ 546 |AR 3|\ 547 ------ \ ------ ------ 548 \|NSLP| ------- |NSLP| 549 /|RTRf| |RTRg| ------- Path C --- 550 ------ / ------ ------ 551 |NTLP|/ 552 |AR 4| 553 ------ Administrative Domain 1 554 - - - - - - - - - - - - - - - - - - - 555 ------ Administrative Domain 2 556 |AR 5|\ 557 ------ \ ------ ------ 558 \|NTLP| |NSLP| 559 /|RTRh| ------- |RTRi| ------- Path D --- 560 / ------ ------ 561 ------/ 562 |AR 6| 563 ------\ 564 \ ------ ------ 565 \|NSLP| |NSLP| 566 /|RTRj| ------- |RTRk| ------- Path E --- 567 / ------ ------ 568 ------/ 569 |AR 7| 570 ^ ------\ ------ 571 | \------ |NSLP| 572 | |RTRl| ------- |RTRm| ------- Path F --- 573 | /------ ------ 574 | ------/ 575 | |AR 8| 'AR': Access Router 576 [MN] ------ 'RTRx': Router with id 'x' 577 'NSLP': Node running NTLP and NSLP 578 'NTLP': Node running only NTLP 580 Figure 3.1: Examples of network architectures 582 3.5. Short Problem Statement 584 Based on the discussion in this section, we can highlight some 585 critical issues that need to be solved to allow NSIS protocols to 586 work in a mobile and wireless environment. There are a number of 587 existing signaling protocols [nsis-analysis], however most of them do 588 not support signaling in mobility scenarios, or the support is 589 insufficient. RSVP [RFC2205], for example, relies on flow's fixed 590 source and destination IP addresses, and ports information to 591 identify signaling sessions and how signaling messages are routed. 592 RSVP also lacks an overall consideration of mobile IP features. 594 An NSIS signaling protocol in mobility scenarios needs to consider 595 the following issues: 597 o Change of route and possibly change of MN IP address 599 Topology changes entail the change of routes for data packets sent to 600 or from the mobile node and may lead to a change of host IP 601 addresses. 603 o Latency of route change 605 This change of routing and IP addresses is typically much faster than 606 traditional route change (for example, those due to failure, adding 607 or removal of nodes/links), which makes existing signaling protocols 608 to be either unable to handle or at least create an additional 609 overhead. 611 o Explicit routes 613 Moreover, MIPv6 adds the possibility to define explicit routers, 614 which creates further issues with routing paths. 616 o IP-in-IP encapsulation 618 The possible use of IP-in-IP encapsulation segments in the end-to-end 619 path for routing traffic from the corresponding node to the mobile 620 node (vice versa), associated with a route change of the same 621 mobility behavior, makes signaling in mobility scenarios more 622 complicated. 624 o Localization of state teardown 626 In the case of MN movement, only NSIS state between (former point of 627 attachment of) MN and the NSIS CRN needs to be torn down: The NSIS 628 state between CRN and CN may have to be updated e.g. to reflect a new 629 Flow ID, but in any event it is still needed. Besides, tearing it 630 down may necessitate re-authentication and re- authorization. 631 Complication is added because the NSIS CRN is only known once the 632 NSIS signaling along the new path is completed. 634 o Ping-pong type handover 635 In a ping-pong type handover, the MN returns to the previous AR after 636 staying with the new AR only for a short while. On the one hand, NSIS 637 should remove quickly in order to free resources. On the other hand, 638 in the case of ping-pong type handover, state would need to be 639 reestablished soon again, also adding overhead. 641 O Upstream local repair vs downstream local repair 643 Since upstream and downstream path need not be equal, upstream and 644 downstream CRNs need not be equal, either. In fact, local repair 645 needs to be handled independently for upstream and downstream flows, 646 including, e.g. discovery of upstream and downstream CRN. 648 In summary, NSIS signaling needs to work with basic mobility which is 649 an extension of general route (topology) change, and typically also 650 includes IP address changes, supports mobile IP tunnels and 651 multihoming. Path repair should be localized, and handled 652 independently for upstream and downstream flows. 654 4. Cross-over Node Discovery and Path Update 656 This section discusses how to discover the crossover node (CRN) in 657 general and the role of the CRN (especially in Path Update). This 658 section also discusses how the NAT/FW NSLP affects the CRN discovery. 660 4.1. Background 662 Route change and main characteristics of mobile IP system described 663 in Section 3.5 cause the session path to be changed, and therefore 664 NSIS state needs to be re-established along the new path. In this 665 case, the exiting protocols which do not support signaling in dynamic 666 environment where route change or mobility event occurs can cause the 667 following basic problems: 669 * Double reservation Problem 671 Since the state on the old path still remains as it is after re- 672 establishing the state along the new path due to route change or 673 mobility, the double reservation problem occurs. Although the 674 existing state on the old path can be torn down by timeout of soft 675 state, the refresh timer value in the core or wired network is 676 quite long (e.g., 30 seconds in RSVP). As a result, in case of QoS- 677 NSLP, the double reservation problem leads to the waste of 678 resources and call blocking (especially in mobility scenarios). 679 Therefore, the state along the old path should be removed 680 immediately after state is set up on the new path. 682 * End-to-end signaling Problem 684 End-to-end signaling has to be considered as the issue-must-be- 685 avoided in mobility scenarios, because it causes most problems 686 related to service quality, signaling performance, and resource 687 availability. The route change caused by mobility, which 688 complicates QoS signaling more, may result in the change of flow 689 identifier. The change of flow identifier requires state update 690 along the entire path to reflect the physical location of the MN: 691 end-to-end signaling. This also incurs a long state setup delay, 692 signaling overhead, and double reservation which affects network 693 performance. Ultimately, the long state setup delay will 694 particularly gives rise to the service blackout or degradation for 695 multimedia application in the mobility environment. 697 To quickly re-establish NSIS state and improve scalability of NSIS 698 signaling when route change and mobility event occurs, NSIS signaling 699 should be localized, and the localized signaling procedure is 700 referred to as path update (see the terminology section). This is 701 because, although NSLP messages are initiated by an MN or CN and sent 702 to the opposite terminating point of the path, the path in the 703 wireless access network usually changes only partially. Therefore, 704 the NSLP/NTLP should limit the scope of signaling information to a 705 local section of the signaling path. 707 The most appropriate node to do path update can be the CRN which is 708 not a simple route splitting point, but an NSLP-aware merging point 709 where the old and new session paths meet. To minimize the impact on 710 seamless service, the CRN should be discovered by the NTLP as quickly 711 as possible (see Section 4.2.2 for details), and afterward the 712 involved NSLP should be triggered by the NTLP for necessary actions, 713 for example, path update in case of QoS-NSLP. 715 4.2. Crossover Node Discovery 717 4.2.1. Types of Crossover Node 719 There can be various types of CRN according to normal route change, 720 mobility management, signaling states, and flow direction. In the 721 context of NSIS, this section mainly discusses the types of CRN 722 according to NSIS signaling states and flow direction. 724 From the perspective of NSIS states (i.e., NSLP and NTLP sates), the 725 types of CRN are basically divided as follows. First, from the NSLP's 726 point of view, the CRN is a signaling application-aware node in the 727 network where the signaling flows meet. Second, from the NTLP's point 728 of view, it is a network node where more than one NTLP states (e.g., 729 messaging association in [ntlp]). are stored. Although there can be 730 various types of CRN according to state information, the CRN required 731 for QoS-NSLP operation is NSLP CRN which has the corresponding 732 signaling application information to perform the path update. 733 Therefore, the CRN for the path update should be a logical NSLP-aware 734 merging point rather than just a physical route splitting point. This 735 implies that the CRN should not only be NTLP-aware but also NSLP- 736 aware even if a CRN is detected by the NTLP. In this process, the 737 NTLP should know the corresponding signaling application (e.g. QoS- 738 NSLP) at the NSLP layer. 740 The path change of a specific NSLP session flows can be caused by 741 either route change or mobility, so basically there are two different 742 types of merging point in the network according to the direction of 743 signaling flows. The path change of downstream signaling flows may 744 result in forming a downstream crossover node (DCRN) where the 745 logical incoming interfaces start to converge, and the path change of 746 upstream signaling flows may result in forming a upstream crossover 747 node (UCRN) where the logical outgoing interface begins to diverge. 748 Therefore, in general, the path change causes convergence or 749 divergence of packets in data plane and/or in control plane (e.g., 750 considering 3G/4G networks). 752 There are some differences between route change and mobility in 753 forming DCRN and UCRN, and the asymmetric characteristics of routing 754 adds complexity to the CRN discovery. When a generic route change 755 occurs, the path change of signaling flows results in forming a chain 756 of two CRNs, which is referred to as a divergence and convergence 757 pair (see Section 4.4.1). 759 When a mobility event occurs, the asymmetric characteristics of 760 routing between downstream and upstream directions can affect the 761 location of the CRN. For instance, the handover of an MN (as an NI) 762 will create a DCRN, and the handover of an MN (as an NR) will form a 763 UCRN. However, the DCRN and the UCRN may be the same merging point 764 in the network or may be different due to the asymmetric 765 characteristics of routing although a CN is the same. 767 The CRN will be temporarily formed for path update, and how long the 768 CRN will be involved in the path update depends on the period and 769 method of re-establishing NSIS states in mobility scenarios. If 770 sates, for example, are pre-established during handover to support 771 multimedia applications seamlessly, candidate NEs can be ferreted out 772 by interacting with Seamoby protocols. In this case, the candidate 773 CRN(s) also is (are) discovered to localize the signaling to obtain 774 performance gains in the network (see Section 4.2.2). 776 4.2.2. Determination of Crossover Node 778 A CRN can be discovered at both NTLP and NSLP layers. The CRN 779 discovery at the NSLP layer can be done by NSLP signaling messages 780 sent from the signaling initiator. For example, NSLP can realize it 781 is a CRN by comparing the Source Identification Information (SII) 782 contained in the incoming signaling message to that of previously 783 stored in the node. However, in particular, the CRN would want to 784 delete NTLP state when a particular NSLP is not supported there and 785 NTLP state is not needed any more. Therefore, CRN discovery can be 786 considered as an extension to the peer discovery at the NTLP level 787 (e.g., using GIMPS query-response [ntlp]). In general, GIMPS message 788 has message routing state information such as flow/session/signaling 789 application identifier, so signaling application can be identified at 790 the NTLP level. For example, in the connection mode of NTLP, when 791 NTLP establishes messaging association between two adjacent peers, 792 the NTLP peers exchange message routing state information through 793 GIMPS query and response messages. Therefore, although CRN is 794 discovered at the NTLP level, the discovered CRN is actually NSLP- 795 aware node which has a involved signaling application. 797 There can also be two different approaches in CRN discovery according 798 as whether the discovery is coupled with signaling message or not: 799 Coupled approach and separated approach. In this case, the CRN 800 discovery at each NSIS level depends on the used approach (see 801 Section 6.1.4). 803 For CRN discovery, some session information such as the flow 804 identifier and session identifier can be used. In addition, 805 incoming/outgoing interfaces (e.g., Logical Interface Number: LIN) 806 may also be used together with the session information. The CRN 807 discovery can be further divided into UCRN discovery and DCRN 808 discovery according to which node is a signaling initiator. 810 The session identifier in the GIMPS message is used to easily 811 identify the involved session because it remains the same while the 812 flow identifier may (or may not) change due to handover. The flow 813 identifier is used to specify the relationship between the address 814 information and the state re-establishment (e.g., QoS-NSLP state re- 815 establishment). That is, the changed flow identifier indicates 816 topological changes (i.e., old path, new path, and common path) and 817 so the state re-establishment is required. 819 The logical interface number (LIN) can be used to establish or delete 820 NSIS associations between peers. This identifier is also used to 821 determine the CRN. NSIS entities may be able to use the interface 822 number to locally distinguish each logical interface identifier 823 between adjacent NTLP peers. Note that the LIN can be included in the 824 NSIS message, but it can also be considered as an implementation 825 issue. 827 In general, when a route change due to mobility occurs, CRN can be 828 recognized by comparing the existing session information (e.g., the 829 session and flow identifiers) with the session information included 830 in the peer discovery message initiated by an NI (e.g., an MN or a 831 CN) through a different LIN (e.g., an incoming/outgoing LIN). If the 832 session identifier is still the same and the flow identifier and LIN 833 has been changed, the current NSLP-aware node realizes it is the CRN. 834 Note that the node which performs the CRN discovery should check 835 whether the CRN has been discovered or not before realizing it is the 836 CRN. 838 Optionally, a mobility object can also be used to indicate that the 839 MN has experienced a handover and a route change has occurred 840 [Jeong01] [Lee01]. In this case, the NSIS protocol (or node) may need 841 to interact with mobility protocols to detect the CRN immediately. 842 For example, the CRN discovery may need to be triggered in parallel 843 with the transmission of the binding update (BU) message (of MIP). 845 The mobility object may be defined in the NTLP message (e.g., GIMPS 846 payload) to notify any mobility event explicitly, and it contains 847 various mobility-related fields such as handover_init field and 848 mobility_event_counter field. The handover_init field can be used to 849 explicitly inform that a handover is initiated for fast state re- 850 establishment. The mobility_event_counter field can be used to detect 851 the latest handover event to avoid confusion about where to send a 852 confirmation message which indicates that the CRN has been found. 854 This type of confirmation may be needed when the MN moves toward the 855 second new AR immediately after it undergoes a handover to the first 856 new AR from the old AR, because the CRN discovery message from the 857 second new AR may arrive earlier than from the first new AR. The 858 mobility object may also be defined in the NSLP in a similar way. In 859 this case, there should be some relationship between the mobility 860 objects of the NTLP and the NSLP. 862 If an MN is an NI when a route change due to mobility occurs, the MN 863 begins to transmit signaling messages toward a CN in the downstream 864 direction. In this case, an NSLP-aware node recognizes that the 865 session paths converge, and then this node performs the comparison of 866 session information checking the incoming LIN. After determining that 867 the CRN has not been discovered yet, the NSLP-aware node realizes it 868 is the DCRN. 870 When an MN (as an NR) undergoes handover, the UCRN can be determined 871 by checking the outgoing LIN of signaling flow from a CN. In this 872 case, the UCRN should be the first node where the signaling flow 873 begins to diverge. Since UCRN is determined by whether outgoing path 874 diverges or not, the UCRN discovery is more complex than the DCRN 875 discovery. If NSIS operates with HMIPv6 and an MAP is an NSIS-aware 876 node, the UCRN can be locally discovered in an access network by the 877 method above. If the UCRN is discovered between the MN and the MAP, 878 the path update can be actually localized for upstream flows. 879 However, note that when interworking with HMIPv6, it is still an open 880 question how these nodes decide locally whether they are indeed the 881 UCRN. 883 The CRN discovery may also be initiated during handover (i.e., before 884 handover is completed). However, in this case, a more efficient 885 mechanism is needed to find a candidate CRN. For example, after a 886 mobility event is detected by the NTLP, the current AR may use CARD 887 to transfer the context for fast QoS-NSLP state re-establishment. 888 After the candidate AR is found, CTP can be used to transfer the 889 context which includes the QoS-NSLP session information for fast QoS- 890 NSLP state re-establishment. If an appropriate AR is found and the 891 context transfer is completed, a candidate CRN can be discovered 892 easily since the candidate CRN discovery is basically the same as 893 above. 895 In some cases, however, it may not be always possible to use 896 mobility-related protocols such as CT and CARD. In this case, the MN 897 can initiate the CRN discovery only after it changes the point of 898 attachment. To expedite the discovery process, it may be useful to 899 transmit the peer discovery message (by the NTLP) and the first 900 binding update message at the same time. 902 4.3. Path update 904 This section discusses possible procedures for path update according 905 to the direction of signaling flows. As discussed in Section 4.1, the 906 CRN can be a crucial point for path update, since the CRN is the 907 NSLP-aware merging point of the old and new paths. From the 908 perspective of path update, the CRN plays the role of initiating re- 909 installation on the new path, teardown on the old path, and update of 910 NSIS state on the common path. 912 In mobility scenarios, the flow identifier for NSIS signaling may 913 Change. Since the flow identifier is used to identify the signaling 914 state installed along the path, the procedures for path update should 915 include state update along the entire path to reflect the topological 916 change of the MN. The CRN discovery is different according to the 917 direction of signaling flow in mobility scenarios, and the DCRN 918 operates independently of the UCRN although DCRN and UCRN can be 919 simultaneously ferreted in bi-directional state establishment. 920 Therefore, the procedures for path update may differ according to the 921 direction of signaling flows. For downstream signaling, path update 922 is triggered by the MN (or mobile agent) or an AR, which is referred 923 to as Downstream Path Update. For the upstream signaling, path update 924 is initiated by a CN, a HA, or a GFA/MAP, which is referred to as 925 Upstream Path Update. In this case, each signaling initiator has to 926 be authorized for secure signaling. 928 4.3.1. State Setup and Update 930 In both types of path update, NSIS protocol needs to interact with 931 mobility signaling and the Seamoby protocols (during or posterior 932 handover) to obtain performance gains through fast re-establishment 933 of the NSIS states along the new path. In this case, NSIS needs to 934 monitor for detecting the movement through several methods [nsis-fw]. 935 After detecting a mobility event, the NSIS protocol can check 936 resource availability on the new path (or new candidate path) through 937 CARD or other mechanisms during handover in order to check the 938 possibility of state re-establishment on the new path in advance. 940 In the downstream path update, if resource availability is assured, 941 an MN initiates the NSIS signaling for state setup toward a CN along 942 the new path. The DCRN discovery is implicitly done by this type of 943 signaling initiated by the MN. In this case, the node where old and 944 new logical session paths converge realizes that it is the DCRN, and 945 afterward the DCRN sends a response message toward the MN to notify 946 of NSLP state installed (e.g., in QoS-NSLP) or installs the NSLP 947 states as responding the NSLP signaling initiated by the MN (e.g., as 948 in RSVP). In the downstream path update, the sender-initiated 949 approach (e.g., QoS-NSLP) leads to faster setup than the receiver- 950 initiated approach as RSVP. And then, the DCRN sends a refresh 951 message toward the signaling destination to update the changed flow 952 identifier on the common path and also sends a teardown message 953 toward the old AR to delete the NSIS states along the obsolete path. 955 In the case of upstream path update, the CN (or a HA/ a GFA/MAP) 956 sends a refresh message toward the MN to perform path update. UCRN 957 is discovered implicitly by the CN-initiated signaling along the 958 shared path, and the node from which the common path begins to 959 diverge into the old and new logical session paths realizes that it 960 is the UCRN. In this case, the CN should be informed of the movement 961 event using an NSIS signaling message sent by the MN or monitoring 962 the mobility signaling. After the UCRN is determined as described in 963 Section 4.2.2, it may send a refresh message to the MN along the new 964 path while establishing the NSIS association between the updated 965 peers, and afterward the UCRN may send a teardown message toward the 966 old AR to delete the NSIS state on the obsolete path. 968 The state update in control plane on the shared/common path to 969 reflect the changed flow identifier brings issues on the end-to-end 970 signaling. Although the state update does not give rise to re-process 971 AAA and admission control, it may lead to the signaling overhead. If 972 NSIS protocol interacts with Hierarchical Mobile IPv6 scheme, the 973 NSIS session only has the changed flow identifier between an MAP/GFA 974 and an MN. However, whether the update of the flow identifier for the 975 session can be considered only between an MN and an MAP to avoid end- 976 to-end signaling is still an open issue. 978 One of the goals of path update is to avoid double reservations (in 979 case of QoS signaling) on the shared path described in Section 4.1. 980 The double reservation problem may be solved by establishing a 981 signaling association using the unique session identifier. That is, 982 NSLP state can be shared even if different flow identifiers changes. 983 For example, QoS-NSLP state (for resource reservation) can be used by 984 packets for either flow. 986 4.3.2. State Teardown 988 After re-establishment of the NSIS state along the new path, the 989 state on the obsolete path should be quickly removed by path update 990 mechanism to prevent the waste of resources due to double reservation 991 (and resource allocation problem by call blocking) and to reduce the 992 cost of using the resources in the access network as described in 993 Section 4.1. Although the release of the existing state on the old 994 path can be accomplished by timeout of soft state, the refresh timer 995 value may be quite long and the maintenance of the NSIS state on the 996 obsolete path may not be necessary. Therefore, the transmission of a 997 teardown message is particularly preferred to the use of refresh 998 timer to quickly delete the old state. 1000 The CRN is an appropriate point to initiate the teardown toward the 1001 old AR after re-establishment of the state along the new path. In 1002 this case, the release of old state on the obsolete path can be 1003 accomplished by comparing outgoing LINs and through reverse routing 1004 using SII. This can prevent the teardown message from being 1005 forwarding toward along the common path. However, whether the 1006 teardown message can be sent toward the opposite direction to the 1007 state initiating node is still an open question. This also leads to 1008 authorization problem because a node which does not initiate 1009 signaling for establishing the NSIS state can delete the state. 1011 To avoid the waste of resources, the resources on the old path should 1012 be removed as soon as possible after re-establishing the state along 1013 the new path. However, this may not be appropriate for fast handover 1014 of a ping-pong type where an MN may return to the previous AR after 1015 staying at a new AR for a short while. When to delete the state along 1016 the obsolete path remains still an open issue. 1018 If the old AR is the last node due to handover, its NSLP may trigger 1019 an error message to indicate that NSLP messages cannot be forwarded 1020 any further. This error message may cause the removal of the old 1021 states. However, although the error message is initiated, the state 1022 on the old path should not be deleted before re-establishing the 1023 state along the new path. This issue can be solved by using the 1024 handover_init field of mobility object mentioned in Section 4.2.2. 1025 When an MN, for example, detects a handover, the QoS-NSLP of the MN 1026 constitutes the MOBILITY object (the handover_init field) in the QoS- 1027 NSLP signaling message and send it to the current AR (the old AR), 1028 which prevent the current AR from initiating the error message 1029 indicating the dealt with more detail in Section 5. 1031 4.4. Effect of generic routing changes 1033 4.4.1. CRN discovery 1035 In case of generic route change, the CRN can be a node which detects 1036 the change of a data flow in the network. When the downstream or 1037 upstream data flow begins to travel, a node can detect the route 1038 change by interacting with NSIS, routing protocol, and detection 1039 method based on network monitoring, data packet monitoring, or 1040 signaling message monitoring [nsis-fw]. The node detecting the route 1041 change starts to discover the next peer via the NTLP peer discovery 1042 message exchanges and continues to do the peer discovery until 1043 discovering a node which already has the involved NSLP states. 1044 Whenever a new peer is discovered, NSIS creates as an association 1045 with the previous peer using the LINs. 1047 In case of downstream data flow, the first NSLP-aware node where the 1048 signaling flow starts to diverge can be considered as a diverging 1049 DCRN, and the first NSLP-aware node where the signaling flow begins 1050 to converge can be identified as a converging DCRN. As mentioned in 1051 Section 4.2.1, the route change of signaling flows results in forming 1052 a chain of divergence and convergence CRN pair in the network. For 1053 upstream signaling flow, the first NSLP-aware node where the 1054 signaling flow diverges can be considered as a diverging UCRN, and 1055 the first NSLP-aware node where the signaling flow converges can be 1056 identified as a converging UCRN. However, How an NSLP-aware node 1057 identified itself whether the first node which converges and diverges 1058 is CRN is still an open question. 1060 4.4.2. Path Update 1062 In generic route change, since the flow identifier does not change, 1063 state update along the common path is not performed. Therefore, 1064 state re-establishment along the new path and teardown along the old 1065 path are only carried out. There is also no difference between 1066 downstream signaling and upstream signaling compared to mobility 1067 scenarios because the diverging CRN should interact with the 1068 converging CRN for each signaling flow. 1070 In downstream path update, the diverging and converging DCRN pair is 1071 discovered after route change as described in Section 4.4.1. In this 1072 case, the diverging DCRN initiates signaling to establish NSLP states 1073 on the new path toward the converging DCRN by sending the RESERVE 1074 message [QoS-NSLP]. Note that in the coupled approach, peer 1075 discovery is done simultaneously with state re-establishment (see 1076 Section 6.1.4), and so a diverging node and a converging node are 1077 implicitly identified as DCRN. 1079 If each node between the diverging DCRN and the converging DCRN can 1080 not delete their NSLP state for itself (i.e., refresh timer), the 1081 converging DCRN can trigger the removal of the obsolete state by 1082 interworking with the diverging DCRN. Therefore, the converging DCRN 1083 begins to delete the NSIS states on the obsolete path in the reverse 1084 direction (e.g., toward the diverging DCRN) after installing state on 1085 the new path. In this case, the diverging DCRN should be able to 1086 identify that the teardown message (e.g., RESERVE message in [QoS- 1087 NSLP]) from the converging DCRN should not be delivered beyond the 1088 diverging DCRN. For this purpose, the teardown message may have a 1089 "Path Update (PU)" flag in its header field, or the destination 1090 address of the teardown message may be that of the diverging DCRN, 1091 and converging DCRN should know the reverse routing information to 1092 send the teardown message toward diverging DCRN (e.g., using SII in 1093 [QoS-NSLP]). For example, the diverging DCRN can prevent the teardown 1094 message from being forwarded toward a sender by discerning the í—PUí˜ 1095 flag. However, whether the teardown message can be sent toward the 1096 opposite direction to the original state initiator is still an open 1097 question. This also leads to authorization problem because a node 1098 which does not initiate signaling for establishing the NSIS state may 1099 delete the state. 1101 For the upstream path update, the divergence and convergence UCRN 1102 pair also follows the same procedure as above. 1104 4.5. Open Issues 1106 There are some open issues that should be discussed in the later 1107 version of this document, and they are summarized as follows. 1108 - In the Interworking with HMIPv6, how can the nodes decide 1109 locally whether they are indeed the UCRN? 1111 - Can the update of the flow identifier for the session when 1112 interworking with HMIPv6 be considered only between an MN 1113 and an MAP to avoid end-to-end signaling? 1115 - Can the teardown message be sent toward the opposite 1116 direction of the state initiator? 1118 - When is the right time to delete the state along the obsolete 1119 path for fast handover of a ping-pong type? 1121 - How can the crossover node be discovered in the specific 1122 multicasting/multihoming cases? 1124 - How does the NAT/FW NSLP affect the CRN discovery? 1126 5. Dead Peer Discovery (DPD) 1128 5.1. Overview 1130 A dead peer can occur either because a link or a network node, 1131 including the MN and CRN, failed, or because the mobile node moved 1132 away without informing NSLP/NTLP (it is recommended to link mobility- 1133 and nsis signaling such that this does not happen). Hence, DPD is the 1134 fall-back mechanism for dealing with mobility which is not currently 1135 hooked into the NSIS protocol suite. 1137 The procedures for handling DPD should be the same no matter why a 1138 peer is dead, because an NE discovering a dead peer cannot judge the 1139 specific reason. That is, DPD due to a link or node failure, and DPD 1140 due to an MN moving away should trigger the same reaction. In any 1141 case, dead peers should be discovered as soon as possible to minimize 1142 service interruption. Subsequently, NSIS needs to find a different 1143 path interacting with the routing protocol. Thereby, NSIS needs to 1144 take into account the possibility that no path to the dead peer 1145 exists. Once the new path is found, NSIS state needs to be set up 1146 along the new path, and NSIS state needs to be torn down along the 1147 old path. However, care must be taken to terminate teardown at the 1148 CRN since the NSIS state on the common path should not be deleted. 1150 5.2. Failure Cases and Impact of Dead Peers 1152 5.2.1. Failure Cases 1154 Dead peers of interest in mobility scenarios include CRN, MN, and AR. 1155 In general, it is possible that only NSIS functions (i.e., NTLP/NSLP) 1156 of the node may fail, or the physical hardware. 1158 As mentioned above, an MN may either fail or move. When it fails, it 1159 becomes a dead peer. When it moves, it either changes or retains its 1160 IP address (e.g., CoA). If it moves and changes its IP address 1161 without notifying NSLP/NTLP, it also becomes a dead peer. If it moves 1162 and keeps its IP address, we need to solve a rerouting problem rather 1163 than a dead peer problem. 1165 5.2.2. Impact of Dead Peers 1167 The failure of a (potential) NSIS CRN may result in incomplete state 1168 re- establishment on the new path and incomplete teardown of the old 1169 path after handover. In this case, a new CRN should be discovered 1170 immediately by the CRN discovery mechanism described in Section 4. 1172 The failure or movement of an MN may cause the 'invalid NR' problem 1173 [draft- lee-nsis-nslp-mobility-01.txt] where the NR is the MN. [the 1174 following text could be added for clarification: If the MN moves, an 1175 error message, e.g., can-not- be-forwarded-further, should be 1176 generated by the MN, since this message may prevent the teardown of 1177 NSIS state on the old path before NSIS state is re-established on the 1178 new path]. We may need to also consider the case where the MN is not 1179 the NR, but a router in the access network (possibly the AR) is 1180 proxying for the MN instead. 1182 If the MN moves without changing its IP address, usually this is a 1183 micro mobility scenario. Two basic ways for handling micro mobility 1184 are currently used: 1186 - By source node routing [HMIPv6] towards the MN, i.e. coding the new 1187 route explicitly in each packet. It is difficult to do nsis-signaling 1188 for such a scenario, except by also source-node routing signaling 1189 messages. 1191 - By changing the so-called Regional CoA, which is not visible 1192 outside the micro mobility region. Packets destined to the MN are 1193 always addressed to the Mobility CRN. The Mobility CRN tunnels the 1194 packet to the MN [HMIPv4, HMIPv6]. Mobility in this case is not 1195 noticed by NSIS, because NSIS signaling is tunneled the same way as 1196 data packets. A separate NSIS state needs to be set up for the 1197 tunnel, and the NSIS state for the old tunnel needs to be torn down. 1199 Micro mobility with unchanged IP address is also handled in ad-hoc 1200 routing protocols in which per-host routing entries are changed in 1201 the routing tables. Hence in this case, mobility results in 1202 rerouting, just as when an intermediate node or link fails. 1204 If the MN moves with a changed IP address, the MN reappears somewhere 1205 else and tries to set up NSIS state along the new path. The 1206 requirements derived from this scenario contradict those derived from 1207 a true MN failure, where the MN does not reappear: 1209 - In the case of MN movement, teardown of NSIS state should be 1210 terminated at the NSIS CRN (cf Sec. 3.5) However, the NSIS CRN is 1211 only known once the NSIS signaling along the new path is completed. 1212 Therefore, state along the new path needs to be established first, 1213 and only then the old state should be torn down. (See also discussion 1214 in Sec. 4). 1216 In contrast, in case of MN failure, NSIS state should be removed 1217 along the entire path as quickly as possible. A CRN does not exist. 1219 Recall it is impossible for the NE discovering a dead peer to 1220 distinguish these two cases. We therefore need to settle on a single 1221 mechanism for handling both. 1223 The failure of an AR may make the interactions with Seamoby protocols 1224 (such as CARD and CT) impossible. In this case, the neighboring peer 1225 closest to the dead AR may need to interact with CARD and CT. 1227 5.3. DPD procedures in NTLP 1229 The procedures of how to do DPD should be handled by the NTLP. In 1230 fact, the DPD can be considered as an extension to the GIMPS peer 1231 discovery. The transmission of peer discovery messages may be 1232 separated from the transmission of regular signaling messages. It is 1233 also possible to combine both types of messages for efficiency in 1234 message delivery. For example, the detection of an NSIS peer and the 1235 establishment of an NSIS state can be performed using an NSIS message 1236 at the same time. 1238 There are cases where an NE does not deliver signaling messages 1239 successfully to its NSIS peer along the signaling path, for example, 1240 when an NF (or NR) was disconnected from the network due to one of 1241 the failures described above, causing a change of signaling path in 1242 the network. Such dead peers which are no longer reachable should be 1243 detected. Some possible DPD procedures are described below. 1245 A peer discovery message can be periodically transmitted to the 1246 neighboring peer (e.g., responding node in [GIMPS]), and the 1247 responding node can send a response message. To determine if the 1248 peer is alive, the use of a timer may be helpful. For example, the 1249 response message may need to be received by the sender (e.g., 1250 querying node in [GIMPS]) of the peer discovery message before the 1251 timer expires. Otherwise, the responding node can be considered dead. 1253 It is important to check the validity of the peer discovery messages 1254 for security protection. For example, it may be necessary to 1255 determine if the peer discovery message has been received from the 1256 authorized peer. Cookies such as query-cookie and response-cookie 1257 [GIMPS] may be useful for this purpose. 1259 According to the [GIMPS], the NTLP itself does not provide for 1260 teardown of NTLP state because, as opposed to NSLP state, it is not 1261 very expensive. NTLP instead relies on time-out. Upon DPD, NTLP 1262 informs the local NSLPs about it, and may even send a notification to 1263 other NTLP peers upstream to inform other NSLPs which it does not 1264 support locally. It is an open question when to stop propagating this 1265 information [GIMPS], which is not specific to mobility. 1267 Local NSLPs (e.g., QoS-NSLP) could either initiate a teardown of the 1268 corresponding NSLP state upstream, i.e., in the direction opposite to 1269 the dead peer (possibly accelerated expiration as described in 1270 [GIMPS] if the node is not authorized to do this) or send a 1271 notification upstream which might result in the NI to take action. 1273 Actually in [QoS-NSLP] it is not fixed yet what must happen. A dead 1274 peer may lead to rerouting, or sometimes, as sometimes in the case of 1275 a dead NR, no new route being discovered. Rerouting may be noticed by 1276 more than one NE using one of the detection mechanisms described in 1277 [GIMPS]. Furthermore, more than one NE may be able to reroute around 1278 the situation (see Fig. 8 in [GIMPS]). The NE closest to the flow 1279 sender should become the NSLP CRN. 1281 Finding the new path and establishing state can be done as described 1282 in Section 4. The relative timing of state teardown and re- 1283 establishment is still an open question as discussed in Section 1284 5.2.2. 1286 6. Case Examples 1288 The movement of end-hosts leads to changes in the data path due to 1289 the change of their point of attachment in the network. This results 1290 in the original data path between a sender and a receiver to be 1291 divided into three paths, all of which intersect at a CRN: the 1292 unchanged path from the CN until the crossover router, the new path 1293 from the crossover router until the new location of the MN and the 1294 old path from the crossover router until the old location of the MN. 1296 Due to rerouting of data packets after handovers, signaling- 1297 associated states need to be updated or removed. This concerns with 1298 which information is needed for indexing states and where and when a 1299 creation, update or removal of these states is required. If 1300 signaling-associated state is indexed based on flow-Ids, the state 1301 indexed by the flow-ID referred to the old path might be inaccessible 1302 for the signaling after most handover procedures. Hence, it is 1303 assumed that signaling-associated state is indexed by session-IDs. 1305 This section provides concrete examples of the signaling done in a 1306 handover situation. 1308 6.1. NSIS in the hard-handover case 1310 This example is called hard-handover, or break-before-make handover, 1311 in which the NSIS signaling, required to update the MN path, happens 1312 only after the MN is attached to the new access point. 1314 To update the path between the CN and the MN, state needs to be 1315 installed in the new path, released from the old one and updated in 1316 the unchanged path. The NSIS signaling required for this operation 1317 may be triggered by the mobile node, mobility agent(s), or by the 1318 access router at which the mobile node is attached to. In any 1319 situation, the CRN is the starting point or finish point of the NSIS 1320 signaling messages. 1322 Since we have to assume that the MN can be a sender as well as a 1323 receiver, the first difficulty to find a CRN is posed by the 1324 asymmetric characteristic of routing, as mentioned in Section 4.2. 1325 Due to routing asymmetry there is no reason for the UCRN and the DCRN 1326 to be the same in the, even for the same correspondent node. 1327 Therefore the NSIS signaling sequence required to update the path 1328 depends on the role of the MN, which is the one detecting the 1329 attachment to a new network. 1331 Figures 6.1 and 6.2 illustrate the signaling needed to update the MN 1332 path in the upstream and downstream direction when the MN is a sender 1333 or a receiver. In both figures, the "r", "s", and "u" indicate NSIS 1334 messages to remove state in the old path, set state in the new path 1335 and update state in the unchanged path. The "t" in Figure 2 1336 represents the triggering message that the MN sends to the CN. This 1337 triggering message can be for instance a mobility-binding message. 1339 +---+ 1340 [MN] |AR1|| 1672 | | 1674 (a) MIPv6: MN-->CN, no reverse tunnel 1676 MN HA CN 1677 |IPv6(tunnel)| | 1678 |----------->| IPv6(normal) | 1679 | |--------------------->| 1680 | | | 1682 (b) MIPv6: MN-->CN, with reverse tunnel 1684 Fig. 8.1: Implications for flows under different mobility scenarios 1685 CN MN 1686 | | 1687 | MIPv6(RH Type 2) | 1688 |--------------------------------->| 1689 | | 1691 (c) MIPv6: CN-->MN, route optimization 1693 CN HA MN 1694 |IPv6(normal)| | 1695 |----------->| | 1696 | | MIPv6(tunnel) | 1697 | |----------------------->| 1698 | | | 1700 (d) MIPv6: CN-->MN, no route optimization 1702 CN HA MAP nAR(MN) 1703 | | | | 1704 | IPv6 | | | 1705 |---------->| | | 1706 | (normal) | | | 1707 | | MIPv6 | | 1708 | |----------->| | 1709 | | (tunnel) | | 1710 | | |HMIPv6 | 1711 | | |-------->| 1712 | | |(tunnel) | 1714 (e) HMIPv6: CN-->MN, no route optimization 1716 CN pAR nAR MN 1717 | | | | 1718 |MIPv6(normal-HA-tunnel) | | 1719 |----------------------->| | 1720 | | | | 1721 | | FMIPv6 | | 1722 | |<-----------| | 1723 | | (tunnel) | | 1724 | | FMIPv6 (tunnel) | 1725 | |---------------------->| 1726 | | | | 1728 (f) FMIPv6: CN-->MN, no route optimization 1730 Fig. 8.1: Implications for flows under different mobility scenarios 1732 8.2. Interactions with Seamoby Protocols 1734 Although the NSIS protocol suite operates in a path-coupled way, the 1735 interactions between NSIS and Seamoby protocols have an effect on 1736 parts that are out of the signaling path. In the context of handovers 1737 between old and new access routers, there can be performance 1738 optimization issues in the following two areas: selection the optimal 1739 access router to handover to and transfer of state information 1740 between the old and new access routers to avoid having to regenerate 1741 it in the new access router after handover. The Seamoby working group 1742 is developing protocols solutions for these functions (CARD and CTP 1743 respectively), but a discussion of the way in which these functions 1744 interact with NSIS signaling is necessary. 1746 As mentioned in Section 3.3, significant performance gains can be 1747 achieved if NSIS signaling can interact with such protocols although 1748 they can operate independently. In this case, some questions arise: 1749 which scenario these protocols can be used in, or what the mode of 1750 interaction should be: pre-establishment and re-establishment 1751 approaches or passive triggering mode where NSIS is triggered by 1752 CARD/CTP and active triggering mode where NSIS triggers these 1753 protocols. 1755 In general, CARD is required to identify candidate ARs (CARs) for 1756 handover and find capabilities of these CARs prior to the initiation 1757 of the IP-layer handover. CTP is used to quickly re-establish context 1758 transfer-candidate services without processing for those services 1759 from scratch and additionally to provide an interoperable solution 1760 that supports various layer 2 radio access technologies. However, in 1761 the pre-establishment using NSIS, CARD/CTP can interact with the NSIS 1762 protocol suite to ferret NSIS-aware candidate AR where an MN will 1763 move and establish NSIS state before the completion of handover. That 1764 is, the interaction between NSIS and CARD/CTP prevents resources from 1765 being excessively pre-reserved. In this approach, for the fast setup 1766 of NSIS state, path update along the candidate NEs may also be 1767 achieved simultaneously with (or through) discovering a candidate 1768 CRN. 1770 When a handover, for example, is initiated, the current AR receiving 1771 the movement detection information (e.g., 'RtSolPr' message in FMIPv6 1772 [FMIP] if NSIS also interacts with this mobility protocol) from an MN 1773 may interact with the CARD to ferret an appropriate (NSIS-aware) 1774 access router (or a few candidate access routers (CARs) may be 1775 found). In this process, the NTLP of the current AR should be able to 1776 recognize whether the CAR is an NSIS-aware node after sending the 1777 'capability reply' message (of CARD). The QoS-NSLP of the AR may need 1778 to be interaction with the CTP to transfer the QoS-NSLP state 1779 information to the newly discovered NSIS-aware candidate AR. After 1780 receiving the context, the NTLP of the candidate AR may be able to 1781 begin to trigger the discovery of a candidate CRN using the QoS-NSLP 1782 state information in the coupled approach or separated approach. QoS 1783 and context transfer issues have already been considered already some 1784 time ago in [I-D.thomas-nsis-rsvp-analysis]. More recently [CTP- 1785 Interop] and [Lee01] present ways and some open issues for 1786 interoperation between NSIS and CTP in both predictive mode and non- 1787 predictive mode. 1789 In the re-establishment approach, CARD can be used to only check 1790 admission control status on the new path before handover is 1791 completed, and CTP can be used to transfer NSIS state (e.g., QoS-NSLP 1792 state) to a CAR to quickly re-establish the state along the new path 1793 after handover. The main objective of interaction in this approach is 1794 to reduce state setup delay and packet losses due to handover. 1796 In case of passive triggering mode, CARD/CTP may use NSIS signaling 1797 to check the admission control status of CAR and pre-establish NSIS 1798 state on the candidate path and discover a candidate CRN in the pre- 1799 establishment approach. In this case, resource availability on the 1800 path between the AR and CN should also be discovered using NSIS 1801 signaling. A possible example is that some entity in a candidate AR 1802 can trigger NSIS using resource and reservation information from the 1803 current AR to find out about how much resources would be available on 1804 the new path. 1806 In the context of NSIS, the NSIS protocol generally can trigger the 1807 CARD/CTP to transfer its own state information from the current AR to 1808 CAR: active triggering mode where the NSIS protocol should monitor 1809 the operation of these protocols. Note that the NSIS protocol, in the 1810 first place, should interact with mobility protocols (i.e., usually 1811 with FMIPv6), or be coupled with movement detection mechanisms to 1812 timely initiate the CARD/CTP in both reservation approaches. 1814 If NSIS does not consider interworking with CARD/CTP or it is not 1815 possible to use these protocols, NSIS protocol in itself may be able 1816 to discover the CAR as an extension of NTLP peer discovery mechanism 1817 in the separated approach, and to check whether resources on the 1818 candidate path is available or not before the completion of handover. 1819 However, this also makes NSIS protocol perform path-decoupled 1820 signaling, and whether these functions in NSIS can be implicitly 1821 developed is an open issue. 1823 9. Additional issues 1825 This section highlights some important issues not discussed earlier 1826 in this draft. 1828 9.1. Both End-Hosts are Mobile 1830 Considerations about signaling between two mobile devices. Until now, 1831 we are assuming a non-mobile corresponding node. Problems can show up 1832 if both devices start to signal at the same time. 1834 9.2. Uni- and Bi-directional State Establishment 1836 It should be possible to support unidirectional NSIS state 1837 establishment in both sender- and receiver-oriented modes. For 1838 example, in case of QoS-NSLP, the MN (as a sender) can initiate a 1839 reservation setup for its outgoing flows in the sender-initiated 1840 mode. With the receiver-initiated approach, the MN (as a sender) 1841 requests the receiver to make a reservation, thus allowing the 1842 receiver to initiate a reservation for the flow. After handover of 1843 the MN (as a sender) to a new AR, the state re-establishment should 1844 be performed in the similar way. 1846 In addition to the unidirectional NSIS state establishment above, 1847 bidirectional state establishment can also be supported. In the basic 1848 case, bidirectional NSIS signaling can simply use a separate instance 1849 of the same signaling mechanism in each direction. Although the 1850 bidirectional data flows have the same end points, the paths in the 1851 two directions do not need to be the same. Therefore, the CRN of the 1852 downstream path may be different from that of the upstream path in 1853 mobility scenarios. As a matter of course, the Session ID in the 1854 downstream reservation should be different from that of the upstream 1855 reservation. If the routes (i.e., upstream and downstream paths) are 1856 symmetric, an NSIS single signaling message can be used to install 1857 state in both directions. If the routes are asymmetric, an NSIS 1858 signaling message from the originator (e.g., MN or CN) can trigger an 1859 independent signaling message from the responder. 1861 9.3. State Management 1863 The main objective of NSIS is to manage state information along the 1864 path taken by a data flow. For state management, the NSIS protocol 1865 suite normally use a soft-state approach to manage state in NEs where 1866 the state created by the NSIS message has to be periodically 1867 refreshed. 1869 At the NTLP layer, the state is maintained through the exchange of 1870 GIMPS query/response messages between adjacent peers [ntlp]. In this 1871 case, the peer relationship is maintained using a timer which implies 1872 how long the association between the peers can be considered valid. 1873 That is, if it has not been refreshed until the timer expires (e.g., 1874 after 30 seconds as a default value), the peer relationship is 1875 removed. The management of state (i.e., routing state and messaging 1876 association) can be controlled in this way. 1878 At the NSLP layer, the peer-to-peer refresh messages can also be used 1879 for state management. In case of QoS-NSLP, states should be set up 1880 and maintained for the reservation of desired resources. In this 1881 context, the operation of QoS-NSLP is similar to that of RSVP [RFC 1882 2205]. An example of state management at the QoS-NSLP layer is as 1883 follows. Upon receiving a RESERVE message, an NE (specifically the 1884 QoS-NSLP) sets up state for QoS reservation. This state will be 1885 deleted unless it is refreshed by a RESERVE message before the 1886 refresh timer expires. The peer-to-peer based refreshment allows the 1887 QoS-NSLP to appropriately select the refresh time by considering the 1888 current network environment. For example, it may set the refresh 1889 timer value in the mobile/wireless (access) network to a smaller 1890 value than that in the core (wired) network [QoS-NSLP]. Note that, 1891 however, unlike the QoS-NSLP, the refresh time of NTLP state doesn't 1892 need to be adjusted according to the type of the network from the 1893 perspective of resource utilization. 1895 In case of QoS-NSLP, the main objective of the adjustment of the 1896 refresh time is to minimize the waste of resources due to double 1897 reservation. Setting the refresh time in the access network 1898 differently from that of the backbone network can be done by manual 1899 configuration or an adaptive technique. A possible example of such 1900 adaptive techniques is to use a field, e.g., 'REFRESH' field of the 1901 mobility object (or Refresh object). The 'REFRESH' field may consist 1902 of 'M' bit for indicating the type of the network (e.g., the 1903 mobility-supporting access network) and 'PRE' bit for fast QoS re- 1904 establishment (e.g., pre-reservation). The refresh timer value of 1905 pre-reservation state should be maintained for a short period of 1906 time. 1908 In mobile and wireless networks, the QoS-NSLP (rather than the NTLP) 1909 should be able to set the refresh timer value depending on the part 1910 of the network (e.g., an access network or backbone network) or the 1911 reservation style (e.g., pre-establishment or re-establishment). For 1912 example, in case of pre-reservation, upon receiving the mobility 1913 object during handover, the QoS-NSLP of the NE which is supposedly 1914 involved in the QoS signaling can set the 'PRE' bit of the outgoing 1915 QoS-NSLP message. In this case, if the refresh timer value of 'PRE' 1916 bit is set to a little higher value than the estimated handover 1917 latency, the MN can be provided with seamless QoS service using the 1918 pre-reserved resources, and the resources which are pre-reserved but 1919 unused will be timely released after handover. Note that after 1920 handover, QoS-NSLP should restore the original refresh timer value in 1921 order to avoid the overhead due to the frequent transmissions of the 1922 refresh message (e.g., 'PRE' bit is reset to null and 'M' bit is kept 1923 to be 1). Note that, however, procedure for computing the refresh 1924 time is not part of the NSIS protocol. Thus, how to set the refresh 1925 timer value of the 'M' and 'PRE' bits according to mobility scenarios 1926 is also an implementation issue. 1928 9.4. State establishment in Network Mobility 1930 The network mobility (NEMO) Working Group is focusing on managing the 1931 mobility of a mobile network (e.g., a leaf network) which changes its 1932 point of network attachment as a unit through one or more mobile 1933 routers (MRs). In this case, the leaf network consists of one or more 1934 MNs and/or fixed hosts, and it may include multiple heterogeneous 1935 network interfaces. An MR basically has a Home Agent (HA) and bi- 1936 directional tunneling between the MR and HA to preserve session 1937 continuity while the MR moves into other point of network attachment. 1938 The MR as a single node obtains a CoA as in the MIP mechanism, which 1939 allows nesting of mobile networks. However, the nested mobile 1940 networks cause the pinball routing problem because flows of each 1941 mobile network may transit multiple HAs through multiple bi- 1942 directional tunnelings. A mobile network can also have multihoming- 1943 related issues through either a single MR which has multiple 1944 interfaces to the network, or multiple MRs which attach the mobile 1945 networks to the network. 1947 The solutions in the NEMO WG will support preservation of route 1948 aggregation in the network when flows of MNs (and/or fixed hosts) in 1949 a mobile network are sent to the same CN. In this case, aggregate 1950 state installation, e.g., for aggregate reservation (or group 1951 reservation), should be considered to guarantee resources along the 1952 aggregated route between the MR of the mobile network and the CN. 1953 This aggregate state installation issue also requires careful 1954 consideration in view of mobility related issues in NSIS. To deal 1955 with aggregate state installation in network mobility, issues such as 1956 multihoming and pinball routing problem caused by the nested mobile 1957 network and various scenarios for network mobility should be 1958 considered. However, it is recommended that such issues be handled in 1959 liaison with NEMO WG which is still at its early stage in developing 1960 solutions for the route optimization problem. Therefore, it is 1961 premature to specify details on the aggregate state installation in 1962 this draft. 1964 10. Guidelines for Designers of new NSLPs 1966 This section presents issues that must be taken into account when 1967 designing a new NSLP for a mobile and wireless environment. The main 1968 issues are: 1970 - IP addresses of the communicating nodes can change during the 1971 lifetime of the session, 1972 - The bandwidth of the last-hop link may be limited and vary 1973 drastically, 1974 - Routing may be asymmetric, 1975 - There may be tunnels that hide the original IP packet header, 1977 - an NE before establishing new state should check whether is already 1978 has state with the same session ID but a different flow ID. If this 1979 is the case it needs to find out whether it is CRN and act 1980 accordingly (details to be spelled out). 1981 - path repair should be localized 1982 - procedures for handling DPD should be the same independent of 1983 whether a peer is truly dead or just changed its IP address because 1984 of handover. 1986 1994 12. Security Considerations 1996 This section describes authorization issues for mobility scenarios in 1997 NSIS. It tries to raise additional questions beyond those discussed 1998 in [SID]. 2000 For the discussion of various authorization problems we assume that 2001 initial authorization is strongly coupled to authorization handling 2002 in subsequent message interactions. Making this assumption, as we see 2003 in the subsequent text, has some implication to the signaling message 2004 behavior. It is certainly possible that the entities who grant the 2005 initial reservation and those who subsequently cause modifications 2006 are not the same entities. 2008 Please also note that NSIS does not mandate a single model for the 2009 initial authorization step (such as receiver has to provide 2010 authorization as in RSVP). Hence it is necessary to consider more 2011 combinations. As argued in [NSIS-AAA] it is necessary to consider 2012 cases where the sender, the receiver or both are authorizing a 2013 reservation. The reader should keep in mind that these signaling 2014 message exchanges are not only applicable for QoS reservations but 2015 also for other NSLP applications such as NAT/Firewall signaling. The 2016 concept of sender- and receiver-initiated reservations is very vague 2017 in case of NAT/Firewall signaling. There a concept of delayed 2018 authorization is suggested with requires both, the sender and the 2019 receiver, to authorize packet and NAT binding establishment. 2021 Subsequently, we will consider the case where the mobile node acts as 2022 a data sender followed by a discussion of the CN as a data sender. 2023 Each scenario is separated into more individual scenarios. 2025 12.1. MN as data sender 2027 Figure 12.1 describes a scenario with the MN as a data sender which 2028 moves from one point of attachment to another. The two flows are 2029 merged at the DCOR. The path between the DCOR and the CN is referred 2030 as the shared segment. Along the shared segment it might be necessary 2031 to update the flow identifier but not the NSLP state itself. 2033 new segment 2035 +--+ +---+ new flow 2036 new |MN|>>>>>>>>>>|NAR|>>>>>>>>>>>>>V 2037 address +--+ +---+ V 2038 ^ +----+ +--+ 2039 | |DCOR|>>>>>>>>>>|CN| 2040 | | |>>>>>>>>>>| | 2041 | +----+ +--+ 2042 | +--+ +---+ ^ shared 2043 original |MN|>>>>>>>>>>|OAR|>>>>>>>>>>>>>^ segment 2044 address +--+ +---+ original 2045 flow 2046 MN acts old segment 2047 as UCOR 2049 ========================= DATA ===================================> 2051 Legend: 2052 >>>>>>>: denotes signaling message flow 2053 the direction of the arrow shows the direction of the 2054 initial signaling flow direction 2055 <------: movement 2056 <======: data flow (direction indicated with arrow) 2058 Figure 12.1: MN as data sender 2060 We will start with the initial flow setup triggered by the MN and 2061 also authorized by the MN. 2063 12.1.1. MN is authorizing entity 2065 This scenario considers the initial flow setup executed by the MN 2066 whereby the MN provides authorization for the initial flow setup. The 2067 initial setup might be used to create state for subsequent 2068 authorization actions by the MN. It is obvious that the authorization 2069 for the NSLP application (e.g., QoS NSLP) has to provided. Depending 2070 on the underlying authorization model it might be either peer-to-peer 2071 or end-to-middle. This authorization decision can possibly be treated 2072 independent of the authorization issues discussed in this section 2074 MN CN 2076 ------>----->------>------>------>------>------> + 2077 ACTION (MN is authz) | 2078 | 2079 <-----<-----<------<------<------<------<------- | Flow 2080 ACK | Setup 2081 | 2082 ===============================================> + 2083 Traffic 2084 Figure 12.2: Initial MN authorized flow setup 2086 The following questions seem to be interesting: 2088 - Should the MN indicate that it is the authorizing entity for 2089 subsequent actions to all entities along the path? 2091 - What information should be used for this purpose? 2093 - Who should add this information? Should the visited network of the 2094 MN add something to the signaling message during the initial flow 2095 setup? 2097 - How do other entities along the path learn this information? 2099 Scenario: The MN authorizes DCOR 2101 The movement of the mobile node after the initial flow setup requires 2102 authorization. Various session ownership authorization issues are 2103 illustrated in the [SID] draft itself. We will not repeat these 2104 issues in this document again. 2106 MN DCOR CN 2108 + E.g. 2109 ------>----->------>------>------>------>------> | Movement 2110 ACTION | with state 2111 | creation at 2112 <-----<-----<------<------<------<------<------- + new path 2113 ACK 2114 Figure 12.3: MN authorizes DCOR 2116 The following questions are of interest: 2118 - Why should DCOR execute something on behalf of the MN? (i.e., why 2119 should it trust the MN and what information can the DCOR use for 2120 verification?) As an example, the DCOR might delete state along the 2121 old segment. 2123 - Should the DCOR alone be able to start signaling (the DCOR might be 2124 a designed node in some mobility protocols (e.g., MAP)) since it is 2125 the node which has more information that other nodes based on the 2126 mobility signaling protocols? 2128 - How should other nodes between the MN and the DCOR and between the 2129 DCOR and the CN know that the DCOR is now acting on behalf of the MN? 2131 Scenario: The CN triggers action 2133 CN wants to tear-down flow or it wants to trigger an action in the 2134 network 2135 MN DCOR CN 2137 <~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + 2138 TRIGGER | E.g. 2139 | Tear 2140 | Down 2141 ------>----->------>------>------>------>------> | 2142 ACTION | 2143 | 2144 <-----<-----<------<------<------<------<------- + 2145 ACK 2146 Figure 12.4: CN triggers action 2148 Questions: 2150 - Why should the MN trust the trigger? 2152 - Is it possible to specify the security properties of the trigger 2153 message in more detail? (If this is an NSIS message then we could 2154 argue that hop-by-hop trust does not always replace end-to-end 2155 security.) 2157 - (see for example the discussion in with regard to an indicator which entity to charge for 2159 the reservation. 2161 - Should the CN restrict the actions of the MN (e.g., delete, update, 2162 create)? On the shared segment it might, for example, be possible to 2163 restrict the allowed action to a flow identifier update. 2165 12.1.2. CN is authorizing entity 2167 This scenario is quite similar to the CN triggering in Section 1.1.1. 2168 Two slightly different protocol variations will be considered. 2169 Authorizing some actions in the reverse data flow direction is more 2170 difficult as it can easily be seen in Figure 12.5. 2172 Variant 1: CN asks MN to trigger action (on behalf of the CN) 2174 In Figure 12.5 the CN authorizes the MN to start signaling after, for 2175 example, a movement. After receiving the trigger message (and some 2176 authorization information) the mobile node starts signaling along the 2177 new segment and automatically discovers the DCOR. The message travels 2178 along the shared segment to the CN and updates the flow identifier 2179 (if necessary). The MN might additionally allow the DCOR to delete 2180 the reservation along the old segment. 2182 MN DCOR CN 2184 <~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + 2185 TRIGGER | 2186 | 2187 ------>----->------>------>------>------>------> | 2188 ACTION (CN is authz; MN on behalf of CN) | 2189 +-----------------+ +-----------------+ | 2190 | Action: | | Action: | | 2191 | 'create' along)| | 'update' along)| | 2192 | new segment) | | shared segment)| | Action 2193 +-----------------+ +-----------------+ | 2194 <------<------<------- | 2195 +-----------------+ | 2196 | Action: | | 2197 | 'delete' along)| | 2198 | old segment) | | 2199 +-----------------+ | 2200 <-----<-----<------<------<------<------<------- | 2201 ACK | 2202 | 2203 | 2204 ===============================================> | 2205 Traffic + 2206 Figure 12.5: CN asks MN to trigger an action (on behalf of the CN) 2208 Questions: 2210 - How should the "delegation" mechanism work such that 2211 intermediate nodes believe the MN that it is acting on 2212 behalf of the CN? 2214 - Is it possible to carry this information with the Trigger 2215 message from the CN and the MN? 2217 Variant 2: CN uses installed state to route message backward 2219 As a second variant the CN uses NSIS installed state to route a 2220 signaling message backward along the path. In some rare cases the 2221 DCOR node might be known already. In this case it is possible to stop 2222 the update process along the shared segment and to possibly mark 2223 installed state along the old segment for deletion. When the MN 2224 receives the message it again has to install state along the new 2225 segment towards the DCOR. The mobile node might also trigger the 2226 deletion of resources along the old segment together with this state 2227 creation (pessimistic delete). The optimistic delete operation is 2228 certainly more error prone. 2230 As it can easily be seen from the description many assumptions have 2231 to be made in order for this signaling exchange to work. Hence, as a 2232 generic solution this approach is certainly not suggested. We 2233 included this scenario for completeness. 2235 MN DCOR CN 2237 [ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~> ] + 2238 [ TRIGGER (e.g., MIP) ] | 2239 | 2240 ------<-----<------<------<------<------<------< | 2241 ACTION (CN is authz) | 2242 +--------------------+ +-----------------+ | 2243 | Action:optimistic | | Action: | | 2244 | 'delete' along | | 'update' along)| | 2245 | old segment) | | shared segment)| | 2246 +--------------------+ +-----------------+ | 2247 >------>------>----------->------>------>------- | 2248 +-----------------+ ACK | 2249 | Action: | | Action 2250 | 'create' along)| | 2251 | new segment) | | 2252 +-----------------+ | 2253 <------<------<------- | 2254 +-------------------+ | 2255 | Action:pessimistic| | 2256 | 'delete' along) | | 2257 | old segment) | | 2258 +-------------------+ | 2259 | 2260 ===============================================> | 2261 Traffic + 2262 Figure 12.6: CN uses installed state to route message backward 2264 Questions: 2266 - Similarly as before the security properties of the trigger message 2267 need to be evaluated. 2269 - It is not always possible to route the message backward from the 2270 CN to the MN: 2272 a) state at the new path might not be established (hence the 2273 signaling message cannot travel backward) 2274 b) the signaling message might not reach the MN via 2275 the old segment. 2276 In the multi-homing case where the mobile node can be reached via 2277 more than two paths it is possible to execute this exchange. The same 2278 might be true for some local repair cases. 2280 - The messages triggered by the MN (namely create state along the new 2281 segment and the pessimistic 'delete along the old segment) still need 2282 to be executed on behalf of the CN. Compared to the first variant 2283 there might be some room for optimization since the first message was 2284 transmitted by the CN. 2286 12.1.3. MN and CN are authorized 2288 If we argue that the authorization at the NSLP layer is somehow tight 2289 to the authorization issues discussed in this section (i.e., 2290 authorization for certain protocol actions) then we also have to 2291 consider the case where both nodes (MN and CN) have to contribute 2292 their part to the authorization decision. This situation appears for 2293 example in the NAT/Firewall signaling case but also in the area of 2294 QoS reservation where both parties might need to share costs. 2296 If both end hosts are authorized then some signaling message 2297 exchanges are less difficult since the trigger message does not need 2298 to include authorization information. Some problems, however, do not 2299 disappear such as the session ownership problem and additional 2300 problems might be caused by certain solution approaches. Since this 2301 section does not discuss solutions the reader is referred to the 2302 [sid] draft which lists a few strawman proposals for addressing the 2303 session ownership problem. 2305 12.2. CN as data sender 2307 In this section we consider the scenarios where the CN acts as a data 2308 sender. Except for some minor issues we believe that the requirements 2309 caused by the signaling exchanges are mostly discussed in Section 1.3 2310 already. 2312 new segment 2314 +--+ +---+ new flow 2315 new |MN|<<<<<<<<<<|NAR|<<<<<<<<<<<<<^ 2316 address +--+ +---+ ^ 2317 ^ +----+ +--+ 2318 | |UCOR|<<<<<<<<<<|CN| 2319 | | |<<<<<<<<<<| | 2320 | +----+ +--+ 2321 | +--+ +---+ V shared 2322 original |MN|<<<<<<<<<<|OAR|<<<<<<<<<<<<----->----->------>------>------>------>------> | 2370 ACK (along new path) | 2371 | 2372 <=============================================== + 2373 Traffic 2374 Figure 12.8: CN as data sender is authorized 2376 Since the mobile node first detects the route change. A trigger to 2377 the CN allows the CN to quickly react on the route change. There are 2378 two variants: 2380 1) The MN sends a trigger to CN and CN starts signaling flow as shown 2381 in Figure 12.8. 2383 2) The MN routes the message back along the reverse path using the 2384 previously established state along the old route. This mechanism only 2385 works if the MN is able to send messages along the old path. As a 2386 generic mechanism this is not suggested. 2388 3) An intermediate node act on its own. This might be possible that 2389 the UCOR is an entity which participates in the mobility signaling 2390 (e.g., MAP) exchange. Depending on the message exchange it needs to 2391 be studied whether the signaling message provides sufficient 2392 authorization to trigger the NSIS exchange. 2394 12.2.2. MN is authorizing entity 2396 In this scenario we consider the case where the CN is the data sender 2397 but the MN authorizes actions. The considerations are similar to 2398 those elaborated in Section 1.3.2 where the MN is the data sender but 2399 the CN is the authorizing entity. 2401 12.3. Multi-homing Scenarios 2403 Multi-homing scenarios have the property that the more than one path 2404 belongs to a signaling session. In Figure 12.9 the MN uses two 2405 interfaces to route NSIS message towards the CN. Both individual 2406 sessions are tight together with the same session identifier. The MN 2407 needs to indicate that both reservations need to be kept alive (and 2408 the DCOR should not delete a reservation). At the shared segment only 2409 a single reservation is stored. 2411 From an authorization point of view the session ownership issues is 2412 applicable since the DCOR needs to merge the two reservation into a 2413 single one along the shared segment. 2415 12.3.1. MN as data sender 2417 This section shows the multi-homing scenario with the MN as a data 2418 sender. 2420 segment 2 2421 +---+ 2422 ^>>>>>>>>>>>>>>>| AR|>>>>>>>>>>>>>V 2423 ^ +---+ V 2424 +----+ +----+ +--+ 2425 | MN | |DCOR|>>>>>>>>>>|CN| 2426 |UCOR| | |>>>>>>>>>>| | 2427 +----+ +----+ +--+ 2428 v +---+ ^ shared 2429 v>>>>>>>>>>>>>>>| AR|>>>>>>>>>>>>>^ segment 2430 +---+ 2431 segment 1 2433 ===============================================================> 2434 Traffic 2435 Figure 12.9: Multi-homed MN as data sender 2437 If the MN is the authorizing entity then the session ownership 2438 problem needs to be solved. Without solving this type of 2439 authorization problem it is possible for an adversary to "join" the 2440 reservation at the shared segment. Furthermore, it is an open issue 2441 whether reservation merging is allowed only for cases where one flow 2442 identifier is used at different interfaces or even with different 2443 flow identifiers. 2445 If the CN is the authorizing entity then, again, some message needs 2446 to be sent from the CN to the MN to trigger the exchange or to route 2447 the request backward along the established path. The MN is reachable 2448 via the two paths. 2450 Mobility handling might be smoother since it is possible that only 2451 one interface experiences an IP address change with all the 2452 previously discussed implications. 2454 12.3.2. CN as data sender 2456 This section shows the multi-homing scenario with the CN as a data 2457 sender. The scenario is simpler (for the CN authorizing case) than 2458 the one described in Section 1.5.1 since the signaling message along 2459 the shared segment travels the previously established path. This 2460 scenario is similar to the route change scenario. At the mobile node 2461 itself the two paths merge which again leads to a session ownership 2462 problem. How should the MN know whether a signaling message with the 2463 same session identifier appearing at a new interface belongs to the 2464 indicated session authorized by the CN. 2466 If the MN is the authorizing entity then again communication between 2467 the end hosts is required as a trigger. Reverse routing might, in 2468 some cases, also be possible. 2470 segment 2 2471 +---+ 2472 v<<<<<<<<<<<<<<<| AR|<<<<<<<<<<<<<^ 2473 v +---+ ^ 2474 +----+ +----+ +--+ 2475 | MN | |UCOR|<<<<<<<<<<|CN| 2476 |DCOR| | |<<<<<<<<<<| | 2477 +----+ +----+ +--+ 2478 ^ +---+ v shared 2479 ^<<<<<<<<<<<<<<<| AR|<<<<<<<<<<<< ----\ 2514 +--+ | Router(pAR)| < \ 2515 | +------------+ +-------------+ 2516 | moving ^ IP |Correspondent| 2517 | |NSIS-CTP Core |Node (CN) | 2518 V | Network +-------------+ 2519 v / 2520 +------------+ / 2521 +--+ | new | NSIS < / 2522 |MN| ---------- | Access | ------ > ----/ 2523 +--+ | Router(nAR)| < 2524 +------------+ 2525 Figure 12.11: Context Transfer 2527 For the signaling message exchange in the predictive and non- 2528 predictive CT mode it can be seen that the assumption is made that 2529 the MN is the authorizing entity. A communication with the CN does 2530 not take place and would certainly increase the complexity of the 2531 protocol exchange. The authorization properties of the Context 2532 Transfer procedure (and some micro-mobility schemes) need to be 2533 studied in more detail to see their implications for security. 2535 The context transfer procedure seems to provide a simple solution for 2536 some session ownership problems (in case that the MN is authorized). 2538 12.5. Proxy Scenario 2540 The proxy scenarios refers to those cases where one of the end hosts 2541 or even both end hosts are not NSIS aware. Two security implications 2542 need to be studied. 2544 First, there is an authorization issue with regard to the NSLP 2545 application. For QoS signaling the end host (and the user) has to 2546 authorize the QoS reservation since the reservation might require the 2547 user is charged for it. Since the end host is not NSIS aware some 2548 other mechanism or protocol needs to be available with provides this 2549 functionality. For NAT/Firewall signaling delayed authorization 2550 assures that both end hosts authorize the packet filter creation at 2551 their local networks (particularly in case of missing trust 2552 relationship between intermediate networks). 2554 Second, the authorization issues which relate to the session 2555 ownership problem also need to be studied. Since the session 2556 ownership issues are a related to the signaling participating nodes 2557 and not to the users or the true end points we think that it does not 2558 lead to complications. This is, however, only true if we assume that 2559 authorization at the NSLP and authorization decisions for the 2560 signaling message handling is decoupled. 2562 12.6. Implications for the costs of a QoS reservation 2564 It is obvious that mobility support within NSIS raises security 2565 issues. A number of mobility scenarios with impacts on security are 2566 discussed in Section 7 of [NSIS-AAA]. Even if the signaling message 2567 exchange is restarted from scratch (i.e., using a new flow-ID), 2568 security handling within NSIS is affected. This type of processing 2569 is, however, mostly not a topic for this draft. 2571 12.6.1. Missing Cost Control 2573 A large number of service providers (e.g., wireless LAN hot spots) 2574 with complex roaming agreements create a non-transparent cost 2575 structure. In a traditional subscription-based scenario, users are 2576 subscribed to their home network and use this trust relationship to 2577 dynamically establish a financial settlement between the visited 2578 network and the home network. Additionally, security associations 2579 are dynamically established as part of this procedure. This is the 2580 typical AAA deployment scenario. In these scenarios users do not 2581 learn the identity of the access network as part of a regular 2582 authentication and key exchange protocol message exchange. The 2583 identity of the access network is possibly never revealed (in a 2584 secure fashion). The user is therefore only authenticated to the home 2585 network (and hopefully vice versa). While issuing a QoS reservation 2586 request to the next NSIS peer (for example in the access network), 2587 the end host is typically unaware of the cost of such an end-to-end 2588 QoS reservation. Without knowing the costs it is not possible to 2589 reject a too expensive QoS reservation. 2591 Currently there is no standardized protocol available which allows 2592 users to communicate cost limits, to request cost information for 2593 network resources or to learn already accumulated costs for a 2594 particular reservation. 2596 Especially in mobility environments - where an end host is likely to 2597 have access to different networks within a short time period - cost 2598 control is even more complicated. 2600 Some protocol proposals try to merge existing mobility protocols with 2601 QoS signaling (i.e., a form of in-band signaling). Thereby the access 2602 network is queried (towards the crossover router or the MAP) for the 2603 possibility of making a QoS reservation (without actually making the 2604 reservation itself). Without a query mechanism, a user cannot take 2605 reservation costs into account when choosing between different access 2606 networks (or different access routers). Hence, the user might be able 2607 to refuse a more expensive service provider. The ability to allow a 2608 user to choose between different providers might be required - not 2609 only because of the availability of different access technologies 2610 (e.g., IEEE 802.1x, Bluetooth, UTRAN) and different service quality 2611 offered, but also for cost reasons. 2613 Although real-time notifications of QoS reservation costs (cost 2614 control) to the user are out of the scope of NSIS, some interaction 2615 might be required. 2617 12.6.2. Implications for Price Determination 2619 The problem of determining the price of a QoS reservation has been 2620 mentioned in [NSIS-AAA] and closely relates to integrating the end 2621 host into the process of authorization. Even if the end host is aware 2622 of the price of a QoS reservation during reservation setup the price 2623 might change for a number of reasons: 2625 o First, mobility in general causes a different path to be chosen and 2626 might therefore require a new price determination. End host mobility 2627 is visible to the end host itself, therefore the appropriate actions 2628 can be triggered by the end host to always determine the correct 2629 price. 2631 o Route changes somewhere along the path, e.g., mobility in NEMO 2632 networks or even mobility in ad-hoc networks, create more problems, 2633 since the route change might not be visible for the end host. If 2634 price determination is based on the number of networks traversed and 2635 intermediate nodes which contribute to the total price of a QoS 2636 reservation, then a periodic price query is necessary. Discussions at 2637 the NEMO mailing list already point to this problem [Nemo-ML]. If the 2638 price of QoS reservation is associated with the authorization itself, 2639 then a periodic re-authorization based on the change of prices or on 2640 the accumulated costs is necessary. 2642 12.7. Conclusion 2644 This security considerations section illustrates the importance of 2645 authorization for NSIS in a mobility environment. Performance is 2646 important in mobility environments. Proper security handling accounts 2647 for a high percentage of the total performance. It is important to 2648 consider this aspect in the analysis of mobility proposals. 2650 From the scenarios we can observe the following issues: 2652 - Signaling in the direction of the data path is simpler than in the 2653 opposite direction. 2655 - There are many similarities between the scenarios in Section X (MN 2656 as data sender) and Section Y (CN as data sender) particularly if we 2657 include multi-homing scenarios. 2659 - Most issues are related to authorization problems that appear after 2660 the initial flow setup took place. In this case we speak about the 2661 following problem: "Is an entity allowed to perform the indicated 2662 action." Only a few problems are related to authorization problems 2663 which already appear during the initial signaling message exchange. 2665 - If the data sender triggers the signaling message exchange and also 2666 provides authorization then the complexity can be kept fairly low. 2668 - NSLP authorization decisions should be treated separately from 2669 authorization decisions which affect the signaling message exchange. 2671 In the [SID] draft we tried to raise the question of a possible 2672 security goal. We list a few variations of this goal: 2674 Version 1: 2676 An off-path adversary MUST NOT be able to inject messages which are 2677 then accepted by NSIS nodes along the path. An NSIS node which once 2678 was along the data path is not treated as an adversary. 2680 Version 2: 2682 Only end points MUST be able to create messages and intermediate NSIS 2683 nodes MUST be able to verify them. 2685 Version 3: 2687 Only the session creator MUST be able to create messages which are 2688 then successfully verifiable by intermediate NSIS nodes. 2690 Based on the first version of the goal it might be necessary to 2691 differentiate between NSIS nodes which are currently part of the 2692 signaling chain (i.e., nodes which are currently part of the NSIS 2693 signaling message processing) and NSIS nodes which previously were 2694 part of this chain. 2696 Furthermore, it might be useful to differentiate between different 2697 messages: 2699 - Refresh, delete or update messages: I assume that these messages 2700 are not idempotent and hence previous state along some nodes has to 2701 be established already. To provide security for the 'different peer' 2702 case it might still be required to provide some security for the 2703 session identifier. This issue is, however, not as dangerous as the 2704 threat described in the SID draft. 2706 - Create messages: This message is particularly dangerous since it 2707 requires (in case of a sender-initiated message) no previous state. 2708 The threat description in the SID draft is immediately applicable. A 2709 receiver-initiated signaling message is, from a session identifier 2710 point of view, better since previously created state can be used. 2711 This might provide some security, although not too much considering 2712 the limited capabilities of the responder to truly provide some 2713 additional authorization capabilities (due to missing end-to-end 2714 security protection or in case of signaling proxies). 2716 - Query alike messages: These message types require little protection 2717 since they do little harm to the state. They still might allow an 2718 adversary to gain information about the reserved resources. 2720 - Error messages: These messages are also sensitive but are typically 2721 returned after a request was submitted. This is, however, not true 2722 for asynchronous error messages. Still some state has to be created 2723 to allow routing along the established path. 2725 Currently, this analysis does not consider the different message 2726 types. 2728 As a final conclusion we must state that more discussion is necessary 2729 to address security and mobility handling in an appropriate way. 2730 Particularly, the expected NSIS signaling behavior must be described. 2731 The improvements due to mobility functionality within NSIS must be 2732 compared with the increased complexity. Careful analysis and 2733 performance evaluations are necessary. 2735 13. Contributors 2737 This draft initially written by Roland Bless, Xiaoming Fu, Robert 2738 Hancock, Seong-Ho Jeong, Cornelia Kappler, Sung-Hyuck Lee, Jukka 2739 Manner, Paulo Mendes, and Hannes Tschofenig. 2741 14. Acknowledgments 2743 This draft is based on four earlier drafts by (in alphabetical order) 2744 Jongho Bang, Roland Bless, Xiaoming Fu, Robert Hancock, Seong-Ho 2745 Jeong, Cornelia Kappler, Sung-Hyuck Lee, Byoung-Joon Lee, Jukka 2746 Manner, Paulo Mendes, Henning Schulzrinne, Charles Q. Shen, and 2747 Hannes Tschofenig. 2749 15. Informative References 2751 [mipv4] Perkins, C., "IP Mobility Support for IPv4," RFC 3344, Aug. 2752 2002. 2754 [mipv6] Johnson, D., Perkins, C. and J. Arkko, Mobility Support in 2755 IPv6, draft-ietf-mobileip-ipv6-24 (work in progress), June 2003. 2757 [lmm] Carl Williams, "Localized Mobility Management Requirements", 2758 draft-ietf-mipshop-lmm-requirements-00 (work in progress), Oct 2003. 2760 [fmip] Koodli, R., "Fast Handovers for Mobile IPv6", 2761 draft-ietf-mipshop-fast-mipv6-00 (work in progress), Oct 2003. 2763 [hmipv6] Soliman, H., Castelluccia, C., Malki, K. and L. Bellier, 2764 "Hierarchical Mobile IPv6 mobility management (HMIPv6)", 2765 draft-ietf-mipshop-hmipv6-00 (work in progress), Oct. 2003. 2767 [nsis-fw] Hancock, R. and et al., "Next Steps in Signaling: 2768 Framework", draft-ietf-nsis-fw-04 (work in progress), Sept 2003. 2770 [ntlp] Schulzrinne, H. and R. Hancock, "GIMPS: General Internet 2771 Messaging Protocol for Signaling", draft-ietf-nsis-ntlp-00 (work in 2772 progress), Oct. 2003. 2774 [nsis-req] Brunner, M., "Requirements for Signaling Protocols", 2775 draft-ietf-nsis-req-09 (work in progress), August 2003. 2777 [nsis-analysis] Manner, J., Fu, X. and P. Pan, "Analysis of Existing 2778 Quality of Service Signaling Protocols", 2779 draft-ietf-nsis-signalling-analysis-03 (work in progress), Oct 2003. 2781 [RFC2205] Braden, R., Zhang, L., Berson, S., Herzog, S. and S. Jamin, 2782 "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional 2783 Specification", RFC 2205, Sep 1997. 2785 [RFC2746] Terzis, A., Wroclawski, J. and L. Zhang, "RSVP Operation 2786 Over IP Tunnels", RFC 2746, January 2000. 2788 [RFC3583] Chaskar, H., "Requirements of a Quality of Service (QoS) 2789 Solution for Mobile IP", RFC 3583, September 2003. 2791 [manner02] Manner, J., Lopez, A., Mihailovic, A., Velayos, H., 2792 Hepworth, E. and Y. Khouaja, "Evaluation of mobility and QoS 2793 interaction", Computer Networks vol.38, no.2, pp.137-163, February 2794 2002. 2796 [Seamoby-terms] Jukka Manner, Markku Kojo (editors) Mobility Related 2797 Terminology Internet Draft (work in progress), November, 2003. 2799 [RFC2961] Berger, L., Gan, D., Swallow, G., Pan, P., Tommasi, F. and 2800 S. Molendini, "RSVP Refresh Overhead Reduction Extensions", RFC 2961, 2801 April 2001. 2803 [I-D.schulzrinne-nsis-casp] Schulzrinne, H. and et al., "CASP - 2804 Cross-Application Signaling Protocol", draft-schulzrinne-nsis-casp-01 2805 (work in progress), March 2003. 2807 [fu03] Fu, X., Schulzrinne, H. and H. Tschofenig, "Mobility Support 2808 for Next-Generation Internet Signaling Protocols", Proceedings of 2809 IEEE Vehicular Technology Conference 2003-Fall, October 2003. 2811 [I-D.ietf-nsis-qos-nslp] Van den Bosch, S. and et al., "NSLP for 2812 Quality-of-Service signaling", draft-iet f-nsis-qos-nslp-00 (work in 2813 progress), September 2003. 2815 [I-D.westphal-nsis-qos-mobileip] Westphal, C. and H. Chaskar, "QoS 2816 Signaling Framework for Mobile IP", 2817 draft-westphal-nsis-qos-mobileip-00 (work in progress), June 2002. 2819 [SID] Tschofenig, H. et al.: "Security Implications of the Session 2820 Identifier", , (work in progress), 2821 June 2003. 2823 [CTP-Interop] "A Framework for Interoperation between NSIS and CTP", 2824 , (work in progress), 2825 October, 2003. 2827 [NSIS-AAA] Tschofenig, H., et al.: "NSIS Authentication, 2828 Authorization and Accounting Issues", 2829 , (work in progress), 2830 March 2003. 2832 [NSIS-Authz] Tschofenig, H., et al.: "QoS NSLP Authorization Issues", 2833 , (work in progress), 2834 June 2003. 2836 [Nemo-ML] Alper, Y., "[nemo] AAA and NEMO", discussion in the IETF 2837 Nemo Mailing List (available at: 2838 http://www.nal.motlabs.com/pipermail/nemo/2003-February/000271.html), 2839 February 2003. 2841 [Lee01] S.-H. Lee, and et al., 2842 "Mobility Functions in the QoS NSLP", Internet Draft, Work in 2843 progress, October 2003. 2845 [Jeong01] S.-H. Jeong, and et al., 2846 "Mobility Functions in the NTLP", Internet Draft, Work in 2847 progress, October 2003. 2849 [I-D.thomas-nsis-rsvp-analysis] Thomas, M., "Analysis of Mobile 2850 IP and RSVP Interactions", draft-thomas-nsis-rsvp-analysis-00 2851 (work in progress), November 2002. 2853 16. Author's Addresses 2855 Questions about this document may be directed to: 2857 Roland Bless 2858 Institute of Telematics, Universitaet Karlsruhe (TH) 2859 Zirkel 2 2860 76128 Karlsruhe 2861 Germany 2862 EMail: bless@tm.uka.de 2863 URI: http://www.tm.uka.de/~bless/ 2864 Xiaoming Fu 2865 University of Goettingen 2866 Telematics Group 2867 Lotzestr. 16-18 2868 Goettingen 37083 2869 Germany 2870 E-Mail: fu@cs.uni-goettingen.de 2872 Robert Hancock 2873 Siemens/Roke Manor Research Ltd 2874 Romsey, Hants, SO51 0ZN 2875 United Kingdom 2876 Voice: +44-1794-833601 2877 Fax: +44-1794-833434 2878 E-Mail: robert.hancock@roke.co.uk 2880 Seong-Ho Jeong 2881 Hankuk University of FS 2882 89 Wangsan, Mohyun 2883 Yongin-si, Gyeonggi-do 449-791 2884 Korea 2885 Phone: +82 31 330 4642 2886 E-Mail: shjeong@hufs.ac.kr 2888 Cornelia Kappler 2889 Siemens AG 2890 Siemensdamm 62 2891 Berlin 13627 2892 Germany 2893 EMail: cornelia.kappler@siemens.com 2895 Sung-Hyuck Lee 2896 SAMSUNG Advanced Institute of Technology 2897 San 14-1, Nongseo-ri, Giheung-eup 2898 Yongin-si, Gyeonggi-do 449-712 2899 KOREA 2900 Voice: +82-31-280-9585 2901 Fax: +82-31-280-9569 2902 E-Mail: starsu.lee@samsung.com 2904 Jukka Manner 2905 Department of Computer Science 2906 University of Helsinki 2907 P.O. Box 26 (Teollisuuskatu 23) 2908 FIN-00014 HELSINKI 2909 Finland 2910 Voice: +358-9-191-44210 2911 Fax: +358-9-191-44441 2912 E-Mail: jmanner@cs.helsinki.fi 2914 Paulo Mendes 2915 DoCoMo Communications Laboratories Europe GmbH 2916 Landsberger Str. 312 2917 80687 Munich, Germany 2918 Voice: +49-89-56824-226 2919 Fax: +49-89-56824-300 2920 E-mail: mendes@docomolab-euro.com 2922 Hannes Tschofenig 2923 Siemens AG 2924 Otto-Hahn-Ring 6 2925 81739 Munich 2926 Germany 2927 EMail: Hannes.Tschofenig@siemens.com 2929 Full Copyright Statement 2931 Copyright (C) The Internet Society (2003). All Rights Reserved. 2933 This document and translations of it may be copied and furnished to 2934 others, and derivative works that comment on or otherwise explain it 2935 or assist in its implementation may be prepared, copied, published 2936 and distributed, in whole or in part, without restriction of any 2937 kind, provided that the above copyright notice and this paragraph are 2938 included on all such copies and derivative works. However, this 2939 document itself may not be modified in any way, such as by removing 2940 the copyright notice or references to the Internet Society or other 2941 Internet organizations, except as needed for the purpose of 2942 developing Internet standards in which case the procedures for 2943 copyrights defined in the Internet Standards process must be 2944 followed, or as required to translate it into languages other than 2945 English. 2947 The limited permissions granted above are perpetual and will not be 2948 revoked by the Internet Society or its successors or assigns. 2950 This document and the information contained herein is provided on an 2951 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 2952 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 2953 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 2954 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 2955 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.