idnits 2.17.1 draft-wing-mmusic-ice-mobility-07.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (June 17, 2014) is 3594 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC5389' is defined on line 532, but no explicit reference was found in the text == Unused Reference: 'RFC5763' is defined on line 554, but no explicit reference was found in the text == Unused Reference: 'RFC6982' is defined on line 567, but no explicit reference was found in the text == Outdated reference: A later version (-03) exists of draft-wing-tram-turn-mobility-00 ** Obsolete normative reference: RFC 5245 (Obsoleted by RFC 8445, RFC 8839) ** Obsolete normative reference: RFC 5389 (Obsoleted by RFC 8489) ** Obsolete normative reference: RFC 5766 (Obsoleted by RFC 8656) -- Obsolete informational reference (is this intentional?): RFC 5077 (Obsoleted by RFC 8446) -- Obsolete informational reference (is this intentional?): RFC 6982 (Obsoleted by RFC 7942) Summary: 3 errors (**), 0 flaws (~~), 5 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MMUSIC D. Wing 3 Internet-Draft T. Reddy 4 Intended status: Standards Track P. Patil 5 Expires: December 19, 2014 P. Martinsen 6 Cisco 7 June 17, 2014 9 Mobility with ICE (MICE) 10 draft-wing-mmusic-ice-mobility-07 12 Abstract 14 This specification describes how endpoint mobility can be achieved 15 using ICE. 17 Status of this Memo 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF). Note that other groups may also distribute 24 working documents as Internet-Drafts. The list of current Internet- 25 Drafts is at http://datatracker.ietf.org/drafts/current/. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 This Internet-Draft will expire on December 19, 2014. 34 Copyright Notice 36 Copyright (c) 2014 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (http://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 described in the Simplified BSD License. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 2. Notational Conventions . . . . . . . . . . . . . . . . . . . . 3 53 3. Break Before Make . . . . . . . . . . . . . . . . . . . . . . 4 54 3.1. Absence of other interfaces in Valid list . . . . . . . . 5 55 3.1.1. Receiving ICE Mobility event . . . . . . . . . . . . . 6 56 3.2. Keeping unused relayed candidates active . . . . . . . . . 7 57 3.3. New STUN Attributes . . . . . . . . . . . . . . . . . . . 8 58 4. Make Before Break . . . . . . . . . . . . . . . . . . . . . . 8 59 5. Comparison to ICE Restart and Trickle ICE . . . . . . . . . . 8 60 5.1. Break Before Make - ICE Restart . . . . . . . . . . . . . 9 61 5.2. Break Before Make - Trickle ICE . . . . . . . . . . . . . 10 62 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 63 7. Security Considerations . . . . . . . . . . . . . . . . . . . 11 64 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 65 9. Change History . . . . . . . . . . . . . . . . . . . . . . . . 11 66 9.1. Changes from draft-wing-mmusic-ice-mobility-00 to -01 . . 11 67 9.2. Changes from draft-wing-mmusic-ice-mobility-01 to -02 . . 11 68 9.3. Changes from draft-wing-mmusic-ice-mobility-02 to -03 . . 11 69 9.4. Changes from draft-wing-mmusic-ice-mobility-03 to -04 . . 12 70 9.5. Changes from draft-wing-mmusic-ice-mobility-04 to -05 . . 12 71 9.6. Changes from draft-wing-mmusic-ice-mobility-05 to -06 . . 12 72 9.7. Changes from draft-wing-mmusic-ice-mobility-06 to -07 . . 12 73 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 74 10.1. Normative References . . . . . . . . . . . . . . . . . . . 12 75 10.2. Informative References . . . . . . . . . . . . . . . . . . 12 76 Appendix A. . . . . . . . . . . . . . . . . . . . . . . . . . . 13 77 A.1. Presence of other interfaces in Valid list . . . . . . . . 13 78 A.1.1. Receiving ICE Mobility event . . . . . . . . . . . . . 14 79 A.2. Losing an Interface . . . . . . . . . . . . . . . . . . . 14 80 A.2.1. Keeping unused candidates in the valid list active . . 15 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 83 1. Introduction 85 When moving between networks, an endpoint has to change its IP 86 address. This change breaks upper layer protocols such as TCP and 87 RTP. Various techniques exist to prevent this breakage, all tied to 88 making the endpoint's IP address static (e.g., Mobile IP, Proxy 89 Mobile IP, LISP). Other techniques exist, which make the upper layer 90 protocol ambivalent to IP address changes (e.g., SCTP). The 91 mechanisms described in this document are in that last category. 93 ICE [RFC5245] ensures two endpoints have a working media path between 94 them, and is typically used by Internet-connected interactive media 95 systems (e.g., SIP endpoints). ICE does not expect either the local 96 host or the remote host to change their IP addresses. Although ICE 97 does allow an "ICE restart", this is done by sending a re-INVITE 98 which goes over the SIP signaling path. The SIP signaling path is 99 often slower than the media path (which needs to be recovered as 100 quickly as possible), consumes an extra half round trip, and incurs 101 an additional delay if the mobility event forces the endpoint to re- 102 connect with its SIP proxy. When a device changes its IP address, it 103 is necessary for it to re-establish connectivity with its SIP proxy, 104 which can be performed in parallel with the steps described in this 105 document. This document describes how mobility is performed entirely 106 in the media path, without the additional delay of re-establishing 107 SIP connectivity, issuing a new offer/answer, or the complications of 108 multiple SIP offers. This document considers re-establishing bi- 109 directional media the most critical aspect of a successful mobility 110 event, and its efforts are towards meeting that goal. 112 This document proposes a mechanism to achieve RTP mobility when both 113 endpoints support MICE. When both endpoints support MICE, ICE itself 114 can be used to provide mobility. When only one endpoint supports 115 MICE, a TURN server provides mobility as described in 116 [I-D.wing-tram-turn-mobility]. Both mobility techniques work across 117 and between network types (e.g., between 3G and wired Internet 118 access), so long as the client can still access the remote ICE peer 119 or TURN server. 121 Readers are assumed to be familiar with ICE [RFC5245]. 123 2. Notational Conventions 125 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 126 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 127 document are to be interpreted as described in [RFC2119]. 129 This note uses terminology defined in [RFC5245], and the following 130 additional terminology: 132 Break Before Make: The initially selected interface for 133 communication may become unavailable (e.g due to loss of coverage 134 when moving out of a WiFi hotspot) and new interfaces may become 135 available due to administrative action (e.g manual activation of a 136 specific connectivity technology) or due to dynamic conditions 137 (e.g. Entering coverage area of a wireless network). 139 Make Before Break: The initially selected interface for 140 communication may become deprioritized (e.g new interface becoming 141 available and it's per bit cost is cheaper and the connection 142 speed is faster than existing interface used for communication). 144 Simultaneous Mobility: If both the endpoints are mobile and roam at 145 the same time between networks. 147 3. Break Before Make 149 When both endpoints support ICE, ICE itself can provide mobility 150 functions. One of the primary aspects of ICE is its address 151 gathering, wherein ICE has each endpoint determine all of the IP 152 addresses and ports that might be usable for that endpoint and 153 communicate that list of addresses and ports to its peer, usually 154 over SDP. That enables the next primary aspect of ICE, which is its 155 connectivity checks: each ICE endpoint sends a connectivity check 156 from a checklist created by the local and remote candidates exchanged 157 in the initial offer/answer exchange. When the ICE endpoint checks 158 the mapped address from the STUN response during ICE connectivity 159 checks and finds that the transport address does not match any of the 160 local candidates that the ICE agent knows about, the mapped address 161 represents a new candidate -- a peer reflexive candidate. This will 162 cause the endpoint to construct a new pair and insert it into the 163 local checklist (Section 7.2.1.3 of [RFC5245]). ICE Mobility (MICE) 164 takes advantage of that existing ICE functionality to provide faster 165 mobility. 167 Endpoints that support ICE Mobility perform ICE normally, and MUST 168 also include the MOBILITY-SUPPORT attribute in all of their STUN 169 requests and their STUN responses. The inclusion of this attribute 170 allows the ICE peer to determine if it can achieve mobility using ICE 171 or needs to use TURN. To force the use of TURN to achieve ICE 172 mobility, the ICE endpoint SHOULD NOT respond to ICE connectivity 173 checks that have an IP address and port different from the TURN 174 server, unless those connectivity checks contain the MOBILITY-SUPPORT 175 attribute. In this way, the remote peer will think those other 176 candidates are invalid (because its connectivity checks did not 177 succeed). 179 After concluding ICE and moving to the ICE completed state (see 180 Section 8 of [RFC5245]) either endpoint or both endpoints can 181 initiate ICE Mobility, no matter if it was the Controlling Agent or 182 the Controlled Agent during normal ICE processing. 184 3.1. Absence of other interfaces in Valid list 186 When the interface currently being used for communication becomes 187 unavailable then ICE agent acquires a list of interfaces that are 188 available and based on the locally configured host policy 189 preferences, the ICE endpoint performs ICE Mobility using one of the 190 available interfaces. In this case local candidates from the 191 selected interface are not present in the valid list. ICE Mobility 192 is performed by: 194 1. The ICE agent remembers the remote host/server reflexive/peer 195 reflexive candidates for each component of the media streams 196 previously used from the valid list before clearing its ICE check 197 list and ICE Valid List. 199 2. The ICE endpoint gathers host candidates of the same address 200 family as the remote peer on the new interface, forms a check 201 list by creating candidate pairs with local host candidates and 202 remote host/server-reflexive candidates collected in step 1, 203 performs "Computing Pair Priority and Ordering Pairs" (Section 204 5.7.2 of [RFC5245]), "Pruning the Pairs" (Section 5.7.3 of 205 [RFC5245], "Computing states" (Section 5.7.4 of [RFC5245]). 207 3. The ICE endpoint initiates ICE connectivity checks on those 208 candidates from the check list in the previous step, and includes 209 the MOBILITY-EVENT attribute in those connectivity checks. 211 4. The ICE endpoint acts as controlling agent and the ICE 212 connectivity check from the previous step SHOULD also include the 213 USE-CANDIDATE attribute to signal an aggressive nomination (see 214 Section 2.6 of [RFC5245]). 216 5. The ICE endpoint performs "Discovering Peer Reflexive Candidates" 217 (Section 7.1.3.2.1 of [RFC5245]), "Constructing a Valid Pair" 218 (Section 7.1.3.2.2 of [RFC5245]), "Updating Pair States" (Section 219 7.1.3.2.3 of [RFC5245]), and "Updating the Nominated Flag" 220 (Section 7.1.3.2.4 of [RFC5245]). When the valid list contains a 221 candidate pair for each component then ICE processing is 222 considered complete for the media stream and ICE agent can start 223 sending media using the nominated candidate pair. 225 6. Once ICE connectivity checks for all of the media streams are 226 completed, the controlling ICE endpoint follows the procedures in 227 Section 11.1 of [RFC5245], specifically to send updated offer if 228 the candidates in the m and c lines for the media stream (called 229 the DEFAULT CANDIDATES) do not match ICE's SELECTED CANDIDATES 230 (also see Appendix B.9 of [RFC5245]). 232 The ICE endpoint even after Mobility using ICE is successful can 233 issue an updated offer indicating ICE restart if connectivity checks 234 using higher priority candidate pairs are not successful. 236 Mobility using ICE could fail in case of Simultaneous Mobility or if 237 the ICE peer is behind NAT that performs Address-Dependent Filtering 238 (see Section 5 of [RFC5245]). Hence the ICE endpoint in parallel 239 will re-establish connection with the SIP proxy. It will then 240 determine whether to initiate ICE restart under the following 241 conditions: 243 a. After re-establishing connection with the SIP proxy and before 244 sending new offer to initiate ICE restart if Mobility using ICE 245 is successful then stop sending the new offer. 247 b. After successful negotiation of updated offer/answer to initiate 248 ICE restart, proceed with ICE restart and stop Mobility using ICE 249 if ICE checks are in the Running/Failed states or ICE is 250 partially successful and not yet reached ICE complete state. 251 It's not implementation friendly to have to two checks running in 252 parallel. ICE restart can re-use partial successful ICE 253 connectivity check results from Mobility using ICE if required as 254 optimization. 256 3.1.1. Receiving ICE Mobility event 258 A STUN Binding Request containing the MOBILITY-EVENT attribute MAY be 259 received by an ICE endpoint. The agent MUST use short-term 260 credential to authenticate the STUN request containing the MOBILITY- 261 EVENT attribute and perform a message integrity check. The ICE 262 endpoint will generate STUN Binding Response containing the MOBILE- 263 SUPPORT attribute and the ICE agent takes role of controlled agent. 264 If STUN Request containing the MOBILITY-EVENT attribute is received 265 before the endpoint is in the ICE Completed state, it should be 266 silently discarded. 268 The agent remembers the highest-priority nominated pairs in the Valid 269 list for each component of the media stream, called the previous 270 selected pairs before removing all the selected candidate pairs from 271 the Valid List . It continues sending media to that address until it 272 finishes with the steps described below. Because those packets might 273 not be received due to the mobility event, it MAY cache a copy of 274 those packets. 276 1. The ICE endpoint constructs a pair whose local candidate is equal 277 to the transport address on which the STUN request was received 278 with MOBILITY-EVENT, USE-CANDIDATE attributes and a remote 279 candidate equal to the source transport address where the STUN 280 request came from. 282 2. The ICE endpoint will add this pair to the valid list if not 283 already present. 285 3. The agent sets the nominated flag for that pair in the valid pair 286 to true. ICE processing is considered complete for a media 287 stream if the valid list contains a selected candidate pair for 288 each component and ICE agent can start sending media. 290 The ICE endpoint will follow Steps 1 to 3 when subsequent STUN 291 Binding Requests are received with MOBILITY-EVENT and USE-CANDIDATE 292 attributes. 294 3.2. Keeping unused relayed candidates active 296 The ICE endpoints can maintain the relayed candidates active even 297 when not actively used, so that relayed candidates can be tried if 298 ICE connectivity checks using other candidate types fails. The ICE 299 agent will have to create permissions in the TURN server for the 300 remote relayed candidate IP addresses and perform the following 301 steps: 303 1. The ICE agent will keep the relayed candidates alive using 304 Refresh transaction, as described in [RFC5766]. 306 2. When the endpoint IP address changes due to mobility, the ICE 307 agent will refresh it's allocation with TURN server using 308 [I-D.wing-tram-turn-mobility]. 310 3. The ICE agent will pair local and remote relayed candidates for 311 connectivity checks when performing the steps in Section 3.1. 313 4. If the ICE connectivity check succeeds only with local and remote 314 relayed candidates, it suggests that either other peer is roaming 315 at the same time or is behind Address-Dependent Filtering NAT. 316 The ICE agent adds the relayed candidate pair to the valid list 317 and marks it as selected. The ICE agent can now send media using 318 the newly selected relayed candidate pair. The Mobile device 319 must re-establish connection with SIP proxy, issue an updated 320 offer indicating ICE restart so that media can switched to 321 higher-priority candidate pairs. 323 This approach assists Mobility using ICE to succeed but brings in 324 additional overhead of maintaining relayed candidates.In case of 325 Simultaneous Mobility, host candidates can change for both the 326 endpoints by maintaining relayed candidates and using 327 [I-D.wing-tram-turn-mobility], media session can be established using 328 the relayed candidate pair. 330 3.3. New STUN Attributes 332 Three new attributes are defined by this section: MOBILITY-EVENT, 333 MOBILITY-SUPPORT. 335 The MOBILITY-EVENT attribute indicate the sender experienced a 336 mobility event. This attribute has no value, thus the attribute 337 length field MUST always be 0. Rules for sending and interpretation 338 of receiving are described above. 340 The MOBILITY-SUPPORT attribute indicates the sender supports ICE 341 Mobility, as defined in this document. This attribute has no value, 342 thus the attribute length field MUST always be 0. Rules for sending 343 and interpretation of receiving are described above. 345 4. Make Before Break 347 When a new interface comes up and initially selected interface 348 becomes deprioritized (e.g due to a low cost interface becoming 349 available). The ICE endpoint re-connects to the SIP proxy using the 350 new interface, gather candidates, exchange updated offer/exchange to 351 restart ICE. Once ICE processing has reached the Completed state 352 then the ICE endpoint can successfully switch the media over to the 353 new interface. The interface initially used for communication can 354 now be turned off without disrupting communications. 356 5. Comparison to ICE Restart and Trickle ICE 358 There has been some concern that ICE Mobility is unnecessary, and 359 that an ICE restart (section 9.1.1.1 of [RFC5245]) would provide 360 exactly the same functionality as ICE Mobility. These sections 361 examine how ICE restart and Trickle ICE 362 [I-D.rescorla-mmusic-ice-trickle] compare with ICE Mobility. 364 5.1. Break Before Make - ICE Restart 366 o If ICE Restart is used for RTP Mobility then in case of Break 367 before Make, 369 1. Before the endpoint can send an ICE restart message, it has to 370 first re-establish communication with its SIP proxy. This 371 consumes one round-trip for both TCP and UDP. If the 372 connection is protected with TLS (TCP) or DTLS (UDP), we can 373 assume TLS session resumption [RFC5077] will be used to reduce 374 the number of TLS messages. With TLS session resumption, this 375 consumes 1 round trip. If TLS session resumption is not 376 available, a full TLS handshake consumes 2 round trips. This 377 is a total of 2 round trips (with session resumption) to 3 378 round trips (without session resumption), which is multiplied 379 by the round trip time to the SIP proxy. The round trip time 380 is dependent on a particular network or deployment, for 381 example in second (2.5G), third (3G) generation wireless 382 networks and satellite communication round trip time could be 383 higher than 250ms. These calculations are only considering 384 the network round-trip time and do not consider the wall-clock 385 time to validate the TLS certificates or generate the TLS keys 386 on the TLS client or the TLS server, which would make this 387 longer. 389 2. While performing the above steps to re-establish SIP 390 connectivity with its SIP proxy, the endpoint will gather host 391 candidates which incur no network traffic, server-reflexive 392 candidates which incur a round-trip to a STUN server, and 393 relayed candidates which incurs three round trips (two for re- 394 authentication and one for creating the TURN permission). The 395 STUN and TURN communications can be performed in parallel with 396 the SIP connectivity check from step (1), above. 398 3. The endpoints through the SIP server will exchange offer/ 399 answer. The SIP server could also be located halfway around 400 the world from the endpoints and the delay could be 401 significant. For SIP over UDP the endpoint will have send a 402 SIP request and wait for the response to arrive. 404 4. ICE restart requires sending a new INVITE. A new INVITE 405 cannot be sent if there is an open SIP dialog, such as a 406 previous INVITE. This means rapid mobility events will not 407 work well, and there is also an increased likelihood for glare 408 (both endpoints sending INVITEs at the same time). 410 5.2. Break Before Make - Trickle ICE 412 o If Trickle ICE [I-D.rescorla-mmusic-ice-trickle] is used for RTP 413 Mobility then in case of Break before Make, 415 1. Trickle ICE can begin connectivity checks while the endpoint 416 is still gathering candidates and can considerably shorten the 417 time necessary for ICE processing to complete. It still 418 involves the overhead of step 1 explained in section 419 Section 5.1. 421 2. The endpoint would learn host candidates and inform them to 422 the remote peer in offer, the remote peer will provide its 423 candidates in answer. The host, server reflexive, peer 424 reflexive and relayed candidates of the remote peer may not 425 change and the remote peer does not have to gather the 426 candidates again. Trickle ICE will test local host candidates 427 with all types of remote candidates provided by the remote 428 peer in the answer. 430 a. If the endpoint is not behind NAT and the ICE peer is 431 behind NAT performing endpoint dependent filtering (or 432 firewall blocking unsolicited incoming traffic) then ICE 433 connectivity checks initiated by the endpoint to the 434 remote peer will succeed as a consequence of suicide ICE 435 connectivitivy check packets. 437 b. If the endpoint is behind NAT and ICE peer is behind 438 endpoint-dependent filtering NAT then ICE connectivity 439 checks using the first offer/answer will fail but will 440 later succeed in subsequent offer/answer where the 441 endpoint provides server-reflexive candidates. 443 3. Trickle ICE must be supported by both endpoints for it be 444 used. 446 o If both endpoints support TRICKLE ICE then it is RECOMMENDED that 447 TRICKLE ICE be tried instead of ICE restart in steps (a) and (b) 448 of Section 3.1. 450 6. IANA Considerations 452 IANA is requested to add the following attributes to the STUN 453 attribute registry [iana-stun], 455 o MOBILITY-EVENT (0x802, in the comprehension-required range) 456 o MOBILITY-SUPPORT (0x8000, in the comprehension-optional range) 458 7. Security Considerations 460 A mobility event only occurs after both ICE endpoints have exchanged 461 their ICE information. Thus, both username fragments are already 462 known to both endpoints. Each endpoint contributes at least 24 bits 463 of randomness to the ice-ufrag (Section 15.4 of [RFC5245]), which 464 provides 48 bits of randomness. An off-path attacker would have to 465 guess those 48 bits to cause the endpoints to perform HMAC-SHA1 466 validation of the MESSAGE-INTEGRITY attribute. 468 An attacker on the path between the ICE endpoints will see both ice- 469 ufrags, and can cause the endpoints to perform HMAC-SHA1 validation 470 by sending messages from any IP address. 472 8. Acknowledgements 474 Thanks to Alfred Heggestad, Lishitao, Sujing Zhou, Martin Thomson, 475 Emil Ivov for review and comments. 477 9. Change History 479 [Note to RFC Editor: Please remove this section prior to 480 publication.] 482 9.1. Changes from draft-wing-mmusic-ice-mobility-00 to -01 484 o Updated section 3 486 9.2. Changes from draft-wing-mmusic-ice-mobility-01 to -02 488 o Updated Introduction, Notational Conventions, sections 3.1, 3.2. 490 o Updated section 3.5 492 9.3. Changes from draft-wing-mmusic-ice-mobility-02 to -03 494 o Moved sections Presence of other interfaces in Valid list, Losing 495 an Interface to Appendix. 497 9.4. Changes from draft-wing-mmusic-ice-mobility-03 to -04 499 o Added Section 6. 501 9.5. Changes from draft-wing-mmusic-ice-mobility-04 to -05 503 o Updated Section 6. 505 9.6. Changes from draft-wing-mmusic-ice-mobility-05 to -06 507 o Updated Section 5. 509 o Added Implementation Status section. 511 9.7. Changes from draft-wing-mmusic-ice-mobility-06 to -07 513 o Removed Turn Mobility 515 10. References 517 10.1. Normative References 519 [I-D.wing-tram-turn-mobility] 520 Wing, D., Patil, P., Reddy, T., and P. Martinsen, 521 "Mobility with TURN", draft-wing-tram-turn-mobility-00 522 (work in progress), June 2014. 524 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 525 Requirement Levels", BCP 14, RFC 2119, March 1997. 527 [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment 528 (ICE): A Protocol for Network Address Translator (NAT) 529 Traversal for Offer/Answer Protocols", RFC 5245, 530 April 2010. 532 [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, 533 "Session Traversal Utilities for NAT (STUN)", RFC 5389, 534 October 2008. 536 [RFC5766] Mahy, R., Matthews, P., and J. Rosenberg, "Traversal Using 537 Relays around NAT (TURN): Relay Extensions to Session 538 Traversal Utilities for NAT (STUN)", RFC 5766, April 2010. 540 10.2. Informative References 542 [I-D.rescorla-mmusic-ice-trickle] 543 Rescorla, E., Uberti, J., and E. Ivov, "Trickle ICE: 545 Incremental Provisioning of Candidates for the Interactive 546 Connectivity Establishment (ICE) Protocol", 547 draft-rescorla-mmusic-ice-trickle-01 (work in progress), 548 October 2012. 550 [RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig, 551 "Transport Layer Security (TLS) Session Resumption without 552 Server-Side State", RFC 5077, January 2008. 554 [RFC5763] Fischl, J., Tschofenig, H., and E. Rescorla, "Framework 555 for Establishing a Secure Real-time Transport Protocol 556 (SRTP) Security Context Using Datagram Transport Layer 557 Security (DTLS)", RFC 5763, May 2010. 559 [RFC5780] MacDonald, D. and B. Lowekamp, "NAT Behavior Discovery 560 Using Session Traversal Utilities for NAT (STUN)", 561 RFC 5780, May 2010. 563 [RFC6263] Marjou, X. and A. Sollaud, "Application Mechanism for 564 Keeping Alive the NAT Mappings Associated with RTP / RTP 565 Control Protocol (RTCP) Flows", RFC 6263, June 2011. 567 [RFC6982] Sheffer, Y. and A. Farrel, "Improving Awareness of Running 568 Code: The Implementation Status Section", RFC 6982, 569 July 2013. 571 [iana-stun] 572 IANA, "IANA: STUN Attributes", April 2011, 573 . 576 Appendix A. 578 A.1. Presence of other interfaces in Valid list 580 This technique is optional and only relevant if there is a host 581 policy to maintain unused candidates on other interfaces using the 582 steps in Appendix A.2.1. ICE Agent can maintain unused candidates on 583 other interfaces if it detects that it is behind Address-Dependent 584 Filtering NAT or Firewall. ICE Agent can detect NAT, Firewall 585 behaviour using the procedure explained in [RFC5780]. When the 586 interface currently being used for media communication becomes 587 unavailable. If other interfaces are available and local candidates 588 from these interfaces are already present in the valid list then ICE 589 endpoint will perform the following steps: 591 1. The ICE endpoint based on the locally configured host policy 592 preferences, will select a interface whose candidates are already 593 present in the valid list. 595 2. The ICE endpoint clears all the pairs in the valid list 596 containing the IP addresses from the interface that become 597 unavailable. 599 3. The ICE endpoint initiates ICE connectivity checks on the 600 selected interface. The ICE endpoint acts as controlling agent 601 and MUST include MOBILITY-EVENT attribute to signal mobility 602 event and SHOULD also include the USE-CANDIDATE attribute to 603 signal an aggressive nomination (see Section 2.6 of [RFC5245]). 604 When all components have a nominated pair in the valid list, 605 media can begin to flow using the highest priority nominated 606 pair. 608 4. The ICE endpoint will re-establish connection with the SIP proxy. 609 Once ICE connectivity checks for all of the media streams are 610 completed, the controlling ICE endpoint follows the procedures in 611 Section 11.1 of [RFC5245], specifically to send updated offer if 612 the candidates in the m and c lines for the media stream (called 613 the DEFAULT CANDIDATES) do not match ICE's SELECTED CANDIDATES 614 (also see Appendix B.9 of [RFC5245]). 616 The ICE endpoint after Mobility using ICE is successful can issue an 617 updated offer indicating ICE restart if higher priority interface 618 becomes available. 620 A.1.1. Receiving ICE Mobility event 622 The ICE endpoint that receives ICE Mobility Event will perform the 623 steps in Section 3.1.1. 625 A.2. Losing an Interface 627 When an interface is lost, the SDP MAY be updated, so that the remote 628 ICE host does not waste its efforts with connectivity checks to that 629 address, as those checks will fail. Because it can be argued that 630 this is merely an optimization, and that the interface loss might be 631 temporary (and soon regained), and that ICE has reasonable 632 accommodation for candidates where connectivity checks timeout, this 633 specification does not strongly encourage updating the SDP to remove 634 a lost interface. 636 Likewise, this specification recommends that ICE candidate addresses 637 in valid list be maintained actively, subject to the host's policy. 638 For example, battery operated hosts have a strong incentive to not 639 maintain NAT binding for server reflexive candidates learnt through 640 STUN Binding Request, as the maintenance requires sending periodic 641 STUN Binding Indication. As another example, a host that is 642 receiving media over IPv6 may not want to persist with keeping a 643 NATted IPv4 mapping alive (because that consumes a NAT mapping that 644 could be more useful to a host actively utilizing the mapping for 645 real traffic). 647 Note: this differs from Section 8.3 of [RFC5245], which encourages 648 abandoning unused candidates. 650 A.2.1. Keeping unused candidates in the valid list active 652 ICE endpoint subject to host policy can continue performing ICE 653 connectivity checks using candidates from other interfaces on the 654 host even after ICE is complete. If valid list contains unused 655 candidate pairs from other interfaces and one of these interfaces can 656 be selected to send to media in case the existing interface used for 657 media is unavailable then ICE endpoint can keep the unused candidate 658 pairs from other interface{s} alive by sending keepalives every NN 659 seconds. It is recommended to only keep host/server-reflexive 660 candidates active in the valid list and not the relayed candidates. 662 A.2.1.1. Sending keep alive requests 664 Application Mechanism for Keeping Alive the NAT Mappings Associated 665 with RTP / RTP Control Protocol (RTCP) Flows [RFC6263] describes 666 various reasons for doing keepalives on inactive streams and how to 667 keep NAT mapping alive. However this specification requires some 668 additional functionality associated with the keepalives. 670 STUN binding requests MUST be used as the keepalive message instead 671 of the STUN Binding indication as specified in [RFC5245]. This is to 672 ensure positive peer consent from the remote side that the candidate 673 pair is still active and in future mobility can be achieved using the 674 steps in Appendix A.1 . The request must include the MOBILITY- 675 SUPPORT attribute. If the STUN binding response matches a pair in 676 the checklist then that candidate pair should be kept in the list. 677 If the STUN transaction fails then the candidate pair will be removed 678 from valid list. 680 A.2.1.2. Receiving keep alive requests 682 Upon receiving a STUN binding request containing a MOBILITY-SUPPORT 683 attribute even when ICE processing is in the Completed state, the ICE 684 endpoint will add this pair to the valid list if not already present 685 and generate STUN Binding Response containing the MOBILE-SUPPORT 686 attribute. 688 Authors' Addresses 690 Dan Wing 691 Cisco Systems, Inc. 692 170 West Tasman Drive 693 San Jose, California 95134 694 USA 696 Email: dwing@cisco.com 698 Tirumaleswar Reddy 699 Cisco Systems, Inc. 700 Cessna Business Park, Varthur Hobli 701 Sarjapur Marathalli Outer Ring Road 702 Bangalore, Karnataka 560103 703 India 705 Email: tireddy@cisco.com 707 Prashanth Patil 708 Cisco Systems, Inc. 709 Cessna Business Park, Varthur Hobli 710 Sarjapur Marthalli Outer Ring Road 711 Bangalore, Karnataka 560103 712 India 714 Email: praspati@cisco.com 716 Paal-Erik Martinsen 717 Cisco Systems, Inc. 718 Philip Pedersens vei 22 719 Lysaker, Akershus 1325 720 Norway 722 Email: palmarti@cisco.com