Re: [dnssd] Review of draft-ietf-dnssd-srp-04; and relation to CoRE Resource Directory

[Ted Lemon <[e-mail]>]

On Nov 3, 2020, at 6:32 AM, Esko Dijk <[e-mail]> wrote:
> Looking forward to the updated version – I will review the changes some time after you have posted it.

Great, thanks. I may just put it up somewhere else, but it’s easier if it’s in the datatracker.

> And below further responses to your reply:
>  
> > Stuart and I discussed this at length with the author of that document. It’s not as simple as it sounds. First, there are no common set of parameters to publish in core RD, so any translation would have to be based on heuristics.
>  > But Core RD and DNS-SD have fairly different core assumptions, and as a consequence, there didn’t seem to be an obvious mapping.
>  
> Yes I recall from one of the authors that doing this mapping is hard, if not impossible. In my view it might still work if we assume a limited subset of DNS-SD semantics that can be mapped to a limited subset of CoRE-RD semantics, and vice versa.  (Under the assumption that this still would be relevant for the applications/systems that would use either DNS-SD or CoRE for their initial, basic service discovery…)   As an example of a subset, the CoRE RD draft since -14 defines a subset of the CoRE Link Format that it aims to support, given that the full format was too complex for developers to get it right and even was hard for the experts to agree on interpretation. So doing some understandable subsets may be the only way – or give up on the idea.  In the RD case the full Link Format can still be used but leads to implementation-specific behavior of the RD in case statements are used that go beyond the subset. 

> > One problem is that DNS-SD has semantics, which Core RD doesn’t. DNS-SD has a bit of free-form additional data in the form of the TXT record, but most of the data is structured and is just about finding a service. Core RD is a lot more general than that.
>  
> True; it would be interesting for me to learn these semantics and see how they could map to CoRE Link Format. Because Link Format is extendible (RFC 6690 , inherits Web Linking RFC 5988, which inherits RDF, so new relation types with specific semantics can be freely defined. ) this can be defined.
> Vice versa some CoRE Link Format semantics would need to be removed in the translation to DNS-SD probably, but the basic service discovery aspect (in Link Format this is the “hosts” relation type) could be at least attempted.


The semantics of DNS-SD are detailed in RFC 6763. Briefly, services are identified by service type, which is generally something like _hap._udp, indicating both the service and transport. Services are discovered in domains. For any given domain, the list of services of a particular type can be found by querying for PTR records on the name <service type>.<domain>. Each PTR record points to a service instance: a specific instance of the service being discovered. The target of the PTR record is a name; on this name there should be an SRV record and possibly also a TXT record. The SRV record’s target name should have one or more A and AAAA records, which indicate which host to contact; the SRV record has the port. The TXT record contains a list of name/value pairs, so basically a dictionary. The data is just text—it’s not typed.

So when you get a service list, you choose a service from that list, and then to resolve it you look up the service instance and the host records. This gives you the information you need to contact the service and possibly some information _about_ the service instance other than the protocol it uses (that’s the service type).

In order to map this into Core RD, I think you’d need a single data structure for enumerating services, which could just be a dictionary keyed by service type. For each type, there would be an array of instance names. Instances would be looked up in a second dictionary, with the instance name as key. For each instance, you’d have a dictionary with at least three keys: hostname, port and parameters. Parameters would be a dictionary with arbitrary key names, and each datum would be a text string. And then you’d need a dictionary keyed by hostname, each element of which would be an array of IP addresses.

To be honest, I’m not convinced that there’s much utility than this.

> >  > The term “SRP client” is used, sometimes for the registering service’s host and sometimes for a client using only the service lookup function.
> > > Is that correct? Should it be explained in a terminology section? And we have also above DNS-SD registration protocol client.
> > > Also “SRP server” vs “SRP Server” are both used.
> > 
> > Fixed the latter. I didn’t find any instances of the former—can you point me to one in the update?
>  
> Looking at the text (-05) again, I see that ‘client’, ‘SRP client’ and ‘DNS-SD registration protocol client’ are used for mostly the same concept – the SRP client publishing the service. The lookup aspect only appears in Section 1 text
> “Once published, these services can be readily discovered by clients using standard DNS lookups” . Here it is clear that the client is as a standard DNS client when doing this so no ambiguity.
> In Section 3.2 I was thinking that the ‘client’ here getting the response from the ‘DNS server’ must be a DNS client because it did not say ‘SRP server’ here. We could change here ‘DNS servers’ to ‘SRP servers’ just to be clear.
> (Because the lookup function is not described in this draft but in other RFCs – standard DNS-SD or mDNS queries etc – the possibility of confusion is currently minimal though.)

I’m seeing it now. I’ve gone through and specifically qualified each instance, and also clarified some text that talks about updates from SRP clients and also from non-SRP DNS Update clients.
 
> 
> > > 3.2 This says nothing about the SIG(0) validation required by the SRP server. That seems strange, given the title?
> > > Title could be changed to e.g. “validating SRP server responses”.  And perhaps add some SIG(0) validation considerations by the SRP server, if we have any. (E.g. avoid certain algorithms?
>  > > Try only one or try multiple? Maybe the key already encodes the used algorithm – I didn’t look into that; in which case there could be invalid algorithms or  parameters specified etc.)
> >
> > It’s pointing out a limitation, so there’s no need to mention the case where the limitation is not present.
>  
> What about changing the title for this section 3.2 to “SRP Server Response Validation” ?  That would fit the current text best.
> Forget what I said about the selection of SIG(0) algorithms because that’s already in 3.3 I see.

Probably authentication rather than validation, but yes, that makes sense. I’ve updated.

> > > The constrained devices would use UDP to register and also to query for services possibly, so I would expect an "_dnssd-srp._udp.<domain>." to be defined at least.
> > > Even if on the constrained network there may be a custom way to provide the host/port of the SRP server to nodes.  After all it *might* use DNS-SD format to distribute such information, or not?
> > > Another consideration: if UDP is supported, then UDP+DTLS may be too?  Although that would severely increase the resource usage (power, network bandwidth) of constrained devices perhaps we don’t want to rule that out.
> > 
> > We’re assuming this is discovered using a network-specific mechanism.
>  
> Agree; it will be network-specific and it may not involve a DNS-SD description at all. E.g. just an IP address and a port configuration. Some of these network-specific means may in the future use DNS-SD descriptions to publish / ‘push’ available network services to clients.
> And one of these services may be a UDP-based SRP server where the client can then choose to register. Then this description would use "_dnssd-srp._udp.<domain>."  , however this is not formally defined in the IANA Service Names registry so the people doing this
> would have to register that entry.  That is still okay, though I considered it better if the present draft would already formally reserve the service name "_dnssd-srp._udp.<domain>." for this purpose just to be complete.

The assumption in the document is that if you can do DNS service discovery, you can do the update using TLS+TCP. This assumption may be unwarranted, but FWIW the only use case so far for SRP over UDP is on Thread, and I really don’t want to make Thread clients go through a series of DNS queries to identify the local browsing domain. That said, we may want to rethink that—I’m not at all sure that I have that right, particularly since we will probably be using DNS-SD for off-mesh service discovery anyway. But the thing I don’t want to have happen is for the UDP and TCP services to be treated as interchangeable.
 
> Another argument why this is needed is the following: the present draft says RFC 2136 is the way for the client to send its DNS updates to the SRP server. And that defines both UDP and TCP. If we want to nudge people towards using TCP and not UDP where possible, then 
> this should be made explicit I think in Section 2.3.1 – add a bullet “Clients SHOULD/MUST use TCP”.  If UDP and TCP are treated as equals as in RFC 2136 then I would assume both need to be supported as well for the SRP server, potentially.
> So is it intended that the non-constrained clients can only discover the TCP-based SRP server, and not the UDP-based SRP server? If so then only defining the TCP-based service description is enough.
> Note: I’m assuming in the above that TCP/UDP based services of SRP server are separately advertised in DNS-SD if both are present, but I may be totally wrong here. If I’m wrong then please ignore this argument.

Yes, that’s the theory. :)

>  
> > Unless CoRE RD does something like FCFS naming, for instance, it would likely be quite a bit more compact.
>  
> RD does have FCFS naming but – because there is no default security solution – it is rather indirectly defined.  RD draft says that registering clients MUST use unique names and points to some mechanisms for clients to generate random UUID names in case there first attempt at registration with a name failed.
> The case where no security is used becomes also tricky then; as the RD server may be unable to distinguish a name-collision from a legitimate client making a service update. The expectation there is that clients will choose random / UUID names in that case to push the probability of collision to 0%. (Doesn’t work against attackers.)
> And RD’s Link Format can in some cases be rather inefficient – there’s now an effort to define a new binary format CoRAL that could replace it.  An RD could handle both Link Format and CoRAL in principle.

I think moving from name to identifier makes a fair amount of sense, as long as there is a way to say what should be displayed in the UI. For IoT devices you’re going to have dozens of light bulbs, as an example, so it makes sense to have a type of light bulb rather than a name of light bulb.