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 > >
- 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