Re: [Tsv-art] Tsvart last call review of draft-ietf-dots-server-discovery-11

Kyle Rose <> Wed, 21 October 2020 14:24 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 55A473A0C11 for <>; Wed, 21 Oct 2020 07:24:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.1
X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 1b2Uad_E2gLN for <>; Wed, 21 Oct 2020 07:24:21 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id B793C3A113D for <>; Wed, 21 Oct 2020 07:23:44 -0700 (PDT)
Received: by with SMTP id l15so1945637ybp.2 for <>; Wed, 21 Oct 2020 07:23:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=vZyc+Z7VtCmyxIy+QGOsbEnlXq2xyJclvDCIKz5YEJg=; b=WuE2NJmDyU5UOAuXNZVMLCVYNHlTaYt5pRoleTuM20r0QKV4/azqyPsrhM1nDIlvMz Z21eJ5DYlYrgQ1/3lgorDn54kW+1K7gpinzCOuRXpVPXWhAxRpggl4qmaqJ18wvkyvoZ rRCKnLFrwclgob+6SQJ3bl3Cxg7HE51ZqC8Ws=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=vZyc+Z7VtCmyxIy+QGOsbEnlXq2xyJclvDCIKz5YEJg=; b=irRulOL00FzcnHhkZOXGU8IEmmItdglDDf3jyVdl+OfxtYbMQ9X4mojFAOr7j27WuG NPV0/VQ0IHvMLM7CSrvboS5SpVZqvihoX4LXNsCZiHyo+Vv7W3ehJkiRaVdtlKNVb6nr pwN9HpfSDpsb1GdWTQZZLXT7r9uqCwYYNksz4v884/fvpbBPb3JKF5W3xNo/NEPXYPZg bJTKjGC9rXULiHTLYq+Vg7C5dhVwhZfPsLXve/rez2o55SzDTQSlICLF50Is7sku4f9W 2O5K0dLUlu5yDUbvrqwmUkYdGRdpWu84SiKgvFIFZl+f7FqyFqiQP/RPHkLw3bH0FbfN iHbg==
X-Gm-Message-State: AOAM530ip26Kzkib8QU1fdzhl13FbAOFRVQtf4azXNS08Uonc3Z24jXe T1YUx3EjaHnssvBaHAOicRwUNQGs/kKcayQ+L27fjQ==
X-Google-Smtp-Source: ABdhPJwusFo/DFffBkNHT0y57uWHyj+2FDBnpBGUVyXEyH0HaMLhjUnM4XGMgQZI/JQUbKOfLCfB55YEZcqUfvm7hJE=
X-Received: by 2002:a25:511:: with SMTP id 17mr5772922ybf.296.1603290223528; Wed, 21 Oct 2020 07:23:43 -0700 (PDT)
MIME-Version: 1.0
References: <> <22178_1602577731_5F856543_22178_325_7_787AE7BB302AE849A7480A190F8B93303155F274@OPEXCAUBMA2.corporate.adroot.infra.ftgroup>
In-Reply-To: <22178_1602577731_5F856543_22178_325_7_787AE7BB302AE849A7480A190F8B93303155F274@OPEXCAUBMA2.corporate.adroot.infra.ftgroup>
From: Kyle Rose <>
Date: Wed, 21 Oct 2020 10:23:33 -0400
Message-ID: <>
Cc: "" <>, "" <>, "" <>, "" <>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <>
Subject: Re: [Tsv-art] Tsvart last call review of draft-ietf-dots-server-discovery-11
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Transport Area Review Team <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 21 Oct 2020 14:24:25 -0000

On Tue, Oct 13, 2020 at 4:28 AM <> wrote:
> > * Section 4 says:
> >
> >    The discovery method is reiterated by a DOTS agent upon the
> > following
> >    events:
> >
> >    o  Expiry of a a validity timer (e.g., DHCP lease, DNS TTL)
> >       associated with a discovered DOTS agent.
> >
> > >From my reading, rendezvous information for the DOTS server is
> > "pushed"
> > >to the
> > client via DHCP, so it's not clear the above is actionable. Is it
> > simply the case that a client should use the DOTS server assigned in
> > the most recent lease?
> >
> [Med] The intent is to avoid using "stale" servers. So yes, this is about using the server that was most recently discovered but also about not using a server beyond a validity time associated with the discovered server.

I think the wording for this requirement should be normative rather
than buried in the description of the discovery mechanism. Adding a
statement somewhere that "a DOTS agent MUST NOT initiate or continue
communicating with a server whose associated discovery metadata has
expired: for instance, once a DNS TTL or DHCP lease has expired, an
appropriate DOTS server must be rediscovered using one of the
mechanisms in {}."

> > Using DHCP, an inherently insecure protocol, to inform DOTS clients
> > of the hostname of DOTS server knocks this third leg out, calling
> > into question the entire mechanism.
> [Med] We didn't include such discussion as this is a variation of agent impersonation (covered by the pointer to RFC8811) and rogue servers in RFC8415. Also, we have the following:
>    This document assumes that security credentials to authenticate DOTS
>    server(s) are provisioned to a DOTS client using a mechanism such as
>    (but not limited to) those discussed in [RFC8572] ...
> We can add some text to elaborate on this further.

No, I think this is fine as-is. I think I just missed these references to 8572.

> > Is the final label zero-length?
> [Med] Yes, as indicated in 5.2.1:
>    o  Peer DOTS agent name: The domain name of the peer DOTS agent.
>       This field is formatted as specified in Section 10 of [RFC8415].
>  Other parts of the DHCPv4 protocol
> > terminate domain names with a zero-length label. What if a zero-
> > length label appears in some s_i other than the final one?
> >
> [Med] Names are validated as per the rules in Section 10 of RFC8415:
>    If the DHCP client receives OPTION_V4_DOTS_RI only, but
>    OPTION_V4_DOTS_RI option contains more than one name, as
>    distinguished by the presence of multiple root labels, the DHCP
>    client MUST use only the first name.  Once the name is validated
>    (Section 10 of [RFC8415]), the name is passed to a name resolution
>    library.

Got it. It's a roundabout way of saying "ignore everything after the
first zero-length label". I'm guessing this is well-understood by the
DNS community.

> > RFC 6763 says that an empty TXT record MUST be included alongside
> > the SRV record where DNS-SD is concerned. Should normative language
> > be used here, or should we rely on the normative reference in case
> > that guidance changes in the future?
> [Med] I don't think that the use of normative language is needed here. RFC6763 is sufficient by its own.

Sounds good.

Thanks for the follow-up. My apologies for the delay in responding.