One document matched: draft-williams-peer-redirect-03.xml
<?xml version="1.0"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY rfc2119 SYSTEM
"http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY rfc5245 SYSTEM
"http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5245.xml">
<!ENTITY rfc5389 SYSTEM
"http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5389.xml">
<!ENTITY rfc5766 SYSTEM
"http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5766.xml">
]>
<?rfc toc='yes'?>
<?rfc rfcprocack="yes" ?>
<?rfc symrefs="yes" ?>
<?rfc iprnotified="no" ?>
<?rfc strict="yes" ?>
<?rfc compact="yes" ?>
<?rfc subcompact="no" ?>
<?rfc sortrefs="yes" ?>
<?rfc colonspace='yes' ?>
<?rfc tocindent='yes' ?>
<rfc ipr="trust200902" category="std">
<front>
<title abbrev="Peer Redirect for TURN">Peer-specific Redirection for
Traversal Using Relays around NAT (TURN)</title>
<author initials="B." surname="Williams" fullname="Brandon Williams">
<organization abbrev="Akamai">Akamai, Inc.</organization>
<address>
<postal>
<street>8 Cambridge Center</street>
<city>Cambridge</city>
<region>MA</region>
<code>02142</code>
<country>USA</country>
</postal>
<email>brandon.williams@akamai.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 year="2014" />
<abstract>
<t>This specification describes a peer-specific redirection method that
allows the TURN server to redirect a client for the purpose of
improving communication with a specific peer without negatively
affecting communication with other peers.</t>
</abstract>
</front>
<middle>
<section anchor="intro" title="Introduction">
<t>A Traversal Using Relay around NAT (TURN) <xref target="RFC5766" />
service provider may provide multiple candidate TURN servers for use
by a host, but it might not be possible to determine which candidate
TURN server will provide the best performance until both peers have
been identified. This could be true for a variety of reasons,
including:
<list style="symbols">
<t>Using the selected relay for a specific peer results in a
sub-optimal end-to-end Internet path.</t>
<t>Load conditions on the selected relay have changed since the
allocation was established such that it cannot support the
new data flow.</t>
</list>
At the same time, the above conditions might apply to one peer but not
another, such that it would be best to selectively use the existing
relay allocation for peers that will receive reasonable performance
and redirect data flows for other peers to an alternate server. These
scenarios are discussed in greater detail below.</t>
<t>The Session Traversal Utilities for NAT (STUN) protocol
<xref target="RFC5389" /> defines an ALTERNATE-SERVER mechanism with
which a server can redirect a client to another server by replying to
a request message with an error response with error code 300 (Try
Alternate). The TURN protocol describes error code 300 as one of the
possible error codes for an Allocate error response.</t>
<t>This specification describes an additional use of the
ALTERNATE-SERVER STUN attribute for TURN that allows the TURN server
to redirect a client for the purpose of improving communication with a
specific peer without negatively affecting communication with other
peers. The client application indicates the nature of the desired
response, which allows the client to treat the alternate server
selection as either a requirement or a suggestion. This flexibility
gives the client the option to choose the best way for the Interactive
Connectivity Establishment (ICE) protocol <xref target="RFC5245" /> to
respond (e.g. discarding the existing relay candidate for
communication with this peer versus evaluating the two candidate
servers using ICE connectivity checks and selecting the best one).</t>
<section title="Redirection for Performance">
<t>Consider the following example:</t>
<figure>
<artwork>
Boston
Peer C
Chicago [PC]
Peer B /
TURN Relay A ----------[PB]-------------[TC]
San Francisco ----------/ TURN Relay C
[TA]----------/ New York
|
[PA]
Peer A
Los Angeles
</artwork>
</figure>
<t>When Peer B wishes to communicate with either Peer A or Peer C, it
performs a DNS lookup and discovers TURN Relay C, the nearest of the
candidate TURN servers. Peer B then sends a TURN Allocate request to
TURN Relay C to determine the reflexive and relay candidates to
offer. After the reflexive candidate has been chosen, Peer B sends a
ChannelBind request to TURN Relay C to establish a channel for
communication with the peer. If Peer C is the remote peer, the
existing allocation will perform reasonably well, but if Peer A is
the remote peer, the latency for relayed packets will be nearly
twice as long as if TURN Relay A had been selected as the relay
candidate. The problem is worse if Peer B wishes to communicate with
both Peer A and Peer C, since there is no single relay candidate
that would provide optimum performance for both peers.</t>
<t>If TURN Relay C and TURN Relay A are part of a common TURN service,
it would be possible for TURN Relay C to determine that TURN Relay A
will provide optimal service for communication between Peer B and
Peer A. This allows the TURN service to redirect just the data
channel between Peer A and Peer B to TURN relay A, thus providing
optimal performance for both relay channels.</t>
<t>The above example describes the problem in terms of physical
geography instead of network geography in order to help clarify the
discussion. However, readers should note that the problem of
selecting a relay server to achieve optimal end-to-end routing is
much more complicated than the above description suggests, requiring
a detailed real-time view of network connectivity characteristics
and the peering relationships between autonomous systems. A naive
approach based solely on the physical location of the hosts involved
is just as likely to produce negative results as positive ones.</t>
<t>That said, a relay service provider with a broadly distributed
system for actively monitoring network performance across the
relevant parts of the Internet could make use of the resulting data
set to select the optimal relay for each peer pair.</t>
</section>
<section title="Redirection for Load Balancing">
<t>At the point when a relay allocation is first established, it can
be difficult to determine how much aggregate concurrent load could
eventually be associated with that allocation. The initiating peer
could attempt to use that allocation for any number of peer-to-peer
data flows over an extended period of time, during which time load
conditions on the relay could change substantially, such that
quality of service for already established flows would degrade if
the relay were to accept additional flows.</t>
<t>Under these conditions, a TURN service provider with multiple relay
hosts and distributed capacity could improve service quality by
redirecting data flows to a different host that has more available
capacity. At the same time, it is desirable to avoid disrupting
established data flows by continuing to handle established flows on
the current relay and only redirecting new flows elsewhere.</t>
</section>
</section>
<section title="Terminology">
<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>
</section>
<section anchor="mechanism" title="Peer-specific Server Redirect Mechanism">
<t>This specification describes two new uses of the existing STUN
ALTERNATE-SERVER attribute. In the first case, the ALTERNATE-SERVER
attribute is included with either a CreatePermission error response or
a ChannelBind error response. In the second case, the ALTERNATE-SERVER
attribute is included with either a CreatePermission success response
or a ChannelBind success response.</t>
<t>This specification also defines two new comprehension-optional STUN
attributes: CHECK-ALTERNATE and XOR-OTHER-ADDRESS. The CHECK-ALTERNATE
attribute is used by the client to request that the server perform
peer-specific redirection. The XOR-OTHER-ADDRESS is used by the client
to provide an alternate peer address for location identification in
the event that the XOR-PEER-ADDRESS attribute in the CreatePermission
or ChannelBind request is not expected to reliably serve this
purpose.</t>
<section title="Attribute Usage">
<t>When sending a CreatePermission or a ChannelBind request, the
CHECK-ALTERNATE STUN attribute allows a TURN client to indicate
support for peer-specific server redirection. To maintain backward
compatibility with <xref target="RFC5766" /> compliant TURN servers
that do not support peer-specific redirection, this attribute is
defined as comprehension-optional, which allows a TURN server that
does not support peer-specific redirection to ignore the attribute.
To maintain backward compatibility with <xref target="RFC5766" />
compliant TURN clients that do not support peer-specific
redirection, a TURN server only sends the ALTERNATE-SERVER attribute
in CreatePermission and ChannelBind responses when the
CHECK-ALTERNATE STUN attribute was present in the request. This
prevents transmission of the ALTERNATE-SERVER attribute in cases
where the receiving client might not consider the usage
legitimate.</t>
<t>The CHECK-ALTERNATE STUN attribute's value indicates the expected
server response type: error or success. This capability to declare
the expected response type allows TURN client implementers greater
flexibility during session establishment. For example, a TURN client
implementer may wish to maintain the smallest number of permissions
possible during session establishment in order keep the internal
client implementation simple, in which case an error response would
be desirable. On the other hand, a TURN client implementer may wish
to optimize for faster session establishment by continuing to use a
sub-optimal allocation while setting up the new one, in which case a
success response would be desirable. This second case could be
achieved with an error response if the client were to send a second
request without the CHECK-ALTERNATE attribute, but such an approach
would require an extra RTT.</t>
<t>The XOR-OTHER-ADDRESS STUN attribute allows the TURN client to
provide an alternate peer address that can be used by the server to
identify the network geographic location of the peer when performing
the peer-specific redirection check. Use of this attribute is only
necessary if the XOR-PEER-ADDRESS already contained in the
CreatePermission or ChannelBind request does not adequately serve
this purpose, which should only be true when both peers require a
TURN relay for end-to-end data flow. In this case, the TURN
CreatePermission or ChannelBind request will provide the peer's TURN
relay address as the XOR-PEER-ADDRESS value. If the RTT between the
peer and its TURN relay server is very small, the TURN relay address
might still be an appropriate address to use for the peer-specific
redirection check. As the RTT grows, the TURN relay address will
become less suitable for this purpose. For this reason, it is
generally the case that the peer's public address (i.e. its host or
reflexive address) is a better indication of its network geographic
location than its TURN relay address.</t>
<t>Even in cases where both peers require a TURN relay, a typical ICE
protocol implementation will give higher candidate priority to the
peer's host and reflexive addresses, which means that the first
CreatePermission or ChannelBind request will provide the peer's
public address as the XOR-PEER-ADDRESS value and no
XOR-OTHER-ADDRESS attribute is necessary. However, although ICE
recommends this priority, it does not require it, and so the first
request may contain the peer's TURN relay address. With such an
implementation, the XOR-OTHER-ADDRESS attribute allows the client to
provide the peer's reflexive address in a request that populates the
XOR-PEER-ADDRESS attribute with the peer's relay address.</t>
</section>
<section anchor="sendreq" title="Sending a CreatePermission or ChannelBind Request">
<t>A client that supports peer-specific server redirection and desires
such redirection to be performed MUST include the CHECK-ALTERNATE
attribute in the first CreatePermission or ChannelBind request when
that request is expected to form a new permission or binding. A
client MUST NOT include the CHECK-ALTERNATE attribute in a
CreatePermission or ChannelBind request that is intended to extend
the lifetime of an existing permission or binding.</t>
<t>Peer-specific server redirection is only supported for requests
that include a single XOR-PEER-ADDRESS attribute. When forming a
CreatePermission request with multiple XOR-PEER-ADDRESS attributes,
the client MUST NOT include the CHECK-ALTERNATE attribute.</t>
<t>When the CreatePermission or ChannelBind request includes the
CHECK-ALTERNATE attribute, the client MAY also include an
XOR-OTHER-ADDRESS attribute with a value appropriate for the above
described purpose. The XOR-OTHER-ADDRESS attribute SHOULD NOT be
included in the request if its value will be identical to the
request's XOR-PEER-ADDRESS attribute.</t>
<section anchor="checkalt" title="The CHECK-ALTERNATE Attribute">
<t>When forming a CHECK-ALTERNATE attribute, the STUN Type is
TBD-CA. This type is in the comprehension-optional range, which
means that STUN agents can safely ignore the attribute if they do
not understand it.</t>
<t>The CHECK-ALTERNATE attribute takes a 1-byte Value, which means
that the Length is 1 and 3 bytes of padding are required after the
Value. The format of the Value is:</t>
<figure>
<artwork>
0
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|E| RFFU |
+-+-+-+-+-+-+-+-+
</artwork>
</figure>
<t>The Value contains a single 1-bit flag:
<list style="hanging">
<t hangText="E:">If 1, the server is requested to send a Try
Alternate (300) error response when redirection is expected.
If 0, the server is request to include an ALTERNATE-SERVER
attribute in the success response for the request.</t>
</list>
The other 7 bits of the attribute's value must be set to zero on
transmission and ignored on reception.</t>
</section>
<section anchor="otheraddr" title="The XOR-OTHER-ADDRESS attribute">
<t>When forming an XOR-OTHER-ADDRESS attribute, the STUN Type is
TBD-XOA. This type is in the comprehension-optional range, which
means that STUN agents can safely ignore the attribute if they do
not understand it.</t>
<t>The XOR-OTHER-ADDRESS value specifies an address and port
suitable for identification of the peer's network geographic
location. It is encoded in the same way as XOR-MAPPED-ADDRESS
<xref target="RFC5389" />.</t>
</section>
</section>
<section anchor="recvreq" title="Receiving a CreatePermission or ChannelBind Request">
<t>When a server receives a CreatePermission or ChannelBind request
that includes a CHECK-ALTERNATE attribute, it processes as per the
TURN specification <xref target="RFC5766" /> plus the specific rules
mentioned here.</t>
<t>The server checks the following:
<list style="symbols">
<t>If the CHECK-ALTERNATE attribute is not recognized, ignore the
attribute because its type indicates that it is
comprehension-optional. This should be the existing behavior.</t>
<t>If the message is a CreatePermission request with multiple
XOR-PEER-ADDRESS attributes, ignore the CHECK-ALTERNATE attribute
if present.</t>
<t>If peer-specific redirection is not supported by the server,
ignore the attribute.</t>
<t>If the associated permission or binding already exists, ignore
the attribute.</t>
</list>
If none of the above causes the attribute to be ignored and no other
cause for sending an error response has been found, the server
attempts to identify an alternate server that will provide better
performance for the session based on the criteria supported by the
TURN service (e.g. optimal data path and/or load balancing). When an
XOR-OTHER-ADDRESS attribute is found in the request message, the
server SHOULD use this address for peer location identification.
Otherwise, the server SHOULD use the address provided in the
XOR-PEER-ADDRESS attribute.</t>
<t>If no alternate server is identified, the server replies with a
success response that does not include an ALTERNATE-SERVER
attribute.</t>
<t>If an alternate server is identified and the client requested an
error response for redirection, the server rejects the request with
a 300 (Try Alternate) error. No new permission or binding is
generated on the server in this case.</t>
<t>If an alternate server is identified and the client did not request
an error response for redirection, the server creates the permission
or binding. The server then replies to the request with a success
response, including an ALTERNATE-SERVER attribute in the
message.</t>
</section>
<section anchor="recverror" title="Receiving a CreatePermission or ChannelBind Error Response">
<t>If the client receives a CreatePermission or ChannelBind error
response with error code 420 (Unknown Attribute) and CHECK-ALTERNATE
is listed in the UNKNOWN-ATTRIBUTE attribute of the message, the
client SHOULD retransmit the original request without the
CHECK-ALTERNATE attribute. This case is not expected due to the use
of a comprehension-optional attribute type.</t>
<t>If the client receives a CreatePermission or ChannelBind error
response with error code 300 (Try Alternate), the client SHOULD
attempt to form an allocation to the TURN server indicated in the
ALTERNATE-SERVER attribute.</t>
<t>If the alternate server responds to the Allocate request with a
success response, the client SHOULD attempt to form a new permission
or binding using the new allocation from the alternate server. The
CreatePermission or ChannelBind request to the alternate server MAY
include a CHECK-ALTERNATE attribute but SHOULD NOT request
redirection via an error response. This helps to avoid the
possibility of redirection loops.</t>
<t>If the alternate server responds to the Allocate request with an
error response, the client MAY resend the original CreatePermission
or ChannelBind request, either without the CHECK-ALTERNATE attribute
or with a CHECK-ALTERNATE attribute that does not request an error
response.</t>
<t>See <xref target="security" /> below for discussion of how the
client should respond when receiving a Try Alternate error response
that was not requested.</t>
</section>
<section anchor="recvsuccess" title="Receiving a CreatePermission or ChannelBind Success Response">
<t>If the client receives a CreatePermission or ChannelBind success
response, it proceeds with processing according to the TURN
specification <xref target="RFC5766" />. If the message does not
include an ALTERNATE-SERVER attribute, no additional processing is
required.</t>
<t>If the success response includes an ALTERNATE-SERVER attribute, the
client SHOULD attempt to form an allocation to the TURN server
indicated in the ALTERNATE-SERVER attribute.</t>
<t>If the alternate server responds to the Allocate request with a
success response, the client SHOULD attempt to form a new permission
or binding using the new allocation from the alternate server. The
CreatePermission or ChannelBind request to the alternate server
MAY include a CHECK-ALTERNATE attribute with either attribute
value. If this is done, care should be taken in the client
implementation to recognize and avoid redirection loops.</t>
<t>While waiting for the new allocation and permission or binding to
form via the indicated alternate server, the client SHOULD use the
original permission or binding from the request that included the
CHECK-ALTERNATE attribute. In this way, peer-specific redirection
without an error response can be considered a "hint" that allows the
client to establish an alternate path and test its quality before
switching to it.</t>
<t>See <xref target="security" /> below for discussion of how the
client should respond when receiving an ALTERNATE-SERVER attribute
that was not requested.</t>
</section>
</section>
<section anchor="security" title="Security Considerations">
<t>This section considers attacks that are possible in a TURN deployment
through the specified protocol extension, and discusses how they are
mitigated by mechanisms in the protocol or recommended practices in
the implementation.</t>
<t>The specified mechanism affects the use of TURN CreatePermission
request messages, ChannelBind request messages, and their respective
success and error response messages. Each of these TURN message types
requires the MESSAGE-INTEGRITY STUN attribute, which limits attacks
that attempt to make use of the specified mechanism to authenticated
clients and servers.</t>
<section title="CHECK-ALTERNATE Flood">
<t>A compromised TURN client could send a large number of
CreatePermission or ChannelBind request messages, which would drive
increased load on the TURN server. The CHECK-ALTERNATE attribute
does not make such an attack more likely, though it could make it
possible to increase the impact of such an attack due to the
additional load associated with determining whether an alternate
server should be used by the client. The TURN server MAY be
configured to ignore the CHECK-ALTERNATE attribute under some
conditions in order to limit the associated load. The conditions
under which it is appropriate for a TURN server to ignore the
CHECK-ALTERNATE attribute are implementation dependent.</t>
</section>
<section title="Unsolicited or Invalid ALTERNATE-SERVER">
<t>A compromised TURN server could send the "Try Alternate" error code
in response to a request message that did not contain the
CHECK-ALTERNATE attribute or where the value of the attribute did
not request an error response. For client connectivity, this is no
worse than any other error response code that could be sent. No
matter what the error response code may be, the client is unable to
relay data to the remote peer. The client MUST ignore the
ALTERNATE-SERVER attribute in error responses when the
CHECK-ALTERNATE attribute was not included in the associated
request. The client SHOULD ignore the ALTERNATE-SERVER attribute in
error responses when the CHECK-ALTERNATE attribute was included in
the associated request if the attribute value did not request an
error response. The client MAY discontinue use of the associated
TURN allocation when an unsolicited Try Alternate error is
received.</t>
<t>A compromised TURN server could send an ALTERNATE-SERVER attribute
in a success response message for a request message that did not
contain the CHECK-ALTERNATE attribute. The client MUST ignore the
ALTERNATE-SERVER attribute in success responses when the
CHECK-ALTERNATE attribute was not included in the associated request
message. The client SHOULD ignore the ALTERNATE-SERVER attribute in
success responses when the CHECK-ALTERNATE attribute was included in
the associated request if the attribute value requested an error
response. The client MAY discontinue use of the associated TURN
allocation when an unsolicited ALTERNATE-SERVER attribute is
received.</t>
<t>A compromised TURN server could send an invalid ALTERNATE-SERVER
attribute value in either an error or a success response message,
where the value refers to an unaffiliated TURN server to which the
sending TURN server is not allowed to redirect traffic. Such an
attack is already allowed by the use of Try Alternate errors in
response to Allocate request messages. Use of the ALTERNATE-SERVER
attribute in the context of peer-specific redirection does not make
such an attack more likely, though it could make it possible to
increase the scale of such an attack by allowing multiple
ALTERNATE-SERVER attributes to each client, one per requested
permission or binding. A client SHOULD ignore all future
ALTERNATE-SERVER attributes received from the TURN server after an
authentication failure with any server identified via an
ALTERNATE-SERVER attribute. A client MAY discontinue use of the
associated TURN allocation after an authentication failure with any
server identified via an ALTERNATE-SERVER attribute.</t>
</section>
</section>
<section anchor="iana" title="IANA Considerations">
<t>[Paragraphs below in braces should be removed by the RFC Editor upon
publication]</t>
<t>[The CHECK-ALTERNATE attribute requires that IANA allocate a value in
the "STUN attributes Registry" from the comprehension-optional range
(0x8000-0xFFFF), to be replaced for TBD-CA throughout this
document]</t>
<t>This document defines the CHECK-ALTERNATE STUN attribute, described
in <xref target="checkalt" />. IANA has allocated the
comprehension-optional codepoint TBD-CA for this attribute.</t>
<t>[The XOR-OTHER-ADDRESS attribute requires that IANA allocate a value
in the "STUN attributes Registry" from the comprehension-optional
range (0x8000-0xFFFF), to be replaced for TBD-XOA throughout this
document]</t>
<t>This document defines the XOR-OTHER-ADDRESS STUN attribute, described
in <xref target="otheraddr" />. IANA has allocated the
comprehension-optional codepoint TBD-XOA for this attribute.</t>
</section>
</middle>
<back>
<references title="Normative References">
&rfc2119;
</references>
<references title="Informative References">
&rfc5245;
&rfc5389;
&rfc5766;
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 08:53:41 |