Re: [tram] I-D Action: draft-ietf-tram-turnbis-19.txt

[Dan Wing <[e-mail]>]

Back on 13 August 2018, Jonathan Lennox <[e-mail]> wrote:

> I’d also like to get security review of this change, especially from the perspective of people running firewalls.
> 
> One of the design goals of TURN originally was that it behave like an address-dependent filtering firewall / NAT — you can’t get incoming traffic from a peer you don’t already know about. This was so it can’t be used to tunnel connections to an open server behind a firewall, e.g. to allow a controller somewhere on the open Internet to contact malware running inside a corporate network. 
> 
> Thus, network operators can be more confident about allowing TURN traffic out through their firewalls. 
> 
> Permissionless ICE relay support breaks this guarantee, if you can tunnel your traffic to make it look like ICE connectivity checks, and I’m worried it will make operators less willing to allow TURN out of their networks. 
> 
> Now, maybe the relevant operators are already not allowing TURN, or there are already plenty of ways to tunnel in traffic, so this isn’t a concern. But if we change this property, I’d like to make sure we’re doing so with full consciousness and deliberation. 

I was poking through STUNbis and TURNbis recently and thought of a different approach.

Prior to -19, TURN created permissions based on the remote IP address.  Could we create permissions based on the remote STUN Username?  That would avoid the "permissionless" problem, as the local peer (which created the TURN allocation) knows half the STUN connectivity check Username (the portion before the ":"), and can communicate that to the TURN server to install what we might call a "username permission".  The TURN server could allow traffic that has (1) an IP permission or (2) is STUN with a matching Username.  We should be able to piggyback that username onto the existing TURN allocation.  Finally, considering ":" is used for the local:remote STUN username, we might consider using another character (e.g., "@") as a username prefix for the TURN server to allow, so that the local client can use different STUN usernames for other purposes.

-d