Re: [Dots] AD evaluation of draft-ietf-dots-use-cases-20

Hi Ben,

Thank you for the comments. I merge your pull request and will go through
the comments in the email in the next two days.

Yours,
Daniel

On Tue, May 12, 2020 at 4:22 PM Benjamin Kaduk <kaduk@mit.edu> wrote:

> Hi all,
>
> This one is in pretty good shape -- I don't have any major comments on it.
> I did write up some editorial nit-level stuff as a github pull request:
> https://github.com/dotswg/dots-use-cases/pull/12 .  I think that nothing
> there should be controversial, but please let me know if I am wrong about
> that.
>
> Please confirm that all six authors made significant contributions: I
> will need to defend this to the rest of the IESG, since per RFC 7322 the
> author count is generally limited to five individuals.  Right now I don't
> have a good response when someone asks.
>
> Section 1
>
>    As DDoS solutions are broadly heterogeneous among vendors, the
>    primary goal of DOTS is to provide high-level interaction amongst
>    differing DDoS solutions, such as detecting, initiating, terminating
>    DDoS mitigation assistance or requesting the status of a DDoS
>    mitigation.
>
> nit: the list structure is not properly parallel.  It looks like the
> various clauses are meant to be "detecting DDoS",
> "initiating/terminating mitigation assistance", and "requesting
> mitigation status", so maybe this could become:
>
> % As DDoS solutions are broadly heterogeneous among vendors, the
> % primary goal of DOTS is to provide high-level interaction amongst
> % differing DDoS solutions, such as detecting DDoS attacks,
> % initiating/terminating DDoS mitigation assistance, or requesting the
> % status of a DDoS mitigation.
>
> Section 3.1
>
>    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.
>
> It's interesting that this is worded in such a way that the (ITP) DOTS
> server knows the specific threshold for what level of attack traffic the
> enterprise DMS can handle, since it's the DOTS server signalling to the
> client that "the attack has subsided".
>
> Section 3.3
>
>    Upon receipt of the DOTS mitigation request from the DDoS telemetry
>    system, the orchestrator DOTS server responds with an acknowledgment,
>    to avoid retransmission of the request for mitigation.  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.
>
> The last sentence seems to say that how the orchestrator gets data from
> the initial DOTS client telemtry system is out-of-scope, but the
> previous sentence talks about the orchestrator collecting information
> from (other) DOTS telemetry systems.  Is that similarly out of scope?
> If so, then the fact that they are specifically *DOTS* telemetry systems
> seems irrelevant and we should probably just describe them as generic
> telemetry or monitoring systems.
>
>    Upon receiving a request to mitigate a DDoS attack performed over a
>    target, the orchestrator may evaluate the volumetry of the attack as
>
> nit(?): is "performed over" a conventional usage?  I would have expected
> something more like "aimed at" given my personal background, but could
> just be ignorant of typical usage.
>
> Also, I think "volumetry" is not the right word here, and just "volume"
> suffices.
>
>    filter the traffic.  In this case, the DDoS mitigation system
>    implements a DOTS client while the orchestrator implements a DOTS
>    server.  Similar to other DOTS use cases, the offloading scenario
>    assumes that some validation checks are followed by the DMS, the
>    orchestrator, or both (e.g., avoid exhausting the resources of the
>    forwarding nodes or disrupting the service).  These validation checks
>    are part of the mitigation, and are therefore out of the scope of the
>    document.
>
> I know we added this last chunk of text after a long exchange during the
> last WGLC, and understand the desire to avoid going into too many
> details on a topic that is mostly out of scope for DOTS.  That said, I'd
> suggest adding a couple more words around "disrupting the service"
> (especially since some level of service disruption during an attack
> might be expected!) to help the reader make the link to what kind of
> validation is expected, perhaps something like "inadvertent disruption
> of legitimate services".
>
> Section 4
>
> In light of my previous comment I don't want to go too far here, but I
> could see it being relevant to have a note that in the "orchestration"
> case it's possible for something that locally to one telemetry system
> looks like an attack is not actually an attack when seen from the
> broader scope (e.g., of the orchestrator).
>
> In the Third Party MSP case we mention BGP as a way to steer traffic to
> the mitigation service.  We could consider (but don't have to)
> mentioning that efforts to secure BGP will need to be considered when
> making pre-arrangements for how traffic is to be moved, since in some
> contexts such BGP announcements could themselves be considered to be an
> attack.
>
> I guess it probably goes without saying that when you add a third-party
> DMS to your setup, you depend on that third party to be operational in
> order for your setup to work properly.
>
> Section 7
>
> We'll probably get someone asking to move RFC 8612 to be a Normative
> reference since we use it for terminology, but I don't mind leaving it
> be for now.
>
> Thanks,
>
> Ben
>
> _______________________________________________
> Dots mailing list
> Dots@ietf.org
> https://www.ietf.org/mailman/listinfo/dots
>

-- 
Daniel Migault
Ericsson