Mobility with TURNCisco Systems, Inc.170 West Tasman DriveSan JoseCalifornia95134USAdwing@cisco.comCisco Systems, Inc.BangaloreIndiapraspati@cisco.comCisco Systems, Inc.Cessna Business Park, Varthur HobliSarjapur Marathalli Outer Ring RoadBangaloreKarnataka560103Indiatireddy@cisco.comCisco Systems, Inc.Philip Pedersens vei 22LysakerAkershus1325Norwaypalmarti@cisco.comTRAMIt 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 only the local
network elements are aware of the changed IP address but the remote peer
is unaware of the changed IP address.This draft provides such an IP address mobility solution using TURN.
This is achieved by allowing a client to retain an allocation on the
TURN server when the IP address of the client changes.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, LISP).
Other techniques exist, which make the change in IP address agnostic to
the upper layer protocol (e.g., SCTP). The mechanism described in this
document are in that last category.A TURN server 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 for a new allocation, create permissions for the remote peer,
create channels etc. In addition to notifying the remote peer of the
address change, and punching new pinholes through any NAT/FW that might
be on the path.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, that 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 STUN. When there is a
change in IP address, the client uses (D)TLS Session Resumption without
Server-Side State as described in to
resume secure communication with the TURN server, using the changed
client IP address.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 .This note uses terminology defined in ,
and the following additional terminology: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 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 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.In addition to the process described in Section 6.1 of , the client includes the MOBILITY-TICKET
attribute with length 0. This indicates the client is a mobile node
and wants a ticket.In addition to the process described in Section 6.2 of , the server does the following:If the MOBILITY-TICKET attribute is included, and has length
zero, and the TURN session mobility is forbidden by local policy,
the server MUST reject the request with the new Mobility Forbidden
error code. If the MOBILITY-TICKET attribute is included and has
non-zero length then the server MUST generate an error response with
an error code of 400 (Bad Request). Following the rules specified in
, if the server does not understand
the MOBILITY-TICKET attribute, it ignores the attribute.If the server can successfully process the request create an
allocation, the server replies with a success response that includes
a STUN MOBILITY-TICKET attribute. TURN server can store system
internal data into 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 Allocate success response.The ticket is opaque to the client, so the structure is not
subject to interoperability concerns, and implementations may
diverge from this format. TURN Allocation state information is
encrypted using 128-bit key for Advance Encryption Standard (AES)
and 256-bit key for HMAC-SHA-256 for integrity protection.In addition to the process described in Section 6.3 of , 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.If the client receives an Allocate error response with error code
TBD (Mobility Forbidden), the error is processed as follows:o TBD (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 MAY notify the user or operator and SHOULD NOT
retry the same request with this server until it believes the
problem has been fixed.All other error responses must be handled as described in .If a client wants to refresh an existing allocation and update
its time-to-expiry or delete an existing allocation, it will send a
Refresh Request as described in Section 7.1 of . If the client wants to retain the existing
allocation in case of IP change, it will include the MOBILITY-TICKET
attribute received in the Allocate Success response. If a Refresh
transaction was previously made, the MOBILITY-TICKET attribute
received in the Refresh Success response of the transaction must be
used.In addition to the process described in Section 7.2 of , the client does the following: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 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 the server
MUST reject the request with an 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 MESSAGE-INTEGRITY validation to identify the that it
is the same user which had previously created the TURN allocation.
If the above checks are not successful then 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 has moved to a new network and acquired a new IP address.
The source IP address of the request could either be the host
transport address or server-reflexive transport address. The server
then updates it's 5-tuple with the new client IP address and port.
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.In addition to the process described in Section 7.3 of , 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.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 MOBILITY-TICKET is encrypted and is of variable-length.This document defines the following new error response code: Mobility Forbidden: Mobility request was valid but cannot be
performed due to administrative or similar restrictions.IANA is requested to add the following attributes to the STUN attribute registry, MOBILITY-TICKET (0x802E, in the comprehension-optional range) and to add a new STUN error code "Mobility Forbidden" with the
value 405 to the STUN Error Codes
registry.[Note to RFC Editor: Please remove this section and reference to
prior to publication.]This section records the status of known implementations of the
protocol defined by this specification at the time of posting of this
Internet-Draft, and is based on a proposal described in . The description of implementations in this
section is intended to assist the IETF in its decision processes in
progressing drafts to RFCs. Please note that the listing of any
individual implementation here does not imply endorsement by the IETF.
Furthermore, no effort has been spent to verify the information
presented here that was supplied by IETF contributors. This is not
intended as, and must not be construed to be, a catalog of available
implementations or their features. Readers are advised to note that
other implementations may exist.According to , "this will allow
reviewers and working groups to assign due consideration to documents
that have the benefit of running code, which may serve as evidence of
valuable experimentation and feedback that have made the implemented
protocols more mature. It is up to the individual working groups to use
this information as they see fit".This is a public project, the full
list of authors and contributors here:
http://turnserver.open-sys.org/downloads/AUTHORSA mature open-source TURN server specs
implementation (RFC 5766, RFC 6062, RFC 6156, etc) designed for
high-performance applications, especially geared for WebRTC.http://code.google.com/p/rfc5766-turn-server/The Mobile ICE feature
implementation can be qualified as "production" - it is well
tested and fully implemented, but not widely used, yet..Fully implements MICE with TURN
protocol.BSD:
http://turnserver.open-sys.org/downloads/LICENSEMICE implementation is
somewhat challenging for a multi-threaded performance-oriented
application (because the mobile ticket information must be shared
between the threads) but it is doable.Oleg Moskalenko
<mom040267@gmail.com>.TURN server MUST use strong encryption and integrity protection for
the ticket to prevent an attacker from using a brute force mechanism to
obtain the ticket's contents or refreshing allocations.Security considerations described in
are also applicable to this mechanism.Thanks to Alfred Heggestad, Lishitao, Sujing Zhou, Martin Thomson,
Emil Ivov and Oleg Moskalenko for review and comments.IANA: STUN Attributes