Subject: [dnssd] Review of draft-ietf-dnssd-srp-02

From: Jonathan Hui <[email-masked]>
Date: Thu, 8 Oct 2020 12:19:11 -0700

I have reviewed this document.

I believe this document addresses a real pain point in constrained networks
- namely how constrained devices can publish services with minimal round
trips (i.e. one per update) and avoids the need for expensive multicast.
This is of great interest to the Thread Group and Project CHIP efforts,
both of which are based on IPv6.

Overall, I found the document well-written and easy to understand.

Detailed comments/questions below:

Intended status: Informational

Why not standards track?

[RFC6763] that allows services to automatically register their

It's not clear to me at this point what "automatic" really means. It
becomes clear later in the doc (e.g. Section 2.6.1), but I think it would
help to be clear in the Introduction.

Manual configuration of the registraton domain can be done either by

Typo: "registraton" -> "registration"

using UDP unless TCP is required due to the size of the update.  It
> is the responsibility of a Constrained-Node Network supporting SRP to
> provide appropriate anycast routing to deliver the DNS updates to the
> appropriate server.  It is the responsibility of the SRP server
>

Is "appropriate" well-understood here? I could use some clarification on
what requirements are placed on the Constrained-Node Network to support SRP
anycast. For example, can there be more than one SRP server on the network?
If so, does the anycast address always need to map to the same SRP server
for a given host?

o  The Host Description records for a service are a KEY RR, used to
>    claim exclusive ownership of the service registration, and one or
>    more RRs of type A or AAAA, giving the IPv4 or IPv6 address(es) of
>    the host where the service resides.
>

Are there recommendations/thoughts on how an SRP server should handle SRP
updates containing multiple IPv6 addresses of varying scopes? Is this a
topic within scope of this document?

updates do not include update prerequisites. The specified in

Typo: "The specified in..."

o  An SRP server is not required to implement general DNS Update
>    prerequsite processing.

Typo: "prerequsite" -> "prerequisite"

The service generates a public/private key pair.  This key pair MUST
> be stored in stable storage; if there is no writable stable storage
> on the client, the client MUST be pre-configured with a public/
> private key pair in read-only storage that can be used.  This key
> pair MUST be unique to the device.
>

Strictly speaking, we require the service to retain the key pair for as
long as it would like to make updates to its existing service information.
For example, should we recommend that a device generate a new key pair
after factory reset (if it has the ability to do that)? I'm thinking that
the public key can serve as a static identifier.

update is constructed by the client, it MUST include include an

Typo: "include include"

updates, and MUST reject updates that would otherwise be SRP updates
> updates if they do not include leases.
>

Typo: "SRP updates updates"

lease time Section 2.6.1.  Shorter TTLs will result in more frequent
> data refreshes; this increases latency on the client side, and
> increases load on any caching resolvers and on the authoritative
> server.  Longer TTLs will increase the likelihood that data in caches

Worth mentioning effect on network utilization? Or is that already implied?

addresses in the records in question.  In addition, proxy should

Typo: "In addition, *the* proxy should..."

specified in [I-D.ietf-dnsop-algorithm-update] section 3.1, in the

"section 3.1" link not pointing to the appropriate doc.

4. Privacy Considerations

Should we mention UDP here?

Should we mention the public key here?

specification in [RFC8375]Section 7.

"Section 7" link not pointing to the appropriate doc.

Thanks.

--
Jonathan Hui

---

From: Ted Lemon <[email-masked]>
Date: Thu, 29 Oct 2020 12:27:42 -0400

Jonathan, thanks for the thorough review. Sorry for taking so long to respond.  I have updated the draft with changes to address your comments. Diffs can be found here: https://tools.ietf.org/rfcdiff?difftype=--hwdiff&url2=draft-ietf-dnssd-srp-05.txt <https://tools.ietf.org/rfcdiff?difftype=--hwdiff&url2=draft-ietf-dnssd-srp-05.txt>

I have additional work to do on this based on Esko’s review, but I’ll do that in a separate update so the diffs don’t get confused. Comments below:

> On Oct 8, 2020, at 3:19 PM, Jonathan Hui <jonhui=[email-masked]> wrote:
> 
> I believe this document addresses a real pain point in constrained networks - namely how constrained devices can publish services with minimal round trips (i.e. one per update) and avoids the need for expensive multicast. This is of great interest to the Thread Group and Project CHIP efforts, both of which are based on IPv6.
> 

Because I accidentally put “info” in the XML instead of “std”. :)

> It's not clear to me at this point what "automatic" really means. It becomes clear later in the doc (e.g. Section 2.6.1), but I think it would help to be clear in the Introduction.

Thanks, this is a really good catch. I’ve substantially updated the introduction to explain this in more detail.

> Typo: "registraton" -> "registration"

:)

> Is "appropriate" well-understood here? I could use some clarification on what requirements are placed on the Constrained-Node Network to support SRP anycast. For example, can there be more than one SRP server on the network? If so, does the anycast address always need to map to the same SRP server for a given host?

Interesting, this was actually fixed in a newer version. So the whole discussion of how to configure SRP on “constrained-node networks” is now left up to the specification for that network type.

> Are there recommendations/thoughts on how an SRP server should handle SRP updates containing multiple IPv6 addresses of varying scopes? Is this a topic within scope of this document?

I’ve added a paragraph to the validation section saying that link-scope and IPv4 autoconf addresses are invalid, and registrations that include them should be treated as invalid registrations.  I’ve also mentioned that addresses must be in scope for all potential clients of the SRP server, but haven’t explained this in more detail. I may add a section about this later.

> Typo: "The specified in..."

Oops!

> Typo: "prerequsite" -> "prerequisite" 

:)

> Strictly speaking, we require the service to retain the key pair for as long as it would like to make updates to its existing service information. For example, should we recommend that a device generate a new key pair after factory reset (if it has the ability to do that)? I'm thinking that the public key can serve as a static identifier.

Yes, that’s intended.  I’ve added some text.

> update is constructed by the client, it MUST include include an

:)

> Typo: "SRP updates updates"

Wow. :)

> Worth mentioning effect on network utilization? Or is that already implied?

OK.  I added text.

> Typo: "In addition, the proxy should..."

:)

> "section 3.1" link not pointing to the appropriate doc.

I’ve updated to point to the RFC.

> Should we mention UDP here?

Dunno what you mean about this.

> Should we mention the public key here?

I’ve added some text. I think we may also want to allow the client to say “don’t show my key.”

> "Section 7" link not pointing to the appropriate doc.

I’m not following this.

> Thanks.
> 
> --
> Jonathan Hui
> 
> _______________________________________________
> dnssd mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnssd

---

From: Jonathan Hui <[email-masked]>
Date: Thu, 29 Oct 2020 12:31:33 -0700

Ted,

Thanks for working to resolve my comments! Responses below:

On Thu, Oct 29, 2020 at 9:27 AM Ted Lemon <[email-masked]> wrote:

> On Oct 8, 2020, at 3:19 PM, Jonathan Hui <
> jonhui=[email-masked]> wrote:
>

Draft-05 still indicates Informational.

> Thanks, this is a really good catch. I’ve substantially updated the
> introduction to explain this in more detail.
>

The additional 4.5 paragraphs of text in the introduction looks great and
the detail is certainly helpful.

> Interesting, this was actually fixed in a newer version. So the whole
> discussion of how to configure SRP on “constrained-node networks” is now
> left up to the specification for that network type.
>

Somehow I reviewed an older draft. The latest text looks good to me!

> I’ve added a paragraph to the validation section saying that link-scope
> and IPv4 autoconf addresses are invalid, and registrations that include
> them should be treated as invalid registrations.  I’ve also mentioned that
> addresses must be in scope for all potential clients of the SRP server, but
> haven’t explained this in more detail. I may add a section about this later.
>

Updated text looks good to me.

> Yes, that’s intended.  I’ve added some text.

Updated text looks good to me.

> Worth mentioning effect on network utilization? Or is that already implied?

Typo: "be an + issue for" -> "be an issue for"

Otherwise, the updated text looks good.

> Dunno what you mean about this.

The current text recommends using TLS when using TCP to mitigate privacy
concerns. Are there any recommendations or warnings to state here when host
implementations are using UDP?

> I’ve added some text. I think we may also want to allow the client to say

Updated text looks good. Giving the client that flexibility sounds
interesting.

> "Section 7" link not pointing to the appropriate doc.

The "Section 7" link in
https://tools.ietf.org/html/draft-ietf-dnssd-srp-05 points
to https://tools.ietf.org/html/draft-ietf-dnssd-srp-05#section-7.

Thanks!

--
Jonathan Hui