Subject: [rtcweb] IP handling: Using mDNS names for host candidates

From: Justin Uberti <[email-masked]>
Date: Mon, 11 Jun 2018 17:40:14 -0700

The Safari team has come up with a clever approach to avoid disclosing
private IP addresses for host candidates. As discussed in this WebKit bug
<https://bugs.webkit.org/show_bug.cgi?id=174500>, the technique works as
follows:

   1. Register a random UUID-based mDNS name when ICE gathering starts
   2. Replace the private IP address by a "{UUID}.local" string in each
   host candidate (and set raddr to 0.0.0.0 for other candidates)
   3. The other party will do mDNS resolution on any candidate having a
   .local suffix, similar to how hostnames in candidates are handled in RFC
   5245, Section 15.1.

This technique is relevant to the IP handling document, as it addresses one
of the lesser problems (private IP disclosure) from the overall problem
statement. While I don't think this will have a large impact on the
document, including the default mode selection, incorporating this
technique would result in some moderate changes:

   - Section 5.1 would mention concealing private IPs in the default case
   as an explicit goal.
   - In Section 6, Mode 2 would change from handling out private IPs to
   handing out mDNS names.
   - This document would have to describe the technique or point to another
   document that describes the technique. mmusic-ice-sip-sdp, Section 4.1
   <https://tools.ietf.org/html/draft-ietf-mmusic-ice-sip-sdp-20#section-4.1>
seems
   like a good option, as it already covers how to handle DNS names in ICE
   candidates.

This is a significant improvement and I think we will want to incorporate
this suggestion. Is this something we could do as part of this WGLC, or
should we look for another option?

---

From: Lennart Grahl <[email-masked]>
Date: Tue, 12 Jun 2018 13:15:06 +0200

>    - In Section 6, Mode 2 would change from handling out private IPs to

IMHO that would create a large gap between mode 1 and 2. Instead, I
would suggest using mDNS *in addition* to mode 2 and 3. For mode 2 this
would mean that only the default private IP is being transmitted but all
other interfaces are hidden by UUID-based hostnames. For mode 3, all
private IPs are hidden by UUID-based hostnames.

>    like a good option, as it already covers how to handle DNS names in ICE

Since this will be useful for ORTC as well, I would not tie that to an
SDP-specific document.

> should we look for another option?
I haven't seen a better solution than mDNS so far to prevent IPs from
leaking and I would appreciate having this to fix the following issues:

- Allowing browsers to use stricter modes by default without significant
drawbacks,
- establishing direct connections even in case no "consent" has been
given because the devices are in fact in the same network segment (with
the exception of mode 4), and
- use cases where gUM cannot be applied and no other way of expressing
consent has been provided (which is the status quo).

Cheers
Lennart

---

From: Justin Uberti <[email-masked]>
Date: Tue, 12 Jun 2018 08:39:21 -0700

> private IPs are hidden by UUID-based hostnames.

I don't see a clear benefit of doing that. If you have the mDNS hostnames,
you don't need the private IPs.

Or, looking at it a different way, if mode 3 is as you describe, why would
we ever use mode 2?

> >    <
> https://tools.ietf.org/html/draft-ietf-mmusic-ice-sip-sdp-20#section-4.1>
> > seems

ORTC already depends on this document (it explains ICE restarts, amongst
other things), so I don't see this as an issue. The nice thing about this
document is that it's nearing last call, but we still have time to make
edits like the ones suggested.

> consent has been provided (which is the status quo).

Noted. Thanks.

---

From: Lennart Grahl <[email-masked]>
Date: Tue, 12 Jun 2018 18:34:23 +0200

On 12.06.2018 17:39, Justin Uberti wrote:
> we ever use mode 2

Mode 2 with mDNS hostnames exclusively would only work when the devices
are in the same network segment. Anything that stops multicast would
require the use of a STUN server. That makes mode 2 a lot less powerful.

Whereas mode 2 as of today and with my suggestion does work without a
STUN server, even if you are not in the same network segment. Think of
IPv6 global addresses or corporate networks with several private
networks. And exposing an IP is still useful for establishing a
connection with an implementation that doesn't support mDNS (not even
resolving).

> edits like the ones suggested.

Fair enough.

Cheers
Lennart

---

From: Joseph Lorenzo Hall <[email-masked]>
Date: Tue, 12 Jun 2018 14:37:57 -0400

inveterate lurker here; I'd definitely +1 getting this in during the WGLC
for this document if there are no strong objections.

On Mon, Jun 11, 2018 at 8:40 PM, Justin Uberti <
juberti=[email-masked]> wrote:

> This technique is relevant to the IP handling document, as it addresses
> one of the lesser problems (private IP disclosure) from the overall problem
>    - This document would have to describe the technique or point to
>    another document that describes the technique. mmusic-ice-sip-sdp,
>    Section 4.1
>    <https://tools.ietf.org/html/draft-ietf-mmusic-ice-sip-sdp-20#section-4.1> seems
> _______________________________________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb
>
>

-- 
Joseph Lorenzo Hall
Chief Technologist, Center for Democracy & Technology [https://www.cdt.org]
1401 K ST NW STE 200, Washington DC 20005-3497
e: [email-masked], p: 202.407.8825, pgp: https://josephhall.org/gpg-key
Fingerprint: 3CA2 8D7B 9F6D DBD3 4B10  1607 5F86 6987 40A9 A871

---

From: Ted Hardie <[email-masked]>
Date: Tue, 12 Jun 2018 20:55:59 +0200

> should we look for another option?
Without having cleared this with Cullen or Sean, my personal chair-hat
opinion is that we can do this in WGLC.  If a new technical solution is
found during WG last call, I see no reason not to incorporate it.

That said, I see two no-hats issues that will want pretty strong text.  The
first is that these are really UUIDs, not traditional mDNS names.  We'll
need text to strongly discourage the re-use of an existing mDNS name, since
those can leak other information.  Second, we'll need text on what to do if
this name can't be registered or resolved in a particular environment (not
every network supports mDNS, after all).  Does it go back to the previous
Mode 2 behavior, or skip private addresses entirely?  I think the right
idea is "go back to the previous Mode 2 behavior" personally, but text on
it one way or the other is required.

regards,

Ted

---

From: Adam Roach <[email-masked]>
Date: Tue, 12 Jun 2018 12:08:24 -0700

I’d like to point out that, while this works fine in most residential settings, it’s pretty broken for multi-segment enterprise deployments. 

/a

> On Jun 12, 2018, at 11:55, Ted Hardie <[email-masked]> wrote:
> 
>> On Tue, Jun 12, 2018 at 2:40 AM, Justin Uberti <juberti=[email-masked]> wrote:
>> 
>> This is a significant improvement and I think we will want to incorporate this suggestion. Is this something we could do as part of this WGLC, or should we look for another option?
>> 
> 
> Without having cleared this with Cullen or Sean, my personal chair-hat opinion is that we can do this in WGLC.  If a new technical solution is found during WG last call, I see no reason not to incorporate it.
> 
> That said, I see two no-hats issues that will want pretty strong text.  The first is that these are really UUIDs, not traditional mDNS names.  We'll need text to strongly discourage the re-use of an existing mDNS name, since those can leak other information.  Second, we'll need text on what to do if this name can't be registered or resolved in a particular environment (not every network supports mDNS, after all).  Does it go back to the previous Mode 2 behavior, or skip private addresses entirely?  I think the right idea is "go back to the previous Mode 2 behavior" personally, but text on it one way or the other is required.
> 
> regards,
> 
> Ted
> 
> 
>

---

From: Justin Uberti <[email-masked]>
Date: Tue, 12 Jun 2018 12:14:19 -0700

One option could be that Mode 2 incorporates RFC 4941 stateless IPv6
addresses, if supported. Otherwise, mDNS is used. This mode would never
include RFC 1918 IPv4 addresses.

This would work well in more environments and still provide significant
privacy improvements.

On Tue, Jun 12, 2018 at 12:08 PM Adam Roach <[email-masked]> wrote:

> I’d like to point out that, while this works fine in most residential
> settings, it’s pretty broken for multi-segment enterprise deployments.
>
> /a
>
> That said, I see two no-hats issues that will want pretty strong text.
> The first is that these are really UUIDs, not traditional mDNS names.
> We'll need text to strongly discourage the re-use of an existing mDNS name,
> since those can leak other information.  Second, we'll need text on what to
> do if this name can't be registered or resolved in a particular environment
> (not every network supports mDNS, after all).  Does it go back to the
> previous Mode 2 behavior, or skip private addresses entirely?  I think the
> right idea is "go back to the previous Mode 2 behavior" personally, but
> text on it one way or the other is required.
>
> regards,
>
> Ted
>
>
>
>

---

From: Justin Uberti <[email-masked]>
Date: Tue, 12 Jun 2018 16:36:44 -0700

Given the general support here, I'll start writing up a PR to incorporate
the aforementioned changes, with the goal to avoid emitting private IPv4
addresses in the default mode.

On Tue, Jun 12, 2018 at 12:14 PM Justin Uberti <[email-masked]> wrote:

>>> This is a significant improvement and I think we will want to
>>> incorporate this suggestion. Is this something we could do as part of this
>>> WGLC, or should we look for another option?
>>>
>>>

---

From: Justin Uberti <[email-masked]>
Date: Tue, 12 Jun 2018 20:20:30 -0700

PTAL at https://github.com/juberti/draughts/pull/103.

It would be great to have some time to discuss this in Montreal.

---

From: Cullen Jennings <[email-masked]>
Date: Wed, 13 Jun 2018 14:28:03 -0600

With my individual hat on …

I have a bunch of concerns about this but the biggest is that mDNS does not work on a large percentage of medium and large corporate WiFI Networks. The problem is the large multicast domains trash the WiFi performance so many APs turn off mDNS or limit it’s range to much less than the scope of where just testing the address with ICE would be routable. It’s exactly theses environment where using the local IP vs a TURN IP provides lots of benefit.  I like the idea of trying to use mDNS but I’d want tot see strong evidence it worked in theses environments before putting it in at the last minute. 

> On Jun 11, 2018, at 6:40 PM, Justin Uberti <juberti=[email-masked]> wrote:
> 
> The Safari team has come up with a clever approach to avoid disclosing private IP addresses for host candidates. As discussed in this WebKit bug <https://bugs.webkit.org/show_bug.cgi?id=174500>, the technique works as follows:
> Register a random UUID-based mDNS name when ICE gathering starts
> Replace the private IP address by a "{UUID}.local" string in each host candidate (and set raddr to 0.0.0.0 for other candidates)
> The other party will do mDNS resolution on any candidate having a .local suffix, similar to how hostnames in candidates are handled in RFC 5245, Section 15.1.
> This technique is relevant to the IP handling document, as it addresses one of the lesser problems (private IP disclosure) from the overall problem statement. While I don't think this will have a large impact on the document, including the default mode selection, incorporating this technique would result in some moderate changes:
> Section 5.1 would mention concealing private IPs in the default case as an explicit goal.
> In Section 6, Mode 2 would change from handling out private IPs to handing out mDNS names.
> This document would have to describe the technique or point to another document that describes the technique. mmusic-ice-sip-sdp, Section 4.1 <https://tools.ietf.org/html/draft-ietf-mmusic-ice-sip-sdp-20#section-4.1> seems like a good option, as it already covers how to handle DNS names in ICE candidates.

---

From: Justin Uberti <[email-masked]>
Date: Thu, 14 Jun 2018 10:14:39 -0700

This is a valid concern, but keep in mind that this only applies to:
- apps without gUM permission (or else they can use Mode 1)
- on networks that don't support IPv6 (or else they can use the RFC 4941 v6
address)
- on networks where mDNS is turned off or constrained

I tend to think this is still a pretty good tradeoff.

One other option could be to add a new Mode 1.5 that did hand out the
private IP which could be selected by domain admins, but given how subtle
this area is, I tend to think that it would rarely, if ever, be enabled.

On Wed, Jun 13, 2018 at 1:28 PM Cullen Jennings <[email-masked]> wrote:

> I have a bunch of concerns about this but the biggest is that mDNS does
> not work on a large percentage of medium and large corporate WiFI Networks.
> The problem is the large multicast domains trash the WiFi performance so
> many APs turn off mDNS or limit it’s range to much less than the scope of
> where just testing the address with ICE would be routable. It’s exactly
> theses environment where using the local IP vs a TURN IP provides lots of
> benefit.  I like the idea of trying to use mDNS but I’d want tot see strong
> evidence it worked in theses environments before putting it in at the last
> minute.
>
>
>
> On Jun 11, 2018, at 6:40 PM, Justin Uberti <

---

From: T H Panton <[email-masked]>
Date: Thu, 14 Jun 2018 18:34:27 +0100

In the case of Burningman/town-hall intranet meeting - the side _sending_ the media would presumably have GUM permissions,
so be advertising it's 'private' IPv4s - I guess we might get a direct connection set up via peer-reflexives discovered that way.

T.

> On 14 Jun 2018, at 18:14, Justin Uberti <juberti=[email-masked]> wrote:
> 
> - on networks that don't support IPv6 (or else they can use the RFC 4941 v6 address)
> One other option could be to add a new Mode 1.5 that did hand out the private IP which could be selected by domain admins, but given how subtle this area is, I tend to think that it would rarely, if ever, be enabled.
> 
> On Wed, Jun 13, 2018 at 1:28 PM Cullen Jennings <[email-masked] <mailto:[email-masked]>> wrote:
> 
> 
>> On Jun 11, 2018, at 6:40 PM, Justin Uberti <juberti=[email-masked] <mailto:juberti=[email-masked]>> wrote:
>> 
>> [email-masked] <mailto:[email-masked]>
>> https://www.ietf.org/mailman/listinfo/rtcweb <https://www.ietf.org/mailman/listinfo/rtcweb>
>

---

From: Cullen Jennings <[email-masked]>
Date: Thu, 14 Jun 2018 12:13:58 -0600

Fair points - I still lean to  “add this later” but I could live with it either way. 

> On Jun 14, 2018, at 11:14 AM, Justin Uberti <[email-masked]> wrote:
>

---

From: Harald Alvestrand <[email-masked]>
Date: Thu, 14 Jun 2018 23:15:33 +0200

I have some worries about this proposal. It seems neat, and solves a
specific problem for a specific use case, but it's not a written-up
proposal, rather a sketch for one - and I'm afraid of devils in the details.

For instance:

- If this technique is used for a computer directly connected to the
Internet, with a public IP address, it won't communicate - unless it is
only used on private addresses - because "uuid.local" doesn't resolve,
whereas a public IP address is globally reachable.

- The above means that the proposal needs a definition of "private
address". Do we mean "private" in the RFC 1918 sense? If so, which IPv6
range is covered by the proposal?

- It will only work if the private address usage is the same scope as
mDNS resolution. On an unmanaged LAN it works, and on a network with
explicit mDNS forwarding it works. But on any other deployment, it
forces traffic to go via public IP addresses learned by STUN.

I think this is worth adding. Perhaps as a new "mode 2m"?

But I'd like a commitment to not adding it until we have a full proposal.

Den 12. juni 2018 02:40, skrev Justin Uberti:
> private IP addresses for host candidates. As discussed in this WebKit
> bug <https://bugs.webkit.org/show_bug.cgi?id=174500>, the technique
> works as follows:
> 
>     .local suffix, similar to how hostnames in candidates are handled in
>     RFC 5245, Section 15.1.
> 
> one of the lesser problems (private IP disclosure) from the overall
> problem statement. While I don't think this will have a large impact on
> the document, including the default mode selection, incorporating this
>   * Section 5.1 would mention concealing private IPs in the default case
>     as an explicit goal.
>   * In Section 6, Mode 2 would change from handling out private IPs to
>     handing out mDNS names.
>   * This document would have to describe the technique or point to
>     like a good option, as it already covers how to handle DNS names in
>     ICE candidates.
> 
> incorporate this suggestion. Is this something we could do as part of
> this WGLC, or should we look for another option?
> 
>

---

From: Justin Uberti <[email-masked]>
Date: Thu, 14 Jun 2018 14:32:28 -0700

> But I'd like a commitment to not adding it until we have a full proposal.

I have sketched out the proposal in
https://github.com/juberti/draughts/pull/103, which while not complete,
does address most of your questions.

> https://tools.ietf.org/html/draft-ietf-mmusic-ice-sip-sdp-20#section-4.1
> > seems

---

From: Harald Alvestrand <[email-masked]>
Date: Thu, 14 Jun 2018 23:40:56 +0200

I found Justin's specific proposal after I sent my previous message.
Apologies for not reading the whole thread.

Detailed comments have been entered on the PR.

---

From: youenn fablet <[email-masked]>
Date: Tue, 12 Jun 2018 08:44:41 -0700

Hi all,

Would it make sense to reserve a time slot at next IETF 102 meeting to discuss this?
Apparently, the RTCWeb WG is not meeting there.
Maybe MMUSIC session would be a good place?

Thanks,
	Y

> Le 12 juin 2018 à 8:39 AM, Justin Uberti <[email-masked]> a écrit :
> 
> 
> 
> On Tue, Jun 12, 2018 at 4:15 AM Lennart Grahl <[email-masked] <mailto:[email-masked]>> wrote:
> > <https://bugs.webkit.org/show_bug.cgi?id=174500 <https://bugs.webkit.org/show_bug.cgi?id=174500>>, the technique works as
> > follows:
> > 
> I don't see a clear benefit of doing that. If you have the mDNS hostnames, you don't need the private IPs.
> 
> Or, looking at it a different way, if mode 3 is as you describe, why would we ever use mode 2? 
> 
> >    <https://tools.ietf.org/html/draft-ietf-mmusic-ice-sip-sdp-20#section-4.1 <https://tools.ietf.org/html/draft-ietf-mmusic-ice-sip-sdp-20#section-4.1>>
> > seems
> ORTC already depends on this document (it explains ICE restarts, amongst other things), so I don't see this as an issue. The nice thing about this document is that it's nearing last call, but we still have time to make edits like the ones suggested.
>

---

From: Matthew Kaufman <[email-masked]>
Date: Fri, 15 Jun 2018 10:48:54 -0700

Opposed because we shouldn't waste any more time on IPv4, and IPv6 has no
analog that we can implement for IPv6 and then implement for IPv4 largely
for free.

Matthew Kaufman

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 29 Jun 2018 07:02:45 -0700

It seems like this is something one could A/B test and measure connection
rates. Has someone done so?

-Ekr

On Fri, Jun 15, 2018 at 10:48 AM, Matthew Kaufman <[email-masked]>
wrote:

> On Thu, Jun 14, 2018 at 2:32 PM Justin Uberti <juberti=40google.com@dmarc.
> ietf.org> wrote:
>
>> I have sketched out the proposal in https://github.com/juberti/
>> draughts/pull/103, which while not complete, does address most of your
>> questions.
>>
>>>

---

From: Justin Uberti <[email-masked]>
Date: Fri, 29 Jun 2018 11:10:17 -0700

I believe such data will be forthcoming from the Safari team. We are also
working on this.

On Fri, Jun 29, 2018 at 7:03 AM Eric Rescorla <[email-masked]> wrote:

>> [email-masked] <[email-masked]..org>> wrote:
>>

---

From: youenn fablet <[email-masked]>
Date: Fri, 29 Jun 2018 18:06:35 -0700

A draft describing the Safari/WebKit approach is available at
https://www.ietf.org/id/draft-mdns-ice-candidates-00.txt

Eric, can you precise the kind of information you would like to have?
Some testing has been done to validate the approach but I do not think this
is representative of the actual state of the affair. Safari/WebKit is not
gathering any related statistic.

   Y

---

From: Eric Rescorla <[email-masked]>
Date: Sat, 30 Jun 2018 05:43:45 -0700

I haven't thought about it too much, but I think that I would probably do
is an A/B test where I randomly set clients to this strategy or the current
strategy and measured success rates, time to connect, and (maybe) some sort
of call quality stat. It's not going to be easy because I don't know how
much non-permissioned WebRTC there is in the wild.
-Ekr

On Fri, Jun 29, 2018 at 6:06 PM, youenn fablet <[email-masked]> wrote:

> Some testing has been done to validate the approach but I do not think
> this is representative of the actual state of the affair. Safari/WebKit is
> not gathering any related statistic.
>
>    Y
>
> Le ven. 29 juin 2018 à 11:10, Justin Uberti <juberti=40google.com@dmarc.
> ietf.org> a écrit :
>
>>> It seems like this is something one could A/B test and measure
>>> connection rates. Has someone done so?
>>>
>>> -Ekr
>>>
>>