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

[Justin Uberti <[e-mail]>]

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

> Thanks for the review,
>
> Based on your review, I filed two issues at
> 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=[e-mail]> wrote:
>
> 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.
>
>
> 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.
>
>
> 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.
>
>
> 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.
>
>
> ---
>
> 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.
>
>
> ---
>
> 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.
> 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:
>
>   "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://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.
> 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.
>

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.

>
>
> ---
>
> 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.
>
>
> ---
>
> Regards,
>
> Christer
>
>
> Thanks again for the review.
>
>
> _______________________________________________
> mmusic mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mmusic
>
>
> _______________________________________________
> mmusic mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mmusic
>