Skip to main content

TURN Revised and Modernized
charter-ietf-tram-02

WG review announcement

WG Review Announcement

From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
Cc: tram WG <tram@ietf.org> 
Subject: WG Review: TURN Revised and Modernized (tram)

The TURN Revised and Modernized (tram) working group in the Transport
Area of the IETF is undergoing rechartering. The IESG has not made any
determination yet. The following draft charter was submitted, and is
provided for informational purposes only. Please send your comments to
the IESG mailing list (iesg at ietf.org) by 2015-10-12.

TURN Revised and Modernized (tram)
------------------------------------------------
Current Status: Active WG

Chairs:
  Gonzalo Camarillo <gonzalo.camarillo@ericsson.com>
  Simon Perreault <sperreault@jive.com>

Assigned Area Director:
  Spencer Dawkins <spencerdawkins.ietf@gmail.com>

Mailing list
  Address: tram@ietf.org
  To Subscribe: https://www.ietf.org/mailman/listinfo/tram
  Archive: https://mailarchive.ietf.org/arch/browse/tram/

Charter:

Traversal Using Relays around NAT (TURN) was published as RFC 5766 in 
April 2010. For a few years, 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 authentication mechanisms,
a path MTU discovery mechanism, an IP address mobility solution for
TURN, 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.

Milestones:


WG action announcement

WG Action Announcement

From: The IESG <iesg-secretary@ietf.org>
To: "IETF-Announce" <ietf-announce@ietf.org>
Cc: tram-chairs@ietf.org,
    tram@ietf.org,
    "The IESG" <iesg@ietf.org> 
Subject: WG Action: Rechartered TURN Revised and Modernized (tram)

The TURN Revised and Modernized (tram) working group in the Transport
Area of the IETF has been rechartered. For additional information please
contact the Area Directors or the WG Chairs.

TURN Revised and Modernized (tram)
------------------------------------------------
Current Status: Active WG

Chairs:
  Gonzalo Camarillo <gonzalo.camarillo@ericsson.com>
  Simon Perreault <sperreault@jive.com>

Assigned Area Director:
  Spencer Dawkins <spencerdawkins.ietf@gmail.com>

Mailing list
  Address: tram@ietf.org
  To Subscribe: https://www.ietf.org/mailman/listinfo/tram
  Archive: https://mailarchive.ietf.org/arch/browse/tram/

Charter:

Traversal Using Relays around NAT (TURN) was published as RFC 5766 in 
April 2010. For a few years, 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 
NAT traversal in a variety of environments, whether for realtime 
media establishment protocols such as the Offer-Answer Session 
Description Protocol (RFC 3264), XMPP (XEP-0176), RTSP
(draft-ietf-mmusic-rtsp-nat), and RTCWeb (draft-ietf-rtcweb-jsep), 
or for non-realtime protocols such as HIP (RFC 5770) and RELOAD 
(RFC 6940). The work will include authentication mechanisms,
a path MTU discovery mechanism, an IP address mobility solution for
TURN, and extensions to TURN and STUN.  The Working Group will closely 
coordinate with the appropriate Working Groups, including ICE, 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.

Milestones:
  Nov 2015 - Send new TURN server discovery mechanism for enterprises and
ISPs to IESG for publication as Proposed Standard
  Nov 2015 - Send path characteristic measurement mechanism to IESG for
publication as Proposed Standard
  Nov 2015 - Adopt TURN PMTUD draft
  Nov 2015 - Adopt TURN IP address mobility draft
  Jan 2016 - Send STUN-bis draft to IESG for publication as Proposed
Standard
  Jan 2016 - Send TURN-bis draft to IESG for publication as Proposed
Standard
  Mar 2016 - Send new authentication mechanism(s) to IESG for publication
as Proposed Standard
  Mar 2016 - Submit TURN PMTUD draft to IESG
  Jul 2016 - Submit TURN IP address mobility draft to IESG


Ballot announcement

Ballot Announcement

Technical Summary

   Relevant content can frequently be found in the abstract
   and/or introduction of the document.  If not, this may be 
   an indication that there are deficiencies in the abstract
   or introduction.

Working Group Summary

   Was there anything in the WG process that is worth noting?
   For example, was there controversy about particular points 
   or were there decisions where the consensus was
   particularly rough? 

Document Quality

   Are there existing implementations of the protocol?  Have a 
   significant number of vendors indicated their plan to
   implement the specification?  Are there any reviewers that
   merit special mention as having done a thorough review,
   e.g., one that resulted in important changes or a
   conclusion that the document had no substantive issues?  If
   there was a MIB Doctor, Media Type, or other Expert Review,
   what was its course (briefly)?  In the case of a Media Type
   Review, on what date was the request posted?

Personnel

   Who is the Document Shepherd for this document?  Who is the 
   Responsible Area Director?  If the document requires IANA
   experts(s), insert 'The IANA Expert(s) for the registries
   in this document are <TO BE ADDED BY THE AD>.'

RFC Editor Note

  (Insert RFC Editor Note here or remove section)

IRTF Note

  (Insert IRTF Note here or remove section)

IESG Note

  (Insert IESG Note here or remove section)

IANA Note

  (Insert IANA Note here or remove section)