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

[Sergio Garcia Murillo <[e-mail]>]

On 17/07/2015 23:41, Justin Uberti wrote:
>
>
> On Fri, Jul 17, 2015 at 2:03 PM, Sergio Garcia Murillo 
> <[e-mail] 
> <mailto:[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).

    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.

What am I missing?

Best regards
Sergio