One document matched: draft-wing-mmusic-ice-mobility-00.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc category="std" docName="draft-wing-mmusic-ice-mobility-00"
ipr="trust200902">
<front>
<title abbrev="MICE">Mobility with ICE (MICE)</title>
<author fullname="Dan Wing" initials="D." surname="Wing">
<organization abbrev="Cisco">Cisco Systems, Inc.</organization>
<address>
<postal>
<street>170 West Tasman Drive</street>
<city>San Jose</city>
<region>California</region>
<code>95134</code>
<country>USA</country>
</postal>
<email>dwing@cisco.com</email>
</address>
</author>
<author fullname="Prashanth Patil" initials="P." surname="Patil">
<organization abbrev="Cisco">Cisco Systems, Inc.</organization>
<address>
<postal>
<street>Cessna Business Park, Varthur Hobli</street>
<street>Sarjapur Marthalli Outer Ring Road</street>
<city>Bangalore</city>
<region>Karnataka</region>
<code>560103</code>
<country>India</country>
</postal>
<email>praspati@cisco.com</email>
</address>
</author>
<author fullname="Tirumaleswar Reddy" initials="T." surname="Reddy">
<organization abbrev="Cisco">Cisco Systems, Inc.</organization>
<address>
<postal>
<street>Cessna Business Park, Varthur Hobli</street>
<street>Sarjapur Marathalli Outer Ring Road</street>
<city>Bangalore</city>
<region>Karnataka</region>
<code>560103</code>
<country>India</country>
</postal>
<email>tireddy@cisco.com</email>
</address>
</author>
<date/>
<workgroup>MMUSIC</workgroup>
<abstract>
<t>This specification describes how endpoint mobility can be achieved
using ICE. Two mechanisms are shown, one where both endpoints support
ICE and another where only one endpoint supports ICE.</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>When moving between networks, an endpoint has to change its IP
address. This change 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 by using tunnels (Mobile IP, Proxy
Mobile IP, LISP). Other techniques exist, which make the upper layer
protocol ambivalent to IP address changes (e.g., SCTP). The mechanisms
described in this document are in that last category.</t>
<!--
<t>[[add text describing ICE technique.]]</t>
-->
<t>To overcome NAT and Firewall traversal issues, hosts may choose to
use the services of a TURN server that acts as a relay to exchange
packets with other hosts <xref target="RFC5766"/>. Relaying is also used
for IPv6 privacy. Clients allocate an IP address and port on the TURN
server, called the relayed transport address, for a specific client IP
address and port. Both the client and the server remember the 5-tuple
used in the Allocate request and all subsequent transactions between the
client and the server use the same 5-tuple. When an IP address of a
client changes because of movement to a new network, the existing
allocation on the TURN server cannot be re-used and the client will have
to allocate a second relayed transport address by creating a second
allocation using a different 5-tuple. This will break connection between
the client and its peer. Communication between the client and its peer
can only continue when the new relayed transport address is signaled to
the peer.</t>
<t>This document proposes two mechanisms to achieve RTP mobility: a
mechanism where both endpoints support ICE, and a mechanism where only
one endpoint supports ICE. When both endpoints support ICE, ICE itself
can be used to provide mobility. When only one endpoint supports ICE, a
TURN server provides mobility. Both mobility techniques work across and
between network types (e.g., between 3G and wired Internet access), so
long as the client can still access the remote ICE peer or TURN
server.</t>
</section>
<section anchor="notation" title="Notational Conventions">
<t>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 <xref
target="RFC2119"/>.</t>
<t>This note uses terminology defined in <xref target="RFC5245"/>.</t>
</section>
<section title="Mobility using ICE">
<t>When both endpoints support ICE, ICE itself can provide mobility.</t>
<t>[[more text will be written here.]]</t>
</section>
<section title="Mobility using TURN">
<t>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.</t>
<t>When the client sends the initial Allocate request to the TURN
server, it will also include a new STUN attribute MOBILITY-REQUEST which
indicates that the client is a mobile node. The TURN server provisions a
ticket that is sent inside a 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. It also ensures that the allocation can only be
refreshed this way by the same client. 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. 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.</t>
<figure>
<artwork><![CDATA[
TURN TURN Peer
client server A
|-- Allocate request --------------->| |
| + MOBILITY-REQUEST | |
| | |
|<--------------- Allocate failure --| |
| (401 Unauthorized) | |
| | |
|-- Allocate request --------------->| |
| + MOBILITY-REQUEST | |
| | |
|<---------- Allocate success resp --| |
| + MOBILITY-TICKET | |
... ... ...
(changes IP address)
| | |
|-- Refresh request ---------------->| |
| + MOBILITY-TICKET | |
| | |
|<----------- Refresh success resp --| |
| + MOBILITY-TICKET | |
| | |
]]></artwork>
</figure>
<section title="Creating an Allocation">
<section title="Sending an Allocate Request">
<t>In addition to the process described in Section 6.1 of <xref
target="RFC5766"/>, the client includes the MOBILITY-REQUEST
attribute indicating that the client is a mobile node.</t>
</section>
<section title="Receiving an Allocate Request">
<t>In addition to the process described in Section 6.2 of <xref
target="RFC5766"/>, the server does the following:</t>
<t>If the MOBILITY-REQUEST attribute is included and the TURN
session mobility is forbidden by local policy, the server MUST
reject the request with a TBD (Mobility Forbidden) error. Following
the rules specified in <xref target="RFC5389"/>, if the server does
not understand the MOBILITY-REQUEST attribute, it generates an
Allocate error response, which includes an ERROR-CODE attribute with
420 (Unknown Attribute) response code. This response will contain an
UNKNOWN-ATTRIBUTE attribute listing the unknown MOBILITY-REQUEST
attribute.</t>
<t>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 stores it's session
state, such as 5-tuple and NONCE, into a 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.</t>
<t>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.</t>
</section>
<section title="Receiving an Allocate Success Response">
<t>In addition to the process described in Section 6.3 of <xref
target="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.</t>
</section>
<section title="Receiving an Allocate Error Response">
<t>If the client receives an Allocate error response with error code
TBD (Mobility Forbidden), the error is processed as follows:</t>
<t>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.</t>
<t>All other error responses must be handled as described in <xref
target="RFC5766"/>.</t>
</section>
</section>
<section title="Refreshing an Allocation">
<section title="Sending a Refresh Request">
<t>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 <xref
target="RFC5766"/>. 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.</t>
</section>
<section title="Receiving a Refresh Request">
<t>In addition to the process described in Section 7.2 of <xref
target="RFC5766"/>, the client does the following:</t>
<t>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 from the contents of the ticket.
If this 5-tuple obtained from the ticket does not identify an
existing allocation then the server MUST reject the request with an
error.</t>
<t>If the source IP address and port of the Refresh Request is
different from the stored 5-tuple allocation, the TURN server
proceeds with checks to see if NONCE in the Refresh request is the
same as the one provided in the ticket. The TURN server also uses
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.</t>
<t>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.</t>
</section>
<section title="Receiving a Refresh Response">
<t>In addition to the process described in Section 7.3 of <xref
target="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.</t>
</section>
</section>
<section title="New STUN Attributes">
<section title="MOBILITY-REQUEST">
<t>This attribute is used by the client to indicate to the TURN
server that it is a mobile node. This attribute has no value part
and thus the attribute length field is 0.</t>
</section>
<section title="MOBILITY-TICKET">
<t>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 is encrypted and identifies identifies session
state such as 5-tuple and NONCE. The value of MOBILITY-TICKET is a
variable-length value.</t>
</section>
</section>
<section title="New STUN Error Response Codes">
<t>This document defines the following new error response codes:</t>
<t>TBD (Mobility Forbidden): Mobility request was valid but cannot be
performed due to administrative or similar restrictions.</t>
</section>
</section>
<section title="IANA Considerations">
<t>This note requests of the IANA to add attributes MOBILITY-REQUEST and
MOBILITY-TICKET to the TURN attribute registry. The note also requires
reservation of a new error code for error Mobility Forbidden.</t>
</section>
<section title="Security Considerations">
<t>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.</t>
<t>Security considerations described in <xref target="RFC5766"/> are
also applicable to this mechanism.</t>
</section>
</middle>
<back>
<references title="Normative References">
<?rfc include="reference.RFC.2119"?>
<?rfc include="reference.RFC.5245"?>
<?rfc include='reference.RFC.5766'?>
<?rfc include='reference.RFC.5389'?>
</references>
<references title="Informative References">
<?rfc include='reference.RFC.2663'?>
<?rfc include='reference.RFC.5768'?>
<!---->
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 21:42:16 |