Re: [Dots] WGLC for use cases draft - until July-1.
Daniel Migault <daniel.migault@ericsson.com> Wed, 04 July 2018 13:03 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 075E9130F03 for <dots@ietfa.amsl.com>; Wed, 4 Jul 2018 06:03:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.398
X-Spam-Level:
X-Spam-Status: No, score=-1.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.25, 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 xsAQEL9LxU95 for <dots@ietfa.amsl.com>; Wed, 4 Jul 2018 06:03:51 -0700 (PDT)
Received: from mail-lf0-x231.google.com (mail-lf0-x231.google.com [IPv6:2a00:1450:4010:c07::231]) (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 5D0FE127332 for <dots@ietf.org>; Wed, 4 Jul 2018 06:03:49 -0700 (PDT)
Received: by mail-lf0-x231.google.com with SMTP id m13-v6so4323963lfb.12 for <dots@ietf.org>; Wed, 04 Jul 2018 06:03:49 -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=9QM9Q/TSeE1/tYvHJrKzhOuL7r+nd35KppcnqzAKvXg=; b=fBAktj19qpuA7uGWm8BXeB97HSHDjj5LliwVIiBHbx3LJFtQkvpP1NocIakJ7lcbdN QVsNrdtbATtMDeHkQrGQypeYkXw/bSd9RNygTx6tHsZajSeFk9o33FQdG12sLslffqh5 nC2hPMQWCGXUGMXsTwCMLpR0wEUpYBm+wnmJMF0d19CauyCB/Uzp5v3jsDgGO1JA06Is h9pdC9Oonbo7AW8gM+gSv1BNb5VBVDVJPjuLCB4EqpG7pChtcItPHFf80xtv5KUHJUkH UASOuW3iNasvaU2gqTyAp7gb0g2R+5idXguKJydAMUHkqY1emUFvlaNGz3nRaeNliyml 5Gng==
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=9QM9Q/TSeE1/tYvHJrKzhOuL7r+nd35KppcnqzAKvXg=; b=OJ5jz6OtObUr9VSOEJQywF+iDCN/InRXmP1V/Otq7G+5BFW5k18uTNUntYSOUeCyA/ 3Gp5mxCzEl+uQXhwrUWSLJnWwm0hvBsWJFB4Q+WykAoHOwipzKcHesgYXx4B8YJ0sw0E fUsuHQA2smMJR1hgiNJ3xW9YWFD5fK4PqIn6TlkyXAS1Kxfwq/EbZ9UN2qZW4oJ18FpH G7pRm0F8v53fc/ME5XaugAzXl+ghgfzN+95sZd1q5dQANDQTA5Mv8ZB8bErSnJr+uWdI xiWjBI8axCbgrFOiHN19Z1SutiX1JHXOGTttPYOCRZEbJ66LEIOylQIvOoaj2HweSisu cl3A==
X-Gm-Message-State: APt69E3wZeVXiaXwVzcU1ExE2o8THjCSu8hc0HoVCyzx1cv8tYrDeDe3 DBwv18RIrZTGl5iYwlE5aKPKB+6zC6pxcfWL5bhBkA==
X-Google-Smtp-Source: AAOMgpc+8gQDENKkLTfv+Rb4mNuKeZR1Jnlt4j5wTxjSEvQFGxMuSDhRcLiTtOLTSEOqbVWvqtXlLUtlfwN4I6zm+tE=
X-Received: by 2002:a19:e40d:: with SMTP id b13-v6mr1566937lfh.141.1530709427461; Wed, 04 Jul 2018 06:03:47 -0700 (PDT)
MIME-Version: 1.0
Sender: mglt.ietf@gmail.com
Received: by 2002:a2e:42cc:0:0:0:0:0 with HTTP; Wed, 4 Jul 2018 06:03:45 -0700 (PDT)
In-Reply-To: <3f3a2835-bb62-5cd4-1466-e89164192473@nttv6.jp>
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> <3f3a2835-bb62-5cd4-1466-e89164192473@nttv6.jp>
From: Daniel Migault <daniel.migault@ericsson.com>
Date: Wed, 04 Jul 2018 09:03:45 -0400
X-Google-Sender-Auth: MYQwo9Mns6KsB9-tzE_SirKVtag
Message-ID: <CADZyTk=-niQJssKUVLiYsw8RFK83vat-yqSJ-m=pVHAdKPQ0Pg@mail.gmail.com>
To: kaname nishizuka <kaname@nttv6.jp>
Cc: "Konda, Tirumaleswar Reddy" <TirumaleswarReddy_Konda@mcafee.com>, Tobias Gondrom <tobias.gondrom@gondrom.org>, Roman Danyliw <rdd@cert.org>, "dots@ietf.org" <dots@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000ada34e05702c0f27"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dots/EdxM1MjAlixKVgjyFdSWqXIAWTw>
Subject: Re: [Dots] WGLC for use cases draft - until July-1.
X-BeenThere: dots@ietf.org
X-Mailman-Version: 2.1.26
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, 04 Jul 2018 13:03:57 -0000
Thanks for the feed backs Kanama. I push the changes on the git repo: https://github.com/dotswg/dots-use-cases/commit/049ae7370c54661b76feba56ddea7f6fc683b0d5 Yours, Daniel On Wed, Jul 4, 2018 at 2:38 AM, kaname nishizuka <kaname@nttv6.jp> wrote: > Hi Daniel, > > I'd like to propose one change and one nit. > > 3.1 > To improve the clarity of our purpose, the > targeted network will be designated as enterprise network, but the > same scenario applies to any downstream network, including > residential network **and cloud hosting network**. > > I'm seeing a lot of DDoS attacks towards cloud type of hosting services. > It would be helpful to include the example, which will not change the > story of this usecase(3.1) > > > Figure 1 to 3 > - Entreprise > + Enterprise > > I support the latest draft. > > thanks, > Kaname > > On 2018/06/27 23:53, Daniel Migault wrote: > > 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 >> <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 >> <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 listDots@ietf.orghttps://www.ietf.org/mailman/listinfo/dots > > > > _______________________________________________ > 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