Subject: [BEHAVE] Version -10 of TURN submitted

From: Philip Matthews <[email-masked]>
Date: Mon, 29 Sep 2008 13:18:19 -0400

I have just submitted version -10 of TURN (draft-ietf-behave-turn).  
There have been quite a few changes since the last version. Most of  
these changes were made to address the concerns that were discussed at  
the last BEHAVE meeting in Dublin. The big technical changes have all  
been mentioned in previous e-mails on the mailing list, so I won't go  
through the motivation for them here.

As far as I know, all the outstanding issues and concerns about TURN  
have been addressed in this version.

The only niggling little issue that I know of is the current  
discussion on the mailing list about CreatePermission vs. ChannelBind  
for refreshing permissions and the related question of whether  
channels should have the same lifetime as permissions. This version of  
the spec allows both CreatePermission and ChannelBind to refresh  
permissions, and keeps the channel lifetime at 10 minutes vs the  
permission lifetime of 5 minutes. I view this as "status quo", and I  
am still waiting for more people to comment on this before making any  
changes.

A complete list of all changes between version -09 and -10 is included  
below and can also be found in section 20.1 of the document.

- Philip

20.1.  Changes from -09 to -10

    o  Changed the recommendation for using the SOFTWARE attribute.
       Previously its use was recommended in all requests and responses;
       now it is only recommended in Allocate and Refresh requests and
       responses, though it may appear elsewhere.  Also, version -09
       incorrectly referred to this attribute as "SOFTWARE-TYPE".

    o  Changed the name of the PEER-ADDRESS and RELAYED-ADDRESS
       attributes to XOR-PEER-ADDRESS and XOR-RELAYED-ADDRESS
       respectively for consistency with other specifications.

    o  Removed the concept of a "preserving" allocation.  All  
allocations
       are now non-preserving.  This simplifies the base specification
       and allows it to advance more rapidly; see the discussion in the
       BEHAVE meeting of 29 July 2008.  The concept of a preserving
       allocation will be advanced as an extension to TURN.  As part of
       this change, the P bit in the REQUESTED-PROPS attribute, the ICMP
       attribute, and ICMP message relaying was removed.  Further, in
       Section 12, the preferred behaviors were removed, leaving the
       alternate behaviors as the specified behaviors.

    o  Replaced the REQUESTED-PROPS attribute with the EVEN-PORT
       attribute.  The new attribute lacks the feature of the old
       attribute of being an alternate way to specify new allocation
       properties.  As a consequence, the only way to specify a new
       allocation property is to define a new attribute.

    o  Added text recommending that the client check that the IP address
       in XOR-PEER-ADDRESS attribute in a received Data indication is  
one
       with which the client believes there is an active permission.
       Similarly, it is recommended that the client check that a
       permission exist when receiving a ChannelData message.

    o  Added text recommending that the client delete the allocation if
       it receives a ChannelBind failure response on an unbound channel.

    o  Added the CreatePermission request/response transaction which  
adds
       or updates permissions, and removed the ability for Send
       indications and ChannelBind messages to install or update
       permissions.  The net effect is that only authenticate-able
       messages (i.e., CreatePermission requests and ChannelBind
       requests) can install or refresh permissions; unauthenticate-able
       Send indications and ChannelData messages do not.

    o  Removed all support for IPv6.  All IPv6 support, including ways  
of
       relaying between IPv4 and IPv6, will now be covered in
       [I-D.ietf-behave-turn-ipv6].

    o  Reserved attribute code point 0x0021.  This was previously used
       for the TIMER-VAL attribute, which was removed when the
       SetActiveDestination feature was removed.

    o  Added the DONT-FRAGMENT attribute which allows the client to
       request that the server set the DF bit when sending the UDP
       datagram to the peer.  This attribute may appear in both Allocate
       requests and Send indications.

    o  Changed how the ALTERNATE-SERVER attribute is used.  The  
attribute
       can no longer be used with any error code, but must be used with
       300 (Try Alternative).  It can now appear in unauthenticated
       responses, however there are restrictions around how the
       subsequent Allocate request is authenticated.

    o  Reworked the details of how idempotency of requests is handled,
       making it clear that the stack can either remember all
       transactions for 40 seconds, or can handle this using the so-
       called "stateless stack approach".  Made some changes to the
       semantics of the Allocate, Refresh, and ChannelBind requests as a
       consequence.

    o  Added the requirement that a client cannot re-use previously  
bound
       channel number or transport address until 5 minutes after the
       channel binding expires.  This avoids various race conditions.

    o  Removed the requirement that an allocation cannot be re-used
       within 2 minutes of having been deleted.  This requirement was  
put
       in place to prevent mis-delivered packets but is no longer seen  
as
       having any real value.

    o  Added a recommendation that the server impose quotas on both the
       number of allocations and the amount of bandwidth a given  
username
       can use at one time.  These quotas help protect against denial- 
of-
       service attacks.

    o  Completely rewrote the security considerations section.

    o  Made quite a few changes to the descriptive text in both the
       Overview and the normative text to try to further clarify
       concepts.

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