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

From: "Alfred E. Heggestad" <[email-masked]>
Date: Thu, 13 Mar 2008 17:45:48 +0100

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.

> Section 6.2, page 19:
>
>   o  A RELAYED-ADDRESS attribute containing the relayed transport
>      address;
>

This should be "RELAY-ADDRESS"

> 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

> 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.

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?

------------------------------------------------------------------------------
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.

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

---

From: Philip Matthews <[email-masked]>
Date: Wed, 19 Mar 2008 10:01:09 -0400

Thanks for the comments. Here are some quick replies. I am going to  
store your comments and revisit them when I produce TURN-08.

> here are some initial comments on draft-ietf-behave-turn-07..

On behalf of my co-authors: thanks!

> 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"?

> errorcode 438 conflicts with 438 Stale Nonce from rfc3489bis

Thanks for catching this!

> 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.

>          Request, ChannelBind Request, Send Indication, Data  

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).

Yup.

- Philip

---

From: "Alfred E. Heggestad" <[email-masked]>
Date: Fri, 21 Mar 2008 11:59:35 +0100

Philip Matthews wrote:
> 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

> TURN-TCP has not been updated since TURN-05, and thus is a bit out-of-date.
> 

I guess this comment should have been addressed to turn-tcp instead..

I prefer that we use IANA protocol numbers for this field.

>    In addition, the server SHOULD require that all TURN requests use the

OK that should be clear now. thanks for the hint.

/alfred