WG Action: Formed TURN Revised and Modernized (tram)

The IESG <iesg-secretary@ietf.org> Fri, 21 February 2014 17:19 UTC

Return-Path: <iesg-secretary@ietf.org>
X-Original-To: ietf-announce@ietfa.amsl.com
Delivered-To: ietf-announce@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com []) by ietfa.amsl.com (Postfix) with ESMTP id 6DAE71A02D0; Fri, 21 Feb 2014 09:19:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id fuwC5I7HZTnr; Fri, 21 Feb 2014 09:19:42 -0800 (PST)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id DA13E1A04C6; Fri, 21 Feb 2014 09:19:40 -0800 (PST)
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
Subject: WG Action: Formed TURN Revised and Modernized (tram)
X-Test-IDTracker: no
X-IETF-IDTracker: 5.0.1
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20140221171940.2127.98041.idtracker@ietfa.amsl.com>
Date: Fri, 21 Feb 2014 09:19:40 -0800
Archived-At: http://mailarchive.ietf.org/arch/msg/ietf-announce/bh2F5vYRJsZ9je4vvgA3kDJ7t9w
Cc: tram WG <tram@ietf.org>
X-BeenThere: ietf-announce@ietf.org
X-Mailman-Version: 2.1.15
Reply-To: ietf@ietf.org
List-Id: "IETF announcement list. No discussions." <ietf-announce.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf-announce>, <mailto:ietf-announce-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf-announce/>
List-Post: <mailto:ietf-announce@ietf.org>
List-Help: <mailto:ietf-announce-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf-announce>, <mailto:ietf-announce-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 21 Feb 2014 17:19:44 -0000

A new IETF working group has been formed in the Transport Area. For
additional information please contact the Area Directors or the WG

TURN Revised and Modernized (tram)
Current Status: Proposed WG

  Gonzalo Camarillo <gonzalo.camarillo@ericsson.com>
  Simon Perreault <simon.perreault@viagenie.ca>

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

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


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.

  Jul 2014 - Send draft adding DTLS as a transport for STUN/TURN to IESG 
  Jul 2014 -  Send analysis of problems with current TURN authentication
  Sep 2014 - Send new proposed standard TURN server discovery mechanism
for enterprises and ISPs to IESG
  Nov 2014 - Send new proposed standard TURN authentication mechanism(s)
  Feb 2015 - Send STUN-bis draft to IESG
  Feb 2015 - Send TURN-bis draft to IESG