summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc8016.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc8016.txt')
-rw-r--r--doc/rfc/rfc8016.txt731
1 files changed, 731 insertions, 0 deletions
diff --git a/doc/rfc/rfc8016.txt b/doc/rfc/rfc8016.txt
new file mode 100644
index 0000000..7e1f1ec
--- /dev/null
+++ b/doc/rfc/rfc8016.txt
@@ -0,0 +1,731 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF) T. Reddy
+Request for Comments: 8016 Cisco
+Category: Standards Track D. Wing
+ISSN: 2070-1721
+ P. Patil
+ P. Martinsen
+ Cisco
+ November 2016
+
+
+ Mobility with Traversal Using Relays around NAT (TURN)
+
+Abstract
+
+ It is desirable to minimize traffic disruption caused by changing IP
+ address during a mobility event. One mechanism to minimize
+ disruption is to expose a shorter network path to the mobility event
+ so that only the local network elements are aware of the changed IP
+ address and the remote peer is unaware of the changed IP address.
+
+ This document provides such an IP address mobility solution using
+ Traversal Using Relays around NAT (TURN). This is achieved by
+ allowing a client to retain an allocation on the TURN server when the
+ IP address of the client changes.
+
+Status of This Memo
+
+ This is an Internet Standards Track document.
+
+ This document is a product of the Internet Engineering Task Force
+ (IETF). It represents the consensus of the IETF community. It has
+ received public review and has been approved for publication by the
+ Internet Engineering Steering Group (IESG). Further information on
+ Internet Standards is available in Section 2 of RFC 7841.
+
+ Information about the current status of this document, any errata,
+ and how to provide feedback on it may be obtained at
+ http://www.rfc-editor.org/info/rfc8016.
+
+
+
+
+
+
+
+
+
+
+
+
+
+Reddy, et al. Standards Track [Page 1]
+
+RFC 8016 Mobility with TURN November 2016
+
+
+Copyright Notice
+
+ Copyright (c) 2016 IETF Trust and the persons identified as the
+ document authors. All rights reserved.
+
+ This document is subject to BCP 78 and the IETF Trust's Legal
+ Provisions Relating to IETF Documents
+ (http://trustee.ietf.org/license-info) in effect on the date of
+ publication of this document. Please review these documents
+ carefully, as they describe your rights and restrictions with respect
+ to this document. Code Components extracted from this document must
+ include Simplified BSD License text as described in Section 4.e of
+ the Trust Legal Provisions and are provided without warranty as
+ described in the Simplified BSD License.
+
+Table of Contents
+
+ 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
+ 2. Notational Conventions . . . . . . . . . . . . . . . . . . . 4
+ 3. Mobility Using TURN . . . . . . . . . . . . . . . . . . . . . 4
+ 3.1. Creating an Allocation . . . . . . . . . . . . . . . . . 5
+ 3.1.1. Sending an Allocate Request . . . . . . . . . . . . . 5
+ 3.1.2. Receiving an Allocate Request . . . . . . . . . . . . 6
+ 3.1.3. Receiving an Allocate Success Response . . . . . . . 6
+ 3.1.4. Receiving an Allocate Error Response . . . . . . . . 7
+ 3.2. Refreshing an Allocation . . . . . . . . . . . . . . . . 7
+ 3.2.1. Sending a Refresh Request . . . . . . . . . . . . . . 7
+ 3.2.2. Receiving a Refresh Request . . . . . . . . . . . . . 7
+ 3.2.3. Receiving a Refresh Response . . . . . . . . . . . . 9
+ 3.3. New STUN Attribute MOBILITY-TICKET . . . . . . . . . . . 9
+ 3.4. New STUN Error Response Code . . . . . . . . . . . . . . 9
+ 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
+ 5. Security Considerations . . . . . . . . . . . . . . . . . . . 9
+ 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
+ 6.1. Normative References . . . . . . . . . . . . . . . . . . 10
+ 6.2. Informative References . . . . . . . . . . . . . . . . . 11
+ Appendix A. Example of Ticket Construction . . . . . . . . . . . 12
+ Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 13
+ Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13
+
+
+
+
+
+
+
+
+
+
+
+
+Reddy, et al. Standards Track [Page 2]
+
+RFC 8016 Mobility with TURN November 2016
+
+
+1. Introduction
+
+ When moving between networks, the endpoint's IP address can change
+ or, due to NAT, the endpoint's public IP address can change. Such a
+ change of IP address breaks upper-layer protocols such as TCP and
+ RTP. Various techniques exist to prevent this breakage, all tied to
+ making the endpoint's IP address static (e.g., Mobile IP, Proxy
+ Mobile IP, Locator/ID Separation Protocol (LISP)). Other techniques
+ exist, which make the change in IP address agnostic to the upper-
+ layer protocol (e.g., Stream Control Transmission Protocol (SCTP)).
+ The mechanism described in this document is in that last category.
+
+ A server using Traversal Using Relays around NAT (TURN) [RFC5766]
+ relays media packets and is used for a variety of purposes, including
+ overcoming NAT and firewall traversal issues. The existing TURN
+ specification does not permit a TURN client to reuse an allocation
+ across client IP address changes. Due to this, when the IP address
+ of the client changes, the TURN client has to request a new
+ allocation, create permissions for the remote peer, create channels,
+ etc. In addition, the client has to re-establish communication with
+ its signaling server and send an updated offer to the remote peer
+ conveying the newly relayed candidate address. Then, the remote side
+ has to re-gather all candidates and signal them to the client, and
+ the endpoints have to perform Interactive Connectivity Establishment
+ (ICE) [RFC5245] checks. If the ICE continuous nomination procedure
+ [NOMBIS] is used, then the newly relayed candidate address would have
+ to be "trickled" (i.e., incrementally provisioned as described in
+ [TRICKLE-SIP]), and ICE checks would have to be performed according
+ to [TRICKLE-ICE] by the endpoints to nominate pairs for selection by
+ ICE.
+
+ This specification describes a mechanism to seamlessly reuse
+ allocations across client IP address changes without any of the
+ hassles described above. A critical benefit of this technique is
+ that the remote peer does not have to support mobility or deal with
+ any of the address changes. The client, which is subject to IP
+ address changes, does all the work. The mobility technique works
+ across and between network types (e.g., between 3G and wired Internet
+ access), so long as the client can still access the TURN server. The
+ technique should also work seamlessly when (D)TLS is used as a
+ transport protocol for Session Traversal Utilities for NAT (STUN)
+ [RFC5389]. When there is a change in IP address, the client uses
+ (D)TLS Session Resumption without Server-Side State as described in
+ [RFC5077] to resume secure communication with the TURN server, using
+ the changed client IP address.
+
+
+
+
+
+
+Reddy, et al. Standards Track [Page 3]
+
+RFC 8016 Mobility with TURN November 2016
+
+
+2. Notational Conventions
+
+ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+ "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+ document are to be interpreted as described in [RFC2119].
+
+ This document uses terminology defined in [RFC5245] and the following
+ additional terminology:
+
+ Break Before Make: The old communication path is broken ("break")
+ before new communication can be created ("make"). Such changes
+ typically occur because a network's physical cable is disconnected,
+ radio transmission is turned off, or a client moves out of radio
+ range.
+
+ Make Before Break: A new communication path is created ("make")
+ before the old communication path is broken ("break"). Such changes
+ typically occur because a network is reconnected with a physical
+ cable, radio transmission is turned on, or a client moves into radio
+ range.
+
+3. Mobility Using TURN
+
+ To achieve mobility, a TURN client should be able to retain an
+ allocation on the TURN server across changes in the client IP address
+ as a consequence of movement to other networks.
+
+ When the client sends the initial Allocate request to the TURN
+ server, it will include a new STUN attribute MOBILITY-TICKET (with
+ zero length value), which indicates that the client is capable of
+ mobility and desires a ticket. The TURN server provisions a ticket
+ that is sent inside the new STUN attribute MOBILITY-TICKET in the
+ Allocate success response to the client. The ticket will be used by
+ the client when it wants to refresh the allocation but with a new
+ client IP address and port. This ensures that an allocation can only
+ be refreshed by the same client that allocated the relayed transport
+ address. When a client's IP address changes due to mobility, it
+ presents the previously obtained ticket in a Refresh request to the
+ TURN server. If the ticket is found to be valid, the TURN server
+ will retain the same relayed address/port for the new IP address/port
+ allowing the client to continue using previous channel bindings --
+ thus, the TURN client does not need to obtain new channel bindings.
+ Any data from the external peer will be delivered by the TURN server
+ to this new IP address/port of the client. The TURN client will
+ continue to send application data to its peers using the previously
+ allocated channelBind Requests.
+
+
+
+
+
+Reddy, et al. Standards Track [Page 4]
+
+RFC 8016 Mobility with TURN November 2016
+
+
+ TURN TURN Peer
+ client server A
+ |-- Allocate request --------------->| |
+ | + MOBILITY-TICKET (length=0) | |
+ | | |
+ |<--------------- Allocate failure --| |
+ | (401 Unauthorized) | |
+ | | |
+ |-- Allocate request --------------->| |
+ | + MOBILITY-TICKET (length=0) | |
+ | | |
+ |<---------- Allocate success resp --| |
+ | + MOBILITY-TICKET | |
+ ... ... ...
+ (changes IP address)
+ | | |
+ |-- Refresh request ---------------->| |
+ | + MOBILITY-TICKET | |
+ | | |
+ |<----------- Refresh success resp --| |
+ | + MOBILITY-TICKET | |
+ | | |
+
+ Figure 1: Mobility Using TURN
+
+ In Figure 1, the client sends an Allocate request with a MOBILITY-
+ TICKET attribute to the server without credentials. Since the server
+ requires that all requests be authenticated using STUN's long-term
+ credential mechanism, the server rejects the request with a 401
+ (Unauthorized) error code. The client then tries again, this time
+ including credentials (not shown). This time, the server accepts the
+ Allocate request and returns an Allocate success response and a
+ ticket inside the MOBILITY-TICKET attribute. Sometime later, the
+ client IP address changes, and the client decides to refresh the
+ allocation, and thus sends a Refresh request to the server with a
+ MOBILITY-TICKET attribute containing the ticket it received from the
+ server. The refresh is accepted, and the server replies with a
+ Refresh success response and a new ticket inside the MOBILITY-TICKET
+ attribute.
+
+3.1. Creating an Allocation
+
+3.1.1. Sending an Allocate Request
+
+ In addition to the process described in Section 6.1 of [RFC5766], the
+ client includes the MOBILITY-TICKET attribute with a length of zero.
+ This indicates that the client is a mobile node and wants a ticket.
+
+
+
+
+Reddy, et al. Standards Track [Page 5]
+
+RFC 8016 Mobility with TURN November 2016
+
+
+3.1.2. Receiving an Allocate Request
+
+ In addition to the process described in Section 6.2 of [RFC5766], the
+ server does the following:
+
+ If the MOBILITY-TICKET attribute is included, and has a length of
+ zero, but TURN session mobility is forbidden by local policy, the
+ server will reject the request with the new error code 405 (Mobility
+ Forbidden). If the MOBILITY-TICKET attribute is included and has a
+ non-zero length, then the server will generate an error response with
+ an error code of 400 (Bad Request). Following the rules specified in
+ [RFC5389], if the server does not understand the MOBILITY-TICKET
+ attribute, it ignores the attribute.
+
+ If the server can successfully process the request and create an
+ allocation, the server replies with a success response that includes
+ a STUN MOBILITY-TICKET attribute. The TURN server can store system-
+ internal data in the ticket that is encrypted by a key known only to
+ the TURN server and sends the ticket in the STUN MOBILITY-TICKET
+ attribute as part of the Allocate success response. An example of
+ ticket construction is discussed in Appendix A. The ticket is opaque
+ to the client, so the structure is not subject to interoperability
+ concerns, and implementations may diverge from this format. The
+ client could be roaming across networks with a different path MTU and
+ from one address family to another (e.g., IPv6 to IPv4). The TURN
+ server to support mobility must assume that the path MTU is unknown
+ and use a ticket length in accordance with the published guidance on
+ STUN UDP fragmentation (Section 7.1 of [RFC5389]).
+
+ Note: There is no guarantee that the fields in the ticket are going
+ to be decodable to a client, and therefore attempts by a client to
+ examine the ticket are unlikely to be useful.
+
+3.1.3. Receiving an Allocate Success Response
+
+ In addition to the process described in Section 6.3 of [RFC5766], the
+ client will store the MOBILITY-TICKET attribute, if present, from the
+ response. This attribute will be presented by the client to the
+ server during a subsequent Refresh request to aid mobility.
+
+
+
+
+
+
+
+
+
+
+
+
+Reddy, et al. Standards Track [Page 6]
+
+RFC 8016 Mobility with TURN November 2016
+
+
+3.1.4. Receiving an Allocate Error Response
+
+ If the client receives an Allocate error response with error code 405
+ (Mobility Forbidden), the error is processed as follows:
+
+ 405 (Mobility Forbidden): The request is valid, but the server is
+ refusing to perform it, likely due to administrative restrictions.
+ The client considers the current transaction as having failed.
+
+ The client can notify the user or operator. The client SHOULD NOT
+ retry sending the Allocate request containing the MOBILITY-TICKET
+ with this server until it believes the problem has been fixed.
+
+ All other error responses must be handled as described in [RFC5766].
+
+3.2. Refreshing an Allocation
+
+3.2.1. Sending a Refresh Request
+
+ If a client wants to refresh an existing allocation and update its
+ time-to-expiry or delete an existing allocation, it sends a Refresh
+ request as described in Section 7.1 of [RFC5766]. If the client's IP
+ address or source port has changed and the client wants to retain the
+ existing allocation, the client includes the MOBILITY-TICKET
+ attribute received in the Allocate success response in the Refresh
+ request. If there has been no IP address or source port number
+ change, the client MUST NOT include a MOBILITY-TICKET attribute, as
+ this would be rejected by the server and the client would need to
+ retransmit the Refresh request without the MOBILITY-TICKET attribute.
+
+3.2.2. Receiving a Refresh Request
+
+ In addition to the process described in Section 7.2 of [RFC5766], the
+ server does the following:
+
+ If the STUN MOBILITY-TICKET attribute is included in the Refresh
+ request, and the server configuration changed to forbid mobility or
+ the server transparently fails over to another server instance that
+ forbids mobility, then the server rejects the Refresh request with a
+ 405 (Mobility Forbidden) error and the client starts afresh with a
+ new allocation.
+
+ If the STUN MOBILITY-TICKET attribute is included in the Refresh
+ request, then the server will not retrieve the 5-tuple from the
+ packet to identify an associated allocation. Instead, the TURN
+ server will decrypt the received ticket, verify the ticket's
+ validity, and retrieve the 5-tuple allocation using the ticket. If
+ this 5-tuple obtained does not identify an existing allocation, then
+
+
+
+Reddy, et al. Standards Track [Page 7]
+
+RFC 8016 Mobility with TURN November 2016
+
+
+ the server MUST reject the request with a 437 (Allocation Mismatch)
+ error. If the ticket is invalid, then the server MUST reject the
+ request with a 400 (Bad Request) error.
+
+ If the source IP address and port of the Refresh request with the
+ STUN MOBILITY-TICKET attribute is the same as the stored 5-tuple
+ allocation, then the TURN server rejects the request with a 400 (Bad
+ Request) error. If the source IP address and port of the Refresh
+ request is different from the stored 5-tuple allocation, the TURN
+ server proceeds with a MESSAGE-INTEGRITY validation to identify that
+ it is the same user that had previously created the TURN allocation.
+ If the above check is not successful, then the server MUST reject the
+ request with a 441 (Wrong Credentials) error.
+
+ If all of the above checks pass, the TURN server understands that the
+ client either has moved to a new network and acquired a new IP
+ address (Break Before Make) or is in the process of switching to a
+ new interface (Make Before Break). The source IP address of the
+ request could be either the host transport address or the server-
+ reflexive transport address. The server then updates its state data
+ with the new client IP address and port but does not discard the old
+ 5-tuple from its state data. The TURN server calculates the ticket
+ with the new 5-tuple and sends the new ticket in the STUN MOBILITY-
+ TICKET attribute as part of Refresh success response. The new ticket
+ sent in the refresh response MUST be different from the old ticket.
+
+ The TURN server MUST continue receiving and processing data on the
+ old 5-tuple and MUST continue transmitting data on the old-5 tuple
+ until it receives a Send Indication or ChannelData message from the
+ client on the new 5-tuple or a message from the client to close the
+ old connection (e.g., a TLS fatal alert or TCP RST). After receiving
+ any of those messages, a TURN server discards the old ticket and the
+ old 5-tuple associated with the old ticket from its state data. Data
+ sent by the client to the peer is accepted on the new 5-tuple and
+ data received from the peer is forwarded to the new 5-tuple. If the
+ refresh request containing the MOBILITY-TICKET attribute does not
+ succeed (e.g., the packet is lost if the request is sent over UDP, or
+ the server is unable to fulfill the request), then the client can
+ continue to exchange data on the old 5-tuple until it receives the
+ Refresh success response.
+
+ The old ticket can only be used for the purposes of retransmission.
+ If the client wants to refresh its allocation with a new server-
+ reflexive transport address, it MUST use the new ticket. If the TURN
+ server has not received a Refresh request with the STUN MOBILITY-
+ TICKET attribute but receives Send indications or ChannelData
+ messages from a client, the TURN server MAY discard or queue those
+ Send indications or ChannelData messages (at its discretion). Thus,
+
+
+
+Reddy, et al. Standards Track [Page 8]
+
+RFC 8016 Mobility with TURN November 2016
+
+
+ it is RECOMMENDED that the client avoid transmitting a Send
+ indication or ChannelData message until it has received an
+ acknowledgement for the Refresh request with the STUN MOBILITY-TICKET
+ attribute.
+
+ To accommodate the potential loss of Refresh responses, a server must
+ retain the old STUN MOBILITY-TICKET attribute for a period of at
+ least 30 seconds to be able to recognize a retransmission of the
+ Refresh request with the old STUN MOBILITY-TICKET attribute from the
+ client.
+
+3.2.3. Receiving a Refresh Response
+
+ In addition to the process described in Section 7.3 of [RFC5766], the
+ client will store the MOBILITY-TICKET attribute, if present, from the
+ response. This attribute will be presented by the client to the
+ server during a subsequent Refresh request to aid mobility.
+
+3.3. New STUN Attribute MOBILITY-TICKET
+
+ This attribute is used to retain an allocation on the TURN server.
+ It is exchanged between the client and server to aid mobility. The
+ value of the MOBILITY-TICKET is encrypted and is of variable length.
+
+3.4. New STUN Error Response Code
+
+ This document defines the following new error response code:
+
+ 405 (Mobility Forbidden): Mobility request was valid but cannot be
+ performed due to administrative or similar restrictions.
+
+4. IANA Considerations
+
+ IANA has added the following attribute to the "STUN Attributes"
+ registry [IANA-STUN]:
+
+ o MOBILITY-TICKET (0x8030, in the comprehension-optional range)
+
+ Also, IANA has added a new STUN error code "Mobility Forbidden" with
+ the value 405 to the "STUN Error Codes" registry [IANA-STUN].
+
+5. Security Considerations
+
+ The TURN server MUST always ensure that the ticket is authenticated
+ and encrypted using strong cryptographic algorithms to prevent
+ modification or eavesdropping by an attacker. The ticket MUST be
+ constructed such that it has strong entropy to ensure that nothing
+ can be gleaned by looking at the ticket alone.
+
+
+
+Reddy, et al. Standards Track [Page 9]
+
+RFC 8016 Mobility with TURN November 2016
+
+
+ An attacker monitoring the traffic between the TURN client and server
+ can impersonate the client and refresh the allocation using the
+ ticket issued to the client with the attacker's IP address and port.
+ The TURN client and server MUST use the STUN long-term credential
+ mechanism [RFC5389], the STUN Extension for Third-Party Authorization
+ [RFC7635], or a (D)TLS connection to prevent malicious users from
+ impersonating the client. With any of those three mechanisms, when
+ the server receives the Refresh request with the STUN MOBILITY-TICKET
+ attribute from the client, it identifies that it is indeed the same
+ client but with a new IP address and port using the ticket it had
+ previously issued to refresh the allocation. If (D)TLS is not used
+ or the (D)TLS handshake fails, and authentication also fails, then
+ the TURN client and server MUST fail and not proceed with TURN
+ mobility.
+
+ Security considerations described in [RFC5766] are also applicable to
+ this mechanism.
+
+6. References
+
+6.1. Normative References
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119,
+ DOI 10.17487/RFC2119, March 1997,
+ <http://www.rfc-editor.org/info/rfc2119>.
+
+ [RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig,
+ "Transport Layer Security (TLS) Session Resumption without
+ Server-Side State", RFC 5077, DOI 10.17487/RFC5077,
+ January 2008, <http://www.rfc-editor.org/info/rfc5077>.
+
+ [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment
+ (ICE): A Protocol for Network Address Translator (NAT)
+ Traversal for Offer/Answer Protocols", RFC 5245,
+ DOI 10.17487/RFC5245, April 2010,
+ <http://www.rfc-editor.org/info/rfc5245>.
+
+ [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing,
+ "Session Traversal Utilities for NAT (STUN)", RFC 5389,
+ DOI 10.17487/RFC5389, October 2008,
+ <http://www.rfc-editor.org/info/rfc5389>.
+
+ [RFC5766] Mahy, R., Matthews, P., and J. Rosenberg, "Traversal Using
+ Relays around NAT (TURN): Relay Extensions to Session
+ Traversal Utilities for NAT (STUN)", RFC 5766,
+ DOI 10.17487/RFC5766, April 2010,
+ <http://www.rfc-editor.org/info/rfc5766>.
+
+
+
+Reddy, et al. Standards Track [Page 10]
+
+RFC 8016 Mobility with TURN November 2016
+
+
+6.2. Informative References
+
+ [IANA-STUN]
+ IANA, "Session Traversal Utilities for NAT (STUN)
+ Parameters",
+ <http://www.iana.org/assignments/stun-parameters>.
+
+ [NOMBIS] Uberti, J. and J. Lennox, "Improvements to ICE Candidate
+ Nomination", Work in Progress,
+ draft-uberti-mmusic-nombis-00, March 2015.
+
+ [RFC7635] Reddy, T., Patil, P., Ravindranath, R., and J. Uberti,
+ "Session Traversal Utilities for NAT (STUN) Extension for
+ Third-Party Authorization", RFC 7635,
+ DOI 10.17487/RFC7635, August 2015,
+ <http://www.rfc-editor.org/info/rfc7635>.
+
+ [TRICKLE-ICE]
+ Ivov, E., Rescorla, E., Uberti, J., and P. Saint-Andre,
+ "Trickle ICE: Incremental Provisioning of Candidates for
+ the Interactive Connectivity Establishment (ICE)
+ Protocol", Work in Progress, draft-ietf-ice-trickle-04,
+ September 2016.
+
+ [TRICKLE-SIP]
+ Ivov, E., Stach, T., Marocco, E., and C. Holmberg, "A
+ Session Initiation Protocol (SIP) usage for Trickle ICE",
+ Work in Progress, draft-ietf-mmusic-trickle-ice-sip-06,
+ October 2016.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Reddy, et al. Standards Track [Page 11]
+
+RFC 8016 Mobility with TURN November 2016
+
+
+Appendix A. Example of Ticket Construction
+
+ The TURN server uses two different keys: one 128-bit key for Advance
+ Encryption Standard (AES) in Cipher Block Chaining (CBC) mode
+ (AES_128_CBC) and a 256-bit key for HMAC-SHA-256-128 for integrity
+ protection. The ticket can be structured as follows:
+
+ struct {
+ opaque key_name[16];
+ opaque iv[16];
+ opaque encrypted_state<0..2^16-1>;
+ opaque mac[16];
+ } ticket;
+
+ Figure 2: Ticket Format
+
+ Here, key_name serves to identify a particular set of keys used to
+ protect the ticket. It enables the TURN server to easily recognize
+ tickets it has issued. The key_name should be randomly generated to
+ avoid collisions between servers. One possibility is to generate new
+ random keys and key_name every time the server is started.
+
+ The TURN state information (which is either self-contained or a
+ handle) in encrypted_state is encrypted using 128-bit AES in CBC mode
+ with the given Initialization Vector (IV). The Message
+ Authentication Code (MAC) is calculated using HMAC-SHA-256-128 over
+ key_name (16 octets) and IV (16 octets), followed by the length of
+ the encrypted_state field (2 octets) and its contents (variable
+ length).
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Reddy, et al. Standards Track [Page 12]
+
+RFC 8016 Mobility with TURN November 2016
+
+
+Acknowledgements
+
+ Thanks to Alfred Heggestad, Lishitao, Sujing Zhou, Martin Thomson,
+ Emil Ivov, Oleg Moskalenko, Dave Waltermire, Pete Resnick, Antoni
+ Przygienda, Alissa Cooper, Ben Campbell, Suresh Krishnan, Mirja
+ Kuehlewind, Jonathan Lennox, and Brandon Williams for review and
+ comments.
+
+Authors' Addresses
+
+ Tirumaleswar Reddy
+ Cisco Systems, Inc.
+ Cessna Business Park, Varthur Hobli
+ Sarjapur Marathalli Outer Ring Road
+ Bangalore, Karnataka 560103
+ India
+
+ Email: tireddy@cisco.com
+
+
+ Dan Wing
+
+ Email: dwing-ietf@fuggles.com
+
+
+ Prashanth Patil
+ Cisco Systems, Inc.
+ Bangalore
+ India
+
+ Email: praspati@cisco.com
+
+
+ Paal-Erik Martinsen
+ Cisco Systems, Inc.
+ Philip Pedersens vei 22
+ Lysaker, Akershus 1325
+ Norway
+
+ Email: palmarti@cisco.com
+
+
+
+
+
+
+
+
+
+
+
+Reddy, et al. Standards Track [Page 13]
+