Subject: [BEHAVE] Comments on TURN-06

From: Marc Petit-Huguenin <[email-masked]>
Date: Sat, 26 Jan 2008 06:06:45 -0800

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.

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.

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.

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.

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?

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.

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.

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.

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.

Thanks.

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

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