Subject: Re: [dnssd] Adoption call for draft-sctl-advertising-proxy

From: Martin Turon <[email-masked]>
Date: Thu, 12 Aug 2021 03:31:24 -0700

Hi All,

I'm writing to offer my support for adopting
draft-sctl-advertising-proxy-02
<https://datatracker.ietf.org/doc/html/draft-sctl-advertising-proxy-02>
by the workgroup.  I have read and reviewed the document and view it
as ready to publish.

The advertising proxy provides an important optimization for a
foundational IoT use case -- bridging legacy multicast DNS clients on
WiFi with unicast SRP clients on a stub network such as Thread, and
allowing seamless service discovery across both scopes.  As mentioned
by others, the Matter <https://buildwithmatter.com/> standard is
planning to leverage this work heavily, and an open source
implementation <https://github.com/project-chip/connectedhomeip> of
the work based on this draft is underway now in that forum.

A few minor comments to note from this final review:

1) *Editorial*: "provide with" is awkward phrasing. Remove "with" or
possibly add a word/object.

In order to address this problem, it may be advisable to *provide with*

   a way for the advertising proxy to inform the mDNS service that it

   should continue to advertise the name that is in conflict, rather

   than ceasing to do so when the conflict is detected.

2)  *Editorial*: as Nathan mentioned, "may made" should be "may make"
in the Security Considerations section:

   An Advertising Proxy *may made* data visible to eavesdroppers on the
   configured multicast-capable link(s).

3) *Question:* Regarding "2.1.1
<https://datatracker.ietf.org/doc/html/draft-sctl-advertising-proxy-02#section-2.1.1>.
Name Conflicts in Managed Namespaces"

Is the case of a device conflicting with itself handled? Specifically,
imagine a dual-radio device (WiFi and Thread) which for some reason
migrates from being an SRP client to an mDNS client or vice versa.  When
the device tries to re-register its services to direct to its new,
renumbered IP addresses, could its own stale records on the proxy possibly
lock it out?

Thank you for the good work here, Stuart and Ted!

Regards,

Martin

_____________________________
Martin Turon  |  Google

---

From: Ted Lemon <[email-masked]>
Date: Thu, 12 Aug 2021 07:58:01 -0700

On August 12, 2021 at 6:32:47 AM, Martin Turon (
mturon=[email-masked]) wrote:

This is exactly the discussion I think we want to have.

With a single SRP server, this is a non-problem: the SRP First-Come,
First-Served Naming mechanism guarantees that if the same client registers
twice, it will be recognized the second time and its update will supersede
the previous registration, rather than conflicting with it.

With multiple SRP servers, we have a problem because the SRP client might
register with a different SRP server the second time, since it has no idea
it's connected to the same infrastructure (and indeed the SRP server
contact mechanism may be different, so that which server is updated is
non-deterministic or just not under the client's control). In this case,
we'll see a conflict when the second update comes in.

The way I'm currently proposing to address this is by requiring SRP
replication when there is more than one SRP server, and by not renaming,
but rather waiting for the conflict to resolve. With SRP replication, we
can use FCFS naming to see that it's actually the same client doing the
update, so there's no conflict at the SRP level. The only conflict is in
mDNS. When the SRP update propagates to the SRP server with the conflicting
data, that SRP server will remove the old data and replace it with the new,
which eliminates the conflict.

I think this is pretty tight; the only problem is that it does rely on SRP
replication working well. If SRP replication gets wedged, then the conflict
won't be resolved until the old data expires. This is not great, of course.

An additional mitigation strategy is to not actually detect conflicts. If
we have two conflicting registrations, and SRP replication doesn't resolve
them, then they just coexist until one goes away. This should happen when
the old SRP lease expires. This means that the consumer of the data has to
be smart about it: if there are conflicting TXT records, it needs to have a
strategy for choosing which one to trust. If there are conflicting address
records, it needs to do happy eyeballs.

The only other alternative is to rename. I think this is too heavy of a
solution, but I'm open to debate. The problem is that if we rename, we now
have two advertisements for the same accessory, so we're pretty much in the
same place we'd be with the "don't detect conflicts" strategy, except that
we have a gratuitous extra name.

So consumers of the data now have to use some other identifier than the
name to uniquely identify the device, and if there are two advertisements
under two different names that present the same identifier, we now have to
have a browse going to detect that, whereas if we don't change the name,
dealing with an unresolved conflict is a lot simpler.

With that said, that's just my thinking on this, and I'd really like to get
more eyes on this problem.

---

From: Jonathan Hui <[email-masked]>
Date: Thu, 12 Aug 2021 10:43:40 -0700

> the previous registration, rather than conflicting with it.
To address the case where a device may transition between Thread and Wi-Fi
networks, having the device leverage SRP regardless of whether the device
is connected via Thread or Wi-Fi would also resolve any conflicts that
might occur. Fortunately, SRP on Wi-Fi is something that you're already
addressing with draft-tljd-dnssd-zone-discover.

> won't be resolved until the old data expires. This is not great, of course.
I agree that SRP replication is an elegant solution in concept. I'd like to
get some implementation/operational experience on how well it works in
practice.

> records, it needs to do happy eyeballs.
If there's no good way to invalidate the old entry, then I think presenting
both is the next best solution - it at least makes it possible to continue
communicating with the service. Although, as you noted, it requires extra
work by the consumer of the service data.

> dealing with an unresolved conflict is a lot simpler.
I agree. I don't see much value in renaming to address these self-conflict
scenarios.

--
Jonathan Hui