[rtcweb] Turn Revised And Modernized (tram)

Simon Perreault <simon.perreault@viagenie.ca> Fri, 15 November 2013 20:27 UTC

Return-Path: <simon.perreault@viagenie.ca>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 50C6711E8128; Fri, 15 Nov 2013 12:27:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599]
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id vkVm7tx7-ICS; Fri, 15 Nov 2013 12:27:11 -0800 (PST)
Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 50DDE11E80E0; Fri, 15 Nov 2013 12:27:08 -0800 (PST)
Received: from porto.nomis80.org (ringo.viagenie.ca []) by jazz.viagenie.ca (Postfix) with ESMTPSA id 8A20B403CB; Fri, 15 Nov 2013 15:27:07 -0500 (EST)
Message-ID: <5286839B.8050305@viagenie.ca>
Date: Fri, 15 Nov 2013 15:27:07 -0500
From: Simon Perreault <simon.perreault@viagenie.ca>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0
MIME-Version: 1.0
To: "rtcweb@ietf.org" <rtcweb@ietf.org>, pntaw@ietf.org, "behave@ietf.org" <behave@ietf.org>, mmusic@ietf.org
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: tram@ietf.org
Subject: [rtcweb] Turn Revised And Modernized (tram)
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: tram@ietf.org
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtcweb>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 15 Nov 2013 20:27:12 -0000


A few of us have been working on a proposal for a new working group that 
would focus on enhancements to STUN and TURN. The proposed name is TRAM 
(Turn Revised And Modernized) and discussion is happening in 
Subscribe link: <https://www.ietf.org/mailman/listinfo/tram>

Here is the charter we have been working on. If you would like to 
comment and/or get involved, please do so on the TRAM mailing list.

Simon (and many others!)

> Turn Revised And Modernized (tram)
> ----------------------------------
> Traversal Using Relays around NAT (TURN) was published as RFC 5766 in April
> 2010.  Until recently the protocol had only a rather limited deployment.  This
> is primarily because its primary use case is as one of the NAT traversal
> methods of the Interactive Connectivity Establishment (ICE) framework (RFC
> 5245).  This inherent dependency on ICE combined with the fact that ICE itself
> was slow to achieve widespread adoption because other alternative mechanisms
> were historically used by the VoIP industry were the causes of the initial
> lack of interest.  This situation has changed drastically as ICE, and
> consequently TURN, are mandatory to implement in WebRTC, which is a set of
> technologies developed at the IETF and W3C aiming to enable Real Time
> Communication on the Web.
> Because of the ubiquity of the Web and of the new opportunities created by the
> arrival of WebRTC, there is a renewed interest in TURN and ICE, as evidenced by
> the recent work updating the ICE framework, as well as standardizing the URIs
> used to access a STUN [RFC7064] or TURN [RFC7065] server.
> The goal of the TRAM Working Group is to consolidate the various initiatives
> to update TURN and STUN, including the definition of new transport and
> authentication mechanisms that make STUN and TURN more suitable for the WebRTC
> environment.  The Working Group will closely coordinate with the appropriate
> Working Groups, including RTCWEB, MMUSIC, and HTTPBIS.
> The current list of deliverable is:
> - DTLS transport for TURN
>   Candidate draft: draft-petithuguenin-tram-turn-dtls
>   TURN defines three transports: UDP, TCP, and TLS. A straightforward extension
>   of this set is DTLS, enabling secure datagram-oriented transport.
> - New authentication mechanism for TURN
>   Problem analysis: draft-reddy-behave-turn-auth
>   Candidate draft: draft-uberti-behave-turn-rest, OAuth has also been suggested
>   The current authentication mechanism for TURN, which is reused from STUN, has
>   been designed with a SIP account database in mind. The new RTCWEB usages,
>   which are mostly based on web applications, do not fit that model. A new
>   authentication mechanism optimized for such web applications will be created.
> - TURN server auto-discovery mechanism for enterprise and ISPs
>   Candidate draft: TBD
>   Current TURN server discovery is based on the presence of SRV and/or NAPTR DNS
>   records. These records are usually under the administrative control of the
>   application or service provider, not the enterprise or the ISP on whose
>   network the client is situated. Enterprises or ISPs wishing to provide their
>   own TURN server, in an attempt to reduce so-called "triangle routing", need a
>   new auto-discovery mechanism.
> - STUN-bis
>   Candidate draft: TBD
>   A new revision of RFC 5389 will contain:
>   - Various bug fixes
>   - STUN hash algorithm agility (currently only SHA-1 is allowed)
> - TURN-bis
>   Candidate draft: TBD
>   A new revision of RFC 5766 will contain:
>   - Various bug fixes
>   - Support for multi-tenant servers
>     (Servers always send the same REALM attribute. No realm negotiation phase
>      currently exists.)
> Goals and Milestones:
> [TBD]

DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
STUN/TURN server               --> http://numb.viagenie.ca