Subject: [rtcweb] draft-ietf-rtcweb-ip-handling: Mode 2 and VPN scenarios

From: Byron Campen <[email-masked]>
Date: Wed, 23 Aug 2017 14:33:39 -0500

A corner-case came up over at 
https://bugzilla.mozilla.org/show_bug.cgi?id=1384265. This corner-case, 
in brief, happens when a webrtc service is deployed entirely on a VPN, 
but does not call gUM, forcing mode 2 to be used. In this case, only the 
default route is gathered, which prevents connections to endpoints on 
the VPN (TURN server, or SFU, or other browsers), even though the 
browser has already exposed its VPN address by connecting to the origin.

     It seems reasonable to gather/trickle the interface that was used 
to connect to the origin, since that IP address has already been 
disclosed. We might also elect to continue exposing the default route, 
since if the webrtc service on the VPN is doing something nefarious, it 
is going to be able to learn the default route by colluding with a 
server out on the Internet.

     Thoughts?

Best regards,

Byron Campen