Re: [BEHAVE] WGLC: draft-ietf-behave-turn-tcp-04

[Ari Keranen <[e-mail]>]

Dan Wing wrote:
>> -----Original Message-----
>> From: [e-mail] 
>> [mailto:[e-mail]] On Behalf Of Ari Keranen
>> Sent: Wednesday, August 19, 2009 3:21 AM
>> To: [e-mail]
>> Cc: [e-mail]
>> Subject: Re: [BEHAVE] WGLC: draft-ietf-behave-turn-tcp-04
>>
>> Hi,
>>
>> One technical issue in draft-ietf-behave-turn-tcp-04 caught 
>> my attention:
>>
>> In section 4.5., "Sending and Receiving Data" is says:
>>
>>     [...] Data on a data connection MUST NOT
>>     be interpreted as STUN messages.
>>
>> I think this is too heavy restriction. What about if the peer 
>> wants to 
>> send some STUN messages on the path via the TURN server and 
>> would need 
>> the TURN client to parse them as STUN?
> 
> How would the TURN server identify such traffic that it should
> respond to?  Thinking aloud, one solution is for the local TURN
> client to tell the TURN server which STUN username(s) indicate 
> the STUN message is intended for the TURN server.

Actually, my point was about TURN clients (section 4, and the 
subsections, I assume, are about "client processing"). That is, a TURN 
client should be able to interpret relayed data as STUN messages. I do 
understand why this same restriction was in the section 5.4, since 
section 5 is about the server part.

I think the TURN-TCP server can, and should, always just blindly relay 
the data on the data connection. If there's need for STUN signaling with 
the server, the control connection should be used for that.

>> I would rather make this "SHOULD NOT" to be future proof. Or even 
>> removing the whole restriction should not do much harm, right?
> 
> The reason for this passage is so that ICE connectivity checks
> can be performed, through the TURN server, between the endpoints.
> If the TURN server 'eats' (processes) the incoming messages
> from the remote peer, the connectivity checks will fail.

Yes, that's why section 5.4 is OK with the restriction. Probably this 
text was supposed to be only in section 5.4 but accidentally slipped to 
section 4.5 too?

> This is really something that belongs in the TURN specification
> because I believe it is not unique to TURN-TCP.  If anything, the 
> TURN specification should say something like: 
> 
>   In the absence of an standards-track enhancement to identify 
>   STUN traffic intended for the TURN server, data on a data
>   connection MUST NOT be interpreted as a STUN message.
> 
> Thoughts?

In the TURN-UDP case you don't have a "data connection" in the same 
sense as with TURN-TCP, so I think this is actually TURN-TCP specific. 
Although data sent by a peer should never be interpreted as STUN by the 
server, but I think this is somewhat clear from the current TURN-UDP draft.


Cheers,
Ari