Subject: Re: [BEHAVE] TURN Issue #7: Framing header length

From: Philip Matthews <[email-masked]>
Date: Fri, 18 Jan 2008 15:41:18 -0500

I have updated the document to reflect this decision, as well as  
fixed a minor related point. Below is the new text. Note that I have  
renamed the TURN framing header to the ChannelData message.

     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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |         Channel Number        |            Length             |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               |
    /                       Application Data                        /
    /                                                               /
    |                                                               |
    |                               +-------------------------------+
    |                               |
    +-------------------------------+

[SNIP]

    The Length field specifies the length in bytes of the application
    data field (i.e., it does not include the size of the ChannelData
    header).  Note that 0 is a valid length.

AND

    Over stream transports, the ChannelData message MUST be padded to a
    multiple of four bytes in order to ensure the alignment of  
subsequent
    messages.  The padding is not reflected in the length field of the
    ChannelData message, so the actual size of a ChannelData message
    (including padding) is (4 + Length) rounded up to the nearest
    multiple of 4.  Over UDP, the padding is not required but MAY be
    included.

AND

    If the ChannelData message is received in a UDP datagram, and if the
    UDP datagram is too short to contain the claimed length of the
    ChannelData message (i.e., the UDP header length field value is less
    than the ChannelData header length field value + 4 + 8), then the
    message is silently discarded.

    If the ChannelData message is received over TCP or over TLS over  
TCP,
    then the actual length of the ChannelData message is as described in
    Section 7.5.

Comments?

- Philip

On 7-Dec-07, at 18:11 , Jonathan Rosenberg wrote:

> This was not in my slides. It was raised at the mike at the WG  
> session, discussed briefly at the WG meeting and again briefly at  
> the end of the ad-hoc.
>
> The current TURN framing header looks like:
>
>         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
>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 
> +-+-+
>        |        Channel                |         Message  
> Length        |
>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 
> +-+-+
>
> When TURN is running over UDP, the length header is redundant. The  
> current spec says to set it to zero. The issue was raised that, it  
> would be better to set it to to be the correct length, rather than  
> zero. The drawback of setting it to the correct length, is it  
> introduces an error condition. What happens if it doesn't match the  
> actual UDP length? Do we truncate (assuming the actual UDP packet  
> size is larger than the TURN header message length)? Or just discard?
>
> The point raised at the ad-hoc later, was that even if you set it  
> to zero, you still have the error condition, what if its not zero.  
> It was also pointed out, by setting the length we get the framing  
> header consistent between UDP and TCP.
>
> So there was rough agreement at the ad-hoc, to change turn so that  
> the message length is the actual message length, even over UDP. If  
> it mismatches the actual UDP message length, then the packet MUST  
> be discarded in error.
>
> Please comment as to whether you agree (or disagree) with this  
> conclusion.
>
> Thanks,
> Jonathan R.
> -- 
> Jonathan D. Rosenberg, Ph.D.                   499 Thornall St.
> Cisco Fellow                                   Edison, NJ 08837
> Cisco, Voice Technology Group
> [email-masked]
> http://www.jdrosen.net                         PHONE: (408) 902-3084
> http://www.cisco.com
>
>
> _______________________________________________
> Behave mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/behave
>

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