Subject: Re: [BEHAVE] Comments on draft-ietf-behave-turn-07

From: Philip Matthews <[email-masked]>
Date: Sat, 12 Jul 2008 14:56:36 -0400

An update on this. See inline.
- Philip

On Fri, 21-Mar-08, at 06:59 , Alfred E. Heggestad wrote:
> Philip Matthews wrote:
>> Thanks for the comments. Here are some quick replies. I am going to
>> store your comments and revisit them when I produce TURN-08.
>>
>>
>> On Thu, 13-Mar-08, at 12:45 , Alfred E. Heggestad wrote:
>>
>>> Hi
>>>
>>> here are some initial comments on draft-ietf-behave-turn-07..
>>>
>>> /alfred
>>>
>>>
>>> --------------------------------------------
>>> Comments on draft-ietf-behave-turn-07..
>>>
>>>
>>> by Alfred E. Heggestad <[email-masked]>
>>> 13. March 2008
>>>
>>>
>>>
>>>
>>> General:
>>>
>>> This document is very well written, and very easy to read from an
>>> implentation
>>> perspective. The new channel binding mechanism is also much more
>>> flexible and
>>> powerful than the old 'Set Active Destination'-hack. Many thanks to
>>> the authors
>>> for cleaning up this important document.
>>
>> On behalf of my co-authors: thanks!
>>
>>>
>>>
>>>
>>>
>>>> Section 6.2, page 19:
>>>>
>>>>  o  A RELAYED-ADDRESS attribute containing the relayed transport
>>>>     address;
>>>>
>>>
>>> This should be "RELAY-ADDRESS"
>>
>> This points out an inconsistency I had not noticed before. The text  
>> now
>> consistently uses the term "relayed transport address" (note the "- 
>> ed"),
>> which is consistent with ICE. But this is called RELAY-ADDRESS  
>> (without
>> the "-ed"). Perhaps this attribute should be renamed to "RELAYED- 
>> ADDRESS"?
>>
>>
>
> ice-19 section 4.1.1.2:
>
>   "in the RELAY-ADDRESS attribute.  If the Allocate request is  
> rejected"
>
>
> keeping it as "RELAY-ADDRESS" is fine by me

I have changed the name of the "RELAY-ADDRESS" attribute (0x0016) to  
"RELAYED-ADDRESS" and have asked Jonathan to update the ICE spec.

>
>
>
>>>
>>>
>>>
>>>
>>>> 14.  New STUN Error Response Codes
>>>>
>>>>  438  (Wrong Credentials): The credentials in the (non-Allocate)
>>>>     request, though otherwise acceptable to the server, do not  
>>>> match
>>>>     those used to create the allocation.
>>>
>>> errorcode 438 conflicts with 438 Stale Nonce from rfc3489bis
>>
>> Thanks for catching this!

The "Wrong Credentials" error now has codepoint 441.

>>
>>
>>>
>>>
>>>
>>>
>>>> 13.8.  REQUESTED-TRANSPORT
>>>>
>>>>  ...[Protocol-Numbers].  This specification only allows the use of
>>>>     codepoint 17 (User Datagram Protocol).
>>>
>>> This is in conflict with turn-tcp which defines:
>>>
>>>      0x0000 0000: UDP
>>>      0x0000 0001: TCP
>>>
>>> I think codepoints 17 (UDP) and 6 (TCP) should be used.
>>
>>
>> This was a change introduced in TURN-06. The spec used to use 0 and 1
>> for UDP and TCP, but now uses their IANA protocol numbers instead.
>> TURN-TCP has not been updated since TURN-05, and thus is a bit out- 
>> of-date.
>>
>> If anyone else has any comments on this change (from 0/1 to IANA
>> protocol numbers), I would be interested in hearing them.
>>
>
> I guess this comment should have been addressed to turn-tcp instead..
>
> I prefer that we use IANA protocol numbers for this field.

No change made here.

>
>
>
>>>
>>>
>>>
>>>
>>> General: It is not clear which methods require MESSAGE-INTEGRITY.
>>>         Obviously the Allocate Request needs it, but what about  
>>> Refresh
>>>         Request, ChannelBind Request, Send Indication, Data  
>>> Indication?
>>
>> Hmmm. I thought it would be clear from:
>>
>>   In addition, the server SHOULD require that all TURN requests use  
>> the
>>   Long-Term Credential mechanism described in
>>   [I-D.ietf-behave-rfc3489bis], and the client MUST be prepared to
>>   authenticate requests if required.
>>
>> Anyway, the answer is that all requests SHOULD use the Long-Term
>> Authentication scheme from STUNbis, but indications do not use this
>> scheme. (STUNbis says that the scheme is not used with indications
>> because there is no way to challenge an indication).
>>
>
> OK that should be clear now. thanks for the hint.

Great.

>
>
>
> /alfred
>
>>
>>>
>>>
>>>
>>>
>>> ------------------------------------------------------------------------------
>>>
>>> NITS
>>>
>>>
>>> General:
>>>
>>> There is a mix of "Allocate request" and "Allocate Request" in the
>>> document. This term should be consistantly used, and either stick
>>> to one of them.
>>
>> Yup.

The text now consistently uses "request", "response", and  
"indication", except in headings, error code names, and similar.

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

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