[Dots] AD evaluation of draft-ietf-dots-use-cases-20

Benjamin Kaduk <kaduk@mit.edu> Tue, 12 May 2020 20:22 UTC

Return-Path: <kaduk@mit.edu>
X-Original-To: dots@ietfa.amsl.com
Delivered-To: dots@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 2A2A83A0A6A; Tue, 12 May 2020 13:22:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
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 ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id ahK2l5NweknH; Tue, 12 May 2020 13:22:14 -0700 (PDT)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu []) (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 AC0783A0A65; Tue, 12 May 2020 13:22:10 -0700 (PDT)
Received: from kduck.mit.edu ([]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 04CKM6oM014353 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 12 May 2020 16:22:08 -0400
Date: Tue, 12 May 2020 13:22:05 -0700
From: Benjamin Kaduk <kaduk@mit.edu>
To: draft-ietf-dots-use-cases.all@ietf.org
Cc: dots@ietf.org
Message-ID: <20200512202205.GF27494@kduck.mit.edu>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.12.1 (2019-06-15)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dots/vUDFKBzQDYtvhsfGbbOKm8G1GZY>
Subject: [Dots] AD evaluation of draft-ietf-dots-use-cases-20
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: Tue, 12 May 2020 20:22:16 -0000

Hi all,

This one is in pretty good shape -- I don't have any major comments on it.
I did write up some editorial nit-level stuff as a github pull request:
https://github.com/dotswg/dots-use-cases/pull/12 .  I think that nothing
there should be controversial, but please let me know if I am wrong about

Please confirm that all six authors made significant contributions: I
will need to defend this to the rest of the IESG, since per RFC 7322 the
author count is generally limited to five individuals.  Right now I don't
have a good response when someone asks.

Section 1

   As DDoS solutions are broadly heterogeneous among vendors, the
   primary goal of DOTS is to provide high-level interaction amongst
   differing DDoS solutions, such as detecting, initiating, terminating
   DDoS mitigation assistance or requesting the status of a DDoS

nit: the list structure is not properly parallel.  It looks like the
various clauses are meant to be "detecting DDoS",
"initiating/terminating mitigation assistance", and "requesting
mitigation status", so maybe this could become:

% As DDoS solutions are broadly heterogeneous among vendors, the
% primary goal of DOTS is to provide high-level interaction amongst
% differing DDoS solutions, such as detecting DDoS attacks,
% initiating/terminating DDoS mitigation assistance, or requesting the
% status of a DDoS mitigation.

Section 3.1

   Over the course of the attack, the DOTS server of the ITP
   periodically informs the DOTS client on the enterprise DMS mitigation
   status, statistics related to DDoS attack traffic mitigation, and
   related information.  Once the DDoS attack has ended, or decreased to
   the certain level that the enterprise DMS can handle by itself, the
   DOTS server signals the enterprise DMS DOTS client that the attack
   has subsided.

It's interesting that this is worded in such a way that the (ITP) DOTS
server knows the specific threshold for what level of attack traffic the
enterprise DMS can handle, since it's the DOTS server signalling to the
client that "the attack has subsided".

Section 3.3

   Upon receipt of the DOTS mitigation request from the DDoS telemetry
   system, the orchestrator DOTS server responds with an acknowledgment,
   to avoid retransmission of the request for mitigation.  The
   orchestrator may begin collecting additional fine-grained and
   specific information from various DDoS telemetry systems in order to
   correlate the measurements and provide an analysis of the event.
   Eventually, the orchestrator may ask for additional information from
   the DDoS telemetry system; however, the collection of this
   information is out of scope.

The last sentence seems to say that how the orchestrator gets data from
the initial DOTS client telemtry system is out-of-scope, but the
previous sentence talks about the orchestrator collecting information
from (other) DOTS telemetry systems.  Is that similarly out of scope?
If so, then the fact that they are specifically *DOTS* telemetry systems
seems irrelevant and we should probably just describe them as generic
telemetry or monitoring systems.

   Upon receiving a request to mitigate a DDoS attack performed over a
   target, the orchestrator may evaluate the volumetry of the attack as

nit(?): is "performed over" a conventional usage?  I would have expected
something more like "aimed at" given my personal background, but could
just be ignorant of typical usage.

Also, I think "volumetry" is not the right word here, and just "volume"

   filter the traffic.  In this case, the DDoS mitigation system
   implements a DOTS client while the orchestrator implements a DOTS
   server.  Similar to other DOTS use cases, the offloading scenario
   assumes that some validation checks are followed by the DMS, the
   orchestrator, or both (e.g., avoid exhausting the resources of the
   forwarding nodes or disrupting the service).  These validation checks
   are part of the mitigation, and are therefore out of the scope of the

I know we added this last chunk of text after a long exchange during the
last WGLC, and understand the desire to avoid going into too many
details on a topic that is mostly out of scope for DOTS.  That said, I'd
suggest adding a couple more words around "disrupting the service"
(especially since some level of service disruption during an attack
might be expected!) to help the reader make the link to what kind of
validation is expected, perhaps something like "inadvertent disruption
of legitimate services".

Section 4

In light of my previous comment I don't want to go too far here, but I
could see it being relevant to have a note that in the "orchestration"
case it's possible for something that locally to one telemetry system
looks like an attack is not actually an attack when seen from the
broader scope (e.g., of the orchestrator).

In the Third Party MSP case we mention BGP as a way to steer traffic to
the mitigation service.  We could consider (but don't have to)
mentioning that efforts to secure BGP will need to be considered when
making pre-arrangements for how traffic is to be moved, since in some
contexts such BGP announcements could themselves be considered to be an

I guess it probably goes without saying that when you add a third-party
DMS to your setup, you depend on that third party to be operational in
order for your setup to work properly.

Section 7

We'll probably get someone asking to move RFC 8612 to be a Normative
reference since we use it for terminology, but I don't mind leaving it
be for now.