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

[Daniel Migault <[e-mail]>]

Hi,

Thank you Ben for you comments. Please find inline how these have been
addressed. The updated version has been pushed to [1].

The main questions I have for the co-authors are:
* does the change of volumetry to volume causes any concern ?
* I guess we could be a little be more specific regarding the delegation
and the pre-arrangement, in particular if BGP is secured. Please update
the text that has been proposed.

Yours,
Daniel


[1] https://github.com/dotswg/dots-use-cases

On Tue, May 12, 2020 at 4:22 PM Benjamin Kaduk <[e-mail]> 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.
>

<mglt>
As far as I know all authors mentioned significantly contributed to the
document. It is true that there are many co-authors, but I think that
reflected that DOTS needs to coordinate multiple actors that were not so
much coordinated before.
</mglt>

>
> 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.
>
> <mglt>
fixed
</mglt>

> 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".
>
> <mglt>
In most cases, if I recall correctly, we expect this to reflect a
contractual relation. That said, it is ultimately the DOTS client that
terminates the mitigation. To remove the impression that the ITP sort of
controls the DOTS client, I propose to change "can handle" by "may
handle".  Here is the updated text:

Once the DDoS attack has ended, or decreased to the certain
level that the enterprise DMS may handle by itself, the DOTS server
signals the enterprise DMS DOTS client that the attack has subsided.
</mglt>

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.
>
> <mglt>
I agree that we should not have DOTS telemetry systems and leave them as
DDoS telemetry systems. I checked the current version and there is no
mention of DOTS telemetry but only DDoS telemetry.
I also suggest the we specify that such collection is out of scope of DOTS.
with the following sentence:

the collection of this information is out of scope of DOTS.
</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(?): 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.
>
<mglt>
changed.
</mglt>

>
> Also, I think "volumetry" is not the right word here, and just "volume"
> suffices.
>
<mglt>
I am fine either way. The current version changed to volume, but I am
waiting co-authors to confirm they agree with the change.
</mglt>

>
>    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".
>
> <mglt>
fixed with the follwoing snetence:

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 inadvertent
disruption of legitimate services).
</mglt>

> 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).
>
> <mglt>
I added the note in the following paragraph.

These systems are configured so that when an event or some measurement
indicators reach a predefined level their associated DOTS client sends a
DOTS mitigation request to the orchestrator DOTS server. The DOTS
mitigation request may be associated with some optional mitigation hints
to let the orchestrator know what has triggered the request. In particular,
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)
</mglt>

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.
>
> <mglt>
Being ignorant on BGP, I am wondering if you are thinking of a BGP
procedure to announce routes or some procedure for enabling a delegation
when BGPsec is considered.
I porpose the following text:

These exact mechanisms
used for traffic steering are out of scope of DOTS, but will need to be
pre-arranged, while in some context such changed could be detected and
considered as an attack.

</mglt>

> 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.
>

<mglt>
I put it as normative.
</mglt>

>
> Thanks,
>
> Ben
>
> _______________________________________________
> Dots mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dots
>


-- 
Daniel Migault
Ericsson