Re: [tram] First post

How does MICE impact TURN?

On Fri, Nov 15, 2013 at 11:01 AM, Oleg Moskalenko <mom040267@gmail.com>wrote:

> MMUSIC has an interesting draft on TURN mobility (MICE) that I am watching
> and I am going to implement. I wonder whether the authors of the draft may
> be interested in the TURN evolution.
>
>
> On Fri, Nov 15, 2013 at 10:55 AM, Simon Perreault <
> simon.perreault@viagenie.ca> wrote:
>
>> All,
>>
>> Any objection against sending the following to rtcweb, pntaw, and behave?
>> Any other lists that should be included?
>>
>> Simon
>>
>> ====================
>>
>> 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 <
>> tram@ietf.org>.
>> 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
>> _______________________________________________
>> tram mailing list
>> tram@ietf.org
>> https://www.ietf.org/mailman/listinfo/tram
>>
>
>
> _______________________________________________
> tram mailing list
> tram@ietf.org
> https://www.ietf.org/mailman/listinfo/tram
>
>