Re: [tram] Stephen Farrell's Discuss on draft-ietf-tram-stun-origin-05: (with DISCUSS and COMMENT)

[Simon Perreault <[e-mail]>]

Le 2015-05-13 06:58, Stephen Farrell a écrit :
> On 10/05/15 18:19, Simon Perreault wrote:
>> I don't follow. If the browser lies, then authentication will fail.
>> Where's the problem?
>> 
> 
> So let's say that a TURN server works on behalf of two "tenant" 
> services, S1 and S2 (legacy-SIP or WebRTC doesn't matter for this 
> point).
> 
> S1 are mean and charge the end user per byte/second and when the
> TURN server is working on behalf of S1 then the TURN server will do
> loads of accounting that'll eventually turn into billing from S1 to
> the user at the UA.
> 
> S2 however are rich new Internet kids and offer calling for nothing
> - they just use some of their vast advertising revenue to pay the
> TURN server operator a big pile of cash and the end user never has to
> pay, because S2 make money elsewhere.
> 
> As a user, I can have accounts with both, and can authenticate to
> the TURN server as either. (I'm not saying that is good but it is
> what you've told me I think.)
> 
> I will of course always assert that the "origin" for all of my calls 
> is S2 and authenticate with those credentials, even when I'm making a
> call that is setup by S1 and that properly ought to be billed that 
> way. (And such a call can be to a destination that is simply not 
> reachable via S2's signalling of course.)
> 
> The fact that this origin is used by the TURN server to pick between 
> those and that there is no binding between that and the in-progress 
> call enables me to succeed when I try the age-old trick of getting 
> calls for nothing.

Correct.

However, imagine the same situation with current STUN authentication
(i.e., no ORIGIN, no third-party-auth). You have an account on each of
S1's and S2's servers, each of which listen on different IP addresses.
You can still use S2's server for a call signalled using S1's servers.

What makes this possible is that STUN authentication has no binding with
call signalling. ORIGIN does not attempt to change this.

> Can you tell me what in the current proposal (or the underlying 
> context, and hence perhaps properly not documented here) means that 
> the above is a non-issue? Or where else am I going wrong?

STUN/TURN is by design a stand-alone NAT traversal service. An important
design principle is that the endpoints are responsible for their own NAT
traversal. Contrast this to hosted NAT traversal [RFC7362].

That is, endpoints using a generic RFC 3261 SIP proxy as signalling
server can use ICE with STUN/TURN servers of their choosing to establish
a peer-to-peer session. The SIP proxy does not need to be aware of any
of this. By design, the STUN/TURN server has a relationship with the
endpoint, not with the signalling infrastructure.

With WebRTC, the typical deployment model has the application provider
in charge of signalling, endpoint provisioning, and STUN/TURN server
operations This particular model makes a binding between signalling and
STUN authentication a possibility.

However, in general, by design, STUN/TURN is a client-server protocol,
and has nothing to do with signalling. Therefore, when a client has an
account with a server, it can use it with whatever signalling it wants.
The server is not aware of this. By design.

Simon