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

[Lanlan Pan <[e-mail]>]

Ted Lemon <[e-mail]> 于2021年8月18日周三 上午6:46写道：

>
> 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.
>
Thank you for the clarification.


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

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