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

[Esko Dijk <[e-mail]>]

Hello,



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



Best regards

Esko



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



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)

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

2.4.3.1
Typo: “Instrructions”

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

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?

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.


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.



“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!



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

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

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.

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


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


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?

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.


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)



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

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.

IoTconsultancy.nl  |  Email/Teams: [e-mail]<mailto:[e-mail]>