Subject: Re: [BEHAVE] TURN-13 posted

From: Christian Huitema <[email-masked]>
Date: Sun, 1 Mar 2009 18:14:13 -0800

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

I found that part of the specification (and STUN) somewhat confusing. For example, we get "even port" specified as:
      0
      0 1 2 3 4 5 6 7
     +-+-+-+-+-+-+-+-+
     |R|    RFFU     |
     +-+-+-+-+-+-+-+-+

While the 8 bit transport type (requested transport) is specified as:
      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |    Protocol   |                    RFFU                       |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Do I understand correctly that the "attribute length" field shall be set to 1 byte for Even-Port, and to 4 bytes for "requested-transport"? The specification would be clearer, and would prevent potential implementation mistakes, if the attribute descriptions mentioned explicitly the value of the attribute length.

If that is so, what is the rationale for the encoding of the requested transport? Why not simply specify:

      0
      0 1 2 3 4 5 6 7
     +-+-+-+-+-+-+-+-+
     |    Protocol   |
     +-+-+-+-+-+-+-+-+

And let the T-L-V encoded do the padding?

---

From: Sebastien Vincent <[email-masked]>
Date: Mon, 09 Mar 2009 09:50:18 +0100

Hello folks,

A new version of TurnServer is available (turnserver-0.2.2) on 
sourceforge (https://sourceforge.net/project/showfiles.php?group_id=234986).

In two word it add support for turn-13 specification and experimental 
multiple uplink interfaces support (warning: configuration file syntax 
have changed for listen_address and listen_addressv6).

Regards,
--
Sebastien Vincent
http://www.turnserver.org
https://sourceforge.net/projects/turnserver/

Philip Matthews a écrit :
> 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
>
>
> _______________________________________________
> Behave mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/behave
>

---

From: Philip Matthews <[email-masked]>
Date: Sat, 21 Mar 2009 12:54:11 -0400

Christian:

My apologies for the slow reply. For some reason, this message did not  
reach my Inbox, and I found it only when looking through the BEHAVE  
list.

Replies inline.

- Philip

On Sun, 1-Mar-09, at 21:14 , Christian Huitema wrote:

> I found that part of the specification (and STUN) somewhat  
> confusing. For example, we get "even port" specified as:
>      0
>      0 1 2 3 4 5 6 7
>     +-+-+-+-+-+-+-+-+
>     |R|    RFFU     |
>     +-+-+-+-+-+-+-+-+
>
> Do I understand correctly that the "attribute length" field shall be  
> set to 1 byte for Even-Port, and to 4 bytes for "requested- 
> transport"? The specification would be clearer, and would prevent  
> potential implementation mistakes, if the attribute descriptions  
> mentioned explicitly the value of the attribute length.
>
>
> If that is so, what is the rationale for the encoding of the  
> requested transport? Why not simply specify:
>
>      0
>      0 1 2 3 4 5 6 7
>     +-+-+-+-+-+-+-+-+
>     |    Protocol   |
>     +-+-+-+-+-+-+-+-+
>

The various approaches to this are historical.  The REQUESTED- 
TRANSPORT attribute is one of the oldest attributes, though it has  
undergone a few changes, while EVEN-PORT is the most recent attribute  
added (replacing an older attribute which went through a number of  
changes). The different approaches reflect changing ideas on how to  
handle this padding issue.

I agree that it would be nice if things were consistent. In fact,  
there are quite a few things that I would change in TURN if I had a  
free hand. However, these days my personal opinion is that the most  
important thing is to get the spec published and not spend more time  
polishing the spec.

- Philip