Subject: Re: [BEHAVE] Comments on TURN-06

From: Philip Matthews <[email-masked]>
Date: Wed, 20 Feb 2008 10:43:04 -0500

Marc:
Thanks for the comments. And sorry to be slow in responding. I was  
busy working on TURN-07, which is now almost done.

On Sat, 26-Jan-08, at 09:06 , Marc Petit-Huguenin wrote:

> 1. Section 5.2.1.2: "If the request did not contain a
> REQUESTED-TRANSPORT attribute, the server MUST use the same transport
> protocol as the request arrived on."
>
> As TURN-06 only defines the usage of UDP between the server and the
> peer, I do not see how to implement this.  UDP should be the  
> default if
> there is no REQUESTED-TRANSPORT attribute.

I have totally rewritten this section.
Elsewhere TURN-06 required the Allocate request to contain a  
REQUESTED-TRANSPORT attribute, so I went with that approach instead.  
TURN-07 currently says that the client MUST request UDP, and the  
server will reject any protocols it doesn't support.

>
>
> 2. Section 5.2.1.6: "Note that the LIFETIME attribute in an Allocate
> request can be zero, though this is effectively a no-op, since it will
> create and destroy the allocation in one transaction."
>
> I saw that section 5.2.1.5 now allow the server to reject too short
> values of LIFETIME, which is good.  Let's also reject a LIFETIME value
> of 0 in the Allocate request.

TURN-07 now takes a more radical approach.
Allocation lifetimes now default to 10 minutes. Clients can ask the  
server to increase this, but the server ignores any requests to  
decrease it.
I didn't see any real need for shorter lifetimes.

>
>
> 3. Section 5.2.2: "If its associated Allocate request contained the
> BANDWIDTH attribute, or this Refresh request contained a new BANDWIDTH
> attribute, the response MUST also contain the BANDWIDTH attribute."
>
> I think that this is inconsistent with what is said in section  
> 5.2.1.7,
> were a BANDWIDTH attribute is always added to the response.  I think
> that it should be the same for the Refresh response.

Currently in TURN-07, the BANDWIDTH attribute is always included in  
the response.

>
>
> 4. Section 6.2: "Any other attributes appearing in the message are
> treated as unexpected."
>
> I am not sure what this means, but I hope that this is not meant to
> override rfc3489bis-13 section 7.3.2, i.e. to consider all other
> attributes as comprehension-required attributes and to discard the
> indication if any other attribute appears in the message.  I would
> suggest to remove this sentence completely.

It was not meant to override that section.
Jonathan complained about this too, so I have remove that sentence.

>
>
> 5. Section 17.1, issue #2: "...under the assumption that the IT
> administrator will only allow clients to contact those servers that
> implement whatever permission policy the IT administrator can accept?"
>
> And how the IT administrator knows that the contacted server  
> implements
> the correct permission policy, if the server is not in the domain
> managed by IT and TLS is used between the client and the server?

My idea was that the IT admin would config the firewall to only allow  
TURN traffic to certain IP addresses. But no one seemed to like this  
idea on the conf calls, so I have dropped it.

>
>
> 6. Section 17.1, issue #3: "Port Adjacency"
>
> I do not see what the big deal is with this issue.  The first Allocate
> binds multiple ports and returns the first one.  If it cannot, then  
> the
> Allocate fails.  Other Allocate requests from different tuples
> authenticated with the same credentials can explicitly request the
> additional ports.  If the additional ports are never requested,  
> they are
> deallocated at the same time the first port is deallocated.  And this
> mechanism can be extended in the future by using the remaining bits in
> REQUESTED-PORTS to some other exotic allocation schemes, like  
> requesting
> multiple contiguous ports, or multiple ports that are all subsequent
> prime numbers or whatever.

TURN-07 uses a slightly modified version of Cullen's proposal for  
port properties. This is as per our conf call discussions.

>
>
> 7. Section 17.1, issue #10: "Allowed PEER-ADDRESS values"
>
> The problem is not what is allowed in a PEER-ADDRESS attribute, but  
> what
> values of PEER-ADDRESS are valid for this specification.  I suggest to
> explicitly say in the spec that the usage of multicast addresses,
> broadcast addresses and 0.0.0.0 address is not defined in this spec  
> (but
> can be in extensions) and that a Send indication with this addresses
> will be dropped and a Bind Channel request will be rejected.

The PEER-ADDRESS attribute is now gone (as per Cullen's proposal),  
though I have re-used the codepoint for the new RESERVATION-TOKEN  
attribute that conveys the token in Cullen's proposal.

>
>
> 8. Section 17.1, issue #13: "Re-using the 5-tuple"
>
> A client should be able to reuse the same tuple immediately, with same
> or different credentials.

Currently, TURN-07 requires a 2 minute delay in re-using the 5-tuple,  
as per my e-mail on the subject a week or so ago.

>
>
> 9. Section 17.1, issue #14: "Password change"
>
> TURN, especially when used with SIP, is different from other
> authenticated protocols like HTTP, IMAP, POP in that the allocation  
> can
> have a very long lifetime (excepted when SIP use the charged-by-minute
> model of the PSTN).  So I think that we should define in the spec what
> happen when the password change.
>
> I think that the right solution would be to reject the next Refresh so
> the user is prompted for a new password.  The remaining allocation
> lifetime should be displayed to the user so s/he knows that the
> allocation will expire if s/he does not enter the new password timely.

TURN-07 adopts Rohan's proposal to not say anything about this,  
except that a couple of MUSTs were changed to SHOULDs to allow a  
mechanism to be added.

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

Again, thanks for the comments.

- Philip

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