Subject: [BEHAVE] TURN as enterprise proxy mechanism

From: Matthew Kaufman <[email-masked]>
Date: Fri, 04 Apr 2008 10:35:42 -0700

We are developing an application which we expect to be (very) widely 
deployed that makes client-server and peer-to-peer connections over a 
UDP-based protocol.

Enterprise customers that wish to block all UDP traffic at their 
firewall have asked for a way to enable the use of this application 
using some sort of proxy.

TURN appears to provide the most convenient UDP-UDP proxy mechanism that 
we've seen specs for, though this application is somewhat different than 
"TURN server on public Internet", and thus assumptions and requirements 
are different than that case.

A handful of questions:

1. Should we be looking at something else instead? (Not SOCKS, as it 
doesn't appear to act as a UDP-UDP proxy and appears to require a fixed 
destination address, both incompatible with our requirements)

2. Has there been any thought given to an advisory "User Agent" 
parameter during association? Enterprises may wish to operate an 
unauthenticated TURN proxy for their employees, but have at least some 
guess as to what is using it. (Note that this is also a good reason for 
continuing to allow an unauthenticated mode of operation for TURN)

3. Has there been any thought given to a DHCP option for providing 
clients with the address of a local TURN server? (This may seem exactly 
backwards from the STUN goal of having the server independent of the 
enterprise network so that the "outside" address may be derived, but 
would help our application and also could support enterprise policy 
about which STUN/TURN server they'd like their VoIP phones using)

Matthew Kaufman
[email-masked]
_______________________________________________
Behave mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/behave

---

From: "Dan Wing" <[email-masked]>
Date: Fri, 4 Apr 2008 17:50:06 -0700

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Matthew Kaufman
> Sent: Friday, April 04, 2008 10:36 AM
> To: [email-masked]; [email-masked]; [email-masked]
> Cc: [email-masked]
> Subject: [BEHAVE] TURN as enterprise proxy mechanism
> 

http://www1.cs.columbia.edu/~lennox/udptunnel also uses fixed addresses, but
might be useful for you.  For example, you could run a CGI on your proxy which
called udptunnel with the necessary UDPtunnel parameters.

> continuing to allow an unauthenticated mode of operation for TURN)

A new STUN attribute could be defined for that.  But of course there
wouldn't be any good way to authenticate its contents -- once someone
learns that 'udp-chat-1.0' and 'quake' are both acceptable for using
the TURN server, they'll configure other TURN-aware applications to
put those strings into that attribute.  But if the applications and
the users are more-or-less trusted (which is often the case with
enterprises -- they can fire employees that subvert company policy),
it could be helpful for traffic statistics.

> about which STUN/TURN server they'd like their VoIP phones using)

Nobody is working on that, but it seems reasonable to me -- it is
more reasonable than doing a DNS SRV query to find your TURN server.

A drawback with DHCP options is the years it takes to get into 
OSs and into DHCP servers.

-d

---

From: Rohan Mahy <[email-masked]>
Date: Sun, 6 Apr 2008 11:16:10 -0700

Hi Mathew,

I think TURN is perfectly reasonable for your application.

While you could define a new USER-AGENT or CLIENT attribute. I  
definitely recommend against making any application unauthenticated  
in an enterprise.  The enterprise certainly has a username/password  
directory (possibly more than one). I would suggest just using that  
same directory.

Why is DNS not working well for you? In my experience it is far  
easier to configure and deploy a new SRV record than a new DHCP  
option.  You have to add the DHCP option on a per-scope (subnet)  
basis whereas the SRV record is done once per zone (domain name).   
Any information you can provide here would be useful.

thanks,
-rohan

On Apr 4, 2008, at 10:35 AM, Matthew Kaufman wrote:
> We are developing an application which we expect to be (very)  
> widely deployed that makes client-server and peer-to-peer  
> connections over a UDP-based protocol.
>
> TURN appears to provide the most convenient UDP-UDP proxy mechanism  
> that we've seen specs for, though this application is somewhat  
> different than "TURN server on public Internet", and thus  
> assumptions and requirements are different than that case.
>
> A handful of questions:
>
> 1. Should we be looking at something else instead? (Not SOCKS, as  
> it doesn't appear to act as a UDP-UDP proxy and appears to require  
> a fixed destination address, both incompatible with our requirements)
>
> unauthenticated TURN proxy for their employees, but have at least  
> some guess as to what is using it. (Note that this is also a good  
> reason for continuing to allow an unauthenticated mode of operation  
> for TURN)
>
> clients with the address of a local TURN server? (This may seem  
> exactly backwards from the STUN goal of having the server  
> independent of the enterprise network so that the "outside" address  
> may be derived, but would help our application and also could  
> support enterprise policy about which STUN/TURN server they'd like  
> their VoIP phones using)
>
> Matthew Kaufman
> [email-masked]

---

From: Matthew Kaufman <[email-masked]>
Date: Sun, 06 Apr 2008 13:59:00 -0700

> called udptunnel with the necessary UDPtunnel parameters.
Appears to also suffer from the same "one allocation talks to one far 
host/port" problem. Our application requires that a single local (or 
proxied-local) UDP port be able to talk to multiple far UDP host/port.
> it could be helpful for traffic statistics.
That would be the utility, exactly. It could be used in enterprises 
where employees are entirely trusted for enabling/disabling certain 
applications, and in enterprises where employees are mostly trusted for 
logging (but not access control).
>> clients with the address of a local TURN server? 
Our application can make the DHCP query itself, and even my home 
firewall has the ability to set new custom DHCP options (unfortunately 
only top-level options, not ones that use the vendor class mechanism)

Matthew Kaufman
[email-masked]

---

From: Matthew Kaufman <[email-masked]>
Date: Sun, 06 Apr 2008 14:09:29 -0700

> I think TURN is perfectly reasonable for your application.
Thanks for the vote in favor... that gives me additional confidence that 
we're going down the right path.
> definitely recommend against making any application unauthenticated in 
> an enterprise.  The enterprise certainly has a username/password 
Some enterprises will want per-user authentication, others don't need 
it. Just as some enterprises require click-throughs or logins to use 
their outbound web proxy, and others allow all users access to the web. 
And like the web proxy, the reason TURN is even appropriate here is 
because some enterprises we've talked to feel it is more secure to 
funnel all UDP traffic for a particular application through a proxy that 
can do things like log usage than it is to just open up outbound UDP 
company-wide on the firewall.
>
> Why is DNS not working well for you? In my experience it is far easier 
> to configure and deploy a new SRV record than a new DHCP option.  You 
> have to add the DHCP option on a per-scope (subnet) basis whereas the 
> SRV record is done once per zone (domain name).  Any information you 
> can provide here would be useful.
>
We're trying to solve the same problem as WPAD (finding a proxy server 
for our client application), and DNS has the same (security) issues for 
us that it has for WPAD-using-DNS. Unless you're suggesting an SRV 
record in <applicationname>.local or something like that. Whether 
strange entries in a .local domain or new DHCP options is more likely to 
be accepted by an enterprise is an open question, though one could argue 
that at some multi-site organizations, having proxies per DHCP scope is 
more appropriate than proxies per scope-of-company-provided-DNS-resolver.

We also need this application to "do the right thing" when it is 
installed in an environment other than an enterprise that has made the 
special configurations necessary to use it, which is to say not do 
things that would annoy consumer ISPs or expose the user to bad things. 
(DNS queries to .local probably fails the first, DNS queries up the 
chain of names as WPAD tried to do certainly fails the second)

The alternative is for users in environments that need the traffic to 
pass through a TURN bottleneck to have to ues a settings dialog and/or 
edit a configuration file... we're just trying to avoid that, and 
thought that DHCP or similar auto-discovery might have already been 
explored for STUN/TURN.

Matthew Kaufman
[email-masked]