Subject: Re: [MMUSIC] ietf-mmusic-mdns-ice-candidates new draft: Christer's comments - corrected version

From: Christer Holmberg <[email-masked]>
Date: Fri, 21 May 2021 17:49:06 +0000

It seems like I added some of the Q4 text to Q3. Here is a corrected version of my question:

Q1:

I think it needs to be more clear that mDNS domain names (.local) can only be resolved by remote peers within the same local network.

Section 5.1 does talk about this, and it may be an implicit assumption, but I think it should be pointed out in the beginning of the document.

---

Q2:

Related to Q1, think it needs to be more clear that the mechanism prevents IP address leaking to peers outside the local network. Inside the local network I assume that web apps can still find out about the local address simply by performing an mDNS lookup on the mDNS domain name.

---

Q3:

The draft makes an assumption that the mDNS domain names are unique. Why making that assumption? If the local network supports multicast, there may even be non-WebRTC applications using mDNS, which increases the risk for collision.

---

Q4:

Section 3.1.1 says that an ICE agent, when it gathers candidates, generates a UNIQUE mDNS domain name. I assume that means that the mDNS domain name will only be valid for the duration of the ICE session.

Doesn't that mean that there is no need for other ICE agents to cache the mDNS domain name:IP address mapping for "future use", because the mDNS domain name won't be used in future anyway?

Also, I am not sure whether ICE implementations should cache mappings to begin with. That's the task of the mDNS client of the host.

---

Q5:

Section 5.3 says:

   "When an endpoint that supports mDNS communicates with an endpoint that does not, the legacy
   endpoint will still provide its local IP addresses, and accordingly a direct connection can still be attempted, 
   even though the legacy endpoint cannot resolve the mDNS names provided by the new endpoint."

Please make it more clear that the legacy endpoint is the one that does not support mDNS. Something like:

    "When an endpoint that supports mDNS communicates with a legacy endpoint that does not, the..."

---

Q6:

If I remember correctly, people have raised issues with legacy parsers not being able to parse non-IP-addresses. If so, shouldn't that be mentioned in Section 5.3?

(NOTE: Eventhough the draft updates RFC 8839, to support mDNS domain names, it does not solve the issue for legacy parsers.)

---

Q7:

The draft does not give any guidance regarding how long an ICE agent can safely cache an mDNS 

---

Regards,

Christer

---

From: Youenn Fablet <[email-masked]>
Date: Tue, 25 May 2021 09:52:41 +0200

Thanks for the review,

Based on your review, I filed two issues at https://github.com/rtcweb-wg/mdns-ice-candidates <https://github.com/rtcweb-wg/mdns-ice-candidates>
Please see below for some answers.

> On 21 May 2021, at 19:49, Christer Holmberg <christer.holmberg=[email-masked]> wrote:
> 

Right, this is a (useful) restriction from mDNS though mDNS extensions could potentially alleviate this.
We might want to say this explicitly and detail that host candidates are useful for peers in the same local network as well.
I filed https://github.com/rtcweb-wg/mdns-ice-candidates/issues/133 <https://github.com/rtcweb-wg/mdns-ice-candidates/issues/133>.

> Related to Q1, think it needs to be more clear that the mechanism prevents IP address leaking to peers outside the local network. Inside the local network I assume that web apps can still find out…

Web apps cannot do mDNS lookups for privacy reasons.
It is a good thing for privacy reasons that a web page does not have access to its local address without some form of user opt-in.

> The draft makes an assumption that the mDNS domain names are unique. Why making that assumption? If the local network supports multicast, there may even be non-WebRTC applications using mDNS, which…

mDNS is supposed to handle name collision.
This spec relies on the mDNS specification to handle such cases, which I think is the correct layering.

> Section 3.1.1 says that an ICE agent, when it gathers candidates, generates a UNIQUE mDNS domain name. I assume that means that the mDNS domain name will only be valid for the duration of the ICE s…

For the lifetime of the ICE agent, this may be more than the ICE session.
Though there is no hard requirement, section 3.3.3 states that mDNS domain name lifetime should be scoped by the lifetime of the web page (agents are free to be stricter than that).

> Doesn't that mean that there is no need for other ICE agents to cache the mDNS domain name:IP address mapping for "future use", because the mDNS domain name won't be used in future anyway?

The idea is for ICE agents to keep alive their own mDNS name as long as needed.
ICE agents should not try to buffer other ICE candidate mDNS:IP mapping. This is an optimization that should be left to the mDNS layer.

> Also, I am not sure whether ICE implementations should cache mappings to begin with. That's the task of the mDNS client of the host.

Agreed.

>    "When an endpoint that supports mDNS communicates with a legacy endpoint that does not, the..."

I filed https://github.com/rtcweb-wg/mdns-ice-candidates/issues/134 <https://github.com/rtcweb-wg/mdns-ice-candidates/issues/134>.

> (NOTE: Eventhough the draft updates RFC 8839, to support mDNS domain names, it does not solve the issue for legacy parsers.)

In practice, deployment has not seen this issue, maybe because legacy parsers are not widely used in mode 3 applications, i.e. applications that do not access to any camera/microphone.
It seems fine mentioning legacy parsers in the document.
Let’s handle it in the same issue as above, https://github.com/rtcweb-wg/mdns-ice-candidates/issues/134 <https://github.com/rtcweb-wg/mdns-ice-candidates/issues/134>.

> The draft does not give any guidance regarding how long an ICE agent can safely cache an mDNS 

Are you referring to remote mDNS mapping? If so, I think we want to leave caching to the mDNS layer.

> Christer

Thanks again for the review.

> 
> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmusic

---

From: Justin Uberti <[email-masked]>
Date: Tue, 25 May 2021 12:38:13 -0700

On Tue, May 25, 2021 at 12:53 AM Youenn Fablet <youenn=
[email-masked]> wrote:

> Thanks for the review,
>
> Based on your review, I filed two issues at
> https://github.com/rtcweb-wg/mdns-ice-candidates
> On 21 May 2021, at 19:49, Christer Holmberg <
> christer.holmberg=[email-masked]> wrote:
>
> I think it needs to be more clear that mDNS domain names (.local) can only
> be resolved by remote peers within the same local network.
>
>
> We might want to say this explicitly and detail that host candidates are
> useful for peers in the same local network as well.
> I filed https://github.com/rtcweb-wg/mdns-ice-candidates/issues/133.
>
>
> Section 5.1 does talk about this, and it may be an implicit assumption,
> but I think it should be pointed out in the beginning of the document.
>
> ---
>
> Q2:
>
> Related to Q1, think it needs to be more clear that the mechanism prevents
> IP address leaking to peers outside the local network. Inside the local
> network I assume that web apps can still find out about the local address
> simply by performing an mDNS lookup on the mDNS domain name.
>
>
> It is a good thing for privacy reasons that a web page does not have
> access to its local address without some form of user opt-in.
>
>
> ---
>
> Q3:
>
> The draft makes an assumption that the mDNS domain names are unique. Why
> making that assumption? If the local network supports multicast, there may
> even be non-WebRTC applications using mDNS, which increases the risk for
> collision.
>
>
> Section 3.1.1 says that an ICE agent, when it gathers candidates,
> generates a UNIQUE mDNS domain name. I assume that means that the mDNS
> domain name will only be valid for the duration of the ICE session.
>
>
> Though there is no hard requirement, section 3.3.3 states that mDNS domain
> name lifetime should be scoped by the lifetime of the web page (agents are
> free to be stricter than that).
>
>
> Doesn't that mean that there is no need for other ICE agents to cache the
> mDNS domain name:IP address mapping for "future use", because the mDNS
> domain name won't be used in future anyway?
>
>
> ICE agents should not try to buffer other ICE candidate mDNS:IP mapping.
> This is an optimization that should be left to the mDNS layer.
>
>
> Also, I am not sure whether ICE implementations should cache mappings to
> begin with. That's the task of the mDNS client of the host.
>
>
> Agreed.
>
>
> ---
>
> Q5:
>
> Section 5.3 says:
>
>   endpoint will still provide its local IP addresses, and accordingly a
> direct connection can still be attempted,
> I filed https://github.com/rtcweb-wg/mdns-ice-candidates/issues/134.
>
>
> ---
>
> Q6:
>
> If I remember correctly, people have raised issues with legacy parsers not
> being able to parse non-IP-addresses. If so, shouldn't that be mentioned in
> Section 5.3?
>
> (NOTE: Eventhough the draft updates RFC 8839, to support mDNS domain
> names, it does not solve the issue for legacy parsers.)
>
>
> In practice, deployment has not seen this issue, maybe because legacy
> parsers are not widely used in mode 3 applications, i.e. applications that
> do not access to any camera/microphone.
> Let’s handle it in the same issue as above,
> https://github.com/rtcweb-wg/mdns-ice-candidates/issues/134.
>

As long as the legacy parser doesn't blow up the session, this will work
fine, as noted in the text.

We have seen one issue with a particular endpoint that did not implement
ICE prflx candidates and could not follow the guidance in the text. This is
already alluded to in S 4.3, but we may want to explicitly use the phrase
"peer-reflexive" to make clear what behavior is needed from the legacy ICE
agent.

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 26 May 2021 09:24:48 +0000

Hi,

Q1:

> I filed https://protect2.fireeye.com/v1/url?k=6f70db02-30ebe3e0-6f709b99-86073b36ea28-d422b5bab32889b5&q=1&e=65335060-b720-4a53-baa4-dfa1a047c81d&u=https%3A%2F%2Fgithub.com%2Frtcweb-wg%2Fmdns-ice-candidates%2Fissues%2F133.

Thanks! I will take a look.

---

> It is a good thing for privacy reasons that a web page does not have access to its local address without some form of user opt-in.

Well, maybe "web app" was too restrictive. You could also implement this in a native WebRTC app.

And, I assume even a web app can e.g., print the domain name on the screen, and the user can then use a separate resolver to get the IP address. Or, the web app can send the domain name to another server/service (within the local network) for resolving the address.

My point is that I think it is not possible that a remote peer *within the same local network* would not be able to figure out your IP address. I believe Tthere are even much simpler way of doing that than implementing a WebRTC app :)

---

>This spec relies on the mDNS specification to handle such cases, which I think is the correct layering.

In the draft you have explicit text saying that one does NOT need to use the mDNS way of handling collisions.

       "The ICE agent SHOULD send an mDNS announcement for the hostname,
       but as the hostname is expected to be unique, the ICE agent
       SHOULD skip probing of the hostname."

Also, in general when you say "unique", please define the scope of the uniqueness - both in time and place.

---

> The idea is for ICE agents to keep alive their own mDNS name as long as needed.

Ok.

Obviously, if the local IP address changes then the mapping has to be updated, but perhaps that is obvious.

> ICE agents should not try to buffer other ICE candidate mDNS:IP mapping. This is an optimization that should be left to the mDNS layer.

I don't even think an ICE agent should buffer its own mapping. Doesn't the local mDNS layer handle that?

---

Q5:

> I filed https://protect2.fireeye.com/v1/url?k=ab050196-f49e3974-ab05410d-86073b36ea28-dfd572b54682df12&q=1&e=65335060-b720-4a53-baa4-dfa1a047c81d&u=https%3A%2F%2Fgithub.com%2Frtcweb-wg%2Fmdns-ice-candidates%2Fissues%2F134.

Thanks! I will take a look.

---

> It seems fine mentioning legacy parsers in the document.

You can for sure mention "legacy parsers", and what your real-network experience is. But, the main point that also needs to be pointed out is a not-backward compatible *specification* change, and it is important to mention those.

> Let’s handle it in the same issue as above, https://protect2.fireeye.com/v1/url?k=c8ba4bed-9721730f-c8ba0b76-86073b36ea28-d633b680ca12acc8&q=1&e=65335060-b720-4a53-baa4-dfa1a047c81d&u=https%3A%2F%2Fgithub.com%2Frtcweb-wg%2Fmdns-ice-candidates%2Fissues%2F134.

Thanks! I will take a look.

---

> Are you referring to remote mDNS mapping? If so, I think we want to leave caching to the mDNS layer.

I guess so. There may be no WebRTC-specific considerations regarding the buffering.

So, perhaps the best thing is to not talk about ICE agents doing buffering etc, and perhaps only have a statement saying that the buffering/caching is taken care of by the mDNS layer, as defined in RFC 6762.

Thanks!

---

Regards,

Christer