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

Hi,

The extended number of authors was assigned by the chairs, however, all contributed significantly IMO.

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