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

[Benjamin Kaduk <[e-mail]>]

Hi Daniel,

Just a few replies inline.

On Wed, May 13, 2020 at 12:06:45PM -0400, Daniel Migault wrote:
> 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>

Thanks, that is good to know.

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

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

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

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

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

Okay.

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

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

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

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

Thanks,

Ben