[tram] STUN auth: The endpoint is in control

[Simon Perreault <[e-mail]>]

TRAMsters,

I think it is important, in order to make STUN's authentication model
clearer in the face of WebRTC usage, that we start re-emphasizing that
the endpoint is in control of its own NAT traversal, independent of call
signalling. This is a core design principle of STUN/TURN/ICE.

=======================

Exhibit A: <http://numb.viagenie.ca>

This is a freely-available STUN/TURN server. You just sign up for an
account and start using it with whatever signalling infrastructure you
want. With SIP, just configure the server address, username, and
password into your SIP client and you're ready to go. With WebRTC you
can do the same by configuring those into your browser, which should
override any application-provided servers.

Notice that the endpoint is fully in charge of its own destiny. It has a
relationship with the server, but the signalling infrastructure does not.

With this use-case the IP addresses on which the server listens are
dedicated to the public service. ORIGIN would be useful in order to
co-locate the public service with some class of private services
(different auth database) without dedicating new IP addresses for each
private service.

========================

Exhibit B: <https://tools.ietf.org/html/draft-ietf-rtcweb-return-00>

RETURN is a way for WebRTC endpoints, browsers in particular, to force
usage of a particular TURN server, with which the endpoint has a prior
trust relationship, in order to ensure some level of privacy for the
endpoint. A second layer of non-privacy-providing TURN may be used in
order to provide NAT traversal.

In this case too the endpoint is fully in control. The signalling
infrastructure (i.e., the WebRTC application) has no relationship with
the privacy-providing TURN server, and no control over it.

========================

What I'm getting at is that trying to bind STUN auth with the signalling
session goes against STUN/TURN/ICE design.

Thoughts? Comments?

Simon