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

[Robert Moskowitz <[e-mail]>]

Sorry that I cannot review this until Wednesday.  Family in for the 
weekend and cataract surgery (2nd eye) Monday.  It is amazing how 
cataract surgery is 'no big deal' compared to when my parents had it 
done.  20 min under the knife and back in business (except for the eye 
drops for a week) in 24 hours.

I suspect that you all caught all the nits that need to be fixed.

Have a good weekend and check out the hotRFC I am helping out with.

On 7/5/19 8:23 AM, Daniel Migault wrote:
> Thanks, just pushed the update.
> Yours,
> Daniel
>
> On Fri, Jul 5, 2019 at 3:21 AM kaname nishizuka <[e-mail] 
> <mailto:[e-mail]>> 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 <[e-mail]
>>     <mailto:[e-mail]>> 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
>>         [e-mail] <mailto:[e-mail]>
>>         https://www.ietf.org/mailman/listinfo/dots
>>
>
>     _______________________________________________
>     Dots mailing list
>     [e-mail] <mailto:[e-mail]>
>     https://www.ietf.org/mailman/listinfo/dots
>

-- 
Standard Robert Moskowitz
Owner
HTT Consulting
C:248-219-2059
F:248-968-2824
E:[e-mail]

There's no limit to what can be accomplished if it doesn't matter who 
gets the credit