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

[Ted Lemon <[e-mail]>]

On August 17, 2021 at 10:33:00 AM, Lanlan Pan ([e-mail]) 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.

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

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.