Subject: [BEHAVE] Review of draft-ietf-behave-turn-06

From: Eric Rescorla <[email-masked]>
Date: Sat, 26 Jan 2008 15:29:20 -0800

$Id: draft-ietf-behave-turn-06-rev.txt,v 1.1 2008/01/26 23:08:30 ekr Exp $

TECHNICAL
S 4.
The ALTERNATE-SERVER stuff seems problematic for the reasons
Cullen indicates. If you're overloaded, better ot simply not
handle the request and let ordinary H-A methods take over.

S 5.1.1.
   If the response is an error response and contains a 442, 443 or 444
   error code, the client knows that its requested properties could not
   be met.  The client MAY retry with different properties, with the
   same properties (in a hope that something has changed on the server),
   or give up, depending on the needs of the application.  However, if
   the client retries, it SHOULD wait 500ms, and if the request fails
   again, wait 1 second, then 2 seconds, and so on, exponentially
   backing off.

I don't see the purpose of this. This kind of backoff is gnenerally
used for congestion control, but if you're getitng errors you know
that the packets weren't lost, so why back off?

S 5.1.2.
This 3/4 guidance seems like it's inappropriate in a number of
respects. Why not simply indicate that clients need to leave
some time for the refresh.

The idea of refreshing with different bandwidth requested
seems problematic. What happens if the server refuses? Do you
need to refresh again with a lower bandwidth if you're willing
to live with that? A policy that refreshes didn't change anything
seems more sensible.

S 5.2.1.
   o  If the transport protocol is UDP, and the transaction id in the
      request message matches the transaction id used for the original
      allocation, then the server treats this as a retransmission of the
      original request, and replies with the same response as it did to
      the original request.  The server may do this by either storing
      its original response and resending it, or by rebuilding its
      original response from other state data.

This is a new requirement that's not in STUN (The stun reqt is 10
seconds) and seems impractical to implement. If I throw an error on a
transaction, how long do I need to be willing to return the same
error? Forever?  What seems appropriate here is that as long as an
allocation exists (And maybe for X seconds afterward) you need
to return the same response. 

S 5.2.1.1.
   If it does, the server attempts to allocate a transport address for
   the client.  The Allocate Request can contain several additional
   attributes that allow the client to request specific characteristics
   of the transport address.  If it doesn't, it sends an error response.

What error?

S 5.2.1.4.
So, I get that you would want an even port for RTP and consecutive
ports for RTP/RTCP, but are there any implementations which
need arbitrary odd ports?

S 6.3.
This section contains way too much information about the UDP datagram
(Length, Checksum...)  It should simply specify that a UDP datagram
with the following contents is sent to the following location as per
standard procedure.

S 7.7.
   When the server receives a valid ChannelData message, it forms a UDP
   datagram as follows: the source transport address is the relayed
   transport address of the allocation, where the allocation is
   determined by the 5-tuple on which the ChannelData message arrived;
   the destination transport address is the peer address to which the
   channel is bound; the data following the UDP header is the contents
   of the data field of the ChannelData message; the Length field in the
   UDP header is set to the Length field of the ChannelData message + 8;
   and the Checksum field in the UDP header is computed as described in

Again, too much information about the UDP header..

EDITORIAL
Abstract:
Is TURN really "more properly" used as part of ICE?

S 1.
   The only way to obtain a UDP transport address that can be used for
   corresponding with a peer through such a NAT is to make use of a
   relay.    

Well, actually, the only reliable way. You mgiht guess correctly.

S 2.5.
   the client can determine the peer that send the UDP datagram.

s/send/sends/

S 4.
   After the initial Allocate transaction, all subsequent TURN
   transactions need to be sent in the context of a valid allocation.
   The source and destination IP address and ports for these TURN
   messages MUST match the those used in the initial Allocate Request.

I'm not sure what "in the context means". The seconds sentence seems
clearer.

S 5.2.1.7.
This section would be imroved by having the required attributes being
a bulleted list.

S 6.
Merging send and data indications (which are basically unrelated) into
a single section is really confusing. It would be better to give them
separate sections.

There should be some explicit statement of what missing DATA attributes
are for (keepalives).

S 7.
   As described in the overview, channel mechanism provides a way for a
   client and server to send application data using ChannelData

s/channel mechanism/the channel mechanism/

S 7.1.

   Over UDP, the client SHOULD NOT send ChannelData messages on the
   channel until it has received a ChannelBind Success Response for the
   binding attempt.  Sending them before the success response is
   received risks having them dropped by the server if he ChannelBind
   Request was lost.

I think we discussed this onlist.

S 11.
   discovery.  As a consequence, TURN runs on a separate port from STUN.
   The client discovers the address and port of the TURN server using
   the same DNS procedures defined in [I-D.ietf-behave-rfc3489bis], but
   using an SRV service name of "turn" (or "turns" for TURN over TLS)

Didn't we get rid of separate ports?

S 12.
   TURN cannot be used by clients for subverting firewall policies.

This is untrue, as acknowledged in the section on using TLS.

-Ekr

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