Subject: [BEHAVE] TURN-13 posted

From: Philip Matthews <[email-masked]>
Date: Tue, 24 Feb 2009 21:14:39 -0500

I have just posted version 13 of the TURN specification (draft-ietf- 
behave-turn-13). This version addresses the comments received during  
IETF Last Call.

Substantive changes from -12 to -13:

* Added a new error code: 403 (Forbidden), and specified that this  
error code is returned when the server processes a CreatePermission or  
ChannelBind request and decides that it wishes to reject the supplied  
IP address and port combination for administrative reasons. Version  
-12 did not specify an error code to use in this situation, and none  
of the existing error codes seemed appropriate. (Thanks to Magnus and  
others for catching this)

* In the IANA considerations section, added a request to IANA to  
establish a registry for channel numbers. This originally seemed  
unnecessary to me, given the nature of channel numbers, but enough  
people asked about this, so I went ahead and did it.

* Clarified the usage of the nonce value in the Long-Term Credential  
Mechanism: a new random nonce SHOULD be selected for each Allocate  
attempt, and the nonce SHOULD be expired at least once every hour.  
Also referenced RFC 4086 for guidelines on selecting the nonce value.

In addition to these technical changes, there are a number of  
editorial changes that either fixed typos or that cleaned up the  
presentation in various places.

There were two notable proposed changes that did NOT make it into this  
version:
* A request to add support for relaying ICMP messages, and
* A request to change the lifetime of a channel binding from 10  
minutes to 5 minutes.
Neither change gathered enough WG support to be added.

Many thanks to everyone who submitted comments.

Submitting this version of TURN was a bit of a challenge, given all  
the IPR boilerplate and related tool issues. TURN is produced using  
Bill Fenner's xxe plug-in for XMLMind and the on-line conversion tool  
at xml.resource.org, neither one of which was updated at the time of  
submission. Thanks to Cullen for figuring out how to produce an I-D  
that includes the necessary clause about pre-Nov10 text and which  
passes the idnits tool, and to Dan for pointing me at Cullen's  
instructions. It is ironic that all this blew up for version -13,  
especially since this version is likely the one that will go to IESG  
evaluation.

- Philip

---

From: Christian Huitema <[email-masked]>
Date: Thu, 26 Feb 2009 23:41:46 -0800

Just a nit, but the coding of the "Even-Port" parameter is described as single byte in section 14.6. EVEN-PORT, page 45. Should I understand correctly that the parameter's value should in fact be padded to a 32 bit word boundary, following STUN conventions?

-- Christian Huitema

---

From: Philip Matthews <[email-masked]>
Date: Fri, 27 Feb 2009 20:39:09 -0500

On Fri, 27-Feb-09, at 02:41 , Christian Huitema wrote:

> Just a nit, but the coding of the "Even-Port" parameter is described  
> as single byte in section 14.6. EVEN-PORT, page 45. Should I  
> understand correctly that the parameter's value should in fact be  
> padded to a 32 bit word boundary, following STUN conventions?
>
>
> -- Christian Huitema
>

Yes. The rules of section 15 of RFC5389 must be followed:

    The value in the length field MUST contain the length of the Value
    part of the attribute, prior to padding, measured in bytes.  Since
    STUN aligns attributes on 32-bit boundaries, attributes whose  
content
    is not a multiple of 4 bytes are padded with 1, 2, or 3 bytes of
    padding so that its value contains a multiple of 4 bytes.  The
    padding bits are ignored, and may be any value.

The last bit applies to the EVEN-PORT and DATA attributes of TURN.

I suppose we could include a sentence in the spec saying this  
explicitly, even though the TURN spec does say (section 4):

    TURN is an extension to STUN.  All TURN messages, with the exception
    of the ChannelData message, are STUN-formatted messages.  All the
    base processing rules described in [RFC5389] apply to STUN-formatted
    messages.  This means that all the message-forming and -processing
    descriptions in this document are implicitly prefixed with the rules
    of [RFC5389].

- Philip