Re: [Dots] AD review of draft-ietf-dots-use-cases-17
Daniel Migault <daniel.migault@ericsson.com> Fri, 05 July 2019 12:23 UTC
Return-Path: <mglt.ietf@gmail.com>
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 159001201D6; Fri, 5 Jul 2019 05:23:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.399
X-Spam-Level:
X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no 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 xG4XfRm0THOX; Fri, 5 Jul 2019 05:23:17 -0700 (PDT)
Received: from mail-ua1-f51.google.com (mail-ua1-f51.google.com [209.85.222.51]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 67D781201D7; Fri, 5 Jul 2019 05:23:17 -0700 (PDT)
Received: by mail-ua1-f51.google.com with SMTP id z13so2130499uaa.4; Fri, 05 Jul 2019 05:23:17 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=pwRPU+fAEf6j/TAZv7ltu74+gtRQZzDLjSYEbdeD+oM=; b=IPNFoxfH+AR1gGkkgcR2fVOcUS8enCn4EYJMMV6FvZJQr3k4lVgdTY2GppCUPqyCAW Ij8HfvPf1FL1YSi/NtKYBQm4KlnpRsTDO/q1W4XGSmhhhUEHcYSSPxcpcNNF2esV16ms 8iZDUkOFaRcn4+lIUPnKFC5m0GAKj8dd/XabBlcbaraWQdzOjZmVIdrNozdFwbxTu/Fh rjw8VgHj424BSxvvyNp1o/SyZng91jYGVTGwhVyBie1GbGxRUQZLYtm9+0OTwxD1Ncre SLSBYmU88K5fbrcn9HS+ESOMoiw6hSoiTnGo3PnvT0vTb+tZXOvT782VQ+JDbMu9vjbA Mg2g==
X-Gm-Message-State: APjAAAUit3WEB307TCJ3N6d2/2rRdlaTOJqcIm61SdIANTkjk8UXcm7r zE9nsF7n8totEjjbS0UTV7l2A+XiCeXC0jMJK34=
X-Google-Smtp-Source: APXvYqywcjuifH4s6KH6cOugbCd45anlVy9rSjKJEuWUh1oRpdsqHx7nGrkhmEj7CeY7CQkMYhcoWKgqKCLWx1J4+XA=
X-Received: by 2002:ab0:614d:: with SMTP id w13mr1684090uan.66.1562329396298; Fri, 05 Jul 2019 05:23:16 -0700 (PDT)
MIME-Version: 1.0
References: <20190702223654.GF13810@kduck.mit.edu> <CADZyTk=odGB8n=B3RWU1i_xumH3TRo+Rn5v6NsFVRZzUKdpaRA@mail.gmail.com> <787AE7BB302AE849A7480A190F8B93302EAC0D83@OPEXCAUBMA2.corporate.adroot.infra.ftgroup>
In-Reply-To: <787AE7BB302AE849A7480A190F8B93302EAC0D83@OPEXCAUBMA2.corporate.adroot.infra.ftgroup>
From: Daniel Migault <daniel.migault@ericsson.com>
Date: Fri, 05 Jul 2019 08:23:05 -0400
Message-ID: <CADZyTkk+Si+1CRpeMPqfrbyRPupmy5X4i1BQtjpysdTF0waj8A@mail.gmail.com>
To: mohamed.boucadair@orange.com
Cc: "draft-ietf-dots-use-cases.all@ietf.org" <draft-ietf-dots-use-cases.all@ietf.org>, dots <dots@ietf.org>, Benjamin Kaduk <kaduk@mit.edu>
Content-Type: multipart/alternative; boundary="000000000000b04691058cee2864"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dots/QgdzjV8NEvSz6BniyVBvIJSAN7Y>
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: Fri, 05 Jul 2019 12:23:21 -0000
Thanks Med! Just merged them! Yours, Daniel On Fri, Jul 5, 2019 at 2:01 AM <mohamed.boucadair@orange.com> wrote: > Hi Daniel, > > > > FWIW, changes to fix some nits can be found at: > > > > https://github.com/dotswg/dots-use-cases/pull/10/files > > > > Cheers, > > Med > > > > *De :* Dots [mailto:dots-bounces@ietf.org] *De la part de* Daniel Migault > *Envoyé :* jeudi 4 juillet 2019 22:14 > *À :* Benjamin Kaduk > *Cc :* draft-ietf-dots-use-cases.all@ietf.org; dots > *Objet :* Re: [Dots] AD review of draft-ietf-dots-use-cases-17 > > > > Hi, > > > > Thank you for the review. Please find my response in line as well as on > the git repo [1]. WG, co-authors, please review section 3.3 by Friday EOB. > > > > In summary we addressed all comments, major changes are: > > > > a) Figure 2 with a channel from DOTS client and DOTS server with th > eaddition of the following text: > > """ > > In some cases the communication between the enterprise DOTS client and > the DOTS server of the DDoS Mitigation Service Provider may go through > the ITP carrying the DDoS attack, which would affect the > communication. On the other hand, the communication between the DOTS > client and DOTS server may take a path that is not undergoing a DDoS > attack. > > """ > > > > b) telemetry > > > > We clarified DOTS client/server involved. > > > > c) it was unclear to me how to address the following comment. > > > > > 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. > > <mglt> > > What we are trying to say is that the network administrator sees its web > interface, and instruct the DOTS client from that interface. I have not > made any change to address that concern, as I do not clearly see what is > confusing. > > </mglt> > > > > > > Yours, > > Daniel > > > > [1] > https://github.com/dotswg/dots-use-cases/commit/e251fb8abb51ba0c68471e847037daf2e81d38aa > > > > > > On Tue, Jul 2, 2019 at 6:37 PM Benjamin Kaduk <kaduk@mit.edu> wrote: > > 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. > > <mglt> > > The text has been replaced by the following: > > > > * DDoS Mitigation Service: designates a service provided to a > customer to mitigate DDoS attacks. Services usually involve Service > Level Agreement (SLA) that have to be met. It is the responsibility of > the DDoS Service provider to instantiate the DDoS Mitigation System to > meet these SLAs. > > </mglt> > > > 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? > > <mglt> > > I agree that could be mentioned explicitly. Here is the proposed text to > address that concern. > > > > The two scenarios, thought different, have similar interactions between > > the DOTS client and server. For the sake of simplicity, only the first > scenario will be detailed in this section. > > </mglt> > > > > 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. > > <mglt> > > To address the concern we specify that the mitigation is handled locally > as well as we explicitly indicate the escalation procedure. I believe the > following text address your concern: > > > > When the enterprise DMS locally detects an inbound DDoS attack targeting > its resources ( e.g. servers, hosts or applications), it immediately > begins a DDoS Mitigation. > > During the course of the attack, the inbound traffic volume exceeds the > 50% threshold and the enterprise DMS escalates the DDoS mitigation. The > enterprise DMS DOTS client signals the DOTS server on the upstream ITP > to initiate DDoS Mitigation. The DOTS server signals the DOTS client > that it can serve this request, and mitigation is initiated on the ITP > network by the ITP DMS. > > </mglt> > > > > 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... > > <mglt> > > This is correct. This has been corrected as follows: > > > > 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. > > </mglt> > > > > 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. > > <mglt> > > > > Yes we sometime probably abused metonymy, but I agree the more specific > > the better. I believe the following text is clarifying. > > > > The DOTS client on the enterprise DMS then requests the ITP to terminate > the DDoS Mitigation. The DOTS server on the ITP receives this request > and once the mitigation has ended, confirms the end of upstream DDoS > Mitigation to the enterprise DMS DOTS client. > > </mglt> > > 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. > > <mglt> > > Here is the current text: > > > > * (a) A DDoS attack is initiated against resources of a > network organization (here, the enterprise) which has deployed a > DOTS-capable DMS - typically a DOTS client. > > </mglt> > > > > 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. > > <mglt> > > I agree. here is the proposed text: > > > > * (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 honors its DDoS Mitigation by orchestrating > its DMS. > > </mglt> > > > > 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". > > <mglt> > > I agree, here is the corrected text: > > > > * (e) While the DDoS Mitigation is active, the DOTS server > regularly transmits DOTS DDoS Mitigation status updates to the DOTS > client. > > </mglt> > > > > Section 3.2 > > As such, this use case likely to match large enterprises or large > data centers, but not exclusively. [...] > > nit: "is likely" > > <mglt> > > This has been added as follows: > > > > As such, this use case is > likely to match large enterprises or large data centers, but not > exclusively. > > </mglt> > > > > 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. > > <mglt> > > I agree that is better. Here is the modified text: > > > > 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 the > enterprise's or any other given DMS to mitigate the attack on its own. > > </mglt> > > > > 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. > > <mglt> > > The intention was to indicate the DDoS Mitigation Service Provider is not > the upstream ITP and thus communication MAY have to transit through the > ITP. I understand from your comment that it might be interpreted as the > communication MUST go through the ITP. > > > > I propose to have the DMS communicating directly via a distinct channel > and mention explicitly that the DOTS channel MAY transit via the ITP or may > use a dedicated path. > > > > Here is the updated figure and the additional text: > > > > +------------------+ +------------------+ > | Enterprise | | Upstream | > | Network | | Internet Transit | > | | | Provider | > | +--------+ | | DDoS Attack > | | DDoS | | <================================= > | | Target | | <================================= > | +--------+ | | | > | | | | > | | +------------------+ > | | > | | +------------------+ > | | | DDoS Mitigation | > | | | Service Provider | > | | | | > | +------------+ | | +------------+ | > | | DDoS |<------------>| DDoS | | > | | Mitigation |C | | S| Mitigation | | > | | System | | | | System | | > | +------------+ | | +------------+ | > +------------------+ +------------------+ > > * C is for DOTS client functionality > * S is for DOTS server functionality > > Figure 2: DDoS Mitigation between an Enterprise Network and Third > Party DDoS Mitigation Service Provider > > > > [...] > > > > In some cases the communication between the enterprise DOTS client and > the DOTS server of the DDoS Mitigation Service Provider may go through > the ITP carrying the DDoS attack, which would affect the > communication. On the other hand, the communication between the DOTS > client and DOTS server may take a path that is not undergoing a DDoS > attack. > > > > </mglt> > > > > 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"?) > > <mglt> > > Seems that DMS's is more appropriated. This has been changed. > > > > Upon detection of a DDoS attack, these DDoS > telemetry systems alert an orchestrator in charge of coordinating the > various DMS's within the domain. > > > > </mglt> > > > > 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 > > <mglt> > > Corrected: > > > > DDoS Mitigation System selection and DDoS Mitigation techniques may > depends on the type of DDoS attack. > > </mglt> > > > > 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. > > <mglt> > > What we are trying to say is that the network administrator sees its web > interface, and instruct the DOTS client from that interface. I have not > made any change to address that concern, as I do not clearly see what is > confusing. > > </mglt> > > > > 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. > > <mglt> > > Both have two DMS's now. > > > > > > </mglt> > > > 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. > > <mglt> > > Thanks. This has been corrected accordingly: > > > > These systems are configured so that when an event or some measurement > indicators reach a predefined level they send a DOTS mitigation request > to the orchestrator. > > > > </mglt> > > > > 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" > > <mglt> > > Thanks for the nits. All have been addressed in the text below: > > > > 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. > > </mglt> > > > > 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" > > <mglt> > > The text has been corrected as follows: > > Upon receiving a request to mitigate a DDoS attack performed over a > target, the orchestrator may evaluate the volumetry of the attack as > well as the value that the target represents. > > </mglt> > > > > 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. > > <mglt> > > Initially, I believe we wanted to distinguish between accepting the > mitigation and having the mitigation effective. I do not think that > necessary here as such details are provided in section 3.1. > > > > The orchestrator requests a DDoS Mitigation to the selected > DDoS mitigation systems via its DOTS client, as described in Section > 3.1. > > </mglt> > > 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? > > <mglt> > > We did not see any differences between the DMS. I believe that the text > above clarify the DMS is the one selected by the orchestrator. > > > > </mglt> > > > > 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? > > > <mglt> > > The orchestrator got DOTS client and DOTS servers. I updated the section > to clarify which entity is involved in term of DOTS. I believe that > clarifies the concern. > > > > </mglt> > > 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". > > <mglt> > > Just added this sentence. > > </mglt> > > Section 6 > > Is Med's name spelled correctly? > > <mglt> > > Now it is spelt correctly! Thanks. > > </mglt> > > > Thanks, > > Ben > > _______________________________________________ > Dots mailing list > Dots@ietf.org > https://www.ietf.org/mailman/listinfo/dots > > _______________________________________________ > 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