[Dots] AD review of draft-ietf-dots-use-cases-17
Benjamin Kaduk <kaduk@mit.edu> Tue, 02 July 2019 22:37 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 3EC49120106; Tue, 2 Jul 2019 15:37:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 Oc0FvknM3DLD; Tue, 2 Jul 2019 15:37:03 -0700 (PDT)
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 D91451200F6; Tue, 2 Jul 2019 15:36:59 -0700 (PDT)
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 x62MatvS013959 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 2 Jul 2019 18:36:57 -0400
Date: Tue, 02 Jul 2019 17:36:54 -0500
From: Benjamin Kaduk <kaduk@mit.edu>
To: draft-ietf-dots-use-cases.all@ietf.org
Cc: dots@ietf.org
Message-ID: <20190702223654.GF13810@kduck.mit.edu>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
User-Agent: Mutt/1.10.1 (2018-07-13)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dots/I0vURjoFTlLxIinQbrgEDns0dcc>
Subject: [Dots] AD review of draft-ietf-dots-use-cases-17
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, 02 Jul 2019 22:37:05 -0000
First off, a few housekeeping items: (1) This document lists seven authors, and per RFC 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] AD review of draft-ietf-dots-use-cases-17 Benjamin Kaduk
- Re: [Dots] AD review of draft-ietf-dots-use-cases… Benjamin Kaduk
- Re: [Dots] AD review of draft-ietf-dots-use-cases… mohamed.boucadair
- Re: [Dots] AD review of draft-ietf-dots-use-cases… Nik Teague
- Re: [Dots] AD review of draft-ietf-dots-use-cases… Nik Teague
- Re: [Dots] AD review of draft-ietf-dots-use-cases… Daniel Migault
- Re: [Dots] AD review of draft-ietf-dots-use-cases… mohamed.boucadair
- Re: [Dots] AD review of draft-ietf-dots-use-cases… kaname nishizuka
- Re: [Dots] AD review of draft-ietf-dots-use-cases… Daniel Migault
- Re: [Dots] AD review of draft-ietf-dots-use-cases… Daniel Migault
- Re: [Dots] AD review of draft-ietf-dots-use-cases… Robert Moskowitz
- Re: [Dots] AD review of draft-ietf-dots-use-cases… Benjamin Kaduk
- Re: [Dots] AD review of draft-ietf-dots-use-cases… Daniel Migault
- Re: [Dots] AD review of draft-ietf-dots-use-cases… Daniel Migault