Re: [Dots] AD review of draft-ietf-dots-use-cases-17
Nik Teague <nik-ietf@0x46.uk> Thu, 04 July 2019 16:00 UTC
Return-Path: <nik-ietf@0x46.uk>
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 EDE7212011F for <dots@ietfa.amsl.com>; Thu, 4 Jul 2019 09:00:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=0x46.uk
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 rxGolWo6pzFK for <dots@ietfa.amsl.com>; Thu, 4 Jul 2019 09:00:37 -0700 (PDT)
Received: from mail-40132.protonmail.ch (mail-40132.protonmail.ch [185.70.40.132]) (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 B65FA1200A3 for <dots@ietf.org>; 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; d=0x46.uk; 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=
To: kaduk@mit.edu, draft-ietf-dots-use-cases.all@ietf.org
From: Nik Teague <nik-ietf@0x46.uk>
Cc: dots@ietf.org
Reply-To: Nik Teague <nik-ietf@0x46.uk>
Message-ID: <58fUfQIr1SMe_bQT6AJKYrrM8mh6L-NUXe5Ne8exSUZui1mHbWbuol85idMsp02IglvvPVGlR7EqXo8veCncoByhz1t3EGrNM51wnyhWZl8=@0x46.uk>
In-Reply-To: <20190702223654.GF13810@kduck.mit.edu>
References: <20190702223654.GF13810@kduck.mit.edu>
Feedback-ID: Y91J0Zr2tpkE2KpleD3ti1ZrR04h6-F6NTTavVNwZ9GVklA9qvQM6vy4qrECIh7ulSHz17JKDFAAnkqRqLmlTg==:Ext:ProtonMail
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="b1_375272b7a21f6731b2c6fff357a13666"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dots/Q-v64QuAGMbfhacTAnyKTuS83Zs>
Subject: Re: [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: Thu, 04 Jul 2019 16:00:41 -0000
Hi, I thought I had issued this already but if not - I am not aware of any IPR in relation to this draft. Thanks, -Nik -------- 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 > Dots@ietf.org > https://www.ietf.org/mailman/listinfo/dots
- [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