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

Daniel Migault <daniel.migault@ericsson.com> Fri, 05 July 2019 12:24 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 9F02E1201D7; Fri, 5 Jul 2019 05:24:06 -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 NXFmHmiOWTt1; Fri, 5 Jul 2019 05:24:03 -0700 (PDT)
Received: from mail-vs1-f42.google.com (mail-vs1-f42.google.com [209.85.217.42]) (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 C6F5E1201D9; Fri, 5 Jul 2019 05:24:02 -0700 (PDT)
Received: by mail-vs1-f42.google.com with SMTP id u3so3691702vsh.6; Fri, 05 Jul 2019 05:24:02 -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=bZagpZbFKSJ2k3qYvPvSTzPyThcp2atL302AapLxZKo=; b=L6LLmLWhbzDODfPWQ7W230CFxxh3MF3wM274PrzFtBTKhGnTjEkcDT+hvdpxM3nOaC isLhm+aXfFqLVYB1xutSSgS2/Stui6Yzet+gKvlc3vjuCEAear8EESpEodEL/pl3BdaE Os2+xWhib7hyvYtQa84kuiLfc3PmRIQC85k/BELHC510bSVnIt5N4wHdT0xCDoiEY79g NHEFsjjxHznNQvMk8RopmuedxzTIdnmoSMGww+4HCn6fbqwlCWog7JzUKBvdBiZRUYXC zSua+6DWG/f19xdRB0tP7RKrfjYV6eYLpWYu0EQc7Jd+ENE66qk3AJMQcmvomdP+Fm3n r4rg==
X-Gm-Message-State: APjAAAV5dR/P621WG5iEcnvhQrjI3xxdeYBxHzSh0aoLrtAJ5oUMYkY+ rRuU5+udksizxrsIGdaJgd6sCtsfRo5xDvp4VtIfUA==
X-Google-Smtp-Source: APXvYqyCw1iAZxMtqibg2NINy4ll8Ar1PAhg+MUNP1cbyIKT0SUzCJX+Q+n+JfVQ93sIe4fURUKOPxP7AAwRT9XIAz0=
X-Received: by 2002:a67:e90c:: with SMTP id c12mr1847636vso.97.1562329441729; Fri, 05 Jul 2019 05:24:01 -0700 (PDT)
MIME-Version: 1.0
References: <20190702223654.GF13810@kduck.mit.edu> <CADZyTk=odGB8n=B3RWU1i_xumH3TRo+Rn5v6NsFVRZzUKdpaRA@mail.gmail.com> <1e54ef4a-a9f3-9aff-ea30-6c65a015eb8e@nttv6.jp>
In-Reply-To: <1e54ef4a-a9f3-9aff-ea30-6c65a015eb8e@nttv6.jp>
From: Daniel Migault <daniel.migault@ericsson.com>
Date: Fri, 5 Jul 2019 08:23:50 -0400
Message-ID: <CADZyTknK4aoiqLQe8LYZetW_Lv=85fTBjzO8c3fcmAKBOri=Ow@mail.gmail.com>
To: kaname nishizuka <kaname@nttv6.jp>
Cc: Benjamin Kaduk <kaduk@mit.edu>, draft-ietf-dots-use-cases.all@ietf.org, dots <dots@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000657eee058cee2bc8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dots/Cw8-8lpfWKtONLubYDgDGQzEXz0>
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:24:07 -0000

Thanks, just pushed the update.
Yours,
Daniel

On Fri, Jul 5, 2019 at 3:21 AM kaname nishizuka <kaname@nttv6.jp>; wrote:

> Hi Daniel,
>
> Thank you for the correction and clarification.
>
> > WG, co-authors, please review section 3.3 by Friday EOB.
> I've reviewed it.
> DOTS client/server involved was clarified and how the DDoS Orchestration
> usecase work is described as it was originally intended.
>
> nit: (Line 539, 540)
> The orchestrator implements a DOTS Client while the DDoS mitigation
> systems implement a DOTS Server.
> Client->client, Server->server
>
> thanks!
> Kaname Nishizuka
>
> On 2019/07/05 5:13, Daniel Migault wrote:
>
> 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
>