Subject: [BEHAVE] TURN: Rebinding channels

From: Philip Matthews <[email-masked]>
Date: Wed, 6 Feb 2008 21:25:23 -0500

Here is a strawman proposal for a mechanism to rebind channels.

* A channel becomes unbound when its associated permission expires.
* A server only allows unbound channels to be bound to a peer.  
Attempts to bind an already bound channel are rejected.
* If a server receives a ChannelData msg on an unbound channel, it  
replies with an UnboundChannel indication. To prevent any form of  
amplification, the indication is suppressed if another indication was  
sent within the last 100 msec.

Comments?

- Philip

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

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 07 Feb 2008 09:15:38 -0500

I agree with the first and second bullets. I'm worried about the third. 
Since indications are not authenticated, and attacker can send an 
UnboundChannel indication and cause the client to cease using that 
channel, instead trying to rebind with a channel bind transaction. This 
provides amplification and increases work on the server.

-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]
http://www.ietf.org/mailman/listinfo/behave

---

From: Rémi Denis-Courmont <[email-masked]>
Date: Thu, 7 Feb 2008 16:24:41 +0200

Le Thursday 07 February 2008 16:15:38 ext Jonathan Rosenberg, vous avez 
> provides amplification and increases work on the server.

I agree here.

UDP is UDP. It is not reliable and voilà. The application-layer protocol 
running on top of TURN needs to have some kind of time out detection that 
will be triggered to address this particular case.

Also: If the server resets, it shall loose entire TURN allocations, not just 
some channels. So it does not seem that useful. It feels like yet 
another "dear client, I, the server, am sorry to inform you that you are 
buggy and I cannot deal with you" type of message, that I can happily live 
without.

-- 
Rémi Denis-Courmont

---

From: Philip Matthews <[email-masked]>
Date: Thu, 7 Feb 2008 10:20:59 -0500

Good point about the lack of authentication on indications.

So let's modify the proposal as Remi suggests and change the third  
bullet to:
* If a server or client receives a ChannelData msg on an unbound  
channel, the msg is silently discarded.

- Philip

---

From: Philip Matthews <[email-masked]>
Date: Fri, 8 Feb 2008 16:49:13 -0500

During yesterday's conf call, we agreed to make channel bindings last  
longer than permissions, but were vague on whether to keep their  
lifetime tied to permissions or not. (As I recall, Jonathan thought  
they should not be tied, someone else thought they should, and we  
left the issue unresolved). As I think more about things today, I now  
feel they SHOULD NOT be tied to permissions: since they have a  
different lifetime, I think it makes things clearer if their lifetime  
is not tied.

So here is my modified proposal:

* A channel binding last 10 minutes unless refreshed.
* A channel binding can be refreshed either (a) by sending a  
ChannelData message from the client to the server on the channel, or  
(b) by sending a ChannelBind message to the server rebinding the  
channel to the same peer.
* Attempting to bind a already-bound channel to a different peer is  
an error (rebinding to the same peer is OK).
* A ChannelData message on an unbound channel is silently ignored.

Channels interact with permissions as follows:
* ChannelBind and ChannelData messages from the client to the server  
also install/refresh a permission for the IP address of the peer.

This proposal also removes the small defect in the previous proposal  
that sending data to port X on a peer would keep a channel to port Y  
on the same peer open, even if the channel was never used. (I don't  
think this is a big issue, but it is a little bonus).

Another thing I like about this proposal is that it is easy to  
document. All the text goes into the section on Channels; there is no  
need to add text to the (new) section on Permissions (and associated  
cross-references).

Unless I hear objections, this is what I plan to put into TURN-07.

- Philip

---

From: "Derek MacDonald" <[email-masked]>
Date: Mon, 11 Feb 2008 10:38:31 -0800

Are zero-length ChannelData messages going to be defined as a
mechanism for keeping a channel alive?

---

From: Philip Matthews <[email-masked]>
Date: Mon, 11 Feb 2008 14:58:29 -0500

> mechanism for keeping a channel alive?

At present, a zero-length ChannelData message will result in a UDP  
datagram with zero data bytes being sent to the peer. Like all  
ChannelData messages from the client to the server, this will refresh  
the binding.

Alternatively, the client can rebind the channel to the peer (= send  
a ChannelBind message rebinding the channel number to the peer). This  
will refresh the channel binding without causing anything to be sent  
to the peer.

Right now, I don't see a need to special-case the zero-length  
ChannelData message.

- Philip