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

From: Ted Lemon <[email-masked]>
Date: Mon, 2 Nov 2020 19:16:19 -0500

On Oct 13, 2020, at 9:40 AM, Esko Dijk <[email-masked]> wrote:
> I’ve reviewed recently SRP draft-ietf-dnssd-srp-04 and also CoRE resource directory (draft-ietf-core-resource-directory, latest Github draft) to see if these are applicable service discovery solutions for constrained devices (specifically 6LoWPAN wireless mesh network nodes, that may operate using the Thread protocol or other). For SRP see the results of my initial review below; hope this helps in improving the document further.
>  
> Both SRP and RD target similar use cases. It would be interesting to understand if services registered under one format (e.g. DNS-SD SRP) can be queried/discovered using another format (e.g. CoRE RD); but that’s future work for me. (draft-ietf-core-rd-dns-sd already provides a start for this.)

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

My conclusion, which I think Stuart shared, is that there isn’t a lot of commonality: it actually seemed to us to make a lot more sense to use DNS-SD as a way to discover the local Core RD server; this would for example allow multiple Core RD servers to be advertised in the case that, as appears to be the case, different application layers require different versions of Core RD.

That said, this is indeed out of scope, but I think it’s an interesting question that should be explored.

> --- Review -04
> Overall: the draft nicely builds on existing/other components in IETF and SRP looks like a potentially good solution for IoT/constrained devices.
>  
> Section 2
> "_dnssd-srp._tcp<zone>"
> "_dnssd-srp-tls._tcp<zone>"
> -> these should have "_tcp.<zone>" with a dot before <zone>, right? 

Sure, that makes sense. I think the &lt; confused things a bit. :)
 
> Section 2 text (up to the 2.1 header) could be more clearly split in the two variants: full-featured host, and constrained host. Initially I was confused here by the mixture of both, thinking that the constrained devices also needed to use DHCPv4 Domain Name option or ND DNS Search List option.
> But later it turns out this isn't needed and these MAY use the default domain only. Creating a new Section 2.1 with two subsections would solve this e.g.
> 2.1 Protocol variants
> 2.1.1 Full-featured hosts
> 2.1.2 Constrained hosts  (or: Constrained nodes)

That’s a nice clarification—thanks!

> 2.4.1 / 2.4.1.1
> What seems to be missing in these sections is the service’s host required or recommended behavior, in case the registration fails. For example if the name is already taken by another device, what would it do? E.g. define a new name?
> (At this point in the draft the reader doesn’t yet know how the SRP server will compare the to-be-registered name(s) to existing name(s) in the registry. E.g. is it based on checking Service Instance Name only? I would expect that described in 2.4.3 somewhere.)

Good point. I have added text.

> 2.4.3.1
> Typo: “Instrructions”

Fixed.

>  
> 2.5
> “The TTL should never be longer than the lease time Section 2.6.1”
> -> typo? Change to e.g. “The TTL should never be longer than the lease time (see Section 2.6.1).”

Fixed

>  2.6.1
> “  A default  limit of two hours for the Lease and 14 days for the SIG(0) KEY are currently thought to be good choices.”
> -> this is interesting to compare to the assumptions of CoRE Resource Directory default lease time, which is 25 hours.
> That is quite a large difference. Since both specs target constrained nodes, I would expect the values to be closer?
> Is the 25 hours too long, or the 2 hours too short?

I suspect that the CoRE RD lifetime is aimed at sleepy end devices as a default, where SRP is aimed at powered devices as a default. Since this is just a default, it makes a lot of sense that a sleepy end device would negotiate a (possibly much) longer lease.  I’ve added some text pointing out that this is a negotiable time period and specifically mentioning sleepy devices.
 
> What I do like a lot in this draft is that the SRP server can shorten or lengthen the lease time, and the client honors this. CoRE RD doesn't have this feature!
> This provides an ‘out of the box’ standard method for higher adaptivity to different use cases, if needed.

Yup. My DHCP roots showing, perhaps. :)
 
> 2.6.2 Sleep Proxy
> This triggers some questions:
> It is mentioned that the sleep proxy may be on another link. How would a SRP server set up a sleep proxy on another link than the one it is currently attached to? How would it know what link to choose to set it up?
> How would a service’s host know that the server is capable to do this? If it doesn't know then it cannot trust the mechanism to work and go to sleep.
> Or, is there a way for the SRP server to reject an update with EDNS(0) OWNER option such that the service’s host knows not to use it again?
> Overall, is sleep proxy support mandatory for the SRP server? This seems not clear.

Remember that SRP is a registration protocol. It is not necessary that the SRP registration service and the DNS server that is answering queries be the same server; DNS for example provides the idea of primary and secondary, where the secondary replicates the primary’s database. That said, I’m somewhat inclined to say that Sleep Proxy should be a separate document, because I think this is a lot less baked than the rest of this document, and I don’t want to delay this document because of the state of Sleep Proxy.
 
> “When a DNS server receives a DNS Update with an EDNS(0) OWNER Option, that
>    signifies that the SRP server should set up a proxy”
> -> is there a difference between DNS server and SRP server? Is it the same entity here?
> We also have “SRP function” that a DNS server can implement. Some clarification of terms could help here!

This is a good point. I’ve clarified that at the top of section 2.
 
> 3.1
> “For Anycast updates, this validation must be enforced by every router”
>  -> to clarify this a bit, e.g. "For updates sent to an anycast destination IP address of an SRP server"
> ( Someone might be thinking otherwise about updates to anycast addresses?)

I’ve clarified.

>  
> "DNS-SD registration protocol clients"
> -> is this the same as SRP clients?

Yes, good catch.

>  
> 3.2 and entire document
> 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?
 
> 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.
 
> 3.3.
> "SRP servers SHOULD implement the algorithms ... starting with algorithm number 13"
> -> is somewhat ambiguous.  Can be interpreted in the extreme case as a server SHOULD implement algorithm 6 , even though RFC 8624 says it MUST NOT do this.
> To be clearer it could be rephrased to 
> "SRP servers SHOULD implement all algorithms specified in [RFC 8624] section 3.1 that are numbered 13 or higher and have a "MUST", "RECOMMENDED", or "MAY" designation in the validation column of the table."
> (The expression “starting with … number X“ feels less familiar to me as a non-native speaker. Is it equal to “X and higher numbers” ? Or do I have to start with X.)

Nice.

>  
> 5
> I don't understand the full details of what is requested here – but looking on high level it says "there must be a delegation".
> For whom is this requirement?  Implementers of SRP servers, system admins, or IANA, ICANN , ... ?
> It seems 6.1 already has the IANA part of the requirement. Are there explicit requirements on others?

Good point. I’ve added some clarification.
 
> 6.2 / 6.3
> why no UDP service description?
> 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.
 
> 6.4
> address "TBD1" is not used in the rest of the document. I think there should be outside section 6 a section that describes the usage of TBD1.
> (Can be short)

I’ve updated this section because it was actually pretty bad. However, we haven’t specified a use for the anycast address; the point of the IANA request is to allocate it so that it can be used in situations where it is needed.
 
> References
> RFC 2136 needs to be a normative reference. Just searching for "2136" in the text reveals many places where it is pointed to RFC 2136 for normative operation.
> RFC 2931 (SIG(0)) needs to be a normative reference.  The SRP server performs this validation and it is mandatory to perform it. Also service-publishing clients need to add the signature always.
> RFC 7858 is also normative for the same reasons.
> [I-D.ietf-dnssd-push] needs to be a normative reference too, as in Section 2 the full-featured devices are required to use it to "discover the zone apex of the closest enclosing DNS zone using SOA queries".
> replace [I-D.ietf-dnssd-push]  -> RFC 8765
> update [I-D.ietf-dnsop-algorithm-update] to RFC 8624

Wow, thanks for going over those. I apologize for not catching these earlier.

> Appendices
> An example ‘service description’ for an IoT device and its encoding (e.g. size of entire UDP registration message) would be of interest here. (Not required of course, but nice to have)
> This could facilitate some initial comparison against CoRE RD.

I don’t see the two protocols as being in competition, so I think this would be confusing. Unless CoRE RD does something like FCFS naming, for instance, it would likely be quite a bit more compact.

---

From: Ted Lemon <[email-masked]>
Date: Mon, 2 Nov 2020 19:17:14 -0500

Oh, two things I forgot to say in the reply. First, thanks very much for the thorough and thoughtful review. It is much appreciated.

Secondly, I am afraid that I left it too late and missed the posting deadline. Not sure what to do about that in the short term, but I will upload it as soon as I can.

---

From: Esko Dijk <[email-masked]>
Date: Tue, 3 Nov 2020 11:32:39 +0000

Hello Ted,

Looking forward to the updated version – I will review the changes some time after you have posted it. 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.

> I suspect that the CoRE RD lifetime is aimed at sleepy end devices as a default, where SRP is aimed at powered devices as a default.

Agree, CoRE targets constrained devices including sleepy devices – and probably less dynamics e.g. a sensor that just sits at one location 24/7 and wakes up once in a while.

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

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

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.

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

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.

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

Esko

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Tue, 3 Nov 2020 12:45:57 +0000

> Oh, two things I forgot to say in the reply. First, thanks very much for the
> thorough and thoughtful review. It is much appreciated.
> 
> Secondly, I am afraid that I left it too late and missed the posting deadline.
> Not sure what to do about that in the short term, but I will upload it as soon
> as I can.

Hi Ted,
Since dnssd isn't meeting in IETF 109, the posting deadline isn't highly relevant. But perhaps after you do post something, it might be good to schedule an interim.
Thx,
Barbara

---

From: Ted Lemon <[email-masked]>
Date: Tue, 3 Nov 2020 08:07:41 -0500

I think that would be good, yes.  There will be a bunch of additional stuff to work on—the srp updates are just the beginning. Some of this stuff potentially implicates homenet as well. 

FYI what’s coming is more on the advertising proxy, a way to discover local advertising proxies, a way to add replication to a local (unmanaged) SRP service, and possibly more. So yeah, it would be good to do an interim so we can get all that out on the table and talk about it. :)

> On Nov 3, 2020, at 07:46, STARK, BARBARA H <[email-masked]> wrote:
> 
> 
>>

---

From: Ted Lemon <[email-masked]>
Date: Wed, 18 Nov 2020 11:53:18 -0500

On Nov 3, 2020, at 6:32 AM, Esko Dijk <[email-masked]> 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:
>  

> 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)…

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.

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

> 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 purpo…

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

Yes, that’s the theory. :)

> 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 pri…

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.