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

From: Benjamin Kaduk <[email-masked]>
Date: Tue, 12 May 2020 13:22:05 -0700

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

---

From: Daniel Migault <[email-masked]>
Date: Tue, 12 May 2020 23:26:11 -0400

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 <[email-masked]> wrote:

> _______________________________________________
> Dots mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dots
>

-- 
Daniel Migault
Ericsson

---

From: Daniel Migault <[email-masked]>
Date: Wed, 13 May 2020 12:06:45 -0400

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

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

> <mglt>
fixed
</mglt>

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

> just be ignorant of typical usage.
<mglt>
changed.
</mglt>

> Also, I think "volumetry" is not the right word here, and just "volume"
<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>

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

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

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

> reference since we use it for terminology, but I don't mind leaving it

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

-- 
Daniel Migault
Ericsson

---

From: "Teague, Francis" <[email-masked]>
Date: Wed, 13 May 2020 18:06:19 +0100

Hi,

Volumetry is awkward - generally an attack is characterized as
volumetric so volume would be correct IMO.

On the BGP side - My 2c - There are methods such as RPKI etc. which present
concerns for BGP based mitigations where implemented, however, these may be
overcome in a number of ways (the mitigator being authorized to originate
prefixes using the customer ASN for example during an attack).  The methods
used to overcome these challenges while remaining compliant with a
particular mechanism are really between the requestor and mitigator to
thrash out.  I'm not sure we should call it out as its part of the wider
relationship/onboarding process.  It's probably a topic for its own BCP
though.

Thanks,

-Nik

On Wed, 13 May 2020 at 17:07, Daniel Migault <[email-masked]> wrote:

> I also suggest the we specify that such collection is out of scope of
> DOTS. with the following sentence:
>
> 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>
>

-- 
The information contained in this email message and its attachments is 
intended only for the private and confidential use of the recipient(s) 
named above, unless the sender expressly agrees otherwise. Transmission of 
email over the Internet is not a secure communications medium. If you are 
requesting or have requested the transmittal of personal data, as defined 
in applicable privacy laws by means of email or in an attachment to email, 
you must select a more secure alternate means of transmittal that supports 
your obligations to protect such personal data. 

If the reader of this 
message is not the intended recipient and/or you have received this email 
in error, you must take no action based on the information in this email 
and you are hereby notified that any dissemination, misuse or copying or 
disclosure of this communication is strictly prohibited. If you have 
received this communication in error, please notify us immediately by email 
and delete the original message.

---

From: Daniel Migault <[email-masked]>
Date: Wed, 13 May 2020 22:24:00 -0400

Thanks for the feed back Nick. I sort of understand that the current text
fits your comment, but prefer to double check before publishing the next
version. Feel free to change the text as you wish.

Here is the text in question:
"""
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.
"""

Yours,
Daniel

On Wed, May 13, 2020 at 1:06 PM Teague, Francis <[email-masked]>
wrote:

> On the BGP side - My 2c - There are methods such as RPKI etc. which
> present concerns for BGP based mitigations where implemented, however,
> these may be overcome in a number of ways (the mitigator being authorized
> to originate prefixes using the customer ASN for example during an
> attack).  The methods used to overcome these challenges while remaining
> compliant with a particular mechanism are really between the requestor and
> mitigator to thrash out.  I'm not sure we should call it out as its part of
> the wider relationship/onboarding process.  It's probably a topic for its
> own BCP though.
>
> Thanks,
>
> -Nik
>
>> 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
>>>
> If the reader of this message is not the intended recipient and/or you
> have received this email in error, you must take no action based on the
> information in this email and you are hereby notified that any
> dissemination, misuse or copying or disclosure of this communication is
> strictly prohibited. If you have received this communication in error,
> please notify us immediately by email and delete the original message.
>

-- 
Daniel Migault
Ericsson

---

From: kaname nishizuka <[email-masked]>
Date: Thu, 14 May 2020 11:41:15 +0900

Hi,

1. "the volume of the attack" is more understandable.

2. "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."
The proposed text seems sufficient to me. +1 to Nik's comments. > It's probably a topic for its own BCP

thanks,
Kaname

On 2020/05/14 2:06, Teague, Francis wrote:
> Hi,
>
> Volumetry is awkward - generally an attack is characterized as volumetric so volume would be correct IMO.
>
> On the BGP side - My 2c - There are methods such as RPKI etc. which present concerns for BGP based mitigations where implemented, however, these may be overcome in a number of ways (the mitigator being authorized to originate prefixes using the customer ASN for example during an attack).  The methods used to overcome these challenges while remaining compliant with a particular mechanism are really between the requestor and mitigator to thrash out.  I'm not sure we should call it out as its part of the wider relationship/onboarding process.  It's probably a topic for its own BCP though.
>
> Thanks,
>
> -Nik
>
> On Wed, 13 May 2020 at 17:07, Daniel Migault <[email-masked] <mailto:[email-masked]>> wrote:
>
>     Hi,
>
>     Thank you Ben for you comments. Please find inline how these have been addressed. The updated version has been pushed to [1].
>
>     * 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
>
>
>     On Tue, May 12, 2020 at 4:22 PM Benjamin Kaduk <[email-masked] <mailto:[email-masked]>> wrote:
>
>         Hi all,
>
>     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
>
>     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:
>
>     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:
>
>     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>
>
>
>     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
>
>     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>
>
>     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.
>     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>
>
>         [email-masked] <mailto:[email-masked]>
> The information contained in this email message and its attachments is intended only for the private and confidential use of the recipient(s) named above, unless the sender expressly agrees otherwise. Transmission of email over the Internet is not a secure communications medium. If you are requesting or have requested the transmittal of personal data, as defined in applicable privacy laws by means of email or in an attachment to email, you must select a more secure alternate means of transmittal that supports your obligations to protect such personal data.
>
> If the reader of this message is not the intended recipient and/or you have received this email in error, you must take no action based on the information in this email and you are hereby notified that any dissemination, misuse or copying or disclosure of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by email and delete the original message.
>

---

From: Benjamin Kaduk <[email-masked]>
Date: Wed, 13 May 2020 19:49:18 -0700

Hi Daniel,

Just a few replies inline.

> reflected that DOTS needs to coordinate multiple actors that were not so

Thanks, that is good to know.

> signals the enterprise DMS DOTS client that the attack has subsided.

I'd consider "might" instead of "may", since sometimes in English "may" has
a connotation of granting permission.

> mention of DOTS telemetry but only DDoS telemetry.

Oops, I seem to have misread this text!  Of course, generic DDoS telemetry
systems make sense in this context.

> the collection of this information is out of scope of DOTS.

Okay.

> when BGPsec is considered.

I think either could be problmatic in some (rare?) circumstances -- I
believe in some cases there are allow-lists for which neighbors'
announcements of which prefixes are acted upon, and of course when the RPKI
comes into play that needs to validate properly as well.

> pre-arranged, while in some context such changed could be detected and

I agree with the other commenters that a separate BCP is where the details
should be covered.

Thanks,

Ben

---

From: "Jon Shallow" <[email-masked]>
Date: Thu, 14 May 2020 09:28:32 +0100

Hi Daniel,

The suggested text needs correcting

OLD

in some context such changed could

NEW

in some contexts such changes could

Regards

Jon

From: Dots [mailto: [email-masked]] On Behalf Of Daniel Migault
Sent: 14 May 2020 03:24
To: Teague, Francis
Cc: [email-masked]; Benjamin Kaduk; dots
Subject: Re: [Dots] AD evaluation of draft-ietf-dots-use-cases-20

Thanks for the feed back Nick. I sort of understand that the current text fits your comment, but prefer to double check before publishing the next version. Feel free to change the text as you wish. 

"""

These exact mechanisms

"""

Yours, 

Daniel

On Wed, May 13, 2020 at 1:06 PM Teague, Francis <[email-masked]> wrote:

Hi,

Thanks,

-Nik

Hi, 

Yours, 

Daniel   

Hi all,

<mglt>

</mglt> 

Section 1

<mglt>

fixed

</mglt> 

Section 3.1

<mglt>

</mglt> 

Section 3.3

<mglt>

</mglt>

<mglt>

changed.

</mglt> 

<mglt>

</mglt> 

<mglt>

</mglt> 

Section 4

<mglt>

</mglt> 

<mglt>

These exact mechanisms

</mglt> 

Section 7

<mglt>

I put it as normative. 

</mglt> 

Thanks,

Ben

 

-- 

Daniel Migault

Ericsson

 

-- 

Daniel Migault

Ericsson

---

From: Daniel Migault <[email-masked]>
Date: Fri, 15 May 2020 15:59:34 -0400

Hi Ben,

Thanks for the follow up. I believe I implemented the changes, and will
publish a new version.
Yours,
Daniel

<mglt>
changed.
</mglt>

> some
> particular,

-- 
Daniel Migault
Ericsson

---

From: Daniel Migault <[email-masked]>
Date: Fri, 15 May 2020 16:00:13 -0400

Thanks Jon for the comment. I updated the text. Thanks!
Yours,
Daniel

On Thu, May 14, 2020 at 4:28 AM Jon Shallow <[email-masked]>
wrote:

> *From:* Dots [mailto: [email-masked]] *On Behalf Of *Daniel Migault
> *Sent:* 14 May 2020 03:24
> *To:* Teague, Francis
> *Cc:* [email-masked]; Benjamin Kaduk; dots
> *Subject:* Re: [Dots] AD evaluation of draft-ietf-dots-use-cases-20
>
>
>

-- 
Daniel Migault
Ericsson