Re: [Dots] Signal / Data / Alias / Filter Implementation

"Konda, Tirumaleswar Reddy" <TirumaleswarReddy_Konda@McAfee.com> Thu, 03 August 2017 13:22 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 34921131FC7 for <dots@ietfa.amsl.com>; Thu, 3 Aug 2017 06:22:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.211
X-Spam-Level:
X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mcafee.onmicrosoft.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 563QD96maYKD for <dots@ietfa.amsl.com>; Thu, 3 Aug 2017 06:22:08 -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 01B28131687 for <dots@ietf.org>; Thu, 3 Aug 2017 06:22:07 -0700 (PDT)
Received: from MIVEXAPP1N03.corpzone.internalzone.com (unknown [10.48.48.90]) by DNVWSMAILOUT1.mcafee.com with smtp id 0fc3_6093_1e4fba29_2bff_438f_a50a_14b2ae7ab3de; Thu, 03 Aug 2017 08:21:57 -0500
Received: from MIVEXUSR1N07.corpzone.internalzone.com (10.48.48.87) by MIVEXAPP1N03.corpzone.internalzone.com (10.48.48.90) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Thu, 3 Aug 2017 09:21:55 -0400
Received: from MIVO365EDGE4.corpzone.internalzone.com (10.48.176.87) by MIVEXUSR1N07.corpzone.internalzone.com (10.48.48.87) with Microsoft SMTP Server (TLS) id 15.0.1263.5 via Frontend Transport; Thu, 3 Aug 2017 09:21:55 -0400
Received: from NAM02-BL2-obe.outbound.protection.outlook.com (10.48.176.241) by edge.mcafee.com (10.48.176.87) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Thu, 3 Aug 2017 09:21:54 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mcafee.onmicrosoft.com; s=selector1-mcafee-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=mZiLASLUjhju2vNnxVhU1w74+PshzYk4dNEqpLDj7Ns=; b=qSJ7DGKyelmkkNZupZlXBZjnPxDQZa7s6vgpjWEZoDXnZOKpbFvNEAJsYymBfEXT1EydusR1putVEOmuXgkqV1Iwap3Jn4GAgHskQ0mPwHhQp450vUKz7gl1SS9kHo4P7RsI8gpVx5LXi0tqk4Tg6b2TABF2/UcplyECJBnRUfI=
Received: from DM5PR16MB1788.namprd16.prod.outlook.com (10.172.44.144) by DM5PR16MB1787.namprd16.prod.outlook.com (10.172.44.143) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.1.1304.22; Thu, 3 Aug 2017 13:21:53 +0000
Received: from DM5PR16MB1788.namprd16.prod.outlook.com ([10.172.44.144]) by DM5PR16MB1788.namprd16.prod.outlook.com ([10.172.44.144]) with mapi id 15.01.1304.023; Thu, 3 Aug 2017 13:21:53 +0000
From: "Konda, Tirumaleswar Reddy" <TirumaleswarReddy_Konda@McAfee.com>
To: kaname nishizuka <kaname@nttv6.jp>, Jon Shallow <supjps-ietf@jpshallow.com>, "dots@ietf.org" <dots@ietf.org>
Thread-Topic: [Dots] Signal / Data / Alias / Filter Implementation
Thread-Index: AdMLd/i8iwFwzTfWQ/S7HayGj5igcAABJg8AAAm7eQAABmLPgAAW0FyAAAVyJ4AABOtMAAAFoj7A
Date: Thu, 03 Aug 2017 13:21:52 +0000
Message-ID: <DM5PR16MB1788F25710A5DDC11C3A733AEAB10@DM5PR16MB1788.namprd16.prod.outlook.com>
References: <035401d30b77$fb3a1da0$f1ae58e0$@jpshallow.com> <628E4313-95D3-42F5-9DDB-00C7B4EBB4D6@arbor.net> <039001d30ba3$7f4290c0$7dc7b240$@jpshallow.com> <B8BBF80E-5A5B-473D-A0B2-B6EFEC21DEBF@arbor.net> <4a158137-5c92-974e-3e4d-6c46fb3e5a52@nttv6.jp> <040101d30c2e$14440f70$3ccc2e50$@jpshallow.com> <80a371a0-9968-d259-7fca-0765d10a1a10@nttv6.jp>
In-Reply-To: <80a371a0-9968-d259-7fca-0765d10a1a10@nttv6.jp>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=TirumaleswarReddy_Konda@McAfee.com;
x-originating-ip: [161.69.192.123]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; DM5PR16MB1787; 7:iZdKjF+kEuAD8I20qJcLh/SOKEjhqvqX2t6oA5ppwv7Iv8XQtEUx8zMu3NDbYJiHAWQ9fNwcMPZyPSlb/o3+IoOq0k+ZIwz6P5jaVksyAtgjSucdqKner7Hevm4BvEPbMk0yKu+pY3qDsrRwXcrar5hltbttiePGm+WmNsnxsoJipoxLJMLxTDYQoWmGZ971cSXYvnf5x5hpv9Yd9V5jNERaOOI5I8NjTMcIvRyAY3u93AbDeKK5lmwFqdvfz6qiR32lNX5B3p+/RQHSFJ5whjOfKCRK17QcnjHBLoK3ogUzxaHdowwwIUXsIG8kWy9F3GAEOlAtWhkQ3cU3dZ8Nq0egOCiLRD9vL0eBhlS2Thupors0wUbY31MGKgfs2GH/btc328VUKglWYj/cmPbc/SymJQmWnDQmfg44MEmUSxcoe0nDi9qJPpRYJY8PgpqcrHQU0yfzO1DeUu3J/NQGhYvZshOCDCpsFnTO4A3Flleo4PRrT+i5ls6vSifBpo8gFBo8HhII+UIvDOtURoZGoBYAKEqPD14f0HK3MJ+USo/d2j33CxgtFIckAfyMzdoJV2hsUrSm9c6Buv4VNqcPnT7I+ATzcrjHLDqs8pdUXiotMcVaUyjXDde85GPZ1tb71Omp9b/IsTVdyT2AqvrqxEiXi+N39wlKW0C73MsjEIFgHa6qIjWqTFuOO317wQayRYIiHvfYxB3jzIw3O8nNviPXpjMKvuvugL7TZaNXXrMItFIlGTeyxI+XZIn6VkpjC4Z+1KkZRos5ntxC3tTPP5zpz1utGzWS+bCKTnSoJ3Y=
x-ms-office365-filtering-correlation-id: e586d47e-3085-428b-0137-08d4da729b40
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254152)(300000503095)(300135400095)(2017052603031)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:DM5PR16MB1787;
x-ms-traffictypediagnostic: DM5PR16MB1787:
x-exchange-antispam-report-test: UriScan:(158342451672863)(278428928389397)(21748063052155);
x-microsoft-antispam-prvs: <DM5PR16MB1787A8BDEFE134CC72CD68A0EAB10@DM5PR16MB1787.namprd16.prod.outlook.com>
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(8121501046)(5005006)(10201501046)(100000703101)(100105400095)(93006095)(93001095)(3002001)(6041248)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123555025)(20161123562025)(20161123564025)(20161123558100)(20161123560025)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:DM5PR16MB1787; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:DM5PR16MB1787;
x-forefront-prvs: 03883BD916
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39850400002)(39450400003)(39840400002)(39410400002)(39400400002)(51914003)(189002)(199003)(32952001)(377454003)(24454002)(5660300001)(102836003)(3846002)(790700001)(86362001)(81156014)(8676002)(81166006)(33656002)(6506006)(966005)(7696004)(14454004)(105586002)(6436002)(478600001)(106356001)(6116002)(189998001)(2950100002)(77096006)(2501003)(2906002)(8936002)(7736002)(66066001)(72206003)(93886004)(25786009)(50986999)(54356999)(9686003)(76176999)(80792005)(99286003)(53936002)(606006)(55016002)(229853002)(6306002)(54896002)(53546010)(3660700001)(236005)(74316002)(101416001)(38730400002)(3280700002)(97736004)(6246003)(2900100001)(68736007)(85282002); DIR:OUT; SFP:1101; SCL:1; SRVR:DM5PR16MB1787; H:DM5PR16MB1788.namprd16.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:3; A:1; LANG:en;
received-spf: None (protection.outlook.com: McAfee.com does not designate permitted sender hosts)
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_DM5PR16MB1788F25710A5DDC11C3A733AEAB10DM5PR16MB1788namp_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Aug 2017 13:21:53.0622 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 4943e38c-6dd4-428c-886d-24932bc2d5de
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR16MB1787
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 <6086> : inlines <6005> : streams <1756990> : uri <2475541>
Archived-At: <https://mailarchive.ietf.org/arch/msg/dots/EVOxazJI4esDO4ZsOxiG0qq6XPw>
Subject: Re: [Dots] Signal / Data / Alias / Filter Implementation
X-BeenThere: dots@ietf.org
X-Mailman-Version: 2.1.22
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, 03 Aug 2017 13:22:11 -0000

Updated parameter names to be consistent b/w ietf-dots-signal and ietf-dots-data-channel in my local copy.

Added the following line to clarify the use of alias:
If the mitigation request contains both alias and other parameters identifying the target resource (such as, target-ip, target-prefix, fqdn, uri) then the DOTS server appends the parameter values in alias with the corresponding parameter values in target-ip, target-prefix, fqdn, uri parameters.

-Tiru
From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of kaname nishizuka
Sent: Thursday, August 3, 2017 3:48 PM
To: Jon Shallow <supjps-ietf@jpshallow.com>; dots@ietf.org
Subject: Re: [Dots] Signal / Data / Alias / Filter Implementation

Hi Jon,

On 2017/08/03 16:56, Jon Shallow wrote:
Hi Kaname,

So as I read this, you are either extending the ietf-dot-signal definition to include source-* (and icmp, fragmentation and possibly rate-limiting) information or you are using Filters over the data channel (which is what Tiru is referring to).  If it is an extension to ietf-dot-signal, then this needs to be formalised for interoperability between different suppliers.
The latter is my intention.  I'll check whether the alias mechanism which couples the data-channel and signal-channel works well.


Similarly, ietf-dots-data-channel-identifier needs to be extended – but I do think the naming (e.g. target-ip instead of just ip) needs to be consistent between ietf-dot-signal and ietf-dots-data-channel-identifier.
+1.
a consistency of naming is important for readers.

thanks,
Kaname


“5.3.1” of draft-ietf-dots-signal-channel would also need to reflect the ietf-dot-signal change. “6.” and “10.1.2” of draft-ietf-dots-signal-channel would also need CBOR to be updated with source-* etc. definitions.

I am of the firm opinion that destination-ip is REQUIRED and MUST be within the mitigation scope of the DOTS Client to prevent taking out someone else’s IP.  This is true for ietf-dot-signal, ietf-dots-data-channel-identifier and ietf-dots-access-control-list.

I do not think fragmentation represented as port=0 is sufficient (and is not necessarily intuitive – it could be read as just take out the subsequent packets of a fragmented sequence if the layer 4 header is not there and hence no port). I think it should have its own ietf-dot-signal definition.

It is unclear to me the usage of alias in the ietf-dot-signal – is it the DOTS client uses just  the alias when requesting mitigation, or if extra parameters are provided (e.g. alias plus target-port-range) are the extra parameters a replacement or in addition to what is in the ietf-dots-data-channel-identifier or are the extra parameters ignored altogether?

Regards

Jon

From: Dots [mailto: dots-bounces@ietf.org<mailto:dots-bounces@ietf.org>] On Behalf Of kaname nishizuka
Sent: 03 August 2017 06:21
To: Dobbins, Roland; Jon Shallow
Cc: dots@ietf.org<mailto:dots@ietf.org>
Subject: Re: [Dots] Signal / Data / Alias / Filter Implementation

Hi Jon,

I'm implementing the DOTS protocol based on current specifications.
The DOTS protocol can handle source-* information in a mitigation signal request.
For example, the DOTS server can enable BGP Flowspec from 5-tuple information derived from mitigation request message from DOTS client, that is actually we are planning to add to our software.
Destination information is used to validate whether the mitigation-scope is really the property of the DOTS client's organization or not.
So, if the request is only including source-* information, how to validate the request is another problem because it can cause unintended side effect to other customers/services (but could be implementation specific)

* How do we handle specific ICMP types  in a mitigation signal request?

Tiru wrote:
> Thanks for the review. Fixed comments 1 and 2 in my local copy. To support filtering rules based on ICMP type and code, and filtering based on fragments, the base ACL model defined in https://tools.ietf.org/html/draft-ietf-netmod-acl-model-06 needs to be extended in this draft using augmentation (see https://tools.ietf.org/html/rfc6020#section-4.2.8).
> I will extend the ACL YANG model in the next revision.

And the latest version of draft-ietf-netmod-acl-model (-11) includes ICMP-ACL (type, code,,)
I think we should update the draft.

* How do we handle fragmentation in a mitigation signal request?
fragmentation can be represented as port=0. Is this a sufficient representation?

thanks,
Kaname



On 2017/08/03 3:27, Dobbins, Roland wrote:

On Aug 2, 2017, at 22:25, Jon Shallow <supjps-ietf@jpshallow.com<mailto:supjps-ietf@jpshallow.com>> wrote:
In draft-ietf-dots-use-cases-07
3.1.6.  End-customer operating a CPE network infrastructure device with
       an integrated DOTS client

3.1.6 from idraft-ietf-dots-use-cases-07 in full:



3.1.6.  End-customer operating a CPE network infrastructure device with

        an integrated DOTS client



   Similar to the above use-case featuring applications or services with

   built-in DDoS attack detection/classification and DOTS client

   capabilities, in this scenario, an end-customer network

   infrastructure CPE device such as a router, layer-3 switch, firewall,

   or load-balance incorporates both the functionality required to

   detect and classify incoming DDoS attacks as well as DOTS client

   functionality.



   The subsequent DOTS communications dialogue and resultant DDoS

   mitigation initiation and termination activities take place in the

   same manner as the use-cases described above.

-----------------------------------

Roland Dobbins <rdobbins@arbor.net<mailto:rdobbins@arbor.net>>





_______________________________________________

Dots mailing list

Dots@ietf.org<mailto:Dots@ietf.org>

https://www.ietf.org/mailman/listinfo/dots





_______________________________________________

Dots mailing list

Dots@ietf.org<mailto:Dots@ietf.org>

https://www.ietf.org/mailman/listinfo/dots