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

[Justin Uberti <[e-mail]>]

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

> On 18/07/2015 1:09, Justin Uberti wrote:
>
>>     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.
>>
>
> Agree, for each HOST candidate, it should send a STUN request to the turn
> server from that IP:port. But shouldn't the VPN configuration prevent the
> non-VPN-host-candidate STUN request to be sent via the non-VPN-interface?
> (i.e. applying default route based on dest?)
>

Replying to Sergio:

Typically with a VPN, the non-VPN interface is locked down so it only has a
single route: to the VPN server. However, split tunnel VPNs allow the
non-VPN interface to route to other addresses (possibly, for performance
reasons), so in this case, the non-VPN-host-candidate STUN request will be
sent successfully from the non-VPN interface.

Sometimes this will be desirable: imagine someone working from home who
wants to connect to their corp VPN, but wants to have their video
conferencing traffic not go through the VPN. Sometimes this will not be
desirable, i.e. when the VPN is being used for privacy. This makes picking
a perfect default setting difficult, although we have some ideas that we
are exploring.