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

[Ted Lemon <[e-mail]>]

On Oct 13, 2020, at 9:40 AM, Esko Dijk <[e-mail]> 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.