idnits 2.17.1 draft-wing-mmusic-ice-mobility-06.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 (February 5, 2014) is 3726 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: 'RFC5763' is defined on line 804, but no explicit reference was found in the text ** 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 (~~), 2 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: August 9, 2014 P. Martinsen 6 Cisco 7 February 5, 2014 9 Mobility with ICE (MICE) 10 draft-wing-mmusic-ice-mobility-06 12 Abstract 14 This specification describes how endpoint mobility can be achieved 15 using ICE. Two mechanisms are shown, one where both endpoints 16 support MICE and another where only one endpoint supports MICE. 18 Status of This Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at http://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on August 9, 2014. 35 Copyright Notice 37 Copyright (c) 2014 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (http://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 53 2. Notational Conventions . . . . . . . . . . . . . . . . . . . 4 54 3. Break Before Make . . . . . . . . . . . . . . . . . . . . . . 4 55 3.1. Absence of other interfaces in Valid list . . . . . . . . 5 56 3.1.1. Receiving ICE Mobility event . . . . . . . . . . . . 6 57 3.2. Keeping unused relayed candidates active . . . . . . . . 7 58 3.3. New STUN Attributes . . . . . . . . . . . . . . . . . . . 8 59 4. Make Before Break . . . . . . . . . . . . . . . . . . . . . . 8 60 5. Mobility using TURN . . . . . . . . . . . . . . . . . . . . . 8 61 5.1. Creating an Allocation . . . . . . . . . . . . . . . . . 9 62 5.1.1. Sending an Allocate Request . . . . . . . . . . . . . 9 63 5.1.2. Receiving an Allocate Request . . . . . . . . . . . . 10 64 5.1.3. Receiving an Allocate Success Response . . . . . . . 10 65 5.1.4. Receiving an Allocate Error Response . . . . . . . . 10 66 5.2. Refreshing an Allocation . . . . . . . . . . . . . . . . 11 67 5.2.1. Sending a Refresh Request . . . . . . . . . . . . . . 11 68 5.2.2. Receiving a Refresh Request . . . . . . . . . . . . . 11 69 5.2.3. Receiving a Refresh Response . . . . . . . . . . . . 11 70 5.3. New STUN Attribute MOBILITY-TICKET . . . . . . . . . . . 12 71 5.4. New STUN Error Response Code . . . . . . . . . . . . . . 12 72 6. Comparison to ICE Restart and Trickle ICE . . . . . . . . . . 12 73 6.1. Break Before Make - ICE Restart . . . . . . . . . . . . . 12 74 6.2. Break Before Make - Trickle ICE . . . . . . . . . . . . . 13 75 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 76 8. Implementation Status . . . . . . . . . . . . . . . . . . . . 14 77 8.1. open-sys . . . . . . . . . . . . . . . . . . . . . . . . 15 78 9. Security Considerations . . . . . . . . . . . . . . . . . . . 15 79 9.1. Considerations for ICE mechanism . . . . . . . . . . . . 15 80 9.2. Considerations for TURN mechanism . . . . . . . . . . . . 16 81 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16 82 11. Change History . . . . . . . . . . . . . . . . . . . . . . . 16 83 11.1. Changes from draft-wing-mmusic-ice-mobility-00 to -01 . 16 84 11.2. Changes from draft-wing-mmusic-ice-mobility-01 to -02 . 16 85 11.3. Changes from draft-wing-mmusic-ice-mobility-02 to -03 . 16 86 11.4. Changes from draft-wing-mmusic-ice-mobility-03 to -04 . 16 87 11.5. Changes from draft-wing-mmusic-ice-mobility-04 to -05 . 16 88 11.6. Changes from draft-wing-mmusic-ice-mobility-05 to -06 . 16 89 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 90 12.1. Normative References . . . . . . . . . . . . . . . . . . 17 91 12.2. Informative References . . . . . . . . . . . . . . . . . 17 92 Appendix A. . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 93 A.1. Presence of other interfaces in Valid list . . . . . . . 18 94 A.1.1. Receiving ICE Mobility event . . . . . . . . . . . . 19 95 A.2. Losing an Interface . . . . . . . . . . . . . . . . . . . 19 96 A.2.1. Keeping unused candidates in the valid list active . 19 97 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20 99 1. Introduction 101 When moving between networks, an endpoint has to change its IP 102 address. This change breaks upper layer protocols such as TCP and 103 RTP. Various techniques exist to prevent this breakage, all tied to 104 making the endpoint's IP address static (e.g., Mobile IP, Proxy 105 Mobile IP, LISP). Other techniques exist, which make the upper layer 106 protocol ambivalent to IP address changes (e.g., SCTP). The 107 mechanisms described in this document are in that last category. 109 ICE [RFC5245] ensures two endpoints have a working media path between 110 them, and is typically used by Internet-connected interactive media 111 systems (e.g., SIP endpoints). ICE does not expect either the local 112 host or the remote host to change their IP addresses. Although ICE 113 does allow an "ICE restart", this is done by sending a re-INVITE 114 which goes over the SIP signaling path. The SIP signaling path is 115 often slower than the media path (which needs to be recovered as 116 quickly as possible), consumes an extra half round trip, and incurs 117 an additional delay if the mobility event forces the endpoint to re- 118 connect with its SIP proxy. When a device changes its IP address, it 119 is necessary for it to re-establish connectivity with its SIP proxy, 120 which can be performed in parallel with the steps described in this 121 document. This document describes how mobility is performed entirely 122 in the media path, without the additional delay of re-establishing 123 SIP connectivity, issuing a new offer/answer, or the complications of 124 multiple SIP offers. This document considers re-establishing bi- 125 directional media the most critical aspect of a successful mobility 126 event, and its efforts are towards meeting that goal. 128 A TURN [RFC5766] server relays media packets and is used for a 129 variety of purposes, including overcoming NAT and firewall traversal 130 issues and IP address privacy. The existing TURN specification does 131 not allow the client address to change, especially if multiple 132 clients share the same TURN username (e.g., the same credentials are 133 used on multiple devices). 135 This document proposes two mechanisms to achieve RTP mobility: a 136 mechanism where both endpoints support MICE, and a mechanism where 137 only one endpoint supports MICE. When both endpoints support MICE, 138 ICE itself can be used to provide mobility. When only one endpoint 139 supports MICE, a TURN server provides mobility. Both mobility 140 techniques work across and between network types (e.g., between 3G 141 and wired Internet access), so long as the client can still access 142 the remote ICE peer or TURN server. 144 Readers are assumed to be familiar with ICE [RFC5245]. 146 2. Notational Conventions 148 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 149 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 150 document are to be interpreted as described in [RFC2119]. 152 This note uses terminology defined in [RFC5245], and the following 153 additional terminology: 155 Break Before Make: The initially selected interface for 156 communication may become unavailable (e.g due to loss of coverage 157 when moving out of a WiFi hotspot) and new interfaces may become 158 available due to administrative action (e.g manual activation of a 159 specific connectivity technology) or due to dynamic conditions 160 (e.g. Entering coverage area of a wireless network). 162 Make Before Break: The initially selected interface for 163 communication may become deprioritized (e.g new interface becoming 164 available and it's per bit cost is cheaper and the connection 165 speed is faster than existing interface used for communication). 167 Simultaneous Mobility: If both the endpoints are mobile and roam at 168 the same time between networks. 170 3. Break Before Make 172 When both endpoints support ICE, ICE itself can provide mobility 173 functions. One of the primary aspects of ICE is its address 174 gathering, wherein ICE has each endpoint determine all of the IP 175 addresses and ports that might be usable for that endpoint and 176 communicate that list of addresses and ports to its peer, usually 177 over SDP. That enables the next primary aspect of ICE, which is its 178 connectivity checks: each ICE endpoint sends a connectivity check 179 from a checklist created by the local and remote candidates exchanged 180 in the initial offer/answer exchange. When the ICE endpoint checks 181 the mapped address from the STUN response during ICE connectivity 182 checks and finds that the transport address does not match any of the 183 local candidates that the ICE agent knows about, the mapped address 184 represents a new candidate -- a peer reflexive candidate. This will 185 cause the endpoint to construct a new pair and insert it into the 186 local checklist (Section 7.2.1.3 of [RFC5245]). ICE Mobility (MICE) 187 takes advantage of that existing ICE functionality to provide faster 188 mobility. 190 Endpoints that support ICE Mobility perform ICE normally, and MUST 191 also include the MOBILITY-SUPPORT attribute in all of their STUN 192 requests and their STUN responses. The inclusion of this attribute 193 allows the ICE peer to determine if it can achieve mobility using ICE 194 or needs to use TURN. To force the use of TURN to achieve ICE 195 mobility, the ICE endpoint SHOULD NOT respond to ICE connectivity 196 checks that have an IP address and port different from the TURN 197 server, unless those connectivity checks contain the MOBILITY-SUPPORT 198 attribute. In this way, the remote peer will think those other 199 candidates are invalid (because its connectivity checks did not 200 succeed). 202 After concluding ICE and moving to the ICE completed state (see 203 Section 8 of [RFC5245]) either endpoint or both endpoints can 204 initiate ICE Mobility, no matter if it was the Controlling Agent or 205 the Controlled Agent during normal ICE processing. 207 3.1. Absence of other interfaces in Valid list 209 When the interface currently being used for communication becomes 210 unavailable then ICE agent acquires a list of interfaces that are 211 available and based on the locally configured host policy 212 preferences, the ICE endpoint performs ICE Mobility using one of the 213 available interfaces. In this case local candidates from the 214 selected interface are not present in the valid list. ICE Mobility 215 is performed by: 217 1. The ICE agent remembers the remote host/server reflexive/peer 218 reflexive candidates for each component of the media streams 219 previously used from the valid list before clearing its ICE check 220 list and ICE Valid List. 222 2. The ICE endpoint gathers host candidates of the same address 223 family as the remote peer on the new interface, forms a check 224 list by creating candidate pairs with local host candidates and 225 remote host/server-reflexive candidates collected in step 1, 226 performs "Computing Pair Priority and Ordering Pairs" 227 (Section 5.7.2 of [RFC5245]), "Pruning the Pairs" (Section 5.7.3 228 of [RFC5245], "Computing states" (Section 5.7.4 of [RFC5245]). 230 3. The ICE endpoint initiates ICE connectivity checks on those 231 candidates from the check list in the previous step, and includes 232 the MOBILITY-EVENT attribute in those connectivity checks. 234 4. The ICE endpoint acts as controlling agent and the ICE 235 connectivity check from the previous step SHOULD also include the 236 USE-CANDIDATE attribute to signal an aggressive nomination (see 237 Section 2.6 of [RFC5245]). 239 5. The ICE endpoint performs "Discovering Peer Reflexive Candidates" 240 (Section 7.1.3.2.1 of [RFC5245]), "Constructing a Valid Pair" 241 (Section 7.1.3.2.2 of [RFC5245]), "Updating Pair States" 242 (Section 7.1.3.2.3 of [RFC5245]), and "Updating the Nominated 243 Flag" (Section 7.1.3.2.4 of [RFC5245]). When the valid list 244 contains a candidate pair for each component then ICE processing 245 is considered complete for the media stream and ICE agent can 246 start sending media using the nominated candidate pair. 248 6. Once ICE connectivity checks for all of the media streams are 249 completed, the controlling ICE endpoint follows the procedures in 250 Section 11.1 of [RFC5245], specifically to send updated offer if 251 the candidates in the m and c lines for the media stream (called 252 the DEFAULT CANDIDATES) do not match ICE's SELECTED CANDIDATES 253 (also see Appendix B.9 of [RFC5245]). 255 The ICE endpoint even after Mobility using ICE is successful can 256 issue an updated offer indicating ICE restart if connectivity checks 257 using higher priority candidate pairs are not successful. 259 Mobility using ICE could fail in case of Simultaneous Mobility or if 260 the ICE peer is behind NAT that performs Address-Dependent Filtering 261 (see Section 5 of [RFC5245]). Hence the ICE endpoint in parallel 262 will re-establish connection with the SIP proxy. It will then 263 determine whether to initiate ICE restart under the following 264 conditions: 266 a. After re-establishing connection with the SIP proxy and before 267 sending new offer to initiate ICE restart if Mobility using ICE 268 is successful then stop sending the new offer. 270 b. After successful negotiation of updated offer/answer to initiate 271 ICE restart, proceed with ICE restart and stop Mobility using ICE 272 if ICE checks are in the Running/Failed states or ICE is 273 partially successful and not yet reached ICE complete state. 274 It's not implementation friendly to have to two checks running in 275 parallel. ICE restart can re-use partial successful ICE 276 connectivity check results from Mobility using ICE if required as 277 optimization. 279 3.1.1. Receiving ICE Mobility event 281 A STUN Binding Request containing the MOBILITY-EVENT attribute MAY be 282 received by an ICE endpoint. The agent MUST use short-term 283 credential to authenticate the STUN request containing the MOBILITY- 284 EVENT attribute and perform a message integrity check. The ICE 285 endpoint will generate STUN Binding Response containing the MOBILE- 286 SUPPORT attribute and the ICE agent takes role of controlled agent. 287 If STUN Request containing the MOBILITY-EVENT attribute is received 288 before the endpoint is in the ICE Completed state, it should be 289 silently discarded. 291 The agent remembers the highest-priority nominated pairs in the Valid 292 list for each component of the media stream, called the previous 293 selected pairs before removing all the selected candidate pairs from 294 the Valid List . It continues sending media to that address until it 295 finishes with the steps described below. Because those packets might 296 not be received due to the mobility event, it MAY cache a copy of 297 those packets. 299 1. The ICE endpoint constructs a pair whose local candidate is equal 300 to the transport address on which the STUN request was received 301 with MOBILITY-EVENT, USE-CANDIDATE attributes and a remote 302 candidate equal to the source transport address where the STUN 303 request came from. 305 2. The ICE endpoint will add this pair to the valid list if not 306 already present. 308 3. The agent sets the nominated flag for that pair in the valid pair 309 to true. ICE processing is considered complete for a media 310 stream if the valid list contains a selected candidate pair for 311 each component and ICE agent can start sending media. 313 The ICE endpoint will follow Steps 1 to 3 when subsequent STUN 314 Binding Requests are received with MOBILITY-EVENT and USE-CANDIDATE 315 attributes. 317 3.2. Keeping unused relayed candidates active 319 The ICE endpoints can maintain the relayed candidates active even 320 when not actively used, so that relayed candidates can be tried if 321 ICE connectivity checks using other candidate types fails. The ICE 322 agent will have to create permissions in the TURN server for the 323 remote relayed candidate IP addresses and perform the following 324 steps: 326 1. The ICE agent will keep the relayed candidates alive using 327 Refresh transaction, as described in [RFC5766]. 329 2. When the endpoint IP address changes due to mobility, the ICE 330 agent will refresh it's allocation with TURN server using 331 Section 5.2. 333 3. The ICE agent will pair local and remote relayed candidates for 334 connectivity checks when performing the steps in Section 3.1. 336 4. If the ICE connectivity check succeeds only with local and remote 337 relayed candidates, it suggests that either other peer is roaming 338 at the same time or is behind Address-Dependent Filtering NAT. 340 The ICE agent adds the relayed candidate pair to the valid list 341 and marks it as selected. The ICE agent can now send media using 342 the newly selected relayed candidate pair. The Mobile device 343 must re-establish connection with SIP proxy, issue an updated 344 offer indicating ICE restart so that media can switched to 345 higher-priority candidate pairs. 347 This approach assists Mobility using ICE to succeed but brings in 348 additional overhead of maintaining relayed candidates.In case of 349 Simultaneous Mobility, host candidates can change for both the 350 endpoints by maintaining relayed candidates and using Section 5 media 351 session can be established using the relayed candidate pair. 353 3.3. New STUN Attributes 355 Three new attributes are defined by this section: MOBILITY-EVENT, 356 MOBILITY-SUPPORT. 358 The MOBILITY-EVENT attribute indicate the sender experienced a 359 mobility event. This attribute has no value, thus the attribute 360 length field MUST always be 0. Rules for sending and interpretation 361 of receiving are described above. 363 The MOBILITY-SUPPORT attribute indicates the sender supports ICE 364 Mobility, as defined in this document. This attribute has no value, 365 thus the attribute length field MUST always be 0. Rules for sending 366 and interpretation of receiving are described above. 368 4. Make Before Break 370 When a new interface comes up and initially selected interface 371 becomes deprioritized (e.g due to a low cost interface becoming 372 available). The ICE endpoint re-connects to the SIP proxy using the 373 new interface, gather candidates, exchange updated offer/exchange to 374 restart ICE. Once ICE processing has reached the Completed state 375 then the ICE endpoint can successfully switch the media over to the 376 new interface. The interface initially used for communication can 377 now be turned off without disrupting communications. 379 5. Mobility using TURN 381 To achieve mobility, a TURN client should be able to retain an 382 allocation on the TURN server across changes in the client IP address 383 as a consequence of movement to other networks. 385 When the client sends the initial Allocate request to the TURN 386 server, it will also include the new STUN attribute MOBILITY-TICKET 387 (with zero length value), which indicates that the client is capable 388 of mobility and desires a ticket. The TURN server provisions a 389 ticket that is sent inside the new STUN attribute MOBILITY-TICKET in 390 the Allocate Success response to the client. The ticket will be used 391 by the client when it wants to refresh the allocation but with a new 392 client IP address and port. It also ensures that the allocation can 393 only be refreshed this way by the same client. When a client's IP 394 address changes due to mobility, it presents the previously obtained 395 ticket in a Refresh Request to the TURN server. If the ticket is 396 found to be valid, the TURN server will retain the same relayed 397 address/port for the new IP address/port allowing the client to 398 continue using previous channel bindings -- thus, the TURN client 399 does not need to obtain new channel bindings. Any data from external 400 peer will be delivered by the TURN server to this new IP address/port 401 of the client. The TURN client will continue to send application 402 data to its peers using the previously allocated channelBind 403 Requests. 405 TURN TURN Peer 406 client server A 407 |-- Allocate request --------------->| | 408 | + MOBILITY-TICKET (length=0) | | 409 | | | 410 |<--------------- Allocate failure --| | 411 | (401 Unauthorized) | | 412 | | | 413 |-- Allocate request --------------->| | 414 | + MOBILITY-TICKET (length=0) | | 415 | | | 416 |<---------- Allocate success resp --| | 417 | + MOBILITY-TICKET | | 418 ... ... ... 419 (changes IP address) 420 | | | 421 |-- Refresh request ---------------->| | 422 | + MOBILITY-TICKET | | 423 | | | 424 |<----------- Refresh success resp --| | 425 | + MOBILITY-TICKET | | 426 | | | 428 5.1. Creating an Allocation 430 5.1.1. Sending an Allocate Request 432 In addition to the process described in Section 6.1 of [RFC5766], the 433 client includes the MOBILITY-TICKET attribute with length 0. This 434 indicates the client is a mobile node and wants a ticket. 436 5.1.2. Receiving an Allocate Request 438 In addition to the process described in Section 6.2 of [RFC5766], the 439 server does the following: 441 If the MOBILITY-TICKET attribute is included, and has length zero, 442 and the TURN session mobility is forbidden by local policy, the 443 server MUST reject the request with the new Mobility Forbidden error 444 code. If the MOBILITY-TICKET attribute is included and has non-zero 445 length then the server MUST generate an error response with an error 446 code of 400 (Bad Request). Following the rules specified in 447 [RFC5389], if the server does not understand the MOBILITY-TICKET 448 attribute, it ignores the attribute. 450 If the server can successfully process the request create an 451 allocation, the server replies with a success response that includes 452 a STUN MOBILITY-TICKET attribute. TURN server can store system 453 internal data into the ticket that is encrypted by a key known only 454 to the TURN server and sends the ticket in the STUN MOBILITY-TICKET 455 attribute as part of Allocate success response. 457 The ticket is opaque to the client, so the structure is not subject 458 to interoperability concerns, and implementations may diverge from 459 this format. TURN Allocation state information is encrypted using 460 128-bit key for Advance Encryption Standard (AES) and 256-bit key for 461 HMAC-SHA-256 for integrity protection. 463 5.1.3. Receiving an Allocate Success Response 465 In addition to the process described in Section 6.3 of [RFC5766], the 466 client will store the MOBILITY-TICKET attribute, if present, from the 467 response. This attribute will be presented by the client to the 468 server during a subsequent Refresh request to aid mobility. 470 5.1.4. Receiving an Allocate Error Response 472 If the client receives an Allocate error response with error code TBD 473 (Mobility Forbidden), the error is processed as follows: 475 o TBD (Mobility Forbidden): The request is valid, but the server is 476 refusing to perform it, likely due to administrative restrictions. 477 The client considers the current transaction as having failed. The 478 client MAY notify the user or operator and SHOULD NOT retry the same 479 request with this server until it believes the problem has been 480 fixed. 482 All other error responses must be handled as described in [RFC5766]. 484 5.2. Refreshing an Allocation 486 5.2.1. Sending a Refresh Request 488 If a client wants to refresh an existing allocation and update its 489 time-to-expiry or delete an existing allocation, it will send a 490 Refresh Request as described in Section 7.1 of [RFC5766]. If the 491 client wants to retain the existing allocation in case of IP change, 492 it will include the MOBILITY-TICKET attribute received in the 493 Allocate Success response. If a Refresh transaction was previously 494 made, the MOBILITY-TICKET attribute received in the Refresh Success 495 response of the transaction must be used. 497 5.2.2. Receiving a Refresh Request 499 In addition to the process described in Section 7.2 of [RFC5766], the 500 client does the following: 502 If the STUN MOBILITY-TICKET attribute is included in the Refresh 503 Request then the server will not retrieve the 5-tuple from the packet 504 to identify an associated allocation. Instead TURN server will 505 decrypt the received ticket, verify the ticket's validity and 506 retrieve the 5-tuple allocation using the ticket. If this 5-tuple 507 obtained does not identify an existing allocation then the server 508 MUST reject the request with an error. 510 If the source IP address and port of the Refresh Request is different 511 from the stored 5-tuple allocation, the TURN server proceeds with 512 MESSAGE-INTEGRITY validation to identify the that it is the same user 513 which had previously created the TURN allocation. If the above 514 checks are not successful then server MUST reject the request with a 515 441 (Wrong Credentials) error. 517 If all of the above checks pass, the TURN server understands that the 518 client has moved to a new network and acquired a new IP address. The 519 source IP address of the request could either be the host transport 520 address or server-reflexive transport address. The server then 521 updates it's 5-tuple with the new client IP address and port. TURN 522 server calculates the ticket with the new 5-tuple and sends the new 523 ticket in the STUN MOBILITY-TICKET attribute as part of Refresh 524 Success response. 526 5.2.3. Receiving a Refresh Response 528 In addition to the process described in Section 7.3 of [RFC5766], the 529 client will store the MOBILITY-TICKET attribute, if present, from the 530 response. This attribute will be presented by the client to the 531 server during a subsequent Refresh Request to aid mobility. 533 5.3. New STUN Attribute MOBILITY-TICKET 535 This attribute is used to retain an Allocation on the TURN server. 536 It is exchanged between the client and server to aid mobility. The 537 value of MOBILITY-TICKET is encrypted and is of variable-length. 539 5.4. New STUN Error Response Code 541 This document defines the following new error response code: 543 Mobility Forbidden: Mobility request was valid but cannot be 544 performed due to administrative or similar restrictions. 546 6. Comparison to ICE Restart and Trickle ICE 548 There has been some concern that ICE Mobility is unnecessary, and 549 that an ICE restart (section 9.1.1.1 of [RFC5245]) would provide 550 exactly the same functionality as ICE Mobility. These sections 551 examine how ICE restart and Trickle ICE 552 [I-D.rescorla-mmusic-ice-trickle] compare with ICE Mobility. 554 6.1. Break Before Make - ICE Restart 556 o If ICE Restart is used for RTP Mobility then in case of Break 557 before Make, 559 1. Before the endpoint can send an ICE restart message, it has to 560 first re-establish communication with its SIP proxy. This 561 consumes one round-trip for both TCP and UDP. If the 562 connection is protected with TLS (TCP) or DTLS (UDP), we can 563 assume TLS session resumption [RFC5077] will be used to reduce 564 the number of TLS messages. With TLS session resumption, this 565 consumes 1 round trip. If TLS session resumption is not 566 available, a full TLS handshake consumes 2 round trips. This 567 is a total of 2 round trips (with session resumption) to 3 568 round trips (without session resumption), which is multiplied 569 by the round trip time to the SIP proxy. The round trip time 570 is dependent on a particular network or deployment, for 571 example in second (2.5G), third (3G) generation wireless 572 networks and satellite communication round trip time could be 573 higher than 250ms. These calculations are only considering 574 the network round-trip time and do not consider the wall-clock 575 time to validate the TLS certificates or generate the TLS keys 576 on the TLS client or the TLS server, which would make this 577 longer. 579 2. While performing the above steps to re-establish SIP 580 connectivity with its SIP proxy, the endpoint will gather host 581 candidates which incur no network traffic, server-reflexive 582 candidates which incur a round-trip to a STUN server, and 583 relayed candidates which incurs three round trips (two for re- 584 authentication and one for creating the TURN permission). The 585 STUN and TURN communications can be performed in parallel with 586 the SIP connectivity check from step (1), above. 588 3. The endpoints through the SIP server will exchange offer/ 589 answer. The SIP server could also be located halfway around 590 the world from the endpoints and the delay could be 591 significant. For SIP over UDP the endpoint will have send a 592 SIP request and wait for the response to arrive. 594 4. ICE restart requires sending a new INVITE. A new INVITE 595 cannot be sent if there is an open SIP dialog, such as a 596 previous INVITE. This means rapid mobility events will not 597 work well, and there is also an increased likelihood for glare 598 (both endpoints sending INVITEs at the same time). 600 6.2. Break Before Make - Trickle ICE 602 o If Trickle ICE [I-D.rescorla-mmusic-ice-trickle] is used for RTP 603 Mobility then in case of Break before Make, 605 1. Trickle ICE can begin connectivity checks while the endpoint 606 is still gathering candidates and can considerably shorten the 607 time necessary for ICE processing to complete. It still 608 involves the overhead of step 1 explained in section 609 Section 6.1. 611 2. The endpoint would learn host candidates and inform them to 612 the remote peer in offer, the remote peer will provide its 613 candidates in answer. The host, server reflexive, peer 614 reflexive and relayed candidates of the remote peer may not 615 change and the remote peer does not have to gather the 616 candidates again. Trickle ICE will test local host candidates 617 with all types of remote candidates provided by the remote 618 peer in the answer. 620 a. If the endpoint is not behind NAT and the ICE peer is 621 behind NAT performing endpoint dependent filtering (or 622 firewall blocking unsolicited incoming traffic) then ICE 623 connectivity checks initiated by the endpoint to the 624 remote peer will succeed as a consequence of suicide ICE 625 connectivitivy check packets. 627 b. If the endpoint is behind NAT and ICE peer is behind 628 endpoint-dependent filtering NAT then ICE connectivity 629 checks using the first offer/answer will fail but will 630 later succeed in subsequent offer/answer where the 631 endpoint provides server-reflexive candidates. 633 3. Trickle ICE must be supported by both endpoints for it be 634 used. 636 o If both endpoints support TRICKLE ICE then it is RECOMMENDED that 637 TRICKLE ICE be tried instead of ICE restart in steps (a) and (b) 638 of Section 3.1. 640 7. IANA Considerations 642 IANA is requested to add the following attributes to the STUN 643 attribute registry [iana-stun], 645 o MOBILITY-TICKET (0x802E, in the comprehension-optional range) 647 o MOBILITY-EVENT (0x802, in the comprehension-required range) 649 o MOBILITY-SUPPORT (0x8000, in the comprehension-optional range) 651 and to add a new STUN error code "Mobility Forbidden" with the value 652 501 to the STUN Error Codes registry [iana-stun]. 654 8. Implementation Status 656 [Note to RFC Editor: Please remove this section and reference to 657 [RFC6982] prior to publication.] 659 This section records the status of known implementations of the 660 protocol defined by this specification at the time of posting of this 661 Internet-Draft, and is based on a proposal described in [RFC6982]. 662 The description of implementations in this section is intended to 663 assist the IETF in its decision processes in progressing drafts to 664 RFCs. Please note that the listing of any individual implementation 665 here does not imply endorsement by the IETF. Furthermore, no effort 666 has been spent to verify the information presented here that was 667 supplied by IETF contributors. This is not intended as, and must not 668 be construed to be, a catalog of available implementations or their 669 features. Readers are advised to note that other implementations may 670 exist. 672 According to [RFC6982], "this will allow reviewers and working groups 673 to assign due consideration to documents that have the benefit of 674 running code, which may serve as evidence of valuable experimentation 675 and feedback that have made the implemented protocols more mature. 677 It is up to the individual working groups to use this information as 678 they see fit". 680 8.1. open-sys 682 Organization: This is a public project, the full list of authors 683 and contributors here: http://turnserver.open-sys.org/downloads/ 684 AUTHORS 686 Description: A mature open-source TURN server specs implementation 687 (RFC 5766, RFC 6062, RFC 6156, etc) designed for high-performance 688 applications, especially geared for WebRTC. 690 Implementation: http://code.google.com/p/rfc5766-turn-server/ 692 Level of maturity: The Mobile ICE feature implementation can be 693 qualified as "production" - it is well tested and fully 694 implemented, but not widely used, yet.. 696 Coverage: Fully implements MICE with TURN protocol. 698 Licensing: BSD: http://turnserver.open-sys.org/downloads/LICENSE 700 Implementation experience: MICE implementation is somewhat 701 challenging for a multi-threaded performance-oriented application 702 (because the mobile ticket information must be shared between the 703 threads) but it is doable. 705 Contact: Oleg Moskalenko . 707 9. Security Considerations 709 9.1. Considerations for ICE mechanism 711 A mobility event only occurs after both ICE endpoints have exchanged 712 their ICE information. Thus, both username fragments are already 713 known to both endpoints. Each endpoint contributes at least 24 bits 714 of randomness to the ice-ufrag (Section 15.4 of [RFC5245]), which 715 provides 48 bits of randomness. An off-path attacker would have to 716 guess those 48 bits to cause the endpoints to perform HMAC-SHA1 717 validation of the MESSAGE-INTEGRITY attribute. 719 An attacker on the path between the ICE endpoints will see both ice- 720 ufrags, and can cause the endpoints to perform HMAC-SHA1 validation 721 by sending messages from any IP address. 723 9.2. Considerations for TURN mechanism 725 TURN server MUST use strong encryption and integrity protection for 726 the ticket to prevent an attacker from using a brute force mechanism 727 to obtain the ticket's contents or refreshing allocations. 729 Security considerations described in [RFC5766] are also applicable to 730 this mechanism. 732 10. Acknowledgements 734 Thanks to Alfred Heggestad, Lishitao, Sujing Zhou, Martin Thomson, 735 Emil Ivov and Oleg Moskalenko for review and comments. 737 11. Change History 739 [Note to RFC Editor: Please remove this section prior to 740 publication.] 742 11.1. Changes from draft-wing-mmusic-ice-mobility-00 to -01 744 o Updated section 3 746 11.2. Changes from draft-wing-mmusic-ice-mobility-01 to -02 748 o Updated Introduction, Notational Conventions, sections 3.1, 3.2. 750 o Updated section 3.5 752 11.3. Changes from draft-wing-mmusic-ice-mobility-02 to -03 754 o Moved sections Presence of other interfaces in Valid list, Losing 755 an Interface to Appendix. 757 11.4. Changes from draft-wing-mmusic-ice-mobility-03 to -04 759 o Added Section 6. 761 11.5. Changes from draft-wing-mmusic-ice-mobility-04 to -05 763 o Updated Section 6. 765 11.6. Changes from draft-wing-mmusic-ice-mobility-05 to -06 767 o Updated Section 5. 769 o Added Implementation Status section. 771 12. References 773 12.1. Normative References 775 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 776 Requirement Levels", BCP 14, RFC 2119, March 1997. 778 [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment 779 (ICE): A Protocol for Network Address Translator (NAT) 780 Traversal for Offer/Answer Protocols", RFC 5245, April 781 2010. 783 [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, 784 "Session Traversal Utilities for NAT (STUN)", RFC 5389, 785 October 2008. 787 [RFC5766] Mahy, R., Matthews, P., and J. Rosenberg, "Traversal Using 788 Relays around NAT (TURN): Relay Extensions to Session 789 Traversal Utilities for NAT (STUN)", RFC 5766, April 2010. 791 12.2. Informative References 793 [I-D.rescorla-mmusic-ice-trickle] 794 Rescorla, E., Uberti, J., and E. Ivov, "Trickle ICE: 795 Incremental Provisioning of Candidates for the Interactive 796 Connectivity Establishment (ICE) Protocol", draft- 797 rescorla-mmusic-ice-trickle-01 (work in progress), October 798 2012. 800 [RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig, 801 "Transport Layer Security (TLS) Session Resumption without 802 Server-Side State", RFC 5077, January 2008. 804 [RFC5763] Fischl, J., Tschofenig, H., and E. Rescorla, "Framework 805 for Establishing a Secure Real-time Transport Protocol 806 (SRTP) Security Context Using Datagram Transport Layer 807 Security (DTLS)", RFC 5763, May 2010. 809 [RFC5780] MacDonald, D. and B. Lowekamp, "NAT Behavior Discovery 810 Using Session Traversal Utilities for NAT (STUN)", RFC 811 5780, May 2010. 813 [RFC6263] Marjou, X. and A. Sollaud, "Application Mechanism for 814 Keeping Alive the NAT Mappings Associated with RTP / RTP 815 Control Protocol (RTCP) Flows", RFC 6263, June 2011. 817 [RFC6982] Sheffer, Y. and A. Farrel, "Improving Awareness of Running 818 Code: The Implementation Status Section", RFC 6982, July 819 2013. 821 [iana-stun] 822 IANA, , "IANA: STUN Attributes", April 2011, 823 . 826 Appendix A. 828 A.1. Presence of other interfaces in Valid list 830 This technique is optional and only relevant if there is a host 831 policy to maintain unused candidates on other interfaces using the 832 steps in Appendix A.2.1. ICE Agent can maintain unused candidates on 833 other interfaces if it detects that it is behind Address-Dependent 834 Filtering NAT or Firewall. ICE Agent can detect NAT, Firewall 835 behaviour using the procedure explained in [RFC5780]. When the 836 interface currently being used for media communication becomes 837 unavailable. If other interfaces are available and local candidates 838 from these interfaces are already present in the valid list then ICE 839 endpoint will perform the following steps: 841 1. The ICE endpoint based on the locally configured host policy 842 preferences, will select a interface whose candidates are already 843 present in the valid list. 845 2. The ICE endpoint clears all the pairs in the valid list 846 containing the IP addresses from the interface that become 847 unavailable. 849 3. The ICE endpoint initiates ICE connectivity checks on the 850 selected interface. The ICE endpoint acts as controlling agent 851 and MUST include MOBILITY-EVENT attribute to signal mobility 852 event and SHOULD also include the USE-CANDIDATE attribute to 853 signal an aggressive nomination (see Section 2.6 of [RFC5245]). 854 When all components have a nominated pair in the valid list, 855 media can begin to flow using the highest priority nominated 856 pair. 858 4. The ICE endpoint will re-establish connection with the SIP proxy. 859 Once ICE connectivity checks for all of the media streams are 860 completed, the controlling ICE endpoint follows the procedures in 861 Section 11.1 of [RFC5245], specifically to send updated offer if 862 the candidates in the m and c lines for the media stream (called 863 the DEFAULT CANDIDATES) do not match ICE's SELECTED CANDIDATES 864 (also see Appendix B.9 of [RFC5245]). 866 The ICE endpoint after Mobility using ICE is successful can issue an 867 updated offer indicating ICE restart if higher priority interface 868 becomes available. 870 A.1.1. Receiving ICE Mobility event 872 The ICE endpoint that receives ICE Mobility Event will perform the 873 steps in Section 3.1.1. 875 A.2. Losing an Interface 877 When an interface is lost, the SDP MAY be updated, so that the remote 878 ICE host does not waste its efforts with connectivity checks to that 879 address, as those checks will fail. Because it can be argued that 880 this is merely an optimization, and that the interface loss might be 881 temporary (and soon regained), and that ICE has reasonable 882 accommodation for candidates where connectivity checks timeout, this 883 specification does not strongly encourage updating the SDP to remove 884 a lost interface. 886 Likewise, this specification recommends that ICE candidate addresses 887 in valid list be maintained actively, subject to the host's policy. 888 For example, battery operated hosts have a strong incentive to not 889 maintain NAT binding for server reflexive candidates learnt through 890 STUN Binding Request, as the maintenance requires sending periodic 891 STUN Binding Indication. As another example, a host that is 892 receiving media over IPv6 may not want to persist with keeping a 893 NATted IPv4 mapping alive (because that consumes a NAT mapping that 894 could be more useful to a host actively utilizing the mapping for 895 real traffic). 897 Note: this differs from Section 8.3 of [RFC5245], which encourages 898 abandoning unused candidates. 900 A.2.1. Keeping unused candidates in the valid list active 902 ICE endpoint subject to host policy can continue performing ICE 903 connectivity checks using candidates from other interfaces on the 904 host even after ICE is complete. If valid list contains unused 905 candidate pairs from other interfaces and one of these interfaces can 906 be selected to send to media in case the existing interface used for 907 media is unavailable then ICE endpoint can keep the unused candidate 908 pairs from other interface{s} alive by sending keepalives every NN 909 seconds. It is recommended to only keep host/server-reflexive 910 candidates active in the valid list and not the relayed candidates. 912 A.2.1.1. Sending keep alive requests 914 Application Mechanism for Keeping Alive the NAT Mappings Associated 915 with RTP / RTP Control Protocol (RTCP) Flows [RFC6263] describes 916 various reasons for doing keepalives on inactive streams and how to 917 keep NAT mapping alive. However this specification requires some 918 additional functionality associated with the keepalives. 920 STUN binding requests MUST be used as the keepalive message instead 921 of the STUN Binding indication as specified in [RFC5245]. This is to 922 ensure positive peer consent from the remote side that the candidate 923 pair is still active and in future mobility can be achieved using the 924 steps in Appendix A.1 . The request must include the MOBILITY-SUPPORT 925 attribute. If the STUN binding response matches a pair in the 926 checklist then that candidate pair should be kept in the list. If 927 the STUN transaction fails then the candidate pair will be removed 928 from valid list. 930 A.2.1.2. Receiving keep alive requests 932 Upon receiving a STUN binding request containing a MOBILITY-SUPPORT 933 attribute even when ICE processing is in the Completed state, the ICE 934 endpoint will add this pair to the valid list if not already present 935 and generate STUN Binding Response containing the MOBILE-SUPPORT 936 attribute. 938 Authors' Addresses 940 Dan Wing 941 Cisco Systems, Inc. 942 170 West Tasman Drive 943 San Jose, California 95134 944 USA 946 Email: dwing@cisco.com 948 Tirumaleswar Reddy 949 Cisco Systems, Inc. 950 Cessna Business Park, Varthur Hobli 951 Sarjapur Marathalli Outer Ring Road 952 Bangalore, Karnataka 560103 953 India 955 Email: tireddy@cisco.com 956 Prashanth Patil 957 Cisco Systems, Inc. 958 Cessna Business Park, Varthur Hobli 959 Sarjapur Marthalli Outer Ring Road 960 Bangalore, Karnataka 560103 961 India 963 Email: praspati@cisco.com 965 Paal-Erik Martinsen 966 Cisco Systems, Inc. 967 Philip Pedersens vei 22 968 Lysaker, Akershus 1325 969 Norway 971 Email: palmarti@cisco.com