Re: [Dots] WGLC for use cases draft - until July-1.
Daniel Migault <daniel.migault@ericsson.com> Wed, 18 July 2018 13:57 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 CEB2C130E31 for <dots@ietfa.amsl.com>; Wed, 18 Jul 2018 06:57:23 -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 TAkm8Fi9fJa0 for <dots@ietfa.amsl.com>; Wed, 18 Jul 2018 06:57:16 -0700 (PDT)
Received: from mail-lj1-x22a.google.com (mail-lj1-x22a.google.com [IPv6:2a00:1450:4864:20::22a]) (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 7786C130EC1 for <dots@ietf.org>; Wed, 18 Jul 2018 06:57:15 -0700 (PDT)
Received: by mail-lj1-x22a.google.com with SMTP id j19-v6so4188610ljc.7 for <dots@ietf.org>; Wed, 18 Jul 2018 06:57:15 -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=8VhrV/8I4AuCtHjVQkXkjvX2RJOMXDbvWzqwJwh1zKY=; b=bBGpf5tAioAswAQw4/VFezpf8e1nAQCyh+pUJ+wceTPTyu/N2Ue/VZx1SGDy3FB1Gy 50NafCA3xtXDO7agBzr+mbEjuyT+8S5SBzQHgbqB5GbmEPuD07kepVaWNhkoiCwZS49O o8jkThEQAZNEjgxHJeq2BE/RxH+78xZAi0H94fnyeqMjXj3OU8WvOUmvJuJD6q/cLbSA S2/FXH4Cl0JH0VhuahJXno25atFGU5VT4z8WFXnnNgl0GTPcC5z1CJk6tmGsRJzd5qd6 Hi+nj7Vd8RKhfMgoa2br3t+lM1zMnAjEZfwFRbfr+7ppKGU/eAlcSwmMY9V1J0Wu7Naf DYIg==
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=8VhrV/8I4AuCtHjVQkXkjvX2RJOMXDbvWzqwJwh1zKY=; b=MNaeF26uDX/LNPNaY5GyQwxxGZko7Qkqmv5UOvGZqh5z3Dl/vkkIKeLW30gnHcZW7u S23yj7YN6AVh+EQTSvzAclA2lIlAlISslICBqe7aeAmmQSrux5LXW86E9QagVwA2oWTr Q8MyR5YdR2JWE+uESto380UBQTvMTZ/buQYeo5nIF/OLcEwotMKins3USNIyWS6flV3a gZAHa5KWqTMy3U5cg0M8l9zF//wZOciSs2PAsmTwbaRMLtNB2QbCyan3+xLtouknwo3S 2OHVOTX1VVot0FtvKSo0+93MTLbRWS75PTcrwRDqwAxTO0CFU1/VgWe7Lxqu+1fc9OtY Oi9w==
X-Gm-Message-State: AOUpUlESx1kW50Y9+9i/bewrzEpqy1gH0uqUZlrRp8/CqLzuDRIiXQ32 n0mFwfc2vCdMS3gUwKx9tLU/FnX4bOgNMPobjak=
X-Google-Smtp-Source: AAOMgpcV5DHGUCEHC5VufGrmdim3eJo7i42RTMHyCZUJQnIVueZJE7aMV/Pbfn7M+Pb9cbphyaDKw+SJME4J15WMCgo=
X-Received: by 2002:a2e:750d:: with SMTP id q13-v6mr4557246ljc.148.1531922233590; Wed, 18 Jul 2018 06:57:13 -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 06:57:12 -0700 (PDT)
In-Reply-To: <BN6PR16MB14259007D03C0313E8D6468AEA530@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>
From: Daniel Migault <daniel.migault@ericsson.com>
Date: Wed, 18 Jul 2018 09:57:12 -0400
X-Google-Sender-Auth: aw4gs4RbwiE1Wr6INERA8BfQXB0
Message-ID: <CADZyTkmcc347A0dFvYKnrJXhrrhNCQCaq0OqEkRay=Noiqam-A@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="0000000000008e89a605714670c0"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dots/NY0NEJtyl8PJcPV4i0VZwO6FRiA>
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 13:57:24 -0000
Thanks for the feed back. I should be able to update the document appropriately. I will clarify by mentioning SFC as a possible way/example to have more complex, fine-tuned DDoS Mitigation strategies. Thanks you for the comments! Will do that hopefully this week. 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> > > ... > > [Message clipped] > _______________________________________________ > Dots mailing list > Dots@ietf.org > https://www.ietf.org/mailman/listinfo/dots > >
- Re: [Dots] WGLC for use cases draft - until July-… Daniel Migault
- Re: [Dots] WGLC for use cases draft - until July-… Konda, Tirumaleswar Reddy
- Re: [Dots] WGLC for use cases draft - until July-… Daniel Migault
- Re: [Dots] WGLC for use cases draft - until July-… Daniel Migault
- Re: [Dots] WGLC for use cases draft - until July-… Daniel Migault
- Re: [Dots] WGLC for use cases draft - until July-… Daniel Migault
- Re: [Dots] WGLC for use cases draft - until July-… Artyom Gavrichenkov
- Re: [Dots] WGLC for use cases draft - until July-… Konda, Tirumaleswar Reddy
- Re: [Dots] WGLC for use cases draft - until July-… Konda, Tirumaleswar Reddy
- Re: [Dots] WGLC for use cases draft - until July-… Konda, Tirumaleswar Reddy
- Re: [Dots] WGLC for use cases draft - until July-… Daniel Migault
- [Dots] WGLC for use cases draft - until July-1. Tobias Gondrom
- Re: [Dots] WGLC for use cases draft - until July-… Konda, Tirumaleswar Reddy
- Re: [Dots] WGLC for use cases draft - until July-… kaname nishizuka
- Re: [Dots] WGLC for use cases draft - until July-… Daniel Migault
- Re: [Dots] WGLC for use cases draft - until July-… Konda, Tirumaleswar Reddy
- Re: [Dots] WGLC for use cases draft - until July-… Daniel Migault
- Re: [Dots] WGLC for use cases draft - until July-… Konda, Tirumaleswar Reddy
- Re: [Dots] WGLC for use cases draft - until July-… Daniel Migault
- Re: [Dots] WGLC for use cases draft - until July-… Daniel Migault
- Re: [Dots] WGLC for use cases draft - until July-… Konda, Tirumaleswar Reddy
- Re: [Dots] WGLC for use cases draft - until July-… Daniel Migault
- Re: [Dots] WGLC for use cases draft - until July-… kaname nishizuka
- Re: [Dots] WGLC for use cases draft - until July-… Daniel Migault
- Re: [Dots] WGLC for use cases draft - until July-… Konda, Tirumaleswar Reddy
- Re: [Dots] WGLC for use cases draft - until July-… Daniel Migault