One document matched: draft-williams-tram-ufrag-permission-00.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">
<!ENTITY rfc6062 SYSTEM
"http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6062.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" docName="draft-williams-tram-ufrag-permission-00">
<front>
<title abbrev="Ufrag Permission for TURN">Ufrag Permissions
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>150 Broadway</street>
<city>Cambridge</city>
<region>MA</region>
<code>02142</code>
<country>USA</country>
</postal>
<email>brandon.williams@akamai.com</email>
</address>
</author>
<author fullname="Justin Uberti" initials="J." surname="Uberti">
<organization>Google</organization>
<address>
<postal>
<street>747 6th Ave S</street>
<city>Kirkland</city>
<region>WA</region>
<code>98033</code>
<country>USA</country>
</postal>
<email>justin@uberti.name</email>
</address>
</author>
<date year="2015" />
<abstract>
<t>When using a TURN relay, ICE connectivity checks require an explicit
permission or channel binding to be established for each peer address
to be checked. This requires the answerer to send its candidate
addresses to the offerer via the rendezvous server, which can impose a
latency penalty when the rendezvous server is centrally located. This
document defines a new type of TURN permission that will allow any ICE
connectivity check message that contains the offerer's ufrag value to
be accepted on a relay address for delivery over the associated TURN
tunnel.</t>
</abstract>
</front>
<middle>
<section anchor="intro" title="Introduction">
<t>Interactive Connectivity Establishment (ICE) <xref target="RFC5245"/>
provides a connectivity checking mechanism that peers can use to
determine how to communicate directly with each other (e.g. which
network layer protocol to use, which network address and transport
port to use, etc.). The peers gather their sets of candidate addresses
and exchange them via a rendezvous server using an offer/answer
protocol. After gathering the addresses, the peers then send
connectivity checks between address pairs to find a suitable
local/remote address pair to use for communication.</t>
<figure>
<preamble>Successful direct connectivity checks between the peers is
the simplest scenario.</preamble>
<artwork><![CDATA[
+------------+
| |
+--------------------> rendezvous +---------------------+
| | server | 2 |
| | | |
| +------------+ |
| |
| |
| |
| |
| 1 |
| |
+-----+------+ +------v-----+
| | 3 | |
| offerer <-----------------------------------------+ answerer |
| | | |
+------------+ +------------+
]]></artwork>
<postamble>The offerer sends an offer with its candidate addresses to
the rendezvous server (1), the rendezvous server forwards the offer
to the answerer (2), and the answerer is able to send a connectivity
check directly to the offerer (3) at the same time that it sends its
answer back to the offerer via the rendezvous server.</postamble>
</figure>
<figure>
<preamble>Successful connectivity checks for a relayed candidate with
Traversal Using Relays around NAT (TURN) <xref target="RFC5766"/> is
more complicated and time consuming, partially due to the
requirement for the local peer to explicitly notify the relay server
about every permitted remote address.</preamble>
<artwork><![CDATA[
+------------+
| | 2
+--------------------> rendezvous +---------------------+
|--------------------+ server <---------------------|
|| 4 | | ||
|| +------------+ ||
|| ||
|| ||
|| ||
|| ||
|| ||
1 || 3 ||
+------v-----+ +------------+ +------v-----+
| | 5 | | | |
| offerer +-------------> relay | | answerer |
| +-------------> +--------------> |
+------------+ 6 +------------+ 7 +------------+
]]></artwork>
<postamble>In this case, the offerer first issues an allocation
request to the relay server (not pictured) before sending an offer
that includes the assigned relay address to the rendezvous server
(1), which forwards the offer to the answerer (2). If the answerer
sends a connectivity check to the relay address immediately, the
relay will reject the message because there is no permission
established for the answerer's address yet. Instead, the answerer
must send its answer along with its candidate list to the rendezvous
server (3), which relays the answer to the offerer (4). Only now can
the offerer send a permission request to the relay (5) and then send
a connectivity check message to the relay (6) to be forwarded to the
answerer (7). Since the answer must be delivered before the
necessary TURN permissions can be established, successful
connectivity checks via the offerer's relay require an extra half
round trip time via the rendezvous server as compared to direct
host-to-host connectivity checks. This could be a significant
penalty in the common case of a remotely located rendezvous
server.</postamble>
</figure>
<t>The latency penalty for the relay use case could be mitigated by
permitting all ICE connectivity check messages to be delivered by the
relay, regardless of whether there is an active permission for the
sender. However, doing so would mean that use of the relay opens up
the client to potential attacks from anywhere on the Internet. TURN
permissions limit the risk by requiring the attacker to first discover
an address associated with an active permission. This may be trivial
to accomplish for an attacker who is on-path between the answerer and
the relay, but would be more difficult for an off-path attacker.</t>
<t>When ICE is in use, the offer and answer messages each contain an
ice-ufrag value, which is used in connectivity check messages as part
of the USERNAME for Session Traversal Utilities for NAT (STUN)
<xref target="RFC5389"/>. This document describes a new TURN
permission type that allows any ICE connectivity check message to be
relayed to TURN client if it has the expected remote ufrag (RFRAG)
value in the STUN USERNAME attribute. This mechanism allows ICE
connectivity checks to the offerer's relayed candidate to succeed
without having to wait for the answer to arrive at the offerer, while
at the same time continuing to require an attacker to learn some
information about an active permission in order to construct packets
that will be accepted by the relay for delivery to the client.</t>
</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="usage" title="Ufrag Permission Usage">
<t>To allow successful connectivity checks from the answerer, the
offerer registers a new type of permission, known as a ufrag
permission, with the relay server. Instead of using an
XOR-PEER-ADDRESS attribute to identify the remote peer, a ufrag
permission specifies the offerer's ufrag as the value for a
LOCAL-UFRAG attribute. A ufrag permission allows any ICE connectivity
check from a remote peer to be accepted by the relay if the RFRAG in
that message matches the ufrag specified for the permission. Note that
the LOCAL-UFRAG attribute is only allowed for TURN permission
requests. ChannelBind requests cannot make use of this type of
permission.</t>
<figure>
<preamble>Message flow for successful connectivity checks using ufrag
permissions looks fairly similar to the direct connectivity case
where timing of the first successful check is concerned.</preamble>
<artwork><![CDATA[
+------------+
| | 2
+--------------------> rendezvous +---------------------+
| | server | |
| | | |
| +------------+ |
| |
| |
| |
| |
| |
1 | |
+-----+------+ 1' +------------+ +------v-----+
| +-------------> | | |
| offerer | | relay | | answerer |
| <-------------+ <--------------+ |
+------------+ 4 +------------+ 3 +------------+
]]></artwork>
<postamble>The offerer first establishes a TURN allocation with the
relay (not pictured) to learn its relay candidate(s). At the point
when the offerer sends the offer to the rendezvous server (1), it
also sends a ufrag permission request to the relay (1'). The
rendezvous server forwards the offer to the answerer (2), at which
point the answerer can immediately send ICE connectivity checks (3)
that can be accepted by the relay and forwarded to the offerer (4).
Provided that the relay is fairly close to the offerer or at least
in-path between the offerer and the answerer, the primary difference
in latency between direct and relay connectivity checks is the time
required for candidate gathering (i.e. the allocation request).
</postamble>
</figure>
<section anchor="forming_perm" title="Forming a CreatePermission Request">
<t>A ufrag permission request is formed in the same general way as a
permission associated with an IP address, with the only exception
being that it contains a LOCAL-UFRAG attribute to provide the ufrag
value. As with any other CreatePermission request, multiple
permissions may be established using a single CreatePermission
request, meaning that a combination of one or more XOR-PEER-ADDRESS
attributes and one or more LOCAL-UFRAG attributes may be present in
a single request, with each resulting in a separate permission.</t>
<t>The LOCAL-UFRAG attribute is an understanding required attribute
with the type TBD, and it contains a single value, which is the
sender's ufrag value. This is allowed to be from 4 to 256 bytes in
length.</t>
<t>NOTE: The authors considered two alternatives: providing the ufrag
in either an XOR-PEER-ADDRESS or a USERNAME attribute. In both
cases, it this change would modify the semantics for the attribute
enough that it seemed better to defined a new attribute type.</t>
</section>
<section title="Processing a CreatePermission Request">
<t>When the server receives a CreatePermission request, it processes
it as per <xref target="RFC5766" />. The rest of this section
describes processing for cases where the request contains a
LOCAL-UFRAG attribute.</t>
<t>If the server understands but does not support ufrag addresses, it
rejects the request with a 403 (Forbidden) error.</t>
<t>If the request is valid, then the server installs or refreshes a
permission for the ufrag contained in the LOCAL-UFRAG attribute. The
server then responds with a CreatePermission success response.</t>
<t>NOTE: Careful consideration of the ufrag permission's lifetime is
required. It needs to be long enough to be useful for its intended
purpose but short enough to limit security exposure. A future
revision of the draft will cover this in more detail.</t>
</section>
<section title="Server Backward Compatibility">
<t>A server that does not recognize the LOCAL-UFRAG attribute will
reject the request and send a 420 (Unknown Attribute) error response
and otherwise ignore the request.</t>
<t>If the request sent by the client contained IP address
XOR-PEER-ADDRESS attributes in addition to a LOCAL-UFRAG attribute,
the client MAY resend the request without the LOCAL-UFRAG attribute
in order to retry registration of the IP address permissions.</t>
</section>
<section title="Processing a ChannelBind Request">
<t>A ChannelBind request received on the server MUST be considered
invalid if it contains a LOCAL-UFRAG attribute. The server MUST
reject such a request with a 403 (Forbidden) error.</t>
</section>
<section title="Processing a Message on the Relay Transport Address">
<t>When a message is received on the relay transport address, the
server first checks whether the allocation has a matching IP/IPv6
permission. If it does not have a matching IP/IPv6 permission but it
does have one or more ufrag permissions, the server examines the
message to determine whether it is an ICE connectivity check
message, meaning: it is a STUN Binding request that contains all of
the required attributes: FINGERPRINT, PRIORTY, ICE-CONTROLLED or
ICE-CONTROLLING, USERNAME, and MESSAGE-INTEGRITY. If the message is
not a structurally valid ICE connectivity check, the server MUST
discard the message if there is no IP/IPv6 permission that
applies.</t>
<t>If the message is an ICE connectivity check with no matching
IP/IPv6 permission, the server then parses the value of the USERNAME
attribute to extract the RFRAG value, which is the second
colon-separated field. If a ufrag permission exists for the RFRAG
value, the relay server generates a Data indication for the message.
The Data indication is then sent to the TURN client.</t>
<t>NOTE: TURN-TCP <xref target="RFC6062" /> should be discussed in
this document if/when it moves forward.</t>
</section>
<section title="Processing a Data Indication">
<t>When the client receives a structurally valid Data indication, the
client first checks whether the XOR-PEER-ADDRESS attribute value
contains an IP address with which the client believes there is an
active permission. If there is no such permission and the message is
not a structurally valid ICE connectivity check, the client SHOULD
discard the message. If the message is a structurally valid ICE
connectivity check, the client parses, validates, and responds to
the message as per standard ICE behavior.</t>
</section>
</section>
<section anchor="ice" title="ICE Interactions">
<t>The following subjects have been identified that should be discussed
in greater detail:
<list style="symbols">
<t>Interaction with ice-lite.</t>
<t>Interactions with vanilla ice.</t>
<t>Interactions with trickle ice.</t>
</list>
In particular, this section should discuss setting IP address
permissions as a result of receiving a valid ICE connectivity
check and/or learning the true candidates via the answer.</t>
</section>
<section title="Security Considerations">
<t>The following subjects have been identified that must be discussed in
greater detail:
<list style="symbols">
<t>An open port could be used to provide an unauthorized
service. At this time, this is the primary security concern
identified by the authors and some suitable mitigations should be
discussed in this document.</t>
<t>A valid ICE connectivity check could be replayed by an attacker.
This risk is shared by existing address-based permissions and so
is not a significant concern for this draft.</t>
<t>An invalid ICE connectivity check using a snooped ufrag value
could be forwarded to the client. This risk is also shared by
existing address-based permissions and so is not a significant
concern for this draft.</t>
<t>Others?</t>
</list>
</t>
</section>
<section title="IANA Considerations">
<t>[Paragraphs below in braces should be removed by the RFC Editor upon
publication]</t>
<t>[The LOCAL-UFRAG attribute requires that IANA allocate a value in
the "STUN attributes Registry" from the comprehension-required range
(0x0000-0x7FFF), to be replaced for TBD throughout this document]</t>
<t>This document defines the LOCAL-UFRAG attribute, described in
<xref target="forming_perm" />. IANA has allocated the
comprehension-required codepoint TBD for this attribute.</t>
</section>
<section anchor="Acknowledgements" title="Acknowledgements">
<t>Thanks to T. Reddy for early review of this draft.</t>
</section>
</middle>
<back>
<references title="Normative References">
&rfc2119;
&rfc5245;
&rfc5389;
&rfc5766;
&rfc6062;
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 09:00:28 |