Subject: Re: [Ietf-behave] Re: I-D ACTION:draft-ietf-behave-turn-00.txt

From: <[email-masked]>
Date: Tue, 21 Mar 2006 08:36:24 -0800 (PST)

Hi,

I have a few comments for the TURN-00:

For TURN usage of STUN the text within this spec does not
yet use consistent terminology. Somewhere it refers the server
as STUN server but in a number of sections as TURN server. 
Further on it mentions TURN clients a number of times. I am
not totally sure how the terminology should be harmonized
but I suggest consistently referring to STUN servers and clients.
The protocol (as STUN usage) might still be referred as TURN.

8.1.1  Server Behavior

   The behavior of the server when receiving an Allocate Request depends
   on whether the request is an initial one, or a subsequent one.  An
   initial request is one whose source and destination transport address
   matches the internal remote and local transport addresses of an
   existing internal 5-tuple.  A subsequent request is one whose source
   and destination transport address do not match the internal remote
   and local transport address of an existing internal 5-tuple.

It should be the other way round: Initial request can not yet match to
any existing 5-tuple, while the subsequent request does.

8.1.1.1  Initial Requests

   If the Allocate request was authenticated using a shared secret
   between the client and server, this credential MUST be associated
   with the allocation.  If the request was authenticated using a short
   term password derived from a shared secret, that shared secret MUST
   be associated with the allocation.

Please clarify the text above. I find the references to "credential"
and "shared secret" to be associated with the allocation as obscure.
My interpreation is that the following formulation would be
equivalent...

   If the Allocate request was authenticated using a shared secret
   between the client and server, this shared secret MUST be associated
   with the allocation.  If the request was authenticated using a short
   term password derived from a shared secret, that short term password
   MUST be associated with the allocation.

... but did I understand it correctly ?

   Allocate Response using the general procedures defined in [1].  The
   transport address allocated to the client MUST be included in the
   RELAY-ADDRESS attribute in the response.  In addition, this response
   MUST contain the MAPPED-ADDRESS attribute.

   Processing of the response follows the general procedures of [1].  A
   successful response will include both a RELAY-ADDRESS and MAPPED-
   ADDRESS attribute, providing both a relayed transport address and a
   reflexive transport address, respectively, to the client. 

   reflects the source IP address and port of the request into the
   MAPPED-ADDRESS (denoted by MA) in the response.  This passes through
   the NAT to the client (8). 

Once again I believe that Allocate Response should contain
XOR-MAPPED-ADDRESS
attribute instead of MAPPED-ADDRESS, to avoid NAT to overwrite its
contents.

Regards,

Erkki
____________________________________

  Erkki Koivusalo
  Nokia Mobile Software
  tel:+358 40 7571197
  mailto:erkki.koivusalo@xxxxxxxxx
____________________________________