[Dots] Martin Duke's No Objection on draft-ietf-dots-rfc8782-bis-07: (with COMMENT)

Martin Duke via Datatracker <noreply@ietf.org> Tue, 01 June 2021 22:39 UTC

Return-Path: <noreply@ietf.org>
X-Original-To: dots@ietf.org
Delivered-To: dots@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 003043A2A12; Tue, 1 Jun 2021 15:39:38 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Martin Duke via Datatracker <noreply@ietf.org>
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-dots-rfc8782-bis@ietf.org, dots-chairs@ietf.org, dots@ietf.org, valery@smyslov.net, valery@smyslov.net
X-Test-IDTracker: no
X-IETF-IDTracker: 7.30.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Martin Duke <martin.h.duke@gmail.com>
Message-ID: <162258717896.27217.11487555052395475135@ietfa.amsl.com>
Date: Tue, 01 Jun 2021 15:39:38 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/dots/JmkST38y9Jjnxq48aDcjjXLTGoM>
Subject: [Dots] Martin Duke's No Objection on draft-ietf-dots-rfc8782-bis-07: (with COMMENT)
X-BeenThere: dots@ietf.org
X-Mailman-Version: 2.1.29
List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." <dots.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dots>, <mailto:dots-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dots/>
List-Post: <mailto:dots@ietf.org>
List-Help: <mailto:dots-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dots>, <mailto:dots-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 01 Jun 2021 22:39:39 -0000

Martin Duke has entered the following ballot position for
draft-ietf-dots-rfc8782-bis-07: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-dots-rfc8782-bis/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thank you for addressing Michael Tuexen's TSVART review.

As I did not review RFC8782, I'm taking this opportunity to review the entire
document, rather than just the bis. I found numerous clarity issues:

(4.4.1.1) How do DOTS servers detect a CUID collision? I believe Sec. 7
explains this is based on client authentication, but mentioning it here would
be helpful.

In the "mid" definition: s/no attack is detected/no attack is underway

In the "target_fqdn" definition. The text appears to assume a DNS resolution;
is there a not a use case where the DOTS server would rely on e.g. SNI
inspection and not defend an entire IP address that had multiple domains?

"lifetime" definition: The text says the DOTS server MAY reject unlimited
lifetime, which implies that it MUST accept any finite lifetime. I presume you
mean to say that DOTS servers are free to set a policy limit on the maximum
allowable lifetime?

(4.4.1.2) "cdid" definition: The example in Fig. 9 does not have a cdid that
matches the cuid. The text indicates that these might not match if a
client-side gateway added the cdid, but then later says that "only the first
on-path server-domain DOTS gateway can  insert a 'cdid' value." After reading
this a few times, I think what you are saying is (a) clients MUST NOT add cdid;
(b) client-side gateways SHOULD add them; (c) the first server-side gateway
MUST strip them and then add their own; and (d) subsequent server side gateways
MUST NOT change the cdid. Is this correct? Either way, it could be expressed
less confusingly.

(4.4.1.3) Fig. 11: Where does the second cuid come from? Is this generated by
the server on behalf of the client? If so, I recommend s/a new request with a
new 'cuid'/a new request with a new, server-provided 'cuid'

When extending the lifetime, does the new lifetime field measure from the
initial trigger or from the moment of extension? If the former, a change in the
lifetime value is mandatory, not "potential." If the latter, how does the
server distinguish this from a duplicate request?

(4.4.2) Fig. 14 uses a string to represent the status instead of one of the
values in Table 3.

(4.4.3) Same with Fig. 16 and Table 4.

(4.4.2.1) If updates are non-confirmable, how does the client know if it's
gotten out of sync on state updates?

(4.5.1) What is the unit of probing rate?

(8) s/should/SHOULD, s/must/MUST throughout.