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

From: "Alfred E. Heggestad" <[email-masked]>
Date: Fri, 31 Aug 2007 00:22:24 +0200

Comments on draft-ietf-behave-turn-04

Technical Review
by Alfred E. Heggestad <[email-masked]>
30. Aug 2007

General:

- Did we consider the scenario where the NAT between the TURN client and the
   TURN server reboots? In such a case both TURN client and server will still
   send and receive data (such as RTP), and if NAT in between reboots, a new
   NAT mapping will be created. The TURN server will not be able to update the
   5-tuple for the "flow" and the result is no RTP data send/received. If we
   can use some kind of unique "Session ID" for the TURN allocation, it will
   still be possible to handle the cases where the NAT reboots. On Allocate
   Request the client could choose a unique 64-bit session ID, which will be
   used in all future communications with the server (for that session).
   Alternatively, the TURN server could keep track of all session IDs, and
   allocate it for the client (returned in Allocate Response). All sub-
   sequent TURN messages from the client will then contain this 64-bit
   session ID, and the TURN server can lookup the allocation (Session) without
   looking at the Source IP+port. Now, this will probably also introduce some
   new security issues..

- Why is the FINGERPRINT attribute not mentioned at all in TURN ?

- There are still references to "Shared Secret request", in section 6.1.1.1
   and 6.1.1.2. This is removed in rfc3489bis-08 and should also be removed
   in TURN

- The BANDWIDTH parameter is a bit problematic, since the TURN allocation
   is normally done before an SDP Offer is sent. If a user-agent is sending
   an SDP offer with audio codecs G.711 (64 kbps) and G.729 (8 kbps) it will
   use the highest bandwidth (64 kbps) to the TURN server. When the call is
   established with G.729, it should be possible to send an update to the
   TURN server, telling it that the bandwidth need changed to 8 kbps

 > Section 4
 >
 >   When the TURN client to server communication is over a datagram
 >   protocol (UDP), any datagram received from the active peer that has
 >   the STUN magic cookie is wrapped in a Data Indication.  Likewise any
 >   datagram sent by the client that has the STUN magic cookie and is
 >   intended for the active peer is wrapped in a Send Indication.  This
 >   wrapping prevents the STUN relay server from inappropriately
 >   interpreting end-to-end data.

Does this mean that the TURN client/server has to scan the whole datagram
looking for the STUN magic cookie? I think not, and I would assume that
it only need to check the 20 first bytes of the datagram.

 > Section 6.2
 >
 >   Response with an appropriate error response code, such as a 431
 >   (Integrity Failure) or 436 (Unknown User).

error codes 431 and 436 are no longer in rfc3489bis-09

 > 6.5.  Connection Status Indication
 >
 >    When the TURN to peer leg is TCP, the TURN client needs to be aware
 >    of the status of these TCP connections.  The TURN extension defines
 >    application states for a TCP connection as follows: LISTEN,
 >    ESTABLISHED, CLOSED.  Consequently, the TURN server sends a

Probably a new state should be defined, if the TCP connection failed
(host unreachable, port unreachable)

 > 7.9.  CONNECT_STAT
 >
 >  This attribute is used by...

It should be mentioned which TURN Requests/Responses/Indications this
attribute is valid for.

 >  17.2.  Informative References
 >

Should be updated:

[1]  draft-ietf-behave-rfc3489bis-06 -> draft-ietf-behave-rfc3489bis-09

[8]  draft-ietf-mmusic-ice-16        -> draft-ietf-mmusic-ice-16

[9]  draft-ietf-behave-nat-udp-08    -> RFC 4787

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

 > Abstract
 >
 >  ..Relays around NAT (TURN), is useful for elements behind NATs whose
 >    mapping behavior is address and port dependent.  The extension..
                          ^^^^^^^^^^^^^^^^^^^^^^^^^^

TURN is also useful for elements behind "Address-Dependent Mapping" NATs,
right? Ideally this should be written "..whose mapping behavior is NOT
Endpoint-Independent Mapping.."

Terminology from RFC 4787:
     -  Endpoint-Independent Mapping:
     -  Address-Dependent Mapping:
     -  Address and Port-Dependent Mapping:

 > 6.1.1.1.  Initial Requests
 >
 >   ...
 >   adajacent pair, even and odd respectively, for compatibility with a
     ^^^^^^^^^

typo, should be "adjacent"

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