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

> -----Original Message-----
> From: behave-bounces@ietf.org 
> [mailto:behave-bounces@ietf.org] On Behalf Of Ari Keranen
> Sent: Wednesday, August 19, 2009 3:21 AM
> To: draft-ietf-behave-turn-tcp@tools.ietf.org
> Cc: behave@ietf.org
> 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.

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

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?

(CC'ing TURN authors.)

-d

> 
> Cheers,
> Ari
> _______________________________________________
> Behave mailing list
> Behave@ietf.org
> https://www.ietf.org/mailman/listinfo/behave
> 