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

Jonathan Hui <jonhui@google.com> Thu, 08 October 2020 19:19 UTC

Return-Path: <jonhui@google.com>
X-Original-To: dnssd@ietfa.amsl.com
Delivered-To: dnssd@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7AE2C3A0C5F for <dnssd@ietfa.amsl.com>; Thu, 8 Oct 2020 12:19:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -17.6
X-Spam-Level:
X-Spam-Status: No, score=-17.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oW6xt6ttMvll for <dnssd@ietfa.amsl.com>; Thu, 8 Oct 2020 12:19:28 -0700 (PDT)
Received: from mail-ot1-x32f.google.com (mail-ot1-x32f.google.com [IPv6:2607:f8b0:4864:20::32f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BEB1C3A0D29 for <dnssd@ietf.org>; Thu, 8 Oct 2020 12:19:24 -0700 (PDT)
Received: by mail-ot1-x32f.google.com with SMTP id n61so6602237ota.10 for <dnssd@ietf.org>; Thu, 08 Oct 2020 12:19:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=Zr8ysnEVE+yyA9FtMZ/Iybt9XRtwYt/DMlBiewKWrI0=; b=G+jjAWlP1YZX8ar0V/MxOWhqb009EYuWUZhRrpMjP1QHJosH1Zcy18gVX5OXOmYYRF 2OoslPvaIZ3JaLOMy8YzgxABgRmBkcO+Su+JcPsGfJ3miI2N00fgVV7xrrsjtc05mpi1 0yDgU6UgE8CUlTRp5UT5YQZKqppCK/nuXWrTx0o5Y5BB412dxFhZ8qxPmtjkmWH89iJX SxKIQoUbNh1FvjeJUGM2jmAPdL8FB6kxnuAwaWRg0b5LQ1pP1nDC954JnVL9Zhw7IwSm zcbIVDBwLb8YblmxWVZcvmcWsivMm3EO7ZoEjmbzYFbD7EtsScXoMkicfAgLL9D7phgY 4F0A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=Zr8ysnEVE+yyA9FtMZ/Iybt9XRtwYt/DMlBiewKWrI0=; b=E3XSJ+fxOAbZUQaroeelPJtStqS/uwuX24K2NC1oMJRJQQi4bcXdSmkfcaAdtIQiZ+ WvBZp130Qq9fm5ZFGjWa9t4akWSw1usVMfQDKY+R6EzByUpXhCczMsFWPFmOBYsdcfvX eYyIa92YRNRC7FLQfNiUXEeHxmM7N1UBjqX4ILzDdzCbTGCQSCRnv9vKrHrbAbEFeAa8 rim3ImU3Dxuu3Pm3ZKQd2OkD8uvNo+6MlE1OuXgELCaWytXYZ9zdo7657SzoTSq1ElXF eU3TUp1zzxNmO2vdz+Ae1k5UmlmeE3PkZRDZN9tCNDPLQLuHfTr6hgpXUhpr0lbC3/3D WKJQ==
X-Gm-Message-State: AOAM5305Z0N2jWYDuDhhSUs+pEBqzeWuxTCIycu/rpAKmjTcPH9VonGP u5ZPPOsmkWGC8VmUnb2tY2KSh9RyY0WCIg5EYvFbtj8dUtSQtA==
X-Google-Smtp-Source: ABdhPJxpjB5qvqSfQ3x3dRzXeJ+5Apxv9/uzv/TnBBilnUU9bfswie31UjDvJ6kzoCVw1kMa3JNR7a572EZXWLsg7dI=
X-Received: by 2002:a9d:7993:: with SMTP id h19mr2539997otm.129.1602184763233; Thu, 08 Oct 2020 12:19:23 -0700 (PDT)
MIME-Version: 1.0
From: Jonathan Hui <jonhui@google.com>
Date: Thu, 08 Oct 2020 12:19:11 -0700
Message-ID: <CAGwZUDvAXr=oKsUtpZAB0PUoR8f+CSGC-4RBkcqoxM2j4QNzeQ@mail.gmail.com>
To: dnssd@ietf.org
Content-Type: multipart/alternative; boundary="000000000000adb5eb05b12db5c9"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnssd/xCu_95G9iAfLvOosb6qb4cLHt9Y>
Subject: [dnssd] Review of draft-ietf-dnssd-srp-02
X-BeenThere: dnssd@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Discussion of extensions to DNS-based service discovery for routed networks." <dnssd.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnssd>, <mailto:dnssd-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnssd/>
List-Post: <mailto:dnssd@ietf.org>
List-Help: <mailto:dnssd-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnssd>, <mailto:dnssd-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 08 Oct 2020 19:19:30 -0000

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