[rtcweb] Turn Revised And Modernized (tram)

[Simon Perreault <[e-mail]>]

All,

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 
<[e-mail]>.
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