idnits 2.17.1 draft-ietf-tram-turn-mobility-09.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 (September 9, 2016) is 2757 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 557 ** 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 T. Reddy 3 Internet-Draft D. Wing 4 Intended status: Standards Track P. Patil 5 Expires: March 13, 2017 P. Martinsen 6 Cisco 7 September 9, 2016 9 Mobility with TURN 10 draft-ietf-tram-turn-mobility-09 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 March 13, 2017. 42 Copyright Notice 44 Copyright (c) 2016 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 . . . . . . . . . . . . . . . . . . . . . 4 62 3.1. Creating an Allocation . . . . . . . . . . . . . . . . . 5 63 3.1.1. Sending an Allocate Request . . . . . . . . . . . . . 5 64 3.1.2. Receiving an Allocate Request . . . . . . . . . . . . 6 65 3.1.3. Receiving an Allocate Success Response . . . . . . . 6 66 3.1.4. Receiving an Allocate Error Response . . . . . . . . 6 67 3.2. Refreshing an Allocation . . . . . . . . . . . . . . . . 7 68 3.2.1. Sending a Refresh Request . . . . . . . . . . . . . . 7 69 3.2.2. Receiving a Refresh Request . . . . . . . . . . . . . 7 70 3.2.3. Receiving a Refresh Response . . . . . . . . . . . . 9 71 3.3. New STUN Attribute MOBILITY-TICKET . . . . . . . . . . . 9 72 3.4. New STUN Error Response Code . . . . . . . . . . . . . . 9 73 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 74 5. Implementation Status . . . . . . . . . . . . . . . . . . . . 9 75 5.1. open-sys . . . . . . . . . . . . . . . . . . . . . . . . 10 76 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 77 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 78 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 79 8.1. Normative References . . . . . . . . . . . . . . . . . . 11 80 8.2. Informative References . . . . . . . . . . . . . . . . . 12 81 Appendix A. Example ticket construction . . . . . . . . . . . . 12 82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 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 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 signaling server, send an updated offer to the remote peer 104 conveying the new relayed candidate address, remote side has to 105 regather all candidates and signal them to the client and then the 106 endpoints have to perform Interactive Connectivity Establishment 107 (ICE) [RFC5245] connectivity checks. If ICE continuous nomination 108 procedure [I-D.uberti-mmusic-nombis] is used then new relayed 109 candidate address would have to be trickled 110 [I-D.ietf-mmusic-trickle-ice] and ICE connectivity checks have to be 111 performed by the endpoints to nominate pairs that will be selected by 112 ICE. 114 This specification describes a mechanism to seamlessly reuse 115 allocations across client IP address changes without any of the 116 hassles described above. A critical benefit of this technique is 117 that the remote peer does not have to support mobility, or deal with 118 any of the address changes. The client, that is subject to IP 119 address changes, does all the work. The mobility technique works 120 across and between network types (e.g., between 3G and wired Internet 121 access), so long as the client can still access the TURN server. The 122 technique should also work seamlessly when (D)TLS is used as a 123 transport protocol for Session Traversal Utilities for NAT (STUN) 124 [RFC5389]. When there is a change in IP address, the client uses 125 (D)TLS Session Resumption without Server-Side State as described in 126 [RFC5077] to resume secure communication with the TURN server, using 127 the changed client IP address. 129 2. Notational Conventions 131 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 132 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 133 document are to be interpreted as described in [RFC2119]. 135 This note uses terminology defined in [RFC5245], and the following 136 additional terminology: 138 Break Before Make: The old communication path is broken ("break") 139 before new communication can be created ("make"). Such changes 140 typically occur because a network is disconnected with a physical 141 cable, turning radio off, or moving out of radio range. 143 Make Before Break: A new communication path is created ("make") 144 before the old communication path is broken ("break"). Such changes 145 typically occur because a network is connected with a physical cable, 146 turning radio on, or moving into radio range. 148 3. Mobility using TURN 150 To achieve mobility, a TURN client should be able to retain an 151 allocation on the TURN server across changes in the client IP address 152 as a consequence of movement to other networks. 154 When the client sends the initial Allocate request to the TURN 155 server, it will include a new STUN attribute MOBILITY-TICKET (with 156 zero length value), which indicates that the client is capable of 157 mobility and desires a ticket. The TURN server provisions a ticket 158 that is sent inside the new STUN attribute MOBILITY-TICKET in the 159 Allocate Success response to the client. The ticket will be used by 160 the client when it wants to refresh the allocation but with a new 161 client IP address and port. This ensures that an allocation can only 162 be refreshed by the same client that allocated relayed transport 163 address. When a client's IP address changes due to mobility, it 164 presents the previously obtained ticket in a Refresh Request to the 165 TURN server. If the ticket is found to be valid, the TURN server 166 will retain the same relayed address/port for the new IP address/port 167 allowing the client to continue using previous channel bindings -- 168 thus, the TURN client does not need to obtain new channel bindings. 169 Any data from external peer will be delivered by the TURN server to 170 this new IP address/port of the client. The TURN client will 171 continue to send application data to its peers using the previously 172 allocated channelBind Requests. 174 TURN TURN Peer 175 client server A 176 |-- Allocate request --------------->| | 177 | + MOBILITY-TICKET (length=0) | | 178 | | | 179 |<--------------- Allocate failure --| | 180 | (401 Unauthorized) | | 181 | | | 182 |-- Allocate request --------------->| | 183 | + MOBILITY-TICKET (length=0) | | 184 | | | 185 |<---------- Allocate success resp --| | 186 | + MOBILITY-TICKET | | 187 ... ... ... 188 (changes IP address) 189 | | | 190 |-- Refresh request ---------------->| | 191 | + MOBILITY-TICKET | | 192 | | | 193 |<----------- Refresh success resp --| | 194 | + MOBILITY-TICKET | | 195 | | | 197 Figure 1: Mobility using TURN 199 In Figure 1, the client sends an Allocate request with an MOBILITY- 200 TICKET attribute to the server without credentials. Since the server 201 requires that all requests be authenticated using STUN's long-term 202 credential mechanism, the server rejects the request with a 401 203 (Unauthorized) error code. The client then tries again, this time 204 including credentials (not shown). This time, the server accepts the 205 Allocate request and returns an Allocate success response and a 206 ticket inside the MOBILITY-TICKET attribute. Sometime later, the 207 client IP address changes and decides to refresh the allocation and 208 thus sends a Refresh request to the server with MOBILITY-TICKET 209 attribute containing the ticket it had received from the server. The 210 refresh is accepted and the server replies with a Refresh success 211 response and a new ticket inside the MOBILITY-TICKET attribute. 213 3.1. Creating an Allocation 215 3.1.1. Sending an Allocate Request 217 In addition to the process described in Section 6.1 of [RFC5766], the 218 client includes the MOBILITY-TICKET attribute with length 0. This 219 indicates the client is a mobile node and wants a ticket. 221 3.1.2. Receiving an Allocate Request 223 In addition to the process described in Section 6.2 of [RFC5766], the 224 server does the following: 226 If the MOBILITY-TICKET attribute is included, and has length zero, 227 but TURN session mobility is forbidden by local policy, the server 228 will reject the request with the new Mobility Forbidden error code. 229 If the MOBILITY-TICKET attribute is included and has non-zero length 230 then the server will generate an error response with an error code of 231 400 (Bad Request). Following the rules specified in [RFC5389], if 232 the server does not understand the MOBILITY-TICKET attribute, it 233 ignores the attribute. 235 If the server can successfully process the request and create an 236 allocation, the server replies with a success response that includes 237 a STUN MOBILITY-TICKET attribute. TURN server can store system 238 internal data into the ticket that is encrypted by a key known only 239 to the TURN server and sends the ticket in the STUN MOBILITY-TICKET 240 attribute as part of Allocate success response. An example for 241 ticket construction is discussed in Appendix A .The ticket is opaque 242 to the client, so the structure is not subject to interoperability 243 concerns, and implementations may diverge from this format. The 244 client could be roaming across networks with different path MTU and 245 from one address family to another (e.g. IPv6 to IPv4). The TURN 246 server to support mobility must assume that the path MTU is unknown 247 and use a ticket length in accordance with published guidance on STUN 248 UDP fragmentation (Section 7.1 of [RFC5389]). 250 Note: There is no guarantee that the fields in the ticket are going 251 to be decodable to a client, and therefore attempts by a client to 252 examine the ticket are unlikely to be useful. 254 3.1.3. Receiving an Allocate Success Response 256 In addition to the process described in Section 6.3 of [RFC5766], the 257 client will store the MOBILITY-TICKET attribute, if present, from the 258 response. This attribute will be presented by the client to the 259 server during a subsequent Refresh request to aid mobility. 261 3.1.4. Receiving an Allocate Error Response 263 If the client receives an Allocate error response with error code TBD 264 (Mobility Forbidden), the error is processed as follows: 266 o TBD (Mobility Forbidden): The request is valid, but the server is 267 refusing to perform it, likely due to administrative restrictions. 268 The client considers the current transaction as having failed. The 269 client can notify the user or operator. The client SHOULD NOT retry 270 to send Allocate request containing MOBILITY-TICKET with this server 271 until it believes the problem has been fixed. 273 All other error responses must be handled as described in [RFC5766]. 275 3.2. Refreshing an Allocation 277 3.2.1. Sending a Refresh Request 279 If a client wants to refresh an existing allocation and update its 280 time-to-expiry or delete an existing allocation, it sends a Refresh 281 Request as described in Section 7.1 of [RFC5766]. If IP address or 282 source port number of the client has changed and the client wants to 283 retain the existing allocation, the client includes the MOBILITY- 284 TICKET attribute received in the Allocate Success response in the 285 Refresh Request. If there has been no IP address or source port 286 number change, the client MUST NOT include a MOBILITY-TICKET 287 attribute, as this will be rejected by the server and the client 288 would need to retransmit the Refresh Request without the MOBILITY- 289 TICKET attribute. 291 3.2.2. Receiving a Refresh Request 293 In addition to the process described in Section 7.2 of [RFC5766], the 294 server does the following: 296 If the STUN MOBILITY-TICKET attribute is included in the Refresh 297 Request and the server configuration changed to forbid mobility or 298 the server transparently fails-over to another server instance that 299 forbids mobility then the server rejects the Refresh request with a 300 Mobility Forbidden error code and the client starts afresh with a new 301 allocation. 303 If the STUN MOBILITY-TICKET attribute is included in the Refresh 304 Request then the server will not retrieve the 5-tuple from the packet 305 to identify an associated allocation. Instead the TURN server will 306 decrypt the received ticket, verify the ticket's validity and 307 retrieve the 5-tuple allocation using the ticket. If this 5-tuple 308 obtained does not identify an existing allocation then the server 309 MUST reject the request with a 437 (Allocation Mismatch) error. If 310 the ticket is invalid then the server MUST reject the request with a 311 400 (Bad Request) error. 313 If the source IP address and port of the Refresh Request with STUN 314 MOBILITY-TICKET attribute is same as the stored 5-tuple allocation 315 then the TURN server rejects the request with 400 (Bad Request) 316 error. If the source IP address and port of the Refresh Request is 317 different from the stored 5-tuple allocation, the TURN server 318 proceeds with MESSAGE-INTEGRITY validation to identify the that it is 319 the same user which had previously created the TURN allocation. If 320 the above check is not successful then server MUST reject the request 321 with a 441 (Wrong Credentials) error. 323 If all of the above checks pass, the TURN server understands that the 324 client has either moved to a new network and acquired a new IP 325 address (Break Before Make) or is in the process of switching to a 326 new interface (Make Before Break). The source IP address of the 327 request could either be the host transport address or server- 328 reflexive transport address. The server then updates its state data 329 with the new client IP address and port but does not discard the old 330 5-tuple from its state data. TURN server calculates the ticket with 331 the new 5-tuple and sends the new ticket in the STUN MOBILITY-TICKET 332 attribute as part of Refresh Success response. The new ticket sent 333 in the refresh response MUST be different from the old ticket. 335 The TURN server MUST continue receiving and processing data on the 336 old 5-tuple and MUST continue transmitting data on the old-5 tuple 337 until it receives an Send Indication or ChannelData message from the 338 client on the new 5-tuple or an message from the client to close the 339 old connection (e.g., a TLS fatal alert, TCP RST). After receiving 340 any of those messages, a TURN server discards the the old ticket and 341 the old 5-tuple associated with the old ticket from its state data. 342 Data sent by the client to the peer is accepted on the new 5-tuple 343 and data received from the peer is forwarded to the new 5-tuple. If 344 the refresh request containing the MOBILITY-TICKET attribute does not 345 succeed (e.g., packet lost if the request is sent over UDP, or the 346 server being unable to fulfill the request) then the client can 347 continue to exchange data on the old 5-tuple until it receives 348 Refresh success response. 350 The old ticket can only be used for the purposes of retransmission. 351 If the client wants to refresh its allocation with a new server- 352 reflexive transport address, it MUST use the new ticket. If the TURN 353 server has not received a Refresh Request with STUN MOBILITY-TICKET 354 attribute but receives Send indications or ChannelData messages from 355 a client, the TURN server MAY discard or queue those Send indications 356 or ChannelData messages (at its discretion). Thus, it is RECOMMENDED 357 that the client avoid transmitting a Send indication or ChannelData 358 message until it has received an acknowledgement for the Refresh 359 Request with STUN MOBILITY-TICKET attribute. 361 To accommodate for loss of Refresh responses, a server must retain 362 the old STUN MOBILITY-TICKET attribute for a period of at least 30 363 seconds to be able to recognize a retransmission of Refresh request 364 with the old STUN MOBILITY-TICKET attribute from the client. 366 3.2.3. Receiving a Refresh Response 368 In addition to the process described in Section 7.3 of [RFC5766], the 369 client will store the MOBILITY-TICKET attribute, if present, from the 370 response. This attribute will be presented by the client to the 371 server during a subsequent Refresh Request to aid mobility. 373 3.3. New STUN Attribute MOBILITY-TICKET 375 This attribute is used to retain an Allocation on the TURN server. 376 It is exchanged between the client and server to aid mobility. The 377 value of MOBILITY-TICKET is encrypted and is of variable-length. 379 3.4. New STUN Error Response Code 381 This document defines the following new error response code: 383 TBD Mobility Forbidden: Mobility request was valid but cannot be 384 performed due to administrative or similar restrictions. 386 4. IANA Considerations 388 [Note to RFC editor: Please update sections 3.1.4 and 3.4 with the 389 error number.] 391 IANA is requested to add the following attributes to the STUN 392 attribute registry [iana-stun], 394 o MOBILITY-TICKET (0x8030, in the comprehension-optional range) 396 and to add a new STUN error code "Mobility Forbidden" with the value 397 405 to the STUN Error Codes registry [iana-stun]. 399 5. Implementation Status 401 [Note to RFC Editor: Please remove this section and reference to 402 [RFC6982] prior to publication.] 404 This section records the status of known implementations of the 405 protocol defined by this specification at the time of posting of this 406 Internet-Draft, and is based on a proposal described in [RFC6982]. 407 The description of implementations in this section is intended to 408 assist the IETF in its decision processes in progressing drafts to 409 RFCs. Please note that the listing of any individual implementation 410 here does not imply endorsement by the IETF. Furthermore, no effort 411 has been spent to verify the information presented here that was 412 supplied by IETF contributors. This is not intended as, and must not 413 be construed to be, a catalog of available implementations or their 414 features. Readers are advised to note that other implementations may 415 exist. 417 According to [RFC6982], "this will allow reviewers and working groups 418 to assign due consideration to documents that have the benefit of 419 running code, which may serve as evidence of valuable experimentation 420 and feedback that have made the implemented protocols more mature. 421 It is up to the individual working groups to use this information as 422 they see fit". 424 5.1. open-sys 426 Organization: This is a public project, the full list of authors 427 and contributors here: http://turnserver.open-sys.org/downloads/ 428 AUTHORS 430 Description: A mature open-source TURN server specs implementation 431 (RFC 5766, RFC 6062, RFC 6156, etc) designed for high-performance 432 applications, especially geared for WebRTC. 434 Implementation: http://code.google.com/p/rfc5766-turn-server/ 436 Level of maturity: The Mobile ICE feature implementation can be 437 qualified as "production" - it is well tested and fully 438 implemented, but not widely used, yet.. 440 Coverage: Fully implements Mobility with TURN. 442 Licensing: BSD: http://turnserver.open-sys.org/downloads/LICENSE 444 Implementation experience: Mobility with TURN implementation is 445 somewhat challenging for a multi-threaded performance-oriented 446 application (because the mobile ticket information must be shared 447 between the threads) but it is doable. 449 Contact: Oleg Moskalenko . 451 6. Security Considerations 453 TURN server MUST always ensure that the ticket is authenticated and 454 encrypted using strong cryptographic algorithms to prevent 455 modification or eavesdropping by an attacker. The ticket MUST be 456 constructed such that it has strong entropy to ensure nothing can be 457 gleaned by looking at the ticket alone. 459 An attacker monitoring the traffic between the TURN client and server 460 can impersonate the client and refresh the allocation using the 461 ticket issued to the client with the attackers IP address and port. 463 TURN client and server MUST use STUN long-term credential mechanism 464 [RFC5389] or STUN Extension for Third-Party Authorization 465 [RFC7635][RFC7635] or (D)TLS connection to avoid malicious users 466 trying to impersonate the client. With any of those three 467 mechanisms, when the server receives Refresh Request with STUN 468 MOBILITY-TICKET attribute from the client it identifies that it is 469 indeed the same client but with a new IP address and port using the 470 ticket it had previously issued to refresh the allocation. If (D)TLS 471 is not used or (D)TLS handshake fails, and authentication also fails 472 then TURN client and server MUST fail, and not proceed with TURN 473 mobility. 475 Security considerations described in [RFC5766] are also applicable to 476 this mechanism. 478 7. Acknowledgements 480 Thanks to Alfred Heggestad, Lishitao, Sujing Zhou, Martin Thomson, 481 Emil Ivov, Oleg Moskalenko, Dave Waltermire, Pete Resnick, Antoni 482 Przygienda, Alissa Cooper, Ben Campbell, Suresh Krishnan, Mirja 483 Kuehlewind, Jonathan Lennox and Brandon Williams for review and 484 comments. 486 8. References 488 8.1. Normative References 490 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 491 Requirement Levels", BCP 14, RFC 2119, 492 DOI 10.17487/RFC2119, March 1997, 493 . 495 [RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig, 496 "Transport Layer Security (TLS) Session Resumption without 497 Server-Side State", RFC 5077, DOI 10.17487/RFC5077, 498 January 2008, . 500 [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment 501 (ICE): A Protocol for Network Address Translator (NAT) 502 Traversal for Offer/Answer Protocols", RFC 5245, 503 DOI 10.17487/RFC5245, April 2010, 504 . 506 [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, 507 "Session Traversal Utilities for NAT (STUN)", RFC 5389, 508 DOI 10.17487/RFC5389, October 2008, 509 . 511 [RFC5766] Mahy, R., Matthews, P., and J. Rosenberg, "Traversal Using 512 Relays around NAT (TURN): Relay Extensions to Session 513 Traversal Utilities for NAT (STUN)", RFC 5766, 514 DOI 10.17487/RFC5766, April 2010, 515 . 517 8.2. Informative References 519 [I-D.ietf-mmusic-trickle-ice] 520 Ivov, E., Rescorla, E., and J. Uberti, "Trickle ICE: 521 Incremental Provisioning of Candidates for the Interactive 522 Connectivity Establishment (ICE) Protocol", draft-ietf- 523 mmusic-trickle-ice-02 (work in progress), January 2015. 525 [I-D.uberti-mmusic-nombis] 526 Uberti, J. and J. Lennox, "Improvements to ICE Candidate 527 Nomination", draft-uberti-mmusic-nombis-00 (work in 528 progress), March 2015. 530 [iana-stun] 531 IANA, , "IANA: STUN Attributes", April 2011, 532 . 535 [RFC6982] Sheffer, Y. and A. Farrel, "Improving Awareness of Running 536 Code: The Implementation Status Section", RFC 6982, 537 DOI 10.17487/RFC6982, July 2013, 538 . 540 [RFC7635] Reddy, T., Patil, P., Ravindranath, R., and J. Uberti, 541 "Session Traversal Utilities for NAT (STUN) Extension for 542 Third-Party Authorization", RFC 7635, 543 DOI 10.17487/RFC7635, August 2015, 544 . 546 Appendix A. Example ticket construction 548 The TURN server uses two different keys: one 128-bit key for Advance 549 Encryption Standard (AES) in Cipher Block Chaining (CBC) mode 550 (AES_128_CBC) and 256-bit key for HMAC-SHA-256-128 for integrity 551 protection. The ticket can be structured as follows: 553 struct { 554 opaque key_name[16]; 555 opaque iv[16]; 556 opaque encrypted_state<0..2^16-1>; 557 opaque mac[16]; 558 } ticket; 560 Figure 2: Ticket Format 562 Here, key_name serves to identify a particular set of keys used to 563 protect the ticket. It enables the TURN server to easily recognize 564 tickets it has issued. The key_name should be randomly generated to 565 avoid collisions between servers. One possibility is to generate new 566 random keys and key_name every time the server is started. 568 The TURN state information (self-contained or handle) in 569 encrypted_state is encrypted using 128-bit AES in CBC mode with the 570 given IV. The MAC is calculated using HMAC-SHA-256-128 over key_name 571 (16 octets)and IV (16 octets), followed by the length of the 572 encrypted_state field (2 octets) and its contents (variable length). 574 Authors' Addresses 576 Tirumaleswar Reddy 577 Cisco Systems, Inc. 578 Cessna Business Park, Varthur Hobli 579 Sarjapur Marathalli Outer Ring Road 580 Bangalore, Karnataka 560103 581 India 583 Email: tireddy@cisco.com 585 Dan Wing 586 Cisco Systems, Inc. 587 170 West Tasman Drive 588 San Jose, California 95134 589 USA 591 Email: dwing@cisco.com 593 Prashanth Patil 594 Cisco Systems, Inc. 595 Bangalore 596 India 598 Email: praspati@cisco.com 599 Paal-Erik Martinsen 600 Cisco Systems, Inc. 601 Philip Pedersens vei 22 602 Lysaker, Akershus 1325 603 Norway 605 Email: palmarti@cisco.com