Subject: [BEHAVE] TURN-09 posted

From: Philip Matthews <[email-masked]>
Date: Sat, 12 Jul 2008 19:10:24 -0400

I have just posted TURN-09. This version fixes a lot of small- to  
medium-sized things that have been raised on the mailing list or e- 
mailed to me privately. The biggest fixes are addition of text  
defining the ICMP attribute, and changing the codepoint for "Wrong  
Credentials" from 438 to 441 to avoid the conflict with "Stale Nonce".  
I have included the complete list of changes below and they are also  
in the draft.

There are still a number of outstanding issues in TURN. I plan to try  
to address these issues shortly. I have listed the outstanding issues  
below and also included them in the draft.

Again, my apologies for the fact that TURN is not finished yet.

- Philip

Changes between TURN-08 and TURN-09:
    o  Added text to properly define the ICMP attribute.  This attribute
       was introduced in TURN-08, but not fully defined due to an
       oversight.  Clarified that the attribute can appear in a Data
       indication, but not a Send indication.  Added text to the section
       on receiving a Data indication that points out that this  
attribute
       may be present.

    o  Changed the wording around the handling of the DSCP field to  
allow
       the server to set the DSCP to an arbitrary value if the next hop
       is a Diff-Serv classifier and marker.

    o  When the server generates a 508 response due to an unsupported
       flag in the REQUESTED-PROPS attribute, the server now includes  
the
       REQUESTED-PROPS attribute in the response with all the flags it
       supports set to 1.  This allows the client to see if the server
       does not understand one of its flags.  Similarly, the client is
       now allowed to immediately retry the request if it modifies the
       included REQUESTED-PROPS attribute.

    o  Clarified that the REQUESTED-PROPS attribute can be used in
       conjunction with the RESERVATION-TOKEN attribute as long as both
       the E and R bits are 0.  The spec previously contradicted itself
       on this point.

    o  Clarified that when the server receives a ChannelData message  
with
       a length field of 0, it sends a UDP Datagram to the peer that
       contains no application data.

    o  Rewrote some text around relaying incoming UDP Datagrams to avoid
       duplication of text in the Data indication and Channel sections.

    o  Added a note that points out that the on-going work on  
randomizing
       port allocations [I-D.ietf-tsvwg-port-randomization] may be
       applicable to TURN.

    o  Clarified that the Allocate request containing a RESERVATION- 
TOKEN
       attribute can use any 5-tuple, and that 5-tuple need not have any
       specific relationship to the 5-tuple of the Allocate request that
       created the reservation.

    o  Added a note that discusses retransmitted Allocate requests over
       UDP where the first request receives a failure response, but the
       second receives a success response.  The server may elect to
       remember transmitted failure responses to avoid this situation.

    o  Added text about the usage of the SOFTWARE-TYPE attribute
       (formerly known as the SERVER attribute) in TURN messages.

    o  Rewrote the text in the Overview that motivates why TURN supports
       TCP and TLS between the client and the server.  The previous text
       had been identified by various readers as inadequate and
       misleading.

    o  Rewrote the section how a server handles a Refresh request to
       clarify processing in various error conditions.  The new text
       makes it clear that it is OK to delete a non-existent allocation.
       It also clarifies how to handle retransmissions of Refresh
       requests over UDP.

    o  Renamed the "RELAY-ADDRESS" attribute to "RELAYED-ADDRESS", since
       the text consistently uses the term "relayed transport address"
       for the concept and ICE uses the term "relayed candidate".

    o  Changed the codepoint assigned to the error code "Wrong
       Credentials" from 438 to 441 to avoid a conflict with the "Stale
       Nonce" error code of STUN.

    o  Changed the text to consistently use non-capitalized "request",
       "response" and "indication", except in headings, error code  
names,
       etc.

    o  Added a note mentioning that TURN packets can be demuxed from
       other packets arriving on the same socket by looking at the
       5-tuple of the arriving packet.

    o  Clarified that there are no required attributes is a ChannelBind
       success response.

Outstanding open issues in TURN-09:
    1.  Detecting in-use channels.  Do we need a way for a client to
        determine if a channel is currently bound?  Right now, the only
        way is to try to bind it to an address.

    2.  Public TURN servers.  The spec currently hints (but does not say
        anything solid) that the way to run a publicly-accessable TURN
        server is to not require authentication.  But perhaps a better
        way is to require authentication but have some unspecified  
method
        to allow any user to create an account on the server.

    3.  IPv6.  Currently, TURN supports IPv4-to-IPv4 relaying, and IPv6-
        to-IPv6 relaying, but does not support IPv4-to-IPv6 relaying.   
To
        ensure this, a server requires that the family of the relayed
        address match that of the 5-tuple as seen by the server.
        However, some people would like to see a different rule.

    4.  ALTERNATE-SERVER and Anycast.  The details of ALTERNATE-SERVER
        support are still under discussion.  In particular, some people
        would like to use ALTERNATE-SERVER to support anycast discovery
        of a TURN server.

    5.  Authenticated Permission Refresh.  Currently, permissions can be
        refreshed by unauthenticated Send indications and ChannelData
        messages.  Some have suggested that this is a security issue.

    6.  PMTUD for non-preserving allocations.  Some people would like a
        way to do PMTUD even if the allocation is non-preserving, and
        have suggested that a way for the client to indicate to the
        server (in a Send indication) that the DF bit should be set when
        sending to the peer might allow this.

    7.  Security.  The security consideration section is out-of-date  
with
        the changes to the rest of the draft, and it has been suggested
        that TURN might require TLS to provide proper security.   
Updating
        the security consideration section will answer this question.

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