Re: [tram] Path Forward for STUN ORIGIN - analysis

[Cullen Jennings <[e-mail]>]

more or the analysis of cases 4 and 5 

> On Aug 25, 2015, at 1:57 PM, Alan Johnston <[e-mail]> wrote:
> 
> 
> 4.  Authorization at border TURN server after authentication.  An enterprise border TURN server can apply policy and allow usage for certain Origins (whitelist) or block usage of others (blacklist).
> 
> 5. draft-jennings-behave-rtcweb-firewall-01 discusses how a firewall with STUN server could use ORIGIN in authorization decisions.
> 
...
> 
> In comparing this solution against the use cases above:
> 
> 4. & 5. Does not seem provide a good solution for these use cases.
> 

I think the solution here does meet the most important pats of use case 4 and 5... let me explain. 

For case 5 ... For applications that care about working in network environments that require the ORIGIN, they will have to add a DNS entry to point at the turn server they want to use. Note they don't have to run their own TURN or STUN server, they just have to have a DNS entry that points at the one they use then use the DNS name that matches their website in the javascript. The -02 firewall draft is updated to assume a solution like this. 

For case 4 ... I'm not seeing the problem. The DNS name of the TURN server would have been provided along with credential s by whatever discover / configuration mechanisms gave it to the browser so it would match and would be provided.