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

Daniel Migault <mglt.ietf@gmail.com> Fri, 15 May 2020 20:00 UTC

Return-Path: <mglt.ietf@gmail.com>
X-Original-To: dots@ietfa.amsl.com
Delivered-To: dots@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B76033A08B3; Fri, 15 May 2020 13:00:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8v4AvTVHLn6q; Fri, 15 May 2020 13:00:25 -0700 (PDT)
Received: from mail-vk1-xa2a.google.com (mail-vk1-xa2a.google.com [IPv6:2607:f8b0:4864:20::a2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2AAB13A08B1; Fri, 15 May 2020 13:00:25 -0700 (PDT)
Received: by mail-vk1-xa2a.google.com with SMTP id 134so909270vky.2; Fri, 15 May 2020 13:00:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=NJ4gjRk8lBBzElXKmfrI0ykw66CP2WSyoAH5WUVq13c=; b=P3NS9u6lEUYw+fA9+iHehO0xFOdXucOCoIHJ+uyoxvfiIiTvq7pSPcNbDRtQXI5tWb DSFHSTJjGK33a1Qs18JKJv+nYFKUP+og4MzFOIprhg+VnbMGaEakWaBncfXCL0XVaIgx i4dSsaFi/hadnKl5IHafatiG3nqRFxoNywmXcTXJ/4BW/lEIPCZYfaA2HLsmUT5qtkUh FzvqYdm4ORA7GVwTY1YRyuWZwT/nSIlMuTnpP7hs607rDS+juKVGhYwDqB4WnsIBS0fJ apQm0kuAH5bUAjQvWiQXKyjm2G3hsntQJuO0VFd7ROA+wXQQ1lyP0DSqvHkhAAAVuHeS Z/rw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=NJ4gjRk8lBBzElXKmfrI0ykw66CP2WSyoAH5WUVq13c=; b=RQCkihLel95gnFdjZK4HCWQVRxqdLUocAkKQp5f87hVgJJGA+rzraMX60crqzzTcW8 ne2Ca2Fu/xnX8A1uEiK0EIXh9KYILZbZvRty4t5GGf+hgbVAKgEdv0AFHhlSC7V5nwbe kllTfCDhHYW05C1Fr2jy/4kNPIh00Kv9KwJwVkDMybQ1vH3K+8vmv/YkjPY9njTOuElB Ax0s35JLUeOJHrM1UTMOhhZWUNsKUfMXJ27d049FsZcTyTDWUEg+/wg9oRN5Kbixcs+x eKSAelP9iQWmLhzw11IOeVeGXY8ESwccLVWGZ0RYXqXKT9lrfp33dmhZ/YN96hLywyeY uo+w==
X-Gm-Message-State: AOAM531pL2xMTCbFBhxbqxeKY9fyCyBEDxYD2Igs7XK6Qm/0fnhywUje 6ucZH84uAoA8Lc2ARnmLCdaZsnC4JPng5DVkur4=
X-Google-Smtp-Source: ABdhPJw4kr72n7XOh67DMu2O6sclmQ+L5aB7Lmm10cYhIWkUoqLgdsoH+gjW8X4Mngc6bqmR3wyGEKnIPWLyT6Y5ymo=
X-Received: by 2002:a1f:5c16:: with SMTP id q22mr2383181vkb.89.1589572824140; Fri, 15 May 2020 13:00:24 -0700 (PDT)
MIME-Version: 1.0
References: <20200512202205.GF27494@kduck.mit.edu> <CADZyTkkk1rgnUOc=pnPWQbLB5vcniko_QDKn_pwYz0hTL79=dw@mail.gmail.com> <CABMKX9sHeS=Oa7=07pKpieSQkyJyx_MpUt4Dz1aEgVO27ykzow@mail.gmail.com> <CADZyTkkaqF=Cse05770tvYT2vBpC3S6RRp=28A9vCUWRgDPwaQ@mail.gmail.com> <134501d629c9$a74ec150$f5ec43f0$@jpshallow.com>
In-Reply-To: <134501d629c9$a74ec150$f5ec43f0$@jpshallow.com>
From: Daniel Migault <mglt.ietf@gmail.com>
Date: Fri, 15 May 2020 16:00:13 -0400
Message-ID: <CADZyTk=b0o1An7Z5hkLuE+Wmtz-b3vyfREOdNtOL3dZtEd5efA@mail.gmail.com>
To: Jon Shallow <supjps-ietf@jpshallow.com>
Cc: dots <dots@ietf.org>, Benjamin Kaduk <kaduk@mit.edu>, "Teague, Francis" <nteague@ironmountain.co.uk>, draft-ietf-dots-use-cases.all@ietf.org
Content-Type: multipart/alternative; boundary="000000000000870e1d05a5b543b8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dots/_sPVt_o_UZHG0BTnBBCtcLMfVUg>
Subject: Re: [Dots] AD evaluation of draft-ietf-dots-use-cases-20
X-BeenThere: dots@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." <dots.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dots>, <mailto:dots-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dots/>
List-Post: <mailto:dots@ietf.org>
List-Help: <mailto:dots-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dots>, <mailto:dots-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 15 May 2020 20:00:29 -0000

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

On Thu, May 14, 2020 at 4:28 AM Jon Shallow <supjps-ietf@jpshallow.com>
wrote:

> 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: dots-bounces@ietf.org] *On Behalf Of *Daniel Migault
> *Sent:* 14 May 2020 03:24
> *To:* Teague, Francis
> *Cc:* draft-ietf-dots-use-cases.all@ietf.org; 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.
>
>
>
> 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 <
> nteague@ironmountain.co.uk> 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 <mglt.ietf@gmail.com> 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 <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.
>
>
>
> <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
> Dots@ietf.org
> https://www.ietf.org/mailman/listinfo/dots
>
>
>
>
> --
>
> Daniel Migault
>
> Ericsson
>
>
> 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.
>
>
>
>
> --
>
> Daniel Migault
>
> Ericsson
>


-- 
Daniel Migault
Ericsson