Re: [tram] stun-origin status==? Is it dead?

Hi Alan et al.

Many thanks for your fast reply!

Do you know any alternatives/workaround to use TURN server with multiple
realms?

What if a client sends in the first STUN request the preferred realm
(which the client's username/credential belongs to) instead of the web
origin?
(In practice the Web ORIGIN is almost useless AFAIU for the TURN server,
it is only used to map it to a realm.)

Add a new attribute in STUN, e.g. "PREFERRED_REALM"

So instead of sending origin, what if we add a new STUN attribute with
the preferred REALM and so, if the client adds it to the first STUN
request then the STUN/TURN server use this realm (instead of default
realm) during the response with the nonce?

(and may add a new optional attribute "realm" in stun/turn credential in
WebRTC STUN/TURN iceServer to indicate for TURN server which realm the
user credential belongs to.)

This hopefully address the origin based too much info leakage.

Could be the idea above a possible acceptable workaround way forward to
continue work on multi domain turn?

Any alternatives?

What are Your thoughts?

Thx,
Misi

2017-01-18 14:39 keltezéssel, Alan Johnston írta:
> Hi Misi,
>
> Yes, it is dead.  While the mechanism is convenient, it leaks too much
> meta-data so the working group abandoned the effort.
>
> - Alan -
>
> On Wed, Jan 18, 2017 at 3:45 AM, Mészáros Mihály <misi@niif.hu
> <mailto:misi@niif.hu>> wrote:
>
>     Hi,
>
>     I am planning to build a multi realm TURN service that would use
>     multi realm feature in coturn.
>
>     But I sadly realized that there was some for me not very clear
>     IETF concerns and somehow writing draft-ietf-tram-stun-origin has
>     been stopped..
>
>     I am wondering what is the WG position about this draft status and
>     future?
>
>     I need this multi domain to avoid server duplication:
>
>       * I need to use multi realm to reuse TURN servers and separate
>         user credential domains, to avoid TURN server duplication for
>         every realm in every region.
>       * If this origin way could not be fixed then then I don't see
>         any way to make a multi realm TURN service.
>         (coTURN name is based on this feature AFAIK.)
>       * If we don't send any information from client side that could
>         be use on coTURN side to identify user credential realm than
>         coTRUN multidomain feature could not be used at all.. :(
>
>     I am wondering if you know what was the main concern about in
>     IESG/IETF tram?
>
>     And if this is final or not? Could it be somehow work it out?
>
>     Why is it a show stopper concern?
>
>     Is it possible to make any workaround to make it possible to send
>     any realm related info to to turn server ?
>
>     I read the connected tram list mails and the ballot
>     <https://datatracker.ietf.org/doc/draft-ietf-tram-stun-origin/ballot/>,
>     but still not clear for me the main concern, and the actual status.
>
>     (The hardest concern was I think Stephen Farrell concerns, but I
>     feel it could be addressed.)
>
>     Unfortunately I saw all WebRTC browsers stopped implementing it.
>
>       * https://bugzilla.mozilla.org/show_bug.cgi?id=1123722
>         <https://bugzilla.mozilla.org/show_bug.cgi?id=1123722>
>       * https://bugs.chromium.org/p/webrtc/issues/detail?id=4091#c10
>         <https://bugs.chromium.org/p/webrtc/issues/detail?id=4091#c10>
>
>     All in all I would like to know the reasons behind Justin statement:
>
>     This feature is dead. We should plan to remove the code when convenient.
>
>     I would like to turn it back if possible and find a way to make
>     multi realm TURN work.
>
>     Any comments would be highly appreciated!
>
>     Thanks,
>     Misi
>
>     _______________________________________________
>     tram mailing list
>     tram@ietf.org <mailto:tram@ietf.org>
>     https://www.ietf.org/mailman/listinfo/tram
>     <https://www.ietf.org/mailman/listinfo/tram>
>
>