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

[Christer Holmberg <[e-mail]>]

Hi,

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.
>
> 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://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%2F133issues%2F133.

Thanks! I will take a look.

---

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.
>
> 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.

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 :)

---

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.
>
>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.

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.

---

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.
>
> 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.

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:

>> 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..."
>
> 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%2F134issues%2F134.

Thanks! I will take a look.

---

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.
> 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%2F134issues%2F134.

Thanks! I will take a look.

---

Q7:

>> 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.

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