Re: [Dots] AD review of draft-ietf-dots-use-cases-17

Nik Teague <> Thu, 04 July 2019 16:00 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id EDE7212011F for <>; Thu, 4 Jul 2019 09:00:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id rxGolWo6pzFK for <>; Thu, 4 Jul 2019 09:00:37 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id B65FA1200A3 for <>; Thu, 4 Jul 2019 09:00:36 -0700 (PDT)
Date: Thu, 04 Jul 2019 16:00:32 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=protonmail; t=1562256034; bh=Wf+INoStUcdrppE//waeoSvpYjEsa8549gXxYErKxBI=; h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References: Feedback-ID:From; b=M5rV7MwPUV7U9taEgZ1A5jMU/3d1fIqhrymT9FWKvndwHdHXMRuKyMzXU/YXvsITD R2lwKjzzPdYxUiYw5N8U2cTf3Yh+2nd4RPcgA5kHXbaAI1hSt9xVtfWdUVawM54CP4 zikEm2CJfr2jYZ7JCazTVC0JOUHcxJyyVzVKaQPs=
From: Nik Teague <>
Reply-To: Nik Teague <>
Message-ID: <>
In-Reply-To: <>
References: <>
Feedback-ID: Y91J0Zr2tpkE2KpleD3ti1ZrR04h6-F6NTTavVNwZ9GVklA9qvQM6vy4qrECIh7ulSHz17JKDFAAnkqRqLmlTg==:Ext:ProtonMail
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="b1_375272b7a21f6731b2c6fff357a13666"
Archived-At: <>
Subject: Re: [Dots] AD review of draft-ietf-dots-use-cases-17
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 04 Jul 2019 16:00:41 -0000


I thought I had issued this already but if not - I am not aware of any IPR in relation to this draft.



-------- Original Message --------
On 2 Jul 2019, 23:36, Benjamin Kaduk wrote:

> First off, a few housekeeping items:
> (1) This document lists seven authors, and per RFC [7322](tel:7322) I/the IESG needs
> to specially consider this and essentially make an exception to have
> more than five authors. Can you please confirm that all listed authors
> have made substantial contributions, so that I can take that to the IESG
> and get it approved?
> (2) The shepherd writeup indicates that three authors (Stefan, Bob, and
> Nik) have not indicated conformance with BCPs 78 and 79. I don't think
> I can issue the IETF LC until that gets straightened out, so please
> confirm that we're all squared away!
> (3) Recently the IESG has been trying to exert some gentle backpressure
> against publishing Informational use-cases/requirements drafts, when they
> serve only as input to future protocol specifications and do not have
> lasting archival value on their own. I do see in the shepherd writeup that
> the working group did reach consensus to publish this document and think
> there's enough value in it to be worth publishing; I just mention this so
> that people aren't surprised if the IESG evaluation comes back with
> questions about whether we should be publishing the document at all.
> Other than those, the document is generally in good shape; there's just
> a few substantive questions buried in the editorial nits.
> On to the section-by-section comments:
> Section 2
> o DDoS Mitigation Service: designates a DDoS mitigation service
> provided to a customer and which is scoped to mitigate DDoS
> attacks. [...]
> I don't really think that using the lowercase-'s' version to define the
> uppercase-'S' version of the term is going to help anyone.
> Section 3.1
> It's a little surprising that we have the two bullet points near the top
> about the enterprise DMS acting as a DOTS client for the first kind of
> service but as a DOTS server for the second kind, but then we never seem
> to talk about that second kind of service again in the document.
> Perhaps we should just explicitly say that it's similar to the first
> kind and not covered further?
> When the enterprise DMS detects an inbound DDoS attack targeting its
> resources ( e.g. servers, hosts or applications), it immediately
> begins a DDoS Mitigation.
> I'd consider clarifying that this mitigation is entirely local within
> the enterprise, so that contacting the ITP in the next step is a clear
> escalation.
> related information. Once the DDoS attack has ended, or decreased to
> the certain level that the DOTS client can handle by itself, the DOTS
> server signals the enterprise DMS DOTS client that the attack has
> subsided.
> I think it's the enterprise DMS that is handling the attack, not the
> DOTS client directly...
> The enterprise DMS then requests the ITP to terminate the DDoS
> Mitigation. The DOTS server on the ITP receives this request and
> .... but this one is the DOTS client.
> o (a) A DDoS attack is initiated against resources of a network
> organization which has deployed a DOTS-capable DMS - typically a
> DOTS client.
> We probably want to reiterate in a parenthetical "network organization
> (here, the enterprise)" the terminology we're using.
> o (d) The DOTS server which receives the DOTS Mitigation request
> determines that it has been configured to honor requests from the
> requesting DOTS client, and honored its DDoS Mitigation by
> orchestrating its DMS.
> nit: I think s/honored/honors/ to stay in the present tense.
> o (e) While the DDoS Mitigation is active, DOTS server regularly
> transmits DOTS DDoS Mitigation status updates to the DOTS client.
> nit: "the DOTS server" or "servers regularly transmit".
> Section 3.2
> As such, this use case likely to match large enterprises or large
> data centers, but not exclusively. [...]
> nit: "is likely"
> In this scenario, an Enterprise Network has entered into a pre-
> arranged DDoS mitigation assistance agreement with one or more other
> DDoS Mitigation Service Providers in order to ensure that sufficient
> DDoS mitigation capacity and/or capabilities may be activated in the
> event that a given DDoS attack threatens to overwhelm the ability of
> a given DMS to mitigate the attack on its own.
> We could perhaps say "overwhelm the ability of the enterprise's or any
> other given DMS" since in most cases the enterprise DMS is the one at
> risk of first being overwhelmed.
> Is the fact that the C<-->S DOTS traffic does not go through the ITP in
> Figure 3 an intentional change from Figure 2 (in that they are expected
> to be communicating "out of band" or not through the enterprise's normal
> transit)? Some readers might see this and get confused if this
> communication is still supposed to be going along the regular transit
> path.
> Section 3.3
> In this use case, one or more DDoS telemetry systems or monitoring
> devices monitor a network - typically an ISP network, an Enterprise
> network, or a data center. Upon detection of a DDoS attack, these
> DDoS telemetry systems alert an orchestrator in charge of
> coordinating the various DMS within the domain. [...]
> nit: do we have a standard plural form for "DMS"? (Is it just "DMS"?)
> ITP. DDoS Mitigation System selection and DDoS Mitigation technique
> may depends on the type of DDoS attack. In some case, a manual
> nit: "techniques" plural
> The communication between a network administrator and the
> orchestrator is also performed using DOTS. The network administrator
> via its web interfaces implements a DOTS client, while the
> Orchestrator implements a DOTS server.
> nit: as written, this is saying that the network administrator has a
> web interface. I think "its" is supposed to refer to something else.
> nit: Figure 4 lists "DDoS mitigation systems" in both the interprise and
> the ITP, but only the enterprise side has a "stack" of boxes to indicate
> there is more than one.
> These systems are configured so that when an event or some
> measurement indicators reach a predefined level to send DOTS
> mitigation request to the orchestrator. The DOTS mitigation request
> nit: the grammar here is a bit off; I think s/to send DOTS mitigation
> request/they send a DOTS mitigation request/ would fix it.
> Upon receipt of the DOTS mitigation request from the DDoS telemetry
> system, the orchestrator responds with an acknowledgment, to avoid
> retransmission of the request for mitigation. The orchestrator may
> begin collecting additional fined grain and specific information from
> nit: "fine-grained"
> and provide an analysis of the event. Eventually, the orchestrator
> may ask additional information to the DDoS telemetry system, however,
> the collection of these information is out of scope.
> nit: s/ask additional information to/ask for additional information
> from/
> nit: semicolon before "however" instead of comma
> nit: "this information"
> Upon receiving a request to mitigate a DDoS attack performed over a
> target, the orchestrator, may evaluate the volumetry of the attack as
> nit: no comma after "the orchestrator"
> well as the value that represent the target. The orchestrator may
> nit: "the value that the target represents"
> When DDoS Mitigation is requested, the status
> indicates the DDoS Mitigation is starting while not effective. The
> DOTS client of the orchestrator will later be notified that the DDoS
> Mitigation is effective.
> I'm not entirely sure what this last sentence is trying to say.
> Orchestration of the DDoS mitigation systems works similarly as
> described in Section 3.1. The orchestrator indicates with its status
> whether the DDoS Mitigation is effective.
> Is this intended to specifically refer to the external (ITP) DMS?
> Also, my understanding is that for this interaction the orchestrator is
> acting as a DOTS client, but the rest of the document only has status
> messages being generated by the DOTS server. Am I confused?
> Section 4
> It feels incomplete to list three primary attacks but only discuss
> mitigations for two of them. Perhaps "preconfigured mitigation steps to
> take on the loss of keepalive traffic can partially mitigate signal
> blocking, but in general it is impossible to comprehensively defend
> against an attacker that can selectively block any or all traffic".
> Section 6
> Is Med's name spelled correctly?
> Thanks,
> Ben
> _______________________________________________
> Dots mailing list