Re: [rtcweb] Please require user consent for data channels

[Justin Uberti <[e-mail]>]

On Fri, Jul 17, 2015 at 3:47 PM, Sergio Garcia Murillo <
[e-mail]> wrote:

>  On 17/07/2015 23:41, Justin Uberti wrote:
>
>
>
> On Fri, Jul 17, 2015 at 2:03 PM, Sergio Garcia Murillo <
> <[e-mail]>[e-mail]> wrote:
>
>>  Hi Justin,
>>
>> Thanks for pointing that out, can you point me were in RFC5245 is that
>> behavior described? I fail to find it.
>>
>> The only references I found about multihoming are about HOST candidates,
>> performing connectivity checks and priorization of candidates, but I cannot
>> find a reference on sending STUN request to the TURN/STUN server via all
>> the available interfaces in order to retrieve the server reflexive
>> candidates that is where the leak is originating. Please correct me again
>> if I am wrong.
>>
>
>  Section 2.1, paragraphs 2 and 3 talks about getting all interfaces, and
> then getting STUN and TURN candidates from said interfaces.
>
>
> That was the ones I was looking at, but my understanding of them is
> different:
>
>    If an agent is multihomed, it obtains a candidate from each IP
>    address.  Depending on the location of the PEER (the other agent in
>    the session) on the IP network relative to the agent, the agent may
>    be reachable by the peer through one or more of those IP addresses.
>    Consider, for example, an agent that has a local IP address on a
>    private net 10 network (I1), and a second connected to the public
>    Internet (I2).  A candidate from I1 will be directly reachable when
>    communicating with a peer on the same private net 10 network, while a
>    candidate from I2 will be directly reachable when communicating with
>    a peer on the public Internet.  Rather than trying to guess which IP
>    address will work prior to sending an offer, the offering agent
>    includes both candidates in its offer.
>
> Here, what I understand is that they are talking about Host ICE candidates, an then, yes, one per interface, no issue here (If my understanding of the leak problem is correct).
>
>
Agreed.

>    Next, the agent uses STUN or TURN to obtain additional candidates.
>    These come in two flavors: translated addresses on the public side of
>    a NAT (SERVER REFLEXIVE CANDIDATES) and addresses on TURN servers
>    (RELAYED CANDIDATES).  When TURN servers are utilized, both types of
>    candidates are obtained from the TURN server.  If only STUN servers
>    are utilized, only server reflexive candidates are obtained from
>    them.  The relationship of these candidates to the host candidate is
>    shown in Figure 2.  In this figure, both types of candidates are
>    discovered using TURN.  In the figure, the notation X:x means IP
>    address X and UDP port x.
>
> In this one is talking about getting server reflexive and relay candidates, but in no way I see that the stun server should be contacted by all the interfaces or overriding default routing from OS.
>
>
It is pretty clear from the diagram on page 10 that for each host candidate
X:x, the agent will gather a srflx candidate X1':x1' and relay candidate
Y:y. This is also spelled out in the text underneath the diagram:

   When the agent sends the TURN Allocate request from IP address and
   port X:x, the NAT (assuming there is one) will create a binding
   X1':x1', mapping this server reflexive candidate to the host
   candidate X:x.

Ergo, one tries to gather srflx and relay candidates for each host
candidate X:x.