Subject: Re: [BEHAVE] DISCUSS and COMMENT: draft-ietf-behave-turn

From: Philip Matthews <[email-masked]>
Date: Tue, 7 Apr 2009 23:47:00 -0400

[Added BEHAVE to the CC line]

Hi Robert:

See comments inline.

On Tue, 7-Apr-09, at 11:54 , Robert Sparks wrote:

> Discuss:
> In section 11.2, I'm not finding where it's explicitly specified  
> what the lifetime of a Permission established by a ChannelBind is. I  
> think both the server and client are expected to use the lifetime of  
> the ChannelBind as the lifetime of the Permission, but this should  
> be explicitly stated.

Actually, the lifetime of a Permission is the same (5 minutes) no  
matter how it is created. This is explained in section 8. To make this  
clearer, in section 11.1, when it says:

    A channel binding is created or refreshed using a ChannelBind
    transaction.  A ChannelBind transaction also creates or refreshes a
    permission towards the peer.

I have added a "(see section 8)" after "peer" to remind the reader to  
check section 8.

>
>
> ----
>
> The text defining how the lifetimes of permissions and allocations  
> are established say to use either the value requested by the client,  
> or the default lifetime (see the bottom of page 25, top of page 26  
> for example). The example shows the server choosing a value (20  
> minutes) between those. Was the intent of the normative text to  
> allow the server to choose any value between the default and  
> requested value, or only the endpoints?

Good catch! The normative text at bottom-25/top-26 does not clearly  
handle the case where the client asks for a lifetime greater than the  
maximum value the server will allow. The intention is to allow the  
server to reduce the client's requested lifetime to the maximum value  
that the server will allow, provided that the result is greater than  
the default lifetime. This is sort-of described in the text, but not  
very well.

To fix this, I have changed this paragraph to read as follows:

     The server determines the initial value of the time-to-expiry
     field as follows. If the request contains a LIFETIME attribute,
     then the server computes MIN(client's proposed lifetime, server's
     maximum allowed lifetime). If this computed lifetime is greater
     than the default lifetime, then the server uses that value.
     Otherwise, the server uses the default lifetime. It is RECOMMENDED
     that the server use a maximum allowed lifetime value of no more
     than 3600 seconds (1 hour). Servers that implement allocation
     quotas or charge users for allocations in some way may wish to
     use a smaller maximum allowed lifetime (perhaps as small as the
     default lifetime) to more quickly remove orphaned allocations
     (that is, allocations where the corresponding client has crashed
     or terminated or the client connection has been lost for some
     reason). Also note that the time-to-expiry is recomputed with
     each successful Refresh request, and thus the value computed here
     applies only until the first refresh.

I have also changed the text in section 7.2 (Receiving a Refresh  
Request), which was also unclear. This text now reads:

     The server computes a value called the "desired lifetime" as
     follows: If the request contains a LIFETIME attribute and the
     attribute value is 0, then the "desired lifetime" is 0. Otherwise,
     if the request contains a LIFETIME attribute, then the server
     computes MIN(client's requested lifetime, server's maximum allowed
     lifetime). If this computed value is greater than the default
     lifetime, then the "desired lifetime" is the computed value.
     Otherwise the "desired lifetime"  is the default lifetime.

Note that both of these paragraphs refer only to the lifetime of the  
Allocation. A permission lifetime cannot be changed by the client and  
is always 5 minutes. You may have gotten the idea that the lifetime of  
a permission was modifiable because the text in section 8 uses the  
term "default permission lifetime". To make this clearer, I have  
changed this term to "Permission Lifetime".

>
>
> ----
>
> I think there is an unintended problem in the way the processing for  
> Allocate requests is spelled out on pages 23 and 24. As written, a  
> request that contains both a RESERVATION-TOKEN and an EVEN-PORT  
> attribute that the server couldn't satisfy, step 5 will cause a 508  
> error (which will lead to the client trying the same request again).  
> The intended check to reject this with a 400 doesn't occur until  
> step 6.

Another good catch! To fix this, I have swapped the order of steps 5  
and 6. This will catch this case and return a 400 Bad Request, while  
not introducing an externally visible change when this error does not  
occur. (In fact, it makes more sense to check for RESERVATION-TOKEN  
before checking for EVEN-PORT). For consistency, I have also re- 
arranged the bullets describing how the server chooses the relayed- 
transport-address to put the RESERVATION-TOKEN case first.

>
>
> ----
>
> Should the text in 17.2.3 say that the TURN server will never accept  
> traffic from a peer which the client has not installed a permission  
> for, rather than which the client has not yet contacted?

Yes. I have changed this to say "from a peer for which the client has  
not installed a permission."

>
>
> Comment:
> There are several invariant times called out in this document  
> without motivation (default lifetimes MUST be 300 seconds, clients  
> SHOULD wait at least one minute before doing some things and MUST  
> wait 5 minutes before doing others). It would be nice to let the  
> implementors know, if possible, why these values were chosen.

I have added text in the Overview of Operation section to say:
* The default allocation lifetime of 10 minutes was chosen to be long  
enough not to be a burden to refresh, but short enough to expire  
allocations quickly when a client quits unexpectedly. This value can  
be increased on request by the client.
* The permission lifetime is 5 minutes and this value was chosen to be  
consistent with the recommended behavior of RFC4787.
* The channel lifetime permission is 10 minutes, and this value was  
chosen to be greater than the permission lifetime.

>
>
> The text in the NOTE on page 25 will not age well after this is  
> published as an RFC

This text was carefully crafted to call the reader's attention to the  
randomized port work without introducing another normative dependency  
that would further delaying TURN (and thus ICE, which has been sitting  
in the RFC Editor queue for 1.5 years now). The text was added as a  
result of a comment by a reviewer, who thought a TURN implementor  
should be aware of this work. Do you have a suggestion for an  
alternative wording that would age better?

- Philip