IETF-90 Proceedings

Introduction  |  Area, Working Goup & BoF Reports  |  Plenaries  |  Training  |  Internet Research Task Force

TURN Revised and Modernized (tram) (WG)

Minutes   |   Jabber Logs  |   Mailing List Archives

Additional information is available at tools.ietf.org/wg/tram

Chair(s):

Transport Area Area Director(s):

Assigned Area Director



Recordings:

Meeting Slides:

Blue Sheets:

Internet-Drafts:

Request for Comments:

Charter (as of 2014-02-21):

Traversal Using Relays around NAT (TURN) was published as RFC 5766 in
April 2010. Until recently the protocol had seen rather limited
deployment. This is largely because its primary use case is as one
of the NAT traversal methods of the Interactive Connectivity
Establishment (ICE) framework (RFC 5245), and ICE itself was slow
to achieve widespread adoption, as other mechanisms were already
being used by the VoIP industry. This situation has changed
drastically as ICE, and consequently TURN, are mandatory to implement
in WebRTC, a set of technologies developed at the IETF and W3C to
standardize Real Time Communication on the Web.

Together with the arrival of WebRTC, there is a renewed interest in
TURN and ICE, as evidenced by recent work updating the ICE framework
(still in progress), and standardizing the URIs used to access a STUN
(RFC 7064) or TURN (RFC 7065) server.

The goal of the TRAM Working Group is to consolidate the various
initiatives to update TURN and STUN to make them more suitable for
the WebRTC environment. The work will include the addition of DTLS
as an additional transport, authentication mechanisms, and extensions
to TURN and STUN. The Working Group will closely coordinate with the
appropriate Working Groups, including RTCWEB, MMUSIC, and HTTPBIS.

In developing upgrades to TURN, the group will consider the passive
monitoring risks introduced by the centralization of call traffic
through a TURN server. When such risks arise, they will recommend
appropriate mitigations. For example, a mechanism for directing traffic
to a TURN server other than one configured by the application could be
used to direct calls through a TURN server configured to do monitoring.
When such a mechanism is used, it is important that the endpoints to the
call apply end-to-end encryption and authentication to ensure that they
are protected from the TURN server.