Subject: [BEHAVE] TURN 06 Comments

From: Cullen Jennings <[email-masked]>
Date: Thu, 24 Jan 2008 22:39:46 -0800

Gave the document a quick skim. Few comments ....

The whole design of refreshing and lifetimes of allocations and  
permissions seems very disjoint and sub optimal.  I would be tempted  
to go with allocation go away 30 seconds after they have no valid  
permissions. Permissions can be updated by client sending data or zero  
length send. Permissions durations match BEHAVE UDP documents.

Much of the discussions around permissions make them sound like they  
are not bound to a specific allocation and instead the permissions is  
granted to the whole TURN server. This needs to be cleaned up.  
(Normative stuff looks right).

I view the whole redirect to another TURN server as a really bad idea.  
Not to mention that it conflicts with the 3489 usage of this but even  
worse, it is highly likely to cause things to fail during overload in  
a way where the overloaded machine gets bounced around and the system  
never recovers. I think the SRV mechanisms are sufficient for load  
balancing, work well, and we should get rid of this stuff.

Not a big deal but I don't like the waiting to 3/4 of LIFETIME, If the  
lifetime is 7200 this is way too early - I would prefer something more  
like LIFETIME minus 5 seconds and some introduction of jitter.

section 5.2, 2nd bullet point. It looks like it always replies with  
437 to a request over TCP. I might just be reading this wrong.

Bandwidth - section 5.2.1.1 I would not want to use the words"  
determines if there is sufficient capacity" as this may be very hard  
to do, instead something like "decide if willing to grant this  
bandwidth". The contract is not guaranteeing a minimum, it is setting  
a max and suggesting a best attempts will be made to do minimum, We  
still need to specify the algo for computing this.

Section 5.2.1.4: One of the key design points of this protocols is  
that you can not use it to pick an arbitrary port number to run over.  
This seems to change that and that is one of the things I feel very  
strong about. You need to support paired ports for RTP/RTCP because  
TURN is the last line of defense that is supposed to always work. I am  
fine with a protocol where the client asks for a pair and gets X and  
knows that X+1 is reserved and then requests X+1. I am not ok with a  
protocol where the client gets to choose the port the server uses.

5.2.1.6, 2nd para. The idea that "standard services" run on ports  
below 1024 does not seem true.

Section 6.3 - This should be reworded to say what goes in the UDP  
payload and then a UDP packets is sent. Once we start talking about  
forming UDP checksums, it is a sign something is not right :-)

Section 7.5, first para. Where you have SHOULD use the Channel-Data, I  
think that has to be a MUST. The server has no way of knowing what the  
clients bandwidth issues are thus cannot make a reasonable  
determination.

Section 2.1. para 2. I find this paragraph somewhat bogus. The  
visibility of peers to attacker between client and TURN server is not  
a threat model I have seen brought up before. Doubt it is relevant. I  
find the argument that TLS has better success rate of traversing  
firewalls than TCP to be, uh, unproven at best.

Section 12

The whole document (not just this section) seems a bit weak on short  
and long term credentials. My understanding is that we don't want to  
create unauthenticated open relays. So even if anyone can get an  
account on a public server, we still want to be able to log what  
account did what. My recollection of previous conversations when doing  
STUN bis was the allocated were going to use long term credentials and  
help set up the short term credentials used to authenticate the data,  
send, and channel data.  I'm not claiming I corruptly remember any of  
this but either way, still looks like some work needed here on how  
this is all authorized.

As a trivial side note, it looks like some of the issues with NAT  
remote in section 12 could be substantially mitigated by clients  
choosing random channel numbers.

On the open issues, I don't actually think all of these are open:

1) thought we agreed to do this

2) I think we agreed address-restricted. I suspect I was the only  
person arguing for address-and-port and well, I loose :-)

3) we need this

4) uh, we are looking for a demux simpler than bit mask 2 bits? Surely  
you are joking :-) Actually I have no idea if we are done or not here.  
I think we need to go think carefully about all the demux.

6) any reason why not?

8) I found Magnus and Lars emails about this pretty much sold me on  
the answer

10) A client should only be able to request an IP address returned in  
allocate response fro the same server and for a allocation that is  
still valid.

11) we should make this the same as the BEHAVE UDP documents. Note  
that choices other than this will result in the same long discussions  
over again and be difficult to implement for some styles of  
implementations (i.e. windows or unix not running as root).

12, 14 - see previous comments on this

15 - I don't care but my gut feeling is put on v4/v6 relays for now.  
Or at least make sure you have the support of the v6ops community  
before you do it.

Cullen <with my individual contributor hat on>

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

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Fri, 25 Jan 2008 04:56:58 -0800

> Gave the document a quick skim. Few comments ....

[snip]

> like LIFETIME minus 5 seconds and some introduction of jitter.

I agree with this.  My suggestion was to use LIFETIME minus 7900ms (the
duration of a STUN transaction), and to also reject too short LIFETIME
values (e.g. with a 423 error code) and to reject a LIFETIME of 0 in the
Allocate request instead of considering it a no-op. See comments #4, #7
and #18 in this email:

http://www1.ietf.org/mail-archive/web/behave/current/msg02905.html

Thanks.

-- 
Marc Petit-Huguenin           [                                 ]
Home: [email-masked] [RFC1855-compliant space for rent ]
Work: [email-masked]            [                                 ]
[                                                               ]

---

From: Philip Matthews <[email-masked]>
Date: Mon, 28 Jan 2008 11:29:01 -0500

I tried to capture this in the open issue around permission and  
allocation lifetimes.
In particular, there seems to be no point in having the allocation  
lifetime to be less than the permission lifetime.

So my suggestion is:
* Permission lifetime MUST be at least 2 minutes, with a recommended  
value of 5 minutes (c.f. BEHAVE-UDP).
* Allocation lifetime MUST be at least as long as the permission  
lifetime.
* Allocation lifetime SHOULD be at most one hour.

We can debate the exact value for the last point, but the goal is to  
make sure that the server can detect when the client has crashed.

- Philip