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

[Daniel Migault <[e-mail]>]

Hi Ben,

Thanks for the follow up. I believe I implemented the changes, and will
publish a new version.
Yours,
Daniel
On Wed, May 13, 2020 at 10:49 PM Benjamin Kaduk <[e-mail]> wrote:

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


-- 
Daniel Migault
Ericsson