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

From: Simon Lin <[email-masked]>
Date: Fri, 13 Aug 2021 11:08:20 +0800

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

What's the solution to resolve the case where an SRP client migrates
to be an mDNS client. When the mDNS client tries to advertise its DNS
service, it will conflict with the SRP server of the original SRP
client. I don't think SRP replication can solve this problem.

As Jonathan said, always using SRP regardless of whether the device is
connected via Thread or WiFi can solve this problem. Also maybe the
device can unregister itself from SRP when it has migrated to WiFi,
which requires the device to remember the IP address of the SRP
server, or to use draft-tljd-dnssd-zone-discover.

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

Agree that SRP replication is the most user-friendly way of addressing
this problem.

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

Does this strategy violate mDNS protocol? Moreover, if two different
devices register their service on different SRP servers using the same
name, it's not a good idea to not resolve the conflict since the
conflict will last for a long time.

> The only other alternative is to rename. I think this is too heavy of a
> solution, but I'm open to debate.

It increases the complexity on every device that needs to browse for
mDNS services. I would prefer SRP replication to renaming.

--
Simon  Lin

---

From: Ted Lemon <[email-masked]>
Date: Fri, 13 Aug 2021 04:19:37 -0700

> migrates from being an SRP client to an mDNS client or vice versa.

Interesting—I'm realizing I completely misread Martin's question. I was
assuming that this client would continue to be an SRP client, not switch
between SRP and mDNS.

I don't think dnssd-zone-discover helps with this. I think the client needs
to either unregister itself with SRP before migrating, or follow the same
protocol I mentioned earlier with respect to its service advertisement:
advertise without asserting uniqueness.

No, it's allowed. If two devices claim the same name, we're now assuming
that this conflict will be resolved out of band rather than through mDNS
conflict detection. TBH, the only time I've ever actually seen an mDNS
conflict happen outside of deliberate testing was when a single device was
connected through two interfaces to the same link and didn't know it.

On the other hand we see conflicts all the time with SRP because of the
two-SRP-server mDNS conflict detection algorithm, so it's pretty clear that
SRP + mDNS conflict detection is a recipe for creating conflicts.

This is a good point—SRP replication also increases complexity, but it
constrains it nicely to the more capable nodes on the network—the ones that
are acting as ad-hoc infrastructure and not as end nodes.

---

From: Jonathan Hui <[email-masked]>
Date: Fri, 13 Aug 2021 10:49:25 -0700

On Fri, Aug 13, 2021 at 4:19 AM Ted Lemon <[email-masked]> wrote:

> I don't think dnssd-zone-discover helps with this. I think the client
> needs to either unregister itself with SRP before migrating, or follow the
> same protocol I mentioned earlier with respect to its service
> advertisement: advertise without asserting uniqueness.
>
On Wi-Fi, the device needs to discover the SRP server. Why can't
dnssd-zone-discover help with that? If there is a single SRP server in the
network and it is servicing both Wi-Fi and Thread networks, we don't need
to deal with conflicts. If there are multiple SRP servers, then I hope SRP
replication will address the vast majority of cases.

> are acting as ad-hoc infrastructure and not as end nodes.
I hope SRP replication will eliminate the need for end devices to handle
conflicts directly. Hopefully we can get some operational experience as to
whether other mitigations are necessary.

--
Jonathan Hui

---

From: Ted Lemon <[email-masked]>
Date: Fri, 13 Aug 2021 13:07:11 -0700

On August 13, 2021 at 1:49:37 PM, Jonathan Hui ([email-masked]) wrote:

dnssd-zone-discover lets you discover DNSSD zones that you can browse. It
doesn't tell you about the SRP server. We need a different DNSSD
advertisement for that. Not a big deal.

Yes. Well, FWIW, my current code does both SRP replication _and_ doesn't
defend names, so we may be getting operational experience on both. :)

Another thing to be aware of is that because of the way mDNS works, if you
are using mDNS for discovery, a name conflict when names aren't being
defended will sit around in the cache for a few minutes. If names are
defended, this doesn't happen; one alternative is to just defend names and
count on SRP to deal with conflicts, but the downside of this is that now
there is a delay before the new information appears.

This delay could potentially be minimized by retrying to register as soon
as the SRP replication update has been acknowledged by all SRP replication
peers—right now my code (when name defense is enabled) just waits two
minutes before re-attempting, which is a lot longer than should be
necessary.

---

From: Jonathan Hui <[email-masked]>
Date: Fri, 13 Aug 2021 15:24:39 -0700

On Fri, Aug 13, 2021 at 1:07 PM Ted Lemon <[email-masked]> wrote:

> doesn't tell you about the SRP server.
>
Ah, yes, I was confused. Thanks for clarifying.

> We need a different DNSSD advertisement for that. Not a big deal.
>
Yes, agreed.

> defend names, so we may be getting operational experience on both. :)
That's great to hear!

> minutes before re-attempting, which is a lot longer than should be
Sounds like a good idea to explore. My initial concern is that waiting for
positive confirmation from all peers can lead to other failure modes
resulting from poor implementation or connectivity. At the same time, those
same assumptions are what would lead us back to needing other mitigations.

--
Jonathan Hui

---

From: Ted Lemon <[email-masked]>
Date: Sat, 14 Aug 2021 00:40:34 +0200

On August 13, 2021 at 6:24:51 PM, Jonathan Hui ([email-masked]) wrote:

The problem with anything that's ad-hoc and not integrated into the
infrastructure is that there's no model that guarantees success. It's
always going to be best effort. The goal has to be to make "best" as good
as possible, but have a backup strategy for when it's not quite good enough.

---

From: Simon Lin <[email-masked]>
Date: Mon, 16 Aug 2021 15:40:32 +0800

> On the other hand we see conflicts all the time with SRP because of the two-SRP-server mDNS conflict detection algorithm, so it's pretty clear that SRP + mDNS conflict detection is a recipe for creating conflicts.

Could you explain why there are so many conflicts because of
two-SRP-server mDNS conflict detection algorithm?

Are the SRP servers using SRP Anycast TLV or Unicast TLV?

I would expect name conflicts to happen more often if SRP servers are
using Anycast TLVs because a SRP client can change SRP server for each
registration or renewing.

When SRP servers are using Unicast TLV, a SRP client should stick to
the same SRP server for registration and renewing, even after the SRP
client is rebooted.
A SRP client may change SRP server when there are multiple request
failures, but I would expect it to be less often.
So, I would not expect many name conflicts for SRP servers using Unicast TLVs.

On Sat, Aug 14, 2021 at 6:40 AM Ted Lemon <[email-masked]> wrote:
>> Another thing to be aware of is that because of the way mDNS works, if you are using mDNS for discovery, a name conflict when names aren't being defended will sit around in the cache for a few minutes. If names are defended, this doesn't happen; one alternative is to just defend names and count on SRP to deal with conflicts, but the downside of this is that now there is a delay before the new information appears.
>>
>> This delay could potentially be minimized by retrying to register as soon as the SRP replication update has been acknowledged by all SRP replication peers—right now my code (when name defense is enabled) just waits two minutes before re-attempting, which is a lot longer than should be necessary.
>
> Sounds like a good idea to explore. My initial concern is that waiting for positive confirmation from all peers can lead to other failure modes resulting from poor implementation or connectivity. At the same time, those same assumptions are what would lead us back to needing other mitigations.
>
> The problem with anything that's ad-hoc and not integrated into the infrastructure is that there's no model that guarantees success. It's always going to be best effort. The goal has to be to make "best" as good as possible, but have a backup strategy for when it's not quite good enough.
>
>
> _______________________________________________
> dnssd mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnssd

---

From: [email-masked]
Date: Mon, 16 Aug 2021 08:17:20 -0700

It generally only happens when the thread omr prefix changes. So in
production network it should be rare. But the thread network can fluctuate
a bit on startup as the mesh settles, and this can result in changes to the
omr prefix. So although this shouldn’t happen much, the time when is is
most likely is right after a power outage or right when the devices are
first installed.

-- 
[email-masked]

---

From: Simon Lin <[email-masked]>
Date: Tue, 17 Aug 2021 10:10:47 +0800

> It generally only happens when the thread omr prefix changes. So in production network it should be rare. But the thread network can fluctuate a bit on startup as the mesh settles, and this can result in changes to > the omr prefix. So although this shouldn’t happen much, the time when is is most likely is right after a power outage or right when the devices are first installed.

Agree that OMR prefix can change for Thread devices of one partition
when two partitions converge.

Are you implying that the SRP server IP address in the SRP Unicast
Dataset is using the OMR address of the SRP server?

In such a case, an OMR prefix change would lead to SRP server IP
change in Unicast Dataset, which further lead to SRP clients having to
switch SRP server IP.
However if the SRP servers are using ML-EIDs in Unicast Dataset, the
SRP server IP won't change when partitions merge, which will lead to
less SRP server switches on SRP clients.

Nevertheless, if a SRP client migrates from one partition to another
and each partition has a different SRP server, the SRP client will
have to reregister, which will cause name conflicts (assuming no SRP
replication).

So, it's foreseeable that partitioning may cause many SRP name
conflicts when SRP replication is not adopted. That being said, can we
argue that SRP replication is less useful when TREL can significantly
reduce the chance of partitioning?

--
Simon Lin

Simon Lin | Software Engineer, Nest Shanghai | [email-masked] |
+86 13656630312

On Mon, Aug 16, 2021 at 11:17 PM <[email-masked]> wrote:
>
> It generally only happens when the thread omr prefix changes. So in production network it should be rare. But the thread network can fluctuate a bit on startup as the mesh settles, and this can result in changes to the omr prefix. So although this shouldn’t happen much, the time when is is most likely is right after a power outage or right when the devices are first installed.
>
> --
> [email-masked]
>

---

From: Jonathan Hui <[email-masked]>
Date: Mon, 16 Aug 2021 19:36:56 -0700

> reduce the chance of partitioning?

It's not clear to me whether TREL would eliminate partitioning/merging
during network formation (e.g. after a power outage).

Regardless, SRP replication provides other benefits beyond avoiding name
collisions when SRP clients change servers.

--
Jonathan Hui

---

From: Lanlan Pan <[email-masked]>
Date: Tue, 17 Aug 2021 22:32:48 +0800

> advertisement: advertise without asserting uniqueness.
+1,  advertise without asserting uniqueness.
To join in a Thread zone,  srp client should be authenticated through
J-PAKE or other protocols. the srp client only its own the srp server, the
srp server can only ensure the uniqueness in its zone, but not asserting
the uniqueness with other zones.
If srp client migrating to a mdns client, just follow the mdns conflicts
policy.

---

From: Ted Lemon <[email-masked]>
Date: Tue, 17 Aug 2021 15:46:20 -0700

On August 17, 2021 at 10:33:00 AM, Lanlan Pan ([email-masked]) wrote:

Actually that's not really an issue we address. Yes, on a network like
Thread, the commissioning process guarantees that the client has the right
to connect, but it doesn't guarantee a unique hostname. Some other part of
the onboarding process might do that, or might not, but SRP doesn't really
pay attention to that. Rather, devices are expected to have a unique
public/private key pair that's used to claim the name, and conflicts are
detected by noticing that the client making a claim to a name has signed
their claim with the wrong key (wrong meaning not the key that was used
last time). And then that client doesn't get the name. This is FCFS naming.

As long as there is a single SRP namespace, it's fine for it to span more
than one network link, because the FCFS naming process ensures that there
will be no duplicate names. If a device moves from Thread to WiFi, we want
it to keep the same name.

The problem is that mDNS currently lacks the capability to defend names
using FCFS, and so when this roaming occurs, if there is an overlap between
the lifetime of the SRP registration and the lifetime of the mDNS
advertisement, we need a strategy for dealing with that.

The strategy I'm proposing is that we allow the conflict to exist, and let
the application figure out which information to use. Ultimately though we
want WiFi clients to use SRP, with FCFS naming, and that solves the problem.

We could do what the Discovery Proxy does and give each link its own name,
but I didn't suggest going that route because I think it's confusing. Is a
device with the same name in a different domain the same device that's
moved to a different network, or a different device? The application still
has to figure this out, so we haven't gained anything. Additionally, the
app needs to do more work, because now it has to have a list of domains to
query (or the API for finding names has to know to query multiple domains).

Also, with that model, when a device roams to a new link, until it's
discovered to have roamed, there is no name the app can use to immediately
reference the device, because now the name changes from link to link. So
the app has to always be doing discovery just to find the device when it
roams, even if it isn't interested in other devices that have the same
service type.

So that's why I tend to prefer the model where we do our best to avoid
conflicts, but when we have duplicate information, we allow it to coexist.
The app should be able to fairly easily figure out which information to
use, and the period of coexistence should be brief, so if there is a cost
to disambiguating, it will be paid only infrequently.

---

From: Lanlan Pan <[email-masked]>
Date: Wed, 18 Aug 2021 23:05:19 +0800

> it to keep the same name.
Thank you for the clarification.

> want WiFi clients to use SRP, with FCFS naming, and that solves the problem.
allowing conflict at Public WiFi may be better for user privacy ? or WiFi
clients using SRP with FCFS naming is an opt-in in a smart home environment
?

> to disambiguating, it will be paid only infrequently.
Yes, the discovery is the base cost.
If the app and the device exchanged some trust credentials (TOFU public
key/psk/...), it can know the real device when it finds two devices with
the same name. If the app trusts anything without authentication, then
there may be some problem.