Re: [rtcweb] Review of draft-ietf-rtcweb-mdns-ice-candidates

[Lennart Grahl <[e-mail]>]

On 14.09.18 19:44, youenn fablet wrote:
> Agreed that this proposal does not solve all cases.
> But it does so in a number of cases like home/small office scenarios.
>
> [...]
>> In general, I do not think there is a guarantee to successfully connect
> without sometimes relying on TURN servers.
> This proposal and other solutions should allow reducing the need to use
> TURN.

The problem I see is that the document deteriorates the default
situation while it only levels it out for home/small office scenarios.
For the majority of implementations (which use mode 2 by default) the
host-to-host connections will less likely succeed than previously.

> Describing precisely the problematic scenarios is useful as we can find
> additional means specific to those scenarios.
> For instance, can it be envisioned to deploy STUN servers inside the user
> network for the financial applications/branch offices scenarios you are
> mentioning?

Perhaps its feasible for those use cases where the administrator is
already aware of the software but definitely not for small applications
such as sharedrop.io, Threema Web whose main use case is the direct
connection in same network environments and its significant benefits
regarding throughput.

Cheers
Lennart

> 
> Le ven. 14 sept. 2018 à 00:10, Bernard Aboba <[e-mail]> a
> écrit :
> 
>> While I understand the overall goal of this document,  it strikes me as
>> suffering from two major problems:
>>
>> a. Introduction of backwards compatibility problems and potential
>> additional delays due to utilization of name resolution mechanisms in ICE,
>> with a corresponding benefit (successful connectivity checks between host
>> candidates on the same network) which is only a marginal improvement over
>> mode 3 (no host candidates).
>>
>> b. Over-reliance on permission mechanisms which have already been
>> stretched to the breaking point, leaving the potential for collateral
>> damage in data channel-only scenarios. Due to limitations in the current
>> permissions mechanisms, it is not currently practically impossible to
>> distinguish legitimate data channel applications that would obtain
>> permissions if there were usable means to do so from illegitimate
>> applications attempting to compromise user privacy.
>>
>> Data-channel only scenarios that would be impacted include those where:
>>
>> 1. Permissions cannot be obtained (e.g. where there is no microphone or
>> camera attached to the device so that getUserMedia will always fail).
>>
>> 2. Low latency communications is a requirement so that TURN server
>> traversal is unacceptable (e.g. in financial applications where there may
>> be regulatory requirements relating to allowable delays).
>>
>> 3. TURN traversal would impose an unacceptable financial cost, such as in
>> branch office scenarios where a TURN servers is not provided in each branch
>> office, and branch office connectivity may be constrained (still an issue
>> for branch offices located on other continents).
>>
>> Essentially, the problem is that these scenarios may have valid reasons
>> why they cannot utilize or do not wish to utilize getUserMedia as a
>> permission-granting mechanism.