idnits 2.17.1 draft-ietf-tram-turn-mobility-00.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 (November 7, 2015) is 3093 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) -- Looks like a reference, but probably isn't: '16' on line 467 ** Obsolete normative reference: RFC 5077 (Obsoleted by RFC 8446) ** 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 6982 (Obsoleted by RFC 7942) Summary: 4 errors (**), 0 flaws (~~), 1 warning (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 TRAM D. Wing 3 Internet-Draft P. Patil 4 Intended status: Standards Track T. Reddy 5 Expires: May 10, 2016 P. Martinsen 6 Cisco 7 November 7, 2015 9 Mobility with TURN 10 draft-ietf-tram-turn-mobility-00 12 Abstract 14 It is desirable to minimize traffic disruption caused by changing IP 15 address during a mobility event. One mechanism to minimize 16 disruption is to expose a shorter network path to the mobility event 17 so only the local network elements are aware of the changed IP 18 address but the remote peer is unaware of the changed IP address. 20 This draft provides such an IP address mobility solution using 21 Traversal Using Relays around NAT (TURN). This is achieved by 22 allowing a client to retain an allocation on the TURN server when the 23 IP address of the client changes. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on May 10, 2016. 42 Copyright Notice 44 Copyright (c) 2015 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 60 2. Notational Conventions . . . . . . . . . . . . . . . . . . . 3 61 3. Mobility using TURN . . . . . . . . . . . . . . . . . . . . . 3 62 3.1. Creating an Allocation . . . . . . . . . . . . . . . . . 4 63 3.1.1. Sending an Allocate Request . . . . . . . . . . . . . 4 64 3.1.2. Receiving an Allocate Request . . . . . . . . . . . . 5 65 3.1.3. Receiving an Allocate Success Response . . . . . . . 5 66 3.1.4. Receiving an Allocate Error Response . . . . . . . . 5 67 3.2. Refreshing an Allocation . . . . . . . . . . . . . . . . 6 68 3.2.1. Sending a Refresh Request . . . . . . . . . . . . . . 6 69 3.2.2. Receiving a Refresh Request . . . . . . . . . . . . . 6 70 3.2.3. Receiving a Refresh Response . . . . . . . . . . . . 7 71 3.3. New STUN Attribute MOBILITY-TICKET . . . . . . . . . . . 7 72 3.4. New STUN Error Response Code . . . . . . . . . . . . . . 7 73 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 74 5. Implementation Status . . . . . . . . . . . . . . . . . . . . 8 75 5.1. open-sys . . . . . . . . . . . . . . . . . . . . . . . . 8 76 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 77 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 78 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 79 8.1. Normative References . . . . . . . . . . . . . . . . . . 9 80 8.2. Informative References . . . . . . . . . . . . . . . . . 10 81 Appendix A. Example ticket construction . . . . . . . . . . . . 10 82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 84 1. Introduction 86 When moving between networks, the endpoint's IP address can change or 87 (due to NAT) the endpoint's public IP address can change. Such a 88 change of IP address breaks upper layer protocols such as TCP and 89 RTP. Various techniques exist to prevent this breakage, all tied to 90 making the endpoint's IP address static (e.g., Mobile IP, Proxy 91 Mobile IP, LISP). Other techniques exist, which make the change in 92 IP address agnostic to the upper layer protocol (e.g., SCTP). The 93 mechanism described in this document are in that last category. 95 A Traversal Using Relays around NAT (TURN) [RFC5766] server relays 96 media packets and is used for a variety of purposes, including 97 overcoming NAT and firewall traversal issues. The existing TURN 98 specification does not permit a TURN client to reuse an allocation 99 across client IP address changes. Due to this, when the IP address 100 of the client changes, the TURN client has to request for a new 101 allocation, create permissions for the remote peer, create channels 102 etc. In addition the client has to re-establish communication with 103 its SIP server, send an updated offer to the remote peer conveying 104 the new relayed candidate address, remote side has to regather all 105 candidates and signal them to the client and then the endpoints have 106 to perform Interactive Connectivity Establishment (ICE) [RFC5245] 107 connectivity checks. If ICE continious nomination procedure 108 [I-D.uberti-mmusic-nombis] is used then new relayed candidate address 109 would have to be tricked [I-D.ietf-mmusic-trickle-ice] and ICE 110 connectivity checks have to be performed by the endpoints to nominate 111 pairs that will be selected by ICE. 113 This specification describes a mechanism to seamlessly reuse 114 allocations across client IP address changes without any of the 115 hassles described above. A critical benefit of this technique is 116 that the remote peer does not have to support mobility, or deal with 117 any of the address changes. The client, that is subject to IP 118 address changes, does all the work. The mobility technique works 119 across and between network types (e.g., between 3G and wired Internet 120 access), so long as the client can still access the TURN server. The 121 technique should also work seamlessly when (D)TLS is used as a 122 transport protocol for STUN. When there is a change in IP address, 123 the client uses (D)TLS Session Resumption without Server-Side State 124 as described in [RFC5077] to resume secure communication with the 125 TURN server, using the changed client IP address. 127 2. Notational Conventions 129 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 130 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 131 document are to be interpreted as described in [RFC2119]. 133 This note uses terminology defined in [RFC5245], and the following 134 additional terminology: 136 3. Mobility using TURN 138 To achieve mobility, a TURN client should be able to retain an 139 allocation on the TURN server across changes in the client IP address 140 as a consequence of movement to other networks. 142 When the client sends the initial Allocate request to the TURN 143 server, it will include a new STUN attribute MOBILITY-TICKET (with 144 zero length value), which indicates that the client is capable of 145 mobility and desires a ticket. The TURN server provisions a ticket 146 that is sent inside the new STUN attribute MOBILITY-TICKET in the 147 Allocate Success response to the client. The ticket will be used by 148 the client when it wants to refresh the allocation but with a new 149 client IP address and port. This ensures that an allocation can only 150 be refreshed by the same client that allocated relayed transport 151 address. When a client's IP address changes due to mobility, it 152 presents the previously obtained ticket in a Refresh Request to the 153 TURN server. If the ticket is found to be valid, the TURN server 154 will retain the same relayed address/port for the new IP address/port 155 allowing the client to continue using previous channel bindings -- 156 thus, the TURN client does not need to obtain new channel bindings. 157 Any data from external peer will be delivered by the TURN server to 158 this new IP address/port of the client. The TURN client will 159 continue to send application data to its peers using the previously 160 allocated channelBind Requests. 162 TURN TURN Peer 163 client server A 164 |-- Allocate request --------------->| | 165 | + MOBILITY-TICKET (length=0) | | 166 | | | 167 |<--------------- Allocate failure --| | 168 | (401 Unauthorized) | | 169 | | | 170 |-- Allocate request --------------->| | 171 | + MOBILITY-TICKET (length=0) | | 172 | | | 173 |<---------- Allocate success resp --| | 174 | + MOBILITY-TICKET | | 175 ... ... ... 176 (changes IP address) 177 | | | 178 |-- Refresh request ---------------->| | 179 | + MOBILITY-TICKET | | 180 | | | 181 |<----------- Refresh success resp --| | 182 | + MOBILITY-TICKET | | 183 | | | 185 3.1. Creating an Allocation 187 3.1.1. Sending an Allocate Request 189 In addition to the process described in Section 6.1 of [RFC5766], the 190 client includes the MOBILITY-TICKET attribute with length 0. This 191 indicates the client is a mobile node and wants a ticket. 193 3.1.2. Receiving an Allocate Request 195 In addition to the process described in Section 6.2 of [RFC5766], the 196 server does the following: 198 If the MOBILITY-TICKET attribute is included, and has length zero, 199 but TURN session mobility is forbidden by local policy, the server 200 MUST reject the request with the new Mobility Forbidden error code. 201 If the MOBILITY-TICKET attribute is included and has non-zero length 202 then the server MUST generate an error response with an error code of 203 400 (Bad Request). Following the rules specified in [RFC5389], if 204 the server does not understand the MOBILITY-TICKET attribute, it 205 ignores the attribute. 207 If the server can successfully process the request create an 208 allocation, the server replies with a success response that includes 209 a STUN MOBILITY-TICKET attribute. TURN server can store system 210 internal data into the ticket that is encrypted by a key known only 211 to the TURN server and sends the ticket in the STUN MOBILITY-TICKET 212 attribute as part of Allocate success response. The ticket is opaque 213 to the client, so the structure is not subject to interoperability 214 concerns, and implementations may diverge from this format. An 215 example for ticket construction is discussed in Appendix A. The 216 client could be roaming across networks with different path MTU and 217 from one address family to another (e.g. IPv6 to IPv4). The TURN 218 server to support mobility must assume that the path MTU is unknown 219 and the STUN message over IPv4 needs to be less than 548 bytes to 220 avoid UDP fragmentation(Section 7.1 of [RFC5389]), it MUST ensure 221 that the ticket length is restricted to fit within the 548 byte STUN 222 message size. Clients MUST NOT examine the ticket under the 223 assumption that it complies with this document. 225 3.1.3. Receiving an Allocate Success Response 227 In addition to the process described in Section 6.3 of [RFC5766], the 228 client will store the MOBILITY-TICKET attribute, if present, from the 229 response. This attribute will be presented by the client to the 230 server during a subsequent Refresh request to aid mobility. 232 3.1.4. Receiving an Allocate Error Response 234 If the client receives an Allocate error response with error code TBD 235 (Mobility Forbidden), the error is processed as follows: 237 o TBD (Mobility Forbidden): The request is valid, but the server is 238 refusing to perform it, likely due to administrative restrictions. 239 The client considers the current transaction as having failed. The 240 client MAY notify the user or operator and SHOULD NOT retry the same 241 request with this server until it believes the problem has been 242 fixed. 244 All other error responses must be handled as described in [RFC5766]. 246 3.2. Refreshing an Allocation 248 3.2.1. Sending a Refresh Request 250 If a client wants to refresh an existing allocation and update its 251 time-to-expiry or delete an existing allocation, it will send a 252 Refresh Request as described in Section 7.1 of [RFC5766]. If the 253 client wants to retain the existing allocation in case of IP change, 254 it will include the MOBILITY-TICKET attribute received in the 255 Allocate Success response. If a Refresh transaction was previously 256 made, the MOBILITY-TICKET attribute received in the Refresh Success 257 response of the transaction must be used. 259 3.2.2. Receiving a Refresh Request 261 In addition to the process described in Section 7.2 of [RFC5766], the 262 server does the following: 264 If the STUN MOBILITY-TICKET attribute is included in the Refresh 265 Request then the server will not retrieve the 5-tuple from the packet 266 to identify an associated allocation. Instead the TURN server will 267 decrypt the received ticket, verify the ticket's validity and 268 retrieve the 5-tuple allocation using the ticket. If this 5-tuple 269 obtained does not identify an existing allocation then the server 270 MUST reject the request with an error. 272 If the source IP address and port of the Refresh Request is different 273 from the stored 5-tuple allocation, the TURN server proceeds with 274 MESSAGE-INTEGRITY validation to identify the that it is the same user 275 which had previously created the TURN allocation. If the above 276 checks are not successful then server MUST reject the request with a 277 441 (Wrong Credentials) error. 279 If all of the above checks pass, the TURN server understands that the 280 client has moved to a new network and acquired a new IP address. The 281 source IP address of the request could either be the host transport 282 address or server-reflexive transport address. The server then 283 updates it's 5-tuple with the new client IP address and port. TURN 284 server calculates the ticket with the new 5-tuple and sends the new 285 ticket in the STUN MOBILITY-TICKET attribute as part of Refresh 286 Success response. The old ticket can only be used for the purposes 287 of retransmission. If the client wants to refresh its allocation 288 with a new server-reflexive transport address, it MUST use the new 289 ticket. If the TURN server has not received a Refresh Request with 290 STUN MOBILITY-TICKET attribute but receives Send indications or 291 ChannelData messages from a client, the TURN server may discard or 292 queue those Send indications or ChannelData messages (at its 293 discretion). Thus, it is RECOMMENDED that the client avoid 294 transmitting a Send indication or ChannelData message until it has 295 received an acknowledgement for the Refresh Request with STUN 296 MOBILITY-TICKET attribute. 298 To accommodate for loss of Refresh responses, a server must retain 299 the old STUN MOBILITY-TICKET attribute for a period of at least 30 300 seconds to be able recognize a retransmission of Refresh request with 301 the old STUN MOBILITY-TICKET attribute from the client. 303 3.2.3. Receiving a Refresh Response 305 In addition to the process described in Section 7.3 of [RFC5766], the 306 client will store the MOBILITY-TICKET attribute, if present, from the 307 response. This attribute will be presented by the client to the 308 server during a subsequent Refresh Request to aid mobility. 310 3.3. New STUN Attribute MOBILITY-TICKET 312 This attribute is used to retain an Allocation on the TURN server. 313 It is exchanged between the client and server to aid mobility. The 314 value of MOBILITY-TICKET is encrypted and is of variable-length. 316 3.4. New STUN Error Response Code 318 This document defines the following new error response code: 320 Mobility Forbidden: Mobility request was valid but cannot be 321 performed due to administrative or similar restrictions. 323 4. IANA Considerations 325 IANA is requested to add the following attributes to the STUN 326 attribute registry [iana-stun], 328 o MOBILITY-TICKET (0x8030, in the comprehension-optional range) 330 and to add a new STUN error code "Mobility Forbidden" with the value 331 405 to the STUN Error Codes registry [iana-stun]. 333 5. Implementation Status 335 [Note to RFC Editor: Please remove this section and reference to 336 [RFC6982] prior to publication.] 338 This section records the status of known implementations of the 339 protocol defined by this specification at the time of posting of this 340 Internet-Draft, and is based on a proposal described in [RFC6982]. 341 The description of implementations in this section is intended to 342 assist the IETF in its decision processes in progressing drafts to 343 RFCs. Please note that the listing of any individual implementation 344 here does not imply endorsement by the IETF. Furthermore, no effort 345 has been spent to verify the information presented here that was 346 supplied by IETF contributors. This is not intended as, and must not 347 be construed to be, a catalog of available implementations or their 348 features. Readers are advised to note that other implementations may 349 exist. 351 According to [RFC6982], "this will allow reviewers and working groups 352 to assign due consideration to documents that have the benefit of 353 running code, which may serve as evidence of valuable experimentation 354 and feedback that have made the implemented protocols more mature. 355 It is up to the individual working groups to use this information as 356 they see fit". 358 5.1. open-sys 360 Organization: This is a public project, the full list of authors 361 and contributors here: http://turnserver.open-sys.org/downloads/ 362 AUTHORS 364 Description: A mature open-source TURN server specs implementation 365 (RFC 5766, RFC 6062, RFC 6156, etc) designed for high-performance 366 applications, especially geared for WebRTC. 368 Implementation: http://code.google.com/p/rfc5766-turn-server/ 370 Level of maturity: The Mobile ICE feature implementation can be 371 qualified as "production" - it is well tested and fully 372 implemented, but not widely used, yet.. 374 Coverage: Fully implements MICE with TURN protocol. 376 Licensing: BSD: http://turnserver.open-sys.org/downloads/LICENSE 378 Implementation experience: MICE implementation is somewhat 379 challenging for a multi-threaded performance-oriented application 380 (because the mobile ticket information must be shared between the 381 threads) but it is doable. 383 Contact: Oleg Moskalenko . 385 6. Security Considerations 387 TURN server MUST use strong encryption and integrity protection for 388 the ticket to prevent an attacker from using a brute force mechanism 389 to obtain the ticket's contents or refreshing allocations. The 390 ticket MUST be constructed such that it has strong entropy to ensure 391 nothing can be gleaned by looking at the ticket alone. 393 Security considerations described in [RFC5766] are also applicable to 394 this mechanism. 396 7. Acknowledgements 398 Thanks to Alfred Heggestad, Lishitao, Sujing Zhou, Martin Thomson, 399 Emil Ivov, Oleg Moskalenko and Brandon Williams for review and 400 comments. 402 8. References 404 8.1. Normative References 406 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 407 Requirement Levels", BCP 14, RFC 2119, 408 DOI 10.17487/RFC2119, March 1997, 409 . 411 [RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig, 412 "Transport Layer Security (TLS) Session Resumption without 413 Server-Side State", RFC 5077, DOI 10.17487/RFC5077, 414 January 2008, . 416 [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment 417 (ICE): A Protocol for Network Address Translator (NAT) 418 Traversal for Offer/Answer Protocols", RFC 5245, 419 DOI 10.17487/RFC5245, April 2010, 420 . 422 [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, 423 "Session Traversal Utilities for NAT (STUN)", RFC 5389, 424 DOI 10.17487/RFC5389, October 2008, 425 . 427 [RFC5766] Mahy, R., Matthews, P., and J. Rosenberg, "Traversal Using 428 Relays around NAT (TURN): Relay Extensions to Session 429 Traversal Utilities for NAT (STUN)", RFC 5766, 430 DOI 10.17487/RFC5766, April 2010, 431 . 433 8.2. Informative References 435 [I-D.ietf-mmusic-trickle-ice] 436 Ivov, E., Rescorla, E., and J. Uberti, "Trickle ICE: 437 Incremental Provisioning of Candidates for the Interactive 438 Connectivity Establishment (ICE) Protocol", draft-ietf- 439 mmusic-trickle-ice-02 (work in progress), January 2015. 441 [I-D.uberti-mmusic-nombis] 442 Uberti, J. and J. Lennox, "Improvements to ICE Candidate 443 Nomination", draft-uberti-mmusic-nombis-00 (work in 444 progress), March 2015. 446 [iana-stun] 447 IANA, , "IANA: STUN Attributes", April 2011, 448 . 451 [RFC6982] Sheffer, Y. and A. Farrel, "Improving Awareness of Running 452 Code: The Implementation Status Section", RFC 6982, 453 DOI 10.17487/RFC6982, July 2013, 454 . 456 Appendix A. Example ticket construction 458 The TURN server uses two different keys: one 128-bit key for Advance 459 Encryption Standard (AES) in Cipher Block Chaining (CBC) mode 460 (AES_128_CBC) and 256-bit key for HMAC-SHA-256-128 for integrity 461 protection. The ticket can be structured as follows: 463 struct { 464 opaque key_name[16]; 465 opaque iv[16]; 466 opaque state<0..2^16-1>; 467 opaque mac[16]; 468 } ticket; 470 Figure 1: Ticket Format 472 Here, key_name serves to identify a particular set of keys used to 473 protect the ticket. It enables the TURN server to easily recognize 474 tickets it has issued. The key_name should be randomly generated to 475 avoid collisions between servers. One possibility is to generate new 476 random keys and key_name every time the server is started. 478 The TURN state information (self-contained or handle) in 479 encrypted_state is encrypted using 128-bit AES in CBC mode with the 480 given IV. The MAC is calculated using HMAC-SHA-256-128 over key_name 481 (16 octets)and IV (16 octets), followed by the length of the 482 encrypted_state field (2 octets) and its contents (variable length). 484 Authors' Addresses 486 Dan Wing 487 Cisco Systems, Inc. 488 170 West Tasman Drive 489 San Jose, California 95134 490 USA 492 Email: dwing@cisco.com 494 Prashanth Patil 495 Cisco Systems, Inc. 496 Bangalore 497 India 499 Email: praspati@cisco.com 501 Tirumaleswar Reddy 502 Cisco Systems, Inc. 503 Cessna Business Park, Varthur Hobli 504 Sarjapur Marathalli Outer Ring Road 505 Bangalore, Karnataka 560103 506 India 508 Email: tireddy@cisco.com 510 Paal-Erik Martinsen 511 Cisco Systems, Inc. 512 Philip Pedersens vei 22 513 Lysaker, Akershus 1325 514 Norway 516 Email: palmarti@cisco.com