idnits 2.17.1 draft-wing-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 (June 14, 2014) is 3605 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) ** 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 (==), 2 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: December 16, 2014 P. Martinsen 6 Cisco 7 June 14, 2014 9 Mobility with TURN 10 draft-wing-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 TURN. 21 This is achieved by allowing a client to retain an allocation on the 22 TURN server when the IP address of the client changes. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on December 16, 2014. 41 Copyright Notice 43 Copyright (c) 2014 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 59 2. Notational Conventions . . . . . . . . . . . . . . . . . . . 3 60 3. Mobility using TURN . . . . . . . . . . . . . . . . . . . . . 3 61 3.1. Creating an Allocation . . . . . . . . . . . . . . . . . 4 62 3.1.1. Sending an Allocate Request . . . . . . . . . . . . . 4 63 3.1.2. Receiving an Allocate Request . . . . . . . . . . . . 4 64 3.1.3. Receiving an Allocate Success Response . . . . . . . 5 65 3.1.4. Receiving an Allocate Error Response . . . . . . . . 5 66 3.2. Refreshing an Allocation . . . . . . . . . . . . . . . . 5 67 3.2.1. Sending a Refresh Request . . . . . . . . . . . . . . 5 68 3.2.2. Receiving a Refresh Request . . . . . . . . . . . . . 6 69 3.2.3. Receiving a Refresh Response . . . . . . . . . . . . 6 70 3.3. New STUN Attribute MOBILITY-TICKET . . . . . . . . . . . 6 71 3.4. New STUN Error Response Code . . . . . . . . . . . . . . 7 72 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 73 5. Implementation Status . . . . . . . . . . . . . . . . . . . . 7 74 5.1. open-sys . . . . . . . . . . . . . . . . . . . . . . . . 7 75 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 76 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 77 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 78 8.1. Normative References . . . . . . . . . . . . . . . . . . 8 79 8.2. Informative References . . . . . . . . . . . . . . . . . 9 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 82 1. Introduction 84 When moving between networks, the endpoint's IP address can change or 85 (due to NAT) the endpoint's public IP address can change. Such a 86 change of IP address 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 change in 90 IP address agnostic to the upper layer protocol (e.g., SCTP). The 91 mechanism described in this document are in that last category. 93 A TURN [RFC5766] server relays media packets and is used for a 94 variety of purposes, including overcoming NAT and firewall traversal 95 issues. The existing TURN specification does not permit a TURN 96 client to reuse an allocation across client IP address changes. Due 97 to this, when the IP address of the client changes, the TURN client 98 has to request for a new allocation, create permissions for the 99 remote peer, create channels etc. In addition to notifying the 100 remote peer of the address change, and punching new pinholes through 101 any NAT/FW that might be on the path. 103 This specification describes a mechanism to seamlessly reuse 104 allocations across client IP address changes without any of the 105 hassles described above. A critical benefit of this technique is 106 that the remote peer does not have to support mobility, or deal with 107 any of the address changes. The client, that is subject to IP 108 address changes, does all the work. The mobility technique works 109 across and between network types (e.g., between 3G and wired Internet 110 access), so long as the client can still access the TURN server. The 111 technique should also work seamlessly when (D)TLS is used as a 112 transport protocol for STUN. When there is a change in IP address, 113 the client uses (D)TLS Session Resumption without Server-Side State 114 as described in [RFC5077] to resume secure communication with the 115 TURN server, using the changed client IP address. 117 2. Notational Conventions 119 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 120 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 121 document are to be interpreted as described in [RFC2119]. 123 This note uses terminology defined in [RFC5245], and the following 124 additional terminology: 126 3. Mobility using TURN 128 To achieve mobility, a TURN client should be able to retain an 129 allocation on the TURN server across changes in the client IP address 130 as a consequence of movement to other networks. 132 When the client sends the initial Allocate request to the TURN 133 server, it will include a new STUN attribute MOBILITY-TICKET (with 134 zero length value), which indicates that the client is capable of 135 mobility and desires a ticket. The TURN server provisions a ticket 136 that is sent inside the new STUN attribute MOBILITY-TICKET in the 137 Allocate Success response to the client. The ticket will be used by 138 the client when it wants to refresh the allocation but with a new 139 client IP address and port. This ensures that an allocation can only 140 be refreshed by the same client that allocated relayed transport 141 address. When a client's IP address changes due to mobility, it 142 presents the previously obtained ticket in a Refresh Request to the 143 TURN server. If the ticket is found to be valid, the TURN server 144 will retain the same relayed address/port for the new IP address/port 145 allowing the client to continue using previous channel bindings -- 146 thus, the TURN client does not need to obtain new channel bindings. 147 Any data from external peer will be delivered by the TURN server to 148 this new IP address/port of the client. The TURN client will 149 continue to send application data to its peers using the previously 150 allocated channelBind Requests. 152 TURN TURN Peer 153 client server A 154 |-- Allocate request --------------->| | 155 | + MOBILITY-TICKET (length=0) | | 156 | | | 157 |<--------------- Allocate failure --| | 158 | (401 Unauthorized) | | 159 | | | 160 |-- Allocate request --------------->| | 161 | + MOBILITY-TICKET (length=0) | | 162 | | | 163 |<---------- Allocate success resp --| | 164 | + MOBILITY-TICKET | | 165 ... ... ... 166 (changes IP address) 167 | | | 168 |-- Refresh request ---------------->| | 169 | + MOBILITY-TICKET | | 170 | | | 171 |<----------- Refresh success resp --| | 172 | + MOBILITY-TICKET | | 173 | | | 175 3.1. Creating an Allocation 177 3.1.1. Sending an Allocate Request 179 In addition to the process described in Section 6.1 of [RFC5766], the 180 client includes the MOBILITY-TICKET attribute with length 0. This 181 indicates the client is a mobile node and wants a ticket. 183 3.1.2. Receiving an Allocate Request 185 In addition to the process described in Section 6.2 of [RFC5766], the 186 server does the following: 188 If the MOBILITY-TICKET attribute is included, and has length zero, 189 and the TURN session mobility is forbidden by local policy, the 190 server MUST reject the request with the new Mobility Forbidden error 191 code. If the MOBILITY-TICKET attribute is included and has non-zero 192 length then the server MUST generate an error response with an error 193 code of 400 (Bad Request). Following the rules specified in 194 [RFC5389], if the server does not understand the MOBILITY-TICKET 195 attribute, it ignores the attribute. 197 If the server can successfully process the request create an 198 allocation, the server replies with a success response that includes 199 a STUN MOBILITY-TICKET attribute. TURN server can store system 200 internal data into the ticket that is encrypted by a key known only 201 to the TURN server and sends the ticket in the STUN MOBILITY-TICKET 202 attribute as part of Allocate success response. 204 The ticket is opaque to the client, so the structure is not subject 205 to interoperability concerns, and implementations may diverge from 206 this format. TURN Allocation state information is encrypted using 207 128-bit key for Advance Encryption Standard (AES) and 256-bit key for 208 HMAC-SHA-256 for integrity protection. 210 3.1.3. Receiving an Allocate Success Response 212 In addition to the process described in Section 6.3 of [RFC5766], the 213 client will store the MOBILITY-TICKET attribute, if present, from the 214 response. This attribute will be presented by the client to the 215 server during a subsequent Refresh request to aid mobility. 217 3.1.4. Receiving an Allocate Error Response 219 If the client receives an Allocate error response with error code TBD 220 (Mobility Forbidden), the error is processed as follows: 222 o TBD (Mobility Forbidden): The request is valid, but the server is 223 refusing to perform it, likely due to administrative restrictions. 224 The client considers the current transaction as having failed. The 225 client MAY notify the user or operator and SHOULD NOT retry the same 226 request with this server until it believes the problem has been 227 fixed. 229 All other error responses must be handled as described in [RFC5766]. 231 3.2. Refreshing an Allocation 233 3.2.1. Sending a Refresh Request 235 If a client wants to refresh an existing allocation and update its 236 time-to-expiry or delete an existing allocation, it will send a 237 Refresh Request as described in Section 7.1 of [RFC5766]. If the 238 client wants to retain the existing allocation in case of IP change, 239 it will include the MOBILITY-TICKET attribute received in the 240 Allocate Success response. If a Refresh transaction was previously 241 made, the MOBILITY-TICKET attribute received in the Refresh Success 242 response of the transaction must be used. 244 3.2.2. Receiving a Refresh Request 246 In addition to the process described in Section 7.2 of [RFC5766], the 247 client does the following: 249 If the STUN MOBILITY-TICKET attribute is included in the Refresh 250 Request then the server will not retrieve the 5-tuple from the packet 251 to identify an associated allocation. Instead TURN server will 252 decrypt the received ticket, verify the ticket's validity and 253 retrieve the 5-tuple allocation using the ticket. If this 5-tuple 254 obtained does not identify an existing allocation then the server 255 MUST reject the request with an error. 257 If the source IP address and port of the Refresh Request is different 258 from the stored 5-tuple allocation, the TURN server proceeds with 259 MESSAGE-INTEGRITY validation to identify the that it is the same user 260 which had previously created the TURN allocation. If the above 261 checks are not successful then server MUST reject the request with a 262 441 (Wrong Credentials) error. 264 If all of the above checks pass, the TURN server understands that the 265 client has moved to a new network and acquired a new IP address. The 266 source IP address of the request could either be the host transport 267 address or server-reflexive transport address. The server then 268 updates it's 5-tuple with the new client IP address and port. TURN 269 server calculates the ticket with the new 5-tuple and sends the new 270 ticket in the STUN MOBILITY-TICKET attribute as part of Refresh 271 Success response. 273 3.2.3. Receiving a Refresh Response 275 In addition to the process described in Section 7.3 of [RFC5766], the 276 client will store the MOBILITY-TICKET attribute, if present, from the 277 response. This attribute will be presented by the client to the 278 server during a subsequent Refresh Request to aid mobility. 280 3.3. New STUN Attribute MOBILITY-TICKET 282 This attribute is used to retain an Allocation on the TURN server. 283 It is exchanged between the client and server to aid mobility. The 284 value of MOBILITY-TICKET is encrypted and is of variable-length. 286 3.4. New STUN Error Response Code 288 This document defines the following new error response code: 290 Mobility Forbidden: Mobility request was valid but cannot be 291 performed due to administrative or similar restrictions. 293 4. IANA Considerations 295 IANA is requested to add the following attributes to the STUN 296 attribute registry [iana-stun], 298 o MOBILITY-TICKET (0x802E, in the comprehension-optional range) 300 and to add a new STUN error code "Mobility Forbidden" with the value 301 405 to the STUN Error Codes registry [iana-stun]. 303 5. Implementation Status 305 [Note to RFC Editor: Please remove this section and reference to 306 [RFC6982] prior to publication.] 308 This section records the status of known implementations of the 309 protocol defined by this specification at the time of posting of this 310 Internet-Draft, and is based on a proposal described in [RFC6982]. 311 The description of implementations in this section is intended to 312 assist the IETF in its decision processes in progressing drafts to 313 RFCs. Please note that the listing of any individual implementation 314 here does not imply endorsement by the IETF. Furthermore, no effort 315 has been spent to verify the information presented here that was 316 supplied by IETF contributors. This is not intended as, and must not 317 be construed to be, a catalog of available implementations or their 318 features. Readers are advised to note that other implementations may 319 exist. 321 According to [RFC6982], "this will allow reviewers and working groups 322 to assign due consideration to documents that have the benefit of 323 running code, which may serve as evidence of valuable experimentation 324 and feedback that have made the implemented protocols more mature. 325 It is up to the individual working groups to use this information as 326 they see fit". 328 5.1. open-sys 330 Organization: This is a public project, the full list of authors 331 and contributors here: http://turnserver.open-sys.org/downloads/ 332 AUTHORS 334 Description: A mature open-source TURN server specs implementation 335 (RFC 5766, RFC 6062, RFC 6156, etc) designed for high-performance 336 applications, especially geared for WebRTC. 338 Implementation: http://code.google.com/p/rfc5766-turn-server/ 340 Level of maturity: The Mobile ICE feature implementation can be 341 qualified as "production" - it is well tested and fully 342 implemented, but not widely used, yet.. 344 Coverage: Fully implements MICE with TURN protocol. 346 Licensing: BSD: http://turnserver.open-sys.org/downloads/LICENSE 348 Implementation experience: MICE implementation is somewhat 349 challenging for a multi-threaded performance-oriented application 350 (because the mobile ticket information must be shared between the 351 threads) but it is doable. 353 Contact: Oleg Moskalenko . 355 6. Security Considerations 357 TURN server MUST use strong encryption and integrity protection for 358 the ticket to prevent an attacker from using a brute force mechanism 359 to obtain the ticket's contents or refreshing allocations. 361 Security considerations described in [RFC5766] are also applicable to 362 this mechanism. 364 7. Acknowledgements 366 Thanks to Alfred Heggestad, Lishitao, Sujing Zhou, Martin Thomson, 367 Emil Ivov and Oleg Moskalenko for review and comments. 369 8. References 371 8.1. Normative References 373 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 374 Requirement Levels", BCP 14, RFC 2119, March 1997. 376 [RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig, 377 "Transport Layer Security (TLS) Session Resumption without 378 Server-Side State", RFC 5077, January 2008. 380 [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment 381 (ICE): A Protocol for Network Address Translator (NAT) 382 Traversal for Offer/Answer Protocols", RFC 5245, April 383 2010. 385 [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, 386 "Session Traversal Utilities for NAT (STUN)", RFC 5389, 387 October 2008. 389 [RFC5766] Mahy, R., Matthews, P., and J. Rosenberg, "Traversal Using 390 Relays around NAT (TURN): Relay Extensions to Session 391 Traversal Utilities for NAT (STUN)", RFC 5766, April 2010. 393 8.2. Informative References 395 [RFC6982] Sheffer, Y. and A. Farrel, "Improving Awareness of Running 396 Code: The Implementation Status Section", RFC 6982, July 397 2013. 399 [iana-stun] 400 IANA, , "IANA: STUN Attributes", April 2011, 401 . 404 Authors' Addresses 406 Dan Wing 407 Cisco Systems, Inc. 408 170 West Tasman Drive 409 San Jose, California 95134 410 USA 412 Email: dwing@cisco.com 414 Prashanth Patil 415 Cisco Systems, Inc. 416 Bangalore 417 India 419 Email: praspati@cisco.com 420 Tirumaleswar Reddy 421 Cisco Systems, Inc. 422 Cessna Business Park, Varthur Hobli 423 Sarjapur Marathalli Outer Ring Road 424 Bangalore, Karnataka 560103 425 India 427 Email: tireddy@cisco.com 429 Paal-Erik Martinsen 430 Cisco Systems, Inc. 431 Philip Pedersens vei 22 432 Lysaker, Akershus 1325 433 Norway 435 Email: palmarti@cisco.com