Internet DRAFT - draft-williams-tram-ufrag-permission
draft-williams-tram-ufrag-permission
Network Working Group B. Williams
Internet-Draft Akamai
Intended status: Standards Track J. Uberti
Expires: April 16, 2016 Google
October 14, 2015
Ufrag Permissions for Traversal Using Relays around NAT (TURN)
draft-williams-tram-ufrag-permission-00
Abstract
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.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 16, 2016.
Copyright Notice
Copyright (c) 2015 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
Williams & Uberti Expires April 16, 2016 [Page 1]
Internet-Draft Ufrag Permission for TURN October 2015
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 . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Ufrag Permission Usage . . . . . . . . . . . . . . . . . . . 5
3.1. Forming a CreatePermission Request . . . . . . . . . . . 6
3.2. Processing a CreatePermission Request . . . . . . . . . . 6
3.3. Server Backward Compatibility . . . . . . . . . . . . . . 6
3.4. Processing a ChannelBind Request . . . . . . . . . . . . 7
3.5. Processing a Message on the Relay Transport Address . . . 7
3.6. Processing a Data Indication . . . . . . . . . . . . . . 7
4. ICE Interactions . . . . . . . . . . . . . . . . . . . . . . 7
5. Security Considerations . . . . . . . . . . . . . . . . . . . 8
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8
8. Normative References . . . . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9
1. Introduction
Interactive Connectivity Establishment (ICE) [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 adress
pair to use for communication.
Successful direct connectivity checks between the peers is the
simplest scenario.
Williams & Uberti Expires April 16, 2016 [Page 2]
Internet-Draft Ufrag Permission for TURN October 2015
+------------+
| |
+--------------------> rendezvous +---------------------+
| | server | 2 |
| | | |
| +------------+ |
| |
| |
| |
| |
| 1 |
| |
+-----+------+ +------v-----+
| | 3 | |
| offerer <-----------------------------------------+ answerer |
| | | |
+------------+ +------------+
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.
Successful connectivity checks for a relayed candidate with Traversal
Using Relays around NAT (TURN) [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.
+------------+
| | 2
+--------------------> rendezvous +---------------------+
|--------------------+ server <---------------------|
|| 4 | | ||
|| +------------+ ||
|| ||
|| ||
|| ||
|| ||
|| ||
1 || 3 ||
+------v-----+ +------------+ +------v-----+
| | 5 | | | |
| offerer +-------------> relay | | answerer |
| +-------------> +--------------> |
+------------+ 6 +------------+ 7 +------------+
Williams & Uberti Expires April 16, 2016 [Page 3]
Internet-Draft Ufrag Permission for TURN October 2015
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.
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.
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)
[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 dor delivery to the client.
2. Terminology
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].
Williams & Uberti Expires April 16, 2016 [Page 4]
Internet-Draft Ufrag Permission for TURN October 2015
3. Ufrag Permission Usage
To allow successful connetivity 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 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.
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.
+------------+
| | 2
+--------------------> rendezvous +---------------------+
| | server | |
| | | |
| +------------+ |
| |
| |
| |
| |
| |
1 | |
+-----+------+ 1' +------------+ +------v-----+
| +-------------> | | |
| offerer | | relay | | answerer |
| <-------------+ <--------------+ |
+------------+ 4 +------------+ 3 +------------+
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 inline 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).
Williams & Uberti Expires April 16, 2016 [Page 5]
Internet-Draft Ufrag Permission for TURN October 2015
3.1. Forming a CreatePermission Request
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.
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.
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.
3.2. Processing a CreatePermission Request
When the server receives a CreatePermission request, it processes it
as per [RFC5766]. The rest of this section describes processing for
cases where the request contains a LOCAL-UFRAG attribute.
If the server understands but does not support ufrag addresses, it
rejects the request with a 403 (Forbidden) error.
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.
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.
3.3. Server Backward Compatibility
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.
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.
Williams & Uberti Expires April 16, 2016 [Page 6]
Internet-Draft Ufrag Permission for TURN October 2015
3.4. Processing a ChannelBind Request
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.
3.5. Processing a Message on the Relay Transport Address
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 atrributes: 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.
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.
NOTE: TURN-TCP [RFC6062] should be discussed in this document if/when
it moves forward.
3.6. Processing a Data Indication
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.
4. ICE Interactions
The following subjects have been identified that should be discussed
in greater detail:
o Interaction with ice-lite.
o Interactions with vanilla ice.
Williams & Uberti Expires April 16, 2016 [Page 7]
Internet-Draft Ufrag Permission for TURN October 2015
o Interactions with trickle ice.
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.
5. Security Considerations
The following subjects have been identified that must be discussed in
greater detail:
o 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.
o 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.
o 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.
o Others?
6. IANA Considerations
[Paragraphs below in braces should be removed by the RFC Editor upon
publication]
[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]
This document defines the LOCAL-UFRAG attribute, described in
Section 3.1. IANA has allocated the comprehension-required codepoint
TBD for this attribute.
7. Acknowledgements
Thanks to T. Reddy for early review of this draft.
8. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/
Williams & Uberti Expires April 16, 2016 [Page 8]
Internet-Draft Ufrag Permission for TURN October 2015
RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.
[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>.
[RFC6062] Perreault, S., Ed. and J. Rosenberg, "Traversal Using
Relays around NAT (TURN) Extensions for TCP Allocations",
RFC 6062, DOI 10.17487/RFC6062, November 2010,
<http://www.rfc-editor.org/info/rfc6062>.
Authors' Addresses
Brandon Williams
Akamai, Inc.
150 Broadway
Cambridge, MA 02142
USA
Email: brandon.williams@akamai.com
Justin Uberti
Google
747 6th Ave S
Kirkland, WA 98033
USA
Email: justin@uberti.name
Williams & Uberti Expires April 16, 2016 [Page 9]
