Subject: [BEHAVE] Version -12 of TURN submitted

From: Philip Matthews <[email-masked]>
Date: Sun, 30 Nov 2008 11:47:50 -0500

I have just submitted version -12 of the TURN specification: draft- 
ietf-behave-turn-12. This version contains updates prompted by the  
comments received during the WGLC period, which ended on Friday.

The authors thank everyone who send comments during the WGLC period. I  
have replied to all e-mails received during that period, and have  
either describing the changes made to the document, or have explaining  
why I didn't think a change was necessary.

If there is anyone who has not had a chance to send me comments yet,  
feel free to send them  anyway. The IETF last call will hopefully  
start soon, and I plan to issue another version after that last call  
period is finished.

A list of the changes made to the document can be found below, and is  
also included in section 21 of the document.

- Philip

21.1.  Changes from -11 to -12

    o  Changed the port numbers used in the examples for the client, the
       peers, and the relayed-transport-address to put them in the
       Dynamic port range.  They were previously in the Registered port
       range, which was arguably unrealistic.

    o  Noted that the XOR-MAPPED-ADDRESS attribute is defined in RFC
       5389.

    o  Used the codepoint names (Not-ECT, ECT(0), ECT(1), and CE) when
       talking about the ECN field.

    o  Updated the Introduction to note that the client must not only
       communicate its relayed-transport-address to the peers, but also
       learn the peers' server-reflexive transport addresses.  As a
       result, removed the suggestion that the client could use a  
webpage
       to communicate with its peers.

    o  Added a description of the "TURN Loop attack" and its mitigation
       to the Security Considerations section.

    o  Fixed some errors in the examples in the Overview section.  They
       had not been updated to be consistent with the change introduced
       in version -11 that a permission must be created before a client
       can send data to a peer.

    o  In the Additional Features subsection of the Overview, reworded
       the discussion of what end-to-end features are preserved by TURN.
       The previous text said that a number of features did not work,  
but
       as of version -11, these features _may_ work.  At the same time,
       added a sentence noting that any Path MTU Discovery mechanism
       using the DONT-FRAGMENT attribute will not receive ICMP messages
       and will thus have to use techniques like those described in
       [RFC4821].

    o  Added the recommendation that, when TCP transport is used between
       the client and the server, both ends should close the connection
       if they notice a long sequence of invalid TURN messages.  A  
likely
       cause of this is an undetected bit error corrupting a length  
field
       somewhere.

    o  Reworded the paragraph explaining that channel bindings are per-
       allocation to further stress this point.

    o  In the discussion on setting the fragmentation fields, added a
       sentence saying that the client or server should follow the  
normal
       rules for fragmentation as described in [RFC1122].

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