Re: [rtcweb] [BEHAVE] New Version Notification for draft-chenxin-behave-turn-websocket-01.txt

["Chenxin (Xin)" <[e-mail]>]

Hi Simon,
>>> I have a new question: what does the TURN server put in the
>>> XOR-MAPPED-ADDRESS attribute? The proxy's address or the client's
>>> address?
>>
>> The proxy's address. I do not think this attribute will help ICE process.
>>
>> Can TURN over WebSockets be used to gather server-reflexive
>>> candidates?
>>
>> Yes, It could do as UDP and TCP. But when there is a http proxy. I think the
>server reflexive candidates will be the address of proxy, which means nothing for
>the peer.
>
>Isn't this a big problem? I mean, if the client cannot trust the value
>of the XOR-MAPPED-ADDRESS attribute, doesn't that break STUN/TURN/ICE
>and everything else?
>
Thanks for your question. You are right about it. We should consider more about gathering the server reflexive candidates in turn over websocket.
I have checked the RFC 5766 again:
      Reflexive Transport Address:  A transport address learned by a client
      that identifies that client as seen by another host on an IP
      network, typically a STUN server.  When there is an intervening
      NAT between the client and the other host, the reflexive transport
      address represents the mapped address allocated to the client on
      the public side of the NAT.  Reflexive transport addresses are
      learned from the mapped address attribute (MAPPED-ADDRESS or XOR-
      MAPPED-ADDRESS) in STUN responses.
Which restricts that the "Reflexive Transport Address" should be obtained from NAT. It will be semantic problem if this address is from proxy.

In ICE, I have not found out the harmful scenario yet. It will be possible to make ICE Connectivity Checks failed, but it will be possible to be useful. 
I am still thinking about how to handle it. Should we just leave it to for the usage of gathering candidate from NAT? OR totally forbid it in the turn over websocket?
What is your suggestion?

>Simon
>--
>DTN made easy, lean, and smart --> http://postellation.viagenie.ca
>NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
>STUN/TURN server               --> http://numb.viagenie.ca