Re: [Dots] (draft-ietf-dots-signal-filter-control) ACL Stats issue

"Konda, Tirumaleswar Reddy" <TirumaleswarReddy_Konda@McAfee.com> Fri, 26 April 2019 14:01 UTC

Return-Path: <TirumaleswarReddy_Konda@mcafee.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 5B6BE12043F for <dots@ietfa.amsl.com>; Fri, 26 Apr 2019 07:01:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.699
X-Spam-Level:
X-Spam-Status: No, score=0.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, GB_SUMOF=5, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mcafee.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 9LLPfDEuBqK0 for <dots@ietfa.amsl.com>; Fri, 26 Apr 2019 07:01:03 -0700 (PDT)
Received: from DNVWSMAILOUT1.mcafee.com (dnvwsmailout1.mcafee.com [161.69.31.173]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 15E00120480 for <dots@ietf.org>; Fri, 26 Apr 2019 07:01:02 -0700 (PDT)
X-NAI-Header: Modified by McAfee Email Gateway (5500)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mcafee.com; s=s_mcafee; t=1556286879; h=From: To:Subject:Thread-Topic:Thread-Index:Date: Message-ID:References:In-Reply-To:Accept-Language: Content-Language:X-MS-Has-Attach:X-MS-TNEF-Correlator: dlp-product:dlp-version:dlp-reaction:authentication-results: x-originating-ip:x-ms-publictraffictype:x-ms-office365-filtering-correlation-id: x-microsoft-antispam:x-ms-traffictypediagnostic: x-ms-exchange-purlcount:x-microsoft-antispam-prvs: x-forefront-prvs:x-forefront-antispam-report: received-spf:x-ms-exchange-senderadcheck:x-microsoft-antispam-message-info: Content-Type:Content-Transfer-Encoding:MIME-Version: X-MS-Exchange-CrossTenant-Network-Message-Id: X-MS-Exchange-CrossTenant-originalarrivaltime: X-MS-Exchange-CrossTenant-fromentityheader: X-MS-Exchange-CrossTenant-id:X-MS-Exchange-CrossTenant-mailboxtype: X-MS-Exchange-Transport-CrossTenantHeadersStamped: X-OriginatorOrg:X-NAI-Spam-Flag:X-NAI-Spam-Threshold: X-NAI-Spam-Score:X-NAI-Spam-Version; bh=M SsEeC5ZlUQ22wWv2anDCgz6rEvBhLqCypVFCqs2I4 M=; b=S73pGJ/FxggVf6yRcltgMLakvAXCq5QsnIRdR8IPJyBQ yDV625cr7ZAnOp+Km90RE4T8K4hwiLdxJqg3kAVCNZfmhdSlDm nOuuRcnXHDo7zYW9dl4GLOuRbq5L0bbD0+kgAnIdv8HHoWU7HA MKIXxXkKJQJV0Qsslf9duzBmQus=
Received: from DNVEXAPP1N06.corpzone.internalzone.com (unknown [10.44.48.90]) by DNVWSMAILOUT1.mcafee.com with smtp (TLS: TLSv1/SSLv3,256bits,ECDHE-RSA-AES256-SHA384) id 0c21_669a_c15ca4b5_75de_4b46_a07f_ee62de956a44; Fri, 26 Apr 2019 07:54:39 -0600
Received: from DNVEXAPP1N05.corpzone.internalzone.com (10.44.48.89) by DNVEXAPP1N06.corpzone.internalzone.com (10.44.48.90) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Fri, 26 Apr 2019 08:00:33 -0600
Received: from DNVO365EDGE1.corpzone.internalzone.com (10.44.176.66) by DNVEXAPP1N05.corpzone.internalzone.com (10.44.48.89) with Microsoft SMTP Server (TLS) id 15.0.1395.4 via Frontend Transport; Fri, 26 Apr 2019 08:00:33 -0600
Received: from NAM03-DM3-obe.outbound.protection.outlook.com (10.44.176.242) by edge.mcafee.com (10.44.176.66) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Fri, 26 Apr 2019 08:00:31 -0600
Received: from BYAPR16MB2790.namprd16.prod.outlook.com (20.178.233.91) by BYAPR16MB2469.namprd16.prod.outlook.com (20.177.224.12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1835.14; Fri, 26 Apr 2019 14:00:31 +0000
Received: from BYAPR16MB2790.namprd16.prod.outlook.com ([fe80::4873:7200:9e57:9e62]) by BYAPR16MB2790.namprd16.prod.outlook.com ([fe80::4873:7200:9e57:9e62%5]) with mapi id 15.20.1835.010; Fri, 26 Apr 2019 14:00:31 +0000
From: "Konda, Tirumaleswar Reddy" <TirumaleswarReddy_Konda@McAfee.com>
To: "mohamed.boucadair@orange.com" <mohamed.boucadair@orange.com>, Jon Shallow <supjps-ietf@jpshallow.com>, 'kaname nishizuka' <kaname@nttv6.jp>, "dots@ietf.org" <dots@ietf.org>
Thread-Topic: [Dots] (draft-ietf-dots-signal-filter-control) ACL Stats issue
Thread-Index: AdT6ZmI8uG0f606MQBW+/9uvcTWn6QA3ueOAAAD5v4AAAuISAAACLWCwAASh2bAAAFNQMAAALZggAB/gx7AADZnDQAAB9k5gAAGY4eA=
Date: Fri, 26 Apr 2019 14:00:31 +0000
Message-ID: <BYAPR16MB27909F467FFE57F380015E94EA3E0@BYAPR16MB2790.namprd16.prod.outlook.com>
References: <787AE7BB302AE849A7480A190F8B93302EA649B4@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <c3c9614f-908a-c132-cd35-6c627e341f2b@nttv6.jp> <012601d4fb49$3328c000$997a4000$@jpshallow.com> <BYAPR16MB279020119E24ADCB54B339E3EA3D0@BYAPR16MB2790.namprd16.prod.outlook.com> <787AE7BB302AE849A7480A190F8B93302EA6591A@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <BYAPR16MB27903D8D208FA3AC951FDEE4EA3D0@BYAPR16MB2790.namprd16.prod.outlook.com> <787AE7BB302AE849A7480A190F8B93302EA65AD6@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <BYAPR16MB279013E8029BE0294293A333EA3D0@BYAPR16MB2790.namprd16.prod.outlook.com> <787AE7BB302AE849A7480A190F8B93302EA6623D@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <BYAPR16MB2790146175B845622B2EF438EA3E0@BYAPR16MB2790.namprd16.prod.outlook.com> <787AE7BB302AE849A7480A190F8B93302EA6649C@OPEXCAUBMA2.corporate.adroot.infra.ftgroup>
In-Reply-To: <787AE7BB302AE849A7480A190F8B93302EA6649C@OPEXCAUBMA2.corporate.adroot.infra.ftgroup>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
dlp-product: dlpe-windows
dlp-version: 11.2.0.6
dlp-reaction: no-action
authentication-results: spf=none (sender IP is ) smtp.mailfrom=TirumaleswarReddy_Konda@McAfee.com;
x-originating-ip: [49.37.205.191]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 11f3763d-dcd1-4cd8-c3c4-08d6ca4f8bb6
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600141)(711020)(4605104)(2017052603328)(7193020); SRVR:BYAPR16MB2469;
x-ms-traffictypediagnostic: BYAPR16MB2469:
x-ms-exchange-purlcount: 6
x-microsoft-antispam-prvs: <BYAPR16MB246903C06C96C80E6E04D3D1EA3E0@BYAPR16MB2469.namprd16.prod.outlook.com>
x-forefront-prvs: 001968DD50
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(979002)(396003)(366004)(346002)(376002)(136003)(39860400002)(52084003)(53754006)(199004)(51444003)(189003)(32952001)(13464003)(229853002)(2501003)(316002)(99286004)(7696005)(93886005)(66574012)(80792005)(97736004)(110136005)(6436002)(30864003)(86362001)(14454004)(66066001)(72206003)(966005)(5660300002)(11346002)(446003)(52536014)(186003)(53546011)(53946003)(476003)(102836004)(33656002)(26005)(6506007)(8676002)(6246003)(9686003)(6306002)(53936002)(478600001)(71190400001)(7736002)(71200400001)(74316002)(305945005)(66446008)(66946007)(2906002)(76176011)(55016002)(5024004)(3846002)(14444005)(73956011)(76116006)(64756008)(66556008)(66476007)(25786009)(256004)(6116002)(486006)(81156014)(81166006)(8936002)(68736007)(85282002)(579004)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1101; SCL:1; SRVR:BYAPR16MB2469; H:BYAPR16MB2790.namprd16.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1;
received-spf: None (protection.outlook.com: McAfee.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: Z7V1nb6ofiG2tEMp2l3/QwTZA1H8l9fgNzlyxSb0GvCgLIQoAtUv8b2nLqwCfERkorE0oF/iJpYwqHAAAxEBig4ZRWtVsW6MczIHPV65BMIcuLzWU2qRxgBd6Y5IzZTYOY2GT29OZn7NmOTsC42G1B1WbGaoN1qlGLAbVNwkvkQdd9eFudfiWG6danECoLP9bw8mc5YNYe/5+qt8QTR0InHPqlwxMlpN5r7EcSmpWUTyaps29416pKBCmAdX9DM7lhGvaw8OwhtZ3+ickkMYwfgRl37zJM6MuOsn3uqBTVXUl1Z/IXrKOu774MPtl2yQeBKijLeAQN5pSa46RPVb3L1DVHHst2tdBcTIRg6QpAGlT7YWoOS8v6lTk0NUBPvR23PUcb70zY+yWW2UieYoExSi0ZjvLGGMyzxbKg1LVXg=
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 11f3763d-dcd1-4cd8-c3c4-08d6ca4f8bb6
X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Apr 2019 14:00:31.2620 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 4943e38c-6dd4-428c-886d-24932bc2d5de
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR16MB2469
X-OriginatorOrg: mcafee.com
X-NAI-Spam-Flag: NO
X-NAI-Spam-Threshold: 15
X-NAI-Spam-Score: 0
X-NAI-Spam-Version: 2.3.0.9418 : core <6534> : inlines <7062> : streams <1819786> : uri <2837323>
Archived-At: <https://mailarchive.ietf.org/arch/msg/dots/a75iKbw6GRfVw2EMeXWsYIqSb1c>
Subject: Re: [Dots] (draft-ietf-dots-signal-filter-control) ACL Stats issue
X-BeenThere: dots@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." <dots.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dots>, <mailto:dots-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dots/>
List-Post: <mailto:dots@ietf.org>
List-Help: <mailto:dots-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dots>, <mailto:dots-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 26 Apr 2019 14:01:16 -0000

> -----Original Message-----
> From: mohamed.boucadair@orange.com
> <mohamed.boucadair@orange.com>
> Sent: Friday, April 26, 2019 6:38 PM
> To: Konda, Tirumaleswar Reddy
> <TirumaleswarReddy_Konda@McAfee.com>om>; Jon Shallow <supjps-
> ietf@jpshallow.com>gt;; 'kaname nishizuka' <kaname@nttv6.jp>jp>;
> dots@ietf.org
> Subject: RE: [Dots] (draft-ietf-dots-signal-filter-control) ACL Stats issue
> 
> This email originated from outside of the organization. Do not click links or
> open attachments unless you recognize the sender and know the content is
> safe.
> 
> Re-,
> 
> Please see inline.
> 
> Cheers,
> Med
> 
> > -----Message d'origine-----
> > De : Konda, Tirumaleswar Reddy
> > [mailto:TirumaleswarReddy_Konda@McAfee.com]
> > Envoyé : vendredi 26 avril 2019 14:20
> > À : BOUCADAIR Mohamed TGI/OLN; Jon Shallow; 'kaname nishizuka';
> > dots@ietf.org Objet : RE: [Dots]
> > (draft-ietf-dots-signal-filter-control) ACL Stats issue
> >
> > > -----Original Message-----
> > > From: Dots <dots-bounces@ietf.org> On Behalf Of
> > > mohamed.boucadair@orange.com
> > > Sent: Friday, April 26, 2019 11:22 AM
> > > To: Konda, Tirumaleswar Reddy
> > > <TirumaleswarReddy_Konda@McAfee.com>om>; Jon Shallow <supjps-
> > > ietf@jpshallow.com>gt;; 'kaname nishizuka' <kaname@nttv6.jp>jp>;
> > > dots@ietf.org
> > > Subject: Re: [Dots] (draft-ietf-dots-signal-filter-control) ACL
> > > Stats issue
> > >
> > > This email originated from outside of the organization. Do not click
> > > links
> > or
> > > open attachments unless you recognize the sender and know the
> > > content is safe.
> > >
> > > Hi Tiru,
> > >
> > > The question then is: How knowing these stats will help in softening
> > > the impact on the "business of the victim" other than observing that
> > > traffic is being rate-limited (which is already known to the
> > > client)? That information will be made available anyway once the
> > > DOTS data channel is functional
> > again.
> >
> > While the DDOS attack is progress (it may last for few weeks), the ACL
> > stats can help the client learn the scale of the DDoS attack, and can
> > identify alternate mitigation providers capable of handling the attack scale.
> 
> [Med] Wouldn't that be inferred from the aggregate stats returned in the
> signal channel and local observation?

No, the client will not know the amount of traffic dropped by the rate-limit ACL.

> 
> >
> > >
> > > An example to soften such impacts could be: A DOTS client can
> > > manipulate ACLs with different rate-limit policies that it can
> > > activate/deactivate
> > based on
> > > local available information AND/OR status/aggregate stats received
> > > via the signal channel without relying on ACL-specific stats
> > > received from the
> > server.
> >
> > If the server can provide the aggregate stats, it can also provide
> > ACL- specific stats.
> 
> [Med] If it can do so, it can do it also for any ACL.

The other ACLs to permit white-listed traffic or drop black-listed traffic is not impacting legitimate traffic to reach the target. As you already know, rate-limit ACL is different, it is dropping good traffic.

> 
>  ACL-specific stats and mitigation stats will give a clear
> > picture of the traffic rate-limited, bad traffic dropped by the DDoS
> > mitigation system, and using these stats the DOTS client can
> > heuristically determine the amount of legitimate traffic dropped
> > because of rate-limit and the impact of the attack on its service.
> 
> [Med] The impact can be observed locally (e.g., bad QoS, inability to access a
> service, instable connectivity, etc.). I still don’t see how sharing the ACL stats
> will be helpful here.
> 
> A DOTS client can preinstall the same rate-limit filter with but with different
> policies. It can select the appropriate ACL to activate/deactivate based on
> local experience.

I don't get how the local experience will help the client pick an alternate mitigation provider who can handle the attack scale. Imagine the hot customer calls because its services are not available to legitimate users because of rate-limit action, 
the client needs to have a granular visibility (visibility is a critical criteria in MITRE attack framework https://attack.mitre.org/).

Cheers,
-Tiru

> 
> >
> > Cheers,
> > -Tiru
> >
> > >
> > > Cheers,
> > > Med
> > >
> > > > -----Message d'origine-----
> > > > De : Konda, Tirumaleswar Reddy
> > > > [mailto:TirumaleswarReddy_Konda@McAfee.com]
> > > > Envoyé : jeudi 25 avril 2019 16:26 À : BOUCADAIR Mohamed TGI/OLN;
> > > > Jon Shallow; 'kaname nishizuka'; dots@ietf.org Objet : RE: [Dots]
> > > > (draft-ietf-dots-signal-filter-control) ACL Stats issue
> > > >
> > > > > -----Original Message-----
> > > > > From: mohamed.boucadair@orange.com
> > > > > <mohamed.boucadair@orange.com>
> > > > > Sent: Thursday, April 25, 2019 7:48 PM
> > > > > To: Konda, Tirumaleswar Reddy
> > > > > <TirumaleswarReddy_Konda@McAfee.com>om>; Jon Shallow <supjps-
> > > > > ietf@jpshallow.com>gt;; 'kaname nishizuka' <kaname@nttv6.jp>jp>;
> > > > > dots@ietf.org
> > > > > Subject: RE: [Dots] (draft-ietf-dots-signal-filter-control) ACL
> > > > > Stats issue
> > > > >
> > > > >
> > > > >
> > > > > Re-,
> > > > >
> > > > > Why it would be useful to share stats for ACLs activated via the
> > > > > signal
> > > > channel
> > > > > but not for (pre-installed) ACLs that are automatically
> > > > > activated during mitigations ?
> > > >
> > > > The rate-limit ACL activated via the signal channel is a last
> > > > resort employed by the DOTS client to mitigate the volumetric
> > > > attack, it has an adverse effect of blocking not just the attack
> > > > traffic but also legitimate traffic, and potentially impacts the
> > > > business of the victim (e.g. good users cannot leverage its
> > > > service), hence it's stats look more
> > > critical to me.
> > > >
> > > > -Tiru
> > > >
> > > > >
> > > > > Cheers,
> > > > > Med
> > > > >
> > > > > > -----Message d'origine-----
> > > > > > De : Konda, Tirumaleswar Reddy
> > > > > > [mailto:TirumaleswarReddy_Konda@McAfee.com]
> > > > > > Envoyé : jeudi 25 avril 2019 16:13 À : BOUCADAIR Mohamed
> > > > > > TGI/OLN; Jon Shallow; 'kaname nishizuka'; dots@ietf.org Objet
> > > > > > : RE: [Dots]
> > > > > > (draft-ietf-dots-signal-filter-control) ACL Stats issue
> > > > > >
> > > > > > > -----Original Message-----
> > > > > > > From: mohamed.boucadair@orange.com
> > > > > > > <mohamed.boucadair@orange.com>
> > > > > > > Sent: Thursday, April 25, 2019 5:37 PM
> > > > > > > To: Konda, Tirumaleswar Reddy
> > > > > > > <TirumaleswarReddy_Konda@McAfee.com>om>; Jon Shallow
> <supjps-
> > > > > > > ietf@jpshallow.com>gt;; 'kaname nishizuka' <kaname@nttv6.jp>jp>;
> > > > > > > dots@ietf.org
> > > > > > > Subject: RE: [Dots] (draft-ietf-dots-signal-filter-control)
> > > > > > > ACL Stats issue
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > Tiru,
> > > > > > >
> > > > > > > Even if we assume that ACL-specific stats can be
> > > > > > > communicated via the
> > > > > > signal
> > > > > > > channel (which we don't have an agreement on it so far),
> > > > > > > this is not
> > > > > > specific
> > > > > > > to the filter-control spec but the same reasoning would
> > > > > > > apply for all ACLs instructed by the DOTS client (not only
> > > > > > > those that are adjusted during
> > > > > > attack
> > > > > > > times).
> > > > > >
> > > > > > My point is, If the ACL is activated using the signal channel,
> > > > > > since the ACL is part of the mitigation request, only the
> > > > > > activated ACL stats needs to be conveyed in the mitigation status.
> > > > > > Other ACLs activated using data channel are not part of
> > > > > > mitigation request, so no need to convey their stats using the signal
> channel.
> > > > > >
> > > > > > -Tiru
> > > > > >
> > > > > > >
> > > > > > > Cheers,
> > > > > > > Med
> > > > > > >
> > > > > > > > -----Message d'origine----- De : Konda, Tirumaleswar Reddy
> > > > > > > > [mailto:TirumaleswarReddy_Konda@McAfee.com]
> > > > > > > > Envoyé : jeudi 25 avril 2019 13:04 À : Jon Shallow;
> > > > > > > > 'kaname nishizuka'; BOUCADAIR Mohamed TGI/OLN;
> dots@ietf.org Objet :
> > > RE:
> > > > > > > > [Dots]
> > > > > > > > (draft-ietf-dots-signal-filter-control) ACL Stats issue
> > > > > > > >
> > > > > > > > > -----Original Message-----
> > > > > > > > > From: Dots <dots-bounces@ietf.org> On Behalf Of Jon
> > > > > > > > > Shallow
> > > > > > > > > Sent: Thursday, April 25, 2019 2:58 PM
> > > > > > > > > To: 'kaname nishizuka' <kaname@nttv6.jp>jp>;
> > > > > > > > > mohamed.boucadair@orange.com; dots@ietf.org
> > > > > > > > > Subject: Re: [Dots]
> > > > > > > > > (draft-ietf-dots-signal-filter-control)
> > > > > > > > > ACL Stats issue
> > > > > > > > >
> > > > > > > > > This email originated from outside of the organization.
> > > > > > > > > Do not click links
> > > > > > > > or
> > > > > > > > > open attachments unless you recognize the sender and
> > > > > > > > > know the content is safe.
> > > > > > > > >
> > > > > > > > > Hi there,
> > > > > > > > >
> > > > > > > > > The advantage of separating out the counters for the
> > > > > > > > > different ACLs is that the DOTS client can then
> > > > > > > > > determine what is being effective or
> > > > > > not.
> > > > > > > > However,
> > > > > > > > > if (signal) data is able to get from the DOTS server to
> > > > > > > > > the DOTS client,
> > > > > > > > then it
> > > > > > > > > is likely that the data channel will still be operable
> > > > > > > > > and can be used to
> > > > > > > > get
> > > > > > > > > these numbers so I still do not think that this should
> > > > > > > > > be over the signal channel.
> > > > > > > > >
> > > > > > > > > I think that that the GET response (or observe response)
> > > > > > > > > bytes-dropped
> > > > > > > etc.
> > > > > > > > > should be the total dropped - i.e. the sum of the ACls
> > > > > > > > > and what the DMS is otherwise doing as it refers to the
> > > > > > > > > mitigation
> > > request.
> > > > > > > >
> > > > > > > > If the DOTS server knows the traffic dropped by ACLs and
> > > > > > > > the traffic dropped by DMS, why can't it provide this
> > > > > > > > statistics separately instead of summing it.  If the
> > > > > > > > incoming link is saturated, data channel will not function
> > > > > > > > but signal channel (using UDP) will work and there is a
> > > > > > > > good possibility that one of the GET responses
> > > > > > > > periodically sent will reach the client (As you already
> > > > > > > > know, DOTS signal
> > > > > > > channel is tolerant to high packet loss in one direction).
> > > > > > > >
> > > > > > > > -Tiru
> > > > > > > >
> > > > > > > > >
> > > > > > > > > Regards
> > > > > > > > >
> > > > > > > > > Jon
> > > > > > > > >
> > > > > > > > > > -----Original Message-----
> > > > > > > > > > From: Dots [mailto: dots-bounces@ietf.org] On Behalf
> > > > > > > > > > Of kaname nishizuka
> > > > > > > > > > Sent: 25 April 2019 10:00
> > > > > > > > > > To: mohamed.boucadair@orange.com; dots@ietf.org
> > > > > > > > > > Subject: Re: [Dots]
> > > > > > > > > > (draft-ietf-dots-signal-filter-control)
> > > > > > > > > > ACL Stats issue
> > > > > > > > > >
> > > > > > > > > > Hi Med, all,
> > > > > > > > > >
> > > > > > > > > > Regarding with the issue, I'm not convinced of the
> > > > > > > > > > benefit to return the activated ACL statistics over signal-
> channel.
> > > > > > > > > >
> > > > > > > > > > The idea of this draft is based on this situation
> > > > > > > > > > (quoted from Jon's
> > > > > > > > > > comment):
> > > > > > > > > > (It is) very unreliable when the inbound pipe is
> > > > > > > > > > running
> > full.
> > > > > > > > > > If the pipe is not running full, then this information
> > > > > > > > > > can be obtained over the
> > > > > > > > data
> > > > > > > > > channel.
> > > > > > > > > >
> > > > > > > > > > ACL stats can be get over the data-channel. I don't
> > > > > > > > > > see any reason to reproduce the same function.
> > > > > > > > > >
> > > > > > > > > > Further more, I don't think the DOTS server should
> > > > > > > > > > notify that DOTS client with the change by including
> > > > > > > > > > the corresponding
> > > > > > > > > > acl-* parameters in an asynchronous notification.
> > > > > > > > > > The basic behavior is already written in the draft:
> > > > > > > > > >     This specification does not require any
> > > > > > > > > > modification to the
> > > > > > efficacy
> > > > > > > > > >     update and the withdrawal procedures defined in
> > > > > > > > > >     [I-D.ietf-dots-signal-channel].  In particular,
> > > > > > > > > > ACL-related
> > > > > > clauses
> > > > > > > > > >     are not included in a PUT request used to send an
> > > > > > > > > > efficacy update
> > > > > > and
> > > > > > > > > >     DELETE requests.
> > > > > > > > > >
> > > > > > > > > > If so, the server need not to store any resource about
> > > > > > > > > > acl-* per mitigation request, which make the function
> > > > > > > > > > of the signal-filter-control
> > > > > > > > > simple enough.
> > > > > > > > > >
> > > > > > > > > > thanks,
> > > > > > > > > > Kaname
> > > > > > > > > >
> > > > > > > > > > On 2019/04/24 15:24, mohamed.boucadair@orange.com
> wrote:
> > > > > > > > > > > Hi all,
> > > > > > > > > > >
> > > > > > > > > > > We do have one pending issue to be resolved for this draft.
> > > > > > > > > > > The issue is
> > > > > > > > > > available at:
> > > > > > > > > > > https://github.com/boucadair/filter-control/issues/1
> > > > > > > > > > >
> > > > > > > > > > > We need your feedback on this.
> > > > > > > > > > >
> > > > > > > > > > > Cheers,
> > > > > > > > > > > Med
> > > > > > > > > > >
> > > > > > > > > > >> -----Message d'origine----- De : Dots
> > > > > > > > > > >> [mailto:dots-bounces@ietf.org] De la part de
> > > > > > > > > > >> internet- drafts@ietf.org Envoyé : mercredi 24
> > > > > > > > > > >> avril
> > > > > > > > > > >> 2019
> > > > > > > > > > >> 07:34 À
> > > > > > :
> > > > > > > > > > >> i-d-announce@ietf.org Cc : dots@ietf.org Objet :
> > > > > > > > > > >> [Dots] I-D
> > > > > > Action:
> > > > > > > > > > >> draft-ietf-dots-signal-filter-control-00.txt
> > > > > > > > > > >>
> > > > > > > > > > >>
> > > > > > > > > > >> A New Internet-Draft is available from the on-line
> > > > > > > > > > >> Internet-Drafts directories.
> > > > > > > > > > >> This draft is a work item of the DDoS Open Threat
> > > > > > > > > > >> Signaling WG of the
> > > > > > > > > > IETF.
> > > > > > > > > > >>
> > > > > > > > > > >>          Title           : Controlling Filtering Rules
> > Using
> > > > > > > > Distributed
> > > > > > > > > > >> Denial-of-Service Open Threat Signaling (DOTS)
> > > > > > > > > > >> Signal
> > > Channel
> > > > > > > > > > >>          Authors         : Kaname Nishizuka
> > > > > > > > > > >>                            Mohamed Boucadair
> > > > > > > > > > >>                            Tirumaleswar Reddy
> > > > > > > > > > >>                            Takahiko Nagata
> > > > > > > > > > >> 	Filename        : draft-ietf-dots-signal-filter-
> > control-
> > > > 00.txt
> > > > > > > > > > >> 	Pages           : 23
> > > > > > > > > > >> 	Date            : 2019-04-23
> > > > > > > > > > >>
> > > > > > > > > > >> Abstract:
> > > > > > > > > > >>     This document specifies an extension to the
> > > > > > > > > > >> DOTS signal
> > > > > > channel
> > > > > > > so
> > > > > > > > > > >>     that DOTS clients can control their filtering
> > > > > > > > > > >> rules when an
> > > > > > attack
> > > > > > > > > > >>     mitigation is active.
> > > > > > > > > > >>
> > > > > > > > > > >>     Particularly, this extension allows a DOTS
> > > > > > > > > > >> client to activate or
> > > > > > > > de-
> > > > > > > > > > >>     activate existing filtering rules during a DDoS
> > attack.
> > > > The
> > > > > > > > > > >>     characterization of these filtering rules is
> > > > > > > > > > >> supposed to be
> > > > > > > > conveyed
> > > > > > > > > > >>     by a DOTS client during an idle time by means
> > > > > > > > > > >> of the DOTS
> > > > data
> > > > > > > > > > >>     channel protocol.
> > > > > > > > > > >>
> > > > > > > > > > >> Editorial Note (To be removed by RFC Editor)
> > > > > > > > > > >>
> > > > > > > > > > >>     Please update these statements within the
> > > > > > > > > > >> document with the
> > > > > > > RFC
> > > > > > > > > > >>     number to be assigned to this document:
> > > > > > > > > > >>
> > > > > > > > > > >>     o  "This version of this YANG module is part of
> > > > > > > > > > >> RFC
> > XXXX;"
> > > > > > > > > > >>
> > > > > > > > > > >>     o  "RFC XXXX: Controlling Filtering Rules Using
> > > > > > > > > > >> Distributed
> > > > > > > > Denial-
> > > > > > > > > > >>        of-Service Open Threat Signaling (DOTS)
> > > > > > > > > > >> Signal Channel";
> > > > > > > > > > >>
> > > > > > > > > > >>     o  reference: RFC XXXX
> > > > > > > > > > >>
> > > > > > > > > > >>     o  [RFCXXXX]
> > > > > > > > > > >>
> > > > > > > > > > >>     Please update these statements with the RFC
> > > > > > > > > > >> number to be assigned
> > > > > > > > > to
> > > > > > > > > > >>     the following documents:
> > > > > > > > > > >>
> > > > > > > > > > >>     o  "RFC SSSS: Distributed Denial-of-Service
> > > > > > > > > > >> Open Threat
> > > > > > Signaling
> > > > > > > > > > >>        (DOTS) Signal Channel Specification" (used to be
> > > > > > > > > > >>        [I-D.ietf-dots-signal-channel])
> > > > > > > > > > >>
> > > > > > > > > > >>     o  "RFC DDDD: Distributed Denial-of-Service
> > > > > > > > > > >> Open Threat
> > > > > > Signaling
> > > > > > > > > > >>        (DOTS) Data Channel Specification" (used to be
> > > > > > > > > > >>        [I-D.ietf-dots-data-channel])
> > > > > > > > > > >>
> > > > > > > > > > >>     Please update the "revision" date of the YANG module.
> > > > > > > > > > >>
> > > > > > > > > > >>
> > > > > > > > > > >> The IETF datatracker status page for this draft is:
> > > > > > > > > > >> https://datatracker.ietf.org/doc/draft-ietf-dots-si
> > > > > > > > > > >> gnal
> > > > > > > > > > >> -fil
> > > > > > > > > > >> ter-
> > > > > > > > > > >> cont
> > > > > > > > > > >> rol/
> > > > > > > > > > >>
> > > > > > > > > > >> There are also htmlized versions available at:
> > > > > > > > > > >> https://tools.ietf.org/html/draft-ietf-dots-signal-
> > > > > > > > > > >> filt
> > > > > > > > > > >> er-c
> > > > > > > > > > >> ontr
> > > > > > > > > > >> ol-0
> > > > > > > > > > >> 0
> > > > > > > > > > >> https://datatracker.ietf.org/doc/html/draft-ietf-do
> > > > > > > > > > >> ts-s
> > > > > > > > > > >> igna
> > > > > > > > > > >> l-fi
> > > > > > > > > > >> lter
> > > > > > > > > > >> -control-
> > > > > > > > > > >> 00
> > > > > > > > > > >>
> > > > > > > > > > >>
> > > > > > > > > > >> Please note that it may take a couple of minutes
> > > > > > > > > > >> from the time of
> > > > > > > > > > submission
> > > > > > > > > > >> until the htmlized version and diff are available
> > > > > > > > > > >> at
> > > > > > tools.ietf.org.
> > > > > > > > > > >>
> > > > > > > > > > >> Internet-Drafts are also available by anonymous FTP at:
> > > > > > > > > > >> ftp://ftp.ietf.org/internet-drafts/
> > > > > > > > > > >>
> > > > > > > > > > >>
> > > _______________________________________________
> > > > > > > > > > >> 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