Subject: [BEHAVE] TURN Issue #8: Managing permission lifetimes

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 07 Dec 2007 18:22:12 -0500

This issue was not in my slides. It was raised at the mike in the WG 
meeting, and was not discussed further at the ad-hoc.

The issue is this. In TURN-05 (and for several versions prior), 
allocations have an expiration and are refreshed explicitly by TURN 
signaling. However, permissions are refreshed by data traffic, and there 
is NO way to explicitly ask for a longer permission. Ekr pointed out 
that, we had a SAFE BoF at this IETF which was trying to address the 
problem that we didn't have an explicit way to manage the binding 
lifetimes on the NAT. So, since a TURN server is basically a 
remote-controlled NAT, isn't it silly to design it outright in a way 
that is known to be broken?

The counter-argument that was made, is that you need to send the data 
traffic anyway to refresh the bindings between the client and the NAT. 
However, if there are multiple peers connected through the allocation, 
it would be possible to send a single data keepalive just to keepalive 
the connection from client to TURN server, instead of sending data 
keepalives for each peer. This is true only if there are no NATs between 
the TURN server and the peers. It was pointed out that there are real 
use cases for that, including enterprise deployments and p2psip.

It was further pointed out that, if SAFE moves forward, at that time we 
could add extensions to turn to manage the permission lifetimes. Indeed, 
if SAFE uses STUN, it might even be the case that we could re-use that 
very extension, but just send it to the TURN server instead of the NAT. 
That would be really neat.

Consequently, my sense from the meeting was that there was rough 
agreement to leave this alone, and not try to add support in TURN for 
explicitly requesting longer permission lifetimes. I think this is the 
right thing.

Please comment if you agree (or don't) with this.

Thanks,
Jonathan R.
-- 
Jonathan D. Rosenberg, Ph.D.                   499 Thornall St.
Cisco Fellow                                   Edison, NJ 08837
Cisco, Voice Technology Group
[email-masked]
http://www.jdrosen.net                         PHONE: (408) 902-3084
http://www.cisco.com

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

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 10 Dec 2007 19:43:41 -0800

At Fri, 07 Dec 2007 18:22:12 -0500,
> Please comment if you agree (or don't) with this.

I'm fine with this.

-Ekr

---

From: Philip Matthews <[email-masked]>
Date: Thu, 13 Dec 2007 09:16:08 -0500

I support leaving this alone and waiting for the SAFE work to progress.

- Philip

On 7-Dec-07, at 18:22 , Jonathan Rosenberg wrote:

> This issue was not in my slides. It was raised at the mike in the  
> WG meeting, and was not discussed further at the ad-hoc.
>
> signaling. However, permissions are refreshed by data traffic, and  
> there is NO way to explicitly ask for a longer permission. Ekr  
> pointed out that, we had a SAFE BoF at this IETF which was trying  
> to address the problem that we didn't have an explicit way to  
> manage the binding lifetimes on the NAT. So, since a TURN server is  
> basically a remote-controlled NAT, isn't it silly to design it  
> outright in a way that is known to be broken?
>
> The counter-argument that was made, is that you need to send the  
> data traffic anyway to refresh the bindings between the client and  
> the NAT. However, if there are multiple peers connected through the  
> allocation, it would be possible to send a single data keepalive  
> just to keepalive the connection from client to TURN server,  
> instead of sending data keepalives for each peer. This is true only  
> if there are no NATs between the TURN server and the peers. It was  
> pointed out that there are real use cases for that, including  
> enterprise deployments and p2psip.
>
> It was further pointed out that, if SAFE moves forward, at that  
> time we could add extensions to turn to manage the permission  
> lifetimes. Indeed, if SAFE uses STUN, it might even be the case  
> that we could re-use that very extension, but just send it to the  
> TURN server instead of the NAT. That would be really neat.
>
> agreement to leave this alone, and not try to add support in TURN  
> for explicitly requesting longer permission lifetimes. I think this  
> is the right thing.
>