Re: [Dots] WGLC for use cases draft - until July-1.

Daniel Migault <daniel.migault@ericsson.com> Wed, 18 July 2018 15:44 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 E06471311AE for <dots@ietfa.amsl.com>; Wed, 18 Jul 2018 08:44:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.399
X-Spam-Level:
X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 WwR3Tm5Kj055 for <dots@ietfa.amsl.com>; Wed, 18 Jul 2018 08:44:42 -0700 (PDT)
Received: from mail-lf0-x236.google.com (mail-lf0-x236.google.com [IPv6:2a00:1450:4010:c07::236]) (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 BFBB413119E for <dots@ietf.org>; Wed, 18 Jul 2018 08:44:40 -0700 (PDT)
Received: by mail-lf0-x236.google.com with SMTP id b22-v6so3807388lfa.3 for <dots@ietf.org>; Wed, 18 Jul 2018 08:44:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=QRpmNBf35OlYcezXFO9b0F8wuizkJaMsTHtjeHsXxOI=; b=Oem384gjmlHfSF/LVQOS+aPX0Lyhl5iD/3XZLz008PmV9LC2atyxAzx5ND37jbQ3sx MHk02dygA49/P9TFT7hQwLzV2E+N53465FeVgIKW+JOaAyp+FkK0tLvCfVo/VK/wUgVk KEg6seByRtevZwJIThcNh4s9OaT12JoZ+grcotLDdBcAPGv55MNhyyayRbpGmlGIq1U3 M4AeZg4vk6W1iJ2e2Ko18hK+R4Ne+ZYyP6QC6l32jF8aKdfk5VBPemXuR4b11w018Xoa 5gf+5EtH+/hCEKBaiq9d+/pv38xRQaZefoGxzVIb2SDHRAGr50KAUxQaYXd8DRU9Fo1w Idkw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=QRpmNBf35OlYcezXFO9b0F8wuizkJaMsTHtjeHsXxOI=; b=cDZVIJzulmkZENXw85csippLYY67Lb8SWyeI/J2dUo8XYsCDAQhyxyN+wRUvc8G1vF 8ZaQOQKhvIYum9jHa4kmnz0KvmiRn1aEXSmItrH1FByivMYnI9uWkqMrqx+OoKHo/MFr DdCdXeKS3ByDVS4SYng0vUEg9JWwW9TZxTAdPOb/BQcjn8rZEJ7IOFdCSqi0uZ74YrLq kYsmPG2pC43Jcngrh5bsrcov5VBlySlj/pTh+rrH3yfXTraOzO+mZGSkgPr5Tg7Ygzld ZHgbUDePdIVrRs2+TGTwICNz0BahX4DIqcbmTwapB8CrLBI27paWlgAp8TEB3o2cxH/z 3feA==
X-Gm-Message-State: AOUpUlFOZMsBTHC3TfHOSfl+oAkFFhuhrfEidTcdtMj17QcB9hIhAZYg POSPcdM4uRIhJ3lIaXw0Gjqr3XB/Dy/MJJ0dmtc=
X-Google-Smtp-Source: AAOMgpdRkIcNdn65XmcSK03QThpPeYVtfKa/0xQgkOmz5YRYKSIxdtY46WPpaRzR4ogf9BPqWo0PkaIseRG7bvAbq0w=
X-Received: by 2002:a19:d095:: with SMTP id h143-v6mr4294582lfg.16.1531928678794; Wed, 18 Jul 2018 08:44:38 -0700 (PDT)
MIME-Version: 1.0
Sender: mglt.ietf@gmail.com
Received: by 2002:a2e:960a:0:0:0:0:0 with HTTP; Wed, 18 Jul 2018 08:44:37 -0700 (PDT)
In-Reply-To: <BN6PR16MB1425CFA8BF33B617E29FCDB3EA530@BN6PR16MB1425.namprd16.prod.outlook.com>
References: <033d01d40353$ee542d90$cafc88b0$@gondrom.org> <CADZyTk=dquqzKkM5qWiOw=0FvQx0xWfbD-uGhNVg5ZebuxJNhg@mail.gmail.com> <BN6PR16MB1425231C027D4C47A70A2B15EA700@BN6PR16MB1425.namprd16.prod.outlook.com> <CADZyTknKS4p4j8uihVr9gWHyRnGy7oZT8dhiqR-ERwDvBrkp0w@mail.gmail.com> <BN6PR16MB1425D144C8A810F613B1B17BEA4B0@BN6PR16MB1425.namprd16.prod.outlook.com> <CADZyTkkBq04wLhCiT2DdS67XG4=7FgVBZcWH1qnzjJN37atxfg@mail.gmail.com> <BN6PR16MB1425398195AD6AB074A36F89EA490@BN6PR16MB1425.namprd16.prod.outlook.com> <CADZyTkmP2jcc7E8UX4W9EUVqfjs=MnuzLdAjL3=ViEGEOKCw2Q@mail.gmail.com> <BN6PR16MB142516AF2BB80046F617B462EA480@BN6PR16MB1425.namprd16.prod.outlook.com> <CADZyTkkKE9Uw+uY7oqyergjrYvxsqWshbp1eenOu0ts_+-VqjQ@mail.gmail.com> <BN6PR16MB14257114A7E9F7AF29514FA0EA5D0@BN6PR16MB1425.namprd16.prod.outlook.com> <CADZyTkmBP-gp_i2xcGfX=kNYvQ=Dyo73Asm5JFuyBPK3e0sb9w@mail.gmail.com> <BN6PR16MB14259007D03C0313E8D6468AEA530@BN6PR16MB1425.namprd16.prod.outlook.com> <CADZyTkkdOO5h20z=WTFRii-b6Nx0feOiVT=M-y26MF9Fwk0yYw@mail.gmail.com> <BN6PR16MB1425CFA8BF33B617E29FCDB3EA530@BN6PR16MB1425.namprd16.prod.outlook.com>
From: Daniel Migault <daniel.migault@ericsson.com>
Date: Wed, 18 Jul 2018 11:44:37 -0400
X-Google-Sender-Auth: EiPHPfuKW6Wxze1uQQyPC8fVGtk
Message-ID: <CADZyTkmu9Co-ggmgg38Wi1Vxji1TXRaaVjjwJU+iYRzKMXRXZQ@mail.gmail.com>
To: "Konda, Tirumaleswar Reddy" <TirumaleswarReddy_Konda@mcafee.com>
Cc: Tobias Gondrom <tobias.gondrom@gondrom.org>, Roman Danyliw <rdd@cert.org>, "dots@ietf.org" <dots@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000b88ad7057147f093"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dots/TCAe9y8jmo-30WTPw3hwYBmbPVY>
Subject: Re: [Dots] WGLC for use cases draft - until July-1.
X-BeenThere: dots@ietf.org
X-Mailman-Version: 2.1.27
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: Wed, 18 Jul 2018 15:44:49 -0000

The reason I would rather leave the SFC is to show that orchestration may
be a bit more complex than selecting a DDoS Service Provider and can be
used to deploy your own orchestration. That said, if the WG prefers to
removes this I am fine removing it. If you have an opinion, please raise
you opinion asap!

Yours,
Daniel

On Wed, Jul 18, 2018 at 11:35 AM, Konda, Tirumaleswar Reddy <
TirumaleswarReddy_Konda@mcafee.com> wrote:

> Hi Daniel,
>
>
>
> Please see inline [TR]
>
>
>
> *From:* mglt.ietf@gmail.com [mailto:mglt.ietf@gmail.com] *On Behalf Of *Daniel
> Migault
> *Sent:* Wednesday, July 18, 2018 8:31 PM
> *To:* Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@McAfee.com>
> *Cc:* Tobias Gondrom <tobias.gondrom@gondrom.org>; Roman Danyliw <
> rdd@cert.org>; dots@ietf.org
> *Subject:* Re: [Dots] WGLC for use cases draft - until July-1.
>
>
>
> *CAUTION*: External email. Do not click links or open attachments unless
> you recognize the sender and know the content is safe.
> ------------------------------
>
> Hi Tiru,
>
>
>
> I believe the text below addresses your concerns:
>
>
>
>
>
> """
>
> The orchestrator analyses the various information it receives from DDoS
> telemetry system, and initiates one or multiple DDoS mitigation
> strategies. For example, the orchestrator could select the DDoS
> mitigation system in the Enterprise network or one provided by the ITP.
> Selection and technique may depends on the type of DDoS attack.
>
>
>
> [TR] I think you mean “The DDoS mitigation system selection and mitigation
> technique depends on the type of the DDoS attack”.
>
>
>
> In some
> cases, the orchestrator may proceed to a coordination that could occurs
> at a finer granularity such as the service functions involved into the
> DDoS Mitigation. Such orchestration is especially targeting DDoS attacks
> that evolves into mutli-vector attacks and could typically be
> implemented in a Service Function Chaining (SFC) {{?RFC7665}} context.
> In some case, a manual confirmation or selection may also be required to
> choose a proposed strategy or to initiate a DDoS Mitigation.  The DDoS
> Mitigation may consist of multiple steps such as configuring the
> network, or updating already instantiated DDoS mitigation functions.  In
> some SFC context, some specific  DDoS mitigation functions must be
> instantiated and properly ordered. Eventually, the coordination of the
> mitigation may involve external DDoS resources such as a transit
> provider or a DDoS Mitigation Service Provider.
>
>
>
> [TR] On second thought, I suggest removing rest of the above lines
> (discussing SFC and instantiation of DDOS mitigation functions looks like
> distraction to me)
>
>
>
> -Tiru
>
>
>
> """
>
>
>
> Yours,
>
> Daniel
>
>
>
> On Wed, Jul 18, 2018 at 5:05 AM, Konda, Tirumaleswar Reddy <
> TirumaleswarReddy_Konda@mcafee.com> wrote:
>
> Hi Daniel,
>
>
>
> Please see inline [TR]
>
>
>
> *From:* mglt.ietf@gmail.com [mailto:mglt.ietf@gmail.com] *On Behalf Of *Daniel
> Migault
> *Sent:* Tuesday, July 17, 2018 10:50 PM
> *To:* Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@McAfee.com>
> *Cc:* Tobias Gondrom <tobias.gondrom@gondrom.org>; Roman Danyliw <
> rdd@cert.org>; dots@ietf.org
> *Subject:* Re: [Dots] WGLC for use cases draft - until July-1.
>
>
>
> *CAUTION*: External email. Do not click links or open attachments unless
> you recognize the sender and know the content is safe.
> ------------------------------
>
> Hi Tiru,
>
>
>
> Please find my comments inline. Most of your comments have been addressed,
> I am waiting for your answer before updating and publishing the draft.
>
>
>
> Yours,
>
> Daniel
>
>
>
> On Mon, Jul 16, 2018 at 5:16 AM, Konda, Tirumaleswar Reddy <
> TirumaleswarReddy_Konda@mcafee.com> wrote:
>
> Hi Daniel,
>
>
>
> Few more comments and nits:
>
>
>
> 1.
>
> OLD:
>
>    Impersonation and traffic injection mitigation can be managed through
>
>    current secure communications best practices.
>
> NEW:
>
>    Impersonation and traffic injection attacks can be mitigated through
>
>    current secure communications best practices.
>
>
>
> <mglt>
>
> corrected
>
> </mglt>
>
> 2. In this use case, one or more DDoS telemetry systems or monitoring
>
>    devices monitor a network - typically an ISP network.
>
>
>
> Comment> why do say “typically an ISP network” ? (DDoS telemetry systems
> can also be used by Large Data Centers and Enterprises).
>
>
>
> <mglt>
>
> enterprise network and data centers have been added.
>
> </mglt>
>
> 3. The orchestrator analyses the various information it receives from
>
>    specialized equipment, and elaborates one or multiple DDoS mitigation
>
>    strategies.
>
>
>
> Comment> What kind of “specialized equipment” ? (You may want to re-use
> the previously defined term “DDoS telemetry system” instead of using
> specialized equipment).
>
> <mglt>
>
> done
>
> </mglt>
>
>
>
> Comment> I think you mean “finalizes one or multiple DDoS mitigation
> strategies”.
>
>
>
> <mglt>
>
> I think you propose to replace "ellaborate" by "finalize". I think
> finalize mena sthat mitigation has already started, which may not be the
> case. Maybe "initiate" may be better ?
>
>
>
> [TR] Yes.
>
>
>
> </mglt>
>
> Comment> You may want to give examples of the DDoS mitigation strategies.
>
> <mglt>
>
> I am happy to see what level of granularity or type of example you are
> willing to put. I have the impression that sky is the limit, and thus any
> example would be very specific. I am happy to add the text you are willing
> to see ;-)
>
>
>
> [TR] In this use case, the orchestrator can either select the DDoS
> mitigation system in the Enterprise network or the one provided by the
> Internet transit provider and the mitigation technique will depend on the
> type of DDoS attack.
>
> As pre my understanding, Mitigation strategy is a pro-active step to
> enhance the mitigation infrastructure to handle sophisticated DDoS attacks
> (e.g. handle large scale DDoS attacks by adding more scrubbing centers).
>
>
>
>
>
> </mglt>
>
>
>
>
>
> 4.
>
>
>
> OLD:
>
>
>
> In some case, a manual confirmation may also be required
>
> to choose a proposed strategy or to initiate a DDoS Mitigation.
>
>
>
> NEW:
>
> In some cases, manual selection by a human operator may also be required
>
> to choose a proposed strategy or to initiate a DDoS Mitigation.
>
>
>
> <mglt>
>
> proposed text:
>
> selection or confirmation
>
>
>
> [TR] Okay.
>
>
>
>
>
> </mglt>
>
> 5. The
>
>    DDoS Mitigation may consist of multiple steps such as configuring the
>
>    network, or updating already instantiated DDoS mitigation functions.
>
>    In some cases, some specific DDoS mitigation functions must be
>
>    instantiated and properly ordered.
>
>
>
>
>
> Comment> What kind of update is required for the instantiated DDoS mitigation function ?
>
> <mglt>
>
> by update I meant using the appropriated functions. More specifically,
> depending on the information you monitor you may use different anti DDoS
> function -- specific to the protocols. Ordered refers to the potential way
> functions are "orchetsrated". This means that you may have one SFC with
> multiple functions organized, this organization may change dynamically
> depending on the measurements.
>
>
>
> [TR] The above text  looks specific to SFC, DDoS mitigation provider may
> or may not use SFC.  You may want explicitly discuss the above line in the
> context of SFC.  DDoS attack can evolve into a multi-vector attack and the
> DDoS mitigator has to handle the attack traffic spanning multiple layers.
>
>
>
> </mglt>Comment> What do you mean by “properly ordered” ?
>
>
>
> 6.
>
> OLD:
>
>
>
>    The communications used to trigger a DDoS Mitigation between the
>
>    telemetry and monitoring systems and the orchestrator is performed
>
>    using DOTS.
>
>
>
> NEW:
>
>    The communications used to trigger DDoS Mitigation between the
>
>    DDoS telemetry systems and the orchestrator is performed
>
>    using DOTS.
>
>
>
> <mglt>
>
> telemetry has been changed to DDoS throughout the doc.
>
>
>
> [TR] Okay.
>
>
>
> Thanks,
>
> -Tiru
>
>
>
> </mglt>
>
> -Tiru
>
>
>
> *From:* mglt.ietf@gmail.com [mailto:mglt.ietf@gmail.com] *On Behalf Of *Daniel
> Migault
> *Sent:* Wednesday, June 27, 2018 8:24 PM
> *To:* Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@McAfee.com>
> *Cc:* Tobias Gondrom <tobias.gondrom@gondrom.org>; Roman Danyliw <
> rdd@cert.org>; dots@ietf.org
> *Subject:* Re: [Dots] WGLC for use cases draft - until July-1.
>
>
>
> *CAUTION*: External email. Do not click links or open attachments unless
> you recognize the sender and know the content is safe.
> ------------------------------
>
> Thanks Tiru for the feed back. I support the idea of your draft. I will
> publish the agreed version [1]. The diiff can be seen there [2] if there is
> anything I missed, please let me know.
>
>
>
> Additional comments are welcome!
>
> Yours
>
> Daniel
>
>
>
> [1] https://datatracker.ietf.org/doc/draft-ietf-dots-use-cases/
>
> [2] https://www.ietf.org/rfcdiff?url2=draft-ietf-dots-use-cases-13
>
>
>
> On Wed, Jun 27, 2018 at 2:27 AM, Konda, Tirumaleswar Reddy <
> TirumaleswarReddy_Konda@mcafee.com> wrote:
>
> Hi Daniel,
>
>
>
> Thanks for addressing all the comments, Please see inline [TR3]
>
>
>
> *From:* mglt.ietf@gmail.com [mailto:mglt.ietf@gmail.com] *On Behalf Of *Daniel
> Migault
> *Sent:* Tuesday, June 26, 2018 8:10 PM
> *To:* Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@McAfee.com>
> *Cc:* Tobias Gondrom <tobias.gondrom@gondrom.org>; Roman Danyliw <
> rdd@cert.org>; dots@ietf.org
> *Subject:* Re: [Dots] WGLC for use cases draft - until July-1.
>
>
>
> *CAUTION*: External email. Do not click links or open attachments unless
> you recognize the sender and know the content is safe.
> ------------------------------
>
> Hi Tiru,
>
>
>
> Please see my response inline. I believe we are close to reaching a
> consensus.
>
>
>
> Yours,
>
> Daniel
>
>
>
> On Tue, Jun 26, 2018 at 7:02 AM, Konda, Tirumaleswar Reddy <
> TirumaleswarReddy_Konda@mcafee.com> wrote:
>
> Hi Daniel,
>
>
>
> Please see inline [TR2]
>
>
>
> *From:* mglt.ietf@gmail.com [mailto:mglt.ietf@gmail.com] *On Behalf Of *Daniel
> Migault
> *Sent:* Tuesday, June 26, 2018 8:33 AM
> *To:* Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@McAfee.com>
> *Cc:* Tobias Gondrom <tobias.gondrom@gondrom.org>; Roman Danyliw <
> rdd@cert.org>; dots@ietf.org
> *Subject:* Re: [Dots] WGLC for use cases draft - until July-1.
>
>
>
> *CAUTION*: External email. Do not click links or open attachments unless
> you recognize the sender and know the content is safe.
> ------------------------------
>
> Hi,
>
>
>
> Thanks for the feed backs. IN my opinion the only issues that remain open
> are issues 1 and 15 . These are copied below. I provided also inline the
> status of each issues - for further details. Once we are clear with these
> two issues, I will publish a new version.
>
>
>
> Thanks you very much for teh comments.
>
>
>
> Yours,
>
> Daniel
>
>
>
>
>
>
>
> 1)
>
>    The current scenario describes the case where the DDoS Target is in
>    the enterprise network while the secondary DMS is provided by the
>    upstream ITP.  An alternate use case may consider the scenario where
>    the ITP informs the enterprise network it is involved into an ongoing
>    attack or that infected machines have been identified.  In this case
>    the DOTS client and DOTS server roles are inverted.  The DOTS client
>    is located in the ITP network and the DOTS server is hosted in the
>    enterprise network.  The enterprise network is then responsible to
>    perform the DDoS Mitigation.  In some case the DDoS Mitigation may be
>    delegated back to the upstream ITP, as described in this section.
>
>
>
> Comment>  If the DMS in the enterprise network is not capable of detecting
> outgoing DDoS attack, how will the signaling from the DOTS client in the
> upstream ITP to the DOTS server in the enterprise network help it to detect
> and mitigate the outgoing DDoS attack ?
>
> <mglt>
>
>
>
> While writing the use case the example I had in mind was that the ITP
> could signal the network enterprise that some hosts are being infected and
> belonging to a botnet. The ITP could provide a list of suspicious tagged
> IPv6 or the indication that hosts are suspected to belong to a specific
> botnet.
>
> The network enterprise may then take the necessary action, monitoring
> specific DNS requests, running specific scans over its hosts... At least
> this what I had in mind. The specific signaling should be defined by DOTS.
> Do you think the text should be updated as below ?
>
>
>
>
>
> OLD:
>
> [...] The enterprise network is then responsible to
>    perform the DDoS Mitigation.  In some case the DDoS Mitigation may be
>    delegated back to the upstream ITP, as described in this section.
>
> NEW:
>
> [...] The enterprise network is then responsible to
>    perform the DDoS Mitigation.  Typically, the ITP could provide a list
> of suspicious hosts with some additional information related the detected
> attacks such as DDoS, Botnet, .... According to the type of attack, the
> enterprise is likely to apply specific security policies which could
> include security checks, updates on the tagged hosts as well as
> instantiating specific monitoring traffic elements such as certain type of
> DNS queries, traffic of specific destination...  In some case the DDoS
> Mitigation may be
>    delegated back to the upstream ITP, as described in this section.
>
> [TR] The above text is not completely clear. The above text assumes hosts
> in the enterprise network are not behind NAT. Further, DMS in the
> enterprise network should be monitoring both incoming and outgoing traffic
> and capable of detecting outgoing DDoS attacks. I think the use case should
> only focus on volumetric attack exceeding the capacity of the DMS in the
> Enterprise network and not discuss multiple attack vectors (You may also
> want to look into the requirement GEN-004 (Mitigation hinting) in the
> requirements draft).
>
> </mglt>
>
>
>
> <mglt>
>
> I understand your comment for the hints. These were example of information
> provided. I agree to mention as GEN-004 that information is a hints that
> may be interpreted.
>
> What is not clear to me is that I do not see how volumetric attacks can be
> addressed in this case. A volumetric attack whose target is in the
> Enterprise Network woudl be detected by the DMS of that Enterprise network.
> In that case the DMS of the Enterprise network will have a DOTS client
> sending a request to the DOTS Server of the ITP..  This is not the case we
> consider here as it has already been described as the primary
> alternative.The reason for a ITP DMS to send a request to the DMS of the
> Enterprise could be 1) the Enterprise network is taking part of a DDoS
> atatck, 2) the ITP DMS delegate the DDoS mitigation to the DMS Enterprise
> network. I see 1) as informing that hosts of the network are being infected
> and being part of a botnet. I am confused by 2) as I see ITP DMS with ways
> more resource than the Enterprise network. Could you elaborate a bit on the
> scenario ?
>
>
>
> [TR2] I meant don’t club incoming and outgoing attacks in the same use
> case, my suggestion is to focus only on the incoming volumetric attack in
> this use case.
>
> If you plan to discuss outgoing attack from the Enterprise network, please
> add more details why the Enterprise DMS cannot detect the outgoing attacks
> and how will the additional information provided by the ITP DMS help the
> Enterprise DMS to detect outgoing DDoS attacks, and how this additional
> information is useful when the compromised hosts in the Enterprise networks
> are behind NAT ?
>
>
>
> </mglt>
>
> <mglt3>
>
> OK got it. Actually I added this use case after our discussion in the
> IETF. I believe also its is going a bit beyong the volumetric attacks. I am
> ok removing it. It has been removed on my local version.
>
>
>
> [TR3] Thanks.  I am facing problems with detecting all types of outgoing
> DDoS attacks on home routers (only few packets are punted to the slow path
> for inspection) and I think DOTS can help to punt traffic from compromised
> devices to slow path for outgoing DDoS traffic detection. Further,
> additional information like source IP and source ports conveyed in the DOTS
> signal channel to identify the hosts behind NAT, and the call home feature
> discussed in https://tools.ietf.org/html/rfc8071 is required for DOTS
> signal channel, though the CPE is acting as a DOTS server it will initiate
> the connection (TLS or DTLS) to the DOTS client in the access network, and
> then the roles get reversed.
>
>
>
> I will try to publish a draft before the DOTS WG meeting at IETF 102.
>
>
>
> </mglt3>
>
>
>
> 15) Figure 4 (DDoS Orchestration) includes both internal and external DDoS
> mitigation systems, but the usage of internal and external DDoS mitigation
> systems in
>        not discussed in section 3.3.
>
> <mglt>
>
> I propose the following change in teh beginign of teh section:
>
>
>
> OLD:
>
> In this use case, one or more DDoS telemetry systems or monitoring
> devices monitor a network - typically an ISP network.
>
>
>
> NEW:
>
> In this use case, one or more DDoS telemetry systems or monitoring
> devices spread over one or multiple administrative domains provides health
> indicator of the network traffic to the orchestrator
>
>
>
> I also propose to indicate on the figure ( orchetsrator adinistrative
> domain / other administraiev domains
>
>
>
> [TR] I don’t understand the multiple administrative domain use case. Why
> would multiple ISPs use the same orchestrator ?
>
>
>
> </mglt>
>
>
>
> <mglt>
>
> The use case considers the following administrative domains: ITP and
> Enterprise Network. I propose to simply replace "internal" by Enterprise
> Network and "external" by ITP.
>
>
>
> [TR2] Okay, but why would the upstream ITP and Enterprise network use the
> same orchestrator ?
>
> <mglt3>
>
> The orchestrator is in the Enterprise Network
>
> and decides between different DDoS Mitigation Serviec Provider. One of
> those is hosted in the NEterprise NEtwork, the other one is in the ITP..
> Sure they share the same orchestrator, but in my opinion that is the
> otherway around, the orchestrator got access to multiple providers. How do
> you think we should clarify this ?
>
>
>
> [TR3] Updated figure looks good to me, Thanks for the clarification.
>
>
>
> Cheers,
>
> -Tiru
>
>
>
> The figure I am proposing is as below:
>
>
>
>            +----------+
>            | network  |C            (Enterprise Network)
>            | adminis  |<-+
>            | trator   |  |
>            +----------+  |
>                          |
>            +----------+  | S+--------------+     +-----------+
>            |telemetry/|  +->|              |C   S| DDoS      |+
>            |monitoring|<--->| Orchestrator |<--->| mitigation||
>            |systems   |C   S|              |<-+  | systems   ||
>            +----------+     +--------------+C |  +-----------+|
>                                               |    +----------+
>            -----------------------------------|-----------------
>                                               |
>                                               |
>               (Internet Transit Provider)     |
>                                               |  +-----------+
>                                               | S| DDoS      |
>                                               +->| mitigation|
>                                                  | systems   |
>                                                  +-----------+
>            * C is for DOTS client functionality
>            * S is for DOTS server functionality
>
>    Figure 4: DDoS Orchestration
>
>
>
> </mglt3>
>
>
>
> -Tiru
>
>
>
> </mglt>
>
>
>
>
>
>
>
> On Sun, Jun 24, 2018 at 4:05 AM, Konda, Tirumaleswar Reddy <
> TirumaleswarReddy_Konda@mcafee.com> wrote:
>
> Hi Daniel,
>
>
>
> Please see inline [TR]
>
>
>
> *From:* mglt.ietf@gmail.com [mailto:mglt.ietf@gmail.com] *On Behalf Of *Daniel
> Migault
> *Sent:* Thursday, June 21, 2018 1:28 AM
> *To:* Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@McAfee.com>
> *Cc:* Tobias Gondrom <tobias.gondrom@gondrom.org>; Roman Danyliw <
> rdd@cert.org>; dots@ietf.org
> *Subject:* Re: [Dots] WGLC for use cases draft - until July-1.
>
>
>
> *CAUTION*: External email. Do not click links or open attachments unless
> you recognize the sender and know the content is safe.
> ------------------------------
>
> Hi Tiru,
>
>
>
> Thanks for the comments. Please see inline my responses. If the proposed
> text is fine to youI will update the draft and publish a new version by the
> end of the week.
>
>
>
> Yours,
>
> Daniel
>
>
>
> On Tue, Jun 19, 2018 at 9:05 AM, Konda, Tirumaleswar Reddy <
> TirumaleswarReddy_Konda@mcafee.com> wrote:
>
> Hi Daniel,
>
> My comments and nits
>
> 1)
>
>    The current scenario describes the case where the DDoS Target is in
>    the enterprise network while the secondary DMS is provided by the
>    upstream ITP.  An alternate use case may consider the scenario where
>    the ITP informs the enterprise network it is involved into an ongoing
>    attack or that infected machines have been identified.  In this case
>    the DOTS client and DOTS server roles are inverted.  The DOTS client
>    is located in the ITP network and the DOTS server is hosted in the
>    enterprise network.  The enterprise network is then responsible to
>    perform the DDoS Mitigation.  In some case the DDoS Mitigation may be
>    delegated back to the upstream ITP, as described in this section.
>
>
>
> Comment>  If the DMS in the enterprise network is not capable of detecting
> outgoing DDoS attack, how will the signaling from the DOTS client in the
> upstream ITP to the DOTS server in the enterprise network help it to detect
> and mitigate the outgoing DDoS attack ?
>
> <mglt>
>
>
>
> While writing the use case the example I had in mind was that the ITP
> could signal the network enterprise that some hosts are being infected and
> belonging to a botnet. The ITP could provide a list of suspicious tagged
> IPv6 or the indication that hosts are suspected to belong to a specific
> botnet.
>
> The network enterprise may then take the necessary action, monitoring
> specific DNS requests, running specific scans over its hosts... At least
> this what I had in mind. The specific signaling should be defined by DOTS.
> Do you think the text should be updated as below ?
>
>
>
>
>
> OLD:
>
> [...] The enterprise network is then responsible to
>    perform the DDoS Mitigation.  In some case the DDoS Mitigation may be
>    delegated back to the upstream ITP, as described in this section.
>
> NEW:
>
> [...] The enterprise network is then responsible to
>    perform the DDoS Mitigation.  Typically, the ITP could provide a list
> of suspicious hosts with some additional information related the detected
> attacks such as DDoS, Botnet, .... According to the type of attack, the
> enterprise is likely to apply specific security policies which could
> include security checks, updates on the tagged hosts as well as
> instantiating specific monitoring traffic elements such as certain type of
> DNS queries, traffic of specific destination...  In some case the DDoS
> Mitigation may be
>    delegated back to the upstream ITP, as described in this section.
>
> [TR] The above text is not completely clear. The above text assumes hosts
> in the enterprise network are not behind NAT. Further, DMS in the
> enterprise network should be monitoring both incoming and outgoing traffic
> and capable of detecting outgoing DDoS attacks. I think the use case should
> only focus on volumetric attack exceeding the capacity of the DMS in the
> Enterprise network and not discuss multiple attack vectors (You may also
> want to look into the requirement GEN-004 (Mitigation hinting) in the
> requirements draft).
>
> </mglt>
>
>
>
> <mglt>
>
> I understand your comment. These were example of information provided. I
> agree to mention as GEN-004 that information is a hints that may be
> interpreted. I do not see how volumetric attacks can be addressed in this
> case. A volumetric attack whose target is in the Entreprise Network woudl
> be detected by the DMS of that Enterprise network. In that case the DMS of
> the Enterprise network will have a DOTS client sending a request to the
> DOTS Server of the ITP..  This is not the case we consider here as it has
> already been described as the primary alternative.The reason for a ITP DMS
> to send a request to the DMS of the Enterprise could be 1) the Enterprise
> network is taking part of a DDoS atatck, 2) the ITP DMS delegate the DDoS
> mitigation to the DMS Enterprise network. I see 1) as informing that hosts
> of the network are being infected and being part of a botnet. I am confused
> by 2) as I see ITP DMS with ways more resource than the Enterprise network.
> Could you elaborate a bit on the scenario you have in mind ?
>
>
>
> </mglt>
>
>
> 2)
>    Once the requesting Enterprise Network is confident that the DDoS
>    attack has either ceased or has fallen to levels of traffic/
>    complexity which they can handle on their own or that it has received
>    a DOTS DDoS Mitigation termination request from a downstream
>    Enterprise Network or DDoS Mitigation Service Provider, the
>    requesting Enterprise Network DOTS client sends a DOTS DDoS
>    Mitigation termination request to the DDoS Mitigation Service
>    Provider.
>
> Comment> In the above line, I don't get "that it has received a DOTS DDoS
> Mitigation termination request from a downstream Enterprise Network or DDoS
> Mitigation Service Provider".
> I think you mean "or notified by the DDoS Mitigation Service Provider that
> the DDoS attack has stopped"
>
>
>
> <mglt>
>
> The text attempt to provide reasons for a DOTS Client to send a DOTS DDoS
> Mitigation termination request. It could be that a) information received
> from the upstream DMS indicates the attacks has been stopped or that the
> attack is sufficiently low so that it can handle the attack on its own. On
> the other hand, in the case of collaboration between DMS, a DMS may end the
> collaboration with an upstream DMS because the downstream DMS has requested
> so. I propose the follwoing clarification, please let me know if that is
> fine with you:
>
>
>
>
>
> OLD:
>
> Once the requesting Enterprise Network is confident that the DDoS
>    attack has either ceased or has fallen to levels of traffic/
>    complexity which they can handle on their own or that it has received
>    a DOTS DDoS Mitigation termination request from a downstream
>    Enterprise Network or DDoS Mitigation Service Provider, the
>    requesting Enterprise Network DOTS client sends a DOTS DDoS
>    Mitigation termination request to the DDoS Mitigation Service
>    Provider.
>
>
>
> NEW:
>
> Once the requesting Enterprise Network has been notified by the DDoS
> Mitigation Service
>    Provider. the attack has been stopped, or that the level of the attack
> has fallen to levels of traffic/
>    complexity which they can handle on their own, the Enterprise Network
> may notify the DDoS Mitigation Service Provider to stop the DDoS
> Mitigation.
>
>
>
>
>
> [TR] You may want to simplify the above text as follows :
>
> The DOTS server notifies the mitigation metrics to the DOTS client. If the
> DDoS attack has stopped or the severity of the attack has subsided, the
> DOTS client can request the DDoS Mitigation Service Provider to stop the
> DDoS Mitigation.
>
>
>
>
>
> Similarly, when DDoS Mitigation Service Providers are collaborating, a
> DDoS Mitigation Service Provider may relay the request for terminating a
> DDoS MItigation to the upstream DoS Mitigation Service Provider upon
> request from a downstream  DoS Mitigation Service Provider. In any case the
> termination of a DDoS Mitigation is requested by the Network Enterprise
> DOTS client sending a DOTS DDoS Mitigation termination request to the DDoS
> Mitigation Service Provider.
>
>
>
> [TR] I am not sure about the above lines, DDoS mitigation service
> providers collaborating with each other does not look relevant to this use
> case. You may want to remove the above lines.
>
>
>
> </mglt>
>
>
>
> <mglt>
>
> The reason for mentioning the collaboration was to indicate there are
> multiple reasons to stop the mitigation. You can be the one deciding given
> the status provided or your can can do that because you have been asked to
> do it. I am fine removing the latest case. Done.
>
>
>
> </mglt>
>
> 3)
>
>    The pre-arrangement typically includes the agreement on the
>    mechanisms used to redirect the traffic to the DDoS Mitigation
>    Service Provider, as well as the mechanism to to re-inject the
>
>  >>>>>>>>>>>>>>>>>>>>>>>>>>> Remove "to"
>
> <mglt>
>
> Done
>
> </mglt>
>
>
>
> [TR] Okay
>
>
>
> 4)
>
>    o  DDoS Mitigation Service: designates a DDoS service provided to a
>       customer and which is scoped to mitigate DDoS attacks.  Services
>       usually involve Service Level Agreement (SLA) that have to be met.
>       It is the responsibility of the service provider to instantiate
>       the DDoS Mitigation System to meet these SLAs.
>
>    o  DDoS Mitigation System (DMS): A system that performs DDoS
>       mitigation.  The DDoS Mitigation System may be composed by a
>       cluster of hardware and/or software resources, but could also
>       involve an orchestrator that may take decisions such as
>       outsourcing partial or more of the mitigation to another DDoS
>       Mitigation System.
>
> Nit> For better readability you may want to define "DMS" followed by "DDoS
> Mitigation Service"
>
>
>
> <mglt>
>
> Done
>
> </mglt>
>
>
>
> [TR] Thanks.
>
>
>
>
> 5)
>    DOTS is at risk from three primary attacks: DOTS agent impersonation,
>    traffic injection, and signaling blocking.  The DOTS protocol must be
>    designed for minimal data transfer to address the blocking risk.
>
> Comment> A MITM attacker can drop all the DOTS signal channel traffic,
> designing the DOTS signal channel protocol for minimal data
> transfer will not address the MITM attack.
>
>
>
> <mglt>
>
>  Agree. I propose to remove:
>
> """
>
> The DOTS protocol must be
>    designed for minimal data transfer to address the blocking risk.
>
> """
>
> </mglt>
>
>
>
> [TR] Thanks.
>
>
>
> <mglt>
>
> done
>
> </mglt>
>
>
> 6)
>    One consideration could be to minimize the security technologies in use
> at any one
>    time.  The more needed, the greater the risk of failures coming from
>    assumptions on one technology providing protection that it does not
>    in the presence of another technology.
>
> Comment> The DOTS signal and data channels are using TLS for mutual
> authentication, confidentiality and data integrity. I don't see the need
> for the above lines.
>
> <mglt>
>
> Agree.  I propose to remove the following lines:
>
> """
>
>  One consideration could be to minimize the security technologies in use
> at any one
>    time.  The more needed, the greater the risk of failures coming from
>    assumptions on one technology providing protection that it does not
>    in the presence of another technology.
>
> """
>
>
>
> </mglt>
>
>
>
> [TR] Okay.
>
>
>
> <mglt>
>
> done
>
> </mglt>
>
> 7)
>    When the DDoS mitigation is finished on the DMS, the orchestrator
>    indicates to the telemetry systems as well as to the network
>    administrator the DDoS mitigation is finished.
>
> Comment> I think you mean the DDoS attack has stopped. You may want to
> rephrase the line.
>
>
>
> <mglt>
>
> I propose the following text:
>
>
>
> OLD:
>
> When the DDoS mitigation is finished on the DMS, the orchestrator
>    indicates to the telemetry systems as well as to the network
>    administrator the DDoS mitigation is finished.
>
>
>
> NEW:
>
> When the DDoS attack has stopped, the orchestrator
>    indicates to the telemetry systems as well as to the network
>    administrator the end of the DDoS Mitigation.
>
> </mglt>
>
>
>
> [TR] Looks good.
>
> <mglt>
>
> done
>
> </mglt>
>
>
>
> 8)
>    Upon receiving the DOTS request for DDoS mitigation from the network
>    administrator, the orchestrator coordinates the DDoS mitigation
>    according to a specified strategy.  Its status indicates the DDoS
>    mitigation is starting while not effective.
>
> Comment> You may want to clarify the DOTS client will later be notified
> that the DDoS mitigation is effective.
>
>
>
> <mglt>
>
> I propose the following text:
>
>
>
> OLD:
>
> Upon receiving the DOTS request for DDoS mitigation from the network
>    administrator, the orchestrator coordinates the DDoS mitigation
>    according to a specified strategy.  Its status indicates the DDoS
>    mitigation is starting while not effective.
>
>
>
> NEW:
>
> Upon receiving the DOTS request for DDoS mitigation from the network
>    administrator, the orchestrator coordinates the DDoS Mitigation
>    according to a specified strategy.  Its status indicates the DDoS
>    Mitigation is starting while not effective. The DOTS client of the
> orchestrator will later be notified that the DDoS Mitigation is effective.
>
>
>
> [TR] Looks good.
>
>
>
> <mglt>
>
> done
>
> </mglt>
>
>
>
>
>
> </mglt>
>
>
> 9) If the network administrator decides to start the
>    mitigation, they order through her web interface a DOTS client to
>    send a request for DDoS mitigation.
>
> Nit> The above line is not clear, who are "they" in the above line ?
>
> <mglt>
>
> I propose the followin text:
>
>
>
> OLD:
>
> If the network administrator decides to start the
>    mitigation, they order through her web interface a DOTS client to
>    send a request for DDoS mitigation.
>
>
>
> NEW:
>
> If the network administrator decides to start the
>    mitigation, the network administrator orders through her web interface
> a DOTS client to
>    send a request for DDoS mitigation.
>
> </mglt>
>
>
>
> [TR] You may want to remove gender from the above line and simplify the
> text.
>
> NEW:
>
> If the network administrator decides to start the
> mitigation, the network administrator triggers the DDoS mitigation request
> using the web interface of a DOTS client.
>
>
>
>
>
> <mglt>
>
> Done
>
> </mglt>
>
> 10) This request is expected to be associated with a context that
> identifies the DDoS mitigation selected.
>
> Comment> I don't understand the context of the above line.
>
>
>
> <mg;t>
>
> The context constitutes of elements, indications that provides sufficient
> information to the orchestrator to know what needs to be done. in other
> words, the DDoS Mitigation.
>
> I propose the following text:
>
>
>
> OLD:
>
> This request is expected to be associated with a context that identifies
> the DDoS mitigation selected.
>
>
>
> NEW:
>
> This request is expected to be associated with a context that identifies
> or provide sufficient information to the orchestrator to in fer the DDoS
> Mitigation to elaborate and coordinate.
>
>
>
> [TR] NEW:
>
> This request is expected to be associated with a context that provides
> sufficient information to the orchestrator to infer the DDoS Mitigation to
> elaborate and coordinate.
>
>
>
>
>
> </mglt>
>
>
>
> <mglt
>
> done
>
> </mglt>
>
>
> 11)   Upon receiving the DOTS request for DDoS mitigation from the network
>    administrator, the orchestrator coordinates the DDoS mitigation
>    according to a specified strategy.
>
> Comment> What is the specified strategy (you may want to give an example) ?
>
> <mglt>
>
> I propose to add the follwoing text, but I am happy if you are willing to
> provide a more specific example.
>
>
>
> NEW:
>
> Upon receiving a request to mitigate a DDoS attack performed over a
> target, the orchestrator, may evaluate the volumetry of the attack as well
> as the value that represent the target. Then it may also request an
> upstream DMS Provider to filter the traffic while moving the target to
> another network so new sessions will not be impacted.
>
>
>
> [TR] I don’t think moving the target to a different network is easy.
> However, the orchestrator may select the DDoS mitigation provider based on
> the attack severity.
>
>
>
> </mglt>
>
>
>
> <mglt>
>
> I agree MTD is not easy, but I wanted to stress that the orchestrator can
> be coordinate complex operations ,that is a bit more than delegating. I
> have added the following text:
>
>
>
> NEW:
>
> Upon receiving a request to mitigate a DDoS attack performed over a
> target, the orchestrator, may evaluate the volumetry of the attack as well
> as the value that represent the target. The orchestrator may select the
> DDoS Mitigation Service  Provider based on the attack severity. It may also
> coordinate the DDoS Mitigation performed by the DDoS Mitigation Service
> Provider with some other tasks such as for example,  moving the target to
> another network so new sessions will not be impacted.
>
>
>
>
>
> </mglt>
>
>
> 12)
> The status of the DDoS mitigation indicates the orchestrator is in an
> analyzing phase.
>
>
>
> Comment> DOTS signal channel draft does not indicate the mitigation status
> is in analyzing phase (Please see "Table 2: Values of 'status' Parameter"
> in the draft).
>
> <mglt>
>
> I propose to remove:
>
>
>
> """
>
> The status of the DDoS
> mitigation indicates the orchestrator is in an analyzing phase.
>
> """
>
> </mglt>
>
>
>
> [TR] Okay
>
>
>
>  <mglt>
>
> Done
>
> </mglt>
>
> 13)
> The orchestrator begins collecting various information from various
> telemetry systems in order to correlate the measurements and provide  an
> analysis of the event.
> Comment> The orchestrator would anyway be collecting data from various
> telemetry systems for correlation.
>
> <mglt>
>
> Agree. I think what I wanted to say that we may move to a state where
> finer information is being monitored. I porposed the follwoing text:
>
>
>
> OLD:
>
> The orchestrator begins collecting various information from various
> telemetry systems in order to correlate the measurements and provide  an
> analysis of the event.
>
>
>
> NEW:
>
> The orchestrator may begin collecting additional fined grain and specific
> information from various  telemetry systems in order to correlate the
> measurements and provide an analysis of the event.
>
>
>
> [TR] Okay.
>
>
>
> </mglt>
>
>
>
>  <mglt>
>
> Done
>
> </mglt>
>
> 14) These systems are configured so that when an
>    event or some measurement indicators reach a predefined level to
>    report a DOTS mitigation request to the orchestrator.  The DOTS
>    mitigation request may be associated with some element such as
>    specific reporting.
>
> Comment> what do you mean by "some measurement indicators" and "specific
> reporting" (looks vague to me) ?
>
> <mglt>
>
>
>
> measurement indicators means to me, some variables that we believe
> representative for threat detection, this typically involved the traffic
> load, the number of SYNs...Specific reporting here indicates what the DOTS
> client refers to while triggering teh DDoS Mitigation request. I propose
> teh follwointext:
>
>
>
> OLD:
>
> These systems are configured so that when an
>    event or some measurement indicators reach a predefined level to
>    report a DOTS mitigation request to the orchestrator.  The DOTS
>    mitigation request may be associated with some element such as
>    specific reporting.
>
>
>
> NEW:
>
> These systems are configured so that when an
>    event or some measurement indicators reach a predefined level to
>   send DOTS mitigation request to the orchestrator.  The DOTS
>    mitigation request may be associated with additional information to let
> the orchestrator know what has triggered the request.
>
>
>
> [TR] Okay (Mitigation hints (“additional information”) are optional and is
> not mandatory to be conveyed in the mitigation request).
>
>
>
> </mglt>
>
>
>
>
>
> <mglt>
>
>
>
> Done
>
>
>
> The following text has been added:
>
> These systems are configured so that when an event or some measurement
> indicators reach a predefined level to send DOTS mitigation request to
> the orchestrator.  The DOTS mitigation request may be associated with
> some optional mitigation hints to let the orchestrator know what has
> triggered the request.
>
> </mglt>
>
>
>
> 15) Figure 4 (DDoS Orchestration) includes both internal and external DDoS
> mitigation systems, but the usage of internal and external DDoS mitigation
> systems in
>        not discussed in section 3.3.
>
> <mglt>
>
> I propose the following change in teh beginign of teh section:
>
>
>
> OLD:
>
> In this use case, one or more DDoS telemetry systems or monitoring
> devices monitor a network - typically an ISP network.
>
>
>
> NEW:
>
> In this use case, one or more DDoS telemetry systems or monitoring
> devices spread over one or multiple administrative domains provides health
> indicator of the network traffic to the orchestrator
>
>
>
> I also propose to indicate on the figure ( orchetsrator adinistrative
> domain / other administraiev domains
>
>
>
> [TR] I don’t understand the multiple administrative domain use case. Why
> would multiple ISPs use the same orchestrator ?
>
>
>
> </mglt>
>
>
>
> <mglt>
>
> The use case considers teh following administrative domains: ITP and
> Enterprise Network. I propose to simply replace internal by Enterprise
> Network and external by ITP.
>
>
>
> </mglt>
>
> 16) Redirection to the DDoS
>    Mitigation Service Provider typically involves BGP prefix
>    announcement eventually combined with DNS redirection, while re-
>    injection may be performed via tunneling mechanisms such as GRE for
>    example.
>
> Comment> You may want to clarify the scrubbed traffic is re-directed to
> the Enterprise network via the tunneling mechanism.
>
>
>
> <mglt>
>
> I propose the following text:
>
>
>
> OLD:
>
> Redirection to the DDoS
>    Mitigation Service Provider typically involves BGP prefix
>    announcement eventually combined with DNS redirection, while re-
>    injection may be performed via tunneling mechanisms such as GRE for
>    example.
>
>
>
> NEW:
>
> Redirection to the DDoS
>    Mitigation Service Provider typically involves BGP prefix
>    announcement eventually combined with DNS redirection, while re-
>    injection to the enterprise network may be performed via tunneling
> mechanisms such as GRE for
>    example.
>
>
>
> [TR] DNS redirection and BGP routing are two different diversion
> techniques, DNS redirection is not required after BGP announcement.
>
>
>
> [TR]
>
> NEW:
>
> Redirection to the DDoS
> Mitigation Service Provider typically involves BGP prefix
> announcement or DNS redirection, while re-injection of the scrubbed
> traffic to the enterprise network may be performed via tunneling mechanisms
> such as GRE for
> example.
>
>
>
>
>
> </mglt>
>
>
>
> <mglt>
>
> Done
>
> </mglt>
>
>
>
> 17) Of course, such mechanisms needs to be regularly tested and
>    evaluated.
>
> Comment> The above line does not look relevant to this document.
>
> <mglt>
>
>
>
> I am fine removing it.
>
>
>
> [TR] Okay.
>
>
>
> </mglt>
>
> <mglt>
>
> Done
>
> </mglt>
>
>
>
>
>
> 18)   Once the requesting Enterprise Network is confident that the DDoS
>    attack has either ceased or has fallen to levels of traffic/
>    complexity which they can handle on their own or that it has received
>    a DOTS DDoS Mitigation termination request from a downstream
>    Enterprise Network or DDoS Mitigation Service Provider, the
>    requesting Enterprise Network DOTS client sends a DOTS DDoS
>    Mitigation termination request to the DDoS Mitigation Service
>    Provider.
>
> Comment> It's not clear how the requesting Enterprise network will learn
> the DDoS attack has ceased ?
>
> <mglt>
>
> DOTS status may be used for example. I hope teh text provided for (2)
> clarifies this.
>
>
>
> [TR] You may want to rephrase the above line similar to the new text you
> have provided for (2).
>
>
>
> Cheers,
>
> -Tiru
>
>
>
> </mglt>
>
> -Tiru
>
> _______________________________________________
> Dots mailing list
> Dots@ietf.org
> https://www.ietf.org/mailman/listinfo/dots
>
>
>
>
> _______________________________________________
> Dots mailing list
> Dots@ietf.org
> https://www.ietf.org/mailman/listinfo/dots
>
>
>
>
> _______________________________________________
> Dots mailing list
> Dots@ietf.org
> https://www.ietf.org/mailman/listinfo/dots
>
>
>
>
> _______________________________________________
> Dots mailing list
> Dots@ietf.org
> https://www.ietf.org/mailman/listinfo/dots
>
>
>
>
> _______________________________________________
> Dots mailing list
> Dots@ietf.org
> https://www.ietf.org/mailman/listinfo/dots
>
>
>
>
> _______________________________________________
> Dots mailing list
> Dots@ietf.org
> https://www.ietf.org/mailman/listinfo/dots
>
>
>
> _______________________________________________
> Dots mailing list
> Dots@ietf.org
> https://www.ietf.org/mailman/listinfo/dots
>
>