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

"Konda, Tirumaleswar Reddy" <TirumaleswarReddy_Konda@McAfee.com> Thu, 25 April 2019 11:04 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 52DEA120071 for <dots@ietfa.amsl.com>; Thu, 25 Apr 2019 04:04:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.698
X-Spam-Level:
X-Spam-Status: No, score=0.698 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] 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 3NMmIBHWtaqM for <dots@ietfa.amsl.com>; Thu, 25 Apr 2019 04:04:10 -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 4851E12004D for <dots@ietf.org>; Thu, 25 Apr 2019 04:04:10 -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=1556189884; 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=l 0x3fb1VvjIc7Boqi+C0nYJ3pyaJgZarFGEWR1s5lp A=; b=GKcfMyzLuXGRVFOyYKg0PYUobE+VuOLpiqxboudt7I3C +RUlYwtc4Z17+ZaTsW3pXftaVzzYzsakGLi7TlAC602hBId/QR 82iciLExboiUxJnB8+6yiXbFGdlRISzsqydlKk0MWwi301Ufoq UEei7va7vRJwGg4j2cPDZm43yoY=
Received: from DNVEXAPP1N05.corpzone.internalzone.com (unknown [10.44.48.89]) by DNVWSMAILOUT1.mcafee.com with smtp (TLS: TLSv1/SSLv3,256bits,ECDHE-RSA-AES256-SHA384) id 46f9_c441_1d9298a9_2330_4655_89be_51a960afcd9c; Thu, 25 Apr 2019 04:58:03 -0600
Received: from DNVEXAPP1N04.corpzone.internalzone.com (10.44.48.88) by DNVEXAPP1N05.corpzone.internalzone.com (10.44.48.89) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Thu, 25 Apr 2019 05:03:43 -0600
Received: from DNVO365EDGE1.corpzone.internalzone.com (10.44.176.66) by DNVEXAPP1N04.corpzone.internalzone.com (10.44.48.88) with Microsoft SMTP Server (TLS) id 15.0.1395.4 via Frontend Transport; Thu, 25 Apr 2019 05:03:42 -0600
Received: from NAM05-CO1-obe.outbound.protection.outlook.com (10.44.176.241) by edge.mcafee.com (10.44.176.66) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Thu, 25 Apr 2019 05:03:34 -0600
Received: from BYAPR16MB2790.namprd16.prod.outlook.com (20.178.233.91) by BYAPR16MB2422.namprd16.prod.outlook.com (20.177.225.148) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1813.14; Thu, 25 Apr 2019 11:03:34 +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.1813.017; Thu, 25 Apr 2019 11:03:34 +0000
From: "Konda, Tirumaleswar Reddy" <TirumaleswarReddy_Konda@McAfee.com>
To: Jon Shallow <supjps-ietf@jpshallow.com>, 'kaname nishizuka' <kaname@nttv6.jp>, "mohamed.boucadair@orange.com" <mohamed.boucadair@orange.com>, "dots@ietf.org" <dots@ietf.org>
Thread-Topic: [Dots] (draft-ietf-dots-signal-filter-control) ACL Stats issue
Thread-Index: AdT6ZmI8uG0f606MQBW+/9uvcTWn6QA3ueOAAAD5v4AAAuISAA==
Date: Thu, 25 Apr 2019 11:03:34 +0000
Message-ID: <BYAPR16MB279020119E24ADCB54B339E3EA3D0@BYAPR16MB2790.namprd16.prod.outlook.com>
References: <787AE7BB302AE849A7480A190F8B93302EA649B4@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <c3c9614f-908a-c132-cd35-6c627e341f2b@nttv6.jp> <012601d4fb49$3328c000$997a4000$@jpshallow.com>
In-Reply-To: <012601d4fb49$3328c000$997a4000$@jpshallow.com>
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: [103.245.47.20]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 9a6eeacf-7220-4a82-9fb0-08d6c96da92c
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600141)(711020)(4605104)(2017052603328)(7193020); SRVR:BYAPR16MB2422;
x-ms-traffictypediagnostic: BYAPR16MB2422:
x-ms-exchange-purlcount: 5
x-microsoft-antispam-prvs: <BYAPR16MB242242A2777886B50A35A65EEA3D0@BYAPR16MB2422.namprd16.prod.outlook.com>
x-forefront-prvs: 0018A2705B
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(366004)(396003)(136003)(39850400004)(346002)(376002)(32952001)(199004)(189003)(53754006)(51444003)(13464003)(2201001)(76176011)(6306002)(66066001)(55016002)(5660300002)(256004)(229853002)(76116006)(2501003)(9686003)(53936002)(66476007)(11346002)(6246003)(14454004)(71200400001)(73956011)(71190400001)(64756008)(5024004)(66556008)(66574012)(25786009)(66946007)(52536014)(476003)(14444005)(966005)(446003)(66446008)(26005)(81156014)(86362001)(478600001)(186003)(53546011)(81166006)(7696005)(68736007)(486006)(6436002)(102836004)(74316002)(7736002)(305945005)(72206003)(2906002)(316002)(33656002)(97736004)(6506007)(110136005)(8936002)(99286004)(6116002)(3846002)(8676002)(80792005)(85282002); DIR:OUT; SFP:1101; SCL:1; SRVR:BYAPR16MB2422; 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: SjQXe4YVR66o4FLYEd/snIbrMaFG33LoWpjQPwe1rv9fYlWP6j9Y5Yl9rkbGk0ZxtbBw/XKF/JssiS+E4AjXpXSU+Zd89KNKdT4/tKnpRNOwUO12Ly98NtaOg42jhPLsk70Tb1qzq5gUNG6HIFP5rR/gGf7aaEMr7y7tCqz4Z/+gm/xVf8e4Lgj14r+gBWYcSl4Szn4pvbyemTR/RfHcrbXNfh18H53rnjSUeDqFqnitE59Kryfq78S0zWs0O1bIyk2P7YTX7fjGzswIkxYl7fea69eM79G9e9ibbyivuLYuR8+FRbO7HC7dYpnUpb7yYNQWkW1wMbbuvRIrE8Gxa5Wus4P+nkhpXh5/qjG1MKYF/GdlZ0xRFkmvNJL5BOB/m1OYsXKUlBigLE6o4tA6/zNrAE/eNFR2pSNF4sti7Wc=
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 9a6eeacf-7220-4a82-9fb0-08d6c96da92c
X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Apr 2019 11:03:34.4784 (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: BYAPR16MB2422
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 <6532> : inlines <7059> : streams <1819679> : uri <2836867>
Archived-At: <https://mailarchive.ietf.org/arch/msg/dots/M783BNFX_M6gcMuQDKhDOdPc_pI>
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: Thu, 25 Apr 2019 11:04:13 -0000

> -----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-signal-filter-cont
> > >> rol/
> > >>
> > >> There are also htmlized versions available at:
> > >> https://tools.ietf.org/html/draft-ietf-dots-signal-filter-control-0
> > >> 0
> > >> https://datatracker.ietf.org/doc/html/draft-ietf-dots-signal-filter
> > >> -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