[Dots] AD review of draft-ietf-dots-rfc8782-bis-04

Benjamin Kaduk <kaduk@mit.edu> Mon, 01 March 2021 22:08 UTC

Return-Path: <kaduk@mit.edu>
X-Original-To: dots@ietfa.amsl.com
Delivered-To: dots@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38D4A3A23C6; Mon, 1 Mar 2021 14:08:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 IG4YYdOmfA3N; Mon, 1 Mar 2021 14:08:03 -0800 (PST)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 29E5E3A23C0; Mon, 1 Mar 2021 14:08:02 -0800 (PST)
Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 121M7u3D006718 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 1 Mar 2021 17:08:01 -0500
Date: Mon, 1 Mar 2021 14:07:55 -0800
From: Benjamin Kaduk <kaduk@mit.edu>
To: draft-ietf-dots-rfc8782-bis.all@ietf.org
Cc: dots@ietf.org
Message-ID: <20210301220755.GK21@kduck.mit.edu>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Archived-At: <https://mailarchive.ietf.org/arch/msg/dots/YHz7C59sPzuqih_Ih1JVe392NHU>
Subject: [Dots] AD review of draft-ietf-dots-rfc8782-bis-04
X-BeenThere: dots@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
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: Mon, 01 Mar 2021 22:08:05 -0000

Hi all,

Sorry to have taken so long on this one -- I opened it up a couple times
thinking "I'll just look at the diff from 8782; it'll be easy", but then
halfway in I realized I did actually want to give some careful attention to
the YANG changes and ran out of time.

The good news is that it's generally in good shape -- I'll request the IETF
LC (it will be extended due to the IETF 110 overlap) and the following
comments can be considered along with the last-call comments.

Thanks for the good work!

-Ben


We'll have to bump the copyright year in the YANG because I was too slow
at processing this :(

Should we say anything about what an implementation should do if it
receives cuid/cdid/mid/sid in the payload body (e.g., ignore it or check
for consistency with the received URI-Path)?

Section 3.1

   same CBOR key value and CBOR major type.  The only upgrade that is
   required to [RFC8782] implementations is to handle the CBOR key value
   range "128-255" as comprehension-optional instead of comprehension-
   required.  Note that this range is anticipated to be used by the DOTS
   telemetry [I-D.ietf-dots-telemetry] in which the following means are
   supported to avoid that a DOTS signal channel message enriched with
   telemetry data will exacerbate message failure: (1) DOTS agents use

nit: I suggest s/are supported to avoid that a DOTS signal channel
message enriched with telemetry data will exacerbate message failure/are
used to prevent message processing failure of a DOTS signal channel
message enriched with telemetry data/ -- the "avoid" and "failure" are
quite far apart in the original, which can be hard to process.

Section 5.3

           container conflict-information {
             description
               "Indicates that a conflict is detected.
                Must only be used for responses.";

The "must only be used for responses" is mechanically redundant with the
"direction" choice, now, so it should probably be removed.

               list acl-list {
                 when "../../conflict-cause ="
                    + " 'conflict-with-acceptlist'";
                 key "acl-name";
                 description
                   "List of conflicting ACLs as defined in the DOTS data
                    channel.  These ACLs are uniquely defined by
                    cuid and acl-name.";

Now that cuid is moved out of the structure and into the Uri-Path
option, we have a new opportunity for separability of payload and
metadata.  The security considerations should discuss what prevents a
"slice and dice" attack that uses a given payload on a different
connection or in a different context such that it is interprted in the
context of a different cuid.  (DTLS ought to be enough, assuming a
request or response does not get split across datagrams.)

(Likewise for 'sid' no longer in the signal-config messages.)


redirected-signal/alt-server is now an inet:domain-name but 8782 has it
as "string".  AFAICT that does not result in an encoding change but
please confirm.


   sx:structure dots-signal {
     description
       "Main structure for DOTS signal message.

        A DOTS signal message can be a mitigation, a configuration,
        or a redirected signal message.";

Should this description list "heartbeat" as well?

Section 7.1

Will whichever author noticed please file an errata report against RFC
8782 for the random "i" in the middle of "The Server Name Indication
(SNI) extension [RFC6066] i defines a mechanism"?  I'd be happy to mark
it verified.

Section 9

   The following list of common CoAP errors that are implemented by DOTS
   servers.  This list is not exhaustive, other errors defined by CoAP
   and associated RFCs may be applicable.

nit: comma splice

   o  4.15 (Unsupported Content-Format) is returned by the DOTS server
      when the Content-Format used in the request is not formatted as
      "application/dots+cbor" (Section 4).

nit: I think either the Content-Format used "is not"
application/dots+cbor, or "the request is not formatted as"
application/dots+cbor.  The current formulation seems to say that the
Content-Format itself is formatted, which is weird.

Section 10.6.1.1

We recently had draft-ietf-mpls-lsp-ping-registries-update come through
to, among other things, change some ranges from "private use" to "first
come, first served", since in the type of deployment they have the
"private use" could not really remain private.  That is probably less of
a concern for DOTS, but I mention it just in case it is relevant.