From nobody Wed Nov 1 04:37:11 2017 Return-Path: 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 E1EC313F6BB for ; Wed, 1 Nov 2017 04:37:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 rU1GrSQvMtyl for ; Wed, 1 Nov 2017 04:37:08 -0700 (PDT) Received: from mail.jpshallow.com (mail.jpshallow.com [217.40.240.153]) (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 D80F013F585 for ; Wed, 1 Nov 2017 04:37:07 -0700 (PDT) Received: from [127.0.0.1] (helo=N01332) by mail.jpshallow.com with smtps (TLSv1:ECDHE-RSA-AES256-SHA:256) (Exim 4.89) (envelope-from ) id 1e9rKT-0006OI-3E; Wed, 01 Nov 2017 11:37:05 +0000 From: "Jon Shallow" To: "Roland Dobbins" , References: <150888203847.25249.11590483174597116578@ietfa.amsl.com> <97BBC935-0E42-47B4-8678-02354E7454B7@arbor.net> In-Reply-To: Date: Wed, 1 Nov 2017 11:37:06 -0000 Message-ID: <050f01d35305$beb214c0$3c163e40$@jpshallow.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0510_01D35305.BEB2FF20" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQLKwQB5m+fHCSaK/NwJJP2P3e7/oQIQQtkTAgJfU6eg7/MbYA== Content-Language: en-gb Archived-At: Subject: Re: [Dots] I-D Action: draft-ietf-dots-use-cases-08.txt 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Nov 2017 11:37:10 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0510_01D35305.BEB2FF20 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable A Nit =E2=80=93 the following does not parse =E2=80=93 delete first = =E2=80=98or=E2=80=99 =20 3.2.2 =E2=80=9C When the CPE suspects an attack, it notifies automatically or = the ISP. The contact address of the DDoS Mitigation service of the ISP may be hard coded or may be configured manually or automatically (e.g., eventually the DHCP server may provide the DDoS mitigation service via specific DHCP options).=E2=80=9D =20 Regards =20 Jon =20 From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of Daniel Migault Sent: 01 November 2017 01:29 To: Roland Dobbins Cc: dots@ietf.org Subject: Re: [Dots] I-D Action: draft-ietf-dots-use-cases-08.txt =20 Hi,=20 Thanks Roland for posting 08. I have a few comments Use case from section 3.1.1 to 3.1.4 seems to me very similar, thus I = am wondering if it would not make sense to have them in one section.=20 Nit: When an attack is detected, an automated or manual DOTS mitigation = request is be generated. I believe "be" should be removed. section 3.1.{5, 6, 7, 8}, 3.2.{1, 2, 3} all mention the DOTS = communication model is the one of Section 3.1.1 or Section 3.1.2. I am = thus wondering if it would not help to have this model described as a = model from which the use cases are derived.=20 =20 Yours,=20 Daniel =20 On Tue, Oct 24, 2017 at 5:59 PM, Roland Dobbins = wrote: On 25 Oct 2017, at 4:53, internet-drafts@ietf.org wrote: Filename : draft-ietf-dots-use-cases-08.txt Comments and suggestions welcome; in particular, the WG's consensus on = the Home Network use-case in Section 3.2.2 and the relative value it = adds as compared to the other use cases would be greatly appreciated. We'd like to rev the draft at least one more time prior to the = pre-meeting cutoff, so please don't be shy! ;> ----------------------------------- Roland Dobbins _______________________________________________ Dots mailing list Dots@ietf.org https://www.ietf.org/mailman/listinfo/dots =20 ------=_NextPart_000_0510_01D35305.BEB2FF20 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

A Nit =E2=80=93 the following does not parse =E2=80=93 delete first = =E2=80=98or=E2=80=99

 

3.2.2

=E2=80=9C When the CPE suspects an attack, it notifies automatically = or the

=C2=A0=C2=A0 ISP.=C2=A0 The contact address of the DDoS Mitigation = service of the ISP

=C2=A0=C2=A0 may be hard coded or may be configured manually or = automatically

=C2=A0=C2=A0 (e.g., eventually the DHCP server may provide the DDoS = mitigation

=C2=A0=C2=A0 service via specific DHCP = options).=E2=80=9D

 

Regards

 

Jon

 

From:= Dots = [mailto: dots-bounces@ietf.org] On Behalf Of Daniel = Migault
Sent: 01 November 2017 01:29
To: Roland = Dobbins
Cc: dots@ietf.org
Subject: Re: [Dots] I-D = Action: draft-ietf-dots-use-cases-08.txt

 


Hi, =

Thanks Roland for posting = 08. I have a few comments

Use case = from section  3.1.1 to 3.1.4 seems to me very similar, thus I am = wondering if it would not make sense to have them in one section. =

Nit:

When an attack is detected, an automated or = manual DOTS mitigation request is be generated. I believe "be" = should be removed.


section = 3.1.{5, 6, 7, 8}, 3.2.{1, 2, 3}  all mention the DOTS communication = model is the one of Section 3.1.1 or Section 3.1.2. I am thus wondering = if it would not help to have this model described as a model from which = the use cases are derived.

 

Yours,

Daniel

 

On Tue, = Oct 24, 2017 at 5:59 PM, Roland Dobbins <rdobbins@arbor.net> wrote:

On 25 Oct 2017, at = 4:53, internet-drafts@ietf.org wrote:

        Filename    =     : draft-ietf-dots-use-cases-08.txt


Comments and suggestions welcome; in particular, = the WG's consensus on the Home Network use-case in Section 3.2.2 and the = relative value it adds as compared to the other use cases would be = greatly appreciated.

We'd like to rev the draft at least one more = time prior to the pre-meeting cutoff, so please don't be = shy!

;>

-----------------------------------
Roland = Dobbins <rdobbins@arbor.net>



_______________________________________________=
Dots mailing list
Dots@ietf.org
https://www.ietf.org/mailman/listinfo/dots

 

------=_NextPart_000_0510_01D35305.BEB2FF20-- From nobody Wed Nov 1 06:31:06 2017 Return-Path: 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 89A3C13F3D5 for ; Wed, 1 Nov 2017 06:31:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.319 X-Spam-Level: X-Spam-Status: No, score=-4.319 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 of9gZ6NC1SVn for ; Wed, 1 Nov 2017 06:31:02 -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 45B4813F967 for ; Wed, 1 Nov 2017 06:31:01 -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=1509543060; h=From: To:Subject:Thread-Topic:Thread-Index:Date: Message-ID:Accept-Language:Content-Language: X-MS-Has-Attach:X-MS-TNEF-Correlator:authentication-results: x-originating-ip:x-ms-publictraffictype:x-microsoft-exchange-diagnostics: x-ms-exchange-antispam-srfa-diagnostics:x-ms-office365-filtering-correlation-id: x-microsoft-antispam:x-ms-traffictypediagnostic: x-exchange-antispam-report-test:x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test:x-forefront-prvs: x-forefront-antispam-report:received-spf:spamdiagnosticoutput: spamdiagnosticmetadata:Content-Type: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-Transport-CrossTenantHeadersStamped: X-OriginatorOrg:X-NAI-Spam-Flag:X-NAI-Spam-Threshold: X-NAI-Spam-Score:X-NAI-Spam-Version; bh=g ej9VldvSxV1VLKudomDK9QLB1iUPS6SXponaX4T4l 8=; b=DXVdcxt51wcvK3btNmQq1mz6LtU3skdhmaOrWvOzUse1 OLSs94gLZf+GgwNUEyUgyUgy164nGaIHDLTwdXsLXSAVKEDOQ6 ZPCT9hvKQNW/ijf6c+l5IgpzlZ3OiusHyu/u9FZz37yp9pNVx9 4OjijEwfSIYS5BTLDL+8nY3i+JM= Received: from DNVEXAPP1N06.corpzone.internalzone.com (unknown [10.44.48.90]) by DNVWSMAILOUT1.mcafee.com with smtp id 540e_f513_e65caa25_5b1c_4e50_a16e_fa5428653c8c; Wed, 01 Nov 2017 08:31:00 -0500 Received: from DNVEXUSR1N14.corpzone.internalzone.com (10.44.48.87) by DNVEXAPP1N06.corpzone.internalzone.com (10.44.48.90) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Wed, 1 Nov 2017 07:29:59 -0600 Received: from DNVEXUSR1N13.corpzone.internalzone.com (10.44.48.86) by DNVEXUSR1N14.corpzone.internalzone.com (10.44.48.87) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Wed, 1 Nov 2017 07:29:58 -0600 Received: from DNVO365EDGE2.corpzone.internalzone.com (10.44.176.74) by DNVEXUSR1N13.corpzone.internalzone.com (10.44.48.86) with Microsoft SMTP Server (TLS) id 15.0.1347.2 via Frontend Transport; Wed, 1 Nov 2017 07:29:58 -0600 Received: from NAM03-BY2-obe.outbound.protection.outlook.com (10.44.176.242) by edge.mcafee.com (10.44.176.74) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Wed, 1 Nov 2017 07:29:57 -0600 Received: from DM5PR16MB1788.namprd16.prod.outlook.com (10.172.44.144) by DM5PR16MB1786.namprd16.prod.outlook.com (10.172.44.142) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.178.6; Wed, 1 Nov 2017 13:29:57 +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.20.0178.015; Wed, 1 Nov 2017 13:29:57 +0000 From: "Konda, Tirumaleswar Reddy" To: "dots@ietf.org" Thread-Topic: Overlapping mitigation requests from a DOTS client Thread-Index: AdNTEI1883tp4+lsSlOjP4a89tzzJQ== Date: Wed, 1 Nov 2017 13:29:56 +0000 Message-ID: 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.206.27] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DM5PR16MB1786; 6:ng80Cb0Fa/zVyspKlER5+wN33+Sybl4m+dZdJw+z0czkQbPjf9+22rZswdIoIhAJ7degFCkJXEDRqxJfZ12Fxh7SPt/DnQCgqPPLHJqbcZr+54bwMr/1MS5B4ts/tlxY4QUtMenYyyxER05rWU5lXLEvYjWPc+cypByw7UVTOqs3fmx+v6w1UaxncpMK4atwsYxh+iR+npyFybnqvXymnAkxPn7lRpAZBPUVJjG338/8dqRCuJjj2HvILF/ECul6ptIeIFwl5qQCdI7YDSmFkXvwo4+gf/ufg7YZ24Y1fKaFku0yTer52YRMIey8f+3FIYUldUwu6jFZfUZeO/UCO97OshBmB0JKlLozEHugvJY=; 5:OBC7GRehGnTVDqGeDXiVPc53xEKtoe0guizVQh6Tt1mtRbuA7nAlryYckpfQ8XLK1TYgEqsdWQ1cXD5HksnAFt7v0BOSi9cUyXnx09DLmGmajfGV9Z9/UVX79vO7b2x1SzXU9GEFuRqAIKZbacVLw7GeUYm/PvGAQ/F7c10D5VU=; 24:lFpUOibnybee3Hx7JTKKXKGCSavmy16Pm/TTfSvZQJSvWcpd4IjCHh7cpECu1cNuPSc0mOTTnMpNt6vN4HC/KS2U4r3bI+o0ZnLYLPsjehI=; 7:yrqgM0WoYlskFVd36xOkkIOZKr7cGWsAoLs739uHYS+az8CBR2V8/Fjp5ZlPpV4tVGmusi8KkVohBHhZBXoyccEfJ/nhzM5efKKSt0yV2SKYW58izTy6O/XUkm6eJHmmbx1VYuk7BgB/98slkLAPMLlXPg1NHnQdiSQ1IbjWTgTHDezTOLdRCM6OUFjfeDTUyff+OqEUr0PcpQM98QOLFh9WyoezJy3pML/CxmYNeuWj3ZMF+riSTFFqpVwK1u6b x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: e33fa84a-b88c-44da-3382-08d5212ca4d3 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(4534020)(4602075)(2017052603199); SRVR:DM5PR16MB1786; x-ms-traffictypediagnostic: DM5PR16MB1786: x-exchange-antispam-report-test: UriScan:(158342451672863)(120809045254105)(166708455590820)(21748063052155); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(8121501046)(5005006)(93006095)(93001095)(3231020)(3002001)(100000703101)(100105400095)(10201501046)(6041248)(20161123560025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123564025)(20161123558100)(20161123562025)(20161123555025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:DM5PR16MB1786; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:DM5PR16MB1786; x-forefront-prvs: 0478C23FE0 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(346002)(376002)(189002)(32952001)(199003)(1730700003)(81166006)(81156014)(68736007)(2900100001)(8676002)(8936002)(66066001)(74316002)(101416001)(7736002)(5630700001)(14454004)(54356999)(966005)(50986999)(5640700003)(316002)(5660300001)(189998001)(7696004)(25786009)(97736004)(6916009)(3660700001)(2351001)(478600001)(105586002)(2906002)(6306002)(54896002)(236005)(55016002)(9686003)(102836003)(3846002)(80792005)(790700001)(6116002)(2501003)(3280700002)(106356001)(72206003)(33656002)(606006)(99286003)(77096006)(86362001)(6436002)(6506006)(53936002)(85282002); DIR:OUT; SFP:1101; SCL:1; SRVR:DM5PR16MB1786; H:DM5PR16MB1788.namprd16.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; 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_DM5PR16MB1788A0456B923C80557B48D6EA5F0DM5PR16MB1788namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: e33fa84a-b88c-44da-3382-08d5212ca4d3 X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Nov 2017 13:29:56.8188 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4943e38c-6dd4-428c-886d-24932bc2d5de X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR16MB1786 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 <6149> : inlines <6153> : streams <1769045> : uri <2526138> Archived-At: Subject: [Dots] Overlapping mitigation requests from a DOTS client 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Nov 2017 13:31:04 -0000 --_000_DM5PR16MB1788A0456B923C80557B48D6EA5F0DM5PR16MB1788namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable In the DOTS signal channel draft, if two mitigation requests have overlappi= ng mitigations scopes, then the overlapped lower number mitigation-id is au= tomatically deleted by the DOTS server. Jon's DOTS server implementation uses the above approach but Kaname's imple= mentation maintains both the mitigation requests, and the DOTS server autom= atically falls back to use the lower number mitigation-id after the higher = number mitigation-id is deleted by the DOTS client. The disadvantage of the= latter approach is, the DOTS server and client could end-up maintaining a = long list of overlapping mitigation requests and looks error-prone. This issue was raised in the virtual interim meeting https://datatracker.ie= tf.org/meeting/interim-2017-dots-03/materials/minutes-interim-2017-dots-03-= 201710021000/ and tracked in https://github.com/dotswg/dots-signal-channel/= issues/2 I would like to start this thread is to discuss the pros and cons of both m= echanisms, to help decide if the current behavior can be retained or needs = to be modified. -Tiru --_000_DM5PR16MB1788A0456B923C80557B48D6EA5F0DM5PR16MB1788namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

In the DOTS signal channel draft, if two mitigation = requests have overlapping mitigations scopes, then the overlapped lower num= ber mitigation-id is automatically deleted by the DOTS server.

 

Jon’s DOTS server implementation uses the abov= e approach but Kaname’s implementation maintains both the mitigation = requests, and the DOTS server automatically falls back to use the lower num= ber mitigation-id after the higher number mitigation-id is deleted by the DOTS client. The disadvantage of the latter approach is,= the DOTS server and client could end-up maintaining a long list of overlap= ping mitigation requests and looks error-prone.

 

This issue was raised in the virtual interim meeting= https://datatracker.ietf.org/meeting/interim-2017-dots-03/materials/minutes= -interim-2017-dots-03-201710021000/ and tracked in https://= github.com/dotswg/dots-signal-channel/issues/2

 

I would like to start this thread is to discuss the = pros and cons of both mechanisms, to help decide if the current behavior ca= n be retained or needs to be modified.

 

-Tiru

--_000_DM5PR16MB1788A0456B923C80557B48D6EA5F0DM5PR16MB1788namp_-- From nobody Wed Nov 1 06:44:29 2017 Return-Path: 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 CE7B0139436 for ; Wed, 1 Nov 2017 06:44:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.999 X-Spam-Level: X-Spam-Status: No, score=-6.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 CD_z-BvlXIIc for ; Wed, 1 Nov 2017 06:44:24 -0700 (PDT) Received: from MIVWSMAILOUT1.mcafee.com (mivwsmailout1.mcafee.com [161.69.47.167]) (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 28C0013A4F4 for ; Wed, 1 Nov 2017 06:44:23 -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=1509543863; 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: authentication-results:x-originating-ip:x-ms-publictraffictype: x-microsoft-exchange-diagnostics:x-ms-exchange-antispam-srfa-diagnostics: x-ms-office365-filtering-correlation-id:x-microsoft-antispam: x-ms-traffictypediagnostic:x-exchange-antispam-report-test: x-microsoft-antispam-prvs:x-exchange-antispam-report-cfa-test: x-forefront-prvs:x-forefront-antispam-report: received-spf:spamdiagnosticoutput:spamdiagnosticmetadata: Content-Type: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-Transport-CrossTenantHeadersStamped: X-OriginatorOrg:X-NAI-Spam-Flag:X-NAI-Spam-Threshold: X-NAI-Spam-Score:X-NAI-Spam-Version; bh=p t11yZ6ZmETLcxDLX2FuJpZ9OGETfBVteiaYhFv9UG U=; b=e+ssfEzLOfFRDnb5opsbvgglpABOZhtAAYJBDycY5GSA s4NnwXFEDUPnBtJ20BtKZOe6e/iJJBBj7gnTTEPq6E85gbGU8I XxxUmnpaNCgubH31pXtA0aCi+FR2vFXySEaK624gI01DPfSgdS H5LPDdedaAVKJK/DixtB12vDKwQ= Received: from MIVEXAPP1N02.corpzone.internalzone.com (unknown [10.48.48.89]) by MIVWSMAILOUT1.mcafee.com with smtp id 5dfc_86ef_53035f05_c6cd_43c4_9c87_fc94acfa8777; Wed, 01 Nov 2017 08:44:21 -0500 Received: from MIVEXUSR1N06.corpzone.internalzone.com (10.48.48.86) by MIVEXAPP1N02.corpzone.internalzone.com (10.48.48.89) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Wed, 1 Nov 2017 09:44:21 -0400 Received: from MIVEXUSR1N04.corpzone.internalzone.com (10.48.48.84) by MIVEXUSR1N06.corpzone.internalzone.com (10.48.48.86) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Wed, 1 Nov 2017 09:44:19 -0400 Received: from MIVO365EDGE3.corpzone.internalzone.com (10.48.176.86) by MIVEXUSR1N04.corpzone.internalzone.com (10.48.48.84) with Microsoft SMTP Server (TLS) id 15.0.1347.2 via Frontend Transport; Wed, 1 Nov 2017 09:44:19 -0400 Received: from NAM02-CY1-obe.outbound.protection.outlook.com (10.48.176.241) by edge.mcafee.com (10.48.176.86) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Wed, 1 Nov 2017 09:44:18 -0400 Received: from DM5PR16MB1788.namprd16.prod.outlook.com (10.172.44.144) by DM5PR16MB1786.namprd16.prod.outlook.com (10.172.44.142) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.178.6; Wed, 1 Nov 2017 13:44:17 +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.20.0178.015; Wed, 1 Nov 2017 13:44:17 +0000 From: "Konda, Tirumaleswar Reddy" To: Jon Shallow , "dots@ietf.org" Thread-Topic: [Dots] Full Pipe Scenario Thread-Index: AdNOmftpS0b6T9g6S+iNSHMqb5xZmAAPOwUAABDy9AAAAZhggACMYj4AAHEFHjA= Date: Wed, 1 Nov 2017 13:44:17 +0000 Message-ID: References: <017001d34e9a$000d7b50$002871f0$@jpshallow.com> <025801d34f1a$b3c62e50$1b528af0$@jpshallow.com> <03a501d35152$9e53da60$dafb8f20$@jpshallow.com> In-Reply-To: <03a501d35152$9e53da60$dafb8f20$@jpshallow.com> 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.206.27] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DM5PR16MB1786; 6:U8k7xfXoq4Cbs6WVZLlZhp/3jfVTaf+R5gpts7NYjtJxrvpw93HT+fps5j6iWx+VGEiwJH57tkG0k8+ktkGXFC8+4r+Gu1cQxGSHbpmmzzayrEYmJUpITsxJR4Gjc343IMSrT1Sqyy4Ue+3v5sWqlGsfDW+PBUdCDkSfOCp/vMF1kX0MoGwGDkOwIABKJn3QGrCH8QSixEm/J8SoxLJ/RdWHS9O4WeNP5cBdBoJssWGHSY7V4mRapcBTXnBhQKevGSWTyaEUsPoJGGhZNMvdHtP1QyPh6YcYMM1X++6Cq0Je1qyKHkT9Y3JhdfSRg9eq+5t01pBMrr0I28Ma56a0uCzoMMrEWxZQaMWIfuEr6u8=; 5:1frNQmnzy0TvaOhZiEgeStn+geTD3tQBvL1QI7tTqhdZxPgREVTxcHg7gPYF6vF9hrc4EKTe7TVpn7YZKXejj/K+3zK+BhtR/Eb7wdQzcqn0ObJjwMC1NotB9emgTbEdN/UBE94+zkwxIBgfro9wKs1ubyxdUubD9CAmN42CX9o=; 24:wMKUHM/YEDMIIFJZ35/Pn6WQmTOANoyv+MWvwCYEhbXSQ+v9BhuUgrbVxzYZZifU6UV0xTNnnI5WmU7lIRgP/SCxMzXmaqiWNYSxT3auocQ=; 7:0lBRvi0FDuDFh42qzpAP76/J6QYqFkXZusJ7AbAtfpvOAWmlDY6OhC7yVLWcCEUPYWCTfr2OdOM5bSXNjCOkm4RntrQNlBsxCfKxmOok1WypY/BiTWfckfdEf/6F0GgUeOC10Gs7qoHTYFBcuo2JjpFYkvHxeg/CWSoTpiEplVJJo0osYAykOt7db+KNBzR1tP4QhS5Tfa4prvHK/sY5TFFxAJNdKliL/mMJ+1mvPCF9eqpy8OQqxBCw+/VemD/F x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 3338f1d4-dc53-4a44-b612-08d5212ea5ee x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(4534020)(4602075)(2017052603199); SRVR:DM5PR16MB1786; x-ms-traffictypediagnostic: DM5PR16MB1786: x-exchange-antispam-report-test: UriScan:(158342451672863)(72170088055959)(166708455590820)(21748063052155)(123452027830198); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(8121501046)(5005006)(93006095)(93001095)(3231020)(3002001)(100000703101)(100105400095)(10201501046)(6041248)(20161123560025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123564025)(20161123558100)(20161123562025)(20161123555025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:DM5PR16MB1786; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:DM5PR16MB1786; x-forefront-prvs: 0478C23FE0 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(376002)(346002)(199003)(32952001)(57704003)(189002)(80792005)(2501003)(6116002)(790700001)(3846002)(102836003)(3280700002)(72206003)(106356001)(105586002)(236005)(2906002)(54896002)(6306002)(55016002)(9686003)(77096006)(99286003)(229853002)(53936002)(6436002)(6506006)(19609705001)(86362001)(6246003)(53546010)(33656002)(606006)(478600001)(74316002)(101416001)(7736002)(66066001)(93886005)(14454004)(68736007)(2900100001)(81156014)(81166006)(8676002)(8936002)(97736004)(189998001)(25786009)(110136005)(7696004)(3660700001)(2950100002)(966005)(50986999)(54356999)(76176999)(5660300001)(316002)(85282002); DIR:OUT; SFP:1101; SCL:1; SRVR:DM5PR16MB1786; H:DM5PR16MB1788.namprd16.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX: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_DM5PR16MB178829DAD60148ACF4A446EBEA5F0DM5PR16MB1788namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 3338f1d4-dc53-4a44-b612-08d5212ea5ee X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Nov 2017 13:44:17.7483 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4943e38c-6dd4-428c-886d-24932bc2d5de X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR16MB1786 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 <6149> : inlines <6153> : streams <1769045> : uri <2526144> Archived-At: Subject: Re: [Dots] Full Pipe Scenario 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Nov 2017 13:44:28 -0000 --_000_DM5PR16MB178829DAD60148ACF4A446EBEA5F0DM5PR16MB1788namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thanks Jon, updated draft uploaded to https://github.com/dotswg/dots-signal= -channel. It also addresses various other issues discussed in the WG (use o= f .well-known, default port for DOTS, comments from Kaname to map alt-serve= r, alt-server-record, ttl, addr to CBOR etc.). -Tiru From: Jon Shallow [mailto:supjps-ietf@jpshallow.com] Sent: Monday, October 30, 2017 1:12 PM To: Konda, Tirumaleswar Reddy ; dots@ie= tf.org Subject: RE: [Dots] Full Pipe Scenario Hi Tiru, This looks good to me. Thanks. Regards Jon From: Dots [mailto: dots-bounces@ietf.org] On= Behalf Of Konda, Tirumaleswar Reddy Sent: 30 October 2017 07:26 To: Jon Shallow; dots@ietf.org Subject: Re: [Dots] Full Pipe Scenario Thanks Jon, I have modified the proposed text as follows: In case of a volumetric DDoS attack saturating the incoming link to the DOT= S client, all traffic from the DOTS server to the DOTS client will likely b= e dropped, although the DOTS server receives heartbeat requests and DOTS me= ssages from the DOTS client. In this scenario, the DOTS agents MUST behave differently to handle message= transmission and DOTS session liveliness during link saturation : * The DOTS client MUST NOT consider the DOTS session terminated even after = maximum "missing-hb-allowed" threshold is reached. DOTS client SHOULD conti= nue to use the current DOTS session, and send heartbeat requests over the c= urrent DOTS session, so the DOTS server knows the DOTS client has not disco= nnected the DOTS session. After the maximum "missing-hb-allowed" threshold = is reached, the DOTS client SHOULD try (D)TLS session resumption. The DOTS = client SHOULD send mitigation requests over the current DOTS session, and i= n parallel, try (D)TLS session resumption or 0-RTT mode in DTLS 1.3 to pigg= yback the mitigation request in the ClientHello message. Once the link is = no longer statured, if traffic from the DOTS server reaches the DOTS client= over the current DOTS session, the DOTS client can stop (D)TLS session res= umption or if (D)TLS session resumption is successful then disconnect the c= urrent DOTS session. * If the DOTS server does not receive any traffic from the DOTS client, the= n the DOTS server sends heartbeat requests to the DOTS client and if "trigg= er-mitigation" is set to "false", then trigger DDoS mitigation after maximu= m "missing-hb-allowed" threshold is reached. -Tiru From: Jon Shallow [mailto:supjps-ietf@jpshallow.com] Sent: Friday, October 27, 2017 5:27 PM To: Konda, Tirumaleswar Reddy >; dots@ietf.org Subject: RE: [Dots] Full Pipe Scenario Hi Tiru, I propose then that we add to the end of the first paragraph of [5.6 Heartb= eat Mechanism] something similar to Orig: "To provide a metric of signal health and distinguish an 'idle' signa= l channel from a 'disconnected' or 'defunct' session, the DOTS agent sends a heartbeat over the signal channel to maintain its half of the channel. The DOTS agent similarly expects a heartbeat from its peer DOTS agent, and may consider a session terminated in the extended absence of a peer agent heartbeat." New: "With the attack scenario of the pipe going from the DOTS server to th= e DOTS client running full, the DOTS server will be seeing the heartbeat re= quests from the DOTS client, but no responses from the DOTS server initiate= d heartbeats. The DOTS server SHOULT NOT consider the session terminated a= fter "missing-hb-allowed" has been exceeded, but SHOULD continue with the s= ession and SHOULD continue sending heartbeats on the assumption that it is = a pipe full scenario and there potentially could be new mitigation requests= from the DOTS client. Any "trigger-mitigation" set to "false" MUST still = be triggered when "missing-hb-allowed" has been exceeded. Similarly, the DOTS client will be seeing nothing coming from the DOTS serv= er. After "missing-hb-allowed" has been exceeded, the DOTS client SHOULD t= ry (D)TLS session resumption or use 0-RTT mode in (D)TLS 1.3 to piggyback a= new mitigation request in the ClientHello, but MUST continue to send heart= beats using the "missing-hb-allowed" failing session so that the DOTS serve= r knows there still is communication. If the DOTS client has a new mitigat= ion request, the DOTS client SHOULD "blindly" send the new mitigation reque= st over the "failing" session in addition to the session resumption. Only = when traffic starts to arrive again from the DOTS server should the "failin= g" session be dropped and a new session established. Orig: " While the communication between the DOTS agents is quiescent, the DOTS client will probe the DOTS server to ensure it has maintained cryptographic state and vice versa. Such probes can also keep alive firewall and/or NAT bindings. This probing reduces the frequency of establishing a new handshake when a DOTS signal needs to be conveyed to the DOTS server." From: Dots [mailto: dots-bounces@ietf.org] On= Behalf Of Konda, Tirumaleswar Reddy Sent: 27 October 2017 07:07 To: Jon Shallow; dots@ietf.org Subject: Re: [Dots] Full Pipe Scenario Heartbeat mechanism is triggered only when the communication b/w the DOTS a= gents is idle (see https://tools.ietf.org/html/draft-ietf-dots-signal-chann= el-05#section-5.6). In this case, the DOTS client does not receive any mitigation response from= the DOTS server, and the DOTS client knows the inbound pipe is saturated, = but the DOTS client does not know if the DOTS session is disconnected. To h= andle both the problems, and maximize reachability, the DOTS client can con= tinue to use the same DOTS session even if no response is received for the = heartbeat but at the same time try (D)TLS session resumption or use 0-RTT m= ode in (D)TLS 1.3 to piggyback the mitigation request in the ClientHello. When the inbound pipe is no longer saturated, but the DOTS client does not = receive any heartbeat responses from the DOTS server then it should conside= r the session is defunct after missing-hb-allowed number of times. -Tiru From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Jon Shallow Sent: Friday, October 27, 2017 2:06 AM To: dots@ietf.org Subject: [Dots] Full Pipe Scenario Hi, DOTS Client (C) --------- Pipe -------- DOTS Server (S) We have been testing DOTS server and DOTS client signal channel interaction= with a full inbound pipe scenario where all traffic from DOTS server to DO= TS client is dropped, but traffic from DOTS client is getting through to th= e DOTS server. The outbound pipe may be lossy, but testing was done with very little loss = outbound. If the outbound pipe is running full, then the DOTS Client environment has = to control this traffic as the DOTS Server is very unlikely to be able to d= o anything here - so this scenario ignored! With this full inbound pipe (direction S to C), we are seeing the following * DOTS server sees the Heartbeat requests from the DOTS client * DOTS server sees any mitigation requests from the DOTS client * DOTS server thinks the signal channel is dead as there are no respo= nses to the DOTS server's Heartbeats * DOTS client thinks the signal channel is dead as there are no respo= nses to the DOTS client's Heartbeats * DOTS client is unable to establish a new signal channel with the se= rver (this may be down to the fact that we internally have not (yet) got se= ssion resumption working over DTLS) and so cannot send mitigation requests = over this channel If the DOTS server is seeing and noting the DOTS client Heartbeat requests,= it can determine the session is still alive and keep it going, even if its= own Heartbeats are failing (perhaps just mark the session as 'Heartbeat Fa= iling' after the missing heartbeat counter has expired). Should we be doin= g this noting of DOTS Client heartbeats? [TR] Yes, it s -The DOTS server can safely assume there is a pipe full scenario (or networ= k routing issue) if it continues to see the DOTS client heartbeats. If the DOTS server is still keeping the session going, and receives a DOTS = client mitigation request it can be acted on, even though there is a full p= ipe. Is this a good thing? Should the DOTS client continue to send Heartbeats after the DOTS client ha= s determined the session has 'Heartbeat Failed' - so that that the DOTS ser= ver is kept "warm" in case a mitigation request has to blindly be sent. If the DOTS client closes the session after Heartbeat failure, fails to est= ablish a new session, then there is no mechanism to send a mitigation reque= st - the DOTS client may have discovered a new IP or subnet under attack. - I appreciate that we have a trigger-mitigation flag which may help here. - If the new session gets going, then the "Heartbeat Failure" session shoul= d be closed down. Keeping the Heartbeats going, even after the determination that Heartbeats = are failing has benefits in supporting additional mitigation requests, but = potentially conflicts with the DOTS requirements specification of consideri= ng a DOTS signal channel as no longer active after receipt of heartbeat res= ponses. I know SIG-003 is the subject of another debate - do we need heart= beats at all. SIG-003 Channel Health Monitoring: Peer DOTS agents MUST regularly send heartbeats to each other after mutual authentication in order to keep the DOTS signal channel active. A signal channel MUST be considered active until a DOTS agent explicitly ends the session, or either DOTS agent fails to receive heartbeats from the other after a mutually agreed upon timeout period has elapsed. Regards Jon --_000_DM5PR16MB178829DAD60148ACF4A446EBEA5F0DM5PR16MB1788namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Thanks Jo= n, updated draft uploaded to https://github.co= m/dotswg/dots-signal-channel. It also addresses various other issues di= scussed in the WG (use of .well-known, default port for DOTS, comments from= Kaname to map alt-server, alt-server-record, ttl, addr to CBOR etc.).

&nbs= p;

-Tiru

 

From:<= /span> Jon Shallow [mailto:s= upjps-ietf@jpshallow.com]
Sent: Monday, October 30, 2017 1:12 PM
To: Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@McAfee.com= >; dots@ietf.org
Subject: RE: [Dots] Full Pipe Scenario

 

Hi Tiru= ,

&n= bsp;

This lo= oks good to me.  Thanks.

&n= bsp;

Regards=

&n= bsp;

Jon

&n= bsp;

From: Dots [mailto: dots-bounces@ietf.org] On B= ehalf Of Konda, Tirumaleswar Reddy
Sent: 30 October 2017 07:26
To: Jon Shallow; dots@ietf.org<= br> Subject: Re: [Dots] Full Pipe Scenario

 

Thanks Jon, I have modified the proposed text as follows:

           &= nbsp;           &nbs= p;            &= nbsp;      

In case of a volumetric DDoS attack saturating the incoming link to= the DOTS client, all traffic from the DOTS server to the DOTS client will = likely be dropped, although the DOTS server receives heartbeat requests and DOTS messages from the DOTS client.=

In this scenario, the DOTS agents MUST behave differently to handle= message transmission and DOTS session liveliness during link saturation :<= o:p>

 

* The DOTS client MUST NOT consider the DOTS session terminated eve= n after maximum "missing-hb-allowed" threshold is reached. DOTS c= lient SHOULD continue to use the current DOTS session, and send heartbeat requests over the current DOTS session, so the= DOTS server knows the DOTS client has not disconnected the DOTS session. A= fter the maximum "missing-hb-allowed" threshold is reached, the D= OTS client SHOULD try (D)TLS session resumption. The DOTS client SHOULD send mitigation requests over the current DOTS sess= ion, and in parallel, try (D)TLS session resumption or 0-RTT mode in DTLS 1= .3 to piggyback the mitigation request in the ClientHello message.  On= ce the link is no longer statured, if traffic from the DOTS server reaches the DOTS client over the current DOTS= session, the DOTS client can stop (D)TLS session resumption or if (D)TLS s= ession resumption is successful then disconnect the current DOTS session.

 

* If the DOTS server does not receive any traffic from the DOTS cli= ent, then the DOTS server sends heartbeat requests to the DOTS client and i= f “trigger-mitigation” is set to “false”, then trigger DDoS mitigation after maximum "missing-hb-allowed" = threshold is reached.

&nbs= p;

-Tiru

&nbs= p;

From:<= /span> Jon Shallow [<= a href=3D"mailto:supjps-ietf@jpshallow.com">mailto:supjps-ietf@jpshallow.com]
Sent: Friday, October 27, 2017 5:27 PM
To: Konda, Tirumaleswar Reddy <Tirum= aleswarReddy_Konda@McAfee.com>; dots@ietf.org=
Subject: RE: [Dots] Full Pipe Scenario

 

Hi Tiru= ,

&n= bsp;

I propo= se then that we add to the end of the first paragraph of [5.6 Heartbeat Mec= hanism] something similar to

&n= bsp;

Orig: &= #8220;To provide a metric of signal health and distinguish an 'idle' signal=

 &= nbsp; channel from a 'disconnected' or 'defunct' session, the DOTS agent

 &= nbsp; sends a heartbeat over the signal channel to maintain its half of the=

 &= nbsp; channel.  The DOTS agent similarly expects a heartbeat from its = peer

 &= nbsp; DOTS agent, and may consider a session terminated in the extended

 &= nbsp; absence of a peer agent heartbeat.”

&n= bsp;

New: &#= 8220;With the attack scenario of the pipe going from the DOTS server to the= DOTS client running full, the DOTS server will be seeing the heartbeat req= uests from the DOTS client, but no responses from the DOTS server initiated heartbeats.  The DOTS server SHOULT NO= T consider the session terminated after "missing-hb-allowed" has = been exceeded, but SHOULD continue with the session and SHOULD continue sen= ding heartbeats on the assumption that it is a pipe full scenario and there potentially could be new mitigation requests = from the DOTS client.  Any “trigger-mitigation” set to = 220;false” MUST still be triggered when "missing-hb-allowed"= ; has been exceeded.

&n= bsp;

Similar= ly, the DOTS client will be seeing nothing coming from the DOTS server.&nbs= p; After "missing-hb-allowed" has been exceeded, the DOTS client = SHOULD try (D)TLS session resumption or use 0-RTT mode in (D)T= LS 1.3 to piggyback a new mitigation request in the ClientHello, but MUST continue to send heartbe= ats using the "missing-hb-allowed" failing session so that the DOTS server knows there still is communication.  = If the DOTS client has a new mitigation request, the DOTS client SHOULD = 220;blindly” send the new mitigation request over the “failing&= #8221; session in addition to the session resumption.  Only when traffic starts to arrive again from the DOTS server should the “fail= ing” session be dropped and a new session established.

&n= bsp;

Orig: &= #8220;   While the communication between the DOTS agents is quies= cent, the

 &= nbsp; DOTS client will probe the DOTS server to ensure it has maintained

 &= nbsp; cryptographic state and vice versa.  Such probes can also keep a= live

 &= nbsp; firewall and/or NAT bindings.  This probing reduces the frequenc= y of

 &= nbsp; establishing a new handshake when a DOTS signal needs to be conveyed<= o:p>

 &= nbsp; to the DOTS server.“

&n= bsp;

From: Dots [mailto: = dots-bounces@ietf.org] On Behalf Of Konda, Tirumaleswar Reddy
Sent: 27 October 2017 07:07
To: Jon Shallow; dots@ietf.org
Subject: Re: [Dots] Full Pipe Scenario

 

Heartbeat= mechanism is triggered only when the communication b/w the DOTS agents is = idle (see https://tools.= ietf.org/html/draft-ietf-dots-signal-channel-05#section-5.6).  

In this c= ase, the DOTS client does not receive any mitigation response from the DOTS= server, and the DOTS client knows the inbound pipe is saturated, but the D= OTS client does not know if the DOTS session is disconnected. To handle both the problems, and maximize reachab= ility, the DOTS client can continue to use the same DOTS session even if no= response is received for the heartbeat but at the same time try (D)TLS ses= sion resumption or use 0-RTT mode in (D)TLS 1.3 to piggyback the mitigation request in the ClientHello.

When the = inbound pipe is no longer saturated, but the DOTS client does not receive a= ny heartbeat responses from the DOTS server then it should consider the ses= sion is defunct

after mis= sing-hb-allowed number of times.

&nbs= p;

-Tiru

&nbs= p;

From:<= /span> Dots [mailto:dots-bounces@ietf.org] On Behalf Of Jon Shallow
Sent: Friday, October 27, 2017 2:06 AM
To: dots@ietf.org
Subject: [Dots] Full Pipe Scenario

 

Hi,

 

DOTS Client (C) –-------- &n= bsp;Pipe –------- DOTS Server (S)

 

We have been testing DOTS serve= r and DOTS client signal channel interaction with a full inbound pipe scena= rio where all traffic from DOTS server to DOTS client is dropped, but traff= ic from DOTS client is getting through to the DOTS server.

 

The outbound pipe may be lossy,= but testing was done with very little loss outbound.

 

If the outbound pipe is running= full, then the DOTS Client environment has to control this traffic as the = DOTS Server is very unlikely to be able to do anything here – so this= scenario ignored!

 

With this full inbound pipe (di= rection S to C), we are seeing the following

 

· &n= bsp;     DOTS server sees the Heartbeat requests from th= e DOTS client

· &n= bsp;     DOTS server sees any mitigation requests from t= he DOTS client

· &n= bsp;     DOTS server thinks the signal channel is dead a= s there are no responses to the DOTS server’s Heartbeats

· &n= bsp;     DOTS client thinks the signal channel is dead a= s there are no responses to the DOTS client’s Heartbeats

· &n= bsp;     DOTS client is unable to establish a new signal= channel with the server (this may be down to the fact that we internally h= ave not (yet) got session resumption working over DTLS) and so cannot send = mitigation requests over  this channel

 

If the DOTS server is seeing an= d noting the DOTS client Heartbeat requests, it can determine the session i= s still alive and keep it going, even if its own Heartbeats are failing (pe= rhaps just mark the session as ‘Heartbeat Failing’ after the missing heartbeat counter has expired).  Sho= uld we be doing this noting of DOTS Client heartbeats?

 

[TR] Yes, it s

 

-The DOTS server can safely ass= ume there is a pipe full scenario (or network routing issue) if it continue= s to see the DOTS client heartbeats.

 

If the DOTS server is still kee= ping the session going, and receives a DOTS client mitigation request it ca= n be acted on, even though there is a full pipe.  Is this a good thing= ?

 

Should the DOTS client continue= to send Heartbeats after the DOTS client has determined the session has &#= 8216;Heartbeat Failed’ – so that that the DOTS server is kept &= #8220;warm” in case a mitigation request has to blindly be sent.=

 

If the DOTS client closes the s= ession after Heartbeat failure, fails to establish a new session, then ther= e is no mechanism to send a mitigation request – the DOTS client may = have discovered a new IP or subnet under attack.

- I appreciate that we have a t= rigger-mitigation flag which may help here.

- If the new session gets going= , then the “Heartbeat Failure” session should be closed down.

 

Keeping the Heartbeats going, e= ven after the determination that Heartbeats are failing has benefits in sup= porting additional mitigation requests, but potentially conflicts with the = DOTS requirements specification of considering a DOTS signal channel as no longer active after receipt of heartbeat respo= nses.  I know SIG-003 is the subject of another debate – do we n= eed heartbeats at all.

 

   SIG-003  Chan= nel Health Monitoring: Peer DOTS agents MUST regularly

      = send heartbeats to each other after mutual authentication in order

      = to keep the DOTS signal channel active.  A signal channel MUST be=

      = considered active until a DOTS agent explicitly ends the session,

      = or either DOTS agent fails to receive heartbeats from the other<= /span>

      = after a mutually agreed upon timeout period has elapsed.<= /p>

 

Regards

 

Jon

--_000_DM5PR16MB178829DAD60148ACF4A446EBEA5F0DM5PR16MB1788namp_-- From nobody Wed Nov 1 07:01:27 2017 Return-Path: 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 0D15513FA37 for ; Wed, 1 Nov 2017 07:01:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 3YMclygOQ-sy for ; Wed, 1 Nov 2017 07:01:20 -0700 (PDT) Received: from mail.jpshallow.com (mail.jpshallow.com [217.40.240.153]) (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 1345313F966 for ; Wed, 1 Nov 2017 07:01:20 -0700 (PDT) Received: from [127.0.0.1] (helo=N01332) by mail.jpshallow.com with smtps (TLSv1:ECDHE-RSA-AES256-SHA:256) (Exim 4.89) (envelope-from ) id 1e9ta1-0006U8-SF; Wed, 01 Nov 2017 14:01:17 +0000 From: "Jon Shallow" To: "'Konda, Tirumaleswar Reddy'" , "Mortensen, Andrew" , References: <787AE7BB302AE849A7480A190F8B93300A058A39@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93300A05E666@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93300A05E6C5@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93300A05E879@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <20171026124947.5107771.45356.38919@sandvine.com> <787AE7BB302AE849A7480A190F8B93300A05E8EA@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <71130fa2-8637-0756-a8e5-fd6e1d144e89@cisco.com> <6EDF1F8D-AA03-4275-951E-CD98047E7C03@arbor.net> <5509420C-6912-4607-B163-5C25660E943F@arbor.net> <044601d351b4$ad35be60$07a13b20$@jpshallow.com> <45176714-7846-48DE-90C5-F59ECB3A1A36@arbor.net> In-Reply-To: Date: Wed, 1 Nov 2017 14:01:18 -0000 Message-ID: <055101d35319$e4197dc0$ac4c7940$@jpshallow.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJn30ed00iE7qe0YFlJWgjFssA0bwJbZnRbAi+AMAsBWj2rLgHxtxAfAZp3c/4B7rP4RQJLUNJSAgrZIB0B9qWiOgIN6gJtAxyC0ecBPo33/AMF8UpjAbjtPRMCZ7KndgE3g/wlAWXpqWagx38xgA== Content-Language: en-gb Archived-At: Subject: Re: [Dots] DOTS & NAT (was RE: DOTS Requirements review (-06)) 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Nov 2017 14:01:27 -0000 Hi Andrew, I have been thinking this through as to how to practically implement = this, come up with some recommendations and then with some suggested = text as a possible substitute. Recommendations =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D 1) In peace time, only the DOTS Client sends heartbeats (so no need to = worry about NAT) at a lower rate 2) In attack time, both the DOTS client and DOTS server send heartbeats = (and continue to send them, even if missing heartbeat count is exceeded) 3) signal 'config' includes both peace time and attack time heartbeat = rates configuration support 4) Heartbeat rates switch over on both DOTS client and DOTS server when = mitigating, and switch back to peace time when there are no mitigation = requests My thinking behind the recommendations =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Two scenario situations * Peace time * Under attack of consequence (flooded inbound pipe) My experience is that the transition time from 'Peace time' to 'Under = attack of consequence' is very small - and once it has occurred any = traffic over the DOTS signal channel that is of CoAP type "Confirmable" = will fail. So, any signal of type 'config' will fail, but signal of = type 'mitigate' will probably get through as it is of type = 'non-confirmable'. We have determined from 'flooded inbound pipe' tests that the heartbeat = requests from the DOTS client get through to the DOTS server, but = nothing gets through to the DOTS client. So the DOTS server can = determine the session is still up and keep the session "warm" should the = DOTS client need to blindly send off a mitigation request. The caveat = here is that the DOTS client needs to continue to send heartbeat = requests even though the DOTS client has exceeded the missing heartbeat = response counts. During time of attack, to me, it is important that the heartbeats run at = a sufficient frequency to keep any NAT / stateful devices allowing = through 2-way traffic - we have generally agreed elsewhere that this = should be the order of 30 seconds, but could be shorter or longer. In peacetime, I do not believe that we need to keep state through any = NAT / stateful devices for traffic initiated by DOTS server. If the = DOTS server sends no heartbeat requests (or any other initiated = traffic), then NAT is not an issue. Any heartbeats sent by a DOTS = client should get the heartbeat responses back through a NAT / stateful = device as the RTT should not be large (certainly should be less than 30 = seconds!). The DOTS client could reduce the heartbeat frequency to, = say, once an hour (empirical guess) with no issues and the DOTS server = can keep the session open ready for attack time as it is continuing to = see the heartbeat requests. As it may not be possible to reconfigure heartbeat rates once an attack = has started, it makes some sense to me to have a peacetime heartbeat = rate (only DOTS client sends) and attack time heartbeat rate (both DOTS = client and DOTS server send). Once a DOTS server has accepted a = mitigation request, and for the continuation of the mitigation request = the attack time heartbeat rate is used. Once the mitigation request is = dropped (and there are no other active mitigation requests from the DOTS = client) then the peacetime heartbeat rate is used. Suggested Updates =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D My suggested update to SIG-003 of the requirements spec is as follows:- SIG-003 Channel Health Monitoring: DOTS agents MUST support exchange of heartbeat messages over the signal channel to monitor channel health. Peer DOTS agents SHOULD regularly send heartbeats to each other while a mitigation request is active. The heartbeat interval during active mitigation is not specified, but SHOULD be frequent enough to maintain any on-path NAT bindings during mitigation. When there is no active mitigation, there is no need = for the=20 DOTS server to send heartbeats, and the DOTS client can use a = lower=20 Heartbeat rate as then there is no requirement to maintain any = on-path NAT bindings. To support scenarios in which loss of heartbeat is used to trigger mitigation, and to keep the channel active, DOTS clients MAY solicit heartbeat exchanges after successful mutual authentication. When DOTS agents are exchanging heartbeats and no mitigation request is active, either agent MAY request changes to the heartbeat rate. For example, a DOTS server might want to delay or cease heartbeat exchanges when an active DOTS client has not requested mitigation, in order to control load. Following mutual authentication, a signal channel MUST be considered active until a DOTS agent explicitly ends the session, or either DOTS agent fails to receive heartbeats from the other after a mutually agreed upon timeout period has elapsed. Because heartbeat loss is much more likely during volumetric attack, DOTS agents SHOULD avoid signal channel termination when mitigation is active and heartbeats are not received by either DOTS agent for an extended period. In such circumstances, DOTS clients MAY attempt to reestablish the signal channel. DOTS servers SHOULD monitor the attack, using feedback from the mitigator and other available sources, and MAY use the absence of attack traffic and lack of client heartbeat requests as an indication the signal channel is = defunct. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Regards Jon From nobody Wed Nov 1 07:04:32 2017 Return-Path: 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 288E013FA25 for ; Wed, 1 Nov 2017 07:04:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.92 X-Spam-Level: X-Spam-Status: No, score=-1.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=thescout.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 JfhuXtAQD1ut for ; Wed, 1 Nov 2017 07:04:28 -0700 (PDT) Received: from NAM01-BN3-obe.outbound.protection.outlook.com (mail-bn3nam01on0096.outbound.protection.outlook.com [104.47.33.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5C7B313F966 for ; Wed, 1 Nov 2017 07:04:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=thescout.onmicrosoft.com; s=selector1-arbor-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=Wr9cI6eVOa2/NsGXkZXDUft0LJQfDXdk5lnUfMp+Jts=; b=SP2gzJg5guMySNS9grBA4i8ZDrJYUPf7Jl50S9qPZrUPRbCAr8Xd8KE7QIoq9VglaslhjMPFz/ehO9EhDZwJEavk/PhTkwuM2XGC9Fpt/rL+s0L1bVvHEETdjErhOT2OWbiZU4J+U1o2pv8IR3HD8fxL4UkXvg5pxzemCxNbZvs= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=rdobbins@arbor.net; Received: from [172.19.254.109] (184.82.228.32) by CY1PR0101MB1035.prod.exchangelabs.com (10.160.225.14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.156.4; Wed, 1 Nov 2017 14:04:25 +0000 From: "Roland Dobbins" To: "dots@ietf.org" Date: Wed, 01 Nov 2017 21:04:09 +0700 Message-ID: <79DF8659-AEEB-4B66-91EF-F2C5EC1786DD@arbor.net> In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.7r5425) X-Originating-IP: [184.82.228.32] X-ClientProxiedBy: KL1PR0601CA0023.apcprd06.prod.outlook.com (10.170.160.161) To CY1PR0101MB1035.prod.exchangelabs.com (10.160.225.14) X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: f55c86a4-0617-4ea1-59f5-08d521317667 X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(4534020)(4602075)(2017052603199); SRVR:CY1PR0101MB1035; X-Microsoft-Exchange-Diagnostics: 1; CY1PR0101MB1035; 3:MtlqkvK1gPpVRiRfq0vLkDvw37nEE+lwL+A8OLzJgkYhGO1S/5GgQrnjQZORF6PLX3tAF/0MH81NIKaSEiKCVpTT6ma8d93YLfOucm20WTwwDDBizUCTUOHen3+r4saMfpDtud+SlISjMcg28AxHVhmIb1Zco+ENuOup2T+FcTVltZi7cigrnCUd4aBvxI7W2G5vgqGKQGRAPkpV1ngOMoPmmviiuOBkU2Xdzj7Pw42sd3z1exCSDy+bMnmxvHY5; 25:xB+Mj93JiBInZ45/U6vs9aPklakUaWr3uLbaLmt3QKEaZRY5jhqZvu7bdb9yaS1OBPfUvoWJ0RJXLZcGzrzMlZyCiH0Is89ClU6v2PBulTiwYZsmDZ7GNBA/SUvUqay3jChByxuKHN0M9u7DVoQk+CaSyZK3O1A+oo1pJD/Bq2o7gG1W/iLP4mBWhLsJPmRwYFeqIgh7DbwFW3UL6FTRbmTih7a24e09+GswLwOuz0UR40jbSoHDd9q39G8nF84Zp8kDp2ac91pQJN/735WY1oHu28hRns2DEDcA4LhQB+WwrifeCQuaUpmv+7WA6lzfnyxqRHyww5GnIa3MdQJQPQ==; 31:01Xbw0izYCBhKBf35dioxck1y0GsobfbpwHLtuKLKiUVirTWZemFBxRYaGs/sOGZmeBlcVpJrl0Jrcgj1xfX2NTe0xP1FS79V7Hs8JnzBgJL8XNA13rLY6orsT9yVeARl4TK0c93+GGs7EMfkdao7ZJkl29t3RUzWQmjdqBOwoW9HlMiTq59cH8v1BMPJA2oit4tjvGjhp9tAVnHSgyhCaD9jVzKncRmxTJQmIqXgQE= X-MS-TrafficTypeDiagnostic: CY1PR0101MB1035: X-Microsoft-Exchange-Diagnostics: 1; CY1PR0101MB1035; 20:98CRsxpEpcKrr+zZMmp/OauPCD20bZc/cuKp0EwMrVZzZv+fafsf5flju+r2AL2zbqUmdrKMvid3sVYFmhXbp6dM6ZZIFH5GcseQ7Uwted5B2/m13cA8ymRMiZ8hpjalMNBbzjPPF03UFziUVurNVYDouJBdZrl2H7xxUtlgXRrcwW4AlU9qujfMQywGWee/bLj3HxAMnTuxAyX+w/GFR5baKeg8b7s/XO3gX4XOFOckifCw2tQFJzXlOpV2qFEMtnMvFq3be1fDhjN8kdSryC1atBOGTCjr16Da2qN43E+lQ5ARliS0VDpa78qaczlhin9qh50tmFGGOFJXLFhrN+JRQQgj4X2Jex6Qsu2XxWcpq0I3J/8zpCsX2KUTFA8cYDSn+ggzu+8JmekCW+i0pJyH32H7fTYMihx8U4ONcmIh2JyzhnkebfUDMs65AR/ZsR0ixJB/5HFIsKhDBRF3v7iPY8e2lZOpAHYO6FQzjjXb2tufy0JhMqChUAmBTrNa; 4:CBkepMdg9pIOFmKMiGikkLGZyaYCPu1SRnBXztar21/72askPt6pGIBa8wFFUPktS84/C9qeIukf1okbJ5rEpX0Cx5YGJfhJ60JEzkSnmrl8f0AHnuTZie/mv6Vz5lDJUMAjk/uln15ddUdPAh/VTSm5jIQN0e5EUDrvg6ib8KAdubfmJgVSlP4iPtjjb6rb996oxMwOS469IDsyXfIStRlDR8iNM6OJy5mks5ro9LTGJAoCsMwnSNBtKUX6MyWu X-Exchange-Antispam-Report-Test: UriScan:; X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(8121501046)(5005006)(93006095)(93001095)(100000703101)(100105400095)(10201501046)(3231020)(3002001)(6041248)(20161123560025)(20161123555025)(20161123564025)(20161123562025)(20161123558100)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:CY1PR0101MB1035; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:CY1PR0101MB1035; X-Forefront-PRVS: 0478C23FE0 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(6009001)(6049001)(346002)(376002)(189002)(199003)(24454002)(53936002)(16526018)(66066001)(76176999)(5003940100001)(83716003)(47776003)(189998001)(6246003)(16586007)(25786009)(478600001)(2501003)(6916009)(6666003)(86362001)(316002)(5660300001)(16576012)(97736004)(53546010)(68736007)(33656002)(8676002)(81156014)(2351001)(50226002)(101416001)(81166006)(3846002)(1730700003)(36756003)(77096006)(90366009)(50466002)(82746002)(2906002)(7736002)(106356001)(305945005)(5640700003)(6486002)(6116002)(105586002)(2950100002)(229853002)(50986999)(8936002)(67846002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR0101MB1035; H:[172.19.254.109]; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Received-SPF: None (protection.outlook.com: arbor.net does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; CY1PR0101MB1035; 23:jB+m2fnw0hZcxvftN3q24ANx4J70fkHikEKa44U?= =?us-ascii?Q?z90ZVX35c9nKYuRLBn4ILmMr5pyE5pgFusjcj+JRHLFpSjvd8uaQS1Ez1r4a?= =?us-ascii?Q?zhS+bTm0czt6W1m3TDez81syHBj83Q56xFvLDZUmzelCaiDgXugynuEahFHU?= =?us-ascii?Q?G9PaWDNltoNi3Y8W2/PfPWNEsUUxUq+FEzOQuT9olY9TbdxOra9FA7c4WcrF?= =?us-ascii?Q?EQpDTDcZMFQwaNasCq/x7cgDnJtvsE9qvjt6hokgqxjv297f3EOAuX5zw1fz?= =?us-ascii?Q?sLykIXx5uO8VzPh6mIyPp5bwMdprl06gT/kunYnviA984YqdQprLNjitvxyW?= =?us-ascii?Q?b7U5SWZL83hb6uzdJtvz8L6q5vDy9XJu+Y+fh6HVyUe8mr7+nmv6pwcjSdEm?= =?us-ascii?Q?xKVuyi4Oly66EDfGWpsMs4w+rq3QVNUKL0GNkYTXz4/sbNoREjR/88kFOrDf?= =?us-ascii?Q?wjBFqDkGOCHomatqaauD1wDV7LxaiO2r+OKsOlBrTWRTZOLJn0FiFm9PIeQN?= =?us-ascii?Q?Wjmz+v34ac2iEBTS04HlDRprDiQkJUm7HDWGg8y5QzPB0HuHvp19mufQf4NC?= =?us-ascii?Q?l/e4hMTbr3FxpQLGPK2s+4aFmIMzFsVfZDNamBFpyc/B1arf3hVnRjOJz+j6?= =?us-ascii?Q?N1NBias6fYrIcOGxplyv1vPm2k+/FkH5SJ29JJaMlUhRBIFLIrXgEgf78uu1?= =?us-ascii?Q?wjkWDAq0ZFzDMoBJQ3l9k7zy8Kg0g9pBrtIfPTbt8NX6iI3FFvzaYiBTlFye?= =?us-ascii?Q?JlqiIUowzQuYmdTRW/uJBhD86DTBdDgx6bC/LMLmQKkA+Boim4C6BU2zLoRq?= =?us-ascii?Q?CtPyirs83PAYPWu2epJlIh3JRDOZ7hTACIVzEIWONhTNRRZDjL6VxlM8dc3s?= =?us-ascii?Q?WY9SLSCLemiOmCK8hT5Gz+ADWdooe8Cf/kAh89w/X2OSwWmTk8TMK+VsJ9qh?= =?us-ascii?Q?23xTlkSKwKNeeB6BamgDuhyFVFV6ZJh4m0+MXDddFboBM9rtqdmc43w990qw?= =?us-ascii?Q?jn9b6zTZ//yitl+vJu1AOZwCTFSTyIb8Rdier95ttB9LozkfFMKIWch3EgJa?= =?us-ascii?Q?omTsd20sEx7Br9+ebFAE+N40XJkVNlRwK3HSqBagdFyDo+eMlYUKfPHiXFuh?= =?us-ascii?Q?dOsxpZYuLEcSK0a9tKMGGvLup3hzjm40bwUzgPMFNAwpgJAFJwmLNPt8v2JU?= =?us-ascii?Q?U1SjzuICHWOd95nB3MIGfWWHF/XULbJrC8pGWmq7IGW555o45HdUnBkNZvoP?= =?us-ascii?Q?hdHMAwP8hc+i01gRUsa3Yf4shzL0pUeRtx8XSIAH3qZlyhw1yS0JBrq0ETrh?= =?us-ascii?Q?az0xPN8MVSA366ER8aGqmp6Q=3D?= X-Microsoft-Exchange-Diagnostics: 1; CY1PR0101MB1035; 6:4L6Y3CXhDB/GjrLMX+9F59wU/GSXr2uPJst8XMH4yjJJly36VX4ZRgg6p5V6gHaCoHjbfaMWMNx2ANxO0mQ2n0sJibRldjJC6BzKF8Ubku3Y+zTzS3e2oP1Wb9ynqRHFcoo01WoJB9hOXpDyQACbvfLBUhiaxsT58fl7ePabWaHsgdjgLYKM2Y4r3PmXfrkF9JC38ZcQqPB3NhcxeWZxuwIQYZ+9m7fP+mnckdaGeMMjytKEA9JJ7sZEY5qZ9gpFl0ZKsi2F/9tqMh8FmofO8zJuHpfCIp7NsgzfBijUTX8O1pH9HO3XLBEivJ1ZIJjWB6HJ0suMFafiPDg/eZsTog==; 5:GtXPtCiK4rvkIYiVfPcOVe4hA2qiRzcdj3OzN1VeyxYoFM3q5EJiExsFBCvDgnauvWbEamCVuwOl9AJJT7+jScYUxWD7HI/Fox2Ue2LphaYNXGpqMhowx3C/sKSBjE4JfAkz14zAYgLLKYYaOqqS5g==; 24:zgi/ugoEzXmWfselegNwbC5rrWlofv9w+VizjWL8Y2o5BmHfvdwITEtEVOdG0rwU3aH/z61Dt75g17oTbqNAOkSfA/dpdyCFgGahd8ZfScA=; 7:2SU9Z6yBcZGwq6L6osNC3Qei/+xYuU3CsUhJJtlTbn7RAEzxI0rnkuITsiyR4Ve0hjhq0KdDJUZXCrhzFbXDbJ+Dj0DpSHifHliy5mCkV/8SIhr41DyMNyhzPZypNOFDa3Lx4L4R9YEvKTmtUG3f42OU27ub/8jpFXeLZeTehdnmOsoeQ1BPEf+3xlw4APAzkV8lj9ReCa1a0898JTq5ISVpeCIXN0neGcz0M/KHnCY= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: arbor.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 01 Nov 2017 14:04:25.8423 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: f55c86a4-0617-4ea1-59f5-08d521317667 X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 54f11205-d4aa-4809-bd36-0b542199c5b2 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR0101MB1035 Archived-At: Subject: Re: [Dots] Overlapping mitigation requests from a DOTS client 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Nov 2017 14:04:31 -0000 On 1 Nov 2017, at 20:29, Konda, Tirumaleswar Reddy wrote: > In the DOTS signal channel draft, if two mitigation requests have > overlapping mitigations scopes, then the overlapped lower number > mitigation-id is automatically deleted by the DOTS server. My view is that resolving mitigation scope overlaps are out of scope for DOTS itself. ----------------------------------- Roland Dobbins From nobody Wed Nov 1 07:29:08 2017 Return-Path: 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 6B12013F996 for ; Wed, 1 Nov 2017 07:29:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 rWFQr72hwy6o for ; Wed, 1 Nov 2017 07:29:05 -0700 (PDT) Received: from mail.jpshallow.com (mail.jpshallow.com [217.40.240.153]) (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 5D0D513FC12 for ; Wed, 1 Nov 2017 07:29:05 -0700 (PDT) Received: from [127.0.0.1] (helo=N01332) by mail.jpshallow.com with smtps (TLSv1:ECDHE-RSA-AES256-SHA:256) (Exim 4.89) (envelope-from ) id 1e9u0t-0006VC-Pc; Wed, 01 Nov 2017 14:29:03 +0000 From: "Jon Shallow" To: "'Roland Dobbins'" , References: <79DF8659-AEEB-4B66-91EF-F2C5EC1786DD@arbor.net> In-Reply-To: <79DF8659-AEEB-4B66-91EF-F2C5EC1786DD@arbor.net> Date: Wed, 1 Nov 2017 14:29:04 -0000 Message-ID: <055601d3531d$c50dcf90$4f296eb0$@jpshallow.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQH5pWUwAA9xtOo6/8WeQH4QpMhR6QFfs0lwoqfsy6A= Content-Language: en-gb Archived-At: Subject: Re: [Dots] Overlapping mitigation requests from a DOTS client 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Nov 2017 14:29:07 -0000 In one sense, I agree with Roland - but what is an overlap has been defined though. I have always struggled with what happens when a mitigation id hits the maximum value and wraps around to what will be a lower number compared to existing mitigation ids. If the DOTS client restarts, does the mitigation id get reset, or is the last mitigation id used get remembered and things move on from there etc.? If we remove the requirement for overlapping checks, then the complete list of mitigation requests may fill up RAM or a database - especially of a DOTS client goes 'rogue'. I think having a complete rollback of mitigation requests is a bit excessive - entries in the middle of the list can be deleted as well as the last or first one. Programmatically this can be done, but could get a bit messy - especially when deciding whether requests overlap or not across the entire list. Best case for me would be to retain current and previous mitigations. To me, the signalling needs to be as simple as possible, reducing the possibility of errors during attack time where requests may get dropped, appear in the wrong order etc. If a DOTS client elects to go back to the previous mitigation request (lower id) by deleting the current request, either the DOTS server has to remember the previous request, or the DOTS client issues a new mitigation requests with the previous mitigation's characteristics. I think I prefer the DOTS client issuing it as a new mitigation request - otherwise the client will need to delete the previous mitigation request at some point. ... but all the above still does not answer what happens when mitigation ids wrap back to 0! Regards Jon -----Original Message----- From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of Roland Dobbins Sent: 01 November 2017 14:04 To: dots@ietf.org Subject: Re: [Dots] Overlapping mitigation requests from a DOTS client On 1 Nov 2017, at 20:29, Konda, Tirumaleswar Reddy wrote: > In the DOTS signal channel draft, if two mitigation requests have > overlapping mitigations scopes, then the overlapped lower number > mitigation-id is automatically deleted by the DOTS server. My view is that resolving mitigation scope overlaps are out of scope for DOTS itself. ----------------------------------- Roland Dobbins _______________________________________________ Dots mailing list Dots@ietf.org https://www.ietf.org/mailman/listinfo/dots From nobody Thu Nov 2 03:02:49 2017 Return-Path: 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 5EFBC13F576 for ; Thu, 2 Nov 2017 03:02:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.001 X-Spam-Level: X-Spam-Status: No, score=-7.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham 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 wu2MF6K0XkzP for ; Thu, 2 Nov 2017 03:02:45 -0700 (PDT) Received: from MIVWSMAILOUT1.mcafee.com (mivwsmailout1.mcafee.com [161.69.47.167]) (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 5DD2C13F567 for ; Thu, 2 Nov 2017 03:02:45 -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=1509616964; 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: authentication-results:x-originating-ip:x-ms-publictraffictype: x-microsoft-exchange-diagnostics:x-ms-exchange-antispam-srfa-diagnostics: x-ms-office365-filtering-correlation-id:x-microsoft-antispam: x-ms-traffictypediagnostic:x-exchange-antispam-report-test: x-microsoft-antispam-prvs:x-exchange-antispam-report-cfa-test: x-forefront-prvs:x-forefront-antispam-report: received-spf:spamdiagnosticoutput:spamdiagnosticmetadata: 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-Transport-CrossTenantHeadersStamped: X-OriginatorOrg:X-NAI-Spam-Flag:X-NAI-Spam-Level: X-NAI-Spam-Threshold:X-NAI-Spam-Score:X-NAI-Spam-Version; bh=kuz1uNwUjV24ttiwlUYlpxEU+lxFUlHiyibUSj 6hDx0=; b=EuXAWuTEPKeGqVQxCOwcUWdTqHvhFSDjIJxs49cV y1WZCGpFYIUuHBewbXmj171Fh5QuzRSPnL0YcJHRN2iBQ1LLyI XOn5AjP6Rl3SNdRic6hAwgTMPFDApXhgiwKRz4UOXMTZ5aSx+5 bMTRRlV7JP0UU4kZE57ALju4PPRoyFo= Received: from MIVEXAPP1N01.corpzone.internalzone.com (mivexapp1n01.corpzone.internalzone.com [10.48.48.88]) by MIVWSMAILOUT1.mcafee.com with smtp id 6600_5d6e_be81ece2_c10d_40ce_993b_a8ea6161e19b; Thu, 02 Nov 2017 05:02:43 -0500 Received: from MIVEXUSR1N02.corpzone.internalzone.com (10.48.48.82) by MIVEXAPP1N01.corpzone.internalzone.com (10.48.48.88) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Thu, 2 Nov 2017 06:00:50 -0400 Received: from MIVEXUSR1N06.corpzone.internalzone.com (10.48.48.86) by MIVEXUSR1N02.corpzone.internalzone.com (10.48.48.82) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Thu, 2 Nov 2017 06:00:49 -0400 Received: from MIVO365EDGE3.corpzone.internalzone.com (10.48.176.86) by MIVEXUSR1N06.corpzone.internalzone.com (10.48.48.86) with Microsoft SMTP Server (TLS) id 15.0.1347.2 via Frontend Transport; Thu, 2 Nov 2017 06:00:49 -0400 Received: from NAM02-SN1-obe.outbound.protection.outlook.com (10.48.176.240) by edge.mcafee.com (10.48.176.86) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Thu, 2 Nov 2017 06:00:48 -0400 Received: from DM5PR16MB1788.namprd16.prod.outlook.com (10.172.44.144) by DM5PR16MB1786.namprd16.prod.outlook.com (10.172.44.142) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.178.6; Thu, 2 Nov 2017 10:00:47 +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.20.0178.015; Thu, 2 Nov 2017 10:00:47 +0000 From: "Konda, Tirumaleswar Reddy" To: Jon Shallow , 'Roland Dobbins' , "dots@ietf.org" Thread-Topic: [Dots] Overlapping mitigation requests from a DOTS client Thread-Index: AdNTEI1883tp4+lsSlOjP4a89tzzJQACbvyAAADexQAAJabbwA== Date: Thu, 2 Nov 2017 10:00:47 +0000 Message-ID: References: <79DF8659-AEEB-4B66-91EF-F2C5EC1786DD@arbor.net> <055601d3531d$c50dcf90$4f296eb0$@jpshallow.com> In-Reply-To: <055601d3531d$c50dcf90$4f296eb0$@jpshallow.com> 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: [103.245.47.20] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DM5PR16MB1786; 6:XFjocdTuCser/2m3UlxRrK1AjZ4tnn7hgm9wdf6pqvfx5MLWwQ+hPEsohKHIFAVb5OnONfQQgmNKCOwkR3+8eUC2O84qATEPHb6B6vOPbRStoBpJrmgjlhdHRc2hHIaERDYXPeuCfUgyEs9FrInBHnTb27uo/cUKg2w/upOH2CrQBWBnyq6Y0puSFiOcyA+M0HYXe/ZE+l55R9Ui+unMO6H+5WoMtDxhL/ht/CI/1fWLCi1Yk2zz/cyKHw2CCTy5vyHwBiaVB3j1SHW8Nvh82z/3W84uRwQ+PLAx23vFv/v8LKNjcendgltTFH1+9wOVPVQwh4dcFQxIBiXP4ni6Ox0aK9HjNYIZda4c80QGNTA=; 5:V9//PBEXxMABF/5z3FQxh9NtnKF+6jaxEf7RA32JWZxjvAMkJ+jRgKh0rvWoOy+d6H5gtojm/t9BnbRmWo4PfDcNoPx9NzFsvhJFRXTGLAep6Bau4y7L34L9slfTxwuZoXzezu8hHlf7zEVF0/UxPBOLEgqr9CCLUeLBERw4C3k=; 24:Y5upz3mJHSzOpmhnxJLO/SoL1ibzXtR0kwuHn45KoJAhrpobWpJ+t9M5l5lCzUEh/9ZAXR4A3lTR0T1bHoGXv8rFTw1+QesUIFQ34ry3f4U=; 7:tnP/wOe/gnFxM8cA5Xb5wSGK6E6sxMqmPV/loGumjeRxnEcv/YzOk9IcRLMZ3loFyeg3BESjcIXSGaBIV0CGzHkcaf8Zjde3PteX9Spt8EpXnvvuf7M4Xk2HF6udjAPH0V63/InaCEMkIrx2xDEgUxjIg3ph+mBvuIKaVwiBUu8DBW5dj0S0jMA8xIy1pyXyAwWlKloAxDFksAor0Ta/QssFyEdqcElISq2V5GEmaeXx4gzH7euB7GDEUUmhOdMr x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 7c9f1d6d-e246-4858-8705-08d521d89755 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(2017052603199); SRVR:DM5PR16MB1786; x-ms-traffictypediagnostic: DM5PR16MB1786: x-exchange-antispam-report-test: UriScan:(158342451672863); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(5005006)(8121501046)(100000703101)(100105400095)(3002001)(3231020)(93006095)(93001095)(10201501046)(6041248)(20161123560025)(20161123555025)(20161123564025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123562025)(20161123558100)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:DM5PR16MB1786; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:DM5PR16MB1786; x-forefront-prvs: 047999FF16 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(346002)(376002)(39830400002)(13464003)(189002)(24454002)(32952001)(199003)(25786009)(8936002)(81166006)(81156014)(3660700001)(8676002)(66066001)(305945005)(14454004)(966005)(76176999)(50986999)(54356999)(5660300001)(316002)(101416001)(74316002)(7736002)(7696004)(110136005)(97736004)(68736007)(2900100001)(2950100002)(102836003)(105586002)(6306002)(55016002)(2906002)(9686003)(189998001)(3280700002)(3846002)(80792005)(6116002)(2501003)(72206003)(106356001)(53546010)(33656002)(478600001)(229853002)(77096006)(86362001)(6436002)(53936002)(6246003)(99286004)(6506006)(85282002); DIR:OUT; SFP:1101; SCL:1; SRVR:DM5PR16MB1786; H:DM5PR16MB1788.namprd16.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; 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: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 7c9f1d6d-e246-4858-8705-08d521d89755 X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Nov 2017 10:00:47.7785 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4943e38c-6dd4-428c-886d-24932bc2d5de X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR16MB1786 X-OriginatorOrg: mcafee.com X-NAI-Spam-Flag: NO X-NAI-Spam-Level: X-NAI-Spam-Threshold: 15 X-NAI-Spam-Score: 0.1 X-NAI-Spam-Version: 2.3.0.9418 : core <6149> : inlines <6155> : streams <1769122> : uri <2526681> Archived-At: Subject: Re: [Dots] Overlapping mitigation requests from a DOTS client 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Nov 2017 10:02:47 -0000 > -----Original Message----- > From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Jon Shallow > Sent: Wednesday, November 1, 2017 7:59 PM > To: 'Roland Dobbins' ; dots@ietf.org > Subject: Re: [Dots] Overlapping mitigation requests from a DOTS client >=20 > In one sense, I agree with Roland - but what is an overlap has been defin= ed > though. >=20 > I have always struggled with what happens when a mitigation id hits the > maximum value and wraps around to what will be a lower number > compared to existing mitigation ids. If the DOTS client restarts, does t= he > mitigation id get reset, or is the last mitigation id used get remembered= and > things move on from there etc.? After restart, DOTS client can either retrieve the previously conveyed and = active mitigation requests from the DOTS server or=20 has to store the last mitigation-id number in a persistent storage.=20 >=20 > If we remove the requirement for overlapping checks, then the complete li= st > of mitigation requests may fill up RAM or a database - especially of a DO= TS > client goes 'rogue'. Agreed.=20 >=20 > I think having a complete rollback of mitigation requests is a bit excess= ive > - entries in the middle of the list can be deleted as well as the last or= first one. > Programmatically this can be done, but could get a bit messy - especially > when deciding whether requests overlap or not across the entire list. Be= st > case for me would be to retain current and previous mitigations. >=20 > To me, the signalling needs to be as simple as possible, reducing the > possibility of errors during attack time where requests may get dropped, > appear in the wrong order etc. >=20 > If a DOTS client elects to go back to the previous mitigation request (lo= wer > id) by deleting the current request, either the DOTS server has to rememb= er > the previous request, or the DOTS client issues a new mitigation requests > with the previous mitigation's characteristics. I think I prefer the DOT= S client > issuing it as a new mitigation request - otherwise the client will need t= o > delete the previous mitigation request at some point. Yes, this approach looks good. >=20 > ... but all the above still does not answer what happens when mitigation = ids > wrap back to 0 ! I don't see a problem. Mitigation-id can take up to 2**32 values before ro= lling back, mitigation-id typically will have a finite lifetime (unless ind= efinite lifetime is used) and PUT allows the client to re-use any=20 existing mitigation-id and overwrite the mitigation request with updated mi= tigation scopes. =20 -Tiru >=20 > Regards >=20 > Jon >=20 > -----Original Message----- > From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of Roland Dobbins > Sent: 01 November 2017 14:04 > To: dots@ietf.org > Subject: Re: [Dots] Overlapping mitigation requests from a DOTS client >=20 > On 1 Nov 2017, at 20:29, Konda, Tirumaleswar Reddy wrote: >=20 > > In the DOTS signal channel draft, if two mitigation requests have > > overlapping mitigations scopes, then the overlapped lower number > > mitigation-id is automatically deleted by the DOTS server. >=20 > My view is that resolving mitigation scope overlaps are out of scope for = DOTS > itself. >=20 > ----------------------------------- > Roland Dobbins >=20 > _______________________________________________ > Dots mailing list > Dots@ietf.org > https://www.ietf.org/mailman/listinfo/dots >=20 > _______________________________________________ > Dots mailing list > Dots@ietf.org > https://www.ietf.org/mailman/listinfo/dots From nobody Thu Nov 2 03:30:02 2017 Return-Path: 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 5475413F60B for ; Thu, 2 Nov 2017 03:30:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 AuEaODQNz_Ty for ; Thu, 2 Nov 2017 03:29:59 -0700 (PDT) Received: from mail.jpshallow.com (mail.jpshallow.com [217.40.240.153]) (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 193CE13F66E for ; Thu, 2 Nov 2017 03:29:59 -0700 (PDT) Received: from [127.0.0.1] (helo=N01332) by mail.jpshallow.com with smtps (TLSv1:ECDHE-RSA-AES256-SHA:256) (Exim 4.89) (envelope-from ) id 1eACl2-0007By-A8; Thu, 02 Nov 2017 10:29:56 +0000 From: "Jon Shallow" To: "'Konda, Tirumaleswar Reddy'" , "Roland Dobbins" , References: <79DF8659-AEEB-4B66-91EF-F2C5EC1786DD@arbor.net> <055601d3531d$c50dcf90$4f296eb0$@jpshallow.com> In-Reply-To: Date: Thu, 2 Nov 2017 10:29:56 -0000 Message-ID: <05cc01d353c5$87625eb0$96271c10$@jpshallow.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQH5pWUwAA9xtOo6/8WeQH4QpMhR6QFfs0lwAYQcz08C30fxbKKGI8ow Content-Language: en-gb Archived-At: Subject: Re: [Dots] Overlapping mitigation requests from a DOTS client 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Nov 2017 10:30:01 -0000 Hi Tiru, >> >> ... but all the above still does not answer what happens when >> mitigation ids wrap back to 0 ! > I don't see a problem. Mitigation-id can take up to 2**32 values before rolling back, mitigation-id typically will have a > > finite lifetime (unless indefinite lifetime is used) and PUT allows the client to re-use any > existing mitigation-id and overwrite the mitigation request with updated mitigation scopes. [5.4.1. Requesting mitigation] States " For a mitigation request to continue beyond the initial negotiated lifetime, the DOTS client need to refresh the current mitigation request by sending a new PUT request. The PUT request MUST use the same 'mitigation-id' value, and MUST repeat all the other parameters as sent in the original mitigation request apart from a possible change to the lifetime parameter value." So, my DOTS server currently rejects any PUT with a mitigation id that already exists that then has a mitigation scope change. You could user a lower mitigation id that is no longer in use to update a mitigation scope, but if there is a scope overlap, then that too will get rejected / ignored. Some of the DOTS agents are likely to be running for years, but I guess that even with a new mitigation id per second, that is about 68 years' worth, so we should be OK! Regards Jon -----Original Message----- From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of Konda, Tirumaleswar Reddy Sent: 02 November 2017 10:01 To: Jon Shallow; 'Roland Dobbins'; dots@ietf.org Subject: Re: [Dots] Overlapping mitigation requests from a DOTS client > -----Original Message----- > From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Jon Shallow > Sent: Wednesday, November 1, 2017 7:59 PM > To: 'Roland Dobbins' ; dots@ietf.org > Subject: Re: [Dots] Overlapping mitigation requests from a DOTS client > > In one sense, I agree with Roland - but what is an overlap has been > defined though. > > I have always struggled with what happens when a mitigation id hits > the maximum value and wraps around to what will be a lower number > compared to existing mitigation ids. If the DOTS client restarts, > does the mitigation id get reset, or is the last mitigation id used > get remembered and things move on from there etc.? After restart, DOTS client can either retrieve the previously conveyed and active mitigation requests from the DOTS server or has to store the last mitigation-id number in a persistent storage. > > If we remove the requirement for overlapping checks, then the complete > list of mitigation requests may fill up RAM or a database - especially > of a DOTS client goes 'rogue'. Agreed. > > I think having a complete rollback of mitigation requests is a bit > excessive > - entries in the middle of the list can be deleted as well as the last or first one. > Programmatically this can be done, but could get a bit messy - > especially when deciding whether requests overlap or not across the > entire list. Best case for me would be to retain current and previous mitigations. > > To me, the signalling needs to be as simple as possible, reducing the > possibility of errors during attack time where requests may get > dropped, appear in the wrong order etc. > > If a DOTS client elects to go back to the previous mitigation request > (lower > id) by deleting the current request, either the DOTS server has to > remember the previous request, or the DOTS client issues a new > mitigation requests with the previous mitigation's characteristics. I > think I prefer the DOTS client issuing it as a new mitigation request > - otherwise the client will need to delete the previous mitigation request at some point. Yes, this approach looks good. > > ... but all the above still does not answer what happens when > mitigation ids wrap back to 0 ! I don't see a problem. Mitigation-id can take up to 2**32 values before rolling back, mitigation-id typically will have a finite lifetime (unless indefinite lifetime is used) and PUT allows the client to re-use any existing mitigation-id and overwrite the mitigation request with updated mitigation scopes. -Tiru > > Regards > > Jon > > -----Original Message----- > From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of Roland Dobbins > Sent: 01 November 2017 14:04 > To: dots@ietf.org > Subject: Re: [Dots] Overlapping mitigation requests from a DOTS client > > On 1 Nov 2017, at 20:29, Konda, Tirumaleswar Reddy wrote: > > > In the DOTS signal channel draft, if two mitigation requests have > > overlapping mitigations scopes, then the overlapped lower number > > mitigation-id is automatically deleted by the DOTS server. > > My view is that resolving mitigation scope overlaps are out of scope > for DOTS itself. > > ----------------------------------- > Roland Dobbins > > _______________________________________________ > 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 From nobody Thu Nov 2 03:41:21 2017 Return-Path: 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 6A85913F6E6 for ; Thu, 2 Nov 2017 03:41:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.001 X-Spam-Level: X-Spam-Status: No, score=-7.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham 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 PHamBcv_SpBC for ; Thu, 2 Nov 2017 03:41:17 -0700 (PDT) Received: from MIVWSMAILOUT1.mcafee.com (mivwsmailout1.mcafee.com [161.69.47.167]) (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 13C9313F6AF for ; Thu, 2 Nov 2017 03:41:06 -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=1509619266; 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: authentication-results:x-originating-ip:x-ms-publictraffictype: x-microsoft-exchange-diagnostics:x-ms-exchange-antispam-srfa-diagnostics: x-ms-office365-filtering-correlation-id:x-microsoft-antispam: x-ms-traffictypediagnostic:x-exchange-antispam-report-test: x-microsoft-antispam-prvs:x-exchange-antispam-report-cfa-test: x-forefront-prvs:x-forefront-antispam-report: received-spf:spamdiagnosticoutput:spamdiagnosticmetadata: 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-Transport-CrossTenantHeadersStamped: X-OriginatorOrg:X-NAI-Spam-Flag:X-NAI-Spam-Level: X-NAI-Spam-Threshold:X-NAI-Spam-Score:X-NAI-Spam-Version; bh=MCRaMKRYVrmNiHiZCHWypR03ohsvDS8qK/q0/2 S69vI=; b=B+02XZRxrtz/z15MxiZ12tKUaG9tM3HmnRmPL6wJ 2zkEhAuijlg4uqjjT3PW2fGCeEk9oza+QEibDLWP+1qsJb7veT i9zrSJSB9IY5LwJz/YvxQsoXvwXOZnc2R7/4QpumMeeO+tPWee P2+MV8rVNGwySc5SNKxKFuC1UB9k8RY= Received: from MIVEXAPP1N01.corpzone.internalzone.com (unknown [10.48.48.88]) by MIVWSMAILOUT1.mcafee.com with smtp id 65fb_1ae9_90ef93ab_7a59_42f3_bd5c_7b422d68be55; Thu, 02 Nov 2017 05:41:04 -0500 Received: from MIVEXUSR1N03.corpzone.internalzone.com (10.48.48.83) by MIVEXAPP1N01.corpzone.internalzone.com (10.48.48.88) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Thu, 2 Nov 2017 06:41:04 -0400 Received: from MIVEXUSR1N05.corpzone.internalzone.com (10.48.48.85) by MIVEXUSR1N03.corpzone.internalzone.com (10.48.48.83) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Thu, 2 Nov 2017 06:41:03 -0400 Received: from MIVO365EDGE3.corpzone.internalzone.com (10.48.176.86) by MIVEXUSR1N05.corpzone.internalzone.com (10.48.48.85) with Microsoft SMTP Server (TLS) id 15.0.1347.2 via Frontend Transport; Thu, 2 Nov 2017 06:41:03 -0400 Received: from NAM02-BL2-obe.outbound.protection.outlook.com (10.48.176.240) by edge.mcafee.com (10.48.176.86) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Thu, 2 Nov 2017 06:41:02 -0400 Received: from DM5PR16MB1788.namprd16.prod.outlook.com (10.172.44.144) by DM5PR16MB1785.namprd16.prod.outlook.com (10.172.44.141) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.197.13; Thu, 2 Nov 2017 10:41:01 +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.20.0178.015; Thu, 2 Nov 2017 10:41:01 +0000 From: "Konda, Tirumaleswar Reddy" To: Jon Shallow , Roland Dobbins , "dots@ietf.org" Thread-Topic: [Dots] Overlapping mitigation requests from a DOTS client Thread-Index: AdNTEI1883tp4+lsSlOjP4a89tzzJQACbvyAAADexQAAJabbwAAESbsAAAATZiA= Date: Thu, 2 Nov 2017 10:41:01 +0000 Message-ID: References: <79DF8659-AEEB-4B66-91EF-F2C5EC1786DD@arbor.net> <055601d3531d$c50dcf90$4f296eb0$@jpshallow.com> <05cc01d353c5$87625eb0$96271c10$@jpshallow.com> In-Reply-To: <05cc01d353c5$87625eb0$96271c10$@jpshallow.com> 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: [103.245.47.20] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DM5PR16MB1785; 6:VBu2PIwwEt62zSt5/0x4VCVMD/is63Rp41J0SUtKOJWKdCOkZWDtMTb2EKOWsFgGJ93fbpboel3VC1AAfU0rh0ezreuKwCA66u8mXSRDAy+5KagG6qfqMtfJ5rTU50Re9OGwXcW/p8hFMhkC6y/LH9s2u9BMSydxaZkjNs0btN4yCwnRtRQgZIIQrTQavsyWgkhfhBTRPfoSQltf46ada4wThrRWloU+Y+A90sP93+JAJWsJYKQ51HJjx+mYnRJingMoS1NCUtPqmpYMgQyPBnRbpwdqvx3JYHb3dNFblac6edUIAKxLY4mvZYM3K+xcx39quIH3jLu+3GEMA0OpaIIpz3dKZrvc/d2dWApLIU0=; 5:c3I/t8utH2JnR3e3gE2nqpV2OHr5o/QoR0tpW2HAflJwHDBoNpiL10iVuVvSlj43nOdOe4cwBb54RQaPxE4rMlQCyGSWG9SP+peInVyh/lS0b92bGNCFjaZfv+K4BcRF4iKREBraMszcg5Vly7XsbaXF3I8CkxsEBn3GuPqsD4Y=; 24:Al3ZSzeKmhYWxCaF1vbHVDKOyjtITBEgFmbJOYokvSZLB+e7GIGCXJ1ZmlII4dUm/8/oRsykg4qDoWuvlABk7Ykutg78HpBRh5ISb4SfBts=; 7:9TgmSGbbNH4H1SGycc5ApkD6P3XAUpOkmNTnux+G6NtztraEdHkgRw3Ng765PwJqFfUgp9OS39y2+DcKTCbnEdsLJEcbRizwzgKZFTpJIeRn8q5UXewWhQeQ3r1eroNWm4MfWIDJu4P8Rj5yt0IJnu+yMXE0Md/lEX8HH6Ify68AkdFGPLBrhJF2eJBGqG+MxI9dvoToncgP7qcybkZT46j09MQ5DkXvloMTxMBzDilMw33VKZ/CWGvULg1SeppP x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 21ef3d2a-da5d-4b7f-62c9-08d521de3634 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(2017052603199); SRVR:DM5PR16MB1785; x-ms-traffictypediagnostic: DM5PR16MB1785: x-exchange-antispam-report-test: UriScan:(158342451672863)(123452027830198); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(5005006)(8121501046)(93006095)(93001095)(10201501046)(3231020)(100000703101)(100105400095)(3002001)(6041248)(20161123560025)(20161123562025)(20161123558100)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123564025)(20161123555025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:DM5PR16MB1785; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:DM5PR16MB1785; x-forefront-prvs: 047999FF16 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(979002)(6009001)(376002)(346002)(189002)(24454002)(13464003)(199003)(32952001)(7696004)(97736004)(2906002)(86362001)(189998001)(3280700002)(33656002)(50986999)(68736007)(3846002)(6116002)(102836003)(76176999)(6436002)(54356999)(14454004)(77096006)(305945005)(8936002)(80792005)(101416001)(3660700001)(93886005)(9686003)(99286004)(53936002)(478600001)(7736002)(110136005)(966005)(74316002)(6246003)(5660300001)(72206003)(2501003)(66066001)(55016002)(6506006)(106356001)(316002)(81156014)(81166006)(2950100002)(25786009)(8676002)(2900100001)(53546010)(6306002)(105586002)(229853002)(85282002)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1101; SCL:1; SRVR:DM5PR16MB1785; H:DM5PR16MB1788.namprd16.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; 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: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 21ef3d2a-da5d-4b7f-62c9-08d521de3634 X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Nov 2017 10:41:01.6933 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4943e38c-6dd4-428c-886d-24932bc2d5de X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR16MB1785 X-OriginatorOrg: mcafee.com X-NAI-Spam-Flag: NO X-NAI-Spam-Level: X-NAI-Spam-Threshold: 15 X-NAI-Spam-Score: 0.1 X-NAI-Spam-Version: 2.3.0.9418 : core <6149> : inlines <6155> : streams <1769125> : uri <2526698> Archived-At: Subject: Re: [Dots] Overlapping mitigation requests from a DOTS client 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Nov 2017 10:41:19 -0000 > -----Original Message----- > From: Jon Shallow [mailto:supjps-ietf@jpshallow.com] > Sent: Thursday, November 2, 2017 4:00 PM > To: Konda, Tirumaleswar Reddy ; > Roland Dobbins ; dots@ietf.org > Subject: RE: [Dots] Overlapping mitigation requests from a DOTS client >=20 > Hi Tiru, >=20 > >> > >> ... but all the above still does not answer what happens when > >> mitigation ids wrap back to 0 ! >=20 > > I don't see a problem. Mitigation-id can take up to 2**32 values > > before > rolling back, mitigation-id typically will have a > > finite lifetime (un= less > indefinite lifetime is used) and PUT allows the client to re-use any >=20 > > existing mitigation-id and overwrite the mitigation request with > > updated > mitigation scopes. >=20 > [5.4.1. Requesting mitigation] States >=20 > " For a mitigation request to continue beyond the initial negotiated > lifetime, the DOTS client need to refresh the current mitigation > request by sending a new PUT request. The PUT request MUST use the > same 'mitigation-id' value, and MUST repeat all the other parameters > as sent in the original mitigation request apart from a possible > change to the lifetime parameter value." >=20 > So, my DOTS server currently rejects any PUT with a mitigation id that al= ready > exists that then has a mitigation scope change. I don't think this behavior is correct, PUT allows the DOTS client to chang= e the mitigation scope for a mitigation-id.=20 "MUST" is used in the above line only to suggest that mitigation scope must= not be changed when only refreshing the lifetime of the mitigation request= .=20 >=20 > You could user a lower mitigation id that is no longer in use to update a > mitigation scope, but if there is a scope overlap, then that too will get > rejected / ignored. Some of the DOTS agents are likely to be running for > years, but I guess that even with a new mitigation id per second, that is= about > 68 years' worth, so we should be OK! :)=20 -Tiru >=20 > Regards >=20 > Jon >=20 > -----Original Message----- > From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of Konda, > Tirumaleswar Reddy > Sent: 02 November 2017 10:01 > To: Jon Shallow; 'Roland Dobbins'; dots@ietf.org > Subject: Re: [Dots] Overlapping mitigation requests from a DOTS client >=20 > > -----Original Message----- > > From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Jon Shallow > > Sent: Wednesday, November 1, 2017 7:59 PM > > To: 'Roland Dobbins' ; dots@ietf.org > > Subject: Re: [Dots] Overlapping mitigation requests from a DOTS client > > > > In one sense, I agree with Roland - but what is an overlap has been > > defined though. > > > > I have always struggled with what happens when a mitigation id hits > > the maximum value and wraps around to what will be a lower number > > compared to existing mitigation ids. If the DOTS client restarts, > > does the mitigation id get reset, or is the last mitigation id used > > get remembered and things move on from there etc.? >=20 > After restart, DOTS client can either retrieve the previously conveyed an= d > active mitigation requests from the DOTS server or has to store the last > mitigation-id number in a persistent storage. >=20 > > > > If we remove the requirement for overlapping checks, then the complete > > list of mitigation requests may fill up RAM or a database - especially > > of a DOTS client goes 'rogue'. >=20 > Agreed. >=20 > > > > I think having a complete rollback of mitigation requests is a bit > > excessive > > - entries in the middle of the list can be deleted as well as the last > > or > first one. > > Programmatically this can be done, but could get a bit messy - > > especially when deciding whether requests overlap or not across the > > entire list. Best case for me would be to retain current and previous > mitigations. > > > > To me, the signalling needs to be as simple as possible, reducing the > > possibility of errors during attack time where requests may get > > dropped, appear in the wrong order etc. > > > > If a DOTS client elects to go back to the previous mitigation request > > (lower > > id) by deleting the current request, either the DOTS server has to > > remember the previous request, or the DOTS client issues a new > > mitigation requests with the previous mitigation's characteristics. I > > think I prefer the DOTS client issuing it as a new mitigation request > > - otherwise the client will need to delete the previous mitigation > > request > at some point. >=20 > Yes, this approach looks good. >=20 >=20 > > > > ... but all the above still does not answer what happens when > > mitigation ids wrap back to 0 ! >=20 > I don't see a problem. Mitigation-id can take up to 2**32 values before > rolling back, mitigation-id typically will have a finite lifetime (unless= indefinite > lifetime is used) and PUT allows the client to re-use any existing mitiga= tion-id > and overwrite the mitigation request with updated > mitigation scopes. >=20 > -Tiru >=20 > > > > Regards > > > > Jon > > > > -----Original Message----- > > From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of Roland Dobbins > > Sent: 01 November 2017 14:04 > > To: dots@ietf.org > > Subject: Re: [Dots] Overlapping mitigation requests from a DOTS client > > > > On 1 Nov 2017, at 20:29, Konda, Tirumaleswar Reddy wrote: > > > > > In the DOTS signal channel draft, if two mitigation requests have > > > overlapping mitigations scopes, then the overlapped lower number > > > mitigation-id is automatically deleted by the DOTS server. > > > > My view is that resolving mitigation scope overlaps are out of scope > > for DOTS itself. > > > > ----------------------------------- > > Roland Dobbins > > > > _______________________________________________ > > 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 >=20 > _______________________________________________ > Dots mailing list > Dots@ietf.org > https://www.ietf.org/mailman/listinfo/dots From nobody Thu Nov 2 03:51:35 2017 Return-Path: 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 66F3D13F60B for ; Thu, 2 Nov 2017 03:51:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.001 X-Spam-Level: X-Spam-Status: No, score=-7.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham 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 ofXESjaMemge for ; Thu, 2 Nov 2017 03:51:31 -0700 (PDT) Received: from MIVWSMAILOUT1.mcafee.com (mivwsmailout1.mcafee.com [161.69.47.167]) (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 5F8D813F67D for ; Thu, 2 Nov 2017 03:51:31 -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=1509619890; 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: x-originating-ip:x-ms-publictraffictype:x-microsoft-exchange-diagnostics: x-ms-exchange-antispam-srfa-diagnostics:x-ms-office365-filtering-correlation-id: x-microsoft-antispam:x-ms-traffictypediagnostic: authentication-results:x-exchange-antispam-report-test: x-microsoft-antispam-prvs:x-exchange-antispam-report-cfa-test: x-forefront-prvs:x-forefront-antispam-report: received-spf:spamdiagnosticoutput:spamdiagnosticmetadata: 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-Transport-CrossTenantHeadersStamped: X-OriginatorOrg:X-NAI-Spam-Flag:X-NAI-Spam-Level: X-NAI-Spam-Threshold:X-NAI-Spam-Score:X-NAI-Spam-Version; bh=zctJysvQk1UZ1vgQ+0+m1q6htQS1sOXCMbem2e wsefE=; b=UOUaIiOicDuZaoJyNEBNQOa6oPj6nIIiy83xq/ps NPwmKVNDqvMW4Bj2+w3rz+eQerb9Ez+dGZfbNZs64kreLJJLiO xRq/gDFpxUwqVWstT4nOYbAzpfS2uBrVLtV3WKIA29HV4s6K/w pXxUxy0wQ5B/LHyg05V5zIHP8jOlTww= Received: from MIVEXAPP1N01.corpzone.internalzone.com (unknown [10.48.48.88]) by MIVWSMAILOUT1.mcafee.com with smtp id 6600_711f_9729213b_a85f_46b0_b423_f4466d7222b7; Thu, 02 Nov 2017 05:51:30 -0500 Received: from MIVEXUSR1N03.corpzone.internalzone.com (10.48.48.83) by MIVEXAPP1N01.corpzone.internalzone.com (10.48.48.88) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Thu, 2 Nov 2017 06:48:41 -0400 Received: from MIVEXUSR1N04.corpzone.internalzone.com (10.48.48.84) by MIVEXUSR1N03.corpzone.internalzone.com (10.48.48.83) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Thu, 2 Nov 2017 06:48:40 -0400 Received: from MIVO365EDGE4.corpzone.internalzone.com (10.48.176.87) by MIVEXUSR1N04.corpzone.internalzone.com (10.48.48.84) with Microsoft SMTP Server (TLS) id 15.0.1347.2 via Frontend Transport; Thu, 2 Nov 2017 06:48:40 -0400 Received: from NAM01-BY2-obe.outbound.protection.outlook.com (10.48.176.240) by edge.mcafee.com (10.48.176.87) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Thu, 2 Nov 2017 06:48:39 -0400 Received: from DM5PR16MB1788.namprd16.prod.outlook.com (10.172.44.144) by DM5PR16MB1788.namprd16.prod.outlook.com (10.172.44.144) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.178.6; Thu, 2 Nov 2017 10:48:38 +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.20.0178.015; Thu, 2 Nov 2017 10:48:38 +0000 From: "Konda, Tirumaleswar Reddy" To: Jon Shallow , "Mortensen, Andrew" , "dots@ietf.org" Thread-Topic: [Dots] DOTS & NAT (was RE: DOTS Requirements review (-06)) Thread-Index: AQHTTmDj2RAQrm+kS0aEpR2RXflMS6L2Wo6AgAAK6QCABl/TAIAAB00AgAAgpICAAL/IEIAB6gIAgAFRomA= Date: Thu, 2 Nov 2017 10:48:38 +0000 Message-ID: References: <787AE7BB302AE849A7480A190F8B93300A058A39@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93300A05E666@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93300A05E6C5@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93300A05E879@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <20171026124947.5107771.45356.38919@sandvine.com> <787AE7BB302AE849A7480A190F8B93300A05E8EA@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <71130fa2-8637-0756-a8e5-fd6e1d144e89@cisco.com> <6EDF1F8D-AA03-4275-951E-CD98047E7C03@arbor.net> <5509420C-6912-4607-B163-5C25660E943F@arbor.net> <044601d351b4$ad35be60$07a13b20$@jpshallow.com> <45176714-7846-48DE-90C5-F59ECB3A1A36@arbor.net> <055101d35319$e4197dc0$ac4c7940$@jpshallow.com> In-Reply-To: <055101d35319$e4197dc0$ac4c7940$@jpshallow.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [103.245.47.20] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DM5PR16MB1788; 6:/wRt+TdyXHKGIU2F+uT5TLSqEsb7YmdE+mzaRW8ggAl1KvgG/iLEhdXoTQuHE0GhL+WpcloDkkg124/OSOwTjfqrkL3/FNV4DQ4m9IOp0hh0d/W7ml/7PRkaPiEDifkROtVaZZFzI+1/PgsdT9r/178bO/5tJU8nOEZzayByj9or1qyHbh67Lq9CqveED/tt68ZddGqlJLETAeIcwgvVkzxmyZStQkKIadsWAJmZoeMaOjI7blR+rw9BaB5Puuqmgsi1JPUhhGviZPcVa3dgKflwut11QvBunl7nesBm0YOEFtJdtvW2ZxzMpuPVOXqHrA18uh+rxGWKCWC+amTWsawKeql1tdr+FU6TbpoiCBE=; 5:XM+BI9n3fxZTCp6G9+2yejYV08Ya2a5y4Rc+frMunWDpeLTyhRNdDJR5HbU4+oS8G3rD+wrkVymcgiiblM9MZQKPi1s6WsjzQ5xWhOJYFCgodQhPg16cgmD9LYGhO+gjT0NZTTWcVSTYrMKdPk8jaskkVmAN7AsS1O3zsSU6lis=; 24:Mv15HCc65bgpKAYDUoMHVELDG0uVDIyWIpP4HQrq+83L57j7ENqEYQ8bW1SApwB/KORvHfzI3+/pueXBlJgMozcq0blTkla6CyJPCsm+DxQ=; 7:NKFOxfi9yMAeJFlJNJWi7ZEFjIDRipvVGUA7L0aCcxUg7ssIYYD7h65W74bZ4PHxoHFL8vSsJKAndcLlZZw8kyf9VAGcMs21tu50xNlVmbJn6H2idftg5P02QfMu9QCIM0UHnUVWp9MLgBsPdYHdpS8UC+UtGg/YtUVYtdaRFkqiff/BG+D6hbE5fYGSbepAvLWmbVt7J6F5EfVKLT4jk2fGG3IZaxwoovpm86aiYh5cUVCwqz/ppPufDAOpFwXN x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 4fffa364-85cb-4b63-fd4d-08d521df4653 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(2017052603238); SRVR:DM5PR16MB1788; x-ms-traffictypediagnostic: DM5PR16MB1788: authentication-results: spf=none (sender IP is ) smtp.mailfrom=TirumaleswarReddy_Konda@McAfee.com; x-exchange-antispam-report-test: UriScan:(158342451672863)(278428928389397)(72170088055959)(123452027830198); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(8121501046)(5005006)(93006095)(93001095)(3002001)(10201501046)(100000703101)(100105400095)(3231020)(6041248)(20161123564025)(20161123555025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123560025)(20161123558100)(20161123562025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:DM5PR16MB1788; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:DM5PR16MB1788; x-forefront-prvs: 047999FF16 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(376002)(346002)(32952001)(13464003)(199003)(189002)(97736004)(68736007)(14454004)(77096006)(966005)(3846002)(102836003)(6116002)(6506006)(6436002)(72206003)(478600001)(101416001)(229853002)(9686003)(99286004)(3660700001)(54356999)(6306002)(2906002)(25786009)(2501003)(76176999)(50986999)(93886005)(3280700002)(33656002)(74316002)(7696004)(189998001)(53546010)(305945005)(2900100001)(105586002)(7736002)(2950100002)(6246003)(86362001)(316002)(53936002)(5660300001)(80792005)(55016002)(8676002)(110136005)(81166006)(8936002)(81156014)(106356001)(66066001)(85282002); DIR:OUT; SFP:1101; SCL:1; SRVR:DM5PR16MB1788; H:DM5PR16MB1788.namprd16.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: McAfee.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 4fffa364-85cb-4b63-fd4d-08d521df4653 X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Nov 2017 10:48:38.3032 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4943e38c-6dd4-428c-886d-24932bc2d5de X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR16MB1788 X-OriginatorOrg: mcafee.com X-NAI-Spam-Flag: NO X-NAI-Spam-Level: X-NAI-Spam-Threshold: 15 X-NAI-Spam-Score: 0.1 X-NAI-Spam-Version: 2.3.0.9418 : core <6149> : inlines <6155> : streams <1769125> : uri <2526702> Archived-At: Subject: Re: [Dots] DOTS & NAT (was RE: DOTS Requirements review (-06)) 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Nov 2017 10:51:33 -0000 Pi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IEpvbiBTaGFsbG93IFttYWlsdG86 c3VwanBzLWlldGZAanBzaGFsbG93LmNvbV0NCj4gU2VudDogV2VkbmVzZGF5LCBOb3ZlbWJlciAx LCAyMDE3IDc6MzEgUE0NCj4gVG86IEtvbmRhLCBUaXJ1bWFsZXN3YXIgUmVkZHkgPFRpcnVtYWxl c3dhclJlZGR5X0tvbmRhQE1jQWZlZS5jb20+Ow0KPiBNb3J0ZW5zZW4sIEFuZHJldyA8YW1vcnRl bnNlbkBhcmJvci5uZXQ+OyBkb3RzQGlldGYub3JnDQo+IFN1YmplY3Q6IFJFOiBbRG90c10gRE9U UyAmIE5BVCAod2FzIFJFOiBET1RTIFJlcXVpcmVtZW50cyByZXZpZXcgKC0wNikpDQo+IA0KPiBI aSBBbmRyZXcsDQo+IA0KPiBJIGhhdmUgYmVlbiB0aGlua2luZyB0aGlzIHRocm91Z2ggYXMgdG8g aG93IHRvIHByYWN0aWNhbGx5IGltcGxlbWVudCB0aGlzLA0KPiBjb21lIHVwIHdpdGggc29tZSBy ZWNvbW1lbmRhdGlvbnMgYW5kIHRoZW4gd2l0aCBzb21lIHN1Z2dlc3RlZCB0ZXh0IGFzDQo+IGEg cG9zc2libGUgc3Vic3RpdHV0ZS4NCj4gDQo+IFJlY29tbWVuZGF0aW9ucw0KPiA9PT09PT09PT09 PT09PT0NCj4gDQo+IDEpIEluIHBlYWNlIHRpbWUsIG9ubHkgdGhlIERPVFMgQ2xpZW50IHNlbmRz IGhlYXJ0YmVhdHMgKHNvIG5vIG5lZWQgdG8gd29ycnkNCj4gYWJvdXQgTkFUKSBhdCBhIGxvd2Vy IHJhdGUNCj4gMikgSW4gYXR0YWNrIHRpbWUsIGJvdGggdGhlIERPVFMgY2xpZW50IGFuZCBET1RT IHNlcnZlciBzZW5kIGhlYXJ0YmVhdHMgKGFuZA0KPiBjb250aW51ZSB0byBzZW5kIHRoZW0sIGV2 ZW4gaWYgbWlzc2luZyBoZWFydGJlYXQgY291bnQgaXMgZXhjZWVkZWQpDQo+IDMpIHNpZ25hbCAn Y29uZmlnJyBpbmNsdWRlcyBib3RoIHBlYWNlIHRpbWUgYW5kIGF0dGFjayB0aW1lIGhlYXJ0YmVh dCByYXRlcw0KPiBjb25maWd1cmF0aW9uIHN1cHBvcnQNCj4gNCkgSGVhcnRiZWF0IHJhdGVzIHN3 aXRjaCBvdmVyIG9uIGJvdGggRE9UUyBjbGllbnQgYW5kIERPVFMgc2VydmVyIHdoZW4NCj4gbWl0 aWdhdGluZywgYW5kIHN3aXRjaCBiYWNrIHRvIHBlYWNlIHRpbWUgd2hlbiB0aGVyZSBhcmUgbm8g bWl0aWdhdGlvbg0KPiByZXF1ZXN0cw0KPiANCj4gTXkgdGhpbmtpbmcgYmVoaW5kIHRoZSByZWNv bW1lbmRhdGlvbnMNCj4gPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0NCj4gDQo+ IFR3byBzY2VuYXJpbyBzaXR1YXRpb25zDQo+ICogUGVhY2UgdGltZQ0KPiAqIFVuZGVyIGF0dGFj ayBvZiBjb25zZXF1ZW5jZSAoZmxvb2RlZCBpbmJvdW5kIHBpcGUpDQo+IA0KPiBNeSBleHBlcmll bmNlIGlzIHRoYXQgdGhlIHRyYW5zaXRpb24gdGltZSBmcm9tICdQZWFjZSB0aW1lJyB0byAnVW5k ZXIgYXR0YWNrDQo+IG9mIGNvbnNlcXVlbmNlJyBpcyB2ZXJ5IHNtYWxsIC0gYW5kIG9uY2UgaXQg aGFzIG9jY3VycmVkIGFueSB0cmFmZmljIG92ZXIgdGhlDQo+IERPVFMgc2lnbmFsIGNoYW5uZWwg dGhhdCBpcyBvZiBDb0FQIHR5cGUgIkNvbmZpcm1hYmxlIiB3aWxsIGZhaWwuICBTbywgYW55DQo+ IHNpZ25hbCBvZiB0eXBlICdjb25maWcnIHdpbGwgZmFpbCwgYnV0IHNpZ25hbCBvZiB0eXBlICdt aXRpZ2F0ZScgd2lsbCBwcm9iYWJseSBnZXQNCj4gdGhyb3VnaCBhcyBpdCBpcyBvZiB0eXBlICdu b24tY29uZmlybWFibGUnLg0KDQpJdCBkZXBlbmRzIG9uIHRoZSB0eXBlIG9mIEREb1MgYXR0YWNr LCBJbiBjYXNlIG9mIHNsb3dsb3JpcyBERG9TIGF0dGFjaywgdGhlIGluY29taW5nIGxpbmsgdG8g dGhlIERPVFMgY2xpZW50IHdpbGwgbW9zdCBsaWtlbHkgbm90IGJlIHNhdHVyYXRlZC4NCkluIGFk ZGl0aW9uLCBpbiBzb21lIGRlcGxveW1lbnRzLCB3aGVyZSBVRFAgaXMgYmxvY2tlZCwgRE9UUy1v dmVyLVRDUCBpcyByZXF1aXJlZC4NCg0KPiANCj4gV2UgaGF2ZSBkZXRlcm1pbmVkIGZyb20gJ2Zs b29kZWQgaW5ib3VuZCBwaXBlJyB0ZXN0cyB0aGF0IHRoZSBoZWFydGJlYXQNCj4gcmVxdWVzdHMg ZnJvbSB0aGUgRE9UUyBjbGllbnQgZ2V0IHRocm91Z2ggdG8gdGhlIERPVFMgc2VydmVyLCBidXQg bm90aGluZw0KPiBnZXRzIHRocm91Z2ggdG8gdGhlIERPVFMgY2xpZW50LiAgU28gdGhlIERPVFMg c2VydmVyIGNhbiBkZXRlcm1pbmUgdGhlDQo+IHNlc3Npb24gaXMgc3RpbGwgdXAgYW5kIGtlZXAg dGhlIHNlc3Npb24gIndhcm0iIHNob3VsZCB0aGUgRE9UUyBjbGllbnQgbmVlZA0KPiB0byBibGlu ZGx5IHNlbmQgb2ZmIGEgbWl0aWdhdGlvbiByZXF1ZXN0LiAgVGhlIGNhdmVhdCBoZXJlIGlzIHRo YXQgdGhlIERPVFMNCj4gY2xpZW50IG5lZWRzIHRvIGNvbnRpbnVlIHRvIHNlbmQgaGVhcnRiZWF0 IHJlcXVlc3RzIGV2ZW4gdGhvdWdoIHRoZSBET1RTDQo+IGNsaWVudCBoYXMgZXhjZWVkZWQgdGhl IG1pc3NpbmcgaGVhcnRiZWF0IHJlc3BvbnNlIGNvdW50cy4NCg0KWWVzLCB0aGlzIG1lY2hhbmlz bSBpcyBkaXNjdXNzZWQgaW4gdGhlIG5leHQgcmUtdmVyc2lvbi4gDQoNCj4gDQo+IER1cmluZyB0 aW1lIG9mIGF0dGFjaywgdG8gbWUsIGl0IGlzIGltcG9ydGFudCB0aGF0IHRoZSBoZWFydGJlYXRz IHJ1biBhdCBhDQo+IHN1ZmZpY2llbnQgZnJlcXVlbmN5IHRvIGtlZXAgYW55IE5BVCAvIHN0YXRl ZnVsIGRldmljZXMgYWxsb3dpbmcgdGhyb3VnaCAyLQ0KPiB3YXkgdHJhZmZpYyAtIHdlIGhhdmUg Z2VuZXJhbGx5IGFncmVlZCBlbHNld2hlcmUgdGhhdCB0aGlzIHNob3VsZCBiZSB0aGUNCj4gb3Jk ZXIgb2YgMzAgc2Vjb25kcywgYnV0IGNvdWxkIGJlIHNob3J0ZXIgb3IgbG9uZ2VyLg0KPiANCj4g SW4gcGVhY2V0aW1lLCBJIGRvIG5vdCBiZWxpZXZlIHRoYXQgd2UgbmVlZCB0byBrZWVwIHN0YXRl IHRocm91Z2ggYW55IE5BVCAvDQo+IHN0YXRlZnVsIGRldmljZXMgZm9yIHRyYWZmaWMgaW5pdGlh dGVkIGJ5IERPVFMgc2VydmVyLiAgSWYgdGhlIERPVFMgc2VydmVyIHNlbmRzDQo+IG5vIGhlYXJ0 YmVhdCByZXF1ZXN0cyAob3IgYW55IG90aGVyIGluaXRpYXRlZCB0cmFmZmljKSwgdGhlbiBOQVQg aXMgbm90IGFuIGlzc3VlLg0KPiBBbnkgaGVhcnRiZWF0cyBzZW50IGJ5IGEgRE9UUyBjbGllbnQg c2hvdWxkIGdldCB0aGUgaGVhcnRiZWF0IHJlc3BvbnNlcw0KPiBiYWNrIHRocm91Z2ggYSBOQVQg LyBzdGF0ZWZ1bCBkZXZpY2UgYXMgdGhlIFJUVCBzaG91bGQgbm90IGJlIGxhcmdlIChjZXJ0YWlu bHkNCj4gc2hvdWxkIGJlIGxlc3MgdGhhbiAzMCBzZWNvbmRzISkuICBUaGUgRE9UUyBjbGllbnQg Y291bGQgcmVkdWNlIHRoZQ0KPiBoZWFydGJlYXQgZnJlcXVlbmN5IHRvLCBzYXksIG9uY2UgYW4g aG91ciAoZW1waXJpY2FsIGd1ZXNzKSB3aXRoIG5vIGlzc3Vlcw0KPiBhbmQgdGhlIERPVFMgc2Vy dmVyIGNhbiBrZWVwIHRoZSBzZXNzaW9uIG9wZW4gcmVhZHkgZm9yIGF0dGFjayB0aW1lIGFzIGl0 IGlzDQo+IGNvbnRpbnVpbmcgdG8gc2VlIHRoZSBoZWFydGJlYXQgcmVxdWVzdHMuDQoNClRoZSBE T1RTIHNlcnZlciBhbHNvIG5lZWRzIHRvIHBlcmZvcm0gaGVhcnRiZWF0IGNoZWNrcyB0byBkZXRl Y3QgYW5kIGRlbGV0ZSBkZWZ1bmN0IERPVFMgc2Vzc2lvbiwgb3RoZXJ3aXNlIHRoZSBET1RTIHNl cnZlciBjb3VsZCBlbmQtdXAgY29uc3VtaW5nIGNyeXB0b2dyYXBoaWMgc3RhdGUgDQpmb3IgRE9U UyBzZXNzaW9uIGFicnVwdGx5IGRpc2Nvbm5lY3RlZCBieSB0aGUgRE9UUyBjbGllbnQuIFBsZWFz ZSBzZWUgdGhlIFVEUCB1c2FnZSBiZXN0IHByYWN0aWNlcyBpbiBodHRwczovL3Rvb2xzLmlldGYu b3JnL2h0bWwvcmZjODA4NSANCg0KPHNuaXA+DQogICBBIFVEUCBhcHBsaWNhdGlvbiB3aXRoIGEg bG9uZy1saXZlZCBhc3NvY2lhdGlvbiBiZXR3ZWVuIHRoZSBzZW5kZXINCiAgIGFuZCByZWNlaXZl ciwgb3VnaHQgdG8gYmUgZGVzaWduZWQgc28gdGhhdCB0aGUgc2VuZGVyIHBlcmlvZGljYWxseQ0K ICAgY2hlY2tzIHRoYXQgdGhlIHJlY2VpdmVyIHN0aWxsIHdhbnRzICgiY29uc2VudHMiKSB0byBy ZWNlaXZlIHRyYWZmaWMNCiAgIGFuZCBuZWVkIHRvIGJlIGRlc2lnbmVkIHRvIHN0b3AgaWYgdGhl cmUgaXMgbm8gZXhwbGljaXQgY29uZmlybWF0aW9uDQogICBvZiB0aGlzIFtSRkM3Njc1XS4gIEFw cGxpY2F0aW9ucyB0aGF0IHJlcXVpcmUgY29tbXVuaWNhdGlvbnMgaW4gdHdvDQogICBkaXJlY3Rp b25zIHRvIGltcGxlbWVudCBwcm90b2NvbCBmdW5jdGlvbnMgKHN1Y2ggYXMgcmVsaWFiaWxpdHkg b3INCiAgIGNvbmdlc3Rpb24gY29udHJvbCkgd2lsbCBuZWVkIHRvIGluZGVwZW5kZW50bHkgY2hl Y2sgYm90aCBkaXJlY3Rpb25zDQogICBvZiBjb21tdW5pY2F0aW9uLCBhbmQgbWF5IGhhdmUgdG8g ZXhjaGFuZ2Uga2VlcC1hbGl2ZSBtZXNzYWdlcyB0bw0KICAgdHJhdmVyc2UgbWlkZGxlYm94ZXMg KHNlZSBTZWN0aW9uIDMuNSkuDQoNCj4gDQo+IEFzIGl0IG1heSBub3QgYmUgcG9zc2libGUgdG8g cmVjb25maWd1cmUgaGVhcnRiZWF0IHJhdGVzIG9uY2UgYW4gYXR0YWNrIGhhcw0KPiBzdGFydGVk LCBpdCBtYWtlcyBzb21lIHNlbnNlIHRvIG1lIHRvIGhhdmUgYSBwZWFjZXRpbWUgaGVhcnRiZWF0 IHJhdGUgKG9ubHkNCj4gRE9UUyBjbGllbnQgc2VuZHMpIGFuZCBhdHRhY2sgdGltZSBoZWFydGJl YXQgcmF0ZSAoYm90aCBET1RTIGNsaWVudCBhbmQNCj4gRE9UUyBzZXJ2ZXIgc2VuZCkuICBPbmNl IGEgRE9UUyBzZXJ2ZXIgaGFzIGFjY2VwdGVkIGEgbWl0aWdhdGlvbiByZXF1ZXN0LA0KPiBhbmQg Zm9yIHRoZSBjb250aW51YXRpb24gb2YgdGhlIG1pdGlnYXRpb24gcmVxdWVzdCB0aGUgYXR0YWNr IHRpbWUgaGVhcnRiZWF0DQo+IHJhdGUgaXMgdXNlZC4gIE9uY2UgdGhlIG1pdGlnYXRpb24gcmVx dWVzdCBpcyBkcm9wcGVkIChhbmQgdGhlcmUgYXJlIG5vIG90aGVyDQo+IGFjdGl2ZSBtaXRpZ2F0 aW9uIHJlcXVlc3RzIGZyb20gdGhlIERPVFMgY2xpZW50KSB0aGVuIHRoZSBwZWFjZXRpbWUNCj4g aGVhcnRiZWF0IHJhdGUgaXMgdXNlZC4NCg0KSSBkb24ndCB1bmRlcnN0YW5kIHRoZSBuZWVkIGZv ciBkaWZmZXJlbnQgaGVhcnRiZWF0IHJhdGVzLiANCldoYXQgcHJvYmxlbXMgZG8geW91IHNlZSB3 aXRoIHRoZSBjdXJyZW50IG1lY2hhbmlzbSA/DQoNCi1UaXJ1DQoNCj4gDQo+IFN1Z2dlc3RlZCBV cGRhdGVzDQo+ID09PT09PT09PT09PT09PT0NCj4gDQo+IE15IHN1Z2dlc3RlZCB1cGRhdGUgdG8g U0lHLTAwMyBvZiB0aGUgcmVxdWlyZW1lbnRzIHNwZWMgaXMgYXMgZm9sbG93czotDQo+IA0KPiAg ICBTSUctMDAzICBDaGFubmVsIEhlYWx0aCBNb25pdG9yaW5nOiBET1RTIGFnZW50cyBNVVNUIHN1 cHBvcnQgZXhjaGFuZ2UNCj4gICAgICAgb2YgaGVhcnRiZWF0IG1lc3NhZ2VzIG92ZXIgdGhlIHNp Z25hbCBjaGFubmVsIHRvIG1vbml0b3IgY2hhbm5lbA0KPiAgICAgICBoZWFsdGguICBQZWVyIERP VFMgYWdlbnRzIFNIT1VMRCByZWd1bGFybHkgc2VuZCBoZWFydGJlYXRzIHRvIGVhY2gNCj4gICAg ICAgb3RoZXIgd2hpbGUgYSBtaXRpZ2F0aW9uIHJlcXVlc3QgaXMgYWN0aXZlLiAgVGhlIGhlYXJ0 YmVhdA0KPiAgICAgICBpbnRlcnZhbCBkdXJpbmcgYWN0aXZlIG1pdGlnYXRpb24gaXMgbm90IHNw ZWNpZmllZCwgYnV0IFNIT1VMRCBiZQ0KPiAgICAgICBmcmVxdWVudCBlbm91Z2ggdG8gbWFpbnRh aW4gYW55IG9uLXBhdGggTkFUIGJpbmRpbmdzIGR1cmluZw0KPiAgICAgICBtaXRpZ2F0aW9uLiAg V2hlbiB0aGVyZSBpcyBubyBhY3RpdmUgbWl0aWdhdGlvbiwgdGhlcmUgaXMgbm8gbmVlZCBmb3Ig dGhlDQo+ICAgICAgIERPVFMgc2VydmVyIHRvIHNlbmQgaGVhcnRiZWF0cywgYW5kIHRoZSBET1RT IGNsaWVudCBjYW4gdXNlIGEgbG93ZXINCj4gICAgICAgSGVhcnRiZWF0IHJhdGUgYXMgdGhlbiB0 aGVyZSBpcyBubyByZXF1aXJlbWVudCB0byBtYWludGFpbiBhbnkgb24tcGF0aA0KPiAgICAgICBO QVQgYmluZGluZ3MuDQo+IA0KPiAgICAgICBUbyBzdXBwb3J0IHNjZW5hcmlvcyBpbiB3aGljaCBs b3NzIG9mIGhlYXJ0YmVhdCBpcyB1c2VkIHRvIHRyaWdnZXINCj4gICAgICAgbWl0aWdhdGlvbiwg YW5kIHRvIGtlZXAgdGhlIGNoYW5uZWwgYWN0aXZlLCBET1RTIGNsaWVudHMgTUFZDQo+ICAgICAg IHNvbGljaXQgaGVhcnRiZWF0IGV4Y2hhbmdlcyBhZnRlciBzdWNjZXNzZnVsIG11dHVhbA0KPiAg ICAgICBhdXRoZW50aWNhdGlvbi4gIFdoZW4gRE9UUyBhZ2VudHMgYXJlIGV4Y2hhbmdpbmcgaGVh cnRiZWF0cyBhbmQgbm8NCj4gICAgICAgbWl0aWdhdGlvbiByZXF1ZXN0IGlzIGFjdGl2ZSwgZWl0 aGVyIGFnZW50IE1BWSByZXF1ZXN0IGNoYW5nZXMgdG8NCj4gICAgICAgdGhlIGhlYXJ0YmVhdCBy YXRlLiAgRm9yIGV4YW1wbGUsIGEgRE9UUyBzZXJ2ZXIgbWlnaHQgd2FudCB0bw0KPiAgICAgICBk ZWxheSBvciBjZWFzZSBoZWFydGJlYXQgZXhjaGFuZ2VzIHdoZW4gYW4gYWN0aXZlIERPVFMgY2xp ZW50IGhhcw0KPiAgICAgICBub3QgcmVxdWVzdGVkIG1pdGlnYXRpb24sIGluIG9yZGVyIHRvIGNv bnRyb2wgbG9hZC4NCj4gDQo+ICAgICAgIEZvbGxvd2luZyBtdXR1YWwgYXV0aGVudGljYXRpb24s IGEgc2lnbmFsIGNoYW5uZWwgTVVTVCBiZQ0KPiAgICAgICBjb25zaWRlcmVkIGFjdGl2ZSB1bnRp bCBhIERPVFMgYWdlbnQgZXhwbGljaXRseSBlbmRzIHRoZSBzZXNzaW9uLA0KPiAgICAgICBvciBl aXRoZXIgRE9UUyBhZ2VudCBmYWlscyB0byByZWNlaXZlIGhlYXJ0YmVhdHMgZnJvbSB0aGUgb3Ro ZXINCj4gICAgICAgYWZ0ZXIgYSBtdXR1YWxseSBhZ3JlZWQgdXBvbiB0aW1lb3V0IHBlcmlvZCBo YXMgZWxhcHNlZC4gIEJlY2F1c2UNCj4gICAgICAgaGVhcnRiZWF0IGxvc3MgaXMgbXVjaCBtb3Jl IGxpa2VseSBkdXJpbmcgdm9sdW1ldHJpYyBhdHRhY2ssIERPVFMNCj4gICAgICAgYWdlbnRzIFNI T1VMRCBhdm9pZCBzaWduYWwgY2hhbm5lbCB0ZXJtaW5hdGlvbiB3aGVuIG1pdGlnYXRpb24gaXMN Cj4gICAgICAgYWN0aXZlIGFuZCBoZWFydGJlYXRzIGFyZSBub3QgcmVjZWl2ZWQgYnkgZWl0aGVy IERPVFMgYWdlbnQgZm9yIGFuDQo+ICAgICAgIGV4dGVuZGVkIHBlcmlvZC4gIEluIHN1Y2ggY2ly Y3Vtc3RhbmNlcywgRE9UUyBjbGllbnRzIE1BWSBhdHRlbXB0DQo+ICAgICAgIHRvIHJlZXN0YWJs aXNoIHRoZSBzaWduYWwgY2hhbm5lbC4gIERPVFMgc2VydmVycyBTSE9VTEQgbW9uaXRvcg0KPiAg ICAgICB0aGUgYXR0YWNrLCB1c2luZyBmZWVkYmFjayBmcm9tIHRoZSBtaXRpZ2F0b3IgYW5kIG90 aGVyIGF2YWlsYWJsZQ0KPiAgICAgICBzb3VyY2VzLCBhbmQgTUFZIHVzZSB0aGUgYWJzZW5jZSBv ZiBhdHRhY2sgdHJhZmZpYyBhbmQgbGFjayBvZg0KPiAgICAgICBjbGllbnQgaGVhcnRiZWF0IHJl cXVlc3RzIGFzIGFuIGluZGljYXRpb24gdGhlIHNpZ25hbCBjaGFubmVsIGlzIGRlZnVuY3QuDQo+ IA0KPiA9PT09PT09PT09DQo+IA0KPiBSZWdhcmRzDQo+IA0KPiBKb24NCg0K From nobody Thu Nov 2 04:25:16 2017 Return-Path: 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 0E18C139982 for ; Thu, 2 Nov 2017 04:25:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 SbP3M_l3QzMC for ; Thu, 2 Nov 2017 04:25:13 -0700 (PDT) Received: from mail.jpshallow.com (mail.jpshallow.com [217.40.240.153]) (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 94D4E13F6FB for ; Thu, 2 Nov 2017 04:25:01 -0700 (PDT) Received: from [127.0.0.1] (helo=N01332) by mail.jpshallow.com with smtps (TLSv1:ECDHE-RSA-AES256-SHA:256) (Exim 4.89) (envelope-from ) id 1eADcJ-0007EL-Qz; Thu, 02 Nov 2017 11:24:59 +0000 From: "Jon Shallow" To: "'Konda, Tirumaleswar Reddy'" , "Roland Dobbins" , References: <79DF8659-AEEB-4B66-91EF-F2C5EC1786DD@arbor.net> <055601d3531d$c50dcf90$4f296eb0$@jpshallow.com> <05cc01d353c5$87625eb0$96271c10$@jpshallow.com> In-Reply-To: Date: Thu, 2 Nov 2017 11:25:00 -0000 Message-ID: <05d401d353cd$386af0d0$a940d270$@jpshallow.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQH5pWUwAA9xtOo6/8WeQH4QpMhR6QFfs0lwAYQcz08C30fxbAKiZgegAitscJuiX8LcwA== Content-Language: en-gb Archived-At: Subject: Re: [Dots] Overlapping mitigation requests from a DOTS client 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Nov 2017 11:25:15 -0000 Hi Tiru, I am having programmatic challenges here with your comment. Case 1: PUT request for same mitigation-id is identical (apart from maybe lifetime) Mitigation is refreshed for another lifetime seconds(or infinite if -1). Case 2: PUT request for same mitigation-id has a new mitigation scope - lifetime may or may not be different Old mitigation is overwritten with new scope parameters - is the mitigation lifetime refreshed for another lifetime seconds, or the remaining time of the mitigation left unchanged? If the mitigation lifetime is refreshed, then why do we need Case 1: with a MUST? There is a second potential issue with Case 2 - what if there is a later mitigation-id also active - no overlap conflicts with original scope, but then has an overlap conflict with the replacement scope - do we auto-delete the mitigation-id that was just updated? Regards Jon -----Original Message----- From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of Konda, Tirumaleswar Reddy Sent: 02 November 2017 10:41 To: Jon Shallow; Roland Dobbins; dots@ietf.org Subject: Re: [Dots] Overlapping mitigation requests from a DOTS client > -----Original Message----- > From: Jon Shallow [mailto:supjps-ietf@jpshallow.com] > Sent: Thursday, November 2, 2017 4:00 PM > To: Konda, Tirumaleswar Reddy ; > Roland Dobbins ; dots@ietf.org > Subject: RE: [Dots] Overlapping mitigation requests from a DOTS client > > Hi Tiru, > > >> > >> ... but all the above still does not answer what happens when > >> mitigation ids wrap back to 0 ! > > > I don't see a problem. Mitigation-id can take up to 2**32 values > > before > rolling back, mitigation-id typically will have a > > finite lifetime > (unless indefinite lifetime is used) and PUT allows the client to > re-use any > > > existing mitigation-id and overwrite the mitigation request with > > updated > mitigation scopes. > > [5.4.1. Requesting mitigation] States > > " For a mitigation request to continue beyond the initial negotiated > lifetime, the DOTS client need to refresh the current mitigation > request by sending a new PUT request. The PUT request MUST use the > same 'mitigation-id' value, and MUST repeat all the other parameters > as sent in the original mitigation request apart from a possible > change to the lifetime parameter value." > > So, my DOTS server currently rejects any PUT with a mitigation id that > already exists that then has a mitigation scope change. I don't think this behavior is correct, PUT allows the DOTS client to change the mitigation scope for a mitigation-id. "MUST" is used in the above line only to suggest that mitigation scope must not be changed when only refreshing the lifetime of the mitigation request. > > You could user a lower mitigation id that is no longer in use to > update a mitigation scope, but if there is a scope overlap, then that > too will get rejected / ignored. Some of the DOTS agents are likely > to be running for years, but I guess that even with a new mitigation > id per second, that is about > 68 years' worth, so we should be OK! :) -Tiru From nobody Thu Nov 2 05:02:43 2017 Return-Path: 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 5BD8B13F619 for ; Thu, 2 Nov 2017 05:02:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 ZPSTTacUO1tJ for ; Thu, 2 Nov 2017 05:02:39 -0700 (PDT) Received: from mail.jpshallow.com (mail.jpshallow.com [217.40.240.153]) (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 49ADF13F5E1 for ; Thu, 2 Nov 2017 05:02:39 -0700 (PDT) Received: from [127.0.0.1] (helo=N01332) by mail.jpshallow.com with smtps (TLSv1:ECDHE-RSA-AES256-SHA:256) (Exim 4.89) (envelope-from ) id 1eAECj-0007GC-Ig; Thu, 02 Nov 2017 12:02:37 +0000 From: "Jon Shallow" To: "'Konda, Tirumaleswar Reddy'" , "Mortensen, Andrew" , References: <787AE7BB302AE849A7480A190F8B93300A058A39@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93300A05E666@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93300A05E6C5@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93300A05E879@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <20171026124947.5107771.45356.38919@sandvine.com> <787AE7BB302AE849A7480A190F8B93300A05E8EA@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <71130fa2-8637-0756-a8e5-fd6e1d144e89@cisco.com> <6EDF1F8D-AA03-4275-951E-CD98047E7C03@arbor.net> <5509420C-6912-4607-B163-5C25660E943F@arbor.net> <044601d351b4$ad35be60$07a13b20$@jpshallow.com> <45176714-7846-48DE-90C5-F59ECB3A1A36@arbor.net> <055101d35319$e4197dc0$ac4c7940$@jpshallow.com> In-Reply-To: Date: Thu, 2 Nov 2017 12:02:38 -0000 Message-ID: <05d901d353d2$7a1fac50$6e5f04f0$@jpshallow.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJn30ed00iE7qe0YFlJWgjFssA0bwJbZnRbAi+AMAsBWj2rLgHxtxAfAZp3c/4B7rP4RQJLUNJSAgrZIB0B9qWiOgIN6gJtAxyC0ecBPo33/AG8vKxTAbjtPRMCZ7KndgE3g/wlAWXpqWYBoAYacgH+q8UEoLZbzcA= Content-Language: en-gb Archived-At: Subject: Re: [Dots] DOTS & NAT (was RE: DOTS Requirements review (-06)) 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Nov 2017 12:02:42 -0000 Hi Tiru, See inline. Regards Jon -----Original Message----- From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of Konda, Tirumaleswar Reddy Sent: 02 November 2017 10:49 To: Jon Shallow; Mortensen, Andrew; dots@ietf.org Subject: Re: [Dots] DOTS & NAT (was RE: DOTS Requirements review (-06)) >-----Original Message----- > From: Jon Shallow [mailto:supjps-ietf@jpshallow.com] > Sent: Wednesday, November 1, 2017 7:31 PM > To: Konda, Tirumaleswar Reddy ; > Mortensen, Andrew ; dots@ietf.org > Subject: RE: [Dots] DOTS & NAT (was RE: DOTS Requirements review >(-06)) > > Hi Andrew, > > I have been thinking this through as to how to practically implement > this, come up with some recommendations and then with some suggested > text as a possible substitute. > > Recommendations > =============== > > 1) In peace time, only the DOTS Client sends heartbeats (so no need to > worry about NAT) at a lower rate > 2) In attack time, both the DOTS client and DOTS server send > heartbeats (and continue to send them, even if missing heartbeat count > is exceeded) > 3) signal 'config' includes both peace time and attack time heartbeat > rates configuration support > 4) Heartbeat rates switch over on both DOTS client and DOTS server > when mitigating, and switch back to peace time when there are no > mitigation requests > > My thinking behind the recommendations > =================================== > > Two scenario situations > * Peace time > * Under attack of consequence (flooded inbound pipe) > > My experience is that the transition time from 'Peace time' to 'Under > attack of consequence' is very small - and once it has occurred any > traffic over the DOTS signal channel that is of CoAP type > "Confirmable" will fail. So, any signal of type 'config' will fail, > but signal of type 'mitigate' will probably get through as it is of type 'non-confirmable'. It depends on the type of DDoS attack, In case of slowloris DDoS attack, the incoming link to the DOTS client will most likely not be saturated. In addition, in some deployments, where UDP is blocked, DOTS-over-TCP is required. Jon> If the link is not saturated then DOTS will continue to work as expected. I am thinking of the boundary conditions - an example being pipe full where DOTS still needs to be functional. Jon> Agreed - CoAP over TLS is not ideal and is likely to fail under boundary conditions. > > We have determined from 'flooded inbound pipe' tests that the > heartbeat requests from the DOTS client get through to the DOTS > server, but nothing gets through to the DOTS client. So the DOTS > server can determine the session is still up and keep the session > "warm" should the DOTS client need to blindly send off a mitigation > request. The caveat here is that the DOTS client needs to continue to > send heartbeat requests even though the DOTS client has exceeded the missing heartbeat response counts. Yes, this mechanism is discussed in the next re-version. > > During time of attack, to me, it is important that the heartbeats run > at a sufficient frequency to keep any NAT / stateful devices allowing > through 2- way traffic - we have generally agreed elsewhere that this > should be the order of 30 seconds, but could be shorter or longer. > > In peacetime, I do not believe that we need to keep state through any > NAT / stateful devices for traffic initiated by DOTS server. If the > DOTS server sends no heartbeat requests (or any other initiated traffic), then NAT is not an issue. > Any heartbeats sent by a DOTS client should get the heartbeat > responses back through a NAT / stateful device as the RTT should not > be large (certainly should be less than 30 seconds!). The DOTS client > could reduce the heartbeat frequency to, say, once an hour (empirical > guess) with no issues and the DOTS server can keep the session open > ready for attack time as it is continuing to see the heartbeat requests. The DOTS server also needs to perform heartbeat checks to detect and delete defunct DOTS session, otherwise the DOTS server could end-up consuming cryptographic state for DOTS session abruptly disconnected by the DOTS client. Please see the UDP usage best practices in https://tools.ietf.org/html/rfc8085 Jon> If the DOTS server fails to see a heartbeat CoAP ping request from the DOTS client within the agreed heartbeat repeat rate * some factor (suggestion 2 * + tolerance to handle a missing heartbeat), then the session can be declared as dead. I would also expect the DOTS client to be sending a session close at the DTLS level if the client is going away (obviously not if the client crashes!). A UDP application with a long-lived association between the sender and receiver, ought to be designed so that the sender periodically checks that the receiver still wants ("consents") to receive traffic and need to be designed to stop if there is no explicit confirmation of this [RFC7675]. Applications that require communications in two directions to implement protocol functions (such as reliability or congestion control) will need to independently check both directions of communication, and may have to exchange keep-alive messages to traverse middleboxes (see Section 3.5). > > As it may not be possible to reconfigure heartbeat rates once an > attack has started, it makes some sense to me to have a peacetime > heartbeat rate (only DOTS client sends) and attack time heartbeat rate > (both DOTS client and DOTS server send). Once a DOTS server has > accepted a mitigation request, and for the continuation of the > mitigation request the attack time heartbeat rate is used. Once the > mitigation request is dropped (and there are no other active > mitigation requests from the DOTS client) then the peacetime heartbeat rate is used. I don't understand the need for different heartbeat rates. What problems do you see with the current mechanism ? Jon> When mitigation is active, heartbeats need to be running at a rate that keeps traffic flowing through middleboxes that may be NAT devices. In peace time, this is creating a lot of chit-chat that is not really needed and could be slowed down (some people appear to be saying that they want no or very little heartbeats). If the rate becomes less frequent than the recognized 30 seconds (even though RFC recommendations are for higher values) the DOTS server will start to suffer heartbeat failure if traffic is passing through a NAT device. Jon> By there being two different sets of heartbeat values (which could be the same values) and which set is used is based on whether mitigating or not removes the need for having to do a CON Configuration change whilst under attack to set the required heartbeat parameters for the attack conditions. -Tiru > > Suggested Updates > ================ > > My suggested update to SIG-003 of the requirements spec is as > follows:- > > SIG-003 Channel Health Monitoring: DOTS agents MUST support exchange > of heartbeat messages over the signal channel to monitor channel > health. Peer DOTS agents SHOULD regularly send heartbeats to each > other while a mitigation request is active. The heartbeat > interval during active mitigation is not specified, but SHOULD be > frequent enough to maintain any on-path NAT bindings during > mitigation. When there is no active mitigation, there is no need for the > DOTS server to send heartbeats, and the DOTS client can use a lower > Heartbeat rate as then there is no requirement to maintain any on-path > NAT bindings. > > To support scenarios in which loss of heartbeat is used to trigger > mitigation, and to keep the channel active, DOTS clients MAY > solicit heartbeat exchanges after successful mutual > authentication. When DOTS agents are exchanging heartbeats and no > mitigation request is active, either agent MAY request changes to > the heartbeat rate. For example, a DOTS server might want to > delay or cease heartbeat exchanges when an active DOTS client has > not requested mitigation, in order to control load. > > Following mutual authentication, a signal channel MUST be > considered active until a DOTS agent explicitly ends the session, > or either DOTS agent fails to receive heartbeats from the other > after a mutually agreed upon timeout period has elapsed. Because > heartbeat loss is much more likely during volumetric attack, DOTS > agents SHOULD avoid signal channel termination when mitigation is > active and heartbeats are not received by either DOTS agent for an > extended period. In such circumstances, DOTS clients MAY attempt > to reestablish the signal channel. DOTS servers SHOULD monitor > the attack, using feedback from the mitigator and other available > sources, and MAY use the absence of attack traffic and lack of > client heartbeat requests as an indication the signal channel is defunct. > > ========== > > Regards > > Jon _______________________________________________ Dots mailing list Dots@ietf.org https://www.ietf.org/mailman/listinfo/dots From nobody Thu Nov 2 07:08:17 2017 Return-Path: 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 5415413F893 for ; Thu, 2 Nov 2017 07:08:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 JGaRWEMNfaJ3 for ; Thu, 2 Nov 2017 07:08:14 -0700 (PDT) Received: from mail.jpshallow.com (mail.jpshallow.com [217.40.240.153]) (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 D26C513F884 for ; Thu, 2 Nov 2017 07:08:13 -0700 (PDT) Received: from [127.0.0.1] (helo=N01332) by mail.jpshallow.com with smtps (TLSv1:ECDHE-RSA-AES256-SHA:256) (Exim 4.89) (envelope-from ) id 1eAGAG-0007K4-C5 for ietf-supjps-dots@ietf.org; Thu, 02 Nov 2017 14:08:12 +0000 From: "Jon Shallow" To: Date: Thu, 2 Nov 2017 14:08:12 -0000 Message-ID: <05e701d353e4$052ab450$0f801cf0$@jpshallow.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_05E8_01D353E4.052B5090" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdNT5AOFWju5GZ2ZR+C6vVHgMupOHQ== Content-Language: en-gb Archived-At: Subject: [Dots] Availability of DOTS Server 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Nov 2017 14:08:16 -0000 This is a multipart message in MIME format. ------=_NextPart_000_05E8_01D353E4.052B5090 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit As mentioned at the last DOTS Virtual Meeting, I would aim to get a DOTS server up and running to test against. It has taken a bit longer than I said - so apologies for that. The DOTS server is hosted at dotsserver.ddos-secure.net , listening on ports 5684 and 4646 for CoAP over both DTLS and TLS. The data channel is not currently available, but should be shortly. At present, you can come in from any IP address, but need to use the Client and CA certificates that provided as part of the nttdots project for authentication (https://github.com/nttdots/go-dots/tree/master/certs) . It is on my ToDo list to use a different set of certificates. Thanks to nttdots for making the current set of certificates available. The DOTS server will accept mitigation requests for 1.1.1.69, 1.1.1.71, and 1.1.2.0/24 It is possible the server may go down briefly - when we update the s/w - but should be for no more than a minute. The server supports signal draft -06, as well as the changes so far in https://github.com/dotswg/dots-signal-channel/blob/master/draft-ietf-dots-si gnal-channel-07.txt. You should get back CoAP diagnostic messages saying what is failing for troubleshooting at both ends. I have logging enabled at my end. We also have a working DOTS client which can be pointed to an external DOTS server for testing - we need a client cert + key for that. Some of the DOTS gateway "glue" is in place. Regards Jon ------=_NextPart_000_05E8_01D353E4.052B5090 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

As = mentioned at the last DOTS Virtual Meeting, I would aim to get a DOTS = server up and running to test against.  It has taken a bit longer = than I said – so apologies for that.

 

The DOTS = server is hosted at dotsserver.ddos-secure.net , listening on ports 5684 = and 4646 for CoAP over both DTLS and TLS.

 

The data = channel is not currently available, but should be = shortly.

 

At present, you can come in from any IP address, but = need to use the Client and CA certificates that provided as part of the = nttdots project for authentication (https://git= hub.com/nttdots/go-dots/tree/master/certs) .  It is on my ToDo = list to use a different set of certificates.  Thanks to nttdots for = making the current set of certificates available.

 

The DOTS = server will accept mitigation requests for 1.1.1.69, 1.1.1.71, and = 1.1.2.0/24

 

It is possible the server may go down briefly – = when we update the s/w - but should be for no more than a = minute.

 

The server supports signal draft -06, as well as the = changes so far in https://github.com/dotswg/dots-signal-cha= nnel/blob/master/draft-ietf-dots-signal-channel-07.txt.

 

You = should get back CoAP diagnostic messages saying what is failing for = troubleshooting at both ends.  I have logging enabled at my = end.

 

We also have a working DOTS client which can be = pointed to an external DOTS server for testing – we need a client = cert + key for that.  Some of the DOTS gateway “glue” = is in place.

 

Regards

 

Jon

 

------=_NextPart_000_05E8_01D353E4.052B5090-- From nobody Thu Nov 2 08:37:10 2017 Return-Path: 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 2BA3A13FAB3 for ; Thu, 2 Nov 2017 08:37:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.001 X-Spam-Level: X-Spam-Status: No, score=-7.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham 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 2K3ggzAIuDUU for ; Thu, 2 Nov 2017 08:37:06 -0700 (PDT) Received: from MIVWSMAILOUT1.mcafee.com (mivwsmailout1.mcafee.com [161.69.47.167]) (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 E91D313FAB8 for ; Thu, 2 Nov 2017 08:37:05 -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=1509637024; 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: authentication-results:x-originating-ip:x-ms-publictraffictype: x-microsoft-exchange-diagnostics:x-ms-exchange-antispam-srfa-diagnostics: x-ms-office365-filtering-correlation-id:x-microsoft-antispam: x-ms-traffictypediagnostic:x-exchange-antispam-report-test: x-microsoft-antispam-prvs:x-exchange-antispam-report-cfa-test: x-forefront-prvs:x-forefront-antispam-report: received-spf:spamdiagnosticoutput:spamdiagnosticmetadata: 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-Transport-CrossTenantHeadersStamped: X-OriginatorOrg:X-NAI-Spam-Flag:X-NAI-Spam-Level: X-NAI-Spam-Threshold:X-NAI-Spam-Score:X-NAI-Spam-Version; bh=HCTx/XcVbZEHbx9WfjPXlXggDNHc5opr24jsKm pjQKE=; b=hWs60wPAZc6Ex+/0A54pHWS9Sa0pJW0mbB4pGph2 zZav2wpqmGW8j/bOT1h4Muxw7kVl6fOGM7gp/g6aJzECYxmUi1 9xumSaquMFt0KMXqrUwHuVf4cBRVCcONXMNAQJZiK3Tis1Lmb6 Fja+22T4/3ug697oHcp9tG4wYZI9VkA= Received: from MIVEXAPP1N01.corpzone.internalzone.com (unknown [10.48.48.88]) by MIVWSMAILOUT1.mcafee.com with smtp id 7f3d_0ff6_c1d6531a_78e8_4693_b370_1d8df33885bf; Thu, 02 Nov 2017 10:37:03 -0500 Received: from MIVEXUSR1N06.corpzone.internalzone.com (10.48.48.86) by MIVEXAPP1N01.corpzone.internalzone.com (10.48.48.88) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Thu, 2 Nov 2017 11:36:53 -0400 Received: from MIVEXUSR1N05.corpzone.internalzone.com (10.48.48.85) by MIVEXUSR1N06.corpzone.internalzone.com (10.48.48.86) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Thu, 2 Nov 2017 11:36:52 -0400 Received: from MIVO365EDGE3.corpzone.internalzone.com (10.48.176.86) by MIVEXUSR1N05.corpzone.internalzone.com (10.48.48.85) with Microsoft SMTP Server (TLS) id 15.0.1347.2 via Frontend Transport; Thu, 2 Nov 2017 11:36:52 -0400 Received: from NAM01-SN1-obe.outbound.protection.outlook.com (10.48.176.240) by edge.mcafee.com (10.48.176.86) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Thu, 2 Nov 2017 11:36:50 -0400 Received: from DM5PR16MB1788.namprd16.prod.outlook.com (10.172.44.144) by DM5PR16MB1785.namprd16.prod.outlook.com (10.172.44.141) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.197.13; Thu, 2 Nov 2017 15:36:50 +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.20.0178.015; Thu, 2 Nov 2017 15:36:50 +0000 From: "Konda, Tirumaleswar Reddy" To: Jon Shallow , Roland Dobbins , "dots@ietf.org" Thread-Topic: [Dots] Overlapping mitigation requests from a DOTS client Thread-Index: AdNTEI1883tp4+lsSlOjP4a89tzzJQACbvyAAADexQAAJabbwAAESbsAAAATZiAAAdjwAAAILJRA Date: Thu, 2 Nov 2017 15:36:49 +0000 Message-ID: References: <79DF8659-AEEB-4B66-91EF-F2C5EC1786DD@arbor.net> <055601d3531d$c50dcf90$4f296eb0$@jpshallow.com> <05cc01d353c5$87625eb0$96271c10$@jpshallow.com> <05d401d353cd$386af0d0$a940d270$@jpshallow.com> In-Reply-To: <05d401d353cd$386af0d0$a940d270$@jpshallow.com> 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: [122.167.140.78] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DM5PR16MB1785; 6:y+A85moKlocFdfVlKh++sbqfKShYFmd9g7B4mX2/fRngI2kNYX9PQQcNd+dJfgdNzc8X1bRQpZsKlqf0EIF4hzW+WITTTHOklA5+0Xms4KaqJy3MAZbkbE8gfbHjzJaMz+RbZ5PMWYP/bh5jhuC7LpWvOHt11xQJ2qjtZdOFYvPNZaTGa2/P7jmqeYw8IVQXp15FBsBdn4wGbjsOsSDFInHbBd1geH7m9+cD3XK7dpf7qM0yJwb0ZB1Cs/trjAVfgyBCZnG2lIn6FcAhiwqTw3O9wptVNJiLBjjcZAeVrdHF7s3xjNPcRM5C9uyJvgt6QYQqHmCTltDP1KEbUJvOArQOkB6Xgv71KMs+Zn/GNr4=; 5:qtLSzLb/lYS8798/w67/cu+117HA3tu1JiHoCfWV4e0SnR5Z27jFqN7RYdqBGQUDh+YKgFWt3Zt2l9Nk9LXrq11mzIf5373CQIQlASgf3xsAuaptzdnHMhsR1nwYQgzpyyXzPhwIpgmHpYlwZ3pqTq/QSTOzytrqvJi5HeX/UEU=; 24:98pLKScZBAU2M06x/tcKKml1bu4jk2g9W0hRsYTJ1LdZKTFSFXTMw/zjMPtdcEed33rtuSQyfQSLS9oeM1cMvqXjgqoJyOpNUdbQYjWq6Gs=; 7:hzhbOzkRAqjIn3m7rK1K2yPEVm8QXu8vr2CEpg66LqB6vFQY15srcq1BmAP4RbQASOUPG0TfwOYfYqs1Sg26cJCLJ2pI8CBLxxntrQeYZ7C/Qm9WOzqvm7o6PsRPa7a7AuNT1UOSDk1orz68HvHs3si/CHa4/l70LnbfLt3F4qJnBWV/b/etxMK8cg9WgBbXL8RSp26JgDAFLVdPZG9FiSEBbLRnPe3YzzaVce3N5C3jYmlUKdvOJXQOdRmLPFBR x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 05ad6c5c-e9d9-4245-edb0-08d522078903 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(2017052603199); SRVR:DM5PR16MB1785; x-ms-traffictypediagnostic: DM5PR16MB1785: x-exchange-antispam-report-test: UriScan:(158342451672863)(123452027830198); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(5005006)(8121501046)(93006095)(93001095)(10201501046)(3231020)(100000703101)(100105400095)(3002001)(6041248)(20161123560025)(20161123562025)(20161123558100)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123555025)(20161123564025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:DM5PR16MB1785; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:DM5PR16MB1785; x-forefront-prvs: 047999FF16 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(376002)(346002)(189002)(13464003)(57704003)(199003)(32952001)(7696004)(2906002)(76176999)(86362001)(189998001)(97736004)(3280700002)(68736007)(33656002)(50986999)(3846002)(6116002)(102836003)(54356999)(14454004)(77096006)(8936002)(305945005)(80792005)(101416001)(3660700001)(93886005)(6436002)(9686003)(99286004)(53936002)(478600001)(110136005)(7736002)(966005)(74316002)(6246003)(5660300001)(72206003)(6506006)(2501003)(66066001)(55016002)(316002)(106356001)(81166006)(2950100002)(81156014)(25786009)(8676002)(2900100001)(53546010)(6306002)(105586002)(229853002)(85282002); DIR:OUT; SFP:1101; SCL:1; SRVR:DM5PR16MB1785; H:DM5PR16MB1788.namprd16.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; 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: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 05ad6c5c-e9d9-4245-edb0-08d522078903 X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Nov 2017 15:36:49.9769 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4943e38c-6dd4-428c-886d-24932bc2d5de X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR16MB1785 X-OriginatorOrg: mcafee.com X-NAI-Spam-Flag: NO X-NAI-Spam-Level: X-NAI-Spam-Threshold: 15 X-NAI-Spam-Score: 0.1 X-NAI-Spam-Version: 2.3.0.9418 : core <6150> : inlines <6155> : streams <1769142> : uri <2526826> Archived-At: Subject: Re: [Dots] Overlapping mitigation requests from a DOTS client 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Nov 2017 15:37:08 -0000 > -----Original Message----- > From: Jon Shallow [mailto:supjps-ietf@jpshallow.com] > Sent: Thursday, November 2, 2017 4:55 PM > To: Konda, Tirumaleswar Reddy ; > Roland Dobbins ; dots@ietf.org > Subject: RE: [Dots] Overlapping mitigation requests from a DOTS client >=20 > Hi Tiru, >=20 > I am having programmatic challenges here with your comment. >=20 > Case 1: PUT request for same mitigation-id is identical (apart from maybe > lifetime) >=20 > Mitigation is refreshed for another lifetime seconds(or infinite if -1). >=20 > Case 2: PUT request for same mitigation-id has a new mitigation scope - > lifetime may or may not be different >=20 > Old mitigation is overwritten with new scope parameters - is the mitigati= on > lifetime refreshed for another lifetime seconds, or the remaining time of= the > mitigation left unchanged? >=20 > If the mitigation lifetime is refreshed, then why do we need Case 1: wit= h a > MUST? PUT allows the resources to be updated (see https://tools.ietf.org/html/rfc= 7252#section-5.8.3), so all the mitigation scope parameters have to be re-c= onveyed=20 in the mitigation request to refresh the mitigation lifetime. I don't think= DOTS should lose the flexibility PUT method provides. >=20 > There is a second potential issue with Case 2 - what if there is a later > mitigation-id also active - no overlap conflicts with original scope, but= then > has an overlap conflict with the replacement scope - do we auto-delete th= e > mitigation-id that was just updated ? For case 2, the DOTS client should either over-write the later active mitig= ation-id or create a new mitigation-id whose value is higher=20 than the current active mitigation-id. -Tiru >=20 > Regards >=20 > Jon >=20 > -----Original Message----- > From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of Konda, > Tirumaleswar Reddy > Sent: 02 November 2017 10:41 > To: Jon Shallow; Roland Dobbins; dots@ietf.org > Subject: Re: [Dots] Overlapping mitigation requests from a DOTS client >=20 > > -----Original Message----- > > From: Jon Shallow [mailto:supjps-ietf@jpshallow.com] > > Sent: Thursday, November 2, 2017 4:00 PM > > To: Konda, Tirumaleswar Reddy > ; > > Roland Dobbins ; dots@ietf.org > > Subject: RE: [Dots] Overlapping mitigation requests from a DOTS client > > > > Hi Tiru, > > > > >> > > >> ... but all the above still does not answer what happens when > > >> mitigation ids wrap back to 0 ! > > > > > I don't see a problem. Mitigation-id can take up to 2**32 values > > > before > > rolling back, mitigation-id typically will have a > > finite lifetime > > (unless indefinite lifetime is used) and PUT allows the client to > > re-use any > > > > > existing mitigation-id and overwrite the mitigation request with > > > updated > > mitigation scopes. > > > > [5.4.1. Requesting mitigation] States > > > > " For a mitigation request to continue beyond the initial negotiated > > lifetime, the DOTS client need to refresh the current mitigation > > request by sending a new PUT request. The PUT request MUST use the > > same 'mitigation-id' value, and MUST repeat all the other parameters > > as sent in the original mitigation request apart from a possible > > change to the lifetime parameter value." > > > > So, my DOTS server currently rejects any PUT with a mitigation id that > > already exists that then has a mitigation scope change. >=20 > I don't think this behavior is correct, PUT allows the DOTS client to cha= nge the > mitigation scope for a mitigation-id. > "MUST" is used in the above line only to suggest that mitigation scope mu= st > not be changed when only refreshing the lifetime of the mitigation reques= t. >=20 > > > > You could user a lower mitigation id that is no longer in use to > > update a mitigation scope, but if there is a scope overlap, then that > > too will get rejected / ignored. Some of the DOTS agents are likely > > to be running for years, but I guess that even with a new mitigation > > id per second, that is about > > 68 years' worth, so we should be OK! >=20 > :) >=20 > -Tiru >=20 From nobody Thu Nov 2 09:08:43 2017 Return-Path: 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 25C8613F9E1 for ; Thu, 2 Nov 2017 09:08:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.001 X-Spam-Level: X-Spam-Status: No, score=-7.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham 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 ZCajqlrZUT6e for ; Thu, 2 Nov 2017 09:08:39 -0700 (PDT) Received: from MIVWSMAILOUT1.mcafee.com (mivwsmailout1.mcafee.com [161.69.47.167]) (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 AB9F313F649 for ; Thu, 2 Nov 2017 09:08:38 -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=1509638907; 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: authentication-results:x-originating-ip:x-ms-publictraffictype: x-microsoft-exchange-diagnostics:x-ms-exchange-antispam-srfa-diagnostics: x-ms-office365-filtering-correlation-id:x-microsoft-antispam: x-ms-traffictypediagnostic:x-exchange-antispam-report-test: x-microsoft-antispam-prvs:x-exchange-antispam-report-cfa-test: x-forefront-prvs:x-forefront-antispam-report: received-spf:spamdiagnosticoutput:spamdiagnosticmetadata: 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-Transport-CrossTenantHeadersStamped: X-OriginatorOrg:X-NAI-Spam-Flag:X-NAI-Spam-Threshold: X-NAI-Spam-Score:X-NAI-Spam-Version; bh=I RAhb+Tulw1mKeKLkBCduoZkBEy0+FEGwGrGOauFQU c=; b=GsFPg9JLW6iar9DILqaVhsVEy6VGtbJ3B788TVLcd4fD Xal1yZktNwCmESOyWh/yrCwJQ19I2DOlLRayiphYh8kh25KfO+ lgQH6st23y6GAMs4GEa44iMDVQGqsIWyEMhcf5wDRdViD0rM4k nLPqoPPxv5nuJOVe1bHMFSN9jBY= Received: from MIVEXAPP1N01.corpzone.internalzone.com (unknown [10.48.48.88]) by MIVWSMAILOUT1.mcafee.com with smtp id 7f3d_2331_9314a05c_ced1_4e05_a444_a1adbaded589; Thu, 02 Nov 2017 11:08:27 -0500 Received: from MIVEXUSR1N03.corpzone.internalzone.com (10.48.48.83) by MIVEXAPP1N01.corpzone.internalzone.com (10.48.48.88) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Thu, 2 Nov 2017 12:08:26 -0400 Received: from MIVO365EDGE3.corpzone.internalzone.com (10.48.176.86) by MIVEXUSR1N03.corpzone.internalzone.com (10.48.48.83) with Microsoft SMTP Server (TLS) id 15.0.1347.2 via Frontend Transport; Thu, 2 Nov 2017 12:08:26 -0400 Received: from NAM02-SN1-obe.outbound.protection.outlook.com (10.48.176.240) by edge.mcafee.com (10.48.176.86) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Thu, 2 Nov 2017 12:08:24 -0400 Received: from DM5PR16MB1788.namprd16.prod.outlook.com (10.172.44.144) by DM5PR16MB1785.namprd16.prod.outlook.com (10.172.44.141) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.197.13; Thu, 2 Nov 2017 16:08:24 +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.20.0178.015; Thu, 2 Nov 2017 16:08:24 +0000 From: "Konda, Tirumaleswar Reddy" To: Jon Shallow , "Mortensen, Andrew" , "dots@ietf.org" Thread-Topic: [Dots] DOTS & NAT (was RE: DOTS Requirements review (-06)) Thread-Index: AQHTTmDj2RAQrm+kS0aEpR2RXflMS6L2Wo6AgAAK6QCABl/TAIAAB00AgAAgpICAAL/IEIAB6gIAgAFRomCAAB+LAIAAO+7A Date: Thu, 2 Nov 2017 16:08:24 +0000 Message-ID: References: <787AE7BB302AE849A7480A190F8B93300A058A39@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93300A05E666@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93300A05E6C5@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93300A05E879@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <20171026124947.5107771.45356.38919@sandvine.com> <787AE7BB302AE849A7480A190F8B93300A05E8EA@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <71130fa2-8637-0756-a8e5-fd6e1d144e89@cisco.com> <6EDF1F8D-AA03-4275-951E-CD98047E7C03@arbor.net> <5509420C-6912-4607-B163-5C25660E943F@arbor.net> <044601d351b4$ad35be60$07a13b20$@jpshallow.com> <45176714-7846-48DE-90C5-F59ECB3A1A36@arbor.net> <055101d35319$e4197dc0$ac4c7940$@jpshallow.com> <05d901d353d2$7a1fac50$6e5f04f0$@jpshallow.com> In-Reply-To: <05d901d353d2$7a1fac50$6e5f04f0$@jpshallow.com> 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: [122.167.140.78] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DM5PR16MB1785; 6:ttHJOmrkoxoKG3ql+5uy8L/N7svou1csyfyv03+OrDvC8apWW4LrjT/Ufpn5LQMxzNe6S99GiNXGSv5BfEB5F7Lf22HLlscBNhDkvdKBZPAo3QxYkgJkMCILX4VqbJCH8ihwLkClOdfQOkfXFcvIG7rahIJgN4svxfWzoq82YrpDEUvDoxNSRwc3j3jbjwKEf97mNJv9Llbz+TcFV7cYFU+sXKg4MYZtmgmUodwEXptkj6vXnmFXdrq0GEC/zOAB0Vf1+jqYnVWPXebdRDXPEtg1zSyAVfClpiAsZSmw0r5s8NY1NBsAsWhEnlUm6blsMeZ99lDFLe2ZpZmtsOwWz98ZY706HUkztYDQkcDL5JU=; 5:1g7UTYgPZ1KWlq4CljrWJUknj9VMStaboJZYksxX6lfoVXO8Fhdmt1yIgZADBiayIf1sjxz4y9n+RKnbzNS9vLsqxk6EwwSxjyM65HrAZjsFb2+sWL/I+qwVputhFK+2VVqbAcU87dFTh66/rdSZOLv2TlMeMD3ejXUfYjahVGw=; 24:X3gHJvigqodTji30HxOEvMi4j+Qqs2Zav+V869KjdfbUnEGplaSt32zlPNTW0RjRyBxVzd5JMrwOF53eL5A8brTLR6OtR1HYXCLio4EMCmc=; 7:W44vLAdPGJVK5iPX8nVSvhteRAhciOqm6QtDdSd+uQvtevDapw6Ffakk8g7CExsA0CEi5DU53sE8bfPHGkI7kjYpfw5ImnlgVtrbMnUPvtxRnQ4WwzX2mHa/w0zh5gcgX/70NWVcjRYzgpQBdolQVEbX/ZppzuyiMt496wDuB0KFYhzAH6CkoTUjjOcorNJPYDvl/h+tf9rtIh38Ye+/f2v8APU2YVHH6dtTY3/JHKprl/j/0Ce5XWFCOSylxqfM x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: ecfae12f-20f6-46a8-2cf4-08d5220bf247 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(2017052603199); SRVR:DM5PR16MB1785; x-ms-traffictypediagnostic: DM5PR16MB1785: x-exchange-antispam-report-test: UriScan:(158342451672863)(278428928389397)(72170088055959)(123452027830198); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(5005006)(8121501046)(93006095)(93001095)(10201501046)(3231020)(100000703101)(100105400095)(3002001)(6041248)(20161123560025)(20161123562025)(20161123558100)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123555025)(20161123564025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:DM5PR16MB1785; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:DM5PR16MB1785; x-forefront-prvs: 047999FF16 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(346002)(376002)(189002)(13464003)(199003)(32952001)(7696004)(561944003)(2906002)(76176999)(86362001)(189998001)(97736004)(3280700002)(68736007)(33656002)(50986999)(6116002)(3846002)(6436002)(102836003)(54356999)(14454004)(77096006)(8936002)(305945005)(80792005)(101416001)(3660700001)(93886005)(9686003)(99286004)(53936002)(478600001)(110136005)(7736002)(966005)(74316002)(6246003)(5660300001)(72206003)(6506006)(2501003)(66066001)(55016002)(106356001)(316002)(81166006)(2950100002)(81156014)(25786009)(8676002)(2900100001)(53546010)(6306002)(105586002)(229853002)(85282002); DIR:OUT; SFP:1101; SCL:1; SRVR:DM5PR16MB1785; H:DM5PR16MB1788.namprd16.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; 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: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: ecfae12f-20f6-46a8-2cf4-08d5220bf247 X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Nov 2017 16:08:24.5809 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4943e38c-6dd4-428c-886d-24932bc2d5de X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR16MB1785 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 <6150> : inlines <6155> : streams <1769144> : uri <2526841> Archived-At: Subject: Re: [Dots] DOTS & NAT (was RE: DOTS Requirements review (-06)) 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Nov 2017 16:08:41 -0000 > -----Original Message----- > From: Jon Shallow [mailto:supjps-ietf@jpshallow.com] > Sent: Thursday, November 2, 2017 5:33 PM > To: Konda, Tirumaleswar Reddy ; > Mortensen, Andrew ; dots@ietf.org > Subject: RE: [Dots] DOTS & NAT (was RE: DOTS Requirements review (-06)) >=20 > Hi Tiru, >=20 > See inline. >=20 > Regards >=20 > Jon >=20 > -----Original Message----- > From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of Konda, > Tirumaleswar Reddy > Sent: 02 November 2017 10:49 > To: Jon Shallow; Mortensen, Andrew; dots@ietf.org > Subject: Re: [Dots] DOTS & NAT (was RE: DOTS Requirements review (-06)) >=20 > >-----Original Message----- > > From: Jon Shallow [mailto:supjps-ietf@jpshallow.com] > > Sent: Wednesday, November 1, 2017 7:31 PM > > To: Konda, Tirumaleswar Reddy > ; > > Mortensen, Andrew ; dots@ietf.org > > Subject: RE: [Dots] DOTS & NAT (was RE: DOTS Requirements review > >(-06)) > > > > Hi Andrew, > > > > I have been thinking this through as to how to practically implement > > this, come up with some recommendations and then with some suggested > > text as a possible substitute. > > > > Recommendations > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > > 1) In peace time, only the DOTS Client sends heartbeats (so no need to > > worry about NAT) at a lower rate > > 2) In attack time, both the DOTS client and DOTS server send > > heartbeats (and continue to send them, even if missing heartbeat count > > is exceeded) > > 3) signal 'config' includes both peace time and attack time heartbeat > > rates configuration support > > 4) Heartbeat rates switch over on both DOTS client and DOTS server > > when mitigating, and switch back to peace time when there are no > > mitigation requests > > > > My thinking behind the recommendations > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > > Two scenario situations > > * Peace time > > * Under attack of consequence (flooded inbound pipe) > > > > My experience is that the transition time from 'Peace time' to 'Under > > attack of consequence' is very small - and once it has occurred any > > traffic over the DOTS signal channel that is of CoAP type > > "Confirmable" will fail. So, any signal of type 'config' will fail, > > but signal of type 'mitigate' will probably get through as it is of > > type > 'non-confirmable'. >=20 > It depends on the type of DDoS attack, In case of slowloris DDoS attack, = the > incoming link to the DOTS client will most likely not be saturated. > In addition, in some deployments, where UDP is blocked, DOTS-over-TCP is > required. >=20 > Jon> If the link is not saturated then DOTS will continue to work as > expected. I am thinking of the boundary conditions - an example being pi= pe > full where DOTS still needs to be functional. > Jon> Agreed - CoAP over TLS is not ideal and is likely to fail under > boundary conditions. >=20 > > > > We have determined from 'flooded inbound pipe' tests that the > > heartbeat requests from the DOTS client get through to the DOTS > > server, but nothing gets through to the DOTS client. So the DOTS > > server can determine the session is still up and keep the session > > "warm" should the DOTS client need to blindly send off a mitigation > > request. The caveat here is that the DOTS client needs to continue to > > send heartbeat requests even though the DOTS client has exceeded the > missing heartbeat response counts. >=20 > Yes, this mechanism is discussed in the next re-version. >=20 > > > > During time of attack, to me, it is important that the heartbeats run > > at a sufficient frequency to keep any NAT / stateful devices allowing > > through 2- way traffic - we have generally agreed elsewhere that this > > should be the order of 30 seconds, but could be shorter or longer. > > > > In peacetime, I do not believe that we need to keep state through any > > NAT / stateful devices for traffic initiated by DOTS server. If the > > DOTS server sends no heartbeat requests (or any other initiated > > traffic), > then NAT is not an issue. > > Any heartbeats sent by a DOTS client should get the heartbeat > > responses back through a NAT / stateful device as the RTT should not > > be large (certainly should be less than 30 seconds!). The DOTS client > > could reduce the heartbeat frequency to, say, once an hour (empirical > > guess) with no issues and the DOTS server can keep the session open > > ready for attack time as it is continuing to see the heartbeat requests= . >=20 > The DOTS server also needs to perform heartbeat checks to detect and > delete defunct DOTS session, otherwise the DOTS server could end-up > consuming cryptographic state for DOTS session abruptly disconnected by > the DOTS client. Please see the UDP usage best practices in > https://tools.ietf.org/html/rfc8085 >=20 > Jon> If the DOTS server fails to see a heartbeat CoAP ping request from > Jon> the > DOTS client within the agreed heartbeat repeat rate * some factor > (suggestion 2 * + tolerance to handle a missing heartbeat), then the sess= ion > can be declared as dead. I would also expect the DOTS client to be sendi= ng a > session close at the DTLS level if the client is going away (obviously no= t if the > client crashes!). Your proposal violates the UDP usage guidelines discussed in RFC8085 (pleas= e see the last paragraph in Section 6).=20 >=20 > > A UDP application with a long-lived association between the sender > and receiver, ought to be designed so that the sender periodically > checks that the receiver still wants ("consents") to receive traffic > and need to be designed to stop if there is no explicit confirmation > of this [RFC7675]. Applications that require communications in two > directions to implement protocol functions (such as reliability or > congestion control) will need to independently check both directions > of communication, and may have to exchange keep-alive messages to > traverse middleboxes (see Section 3.5). >=20 > > > > As it may not be possible to reconfigure heartbeat rates once an > > attack has started, it makes some sense to me to have a peacetime > > heartbeat rate (only DOTS client sends) and attack time heartbeat rate > > (both DOTS client and DOTS server send). Once a DOTS server has > > accepted a mitigation request, and for the continuation of the > > mitigation request the attack time heartbeat rate is used. Once the > > mitigation request is dropped (and there are no other active > > mitigation requests from the DOTS client) then the peacetime heartbeat > rate is used. >=20 > I don't understand the need for different heartbeat rates. > What problems do you see with the current mechanism ? >=20 > Jon> When mitigation is active, heartbeats need to be running at a rate > Jon> that > keeps traffic flowing through middleboxes that may be NAT devices. In > peace time, this is creating a lot of chit-chat that is not really needed= and > could be slowed down (some people appear to be saying that they want no > or very little heartbeats). If the rate becomes less frequent than the > recognized 30 seconds (even though RFC recommendations are for higher > values) the DOTS server will start to suffer heartbeat failure if traffic= is > passing through a NAT device. I don't think the proposed keep-alive interval is the problem, WebRTC uses = consent checks (30 second expiry on consent https://tools.ietf.org/html/rfc= 7675) and=20 QUIC sends keepalives every 15 to 30 seconds. -Tiru >=20 > Jon> By there being two different sets of heartbeat values (which could > Jon> be > the same values) and which set is used is based on whether mitigating or = not > removes the need for having to do a CON Configuration change whilst under > attack to set the required heartbeat parameters for the attack conditions= . > =20 > -Tiru >=20 > > > > Suggested Updates > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > > My suggested update to SIG-003 of the requirements spec is as > > follows:- > > > > SIG-003 Channel Health Monitoring: DOTS agents MUST support > exchange > > of heartbeat messages over the signal channel to monitor channel > > health. Peer DOTS agents SHOULD regularly send heartbeats to eac= h > > other while a mitigation request is active. The heartbeat > > interval during active mitigation is not specified, but SHOULD be > > frequent enough to maintain any on-path NAT bindings during > > mitigation. When there is no active mitigation, there is no > > need > for the > > DOTS server to send heartbeats, and the DOTS client can use a low= er > > Heartbeat rate as then there is no requirement to maintain any > on-path > > NAT bindings. > > > > To support scenarios in which loss of heartbeat is used to trigge= r > > mitigation, and to keep the channel active, DOTS clients MAY > > solicit heartbeat exchanges after successful mutual > > authentication. When DOTS agents are exchanging heartbeats and n= o > > mitigation request is active, either agent MAY request changes to > > the heartbeat rate. For example, a DOTS server might want to > > delay or cease heartbeat exchanges when an active DOTS client has > > not requested mitigation, in order to control load. > > > > Following mutual authentication, a signal channel MUST be > > considered active until a DOTS agent explicitly ends the session, > > or either DOTS agent fails to receive heartbeats from the other > > after a mutually agreed upon timeout period has elapsed. Because > > heartbeat loss is much more likely during volumetric attack, DOTS > > agents SHOULD avoid signal channel termination when mitigation is > > active and heartbeats are not received by either DOTS agent for a= n > > extended period. In such circumstances, DOTS clients MAY attempt > > to reestablish the signal channel. DOTS servers SHOULD monitor > > the attack, using feedback from the mitigator and other available > > sources, and MAY use the absence of attack traffic and lack of > > client heartbeat requests as an indication the signal channel is > defunct. > > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > > Regards > > > > Jon >=20 > _______________________________________________ > Dots mailing list > Dots@ietf.org > https://www.ietf.org/mailman/listinfo/dots From nobody Thu Nov 2 09:38:58 2017 Return-Path: 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 3C12913F74E for ; Thu, 2 Nov 2017 09:38:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 pZruMj8BR_Ga for ; Thu, 2 Nov 2017 09:38:54 -0700 (PDT) Received: from mail.jpshallow.com (mail.jpshallow.com [217.40.240.153]) (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 990F913F756 for ; Thu, 2 Nov 2017 09:38:52 -0700 (PDT) Received: from [127.0.0.1] (helo=N01332) by mail.jpshallow.com with smtps (TLSv1:ECDHE-RSA-AES256-SHA:256) (Exim 4.89) (envelope-from ) id 1eAIW0-0007Ol-NI; Thu, 02 Nov 2017 16:38:48 +0000 From: "Jon Shallow" To: "'Konda, Tirumaleswar Reddy'" , "Roland Dobbins" , References: <79DF8659-AEEB-4B66-91EF-F2C5EC1786DD@arbor.net> <055601d3531d$c50dcf90$4f296eb0$@jpshallow.com> <05cc01d353c5$87625eb0$96271c10$@jpshallow.com> <05d401d353cd$386af0d0$a940d270$@jpshallow.com> In-Reply-To: Date: Thu, 2 Nov 2017 16:38:48 -0000 Message-ID: <060c01d353f9$0f324070$2d96c150$@jpshallow.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQH5pWUwAA9xtOo6/8WeQH4QpMhR6QFfs0lwAYQcz08C30fxbAKiZgegAitscJsBSJGpFwE4fb6iokwUNeA= Content-Language: en-gb Archived-At: Subject: Re: [Dots] Overlapping mitigation requests from a DOTS client 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Nov 2017 16:38:57 -0000 Hi Tiru, "PUT allows the resources to be updated (see https://tools.ietf.org/html/rfc7252#section-5.8.3), so all the mitigation scope parameters have to be re-conveyed in the mitigation request to refresh the mitigation lifetime. I don't think DOTS should lose the flexibility PUT method provides." I agree about not losing flexibility. However, if the mitigation lifetime is only extended if there is an exact match on all the other scope parameters - is this the scope parameters before the PUT updates the mitigation scope, or after the PUT updates the mitigation scope? If the PUT update sends less parameters - are the non-referenced parameters that were in the previous PUT request to be left there or deleted? I need to know what to keep to look for an exact match to allow lifetime to be extended because of the MUST whenever any PUT updated the current mitigation scope. Regards Jon -----Original Message----- From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of Konda, Tirumaleswar Reddy Sent: 02 November 2017 15:37 To: Jon Shallow; Roland Dobbins; dots@ietf.org Subject: Re: [Dots] Overlapping mitigation requests from a DOTS client > -----Original Message----- > From: Jon Shallow [mailto:supjps-ietf@jpshallow.com] > Sent: Thursday, November 2, 2017 4:55 PM > To: Konda, Tirumaleswar Reddy ; > Roland Dobbins ; dots@ietf.org > Subject: RE: [Dots] Overlapping mitigation requests from a DOTS client > > Hi Tiru, > > I am having programmatic challenges here with your comment. > > Case 1: PUT request for same mitigation-id is identical (apart from > maybe > lifetime) > > Mitigation is refreshed for another lifetime seconds(or infinite if -1). > > Case 2: PUT request for same mitigation-id has a new mitigation scope > - lifetime may or may not be different > > Old mitigation is overwritten with new scope parameters - is the > mitigation lifetime refreshed for another lifetime seconds, or the > remaining time of the mitigation left unchanged? > > If the mitigation lifetime is refreshed, then why do we need Case 1: > with a MUST? PUT allows the resources to be updated (see https://tools.ietf.org/html/rfc7252#section-5.8.3), so all the mitigation scope parameters have to be re-conveyed in the mitigation request to refresh the mitigation lifetime. I don't think DOTS should lose the flexibility PUT method provides. > > There is a second potential issue with Case 2 - what if there is a > later mitigation-id also active - no overlap conflicts with original > scope, but then has an overlap conflict with the replacement scope - > do we auto-delete the mitigation-id that was just updated ? For case 2, the DOTS client should either over-write the later active mitigation-id or create a new mitigation-id whose value is higher than the current active mitigation-id. -Tiru > > Regards > > Jon > > -----Original Message----- > From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of Konda, > Tirumaleswar Reddy > Sent: 02 November 2017 10:41 > To: Jon Shallow; Roland Dobbins; dots@ietf.org > Subject: Re: [Dots] Overlapping mitigation requests from a DOTS client > > > -----Original Message----- > > From: Jon Shallow [mailto:supjps-ietf@jpshallow.com] > > Sent: Thursday, November 2, 2017 4:00 PM > > To: Konda, Tirumaleswar Reddy > ; > > Roland Dobbins ; dots@ietf.org > > Subject: RE: [Dots] Overlapping mitigation requests from a DOTS > > client > > > > Hi Tiru, > > > > >> > > >> ... but all the above still does not answer what happens when > > >> mitigation ids wrap back to 0 ! > > > > > I don't see a problem. Mitigation-id can take up to 2**32 values > > > before > > rolling back, mitigation-id typically will have a > > finite > > lifetime (unless indefinite lifetime is used) and PUT allows the > > client to re-use any > > > > > existing mitigation-id and overwrite the mitigation request with > > > updated > > mitigation scopes. > > > > [5.4.1. Requesting mitigation] States > > > > " For a mitigation request to continue beyond the initial negotiated > > lifetime, the DOTS client need to refresh the current mitigation > > request by sending a new PUT request. The PUT request MUST use the > > same 'mitigation-id' value, and MUST repeat all the other parameters > > as sent in the original mitigation request apart from a possible > > change to the lifetime parameter value." > > > > So, my DOTS server currently rejects any PUT with a mitigation id > > that already exists that then has a mitigation scope change. > > I don't think this behavior is correct, PUT allows the DOTS client to > change the mitigation scope for a mitigation-id. > "MUST" is used in the above line only to suggest that mitigation scope > must not be changed when only refreshing the lifetime of the mitigation request. > > > > > You could user a lower mitigation id that is no longer in use to > > update a mitigation scope, but if there is a scope overlap, then > > that too will get rejected / ignored. Some of the DOTS agents are > > likely to be running for years, but I guess that even with a new > > mitigation id per second, that is about > > 68 years' worth, so we should be OK! > > :) > > -Tiru > _______________________________________________ Dots mailing list Dots@ietf.org https://www.ietf.org/mailman/listinfo/dots From nobody Thu Nov 2 10:29:21 2017 Return-Path: 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 45C5D13F5CB for ; Thu, 2 Nov 2017 10:29:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.8 X-Spam-Level: X-Spam-Status: No, score=0.8 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 V_bBfMQv6Pei for ; Thu, 2 Nov 2017 10:29:18 -0700 (PDT) Received: from mail.jpshallow.com (mail.jpshallow.com [217.40.240.153]) (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 B8D4713F74A for ; Thu, 2 Nov 2017 10:29:18 -0700 (PDT) Received: from [127.0.0.1] (helo=N01332) by mail.jpshallow.com with smtps (TLSv1:ECDHE-RSA-AES256-SHA:256) (Exim 4.89) (envelope-from ) id 1eAJIr-0007QE-6y for ietf-supjps-dots@ietf.org; Thu, 02 Nov 2017 17:29:17 +0000 From: "Jon Shallow" To: Date: Thu, 2 Nov 2017 17:29:17 -0000 Message-ID: <061101d35400$1c4d0860$54e71920$@jpshallow.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0612_01D35400.1C4DCBB0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdNUABd2oazNQrGkTcGpdBoMvbQJQQ== Content-Language: en-gb Archived-At: Subject: [Dots] Data Channel DELETE 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Nov 2017 17:29:20 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0612_01D35400.1C4DCBB0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Tiru et al, We need to rework the DELETE example to handle both alias-name and client-identifier when deleting an alias-name. The same is true for acl-names. Original ====== 3.2.2. Delete Identifiers A DELETE request is used to delete identifiers maintained by a DOTS server (Figure 5). DELETE /restconf/data/ietf-dots-data-channel-identifier:identifier\ /alias=Server1 HTTP/1.1 Host: {host}:{port} Figure 5: DELETE identifier Suggestion (there may be a better way of doing this..) for a list of 2 client-identifiers. ========= 3.2.2. Delete Identifiers A DELETE request is used to delete identifiers maintained by a DOTS server (Figure 5). DELETE /restconf/data/ietf-dots-data-channel-identifier:identifier\ /alias-name=Server1&client-identifier=dz6pHjaADkaFTbjr0JGBpw==,diffHjaADkaFT bjr0JGOne== HTTP/1.1 Host: {host}:{port} Figure 5: DELETE identifier ====== However, we may need to drop the trailing == and certainly explain the client-identifier field. alias should also be alias-name. Regards Jon ------=_NextPart_000_0612_01D35400.1C4DCBB0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Tiru et = al,

 

We need to rework the DELETE example to handle both = alias-name and client-identifier when deleting an alias-name.  The = same is true for acl-names.

 

Original

=3D=3D=3D=3D=3D=3D

 

3.2.2.  = Delete Identifiers

 

   = A DELETE request is used to delete identifiers maintained by a = DOTS

   server (Figure = 5).

 

     DELETE = /restconf/data/ietf-dots-data-channel-identifier:identifier\

         &= nbsp;  /alias=3DServer1 HTTP/1.1

     Host: = {host}:{port}

 

         &= nbsp;           &n= bsp;  Figure 5: DELETE identifier

 

Suggestion = (there may be a better way of doing this….) for a list of 2 = client-identifiers.

=3D=3D=3D=3D=3D=3D=3D=3D=3D

 

3.2.2.  = Delete Identifiers

 

   = A DELETE request is used to delete identifiers maintained by a = DOTS

   server (Figure = 5).

 

     DELETE = /restconf/data/ietf-dots-data-channel-identifier:identifier\

         &= nbsp;  /alias-name=3DServer1&client-identifier=3Ddz6pHjaADkaFTbjr0JGBpw=3D=3D,diffHjaADkaFTbjr0JGOne=3D=3D = HTTP/1.1

     = Host: {host}:{port}

 

         &= nbsp;           &n= bsp;  Figure 5: DELETE identifier

 

=3D=3D=3D=3D=3D=3D

 

However, we = may need to drop the trailing =3D=3D and certainly explain the = client-identifier field. alias should also be = alias-name.

 

Regards

 

Jon

------=_NextPart_000_0612_01D35400.1C4DCBB0-- From nobody Fri Nov 3 01:40:32 2017 Return-Path: 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 4C43D13FC21 for ; Fri, 3 Nov 2017 01:40:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.999 X-Spam-Level: X-Spam-Status: No, score=-6.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 FMmLHnxTPJpM for ; Fri, 3 Nov 2017 01:40:28 -0700 (PDT) Received: from MIVWSMAILOUT1.mcafee.com (mivwsmailout1.mcafee.com [161.69.47.167]) (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 3E5AA13FD02 for ; Fri, 3 Nov 2017 01:40:27 -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=1509698419; 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: authentication-results:x-originating-ip:x-ms-publictraffictype: x-microsoft-exchange-diagnostics:x-ms-exchange-antispam-srfa-diagnostics: x-ms-office365-filtering-correlation-id:x-microsoft-antispam: x-ms-traffictypediagnostic:x-exchange-antispam-report-test: x-microsoft-antispam-prvs:x-exchange-antispam-report-cfa-test: x-forefront-prvs:x-forefront-antispam-report: received-spf:spamdiagnosticoutput:spamdiagnosticmetadata: Content-Type: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-Transport-CrossTenantHeadersStamped: X-OriginatorOrg:X-NAI-Spam-Flag:X-NAI-Spam-Level: X-NAI-Spam-Threshold:X-NAI-Spam-Score:X-NAI-Spam-Version; bh=f8WpBvm63pdFHAZVPHiG1ud4I/dg29s7X29zTI 6dD6c=; b=n0r7mVwl1+Z+wyYCCmH73rZikwXCRDbBUDgT1o+t U8yqop+GfWdK26ZRNVdKd2j2cbEu3pPxmUHAztEmwuhTr7SCGK t6ZLFQR+3uUqsK4iGzMw5kY2GBDg6X4yeXTk0ZHQKgTp4U1tnI j6d1UtdYLZz8Dv82mYBHSClt5DU3j44= Received: from MIVEXAPP1N03.corpzone.internalzone.com (unknown [10.48.48.90]) by MIVWSMAILOUT1.mcafee.com with smtp id 74ec_366d_795397f7_d2c2_4b5a_8827_3449f56bfe58; Fri, 03 Nov 2017 03:40:18 -0500 Received: from MIVEXAPP1N03.corpzone.internalzone.com (10.48.48.90) by MIVEXAPP1N03.corpzone.internalzone.com (10.48.48.90) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Fri, 3 Nov 2017 04:40:15 -0400 Received: from MIVO365EDGE4.corpzone.internalzone.com (10.48.176.87) by MIVEXAPP1N03.corpzone.internalzone.com (10.48.48.90) with Microsoft SMTP Server (TLS) id 15.0.1347.2 via Frontend Transport; Fri, 3 Nov 2017 04:40:15 -0400 Received: from NAM02-BL2-obe.outbound.protection.outlook.com (10.48.176.242) by edge.mcafee.com (10.48.176.87) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Fri, 3 Nov 2017 04:40:15 -0400 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.20.197.13; Fri, 3 Nov 2017 08:40:13 +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.20.0197.017; Fri, 3 Nov 2017 08:40:13 +0000 From: "Konda, Tirumaleswar Reddy" To: Jon Shallow , "dots@ietf.org" Thread-Topic: [Dots] Data Channel DELETE Thread-Index: AdNUABd2oazNQrGkTcGpdBoMvbQJQQAfdJZA Date: Fri, 3 Nov 2017 08:40:13 +0000 Message-ID: References: <061101d35400$1c4d0860$54e71920$@jpshallow.com> In-Reply-To: <061101d35400$1c4d0860$54e71920$@jpshallow.com> 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: [103.245.47.20] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DM5PR16MB1787; 6:pWvej6TCvPXzl6OP8im1sTsUtAFL07SOvfF1MgU7wgSLeLuzGF1mrPCAQqdjP8tPKuFPHLSdlqlHILgH0mZbkMaB1HvYWHhQqeTnxqypnzklQi4o022jbOMv9FdM70m37LdxoMT0CqldEEhpPZNv8QOqI+v1zNG0O1ZgcYbmnDyoJzEOitH04orB5D6aOMjQm7LVN16wohRJUm1BNxoMjehMq7rd8RveokWfva2gnB43OwCwlm02as2j+cCdOTiPWkexbzAHntbWXli9TS8wrSZPT48YakjGJPZGLupWaoowrll+rgg2immtJMAI9eAxsT06L2cDWCUZGPUYCOIRyXYM4xQTAHM0BrjC670DRI8=; 5:DsFLQX+jkJ+xV61G9h9MGB7vz110q1uNuqV1YKHW2iG2aB6d6DJBD5t1xl7TEww0b08p6Mbha8rPACZRF35t4xC0uN/QR/p4KbHSm/r5dHBfobMhSdcrhm3/ayGx3UyxdUZlK9TmCoZWZPw67dNKUrpKC9IR1rL5wXGBwJIYmGg=; 24:AInRDa/cyq5WyamhvDo1w1AeXvoNZBUxrC56cE+BFCkA0gZJloHEh0eo2GCxr0vLca0m3dZLmyfJ4m6Vz7IrNYzVp4FFXXnv6VteUFzweY8=; 7:IiQyoMq7MEgyhEtmZYgZSzeXhoNo3x+GJtkQ2sX7ujEBKoSIHjcusz59StFlpYR0iGV1TPx477YbCkcEqW3pC2CLbbmL3GXrbmBAUhxymA+7mrczSfgwTfAPRYjiY/8YMTVFTcJgn6edmsSFr3ymoEtsnm4BHhAJBHw92o4k4Plguq9FczxOKqiCJkBFCZ670idwSm/JbAIqIRtQi8VTg7gVl0Uzx98ga/CeJinBpg5OcWb53BofN8Rmuz8r3Cyu x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: fbf1acc9-43eb-49f0-c132-08d522968068 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(2017052603238); SRVR:DM5PR16MB1787; x-ms-traffictypediagnostic: DM5PR16MB1787: x-exchange-antispam-report-test: UriScan:(158342451672863)(21748063052155); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(8121501046)(5005006)(93006095)(93001095)(3231021)(100000703101)(100105400095)(3002001)(10201501046)(6041248)(20161123555025)(20161123564025)(20161123558100)(20161123560025)(20161123562025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(6072148)(201708071742011)(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: 0480A51D4A x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(376002)(346002)(189002)(32952001)(199003)(53936002)(81156014)(33656002)(6306002)(8676002)(97736004)(189998001)(7736002)(6246003)(790700001)(55016002)(2906002)(77096006)(106356001)(25786009)(105586002)(2900100001)(6506006)(99286004)(2950100002)(9686003)(86362001)(54896002)(81166006)(229853002)(66066001)(575784001)(53546010)(8936002)(110136005)(5660300001)(2501003)(14454004)(68736007)(3660700001)(50986999)(19609705001)(74316002)(478600001)(6436002)(3280700002)(80792005)(101416001)(3846002)(316002)(102836003)(9326002)(72206003)(6116002)(7696004)(54356999)(76176999)(85282002); DIR:OUT; SFP:1101; SCL:1; SRVR:DM5PR16MB1787; H:DM5PR16MB1788.namprd16.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; 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_DM5PR16MB1788986BA613E76ACF4D4CD8EA5D0DM5PR16MB1788namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: fbf1acc9-43eb-49f0-c132-08d522968068 X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Nov 2017 08:40:13.5705 (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-Level: X-NAI-Spam-Threshold: 15 X-NAI-Spam-Score: 0.1 X-NAI-Spam-Version: 2.3.0.9418 : core <6150> : inlines <6155> : streams <1769208> : uri <2527283> Archived-At: Subject: Re: [Dots] Data Channel DELETE 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Nov 2017 08:40:31 -0000 --_000_DM5PR16MB1788986BA613E76ACF4D4CD8EA5D0DM5PR16MB1788namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Jon, Agree with your comments. Updated the examples in DOTS data channel to conv= ey 2 client-identifiers and changed DOTS signal channel draft to use base64= url encoding (to couple the DOTS signal and data channel based on the "clie= nt-identifier" parameter value). Replaced "alias" with "alias-name". Thanks and Regards, -Tiru From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Jon Shallow Sent: Thursday, November 2, 2017 10:59 PM To: dots@ietf.org Subject: [Dots] Data Channel DELETE Hi Tiru et al, We need to rework the DELETE example to handle both alias-name and client-i= dentifier when deleting an alias-name. The same is true for acl-names. Original =3D=3D=3D=3D=3D=3D 3.2.2. Delete Identifiers A DELETE request is used to delete identifiers maintained by a DOTS server (Figure 5). DELETE /restconf/data/ietf-dots-data-channel-identifier:identifier\ /alias=3DServer1 HTTP/1.1 Host: {host}:{port} Figure 5: DELETE identifier Suggestion (there may be a better way of doing this....) for a list of 2 cl= ient-identifiers. =3D=3D=3D=3D=3D=3D=3D=3D=3D 3.2.2. Delete Identifiers A DELETE request is used to delete identifiers maintained by a DOTS server (Figure 5). DELETE /restconf/data/ietf-dots-data-channel-identifier:identifier\ /alias-name=3DServer1&client-identifier=3Ddz6pHjaADkaFTbjr0JGBp= w=3D=3D,diffHjaADkaFTbjr0JGOne=3D=3D HTTP/1.1 Host: {host}:{port} Figure 5: DELETE identifier =3D=3D=3D=3D=3D=3D However, we may need to drop the trailing =3D=3D and certainly explain the = client-identifier field. alias should also be alias-name. Regards Jon --_000_DM5PR16MB1788986BA613E76ACF4D4CD8EA5D0DM5PR16MB1788namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Jon,

&nbs= p;

Agree wit= h your comments. Updated the examples in DOTS data channel to convey 2 clie= nt-identifiers and changed DOTS signal channel draft to use base64url encod= ing (to couple the DOTS signal and data channel based on the “client-identifier” parameter value).

Replaced = “alias” with “alias-name”.

&nbs= p;

Thanks an= d Regards,

-Tiru

 

From:<= /span> Dots [mailto:dots-bou= nces@ietf.org] On Behalf Of Jon Shallow
Sent: Thursday, November 2, 2017 10:59 PM
To: dots@ietf.org
Subject: [Dots] Data Channel DELETE

 

Hi Tiru et al,

 

We need to rework the DELETE ex= ample to handle both alias-name and client-identifier when deleting an alia= s-name.  The same is true for acl-names.

 

Original

=3D=3D=3D=3D=3D=3D

 

3.2.2.  Delete Identifiers=

 

   A DELETE request i= s used to delete identifiers maintained by a DOTS

   server (Figure 5).=

 

     DELETE= /restconf/data/ietf-dots-data-channel-identifier:identifier\

     &= nbsp;      /alias=3DServer1 HTTP/1.1

     Host: = {host}:{port}

 

     &= nbsp;           &nbs= p;      Figure 5: DELETE identifier

 

Suggestion (there may be a bett= er way of doing this….) for a list of 2 client-identifiers.

=3D=3D=3D=3D=3D=3D=3D=3D=3D

 

3.2.2.  Delete Identifiers=

 

   A DELETE request i= s used to delete identifiers maintained by a DOTS

   server (Figure 5).=

 

     DELETE= /restconf/data/ietf-dots-data-channel-identifier:identifier\

     &= nbsp;      /alias-name=3DServer1&client-identi= fier=3Ddz6pHjaADkaFTbjr0JGBpw=3D=3D,diffHjaA= DkaFTbjr0JGOne=3D=3D HTTP/1.1

     Host: = {host}:{port}

 

     &= nbsp;           &nbs= p;      Figure 5: DELETE identifier

 

=3D=3D=3D=3D=3D=3D

 

However, we may need to drop th= e trailing =3D=3D and certainly explain the client-identifier field. alias = should also be alias-name.

 

Regards

 

Jon

--_000_DM5PR16MB1788986BA613E76ACF4D4CD8EA5D0DM5PR16MB1788namp_-- From nobody Fri Nov 3 01:46:16 2017 Return-Path: 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 49E8613FD03 for ; Fri, 3 Nov 2017 01:46:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7 X-Spam-Level: X-Spam-Status: No, score=-7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 1tfQXjEsY2nr for ; Fri, 3 Nov 2017 01:46:11 -0700 (PDT) Received: from MIVWSMAILOUT1.mcafee.com (mivwsmailout1.mcafee.com [161.69.47.167]) (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 1AB4C13FB53 for ; Fri, 3 Nov 2017 01:46: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=1509698770; 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: authentication-results:x-originating-ip:x-ms-publictraffictype: x-microsoft-exchange-diagnostics:x-ms-exchange-antispam-srfa-diagnostics: x-ms-office365-filtering-correlation-id:x-microsoft-antispam: x-ms-traffictypediagnostic:x-exchange-antispam-report-test: x-microsoft-antispam-prvs:x-exchange-antispam-report-cfa-test: x-forefront-prvs:x-forefront-antispam-report: received-spf:spamdiagnosticoutput:spamdiagnosticmetadata: 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-Transport-CrossTenantHeadersStamped: X-OriginatorOrg:X-NAI-Spam-Flag:X-NAI-Spam-Threshold: X-NAI-Spam-Score:X-NAI-Spam-Version; bh=s 3FwS7MxFrzN8sW7mNeMaiOL0+3vK2yuVM7ORwG9dj c=; b=hLkfE285Swsxw8vA3UJvfCOXt1tdl3lBZm6OOp86jtZJ 0CRCLDPQT9PsetM8fwWPKbosIGnwOi+FfJKEnGRPI9J7/eRr5m hd6P6PvmozpV1ZXBUXRH21m/XdGaEsfTrjV1z9bnI9z4Skuzlk GFr9BtZHSm9FTSP00g8dUtqHtQk= Received: from MIVEXAPP1N02.corpzone.internalzone.com (unknown [10.48.48.89]) by MIVWSMAILOUT1.mcafee.com with smtp id 74ec_384a_d5a12591_5e9b_47c3_9e19_8d498b33a163; Fri, 03 Nov 2017 03:46:09 -0500 Received: from MIVEXUSR1N06.corpzone.internalzone.com (10.48.48.86) by MIVEXAPP1N02.corpzone.internalzone.com (10.48.48.89) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Fri, 3 Nov 2017 04:46:05 -0400 Received: from MIVEXUSR1N03.corpzone.internalzone.com (10.48.48.83) by MIVEXUSR1N06.corpzone.internalzone.com (10.48.48.86) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Fri, 3 Nov 2017 04:46:04 -0400 Received: from MIVO365EDGE3.corpzone.internalzone.com (10.48.176.86) by MIVEXUSR1N03.corpzone.internalzone.com (10.48.48.83) with Microsoft SMTP Server (TLS) id 15.0.1347.2 via Frontend Transport; Fri, 3 Nov 2017 04:46:04 -0400 Received: from NAM03-BY2-obe.outbound.protection.outlook.com (10.48.176.242) by edge.mcafee.com (10.48.176.86) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Fri, 3 Nov 2017 04:46:03 -0400 Received: from DM5PR16MB1788.namprd16.prod.outlook.com (10.172.44.144) by DM5PR16MB1785.namprd16.prod.outlook.com (10.172.44.141) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.197.13; Fri, 3 Nov 2017 08:46:02 +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.20.0197.017; Fri, 3 Nov 2017 08:46:02 +0000 From: "Konda, Tirumaleswar Reddy" To: Jon Shallow , Roland Dobbins , "dots@ietf.org" Thread-Topic: [Dots] Overlapping mitigation requests from a DOTS client Thread-Index: AdNTEI1883tp4+lsSlOjP4a89tzzJQACbvyAAADexQAAJabbwAAESbsAAAATZiAAAdjwAAAILJRAAALJAwAAIZeUgA== Date: Fri, 3 Nov 2017 08:46:01 +0000 Message-ID: References: <79DF8659-AEEB-4B66-91EF-F2C5EC1786DD@arbor.net> <055601d3531d$c50dcf90$4f296eb0$@jpshallow.com> <05cc01d353c5$87625eb0$96271c10$@jpshallow.com> <05d401d353cd$386af0d0$a940d270$@jpshallow.com> <060c01d353f9$0f324070$2d96c150$@jpshallow.com> In-Reply-To: <060c01d353f9$0f324070$2d96c150$@jpshallow.com> 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: [103.245.47.20] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DM5PR16MB1785; 6:G+NL0d/yu3VSavoddkIyw8qjYQPpxtpLyHe+xjDbYbX1IRa0L/rDm2otu3Sdeh9vBPVaOukZ4aQ9p5494a/TeWxFSVFwIM4qVM7ClV8y1zxItABLoCkHqdFzZx2r8kvtchwswq3p00OT0o+tJPTwecHIPyc5mm/ySpSyDX4dmd+jflqcoIq9ZdnkRWY/fmyD/ZZ62PwmEAutr+QxXVa0uCtx29v/7wsKKzBF6GTu+IeWI/M1r4rICWyIZDMIZ5xJMmZTjd2RGZGHxLkLrFUY58p+SeyF5feHikfYDv7bo56jN/8fEV7WY/WThW0YYQfdmQBnspbrbry+o3XRhktKcVFcVPsBqIVjQM5Yjseewe8=; 5:c9qJ6A6QhgzrmvcFOfESzH+ctYNN3AMTGSFD31IhgPKfCY962HlgLA8uMuR/vev6nKGa26WOkwhXTi045PTx3sN7NXhOUtqTjdiqC8gYBDssYr+0ttjl/Zh9fvbrZlAlzbM8BckzMSVULucFnxueVdJ5ixwmUEHflrMY0NWbJLg=; 24:0cLDugOD/ZtusKq9zk2kt+KwArD17VM7XEABl39c10tyAaxC1CIsxMMjiDtTAx1IHBNzXCQ1NiJwJdKhNt9dnMfrVnPAmNEnUEzsBK0khlU=; 7:qMzNxq3+PdQzl9rO5+Q0XmP2lHI4jgsx2vqb6SWr50pmlMqy7sz4qxycTs4EzqlRCGpUmRscF2HKA7utu0q45fYZ2QQn3mQXrAERITVbGVWugDUmeam2ZHbXHNFvZ9Spl6gXl1pxSYxbR02QFTI9t91neeJLB5iLb9b6+YDNNi7uWFlw6481j0KQkFR0lDMpa3AMNkHjxp/yuJ9WBKTloQ5MvQAbl6al3kI5yHNzRHs6TQdEerySwbALA9C/WxE3 x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: cd23d171-4af2-4c06-b505-08d522975015 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(2017052603199); SRVR:DM5PR16MB1785; x-ms-traffictypediagnostic: DM5PR16MB1785: x-exchange-antispam-report-test: UriScan:(158342451672863)(123452027830198); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(5005006)(8121501046)(3002001)(3231021)(100000703101)(100105400095)(10201501046)(93006095)(93001095)(6041248)(20161123564025)(20161123558100)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123555025)(20161123560025)(20161123562025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:DM5PR16MB1785; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:DM5PR16MB1785; x-forefront-prvs: 0480A51D4A x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(979002)(6009001)(376002)(346002)(199003)(32952001)(57704003)(189002)(13464003)(6246003)(74316002)(72206003)(5660300001)(2900100001)(99286004)(53936002)(9686003)(7736002)(110136005)(478600001)(53546010)(8676002)(105586002)(25786009)(229853002)(966005)(6306002)(6506006)(66066001)(55016002)(2501003)(81156014)(106356001)(316002)(81166006)(2950100002)(97736004)(86362001)(68736007)(50986999)(33656002)(3280700002)(7696004)(76176999)(3846002)(2906002)(80792005)(101416001)(305945005)(8936002)(93886005)(3660700001)(6436002)(6116002)(102836003)(14454004)(189998001)(77096006)(54356999)(85282002)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1101; SCL:1; SRVR:DM5PR16MB1785; H:DM5PR16MB1788.namprd16.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: McAfee.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: cd23d171-4af2-4c06-b505-08d522975015 X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Nov 2017 08:46:02.0080 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4943e38c-6dd4-428c-886d-24932bc2d5de X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR16MB1785 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 <6150> : inlines <6155> : streams <1769208> : uri <2527286> Archived-At: Subject: Re: [Dots] Overlapping mitigation requests from a DOTS client 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Nov 2017 08:46:14 -0000 > -----Original Message----- > From: Jon Shallow [mailto:supjps-ietf@jpshallow.com] > Sent: Thursday, November 2, 2017 10:09 PM > To: Konda, Tirumaleswar Reddy ; > Roland Dobbins ; dots@ietf.org > Subject: RE: [Dots] Overlapping mitigation requests from a DOTS client >=20 > Hi Tiru, >=20 > "PUT allows the resources to be updated (see > https://tools.ietf.org/html/rfc7252#section-5.8.3), so all the mitigation= scope > parameters have to be re-conveyed in the mitigation request to refresh th= e > mitigation lifetime. I don't think DOTS should lose the flexibility PUT m= ethod > provides." >=20 > I agree about not losing flexibility. >=20 > However, if the mitigation lifetime is only extended if there is an exact= match > on all the other scope parameters - is this the scope parameters before t= he > PUT updates the mitigation scope, or after the PUT updates the mitigation > scope? >=20 > If the PUT update sends less parameters - are the non-referenced > parameters that were in the previous PUT request to be left there or del= eted? PUT replaces the mitigation request, so non-referenced parameters will be d= eleted.=20 -Tiru >=20 > I need to know what to keep to look for an exact match to allow lifetime = to > be extended because of the MUST whenever any PUT updated the current > mitigation scope. >=20 > Regards >=20 > Jon >=20 > -----Original Message----- > From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of Konda, > Tirumaleswar Reddy > Sent: 02 November 2017 15:37 > To: Jon Shallow; Roland Dobbins; dots@ietf.org > Subject: Re: [Dots] Overlapping mitigation requests from a DOTS client >=20 > > -----Original Message----- > > From: Jon Shallow [mailto:supjps-ietf@jpshallow.com] > > Sent: Thursday, November 2, 2017 4:55 PM > > To: Konda, Tirumaleswar Reddy > ; > > Roland Dobbins ; dots@ietf.org > > Subject: RE: [Dots] Overlapping mitigation requests from a DOTS client > > > > Hi Tiru, > > > > I am having programmatic challenges here with your comment. > > > > Case 1: PUT request for same mitigation-id is identical (apart from > > maybe > > lifetime) > > > > Mitigation is refreshed for another lifetime seconds(or infinite if -1= ). > > > > Case 2: PUT request for same mitigation-id has a new mitigation scope > > - lifetime may or may not be different > > > > Old mitigation is overwritten with new scope parameters - is the > > mitigation lifetime refreshed for another lifetime seconds, or the > > remaining time of the mitigation left unchanged? > > > > If the mitigation lifetime is refreshed, then why do we need Case 1: > > with a MUST? >=20 > PUT allows the resources to be updated (see > https://tools.ietf.org/html/rfc7252#section-5.8.3), so all the mitigation= scope > parameters have to be re-conveyed in the mitigation request to refresh th= e > mitigation lifetime. I don't think DOTS should lose the flexibility PUT m= ethod > provides. >=20 > > > > There is a second potential issue with Case 2 - what if there is a > > later mitigation-id also active - no overlap conflicts with original > > scope, but then has an overlap conflict with the replacement scope - > > do we auto-delete the mitigation-id that was just updated ? >=20 > For case 2, the DOTS client should either over-write the later active > mitigation-id or create a new mitigation-id whose value is higher than th= e > current active mitigation-id. >=20 > -Tiru >=20 > > > > Regards > > > > Jon > > > > -----Original Message----- > > From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of Konda, > > Tirumaleswar Reddy > > Sent: 02 November 2017 10:41 > > To: Jon Shallow; Roland Dobbins; dots@ietf.org > > Subject: Re: [Dots] Overlapping mitigation requests from a DOTS client > > > > > -----Original Message----- > > > From: Jon Shallow [mailto:supjps-ietf@jpshallow.com] > > > Sent: Thursday, November 2, 2017 4:00 PM > > > To: Konda, Tirumaleswar Reddy > > ; > > > Roland Dobbins ; dots@ietf.org > > > Subject: RE: [Dots] Overlapping mitigation requests from a DOTS > > > client > > > > > > Hi Tiru, > > > > > > >> > > > >> ... but all the above still does not answer what happens when > > > >> mitigation ids wrap back to 0 ! > > > > > > > I don't see a problem. Mitigation-id can take up to 2**32 values > > > > before > > > rolling back, mitigation-id typically will have a > > finite > > > lifetime (unless indefinite lifetime is used) and PUT allows the > > > client to re-use any > > > > > > > existing mitigation-id and overwrite the mitigation request with > > > > updated > > > mitigation scopes. > > > > > > [5.4.1. Requesting mitigation] States > > > > > > " For a mitigation request to continue beyond the initial negotiated > > > lifetime, the DOTS client need to refresh the current mitigation > > > request by sending a new PUT request. The PUT request MUST use th= e > > > same 'mitigation-id' value, and MUST repeat all the other paramete= rs > > > as sent in the original mitigation request apart from a possible > > > change to the lifetime parameter value." > > > > > > So, my DOTS server currently rejects any PUT with a mitigation id > > > that already exists that then has a mitigation scope change. > > > > I don't think this behavior is correct, PUT allows the DOTS client to > > change the mitigation scope for a mitigation-id. > > "MUST" is used in the above line only to suggest that mitigation scope > > must not be changed when only refreshing the lifetime of the > > mitigation > request. > > > > > > > > You could user a lower mitigation id that is no longer in use to > > > update a mitigation scope, but if there is a scope overlap, then > > > that too will get rejected / ignored. Some of the DOTS agents are > > > likely to be running for years, but I guess that even with a new > > > mitigation id per second, that is about > > > 68 years' worth, so we should be OK! > > > > :) > > > > -Tiru > > >=20 > _______________________________________________ > Dots mailing list > Dots@ietf.org > https://www.ietf.org/mailman/listinfo/dots From nobody Fri Nov 3 05:38:27 2017 Return-Path: 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 EED2013FAFC for ; Fri, 3 Nov 2017 05:38:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.92 X-Spam-Level: X-Spam-Status: No, score=-1.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=thescout.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 k-zHhjlPY0Ay for ; Fri, 3 Nov 2017 05:38:23 -0700 (PDT) Received: from NAM03-CO1-obe.outbound.protection.outlook.com (mail-co1nam03on0108.outbound.protection.outlook.com [104.47.40.108]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 48F1B13AF75 for ; Fri, 3 Nov 2017 05:38:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=thescout.onmicrosoft.com; s=selector1-arbor-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=anFB3Eu+5vGfdrs+k8TIzaoBjqP05q7M9I2Gz0xQF9A=; b=gwTd3lAFNHYYaspfgb1xNhb7vN9Mwz/IBYLeXm882wQA1qrG9m7qT7/Lt4JZaq1ThmY4WKJxKe3kZ6bpreksVm6L0aSoLwRNRxNcnEgMdYDSOmx1VOi8Uk8VfE47M9J/NTFzWHpn0h8Eo3eKSerq1WW+VobJxfF493mwThZKZpY= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=rdobbins@arbor.net; Received: from [172.19.254.109] (184.82.238.135) by CY1PR0101MB1035.prod.exchangelabs.com (10.160.225.14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.156.4; Fri, 3 Nov 2017 12:38:20 +0000 From: "Roland Dobbins" To: dots@ietf.org Date: Fri, 03 Nov 2017 19:38:06 +0700 Message-ID: <17B5F5AF-F4D9-41DF-8ACF-80000F731955@arbor.net> In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.7r5425) X-Originating-IP: [184.82.238.135] X-ClientProxiedBy: HK2PR02CA0178.apcprd02.prod.outlook.com (10.171.31.14) To CY1PR0101MB1035.prod.exchangelabs.com (10.160.225.14) X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 4b1d6de4-e33b-4cb5-3670-08d522b7c469 X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(2017052603199); SRVR:CY1PR0101MB1035; X-Microsoft-Exchange-Diagnostics: 1; CY1PR0101MB1035; 3:RvxbVefnke1r0mKr7mR8L+jBJd/HcWGEPNASC+W6BmWlztxuI1pLZZROl5yzJM/mJSjHl4lnXS1O3TM4lsOeZIQlAhW8xn6Ai1MzDh/IkWdFLXzxkMVtYb0DkBNRj2pdWKBPmnENKecteFfVHAklOG6xXepOXzEDJvkGj/BRNPCI5YK1chAot8x404Kt8KrO3QkDA08UUsVEIG0v3s9go64ZgK2o3oTbo5o6KaRiBbpGLvBeKQJQdCBsAjSzLECs; 25:fhm2en2lHRbz3Xao6k0BI+32r9cI+f7/i5QOfdQjgJ6iGbwbx2MjJRETAtyZInu8H/SwGi8R4arwg55VhV0/dv6O3szTzpoD+SRRNC/iQ807xi3BZRGG2BDOWRlTYQI6DYC1O7Zkuhmjd7Cw5nciinKkUAppZL0g6f94wQcy2LnDA20htYnVuq3k8JDQ6zbfUF3++CdiowD1xL/25G9TilPkfnaGzyC7CsJ3VhuW1B+K+9h2TpkasXknNUrfD72QlHsNAfgwONaAriB6HQTjwUPzELDndClFWzrfZyjrubNXeBQzwcCFxyCh04Vr5hDRRJWhcbFdzSWcvC06jDsLh3r9zJZ8C50X6b1wyG3C4ZI=; 31:RUK5MH8QU1xsFPf7Ht13YMhe2pGRiQl0rpFbO3Eo9VK+FDisNoV10XYHNjS5MBzXQgvXXygZYjGeXsTh1zUgfHlA7GtatzwzURE41zw8FXXGwBLY2t6uXwo84gL6sT243/6IwjSXfNvSy0G3Nbmw9spj7sPWYUo3lMXrKytGmUt3sofD0KDW45A2N5+XHPcTSecDJJOSFe5i/4gZ/9C3KtDElkavHIU2NavzIHbMMNU= X-MS-TrafficTypeDiagnostic: CY1PR0101MB1035: X-Microsoft-Exchange-Diagnostics: 1; CY1PR0101MB1035; 20:/d4eGXUlDwSO83/YHD1KAgrMGQMdFkIRMzO6ZCcwZUjG3tIqq7e7W1XKuzlvdFj0vYDCjYHot1BYcCPkpJEu8gGaSg9tafsdbOVkKydqAIhS1hde8LFvGzJrvO4Hcp4uEHAGYDuFv1tDqp3FuFyE7BWuS4L7b1QQGSFoILu6kMhbvWlUND9aUs5xmNa0kySofpQrO6K48KRM0DZ4suPyUh33vKwFr2PIt/do0HXth3OQ6uTEsiaV9BuDGdhDsy/SzJtvrpkQodGHAzY9NSs5XEk6tVeiAhHbr2zl0MSU74ZFD4knLnbts++/3v70G8zIPq398n1irvh+V/s9Uvvx6Eih+/lT1YiOj7itJkVoHMQIquEcCTIpX7xOkz/ICaQhWKsHS7Oj/2AuPTSrNtrQmdP33KZ7irW7uQiCwEnWW4wZzbnYRULUa3O+5jQgLIor23Lqftx+2t2pUHeNLcEkVDEUNVt+zYk1t1g1Uaeimu/cBQoxnVM80ISY8U5vHquB; 4:/NYIuSUNMu/Hwpz/hkUIdsApce8tvcGa4a9vB3FgcvmSj+1xp41oK0Qf2kPuj/GUaefjdQDqaAbzUEx0l9k5D5SCSMWpBHJz1C8/j+P8lLt/M90NBTdpgImVRECkM5r58KGZfhdgldj59vqQ3JzUW41flZQIdkc+T5o4uWa26QfdKen/CHtfnBPrwZbCQU2GQcJURrzBoyI+eJJG51qTYmg9C0yFssjbjJy+lZCWwFzbGXvEckjX/gwa82m/Sur0 X-Exchange-Antispam-Report-Test: UriScan:; X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(8121501046)(5005006)(10201501046)(3231021)(3002001)(100000703101)(100105400095)(93006095)(93001095)(6041248)(20161123560025)(20161123555025)(20161123564025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123562025)(20161123558100)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:CY1PR0101MB1035; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:CY1PR0101MB1035; X-Forefront-PRVS: 0480A51D4A X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(6009001)(6049001)(346002)(376002)(189002)(199003)(24454002)(16526018)(5660300001)(83716003)(5003940100001)(53936002)(76176999)(66066001)(47776003)(189998001)(6246003)(53546010)(6916009)(6666003)(25786009)(478600001)(16586007)(86362001)(316002)(97736004)(16576012)(81166006)(8676002)(68736007)(33656002)(2351001)(81156014)(50226002)(50986999)(229853002)(2361001)(6486002)(36756003)(90366009)(50466002)(77096006)(101416001)(82746002)(7736002)(67846002)(2950100002)(2906002)(106356001)(6116002)(105586002)(305945005)(8936002)(230783001)(3846002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR0101MB1035; H:[172.19.254.109]; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Received-SPF: None (protection.outlook.com: arbor.net does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; CY1PR0101MB1035; 23:QoU+iiZG3r4tIMKtbTx2rWLumG3eUcordU92buo?= =?us-ascii?Q?EJXwCjwwHB9GbYMjhgEPlrwzAUutKYKvKy3tzKmMMD9AzKvQh46UXcXn0Umj?= =?us-ascii?Q?0BtmFB5LrHc1HlMmm19g4r3VkkqEXIGVe6qHB8V63hgUyVSR/Bcwbt7XtDOy?= =?us-ascii?Q?g4aXRUJ7yPj908kdQTFPZURy3lYRXt8BAwP2Ln3Z1oDCRrkVqSBx5m81dgbO?= =?us-ascii?Q?qzcZc4PpCUDtY2LdvEQfAIbzK7reCHCgvUZOoMlgbtHaP3qmxwh1jiYWPq0n?= =?us-ascii?Q?9wduxSQ8C4uHU9ThHQAiCJbb+jOAJ7+QBnzkqfsyOTqSW4GEFQmI3pfWhT/Z?= =?us-ascii?Q?a2/6n5hPrGS9boypTz3kOq7MevD3d3QuuxXDTU8V9KuQSSvPs/MCpF+Q9Oda?= =?us-ascii?Q?v4a8uAfmrhqjUtJyFkmFznR7vkVKMbXXgf7vDsyaNak05XS0TdEDcUiICHGe?= =?us-ascii?Q?vRPb55ZbGdv4x65LBthQQXjf/mWM0hnwNPkhD9qUvDyUh1zwCw7aGsWf9opj?= =?us-ascii?Q?LMl2RZCI8y5sblZ4towpsPVph/S+KI5lQOhI49ZIZfywjmKdhvla6Hgduwit?= =?us-ascii?Q?opzvm+cHRd8LpsXPRE4wjUQ80XE7P7g26ug/nd5+cyzBoTDseweM3rcYWism?= =?us-ascii?Q?6w41APKBp9ejQxBZkzdjy192IkBXPN+8uzm18RJn6bTuqGLkVBmdAmAnHMur?= =?us-ascii?Q?5T8M40QfBKr50uv4Yng+xFifyXidmJzLBx3OYLLrF19g2y96tnertvrTEQlR?= =?us-ascii?Q?5KDMKUdJztr5pWsO+Qp3nFZDfLA8V9J4MyC/FXEG7AZr29GqEwjzgw2aJ6Gb?= =?us-ascii?Q?9Zf2Yb9vVz1X5XzihwgqQB0Rn0xFVZd4/lxhrYrUSOMs92Gbcs8LTTtjvnQw?= =?us-ascii?Q?NshImzWJ19yAf4FdowvV8rTfv6KOyKesEJVm50h/CR4gScTHhm4hI1oMSmIm?= =?us-ascii?Q?ylGIaatm6QYGccPkjOM+KxHbI6wQ/NrWnpuzEadeFX5UWaDOJLEBKkH1F2Ns?= =?us-ascii?Q?yc6tFvqnFq8CqsW8blabXpkVuhyj0VG5Cdpn8jHd95p2V4cJMCKstUj5J0Hb?= =?us-ascii?Q?WeXF4BfN8XiUGc0O6rng/fvztZb4vQZivMqldANTmRPcUHBYSjDEr8/xQnyI?= =?us-ascii?Q?esxx7UIvNQAsc13GKKv9BzNJR+TFr8OAG3UtiB7O/0PdOZBqBIcF3gzSzOXX?= =?us-ascii?Q?por2juOy6klxUfRVK3BYhIRfGmlTMIkdibYb4Gct34Ke6NzmKVWWlNoiSUud?= =?us-ascii?Q?kZIXdrYLUiJ2K+8O+1UnuOJ8SM4D69Z2dWJzPvt5n?= X-Microsoft-Exchange-Diagnostics: 1; CY1PR0101MB1035; 6:7yYul0v3xhh4Tv33av9+FqQWu2dRAame95jeRBtJq2k7Tdd0rWezfhH+c7DDZIZ0wTYRA9TZk8BwvJuQ0p2KR15L8J0GGTjwX77Nq3RMEPHmTwahkZ0RXiZ9u49MIRxvuHndFKIdxkNs0Y00YgpWb0GJ70QtwCEF/DDwS+YtN+XGAcnB6Y0MtzwmzZyQvqLYNLo3AQEO3JvW8lBnv+XG0QXfpRT8Cj4d8UXn+BF99nnohqke29S0QMq1lPXN6DZLkhEttp6LISkXpjTwmts3U7z1dBj8pJfuCCDVN7z/uC9IiljqppqrhzMLBkbJkt1HNlGLHgyTRh7oU8L3M+l6ZA==; 5:Ox6rWF1tZt58KOMb2WczVBrgHc2DmOLslBMT7O11Wdy+fXLPv5BrxAe6pqttGV2CoK5MDeYnBfsLumd/RDGPJQeJlwV0/Zwf8XkUt1S5aEu9we9GoK9Ztox46a+seXsOpBhwf9DmQpwP8S0cRepDVw==; 24:wIDNpmM7xVbIF3Zkt2EElgNzIj/oMOl2QYBKwICsQMJ19ydwHpGFBC3u0bP59eNCyxGjCd8HnmYa0EBGefz09X20egsb/sT39u9dnC9/9j4=; 7:TwyEsbgnxoMfwNzpl+KMDnfDcFTWHuKA8aERY9WbWim9nvFAxiut0Dtuagon5j4hPEHIrj+E47tls/HTzyI3EfU74Odgkk3TeL0fc9Ca9dBaH31TCUkNMWlM+b9fjIN+Y7jEXosnbORsScVGsPh9WiwYNELXCZl/CvHzpYOP7qjVicq3MkRMocqBHaDzubGqONu4uJGTRClJY0gEXyYkIY55pqkPRDxCCB1yn4Gd8gM= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: arbor.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 03 Nov 2017 12:38:20.4726 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 4b1d6de4-e33b-4cb5-3670-08d522b7c469 X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 54f11205-d4aa-4809-bd36-0b542199c5b2 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR0101MB1035 Archived-At: Subject: Re: [Dots] A few suggestions for draft-ietf-dots-use-cases-07 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Nov 2017 12:38:26 -0000 On 2 Oct 2017, at 17:38, Artyom Gavrichenkov wrote: > == > 3.1.1. > - Paragraph 3: "is performed" -> "are performed". > - I propose changing the use case title: > "End-customer with a single upstream transit provider offering DDoS > mitigation services" > -> > "End-customer with a single upstream transit provider offering DDoS > mitigation services on demand" This is a needless change which does not offer additional clarity. > - I propose adding two new paragraphs after paragraph 7, as follows: In earlier drafts, we had a scenario in which the upstream mitigation provider couldn't immediately fulfill the mitigation request. It makes sense to revive this use-case, minus all the speculative and situationally-specific flowspec details posited in your sample text. > > == > 3.1.2. > I propose a new paragraph (IPaNP), after 2. The motivation: this is > what already happens now, ad-hoc, via phone or instant messaging, > without DOTS and/or any mutual agreements between ISPs. Therefore, it > makes sense to cover this case in the process of designing a DDoS > mitigation control protocol: > > In case there's no such agreement between the upstream transit > providers, the DOTS client may still decide to share the > information > and statistics obtained from one or more of the upstream transit > providers to others by unicasting or broadcasting the status > messages. > An upstream transit provider receiving this kind of data may then > plan > the allocation of its mitigation facilities with accordance to the > current risk level, as seen by other upstream transit providers or > the > enterprise itself. There are no plans to unicast or 'broadcast' DOTS messages except within the context of a DOTS peering relationship. > == > 3.1.4. > IPaNP, after 5: > > The MSSP receiving a request to end the mitigation may be unable to > act accordingly due to reasons similar to what is discussed in > 3.1.1. > In such case, the enterprise may react with diversion of Internet > traffic destined for its network back from the MSSP network > facilities, or may wait for MSSP to effectively stop the > mitigation. No diversion takes place unless the mitigation request has been accepted. DOTS clients are always free to request mitigation termination. > > > == > 3.1.5. > I propose changing the paragraph 2 to the following: This level of detail is unnecessary and does not add to comprehension of the base scenario. > > > == > 3.1.6. > I propose a change to the paragraph 1: > "router, layer-3 switch, firewall, or load-balance" > -> > "router, layer 3 switch, firewall, IDS, IPS, Web application > firewall, > or load balancer". This makes sense. > > > == > 3.1.8. > IPaNP, after 3: > > Note that only the messages directly related to the DDoS attack and > mitigation status should be passed between the DDoS MSSPs via DOTS, > both in the request for an assistance and during the course of the > attack. The exchange of the rest of the information that may be of > use in this scenario, which includes interconnection metadata, > logging, authorization rules, geo-blocking restriction policies, > and > similar data, falls out of scope for this document and must be > implemented by the means of other protocols and interfaces, such as > Content Delivery Network Interconnection (CDNI) Logging interface > [RFC7937] or CDNI Metadata interface [RFC8006]. This is already understood and there is no need to reference CDNI or any similar protocols or interfaces. > == > I propose adding two more use cases, as follows: > > 3.1.9. End-customer with an upstream transit provider or MSSP > offering DDoS mitigation services on the permanent basis This makes sense. > 3.1.10. Community member notifying CSIRT about the attack This application is outside the scope of DOTS in its present incarnation; exchanging flow telemetry information, would be required in order to provide the requisite information to make such an information exchange practicable. > == > Also, please consider updating the Github repo for the Use Cases > draft. > It's now on the version 05 while the most recent one is 07. Yes, will do. ----------------------------------- Roland Dobbins From nobody Fri Nov 3 07:34:42 2017 Return-Path: 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 30D8013FC10 for ; Fri, 3 Nov 2017 07:34:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.69 X-Spam-Level: X-Spam-Status: No, score=-4.69 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, SPF_PASS=-0.001, T_FILL_THIS_FORM_SHORT=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=thescout.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 lhqi0rB1p_Us for ; Fri, 3 Nov 2017 07:34:35 -0700 (PDT) Received: from NAM03-BY2-obe.outbound.protection.outlook.com (mail-by2nam03on0120.outbound.protection.outlook.com [104.47.42.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0B94713FAEB for ; Fri, 3 Nov 2017 07:34:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=thescout.onmicrosoft.com; s=selector1-arbor-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=lZuplFMwXIBGbgWXyQabAbGIVwF6/or+DmB5xTKKJSQ=; b=PrnhYjvsntfdbxBugMbP35pbFCSyVBs97oJQk7aN3S76V3mo6ogPJEmb1qRL43NjNYuzwxLLhWz/6MGUw1XblVcKXFf5yTy4ZeT1d31HFxMKwiaVzzNOB9VizF56vuw5tNMJwSZHB9BKRUiAG9aum6W8yypY/5TfCEBkgWK3uvg= Received: from [172.19.254.109] (184.82.238.135) by DM2PR0101MB1039.prod.exchangelabs.com (2a01:111:e400:3c19::28) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.77.7; Fri, 3 Nov 2017 14:34:28 +0000 From: "Roland Dobbins" To: dots Date: Fri, 03 Nov 2017 21:34:14 +0700 Message-ID: <45D6E0F2-3072-4F27-9E5B-050C5D0AA344@arbor.net> MIME-Version: 1.0 Content-Type: text/plain; format=flowed Content-Transfer-Encoding: quoted-printable X-Mailer: MailMate (1.9.7r5425) X-Originating-IP: [184.82.238.135] X-ClientProxiedBy: SG2PR06CA0097.apcprd06.prod.outlook.com (2603:1096:3:14::23) To DM2PR0101MB1039.prod.exchangelabs.com (2a01:111:e400:3c19::28) X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 6ec085a0-f7ab-402b-dd27-08d522c7fe0b X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(2017052603238); SRVR:DM2PR0101MB1039; X-Microsoft-Exchange-Diagnostics: 1; DM2PR0101MB1039; 3:Bi2lgKHXGXN/yZ0Dr940jEzcGfqhT5DuAEJhGRnGhr9qO1GQcuMDZyTrBq/0Qx2BR63hqRKQnh95054x8rV5P7pqGRxwrn5XFOFowb57KpA0vUdPg54RGeS+q+wAe6/uk9AOfZdQuECDTUqXSsQj2Kk2SfV9BH3LSknkEJSgV5ItsF/3+0C82uIvkdWChfCUPmPtEx6zn3HdW/siA8Bn6EqGR29khQPwPAU10wzpsF/ysqrLmRcSLk+gdJNR1Q+X; 25:UtutG0/6H5a7sA58sUiZeqj2Vi8X/JdAs3qF5JkvcZI//VMBMEajdtVzp9BRmlcIahfbXwFaYvdimk9nauBtq3JFV21CR6UB/Wqdp3YXpsOO5cWpGwKo3VEqUsrtrhunGCfz76qx2kPilPCW9F90phFIi6MDzTObk+qalQf/kY+t/sioygskY1A/VcV21TSqpDMgQvvYCjDQEUeOUsfcgsB+bdptM3Tb6KWLAU07cE9oXrE5aAn9t59pqTW8LCu0hbif2IZAGwJ++V8WM66abz7jReWiJdR72Zvt7HJHaCxP7dGiRcli+htCqCB2gWcmm61pMk4RORj781/grMYO1A==; 31:S8EY98BumiA4Jgh7T+BtomGXWmQ7QNGFuWqiFfkiZF64ft6UL/Y+0JHNvhmShx36d4emx1aFEYCjiy9zHjcrv+zKtZ2DjUIzNgW7YhYXicz2q/IvOpErBLuLNBLxwNqHOWMWxwstZrPqrGkqeswCVLYavaezVGab7TUgsg1mm3QpDA31UpHjb821xD3wofB0liI6+WMzsI7v3xssoDMF82v0ANhVNKnHSh4le2A6Cnc= X-MS-TrafficTypeDiagnostic: DM2PR0101MB1039: Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=rdobbins@arbor.net; X-Microsoft-Exchange-Diagnostics: 1; DM2PR0101MB1039; 20:2ZsjrGUxY5uF5OqCYKPmUa6uOHyddXchZm8U727KgM7rhKvWirJYiJVLtPEmWF4QnnhXwfnc/nIsU4OtNMBaQGcFcCgqkeL8bvqU/W8by/qKYT7Eqh8yUuevcQu2EmYQRO5ZteG9fQLy/bljQHOvL2Onb0vH9NLsen7QDFI/PTyXEmeHg2+psXBVW5GCgBsTE28TTNC3kBFTfY2h6adtOEe4VdmC9VDwGqItm5UyFN4KchT8Lsn6N9jLAipz04pkEC0uGieTp4NPUQ6/22Ii3VF5mjrh16QuS69BZkBjI4ddrwlqLK8fhkycp47mSPw+7qART3a70YN0FerFGwYdL4WzYYsSsWu/MNUsDvVbPt+Wweyz75hPo41xnnxlug2+pn1f6CzYSVF3F6T2VNque+4FSqGxYlH/lW2ePc0oYPn2mFXV99NupZaSNVT/3P2OZ6Hv+khfCejwM4KmfkH6afFM6hm0Q2+x6R1OukTGW5d5JwcWMM1h7py+LIESB3Yi X-Exchange-Antispam-Report-Test: UriScan:(37575265505322)(158342451672863)(278428928389397)(43178223235956)(72170088055959)(120809045254105)(209352067349851)(192374486261705)(131327999870524)(50582790962513); X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(8121501046)(5005006)(93006095)(93001095)(3002001)(100000703101)(100105400095)(10201501046)(3231021)(6041248)(20161123564025)(20161123562025)(20161123560025)(20161123555025)(20161123558100)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:DM2PR0101MB1039; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:DM2PR0101MB1039; X-Microsoft-Exchange-Diagnostics: 1; DM2PR0101MB1039; 4:p/pZ/ZdrmsCADigF45GuLvPGGE/mRu7R0dg6chPIWsBMfrerFJcP4uu1vH7cezc4jzomKYuVrgdvY497SGyPb9r04TbUW5GXappzp3ti3x8cBaSb7UsmtSWPxGc2ouADJIOv4IECjd0W4eoqPExf9HkUuhYFnqZCZugVYjgzuWOK/ZogdMJtMUBBWLbsBE22WMAqYj/wIxottJHg5KqpVZ2e/eSvXnel3j+tj2HDVyWC8WFy/yI8RQWcelr6w8ydzXSseK1P3SVMnlANGc2q5ncvX0sg9BQvIc3bTiGdnXhfxBVXFm/xA1OTC+vYw1V+23cwbaGzf/+xh18u0tQdL99mZd6A5mbQEBHVJvqR0GHDAfJGabz2GSxPfuUv80raeja0dTqV6j+50LiU4GPe6dk0cfSs7Yam6k54ZGA7yVJO3ba5IxKpBu0Dh5lg4ZYxMfhzZmSvJQBcg1AmoYKZtIManZTIxVWq917sowt/CRVF8LEN3IspWIu6aFWheZsU3pJzZ0MBIaIjzRNtUgQ1VFAbr4tiP1nzEXsx6sIHZhpl5I6y5TcW1CFehYbuidhBEDV8sh2q+c1VQ+RzCzPAySyWuE6kzc6PVDM09+oyL7M= X-Forefront-PRVS: 0480A51D4A X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(6009001)(6049001)(376002)(346002)(189002)(252514010)(377424004)(15374003)(199003)(8936002)(16526018)(25786009)(6916009)(7736002)(83716003)(50986999)(105586002)(86362001)(68736007)(966005)(566174002)(50466002)(101416001)(106356001)(77096006)(6486002)(6116002)(33656002)(97736004)(230783001)(189998001)(6666003)(3846002)(478600001)(5003940100001)(5660300001)(50226002)(316002)(16576012)(53946003)(8746002)(305945005)(53936002)(8676002)(2906002)(82746002)(66066001)(67846002)(81156014)(16200700003)(6306002)(36756003)(81166006)(47776003)(569006); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR0101MB1039; H:[172.19.254.109]; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Received-SPF: None (protection.outlook.com: arbor.net does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; DM2PR0101MB1039; 23:pPfKOA97flVujVKHA60uzvSmjuRv335ruumwKUs?= =?us-ascii?Q?8v0gSUYW9wsaHNRizQIFzyHnLmxSA9EpYqSqMFod2SffliyElyhbE2gtFQnu?= =?us-ascii?Q?Byhfgv0ftjkjDxxE8r5/axk10mO9Vn0yldhApUzVqjuE2fpzT0Ma00G3gMrZ?= =?us-ascii?Q?hjjxMPzs9c3T4t0mAU61tYjborMur7fLdJaSg6UGiXRQAJy/J3UWsJCqbFkO?= =?us-ascii?Q?QP85KZjDR0ZlJldb+6onGmE2BM1a5FsfKEqrC9ObpexnQNsqhpSBqBXhflYk?= =?us-ascii?Q?LcXy8Qh3QFbpp6vmn+k4Wu5cbyLk77hWg67+DOG6pNdTW9GsoWngcp5/SZB+?= =?us-ascii?Q?OemhxkcWKb3/BjHzTPOzrfjJQkKxzYuziT1n48h/9Rr0gHjWcqt8H34fzDHk?= =?us-ascii?Q?aH6OFymJ4qr41fEg1vqs2h7RE04DpNrretZMyhFU8cKCTrSP/m/g/QxL0rVP?= =?us-ascii?Q?wg6aRAkL9Xl6OEC7HYe03sIFPpv41dsCa4Ka74r6HDwCscHu3JItSnO0z7Qb?= =?us-ascii?Q?VSkQnzhgi1se67c6WGCHPe/c7p/ccFtTfpL5khKJ07coB1yGK15sZuOG2lSQ?= =?us-ascii?Q?gdKXxqD6yogEEBXMRmV3C/eyLc5xo6Zja8C39FdekFkDRcyTCeb4CnOsb3I2?= =?us-ascii?Q?QehZrzPOU+pDVRaCeu/qt6hEmz+IoQ1AvtJQl3eorVxZ5bQxnaiam/bXF9sR?= =?us-ascii?Q?PD1eLZMDLq5P3izPp2onoPEnq7QyhJG7LFK2LPcqLfdjaoqkGaeUvQ2SuTct?= =?us-ascii?Q?QN8stZHu2L/sGGiNB/1WEW7JlzPRP4R/5eEdh+FiEYH0QAo4VSIxSNRTDSaw?= =?us-ascii?Q?eCd89d0whaayRUPFG+ZITHgcgfK9GdaQ10s2idKpg1FS2qkRXsLxFjAc90q8?= =?us-ascii?Q?AZwXNYjpa3L/2zaw0lwWZpv93xDUBH5/h9U/2jHmeeNmQYkEo7ZktqxdNVcM?= =?us-ascii?Q?AQ1fzVi5aGmcGSt+UXoFM0aj7IuCzy10q1h5bx5+tDYC+/VN3YGBkB9sszL/?= =?us-ascii?Q?iw4vb/RfMrdlXRlDASbiZsBBmfjGZHsjN+gTHJd1EPoWjp1Es3USRjNrkZ0x?= =?us-ascii?Q?yAwETIYBvn8SZg32N5UEmgjV+bX9LMnqTC5ZSxAi7QF494h/85Zoh/FrSGUS?= =?us-ascii?Q?r6S5nrElmcV+yqLoGkviJb30FCfwY8phRo+7bLxOQiUBHsi76cGCmyqucCNP?= =?us-ascii?Q?gdJptQYuhh95xCuWDFl1gPfcSccf7dQrlGY2bgwB51Q3+lr7zXGv9brExYy0?= =?us-ascii?Q?gTlr17lEaxr3cOmBNhK+STQs136LBUXtwABPcC8SI?= X-Microsoft-Exchange-Diagnostics: 1; DM2PR0101MB1039; 6:RukiO+t7vWc3HsbGF79dggNTQhA+AnMLl6YmSZVZI43eB0MugrUHt21OY9Whi+6qk36+2t7mLHs1Qdo/a0s7y6g14cGaaDvjjWfzKPo8fD6lES9jbk8wOI8LwTxBgRtEW18+z1kcPpQuvmOIZB5mQzaH8irj+tL9/xDvhFx0Gzd9o435y7VZ294CnrUC4dJRUfSsAwyqv05s1qrhUz2uOv16EhZWlyvEQoZdjD2IqjomSHktTqsIwA13E5vmAXjOXLu6dCZt9kzbJqUGYcAlwiaoIS8w1d1mbMSaVpS4QbcreCzACluQNVrHoYjdH6dWPoWPMxmZfiXnPGL7CToicw==; 5:hrnp31pU7GintOB0Xgn3GDNqPd851q+JDRJuwdEmJf52jPLrNjbF1zcKAOQb3VmenGdURFAVwd6I+hXt8L9jFu9xmvmAwVEaq5K5VXggF4STwgVCW+iyPgz0Dipu7E5t+mKWXkUwFeExbPLYUDBr6w==; 24:t6tMcRr0QqLmtlETGbdwA1V4wMYBZST3z8a0SX5BccmtVTi1lSbIP0u1r3EDbx7GcGLAGrAG9DqRJNYZ74uTVBe/Mk3QgEcyjNi5a9W0mZQ=; 7:kdO+EXbl8tP+srfxtIYP34TtfeC+gUVbW4nlEIql18qWOK/F3ym/FD67mTMvgh/7TlcQ6kyjy4/pyWRT8y+BSjwF3GnVyOObAG/bV1aZQVrHZmZPnq4iTCh1oaUdTuENXcOjI0BwSu11jaGTwubGggoQzq480Ckt9hbxHobAWaMXVH/vBQusZGJJZ+iHmmikWm4CXz/guc8ys8QwNsgy2wZSwQcDW+eVX8rCqbj66Ks= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: arbor.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 03 Nov 2017 14:34:28.9288 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 54f11205-d4aa-4809-bd36-0b542199c5b2 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR0101MB1039 Archived-At: Subject: [Dots] draft-use-cases-09b. 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Nov 2017 14:34:41 -0000 This beta of -09 incorporates feedback from Kathleen Moriarty, Roman = Danyliw, Daniel Migault, and Artyom Gavrichenkov. As always, feedback is welcome. In particular, feedback on the utility = of Section 3.2.2, 'Home Network DDoS Detection Collaboration for ISP = network management', would be greatly appreciated! ----- DOTS R. Dobbins Internet-Draft Arbor Networks Intended status: Informational D. Migault Expires: May 7, 2018 Ericsson S. = Fouant R. = Moskowitz HTT = Consulting N. = Teague Verisign= L. = Xia Huawei= K. = Nishizuka NTT = Communications November 03, = 2017 Use cases for DDoS Open Threat Signaling draft-ietf-dots-use-cases-09b Abstract The DDoS Open Threat Signaling (DOTS) effort is intended to provide = a protocol to facilitate interoperability between multivendor DDoS mitigation solutions and services. This document presents use cases which describe the interactions expected between the DOTS components as well as DOTS messaging exchanges. The purpose of describing use cases is to identify the interacting DOTS components, how they collaborate and what are the types of information to be exchanged. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six = months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on May 7, 2018. Dobbins, et al. Expires May 7, 2018 [Page 1] =0C Internet-Draft DOTS Use Cases November 2017 Copyright Notice Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with = respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . = 3 2. Terminology and Acronyms . . . . . . . . . . . . . . . . . . = 4 2.1. Requirements Terminology . . . . . . . . . . . . . . . . = 4 3. Use Cases Scenarios . . . . . . . . . . . . . . . . . . . . . = 4 3.1. Inter-domain Use Cases . . . . . . . . . . . . . . . . . = 5 3.1.1. End-customer with a single upstream transit provider offering DDoS mitigation services . . . . . . . . . . = 5 3.1.2. End-customer with multiple upstream transit providers offering DDoS mitigation services . . . . . . . . . . = 6 3.1.3. End-customer with multiple upstream transit providers, but only a single upstream transit provider offering DDoS mitigation services . . . . . = 7 3.1.4. End-customer with an overlay DDoS mitigation managed security service provider (MSSP) . . . . . . . . . . = 8 3.1.5. End-customer operating an application or service with an integrated DOTS client . . . . . . . . . . . . . . = 9 3.1.6. End-customer operating a CPE network infrastructure device with an integrated DOTS client . . . . . . . . = 9 3.1.7. End-customer with an out-of-band smartphone application featuring DOTS client capabilities . . . = 10 3.1.8. MSSP as an end-customer requesting overflow DDoS mitigation assistance from other MSSPs . . . . . . . = 10 3.1.9. End-customer with an upstream transit provider or overly MSSP providing DDoS mitigation services on an ongoing basis . . . . . . . . . . . . . . . . . . . . = 11 3.1.10. End-customer with an upstream transit provider or overly MSSP providing DDoS mitigation services, but DDoS mitigation service is refused . . . . . . . . . = 11 3.2. Intra-domain Use Cases . . . . . . . . . . . . . . . . . = 12 3.2.1. Suppression of outbound DDoS traffic originating from a consumer broadband access network . . . . . . . . . = 12 Dobbins, et al. Expires May 7, 2018 [Page 2] =0C Internet-Draft DOTS Use Cases November 2017 3.2.2. Home Network DDoS Detection Collaboration for ISP network management . . . . . . . . . . . . . . . . . = 14 3.2.3. DDoS Orchestration . . . . . . . . . . . . . . . . . = 17 4. Overview of DOTS Messaging Interactions During a DDoS Mitigation Session . . . . . . . . . . . . . . . . . . . . . = 19 4.1. Successful DOTS DDoS Mitigation Request Example . . . . . = 19 4.2. Unsuccessful DOTS DDoS Mitigation Request Example . . . . = 21 5. Security Considerations . . . . . . . . . . . . . . . . . . . = 22 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . = 23 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . = 23 8. References . . . . . . . . . . . . . . . . . . . . . . . . . = 23 8.1. Normative References . . . . . . . . . . . . . . . . . . = 23 8.2. Informative References . . . . . . . . . . . . . . . . . = 23 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . = 23 1. Introduction Currently, distributed denial-of-service (DDoS) attack mitigation solutions are largely based upon siloed, proprietary communications schemes which result in vendor lock-in. As a side-effect, this = makes the configuration, provisioning, operation, and activation of these solutions a highly manual and often time-consuming process. Additionally, coordination of multiple DDoS mitigation solutions simultaneously engaged in defending the same organization = (resources) against DDoS attacks is fraught with both technical and process- related hurdles. This greatly increase operational complexity and often results in suboptimal DDoS attack mitigation efficacy. The DDoS Open Threat Signaling (DOTS) effort is intended to specify = a protocol that facilitates interoperability between multivendor DDoS mitigation solutions and ensures more automation in term of mitigation requests and attack characterization patterns. As DDoS solutions are broadly heterogeneous among vendors, the primary goal of DOTS is to provide high-level interaction amongst differeing DDoS solutions, such as initiating or terminating DDoS mitigation assistance. It should be noted that DOTS is not intended toperform orchestration functions; rather, DOTS is intended to allowdevices, services, and applications to request DDoS attack mitigation assistance and = receive mitigation status updates. These use cases are expected to provide inputs for the design of the DOTS protocol(s). Dobbins, et al. Expires May 7, 2018 [Page 3] =0C Internet-Draft DOTS Use Cases November 2017 2. Terminology and Acronyms This document makes use of the terms defined in [I-D.ietf-dots-requirements]. In addition, this document introduces the following terms: Inter-domain: a DOTS communications relationship between distinct organizations with separate spans of administrative control. Typical inter-domain DOTS communication relationships would be between a DDoS mitigation service provider and an end-customer who requires DDoS mitigation assistance; between multiple DDoS mitigation service providers coordinating mutual defense of a mutual end-customer; or between DDoS mitigation service providers which are requesting additional DDoS mitigation assistance in for attacks which exceed their inherent DDoS mitigation capacities and/or capabilities. Intra-domain: a DOTS communications relationship between various (network) elements that are owned and operated by the same administrative entity. A typical intra-domain DOTS communications relationship would be between DOTS agents [I-D.ietf-dots- requirements] within the same organization. 2.1. Requirements Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. 3. Use Cases Scenarios This section provides a high-level description of scenarios = addressed by DOTS. In both sub-sections, the scenarios are provided in order to illustrate the use of DOTS in typical DDoS attack scenarios. = They are not definitive, and other use cases are expected to emerge with widespread DOTS deployment. All scenarios present a coordination between the targeted organization, the DDoS attack telemetry and the mitigator. The coordination and communication between these entities depends, for example, on the characteristic or functionality of the entity = itself, the reliability of the information provided by DDoS attack = telemetry, and the business relationship between the DDoS target domain and the mitigator. More explicitly, in some cases, the DDoS attack telemetry may simply activate a DDoS mitigation, whereas in other cases, it may Dobbins, et al. Expires May 7, 2018 [Page 4] =0C Internet-Draft DOTS Use Cases November 2017 collaborate by providing some information about an attack. In some cases, the DDoS mitigation may be orchestrated, which includes selecting a specific appliance as well as starting/ending a mitigation. 3.1. Inter-domain Use Cases Inter-domain DOTS deployment scenarios encompass two or more = distinct spans of administrative control. A typical inter-domain DOTS deployment may consist of an endpoint network such as an Internet- connected enterprise requesting DDoS mitigation assistance from one or more upstream transit providers offering DDoS mitigation = services, or from a topologically-distant MSSP offering cloud-based overlay DDoS mitigation services. DOTS may also be used to facilitate coordination of DDoS mitigation activities between mitigation providers. Coordination between organizations making use of DOTS in such scenarios is necessary. Along with DOTS-specific tasks such as DOTS peering and validating the exchange of DOTS messaging between the relevant organizations, externalities relating to routing advertisements, authoritative DNS records (for DNS-based diversion), network access policies for DOTS nodes, service-level agreements (SLAs), and DDoS mitigation provisioning are required. 3.1.1. End-customer with a single upstream transit provider offering DDoS mitigation services In this scenario, an enterprise network with self-hosted Internet- facing properties such as Web servers, authoritative DNS servers, = and VoIP PBXes has an intelligent DDoS mitigation system (IDMS) deployed to protect those servers and applications from DDoS attacks. In addition to their on-premise DDoS defense capability, they have contracted with their Internet transit provider for DDoS mitigation services which threaten to overwhelm their transit link bandwidth. The IDMS is configured such that if the incoming Internet traffic volume exceeds 50% of the provisioned upstream Internet transit link capacity, the IDMS will request DDoS mitigation assistance from the upstream transit provider. The requests to trigger, manage, and finalize a DDoS mitigation between the enterprise IDMS and the transit provider is performed using DOTS. The enterprise IDMS implements a DOTS client while the transit provider implements a DOTS server which is integrated with their DDoS mitigation orchestration system. Dobbins, et al. Expires May 7, 2018 [Page 5] =0C Internet-Draft DOTS Use Cases November 2017 When the IDMS detects an inbound DDoS attack targeting the = enterprise servers and applications, it immediately begins mitigating the attack. During the course of the attack, the inbound traffic volume exceeds the 50% threshold; the IDMS DOTS client signals the DOTS server on the upstream transit provider network to initiate DDoS mitigation. The DOTS server signals the DOTS client that it can service this request, and mitigation is initiated on the transit provider = network. Over the course of the attack, the DOTS server on the transit provider network periodically signals the DOTS client on the enterprise IDMS in order to provide mitigation status information, statistics related to DDoS attack traffic mitigation, and related information. Once the DDoS attack has ended, the DOTS server = signals the enterprise IDMS DOTS client that the attack has subsided. The enterprise IDMS then requests that DDoS mitigation services on the upstream transit provider network be terminated. The DOTS = server on the transit provider network receives this request, communicates with the transit provider orchestration system controlling its DDoS mitigation system to terminate attack mitigation, and once the mitigation has ended, confirms the end of upstream DDoS mitigation service to the enterprise IDMS DOTS client. Note that communications between the enterprise DOTS client and the upstream transit provider DOTS server may take place in-band within the main Internet transit link between the enterprise and the = transit provider; out-of-band via a separate, dedicated wireline network = link utilized solely for DOTS signaling; or out-of-band via some other form of network connectivity such as a third-party wireless 4G network link. An overview of DOTS messaging interactions between = the DOTS client and server in this scenario may be found in Section 4.1. 3.1.2. End-customer with multiple upstream transit providers offering DDoS mitigation services This scenario shares many characteristics with Section 3.1.1, but with the key difference that the enterprise in question is multi- homed, i.e., has two or more upstream transit providers, and that they all provide DDoS mitigation services. In most cases, the communications model for a multi-homed model = would be the same as in the single-homed model, merely duplicated in parallel. However, if two or more of the upstream transit providers have entered into a mutual DDoS mitigation agreement and have established DOTS peering relationships, DDoS mitigation status messages may exchanged between their respective DOTS servers in = order Dobbins, et al. Expires May 7, 2018 [Page 6] =0C Internet-Draft DOTS Use Cases November 2017 to provide a more complete picture of the DDoS attack scope. This will also allow for either automated or operator-assisted programmatic cooperative DDoS mitigation activities on the part of the DOTS-peered transit providers. The DOTS communications between the upstream transit providers will consist of mitigation start, mitigation status, and mitigation termination messages. 3.1.3. End-customer with multiple upstream transit providers, but only a single upstream transit provider offering DDoS mitigation services This scenario is similar to that outlined in Section 3.1.2; however, only one of the upstream transit providers in question offers DDoS mitigation services. In this situation, the enterprise would cease advertising the relevant network prefixes via the transit providers which do not provide DDoS mitigation services - or, in the case = where the enterprise does not control its own routing, request that the upstream transit providers which do not offer DDoS mitigation services stop advertising the relevant network prefixes on their behalf. Once it has been determined that the DDoS attack has ceased, the enterprise once again announces the relevant routes to the upstream transit providers which do not offer DDoS mitigation services, or requests that they resume announcing the relevant routes on behalf = of the enterprise. Note that falling back to a single transit provider has the effect = of reducing available inbound transit bandwidth during a DDoS attack. Without proper planning and sufficient provisioning of both the link capacity and DDoS mitigation capacity of the sole transit provider offering DDoS mitigation services, this reduction of available bandwidth could lead to network link congestion caused by legitimate inbound network traffic. Therefore, careful planning and provisioning of both upstream transit bandwidth as well as DDoS mitigation capacity is required in scenarios of this nature. The withdrawal and announcement of routing prefixes described in = this use-case falls outside the scope of DOTS, although they could conceivably be triggered as a result of provider-specific orchestration triggered by the receipt of specific DOTS messages = from the enterprise in question. The DOTS communications model for this scenario will be identical to that described in Section 3.1.1. Dobbins, et al. Expires May 7, 2018 [Page 7] =0C Internet-Draft DOTS Use Cases November 2017 3.1.4. End-customer with an overlay DDoS mitigation managed security service provider (MSSP) This use case details an enterprise that has a local DDoS detection and classification capability and may or may not have an on-premise mitigation capability. The enterprise is contracted with an overlay DDoS mitigation MSSP, topologically distant from the enterprise network (i.e., not a direct upstream transit provider), which can redirect (divert) traffic away from the enterprise, provide DDoS mitigation services services, and then forward (re-inject) = legitimate traffic to the enterprise on an on-demand basis. In this scenario, diversion of Internet traffic destined for the enterprise network into the overlay DDoS mitigation MSSP network is typically accomplished via eBGP announcements of the relevant enterprise network CIDR blocks, or via authoritative DNS subdomain-based mechanisms (other mechanisms are not precluded, these are merely the most common ones in use today). The enterprise determines thresholds at which a request for mitigation is triggered indicating to the MSSP that inbound network traffic should be diverted into the MSSP network and that DDoS mitigation should be initiated. The enterprise may also elect to manually request diversion and mitigation via the MSSP network as desired. The communications required to initiate, manage, and terminate = active DDoS mitigation by the MSSP is performed using DOTS. The enterprise DDoS detection/classification system implements a DOTS client, while the MSSP implements a DOTS server integrated with its DDoS = mitigation orchestration system. One or more out-of-band methods for = initiating a mitigation request, such as a Web portal, a smartphone app, or voice support hotline, may also be made available by the MSSP. When an attack is detected, an automated or manual DOTS mitigation request is generated by the enterprise and sent to the MSSP. The enterprise DOTS mitigation request is processed by the MSSP DOTS server, which validates the origin of the request and passes it to the MSSP DDoS mitigation orchestration system, which then initiates active DDoS mitigation. This action will usually involve the diversion of all network traffic destined for the targeted = enterprise into the MSSP DDoS mitigation network, where it will be subjected to further scrutiny, with DDoS attack traffic filtered by the MSSP. Successful mitigation of the DDoS attack will not only result preserving the availability of services and applications resident on the enterprise network, but will also prevent DDoS attack traffic from ingressing the networks of the enterprise upstream transit providers and/or peers. Dobbins, et al. Expires May 7, 2018 [Page 8] =0C Internet-Draft DOTS Use Cases November 2017 The MSSP should signal via DOTS to the enterprise that a mitigation request has been received and acted upon, and should also include an update of the mitigation status. The MSSP may respond periodically with additional updates on the mitigation status to in order to enable the enterprise to make an informed decision on whether to maintain or terminate the mitigation. An alternative approach would be for the DOTS client mitigation request to include a time to live (TTL) for the mitigation, which may also be extended by the client should the attack still be ongoing as the TTL reaches expiration. A variation of this use case may be that the enterprise is providing a DDoS monitoring and analysis service to customers whose networks may be protected by any one of a number of third-party providers. The enterprise in question may integrate with these third-party providers using DOTS and signal accordingly when a customer is attacked - the MSSP may then manage the life-cycle of the attack mitigation on behalf of the enterprise. The DOTS communication model used in these scenarios will be identical to those described in Section 3.1.1 or Section 3.1.2. 3.1.5. End-customer operating an application or service with an integrated DOTS client In this scenario, a Web server has a built-in mechanism to detect = and classify DDoS attacks, which also incorporates a DOTS client. When an attack is detected, the self-defense mechanism is activated, and local DDoS mitigation is initiated. The DOTS client built into the Web server has been configured to request DDoS mitigation services from an upstream transit provider = or overlay MSSP once specific attack traffic thresholds have been reached, or certain network traffic conditions prevail. Once the specified conditions have been met, the DOTS communications dialogue and subsequent DDoS mitigation initiation and termination actions described above take place. The DOTS communication model used in these scenarios will be identical to those described in Section 3.1.1, Section 3.1.2 or Section 3.1.4, with the exception that the DOTS client will be the application or service in question. 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 Dobbins, et al. Expires May 7, 2018 [Page 9] =0C Internet-Draft DOTS Use Cases November 2017 infrastructure CPE device such as a router, layer-3 switch, = firewall, IDS/IPS, Web application firewall or load-balancer 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 as described in Section 3.1.1, Section 3.1.2 or Section 3.1.4. 3.1.7. End-customer with an out-of-band smartphone application featuring DOTS client capabilities This scenario would typically apply in a small office or home office (SOHO) setting, where the end-customer does not have CPE equipment = or software capable of detecting/classifying/mitigating DDoS attack, = yet still has a requirement for on-demand DDoS mitigation services. A smartphone application containing a DOTS client would be provided by the upstream transit mitigation provider or overlay DDoS MSSP to the SOHO end-customer; this application would allow a manual 'panic- button' to request the initiation and termination of DDoS mitigation services. The DOTS communications dialogue and resultant DDoS mitigation initiation/status reporting/termination actions would then take = place as in as described in in Section 3.1.1, Section 3.1.2 or Section 3.1.4, with the end-customer DOTS client application serving to display received status information while DDoS mitigation activities are taking place. 3.1.8. MSSP as an end-customer requesting overflow DDoS mitigation assistance from other MSSPs This is a more complex use-case involving multiple DDoS MSSPs, whether transit operators, overlay MSSPs, or both. In this = scenario, an MSSP has entered into a pre-arranged DDoS mitigation assistance agreement with one or more other DDoS MSSPs in order to ensure that sufficient DDoS mitigation capacity and/or capabilities may be activated in the event that a given DDoS attack threatens to overwhelm the ability of a given DDoS MSSP to mitigate the attack on its own. BGP-based diversion (including relevant Letters of Authorization, or LoAs), DNS-based diversion (including relevant LoAs), traffic re- injection mechanisms such as Generic Routing Encapsulation (GRE) tunnels, provisioning of DDoS orchestration systems, et. al,. must = be arranged in advance between the DDoS MSSPs which are parties to the agreement. They should also be tested on a regular basis. Dobbins, et al. Expires May 7, 2018 [Page 10] =0C Internet-Draft DOTS Use Cases November 2017 When a DDoS MSSP which is party to the agreement is nearing its capacity or ability to mitigate a given DDoS attack traffic, the = DOTS client integrated with the MSSP DDoS mitigation orchestration system signals partner MSSPs to initiate network traffic diversion and DDoS mitigation activities. Ongoing attack and mitigation status = messages may be passed between the DDoS MSSPs, and between the requesting = MSSP and the ultimate end-customer of the attack. The DOTS dialogues and resultant DDoS mitigation-related activities in this scenario progress as described in the other use-cases detailed above. Once the requesting DDoS MSSP is confident that the DDoS attack has either ceased or has fallen to levels of traffic/ complexity which they can handle on their own, the requesting DDoS MSSP DOTS client sends mitigation termination requests to the participating overflow DDoS MSSPs. 3.1.9. End-customer with an upstream transit provider or overly MSSP providing DDoS mitigation services on an ongoing basis This scenario is similar to that described in Section 3.1.1, except that due to the lack of a capable local IDMS solution, strict uptime requirements, or other considerations, the end-customer has previously arranged for continuous active DDoS mitigation coverage; thus, the concepts of initiating or terminating DDoS mitigation services do not apply. During an attack, the DOTS server on the upstream transit provider network immediately notifies the DOTS client on the enterprise network about the attack and periodically signals the DOTS client in order to provide mitigation status information and related information. The end-customer may then use this information to add capacity or implement configuration changes intended to increase resilience, to plan maintenance windows or changes to routing policies, etc. 3.1.10. End-customer with an upstream transit provider or overly MSSP providing DDoS mitigation services, but DDoS mitigation = service is refused This scenario is similar to that described in Section 3.1.1, except that the upstream transit provider or MSSP is unable to honor the DDoS mitigation service request from the end-customer due to mitigation capacity limitations, technical faults, or other circumstances. The end-customer DOTS client may be configured to make repeated attempts to engage DDoS mitigation service from the refusing provider, or alternately may be configured to request DDoS mitigation service from alternate providers. Dobbins, et al. Expires May 7, 2018 [Page 11] =0C Internet-Draft DOTS Use Cases November 2017 The DOTS communication model for this use case is outlined in Section 4.2. 3.2. Intra-domain Use Cases While many of the DOTS-specific elements of inter-domain DOTS deployment scenarios apply to intra-domain scenarios, it is expected that many externalities such as coordination of and authorization = for routing advertisements and authoritative DNS updates may be = automated to a higher degree than is practicable in inter-domain scenarios, given that the scope of required activities and authorizations are confined to a single organization. In theory, provisioning and change-control related both to DOTS itself as well as relevant externalities may require less administrative overhead and less implementation lead-times. The scope of potential DDoS mitigation actions may also be broader = in intra-organizational scenarios, as presumably an organization will have a higher degree of autonomy with regards to both techically and administratively feasible activities. 3.2.1. Suppression of outbound DDoS traffic originating from a consumer broadband access network While most DDoS defenses concentrate on inbound DDoS attacks ingressing from direct peering links or upstream transit providers, the DDoS attack traffic in question originates from one or more Internet-connected networks. In some cases, compromised devices residing on the local networks of broadband access customers are = used to directly generate this DDoS attack traffic; in others, misconfigured devices residing on said local customer networks are exploited by attackers to launch reflection/amplification DDoS attacks. In either scenario, the outbound DDoS traffic emanating from these devices can be just as disruptive as an inbound DDoS attack, and can cause disruption for substantial proportions of the broadband access network operator's customer base. Some broadband access network operators provide CPE devices (DSL modems/routers, cablemodems, FTTH routers, etc.) to their end- customers. Others allow end-customers to provide their own CPE devices. Many will either provide CPE devices or allow = end-customers to supply their own. Broadband access network operators typically have mechanisms to detect and classify both inbound and outbound DDoS attacks, = utilizing flow telemetry exported from their peering/transit and customer aggregation routers. In the event of an outbound DDoS attack, they may make use of internally-developed systems which leverage their Dobbins, et al. Expires May 7, 2018 [Page 12] =0C Internet-Draft DOTS Use Cases November 2017 subscriber-management systems to de-provision end-customers who are sourcing outbound DDoS traffic; in some cases, they may have implemented quarantine systems to block all outbound traffic sourced from the offending end-customers. In either case, the perceived disruption of the end-customer's Internet access often prompts a help-desk call, which erodes the margins of the broadband access provider and can cause end-customer dissatisfaction. Increasingly, CPE devices themselves are targeted by attackers who exploit security flaws in these devices in order to compromise them and subsume them into botnets, and then leverage them to launch outbound DDoS attacks. In all of the described scenarios, the end- customers are unaware that their computers and/or CPE devices have been compromised and are being used to launch outbound DDoS attacks = - however, they may notice a degradation of their Internet = connectivity as a result of outbound bandwidth consumption or other disruption. By deploying DOTS-enabled telemetry systems and CPE devices (and possibly requiring DOTS functionality in customer-provided CPE devices), broadband access providers can utilize a standards-based mechanism to suppress outbound DDoS attack traffic while optionally allowing legitimate end-customer traffic to proceed unmolested. In order to achieve this capability, the telemetry analysis system utilized by the broadband access provider must have DOTS client functionality, and the end-customer CPE devices must have DOTS = server functionality. When the telemetry analysis system detects and classifies an outbound DDoS attack sourced from one or more end- customer networks/devices, the DOTS client of the telemetry analysis system sends a DOTS request to the DOTS server implemented on the = CPE devices, requesting local mitigation assistance in suppressing = either the identified outbound DDoS traffic, or all outbound traffic = sourced from the end-customer networks/devices. The DOTS server residing within the CPE device(s) would then perform predefined actions such as implementing on-board access-control lists (ACLs) to suppress the outbound traffic in question and prevent it from leaving the local end-customer network(s). Broadband access network operators may choose to implement a quarantine of all or selected network traffic originating from end- customer networks/devices which are sourcing outbound DDoS traffic, redirecting traffic from interactive applications such as Web browsers to an internal portal which informs the end-customer of the quarantine action, and providing instructions for self-remediation and/or helpdesk contact information. Quarantine systems for broadband access networks are typically custom-developed and -maintained, and are generally deployed only by Dobbins, et al. Expires May 7, 2018 [Page 13] =0C Internet-Draft DOTS Use Cases November 2017 a relatively small number of broadband access providers with considerable internal software development and support capabilities. By requiring the manufacturers of operator-supplied CPE devices to implement DOTS server functionality, and requiring customer-provided CPE devices to feature DOTS server functionality, broadband access network operators who previously could not afford the development expense of creating custom quarantine systems to integrate DOTS- enabled network telemetry systems to act as DOTS clients and perform effective quarantine of end-customer networks and devices until such time as they have been remediated. The DOTS communications model in this scenario resembles that described in Section 3.1.1, except that all the DOTS communications take place within the same span of administrative control and the same network. 3.2.2. Home Network DDoS Detection Collaboration for ISP network management Home networks run with (limited) bandwidth as well as limited = routing resources, while they are expected to provide services reachable = from the outside [RFC7368]. This makes such networks some easy targets = to DDoS attacks via their WAN interface. As these DDoS attacks are = easy to perform, they may remain undetected by the upstream ISP. When = the CPE is congested, the customer is likely to call the ISP hotline. = In order to improve the quality of experience of the connectivity as well as to automate the request for DDoS mitigation, ISPs are likely to consider a standard mean for CPEs to automatically inform a dedicated service mitigation platform when they are under a = suspected DDoS. Note also that this section only considers DDoS attacks CPE or services in the home network are encountering. This differs from DDoS attacks the CPE or any device within the home network may take part of - such as botnets. In the later attacks, the home network generates traffic under the control of a botmaster. Such attacks = may only be detected once the attacks have been characterized. It would be tempting to consider a feature in the DOTS protocol to allow a DOTS server to inform a CPE that some suspect traffic is being sent by the CPE so that appropriate actions are undertaken by the CPE/ user. Nevertheless, this feature would require some interaction = with the CPE administrator. Such scenario is outside the scope of this document. In this use case, ISPs are willing to prevent their customer undergoing DDoS attacks in order to enhance the quality of = experience of their customers, to avoid unnecessary costly call on hot lines as well as to optimize the bandwidth of their network. A key challenge Dobbins, et al. Expires May 7, 2018 [Page 14] =0C Internet-Draft DOTS Use Cases November 2017 for the ISP is to detect DDoS attacks. In fact, DDoS detection is not only fine grained but is also expected to be different for each home network or small businesses networks (SOHO), and the ISP is unlikely to have sufficient resource to inspect the traffic of all its customers. In order to address these challenges, ISPs are delegating the DDoS detection to CPE of home network or SOHO. Outsourcing the detection on the CPE provides the following advantages to the ISP: 1) Avoid = the ISP to dedicate a huge amount of resource for deep packet inspection over a large amount of traffic with a specific security policies associated to each home network. It is expected that such traffic only constitutes a small fraction of the total traffic the ISP is responsible for. 2) DDoS detection is deployed in a scalable way. 3) Provide more deterministic DDoS attack detection. For example, what could be suspected to be an UDP flood by the ISP may be consented by the terminating point hosted in the home network or SOHO. In fact, without specific home network security policies, the ISP is likely = to detect DDoS attack over regular traffic or to miss DDoS attacks targeting a specific home network or CPE. In the first case, this would result in the ISP spending unnecessary resources and in the second case this would directly impact the quality of experience of the customer. Note that in this scenario slightly differs from the "Enterprise = with an upstream transit provider DDoS mitigation Service" scenario described in Section 3.1.1. In this scenario, the detection DDoS is motivated by the ISP in order to operate appropriately its network. For that purpose, it requires some collaboration with the home network. In Section 3.1.1, the target network requests a mitigation service from the upstream transit provider in order to operate its services. Even though the motivations differ, there are still significant advantages for the home network to collaborate. On the home network or SOHO perspective such collaboration provides the following advantages: 1) If it removes the flows contributing to a DDoS attacks, then it enhances the quality of experience of the users of the targeted services or the entire home network. 2) If mitigation = is being handled by the ISP rather then the home network, then it reduces the management of DDoS attacks by the network administrator which involves detection as well as mitigation as well as the provisioning of extra resources. 3) If the DDoS detection is based = on information specific to the home network, such as for example the description of the services, the hosts capacities or the network topology, then performing the DDoS detection by the home network instead of the ISP avoids the home network to leak private Dobbins, et al. Expires May 7, 2018 [Page 15] =0C Internet-Draft DOTS Use Cases November 2017 information to the ISP. In that sense, it better preserves the home network or SOHO privacy while enabling a better detection. However, the request for mitigation may still leak some informations. ISPs must not retrieve sensitive data without the consent of the user. This is usually captured in administrative contracts that are out of scope of this document. When the CPE suspects an attack, it notifies automatically or the ISP. The contact address of the DDoS Mitigation service of the ISP may be hard coded or may be configured manually or automatically (e.g., eventually the DHCP server may provide the DDoS mitigation service via specific DHCP options). The communication to trigger a DDoS mitigation between the home network and the ISP is performed using DOTS. The home network CPE implements a DOTS client while the ISP implements a DOTS server. The DOTS client on the CPE monitors the status of CPE's resource and WAN link bandwidth usage. If something unusual happens based on preconfigured throughput, traffic patter, explicit action from the user, or some heuristics methods, the DOTS client sends a DOTS mitigation request to the ISP DOTS server. Typically, a default configuration with no additional information associated to the DOTS mitigation request is expected. The ISP derives traffic to mitigate from the CPE IP address. In some cases, the DOTS mitigation request contains options such as some IP addresses or prefixes that belongs to a whitelist or a blacklist. In this case, the white and black lists are not associated to some analysis performed by the CPE - as the CPE is clearly not expected to analyze such attacks. Instead these are = part of some configuration parameters. For example, in the case of small business, one may indicate specific legitimate IP addresses such as those used for VPNs, or third party services the company is likely = to set a session. Similarly, the CPE may provide the IP addresses targeting the assets to be protected inside the network. Note that the IP address is the IP address used to reach the asset from the internet, and as such is expected to be globally routable. Such options may include the IP address as well as a service description. Similarly to the previous blacklist and whitelist, such information are likely not derived from a traffic analysis performed by the CPE, but instead are more related to configuration parameters. Upon receiving the DOTS mitigation request, the DOTS server acknowledges its reception and confirms DDoS mitigation starts or not. Such feed back is mostly to avoid retransmission of the request. Dobbins, et al. Expires May 7, 2018 [Page 16] =0C Internet-Draft DOTS Use Cases November 2017 Note that the ISP is connected to multiple CPEs and as such the CPE can potentially perform DDoS attack to the DOTS server. ISP may use gateways to absorbs the traffic. These gateways, will typically aggregate a smaller number of CPEs and retransmit to the destination DOTS Server a selected information. Note that such gateways may somehow act as a DOTS relay, which is implemented with a DOTS Server and a DOTS Client. Note also that the case of a large DDoS attack targeting simultaneously multiple CPEs is expected to be detected = and mitigated by the upstream architecture, eventually without DOTS alerts sent by each single CPE. ISP may activate mitigation for the traffic associated to the CPE sending the alert or instead to the traffic associated to all CPE. Such decisions are not part of DOTS, but instead depend on the policies of the ISP. It is unlikely the CPE will follow the status of the mitigation. = The ISP is only expected to inform the CPE the mitigation has been stopped. Upon receipt of such notification the CPE may, for example, re- activate the monitoring jobs and thus is likely to provide some further DOTS alert. 3.2.3. DDoS Orchestration In this use case, one or more DDoS telemetry systems or monitoring devices such as a flow telemetry collector monitor a network -- typically an ISP network. Upon detection of a DDoS attack, these telemetry systems alert an orchestrator in charge of coordinating = the various DDoS mitigation systems within the domain. The telemetry systems may be configured to provide necessary and useful pieces of information, such as a preliminary analysis of the observation to = the orchestrator. The orchestrator analyses the various information it receives from specialized equipement, and elaborates one or multiple DDoS mitigation strategies. In some case, a manual confirmation 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, various hardware, or updating already instantiated DDoS mitigation functions. In some cases, some = specific virtual 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 (Section 3.1.1) = or an MSSP (Section 3.1.4). Dobbins, et al. Expires May 7, 2018 [Page 17] =0C Internet-Draft DOTS Use Cases November 2017 The communications used to trigger a DDoS mitigation between the telemetry and monitoring systems and the orchestrator is performed using DOTS. The telemetry systems implements a DOTS client while = the orchestrator implements a DOTS server. The communication between a network administrator and the orchestrator is also performed using DOTS. The network = administrator via its web interfaces implements a DOTS client, while the Orchestrator implements a DOTS server. The communication between the Orchestrator and the DDoS mitigation systems is performed using DOTS. The Orchestrator implements a DOTS client while the DDoS mitigation systems implement a DOTS server. The configuration aspects of each DDoS mitigation system, as well as the instantiations of DDoS mitigation functions or network configuration is not part of DOTS. Similarly, the discovery of available DDoS mitigation functions is not part of DOTS. +----------+ | network |C | adminis |<-+ | trator | | +----------+ | | (internal) +----------+ | S+--------------+ +-----------+ |telemetry/| +->| |C S| DDoS |+ |monitoring|<--->| Orchestrator |<--->| mitigation|| |systems |C S| |<-+ | systems || +----------+ +--------------+C | +-----------+| | +----------+ | | (external) | +-----------+ | S| DDoS | +->| mitigation| | systems | +-----------+ * C is for DOTS client functionality * S is for DOTS server functionality Figure 1: DDoS Orchestration The telemetry systems monitor various traffic network and perform their measurement tasks. They are configured so that when an event or some measurements reach a predefined level to report a DOTS Dobbins, et al. Expires May 7, 2018 [Page 18] =0C Internet-Draft DOTS Use Cases November 2017 mitigation request to the Orchestrator. The DOTS mitigation request may be associated with some element such as specific reporting. Upon receipt of the DOTS mitigation request from the telemetry system, the Orchestrator responds with an acknowledgement, to avoid retransmission of the request for mitigation. The status of the = DDoS mitigation indicates the Orchestrator is in an analysing phase. The Orchestrator begins collecting various information from various telemetry systems in order to correlate the measurements and provide an analysis of the event. Eventually, the Orchestrator may ask additional information to the telemetry system, however, the collection of these information is performed outside DOTS. The orchestrator may be configured to start a DDoS mitigation upon approval from a network administrator. The analysis from the orchestrator is reported to the network administrator via a web interface. If the network administrator decides to start the mitigation, she orders through her web interface a DOTS client to send a request for DDoS mitigation. This request is expected to be associated with a context that identifies the DDoS mitigation selected. Upon receiving the DOTS request for DDoS mitigation from the network administrator, the orchestrator orchestrates the DDoS mitigation according to the specified strategy. Its status indicates the DDoS mitigation is starting while not effective. Orchestration of the DDoS mitigation systems works similarly as described in Section 3.1.1 and Section 3.1.4. The Orchestrator indicates with its status whether the DDoS Mitigation is effective. When the DDoS mitigation is finished on the DDoS mitigation systems, the orchestrator indicates to the Telemetry systems as well as to = the network administrator the DDoS mitigation is finished. 4. Overview of DOTS Messaging Interactions During a DDoS Mitigation Session This section provides an overview of the DOTS messaging interactions between the DOTS client and server as described in Section 3.1.1 and Section 3.1.10. Scenario-specific variations are noted in the text describing each specific use case. 4.1. Successful DOTS DDoS Mitigation Request Example (a) A DDoS attack is initiated against online properties of an organization which has deployed DOTS-client-capable DDoS mitigators. Dobbins, et al. Expires May 7, 2018 [Page 19] =0C Internet-Draft DOTS Use Cases November 2017 (b) CPE or PE DDoS mitigators detect, classify, and begin mitigating the DDoS attack. (c) CPE or PE DDoS mitigators determine that their capacity and/or capability to mitigate the DDoS attack is insufficient, and utilize their DOTS client functionality to send a DOTS mitigation service initiation request to one or more DOTS servers residing on one or more upstream transit networks, peer networks, or overlay MSSP networks. This DOTS mitigation service initiation request may be automatically initiated by the CPE or PE DDoS mitigators, or may be manually triggered by personnel of the requesting organization in response to an alert from the mitigators (the mechanism by which = this process takes place is beyond the scope of this document). (d) The DOTS servers which receive the DOTS mitigation service initiation requests determine that they have been configured to = honor requests from the requesting CPE or PE mitigators, and initiate situationally-appropriate DDoS mitigation service on their = respective networks (the mechanism by which this process takes place is beyond the scope of this document). (e) The DOTS servers transmit a DOTS service status message to the requesting CPE or PE mitigators indicating that upstream DDoS mitigation service has been initiated. (f) While DDoS mitigation services are active, the DOTS servers regularly transmit DOTS mitigation status updates to the requesting CPE or PE mitigators. (g) While DDoS mitigation services are active, the CPE or PE mitigators may optionally regularly transmit DOTS mitigation = efficacy updates to the relevant DOTS servers. (h) When the upstream DDoS mitigators determine that the DDoS attack has ceased, they indicate this change in status to their respective DOTS servers (the mechanism by which this process takes place is beyond the scope of this document). (i) The DOTS servers transmit a DOTS mitigation status update to the CPE or PE mitigators indicating that the DDoS attack has ceased. (j) The CPE or PE DDoS mitigators transmit a DOTS mitigation service termination request to the DOTS servers. This DOTS mitigation service termination request may be automatically initiated by the = CPE or PE DDoS mitigators, or may be manually triggered by personnel of the requesting organization in response to an alert from the mitigators or a management system which monitors them (the mechanism Dobbins, et al. Expires May 7, 2018 [Page 20] =0C Internet-Draft DOTS Use Cases November 2017 by which this process takes place is beyond the scope of this document). (k) The DOTS servers terminate DDoS mitigation service on their respective networks (the mechanism by which this process takes place is beyond the scope of this document). (l) The DOTS servers transmit a DOTS mitigation status update to the CPE or PE mitigators indicating that DDoS mitigation services have been terminated. (m) The CPE or PE DDoS mitigators transmit a DOTS mitigation termination status acknowledgement to the DOTS servers. 4.2. Unsuccessful DOTS DDoS Mitigation Request Example (a) A DDoS attack is initiated against online properties of an organization which has deployed DOTS-client-capable DDoS mitigators. (b) CPE or PE DDoS mitigators detect, classify, and begin mitigating the DDoS attack. (c) CPE or PE DDoS mitigators determine that their capacity and/or capability to mitigate the DDoS attack is insufficient, and utilize their DOTS client functionality to send a DOTS mitigation service initiation request to one or more DOTS servers residing on one or more upstream transit networks, peer networks, or overlay MSSP networks. This DOTS mitigation service initiation request may be automatically initiated by the CPE or PE DDoS mitigators, or may be manually triggered by personnel of the requesting organization in response to an alert from the mitigators (the mechanism by which this process takes place is beyond the scope of this document). (d) The DOTS servers which receive the DOTS mitigation service initiation requests determine that they have been to honor requests from the requesting CPE or PE mitigators, and attempt to initiate situationally-appropriate DDoS mitigation service on their = respective networks (the mechanism by which this process takes place is beyond the scope of this document). (e) The DDoS mitigators on the upstream network report back to the DOTS servers that they are unable to initiate DDoS mitigation = service for the requesting organization due to mitigation capacity constraints, bandwidth constraints, functionality constraints, Dobbins, et al. Expires May 7, 2018 [Page 21] =0C Internet-Draft DOTS Use Cases November 2017 hardware casualties, or other impediments (the mechanism by which this process takes place is beyond the scope of this document). (f) The DOTS servers transmit a DOTS service status message to the requesting CPE or PE mitigators indicating that upstream DDoS mitigation service cannot be initiated as requested. The scope, format, and content of these messages must be codified by the DOTS WG. (g) The CPE or PE mitigators may optionally regularly re-transmit DOTS mitigation status request messages to the relevant DOTS servers until acknowledgement that mitigation services have been initiated. The scope, format, and content of these messages must be codified by the DOTS WG. (h) The CPE or PE mitigators may optionally transmit a DOTS mitigation service initiation request to DOTS servers associated = with a configured fallback upstream DDoS mitigation service. The scope, format, and content of these messages must be codified by the DOTS WG. Multiple fallback DDoS mitigation services may optionally be configured. (i) The process describe above cyclically continues until the DDoS mitigation service request is fulfilled; the CPE or PE mitigators determine that the DDoS attack volume has decreased to a level = and/or complexity which they themselves can successfully mitigate; the DDoS attack has ceased; or manual intervention by personnel of the requesting organization has taken place. 5. Security Considerations DOTS is at risk from three primary attacks: DOTS agent = impersonation, traffic injection, and signaling blocking. Associated security requirements and additional ones are defined in [I-D.ietf-dots-requirements]. Impersonation and traffic injection mitigation can be managed = through current secure communications best practices. DOTS is not subject = to anything new in this area. 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. Dobbins, et al. Expires May 7, 2018 [Page 22] =0C Internet-Draft DOTS Use Cases November 2017 6. IANA Considerations No IANA considerations exist for this document at this time. 7. Acknowledgments The authors would like to thank among others Tirumaleswar Reddy; Andrew Mortensen; Mohamed Boucadaire; Artyom Gavrichenkov; and the DOTS WG chairs, Roman D. Danyliw and Tobias Gondrom, for their valuable feedback. 8. References 8.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . 8.2. Informative References [I-D.ietf-dots-requirements] Mortensen, A., Moskowitz, R., and T. Reddy, "Distributed Denial of Service (DDoS) Open Threat Signaling Requirements", draft-ietf-dots-requirements-06 (work in progress), July 2017. [RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S. Cheshire, "Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry", BCP 165, RFC 6335, DOI 10.17487/RFC6335, August 2011, . [RFC7368] Chown, T., Ed., Arkko, J., Brandt, A., Troan, O., and J. Weil, "IPv6 Home Networking Architecture Principles", RFC 7368, DOI 10.17487/RFC7368, October 2014, . Authors' Addresses Roland Dobbins Arbor Networks Singapore EMail: rdobbins@arbor.net Dobbins, et al. Expires May 7, 2018 [Page 23] =0C Internet-Draft DOTS Use Cases November 2017 Daniel Migault Ericsson 8400 boulevard Decarie Montreal, QC H4P 2N2 Canada EMail: daniel.migault@ericsson.com Stefan Fouant USA EMail: stefan.fouant@copperriverit.com Robert Moskowitz HTT Consulting Oak Park, MI 48237 USA EMail: rgm@labs.htt-consult.com Nik Teague Verisign 12061 Bluemont Way Reston, VA 20190 EMail: nteague@verisign.com Liang Xia Huawei No. 101, Software Avenue, Yuhuatai District Nanjing China EMail: Frank.xialiang@huawei.com Kaname Nishizuka NTT Communications GranPark 16F 3-4-1 Shibaura, Minato-ku Tokyo 108-8118 Japan EMail: kaname@nttv6.jp Dobbins, et al. Expires May 7, 2018 [Page 24] ----- ----------------------------------- Roland Dobbins From nobody Fri Nov 3 14:32:47 2017 Return-Path: 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 EC48413FFE4 for ; Fri, 3 Nov 2017 14:32:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 eaYZqfiIN9Kr for ; Fri, 3 Nov 2017 14:32:44 -0700 (PDT) Received: from mail.jpshallow.com (mail.jpshallow.com [217.40.240.153]) (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 57B2913FFE3 for ; Fri, 3 Nov 2017 14:32:44 -0700 (PDT) Received: from [127.0.0.1] (helo=N01332) by mail.jpshallow.com with smtps (TLSv1:ECDHE-RSA-AES256-SHA:256) (Exim 4.89) (envelope-from ) id 1eAjZx-0008Kk-Lb for ietf-supjps-dots@ietf.org; Fri, 03 Nov 2017 21:32:41 +0000 From: "Jon Shallow" To: Date: Fri, 3 Nov 2017 21:32:42 -0000 Message-ID: <06f601d354eb$482cce20$d8866a60$@jpshallow.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_06F7_01D354EB.482E54C0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdNU60NzSK+9AEyfSlySy52mDm5lHg== Content-Language: en-gb Archived-At: Subject: [Dots] Data channel issues with GET 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Nov 2017 21:32:46 -0000 This is a multipart message in MIME format. ------=_NextPart_000_06F7_01D354EB.482E54C0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Tiru et al, I am having challenges coding up the GET for channel identifiers. A DOTS Client as part of a DOTS gateway can use different client-identifiers when doing a PUT for the alias-name. The DOTS server will therefore have multiple client-identifier arrays for the DOTS GW client. However when doing a GET using 'content=config', as things currently stand, only one client-identifier array can returned as per the below in Figure 7:- =============================== "3.2.3. Retrieving Installed Identifiers A GET request is used to retrieve the set of installed identifiers from a DOTS server (Section 3.3.1 in [RFC8040]). Figure 6 shows how to retrieve all the identifiers that were instantiated by the DOTS client. The content parameter and its permitted values are defined in Section 4.8.1 of [RFC8040]. GET /restconf/data/ietf-dots-data-channel-identifier:identifier?\ content=config HTTP/1.1 Host: {host}:{port} Accept: application/yang-data+json Figure 6: GET to retrieve all the installed identifiers Figure 7 shows response for all identifiers on the DOTS server. { "ietf-dots-data-channel-identifier:identifier": { "client-identifier": [ "dz6pHjaADkaFTbjr0JGBpw", "iAYmCNPmrYoKoqzgFMiobw" ], "alias": [ { "alias-name": "Server1", "traffic-protocol": [ 6" =========== I think that the yang model needs to be re-written, by moving leaf-list client-identifier down to the same level as alias-name as :- =========== container identifier { description "Top level container for identifiers"; list alias { key alias-name; description "List of identifiers"; leaf alias-name { type string; description "alias name"; } leaf-list client-identifier { type binary; description "A client identifier conveyed by a DOTS gateway to a remote DOTS server."; reference "I-D.itef-dots-signal-channel"; } leaf-list target-ip { ================ And reflected appropriately throughout the data channel draft. The issue is the same for the access control list - client-identifier needs to be at the same level as acl-name module: ietf-dots-access-control-list augment /ietf-acl:access-lists: +--rw client-identifier* binary ============= Needs to be module: ietf-dots-access-control-list augment /ietf-acl:access-lists/ietf-acl:acl/: +--rw client-identifier* binary =============== And replicated as appropriate throughout the draft Regards Jon ------=_NextPart_000_06F7_01D354EB.482E54C0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Tiru et = al,

 

I am having challenges coding up the GET for channel = identifiers.

 

A DOTS Client as part of a DOTS gateway can use = different client-identifiers when doing a PUT for the alias-name. =   The DOTS server will therefore have multiple = client-identifier arrays for the DOTS GW client.

 

However when = doing a GET using ‘content=3Dconfig’, as things currently = stand, only one client-identifier array can returned as per the below in = Figure 7:-

 

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

 

“3.2.3.  Retrieving Installed = Identifiers

 

   A GET request is used to retrieve the set = of installed identifiers

   = from a DOTS server (Section 3.3.1 in [RFC8040]).  Figure 6 shows = how

   to retrieve all the = identifiers that were instantiated by the DOTS

   client.  The content parameter and = its permitted values are defined

   in Section 4.8.1 of = [RFC8040].

 

     GET = /restconf/data/ietf-dots-data-channel-identifier:identifier?\<= /p>

         = content=3Dconfig HTTP/1.1

     Host: = {host}:{port}

     Accept: = application/yang-data+json

 

          = Figure 6: GET to retrieve all the installed identifiers

 

   = Figure 7 shows response for all identifiers on the DOTS = server.

 

   {

    = "ietf-dots-data-channel-identifier:identifier": = {

       = "client-identifier": [

          = "dz6pHjaADkaFTbjr0JGBpw",

          = "iAYmCNPmrYoKoqzgFMiobw"

       = ],

       = "alias": [

         = {

         &= nbsp; "alias-name": "Server1",

         &= nbsp; "traffic-protocol": [

         &= nbsp;   6”

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

 

I think that = the yang model needs to be re-written, by moving leaf-list = client-identifier down to the same level as alias-name as = :-

 

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

     container identifier = {

          = description "Top level container for = identifiers";

 

         &= nbsp;    list alias {

         &= nbsp;         key = alias-name;

          =          description = "List of identifiers";

 

         &= nbsp;         leaf alias-name = {

         &= nbsp;            = type string;

         &= nbsp;            = description "alias name";

         &= nbsp;         }

 

         &= nbsp;         leaf-list = client-identifier {

         &= nbsp;            = type binary;

         &= nbsp;            = description  "A client identifier conveyed by a DOTS = gateway

         &= nbsp;           &n= bsp;           &nb= sp;  to a remote DOTS server.";

 

         &= nbsp;            = reference

         &= nbsp;           &n= bsp;   = "I-D.itef-dots-signal-channel";

         &= nbsp;         }

 

         &= nbsp;         leaf-list = target-ip {

 

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

 

And reflected appropriately throughout the data = channel draft.

 

The issue is = the same for the access control list – client-identifier needs to = be at the same level as acl-name

 

module: = ietf-dots-access-control-list

  = augment /ietf-acl:access-lists:

    +--rw = client-identifier*   binary

 

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

<= p class=3DMsoNormal>Needs to be

 

module: = ietf-dots-access-control-list

  = augment /ietf-acl:access-lists/ietf-acl:acl/:

    +--rw = client-identifier*   binary

 

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

 

And = replicated as appropriate throughout the draft

 

Regards

 

Jon

------=_NextPart_000_06F7_01D354EB.482E54C0-- From nobody Fri Nov 3 15:09:05 2017 Return-Path: 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 6FC0313FEF8 for ; Fri, 3 Nov 2017 15:09:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 PMwqwylZ90DL for ; Fri, 3 Nov 2017 15:09:02 -0700 (PDT) Received: from mail.jpshallow.com (mail.jpshallow.com [217.40.240.153]) (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 5F98913FFF4 for ; Fri, 3 Nov 2017 15:09:02 -0700 (PDT) Received: from [127.0.0.1] (helo=N01332) by mail.jpshallow.com with smtps (TLSv1:ECDHE-RSA-AES256-SHA:256) (Exim 4.89) (envelope-from ) id 1eAk96-0008Lu-RN for ietf-supjps-dots@ietf.org; Fri, 03 Nov 2017 22:09:00 +0000 From: "Jon Shallow" To: References: <06f601d354eb$482cce20$d8866a60$@jpshallow.com> In-Reply-To: <06f601d354eb$482cce20$d8866a60$@jpshallow.com> Date: Fri, 3 Nov 2017 22:09:01 -0000 Message-ID: <070f01d354f0$5b0d7850$112868f0$@jpshallow.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0710_01D354F0.5B0F7420" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQGq3C7tF9zj9qMEJcmaXbDvWUqFfaNUJtNg Content-Language: en-gb Archived-At: Subject: Re: [Dots] Data channel issues with GET 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Nov 2017 22:09:04 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0710_01D354F0.5B0F7420 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Tiru et al, In addition, on the signal channel, it is also worth considering moving client-identifier to the same level as mitigation-id, so that ====== 1) To retrieve all DOTS signals signaled by the DOTS client. Header: GET (Code=0.01) Uri-Host: "host" Uri-Path: ".well-known" Uri-Path: "dots" Uri-Path: "version" Uri-Path: "mitigate" Observe : 0 { "mitigation-scope": { "client-identifier": [ "string" ] } } ======== Can be reduced to 1) To retrieve all DOTS signals signaled by the DOTS client. Header: GET (Code=0.01) Uri-Host: "host" Uri-Path: ".well-known" Uri-Path: "dots" Uri-Path: "version" Uri-Path: "mitigate" Observe : 0 ======= Regards Jon From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of Jon Shallow Sent: 03 November 2017 21:33 To: dots@ietf.org Subject: [Dots] Data channel issues with GET Hi Tiru et al, I am having challenges coding up the GET for channel identifiers. A DOTS Client as part of a DOTS gateway can use different client-identifiers when doing a PUT for the alias-name. The DOTS server will therefore have multiple client-identifier arrays for the DOTS GW client. However when doing a GET using 'content=config', as things currently stand, only one client-identifier array can returned as per the below in Figure 7:- =============================== "3.2.3. Retrieving Installed Identifiers A GET request is used to retrieve the set of installed identifiers from a DOTS server (Section 3.3.1 in [RFC8040]). Figure 6 shows how to retrieve all the identifiers that were instantiated by the DOTS client. The content parameter and its permitted values are defined in Section 4.8.1 of [RFC8040]. GET /restconf/data/ietf-dots-data-channel-identifier:identifier?\ content=config HTTP/1.1 Host: {host}:{port} Accept: application/yang-data+json Figure 6: GET to retrieve all the installed identifiers Figure 7 shows response for all identifiers on the DOTS server. { "ietf-dots-data-channel-identifier:identifier": { "client-identifier": [ "dz6pHjaADkaFTbjr0JGBpw", "iAYmCNPmrYoKoqzgFMiobw" ], "alias": [ { "alias-name": "Server1", "traffic-protocol": [ 6" =========== I think that the yang model needs to be re-written, by moving leaf-list client-identifier down to the same level as alias-name as :- =========== container identifier { description "Top level container for identifiers"; list alias { key alias-name; description "List of identifiers"; leaf alias-name { type string; description "alias name"; } leaf-list client-identifier { type binary; description "A client identifier conveyed by a DOTS gateway to a remote DOTS server."; reference "I-D.itef-dots-signal-channel"; } leaf-list target-ip { ================ And reflected appropriately throughout the data channel draft. The issue is the same for the access control list - client-identifier needs to be at the same level as acl-name module: ietf-dots-access-control-list augment /ietf-acl:access-lists: +--rw client-identifier* binary ============= Needs to be module: ietf-dots-access-control-list augment /ietf-acl:access-lists/ietf-acl:acl/: +--rw client-identifier* binary =============== And replicated as appropriate throughout the draft Regards Jon ------=_NextPart_000_0710_01D354F0.5B0F7420 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Tiru et al,

 

In addition, on the = signal channel, it is also worth considering moving client-identifier to = the same level as mitigation-id, so that

 

=3D=3D=3D=3D=3D=3D

   1) To = retrieve all DOTS signals signaled by the DOTS = client.

 

     = Header: GET (Code=3D0.01)

     = Uri-Host: "host"

     = Uri-Path: ".well-known"

    =  Uri-Path: "dots"

     = Uri-Path: "version"

     = Uri-Path: "mitigate"

     = Observe : 0

     = {

       = "mitigation-scope": {

         = "client-identifier": [

        &= nbsp;   "string"

         = ]

       = }

     = }

=3D=3D=3D=3D=3D=3D=3D=3D

Can be reduced to =

 

   1) To = retrieve all DOTS signals signaled by the DOTS = client.

 

     = Header: GET (Code=3D0.01)

     = Uri-Host: "host"

     = Uri-Path: ".well-known"

    =  Uri-Path: "dots"

     = Uri-Path: "version"

     = Uri-Path: "mitigate"

     = Observe : 0

 

=3D=3D=3D=3D=3D=3D=3D

 

Regards

 

Jon

 

From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of = Jon Shallow
Sent: 03 November 2017 21:33
To: = dots@ietf.org
Subject: [Dots] Data channel issues with = GET

 

Hi Tiru et = al,

 

I am having challenges coding up the GET for channel = identifiers.

 

A DOTS Client as part of a DOTS gateway can use = different client-identifiers when doing a PUT for the alias-name. =   The DOTS server will therefore have multiple = client-identifier arrays for the DOTS GW client.

 

However when = doing a GET using ‘content=3Dconfig’, as things currently = stand, only one client-identifier array can returned as per the below in = Figure 7:-

 

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

 

“3.2.3.  Retrieving Installed = Identifiers

 

   A GET request is used to retrieve the set = of installed identifiers

   = from a DOTS server (Section 3.3.1 in [RFC8040]).  Figure 6 shows = how

   to retrieve all the = identifiers that were instantiated by the DOTS

   client.  The content parameter and = its permitted values are defined

   in Section 4.8.1 of = [RFC8040].

 

     GET = /restconf/data/ietf-dots-data-channel-identifier:identifier?\<= /p>

         = content=3Dconfig HTTP/1.1

     Host: = {host}:{port}

     Accept: = application/yang-data+json

 

          = Figure 6: GET to retrieve all the installed identifiers

 

   = Figure 7 shows response for all identifiers on the DOTS = server.

 

   {

    = "ietf-dots-data-channel-identifier:identifier": = {

       = "client-identifier": [

          = "dz6pHjaADkaFTbjr0JGBpw",

          = "iAYmCNPmrYoKoqzgFMiobw"

       = ],

       = "alias": [

         = {

         &= nbsp; "alias-name": "Server1",

         &= nbsp; "traffic-protocol": [

         &= nbsp;   6”

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

 

I think that = the yang model needs to be re-written, by moving leaf-list = client-identifier down to the same level as alias-name as = :-

 

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

     container identifier = {

          = description "Top level container for = identifiers";

 

         &= nbsp;    list alias {

         &= nbsp;         key = alias-name;

          =          description = "List of identifiers";

 

         &= nbsp;         leaf alias-name = {

         &= nbsp;            = type string;

         &= nbsp;            = description "alias name";

         &= nbsp;         }

 

         &= nbsp;         leaf-list = client-identifier {

         &= nbsp;            = type binary;

         &= nbsp;            = description  "A client identifier conveyed by a DOTS = gateway

         &= nbsp;           &n= bsp;           &nb= sp;  to a remote DOTS server.";

 

         &= nbsp;            = reference

         &= nbsp;           &n= bsp;   = "I-D.itef-dots-signal-channel";

         &= nbsp;         }

 

         &= nbsp;         leaf-list = target-ip {

 

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

 

And reflected appropriately throughout the data = channel draft.

 

The issue is = the same for the access control list – client-identifier needs to = be at the same level as acl-name

 

module: = ietf-dots-access-control-list

  = augment /ietf-acl:access-lists:

    +--rw = client-identifier*   binary

 

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

<= p class=3DMsoNormal>Needs to be

 

module: = ietf-dots-access-control-list

  = augment /ietf-acl:access-lists/ietf-acl:acl/:

    +--rw = client-identifier*   binary

 

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

 

And = replicated as appropriate throughout the draft

 

Regards

 

Jon

------=_NextPart_000_0710_01D354F0.5B0F7420-- From nobody Fri Nov 3 21:16:13 2017 Return-Path: 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 04FEA13FB2A for ; Fri, 3 Nov 2017 21:16:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.32 X-Spam-Level: X-Spam-Status: No, score=-4.32 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham 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 S1GPQ-6KxDmC for ; Fri, 3 Nov 2017 21:16: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 B1ACF13FB24 for ; Fri, 3 Nov 2017 21:16:09 -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=1509768957; 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: x-originating-ip:x-ms-publictraffictype:x-microsoft-exchange-diagnostics: x-ms-exchange-antispam-srfa-diagnostics:x-ms-office365-filtering-correlation-id: x-microsoft-antispam:x-ms-traffictypediagnostic: x-exchange-antispam-report-test:x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test:x-forefront-prvs: x-forefront-antispam-report:received-spf:authentication-results: spamdiagnosticoutput:spamdiagnosticmetadata: Content-Type: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-Transport-CrossTenantHeadersStamped: X-OriginatorOrg:X-NAI-Spam-Flag:X-NAI-Spam-Threshold: X-NAI-Spam-Score:X-NAI-Spam-Version; bh=I D0hZk9p0JTnwpBfM1cIN7IijZb2186NFbLkIE4pU9 g=; b=a1/hbXnCxsxiNF7POlCeo7JHZQ7r4VED36FlnIp5ycS+ 56Vmx8GrtfOin5dfn4VWV8yTdQsx08Sbs2R/ANzyuIJAlNegLk TQtNgIrwubSZjnRO11TkIhQrMtOiLsGfWGXjTRFIbPZBm4VmZq b2kRsw+INJJ2/n8uiKD0AlyWaUk= Received: from DNVEXAPP1N04.corpzone.internalzone.com (unknown [10.44.48.88]) by DNVWSMAILOUT1.mcafee.com with smtp id 6d6d_0323_f4223684_26e8_4557_a0d7_bdbb94b0c021; Fri, 03 Nov 2017 23:15:57 -0500 Received: from DNVEXUSR1N08.corpzone.internalzone.com (10.44.48.81) by DNVEXAPP1N04.corpzone.internalzone.com (10.44.48.88) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Fri, 3 Nov 2017 22:15:56 -0600 Received: from DNVO365EDGE1.corpzone.internalzone.com (10.44.176.66) by DNVEXUSR1N08.corpzone.internalzone.com (10.44.48.81) with Microsoft SMTP Server (TLS) id 15.0.1347.2 via Frontend Transport; Fri, 3 Nov 2017 22:15:56 -0600 Received: from NAM01-BY2-obe.outbound.protection.outlook.com (10.44.176.240) by edge.mcafee.com (10.44.176.66) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Fri, 3 Nov 2017 22:15:55 -0600 Received: from DM5PR16MB1788.namprd16.prod.outlook.com (10.172.44.144) by DM5PR16MB1788.namprd16.prod.outlook.com (10.172.44.144) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.197.13; Sat, 4 Nov 2017 04:15: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.20.0197.017; Sat, 4 Nov 2017 04:15:53 +0000 From: "Konda, Tirumaleswar Reddy" To: Jon Shallow , "dots@ietf.org" Thread-Topic: [Dots] Data channel issues with GET Thread-Index: AdNU60NzSK+9AEyfSlySy52mDm5lHgANmhBQ Date: Sat, 4 Nov 2017 04:15:53 +0000 Message-ID: References: <06f601d354eb$482cce20$d8866a60$@jpshallow.com> In-Reply-To: <06f601d354eb$482cce20$d8866a60$@jpshallow.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [122.171.65.119] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DM5PR16MB1788; 6:cHi9+13pcTs2L1V8W/Aqea4GL00itod/p7t5vmuD1pxNTOQDwn1DXB03jfkY4Ddvv9BbZba3H90llZRU06AFCt4sZCaGS6x+MnF2e/Y2o2oE+tn7FSViTHD1BL+Y7EA+tUHktr3n17bZcmwIu+FoAEYsUnU7i0l+CA3NTG2tInv5tLR91HDucoX27JawerOSHUTXBfm7AiMyopHYhwC7X37k4+NRp/TtmuJ+w16JbowKdCTuYOnb70XREyLQXoZQ9xPJS5np/RmhNQsnNXjuVjNgU/7ffmryBg0ICfXabr5AUx1Xplj3tC1KpRi98U9QzzaS9KHq3cRPgOXB6nfbn2z1LKXrYQPP/B1KKT6t2Ao=; 5:Ea3uYL0HBqE8KmFG9DXfPTEX6dJISsq4A4+zXlEE6Xz4WrV047DLnYJ01Mh02CxMtTbc7OqQwyIKlN52ZQLt6bzElTRvt9F0wYzWx3tnViMCGt1GI1hk6obItdT+BGN0wVS1o95JfjwVQrrBJ1qJhDNnWY/HfPxBh/ksBGyS15k=; 24:SLslQrq0gFIlWGQF6SiuU7PEvvkJtHyCN8gC4CwgC1voIvVGP5cHEhrPY7Xw2kZFmLa3U1OkM9uKAGPuWF5yYFWlGjEpLQJKphYGCTMlOvc=; 7:ePA+j892kY8bYUOAjl2YSH0ygfs1J8dRdfOAWL1kavwcwSaoe2Efl1vfFJ+zlUBMdLERY4L4ve0JFKgldxlxom3p2Wa3f5kny6hbH5Yms3fm+c476BXTz41DCwj1FnyqHsSqpoZlpnW4+XqGBb/uSIiXlCual4nA2eEHSC1IgkEx9go9GeCQMmZUb0dLVz0+CPTAtP4hcvgYXfPUloiq3sd7LbQQz55CotGaWnnfFVu2SRHGqvxaPM76XQFlhB/E x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 9c98c975-bce5-446f-d5b9-08d5233abd5a x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(2017052603246); SRVR:DM5PR16MB1788; x-ms-traffictypediagnostic: DM5PR16MB1788: x-exchange-antispam-report-test: UriScan:(158342451672863)(21748063052155); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(5005006)(8121501046)(3231021)(10201501046)(100000703101)(100105400095)(93006095)(93001095)(3002001)(6041248)(20161123558100)(20161123564025)(20161123560025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123562025)(20161123555025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:DM5PR16MB1788; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:DM5PR16MB1788; x-forefront-prvs: 048111149A x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(346002)(376002)(32952001)(189002)(199003)(51444003)(2950100002)(74316002)(76176999)(7736002)(5660300001)(478600001)(50986999)(229853002)(7696004)(86362001)(316002)(99286004)(575784001)(25786009)(6116002)(790700001)(102836003)(6246003)(54896002)(3846002)(6306002)(110136005)(72206003)(3280700002)(9686003)(66066001)(3660700001)(54356999)(2906002)(53546010)(101416001)(68736007)(80792005)(189998001)(55016002)(105586002)(106356001)(81166006)(33656002)(6506006)(53936002)(8936002)(6436002)(2501003)(14454004)(8676002)(81156014)(97736004)(9326002)(2900100001)(77096006)(19609705001)(85282002); DIR:OUT; SFP:1101; SCL:1; SRVR:DM5PR16MB1788; H:DM5PR16MB1788.namprd16.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: McAfee.com does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=TirumaleswarReddy_Konda@McAfee.com; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_DM5PR16MB1788D6CF70DE9767C733C105EA520DM5PR16MB1788namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 9c98c975-bce5-446f-d5b9-08d5233abd5a X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Nov 2017 04:15:53.3621 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4943e38c-6dd4-428c-886d-24932bc2d5de X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR16MB1788 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 <6151> : inlines <6156> : streams <1769285> : uri <2527789> Archived-At: Subject: Re: [Dots] Data channel issues with GET 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Nov 2017 04:16:12 -0000 --_000_DM5PR16MB1788D6CF70DE9767C733C105EA520DM5PR16MB1788namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Jon, GET request will only retrieve the alias-names installed by a DOTS client a= nd not the alias-names for all the DOTS clients. The client-identifier arra= y is uniquely identifying the DOTS client and does not need be repeated for= every alias-name conveyed by the client. Figure 6 is showing the GET requ= est from the DOTS client, and the DOTS gateways will update the GET request= to add and update the client-identifier array. I don't think the client-identifier should be in the same level as alias-na= me. -Tiru From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Jon Shallow Sent: Saturday, November 4, 2017 3:03 AM To: dots@ietf.org Subject: [Dots] Data channel issues with GET Hi Tiru et al, I am having challenges coding up the GET for channel identifiers. A DOTS Client as part of a DOTS gateway can use different client-identifier= s when doing a PUT for the alias-name. The DOTS server will therefore hav= e multiple client-identifier arrays for the DOTS GW client. However when doing a GET using 'content=3Dconfig', as things currently stan= d, only one client-identifier array can returned as per the below in Figure= 7:- =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D "3.2.3. Retrieving Installed Identifiers A GET request is used to retrieve the set of installed identifiers from a DOTS server (Section 3.3.1 in [RFC8040]). Figure 6 shows how to retrieve all the identifiers that were instantiated by the DOTS client. The content parameter and its permitted values are defined in Section 4.8.1 of [RFC8040]. GET /restconf/data/ietf-dots-data-channel-identifier:identifier?\ content=3Dconfig HTTP/1.1 Host: {host}:{port} Accept: application/yang-data+json Figure 6: GET to retrieve all the installed identifiers Figure 7 shows response for all identifiers on the DOTS server. { "ietf-dots-data-channel-identifier:identifier": { "client-identifier": [ "dz6pHjaADkaFTbjr0JGBpw", "iAYmCNPmrYoKoqzgFMiobw" ], "alias": [ { "alias-name": "Server1", "traffic-protocol": [ 6" =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D I think that the yang model needs to be re-written, by moving leaf-list cli= ent-identifier down to the same level as alias-name as :- =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D container identifier { description "Top level container for identifiers"; list alias { key alias-name; description "List of identifiers"; leaf alias-name { type string; description "alias name"; } leaf-list client-identifier { type binary; description "A client identifier conveyed by a DOTS = gateway to a remote DOTS server."; reference "I-D.itef-dots-signal-channel"; } leaf-list target-ip { =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D And reflected appropriately throughout the data channel draft. The issue is the same for the access control list - client-identifier needs= to be at the same level as acl-name module: ietf-dots-access-control-list augment /ietf-acl:access-lists: +--rw client-identifier* binary =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Needs to be module: ietf-dots-access-control-list augment /ietf-acl:access-lists/ietf-acl:acl/: +--rw client-identifier* binary =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D And replicated as appropriate throughout the draft Regards Jon --_000_DM5PR16MB1788D6CF70DE9767C733C105EA520DM5PR16MB1788namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Jon,

&nbs= p;

GET reque= st will only retrieve the alias-names installed by a DOTS client and not th= e alias-names for all the DOTS clients. The client-identifier array is uniq= uely identifying the DOTS client and does not need be repeated for every alias-name conveyed by the client. &nb= sp;Figure 6 is showing the GET request from the DOTS client, and the DOTS g= ateways will update the GET request to add and update the client-identifier= array.

I donR= 17;t think the client-identifier should be in the same level as alias-name.

&nbs= p;

-Tiru

 

From:<= /span> Dots [mailto:dots-bou= nces@ietf.org] On Behalf Of Jon Shallow
Sent: Saturday, November 4, 2017 3:03 AM
To: dots@ietf.org
Subject: [Dots] Data channel issues with GET

 

Hi Tiru et al,

 

I am having challenges coding u= p the GET for channel identifiers.

 

A DOTS Client as part of a DOTS= gateway can use different client-identifiers when doing a PUT for the alia= s-name.   The DOTS server will therefore have multiple client-ide= ntifier arrays for the DOTS GW client.

 

However when doing a GET using = ‘content=3Dconfig’, as things currently stand, only one client-= identifier array can returned as per the below in Figure 7:-

 

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<= /span>

 

“3.2.3.  Retrieving = Installed Identifiers

 

   A GET request is u= sed to retrieve the set of installed identifiers

   from a DOTS server= (Section 3.3.1 in [RFC8040]).  Figure 6 shows how

   to retrieve all th= e identifiers that were instantiated by the DOTS

   client.  The = content parameter and its permitted values are defined

   in Section 4.8.1 o= f [RFC8040].

 

     GET /r= estconf/data/ietf-dots-data-channel-identifier:identifier?\

     &= nbsp;   content=3Dconfig HTTP/1.1

     Host: = {host}:{port}

     Accept= : application/yang-data+json

 

     &= nbsp;    Figure 6: GET to retrieve all the installed identif= iers

 

   Figure 7 shows res= ponse for all identifiers on the DOTS server.

 

   {

    "ietf-d= ots-data-channel-identifier:identifier": {

     &= nbsp; "client-identifier": [

     &= nbsp;    "dz6pHjaADkaFTbjr0JGBpw",

     &= nbsp;    "iAYmCNPmrYoKoqzgFMiobw"

     &= nbsp; ],

     &= nbsp; "alias": [

     &= nbsp;   {

     &= nbsp;     "alias-name": "Server1",<= o:p>

     &= nbsp;     "traffic-protocol": [

     &= nbsp;       6”

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D

 

I think that the yang model nee= ds to be re-written, by moving leaf-list client-identifier down to the same= level as alias-name as :-

 

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D

     contai= ner identifier {

     &= nbsp;    description "Top level container for identifie= rs";

 

     &= nbsp;        list alias {

     &= nbsp;           &nbs= p; key alias-name;

     &= nbsp;            &nb= sp;description "List of identifiers";

 

     &= nbsp;           &nbs= p; leaf alias-name {

     &= nbsp;           &nbs= p;    type string;

     &= nbsp;           &nbs= p;    description "alias name";<= /p>

     &= nbsp;           &nbs= p; }

 

     &= nbsp;           &nbs= p; leaf-list client-identifier {

     &= nbsp;           &nbs= p;    type binary;

     &= nbsp;           &nbs= p;    description  "A client identifier conveyed b= y a DOTS gateway

     &= nbsp;           &nbs= p;            &= nbsp;     to a remote DOTS server.";

 

     &= nbsp;           &nbs= p;    reference

     &= nbsp;           &nbs= p;       "I-D.itef-dots-signal-channel&q= uot;;

     &= nbsp;           &nbs= p; }

 

     &= nbsp;           &nbs= p; leaf-list target-ip {

 

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D

 

And reflected appropriately thr= oughout the data channel draft.

 

The issue is the same for the a= ccess control list – client-identifier needs to be at the same level = as acl-name

 

module: ietf-dots-access-contro= l-list

  augment /ietf-acl:access= -lists:

    +--rw cl= ient-identifier*   binary

 

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D

Needs to be

 

module: ietf-dots-access-contro= l-list

  augment /ietf-acl:access= -lists/ietf-acl:acl/:

    +--rw cl= ient-identifier*   binary

 

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D

 

And replicated as appropriate t= hroughout the draft

 

Regards

 

Jon

--_000_DM5PR16MB1788D6CF70DE9767C733C105EA520DM5PR16MB1788namp_-- From nobody Fri Nov 3 21:23:06 2017 Return-Path: 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 54DCE13FB2E for ; Fri, 3 Nov 2017 21:23:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.32 X-Spam-Level: X-Spam-Status: No, score=-4.32 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham 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 M1kFczarP4ax for ; Fri, 3 Nov 2017 21:23:02 -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 F3BBB13FB04 for ; Fri, 3 Nov 2017 21:23:01 -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=1509769381; 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: authentication-results:x-originating-ip:x-ms-publictraffictype: x-microsoft-exchange-diagnostics:x-ms-exchange-antispam-srfa-diagnostics: x-ms-office365-filtering-correlation-id:x-microsoft-antispam: x-ms-traffictypediagnostic:x-exchange-antispam-report-test: x-microsoft-antispam-prvs:x-exchange-antispam-report-cfa-test: x-forefront-prvs:x-forefront-antispam-report: received-spf:spamdiagnosticoutput:spamdiagnosticmetadata: Content-Type: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-Transport-CrossTenantHeadersStamped: X-OriginatorOrg:X-NAI-Spam-Flag:X-NAI-Spam-Threshold: X-NAI-Spam-Score:X-NAI-Spam-Version; bh=F E4kxLNDS5hheTOnSsIFYKZCshCG89wBS+BT/GfUF0 4=; b=NBgkQWm+yL6oPpZeOWj8TqJbI6aD8u8iTUBKVuWYlGH3 MWdlRRb2vIyrASNYzeNxCbWWxuP5gX4UeYo8XMOfPSrMDa0UbH LjfgaJgoHQRtJuzsjo19WMgCdKjF1bIqNMw8KYIf07tNq4zf9I 5UDi/pVx5HascQIJErcF2DOTIQk= Received: from DNVEXAPP1N05.corpzone.internalzone.com (unknown [10.44.48.89]) by DNVWSMAILOUT1.mcafee.com with smtp id 6d6d_0683_78dd6631_457a_4ad6_9b0c_628c42f7bcf4; Fri, 03 Nov 2017 23:23:00 -0500 Received: from DNVEXUSR1N09.corpzone.internalzone.com (10.44.48.82) by DNVEXAPP1N05.corpzone.internalzone.com (10.44.48.89) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Fri, 3 Nov 2017 22:22:59 -0600 Received: from DNVEXUSR1N12.corpzone.internalzone.com (10.44.48.85) by DNVEXUSR1N09.corpzone.internalzone.com (10.44.48.82) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Fri, 3 Nov 2017 22:22:58 -0600 Received: from DNVO365EDGE1.corpzone.internalzone.com (10.44.176.66) by DNVEXUSR1N12.corpzone.internalzone.com (10.44.48.85) with Microsoft SMTP Server (TLS) id 15.0.1347.2 via Frontend Transport; Fri, 3 Nov 2017 22:22:58 -0600 Received: from NAM01-SN1-obe.outbound.protection.outlook.com (10.44.176.240) by edge.mcafee.com (10.44.176.66) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Fri, 3 Nov 2017 22:22:58 -0600 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.20.197.13; Sat, 4 Nov 2017 04:22:56 +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.20.0197.017; Sat, 4 Nov 2017 04:22:56 +0000 From: "Konda, Tirumaleswar Reddy" To: Jon Shallow , "dots@ietf.org" Thread-Topic: [Dots] Data channel issues with GET Thread-Index: AdNU60NzSK+9AEyfSlySy52mDm5lHgABRb+AAAzRC0A= Date: Sat, 4 Nov 2017 04:22:56 +0000 Message-ID: References: <06f601d354eb$482cce20$d8866a60$@jpshallow.com> <070f01d354f0$5b0d7850$112868f0$@jpshallow.com> In-Reply-To: <070f01d354f0$5b0d7850$112868f0$@jpshallow.com> 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: [122.171.65.119] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DM5PR16MB1787; 6:sYl7wGoBT2STbw/huwR610jifonyy3Z0AOB1jpK9kG0q79N7ubsQcPVAm/HUgNVeKD0SHW8PyWr3WUPyAOzHjpHkglHSBCuBy45Oo8VOzSfoRpCpv6315l8+4bvb/BNmLMflQSYLX+thN37NeHh7xXgYK8RBOVKbYrxdRTDHpmAKOcRSYoMJivDe6MxGVt25jno1MT86/g14+wqv7RoJp/mtYF5zEO9mCvt2ikxEANs6gWd7fDMFdoy9pJuhvaJkJp/UBTITDDvAkKbjU6tDNtKgQfU9oKn1uiYp21sZoh064CGVz6H8l5fvIMyN2jc80HjJhQBJbYp6FW8bH5zLXxJ8SER9g9pbfs45IBQ+FtY=; 5:/JMn6mCWO60MhK0yU23SitZCtG7XlzreOQdnqWlCKhvA//NTP0F/HaplK1qF/BNXZ6zRbMDDrksQUQB0sAXaKa1B6AY1/asZjD5PkgLGfR5Bj6Rriuii3R7+PYBkxd8GalbCJqMsb/P8bHfevS7IK8zByPxl5WXOkowDh/AIIgk=; 24:tL1Q5JlHYsn23wLJM3dO/+NCelmd+OMbQK2MlIg2+fm053tqzcF4k7WURxceCdE+BHeFgdEVbDp43P78Wxv7KmaipnwsMxu7qQaiCUvYMMs=; 7:4enxtFt27i/qjoX4/xmBFp34X716KNI1oGA82s9srEwkD+qwS4DXILRIJbHPlgDLk9jvFm9Lwll7aTgtd5UMsYbFvUq0fFFQXuLCXfVpSldF3EcpOxnaHpeZ0/VPe4I/kF7jIyawhvMIlYaF4ANDgCSXdh4+Xes01tO3KY9XczJ38r9HRhscja/NyUxCwSGWDOni6lQ1tNd/oUl0eiDKNG1mlWAhrBECckI0nO1TFUEwduZD0peD1hDUiRw8zlaN x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: afb982d9-695f-4917-1da7-08d5233bb999 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(2017052603246); SRVR:DM5PR16MB1787; x-ms-traffictypediagnostic: DM5PR16MB1787: x-exchange-antispam-report-test: UriScan:(190756311086443)(158342451672863)(21748063052155); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(8121501046)(5005006)(3002001)(93006095)(93001095)(3231021)(100000703101)(100105400095)(10201501046)(6041248)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123562025)(20161123555025)(20161123560025)(20161123564025)(20161123558100)(6072148)(201708071742011)(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: 048111149A x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(346002)(376002)(32952001)(51444003)(189002)(199003)(68736007)(7736002)(54356999)(50986999)(76176999)(2906002)(53546010)(575784001)(86362001)(2950100002)(5660300001)(3660700001)(101416001)(33656002)(14454004)(106356001)(7696004)(105586002)(6306002)(9686003)(790700001)(6116002)(81156014)(3846002)(74316002)(102836003)(66066001)(81166006)(3280700002)(8936002)(229853002)(236005)(8676002)(55016002)(54896002)(6436002)(110136005)(19609705001)(2501003)(189998001)(478600001)(6246003)(99286004)(72206003)(2900100001)(6506006)(25786009)(53936002)(316002)(97736004)(80792005)(77096006)(85282002); DIR:OUT; SFP:1101; SCL:1; SRVR:DM5PR16MB1787; H:DM5PR16MB1788.namprd16.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; 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_DM5PR16MB17888D124FE0134FD80572EEEA520DM5PR16MB1788namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: afb982d9-695f-4917-1da7-08d5233bb999 X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Nov 2017 04:22:56.6499 (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 <6151> : inlines <6156> : streams <1769285> : uri <2527792> Archived-At: Subject: Re: [Dots] Data channel issues with GET 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Nov 2017 04:23:04 -0000 --_000_DM5PR16MB17888D124FE0134FD80572EEEA520DM5PR16MB1788namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable If the client-identifier is not conveyed by the DOTS gateway in the GET req= uest, the DOTS server cannot determine the DOTS signals associated with a D= OTS client, and will not return any results. Irrespective of the method used by the DOTS client, the DOTS gateway should= add the client-identifier to the requests from the DOTS clients. -Tiru From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Jon Shallow Sent: Saturday, November 4, 2017 3:39 AM To: dots@ietf.org Subject: Re: [Dots] Data channel issues with GET Hi Tiru et al, In addition, on the signal channel, it is also worth considering moving cli= ent-identifier to the same level as mitigation-id, so that =3D=3D=3D=3D=3D=3D 1) To retrieve all DOTS signals signaled by the DOTS client. Header: GET (Code=3D0.01) Uri-Host: "host" Uri-Path: ".well-known" Uri-Path: "dots" Uri-Path: "version" Uri-Path: "mitigate" Observe : 0 { "mitigation-scope": { "client-identifier": [ "string" ] } } =3D=3D=3D=3D=3D=3D=3D=3D Can be reduced to 1) To retrieve all DOTS signals signaled by the DOTS client. Header: GET (Code=3D0.01) Uri-Host: "host" Uri-Path: ".well-known" Uri-Path: "dots" Uri-Path: "version" Uri-Path: "mitigate" Observe : 0 =3D=3D=3D=3D=3D=3D=3D Regards Jon From: Dots [mailto: dots-bounces@ietf.org] On= Behalf Of Jon Shallow Sent: 03 November 2017 21:33 To: dots@ietf.org Subject: [Dots] Data channel issues with GET Hi Tiru et al, I am having challenges coding up the GET for channel identifiers. A DOTS Client as part of a DOTS gateway can use different client-identifier= s when doing a PUT for the alias-name. The DOTS server will therefore hav= e multiple client-identifier arrays for the DOTS GW client. However when doing a GET using 'content=3Dconfig', as things currently stan= d, only one client-identifier array can returned as per the below in Figure= 7:- =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D "3.2.3. Retrieving Installed Identifiers A GET request is used to retrieve the set of installed identifiers from a DOTS server (Section 3.3.1 in [RFC8040]). Figure 6 shows how to retrieve all the identifiers that were instantiated by the DOTS client. The content parameter and its permitted values are defined in Section 4.8.1 of [RFC8040]. GET /restconf/data/ietf-dots-data-channel-identifier:identifier?\ content=3Dconfig HTTP/1.1 Host: {host}:{port} Accept: application/yang-data+json Figure 6: GET to retrieve all the installed identifiers Figure 7 shows response for all identifiers on the DOTS server. { "ietf-dots-data-channel-identifier:identifier": { "client-identifier": [ "dz6pHjaADkaFTbjr0JGBpw", "iAYmCNPmrYoKoqzgFMiobw" ], "alias": [ { "alias-name": "Server1", "traffic-protocol": [ 6" =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D I think that the yang model needs to be re-written, by moving leaf-list cli= ent-identifier down to the same level as alias-name as :- =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D container identifier { description "Top level container for identifiers"; list alias { key alias-name; description "List of identifiers"; leaf alias-name { type string; description "alias name"; } leaf-list client-identifier { type binary; description "A client identifier conveyed by a DOTS = gateway to a remote DOTS server."; reference "I-D.itef-dots-signal-channel"; } leaf-list target-ip { =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D And reflected appropriately throughout the data channel draft. The issue is the same for the access control list - client-identifier needs= to be at the same level as acl-name module: ietf-dots-access-control-list augment /ietf-acl:access-lists: +--rw client-identifier* binary =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Needs to be module: ietf-dots-access-control-list augment /ietf-acl:access-lists/ietf-acl:acl/: +--rw client-identifier* binary =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D And replicated as appropriate throughout the draft Regards Jon --_000_DM5PR16MB17888D124FE0134FD80572EEEA520DM5PR16MB1788namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

If the cl= ient-identifier is not conveyed by the DOTS gateway in the GET request, the= DOTS server cannot determine the DOTS signals associated with a DOTS clien= t, and will not return any results.

Irrespect= ive of the method used by the DOTS client, the DOTS gateway should add the = client-identifier to the requests from the DOTS clients.

&nbs= p;

-Tiru

 

From:<= /span> Dots [mailto:dots-bou= nces@ietf.org] On Behalf Of Jon Shallow
Sent: Saturday, November 4, 2017 3:39 AM
To: dots@ietf.org
Subject: Re: [Dots] Data channel issues with GET

 

Hi Tiru= et al,

&n= bsp;

In addi= tion, on the signal channel, it is also worth considering moving client-ide= ntifier to the same level as mitigation-id, so that

&n= bsp;

=3D=3D= =3D=3D=3D=3D

 &= nbsp; 1) To retrieve all DOTS signals signaled by the DOTS client.

&n= bsp;

 &= nbsp;   Header: GET (Code=3D0.01)

 &= nbsp;   Uri-Host: "host"

 &= nbsp;   Uri-Path: ".well-known"

 &= nbsp;   Uri-Path: "dots"

 &= nbsp;   Uri-Path: "version"

 &= nbsp;   Uri-Path: "mitigate"

 &= nbsp;   Observe : 0

 &= nbsp;   {

 &= nbsp;     "mitigation-scope": {

 &= nbsp;       "client-identifier": [<= o:p>

 &= nbsp;          "string&qu= ot;

 &= nbsp;       ]

 &= nbsp;     }

 &= nbsp;   }

=3D=3D= =3D=3D=3D=3D=3D=3D

Can be = reduced to

&n= bsp;

 &= nbsp; 1) To retrieve all DOTS signals signaled by the DOTS client.=

&n= bsp;

 &= nbsp;   Header: GET (Code=3D0.01)

 &= nbsp;   Uri-Host: "host"

 &= nbsp;   Uri-Path: ".well-known"

 &= nbsp;   Uri-Path: "dots"

 &= nbsp;   Uri-Path: "version"

 &= nbsp;   Uri-Path: "mitigate"

 &= nbsp;   Observe : 0

&n= bsp;

=3D=3D= =3D=3D=3D=3D=3D

&n= bsp;

Regards=

&n= bsp;

Jon

&n= bsp;

From: Dots [mailto: dots-bounces@ietf.org] On B= ehalf Of Jon Shallow
Sent: 03 November 2017 21:33
To: dots@ietf.org
Subject: [Dots] Data channel issues with GET

 

Hi Tiru et al,

 

I am having challenges coding u= p the GET for channel identifiers.

 

A DOTS Client as part of a DOTS= gateway can use different client-identifiers when doing a PUT for the alia= s-name.   The DOTS server will therefore have multiple client-ide= ntifier arrays for the DOTS GW client.

 

However when doing a GET using = ‘content=3Dconfig’, as things currently stand, only one client-= identifier array can returned as per the below in Figure 7:-

 

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<= /span>

 

“3.2.3.  Retrieving = Installed Identifiers

 

   A GET request is u= sed to retrieve the set of installed identifiers

   from a DOTS server= (Section 3.3.1 in [RFC8040]).  Figure 6 shows how

   to retrieve all th= e identifiers that were instantiated by the DOTS

   client.  The = content parameter and its permitted values are defined

   in Section 4.8.1 o= f [RFC8040].

 

     GET /r= estconf/data/ietf-dots-data-channel-identifier:identifier?\

     &= nbsp;   content=3Dconfig HTTP/1.1

     Host: = {host}:{port}

     Accept= : application/yang-data+json

 

     &= nbsp;    Figure 6: GET to retrieve all the installed identif= iers

 

   Figure 7 shows res= ponse for all identifiers on the DOTS server.

 

   {

    "ietf-d= ots-data-channel-identifier:identifier": {

     &= nbsp; "client-identifier": [

     &= nbsp;    "dz6pHjaADkaFTbjr0JGBpw",

     &= nbsp;    "iAYmCNPmrYoKoqzgFMiobw"

     &= nbsp; ],

     &= nbsp; "alias": [

     &= nbsp;   {

     &= nbsp;     "alias-name": "Server1",<= o:p>

     &= nbsp;     "traffic-protocol": [

     &= nbsp;       6”

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D

 

I think that the yang model nee= ds to be re-written, by moving leaf-list client-identifier down to the same= level as alias-name as :-

 

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D

     contai= ner identifier {

     &= nbsp;    description "Top level container for identifie= rs";

 

     &= nbsp;        list alias {

     &= nbsp;           &nbs= p; key alias-name;

     &= nbsp;            &nb= sp;description "List of identifiers";

 

     &= nbsp;           &nbs= p; leaf alias-name {

     &= nbsp;           &nbs= p;    type string;

     &= nbsp;           &nbs= p;    description "alias name";<= /p>

     &= nbsp;           &nbs= p; }

 

     &= nbsp;           &nbs= p; leaf-list client-identifier {

     &= nbsp;           &nbs= p;    type binary;

     &= nbsp;           &nbs= p;    description  "A client identifier conveyed b= y a DOTS gateway

     &= nbsp;           &nbs= p;            &= nbsp;     to a remote DOTS server.";

 

     &= nbsp;           &nbs= p;    reference

     &= nbsp;           &nbs= p;       "I-D.itef-dots-signal-channel&q= uot;;

     &= nbsp;           &nbs= p; }

 

     &= nbsp;           &nbs= p; leaf-list target-ip {

 

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D

 

And reflected appropriately thr= oughout the data channel draft.

 

The issue is the same for the a= ccess control list – client-identifier needs to be at the same level = as acl-name

 

module: ietf-dots-access-contro= l-list

  augment /ietf-acl:access= -lists:

    +--rw cl= ient-identifier*   binary

 

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D

Needs to be

 

module: ietf-dots-access-contro= l-list

  augment /ietf-acl:access= -lists/ietf-acl:acl/:

    +--rw cl= ient-identifier*   binary

 

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D

 

And replicated as appropriate t= hroughout the draft

 

Regards

 

Jon

--_000_DM5PR16MB17888D124FE0134FD80572EEEA520DM5PR16MB1788namp_-- From nobody Sat Nov 4 03:46:51 2017 Return-Path: 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 2889F13FB8B for ; Sat, 4 Nov 2017 03:46:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 JFDNHh1AyY5p for ; Sat, 4 Nov 2017 03:46:46 -0700 (PDT) Received: from mail.jpshallow.com (mail.jpshallow.com [217.40.240.153]) (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 619DB13FB6A for ; Sat, 4 Nov 2017 03:46:46 -0700 (PDT) Received: from [127.0.0.1] (helo=N01332) by mail.jpshallow.com with smtps (TLSv1:ECDHE-RSA-AES256-SHA:256) (Exim 4.89) (envelope-from ) id 1eAvyN-0000KT-CV; Sat, 04 Nov 2017 10:46:43 +0000 From: "Jon Shallow" To: "'Konda, Tirumaleswar Reddy'" , References: <06f601d354eb$482cce20$d8866a60$@jpshallow.com> In-Reply-To: Date: Sat, 4 Nov 2017 10:46:44 -0000 Message-ID: <075801d3555a$34dbbd30$9e933790$@jpshallow.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0759_01D3555A.34DE2E30" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQGq3C7tF9zj9qMEJcmaXbDvWUqFfQEpBvoXo0ucOQA= Content-Language: en-gb Archived-At: Subject: Re: [Dots] Data channel issues with GET 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Nov 2017 10:46:49 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0759_01D3555A.34DE2E30 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Tiru, Agreed that a request from a DOTS client going through multiple DOTS gateways will get the appropriate client-identifier added, and the response initially generated by the final DOTS server will have all the client-identifiers. However, as the response passes back through the DOTS gateways, the appropriate client-identifier will get stripped off and the originating DOTS client will have no visibility of the client-identifiers - as per " A DOTS gateway MUST update the 'client-identifier' list in the response to remove the 'client-identifier' value it had added in the corresponding request before forwarding the response to the DOTS client." So, Figure 6 and Figure 7 do not correctly portray the reality as seen by a DOTS client (whether on a DOTS gateway or not). When the DOTS Gateway client component generates the GET request should the request be (to match Figure 7 response) " GET /restconf/data/ietf-dots-data-channel-identifier:identifier?\ content=config&client-identifier=dz6pHjaADkaFTbjr0JGBpw,iAYmCNPmrYoKoqzgFMio bw HTTP/1.1 Host: {host}:{port} Accept: application/yang-data+json Figure 6: GET to retrieve all the installed identifiers" ===== This still does not answer my implied concern - how does a DOTS gateway client request all the aliases / filters / mitigations to sync up state when, say, the DOTS gateway client restarts? - The DOTS gateway may not know all the client-identifiers that are talking to the server component of the DOTS gateway - they may be behind yet another DOTS gateway. Taking this more complex example involving multiple gateways (should it be in the drafts somewhere for helping with client-identifier clarity?) DOTS client (C1aj) ----------------------------------------- (S1j) DOTS gateway J (C2j) ----------\ DOTS client (C1bj) --------------------------------------------/ | | DOTS client (C1ax) ------- (S1x) DOTS gateway X (C2x) ------ (S2k) DOTS gateway K (C3k) -------- (S3) DOTS client (C1bx) ----------/ | | DOTS client (C1ay) ------- (S1y) DOTS gateway Y (C2y) ---------/ DOTS client (C1by) ----------/ If C3k restarts how is he able to re-sync his information from S3? C3K does not have a GET 'all' capability with client-identifier being above the level of alias-name. It maybe that C3k does not need to re-sync, but C3k should have the flexibility if C3k is, say, able to cache information to reduce the number of requests having to pass all the way through to S3. As an aside, in my current implementation, where CIH(xxx) is the Client Identifier hash of xxx C1ax does a PUT (alias-name=Server1), C2x does a PUT (alias-name=Server1&client-identifer=CIH(C1ax)), C3k does a PUT (alias-name=Server1&client-identifer=CIH(C1ax),CIH(C2x)) and S3 uniquely stores this alias-name as (alias-name=Server1&client-identifer=CIH(C1ax),CIH(C2x),CIH(C3k)) so that if any of the DOTS clients do a PUT (alias-name=Server1) [with same alias name] S3 can differentiate them all. As CIH(C1ax) should be unique across all DOTS clients, do we really need to add in all the other CIH() as the traffic passes up through to S3? Regards Jon From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of Konda, Tirumaleswar Reddy Sent: 04 November 2017 04:16 To: Jon Shallow; dots@ietf.org Subject: Re: [Dots] Data channel issues with GET Hi Jon, GET request will only retrieve the alias-names installed by a DOTS client and not the alias-names for all the DOTS clients. The client-identifier array is uniquely identifying the DOTS client and does not need be repeated for every alias-name conveyed by the client. Figure 6 is showing the GET request from the DOTS client, and the DOTS gateways will update the GET request to add and update the client-identifier array. I don't think the client-identifier should be in the same level as alias-name. -Tiru From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Jon Shallow Sent: Saturday, November 4, 2017 3:03 AM To: dots@ietf.org Subject: [Dots] Data channel issues with GET Hi Tiru et al, I am having challenges coding up the GET for channel identifiers. A DOTS Client as part of a DOTS gateway can use different client-identifiers when doing a PUT for the alias-name. The DOTS server will therefore have multiple client-identifier arrays for the DOTS GW client. However when doing a GET using 'content=config', as things currently stand, only one client-identifier array can returned as per the below in Figure 7:- =============================== "3.2.3. Retrieving Installed Identifiers A GET request is used to retrieve the set of installed identifiers from a DOTS server (Section 3.3.1 in [RFC8040]). Figure 6 shows how to retrieve all the identifiers that were instantiated by the DOTS client. The content parameter and its permitted values are defined in Section 4.8.1 of [RFC8040]. GET /restconf/data/ietf-dots-data-channel-identifier:identifier?\ content=config HTTP/1.1 Host: {host}:{port} Accept: application/yang-data+json Figure 6: GET to retrieve all the installed identifiers Figure 7 shows response for all identifiers on the DOTS server. { "ietf-dots-data-channel-identifier:identifier": { "client-identifier": [ "dz6pHjaADkaFTbjr0JGBpw", "iAYmCNPmrYoKoqzgFMiobw" ], "alias": [ { "alias-name": "Server1", "traffic-protocol": [ 6" =========== I think that the yang model needs to be re-written, by moving leaf-list client-identifier down to the same level as alias-name as :- =========== container identifier { description "Top level container for identifiers"; list alias { key alias-name; description "List of identifiers"; leaf alias-name { type string; description "alias name"; } leaf-list client-identifier { type binary; description "A client identifier conveyed by a DOTS gateway to a remote DOTS server."; reference "I-D.itef-dots-signal-channel"; } leaf-list target-ip { ================ And reflected appropriately throughout the data channel draft. The issue is the same for the access control list - client-identifier needs to be at the same level as acl-name module: ietf-dots-access-control-list augment /ietf-acl:access-lists: +--rw client-identifier* binary ============= Needs to be module: ietf-dots-access-control-list augment /ietf-acl:access-lists/ietf-acl:acl/: +--rw client-identifier* binary =============== And replicated as appropriate throughout the draft Regards Jon ------=_NextPart_000_0759_01D3555A.34DE2E30 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Tiru,

 

Agreed that a request = from a DOTS client going through multiple DOTS gateways will get the = appropriate client-identifier added, and the response initially = generated by the final DOTS server will have all the = client-identifiers.

 

However, as the response = passes back through the DOTS gateways, the appropriate client-identifier = will get stripped off and the originating DOTS client will have no = visibility of the client-identifiers – as = per

“   A DOTS gateway MUST update = the 'client-identifier' list in the

   response to = remove the 'client-identifier' value it had added in = the

   corresponding request before = forwarding the response to the DOTS

   = client.”

 

So, Figure 6 and Figure = 7 do not correctly portray the reality as seen by a DOTS client (whether = on a DOTS gateway or not).

 

When the DOTS Gateway = client component generates the GET request should the request be (to = match Figure 7 response)

 

“    GET = /restconf/data/ietf-dots-data-channel-identifier:identifier?\<= /span>

         = content=3Dconfig&client-identifier=3Ddz6pHjaADkaFTbjr0JGBpw,iAYmCNPmr= YoKoqzgFMiobw HTTP/1.1

     Host: = {host}:{port}

     Accept: = application/yang-data+json

 

        &= nbsp; Figure 6: GET to retrieve all the installed = identifiers”

 

=3D=3D=3D=3D=3D

 

This still does not = answer my implied concern – how does a DOTS gateway client request = all the aliases / filters / mitigations to sync up state when, say, the = DOTS gateway client restarts?

- The DOTS gateway may = not know all the client-identifiers that are talking to the server = component of the DOTS gateway – they may be behind yet another = DOTS gateway.

 

Taking this more complex = example involving multiple gateways (should it be in the drafts = somewhere for helping with client-identifier = clarity?)

 

DOTS client (C1aj) = ----------------------------------------- (S1j) DOTS gateway J (C2j) = ----------\  

DOTS = client (C1bj) = --------------------------------------------/    &nbs= p;            = ;  =             &= nbsp;  |

         = ;            =             &= nbsp;    =             &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;           |

DOTS = client (C1ax) ------- (S1x) DOTS gateway X (C2x) ------ (S2k) DOTS = gateway K (C3k) -------- (S3)   

DOTS client (C1bx) = ----------/          &n= bsp;           &nb= sp;   =        |     =             &= nbsp;          =    

         = ;            =             &= nbsp;           &n= bsp;           &nb= sp;     |      &nb= sp;           &nbs= p;         =      

DOTS client (C1ay) ------- (S1y) DOTS gateway Y = (C2y) = ---------/          &nb= sp;           &nbs= p;    =       

DOTS client (C1by) = ----------/          &n= bsp;           &nb= sp;   =             &= nbsp;           &n= bsp;           &nb= sp;    

         = ;            =             &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;            = ;            =    

 

If C3k restarts how is = he able to re-sync his information from S3?  C3K does not have a = GET ‘all’ capability with client-identifier being above the = level of alias-name.  It maybe that C3k does not need to re-sync, = but C3k should have the flexibility if C3k is, say, able to cache = information to reduce the number of requests having to pass all the way = through to S3.

 

As an aside, in my = current implementation, where CIH(xxx) is the Client Identifier hash of = xxx

 

C1ax does a PUT = (alias-name=3DServer1),

C2x does a PUT = (alias-name=3DServer1&client-identifer=3DCIH(C1ax)),

C3k does a PUT = (alias-name=3DServer1&client-identifer=3DCIH(C1ax),CIH(C2x))

and S3 = uniquely stores this alias-name as = (alias-name=3DServer1&client-identifer=3DCIH(C1ax),CIH(C2x),CIH(C3k))=

so that if any of the DOTS clients do a PUT = (alias-name=3DServer1) [with same alias name] S3 can differentiate them = all.

 

As CIH(C1ax) should be = unique across all DOTS clients, do we really need to add in all the = other CIH() as the traffic passes up through to = S3?

 

Regards

 

Jon

 

From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of = Konda, Tirumaleswar Reddy
Sent: 04 November 2017 = 04:16
To: Jon Shallow; dots@ietf.org
Subject: Re: = [Dots] Data channel issues with GET

 

Hi = Jon,

 

GET request will only retrieve the = alias-names installed by a DOTS client and not the alias-names for all = the DOTS clients. The client-identifier array is uniquely identifying = the DOTS client and does not need be repeated for every alias-name = conveyed by the client.  Figure 6 is showing the GET request from = the DOTS client, and the DOTS gateways will update the GET request to = add and update the client-identifier array.

I don’t think the = client-identifier should be in the same level as alias-name. =

 

-Tiru

 

From: Dots [mailto:dots-bounces@ietf.org] = On Behalf Of Jon Shallow
Sent: Saturday, November 4, = 2017 3:03 AM
To: dots@ietf.org
Subject: = [Dots] Data channel issues with GET

 

Hi Tiru et al,

 

I am having = challenges coding up the GET for channel identifiers.

 

A DOTS = Client as part of a DOTS gateway can use different client-identifiers = when doing a PUT for the alias-name.   The DOTS server will = therefore have multiple client-identifier arrays for the DOTS GW = client.

 

However when doing a GET using = ‘content=3Dconfig’, as things currently stand, only one = client-identifier array can returned as per the below in Figure = 7:-

 

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

 

“3.2.3.  Retrieving Installed = Identifiers

 

   A GET request is used to retrieve the set = of installed identifiers

   = from a DOTS server (Section 3.3.1 in [RFC8040]).  Figure 6 shows = how

   to retrieve all the = identifiers that were instantiated by the DOTS

   client.  The content parameter and = its permitted values are defined

   in Section 4.8.1 of = [RFC8040].

 

     GET = /restconf/data/ietf-dots-data-channel-identifier:identifier?\<= /p>

         = content=3Dconfig HTTP/1.1

     Host: = {host}:{port}

     Accept: = application/yang-data+json

 

          = Figure 6: GET to retrieve all the installed identifiers

 

   = Figure 7 shows response for all identifiers on the DOTS = server.

 

   {

    = "ietf-dots-data-channel-identifier:identifier": = {

       = "client-identifier": [

          = "dz6pHjaADkaFTbjr0JGBpw",

          = "iAYmCNPmrYoKoqzgFMiobw"

       = ],

       = "alias": [

         = {

         &= nbsp; "alias-name": "Server1",

         &= nbsp; "traffic-protocol": [

         &= nbsp;   6”

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

 

I think that = the yang model needs to be re-written, by moving leaf-list = client-identifier down to the same level as alias-name as = :-

 

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

     container identifier = {

          = description "Top level container for = identifiers";

 

         &= nbsp;    list alias {

         &= nbsp;         key = alias-name;

          =          description = "List of identifiers";

 

         &= nbsp;         leaf alias-name = {

         &= nbsp;            = type string;

         &= nbsp;            = description "alias name";

         &= nbsp;         }

 

         &= nbsp;         leaf-list = client-identifier {

         &= nbsp;            = type binary;

         &= nbsp;            = description  "A client identifier conveyed by a DOTS = gateway

         &= nbsp;           &n= bsp;           &nb= sp;  to a remote DOTS server.";

 

         &= nbsp;            = reference

         &= nbsp;           &n= bsp;   = "I-D.itef-dots-signal-channel";

         &= nbsp;         }

 

         &= nbsp;         leaf-list = target-ip {

 

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

 

And reflected appropriately throughout the data = channel draft.

 

The issue is = the same for the access control list – client-identifier needs to = be at the same level as acl-name

 

module: = ietf-dots-access-control-list

  = augment /ietf-acl:access-lists:

    +--rw = client-identifier*   binary

 

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

<= p class=3DMsoNormal>Needs to be

 

module: = ietf-dots-access-control-list

  = augment /ietf-acl:access-lists/ietf-acl:acl/:

    +--rw = client-identifier*   binary

 

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

 

And = replicated as appropriate throughout the draft

 

Regards

 

Jon

------=_NextPart_000_0759_01D3555A.34DE2E30-- From nobody Sat Nov 4 04:45:51 2017 Return-Path: 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 07B5813FB22 for ; Sat, 4 Nov 2017 04:45:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 fCvNl_e2dCUQ for ; Sat, 4 Nov 2017 04:45:46 -0700 (PDT) Received: from mail.jpshallow.com (mail.jpshallow.com [217.40.240.153]) (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 5329013FAEE for ; Sat, 4 Nov 2017 04:45:46 -0700 (PDT) Received: from [127.0.0.1] (helo=N01332) by mail.jpshallow.com with smtps (TLSv1:ECDHE-RSA-AES256-SHA:256) (Exim 4.89) (envelope-from ) id 1eAwtO-0000MB-Oc; Sat, 04 Nov 2017 11:45:38 +0000 From: "Jon Shallow" To: "Konda, Tirumaleswar Reddy" , References: <06f601d354eb$482cce20$d8866a60$@jpshallow.com> <075801d3555a$34dbbd30$9e933790$@jpshallow.com> In-Reply-To: <075801d3555a$34dbbd30$9e933790$@jpshallow.com> Date: Sat, 4 Nov 2017 11:45:39 -0000 Message-ID: <077401d35562$7015a8e0$5040faa0$@jpshallow.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0775_01D35562.7018B620" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQGq3C7tF9zj9qMEJcmaXbDvWUqFfQEpBvoXAuZQ++KjNJDRkA== Content-Language: en-gb Archived-At: Subject: Re: [Dots] Data channel issues with GET 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Nov 2017 11:45:49 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0775_01D35562.7018B620 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Actually, looking at RFC8040, the Figure 6 syntax should be " GET /restconf/data/ietf-dots-data-channel-identifier:identifier/\ client-identifier=dz6pHjaADkaFTbjr0JGBpw,iAYmCNPmrYoKoqzgFMiobw?\ content=config HTTP/1.1 Host: {host}:{port} Accept: application/yang-data+json Figure 6: GET to retrieve all the installed identifiers" To represent the Figure 7 output. Correct? Regards Jon From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of Jon Shallow Sent: 04 November 2017 10:47 To: 'Konda, Tirumaleswar Reddy'; dots@ietf.org Subject: Re: [Dots] Data channel issues with GET Hi Tiru, Agreed that a request from a DOTS client going through multiple DOTS gateways will get the appropriate client-identifier added, and the response initially generated by the final DOTS server will have all the client-identifiers. However, as the response passes back through the DOTS gateways, the appropriate client-identifier will get stripped off and the originating DOTS client will have no visibility of the client-identifiers - as per " A DOTS gateway MUST update the 'client-identifier' list in the response to remove the 'client-identifier' value it had added in the corresponding request before forwarding the response to the DOTS client." So, Figure 6 and Figure 7 do not correctly portray the reality as seen by a DOTS client (whether on a DOTS gateway or not). When the DOTS Gateway client component generates the GET request should the request be (to match Figure 7 response) " GET /restconf/data/ietf-dots-data-channel-identifier:identifier?\ content=config&client-identifier=dz6pHjaADkaFTbjr0JGBpw,iAYmCNPmrYoKoqzgFMio bw HTTP/1.1 Host: {host}:{port} Accept: application/yang-data+json Figure 6: GET to retrieve all the installed identifiers" ===== This still does not answer my implied concern - how does a DOTS gateway client request all the aliases / filters / mitigations to sync up state when, say, the DOTS gateway client restarts? - The DOTS gateway may not know all the client-identifiers that are talking to the server component of the DOTS gateway - they may be behind yet another DOTS gateway. Taking this more complex example involving multiple gateways (should it be in the drafts somewhere for helping with client-identifier clarity?) DOTS client (C1aj) ----------------------------------------- (S1j) DOTS gateway J (C2j) ----------\ DOTS client (C1bj) --------------------------------------------/ | | DOTS client (C1ax) ------- (S1x) DOTS gateway X (C2x) ------ (S2k) DOTS gateway K (C3k) -------- (S3) DOTS client (C1bx) ----------/ | | DOTS client (C1ay) ------- (S1y) DOTS gateway Y (C2y) ---------/ DOTS client (C1by) ----------/ If C3k restarts how is he able to re-sync his information from S3? C3K does not have a GET 'all' capability with client-identifier being above the level of alias-name. It maybe that C3k does not need to re-sync, but C3k should have the flexibility if C3k is, say, able to cache information to reduce the number of requests having to pass all the way through to S3. As an aside, in my current implementation, where CIH(xxx) is the Client Identifier hash of xxx C1ax does a PUT (alias-name=Server1), C2x does a PUT (alias-name=Server1&client-identifer=CIH(C1ax)), C3k does a PUT (alias-name=Server1&client-identifer=CIH(C1ax),CIH(C2x)) and S3 uniquely stores this alias-name as (alias-name=Server1&client-identifer=CIH(C1ax),CIH(C2x),CIH(C3k)) so that if any of the DOTS clients do a PUT (alias-name=Server1) [with same alias name] S3 can differentiate them all. As CIH(C1ax) should be unique across all DOTS clients, do we really need to add in all the other CIH() as the traffic passes up through to S3? Regards Jon From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of Konda, Tirumaleswar Reddy Sent: 04 November 2017 04:16 To: Jon Shallow; dots@ietf.org Subject: Re: [Dots] Data channel issues with GET Hi Jon, GET request will only retrieve the alias-names installed by a DOTS client and not the alias-names for all the DOTS clients. The client-identifier array is uniquely identifying the DOTS client and does not need be repeated for every alias-name conveyed by the client. Figure 6 is showing the GET request from the DOTS client, and the DOTS gateways will update the GET request to add and update the client-identifier array. I don't think the client-identifier should be in the same level as alias-name. -Tiru From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Jon Shallow Sent: Saturday, November 4, 2017 3:03 AM To: dots@ietf.org Subject: [Dots] Data channel issues with GET Hi Tiru et al, I am having challenges coding up the GET for channel identifiers. A DOTS Client as part of a DOTS gateway can use different client-identifiers when doing a PUT for the alias-name. The DOTS server will therefore have multiple client-identifier arrays for the DOTS GW client. However when doing a GET using 'content=config', as things currently stand, only one client-identifier array can returned as per the below in Figure 7:- =============================== "3.2.3. Retrieving Installed Identifiers A GET request is used to retrieve the set of installed identifiers from a DOTS server (Section 3.3.1 in [RFC8040]). Figure 6 shows how to retrieve all the identifiers that were instantiated by the DOTS client. The content parameter and its permitted values are defined in Section 4.8.1 of [RFC8040]. GET /restconf/data/ietf-dots-data-channel-identifier:identifier?\ content=config HTTP/1.1 Host: {host}:{port} Accept: application/yang-data+json Figure 6: GET to retrieve all the installed identifiers Figure 7 shows response for all identifiers on the DOTS server. { "ietf-dots-data-channel-identifier:identifier": { "client-identifier": [ "dz6pHjaADkaFTbjr0JGBpw", "iAYmCNPmrYoKoqzgFMiobw" ], "alias": [ { "alias-name": "Server1", "traffic-protocol": [ 6" =========== I think that the yang model needs to be re-written, by moving leaf-list client-identifier down to the same level as alias-name as :- =========== container identifier { description "Top level container for identifiers"; list alias { key alias-name; description "List of identifiers"; leaf alias-name { type string; description "alias name"; } leaf-list client-identifier { type binary; description "A client identifier conveyed by a DOTS gateway to a remote DOTS server."; reference "I-D.itef-dots-signal-channel"; } leaf-list target-ip { ================ And reflected appropriately throughout the data channel draft. The issue is the same for the access control list - client-identifier needs to be at the same level as acl-name module: ietf-dots-access-control-list augment /ietf-acl:access-lists: +--rw client-identifier* binary ============= Needs to be module: ietf-dots-access-control-list augment /ietf-acl:access-lists/ietf-acl:acl/: +--rw client-identifier* binary =============== And replicated as appropriate throughout the draft Regards Jon ------=_NextPart_000_0775_01D35562.7018B620 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Actually, looking at RFC8040, the Figure 6 = syntax should be

 

“    GET = /restconf/data/ietf-dots-data-channel-identifier:identifier/\<= /span>

         = client-identifier=3Ddz6pHjaADkaFTbjr0JGBpw,iAYmCNPmrYoKoqzgFMiobw?\<= /o:p>

         = content=3Dconfig HTTP/1.1

     = Host: {host}:{port}

     Accept: = application/yang-data+json

 

        &= nbsp; Figure 6: GET to retrieve all the installed = identifiers”

 

To represent the Figure = 7 output.

 

Correct?

 

Regards

 

Jon

 

From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of = Jon Shallow
Sent: 04 November 2017 10:47
To: = 'Konda, Tirumaleswar Reddy'; dots@ietf.org
Subject: Re: [Dots] = Data channel issues with GET

 

Hi Tiru,

 

Agreed that a request = from a DOTS client going through multiple DOTS gateways will get the = appropriate client-identifier added, and the response initially = generated by the final DOTS server will have all the = client-identifiers.

 

However, as the response = passes back through the DOTS gateways, the appropriate client-identifier = will get stripped off and the originating DOTS client will have no = visibility of the client-identifiers – as = per

“   A DOTS gateway MUST update = the 'client-identifier' list in the

   response to = remove the 'client-identifier' value it had added in = the

   corresponding request before = forwarding the response to the DOTS

   = client.”

 

So, Figure 6 and Figure = 7 do not correctly portray the reality as seen by a DOTS client (whether = on a DOTS gateway or not).

 

When the DOTS Gateway = client component generates the GET request should the request be (to = match Figure 7 response)

 

“    GET = /restconf/data/ietf-dots-data-channel-identifier:identifier?\<= /span>

         = content=3Dconfig&client-identifier=3Ddz6pHjaADkaFTbjr0JGBpw,iAYmCNPmr= YoKoqzgFMiobw HTTP/1.1

     Host: = {host}:{port}

     Accept: = application/yang-data+json

 

        &= nbsp; Figure 6: GET to retrieve all the installed = identifiers”

 

=3D=3D=3D=3D=3D

 

This still does not = answer my implied concern – how does a DOTS gateway client request = all the aliases / filters / mitigations to sync up state when, say, the = DOTS gateway client restarts?

- The DOTS gateway may = not know all the client-identifiers that are talking to the server = component of the DOTS gateway – they may be behind yet another = DOTS gateway.

 

Taking this more complex = example involving multiple gateways (should it be in the drafts = somewhere for helping with client-identifier = clarity?)

 

DOTS client (C1aj) = ----------------------------------------- (S1j) DOTS gateway J (C2j) = ----------\  

DOTS = client (C1bj) = --------------------------------------------/    &nbs= p;            = ;  =             &= nbsp;  |

         = ;            =             &= nbsp;    =             &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;           |

DOTS = client (C1ax) ------- (S1x) DOTS gateway X (C2x) ------ (S2k) DOTS = gateway K (C3k) -------- (S3)   

DOTS client (C1bx) = ----------/          &n= bsp;           &nb= sp;   =        |     =             &= nbsp;          =    

         = ;            =             &= nbsp;           &n= bsp;           &nb= sp;     |      &nb= sp;           &nbs= p;         =      

DOTS client (C1ay) ------- (S1y) DOTS gateway Y = (C2y) = ---------/          &nb= sp;           &nbs= p;    =       

DOTS client (C1by) = ----------/          &n= bsp;           &nb= sp;   =             &= nbsp;           &n= bsp;           &nb= sp;    

         = ;            =             &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;            = ;            =    

 

If C3k restarts how is = he able to re-sync his information from S3?  C3K does not have a = GET ‘all’ capability with client-identifier being above the = level of alias-name.  It maybe that C3k does not need to re-sync, = but C3k should have the flexibility if C3k is, say, able to cache = information to reduce the number of requests having to pass all the way = through to S3.

 

As an aside, in my = current implementation, where CIH(xxx) is the Client Identifier hash of = xxx

 

C1ax does a PUT = (alias-name=3DServer1),

C2x does a PUT = (alias-name=3DServer1&client-identifer=3DCIH(C1ax)),

C3k does a PUT = (alias-name=3DServer1&client-identifer=3DCIH(C1ax),CIH(C2x))

and S3 = uniquely stores this alias-name as = (alias-name=3DServer1&client-identifer=3DCIH(C1ax),CIH(C2x),CIH(C3k))=

so that if any of the DOTS clients do a PUT = (alias-name=3DServer1) [with same alias name] S3 can differentiate them = all.

 

As CIH(C1ax) should be = unique across all DOTS clients, do we really need to add in all the = other CIH() as the traffic passes up through to = S3?

 

Regards

 

Jon

 

From: Dots [mailto: dots-bounces@ietf.org] On = Behalf Of Konda, Tirumaleswar Reddy
Sent: 04 November 2017 = 04:16
To: Jon Shallow; dots@ietf.org
Subject: Re: = [Dots] Data channel issues with GET

 

Hi = Jon,

 

GET request will only retrieve the = alias-names installed by a DOTS client and not the alias-names for all = the DOTS clients. The client-identifier array is uniquely identifying = the DOTS client and does not need be repeated for every alias-name = conveyed by the client.  Figure 6 is showing the GET request from = the DOTS client, and the DOTS gateways will update the GET request to = add and update the client-identifier array.

I don’t think the = client-identifier should be in the same level as alias-name. =

 

-Tiru

 

From: Dots [mailto:dots-bounces@ietf.org] = On Behalf Of Jon Shallow
Sent: Saturday, November 4, = 2017 3:03 AM
To: dots@ietf.org
Subject: = [Dots] Data channel issues with GET

 

Hi Tiru et al,

 

I am having = challenges coding up the GET for channel identifiers.

 

A DOTS = Client as part of a DOTS gateway can use different client-identifiers = when doing a PUT for the alias-name.   The DOTS server will = therefore have multiple client-identifier arrays for the DOTS GW = client.

 

However when doing a GET using = ‘content=3Dconfig’, as things currently stand, only one = client-identifier array can returned as per the below in Figure = 7:-

 

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

 

“3.2.3.  Retrieving Installed = Identifiers

 

   A GET request is used to retrieve the set = of installed identifiers

   = from a DOTS server (Section 3.3.1 in [RFC8040]).  Figure 6 shows = how

   to retrieve all the = identifiers that were instantiated by the DOTS

   client.  The content parameter and = its permitted values are defined

   in Section 4.8.1 of = [RFC8040].

 

     GET = /restconf/data/ietf-dots-data-channel-identifier:identifier?\<= /p>

         = content=3Dconfig HTTP/1.1

     Host: = {host}:{port}

     Accept: = application/yang-data+json

 

          = Figure 6: GET to retrieve all the installed identifiers

 

   = Figure 7 shows response for all identifiers on the DOTS = server.

 

   {

    = "ietf-dots-data-channel-identifier:identifier": = {

       = "client-identifier": [

          = "dz6pHjaADkaFTbjr0JGBpw",

          = "iAYmCNPmrYoKoqzgFMiobw"

       = ],

       = "alias": [

         = {

         &= nbsp; "alias-name": "Server1",

         &= nbsp; "traffic-protocol": [

         &= nbsp;   6”

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

 

I think that = the yang model needs to be re-written, by moving leaf-list = client-identifier down to the same level as alias-name as = :-

 

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

     container identifier = {

          = description "Top level container for = identifiers";

 

         &= nbsp;    list alias {

         &= nbsp;         key = alias-name;

          =          description = "List of identifiers";

 

         &= nbsp;         leaf alias-name = {

         &= nbsp;            = type string;

         &= nbsp;            = description "alias name";

         &= nbsp;         }

 

         &= nbsp;         leaf-list = client-identifier {

         &= nbsp;            = type binary;

         &= nbsp;            = description  "A client identifier conveyed by a DOTS = gateway

         &= nbsp;           &n= bsp;           &nb= sp;  to a remote DOTS server.";

 

         &= nbsp;            = reference

         &= nbsp;           &n= bsp;   = "I-D.itef-dots-signal-channel";

         &= nbsp;         }

 

         &= nbsp;         leaf-list = target-ip {

 

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

 

And reflected appropriately throughout the data = channel draft.

 

The issue is = the same for the access control list – client-identifier needs to = be at the same level as acl-name

 

module: = ietf-dots-access-control-list

  = augment /ietf-acl:access-lists:

    +--rw = client-identifier*   binary

 

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

<= p class=3DMsoNormal>Needs to be

 

module: = ietf-dots-access-control-list

  = augment /ietf-acl:access-lists/ietf-acl:acl/:

    +--rw = client-identifier*   binary

 

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

 

And = replicated as appropriate throughout the draft

 

Regards

 

Jon

------=_NextPart_000_0775_01D35562.7018B620-- From nobody Sat Nov 4 07:11:54 2017 Return-Path: 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 9708613FB58 for ; Sat, 4 Nov 2017 07:11:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.32 X-Spam-Level: X-Spam-Status: No, score=-4.32 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham 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 YbjYf5mH50ia for ; Sat, 4 Nov 2017 07:11:48 -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 BB06013FB00 for ; Sat, 4 Nov 2017 07:11:47 -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=1509804695; 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: authentication-results:x-originating-ip:x-ms-publictraffictype: x-microsoft-exchange-diagnostics:x-ms-exchange-antispam-srfa-diagnostics: x-ms-office365-filtering-correlation-id:x-microsoft-antispam: x-ms-traffictypediagnostic:x-exchange-antispam-report-test: x-microsoft-antispam-prvs:x-exchange-antispam-report-cfa-test: x-forefront-prvs:x-forefront-antispam-report: received-spf:spamdiagnosticoutput:spamdiagnosticmetadata: Content-Type: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-Transport-CrossTenantHeadersStamped: X-OriginatorOrg:X-NAI-Spam-Flag:X-NAI-Spam-Threshold: X-NAI-Spam-Score:X-NAI-Spam-Version; bh=h vAxKW86rbXwSZXhYTlL6ZmBS7BxeWoJdzTj/lyGyb s=; b=APZxUI5Tf8n3o/9q8Au6ixCaBo8kfR5kYvvCawpWzwoC 71E5cB4b1AJd6pqBD8Jkqj5wPaKIQmfNpkgKIcG7hqzXtEXbAU xzakPKnBCpWy46mHoKXyULD+FJighFHUUE0CCJDAYZ3waqjlgU 0ZP9BTl2YjJGWcYqNNcNypKBiAs= Received: from DNVEXAPP1N04.corpzone.internalzone.com (unknown [10.44.48.88]) by DNVWSMAILOUT1.mcafee.com with smtp id 6d68_80ea_32051642_3a38_4059_99e8_3cfe9f40cf8f; Sat, 04 Nov 2017 09:11:34 -0500 Received: from DNVEXUSR1N08.corpzone.internalzone.com (10.44.48.81) by DNVEXAPP1N04.corpzone.internalzone.com (10.44.48.88) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Sat, 4 Nov 2017 08:11:33 -0600 Received: from DNVO365EDGE2.corpzone.internalzone.com (10.44.176.74) by DNVEXUSR1N08.corpzone.internalzone.com (10.44.48.81) with Microsoft SMTP Server (TLS) id 15.0.1347.2 via Frontend Transport; Sat, 4 Nov 2017 08:11:33 -0600 Received: from NAM02-SN1-obe.outbound.protection.outlook.com (10.44.176.243) by edge.mcafee.com (10.44.176.74) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Sat, 4 Nov 2017 08:11:32 -0600 Received: from DM5PR16MB1788.namprd16.prod.outlook.com (10.172.44.144) by DM5PR16MB1786.namprd16.prod.outlook.com (10.172.44.142) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.197.13; Sat, 4 Nov 2017 14:11:31 +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.20.0197.017; Sat, 4 Nov 2017 14:11:31 +0000 From: "Konda, Tirumaleswar Reddy" To: Jon Shallow , "dots@ietf.org" Thread-Topic: [Dots] Data channel issues with GET Thread-Index: AdNU60NzSK+9AEyfSlySy52mDm5lHgANmhBQAA4iMgAAAg7CgAAE0QTg Date: Sat, 4 Nov 2017 14:11:31 +0000 Message-ID: References: <06f601d354eb$482cce20$d8866a60$@jpshallow.com> <075801d3555a$34dbbd30$9e933790$@jpshallow.com> <077401d35562$7015a8e0$5040faa0$@jpshallow.com> In-Reply-To: <077401d35562$7015a8e0$5040faa0$@jpshallow.com> 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: [122.171.65.119] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DM5PR16MB1786; 6:/OSP/lv99wy3DZXhqRI7+jlspRKj3YBEKIzXZqq8ab1A3SgjWHwqhNEz+KuIQaGpHz6qqH2metYOCd36C5Lwlp1INsmS1cmyBZT9NXnBYE191f2YgxFoa925suDc+H+lgNyxjA8E/MazQO3oP7cCguON0QoWxe2BO78+xDSlQoPCs8i+W+NC4WMf7EcDzGVhNytZuZpOyf4iHSR4M+SaHaueVU0uh+/A8CP33uiNtYfT5CSDcU1xMCmfRT21vW0n5YVRKYeJuVNu5uhubQxzMQ82u8KF2eVA+ZkaMcbpyORJzfoEpkxslWDyLHO+Mne4Wl8oKac4COUVFdO51Td1hYHzAYqhqmC5BFeL6VSAmEM=; 5:PqSCZPACUSMpnjIZOuc/ji0iqgktKwhgx7FxgwcjQnOU111TH8ufVToIYT6+VwYrln1orrzGp9Djh+uuNrmpaBhy08ZY0zd2qwdy2LWTP13l4w3qQpfQEezVs9OhmzIU62A2FyqMkuR26jRohfZnmFyAjyLN+Ly54j37cSsLU3M=; 24:UPAMt4fiPRTf62Y9duoQN1of9Z+ChJiTKByd6S2n1HKyikYW1bpQeeAfzW3aA5X+XNkFazeNQaPyKWaYBpwQMOp1pIpgQlc0AOBf3rX71Lk=; 7:xUf+VEilSv6QpirPZLOhq1qqUkWWsjZTRH/TcQ9IPdwnRnzhWPBPTeQd3Ff91wuQd+nfM4kInfMSbFd4ncA0ETJ4OzNY8107zz9DBTjoNgQ5I31YGU0YSFYgdhh7Alz/4olpTVHmONY7GVAYBXmypZb+DCqoiF3DoOTrhzYAH6PYoP/vfDYz1/cKw2mmndVbql+4t7a3dkUaDRGFqSpbOfX0MYM46013+El/37Z6VprcwWEZXc/xmqWnwOxeoamw x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 3e89ff5a-82a4-403e-bfcd-08d5238df2d4 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(2017052603199); SRVR:DM5PR16MB1786; x-ms-traffictypediagnostic: DM5PR16MB1786: x-exchange-antispam-report-test: UriScan:(158342451672863)(21748063052155)(123452027830198); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(8121501046)(5005006)(10201501046)(93006095)(93001095)(3002001)(100000703101)(100105400095)(3231021)(6041248)(20161123558100)(20161123560025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123555025)(20161123562025)(20161123564025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:DM5PR16MB1786; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:DM5PR16MB1786; x-forefront-prvs: 048111149A x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(979002)(376002)(346002)(32952001)(189002)(199003)(51444003)(3660700001)(7736002)(5660300001)(97736004)(99286004)(81156014)(316002)(72206003)(74316002)(2950100002)(478600001)(3280700002)(8676002)(80792005)(14454004)(2900100001)(68736007)(8936002)(81166006)(7696004)(229853002)(93886005)(2906002)(66066001)(33656002)(6116002)(790700001)(102836003)(105586002)(3846002)(25786009)(19609705001)(53546010)(189998001)(77096006)(2501003)(54356999)(6506006)(50986999)(6436002)(106356001)(101416001)(236005)(86362001)(575784001)(76176999)(53946003)(6306002)(54896002)(9686003)(6246003)(55016002)(110136005)(53936002)(21314002)(85282002)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1101; SCL:1; SRVR:DM5PR16MB1786; H:DM5PR16MB1788.namprd16.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; 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_DM5PR16MB1788579E186E6516167E33DFEA520DM5PR16MB1788namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 3e89ff5a-82a4-403e-bfcd-08d5238df2d4 X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Nov 2017 14:11:31.2620 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4943e38c-6dd4-428c-886d-24932bc2d5de X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR16MB1786 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 <6151> : inlines <6156> : streams <1769324> : uri <2528041> Archived-At: Subject: Re: [Dots] Data channel issues with GET 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Nov 2017 14:11:50 -0000 --_000_DM5PR16MB1788579E186E6516167E33DFEA520DM5PR16MB1788namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable From: Jon Shallow [mailto:supjps-ietf@jpshallow.com] Sent: Saturday, November 4, 2017 5:16 PM To: Konda, Tirumaleswar Reddy ; dots@ie= tf.org Subject: RE: [Dots] Data channel issues with GET Actually, looking at RFC8040, the Figure 6 syntax should be " GET /restconf/data/ietf-dots-data-channel-identifier:identifier/\ client-identifier=3Ddz6pHjaADkaFTbjr0JGBpw,iAYmCNPmrYoKoqzgFMiobw?= \ content=3Dconfig HTTP/1.1 Host: {host}:{port} Accept: application/yang-data+json Figure 6: GET to retrieve all the installed identifiers" To represent the Figure 7 output. Correct? Yes, fixed. -Tiru Regards Jon From: Dots [mailto: dots-bounces@ietf.org] On= Behalf Of Jon Shallow Sent: 04 November 2017 10:47 To: 'Konda, Tirumaleswar Reddy'; dots@ietf.org Subject: Re: [Dots] Data channel issues with GET Hi Tiru, Agreed that a request from a DOTS client going through multiple DOTS gatewa= ys will get the appropriate client-identifier added, and the response initi= ally generated by the final DOTS server will have all the client-identifier= s. However, as the response passes back through the DOTS gateways, the appropr= iate client-identifier will get stripped off and the originating DOTS clien= t will have no visibility of the client-identifiers - as per " A DOTS gateway MUST update the 'client-identifier' list in the response to remove the 'client-identifier' value it had added in the corresponding request before forwarding the response to the DOTS client." So, Figure 6 and Figure 7 do not correctly portray the reality as seen by a= DOTS client (whether on a DOTS gateway or not). When the DOTS Gateway client component generates the GET request should the= request be (to match Figure 7 response) " GET /restconf/data/ietf-dots-data-channel-identifier:identifier?\ content=3Dconfig&client-identifier=3Ddz6pHjaADkaFTbjr0JGBpw,iAYmCN= PmrYoKoqzgFMiobw HTTP/1.1 Host: {host}:{port} Accept: application/yang-data+json Figure 6: GET to retrieve all the installed identifiers" =3D=3D=3D=3D=3D This still does not answer my implied concern - how does a DOTS gateway cli= ent request all the aliases / filters / mitigations to sync up state when, = say, the DOTS gateway client restarts? - The DOTS gateway may not know all the client-identifiers that are talking= to the server component of the DOTS gateway - they may be behind yet anoth= er DOTS gateway. Taking this more complex example involving multiple gateways (should it be = in the drafts somewhere for helping with client-identifier clarity?) DOTS client (C1aj) ----------------------------------------- (S1j) DOTS gat= eway J (C2j) ----------\ DOTS client (C1bj) --------------------------------------------/ = | = | DOTS client (C1ax) ------- (S1x) DOTS gateway X (C2x) ------ (S2k) DOTS gat= eway K (C3k) -------- (S3) DOTS client (C1bx) ----------/ | | DOTS client (C1ay) ------- (S1y) DOTS gateway Y (C2y) ---------/ DOTS client (C1by) ----------/ If C3k restarts how is he able to re-sync his information from S3? C3K doe= s not have a GET 'all' capability with client-identifier being above the le= vel of alias-name. It maybe that C3k does not need to re-sync, but C3k sho= uld have the flexibility if C3k is, say, able to cache information to reduc= e the number of requests having to pass all the way through to S3. As an aside, in my current implementation, where CIH(xxx) is the Client Ide= ntifier hash of xxx C1ax does a PUT (alias-name=3DServer1), C2x does a PUT (alias-name=3DServer1&client-identifer=3DCIH(C1ax)), C3k does a PUT (alias-name=3DServer1&client-identifer=3DCIH(C1ax),CIH(C2x)) and S3 uniquely stores this alias-name as (alias-name=3DServer1&client-iden= tifer=3DCIH(C1ax),CIH(C2x),CIH(C3k)) so that if any of the DOTS clients do a PUT (alias-name=3DServer1) [with sa= me alias name] S3 can differentiate them all. As CIH(C1ax) should be unique across all DOTS clients, do we really need to= add in all the other CIH() as the traffic passes up through to S3? Regards Jon From: Dots [mailto: dots-bounces@ietf.org] On= Behalf Of Konda, Tirumaleswar Reddy Sent: 04 November 2017 04:16 To: Jon Shallow; dots@ietf.org Subject: Re: [Dots] Data channel issues with GET Hi Jon, GET request will only retrieve the alias-names installed by a DOTS client a= nd not the alias-names for all the DOTS clients. The client-identifier arra= y is uniquely identifying the DOTS client and does not need be repeated for= every alias-name conveyed by the client. Figure 6 is showing the GET requ= est from the DOTS client, and the DOTS gateways will update the GET request= to add and update the client-identifier array. I don't think the client-identifier should be in the same level as alias-na= me. -Tiru From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Jon Shallow Sent: Saturday, November 4, 2017 3:03 AM To: dots@ietf.org Subject: [Dots] Data channel issues with GET Hi Tiru et al, I am having challenges coding up the GET for channel identifiers. A DOTS Client as part of a DOTS gateway can use different client-identifier= s when doing a PUT for the alias-name. The DOTS server will therefore hav= e multiple client-identifier arrays for the DOTS GW client. However when doing a GET using 'content=3Dconfig', as things currently stan= d, only one client-identifier array can returned as per the below in Figure= 7:- =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D "3.2.3. Retrieving Installed Identifiers A GET request is used to retrieve the set of installed identifiers from a DOTS server (Section 3.3.1 in [RFC8040]). Figure 6 shows how to retrieve all the identifiers that were instantiated by the DOTS client. The content parameter and its permitted values are defined in Section 4.8.1 of [RFC8040]. GET /restconf/data/ietf-dots-data-channel-identifier:identifier?\ content=3Dconfig HTTP/1.1 Host: {host}:{port} Accept: application/yang-data+json Figure 6: GET to retrieve all the installed identifiers Figure 7 shows response for all identifiers on the DOTS server. { "ietf-dots-data-channel-identifier:identifier": { "client-identifier": [ "dz6pHjaADkaFTbjr0JGBpw", "iAYmCNPmrYoKoqzgFMiobw" ], "alias": [ { "alias-name": "Server1", "traffic-protocol": [ 6" =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D I think that the yang model needs to be re-written, by moving leaf-list cli= ent-identifier down to the same level as alias-name as :- =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D container identifier { description "Top level container for identifiers"; list alias { key alias-name; description "List of identifiers"; leaf alias-name { type string; description "alias name"; } leaf-list client-identifier { type binary; description "A client identifier conveyed by a DOTS = gateway to a remote DOTS server."; reference "I-D.itef-dots-signal-channel"; } leaf-list target-ip { =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D And reflected appropriately throughout the data channel draft. The issue is the same for the access control list - client-identifier needs= to be at the same level as acl-name module: ietf-dots-access-control-list augment /ietf-acl:access-lists: +--rw client-identifier* binary =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Needs to be module: ietf-dots-access-control-list augment /ietf-acl:access-lists/ietf-acl:acl/: +--rw client-identifier* binary =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D And replicated as appropriate throughout the draft Regards Jon --_000_DM5PR16MB1788579E186E6516167E33DFEA520DM5PR16MB1788namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

From:<= /span> Jon Shallow [mailto:s= upjps-ietf@jpshallow.com]
Sent: Saturday, November 4, 2017 5:16 PM
To: Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@McAfee.com= >; dots@ietf.org
Subject: RE: [Dots] Data channel issues with GET

 

Actuall= y, looking at RFC8040, the Figure 6 syntax should be

&n= bsp;

“=     GET /restconf/data/ietf-dots-data-channel-identifier:ide= ntifier/\

 &= nbsp;       client-identifier=3Ddz6pHjaADkaFT= bjr0JGBpw,iAYmCNPmrYoKoqzgFMiobw?\

 &= nbsp;       content=3Dconfig HTTP/1.1

 &= nbsp;   Host: {host}:{port}

 &= nbsp;   Accept: application/yang-data+json<= /p>

&n= bsp;

 &= nbsp;        Figure 6: GET to retrieve a= ll the installed identifiers”

&n= bsp;

To repr= esent the Figure 7 output.

&n= bsp;

Correct= ?

 

Yes, fixed.

 

-Tiru

&n= bsp;

Regards=

&n= bsp;

Jon

&n= bsp;

From: Dots [mailto: = dots-bounces@ietf.org] On Behalf Of Jon Shallow
Sent: 04 November 2017 10:47
To: 'Konda, Tirumaleswar Reddy'; dots@ietf.org
Subject: Re: [Dots] Data channel issues with GET

 

Hi Tiru= ,

&n= bsp;

Agreed = that a request from a DOTS client going through multiple DOTS gateways will= get the appropriate client-identifier added, and the response initially ge= nerated by the final DOTS server will have all the client-identifiers.

&n= bsp;

However= , as the response passes back through the DOTS gateways, the appropriate cl= ient-identifier will get stripped off and the originating DOTS client will = have no visibility of the client-identifiers – as per

“=    A DOTS gateway MUST update the 'client-identifier' list in the=

 &= nbsp; response to remove the 'client-identifier' value it had added in the<= o:p>

 &= nbsp; corresponding request before forwarding the response to the DOTS=

 &= nbsp; client.”

&n= bsp;

So, Fig= ure 6 and Figure 7 do not correctly portray the reality as seen by a DOTS c= lient (whether on a DOTS gateway or not).

&n= bsp;

When th= e DOTS Gateway client component generates the GET request should the reques= t be (to match Figure 7 response)

&n= bsp;

“=     GET /restconf/data/ietf-dots-data-channel-identifier:ide= ntifier?\

 &= nbsp;       content=3Dconfig&client-ident= ifier=3Ddz6pHjaADkaFTbjr0JGBpw,iAYmCNPmrYoKoqzgFMiobw HTTP/1.1

 &= nbsp;   Host: {host}:{port}

 &= nbsp;   Accept: application/yang-data+json<= /p>

&n= bsp;

 &= nbsp;        Figure 6: GET to retrieve a= ll the installed identifiers”

&n= bsp;

=3D=3D= =3D=3D=3D

&n= bsp;

This st= ill does not answer my implied concern – how does a DOTS gateway clie= nt request all the aliases / filters / mitigations to sync up state when, s= ay, the DOTS gateway client restarts?

- The D= OTS gateway may not know all the client-identifiers that are talking to the= server component of the DOTS gateway – they may be behind yet anothe= r DOTS gateway.

&n= bsp;

Taking = this more complex example involving multiple gateways (should it be in the = drafts somewhere for helping with client-identifier clarity?)

&n= bsp;

DOTS client (C1aj) -----------= ------------------------------ (S1j) DOTS gateway J (C2j) ----------\ =  

DOTS client (C1bj) -----------= ---------------------------------/       = ;             &= nbsp;           &nbs= p; |

     =             &nb= sp;            =              &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;    |

DOTS client (C1ax) ------- (S1= x) DOTS gateway X (C2x) ------ (S2k) DOTS gateway K (C3k) -------- (S3)&nbs= p;  

DOTS client (C1bx) ----------/&nb= sp;            =              &n= bsp;      |     &nbs= p;            &= nbsp;            

     &nb= sp;            =             &nb= sp;            =             &nb= sp;       |     = ;            &n= bsp;            &nbs= p;  

DOTS client (C1ay) ------- (S1y) = DOTS gateway Y (C2y) ---------/       &n= bsp;            = ;             <= o:p>

DOTS client (C1by) ----------/&nb= sp;            =              &n= bsp;            = ;            &n= bsp;            = ;   

     &nb= sp;            =             &nb= sp;            =             &nb= sp;            =             &nb= sp;            =     

 = ;

If C3k = restarts how is he able to re-sync his information from S3?  C3K does = not have a GET ‘all’ capability with client-identifier being ab= ove the level of alias-name.  It maybe that C3k does not need to re-sync, but C3k should have the flexibility if C3k is, say, able = to cache information to reduce the number of requests having to pass all th= e way through to S3.

&n= bsp;

As an a= side, in my current implementation, where CIH(xxx) is the Client Identifier= hash of xxx

&n= bsp;

C1ax do= es a PUT (alias-name=3DServer1),

C2x doe= s a PUT (alias-name=3DServer1&client-identifer=3DCIH(C1ax)),=

C3k doe= s a PUT (alias-name=3DServer1&client-identifer=3DCIH(C1ax),CIH(C2x))

and S3 = uniquely stores this alias-name as (alias-name=3DServer1&client-identif= er=3DCIH(C1ax),CIH(C2x),CIH(C3k))

so that= if any of the DOTS clients do a PUT (alias-name=3DServer1) [with same alia= s name] S3 can differentiate them all.

&n= bsp;

As CIH(= C1ax) should be unique across all DOTS clients, do we really need to add in= all the other CIH() as the traffic passes up through to S3?

&n= bsp;

Regards=

&n= bsp;

Jon

&n= bsp;

From: Dots [mailto: = dots-bounces@ietf.org] On Behalf Of Konda, Tirumaleswar Reddy
Sent: 04 November 2017 04:16
To: Jon Shallow; dots@ietf.org
Subject: Re: [Dots] Data channel issues with GET

 

Hi Jon,

&nbs= p;

GET reque= st will only retrieve the alias-names installed by a DOTS client and not th= e alias-names for all the DOTS clients. The client-identifier array is uniq= uely identifying the DOTS client and does not need be repeated for every alias-name conveyed by the client. &nb= sp;Figure 6 is showing the GET request from the DOTS client, and the DOTS g= ateways will update the GET request to add and update the client-identifier= array.

I donR= 17;t think the client-identifier should be in the same level as alias-name.

&nbs= p;

-Tiru

&nbs= p;

From:<= /span> Dots [mailto:dots-bounces@ietf.org] On Behalf Of Jon Shallow
Sent: Saturday, November 4, 2017 3:03 AM
To: dots@ietf.org
Subject: [Dots] Data channel issues with GET

 

Hi Tiru et al,

 

I am having challenges coding u= p the GET for channel identifiers.

 

A DOTS Client as part of a DOTS= gateway can use different client-identifiers when doing a PUT for the alia= s-name.   The DOTS server will therefore have multiple client-ide= ntifier arrays for the DOTS GW client.

 

However when doing a GET using = ‘content=3Dconfig’, as things currently stand, only one client-= identifier array can returned as per the below in Figure 7:-

 

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<= /span>

 

“3.2.3.  Retrieving = Installed Identifiers

 

   A GET request is u= sed to retrieve the set of installed identifiers

   from a DOTS server= (Section 3.3.1 in [RFC8040]).  Figure 6 shows how

   to retrieve all th= e identifiers that were instantiated by the DOTS

   client.  The = content parameter and its permitted values are defined

   in Section 4.8.1 o= f [RFC8040].

 

     GET /r= estconf/data/ietf-dots-data-channel-identifier:identifier?\

     &= nbsp;   content=3Dconfig HTTP/1.1

     Host: = {host}:{port}

     Accept= : application/yang-data+json

 

     &= nbsp;    Figure 6: GET to retrieve all the installed identif= iers

 

   Figure 7 shows res= ponse for all identifiers on the DOTS server.

 

   {

    "ietf-dots= -data-channel-identifier:identifier": {

     &nbs= p; "client-identifier": [

     &nbs= p;    "dz6pHjaADkaFTbjr0JGBpw",<= /p>

     &nbs= p;    "iAYmCNPmrYoKoqzgFMiobw"

     &nbs= p; ],

     &nbs= p; "alias": [

     &nbs= p;   {

     &= nbsp;     "alias-name": "Server1",<= o:p>

     &= nbsp;     "traffic-protocol": [

     &= nbsp;       6”

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D

 

I think that the yang model nee= ds to be re-written, by moving leaf-list client-identifier down to the same= level as alias-name as :-

 

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D

     contai= ner identifier {

     &= nbsp;    description "Top level container for identifie= rs";

 

     &= nbsp;        list alias {

     &= nbsp;           &nbs= p; key alias-name;

     &= nbsp;            &nb= sp;description "List of identifiers";

 

     &= nbsp;           &nbs= p; leaf alias-name {

     &= nbsp;           &nbs= p;    type string;

     &= nbsp;           &nbs= p;    description "alias name";<= /p>

     &= nbsp;           &nbs= p; }

 

     &= nbsp;           &nbs= p; leaf-list client-identifier {

     &= nbsp;           &nbs= p;    type binary;

     &= nbsp;           &nbs= p;    description  "A client identifier conveyed b= y a DOTS gateway

     &= nbsp;           &nbs= p;            &= nbsp;     to a remote DOTS server.";

 

     &= nbsp;           &nbs= p;    reference

     &= nbsp;           &nbs= p;       "I-D.itef-dots-signal-channel&q= uot;;

     &= nbsp;           &nbs= p; }

 

     &= nbsp;           &nbs= p; leaf-list target-ip {

 

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D

 

And reflected appropriately thr= oughout the data channel draft.

 

The issue is the same for the a= ccess control list – client-identifier needs to be at the same level = as acl-name

 

module: ietf-dots-access-contro= l-list

  augment /ietf-acl:access= -lists:

    +--rw cl= ient-identifier*   binary

 

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D

Needs to be

 

module: ietf-dots-access-contro= l-list

  augment /ietf-acl:access= -lists/ietf-acl:acl/:

    +--rw cl= ient-identifier*   binary

 

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D

 

And replicated as appropriate t= hroughout the draft

 

Regards

 

Jon

--_000_DM5PR16MB1788579E186E6516167E33DFEA520DM5PR16MB1788namp_-- From nobody Sat Nov 4 07:25:52 2017 Return-Path: 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 7F1FC13FB26 for ; Sat, 4 Nov 2017 07:25:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 oepKnB1kK3kS for ; Sat, 4 Nov 2017 07:25:47 -0700 (PDT) Received: from mail.jpshallow.com (mail.jpshallow.com [217.40.240.153]) (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 1D75C13F6BC for ; Sat, 4 Nov 2017 07:25:47 -0700 (PDT) Received: from [127.0.0.1] (helo=N01332) by mail.jpshallow.com with smtps (TLSv1:ECDHE-RSA-AES256-SHA:256) (Exim 4.89) (envelope-from ) id 1eAzOL-0000Qf-Do; Sat, 04 Nov 2017 14:25:45 +0000 From: "Jon Shallow" To: "'Konda, Tirumaleswar Reddy'" , References: <06f601d354eb$482cce20$d8866a60$@jpshallow.com> <075801d3555a$34dbbd30$9e933790$@jpshallow.com> <077401d35562$7015a8e0$5040faa0$@jpshallow.com> In-Reply-To: Date: Sat, 4 Nov 2017 14:25:46 -0000 Message-ID: <079901d35578$ce0bc270$6a234750$@jpshallow.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_079A_01D35578.CE0F1DD0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQGq3C7tF9zj9qMEJcmaXbDvWUqFfQEpBvoXAuZQ++ICoXqf6wItmOrhow5DdIA= Content-Language: en-gb Archived-At: Subject: Re: [Dots] Data channel issues with GET 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Nov 2017 14:25:50 -0000 This is a multipart message in MIME format. ------=_NextPart_000_079A_01D35578.CE0F1DD0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Tiru, I still do not have an answer to my two other questions in my mail of 04 November 2017 10:47 One "This still does not answer my implied concern - how does a DOTS gateway client request all the aliases / filters / mitigations to sync up state when, say, the DOTS gateway client restarts? - The DOTS gateway may not know all the client-identifiers that are talking to the server component of the DOTS gateway - they may be behind yet another DOTS gateway." Comment: The DOTS server will have the requesting DOTS client (client in a DOTS gateway) identifier, so the DOTS server will filter on this, but is incapable of sending back different passed upstream client identifiers unless they are included in the GET request. Two As CIH(C1ax) should be unique across all DOTS clients, do we really need to add in all the other CIH() as the traffic passes up through to S3? ==== In addition, I am not convinced that the DELETE statement is correct as per RFC8040 - I think the & before alias-name should be a / which makes things interesting if there is no client-identifier to put in the path. DELETE /restconf/data/ietf-dots-data-channel-identifier:identifier\ /client-identifier=dz6pHjaADkaFTbjr0JGBpw,iAYmCNPmrYoKoqzgFMiobw&alias-name= Server1 HTTP/1.1 Host: {host}:{port} Figure 5: DELETE identifier From: Dots [mailto:ietf-supjps-dots-bounces@ietf.org] On Behalf Of Konda, Tirumaleswar Reddy Sent: 04 November 2017 14:12 To: Jon Shallow; dots@ietf.org Subject: Re: [Dots] Data channel issues with GET From: Jon Shallow [mailto:supjps-ietf@jpshallow.com] Sent: Saturday, November 4, 2017 5:16 PM To: Konda, Tirumaleswar Reddy ; dots@ietf.org Subject: RE: [Dots] Data channel issues with GET Actually, looking at RFC8040, the Figure 6 syntax should be " GET /restconf/data/ietf-dots-data-channel-identifier:identifier/\ client-identifier=dz6pHjaADkaFTbjr0JGBpw,iAYmCNPmrYoKoqzgFMiobw?\ content=config HTTP/1.1 Host: {host}:{port} Accept: application/yang-data+json Figure 6: GET to retrieve all the installed identifiers" To represent the Figure 7 output. Correct? Yes, fixed. -Tiru Regards Jon From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of Jon Shallow Sent: 04 November 2017 10:47 To: 'Konda, Tirumaleswar Reddy'; dots@ietf.org Subject: Re: [Dots] Data channel issues with GET Hi Tiru, Agreed that a request from a DOTS client going through multiple DOTS gateways will get the appropriate client-identifier added, and the response initially generated by the final DOTS server will have all the client-identifiers. However, as the response passes back through the DOTS gateways, the appropriate client-identifier will get stripped off and the originating DOTS client will have no visibility of the client-identifiers - as per " A DOTS gateway MUST update the 'client-identifier' list in the response to remove the 'client-identifier' value it had added in the corresponding request before forwarding the response to the DOTS client." So, Figure 6 and Figure 7 do not correctly portray the reality as seen by a DOTS client (whether on a DOTS gateway or not). When the DOTS Gateway client component generates the GET request should the request be (to match Figure 7 response) " GET /restconf/data/ietf-dots-data-channel-identifier:identifier?\ content=config&client-identifier=dz6pHjaADkaFTbjr0JGBpw,iAYmCNPmrYoKoqzgFMio bw HTTP/1.1 Host: {host}:{port} Accept: application/yang-data+json Figure 6: GET to retrieve all the installed identifiers" ===== This still does not answer my implied concern - how does a DOTS gateway client request all the aliases / filters / mitigations to sync up state when, say, the DOTS gateway client restarts? - The DOTS gateway may not know all the client-identifiers that are talking to the server component of the DOTS gateway - they may be behind yet another DOTS gateway. Taking this more complex example involving multiple gateways (should it be in the drafts somewhere for helping with client-identifier clarity?) DOTS client (C1aj) ----------------------------------------- (S1j) DOTS gateway J (C2j) ----------\ DOTS client (C1bj) --------------------------------------------/ | | DOTS client (C1ax) ------- (S1x) DOTS gateway X (C2x) ------ (S2k) DOTS gateway K (C3k) -------- (S3) DOTS client (C1bx) ----------/ | | DOTS client (C1ay) ------- (S1y) DOTS gateway Y (C2y) ---------/ DOTS client (C1by) ----------/ If C3k restarts how is he able to re-sync his information from S3? C3K does not have a GET 'all' capability with client-identifier being above the level of alias-name. It maybe that C3k does not need to re-sync, but C3k should have the flexibility if C3k is, say, able to cache information to reduce the number of requests having to pass all the way through to S3. As an aside, in my current implementation, where CIH(xxx) is the Client Identifier hash of xxx C1ax does a PUT (alias-name=Server1), C2x does a PUT (alias-name=Server1&client-identifer=CIH(C1ax)), C3k does a PUT (alias-name=Server1&client-identifer=CIH(C1ax),CIH(C2x)) and S3 uniquely stores this alias-name as (alias-name=Server1&client-identifer=CIH(C1ax),CIH(C2x),CIH(C3k)) so that if any of the DOTS clients do a PUT (alias-name=Server1) [with same alias name] S3 can differentiate them all. As CIH(C1ax) should be unique across all DOTS clients, do we really need to add in all the other CIH() as the traffic passes up through to S3? Regards Jon From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of Konda, Tirumaleswar Reddy Sent: 04 November 2017 04:16 To: Jon Shallow; dots@ietf.org Subject: Re: [Dots] Data channel issues with GET Hi Jon, GET request will only retrieve the alias-names installed by a DOTS client and not the alias-names for all the DOTS clients. The client-identifier array is uniquely identifying the DOTS client and does not need be repeated for every alias-name conveyed by the client. Figure 6 is showing the GET request from the DOTS client, and the DOTS gateways will update the GET request to add and update the client-identifier array. I don't think the client-identifier should be in the same level as alias-name. -Tiru From: Dots [ mailto:dots-bounces@ietf.org] On Behalf Of Jon Shallow Sent: Saturday, November 4, 2017 3:03 AM To: dots@ietf.org Subject: [Dots] Data channel issues with GET Hi Tiru et al, I am having challenges coding up the GET for channel identifiers. A DOTS Client as part of a DOTS gateway can use different client-identifiers when doing a PUT for the alias-name. The DOTS server will therefore have multiple client-identifier arrays for the DOTS GW client. However when doing a GET using 'content=config', as things currently stand, only one client-identifier array can returned as per the below in Figure 7:- =============================== "3.2.3. Retrieving Installed Identifiers A GET request is used to retrieve the set of installed identifiers from a DOTS server (Section 3.3.1 in [RFC8040]). Figure 6 shows how to retrieve all the identifiers that were instantiated by the DOTS client. The content parameter and its permitted values are defined in Section 4.8.1 of [RFC8040]. GET /restconf/data/ietf-dots-data-channel-identifier:identifier?\ content=config HTTP/1.1 Host: {host}:{port} Accept: application/yang-data+json Figure 6: GET to retrieve all the installed identifiers Figure 7 shows response for all identifiers on the DOTS server. { "ietf-dots-data-channel-identifier:identifier": { "client-identifier": [ "dz6pHjaADkaFTbjr0JGBpw", "iAYmCNPmrYoKoqzgFMiobw" ], "alias": [ { "alias-name": "Server1", "traffic-protocol": [ 6" =========== I think that the yang model needs to be re-written, by moving leaf-list client-identifier down to the same level as alias-name as :- =========== container identifier { description "Top level container for identifiers"; list alias { key alias-name; description "List of identifiers"; leaf alias-name { type string; description "alias name"; } leaf-list client-identifier { type binary; description "A client identifier conveyed by a DOTS gateway to a remote DOTS server."; reference "I-D.itef-dots-signal-channel"; } leaf-list target-ip { ================ And reflected appropriately throughout the data channel draft. The issue is the same for the access control list - client-identifier needs to be at the same level as acl-name module: ietf-dots-access-control-list augment /ietf-acl:access-lists: +--rw client-identifier* binary ============= Needs to be module: ietf-dots-access-control-list augment /ietf-acl:access-lists/ietf-acl:acl/: +--rw client-identifier* binary =============== And replicated as appropriate throughout the draft Regards Jon ------=_NextPart_000_079A_01D35578.CE0F1DD0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Tiru,

 

I still do not have an = answer to my two other questions in my mail of 04 November 2017 10:47

 

One

 

“This still = does not answer my implied concern – how does a DOTS gateway = client request all the aliases / filters / mitigations to sync up state = when, say, the DOTS gateway client restarts?

- The DOTS gateway may = not know all the client-identifiers that are talking to the server = component of the DOTS gateway – they may be behind yet another = DOTS gateway.”

 

Comment: The DOTS server = will have the requesting DOTS client (client in a DOTS gateway) = identifier, so the DOTS server will filter on this, but is incapable of = sending back different passed upstream client identifiers unless they = are included in the GET request.

 

Two

 

As CIH(C1ax) should be unique across all DOTS = clients, do we really need to add in all the other CIH() as the traffic = passes up through to S3?

 

=3D=3D=3D=3D

In addition, I am not = convinced that the DELETE statement is correct as per RFC8040 – I = think the & before alias-name should be a / which makes things = interesting if there is no client-identifier to put in the = path.

 

  DELETE = /restconf/data/ietf-dots-data-channel-identifier:identifier\

         = /client-identifier=3Ddz6pHjaADkaFTbjr0JGBpw,iAYmCNPmrYoKoqzgFMiobw= &alias-name=3DServer1 = HTTP/1.1

  Host: = {host}:{port}

 

        &= nbsp;           &n= bsp;   Figure 5: DELETE identifier

 

From: Dots [mailto:ietf-supjps-dots-bounces@ietf.org] On = Behalf Of Konda, Tirumaleswar Reddy
Sent: 04 November 2017 = 14:12
To: Jon Shallow; dots@ietf.org
Subject: Re: = [Dots] Data channel issues with GET

 

From: Jon Shallow [mailto:supjps-ietf@jpshallow.co= m]
Sent: Saturday, November 4, 2017 5:16 PM
To: = Konda, Tirumaleswar Reddy <TirumaleswarReddy_Kond= a@McAfee.com>; dots@ietf.org
Subject: RE: = [Dots] Data channel issues with GET

 

Actually, looking at = RFC8040, the Figure 6 syntax should be

 

“    GET = /restconf/data/ietf-dots-data-channel-identifier:identifier/\<= /span>

         = client-identifier=3Ddz6pHjaADkaFTbjr0JGBpw,iAYmCNPmrYoKoqzgFMiobw?\<= /o:p>

         = content=3Dconfig HTTP/1.1

     = Host: {host}:{port}

     Accept: = application/yang-data+json

 

        &= nbsp; Figure 6: GET to retrieve all the installed = identifiers”

 

To represent the Figure = 7 output.

 

Correct?

 

Yes, = fixed.

 

-Tiru

 

Regards

 

Jon

 

From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of Jon Shallow
Sent: 04 = November 2017 10:47
To: 'Konda, Tirumaleswar Reddy'; = dots@ietf.org
Subject: Re: [Dots] Data channel issues with = GET

 

Hi Tiru,

 

Agreed that a request = from a DOTS client going through multiple DOTS gateways will get the = appropriate client-identifier added, and the response initially = generated by the final DOTS server will have all the = client-identifiers.

 

However, as the response = passes back through the DOTS gateways, the appropriate client-identifier = will get stripped off and the originating DOTS client will have no = visibility of the client-identifiers – as = per

“   A DOTS gateway MUST update = the 'client-identifier' list in the

   response to = remove the 'client-identifier' value it had added in = the

   corresponding request before = forwarding the response to the DOTS

   = client.”

 

So, Figure 6 and Figure = 7 do not correctly portray the reality as seen by a DOTS client (whether = on a DOTS gateway or not).

 

When the DOTS Gateway = client component generates the GET request should the request be (to = match Figure 7 response)

 

“    GET = /restconf/data/ietf-dots-data-channel-identifier:identifier?\<= /span>

         = content=3Dconfig&client-identifier=3Ddz6pHjaADkaFTbjr0JGBpw,iAYmCNPmr= YoKoqzgFMiobw HTTP/1.1

     Host: = {host}:{port}

     Accept: = application/yang-data+json

 

        &= nbsp; Figure 6: GET to retrieve all the installed = identifiers”

 

=3D=3D=3D=3D=3D

 

This still does not = answer my implied concern – how does a DOTS gateway client request = all the aliases / filters / mitigations to sync up state when, say, the = DOTS gateway client restarts?

- The DOTS gateway may = not know all the client-identifiers that are talking to the server = component of the DOTS gateway – they may be behind yet another = DOTS gateway.

 

Taking this more complex = example involving multiple gateways (should it be in the drafts = somewhere for helping with client-identifier = clarity?)

 

DOTS client (C1aj) = ----------------------------------------- (S1j) DOTS gateway J (C2j) = ----------\  

DOTS = client (C1bj) = --------------------------------------------/    &nbs= p;            = ;  =             &= nbsp;  |

         = ;            =             &= nbsp;    =             &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;           |

DOTS = client (C1ax) ------- (S1x) DOTS gateway X (C2x) ------ (S2k) DOTS = gateway K (C3k) -------- (S3)   

DOTS = client (C1bx) = ----------/          &n= bsp;           &nb= sp;   =        |     =             &= nbsp;          =    

         = ;            =             &= nbsp;           &n= bsp;           &nb= sp;     |      &nb= sp;           &nbs= p;         =      

DOTS = client (C1ay) ------- (S1y) DOTS gateway Y (C2y) = ---------/          &nb= sp;           &nbs= p;    =       

DOTS = client (C1by) = ----------/          &n= bsp;           &nb= sp;   =             &= nbsp;           &n= bsp;           &nb= sp;    

         = ;            =             &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;            = ;            =    

 

If C3k restarts how is = he able to re-sync his information from S3?  C3K does not have a = GET ‘all’ capability with client-identifier being above the = level of alias-name.  It maybe that C3k does not need to re-sync, = but C3k should have the flexibility if C3k is, say, able to cache = information to reduce the number of requests having to pass all the way = through to S3.

 

As an aside, in my = current implementation, where CIH(xxx) is the Client Identifier hash of = xxx

 

C1ax does a PUT = (alias-name=3DServer1),

C2x does a PUT = (alias-name=3DServer1&client-identifer=3DCIH(C1ax)),

C3k does a PUT = (alias-name=3DServer1&client-identifer=3DCIH(C1ax),CIH(C2x))

and S3 = uniquely stores this alias-name as = (alias-name=3DServer1&client-identifer=3DCIH(C1ax),CIH(C2x),CIH(C3k))=

so that if any of the DOTS clients do a PUT = (alias-name=3DServer1) [with same alias name] S3 can differentiate them = all.

 

As CIH(C1ax) should be = unique across all DOTS clients, do we really need to add in all the = other CIH() as the traffic passes up through to = S3?

 

Regards

 

Jon

 

From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of Konda, Tirumaleswar = Reddy
Sent: 04 November 2017 04:16
To: Jon Shallow; = dots@ietf.org
Subject: Re: [Dots] Data channel issues with = GET

 

Hi = Jon,

 

GET request will only retrieve the = alias-names installed by a DOTS client and not the alias-names for all = the DOTS clients. The client-identifier array is uniquely identifying = the DOTS client and does not need be repeated for every alias-name = conveyed by the client.  Figure 6 is showing the GET request from = the DOTS client, and the DOTS gateways will update the GET request to = add and update the client-identifier array.

I don’t think the = client-identifier should be in the same level as alias-name. =

 

-Tiru

 

 

Hi Tiru et al,

 

I am having = challenges coding up the GET for channel identifiers.

 

A DOTS = Client as part of a DOTS gateway can use different client-identifiers = when doing a PUT for the alias-name.   The DOTS server will = therefore have multiple client-identifier arrays for the DOTS GW = client.

 

However when doing a GET using = ‘content=3Dconfig’, as things currently stand, only one = client-identifier array can returned as per the below in Figure = 7:-

 

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

 

“3.2.3.  Retrieving Installed = Identifiers

 

   A GET request is used to retrieve the set = of installed identifiers

   = from a DOTS server (Section 3.3.1 in [RFC8040]).  Figure 6 shows = how

   to retrieve all the = identifiers that were instantiated by the DOTS

   client.  The content parameter and = its permitted values are defined

   in Section 4.8.1 of = [RFC8040].

 

     GET = /restconf/data/ietf-dots-data-channel-identifier:identifier?\<= /p>

         = content=3Dconfig HTTP/1.1

     Host: = {host}:{port}

     Accept: = application/yang-data+json

 

          = Figure 6: GET to retrieve all the installed identifiers

 

   = Figure 7 shows response for all identifiers on the DOTS = server.

 

   {

    = "ietf-dots-data-channel-identifier:identifier": = {

       = "client-identifier": [

          = "dz6pHjaADkaFTbjr0JGBpw",

          = "iAYmCNPmrYoKoqzgFMiobw"

       = ],

       "alias": = [

         = {

         &= nbsp; "alias-name": "Server1",

         &= nbsp; "traffic-protocol": [

         &= nbsp;   6”

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

 

I think that = the yang model needs to be re-written, by moving leaf-list = client-identifier down to the same level as alias-name as = :-

 

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

     container identifier = {

          = description "Top level container for = identifiers";

 

         &= nbsp;    list alias {

         &= nbsp;         key = alias-name;

          =          description = "List of identifiers";

 

         &= nbsp;         leaf alias-name = {

         &= nbsp;            = type string;

         &= nbsp;            = description "alias name";

         &= nbsp;         }

 

         &= nbsp;         leaf-list = client-identifier {

         &= nbsp;            = type binary;

         &= nbsp;            = description  "A client identifier conveyed by a DOTS = gateway

         &= nbsp;           &n= bsp;           &nb= sp;  to a remote DOTS server.";

 

         &= nbsp;            = reference

         &= nbsp;           &n= bsp;   = "I-D.itef-dots-signal-channel";

         &= nbsp;         }

 

         &= nbsp;         leaf-list = target-ip {

 

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

 

And reflected appropriately throughout the data = channel draft.

 

The issue is = the same for the access control list – client-identifier needs to = be at the same level as acl-name

 

module: = ietf-dots-access-control-list

  = augment /ietf-acl:access-lists:

    +--rw = client-identifier*   binary

 

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

<= p class=3DMsoNormal>Needs to be

 

module: = ietf-dots-access-control-list

  = augment /ietf-acl:access-lists/ietf-acl:acl/:

    +--rw = client-identifier*   binary

 

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

 

And = replicated as appropriate throughout the draft

 

Regards

 

Jon

------=_NextPart_000_079A_01D35578.CE0F1DD0-- From nobody Sat Nov 4 07:28:50 2017 Return-Path: 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 4967A13FB87 for ; Sat, 4 Nov 2017 07:28:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7 X-Spam-Level: X-Spam-Status: No, score=-7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham 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 1KcOBCXAedbF for ; Sat, 4 Nov 2017 07:28:46 -0700 (PDT) Received: from MIVWSMAILOUT1.mcafee.com (mivwsmailout1.mcafee.com [161.69.47.167]) (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 0279613F6BC for ; Sat, 4 Nov 2017 07:28:45 -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=1509805724; 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: x-originating-ip:x-ms-publictraffictype:x-microsoft-exchange-diagnostics: x-ms-exchange-antispam-srfa-diagnostics:x-ms-office365-filtering-correlation-id: x-microsoft-antispam:x-ms-traffictypediagnostic: x-exchange-antispam-report-test:x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test:x-forefront-prvs: x-forefront-antispam-report:received-spf:authentication-results: spamdiagnosticoutput:spamdiagnosticmetadata: Content-Type: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-Transport-CrossTenantHeadersStamped: X-OriginatorOrg:X-NAI-Spam-Flag:X-NAI-Spam-Threshold: X-NAI-Spam-Score:X-NAI-Spam-Version; bh=C FNVE01Fyor1Q8JD1zK5GctZBfsHC000sEh/laXcex o=; b=NtdX1jQcmi234zvQr2g6Dm4SXxg5JLxQnRea+OMNGXJL Eco77XprUTWEtMBmDS36kjf7PEPHHbKi+n1+gjz7Dny6A6+M4X oVCOtseJSFf/6a+uJsx6NuJ8d4tUg8/Gzv6zhZH29Ejk9/wHkA z1012OMq7UDxoxOot+XP/bR/ix8= Received: from MIVEXAPP1N01.corpzone.internalzone.com (unknown [10.48.48.88]) by MIVWSMAILOUT1.mcafee.com with smtp id 6464_4e0f_40d4ba98_8355_49f5_af62_87fd7afb1a15; Sat, 04 Nov 2017 09:28:43 -0500 Received: from MIVEXUSR1N02.corpzone.internalzone.com (10.48.48.82) by MIVEXAPP1N01.corpzone.internalzone.com (10.48.48.88) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Sat, 4 Nov 2017 10:28:43 -0400 Received: from MIVEXUSR1N05.corpzone.internalzone.com (10.48.48.85) by MIVEXUSR1N02.corpzone.internalzone.com (10.48.48.82) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Sat, 4 Nov 2017 10:28:42 -0400 Received: from MIVO365EDGE4.corpzone.internalzone.com (10.48.176.87) by MIVEXUSR1N05.corpzone.internalzone.com (10.48.48.85) with Microsoft SMTP Server (TLS) id 15.0.1347.2 via Frontend Transport; Sat, 4 Nov 2017 10:28:35 -0400 Received: from NAM02-BL2-obe.outbound.protection.outlook.com (10.48.176.243) by edge.mcafee.com (10.48.176.87) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Sat, 4 Nov 2017 10:28:34 -0400 Received: from DM5PR16MB1788.namprd16.prod.outlook.com (10.172.44.144) by DM5PR16MB1788.namprd16.prod.outlook.com (10.172.44.144) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.197.13; Sat, 4 Nov 2017 14:28:33 +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.20.0197.017; Sat, 4 Nov 2017 14:28:33 +0000 From: "Konda, Tirumaleswar Reddy" To: Jon Shallow , "dots@ietf.org" Thread-Topic: [Dots] Data channel issues with GET Thread-Index: AdNU60NzSK+9AEyfSlySy52mDm5lHgANmhBQAA4iMgAABuS8gA== Date: Sat, 4 Nov 2017 14:28:33 +0000 Message-ID: References: <06f601d354eb$482cce20$d8866a60$@jpshallow.com> <075801d3555a$34dbbd30$9e933790$@jpshallow.com> In-Reply-To: <075801d3555a$34dbbd30$9e933790$@jpshallow.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [122.171.65.119] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DM5PR16MB1788; 6:TSWH7v3EzM1IkvEk7Wl6+O4y59Ej9aSZEyt8anb/5s5uTJaXUQN2Vdmd+aURkOVzP+2wZW9WWUcZxpRwIEuy6bdueOXLsCTZ8KyMa8hmy0wAP5dC5htT2hQ+XJFMAp1Yk7X95iZJiQkTCkMNlSrYWM7Q55/mA4g5Eydgc+SsrFnYLAiqi63JF/Ozbr8Taw6T+zu05wXGZ+bdvWyMF3cxXy9TLCvW0lp8YcTi8+9znK9CPcyACUbe+mSDA+Vt+OxHa9mu4mj5Eg8qYt853LD6k7xeSbRfZB81J5f9T6DL8ThoxsooL6pJte+9sfEqeDveFpnc4p9gYiL38xeIra3SDVcaEsowvR4JETn8Q5jgwjQ=; 5:EtKrxY0GS55o2V09A0ZfAFPdy/Mx+VQUY2aPCxRMmU4zEByhRsaEYoHd5SMWjHzWtpooRlKd+CrZmZncpIUnkpgTMQFRq1d6QB366N08FT/uMCLfSdNY/2G7ChvpRuxBW4ElEDY70XZQrnb0F1avZ64Xs/llBS//oe/o2LLkMEo=; 24:3iBs4dLilcpxbsXec9EgRT/Wbb+GiChx5Ofj9qt3bx42TZ5A0o+czGAsxjt6UBdnk1PQ6GGWslqCj1zPLGiXcJJzYal0OVpdqo52bwtN/QI=; 7:le/WwEEUvGOcLk8UXNgSY4fTkBMUpNDRghMpk8wxDuW/aZimyxZoRcnCr5QLktrGQ498bB94AUVLtkmuHkcoVcHJDz6U5JVhmcZtQFmC8FVGB+BfVlduwHu6BS9oUcJRTfnrhiNjFegg5spSMor1nEflqY39EdrdqLHyuHlI2SwptMhjFWCtbH4yYwCPmzGer+O+R32CPKc1K/OvsyCFoxGM0CX0ys/z0KMl0iwjXvjNJJ8H7VHbiIorm2C3BgEW x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 3a0ee004-e0a8-471d-bc21-08d523905423 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(2017052603249); SRVR:DM5PR16MB1788; x-ms-traffictypediagnostic: DM5PR16MB1788: x-exchange-antispam-report-test: UriScan:(158342451672863)(21748063052155)(123452027830198); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(8121501046)(5005006)(10201501046)(3231021)(100000703101)(100105400095)(3002001)(93006095)(93001095)(6041248)(20161123558100)(20161123564025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123562025)(20161123555025)(20161123560025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:DM5PR16MB1788; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:DM5PR16MB1788; x-forefront-prvs: 048111149A x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(376002)(346002)(199003)(51444003)(189002)(32952001)(105586002)(8936002)(106356001)(55016002)(189998001)(33656002)(81166006)(68736007)(53546010)(101416001)(80792005)(9326002)(81156014)(236005)(2900100001)(97736004)(77096006)(19609705001)(606006)(53936002)(6506006)(14454004)(8676002)(6436002)(2501003)(76176999)(229853002)(966005)(7696004)(99286004)(25786009)(575784001)(86362001)(316002)(74316002)(2950100002)(7736002)(5660300001)(50986999)(478600001)(66066001)(9686003)(3660700001)(2906002)(6246003)(54356999)(54896002)(72206003)(6116002)(790700001)(102836003)(3280700002)(3846002)(6306002)(110136005)(21314002)(85282002); DIR:OUT; SFP:1101; SCL:1; SRVR:DM5PR16MB1788; H:DM5PR16MB1788.namprd16.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: McAfee.com does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=TirumaleswarReddy_Konda@McAfee.com; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_DM5PR16MB1788B62D9BA630B9B0153019EA520DM5PR16MB1788namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 3a0ee004-e0a8-471d-bc21-08d523905423 X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Nov 2017 14:28:33.4652 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4943e38c-6dd4-428c-886d-24932bc2d5de X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR16MB1788 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 <6151> : inlines <6156> : streams <1769326> : uri <2528047> Archived-At: Subject: Re: [Dots] Data channel issues with GET 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Nov 2017 14:28:49 -0000 --_000_DM5PR16MB1788B62D9BA630B9B0153019EA520DM5PR16MB1788namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Jon, The DOTS gateway (C3k) does not send any requests on its own to the DOTS se= rver (S3). As per the discussion of DOTS gateways in https://tools.ietf.or= g/html/draft-ietf-dots-architecture-05, it's only relaying the messages fro= m the downstream and upstream agents. The DOTS architecture does not discus= s DOTS gateway acting as a caching server. CIH(C1ax) would only be unique across all the DOTS clients communicating wi= th the DOTS gateway X but may not be globally unique (across Gateways J and= K), the current approach would ensure no probability of client-identifier = collisions. -Tiru From: Jon Shallow [mailto:supjps-ietf@jpshallow.com] Sent: Saturday, November 4, 2017 4:17 PM To: Konda, Tirumaleswar Reddy ; dots@ie= tf.org Subject: RE: [Dots] Data channel issues with GET Hi Tiru, Agreed that a request from a DOTS client going through multiple DOTS gatewa= ys will get the appropriate client-identifier added, and the response initi= ally generated by the final DOTS server will have all the client-identifier= s. However, as the response passes back through the DOTS gateways, the appropr= iate client-identifier will get stripped off and the originating DOTS clien= t will have no visibility of the client-identifiers - as per " A DOTS gateway MUST update the 'client-identifier' list in the response to remove the 'client-identifier' value it had added in the corresponding request before forwarding the response to the DOTS client." So, Figure 6 and Figure 7 do not correctly portray the reality as seen by a= DOTS client (whether on a DOTS gateway or not). When the DOTS Gateway client component generates the GET request should the= request be (to match Figure 7 response) " GET /restconf/data/ietf-dots-data-channel-identifier:identifier?\ content=3Dconfig&client-identifier=3Ddz6pHjaADkaFTbjr0JGBpw,iAYmCN= PmrYoKoqzgFMiobw HTTP/1.1 Host: {host}:{port} Accept: application/yang-data+json Figure 6: GET to retrieve all the installed identifiers" =3D=3D=3D=3D=3D This still does not answer my implied concern - how does a DOTS gateway cli= ent request all the aliases / filters / mitigations to sync up state when, = say, the DOTS gateway client restarts? - The DOTS gateway may not know all the client-identifiers that are talking= to the server component of the DOTS gateway - they may be behind yet anoth= er DOTS gateway. Taking this more complex example involving multiple gateways (should it be = in the drafts somewhere for helping with client-identifier clarity?) DOTS client (C1aj) ----------------------------------------- (S1j) DOTS gat= eway J (C2j) ----------\ DOTS client (C1bj) --------------------------------------------/ = | = | DOTS client (C1ax) ------- (S1x) DOTS gateway X (C2x) ------ (S2k) DOTS gat= eway K (C3k) -------- (S3) DOTS client (C1bx) ----------/ | | DOTS client (C1ay) ------- (S1y) DOTS gateway Y (C2y) ---------/ DOTS client (C1by) ----------/ If C3k restarts how is he able to re-sync his information from S3? C3K doe= s not have a GET 'all' capability with client-identifier being above the le= vel of alias-name. It maybe that C3k does not need to re-sync, but C3k sho= uld have the flexibility if C3k is, say, able to cache information to reduc= e the number of requests having to pass all the way through to S3. As an aside, in my current implementation, where CIH(xxx) is the Client Ide= ntifier hash of xxx C1ax does a PUT (alias-name=3DServer1), C2x does a PUT (alias-name=3DServer1&client-identifer=3DCIH(C1ax)), C3k does a PUT (alias-name=3DServer1&client-identifer=3DCIH(C1ax),CIH(C2x)) and S3 uniquely stores this alias-name as (alias-name=3DServer1&client-iden= tifer=3DCIH(C1ax),CIH(C2x),CIH(C3k)) so that if any of the DOTS clients do a PUT (alias-name=3DServer1) [with sa= me alias name] S3 can differentiate them all. As CIH(C1ax) should be unique across all DOTS clients, do we really need to= add in all the other CIH() as the traffic passes up through to S3? Regards Jon From: Dots [mailto: dots-bounces@ietf.org] On= Behalf Of Konda, Tirumaleswar Reddy Sent: 04 November 2017 04:16 To: Jon Shallow; dots@ietf.org Subject: Re: [Dots] Data channel issues with GET Hi Jon, GET request will only retrieve the alias-names installed by a DOTS client a= nd not the alias-names for all the DOTS clients. The client-identifier arra= y is uniquely identifying the DOTS client and does not need be repeated for= every alias-name conveyed by the client. Figure 6 is showing the GET requ= est from the DOTS client, and the DOTS gateways will update the GET request= to add and update the client-identifier array. I don't think the client-identifier should be in the same level as alias-na= me. -Tiru From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Jon Shallow Sent: Saturday, November 4, 2017 3:03 AM To: dots@ietf.org Subject: [Dots] Data channel issues with GET Hi Tiru et al, I am having challenges coding up the GET for channel identifiers. A DOTS Client as part of a DOTS gateway can use different client-identifier= s when doing a PUT for the alias-name. The DOTS server will therefore hav= e multiple client-identifier arrays for the DOTS GW client. However when doing a GET using 'content=3Dconfig', as things currently stan= d, only one client-identifier array can returned as per the below in Figure= 7:- =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D "3.2.3. Retrieving Installed Identifiers A GET request is used to retrieve the set of installed identifiers from a DOTS server (Section 3.3.1 in [RFC8040]). Figure 6 shows how to retrieve all the identifiers that were instantiated by the DOTS client. The content parameter and its permitted values are defined in Section 4.8.1 of [RFC8040]. GET /restconf/data/ietf-dots-data-channel-identifier:identifier?\ content=3Dconfig HTTP/1.1 Host: {host}:{port} Accept: application/yang-data+json Figure 6: GET to retrieve all the installed identifiers Figure 7 shows response for all identifiers on the DOTS server. { "ietf-dots-data-channel-identifier:identifier": { "client-identifier": [ "dz6pHjaADkaFTbjr0JGBpw", "iAYmCNPmrYoKoqzgFMiobw" ], "alias": [ { "alias-name": "Server1", "traffic-protocol": [ 6" =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D I think that the yang model needs to be re-written, by moving leaf-list cli= ent-identifier down to the same level as alias-name as :- =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D container identifier { description "Top level container for identifiers"; list alias { key alias-name; description "List of identifiers"; leaf alias-name { type string; description "alias name"; } leaf-list client-identifier { type binary; description "A client identifier conveyed by a DOTS = gateway to a remote DOTS server."; reference "I-D.itef-dots-signal-channel"; } leaf-list target-ip { =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D And reflected appropriately throughout the data channel draft. The issue is the same for the access control list - client-identifier needs= to be at the same level as acl-name module: ietf-dots-access-control-list augment /ietf-acl:access-lists: +--rw client-identifier* binary =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Needs to be module: ietf-dots-access-control-list augment /ietf-acl:access-lists/ietf-acl:acl/: +--rw client-identifier* binary =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D And replicated as appropriate throughout the draft Regards Jon --_000_DM5PR16MB1788B62D9BA630B9B0153019EA520DM5PR16MB1788namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Jon,

&nbs= p;

The DOTS = gateway (C3k) does not send any requests on its own to the DOTS server (S3)= .  As per the discussion of DOTS gateways in htt= ps://tools.ietf.org/html/draft-ietf-dots-architecture-05, it’s on= ly relaying the messages from the downstream and upstream agents. The DOTS = architecture does not discuss DOTS gateway acting as a caching server.

 

CIH(C1a= x) would only be unique across all the DOTS clients communicating with the = DOTS gateway X but may not be globally unique (across Gateways J and K), th= e current approach would ensure no probability of client-identifier collisions.

&n= bsp;

-Tiru

 

From:<= /span> Jon Shallow [mailto:s= upjps-ietf@jpshallow.com]
Sent: Saturday, November 4, 2017 4:17 PM
To: Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@McAfee.com= >; dots@ietf.org
Subject: RE: [Dots] Data channel issues with GET

 

Hi Tiru= ,

&n= bsp;

Agreed = that a request from a DOTS client going through multiple DOTS gateways will= get the appropriate client-identifier added, and the response initially ge= nerated by the final DOTS server will have all the client-identifiers.

&n= bsp;

However= , as the response passes back through the DOTS gateways, the appropriate cl= ient-identifier will get stripped off and the originating DOTS client will = have no visibility of the client-identifiers – as per

“=    A DOTS gateway MUST update the 'client-identifier' list in the=

 &= nbsp; response to remove the 'client-identifier' value it had added in the<= o:p>

 &= nbsp; corresponding request before forwarding the response to the DOTS=

 &= nbsp; client.”

&n= bsp;

So, Fig= ure 6 and Figure 7 do not correctly portray the reality as seen by a DOTS c= lient (whether on a DOTS gateway or not).

&n= bsp;

When th= e DOTS Gateway client component generates the GET request should the reques= t be (to match Figure 7 response)

&n= bsp;

“=     GET /restconf/data/ietf-dots-data-channel-identifier:ide= ntifier?\

 &= nbsp;       content=3Dconfig&client-ident= ifier=3Ddz6pHjaADkaFTbjr0JGBpw,iAYmCNPmrYoKoqzgFMiobw HTTP/1.1

 &= nbsp;   Host: {host}:{port}

 &= nbsp;   Accept: application/yang-data+json<= /p>

&n= bsp;

 &= nbsp;        Figure 6: GET to retrieve a= ll the installed identifiers”

&n= bsp;

=3D=3D= =3D=3D=3D

&n= bsp;

This st= ill does not answer my implied concern – how does a DOTS gateway clie= nt request all the aliases / filters / mitigations to sync up state when, s= ay, the DOTS gateway client restarts?

- The D= OTS gateway may not know all the client-identifiers that are talking to the= server component of the DOTS gateway – they may be behind yet anothe= r DOTS gateway.

&n= bsp;

Taking = this more complex example involving multiple gateways (should it be in the = drafts somewhere for helping with client-identifier clarity?)

&n= bsp;

DOTS client (C1aj) -----------= ------------------------------ (S1j) DOTS gateway J (C2j) ----------\ =  

DOTS client (C1bj) -----------= ---------------------------------/       = ;             &= nbsp;           &nbs= p; |

     =             &nb= sp;            =              &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;    |

DOTS client (C1ax) ------- (S1= x) DOTS gateway X (C2x) ------ (S2k) DOTS gateway K (C3k) -------- (S3)&nbs= p;  

DOTS client (C1bx) ----------/=             &nb= sp;            =        |     &= nbsp;           &nbs= p;             =

     =             &nb= sp;            =             &nb= sp;            =         |    &n= bsp;            = ;             &= nbsp;  

DOTS client (C1ay) ------- (S1= y) DOTS gateway Y (C2y) ---------/       = ;            &n= bsp;            &nbs= p;

DOTS client (C1by) ----------/=             &nb= sp;            =             &n= bsp;            = ;            &n= bsp;   

     =             &nb= sp;            =             &nb= sp;            =             &nb= sp;            =             &nb= sp;    

&n= bsp;

If C3k = restarts how is he able to re-sync his information from S3?  C3K does = not have a GET ‘all’ capability with client-identifier being ab= ove the level of alias-name.  It maybe that C3k does not need to re-sync, but C3k should have the flexibility if C3k is, say, able = to cache information to reduce the number of requests having to pass all th= e way through to S3.

&n= bsp;

As an a= side, in my current implementation, where CIH(xxx) is the Client Identifier= hash of xxx

&n= bsp;

C1ax do= es a PUT (alias-name=3DServer1),

C2x doe= s a PUT (alias-name=3DServer1&client-identifer=3DCIH(C1ax)),=

C3k doe= s a PUT (alias-name=3DServer1&client-identifer=3DCIH(C1ax),CIH(C2x))

and S3 = uniquely stores this alias-name as (alias-name=3DServer1&client-identif= er=3DCIH(C1ax),CIH(C2x),CIH(C3k))

so that= if any of the DOTS clients do a PUT (alias-name=3DServer1) [with same alia= s name] S3 can differentiate them all.

&n= bsp;

As CIH(= C1ax) should be unique across all DOTS clients, do we really need to add in= all the other CIH() as the traffic passes up through to S3?

&n= bsp;

Regards=

&n= bsp;

Jon

&n= bsp;

From: Dots [mailto: dots-bounces@ietf.org] On B= ehalf Of Konda, Tirumaleswar Reddy
Sent: 04 November 2017 04:16
To: Jon Shallow; dots@ietf.org<= br> Subject: Re: [Dots] Data channel issues with GET

 

Hi Jon,

&nbs= p;

GET reque= st will only retrieve the alias-names installed by a DOTS client and not th= e alias-names for all the DOTS clients. The client-identifier array is uniq= uely identifying the DOTS client and does not need be repeated for every alias-name conveyed by the client. &nb= sp;Figure 6 is showing the GET request from the DOTS client, and the DOTS g= ateways will update the GET request to add and update the client-identifier= array.

I donR= 17;t think the client-identifier should be in the same level as alias-name.

&nbs= p;

-Tiru

&nbs= p;

From:<= /span> Dots [mailto:dots-bounces@ietf.org] On Behalf Of Jon Shallow
Sent: Saturday, November 4, 2017 3:03 AM
To: dots@ietf.org
Subject: [Dots] Data channel issues with GET

 

Hi Tiru et al,

 

I am having challenges coding u= p the GET for channel identifiers.

 

A DOTS Client as part of a DOTS= gateway can use different client-identifiers when doing a PUT for the alia= s-name.   The DOTS server will therefore have multiple client-ide= ntifier arrays for the DOTS GW client.

 

However when doing a GET using = ‘content=3Dconfig’, as things currently stand, only one client-= identifier array can returned as per the below in Figure 7:-

 

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<= /span>

 

“3.2.3.  Retrieving = Installed Identifiers

 

   A GET request is u= sed to retrieve the set of installed identifiers

   from a DOTS server= (Section 3.3.1 in [RFC8040]).  Figure 6 shows how

   to retrieve all th= e identifiers that were instantiated by the DOTS

   client.  The = content parameter and its permitted values are defined

   in Section 4.8.1 o= f [RFC8040].

 

     GET /r= estconf/data/ietf-dots-data-channel-identifier:identifier?\

     &= nbsp;   content=3Dconfig HTTP/1.1

     Host: = {host}:{port}

     Accept= : application/yang-data+json

 

     &= nbsp;    Figure 6: GET to retrieve all the installed identif= iers

 

   Figure 7 shows res= ponse for all identifiers on the DOTS server.

 

   {

    "ietf-d= ots-data-channel-identifier:identifier": {

     &= nbsp; "client-identifier": [

     &= nbsp;    "dz6pHjaADkaFTbjr0JGBpw",

     &= nbsp;    "iAYmCNPmrYoKoqzgFMiobw"

     &= nbsp; ],

     &= nbsp; "alias": [

     &= nbsp;   {

     &= nbsp;     "alias-name": "Server1",<= o:p>

     &= nbsp;     "traffic-protocol": [

     &= nbsp;       6”

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D

 

I think that the yang model nee= ds to be re-written, by moving leaf-list client-identifier down to the same= level as alias-name as :-

 

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D

     contai= ner identifier {

     &= nbsp;    description "Top level container for identifie= rs";

 

     &= nbsp;        list alias {

     &= nbsp;           &nbs= p; key alias-name;

     &= nbsp;            &nb= sp;description "List of identifiers";

 

     &= nbsp;           &nbs= p; leaf alias-name {

     &= nbsp;           &nbs= p;    type string;

     &= nbsp;           &nbs= p;    description "alias name";<= /p>

     &= nbsp;           &nbs= p; }

 

     &= nbsp;           &nbs= p; leaf-list client-identifier {

     &= nbsp;           &nbs= p;    type binary;

     &= nbsp;           &nbs= p;    description  "A client identifier conveyed b= y a DOTS gateway

     &= nbsp;           &nbs= p;            &= nbsp;     to a remote DOTS server.";

 

     &= nbsp;           &nbs= p;    reference

     &= nbsp;           &nbs= p;       "I-D.itef-dots-signal-channel&q= uot;;

     &= nbsp;           &nbs= p; }

 

     &= nbsp;           &nbs= p; leaf-list target-ip {

 

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D

 

And reflected appropriately thr= oughout the data channel draft.

 

The issue is the same for the a= ccess control list – client-identifier needs to be at the same level = as acl-name

 

module: ietf-dots-access-contro= l-list

  augment /ietf-acl:access= -lists:

    +--rw cl= ient-identifier*   binary

 

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D

Needs to be

 

module: ietf-dots-access-contro= l-list

  augment /ietf-acl:access= -lists/ietf-acl:acl/:

    +--rw cl= ient-identifier*   binary

 

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D

 

And replicated as appropriate t= hroughout the draft

 

Regards

 

Jon

--_000_DM5PR16MB1788B62D9BA630B9B0153019EA520DM5PR16MB1788namp_-- From nobody Sat Nov 4 07:35:09 2017 Return-Path: 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 A125813FAF5 for ; Sat, 4 Nov 2017 07:35:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.32 X-Spam-Level: X-Spam-Status: No, score=-4.32 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham 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 ElYWMj-GBfgu for ; Sat, 4 Nov 2017 07:35:04 -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 40A4513F6BC for ; Sat, 4 Nov 2017 07:35:04 -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=1509806085; 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: authentication-results:x-originating-ip:x-ms-publictraffictype: x-microsoft-exchange-diagnostics:x-ms-exchange-antispam-srfa-diagnostics: x-ms-office365-filtering-correlation-id:x-microsoft-antispam: x-ms-traffictypediagnostic:x-exchange-antispam-report-test: x-microsoft-antispam-prvs:x-exchange-antispam-report-cfa-test: x-forefront-prvs:x-forefront-antispam-report: received-spf:spamdiagnosticoutput:spamdiagnosticmetadata: Content-Type: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-Transport-CrossTenantHeadersStamped: X-OriginatorOrg:X-NAI-Spam-Flag:X-NAI-Spam-Threshold: X-NAI-Spam-Score:X-NAI-Spam-Version; bh=T O0kjqbW1+xTTldsRKPnO0evW7wEcV0lRhZrjWjHAA U=; b=EdP9ComkXofysm/5yKRFjj9mty7ElsTp7TF4WuhE0uE8 wrZkyPIat5KvSZA8NhikOfvstUfN71cNs0cMHDFQRquNlpXD+N 2SxI6IxZKmTiIheu9XxjL5/FP4YDExxY07W9YEOAgMksafVYf9 DzT3n59tAXEdmBXrpPuaUZG9gus= Received: from DNVEXAPP1N05.corpzone.internalzone.com (unknown [10.44.48.89]) by DNVWSMAILOUT1.mcafee.com with smtp id 6d6d_0820_93bbd4ea_4799_4b79_8b4b_4af748e1efd2; Sat, 04 Nov 2017 09:34:44 -0500 Received: from DNVEXUSR1N13.corpzone.internalzone.com (10.44.48.86) by DNVEXAPP1N05.corpzone.internalzone.com (10.44.48.89) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Sat, 4 Nov 2017 08:34:44 -0600 Received: from DNVO365EDGE2.corpzone.internalzone.com (10.44.176.74) by DNVEXUSR1N13.corpzone.internalzone.com (10.44.48.86) with Microsoft SMTP Server (TLS) id 15.0.1347.2 via Frontend Transport; Sat, 4 Nov 2017 08:34:44 -0600 Received: from NAM02-CY1-obe.outbound.protection.outlook.com (10.44.176.241) by edge.mcafee.com (10.44.176.74) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Sat, 4 Nov 2017 08:34:43 -0600 Received: from DM5PR16MB1788.namprd16.prod.outlook.com (10.172.44.144) by DM5PR16MB1786.namprd16.prod.outlook.com (10.172.44.142) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.197.13; Sat, 4 Nov 2017 14:34:41 +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.20.0197.017; Sat, 4 Nov 2017 14:34:41 +0000 From: "Konda, Tirumaleswar Reddy" To: Jon Shallow , "dots@ietf.org" Thread-Topic: [Dots] Data channel issues with GET Thread-Index: AdNU60NzSK+9AEyfSlySy52mDm5lHgANmhBQAA4iMgAAAg7CgAAE0QTgAADGigAAABq2UA== Date: Sat, 4 Nov 2017 14:34:41 +0000 Message-ID: References: <06f601d354eb$482cce20$d8866a60$@jpshallow.com> <075801d3555a$34dbbd30$9e933790$@jpshallow.com> <077401d35562$7015a8e0$5040faa0$@jpshallow.com> <079901d35578$ce0bc270$6a234750$@jpshallow.com> In-Reply-To: <079901d35578$ce0bc270$6a234750$@jpshallow.com> 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: [122.171.65.119] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DM5PR16MB1786; 6:YQFvH29WcQs9JehOiYseFtLjgASVuQ6o+mILM8mWoeHtFZtXmcPFVO/cC0MCVIljbB32h1t9CReyBlkqwPs2Z2wdOT8m//wYIfaMnnGzQOdxmsChwSv9pbP0RA065dZM9ftdOVxHaIUOEbi/hhix3euh+8VrI4rPVXkR+pr06aWb6RriRL1KYLxr8WUmPW3s/xroil5ydFC2pXK4eskP2lghzSo9gD3BrXUY7SXhR9hf35pqdjW63i7pZ85j++ccwEOXXnEKECp/zRoPx6ANOa8f0TeQdvrDi+HeCqnduaP24mCsM/FtFXBRqtdOg3uTc5Y9rJKVO3zKeKY2oyiir9AeJGsi1dmVzU0NFV+352k=; 5:90LslcStZU36qTnjOsSJAECbIHgyFecZxw4XJfOcqH74qh6IF+ddEWyDOJ2m5cMO2w8Xu41wKyz3tLSFFnfg5EmSHDb98MX1J5p9xudC/nGp6PvUzL+QHJjTF59eDDzOk5NQZ4pfJq1rNeOxmL1uYKjGgv70Du/2dMersiBk+5Y=; 24:DZnnRGuyq0V6aVAb+QuGkzC8anlw6u758sXhdUZlOpxe6DbgSobEOCeV+PikREWF7Y0qxWkAy9s1eMzUGMaJwYBWijhbo8Sm7q4FN/Fsyl4=; 7:RpPesyyxKLQxLpHBn8uUfP70OwhRwwXVpJvMi/Slel3gFgXpGNzF1tu2BpACrc6RYlzgtWWI0XrAGCGPOgmfvXqnxv/k+p26Ps/KmSlLjWMFgWCzEekB5p63WwKIGxufvEq6iOwm4gmj9V5mfFAbSnyWR/a9TQTm5ktoGY6buofV9oOTfl9ZnKuGb2foGk5jAjr6M+FI7ri5vZI+h1/LBvvGc8xC9MM6eOCMUVUcu4Q4dPUw/XeWtvRy+np+IloD x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: ff56826a-812d-4652-16f7-08d523912fa3 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(2017052603199); SRVR:DM5PR16MB1786; x-ms-traffictypediagnostic: DM5PR16MB1786: x-exchange-antispam-report-test: UriScan:(158342451672863)(21748063052155)(123452027830198); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(8121501046)(5005006)(10201501046)(93006095)(93001095)(3002001)(100000703101)(100105400095)(3231021)(6041248)(20161123558100)(20161123560025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123555025)(20161123562025)(20161123564025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:DM5PR16MB1786; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:DM5PR16MB1786; x-forefront-prvs: 048111149A x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(376002)(346002)(51444003)(189002)(32952001)(199003)(102836003)(3846002)(105586002)(790700001)(6116002)(33656002)(19609705001)(189998001)(53546010)(25786009)(93886005)(229853002)(66066001)(2906002)(9686003)(53946003)(6306002)(54896002)(55016002)(53936002)(110136005)(6246003)(50986999)(6506006)(6436002)(77096006)(2501003)(54356999)(76176999)(575784001)(86362001)(106356001)(101416001)(236005)(72206003)(316002)(74316002)(7736002)(5660300001)(3660700001)(81156014)(97736004)(99286004)(9326002)(2900100001)(14454004)(81166006)(8936002)(7696004)(68736007)(2950100002)(478600001)(3280700002)(80792005)(8676002)(21314002)(85282002); DIR:OUT; SFP:1101; SCL:1; SRVR:DM5PR16MB1786; H:DM5PR16MB1788.namprd16.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; 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_DM5PR16MB178832B56CE95EE5739B31A0EA520DM5PR16MB1788namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: ff56826a-812d-4652-16f7-08d523912fa3 X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Nov 2017 14:34:41.7834 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4943e38c-6dd4-428c-886d-24932bc2d5de X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR16MB1786 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 <6151> : inlines <6156> : streams <1769326> : uri <2528049> Archived-At: Subject: Re: [Dots] Data channel issues with GET 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Nov 2017 14:35:08 -0000 --_000_DM5PR16MB178832B56CE95EE5739B31A0EA520DM5PR16MB1788namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Jon, Please see inline From: Jon Shallow [mailto:supjps-ietf@jpshallow.com] Sent: Saturday, November 4, 2017 7:56 PM To: Konda, Tirumaleswar Reddy ; dots@ie= tf.org Subject: RE: [Dots] Data channel issues with GET Hi Tiru, I still do not have an answer to my two other questions in my mail of 04 No= vember 2017 10:47 One "This still does not answer my implied concern - how does a DOTS gateway cl= ient request all the aliases / filters / mitigations to sync up state when,= say, the DOTS gateway client restarts? - The DOTS gateway may not know all the client-identifiers that are talking= to the server component of the DOTS gateway - they may be behind yet anoth= er DOTS gateway." Comment: The DOTS server will have the requesting DOTS client (client in a = DOTS gateway) identifier, so the DOTS server will filter on this, but is in= capable of sending back different passed upstream client identifiers unless= they are included in the GET request. Two As CIH(C1ax) should be unique across all DOTS clients, do we really need to= add in all the other CIH() as the traffic passes up through to S3? =3D=3D=3D=3D In addition, I am not convinced that the DELETE statement is correct as per= RFC8040 - I think the & before alias-name should be a / which makes things= interesting if there is no client-identifier to put in the path. [TR] Thanks, fixed. -Tiru DELETE /restconf/data/ietf-dots-data-channel-identifier:identifier\ /client-identifier=3Ddz6pHjaADkaFTbjr0JGBpw,iAYmCNPmrYoKoqzgFMiobw= &alias-name=3DServer1 HTTP/1.1 Host: {host}:{port} Figure 5: DELETE identifier From: Dots [mailto:ietf-supjps-dots-bounces@ietf.org] On Behalf Of Konda, T= irumaleswar Reddy Sent: 04 November 2017 14:12 To: Jon Shallow; dots@ietf.org Subject: Re: [Dots] Data channel issues with GET From: Jon Shallow [mailto:supjps-ietf@jpshallow.com] Sent: Saturday, November 4, 2017 5:16 PM To: Konda, Tirumaleswar Reddy >; dots@ietf.org Subject: RE: [Dots] Data channel issues with GET Actually, looking at RFC8040, the Figure 6 syntax should be " GET /restconf/data/ietf-dots-data-channel-identifier:identifier/\ client-identifier=3Ddz6pHjaADkaFTbjr0JGBpw,iAYmCNPmrYoKoqzgFMiobw?= \ content=3Dconfig HTTP/1.1 Host: {host}:{port} Accept: application/yang-data+json Figure 6: GET to retrieve all the installed identifiers" To represent the Figure 7 output. Correct? Yes, fixed. -Tiru Regards Jon From: Dots [mailto: dots-bounces@ietf.org] On= Behalf Of Jon Shallow Sent: 04 November 2017 10:47 To: 'Konda, Tirumaleswar Reddy'; dots@ietf.org Subject: Re: [Dots] Data channel issues with GET Hi Tiru, Agreed that a request from a DOTS client going through multiple DOTS gatewa= ys will get the appropriate client-identifier added, and the response initi= ally generated by the final DOTS server will have all the client-identifier= s. However, as the response passes back through the DOTS gateways, the appropr= iate client-identifier will get stripped off and the originating DOTS clien= t will have no visibility of the client-identifiers - as per " A DOTS gateway MUST update the 'client-identifier' list in the response to remove the 'client-identifier' value it had added in the corresponding request before forwarding the response to the DOTS client." So, Figure 6 and Figure 7 do not correctly portray the reality as seen by a= DOTS client (whether on a DOTS gateway or not). When the DOTS Gateway client component generates the GET request should the= request be (to match Figure 7 response) " GET /restconf/data/ietf-dots-data-channel-identifier:identifier?\ content=3Dconfig&client-identifier=3Ddz6pHjaADkaFTbjr0JGBpw,iAYmCN= PmrYoKoqzgFMiobw HTTP/1.1 Host: {host}:{port} Accept: application/yang-data+json Figure 6: GET to retrieve all the installed identifiers" =3D=3D=3D=3D=3D This still does not answer my implied concern - how does a DOTS gateway cli= ent request all the aliases / filters / mitigations to sync up state when, = say, the DOTS gateway client restarts? - The DOTS gateway may not know all the client-identifiers that are talking= to the server component of the DOTS gateway - they may be behind yet anoth= er DOTS gateway. Taking this more complex example involving multiple gateways (should it be = in the drafts somewhere for helping with client-identifier clarity?) DOTS client (C1aj) ----------------------------------------- (S1j) DOTS gat= eway J (C2j) ----------\ DOTS client (C1bj) --------------------------------------------/ = | = | DOTS client (C1ax) ------- (S1x) DOTS gateway X (C2x) ------ (S2k) DOTS gat= eway K (C3k) -------- (S3) DOTS client (C1bx) ----------/ | | DOTS client (C1ay) ------- (S1y) DOTS gateway Y (C2y) ---------/ DOTS client (C1by) ----------/ If C3k restarts how is he able to re-sync his information from S3? C3K doe= s not have a GET 'all' capability with client-identifier being above the le= vel of alias-name. It maybe that C3k does not need to re-sync, but C3k sho= uld have the flexibility if C3k is, say, able to cache information to reduc= e the number of requests having to pass all the way through to S3. As an aside, in my current implementation, where CIH(xxx) is the Client Ide= ntifier hash of xxx C1ax does a PUT (alias-name=3DServer1), C2x does a PUT (alias-name=3DServer1&client-identifer=3DCIH(C1ax)), C3k does a PUT (alias-name=3DServer1&client-identifer=3DCIH(C1ax),CIH(C2x)) and S3 uniquely stores this alias-name as (alias-name=3DServer1&client-iden= tifer=3DCIH(C1ax),CIH(C2x),CIH(C3k)) so that if any of the DOTS clients do a PUT (alias-name=3DServer1) [with sa= me alias name] S3 can differentiate them all. As CIH(C1ax) should be unique across all DOTS clients, do we really need to= add in all the other CIH() as the traffic passes up through to S3? Regards Jon From: Dots [mailto: dots-bounces@ietf.org] On= Behalf Of Konda, Tirumaleswar Reddy Sent: 04 November 2017 04:16 To: Jon Shallow; dots@ietf.org Subject: Re: [Dots] Data channel issues with GET Hi Jon, GET request will only retrieve the alias-names installed by a DOTS client a= nd not the alias-names for all the DOTS clients. The client-identifier arra= y is uniquely identifying the DOTS client and does not need be repeated for= every alias-name conveyed by the client. Figure 6 is showing the GET requ= est from the DOTS client, and the DOTS gateways will update the GET request= to add and update the client-identifier array. I don't think the client-identifier should be in the same level as alias-na= me. -Tiru From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Jon Shallow Sent: Saturday, November 4, 2017 3:03 AM To: dots@ietf.org Subject: [Dots] Data channel issues with GET Hi Tiru et al, I am having challenges coding up the GET for channel identifiers. A DOTS Client as part of a DOTS gateway can use different client-identifier= s when doing a PUT for the alias-name. The DOTS server will therefore hav= e multiple client-identifier arrays for the DOTS GW client. However when doing a GET using 'content=3Dconfig', as things currently stan= d, only one client-identifier array can returned as per the below in Figure= 7:- =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D "3.2.3. Retrieving Installed Identifiers A GET request is used to retrieve the set of installed identifiers from a DOTS server (Section 3.3.1 in [RFC8040]). Figure 6 shows how to retrieve all the identifiers that were instantiated by the DOTS client. The content parameter and its permitted values are defined in Section 4.8.1 of [RFC8040]. GET /restconf/data/ietf-dots-data-channel-identifier:identifier?\ content=3Dconfig HTTP/1.1 Host: {host}:{port} Accept: application/yang-data+json Figure 6: GET to retrieve all the installed identifiers Figure 7 shows response for all identifiers on the DOTS server. { "ietf-dots-data-channel-identifier:identifier": { "client-identifier": [ "dz6pHjaADkaFTbjr0JGBpw", "iAYmCNPmrYoKoqzgFMiobw" ], "alias": [ { "alias-name": "Server1", "traffic-protocol": [ 6" =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D I think that the yang model needs to be re-written, by moving leaf-list cli= ent-identifier down to the same level as alias-name as :- =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D container identifier { description "Top level container for identifiers"; list alias { key alias-name; description "List of identifiers"; leaf alias-name { type string; description "alias name"; } leaf-list client-identifier { type binary; description "A client identifier conveyed by a DOTS = gateway to a remote DOTS server."; reference "I-D.itef-dots-signal-channel"; } leaf-list target-ip { =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D And reflected appropriately throughout the data channel draft. The issue is the same for the access control list - client-identifier needs= to be at the same level as acl-name module: ietf-dots-access-control-list augment /ietf-acl:access-lists: +--rw client-identifier* binary =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Needs to be module: ietf-dots-access-control-list augment /ietf-acl:access-lists/ietf-acl:acl/: +--rw client-identifier* binary =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D And replicated as appropriate throughout the draft Regards Jon --_000_DM5PR16MB178832B56CE95EE5739B31A0EA520DM5PR16MB1788namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Jon,

&nbs= p;

Please se= e inline

 

From:<= /span> Jon Shallow [mailto:s= upjps-ietf@jpshallow.com]
Sent: Saturday, November 4, 2017 7:56 PM
To: Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@McAfee.com= >; dots@ietf.org
Subject: RE: [Dots] Data channel issues with GET

 

Hi Tiru= ,

&n= bsp;

I still= do not have an answer to my two other questions in my mail of 04 November 2017 10:47<= /p>

 <= /p>

One

 <= /p>

“This still does not answer my implied co= ncern – how does a DOTS gateway client request all the aliases / filters / mitigations to sync up state when, say, the DOTS gateway clien= t restarts?

- The D= OTS gateway may not know all the client-identifiers that are talking to the= server component of the DOTS gateway – they may be behind yet anothe= r DOTS gateway.”

&n= bsp;

Comment= : The DOTS server will have the requesting DOTS client (client in a DOTS ga= teway) identifier, so the DOTS server will filter on this, but is incapable= of sending back different passed upstream client identifiers unless they are included in the GET request.=

 <= /p>

Two

 <= /p>

As CIH(= C1ax) should be unique across all DOTS clients, do we really need to add in= all the other CIH() as the traffic passes up through to S3?

 <= /p>

=3D=3D= =3D=3D

In addi= tion, I am not convinced that the DELETE statement is correct as per RFC804= 0 – I think the & before alias-name should be a / which makes thi= ngs interesting if there is no client-identifier to put in the path.

 

[TR] Thanks, fixed.<= /span>

 

-Tiru

&n= bsp;

  = DELETE /restconf/data/ietf-dots-data-channel-identifier:identifier\

 &= nbsp;       /client-identifier=3Ddz6pHjaADkaF= Tbjr0JGBpw,iAYmCNPmrYoKoqzgFMiobw&alias= -name=3DServer1 HTTP/1.1

  = Host: {host}:{port}

&n= bsp;

 &= nbsp;           &nbs= p;          Figure 5: DELETE i= dentifier

&n= bsp;

From: Dots [mailto:ietf-supjps-dots-bounces@ietf.org] On Behalf Of Konda, Tirumaleswar Reddy
Sent: 04 November 2017 14:12
To: Jon Shallow; dots@ietf.org<= br> Subject: Re: [Dots] Data channel issues with GET

 

From:<= /span> Jon Shallow [mailto:supjps-ietf@jpshallow.com]
Sent: Saturday, November 4, 2017 5:16 PM
To: Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@McAfee.com>; dots@ietf.org
Subject: RE: [Dots] Data channel issues with GET

 

Actuall= y, looking at RFC8040, the Figure 6 syntax should be

&n= bsp;

“=     GET /restconf/data/ietf-dots-data-channel-identifier:ide= ntifier/\

 &= nbsp;       client-identifier=3Ddz6pHjaADkaFT= bjr0JGBpw,iAYmCNPmrYoKoqzgFMiobw?\

 &= nbsp;       content=3Dconfig HTTP/1.1

 &= nbsp;   Host: {host}:{port}

 &= nbsp;   Accept: application/yang-data+json<= /p>

&n= bsp;

 &= nbsp;        Figure 6: GET to retrieve a= ll the installed identifiers”

&n= bsp;

To repr= esent the Figure 7 output.

&n= bsp;

Correct= ?

 

Yes, fixed.

 

-Tiru

&n= bsp;

Regards=

&n= bsp;

Jon

&n= bsp;

From: Dots [mailto: = dots-bounces@ietf.org] On Behalf Of Jon Shallow
Sent: 04 November 2017 10:47
To: 'Konda, Tirumaleswar Reddy'; dots@ietf.org
Subject: Re: [Dots] Data channel issues with GET

 

Hi Tiru= ,

&n= bsp;

Agreed = that a request from a DOTS client going through multiple DOTS gateways will= get the appropriate client-identifier added, and the response initially ge= nerated by the final DOTS server will have all the client-identifiers.

&n= bsp;

However= , as the response passes back through the DOTS gateways, the appropriate cl= ient-identifier will get stripped off and the originating DOTS client will = have no visibility of the client-identifiers – as per

“=    A DOTS gateway MUST update the 'client-identifier' list in the=

 &= nbsp; response to remove the 'client-identifier' value it had added in the<= o:p>

 &= nbsp; corresponding request before forwarding the response to the DOTS=

 &= nbsp; client.”

&n= bsp;

So, Fig= ure 6 and Figure 7 do not correctly portray the reality as seen by a DOTS c= lient (whether on a DOTS gateway or not).

&n= bsp;

When th= e DOTS Gateway client component generates the GET request should the reques= t be (to match Figure 7 response)

&n= bsp;

“=     GET /restconf/data/ietf-dots-data-channel-identifier:ide= ntifier?\

 &= nbsp;       content=3Dconfig&client-ident= ifier=3Ddz6pHjaADkaFTbjr0JGBpw,iAYmCNPmrYoKoqzgFMiobw HTTP/1.1

 &= nbsp;   Host: {host}:{port}

 &= nbsp;   Accept: application/yang-data+json<= /p>

&n= bsp;

 &= nbsp;        Figure 6: GET to retrieve a= ll the installed identifiers”

&n= bsp;

=3D=3D= =3D=3D=3D

&n= bsp;

This st= ill does not answer my implied concern – how does a DOTS gateway clie= nt request all the aliases / filters / mitigations to sync up state when, s= ay, the DOTS gateway client restarts?

- The D= OTS gateway may not know all the client-identifiers that are talking to the= server component of the DOTS gateway – they may be behind yet anothe= r DOTS gateway.

&n= bsp;

Taking = this more complex example involving multiple gateways (should it be in the = drafts somewhere for helping with client-identifier clarity?)

&n= bsp;

DOTS client (C1aj) -----------= ------------------------------ (S1j) DOTS gateway J (C2j) ----------\ =  

DOTS client (C1bj) -----------= ---------------------------------/       = ;             &= nbsp;           &nbs= p; |

     =             &nb= sp;            =              &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;    |

DOTS client (C1ax) ------- (S1= x) DOTS gateway X (C2x) ------ (S2k) DOTS gateway K (C3k) -------- (S3)&nbs= p;  

DOTS client (C1bx) ----------/&nb= sp;            =              &n= bsp;      |     &nbs= p;            &= nbsp;            

     &nb= sp;            =             &nb= sp;            =             &nb= sp;       |     = ;            &n= bsp;            &nbs= p;  

DOTS client (C1ay) ------- (S1y) = DOTS gateway Y (C2y) ---------/       &n= bsp;            = ;             <= o:p>

DOTS client (C1by) ----------/&nb= sp;            =              &n= bsp;            = ;            &n= bsp;            = ;   

     &nb= sp;            =             &nb= sp;            =             &nb= sp;            =             &nb= sp;            =     

 = ;

If C3k = restarts how is he able to re-sync his information from S3?  C3K does = not have a GET ‘all’ capability with client-identifier being ab= ove the level of alias-name.  It maybe that C3k does not need to re-sync, but C3k should have the flexibility if C3k is, say, able = to cache information to reduce the number of requests having to pass all th= e way through to S3.

&n= bsp;

As an a= side, in my current implementation, where CIH(xxx) is the Client Identifier= hash of xxx

&n= bsp;

C1ax do= es a PUT (alias-name=3DServer1),

C2x doe= s a PUT (alias-name=3DServer1&client-identifer=3DCIH(C1ax)),=

C3k doe= s a PUT (alias-name=3DServer1&client-identifer=3DCIH(C1ax),CIH(C2x))

and S3 = uniquely stores this alias-name as (alias-name=3DServer1&client-identif= er=3DCIH(C1ax),CIH(C2x),CIH(C3k))

so that= if any of the DOTS clients do a PUT (alias-name=3DServer1) [with same alia= s name] S3 can differentiate them all.

&n= bsp;

As CIH(= C1ax) should be unique across all DOTS clients, do we really need to add in= all the other CIH() as the traffic passes up through to S3?

&n= bsp;

Regards=

&n= bsp;

Jon

&n= bsp;

From: Dots [mailto: = dots-bounces@ietf.org] On Behalf Of Konda, Tirumaleswar Reddy
Sent: 04 November 2017 04:16
To: Jon Shallow; dots@ietf.org
Subject: Re: [Dots] Data channel issues with GET

 

Hi Jon,

&nbs= p;

GET reque= st will only retrieve the alias-names installed by a DOTS client and not th= e alias-names for all the DOTS clients. The client-identifier array is uniq= uely identifying the DOTS client and does not need be repeated for every alias-name conveyed by the client. &nb= sp;Figure 6 is showing the GET request from the DOTS client, and the DOTS g= ateways will update the GET request to add and update the client-identifier= array.

I donR= 17;t think the client-identifier should be in the same level as alias-name.

&nbs= p;

-Tiru

&nbs= p;

From:<= /span> Dots [mailto:dots-bounces@ietf.org] On Behalf Of Jon Shallow
Sent: Saturday, November 4, 2017 3:03 AM
To: dots@ietf.org
Subject: [Dots] Data channel issues with GET

 

Hi Tiru et al,

 

I am having challenges coding u= p the GET for channel identifiers.

 

A DOTS Client as part of a DOTS= gateway can use different client-identifiers when doing a PUT for the alia= s-name.   The DOTS server will therefore have multiple client-ide= ntifier arrays for the DOTS GW client.

 

However when doing a GET using = ‘content=3Dconfig’, as things currently stand, only one client-= identifier array can returned as per the below in Figure 7:-

 

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<= /span>

 

“3.2.3.  Retrieving = Installed Identifiers

 

   A GET request is u= sed to retrieve the set of installed identifiers

   from a DOTS server= (Section 3.3.1 in [RFC8040]).  Figure 6 shows how

   to retrieve all th= e identifiers that were instantiated by the DOTS

   client.  The = content parameter and its permitted values are defined

   in Section 4.8.1 o= f [RFC8040].

 

     GET /r= estconf/data/ietf-dots-data-channel-identifier:identifier?\

     &= nbsp;   content=3Dconfig HTTP/1.1

     Host: = {host}:{port}

     Accept= : application/yang-data+json

 

     &= nbsp;    Figure 6: GET to retrieve all the installed identif= iers

 

   Figure 7 shows res= ponse for all identifiers on the DOTS server.

 

   {

    "ietf-dots= -data-channel-identifier:identifier": {

     &nbs= p; "client-identifier": [

     &nbs= p;    "dz6pHjaADkaFTbjr0JGBpw",<= /p>

     &nbs= p;    "iAYmCNPmrYoKoqzgFMiobw"

     &nbs= p; ],

     &nbs= p; "alias": [

     &nbs= p;   {

     &= nbsp;     "alias-name": "Server1",<= o:p>

     &= nbsp;     "traffic-protocol": [

     &= nbsp;       6”

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D

 

I think that the yang model nee= ds to be re-written, by moving leaf-list client-identifier down to the same= level as alias-name as :-

 

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D

     contai= ner identifier {

     &= nbsp;    description "Top level container for identifie= rs";

 

     &= nbsp;        list alias {

     &= nbsp;           &nbs= p; key alias-name;

     &= nbsp;            &nb= sp;description "List of identifiers";

 

     &= nbsp;           &nbs= p; leaf alias-name {

     &= nbsp;           &nbs= p;    type string;

     &= nbsp;           &nbs= p;    description "alias name";<= /p>

     &= nbsp;           &nbs= p; }

 

     &= nbsp;           &nbs= p; leaf-list client-identifier {

     &= nbsp;           &nbs= p;    type binary;

     &= nbsp;           &nbs= p;    description  "A client identifier conveyed b= y a DOTS gateway

     &= nbsp;           &nbs= p;            &= nbsp;     to a remote DOTS server.";

 

     &= nbsp;           &nbs= p;    reference

     &= nbsp;           &nbs= p;       "I-D.itef-dots-signal-channel&q= uot;;

     &= nbsp;           &nbs= p; }

 

     &= nbsp;           &nbs= p; leaf-list target-ip {

 

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D

 

And reflected appropriately thr= oughout the data channel draft.

 

The issue is the same for the a= ccess control list – client-identifier needs to be at the same level = as acl-name

 

module: ietf-dots-access-contro= l-list

  augment /ietf-acl:access= -lists:

    +--rw cl= ient-identifier*   binary

 

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D

Needs to be

 

module: ietf-dots-access-contro= l-list

  augment /ietf-acl:access= -lists/ietf-acl:acl/:

    +--rw cl= ient-identifier*   binary

 

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D

 

And replicated as appropriate t= hroughout the draft

 

Regards

 

Jon

--_000_DM5PR16MB178832B56CE95EE5739B31A0EA520DM5PR16MB1788namp_-- From nobody Sat Nov 4 07:51:51 2017 Return-Path: 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 4D35313FAC5 for ; Sat, 4 Nov 2017 07:51:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 WFDnZLjteKPz for ; Sat, 4 Nov 2017 07:51:47 -0700 (PDT) Received: from mail.jpshallow.com (mail.jpshallow.com [217.40.240.153]) (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 560F213F6BC for ; Sat, 4 Nov 2017 07:51:47 -0700 (PDT) Received: from [127.0.0.1] (helo=N01332) by mail.jpshallow.com with smtps (TLSv1:ECDHE-RSA-AES256-SHA:256) (Exim 4.89) (envelope-from ) id 1eAznV-0000Rr-Ld; Sat, 04 Nov 2017 14:51:45 +0000 From: "Jon Shallow" To: "'Konda, Tirumaleswar Reddy'" , References: <06f601d354eb$482cce20$d8866a60$@jpshallow.com> <075801d3555a$34dbbd30$9e933790$@jpshallow.com> In-Reply-To: Date: Sat, 4 Nov 2017 14:51:46 -0000 Message-ID: <07c101d3557c$70035a90$500a0fb0$@jpshallow.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_07C2_01D3557C.70070410" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQGq3C7tF9zj9qMEJcmaXbDvWUqFfQEpBvoXAuZQ++ICVTWFiqMiGGeQ Content-Language: en-gb Archived-At: Subject: Re: [Dots] Data channel issues with GET 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Nov 2017 14:51:50 -0000 This is a multipart message in MIME format. ------=_NextPart_000_07C2_01D3557C.70070410 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Tiru See 3 comments inline Regards Jon From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of Konda, Tirumaleswar Reddy Sent: 04 November 2017 14:29 To: Jon Shallow; dots@ietf.org Subject: Re: [Dots] Data channel issues with GET Hi Jon, The DOTS gateway (C3k) does not send any requests on its own to the DOTS server (S3). As per the discussion of DOTS gateways in https://tools.ietf.org/html/draft-ietf-dots-architecture-05, it's only relaying the messages from the downstream and upstream agents. The DOTS architecture does not discuss DOTS gateway acting as a caching server. Jon> OK - I will see if further implementation throws anything else up on this - if not, I will leave it as it stands CIH(C1ax) would only be unique across all the DOTS clients communicating with the DOTS gateway X but may not be globally unique (across Gateways J and K), the current approach would ensure no probability of client-identifier collisions. DOTS client (C1aj) -------------------------------------- (S1j) DOTS gateway J (C2j) ------\ DOTS client (C1bj) -----------------------------------------/ | | DOTS client (C1ax) ----- (S1x) DOTS gateway X (C2x) ----- (S2k) DOTS gateway K (C3k) ---- (S3) DOTS client (C1bx) -------/ | | DOTS client (C1ay) ----- (S1y) DOTS gateway Y (C2y) --------/ DOTS client (C1by) -------/ Jon> If gateway K detects a collision in any of CIH(C1ax), CIH(C1bx), CIH(C1ay) and CIH(C1by), gateway K can then add in CIH(C2x) or CIH(C2y) as appropriate to maintain uniqueness as seen by S3. If there is no collision in CIH(C1ax), CIH(C1bx), CIH(C1ay) and CIH(C1by), then these will be unique to S3 when coming from C3k. This then potentially saves some packet space and allows for scaling beyond a small number of gateways. Jon> I 100% agree that we must not have any client identifier collisions. -Tiru From: Jon Shallow [mailto:supjps-ietf@jpshallow.com] Sent: Saturday, November 4, 2017 4:17 PM To: Konda, Tirumaleswar Reddy ; dots@ietf.org Subject: RE: [Dots] Data channel issues with GET Hi Tiru, Agreed that a request from a DOTS client going through multiple DOTS gateways will get the appropriate client-identifier added, and the response initially generated by the final DOTS server will have all the client-identifiers. However, as the response passes back through the DOTS gateways, the appropriate client-identifier will get stripped off and the originating DOTS client will have no visibility of the client-identifiers - as per " A DOTS gateway MUST update the 'client-identifier' list in the response to remove the 'client-identifier' value it had added in the corresponding request before forwarding the response to the DOTS client." So, Figure 6 and Figure 7 do not correctly portray the reality as seen by a DOTS client (whether on a DOTS gateway or not). When the DOTS Gateway client component generates the GET request should the request be (to match Figure 7 response) " GET /restconf/data/ietf-dots-data-channel-identifier:identifier?\ content=config&client-identifier=dz6pHjaADkaFTbjr0JGBpw,iAYmCNPmrYoKoqzgFMio bw HTTP/1.1 Host: {host}:{port} Accept: application/yang-data+json Figure 6: GET to retrieve all the installed identifiers" ===== This still does not answer my implied concern - how does a DOTS gateway client request all the aliases / filters / mitigations to sync up state when, say, the DOTS gateway client restarts? - The DOTS gateway may not know all the client-identifiers that are talking to the server component of the DOTS gateway - they may be behind yet another DOTS gateway. Taking this more complex example involving multiple gateways (should it be in the drafts somewhere for helping with client-identifier clarity?) DOTS client (C1aj) ----------------------------------------- (S1j) DOTS gateway J (C2j) ----------\ DOTS client (C1bj) --------------------------------------------/ | | DOTS client (C1ax) ------- (S1x) DOTS gateway X (C2x) ------ (S2k) DOTS gateway K (C3k) -------- (S3) DOTS client (C1bx) ----------/ | | DOTS client (C1ay) ------- (S1y) DOTS gateway Y (C2y) ---------/ DOTS client (C1by) ----------/ If C3k restarts how is he able to re-sync his information from S3? C3K does not have a GET 'all' capability with client-identifier being above the level of alias-name. It maybe that C3k does not need to re-sync, but C3k should have the flexibility if C3k is, say, able to cache information to reduce the number of requests having to pass all the way through to S3. As an aside, in my current implementation, where CIH(xxx) is the Client Identifier hash of xxx C1ax does a PUT (alias-name=Server1), C2x does a PUT (alias-name=Server1&client-identifer=CIH(C1ax)), C3k does a PUT (alias-name=Server1&client-identifer=CIH(C1ax),CIH(C2x)) and S3 uniquely stores this alias-name as (alias-name=Server1&client-identifer=CIH(C1ax),CIH(C2x),CIH(C3k)) so that if any of the DOTS clients do a PUT (alias-name=Server1) [with same alias name] S3 can differentiate them all. As CIH(C1ax) should be unique across all DOTS clients, do we really need to add in all the other CIH() as the traffic passes up through to S3? Regards Jon From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of Konda, Tirumaleswar Reddy Sent: 04 November 2017 04:16 To: Jon Shallow; dots@ietf.org Subject: Re: [Dots] Data channel issues with GET Hi Jon, GET request will only retrieve the alias-names installed by a DOTS client and not the alias-names for all the DOTS clients. The client-identifier array is uniquely identifying the DOTS client and does not need be repeated for every alias-name conveyed by the client. Figure 6 is showing the GET request from the DOTS client, and the DOTS gateways will update the GET request to add and update the client-identifier array. I don't think the client-identifier should be in the same level as alias-name. -Tiru From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Jon Shallow Sent: Saturday, November 4, 2017 3:03 AM To: dots@ietf.org Subject: [Dots] Data channel issues with GET Hi Tiru et al, I am having challenges coding up the GET for channel identifiers. A DOTS Client as part of a DOTS gateway can use different client-identifiers when doing a PUT for the alias-name. The DOTS server will therefore have multiple client-identifier arrays for the DOTS GW client. However when doing a GET using 'content=config', as things currently stand, only one client-identifier array can returned as per the below in Figure 7:- =============================== "3.2.3. Retrieving Installed Identifiers A GET request is used to retrieve the set of installed identifiers from a DOTS server (Section 3.3.1 in [RFC8040]). Figure 6 shows how to retrieve all the identifiers that were instantiated by the DOTS client. The content parameter and its permitted values are defined in Section 4.8.1 of [RFC8040]. GET /restconf/data/ietf-dots-data-channel-identifier:identifier?\ content=config HTTP/1.1 Host: {host}:{port} Accept: application/yang-data+json Figure 6: GET to retrieve all the installed identifiers Figure 7 shows response for all identifiers on the DOTS server. { "ietf-dots-data-channel-identifier:identifier": { "client-identifier": [ "dz6pHjaADkaFTbjr0JGBpw", "iAYmCNPmrYoKoqzgFMiobw" ], "alias": [ { "alias-name": "Server1", "traffic-protocol": [ 6" =========== I think that the yang model needs to be re-written, by moving leaf-list client-identifier down to the same level as alias-name as :- =========== container identifier { description "Top level container for identifiers"; list alias { key alias-name; description "List of identifiers"; leaf alias-name { type string; description "alias name"; } leaf-list client-identifier { type binary; description "A client identifier conveyed by a DOTS gateway to a remote DOTS server."; reference "I-D.itef-dots-signal-channel"; } leaf-list target-ip { ================ And reflected appropriately throughout the data channel draft. The issue is the same for the access control list - client-identifier needs to be at the same level as acl-name module: ietf-dots-access-control-list augment /ietf-acl:access-lists: +--rw client-identifier* binary ============= Needs to be module: ietf-dots-access-control-list augment /ietf-acl:access-lists/ietf-acl:acl/: +--rw client-identifier* binary =============== And replicated as appropriate throughout the draft Regards Jon ------=_NextPart_000_07C2_01D3557C.70070410 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Tiru

 

See 3 comments = inline

 

Regards

 

Jon

 

From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of = Konda, Tirumaleswar Reddy
Sent: 04 November 2017 = 14:29
To: Jon Shallow; dots@ietf.org
Subject: Re: = [Dots] Data channel issues with GET

 

Hi = Jon,

 

The DOTS gateway (C3k) does not = send any requests on its own to the DOTS server (S3).  As per the = discussion of DOTS gateways in http= s://tools.ietf.org/html/draft-ietf-dots-architecture-05, it’s = only relaying the messages from the downstream and upstream agents. The = DOTS architecture does not discuss DOTS gateway acting as a caching = server.

 

Jon> OK – I = will see if further implementation throws anything else up on this = – if not, I will leave it as it stands

 

CIH(C1ax) would only be = unique across all the DOTS clients communicating with the DOTS gateway X = but may not be globally unique (across Gateways J and K), the current = approach would ensure no probability of client-identifier = collisions.

 

DOTS client (C1aj) = -------------------------------------- (S1j) DOTS gateway J (C2j) = ------\  

DOTS = client (C1bj) = -----------------------------------------/     &= nbsp;           &n= bsp; =            |<= /o:p>

         = ;            =             &= nbsp;   =             &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;     |

DOTS client (C1ax) ----- (S1x) DOTS gateway X (C2x) = ----- (S2k) DOTS gateway K (C3k) ---- (S3)    =

DOTS = client (C1bx) = -------/           = ;            =    =        |     =             &= nbsp;          =    

         = ;            =             &= nbsp;           &n= bsp;           &nb= sp;  |         &nb= sp;           &nbs= p;      =      

DOTS client (C1ay) ----- (S1y) DOTS gateway Y (C2y) = --------/          &nbs= p;            = ;    =       

DOTS client (C1by) = -------/           = ;            =    =             &= nbsp;           &n= bsp;           &nb= sp;    

 

Jon>  If gateway = K detects a collision in any of CIH(C1ax), CIH(C1bx), CIH(C1ay) and = CIH(C1by), gateway K can then add in CIH(C2x) or CIH(C2y) as appropriate = to maintain uniqueness as seen by S3.  If there is no collision in = CIH(C1ax), CIH(C1bx), CIH(C1ay) and CIH(C1by), then these will be unique = to S3 when coming from C3k.  This then potentially saves some = packet space and allows for scaling beyond a small number of = gateways.

 

Jon> I 100% agree = that we must not have any client identifier = collisions.

 

-Tiru

 

From: Jon Shallow [mailto:supjps-ietf@jpshallow.co= m]
Sent: Saturday, November 4, 2017 4:17 PM
To: = Konda, Tirumaleswar Reddy <TirumaleswarReddy_Kond= a@McAfee.com>; dots@ietf.org
Subject: RE: = [Dots] Data channel issues with GET

 

Hi = Tiru,

 

Agreed that a request = from a DOTS client going through multiple DOTS gateways will get the = appropriate client-identifier added, and the response initially = generated by the final DOTS server will have all the = client-identifiers.

 

However, as the response = passes back through the DOTS gateways, the appropriate client-identifier = will get stripped off and the originating DOTS client will have no = visibility of the client-identifiers – as = per

“   A DOTS gateway MUST update = the 'client-identifier' list in the

   response to = remove the 'client-identifier' value it had added in = the

   corresponding request before = forwarding the response to the DOTS

   = client.”

 

So, Figure 6 and Figure = 7 do not correctly portray the reality as seen by a DOTS client (whether = on a DOTS gateway or not).

 

When the DOTS Gateway = client component generates the GET request should the request be (to = match Figure 7 response)

 

“    GET = /restconf/data/ietf-dots-data-channel-identifier:identifier?\<= /span>

         = content=3Dconfig&client-identifier=3Ddz6pHjaADkaFTbjr0JGBpw,iAYmCNPmr= YoKoqzgFMiobw HTTP/1.1

     Host: = {host}:{port}

     Accept: = application/yang-data+json

 

        &= nbsp; Figure 6: GET to retrieve all the installed = identifiers”

 

=3D=3D=3D=3D=3D

 

This still does not = answer my implied concern – how does a DOTS gateway client request = all the aliases / filters / mitigations to sync up state when, say, the = DOTS gateway client restarts?

- The DOTS gateway may = not know all the client-identifiers that are talking to the server = component of the DOTS gateway – they may be behind yet another = DOTS gateway.

 

Taking this more complex = example involving multiple gateways (should it be in the drafts = somewhere for helping with client-identifier = clarity?)

 

DOTS client (C1aj) = ----------------------------------------- (S1j) DOTS gateway J (C2j) = ----------\  

DOTS = client (C1bj) = --------------------------------------------/    &nbs= p;            = ;  =             &= nbsp;  |

         = ;            =             &= nbsp;    =             &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;           |

DOTS = client (C1ax) ------- (S1x) DOTS gateway X (C2x) ------ (S2k) DOTS = gateway K (C3k) -------- (S3)   

DOTS client (C1bx) = ----------/          &n= bsp;           &nb= sp;   =        |     =             &= nbsp;          =    

         = ;            =             &= nbsp;           &n= bsp;           &nb= sp;     |      &nb= sp;           &nbs= p;         =      

DOTS client (C1ay) ------- (S1y) DOTS gateway Y = (C2y) = ---------/          &nb= sp;           &nbs= p;    =       

DOTS client (C1by) = ----------/          &n= bsp;           &nb= sp;   =             &= nbsp;           &n= bsp;           &nb= sp;    

         = ;            =             &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;            = ;            =    

 

If C3k restarts how is = he able to re-sync his information from S3?  C3K does not have a = GET ‘all’ capability with client-identifier being above the = level of alias-name.  It maybe that C3k does not need to re-sync, = but C3k should have the flexibility if C3k is, say, able to cache = information to reduce the number of requests having to pass all the way = through to S3.

 

As an aside, in my = current implementation, where CIH(xxx) is the Client Identifier hash of = xxx

 

C1ax does a PUT = (alias-name=3DServer1),

C2x does a PUT = (alias-name=3DServer1&client-identifer=3DCIH(C1ax)),

C3k does a PUT = (alias-name=3DServer1&client-identifer=3DCIH(C1ax),CIH(C2x))

and S3 = uniquely stores this alias-name as = (alias-name=3DServer1&client-identifer=3DCIH(C1ax),CIH(C2x),CIH(C3k))=

so that if any of the DOTS clients do a PUT = (alias-name=3DServer1) [with same alias name] S3 can differentiate them = all.

 

As CIH(C1ax) should be = unique across all DOTS clients, do we really need to add in all the = other CIH() as the traffic passes up through to = S3?

 

Regards

 

Jon

 

From: Dots [mailto: dots-bounces@ietf.org] On = Behalf Of Konda, Tirumaleswar Reddy
Sent: 04 November 2017 = 04:16
To: Jon Shallow; dots@ietf.org
Subject: Re: = [Dots] Data channel issues with GET

 

Hi = Jon,

 

GET request will only retrieve the = alias-names installed by a DOTS client and not the alias-names for all = the DOTS clients. The client-identifier array is uniquely identifying = the DOTS client and does not need be repeated for every alias-name = conveyed by the client.  Figure 6 is showing the GET request from = the DOTS client, and the DOTS gateways will update the GET request to = add and update the client-identifier array.

I don’t think the = client-identifier should be in the same level as alias-name. =

 

-Tiru

 

From: Dots [mailto:dots-bounces@ietf.org] = On Behalf Of Jon Shallow
Sent: Saturday, November 4, = 2017 3:03 AM
To: dots@ietf.org
Subject: = [Dots] Data channel issues with GET

 

Hi Tiru et al,

 

I am having = challenges coding up the GET for channel identifiers.

 

A DOTS = Client as part of a DOTS gateway can use different client-identifiers = when doing a PUT for the alias-name.   The DOTS server will = therefore have multiple client-identifier arrays for the DOTS GW = client.

 

However when doing a GET using = ‘content=3Dconfig’, as things currently stand, only one = client-identifier array can returned as per the below in Figure = 7:-

 

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

 

“3.2.3.  Retrieving Installed = Identifiers

 

   A GET request is used to retrieve the set = of installed identifiers

   = from a DOTS server (Section 3.3.1 in [RFC8040]).  Figure 6 shows = how

   to retrieve all the = identifiers that were instantiated by the DOTS

   client.  The content parameter and = its permitted values are defined

   in Section 4.8.1 of = [RFC8040].

 

     GET = /restconf/data/ietf-dots-data-channel-identifier:identifier?\<= /p>

         = content=3Dconfig HTTP/1.1

     Host: = {host}:{port}

     Accept: = application/yang-data+json

 

          = Figure 6: GET to retrieve all the installed identifiers

 

   = Figure 7 shows response for all identifiers on the DOTS = server.

 

   {

    = "ietf-dots-data-channel-identifier:identifier": = {

       = "client-identifier": [

          = "dz6pHjaADkaFTbjr0JGBpw",

          = "iAYmCNPmrYoKoqzgFMiobw"

       = ],

       = "alias": [

         = {

         &= nbsp; "alias-name": "Server1",

         &= nbsp; "traffic-protocol": [

         &= nbsp;   6”

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

 

I think that = the yang model needs to be re-written, by moving leaf-list = client-identifier down to the same level as alias-name as = :-

 

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

     container identifier = {

          = description "Top level container for = identifiers";

 

         &= nbsp;    list alias {

         &= nbsp;         key = alias-name;

          =          description = "List of identifiers";

 

         &= nbsp;         leaf alias-name = {

         &= nbsp;            = type string;

         &= nbsp;            = description "alias name";

         &= nbsp;         }

 

         &= nbsp;         leaf-list = client-identifier {

         &= nbsp;            = type binary;

         &= nbsp;            = description  "A client identifier conveyed by a DOTS = gateway

         &= nbsp;           &n= bsp;           &nb= sp;  to a remote DOTS server.";

 

         &= nbsp;            = reference

         &= nbsp;           &n= bsp;   = "I-D.itef-dots-signal-channel";

         &= nbsp;         }

 

         &= nbsp;         leaf-list = target-ip {

 

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

 

And reflected appropriately throughout the data = channel draft.

 

The issue is = the same for the access control list – client-identifier needs to = be at the same level as acl-name

 

module: = ietf-dots-access-control-list

  = augment /ietf-acl:access-lists:

    +--rw = client-identifier*   binary

 

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

<= p class=3DMsoNormal>Needs to be

 

module: = ietf-dots-access-control-list

  = augment /ietf-acl:access-lists/ietf-acl:acl/:

    +--rw = client-identifier*   binary

 

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

 

And = replicated as appropriate throughout the draft

 

Regards

 

Jon

------=_NextPart_000_07C2_01D3557C.70070410-- From nobody Sat Nov 4 08:22:35 2017 Return-Path: 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 6960D13FAC5 for ; Sat, 4 Nov 2017 08:22:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7 X-Spam-Level: X-Spam-Status: No, score=-7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham 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 RsFjTPpgd_oS for ; Sat, 4 Nov 2017 08:22:30 -0700 (PDT) Received: from MIVWSMAILOUT1.mcafee.com (mivwsmailout1.mcafee.com [161.69.47.167]) (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 042C813F6BC for ; Sat, 4 Nov 2017 08:22:29 -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=1509808948; 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: authentication-results:x-originating-ip:x-ms-publictraffictype: x-microsoft-exchange-diagnostics:x-ms-exchange-antispam-srfa-diagnostics: x-ms-office365-filtering-correlation-id:x-microsoft-antispam: x-ms-traffictypediagnostic:x-exchange-antispam-report-test: x-microsoft-antispam-prvs:x-exchange-antispam-report-cfa-test: x-forefront-prvs:x-forefront-antispam-report: received-spf:spamdiagnosticoutput:spamdiagnosticmetadata: Content-Type: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-Transport-CrossTenantHeadersStamped: X-OriginatorOrg:X-NAI-Spam-Flag:X-NAI-Spam-Threshold: X-NAI-Spam-Score:X-NAI-Spam-Version; bh=p mYl/lcfv8ylz3KBXfK4sjUcKwlRUAdF0mZ2LQFvtC E=; b=R6YrPiAYas5k1U3u0PWIb+AobutWBKariuf4krnNgTle ex6op1k+VoC3AgsSRwVvKXn29AXwULRamkvl0r2tMckxBchZ3t OZyX6hqDde2cu5z/pGmAtiory3qeAQFrtn+9mSqh3GGr3k6Ooi e4LVv2W2Kr47SOcEbuUoWNqCTp0= Received: from MIVEXAPP1N02.corpzone.internalzone.com (unknown [10.48.48.89]) by MIVWSMAILOUT1.mcafee.com with smtp id 6464_57e0_03086b88_a910_412b_95bb_554774c7cdcb; Sat, 04 Nov 2017 10:22:27 -0500 Received: from MIVEXUSR1N01.corpzone.internalzone.com (10.48.48.81) by MIVEXAPP1N02.corpzone.internalzone.com (10.48.48.89) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Sat, 4 Nov 2017 11:22:27 -0400 Received: from MIVEXUSR1N07.corpzone.internalzone.com (10.48.48.87) by MIVEXUSR1N01.corpzone.internalzone.com (10.48.48.81) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Sat, 4 Nov 2017 11:22:26 -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.1347.2 via Frontend Transport; Sat, 4 Nov 2017 11:22:25 -0400 Received: from NAM03-DM3-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.1347.2; Sat, 4 Nov 2017 11:22:24 -0400 Received: from DM5PR16MB1788.namprd16.prod.outlook.com (10.172.44.144) by DM5PR16MB1785.namprd16.prod.outlook.com (10.172.44.141) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.197.13; Sat, 4 Nov 2017 15:22:23 +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.20.0197.017; Sat, 4 Nov 2017 15:22:23 +0000 From: "Konda, Tirumaleswar Reddy" To: Jon Shallow , "dots@ietf.org" Thread-Topic: [Dots] Data channel issues with GET Thread-Index: AdNU60NzSK+9AEyfSlySy52mDm5lHgANmhBQAA4iMgAABuS8gAABqgkAAAEMVoA= Date: Sat, 4 Nov 2017 15:22:23 +0000 Message-ID: References: <06f601d354eb$482cce20$d8866a60$@jpshallow.com> <075801d3555a$34dbbd30$9e933790$@jpshallow.com> <07c101d3557c$70035a90$500a0fb0$@jpshallow.com> In-Reply-To: <07c101d3557c$70035a90$500a0fb0$@jpshallow.com> 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: [122.171.65.119] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DM5PR16MB1785; 6:zl1cKW5Rf9guq+6QPP7/J3rUFOrDsN8krdZj2EtT93Ggr7qj7lr0jahwjhOn+Mov3COU08KgqxvvcGfBXv78WLM2iqZrWtVSjXNlp3GubtgsH/+O+IZN+SQAr7Is4gS6urhHIq55CDlPK5zhiHqkg6qSwWtMGOi+KmfE17qQFiGBSTXiwqJMI3f/6HjFCpis/bfKZFsKC1op0ZacgSSlMMMSWhJh5Toyqt0McC/OMX9GAEmoUIQ3pTk/j7JFACgQREEY85Ok3Y5TptJTbh+H4fCu0J5w3SjVV2IUj6Y8XhPus+QSrsazhJKzKh1m9km5mRjDmnjNORr3MnAYwGJca1pwwpW6orSKjvcpenGPIok=; 5:WySoZt2+QdRT/2Qb5MmW/SWBZRy1UosfB7D9s/yfr7jLs8I3zbrjvIp6oH4ZDpBKrFB/1QnoIggfOGOPi7EJsR0pH2VCFeJcdfB5HfWlNK6ob5zOWylsENqslXzfHFTnMp2+NZyE60nMorwusiQWsd9iOJFoFU3j+I2Bvnfy9R0=; 24:XUrCD6GTl5soeSxb4uj4qsqlEEbN4Voaxr7tnAiCIJBzf+9oTs5ZEFie0CfuPTSvpM6NSTQm3XBSCbV8XycdSZ6O2cwO/SeBiwgoHfaWSkg=; 7:asojy5RoU+0xcG2LUUXjBZjfZ2DrSwGZQcNOd5GLdaHJUlr8xyD050Q3B/CN6XuOCsV1adfx/qDet5/zzzrim5s0rJeVFVyh8SH5cnrx1YxWgLcZvL+MDgTMT03eefNoqxfXRTGe/dtP8gprxFtxLqwBnRlaUhFCq/oqdWjcpwfU18BTQpuo1yCfdrkT4LxGpfl40E2+tQ+f0GzS9mkYF+yWdv45rtwYAtKDIidEUF1fXnXzKom3sSsY3irmA816 x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 592a0e43-7759-46d6-4a38-08d52397d91c x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(2017052603199); SRVR:DM5PR16MB1785; x-ms-traffictypediagnostic: DM5PR16MB1785: x-exchange-antispam-report-test: UriScan:(158342451672863)(21748063052155)(123452027830198); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(5005006)(8121501046)(93006095)(93001095)(3002001)(3231021)(100000703101)(100105400095)(10201501046)(6041248)(20161123555025)(20161123558100)(20161123560025)(20161123562025)(20161123564025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:DM5PR16MB1785; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:DM5PR16MB1785; x-forefront-prvs: 048111149A x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(346002)(376002)(51444003)(199003)(189002)(32952001)(55016002)(102836003)(189998001)(53946003)(236005)(790700001)(575784001)(2950100002)(86362001)(33656002)(74316002)(6436002)(2900100001)(9326002)(101416001)(316002)(9686003)(2501003)(68736007)(5660300001)(7736002)(50986999)(76176999)(54356999)(53936002)(3846002)(6116002)(6306002)(54896002)(3280700002)(606006)(14454004)(8936002)(25786009)(97736004)(81166006)(478600001)(77096006)(229853002)(6506006)(99286004)(93886005)(8676002)(19609705001)(106356001)(72206003)(105586002)(81156014)(66066001)(2906002)(7696004)(110136005)(6246003)(53546010)(3660700001)(80792005)(966005)(21314002)(85282002); DIR:OUT; SFP:1101; SCL:1; SRVR:DM5PR16MB1785; H:DM5PR16MB1788.namprd16.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX: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_DM5PR16MB178813CB8A56B2B9AC31CFC1EA520DM5PR16MB1788namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 592a0e43-7759-46d6-4a38-08d52397d91c X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Nov 2017 15:22:23.1086 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4943e38c-6dd4-428c-886d-24932bc2d5de X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR16MB1785 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 <6151> : inlines <6156> : streams <1769329> : uri <2528066> Archived-At: Subject: Re: [Dots] Data channel issues with GET 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Nov 2017 15:22:33 -0000 --_000_DM5PR16MB178813CB8A56B2B9AC31CFC1EA520DM5PR16MB1788namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Jon, Please see inline [TR] From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Jon Shallow Sent: Saturday, November 4, 2017 8:22 PM To: Konda, Tirumaleswar Reddy ; dots@ie= tf.org Subject: Re: [Dots] Data channel issues with GET Hi Tiru See 3 comments inline Regards Jon From: Dots [mailto: dots-bounces@ietf.org] On= Behalf Of Konda, Tirumaleswar Reddy Sent: 04 November 2017 14:29 To: Jon Shallow; dots@ietf.org Subject: Re: [Dots] Data channel issues with GET Hi Jon, The DOTS gateway (C3k) does not send any requests on its own to the DOTS se= rver (S3). As per the discussion of DOTS gateways in https://tools.ietf.or= g/html/draft-ietf-dots-architecture-05, it's only relaying the messages fro= m the downstream and upstream agents. The DOTS architecture does not discus= s DOTS gateway acting as a caching server. Jon> OK - I will see if further implementation throws anything else up on t= his - if not, I will leave it as it stands CIH(C1ax) would only be unique across all the DOTS clients communicating wi= th the DOTS gateway X but may not be globally unique (across Gateways J and= K), the current approach would ensure no probability of client-identifier = collisions. DOTS client (C1aj) -------------------------------------- (S1j) DOTS gatewa= y J (C2j) ------\ DOTS client (C1bj) -----------------------------------------/ = | = | DOTS client (C1ax) ----- (S1x) DOTS gateway X (C2x) ----- (S2k) DOTS gatewa= y K (C3k) ---- (S3) DOTS client (C1bx) -------/ | | DOTS client (C1ay) ----- (S1y) DOTS gateway Y (C2y) --------/ DOTS client (C1by) -------/ Jon> If gateway K detects a collision in any of CIH(C1ax), CIH(C1bx), CIH(= C1ay) and CIH(C1by), gateway K can then add in CIH(C2x) or CIH(C2y) as appr= opriate to maintain uniqueness as seen by S3. If there is no collision in = CIH(C1ax), CIH(C1bx), CIH(C1ay) and CIH(C1by), then these will be unique to= S3 when coming from C3k. This then potentially saves some packet space an= d allows for scaling beyond a small number of gateways. [TR] Agreed. I am assuming there won't be more than 3 DOTS gateways b/w the= DOTS client and server (client-side, server-side and one additional gatewa= y because of recursive signalling). As per our discussion, DOTS signal channel draft says, a DOTS gateway "MAY"= add the client-identifier. -Tiru Jon> I 100% agree that we must not have any client identifier collisions. -Tiru From: Jon Shallow [mailto:supjps-ietf@jpshallow.com] Sent: Saturday, November 4, 2017 4:17 PM To: Konda, Tirumaleswar Reddy >; dots@ietf.org Subject: RE: [Dots] Data channel issues with GET Hi Tiru, Agreed that a request from a DOTS client going through multiple DOTS gatewa= ys will get the appropriate client-identifier added, and the response initi= ally generated by the final DOTS server will have all the client-identifier= s. However, as the response passes back through the DOTS gateways, the appropr= iate client-identifier will get stripped off and the originating DOTS clien= t will have no visibility of the client-identifiers - as per " A DOTS gateway MUST update the 'client-identifier' list in the response to remove the 'client-identifier' value it had added in the corresponding request before forwarding the response to the DOTS client." So, Figure 6 and Figure 7 do not correctly portray the reality as seen by a= DOTS client (whether on a DOTS gateway or not). When the DOTS Gateway client component generates the GET request should the= request be (to match Figure 7 response) " GET /restconf/data/ietf-dots-data-channel-identifier:identifier?\ content=3Dconfig&client-identifier=3Ddz6pHjaADkaFTbjr0JGBpw,iAYmCN= PmrYoKoqzgFMiobw HTTP/1.1 Host: {host}:{port} Accept: application/yang-data+json Figure 6: GET to retrieve all the installed identifiers" =3D=3D=3D=3D=3D This still does not answer my implied concern - how does a DOTS gateway cli= ent request all the aliases / filters / mitigations to sync up state when, = say, the DOTS gateway client restarts? - The DOTS gateway may not know all the client-identifiers that are talking= to the server component of the DOTS gateway - they may be behind yet anoth= er DOTS gateway. Taking this more complex example involving multiple gateways (should it be = in the drafts somewhere for helping with client-identifier clarity?) DOTS client (C1aj) ----------------------------------------- (S1j) DOTS gat= eway J (C2j) ----------\ DOTS client (C1bj) --------------------------------------------/ = | = | DOTS client (C1ax) ------- (S1x) DOTS gateway X (C2x) ------ (S2k) DOTS gat= eway K (C3k) -------- (S3) DOTS client (C1bx) ----------/ | | DOTS client (C1ay) ------- (S1y) DOTS gateway Y (C2y) ---------/ DOTS client (C1by) ----------/ If C3k restarts how is he able to re-sync his information from S3? C3K doe= s not have a GET 'all' capability with client-identifier being above the le= vel of alias-name. It maybe that C3k does not need to re-sync, but C3k sho= uld have the flexibility if C3k is, say, able to cache information to reduc= e the number of requests having to pass all the way through to S3. As an aside, in my current implementation, where CIH(xxx) is the Client Ide= ntifier hash of xxx C1ax does a PUT (alias-name=3DServer1), C2x does a PUT (alias-name=3DServer1&client-identifer=3DCIH(C1ax)), C3k does a PUT (alias-name=3DServer1&client-identifer=3DCIH(C1ax),CIH(C2x)) and S3 uniquely stores this alias-name as (alias-name=3DServer1&client-iden= tifer=3DCIH(C1ax),CIH(C2x),CIH(C3k)) so that if any of the DOTS clients do a PUT (alias-name=3DServer1) [with sa= me alias name] S3 can differentiate them all. As CIH(C1ax) should be unique across all DOTS clients, do we really need to= add in all the other CIH() as the traffic passes up through to S3? Regards Jon From: Dots [mailto: dots-bounces@ietf.org] On= Behalf Of Konda, Tirumaleswar Reddy Sent: 04 November 2017 04:16 To: Jon Shallow; dots@ietf.org Subject: Re: [Dots] Data channel issues with GET Hi Jon, GET request will only retrieve the alias-names installed by a DOTS client a= nd not the alias-names for all the DOTS clients. The client-identifier arra= y is uniquely identifying the DOTS client and does not need be repeated for= every alias-name conveyed by the client. Figure 6 is showing the GET requ= est from the DOTS client, and the DOTS gateways will update the GET request= to add and update the client-identifier array. I don't think the client-identifier should be in the same level as alias-na= me. -Tiru From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Jon Shallow Sent: Saturday, November 4, 2017 3:03 AM To: dots@ietf.org Subject: [Dots] Data channel issues with GET Hi Tiru et al, I am having challenges coding up the GET for channel identifiers. A DOTS Client as part of a DOTS gateway can use different client-identifier= s when doing a PUT for the alias-name. The DOTS server will therefore hav= e multiple client-identifier arrays for the DOTS GW client. However when doing a GET using 'content=3Dconfig', as things currently stan= d, only one client-identifier array can returned as per the below in Figure= 7:- =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D "3.2.3. Retrieving Installed Identifiers A GET request is used to retrieve the set of installed identifiers from a DOTS server (Section 3.3.1 in [RFC8040]). Figure 6 shows how to retrieve all the identifiers that were instantiated by the DOTS client. The content parameter and its permitted values are defined in Section 4.8.1 of [RFC8040]. GET /restconf/data/ietf-dots-data-channel-identifier:identifier?\ content=3Dconfig HTTP/1.1 Host: {host}:{port} Accept: application/yang-data+json Figure 6: GET to retrieve all the installed identifiers Figure 7 shows response for all identifiers on the DOTS server. { "ietf-dots-data-channel-identifier:identifier": { "client-identifier": [ "dz6pHjaADkaFTbjr0JGBpw", "iAYmCNPmrYoKoqzgFMiobw" ], "alias": [ { "alias-name": "Server1", "traffic-protocol": [ 6" =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D I think that the yang model needs to be re-written, by moving leaf-list cli= ent-identifier down to the same level as alias-name as :- =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D container identifier { description "Top level container for identifiers"; list alias { key alias-name; description "List of identifiers"; leaf alias-name { type string; description "alias name"; } leaf-list client-identifier { type binary; description "A client identifier conveyed by a DOTS = gateway to a remote DOTS server."; reference "I-D.itef-dots-signal-channel"; } leaf-list target-ip { =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D And reflected appropriately throughout the data channel draft. The issue is the same for the access control list - client-identifier needs= to be at the same level as acl-name module: ietf-dots-access-control-list augment /ietf-acl:access-lists: +--rw client-identifier* binary =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Needs to be module: ietf-dots-access-control-list augment /ietf-acl:access-lists/ietf-acl:acl/: +--rw client-identifier* binary =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D And replicated as appropriate throughout the draft Regards Jon --_000_DM5PR16MB178813CB8A56B2B9AC31CFC1EA520DM5PR16MB1788namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Jon,

&nbs= p;

Please se= e inline [TR]

 

From:<= /span> Dots [mailto:dots-bou= nces@ietf.org] On Behalf Of Jon Shallow
Sent: Saturday, November 4, 2017 8:22 PM
To: Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@McAfee.com= >; dots@ietf.org
Subject: Re: [Dots] Data channel issues with GET

 

Hi Tiru=

&n= bsp;

See 3 c= omments inline

&n= bsp;

Regards=

&n= bsp;

Jon

&n= bsp;

From: Dots [mailto: dots-bounces@ietf.org] On B= ehalf Of Konda, Tirumaleswar Reddy
Sent: 04 November 2017 14:29
To: Jon Shallow; dots@ietf.org<= br> Subject: Re: [Dots] Data channel issues with GET

 

Hi Jon,

&nbs= p;

The DOTS = gateway (C3k) does not send any requests on its own to the DOTS server (S3)= .  As per the discussion of DOTS gateways in htt= ps://tools.ietf.org/html/draft-ietf-dots-architecture-05, it’s on= ly relaying the messages from the downstream and upstream agents. The DOTS = architecture does not discuss DOTS gateway acting as a caching server.

 

Jon> OK – I will see if further implementation throws anythin= g else up on this – if not, I will leave it as it stands

 

CIH(C1a= x) would only be unique across all the DOTS clients communicating with the = DOTS gateway X but may not be globally unique (across Gateways J and K), th= e current approach would ensure no probability of client-identifier collisions.

&n= bsp;

DOTS client (C1aj) -----------= --------------------------- (S1j) DOTS gateway J (C2j) ------\  

DOTS client (C1bj) -----------= ------------------------------/       &n= bsp;            &nbs= p;         |=

     =             &nb= sp;            =              &n= bsp;            = ;            &n= bsp;            = ;          |

DOTS client (C1ax) ----- (S1x)= DOTS gateway X (C2x) ----- (S2k) DOTS gateway K (C3k) ---- (S3)  = ; 

DOTS client (C1bx) -------/&nb= sp;            =              &n= bsp;      |     &nbs= p;            &= nbsp;            

     =             &nb= sp;            =             &nb= sp;            =      |       &n= bsp;            = ;             <= o:p>

DOTS client (C1ay) ----- (S1y)= DOTS gateway Y (C2y) --------/       &n= bsp;            = ;             <= o:p>

DOTS client (C1by) -------/&nb= sp;            =              &n= bsp;            = ;            &n= bsp;            = ;   

&n= bsp;

Jon>=   If gateway K detects a collision in any of CIH(C1ax), CIH(C1bx), CIH= (C1ay) and CIH(C1by), gateway K can then add in CIH(C2x) or CIH(C2y) as app= ropriate to maintain uniqueness as seen by S3.  If there is no collision in CIH(C1ax), CIH(C1bx), CIH(C1ay) and CIH(C1by),= then these will be unique to S3 when coming from C3k.  This then pote= ntially saves some packet space and allows for scaling beyond a small numbe= r of gateways.

 

[TR] Ag= reed. I am assuming there won’t be more than 3 DOTS gateways b/w the = DOTS client and server (client-side, server-side and one additional gateway= because of recursive signalling).

As per = our discussion, DOTS signal channel draft says, a DOTS gateway “MAY&#= 8221; add the client-identifier.

&n= bsp;

-Tiru

 

&n= bsp;

Jon>= I 100% agree that we must not have any client identifier collisions.<= /o:p>

&n= bsp;

&n= bsp;

-Tiru

&nbs= p;

From:<= /span> Jon Shallow [mailto:supjps-ietf@jpshallow.com]
Sent: Saturday, November 4, 2017 4:17 PM
To: Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@McAfee.com>; dots@ietf.org
Subject: RE: [Dots] Data channel issues with GET

 

Hi Tiru= ,

&n= bsp;

Agreed = that a request from a DOTS client going through multiple DOTS gateways will= get the appropriate client-identifier added, and the response initially ge= nerated by the final DOTS server will have all the client-identifiers.

&n= bsp;

However= , as the response passes back through the DOTS gateways, the appropriate cl= ient-identifier will get stripped off and the originating DOTS client will = have no visibility of the client-identifiers – as per

“=    A DOTS gateway MUST update the 'client-identifier' list in the=

 &= nbsp; response to remove the 'client-identifier' value it had added in the<= o:p>

 &= nbsp; corresponding request before forwarding the response to the DOTS=

 &= nbsp; client.”

&n= bsp;

So, Fig= ure 6 and Figure 7 do not correctly portray the reality as seen by a DOTS c= lient (whether on a DOTS gateway or not).

&n= bsp;

When th= e DOTS Gateway client component generates the GET request should the reques= t be (to match Figure 7 response)

&n= bsp;

“=     GET /restconf/data/ietf-dots-data-channel-identifier:ide= ntifier?\

 &= nbsp;       content=3Dconfig&client-ident= ifier=3Ddz6pHjaADkaFTbjr0JGBpw,iAYmCNPmrYoKoqzgFMiobw HTTP/1.1

 &= nbsp;   Host: {host}:{port}

 &= nbsp;   Accept: application/yang-data+json<= /p>

&n= bsp;

 &= nbsp;        Figure 6: GET to retrieve a= ll the installed identifiers”

&n= bsp;

=3D=3D= =3D=3D=3D

&n= bsp;

This st= ill does not answer my implied concern – how does a DOTS gateway clie= nt request all the aliases / filters / mitigations to sync up state when, s= ay, the DOTS gateway client restarts?

- The D= OTS gateway may not know all the client-identifiers that are talking to the= server component of the DOTS gateway – they may be behind yet anothe= r DOTS gateway.

&n= bsp;

Taking = this more complex example involving multiple gateways (should it be in the = drafts somewhere for helping with client-identifier clarity?)

&n= bsp;

DOTS client (C1aj) -----------= ------------------------------ (S1j) DOTS gateway J (C2j) ----------\ =  

DOTS client (C1bj) -----------= ---------------------------------/       = ;             &= nbsp;           &nbs= p; |

     =             &nb= sp;            =              &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;    |

DOTS client (C1ax) ------- (S1= x) DOTS gateway X (C2x) ------ (S2k) DOTS gateway K (C3k) -------- (S3)&nbs= p;  

DOTS client (C1bx) ----------/=             &nb= sp;            =        |     &= nbsp;           &nbs= p;             =

     =             &nb= sp;            =             &nb= sp;            =         |    &n= bsp;            = ;             &= nbsp;  

DOTS client (C1ay) ------- (S1= y) DOTS gateway Y (C2y) ---------/       = ;            &n= bsp;            &nbs= p;

DOTS client (C1by) ----------/=             &nb= sp;            =             &n= bsp;            = ;            &n= bsp;   

     =             &nb= sp;            =             &nb= sp;            =             &nb= sp;            =             &nb= sp;    

&n= bsp;

If C3k = restarts how is he able to re-sync his information from S3?  C3K does = not have a GET ‘all’ capability with client-identifier being ab= ove the level of alias-name.  It maybe that C3k does not need to re-sync, but C3k should have the flexibility if C3k is, say, able = to cache information to reduce the number of requests having to pass all th= e way through to S3.

&n= bsp;

As an a= side, in my current implementation, where CIH(xxx) is the Client Identifier= hash of xxx

&n= bsp;

C1ax do= es a PUT (alias-name=3DServer1),

C2x doe= s a PUT (alias-name=3DServer1&client-identifer=3DCIH(C1ax)),=

C3k doe= s a PUT (alias-name=3DServer1&client-identifer=3DCIH(C1ax),CIH(C2x))

and S3 = uniquely stores this alias-name as (alias-name=3DServer1&client-identif= er=3DCIH(C1ax),CIH(C2x),CIH(C3k))

so that= if any of the DOTS clients do a PUT (alias-name=3DServer1) [with same alia= s name] S3 can differentiate them all.

&n= bsp;

As CIH(= C1ax) should be unique across all DOTS clients, do we really need to add in= all the other CIH() as the traffic passes up through to S3?

&n= bsp;

Regards=

&n= bsp;

Jon

&n= bsp;

From: Dots [mailto: dots-bounces@ietf.org] On B= ehalf Of Konda, Tirumaleswar Reddy
Sent: 04 November 2017 04:16
To: Jon Shallow; dots@ietf.org<= br> Subject: Re: [Dots] Data channel issues with GET

 

Hi Jon,

&nbs= p;

GET reque= st will only retrieve the alias-names installed by a DOTS client and not th= e alias-names for all the DOTS clients. The client-identifier array is uniq= uely identifying the DOTS client and does not need be repeated for every alias-name conveyed by the client. &nb= sp;Figure 6 is showing the GET request from the DOTS client, and the DOTS g= ateways will update the GET request to add and update the client-identifier= array.

I donR= 17;t think the client-identifier should be in the same level as alias-name.

&nbs= p;

-Tiru

&nbs= p;

From:<= /span> Dots [mailto:dots-bounces@ietf.org] On Behalf Of Jon Shallow
Sent: Saturday, November 4, 2017 3:03 AM
To: dots@ietf.org
Subject: [Dots] Data channel issues with GET

 

Hi Tiru et al,

 

I am having challenges coding u= p the GET for channel identifiers.

 

A DOTS Client as part of a DOTS= gateway can use different client-identifiers when doing a PUT for the alia= s-name.   The DOTS server will therefore have multiple client-ide= ntifier arrays for the DOTS GW client.

 

However when doing a GET using = ‘content=3Dconfig’, as things currently stand, only one client-= identifier array can returned as per the below in Figure 7:-

 

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<= /span>

 

“3.2.3.  Retrieving = Installed Identifiers

 

   A GET request is u= sed to retrieve the set of installed identifiers

   from a DOTS server= (Section 3.3.1 in [RFC8040]).  Figure 6 shows how

   to retrieve all th= e identifiers that were instantiated by the DOTS

   client.  The = content parameter and its permitted values are defined

   in Section 4.8.1 o= f [RFC8040].

 

     GET /r= estconf/data/ietf-dots-data-channel-identifier:identifier?\

     &= nbsp;   content=3Dconfig HTTP/1.1

     Host: = {host}:{port}

     Accept= : application/yang-data+json

 

     &= nbsp;    Figure 6: GET to retrieve all the installed identif= iers

 

   Figure 7 shows res= ponse for all identifiers on the DOTS server.

 

   {

    "ietf-d= ots-data-channel-identifier:identifier": {

     &= nbsp; "client-identifier": [

     &= nbsp;    "dz6pHjaADkaFTbjr0JGBpw",

     &= nbsp;    "iAYmCNPmrYoKoqzgFMiobw"

     &= nbsp; ],

     &= nbsp; "alias": [

     &= nbsp;   {

     &= nbsp;     "alias-name": "Server1",<= o:p>

     &= nbsp;     "traffic-protocol": [

     &= nbsp;       6”

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D

 

I think that the yang model nee= ds to be re-written, by moving leaf-list client-identifier down to the same= level as alias-name as :-

 

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D

     contai= ner identifier {

     &= nbsp;    description "Top level container for identifie= rs";

 

     &= nbsp;        list alias {

     &= nbsp;           &nbs= p; key alias-name;

     &= nbsp;            &nb= sp;description "List of identifiers";

 

     &= nbsp;           &nbs= p; leaf alias-name {

     &= nbsp;           &nbs= p;    type string;

     &= nbsp;           &nbs= p;    description "alias name";<= /p>

     &= nbsp;           &nbs= p; }

 

     &= nbsp;           &nbs= p; leaf-list client-identifier {

     &= nbsp;           &nbs= p;    type binary;

     &= nbsp;           &nbs= p;    description  "A client identifier conveyed b= y a DOTS gateway

     &= nbsp;           &nbs= p;            &= nbsp;     to a remote DOTS server.";

 

     &= nbsp;           &nbs= p;    reference

     &= nbsp;           &nbs= p;       "I-D.itef-dots-signal-channel&q= uot;;

     &= nbsp;           &nbs= p; }

 

     &= nbsp;           &nbs= p; leaf-list target-ip {

 

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D

 

And reflected appropriately thr= oughout the data channel draft.

 

The issue is the same for the a= ccess control list – client-identifier needs to be at the same level = as acl-name

 

module: ietf-dots-access-contro= l-list

  augment /ietf-acl:access= -lists:

    +--rw cl= ient-identifier*   binary

 

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D

Needs to be

 

module: ietf-dots-access-contro= l-list

  augment /ietf-acl:access= -lists/ietf-acl:acl/:

    +--rw cl= ient-identifier*   binary

 

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D

 

And replicated as appropriate t= hroughout the draft

 

Regards

 

Jon

--_000_DM5PR16MB178813CB8A56B2B9AC31CFC1EA520DM5PR16MB1788namp_-- From nobody Sat Nov 4 09:27:48 2017 Return-Path: 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 38B0A13FB7D for ; Sat, 4 Nov 2017 09:27:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 Z-NbdL3xI4mC for ; Sat, 4 Nov 2017 09:27:43 -0700 (PDT) Received: from mail.jpshallow.com (mail.jpshallow.com [217.40.240.153]) (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 8C09613FB71 for ; Sat, 4 Nov 2017 09:27:42 -0700 (PDT) Received: from [127.0.0.1] (helo=N01332) by mail.jpshallow.com with smtps (TLSv1:ECDHE-RSA-AES256-SHA:256) (Exim 4.89) (envelope-from ) id 1eB1IK-0000VA-Qh; Sat, 04 Nov 2017 16:27:41 +0000 From: "Jon Shallow" To: "'Konda, Tirumaleswar Reddy'" , References: <06f601d354eb$482cce20$d8866a60$@jpshallow.com> <075801d3555a$34dbbd30$9e933790$@jpshallow.com> <07c101d3557c$70035a90$500a0fb0$@jpshallow.com> In-Reply-To: Date: Sat, 4 Nov 2017 16:27:41 -0000 Message-ID: <07e901d35589$d6519e30$82f4da90$@jpshallow.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_07EA_01D35589.D6556EC0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQGq3C7tF9zj9qMEJcmaXbDvWUqFfQEpBvoXAuZQ++ICVTWFigEezdBqANxQsJOjElvS4A== Content-Language: en-gb Archived-At: Subject: Re: [Dots] Data channel issues with GET 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Nov 2017 16:27:46 -0000 This is a multipart message in MIME format. ------=_NextPart_000_07EA_01D35589.D6556EC0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Tiru, I agree that there is a MAY in "client-identifier: The client identifier MAY be conveyed by the DOTS gateway to propagate the DOTS client identity from the gateway's client-side to the gateway's server-side, and from the gateway's server-side to the DOTS server." But the following implies it has to be done, even though there is not a MUST - MAY should be included (as in '., the DOTS gateway MAY compute the 'client-identifier' value, as discussed above, and add the computed ." I think. "If the 'client-identifier' value is already present in the mitigation request received from the DOTS client, the DOTS gateway computes the 'client-identifier' value, as discussed above, and adds the computed 'client-identifier' value to the end of the 'client-identifier' list." Regards Jon From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of Konda, Tirumaleswar Reddy Sent: 04 November 2017 15:22 To: Jon Shallow; dots@ietf.org Subject: Re: [Dots] Data channel issues with GET Hi Jon, Please see inline [TR] From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Jon Shallow Sent: Saturday, November 4, 2017 8:22 PM To: Konda, Tirumaleswar Reddy ; dots@ietf.org Subject: Re: [Dots] Data channel issues with GET Hi Tiru See 3 comments inline Regards Jon From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of Konda, Tirumaleswar Reddy Sent: 04 November 2017 14:29 To: Jon Shallow; dots@ietf.org Subject: Re: [Dots] Data channel issues with GET Hi Jon, The DOTS gateway (C3k) does not send any requests on its own to the DOTS server (S3). As per the discussion of DOTS gateways in https://tools.ietf.org/html/draft-ietf-dots-architecture-05, it's only relaying the messages from the downstream and upstream agents. The DOTS architecture does not discuss DOTS gateway acting as a caching server. Jon> OK - I will see if further implementation throws anything else up on this - if not, I will leave it as it stands CIH(C1ax) would only be unique across all the DOTS clients communicating with the DOTS gateway X but may not be globally unique (across Gateways J and K), the current approach would ensure no probability of client-identifier collisions. DOTS client (C1aj) -------------------------------------- (S1j) DOTS gateway J (C2j) ------\ DOTS client (C1bj) -----------------------------------------/ | | DOTS client (C1ax) ----- (S1x) DOTS gateway X (C2x) ----- (S2k) DOTS gateway K (C3k) ---- (S3) DOTS client (C1bx) -------/ | | DOTS client (C1ay) ----- (S1y) DOTS gateway Y (C2y) --------/ DOTS client (C1by) -------/ Jon> If gateway K detects a collision in any of CIH(C1ax), CIH(C1bx), CIH(C1ay) and CIH(C1by), gateway K can then add in CIH(C2x) or CIH(C2y) as appropriate to maintain uniqueness as seen by S3. If there is no collision in CIH(C1ax), CIH(C1bx), CIH(C1ay) and CIH(C1by), then these will be unique to S3 when coming from C3k. This then potentially saves some packet space and allows for scaling beyond a small number of gateways. [TR] Agreed. I am assuming there won't be more than 3 DOTS gateways b/w the DOTS client and server (client-side, server-side and one additional gateway because of recursive signalling). As per our discussion, DOTS signal channel draft says, a DOTS gateway "MAY" add the client-identifier. -Tiru Jon> I 100% agree that we must not have any client identifier collisions. -Tiru From: Jon Shallow [mailto:supjps-ietf@jpshallow.com] Sent: Saturday, November 4, 2017 4:17 PM To: Konda, Tirumaleswar Reddy ; dots@ietf.org Subject: RE: [Dots] Data channel issues with GET Hi Tiru, Agreed that a request from a DOTS client going through multiple DOTS gateways will get the appropriate client-identifier added, and the response initially generated by the final DOTS server will have all the client-identifiers. However, as the response passes back through the DOTS gateways, the appropriate client-identifier will get stripped off and the originating DOTS client will have no visibility of the client-identifiers - as per " A DOTS gateway MUST update the 'client-identifier' list in the response to remove the 'client-identifier' value it had added in the corresponding request before forwarding the response to the DOTS client." So, Figure 6 and Figure 7 do not correctly portray the reality as seen by a DOTS client (whether on a DOTS gateway or not). When the DOTS Gateway client component generates the GET request should the request be (to match Figure 7 response) " GET /restconf/data/ietf-dots-data-channel-identifier:identifier?\ content=config&client-identifier=dz6pHjaADkaFTbjr0JGBpw,iAYmCNPmrYoKoqzgFMio bw HTTP/1.1 Host: {host}:{port} Accept: application/yang-data+json Figure 6: GET to retrieve all the installed identifiers" ===== This still does not answer my implied concern - how does a DOTS gateway client request all the aliases / filters / mitigations to sync up state when, say, the DOTS gateway client restarts? - The DOTS gateway may not know all the client-identifiers that are talking to the server component of the DOTS gateway - they may be behind yet another DOTS gateway. Taking this more complex example involving multiple gateways (should it be in the drafts somewhere for helping with client-identifier clarity?) DOTS client (C1aj) ----------------------------------------- (S1j) DOTS gateway J (C2j) ----------\ DOTS client (C1bj) --------------------------------------------/ | | DOTS client (C1ax) ------- (S1x) DOTS gateway X (C2x) ------ (S2k) DOTS gateway K (C3k) -------- (S3) DOTS client (C1bx) ----------/ | | DOTS client (C1ay) ------- (S1y) DOTS gateway Y (C2y) ---------/ DOTS client (C1by) ----------/ If C3k restarts how is he able to re-sync his information from S3? C3K does not have a GET 'all' capability with client-identifier being above the level of alias-name. It maybe that C3k does not need to re-sync, but C3k should have the flexibility if C3k is, say, able to cache information to reduce the number of requests having to pass all the way through to S3. As an aside, in my current implementation, where CIH(xxx) is the Client Identifier hash of xxx C1ax does a PUT (alias-name=Server1), C2x does a PUT (alias-name=Server1&client-identifer=CIH(C1ax)), C3k does a PUT (alias-name=Server1&client-identifer=CIH(C1ax),CIH(C2x)) and S3 uniquely stores this alias-name as (alias-name=Server1&client-identifer=CIH(C1ax),CIH(C2x),CIH(C3k)) so that if any of the DOTS clients do a PUT (alias-name=Server1) [with same alias name] S3 can differentiate them all. As CIH(C1ax) should be unique across all DOTS clients, do we really need to add in all the other CIH() as the traffic passes up through to S3? Regards Jon From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of Konda, Tirumaleswar Reddy Sent: 04 November 2017 04:16 To: Jon Shallow; dots@ietf.org Subject: Re: [Dots] Data channel issues with GET Hi Jon, GET request will only retrieve the alias-names installed by a DOTS client and not the alias-names for all the DOTS clients. The client-identifier array is uniquely identifying the DOTS client and does not need be repeated for every alias-name conveyed by the client. Figure 6 is showing the GET request from the DOTS client, and the DOTS gateways will update the GET request to add and update the client-identifier array. I don't think the client-identifier should be in the same level as alias-name. -Tiru From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Jon Shallow Sent: Saturday, November 4, 2017 3:03 AM To: dots@ietf.org Subject: [Dots] Data channel issues with GET Hi Tiru et al, I am having challenges coding up the GET for channel identifiers. A DOTS Client as part of a DOTS gateway can use different client-identifiers when doing a PUT for the alias-name. The DOTS server will therefore have multiple client-identifier arrays for the DOTS GW client. However when doing a GET using 'content=config', as things currently stand, only one client-identifier array can returned as per the below in Figure 7:- =============================== "3.2.3. Retrieving Installed Identifiers A GET request is used to retrieve the set of installed identifiers from a DOTS server (Section 3.3.1 in [RFC8040]). Figure 6 shows how to retrieve all the identifiers that were instantiated by the DOTS client. The content parameter and its permitted values are defined in Section 4.8.1 of [RFC8040]. GET /restconf/data/ietf-dots-data-channel-identifier:identifier?\ content=config HTTP/1.1 Host: {host}:{port} Accept: application/yang-data+json Figure 6: GET to retrieve all the installed identifiers Figure 7 shows response for all identifiers on the DOTS server. { "ietf-dots-data-channel-identifier:identifier": { "client-identifier": [ "dz6pHjaADkaFTbjr0JGBpw", "iAYmCNPmrYoKoqzgFMiobw" ], "alias": [ { "alias-name": "Server1", "traffic-protocol": [ 6" =========== I think that the yang model needs to be re-written, by moving leaf-list client-identifier down to the same level as alias-name as :- =========== container identifier { description "Top level container for identifiers"; list alias { key alias-name; description "List of identifiers"; leaf alias-name { type string; description "alias name"; } leaf-list client-identifier { type binary; description "A client identifier conveyed by a DOTS gateway to a remote DOTS server."; reference "I-D.itef-dots-signal-channel"; } leaf-list target-ip { ================ And reflected appropriately throughout the data channel draft. The issue is the same for the access control list - client-identifier needs to be at the same level as acl-name module: ietf-dots-access-control-list augment /ietf-acl:access-lists: +--rw client-identifier* binary ============= Needs to be module: ietf-dots-access-control-list augment /ietf-acl:access-lists/ietf-acl:acl/: +--rw client-identifier* binary =============== And replicated as appropriate throughout the draft Regards Jon ------=_NextPart_000_07EA_01D35589.D6556EC0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Tiru,

 

I agree that there is a = MAY in

 

“client-identifier:  The client = identifier MAY be conveyed by the DOTS

      gateway to = propagate the DOTS client identity from the = gateway's

      client-side to = the gateway's server-side, and from the = gateway's

      server-side to = the DOTS server.”

 

But the following = implies it has to be done, even though there is not a MUST – MAY = should be included (as in ‘…, the DOTS gateway MAY compute = the 'client-identifier' value, as discussed above, and add the computed = …” I think.

 

“If = the

   'client-identifier' value is = already present in the mitigation

   request = received from the DOTS client, the DOTS gateway computes = the

   'client-identifier' value, as = discussed above, and adds the computed

   = 'client-identifier' value to the end of the 'client-identifier' = list.”

 

Regards

 

Jon

 

From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of = Konda, Tirumaleswar Reddy
Sent: 04 November 2017 = 15:22
To: Jon Shallow; dots@ietf.org
Subject: Re: = [Dots] Data channel issues with GET

 

Hi = Jon,

 

Please see inline = [TR]

 

From: Dots [mailto:dots-bounces@ietf.org] = On Behalf Of Jon Shallow
Sent: Saturday, November 4, = 2017 8:22 PM
To: Konda, Tirumaleswar Reddy <TirumaleswarReddy_Kond= a@McAfee.com>; dots@ietf.org
Subject: Re: = [Dots] Data channel issues with GET

 

Hi = Tiru

 

See 3 comments = inline

 

Regards

 

Jon

 

From: Dots [mailto: dots-bounces@ietf.org] On = Behalf Of Konda, Tirumaleswar Reddy
Sent: 04 November 2017 = 14:29
To: Jon Shallow; dots@ietf.org
Subject: Re: = [Dots] Data channel issues with GET

 

Hi = Jon,

 

The DOTS gateway (C3k) does not = send any requests on its own to the DOTS server (S3).  As per the = discussion of DOTS gateways in http= s://tools.ietf.org/html/draft-ietf-dots-architecture-05, it’s = only relaying the messages from the downstream and upstream agents. The = DOTS architecture does not discuss DOTS gateway acting as a caching = server.

 

Jon> OK – I = will see if further implementation throws anything else up on this = – if not, I will leave it as it stands

 

CIH(C1ax) would only be = unique across all the DOTS clients communicating with the DOTS gateway X = but may not be globally unique (across Gateways J and K), the current = approach would ensure no probability of client-identifier = collisions.

 

DOTS client (C1aj) = -------------------------------------- (S1j) DOTS gateway J (C2j) = ------\  

DOTS = client (C1bj) = -----------------------------------------/     &= nbsp;           &n= bsp; =            |<= /o:p>

         = ;            =             &= nbsp;   =             &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;     |

DOTS client (C1ax) ----- (S1x) DOTS gateway X (C2x) = ----- (S2k) DOTS gateway K (C3k) ---- (S3)    =

DOTS = client (C1bx) = -------/           = ;            =    =        |     =             &= nbsp;          =    

         = ;            =             &= nbsp;           &n= bsp;           &nb= sp;  |         &nb= sp;           &nbs= p;      =      

DOTS client (C1ay) ----- (S1y) DOTS gateway Y (C2y) = --------/          &nbs= p;            = ;    =       

DOTS client (C1by) = -------/           = ;            =    =             &= nbsp;           &n= bsp;           &nb= sp;    

 

Jon>  If gateway = K detects a collision in any of CIH(C1ax), CIH(C1bx), CIH(C1ay) and = CIH(C1by), gateway K can then add in CIH(C2x) or CIH(C2y) as appropriate = to maintain uniqueness as seen by S3.  If there is no collision in = CIH(C1ax), CIH(C1bx), CIH(C1ay) and CIH(C1by), then these will be unique = to S3 when coming from C3k.  This then potentially saves some = packet space and allows for scaling beyond a small number of = gateways.

 

[TR] Agreed. I am assuming there won’t be = more than 3 DOTS gateways b/w the DOTS client and server (client-side, = server-side and one additional gateway because of recursive signalling). =

As per our discussion, DOTS signal channel draft = says, a DOTS gateway “MAY” add the client-identifier. =

 

-Tiru

 

 

Jon> I 100% agree = that we must not have any client identifier = collisions.

 

 

-Tiru

 

From: Jon Shallow [mailto:supjps-ietf@jpshallow.co= m]
Sent: Saturday, November 4, 2017 4:17 PM
To: = Konda, Tirumaleswar Reddy <TirumaleswarReddy_Kond= a@McAfee.com>; dots@ietf.org
Subject: RE: = [Dots] Data channel issues with GET

 

Hi = Tiru,

 

Agreed that a request = from a DOTS client going through multiple DOTS gateways will get the = appropriate client-identifier added, and the response initially = generated by the final DOTS server will have all the = client-identifiers.

 

However, as the response = passes back through the DOTS gateways, the appropriate client-identifier = will get stripped off and the originating DOTS client will have no = visibility of the client-identifiers – as = per

“   A DOTS gateway MUST update = the 'client-identifier' list in the

   response to = remove the 'client-identifier' value it had added in = the

   corresponding request before = forwarding the response to the DOTS

   = client.”

 

So, Figure 6 and Figure = 7 do not correctly portray the reality as seen by a DOTS client (whether = on a DOTS gateway or not).

 

When the DOTS Gateway = client component generates the GET request should the request be (to = match Figure 7 response)

 

“    GET = /restconf/data/ietf-dots-data-channel-identifier:identifier?\<= /span>

         = content=3Dconfig&client-identifier=3Ddz6pHjaADkaFTbjr0JGBpw,iAYmCNPmr= YoKoqzgFMiobw HTTP/1.1

     Host: = {host}:{port}

     Accept: = application/yang-data+json

 

        &= nbsp; Figure 6: GET to retrieve all the installed = identifiers”

 

=3D=3D=3D=3D=3D

 

This still does not = answer my implied concern – how does a DOTS gateway client request = all the aliases / filters / mitigations to sync up state when, say, the = DOTS gateway client restarts?

- The DOTS gateway may = not know all the client-identifiers that are talking to the server = component of the DOTS gateway – they may be behind yet another = DOTS gateway.

 

Taking this more complex = example involving multiple gateways (should it be in the drafts = somewhere for helping with client-identifier = clarity?)

 

DOTS client (C1aj) = ----------------------------------------- (S1j) DOTS gateway J (C2j) = ----------\  

DOTS = client (C1bj) = --------------------------------------------/    &nbs= p;            = ;  =             &= nbsp;  |

         = ;            =             &= nbsp;    =             &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;           |

DOTS = client (C1ax) ------- (S1x) DOTS gateway X (C2x) ------ (S2k) DOTS = gateway K (C3k) -------- (S3)   

DOTS client (C1bx) = ----------/          &n= bsp;           &nb= sp;   =        |     =             &= nbsp;          =    

         = ;            =             &= nbsp;           &n= bsp;           &nb= sp;     |      &nb= sp;           &nbs= p;         =      

DOTS client (C1ay) ------- (S1y) DOTS gateway Y = (C2y) = ---------/          &nb= sp;           &nbs= p;    =       

DOTS client (C1by) = ----------/          &n= bsp;           &nb= sp;   =             &= nbsp;           &n= bsp;           &nb= sp;    

         = ;            =             &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;            = ;            =    

 

If C3k restarts how is = he able to re-sync his information from S3?  C3K does not have a = GET ‘all’ capability with client-identifier being above the = level of alias-name.  It maybe that C3k does not need to re-sync, = but C3k should have the flexibility if C3k is, say, able to cache = information to reduce the number of requests having to pass all the way = through to S3.

 

As an aside, in my = current implementation, where CIH(xxx) is the Client Identifier hash of = xxx

 

C1ax does a PUT = (alias-name=3DServer1),

C2x does a PUT = (alias-name=3DServer1&client-identifer=3DCIH(C1ax)),

C3k does a PUT = (alias-name=3DServer1&client-identifer=3DCIH(C1ax),CIH(C2x))

and S3 = uniquely stores this alias-name as = (alias-name=3DServer1&client-identifer=3DCIH(C1ax),CIH(C2x),CIH(C3k))=

so that if any of the DOTS clients do a PUT = (alias-name=3DServer1) [with same alias name] S3 can differentiate them = all.

 

As CIH(C1ax) should be = unique across all DOTS clients, do we really need to add in all the = other CIH() as the traffic passes up through to = S3?

 

Regards

 

Jon

 

From: Dots [mailto: dots-bounces@ietf.org] On = Behalf Of Konda, Tirumaleswar Reddy
Sent: 04 November 2017 = 04:16
To: Jon Shallow; dots@ietf.org
Subject: Re: = [Dots] Data channel issues with GET

 

Hi = Jon,

 

GET request will only retrieve the = alias-names installed by a DOTS client and not the alias-names for all = the DOTS clients. The client-identifier array is uniquely identifying = the DOTS client and does not need be repeated for every alias-name = conveyed by the client.  Figure 6 is showing the GET request from = the DOTS client, and the DOTS gateways will update the GET request to = add and update the client-identifier array.

I don’t think the = client-identifier should be in the same level as alias-name. =

 

-Tiru

 

From: Dots [mailto:dots-bounces@ietf.org] = On Behalf Of Jon Shallow
Sent: Saturday, November 4, = 2017 3:03 AM
To: dots@ietf.org
Subject: = [Dots] Data channel issues with GET

 

Hi Tiru et al,

 

I am having = challenges coding up the GET for channel identifiers.

 

A DOTS = Client as part of a DOTS gateway can use different client-identifiers = when doing a PUT for the alias-name.   The DOTS server will = therefore have multiple client-identifier arrays for the DOTS GW = client.

 

However when doing a GET using = ‘content=3Dconfig’, as things currently stand, only one = client-identifier array can returned as per the below in Figure = 7:-

 

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

 

“3.2.3.  Retrieving Installed = Identifiers

 

   A GET request is used to retrieve the set = of installed identifiers

   = from a DOTS server (Section 3.3.1 in [RFC8040]).  Figure 6 shows = how

   to retrieve all the = identifiers that were instantiated by the DOTS

   client.  The content parameter and = its permitted values are defined

   in Section 4.8.1 of = [RFC8040].

 

     GET = /restconf/data/ietf-dots-data-channel-identifier:identifier?\<= /p>

         = content=3Dconfig HTTP/1.1

     Host: = {host}:{port}

     Accept: = application/yang-data+json

 

          = Figure 6: GET to retrieve all the installed identifiers

 

   = Figure 7 shows response for all identifiers on the DOTS = server.

 

   {

    = "ietf-dots-data-channel-identifier:identifier": = {

       = "client-identifier": [

          = "dz6pHjaADkaFTbjr0JGBpw",

          = "iAYmCNPmrYoKoqzgFMiobw"

       = ],

       = "alias": [

         = {

         &= nbsp; "alias-name": "Server1",

         &= nbsp; "traffic-protocol": [

         &= nbsp;   6”

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

 

I think that = the yang model needs to be re-written, by moving leaf-list = client-identifier down to the same level as alias-name as = :-

 

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

     container identifier = {

          = description "Top level container for = identifiers";

 

         &= nbsp;    list alias {

         &= nbsp;         key = alias-name;

          =          description = "List of identifiers";

 

         &= nbsp;         leaf alias-name = {

         &= nbsp;            = type string;

         &= nbsp;            = description "alias name";

         &= nbsp;         }

 

         &= nbsp;         leaf-list = client-identifier {

         &= nbsp;            = type binary;

         &= nbsp;            = description  "A client identifier conveyed by a DOTS = gateway

         &= nbsp;           &n= bsp;           &nb= sp;  to a remote DOTS server.";

 

         &= nbsp;            = reference

         &= nbsp;           &n= bsp;   = "I-D.itef-dots-signal-channel";

         &= nbsp;         }

 

         &= nbsp;         leaf-list = target-ip {

 

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

 

And reflected appropriately throughout the data = channel draft.

 

The issue is = the same for the access control list – client-identifier needs to = be at the same level as acl-name

 

module: = ietf-dots-access-control-list

  = augment /ietf-acl:access-lists:

    +--rw = client-identifier*   binary

 

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

<= p class=3DMsoNormal>Needs to be

 

module: = ietf-dots-access-control-list

  = augment /ietf-acl:access-lists/ietf-acl:acl/:

    +--rw = client-identifier*   binary

 

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

 

And = replicated as appropriate throughout the draft

 

Regards

 

Jon

------=_NextPart_000_07EA_01D35589.D6556EC0-- From nobody Sat Nov 4 09:32:09 2017 Return-Path: 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 D143313FB8F for ; Sat, 4 Nov 2017 09:32:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 GZyaajFyfafC for ; Sat, 4 Nov 2017 09:32:04 -0700 (PDT) Received: from mail.jpshallow.com (mail.jpshallow.com [217.40.240.153]) (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 8A5FF13FB8E for ; Sat, 4 Nov 2017 09:32:04 -0700 (PDT) Received: from [127.0.0.1] (helo=N01332) by mail.jpshallow.com with smtps (TLSv1:ECDHE-RSA-AES256-SHA:256) (Exim 4.89) (envelope-from ) id 1eB1MY-0000VZ-NA; Sat, 04 Nov 2017 16:32:02 +0000 From: "Jon Shallow" To: "'Konda, Tirumaleswar Reddy'" , "Roland Dobbins" , , References: In-Reply-To: Date: Sat, 4 Nov 2017 16:32:03 -0000 Message-ID: <07ff01d3558a$726a8e30$573faa90$@jpshallow.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0800_01D3558A.726BEDC0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQEyXr0bQ4xr8pPaX7wAIbBvT5xlH6RC6AnA Content-Language: en-gb Archived-At: Subject: Re: [Dots] New DOTS signal and data channel requirements 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Nov 2017 16:32:07 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0800_01D3558A.726BEDC0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi there, =20 As I am moving back into getting the data channel functionally up and = running, I need to revisit this =E2=80=93 in particular something else = that was in that original email thread just after what Tiru has quoted = below. =20 =E2=80=9CEven if the Filters are held on a per client identity basis, = there no way to upload a set of different filters in peace time ready = for selection as to which is be used in case of DDoS Attack. = White/Black lists are probably fairly static, it is the customizable = filters that are the issue currently for me.=E2=80=9D=20 =20 Do we need to be able to add in selectable ACL support? =20 Client-identifier is now supported in = ietf-dots-access-control-list:access-lists, so filters / acls are now = maintainable on a per original DOTS client basis. =20 If a DOTS client defines multiple acls (e.g. white list, black list and = custom acls), there is now the possibility of them being sent to the = DOTS mitigator in a sorted order. = https://datatracker.ietf.org/doc/draft-ietf-netmod-acl-model/ has added = =E2=80=9Cinterfaces=E2=80=9D under =E2=80=9Caccess-lists=E2=80=9D, and = under =E2=80=9Cinterfaces=E2=80=9D is =E2=80=9Cingress=E2=80=9D where = you can define an ordered set of =E2=80=9Cacl-sets=E2=80=9D in which = each =E2=80=9Cset-name=E2=80=9D refers back to the = =E2=80=9Cacl-name=E2=80=9D sitting under =E2=80=9Cacl=E2=80=9D, sitting = under =E2=80=9Caccess-lists=E2=80=9D. =20 module: ietf-access-control-list +--rw access-lists +--rw acl* [acl-type acl-name] | +--rw acl-name string =E2=80=A6 +--rw interfaces +--rw interface* [interface-id] +--rw interface-id if:interface-ref +--rw ingress | +--rw acl-sets | +--rw acl-set* [set-name type] | +--rw set-name -> = ../../../../../../acl/acl-name =E2=80=A6 =20 However, for each DOTS client, we can only have one = ietf-dots-access-control-list which only allows for one = ietf-access-control-list. So it not possible to build up a library of = different acls, one of which can be selected by the DOTS client as a = =E2=80=9Chint=E2=80=9D to get forwarded onto the DOTS mitigator. = During times of attack, it may be difficult / impossible to update the = acl because of TCP failures. =20 I agree that we cannot expect there to be much intelligence in the DOTS = client. However in DOTS use cases, =E2=80=9C3.1.1. End-customer with a = single upstream transit provider offering DDoS mitigation = services=E2=80=9D there is reference to the customer having an = intelligent DDoS Mitigation system (IDMS). This IDMS could give = =E2=80=9Chints=E2=80=9D. =20 The DOTS signal mitigate protocol supports alias-names, but not filters = or acls. We could 1) Add in filter invoking support into the DOTS signal mitigate = protocol and extend ietf-dots-access-control-list 2) Extend the alias definition in the data channel definitions to = include other parameters supported by netmod-acl-model =20 Ideas / suggestions? =20 Regards =20 Jon =20 =20 =20 =20 =20 From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of Konda, = Tirumaleswar Reddy Sent: 10 October 2017 13:22 To: Jon Shallow; mohamed.boucadair@orange.com; dots@ietf.org; Roland = Dobbins Subject: [Dots] New DOTS signal and data channel requirements =20 Starting a new thread to discuss the below new requirement from Jon: =20 [Jon] I have re-read the requirements / architecture drafts. I agree = that currently the White/Black/Filter definitions have no dependency on = the mitigation request =E2=80=93 it is up to the DOTS server (GW or not) = as to how the White/Black/Filter definitions get passed on to DOTS = mitigator (out of spec), but the DOTS server needs to know which of the = White/Black/Filter definitions are relevant when a mitigation request = comes in. Currently, it is possible for the DOTS Server to hold = White/Black/Filter definitions on a per client identity. When the = White/Black/Filter definitions are passed from a GW Client side to a GW = server side and on to the next DOTS server, GW server side has to convey = also something about the clients on the GW client side for the DOTS = server to maintain the White/Black/Filter definitions on a per pseudo = =E2=80=9Cclient identity=E2=80=9D =E2=80=93 so when the migration = request is passed to the DOS server via a GW it knows what = White/Black/Filter definitions to apply to that mitigation request. =20 -Tiru =20 ------=_NextPart_000_0800_01D3558A.726BEDC0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Hi there,

 

As I am moving back into getting the data channel functionally up and = running, I need to revisit this =E2=80=93 in particular something else = that was in that original email thread just after what Tiru has quoted = below.

 

=E2=80=9CEven if the Filters are held on a per client identity basis, there no = way to upload a set of different filters in peace time ready for = selection as to which is be used in case of DDoS Attack.  = White/Black lists are probably fairly static, it is the customizable = filters that are the issue currently for me.=E2=80=9D =

 

Do we need to be able to add in selectable ACL = support?

 

Client-identifier is now supported in = ietf-dots-access-control-list:access-lists, so filters / acls are now = maintainable on a per original DOTS client = basis.

 

If a DOTS client defines multiple acls (e.g. white list, black list = and custom acls), there is now the possibility of them being sent to the = DOTS mitigator in a sorted order. =C2=A0ht= tps://datatracker.ietf.org/doc/draft-ietf-netmod-acl-model/ has = added =E2=80=9Cinterfaces=E2=80=9D under =E2=80=9Caccess-lists=E2=80=9D, = and under =E2=80=9Cinterfaces=E2=80=9D is =E2=80=9Cingress=E2=80=9D = where you can define an ordered set of =E2=80=9Cacl-sets=E2=80=9D in = which each =E2=80=9Cset-name=E2=80=9D refers back to the = =E2=80=9Cacl-name=E2=80=9D sitting under =E2=80=9Cacl=E2=80=9D, sitting = under =E2=80=9Caccess-lists=E2=80=9D.

 

module: = ietf-access-control-list

=C2=A0=C2=A0=C2=A0=C2=A0 +--rw = access-lists

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 +--rw = acl* [acl-type acl-name]

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0 = +--rw acl-name=C2=A0=C2=A0=C2=A0 string

=E2=80=A6

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0+--rw = interfaces

=C2=A0=C2=A0 = =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0+--rw interface* = [interface-id]

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 +--rw interface-id=C2=A0=C2=A0=C2=A0 = if:interface-ref

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 +--rw ingress

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0 +--rw acl-sets

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0 +--rw acl-set* = [set-name type]

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 = +--rw set-name=C2=A0=C2=A0=C2=A0 -> = ../../../../../../acl/acl-name

=E2=80=A6

 

However, for each DOTS client, we can only have one = ietf-dots-access-control-list which only allows for one = ietf-access-control-list.=C2=A0 So it not possible to build up a library = of different acls, one of which can be selected by the DOTS client as a = =E2=80=9Chint=E2=80=9D to get forwarded onto =C2=A0the DOTS = mitigator.=C2=A0 During times of attack, it may be difficult / = impossible to update the acl because of TCP = failures.

 

I agree that we cannot expect there to be much intelligence in the = DOTS client.=C2=A0 However in DOTS use cases, =E2=80=9C3.1.1.=C2=A0 = End-customer with a single upstream transit provider offering DDoS = mitigation services=E2=80=9D there is reference to the customer having = an intelligent DDoS Mitigation system (IDMS).=C2=A0 This IDMS could give = =E2=80=9Chints=E2=80=9D.

 

The DOTS signal mitigate protocol supports alias-names, but not = filters or acls.=C2=A0 We could

1)      = Add in filter invoking support into the DOTS signal mitigate protocol = and extend ietf-dots-access-control-list

2)      = Extend the alias definition in the data channel definitions to = include other parameters supported by = netmod-acl-model

 

Ideas / suggestions?

 

Regards

 

Jon

 

 

 

 

 

From:= Dots = [mailto: dots-bounces@ietf.org] On Behalf Of Konda, Tirumaleswar = Reddy
Sent: 10 October 2017 13:22
To: Jon Shallow; = mohamed.boucadair@orange.com; dots@ietf.org; Roland = Dobbins
Subject: [Dots] New DOTS signal and data channel = requirements

 

Starting a new thread to discuss the below new requirement from = Jon:

 

[Jon] I have re-read the requirements / architecture drafts.  I = agree that currently the White/Black/Filter definitions have no = dependency on the mitigation request =E2=80=93 it is up to the DOTS = server (GW or not) as to how the White/Black/Filter definitions get = passed on to DOTS mitigator (out of spec), but the DOTS server needs to = know which of the White/Black/Filter definitions are relevant when a = mitigation request comes in.  Currently, it is possible for the = DOTS Server to hold White/Black/Filter definitions on a per client = identity.  When the White/Black/Filter definitions are passed from = a GW Client side to a GW server side and on to the next DOTS server, GW = server side has to convey also something about the clients on the GW = client side for the DOTS server to maintain the White/Black/Filter = definitions on a per pseudo =E2=80=9Cclient identity=E2=80=9D =E2=80=93 = so when the migration request is passed to the DOS server via a GW it = knows what White/Black/Filter definitions to apply to that mitigation = request.

 

-Tiru

 

------=_NextPart_000_0800_01D3558A.726BEDC0-- From nobody Sun Nov 5 17:40:55 2017 Return-Path: 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 A570313FB13 for ; Sun, 5 Nov 2017 17:40:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 BMvW7HG-VLpI for ; Sun, 5 Nov 2017 17:40:52 -0800 (PST) Received: from guri.nttv6.jp (guri.nttv6.jp [IPv6:2402:c800:ff06:136::140]) by ietfa.amsl.com (Postfix) with ESMTP id 8FFF713FB94 for ; Sun, 5 Nov 2017 17:40:52 -0800 (PST) Received: from z.nttv6.jp (z.nttv6.jp [IPv6:2402:c800:ff06:6::f]) by guri.nttv6.jp (NTTv6MTA) with ESMTP id E72E325F68D for ; Mon, 6 Nov 2017 10:40:50 +0900 (JST) Received: from SR2-nishizuka.local (fujiko.nttv6.jp [IPv6:2402:c800:ff06:136::141]) by z.nttv6.jp (NTTv6MTA) with ESMTP id C845475904A for ; Mon, 6 Nov 2017 10:40:50 +0900 (JST) To: dots@ietf.org From: kaname nishizuka Message-ID: Date: Mon, 6 Nov 2017 10:40:49 +0900 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: [Dots] Interoperability testing at the hackathon of the next IETF 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Nov 2017 01:40:55 -0000 Hi, Jon and I are preparing for an Interoperability testing at the hackathon of the next IETF. The schedule is very tight, so our primary target at the hackathon is to test the interoperability of signal-channel on COAP over DTLS. Especially, nttdots is needed to be updated to be compatible with the latest signal-channel draft. We will try hard to make it successful. Jon kindly decided to participate in the hackathon remotely, I'd like to say thanks to Jon in advance. Project Description: https://www.ietf.org/registration/MeetingWiki/wiki/doku.php?id=100hackathon **DOTS Interop**       * Champion(s)           * Kaname Nishizuka           * Jon Shallow(Remote)       * Project(s)         * DDoS Open Threat Signaling (DOTS).           * The aim of DOTS is to develop a standards based approach for the realtime signaling of DDoS related telemetry and threat handling requests and data between elements concerned with DDoS attack detection, classification, traceback, and mitigation.         * We will test the interoperability between two independent implementations:           * The primary goal is to test the interoperability of signal-channel (CoAP over DTLS) of DOT protocol.       * Specifications           * https://tools.ietf.org/html/draft-ietf-dots-signal-channel-06 **focused**           * https://tools.ietf.org/html/draft-ietf-dots-data-channel-06       * Implementations           * nttdots: https://github.com/nttdots/go-dots           * internal implementation by Jon Shallow Regards, Kaname From nobody Mon Nov 6 05:19:16 2017 Return-Path: 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 55CC613FC07 for ; Mon, 6 Nov 2017 05:19:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7 X-Spam-Level: X-Spam-Status: No, score=-7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham 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 4ysIJno2yn-4 for ; Mon, 6 Nov 2017 05:19:11 -0800 (PST) Received: from MIVWSMAILOUT1.mcafee.com (mivwsmailout1.mcafee.com [161.69.47.167]) (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 DB6F813FB09 for ; Mon, 6 Nov 2017 05:19:10 -0800 (PST) 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=1509974349; 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: authentication-results:x-originating-ip:x-ms-publictraffictype: x-microsoft-exchange-diagnostics:x-ms-exchange-antispam-srfa-diagnostics: x-ms-office365-filtering-correlation-id:x-microsoft-antispam: x-ms-traffictypediagnostic:x-exchange-antispam-report-test: x-microsoft-antispam-prvs:x-exchange-antispam-report-cfa-test: x-forefront-prvs:x-forefront-antispam-report: received-spf:spamdiagnosticoutput:spamdiagnosticmetadata: Content-Type: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-Transport-CrossTenantHeadersStamped: X-OriginatorOrg:X-NAI-Spam-Flag:X-NAI-Spam-Threshold: X-NAI-Spam-Score:X-NAI-Spam-Version; bh=4 Rr0E0p5eYjteAZXmlB+WvkYgstTu9bdMCMPcxdpuB Q=; b=Lhm4x2huJrxK/V99jbkUF12RO3SWCSvuZLtfD9yWW1X+ uxDGIeVcDaj/Fn8uCQrkxW4XrV6TvCzbrqAR3A6BtgR3eiDAsH 8K1NZ3Dv15LL93jNic3n8JvRtyBOdlFW+eLmunExYP6KDWr12J 2YNaMf9kfnWxRNTxYK5dL0lUdNw= Received: from MIVEXAPP1N03.corpzone.internalzone.com (unknown [10.48.48.90]) by MIVWSMAILOUT1.mcafee.com with smtp id 3bd1_98db_821ddf2f_f225_4e34_af6f_df759f364a90; Mon, 06 Nov 2017 07:19:08 -0600 Received: from MIVEXUSR1N04.corpzone.internalzone.com (10.48.48.84) by MIVEXAPP1N03.corpzone.internalzone.com (10.48.48.90) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Mon, 6 Nov 2017 08:19:02 -0500 Received: from MIVEXAPP1N03.corpzone.internalzone.com (10.48.48.90) by MIVEXUSR1N04.corpzone.internalzone.com (10.48.48.84) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Mon, 6 Nov 2017 08:19:01 -0500 Received: from MIVO365EDGE4.corpzone.internalzone.com (10.48.176.87) by MIVEXAPP1N03.corpzone.internalzone.com (10.48.48.90) with Microsoft SMTP Server (TLS) id 15.0.1347.2 via Frontend Transport; Mon, 6 Nov 2017 08:19:01 -0500 Received: from NAM01-SN1-obe.outbound.protection.outlook.com (10.48.176.242) by edge.mcafee.com (10.48.176.87) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Mon, 6 Nov 2017 08:19:00 -0500 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.20.197.13; Mon, 6 Nov 2017 13:18:59 +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.20.0197.020; Mon, 6 Nov 2017 13:18:59 +0000 From: "Konda, Tirumaleswar Reddy" To: Jon Shallow , "dots@ietf.org" Thread-Topic: [Dots] Data channel issues with GET Thread-Index: AdNU60NzSK+9AEyfSlySy52mDm5lHgANmhBQAA4iMgAABuS8gAABqgkAAAEMVoAAAk06gABd6xfQ Date: Mon, 6 Nov 2017 13:18:58 +0000 Message-ID: References: <06f601d354eb$482cce20$d8866a60$@jpshallow.com> <075801d3555a$34dbbd30$9e933790$@jpshallow.com> <07c101d3557c$70035a90$500a0fb0$@jpshallow.com> <07e901d35589$d6519e30$82f4da90$@jpshallow.com> In-Reply-To: <07e901d35589$d6519e30$82f4da90$@jpshallow.com> 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.206.27] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DM5PR16MB1787; 6:ubqwgdyqExgJ0NCPz17YOKYLiGVdRjQiFZUj8ndHV+iBv8+Yl9AhxvWlGoiWRqwY/fgWRZxvyeg+G8PEfzi8mLk0/CQ5s0DSdYox48/ZTO4Ns91zzliAuHb+acXREs1rfThCJFVIfUg443cdnx8uBqvLxefjvYfM8kbau2dKxMy8Sf3YH8tCYMj2o744VU+svjpPs9DNfuhOJ8PnASFsFKoCCyjS7VHcjQ2yFXmi7Xw44CknZjBwKA0gnCqyYuDSnV0xBlVL7+gYrPYITCUuFMwyRSFoEFD+LmHHrx3OZMg2fgI7uSykZ14jHrHIfn6dtvDHIGhw0I0S6mfKPb7+pxJFyoNHkpqFvzlJIyyTMR8=; 5:fBxmS6UOg1VhMiwhBTROpvBM9zqX6aCl74mMoJHhiE5sB4dUdOC/PYOtCSrR1xmOIeYhRmYJad8mq3jD1cc7Ad0WF6mSXUxOLJ8Ey9u6p/9EvDopkuBUHy18+GN3THwhJdA2ojs6p277p3G2YQcu9s65GubQvFwULYufSeoEGMc=; 24:f1x6bbspguGs/Dzr0dNzdil6BQjzr1RVqzPQuYeCPYKEtyk0y6GK6GAHTRnCsv5KzzdKSCpaBVZJi3gRDYhFmNifWY410cD3Df+2KnsKGqs=; 7:sXbLex2rKDMWJx5dsxbWtA4UxVIL/ZZd3M1BHh4GOWAqYsACS6N5br7Kz2HQf5j/cgGTmAzBdNylBZDT7QrKc/wQEaTKEuJQURqRlF7UPSgfI8fYj9pktxC7wg/S/3PBM6UcKwD1ZMCElKwvgh7ebS7okyTkDTw9r5JqFsaEkoviUSHYos7bDVx9znEZUBcmM6NoC90CNRv7ZaU1G7AhahQ2dxn8hSia1BF270oIAdMnhQFcGBmBM2KUIcT5EP2y x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: baa8e2b7-cff3-4dd2-1706-08d52518f0be x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(2017052603249); SRVR:DM5PR16MB1787; x-ms-traffictypediagnostic: DM5PR16MB1787: x-exchange-antispam-report-test: UriScan:(158342451672863)(21748063052155)(123452027830198); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(8121501046)(5005006)(100000703101)(100105400095)(93006095)(93001095)(3231021)(10201501046)(3002001)(6041248)(20161123562025)(20161123558100)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123560025)(20161123555025)(20161123564025)(6072148)(201708071742011)(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: 048396AFA0 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(346002)(376002)(199003)(189002)(51444003)(32952001)(575784001)(105586002)(86362001)(53546010)(6506006)(72206003)(77096006)(8676002)(606006)(966005)(6436002)(478600001)(229853002)(790700001)(102836003)(6116002)(3846002)(74316002)(3280700002)(5660300001)(33656002)(8936002)(3660700001)(2906002)(25786009)(2900100001)(106356001)(101416001)(7736002)(189998001)(2950100002)(81166006)(81156014)(66066001)(54356999)(76176999)(14454004)(50986999)(7696004)(80792005)(9686003)(2501003)(97736004)(53946003)(9326002)(93886005)(316002)(54896002)(53936002)(68736007)(19609705001)(6306002)(55016002)(6246003)(110136005)(236005)(99286004)(21314002)(85282002)(579004); DIR:OUT; SFP:1101; SCL:1; SRVR:DM5PR16MB1787; H:DM5PR16MB1788.namprd16.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX: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_DM5PR16MB1788337AF76AEA7A024DF085EA500DM5PR16MB1788namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: baa8e2b7-cff3-4dd2-1706-08d52518f0be X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Nov 2017 13:18:58.9684 (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 <6152> : inlines <6156> : streams <1769508> : uri <2529160> Archived-At: Subject: Re: [Dots] Data channel issues with GET 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Nov 2017 13:19:14 -0000 --_000_DM5PR16MB1788337AF76AEA7A024DF085EA500DM5PR16MB1788namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Jon, Please see inline [TR] From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Jon Shallow Sent: Saturday, November 4, 2017 9:58 PM To: Konda, Tirumaleswar Reddy ; dots@ie= tf.org Subject: Re: [Dots] Data channel issues with GET Hi Tiru, I agree that there is a MAY in "client-identifier: The client identifier MAY be conveyed by the DOTS gateway to propagate the DOTS client identity from the gateway's client-side to the gateway's server-side, and from the gateway's server-side to the DOTS server." But the following implies it has to be done, even though there is not a MUS= T - MAY should be included (as in '..., the DOTS gateway MAY compute the 'c= lient-identifier' value, as discussed above, and add the computed ..." I th= ink. [TR] Agreed, fixed. Cheers, -Tiru "If the 'client-identifier' value is already present in the mitigation request received from the DOTS client, the DOTS gateway computes the 'client-identifier' value, as discussed above, and adds the computed 'client-identifier' value to the end of the 'client-identifier' list." Regards Jon From: Dots [mailto: dots-bounces@ietf.org] On= Behalf Of Konda, Tirumaleswar Reddy Sent: 04 November 2017 15:22 To: Jon Shallow; dots@ietf.org Subject: Re: [Dots] Data channel issues with GET Hi Jon, Please see inline [TR] From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Jon Shallow Sent: Saturday, November 4, 2017 8:22 PM To: Konda, Tirumaleswar Reddy >; dots@ietf.org Subject: Re: [Dots] Data channel issues with GET Hi Tiru See 3 comments inline Regards Jon From: Dots [mailto: dots-bounces@ietf.org] On= Behalf Of Konda, Tirumaleswar Reddy Sent: 04 November 2017 14:29 To: Jon Shallow; dots@ietf.org Subject: Re: [Dots] Data channel issues with GET Hi Jon, The DOTS gateway (C3k) does not send any requests on its own to the DOTS se= rver (S3). As per the discussion of DOTS gateways in https://tools.ietf.or= g/html/draft-ietf-dots-architecture-05, it's only relaying the messages fro= m the downstream and upstream agents. The DOTS architecture does not discus= s DOTS gateway acting as a caching server. Jon> OK - I will see if further implementation throws anything else up on t= his - if not, I will leave it as it stands CIH(C1ax) would only be unique across all the DOTS clients communicating wi= th the DOTS gateway X but may not be globally unique (across Gateways J and= K), the current approach would ensure no probability of client-identifier = collisions. DOTS client (C1aj) -------------------------------------- (S1j) DOTS gatewa= y J (C2j) ------\ DOTS client (C1bj) -----------------------------------------/ = | = | DOTS client (C1ax) ----- (S1x) DOTS gateway X (C2x) ----- (S2k) DOTS gatewa= y K (C3k) ---- (S3) DOTS client (C1bx) -------/ | | DOTS client (C1ay) ----- (S1y) DOTS gateway Y (C2y) --------/ DOTS client (C1by) -------/ Jon> If gateway K detects a collision in any of CIH(C1ax), CIH(C1bx), CIH(= C1ay) and CIH(C1by), gateway K can then add in CIH(C2x) or CIH(C2y) as appr= opriate to maintain uniqueness as seen by S3. If there is no collision in = CIH(C1ax), CIH(C1bx), CIH(C1ay) and CIH(C1by), then these will be unique to= S3 when coming from C3k. This then potentially saves some packet space an= d allows for scaling beyond a small number of gateways. [TR] Agreed. I am assuming there won't be more than 3 DOTS gateways b/w the= DOTS client and server (client-side, server-side and one additional gatewa= y because of recursive signalling). As per our discussion, DOTS signal channel draft says, a DOTS gateway "MAY"= add the client-identifier. -Tiru Jon> I 100% agree that we must not have any client identifier collisions. -Tiru From: Jon Shallow [mailto:supjps-ietf@jpshallow.com] Sent: Saturday, November 4, 2017 4:17 PM To: Konda, Tirumaleswar Reddy >; dots@ietf.org Subject: RE: [Dots] Data channel issues with GET Hi Tiru, Agreed that a request from a DOTS client going through multiple DOTS gatewa= ys will get the appropriate client-identifier added, and the response initi= ally generated by the final DOTS server will have all the client-identifier= s. However, as the response passes back through the DOTS gateways, the appropr= iate client-identifier will get stripped off and the originating DOTS clien= t will have no visibility of the client-identifiers - as per " A DOTS gateway MUST update the 'client-identifier' list in the response to remove the 'client-identifier' value it had added in the corresponding request before forwarding the response to the DOTS client." So, Figure 6 and Figure 7 do not correctly portray the reality as seen by a= DOTS client (whether on a DOTS gateway or not). When the DOTS Gateway client component generates the GET request should the= request be (to match Figure 7 response) " GET /restconf/data/ietf-dots-data-channel-identifier:identifier?\ content=3Dconfig&client-identifier=3Ddz6pHjaADkaFTbjr0JGBpw,iAYmCN= PmrYoKoqzgFMiobw HTTP/1.1 Host: {host}:{port} Accept: application/yang-data+json Figure 6: GET to retrieve all the installed identifiers" =3D=3D=3D=3D=3D This still does not answer my implied concern - how does a DOTS gateway cli= ent request all the aliases / filters / mitigations to sync up state when, = say, the DOTS gateway client restarts? - The DOTS gateway may not know all the client-identifiers that are talking= to the server component of the DOTS gateway - they may be behind yet anoth= er DOTS gateway. Taking this more complex example involving multiple gateways (should it be = in the drafts somewhere for helping with client-identifier clarity?) DOTS client (C1aj) ----------------------------------------- (S1j) DOTS gat= eway J (C2j) ----------\ DOTS client (C1bj) --------------------------------------------/ = | = | DOTS client (C1ax) ------- (S1x) DOTS gateway X (C2x) ------ (S2k) DOTS gat= eway K (C3k) -------- (S3) DOTS client (C1bx) ----------/ | | DOTS client (C1ay) ------- (S1y) DOTS gateway Y (C2y) ---------/ DOTS client (C1by) ----------/ If C3k restarts how is he able to re-sync his information from S3? C3K doe= s not have a GET 'all' capability with client-identifier being above the le= vel of alias-name. It maybe that C3k does not need to re-sync, but C3k sho= uld have the flexibility if C3k is, say, able to cache information to reduc= e the number of requests having to pass all the way through to S3. As an aside, in my current implementation, where CIH(xxx) is the Client Ide= ntifier hash of xxx C1ax does a PUT (alias-name=3DServer1), C2x does a PUT (alias-name=3DServer1&client-identifer=3DCIH(C1ax)), C3k does a PUT (alias-name=3DServer1&client-identifer=3DCIH(C1ax),CIH(C2x)) and S3 uniquely stores this alias-name as (alias-name=3DServer1&client-iden= tifer=3DCIH(C1ax),CIH(C2x),CIH(C3k)) so that if any of the DOTS clients do a PUT (alias-name=3DServer1) [with sa= me alias name] S3 can differentiate them all. As CIH(C1ax) should be unique across all DOTS clients, do we really need to= add in all the other CIH() as the traffic passes up through to S3? Regards Jon From: Dots [mailto: dots-bounces@ietf.org] On= Behalf Of Konda, Tirumaleswar Reddy Sent: 04 November 2017 04:16 To: Jon Shallow; dots@ietf.org Subject: Re: [Dots] Data channel issues with GET Hi Jon, GET request will only retrieve the alias-names installed by a DOTS client a= nd not the alias-names for all the DOTS clients. The client-identifier arra= y is uniquely identifying the DOTS client and does not need be repeated for= every alias-name conveyed by the client. Figure 6 is showing the GET requ= est from the DOTS client, and the DOTS gateways will update the GET request= to add and update the client-identifier array. I don't think the client-identifier should be in the same level as alias-na= me. -Tiru From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Jon Shallow Sent: Saturday, November 4, 2017 3:03 AM To: dots@ietf.org Subject: [Dots] Data channel issues with GET Hi Tiru et al, I am having challenges coding up the GET for channel identifiers. A DOTS Client as part of a DOTS gateway can use different client-identifier= s when doing a PUT for the alias-name. The DOTS server will therefore hav= e multiple client-identifier arrays for the DOTS GW client. However when doing a GET using 'content=3Dconfig', as things currently stan= d, only one client-identifier array can returned as per the below in Figure= 7:- =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D "3.2.3. Retrieving Installed Identifiers A GET request is used to retrieve the set of installed identifiers from a DOTS server (Section 3.3.1 in [RFC8040]). Figure 6 shows how to retrieve all the identifiers that were instantiated by the DOTS client. The content parameter and its permitted values are defined in Section 4.8.1 of [RFC8040]. GET /restconf/data/ietf-dots-data-channel-identifier:identifier?\ content=3Dconfig HTTP/1.1 Host: {host}:{port} Accept: application/yang-data+json Figure 6: GET to retrieve all the installed identifiers Figure 7 shows response for all identifiers on the DOTS server. { "ietf-dots-data-channel-identifier:identifier": { "client-identifier": [ "dz6pHjaADkaFTbjr0JGBpw", "iAYmCNPmrYoKoqzgFMiobw" ], "alias": [ { "alias-name": "Server1", "traffic-protocol": [ 6" =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D I think that the yang model needs to be re-written, by moving leaf-list cli= ent-identifier down to the same level as alias-name as :- =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D container identifier { description "Top level container for identifiers"; list alias { key alias-name; description "List of identifiers"; leaf alias-name { type string; description "alias name"; } leaf-list client-identifier { type binary; description "A client identifier conveyed by a DOTS = gateway to a remote DOTS server."; reference "I-D.itef-dots-signal-channel"; } leaf-list target-ip { =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D And reflected appropriately throughout the data channel draft. The issue is the same for the access control list - client-identifier needs= to be at the same level as acl-name module: ietf-dots-access-control-list augment /ietf-acl:access-lists: +--rw client-identifier* binary =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Needs to be module: ietf-dots-access-control-list augment /ietf-acl:access-lists/ietf-acl:acl/: +--rw client-identifier* binary =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D And replicated as appropriate throughout the draft Regards Jon --_000_DM5PR16MB1788337AF76AEA7A024DF085EA500DM5PR16MB1788namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Jon,

&nbs= p;

Please se= e inline [TR]

 

From:<= /span> Dots [mailto:dots-bou= nces@ietf.org] On Behalf Of Jon Shallow
Sent: Saturday, November 4, 2017 9:58 PM
To: Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@McAfee.com= >; dots@ietf.org
Subject: Re: [Dots] Data channel issues with GET

 

Hi Tiru= ,

&n= bsp;

I agree= that there is a MAY in

&n= bsp;

“= client-identifier:  The client identifier MAY be conveyed by the DOTS<= o:p>

 &= nbsp;    gateway to propagate the DOTS client identity from = the gateway's

 &= nbsp;    client-side to the gateway's server-side, and from = the gateway's

 &= nbsp;    server-side to the DOTS server.”

&n= bsp;

But the= following implies it has to be done, even though there is not a MUST ̵= 1; MAY should be included (as in ‘…, the DOTS gateway MAY compu= te the 'client-identifier' value, as discussed above, and add the computed …” I think.

 

[TR] Agreed, fixed.<= /span>

 

Cheers,

-Tiru

&n= bsp;

“= If the

 &= nbsp; 'client-identifier' value is already present in the mitigation

 &= nbsp; request received from the DOTS client, the DOTS gateway computes the<= o:p>

 &= nbsp; 'client-identifier' value, as discussed above, and adds the computed<= o:p>

 &= nbsp; 'client-identifier' value to the end of the 'client-identifier' list.= ”

&n= bsp;

Regards=

&n= bsp;

Jon

&n= bsp;

From: Dots [mailto: dots-bounces@ietf.org] On B= ehalf Of Konda, Tirumaleswar Reddy
Sent: 04 November 2017 15:22
To: Jon Shallow; dots@ietf.org<= br> Subject: Re: [Dots] Data channel issues with GET

 

Hi Jon,

&nbs= p;

Please se= e inline [TR]

&nbs= p;

From:<= /span> Dots [mailto:dots-bounces@ietf.org] On Behalf Of Jon Shallow
Sent: Saturday, November 4, 2017 8:22 PM
To: Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@McAfee.com>; dots@ietf.org
Subject: Re: [Dots] Data channel issues with GET

 

Hi Tiru=

&n= bsp;

See 3 c= omments inline

&n= bsp;

Regards=

&n= bsp;

Jon

&n= bsp;

From: Dots [mailto: dots-bounces@ietf.org] On B= ehalf Of Konda, Tirumaleswar Reddy
Sent: 04 November 2017 14:29
To: Jon Shallow; dots@ietf.org<= br> Subject: Re: [Dots] Data channel issues with GET

 

Hi Jon,

&nbs= p;

The DOTS = gateway (C3k) does not send any requests on its own to the DOTS server (S3)= .  As per the discussion of DOTS gateways in htt= ps://tools.ietf.org/html/draft-ietf-dots-architecture-05, it’s on= ly relaying the messages from the downstream and upstream agents. The DOTS = architecture does not discuss DOTS gateway acting as a caching server.

 

Jon> OK – I will see if further implementation throws anythin= g else up on this – if not, I will leave it as it stands

 

CIH(C1a= x) would only be unique across all the DOTS clients communicating with the = DOTS gateway X but may not be globally unique (across Gateways J and K), th= e current approach would ensure no probability of client-identifier collisions.

&n= bsp;

DOTS client (C1aj) -----------= --------------------------- (S1j) DOTS gateway J (C2j) ------\  

DOTS client (C1bj) -----------= ------------------------------/       &n= bsp;            &nbs= p;         |=

     =             &nb= sp;            =              &n= bsp;            = ;            &n= bsp;            = ;          |

DOTS client (C1ax) ----- (S1x)= DOTS gateway X (C2x) ----- (S2k) DOTS gateway K (C3k) ---- (S3)  = ; 

DOTS client (C1bx) -------/&nb= sp;            =              &n= bsp;      |     &nbs= p;            &= nbsp;            

     =             &nb= sp;            =             &nb= sp;            =      |       &n= bsp;            = ;             <= o:p>

DOTS client (C1ay) ----- (S1y)= DOTS gateway Y (C2y) --------/       &n= bsp;            = ;             <= o:p>

DOTS client (C1by) -------/&nb= sp;            =              &n= bsp;            = ;            &n= bsp;            = ;   

&n= bsp;

Jon>=   If gateway K detects a collision in any of CIH(C1ax), CIH(C1bx), CIH= (C1ay) and CIH(C1by), gateway K can then add in CIH(C2x) or CIH(C2y) as app= ropriate to maintain uniqueness as seen by S3.  If there is no collision in CIH(C1ax), CIH(C1bx), CIH(C1ay) and CIH(C1by),= then these will be unique to S3 when coming from C3k.  This then pote= ntially saves some packet space and allows for scaling beyond a small numbe= r of gateways.

 

[TR] Ag= reed. I am assuming there won’t be more than 3 DOTS gateways b/w the = DOTS client and server (client-side, server-side and one additional gateway= because of recursive signalling).

As per = our discussion, DOTS signal channel draft says, a DOTS gateway “MAY&#= 8221; add the client-identifier.

&n= bsp;

-Tiru

 

&n= bsp;

Jon>= I 100% agree that we must not have any client identifier collisions.<= /o:p>

&n= bsp;

&n= bsp;

-Tiru

&nbs= p;

From:<= /span> Jon Shallow [mailto:supjps-ietf@jpshallow.com]
Sent: Saturday, November 4, 2017 4:17 PM
To: Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@McAfee.com>; dots@ietf.org
Subject: RE: [Dots] Data channel issues with GET

 

Hi Tiru= ,

&n= bsp;

Agreed = that a request from a DOTS client going through multiple DOTS gateways will= get the appropriate client-identifier added, and the response initially ge= nerated by the final DOTS server will have all the client-identifiers.

&n= bsp;

However= , as the response passes back through the DOTS gateways, the appropriate cl= ient-identifier will get stripped off and the originating DOTS client will = have no visibility of the client-identifiers – as per

“=    A DOTS gateway MUST update the 'client-identifier' list in the=

 &= nbsp; response to remove the 'client-identifier' value it had added in the<= o:p>

 &= nbsp; corresponding request before forwarding the response to the DOTS=

 &= nbsp; client.”

&n= bsp;

So, Fig= ure 6 and Figure 7 do not correctly portray the reality as seen by a DOTS c= lient (whether on a DOTS gateway or not).

&n= bsp;

When th= e DOTS Gateway client component generates the GET request should the reques= t be (to match Figure 7 response)

&n= bsp;

“=     GET /restconf/data/ietf-dots-data-channel-identifier:ide= ntifier?\

 &= nbsp;       content=3Dconfig&client-ident= ifier=3Ddz6pHjaADkaFTbjr0JGBpw,iAYmCNPmrYoKoqzgFMiobw HTTP/1.1

 &= nbsp;   Host: {host}:{port}

 &= nbsp;   Accept: application/yang-data+json<= /p>

&n= bsp;

 &= nbsp;        Figure 6: GET to retrieve a= ll the installed identifiers”

&n= bsp;

=3D=3D= =3D=3D=3D

&n= bsp;

This st= ill does not answer my implied concern – how does a DOTS gateway clie= nt request all the aliases / filters / mitigations to sync up state when, s= ay, the DOTS gateway client restarts?

- The D= OTS gateway may not know all the client-identifiers that are talking to the= server component of the DOTS gateway – they may be behind yet anothe= r DOTS gateway.

&n= bsp;

Taking = this more complex example involving multiple gateways (should it be in the = drafts somewhere for helping with client-identifier clarity?)

&n= bsp;

DOTS client (C1aj) -----------= ------------------------------ (S1j) DOTS gateway J (C2j) ----------\ =  

DOTS client (C1bj) -----------= ---------------------------------/       = ;             &= nbsp;           &nbs= p; |

     =             &nb= sp;            =              &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;    |

DOTS client (C1ax) ------- (S1= x) DOTS gateway X (C2x) ------ (S2k) DOTS gateway K (C3k) -------- (S3)&nbs= p;  

DOTS client (C1bx) ----------/=             &nb= sp;            =        |     &= nbsp;           &nbs= p;             =

     =             &nb= sp;            =             &nb= sp;            =         |    &n= bsp;            = ;             &= nbsp;  

DOTS client (C1ay) ------- (S1= y) DOTS gateway Y (C2y) ---------/       = ;            &n= bsp;            &nbs= p;

DOTS client (C1by) ----------/=             &nb= sp;            =             &n= bsp;            = ;            &n= bsp;   

     =             &nb= sp;            =             &nb= sp;            =             &nb= sp;            =             &nb= sp;    

&n= bsp;

If C3k = restarts how is he able to re-sync his information from S3?  C3K does = not have a GET ‘all’ capability with client-identifier being ab= ove the level of alias-name.  It maybe that C3k does not need to re-sync, but C3k should have the flexibility if C3k is, say, able = to cache information to reduce the number of requests having to pass all th= e way through to S3.

&n= bsp;

As an a= side, in my current implementation, where CIH(xxx) is the Client Identifier= hash of xxx

&n= bsp;

C1ax do= es a PUT (alias-name=3DServer1),

C2x doe= s a PUT (alias-name=3DServer1&client-identifer=3DCIH(C1ax)),=

C3k doe= s a PUT (alias-name=3DServer1&client-identifer=3DCIH(C1ax),CIH(C2x))

and S3 = uniquely stores this alias-name as (alias-name=3DServer1&client-identif= er=3DCIH(C1ax),CIH(C2x),CIH(C3k))

so that= if any of the DOTS clients do a PUT (alias-name=3DServer1) [with same alia= s name] S3 can differentiate them all.

&n= bsp;

As CIH(= C1ax) should be unique across all DOTS clients, do we really need to add in= all the other CIH() as the traffic passes up through to S3?

&n= bsp;

Regards=

&n= bsp;

Jon

&n= bsp;

From: Dots [mailto: dots-bounces@ietf.org] On B= ehalf Of Konda, Tirumaleswar Reddy
Sent: 04 November 2017 04:16
To: Jon Shallow; dots@ietf.org<= br> Subject: Re: [Dots] Data channel issues with GET

 

Hi Jon,

&nbs= p;

GET reque= st will only retrieve the alias-names installed by a DOTS client and not th= e alias-names for all the DOTS clients. The client-identifier array is uniq= uely identifying the DOTS client and does not need be repeated for every alias-name conveyed by the client. &nb= sp;Figure 6 is showing the GET request from the DOTS client, and the DOTS g= ateways will update the GET request to add and update the client-identifier= array.

I donR= 17;t think the client-identifier should be in the same level as alias-name.

&nbs= p;

-Tiru

&nbs= p;

From:<= /span> Dots [mailto:dots-bounces@ietf.org] On Behalf Of Jon Shallow
Sent: Saturday, November 4, 2017 3:03 AM
To: dots@ietf.org
Subject: [Dots] Data channel issues with GET

 

Hi Tiru et al,

 

I am having challenges coding u= p the GET for channel identifiers.

 

A DOTS Client as part of a DOTS= gateway can use different client-identifiers when doing a PUT for the alia= s-name.   The DOTS server will therefore have multiple client-ide= ntifier arrays for the DOTS GW client.

 

However when doing a GET using = ‘content=3Dconfig’, as things currently stand, only one client-= identifier array can returned as per the below in Figure 7:-

 

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<= /span>

 

“3.2.3.  Retrieving = Installed Identifiers

 

   A GET request is u= sed to retrieve the set of installed identifiers

   from a DOTS server= (Section 3.3.1 in [RFC8040]).  Figure 6 shows how

   to retrieve all th= e identifiers that were instantiated by the DOTS

   client.  The = content parameter and its permitted values are defined

   in Section 4.8.1 o= f [RFC8040].

 

     GET /r= estconf/data/ietf-dots-data-channel-identifier:identifier?\

     &= nbsp;   content=3Dconfig HTTP/1.1

     Host: = {host}:{port}

     Accept= : application/yang-data+json

 

     &= nbsp;    Figure 6: GET to retrieve all the installed identif= iers

 

   Figure 7 shows res= ponse for all identifiers on the DOTS server.

 

   {

    "ietf-d= ots-data-channel-identifier:identifier": {

     &= nbsp; "client-identifier": [

     &= nbsp;    "dz6pHjaADkaFTbjr0JGBpw",

     &= nbsp;    "iAYmCNPmrYoKoqzgFMiobw"

     &= nbsp; ],

     &= nbsp; "alias": [

     &= nbsp;   {

     &= nbsp;     "alias-name": "Server1",<= o:p>

     &= nbsp;     "traffic-protocol": [

     &= nbsp;       6”

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D

 

I think that the yang model nee= ds to be re-written, by moving leaf-list client-identifier down to the same= level as alias-name as :-

 

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D

     contai= ner identifier {

     &= nbsp;    description "Top level container for identifie= rs";

 

     &= nbsp;        list alias {

     &= nbsp;           &nbs= p; key alias-name;

     &= nbsp;            &nb= sp;description "List of identifiers";

 

     &= nbsp;           &nbs= p; leaf alias-name {

     &= nbsp;           &nbs= p;    type string;

     &= nbsp;           &nbs= p;    description "alias name";<= /p>

     &= nbsp;           &nbs= p; }

 

     &= nbsp;           &nbs= p; leaf-list client-identifier {

     &= nbsp;           &nbs= p;    type binary;

     &= nbsp;           &nbs= p;    description  "A client identifier conveyed b= y a DOTS gateway

     &= nbsp;           &nbs= p;            &= nbsp;     to a remote DOTS server.";

 

     &= nbsp;           &nbs= p;    reference

     &= nbsp;           &nbs= p;       "I-D.itef-dots-signal-channel&q= uot;;

     &= nbsp;           &nbs= p; }

 

     &= nbsp;           &nbs= p; leaf-list target-ip {

 

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D

 

And reflected appropriately thr= oughout the data channel draft.

 

The issue is the same for the a= ccess control list – client-identifier needs to be at the same level = as acl-name

 

module: ietf-dots-access-contro= l-list

  augment /ietf-acl:access= -lists:

    +--rw cl= ient-identifier*   binary

 

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D

Needs to be

 

module: ietf-dots-access-contro= l-list

  augment /ietf-acl:access= -lists/ietf-acl:acl/:

    +--rw cl= ient-identifier*   binary

 

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D

 

And replicated as appropriate t= hroughout the draft

 

Regards

 

Jon

--_000_DM5PR16MB1788337AF76AEA7A024DF085EA500DM5PR16MB1788namp_-- From nobody Tue Nov 7 07:07:37 2017 Return-Path: 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 4365A13FF9A for ; Tue, 7 Nov 2017 07:07:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 isFHkZ3raxFA for ; Tue, 7 Nov 2017 07:07:29 -0800 (PST) Received: from mail-pg0-x22d.google.com (mail-pg0-x22d.google.com [IPv6:2607:f8b0:400e:c05::22d]) (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 BF6C113FF5B for ; Tue, 7 Nov 2017 07:04:43 -0800 (PST) Received: by mail-pg0-x22d.google.com with SMTP id a192so11234547pge.9 for ; Tue, 07 Nov 2017 07:04:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-transfer-encoding; bh=V81kvMu/SgFjZMG1xSDf/sCB/IqwhnHNTO2Mmjo2SVY=; b=GtcIrZm7F06fxdAnFOhoex4jUXMD19GkcedpsOmnbqV3qwVOJ3xK/+HIN84Wo28Rqn vGNPX9LcFLJ9zZlD3Ss1Q59gTAYFVaD1kwcC/HDJPJ90UsuY1ug4w9dTrLc1g1ghF3s2 NtL2VY2eSA2vLiGmKiMIUz+3TaXbi8UApW8h1wlijhFHgJ/aaHNLnovztH3pOI9c9mkW Apl6TvjYpnW7jo/6rOGMaSL1cBmiAdcaQcAHS36be4X2n80PcuTg9b/3s+NK7agvnUCm ca2oBoGsG8SAOgJrQLowsoe15XhEaOJHwmaTLaTPLCtYfMFlyM+seqM+mBxckKkLZiXw GjUg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:content-transfer-encoding; bh=V81kvMu/SgFjZMG1xSDf/sCB/IqwhnHNTO2Mmjo2SVY=; b=liBqcAgjCS5Xnjlv3OhjtRywWy3FX/wgM/8pCeWrqm/ef7Nl4gAb4oK5yhLN8N048o QEvttu2bRnH3oX33wcPcSK5LP0dlbB5btSlOUlTjLjEREef8lEgDb0llOAw2AxmWmMZA onn2/HZivCPYi8OoCKBtfKb8/xq/vZWFX7iwOAJC2dnc/AZ3CDH9rcLDDRoIiGTVK67+ DmE46xbZxJ9v84U+gC9C2Dy29UXbLJT7xV90B05mbKnhPH+JRc8n1pRDEQqTgH4nZOpw lLJIDdD1O8zakUTfERHWlmU+uiuetXDFjqyb++3MiPspFwpfUfPKIetZDYNwPuDhi/KS Kdsg== X-Gm-Message-State: AMCzsaWfiGY50iNi2B88Qwoh8/vDskqc/+kIHgZheH8wozO51EsjsjD9 WPfR9t3It96ANAkw7VC/y45+cI/yg0y+GKkW69g= X-Google-Smtp-Source: ABhQp+T/RMo35/VPeEQnlrxuESXxdNiQ/pJWCLRzBcM9B1lHvE/s5CWMVTYK5qsWBclgGcj0pQl2bxlk5UTf3B1Xye8= X-Received: by 10.98.87.74 with SMTP id l71mr21146680pfb.204.1510067082951; Tue, 07 Nov 2017 07:04:42 -0800 (PST) MIME-Version: 1.0 Received: by 10.100.186.194 with HTTP; Tue, 7 Nov 2017 07:04:02 -0800 (PST) In-Reply-To: References: From: Kathleen Moriarty Date: Tue, 7 Nov 2017 10:04:02 -0500 Message-ID: To: "dots@ietf.org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: [Dots] Fwd: SAAG IETF 100 Agenda 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Nov 2017 15:07:35 -0000 Hello, SAAG will have a guest speaker presenting their DDoS research and it may be of interest to DOTS participants. The abstract is included below. Best regards, Kathleen ---------- Forwarded message ---------- From: Kathleen Moriarty Date: Tue, Nov 7, 2017 at 10:02 AM Subject: SAAG IETF 100 Agenda To: "saag@ietf.org" Hello, The SAAG agenda has been posted. Since SecDispatch will follow SAAG in the same session, SAAG will be shorter then normal and we have one invited speaker, Min Suk KANG. Agenda: https://datatracker.ietf.org/meeting/100/materials/agenda-100-saag/ Abstract for invited talk: Title: Inter-domain DDoS mitigations: potentials, challenges, and solutions Abstract: Distributed denial-of-service (DDoS) attacks have plagued the Internet for a few decades. Particularly, volumetric DDoS attacks have shown a tremendous increase in volume in the past few years, often flooding one or more upstream ASes of a target network. Academic community also has warned about new volumetric attack vectors (e.g., link-flooding attacks [Studer and Perrig, 2009] [Kang et al. 2013]); yet, it has been shown that single-domain mitigations have limited defense capability [Kang et al. 2016]. To that end, ASes in practice have begun to collaborate and outsource packet filtering to neighboring ASes (see the recent inter-domain packet filtering system between AT&T and CenturyLink [Levy et al., 2017]) and an IETF standard working group, called DDoS Open Threat Signaling or DOTS, has been formed. Although collaborative packet filtering between two ASes has great potentials and often is necessary for DDoS mitigations, there exist several fundamental concerns for designing a secure collaborative packet filtering between mutually distrusting ASes. In this talk, we argue that three security properties are desired for secure inter-domain packet filtering: (1) fairness guarantees (i.e., both ASes can equally contribute to filtering operations); (2) privacy guarantees (i.e., one AS cannot learn the other AS=E2=80=99s filtering poli= cy beyond what is already known); and (3) accountable packet filtering (i.e., collaborating ASes can prove if a packet has been dropped as a result of the collaborative packet filtering). We present a prototype for an ongoing project on a secure inter-domain collaborative packet filtering system that exploits a trusted hardware commodity server platform (i.e., Intel SGX) and supports line-rate (e.g., 10 Gbps) rate-limiting operations. [Studer and Perrig, 2009] Ahren Studer and Adrian Perrig. "The Coremelt Attack." ESORICS. 2009. [Kang et al., 2013] Min Suk Kang, Soo Bum Lee, and Virgil D. Gligor. "The crossfire attack." IEEE Symposium on Security and Privacy (SP), 2013. [Kang et al., 2016] Min Suk Kang, Virgil D. Gligor, and Vyas Sekar. "SPIFFY: Inducing Cost-Detectability Tradeoffs for Persistent Link-Flooding Attacks." NDSS. 2016. [Levy et al., 2017] Nimrod Levy, Don Smith, and John Schiel. =E2=80=9COperationalizing ISP cooperation during DDoS attacks.=E2=80=9D NAN= OG 71, October 3, 2017. -- Best regards, Kathleen --=20 Best regards, Kathleen From nobody Tue Nov 7 23:34:19 2017 Return-Path: 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 390511300BC for ; Tue, 7 Nov 2017 23:34:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.32 X-Spam-Level: X-Spam-Status: No, score=-4.32 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham 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 VL9wY96x69jn for ; Tue, 7 Nov 2017 23:34:13 -0800 (PST) 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 56DAA12ECCA for ; Tue, 7 Nov 2017 23:34:13 -0800 (PST) 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=1510126438; 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: authentication-results:x-originating-ip:x-ms-publictraffictype: x-microsoft-exchange-diagnostics:x-ms-exchange-antispam-srfa-diagnostics: x-ms-office365-filtering-correlation-id:x-microsoft-antispam: x-ms-traffictypediagnostic:x-exchange-antispam-report-test: x-microsoft-antispam-prvs:x-exchange-antispam-report-cfa-test: x-forefront-prvs:x-forefront-antispam-report: received-spf:spamdiagnosticoutput:spamdiagnosticmetadata: Content-Type: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-Transport-CrossTenantHeadersStamped: X-OriginatorOrg:X-NAI-Spam-Flag:X-NAI-Spam-Threshold: X-NAI-Spam-Score:X-NAI-Spam-Version; bh=A 1cjhMAkMCvWzIbe0q0vnpUvAV70XewJde+M2SH6u/ k=; b=GJW+3O4CQeCd2MUpwrkYibq76zVAA85kwWY7mGvbXXCi W8yjjvpy5MdSRbyozd4kF9oztZyVozD4lf4eA8EAxuZQ16HVJz H/cSOZjaAcOGMJwGMxiv1t8zh0ChHkm2TqmyM9NGP9PdilwRgI OuxtmoIlgHeHVJEV8u95Lgx3OWY= Received: from DNVEXAPP1N06.corpzone.internalzone.com (unknown [10.44.48.90]) by DNVWSMAILOUT1.mcafee.com with smtp id 49bc_20f2_dd955a19_02f2_442b_8a84_ddc9dfcdacc1; Wed, 08 Nov 2017 01:33:57 -0600 Received: from DNVEXUSR1N10.corpzone.internalzone.com (10.44.48.83) by DNVEXAPP1N06.corpzone.internalzone.com (10.44.48.90) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Wed, 8 Nov 2017 00:33:56 -0700 Received: from DNVO365EDGE1.corpzone.internalzone.com (10.44.176.66) by DNVEXUSR1N10.corpzone.internalzone.com (10.44.48.83) with Microsoft SMTP Server (TLS) id 15.0.1347.2 via Frontend Transport; Wed, 8 Nov 2017 00:33:56 -0700 Received: from NAM01-BY2-obe.outbound.protection.outlook.com (10.44.176.243) by edge.mcafee.com (10.44.176.66) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Wed, 8 Nov 2017 00:33:56 -0700 Received: from DM5PR16MB1788.namprd16.prod.outlook.com (10.172.44.144) by DM5PR16MB1785.namprd16.prod.outlook.com (10.172.44.141) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.197.13; Wed, 8 Nov 2017 07:33:54 +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.20.0197.020; Wed, 8 Nov 2017 07:33:54 +0000 From: "Konda, Tirumaleswar Reddy" To: Jon Shallow , Roland Dobbins , "mohamed.boucadair@orange.com" , "dots@ietf.org" Thread-Topic: [Dots] New DOTS signal and data channel requirements Thread-Index: AdNBwk09lvTBkcrPTyu7yNIocIr0swTyCS+AALZKB2A= Date: Wed, 8 Nov 2017 07:33:54 +0000 Message-ID: References: <07ff01d3558a$726a8e30$573faa90$@jpshallow.com> In-Reply-To: <07ff01d3558a$726a8e30$573faa90$@jpshallow.com> 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: [103.245.47.20] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DM5PR16MB1785; 6:c6YJuJqSGm2cbnPEXCqLzlgOi8zZagyjLhCmOQCK7c6VR2wYIq8npMSI7p9K96TXmfidY6gc15lRMM1jYcHhbkY5VEibvaHVHw5GKZ3lGjWNNDQFJPCW4qnB93BIkwtjy5eC++9SLjsxzvajNXnaQDRMbyMvxmg81Inlltxy8oHRi5UgaQTVrVvYqwvfltcp2Gyz8VA2Cm6EFffUTt1B00S2BSf1XC2Pm3KsEBrbC4vorT8b++8E9VDFJs5F2LcuGZqucY4AVJTChoMf5ITxwDIpWMBzR3OY3eLVJQ274SuFr/byhZzSR5Vg6lf3PBPowcJ/2PB0IhG6qxFkaE4Zr1H+LvjCnMG8CYQljuXcxrY=; 5:v2UBuMjTjo2ezl2faO2JBpexWIsDCOHF0glcFkbeFPZ7n4koPol4rKXZ8kMq9E5f/g+CDMzQ6k3izuEtw3m3iDtltD0besdCKyGhB2EWpmLzzDYeAENdyYJeBJtErx7N2bSOptx1rY8o7e3oPd6k7KOePOm5tlBFTHLtzpMb6U8=; 24:7RNAhuKyOPyErFnzMi1pXoXboiAGVBwQa/rr6mtawefjvIdkXs+xjwNp9ooOYnBLoy1EsRqXdEeBMLU1pxLWin0U9gl0WsDIR/1tSfPZveM=; 7:vWQkxfeFnzV0gld/3zKuxGudDY+hEjQT3ydKmmHBMk7vkSStnKyVl2Bc60O5T7p6BwG9CEbtxOa/uqNFsD9wbax+pIY7XTx9AhN26uSLCkbLAwyqUnuj1zQ5CAFEmmiPwnFUA/rMXX+9bBQm4yrGuCf2bsjK3+Y/Tcd89LBQj743ZachOh/nyN5lqfL5F4bRB8Ae0ks+1RLSYVYYaufaXUSL7dwTNhUVISDxlmKd51U/TQYmtOrOuXUi+KIs48km x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: b2a245bf-2bfe-4f2e-7b80-08d5267b10bb x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(2017052603199); SRVR:DM5PR16MB1785; x-ms-traffictypediagnostic: DM5PR16MB1785: x-exchange-antispam-report-test: UriScan:(158342451672863)(120809045254105)(18271650672692)(21748063052155)(123452027830198); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(8121501046)(5005006)(100000703101)(100105400095)(3231021)(3002001)(93006095)(93001095)(10201501046)(6041248)(20161123558100)(20161123560025)(20161123564025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123555025)(20161123562025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:DM5PR16MB1785; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:DM5PR16MB1785; x-forefront-prvs: 0485417665 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(376002)(346002)(199003)(32952001)(57704003)(189002)(3660700001)(19609705001)(229853002)(6116002)(110136005)(2906002)(790700001)(7736002)(66066001)(76176999)(72206003)(102836003)(7696004)(8676002)(81166006)(2201001)(478600001)(54356999)(8936002)(50986999)(606006)(54896002)(55016002)(14454004)(6306002)(966005)(6246003)(77096006)(25786009)(3280700002)(81156014)(53546010)(106356001)(99286004)(6436002)(3846002)(9326002)(68736007)(6506006)(86362001)(9686003)(74316002)(189998001)(105586002)(316002)(80792005)(2501003)(5660300001)(53936002)(2950100002)(33656002)(2900100001)(101416001)(97736004)(236005)(85282002); DIR:OUT; SFP:1101; SCL:1; SRVR:DM5PR16MB1785; H:DM5PR16MB1788.namprd16.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX: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_DM5PR16MB1788CB569C96726D6E417E59EA560DM5PR16MB1788namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: b2a245bf-2bfe-4f2e-7b80-08d5267b10bb X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Nov 2017 07:33:54.4942 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4943e38c-6dd4-428c-886d-24932bc2d5de X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR16MB1785 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 <6153> : inlines <6164> : streams <1769674> : uri <2530187> Archived-At: Subject: Re: [Dots] New DOTS signal and data channel requirements 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Nov 2017 07:34:16 -0000 --_000_DM5PR16MB1788CB569C96726D6E417E59EA560DM5PR16MB1788namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgSm9uLA0KDQpZb3VyIG1haWwgaXMgZGlzY3Vzc2luZyB0d28gZGlmZmVyZW50IGlzc3Vlcywg SSB3aWxsIGZvY3VzIG9uIG9uZSBvZiB0aGVtIGluIHRoaXMgdGhyZWFkOg0KDQoxLiBUaGUgQUNF cyBpbiBhIEFDTCBjYW4gYmUgb3JkZXJlZCB1c2luZyB0aGUgImluc2VydCIgcXVlcnkgcGFyYW1l dGVyIGRpc2N1c3NlZCBpbiBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjODA0MCNzZWN0 aW9uLTQuOC41Lg0KICAgVGhlIGxpc3QgImFjZSIgaW4gY29udGFpbmVyICJhY2VzIiBoYXMgdGhl ICdvcmRlcmVkLWJ5LXVzZXInIHN0YXRlbWVudCwgc28gQUNFcyBpbiBhIEFDTCBjYW4gb3JkZXJl ZCB1c2luZyBSRVNUQ09ORi4NCg0KMi4gSG93ZXZlciwgbGlzdCAiYWNsIiBpbiBjb250YWluZXIg ImFjY2Vzcy1saXN0cyIgZG9lcyBub3QgaGF2ZSB0aGUgJ29yZGVyZWQtYnktdXNlcicgc3RhdGVt ZW50LCBidXQgQUNMcyBjYW4gYmUgb3JkZXJlZCB3aGVuIGFwcGxpZWQgdG8gYW4gaW50ZXJmYWNl Lg0KDQogICBUaGUgcHJvYmxlbSB3aXRoIERPVFMgZGF0YSBjaGFubmVsIGlzLCB0aGUgRE9UUyBj bGllbnQgZG9lcyBub3Qga25vdyB0aGUgaW50ZXJmYWNlIGRldGFpbHMNCiAgIG9uIHRoZSBERG9T IG1pdGlnYXRvciwgc28gdXNpbmcgdGhlIHlhbmcgbW9kZWwgaW4gZHJhZnQtaWV0Zi1uZXRtb2Qt YWNsLW1vZGVsLTE0DQogICBtdWx0aXBsZSBBQ0xzIGZyb20gdGhlIERPVFMgY2xpZW50IGNhbm5v dCBiZSBvcmRlcmVkLg0KDQozLiBJZiB0aGUgV0cgYWdyZWVzIG9uIHRoZSByZXF1aXJlbWVudCB0 byBzdXBwb3J0IG11bHRpcGxlIG9yZGVyZWQgQUNMcyBmcm9tIHRoZSBET1RTIGNsaWVudCwgSSBj YW4NCiAgIGV4dGVuZCB0aGUgWUFORyBtb2RlbCB0byBvcmRlciBtdWx0aXBsZSBBQ0xzIGZyb20g dGhlIERPVFMgY2xpZW50Lg0KDQogIEZvbGxvd2luZyBpcyBhIHNpbXBsZSBleHRlbnNpb24gdG8g dGhlIHlhbmcgbW9kZWwgdG8gaGFuZGxlIG9yZGVyaW5nIG9mIEFDTHM6DQoNCiAgYXVnbWVudCAv aWV0Zi1hY2w6YWNjZXNzLWxpc3RzOg0KICAgICstLXJ3IGFjbC1vcmRlcg0KICAgICAgICstLXJ3 IGFjbC1zZXQqIFtzZXQtbmFtZSB0eXBlXQ0KICAgICAgICAgICstLXJ3IHNldC1uYW1lICAgIC0+ IC9pZXRmLWFjbDphY2Nlc3MtbGlzdHMvYWNsL2FjbC1uYW1lDQogICAgICAgICAgKy0tcncgdHlw ZSAgICAgICAgLT4gL2lldGYtYWNsOmFjY2Vzcy1saXN0cy9hY2wvYWNsLXR5cGUNCg0KLVRpcnUN Cg0KRnJvbTogRG90cyBbbWFpbHRvOmRvdHMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9m IEpvbiBTaGFsbG93DQpTZW50OiBTYXR1cmRheSwgTm92ZW1iZXIgNCwgMjAxNyAxMDowMiBQTQ0K VG86IEtvbmRhLCBUaXJ1bWFsZXN3YXIgUmVkZHkgPFRpcnVtYWxlc3dhclJlZGR5X0tvbmRhQE1j QWZlZS5jb20+OyBSb2xhbmQgRG9iYmlucyA8cmRvYmJpbnNAYXJib3IubmV0PjsgbW9oYW1lZC5i b3VjYWRhaXJAb3JhbmdlLmNvbTsgZG90c0BpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtEb3RzXSBO ZXcgRE9UUyBzaWduYWwgYW5kIGRhdGEgY2hhbm5lbCByZXF1aXJlbWVudHMNCg0KSGkgdGhlcmUs DQoNCkFzIEkgYW0gbW92aW5nIGJhY2sgaW50byBnZXR0aW5nIHRoZSBkYXRhIGNoYW5uZWwgZnVu Y3Rpb25hbGx5IHVwIGFuZCBydW5uaW5nLCBJIG5lZWQgdG8gcmV2aXNpdCB0aGlzIOKAkyBpbiBw YXJ0aWN1bGFyIHNvbWV0aGluZyBlbHNlIHRoYXQgd2FzIGluIHRoYXQgb3JpZ2luYWwgZW1haWwg dGhyZWFkIGp1c3QgYWZ0ZXIgd2hhdCBUaXJ1IGhhcyBxdW90ZWQgYmVsb3cuDQoNCuKAnEV2ZW4g aWYgdGhlIEZpbHRlcnMgYXJlIGhlbGQgb24gYSBwZXIgY2xpZW50IGlkZW50aXR5IGJhc2lzLCB0 aGVyZSBubyB3YXkgdG8gdXBsb2FkIGEgc2V0IG9mIGRpZmZlcmVudCBmaWx0ZXJzIGluIHBlYWNl IHRpbWUgcmVhZHkgZm9yIHNlbGVjdGlvbiBhcyB0byB3aGljaCBpcyBiZSB1c2VkIGluIGNhc2Ug b2YgRERvUyBBdHRhY2suICBXaGl0ZS9CbGFjayBsaXN0cyBhcmUgcHJvYmFibHkgZmFpcmx5IHN0 YXRpYywgaXQgaXMgdGhlIGN1c3RvbWl6YWJsZSBmaWx0ZXJzIHRoYXQgYXJlIHRoZSBpc3N1ZSBj dXJyZW50bHkgZm9yIG1lLuKAnQ0KDQpEbyB3ZSBuZWVkIHRvIGJlIGFibGUgdG8gYWRkIGluIHNl bGVjdGFibGUgQUNMIHN1cHBvcnQ/DQoNCkNsaWVudC1pZGVudGlmaWVyIGlzIG5vdyBzdXBwb3J0 ZWQgaW4gaWV0Zi1kb3RzLWFjY2Vzcy1jb250cm9sLWxpc3Q6YWNjZXNzLWxpc3RzLCBzbyBmaWx0 ZXJzIC8gYWNscyBhcmUgbm93IG1haW50YWluYWJsZSBvbiBhIHBlciBvcmlnaW5hbCBET1RTIGNs aWVudCBiYXNpcy4NCg0KSWYgYSBET1RTIGNsaWVudCBkZWZpbmVzIG11bHRpcGxlIGFjbHMgKGUu Zy4gd2hpdGUgbGlzdCwgYmxhY2sgbGlzdCBhbmQgY3VzdG9tIGFjbHMpLCB0aGVyZSBpcyBub3cg dGhlIHBvc3NpYmlsaXR5IG9mIHRoZW0gYmVpbmcgc2VudCB0byB0aGUgRE9UUyBtaXRpZ2F0b3Ig aW4gYSBzb3J0ZWQgb3JkZXIuICBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFm dC1pZXRmLW5ldG1vZC1hY2wtbW9kZWwvIGhhcyBhZGRlZCDigJxpbnRlcmZhY2Vz4oCdIHVuZGVy IOKAnGFjY2Vzcy1saXN0c+KAnSwgYW5kIHVuZGVyIOKAnGludGVyZmFjZXPigJ0gaXMg4oCcaW5n cmVzc+KAnSB3aGVyZSB5b3UgY2FuIGRlZmluZSBhbiBvcmRlcmVkIHNldCBvZiDigJxhY2wtc2V0 c+KAnSBpbiB3aGljaCBlYWNoIOKAnHNldC1uYW1l4oCdIHJlZmVycyBiYWNrIHRvIHRoZSDigJxh Y2wtbmFtZeKAnSBzaXR0aW5nIHVuZGVyIOKAnGFjbOKAnSwgc2l0dGluZyB1bmRlciDigJxhY2Nl c3MtbGlzdHPigJ0uDQoNCm1vZHVsZTogaWV0Zi1hY2Nlc3MtY29udHJvbC1saXN0DQogICAgICst LXJ3IGFjY2Vzcy1saXN0cw0KICAgICAgICArLS1ydyBhY2wqIFthY2wtdHlwZSBhY2wtbmFtZV0N CiAgICAgICAgfCAgKy0tcncgYWNsLW5hbWUgICAgc3RyaW5nDQrigKYNCiAgICAgICArLS1ydyBp bnRlcmZhY2VzDQogICAgICAgICAgICstLXJ3IGludGVyZmFjZSogW2ludGVyZmFjZS1pZF0NCiAg ICAgICAgICAgICAgKy0tcncgaW50ZXJmYWNlLWlkICAgIGlmOmludGVyZmFjZS1yZWYNCiAgICAg ICAgICAgICAgKy0tcncgaW5ncmVzcw0KICAgICAgICAgICAgICB8ICArLS1ydyBhY2wtc2V0cw0K ICAgICAgICAgICAgICB8ICAgICArLS1ydyBhY2wtc2V0KiBbc2V0LW5hbWUgdHlwZV0NCiAgICAg ICAgICAgICAgfCAgICAgICAgKy0tcncgc2V0LW5hbWUgICAgLT4gLi4vLi4vLi4vLi4vLi4vLi4v YWNsL2FjbC1uYW1lDQrigKYNCg0KSG93ZXZlciwgZm9yIGVhY2ggRE9UUyBjbGllbnQsIHdlIGNh biBvbmx5IGhhdmUgb25lIGlldGYtZG90cy1hY2Nlc3MtY29udHJvbC1saXN0IHdoaWNoIG9ubHkg YWxsb3dzIGZvciBvbmUgaWV0Zi1hY2Nlc3MtY29udHJvbC1saXN0LiAgU28gaXQgbm90IHBvc3Np YmxlIHRvIGJ1aWxkIHVwIGEgbGlicmFyeSBvZiBkaWZmZXJlbnQgYWNscywgb25lIG9mIHdoaWNo IGNhbiBiZSBzZWxlY3RlZCBieSB0aGUgRE9UUyBjbGllbnQgYXMgYSDigJxoaW504oCdIHRvIGdl dCBmb3J3YXJkZWQgb250byAgdGhlIERPVFMgbWl0aWdhdG9yLiAgRHVyaW5nIHRpbWVzIG9mIGF0 dGFjaywgaXQgbWF5IGJlIGRpZmZpY3VsdCAvIGltcG9zc2libGUgdG8gdXBkYXRlIHRoZSBhY2wg YmVjYXVzZSBvZiBUQ1AgZmFpbHVyZXMuDQoNCkkgYWdyZWUgdGhhdCB3ZSBjYW5ub3QgZXhwZWN0 IHRoZXJlIHRvIGJlIG11Y2ggaW50ZWxsaWdlbmNlIGluIHRoZSBET1RTIGNsaWVudC4gIEhvd2V2 ZXIgaW4gRE9UUyB1c2UgY2FzZXMsIOKAnDMuMS4xLiAgRW5kLWN1c3RvbWVyIHdpdGggYSBzaW5n bGUgdXBzdHJlYW0gdHJhbnNpdCBwcm92aWRlciBvZmZlcmluZyBERG9TIG1pdGlnYXRpb24gc2Vy dmljZXPigJ0gdGhlcmUgaXMgcmVmZXJlbmNlIHRvIHRoZSBjdXN0b21lciBoYXZpbmcgYW4gaW50 ZWxsaWdlbnQgRERvUyBNaXRpZ2F0aW9uIHN5c3RlbSAoSURNUykuICBUaGlzIElETVMgY291bGQg Z2l2ZSDigJxoaW50c+KAnS4NCg0KVGhlIERPVFMgc2lnbmFsIG1pdGlnYXRlIHByb3RvY29sIHN1 cHBvcnRzIGFsaWFzLW5hbWVzLCBidXQgbm90IGZpbHRlcnMgb3IgYWNscy4gIFdlIGNvdWxkDQoN CjEpICAgICAgQWRkIGluIGZpbHRlciBpbnZva2luZyBzdXBwb3J0IGludG8gdGhlIERPVFMgc2ln bmFsIG1pdGlnYXRlIHByb3RvY29sIGFuZCBleHRlbmQgaWV0Zi1kb3RzLWFjY2Vzcy1jb250cm9s LWxpc3QNCg0KMikgICAgICBFeHRlbmQgdGhlIGFsaWFzIGRlZmluaXRpb24gaW4gdGhlIGRhdGEg Y2hhbm5lbCBkZWZpbml0aW9ucyB0byBpbmNsdWRlIG90aGVyIHBhcmFtZXRlcnMgc3VwcG9ydGVk IGJ5IG5ldG1vZC1hY2wtbW9kZWwNCg0KSWRlYXMgLyBzdWdnZXN0aW9ucz8NCg0KUmVnYXJkcw0K DQpKb24NCg0KDQoNCg0KDQpGcm9tOiBEb3RzIFttYWlsdG86IGRvdHMtYm91bmNlc0BpZXRmLm9y ZzxtYWlsdG86ZG90cy1ib3VuY2VzQGlldGYub3JnPl0gT24gQmVoYWxmIE9mIEtvbmRhLCBUaXJ1 bWFsZXN3YXIgUmVkZHkNClNlbnQ6IDEwIE9jdG9iZXIgMjAxNyAxMzoyMg0KVG86IEpvbiBTaGFs bG93OyBtb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tPG1haWx0bzptb2hhbWVkLmJvdWNhZGFp ckBvcmFuZ2UuY29tPjsgZG90c0BpZXRmLm9yZzxtYWlsdG86ZG90c0BpZXRmLm9yZz47IFJvbGFu ZCBEb2JiaW5zDQpTdWJqZWN0OiBbRG90c10gTmV3IERPVFMgc2lnbmFsIGFuZCBkYXRhIGNoYW5u ZWwgcmVxdWlyZW1lbnRzDQoNClN0YXJ0aW5nIGEgbmV3IHRocmVhZCB0byBkaXNjdXNzIHRoZSBi ZWxvdyBuZXcgcmVxdWlyZW1lbnQgZnJvbSBKb246DQoNCltKb25dIEkgaGF2ZSByZS1yZWFkIHRo ZSByZXF1aXJlbWVudHMgLyBhcmNoaXRlY3R1cmUgZHJhZnRzLiAgSSBhZ3JlZSB0aGF0IGN1cnJl bnRseSB0aGUgV2hpdGUvQmxhY2svRmlsdGVyIGRlZmluaXRpb25zIGhhdmUgbm8gZGVwZW5kZW5j eSBvbiB0aGUgbWl0aWdhdGlvbiByZXF1ZXN0IOKAkyBpdCBpcyB1cCB0byB0aGUgRE9UUyBzZXJ2 ZXIgKEdXIG9yIG5vdCkgYXMgdG8gaG93IHRoZSBXaGl0ZS9CbGFjay9GaWx0ZXIgZGVmaW5pdGlv bnMgZ2V0IHBhc3NlZCBvbiB0byBET1RTIG1pdGlnYXRvciAob3V0IG9mIHNwZWMpLCBidXQgdGhl IERPVFMgc2VydmVyIG5lZWRzIHRvIGtub3cgd2hpY2ggb2YgdGhlIFdoaXRlL0JsYWNrL0ZpbHRl ciBkZWZpbml0aW9ucyBhcmUgcmVsZXZhbnQgd2hlbiBhIG1pdGlnYXRpb24gcmVxdWVzdCBjb21l cyBpbi4gIEN1cnJlbnRseSwgaXQgaXMgcG9zc2libGUgZm9yIHRoZSBET1RTIFNlcnZlciB0byBo b2xkIFdoaXRlL0JsYWNrL0ZpbHRlciBkZWZpbml0aW9ucyBvbiBhIHBlciBjbGllbnQgaWRlbnRp dHkuICBXaGVuIHRoZSBXaGl0ZS9CbGFjay9GaWx0ZXIgZGVmaW5pdGlvbnMgYXJlIHBhc3NlZCBm cm9tIGEgR1cgQ2xpZW50IHNpZGUgdG8gYSBHVyBzZXJ2ZXIgc2lkZSBhbmQgb24gdG8gdGhlIG5l eHQgRE9UUyBzZXJ2ZXIsIEdXIHNlcnZlciBzaWRlIGhhcyB0byBjb252ZXkgYWxzbyBzb21ldGhp bmcgYWJvdXQgdGhlIGNsaWVudHMgb24gdGhlIEdXIGNsaWVudCBzaWRlIGZvciB0aGUgRE9UUyBz ZXJ2ZXIgdG8gbWFpbnRhaW4gdGhlIFdoaXRlL0JsYWNrL0ZpbHRlciBkZWZpbml0aW9ucyBvbiBh IHBlciBwc2V1ZG8g4oCcY2xpZW50IGlkZW50aXR54oCdIOKAkyBzbyB3aGVuIHRoZSBtaWdyYXRp b24gcmVxdWVzdCBpcyBwYXNzZWQgdG8gdGhlIERPUyBzZXJ2ZXIgdmlhIGEgR1cgaXQga25vd3Mg d2hhdCBXaGl0ZS9CbGFjay9GaWx0ZXIgZGVmaW5pdGlvbnMgdG8gYXBwbHkgdG8gdGhhdCBtaXRp Z2F0aW9uIHJlcXVlc3QuDQoNCi1UaXJ1DQoNCg== --_000_DM5PR16MB1788CB569C96726D6E417E59EA560DM5PR16MB1788namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkRlbmdYaWFuOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAx IDE7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIgMTUg NSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IlxARGVuZ1hpYW4i Ow0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZh bWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7fQ0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiU2Vnb2UgVUkiOw0KCXBhbm9zZS0xOjIgMTEgNSAyIDQgMiA0IDIg MiAzO30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFs LCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0K CWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsc2VyaWY7 fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJ Y29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bh bi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5Nc29BY2V0YXRlLCBsaS5N c29BY2V0YXRlLCBkaXYuTXNvQWNldGF0ZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNv LXN0eWxlLWxpbms6IkJhbGxvb24gVGV4dCBDaGFyIjsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1i b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6OC4wcHQ7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIs c2Fucy1zZXJpZjt9DQpwLk1zb0xpc3RQYXJhZ3JhcGgsIGxpLk1zb0xpc3RQYXJhZ3JhcGgsIGRp di5Nc29MaXN0UGFyYWdyYXBoDQoJe21zby1zdHlsZS1wcmlvcml0eTozNDsNCgltYXJnaW4tdG9w OjBpbjsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1hcmdpbi1ib3R0b206MGluOw0KCW1hcmdpbi1s ZWZ0Oi41aW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJ Zm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsc2VyaWY7fQ0KcC5tc29ub3JtYWwwLCBsaS5t c29ub3JtYWwwLCBkaXYubXNvbm9ybWFsMA0KCXttc28tc3R5bGUtbmFtZTptc29ub3JtYWw7DQoJ bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowaW47DQoJZm9udC1zaXplOjEyLjBwdDsN Cglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9DQpzcGFuLkJhbGxvb25UZXh0 Q2hhcg0KCXttc28tc3R5bGUtbmFtZToiQmFsbG9vbiBUZXh0IENoYXIiOw0KCW1zby1zdHlsZS1w cmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiQmFsbG9vbiBUZXh0IjsNCglmb250LWZhbWls eToiU2Vnb2UgVUkiLHNhbnMtc2VyaWY7fQ0Kc3Bhbi5UZXh0ZWRlYnVsbGVzQ2FyDQoJe21zby1z dHlsZS1uYW1lOiJUZXh0ZSBkZSBidWxsZXMgQ2FyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7 DQoJbXNvLXN0eWxlLWxpbms6IlRleHRlIGRlIGJ1bGxlcyI7DQoJZm9udC1mYW1pbHk6IlRhaG9t YSIsc2Fucy1zZXJpZjt9DQpwLlRleHRlZGVidWxsZXMsIGxpLlRleHRlZGVidWxsZXMsIGRpdi5U ZXh0ZWRlYnVsbGVzDQoJe21zby1zdHlsZS1uYW1lOiJUZXh0ZSBkZSBidWxsZXMiOw0KCW1zby1z dHlsZS1saW5rOiJUZXh0ZSBkZSBidWxsZXMgQ2FyIjsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1i b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBO ZXcgUm9tYW4iLHNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTIzDQoJe21zby1zdHlsZS10eXBlOnBl cnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOiMxRjQ5 N0Q7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjQNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9u dC1mYW1pbHk6IkNvdXJpZXIgTmV3IjsNCgljb2xvcjpibGFjazsNCglmb250LXdlaWdodDpub3Jt YWw7DQoJZm9udC1zdHlsZTpub3JtYWw7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjUNCgl7bXNvLXN0eWxl LXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29s b3I6d2luZG93dGV4dDt9DQpzcGFuLkVtYWlsU3R5bGUyNg0KCXttc28tc3R5bGUtdHlwZTpwZXJz b25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjojMUY0OTdE O30NCnNwYW4uRW1haWxTdHlsZTI3DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQt ZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0Kc3Bhbi5F bWFpbFN0eWxlMjgNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNh bGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFuLkVtYWlsU3R5bGUyOQ0K CXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1z ZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCnNwYW4uRW1haWxTdHlsZTMwDQoJe21zby1zdHls ZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNv bG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5FbWFpbFN0eWxlMzENCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29u YWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4 dDt9DQpzcGFuLkVtYWlsU3R5bGUzMg0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250 LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4uRW1h aWxTdHlsZTMzDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxp YnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0Kc3Bhbi5FbWFpbFN0eWxlMzQN Cgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMt c2VyaWY7DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFuLkVtYWlsU3R5bGUzNQ0KCXttc28tc3R5bGUt dHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsN Cgljb2xvcjp3aW5kb3d0ZXh0O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4 cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3Np emU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYu V29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi8qIExpc3QgRGVmaW5pdGlvbnMg Ki8NCkBsaXN0IGwwDQoJe21zby1saXN0LWlkOjI1MjQwMDQ1NTsNCgltc28tbGlzdC10eXBlOmh5 YnJpZDsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6LTE1MTU4MTQyNTQgMTM0ODA3NTY5IDEzNDgw NzU3NyAxMzQ4MDc1NzkgMTM0ODA3NTY3IDEzNDgwNzU3NyAxMzQ4MDc1NzkgMTM0ODA3NTY3IDEz NDgwNzU3NyAxMzQ4MDc1Nzk7fQ0KQGxpc3QgbDA6bGV2ZWwxDQoJe21zby1sZXZlbC10ZXh0OiIl MVwpIjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0 aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0IGwwOmxldmVsMg0KCXttc28t bGV2ZWwtbnVtYmVyLWZvcm1hdDphbHBoYS1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9u ZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWlu O30NCkBsaXN0IGwwOmxldmVsMw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpyb21hbi1sb3dl cjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9u OnJpZ2h0Ow0KCXRleHQtaW5kZW50Oi05LjBwdDt9DQpAbGlzdCBsMDpsZXZlbDQNCgl7bXNvLWxl dmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRl eHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsMDpsZXZlbDUNCgl7bXNvLWxldmVsLW51bWJlci1m b3JtYXQ6YWxwaGEtbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVs LW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsMDps ZXZlbDYNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6cm9tYW4tbG93ZXI7DQoJbXNvLWxldmVs LXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpyaWdodDsNCgl0ZXh0 LWluZGVudDotOS4wcHQ7fQ0KQGxpc3QgbDA6bGV2ZWw3DQoJe21zby1sZXZlbC10YWItc3RvcDpu b25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1 aW47fQ0KQGxpc3QgbDA6bGV2ZWw4DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmFscGhhLWxv d2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRp b246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDA6bGV2ZWw5DQoJe21zby1s ZXZlbC1udW1iZXItZm9ybWF0OnJvbWFuLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25l Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246cmlnaHQ7DQoJdGV4dC1pbmRlbnQ6LTkuMHB0 O30NCm9sDQoJe21hcmdpbi1ib3R0b206MGluO30NCnVsDQoJe21hcmdpbi1ib3R0b206MGluO30N Ci0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6 ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBn dGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2 OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0t LT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxl Ij4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWYiPkhpIEpvbiw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+WW91ciBtYWlsIGlzIGRpc2N1c3Np bmcgdHdvIGRpZmZlcmVudCBpc3N1ZXMsIEkgd2lsbCBmb2N1cyBvbiBvbmUgb2YgdGhlbSBpbiB0 aGlzIHRocmVhZDo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+MS4gVGhlIEFDRXMgaW4gYSBBQ0wgY2FuIGJlIG9y ZGVyZWQgdXNpbmcgdGhlICZxdW90O2luc2VydCZxdW90OyBxdWVyeSBwYXJhbWV0ZXIgZGlzY3Vz c2VkIGluIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM4MDQwI3NlY3Rpb24tNC44LjUu DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWYiPiZuYnNwOyZuYnNwOyZuYnNwO1RoZSBsaXN0ICZxdW90O2FjZSZxdW90OyBpbiBjb250 YWluZXIgJnF1b3Q7YWNlcyZxdW90OyBoYXMgdGhlICdvcmRlcmVkLWJ5LXVzZXInIHN0YXRlbWVu dCwgc28gQUNFcyBpbiBhIEFDTCBjYW4gb3JkZXJlZCB1c2luZyBSRVNUQ09ORi48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZiI+Mi4gSG93ZXZlciwgbGlzdCAmcXVvdDthY2wmcXVvdDsgaW4gY29udGFpbmVyICZxdW90 O2FjY2Vzcy1saXN0cyZxdW90OyBkb2VzIG5vdCBoYXZlIHRoZSAnb3JkZXJlZC1ieS11c2VyJyBz dGF0ZW1lbnQsIGJ1dCBBQ0xzIGNhbiBiZSBvcmRlcmVkIHdoZW4gYXBwbGllZCB0byBhbiBpbnRl cmZhY2UuDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWYiPiZuYnNwOyZuYnNwOyZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7VGhl IHByb2JsZW0gd2l0aCBET1RTIGRhdGEgY2hhbm5lbCBpcywgdGhlIERPVFMgY2xpZW50IGRvZXMg bm90IGtub3cgdGhlIGludGVyZmFjZSBkZXRhaWxzPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDsmbmJzcDsgb24gdGhlIERE b1MgbWl0aWdhdG9yLCBzbyB1c2luZyB0aGUgeWFuZyBtb2RlbCBpbiBkcmFmdC1pZXRmLW5ldG1v ZC1hY2wtbW9kZWwtMTQNCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7bXVsdGlwbGUgQUNMcyBmcm9t IHRoZSBET1RTIGNsaWVudCBjYW5ub3QgYmUgb3JkZXJlZC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+My4gSWYg dGhlIFdHIGFncmVlcyBvbiB0aGUgcmVxdWlyZW1lbnQgdG8gc3VwcG9ydCBtdWx0aXBsZSBvcmRl cmVkIEFDTHMgZnJvbSB0aGUgRE9UUyBjbGllbnQsIEkgY2FuPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDsmbmJzcDsgZXh0 ZW5kIHRoZSBZQU5HIG1vZGVsIHRvIG9yZGVyIG11bHRpcGxlIEFDTHMgZnJvbSB0aGUgRE9UUyBj bGllbnQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOyBGb2xsb3dpbmcgaXMgYSBzaW1wbGUgZXh0ZW5z aW9uIHRvIHRoZSB5YW5nIG1vZGVsIHRvIGhhbmRsZSBvcmRlcmluZyBvZiBBQ0xzOjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmIj4mbmJzcDsgYXVnbWVudCAvaWV0Zi1hY2w6YWNjZXNzLWxpc3RzOjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7 Jm5ic3A7Jm5ic3A7ICYjNDM7LS1ydyBhY2wtb3JkZXI8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyAmIzQzOy0tcncgYWNsLXNldCogW3NldC1uYW1lIHR5cGVdPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4m bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJiM0 MzstLXJ3IHNldC1uYW1lJm5ic3A7Jm5ic3A7Jm5ic3A7IC0mZ3Q7IC9pZXRmLWFjbDphY2Nlc3Mt bGlzdHMvYWNsL2FjbC1uYW1lPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgJiM0MzstLXJ3IHR5cGUmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgLSZndDsgL2lldGYtYWNsOmFjY2Vzcy1saXN0cy9hY2wvYWNs LXR5cGU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZiI+LVRpcnU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48YSBuYW1lPSJfTWFpbEVuZENvbXBvc2UiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9hPjwvcD4NCjxzcGFuIHN0eWxlPSJtc28tYm9va21h cms6X01haWxFbmRDb21wb3NlIj48L3NwYW4+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3Jk ZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNC4wcHQiPg0KPGRp dj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBw dDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+IERvdHMgW21h aWx0bzpkb3RzLWJvdW5jZXNAaWV0Zi5vcmddDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPkpvbiBTaGFs bG93PGJyPg0KPGI+U2VudDo8L2I+IFNhdHVyZGF5LCBOb3ZlbWJlciA0LCAyMDE3IDEwOjAyIFBN PGJyPg0KPGI+VG86PC9iPiBLb25kYSwgVGlydW1hbGVzd2FyIFJlZGR5ICZsdDtUaXJ1bWFsZXN3 YXJSZWRkeV9Lb25kYUBNY0FmZWUuY29tJmd0OzsgUm9sYW5kIERvYmJpbnMgJmx0O3Jkb2JiaW5z QGFyYm9yLm5ldCZndDs7IG1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb207IGRvdHNAaWV0Zi5v cmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtEb3RzXSBOZXcgRE9UUyBzaWduYWwgYW5kIGRh dGEgY2hhbm5lbCByZXF1aXJlbWVudHM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Qi PkhpIHRoZXJlLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZjtjb2xvcjojMUY0OTdEIj5BcyBJIGFtIG1vdmluZyBiYWNrIGludG8gZ2V0dGluZyB0 aGUgZGF0YSBjaGFubmVsIGZ1bmN0aW9uYWxseSB1cCBhbmQgcnVubmluZywgSSBuZWVkIHRvIHJl dmlzaXQgdGhpcyDigJMgaW4gcGFydGljdWxhciBzb21ldGhpbmcgZWxzZSB0aGF0IHdhcyBpbg0K IHRoYXQgb3JpZ2luYWwgZW1haWwgdGhyZWFkIGp1c3QgYWZ0ZXIgd2hhdCBUaXJ1IGhhcyBxdW90 ZWQgYmVsb3cuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOiMxRjQ5N0QiPuKAnEV2ZW4gaWYgdGhlIEZpbHRlcnMgYXJlIGhlbGQgb24g YSBwZXIgY2xpZW50IGlkZW50aXR5IGJhc2lzLCB0aGVyZSBubyB3YXkgdG8gdXBsb2FkIGEgc2V0 IG9mIGRpZmZlcmVudCBmaWx0ZXJzIGluIHBlYWNlIHRpbWUgcmVhZHkgZm9yIHNlbGVjdGlvbg0K IGFzIHRvIHdoaWNoIGlzIGJlIHVzZWQgaW4gY2FzZSBvZiBERG9TIEF0dGFjay4mbmJzcDsgV2hp dGUvQmxhY2sgbGlzdHMgYXJlIHByb2JhYmx5IGZhaXJseSBzdGF0aWMsIGl0IGlzIHRoZSBjdXN0 b21pemFibGUgZmlsdGVycyB0aGF0IGFyZSB0aGUgaXNzdWUgY3VycmVudGx5IGZvciBtZS7igJ0N CjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtj b2xvcjojMUY0OTdEIj5EbyB3ZSBuZWVkIHRvIGJlIGFibGUgdG8gYWRkIGluIHNlbGVjdGFibGUg QUNMIHN1cHBvcnQ/PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIg c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkNsaWVudC1pZGVudGlmaWVyIGlzIG5vdyBzdXBwb3J0 ZWQgaW4gaWV0Zi1kb3RzLWFjY2Vzcy1jb250cm9sLWxpc3Q6YWNjZXNzLWxpc3RzLCBzbyBmaWx0 ZXJzIC8gYWNscyBhcmUgbm93IG1haW50YWluYWJsZSBvbiBhIHBlciBvcmlnaW5hbCBET1RTIGNs aWVudA0KIGJhc2lzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0Ii IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5JZiBhIERPVFMgY2xpZW50IGRlZmluZXMgbXVsdGlw bGUgYWNscyAoZS5nLiB3aGl0ZSBsaXN0LCBibGFjayBsaXN0IGFuZCBjdXN0b20gYWNscyksIHRo ZXJlIGlzIG5vdyB0aGUgcG9zc2liaWxpdHkgb2YgdGhlbSBiZWluZyBzZW50IHRvIHRoZSBET1RT DQogbWl0aWdhdG9yIGluIGEgc29ydGVkIG9yZGVyLiAmbmJzcDs8YSBocmVmPSJodHRwczovL2Rh dGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLW5ldG1vZC1hY2wtbW9kZWwvIj5odHRw czovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLW5ldG1vZC1hY2wtbW9kZWwv PC9hPiBoYXMgYWRkZWQg4oCcaW50ZXJmYWNlc+KAnSB1bmRlciDigJxhY2Nlc3MtbGlzdHPigJ0s IGFuZCB1bmRlciDigJxpbnRlcmZhY2Vz4oCdIGlzIOKAnGluZ3Jlc3PigJ0gd2hlcmUgeW91DQog Y2FuIGRlZmluZSBhbiBvcmRlcmVkIHNldCBvZiDigJxhY2wtc2V0c+KAnSBpbiB3aGljaCBlYWNo IOKAnHNldC1uYW1l4oCdIHJlZmVycyBiYWNrIHRvIHRoZSDigJxhY2wtbmFtZeKAnSBzaXR0aW5n IHVuZGVyIOKAnGFjbOKAnSwgc2l0dGluZyB1bmRlciDigJxhY2Nlc3MtbGlzdHPigJ0uPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0Ii IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZTo4 LjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjojMUY0OTdEIj5t b2R1bGU6IGlldGYtYWNjZXNzLWNvbnRyb2wtbGlzdDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjgu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmIzQzOy0tcncgYWNjZXNzLWxpc3RzPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxl PSJmb250LXNpemU6OC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29s b3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICYj NDM7LS1ydyBhY2wqIFthY2wtdHlwZSBhY2wtbmFtZV08bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZTo4 LjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjojMUY0OTdEIj4m bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyAmIzQzOy0t cncgYWNsLW5hbWUmbmJzcDsmbmJzcDsmbmJzcDsgc3RyaW5nPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNp emU6OC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6IzFGNDk3 RCI+4oCmPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6OC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291 cmllciBOZXcmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7JiM0MzstLXJ3IGludGVyZmFjZXM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6 ZTo4LjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjojMUY0OTdE Ij4mbmJzcDsmbmJzcDsgJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7JiM0MzstLXJ3IGludGVyZmFjZSogW2ludGVyZmFjZS1pZF08bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZv bnQtc2l6ZTo4LjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjoj MUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJiM0MzstLXJ3IGludGVyZmFjZS1pZCZuYnNw OyZuYnNwOyZuYnNwOyBpZjppbnRlcmZhY2UtcmVmPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6OC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7ICYjNDM7LS1ydyBpbmdyZXNzPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNp emU6OC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6IzFGNDk3 RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsgJiM0MzstLXJ3IGFjbC1zZXRzPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0Ii IHN0eWxlPSJmb250LXNpemU6OC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVv dDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgJiM0MzstLXJ3IGFjbC1zZXQqIFtzZXQtbmFtZSB0eXBlXTxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0i Zm9udC1zaXplOjguMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9y OiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7ICYjNDM7LS1ydyBzZXQtbmFtZSZuYnNwOyZuYnNwOyZuYnNwOyAt Jmd0OyAuLi8uLi8uLi8uLi8uLi8uLi9hY2wvYWNsLW5hbWU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6 ZTo4LjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjojMUY0OTdE Ij7igKY8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWY7Y29sb3I6IzFGNDk3RCI+SG93ZXZlciwgZm9yIGVhY2ggRE9UUyBjbGllbnQsIHdlIGNhbiBv bmx5IGhhdmUgb25lIGlldGYtZG90cy1hY2Nlc3MtY29udHJvbC1saXN0IHdoaWNoIG9ubHkgYWxs b3dzIGZvciBvbmUgaWV0Zi1hY2Nlc3MtY29udHJvbC1saXN0LiZuYnNwOyBTbyBpdCBub3QNCiBw b3NzaWJsZSB0byBidWlsZCB1cCBhIGxpYnJhcnkgb2YgZGlmZmVyZW50IGFjbHMsIG9uZSBvZiB3 aGljaCBjYW4gYmUgc2VsZWN0ZWQgYnkgdGhlIERPVFMgY2xpZW50IGFzIGEg4oCcaGludOKAnSB0 byBnZXQgZm9yd2FyZGVkIG9udG8gJm5ic3A7dGhlIERPVFMgbWl0aWdhdG9yLiZuYnNwOyBEdXJp bmcgdGltZXMgb2YgYXR0YWNrLCBpdCBtYXkgYmUgZGlmZmljdWx0IC8gaW1wb3NzaWJsZSB0byB1 cGRhdGUgdGhlIGFjbCBiZWNhdXNlIG9mIFRDUCBmYWlsdXJlcy48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2Nv bG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+SSBhZ3Jl ZSB0aGF0IHdlIGNhbm5vdCBleHBlY3QgdGhlcmUgdG8gYmUgbXVjaCBpbnRlbGxpZ2VuY2UgaW4g dGhlIERPVFMgY2xpZW50LiZuYnNwOyBIb3dldmVyIGluIERPVFMgdXNlIGNhc2VzLCDigJwzLjEu MS4mbmJzcDsgRW5kLWN1c3RvbWVyIHdpdGggYSBzaW5nbGUgdXBzdHJlYW0NCiB0cmFuc2l0IHBy b3ZpZGVyIG9mZmVyaW5nIEREb1MgbWl0aWdhdGlvbiBzZXJ2aWNlc+KAnSB0aGVyZSBpcyByZWZl cmVuY2UgdG8gdGhlIGN1c3RvbWVyIGhhdmluZyBhbiBpbnRlbGxpZ2VudCBERG9TIE1pdGlnYXRp b24gc3lzdGVtIChJRE1TKS4mbmJzcDsgVGhpcyBJRE1TIGNvdWxkIGdpdmUg4oCcaGludHPigJ0u PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2Nv bG9yOiMxRjQ5N0QiPlRoZSBET1RTIHNpZ25hbCBtaXRpZ2F0ZSBwcm90b2NvbCBzdXBwb3J0cyBh bGlhcy1uYW1lcywgYnV0IG5vdCBmaWx0ZXJzIG9yIGFjbHMuJm5ic3A7IFdlIGNvdWxkPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJ0ZXh0 LWluZGVudDotLjI1aW47bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzIiPjwhW2lmICFzdXBwb3J0TGlz dHNdPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PHNwYW4gc3R5 bGU9Im1zby1saXN0Oklnbm9yZSI+MSk8c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1l cyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFu Pjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPjxzcGFuIGRpcj0iTFRSIj48L3NwYW4+PHNwYW4gbGFu Zz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5BZGQgaW4gZmlsdGVyIGludm9raW5n IHN1cHBvcnQgaW50byB0aGUgRE9UUyBzaWduYWwgbWl0aWdhdGUgcHJvdG9jb2wgYW5kIGV4dGVu ZCBpZXRmLWRvdHMtYWNjZXNzLWNvbnRyb2wtbGlzdDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0idGV4dC1pbmRlbnQ6LS4yNWluO21zby1s aXN0OmwwIGxldmVsMSBsZm8yIj48IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBsYW5nPSJFTi1H QiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUi PjIpPHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4m bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2Vu ZGlmXT48c3BhbiBkaXI9IkxUUiI+PC9zcGFuPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7 Y29sb3I6IzFGNDk3RCI+RXh0ZW5kIHRoZSBhbGlhcyBkZWZpbml0aW9uIGluIHRoZSBkYXRhIGNo YW5uZWwgZGVmaW5pdGlvbnMgdG8gaW5jbHVkZSBvdGhlciBwYXJhbWV0ZXJzIHN1cHBvcnRlZCBi eSBuZXRtb2QtYWNsLW1vZGVsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPklkZWFzIC8gc3VnZ2VzdGlvbnM/PG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0Ii IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMx RjQ5N0QiPlJlZ2FyZHM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdC IiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Sm9uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0 OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0 OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9w OnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtUYWhvbWEmcXVvdDssc2Fucy1zZXJpZiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OyxzYW5z LXNlcmlmIj4gRG90cyBbbWFpbHRvOg0KPGEgaHJlZj0ibWFpbHRvOmRvdHMtYm91bmNlc0BpZXRm Lm9yZyI+ZG90cy1ib3VuY2VzQGlldGYub3JnPC9hPl0gPGI+T24gQmVoYWxmIE9mDQo8L2I+S29u ZGEsIFRpcnVtYWxlc3dhciBSZWRkeTxicj4NCjxiPlNlbnQ6PC9iPiAxMCBPY3RvYmVyIDIwMTcg MTM6MjI8YnI+DQo8Yj5Ubzo8L2I+IEpvbiBTaGFsbG93OyA8YSBocmVmPSJtYWlsdG86bW9oYW1l ZC5ib3VjYWRhaXJAb3JhbmdlLmNvbSI+bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbTwvYT47 DQo8YSBocmVmPSJtYWlsdG86ZG90c0BpZXRmLm9yZyI+ZG90c0BpZXRmLm9yZzwvYT47IFJvbGFu ZCBEb2JiaW5zPGJyPg0KPGI+U3ViamVjdDo8L2I+IFtEb3RzXSBOZXcgRE9UUyBzaWduYWwgYW5k IGRhdGEgY2hhbm5lbCByZXF1aXJlbWVudHM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+U3RhcnRpbmcgYSBuZXcgdGhyZWFkIHRvIGRp c2N1c3MgdGhlIGJlbG93IG5ldyByZXF1aXJlbWVudCBmcm9tIEpvbjo8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+W0pv bl0gSSBoYXZlIHJlLXJlYWQgdGhlIHJlcXVpcmVtZW50cyAvIGFyY2hpdGVjdHVyZSBkcmFmdHMu Jm5ic3A7IEkgYWdyZWUgdGhhdCBjdXJyZW50bHkgdGhlIFdoaXRlL0JsYWNrL0ZpbHRlciBkZWZp bml0aW9ucyBoYXZlIG5vIGRlcGVuZGVuY3kgb24gdGhlDQogbWl0aWdhdGlvbiByZXF1ZXN0IOKA kyBpdCBpcyB1cCB0byB0aGUgRE9UUyBzZXJ2ZXIgKEdXIG9yIG5vdCkgYXMgdG8gaG93IHRoZSBX aGl0ZS9CbGFjay9GaWx0ZXIgZGVmaW5pdGlvbnMgZ2V0IHBhc3NlZCBvbiB0byBET1RTIG1pdGln YXRvciAob3V0IG9mIHNwZWMpLCBidXQgdGhlIERPVFMgc2VydmVyIG5lZWRzIHRvIGtub3cgd2hp Y2ggb2YgdGhlIFdoaXRlL0JsYWNrL0ZpbHRlciBkZWZpbml0aW9ucyBhcmUgcmVsZXZhbnQgd2hl biBhIG1pdGlnYXRpb24NCiByZXF1ZXN0IGNvbWVzIGluLiZuYnNwOyBDdXJyZW50bHksIGl0IGlz IHBvc3NpYmxlIGZvciB0aGUgRE9UUyBTZXJ2ZXIgdG8gaG9sZCBXaGl0ZS9CbGFjay9GaWx0ZXIg ZGVmaW5pdGlvbnMgb24gYSBwZXIgY2xpZW50IGlkZW50aXR5LiZuYnNwOyBXaGVuIHRoZSBXaGl0 ZS9CbGFjay9GaWx0ZXIgZGVmaW5pdGlvbnMgYXJlIHBhc3NlZCBmcm9tIGEgR1cgQ2xpZW50IHNp ZGUgdG8gYSBHVyBzZXJ2ZXIgc2lkZSBhbmQgb24gdG8gdGhlIG5leHQgRE9UUyBzZXJ2ZXIsDQog R1cgc2VydmVyIHNpZGUgaGFzIHRvIGNvbnZleSBhbHNvIHNvbWV0aGluZyBhYm91dCB0aGUgY2xp ZW50cyBvbiB0aGUgR1cgY2xpZW50IHNpZGUgZm9yIHRoZSBET1RTIHNlcnZlciB0byBtYWludGFp biB0aGUgV2hpdGUvQmxhY2svRmlsdGVyIGRlZmluaXRpb25zIG9uIGEgcGVyIHBzZXVkbyDigJxj bGllbnQgaWRlbnRpdHnigJ0g4oCTIHNvIHdoZW4gdGhlIG1pZ3JhdGlvbiByZXF1ZXN0IGlzIHBh c3NlZCB0byB0aGUgRE9TIHNlcnZlciB2aWEgYSBHVyBpdA0KIGtub3dzIHdoYXQgV2hpdGUvQmxh Y2svRmlsdGVyIGRlZmluaXRpb25zIHRvIGFwcGx5IHRvIHRoYXQgbWl0aWdhdGlvbiByZXF1ZXN0 LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtj b2xvcjojMUY0OTdEIj4tVGlydTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_DM5PR16MB1788CB569C96726D6E417E59EA560DM5PR16MB1788namp_-- From nobody Tue Nov 7 23:38:20 2017 Return-Path: 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 E0BD1131548 for ; Tue, 7 Nov 2017 23:38:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.001 X-Spam-Level: X-Spam-Status: No, score=-7.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham 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 nL8FlGlGhWRS for ; Tue, 7 Nov 2017 23:38:16 -0800 (PST) Received: from MIVWSMAILOUT1.mcafee.com (mivwsmailout1.mcafee.com [161.69.47.167]) (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 8859513152A for ; Tue, 7 Nov 2017 23:38:16 -0800 (PST) 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=1510126695; 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: authentication-results:x-originating-ip:x-ms-publictraffictype: x-microsoft-exchange-diagnostics:x-ms-exchange-antispam-srfa-diagnostics: x-ms-office365-filtering-correlation-id:x-microsoft-antispam: x-ms-traffictypediagnostic:x-exchange-antispam-report-test: x-microsoft-antispam-prvs:x-exchange-antispam-report-cfa-test: x-forefront-prvs:x-forefront-antispam-report: received-spf:spamdiagnosticoutput:spamdiagnosticmetadata: 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-Transport-CrossTenantHeadersStamped: X-OriginatorOrg:X-NAI-Spam-Flag:X-NAI-Spam-Level: X-NAI-Spam-Threshold:X-NAI-Spam-Score:X-NAI-Spam-Version; bh=gHQ9Asa+15C7kwWg6EbzYuuXQvm67h7Vx05qv3 m8IYw=; b=LsW2NAnEv/fuhT0zWEmFvNcCVr8rv4VLVApiYSRP I7V0YE3PXg245B3NaCmYBIWCvLdVIdQqfw0I5dgHFjEQz4YB1x /LgC1eaWILIj/R/ssea2q7x40P+PrW2Cg0l174W//iONeRy2TW 569qW5FKYEfs28KZ5F88RavO6/DgmJE= Received: from MIVEXAPP1N01.corpzone.internalzone.com (mivexapp1n01.corpzone.internalzone.com [10.48.48.88]) by MIVWSMAILOUT1.mcafee.com with smtp id 7ea4_2987_802edb8d_7c39_4ece_9ab5_165c846846ec; Wed, 08 Nov 2017 01:38:15 -0600 Received: from MIVEXUSR1N07.corpzone.internalzone.com (10.48.48.87) by MIVEXAPP1N01.corpzone.internalzone.com (10.48.48.88) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Wed, 8 Nov 2017 02:38:06 -0500 Received: from MIVEXAPP1N02.corpzone.internalzone.com (10.48.48.89) by MIVEXUSR1N07.corpzone.internalzone.com (10.48.48.87) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Wed, 8 Nov 2017 02:38:05 -0500 Received: from MIVO365EDGE3.corpzone.internalzone.com (10.48.176.86) by MIVEXAPP1N02.corpzone.internalzone.com (10.48.48.89) with Microsoft SMTP Server (TLS) id 15.0.1347.2 via Frontend Transport; Wed, 8 Nov 2017 02:38:05 -0500 Received: from NAM03-CO1-obe.outbound.protection.outlook.com (10.48.176.240) by edge.mcafee.com (10.48.176.86) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Wed, 8 Nov 2017 02:38:02 -0500 Received: from DM5PR16MB1788.namprd16.prod.outlook.com (10.172.44.144) by DM5PR16MB1785.namprd16.prod.outlook.com (10.172.44.141) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.197.13; Wed, 8 Nov 2017 07:38:01 +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.20.0197.020; Wed, 8 Nov 2017 07:38:01 +0000 From: "Konda, Tirumaleswar Reddy" To: "'dots@ietf.org'" Thread-Topic: Minutes from the October-02-2017 Virtual Interim Meeting Thread-Index: AdM8VrzmSj2Cd2oFQI2oXkHy1FYAHgHnXhdQA8c03FA= Date: Wed, 8 Nov 2017 07:38:00 +0000 Message-ID: References: <359EC4B99E040048A7131E0F4E113AFC0104FE35B8@marathon> In-Reply-To: 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: [103.245.47.20] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DM5PR16MB1785; 6:n8btnis4AJIGaxRtrO+WyBFKruvmIcScQ6qvs5wEDfEx4cbvWMarbCNAmi2dceqd3SEWMyvfbCMOULLtjXFZTVLreTmTNY6wmioXwUz6CJhAfwx5yRDei8kl4/efpcCX/QXwkB9E2p1DqH22CofR2XLaJMr983g8XfihI3gTPGgzo4x8ZsipheWsN1VMa1joxGGjxzy7KtknEaXkkQaCPXhLe5ofFyl/5wkiMlrJJnIOT/RjOCQWJEu+vJovhYDaP3IHZ+UjyL8bLXcpZPPxAFSrgU12q3Q34MWpXSQJ1fLPo7JkiXXu4q2VxVfmaQ9dG+DLZIoX38UoYWsngSPG15T/btB+6/t8uDB5Gr3e+7c=; 5:6Kt5rsh236ZxJZvWnHQXLpHn5mmwMd1hthHq8bXZYVu/nyflF0NRJqOetwWhY4TqMv3MCNlzCTA3kId71bYw1fl25MmmITo5WGrGwPWLcA40L8FFmVR54kuZIZ4IsTVEsWU7phMLNdBmn/IIkoi5d0iIu1s4zEhFz1RkFv0Fo7s=; 24:pLsOo93mZqJL6SbUJ7gzAU93OdLQDJGYsIL8iAT8Sk/1CwaLjXMuaZX3AZUtqwh9TPZgBuNZ79QVwee7/dPybweRcF1+T7/E8aMwenRlDTg=; 7:eXCbRW3d+IjKje6N9lqkt4fV4sxxczSqNtar/KZsdwlaTR2yff6BdZZQcTUPsMhRBLnsEIEZXSWydzcl1Fs2sl/o9ZCjA+HxkdkkYGuA4Rm+sZJ3b8edvhBCpoIv1IIJB2Kg2lBnRPeJHPgd7G+T2ffJrSWK1UYkiJNkEvXLu1idlxLJtkkM3bcqQsR+4I9bCqGL6yvPG/UYw+udt4fbgtS8FqvTPgcbikMgTFEN/GqBM5mhNEaPY7Gw3HNTad8+ x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 4de70bab-aebc-4038-c7d3-08d5267ba3dd x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(2017052603199); SRVR:DM5PR16MB1785; x-ms-traffictypediagnostic: DM5PR16MB1785: x-exchange-antispam-report-test: UriScan:(120809045254105)(166708455590820)(198458107723671); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(5005006)(8121501046)(10201501046)(93006095)(93001095)(3002001)(3231021)(100000703101)(100105400095)(6041248)(20161123562025)(20161123555025)(20161123564025)(20161123560025)(20161123558100)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:DM5PR16MB1785; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:DM5PR16MB1785; x-forefront-prvs: 0485417665 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(346002)(376002)(189002)(13464003)(199003)(32952001)(105586002)(316002)(80792005)(86362001)(68736007)(6506006)(74316002)(189998001)(9686003)(97736004)(101416001)(230783001)(5660300001)(2900100001)(2950100002)(53936002)(33656002)(3846002)(7696004)(8676002)(81166006)(76176999)(72206003)(102836003)(8936002)(50986999)(54356999)(478600001)(229853002)(6116002)(6916009)(3660700001)(7736002)(66066001)(2906002)(3280700002)(81156014)(6436002)(106356001)(53546010)(305945005)(99286004)(55016002)(6306002)(14454004)(25786009)(6246003)(77096006)(966005)(85282002)(491001); DIR:OUT; SFP:1101; SCL:1; SRVR:DM5PR16MB1785; H:DM5PR16MB1788.namprd16.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; 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: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 4de70bab-aebc-4038-c7d3-08d5267ba3dd X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Nov 2017 07:38:01.2971 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4943e38c-6dd4-428c-886d-24932bc2d5de X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR16MB1785 X-OriginatorOrg: mcafee.com X-NAI-Spam-Flag: NO X-NAI-Spam-Level: X-NAI-Spam-Threshold: 15 X-NAI-Spam-Score: 0.1 X-NAI-Spam-Version: 2.3.0.9418 : core <6153> : inlines <6164> : streams <1769674> : uri <2530189> Archived-At: Subject: Re: [Dots] Minutes from the October-02-2017 Virtual Interim Meeting 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Nov 2017 07:38:19 -0000 > -----Original Message----- > From: Konda, Tirumaleswar Reddy > Sent: Monday, October 16, 2017 11:53 AM > To: 'dots@ietf.org' > Subject: RE: Minutes from the October-02-2017 Virtual Interim Meeting >=20 > The DOTS signal channel currently uses a default mitigation lifetime of 3= 600 > seconds, https://www.sans.org/reading-room/whitepapers/analyst/ddos- > attacks-advancing-enduring-survey-34700 report discusses that the most > common DDoS attacks lasted less than one hour (42%), although 14% > experienced attacks that lasted for up to one day and 13% for more than a > day (between one and three days). The weighted average for attack duratio= n > across all reported DDoS attacks is 8.7 hours, or an entire business day. >=20 > Based on the above survey, looks like the default mitigation lifetime in = the > spec is reasonable. If no objections to the default mitigation lifetime of 3600 seconds, I woul= d like to close this issue tracked in https://github.com/dotswg/dots-signal= -channel/issues/3. -Tiru >=20 > -Tiru >=20 > > -----Original Message----- > > From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Roman Danyliw > > Sent: Tuesday, October 3, 2017 8:21 PM > > To: 'dots@ietf.org' > > Subject: [Dots] Minutes from the October-02-2017 Virtual Interim > > Meeting > > > > Hello! > > > > Draft minutes from yesterday's (October 2, 2017) virtual interim > > meeting can be found here: > > > > https://datatracker.ietf.org/meeting/interim-2017-dots- > > 03/materials/minutes-interim-2017-dots-03-201710021000/ > > > > Thank you to all who attended. If you have corrections to the > > minutes, please send them to the chairs. > > > > Regards, > > Roman > > > > _______________________________________________ > > Dots mailing list > > Dots@ietf.org > > https://www.ietf.org/mailman/listinfo/dots From nobody Wed Nov 8 01:53:55 2017 Return-Path: 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 9DF0F13192B for ; Wed, 8 Nov 2017 01:53:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 04NTNSlzPt_D for ; Wed, 8 Nov 2017 01:53:52 -0800 (PST) Received: from mail.jpshallow.com (mail.jpshallow.com [217.40.240.153]) (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 010DF13192A for ; Wed, 8 Nov 2017 01:53:51 -0800 (PST) Received: from [127.0.0.1] (helo=N01332) by mail.jpshallow.com with smtps (TLSv1:ECDHE-RSA-AES256-SHA:256) (Exim 4.89) (envelope-from ) id 1eCN3M-00047Z-Us; Wed, 08 Nov 2017 09:53:49 +0000 From: "Jon Shallow" To: "'Konda, Tirumaleswar Reddy'" , References: <359EC4B99E040048A7131E0F4E113AFC0104FE35B8@marathon> In-Reply-To: Date: Wed, 8 Nov 2017 09:53:51 -0000 Message-ID: <01ae01d35877$7b82d280$72887780$@jpshallow.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQGh+lDsBRqaE9/TYPi748KiS/MjmQKRzEMFAUvW842jTg0aUA== Content-Language: en-gb Archived-At: Subject: Re: [Dots] Minutes from the October-02-2017 Virtual Interim Meeting 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Nov 2017 09:53:54 -0000 Fine for me. -----Original Message----- From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of Konda, Tirumaleswar Reddy Sent: 08 November 2017 07:38 To: 'dots@ietf.org' Subject: Re: [Dots] Minutes from the October-02-2017 Virtual Interim Meeting > -----Original Message----- > From: Konda, Tirumaleswar Reddy > Sent: Monday, October 16, 2017 11:53 AM > To: 'dots@ietf.org' > Subject: RE: Minutes from the October-02-2017 Virtual Interim Meeting > > The DOTS signal channel currently uses a default mitigation lifetime > of 3600 seconds, > https://www.sans.org/reading-room/whitepapers/analyst/ddos- > attacks-advancing-enduring-survey-34700 report discusses that the most > common DDoS attacks lasted less than one hour (42%), although 14% > experienced attacks that lasted for up to one day and 13% for more > than a day (between one and three days). The weighted average for > attack duration across all reported DDoS attacks is 8.7 hours, or an entire business day. > > Based on the above survey, looks like the default mitigation lifetime > in the spec is reasonable. If no objections to the default mitigation lifetime of 3600 seconds, I would like to close this issue tracked in https://github.com/dotswg/dots-signal-channel/issues/3. -Tiru > > -Tiru > > > -----Original Message----- > > From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Roman Danyliw > > Sent: Tuesday, October 3, 2017 8:21 PM > > To: 'dots@ietf.org' > > Subject: [Dots] Minutes from the October-02-2017 Virtual Interim > > Meeting > > > > Hello! > > > > Draft minutes from yesterday's (October 2, 2017) virtual interim > > meeting can be found here: > > > > https://datatracker.ietf.org/meeting/interim-2017-dots- > > 03/materials/minutes-interim-2017-dots-03-201710021000/ > > > > Thank you to all who attended. If you have corrections to the > > minutes, please send them to the chairs. > > > > Regards, > > Roman > > > > _______________________________________________ > > 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 From nobody Thu Nov 9 00:19:39 2017 Return-Path: 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 CC32212EC8D for ; Thu, 9 Nov 2017 00:19:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 6zLvXt352E0O for ; Thu, 9 Nov 2017 00:19:37 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 732E312EC70 for ; Thu, 9 Nov 2017 00:19:35 -0800 (PST) Received: from 172.18.7.190 (EHLO LHREML711-CAH.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DSG36962; Thu, 09 Nov 2017 08:19:32 +0000 (GMT) Received: from DGGEML405-HUB.china.huawei.com (10.3.17.49) by LHREML711-CAH.china.huawei.com (10.201.108.34) with Microsoft SMTP Server (TLS) id 14.3.361.1; Thu, 9 Nov 2017 08:19:31 +0000 Received: from DGGEML502-MBS.china.huawei.com ([169.254.3.68]) by dggeml405-hub.china.huawei.com ([10.3.17.49]) with mapi id 14.03.0361.001; Thu, 9 Nov 2017 16:19:26 +0800 From: "Xialiang (Frank)" To: kaname nishizuka , Jon Shallow CC: "dots@ietf.org" Thread-Topic: [Dots] Interoperability testing at the hackathon of the next IETF Thread-Index: AQHTVqBPN0rPQutEuEKyKu13HrJ8L6MLuFpw Date: Thu, 9 Nov 2017 08:19:25 +0000 Message-ID: References: In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.134.159.76] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A0B0208.5A040F94.015E, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.3.68, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 6db4a62cf4899baa215f0ea9f88fe14f Archived-At: Subject: [Dots] =?utf-8?b?562U5aSNOiAgSW50ZXJvcGVyYWJpbGl0eSB0ZXN0aW5nIGF0?= =?utf-8?q?_the_hackathon_of_the_next_IETF?= 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Nov 2017 08:19:39 -0000 SGkgS2FuYW1lIGFuZCBKb24sDQpXZSAoSHVhd2VpKSBhcmUgYWxzbyB2ZXJ5IGhhcHB5IHRvIGpv aW4gYW5kIGNvbnRyaWJ1dGUgdG8gaXQuDQpTbywgbG9va2luZyBmb3J3YXJkIHRvIHdvcmtpbmcg d2l0aCB5b3UgZnJvbSBTYXR1cmRheSBhbmQgbWFraW5nIG91ciBnb2FsIHN1Y2Nlc3NmdWwuDQoN CkIuUi4NCkZyYW5rDQoNCi0tLS0t6YKu5Lu25Y6f5Lu2LS0tLS0NCuWPkeS7tuS6ujogRG90cyBb bWFpbHRvOmRvdHMtYm91bmNlc0BpZXRmLm9yZ10g5Luj6KGoIGthbmFtZSBuaXNoaXp1a2ENCuWP kemAgeaXtumXtDogMjAxN+W5tDEx5pyINuaXpSA5OjQxDQrmlLbku7bkuro6IGRvdHNAaWV0Zi5v cmcNCuS4u+mimDogW0RvdHNdIEludGVyb3BlcmFiaWxpdHkgdGVzdGluZyBhdCB0aGUgaGFja2F0 aG9uIG9mIHRoZSBuZXh0IElFVEYNCg0KSGksDQoNCkpvbiBhbmQgSSBhcmUgcHJlcGFyaW5nIGZv ciBhbiBJbnRlcm9wZXJhYmlsaXR5IHRlc3RpbmcgYXQgdGhlIGhhY2thdGhvbiBvZiB0aGUgbmV4 dCBJRVRGLg0KVGhlIHNjaGVkdWxlIGlzIHZlcnkgdGlnaHQsIHNvIG91ciBwcmltYXJ5IHRhcmdl dCBhdCB0aGUgaGFja2F0aG9uIGlzIHRvIHRlc3QgdGhlIGludGVyb3BlcmFiaWxpdHkgb2Ygc2ln bmFsLWNoYW5uZWwgb24gQ09BUCBvdmVyIERUTFMuDQpFc3BlY2lhbGx5LCBudHRkb3RzIGlzIG5l ZWRlZCB0byBiZSB1cGRhdGVkIHRvIGJlIGNvbXBhdGlibGUgd2l0aCB0aGUgbGF0ZXN0IHNpZ25h bC1jaGFubmVsIGRyYWZ0LiBXZSB3aWxsIHRyeSBoYXJkIHRvIG1ha2UgaXQgc3VjY2Vzc2Z1bC4N CkpvbiBraW5kbHkgZGVjaWRlZCB0byBwYXJ0aWNpcGF0ZSBpbiB0aGUgaGFja2F0aG9uIHJlbW90 ZWx5LCBJJ2QgbGlrZSB0byBzYXkgdGhhbmtzIHRvIEpvbiBpbiBhZHZhbmNlLg0KDQoNClByb2pl Y3QgRGVzY3JpcHRpb246DQpodHRwczovL3d3dy5pZXRmLm9yZy9yZWdpc3RyYXRpb24vTWVldGlu Z1dpa2kvd2lraS9kb2t1LnBocD9pZD0xMDBoYWNrYXRob24NCioqRE9UUyBJbnRlcm9wKioNCiDC oMKgwqDCoMKgICogQ2hhbXBpb24ocykNCiDCoMKgwqDCoMKgwqDCoMKgwqAgKiBLYW5hbWUgTmlz aGl6dWthDQogwqDCoMKgwqDCoMKgwqDCoMKgICogSm9uIFNoYWxsb3coUmVtb3RlKQ0KIMKgwqDC oMKgwqAgKiBQcm9qZWN0KHMpDQogwqDCoMKgwqDCoMKgwqAgKiBERG9TIE9wZW4gVGhyZWF0IFNp Z25hbGluZyAoRE9UUykuDQogwqDCoMKgwqDCoMKgwqDCoMKgICogVGhlIGFpbSBvZiBET1RTIGlz IHRvIGRldmVsb3AgYSBzdGFuZGFyZHMgYmFzZWQgYXBwcm9hY2ggZm9yIHRoZSByZWFsdGltZSBz aWduYWxpbmcgb2YgRERvUyByZWxhdGVkIHRlbGVtZXRyeSBhbmQgdGhyZWF0IGhhbmRsaW5nIHJl cXVlc3RzIGFuZCBkYXRhIGJldHdlZW4gZWxlbWVudHMgY29uY2VybmVkIHdpdGggRERvUyBhdHRh Y2sgZGV0ZWN0aW9uLCBjbGFzc2lmaWNhdGlvbiwgdHJhY2ViYWNrLCBhbmQgbWl0aWdhdGlvbi4N CiDCoMKgwqDCoMKgwqDCoCAqIFdlIHdpbGwgdGVzdCB0aGUgaW50ZXJvcGVyYWJpbGl0eSBiZXR3 ZWVuIHR3byBpbmRlcGVuZGVudCBpbXBsZW1lbnRhdGlvbnM6DQogwqDCoMKgwqDCoMKgwqDCoMKg ICogVGhlIHByaW1hcnkgZ29hbCBpcyB0byB0ZXN0IHRoZSBpbnRlcm9wZXJhYmlsaXR5IG9mIHNp Z25hbC1jaGFubmVsIChDb0FQIG92ZXIgRFRMUykgb2YgRE9UIHByb3RvY29sLg0KIMKgwqDCoMKg wqAgKiBTcGVjaWZpY2F0aW9ucw0KIMKgwqDCoMKgwqDCoMKgwqDCoCAqIGh0dHBzOi8vdG9vbHMu aWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWRvdHMtc2lnbmFsLWNoYW5uZWwtMDYgKipmb2N1c2Vk KioNCiDCoMKgwqDCoMKgwqDCoMKgwqAgKiBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJh ZnQtaWV0Zi1kb3RzLWRhdGEtY2hhbm5lbC0wNg0KIMKgwqDCoMKgwqAgKiBJbXBsZW1lbnRhdGlv bnMNCiDCoMKgwqDCoMKgwqDCoMKgwqAgKiBudHRkb3RzOiBodHRwczovL2dpdGh1Yi5jb20vbnR0 ZG90cy9nby1kb3RzDQogwqDCoMKgwqDCoMKgwqDCoMKgICogaW50ZXJuYWwgaW1wbGVtZW50YXRp b24gYnkgSm9uIFNoYWxsb3cNCg0KUmVnYXJkcywNCkthbmFtZQ0KDQpfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KRG90cyBtYWlsaW5nIGxpc3QNCkRvdHNA aWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZG90cw0K From nobody Sun Nov 12 14:28:29 2017 Return-Path: X-Original-To: dots@ietf.org Delivered-To: dots@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BFD1126B71; Sun, 12 Nov 2017 14:28:28 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: dots@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.65.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151052570807.21438.6583700893469504299@ietfa.amsl.com> Date: Sun, 12 Nov 2017 14:28:28 -0800 Archived-At: Subject: [Dots] I-D Action: draft-ietf-dots-use-cases-09.txt X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.22 List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Nov 2017 22:28:28 -0000 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 : Use cases for DDoS Open Threat Signaling Authors : Roland Dobbins Daniel Migault Stefan Fouant Robert Moskowitz Nik Teague Liang Xia Kaname Nishizuka Filename : draft-ietf-dots-use-cases-09.txt Pages : 23 Date : 2017-11-12 Abstract: The DDoS Open Threat Signaling (DOTS) effort is intended to provide a protocol to facilitate interoperability between multivendor DDoS mitigation solutions and services. This document presents use cases which describe the interactions expected between the DOTS components as well as DOTS messaging exchanges. The purpose of describing use cases is to identify the interacting DOTS components, how they collaborate and what are the types of information to be exchanged. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dots-use-cases/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-dots-use-cases-09 https://datatracker.ietf.org/doc/html/draft-ietf-dots-use-cases-09 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dots-use-cases-09 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/ From nobody Sun Nov 12 14:39:16 2017 Return-Path: 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 4D67A1267BB for ; Sun, 12 Nov 2017 14:39:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=thescout.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 ii924P7z2MYb for ; Sun, 12 Nov 2017 14:39:12 -0800 (PST) Received: from mx0a-00196b01.pphosted.com (mx0a-00196b01.pphosted.com [67.231.149.170]) (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 28BBA1200B9 for ; Sun, 12 Nov 2017 14:39:12 -0800 (PST) Received: from pps.filterd (m0072398.ppops.net [127.0.0.1]) by mx0a-00196b01.pphosted.com (8.16.0.21/8.16.0.21) with SMTP id vACMZoBR023914 for ; Sun, 12 Nov 2017 17:39:10 -0500 Received: from nam02-sn1-obe.outbound.protection.outlook.com (mail-sn1nam02lp0023.outbound.protection.outlook.com [216.32.180.23]) by mx0a-00196b01.pphosted.com with ESMTP id 2e5x7tsw3r-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT) for ; Sun, 12 Nov 2017 17:39:10 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=thescout.onmicrosoft.com; s=selector1-arbor-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=YqvlWEjLawGMcLE0eLILZB8iO3LEEJ1x0tHMr8w2noM=; b=SMazUBUOTIyCF3z/uRFo3Wmvc5eV5HA2lEwQ3JHqeidEkLgfpLaLzKMiESjan9dadmRne11p1tBtZ/5Z5TlyzwM0rAbiF3sYQqekjkXkde+xKfnbT5foZMW8n6eWFnusstB5rY4OTpbHTsROXo2Bt8qvwdgoIsxVAwkkWpvimjI= Received: from [172.19.254.109] (184.82.224.107) by DM2PR0101MB1038.prod.exchangelabs.com (2a01:111:e400:3c19::27) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.197.13; Sun, 12 Nov 2017 22:39:07 +0000 From: "Roland Dobbins" To: dots Date: Mon, 13 Nov 2017 05:38:52 +0700 Message-ID: <2E5AB91E-888B-4F99-989D-66EC46311A0A@arbor.net> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.7r5425) X-Originating-IP: [184.82.224.107] X-ClientProxiedBy: HK2PR02CA0160.apcprd02.prod.outlook.com (2603:1096:201:1f::20) To DM2PR0101MB1038.prod.exchangelabs.com (2a01:111:e400:3c19::27) X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 5d651702-9a27-4c24-9707-08d52a1e2fd3 X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(2017052603199); SRVR:DM2PR0101MB1038; X-Microsoft-Exchange-Diagnostics: 1; DM2PR0101MB1038; 3:bOXCkSC7aRKfy8QMhj9YWrHsex6YdnjVhcVHXsSqgRIA+NPstWmSgGd0WVUsIpel3+ciOtMc+V/sFtLeHltTuqw9qcNvfWdNiNMWIyvePOfr7eyxrWtmSpHABtoHUKWwvcCkpwoOW7JXmZ/qJVZsAJbqpwDQ8ZlXXz16ntnsUgW1ol75/tjOY7PHEvd5ZlTa+wJiI1uCJMGgwEoOS8egrebSya5dp6qlhyXrisFOw/jshp+jsk0u2Gzh8RLVGu6N; 25:Em8yzicCetCX4jy/3PSNPO9qGspKW4GV2RyV6A3WgLhiK55FmNwg2cCcNSxABKlNxnJJ0NZy2X/f+Mm2tQTlhWLh3hit39Jk71irt2C5hF+8lfjVDfLZPkbxqY6jFVkuxGn1jlAYUuw8EI3Eu/+DojPts29fZyFUZDkfMYLwbQDcE24yQm+bjlsLkawWxBOwx+2T7IKKC4ZA3YfaKCYztyFi8d/cGQORYmhW53rHFzj++SQGWgD9IDIA5VzWtRmSBhjb9ZDkoeRThlU94tIG5fWIzjUOQ2aXsxa/D5Ds5KUNieNkSIf0mw+2FTyHpIUiwQSmoINm/2d1d2Z6YDpRRN9f/Ba25YlUnvQE3FguEsY=; 31:wkdTW79dVBqWowdvHDvEa9Eemqb15kQln4YggEKluXEdKgR1/g1LR/DassxCQ6uWHAlkW4w4n7r/J9ltFquWKvhoCsLXZT1qJOQQcH1/QE65q5cfnyv5cK0cbymR5qSzGcpqWsjNWelEmmCnDYQOzjxNvLyLQm0yfem60kES+hi0VXMhR5xAYYIQJwboRkUGU/8tnVmwxTcocNf19u502TVqDlTgSHygUrHh7G+kh0k= X-MS-TrafficTypeDiagnostic: DM2PR0101MB1038: X-Microsoft-Exchange-Diagnostics: 1; DM2PR0101MB1038; 20:iWbwWdxXkwWF/2rPzrCBkxPBe3f2lj+1J/MEs2aNsRMJTXSTLMFQjGmJJ4dePpKpUhYFDH38JhQMSdCZcqodum6xiy/APQ+MBrB1qbIVcyFMD7yZM22yOezVaKQTXjTUe+zotItFQq/zOqLWt925IL0eIdGrbGcRQJ1CqFx8LV2radUlNhi1j5X50qtU8H6zGVDwJYJsscKc6drIezwACByAFueLXSt9yWyNEeIi6Ppb5rh4u/NrctkiyMJ+jOjU2GkEWbygrE2oO6vKelhyaJXN/fyvSuakHh0JBhHBJeG/dMvB4GxKPeJwimT3NflbXIdUOEVPKBBXgHbsLIqGXQ==; 4:YdNq2pqqq12MpPs/A6gYE0nZvRLEhOGIl5vHfoxPG84D3SJK9nz2LaUgw9fSPqCp0P406DtsGc1y5LyLyG9XL4iZXwt3lUoYGuO5qhahTkES3GExqrm7WJLzsl8SMdi00KByD+HufS5vvXYpAGFSuzKpb280jDafzKTb8kdajlQcepZmFDYK9kVYdquyHEHd2xCozbpL6pe00BrTE/IspdvRqVJhUZP/xiiLRdUrBJKoTvbKyZpPmOdIVcdjB5Kz0YsPncOHs4TdsAUJpVa5EvzeCvcAbwAHfbiRnODWp0UWz6CmJAUJ6mHSBpB7LS1MT52dglel2aLIiM16vABviuy8kNfGoYvcTTqwCcG/X6onnTVLBD+D7vf4NvUxnbrm X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(120809045254105)(192374486261705)(231250463719595); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(5005006)(8121501046)(100000703101)(100105400095)(10201501046)(3002001)(93006095)(93001095)(3231022)(6041248)(20161123562025)(20161123558100)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123555025)(20161123564025)(20161123560025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:DM2PR0101MB1038; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:DM2PR0101MB1038; X-Forefront-PRVS: 0489CFBAC9 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(6009001)(6049001)(346002)(39830400002)(376002)(199003)(189002)(6666003)(6116002)(6916009)(189998001)(5003940100001)(68736007)(305945005)(50226002)(230783001)(16576012)(6306002)(50466002)(5660300001)(86362001)(3846002)(83716003)(36756003)(8676002)(82746002)(67846002)(7736002)(106356001)(8936002)(478600001)(6486002)(33656002)(316002)(16526018)(105586002)(50986999)(47776003)(81156014)(81166006)(25786009)(16586007)(53936002)(2906002)(77096006)(66066001)(97736004)(101416001); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR0101MB1038; H:[172.19.254.109]; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; Received-SPF: None (protection.outlook.com: arbor.net does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; DM2PR0101MB1038; 23:xxH03Dz0DZX96+byGsUlerZEJQ/dMXIVkcoBSjl?= =?us-ascii?Q?rxu00RNAwhrcSSz3lsJd1XITLyWzbqAgjPTdq77LiTcY5rTFoRPHlP+Sccp3?= =?us-ascii?Q?7Bho3cjB2mYqaSRsET0YIDPCw75a40IJI3q/eiPKtyC0a7Yk6e+eZMNhbW+X?= =?us-ascii?Q?9bf5OzFcWBFKZ32DUcQ9cSPeWePIzqYRINaF6Pa3+Mw+ocbweLNbMT1iq+AN?= =?us-ascii?Q?A9gmsCnUz3dSAxEjBwDlOtdY8FXkHJ1EHS0+kyCp5raIRmrt+bPGPVSiyoiF?= =?us-ascii?Q?vrNz4uULGJ7xCIo3x5e1gR7zAPm1OtjSgpQsv10QOhD8NBQS44ddx3NVLJ42?= =?us-ascii?Q?BEvKdVmGtvKYploOsG0ClLxxs23fNCgwTptebmwPvnZJhhL9WP9UBRg/7tFD?= =?us-ascii?Q?rMgvLrl2Wb/Y/nNx9R6ezpIUfstrNp4LBINPnRCtMjwclzxbr3z2w5c6VxTn?= =?us-ascii?Q?zwm2+T9OdWbkcIROPG8okJlsbNCDQCA789uJ+h+hif20zWGlMiJl2+ieTNpE?= =?us-ascii?Q?Z7bp1na8YgdVF610YO3/GH7QxxqD8Xya1HLKRwfU9YSHXSQplhDQ7oqzvuba?= =?us-ascii?Q?khFGmiObBgyiKC2WtWYlDqDvlUAE1drhldFtVDXYQ0C5Xayf8x46nLYhwZ4s?= =?us-ascii?Q?OQ9JGC+ID5bbom26zVwxmC+NHjAwGKzUU+kduQmnTFEcFN1z8TJySPN6JPUy?= =?us-ascii?Q?RHJrcfUFPilll4+fqz0G00urAbcm6Sm6HuyLOR5ZIjwxQFbTLBQD5Lu5cmgu?= =?us-ascii?Q?VTtYQoDdDD76Tr7v2Pu38U7P635XHWOlUeFxu4/uXs7G/7PirG/hRmaEcht7?= =?us-ascii?Q?VxpF/Y5zFYG58bPt/aiW63MLqGRjGHOTUfVzYdL+8nnyEZv4mycYC4oT55ey?= =?us-ascii?Q?n+Cnp0V8rANYhvB6gJec2DrGJnGThOGi67W30rB+VgBaF3zmaljDywg+UdJO?= =?us-ascii?Q?0UmynFjkLkWby2FCXJ3HEqRj07csZS1b14Ui8c9FlJi0hleis3YfSgtALFG+?= =?us-ascii?Q?1aZ3dScSE6S0UEb7yY+yHmgpVZcItpcUclMOWbavwhq5bOxt/QzLTYspJp8O?= =?us-ascii?Q?nI8F5UxVX2qbqPm9X/U8xguir9MMB2Tw00vEQzUqsTm3pL7KN+S2ZRwQvQaG?= =?us-ascii?Q?sqfV+TP7XRgI=3D?= X-Microsoft-Exchange-Diagnostics: 1; DM2PR0101MB1038; 6:D44hJd6+3nEgR5/D3Z5y8Zbce/cevNaCzACkczqdyD/LtmrLGkrm5ZFMzjlPvjIQKaOEnchiTHRi2fRNtenfjPyMbKx07+/zkv2A4q1kNgj/BZVJCsspdiKQQ1lQYzebw9euV1Ry9I7E5K3z1IIht6KxSCDT0SdGQLdxZ6bYcGzmQP4v5rlKLFqs+B0Wy4bNdCV8kq3F1ha1e+4jK8Gt3xGzPL20w7hCUkNOE9N1450NMZRKI7FdxINLhgc9H5qIxO+46kWcuhbbhwMswgxbeOcZZUM4Pqsa9VYriYJI6yCFJxWsZESdi6sSqRLhNUFsSZf1F0dKgT+Ph35k8kns66Q/vSxipPRchl2CTYMCg50=; 5:57VIt6fGgkOFOb5ubLqrh/MHdcNLf7t6wipEGdcBgT9XaCewkX+LE7qql81kEpWet9XPKp67az/nnHYtMuZTW31V3qw18sdWva3Xh2MiENFF7HC1QFMh71VXHcd9RLqVez+sf3MzqQv3A5ZvNyBCRQdORCFIPSdQxNkhbQRKKew=; 24:sDYwjQGs8/INoLaqDWm99Nad9fTHLQBYBwIOAngUIWBC3knuaIoyEtNva2Kn2KxbY1iaZt362khHseXmM/9J088Jw24T1HZISlsGyZpcTJo=; 7:3EuubfoR7V4V82wq6jgI2O+OOMKEZxLXGVXIlJA5QCDKJGoYDFF/jBw1KQA6TPJhM2KGqPrcsmViCPf1gK1jP09z5Y/114mKsBR6d2t24rk1ORo0f8uo3JuKYYDpu6EHs0jp6EFrm0wd1mCQ+3X/Kq3GUag7Nd9Jp+zzTPxN3CedzTjDXXCtT0G3H1/SSPhLTdQYLiDeJ2K+/0wGE0Fm714giiTU4zqmAnIKzzxo36/W0vD1S9UO1ifzC6s5TFKv SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: arbor.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 12 Nov 2017 22:39:07.1168 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 5d651702-9a27-4c24-9707-08d52a1e2fd3 X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 54f11205-d4aa-4809-bd36-0b542199c5b2 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR0101MB1038 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-11-12_10:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1711120323 Archived-At: Subject: [Dots] draft-ietf-dots-use-cases-09 posted - please review and provide feedback. 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Nov 2017 22:39:14 -0000 We've re-organized the use-cases so that DOTS implementors won't feel compelled to read through multiple use-cases with similar DOTS communications models, while at the same time retaining those use-cases because they contain significant procedural, operational, and topological variances which are of great significance to network operators and end-customer organizations. The wording in the DOTS communications model listings and several of the use-cases has been streamlined. The security considerations were updated to include DDoS attacks. Finally, we really need WG feedback on the applicability of Section 3.2.2, 'Home Network DDoS Detection Collaboration for ISP network management'. Thanks much! ----------------------------------- Roland Dobbins From nobody Sun Nov 12 20:21:45 2017 Return-Path: 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 5338A129407 for ; Sun, 12 Nov 2017 20:21:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.799 X-Spam-Level: * X-Spam-Status: No, score=1.799 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MISSING_MIMEOLE=1.899, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); domainkeys=pass (1024-bit key) header.from=tobias.gondrom@gondrom.org header.d=gondrom.org 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 JSTKkcVdl_hL for ; Sun, 12 Nov 2017 20:21:42 -0800 (PST) Received: from gondrom.org (www.gondrom.org [5.35.241.16]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CEBB212932A for ; Sun, 12 Nov 2017 20:21:41 -0800 (PST) Received: from seraph (dhcp-8964.meeting.ietf.org [31.133.137.100]) by gondrom.org (Postfix) with ESMTPSA id 93D4464A64; Mon, 13 Nov 2017 05:21:39 +0100 (CET) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=gondrom.org; b=h9cp6iljhj+VH2JBLRHviTPzOefsQu/Bvc1YO3f4Rq5Am6SbhOlmIDyOiS/UxrRJop8u6hN+It2hZw4nt3pmKDWdykfSc/rBRD8WgvFYdmNYgm7xvlpJM/dYnkQdGqrr8M7O8cmgHiVBaUb67uTNVytl05uIhh0fChhIT/+083Y=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version:Content-Type:X-Priority:X-MSMail-Priority:X-Mailer:Thread-Index:Content-Language:Importance; From: "Tobias Gondrom" To: Cc: "'Roman Danyliw'" Date: Mon, 13 Nov 2017 12:21:34 +0800 Message-ID: <034201d35c36$e5d50a50$b17f1ef0$@gondrom.org> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0343_01D35C79.F3F9D0F0" X-Priority: 1 (Highest) X-MSMail-Priority: High X-Mailer: Microsoft Outlook 16.0 Thread-Index: AdNcNrRVOr4WTD9USwucc+Du2yJNnQ== Content-Language: en-us Importance: High Archived-At: Subject: [Dots] DOTS WG meeting tomorrow: Tuesday (Nov-14) at 13:30-15:30 (Singapore local time) 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Nov 2017 04:21:43 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0343_01D35C79.F3F9D0F0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Dear DOTS WG, This time we will have a number of remote presenters at our DOTS meeting. And as you know IETF has made great efforts in enhancing our facilities for remote presentation and remote participation. Please feel encouraged to discuss and contribute remotely, even if you can not attend in person. For all remote participants: for a smooth experience, please read the information page: https://www.ietf.org/meeting/100/remote-participation.html and for remote presenters, please do try your system and Meetecho before the meeting to make sure everything works. The Meetecho team is always happy to help if you have any questions. In addition, as a number of contributors are this time remotely, we will this time not have a design team meeting before the meeting. Based on the discussion in the WG meeting, we will organize Interim meetings after the IETF in Singapore. Best regards, Tobias & Roman ------=_NextPart_000_0343_01D35C79.F3F9D0F0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear DOTS WG,

 

This time we = will have a number of remote presenters at our DOTS meeting. =

And as you know IETF has made great = efforts in enhancing our facilities for remote presentation and remote = participation.

Please feel = encouraged to discuss and contribute remotely, even if you can not = attend in person.

 

For all = remote participants: for a smooth experience, please read the = information page:

https= ://www.ietf.org/meeting/100/remote-participation.html and for remote = presenters, please do try your system and Meetecho before the meeting to = make sure everything works.

The = Meetecho team is always happy to help if you have any questions. =

 

In addition, as a number of contributors are this time = remotely, we will this time not have a design team meeting before the = meeting.

Based on the discussion in = the WG meeting, we will organize Interim meetings after the IETF in = Singapore.

 

Best regards, Tobias & Roman

 

 

 

------=_NextPart_000_0343_01D35C79.F3F9D0F0-- From nobody Sun Nov 12 21:11:41 2017 Return-Path: X-Original-To: dots@ietf.org Delivered-To: dots@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C3741270A0; Sun, 12 Nov 2017 21:11:33 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: dots@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.65.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151054989334.21482.3285502775236979413@ietfa.amsl.com> Date: Sun, 12 Nov 2017 21:11:33 -0800 Archived-At: Subject: [Dots] I-D Action: draft-ietf-dots-signal-channel-07.txt X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.22 List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Nov 2017 05:11:33 -0000 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 : Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal Channel Authors : Tirumaleswar Reddy Mohamed Boucadair Prashanth Patil Andrew Mortensen Nik Teague Filename : draft-ietf-dots-signal-channel-07.txt Pages : 61 Date : 2017-11-12 Abstract: This document specifies the DOTS signal channel, a protocol for signaling the need for protection against Distributed Denial-of- Service (DDoS) attacks to a server capable of enabling network traffic mitigation on behalf of the requesting client. A companion document defines the DOTS data channel, a separate reliable communication layer for DOTS management and configuration. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dots-signal-channel/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-dots-signal-channel-07 https://datatracker.ietf.org/doc/html/draft-ietf-dots-signal-channel-07 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dots-signal-channel-07 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/ From nobody Sun Nov 12 21:29:31 2017 Return-Path: X-Original-To: dots@ietf.org Delivered-To: dots@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 13B2112947C; Sun, 12 Nov 2017 21:29:30 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: dots@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.65.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151055097004.21466.3270852509557866094@ietfa.amsl.com> Date: Sun, 12 Nov 2017 21:29:30 -0800 Archived-At: Subject: [Dots] I-D Action: draft-ietf-dots-data-channel-07.txt X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.22 List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Nov 2017 05:29:30 -0000 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 : Distributed Denial-of-Service Open Threat Signaling (DOTS) Data Channel Authors : Tirumaleswar Reddy Mohamed Boucadair Kaname Nishizuka Liang Xia Prashanth Patil Andrew Mortensen Nik Teague Filename : draft-ietf-dots-data-channel-07.txt Pages : 28 Date : 2017-11-12 Abstract: The document specifies a Distributed Denial-of-Service Open Threat Signaling (DOTS) data channel used for bulk exchange of data not easily or appropriately communicated through the DOTS signal channel under attack conditions. This is a companion document to the DOTS signal channel specification. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dots-data-channel/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-dots-data-channel-07 https://datatracker.ietf.org/doc/html/draft-ietf-dots-data-channel-07 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dots-data-channel-07 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/ From nobody Sun Nov 12 21:48:37 2017 Return-Path: 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 B76A8127599 for ; Sun, 12 Nov 2017 21:48:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7 X-Spam-Level: X-Spam-Status: No, score=-7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 WdPgbLeJ_ZVj for ; Sun, 12 Nov 2017 21:48:34 -0800 (PST) Received: from MIVWSMAILOUT1.mcafee.com (mivwsmailout1.mcafee.com [161.69.47.167]) (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 0C807127337 for ; Sun, 12 Nov 2017 21:48:33 -0800 (PST) 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=1510552112; 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: authentication-results:x-originating-ip:x-ms-publictraffictype: x-microsoft-exchange-diagnostics:x-ms-exchange-antispam-srfa-diagnostics: x-ms-office365-filtering-correlation-id:x-microsoft-antispam: x-ms-traffictypediagnostic:x-microsoft-antispam-prvs: x-exchange-antispam-report-test:x-exchange-antispam-report-cfa-test: x-forefront-prvs:x-forefront-antispam-report: received-spf:spamdiagnosticoutput:spamdiagnosticmetadata: 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-Transport-CrossTenantHeadersStamped: X-OriginatorOrg:X-NAI-Spam-Flag:X-NAI-Spam-Threshold: X-NAI-Spam-Score:X-NAI-Spam-Version; bh=I 9E0xH0kn5huHE9XDryM1QSwbdglnEOuO6yy/RfyZj c=; b=Ys/lnUpcK5t6cV0VC1eRoYZTlC8GsmznG01ot9q8kPpU ccug6f4R3kopkrWDpPIdGo5V2fP5lBldFkN9fT6Nx5/wm+PXwv b38p+UFGOtmo8doK5vNaNehqLA5T6fA65BID8AC2bO8QDkVLTp rCPK0U3Ag5nfv0/B4vlKXC9jkzQ= Received: from MIVEXAPP1N01.corpzone.internalzone.com (unknown [10.48.48.88]) by MIVWSMAILOUT1.mcafee.com with smtp id 50f1_29dc_d4498afc_12bf_4451_9f5f_23d55e9e5da4; Sun, 12 Nov 2017 23:48:32 -0600 Received: from MIVEXUSR1N03.corpzone.internalzone.com (10.48.48.83) by MIVEXAPP1N01.corpzone.internalzone.com (10.48.48.88) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Mon, 13 Nov 2017 00:48:31 -0500 Received: from MIVEXAPP1N02.corpzone.internalzone.com (10.48.48.89) by MIVEXUSR1N03.corpzone.internalzone.com (10.48.48.83) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Mon, 13 Nov 2017 00:48:30 -0500 Received: from MIVO365EDGE3.corpzone.internalzone.com (10.48.176.86) by MIVEXAPP1N02.corpzone.internalzone.com (10.48.48.89) with Microsoft SMTP Server (TLS) id 15.0.1347.2 via Frontend Transport; Mon, 13 Nov 2017 00:48:30 -0500 Received: from NAM02-SN1-obe.outbound.protection.outlook.com (10.48.176.243) by edge.mcafee.com (10.48.176.86) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Mon, 13 Nov 2017 00:48:29 -0500 Received: from DM5PR16MB1788.namprd16.prod.outlook.com (10.172.44.144) by DM5PR16MB1786.namprd16.prod.outlook.com (10.172.44.142) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.218.12; Mon, 13 Nov 2017 05:48:29 +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.20.0218.011; Mon, 13 Nov 2017 05:48:29 +0000 From: "Konda, Tirumaleswar Reddy" To: "dots@ietf.org" Thread-Topic: [Dots] I-D Action: draft-ietf-dots-signal-channel-07.txt Thread-Index: AQHTXD4EwSeyi1cat0KRQI2jbeItb6MRzMHA Date: Mon, 13 Nov 2017 05:48:28 +0000 Message-ID: References: <151054989334.21482.3285502775236979413@ietfa.amsl.com> In-Reply-To: <151054989334.21482.3285502775236979413@ietfa.amsl.com> 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: [103.245.47.20] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DM5PR16MB1786; 6:uSJw16Dz9L9Q5oe9fsCCkL0HWef+Tum16FUBDIYBJ0DbzqYE+wj69/evSDW8kHqqMK4LlM/iewyjy3kBiBtn3xeg+waejabtNqjn45us81IzlNHERuoo0RlEzAZHuLSqIUakvPmdD52Q1Pt0ASkrZ4fLi0wwVsFf8pIKkUUbifkQl+kmodq2FcKiWYfyq51ojL9caouxaP8Ex4swoeFUaGot1xjcqe96K6iK2PRH40jre0Th5utzvVimdFgYeNn8Xnm7RreRUmnMxYJmXsZ0XjtKOjVRmCi6Wj5LCiu2eBYUR41cgNtNNhYYqnT53c9fNVyp2JMfxGrP784BrDW4bjwEnC5jGHXv4h9Iopip/dU=; 5:ElrLK1xd72LshbyKHn9KfN6eiTnmaBa8qdRAw7z+Frdi3wZqHh6Xw3xxC6djYVMm7vA9qpa11+uLIX0+x83tE+hclif7uGBV+bKxOqDt3UWlRY3v/q8+u1TtVam0FteoV5aMWXxpOpLugUbgzKMEy7Bsj4zPV0rDX5GefdpW8ns=; 24:zIJHbi5fYm9rL9++kq7AegBnwtcQLf3GoL3mpYXSGA9inuwYw5moflcjgSp677YwgW/+GeI518gL/zOLHLOS5kz3wPWHhRUVp95X3KtzbQ4=; 7:qMfzbU5dWQNJYFt94TymMoL8Y9MAGpi0RTxieNeW3RMf8b1EJzTPecTZZEEB5GcjEkn3aGQtYuVgo8yE/PMYJdOjpQmHAb0QYSpYt5iLBQ0Htlu8hwhOYuMnTK/4aTf4/eTk/MTR5rW6N9c6/gK3+M67N8+BLghLaWxtvbVx4ueBsByxsbT7xlKHtJei/cx8bUGCA/pgNVpSfEfmsYEmuatR8HaPQ5txK2esUJw6BpXXlb0vUHfHEpH2WoB87Q2a x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 72a02727-a616-4883-242e-08d52a5a2a6e x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(2017052603199); SRVR:DM5PR16MB1786; x-ms-traffictypediagnostic: DM5PR16MB1786: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(120809045254105); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(8121501046)(5005006)(100000703101)(100105400095)(10201501046)(93006095)(93001095)(3231022)(3002001)(6041248)(20161123555025)(20161123562025)(20161123560025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123558100)(20161123564025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:DM5PR16MB1786; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:DM5PR16MB1786; x-forefront-prvs: 0490BBA1F0 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(376002)(39860400002)(346002)(377424004)(189002)(199003)(13464003)(32952001)(76176999)(9686003)(99286004)(72206003)(53936002)(305945005)(74316002)(53546010)(189998001)(50986999)(316002)(25786009)(230783001)(6306002)(2501003)(6506006)(6436002)(55016002)(5640700003)(77096006)(101416001)(4001150100001)(33656002)(3280700002)(478600001)(66066001)(80792005)(3660700001)(6246003)(229853002)(97736004)(966005)(54356999)(2906002)(8676002)(14454004)(105586002)(6116002)(102836003)(2351001)(2950100002)(86362001)(8936002)(7696004)(2900100001)(7736002)(5660300001)(106356001)(1730700003)(68736007)(6916009)(3846002)(81156014)(81166006)(85282002); DIR:OUT; SFP:1101; SCL:1; SRVR:DM5PR16MB1786; H:DM5PR16MB1788.namprd16.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; 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: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 72a02727-a616-4883-242e-08d52a5a2a6e X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Nov 2017 05:48:28.9296 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4943e38c-6dd4-428c-886d-24932bc2d5de X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR16MB1786 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 <6156> : inlines <6171> : streams <1770139> : uri <2533006> Archived-At: Subject: Re: [Dots] I-D Action: draft-ietf-dots-signal-channel-07.txt 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Nov 2017 05:48:36 -0000 This revision https://tools.ietf.org/html/draft-ietf-dots-signal-channel-07= addresses comments and issues raised during the interim meeting.=20 Main changes are 1. New port for DOTS signal channel 2. Use of ".well-known" and dots URI suffix 3. Heartbeat mechanism during volumetric DDoS attack saturating the incomin= g link Thanks to Jon for the detailed review.=20 Cheers, -Tiru > -----Original Message----- > From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of internet- > drafts@ietf.org > Sent: Monday, November 13, 2017 10:42 AM > To: i-d-announce@ietf.org > Cc: dots@ietf.org > Subject: [Dots] I-D Action: draft-ietf-dots-signal-channel-07.txt >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. > This draft is a work item of the DDoS Open Threat Signaling WG of the IET= F. >=20 > Title : Distributed Denial-of-Service Open Threat Signa= ling (DOTS) > Signal Channel > Authors : Tirumaleswar Reddy > Mohamed Boucadair > Prashanth Patil > Andrew Mortensen > Nik Teague > Filename : draft-ietf-dots-signal-channel-07.txt > Pages : 61 > Date : 2017-11-12 >=20 > Abstract: > This document specifies the DOTS signal channel, a protocol for > signaling the need for protection against Distributed Denial-of- > Service (DDoS) attacks to a server capable of enabling network > traffic mitigation on behalf of the requesting client. A companion > document defines the DOTS data channel, a separate reliable > communication layer for DOTS management and configuration. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-dots-signal-channel/ >=20 > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-dots-signal-channel-07 > https://datatracker.ietf.org/doc/html/draft-ietf-dots-signal-channel-07 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dots-signal-channel-07 >=20 >=20 > Please note that it may take a couple of minutes from the time of submiss= ion > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > Dots mailing list > Dots@ietf.org > https://www.ietf.org/mailman/listinfo/dots From nobody Sun Nov 12 21:50:22 2017 Return-Path: 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 BAEAD12946E for ; Sun, 12 Nov 2017 21:50:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7 X-Spam-Level: X-Spam-Status: No, score=-7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 oUMfVPAI-55p for ; Sun, 12 Nov 2017 21:50:04 -0800 (PST) Received: from MIVWSMAILOUT1.mcafee.com (mivwsmailout1.mcafee.com [161.69.47.167]) (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 8B754129481 for ; Sun, 12 Nov 2017 21:50:04 -0800 (PST) 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=1510552203; 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: authentication-results:x-originating-ip:x-ms-publictraffictype: x-microsoft-exchange-diagnostics:x-ms-exchange-antispam-srfa-diagnostics: x-ms-office365-filtering-correlation-id:x-microsoft-antispam: x-ms-traffictypediagnostic:x-microsoft-antispam-prvs: x-exchange-antispam-report-test:x-exchange-antispam-report-cfa-test: x-forefront-prvs:x-forefront-antispam-report: received-spf:spamdiagnosticoutput:spamdiagnosticmetadata: 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-Transport-CrossTenantHeadersStamped: X-OriginatorOrg:X-NAI-Spam-Flag:X-NAI-Spam-Threshold: X-NAI-Spam-Score:X-NAI-Spam-Version; bh=N SO4zuhj8R/JpGtbu4mzgFBLYbhRmpU0gep3Qw8yH2 I=; b=Fa+s6NTyBZ9f0TLT1Ql/h0TYp9S1AXwpqXMkdPV5G8x7 acZVLGIsTQsPcSmuUSzf2d4AP0nwtbivK1zfTC1byfEsctOyPS oZqqrH7fBgNNMaM9MZWlgv+uY9+NFzMW0QohIn7/KxnyVoKxfY NP8pxiOEPMOkiEL8Rv9erfrhfgI= Received: from MIVEXAPP1N02.corpzone.internalzone.com (unknown [10.48.48.89]) by MIVWSMAILOUT1.mcafee.com with smtp id 50f1_2b59_47e9619b_b080_41fd_bc14_911bb71227b3; Sun, 12 Nov 2017 23:50:03 -0600 Received: from MIVEXUSR1N01.corpzone.internalzone.com (10.48.48.81) by MIVEXAPP1N02.corpzone.internalzone.com (10.48.48.89) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Mon, 13 Nov 2017 00:50:02 -0500 Received: from MIVEXUSR1N06.corpzone.internalzone.com (10.48.48.86) by MIVEXUSR1N01.corpzone.internalzone.com (10.48.48.81) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Mon, 13 Nov 2017 00:50:01 -0500 Received: from MIVO365EDGE4.corpzone.internalzone.com (10.48.176.87) by MIVEXUSR1N06.corpzone.internalzone.com (10.48.48.86) with Microsoft SMTP Server (TLS) id 15.0.1347.2 via Frontend Transport; Mon, 13 Nov 2017 00:50:01 -0500 Received: from NAM02-SN1-obe.outbound.protection.outlook.com (10.48.176.243) by edge.mcafee.com (10.48.176.87) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Mon, 13 Nov 2017 00:50:00 -0500 Received: from DM5PR16MB1788.namprd16.prod.outlook.com (10.172.44.144) by DM5PR16MB1786.namprd16.prod.outlook.com (10.172.44.142) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.218.12; Mon, 13 Nov 2017 05:50:00 +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.20.0218.011; Mon, 13 Nov 2017 05:50:00 +0000 From: "Konda, Tirumaleswar Reddy" To: "dots@ietf.org" Thread-Topic: [Dots] I-D Action: draft-ietf-dots-data-channel-07.txt Thread-Index: AQHTXEBzQbOtygzsUEaM1CuS4gs7y6MRzdpg Date: Mon, 13 Nov 2017 05:50:00 +0000 Message-ID: References: <151055097004.21466.3270852509557866094@ietfa.amsl.com> In-Reply-To: <151055097004.21466.3270852509557866094@ietfa.amsl.com> 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: [103.245.47.20] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DM5PR16MB1786; 6:ZVYmb/AUx2C9jjRcZ9fSojdcLeJQ4ryO7f0ktcCLuT0jiPwQc/u4uRxoBCW0CWYLTlA8/hAyAzIwEqMa/BELkzF3+rRn1mFffr2B3O+XKX5WlJPxFaFoDQgQZByUsr/Qw+FiUSgKyPB5Q7Qwz1D/LnnVcnRV/8OvzFixlmvbx1KO2T5DRQyn6fFFMtuDlIXRmL9JXjF6KQizzqm3LKCJg4KQD2x9X6QHiqwDbbHEvuEnc/KuYJ3nDLZQwewH1wf8BPtfRXKEIzGCZSlE+DejZLHR7RTvxzHJctrY3WW+k9833x9+IyiOL2Regk/pg/ib81n4MSb1NN48GR+OMG+wmt0MFsx3kGfgTe3Xn6/b4G0=; 5:pF6OU3KQTvjVt0Za1AAtkSuliiXVbZIwyNbfvirenEuZUGL9EWhpM30ey3ba6bQsqivBetN4wOPyrcKPaezZ59094wbt7zCyuvZNTNpa6aeADe2Ktgpe6DH6/rUcgMt4tnPtICRGdcV0T5QX6WH3XP/7QAaDj8BuaLFq/4JUh24=; 24:tCH9rjKW6asqTuywRyrID3KIsa0mCBkOEBwlPiNlBv2A1LK143ga+dDMasxpndhaiJIN4f0nYcAbmUGKa31S+cYvDNFfGMsNfayauVoXYlE=; 7:1TgnQJpPL1RL0Gp17OfCU/bWmhFwuGscgCh1uPq72E/NrsmYhmPnOtDiX7prKhWY51tVP+pdVdUKtDDMXt98fHYaz5zHxmuXV0dBm21FCXYYfA578sZ5njjaSQWQwT9wWWG+mQ+ke00AFkjCuTcgtbSPIqxwDeEVbDy81edNPgA0B07R4bJbHnSYF3Y1V7suVZMm7WxoUO8KYFcPKIT9Q8NywGUeP6es/3Smi+BSN77lXw+Ahw/EloT9H+P9GqJL x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 0baca68f-aa2e-48e7-ad00-08d52a5a60cf x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(2017052603199); SRVR:DM5PR16MB1786; x-ms-traffictypediagnostic: DM5PR16MB1786: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(120809045254105); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(8121501046)(5005006)(100000703101)(100105400095)(10201501046)(93006095)(93001095)(3231022)(3002001)(6041248)(20161123555025)(20161123562025)(20161123560025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123558100)(20161123564025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:DM5PR16MB1786; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:DM5PR16MB1786; x-forefront-prvs: 0490BBA1F0 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(376002)(39860400002)(346002)(377424004)(189002)(199003)(13464003)(32952001)(76176999)(9686003)(99286004)(72206003)(53936002)(305945005)(74316002)(53546010)(189998001)(50986999)(316002)(25786009)(230783001)(6306002)(2501003)(6506006)(6436002)(55016002)(5640700003)(77096006)(101416001)(4001150100001)(33656002)(3280700002)(478600001)(66066001)(80792005)(3660700001)(6246003)(229853002)(97736004)(966005)(54356999)(2906002)(8676002)(14454004)(105586002)(6116002)(102836003)(2351001)(2950100002)(86362001)(8936002)(7696004)(2900100001)(7736002)(5660300001)(106356001)(1730700003)(68736007)(6916009)(3846002)(81156014)(81166006)(85282002); DIR:OUT; SFP:1101; SCL:1; SRVR:DM5PR16MB1786; H:DM5PR16MB1788.namprd16.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; 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: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 0baca68f-aa2e-48e7-ad00-08d52a5a60cf X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Nov 2017 05:50:00.1345 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4943e38c-6dd4-428c-886d-24932bc2d5de X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR16MB1786 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 <6156> : inlines <6171> : streams <1770139> : uri <2533007> Archived-At: Subject: Re: [Dots] I-D Action: draft-ietf-dots-data-channel-07.txt 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Nov 2017 05:50:07 -0000 This revision addresses comments from Jon. -Tiru > -----Original Message----- > From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of internet- > drafts@ietf.org > Sent: Monday, November 13, 2017 11:00 AM > To: i-d-announce@ietf.org > Cc: dots@ietf.org > Subject: [Dots] I-D Action: draft-ietf-dots-data-channel-07.txt >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. > This draft is a work item of the DDoS Open Threat Signaling WG of the IET= F. >=20 > Title : Distributed Denial-of-Service Open Threat Signa= ling (DOTS) > Data Channel > Authors : Tirumaleswar Reddy > Mohamed Boucadair > Kaname Nishizuka > Liang Xia > Prashanth Patil > Andrew Mortensen > Nik Teague > Filename : draft-ietf-dots-data-channel-07.txt > Pages : 28 > Date : 2017-11-12 >=20 > Abstract: > The document specifies a Distributed Denial-of-Service Open Threat > Signaling (DOTS) data channel used for bulk exchange of data not > easily or appropriately communicated through the DOTS signal channel > under attack conditions. This is a companion document to the DOTS > signal channel specification. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-dots-data-channel/ >=20 > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-dots-data-channel-07 > https://datatracker.ietf.org/doc/html/draft-ietf-dots-data-channel-07 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dots-data-channel-07 >=20 >=20 > Please note that it may take a couple of minutes from the time of submiss= ion > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > Dots mailing list > Dots@ietf.org > https://www.ietf.org/mailman/listinfo/dots From nobody Mon Nov 13 12:22:58 2017 Return-Path: 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 4C0801241F3 for ; Mon, 13 Nov 2017 12:22:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.124 X-Spam-Level: X-Spam-Status: No, score=-1.124 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FORGED_HOTMAIL_RCVD2=0.874, FREEMAIL_FROM=0.001, 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=hotmail.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 WlrQNWh1Pn0f for ; Mon, 13 Nov 2017 12:22:54 -0800 (PST) Received: from NAM01-BN3-obe.outbound.protection.outlook.com (mail-oln040092000045.outbound.protection.outlook.com [40.92.0.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 72EAB1201F8 for ; Mon, 13 Nov 2017 12:22:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hotmail.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=xWBe2mbXmJ0y3oSPi5WmlvlxjjllK70Aq8Rc+8Ki3Js=; b=pgTlbbjvURmlMeoevC5E8jLyKUmFWCSA7OGvvoYfobk8/GRT+87Vy+BAFVFbc2bOVQ6isTdHXcUYMaiOoGr0m65tJt7fQ1Lo5eJONMDnkPPsMEHpvrKsggVgrv/EoIpvc5a2etyuYiWpfeuGg955g63ubQ71JwlZEuJUc+x2N5ENDkEqpMQpB/kUS17WxSf2j4wk+vwTvLszDmNl8O2RvsuHgt1xhi5q7JCA+dbx4t1nGBITQ6rt2Ywf9C+p/l+c98nLgja7ux9gPcr5Q3rbyx2bokTSEhuhDHiK2un3Ck5oSqMvIZot0wk8u+FgdEl8osEngtnkkahR1mi+PETD0A== Received: from BN3NAM01FT057.eop-nam01.prod.protection.outlook.com (10.152.66.59) by BN3NAM01HT015.eop-nam01.prod.protection.outlook.com (10.152.66.104) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.20.197.9; Mon, 13 Nov 2017 20:22:52 +0000 Received: from CY1PR13MB0858.namprd13.prod.outlook.com (10.152.66.58) by BN3NAM01FT057.mail.protection.outlook.com (10.152.66.158) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.20.197.9 via Frontend Transport; Mon, 13 Nov 2017 20:22:52 +0000 Received: from CY1PR13MB0858.namprd13.prod.outlook.com ([10.169.20.26]) by CY1PR13MB0858.namprd13.prod.outlook.com ([10.169.20.26]) with mapi id 15.20.0239.005; Mon, 13 Nov 2017 20:22:52 +0000 From: Maheswaran Balasubramanian To: Roland Dobbins , dots Thread-Topic: [Dots] draft-ietf-dots-use-cases-09 posted - please review and provide feedback. Thread-Index: AQHTXAcT4GvwEDw2SUCPz3aA0l1AxqMSpvh4 Date: Mon, 13 Nov 2017 20:22:52 +0000 Message-ID: References: <2E5AB91E-888B-4F99-989D-66EC46311A0A@arbor.net> In-Reply-To: <2E5AB91E-888B-4F99-989D-66EC46311A0A@arbor.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: arbor.net; dkim=none (message not signed) header.d=none;arbor.net; dmarc=none action=none header.from=hotmail.com; x-incomingtopheadermarker: OriginalChecksum:6A9067905E47FE19C45D6A2388E72965E467FABF0A825851A9F67B60D31A8417; UpperCasedChecksum:4EA8D262224EB4DA699F61913230E789DD70235BE9A9A1CBA719183B0D2404D6; SizeAsReceived:7220; Count:46 x-ms-exchange-messagesentrepresentingtype: 1 x-tmn: [0PCSwZpmIGQ0EOpZmGWlvoAtTM2Vz2wrpBPSXUZR2w8GjYnRUmU3ckqatED/6Tom] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BN3NAM01HT015; 6:eyuMFyo2MdjZ4vW6xgXDEkEvQ8RQha+VpN0ufTy5hn/nKYgj/yEcIpxojQLjB+HqssaTLEZbvW36yGtgchwttEUw9y3VlsO+Ips0l7KrK3NB0HgjXyt4H6YoItEy4c8iraMqxJbfetX3Q7H/pu1jFA8NsYWr9bhBQkW3AkNVoAOwv72KZ6k68LGwumZOjhcEJcTNNtHQtRHSjqMAKnE74JA+aZJqZLH/bdqDcaZgkKoQWlJ3neWowIFTsd8haKnNXYmNNZMyDYb9+HV5d/6p6t52+s/MRDgDIdTBn8yzrRyf4I3zT+NZlvNrZ1oMOhXSyioFd4XLeSiXi+GGBsTgBe4dkkWzL5qqJ/R9MeCgH7s=; 5:E3kPxuNWcy8+83jlgJjZQYY7tOKXWNjrCEoHsC8WfwygMqeatALofgJnF0WwTQiDzk+hN5vaK+USxtqZBGtgZzVlFnwNM7GFHXaXaNSl4RTB9jc21i/zZ2oxppr2xrJJjVtHEyrLDJ/GrNsG+TNOoMdmcTSIN9Am4pWyWAq1UH8=; 24:t6loQcd7fsnFt/ECXTEQaFbcjTE8jaJViTR/xo48AqWuDDztmekiajzP6YZ0h3vklv9O6d/zHlzOAt4enKBK+zmM6jfL2OYcO2bMNvP/uXo=; 7:jmayuTbuCYLRqlQ+sWztE+87JyMHG9G+CcFdVHIeZ82O4RB1C8te0VVCqY1uKo6SKLRyTxi/GR70VecG9xLRyI0+5MLnZzgMDuLNpaAP887lw51z6Gg54wpozQ8cqWgOPkQEGeTJW7jd1ZbzOoc81TTlVQgYJ3bsSv0kHLgdJMI08j6HJi5qGmT/4SAUkBANzVI2mKT5Fs+sDif9XdKwBZCQnCQVBUGo9ptE2MAdHo8IritZodAp3Uxk6ME6rN6I x-incomingheadercount: 46 x-eopattributedmessage: 0 x-ms-office365-filtering-correlation-id: 920be98f-ad63-491f-dad5-08d52ad45151 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(201702061074)(5061506573)(5061507331)(1603103135)(2017031320274)(2017031324274)(2017031323274)(2017031322404)(1603101448)(1601125374)(1701031045); SRVR:BN3NAM01HT015; x-ms-traffictypediagnostic: BN3NAM01HT015: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(444000031); SRVR:BN3NAM01HT015; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:BN3NAM01HT015; x-forefront-prvs: 0490BBA1F0 x-forefront-antispam-report: SFV:NSPM; SFS:(7070007)(98901004); DIR:OUT; SFP:1901; SCL:1; SRVR:BN3NAM01HT015; H:CY1PR13MB0858.namprd13.prod.outlook.com; FPR:; SPF:None; LANG:; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_CY1PR13MB08580C1CC5C88D6F8DA31DBAEB2B0CY1PR13MB0858namp_" MIME-Version: 1.0 X-OriginatorOrg: hotmail.com X-MS-Exchange-CrossTenant-Network-Message-Id: 920be98f-ad63-491f-dad5-08d52ad45151 X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Nov 2017 20:22:52.7295 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Internet X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3NAM01HT015 Archived-At: Subject: Re: [Dots] draft-ietf-dots-use-cases-09 posted - please review and provide feedback. 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Nov 2017 20:22:57 -0000 --_000_CY1PR13MB08580C1CC5C88D6F8DA31DBAEB2B0CY1PR13MB0858namp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Typically, SOHO devices(CPE) built with finite resources and offloading the= detection function to this CPE has its own limitation. Doing DPI (or) heur= istics at SOHO devices certainly requires enough resources (processing powe= r) also necessary intelligence built into it. Thanks. ________________________________ From: Dots on behalf of Roland Dobbins Sent: Monday, November 13, 2017 4:08:52 AM To: dots Subject: [Dots] draft-ietf-dots-use-cases-09 posted - please review and pro= vide feedback. We've re-organized the use-cases so that DOTS implementors won't feel compelled to read through multiple use-cases with similar DOTS communications models, while at the same time retaining those use-cases because they contain significant procedural, operational, and topological variances which are of great significance to network operators and end-customer organizations. The wording in the DOTS communications model listings and several of the use-cases has been streamlined. The security considerations were updated to include DDoS attacks. Finally, we really need WG feedback on the applicability of Section 3.2.2, 'Home Network DDoS Detection Collaboration for ISP network management'. Thanks much! ----------------------------------- Roland Dobbins _______________________________________________ Dots mailing list Dots@ietf.org https://www.ietf.org/mailman/listinfo/dots Dots Info Page - Internet Engineering Task Force www.ietf.org Dots -- List for discussion of DDoS Open Threat Signaling (DOTS) technology= and directions. About Dots --_000_CY1PR13MB08580C1CC5C88D6F8DA31DBAEB2B0CY1PR13MB0858namp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

 

Typically, SOHO devices(CPE) built with finite resources and offload= ing the detection function to this CPE has its own limitation. Doing DPI (or) heuristics at SOHO devices= certainly requires enough resources (processing power) also necessary inte= lligence built into it.


Thanks.


From: Dots <dots-bounces= @ietf.org> on behalf of Roland Dobbins <rdobbins@arbor.net>
Sent: Monday, November 13, 2017 4:08:52 AM
To: dots
Subject: [Dots] draft-ietf-dots-use-cases-09 posted - please review = and provide feedback.
 

We've re-organized the use-cases so that DOTS implementors won't feel
compelled to read through multiple use-cases with similar DOTS
communications models, while at the same time retaining those use-cases because they contain significant procedural, operational, and
topological variances which are of great significance to network
operators and end-customer organizations.

The wording in the DOTS communications model listings and several of the use-cases has been streamlined.  The security considerations were
updated to include DDoS attacks.

Finally, we really need WG feedback on the applicability of Section
3.2.2, 'Home Network DDoS Detection Collaboration for ISP network
management'.

Thanks much!

<https://datatracker.ietf.org/do= c/draft-ietf-dots-use-cases/>

-----------------------------------
Roland Dobbins <rdobbins@arbor.net>

_______________________________________________
Dots mailing list
Dots@ietf.org
https://www.ietf.org/mailman/listinfo/dots
www.ietf.org
Dots -- List for discussion of DDoS Open Threat Signaling (DOTS) technology= and directions. About Dots


--_000_CY1PR13MB08580C1CC5C88D6F8DA31DBAEB2B0CY1PR13MB0858namp_-- From nobody Mon Nov 13 12:56:43 2017 Return-Path: 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 C659D126DEE for ; Mon, 13 Nov 2017 12:56:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 KecFHVwbnukU for ; Mon, 13 Nov 2017 12:56:39 -0800 (PST) Received: from mail-vk0-x230.google.com (mail-vk0-x230.google.com [IPv6:2607:f8b0:400c:c05::230]) (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 5B2F21201F8 for ; Mon, 13 Nov 2017 12:56:39 -0800 (PST) Received: by mail-vk0-x230.google.com with SMTP id k82so2778380vkd.5 for ; Mon, 13 Nov 2017 12:56:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=ynaiwrlEmdWJ5tbioElM1xfJaeOw4oRQL4LdkOEjKZw=; b=Fk/K6BGDuZ1Dy1/qdn7ybSTwPIf0RHA9PKk2OQ4HIVS82V1bMSDIbFd+XPjwkq7r5K +qD5sjadMH2T4IV1GoyeIUj3Q0ntToHwAMzt1a3vCuakvSxzVRCqO/3zRk9ucYdBCiM2 fHNbIEBmdJeloFibvqh+RlkpyF2DdPdda4WoHgDnncOM8oGc+aN+nqPaMNrquDbKjt9G 5vmW4Fmi8mIwX8KGI2OZuJ/DnJoNG14iiD56Vl8t7DwPNlFqaPMW+P5ZvecEvu2asQ72 Fg4SFYgVk4IbjBhkR09adPgeX7S/0priqeKdSTt9iCwG1tjB8U4R4lbI1+zsjUq6SeGE 3Irg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=ynaiwrlEmdWJ5tbioElM1xfJaeOw4oRQL4LdkOEjKZw=; b=bPNtxXj/23M8+XNmKEKkOJpZo/vOukTIXSJ+t42aEum50ie+vD6uC3Tng4vOVfJ3yy vMm+E6GebuST6iblzmE13+UrlmAYo+nPXuh1EC3Z/ViasCdRhEuY+YUtyi/wDVvxyxho I76IMQg1WVNGXxxRchuU6bzrImpmFK3N/5ZYvMsA35wJa79zKcT6Cavh5bt6BTfU6Lju LP++WaUYH8S8/f6unklw10BbqMzBxs+HlR7FbrIYKii86N3TOAfhqNROO+fQYM5V3l1n 4lFuh1hjuZhfkheMdHr7DwKdi3apRX9Tp7rR5G1KwI4q1rmf0Y+WGmkYVxSWj9bx89gb 3Oxw== X-Gm-Message-State: AJaThX573Mj9vYinvwwaIT+wqmj8hITzYzwskVY1H+OJXvnOyQW94IEp juY4qTBlRZmZ2RBWrqe5wwc/M8xX5ZruxpRHUJE= X-Google-Smtp-Source: AGs4zMYxhHt16DAP2BUKfNRl++z67F6g9SCTXzQuHz5YzVGBqwtjkpsopCako/7xqQuqT9KdZsLsLmvNtx05DcBSfqg= X-Received: by 10.31.133.197 with SMTP id h188mr6665828vkd.99.1510606597552; Mon, 13 Nov 2017 12:56:37 -0800 (PST) MIME-Version: 1.0 Received: by 10.176.27.15 with HTTP; Mon, 13 Nov 2017 12:56:17 -0800 (PST) In-Reply-To: References: <2E5AB91E-888B-4F99-989D-66EC46311A0A@arbor.net> From: Artyom Gavrichenkov Date: Mon, 13 Nov 2017 23:56:17 +0300 Message-ID: To: Maheswaran Balasubramanian Cc: Roland Dobbins , dots Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Dots] draft-ietf-dots-use-cases-09 posted - please review and provide feedback. 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Nov 2017 20:56:42 -0000 Hi, So what? Someone should have that processing power, either far or close to the endpoint. Building a DPI system for attack detection on the ISP side only is costly and error-prone (as it is stated on the draft). RFC 7754, for one, insists on doing filtering *on* the endpoint, or at least as close to it as possible. Moreover, ISPs are recently becoming used to supply SOHO devices to their customers themselves, so this is purely a decision on their side where to set up the detection: everything in their network, except for endpoints, is essentially under their full control. A use case where DPI is run far from the endpoint is in fact covered already in 3.1, so 3.2.2 is just another option for a service provider. | Artyom Gavrichenkov | gpg: 2deb 97b1 0a3c 151d b67f 1ee5 00e7 94bc 4d08 9191 | mailto: ximaera@gmail.com | fb: ximaera | telegram: xima_era | skype: xima_era | tel. no: +7 916 515 49 58 On Mon, Nov 13, 2017 at 11:22 PM, Maheswaran Balasubramanian wrote: > > > Typically, SOHO devices(CPE) built with finite resources and offloading the > detection function to this CPE has its own limitation. Doing DPI (or) > heuristics at SOHO devices certainly requires enough resources (processing > power) also necessary intelligence built into it. > > > Thanks. > > > ________________________________ > From: Dots on behalf of Roland Dobbins > > Sent: Monday, November 13, 2017 4:08:52 AM > To: dots > Subject: [Dots] draft-ietf-dots-use-cases-09 posted - please review and > provide feedback. > > > We've re-organized the use-cases so that DOTS implementors won't feel > compelled to read through multiple use-cases with similar DOTS > communications models, while at the same time retaining those use-cases > because they contain significant procedural, operational, and > topological variances which are of great significance to network > operators and end-customer organizations. > > The wording in the DOTS communications model listings and several of the > use-cases has been streamlined. The security considerations were > updated to include DDoS attacks. > > Finally, we really need WG feedback on the applicability of Section > 3.2.2, 'Home Network DDoS Detection Collaboration for ISP network > management'. > > Thanks much! > > > > ----------------------------------- > Roland Dobbins > > _______________________________________________ > Dots mailing list > Dots@ietf.org > https://www.ietf.org/mailman/listinfo/dots > Dots Info Page - Internet Engineering Task Force > www.ietf.org > Dots -- List for discussion of DDoS Open Threat Signaling (DOTS) technology > and directions. About Dots > > > > _______________________________________________ > Dots mailing list > Dots@ietf.org > https://www.ietf.org/mailman/listinfo/dots > From nobody Mon Nov 13 19:56:38 2017 Return-Path: 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 59150127876 for ; Mon, 13 Nov 2017 19:56:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.521 X-Spam-Level: X-Spam-Status: No, score=-14.521 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 9nFpUm1zDNQW for ; Mon, 13 Nov 2017 19:56:34 -0800 (PST) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 701161242EA for ; Mon, 13 Nov 2017 19:56:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1244; q=dns/txt; s=iport; t=1510631794; x=1511841394; h=subject:to:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=GI1dtwUGBVxFzb/G/cOJbHYx7hlOVsyrXzueQh7yYQo=; b=T+SQmZG5p3m4akTH9XboyqdQvnG0oR+HVh4BWp+4mTLztrGgC9N7rSqV LkzT0RMHks3LlygqI73UgfLmr65tdWcliNjBUslqn2lJ/bHgsKhRxodNQ UFTaCKCguDl6CaLgqK1IH6wmpOaJt+NlmkLXz+THSUvLyEZZGSPMiqBVc 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0C4AQDSaApa/5xdJa1bGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYM1ZG4ng36ZToFXJpZQghEKGAuFGAKEZUEWAQEBAQEBAQEBayi?= =?us-ascii?q?FHgEBAQECAQEBIQ8BBTYQCwsOCgICJgICJzAGAQwGAgEBihEFCBCrJoInixEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAQEBAQEYBYEPgiWBKl2BVYISC4J2iCyCYwWKLYhOjy+?= =?us-ascii?q?Ha40ZghWGCINgJIchjGiJPIE5JgongXJVJRVJgmSDEYFsIzaISQEBAQ?= X-IronPort-AV: E=Sophos;i="5.44,392,1505779200"; d="scan'208";a="309848527" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 14 Nov 2017 03:56:33 +0000 Received: from [10.82.249.233] (rtp-vpn6-488.cisco.com [10.82.249.233]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id vAE3uVkO009894; Tue, 14 Nov 2017 03:56:32 GMT To: Roland Dobbins , dots References: <2E5AB91E-888B-4F99-989D-66EC46311A0A@arbor.net> From: Flemming Andreasen Message-ID: <142151b1-1206-4691-de70-eec8d3428c81@cisco.com> Date: Mon, 13 Nov 2017 22:56:30 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: <2E5AB91E-888B-4F99-989D-66EC46311A0A@arbor.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [Dots] draft-ietf-dots-use-cases-09 posted - please review and provide feedback. 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Nov 2017 03:56:36 -0000 On 11/12/17 5:38 PM, Roland Dobbins wrote: > > We've re-organized the use-cases so that DOTS implementors won't feel > compelled to read through multiple use-cases with similar DOTS > communications models, while at the same time retaining those > use-cases because they contain significant procedural, operational, > and topological variances which are of great significance to network > operators and end-customer organizations. > > The wording in the DOTS communications model listings and several of > the use-cases has been streamlined.  The security considerations were > updated to include DDoS attacks. > > Finally, we really need WG feedback on the applicability of Section > 3.2.2, 'Home Network DDoS Detection Collaboration for ISP network > management'. > I think the use case itself is perfectly valid. The actual text in the section is a bit verbose though. Thanks -- Flemming > Thanks much! > > > > ----------------------------------- > Roland Dobbins > > _______________________________________________ > Dots mailing list > Dots@ietf.org > https://www.ietf.org/mailman/listinfo/dots > . > From nobody Mon Nov 13 20:03:30 2017 Return-Path: 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 A96D0129405 for ; Mon, 13 Nov 2017 20:03:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cert.org 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 xBizPIzcWN5H for ; Mon, 13 Nov 2017 20:03:27 -0800 (PST) Received: from veto.sei.cmu.edu (veto.sei.cmu.edu [147.72.252.17]) (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 E62F412704A for ; Mon, 13 Nov 2017 20:03:26 -0800 (PST) Received: from korb.sei.cmu.edu (korb.sei.cmu.edu [10.64.21.30]) by veto.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id vAE43PkQ011885 for ; Mon, 13 Nov 2017 23:03:25 -0500 DKIM-Filter: OpenDKIM Filter v2.11.0 veto.sei.cmu.edu vAE43PkQ011885 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cert.org; s=yc2bmwvrj62m; t=1510632205; bh=Cek0LNHehmH51tTgL3Ncp5GWeMXGANic2E/SPxk63kg=; h=From:To:Subject:Date:From; b=YkwTWruBdwVdriqXnkA147bjVgGGQMg+4KQiAAwidCLDrS6GCZ+4FiBYwt7qccwZO FWiOQ/r/vPH+YPEfZnI+DvuPEa5yjAhKAb48XdOxgM7XmdqNDrxoyrNNNS/DZ7PBXA /02dEKlzcdumjr6eMACYU68SNP7we0IYQ+/BGifs= Received: from CASCADE.ad.sei.cmu.edu (cascade.ad.sei.cmu.edu [10.64.28.248]) by korb.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id vAE43MpL032634 for ; Mon, 13 Nov 2017 23:03:22 -0500 Received: from MARATHON.ad.sei.cmu.edu ([10.64.28.250]) by CASCADE.ad.sei.cmu.edu ([10.64.28.248]) with mapi id 14.03.0361.001; Mon, 13 Nov 2017 23:03:22 -0500 From: Roman Danyliw To: "'dots@ietf.org'" Thread-Topic: -08/-09 use case feedback Thread-Index: AdNc/NT9YV93gQXZTIyV7ok+R9WlOg== Date: Tue, 14 Nov 2017 04:03:21 +0000 Message-ID: <359EC4B99E040048A7131E0F4E113AFC0105004A86@marathon> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.64.22.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: [Dots] -08/-09 use case feedback 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Nov 2017 04:03:29 -0000 Hello! (wearing no hat) I like the direction that the updated text in -08/-09 has been taking in or= ganizing the use cases to emphasize the differences and reducing (or at lea= st acknowledging) the overlap in the use cases. I believe we should press = this editorial reorganization further. From the existing uses cases, they = appear to be "parameterized" around who asks for mitigation help, who accep= ts/services these mitigation requests and the interconnectivity between the= two. In broad strokes, I would propose an alternative organizational structure a= round these concepts. =20 ** Create a new Section 3.1 named "Mitigation Requestors/DOTS clients", to = summarize the various clients that would request mitigation help using cont= ent from Section 3.1.1.1 (IDMS), 3.1.3.1 (integrated client), 3.1.3.3 (CPE)= , 3.1.3.3 (smartphone app), 3.1.2.2 (MSSP as client), and 3.2.3 (orchestrat= or) (irrespective of whether they are single vs. multi-homed; inter vs. int= ra domain; etc). =09 ** Next, create a new Section 3.2 named "Mitigator/DOTS servers", to summar= ize the kinds of "organizations" (?) that provide mitigation for requestors= using content from Sections 3.1.1/3.1.2/3.1.3 (transit provider) and 3.1.2= (MSSPs). ** Next, create a new Section 3.3 named "Topologies", to summarize how requ= estors/mitigators are connected using content from 3.1.1 (single homed tran= sit), 3.1.2 (multiple homed transit), 3.1.3 (not all upstream transit offer= mitigation help), and 3.1.4 (MSSP). ** Finally, create a few examples that compose the concepts introduced in t= hese sections with great specificity. For example, the text in Section 3.1= .1 is a composition of "IDMS+single homed" and helpfully provides a lot det= ail that concretely explains a mitigation in action. Section 3.1, 2, and 3= would be relatively lightweight. When reviewing the intra-domain use cases (Section 3.2), their descriptions= do not cleanly fit with the above alternate organizational structure but a= lso aren't currently documented in the same way as the inter-domain use cas= es (Section 3.1). Per the Section 3.2.1 (suppression of outbound DDOS traf= fic from broadband) or 3.2.2 (home network) use cases, are there new client= or server types? Is there an additional topology? Communication pattern? = Or perhaps these use cases are just more detailed examples akin the detail= s in Section 3.1.1? Roman From nobody Mon Nov 13 20:25:08 2017 Return-Path: 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 B47CB1286B1 for ; Mon, 13 Nov 2017 20:25:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 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_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=thescout.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 JpPQI73qHLRn for ; Mon, 13 Nov 2017 20:25:03 -0800 (PST) Received: from mx0a-00196b01.pphosted.com (mx0b-00196b01.pphosted.com [67.231.157.166]) (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 9ABFE1271DF for ; Mon, 13 Nov 2017 20:25:03 -0800 (PST) Received: from pps.filterd (m0096262.ppops.net [127.0.0.1]) by mx0b-00196b01.pphosted.com (8.16.0.21/8.16.0.21) with SMTP id vAE4MDnQ024775; Mon, 13 Nov 2017 23:25:01 -0500 Received: from nam01-sn1-obe.outbound.protection.outlook.com (mail-sn1nam01lp0119.outbound.protection.outlook.com [207.46.163.119]) by mx0b-00196b01.pphosted.com with ESMTP id 2e7p3sr74c-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Mon, 13 Nov 2017 23:25:01 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=thescout.onmicrosoft.com; s=selector1-arbor-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=TuRKEwQ3vbzkdImwRCAGC87lU7zb8KliLqaKwX/zsOU=; b=MtEowmztH5JTybo+kIPH8KSpUgBGGtWKILZXJnM3jGkVfwBhu9VIx5/JoJbq34PQ0rINPSGAY7eCqZPpSalu4NS/1FtJxXbXO2Wh/z0zdArFRrySJsZq2+9csic5PVuVyOd4zyt45u7v8GHa++gOR5v2WqiX/OaGUqpkW3N+4dU= Received: from DM2PR0101MB1039.prod.exchangelabs.com (10.160.129.156) by DM2PR0101MB1039.prod.exchangelabs.com (10.160.129.156) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.239.5; Tue, 14 Nov 2017 04:24:59 +0000 Received: from DM2PR0101MB1039.prod.exchangelabs.com ([fe80::c4fd:5de3:ad60:185a]) by DM2PR0101MB1039.prod.exchangelabs.com ([fe80::c4fd:5de3:ad60:185a%18]) with mapi id 15.20.0239.005; Tue, 14 Nov 2017 04:24:58 +0000 From: "Dobbins, Roland" To: Roman Danyliw CC: "dots@ietf.org" Thread-Topic: [Dots] -08/-09 use case feedback Thread-Index: AdNc/NT9YV93gQXZTIyV7ok+R9WlOgAA7LWV Date: Tue, 14 Nov 2017 04:24:58 +0000 Message-ID: References: <359EC4B99E040048A7131E0F4E113AFC0105004A86@marathon> In-Reply-To: <359EC4B99E040048A7131E0F4E113AFC0105004A86@marathon> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [184.82.224.107] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DM2PR0101MB1039; 6:Tv+dQTtkDOhCFInt2dStSQJu2AWC+e2T6DKBWn/TTnGzQzR2ZpXFVIGBTM6FwPsaYhr/StONYUbcweXle3vupT0mwDOSJAgqYMIZLIwkCMZ80q1qNDdXQHOuJ916CYIKaPePkH0Eo2cnunGmlBpgXUe8pN0hqy1ucWVFjFOXMGZUPhVKSWVY0OFrxEpt45nKt+r5Mj9M2xgE8S/h75zNF2sH2BWhkUYI6bLxJIvIzjsXANM4c/3BphUiy7I1QI6KW0nY+uvWcZ448Rbz0Nc813iJnWq6Pr9bgRYUHWH/k+TbopAq3En+NZN5pKbS1fITs7HMwkSqaith/0DqcDhvO05hh8vEY88nGNj0PJJ6s2I=; 5:FmIL6EBxdTIPvBbhZrlkLrOb2MPJAuRyGMpg8s5NQeS69CwXh/tepxGpJDWeJr8+LWLMyZV8sqWN3XTGDYPPlPoq2KHunScC/7Nrq7NJzaENwRPPcg0zVEbXuGi+67G12CZFOyQHfik6plMNvDb3NrGZ5fKzcGEhJ5EiBjKq0mw=; 24:2s9oJYy2Df6vutDQUAGod1lXAzoq8IIgLBizyI/KzZcX+X0NiTNilc8hK9PtQuu+/zMrM2MR3jRTvLk4hynGrx/mQJAdIFar2x2MXGp/luM=; 7:YvZehkD98t3rmtzPPoEzLYRAqBXUGkokum4OGZLf5qZilPdqzcRhYaHh0RvaQ3YOpQJPzc9H/7wYcSjvdvBtnxpXenf15PNhDNCwGCGxXXXAAAI7uNiB2Snf2zPMWV5SY0cb5QOnxEwA6KwVuzXEKzz2MGqncbCwx+Vu4zNG0E8sbog2v7JWGlrXvWDCu1KmmP1AGoT9F46hOiKcN0tYwQRPRChxgsIVulda3XEtbqKBglcg5n0hTs3clZdR77eV x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 8419de56-a6e9-4115-c77d-08d52b17aa9c x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(2017052603258); SRVR:DM2PR0101MB1039; x-ms-traffictypediagnostic: DM2PR0101MB1039: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(5005006)(8121501046)(93006095)(93001095)(100000703101)(100105400095)(3002001)(3231022)(10201501046)(6041248)(20161123558100)(20161123560025)(20161123555025)(20161123564025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123562025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:DM2PR0101MB1039; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:DM2PR0101MB1039; x-forefront-prvs: 04916EA04C x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(376002)(346002)(189002)(199003)(24454002)(51914003)(8936002)(3660700001)(3280700002)(6916009)(2950100002)(105586002)(106356001)(36756003)(97736004)(2906002)(5250100002)(68736007)(7736002)(8676002)(81166006)(81156014)(3846002)(6116002)(102836003)(2900100001)(5660300001)(66066001)(99286004)(478600001)(229853002)(53936002)(25786009)(33656002)(4326008)(14454004)(54896002)(101416001)(189998001)(236005)(83716003)(6486002)(6512007)(6506006)(82746002)(53546010)(86362001)(6436002)(76176999)(54356999)(316002)(50986999)(6246003); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR0101MB1039; H:DM2PR0101MB1039.prod.exchangelabs.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: arbor.net does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_B8886244E8674535BAECB8285E358786arbornet_" MIME-Version: 1.0 X-OriginatorOrg: arbor.net X-MS-Exchange-CrossTenant-Network-Message-Id: 8419de56-a6e9-4115-c77d-08d52b17aa9c X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Nov 2017 04:24:58.4905 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 54f11205-d4aa-4809-bd36-0b542199c5b2 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR0101MB1039 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-11-14_03:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1709140000 definitions=main-1711140058 Archived-At: Subject: Re: [Dots] -08/-09 use case feedback 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Nov 2017 04:25:06 -0000 --_000_B8886244E8674535BAECB8285E358786arbornet_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQpPbiBOb3YgMTQsIDIwMTcsIGF0IDExOjAzLCBSb21hbiBEYW55bGl3IDxyZGRAY2VydC5vcmc8 bWFpbHRvOnJkZEBjZXJ0Lm9yZz4+IHdyb3RlOg0KDQpPciBwZXJoYXBzIHRoZXNlIHVzZSBjYXNl cyBhcmUganVzdCBtb3JlIGRldGFpbGVkIGV4YW1wbGVzIGFraW4gdGhlIGRldGFpbHMgaW4gU2Vj dGlvbiAzLjEuMT8NCg0KVGhleSdyZSBsYXJnZWx5IG1vcmUgZGV0YWlsZWQgZXhhbXBsZXMsIHdo aWNoIGFyZSBpbXBvcnRhbnQgaW4gdGVybXMgb2YgYSkgc2hvd2luZyBET1RTIGltcGxlbWVudG9y cyBob3cgaXQgY2FuIGJlIHVzZWQgaW4gcHJhY3RpY2U7IGIpIHNob3dpbmcgb3BlcmF0aW9uYWwg Zm9sa3MgdGhlIHNhbWUgdGhpbmcsIHdpdGggYWRkaXRpb25hbCAnZXh0ZXJuYWxpdGllcycgd2hp Y2ggbmV2ZXJ0aGVsZXNzIGFyZSBpbXBvcnRhbnQ7ICYgYykgZWR1Y2F0aW5nIG5vbi1zcGVjaWFs aXN0cyBhcyB0byB3aHkgRE9UUyBpcyBpbXBvcnRhbnQuDQoNClRoYW5rcyBmb3IgdGhlIGRldGFp bGVkIGZlZWRiYWNrIQ0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KUm9s YW5kIERvYmJpbnMgPHJkb2JiaW5zQGFyYm9yLm5ldDxtYWlsdG86cmRvYmJpbnNAYXJib3IubmV0 Pj4NCg0K --_000_B8886244E8674535BAECB8285E358786arbornet_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IGRpcj0iYXV0byI+DQo8 ZGl2PjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+T24gTm92IDE0LCAyMDE3LCBhdCAx MTowMywgUm9tYW4gRGFueWxpdyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnJkZEBjZXJ0Lm9yZyI+cmRk QGNlcnQub3JnPC9hPiZndDsgd3JvdGU6PGJyPg0KPGJyPg0KPC9kaXY+DQo8YmxvY2txdW90ZSB0 eXBlPSJjaXRlIj4NCjxkaXY+T3IgcGVyaGFwcyB0aGVzZSB1c2UgY2FzZXMgYXJlIGp1c3QgbW9y ZSBkZXRhaWxlZCBleGFtcGxlcyBha2luIHRoZSBkZXRhaWxzIGluIFNlY3Rpb24gMy4xLjE/PC9k aXY+DQo8L2Jsb2NrcXVvdGU+DQo8YnI+DQo8ZGl2PlRoZXkncmUgbGFyZ2VseSBtb3JlIGRldGFp bGVkIGV4YW1wbGVzLCB3aGljaCBhcmUgaW1wb3J0YW50IGluIHRlcm1zIG9mIGEpIHNob3dpbmcg RE9UUyBpbXBsZW1lbnRvcnMgaG93IGl0IGNhbiBiZSB1c2VkIGluIHByYWN0aWNlOyBiKSBzaG93 aW5nIG9wZXJhdGlvbmFsIGZvbGtzIHRoZSBzYW1lIHRoaW5nLCB3aXRoIGFkZGl0aW9uYWwgJ2V4 dGVybmFsaXRpZXMnIHdoaWNoIG5ldmVydGhlbGVzcyBhcmUgaW1wb3J0YW50OyAmYW1wOyBjKSBl ZHVjYXRpbmcNCiBub24tc3BlY2lhbGlzdHMgYXMgdG8gd2h5IERPVFMgaXMgaW1wb3J0YW50Ljwv ZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+VGhhbmtzIGZvciB0aGUgZGV0YWlsZWQgZmVl ZGJhY2shPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj48c3BhbiBzdHlsZT0iYmFja2dy b3VuZC1jb2xvcjogcmdiYSgyNTUsIDI1NSwgMjU1LCAwKTsiPjxzcGFuIHN0eWxlPSJmb250LXZh cmlhbnQtbGlnYXR1cmVzOiBub3JtYWw7IGZvbnQtdmFyaWFudC1lYXN0LWFzaWFuOiBub3JtYWw7 IGZvbnQtdmFyaWFudC1wb3NpdGlvbjogbm9ybWFsOyBsaW5lLWhlaWdodDogbm9ybWFsOyI+LS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08L3NwYW4+PGJyIHN0eWxlPSJmb250LXZh cmlhbnQtbGlnYXR1cmVzOiBub3JtYWw7IGZvbnQtdmFyaWFudC1lYXN0LWFzaWFuOiBub3JtYWw7 IGZvbnQtdmFyaWFudC1wb3NpdGlvbjogbm9ybWFsOyBsaW5lLWhlaWdodDogbm9ybWFsOyI+DQo8 L3NwYW4+DQo8ZGl2IHN0eWxlPSJmb250LXZhcmlhbnQtbGlnYXR1cmVzOiBub3JtYWw7IGZvbnQt dmFyaWFudC1lYXN0LWFzaWFuOiBub3JtYWw7IGZvbnQtdmFyaWFudC1wb3NpdGlvbjogbm9ybWFs OyBsaW5lLWhlaWdodDogbm9ybWFsOyI+DQo8c3BhbiBzdHlsZT0iYmFja2dyb3VuZC1jb2xvcjog cmdiYSgyNTUsIDI1NSwgMjU1LCAwKTsiPlJvbGFuZCBEb2JiaW5zICZsdDs8YSBocmVmPSJtYWls dG86cmRvYmJpbnNAYXJib3IubmV0Ij5yZG9iYmluc0BhcmJvci5uZXQ8L2E+Jmd0Ozwvc3Bhbj48 L2Rpdj4NCjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_B8886244E8674535BAECB8285E358786arbornet_-- From nobody Mon Nov 13 22:34:29 2017 Return-Path: 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 DD417128B8D for ; Mon, 13 Nov 2017 22:34:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.752 X-Spam-Level: X-Spam-Status: No, score=-2.752 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_BRBL_LASTEXT=1.449, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 pwpWSjYqUs67 for ; Mon, 13 Nov 2017 22:34:25 -0800 (PST) Received: from z9m9z.htt-consult.com (z9m9z.htt-consult.com [50.253.254.3]) (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 00D36127342 for ; Mon, 13 Nov 2017 22:34:24 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by z9m9z.htt-consult.com (Postfix) with ESMTP id D594262136 for ; Tue, 14 Nov 2017 01:34:23 -0500 (EST) X-Virus-Scanned: amavisd-new at htt-consult.com Received: from z9m9z.htt-consult.com ([127.0.0.1]) by localhost (z9m9z.htt-consult.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id eV1ZCfBWE6ZW for ; Tue, 14 Nov 2017 01:34:18 -0500 (EST) Received: from lx120e.htt-consult.com (dhcp-80f0.meeting.ietf.org [31.133.128.240]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by z9m9z.htt-consult.com (Postfix) with ESMTPSA id 3C74562124 for ; Tue, 14 Nov 2017 01:34:14 -0500 (EST) To: "dots@ietf.org" From: Robert Moskowitz Message-ID: <3b11b3bd-5bcc-c53f-9725-64a8b1ae1fa2@htt-consult.com> Date: Tue, 14 Nov 2017 14:34:08 +0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: [Dots] Comment on client-identifier construction in draft-ietf-dots-signal-channel-06.txt 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Nov 2017 06:34:28 -0000 The text: If the DOTS client is using the certificate provisioned by the Enrollment over Secure Transport (EST) server [RFC6234] in the DOTS gateway-domain to authenticate itself to the DOTS gateway, then the 'client-identifier' value will be the output of a cryptographic hash algorithm whose input is the DER-encoded ASN.1 representation of the Subject Public Key Info (SPKI) of an X.509 certificate. The output of the cryptographic hash algorithm is base64url encoded. In this version of the specification, the cryptographic hash algorithm used is SHA-256 [RFC6234]. If the 'client-identifier' value is already present in the mitigation request received from the DOTS client, the DOTS gateway computes the 'client-identifier' value, as discussed above, and adds the computed 'client-identifier' value to the end of the 'client-identifier' list. The DOTS server MUST NOT use the 'client-identifier' for the DOTS client authentication process. Newer EDDSA certificates do not use SHA-256. The hash used should match what is used in the certificate. In what way is the output of a SHA-256 operation base64url encoded? Are you saying you want to take the hash and do this to it? Is this to make it text safe? Perhaps then you should say it. Bob From nobody Mon Nov 13 23:17:59 2017 Return-Path: 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 677FA124BE8 for ; Mon, 13 Nov 2017 23:17:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.752 X-Spam-Level: X-Spam-Status: No, score=-2.752 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_BRBL_LASTEXT=1.449, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 PiHR9RWteyCH for ; Mon, 13 Nov 2017 23:17:56 -0800 (PST) Received: from z9m9z.htt-consult.com (z9m9z.htt-consult.com [50.253.254.3]) (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 DEF86120046 for ; Mon, 13 Nov 2017 23:17:55 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by z9m9z.htt-consult.com (Postfix) with ESMTP id F0F446213A for ; Tue, 14 Nov 2017 02:17:54 -0500 (EST) X-Virus-Scanned: amavisd-new at htt-consult.com Received: from z9m9z.htt-consult.com ([127.0.0.1]) by localhost (z9m9z.htt-consult.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id WyxH6vAEjQMb for ; Tue, 14 Nov 2017 02:17:50 -0500 (EST) Received: from lx120e.htt-consult.com (dhcp-80f0.meeting.ietf.org [31.133.128.240]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by z9m9z.htt-consult.com (Postfix) with ESMTPSA id C7B5362125 for ; Tue, 14 Nov 2017 02:17:48 -0500 (EST) To: "dots@ietf.org" From: Robert Moskowitz Message-ID: Date: Tue, 14 Nov 2017 15:17:44 +0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: [Dots] IPaddress in certificates 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Nov 2017 07:17:57 -0000 I just checked and RFC 5280 does allow IPaddresses in subjectAltName, but as I recall from the debates... Better DNSname. A provider that is issuing certificates to a client that is only known by IPaddress should be smart and have some way to map that to a name so that certificates will still continue to work if the device is readdressed. I can think of half-a-dozen ways to do this. Just seem to recall all sorts of negative comments of addresses in certs. Bob From nobody Tue Nov 14 00:42:12 2017 Return-Path: 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 591AE1200E5 for ; Tue, 14 Nov 2017 00:42:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.001 X-Spam-Level: X-Spam-Status: No, score=-7.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham 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 X_2k8cljer7i for ; Tue, 14 Nov 2017 00:42:05 -0800 (PST) Received: from MIVWSMAILOUT1.mcafee.com (mivwsmailout1.mcafee.com [161.69.47.167]) (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 AB9F912008A for ; Tue, 14 Nov 2017 00:42:04 -0800 (PST) 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=1510648922; 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: authentication-results:x-originating-ip:x-ms-publictraffictype: x-microsoft-exchange-diagnostics:x-ms-exchange-antispam-srfa-diagnostics: x-ms-office365-filtering-correlation-id:x-microsoft-antispam: x-ms-traffictypediagnostic:x-microsoft-antispam-prvs: x-exchange-antispam-report-test:x-exchange-antispam-report-cfa-test: x-forefront-prvs:x-forefront-antispam-report: received-spf:spamdiagnosticoutput:spamdiagnosticmetadata: 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-Transport-CrossTenantHeadersStamped: X-OriginatorOrg:X-NAI-Spam-Flag:X-NAI-Spam-Level: X-NAI-Spam-Threshold:X-NAI-Spam-Score:X-NAI-Spam-Version; bh=2lyCAyIdFRrRhZXvSCGrYYgS74OamFd2Yoll/B 6YmfE=; b=lAumCv5oQnk07UA0U57DxTF8rM6vUCD4Oz8J7Dyt D8VtDZrnCTqDY9ZOgop7OcC0T9CkJCwcukvPKtokztCbH4Ox1x mRHXJtvY4NbaAij/Ex417Aipmu4WSPjcBKos85Kny2fa+U0iXh GyyGXRCDl4NyIVENpQmAQbBbrDPnYZs= Received: from MIVEXAPP1N02.corpzone.internalzone.com (mivexapp1n02.corpzone.internalzone.com [10.48.48.89]) by MIVWSMAILOUT1.mcafee.com with smtp id 5dee_de4a_fca0dd8e_97c8_4723_bef9_ccfa13c68ef2; Tue, 14 Nov 2017 02:42:01 -0600 Received: from MIVEXUSR1N05.corpzone.internalzone.com (10.48.48.85) by MIVEXAPP1N02.corpzone.internalzone.com (10.48.48.89) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Tue, 14 Nov 2017 03:41:56 -0500 Received: from MIVEXUSR1N01.corpzone.internalzone.com (10.48.48.81) by MIVEXUSR1N05.corpzone.internalzone.com (10.48.48.85) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Tue, 14 Nov 2017 03:41:55 -0500 Received: from MIVO365EDGE4.corpzone.internalzone.com (10.48.176.87) by MIVEXUSR1N01.corpzone.internalzone.com (10.48.48.81) with Microsoft SMTP Server (TLS) id 15.0.1347.2 via Frontend Transport; Tue, 14 Nov 2017 03:41:54 -0500 Received: from NAM01-BN3-obe.outbound.protection.outlook.com (10.48.176.240) by edge.mcafee.com (10.48.176.87) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Tue, 14 Nov 2017 03:41:53 -0500 Received: from DM5PR16MB1788.namprd16.prod.outlook.com (10.172.44.144) by DM5PR16MB1786.namprd16.prod.outlook.com (10.172.44.142) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.218.12; Tue, 14 Nov 2017 08:41: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.20.0218.015; Tue, 14 Nov 2017 08:41:53 +0000 From: "Konda, Tirumaleswar Reddy" To: Robert Moskowitz , "dots@ietf.org" Thread-Topic: [Dots] Comment on client-identifier construction in draft-ietf-dots-signal-channel-06.txt Thread-Index: AQHTXRKyl5dtK2pDCEuUNpC/Ix68g6MTcy+w Date: Tue, 14 Nov 2017 08:41:53 +0000 Message-ID: References: <3b11b3bd-5bcc-c53f-9725-64a8b1ae1fa2@htt-consult.com> In-Reply-To: <3b11b3bd-5bcc-c53f-9725-64a8b1ae1fa2@htt-consult.com> 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: [103.245.47.20] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DM5PR16MB1786; 6:l5ZZZB+6rhfV+wnwEPzDQcsu96auhbd0DMX+xPTsQhw+QIBI29J8turEYwap7UbytP9Jf6q0kelgk2VxdlTG7L1Zoki4KEJ7yvclCwfAZDr0iKbLf+PzcfJiHzAATYAwFFnddss9k6aiz0FbO+gmneEH9f+PaxHl2y9MzcKThq73bhdqLAU3DMAUV7GvmVuWE+IZKwjMug/TOpjLbh9PqeJufeanZX4y7soqcJwisyjs7AtXoWiUb+qStVYUAeGXkeFM0LAORmiSXx+xnE/XW40NoqBSdohV2erD+UwCZjY+tzfzyzNxPoAPBrQ/FUK7uOUA9dW3n5Kub+yndUibZ8b89phiDJJgZe91/n1ZM9E=; 5:u6QTr7BGiMseGt+FEPpVFiO7DGai6M5JJvuU9JbawXhojCUuBntGKYSYNIkphKMWaf5o2GUnIgOPw+pvgj63ylu1NUuKrheRvubWpJ7TpaNj7VoWQn0ZeJ2zt5C5kEX9+cjZle6cFQEFzLX84IxBprT5LVNLDc5P+6fCOzkgdSw=; 24:pRBrOmnZC4c2f7T/8NMKSy36XTr4BGR1ytQ4WLGOcebK2BWEy8GAyprkFu3JDbrP8go/0xPac2F+doAp5UoPd5RD0nNE4/lYR7ZJW4V+emQ=; 7:w4tNPeZE4PoVYbzo6InH4Ba6MD7UbKG6smsMfYxUWik2XcdaGlsmtsy+vEkjPyAVrWaxfXpqjeUgwkpNh4EagPE8ADVrgiN7SC2/qtpFciDzUtZVvdOxTSZodQVRMPKZ5RypRbD6Tz0aOWWtoVZ3YRVrWwlSJ2qGqKVcsyLyOtqPIdDhU+YfP8wuKR+jS3UUiy69ZDGntf0vNLNWzB032ODEBmXoKZ3FZlYYRTCJVM6InFg4UGrylyYEgtLlyzzZ x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 2c56ae53-2239-4f07-2d1e-08d52b3b8e6a x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(2017052603199); SRVR:DM5PR16MB1786; x-ms-traffictypediagnostic: DM5PR16MB1786: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(8121501046)(5005006)(10201501046)(3002001)(3231022)(100000703101)(100105400095)(93006095)(93001095)(6041248)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123562025)(20161123558100)(20161123564025)(20161123555025)(20161123560025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:DM5PR16MB1786; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:DM5PR16MB1786; x-forefront-prvs: 04916EA04C x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(346002)(376002)(39860400002)(199003)(189002)(13464003)(32952001)(102836003)(6116002)(86362001)(2950100002)(2906002)(8676002)(3846002)(68736007)(81156014)(81166006)(7736002)(7696004)(14454004)(2900100001)(105586002)(5660300001)(8936002)(106356001)(53546010)(2501003)(74316002)(230783001)(189998001)(50986999)(316002)(101416001)(25786009)(6306002)(6506006)(305945005)(55016002)(6436002)(9686003)(99286004)(77096006)(3660700001)(76176999)(53936002)(72206003)(6246003)(229853002)(110136005)(97736004)(966005)(80792005)(33656002)(3280700002)(66066001)(478600001)(54356999)(85282002); DIR:OUT; SFP:1101; SCL:1; SRVR:DM5PR16MB1786; H:DM5PR16MB1788.namprd16.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: McAfee.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 2c56ae53-2239-4f07-2d1e-08d52b3b8e6a X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Nov 2017 08:41:53.4556 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4943e38c-6dd4-428c-886d-24932bc2d5de X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR16MB1786 X-OriginatorOrg: mcafee.com X-NAI-Spam-Flag: NO X-NAI-Spam-Level: X-NAI-Spam-Threshold: 15 X-NAI-Spam-Score: 0.1 X-NAI-Spam-Version: 2.3.0.9418 : core <6157> : inlines <6171> : streams <1770247> : uri <2533674> Archived-At: Subject: Re: [Dots] Comment on client-identifier construction in draft-ietf-dots-signal-channel-06.txt 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Nov 2017 08:42:07 -0000 Hi Bob,=20 Please see inline > -----Original Message----- > From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Robert Moskowitz > Sent: Tuesday, November 14, 2017 12:04 PM > To: dots@ietf.org > Subject: [Dots] Comment on client-identifier construction in draft-ietf-d= ots- > signal-channel-06.txt >=20 > The text: >=20 > If the DOTS client is using the certificate provisioned by the > Enrollment over Secure Transport (EST) server [RFC6234] in the DOTS > gateway-domain to authenticate itself to the DOTS gateway, then the > 'client-identifier' value will be the output of a cryptographic hash > algorithm whose input is the DER-encoded ASN.1 representation of the > Subject Public Key Info (SPKI) of an X.509 certificate. The output > of the cryptographic hash algorithm is base64url encoded. In this > version of the specification, the cryptographic hash algorithm used > is SHA-256 [RFC6234]. If the 'client-identifier' value is already > present in the mitigation request received from the DOTS client, the > DOTS gateway computes the 'client-identifier' value, as discussed > above, and adds the computed 'client-identifier' value to the end of > the 'client-identifier' list. The DOTS server MUST NOT use the > 'client-identifier' for the DOTS client authentication process. >=20 > Newer EDDSA certificates do not use SHA-256. The hash used should match > what is used in the certificate. No, the approach is similar to the one used in https://tools.ietf.org/html/= rfc7469#section-2.4 and works for EDDSA certificates.=20 >=20 > In what way is the output of a SHA-256 operation base64url encoded? Are > you saying you want to take the hash and do this to it? =20 Yes, just like it's done in RFC7469 (except that it uses base64 encoding). > Is this to make it text > safe? Perhaps then you should say it. Base64rul encoding is picked to have the same representation for the client= - identifier in both DOTS signal and data=20 channel protocols (see https://tools.ietf.org/html/draft-ietf-dots-data-cha= nnel-07#section-3.2.2, In RESTCONF, URI-encoded path expressions are used). -Tiru >=20 > Bob >=20 > _______________________________________________ > Dots mailing list > Dots@ietf.org > https://www.ietf.org/mailman/listinfo/dots From nobody Tue Nov 14 00:54:18 2017 Return-Path: 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 2B522126FB3 for ; Tue, 14 Nov 2017 00:54:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.001 X-Spam-Level: X-Spam-Status: No, score=-7.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham 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 s4q6sC1kmUbT for ; Tue, 14 Nov 2017 00:54:15 -0800 (PST) Received: from MIVWSMAILOUT1.mcafee.com (mivwsmailout1.mcafee.com [161.69.47.167]) (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 43378124D6C for ; Tue, 14 Nov 2017 00:54:15 -0800 (PST) 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=1510649654; 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: authentication-results:x-originating-ip:x-ms-publictraffictype: x-microsoft-exchange-diagnostics:x-ms-exchange-antispam-srfa-diagnostics: x-ms-office365-filtering-correlation-id:x-microsoft-antispam: x-ms-traffictypediagnostic:x-microsoft-antispam-prvs: x-exchange-antispam-report-test:x-exchange-antispam-report-cfa-test: x-forefront-prvs:x-forefront-antispam-report: received-spf:spamdiagnosticoutput:spamdiagnosticmetadata: 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-Transport-CrossTenantHeadersStamped: X-OriginatorOrg:X-NAI-Spam-Flag:X-NAI-Spam-Threshold: X-NAI-Spam-Score:X-NAI-Spam-Version; bh=Q 9cBZqk4HyzUrKtwy8k3A0q8aaJJfUytQCDOQX0na4 U=; b=Lrd42z32nBSkenRsCvkLumf9jkN5cK4ryohMeEi1+qYF 3/HQ6S7nfxpxuWaRNKST2PGB/kew9W/YUIVT4vGvCTYrPpBeYG HarQIrJKnqZIRut7MRSzXNb4zgzv8cM9kwk+UdcmryCvi3kvi+ xaOu0EpRqdAz7ir2U53fqfKtm38= Received: from MIVEXAPP1N02.corpzone.internalzone.com (mivexapp1n02.corpzone.internalzone.com [10.48.48.89]) by MIVWSMAILOUT1.mcafee.com with smtp id 5dee_eb97_23393d4a_5d7f_4e67_af26_28bd3cc58810; Tue, 14 Nov 2017 02:54:13 -0600 Received: from MIVEXUSR1N02.corpzone.internalzone.com (10.48.48.82) by MIVEXAPP1N02.corpzone.internalzone.com (10.48.48.89) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Tue, 14 Nov 2017 03:54:12 -0500 Received: from MIVEXUSR1N06.corpzone.internalzone.com (10.48.48.86) by MIVEXUSR1N02.corpzone.internalzone.com (10.48.48.82) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Tue, 14 Nov 2017 03:54:11 -0500 Received: from MIVO365EDGE3.corpzone.internalzone.com (10.48.176.86) by MIVEXUSR1N06.corpzone.internalzone.com (10.48.48.86) with Microsoft SMTP Server (TLS) id 15.0.1347.2 via Frontend Transport; Tue, 14 Nov 2017 03:54:11 -0500 Received: from NAM01-BY2-obe.outbound.protection.outlook.com (10.48.176.243) by edge.mcafee.com (10.48.176.86) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Tue, 14 Nov 2017 03:54:09 -0500 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.20.218.12; Tue, 14 Nov 2017 08:54:10 +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.20.0218.015; Tue, 14 Nov 2017 08:54:10 +0000 From: "Konda, Tirumaleswar Reddy" To: Robert Moskowitz , "dots@ietf.org" Thread-Topic: [Dots] IPaddress in certificates Thread-Index: AQHTXRjBlfsYT0g+7kGIi66XtY7s3aMTj/VA Date: Tue, 14 Nov 2017 08:54:09 +0000 Message-ID: References: In-Reply-To: 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: [103.245.47.20] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DM5PR16MB1787; 6:P7ChAhNsPg7IG0EBs97Ac123PelsH/D3ADHzA7Hiap3Y6KAGh88Z8LHXDetFWYWGMBw8MXLAk18d0bed7iaH20Q8cATAzknZYybjyZu7RspEReX2vMlpGKKZDymN+bzMa5WxW0FrokETixGesog/jyaiBg68RK18nyks4pF1kGvmzfVH7/K+eB1sJphxOJxbW8G8tCK3QgNYi5ouZ5yyklBHW4HmWQWPrcf/gSUGf141BZmrY9k3GdaReDAz5nUYjJ+caIsfOB+B+DRY2zdmmog23HVR63WvpWoJaBs2PK1GijocDarVfWCe/SWf4cZ3F4vrW3wm6Sb39OzzvabZVNmGgM/raJgt9gYOk56GwQA=; 5:kMVotjigrjgc45Yq7waaXQLq1I6jAntx8nqYkdGKVGys+xcCcxzk1Wb1l3IaqNWniiqbjXhv4wn7U2d0e2uLV1Nvro00u8pLcQ2IgirS/giAjV6RL31XaV5GOa07kBAVlorr9Eh7OnQg4zdT/+oDiDPlDsSvNTdJlxcjaf0xuEg=; 24:4g4+VrjEU/AdOc0k2JnCLsIez0vSkGNMN7L3qvWfBD1ESt85fVj6yGShYq6OeTI5ABvIBKs7uv5Yv4FXI9JksMd+qOFNtI8ajpEZP502TEY=; 7:Ep0i8rT5OXruJYzwfLHHzfZ0X3BWt67cHXJzy9uGbNiShdRSVSXEzJdThIBiClEX3nnoWVhA8hP67DrWa1s04e8t8nLlQbhaWt8RTZBenCE5wE/BuAoGQ7x5utWYHCj72IAS7htoRQnEMi2ZZBO6Z/Z/IkHHKNY+ed7ZCsZLgF+coAmEvHFXnxlCvTM0hBaDTOJg7lPJ2d3UUXk8S6ZbDkNvo9Dd8wuEWne+xM7bSYbX1M2nyqLocMQsowaq5U8i x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 41950002-d54f-442c-5455-08d52b3d456f x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(2017052603258); SRVR:DM5PR16MB1787; x-ms-traffictypediagnostic: DM5PR16MB1787: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(5005006)(8121501046)(93006095)(93001095)(100000703101)(100105400095)(3002001)(3231022)(10201501046)(6041248)(20161123564025)(20161123562025)(20161123555025)(20161123558100)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123560025)(6072148)(201708071742011)(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: 04916EA04C x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(376002)(39860400002)(346002)(32952001)(189002)(199003)(13464003)(101416001)(8936002)(305945005)(2501003)(478600001)(7736002)(2950100002)(25786009)(99286004)(80792005)(229853002)(2900100001)(5660300001)(81166006)(14454004)(81156014)(9686003)(6246003)(53936002)(74316002)(6306002)(55016002)(966005)(110136005)(316002)(3280700002)(72206003)(8676002)(3660700001)(2906002)(7696004)(68736007)(97736004)(33656002)(53546010)(6436002)(105586002)(77096006)(106356001)(6116002)(102836003)(3846002)(76176999)(54356999)(86362001)(66066001)(189998001)(6506006)(50986999)(85282002); DIR:OUT; SFP:1101; SCL:1; SRVR:DM5PR16MB1787; H:DM5PR16MB1788.namprd16.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; 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: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 41950002-d54f-442c-5455-08d52b3d456f X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Nov 2017 08:54:09.9779 (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 <6157> : inlines <6171> : streams <1770247> : uri <2533679> Archived-At: Subject: Re: [Dots] IPaddress in certificates 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Nov 2017 08:54:17 -0000 Agreed, https://tools.ietf.org/html/rfc6125 discusses various drawbacks of = using IP addresses in subjectAltName. Even DNS-over-(D)TLS for server authe= ntication uses "authentication domain names" for PKIX Certificate Based Aut= hentication and not IP addresses. -Tiru > -----Original Message----- > From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Robert Moskowitz > Sent: Tuesday, November 14, 2017 12:48 PM > To: dots@ietf.org > Subject: [Dots] IPaddress in certificates >=20 > I just checked and RFC 5280 does allow IPaddresses in subjectAltName, but > as I recall from the debates... Better DNSname. >=20 > A provider that is issuing certificates to a client that is only known by > IPaddress should be smart and have some way to map that to a name so that > certificates will still continue to work if the device is readdressed. I= can think > of half-a-dozen ways to do this. >=20 > Just seem to recall all sorts of negative comments of addresses in certs. >=20 > Bob >=20 >=20 >=20 > _______________________________________________ > Dots mailing list > Dots@ietf.org > https://www.ietf.org/mailman/listinfo/dots From nobody Fri Nov 17 09:50:54 2017 Return-Path: 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 AD6421243FE for ; Fri, 17 Nov 2017 09:50:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.8 X-Spam-Level: X-Spam-Status: No, score=0.8 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 SgZZgfcNveLx for ; Fri, 17 Nov 2017 09:50:50 -0800 (PST) Received: from mail.jpshallow.com (mail.jpshallow.com [217.40.240.153]) (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 C0D1A1200FC for ; Fri, 17 Nov 2017 09:50:49 -0800 (PST) Received: from [127.0.0.1] (helo=N01332) by mail.jpshallow.com with smtps (TLSv1:ECDHE-RSA-AES256-SHA:256) (Exim 4.89) (envelope-from ) id 1eFkms-0005uX-T8 for ietf-supjps-dots@ietf.org; Fri, 17 Nov 2017 17:50:46 +0000 From: "Jon Shallow" To: Date: Fri, 17 Nov 2017 17:50:46 -0000 Message-ID: <014b01d35fcc$98a8e910$c9fabb30$@jpshallow.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_014C_01D35FCC.98AA2190" X-Mailer: Microsoft Outlook 14.0 Content-Language: en-gb Thread-Index: AdNfzJPvzFwhg6Z7ReePjrKxtiw2xA== Archived-At: Subject: [Dots] Data Channel ACL Actions 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Nov 2017 17:50:53 -0000 This is a multipart message in MIME format. ------=_NextPart_000_014C_01D35FCC.98AA2190 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi there, draft-ietf-netmod-acl-model-14 has another significant change which affects DOTS. draft-ietf-netmod-acl-model-13 has the following for ACL actions +--rw actions | +--rw (packet-handling)? | | +--:(deny) | | | +--rw deny? empty | | +--:(permit) | | +--rw permit? empty | +--rw logging? Boolean draft-ietf-netmod-acl-model-14 has updated it with this +--rw actions | {acl-aggregate-stats or interface-acl-aggregate }? | +--rw forwarding identityref | +--rw logging? identityref | +--rw icmp-off? Boolean With different definitions for forwarding. So, I reckon that Figure 8 should look like POST /restconf/data/ietf-dots-access-control-list HTTP/1.1 Host: www.example.com Content-Format: "application/yang.api+json" { "ietf-dots-access-control-list:access-lists": { "client-identifier": [ "dz6pHjaADkaFTbjr0JGBpw", "iAYmCNPmrYoKoqzgFMiobw" ], "acl": [ { "acl-name": "sample-ipv4-acl", "acl-type": "ipv4-acl", "aces": { "ace": [ { "rule-name": "rule1", "matches": { "ipv4-acl": { "source-ipv4-network": "192.0.2.0/24", "destination-ipv4-network": "198.51.100.0/24" } }, "actions": { "forwarding" : "drop" } } ] } } ] } } Figure 8: POST to install filtering rules With a fair amount of permit = allow, deny = drop (or should it be reject - I do not think so) and augment updates through the document. Regards Jon ------=_NextPart_000_014C_01D35FCC.98AA2190 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi = there,

 

draft-ietf-netmod-acl-model-14 has another significant = change which affects DOTS.

 

 

draft-ietf-netmod-acl-model-13 has the following for = ACL actions

 

   +--rw = actions           =              =

   |  +--rw = (packet-handling)?         &= nbsp;       

   |  |  = +--:(deny)          &nb= sp;  

   |  |  |  +--rw = deny?      = empty           &n= bsp;          =

   |  |  = +--:(permit)          &= nbsp;       

   |  |     = +--rw permit?    = empty           &n= bsp;          =

   |  +--rw = logging?   Boolean

 

draft-ietf-netmod-acl-model-14 has updated it with = this

 

   +--rw actions

   |       = {acl-aggregate-stats or interface-acl-aggregate }?

   |  +--rw = forwarding    identityref  

   |  +--rw = logging?      identityref   =

   |  +--rw = icmp-off?     Boolean

 

With = different definitions for forwarding.

 

So, I reckon = that Figure 8 should look like

 

  POST = /restconf/data/ietf-dots-access-control-list HTTP/1.1

  Host: www.example.com

  Content-Format: = "application/yang.api+json"

  {

   = "ietf-dots-access-control-list:access-lists": = {

      = "client-identifier": [

       = "dz6pHjaADkaFTbjr0JGBpw",

       = "iAYmCNPmrYoKoqzgFMiobw"

      ],

      "acl": = [

      =     {

         &= nbsp;     "acl-name": = "sample-ipv4-acl",

         &= nbsp;     "acl-type": = "ipv4-acl",

         &= nbsp;     "aces": {

         &= nbsp;         "ace": = [

         &= nbsp;           &n= bsp; {

         &= nbsp;           &n= bsp;     "rule-name": = "rule1",

         &= nbsp;           &n= bsp;     "matches": {

         &= nbsp;           &n= bsp;       "ipv4-acl": = {

         &= nbsp;           &n= bsp;         = "source-ipv4-network": = "192.0.2.0/24",

         &= nbsp;           &n= bsp;         = "destination-ipv4-network": = "198.51.100.0/24"

         &= nbsp;           &n= bsp;       }

         &= nbsp;           &n= bsp;      },

         &= nbsp;           &n= bsp;      "actions": = {

         &= nbsp;           &n= bsp;          "forwarding" : = "drop"

         &= nbsp;           &n= bsp;      }

         &= nbsp;           &n= bsp;  }

         &= nbsp;          = ]

         &= nbsp;     }

          = }

      = ]

   }

  }

 

         &= nbsp;       Figure 8: POST to install = filtering rules

 

With a fair = amount of permit =3D allow, deny =3D drop (or should it be reject = – I do not think so) and augment updates through the = document.

 

Regards

 

Jon

------=_NextPart_000_014C_01D35FCC.98AA2190-- From nobody Tue Nov 21 22:26:34 2017 Return-Path: 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 6759112EB7B for ; Tue, 21 Nov 2017 22:26:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.999 X-Spam-Level: X-Spam-Status: No, score=-6.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 arzoSQLQ3kbc for ; Tue, 21 Nov 2017 22:26:29 -0800 (PST) Received: from MIVWSMAILOUT1.mcafee.com (mivwsmailout1.mcafee.com [161.69.47.167]) (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 E47D4127241 for ; Tue, 21 Nov 2017 22:26:28 -0800 (PST) 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=1511331987; 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: authentication-results:x-originating-ip:x-ms-publictraffictype: x-microsoft-exchange-diagnostics:x-ms-exchange-antispam-srfa-diagnostics: x-ms-office365-filtering-correlation-id:x-microsoft-antispam: x-ms-traffictypediagnostic:x-microsoft-antispam-prvs: x-exchange-antispam-report-test:x-exchange-antispam-report-cfa-test: x-forefront-prvs:x-forefront-antispam-report: received-spf:spamdiagnosticoutput:spamdiagnosticmetadata: Content-Type: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-Transport-CrossTenantHeadersStamped: X-OriginatorOrg:X-NAI-Spam-Flag:X-NAI-Spam-Level: X-NAI-Spam-Threshold:X-NAI-Spam-Score:X-NAI-Spam-Version; bh=FRLKyeLu97SayR3wGx8Yan4VRq/xgAnrWUHP/R okqqs=; b=i2DkjLFBWoJYDOId/vstB5LQsCNTsS3+LKutj3X+ G2E5vQaE7CiKi8seb7XzENPGe2bh2Upqn+H5j6IAg2SrD8CqnY QUcy903tMBB4tODLssKlssWflPWcbT4b4Uym8mn+YjUHgMAB5E 9x2IbMuuXXTXQoDNkhlayRLVB9kyhg4= Received: from MIVEXAPP1N01.corpzone.internalzone.com (unknown [10.48.48.88]) by MIVWSMAILOUT1.mcafee.com with smtp id 529c_1823_7cc77413_8fe2_4fe1_af75_8fa11f9c320f; Wed, 22 Nov 2017 00:26:27 -0600 Received: from MIVEXUSR1N04.corpzone.internalzone.com (10.48.48.84) by MIVEXAPP1N01.corpzone.internalzone.com (10.48.48.88) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Wed, 22 Nov 2017 01:26:18 -0500 Received: from MIVEXUSR1N01.corpzone.internalzone.com (10.48.48.81) by MIVEXUSR1N04.corpzone.internalzone.com (10.48.48.84) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Wed, 22 Nov 2017 01:26:17 -0500 Received: from MIVO365EDGE4.corpzone.internalzone.com (10.48.176.87) by MIVEXUSR1N01.corpzone.internalzone.com (10.48.48.81) with Microsoft SMTP Server (TLS) id 15.0.1347.2 via Frontend Transport; Wed, 22 Nov 2017 01:26:16 -0500 Received: from NAM03-BY2-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.1347.2; Wed, 22 Nov 2017 01:26:15 -0500 Received: from DM5PR16MB1788.namprd16.prod.outlook.com (10.172.44.144) by DM5PR16MB1786.namprd16.prod.outlook.com (10.172.44.142) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.239.5; Wed, 22 Nov 2017 06:26:15 +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.20.0239.009; Wed, 22 Nov 2017 06:26:15 +0000 From: "Konda, Tirumaleswar Reddy" To: Jon Shallow , "dots@ietf.org" Thread-Topic: [Dots] Data Channel ACL Actions Thread-Index: AdNfzJPvzFwhg6Z7ReePjrKxtiw2xAC5c5bw Date: Wed, 22 Nov 2017 06:26:15 +0000 Message-ID: References: <014b01d35fcc$98a8e910$c9fabb30$@jpshallow.com> In-Reply-To: <014b01d35fcc$98a8e910$c9fabb30$@jpshallow.com> 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: [103.245.47.20] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DM5PR16MB1786; 6:x3MPJPTcwDAzaDiZRtCILOSEEMcbfBr+OWam3hDd4h4o48U7FUxZVXrvfKgfCjwDIKeeFDwXn1Aiv7K2c9Qf1bq8INwSJTML355B8NmsGGfaRoRHjXwJRALQa1QE4elG6uy5IfTLx2TypL9Et6DS5t6INFpNKUEf0TKJ0TJcKfIGl43xBJ0fJVpI9AxSzzlIwJSEImvcIiuW9ra+W6FCRPNFnp0PnBcbedupZ/vmzt3DIhcEEJKxSHBg0jGLUvieJXszFPxdwIuT+HyTDOwpjh16e9b1mzeMRDP9nTgJhJmO9u+EQ/v04usXndEmR9ibqTgpa9o1MiFuFgC3XiSP1McxIAXABUfqRH1wGMpXgEI=; 5:4gstukTAPj7/X0o6kTDg2mJGoBvy9AalacTAYvP3A0Fe3jeSoQdMI9iluGcHdtqjMmQW5p5WzEf4IimDOTaQUMm/39kXl7M+tfwcqDn3oyXNyYhC+S3hbd2kmd5t627UIvx8zaXnacH0rfNntOF3G95hzoOkH70qoVTCOr66QhE=; 24:GRbcefHb41Upmg/od/USYPm/J0SHtPXaKM7i6Q6ZPBruF10LtPRNDDVH3xpuYbmmN/ogED9l2fPN/iluef/1Zinn7otN+nSwDnMgw1o6/d0=; 7:mxcyJ/EZRrFNTMNasD9aDBABJ041hB3JqBJGFsabTm8Cl4aTNfHxbRg1JM+MZtv9CylU4jbBwTH1TEa+iWtsaB0TUhaiv4kDr9jKKolt567VQoqTondTP5IQBVpippp96Zx7vOgf7/bpjUw+/XaKEoirj/TxopoHmaTdxrBCNwIifJ09natCbHtYxYfH+NXJWNu6mOLgU5tYQndYQCQhkY5Y9yD6bsdcqT4MPQIvYu0kRl/b/tllRhWWo95OW1kB x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 2f971a57-dd5d-4c6d-859d-08d53171eef5 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(2017052603199); SRVR:DM5PR16MB1786; x-ms-traffictypediagnostic: DM5PR16MB1786: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(227612066756510)(21748063052155)(79290750141951); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(5005006)(8121501046)(100000703101)(100105400095)(10201501046)(3231022)(3002001)(93006095)(93001095)(6041248)(20161123560025)(20161123564025)(20161123555025)(20161123562025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123558100)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:DM5PR16MB1786; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:DM5PR16MB1786; x-forefront-prvs: 0499DAF22A x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(346002)(376002)(39860400002)(32952001)(199003)(189002)(102836003)(6116002)(575784001)(3846002)(53546010)(790700001)(72206003)(606006)(106356001)(105586002)(14454004)(6246003)(8936002)(9326002)(478600001)(53936002)(101416001)(68736007)(6306002)(54896002)(236005)(9686003)(6506006)(66066001)(97736004)(25786009)(6436002)(80792005)(77096006)(99286004)(3660700001)(2906002)(3280700002)(2900100001)(8676002)(74316002)(110136005)(33656002)(316002)(19609705001)(7736002)(7696004)(189998001)(2950100002)(81156014)(86362001)(5660300001)(2501003)(50986999)(229853002)(55016002)(54356999)(53386004)(76176999)(81166006)(85282002); DIR:OUT; SFP:1101; SCL:1; SRVR:DM5PR16MB1786; H:DM5PR16MB1788.namprd16.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX: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_DM5PR16MB17889596014DD08105A387E4EA200DM5PR16MB1788namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 2f971a57-dd5d-4c6d-859d-08d53171eef5 X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Nov 2017 06:26:15.1207 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4943e38c-6dd4-428c-886d-24932bc2d5de X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR16MB1786 X-OriginatorOrg: mcafee.com X-NAI-Spam-Flag: NO X-NAI-Spam-Level: X-NAI-Spam-Threshold: 15 X-NAI-Spam-Score: 0.1 X-NAI-Spam-Version: 2.3.0.9418 : core <6163> : inlines <6181> : streams <1770994> : uri <2538223> Archived-At: Subject: Re: [Dots] Data Channel ACL Actions 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Nov 2017 06:26:31 -0000 --_000_DM5PR16MB17889596014DD08105A387E4EA200DM5PR16MB1788namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Jon, I don't think the new actions container in draft-ietf-netmod-acl-model-14 c= an be augmented to add a new rate-limit action, I can augment to add a new = dots specific action container. The updated yang model looks as follows (it= will also order the ACLs created by a DOTS client): module: ietf-dots-access-control-list augment /ietf-acl:access-lists: +--rw client-identifier* binary augment /ietf-acl:access-lists/ietf-acl:acl/ietf-acl:aces: +--rw dots-actions +--rw (packet-handling)? +--:(deny) | +--rw deny? empty +--:(permit) | +--rw permit? empty +--:(rate-limit) +--rw rate-limit? decimal64 augment /ietf-acl:access-lists/ietf-acl:acl/ietf-acl:aces/ietf-acl:ace: +--rw fragments? empty augment /ietf-acl:access-lists: +--rw dots-acl-order +--rw acl-set* [set-name type] +--rw set-name -> /ietf-acl:access-lists/acl/acl-name +--rw type -> /ietf-acl:access-lists/acl/acl-type -Tiru From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Jon Shallow Sent: Friday, November 17, 2017 11:21 PM To: dots@ietf.org Subject: [Dots] Data Channel ACL Actions Hi there, draft-ietf-netmod-acl-model-14 has another significant change which affects= DOTS. draft-ietf-netmod-acl-model-13 has the following for ACL actions +--rw actions | +--rw (packet-handling)? | | +--:(deny) | | | +--rw deny? empty | | +--:(permit) | | +--rw permit? empty | +--rw logging? Boolean draft-ietf-netmod-acl-model-14 has updated it with this +--rw actions | {acl-aggregate-stats or interface-acl-aggregate }? | +--rw forwarding identityref | +--rw logging? identityref | +--rw icmp-off? Boolean With different definitions for forwarding. So, I reckon that Figure 8 should look like POST /restconf/data/ietf-dots-access-control-list HTTP/1.1 Host: www.example.com Content-Format: "application/yang.api+json" { "ietf-dots-access-control-list:access-lists": { "client-identifier": [ "dz6pHjaADkaFTbjr0JGBpw", "iAYmCNPmrYoKoqzgFMiobw" ], "acl": [ { "acl-name": "sample-ipv4-acl", "acl-type": "ipv4-acl", "aces": { "ace": [ { "rule-name": "rule1", "matches": { "ipv4-acl": { "source-ipv4-network": "192.0.2.0/24", "destination-ipv4-network": "198.51.100.0/24= " } }, "actions": { "forwarding" : "drop" } } ] } } ] } } Figure 8: POST to install filtering rules With a fair amount of permit =3D allow, deny =3D drop (or should it be reje= ct - I do not think so) and augment updates through the document. Regards Jon --_000_DM5PR16MB17889596014DD08105A387E4EA200DM5PR16MB1788namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Jon,

&nbs= p;

I donR= 17;t think the new actions container in draft-ietf-netmod-acl-model-14 can be augmented to add a new rate-limit = action, I can augment to add a new dots specific action container. The upda= ted yang model looks as follows (it will also order the ACLs created by a DOTS client):

&nbs= p;

module: ietf-dots-access-contro= l-list

  augment /ietf-acl:access= -lists:

    +--rw cl= ient-identifier*   binary

  augment /ietf-acl:access= -lists/ietf-acl:acl/ietf-acl:aces:

    +--rw do= ts-actions

      =  +--rw (packet-handling)?

     &= nbsp;    +--:(deny)

     &= nbsp;    |  +--rw deny?    &nbs= p;    empty

     &= nbsp;    +--:(permit)

     &= nbsp;    |  +--rw permit?    &n= bsp;  empty

     &= nbsp;    +--:(rate-limit)

     &= nbsp;       +--rw rate-limit?  = decimal64

  augment /ietf-acl:access= -lists/ietf-acl:acl/ietf-acl:aces/ietf-acl:ace:

    +--rw fr= agments?   empty

  augment /ietf-acl:access= -lists:

    +--rw do= ts-acl-order

     &= nbsp; +--rw acl-set* [set-name type]

     &= nbsp;    +--rw set-name    -> /ietf-ac= l:access-lists/acl/acl-name

     &= nbsp;    +--rw type       =  -> /ietf-acl:access-lists/acl/acl-type

&nbs= p;

&nbs= p;

-Tiru

 

From:<= /span> Dots [mailto:dots-bou= nces@ietf.org] On Behalf Of Jon Shallow
Sent: Friday, November 17, 2017 11:21 PM
To: dots@ietf.org
Subject: [Dots] Data Channel ACL Actions

 

Hi there,

 

draft-ietf-netmod-acl-model-14 = has another significant change which affects DOTS.

 

 

draft-ietf-netmod-acl-model-13 = has the following for ACL actions

 

   +--rw actions&= nbsp;           &nbs= p;          

   |  += --rw (packet-handling)?        &nbs= p;        

   |  |&nbs= p; +--:(deny)         &nbs= p;   

   |  |&nbs= p; |  +--rw deny?      empty  &= nbsp;           &nbs= p;      

   |  |&nbs= p; +--:(permit)         &n= bsp;        

   |  |&nbs= p;    +--rw permit?    empty  &= nbsp;           &nbs= p;      

   |  += --rw logging?   Boolean

 

draft-ietf-netmod-acl-model-14 = has updated it with this

 

   +--rw actions<= o:p>

   |   = ;    {acl-aggregate-stats or interface-acl-aggregate }?=

   |  +--rw = forwarding    identityref  

   |  += --rw logging?      identityref  

   |  += --rw icmp-off?     Boolean

 

With different definitions for = forwarding.

 

So, I reckon that Figure 8 shou= ld look like

 

  POST /restconf/data/ietf= -dots-access-control-list HTTP/1.1

  Host: www.exam= ple.com

  Content-Format: "appli= cation/yang.api+json"

  {

   "ietf-dots-ac= cess-control-list:access-lists": {

      = "client-identifier": [

     &= nbsp; "dz6pHjaADkaFTbjr0JGBpw",

     &= nbsp; "iAYmCNPmrYoKoqzgFMiobw"

      = ],

      = "acl": [

      =     {

     &= nbsp;         "acl-name":= "sample-ipv4-acl",

     &= nbsp;         "acl-type": "ipv4-acl",

     &nbs= p;         "aces": {=

     &nbs= p;             = "ace": [

     &= nbsp;           &nbs= p;     {

     &= nbsp;           &nbs= p;         "rule-name": &= quot;rule1",

     &= nbsp;           &nbs= p;         "matches": {

     &= nbsp;           &nbs= p;           "ipv4-a= cl": {

     &= nbsp;           &nbs= p;             = "source-ipv4-network": "192.0.2.0/24",

     &= nbsp;           &nbs= p;             = "destination-ipv4-network": "198.51.100.0/24"

     &= nbsp;           &nbs= p;           }=

     &= nbsp;           &nbs= p;          },

     &= nbsp;           &nbs= p;          "actions"= ;: {

     &= nbsp;           &nbs= p;            &= nbsp; "forwarding" : "drop"= ;

     &= nbsp;           &nbs= p;          }

     &= nbsp;           &nbs= p;      }

     &= nbsp;           &nbs= p;  ]

     &= nbsp;         }

     &= nbsp;    }

      = ]

   }

  }

 

     &= nbsp;           Figure 8:= POST to install filtering rules

 

With a fair amount of permit = =3D allow, deny =3D drop (or should it be reject – I do not think so)= and augment updates through the document.

 

Regards

 

Jon

--_000_DM5PR16MB17889596014DD08105A387E4EA200DM5PR16MB1788namp_-- From nobody Tue Nov 21 23:10:07 2017 Return-Path: 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 7EAEF12EB3B for ; Tue, 21 Nov 2017 23:10:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=thescout.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 RmJu6k8VxbFZ for ; Tue, 21 Nov 2017 23:10:00 -0800 (PST) Received: from mx0a-00196b01.pphosted.com (mx0b-00196b01.pphosted.com [67.231.157.166]) (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 DA7DF12895E for ; Tue, 21 Nov 2017 23:09:59 -0800 (PST) Received: from pps.filterd (m0096262.ppops.net [127.0.0.1]) by mx0b-00196b01.pphosted.com (8.16.0.21/8.16.0.21) with SMTP id vAM71rBU016568 for ; Wed, 22 Nov 2017 02:09:59 -0500 Received: from nam02-cy1-obe.outbound.protection.outlook.com (mail-cys01nam02lp0051.outbound.protection.outlook.com [207.46.163.51]) by mx0b-00196b01.pphosted.com with ESMTP id 2ecwmeryv7-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT) for ; Wed, 22 Nov 2017 02:09:58 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=thescout.onmicrosoft.com; s=selector1-arbor-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=Ka2IOCSgWjXmMDwRKq2eo0KP8YjNHvsp7oCi3W2Mn9E=; b=FZwwHOvO/oFNtcf6Q3lCiT8lIBO62fs3F3hF879FP/JPvRXwLQt/P2GUUpyIdPBYzWp0mqhmeocTY5NZAJR0mc8bFVmOrndCZ1SMIPaol9j1HI3r+nES0ZqwxqudRre0aqqY+x6os9iXqG5hjxFa+6c2mVpAceJodMrxOnjYPY8= Received: from [172.19.254.109] (184.82.227.16) by DM2PR0101MB1039.prod.exchangelabs.com (2a01:111:e400:3c19::28) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.239.5; Wed, 22 Nov 2017 07:09:56 +0000 From: "Roland Dobbins" To: "dots@ietf.org" Date: Wed, 22 Nov 2017 14:09:42 +0700 Message-ID: <07646644-9A1B-442C-8517-D358E8CBF374@arbor.net> In-Reply-To: References: <014b01d35fcc$98a8e910$c9fabb30$@jpshallow.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.7r5425) X-Originating-IP: [184.82.227.16] X-ClientProxiedBy: SG2PR06CA0101.apcprd06.prod.outlook.com (2603:1096:3:14::27) To DM2PR0101MB1039.prod.exchangelabs.com (2a01:111:e400:3c19::28) X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: d29f2918-ee63-4963-6a69-08d5317809c4 X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(5600022)(4604075)(2017052603258); SRVR:DM2PR0101MB1039; X-Microsoft-Exchange-Diagnostics: 1; DM2PR0101MB1039; 3:Kxyis9799KVjT+JUdQTf/HQ0JKu6B80l3QTJo8nGvSe2PdTBVtMElU+1SIv/WaE7Ke8dQTZQpa7IUMycjMPlY8ymoFuwa5am9/kVn+TalzpT22sdd5CPMvQzT9UAyDfhycZ0IxerdK3OFrdkaLRJwK6qgzU+QfmyJVflVggiJTxkx0R+RFaPOdhoB1TTpvPBxM3P4/tD4R5frEbw4H0/+6r4V5pgGbzTZhuQ5HeTUtIAHsTdaugOG+PDNdSObsWi; 25:k5Fl6QtpyqggPQg9VDsyeH1ayKs5fqmJaNd2Qko+zNUcDd5foU4XdMiFE4uSmOmYJAr8ZBgY/Jn/4GHohhVIPiNU0l/3ztBtjkHhgnQeEPrveiT9J+gqmh5R7pLRlg7m7g7+g4Xnz6psvBaF8Pat1tkPI4EO5kfukIEfB7ZIobbLtLpaNn4cVuxcTLHbVFyRdR8OJq/3r2QH3XG3OMiPm+Ey2OVBcZCLFmjqmp5izz6mc0r5cCtgsRikGk5ZcKeXSiI20+PkA08VQILVZP0c7UkK5TY9+1H04GjbmS7znK1S3wbyROz5xjJEZZ64FFJbZ4Ws2dWfZnnd7i1u59P/TQsxxIIfjycSIY41YsOIGb4=; 31:cRDSiykOwIMSfb5pW34lWZEbj6C2Vxv8cLWgQEZ3swS3rqPKx1LBgzNxfTjCARM1ncaxF4Dx/GiD40+kZeLqiJih5tbtO+IelPMi8HKbWR+O7GSs6I8SvNma689JNCnCdPyWDaUl/e4efxupQdyWNcdwYSz1R2SPImtVaFUO+WhHyroL+Py4DuHXH/SdHxmZHSsZKZHTqW27Azu0WgkeR/dWlGP7BD07qep70ykAH2o= X-MS-TrafficTypeDiagnostic: DM2PR0101MB1039: X-Microsoft-Exchange-Diagnostics: 1; DM2PR0101MB1039; 20:5dGryUMAtjdGM/qujW4b1t2hODIjAejgehRg7jgf3aB1WvNrbi6TEeg5cKy8SNX19s2QvzfFN5zujyi3eUiZUzs6lPP23zWrzai01ddDnwGbfWdtoiCBVYqCe+HCsrir9j2i8WCZmMwKq4XVJ932/bDQSqGlt0K5+a2tNbDdMmtScwYq0Y6EaG91pf3kRmWG4Ja+eUx+W2cejJDiyhOEoXWehj5etEw+ZtfIKg94CfZ0y1V8STvQgSjSw9GtRzZ+Gb2WadtW9v/2hy8kjOkIRklJ+96sLPsMJih+diWd2zJLfbQ/qwZJTVOKOBo45zWiNl8wlDywmwrqUgRp6ga52A==; 4:cZqfK1Kh4BcJMp6Gly7YvHaGZ1VdxTizyk/3mEUGcs0ajijALn13TIHtND7LG3D6CmBnJa9lH1LNNWCdzQq64ZK9pffl/liwh1Llg8g9Q+KMxYcfvLwiHkpeIH+/bpIqnG0UGfONkDnQO85Sy9h7NcSvQ6pGCdbNFWRJuK5Cil67sxs6Q/Hl3g1476DJtiSQUYfZf7sTkVaeSMjb5ZogGlK/K4GURAHDPShpPpuPruCviZ1MheyJjRQHwsLoJU1q6kAY9zi3+tcwRiEF4S7ziA== X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(8121501046)(5005006)(10201501046)(93006095)(93001095)(3002001)(3231022)(100000703101)(100105400095)(6041248)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123558100)(20161123562025)(20161123555025)(20161123560025)(20161123564025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:DM2PR0101MB1039; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:DM2PR0101MB1039; X-Forefront-PRVS: 0499DAF22A X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(6009001)(6049001)(346002)(376002)(189002)(199003)(24454002)(5640700003)(2906002)(2351001)(8936002)(229853002)(86362001)(189998001)(5660300001)(25786009)(53936002)(33656002)(81156014)(6916009)(5003940100001)(8676002)(36756003)(106356001)(105586002)(2950100002)(68736007)(6666003)(1730700003)(97736004)(2501003)(16586007)(16576012)(50466002)(77096006)(53546010)(16526018)(6486002)(316002)(50226002)(81166006)(76176999)(83716003)(101416001)(6116002)(478600001)(67846002)(7736002)(47776003)(82746002)(3846002)(66066001)(305945005)(50986999)(6246003); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR0101MB1039; H:[172.19.254.109]; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Received-SPF: None (protection.outlook.com: arbor.net does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; DM2PR0101MB1039; 23:xfbVquafGYS+FGMWmUXbAiflaem8g/UEtZRbn48?= =?us-ascii?Q?/+xiF5epBLoeiwiEk9bFe3JFCta8/UhNAvVpmXDSDSzlwE7PWV9o8HepMvZ6?= =?us-ascii?Q?pYITvynGUzJyZyw9t96nP2q63cd0us1/ucoF2MG4O/nUklEaAYGf0r004a8w?= =?us-ascii?Q?f1EdDdljiHaECacwSKZ3uAJGzCSq/cfY8ArZZloMEJ/6F5b09gzV6YXxae62?= =?us-ascii?Q?82p3iFnBibx1Fu7ZWznXG3IJqFP9AC5gZ6PTAeVzxyncfGZ8hnbQA12wNgYM?= =?us-ascii?Q?rVJXzVpzjXRpbvRqC95UUELOrWEN/oM4/+aMIPXPRe3dnVsB+PAtxrDeNjRW?= =?us-ascii?Q?X5Zw13jNn9VmhlqlrotFfeSG8SsLrrbANcca5nT5KtOMONIhk1Ubh9cllk80?= =?us-ascii?Q?Yr+cJCjiOETf61D8PgCkbaWonGPHngQKLlg+1UDNh0em4a2TD+C6uTbr67Wv?= =?us-ascii?Q?s5XpBK8sioL9sioeYeA7bjwtfQIGMU1nYdSE4uP/Hj5jiDNnDK212pDicOmg?= =?us-ascii?Q?MWV6s0RfcEeGJui8cNAYzqdKxdDCCR7BEbc7meHRro1UnIZclxPKt8JSl0FO?= =?us-ascii?Q?TLtzFp+56QnFyWxE6VpTcuLKOMCzrp4FR5wNPQywLeYxUbWZZE4/NF/fZCu4?= =?us-ascii?Q?RaDwkgtBt9u2plXNtVFeQQruXBhMX0BU+eaSalubkY+BWD8ZR/UUzeegOGBs?= =?us-ascii?Q?OfXeovvAFpTHjf8JdI44/LyE/IP0FqlysUoaCS2+EelmCdTrtAc69s9jmBA8?= =?us-ascii?Q?QTOd1+G4sLj4ScYiDgOIVHLHxOUgvy86iIgxOJ7HVqL5FnPL2PqvC77cOnRk?= =?us-ascii?Q?ou3C1CUHhggM+hHw8SKb351ep7RedufX/MMT/1EDH6peS2/+wYxTIL0GclJl?= =?us-ascii?Q?tii/CqwaCfwwSigEndddhIPjswJunXHRWV24yqbozveMSW3Dos0odTxyx57u?= =?us-ascii?Q?wySeJRcZ03cTONB9h9YEypxcZyZ3dWt95lhD3lCXfTWH7MhYfMe/DbTeLVHg?= =?us-ascii?Q?GOdBTQ5fHTeR//H+qPqzpabMT5lNOjO5CUAOiZY8Ejrd34ZqgnUeUzXCr4wS?= =?us-ascii?Q?dZjGLQr4+jjs3BT/RY1HQpgWZ9ySJG+jMoziMzACQHnKaMajQi3oNdi0RiXt?= =?us-ascii?Q?pB5LM/TPzDa2lMFLKIXI+5QHc6f8a/9oqeS4OWEAILXO6dwPLmKm5Kmx87JU?= =?us-ascii?Q?2+hPnhXy1m/qtjiuFUnD6i9Ho3XEbBQlFegvxxJcevars3tNzYdAPEyWc1Lr?= =?us-ascii?Q?VjXdP83iqlIuLtPv4SMGeyMcze57sYoi+0vHmAyO1TuDw8kOvNNA8Gken9UZ?= =?us-ascii?Q?4wA=3D=3D?= X-Microsoft-Exchange-Diagnostics: 1; DM2PR0101MB1039; 6:Zs9SHYGhiMCTgDndLTO7+5tLranBpv7lS75r1vz0Kr/CCV7hBEu4wjkH5XRBzkdjKh1Bm9ZRulXN7yOUmiIFm0ImV1vLKB4b7NnjvGlBc8wILYJzaHnJ9tIKe7HVN3O83Au7FWwTJ/2Tv6EETPVL8Qar/fu5FMb2RVIlNXU0if8WML32UogmhbFs5tGh2a6ZZRsz8j8mw5wYS3umCXuiVNP/g/HMyUPucgXF4589shraZc1F/ttKuE/0bbe8MJyC2SO962RaX0crWtMdEYinR3UGF01H+v7xJex8kZUQoP1KHgo1nb7Ea9bfigFQV2fRS6pZCk3qAaq/BjNWfnESR4qslTbE07/og2Lqm0qphvU=; 5:jYfCc+WAE4iWxcQDYcEY5BKzZf2RKj4ErmBa6tspV+6CevlqWZgGrVzZJAuDHXQWvHzuSmQyTeoE+k5hTX0XNeUpZIvTLx8UjM0ZYCS4zqCLDZZCJM/f7jqpp3yZUH31/9g8P9SaUuPRtrtduZscR/rS7rfakOx/39hccpAPXMM=; 24:VDpTstQRQIidoBOXAinuLoGmAsDLtJi8m20vQ+p5vg3jf+ZbhJAQHoJQF8w9BmJnOzjx8BSk9cqL32XCLWVc3qg5zDCN9kdCg/lKZy+XXGE=; 7:qC5K6HerzqKqfvjbiWDtSLj0KozScFcvI0OPcjh0Zf6JVmL8S15t2b1RdUTYYhvRSEawmHEQGYhDOUr/L4D8dQK3kkj+P9swwgUkP91e3BvzEphdrPlguPr7frFY6VBTrLJ0c8oRrNhfwUpTYrz3/sPLIIpxv64tYhOB0niuhgDXzFOppNuxbxXWA0hp6kIW+NHhEmAgypk4ONfQAjBVaQp6g31HJJ4PopA9qCopoJFzvaKnSVNPZVnLi59Dmuob SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: arbor.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 22 Nov 2017 07:09:56.4684 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: d29f2918-ee63-4963-6a69-08d5317809c4 X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 54f11205-d4aa-4809-bd36-0b542199c5b2 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR0101MB1039 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-11-22_02:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1709140000 definitions=main-1711220098 Archived-At: Subject: Re: [Dots] Data Channel ACL Actions 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Nov 2017 07:10:06 -0000 On 22 Nov 2017, at 13:26, Konda, Tirumaleswar Reddy wrote: > I don't think the new actions container in > draft-ietf-netmod-acl-model-14 can be augmented to add a new > rate-limit action, Out of curiosity, why do we seem intent on replicating flowspec functionality in DOTS? ----------------------------------- Roland Dobbins From nobody Tue Nov 21 23:22:03 2017 Return-Path: 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 49E07128B51 for ; Tue, 21 Nov 2017 23:22:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.32 X-Spam-Level: X-Spam-Status: No, score=-4.32 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 FG9qxaAIrwVL for ; Tue, 21 Nov 2017 23:21:54 -0800 (PST) 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 3F3FD1271DF for ; Tue, 21 Nov 2017 23:21:54 -0800 (PST) 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=1511335313; 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: authentication-results:x-originating-ip:x-ms-publictraffictype: x-microsoft-exchange-diagnostics:x-ms-exchange-antispam-srfa-diagnostics: x-ms-office365-filtering-correlation-id:x-microsoft-antispam: x-ms-traffictypediagnostic:x-microsoft-antispam-prvs: x-exchange-antispam-report-test:x-exchange-antispam-report-cfa-test: x-forefront-prvs:x-forefront-antispam-report: received-spf:spamdiagnosticoutput:spamdiagnosticmetadata: 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-Transport-CrossTenantHeadersStamped: X-OriginatorOrg:X-NAI-Spam-Flag:X-NAI-Spam-Level: X-NAI-Spam-Threshold:X-NAI-Spam-Score:X-NAI-Spam-Version; bh=q2wGxB5PCsrDgP6j3wvjWXcPjSQ71Knk8obQvA +4eoE=; b=BVb9aI941v+RLTAHSCwSHFsFX/haanOxGWdnHE8K aeaODm0QBzTrhFfH9o0sMIYwsgV1orPJDZXgi07qfvx24rEbaN QiZe5qvnPwnEePx6m/3uwUcFNnZlcIueOtlSZGYB5hCJUNGhU6 7d/W0hM5UHdHNP6Da6Y5WptvdS4J6As= Received: from DNVEXAPP1N06.corpzone.internalzone.com (unknown [10.44.48.90]) by DNVWSMAILOUT1.mcafee.com with smtp id 0408_ee6f_79e5b33f_b5f3_4bbe_966a_33dc58e21f87; Wed, 22 Nov 2017 01:21:53 -0600 Received: from DNVEXUSR1N10.corpzone.internalzone.com (10.44.48.83) by DNVEXAPP1N06.corpzone.internalzone.com (10.44.48.90) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Wed, 22 Nov 2017 00:21:49 -0700 Received: from DNVEXUSR1N08.corpzone.internalzone.com (10.44.48.81) by DNVEXUSR1N10.corpzone.internalzone.com (10.44.48.83) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Wed, 22 Nov 2017 00:21:49 -0700 Received: from DNVO365EDGE2.corpzone.internalzone.com (10.44.176.74) by DNVEXUSR1N08.corpzone.internalzone.com (10.44.48.81) with Microsoft SMTP Server (TLS) id 15.0.1347.2 via Frontend Transport; Wed, 22 Nov 2017 00:21:48 -0700 Received: from NAM01-SN1-obe.outbound.protection.outlook.com (10.44.176.243) by edge.mcafee.com (10.44.176.74) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Wed, 22 Nov 2017 00:21:48 -0700 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.20.239.5; Wed, 22 Nov 2017 07:21:47 +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.20.0239.009; Wed, 22 Nov 2017 07:21:47 +0000 From: "Konda, Tirumaleswar Reddy" To: Roland Dobbins , "dots@ietf.org" Thread-Topic: [Dots] Data Channel ACL Actions Thread-Index: AdNfzJPvzFwhg6Z7ReePjrKxtiw2xAC5c5bwACue+wAAABAcsA== Date: Wed, 22 Nov 2017 07:21:47 +0000 Message-ID: References: <014b01d35fcc$98a8e910$c9fabb30$@jpshallow.com> <07646644-9A1B-442C-8517-D358E8CBF374@arbor.net> In-Reply-To: <07646644-9A1B-442C-8517-D358E8CBF374@arbor.net> 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: [103.245.47.20] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DM5PR16MB1787; 6:t7JOyzRyUufo9kStJO12KgeWcmw4kfvpn04Cy+Rk3YZVMVBjmNUnj/TQWvrq2cRD1pXnswdfM9f8xHshadIZ1lnXPolCHwDsTFzh4UxaoGqytx5HX2bQ7OkJImmX+rXAAHunlpwn8US1xOSTZkkN0zQAnV9FaqEN5HpLXMPtKIzlJX6ejuqKfCWuODKeLs85MeGmVkyPY5rFhoM7y1Sm/t+hNBzHqho8ULvycvqZ6tLbxuUsvFjVAiDTgdy/jvm9/F0vlPDYPzpPxHgsS6Z1DByP/0nwLl4Zz6l1hYMBswlVTkC2o7vvNi2LPTKLj1YQcriHnt3q71Xv4YyILN96+tey+gJGlFkA1JgtGlnNEwY=; 5:FtNh3r2VnjUhI6oMZ68xi2OACzHz+VXQUWa89Bd2oAH8AQwus3d5Fa58cYVtQWm7k7SfP9i7rmyRXkGZ2UJ66ezL2vt1sxkt0IylRySLlZ3fBN7bVLbUfrjYyLW49j4Gifgnk9rY32pQswa/Vvcu3W+O0zoVUqFNkqlep5QMfJw=; 24:cOt1mCEbCHs3o7g/SZNBrRb4cK8pubnGeT3p16i/z+mjgRm7fHj2oSoxlwxGsqmAW0Ei+pJrmfDruQHZS8pavcmtu9kxd7C9xfwR5JM+30o=; 7:ku53o3rhljdBbJUeP58SbxM+UblhVTo0sEMgfededudtRwnRJT8IVIBr+0VHE4d/qN/r8Yvp4nu/Qg93ipAbPEpYLEQlFWztXb13ua6UpcEDdiENVw2zBgAIp0sOpzoxzC4t5gYmBZC9bhB1LkEyY5NNYRN9PAd5qKD8hdKOgkTRJhr688n0hbdTho02CIFkUITFZh0XgdAPGmbpRml42tdVF/MtAHLBsdmq3L3932dtzGGoSh7f+7VykMHf4Me+ x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: eb44ba87-24fb-459e-fbbb-08d53179b133 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(5600022)(4604075)(2017052603258); SRVR:DM5PR16MB1787; x-ms-traffictypediagnostic: DM5PR16MB1787: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(8121501046)(5005006)(3002001)(10201501046)(3231022)(93006095)(93001095)(100000703101)(100105400095)(6041248)(20161123562025)(20161123558100)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123564025)(20161123560025)(20161123555025)(6072148)(201708071742011)(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: 0499DAF22A x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(376002)(39860400002)(346002)(32952001)(199003)(13464003)(189002)(24454002)(55016002)(53936002)(66066001)(80792005)(7696004)(72206003)(8936002)(86362001)(99286004)(110136005)(6246003)(6506006)(7736002)(6436002)(305945005)(74316002)(77096006)(81156014)(6306002)(68736007)(9686003)(8676002)(81166006)(5660300001)(3846002)(102836003)(14454004)(316002)(54356999)(106356001)(105586002)(76176999)(2501003)(53546010)(3660700001)(97736004)(229853002)(50986999)(6116002)(2900100001)(966005)(3280700002)(189998001)(101416001)(478600001)(2906002)(25786009)(2950100002)(33656002)(85282002); DIR:OUT; SFP:1101; SCL:1; SRVR:DM5PR16MB1787; H:DM5PR16MB1788.namprd16.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: McAfee.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: eb44ba87-24fb-459e-fbbb-08d53179b133 X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Nov 2017 07:21:47.5321 (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-Level: X-NAI-Spam-Threshold: 15 X-NAI-Spam-Score: 0.1 X-NAI-Spam-Version: 2.3.0.9418 : core <6163> : inlines <6181> : streams <1770997> : uri <2538244> Archived-At: Subject: Re: [Dots] Data Channel ACL Actions 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Nov 2017 07:22:02 -0000 > -----Original Message----- > From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Roland Dobbins > Sent: Wednesday, November 22, 2017 12:40 PM > To: dots@ietf.org > Subject: Re: [Dots] Data Channel ACL Actions >=20 > On 22 Nov 2017, at 13:26, Konda, Tirumaleswar Reddy wrote: >=20 > > I don't think the new actions container in > > draft-ietf-netmod-acl-model-14 can be augmented to add a new > > rate-limit action, >=20 > Out of curiosity, why do we seem intent on replicating flowspec functiona= lity > in DOTS? The intent is not to replicate flowspec functionality, rate-limiting is dis= cussed in both the architecture and requirements drafts, and=20 the WG wanted the rate-limit action in addition to permit and deny actions. -Tiru >=20 > ----------------------------------- > Roland Dobbins >=20 > _______________________________________________ > Dots mailing list > Dots@ietf.org > https://www.ietf.org/mailman/listinfo/dots From nobody Wed Nov 22 07:59:41 2017 Return-Path: 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 0BF5D129466 for ; Wed, 22 Nov 2017 07:59:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 UfcyvhafnBgr for ; Wed, 22 Nov 2017 07:59:38 -0800 (PST) Received: from mail.jpshallow.com (mail.jpshallow.com [217.40.240.153]) (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 38D7A12940E for ; Wed, 22 Nov 2017 07:59:38 -0800 (PST) Received: from [127.0.0.1] (helo=N01332) by mail.jpshallow.com with smtps (TLSv1:ECDHE-RSA-AES256-SHA:256) (Exim 4.89) (envelope-from ) id 1eHXR1-0001fR-2x; Wed, 22 Nov 2017 15:59:35 +0000 From: "Jon Shallow" To: "'Konda, Tirumaleswar Reddy'" , References: <014b01d35fcc$98a8e910$c9fabb30$@jpshallow.com> In-Reply-To: Date: Wed, 22 Nov 2017 15:59:35 -0000 Message-ID: <012a01d363aa$e4cd0d30$ae672790$@jpshallow.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_012B_01D363AA.E4CF7E30" X-Mailer: Microsoft Outlook 14.0 Content-Language: en-gb Thread-Index: AQLEJeTZWxLmPjSU34IiB1W15cI71AIHigZtoS65RjA= Archived-At: Subject: Re: [Dots] Data Channel ACL Actions 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Nov 2017 15:59:40 -0000 This is a multipart message in MIME format. ------=_NextPart_000_012B_01D363AA.E4CF7E30 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Tiru, I agree that the new actions container with forwarding identityref is not workable for adding in rate-limiting. Forwarding is a mandatory field, so another possibility is that you augment actions (the level above) with rate-limiting. This then gives the possibility of allow with a rate-limit or drop with a rate-limit - a bit messy though. I think augment /ietf-acl:access-lists/ietf-acl:acl/ietf-acl:aces/ietf-acl:ace: +--rw fragments? empty Should (at a minimum) read (as netmod-14 has added in another layer) augment /ietf-acl:access-lists/ietf-acl:acl/ietf-acl:aces/ietf-acl:ace/ietf-acl:ipv4 -acl: +--rw fragments? empty augment /ietf-acl:access-lists/ietf-acl:acl/ietf-acl:aces/ietf-acl:ace/ietf-acl:ipv6 -acl: +--rw fragments? empty In Figure 8, you have (ignoring the fact that "actions" should now be "dots-actions" if your change is accepted) "deny": [null] Which is an empty array. I think it should be "deny": null Regards Jon From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of Konda, Tirumaleswar Reddy Sent: 22 November 2017 06:26 To: Jon Shallow; dots@ietf.org Subject: Re: [Dots] Data Channel ACL Actions Hi Jon, I don't think the new actions container in draft-ietf-netmod-acl-model-14 can be augmented to add a new rate-limit action, I can augment to add a new dots specific action container. The updated yang model looks as follows (it will also order the ACLs created by a DOTS client): module: ietf-dots-access-control-list augment /ietf-acl:access-lists: +--rw client-identifier* binary augment /ietf-acl:access-lists/ietf-acl:acl/ietf-acl:aces: +--rw dots-actions +--rw (packet-handling)? +--:(deny) | +--rw deny? empty +--:(permit) | +--rw permit? empty +--:(rate-limit) +--rw rate-limit? decimal64 augment /ietf-acl:access-lists/ietf-acl:acl/ietf-acl:aces/ietf-acl:ace: +--rw fragments? empty augment /ietf-acl:access-lists: +--rw dots-acl-order +--rw acl-set* [set-name type] +--rw set-name -> /ietf-acl:access-lists/acl/acl-name +--rw type -> /ietf-acl:access-lists/acl/acl-type -Tiru From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Jon Shallow Sent: Friday, November 17, 2017 11:21 PM To: dots@ietf.org Subject: [Dots] Data Channel ACL Actions Hi there, draft-ietf-netmod-acl-model-14 has another significant change which affects DOTS. draft-ietf-netmod-acl-model-13 has the following for ACL actions +--rw actions | +--rw (packet-handling)? | | +--:(deny) | | | +--rw deny? empty | | +--:(permit) | | +--rw permit? empty | +--rw logging? Boolean draft-ietf-netmod-acl-model-14 has updated it with this +--rw actions | {acl-aggregate-stats or interface-acl-aggregate }? | +--rw forwarding identityref | +--rw logging? identityref | +--rw icmp-off? Boolean With different definitions for forwarding. So, I reckon that Figure 8 should look like POST /restconf/data/ietf-dots-access-control-list HTTP/1.1 Host: www.example.com Content-Format: "application/yang.api+json" { "ietf-dots-access-control-list:access-lists": { "client-identifier": [ "dz6pHjaADkaFTbjr0JGBpw", "iAYmCNPmrYoKoqzgFMiobw" ], "acl": [ { "acl-name": "sample-ipv4-acl", "acl-type": "ipv4-acl", "aces": { "ace": [ { "rule-name": "rule1", "matches": { "ipv4-acl": { "source-ipv4-network": "192.0.2.0/24", "destination-ipv4-network": "198.51.100.0/24" } }, "actions": { "forwarding" : "drop" } } ] } } ] } } Figure 8: POST to install filtering rules With a fair amount of permit = allow, deny = drop (or should it be reject - I do not think so) and augment updates through the document. Regards Jon ------=_NextPart_000_012B_01D363AA.E4CF7E30 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Tiru,

 

I agree that the new = actions container with forwarding identityref is not workable for adding = in rate-limiting.  Forwarding is a mandatory field, so another = possibility is that you augment actions (the level above) with = rate-limiting.  This then gives the possibility of allow with a = rate-limit or drop with a rate-limit – a bit messy = though.

 

I = think

 

  augment = /ietf-acl:access-lists/ietf-acl:acl/ietf-acl:aces/ietf-acl:ace:

    +--rw = fragments?   empty

 

Should (at a minimum) = read (as netmod-14 has added in another layer)

 

  augment = /ietf-acl:access-lists/ietf-acl:acl/ietf-acl:aces/ietf-acl:ace/ietf-acl:i= pv4-acl:

    +--rw = fragments?   empty

  augment = /ietf-acl:access-lists/ietf-acl:acl/ietf-acl:aces/ietf-acl:ace/ietf-acl:i= pv6-acl:

    +--rw = fragments?   empty

 

In Figure 8, you have = (ignoring the fact that “actions” should now be = “dots-actions” if your change is = accepted)

“deny”: [null]

Which is an empty = array.  I think it should be

“deny”: null

 

Regards

 

Jon

 

From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of = Konda, Tirumaleswar Reddy
Sent: 22 November 2017 = 06:26
To: Jon Shallow; dots@ietf.org
Subject: Re: = [Dots] Data Channel ACL Actions

 

Hi = Jon,

 

I don’t think the new actions = container in draft-ietf-netmod-acl-model-14 can be augmented to add a new = rate-limit action, I can augment to add a new dots specific action = container. The updated yang model looks as follows (it will also order = the ACLs created by a DOTS client):

 

module: = ietf-dots-access-control-list

  augment = /ietf-acl:access-lists:

    +--rw = client-identifier*   binary

  augment = /ietf-acl:access-lists/ietf-acl:acl/ietf-acl:aces:

<= p class=3DMsoNormal>    +--rw = dots-actions

     =   +--rw (packet-handling)?

      &nbs= p;   +--:(deny)

      &nbs= p;   |  +--rw = deny?         = empty

      &nbs= p;   +--:(permit)

      &nbs= p;   |  +--rw permit?       = empty

      &nbs= p;   +--:(rate-limit)

      &nbs= p;      +--rw rate-limit?   = decimal64

  augment = /ietf-acl:access-lists/ietf-acl:acl/ietf-acl:aces/ietf-acl:ace:

    +--rw = fragments?   empty

  augment = /ietf-acl:access-lists:

    +--rw = dots-acl-order

       = +--rw acl-set* [set-name type]

      &nbs= p;   +--rw set-name    -> = /ietf-acl:access-lists/acl/acl-name

      &nbs= p;   +--rw type      =   -> = /ietf-acl:access-lists/acl/acl-type

 

 

-Tiru

 

From: Dots [mailto:dots-bounces@ietf.org] = On Behalf Of Jon Shallow
Sent: Friday, November 17, = 2017 11:21 PM
To: dots@ietf.org
Subject: = [Dots] Data Channel ACL Actions

 

Hi there,

 

draft-ietf-netmod-acl-model-14 has another significant = change which affects DOTS.

 

 

draft-ietf-netmod-acl-model-13 has the following for = ACL actions

 

   +--rw = actions           =              =

   |  +--rw = (packet-handling)?         &= nbsp;       

   |  |  = +--:(deny)          &nb= sp;  

   |  |  |  +--rw = deny?      = empty           &n= bsp;          =

   |  |  = +--:(permit)          &= nbsp;       

   |  |     = +--rw permit?    = empty           &n= bsp;          =

   |  +--rw = logging?   Boolean

 

draft-ietf-netmod-acl-model-14 has updated it with = this

 

   +--rw actions

   |       = {acl-aggregate-stats or interface-acl-aggregate }?

   |  +--rw = forwarding    identityref  

   |  +--rw = logging?      identityref   =

   |  +--rw = icmp-off?     Boolean

 

With = different definitions for forwarding.

 

So, I reckon = that Figure 8 should look like

 

  POST = /restconf/data/ietf-dots-access-control-list HTTP/1.1

  Host: www.example.com

  Content-Format: = "application/yang.api+json"

  {

   = "ietf-dots-access-control-list:access-lists": = {

      = "client-identifier": [

       = "dz6pHjaADkaFTbjr0JGBpw",

       = "iAYmCNPmrYoKoqzgFMiobw"

      ],

      "acl": = [

      =     {

         &= nbsp;     "acl-name": = "sample-ipv4-acl",

         &= nbsp;     "acl-type": = "ipv4-acl",

          &nb= sp;    "aces": {

          &nb= sp;        "ace": = [

         &= nbsp;           &n= bsp; {

         &= nbsp;           &n= bsp;     "rule-name": = "rule1",

         &= nbsp;           &n= bsp;     "matches": {

         &= nbsp;           &n= bsp;       "ipv4-acl": = {

         &= nbsp;           &n= bsp;         = "source-ipv4-network": = "192.0.2.0/24",

         &= nbsp;           &n= bsp;         = "destination-ipv4-network": = "198.51.100.0/24"

         &= nbsp;           &n= bsp;       }

         &= nbsp;           &n= bsp;      },

         &= nbsp;           &n= bsp;      "actions": = {

         &= nbsp;           &n= bsp;          "forwarding" : = "drop"

         &= nbsp;           &n= bsp;      }

         &= nbsp;           &n= bsp;  }

         &= nbsp;          = ]

         &= nbsp;     }

          = }

      = ]

   }

  }

 

         &= nbsp;       Figure 8: POST to install = filtering rules

 

With a fair = amount of permit =3D allow, deny =3D drop (or should it be reject = – I do not think so) and augment updates through the = document.

 

Regards

 

Jon

------=_NextPart_000_012B_01D363AA.E4CF7E30-- From nobody Thu Nov 23 00:25:09 2017 Return-Path: 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 B56A1127978 for ; Thu, 23 Nov 2017 00:25:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7 X-Spam-Level: X-Spam-Status: No, score=-7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham 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 Aho-ElN70Zko for ; Thu, 23 Nov 2017 00:25:05 -0800 (PST) Received: from MIVWSMAILOUT1.mcafee.com (mivwsmailout1.mcafee.com [161.69.47.167]) (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 0DD2B12778E for ; Thu, 23 Nov 2017 00:25:03 -0800 (PST) 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=1511425489; 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: authentication-results:x-originating-ip:x-ms-publictraffictype: x-microsoft-exchange-diagnostics:x-ms-exchange-antispam-srfa-diagnostics: x-ms-office365-filtering-correlation-id:x-microsoft-antispam: x-ms-traffictypediagnostic:x-microsoft-antispam-prvs: x-exchange-antispam-report-test:x-exchange-antispam-report-cfa-test: x-forefront-prvs:x-forefront-antispam-report: received-spf:spamdiagnosticoutput:spamdiagnosticmetadata: Content-Type: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-Transport-CrossTenantHeadersStamped: X-OriginatorOrg:X-NAI-Spam-Flag:X-NAI-Spam-Level: X-NAI-Spam-Threshold:X-NAI-Spam-Score:X-NAI-Spam-Version; bh=//v22WxYiVj67LCUYtecNiXRr4kFgf1kGhJclr ciUuk=; b=UJFjTonBVwopCujjMofbF81iC7lf8knW+DaKbpYq zA1tE/jq9LZoSwQlLUzyDQdULwSWa0NzANawAPSFJOle4sBm7Z CQ2FlFm/8q+H9RekVDKtnNZLzMjzKUGIHjBOyro1v3L/0ESQcQ hVdJk8BmZNrYBw3hT7mQ7XKf5rN+aKQ= Received: from MIVEXAPP1N03.corpzone.internalzone.com (unknown [10.48.48.90]) by MIVWSMAILOUT1.mcafee.com with smtp id 46e6_cca0_953b5bd9_130a_4f02_9e07_85dd3963e450; Thu, 23 Nov 2017 02:24:48 -0600 Received: from MIVEXUSR1N02.corpzone.internalzone.com (10.48.48.82) by MIVEXAPP1N03.corpzone.internalzone.com (10.48.48.90) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Thu, 23 Nov 2017 03:24:47 -0500 Received: from MIVO365EDGE3.corpzone.internalzone.com (10.48.176.86) by MIVEXUSR1N02.corpzone.internalzone.com (10.48.48.82) with Microsoft SMTP Server (TLS) id 15.0.1347.2 via Frontend Transport; Thu, 23 Nov 2017 03:24:47 -0500 Received: from NAM02-CY1-obe.outbound.protection.outlook.com (10.48.176.241) by edge.mcafee.com (10.48.176.86) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Thu, 23 Nov 2017 03:24:46 -0500 Received: from DM5PR16MB1788.namprd16.prod.outlook.com (10.172.44.144) by DM5PR16MB1786.namprd16.prod.outlook.com (10.172.44.142) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.239.5; Thu, 23 Nov 2017 08:24:45 +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.20.0239.009; Thu, 23 Nov 2017 08:24:44 +0000 From: "Konda, Tirumaleswar Reddy" To: Jon Shallow , "dots@ietf.org" Thread-Topic: [Dots] Data Channel ACL Actions Thread-Index: AdNfzJPvzFwhg6Z7ReePjrKxtiw2xAC5c5bwAD4ggoAAHQYYwA== Date: Thu, 23 Nov 2017 08:24:44 +0000 Message-ID: References: <014b01d35fcc$98a8e910$c9fabb30$@jpshallow.com> <012a01d363aa$e4cd0d30$ae672790$@jpshallow.com> In-Reply-To: <012a01d363aa$e4cd0d30$ae672790$@jpshallow.com> 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: [103.245.47.20] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DM5PR16MB1786; 6:IDk/XDUwptf5HsklRzSmONNGhBv0mH56whPCSd23QWlsZvrhkf5HpbNyAtOipjwWbWjJ8Ed/GUUL2OaUOIJYlqqqwgPQfhqxq0SihXDmrmAKs74yblfW7ruSRm+3UL2aFRaMDpB622fz53CCHNbGphT/JDYzKY7q7atNY4s6z5VtNQJH2mrWwsLeboJLfCaxLx2N0Kjaxqe1xi9k4uTEUy7ds8Yu+EMlWLxaRHnuotOTtL59gCv4UgQu5raXCHrRHO5hp11UD8ALr7xJfMbm6Uq2sjXr5ztDIu+Ovjcbla/pXME3NdIBJmrIikEFHj9lPHB63FejakwtP7678sEmEaRlOALrnMHHq1/1DcKy+HQ=; 5:Xgr6Oqo2tfy8RncvudoDeQuOzn0d0MXXy0yyhAc8KH9Yim2vqAQsCOXW1XUmUZf640fh89TAY1c2aQicgH4X45NzI2Oq3hhCPLo9FsUm7a49ITKrP1GMc+A1MNSzwH9d/3GTXfD0mFj8LMX9aoQiMQai/TcU44TQAgL6DVzXzII=; 24:19mzqHJOtLS8Mx7HMW0Ug8+gnd2SVtZ0qhApb+EVQ+FUxqxPwfHMjoo9IjeRtp0U6DCLPVY3jN0MQF+1qC9ykDJw8Qe3TblzPDWNwVWIhLc=; 7:VxUWm66e7kR9+jpSEJ79stGb/NKe06VSWyX3haoY45KZ5eTmcEXiaEkI7Mt0t42zCp7YA5ybrvEnxXhn3Ua40LslvMDKJRm+CgeCw7iPVcA5suJccngurgDi+cyym9slLzeMuV5zRWAgNguhUu/3pxzz1RlAP0RXX/sI6pzTmMQy+nZcWmOIsa2bf5NQmXjeq03YrhKfe04gPtBxno+2UyVuWrNRNufbYUU8uNYZfuO95iOrAHqCkn9w7lUstNKT x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 8555f90c-1926-4363-4e9d-08d5324ba706 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(2017052603199); SRVR:DM5PR16MB1786; x-ms-traffictypediagnostic: DM5PR16MB1786: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(166708455590820)(227612066756510)(21748063052155)(79290750141951)(123452027830198); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(8121501046)(5005006)(93006095)(93001095)(3231022)(3002001)(10201501046)(100000703101)(100105400095)(6041248)(20161123562025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123558100)(20161123555025)(20161123560025)(20161123564025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:DM5PR16MB1786; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:DM5PR16MB1786; x-forefront-prvs: 05009853EF x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(346002)(376002)(39860400002)(366004)(32952001)(199003)(189002)(6506006)(66066001)(575784001)(72206003)(606006)(8936002)(102836003)(106356001)(966005)(105586002)(14454004)(6246003)(478600001)(53546010)(53936002)(9326002)(101416001)(68736007)(54896002)(9686003)(6306002)(236005)(790700001)(6116002)(97736004)(25786009)(6436002)(3846002)(189998001)(80792005)(77096006)(3660700001)(2906002)(3280700002)(99286004)(33656002)(110136005)(7696004)(86362001)(5660300001)(7736002)(19609705001)(316002)(2900100001)(2950100002)(81156014)(2501003)(55016002)(50986999)(81166006)(229853002)(53386004)(74316002)(54356999)(76176999)(8676002)(85282002); DIR:OUT; SFP:1101; SCL:1; SRVR:DM5PR16MB1786; H:DM5PR16MB1788.namprd16.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX: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_DM5PR16MB1788918EE6AF7E3D13119201EA210DM5PR16MB1788namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 8555f90c-1926-4363-4e9d-08d5324ba706 X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Nov 2017 08:24:44.7375 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4943e38c-6dd4-428c-886d-24932bc2d5de X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR16MB1786 X-OriginatorOrg: mcafee.com X-NAI-Spam-Flag: NO X-NAI-Spam-Level: X-NAI-Spam-Threshold: 15 X-NAI-Spam-Score: 0.1 X-NAI-Spam-Version: 2.3.0.9418 : core <6164> : inlines <6183> : streams <1771085> : uri <2538653> Archived-At: Subject: Re: [Dots] Data Channel ACL Actions 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Nov 2017 08:25:08 -0000 --_000_DM5PR16MB1788918EE6AF7E3D13119201EA210DM5PR16MB1788namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Jon, Good point, rate-limit makes sense only with allow action (I have the updat= ed the yang model to use "when-stmt" to make rate-limit leaf node valid onl= y when "accept" action is used) augment "/ietf-acl:access-lists/ietf-acl:acl/ietf-acl:aces" + "/ietf-acl:ace/ietf-acl:actions" { description "rate-limit action"; leaf rate-limit { when "/ietf-acl:access-lists/ietf-acl:acl/ietf-acl:aces/ietf-acl= :ace" + "/ietf-acl:actions/ietf-acl:forwarding !=3D 'accept'" { description "rate-limit valid only when accept action is used= "; } type decimal64 { fraction-digits 2; } description "rate-limit traffic"; } } Also updated draft to address your other comment related to fragments augment /ietf-acl:access-lists/ietf-acl:acl/ietf-acl:aces/ietf-acl:ace/ie= tf-acl:matches/ietf-acl:ipv4-acl: +--rw fragments? empty augment /ietf-acl:access-lists/ietf-acl:acl/ietf-acl:aces/ietf-acl:ace/ie= tf-acl:matches/ietf-acl:ipv6-acl: +--rw fragments? empty The updated draft is uploaded to https://github.com/dotswg/dots-data-channe= l/blob/master/draft-ietf-dots-data-channel-08.txt Cheers, -Tiru From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Jon Shallow Sent: Wednesday, November 22, 2017 9:30 PM To: Konda, Tirumaleswar Reddy ; dots@ie= tf.org Subject: Re: [Dots] Data Channel ACL Actions Hi Tiru, I agree that the new actions container with forwarding identityref is not w= orkable for adding in rate-limiting. Forwarding is a mandatory field, so a= nother possibility is that you augment actions (the level above) with rate-= limiting. This then gives the possibility of allow with a rate-limit or dr= op with a rate-limit - a bit messy though. I think augment /ietf-acl:access-lists/ietf-acl:acl/ietf-acl:aces/ietf-acl:ace: +--rw fragments? empty Should (at a minimum) read (as netmod-14 has added in another layer) augment /ietf-acl:access-lists/ietf-acl:acl/ietf-acl:aces/ietf-acl:ace/ie= tf-acl:ipv4-acl: +--rw fragments? empty augment /ietf-acl:access-lists/ietf-acl:acl/ietf-acl:aces/ietf-acl:ace/ie= tf-acl:ipv6-acl: +--rw fragments? empty In Figure 8, you have (ignoring the fact that "actions" should now be "dots= -actions" if your change is accepted) "deny": [null] Which is an empty array. I think it should be "deny": null Regards Jon From: Dots [mailto: dots-bounces@ietf.org] On= Behalf Of Konda, Tirumaleswar Reddy Sent: 22 November 2017 06:26 To: Jon Shallow; dots@ietf.org Subject: Re: [Dots] Data Channel ACL Actions Hi Jon, I don't think the new actions container in draft-ietf-netmod-acl-model-14 c= an be augmented to add a new rate-limit action, I can augment to add a new = dots specific action container. The updated yang model looks as follows (it= will also order the ACLs created by a DOTS client): module: ietf-dots-access-control-list augment /ietf-acl:access-lists: +--rw client-identifier* binary augment /ietf-acl:access-lists/ietf-acl:acl/ietf-acl:aces: +--rw dots-actions +--rw (packet-handling)? +--:(deny) | +--rw deny? empty +--:(permit) | +--rw permit? empty +--:(rate-limit) +--rw rate-limit? decimal64 augment /ietf-acl:access-lists/ietf-acl:acl/ietf-acl:aces/ietf-acl:ace: +--rw fragments? empty augment /ietf-acl:access-lists: +--rw dots-acl-order +--rw acl-set* [set-name type] +--rw set-name -> /ietf-acl:access-lists/acl/acl-name +--rw type -> /ietf-acl:access-lists/acl/acl-type -Tiru From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Jon Shallow Sent: Friday, November 17, 2017 11:21 PM To: dots@ietf.org Subject: [Dots] Data Channel ACL Actions Hi there, draft-ietf-netmod-acl-model-14 has another significant change which affects= DOTS. draft-ietf-netmod-acl-model-13 has the following for ACL actions +--rw actions | +--rw (packet-handling)? | | +--:(deny) | | | +--rw deny? empty | | +--:(permit) | | +--rw permit? empty | +--rw logging? Boolean draft-ietf-netmod-acl-model-14 has updated it with this +--rw actions | {acl-aggregate-stats or interface-acl-aggregate }? | +--rw forwarding identityref | +--rw logging? identityref | +--rw icmp-off? Boolean With different definitions for forwarding. So, I reckon that Figure 8 should look like POST /restconf/data/ietf-dots-access-control-list HTTP/1.1 Host: www.example.com Content-Format: "application/yang.api+json" { "ietf-dots-access-control-list:access-lists": { "client-identifier": [ "dz6pHjaADkaFTbjr0JGBpw", "iAYmCNPmrYoKoqzgFMiobw" ], "acl": [ { "acl-name": "sample-ipv4-acl", "acl-type": "ipv4-acl", "aces": { "ace": [ { "rule-name": "rule1", "matches": { "ipv4-acl": { "source-ipv4-network": "192.0.2.0/24", "destination-ipv4-network": "198.51.100.0/24= " } }, "actions": { "forwarding" : "drop" } } ] } } ] } } Figure 8: POST to install filtering rules With a fair amount of permit =3D allow, deny =3D drop (or should it be reje= ct - I do not think so) and augment updates through the document. Regards Jon --_000_DM5PR16MB1788918EE6AF7E3D13119201EA210DM5PR16MB1788namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Jon,

&nbs= p;

Good poin= t, rate-limit makes sense only with allow action (I have the updated the ya= ng model to use “when-stmt” to make rate-limit leaf node valid = only when “accept” action is used)

&nbs= p;

 &nb= sp;  augment "/ietf-acl:access-lists/ietf-acl:acl/ietf-acl:aces&q= uot; +

 &nb= sp;          "/ietf-acl:a= ce/ietf-acl:actions" {

 &nb= sp;      description "rate-limit action"= ;

 &nb= sp;      leaf rate-limit {

 &nb= sp;         when "/ietf-acl:ac= cess-lists/ietf-acl:acl/ietf-acl:aces/ietf-acl:ace" +

 &nb= sp;            =   "/ietf-acl:actions/ietf-acl:forwarding !=3D 'accept'" {

 &nb= sp;            descr= iption "rate-limit valid only when accept action is used";

 &nb= sp;         }

 &nb= sp;         type decimal64 {

 &nb= sp;           fraction-di= gits 2;

 &nb= sp;         }

 &nb= sp;         description "rate-= limit traffic";

 &nb= sp;     }

 &nb= sp;  }

&nbs= p;

Also upda= ted draft to address your other comment related to fragments

  augment /ietf-acl:a= ccess-lists/ietf-acl:acl/ietf-acl:aces/ietf-acl:ace/ietf-acl:matches/ietf-a= cl:ipv4-acl:

    +--rw fr= agments?   empty

  augment /ietf-acl:access= -lists/ietf-acl:acl/ietf-acl:aces/ietf-acl:ace/ietf-acl:matches/ietf-acl:ip= v6-acl:

    +--rw fr= agments?   empty

&nbs= p;

The updat= ed draft is uploaded to https://github.com/dotswg/dots-data-channel/blob/master/draft-ietf-dots-dat= a-channel-08.txt

&nbs= p;

Cheers,

-Tiru

&nbs= p;

 

From:<= /span> Dots [mailto:dots-bou= nces@ietf.org] On Behalf Of Jon Shallow
Sent: Wednesday, November 22, 2017 9:30 PM
To: Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@McAfee.com= >; dots@ietf.org
Subject: Re: [Dots] Data Channel ACL Actions

 

Hi Tiru= ,

&n= bsp;

I agree= that the new actions container with forwarding identityref is not workable= for adding in rate-limiting.  Forwarding is a mandatory field, so ano= ther possibility is that you augment actions (the level above) with rate-limiting.  This then gives the possibilit= y of allow with a rate-limit or drop with a rate-limit – a bit messy = though.

&n= bsp;

I think=

&n= bsp;

  augment /ietf-acl:access= -lists/ietf-acl:acl/ietf-acl:aces/ietf-acl:ace:

    +--rw fr= agments?   empty

&n= bsp;

Should = (at a minimum) read (as netmod-14 has added in another layer)

&n= bsp;

  augment /ietf-acl:access= -lists/ietf-acl:acl/ietf-acl:aces/ietf-acl:ace/ietf-acl:ipv4-acl:

    +--rw fr= agments?   empty

  augment /ietf-acl:access= -lists/ietf-acl:acl/ietf-acl:aces/ietf-acl:ace/ietf-acl:ipv6-acl:

    +--rw fr= agments?   empty

&n= bsp;

In Figu= re 8, you have (ignoring the fact that “actions” should now be = “dots-actions” if your change is accepted)

“deny”: [null]

Which i= s an empty array.  I think it should be

“deny”: null=

&n= bsp;

Regards=

&n= bsp;

Jon

&n= bsp;

From: Dots [mailto: dots-bounces@ietf.org] On B= ehalf Of Konda, Tirumaleswar Reddy
Sent: 22 November 2017 06:26
To: Jon Shallow; dots@ietf.org<= br> Subject: Re: [Dots] Data Channel ACL Actions

 

Hi Jon,

&nbs= p;

I donR= 17;t think the new actions container in draft-ietf-netmod-acl-model-14 can be augmented to add a new rate-limit = action, I can augment to add a new dots specific action container. The upda= ted yang model looks as follows (it will also order the ACLs created by a DOTS client):

&nbs= p;

module: ietf-dots-access-contro= l-list

  augment /ietf-acl:access= -lists:

    +--rw cl= ient-identifier*   binary

  augment /ietf-acl:access= -lists/ietf-acl:acl/ietf-acl:aces:

    +--rw do= ts-actions

      =  +--rw (packet-handling)?

     &= nbsp;    +--:(deny)

     &= nbsp;    |  +--rw deny?    &nbs= p;    empty

     &= nbsp;    +--:(permit)

     &= nbsp;    |  +--rw permit?    &n= bsp;  empty

     &= nbsp;    +--:(rate-limit)

     &= nbsp;       +--rw rate-limit?  = decimal64

  augment /ietf-acl:access= -lists/ietf-acl:acl/ietf-acl:aces/ietf-acl:ace:

    +--rw fr= agments?   empty

  augment /ietf-acl:access= -lists:

    +--rw do= ts-acl-order

     &= nbsp; +--rw acl-set* [set-name type]

     &= nbsp;    +--rw set-name    -> /ietf-ac= l:access-lists/acl/acl-name

     &= nbsp;    +--rw type       =  -> /ietf-acl:access-lists/acl/acl-type

&nbs= p;

&nbs= p;

-Tiru

&nbs= p;

From:<= /span> Dots [mailto:dots-bounces@ietf.org] On Behalf Of Jon Shallow
Sent: Friday, November 17, 2017 11:21 PM
To: dots@ietf.org
Subject: [Dots] Data Channel ACL Actions

 

Hi there,

 

draft-ietf-netmod-acl-model-14 = has another significant change which affects DOTS.

 

 

draft-ietf-netmod-acl-model-13 = has the following for ACL actions

 

   +--rw actions&= nbsp;           &nbs= p;          

   |  += --rw (packet-handling)?        &nbs= p;        

   |  |&nbs= p; +--:(deny)         &nbs= p;   

   |  |&nbs= p; |  +--rw deny?      empty  &= nbsp;           &nbs= p;      

   |  |&nbs= p; +--:(permit)         &n= bsp;        

   |  |&nbs= p;    +--rw permit?    empty  &= nbsp;           &nbs= p;      

   |  += --rw logging?   Boolean

 

draft-ietf-netmod-acl-model-14 = has updated it with this

 

   +--rw actions<= o:p>

   |   = ;    {acl-aggregate-stats or interface-acl-aggregate }?=

   |  +--rw = forwarding    identityref  

   |  += --rw logging?      identityref  

   |  += --rw icmp-off?     Boolean

 

With different definitions for = forwarding.

 

So, I reckon that Figure 8 shou= ld look like

 

  POST /restconf/data/ietf= -dots-access-control-list HTTP/1.1

  Host: www.exam= ple.com

  Content-Format: "appli= cation/yang.api+json"

  {

   "ietf-dots-ac= cess-control-list:access-lists": {

      = "client-identifier": [

     &= nbsp; "dz6pHjaADkaFTbjr0JGBpw",

     &= nbsp; "iAYmCNPmrYoKoqzgFMiobw"

      = ],

      = "acl": [

      =     {

     &= nbsp;         "acl-name":= "sample-ipv4-acl",

     &= nbsp;         "acl-type": "ipv4-acl",

     &nbs= p;         "aces": {=

     &nbs= p;             = "ace": [

     &= nbsp;           &nbs= p;     {

     &= nbsp;           &nbs= p;         "rule-name": &= quot;rule1",

     &= nbsp;           &nbs= p;         "matches": {

     &= nbsp;           &nbs= p;           "ipv4-a= cl": {

     &= nbsp;           &nbs= p;             = "source-ipv4-network": "192.0.2.0/24",

     &= nbsp;           &nbs= p;             = "destination-ipv4-network": "198.51.100.0/24"

     &= nbsp;           &nbs= p;           }=

     &= nbsp;           &nbs= p;          },

     &= nbsp;           &nbs= p;          "actions"= ;: {

     &= nbsp;           &nbs= p;            &= nbsp; "forwarding" : "drop"= ;

     &= nbsp;           &nbs= p;          }

     &= nbsp;           &nbs= p;      }

     &= nbsp;           &nbs= p;  ]

     &= nbsp;         }

     &= nbsp;    }

      = ]

   }

  }

 

     &= nbsp;           Figure 8:= POST to install filtering rules

 

With a fair amount of permit = =3D allow, deny =3D drop (or should it be reject – I do not think so)= and augment updates through the document.

 

Regards

 

Jon

--_000_DM5PR16MB1788918EE6AF7E3D13119201EA210DM5PR16MB1788namp_-- From nobody Thu Nov 23 02:59:43 2017 Return-Path: X-Original-To: dots@ietf.org Delivered-To: dots@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 05E9F1277BB; Thu, 23 Nov 2017 02:59:42 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: dots@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.66.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151143478197.13143.8345448951718175275@ietfa.amsl.com> Date: Thu, 23 Nov 2017 02:59:42 -0800 Archived-At: Subject: [Dots] I-D Action: draft-ietf-dots-signal-channel-08.txt X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.22 List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Nov 2017 10:59:42 -0000 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 : Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal Channel Authors : Tirumaleswar Reddy Mohamed Boucadair Prashanth Patil Andrew Mortensen Nik Teague Filename : draft-ietf-dots-signal-channel-08.txt Pages : 61 Date : 2017-11-23 Abstract: This document specifies the DOTS signal channel, a protocol for signaling the need for protection against Distributed Denial-of- Service (DDoS) attacks to a server capable of enabling network traffic mitigation on behalf of the requesting client. A companion document defines the DOTS data channel, a separate reliable communication layer for DOTS management and configuration. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dots-signal-channel/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-dots-signal-channel-08 https://datatracker.ietf.org/doc/html/draft-ietf-dots-signal-channel-08 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dots-signal-channel-08 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/ From nobody Thu Nov 23 04:07:13 2017 Return-Path: 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 C95BE124F57 for ; Thu, 23 Nov 2017 04:07:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.001 X-Spam-Level: X-Spam-Status: No, score=-7.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham 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 9w5FcXIbrzEB for ; Thu, 23 Nov 2017 04:07:10 -0800 (PST) Received: from MIVWSMAILOUT1.mcafee.com (mivwsmailout1.mcafee.com [161.69.47.167]) (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 0A696128AB0 for ; Thu, 23 Nov 2017 04:07:09 -0800 (PST) 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=1511438828; 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: authentication-results:x-originating-ip:x-ms-publictraffictype: x-microsoft-exchange-diagnostics:x-ms-exchange-antispam-srfa-diagnostics: x-ms-office365-filtering-correlation-id:x-microsoft-antispam: x-ms-traffictypediagnostic:x-microsoft-antispam-prvs: x-exchange-antispam-report-test:x-exchange-antispam-report-cfa-test: x-forefront-prvs:x-forefront-antispam-report: received-spf:spamdiagnosticoutput:spamdiagnosticmetadata: 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-Transport-CrossTenantHeadersStamped: X-OriginatorOrg:X-NAI-Spam-Flag:X-NAI-Spam-Threshold: X-NAI-Spam-Score:X-NAI-Spam-Version; bh=A ZGyfXxq5H4Iv150ARV9OvSvnss1+UazPaizj1kOal o=; b=ppKBs4SDLWb1CnqLSAug1nJRH9pneqoL7Qdee3KPcXTP JSHhCRd5YrjOhX/xY26fyB3dobdOSV5Id+mUwl9fHYqJZjTbcQ zeg0dUypUNopL7/I9haRhWQhQdrpuGNy0p6oHal5ok6HDxkfSO ZkISa27jGgMUgtjz8lYHW3C3zKg= Received: from MIVEXAPP1N03.corpzone.internalzone.com (unknown [10.48.48.90]) by MIVWSMAILOUT1.mcafee.com with smtp id 46e6_cb4e_956113a7_f6f7_4c33_b932_e84ca9acf1e6; Thu, 23 Nov 2017 06:07:08 -0600 Received: from MIVEXUSR1N06.corpzone.internalzone.com (10.48.48.86) by MIVEXAPP1N03.corpzone.internalzone.com (10.48.48.90) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Thu, 23 Nov 2017 07:06:58 -0500 Received: from MIVEXAPP1N02.corpzone.internalzone.com (10.48.48.89) by MIVEXUSR1N06.corpzone.internalzone.com (10.48.48.86) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Thu, 23 Nov 2017 07:06:57 -0500 Received: from MIVO365EDGE4.corpzone.internalzone.com (10.48.176.87) by MIVEXAPP1N02.corpzone.internalzone.com (10.48.48.89) with Microsoft SMTP Server (TLS) id 15.0.1347.2 via Frontend Transport; Thu, 23 Nov 2017 07:06:56 -0500 Received: from NAM01-BY2-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.1347.2; Thu, 23 Nov 2017 07:06:54 -0500 Received: from DM5PR16MB1788.namprd16.prod.outlook.com (10.172.44.144) by DM5PR16MB1785.namprd16.prod.outlook.com (10.172.44.141) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.239.5; Thu, 23 Nov 2017 12:06:55 +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.20.0239.009; Thu, 23 Nov 2017 12:06:54 +0000 From: "Konda, Tirumaleswar Reddy" To: "dots@ietf.org" Thread-Topic: [Dots] I-D Action: draft-ietf-dots-signal-channel-08.txt Thread-Index: AQHTZEo6yGgVrQsOpEGRYQ/AdAgm8KMh3hEA Date: Thu, 23 Nov 2017 12:06:54 +0000 Message-ID: References: <151143478197.13143.8345448951718175275@ietfa.amsl.com> In-Reply-To: <151143478197.13143.8345448951718175275@ietfa.amsl.com> 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: [122.172.59.37] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DM5PR16MB1785; 6:uQ4+G8ivdn6BdD6JfAXmOXL+lXFOktkd4V4vq0GXPlmqKebJv+BNyB0Zn2zscoXGpLjRaOX9KUISOo34axUgKnhieeLAc7eL+ZHMJKJAA0FJi+VpundvkmhHIeGRERTVnA0F8JvsyfYyPtKPLWrhrYEMoM27/+6Xxc7gNY+AFikbDqzo/Op1HI0MxCVUFUTnlaXV7FbKoLGTqZznVk+yn9WaXq+Mn5GMJSrfGbx0owrr7qixbAKrFSpzBe9yk8/uVtnAvL7AyhcsBziNAyzLru258QeotuQwdEHgl+P7o5ulQAlY948FZ4C6C8oosk2S6t9ryfoOKX3U0QWYrCCzEUhWzbMvnaRJAsYrOia2/74=; 5:fOQgPU26mrH+eEMQKloyR6iikp0gYOTDoI9WwcTPvuPj7NGb9CK9Uwm0TNVClgcL3x4BrZ9IiSr8Tljam6k1iXuB8VZ53e4hZzoZOMhFQOmJvZQkKbx2M5j/Uodd7URmTG+YlelR5dHAfpAZBThTvd6JUnP9Lq8d3codPZJjcv8=; 24:jO/pAifRnvyGCIPE2PgDEdk3eVB0dU+h3m4eW6094rtN0JilC+JKLglAxdGugvY1EnPW4YwhfkNRrjhCHEijZe9s/uT8MJlYEgvLPTDJVu0=; 7:aU24guvEO7LGMQpIa1c5x/ZnJazskQRQpvVzOWN1d8/zrX8zhcUHbrDezqP9uUpKrSBlImssJxpIMSp6BAMKRMXgLDDZNq341HGmwJMGBEGITGufI8qk3+tw1WX6TESen59wK7mZb+PNNcI1TPCJdpxzFLw0QhppdD7XoY5OURgjDldewrYQn9Dz5CvDnM7a5pO2pww6AQD2aILmIHrHf+nFr7lpW/Ge+Q6ckiiQX53ljtXPCjlxtGhkuSke6gjq x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 8fcbe4da-148c-423a-46b3-08d5326ab05d x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(5600025)(4604075)(2017052603199); SRVR:DM5PR16MB1785; x-ms-traffictypediagnostic: DM5PR16MB1785: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(120809045254105); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(8121501046)(5005006)(93006095)(93001095)(3231022)(3002001)(10201501046)(100000703101)(100105400095)(6041248)(20161123562025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123558100)(20161123555025)(20161123560025)(20161123564025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:DM5PR16MB1785; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:DM5PR16MB1785; x-forefront-prvs: 05009853EF x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(346002)(376002)(39860400002)(366004)(199003)(32952001)(13464003)(377424004)(189002)(966005)(7736002)(25786009)(106356001)(68736007)(33656002)(2900100001)(4001150100001)(80792005)(97736004)(14454004)(1730700003)(3660700001)(99286004)(86362001)(105586002)(53546010)(316002)(5640700003)(74316002)(66066001)(81156014)(305945005)(81166006)(8676002)(478600001)(55016002)(54356999)(77096006)(101416001)(3846002)(76176999)(5660300001)(8936002)(102836003)(50986999)(6306002)(6246003)(2950100002)(6506006)(2351001)(3280700002)(6436002)(53936002)(7696004)(6916009)(2501003)(2906002)(9686003)(230783001)(229853002)(72206003)(189998001)(6116002)(85282002); DIR:OUT; SFP:1101; SCL:1; SRVR:DM5PR16MB1785; H:DM5PR16MB1788.namprd16.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: McAfee.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 8fcbe4da-148c-423a-46b3-08d5326ab05d X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Nov 2017 12:06:54.7430 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4943e38c-6dd4-428c-886d-24932bc2d5de X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR16MB1785 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 <6165> : inlines <6183> : streams <1771099> : uri <2538748> Archived-At: Subject: Re: [Dots] I-D Action: draft-ietf-dots-signal-channel-08.txt 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Nov 2017 12:07:12 -0000 This update https://tools.ietf.org/html/draft-ietf-dots-signal-channel-08 a= ddresses all issues tracked in github based on the discussions in DOTS WG s= ession at IETF-100. Any further comments and suggestions are welcome. Cheers, -Tiru > -----Original Message----- > From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of internet- > drafts@ietf.org > Sent: Thursday, November 23, 2017 4:30 PM > To: i-d-announce@ietf.org > Cc: dots@ietf.org > Subject: [Dots] I-D Action: draft-ietf-dots-signal-channel-08.txt >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. > This draft is a work item of the DDoS Open Threat Signaling WG of the IET= F. >=20 > Title : Distributed Denial-of-Service Open Threat Signa= ling (DOTS) > Signal Channel > Authors : Tirumaleswar Reddy > Mohamed Boucadair > Prashanth Patil > Andrew Mortensen > Nik Teague > Filename : draft-ietf-dots-signal-channel-08.txt > Pages : 61 > Date : 2017-11-23 >=20 > Abstract: > This document specifies the DOTS signal channel, a protocol for > signaling the need for protection against Distributed Denial-of- > Service (DDoS) attacks to a server capable of enabling network > traffic mitigation on behalf of the requesting client. A companion > document defines the DOTS data channel, a separate reliable > communication layer for DOTS management and configuration. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-dots-signal-channel/ >=20 > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-dots-signal-channel-08 > https://datatracker.ietf.org/doc/html/draft-ietf-dots-signal-channel-08 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dots-signal-channel-08 >=20 >=20 > Please note that it may take a couple of minutes from the time of submiss= ion > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > Dots mailing list > Dots@ietf.org > https://www.ietf.org/mailman/listinfo/dots From nobody Thu Nov 23 05:30:21 2017 Return-Path: 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 7F13712426E for ; Thu, 23 Nov 2017 05:30:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7 X-Spam-Level: X-Spam-Status: No, score=-7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham 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 M2R61YgCMCTx for ; Thu, 23 Nov 2017 05:30:18 -0800 (PST) Received: from MIVWSMAILOUT1.mcafee.com (mivwsmailout1.mcafee.com [161.69.47.167]) (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 6DCDE120046 for ; Thu, 23 Nov 2017 05:30:17 -0800 (PST) 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=1511443816; 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: authentication-results:x-originating-ip:x-ms-publictraffictype: x-microsoft-exchange-diagnostics:x-ms-exchange-antispam-srfa-diagnostics: x-ms-office365-filtering-correlation-id:x-microsoft-antispam: x-ms-traffictypediagnostic:x-microsoft-antispam-prvs: x-exchange-antispam-report-test:x-exchange-antispam-report-cfa-test: x-forefront-prvs:x-forefront-antispam-report: received-spf:spamdiagnosticoutput:spamdiagnosticmetadata: Content-Type: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-Transport-CrossTenantHeadersStamped: X-OriginatorOrg:X-NAI-Spam-Flag:X-NAI-Spam-Threshold: X-NAI-Spam-Score:X-NAI-Spam-Version; bh=Z X7FIUBgyc3/+5pzlZPvZSL2/LrL1rKjhdF7ple+8G c=; b=hTeawXfxrSBJsch5OEOLr4nxu/FXLibYeLAmsgIeqHxy kRPvTz64A14QjDjnZtSD7RwuAQNhpqRPkm79U2u1Ay2YIH2khe ew28Hcnto5yH2C0IVAFm6d9pOysnKajVk/VW4aqe9lvbE4uIxg l9KvR97anVPWNUFZHIq06jpimZA= Received: from MIVEXAPP1N02.corpzone.internalzone.com (unknown [10.48.48.89]) by MIVWSMAILOUT1.mcafee.com with smtp id 46e6_23eb_a3c896a3_0be1_4d42_bccc_1dc54d227cd4; Thu, 23 Nov 2017 07:30:15 -0600 Received: from MIVEXUSR1N01.corpzone.internalzone.com (10.48.48.81) by MIVEXAPP1N02.corpzone.internalzone.com (10.48.48.89) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Thu, 23 Nov 2017 08:30:14 -0500 Received: from MIVEXUSR1N02.corpzone.internalzone.com (10.48.48.82) by MIVEXUSR1N01.corpzone.internalzone.com (10.48.48.81) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Thu, 23 Nov 2017 08:30:13 -0500 Received: from MIVO365EDGE3.corpzone.internalzone.com (10.48.176.86) by MIVEXUSR1N02.corpzone.internalzone.com (10.48.48.82) with Microsoft SMTP Server (TLS) id 15.0.1347.2 via Frontend Transport; Thu, 23 Nov 2017 08:30:13 -0500 Received: from NAM03-DM3-obe.outbound.protection.outlook.com (10.48.176.240) by edge.mcafee.com (10.48.176.86) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Thu, 23 Nov 2017 08:30:11 -0500 Received: from DM5PR16MB1788.namprd16.prod.outlook.com (10.172.44.144) by DM5PR16MB1785.namprd16.prod.outlook.com (10.172.44.141) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.239.5; Thu, 23 Nov 2017 13:30:12 +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.20.0239.009; Thu, 23 Nov 2017 13:30:11 +0000 From: "Konda, Tirumaleswar Reddy" To: Jon Shallow , "dots@ietf.org" Thread-Topic: [Dots] Data Channel ACL Actions Thread-Index: AdNfzJPvzFwhg6Z7ReePjrKxtiw2xAC5c5bwAD4ggoAAHQYYwAAP/S4Q Date: Thu, 23 Nov 2017 13:30:11 +0000 Message-ID: References: <014b01d35fcc$98a8e910$c9fabb30$@jpshallow.com> <012a01d363aa$e4cd0d30$ae672790$@jpshallow.com> In-Reply-To: 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.206.27] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DM5PR16MB1785; 6:HX/4F/e3OCLAlAF/UkaYf58RSYhPFH//yIh6KV178blS/uNKQ0WS/pi7mLAtoA3FSnNfnjhs0oASUtDDGgvbB4VKD3Wpr+dFsUWTQrdPLbTJ7pSFiOzejPUxx3F1dLMNAWh42BFx32/59JI3IFXD7hL9/Au2CGrjPUk49lM75kqgLLe1lVwsUGdD7dgXmRbWSNncjyN/ic5tp5ca+smB70JNet8J5ZxjFJmqgvpW9kssnJR9DCdIqqyTYERT/YiqKuTQIIu4FBzYgdipa6uvrWxd9ZVBaZXQNYoxP/mIekdNIHdM9K9V+z8lv6d6mLh+hKBE63HQT88XtVAbgOU6jLGVwN4cv+dTv1CHNgiMFT4=; 5:6Jun72usV4izVunGWJ0LaKFpYBBInrCsBPJu+CfNYizdRDOq4XDq6VuhEo7YGyMz97bCen9W+6/xQg6lxci29qhur5v4+/73WQpEUWRNnh63vUNXAmYY9CmsYwPEVPv7o7HOQF1heVLhQLX07E3ST6+hgrKahbzMR32WGIgJXYc=; 24:akCup7aKjyWyrGbVZhgALSlJg4vX9QbvK5ySzlPoomHyorO8ztW/XPN5ZGAvXuaViH9aPUC2uGDxB7wYTaNB96beFCiGRs1Y5CIfeemrYgc=; 7:zg15jYu/2d4kUyiM3qFqoyfizvKj7OkmM+8hBSqUsF+Jr6O32zfv7g67RUazMPve1Wm1Q9hUMVgu9XOLiLvlAJZawrAGiMx/bFFPJyWjxAToYil8ZpQVwEjdPifv7me8llT4qSpDdvRj/gj6+ty+9s2hohzK+vUwKIpOdzu14IWPycca3N6vp/EYwzqUkvefq4YyFjYFeDNcmzXaNzXMQ2RlM42ZOpNjJ4iK3rxT7NeETrq4dzr2p/FfMHynMvBu x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: aeb8bd40-3eae-4b97-86e3-08d5327652bd x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(5600025)(4604075)(2017052603199); SRVR:DM5PR16MB1785; x-ms-traffictypediagnostic: DM5PR16MB1785: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(166708455590820)(227612066756510)(21748063052155)(79290750141951)(123452027830198); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(8121501046)(5005006)(93006095)(93001095)(3231022)(3002001)(10201501046)(100000703101)(100105400095)(6041248)(20161123562025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123558100)(20161123555025)(20161123560025)(20161123564025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:DM5PR16MB1785; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:DM5PR16MB1785; x-forefront-prvs: 05009853EF x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(346002)(376002)(366004)(199003)(32952001)(189002)(7736002)(25786009)(966005)(106356001)(68736007)(33656002)(80792005)(2900100001)(97736004)(14454004)(3660700001)(99286004)(86362001)(105586002)(53546010)(316002)(575784001)(74316002)(66066001)(93886005)(81156014)(81166006)(110136005)(8676002)(55016002)(478600001)(54356999)(53386004)(77096006)(101416001)(790700001)(3846002)(76176999)(5660300001)(8936002)(54896002)(102836003)(50986999)(6306002)(6246003)(2950100002)(6506006)(6436002)(3280700002)(7696004)(53936002)(606006)(2501003)(2906002)(19609705001)(9686003)(236005)(72206003)(229853002)(2940100002)(189998001)(6116002)(85282002); DIR:OUT; SFP:1101; SCL:1; SRVR:DM5PR16MB1785; H:DM5PR16MB1788.namprd16.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX: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_DM5PR16MB1788156803F9B90A7B888618EA210DM5PR16MB1788namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: aeb8bd40-3eae-4b97-86e3-08d5327652bd X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Nov 2017 13:30:11.7850 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4943e38c-6dd4-428c-886d-24932bc2d5de X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR16MB1785 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 <6165> : inlines <6183> : streams <1771104> : uri <2538781> Archived-At: Subject: Re: [Dots] Data Channel ACL Actions 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Nov 2017 13:30:20 -0000 --_000_DM5PR16MB1788156803F9B90A7B888618EA210DM5PR16MB1788namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable From: Konda, Tirumaleswar Reddy Sent: Thursday, November 23, 2017 1:55 PM To: 'Jon Shallow' ; dots@ietf.org Subject: RE: [Dots] Data Channel ACL Actions Hi Jon, Good point, rate-limit makes sense only with allow action (I have the updat= ed the yang model to use "when-stmt" to make rate-limit leaf node valid onl= y when "accept" action is used) augment "/ietf-acl:access-lists/ietf-acl:acl/ietf-acl:aces" + "/ietf-acl:ace/ietf-acl:actions" { description "rate-limit action"; leaf rate-limit { when "/ietf-acl:access-lists/ietf-acl:acl/ietf-acl:aces/ietf-acl= :ace" + "/ietf-acl:actions/ietf-acl:forwarding !=3D 'accept'" { Realized the condition can be simplified, used (when "ietf-acl:forwarding = =3D 'accept'") instead -Tiru description "rate-limit valid only when accept action is used= "; } type decimal64 { fraction-digits 2; } description "rate-limit traffic"; } } Also updated draft to address your other comment related to fragments augment /ietf-acl:access-lists/ietf-acl:acl/ietf-acl:aces/ietf-acl:ace/ie= tf-acl:matches/ietf-acl:ipv4-acl: +--rw fragments? empty augment /ietf-acl:access-lists/ietf-acl:acl/ietf-acl:aces/ietf-acl:ace/ie= tf-acl:matches/ietf-acl:ipv6-acl: +--rw fragments? empty The updated draft is uploaded to https://github.com/dotswg/dots-data-channe= l/blob/master/draft-ietf-dots-data-channel-08.txt Cheers, -Tiru From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Jon Shallow Sent: Wednesday, November 22, 2017 9:30 PM To: Konda, Tirumaleswar Reddy ; dots@ie= tf.org Subject: Re: [Dots] Data Channel ACL Actions Hi Tiru, I agree that the new actions container with forwarding identityref is not w= orkable for adding in rate-limiting. Forwarding is a mandatory field, so a= nother possibility is that you augment actions (the level above) with rate-= limiting. This then gives the possibility of allow with a rate-limit or dr= op with a rate-limit - a bit messy though. I think augment /ietf-acl:access-lists/ietf-acl:acl/ietf-acl:aces/ietf-acl:ace: +--rw fragments? empty Should (at a minimum) read (as netmod-14 has added in another layer) augment /ietf-acl:access-lists/ietf-acl:acl/ietf-acl:aces/ietf-acl:ace/ie= tf-acl:ipv4-acl: +--rw fragments? empty augment /ietf-acl:access-lists/ietf-acl:acl/ietf-acl:aces/ietf-acl:ace/ie= tf-acl:ipv6-acl: +--rw fragments? empty In Figure 8, you have (ignoring the fact that "actions" should now be "dots= -actions" if your change is accepted) "deny": [null] Which is an empty array. I think it should be "deny": null Regards Jon From: Dots [mailto: dots-bounces@ietf.org] On= Behalf Of Konda, Tirumaleswar Reddy Sent: 22 November 2017 06:26 To: Jon Shallow; dots@ietf.org Subject: Re: [Dots] Data Channel ACL Actions Hi Jon, I don't think the new actions container in draft-ietf-netmod-acl-model-14 c= an be augmented to add a new rate-limit action, I can augment to add a new = dots specific action container. The updated yang model looks as follows (it= will also order the ACLs created by a DOTS client): module: ietf-dots-access-control-list augment /ietf-acl:access-lists: +--rw client-identifier* binary augment /ietf-acl:access-lists/ietf-acl:acl/ietf-acl:aces: +--rw dots-actions +--rw (packet-handling)? +--:(deny) | +--rw deny? empty +--:(permit) | +--rw permit? empty +--:(rate-limit) +--rw rate-limit? decimal64 augment /ietf-acl:access-lists/ietf-acl:acl/ietf-acl:aces/ietf-acl:ace: +--rw fragments? empty augment /ietf-acl:access-lists: +--rw dots-acl-order +--rw acl-set* [set-name type] +--rw set-name -> /ietf-acl:access-lists/acl/acl-name +--rw type -> /ietf-acl:access-lists/acl/acl-type -Tiru From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Jon Shallow Sent: Friday, November 17, 2017 11:21 PM To: dots@ietf.org Subject: [Dots] Data Channel ACL Actions Hi there, draft-ietf-netmod-acl-model-14 has another significant change which affects= DOTS. draft-ietf-netmod-acl-model-13 has the following for ACL actions +--rw actions | +--rw (packet-handling)? | | +--:(deny) | | | +--rw deny? empty | | +--:(permit) | | +--rw permit? empty | +--rw logging? Boolean draft-ietf-netmod-acl-model-14 has updated it with this +--rw actions | {acl-aggregate-stats or interface-acl-aggregate }? | +--rw forwarding identityref | +--rw logging? identityref | +--rw icmp-off? Boolean With different definitions for forwarding. So, I reckon that Figure 8 should look like POST /restconf/data/ietf-dots-access-control-list HTTP/1.1 Host: www.example.com Content-Format: "application/yang.api+json" { "ietf-dots-access-control-list:access-lists": { "client-identifier": [ "dz6pHjaADkaFTbjr0JGBpw", "iAYmCNPmrYoKoqzgFMiobw" ], "acl": [ { "acl-name": "sample-ipv4-acl", "acl-type": "ipv4-acl", "aces": { "ace": [ { "rule-name": "rule1", "matches": { "ipv4-acl": { "source-ipv4-network": "192.0.2.0/24", "destination-ipv4-network": "198.51.100.0/24= " } }, "actions": { "forwarding" : "drop" } } ] } } ] } } Figure 8: POST to install filtering rules With a fair amount of permit =3D allow, deny =3D drop (or should it be reje= ct - I do not think so) and augment updates through the document. Regards Jon --_000_DM5PR16MB1788156803F9B90A7B888618EA210DM5PR16MB1788namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

From:<= /span> Konda, Tirumaleswar R= eddy
Sent: Thursday, November 23, 2017 1:55 PM
To: 'Jon Shallow' <supjps-ietf@jpshallow.com>; dots@ietf.org Subject: RE: [Dots] Data Channel ACL Actions

 

Hi Jon,

&nbs= p;

Good poin= t, rate-limit makes sense only with allow action (I have the updated the ya= ng model to use “when-stmt” to make rate-limit leaf node valid = only when “accept” action is used)

&nbs= p;

 &nb= sp;  augment "/ietf-acl:access-lists/ietf-acl:acl/ietf-acl:aces&q= uot; +

 &nb= sp;          "/ietf-acl:a= ce/ietf-acl:actions" {

 &nb= sp;      description "rate-limit action"= ;

 &nb= sp;      leaf rate-limit {

 &nb= sp;         when "/ietf-acl:ac= cess-lists/ietf-acl:acl/ietf-acl:aces/ietf-acl:ace" +

 &nb= sp;            =   "/ietf-acl:actions/ietf-acl:forwarding !=3D 'accept'" {

&nbs= p;

Realized = the condition can be simplified, used (when "ietf-acl:forwarding =3D '= accept'") instead

&nbs= p;

-Tiru

&nbs= p;

 &nb= sp;            descr= iption "rate-limit valid only when accept action is used";

 &nb= sp;         }

 &nb= sp;         type decimal64 {

 &nb= sp;           fraction-di= gits 2;

 &nb= sp;         }

 &nb= sp;         description "rate-= limit traffic";

 &nb= sp;     }

 &nb= sp;  }

&nbs= p;

Also upda= ted draft to address your other comment related to fragments

  augment /ietf-acl:a= ccess-lists/ietf-acl:acl/ietf-acl:aces/ietf-acl:ace/ietf-acl:matches/ietf-a= cl:ipv4-acl:

    +--rw fr= agments?   empty

  augment /ietf-acl:access= -lists/ietf-acl:acl/ietf-acl:aces/ietf-acl:ace/ietf-acl:matches/ietf-acl:ip= v6-acl:

    +--rw fr= agments?   empty

&nbs= p;

The updat= ed draft is uploaded to https://github.com/dotswg/dots-data-channel/blob/master/draft-ietf-dots-dat= a-channel-08.txt

&nbs= p;

Cheers,

-Tiru

&nbs= p;

&nbs= p;

From:<= /span> Dots [mailto:dots-bou= nces@ietf.org] On Behalf Of Jon Shallow
Sent: Wednesday, November 22, 2017 9:30 PM
To: Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@McAfee.com= >; dots@ietf.org
Subject: Re: [Dots] Data Channel ACL Actions

 

Hi Tiru= ,

&n= bsp;

I agree= that the new actions container with forwarding identityref is not workable= for adding in rate-limiting.  Forwarding is a mandatory field, so ano= ther possibility is that you augment actions (the level above) with rate-limiting.  This then gives the possibilit= y of allow with a rate-limit or drop with a rate-limit – a bit messy = though.

&n= bsp;

I think=

&n= bsp;

  augment /ietf-acl:access= -lists/ietf-acl:acl/ietf-acl:aces/ietf-acl:ace:

    +--rw fr= agments?   empty

&n= bsp;

Should = (at a minimum) read (as netmod-14 has added in another layer)

&n= bsp;

  augment /ietf-acl:access= -lists/ietf-acl:acl/ietf-acl:aces/ietf-acl:ace/ietf-acl:ipv4-acl:

    +--rw fr= agments?   empty

  augment /ietf-acl:access= -lists/ietf-acl:acl/ietf-acl:aces/ietf-acl:ace/ietf-acl:ipv6-acl:

    +--rw fr= agments?   empty

&n= bsp;

In Figu= re 8, you have (ignoring the fact that “actions” should now be = “dots-actions” if your change is accepted)

“deny”: [null]

Which i= s an empty array.  I think it should be

“deny”: null=

&n= bsp;

Regards=

&n= bsp;

Jon

&n= bsp;

From: Dots [mailto: dots-bounces@ietf.org] On B= ehalf Of Konda, Tirumaleswar Reddy
Sent: 22 November 2017 06:26
To: Jon Shallow; dots@ietf.org<= br> Subject: Re: [Dots] Data Channel ACL Actions

 

Hi Jon,

&nbs= p;

I donR= 17;t think the new actions container in draft-ietf-netmod-acl-model-14 can be augmented to add a new rate-limit = action, I can augment to add a new dots specific action container. The upda= ted yang model looks as follows (it will also order the ACLs created by a DOTS client):

&nbs= p;

module: ietf-dots-access-contro= l-list

  augment /ietf-acl:access= -lists:

    +--rw cl= ient-identifier*   binary

  augment /ietf-acl:access= -lists/ietf-acl:acl/ietf-acl:aces:

    +--rw do= ts-actions

      =  +--rw (packet-handling)?

     &= nbsp;    +--:(deny)

     &= nbsp;    |  +--rw deny?    &nbs= p;    empty

     &= nbsp;    +--:(permit)

     &= nbsp;    |  +--rw permit?    &n= bsp;  empty

     &= nbsp;    +--:(rate-limit)

     &= nbsp;       +--rw rate-limit?  = decimal64

  augment /ietf-acl:access= -lists/ietf-acl:acl/ietf-acl:aces/ietf-acl:ace:

    +--rw fr= agments?   empty

  augment /ietf-acl:access= -lists:

    +--rw do= ts-acl-order

     &= nbsp; +--rw acl-set* [set-name type]

     &= nbsp;    +--rw set-name    -> /ietf-ac= l:access-lists/acl/acl-name

     &= nbsp;    +--rw type       =  -> /ietf-acl:access-lists/acl/acl-type

&nbs= p;

&nbs= p;

-Tiru

&nbs= p;

From:<= /span> Dots [mailto:dots-bounces@ietf.org] On Behalf Of Jon Shallow
Sent: Friday, November 17, 2017 11:21 PM
To: dots@ietf.org
Subject: [Dots] Data Channel ACL Actions

 

Hi there,

 

draft-ietf-netmod-acl-model-14 = has another significant change which affects DOTS.

 

 

draft-ietf-netmod-acl-model-13 = has the following for ACL actions

 

   +--rw actions&= nbsp;           &nbs= p;          

   |  += --rw (packet-handling)?        &nbs= p;        

   |  |&nbs= p; +--:(deny)         &nbs= p;   

   |  |&nbs= p; |  +--rw deny?      empty  &= nbsp;           &nbs= p;      

   |  |&nbs= p; +--:(permit)         &n= bsp;        

   |  |&nbs= p;    +--rw permit?    empty  &= nbsp;           &nbs= p;      

   |  += --rw logging?   Boolean

 

draft-ietf-netmod-acl-model-14 = has updated it with this

 

   +--rw actions<= o:p>

   |   = ;    {acl-aggregate-stats or interface-acl-aggregate }?=

   |  +--rw = forwarding    identityref  

   |  += --rw logging?      identityref  

   |  += --rw icmp-off?     Boolean

 

With different definitions for = forwarding.

 

So, I reckon that Figure 8 shou= ld look like

 

  POST /restconf/data/ietf= -dots-access-control-list HTTP/1.1

  Host: www.exam= ple.com

  Content-Format: "appli= cation/yang.api+json"

  {

   "ietf-dots-ac= cess-control-list:access-lists": {

      = "client-identifier": [

     &= nbsp; "dz6pHjaADkaFTbjr0JGBpw",

     &= nbsp; "iAYmCNPmrYoKoqzgFMiobw"

      = ],

      = "acl": [

      =     {

     &= nbsp;         "acl-name":= "sample-ipv4-acl",

     &= nbsp;         "acl-type": "ipv4-acl",

     &nbs= p;         "aces": {=

     &nbs= p;             = "ace": [

     &= nbsp;           &nbs= p;     {

     &= nbsp;           &nbs= p;         "rule-name": &= quot;rule1",

     &= nbsp;           &nbs= p;         "matches": {

     &= nbsp;           &nbs= p;           "ipv4-a= cl": {

     &= nbsp;           &nbs= p;             = "source-ipv4-network": "192.0.2.0/24",

     &= nbsp;           &nbs= p;             = "destination-ipv4-network": "198.51.100.0/24"

     &= nbsp;           &nbs= p;           }=

     &= nbsp;           &nbs= p;          },

     &= nbsp;           &nbs= p;          "actions"= ;: {

     &= nbsp;           &nbs= p;            &= nbsp; "forwarding" : "drop"= ;

     &= nbsp;           &nbs= p;          }

     &= nbsp;           &nbs= p;      }

     &= nbsp;           &nbs= p;  ]

     &= nbsp;         }

     &= nbsp;    }

      = ]

   }

  }

 

     &= nbsp;           Figure 8:= POST to install filtering rules

 

With a fair amount of permit = =3D allow, deny =3D drop (or should it be reject – I do not think so)= and augment updates through the document.

 

Regards

 

Jon

--_000_DM5PR16MB1788156803F9B90A7B888618EA210DM5PR16MB1788namp_-- From nobody Thu Nov 23 05:59:05 2017 Return-Path: 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 10079128D69 for ; Thu, 23 Nov 2017 05:59:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 6sWbPGGxx6hU for ; Thu, 23 Nov 2017 05:59:01 -0800 (PST) Received: from mail.jpshallow.com (mail.jpshallow.com [217.40.240.153]) (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 37A4E128D44 for ; Thu, 23 Nov 2017 05:59:01 -0800 (PST) Received: from [127.0.0.1] (helo=N01332) by mail.jpshallow.com with smtps (TLSv1:ECDHE-RSA-AES256-SHA:256) (Exim 4.89) (envelope-from ) id 1eHs1q-0002Q0-Do; Thu, 23 Nov 2017 13:58:58 +0000 From: "Jon Shallow" To: "'Konda, Tirumaleswar Reddy'" , References: <014b01d35fcc$98a8e910$c9fabb30$@jpshallow.com> <012a01d363aa$e4cd0d30$ae672790$@jpshallow.com> In-Reply-To: Date: Thu, 23 Nov 2017 13:58:59 -0000 Message-ID: <022b01d36463$360d0840$a22718c0$@jpshallow.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_022C_01D36463.361063A0" X-Mailer: Microsoft Outlook 14.0 Content-Language: en-gb Thread-Index: AQLEJeTZWxLmPjSU34IiB1W15cI71AIHigZtAqDAHqMB9N2EVgNXgtN3oPDQaSA= Archived-At: Subject: Re: [Dots] Data Channel ACL Actions 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Nov 2017 13:59:04 -0000 This is a multipart message in MIME format. ------=_NextPart_000_022C_01D36463.361063A0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Tiru, I think the rate limiting needs to be defined as being in bytes per second or in bits per second for clarity. I am a bit confused about your update - it is not the same as in draft-ietf-dots-data-channel-08.txt. Also, should rate-limit only be there when :forwarding = 'accept', rather than a description telling you it is not there in the case of != 'accept'? Regards Jon From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of Konda, Tirumaleswar Reddy Sent: 23 November 2017 13:30 To: Jon Shallow; dots@ietf.org Subject: Re: [Dots] Data Channel ACL Actions From: Konda, Tirumaleswar Reddy Sent: Thursday, November 23, 2017 1:55 PM To: 'Jon Shallow' ; dots@ietf.org Subject: RE: [Dots] Data Channel ACL Actions Hi Jon, Good point, rate-limit makes sense only with allow action (I have the updated the yang model to use "when-stmt" to make rate-limit leaf node valid only when "accept" action is used) augment "/ietf-acl:access-lists/ietf-acl:acl/ietf-acl:aces" + "/ietf-acl:ace/ietf-acl:actions" { description "rate-limit action"; leaf rate-limit { when "/ietf-acl:access-lists/ietf-acl:acl/ietf-acl:aces/ietf-acl:ace" + "/ietf-acl:actions/ietf-acl:forwarding != 'accept'" { Realized the condition can be simplified, used (when "ietf-acl:forwarding = 'accept'") instead -Tiru description "rate-limit valid only when accept action is used"; } type decimal64 { fraction-digits 2; } description "rate-limit traffic"; } } Also updated draft to address your other comment related to fragments augment /ietf-acl:access-lists/ietf-acl:acl/ietf-acl:aces/ietf-acl:ace/ietf-acl:matc hes/ietf-acl:ipv4-acl: +--rw fragments? empty augment /ietf-acl:access-lists/ietf-acl:acl/ietf-acl:aces/ietf-acl:ace/ietf-acl:matc hes/ietf-acl:ipv6-acl: +--rw fragments? empty The updated draft is uploaded to https://github.com/dotswg/dots-data-channel/blob/master/draft-ietf-dots-data -channel-08.txt Cheers, -Tiru From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Jon Shallow Sent: Wednesday, November 22, 2017 9:30 PM To: Konda, Tirumaleswar Reddy ; dots@ietf.org Subject: Re: [Dots] Data Channel ACL Actions Hi Tiru, I agree that the new actions container with forwarding identityref is not workable for adding in rate-limiting. Forwarding is a mandatory field, so another possibility is that you augment actions (the level above) with rate-limiting. This then gives the possibility of allow with a rate-limit or drop with a rate-limit - a bit messy though. I think augment /ietf-acl:access-lists/ietf-acl:acl/ietf-acl:aces/ietf-acl:ace: +--rw fragments? empty Should (at a minimum) read (as netmod-14 has added in another layer) augment /ietf-acl:access-lists/ietf-acl:acl/ietf-acl:aces/ietf-acl:ace/ietf-acl:ipv4 -acl: +--rw fragments? empty augment /ietf-acl:access-lists/ietf-acl:acl/ietf-acl:aces/ietf-acl:ace/ietf-acl:ipv6 -acl: +--rw fragments? empty In Figure 8, you have (ignoring the fact that "actions" should now be "dots-actions" if your change is accepted) "deny": [null] Which is an empty array. I think it should be "deny": null Regards Jon From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of Konda, Tirumaleswar Reddy Sent: 22 November 2017 06:26 To: Jon Shallow; dots@ietf.org Subject: Re: [Dots] Data Channel ACL Actions Hi Jon, I don't think the new actions container in draft-ietf-netmod-acl-model-14 can be augmented to add a new rate-limit action, I can augment to add a new dots specific action container. The updated yang model looks as follows (it will also order the ACLs created by a DOTS client): module: ietf-dots-access-control-list augment /ietf-acl:access-lists: +--rw client-identifier* binary augment /ietf-acl:access-lists/ietf-acl:acl/ietf-acl:aces: +--rw dots-actions +--rw (packet-handling)? +--:(deny) | +--rw deny? empty +--:(permit) | +--rw permit? empty +--:(rate-limit) +--rw rate-limit? decimal64 augment /ietf-acl:access-lists/ietf-acl:acl/ietf-acl:aces/ietf-acl:ace: +--rw fragments? empty augment /ietf-acl:access-lists: +--rw dots-acl-order +--rw acl-set* [set-name type] +--rw set-name -> /ietf-acl:access-lists/acl/acl-name +--rw type -> /ietf-acl:access-lists/acl/acl-type -Tiru From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Jon Shallow Sent: Friday, November 17, 2017 11:21 PM To: dots@ietf.org Subject: [Dots] Data Channel ACL Actions Hi there, draft-ietf-netmod-acl-model-14 has another significant change which affects DOTS. draft-ietf-netmod-acl-model-13 has the following for ACL actions +--rw actions | +--rw (packet-handling)? | | +--:(deny) | | | +--rw deny? empty | | +--:(permit) | | +--rw permit? empty | +--rw logging? Boolean draft-ietf-netmod-acl-model-14 has updated it with this +--rw actions | {acl-aggregate-stats or interface-acl-aggregate }? | +--rw forwarding identityref | +--rw logging? identityref | +--rw icmp-off? Boolean With different definitions for forwarding. So, I reckon that Figure 8 should look like POST /restconf/data/ietf-dots-access-control-list HTTP/1.1 Host: www.example.com Content-Format: "application/yang.api+json" { "ietf-dots-access-control-list:access-lists": { "client-identifier": [ "dz6pHjaADkaFTbjr0JGBpw", "iAYmCNPmrYoKoqzgFMiobw" ], "acl": [ { "acl-name": "sample-ipv4-acl", "acl-type": "ipv4-acl", "aces": { "ace": [ { "rule-name": "rule1", "matches": { "ipv4-acl": { "source-ipv4-network": "192.0.2.0/24", "destination-ipv4-network": "198.51.100.0/24" } }, "actions": { "forwarding" : "drop" } } ] } } ] } } Figure 8: POST to install filtering rules With a fair amount of permit = allow, deny = drop (or should it be reject - I do not think so) and augment updates through the document. Regards Jon ------=_NextPart_000_022C_01D36463.361063A0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Tiru,

 

I think the rate = limiting needs to be defined as being in bytes per second or in bits per = second for clarity.

 

I am a bit confused = about your update – it is not the same as in = draft-ietf-dots-data-channel-08.txt.

Also, should rate-limit = only be there when :forwarding =3D ‘accept’, rather than a = description telling you it is not there in the case of !=3D = ‘accept’?

 

Regards

 

Jon

 

 

From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of = Konda, Tirumaleswar Reddy
Sent: 23 November 2017 = 13:30
To: Jon Shallow; dots@ietf.org
Subject: Re: = [Dots] Data Channel ACL Actions

 

From: Konda, Tirumaleswar = Reddy
Sent: Thursday, November 23, 2017 1:55 PM
To: = 'Jon Shallow' <supjps-ietf@jpshallow.com&g= t;; dots@ietf.org
Subject: RE: = [Dots] Data Channel ACL Actions

 

Hi Jon,

 

Good point, rate-limit makes sense = only with allow action (I have the updated the yang model to use = “when-stmt” to make rate-limit leaf node valid only when = “accept” action is used)

 

    augment = "/ietf-acl:access-lists/ietf-acl:acl/ietf-acl:aces" = +

      =       = "/ietf-acl:ace/ietf-acl:actions" {

      =   description "rate-limit = action";

      =   leaf rate-limit {

      =      when = "/ietf-acl:access-lists/ietf-acl:acl/ietf-acl:aces/ietf-acl:ace"= ; +

      =           = "/ietf-acl:actions/ietf-acl:forwarding !=3D 'accept'" = {

 

Realized the condition can be = simplified, used (when "ietf-acl:forwarding =3D 'accept'") = instead

 

-Tiru

 

      =         description "rate-limit = valid only when accept action is used";

      =      }

      =      type decimal64 {

      =        fraction-digits = 2;

      =      }

      =      description "rate-limit = traffic";

      = }

    = }

 

Also updated draft to address your = other comment related to fragments

  augment = /ietf-acl:access-lists/ietf-acl:acl/ietf-acl:aces/ietf-acl:ace/ietf-acl:m= atches/ietf-acl:ipv4-acl:

    +--rw = fragments?   empty

  augment = /ietf-acl:access-lists/ietf-acl:acl/ietf-acl:aces/ietf-acl:ace/ietf-acl:m= atches/ietf-acl:ipv6-acl:

    +--rw = fragments?   empty

 

The updated draft is uploaded to https://github.com/dotswg/dots-data-channel/b= lob/master/draft-ietf-dots-data-channel-08.txt =

 

Cheers,

-Tiru

 

 

From: Dots [mailto:dots-bounces@ietf.org] = On Behalf Of Jon Shallow
Sent: Wednesday, November 22, = 2017 9:30 PM
To: Konda, Tirumaleswar Reddy <TirumaleswarReddy_Kond= a@McAfee.com>; dots@ietf.org
Subject: Re: = [Dots] Data Channel ACL Actions

 

Hi = Tiru,

 

I agree that the new = actions container with forwarding identityref is not workable for adding = in rate-limiting.  Forwarding is a mandatory field, so another = possibility is that you augment actions (the level above) with = rate-limiting.  This then gives the possibility of allow with a = rate-limit or drop with a rate-limit – a bit messy = though.

 

I = think

 

  augment = /ietf-acl:access-lists/ietf-acl:acl/ietf-acl:aces/ietf-acl:ace:

    +--rw = fragments?   empty

 

Should (at a minimum) = read (as netmod-14 has added in another layer)

 

  augment = /ietf-acl:access-lists/ietf-acl:acl/ietf-acl:aces/ietf-acl:ace/ietf-acl:i= pv4-acl:

    +--rw = fragments?   empty

  augment = /ietf-acl:access-lists/ietf-acl:acl/ietf-acl:aces/ietf-acl:ace/ietf-acl:i= pv6-acl:

    +--rw = fragments?   empty

 

In Figure 8, you have = (ignoring the fact that “actions” should now be = “dots-actions” if your change is = accepted)

“deny”: [null]

Which is an empty = array.  I think it should be

“deny”: null

 

Regards

 

Jon

 

From: Dots [mailto: dots-bounces@ietf.org] On = Behalf Of Konda, Tirumaleswar Reddy
Sent: 22 November 2017 = 06:26
To: Jon Shallow; dots@ietf.org
Subject: Re: = [Dots] Data Channel ACL Actions

 

Hi = Jon,

 

I don’t think the new actions = container in draft-ietf-netmod-acl-model-14 can be augmented to add a new = rate-limit action, I can augment to add a new dots specific action = container. The updated yang model looks as follows (it will also order = the ACLs created by a DOTS client):

 

module: = ietf-dots-access-control-list

  augment = /ietf-acl:access-lists:

    +--rw = client-identifier*   binary

  augment = /ietf-acl:access-lists/ietf-acl:acl/ietf-acl:aces:

<= p class=3DMsoNormal>    +--rw = dots-actions

     =   +--rw (packet-handling)?

      &nbs= p;   +--:(deny)

      &nbs= p;   |  +--rw = deny?         = empty

      &nbs= p;   +--:(permit)

      &nbs= p;   |  +--rw permit?       = empty

      &nbs= p;   +--:(rate-limit)

      &nbs= p;      +--rw rate-limit?   = decimal64

  augment = /ietf-acl:access-lists/ietf-acl:acl/ietf-acl:aces/ietf-acl:ace:

    +--rw = fragments?   empty

  augment = /ietf-acl:access-lists:

    +--rw = dots-acl-order

       = +--rw acl-set* [set-name type]

      &nbs= p;   +--rw set-name    -> = /ietf-acl:access-lists/acl/acl-name

      &nbs= p;   +--rw type      =   -> = /ietf-acl:access-lists/acl/acl-type

 

 

-Tiru

 

From: Dots [mailto:dots-bounces@ietf.org] = On Behalf Of Jon Shallow
Sent: Friday, November 17, = 2017 11:21 PM
To: dots@ietf.org
Subject: = [Dots] Data Channel ACL Actions

 

Hi there,

 

draft-ietf-netmod-acl-model-14 has another significant = change which affects DOTS.

 

 

draft-ietf-netmod-acl-model-13 has the following for = ACL actions

 

   +--rw = actions           =              =

   |  +--rw = (packet-handling)?         &= nbsp;       

   |  |  = +--:(deny)          &nb= sp;  

   |  |  |  +--rw = deny?      = empty           &n= bsp;          =

   |  |  = +--:(permit)          &= nbsp;       

   |  |     = +--rw permit?    = empty           &n= bsp;          =

   |  +--rw = logging?   Boolean

 

draft-ietf-netmod-acl-model-14 has updated it with = this

 

   +--rw actions

   |       = {acl-aggregate-stats or interface-acl-aggregate }?

   |  +--rw = forwarding    identityref  

   |  +--rw = logging?      identityref   =

   |  +--rw = icmp-off?     Boolean

 

With = different definitions for forwarding.

 

So, I reckon = that Figure 8 should look like

 

  POST = /restconf/data/ietf-dots-access-control-list HTTP/1.1

  Host: www.example.com

  Content-Format: = "application/yang.api+json"

  {

   = "ietf-dots-access-control-list:access-lists": = {

      = "client-identifier": [

       = "dz6pHjaADkaFTbjr0JGBpw",

       = "iAYmCNPmrYoKoqzgFMiobw"

      ],

      "acl": = [

      =     {

         &= nbsp;     "acl-name": = "sample-ipv4-acl",

         &= nbsp;     "acl-type": = "ipv4-acl",

          &nb= sp;    "aces": {

          &nb= sp;        "ace": = [

         &= nbsp;           &n= bsp; {

         &= nbsp;           &n= bsp;     "rule-name": = "rule1",

         &= nbsp;           &n= bsp;     "matches": {

         &= nbsp;           &n= bsp;       "ipv4-acl": = {

         &= nbsp;           &n= bsp;         = "source-ipv4-network": = "192.0.2.0/24",

         &= nbsp;           &n= bsp;         = "destination-ipv4-network": = "198.51.100.0/24"

         &= nbsp;           &n= bsp;       }

         &= nbsp;           &n= bsp;      },

         &= nbsp;           &n= bsp;      "actions": = {

         &= nbsp;           &n= bsp;          "forwarding" : = "drop"

         &= nbsp;           &n= bsp;      }

         &= nbsp;           &n= bsp;  }

         &= nbsp;          = ]

         &= nbsp;     }

          = }

      = ]

   }

  }

 

         &= nbsp;       Figure 8: POST to install = filtering rules

 

With a fair = amount of permit =3D allow, deny =3D drop (or should it be reject = – I do not think so) and augment updates through the = document.

 

Regards

 

Jon

------=_NextPart_000_022C_01D36463.361063A0-- From nobody Thu Nov 23 06:20:37 2017 Return-Path: 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 0CA991292CE for ; Thu, 23 Nov 2017 06:20:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.32 X-Spam-Level: X-Spam-Status: No, score=-4.32 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham 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 Z3pxJyYkOq-U for ; Thu, 23 Nov 2017 06:20:29 -0800 (PST) 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 3BC771293F4 for ; Thu, 23 Nov 2017 06:19:03 -0800 (PST) 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=1511446742; 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: authentication-results:x-originating-ip:x-ms-publictraffictype: x-microsoft-exchange-diagnostics:x-ms-exchange-antispam-srfa-diagnostics: x-ms-office365-filtering-correlation-id:x-microsoft-antispam: x-ms-traffictypediagnostic:x-microsoft-antispam-prvs: x-exchange-antispam-report-test:x-exchange-antispam-report-cfa-test: x-forefront-prvs:x-forefront-antispam-report: received-spf:spamdiagnosticoutput:spamdiagnosticmetadata: Content-Type: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-Transport-CrossTenantHeadersStamped: X-OriginatorOrg:X-NAI-Spam-Flag:X-NAI-Spam-Threshold: X-NAI-Spam-Score:X-NAI-Spam-Version; bh=q S3equFbMVEaPGK/PFpqTMAngz6KT5rtPRGf8DgF1K M=; b=hdbyvFKoY0Y73a4pNmxQHodOfXmZ0zX8Qnxejgy7+u3t NsgRcQJEMie+L1+9Q4RZ4bZmTWDzcPZbi2dGXitzibJarms79n ngfvy/rAFehr9K1xGr6nEWcltGu9M3raJMHhIIGRgJBVvWtI7i Jyn8n6eEzbfDwCjhRszuuomP9YI= Received: from DNVEXAPP1N05.corpzone.internalzone.com (unknown [10.44.48.89]) by DNVWSMAILOUT1.mcafee.com with smtp id 41a1_f36a_704afc44_7eb2_4b34_8850_71154a0d09f2; Thu, 23 Nov 2017 08:19:01 -0600 Received: from DNVEXUSR1N09.corpzone.internalzone.com (10.44.48.82) by DNVEXAPP1N05.corpzone.internalzone.com (10.44.48.89) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Thu, 23 Nov 2017 07:18:14 -0700 Received: from DNVEXUSR1N09.corpzone.internalzone.com (10.44.48.82) by DNVEXUSR1N09.corpzone.internalzone.com (10.44.48.82) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Thu, 23 Nov 2017 07:18:12 -0700 Received: from DNVO365EDGE2.corpzone.internalzone.com (10.44.176.74) by DNVEXUSR1N09.corpzone.internalzone.com (10.44.48.82) with Microsoft SMTP Server (TLS) id 15.0.1347.2 via Frontend Transport; Thu, 23 Nov 2017 07:18:12 -0700 Received: from NAM03-CO1-obe.outbound.protection.outlook.com (10.44.176.242) by edge.mcafee.com (10.44.176.74) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Thu, 23 Nov 2017 07:18:11 -0700 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.20.239.5; Thu, 23 Nov 2017 14:18:10 +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.20.0239.009; Thu, 23 Nov 2017 14:18:10 +0000 From: "Konda, Tirumaleswar Reddy" To: Jon Shallow , "dots@ietf.org" Thread-Topic: [Dots] Data Channel ACL Actions Thread-Index: AdNfzJPvzFwhg6Z7ReePjrKxtiw2xAC5c5bwAD4ggoAAHQYYwAAP/S4QAAERFYAAAJgXkA== Date: Thu, 23 Nov 2017 14:18:10 +0000 Message-ID: References: <014b01d35fcc$98a8e910$c9fabb30$@jpshallow.com> <012a01d363aa$e4cd0d30$ae672790$@jpshallow.com> <022b01d36463$360d0840$a22718c0$@jpshallow.com> In-Reply-To: <022b01d36463$360d0840$a22718c0$@jpshallow.com> 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.206.27] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DM5PR16MB1787; 6:KJrAHQPb+dOW2YUTxV0H0+jeJkMQ6/v2e6kG1sWh3BCHD8k3dxkyk3f3sxRjrndYts3EdULHdV74nRaCCd+yLRLuTG5u7cuRRplFU/wFr9hOGDi7pM0JlFXvktaM7MTMJhx5nFh2v6Dsk9mXmS8LaM1WU8WAC+hnY4AswegAWHfXCgnMvHGXPG3uD5JxqxZTh0D7Fg6Z1vapmEDzoNHA08yM30NvpTVsF1jvrK0KQytOEr2xyLhQpG+cKrKEv7az5t/9MfV0cvpCdxS7+1LaG+VVr5tY4s0v8R/xTAuIPxx9dyQ53Dv3s7Q6gOG53O/fj4wZE+NAOPS1pInULpkahDvBrhZGLQ+QC+9Lbe3RmG8=; 5:7ILFfdC6oxTVgN1UO0LaTJKiiOOa0yWEuaSfj319tX+6g0GOMHD5gsVt33y9MY8QgGUDVxALYuJ3n91omqJinN7Nt6Hlcnhydp0Vvw0cTbvUWcBnSmUOtmpHyPofRhPuEJ8GzPr6/HeQhTR0RznxPhW4vjnm8vEp0mR+jRKimkg=; 24:e6cHh2NSI1r4+uXY5L+L/cE/YlFzkz7GZo/E8Q7dsDmXcbHRZpL10FG0fC7r2Grxga0+/f1qzLMse7Fa/op4J0JFwihmGz1b+uQXgvyzKq8=; 7:GAU9m+TrWRO85UAiKCfXNbYn7ff994fGtNTIhG2i1KfBqKIB/Rufi5s4a+u+EGg+NV1+o/ta38TD16q/FsbXHWk1QcmDcNlBLPzo0KdXb/a84mmyo6lDN/CiVvwl/z2MSw/xQwcflVWPA18deSp7E5KhY0HX3KbI3dZ+W0u/wuplJsZwE2AtItSbhzecUPqAmE0ks74H7gq+WZzwg+LRheWGjG1POnfWDR+z49ESB1kJyv2WmYKJ4ws1NeIbdLQV x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: bc167cb4-afc5-4d86-815b-08d5327d0684 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(5600025)(4604075)(2017052603258); SRVR:DM5PR16MB1787; x-ms-traffictypediagnostic: DM5PR16MB1787: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(166708455590820)(227612066756510)(21748063052155)(79290750141951)(123452027830198); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(8121501046)(5005006)(3002001)(10201501046)(93006095)(93001095)(3231022)(100000703101)(100105400095)(6041248)(20161123564025)(20161123555025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123560025)(20161123562025)(20161123558100)(6072148)(201708071742011)(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: 05009853EF x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(366004)(346002)(376002)(189002)(32952001)(199003)(53386004)(3280700002)(229853002)(50986999)(93886005)(14454004)(97736004)(102836003)(54356999)(76176999)(2501003)(6116002)(5660300001)(105586002)(790700001)(3846002)(106356001)(316002)(53546010)(2900100001)(33656002)(3660700001)(966005)(189998001)(606006)(2950100002)(478600001)(2906002)(101416001)(25786009)(86362001)(53946003)(80792005)(8936002)(72206003)(7696004)(236005)(66066001)(53936002)(55016002)(8676002)(9686003)(6246003)(6306002)(68736007)(81156014)(575784001)(81166006)(54896002)(99286004)(7736002)(110136005)(74316002)(6436002)(77096006)(6506006)(19609705001)(85282002); DIR:OUT; SFP:1101; SCL:1; SRVR:DM5PR16MB1787; H:DM5PR16MB1788.namprd16.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; 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_DM5PR16MB17885E1F0E5091929A90FDD9EA210DM5PR16MB1788namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: bc167cb4-afc5-4d86-815b-08d5327d0684 X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Nov 2017 14:18:10.2878 (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 <6165> : inlines <6183> : streams <1771108> : uri <2538801> Archived-At: Subject: Re: [Dots] Data Channel ACL Actions 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Nov 2017 14:20:35 -0000 --_000_DM5PR16MB17885E1F0E5091929A90FDD9EA210DM5PR16MB1788namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Jon, Its defined as bytes per second (see Section 3.3.1) and the updated draft i= s using ":forwarding =3D 'accept'. -Tiru From: Jon Shallow [mailto:supjps-ietf@jpshallow.com] Sent: Thursday, November 23, 2017 7:29 PM To: Konda, Tirumaleswar Reddy ; dots@ie= tf.org Subject: RE: [Dots] Data Channel ACL Actions Hi Tiru, I think the rate limiting needs to be defined as being in bytes per second = or in bits per second for clarity. I am a bit confused about your update - it is not the same as in draft-ietf= -dots-data-channel-08.txt. Also, should rate-limit only be there when :forwarding =3D 'accept', rather= than a description telling you it is not there in the case of !=3D 'accept= '? Regards Jon From: Dots [mailto: dots-bounces@ietf.org] On= Behalf Of Konda, Tirumaleswar Reddy Sent: 23 November 2017 13:30 To: Jon Shallow; dots@ietf.org Subject: Re: [Dots] Data Channel ACL Actions From: Konda, Tirumaleswar Reddy Sent: Thursday, November 23, 2017 1:55 PM To: 'Jon Shallow' >; dots@ietf.org Subject: RE: [Dots] Data Channel ACL Actions Hi Jon, Good point, rate-limit makes sense only with allow action (I have the updat= ed the yang model to use "when-stmt" to make rate-limit leaf node valid onl= y when "accept" action is used) augment "/ietf-acl:access-lists/ietf-acl:acl/ietf-acl:aces" + "/ietf-acl:ace/ietf-acl:actions" { description "rate-limit action"; leaf rate-limit { when "/ietf-acl:access-lists/ietf-acl:acl/ietf-acl:aces/ietf-acl= :ace" + "/ietf-acl:actions/ietf-acl:forwarding !=3D 'accept'" { Realized the condition can be simplified, used (when "ietf-acl:forwarding = =3D 'accept'") instead -Tiru description "rate-limit valid only when accept action is used= "; } type decimal64 { fraction-digits 2; } description "rate-limit traffic"; } } Also updated draft to address your other comment related to fragments augment /ietf-acl:access-lists/ietf-acl:acl/ietf-acl:aces/ietf-acl:ace/ie= tf-acl:matches/ietf-acl:ipv4-acl: +--rw fragments? empty augment /ietf-acl:access-lists/ietf-acl:acl/ietf-acl:aces/ietf-acl:ace/ie= tf-acl:matches/ietf-acl:ipv6-acl: +--rw fragments? empty The updated draft is uploaded to https://github.com/dotswg/dots-data-channe= l/blob/master/draft-ietf-dots-data-channel-08.txt Cheers, -Tiru From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Jon Shallow Sent: Wednesday, November 22, 2017 9:30 PM To: Konda, Tirumaleswar Reddy >; dots@ietf.org Subject: Re: [Dots] Data Channel ACL Actions Hi Tiru, I agree that the new actions container with forwarding identityref is not w= orkable for adding in rate-limiting. Forwarding is a mandatory field, so a= nother possibility is that you augment actions (the level above) with rate-= limiting. This then gives the possibility of allow with a rate-limit or dr= op with a rate-limit - a bit messy though. I think augment /ietf-acl:access-lists/ietf-acl:acl/ietf-acl:aces/ietf-acl:ace: +--rw fragments? empty Should (at a minimum) read (as netmod-14 has added in another layer) augment /ietf-acl:access-lists/ietf-acl:acl/ietf-acl:aces/ietf-acl:ace/ie= tf-acl:ipv4-acl: +--rw fragments? empty augment /ietf-acl:access-lists/ietf-acl:acl/ietf-acl:aces/ietf-acl:ace/ie= tf-acl:ipv6-acl: +--rw fragments? empty In Figure 8, you have (ignoring the fact that "actions" should now be "dots= -actions" if your change is accepted) "deny": [null] Which is an empty array. I think it should be "deny": null Regards Jon From: Dots [mailto: dots-bounces@ietf.org] On= Behalf Of Konda, Tirumaleswar Reddy Sent: 22 November 2017 06:26 To: Jon Shallow; dots@ietf.org Subject: Re: [Dots] Data Channel ACL Actions Hi Jon, I don't think the new actions container in draft-ietf-netmod-acl-model-14 c= an be augmented to add a new rate-limit action, I can augment to add a new = dots specific action container. The updated yang model looks as follows (it= will also order the ACLs created by a DOTS client): module: ietf-dots-access-control-list augment /ietf-acl:access-lists: +--rw client-identifier* binary augment /ietf-acl:access-lists/ietf-acl:acl/ietf-acl:aces: +--rw dots-actions +--rw (packet-handling)? +--:(deny) | +--rw deny? empty +--:(permit) | +--rw permit? empty +--:(rate-limit) +--rw rate-limit? decimal64 augment /ietf-acl:access-lists/ietf-acl:acl/ietf-acl:aces/ietf-acl:ace: +--rw fragments? empty augment /ietf-acl:access-lists: +--rw dots-acl-order +--rw acl-set* [set-name type] +--rw set-name -> /ietf-acl:access-lists/acl/acl-name +--rw type -> /ietf-acl:access-lists/acl/acl-type -Tiru From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Jon Shallow Sent: Friday, November 17, 2017 11:21 PM To: dots@ietf.org Subject: [Dots] Data Channel ACL Actions Hi there, draft-ietf-netmod-acl-model-14 has another significant change which affects= DOTS. draft-ietf-netmod-acl-model-13 has the following for ACL actions +--rw actions | +--rw (packet-handling)? | | +--:(deny) | | | +--rw deny? empty | | +--:(permit) | | +--rw permit? empty | +--rw logging? Boolean draft-ietf-netmod-acl-model-14 has updated it with this +--rw actions | {acl-aggregate-stats or interface-acl-aggregate }? | +--rw forwarding identityref | +--rw logging? identityref | +--rw icmp-off? Boolean With different definitions for forwarding. So, I reckon that Figure 8 should look like POST /restconf/data/ietf-dots-access-control-list HTTP/1.1 Host: www.example.com Content-Format: "application/yang.api+json" { "ietf-dots-access-control-list:access-lists": { "client-identifier": [ "dz6pHjaADkaFTbjr0JGBpw", "iAYmCNPmrYoKoqzgFMiobw" ], "acl": [ { "acl-name": "sample-ipv4-acl", "acl-type": "ipv4-acl", "aces": { "ace": [ { "rule-name": "rule1", "matches": { "ipv4-acl": { "source-ipv4-network": "192.0.2.0/24", "destination-ipv4-network": "198.51.100.0/24= " } }, "actions": { "forwarding" : "drop" } } ] } } ] } } Figure 8: POST to install filtering rules With a fair amount of permit =3D allow, deny =3D drop (or should it be reje= ct - I do not think so) and augment updates through the document. Regards Jon --_000_DM5PR16MB17885E1F0E5091929A90FDD9EA210DM5PR16MB1788namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Jon,

 

Its defined as bytes per second (see Se= ction 3.3.1) and the updated draft is using “:forwarding =3D ‘a= ccept’.

 

-Tiru

 

From:<= /span> Jon Shallow [mailto:s= upjps-ietf@jpshallow.com]
Sent: Thursday, November 23, 2017 7:29 PM
To: Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@McAfee.com= >; dots@ietf.org
Subject: RE: [Dots] Data Channel ACL Actions

 

Hi Tiru= ,

&n= bsp;

I think= the rate limiting needs to be defined as being in bytes per second or in b= its per second for clarity.

&n= bsp;

I am a = bit confused about your update – it is not the same as in draft-ietf-= dots-data-channel-08.txt.

Also, s= hould rate-limit only be there when :forwarding =3D ‘accept’, r= ather than a description telling you it is not there in the case of !=3D &#= 8216;accept’?

&n= bsp;

Regards=

&n= bsp;

Jon

&n= bsp;

&n= bsp;

From: Dots [mailto: dots-bounces@ietf.org] On B= ehalf Of Konda, Tirumaleswar Reddy
Sent: 23 November 2017 13:30
To: Jon Shallow; dots@ietf.org<= br> Subject: Re: [Dots] Data Channel ACL Actions

 

From:<= /span> Konda, Tirumaleswar R= eddy
Sent: Thursday, November 23, 2017 1:55 PM
To: 'Jon Shallow' <s= upjps-ietf@jpshallow.com>; dots@ietf.org
Subject: RE: [Dots] Data Channel ACL Actions

 

Hi Jon,

&nbs= p;

Good poin= t, rate-limit makes sense only with allow action (I have the updated the ya= ng model to use “when-stmt” to make rate-limit leaf node valid = only when “accept” action is used)

&nbs= p;

 &nb= sp;  augment "/ietf-acl:access-lists/ietf-acl:acl/ietf-acl:aces&q= uot; +

 &nb= sp;          "/ietf-acl:a= ce/ietf-acl:actions" {

 &nb= sp;      description "rate-limit action"= ;

 &nb= sp;      leaf rate-limit {

 &nb= sp;         when "/ietf-acl:ac= cess-lists/ietf-acl:acl/ietf-acl:aces/ietf-acl:ace" +

 &nb= sp;            =   "/ietf-acl:actions/ietf-acl:forwarding !=3D 'accept'" {

&nbs= p;

Realized = the condition can be simplified, used (when "ietf-acl:forwarding =3D '= accept'") instead

&nbs= p;

-Tiru

&nbs= p;

 &nb= sp;            descr= iption "rate-limit valid only when accept action is used";

 &nb= sp;         }

 &nb= sp;         type decimal64 {

 &nb= sp;           fraction-di= gits 2;

 &nb= sp;         }

 &nb= sp;         description "rate-= limit traffic";

 &nb= sp;     }

 &nb= sp;  }

&nbs= p;

Also upda= ted draft to address your other comment related to fragments

  augment /ietf-acl:a= ccess-lists/ietf-acl:acl/ietf-acl:aces/ietf-acl:ace/ietf-acl:matches/ietf-a= cl:ipv4-acl:

    +--rw fr= agments?   empty

  augment /ietf-acl:access= -lists/ietf-acl:acl/ietf-acl:aces/ietf-acl:ace/ietf-acl:matches/ietf-acl:ip= v6-acl:

    +--rw fr= agments?   empty

&nbs= p;

The updat= ed draft is uploaded to https://github.com/dotswg/dots-data-channel/blob/master/draft-ietf-dots-dat= a-channel-08.txt

&nbs= p;

Cheers,

-Tiru

&nbs= p;

&nbs= p;

From:<= /span> Dots [mailto:dots-bounces@ietf.org] On Behalf Of Jon Shallow
Sent: Wednesday, November 22, 2017 9:30 PM
To: Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@McAfee.com>; dots@ietf.org
Subject: Re: [Dots] Data Channel ACL Actions

 

Hi Tiru= ,

&n= bsp;

I agree= that the new actions container with forwarding identityref is not workable= for adding in rate-limiting.  Forwarding is a mandatory field, so ano= ther possibility is that you augment actions (the level above) with rate-limiting.  This then gives the possibilit= y of allow with a rate-limit or drop with a rate-limit – a bit messy = though.

&n= bsp;

I think=

&n= bsp;

  augment /ietf-acl:access= -lists/ietf-acl:acl/ietf-acl:aces/ietf-acl:ace:

    +--rw fr= agments?   empty

&n= bsp;

Should = (at a minimum) read (as netmod-14 has added in another layer)

&n= bsp;

  augment /ietf-acl:access= -lists/ietf-acl:acl/ietf-acl:aces/ietf-acl:ace/ietf-acl:ipv4-acl:

    +--rw fr= agments?   empty

  augment /ietf-acl:access= -lists/ietf-acl:acl/ietf-acl:aces/ietf-acl:ace/ietf-acl:ipv6-acl:

    +--rw fr= agments?   empty

&n= bsp;

In Figu= re 8, you have (ignoring the fact that “actions” should now be = “dots-actions” if your change is accepted)

“deny”: [null]

Which i= s an empty array.  I think it should be

“deny”: null=

&n= bsp;

Regards=

&n= bsp;

Jon

&n= bsp;

From: Dots [mailto: dots-bounces@ietf.org] On B= ehalf Of Konda, Tirumaleswar Reddy
Sent: 22 November 2017 06:26
To: Jon Shallow; dots@ietf.org<= br> Subject: Re: [Dots] Data Channel ACL Actions

 

Hi Jon,

&nbs= p;

I donR= 17;t think the new actions container in draft-ietf-netmod-acl-model-14 can be augmented to add a new rate-limit = action, I can augment to add a new dots specific action container. The upda= ted yang model looks as follows (it will also order the ACLs created by a DOTS client):

&nbs= p;

module: ietf-dots-access-contro= l-list

  augment /ietf-acl:access= -lists:

    +--rw cl= ient-identifier*   binary

  augment /ietf-acl:access= -lists/ietf-acl:acl/ietf-acl:aces:

    +--rw do= ts-actions

      =  +--rw (packet-handling)?

     &= nbsp;    +--:(deny)

     &= nbsp;    |  +--rw deny?    &nbs= p;    empty

     &= nbsp;    +--:(permit)

     &= nbsp;    |  +--rw permit?    &n= bsp;  empty

     &= nbsp;    +--:(rate-limit)

     &= nbsp;       +--rw rate-limit?  = decimal64

  augment /ietf-acl:access= -lists/ietf-acl:acl/ietf-acl:aces/ietf-acl:ace:

    +--rw fr= agments?   empty

  augment /ietf-acl:access= -lists:

    +--rw do= ts-acl-order

     &= nbsp; +--rw acl-set* [set-name type]

     &= nbsp;    +--rw set-name    -> /ietf-ac= l:access-lists/acl/acl-name

     &= nbsp;    +--rw type       =  -> /ietf-acl:access-lists/acl/acl-type

&nbs= p;

&nbs= p;

-Tiru

&nbs= p;

From:<= /span> Dots [mailto:dots-bounces@ietf.org] On Behalf Of Jon Shallow
Sent: Friday, November 17, 2017 11:21 PM
To: dots@ietf.org
Subject: [Dots] Data Channel ACL Actions

 

Hi there,

 

draft-ietf-netmod-acl-model-14 = has another significant change which affects DOTS.

 

 

draft-ietf-netmod-acl-model-13 = has the following for ACL actions

 

   +--rw actions&= nbsp;           &nbs= p;          

   |  += --rw (packet-handling)?        &nbs= p;        

   |  |&nbs= p; +--:(deny)         &nbs= p;   

   |  |&nbs= p; |  +--rw deny?      empty  &= nbsp;           &nbs= p;      

   |  |&nbs= p; +--:(permit)         &n= bsp;        

   |  |&nbs= p;    +--rw permit?    empty  &= nbsp;           &nbs= p;      

   |  += --rw logging?   Boolean

 

draft-ietf-netmod-acl-model-14 = has updated it with this

 

   +--rw actions<= o:p>

   |   = ;    {acl-aggregate-stats or interface-acl-aggregate }?=

   |  +--rw = forwarding    identityref  

   |  += --rw logging?      identityref  

   |  += --rw icmp-off?     Boolean

 

With different definitions for = forwarding.

 

So, I reckon that Figure 8 shou= ld look like

 

  POST /restconf/data/ietf= -dots-access-control-list HTTP/1.1

  Host: www.exam= ple.com

  Content-Format: "appli= cation/yang.api+json"

  {

   "ietf-dots-ac= cess-control-list:access-lists": {

      = "client-identifier": [

     &= nbsp; "dz6pHjaADkaFTbjr0JGBpw",

     &= nbsp; "iAYmCNPmrYoKoqzgFMiobw"

      = ],

      = "acl": [

      =     {

     &= nbsp;         "acl-name":= "sample-ipv4-acl",

     &= nbsp;         "acl-type": "ipv4-acl",

     &nbs= p;         "aces": {=

     &nbs= p;             = "ace": [

     &= nbsp;           &nbs= p;     {

     &= nbsp;           &nbs= p;         "rule-name": &= quot;rule1",

     &= nbsp;           &nbs= p;         "matches": {

     &= nbsp;           &nbs= p;           "ipv4-a= cl": {

     &= nbsp;           &nbs= p;             = "source-ipv4-network": "192.0.2.0/24",

     &= nbsp;           &nbs= p;             = "destination-ipv4-network": "198.51.100.0/24"

     &= nbsp;           &nbs= p;           }=

     &= nbsp;           &nbs= p;          },

     &= nbsp;           &nbs= p;          "actions"= ;: {

     &= nbsp;           &nbs= p;            &= nbsp; "forwarding" : "drop"= ;

     &= nbsp;           &nbs= p;          }

     &= nbsp;           &nbs= p;      }

     &= nbsp;           &nbs= p;  ]

     &= nbsp;         }

     &= nbsp;    }

      = ]

   }

  }

 

     &= nbsp;           Figure 8:= POST to install filtering rules

 

With a fair amount of permit = =3D allow, deny =3D drop (or should it be reject – I do not think so)= and augment updates through the document.

 

Regards

 

Jon

--_000_DM5PR16MB17885E1F0E5091929A90FDD9EA210DM5PR16MB1788namp_-- From nobody Thu Nov 23 08:43:22 2017 Return-Path: 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 E4A3512EBA8 for ; Thu, 23 Nov 2017 08:43:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=thescout.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 4zvdMga8tGhN for ; Thu, 23 Nov 2017 08:43:19 -0800 (PST) Received: from mx0a-00196b01.pphosted.com (mx0b-00196b01.pphosted.com [67.231.157.166]) (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 0D63912EB9F for ; Thu, 23 Nov 2017 08:43:18 -0800 (PST) Received: from pps.filterd (m0096262.ppops.net [127.0.0.1]) by mx0b-00196b01.pphosted.com (8.16.0.21/8.16.0.21) with SMTP id vANGb7q0010103 for ; Thu, 23 Nov 2017 11:43:17 -0500 Received: from nam01-bn3-obe.outbound.protection.outlook.com (mail-bn3nam01lp0178.outbound.protection.outlook.com [216.32.180.178]) by mx0b-00196b01.pphosted.com with ESMTP id 2ecwmex6tr-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT) for ; Thu, 23 Nov 2017 11:43:16 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=thescout.onmicrosoft.com; s=selector1-arbor-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=1CYmo3ZRDFGsR/ZHQssWK8f1ZhnNBiCx5kf7n1sK0ls=; b=CiTKEWlbMajr2pqqKDOpWLWd/fP6A86ifX2PAWX2jt3LnuosrWXBZQpC6RvKUfL/CIKlq6ASYyoihGVwCjAZysmoApRXyvWyUDNDKKaOsW4mzxU6AgqozgeG//vhYypY5shTHwRJzpoQAMVBdzyQBklCtAj3v2ttUzSLHSx1HV8= Received: from [172.19.254.109] (184.82.227.16) by DM2PR0101MB1038.prod.exchangelabs.com (2a01:111:e400:3c19::27) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.239.5; Thu, 23 Nov 2017 16:43:14 +0000 From: "Roland Dobbins" To: "dots@ietf.org" Date: Thu, 23 Nov 2017 23:42:58 +0700 Message-ID: In-Reply-To: References: <014b01d35fcc$98a8e910$c9fabb30$@jpshallow.com> <012a01d363aa$e4cd0d30$ae672790$@jpshallow.com> <022b01d36463$360d0840$a22718c0$@jpshallow.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.7r5425) X-Originating-IP: [184.82.227.16] X-ClientProxiedBy: HK2PR04CA0055.apcprd04.prod.outlook.com (2603:1096:202:14::23) To DM2PR0101MB1038.prod.exchangelabs.com (2a01:111:e400:3c19::27) X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: aa7d42dc-4019-419e-fb2a-08d532914b0a X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(5600025)(4604075)(2017052603199); SRVR:DM2PR0101MB1038; X-Microsoft-Exchange-Diagnostics: 1; DM2PR0101MB1038; 3:R/quqbvX/uwQLUSAG7/qaKmJMakCRAKUedPM3mMQ5J6YewZhtYYsYN5BWrFue/WBUS1cj1KDBpAoIfFjlemZ9Fy6t1bgXfwe6LJNPQlCI8RQLrkNhXOlhq6C6ojLy6stbbvtiLMe/jwCmuHQE/3rZ3Fe1C2kwQ6rWDHWNRXSvc5Nd9JsLWX2oBoPQoLpaLPXevuJmgPtskVQEvYX32XhPHvoT0wqpLM22KARLndVwtxnZ2srXtjLbDfOnfos7AEK; 25:I13iwZ2YROZzn/ljwWFmNFak/aFqkr0XlLTM3fePQW6KFzox+fMQzvRS5gmZzHQZna7K3teeBHbsO7MPRCSgk0h+O78jvxGUraN+L2FVbL06Bt+oIXwp7ocDs7o8iiekV0VHK5uXUEmi8qbu0AAkjylhH84URjwgUDCWCmvpNLvA6Re0nsiBblFxQDx0T/pTssR1dt781TkTbpD2/xa5TSzGPpaceZC1BWKzNFs7cc3GLZuaZscKqolBxwguAiTG9EqFMI67whWqoffru/i6LLwmh8WJpiRAdJPhRuUGDRG9KJ1ydUBU9pqJXHV8SQgGle/2Zfa///n5Prf4asK7sgfQse8RX9IUaakNx7Yykvk=; 31:iROB3EzJeaxA2aL7uk9pB/aDPAaejI50HE86z6vgXddFceJdpl+fhfsIoDDrWJJYnnYc7uhoU1jNJepM2uXhG4JOj0NoNIWa2bVXeWRxCCCkYbVwtChQ6zKyrT94WamIffqOaJtN5FWPwM/TBEjdu0oj1UL99h/MX5GhbYp4v5knzd+Egy7tVT2qH4Odr4jaEtuhYCfLHwliqQVw+7F/wY4zhTaVaSPK0trC+kciJ7c= X-MS-TrafficTypeDiagnostic: DM2PR0101MB1038: X-Microsoft-Exchange-Diagnostics: 1; DM2PR0101MB1038; 20:c2ezJmkXzOyPPnVEOo/RpZswRATVjiRIrqSYyhmlGGHDodAGyesvamtk65bNLrTSwCK84KZt79HMz1PW+7eDSTRtq/sT66y6v2gaLRArX+8R8pUEFpJF3QDa8Nux7529UP1fCYVYhY2U/ztkdFQWPN+oIQtGZPz5HteRBIvT31+j2/Da5EeHn+VnudualFm2QBJ2L/hO/SBD+IwwKO6E7Zvpo2cxW5Ood+yzAU177ULJ8Q33u/mH+hWGmQMyZFz0UCbCI+8biAZfR/9qJ+Tk9nTQWTT7afBLODBHLm8iixAVaCmQ2MoB2pI9NhJL54QTvPJoyJw4D2MqSTpNVjwbAA==; 4:KtisEekSIdZ/R5JzFL/qdF990fN6D9g+dvCdWCbxeeaFAictFDURP+5OAS6Lid0Egc1/IWFrVZJBeobSR7PKRlsO7d77FqQ3e2HvKyGMz/9+rT2Z/uV0Gk/PzVrgq8Aofr4vkToocRoD8VXbMKUW74DBVY5e5xyUGJFuLODXsQIvLGj04N51nXsD4HoIGb+EB1TTCCxNC8avD/S19T9N9Kqb5LkRV06cb2HpEhY8oXm+EqFPH9Ihkkw2gDHA2VSOeUMY5uHGDuBtcR6T0VS5Mg== X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(8121501046)(5005006)(10201501046)(3002001)(3231022)(93006095)(93001095)(100000703101)(100105400095)(6041248)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123562025)(20161123560025)(20161123564025)(20161123555025)(20161123558100)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:DM2PR0101MB1038; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:DM2PR0101MB1038; X-Forefront-PRVS: 05009853EF X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(6009001)(6049001)(346002)(366004)(376002)(189002)(199003)(24454002)(93886005)(67846002)(5660300001)(86362001)(53936002)(6246003)(25786009)(66066001)(81166006)(68736007)(83716003)(47776003)(316002)(8676002)(53546010)(16586007)(81156014)(105586002)(16576012)(8936002)(5003940100001)(106356001)(1730700003)(2351001)(5640700003)(229853002)(76176999)(2950100002)(2906002)(305945005)(6916009)(189998001)(6666003)(6486002)(36756003)(50986999)(82746002)(16526018)(33656002)(2501003)(478600001)(7736002)(3846002)(50226002)(101416001)(97736004)(6116002)(50466002)(77096006)(52116002); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR0101MB1038; H:[172.19.254.109]; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Received-SPF: None (protection.outlook.com: arbor.net does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; DM2PR0101MB1038; 23:u6DUtdgu9BtZx48nF4TCaSGlbPUxaqOmxeV6Q35?= =?us-ascii?Q?XPfk0j4y049HpDWHcwkJEL7FC5Q3rhmLapt9Qmahzx/YFd2rAe7HlDne3Zuw?= =?us-ascii?Q?iUIxH2iZ4PM5WIapO0H4YkFZHEtAqccyI37SOxarfTQw7nEIYJ5YzRIz9xC5?= =?us-ascii?Q?Y727OnBmQnT1QP8FLQMgyPpS6KhJJfyiVAjiccUdLaukgoc+hv2/cCu+0kJ+?= =?us-ascii?Q?9AGg6a578qjse0fGOT0QwfLsuOn4gtEFX5F12HO/2X+3DbGy9D19+vuvoc/u?= =?us-ascii?Q?smQLFzR5hTOmWrLq+qab7swnU8Bj6kmb9icClAIezQFBCWxC22r4P+Fn7WQ8?= =?us-ascii?Q?fiohEtTlJKrtEZ08mo5UL6eFyCpEC2IxEQ3o/mBEz0QWa4EezrdvGH5oKo9q?= =?us-ascii?Q?u2GzPYB6ePKmz1UN5koshriSYDwmoAgELYxiYNxhVvtASGlcmkMbogU4uvf6?= =?us-ascii?Q?wFnxQqZVbjZBPjuzwaJDVXa/E8Lm2dS00057CWNP45P/XlZ58HtS5ADc3A6B?= =?us-ascii?Q?B4NDTlJ5idnR8MCebY5Ebj6gWoQ5bikfgvuvtyiTZB7WxdqyfAS9y6IjVx79?= =?us-ascii?Q?3HcVkicTLzqPGR96Q07uHN2h5gxz3hzXlA2cNoAXK5Sy3lmBAo0p6P/fMnug?= =?us-ascii?Q?viMK/wG/bClyMTw3dbXIr3FdCK8fNk6VywYofstfNh0pFIHOfWwMQaXltKcs?= =?us-ascii?Q?SsnXIEZjMKMa6QlGf1CzL1TDWBHQwBalcuZWd07AAHglGNBEkF/CgBB3SBVC?= =?us-ascii?Q?i9xMRj2wau9SLsFEhQ1zXpVqNqzElbKuCTmucBYRwrVpnJiRKqxrURDrc4gy?= =?us-ascii?Q?M1XXj2E6n39XNVBg7iI46H81G+ET4Ru+p8dMVCXG84Iwm6y6CS6VpmwHhywr?= =?us-ascii?Q?CYi9z770dTVeT3oJ9uDa8M7sy1a2mXREZXrGd5kPOEvRpmJnxFaNNrbr5dZV?= =?us-ascii?Q?jHHALwkYtkJyW1yOnP+caa1mSnQxurAHcYRE/oE1hTtSTxpi5coF5hcmlT3n?= =?us-ascii?Q?p0yqGlWC/v7Zdk8SqSkkcPCbJ4tNfT0iD2BVgaaI16j9eTArBeuFNNta7HfM?= =?us-ascii?Q?aLi0d6T2o0ueGh9yEWQ1wSiYUUMwFGp13aASzoitGCqKcx2O9Ku4k2fm9Z0M?= =?us-ascii?Q?sH7Q/Wohbp8WcVKPGNMSYhwOaobILV1YRrFn3BEee19WuIMnC93HcbCw4uUI?= =?us-ascii?Q?CojIk0/Cqu6JnvYq0u9tktZJPueAL9ACnQ1OFwfABqDKep2C00N2C1ZRS/M7?= =?us-ascii?Q?uWiAY8E7KswM6b+yThw8FI99JeK1LchMxmWtrsVmox6X/xvvbvET/KFP4q1c?= =?us-ascii?Q?zXZN9QibI2fselQ6FPWUdt//Og/9tj7wb1i36eyi3qLxA?= X-Microsoft-Exchange-Diagnostics: 1; DM2PR0101MB1038; 6:RsAiDZu6FdmkO8QLYvwIlqZugBAB7kq2LwUKbcRVsMKL31l4TGkBt+vMFazOg9tnMPeXq+y1fL6Ezn/xDIxiQHvQKJm2TtP3oaxeYfdLJF3kvqF+x7Mx+oQwfBMqVZGhZ8jotLDKB3b3nFujWxJHxteYiKoRglB9EjJ24ghisjhgAgsgcvkuF9ZwBQbLuhrjBbjMbFr2diS95dUPA2IRvvbLBGIYLmk6hLOVjkKJmLL272vlg5G+GJ5WWRhK8JyOX6JHz+OJym/vprAUGlkKe+P6E0Of21Dyqk9I5aJpGpncXMMcFYqMJs99SF32NdzDkMMW824P4Ut6YoA5l7ObbrQDuN8Lj5Zu6J8oURqJ9QQ=; 5:iu+S+6BSwzf3sG0Tgp5KymzFtlCWjB+ycibaqdfYT7hZcaLMyv+3TjFdQEantEe+t9iCK23o9okU+SpJ0IkUVAYgmz3G7CT5TeWnYa/r8Yk1rMEXhAjYAPojqqLdlJOZjByCCQ8BAx25rE7wwbuL2k8jBbY2aIVqBnqboVXNMo4=; 24:2oJK7kF9XN059QOnvfqHb8mEbv60soGR/JcjYviOwEvVJXAGHGQKdwpk6YU+RIFqGVijEOXozKMfl4b3+XbB2QOBVCZrhgCMkGXTaS8VEAA=; 7:/QfuTjhiu1kYEEcQbEqz/M0nhOdr1GDkv8W8Zd2K0F+Ki6XlTl8HVQEiQpGjV7abWjJ7Wht3yoU5OU316ATUvZWgwhDDOuLuUGpBfhHwGYzU2iNli0dSJqPbZRFIDnay2nqg4EAxPjfZLYxAPor5iMn/SdyPQWg/X3g+UGwKAFT2+wVcjGDi0Zk52iuGry06C2Wl5FMen0fQpXuEMSg64Bx562Mh+bZd9TS93uFhrjNPfKmoSMWEqV4XOQYqJdAD SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: arbor.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 23 Nov 2017 16:43:14.0794 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: aa7d42dc-4019-419e-fb2a-08d532914b0a X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 54f11205-d4aa-4809-bd36-0b542199c5b2 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR0101MB1038 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-11-23_06:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1709140000 definitions=main-1711230226 Archived-At: Subject: Re: [Dots] Data Channel ACL Actions 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Nov 2017 16:43:21 -0000 On 23 Nov 2017, at 21:18, Konda, Tirumaleswar Reddy wrote: > Its defined as bytes per second (see Section 3.3.1) and the updated > draft is using ":forwarding = 'accept'. If we're actually going to do this, it should be bits-per-second, because that's the unit which is universally used in the networking space. Nobody uses bytes-per-second in networking. ----------------------------------- Roland Dobbins From nobody Thu Nov 23 08:53:25 2017 Return-Path: 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 6C08012EBB3 for ; Thu, 23 Nov 2017 08:53:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 i7ezbmCojqDL for ; Thu, 23 Nov 2017 08:53:22 -0800 (PST) Received: from mail.jpshallow.com (mail.jpshallow.com [217.40.240.153]) (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 DA50012EBAC for ; Thu, 23 Nov 2017 08:53:21 -0800 (PST) Received: from [127.0.0.1] (helo=N01332) by mail.jpshallow.com with smtps (TLSv1:ECDHE-RSA-AES256-SHA:256) (Exim 4.89) (envelope-from ) id 1eHukZ-0002XE-RB; Thu, 23 Nov 2017 16:53:19 +0000 From: "Jon Shallow" To: "'Roland Dobbins'" , References: <014b01d35fcc$98a8e910$c9fabb30$@jpshallow.com> <012a01d363aa$e4cd0d30$ae672790$@jpshallow.com> <022b01d36463$360d0840$a22718c0$@jpshallow.com> In-Reply-To: Date: Thu, 23 Nov 2017 16:53:20 -0000 Message-ID: <029301d3647b$9179f400$b46ddc00$@jpshallow.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Content-Language: en-gb Thread-Index: AQLEJeTZWxLmPjSU34IiB1W15cI71AIHigZtAqDAHqMB9N2EVgNXgtN3Alc5I+ECXW+iHwHp8wcmoLwQS4A= Archived-At: Subject: Re: [Dots] Data Channel ACL Actions 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Nov 2017 16:53:23 -0000 ... apart from BGP FlowSpec ..... RFC5575 Traffic-rate: The traffic-rate extended community is a non- transitive extended community across the autonomous-system boundary and uses following extended community encoding: The first two octets carry the 2-octet id, which can be assigned from a 2-byte AS number. When a 4-byte AS number is locally present, the 2 least significant bytes of such an AS number can be used. This value is purely informational and should not be interpreted by the implementation. The remaining 4 octets carry the rate information in IEEE floating point [IEEE.754.1985] format, units being bytes per second. A traffic-rate of 0 should result on all traffic for the particular flow to be discarded. Regards Jon -----Original Message----- From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of Roland Dobbins Sent: 23 November 2017 16:43 To: dots@ietf.org Subject: Re: [Dots] Data Channel ACL Actions On 23 Nov 2017, at 21:18, Konda, Tirumaleswar Reddy wrote: > Its defined as bytes per second (see Section 3.3.1) and the updated > draft is using ":forwarding = 'accept'. If we're actually going to do this, it should be bits-per-second, because that's the unit which is universally used in the networking space. Nobody uses bytes-per-second in networking. ----------------------------------- Roland Dobbins _______________________________________________ Dots mailing list Dots@ietf.org https://www.ietf.org/mailman/listinfo/dots From nobody Thu Nov 23 22:23:59 2017 Return-Path: X-Original-To: dots@ietf.org Delivered-To: dots@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id EE119129AD5; Thu, 23 Nov 2017 22:23:51 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: dots@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.66.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151150463192.9059.15504817058417468407@ietfa.amsl.com> Date: Thu, 23 Nov 2017 22:23:51 -0800 Archived-At: Subject: [Dots] I-D Action: draft-ietf-dots-data-channel-08.txt X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.22 List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Nov 2017 06:23:52 -0000 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 : Distributed Denial-of-Service Open Threat Signaling (DOTS) Data Channel Authors : Tirumaleswar Reddy Mohamed Boucadair Kaname Nishizuka Liang Xia Prashanth Patil Andrew Mortensen Nik Teague Filename : draft-ietf-dots-data-channel-08.txt Pages : 29 Date : 2017-11-23 Abstract: The document specifies a Distributed Denial-of-Service Open Threat Signaling (DOTS) data channel used for bulk exchange of data not easily or appropriately communicated through the DOTS signal channel under attack conditions. This is a companion document to the DOTS signal channel specification. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dots-data-channel/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-dots-data-channel-08 https://datatracker.ietf.org/doc/html/draft-ietf-dots-data-channel-08 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dots-data-channel-08 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/ From nobody Thu Nov 23 22:32:39 2017 Return-Path: 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 43B5A129AE9 for ; Thu, 23 Nov 2017 22:32:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.32 X-Spam-Level: X-Spam-Status: No, score=-4.32 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 0AONPX2Hrzke for ; Thu, 23 Nov 2017 22:32:36 -0800 (PST) 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 992411205F1 for ; Thu, 23 Nov 2017 22:32:36 -0800 (PST) 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=1511505155; 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: x-originating-ip:x-ms-publictraffictype:x-microsoft-exchange-diagnostics: x-ms-exchange-antispam-srfa-diagnostics:x-microsoft-antispam: x-ms-traffictypediagnostic:x-ms-office365-filtering-correlation-id: x-microsoft-antispam-prvs:x-exchange-antispam-report-test: x-exchange-antispam-report-cfa-test:x-forefront-prvs: x-forefront-antispam-report:received-spf:authentication-results: spamdiagnosticoutput:spamdiagnosticmetadata: 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-Transport-CrossTenantHeadersStamped: X-OriginatorOrg:X-NAI-Spam-Flag:X-NAI-Spam-Threshold: X-NAI-Spam-Score:X-NAI-Spam-Version; bh=q CZB3X8Ls+Ddg3PMhzzIOAm/NJctUpTg1aDBwW0V+e Y=; b=XRGeQ0uxWFERtjNPHer0EiL4tTbZuK/obWtw+PU2eXDT YXp4gNkfRto+S8crDJNKGxT1PMR4YJav18LkGDaIK6fCevKIeH Am55IHqnM/4PQOtd9qB99KmFjQKkp7vDQHluAmMZqSPehShNiU Obk0Ruz/mbIrPGW6s9tkJQupzpU= Received: from DNVEXAPP1N05.corpzone.internalzone.com (unknown [10.44.48.89]) by DNVWSMAILOUT1.mcafee.com with smtp id 024a_8939_7628d0ae_43d2_4c3d_b7b5_175f31ee2f38; Fri, 24 Nov 2017 00:32:35 -0600 Received: from DNVEXUSR1N09.corpzone.internalzone.com (10.44.48.82) by DNVEXAPP1N05.corpzone.internalzone.com (10.44.48.89) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Thu, 23 Nov 2017 23:32:34 -0700 Received: from DNVEXAPP1N05.corpzone.internalzone.com (10.44.48.89) by DNVEXUSR1N09.corpzone.internalzone.com (10.44.48.82) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Thu, 23 Nov 2017 23:32:33 -0700 Received: from DNVO365EDGE2.corpzone.internalzone.com (10.44.176.74) by DNVEXAPP1N05.corpzone.internalzone.com (10.44.48.89) with Microsoft SMTP Server (TLS) id 15.0.1347.2 via Frontend Transport; Thu, 23 Nov 2017 23:32:33 -0700 Received: from NAM01-BN3-obe.outbound.protection.outlook.com (10.44.176.240) by edge.mcafee.com (10.44.176.74) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Thu, 23 Nov 2017 23:32:23 -0700 Received: from DM5PR16MB1788.namprd16.prod.outlook.com (10.172.44.144) by DM5PR16MB1788.namprd16.prod.outlook.com (10.172.44.144) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.239.5; Fri, 24 Nov 2017 06:32:22 +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.20.0239.009; Fri, 24 Nov 2017 06:32:22 +0000 From: "Konda, Tirumaleswar Reddy" To: "dots@ietf.org" Thread-Topic: [Dots] I-D Action: draft-ietf-dots-data-channel-08.txt Thread-Index: AQHTZOznz17mr9kA+0KyUjctOf1i1KMjEX9w Date: Fri, 24 Nov 2017 06:32:22 +0000 Message-ID: References: <151150463192.9059.15504817058417468407@ietfa.amsl.com> In-Reply-To: <151150463192.9059.15504817058417468407@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [103.245.47.20] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DM5PR16MB1788; 6:sN5cQ3EH9gy6lDjMpdCMu+cxLNMpsBrpTt4kJpe4AWgmZxNRl6h7Ds/usAViDrB9AG4FhasaZUlyu3y8++YMX8+whn/6jlj4HSJs5SOtfMxhR5Fkx6Lh0po6/BOX5ksU7Wzrb4qOCK6oJUVMhVOz1RG/+SbcfWcddL6t9ie496cVM6/w696pED444SY/nvXMxo5deAbqy47vg1uTLCYvyR+NoWKJG2s0pTxfvbdiL5xL8W7wFT+u2WECvLHRC6UbAKp2V/IfXdb/7361hkWwFIaHdCVeBANGD+tFKLZT7q49c2vnOVjVgNZOi9eMASe5WSm3EFcWsHLs+fKL7VwaqvS3rjGylautqogZU1D3BDQ=; 5:19TqNcydswSqN3wY/0V1fQUHyxXDqgArwFMk9vL1lVmkQUfawufshnVDylpYQGLAOW6RKGY3we9XMsy1SJoTyQBiiHTXpZITn6ofsIdUml94dl+LYY46ZysD2l2WjLu6bwdm55N97XL9xvb47o3mR/NYp1927G/LZixQCOKzspA=; 24:rVqMGYIHW0Phltat7KfYrQUM0gcIEV04eBsTdgz74MtiEKY9oJjnPen1o7nVm6d58tfJ1GHCRw8/M/J/e6jleGaurvSU9XfzVQemioCe1kg=; 7:I7jjAwt+yxNl7+Q8oM0FM+fx7do5rI27O9bJoWY/YfDHyMgGdtIFpaaw0qGWfXBBFa4+Ifunwps88VNBuRxv5yIFJu1NM5zUtZwDv82hAUAImgHkeiUTQYUGE28jmtu9rOQgTMd5K5I658myvhvzEbKkud4ZPoNXc39TCnE3H1qjxkSe0fl5qoa/q1kn0VhzR1qrntkLxacT6/HlKPSvAQqY5nnBKcagr1D2SbItjQKgtG3n/vSLdSz4qX58kGSv x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(2017052603258); SRVR:DM5PR16MB1788; x-ms-traffictypediagnostic: DM5PR16MB1788: x-ms-office365-filtering-correlation-id: 7da505b9-d9dd-40a6-f7ff-08d533051e71 x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(120809045254105); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(2401047)(5005006)(8121501046)(10201501046)(93006095)(93001095)(3231022)(3002001)(6041248)(20161123555025)(20161123564025)(20161123558100)(20161123562025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123560025)(6072148)(201708071742011); SRVR:DM5PR16MB1788; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:DM5PR16MB1788; x-forefront-prvs: 05015EB482 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(39860400002)(376002)(346002)(366004)(199003)(13464003)(377424004)(32952001)(189002)(8676002)(7736002)(3846002)(316002)(81156014)(2501003)(6116002)(102836003)(966005)(14454004)(8936002)(72206003)(2351001)(74316002)(97736004)(1730700003)(7696005)(53546010)(106356001)(305945005)(105586002)(4001150100001)(99286004)(81166006)(25786009)(478600001)(53936002)(33656002)(9686003)(2950100002)(80792005)(6916009)(76176999)(6306002)(2900100001)(3280700002)(77096006)(2906002)(229853002)(5640700003)(54356999)(6506006)(3660700001)(6436002)(189998001)(55016002)(101416001)(50986999)(86362001)(66066001)(230783001)(5660300001)(68736007)(6246003)(85282002); DIR:OUT; SFP:1101; SCL:1; SRVR:DM5PR16MB1788; H:DM5PR16MB1788.namprd16.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: McAfee.com does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=TirumaleswarReddy_Konda@McAfee.com; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 7da505b9-d9dd-40a6-f7ff-08d533051e71 X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Nov 2017 06:32:22.0806 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4943e38c-6dd4-428c-886d-24932bc2d5de X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR16MB1788 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 <6165> : inlines <6186> : streams <1771172> : uri <2539185> Archived-At: Subject: Re: [Dots] I-D Action: draft-ietf-dots-data-channel-08.txt 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Nov 2017 06:32:38 -0000 This revision https://tools.ietf.org/html/draft-ietf-dots-data-channel-08 e= xtends the ACL YANG module to support ordering of ACLs from a DOTS client=20 and aligns with updates to "actions" container in draft-ietf-netmod-acl-mod= el-14 (modified the way "rate-limit" action is used in the "actions" contai= ner). -Tiru > -----Original Message----- > From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of internet- > drafts@ietf.org > Sent: Friday, November 24, 2017 11:54 AM > To: i-d-announce@ietf.org > Cc: dots@ietf.org > Subject: [Dots] I-D Action: draft-ietf-dots-data-channel-08.txt >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. > This draft is a work item of the DDoS Open Threat Signaling WG of the IET= F. >=20 > Title : Distributed Denial-of-Service Open Threat Signa= ling (DOTS) > Data Channel > Authors : Tirumaleswar Reddy > Mohamed Boucadair > Kaname Nishizuka > Liang Xia > Prashanth Patil > Andrew Mortensen > Nik Teague > Filename : draft-ietf-dots-data-channel-08.txt > Pages : 29 > Date : 2017-11-23 >=20 > Abstract: > The document specifies a Distributed Denial-of-Service Open Threat > Signaling (DOTS) data channel used for bulk exchange of data not > easily or appropriately communicated through the DOTS signal channel > under attack conditions. This is a companion document to the DOTS > signal channel specification. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-dots-data-channel/ >=20 > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-dots-data-channel-08 > https://datatracker.ietf.org/doc/html/draft-ietf-dots-data-channel-08 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dots-data-channel-08 >=20 >=20 > Please note that it may take a couple of minutes from the time of submiss= ion > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > Dots mailing list > Dots@ietf.org > https://www.ietf.org/mailman/listinfo/dots From nobody Fri Nov 24 06:03:02 2017 Return-Path: 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 A56C2128656 for ; Fri, 24 Nov 2017 06:03:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.618 X-Spam-Level: X-Spam-Status: No, score=-2.618 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no 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 AeDp6ZgNapLO for ; Fri, 24 Nov 2017 06:02:58 -0800 (PST) Received: from orange.com (mta240.mail.business.static.orange.com [80.12.66.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C83AF1286B1 for ; Fri, 24 Nov 2017 06:02:57 -0800 (PST) Received: from opfedar03.francetelecom.fr (unknown [xx.xx.xx.5]) by opfedar27.francetelecom.fr (ESMTP service) with ESMTP id E7E2660CC9 for ; Fri, 24 Nov 2017 15:02:55 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.43]) by opfedar03.francetelecom.fr (ESMTP service) with ESMTP id CBA6418006B for ; Fri, 24 Nov 2017 15:02:55 +0100 (CET) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM5F.corporate.adroot.infra.ftgroup ([fe80::e172:f13e:8be6:71cc%18]) with mapi id 14.03.0361.001; Fri, 24 Nov 2017 15:02:55 +0100 From: To: "dots@ietf.org" Thread-Topic: signal-channel: Conflict detection and notification Thread-Index: AdNlLOxuTejE5Yr+TiWtd6n7pT4m0Q== Date: Fri, 24 Nov 2017 14:02:55 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93300A07F4E4@OPEXCLILMA3.corporate.adroot.infra.ftgroup> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.2] Content-Type: multipart/alternative; boundary="_000_787AE7BB302AE849A7480A190F8B93300A07F4E4OPEXCLILMA3corp_" MIME-Version: 1.0 Archived-At: Subject: [Dots] signal-channel: Conflict detection and notification 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Nov 2017 14:03:01 -0000 --_000_787AE7BB302AE849A7480A190F8B93300A07F4E4OPEXCLILMA3corp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, As discussed during the last IETF meeting, we are seeking for feedback from= the WG about how to address this requirement: =3D=3D=3D=3D=3D=3D=3D=3D=3D SIG-009 Conflict Detection and Notification: Multiple DOTS clients controlled by a single administrative entity may send conflicting mitigation requests for pools of protected resources as a result of misconfiguration, operator error, or compromised DOTS clients. DOTS servers in the same administrative domain attempting to honor conflicting requests may flap network route or DNS information, degrading the networks attempting to participate in attack response with the DOTS clients. DOTS servers in a single administrative domain SHALL detect such conflicting requests, and SHALL notify the DOTS clients in conflict. The notification SHOULD indicate the nature and scope of the conflict, for example, the overlapping prefix range in a conflicting mitigation request. =3D=3D=3D=3D=3D=3D=3D=3D For example, would it be OK if we leave implementation-specific the criteri= a upon which a dots server relies to consider two requests from two clients= as conflicting, but draft-ietf-dots-signal defines only the procedure to n= otify clients when a conflict is detected? Likewise, would it be OK if the document does not specify which of the conf= licting actions is to be discarded (old, new, all) by the server, but draft= -ietf-dots-signal defines how to inform clients about which action was enfo= rced by the server? Cheers, Med --_000_787AE7BB302AE849A7480A190F8B93300A07F4E4OPEXCLILMA3corp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi all,

 

As discussed during the last IETF meeting, = we are seeking for feedback from the WG about how to address this requireme= nt:

 

=3D=3D=3D=3D=3D=3D=3D=3D=3D

   SIG-00= 9  Conflict Detection and Notification: Multiple DOTS clients

   &= nbsp;  controlled by a single administrative entity may send conflicti= ng

   &= nbsp;  mitigation requests for pools of protected resources as a resul= t

   &= nbsp;  of misconfiguration, operator error, or compromised DOTS client= s.

   &= nbsp;  DOTS servers in the same administrative domain attempting to ho= nor

   &= nbsp;  conflicting requests may flap network route or DNS information,=

   &= nbsp;  degrading the networks attempting to participate in attack=

   &= nbsp;  response with the DOTS clients.  DOTS servers in a single<= o:p>

   &= nbsp;  administrative domain SHALL detect such conflicting requests, a= nd

   &= nbsp;  SHALL notify the DOTS clients in conflict.  The notificati= on

   &= nbsp;  SHOULD indicate the nature and scope of the conflict, for examp= le,

   &= nbsp;  the overlapping prefix range in a conflicting mitigation reques= t.

=3D=3D=3D=3D=3D=3D=3D=3D<= /p>

 

For example, would it be OK if we leave imp= lementation-specific the criteria upon which a dots server relies to consid= er two requests from two clients as conflicting, but draft-ietf-dots-signal defines only the procedure to notify clients wh= en a conflict is detected?

 

Likewise, would it be OK if the document do= es not specify which of the conflicting actions is to be discarded (old, ne= w, all) by the server, but draft-ietf-dots-signal defines how to inform clients about which action was enforced by the serve= r?

 

Cheers,

Med

--_000_787AE7BB302AE849A7480A190F8B93300A07F4E4OPEXCLILMA3corp_-- From nobody Sun Nov 26 22:34:31 2017 Return-Path: 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 BE654126C25 for ; Sun, 26 Nov 2017 22:34:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 jhC-OI686Yfo for ; Sun, 26 Nov 2017 22:34:28 -0800 (PST) Received: from huawei.com (lhrrgout.huawei.com [194.213.3.17]) (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 096C6124B18 for ; Sun, 26 Nov 2017 22:34:28 -0800 (PST) Received: from lhreml707-cah.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id 19D893AB9C499 for ; Mon, 27 Nov 2017 06:34:24 +0000 (GMT) Received: from DGGEML401-HUB.china.huawei.com (10.3.17.32) by lhreml707-cah.china.huawei.com (10.201.108.48) with Microsoft SMTP Server (TLS) id 14.3.361.1; Mon, 27 Nov 2017 06:34:24 +0000 Received: from DGGEML509-MBX.china.huawei.com ([169.254.1.5]) by DGGEML401-HUB.china.huawei.com ([fe80::89ed:853e:30a9:2a79%31]) with mapi id 14.03.0361.001; Mon, 27 Nov 2017 14:34:10 +0800 From: "dongyue (D)" To: Roland Dobbins , dots Thread-Topic: [Dots] draft-ietf-dots-use-cases-09 posted - please review and provide feedback. Thread-Index: AdNnSYckbS1J+O8sQoKCh3MPmTGyng== Date: Mon, 27 Nov 2017 06:34:10 +0000 Message-ID: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.134.147.99] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [Dots] draft-ietf-dots-use-cases-09 posted - please review and provide feedback. 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Nov 2017 06:34:30 -0000 SGVyZSBhcmUgYSBmZXcgcXVlc3Rpb25zL2NvbW1lbnRzIG9uIHRoZSB1c2UgY2FzZXM6DQoNCiog c2VjdGlvbiAzLjEuMS4xLCBwYXJhZ3JhcGggNyAtLSBJbiB0aGlzIHBhcmFncmFwaCwgdGhlIERP VFMgc2VydmVyIHdpbGwgc2VuZCBhIGNvbmZpcm1hdGlvbiB0byB0aGUgZW50ZXJwcmlzZSBJRE1T IERPVFMgY2xpZW50IG9uY2UgdGhlIG1pdGlnYXRpb24gaGFzIGFscmVhZHkgYmVlbiBlbmRlZC4g SG93ZXZlciwgdG8gdGhlIGJlc3Qgb2YgbXkga25vd2xlZGdlLCB0aGlzIGZlYXR1cmUgZG9lcyBu b3QgZXhpc3QgaW4gdGhlIERPVFMgc2lnbmFsIGNoYW5uZWwgZHJhZnQuIFdpbGwgeW91IHN1Z2dl c3QgdGhpcyB0byBiZSBhZGRlZCBpbiB0aGUgc2lnbmFsIGNoYW5uZWw/IA0KDQoqIHNlY3Rpb24g My4xLjIuMS4gLCBwYXJhZ3JhcGggNSAtLSBJbiB0aGlzIHBhcmFncmFwaCB0aGUgdGltZSB0byBs aXZlIChUVEwpIGlzIHByb3Bvc2VkIHRvIGJlIGluY2x1ZGVkIGluIHRoZSBtaXRpZ2F0aW9uIHJl cXVlc3QgYXMgYW4gYWx0ZXJuYXRpdmUgd2F5IHRvIHRlcm1pbmF0ZSB0aGUgbWl0aWdhdGlvbi4g SW4gbXkgb3BpbmlvbiwgdGhlIFRUTCBhcHByb2FjaCBjb3VsZCBiZSB1c2VkIGluIGFsbCB0aGUg RE9UUyB1c2UgY2FzZSBzY2VuYXJpb3MuIEhlbmNlIEkgcmVjb21tZW5kIHRvIGV4cGxhaW4gaXQg aW4gdGhlIHZlcnkgZmlyc3QgdXNlIGNhc2UgaW4gMy4xLjEuMS4sIG90aGVyd2lzZSBpdCBsb29r cyBvbmx5IGJlIHVzZWQgaW4gdXNlIGNhc2VzIHRoYXQgTVNTUCBvZmZlcmluZyB0aGUgbWl0aWdh dGlvbiBzZXJ2aWNlcy4NCg0KKiBzZWN0aW9uIDMuMi4yLiAtLSAgRmlyc3RseSwgdGhpcyB1c2Ug Y2FzZSBwbGFjZWQgdG9vIG11Y2ggZW1waGFzaXMgb24gaG93IHRoZSBERG9TIGF0dGFjayBpcyBk ZXRlY3RlZC4gU2Vjb25kbHksIEkgdGhpbmsgaXQgaXMgYmV0dGVyIHRvIGhhdmUgYSBzY2hlbWF0 aWMgZGlhZ3JhbSAobGlrZSB0aGUgZmlndXJlIGluIHNlY3Rpb24gMy4yLjMpIHRvIHNob3cgdGhl IGFyY2hpdGVjdHVyZSBhbmQgZXhwbGFpbiB0aGUgd29yayBmbG93IGluIGRldGFpbCB0byBzaG93 IGhvdyB0aGUgRE9UUyBwcm90b2NvbCB3b3JrcyBpbiB0aGlzIHNjZW5hcmlvLiAgDQoNCiogc2Vj dGlvbiAzLjIuMi4gLS0gdGhlIGxhc3QgcGFyYWdyYXBoIG9uIHBhZ2UgMTcsIGxpbmU3LCAgICdy YXRoZXIgdGhlbicgLS0+ICdyYXRoZXIgdGhhbicNCiogc2VjdGlvbiAzLjIuMi4gLS0gdGhlIHNl Y29uZCBwYXJhZ3JhcGggb24gcGFnZSAxOCwgbGluZSAxLCAnaXQgbm90aWZpZXMgYXV0b21hdGlj YWxseSBvciB0aGUgSVNQJyAtLT4gJ2l0IG5vdGlmaWVzIGF1dG9tYXRpY2FsbHkgdG8gdGhlIElT UCcNCiogc2VjdGlvbiAzLjIuMi4gLS0gdGhlIGZvdXJ0aCBwYXJhZ3JhcGggb24gcGFnZSAxOCwg bGluZSAzLCAndHJhZmZpYyBwYXR0ZXInIC0tPiAndHJhZmZpYyBwYXR0ZXJuJw0KDQpCZXN0IFJl Z2FyZHMsDQpZdWUNCg0KDQotLS0tLdPKvP7Urbz+LS0tLS0NCreivP7IyzogRG90cyBbbWFpbHRv OmRvdHMtYm91bmNlc0BpZXRmLm9yZ10gtPqx7SBSb2xhbmQgRG9iYmlucw0Kt6LLzcqxvOQ6IDIw MTfE6jEx1MIxM8jVIDY6MzkNCsrVvP7IyzogZG90cyA8ZG90c0BpZXRmLm9yZz4NCtb3zOI6IFtE b3RzXSBkcmFmdC1pZXRmLWRvdHMtdXNlLWNhc2VzLTA5IHBvc3RlZCAtIHBsZWFzZSByZXZpZXcg YW5kIHByb3ZpZGUgZmVlZGJhY2suDQoNCg0KV2UndmUgcmUtb3JnYW5pemVkIHRoZSB1c2UtY2Fz ZXMgc28gdGhhdCBET1RTIGltcGxlbWVudG9ycyB3b24ndCBmZWVsIGNvbXBlbGxlZCB0byByZWFk IHRocm91Z2ggbXVsdGlwbGUgdXNlLWNhc2VzIHdpdGggc2ltaWxhciBET1RTIGNvbW11bmljYXRp b25zIG1vZGVscywgd2hpbGUgYXQgdGhlIHNhbWUgdGltZSByZXRhaW5pbmcgdGhvc2UgdXNlLWNh c2VzIGJlY2F1c2UgdGhleSBjb250YWluIHNpZ25pZmljYW50IHByb2NlZHVyYWwsIG9wZXJhdGlv bmFsLCBhbmQgdG9wb2xvZ2ljYWwgdmFyaWFuY2VzIHdoaWNoIGFyZSBvZiBncmVhdCBzaWduaWZp Y2FuY2UgdG8gbmV0d29yayBvcGVyYXRvcnMgYW5kIGVuZC1jdXN0b21lciBvcmdhbml6YXRpb25z Lg0KDQpUaGUgd29yZGluZyBpbiB0aGUgRE9UUyBjb21tdW5pY2F0aW9ucyBtb2RlbCBsaXN0aW5n cyBhbmQgc2V2ZXJhbCBvZiB0aGUgdXNlLWNhc2VzIGhhcyBiZWVuIHN0cmVhbWxpbmVkLiAgVGhl IHNlY3VyaXR5IGNvbnNpZGVyYXRpb25zIHdlcmUgdXBkYXRlZCB0byBpbmNsdWRlIEREb1MgYXR0 YWNrcy4NCg0KRmluYWxseSwgd2UgcmVhbGx5IG5lZWQgV0cgZmVlZGJhY2sgb24gdGhlIGFwcGxp Y2FiaWxpdHkgb2YgU2VjdGlvbiAzLjIuMiwgJ0hvbWUgTmV0d29yayBERG9TIERldGVjdGlvbiBD b2xsYWJvcmF0aW9uIGZvciBJU1AgbmV0d29yayBtYW5hZ2VtZW50Jy4NCg0KVGhhbmtzIG11Y2gh DQoNCjxodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLWRvdHMtdXNl LWNhc2VzLz4NCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NClJvbGFuZCBE b2JiaW5zIDxyZG9iYmluc0BhcmJvci5uZXQ+DQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fDQpEb3RzIG1haWxpbmcgbGlzdA0KRG90c0BpZXRmLm9yZw0K aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kb3RzDQo= From nobody Sun Nov 26 23:19:27 2017 Return-Path: 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 983EF126E3A for ; Sun, 26 Nov 2017 23:19:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.619 X-Spam-Level: X-Spam-Status: No, score=-2.619 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no 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 QELYNPU4ZBLw for ; Sun, 26 Nov 2017 23:19:25 -0800 (PST) Received: from orange.com (mta136.mail.business.static.orange.com [80.12.70.36]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E7BF61200CF for ; Sun, 26 Nov 2017 23:19:24 -0800 (PST) Received: from opfednr05.francetelecom.fr (unknown [xx.xx.xx.69]) by opfednr24.francetelecom.fr (ESMTP service) with ESMTP id 88C40407BE; Mon, 27 Nov 2017 08:19:23 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.58]) by opfednr05.francetelecom.fr (ESMTP service) with ESMTP id 6404F2006E; Mon, 27 Nov 2017 08:19:23 +0100 (CET) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM33.corporate.adroot.infra.ftgroup ([fe80::3881:fc15:b4b2:9017%19]) with mapi id 14.03.0361.001; Mon, 27 Nov 2017 08:19:23 +0100 From: To: "dongyue (D)" , Roland Dobbins , dots Thread-Topic: [Dots] draft-ietf-dots-use-cases-09 posted - please review and provide feedback. Thread-Index: AdNnSYckbS1J+O8sQoKCh3MPmTGyngABO4lw Date: Mon, 27 Nov 2017 07:19:22 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93300A07FDBD@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.2] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [Dots] draft-ietf-dots-use-cases-09 posted - please review and provide feedback. 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Nov 2017 07:19:26 -0000 RGVhciBZdWUsIA0KDQpQbGVhc2Ugc2VlIGlubGluZS4gDQoNCkNoZWVycywNCk1lZA0KDQo+IC0t LS0tTWVzc2FnZSBkJ29yaWdpbmUtLS0tLQ0KPiBEZcKgOiBEb3RzIFttYWlsdG86ZG90cy1ib3Vu Y2VzQGlldGYub3JnXSBEZSBsYSBwYXJ0IGRlIGRvbmd5dWUgKEQpDQo+IEVudm95w6nCoDogbHVu ZGkgMjcgbm92ZW1icmUgMjAxNyAwNzozNA0KPiDDgMKgOiBSb2xhbmQgRG9iYmluczsgZG90cw0K PiBPYmpldMKgOiBSZTogW0RvdHNdIGRyYWZ0LWlldGYtZG90cy11c2UtY2FzZXMtMDkgcG9zdGVk IC0gcGxlYXNlIHJldmlldyBhbmQNCj4gcHJvdmlkZSBmZWVkYmFjay4NCj4gDQo+IEhlcmUgYXJl IGEgZmV3IHF1ZXN0aW9ucy9jb21tZW50cyBvbiB0aGUgdXNlIGNhc2VzOg0KPiANCj4gKiBzZWN0 aW9uIDMuMS4xLjEsIHBhcmFncmFwaCA3IC0tIEluIHRoaXMgcGFyYWdyYXBoLCB0aGUgRE9UUyBz ZXJ2ZXIgd2lsbA0KPiBzZW5kIGEgY29uZmlybWF0aW9uIHRvIHRoZSBlbnRlcnByaXNlIElETVMg RE9UUyBjbGllbnQgb25jZSB0aGUgbWl0aWdhdGlvbg0KPiBoYXMgYWxyZWFkeSBiZWVuIGVuZGVk LiBIb3dldmVyLCB0byB0aGUgYmVzdCBvZiBteSBrbm93bGVkZ2UsIHRoaXMgZmVhdHVyZQ0KPiBk b2VzIG5vdCBleGlzdCBpbiB0aGUgRE9UUyBzaWduYWwgY2hhbm5lbCBkcmFmdC4gDQoNCltNZWRd IEEgZG90cyBjbGllbnQgY2FuIHJldHJpZXZlIHRoZSBzdGF0dXMgb2YgYW4gb25nb2luZyBtaXRp Z2F0aW9uIHJlcXVlc3QgYnkgcGVyaW9kaWNhbGx5IHBva2luZyB0aGUgc2VydmVyIG9yIGJ5IHN1 YnNjcmliaW5nIHRvIHVuc29saWNpdGVkIG5vdGlmaWNhdGlvbnMuIEJlbG93IGFuIGV4YW1wbGUg ZnJvbSB0aGUgc2lnbmFsLWNoYW5uZWwgZHJhZnQgdG8gaWxsdXN0cmF0ZSB0aGlzICBiZWhhdmlv cjogDQoNCiAgICAgICAgICAgICAgICAgICAgICAgRE9UUyBDbGllbnQgICAgICAgICAgICBET1RT IFNlcnZlcg0KICAgICAgICAgICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIHwNCiAgICAgICAgICAgICAgICAgICAgICAgICAgfCAgR0VUIC88bWl0aWdhdGlv bi1pZCBudW1iZXI+ICB8DQogICAgICAgICAgICAgICAgICAgICAgICAgIHwgIFRva2VuOiAweDRh ICAgICAgICAgICAgICAgICAgfCAgIFJlZ2lzdHJhdGlvbg0KICAgICAgICAgICAgICAgICAgICAg ICAgICB8ICBPYnNlcnZlOiAwICAgICAgICAgICAgICAgICAgIHwNCiAgICAgICAgICAgICAgICAg ICAgICAgICAgKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLT58DQogICAgICAgICAgICAg ICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfA0KICAgICAgICAg ICAgICAgICAgICAgICAgICB8ICAyLjA1IENvbnRlbnQgICAgICAgICAgICAgICAgIHwNCiAgICAg ICAgICAgICAgICAgICAgICAgICAgfCAgVG9rZW46IDB4NGEgICAgICAgICAgICAgICAgICB8ICAg Tm90aWZpY2F0aW9uIG9mDQogICAgICAgICAgICAgICAgICAgICAgICAgIHwgIE9ic2VydmU6IDEy ICAgICAgICAgICAgICAgICAgfCAgIHRoZSBjdXJyZW50IHN0YXRlDQogICAgICAgICAgICAgICAg ICAgICAgICAgIHwgIHN0YXR1czogIm1pdGlnYXRpb24gICAgICAgICAgfA0KICAgICAgICAgICAg ICAgICAgICAgICAgICB8ICAgICAgICAgIGluIHByb2dyZXNzIiAgICAgICAgIHwNCiAgICAgICAg ICAgICAgICAgICAgICAgICAgfDwtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rDQogICAg ICAgICAgICAgICAgICAgICAgICAgIHwgIDIuMDUgQ29udGVudCAgICAgICAgICAgICAgICAgfA0K ICAgICAgICAgICAgICAgICAgICAgICAgICB8ICBUb2tlbjogMHg0YSAgICAgICAgICAgICAgICAg IHwgICBOb3RpZmljYXRpb24gdXBvbg0KICAgICAgICAgICAgICAgICAgICAgICAgICB8ICBPYnNl cnZlOiA0NCAgICAgICAgICAgICAgICAgIHwgICAgYSBzdGF0ZSBjaGFuZ2UNCiAgICAgICAgICAg ICAgICAgICAgICAgICAgfCAgc3RhdHVzOiAibWl0aWdhdGlvbiAgICAgICAgICB8DQogICAgICAg ICAgICAgICAgICAgICAgICAgIHwgICAgICAgICAgY29tcGxldGUiICAgICAgICAgICAgfA0KICAg ICAgICAgICAgICAgICAgICAgICAgICB8PC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSsN CiAgICAgICAgICAgICAgICAgICAgICAgICAgfCAgMi4wNSBDb250ZW50ICAgICAgICAgICAgICAg ICB8DQogICAgICAgICAgICAgICAgICAgICAgICAgIHwgIFRva2VuOiAweDRhICAgICAgICAgICAg ICAgICAgfCAgIE5vdGlmaWNhdGlvbiB1cG9uDQogICAgICAgICAgICAgICAgICAgICAgICAgIHwg IE9ic2VydmU6IDYwICAgICAgICAgICAgICAgICAgfCAgIGEgc3RhdGUgY2hhbmdlDQogICAgICAg ICAgICAgICAgICAgICAgICAgIHwgIHN0YXR1czogImF0dGFjayBzdG9wcGVkIiAgICAgfA0KICAg ICAgICAgICAgICAgICAgICAgICAgICB8PC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSsN CiAgICAgICAgICAgICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICB8DQoNCg0KV2lsbCB5b3Ugc3VnZ2VzdCB0aGlzIHRvDQo+IGJlIGFkZGVkIGluIHRoZSBzaWdu YWwgY2hhbm5lbD8NCj4gDQo+ICogc2VjdGlvbiAzLjEuMi4xLiAsIHBhcmFncmFwaCA1IC0tIElu IHRoaXMgcGFyYWdyYXBoIHRoZSB0aW1lIHRvIGxpdmUNCj4gKFRUTCkgaXMgcHJvcG9zZWQgdG8g YmUgaW5jbHVkZWQgaW4gdGhlIG1pdGlnYXRpb24gcmVxdWVzdCBhcyBhbg0KPiBhbHRlcm5hdGl2 ZSB3YXkgdG8gdGVybWluYXRlIHRoZSBtaXRpZ2F0aW9uLiBJbiBteSBvcGluaW9uLCB0aGUgVFRM DQo+IGFwcHJvYWNoIGNvdWxkIGJlIHVzZWQgaW4gYWxsIHRoZSBET1RTIHVzZSBjYXNlIHNjZW5h cmlvcy4gSGVuY2UgSQ0KPiByZWNvbW1lbmQgdG8gZXhwbGFpbiBpdCBpbiB0aGUgdmVyeSBmaXJz dCB1c2UgY2FzZSBpbiAzLjEuMS4xLiwgb3RoZXJ3aXNlDQo+IGl0IGxvb2tzIG9ubHkgYmUgdXNl ZCBpbiB1c2UgY2FzZXMgdGhhdCBNU1NQIG9mZmVyaW5nIHRoZSBtaXRpZ2F0aW9uDQo+IHNlcnZp Y2VzLg0KPiANCj4gKiBzZWN0aW9uIDMuMi4yLiAtLSAgRmlyc3RseSwgdGhpcyB1c2UgY2FzZSBw bGFjZWQgdG9vIG11Y2ggZW1waGFzaXMgb24NCj4gaG93IHRoZSBERG9TIGF0dGFjayBpcyBkZXRl Y3RlZC4gU2Vjb25kbHksIEkgdGhpbmsgaXQgaXMgYmV0dGVyIHRvIGhhdmUgYQ0KPiBzY2hlbWF0 aWMgZGlhZ3JhbSAobGlrZSB0aGUgZmlndXJlIGluIHNlY3Rpb24gMy4yLjMpIHRvIHNob3cgdGhl DQo+IGFyY2hpdGVjdHVyZSBhbmQgZXhwbGFpbiB0aGUgd29yayBmbG93IGluIGRldGFpbCB0byBz aG93IGhvdyB0aGUgRE9UUw0KPiBwcm90b2NvbCB3b3JrcyBpbiB0aGlzIHNjZW5hcmlvLg0KPiAN Cj4gKiBzZWN0aW9uIDMuMi4yLiAtLSB0aGUgbGFzdCBwYXJhZ3JhcGggb24gcGFnZSAxNywgbGlu ZTcsICAgJ3JhdGhlciB0aGVuJw0KPiAtLT4gJ3JhdGhlciB0aGFuJw0KPiAqIHNlY3Rpb24gMy4y LjIuIC0tIHRoZSBzZWNvbmQgcGFyYWdyYXBoIG9uIHBhZ2UgMTgsIGxpbmUgMSwgJ2l0IG5vdGlm aWVzDQo+IGF1dG9tYXRpY2FsbHkgb3IgdGhlIElTUCcgLS0+ICdpdCBub3RpZmllcyBhdXRvbWF0 aWNhbGx5IHRvIHRoZSBJU1AnDQo+ICogc2VjdGlvbiAzLjIuMi4gLS0gdGhlIGZvdXJ0aCBwYXJh Z3JhcGggb24gcGFnZSAxOCwgbGluZSAzLCAndHJhZmZpYw0KPiBwYXR0ZXInIC0tPiAndHJhZmZp YyBwYXR0ZXJuJw0KPiANCj4gQmVzdCBSZWdhcmRzLA0KPiBZdWUNCj4gDQo+IA0KPiAtLS0tLemC ruS7tuWOn+S7ti0tLS0tDQo+IOWPkeS7tuS6ujogRG90cyBbbWFpbHRvOmRvdHMtYm91bmNlc0Bp ZXRmLm9yZ10g5Luj6KGoIFJvbGFuZCBEb2JiaW5zDQo+IOWPkemAgeaXtumXtDogMjAxN+W5tDEx 5pyIMTPml6UgNjozOQ0KPiDmlLbku7bkuro6IGRvdHMgPGRvdHNAaWV0Zi5vcmc+DQo+IOS4u+mi mDogW0RvdHNdIGRyYWZ0LWlldGYtZG90cy11c2UtY2FzZXMtMDkgcG9zdGVkIC0gcGxlYXNlIHJl dmlldyBhbmQNCj4gcHJvdmlkZSBmZWVkYmFjay4NCj4gDQo+IA0KPiBXZSd2ZSByZS1vcmdhbml6 ZWQgdGhlIHVzZS1jYXNlcyBzbyB0aGF0IERPVFMgaW1wbGVtZW50b3JzIHdvbid0IGZlZWwNCj4g Y29tcGVsbGVkIHRvIHJlYWQgdGhyb3VnaCBtdWx0aXBsZSB1c2UtY2FzZXMgd2l0aCBzaW1pbGFy IERPVFMNCj4gY29tbXVuaWNhdGlvbnMgbW9kZWxzLCB3aGlsZSBhdCB0aGUgc2FtZSB0aW1lIHJl dGFpbmluZyB0aG9zZSB1c2UtY2FzZXMNCj4gYmVjYXVzZSB0aGV5IGNvbnRhaW4gc2lnbmlmaWNh bnQgcHJvY2VkdXJhbCwgb3BlcmF0aW9uYWwsIGFuZCB0b3BvbG9naWNhbA0KPiB2YXJpYW5jZXMg d2hpY2ggYXJlIG9mIGdyZWF0IHNpZ25pZmljYW5jZSB0byBuZXR3b3JrIG9wZXJhdG9ycyBhbmQg ZW5kLQ0KPiBjdXN0b21lciBvcmdhbml6YXRpb25zLg0KPiANCj4gVGhlIHdvcmRpbmcgaW4gdGhl IERPVFMgY29tbXVuaWNhdGlvbnMgbW9kZWwgbGlzdGluZ3MgYW5kIHNldmVyYWwgb2YgdGhlDQo+ IHVzZS1jYXNlcyBoYXMgYmVlbiBzdHJlYW1saW5lZC4gIFRoZSBzZWN1cml0eSBjb25zaWRlcmF0 aW9ucyB3ZXJlIHVwZGF0ZWQNCj4gdG8gaW5jbHVkZSBERG9TIGF0dGFja3MuDQo+IA0KPiBGaW5h bGx5LCB3ZSByZWFsbHkgbmVlZCBXRyBmZWVkYmFjayBvbiB0aGUgYXBwbGljYWJpbGl0eSBvZiBT ZWN0aW9uIDMuMi4yLA0KPiAnSG9tZSBOZXR3b3JrIEREb1MgRGV0ZWN0aW9uIENvbGxhYm9yYXRp b24gZm9yIElTUCBuZXR3b3JrIG1hbmFnZW1lbnQnLg0KPiANCj4gVGhhbmtzIG11Y2ghDQo+IA0K PiA8aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1kb3RzLXVzZS1j YXNlcy8+DQo+IA0KPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiBSb2xh bmQgRG9iYmlucyA8cmRvYmJpbnNAYXJib3IubmV0Pg0KPiANCj4gX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gRG90cyBtYWlsaW5nIGxpc3QNCj4gRG90 c0BpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RvdHMN Cj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gRG90 cyBtYWlsaW5nIGxpc3QNCj4gRG90c0BpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL2RvdHMNCg== From nobody Mon Nov 27 19:22:59 2017 Return-Path: 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 7FDAE126C22 for ; Mon, 27 Nov 2017 19:22:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 Xp4iypzrN0Qx for ; Mon, 27 Nov 2017 19:22:56 -0800 (PST) Received: from huawei.com (lhrrgout.huawei.com [194.213.3.17]) (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 5A8401201F2 for ; Mon, 27 Nov 2017 19:22:56 -0800 (PST) Received: from lhreml707-cah.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id 143B59AD35492 for ; Tue, 28 Nov 2017 03:22:53 +0000 (GMT) Received: from DGGEML403-HUB.china.huawei.com (10.3.17.33) by lhreml707-cah.china.huawei.com (10.201.108.48) with Microsoft SMTP Server (TLS) id 14.3.361.1; Tue, 28 Nov 2017 03:22:53 +0000 Received: from DGGEML509-MBX.china.huawei.com ([169.254.1.5]) by DGGEML403-HUB.china.huawei.com ([fe80::74d9:c659:fbec:21fa%31]) with mapi id 14.03.0361.001; Tue, 28 Nov 2017 11:22:50 +0800 From: "dongyue (D)" To: "mohamed.boucadair@orange.com" , "Roland Dobbins" , dots Thread-Topic: [Dots] draft-ietf-dots-use-cases-09 posted - please review and provide feedback. Thread-Index: AdNnSYckbS1J+O8sQoKCh3MPmTGyngABO4lwACY+4NA= Date: Tue, 28 Nov 2017 03:22:49 +0000 Message-ID: References: <787AE7BB302AE849A7480A190F8B93300A07FDBD@OPEXCLILMA3.corporate.adroot.infra.ftgroup> In-Reply-To: <787AE7BB302AE849A7480A190F8B93300A07FDBD@OPEXCLILMA3.corporate.adroot.infra.ftgroup> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.134.147.99] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: [Dots] =?utf-8?b?562U5aSNOiAgZHJhZnQtaWV0Zi1kb3RzLXVzZS1jYXNlcy0w?= =?utf-8?q?9_posted_-_please_review_and_provide_feedback=2E?= 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Nov 2017 03:22:58 -0000 SGkgTWVkLA0KDQpUaGFua3MgZm9yIHlvdXIgcmVwbHkhDQoNCkFjY29yZGluZyB0byB0aGUgdXNl IGNhc2UsIGZpcnN0bHkgd2hlbiBhIGNsaWVudCByZXF1ZXN0IHRvIHRlcm1pbmF0ZSBhIG1pdGln YXRpb24sIHRoZSBzZXJ2ZXIgaGFzIHRvIHNlbmQgYSBzdGF0dXMgbWVzc2FnZSAobWl0aWdhdGlv biBpcyBhY3RpdmUgYnV0IHRlcm1pbmF0aW5nLCBsaXN0ZWQgaW4gdGhlIHRhYmxlIGluIHBhZ2Ug MjggaW4gc2lnbmFsIGNoYW5uZWwgZHJhZnQpLiBUaGVuLCB0aGUgbWl0aWdhdGlvbiBpcyBleGFj dGx5IHRlcm1pbmF0ZWQgYnkgdGhlIG1pdGlnYXRvciwgdGhlIHNldmVyIHJlcXVpcmVzIHRvIHNl bmQgYW5vdGhlciBzdGF0dXMgbWVzc2FnZSAobm90IGxpc3RlZCBpbiB0aGUgdGFibGUpIHRvIGNv bmZpcm0gdGhlIHRlcm1pbmF0aW9uLiBJIGp1c3QgZW5xdWlyZXMgaWYgdGhlIHNlY29uZCBzdGFn ZSBzaG91bGQgYmUgZXhwbGFpbmVkIGluIHRoZSBzaWduYWwgY2hhbm5lbCBkcmFmdC4gIA0KRm9y IHRoZSBzdWJzY3JpYmluZyBhcHByb2FjaCwgdGhlIHNlcnZlciB3aWxsIHNlbmQgdGhlIG5vdGlm aWNhdGlvbnMgdXBvbiB0aGUgc3RhdHVzIGNoYW5nZS4gVGhpcyBhcHByb2FjaCBpcyBvay4NCkZv ciBhbm90aGVyIGFwcHJvYWNoLCBuYW1lbHkgdGhlIGNsaWVudCBzZW5kaW5nIHN0YXR1cyByZXF1 ZXN0IHBlcmlvZGljYWxseSwgdGhlIHRpbWUgdG8gc3RvcCBzZW5kaW5nIHRoZSBzdGF0dXMgcmVx dWVzdCBpcyBhbm90aGVyIGlzc3VlIHRoYXQgbmVlZCB0byBiZSBkZXRlcm1pbmVkIGJ5IHRoZSBt aXRpZ2F0aW9uIHRlcm1pbmF0aW9uIHN0YXR1cyBtZXNzYWdlLiBCZWNhdXNlIEkgdGhpbmsgaXQg aXMgdW5uZWNlc3NhcnkgdG8gYWx3YXlzIHNlbmQgdGhlIHN0YXR1cyByZXF1ZXN0IGlmIHRoZSBt aXRpZ2F0aW9uIGlzIHN0b3BwZWQuIA0KDQpCZXN0IFJlZ2FyZHMsDQpZdWUNCg0KLS0tLS3pgq7k u7bljp/ku7YtLS0tLQ0K5Y+R5Lu25Lq6OiBtb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tIFtt YWlsdG86bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbV0gDQrlj5HpgIHml7bpl7Q6IDIwMTfl ubQxMeaciDI35pelIDE1OjE5DQrmlLbku7bkuro6IGRvbmd5dWUgKEQpIDxkb25neXVlNkBodWF3 ZWkuY29tPjsgUm9sYW5kIERvYmJpbnMgPHJkb2JiaW5zQGFyYm9yLm5ldD47IGRvdHMgPGRvdHNA aWV0Zi5vcmc+DQrkuLvpopg6IFJFOiBbRG90c10gZHJhZnQtaWV0Zi1kb3RzLXVzZS1jYXNlcy0w OSBwb3N0ZWQgLSBwbGVhc2UgcmV2aWV3IGFuZCBwcm92aWRlIGZlZWRiYWNrLg0KDQpEZWFyIFl1 ZSwgDQoNClBsZWFzZSBzZWUgaW5saW5lLiANCg0KQ2hlZXJzLA0KTWVkDQoNCj4gLS0tLS1NZXNz YWdlIGQnb3JpZ2luZS0tLS0tDQo+IERlwqA6IERvdHMgW21haWx0bzpkb3RzLWJvdW5jZXNAaWV0 Zi5vcmddIERlIGxhIHBhcnQgZGUgZG9uZ3l1ZSAoRCkgDQo+IEVudm95w6nCoDogbHVuZGkgMjcg bm92ZW1icmUgMjAxNyAwNzozNCDDgMKgOiBSb2xhbmQgRG9iYmluczsgZG90cyBPYmpldMKgOiAN Cj4gUmU6IFtEb3RzXSBkcmFmdC1pZXRmLWRvdHMtdXNlLWNhc2VzLTA5IHBvc3RlZCAtIHBsZWFz ZSByZXZpZXcgYW5kIA0KPiBwcm92aWRlIGZlZWRiYWNrLg0KPiANCj4gSGVyZSBhcmUgYSBmZXcg cXVlc3Rpb25zL2NvbW1lbnRzIG9uIHRoZSB1c2UgY2FzZXM6DQo+IA0KPiAqIHNlY3Rpb24gMy4x LjEuMSwgcGFyYWdyYXBoIDcgLS0gSW4gdGhpcyBwYXJhZ3JhcGgsIHRoZSBET1RTIHNlcnZlciAN Cj4gd2lsbCBzZW5kIGEgY29uZmlybWF0aW9uIHRvIHRoZSBlbnRlcnByaXNlIElETVMgRE9UUyBj bGllbnQgb25jZSB0aGUgDQo+IG1pdGlnYXRpb24gaGFzIGFscmVhZHkgYmVlbiBlbmRlZC4gSG93 ZXZlciwgdG8gdGhlIGJlc3Qgb2YgbXkgDQo+IGtub3dsZWRnZSwgdGhpcyBmZWF0dXJlIGRvZXMg bm90IGV4aXN0IGluIHRoZSBET1RTIHNpZ25hbCBjaGFubmVsIGRyYWZ0Lg0KDQpbTWVkXSBBIGRv dHMgY2xpZW50IGNhbiByZXRyaWV2ZSB0aGUgc3RhdHVzIG9mIGFuIG9uZ29pbmcgbWl0aWdhdGlv biByZXF1ZXN0IGJ5IHBlcmlvZGljYWxseSBwb2tpbmcgdGhlIHNlcnZlciBvciBieSBzdWJzY3Jp YmluZyB0byB1bnNvbGljaXRlZCBub3RpZmljYXRpb25zLiBCZWxvdyBhbiBleGFtcGxlIGZyb20g dGhlIHNpZ25hbC1jaGFubmVsIGRyYWZ0IHRvIGlsbHVzdHJhdGUgdGhpcyAgYmVoYXZpb3I6IA0K DQogICAgICAgICAgICAgICAgICAgICAgIERPVFMgQ2xpZW50ICAgICAgICAgICAgRE9UUyBTZXJ2 ZXINCiAgICAgICAgICAgICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICB8DQogICAgICAgICAgICAgICAgICAgICAgICAgIHwgIEdFVCAvPG1pdGlnYXRpb24taWQg bnVtYmVyPiAgfA0KICAgICAgICAgICAgICAgICAgICAgICAgICB8ICBUb2tlbjogMHg0YSAgICAg ICAgICAgICAgICAgIHwgICBSZWdpc3RyYXRpb24NCiAgICAgICAgICAgICAgICAgICAgICAgICAg fCAgT2JzZXJ2ZTogMCAgICAgICAgICAgICAgICAgICB8DQogICAgICAgICAgICAgICAgICAgICAg ICAgICstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0+fA0KICAgICAgICAgICAgICAgICAg ICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwNCiAgICAgICAgICAgICAg ICAgICAgICAgICAgfCAgMi4wNSBDb250ZW50ICAgICAgICAgICAgICAgICB8DQogICAgICAgICAg ICAgICAgICAgICAgICAgIHwgIFRva2VuOiAweDRhICAgICAgICAgICAgICAgICAgfCAgIE5vdGlm aWNhdGlvbiBvZg0KICAgICAgICAgICAgICAgICAgICAgICAgICB8ICBPYnNlcnZlOiAxMiAgICAg ICAgICAgICAgICAgIHwgICB0aGUgY3VycmVudCBzdGF0ZQ0KICAgICAgICAgICAgICAgICAgICAg ICAgICB8ICBzdGF0dXM6ICJtaXRpZ2F0aW9uICAgICAgICAgIHwNCiAgICAgICAgICAgICAgICAg ICAgICAgICAgfCAgICAgICAgICBpbiBwcm9ncmVzcyIgICAgICAgICB8DQogICAgICAgICAgICAg ICAgICAgICAgICAgIHw8LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKw0KICAgICAgICAg ICAgICAgICAgICAgICAgICB8ICAyLjA1IENvbnRlbnQgICAgICAgICAgICAgICAgIHwNCiAgICAg ICAgICAgICAgICAgICAgICAgICAgfCAgVG9rZW46IDB4NGEgICAgICAgICAgICAgICAgICB8ICAg Tm90aWZpY2F0aW9uIHVwb24NCiAgICAgICAgICAgICAgICAgICAgICAgICAgfCAgT2JzZXJ2ZTog NDQgICAgICAgICAgICAgICAgICB8ICAgIGEgc3RhdGUgY2hhbmdlDQogICAgICAgICAgICAgICAg ICAgICAgICAgIHwgIHN0YXR1czogIm1pdGlnYXRpb24gICAgICAgICAgfA0KICAgICAgICAgICAg ICAgICAgICAgICAgICB8ICAgICAgICAgIGNvbXBsZXRlIiAgICAgICAgICAgIHwNCiAgICAgICAg ICAgICAgICAgICAgICAgICAgfDwtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rDQogICAg ICAgICAgICAgICAgICAgICAgICAgIHwgIDIuMDUgQ29udGVudCAgICAgICAgICAgICAgICAgfA0K ICAgICAgICAgICAgICAgICAgICAgICAgICB8ICBUb2tlbjogMHg0YSAgICAgICAgICAgICAgICAg IHwgICBOb3RpZmljYXRpb24gdXBvbg0KICAgICAgICAgICAgICAgICAgICAgICAgICB8ICBPYnNl cnZlOiA2MCAgICAgICAgICAgICAgICAgIHwgICBhIHN0YXRlIGNoYW5nZQ0KICAgICAgICAgICAg ICAgICAgICAgICAgICB8ICBzdGF0dXM6ICJhdHRhY2sgc3RvcHBlZCIgICAgIHwNCiAgICAgICAg ICAgICAgICAgICAgICAgICAgfDwtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rDQogICAg ICAgICAgICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfA0K DQoNCldpbGwgeW91IHN1Z2dlc3QgdGhpcyB0bw0KPiBiZSBhZGRlZCBpbiB0aGUgc2lnbmFsIGNo YW5uZWw/DQo+IA0KPiAqIHNlY3Rpb24gMy4xLjIuMS4gLCBwYXJhZ3JhcGggNSAtLSBJbiB0aGlz IHBhcmFncmFwaCB0aGUgdGltZSB0byBsaXZlDQo+IChUVEwpIGlzIHByb3Bvc2VkIHRvIGJlIGlu Y2x1ZGVkIGluIHRoZSBtaXRpZ2F0aW9uIHJlcXVlc3QgYXMgYW4gDQo+IGFsdGVybmF0aXZlIHdh eSB0byB0ZXJtaW5hdGUgdGhlIG1pdGlnYXRpb24uIEluIG15IG9waW5pb24sIHRoZSBUVEwgDQo+ IGFwcHJvYWNoIGNvdWxkIGJlIHVzZWQgaW4gYWxsIHRoZSBET1RTIHVzZSBjYXNlIHNjZW5hcmlv cy4gSGVuY2UgSSANCj4gcmVjb21tZW5kIHRvIGV4cGxhaW4gaXQgaW4gdGhlIHZlcnkgZmlyc3Qg dXNlIGNhc2UgaW4gMy4xLjEuMS4sIA0KPiBvdGhlcndpc2UgaXQgbG9va3Mgb25seSBiZSB1c2Vk IGluIHVzZSBjYXNlcyB0aGF0IE1TU1Agb2ZmZXJpbmcgdGhlIA0KPiBtaXRpZ2F0aW9uIHNlcnZp Y2VzLg0KPiANCj4gKiBzZWN0aW9uIDMuMi4yLiAtLSAgRmlyc3RseSwgdGhpcyB1c2UgY2FzZSBw bGFjZWQgdG9vIG11Y2ggZW1waGFzaXMgDQo+IG9uIGhvdyB0aGUgRERvUyBhdHRhY2sgaXMgZGV0 ZWN0ZWQuIFNlY29uZGx5LCBJIHRoaW5rIGl0IGlzIGJldHRlciB0byANCj4gaGF2ZSBhIHNjaGVt YXRpYyBkaWFncmFtIChsaWtlIHRoZSBmaWd1cmUgaW4gc2VjdGlvbiAzLjIuMykgdG8gc2hvdyAN Cj4gdGhlIGFyY2hpdGVjdHVyZSBhbmQgZXhwbGFpbiB0aGUgd29yayBmbG93IGluIGRldGFpbCB0 byBzaG93IGhvdyB0aGUgDQo+IERPVFMgcHJvdG9jb2wgd29ya3MgaW4gdGhpcyBzY2VuYXJpby4N Cj4gDQo+ICogc2VjdGlvbiAzLjIuMi4gLS0gdGhlIGxhc3QgcGFyYWdyYXBoIG9uIHBhZ2UgMTcs IGxpbmU3LCAgICdyYXRoZXIgdGhlbicNCj4gLS0+ICdyYXRoZXIgdGhhbicNCj4gKiBzZWN0aW9u IDMuMi4yLiAtLSB0aGUgc2Vjb25kIHBhcmFncmFwaCBvbiBwYWdlIDE4LCBsaW5lIDEsICdpdCAN Cj4gbm90aWZpZXMgYXV0b21hdGljYWxseSBvciB0aGUgSVNQJyAtLT4gJ2l0IG5vdGlmaWVzIGF1 dG9tYXRpY2FsbHkgdG8gdGhlIElTUCcNCj4gKiBzZWN0aW9uIDMuMi4yLiAtLSB0aGUgZm91cnRo IHBhcmFncmFwaCBvbiBwYWdlIDE4LCBsaW5lIDMsICd0cmFmZmljIA0KPiBwYXR0ZXInIC0tPiAn dHJhZmZpYyBwYXR0ZXJuJw0KPiANCj4gQmVzdCBSZWdhcmRzLA0KPiBZdWUNCj4gDQo+IA0KPiAt LS0tLemCruS7tuWOn+S7ti0tLS0tDQo+IOWPkeS7tuS6ujogRG90cyBbbWFpbHRvOmRvdHMtYm91 bmNlc0BpZXRmLm9yZ10g5Luj6KGoIFJvbGFuZCBEb2JiaW5zDQo+IOWPkemAgeaXtumXtDogMjAx N+W5tDEx5pyIMTPml6UgNjozOQ0KPiDmlLbku7bkuro6IGRvdHMgPGRvdHNAaWV0Zi5vcmc+DQo+ IOS4u+mimDogW0RvdHNdIGRyYWZ0LWlldGYtZG90cy11c2UtY2FzZXMtMDkgcG9zdGVkIC0gcGxl YXNlIHJldmlldyBhbmQgDQo+IHByb3ZpZGUgZmVlZGJhY2suDQo+IA0KPiANCj4gV2UndmUgcmUt b3JnYW5pemVkIHRoZSB1c2UtY2FzZXMgc28gdGhhdCBET1RTIGltcGxlbWVudG9ycyB3b24ndCBm ZWVsIA0KPiBjb21wZWxsZWQgdG8gcmVhZCB0aHJvdWdoIG11bHRpcGxlIHVzZS1jYXNlcyB3aXRo IHNpbWlsYXIgRE9UUyANCj4gY29tbXVuaWNhdGlvbnMgbW9kZWxzLCB3aGlsZSBhdCB0aGUgc2Ft ZSB0aW1lIHJldGFpbmluZyB0aG9zZSANCj4gdXNlLWNhc2VzIGJlY2F1c2UgdGhleSBjb250YWlu IHNpZ25pZmljYW50IHByb2NlZHVyYWwsIG9wZXJhdGlvbmFsLCANCj4gYW5kIHRvcG9sb2dpY2Fs IHZhcmlhbmNlcyB3aGljaCBhcmUgb2YgZ3JlYXQgc2lnbmlmaWNhbmNlIHRvIG5ldHdvcmsgDQo+ IG9wZXJhdG9ycyBhbmQgZW5kLSBjdXN0b21lciBvcmdhbml6YXRpb25zLg0KPiANCj4gVGhlIHdv cmRpbmcgaW4gdGhlIERPVFMgY29tbXVuaWNhdGlvbnMgbW9kZWwgbGlzdGluZ3MgYW5kIHNldmVy YWwgb2YgDQo+IHRoZSB1c2UtY2FzZXMgaGFzIGJlZW4gc3RyZWFtbGluZWQuICBUaGUgc2VjdXJp dHkgY29uc2lkZXJhdGlvbnMgd2VyZSANCj4gdXBkYXRlZCB0byBpbmNsdWRlIEREb1MgYXR0YWNr cy4NCj4gDQo+IEZpbmFsbHksIHdlIHJlYWxseSBuZWVkIFdHIGZlZWRiYWNrIG9uIHRoZSBhcHBs aWNhYmlsaXR5IG9mIFNlY3Rpb24gDQo+IDMuMi4yLCAnSG9tZSBOZXR3b3JrIEREb1MgRGV0ZWN0 aW9uIENvbGxhYm9yYXRpb24gZm9yIElTUCBuZXR3b3JrIG1hbmFnZW1lbnQnLg0KPiANCj4gVGhh bmtzIG11Y2ghDQo+IA0KPiA8aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQt aWV0Zi1kb3RzLXVzZS1jYXNlcy8+DQo+IA0KPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLQ0KPiBSb2xhbmQgRG9iYmlucyA8cmRvYmJpbnNAYXJib3IubmV0Pg0KPiANCj4gX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gRG90cyBtYWls aW5nIGxpc3QNCj4gRG90c0BpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL2RvdHMNCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18NCj4gRG90cyBtYWlsaW5nIGxpc3QNCj4gRG90c0BpZXRmLm9yZw0KPiBodHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RvdHMNCg== From nobody Tue Nov 28 01:08:36 2017 Return-Path: X-Original-To: dots@ietf.org Delivered-To: dots@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id AEC4F126CD8; Tue, 28 Nov 2017 01:08:29 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: dots@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.66.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151186010967.13469.3880889839321858106@ietfa.amsl.com> Date: Tue, 28 Nov 2017 01:08:29 -0800 Archived-At: Subject: [Dots] I-D Action: draft-ietf-dots-signal-channel-09.txt X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.22 List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Nov 2017 09:08:30 -0000 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 : Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal Channel Authors : Tirumaleswar Reddy Mohamed Boucadair Prashanth Patil Andrew Mortensen Nik Teague Filename : draft-ietf-dots-signal-channel-09.txt Pages : 64 Date : 2017-11-28 Abstract: This document specifies the DOTS signal channel, a protocol for signaling the need for protection against Distributed Denial-of- Service (DDoS) attacks to a server capable of enabling network traffic mitigation on behalf of the requesting client. A companion document defines the DOTS data channel, a separate reliable communication layer for DOTS management and configuration. Editorial Note (To be removed by RFC Editor) Please update these statements 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: Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal Channel"; o "| 3.00 | Alternate server | [RFCXXXX] |" o reference: RFC XXXX The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dots-signal-channel/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-dots-signal-channel-09 https://datatracker.ietf.org/doc/html/draft-ietf-dots-signal-channel-09 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dots-signal-channel-09 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/ From nobody Tue Nov 28 01:18:02 2017 Return-Path: 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 AC0C91273E2 for ; Tue, 28 Nov 2017 01:18:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.618 X-Spam-Level: X-Spam-Status: No, score=-2.618 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 FNXTx-8dAf6y for ; Tue, 28 Nov 2017 01:18:00 -0800 (PST) Received: from orange.com (mta239.mail.business.static.orange.com [80.12.66.39]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 335C912421A for ; Tue, 28 Nov 2017 01:18:00 -0800 (PST) Received: from opfedar07.francetelecom.fr (unknown [xx.xx.xx.9]) by opfedar23.francetelecom.fr (ESMTP service) with ESMTP id 642201604E1 for ; Tue, 28 Nov 2017 10:17:58 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.18]) by opfedar07.francetelecom.fr (ESMTP service) with ESMTP id 4C582C0065 for ; Tue, 28 Nov 2017 10:17:58 +0100 (CET) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM34.corporate.adroot.infra.ftgroup ([fe80::cba:56d0:a732:ef5a%19]) with mapi id 14.03.0361.001; Tue, 28 Nov 2017 10:17:57 +0100 From: To: "dots@ietf.org" Thread-Topic: I-D Action: draft-ietf-dots-signal-channel-09.txt Thread-Index: AQHTaCh9Nt9VKmAodk29q2SlqRGuZqMpgVIA Date: Tue, 28 Nov 2017 09:17:57 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93300A0807FA@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <151186010967.13469.3880889839321858106@ietfa.amsl.com> In-Reply-To: <151186010967.13469.3880889839321858106@ietfa.amsl.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.4] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Dots] I-D Action: draft-ietf-dots-signal-channel-09.txt 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Nov 2017 09:18:01 -0000 Hi all,=20 We tried to reorganize the content of the draft for a better readability. W= e also fixed many nits and checked the consistency of the overall document.= =20 The only pending issue so far is how to handle conflicts among dots clients= .=20 Please review and share your comments.=20 Cheers, Med > -----Message d'origine----- > De=A0: I-D-Announce [mailto:i-d-announce-bounces@ietf.org] De la part de > internet-drafts@ietf.org > Envoy=E9=A0: mardi 28 novembre 2017 10:08 > =C0=A0: i-d-announce@ietf.org > Cc=A0: dots@ietf.org > Objet=A0: I-D Action: draft-ietf-dots-signal-channel-09.txt >=20 >=20 > 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. >=20 > Title : Distributed Denial-of-Service Open Threat > Signaling (DOTS) Signal Channel > Authors : Tirumaleswar Reddy > Mohamed Boucadair > Prashanth Patil > Andrew Mortensen > Nik Teague > Filename : draft-ietf-dots-signal-channel-09.txt > Pages : 64 > Date : 2017-11-28 >=20 > Abstract: > This document specifies the DOTS signal channel, a protocol for > signaling the need for protection against Distributed Denial-of- > Service (DDoS) attacks to a server capable of enabling network > traffic mitigation on behalf of the requesting client. >=20 > A companion document defines the DOTS data channel, a separate > reliable communication layer for DOTS management and configuration. >=20 > Editorial Note (To be removed by RFC Editor) >=20 > Please update these statements with the RFC number to be assigned to > this document: >=20 > o "This version of this YANG module is part of RFC XXXX;" >=20 > o "RFC XXXX: Distributed Denial-of-Service Open Threat Signaling > (DOTS) Signal Channel"; >=20 > o "| 3.00 | Alternate server | [RFCXXXX] |" >=20 > o reference: RFC XXXX >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-dots-signal-channel/ >=20 > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-dots-signal-channel-09 > https://datatracker.ietf.org/doc/html/draft-ietf-dots-signal-channel-09 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dots-signal-channel-09 >=20 >=20 > 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. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From nobody Tue Nov 28 02:38:54 2017 Return-Path: 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 C16F4127599 for ; Tue, 28 Nov 2017 02:38:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 29FCYek-IfEu for ; Tue, 28 Nov 2017 02:38:43 -0800 (PST) Received: from mail.jpshallow.com (mail.jpshallow.com [217.40.240.153]) (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 8A3691200F3 for ; Tue, 28 Nov 2017 02:38:43 -0800 (PST) Received: from [127.0.0.1] (helo=N01332) by mail.jpshallow.com with smtps (TLSv1:ECDHE-RSA-AES256-SHA:256) (Exim 4.89) (envelope-from ) id 1eJdHk-00060M-Uu; Tue, 28 Nov 2017 10:38:41 +0000 From: "Jon Shallow" To: , References: <151186010967.13469.3880889839321858106@ietfa.amsl.com> <787AE7BB302AE849A7480A190F8B93300A0807FA@OPEXCLILMA3.corporate.adroot.infra.ftgroup> In-Reply-To: <787AE7BB302AE849A7480A190F8B93300A0807FA@OPEXCLILMA3.corporate.adroot.infra.ftgroup> Date: Tue, 28 Nov 2017 10:38:43 -0000 Message-ID: <009401d36835$10212780$30637680$@jpshallow.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJb6QHA2mGRle/f9ovTPcwBeUIviQE5Kvz2og64q4A= Content-Language: en-gb Archived-At: Subject: Re: [Dots] I-D Action: draft-ietf-dots-signal-channel-09.txt 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Nov 2017 10:38:47 -0000 I like the reformatting and use of mitigation instead of signal in the appropriate places. Nits Table 2: "DOTS client an withdraw" should be "DOTS client can withdraw" Figure 12: It would be good to add in the option If-Match in the example - i.e. Header: PUT (Code=3D0.03) Uri-Host: "host" Uri-Path: ".well-known" Uri-Path: "dots" Uri-Path: "version" Uri-Path: "mitigate" Content-Format: "application/cbor" If-Match: { "mitigation-scope": { Regards Jon -----Original Message----- From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of ietf-supjps-mohamed.boucadair@orange.com Sent: 28 November 2017 09:18 To: dots@ietf.org Subject: Re: [Dots] I-D Action: draft-ietf-dots-signal-channel-09.txt Hi all,=20 We tried to reorganize the content of the draft for a better = readability. We also fixed many nits and checked the consistency of the overall = document.=20 The only pending issue so far is how to handle conflicts among dots = clients. Please review and share your comments.=20 Cheers, Med > -----Message d'origine----- > De=A0: I-D-Announce [mailto:i-d-announce-bounces@ietf.org] De la part = de=20 > internet-drafts@ietf.org Envoy=E9=A0: mardi 28 novembre 2017 10:08 = =C0=A0:=20 > i-d-announce@ietf.org Cc=A0: dots@ietf.org Objet=A0: I-D Action:=20 > draft-ietf-dots-signal-channel-09.txt >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts=20 > directories. > This draft is a work item of the DDoS Open Threat Signaling WG of the=20 > IETF. >=20 > Title : Distributed Denial-of-Service Open Threat > Signaling (DOTS) Signal Channel > Authors : Tirumaleswar Reddy > Mohamed Boucadair > Prashanth Patil > Andrew Mortensen > Nik Teague > Filename : draft-ietf-dots-signal-channel-09.txt > Pages : 64 > Date : 2017-11-28 >=20 > Abstract: > This document specifies the DOTS signal channel, a protocol for > signaling the need for protection against Distributed Denial-of- > Service (DDoS) attacks to a server capable of enabling network > traffic mitigation on behalf of the requesting client. >=20 > A companion document defines the DOTS data channel, a separate > reliable communication layer for DOTS management and configuration. >=20 > Editorial Note (To be removed by RFC Editor) >=20 > Please update these statements with the RFC number to be assigned = to > this document: >=20 > o "This version of this YANG module is part of RFC XXXX;" >=20 > o "RFC XXXX: Distributed Denial-of-Service Open Threat Signaling > (DOTS) Signal Channel"; >=20 > o "| 3.00 | Alternate server | [RFCXXXX] |" >=20 > o reference: RFC XXXX >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-dots-signal-channel/ >=20 > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-dots-signal-channel-09 > https://datatracker.ietf.org/doc/html/draft-ietf-dots-signal-channel-0 > 9 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dots-signal-channel-09 >=20 >=20 > Please note that it may take a couple of minutes from the time of=20 > submission until the htmlized version and diff are available at=20 > tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html or=20 > ftp://ftp.ietf.org/ietf/1shadow-sites.txt _______________________________________________ Dots mailing list Dots@ietf.org https://www.ietf.org/mailman/listinfo/dots From nobody Tue Nov 28 02:51:53 2017 Return-Path: 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 D04C3126BF0 for ; Tue, 28 Nov 2017 02:51:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 rLccoRPELjNs for ; Tue, 28 Nov 2017 02:51:49 -0800 (PST) Received: from mail.jpshallow.com (mail.jpshallow.com [217.40.240.153]) (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 49ABF1200F3 for ; Tue, 28 Nov 2017 02:51:49 -0800 (PST) Received: from [127.0.0.1] (helo=N01332) by mail.jpshallow.com with smtps (TLSv1:ECDHE-RSA-AES256-SHA:256) (Exim 4.89) (envelope-from ) id 1eJdUR-00060r-4A; Tue, 28 Nov 2017 10:51:47 +0000 From: "Jon Shallow" To: "'dongyue \(D\)'" , , "Roland Dobbins" , References: <787AE7BB302AE849A7480A190F8B93300A07FDBD@OPEXCLILMA3.corporate.adroot.infra.ftgroup> In-Reply-To: Date: Tue, 28 Nov 2017 10:51:49 -0000 Message-ID: <009601d36836$e4b81bb0$ae285310$@jpshallow.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIkmbd3sDBxULBoFa/Ejayy+wcNrAKjcHqVAlVAgZqiX3FWkA== Content-Language: en-gb Archived-At: Subject: Re: [Dots] =?utf-8?b?562U5aSNOiAgZHJhZnQtaWV0Zi1kb3RzLXVzZS1jYXNl?= =?utf-8?q?s-09_posted_-_please_review_and_provide_feedback=2E?= 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Nov 2017 10:51:51 -0000 Hi Med, I agree that Table 2: (-09 version) on dots-signal should have an = additional status entry +-----------+-------------------------------------------------------+ | 6 | The mitigation has now terminated | +-----------+-------------------------------------------------------+ Which will only get sent if 'Observe' is active. =20 Hi Yue, If the client periodically sends a status request with the appropriate = mitigation-id, once the mitigation has terminated, the DOTS server will = send back a 4.04 message (first paragraph of 4.4.3. Retrieve Information = Related to a Mitigation) as the mitigation-id is no longer in use. = However, as you effectively say, the DOTS client should know by that = stage that the mitigation is getting closed down and does not = necessarily need to send a status query to find out what is happening. Regards Jon -----Original Message----- From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of dongyue (D) Sent: 28 November 2017 03:23 To: mohamed.boucadair@orange.com; Roland Dobbins; dots Subject: [Dots] =E7=AD=94=E5=A4=8D: draft-ietf-dots-use-cases-09 posted = - please review and provide feedback. Hi Med, Thanks for your reply! According to the use case, firstly when a client request to terminate a = mitigation, the server has to send a status message (mitigation is = active but terminating, listed in the table in page 28 in signal channel = draft). Then, the mitigation is exactly terminated by the mitigator, the = sever requires to send another status message (not listed in the table) = to confirm the termination. I just enquires if the second stage should = be explained in the signal channel draft. =20 For the subscribing approach, the server will send the notifications = upon the status change. This approach is ok. For another approach, namely the client sending status request = periodically, the time to stop sending the status request is another = issue that need to be determined by the mitigation termination status = message. Because I think it is unnecessary to always send the status = request if the mitigation is stopped.=20 Best Regards, Yue -----=E9=82=AE=E4=BB=B6=E5=8E=9F=E4=BB=B6----- =E5=8F=91=E4=BB=B6=E4=BA=BA: mohamed.boucadair@orange.com = [mailto:mohamed.boucadair@orange.com] =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: = 2017=E5=B9=B411=E6=9C=8827=E6=97=A5 15:19 =E6=94=B6=E4=BB=B6=E4=BA=BA: dongyue (D) ; Roland = Dobbins ; dots =E4=B8=BB=E9=A2=98: RE: [Dots] draft-ietf-dots-use-cases-09 posted - = please review and provide feedback. Dear Yue,=20 Please see inline.=20 Cheers, Med > -----Message d'origine----- > De : Dots [mailto:dots-bounces@ietf.org] De la part de dongyue (D)=20 > Envoy=C3=A9 : lundi 27 novembre 2017 07:34 =C3=80 : Roland Dobbins; = dots Objet : > Re: [Dots] draft-ietf-dots-use-cases-09 posted - please review and=20 > provide feedback. >=20 > Here are a few questions/comments on the use cases: >=20 > * section 3.1.1.1, paragraph 7 -- In this paragraph, the DOTS server=20 > will send a confirmation to the enterprise IDMS DOTS client once the=20 > mitigation has already been ended. However, to the best of my=20 > knowledge, this feature does not exist in the DOTS signal channel = draft. [Med] A dots client can retrieve the status of an ongoing mitigation = request by periodically poking the server or by subscribing to = unsolicited notifications. Below an example from the signal-channel = draft to illustrate this behavior:=20 DOTS Client DOTS Server | | | GET / | | Token: 0x4a | = Registration | Observe: 0 | +------------------------------>| | | | 2.05 Content | | Token: 0x4a | = Notification of | Observe: 12 | the = current state | status: "mitigation | | in progress" | |<------------------------------+ | 2.05 Content | | Token: 0x4a | = Notification upon | Observe: 44 | a state = change | status: "mitigation | | complete" | |<------------------------------+ | 2.05 Content | | Token: 0x4a | = Notification upon | Observe: 60 | a state = change | status: "attack stopped" | |<------------------------------+ | | Will you suggest this to > be added in the signal channel? >=20 > * section 3.1.2.1. , paragraph 5 -- In this paragraph the time to live > (TTL) is proposed to be included in the mitigation request as an=20 > alternative way to terminate the mitigation. In my opinion, the TTL=20 > approach could be used in all the DOTS use case scenarios. Hence I=20 > recommend to explain it in the very first use case in 3.1.1.1.,=20 > otherwise it looks only be used in use cases that MSSP offering the=20 > mitigation services. >=20 > * section 3.2.2. -- Firstly, this use case placed too much emphasis=20 > on how the DDoS attack is detected. Secondly, I think it is better to=20 > have a schematic diagram (like the figure in section 3.2.3) to show=20 > the architecture and explain the work flow in detail to show how the=20 > DOTS protocol works in this scenario. >=20 > * section 3.2.2. -- the last paragraph on page 17, line7, 'rather = then' > --> 'rather than' > * section 3.2.2. -- the second paragraph on page 18, line 1, 'it=20 > notifies automatically or the ISP' --> 'it notifies automatically to = the ISP' > * section 3.2.2. -- the fourth paragraph on page 18, line 3, 'traffic=20 > patter' --> 'traffic pattern' >=20 > Best Regards, > Yue >=20 >=20 > -----=E9=82=AE=E4=BB=B6=E5=8E=9F=E4=BB=B6----- > =E5=8F=91=E4=BB=B6=E4=BA=BA: Dots [mailto:dots-bounces@ietf.org] = =E4=BB=A3=E8=A1=A8 Roland Dobbins > =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: = 2017=E5=B9=B411=E6=9C=8813=E6=97=A5 6:39 > =E6=94=B6=E4=BB=B6=E4=BA=BA: dots > =E4=B8=BB=E9=A2=98: [Dots] draft-ietf-dots-use-cases-09 posted - = please review and=20 > provide feedback. >=20 >=20 > We've re-organized the use-cases so that DOTS implementors won't feel=20 > compelled to read through multiple use-cases with similar DOTS=20 > communications models, while at the same time retaining those=20 > use-cases because they contain significant procedural, operational,=20 > and topological variances which are of great significance to network=20 > operators and end- customer organizations. >=20 > The wording in the DOTS communications model listings and several of=20 > the use-cases has been streamlined. The security considerations were=20 > updated to include DDoS attacks. >=20 > Finally, we really need WG feedback on the applicability of Section=20 > 3.2.2, 'Home Network DDoS Detection Collaboration for ISP network = management'. >=20 > Thanks much! >=20 > >=20 > ----------------------------------- > Roland Dobbins >=20 > _______________________________________________ > 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 From nobody Tue Nov 28 03:00:32 2017 Return-Path: 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 4D3A01279E5 for ; Tue, 28 Nov 2017 03:00:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.5 X-Spam-Level: X-Spam-Status: No, score=-5.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_SORBS_WEB=1.5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 V6w0IrU39dj4 for ; Tue, 28 Nov 2017 03:00:29 -0800 (PST) Received: from MIVWSMAILOUT1.mcafee.com (mivwsmailout1.mcafee.com [161.69.47.167]) (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 160141277BB for ; Tue, 28 Nov 2017 03:00:28 -0800 (PST) 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=1511866827; 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: authentication-results:x-originating-ip:x-ms-publictraffictype: x-microsoft-exchange-diagnostics:x-ms-exchange-antispam-srfa-diagnostics: x-ms-office365-filtering-correlation-id:x-microsoft-antispam: x-ms-traffictypediagnostic:x-microsoft-antispam-prvs: x-exchange-antispam-report-test:x-exchange-antispam-report-cfa-test: x-forefront-prvs:x-forefront-antispam-report: received-spf:spamdiagnosticoutput:spamdiagnosticmetadata: 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-Transport-CrossTenantHeadersStamped: X-OriginatorOrg:X-NAI-Spam-Flag:X-NAI-Spam-Threshold: X-NAI-Spam-Score:X-NAI-Spam-Version; bh=f I+PruNMYv2VJYXT7YO0koJq9DXl1UAxKJPIIx6LwF Y=; b=d5f5oX/xCM3eRB4ki8h1eQB5GdX+5x5ZgYE0wBF3CCla WxSWgz9FyzhFwWEoIQZbear3tZo+TAN2ScZyKRyfO2AZ9CaC0G zFWTRJJuMNi/fEWcyKJznMzd5nOqHX8DpBRbvDp4MwQLed4+rf l7y03DdJYnIT9/+Tf7fNYelJ87U= Received: from MIVEXAPP1N03.corpzone.internalzone.com (mivexapp1n03.corpzone.internalzone.com [10.48.48.90]) by MIVWSMAILOUT1.mcafee.com with smtp id 4149_050e_152b994c_5a77_4ce8_ad7b_5a89c1de8b84; Tue, 28 Nov 2017 05:00:27 -0600 Received: from MIVEXUSR1N02.corpzone.internalzone.com (10.48.48.82) by MIVEXAPP1N03.corpzone.internalzone.com (10.48.48.90) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Tue, 28 Nov 2017 05:59:39 -0500 Received: from MIVEXAPP1N01.corpzone.internalzone.com (10.48.48.88) by MIVEXUSR1N02.corpzone.internalzone.com (10.48.48.82) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Tue, 28 Nov 2017 05:59:38 -0500 Received: from MIVO365EDGE3.corpzone.internalzone.com (10.48.176.86) by MIVEXAPP1N01.corpzone.internalzone.com (10.48.48.88) with Microsoft SMTP Server (TLS) id 15.0.1347.2 via Frontend Transport; Tue, 28 Nov 2017 05:59:38 -0500 Received: from NAM03-DM3-obe.outbound.protection.outlook.com (10.48.176.242) by edge.mcafee.com (10.48.176.86) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Tue, 28 Nov 2017 05:59:36 -0500 Received: from DM5PR16MB1788.namprd16.prod.outlook.com (10.172.44.144) by DM5PR16MB1786.namprd16.prod.outlook.com (10.172.44.142) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.260.4; Tue, 28 Nov 2017 10:59:37 +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.20.0260.006; Tue, 28 Nov 2017 10:59:36 +0000 From: "Konda, Tirumaleswar Reddy" To: Jon Shallow , "mohamed.boucadair@orange.com" , "dots@ietf.org" Thread-Topic: [Dots] I-D Action: draft-ietf-dots-signal-channel-09.txt Thread-Index: AQHTaCneZf5PzpTzrkmxz2tBOEDvhaMpmcuAgAAFkDA= Date: Tue, 28 Nov 2017 10:59:36 +0000 Message-ID: References: <151186010967.13469.3880889839321858106@ietfa.amsl.com> <787AE7BB302AE849A7480A190F8B93300A0807FA@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <009401d36835$10212780$30637680$@jpshallow.com> In-Reply-To: <009401d36835$10212780$30637680$@jpshallow.com> 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: [122.172.38.74] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DM5PR16MB1786; 6:91BRyxS3HNHMxubvMacO2Rru46p9ktU7tJhk6+DZOhCGP6EP1tmKbzp3tivbRi0ua2HWl7jnIU6jNAhFz/iXoK9HVdX2JvJIVTbX/KwH3yx8LXns8RYXEspBP/L6YkTdqJdTKAVj5Bj4jP8J9N37dLiELfUCyOfercHAFfIEFCYddZ9x3W/IObhLzSO08li4Jt2934mQGaU+6T9haYn1pJ3q6sAe/LJKGy73OtVmrwN7Wd2KG8FJVJLHbDBN3FpAO5DG1O0ckWSvFCkJhzqUJny0YbhF9HhIiiT25LjY1aQdwtamCgLBZTgsuFd9/Nca9J2zoIdjSKPmPc3knUxHd2GJCH2fOIn26n+oysNx4gg=; 5:NUFIAg4vpN7tdFWapbkkVU7u28Ufj6GKJHHKbBreVHUxVHIiigz3I0sKMKcAF4okcQ8b8jV5EHJyB93e3NJr1yaQ8yS7h/ybxCEAa1M+i1APXInpAfPh9KzZ4ZrPnPIzN6hfVyGq4JismquLj0SUMPMOtwUg8raWLU6L1ZPtWUU=; 24:wnP+wU9RLc6lKLdVdNX5C7RRw3tp1Ydq5rmqvmi9Pyes+TuA1N2QFgAMKv+AU3E1O1ro2ToC1waFL4YpxCMbF3jG/9Zbj0yPmOCmDczLBUc=; 7:Hray2/M9KqOl59Q6kB6pao84mV/wK+MhlA74UGTFGUddigzNAolxTkaa3Avmpk+2P/O8mxoCG8XCalSb3bYZ66cTq6EQBYi3HyjmuppCQmkGRK5NrXFXnQl4vVy/RS6/tko7zUCfKGpEW9wfgpsSv5lN0dMGz758M4cKvkiwG+SNLamZFlvu2yluLN48uxQZhivKNIWrlq6GmAaVLkRNbCzcnqD9Z8k5ZelW/klj7EY5KMgJRUkY/HJ/lZ7crhz9 x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 25adebde-e5e9-4e34-8970-08d5364f1d7d x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(5600026)(4604075)(2017052603199); SRVR:DM5PR16MB1786; x-ms-traffictypediagnostic: DM5PR16MB1786: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(120809045254105)(18271650672692); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(2401047)(5005006)(8121501046)(93006095)(93001095)(10201501046)(3231022)(3002001)(6041248)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123564025)(20161123562025)(20161123560025)(20161123555025)(20161123558100)(6072148)(201708071742011); SRVR:DM5PR16MB1786; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:DM5PR16MB1786; x-forefront-prvs: 0505147DDB x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(39860400002)(346002)(376002)(366004)(189002)(32952001)(199003)(55784002)(377424004)(53754006)(13464003)(72206003)(102836003)(3846002)(53546010)(14454004)(33656002)(6116002)(80792005)(966005)(3280700002)(2950100002)(8936002)(77096006)(3660700001)(7696005)(6246003)(478600001)(68736007)(189998001)(53936002)(2900100001)(50986999)(6506006)(2201001)(55016002)(86362001)(105586002)(110136005)(316002)(230783001)(54356999)(6306002)(6436002)(74316002)(5660300001)(9686003)(97736004)(106356001)(66066001)(101416001)(99286004)(305945005)(4001150100001)(76176999)(2906002)(229853002)(2501003)(8676002)(25786009)(7736002)(81156014)(81166006)(85282002); DIR:OUT; SFP:1101; SCL:1; SRVR:DM5PR16MB1786; H:DM5PR16MB1788.namprd16.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; 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: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 25adebde-e5e9-4e34-8970-08d5364f1d7d X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Nov 2017 10:59:36.6625 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4943e38c-6dd4-428c-886d-24932bc2d5de X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR16MB1786 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 <6167> : inlines <6186> : streams <1771571> : uri <2541469> Archived-At: Subject: Re: [Dots] I-D Action: draft-ietf-dots-signal-channel-09.txt 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Nov 2017 11:00:31 -0000 Thanks Jon, fixed both Nits (uploaded revision to github).=20 -Tiru > -----Original Message----- > From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Jon Shallow > Sent: Tuesday, November 28, 2017 4:09 PM > To: mohamed.boucadair@orange.com; dots@ietf.org > Subject: Re: [Dots] I-D Action: draft-ietf-dots-signal-channel-09.txt >=20 > I like the reformatting and use of mitigation instead of signal in the > appropriate places. >=20 > Nits >=20 > Table 2: > "DOTS client an withdraw" should be "DOTS client can withdraw" >=20 > Figure 12: > It would be good to add in the option If-Match in the example - i.e. > Header: PUT (Code=3D0.03) > Uri-Host: "host" > Uri-Path: ".well-known" > Uri-Path: "dots" > Uri-Path: "version" > Uri-Path: "mitigate" > Content-Format: "application/cbor" > If-Match: > { > "mitigation-scope": { >=20 > Regards >=20 > Jon >=20 > -----Original Message----- > From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of ietf-supjps- > mohamed.boucadair@orange.com > Sent: 28 November 2017 09:18 > To: dots@ietf.org > Subject: Re: [Dots] I-D Action: draft-ietf-dots-signal-channel-09.txt >=20 > Hi all, >=20 > We tried to reorganize the content of the draft for a better readability.= We > also fixed many nits and checked the consistency of the overall document. >=20 > The only pending issue so far is how to handle conflicts among dots clien= ts. >=20 >=20 > Please review and share your comments. >=20 > Cheers, > Med >=20 > > -----Message d'origine----- > > De=A0: I-D-Announce [mailto:i-d-announce-bounces@ietf.org] De la part d= e > > internet-drafts@ietf.org Envoy=E9=A0: mardi 28 novembre 2017 10:08 =C0= =A0: > > i-d-announce@ietf.org Cc=A0: dots@ietf.org Objet=A0: I-D Action: > > draft-ietf-dots-signal-channel-09.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 : Distributed Denial-of-Service Open Threat > > Signaling (DOTS) Signal Channel > > Authors : Tirumaleswar Reddy > > Mohamed Boucadair > > Prashanth Patil > > Andrew Mortensen > > Nik Teague > > Filename : draft-ietf-dots-signal-channel-09.txt > > Pages : 64 > > Date : 2017-11-28 > > > > Abstract: > > This document specifies the DOTS signal channel, a protocol for > > signaling the need for protection against Distributed Denial-of- > > Service (DDoS) attacks to a server capable of enabling network > > traffic mitigation on behalf of the requesting client. > > > > A companion document defines the DOTS data channel, a separate > > reliable communication layer for DOTS management and configuration. > > > > Editorial Note (To be removed by RFC Editor) > > > > Please update these statements 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: Distributed Denial-of-Service Open Threat Signaling > > (DOTS) Signal Channel"; > > > > o "| 3.00 | Alternate server | [RFCXXXX] |" > > > > o reference: RFC XXXX > > > > > > The IETF datatracker status page for this draft is: > > https://datatracker.ietf.org/doc/draft-ietf-dots-signal-channel/ > > > > There are also htmlized versions available at: > > https://tools.ietf.org/html/draft-ietf-dots-signal-channel-09 > > https://datatracker.ietf.org/doc/html/draft-ietf-dots-signal-channel-0 > > 9 > > > > A diff from the previous version is available at: > > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dots-signal-channel-09 > > > > > > 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/ > > > > _______________________________________________ > > I-D-Announce mailing list > > I-D-Announce@ietf.org > > https://www.ietf.org/mailman/listinfo/i-d-announce > > Internet-Draft directories: http://www.ietf.org/shadow.html or > > ftp://ftp.ietf.org/ietf/1shadow-sites.txt >=20 > _______________________________________________ > Dots mailing list > Dots@ietf.org > https://www.ietf.org/mailman/listinfo/dots >=20 > _______________________________________________ > Dots mailing list > Dots@ietf.org > https://www.ietf.org/mailman/listinfo/dots From nobody Tue Nov 28 03:01:07 2017 Return-Path: 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 5AB0D127599 for ; Tue, 28 Nov 2017 03:01:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.82 X-Spam-Level: X-Spam-Status: No, score=-2.82 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RCVD_IN_SORBS_WEB=1.5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 yUtx_Mp-tAUi for ; Tue, 28 Nov 2017 03:01:01 -0800 (PST) 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 3DB8C1271DF for ; Tue, 28 Nov 2017 03:00:49 -0800 (PST) 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=1511866844; 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: authentication-results:x-originating-ip:x-ms-publictraffictype: x-microsoft-exchange-diagnostics:x-ms-exchange-antispam-srfa-diagnostics: x-ms-office365-filtering-correlation-id:x-microsoft-antispam: x-ms-traffictypediagnostic:x-microsoft-antispam-prvs: x-exchange-antispam-report-test:x-exchange-antispam-report-cfa-test: x-forefront-prvs:x-forefront-antispam-report: received-spf:spamdiagnosticoutput:spamdiagnosticmetadata: 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-Transport-CrossTenantHeadersStamped: X-OriginatorOrg:X-NAI-Spam-Flag:X-NAI-Spam-Level: X-NAI-Spam-Threshold:X-NAI-Spam-Score:X-NAI-Spam-Version; bh=wNS6c3jYMh2sR5BTIDp4E36XLgSVo7VlovJXEl jowaE=; b=oXxxl4KqGUjY6vijzesc+ClBY3nnL/us8sWX1WoZ SXpW+ITwGxVQ7AqzFEKGuFb0Lh21ahSu2HgFEpVwNBMYwwpCe8 envM1hbYf88ClgIMYAUcKOFtqaTRJTPpLYUb3tgm5cQtZlvK10 5rwGTGSydJxwLxA9YGfLfTKVwqjY2Ps= Received: from DNVEXAPP1N05.corpzone.internalzone.com (unknown [10.44.48.89]) by DNVWSMAILOUT1.mcafee.com with smtp id 1151_2f66_e7cc251b_84df_4ca4_8434_c500ed1ae8da; Tue, 28 Nov 2017 05:00:43 -0600 Received: from DNVEXUSR1N10.corpzone.internalzone.com (10.44.48.83) by DNVEXAPP1N05.corpzone.internalzone.com (10.44.48.89) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Tue, 28 Nov 2017 04:00:43 -0700 Received: from DNVEXUSR1N13.corpzone.internalzone.com (10.44.48.86) by DNVEXUSR1N10.corpzone.internalzone.com (10.44.48.83) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Tue, 28 Nov 2017 04:00:41 -0700 Received: from DNVO365EDGE2.corpzone.internalzone.com (10.44.176.74) by DNVEXUSR1N13.corpzone.internalzone.com (10.44.48.86) with Microsoft SMTP Server (TLS) id 15.0.1347.2 via Frontend Transport; Tue, 28 Nov 2017 04:00:41 -0700 Received: from NAM03-DM3-obe.outbound.protection.outlook.com (10.44.176.242) by edge.mcafee.com (10.44.176.74) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Tue, 28 Nov 2017 04:00:41 -0700 Received: from DM5PR16MB1788.namprd16.prod.outlook.com (10.172.44.144) by DM5PR16MB1786.namprd16.prod.outlook.com (10.172.44.142) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.260.4; Tue, 28 Nov 2017 11:00:40 +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.20.0260.006; Tue, 28 Nov 2017 11:00:40 +0000 From: "Konda, Tirumaleswar Reddy" To: Jon Shallow , "'dongyue (D)'" , "mohamed.boucadair@orange.com" , Roland Dobbins , "dots@ietf.org" Thread-Topic: =?utf-8?B?W0RvdHNdIOetlOWkjTogIGRyYWZ0LWlldGYtZG90cy11c2UtY2FzZXMtMDkg?= =?utf-8?Q?posted_-_please_review_and_provide_feedback.?= Thread-Index: AQHTZ/g+U11Cmxyg0E2fZOTFV5nspKMpndeAgAACPGA= Date: Tue, 28 Nov 2017 11:00:40 +0000 Message-ID: References: <787AE7BB302AE849A7480A190F8B93300A07FDBD@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <009601d36836$e4b81bb0$ae285310$@jpshallow.com> In-Reply-To: <009601d36836$e4b81bb0$ae285310$@jpshallow.com> 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: [122.172.38.74] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DM5PR16MB1786; 6:gswUBcpCdTrjbMdIwqcmA5Q5QWe7OmR3eFs5IbeWOgo1UlvpMRYrIKaIqBuNI+i5nTZq3s8yRfxokk5WAVcRuJEjjcx0+JBvJHPYS1ZcLOzcArwmw2+5d32nbhhFe7damAF7BrPgXU3SyvhOoxFolLgXvps0OLrx3Sjki9zVhn6nAdarfxea/POQ4DsGe4fxPoklmx31/jwSQkGncVJZoJvtlidjLMA0HR4wE8Qzn6hmQyyBn+EewKQdiN0fpkgjerX78F5EJKdKWgFEN6egKZ0EDqrob1+byLKGF6QFb4MkzQHOTMdVFOW1miy8oequN/60yx6jXvmD4G23S2IZSLRSS/Vqr1tQ0t5K17rxUTc=; 5:XygFTJ+t0idhuUQYHy1WLcQi1hFBOeQ0Dr2FOg2TPqPyvDU8QLRL2mxmD4O7QuCGbeUyqGzAUU87qvlzs8hzAwDCXJF1Dxb7a1BO7ph31C/wz1eUj7DpQLwoVdiRZVM9YR/jfmBPhaTaY+D0gNJDGmVXcfswGnQR8j2Cnp9Mas0=; 24:7x090/EbMzSU9nyQJhksVL9KAKaIgxv4GyGRck6wKTjZZyz/76fZu+aOyegupHfy9F8xX5WAZlUEreFd8qXXOEGrLKnL4v/R+lryeLpY79k=; 7:U2Zrgfe6TNVWxvPJUfzGSJEs9t6h3uGgQoTfZNDA4pfrd/CWN+vEeDjU9TMXQROpYKEaa0izSSzwDKMmh4DhKgpkD0wY2448RfrVopJCMvUkQH53NiOT7UuhnL3KRQ/XIMSLdm2tD+gZhyCYM0O6OycJLTan9CGq5IhnbsCzpUn61HmW3fHLkR8RJHUNHs9Um5Kj6n+xyZCY6BPuNbUuoR8Z4pcozpqbPZsOjPAwBB0+HLSqIslDesDU8DkxTbsL x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: a4668182-3467-45b1-0ffd-08d5364f4357 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(5600026)(4604075)(2017052603199); SRVR:DM5PR16MB1786; x-ms-traffictypediagnostic: DM5PR16MB1786: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(190756311086443)(158342451672863)(120809045254105)(192374486261705)(50582790962513)(18271650672692)(231250463719595); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(2401047)(5005006)(8121501046)(93006095)(93001095)(10201501046)(3231022)(3002001)(6041248)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123564025)(20161123562025)(20161123560025)(20161123555025)(20161123558100)(6072148)(201708071742011); SRVR:DM5PR16MB1786; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:DM5PR16MB1786; x-forefront-prvs: 0505147DDB x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(39860400002)(346002)(376002)(366004)(189002)(32952001)(199003)(55784002)(13464003)(72206003)(102836003)(3846002)(53546010)(14454004)(33656002)(6116002)(80792005)(966005)(3280700002)(2950100002)(8936002)(77096006)(3660700001)(7696005)(6246003)(478600001)(68736007)(189998001)(53936002)(2900100001)(50986999)(6506006)(55016002)(86362001)(105586002)(110136005)(93886005)(316002)(230783001)(54356999)(6306002)(6436002)(74316002)(5660300001)(224303003)(9686003)(97736004)(106356001)(66066001)(101416001)(99286004)(305945005)(76176999)(2906002)(229853002)(2501003)(25786009)(7736002)(81156014)(81166006)(85282002); DIR:OUT; SFP:1101; SCL:1; SRVR:DM5PR16MB1786; H:DM5PR16MB1788.namprd16.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; 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: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: a4668182-3467-45b1-0ffd-08d5364f4357 X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Nov 2017 11:00:40.1638 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4943e38c-6dd4-428c-886d-24932bc2d5de X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR16MB1786 X-OriginatorOrg: mcafee.com X-NAI-Spam-Flag: NO X-NAI-Spam-Level: X-NAI-Spam-Threshold: 15 X-NAI-Spam-Score: 0.1 X-NAI-Spam-Version: 2.3.0.9418 : core <6167> : inlines <6186> : streams <1771571> : uri <2541469> Archived-At: Subject: Re: [Dots] =?utf-8?b?562U5aSNOiAgZHJhZnQtaWV0Zi1kb3RzLXVzZS1jYXNl?= =?utf-8?q?s-09_posted_-_please_review_and_provide_feedback=2E?= 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Nov 2017 11:01:05 -0000 RG9uZSwgYWRkZWQgYWRkaXRpb25hbCBzdGF0dXMgZW50cnkuDQoNCkNoZWVycywNCi1UaXJ1DQoN Cj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogRG90cyBbbWFpbHRvOmRvdHMt Ym91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEpvbiBTaGFsbG93DQo+IFNlbnQ6IFR1ZXNk YXksIE5vdmVtYmVyIDI4LCAyMDE3IDQ6MjIgUE0NCj4gVG86ICdkb25neXVlIChEKScgPGRvbmd5 dWU2QGh1YXdlaS5jb20+Ow0KPiBtb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tOyBSb2xhbmQg RG9iYmlucyA8cmRvYmJpbnNAYXJib3IubmV0PjsNCj4gZG90c0BpZXRmLm9yZw0KPiBTdWJqZWN0 OiBSZTogW0RvdHNdIOetlOWkjTogZHJhZnQtaWV0Zi1kb3RzLXVzZS1jYXNlcy0wOSBwb3N0ZWQg LSBwbGVhc2UgcmV2aWV3DQo+IGFuZCBwcm92aWRlIGZlZWRiYWNrLg0KPiANCj4gSGkgTWVkLA0K PiANCj4gSSBhZ3JlZSB0aGF0IFRhYmxlIDI6ICgtMDkgdmVyc2lvbikgb24gZG90cy1zaWduYWwg c2hvdWxkIGhhdmUgYW4gYWRkaXRpb25hbA0KPiBzdGF0dXMgZW50cnkNCj4gDQo+ICAgICstLS0t LS0tLS0tLSstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tKw0KPiAgICB8ICAgICAgICAgNiB8IFRoZSBtaXRpZ2F0aW9uIGhhcyBub3cgdGVybWlu YXRlZCAgfA0KPiAgICArLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSsNCj4gDQo+IFdoaWNoIHdpbGwgb25seSBnZXQgc2Vu dCBpZiAnT2JzZXJ2ZScgaXMgYWN0aXZlLg0KPiANCj4gSGkgWXVlLA0KPiANCj4gSWYgdGhlIGNs aWVudCBwZXJpb2RpY2FsbHkgc2VuZHMgYSBzdGF0dXMgcmVxdWVzdCB3aXRoIHRoZSBhcHByb3By aWF0ZQ0KPiBtaXRpZ2F0aW9uLWlkLCBvbmNlIHRoZSBtaXRpZ2F0aW9uIGhhcyB0ZXJtaW5hdGVk LCB0aGUgRE9UUyBzZXJ2ZXIgd2lsbCBzZW5kDQo+IGJhY2sgYSA0LjA0IG1lc3NhZ2UgKGZpcnN0 IHBhcmFncmFwaCBvZiA0LjQuMy4gUmV0cmlldmUgSW5mb3JtYXRpb24gUmVsYXRlZA0KPiB0byBh IE1pdGlnYXRpb24pIGFzIHRoZSBtaXRpZ2F0aW9uLWlkIGlzIG5vIGxvbmdlciBpbiB1c2UuICBI b3dldmVyLCBhcyB5b3UNCj4gZWZmZWN0aXZlbHkgc2F5LCB0aGUgRE9UUyBjbGllbnQgc2hvdWxk IGtub3cgYnkgdGhhdCBzdGFnZSB0aGF0IHRoZSBtaXRpZ2F0aW9uDQo+IGlzIGdldHRpbmcgY2xv c2VkIGRvd24gYW5kIGRvZXMgbm90IG5lY2Vzc2FyaWx5IG5lZWQgdG8gc2VuZCBhIHN0YXR1cyBx dWVyeQ0KPiB0byBmaW5kIG91dCB3aGF0IGlzIGhhcHBlbmluZy4NCj4gDQo+IFJlZ2FyZHMNCj4g DQo+IEpvbg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBEb3RzIFttYWls dG86IGRvdHMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIGRvbmd5dWUgKEQpDQo+IFNl bnQ6IDI4IE5vdmVtYmVyIDIwMTcgMDM6MjMNCj4gVG86IG1vaGFtZWQuYm91Y2FkYWlyQG9yYW5n ZS5jb207IFJvbGFuZCBEb2JiaW5zOyBkb3RzDQo+IFN1YmplY3Q6IFtEb3RzXSDnrZTlpI06IGRy YWZ0LWlldGYtZG90cy11c2UtY2FzZXMtMDkgcG9zdGVkIC0gcGxlYXNlIHJldmlldyBhbmQNCj4g cHJvdmlkZSBmZWVkYmFjay4NCj4gDQo+IEhpIE1lZCwNCj4gDQo+IFRoYW5rcyBmb3IgeW91ciBy ZXBseSENCj4gDQo+IEFjY29yZGluZyB0byB0aGUgdXNlIGNhc2UsIGZpcnN0bHkgd2hlbiBhIGNs aWVudCByZXF1ZXN0IHRvIHRlcm1pbmF0ZSBhDQo+IG1pdGlnYXRpb24sIHRoZSBzZXJ2ZXIgaGFz IHRvIHNlbmQgYSBzdGF0dXMgbWVzc2FnZSAobWl0aWdhdGlvbiBpcyBhY3RpdmUgYnV0DQo+IHRl cm1pbmF0aW5nLCBsaXN0ZWQgaW4gdGhlIHRhYmxlIGluIHBhZ2UgMjggaW4gc2lnbmFsIGNoYW5u ZWwgZHJhZnQpLiBUaGVuLCB0aGUNCj4gbWl0aWdhdGlvbiBpcyBleGFjdGx5IHRlcm1pbmF0ZWQg YnkgdGhlIG1pdGlnYXRvciwgdGhlIHNldmVyIHJlcXVpcmVzIHRvIHNlbmQNCj4gYW5vdGhlciBz dGF0dXMgbWVzc2FnZSAobm90IGxpc3RlZCBpbiB0aGUgdGFibGUpIHRvIGNvbmZpcm0gdGhlIHRl cm1pbmF0aW9uLiBJDQo+IGp1c3QgZW5xdWlyZXMgaWYgdGhlIHNlY29uZCBzdGFnZSBzaG91bGQg YmUgZXhwbGFpbmVkIGluIHRoZSBzaWduYWwgY2hhbm5lbA0KPiBkcmFmdC4NCj4gRm9yIHRoZSBz dWJzY3JpYmluZyBhcHByb2FjaCwgdGhlIHNlcnZlciB3aWxsIHNlbmQgdGhlIG5vdGlmaWNhdGlv bnMgdXBvbiB0aGUNCj4gc3RhdHVzIGNoYW5nZS4gVGhpcyBhcHByb2FjaCBpcyBvay4NCj4gRm9y IGFub3RoZXIgYXBwcm9hY2gsIG5hbWVseSB0aGUgY2xpZW50IHNlbmRpbmcgc3RhdHVzIHJlcXVl c3QgcGVyaW9kaWNhbGx5LA0KPiB0aGUgdGltZSB0byBzdG9wIHNlbmRpbmcgdGhlIHN0YXR1cyBy ZXF1ZXN0IGlzIGFub3RoZXIgaXNzdWUgdGhhdCBuZWVkIHRvIGJlDQo+IGRldGVybWluZWQgYnkg dGhlIG1pdGlnYXRpb24gdGVybWluYXRpb24gc3RhdHVzIG1lc3NhZ2UuIEJlY2F1c2UgSSB0aGlu ayBpdA0KPiBpcyB1bm5lY2Vzc2FyeSB0byBhbHdheXMgc2VuZCB0aGUgc3RhdHVzIHJlcXVlc3Qg aWYgdGhlIG1pdGlnYXRpb24gaXMgc3RvcHBlZC4NCj4gDQo+IEJlc3QgUmVnYXJkcywNCj4gWXVl DQo+IA0KPiAtLS0tLemCruS7tuWOn+S7ti0tLS0tDQo+IOWPkeS7tuS6ujogbW9oYW1lZC5ib3Vj YWRhaXJAb3JhbmdlLmNvbQ0KPiBbbWFpbHRvOm1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb21d DQo+IOWPkemAgeaXtumXtDogMjAxN+W5tDEx5pyIMjfml6UgMTU6MTkNCj4g5pS25Lu25Lq6OiBk b25neXVlIChEKSA8ZG9uZ3l1ZTZAaHVhd2VpLmNvbT47IFJvbGFuZCBEb2JiaW5zDQo+IDxyZG9i Ymluc0BhcmJvci5uZXQ+OyBkb3RzIDxkb3RzQGlldGYub3JnPg0KPiDkuLvpopg6IFJFOiBbRG90 c10gZHJhZnQtaWV0Zi1kb3RzLXVzZS1jYXNlcy0wOSBwb3N0ZWQgLSBwbGVhc2UgcmV2aWV3IGFu ZA0KPiBwcm92aWRlIGZlZWRiYWNrLg0KPiANCj4gRGVhciBZdWUsDQo+IA0KPiBQbGVhc2Ugc2Vl IGlubGluZS4NCj4gDQo+IENoZWVycywNCj4gTWVkDQo+IA0KPiA+IC0tLS0tTWVzc2FnZSBkJ29y aWdpbmUtLS0tLQ0KPiA+IERlIDogRG90cyBbbWFpbHRvOmRvdHMtYm91bmNlc0BpZXRmLm9yZ10g RGUgbGEgcGFydCBkZSBkb25neXVlIChEKQ0KPiA+IEVudm95w6kgOiBsdW5kaSAyNyBub3ZlbWJy ZSAyMDE3IDA3OjM0IMOAIDogUm9sYW5kIERvYmJpbnM7IGRvdHMgT2JqZXQgOg0KPiA+IFJlOiBb RG90c10gZHJhZnQtaWV0Zi1kb3RzLXVzZS1jYXNlcy0wOSBwb3N0ZWQgLSBwbGVhc2UgcmV2aWV3 IGFuZA0KPiA+IHByb3ZpZGUgZmVlZGJhY2suDQo+ID4NCj4gPiBIZXJlIGFyZSBhIGZldyBxdWVz dGlvbnMvY29tbWVudHMgb24gdGhlIHVzZSBjYXNlczoNCj4gPg0KPiA+ICogc2VjdGlvbiAzLjEu MS4xLCBwYXJhZ3JhcGggNyAtLSBJbiB0aGlzIHBhcmFncmFwaCwgdGhlIERPVFMgc2VydmVyDQo+ ID4gd2lsbCBzZW5kIGEgY29uZmlybWF0aW9uIHRvIHRoZSBlbnRlcnByaXNlIElETVMgRE9UUyBj bGllbnQgb25jZSB0aGUNCj4gPiBtaXRpZ2F0aW9uIGhhcyBhbHJlYWR5IGJlZW4gZW5kZWQuIEhv d2V2ZXIsIHRvIHRoZSBiZXN0IG9mIG15DQo+ID4ga25vd2xlZGdlLCB0aGlzIGZlYXR1cmUgZG9l cyBub3QgZXhpc3QgaW4gdGhlIERPVFMgc2lnbmFsIGNoYW5uZWwgZHJhZnQuDQo+IA0KPiBbTWVk XSBBIGRvdHMgY2xpZW50IGNhbiByZXRyaWV2ZSB0aGUgc3RhdHVzIG9mIGFuIG9uZ29pbmcgbWl0 aWdhdGlvbiByZXF1ZXN0DQo+IGJ5IHBlcmlvZGljYWxseSBwb2tpbmcgdGhlIHNlcnZlciBvciBi eSBzdWJzY3JpYmluZyB0byB1bnNvbGljaXRlZCBub3RpZmljYXRpb25zLg0KPiBCZWxvdyBhbiBl eGFtcGxlIGZyb20gdGhlIHNpZ25hbC1jaGFubmVsIGRyYWZ0IHRvIGlsbHVzdHJhdGUgdGhpcyAg YmVoYXZpb3I6DQo+IA0KPiAgICAgICAgICAgICAgICAgICAgICAgIERPVFMgQ2xpZW50ICAgICAg ICAgICAgRE9UUyBTZXJ2ZXINCj4gICAgICAgICAgICAgICAgICAgICAgICAgICB8ICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIHwNCj4gICAgICAgICAgICAgICAgICAgICAgICAgICB8ICBH RVQgLzxtaXRpZ2F0aW9uLWlkIG51bWJlcj4gIHwNCj4gICAgICAgICAgICAgICAgICAgICAgICAg ICB8ICBUb2tlbjogMHg0YSAgICAgICAgICAgICAgICAgIHwgICBSZWdpc3RyYXRpb24NCj4gICAg ICAgICAgICAgICAgICAgICAgICAgICB8ICBPYnNlcnZlOiAwICAgICAgICAgICAgICAgICAgIHwN Cj4gICAgICAgICAgICAgICAgICAgICAgICAgICArLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tPnwNCj4gICAgICAgICAgICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIHwNCj4gICAgICAgICAgICAgICAgICAgICAgICAgICB8ICAyLjA1IENvbnRlbnQg ICAgICAgICAgICAgICAgIHwNCj4gICAgICAgICAgICAgICAgICAgICAgICAgICB8ICBUb2tlbjog MHg0YSAgICAgICAgICAgICAgICAgIHwgICBOb3RpZmljYXRpb24gb2YNCj4gICAgICAgICAgICAg ICAgICAgICAgICAgICB8ICBPYnNlcnZlOiAxMiAgICAgICAgICAgICAgICAgIHwgICB0aGUgY3Vy cmVudCBzdGF0ZQ0KPiAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgIHN0YXR1czogIm1pdGln YXRpb24gICAgICAgICAgfA0KPiAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgICAgICAgICAg aW4gcHJvZ3Jlc3MiICAgICAgICAgfA0KPiAgICAgICAgICAgICAgICAgICAgICAgICAgIHw8LS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKw0KPiAgICAgICAgICAgICAgICAgICAgICAgICAg IHwgIDIuMDUgQ29udGVudCAgICAgICAgICAgICAgICAgfA0KPiAgICAgICAgICAgICAgICAgICAg ICAgICAgIHwgIFRva2VuOiAweDRhICAgICAgICAgICAgICAgICAgfCAgIE5vdGlmaWNhdGlvbiB1 cG9uDQo+ICAgICAgICAgICAgICAgICAgICAgICAgICAgfCAgT2JzZXJ2ZTogNDQgICAgICAgICAg ICAgICAgICB8ICAgIGEgc3RhdGUgY2hhbmdlDQo+ICAgICAgICAgICAgICAgICAgICAgICAgICAg fCAgc3RhdHVzOiAibWl0aWdhdGlvbiAgICAgICAgICB8DQo+ICAgICAgICAgICAgICAgICAgICAg ICAgICAgfCAgICAgICAgICBjb21wbGV0ZSIgICAgICAgICAgICB8DQo+ICAgICAgICAgICAgICAg ICAgICAgICAgICAgfDwtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rDQo+ICAgICAgICAg ICAgICAgICAgICAgICAgICAgfCAgMi4wNSBDb250ZW50ICAgICAgICAgICAgICAgICB8DQo+ICAg ICAgICAgICAgICAgICAgICAgICAgICAgfCAgVG9rZW46IDB4NGEgICAgICAgICAgICAgICAgICB8 ICAgTm90aWZpY2F0aW9uIHVwb24NCj4gICAgICAgICAgICAgICAgICAgICAgICAgICB8ICBPYnNl cnZlOiA2MCAgICAgICAgICAgICAgICAgIHwgICBhIHN0YXRlIGNoYW5nZQ0KPiAgICAgICAgICAg ICAgICAgICAgICAgICAgIHwgIHN0YXR1czogImF0dGFjayBzdG9wcGVkIiAgICAgfA0KPiAgICAg ICAgICAgICAgICAgICAgICAgICAgIHw8LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKw0K PiAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgfA0KPiANCj4gDQo+IFdpbGwgeW91IHN1Z2dlc3QgdGhpcyB0bw0KPiA+IGJlIGFkZGVkIGlu IHRoZSBzaWduYWwgY2hhbm5lbD8NCj4gPg0KPiA+ICogc2VjdGlvbiAzLjEuMi4xLiAsIHBhcmFn cmFwaCA1IC0tIEluIHRoaXMgcGFyYWdyYXBoIHRoZSB0aW1lIHRvIGxpdmUNCj4gPiAoVFRMKSBp cyBwcm9wb3NlZCB0byBiZSBpbmNsdWRlZCBpbiB0aGUgbWl0aWdhdGlvbiByZXF1ZXN0IGFzIGFu DQo+ID4gYWx0ZXJuYXRpdmUgd2F5IHRvIHRlcm1pbmF0ZSB0aGUgbWl0aWdhdGlvbi4gSW4gbXkg b3BpbmlvbiwgdGhlIFRUTA0KPiA+IGFwcHJvYWNoIGNvdWxkIGJlIHVzZWQgaW4gYWxsIHRoZSBE T1RTIHVzZSBjYXNlIHNjZW5hcmlvcy4gSGVuY2UgSQ0KPiA+IHJlY29tbWVuZCB0byBleHBsYWlu IGl0IGluIHRoZSB2ZXJ5IGZpcnN0IHVzZSBjYXNlIGluIDMuMS4xLjEuLA0KPiA+IG90aGVyd2lz ZSBpdCBsb29rcyBvbmx5IGJlIHVzZWQgaW4gdXNlIGNhc2VzIHRoYXQgTVNTUCBvZmZlcmluZyB0 aGUNCj4gPiBtaXRpZ2F0aW9uIHNlcnZpY2VzLg0KPiA+DQo+ID4gKiBzZWN0aW9uIDMuMi4yLiAt LSAgRmlyc3RseSwgdGhpcyB1c2UgY2FzZSBwbGFjZWQgdG9vIG11Y2ggZW1waGFzaXMNCj4gPiBv biBob3cgdGhlIEREb1MgYXR0YWNrIGlzIGRldGVjdGVkLiBTZWNvbmRseSwgSSB0aGluayBpdCBp cyBiZXR0ZXIgdG8NCj4gPiBoYXZlIGEgc2NoZW1hdGljIGRpYWdyYW0gKGxpa2UgdGhlIGZpZ3Vy ZSBpbiBzZWN0aW9uIDMuMi4zKSB0byBzaG93DQo+ID4gdGhlIGFyY2hpdGVjdHVyZSBhbmQgZXhw bGFpbiB0aGUgd29yayBmbG93IGluIGRldGFpbCB0byBzaG93IGhvdyB0aGUNCj4gPiBET1RTIHBy b3RvY29sIHdvcmtzIGluIHRoaXMgc2NlbmFyaW8uDQo+ID4NCj4gPiAqIHNlY3Rpb24gMy4yLjIu IC0tIHRoZSBsYXN0IHBhcmFncmFwaCBvbiBwYWdlIDE3LCBsaW5lNywgICAncmF0aGVyIHRoZW4n DQo+ID4gLS0+ICdyYXRoZXIgdGhhbicNCj4gPiAqIHNlY3Rpb24gMy4yLjIuIC0tIHRoZSBzZWNv bmQgcGFyYWdyYXBoIG9uIHBhZ2UgMTgsIGxpbmUgMSwgJ2l0DQo+ID4gbm90aWZpZXMgYXV0b21h dGljYWxseSBvciB0aGUgSVNQJyAtLT4gJ2l0IG5vdGlmaWVzIGF1dG9tYXRpY2FsbHkgdG8gdGhl IElTUCcNCj4gPiAqIHNlY3Rpb24gMy4yLjIuIC0tIHRoZSBmb3VydGggcGFyYWdyYXBoIG9uIHBh Z2UgMTgsIGxpbmUgMywgJ3RyYWZmaWMNCj4gPiBwYXR0ZXInIC0tPiAndHJhZmZpYyBwYXR0ZXJu Jw0KPiA+DQo+ID4gQmVzdCBSZWdhcmRzLA0KPiA+IFl1ZQ0KPiA+DQo+ID4NCj4gPiAtLS0tLemC ruS7tuWOn+S7ti0tLS0tDQo+ID4g5Y+R5Lu25Lq6OiBEb3RzIFttYWlsdG86ZG90cy1ib3VuY2Vz QGlldGYub3JnXSDku6PooaggUm9sYW5kIERvYmJpbnMNCj4gPiDlj5HpgIHml7bpl7Q6IDIwMTfl ubQxMeaciDEz5pelIDY6MzkNCj4gPiDmlLbku7bkuro6IGRvdHMgPGRvdHNAaWV0Zi5vcmc+DQo+ ID4g5Li76aKYOiBbRG90c10gZHJhZnQtaWV0Zi1kb3RzLXVzZS1jYXNlcy0wOSBwb3N0ZWQgLSBw bGVhc2UgcmV2aWV3IGFuZA0KPiA+IHByb3ZpZGUgZmVlZGJhY2suDQo+ID4NCj4gPg0KPiA+IFdl J3ZlIHJlLW9yZ2FuaXplZCB0aGUgdXNlLWNhc2VzIHNvIHRoYXQgRE9UUyBpbXBsZW1lbnRvcnMg d29uJ3QgZmVlbA0KPiA+IGNvbXBlbGxlZCB0byByZWFkIHRocm91Z2ggbXVsdGlwbGUgdXNlLWNh c2VzIHdpdGggc2ltaWxhciBET1RTDQo+ID4gY29tbXVuaWNhdGlvbnMgbW9kZWxzLCB3aGlsZSBh dCB0aGUgc2FtZSB0aW1lIHJldGFpbmluZyB0aG9zZQ0KPiA+IHVzZS1jYXNlcyBiZWNhdXNlIHRo ZXkgY29udGFpbiBzaWduaWZpY2FudCBwcm9jZWR1cmFsLCBvcGVyYXRpb25hbCwNCj4gPiBhbmQg dG9wb2xvZ2ljYWwgdmFyaWFuY2VzIHdoaWNoIGFyZSBvZiBncmVhdCBzaWduaWZpY2FuY2UgdG8g bmV0d29yaw0KPiA+IG9wZXJhdG9ycyBhbmQgZW5kLSBjdXN0b21lciBvcmdhbml6YXRpb25zLg0K PiA+DQo+ID4gVGhlIHdvcmRpbmcgaW4gdGhlIERPVFMgY29tbXVuaWNhdGlvbnMgbW9kZWwgbGlz dGluZ3MgYW5kIHNldmVyYWwgb2YNCj4gPiB0aGUgdXNlLWNhc2VzIGhhcyBiZWVuIHN0cmVhbWxp bmVkLiAgVGhlIHNlY3VyaXR5IGNvbnNpZGVyYXRpb25zIHdlcmUNCj4gPiB1cGRhdGVkIHRvIGlu Y2x1ZGUgRERvUyBhdHRhY2tzLg0KPiA+DQo+ID4gRmluYWxseSwgd2UgcmVhbGx5IG5lZWQgV0cg ZmVlZGJhY2sgb24gdGhlIGFwcGxpY2FiaWxpdHkgb2YgU2VjdGlvbg0KPiA+IDMuMi4yLCAnSG9t ZSBOZXR3b3JrIEREb1MgRGV0ZWN0aW9uIENvbGxhYm9yYXRpb24gZm9yIElTUCBuZXR3b3JrDQo+ IG1hbmFnZW1lbnQnLg0KPiA+DQo+ID4gVGhhbmtzIG11Y2ghDQo+ID4NCj4gPiA8aHR0cHM6Ly9k YXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1kb3RzLXVzZS1jYXNlcy8+DQo+ID4N Cj4gPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiA+IFJvbGFuZCBEb2Ji aW5zIDxyZG9iYmluc0BhcmJvci5uZXQ+DQo+ID4NCj4gPiBfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+IERvdHMgbWFpbGluZyBsaXN0DQo+ID4gRG90 c0BpZXRmLm9yZw0KPiA+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZG90 cw0KPiA+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ ID4gRG90cyBtYWlsaW5nIGxpc3QNCj4gPiBEb3RzQGlldGYub3JnDQo+ID4gaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kb3RzDQo+IF9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fDQo+IERvdHMgbWFpbGluZyBsaXN0DQo+IERvdHNAaWV0 Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kb3RzDQo+IA0K PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBEb3Rz IG1haWxpbmcgbGlzdA0KPiBEb3RzQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vZG90cw0K From nobody Tue Nov 28 03:07:43 2017 Return-Path: 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 CAAA8124BE8 for ; Tue, 28 Nov 2017 03:07:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=thescout.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 GvmW_kU8p-ij for ; Tue, 28 Nov 2017 03:07:36 -0800 (PST) Received: from mx0a-00196b01.pphosted.com (mx0a-00196b01.pphosted.com [67.231.149.170]) (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 475C91200F3 for ; Tue, 28 Nov 2017 03:07:36 -0800 (PST) Received: from pps.filterd (m0072398.ppops.net [127.0.0.1]) by mx0a-00196b01.pphosted.com (8.16.0.21/8.16.0.21) with SMTP id vASB6CE5024688; Tue, 28 Nov 2017 06:07:28 -0500 Received: from nam02-sn1-obe.outbound.protection.outlook.com (mail-sn1nam02lp0024.outbound.protection.outlook.com [216.32.180.24]) by mx0a-00196b01.pphosted.com with ESMTP id 2egvx28jf8-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Tue, 28 Nov 2017 06:07:28 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=thescout.onmicrosoft.com; s=selector1-arbor-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=BrMObbrW5vvnj/1Tbf1/RPQx07n9uHw5DOSPh6DNaPM=; b=o2xravtbWZHKm21j+VNJrqL+dfzol9yNG7jdBCZGMz711Wd68MG16F+4jqn9XNPjFlREjpk/YlPHf9sF23nMZYx0T8scyTuBuZ6fCCxDgVBTy5PX4aKXTeJYibjFJ/eHy/BDcYRD/PlL/FMg7c3HHgF/Datl50TCw1i/KOogA+0= Received: from [172.21.0.4] (68.68.46.161) by DM2PR0101MB1037.prod.exchangelabs.com (2a01:111:e400:3c19::26) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.239.5; Tue, 28 Nov 2017 11:07:23 +0000 From: "Roland Dobbins" To: "Konda, Tirumaleswar Reddy" Cc: dongyue , "mohamed.boucadair@orange.com" , dots Date: Tue, 28 Nov 2017 18:07:16 +0700 Message-ID: <2FFEB802-6D97-4FF5-BA2B-E7DD9D14A4E9@arbor.net> In-Reply-To: References: <787AE7BB302AE849A7480A190F8B93300A07FDBD@OPEXCLILMA3.corporate.adroot.infra.ftgroup> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.7r5425) X-Originating-IP: [68.68.46.161] X-ClientProxiedBy: MWHPR20CA0014.namprd20.prod.outlook.com (2603:10b6:300:13d::24) To DM2PR0101MB1037.prod.exchangelabs.com (2a01:111:e400:3c19::26) X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: b4688b64-4ec4-4275-880f-08d5365034e7 X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(5600026)(4604075)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(2017052603199); SRVR:DM2PR0101MB1037; X-Microsoft-Exchange-Diagnostics: 1; DM2PR0101MB1037; 3:J2Aoqp2a1U403DtqljvZkzzXs6G6moFuux5WclpEdPbHydupWqgFx2S4ZVlur1y7QIdbyO10MHXPWBnJiq30yWEO/LEko8d6OiexvMSshU3p0wBB8aP5pD8gTh6x6QSRMaNQ5AHwxXEs2Th0ZfZKY1rbl+tr87ARAu1iZJjIzF4mTFAcePxStv25fVFOPh+l59304hUWm8TEfOOK0Wj9tB3IWwiQhFFhURCaTuWafj4+5xcQUtXNZKZmSH/n/x5R; 25:ucEYNFzPKCvw8h77fmRJxZ+LiT0LrW4/VChx1JkQT0egGXZSLjgGVXOeByhxxERmFUvzZvmp1ytT8CanN9uh8G+R8Ctm9OnI05zgPoC0G6j+ukvylLjc6mn2jvfx3W3g+UIIybmXcRv2GdmSV9P7uUmAk2PYxoWBuj2Hv5Wgiz50H5UU2237UNUWL8EDCWOQVuWr9fv3Rx6ywo8GZCi005C5Vc2I5mmTlB368AYQ9aaFVE8UfUMzfH3gkYrt1YKqsjiUpBPJnTD1O4fC8fYOOnLfNjtN+jQWJYKBApu+nqGUHsPg0u/ABDjRcl8GYIAOG4SOQn4z/sTcbpllPsTQWdDxyA5MS1Fr1Ij27r4+AAc=; 31:6PAfssXvKs/3vHLkZdm2puPT7KTYzVBNisooxPQvK4rLJ0q5/OwF/h3aaEOhqXYuxMmcsAVpvGbFLxwwla7KF9HIML1phoukGm3YPjHVBi3P9W4e4+iRUi1DPdf0Ll3KefCp5ri9pPiAmU52A0eDTQh9pe+xGvJSWJ8/Ef2DX7W1eHInfh0QvJHkxVNmgFcNa+fAgFTXNaRpt8KZK0bVd2vr4+0mgrV3YCw9yjyVriY= X-MS-TrafficTypeDiagnostic: DM2PR0101MB1037: X-Microsoft-Exchange-Diagnostics: 1; DM2PR0101MB1037; 20:uYRIssoID187cj9AbVhsPFrgnycOS0Mz8yUEaZPX9ezjEKJCWlzF2G0bF2uQpe5Y3tRWD1WVo897G/C/8dJGjd6eRT2yYAfrQwCCwtr5SY0jlxEq5laraSmzOtiK9Zcc5GLfezAlgS8FZnclmNTcFah/LM7WsvP2xPog1uxZ746kvHQQ4uZzSDNCWFK9bCwNoT/Q78R5m5QAl9wlrKYhX1QAfF/uYdwho5LkRrWF6GDtflC9LHUT/eTcjDvhCqIFNUwy5fh+JCZMYSeCLn4I7VAMOqgwJUPLDJwi2MB30yLw2fgHG5OfKwRUn1iiXnSPqP/RIfnzkqFnHV1pXrJBDw==; 4:rpa3rsawqNeywW08rgjZPYupzNXeBg6ABkokZsYyB7IzodkSpPu7TgwITNyMu2JV1iQDJbR9mvjmrmLN/Mucs8NCK86Kb+r7TCyv9DrTRMWAcowZrGWxST7hUtnteluauTcuxKHt3ZyeQfRNyjeVSyJfBoDhGYHFqDd0H2w19D/aTyKQWUNizmb5OgWyktrk6tYouki4Rlpbe/q/vRRR1Huf9PzTsNfF1p3sL3oZ92YhkyNpRmUmiFquYq3k3yGlZ0fuNfUvJCfI1txZA3WGHBYTmZ6gnggr6b/ALUobEaoz7zfubD4ze9CD3rz1hQsC X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(158342451672863); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040450)(2401047)(8121501046)(5005006)(93006095)(93001095)(3231022)(3002001)(10201501046)(6041248)(20161123562025)(20161123558100)(20161123560025)(20161123564025)(20161123555025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(6072148)(201708071742011); SRVR:DM2PR0101MB1037; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:DM2PR0101MB1037; X-Forefront-PRVS: 0505147DDB X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(6009001)(6049001)(366004)(376002)(346002)(24454002)(189002)(199003)(53936002)(6116002)(6246003)(86362001)(224303003)(33656002)(106356001)(67846002)(105586002)(82746002)(53546010)(5660300001)(189998001)(81156014)(2950100002)(6666003)(47776003)(93886005)(81166006)(50226002)(6916009)(4326008)(68736007)(478600001)(66066001)(7736002)(2906002)(51416003)(229853002)(305945005)(16526018)(3846002)(83716003)(16576012)(230783001)(101416001)(97736004)(8936002)(54906003)(50466002)(316002)(36756003)(76176999)(16586007)(52116002)(50986999)(25786009)(77096006)(6486002); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR0101MB1037; H:[172.21.0.4]; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Received-SPF: None (protection.outlook.com: arbor.net does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; DM2PR0101MB1037; 23:OKK8+QkXCuZlyd4bUmmgjGpDiYcRlGgq0G7zxba?= =?us-ascii?Q?ojR3dBXxK1Pt2KVD55/XTNSSYjcRmd313eVg1xjUmW+JesTTo6SEI9dNKm0N?= =?us-ascii?Q?3y5lbAt/jDo0TWfXVYNSaJuJGH3GCWSgf3s3zBI0BwGeZ+RwBuqtIqCfvcFW?= =?us-ascii?Q?QxrDTJ4o5tC7ino1SmO0W95PTUbevwdQtwk6cELs+0JbNeQP9lNl5Cd4RMqp?= =?us-ascii?Q?CIHaH0Gvqm6DOaSGKw+guTowQZmsZKC9cLRTBj7U40e1bA1NASZRXSBRZ2jH?= =?us-ascii?Q?fDdYOm528crUj21k0oEuj/XNEndxdNWz9jS7iUwq1KDE6JlTr41IeXjYXN8/?= =?us-ascii?Q?N6iJ2ZeDKpSCuISNMxA5P9W5GQ9bCxWO01pLoJPKpwcyv7yvSGGSGnHyiS/6?= =?us-ascii?Q?bIG+PvbGo4V5NtJrpwlSWeM2A9BqXrshrn3K+PhTc14d8jvj79eIM1WtLLg+?= =?us-ascii?Q?cW7gkSe2wa8wdAvpAXz/Mkof4/8RFJpZ61s0sr4yZpg9Y8/CeBF4BRkRWY5V?= =?us-ascii?Q?/75Qam5n2m1ZffBNLVaXXCgJnGShZvYnWGXy7AMyfp+WAXqgPUdQLvQ4gTTs?= =?us-ascii?Q?VYhl2HyXTAsci5Ag4tPcqIVOGzwbDLwGK10kRMlYTSG33sZabCn1HZbrCpEM?= =?us-ascii?Q?pKf46iu8/c8Tad6QsV78eSbRXpqaT9GqeSLSQcDu0ZpRneNCo58I7+kGe9EO?= =?us-ascii?Q?wOQfhE1++A6zaPtK3+Uu8hp4OdwuLg8ag1Gsk2AwF6OzdLHvfDm9fGcOp4bQ?= =?us-ascii?Q?6WLK8dTnQ+boOcraW28cuw/lkd6V0iYDHCPVzVXes0dStw32e6K5k+E5eiq/?= =?us-ascii?Q?7EFu3kLDLablcHlY0+KE3t1S6RcJdtAELPYXKlVmumgE38gTKJdZ2KCB9Aph?= =?us-ascii?Q?qgDZMx+ZizNQ9XIYyTUFF17DbeZ8mhFOvTqfmi3VE4GRT0zMwJLEhVFM3/5h?= =?us-ascii?Q?VshW0m05BtDbUbrTcj30zQl/sZsnkSiiUtTwD15bm81NbP3ilBmZzeA26vHI?= =?us-ascii?Q?RkRRKakwgxRX6BIUyUjalSlygUVWi256xol4sAj7fyP+cH32SsgRYe8KWUp9?= =?us-ascii?Q?FF9xya9rlS12E7+TbvKhBw84iJ+UlE0N3+Gnx4PtgP1uX8U3RHShFG8awUlL?= =?us-ascii?Q?+FYWRzXEuu6ZXAGlRHZoF7m28dpSe+sgx9B0URB9mhDnTeNFwvE+O5KMJH+M?= =?us-ascii?Q?c1yigd14Jr+dwMpW0kuJIeYb0rVkFwZl6eFEmaaKVmSXUKU6hPIcZ/tMSgo8?= =?us-ascii?Q?zapCUjrAbVnze31e3yol9xeErHyFQfj2VmFmNldEPWGZqDBEcEGtIcPpISas?= =?us-ascii?Q?yuxAuwfowJpJPEXRDGZhWKuQ=3D?= X-Microsoft-Exchange-Diagnostics: 1; DM2PR0101MB1037; 6:BZed5wCJy1utWCnlrBJn0aya/Bp+yIlfHMY1R2dYHke1v7k+BVBwBRygOCktZedsuEhqchH6Gnp4AYvCnpPoT7vFxFOwSXkwlwN3/fG7mBVR5SGaJlVR18tKHHJp4qEBJGPnfGWRrJ0QQLwREYhph8Pd2RJkhIMP/Q1d7XcujzDNcQHiejBgCg9iJe2gpmywEya8tyhy/si5ArG9NSo77u0qhU/qLiuzgXO+FhHnPbs8vqwdwZh8M0gx/KJ1/XCIF4Gjuyz0IXu4hWxoJL1BzNxh9Gw9gOQT89OmBb40WO4/OIeUGmjtt5A/jZyPXyiS56vCDIpkNi1U5GIUGAXvjDeNlDz+nS+JhznAjm6cCX4=; 5:MuiJ9zSlR0cLHlTha8VOini36ObujVAuglCnbKh2jiaYvHjj/bBmPFhoza1gC5fKBtLi5LfIYFnKp+p+aox0aMhrD1GnTOr49pJ7w6qc9vVqiiRL3Do1nZOGcONjVb3C162wDuMt3SYMCPu8z7dHZNUSI9ypSgsxDY3U7re6mjA=; 24:UEYgG8jbqjxDi9RPlSvqsl+WKjgPcLIp+4+krT8oHk60lfzH8hyC1Rn5hbaCEDhViv+MaZfnuodx6w3eR1uvAeco7tErA1dBBul+aNU2oaw=; 7:4kANMDgrTc8xaeLkFW31RK1QrsaIg7yhUlsXbIGIgfxd/34C7GmnOvfdQjIhN0QyoVNanqxPYLc5UHaGBUzw1Fb2gHAp2hnAfAIUnRqJ7695BaAoxte0DeLOfJxgrlIYlteAngRUU7ARmW/jDITa0b88LERg+Pi3N5UM5HE9+4ITe6mCK4CZ8P7D976Adxn+1lEWLaq+6gydJPD4yuFycMEy0TB3sUOI/o0E2zBkd52J/qGIWVSExsBDOOweDoHZ SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: arbor.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 28 Nov 2017 11:07:23.8321 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: b4688b64-4ec4-4275-880f-08d5365034e7 X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 54f11205-d4aa-4809-bd36-0b542199c5b2 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR0101MB1037 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-11-28_07:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1709140000 definitions=main-1711280150 Archived-At: Subject: Re: [Dots] =?utf-8?b?562U5aSNOiBkcmFmdC1pZXRmLWRvdHMtdXNlLWNhc2Vz?= =?utf-8?q?-09_posted_-_please_review_and_provide_feedback=2E?= 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Nov 2017 11:07:43 -0000 On 28 Nov 2017, at 17:42, Konda, Tirumaleswar Reddy wrote: > However, if we think it's useful the DOTS server can send a mitigation > terminated message just before removing the mitigation request. Very much so, yes. This is the kind of thing which makes DOTS useful. ----------------------------------- Roland Dobbins From nobody Tue Nov 28 03:15:36 2017 Return-Path: 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 77A3D124B18 for ; Tue, 28 Nov 2017 03:15:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.5 X-Spam-Level: X-Spam-Status: No, score=-5.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_SORBS_WEB=1.5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 DLcWggTGcxJv for ; Tue, 28 Nov 2017 03:15:33 -0800 (PST) Received: from MIVWSMAILOUT1.mcafee.com (mivwsmailout1.mcafee.com [161.69.47.167]) (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 BCBDF124BE8 for ; Tue, 28 Nov 2017 03:15:31 -0800 (PST) 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=1511865774; 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: x-originating-ip:x-ms-publictraffictype:x-microsoft-exchange-diagnostics: x-ms-exchange-antispam-srfa-diagnostics:x-ms-office365-filtering-correlation-id: x-microsoft-antispam:x-ms-traffictypediagnostic: authentication-results:x-microsoft-antispam-prvs: x-exchange-antispam-report-test:x-exchange-antispam-report-cfa-test: x-forefront-prvs:x-forefront-antispam-report: received-spf:spamdiagnosticoutput:spamdiagnosticmetadata: 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-Transport-CrossTenantHeadersStamped: X-OriginatorOrg:X-NAI-Spam-Flag:X-NAI-Spam-Level: X-NAI-Spam-Threshold:X-NAI-Spam-Score:X-NAI-Spam-Version; bh=iaLbqBwMUGuuPuBr8UeX4KGRAi/0QcIzYmri8O FJKqM=; b=INKLrzMXVzziaDhGaaVJFDHPL0o338xEiNEqT2yM 2+YMAXJLLAjdJc4VkcnILvBhNL3d6STrcgsjv1lOQcYt1a0TaK 5XOlPstJqQVHLKzkHZ+nKMvrdNJgnvGm7lOy+tQboqM6gkjHW+ yDyZvJR0y8wUKMyH0JAdu6gACZVzqB8= Received: from MIVEXAPP1N03.corpzone.internalzone.com (mivexapp1n03.corpzone.internalzone.com [10.48.48.90]) by MIVWSMAILOUT1.mcafee.com with smtp id 4149_f857_cbcaa98c_456e_4f0b_89d8_47c317b55934; Tue, 28 Nov 2017 04:42:54 -0600 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.1347.2; Tue, 28 Nov 2017 05:42:10 -0500 Received: from MIVEXUSR1N01.corpzone.internalzone.com (10.48.48.81) by MIVEXUSR1N07.corpzone.internalzone.com (10.48.48.87) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Tue, 28 Nov 2017 05:42:09 -0500 Received: from MIVO365EDGE3.corpzone.internalzone.com (10.48.176.86) by MIVEXUSR1N01.corpzone.internalzone.com (10.48.48.81) with Microsoft SMTP Server (TLS) id 15.0.1347.2 via Frontend Transport; Tue, 28 Nov 2017 05:42:09 -0500 Received: from NAM03-DM3-obe.outbound.protection.outlook.com (10.48.176.243) by edge.mcafee.com (10.48.176.86) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Tue, 28 Nov 2017 05:42:06 -0500 Received: from DM5PR16MB1788.namprd16.prod.outlook.com (10.172.44.144) by DM5PR16MB1788.namprd16.prod.outlook.com (10.172.44.144) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.260.4; Tue, 28 Nov 2017 10:42:06 +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.20.0260.006; Tue, 28 Nov 2017 10:42:06 +0000 From: "Konda, Tirumaleswar Reddy" To: "dongyue (D)" , "mohamed.boucadair@orange.com" , Roland Dobbins , dots Thread-Topic: =?utf-8?B?W0RvdHNdIOetlOWkjTogIGRyYWZ0LWlldGYtZG90cy11c2UtY2FzZXMtMDkg?= =?utf-8?Q?posted_-_please_review_and_provide_feedback.?= Thread-Index: AQHTZ/g+U11Cmxyg0E2fZOTFV5nspKMpl+DA Date: Tue, 28 Nov 2017 10:42:06 +0000 Message-ID: References: <787AE7BB302AE849A7480A190F8B93300A07FDBD@OPEXCLILMA3.corporate.adroot.infra.ftgroup> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [122.172.38.74] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DM5PR16MB1788; 6:iBQeIHcZhpE16KEZo+4mDYPVqt5tluTOUYPR5wjso0KgYL740n+7BA8HraxyJBvPzSFR8/RSVu9NTWGrwgY2p6geMIPw1T0Q/B6xG1pOSzs3S/xNOnFNMIXfs0lsS0dpxswlRueGdZRxFPNOvKJR69WaGflVapIUK9PBqxOzUu/LguDx54Mbh8fCqmjtVX4PDuNbfbJKiNsjgzk18u0j3ogtb9nInP190mJ2/1owlmHGnzAW+1/BXZ5Ffln/Eb6LE7nVViIco7aDUmAGilpWTD4YcAT7oVGQKwgofnCe52rcsSAt+5EkbFGTUedZqWEqJdC++aoU0aV1sHHTxvfR2iptfWEuCXvBmYrBJEPReNg=; 5:4hwDxYBbagP9jcTNgVxpECMOOeL6exSGyXcy5bicO7FcioEsh3pjfmDo7xrdmpuRdMWpPsY1IizWD+Pi9/8psqs8eucAJvEzmsMr+Tz79Ep5ZpTSfkboCdZnDM+uwrxUF3nezZZG9a9wTQPhjl+bjHAdCA8wK6Hx4tNGdF2d8/0=; 24:Hgjm3BkR8b2YANK5k3CbcMTAYq3f2tHJ0RIpWHycidO3AuO4nMrpc7zukE07Ga1hSh0srptLp/jW9qeib3x4zuC1U45M2SBnWj7x6R0fmNw=; 7:bzqe5Zcy40zNExB4p5GeM9SoCaN+K49A4va78C+DeLwFOs+96Yi0mkbw8Kc4tZD+4/lxTKYui5WrgtYzDBNoxy5IaWzKxoFt+6Br0R3pT4mpB92RoTerpTy7qNUwpOBQO9Min1bjN2vf9pgu3jNfidFBJJxpl9qAVkArmVeOXrjrCQbfnp+DFPKlKhBHzPRbSLjAwu3FTE5Ti4Mc4ZGtuF5l+OHpCl79GfFwEDMnT8LE2IZ0R4EiMGX+SzOlCzTL x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 996f0910-2a34-4301-08f9-08d5364caba1 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(5600026)(4604075)(2017052603258); SRVR:DM5PR16MB1788; x-ms-traffictypediagnostic: DM5PR16MB1788: authentication-results: spf=none (sender IP is ) smtp.mailfrom=TirumaleswarReddy_Konda@McAfee.com; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(190756311086443)(158342451672863)(120809045254105)(192374486261705)(50582790962513)(18271650672692)(231250463719595); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(2401047)(8121501046)(5005006)(10201501046)(3002001)(93006095)(93001095)(3231022)(6041248)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123564025)(20161123562025)(20161123558100)(20161123555025)(20161123560025)(6072148)(201708071742011); SRVR:DM5PR16MB1788; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:DM5PR16MB1788; x-forefront-prvs: 0505147DDB x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(366004)(39860400002)(346002)(376002)(13464003)(199003)(55784002)(32952001)(189002)(33656002)(2900100001)(106356001)(105586002)(224303003)(230783001)(6116002)(3280700002)(8936002)(102836003)(3846002)(68736007)(3660700001)(2906002)(7696005)(478600001)(72206003)(14454004)(966005)(110136005)(53546010)(2501003)(305945005)(97736004)(80792005)(316002)(25786009)(99286004)(81156014)(53936002)(7736002)(74316002)(81166006)(6506006)(55016002)(6436002)(229853002)(189998001)(77096006)(6246003)(76176999)(2950100002)(9686003)(66066001)(5660300001)(101416001)(54356999)(6306002)(50986999)(86362001)(85282002); DIR:OUT; SFP:1101; SCL:1; SRVR:DM5PR16MB1788; H:DM5PR16MB1788.namprd16.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: McAfee.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 996f0910-2a34-4301-08f9-08d5364caba1 X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Nov 2017 10:42:06.5946 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4943e38c-6dd4-428c-886d-24932bc2d5de X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR16MB1788 X-OriginatorOrg: mcafee.com X-NAI-Spam-Flag: NO X-NAI-Spam-Level: X-NAI-Spam-Threshold: 15 X-NAI-Spam-Score: 0.1 X-NAI-Spam-Version: 2.3.0.9418 : core <6167> : inlines <6186> : streams <1771570> : uri <2541462> Archived-At: Subject: Re: [Dots] =?utf-8?b?562U5aSNOiAgZHJhZnQtaWV0Zi1kb3RzLXVzZS1jYXNl?= =?utf-8?q?s-09_posted_-_please_review_and_provide_feedback=2E?= 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Nov 2017 11:15:35 -0000 QWZ0ZXIgdGhlIG1pdGlnYXRpb24gcmVxdWVzdCBpcyB3aXRoZHJhd24gYnkgdGhlIERPVFMgY2xp ZW50IGFuZCBtaXRpZ2F0aW9uIGlzIHRlcm1pbmF0ZWQgYnkgdGhlIG1pdGlnYXRvciwgdGhlIG1p dGlnYXRpb24gcmVxdWVzdCBpcyByZW1vdmVkIGFuZCB0aGUgRE9UUyBjbGllbnQgY2Fubm90IGdl dCBhbnkgc3RhdHVzIG1lc3NhZ2VzIHJlZ2FyZGluZyB0aGUgbWl0aWdhdGlvbiBzdGF0dXMuIEhv d2V2ZXIsIGlmIHdlIHRoaW5rIGl0J3MgdXNlZnVsIHRoZSBET1RTIHNlcnZlciBjYW4gc2VuZCBh IG1pdGlnYXRpb24gdGVybWluYXRlZCBtZXNzYWdlIGp1c3QgYmVmb3JlIHJlbW92aW5nIHRoZSBt aXRpZ2F0aW9uIHJlcXVlc3QuDQoNCi1UaXJ1DQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0t LS0NCj4gRnJvbTogRG90cyBbbWFpbHRvOmRvdHMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxm IE9mIGRvbmd5dWUgKEQpDQo+IFNlbnQ6IFR1ZXNkYXksIE5vdmVtYmVyIDI4LCAyMDE3IDg6NTMg QU0NCj4gVG86IG1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb207IFJvbGFuZCBEb2JiaW5zDQo+ IDxyZG9iYmluc0BhcmJvci5uZXQ+OyBkb3RzIDxkb3RzQGlldGYub3JnPg0KPiBTdWJqZWN0OiBb RG90c10g562U5aSNOiBkcmFmdC1pZXRmLWRvdHMtdXNlLWNhc2VzLTA5IHBvc3RlZCAtIHBsZWFz ZSByZXZpZXcgYW5kDQo+IHByb3ZpZGUgZmVlZGJhY2suDQo+IA0KPiBIaSBNZWQsDQo+IA0KPiBU aGFua3MgZm9yIHlvdXIgcmVwbHkhDQo+IA0KPiBBY2NvcmRpbmcgdG8gdGhlIHVzZSBjYXNlLCBm aXJzdGx5IHdoZW4gYSBjbGllbnQgcmVxdWVzdCB0byB0ZXJtaW5hdGUgYQ0KPiBtaXRpZ2F0aW9u LCB0aGUgc2VydmVyIGhhcyB0byBzZW5kIGEgc3RhdHVzIG1lc3NhZ2UgKG1pdGlnYXRpb24gaXMg YWN0aXZlIGJ1dA0KPiB0ZXJtaW5hdGluZywgbGlzdGVkIGluIHRoZSB0YWJsZSBpbiBwYWdlIDI4 IGluIHNpZ25hbCBjaGFubmVsIGRyYWZ0KS4gVGhlbiwgdGhlDQo+IG1pdGlnYXRpb24gaXMgZXhh Y3RseSB0ZXJtaW5hdGVkIGJ5IHRoZSBtaXRpZ2F0b3IsIHRoZSBzZXZlciByZXF1aXJlcyB0byBz ZW5kDQo+IGFub3RoZXIgc3RhdHVzIG1lc3NhZ2UgKG5vdCBsaXN0ZWQgaW4gdGhlIHRhYmxlKSB0 byBjb25maXJtIHRoZSB0ZXJtaW5hdGlvbi4gSQ0KPiBqdXN0IGVucXVpcmVzIGlmIHRoZSBzZWNv bmQgc3RhZ2Ugc2hvdWxkIGJlIGV4cGxhaW5lZCBpbiB0aGUgc2lnbmFsIGNoYW5uZWwNCj4gZHJh ZnQuDQo+IEZvciB0aGUgc3Vic2NyaWJpbmcgYXBwcm9hY2gsIHRoZSBzZXJ2ZXIgd2lsbCBzZW5k IHRoZSBub3RpZmljYXRpb25zIHVwb24gdGhlDQo+IHN0YXR1cyBjaGFuZ2UuIFRoaXMgYXBwcm9h Y2ggaXMgb2suDQo+IEZvciBhbm90aGVyIGFwcHJvYWNoLCBuYW1lbHkgdGhlIGNsaWVudCBzZW5k aW5nIHN0YXR1cyByZXF1ZXN0IHBlcmlvZGljYWxseSwNCj4gdGhlIHRpbWUgdG8gc3RvcCBzZW5k aW5nIHRoZSBzdGF0dXMgcmVxdWVzdCBpcyBhbm90aGVyIGlzc3VlIHRoYXQgbmVlZCB0byBiZQ0K PiBkZXRlcm1pbmVkIGJ5IHRoZSBtaXRpZ2F0aW9uIHRlcm1pbmF0aW9uIHN0YXR1cyBtZXNzYWdl LiBCZWNhdXNlIEkgdGhpbmsgaXQNCj4gaXMgdW5uZWNlc3NhcnkgdG8gYWx3YXlzIHNlbmQgdGhl IHN0YXR1cyByZXF1ZXN0IGlmIHRoZSBtaXRpZ2F0aW9uIGlzIHN0b3BwZWQuDQo+IA0KPiBCZXN0 IFJlZ2FyZHMsDQo+IFl1ZQ0KPiANCj4gLS0tLS3pgq7ku7bljp/ku7YtLS0tLQ0KPiDlj5Hku7bk uro6IG1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20NCj4gW21haWx0bzptb2hhbWVkLmJvdWNh ZGFpckBvcmFuZ2UuY29tXQ0KPiDlj5HpgIHml7bpl7Q6IDIwMTflubQxMeaciDI35pelIDE1OjE5 DQo+IOaUtuS7tuS6ujogZG9uZ3l1ZSAoRCkgPGRvbmd5dWU2QGh1YXdlaS5jb20+OyBSb2xhbmQg RG9iYmlucw0KPiA8cmRvYmJpbnNAYXJib3IubmV0PjsgZG90cyA8ZG90c0BpZXRmLm9yZz4NCj4g 5Li76aKYOiBSRTogW0RvdHNdIGRyYWZ0LWlldGYtZG90cy11c2UtY2FzZXMtMDkgcG9zdGVkIC0g cGxlYXNlIHJldmlldyBhbmQNCj4gcHJvdmlkZSBmZWVkYmFjay4NCj4gDQo+IERlYXIgWXVlLA0K PiANCj4gUGxlYXNlIHNlZSBpbmxpbmUuDQo+IA0KPiBDaGVlcnMsDQo+IE1lZA0KPiANCj4gPiAt LS0tLU1lc3NhZ2UgZCdvcmlnaW5lLS0tLS0NCj4gPiBEZcKgOiBEb3RzIFttYWlsdG86ZG90cy1i b3VuY2VzQGlldGYub3JnXSBEZSBsYSBwYXJ0IGRlIGRvbmd5dWUgKEQpDQo+ID4gRW52b3nDqcKg OiBsdW5kaSAyNyBub3ZlbWJyZSAyMDE3IDA3OjM0IMOAwqA6IFJvbGFuZCBEb2JiaW5zOyBkb3Rz IE9iamV0wqA6DQo+ID4gUmU6IFtEb3RzXSBkcmFmdC1pZXRmLWRvdHMtdXNlLWNhc2VzLTA5IHBv c3RlZCAtIHBsZWFzZSByZXZpZXcgYW5kDQo+ID4gcHJvdmlkZSBmZWVkYmFjay4NCj4gPg0KPiA+ IEhlcmUgYXJlIGEgZmV3IHF1ZXN0aW9ucy9jb21tZW50cyBvbiB0aGUgdXNlIGNhc2VzOg0KPiA+ DQo+ID4gKiBzZWN0aW9uIDMuMS4xLjEsIHBhcmFncmFwaCA3IC0tIEluIHRoaXMgcGFyYWdyYXBo LCB0aGUgRE9UUyBzZXJ2ZXINCj4gPiB3aWxsIHNlbmQgYSBjb25maXJtYXRpb24gdG8gdGhlIGVu dGVycHJpc2UgSURNUyBET1RTIGNsaWVudCBvbmNlIHRoZQ0KPiA+IG1pdGlnYXRpb24gaGFzIGFs cmVhZHkgYmVlbiBlbmRlZC4gSG93ZXZlciwgdG8gdGhlIGJlc3Qgb2YgbXkNCj4gPiBrbm93bGVk Z2UsIHRoaXMgZmVhdHVyZSBkb2VzIG5vdCBleGlzdCBpbiB0aGUgRE9UUyBzaWduYWwgY2hhbm5l bCBkcmFmdC4NCj4gDQo+IFtNZWRdIEEgZG90cyBjbGllbnQgY2FuIHJldHJpZXZlIHRoZSBzdGF0 dXMgb2YgYW4gb25nb2luZyBtaXRpZ2F0aW9uIHJlcXVlc3QNCj4gYnkgcGVyaW9kaWNhbGx5IHBv a2luZyB0aGUgc2VydmVyIG9yIGJ5IHN1YnNjcmliaW5nIHRvIHVuc29saWNpdGVkIG5vdGlmaWNh dGlvbnMuDQo+IEJlbG93IGFuIGV4YW1wbGUgZnJvbSB0aGUgc2lnbmFsLWNoYW5uZWwgZHJhZnQg dG8gaWxsdXN0cmF0ZSB0aGlzICBiZWhhdmlvcjoNCj4gDQo+ICAgICAgICAgICAgICAgICAgICAg ICAgRE9UUyBDbGllbnQgICAgICAgICAgICBET1RTIFNlcnZlcg0KPiAgICAgICAgICAgICAgICAg ICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfA0KPiAgICAgICAgICAg ICAgICAgICAgICAgICAgIHwgIEdFVCAvPG1pdGlnYXRpb24taWQgbnVtYmVyPiAgfA0KPiAgICAg ICAgICAgICAgICAgICAgICAgICAgIHwgIFRva2VuOiAweDRhICAgICAgICAgICAgICAgICAgfCAg IFJlZ2lzdHJhdGlvbg0KPiAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgIE9ic2VydmU6IDAg ICAgICAgICAgICAgICAgICAgfA0KPiAgICAgICAgICAgICAgICAgICAgICAgICAgICstLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0+fA0KPiAgICAgICAgICAgICAgICAgICAgICAgICAgIHwg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfA0KPiAgICAgICAgICAgICAgICAgICAgICAg ICAgIHwgIDIuMDUgQ29udGVudCAgICAgICAgICAgICAgICAgfA0KPiAgICAgICAgICAgICAgICAg ICAgICAgICAgIHwgIFRva2VuOiAweDRhICAgICAgICAgICAgICAgICAgfCAgIE5vdGlmaWNhdGlv biBvZg0KPiAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgIE9ic2VydmU6IDEyICAgICAgICAg ICAgICAgICAgfCAgIHRoZSBjdXJyZW50IHN0YXRlDQo+ICAgICAgICAgICAgICAgICAgICAgICAg ICAgfCAgc3RhdHVzOiAibWl0aWdhdGlvbiAgICAgICAgICB8DQo+ICAgICAgICAgICAgICAgICAg ICAgICAgICAgfCAgICAgICAgICBpbiBwcm9ncmVzcyIgICAgICAgICB8DQo+ICAgICAgICAgICAg ICAgICAgICAgICAgICAgfDwtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rDQo+ICAgICAg ICAgICAgICAgICAgICAgICAgICAgfCAgMi4wNSBDb250ZW50ICAgICAgICAgICAgICAgICB8DQo+ ICAgICAgICAgICAgICAgICAgICAgICAgICAgfCAgVG9rZW46IDB4NGEgICAgICAgICAgICAgICAg ICB8ICAgTm90aWZpY2F0aW9uIHVwb24NCj4gICAgICAgICAgICAgICAgICAgICAgICAgICB8ICBP YnNlcnZlOiA0NCAgICAgICAgICAgICAgICAgIHwgICAgYSBzdGF0ZSBjaGFuZ2UNCj4gICAgICAg ICAgICAgICAgICAgICAgICAgICB8ICBzdGF0dXM6ICJtaXRpZ2F0aW9uICAgICAgICAgIHwNCj4g ICAgICAgICAgICAgICAgICAgICAgICAgICB8ICAgICAgICAgIGNvbXBsZXRlIiAgICAgICAgICAg IHwNCj4gICAgICAgICAgICAgICAgICAgICAgICAgICB8PC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLSsNCj4gICAgICAgICAgICAgICAgICAgICAgICAgICB8ICAyLjA1IENvbnRlbnQgICAg ICAgICAgICAgICAgIHwNCj4gICAgICAgICAgICAgICAgICAgICAgICAgICB8ICBUb2tlbjogMHg0 YSAgICAgICAgICAgICAgICAgIHwgICBOb3RpZmljYXRpb24gdXBvbg0KPiAgICAgICAgICAgICAg ICAgICAgICAgICAgIHwgIE9ic2VydmU6IDYwICAgICAgICAgICAgICAgICAgfCAgIGEgc3RhdGUg Y2hhbmdlDQo+ICAgICAgICAgICAgICAgICAgICAgICAgICAgfCAgc3RhdHVzOiAiYXR0YWNrIHN0 b3BwZWQiICAgICB8DQo+ICAgICAgICAgICAgICAgICAgICAgICAgICAgfDwtLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0rDQo+ICAgICAgICAgICAgICAgICAgICAgICAgICAgfCAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICB8DQo+IA0KPiANCj4gV2lsbCB5b3Ugc3VnZ2VzdCB0aGlz IHRvDQo+ID4gYmUgYWRkZWQgaW4gdGhlIHNpZ25hbCBjaGFubmVsPw0KPiA+DQo+ID4gKiBzZWN0 aW9uIDMuMS4yLjEuICwgcGFyYWdyYXBoIDUgLS0gSW4gdGhpcyBwYXJhZ3JhcGggdGhlIHRpbWUg dG8gbGl2ZQ0KPiA+IChUVEwpIGlzIHByb3Bvc2VkIHRvIGJlIGluY2x1ZGVkIGluIHRoZSBtaXRp Z2F0aW9uIHJlcXVlc3QgYXMgYW4NCj4gPiBhbHRlcm5hdGl2ZSB3YXkgdG8gdGVybWluYXRlIHRo ZSBtaXRpZ2F0aW9uLiBJbiBteSBvcGluaW9uLCB0aGUgVFRMDQo+ID4gYXBwcm9hY2ggY291bGQg YmUgdXNlZCBpbiBhbGwgdGhlIERPVFMgdXNlIGNhc2Ugc2NlbmFyaW9zLiBIZW5jZSBJDQo+ID4g cmVjb21tZW5kIHRvIGV4cGxhaW4gaXQgaW4gdGhlIHZlcnkgZmlyc3QgdXNlIGNhc2UgaW4gMy4x LjEuMS4sDQo+ID4gb3RoZXJ3aXNlIGl0IGxvb2tzIG9ubHkgYmUgdXNlZCBpbiB1c2UgY2FzZXMg dGhhdCBNU1NQIG9mZmVyaW5nIHRoZQ0KPiA+IG1pdGlnYXRpb24gc2VydmljZXMuDQo+ID4NCj4g PiAqIHNlY3Rpb24gMy4yLjIuIC0tICBGaXJzdGx5LCB0aGlzIHVzZSBjYXNlIHBsYWNlZCB0b28g bXVjaCBlbXBoYXNpcw0KPiA+IG9uIGhvdyB0aGUgRERvUyBhdHRhY2sgaXMgZGV0ZWN0ZWQuIFNl Y29uZGx5LCBJIHRoaW5rIGl0IGlzIGJldHRlciB0bw0KPiA+IGhhdmUgYSBzY2hlbWF0aWMgZGlh Z3JhbSAobGlrZSB0aGUgZmlndXJlIGluIHNlY3Rpb24gMy4yLjMpIHRvIHNob3cNCj4gPiB0aGUg YXJjaGl0ZWN0dXJlIGFuZCBleHBsYWluIHRoZSB3b3JrIGZsb3cgaW4gZGV0YWlsIHRvIHNob3cg aG93IHRoZQ0KPiA+IERPVFMgcHJvdG9jb2wgd29ya3MgaW4gdGhpcyBzY2VuYXJpby4NCj4gPg0K PiA+ICogc2VjdGlvbiAzLjIuMi4gLS0gdGhlIGxhc3QgcGFyYWdyYXBoIG9uIHBhZ2UgMTcsIGxp bmU3LCAgICdyYXRoZXIgdGhlbicNCj4gPiAtLT4gJ3JhdGhlciB0aGFuJw0KPiA+ICogc2VjdGlv biAzLjIuMi4gLS0gdGhlIHNlY29uZCBwYXJhZ3JhcGggb24gcGFnZSAxOCwgbGluZSAxLCAnaXQN Cj4gPiBub3RpZmllcyBhdXRvbWF0aWNhbGx5IG9yIHRoZSBJU1AnIC0tPiAnaXQgbm90aWZpZXMg YXV0b21hdGljYWxseSB0byB0aGUgSVNQJw0KPiA+ICogc2VjdGlvbiAzLjIuMi4gLS0gdGhlIGZv dXJ0aCBwYXJhZ3JhcGggb24gcGFnZSAxOCwgbGluZSAzLCAndHJhZmZpYw0KPiA+IHBhdHRlcicg LS0+ICd0cmFmZmljIHBhdHRlcm4nDQo+ID4NCj4gPiBCZXN0IFJlZ2FyZHMsDQo+ID4gWXVlDQo+ ID4NCj4gPg0KPiA+IC0tLS0t6YKu5Lu25Y6f5Lu2LS0tLS0NCj4gPiDlj5Hku7bkuro6IERvdHMg W21haWx0bzpkb3RzLWJvdW5jZXNAaWV0Zi5vcmddIOS7o+ihqCBSb2xhbmQgRG9iYmlucw0KPiA+ IOWPkemAgeaXtumXtDogMjAxN+W5tDEx5pyIMTPml6UgNjozOQ0KPiA+IOaUtuS7tuS6ujogZG90 cyA8ZG90c0BpZXRmLm9yZz4NCj4gPiDkuLvpopg6IFtEb3RzXSBkcmFmdC1pZXRmLWRvdHMtdXNl LWNhc2VzLTA5IHBvc3RlZCAtIHBsZWFzZSByZXZpZXcgYW5kDQo+ID4gcHJvdmlkZSBmZWVkYmFj ay4NCj4gPg0KPiA+DQo+ID4gV2UndmUgcmUtb3JnYW5pemVkIHRoZSB1c2UtY2FzZXMgc28gdGhh dCBET1RTIGltcGxlbWVudG9ycyB3b24ndCBmZWVsDQo+ID4gY29tcGVsbGVkIHRvIHJlYWQgdGhy b3VnaCBtdWx0aXBsZSB1c2UtY2FzZXMgd2l0aCBzaW1pbGFyIERPVFMNCj4gPiBjb21tdW5pY2F0 aW9ucyBtb2RlbHMsIHdoaWxlIGF0IHRoZSBzYW1lIHRpbWUgcmV0YWluaW5nIHRob3NlDQo+ID4g dXNlLWNhc2VzIGJlY2F1c2UgdGhleSBjb250YWluIHNpZ25pZmljYW50IHByb2NlZHVyYWwsIG9w ZXJhdGlvbmFsLA0KPiA+IGFuZCB0b3BvbG9naWNhbCB2YXJpYW5jZXMgd2hpY2ggYXJlIG9mIGdy ZWF0IHNpZ25pZmljYW5jZSB0byBuZXR3b3JrDQo+ID4gb3BlcmF0b3JzIGFuZCBlbmQtIGN1c3Rv bWVyIG9yZ2FuaXphdGlvbnMuDQo+ID4NCj4gPiBUaGUgd29yZGluZyBpbiB0aGUgRE9UUyBjb21t dW5pY2F0aW9ucyBtb2RlbCBsaXN0aW5ncyBhbmQgc2V2ZXJhbCBvZg0KPiA+IHRoZSB1c2UtY2Fz ZXMgaGFzIGJlZW4gc3RyZWFtbGluZWQuICBUaGUgc2VjdXJpdHkgY29uc2lkZXJhdGlvbnMgd2Vy ZQ0KPiA+IHVwZGF0ZWQgdG8gaW5jbHVkZSBERG9TIGF0dGFja3MuDQo+ID4NCj4gPiBGaW5hbGx5 LCB3ZSByZWFsbHkgbmVlZCBXRyBmZWVkYmFjayBvbiB0aGUgYXBwbGljYWJpbGl0eSBvZiBTZWN0 aW9uDQo+ID4gMy4yLjIsICdIb21lIE5ldHdvcmsgRERvUyBEZXRlY3Rpb24gQ29sbGFib3JhdGlv biBmb3IgSVNQIG5ldHdvcmsNCj4gbWFuYWdlbWVudCcuDQo+ID4NCj4gPiBUaGFua3MgbXVjaCEN Cj4gPg0KPiA+IDxodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLWRv dHMtdXNlLWNhc2VzLz4NCj4gPg0KPiA+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tDQo+ID4gUm9sYW5kIERvYmJpbnMgPHJkb2JiaW5zQGFyYm9yLm5ldD4NCj4gPg0KPiA+IF9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4gRG90cyBt YWlsaW5nIGxpc3QNCj4gPiBEb3RzQGlldGYub3JnDQo+ID4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9kb3RzDQo+ID4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18NCj4gPiBEb3RzIG1haWxpbmcgbGlzdA0KPiA+IERvdHNAaWV0Zi5v cmcNCj4gPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RvdHMNCj4gX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gRG90cyBtYWls aW5nIGxpc3QNCj4gRG90c0BpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL2RvdHMNCg== From nobody Tue Nov 28 03:19:38 2017 Return-Path: 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 BB869124BE8 for ; Tue, 28 Nov 2017 03:19:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 rwKNZ46jAOl9 for ; Tue, 28 Nov 2017 03:19:35 -0800 (PST) Received: from mail.jpshallow.com (mail.jpshallow.com [217.40.240.153]) (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 3F3B11200F3 for ; Tue, 28 Nov 2017 03:19:35 -0800 (PST) Received: from [127.0.0.1] (helo=N01332) by mail.jpshallow.com with smtps (TLSv1:ECDHE-RSA-AES256-SHA:256) (Exim 4.89) (envelope-from ) id 1eJdvJ-00062P-Nj; Tue, 28 Nov 2017 11:19:33 +0000 From: "Jon Shallow" To: , References: <787AE7BB302AE849A7480A190F8B93300A07F4E4@OPEXCLILMA3.corporate.adroot.infra.ftgroup> In-Reply-To: <787AE7BB302AE849A7480A190F8B93300A07F4E4@OPEXCLILMA3.corporate.adroot.infra.ftgroup> Date: Tue, 28 Nov 2017 11:19:36 -0000 Message-ID: <009b01d3683a$c6158f90$5240aeb0$@jpshallow.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_009C_01D3683A.C616A100" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQI5QycoOO+6Sl3hDoQKXRH887G99aJd55Jw Content-Language: en-gb Archived-At: Subject: Re: [Dots] signal-channel: Conflict detection and notification 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Nov 2017 11:19:37 -0000 This is a multipart message in MIME format. ------=_NextPart_000_009C_01D3683A.C616A100 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Med, See inline Regards Jon From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of ietf-supjps-mohamed.boucadair@orange.com Sent: 24 November 2017 14:03 To: dots@ietf.org Subject: [Dots] signal-channel: Conflict detection and notification Hi all, As discussed during the last IETF meeting, we are seeking for feedback from the WG about how to address this requirement: ========= SIG-009 Conflict Detection and Notification: Multiple DOTS clients controlled by a single administrative entity may send conflicting mitigation requests for pools of protected resources as a result of misconfiguration, operator error, or compromised DOTS clients. DOTS servers in the same administrative domain attempting to honor conflicting requests may flap network route or DNS information, degrading the networks attempting to participate in attack response with the DOTS clients. DOTS servers in a single administrative domain SHALL detect such conflicting requests, and SHALL notify the DOTS clients in conflict. The notification SHOULD indicate the nature and scope of the conflict, for example, the overlapping prefix range in a conflicting mitigation request. ======== For example, would it be OK if we leave implementation-specific the criteria upon which a dots server relies to consider two requests from two clients as conflicting, but draft-ietf-dots-signal defines only the procedure to notify clients when a conflict is detected? Jon> I agree that how this is done is implementation specific. However there is a scenario where Client-A initiates a mitigation requests which is acted upon, Client-B does a conflicting mitigation request but the DOTS Server decides that Client-B is the "more" valid mitigation request and effectively de-activates Client-A's request. Table 2: draft-ietf-dots-signal-channel-09 therefore needs an additional status parameter to indicate to client-A there is a conflict and hence Client-A is being stood down while another client is controlling the mitigation. A suggestion would be 7 | DOTS Server has detected conflicting mitigation requests from different DOTS clients. This mitigation request is currently inactive until the conflicts are resolved. Another mitigation request is active. Jon> The DOTS client can then elect to leave in the mitigation request (and even refresh the PUT to refresh the timeout) or delete it. Jon> I do not think it appropriate that an error message be sent back (e.g. 4.xx) if the DOTS server immediately decides there is a conflicting request and closes down the new PUT request unless we come up with a specific error code so the DOTS client can understand why the request is getting errored. Likewise, would it be OK if the document does not specify which of the conflicting actions is to be discarded (old, new, all) by the server, but draft-ietf-dots-signal defines how to inform clients about which action was enforced by the server? Jon> Again, I think that this would be implementation specific. The suggested Table 2: entry above would cover this as well. The DOTS client just needs to know it has been de-selected / discarded - I don't think the DOTS client needs to know how / why the DOTS server chose that particular DOTS client. Cheers, Med ------=_NextPart_000_009C_01D3683A.C616A100 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Med,

 

See = inline

 

Regards

 

Jon

 

From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of = ietf-supjps-mohamed.boucadair@orange.com
Sent: 24 November = 2017 14:03
To: dots@ietf.org
Subject: [Dots] = signal-channel: Conflict detection and = notification

 

Hi = all,

 

As = discussed during the last IETF meeting, we are seeking for feedback from = the WG about how to address this requirement:

 

=3D=3D=3D=3D=3D=3D=3D=3D=3D

   SIG-009  Conflict = Detection and Notification: Multiple DOTS = clients

      controlled = by a single administrative entity may send = conflicting

      mitigation = requests for pools of protected resources as a = result

      of = misconfiguration, operator error, or compromised DOTS = clients.

      DOTS = servers in the same administrative domain attempting to = honor

      conflicting = requests may flap network route or DNS = information,

      degrading = the networks attempting to participate in attack

      response = with the DOTS clients.  DOTS servers in a = single

      = administrative domain SHALL detect such conflicting requests, = and

      SHALL = notify the DOTS clients in conflict.  The = notification

      SHOULD = indicate the nature and scope of the conflict, for = example,

      the = overlapping prefix range in a conflicting mitigation = request.

=3D=3D=3D=3D=3D=3D=3D=3D

 

For = example, would it be OK if we leave implementation-specific the criteria = upon which a dots server relies to consider two requests from two = clients as conflicting, but draft-ietf-dots-signal defines only the = procedure to notify clients when a conflict is detected? =

Jon> I agree that how this is done is = implementation specific.  However there is a scenario where = Client-A initiates a mitigation requests which is acted upon, Client-B = does a conflicting mitigation request but the DOTS Server decides that = Client-B is the “more” valid mitigation request and = effectively de-activates Client-A’s request.  Table 2: = draft-ietf-dots-signal-channel-09 therefore needs an additional status = parameter to indicate to client-A there is a conflict and hence Client-A = is being stood down while another client is controlling the = mitigation.  A suggestion would be

 

7 | DOTS = Server has detected conflicting mitigation requests from different DOTS = clients.  This mitigation request is currently inactive until the = conflicts are resolved. Another mitigation request is = active.

 

Jon> The = DOTS client can then elect to leave in the mitigation request (and even = refresh the PUT to refresh the timeout) or delete = it.

Jon> I do not think it appropriate that an = error message be sent back (e.g. 4.xx) if the DOTS server immediately = decides there is a conflicting request and closes down the new PUT = request unless we come up with a specific error code so the DOTS client = can understand why the request is getting = errored.

 

 

Likewise, would it be OK if the document does not specify which of = the conflicting actions is to be discarded (old, new, all) by the = server, but draft-ietf-dots-signal defines how to inform clients about = which action was enforced by the server?

 

Jon> = Again, I think that this would be implementation specific.  The = suggested Table 2: entry above would cover this as well.  The DOTS = client just needs to know it has been de-selected / discarded – I = don’t think the DOTS client needs to know how / why the DOTS = server chose that particular DOTS client.

 

Cheers,

Med =

------=_NextPart_000_009C_01D3683A.C616A100-- From nobody Tue Nov 28 03:40:17 2017 Return-Path: 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 7C507126C2F for ; Tue, 28 Nov 2017 03:40:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.89 X-Spam-Level: X-Spam-Status: No, score=-1.89 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_MIME_MALF=0.01] autolearn=ham autolearn_force=no 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 JjZ0P5WsJaBy for ; Tue, 28 Nov 2017 03:40:14 -0800 (PST) Received: from mail.jpshallow.com (mail.jpshallow.com [217.40.240.153]) (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 57EA5126B71 for ; Tue, 28 Nov 2017 03:40:14 -0800 (PST) Received: from [127.0.0.1] (helo=N01332) by mail.jpshallow.com with smtps (TLSv1:ECDHE-RSA-AES256-SHA:256) (Exim 4.89) (envelope-from ) id 1eJeFI-00063H-SN for ietf-supjps-dots@ietf.org; Tue, 28 Nov 2017 11:40:12 +0000 From: "Jon Shallow" To: Date: Tue, 28 Nov 2017 11:40:15 -0000 Message-ID: <00b401d3683d$a8aa8e80$f9ffab80$@jpshallow.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00B5_01D3683D.A8AB03B0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdNoPaP45StLCGo/SQWeQ9wr4oolRg== Content-Language: en-gb Archived-At: Subject: [Dots] Data Channel Nit 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Nov 2017 11:40:15 -0000 This is a multipart message in MIME format. ------=_NextPart_000_00B5_01D3683D.A8AB03B0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi There, In draft-ietf-dots-data-channel-08, there is the use of Content-Format: as a header. Content-Format is a CBOR option - not relevant for the data channel, and the Content-Format: header should be Content-Type:. Furthermore, I think "application/yang.api+json" should be "application/yang-data+json" (RFC8040). For example in Figure 3: POST /restconf/data/ietf-dots-data-channel-identifier HTTP/1.1 Host: {host}:{port} Content-Type: "application/yang-data+json" { "ietf-dots-data-channel-identifier:identifier": { Regards Jon ------=_NextPart_000_00B5_01D3683D.A8AB03B0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi = There,

 

In draft-ietf-dots-data-channel-08, there is the use = of Content-Format: as a header.  Content-Format is a CBOR option = – not relevant for the data channel, and the Content-Format: = header should be Content-Type:.

Furthermore, I think = “application/yang.api+json” should be = “application/yang-data+json” (RFC8040).  For example in = Figure 3:

 

    POST = /restconf/data/ietf-dots-data-channel-identifier = HTTP/1.1

    Host: = {host}:{port}

    = Content-Type: "application/yang-data+json"

    {

     = "ietf-dots-data-channel-identifier:identifier": = {

 

Regards

 

Jon

------=_NextPart_000_00B5_01D3683D.A8AB03B0-- From nobody Tue Nov 28 04:26:46 2017 Return-Path: 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 AAF8D1275C5 for ; Tue, 28 Nov 2017 04:26:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.499 X-Spam-Level: X-Spam-Status: No, score=-5.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_SORBS_WEB=1.5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 qc0xpUlyXV9k for ; Tue, 28 Nov 2017 04:26:42 -0800 (PST) Received: from MIVWSMAILOUT1.mcafee.com (mivwsmailout1.mcafee.com [161.69.47.167]) (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 0EC41126B71 for ; Tue, 28 Nov 2017 04:26:41 -0800 (PST) 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=1511869345; 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: authentication-results:x-originating-ip:x-ms-publictraffictype: x-microsoft-exchange-diagnostics:x-ms-exchange-antispam-srfa-diagnostics: x-ms-office365-filtering-correlation-id:x-microsoft-antispam: x-ms-traffictypediagnostic:x-microsoft-antispam-prvs: x-exchange-antispam-report-test:x-exchange-antispam-report-cfa-test: x-forefront-prvs:x-forefront-antispam-report: received-spf:spamdiagnosticoutput:spamdiagnosticmetadata: Content-Type: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-Transport-CrossTenantHeadersStamped: X-OriginatorOrg:X-NAI-Spam-Flag:X-NAI-Spam-Level: X-NAI-Spam-Threshold:X-NAI-Spam-Score:X-NAI-Spam-Version; bh=OWZjxVDIyRLET8BHCB6a+m0528tizaX9p2+LoK BxnVo=; b=ielRNLYJ9z8DdLevdHhuX34YdCEugBcpSagfZEUr l6IirbUn98THac7bHCf2+EbFNH5wYpUqRgBcrsq32mlxHIp1GH VyogZbR8fw3QarMGtQYBTyodEioWOBa/xJDdPr/LnKyHdFApwd ncW/JhdfSXK/WQ+SI4XqEI7yVjwtQRk= Received: from MIVEXAPP1N03.corpzone.internalzone.com (mivexapp1n03.corpzone.internalzone.com [10.48.48.90]) by MIVWSMAILOUT1.mcafee.com with smtp id 4149_2cab_b6027dd6_20c4_4ced_a328_47e81712eecf; Tue, 28 Nov 2017 05:42:24 -0600 Received: from MIVEXAPP1N03.corpzone.internalzone.com (10.48.48.90) by MIVEXAPP1N03.corpzone.internalzone.com (10.48.48.90) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Tue, 28 Nov 2017 06:42:08 -0500 Received: from MIVO365EDGE4.corpzone.internalzone.com (10.48.176.87) by MIVEXAPP1N03.corpzone.internalzone.com (10.48.48.90) with Microsoft SMTP Server (TLS) id 15.0.1347.2 via Frontend Transport; Tue, 28 Nov 2017 06:42:08 -0500 Received: from NAM02-SN1-obe.outbound.protection.outlook.com (10.48.176.243) by edge.mcafee.com (10.48.176.87) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Tue, 28 Nov 2017 06:42:06 -0500 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.20.260.4; Tue, 28 Nov 2017 11:42:06 +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.20.0260.006; Tue, 28 Nov 2017 11:42:06 +0000 From: "Konda, Tirumaleswar Reddy" To: Jon Shallow , "mohamed.boucadair@orange.com" , "dots@ietf.org" Thread-Topic: [Dots] signal-channel: Conflict detection and notification Thread-Index: AQI5QycoOO+6Sl3hDoQKXRH887G99aJd55JwgAAKs5A= Date: Tue, 28 Nov 2017 11:42:05 +0000 Message-ID: References: <787AE7BB302AE849A7480A190F8B93300A07F4E4@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <009b01d3683a$c6158f90$5240aeb0$@jpshallow.com> In-Reply-To: <009b01d3683a$c6158f90$5240aeb0$@jpshallow.com> 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: [122.172.38.74] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DM5PR16MB1787; 6:uC6bu1k0jnO1htgN5vETfkHWRx5/sDOB1WRhm8mKa/6OAnzxbSvRDtRUTBohuzrokLg95TKRlr0RPt8tNv1mmra96qVQhMqWulUwd+i/JCu06a9u8IN8fHgu4bJ6JUWXrrTPUEYcRWRSko8H08aXLCDGXZ403FzDJl1nVCQD0gZ21eAGf4nac+/ad1dFaWL5LgpxREgD78zn5YK1q8csO9PqUicYZ5bjBUCtZgXQrPIHKCWr5p/biFhx+qWlioo12ZzEZfd/G9yg1o6c0UdpHsFH8cDeBiWtDXCkebN7dIrv1//pMkVB9rvI98Dy98FNA3Lh/88yNnv340kf6oiYDH/aG2ZLtSB7NrMItge2oWc=; 5:cNBEJuikNKZuOOhK/TSx+qjD46CLlDQQnDQDdmWv2nQHm9666qcScTFmXAQWy25kooxutRSQZ3PDJnbKZE4HXNgp/C+K8+6BnQFFkE1WZgZPyVd377EmL2toDyoZk/QoytCHa9w5AYoijsDZRNcxS4FAhJnPORrhpNmbL7Ba6IQ=; 24:0Kvaz18D8FayVkFmKTh8UNHE2afLJj8vZkgtln2kSnNCPHWw2DTFFzo4+JyR9l48Xw+39Wfu5UpACXr4zKdHiItpnKAf44z7RLoiVgjTQO8=; 7:IzXzX7sW+7xhWchSDqmcP4yziOdhij390BI/1uroW8WUUmsQFAboKP8DOysacQRmpDM07wuFmQRYpuwDWhXAgm58tMgbPQkMYkr1Maz5fjAZSJ01mvW5JvvSifne2NuhiTrRNL3TFMSAU2BSssyFyH9QMhHss3aHXeV+YYpv4oWwrkTROZ/9tSfn9z2Snui9HeeHHa/KhSBewalvXyd/NMEbU67E7or/r+tXsl/sarBlJKCbSgtNZEDhl2yL9Jxa x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: faec609a-9bd4-477d-4216-08d536550cf9 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(5600026)(4604075)(2017052603258); SRVR:DM5PR16MB1787; x-ms-traffictypediagnostic: DM5PR16MB1787: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(227612066756510)(18271650672692)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(2401047)(5005006)(8121501046)(10201501046)(93006095)(93001095)(3002001)(3231022)(6041248)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123562025)(20161123558100)(20161123555025)(20161123560025)(20161123564025)(6072148)(201708071742011); SRVR:DM5PR16MB1787; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:DM5PR16MB1787; x-forefront-prvs: 0505147DDB x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(346002)(376002)(366004)(39860400002)(199003)(53754006)(32952001)(51444003)(189002)(2201001)(33656002)(236005)(53936002)(25786009)(74316002)(229853002)(6506006)(2950100002)(77096006)(189998001)(7110500001)(2420400007)(316002)(15650500001)(6306002)(2501003)(19609705001)(80792005)(9686003)(86362001)(6246003)(66066001)(54896002)(97736004)(7696005)(110136005)(14454004)(68736007)(72206003)(53546010)(966005)(99286004)(10710500007)(101416001)(3280700002)(2906002)(5660300001)(50986999)(6436002)(55016002)(8936002)(3660700001)(76176999)(54356999)(2900100001)(106356001)(6116002)(7736002)(102836003)(105586002)(81156014)(478600001)(3846002)(81166006)(606006)(790700001)(8676002)(85282002); DIR:OUT; SFP:1101; SCL:1; SRVR:DM5PR16MB1787; H:DM5PR16MB1788.namprd16.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX: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_DM5PR16MB1788D209F36BFD6387D62ECCEA3A0DM5PR16MB1788namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: faec609a-9bd4-477d-4216-08d536550cf9 X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Nov 2017 11:42:05.9012 (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-Level: X-NAI-Spam-Threshold: 15 X-NAI-Spam-Score: 0.9 X-NAI-Spam-Version: 2.3.0.9418 : core <6168> : inlines <6186> : streams <1771574> : uri <2541486> Archived-At: Subject: Re: [Dots] signal-channel: Conflict detection and notification 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Nov 2017 12:26:45 -0000 --_000_DM5PR16MB1788D209F36BFD6387D62ECCEA3A0DM5PR16MB1788namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Jon, What is the problem if the DOTS server returns 4.09 (conflict) error respon= se for the conflicting mitigation request from Client-A ? The above error code is already defined https://tools.ietf.org/html/rfc8132= . -Tiru From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Jon Shallow Sent: Tuesday, November 28, 2017 4:50 PM To: mohamed.boucadair@orange.com; dots@ietf.org Subject: Re: [Dots] signal-channel: Conflict detection and notification Hi Med, See inline Regards Jon From: Dots [mailto: dots-bounces@ietf.org] On= Behalf Of ietf-supjps-mohamed.boucadair@orange.com Sent: 24 November 2017 14:03 To: dots@ietf.org Subject: [Dots] signal-channel: Conflict detection and notification Hi all, As discussed during the last IETF meeting, we are seeking for feedback from= the WG about how to address this requirement: =3D=3D=3D=3D=3D=3D=3D=3D=3D SIG-009 Conflict Detection and Notification: Multiple DOTS clients controlled by a single administrative entity may send conflicting mitigation requests for pools of protected resources as a result of misconfiguration, operator error, or compromised DOTS clients. DOTS servers in the same administrative domain attempting to honor conflicting requests may flap network route or DNS information, degrading the networks attempting to participate in attack response with the DOTS clients. DOTS servers in a single administrative domain SHALL detect such conflicting requests, and SHALL notify the DOTS clients in conflict. The notification SHOULD indicate the nature and scope of the conflict, for example, the overlapping prefix range in a conflicting mitigation request. =3D=3D=3D=3D=3D=3D=3D=3D For example, would it be OK if we leave implementation-specific the criteri= a upon which a dots server relies to consider two requests from two clients= as conflicting, but draft-ietf-dots-signal defines only the procedure to n= otify clients when a conflict is detected? Jon> I agree that how this is done is implementation specific. However the= re is a scenario where Client-A initiates a mitigation requests which is ac= ted upon, Client-B does a conflicting mitigation request but the DOTS Serve= r decides that Client-B is the "more" valid mitigation request and effectiv= ely de-activates Client-A's request. Table 2: draft-ietf-dots-signal-chann= el-09 therefore needs an additional status parameter to indicate to client-= A there is a conflict and hence Client-A is being stood down while another = client is controlling the mitigation. A suggestion would be 7 | DOTS Server has detected conflicting mitigation requests from different= DOTS clients. This mitigation request is currently inactive until the con= flicts are resolved. Another mitigation request is active. Jon> The DOTS client can then elect to leave in the mitigation request (and= even refresh the PUT to refresh the timeout) or delete it. Jon> I do not think it appropriate that an error message be sent back (e.g.= 4.xx) if the DOTS server immediately decides there is a conflicting reques= t and closes down the new PUT request unless we come up with a specific err= or code so the DOTS client can understand why the request is getting errore= d. Likewise, would it be OK if the document does not specify which of the conf= licting actions is to be discarded (old, new, all) by the server, but draft= -ietf-dots-signal defines how to inform clients about which action was enfo= rced by the server? Jon> Again, I think that this would be implementation specific. The sugges= ted Table 2: entry above would cover this as well. The DOTS client just ne= eds to know it has been de-selected / discarded - I don't think the DOTS cl= ient needs to know how / why the DOTS server chose that particular DOTS cli= ent. Cheers, Med --_000_DM5PR16MB1788D209F36BFD6387D62ECCEA3A0DM5PR16MB1788namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Jon,

 

What is the problem if the DOTS server = returns 4.09 (conflict) error response for the conflicting mitigation reque= st from Client-A ?

The above error code is already defined https://tools.ietf.org/html/rfc8132.

 

-Tiru

 

From:<= /span> Dots [mailto:dots-bou= nces@ietf.org] On Behalf Of Jon Shallow
Sent: Tuesday, November 28, 2017 4:50 PM
To: mohamed.boucadair@orange.com; dots@ietf.org
Subject: Re: [Dots] signal-channel: Conflict detection and notificat= ion

 

Hi Med,=

&n= bsp;

See inl= ine

&n= bsp;

Regards=

&n= bsp;

Jon

&n= bsp;

From: Dots [mailto: dots-bounces@ietf.org] On B= ehalf Of ietf-supjps= -mohamed.boucadair@orange.com
Sent: 24 November 2017 14:03
To: dots@ietf.org
Subject: [Dots] signal-channel: Conflict detection and notification<= o:p>

 

Hi all,

 

As discussed during the last IETF meeting, we are seeking = for feedback from the WG about how to address this requirement:<= /span>

 

=3D=3D=3D=3D=3D=3D=3D=3D=3D

   SIG-009  Conflic= t Detection and Notification: Multiple DOTS clients

      con= trolled by a single administrative entity may send conflicting

      mit= igation requests for pools of protected resources as a result

      of = misconfiguration, operator error, or compromised DOTS clients.

      DOT= S servers in the same administrative domain attempting to honor<= /span>

      con= flicting requests may flap network route or DNS information,

      deg= rading the networks attempting to participate in attack

      res= ponse with the DOTS clients.  DOTS servers in a single

      adm= inistrative domain SHALL detect such conflicting requests, and

      SHA= LL notify the DOTS clients in conflict.  The notification

      SHO= ULD indicate the nature and scope of the conflict, for example,<= /span>

      the= overlapping prefix range in a conflicting mitigation request.

=3D=3D=3D=3D=3D=3D=3D=3D

 

For example, would it be OK if we leave implementation-spe= cific the criteria upon which a dots server relies to consider two requests= from two clients as conflicting, but draft-ietf-dots-signal defines only the procedure to notify clients when a conflict is detected? =

Jon> I agree that h= ow this is done is implementation specific.  However there is a scenar= io where Client-A initiates a mitigation requests which is acted upon, Clie= nt-B does a conflicting mitigation request but the DOTS Server decides that Client-B is the “more” valid miti= gation request and effectively de-activates Client-A’s request. = Table 2: draft-ietf-dots-signal-channel-09 therefore needs an additional s= tatus parameter to indicate to client-A there is a conflict and hence Client-A is being stood down while another client is controlling= the mitigation.  A suggestion would be

 

7 | DOTS Server has de= tected conflicting mitigation requests from different DOTS clients.  T= his mitigation request is currently inactive until the conflicts are resolv= ed. Another mitigation request is active.

 

Jon> The DOTS clien= t can then elect to leave in the mitigation request (and even refresh the P= UT to refresh the timeout) or delete it.

Jon> I do not think= it appropriate that an error message be sent back (e.g. 4.xx) if the DOTS = server immediately decides there is a conflicting request and closes down t= he new PUT request unless we come up with a specific error code so the DOTS client can understand why the request is= getting errored.

 

 

Likewise, would it be OK if the document does not specify = which of the conflicting actions is to be discarded (old, new, all) by the = server, but draft-ietf-dots-signal defines how to inform clients about which action was enforced by the server?

 

Jon> Again, I think= that this would be implementation specific.  The suggested Table 2: e= ntry above would cover this as well.  The DOTS client just needs to kn= ow it has been de-selected / discarded – I don’t think the DOTS client needs to know how / why the DOTS server chose that p= articular DOTS client.

 

Cheers,

Med

--_000_DM5PR16MB1788D209F36BFD6387D62ECCEA3A0DM5PR16MB1788namp_-- From nobody Tue Nov 28 04:27:01 2017 Return-Path: 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 0ABC3128768 for ; Tue, 28 Nov 2017 04:26:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.489 X-Spam-Level: X-Spam-Status: No, score=-5.489 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_SORBS_WEB=1.5, SPF_PASS=-0.001, T_MIME_MALF=0.01, URIBL_BLOCKED=0.001] autolearn=ham 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 UKQKIXXbxd9r for ; Tue, 28 Nov 2017 04:26:49 -0800 (PST) Received: from MIVWSMAILOUT1.mcafee.com (mivwsmailout1.mcafee.com [161.69.47.167]) (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 47671126B71 for ; Tue, 28 Nov 2017 04:26:49 -0800 (PST) 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=1511869610; 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: authentication-results:x-originating-ip:x-ms-publictraffictype: x-microsoft-exchange-diagnostics:x-ms-exchange-antispam-srfa-diagnostics: x-ms-office365-filtering-correlation-id:x-microsoft-antispam: x-ms-traffictypediagnostic:x-microsoft-antispam-prvs: x-exchange-antispam-report-test:x-exchange-antispam-report-cfa-test: x-forefront-prvs:x-forefront-antispam-report: received-spf:spamdiagnosticoutput:spamdiagnosticmetadata: Content-Type: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-Transport-CrossTenantHeadersStamped: X-OriginatorOrg:X-NAI-Spam-Flag:X-NAI-Spam-Threshold: X-NAI-Spam-Score:X-NAI-Spam-Version; bh=7 HR7J20ZgN3m66lvz9e/L2Xp0IU5HgOtXlVK+AWsCP M=; b=HR65zkvgxYEG+M4ZGUxx2t72QJf+PzIOfBsebLFqcVaP HOMQzkBUarR0wWcJqLTtYja+05Gkucc5as66U2ZDx4fSLb2jpV kjCLToLMz3cGiEojGsBdTA0pnksziInPywgZ12YyPs6Xx+Z/eG eZ/NBm2XSjMIn/DwmUiVGTQzVB8= Received: from MIVEXAPP1N03.corpzone.internalzone.com (unknown [10.48.48.90]) by MIVWSMAILOUT1.mcafee.com with smtp id 4149_3077_85224d6f_dbaf_4a1c_b7ff_6fca5cadeb0d; Tue, 28 Nov 2017 05:46:49 -0600 Received: from MIVEXAPP1N02.corpzone.internalzone.com (10.48.48.89) by MIVEXAPP1N03.corpzone.internalzone.com (10.48.48.90) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Tue, 28 Nov 2017 06:46:49 -0500 Received: from MIVO365EDGE3.corpzone.internalzone.com (10.48.176.86) by MIVEXAPP1N02.corpzone.internalzone.com (10.48.48.89) with Microsoft SMTP Server (TLS) id 15.0.1347.2 via Frontend Transport; Tue, 28 Nov 2017 06:46:49 -0500 Received: from NAM02-SN1-obe.outbound.protection.outlook.com (10.48.176.241) by edge.mcafee.com (10.48.176.86) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Tue, 28 Nov 2017 06:46:47 -0500 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.20.260.4; Tue, 28 Nov 2017 11:46:48 +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.20.0260.006; Tue, 28 Nov 2017 11:46:47 +0000 From: "Konda, Tirumaleswar Reddy" To: Jon Shallow , "dots@ietf.org" Thread-Topic: [Dots] Data Channel Nit Thread-Index: AdNoPaP45StLCGo/SQWeQ9wr4oolRgAANv1Q Date: Tue, 28 Nov 2017 11:46:47 +0000 Message-ID: References: <00b401d3683d$a8aa8e80$f9ffab80$@jpshallow.com> In-Reply-To: <00b401d3683d$a8aa8e80$f9ffab80$@jpshallow.com> 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: [122.172.38.74] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DM5PR16MB1787; 6:b533mindY/4bmJW5casyWWGZOGzxAViY/S93OPfMlxX5qZyXmIQBg/yXO1FpMdSS/cJ4vjcE2j7UZsfJ7zZ9mW6gb38cerFAISVMJlCjV28K/cHPd+SJ8cPlETDL9rfa/1IWJ0PW9gPvE3SYX7FEdUV6xPGoXKxtrREfreqETgOQDzFb00A/MXzgTHLs6/9VlE42Inva6s+r0rggyc98WiiJBNyCWXEYDR1WoUDNh7OSmgO8rzMdMv80mFlUnVercdVWPAvftE0lsluYVWk7z0yMxR/PRWRLpTtAxgyKNKPXBcn/D8/YaTpBm4BVYsImrhjQ22vE95vWa0L3Klp6I9DW4qS3ZL0/c7Z0dnysqtc=; 5:YvwVKXB4pxkCHg2NDZRThdMpCtPXwoRMKgwDs4LRDkjgtVi4JpjQw6MGMoBSdR5kJtWHJpajwQv5LR0hsEG2RX7ne0NrOsYWMoD2XCfqFpuZr7E3N4HP4eJ55fzJF55ymYm2vINhFvdG425WgYDMd6EUas9I0lkbrcFKNch8yPw=; 24:KO3CwlniVOWSKFw3EsG8isnY3AdGMlC4h1TWRJ8Xj/VffvJ7mfp9O3+gNJjFDofiDNTpoHsHRQ81HvN+OOy8WQv3IkT3rKuRjIVjeHdiyc4=; 7:kxVyWsmTVMwjOxPQR8qTLPJxuOEZsspETup2M7UZKn+SrRQsP7cGvgKdMIw2LAiRpfN2/pqlvsloGYr7grA6Mm9A96IDK/6KGbiKHctkY0nhMjsV+CoZOkSsi7PeQ4158b00y4J3bgwHy8TAFC+gBkavDEdHqZ51Cm0Xj3cGVTTAxreyaXFWNR9dUE67xrJFue1N4l4E2tC9JP1259HhM6kbnCEu+2kwbofLhUJhPt27CeLVggKsSHsCxbc9VwjL x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 281aae7f-8eb0-4070-ae3e-08d53655b4f5 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(5600026)(4604075)(2017052603258); SRVR:DM5PR16MB1787; x-ms-traffictypediagnostic: DM5PR16MB1787: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(227612066756510)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(2401047)(5005006)(8121501046)(10201501046)(93006095)(93001095)(3002001)(3231022)(6041248)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123562025)(20161123558100)(20161123555025)(20161123560025)(20161123564025)(6072148)(201708071742011); SRVR:DM5PR16MB1787; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:DM5PR16MB1787; x-forefront-prvs: 0505147DDB x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(346002)(376002)(366004)(39860400002)(199003)(32952001)(189002)(33656002)(53936002)(25786009)(74316002)(229853002)(6506006)(2950100002)(77096006)(189998001)(316002)(6306002)(2501003)(19609705001)(80792005)(9686003)(86362001)(6246003)(66066001)(54896002)(97736004)(7696005)(110136005)(14454004)(68736007)(72206003)(53546010)(99286004)(101416001)(3280700002)(2906002)(5660300001)(50986999)(6436002)(55016002)(8936002)(3660700001)(76176999)(54356999)(2900100001)(106356001)(6116002)(7736002)(102836003)(105586002)(81156014)(478600001)(3846002)(81166006)(790700001)(8676002)(85282002); DIR:OUT; SFP:1101; SCL:1; SRVR:DM5PR16MB1787; H:DM5PR16MB1788.namprd16.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX: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_DM5PR16MB1788E1A03ACDFEA748F98AD0EA3A0DM5PR16MB1788namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 281aae7f-8eb0-4070-ae3e-08d53655b4f5 X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Nov 2017 11:46:47.6725 (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 <6168> : inlines <6186> : streams <1771574> : uri <2541488> Archived-At: Subject: Re: [Dots] Data Channel Nit 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Nov 2017 12:26:51 -0000 --_000_DM5PR16MB1788E1A03ACDFEA748F98AD0EA3A0DM5PR16MB1788namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thanks Jon, updated draft. -Tiru From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Jon Shallow Sent: Tuesday, November 28, 2017 5:10 PM To: dots@ietf.org Subject: [Dots] Data Channel Nit Hi There, In draft-ietf-dots-data-channel-08, there is the use of Content-Format: as = a header. Content-Format is a CBOR option - not relevant for the data chan= nel, and the Content-Format: header should be Content-Type:. Furthermore, I think "application/yang.api+json" should be "application/yan= g-data+json" (RFC8040). For example in Figure 3: POST /restconf/data/ietf-dots-data-channel-identifier HTTP/1.1 Host: {host}:{port} Content-Type: "application/yang-data+json" { "ietf-dots-data-channel-identifier:identifier": { Regards Jon --_000_DM5PR16MB1788E1A03ACDFEA748F98AD0EA3A0DM5PR16MB1788namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Thanks Jo= n, updated draft.

&nbs= p;

-Tiru

 

From:<= /span> Dots [mailto:dots-bou= nces@ietf.org] On Behalf Of Jon Shallow
Sent: Tuesday, November 28, 2017 5:10 PM
To: dots@ietf.org
Subject: [Dots] Data Channel Nit

 

Hi There,

 

In draft-ietf-dots-data-channel= -08, there is the use of Content-Format: as a header.  Content-Format = is a CBOR option – not relevant for the data channel, and the Content= -Format: header should be Content-Type:.

Furthermore, I think “app= lication/yang.api+json” should be “application/yang-data= 3;json” (RFC8040).  For example in Figure 3:

 

    POST /restco= nf/data/ietf-dots-data-channel-identifier HTTP/1.1

    Host: {host}= :{port}

    Content-Type= : "application/yang-data+json"

    {=

     "= ietf-dots-data-channel-identifier:identifier": {

 

Regards

 

Jon

--_000_DM5PR16MB1788E1A03ACDFEA748F98AD0EA3A0DM5PR16MB1788namp_-- From nobody Tue Nov 28 04:30:40 2017 Return-Path: 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 BA5651275C5 for ; Tue, 28 Nov 2017 04:30:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 gdiIETeyN1LM for ; Tue, 28 Nov 2017 04:30:36 -0800 (PST) Received: from mail.jpshallow.com (mail.jpshallow.com [217.40.240.153]) (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 332A7126B71 for ; Tue, 28 Nov 2017 04:30:36 -0800 (PST) Received: from [127.0.0.1] (helo=N01332) by mail.jpshallow.com with smtps (TLSv1:ECDHE-RSA-AES256-SHA:256) (Exim 4.89) (envelope-from ) id 1eJf22-00065T-Hf; Tue, 28 Nov 2017 12:30:34 +0000 From: "Jon Shallow" To: "'Konda, Tirumaleswar Reddy'" , , References: <787AE7BB302AE849A7480A190F8B93300A07F4E4@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <009b01d3683a$c6158f90$5240aeb0$@jpshallow.com> In-Reply-To: Date: Tue, 28 Nov 2017 12:30:37 -0000 Message-ID: <00e201d36844$b1b39ec0$151adc40$@jpshallow.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00E3_01D36844.B1B4FE50" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQI5QycoOO+6Sl3hDoQKXRH887G99QHmvtxLArQ3BpOiOSjLoA== Content-Language: en-gb Archived-At: Subject: Re: [Dots] signal-channel: Conflict detection and notification 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Nov 2017 12:30:39 -0000 This is a multipart message in MIME format. ------=_NextPart_000_00E3_01D36844.B1B4FE50 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Tiru, If Client-A has invoked a mitigation, then Client-B requests a conflicting mitigation, if the DOTS server is only allowing the first mitigation request to be the valid one, then the DOTS server could send back a 4.09 to Client-B. However, if the DOTS server is allowed to choose the best mitigation request, decides it is Client-B, there is no simple way of sending an unsolicited 4.09 to client-A. Hence suggestion for an additional status message which can be sent to Client-A stating that Client-A has been de-selected because of a mitigation request conflict. It is also possible that a mitigation state is status 1 (parameter value - Table 2)) and needs to transition to another state - at which point the conflict is found - possibly by the DOTS mitigator - which then needs to be relayed back through the DOTS server. Regards Jon From: Konda, Tirumaleswar Reddy [mailto: TirumaleswarReddy_Konda@mcafee.com] Sent: 28 November 2017 11:42 To: Jon Shallow; mohamed.boucadair@orange.com; dots@ietf.org Subject: RE: [Dots] signal-channel: Conflict detection and notification Hi Jon, What is the problem if the DOTS server returns 4.09 (conflict) error response for the conflicting mitigation request from Client-A ? The above error code is already defined https://tools.ietf.org/html/rfc8132. -Tiru From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Jon Shallow Sent: Tuesday, November 28, 2017 4:50 PM To: mohamed.boucadair@orange.com; dots@ietf.org Subject: Re: [Dots] signal-channel: Conflict detection and notification Hi Med, See inline Regards Jon From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of ietf-supjps-mohamed.boucadair@orange.com Sent: 24 November 2017 14:03 To: dots@ietf.org Subject: [Dots] signal-channel: Conflict detection and notification Hi all, As discussed during the last IETF meeting, we are seeking for feedback from the WG about how to address this requirement: ========= SIG-009 Conflict Detection and Notification: Multiple DOTS clients controlled by a single administrative entity may send conflicting mitigation requests for pools of protected resources as a result of misconfiguration, operator error, or compromised DOTS clients. DOTS servers in the same administrative domain attempting to honor conflicting requests may flap network route or DNS information, degrading the networks attempting to participate in attack response with the DOTS clients. DOTS servers in a single administrative domain SHALL detect such conflicting requests, and SHALL notify the DOTS clients in conflict. The notification SHOULD indicate the nature and scope of the conflict, for example, the overlapping prefix range in a conflicting mitigation request. ======== For example, would it be OK if we leave implementation-specific the criteria upon which a dots server relies to consider two requests from two clients as conflicting, but draft-ietf-dots-signal defines only the procedure to notify clients when a conflict is detected? Jon> I agree that how this is done is implementation specific. However there is a scenario where Client-A initiates a mitigation requests which is acted upon, Client-B does a conflicting mitigation request but the DOTS Server decides that Client-B is the "more" valid mitigation request and effectively de-activates Client-A's request. Table 2: draft-ietf-dots-signal-channel-09 therefore needs an additional status parameter to indicate to client-A there is a conflict and hence Client-A is being stood down while another client is controlling the mitigation. A suggestion would be 7 | DOTS Server has detected conflicting mitigation requests from different DOTS clients. This mitigation request is currently inactive until the conflicts are resolved. Another mitigation request is active. Jon> The DOTS client can then elect to leave in the mitigation request (and even refresh the PUT to refresh the timeout) or delete it. Jon> I do not think it appropriate that an error message be sent back (e.g. 4.xx) if the DOTS server immediately decides there is a conflicting request and closes down the new PUT request unless we come up with a specific error code so the DOTS client can understand why the request is getting errored. Likewise, would it be OK if the document does not specify which of the conflicting actions is to be discarded (old, new, all) by the server, but draft-ietf-dots-signal defines how to inform clients about which action was enforced by the server? Jon> Again, I think that this would be implementation specific. The suggested Table 2: entry above would cover this as well. The DOTS client just needs to know it has been de-selected / discarded - I don't think the DOTS client needs to know how / why the DOTS server chose that particular DOTS client. Cheers, Med ------=_NextPart_000_00E3_01D36844.B1B4FE50 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Tiru,

 

If Client-A has invoked = a mitigation, then Client-B requests a conflicting mitigation, if the = DOTS server is only allowing the first mitigation request to be the = valid one, then the DOTS server could send back a 4.09 to = Client-B.

 

However, if the DOTS = server is allowed to choose the best mitigation request, decides it is = Client-B, there is no simple way of sending an unsolicited 4.09 to = client-A.  Hence suggestion for an additional status message which = can be sent to Client-A stating that Client-A has been de-selected = because of a mitigation request conflict.

 

It is also possible that = a mitigation state is status 1 (parameter value – Table 2)) and = needs to transition to another state – at which point the conflict = is found - possibly by the DOTS mitigator - which then needs to be = relayed back through the DOTS server.

 

Regards

 

Jon

 

From: Konda, Tirumaleswar Reddy [mailto: = TirumaleswarReddy_Konda@mcafee.com]
Sent: 28 November 2017 = 11:42
To: Jon Shallow; mohamed.boucadair@orange.com; = dots@ietf.org
Subject: RE: [Dots] signal-channel: Conflict = detection and notification

 

Hi Jon,

 

What is the problem if the DOTS = server returns 4.09 (conflict) error response for the conflicting = mitigation request from Client-A ?

The above error code is already = defined https://tools.ietf.org/html/rfc8132<= /span>. =

 

-Tiru

 

From: Dots [mailto:dots-bounces@ietf.org] = On Behalf Of Jon Shallow
Sent: Tuesday, November 28, = 2017 4:50 PM
To: mohamed.boucadair@orange.com= ; dots@ietf.org
Subject: Re: = [Dots] signal-channel: Conflict detection and = notification

 

Hi Med,

 

See = inline

 

Regards

 

Jon

 

From: Dots [mailto: dots-bounces@ietf.org] On = Behalf Of ietf-supjps-moha= med.boucadair@orange.com
Sent: 24 November 2017 = 14:03
To: dots@ietf.org
Subject: = [Dots] signal-channel: Conflict detection and = notification

 

Hi = all,

 

As = discussed during the last IETF meeting, we are seeking for feedback from = the WG about how to address this requirement:

 

=3D=3D=3D=3D=3D=3D=3D=3D=3D

   SIG-009  Conflict = Detection and Notification: Multiple DOTS = clients

      controlled = by a single administrative entity may send = conflicting

      mitigation = requests for pools of protected resources as a = result

      of = misconfiguration, operator error, or compromised DOTS = clients.

      DOTS = servers in the same administrative domain attempting to = honor

      conflicting = requests may flap network route or DNS = information,

      degrading = the networks attempting to participate in attack

      response = with the DOTS clients.  DOTS servers in a = single

      = administrative domain SHALL detect such conflicting requests, = and

      SHALL = notify the DOTS clients in conflict.  The = notification

      SHOULD = indicate the nature and scope of the conflict, for = example,

      the = overlapping prefix range in a conflicting mitigation = request.

=3D=3D=3D=3D=3D=3D=3D=3D

 

For = example, would it be OK if we leave implementation-specific the criteria = upon which a dots server relies to consider two requests from two = clients as conflicting, but draft-ietf-dots-signal defines only the = procedure to notify clients when a conflict is detected? =

Jon> I agree that how this is done is = implementation specific.  However there is a scenario where = Client-A initiates a mitigation requests which is acted upon, Client-B = does a conflicting mitigation request but the DOTS Server decides that = Client-B is the “more” valid mitigation request and = effectively de-activates Client-A’s request.  Table 2: = draft-ietf-dots-signal-channel-09 therefore needs an additional status = parameter to indicate to client-A there is a conflict and hence Client-A = is being stood down while another client is controlling the = mitigation.  A suggestion would be

 

7 | DOTS = Server has detected conflicting mitigation requests from different DOTS = clients.  This mitigation request is currently inactive until the = conflicts are resolved. Another mitigation request is = active.

 

Jon> The = DOTS client can then elect to leave in the mitigation request (and even = refresh the PUT to refresh the timeout) or delete = it.

Jon> I do not think it appropriate that an = error message be sent back (e.g. 4.xx) if the DOTS server immediately = decides there is a conflicting request and closes down the new PUT = request unless we come up with a specific error code so the DOTS client = can understand why the request is getting = errored.

 

 

Likewise, would it be OK if the document does not specify which of = the conflicting actions is to be discarded (old, new, all) by the = server, but draft-ietf-dots-signal defines how to inform clients about = which action was enforced by the server?

 

Jon> = Again, I think that this would be implementation specific.  The = suggested Table 2: entry above would cover this as well.  The DOTS = client just needs to know it has been de-selected / discarded – I = don’t think the DOTS client needs to know how / why the DOTS = server chose that particular DOTS client.

 

Cheers,

Med =

------=_NextPart_000_00E3_01D36844.B1B4FE50-- From nobody Tue Nov 28 05:28:41 2017 Return-Path: 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 E57FB124B18 for ; Tue, 28 Nov 2017 05:28:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.397 X-Spam-Level: X-Spam-Status: No, score=-5.397 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-2.8, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 n7bhfjAetFc1 for ; Tue, 28 Nov 2017 05:28:37 -0800 (PST) Received: from orange.com (mta135.mail.business.static.orange.com [80.12.70.35]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0D17A1243F6 for ; Tue, 28 Nov 2017 05:28:37 -0800 (PST) Received: from opfednr05.francetelecom.fr (unknown [xx.xx.xx.69]) by opfednr24.francetelecom.fr (ESMTP service) with ESMTP id 5DEAA40CC8; Tue, 28 Nov 2017 14:28:35 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.2]) by opfednr05.francetelecom.fr (ESMTP service) with ESMTP id 43A2C20068; Tue, 28 Nov 2017 14:28:35 +0100 (CET) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM21.corporate.adroot.infra.ftgroup ([fe80::e92a:c932:907e:8f06%19]) with mapi id 14.03.0361.001; Tue, 28 Nov 2017 14:28:35 +0100 From: To: Jon Shallow , "'Konda, Tirumaleswar Reddy'" , "dots@ietf.org" Thread-Topic: [Dots] signal-channel: Conflict detection and notification Thread-Index: AdNlLOxuTejE5Yr+TiWtd6n7pT4m0QHmvtxLArQ3BpOiOSjLoKJXx2WA Date: Tue, 28 Nov 2017 13:28:34 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93300A0819DB@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <787AE7BB302AE849A7480A190F8B93300A07F4E4@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <009b01d3683a$c6158f90$5240aeb0$@jpshallow.com> <00e201d36844$b1b39ec0$151adc40$@jpshallow.com> In-Reply-To: <00e201d36844$b1b39ec0$151adc40$@jpshallow.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.4] Content-Type: multipart/alternative; boundary="_000_787AE7BB302AE849A7480A190F8B93300A0819DBOPEXCLILMA3corp_" MIME-Version: 1.0 Archived-At: Subject: Re: [Dots] signal-channel: Conflict detection and notification 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Nov 2017 13:28:40 -0000 --_000_787AE7BB302AE849A7480A190F8B93300A0819DBOPEXCLILMA3corp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Jon, all, Thank you for sharing your thoughts on this. I tend to allow for both 4.09 code and new status values in the spec. I see that you proposed this new value: =3D=3D 7 | DOTS Server has detected conflicting mitigation requests from different= DOTS clients. This mitigation request is currently inactive until the con= flicts are resolved. Another mitigation request is active. =3D=3D Please note that a server may be instructed to adopt a more strict behavior= by deactivating all conflicting requests. Further, all DOTS clients which = issued conflicting requests should be notified, not only the one for which = a request is de-activated. As such, I'm afraid we will need more values, e.= g., =3D=3D 7 | DOTS Server has detected conflicting mitigation requests from different= DOTS clients. This mitigation request is currently inactive until the con= flicts are resolved. Another mitigation request is active. 8 | DOTS Server has detected conflicting mitigation requests from different= DOTS clients. This mitigation request is currently active. 9 | DOTS Server has detected conflicting mitigation requests from different= DOTS clients. All conflicting mitigation requests are inactive. =3D=3D For example: * If the server decides to activate only one request, then 7 will be sent t= o all clients for which the request is de-activated and 8 to the client for= which the request is maintained active. * If the server decides to deactivate all requests, then 9 will be sent to = all clients. Cheers, Med De : Jon Shallow [mailto:supjps-ietf@jpshallow.com] Envoy=E9 : mardi 28 novembre 2017 13:31 =C0 : 'Konda, Tirumaleswar Reddy'; BOUCADAIR Mohamed IMT/OLN; dots@ietf.org Objet : RE: [Dots] signal-channel: Conflict detection and notification Hi Tiru, If Client-A has invoked a mitigation, then Client-B requests a conflicting = mitigation, if the DOTS server is only allowing the first mitigation reques= t to be the valid one, then the DOTS server could send back a 4.09 to Clien= t-B. However, if the DOTS server is allowed to choose the best mitigation reques= t, decides it is Client-B, there is no simple way of sending an unsolicited= 4.09 to client-A. Hence suggestion for an additional status message which= can be sent to Client-A stating that Client-A has been de-selected because= of a mitigation request conflict. It is also possible that a mitigation state is status 1 (parameter value - = Table 2)) and needs to transition to another state - at which point the con= flict is found - possibly by the DOTS mitigator - which then needs to be re= layed back through the DOTS server. Regards Jon From: Konda, Tirumaleswar Reddy [mailto: TirumaleswarReddy_Konda@mcafee.com= ] Sent: 28 November 2017 11:42 To: Jon Shallow; mohamed.boucadair@orange.com; dots@ietf.org Subject: RE: [Dots] signal-channel: Conflict detection and notification Hi Jon, What is the problem if the DOTS server returns 4.09 (conflict) error respon= se for the conflicting mitigation request from Client-A ? The above error code is already defined https://tools.ietf.org/html/rfc8132= . -Tiru From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Jon Shallow Sent: Tuesday, November 28, 2017 4:50 PM To: mohamed.boucadair@orange.com; dots= @ietf.org Subject: Re: [Dots] signal-channel: Conflict detection and notification Hi Med, See inline Regards Jon From: Dots [mailto: dots-bounces@ietf.org] On= Behalf Of ietf-supjps-mohamed.boucadair@orange.com Sent: 24 November 2017 14:03 To: dots@ietf.org Subject: [Dots] signal-channel: Conflict detection and notification Hi all, As discussed during the last IETF meeting, we are seeking for feedback from= the WG about how to address this requirement: =3D=3D=3D=3D=3D=3D=3D=3D=3D SIG-009 Conflict Detection and Notification: Multiple DOTS clients controlled by a single administrative entity may send conflicting mitigation requests for pools of protected resources as a result of misconfiguration, operator error, or compromised DOTS clients. DOTS servers in the same administrative domain attempting to honor conflicting requests may flap network route or DNS information, degrading the networks attempting to participate in attack response with the DOTS clients. DOTS servers in a single administrative domain SHALL detect such conflicting requests, and SHALL notify the DOTS clients in conflict. The notification SHOULD indicate the nature and scope of the conflict, for example, the overlapping prefix range in a conflicting mitigation request. =3D=3D=3D=3D=3D=3D=3D=3D For example, would it be OK if we leave implementation-specific the criteri= a upon which a dots server relies to consider two requests from two clients= as conflicting, but draft-ietf-dots-signal defines only the procedure to n= otify clients when a conflict is detected? Jon> I agree that how this is done is implementation specific. However the= re is a scenario where Client-A initiates a mitigation requests which is ac= ted upon, Client-B does a conflicting mitigation request but the DOTS Serve= r decides that Client-B is the "more" valid mitigation request and effectiv= ely de-activates Client-A's request. Table 2: draft-ietf-dots-signal-chann= el-09 therefore needs an additional status parameter to indicate to client-= A there is a conflict and hence Client-A is being stood down while another = client is controlling the mitigation. A suggestion would be 7 | DOTS Server has detected conflicting mitigation requests from different= DOTS clients. This mitigation request is currently inactive until the con= flicts are resolved. Another mitigation request is active. Jon> The DOTS client can then elect to leave in the mitigation request (and= even refresh the PUT to refresh the timeout) or delete it. Jon> I do not think it appropriate that an error message be sent back (e.g.= 4.xx) if the DOTS server immediately decides there is a conflicting reques= t and closes down the new PUT request unless we come up with a specific err= or code so the DOTS client can understand why the request is getting errore= d. Likewise, would it be OK if the document does not specify which of the conf= licting actions is to be discarded (old, new, all) by the server, but draft= -ietf-dots-signal defines how to inform clients about which action was enfo= rced by the server? Jon> Again, I think that this would be implementation specific. The sugges= ted Table 2: entry above would cover this as well. The DOTS client just ne= eds to know it has been de-selected / discarded - I don't think the DOTS cl= ient needs to know how / why the DOTS server chose that particular DOTS cli= ent. Cheers, Med --_000_787AE7BB302AE849A7480A190F8B93300A0819DBOPEXCLILMA3corp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Jon, all,

 

Thank you for= sharing your thoughts on this.

 

I tend to all= ow for both 4.09 code and new status values in the spec.

 

I see that yo= u proposed this new value:

=3D=3D

7 | DOT= S Server has detected conflicting mitigation requests from different DOTS c= lients.  This mitigation request is currently inactive until the confl= icts are resolved. Another mitigation request is active.

=3D=3D

 

Please note t= hat a server may be instructed to adopt a more strict behavior by deactivat= ing all conflicting requests. Further, all DOTS clients which issued conflicting requests should be notified, not only the one for which= a request is de-activated. As such, I’m afraid we will need more val= ues, e.g.,

 

=3D=3D

7 | DOT= S Server has detected conflicting mitigation requests from different DOTS c= lients.  This mitigation request is currently inactive until the confl= icts are resolved. Another mitigation request is active.

8 | DOT= S Server has detected conflicting mitigation requests from different DOTS c= lients.  This mitigation request is currently active.

9 | DOT= S Server has detected conflicting mitigation requests from different DOTS c= lients.  All conflicting mitigation requests are inactive.<= /span>

=3D=3D

 

For example:<= o:p>

* If the serv= er decides to activate only one request, then 7 will be sent to all clients= for which the request is de-activated and 8 to the client for which the request is maintained active.

* If the serv= er decides to deactivate all requests, then 9 will be sent to all clients. =  

 

Cheers,<= /o:p>

Med

 

J= on Shallow [mailto:supjps-ietf@jpshallow.com]
Envoy=E9 : mardi 28 novembre 2017 13:31
=C0 : 'Konda, Tirumaleswar Reddy'; BOUCADAIR Mohamed IMT/OLN; dots@ietf.org
Objet : RE: [Dots] signal-channel: Conflict detection and notif= ication

 

Hi Tiru= ,

&n= bsp;

If Clie= nt-A has invoked a mitigation, then Client-B requests a conflicting mitigat= ion, if the DOTS server is only allowing the first mitigation request to be= the valid one, then the DOTS server could send back a 4.09 to Client-B.

&n= bsp;

However= , if the DOTS server is allowed to choose the best mitigation request, deci= des it is Client-B, there is no simple way of sending an unsolicited 4.09 t= o client-A.  Hence suggestion for an additional status message which can be sent to Client-A stating that Client-A has bee= n de-selected because of a mitigation request conflict.

&n= bsp;

It is a= lso possible that a mitigation state is status 1 (parameter value – T= able 2)) and needs to transition to another state – at which point th= e conflict is found - possibly by the DOTS mitigator - which then needs to be relayed back through the DOTS server.<= /span>

&n= bsp;

Regards=

&n= bsp;

Jon

&n= bsp;

From:= Konda, Tirumaleswar Reddy [mailto: TirumaleswarReddy_Konda@mcafee.com]
Sent: 28 November 2017 11:42
To: Jon Shallow; moh= amed.boucadair@orange.com; dots@ietf.org
Subject: RE: [Dots] signal-channel: Conflict detection and notificat= ion

 

Hi Jon,

 

What is the problem if the DOTS server returns 4.09 (conflict) error = response for the conflicting mitigation request from Client-A ?<= /span>

The above error code is already defined https://tools.ie= tf.org/html/rfc8132.

 

-Tiru

 

From: Dots [mailto:dots-bounces= @ietf.org] On Behalf Of Jon Shallow
Sent: Tuesday, November 28, 2017 4:50 PM
To: mohamed.boucadai= r@orange.com; dots@ietf.org
Subject: Re: [Dots] signal-channel: Conflict detection and notificat= ion

 

Hi Med,=

&n= bsp;

See inl= ine

&n= bsp;

Regards=

&n= bsp;

Jon

&n= bsp;

From:= Dots [mailto: dots-bounces@ietf.org] On B= ehalf Of ietf-supjps= -mohamed.boucadair@orange.com
Sent: 24 November 2017 14:03
To: dots@ietf.org
Subject: [Dots] signal-channel: Conflict detection and notification<= o:p>

 

Hi all,

 <= /p>

As discussed during the l= ast IETF meeting, we are seeking for feedback from the WG about how to addr= ess this requirement:

 <= /p>

=3D=3D=3D=3D=3D=3D=3D=3D= =3D

&= nbsp;  SIG-009  Conflict Detection and Notification: Multiple DOT= S clients

&= nbsp;     controlled by a single administrative entity = may send conflicting

&= nbsp;     mitigation requests for pools of protected re= sources as a result

&= nbsp;     of misconfiguration, operator error, or compr= omised DOTS clients.

&= nbsp;     DOTS servers in the same administrative domai= n attempting to honor

&= nbsp;     conflicting requests may flap network route o= r DNS information,

&= nbsp;     degrading the networks attempting to particip= ate in attack

&= nbsp;     response with the DOTS clients.  DOTS se= rvers in a single

&= nbsp;     administrative domain SHALL detect such confl= icting requests, and

&= nbsp;     SHALL notify the DOTS clients in conflict.&nb= sp; The notification

&= nbsp;     SHOULD indicate the nature and scope of the c= onflict, for example,

&= nbsp;     the overlapping prefix range in a conflicting= mitigation request.

=3D=3D=3D=3D=3D=3D=3D=3D<= o:p>

 <= /p>

For example, would it be = OK if we leave implementation-specific the criteria upon which a dots serve= r relies to consider two requests from two clients as conflicting, but draft-ietf-dots-signal defines only the procedure to notify clients wh= en a conflict is detected?

Jon>= I agree that how this is done is implementation specific.  However th= ere is a scenario where Client-A initiates a mitigation requests which is a= cted upon, Client-B does a conflicting mitigation request but the DOTS Server decides that Client-B is the “more”= ; valid mitigation request and effectively de-activates Client-A’s re= quest.  Table 2: draft-ietf-dots-signal-channel-09 therefore needs an = additional status parameter to indicate to client-A there is a conflict and hence Client-A is being stood down while another client = is controlling the mitigation.  A suggestion would be

&n= bsp;

7 | DOT= S Server has detected conflicting mitigation requests from different DOTS c= lients.  This mitigation request is currently inactive until the confl= icts are resolved. Another mitigation request is active.

&n= bsp;

Jon>= The DOTS client can then elect to leave in the mitigation request (and eve= n refresh the PUT to refresh the timeout) or delete it.

Jon>= I do not think it appropriate that an error message be sent back (e.g. 4.x= x) if the DOTS server immediately decides there is a conflicting request an= d closes down the new PUT request unless we come up with a specific error code so the DOTS client can understand wh= y the request is getting errored.

&n= bsp;

 <= /p>

Likewise, would it be OK = if the document does not specify which of the conflicting actions is to be = discarded (old, new, all) by the server, but draft-ietf-dots-signal defines how to inform clients about which action was enforced by the serve= r?

&n= bsp;

Jon>= Again, I think that this would be implementation specific.  The sugge= sted Table 2: entry above would cover this as well.  The DOTS client j= ust needs to know it has been de-selected / discarded – I don’t think the DOTS client needs to know how / why the DO= TS server chose that particular DOTS client.

 <= /p>

Cheers,=

Med

--_000_787AE7BB302AE849A7480A190F8B93300A0819DBOPEXCLILMA3corp_-- From nobody Tue Nov 28 06:15:12 2017 Return-Path: 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 5D985127011 for ; Tue, 28 Nov 2017 06:15:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 Zvy5qWAyyt5J for ; Tue, 28 Nov 2017 06:15:03 -0800 (PST) Received: from mail.jpshallow.com (mail.jpshallow.com [217.40.240.153]) (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 22249124234 for ; Tue, 28 Nov 2017 06:15:03 -0800 (PST) Received: from [127.0.0.1] (helo=N01332) by mail.jpshallow.com with smtps (TLSv1:ECDHE-RSA-AES256-SHA:256) (Exim 4.89) (envelope-from ) id 1eJgf7-00068y-9Q; Tue, 28 Nov 2017 14:15:01 +0000 From: "Jon Shallow" To: , "Konda, Tirumaleswar Reddy" , References: <787AE7BB302AE849A7480A190F8B93300A07F4E4@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <009b01d3683a$c6158f90$5240aeb0$@jpshallow.com> <00e201d36844$b1b39ec0$151adc40$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93300A0819DB@OPEXCLILMA3.corporate.adroot.infra.ftgroup> In-Reply-To: <787AE7BB302AE849A7480A190F8B93300A0819DB@OPEXCLILMA3.corporate.adroot.infra.ftgroup> Date: Tue, 28 Nov 2017 14:15:03 -0000 Message-ID: <011301d36853$48efb680$dacf2380$@jpshallow.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0114_01D36853.48F22780" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQI5QycoOO+6Sl3hDoQKXRH887G99QHmvtxLArQ3BpMBrkCf6AG8EcvIoh3syjA= Content-Language: en-gb Archived-At: Subject: Re: [Dots] signal-channel: Conflict detection and notification 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Nov 2017 14:15:10 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0114_01D36853.48F22780 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Med, =20 In principal I accept the concept of your 7, 8 & 9 status which in = effect are part of the mitigation state as in a state diagram. However, having issued a =938=94 status, this then needs to transition to another state = which reflects what is actually happening =96 e.g. =932=94. =20 The actual state could immediately be sent following the reporting of = =938=94 (if Observe active), else it would need to wait until the next status = GET. It is possible that the =938=94 message gets lost, so relying on = receiving the =938=94 could be dangerous. =20 With a =939=94 response what then is the DOTS client allowed to do? - A retry of the original mitigation request is likely to fail again - If all the DOTS clients back off, then there will be no mitigation - Should there be a random back-off time before retrying? =20 What is critical is that=20 DOTS servers in the same administrative domain attempting to honor conflicting requests may flap network route or DNS information, degrading the networks attempting to participate in attack response with the DOTS clients. Should not be allowed to happen. =20 I also do not want to lose sight of=20 The notification SHOULD indicate the nature and scope of the conflict, for example, the overlapping prefix range in a conflicting mitigation request.=94 This potentially can be conveyed in the 4.09 message, or could be a new mitigation status parameter such as "additional-info" with an = appropriate text value. It could be that =93status=94 stays with =931=94 through = =936=94, and (possibly optional) =93additional-status=94 has=20 0 | This DOTS client mitigation request is being honoured 1 | DOTS Server has detected conflicting mitigation requests from = different DOTS clients. This mitigation request is currently inactive until the conflicts are resolved. Another mitigation request is active. 2 | DOTS Server has detected conflicting mitigation requests from = different DOTS clients. This mitigation request is currently active.=20 3 | DOTS Server has detected conflicting mitigation requests from = different DOTS clients. All conflicting mitigation requests are inactive. And =93additional-info=94 reports on what the nature and scope of the = conflict is. =20 Regards =20 Jon =20 From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of mohamed.boucadair@orange.com Sent: 28 November 2017 13:29 To: Jon Shallow; 'Konda, Tirumaleswar Reddy'; dots@ietf.org Subject: Re: [Dots] signal-channel: Conflict detection and notification =20 Hi Jon, all, =20 Thank you for sharing your thoughts on this. =20 I tend to allow for both 4.09 code and new status values in the spec.=20 =20 I see that you proposed this new value:=20 =3D=3D 7 | DOTS Server has detected conflicting mitigation requests from = different DOTS clients. This mitigation request is currently inactive until the conflicts are resolved. Another mitigation request is active. =3D=3D =20 Please note that a server may be instructed to adopt a more strict = behavior by deactivating all conflicting requests. Further, all DOTS clients = which issued conflicting requests should be notified, not only the one for = which a request is de-activated. As such, I=92m afraid we will need more values, = e.g., =20 =3D=3D 7 | DOTS Server has detected conflicting mitigation requests from = different DOTS clients. This mitigation request is currently inactive until the conflicts are resolved. Another mitigation request is active. 8 | DOTS Server has detected conflicting mitigation requests from = different DOTS clients. This mitigation request is currently active.=20 9 | DOTS Server has detected conflicting mitigation requests from = different DOTS clients. All conflicting mitigation requests are inactive. =3D=3D =20 For example: * If the server decides to activate only one request, then 7 will be = sent to all clients for which the request is de-activated and 8 to the client = for which the request is maintained active.=20 * If the server decides to deactivate all requests, then 9 will be sent = to all clients. =20 =20 Cheers, Med =20 De : Jon Shallow [mailto:supjps-ietf@jpshallow.com]=20 Envoy=E9 : mardi 28 novembre 2017 13:31 =C0 : 'Konda, Tirumaleswar Reddy'; BOUCADAIR Mohamed IMT/OLN; = dots@ietf.org Objet : RE: [Dots] signal-channel: Conflict detection and notification =20 Hi Tiru, =20 If Client-A has invoked a mitigation, then Client-B requests a = conflicting mitigation, if the DOTS server is only allowing the first mitigation = request to be the valid one, then the DOTS server could send back a 4.09 to Client-B. =20 However, if the DOTS server is allowed to choose the best mitigation request, decides it is Client-B, there is no simple way of sending an unsolicited 4.09 to client-A. Hence suggestion for an additional status message which can be sent to Client-A stating that Client-A has been de-selected because of a mitigation request conflict. =20 It is also possible that a mitigation state is status 1 (parameter value = =96 Table 2)) and needs to transition to another state =96 at which point = the conflict is found - possibly by the DOTS mitigator - which then needs to = be relayed back through the DOTS server. =20 Regards =20 Jon =20 From: Konda, Tirumaleswar Reddy [mailto: = TirumaleswarReddy_Konda@mcafee.com] Sent: 28 November 2017 11:42 To: Jon Shallow; mohamed.boucadair@orange.com; dots@ietf.org Subject: RE: [Dots] signal-channel: Conflict detection and notification =20 Hi Jon, =20 What is the problem if the DOTS server returns 4.09 (conflict) error response for the conflicting mitigation request from Client-A ? The above error code is already defined = https://tools.ietf.org/html/rfc8132.=20 =20 -Tiru =20 From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Jon Shallow Sent: Tuesday, November 28, 2017 4:50 PM To: mohamed.boucadair@orange.com; dots@ietf.org Subject: Re: [Dots] signal-channel: Conflict detection and notification =20 Hi Med, =20 See inline =20 Regards =20 Jon =20 From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of ietf-supjps-mohamed.boucadair@orange.com Sent: 24 November 2017 14:03 To: dots@ietf.org Subject: [Dots] signal-channel: Conflict detection and notification =20 Hi all,=20 =20 As discussed during the last IETF meeting, we are seeking for feedback = from the WG about how to address this requirement: =20 =3D=3D=3D=3D=3D=3D=3D=3D=3D SIG-009 Conflict Detection and Notification: Multiple DOTS clients controlled by a single administrative entity may send conflicting mitigation requests for pools of protected resources as a result of misconfiguration, operator error, or compromised DOTS clients. DOTS servers in the same administrative domain attempting to honor conflicting requests may flap network route or DNS information, degrading the networks attempting to participate in attack response with the DOTS clients. DOTS servers in a single administrative domain SHALL detect such conflicting requests, and SHALL notify the DOTS clients in conflict. The notification SHOULD indicate the nature and scope of the conflict, for example, the overlapping prefix range in a conflicting mitigation request. =3D=3D=3D=3D=3D=3D=3D=3D =20 For example, would it be OK if we leave implementation-specific the = criteria upon which a dots server relies to consider two requests from two = clients as conflicting, but draft-ietf-dots-signal defines only the procedure to = notify clients when a conflict is detected?=20 Jon> I agree that how this is done is implementation specific. However there is a scenario where Client-A initiates a mitigation requests which = is acted upon, Client-B does a conflicting mitigation request but the DOTS Server decides that Client-B is the =93more=94 valid mitigation request = and effectively de-activates Client-A=92s request. Table 2: draft-ietf-dots-signal-channel-09 therefore needs an additional status parameter to indicate to client-A there is a conflict and hence Client-A = is being stood down while another client is controlling the mitigation. A suggestion would be=20 =20 7 | DOTS Server has detected conflicting mitigation requests from = different DOTS clients. This mitigation request is currently inactive until the conflicts are resolved. Another mitigation request is active. =20 Jon> The DOTS client can then elect to leave in the mitigation request = (and even refresh the PUT to refresh the timeout) or delete it. Jon> I do not think it appropriate that an error message be sent back = (e.g. 4.xx) if the DOTS server immediately decides there is a conflicting = request and closes down the new PUT request unless we come up with a specific = error code so the DOTS client can understand why the request is getting = errored. =20 =20 Likewise, would it be OK if the document does not specify which of the conflicting actions is to be discarded (old, new, all) by the server, = but draft-ietf-dots-signal defines how to inform clients about which action = was enforced by the server?=20 =20 Jon> Again, I think that this would be implementation specific. The suggested Table 2: entry above would cover this as well. The DOTS = client just needs to know it has been de-selected / discarded =96 I don=92t = think the DOTS client needs to know how / why the DOTS server chose that = particular DOTS client. =20 Cheers, Med=20 ------=_NextPart_000_0114_01D36853.48F22780 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Med,

 

In principal I accept = the concept of your 7, 8 & 9 status which in effect are part of the = mitigation state as in a state diagram.=A0 However, having issued a = “8” status, this then needs to transition to another state = which reflects what is actually happening – e.g. = “2”.

 

The actual state could = immediately be sent following the reporting of “8” (if = Observe active), else it would need to wait until the next status = GET.=A0 It is possible that the “8” message gets lost, so = relying on receiving the “8” could be = dangerous.

 

With a “9” = response what then is the DOTS client allowed to = do?

- A retry of the original mitigation request is = likely to fail again

- If all the DOTS clients back off, then there = will be no mitigation

- Should there be a random back-off time before = retrying?

 

What is critical is that =

      DOTS = servers in the same administrative domain attempting to = honor

      conflicting = requests may flap network route or DNS = information,

      degrading = the networks attempting to participate in attack

      response = with the DOTS clients.

Should not be allowed to = happen.

 

I also do not want to = lose sight of

The notification SHOULD indicate the = nature and scope of the conflict,

for example, the overlapping prefix range = in a conflicting mitigation request.”

This potentially can be = conveyed in the 4.09 message, or could be a new mitigation status = parameter such as "additional-info" with an appropriate text = value.=A0 It could be that “status” stays with = “1” through “6”, and (possibly optional) = “additional-status” has

0 | This DOTS client = mitigation request is being honoured

1 | DOTS = Server has detected conflicting mitigation requests from different DOTS = clients.  This mitigation request is currently inactive until the = conflicts are resolved. Another mitigation request is = active.

2 | DOTS Server has detected conflicting = mitigation requests from different DOTS clients.  This mitigation = request is currently active.

3 | DOTS = Server has detected conflicting mitigation requests from different DOTS = clients.  All conflicting mitigation requests are = inactive.

And “additional-info” reports on = what the nature and scope of the conflict is.

 

Regards

 

Jon

 

From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of = mohamed.boucadair@orange.com
Sent: 28 November 2017 = 13:29
To: Jon Shallow; 'Konda, Tirumaleswar Reddy'; = dots@ietf.org
Subject: Re: [Dots] signal-channel: Conflict = detection and notification

 

Hi Jon, all,

 

Thank you for sharing your thoughts on = this.

 

I tend to allow for both 4.09 code and new status = values in the spec.

 

I see that you proposed this new value: =

=3D=3D

7 | DOTS Server has detected = conflicting mitigation requests from different DOTS clients.  This = mitigation request is currently inactive until the conflicts are = resolved. Another mitigation request is active.

=3D=3D

 

Please note that a server may be instructed to adopt a = more strict behavior by deactivating all conflicting requests. Further, = all DOTS clients which issued conflicting requests should be notified, = not only the one for which a request is de-activated. As such, I’m = afraid we will need more values, e.g.,

 

=3D=3D

7 | DOTS Server has detected = conflicting mitigation requests from different DOTS clients.  This = mitigation request is currently inactive until the conflicts are = resolved. Another mitigation request is active.

8 | DOTS = Server has detected conflicting mitigation requests from different DOTS = clients.  This mitigation request is currently active. =

9 | DOTS Server has detected conflicting = mitigation requests from different DOTS clients.  All conflicting = mitigation requests are inactive.

=3D=3D

 

For example:

* If = the server decides to activate only one request, then 7 will be sent to = all clients for which the request is de-activated and 8 to the client = for which the request is maintained active.

* If = the server decides to deactivate all requests, then 9 will be sent to = all clients.  

 

Cheers,

Med

 

De : Jon Shallow [mailto:supjps-ietf@jpshallow.co= m]
Envoy=E9 : mardi 28 novembre 2017 = 13:31
=C0 : 'Konda, Tirumaleswar Reddy'; BOUCADAIR Mohamed IMT/OLN; dots@ietf.org
Objet : = RE: [Dots] signal-channel: Conflict detection and = notification

 

Hi Tiru,

 

If Client-A has invoked = a mitigation, then Client-B requests a conflicting mitigation, if the = DOTS server is only allowing the first mitigation request to be the = valid one, then the DOTS server could send back a 4.09 to = Client-B.

 

However, if the DOTS = server is allowed to choose the best mitigation request, decides it is = Client-B, there is no simple way of sending an unsolicited 4.09 to = client-A.  Hence suggestion for an additional status message which = can be sent to Client-A stating that Client-A has been de-selected = because of a mitigation request conflict.

 

It is also possible that = a mitigation state is status 1 (parameter value – Table 2)) and = needs to transition to another state – at which point the conflict = is found - possibly by the DOTS mitigator - which then needs to be = relayed back through the DOTS server.

 

Regards

 

Jon

 

From: Konda, Tirumaleswar Reddy [mailto: TirumaleswarReddy_Kond= a@mcafee.com]
Sent: 28 November 2017 11:42
To: = Jon Shallow; mohamed.boucadair@orange.com= ; dots@ietf.org
Subject: RE: = [Dots] signal-channel: Conflict detection and = notification

 

Hi Jon,

 

What is the problem if the DOTS = server returns 4.09 (conflict) error response for the conflicting = mitigation request from Client-A ?

The above error code is already = defined https://tools.ietf.org/html/rfc8132<= /span>. =

 

-Tiru

 

From: Dots [mailto:dots-bounces@ietf.org] = On Behalf Of Jon Shallow
Sent: Tuesday, November 28, = 2017 4:50 PM
To: mohamed.boucadair@orange.com= ; dots@ietf.org
Subject: Re: = [Dots] signal-channel: Conflict detection and = notification

 

Hi Med,

 

See = inline

 

Regards

 

Jon

 

From: Dots [mailto: dots-bounces@ietf.org] On = Behalf Of ietf-supjps-moha= med.boucadair@orange.com
Sent: 24 November 2017 = 14:03
To: dots@ietf.org
Subject: = [Dots] signal-channel: Conflict detection and = notification

 

Hi = all,

 

As = discussed during the last IETF meeting, we are seeking for feedback from = the WG about how to address this requirement:

 

=3D=3D=3D=3D=3D=3D=3D=3D=3D

   SIG-009  Conflict = Detection and Notification: Multiple DOTS = clients

      controlled = by a single administrative entity may send = conflicting

      mitigation = requests for pools of protected resources as a = result

      of = misconfiguration, operator error, or compromised DOTS = clients.

      DOTS = servers in the same administrative domain attempting to = honor

      conflicting = requests may flap network route or DNS = information,

      degrading = the networks attempting to participate in attack

      response = with the DOTS clients.  DOTS servers in a = single

      = administrative domain SHALL detect such conflicting requests, = and

      SHALL = notify the DOTS clients in conflict.  The = notification

      SHOULD = indicate the nature and scope of the conflict, for = example,

      the = overlapping prefix range in a conflicting mitigation = request.

=3D=3D=3D=3D=3D=3D=3D=3D

 

For = example, would it be OK if we leave implementation-specific the criteria = upon which a dots server relies to consider two requests from two = clients as conflicting, but draft-ietf-dots-signal defines only the = procedure to notify clients when a conflict is detected? =

Jon> I agree that how this is done is = implementation specific.  However there is a scenario where = Client-A initiates a mitigation requests which is acted upon, Client-B = does a conflicting mitigation request but the DOTS Server decides that = Client-B is the “more” valid mitigation request and = effectively de-activates Client-A’s request.  Table 2: = draft-ietf-dots-signal-channel-09 therefore needs an additional status = parameter to indicate to client-A there is a conflict and hence Client-A = is being stood down while another client is controlling the = mitigation.  A suggestion would be

 

7 | DOTS = Server has detected conflicting mitigation requests from different DOTS = clients.  This mitigation request is currently inactive until the = conflicts are resolved. Another mitigation request is = active.

 

Jon> The = DOTS client can then elect to leave in the mitigation request (and even = refresh the PUT to refresh the timeout) or delete = it.

Jon> I do not think it appropriate that an = error message be sent back (e.g. 4.xx) if the DOTS server immediately = decides there is a conflicting request and closes down the new PUT = request unless we come up with a specific error code so the DOTS client = can understand why the request is getting = errored.

 

 

Likewise, would it be OK if the document does not specify which of = the conflicting actions is to be discarded (old, new, all) by the = server, but draft-ietf-dots-signal defines how to inform clients about = which action was enforced by the server?

 

Jon> = Again, I think that this would be implementation specific.  The = suggested Table 2: entry above would cover this as well.  The DOTS = client just needs to know it has been de-selected / discarded – I = don’t think the DOTS client needs to know how / why the DOTS = server chose that particular DOTS client.

 

Cheers,

Med =

------=_NextPart_000_0114_01D36853.48F22780-- From nobody Tue Nov 28 07:03:14 2017 Return-Path: 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 706E1124E15 for ; Tue, 28 Nov 2017 07:03:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.999 X-Spam-Level: X-Spam-Status: No, score=-6.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 0xenmMzEIN4B for ; Tue, 28 Nov 2017 07:03:05 -0800 (PST) Received: from MIVWSMAILOUT1.mcafee.com (mivwsmailout1.mcafee.com [161.69.47.167]) (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 091E81200B9 for ; Tue, 28 Nov 2017 07:03:04 -0800 (PST) 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=1511881383; 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: x-originating-ip:x-ms-publictraffictype:x-microsoft-exchange-diagnostics: x-ms-exchange-antispam-srfa-diagnostics:x-ms-office365-filtering-correlation-id: x-microsoft-antispam:x-ms-traffictypediagnostic: authentication-results:x-microsoft-antispam-prvs: x-exchange-antispam-report-test:x-exchange-antispam-report-cfa-test: x-forefront-prvs:x-forefront-antispam-report: received-spf:spamdiagnosticoutput:spamdiagnosticmetadata: Content-Type: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-Transport-CrossTenantHeadersStamped: X-OriginatorOrg:X-NAI-Spam-Flag:X-NAI-Spam-Level: X-NAI-Spam-Threshold:X-NAI-Spam-Score:X-NAI-Spam-Version; bh=5EDlXnOIf4JHpIKWN93zlwtC8z1742qhEiFBIv EMTeU=; b=E0ZWQ2U26D/qVejtRon38xSMmxIJ2LRTJXZJvaYi xy+nmiWVwgqB4lYmZEI+52OitZ+Zfy0aZ1R29ut2NcfjMMacIx J/6i4Zw7Shl613hN4v+r3sqOLFpOBZNjv+6Zf1vNz00IXxnsYX 3ZshYYEn1fhVGw/Hq2SgiXQWfm7YjXc= Received: from MIVEXAPP1N03.corpzone.internalzone.com (mivexapp1n03.corpzone.internalzone.com [10.48.48.90]) by MIVWSMAILOUT1.mcafee.com with smtp id 4149_dc5d_3c90cd58_135c_45f1_b55f_515031235905; Tue, 28 Nov 2017 09:03:03 -0600 Received: from MIVEXUSR1N05.corpzone.internalzone.com (10.48.48.85) by MIVEXAPP1N03.corpzone.internalzone.com (10.48.48.90) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Tue, 28 Nov 2017 10:01:55 -0500 Received: from MIVEXUSR1N02.corpzone.internalzone.com (10.48.48.82) by MIVEXUSR1N05.corpzone.internalzone.com (10.48.48.85) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Tue, 28 Nov 2017 10:01:48 -0500 Received: from MIVO365EDGE3.corpzone.internalzone.com (10.48.176.86) by MIVEXUSR1N02.corpzone.internalzone.com (10.48.48.82) with Microsoft SMTP Server (TLS) id 15.0.1347.2 via Frontend Transport; Tue, 28 Nov 2017 10:01:48 -0500 Received: from NAM01-SN1-obe.outbound.protection.outlook.com (10.48.176.241) by edge.mcafee.com (10.48.176.86) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Tue, 28 Nov 2017 10:01:45 -0500 Received: from DM5PR16MB1788.namprd16.prod.outlook.com (10.172.44.144) by DM5PR16MB1788.namprd16.prod.outlook.com (10.172.44.144) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.260.4; Tue, 28 Nov 2017 15:01:45 +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.20.0260.006; Tue, 28 Nov 2017 15:01:45 +0000 From: "Konda, Tirumaleswar Reddy" To: Jon Shallow , "mohamed.boucadair@orange.com" , "dots@ietf.org" Thread-Topic: [Dots] signal-channel: Conflict detection and notification Thread-Index: AQI5QycoOO+6Sl3hDoQKXRH887G99aJd55JwgAAKs5CAABDPgIAAEDEAgAAM/YCAAAnqQA== Date: Tue, 28 Nov 2017 15:01:45 +0000 Message-ID: References: <787AE7BB302AE849A7480A190F8B93300A07F4E4@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <009b01d3683a$c6158f90$5240aeb0$@jpshallow.com> <00e201d36844$b1b39ec0$151adc40$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93300A0819DB@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <011301d36853$48efb680$dacf2380$@jpshallow.com> In-Reply-To: <011301d36853$48efb680$dacf2380$@jpshallow.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [122.172.101.195] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DM5PR16MB1788; 6:drptg8Qmkr+p+l/zZp15tF1O1i9QRJ7PGsy5XxaCkbakqpJ8ZvCKefJuW0NU5G9gXF+zBYLy7oMI4QGrlYXyGKJYOIkwhCqP5/DDcqcQqtnyBjMPaY3zmBoyNzc3PdffkGaVsuEzd4uE+ALiV07oY+LS38YoPDADs356C4vC2gi6pzlpziDfkUFOeEOX8u5/rYMxg9Nl9E6AlagWbDZG3D+aNHPb1n8GG3j7FYH84F8Vy240S7G5BEtSGl0MTPMK7wwCpDkSY9Gub6Rxfl49f/+jmb1Dj9Mu91fDOP363xu+1/DyiIEmlCmDhmKZFsVb5VSI2y6asamTOhPyuYbpS1Zw5n5QsL4mSQDosj6EWRQ=; 5:uW9BVFwQn7hIcQ7J9TR6qzxEy3N4j5hoa5B60YSpLgngciDdFvdqN2hXNUP94Csh9AU/nz0uvZR+EIZwOzLywryQdd+2eCKAdDDR0K9qs0KjcsOo9EluSdgMIBji8LBzUGXIZDjxBTHMddd5zz9KXBZUCoxZmfV1NHg3SqxmDLk=; 24:iLMfqD3vad1wN5smmC5a/yl1rI7fezMUuuURmkSTZmUby/bWvIN/9umflSrEV4NDs2HoJ4MlHQHINoogA0yN8f3QDnfcoZSTuOkaXezI5WQ=; 7:rgnehHKDV5tXlqAXJfAOpcQZ4npU8aLwgVGer7RiK4o9zpHnpoNANnbxNT4ZO4e63CbkQnx5Wm4s/Ya3yedL7OLTs9WMJ0GEhm3R2VxREzSoTijG2QOqsDJ0d61BUnBZD9pGevXdAMJsz6iiOvQsXSTS+EQFV/r5Yr5ngjcQ+6e455apmVNKFJ57m5I5kNNIxNmXOJQLOaINVrewI0oH0d5uip7EksYoIzhcXwEdPjBmTdm++2ZtDwc8tKlLfmP0 x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: a953771f-73bc-4298-dce9-08d53670f158 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(5600026)(4604075)(2017052603258); SRVR:DM5PR16MB1788; x-ms-traffictypediagnostic: DM5PR16MB1788: authentication-results: spf=none (sender IP is ) smtp.mailfrom=TirumaleswarReddy_Konda@McAfee.com; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(190756311086443)(158342451672863)(20558992708506)(227612066756510)(18271650672692)(21748063052155)(211171220733660)(123452027830198); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(2401047)(5005006)(8121501046)(93006095)(93001095)(3231022)(3002001)(10201501046)(6041248)(20161123560025)(20161123558100)(20161123555025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123564025)(20161123562025)(6072148)(201708071742011); SRVR:DM5PR16MB1788; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:DM5PR16MB1788; x-forefront-prvs: 0505147DDB x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(376002)(346002)(366004)(39860400002)(199003)(189002)(32952001)(53754006)(51444003)(53936002)(7736002)(8676002)(81156014)(74316002)(81166006)(25786009)(316002)(80792005)(99286004)(97736004)(101416001)(6306002)(50986999)(54356999)(86362001)(5660300001)(54896002)(6246003)(76176999)(77096006)(189998001)(6506006)(55016002)(6436002)(229853002)(2201001)(66066001)(19609705001)(9686003)(2950100002)(2900100001)(105586002)(106356001)(33656002)(93886005)(236005)(7110500001)(478600001)(72206003)(966005)(14454004)(7696005)(15650500001)(2501003)(53546010)(110136005)(345774005)(2906002)(2420400007)(8936002)(6116002)(10710500007)(790700001)(3280700002)(102836003)(606006)(68736007)(3846002)(3660700001)(85282002); DIR:OUT; SFP:1101; SCL:1; SRVR:DM5PR16MB1788; H:DM5PR16MB1788.namprd16.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX: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_DM5PR16MB17883E66AD4F8C1D9707D8A0EA3A0DM5PR16MB1788namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: a953771f-73bc-4298-dce9-08d53670f158 X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Nov 2017 15:01:45.3975 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4943e38c-6dd4-428c-886d-24932bc2d5de X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR16MB1788 X-OriginatorOrg: mcafee.com X-NAI-Spam-Flag: NO X-NAI-Spam-Level: X-NAI-Spam-Threshold: 15 X-NAI-Spam-Score: 0.9 X-NAI-Spam-Version: 2.3.0.9418 : core <6168> : inlines <6187> : streams <1771587> : uri <2541575> Archived-At: Subject: Re: [Dots] signal-channel: Conflict detection and notification 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Nov 2017 15:03:12 -0000 --_000_DM5PR16MB17883E66AD4F8C1D9707D8A0EA3A0DM5PR16MB1788namp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Within a administrative domain, there won't be many different DOTS clients = raising conflicting mitigation requests for the same target, the conflict m= ay arise between a DDoS Detector (or a on premise DDoS mitigation system) a= cting as DOTS clients and a web server with in-built DDoS detection capabil= ity. Under what conditions does the DOTS server return "DOTS Server has detected= conflicting mitigation requests from different DOTS clients. All conflict= ing mitigation requests are inactive." ? -Tiru From: Jon Shallow [mailto:supjps-ietf@jpshallow.com] Sent: Tuesday, November 28, 2017 7:45 PM To: mohamed.boucadair@orange.com; Konda, Tirumaleswar Reddy ; dots@ietf.org Subject: RE: [Dots] signal-channel: Conflict detection and notification Hi Med, In principal I accept the concept of your 7, 8 & 9 status which in effect a= re part of the mitigation state as in a state diagram. However, having iss= ued a "8" status, this then needs to transition to another state which refl= ects what is actually happening - e.g. "2". The actual state could immediately be sent following the reporting of "8" (= if Observe active), else it would need to wait until the next status GET. = It is possible that the "8" message gets lost, so relying on receiving the = "8" could be dangerous. With a "9" response what then is the DOTS client allowed to do? - A retry of the original mitigation request is likely to fail again - If all the DOTS clients back off, then there will be no mitigation - Should there be a random back-off time before retrying? What is critical is that DOTS servers in the same administrative domain attempting to honor conflicting requests may flap network route or DNS information, degrading the networks attempting to participate in attack response with the DOTS clients. Should not be allowed to happen. I also do not want to lose sight of The notification SHOULD indicate the nature and scope of the conflict, for example, the overlapping prefix range in a conflicting mitigation reque= st." This potentially can be conveyed in the 4.09 message, or could be a new mit= igation status parameter such as "additional-info" with an appropriate text= value. It could be that "status" stays with "1" through "6", and (possibl= y optional) "additional-status" has 0 | This DOTS client mitigation request is being honoured 1 | DOTS Server has detected conflicting mitigation requests from different= DOTS clients. This mitigation request is currently inactive until the con= flicts are resolved. Another mitigation request is active. 2 | DOTS Server has detected conflicting mitigation requests from different= DOTS clients. This mitigation request is currently active. 3 | DOTS Server has detected conflicting mitigation requests from different= DOTS clients. All conflicting mitigation requests are inactive. And "additional-info" reports on what the nature and scope of the conflict = is. Regards Jon From: Dots [mailto: dots-bounces@ietf.org] On= Behalf Of mohamed.boucadair@orange.com Sent: 28 November 2017 13:29 To: Jon Shallow; 'Konda, Tirumaleswar Reddy'; dots@ietf.org Subject: Re: [Dots] signal-channel: Conflict detection and notification Hi Jon, all, Thank you for sharing your thoughts on this. I tend to allow for both 4.09 code and new status values in the spec. I see that you proposed this new value: =3D=3D 7 | DOTS Server has detected conflicting mitigation requests from different= DOTS clients. This mitigation request is currently inactive until the con= flicts are resolved. Another mitigation request is active. =3D=3D Please note that a server may be instructed to adopt a more strict behavior= by deactivating all conflicting requests. Further, all DOTS clients which = issued conflicting requests should be notified, not only the one for which = a request is de-activated. As such, I'm afraid we will need more values, e.= g., =3D=3D 7 | DOTS Server has detected conflicting mitigation requests from different= DOTS clients. This mitigation request is currently inactive until the con= flicts are resolved. Another mitigation request is active. 8 | DOTS Server has detected conflicting mitigation requests from different= DOTS clients. This mitigation request is currently active. 9 | DOTS Server has detected conflicting mitigation requests from different= DOTS clients. All conflicting mitigation requests are inactive. =3D=3D For example: * If the server decides to activate only one request, then 7 will be sent t= o all clients for which the request is de-activated and 8 to the client for= which the request is maintained active. * If the server decides to deactivate all requests, then 9 will be sent to = all clients. Cheers, Med De : Jon Shallow [mailto:supjps-ietf@jpshallow.com] Envoy=E9 : mardi 28 novembre 2017 13:31 =C0 : 'Konda, Tirumaleswar Reddy'; BOUCADAIR Mohamed IMT/OLN; dots@ietf.org= Objet : RE: [Dots] signal-channel: Conflict detection and notification Hi Tiru, If Client-A has invoked a mitigation, then Client-B requests a conflicting = mitigation, if the DOTS server is only allowing the first mitigation reques= t to be the valid one, then the DOTS server could send back a 4.09 to Clien= t-B. However, if the DOTS server is allowed to choose the best mitigation reques= t, decides it is Client-B, there is no simple way of sending an unsolicited= 4.09 to client-A. Hence suggestion for an additional status message which= can be sent to Client-A stating that Client-A has been de-selected because= of a mitigation request conflict. It is also possible that a mitigation state is status 1 (parameter value - = Table 2)) and needs to transition to another state - at which point the con= flict is found - possibly by the DOTS mitigator - which then needs to be re= layed back through the DOTS server. Regards Jon From: Konda, Tirumaleswar Reddy [mailto: TirumaleswarReddy_Konda@mcafee.com= ] Sent: 28 November 2017 11:42 To: Jon Shallow; mohamed.boucadair@orange.com; dots@ietf.org Subject: RE: [Dots] signal-channel: Conflict detection and notification Hi Jon, What is the problem if the DOTS server returns 4.09 (conflict) error respon= se for the conflicting mitigation request from Client-A ? The above error code is already defined https://tools.ietf.org/html/rfc8132= . -Tiru From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Jon Shallow Sent: Tuesday, November 28, 2017 4:50 PM To: mohamed.boucadair@orange.com; dots= @ietf.org Subject: Re: [Dots] signal-channel: Conflict detection and notification Hi Med, See inline Regards Jon From: Dots [mailto: dots-bounces@ietf.org] On= Behalf Of ietf-supjps-mohamed.boucadair@orange.com Sent: 24 November 2017 14:03 To: dots@ietf.org Subject: [Dots] signal-channel: Conflict detection and notification Hi all, As discussed during the last IETF meeting, we are seeking for feedback from= the WG about how to address this requirement: =3D=3D=3D=3D=3D=3D=3D=3D=3D SIG-009 Conflict Detection and Notification: Multiple DOTS clients controlled by a single administrative entity may send conflicting mitigation requests for pools of protected resources as a result of misconfiguration, operator error, or compromised DOTS clients. DOTS servers in the same administrative domain attempting to honor conflicting requests may flap network route or DNS information, degrading the networks attempting to participate in attack response with the DOTS clients. DOTS servers in a single administrative domain SHALL detect such conflicting requests, and SHALL notify the DOTS clients in conflict. The notification SHOULD indicate the nature and scope of the conflict, for example, the overlapping prefix range in a conflicting mitigation request. =3D=3D=3D=3D=3D=3D=3D=3D For example, would it be OK if we leave implementation-specific the criteri= a upon which a dots server relies to consider two requests from two clients= as conflicting, but draft-ietf-dots-signal defines only the procedure to n= otify clients when a conflict is detected? Jon> I agree that how this is done is implementation specific. However the= re is a scenario where Client-A initiates a mitigation requests which is ac= ted upon, Client-B does a conflicting mitigation request but the DOTS Serve= r decides that Client-B is the "more" valid mitigation request and effectiv= ely de-activates Client-A's request. Table 2: draft-ietf-dots-signal-chann= el-09 therefore needs an additional status parameter to indicate to client-= A there is a conflict and hence Client-A is being stood down while another = client is controlling the mitigation. A suggestion would be 7 | DOTS Server has detected conflicting mitigation requests from different= DOTS clients. This mitigation request is currently inactive until the con= flicts are resolved. Another mitigation request is active. Jon> The DOTS client can then elect to leave in the mitigation request (and= even refresh the PUT to refresh the timeout) or delete it. Jon> I do not think it appropriate that an error message be sent back (e.g.= 4.xx) if the DOTS server immediately decides there is a conflicting reques= t and closes down the new PUT request unless we come up with a specific err= or code so the DOTS client can understand why the request is getting errore= d. Likewise, would it be OK if the document does not specify which of the conf= licting actions is to be discarded (old, new, all) by the server, but draft= -ietf-dots-signal defines how to inform clients about which action was enfo= rced by the server? Jon> Again, I think that this would be implementation specific. The sugges= ted Table 2: entry above would cover this as well. The DOTS client just ne= eds to know it has been de-selected / discarded - I don't think the DOTS cl= ient needs to know how / why the DOTS server chose that particular DOTS cli= ent. Cheers, Med --_000_DM5PR16MB17883E66AD4F8C1D9707D8A0EA3A0DM5PR16MB1788namp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Within a administrative domain, there won’t be man= y different DOTS clients raising conflicting mitigation requests for the sa= me target, the conflict may arise between a DDoS Detector (or a on premise DDoS mitigation system) acting as DOTS clie= nts and a web server with in-built DDoS detection capability. 

 

Under what conditions does the DOTS ser= ver return “DOTS Server has detected conflicting mitigation requests = from different DOTS clients.  All conflicting mitigation requests are inactive.” ?

 

-Tiru

 

From:<= /span> Jon Shallow [mailto:s= upjps-ietf@jpshallow.com]
Sent: Tuesday, November 28, 2017 7:45 PM
To: mohamed.boucadair@orange.com; Konda, Tirumaleswar Reddy <Tiru= maleswarReddy_Konda@McAfee.com>; dots@ietf.org
Subject: RE: [Dots] signal-channel: Conflict detection and notificat= ion

 

Hi Med,=

&n= bsp;

In prin= cipal I accept the concept of your 7, 8 & 9 status which in effect are = part of the mitigation state as in a state diagram.  However, having i= ssued a “8” status, this then needs to transition to another state which reflects what is actually happening – e.g. &#= 8220;2”.

&n= bsp;

The act= ual state could immediately be sent following the reporting of “8R= 21; (if Observe active), else it would need to wait until the next status G= ET.  It is possible that the “8” message gets lost, so relying on receiving the “8” could be dangerous.=

&n= bsp;

With a = “9” response what then is the DOTS client allowed to do?

- A ret= ry of the original mitigation request is likely to fail again

- If al= l the DOTS clients back off, then there will be no mitigation

- Shoul= d there be a random back-off time before retrying?

&n= bsp;

What is= critical is that

      DOT= S servers in the same administrative domain attempting to honor<= /span>

      con= flicting requests may flap network route or DNS information,

      deg= rading the networks attempting to participate in attack

      res= ponse with the DOTS clients.

Should not b= e allowed to happen.

&n= bsp;

I also = do not want to lose sight of

The not= ification SHOULD indicate the nature and scope of the conflict,<= /span>

for exa= mple, the overlapping prefix range in a conflicting mitigation request.R= 21;

This po= tentially can be conveyed in the 4.09 message, or could be a new mitigation= status parameter such as "additional-info" with an appropriate t= ext value.  It could be that “status” stays with “1” through “6”, and (possibly optional) “ad= ditional-status” has

0 | Thi= s DOTS client mitigation request is being honoured

1 | DOTS Server has de= tected conflicting mitigation requests from different DOTS clients.  T= his mitigation request is currently inactive until the conflicts are resolv= ed. Another mitigation request is active.

2 | DOTS Server has de= tected conflicting mitigation requests from different DOTS clients.  T= his mitigation request is currently active.

3 | DOTS Server has de= tected conflicting mitigation requests from different DOTS clients.  A= ll conflicting mitigation requests are inactive.

And = 220;additional-info” reports on what the nature and scope of the conf= lict is.

&n= bsp;

Regards=

&n= bsp;

Jon

&n= bsp;

From: Dots [mailto: dots-bounces@ietf.org] On B= ehalf Of mohamed.boucadair@orang= e.com
Sent: 28 November 2017 13:29
To: Jon Shallow; 'Konda, Tirumaleswar Reddy'; dots@ietf.org
Subject: Re: [Dots] signal-channel: Conflict detection and notificat= ion

 

Hi Jon, all,

 

Thank you for sharing your thoughts on this.

 

I tend to allow for both 4.09 code and new sta= tus values in the spec.

 

I see that you proposed this new value:

=3D=3D

7 | DOTS Server has de= tected conflicting mitigation requests from different DOTS clients.  T= his mitigation request is currently inactive until the conflicts are resolv= ed. Another mitigation request is active.

=3D=3D

 

Please note that a server may be instructed to= adopt a more strict behavior by deactivating all conflicting requests. Fur= ther, all DOTS clients which issued conflicting requests should be notified, not only the one for which a request is de-ac= tivated. As such, I’m afraid we will need more values, e.g.,

 

=3D=3D

7 | DOTS Server has de= tected conflicting mitigation requests from different DOTS clients.  T= his mitigation request is currently inactive until the conflicts are resolv= ed. Another mitigation request is active.

8 | DOTS Server has de= tected conflicting mitigation requests from different DOTS clients.  T= his mitigation request is currently active.

9 | DOTS Server has de= tected conflicting mitigation requests from different DOTS clients.  A= ll conflicting mitigation requests are inactive.

=3D=3D

 

For example:

* If the server decides to activate only one r= equest, then 7 will be sent to all clients for which the request is de-acti= vated and 8 to the client for which the request is maintained active.

* If the server decides to deactivate all requ= ests, then 9 will be sent to all clients.  

 

Cheers,

Med

 

De : Jon Shallow [mailto:supjps-ietf@jpshallow.com]
Envoy=E9 : mardi 28 novembre 2017 13:31
=C0 : 'Konda, Tirumaleswar Reddy'; BOUCADAIR Mohamed IMT/OLN; dots@ietf.org
Objet : RE: [Dots] signal-channel: Conflict detection and notif= ication

 

Hi Tiru= ,

&n= bsp;

If Clie= nt-A has invoked a mitigation, then Client-B requests a conflicting mitigat= ion, if the DOTS server is only allowing the first mitigation request to be= the valid one, then the DOTS server could send back a 4.09 to Client-B.

&n= bsp;

However= , if the DOTS server is allowed to choose the best mitigation request, deci= des it is Client-B, there is no simple way of sending an unsolicited 4.09 t= o client-A.  Hence suggestion for an additional status message which can be sent to Client-A stating that Client-A has bee= n de-selected because of a mitigation request conflict.

&n= bsp;

It is a= lso possible that a mitigation state is status 1 (parameter value – T= able 2)) and needs to transition to another state – at which point th= e conflict is found - possibly by the DOTS mitigator - which then needs to be relayed back through the DOTS server.<= /span>

&n= bsp;

Regards=

&n= bsp;

Jon

&n= bsp;

From: Konda, Tirumaleswar Reddy [mailto: TirumaleswarReddy_Kon= da@mcafee.com]
Sent: 28 November 2017 11:42
To: Jon Shallow; moh= amed.boucadair@orange.com; dots@ietf.org
Subject: RE: [Dots] signal-channel: Conflict detection and notificat= ion

 

Hi Jon,

&nbs= p;

What is t= he problem if the DOTS server returns 4.09 (conflict) error response for th= e conflicting mitigation request from Client-A ?

The above= error code is already defined https://tools.ie= tf.org/html/rfc8132.

&nbs= p;

-Tiru

&nbs= p;

From:<= /span> Dots [mailto:dots-bounces@ietf.org] On Behalf Of Jon Shallow
Sent: Tuesday, November 28, 2017 4:50 PM
To: mohamed.boucadai= r@orange.com; dots@ietf.org
Subject: Re: [Dots] signal-channel: Conflict detection and notificat= ion

 

Hi Med,=

&n= bsp;

See inl= ine

&n= bsp;

Regards=

&n= bsp;

Jon

&n= bsp;

From: Dots [mailto: dots-bounces@ietf.org] On B= ehalf Of ietf-supjps= -mohamed.boucadair@orange.com
Sent: 24 November 2017 14:03
To: dots@ietf.org
Subject: [Dots] signal-channel: Conflict detection and notification<= o:p>

 

Hi all,

 

As discussed during the last IETF meeting, we are seeking = for feedback from the WG about how to address this requirement:<= /span>

 

=3D=3D=3D=3D=3D=3D=3D=3D=3D

   SIG-009  Conflic= t Detection and Notification: Multiple DOTS clients

      con= trolled by a single administrative entity may send conflicting

      mit= igation requests for pools of protected resources as a result

      of = misconfiguration, operator error, or compromised DOTS clients.

      DOT= S servers in the same administrative domain attempting to honor<= /span>

      con= flicting requests may flap network route or DNS information,

      deg= rading the networks attempting to participate in attack

      res= ponse with the DOTS clients.  DOTS servers in a single

      adm= inistrative domain SHALL detect such conflicting requests, and

      SHA= LL notify the DOTS clients in conflict.  The notification

      SHO= ULD indicate the nature and scope of the conflict, for example,<= /span>

      the= overlapping prefix range in a conflicting mitigation request.

=3D=3D=3D=3D=3D=3D=3D=3D

 

For example, would it be OK if we leave implementation-spe= cific the criteria upon which a dots server relies to consider two requests= from two clients as conflicting, but draft-ietf-dots-signal defines only the procedure to notify clients when a conflict is detected? =

Jon> I agree that h= ow this is done is implementation specific.  However there is a scenar= io where Client-A initiates a mitigation requests which is acted upon, Clie= nt-B does a conflicting mitigation request but the DOTS Server decides that Client-B is the “more” valid miti= gation request and effectively de-activates Client-A’s request. = Table 2: draft-ietf-dots-signal-channel-09 therefore needs an additional s= tatus parameter to indicate to client-A there is a conflict and hence Client-A is being stood down while another client is controlling= the mitigation.  A suggestion would be

 

7 | DOTS Server has de= tected conflicting mitigation requests from different DOTS clients.  T= his mitigation request is currently inactive until the conflicts are resolv= ed. Another mitigation request is active.

 

Jon> The DOTS clien= t can then elect to leave in the mitigation request (and even refresh the P= UT to refresh the timeout) or delete it.

Jon> I do not think= it appropriate that an error message be sent back (e.g. 4.xx) if the DOTS = server immediately decides there is a conflicting request and closes down t= he new PUT request unless we come up with a specific error code so the DOTS client can understand why the request is= getting errored.

 

 

Likewise, would it be OK if the document does not specify = which of the conflicting actions is to be discarded (old, new, all) by the = server, but draft-ietf-dots-signal defines how to inform clients about which action was enforced by the server?

 

Jon> Again, I think= that this would be implementation specific.  The suggested Table 2: e= ntry above would cover this as well.  The DOTS client just needs to kn= ow it has been de-selected / discarded – I don’t think the DOTS client needs to know how / why the DOTS server chose that p= articular DOTS client.

 

Cheers,

Med

--_000_DM5PR16MB17883E66AD4F8C1D9707D8A0EA3A0DM5PR16MB1788namp_-- From nobody Tue Nov 28 07:17:37 2017 Return-Path: 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 42796120727 for ; Tue, 28 Nov 2017 07:17:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.617 X-Spam-Level: X-Spam-Status: No, score=-2.617 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 lOa31pgg5uWY for ; Tue, 28 Nov 2017 07:17:32 -0800 (PST) Received: from orange.com (mta136.mail.business.static.orange.com [80.12.70.36]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7663C126D3F for ; Tue, 28 Nov 2017 07:17:32 -0800 (PST) Received: from opfednr06.francetelecom.fr (unknown [xx.xx.xx.70]) by opfednr23.francetelecom.fr (ESMTP service) with ESMTP id EB221C0C43; Tue, 28 Nov 2017 16:17:30 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.59]) by opfednr06.francetelecom.fr (ESMTP service) with ESMTP id CC0021A0090; Tue, 28 Nov 2017 16:17:30 +0100 (CET) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM43.corporate.adroot.infra.ftgroup ([fe80::ec23:902:c31f:731c%19]) with mapi id 14.03.0361.001; Tue, 28 Nov 2017 16:17:28 +0100 From: To: Jon Shallow , "Konda, Tirumaleswar Reddy" , "dots@ietf.org" Thread-Topic: [Dots] signal-channel: Conflict detection and notification Thread-Index: AdNlLOxuTejE5Yr+TiWtd6n7pT4m0QHmvtxLArQ3BpMBrkCf6AG8EcvIoh3syjCiV7+IUA== Date: Tue, 28 Nov 2017 15:17:27 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93300A081AF2@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <787AE7BB302AE849A7480A190F8B93300A07F4E4@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <009b01d3683a$c6158f90$5240aeb0$@jpshallow.com> <00e201d36844$b1b39ec0$151adc40$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93300A0819DB@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <011301d36853$48efb680$dacf2380$@jpshallow.com> In-Reply-To: <011301d36853$48efb680$dacf2380$@jpshallow.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.4] Content-Type: multipart/alternative; boundary="_000_787AE7BB302AE849A7480A190F8B93300A081AF2OPEXCLILMA3corp_" MIME-Version: 1.0 Archived-At: Subject: Re: [Dots] signal-channel: Conflict detection and notification 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Nov 2017 15:17:35 -0000 --_000_787AE7BB302AE849A7480A190F8B93300A081AF2OPEXCLILMA3corp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re-, Please see inline. Cheers, Med De : Jon Shallow [mailto:supjps-ietf@jpshallow.com] Envoy=E9 : mardi 28 novembre 2017 15:15 =C0 : BOUCADAIR Mohamed IMT/OLN; Konda, Tirumaleswar Reddy; dots@ietf.org Objet : RE: [Dots] signal-channel: Conflict detection and notification Hi Med, In principal I accept the concept of your 7, 8 & 9 status which in effect a= re part of the mitigation state as in a state diagram. [Med] Actually, my initial point is that one single additional status messa= ge is not sufficient. We need more granularly. However, having issued a "8" status, this then needs to transition to ano= ther state which reflects what is actually happening - e.g. "2". [Med] Yes for that dots client. The actual state could immediately be sent following the reporting of "8" (= if Observe active), else it would need to wait until the next status GET. [Med] Yes. It is possible that the "8" message gets lost, so relying on receiving th= e "8" could be dangerous. With a "9" response what then is the DOTS client allowed to do? [Med] The rationale for enforcing this policy is that the server "believes"= there is a misconfiguration at the client side and fixes are need at that = front before soliciting the server. At least, clients should log that infor= mation and should not renew the request immediately. - A retry of the original mitigation request is likely to fail again [Med] Exact. - If all the DOTS clients back off, then there will be no mitigation [Med] Exact, but mitigation may not be required to start with. Please remem= ber what happened with Stanislav Petrov, despite a very distinct area. - Should there be a random back-off time before retrying? [Med] The server will maintain the state for a given timer and then will re= move stale entries. Requests received before that timers will be rejected. What is critical is that DOTS servers in the same administrative domain attempting to honor conflicting requests may flap network route or DNS information, degrading the networks attempting to participate in attack response with the DOTS clients. Should not be allowed to happen. I also do not want to lose sight of The notification SHOULD indicate the nature and scope of the conflict, for example, the overlapping prefix range in a conflicting mitigation reque= st." This potentially can be conveyed in the 4.09 message, or could be a new mit= igation status parameter such as "additional-info" with an appropriate text= value. It could be that "status" stays with "1" through "6", and (possibl= y optional) "additional-status" has 0 | This DOTS client mitigation request is being honoured 1 | DOTS Server has detected conflicting mitigation requests from different= DOTS clients. This mitigation request is currently inactive until the con= flicts are resolved. Another mitigation request is active. 2 | DOTS Server has detected conflicting mitigation requests from different= DOTS clients. This mitigation request is currently active. 3 | DOTS Server has detected conflicting mitigation requests from different= DOTS clients. All conflicting mitigation requests are inactive. And "additional-info" reports on what the nature and scope of the conflict = is. Regards Jon From: Dots [mailto: dots-bounces@ietf.org] On= Behalf Of mohamed.boucadair@orange.com Sent: 28 November 2017 13:29 To: Jon Shallow; 'Konda, Tirumaleswar Reddy'; dots@ietf.org Subject: Re: [Dots] signal-channel: Conflict detection and notification Hi Jon, all, Thank you for sharing your thoughts on this. I tend to allow for both 4.09 code and new status values in the spec. I see that you proposed this new value: =3D=3D 7 | DOTS Server has detected conflicting mitigation requests from different= DOTS clients. This mitigation request is currently inactive until the con= flicts are resolved. Another mitigation request is active. =3D=3D Please note that a server may be instructed to adopt a more strict behavior= by deactivating all conflicting requests. Further, all DOTS clients which = issued conflicting requests should be notified, not only the one for which = a request is de-activated. As such, I'm afraid we will need more values, e.= g., =3D=3D 7 | DOTS Server has detected conflicting mitigation requests from different= DOTS clients. This mitigation request is currently inactive until the con= flicts are resolved. Another mitigation request is active. 8 | DOTS Server has detected conflicting mitigation requests from different= DOTS clients. This mitigation request is currently active. 9 | DOTS Server has detected conflicting mitigation requests from different= DOTS clients. All conflicting mitigation requests are inactive. =3D=3D For example: * If the server decides to activate only one request, then 7 will be sent t= o all clients for which the request is de-activated and 8 to the client for= which the request is maintained active. * If the server decides to deactivate all requests, then 9 will be sent to = all clients. Cheers, Med De : Jon Shallow [mailto:supjps-ietf@jpshallow.com] Envoy=E9 : mardi 28 novembre 2017 13:31 =C0 : 'Konda, Tirumaleswar Reddy'; BOUCADAIR Mohamed IMT/OLN; dots@ietf.org= Objet : RE: [Dots] signal-channel: Conflict detection and notification Hi Tiru, If Client-A has invoked a mitigation, then Client-B requests a conflicting = mitigation, if the DOTS server is only allowing the first mitigation reques= t to be the valid one, then the DOTS server could send back a 4.09 to Clien= t-B. However, if the DOTS server is allowed to choose the best mitigation reques= t, decides it is Client-B, there is no simple way of sending an unsolicited= 4.09 to client-A. Hence suggestion for an additional status message which= can be sent to Client-A stating that Client-A has been de-selected because= of a mitigation request conflict. It is also possible that a mitigation state is status 1 (parameter value - = Table 2)) and needs to transition to another state - at which point the con= flict is found - possibly by the DOTS mitigator - which then needs to be re= layed back through the DOTS server. Regards Jon From: Konda, Tirumaleswar Reddy [mailto: TirumaleswarReddy_Konda@mcafee.com= ] Sent: 28 November 2017 11:42 To: Jon Shallow; mohamed.boucadair@orange.com; dots@ietf.org Subject: RE: [Dots] signal-channel: Conflict detection and notification Hi Jon, What is the problem if the DOTS server returns 4.09 (conflict) error respon= se for the conflicting mitigation request from Client-A ? The above error code is already defined https://tools.ietf.org/html/rfc8132= . -Tiru From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Jon Shallow Sent: Tuesday, November 28, 2017 4:50 PM To: mohamed.boucadair@orange.com; dots= @ietf.org Subject: Re: [Dots] signal-channel: Conflict detection and notification Hi Med, See inline Regards Jon From: Dots [mailto: dots-bounces@ietf.org] On= Behalf Of ietf-supjps-mohamed.boucadair@orange.com Sent: 24 November 2017 14:03 To: dots@ietf.org Subject: [Dots] signal-channel: Conflict detection and notification Hi all, As discussed during the last IETF meeting, we are seeking for feedback from= the WG about how to address this requirement: =3D=3D=3D=3D=3D=3D=3D=3D=3D SIG-009 Conflict Detection and Notification: Multiple DOTS clients controlled by a single administrative entity may send conflicting mitigation requests for pools of protected resources as a result of misconfiguration, operator error, or compromised DOTS clients. DOTS servers in the same administrative domain attempting to honor conflicting requests may flap network route or DNS information, degrading the networks attempting to participate in attack response with the DOTS clients. DOTS servers in a single administrative domain SHALL detect such conflicting requests, and SHALL notify the DOTS clients in conflict. The notification SHOULD indicate the nature and scope of the conflict, for example, the overlapping prefix range in a conflicting mitigation request. =3D=3D=3D=3D=3D=3D=3D=3D For example, would it be OK if we leave implementation-specific the criteri= a upon which a dots server relies to consider two requests from two clients= as conflicting, but draft-ietf-dots-signal defines only the procedure to n= otify clients when a conflict is detected? Jon> I agree that how this is done is implementation specific. However the= re is a scenario where Client-A initiates a mitigation requests which is ac= ted upon, Client-B does a conflicting mitigation request but the DOTS Serve= r decides that Client-B is the "more" valid mitigation request and effectiv= ely de-activates Client-A's request. Table 2: draft-ietf-dots-signal-chann= el-09 therefore needs an additional status parameter to indicate to client-= A there is a conflict and hence Client-A is being stood down while another = client is controlling the mitigation. A suggestion would be 7 | DOTS Server has detected conflicting mitigation requests from different= DOTS clients. This mitigation request is currently inactive until the con= flicts are resolved. Another mitigation request is active. Jon> The DOTS client can then elect to leave in the mitigation request (and= even refresh the PUT to refresh the timeout) or delete it. Jon> I do not think it appropriate that an error message be sent back (e.g.= 4.xx) if the DOTS server immediately decides there is a conflicting reques= t and closes down the new PUT request unless we come up with a specific err= or code so the DOTS client can understand why the request is getting errore= d. Likewise, would it be OK if the document does not specify which of the conf= licting actions is to be discarded (old, new, all) by the server, but draft= -ietf-dots-signal defines how to inform clients about which action was enfo= rced by the server? Jon> Again, I think that this would be implementation specific. The sugges= ted Table 2: entry above would cover this as well. The DOTS client just ne= eds to know it has been de-selected / discarded - I don't think the DOTS cl= ient needs to know how / why the DOTS server chose that particular DOTS cli= ent. Cheers, Med --_000_787AE7BB302AE849A7480A190F8B93300A081AF2OPEXCLILMA3corp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Re-,

 

Please see inline.

 

Cheers,

Med

 

De : Jon Shallow [mailto:supjps-ietf= @jpshallow.com]
Envoy=E9 : mardi 28 novembre 2017 15:15
=C0 : BOUCADAIR Mohamed IMT/OLN; Konda, Tirumaleswar Reddy; dot= s@ietf.org
Objet : RE: [Dots] signal-channel: Conflict detection and notif= ication

 

Hi Med,=

&n= bsp;

In prin= cipal I accept the concept of your 7, 8 & 9 status which in effect are = part of the mitigation state as in a state diagram.

[Med] Actuall= y, my initial point is that one single additional status message is not suf= ficient. We need more granularly.

 

  = However, having issued a “8” status, this then needs to transit= ion to another state which reflects what is actually happening – e.g.= “2”.

[Med] Yes for= that dots client.

&n= bsp;

The act= ual state could immediately be sent following the reporting of “8R= 21; (if Observe active), else it would need to wait until the next status G= ET.

[Med] Yes.

 

  = It is possible that the “8” message gets lost, so relying on re= ceiving the “8” could be dangerous.

&n= bsp;

With a = “9” response what then is the DOTS client allowed to do?

[Med] The rat= ionale for enforcing this policy is that the server “believes” = there is a misconfiguration at the client side and fixes are need at that front before soliciting the server. At least, clients should log that info= rmation and should not renew the request immediately.

 

- A ret= ry of the original mitigation request is likely to fail again

[Med] Exact.

- If al= l the DOTS clients back off, then there will be no mitigation

[Med] Exact, = but mitigation may not be required to start with. Please remember what happ= ened with Stanislav Petrov, despite a very distinct area.=

 

- Shoul= d there be a random back-off time before retrying?

[Med] The ser= ver will maintain the state for a given timer and then will remove stale en= tries. Requests received before that timers will be rejected.  

&n= bsp;

What is= critical is that

&= nbsp;     DOTS servers in the same administrative domai= n attempting to honor

&= nbsp;     conflicting requests may flap network route o= r DNS information,

&= nbsp;     degrading the networks attempting to particip= ate in attack

&= nbsp;     response with the DOTS clients.

Should not be allowed to happen.

&n= bsp;

I also = do not want to lose sight of

The notification SHOULD indicate the nature and= scope of the conflict,

for example, the overlapping prefix range in a = conflicting mitigation request.”

This po= tentially can be conveyed in the 4.09 message, or could be a new mitigation= status parameter such as "additional-info" with an appropriate t= ext value.  It could be that “status” stays with “1” through “6”, and (possibly optional) “ad= ditional-status” has

0 | Thi= s DOTS client mitigation request is being honoured

1 | DOT= S Server has detected conflicting mitigation requests from different DOTS c= lients.  This mitigation request is currently inactive until the confl= icts are resolved. Another mitigation request is active.

2 | DOT= S Server has detected conflicting mitigation requests from different DOTS c= lients.  This mitigation request is currently active.

3 | DOT= S Server has detected conflicting mitigation requests from different DOTS c= lients.  All conflicting mitigation requests are inactive.<= /span>

And = 220;additional-info” reports on what the nature and scope of the conf= lict is.

&n= bsp;

Regards=

&n= bsp;

Jon

&n= bsp;

From:= Dots [mailto: dots-bounces@ietf.org] On B= ehalf Of mohamed.boucadair@orang= e.com
Sent: 28 November 2017 13:29
To: Jon Shallow; 'Konda, Tirumaleswar Reddy'; dots@ietf.org
Subject: Re: [Dots] signal-channel: Conflict detection and notificat= ion

 

Hi Jon, all,

 

Thank you for= sharing your thoughts on this.

 

I tend to all= ow for both 4.09 code and new status values in the spec.

 

I see that yo= u proposed this new value:

=3D=3D

7 | DOT= S Server has detected conflicting mitigation requests from different DOTS c= lients.  This mitigation request is currently inactive until the confl= icts are resolved. Another mitigation request is active.

=3D=3D

 

Please note t= hat a server may be instructed to adopt a more strict behavior by deactivat= ing all conflicting requests. Further, all DOTS clients which issued conflicting requests should be notified, not only the one for which= a request is de-activated. As such, I’m afraid we will need more val= ues, e.g.,

 

=3D=3D

7 | DOT= S Server has detected conflicting mitigation requests from different DOTS c= lients.  This mitigation request is currently inactive until the confl= icts are resolved. Another mitigation request is active.

8 | DOT= S Server has detected conflicting mitigation requests from different DOTS c= lients.  This mitigation request is currently active.

9 | DOT= S Server has detected conflicting mitigation requests from different DOTS c= lients.  All conflicting mitigation requests are inactive.<= /span>

=3D=3D

 

For example:<= o:p>

* If the serv= er decides to activate only one request, then 7 will be sent to all clients= for which the request is de-activated and 8 to the client for which the request is maintained active.

* If the serv= er decides to deactivate all requests, then 9 will be sent to all clients. =  

 

Cheers,<= /o:p>

Med

 

J= on Shallow [mailto:supjps-ietf= @jpshallow.com]
Envoy=E9 : mardi 28 novembre 2017 13:31
=C0 : 'Konda, Tirumaleswar Reddy'; BOUCADAIR Mohamed IMT/OLN; dots@ietf.org
Objet : RE: [Dots] signal-channel: Conflict detection and notif= ication

 

Hi Tiru= ,

&n= bsp;

If Clie= nt-A has invoked a mitigation, then Client-B requests a conflicting mitigat= ion, if the DOTS server is only allowing the first mitigation request to be= the valid one, then the DOTS server could send back a 4.09 to Client-B.

&n= bsp;

However= , if the DOTS server is allowed to choose the best mitigation request, deci= des it is Client-B, there is no simple way of sending an unsolicited 4.09 t= o client-A.  Hence suggestion for an additional status message which can be sent to Client-A stating that Client-A has bee= n de-selected because of a mitigation request conflict.

&n= bsp;

It is a= lso possible that a mitigation state is status 1 (parameter value – T= able 2)) and needs to transition to another state – at which point th= e conflict is found - possibly by the DOTS mitigator - which then needs to be relayed back through the DOTS server.<= /span>

&n= bsp;

Regards=

&n= bsp;

Jon

&n= bsp;

From:= Konda, Tirumaleswar Reddy [mailto: TirumaleswarReddy_Konda@mcafee.com]
Sent: 28 November 2017 11:42
To: Jon Shallow; moh= amed.boucadair@orange.com; dots@ietf.org
Subject: RE: [Dots] signal-channel: Conflict detection and notificat= ion

 

Hi Jon,

 

What is the problem if the DOTS server returns 4.09 (conflict) error = response for the conflicting mitigation request from Client-A ?<= /span>

The above error code is already defined https://tools.ie= tf.org/html/rfc8132.

 

-Tiru

 

From: Dots [mailto:dots-bounces= @ietf.org] On Behalf Of Jon Shallow
Sent: Tuesday, November 28, 2017 4:50 PM
To: mohamed.boucadai= r@orange.com; dots@ietf.org
Subject: Re: [Dots] signal-channel: Conflict detection and notificat= ion

 

Hi Med,=

&n= bsp;

See inl= ine

&n= bsp;

Regards=

&n= bsp;

Jon

&n= bsp;

From:= Dots [mailto: dots-bounces@ietf.org] On B= ehalf Of ietf-supjps= -mohamed.boucadair@orange.com
Sent: 24 November 2017 14:03
To: dots@ietf.org
Subject: [Dots] signal-channel: Conflict detection and notification<= o:p>

 

Hi all,

 <= /p>

As discussed during the l= ast IETF meeting, we are seeking for feedback from the WG about how to addr= ess this requirement:

 <= /p>

=3D=3D=3D=3D=3D=3D=3D=3D= =3D

&= nbsp;  SIG-009  Conflict Detection and Notification: Multiple DOT= S clients

&= nbsp;     controlled by a single administrative entity = may send conflicting

&= nbsp;     mitigation requests for pools of protected re= sources as a result

&= nbsp;     of misconfiguration, operator error, or compr= omised DOTS clients.

&= nbsp;     DOTS servers in the same administrative domai= n attempting to honor

&= nbsp;     conflicting requests may flap network route o= r DNS information,

&= nbsp;     degrading the networks attempting to particip= ate in attack

&= nbsp;     response with the DOTS clients.  DOTS se= rvers in a single

&= nbsp;     administrative domain SHALL detect such confl= icting requests, and

&= nbsp;     SHALL notify the DOTS clients in conflict.&nb= sp; The notification

&= nbsp;     SHOULD indicate the nature and scope of the c= onflict, for example,

&= nbsp;     the overlapping prefix range in a conflicting= mitigation request.

=3D=3D=3D=3D=3D=3D=3D=3D<= o:p>

 <= /p>

For example, would it be = OK if we leave implementation-specific the criteria upon which a dots serve= r relies to consider two requests from two clients as conflicting, but draft-ietf-dots-signal defines only the procedure to notify clients wh= en a conflict is detected?

Jon>= I agree that how this is done is implementation specific.  However th= ere is a scenario where Client-A initiates a mitigation requests which is a= cted upon, Client-B does a conflicting mitigation request but the DOTS Server decides that Client-B is the “more”= ; valid mitigation request and effectively de-activates Client-A’s re= quest.  Table 2: draft-ietf-dots-signal-channel-09 therefore needs an = additional status parameter to indicate to client-A there is a conflict and hence Client-A is being stood down while another client = is controlling the mitigation.  A suggestion would be

&n= bsp;

7 | DOT= S Server has detected conflicting mitigation requests from different DOTS c= lients.  This mitigation request is currently inactive until the confl= icts are resolved. Another mitigation request is active.

&n= bsp;

Jon>= The DOTS client can then elect to leave in the mitigation request (and eve= n refresh the PUT to refresh the timeout) or delete it.

Jon>= I do not think it appropriate that an error message be sent back (e.g. 4.x= x) if the DOTS server immediately decides there is a conflicting request an= d closes down the new PUT request unless we come up with a specific error code so the DOTS client can understand wh= y the request is getting errored.

&n= bsp;

 <= /p>

Likewise, would it be OK = if the document does not specify which of the conflicting actions is to be = discarded (old, new, all) by the server, but draft-ietf-dots-signal defines how to inform clients about which action was enforced by the serve= r?

&n= bsp;

Jon>= Again, I think that this would be implementation specific.  The sugge= sted Table 2: entry above would cover this as well.  The DOTS client j= ust needs to know it has been de-selected / discarded – I don’t think the DOTS client needs to know how / why the DO= TS server chose that particular DOTS client.

 <= /p>

Cheers,=

Med

--_000_787AE7BB302AE849A7480A190F8B93300A081AF2OPEXCLILMA3corp_-- From nobody Tue Nov 28 07:18:34 2017 Return-Path: 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 8A064126D3F for ; Tue, 28 Nov 2017 07:18:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.5 X-Spam-Level: X-Spam-Status: No, score=-0.5 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 7jsVdIwOO5cI for ; Tue, 28 Nov 2017 07:18:30 -0800 (PST) Received: from mail.jpshallow.com (mail.jpshallow.com [217.40.240.153]) (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 497A0120727 for ; Tue, 28 Nov 2017 07:18:30 -0800 (PST) Received: from [127.0.0.1] (helo=N01332) by mail.jpshallow.com with smtps (TLSv1:ECDHE-RSA-AES256-SHA:256) (Exim 4.89) (envelope-from ) id 1eJheW-0006BU-Nj for ietf-supjps-dots@ietf.org; Tue, 28 Nov 2017 15:18:28 +0000 From: "Jon Shallow" To: Date: Tue, 28 Nov 2017 15:18:31 -0000 Message-ID: <014101d3685c$26539c50$72fad4f0$@jpshallow.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0142_01D3685C.2654D4D0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdNoXB5u3ro545K8R1evbMe9O8X0GA== Content-Language: en-gb Archived-At: Subject: [Dots] signal-mitigate and alias parameters 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Nov 2017 15:18:31 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0142_01D3685C.2654D4D0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit I know that this is trivial, but uri and fqdn parameters are not prefixed with target- as in module: ietf-dots-signal +--rw mitigation-scope +--rw client-identifier* binary +--rw scope* [mitigation-id] +--rw mitigation-id int32 +--rw target-ip* inet:ip-address +--rw target-prefix* inet:ip-prefix +--rw target-port-range* [lower-port upper-port] | +--rw lower-port inet:port-number | +--rw upper-port inet:port-number +--rw target-protocol* uint8 +--rw fqdn* inet:domain-name +--rw uri* inet:uri +--rw alias-name* string +--rw lifetime? int32 And module: ietf-dots-data-channel-identifier +--rw identifier +--rw client-identifier* binary +--rw alias* [alias-name] +--rw alias-name string +--rw target-ip* inet:ip-address +--rw target-prefix* inet:ip-prefix +--rw target-port-range* [lower-port upper-port] | +--rw lower-port inet:port-number | +--rw upper-port inet:port-number +--rw target-protocol* uint8 +--rw fqdn* inet:domain-name +--rw uri* inet:uri Does it not make sense to add in the target- for fqdn and uri for consistency ? - and update the CBOR mapping! Regards Jon ------=_NextPart_000_0142_01D3685C.2654D4D0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I know = that this is trivial, but uri and fqdn parameters are not prefixed with = target- as in

 

   module: ietf-dots-signal

       +--rw = mitigation-scope

          = +--rw client-identifier*   binary

          = +--rw scope* [mitigation-id]

         &= nbsp;   +--rw = mitigation-id        = int32

         &= nbsp;   +--rw = target-ip*           = inet:ip-address

         &= nbsp;   +--rw = target-prefix*       = inet:ip-prefix

         &= nbsp;   +--rw target-port-range* [lower-port = upper-port]

         &= nbsp;   |  +--rw lower-port    = inet:port-number

         &= nbsp;   |  +--rw upper-port    = inet:port-number

         &= nbsp;   +--rw target-protocol*     = uint8

         &= nbsp;   +--rw = fqdn*           &n= bsp;    inet:domain-name

         &= nbsp;   +--rw = uri*           &nb= sp;     inet:uri

         &= nbsp;   +--rw = alias-name*          = string

         &= nbsp;   +--rw = lifetime?          &nbs= p; int32

 

And

 

   = module: ietf-dots-data-channel-identifier

       +--rw = identifier

          = +--rw client-identifier*   binary

          = +--rw alias* [alias-name]

         &= nbsp;   +--rw = alias-name           = string

         &= nbsp;   +--rw = target-ip*           = inet:ip-address

         &= nbsp;   +--rw = target-prefix*       = inet:ip-prefix

       =       +--rw target-port-range* [lower-port = upper-port]

         &= nbsp;   |  +--rw lower-port    = inet:port-number

         &= nbsp;   |  +--rw upper-port    = inet:port-number

         &= nbsp;   +--rw target-protocol*     = uint8

         &= nbsp;   +--rw = fqdn*           &n= bsp;    inet:domain-name

         &= nbsp;   +--rw = uri*           &nb= sp;     inet:uri

 

Does it not = make sense to add in the target-  for fqdn and uri for consistency = ?

- and update the CBOR = mapping!

 

Regards

 

Jon

------=_NextPart_000_0142_01D3685C.2654D4D0-- From nobody Tue Nov 28 07:24:48 2017 Return-Path: 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 A94CE120727 for ; Tue, 28 Nov 2017 07:24:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.397 X-Spam-Level: X-Spam-Status: No, score=-5.397 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-2.8, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 QurB2E0aplu6 for ; Tue, 28 Nov 2017 07:24:43 -0800 (PST) Received: from orange.com (mta135.mail.business.static.orange.com [80.12.70.35]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 265031200FC for ; Tue, 28 Nov 2017 07:24:43 -0800 (PST) Received: from opfednr01.francetelecom.fr (unknown [xx.xx.xx.65]) by opfednr25.francetelecom.fr (ESMTP service) with ESMTP id 9149D180CFD; Tue, 28 Nov 2017 16:24:41 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.60]) by opfednr01.francetelecom.fr (ESMTP service) with ESMTP id 718911A0077; Tue, 28 Nov 2017 16:24:41 +0100 (CET) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM7F.corporate.adroot.infra.ftgroup ([fe80::c1d7:e278:e357:11ad%19]) with mapi id 14.03.0361.001; Tue, 28 Nov 2017 16:24:41 +0100 From: To: "Konda, Tirumaleswar Reddy" , "Jon Shallow" , "dots@ietf.org" Thread-Topic: [Dots] signal-channel: Conflict detection and notification Thread-Index: AdNlLOxuTejE5Yr+TiWtd6n7pT4m0aJd55JwgAAKs5CAABDPgIAAEDEAgAAM/YCAAAnqQKJXzAPA Date: Tue, 28 Nov 2017 15:24:40 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93300A081B18@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <787AE7BB302AE849A7480A190F8B93300A07F4E4@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <009b01d3683a$c6158f90$5240aeb0$@jpshallow.com> <00e201d36844$b1b39ec0$151adc40$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93300A0819DB@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <011301d36853$48efb680$dacf2380$@jpshallow.com> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.4] Content-Type: multipart/alternative; boundary="_000_787AE7BB302AE849A7480A190F8B93300A081B18OPEXCLILMA3corp_" MIME-Version: 1.0 Archived-At: Subject: Re: [Dots] signal-channel: Conflict detection and notification 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Nov 2017 15:24:47 -0000 --_000_787AE7BB302AE849A7480A190F8B93300A081B18OPEXCLILMA3corp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Tiru, Please see inline. Cheers, Med De : Dots [mailto:dots-bounces@ietf.org] De la part de Konda, Tirumaleswar = Reddy Envoy=E9 : mardi 28 novembre 2017 16:02 =C0 : Jon Shallow; BOUCADAIR Mohamed IMT/OLN; dots@ietf.org Objet : Re: [Dots] signal-channel: Conflict detection and notification Within a administrative domain, there won't be many different DOTS clients = raising conflicting mitigation requests for the same target, the conflict m= ay arise between a DDoS Detector (or a on premise DDoS mitigation system) a= cting as DOTS clients and a web server with in-built DDoS detection capabil= ity. [Med] I don't think that we can speculate about the nature of the conflicts= that may happen. Misconfigured and corrupted software instances may happen= . Under what conditions does the DOTS server return "DOTS Server has detected= conflicting mitigation requests from different DOTS clients. All conflict= ing mitigation requests are inactive." ? [Med] A dots server can be typically instructed by a policy to discard conf= licting requests. The rationale is that the provider thinks that the client= s are misconfigured and something is needed to be fixed before solicited th= e server. The signal-channel does not need to call for a favorite action wh= en conflicts; that is implementation- and deployment-specific. -Tiru From: Jon Shallow [mailto:supjps-ietf@jpshallow.com] Sent: Tuesday, November 28, 2017 7:45 PM To: mohamed.boucadair@orange.com; Kond= a, Tirumaleswar Reddy >; dots@ietf.org Subject: RE: [Dots] signal-channel: Conflict detection and notification Hi Med, In principal I accept the concept of your 7, 8 & 9 status which in effect a= re part of the mitigation state as in a state diagram. However, having iss= ued a "8" status, this then needs to transition to another state which refl= ects what is actually happening - e.g. "2". The actual state could immediately be sent following the reporting of "8" (= if Observe active), else it would need to wait until the next status GET. = It is possible that the "8" message gets lost, so relying on receiving the = "8" could be dangerous. With a "9" response what then is the DOTS client allowed to do? - A retry of the original mitigation request is likely to fail again - If all the DOTS clients back off, then there will be no mitigation - Should there be a random back-off time before retrying? What is critical is that DOTS servers in the same administrative domain attempting to honor conflicting requests may flap network route or DNS information, degrading the networks attempting to participate in attack response with the DOTS clients. Should not be allowed to happen. I also do not want to lose sight of The notification SHOULD indicate the nature and scope of the conflict, for example, the overlapping prefix range in a conflicting mitigation reque= st." This potentially can be conveyed in the 4.09 message, or could be a new mit= igation status parameter such as "additional-info" with an appropriate text= value. It could be that "status" stays with "1" through "6", and (possibl= y optional) "additional-status" has 0 | This DOTS client mitigation request is being honoured 1 | DOTS Server has detected conflicting mitigation requests from different= DOTS clients. This mitigation request is currently inactive until the con= flicts are resolved. Another mitigation request is active. 2 | DOTS Server has detected conflicting mitigation requests from different= DOTS clients. This mitigation request is currently active. 3 | DOTS Server has detected conflicting mitigation requests from different= DOTS clients. All conflicting mitigation requests are inactive. And "additional-info" reports on what the nature and scope of the conflict = is. Regards Jon From: Dots [mailto: dots-bounces@ietf.org] On= Behalf Of mohamed.boucadair@orange.com Sent: 28 November 2017 13:29 To: Jon Shallow; 'Konda, Tirumaleswar Reddy'; dots@ietf.org Subject: Re: [Dots] signal-channel: Conflict detection and notification Hi Jon, all, Thank you for sharing your thoughts on this. I tend to allow for both 4.09 code and new status values in the spec. I see that you proposed this new value: =3D=3D 7 | DOTS Server has detected conflicting mitigation requests from different= DOTS clients. This mitigation request is currently inactive until the con= flicts are resolved. Another mitigation request is active. =3D=3D Please note that a server may be instructed to adopt a more strict behavior= by deactivating all conflicting requests. Further, all DOTS clients which = issued conflicting requests should be notified, not only the one for which = a request is de-activated. As such, I'm afraid we will need more values, e.= g., =3D=3D 7 | DOTS Server has detected conflicting mitigation requests from different= DOTS clients. This mitigation request is currently inactive until the con= flicts are resolved. Another mitigation request is active. 8 | DOTS Server has detected conflicting mitigation requests from different= DOTS clients. This mitigation request is currently active. 9 | DOTS Server has detected conflicting mitigation requests from different= DOTS clients. All conflicting mitigation requests are inactive. =3D=3D For example: * If the server decides to activate only one request, then 7 will be sent t= o all clients for which the request is de-activated and 8 to the client for= which the request is maintained active. * If the server decides to deactivate all requests, then 9 will be sent to = all clients. Cheers, Med De : Jon Shallow [mailto:supjps-ietf@jpshallow.com] Envoy=E9 : mardi 28 novembre 2017 13:31 =C0 : 'Konda, Tirumaleswar Reddy'; BOUCADAIR Mohamed IMT/OLN; dots@ietf.org= Objet : RE: [Dots] signal-channel: Conflict detection and notification Hi Tiru, If Client-A has invoked a mitigation, then Client-B requests a conflicting = mitigation, if the DOTS server is only allowing the first mitigation reques= t to be the valid one, then the DOTS server could send back a 4.09 to Clien= t-B. However, if the DOTS server is allowed to choose the best mitigation reques= t, decides it is Client-B, there is no simple way of sending an unsolicited= 4.09 to client-A. Hence suggestion for an additional status message which= can be sent to Client-A stating that Client-A has been de-selected because= of a mitigation request conflict. It is also possible that a mitigation state is status 1 (parameter value - = Table 2)) and needs to transition to another state - at which point the con= flict is found - possibly by the DOTS mitigator - which then needs to be re= layed back through the DOTS server. Regards Jon From: Konda, Tirumaleswar Reddy [mailto: TirumaleswarReddy_Konda@mcafee.com= ] Sent: 28 November 2017 11:42 To: Jon Shallow; mohamed.boucadair@orange.com; dots@ietf.org Subject: RE: [Dots] signal-channel: Conflict detection and notification Hi Jon, What is the problem if the DOTS server returns 4.09 (conflict) error respon= se for the conflicting mitigation request from Client-A ? The above error code is already defined https://tools.ietf.org/html/rfc8132= . -Tiru From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Jon Shallow Sent: Tuesday, November 28, 2017 4:50 PM To: mohamed.boucadair@orange.com; dots= @ietf.org Subject: Re: [Dots] signal-channel: Conflict detection and notification Hi Med, See inline Regards Jon From: Dots [mailto: dots-bounces@ietf.org] On= Behalf Of ietf-supjps-mohamed.boucadair@orange.com Sent: 24 November 2017 14:03 To: dots@ietf.org Subject: [Dots] signal-channel: Conflict detection and notification Hi all, As discussed during the last IETF meeting, we are seeking for feedback from= the WG about how to address this requirement: =3D=3D=3D=3D=3D=3D=3D=3D=3D SIG-009 Conflict Detection and Notification: Multiple DOTS clients controlled by a single administrative entity may send conflicting mitigation requests for pools of protected resources as a result of misconfiguration, operator error, or compromised DOTS clients. DOTS servers in the same administrative domain attempting to honor conflicting requests may flap network route or DNS information, degrading the networks attempting to participate in attack response with the DOTS clients. DOTS servers in a single administrative domain SHALL detect such conflicting requests, and SHALL notify the DOTS clients in conflict. The notification SHOULD indicate the nature and scope of the conflict, for example, the overlapping prefix range in a conflicting mitigation request. =3D=3D=3D=3D=3D=3D=3D=3D For example, would it be OK if we leave implementation-specific the criteri= a upon which a dots server relies to consider two requests from two clients= as conflicting, but draft-ietf-dots-signal defines only the procedure to n= otify clients when a conflict is detected? Jon> I agree that how this is done is implementation specific. However the= re is a scenario where Client-A initiates a mitigation requests which is ac= ted upon, Client-B does a conflicting mitigation request but the DOTS Serve= r decides that Client-B is the "more" valid mitigation request and effectiv= ely de-activates Client-A's request. Table 2: draft-ietf-dots-signal-chann= el-09 therefore needs an additional status parameter to indicate to client-= A there is a conflict and hence Client-A is being stood down while another = client is controlling the mitigation. A suggestion would be 7 | DOTS Server has detected conflicting mitigation requests from different= DOTS clients. This mitigation request is currently inactive until the con= flicts are resolved. Another mitigation request is active. Jon> The DOTS client can then elect to leave in the mitigation request (and= even refresh the PUT to refresh the timeout) or delete it. Jon> I do not think it appropriate that an error message be sent back (e.g.= 4.xx) if the DOTS server immediately decides there is a conflicting reques= t and closes down the new PUT request unless we come up with a specific err= or code so the DOTS client can understand why the request is getting errore= d. Likewise, would it be OK if the document does not specify which of the conf= licting actions is to be discarded (old, new, all) by the server, but draft= -ietf-dots-signal defines how to inform clients about which action was enfo= rced by the server? Jon> Again, I think that this would be implementation specific. The sugges= ted Table 2: entry above would cover this as well. The DOTS client just ne= eds to know it has been de-selected / discarded - I don't think the DOTS cl= ient needs to know how / why the DOTS server chose that particular DOTS cli= ent. Cheers, Med --_000_787AE7BB302AE849A7480A190F8B93300A081B18OPEXCLILMA3corp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Tiru,

 

Please see inline.

 

Cheers,

Med

 

De : Dots [mailto:dots-bounces@ietf.= org] De la part de Konda, Tirumaleswar Reddy
Envoy=E9 : mardi 28 novembre 2017 16:02
=C0 : Jon Shallow; BOUCADAIR Mohamed IMT/OLN; dots@ietf.org
Objet : Re: [Dots] signal-channel: Conflict detection and notif= ication

 

Within a administrative domain, there won= ’t be many different DOTS clients raising conflicting mitigation requ= ests for the same target, the conflict may arise between a DDoS Detector (or a on premise DDoS mitigation system) acting as= DOTS clients and a web server with in-built DDoS detection capability.&nbs= p;

[Med] I don’t think that we can speculate about the nat= ure of the conflicts that may happen. Misconfigured and corrupted software instances may happen.

 

Under what conditions does the DOTS server return “DOTS Server = has detected conflicting mitigation requests from different DOTS clients.&n= bsp; All conflicting mitigation requests are inactive.” ?

[Med] A dots server can be typically instructed by a policy t= o discard conflicting requests. The rationale is that the provider thinks that the clients are misconfigured and something is needed= to be fixed before solicited the server. The signal-channel does not need = to call for a favorite action when conflicts; that is implementation- and d= eployment-specific.  

 

-Tiru

 

From: Jon Shallow [mailto:s= upjps-ietf@jpshallow.com]
Sent: Tuesday, November 28, 2017 7:45 PM
To: mohamed.boucadai= r@orange.com; Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@McAfee.com>; dots@ietf.org
Subject: RE: [Dots] signal-channel: Conflict detection and notificat= ion

 

Hi Med,=

&n= bsp;

In prin= cipal I accept the concept of your 7, 8 & 9 status which in effect are = part of the mitigation state as in a state diagram.  However, having i= ssued a “8” status, this then needs to transition to another state which reflects what is actually happening – e.g. &#= 8220;2”.

&n= bsp;

The act= ual state could immediately be sent following the reporting of “8R= 21; (if Observe active), else it would need to wait until the next status G= ET.  It is possible that the “8” message gets lost, so relying on receiving the “8” could be dangerous.=

&n= bsp;

With a = “9” response what then is the DOTS client allowed to do?

- A ret= ry of the original mitigation request is likely to fail again

- If al= l the DOTS clients back off, then there will be no mitigation

- Shoul= d there be a random back-off time before retrying?

&n= bsp;

What is= critical is that

&= nbsp;     DOTS servers in the same administrative domai= n attempting to honor

&= nbsp;     conflicting requests may flap network route o= r DNS information,

&= nbsp;     degrading the networks attempting to particip= ate in attack

&= nbsp;     response with the DOTS clients.

Should not be allowed to happen.

&n= bsp;

I also = do not want to lose sight of

The notification SHOULD indicate the nature and= scope of the conflict,

for example, the overlapping prefix range in a = conflicting mitigation request.”

This po= tentially can be conveyed in the 4.09 message, or could be a new mitigation= status parameter such as "additional-info" with an appropriate t= ext value.  It could be that “status” stays with “1” through “6”, and (possibly optional) “ad= ditional-status” has

0 | Thi= s DOTS client mitigation request is being honoured

1 | DOT= S Server has detected conflicting mitigation requests from different DOTS c= lients.  This mitigation request is currently inactive until the confl= icts are resolved. Another mitigation request is active.

2 | DOT= S Server has detected conflicting mitigation requests from different DOTS c= lients.  This mitigation request is currently active.

3 | DOT= S Server has detected conflicting mitigation requests from different DOTS c= lients.  All conflicting mitigation requests are inactive.<= /span>

And = 220;additional-info” reports on what the nature and scope of the conf= lict is.

&n= bsp;

Regards=

&n= bsp;

Jon

&n= bsp;

From:= Dots [mailto: dots-bounces@ietf.org] On B= ehalf Of mohamed.boucadair@orang= e.com
Sent: 28 November 2017 13:29
To: Jon Shallow; 'Konda, Tirumaleswar Reddy'; dots@ietf.org
Subject: Re: [Dots] signal-channel: Conflict detection and notificat= ion

 

Hi Jon, all,

 

Thank you for= sharing your thoughts on this.

 

I tend to all= ow for both 4.09 code and new status values in the spec.

 

I see that yo= u proposed this new value:

=3D=3D

7 | DOT= S Server has detected conflicting mitigation requests from different DOTS c= lients.  This mitigation request is currently inactive until the confl= icts are resolved. Another mitigation request is active.

=3D=3D

 

Please note t= hat a server may be instructed to adopt a more strict behavior by deactivat= ing all conflicting requests. Further, all DOTS clients which issued conflicting requests should be notified, not only the one for which= a request is de-activated. As such, I’m afraid we will need more val= ues, e.g.,

 

=3D=3D

7 | DOT= S Server has detected conflicting mitigation requests from different DOTS c= lients.  This mitigation request is currently inactive until the confl= icts are resolved. Another mitigation request is active.

8 | DOT= S Server has detected conflicting mitigation requests from different DOTS c= lients.  This mitigation request is currently active.

9 | DOT= S Server has detected conflicting mitigation requests from different DOTS c= lients.  All conflicting mitigation requests are inactive.<= /span>

=3D=3D

 

For example:<= o:p>

* If the serv= er decides to activate only one request, then 7 will be sent to all clients= for which the request is de-activated and 8 to the client for which the request is maintained active.

* If the serv= er decides to deactivate all requests, then 9 will be sent to all clients. =  

 

Cheers,<= /o:p>

Med

 

J= on Shallow [mailto:supjps-ietf= @jpshallow.com]
Envoy=E9 : mardi 28 novembre 2017 13:31
=C0 : 'Konda, Tirumaleswar Reddy'; BOUCADAIR Mohamed IMT/OLN; dots@ietf.org
Objet : RE: [Dots] signal-channel: Conflict detection and notif= ication

 

Hi Tiru= ,

&n= bsp;

If Clie= nt-A has invoked a mitigation, then Client-B requests a conflicting mitigat= ion, if the DOTS server is only allowing the first mitigation request to be= the valid one, then the DOTS server could send back a 4.09 to Client-B.

&n= bsp;

However= , if the DOTS server is allowed to choose the best mitigation request, deci= des it is Client-B, there is no simple way of sending an unsolicited 4.09 t= o client-A.  Hence suggestion for an additional status message which can be sent to Client-A stating that Client-A has bee= n de-selected because of a mitigation request conflict.

&n= bsp;

It is a= lso possible that a mitigation state is status 1 (parameter value – T= able 2)) and needs to transition to another state – at which point th= e conflict is found - possibly by the DOTS mitigator - which then needs to be relayed back through the DOTS server.<= /span>

&n= bsp;

Regards=

&n= bsp;

Jon

&n= bsp;

From:= Konda, Tirumaleswar Reddy [mailto: TirumaleswarReddy_Konda@mcafee.com]
Sent: 28 November 2017 11:42
To: Jon Shallow; moh= amed.boucadair@orange.com; dots@ietf.org
Subject: RE: [Dots] signal-channel: Conflict detection and notificat= ion

 

Hi Jon,

 

What is the problem if the DOTS server returns 4.09 (conflict) error = response for the conflicting mitigation request from Client-A ?<= /span>

The above error code is already defined https://tools.ie= tf.org/html/rfc8132.

 

-Tiru

 

From: Dots [mailto:dots-bounces= @ietf.org] On Behalf Of Jon Shallow
Sent: Tuesday, November 28, 2017 4:50 PM
To: mohamed.boucadai= r@orange.com; dots@ietf.org
Subject: Re: [Dots] signal-channel: Conflict detection and notificat= ion

 

Hi Med,=

&n= bsp;

See inl= ine

&n= bsp;

Regards=

&n= bsp;

Jon

&n= bsp;

From:= Dots [mailto: dots-bounces@ietf.org] On B= ehalf Of ietf-supjps= -mohamed.boucadair@orange.com
Sent: 24 November 2017 14:03
To: dots@ietf.org
Subject: [Dots] signal-channel: Conflict detection and notification<= o:p>

 

Hi all,

 <= /p>

As discussed during the l= ast IETF meeting, we are seeking for feedback from the WG about how to addr= ess this requirement:

 <= /p>

=3D=3D=3D=3D=3D=3D=3D=3D= =3D

&= nbsp;  SIG-009  Conflict Detection and Notification: Multiple DOT= S clients

&= nbsp;     controlled by a single administrative entity = may send conflicting

&= nbsp;     mitigation requests for pools of protected re= sources as a result

&= nbsp;     of misconfiguration, operator error, or compr= omised DOTS clients.

&= nbsp;     DOTS servers in the same administrative domai= n attempting to honor

&= nbsp;     conflicting requests may flap network route o= r DNS information,

&= nbsp;     degrading the networks attempting to particip= ate in attack

&= nbsp;     response with the DOTS clients.  DOTS se= rvers in a single

&= nbsp;     administrative domain SHALL detect such confl= icting requests, and

&= nbsp;     SHALL notify the DOTS clients in conflict.&nb= sp; The notification

&= nbsp;     SHOULD indicate the nature and scope of the c= onflict, for example,

&= nbsp;     the overlapping prefix range in a conflicting= mitigation request.

=3D=3D=3D=3D=3D=3D=3D=3D<= o:p>

 <= /p>

For example, would it be = OK if we leave implementation-specific the criteria upon which a dots serve= r relies to consider two requests from two clients as conflicting, but draft-ietf-dots-signal defines only the procedure to notify clients wh= en a conflict is detected?

Jon>= I agree that how this is done is implementation specific.  However th= ere is a scenario where Client-A initiates a mitigation requests which is a= cted upon, Client-B does a conflicting mitigation request but the DOTS Server decides that Client-B is the “more”= ; valid mitigation request and effectively de-activates Client-A’s re= quest.  Table 2: draft-ietf-dots-signal-channel-09 therefore needs an = additional status parameter to indicate to client-A there is a conflict and hence Client-A is being stood down while another client = is controlling the mitigation.  A suggestion would be

&n= bsp;

7 | DOT= S Server has detected conflicting mitigation requests from different DOTS c= lients.  This mitigation request is currently inactive until the confl= icts are resolved. Another mitigation request is active.

&n= bsp;

Jon>= The DOTS client can then elect to leave in the mitigation request (and eve= n refresh the PUT to refresh the timeout) or delete it.

Jon>= I do not think it appropriate that an error message be sent back (e.g. 4.x= x) if the DOTS server immediately decides there is a conflicting request an= d closes down the new PUT request unless we come up with a specific error code so the DOTS client can understand wh= y the request is getting errored.

&n= bsp;

 <= /p>

Likewise, would it be OK = if the document does not specify which of the conflicting actions is to be = discarded (old, new, all) by the server, but draft-ietf-dots-signal defines how to inform clients about which action was enforced by the serve= r?

&n= bsp;

Jon>= Again, I think that this would be implementation specific.  The sugge= sted Table 2: entry above would cover this as well.  The DOTS client j= ust needs to know it has been de-selected / discarded – I don’t think the DOTS client needs to know how / why the DO= TS server chose that particular DOTS client.

 <= /p>

Cheers,=

Med

--_000_787AE7BB302AE849A7480A190F8B93300A081B18OPEXCLILMA3corp_-- From nobody Tue Nov 28 21:39:20 2017 Return-Path: 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 8A386126B7E for ; Tue, 28 Nov 2017 21:39:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.32 X-Spam-Level: X-Spam-Status: No, score=-4.32 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham 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 3RLAr8rWl2cU for ; Tue, 28 Nov 2017 21:39:15 -0800 (PST) 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 3DC601200F1 for ; Tue, 28 Nov 2017 21:39:15 -0800 (PST) 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=1511933948; 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: x-originating-ip:x-ms-publictraffictype:x-microsoft-exchange-diagnostics: x-ms-exchange-antispam-srfa-diagnostics:x-ms-office365-filtering-correlation-id: x-microsoft-antispam:x-ms-traffictypediagnostic: x-microsoft-antispam-prvs:x-exchange-antispam-report-test: x-exchange-antispam-report-cfa-test:x-forefront-prvs: x-forefront-antispam-report:received-spf:authentication-results: spamdiagnosticoutput:spamdiagnosticmetadata: Content-Type: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-Transport-CrossTenantHeadersStamped: X-OriginatorOrg:X-NAI-Spam-Flag:X-NAI-Spam-Level: X-NAI-Spam-Threshold:X-NAI-Spam-Score:X-NAI-Spam-Version; bh=5gHO9wWUlUhJesx9SLGWJ8aG48rTwPXzQ6g8qb JPwyU=; b=BRKOaIjZa3Q7tXUImmX0PsEL4os2vrNbqRVKdYiJ ct3HUUk438zUmpTtXDG3srhV2YmLtxy39SE4EzfOInMCFpQc2v LHHPKkyWiWA3qwGSEHKXMGPEQB7KPO9Hbk2Y5VxbhzLDGysqUA oMqcxx2fBlmRwenbR3J0dBvibvY1JmA= Received: from DNVEXAPP1N06.corpzone.internalzone.com (unknown [10.44.48.90]) by DNVWSMAILOUT1.mcafee.com with smtp id 6825_2463_1041ff54_3871_41e1_8596_a6831dbd6c1c; Tue, 28 Nov 2017 23:39:07 -0600 Received: from DNVEXUSR1N13.corpzone.internalzone.com (10.44.48.86) by DNVEXAPP1N06.corpzone.internalzone.com (10.44.48.90) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Tue, 28 Nov 2017 22:39:06 -0700 Received: from DNVEXUSR1N12.corpzone.internalzone.com (10.44.48.85) by DNVEXUSR1N13.corpzone.internalzone.com (10.44.48.86) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Tue, 28 Nov 2017 22:39:05 -0700 Received: from DNVO365EDGE1.corpzone.internalzone.com (10.44.176.66) by DNVEXUSR1N12.corpzone.internalzone.com (10.44.48.85) with Microsoft SMTP Server (TLS) id 15.0.1347.2 via Frontend Transport; Tue, 28 Nov 2017 22:39:05 -0700 Received: from NAM02-CY1-obe.outbound.protection.outlook.com (10.44.176.240) by edge.mcafee.com (10.44.176.66) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Tue, 28 Nov 2017 22:39:04 -0700 Received: from DM5PR16MB1788.namprd16.prod.outlook.com (10.172.44.144) by DM5PR16MB1788.namprd16.prod.outlook.com (10.172.44.144) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.260.4; Wed, 29 Nov 2017 05:39:02 +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.20.0260.007; Wed, 29 Nov 2017 05:39:02 +0000 From: "Konda, Tirumaleswar Reddy" To: "mohamed.boucadair@orange.com" , Jon Shallow , "dots@ietf.org" Thread-Topic: [Dots] signal-channel: Conflict detection and notification Thread-Index: AQI5QycoOO+6Sl3hDoQKXRH887G99aJd55JwgAAKs5CAABDPgIAAEDEAgAAM/YCAAAnqQIAACYkAgADteRA= Date: Wed, 29 Nov 2017 05:39:02 +0000 Message-ID: References: <787AE7BB302AE849A7480A190F8B93300A07F4E4@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <009b01d3683a$c6158f90$5240aeb0$@jpshallow.com> <00e201d36844$b1b39ec0$151adc40$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93300A0819DB@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <011301d36853$48efb680$dacf2380$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93300A081B18@OPEXCLILMA3.corporate.adroot.infra.ftgroup> In-Reply-To: <787AE7BB302AE849A7480A190F8B93300A081B18@OPEXCLILMA3.corporate.adroot.infra.ftgroup> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [103.245.47.20] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DM5PR16MB1788; 6:6fHZTzI6iBDUvcAY1WKb1P9I2qUtBl55nqZ2iLMEQR5Z97N0QhZZm78903s7Kf2OiQaYs8P+dhPgxyKpuFvmJGUufE30tPZ9DfnyZE624WG25pPlsCougQLudyqTLsy2bEGjmtplVAa+YpsPDh8/+otqnvN8M0QJWJRwC1ZJBD+jOfrv9oE6F8j45YQsKQmkizZV34jzAaBA9OXEN290DXJQiVHNGG8LO12jg4k5MeKrJ9FAhrsKZowPQV7dITJkalohEhvARSFivia6bcZ7jIZ59iqhOa7Zm24RfDbs/2wWpWzn+eGmOLOlHqrb6YK/QE4A3G8qv7/IAQ1RM/3dlHxHbyb1U9cpdn+UJbOyUCM=; 5:vOM8Ph/5vtRxUsgPRQcNy3wT9api3y7cU9lLKtkZz0YNubtwSbY5tWb/uu+5xe3SZ7AxjqLUYetRLbu6kHEL0ZHjSQEW6Yx/2PnXwstEbnclEjB5OoSGXlUOv8Ka/4QEoJHofGTCgDd1OEEpTqSWCPrd6SFYg6PvJYlXL56/8GA=; 24:WLH7l+lfz09ZZlWe9BOUaYS4dXP8fl4WvFYask5HXUIu9G12lWBWdLT9cj4ekSN0g3hhBcXGkHljivx38To3gfIdnUfShG6W5/3MjeLhnHI=; 7:yaQPFGR/YJtoKXb/oHszm5oAIJvkIZ18k8grG3KHJBae/28vRAkh4PbkvDHePb1q9f71w+xwgq389OpdD2XRYEHT7OmFTmLWHr+aSGLx8aHdpbqxctLoaZAh4cmZyBnwD5AbpxkgkP3g4MccBmI/U1OOVJBk/9pm17jCfAPeocS8lxQ7W0r5zaxfbwBMoihXvGYjY9z6NQh0CvgqDS1nVpZR3ojPeDAOfpX1wV1LX6m/qocKPFkhI2mIILPrijdo x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: b48ac638-7453-49d1-5ff0-08d536eb7f6d x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(5600026)(4604075)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(2017052603265); SRVR:DM5PR16MB1788; x-ms-traffictypediagnostic: DM5PR16MB1788: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(190756311086443)(158342451672863)(20558992708506)(227612066756510)(18271650672692)(21748063052155)(211171220733660)(123452027830198); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(2401047)(5005006)(8121501046)(3002001)(10201501046)(93006095)(93001095)(3231022)(6041248)(20161123564025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123562025)(20161123558100)(20161123560025)(20161123555025)(6072148)(201708071742011); SRVR:DM5PR16MB1788; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:DM5PR16MB1788; x-forefront-prvs: 05066DEDBB x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(346002)(376002)(366004)(53754006)(32952001)(199003)(189002)(51444003)(189998001)(2501003)(7110500001)(105586002)(106356001)(33656002)(2900100001)(6116002)(790700001)(3846002)(102836003)(8936002)(3280700002)(68736007)(3660700001)(10710500007)(2906002)(2420400007)(9326002)(345774005)(15650500001)(72206003)(966005)(14454004)(478600001)(53546010)(7696005)(606006)(110136005)(93886005)(316002)(25786009)(99286004)(97736004)(80792005)(8676002)(81156014)(81166006)(7736002)(74316002)(229853002)(6436002)(77096006)(55016002)(6506006)(53946003)(5660300001)(53936002)(9686003)(54896002)(6306002)(101416001)(236005)(2950100002)(6246003)(54356999)(66066001)(86362001)(19609705001)(50986999)(76176999)(85282002); DIR:OUT; SFP:1101; SCL:1; SRVR:DM5PR16MB1788; H:DM5PR16MB1788.namprd16.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: McAfee.com does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=TirumaleswarReddy_Konda@McAfee.com; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_DM5PR16MB1788C84A0B43830F1080F902EA3B0DM5PR16MB1788namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: b48ac638-7453-49d1-5ff0-08d536eb7f6d X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Nov 2017 05:39:02.4475 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4943e38c-6dd4-428c-886d-24932bc2d5de X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR16MB1788 X-OriginatorOrg: mcafee.com X-NAI-Spam-Flag: NO X-NAI-Spam-Level: X-NAI-Spam-Threshold: 15 X-NAI-Spam-Score: 0.9 X-NAI-Spam-Version: 2.3.0.9418 : core <6168> : inlines <6192> : streams <1771646> : uri <2541932> Archived-At: Subject: Re: [Dots] signal-channel: Conflict detection and notification 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Nov 2017 05:39:19 -0000 --_000_DM5PR16MB1788C84A0B43830F1080F902EA3B0DM5PR16MB1788namp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Med, In a deployment scenario with a DDoS Detector (or a on premise DDoS mitigat= ion system) acting as DOTS clients and a web server with in-built DDoS dete= ction capability. The web server may not have as much visibility into the e= xtent of the DDoS attack as the DDoS Detector (or IDMS) and there will be c= onflicting mitigation requests from different DOTS clients, discarding all = the mitigation requests from different clients will make the mechanism not = useful. -Tiru From: mohamed.boucadair@orange.com [mailto:mohamed.boucadair@orange.com] Sent: Tuesday, November 28, 2017 8:55 PM To: Konda, Tirumaleswar Reddy ; Jon Sha= llow ; dots@ietf.org Subject: RE: [Dots] signal-channel: Conflict detection and notification Tiru, Please see inline. Cheers, Med De : Dots [mailto:dots-bounces@ietf.org] De la part de Konda, Tirumaleswar = Reddy Envoy=E9 : mardi 28 novembre 2017 16:02 =C0 : Jon Shallow; BOUCADAIR Mohamed IMT/OLN; dots@ietf.org Objet : Re: [Dots] signal-channel: Conflict detection and notification Within a administrative domain, there won't be many different DOTS clients = raising conflicting mitigation requests for the same target, the conflict m= ay arise between a DDoS Detector (or a on premise DDoS mitigation system) a= cting as DOTS clients and a web server with in-built DDoS detection capabil= ity. [Med] I don't think that we can speculate about the nature of the conflicts= that may happen. Misconfigured and corrupted software instances may happen= . Under what conditions does the DOTS server return "DOTS Server has detected= conflicting mitigation requests from different DOTS clients. All conflict= ing mitigation requests are inactive." ? [Med] A dots server can be typically instructed by a policy to discard conf= licting requests. The rationale is that the provider thinks that the client= s are misconfigured and something is needed to be fixed before solicited th= e server. The signal-channel does not need to call for a favorite action wh= en conflicts; that is implementation- and deployment-specific. -Tiru From: Jon Shallow [mailto:supjps-ietf@jpshallow.com] Sent: Tuesday, November 28, 2017 7:45 PM To: mohamed.boucadair@orange.com; Kond= a, Tirumaleswar Reddy >; dots@ietf.org Subject: RE: [Dots] signal-channel: Conflict detection and notification Hi Med, In principal I accept the concept of your 7, 8 & 9 status which in effect a= re part of the mitigation state as in a state diagram. However, having iss= ued a "8" status, this then needs to transition to another state which refl= ects what is actually happening - e.g. "2". The actual state could immediately be sent following the reporting of "8" (= if Observe active), else it would need to wait until the next status GET. = It is possible that the "8" message gets lost, so relying on receiving the = "8" could be dangerous. With a "9" response what then is the DOTS client allowed to do? - A retry of the original mitigation request is likely to fail again - If all the DOTS clients back off, then there will be no mitigation - Should there be a random back-off time before retrying? What is critical is that DOTS servers in the same administrative domain attempting to honor conflicting requests may flap network route or DNS information, degrading the networks attempting to participate in attack response with the DOTS clients. Should not be allowed to happen. I also do not want to lose sight of The notification SHOULD indicate the nature and scope of the conflict, for example, the overlapping prefix range in a conflicting mitigation reque= st." This potentially can be conveyed in the 4.09 message, or could be a new mit= igation status parameter such as "additional-info" with an appropriate text= value. It could be that "status" stays with "1" through "6", and (possibl= y optional) "additional-status" has 0 | This DOTS client mitigation request is being honoured 1 | DOTS Server has detected conflicting mitigation requests from different= DOTS clients. This mitigation request is currently inactive until the con= flicts are resolved. Another mitigation request is active. 2 | DOTS Server has detected conflicting mitigation requests from different= DOTS clients. This mitigation request is currently active. 3 | DOTS Server has detected conflicting mitigation requests from different= DOTS clients. All conflicting mitigation requests are inactive. And "additional-info" reports on what the nature and scope of the conflict = is. Regards Jon From: Dots [mailto: dots-bounces@ietf.org] On= Behalf Of mohamed.boucadair@orange.com Sent: 28 November 2017 13:29 To: Jon Shallow; 'Konda, Tirumaleswar Reddy'; dots@ietf.org Subject: Re: [Dots] signal-channel: Conflict detection and notification Hi Jon, all, Thank you for sharing your thoughts on this. I tend to allow for both 4.09 code and new status values in the spec. I see that you proposed this new value: =3D=3D 7 | DOTS Server has detected conflicting mitigation requests from different= DOTS clients. This mitigation request is currently inactive until the con= flicts are resolved. Another mitigation request is active. =3D=3D Please note that a server may be instructed to adopt a more strict behavior= by deactivating all conflicting requests. Further, all DOTS clients which = issued conflicting requests should be notified, not only the one for which = a request is de-activated. As such, I'm afraid we will need more values, e.= g., =3D=3D 7 | DOTS Server has detected conflicting mitigation requests from different= DOTS clients. This mitigation request is currently inactive until the con= flicts are resolved. Another mitigation request is active. 8 | DOTS Server has detected conflicting mitigation requests from different= DOTS clients. This mitigation request is currently active. 9 | DOTS Server has detected conflicting mitigation requests from different= DOTS clients. All conflicting mitigation requests are inactive. =3D=3D For example: * If the server decides to activate only one request, then 7 will be sent t= o all clients for which the request is de-activated and 8 to the client for= which the request is maintained active. * If the server decides to deactivate all requests, then 9 will be sent to = all clients. Cheers, Med De : Jon Shallow [mailto:supjps-ietf@jpshallow.com] Envoy=E9 : mardi 28 novembre 2017 13:31 =C0 : 'Konda, Tirumaleswar Reddy'; BOUCADAIR Mohamed IMT/OLN; dots@ietf.org= Objet : RE: [Dots] signal-channel: Conflict detection and notification Hi Tiru, If Client-A has invoked a mitigation, then Client-B requests a conflicting = mitigation, if the DOTS server is only allowing the first mitigation reques= t to be the valid one, then the DOTS server could send back a 4.09 to Clien= t-B. However, if the DOTS server is allowed to choose the best mitigation reques= t, decides it is Client-B, there is no simple way of sending an unsolicited= 4.09 to client-A. Hence suggestion for an additional status message which= can be sent to Client-A stating that Client-A has been de-selected because= of a mitigation request conflict. It is also possible that a mitigation state is status 1 (parameter value - = Table 2)) and needs to transition to another state - at which point the con= flict is found - possibly by the DOTS mitigator - which then needs to be re= layed back through the DOTS server. Regards Jon From: Konda, Tirumaleswar Reddy [mailto: TirumaleswarReddy_Konda@mcafee.com= ] Sent: 28 November 2017 11:42 To: Jon Shallow; mohamed.boucadair@orange.com; dots@ietf.org Subject: RE: [Dots] signal-channel: Conflict detection and notification Hi Jon, What is the problem if the DOTS server returns 4.09 (conflict) error respon= se for the conflicting mitigation request from Client-A ? The above error code is already defined https://tools.ietf.org/html/rfc8132= . -Tiru From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Jon Shallow Sent: Tuesday, November 28, 2017 4:50 PM To: mohamed.boucadair@orange.com; dots= @ietf.org Subject: Re: [Dots] signal-channel: Conflict detection and notification Hi Med, See inline Regards Jon From: Dots [mailto: dots-bounces@ietf.org] On= Behalf Of ietf-supjps-mohamed.boucadair@orange.com Sent: 24 November 2017 14:03 To: dots@ietf.org Subject: [Dots] signal-channel: Conflict detection and notification Hi all, As discussed during the last IETF meeting, we are seeking for feedback from= the WG about how to address this requirement: =3D=3D=3D=3D=3D=3D=3D=3D=3D SIG-009 Conflict Detection and Notification: Multiple DOTS clients controlled by a single administrative entity may send conflicting mitigation requests for pools of protected resources as a result of misconfiguration, operator error, or compromised DOTS clients. DOTS servers in the same administrative domain attempting to honor conflicting requests may flap network route or DNS information, degrading the networks attempting to participate in attack response with the DOTS clients. DOTS servers in a single administrative domain SHALL detect such conflicting requests, and SHALL notify the DOTS clients in conflict. The notification SHOULD indicate the nature and scope of the conflict, for example, the overlapping prefix range in a conflicting mitigation request. =3D=3D=3D=3D=3D=3D=3D=3D For example, would it be OK if we leave implementation-specific the criteri= a upon which a dots server relies to consider two requests from two clients= as conflicting, but draft-ietf-dots-signal defines only the procedure to n= otify clients when a conflict is detected? Jon> I agree that how this is done is implementation specific. However the= re is a scenario where Client-A initiates a mitigation requests which is ac= ted upon, Client-B does a conflicting mitigation request but the DOTS Serve= r decides that Client-B is the "more" valid mitigation request and effectiv= ely de-activates Client-A's request. Table 2: draft-ietf-dots-signal-chann= el-09 therefore needs an additional status parameter to indicate to client-= A there is a conflict and hence Client-A is being stood down while another = client is controlling the mitigation. A suggestion would be 7 | DOTS Server has detected conflicting mitigation requests from different= DOTS clients. This mitigation request is currently inactive until the con= flicts are resolved. Another mitigation request is active. Jon> The DOTS client can then elect to leave in the mitigation request (and= even refresh the PUT to refresh the timeout) or delete it. Jon> I do not think it appropriate that an error message be sent back (e.g.= 4.xx) if the DOTS server immediately decides there is a conflicting reques= t and closes down the new PUT request unless we come up with a specific err= or code so the DOTS client can understand why the request is getting errore= d. Likewise, would it be OK if the document does not specify which of the conf= licting actions is to be discarded (old, new, all) by the server, but draft= -ietf-dots-signal defines how to inform clients about which action was enfo= rced by the server? Jon> Again, I think that this would be implementation specific. The sugges= ted Table 2: entry above would cover this as well. The DOTS client just ne= eds to know it has been de-selected / discarded - I don't think the DOTS cl= ient needs to know how / why the DOTS server chose that particular DOTS cli= ent. Cheers, Med --_000_DM5PR16MB1788C84A0B43830F1080F902EA3B0DM5PR16MB1788namp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Med,

&nbs= p;

In a depl= oyment scenario with a DDoS Detector (or a on = premise DDoS mitigation system) acting as DOTS clients and a web server wit= h in-built DDoS detection capability. The web server may not have as much v= isibility into the extent of the DDoS attack as the DDoS Detector (or IDMS) and there will be conflicting mitiga= tion requests from different DOTS clients, discarding all the mitigation re= quests from different clients will make the mechanism not useful.

&nbs= p;

-Tiru

 

From:<= /span> mohamed.boucadair@ora= nge.com [mailto:mohamed.boucadair@orange.com]
Sent: Tuesday, November 28, 2017 8:55 PM
To: Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@McAfee.com= >; Jon Shallow <supjps-ietf@jpshallow.com>; dots@ietf.org
Subject: RE: [Dots] signal-channel: Conflict detection and notificat= ion

 

Tiru,

 

Please see inline.

 

Cheers,

Med

 

De : Dots [mailto:dots-bounces@ietf.org] De la part de Konda, Tirumaleswar Reddy
Envoy=E9 : mardi 28 novembre 2017 16:02
=C0 : Jon Shallow; BOUCADAIR Mohamed IMT/OLN; dots@ietf.org
Objet : Re: [Dots] signal-channel: Conflict detection and notif= ication

 

Within a = administrative domain, there won’t be many different DOTS clients rai= sing conflicting mitigation requests for the same target, the conflict may = arise between a DDoS Detector (or a on premise DDoS mitigation system) acting as DOTS clients and a web server with in-bu= ilt DDoS detection capability. 

[Med] I don’t= think that we can speculate about the nature of the conflicts that may hap= pen. Misconfigured and corrupted software instances may happen.

&nbs= p;

Under wha= t conditions does the DOTS server return “DOTS Server has detected co= nflicting mitigation requests from different DOTS clients.  All confli= cting mitigation requests are inactive.” ?

[Med] A dots server= can be typically instructed by a policy to discard conflicting requests. T= he rationale is that the provider thinks that the clients are misconfigured and something is needed to be fixed before s= olicited the server. The signal-channel does not need to call for a favorit= e action when conflicts; that is implementation- and deployment-specific. &= nbsp;

&nbs= p;

-Tiru

&nbs= p;

From:<= /span> Jon Shallow [mailto:supjps-ietf@jpshallow.com]
Sent: Tuesday, November 28, 2017 7:45 PM
To: mohamed.boucadai= r@orange.com; Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@McAfee.com>; dots@ietf.org
Subject: RE: [Dots] signal-channel: Conflict detection and notificat= ion

 

Hi Med,=

&n= bsp;

In prin= cipal I accept the concept of your 7, 8 & 9 status which in effect are = part of the mitigation state as in a state diagram.  However, having i= ssued a “8” status, this then needs to transition to another state which reflects what is actually happening – e.g. &#= 8220;2”.

&n= bsp;

The act= ual state could immediately be sent following the reporting of “8R= 21; (if Observe active), else it would need to wait until the next status G= ET.  It is possible that the “8” message gets lost, so relying on receiving the “8” could be dangerous.=

&n= bsp;

With a = “9” response what then is the DOTS client allowed to do?

- A ret= ry of the original mitigation request is likely to fail again

- If al= l the DOTS clients back off, then there will be no mitigation

- Shoul= d there be a random back-off time before retrying?

&n= bsp;

What is= critical is that

      DOT= S servers in the same administrative domain attempting to honor<= /span>

      con= flicting requests may flap network route or DNS information,

      deg= rading the networks attempting to participate in attack

      res= ponse with the DOTS clients.

Should not b= e allowed to happen.

&n= bsp;

I also = do not want to lose sight of

The not= ification SHOULD indicate the nature and scope of the conflict,<= /span>

for exa= mple, the overlapping prefix range in a conflicting mitigation request.R= 21;

This po= tentially can be conveyed in the 4.09 message, or could be a new mitigation= status parameter such as "additional-info" with an appropriate t= ext value.  It could be that “status” stays with “1” through “6”, and (possibly optional) “ad= ditional-status” has

0 | Thi= s DOTS client mitigation request is being honoured

1 | DOTS Server has de= tected conflicting mitigation requests from different DOTS clients.  T= his mitigation request is currently inactive until the conflicts are resolv= ed. Another mitigation request is active.

2 | DOTS Server has de= tected conflicting mitigation requests from different DOTS clients.  T= his mitigation request is currently active.

3 | DOTS Server has de= tected conflicting mitigation requests from different DOTS clients.  A= ll conflicting mitigation requests are inactive.

And = 220;additional-info” reports on what the nature and scope of the conf= lict is.

&n= bsp;

Regards=

&n= bsp;

Jon

&n= bsp;

From: Dots [mailto: dots-bounces@ietf.org] On B= ehalf Of mohamed.boucadair@orang= e.com
Sent: 28 November 2017 13:29
To: Jon Shallow; 'Konda, Tirumaleswar Reddy'; dots@ietf.org
Subject: Re: [Dots] signal-channel: Conflict detection and notificat= ion

 

Hi Jon, all,

 

Thank you for sharing your thoughts on this.

 

I tend to allow for both 4.09 code and new sta= tus values in the spec.

 

I see that you proposed this new value:

=3D=3D

7 | DOTS Server has de= tected conflicting mitigation requests from different DOTS clients.  T= his mitigation request is currently inactive until the conflicts are resolv= ed. Another mitigation request is active.

=3D=3D

 

Please note that a server may be instructed to= adopt a more strict behavior by deactivating all conflicting requests. Fur= ther, all DOTS clients which issued conflicting requests should be notified, not only the one for which a request is de-ac= tivated. As such, I’m afraid we will need more values, e.g.,

 

=3D=3D

7 | DOTS Server has de= tected conflicting mitigation requests from different DOTS clients.  T= his mitigation request is currently inactive until the conflicts are resolv= ed. Another mitigation request is active.

8 | DOTS Server has de= tected conflicting mitigation requests from different DOTS clients.  T= his mitigation request is currently active.

9 | DOTS Server has de= tected conflicting mitigation requests from different DOTS clients.  A= ll conflicting mitigation requests are inactive.

=3D=3D

 

For example:

* If the server decides to activate only one r= equest, then 7 will be sent to all clients for which the request is de-acti= vated and 8 to the client for which the request is maintained active.

* If the server decides to deactivate all requ= ests, then 9 will be sent to all clients.  

 

Cheers,

Med

 

De : Jon Shallow [mailto:supjps-ietf@jpshallow.com]
Envoy=E9 : mardi 28 novembre 2017 13:31
=C0 : 'Konda, Tirumaleswar Reddy'; BOUCADAIR Mohamed IMT/OLN; dots@ietf.org
Objet : RE: [Dots] signal-channel: Conflict detection and notif= ication

 

Hi Tiru= ,

&n= bsp;

If Clie= nt-A has invoked a mitigation, then Client-B requests a conflicting mitigat= ion, if the DOTS server is only allowing the first mitigation request to be= the valid one, then the DOTS server could send back a 4.09 to Client-B.

&n= bsp;

However= , if the DOTS server is allowed to choose the best mitigation request, deci= des it is Client-B, there is no simple way of sending an unsolicited 4.09 t= o client-A.  Hence suggestion for an additional status message which can be sent to Client-A stating that Client-A has bee= n de-selected because of a mitigation request conflict.

&n= bsp;

It is a= lso possible that a mitigation state is status 1 (parameter value – T= able 2)) and needs to transition to another state – at which point th= e conflict is found - possibly by the DOTS mitigator - which then needs to be relayed back through the DOTS server.<= /span>

&n= bsp;

Regards=

&n= bsp;

Jon

&n= bsp;

From: Konda, Tirumaleswar Reddy [mailto: TirumaleswarReddy_Kon= da@mcafee.com]
Sent: 28 November 2017 11:42
To: Jon Shallow; moh= amed.boucadair@orange.com; dots@ietf.org
Subject: RE: [Dots] signal-channel: Conflict detection and notificat= ion

 

Hi Jon,

&nbs= p;

What is t= he problem if the DOTS server returns 4.09 (conflict) error response for th= e conflicting mitigation request from Client-A ?

The above= error code is already defined https://tools.ie= tf.org/html/rfc8132.

&nbs= p;

-Tiru

&nbs= p;

From:<= /span> Dots [mailto:dots-bounces@ietf.org] On Behalf Of Jon Shallow
Sent: Tuesday, November 28, 2017 4:50 PM
To: mohamed.boucadai= r@orange.com; dots@ietf.org
Subject: Re: [Dots] signal-channel: Conflict detection and notificat= ion

 

Hi Med,=

&n= bsp;

See inl= ine

&n= bsp;

Regards=

&n= bsp;

Jon

&n= bsp;

From: Dots [mailto: dots-bounces@ietf.org] On B= ehalf Of ietf-supjps= -mohamed.boucadair@orange.com
Sent: 24 November 2017 14:03
To: dots@ietf.org
Subject: [Dots] signal-channel: Conflict detection and notification<= o:p>

 

Hi all,

 

As discussed during the last IETF meeting, we are seeking = for feedback from the WG about how to address this requirement:<= /span>

 

=3D=3D=3D=3D=3D=3D=3D=3D=3D

   SIG-009  Conflic= t Detection and Notification: Multiple DOTS clients

      con= trolled by a single administrative entity may send conflicting

      mit= igation requests for pools of protected resources as a result

      of = misconfiguration, operator error, or compromised DOTS clients.

      DOT= S servers in the same administrative domain attempting to honor<= /span>

      con= flicting requests may flap network route or DNS information,

      deg= rading the networks attempting to participate in attack

      res= ponse with the DOTS clients.  DOTS servers in a single

      adm= inistrative domain SHALL detect such conflicting requests, and

      SHA= LL notify the DOTS clients in conflict.  The notification

      SHO= ULD indicate the nature and scope of the conflict, for example,<= /span>

      the= overlapping prefix range in a conflicting mitigation request.

=3D=3D=3D=3D=3D=3D=3D=3D

 

For example, would it be OK if we leave implementation-spe= cific the criteria upon which a dots server relies to consider two requests= from two clients as conflicting, but draft-ietf-dots-signal defines only the procedure to notify clients when a conflict is detected? =

Jon> I agree that h= ow this is done is implementation specific.  However there is a scenar= io where Client-A initiates a mitigation requests which is acted upon, Clie= nt-B does a conflicting mitigation request but the DOTS Server decides that Client-B is the “more” valid miti= gation request and effectively de-activates Client-A’s request. = Table 2: draft-ietf-dots-signal-channel-09 therefore needs an additional s= tatus parameter to indicate to client-A there is a conflict and hence Client-A is being stood down while another client is controlling= the mitigation.  A suggestion would be

 

7 | DOTS Server has de= tected conflicting mitigation requests from different DOTS clients.  T= his mitigation request is currently inactive until the conflicts are resolv= ed. Another mitigation request is active.

 

Jon> The DOTS clien= t can then elect to leave in the mitigation request (and even refresh the P= UT to refresh the timeout) or delete it.

Jon> I do not think= it appropriate that an error message be sent back (e.g. 4.xx) if the DOTS = server immediately decides there is a conflicting request and closes down t= he new PUT request unless we come up with a specific error code so the DOTS client can understand why the request is= getting errored.

 

 

Likewise, would it be OK if the document does not specify = which of the conflicting actions is to be discarded (old, new, all) by the = server, but draft-ietf-dots-signal defines how to inform clients about which action was enforced by the server?

 

Jon> Again, I think= that this would be implementation specific.  The suggested Table 2: e= ntry above would cover this as well.  The DOTS client just needs to kn= ow it has been de-selected / discarded – I don’t think the DOTS client needs to know how / why the DOTS server chose that p= articular DOTS client.

 

Cheers,

Med

--_000_DM5PR16MB1788C84A0B43830F1080F902EA3B0DM5PR16MB1788namp_-- From nobody Tue Nov 28 22:20:49 2017 Return-Path: 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 01124126DD9 for ; Tue, 28 Nov 2017 22:20:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7 X-Spam-Level: X-Spam-Status: No, score=-7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham 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 1Hc6kOgoQoDh for ; Tue, 28 Nov 2017 22:20:46 -0800 (PST) Received: from MIVWSMAILOUT1.mcafee.com (mivwsmailout1.mcafee.com [161.69.47.167]) (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 5A026126B7E for ; Tue, 28 Nov 2017 22:20:46 -0800 (PST) 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=1511936445; 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: authentication-results:x-originating-ip:x-ms-publictraffictype: x-microsoft-exchange-diagnostics:x-ms-exchange-antispam-srfa-diagnostics: x-ms-office365-filtering-correlation-id:x-microsoft-antispam: x-ms-traffictypediagnostic:x-microsoft-antispam-prvs: x-exchange-antispam-report-test:x-exchange-antispam-report-cfa-test: x-forefront-prvs:x-forefront-antispam-report: received-spf:spamdiagnosticoutput:spamdiagnosticmetadata: Content-Type: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-Transport-CrossTenantHeadersStamped: X-OriginatorOrg:X-NAI-Spam-Flag:X-NAI-Spam-Level: X-NAI-Spam-Threshold:X-NAI-Spam-Score:X-NAI-Spam-Version; bh=UlYe2VIbIwwSIjymZ4nQrf9ltBtw0luBjswPnu kW7fc=; b=dqgcaEjJKZAXzhK0XCBuAYO1BHpRwAJrcWI2SzsI SKlS7H6IA/9r7FgZFaR/7aHKpl3HkAaBAqHSuzOqHu5vD6hZg5 FExQwhX5jokcyVDPnNsGWp4ZWWceyVg8TvBujCb2vA7m9vnaZB t/4b9o5JLVZABg5UoICtGo98sfYwmOA= Received: from MIVEXAPP1N03.corpzone.internalzone.com (unknown [10.48.48.90]) by MIVWSMAILOUT1.mcafee.com with smtp id 592d_1640_83e06053_fe60_4766_a60d_8b582b2863e7; Wed, 29 Nov 2017 00:20:44 -0600 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.1347.2; Wed, 29 Nov 2017 01:20:43 -0500 Received: from MIVEXAPP1N02.corpzone.internalzone.com (10.48.48.89) by MIVEXUSR1N07.corpzone.internalzone.com (10.48.48.87) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Wed, 29 Nov 2017 01:20:42 -0500 Received: from MIVO365EDGE4.corpzone.internalzone.com (10.48.176.87) by MIVEXAPP1N02.corpzone.internalzone.com (10.48.48.89) with Microsoft SMTP Server (TLS) id 15.0.1347.2 via Frontend Transport; Wed, 29 Nov 2017 01:20:42 -0500 Received: from NAM01-BY2-obe.outbound.protection.outlook.com (10.48.176.240) by edge.mcafee.com (10.48.176.87) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Wed, 29 Nov 2017 01:20:41 -0500 Received: from DM5PR16MB1788.namprd16.prod.outlook.com (10.172.44.144) by DM5PR16MB1785.namprd16.prod.outlook.com (10.172.44.141) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.260.4; Wed, 29 Nov 2017 06:20:41 +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.20.0260.007; Wed, 29 Nov 2017 06:20:41 +0000 From: "Konda, Tirumaleswar Reddy" To: Jon Shallow , "dots@ietf.org" Thread-Topic: [Dots] signal-mitigate and alias parameters Thread-Index: AdNoXB5u3ro545K8R1evbMe9O8X0GAAffk4Q Date: Wed, 29 Nov 2017 06:20:40 +0000 Message-ID: References: <014101d3685c$26539c50$72fad4f0$@jpshallow.com> In-Reply-To: <014101d3685c$26539c50$72fad4f0$@jpshallow.com> 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: [103.245.47.20] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DM5PR16MB1785; 6:m+jq/bpjZqx+DQcJfc9MUWJPjsXVsWZJoFsVacvsp7vKnBTzLrviRDbH1V/tO5BLm21CT0ezfN4CSgIQN9VFddrC1s1uW0l/jSwShPyaVDc/DDWiVd+8kH/qyY17drB53wFggNMJhgOwnA8vvKuk1PzCM+dd3PXXLn39zoahmxfMS2o4tG3WevJZC1O5WZg0vCcKITPn5L47N15qX5m9BYQ3dyNHvP7AGSHB+V8n9K7Z4+6y6+3MSnDv6bZ13iKuBjoGD/J7M6FCequ1uf8Z+zQcss97zrgrRx6uMG9fan42WmFwFcWz05fRE8HOZwUTVKSb0LISeMBC7EIKXxz/rvuhRsVpFhr5GZinC91AQWg=; 5:kmSgn3LSK+oi0M5EpNBVF0aR3zJnaRm/FeJ6jC3sd7897qfwM78D0jZJ1c1S/lWrrRcn1Nucr/DDevZ77mjTAJ5PFt3HpvvFirdxa8RWf6k6lSDbNJgaAkKe1v3jQYbIbozBmTJxJpUvezbJTxp/j8cajzCb278MLpxHQv9M/dg=; 24:WrI4wjzoYvONIS21kXuqN0ucpXznFwovgzYceuYJm9Ap8lkSeer997U9SLjZLsIFE0lhaHjbb4Pi8DGKn0/nC+jOCBTeoqGeMeuCQetrtSA=; 7:s5SmdxD5tkRHnB8cGXZqbKmXSfmAfvEX06kGLqG6xffR0T9mFa5uDbn5yNVpote8muz0Q5vf6L31mbv3dKx5WJe80YQ9/IzOs2ehcfLg2pFVGFIckGWqsHVISAt0ODqR5s8S6fGOdxrl6xWqKpotiDuHrzpzO3vb31nS/+t6jmoWQiaLiUFAm5ioKG/s46xcHEao+Mg3uv3PbKuggLI+zUJ8HPMdgK6X+noUypZJEw+GGnAI2oeyFNeav7ztCpwu x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: b4a62500-e3c2-4ada-873b-08d536f150a6 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(5600026)(4604075)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(2017052603199); SRVR:DM5PR16MB1785; x-ms-traffictypediagnostic: DM5PR16MB1785: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(227612066756510)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(2401047)(8121501046)(5005006)(3002001)(10201501046)(93006095)(93001095)(3231022)(6041248)(20161123560025)(20161123562025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123555025)(20161123558100)(20161123564025)(6072148)(201708071742011); SRVR:DM5PR16MB1785; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:DM5PR16MB1785; x-forefront-prvs: 05066DEDBB x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(366004)(376002)(346002)(39860400002)(189002)(199003)(32952001)(68736007)(5660300001)(101416001)(8676002)(54896002)(6246003)(6306002)(9686003)(6116002)(81166006)(81156014)(3846002)(50986999)(54356999)(76176999)(102836003)(66066001)(2950100002)(790700001)(53936002)(53546010)(2900100001)(19609705001)(33656002)(55016002)(2906002)(99286004)(106356001)(3660700001)(74316002)(316002)(2501003)(3280700002)(72206003)(86362001)(110136005)(229853002)(14454004)(77096006)(25786009)(189998001)(6436002)(478600001)(105586002)(6506006)(7736002)(80792005)(97736004)(8936002)(7696005)(85282002); DIR:OUT; SFP:1101; SCL:1; SRVR:DM5PR16MB1785; H:DM5PR16MB1788.namprd16.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; 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_DM5PR16MB17881C69E383F10C978109EEEA3B0DM5PR16MB1788namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: b4a62500-e3c2-4ada-873b-08d536f150a6 X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Nov 2017 06:20:40.8590 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4943e38c-6dd4-428c-886d-24932bc2d5de X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR16MB1785 X-OriginatorOrg: mcafee.com X-NAI-Spam-Flag: NO X-NAI-Spam-Level: X-NAI-Spam-Threshold: 15 X-NAI-Spam-Score: 0.1 X-NAI-Spam-Version: 2.3.0.9418 : core <6168> : inlines <6192> : streams <1771648> : uri <2541947> Archived-At: Subject: Re: [Dots] signal-mitigate and alias parameters 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Nov 2017 06:20:48 -0000 --_000_DM5PR16MB17881C69E383F10C978109EEEA3B0DM5PR16MB1788namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Yes, fixed; updated drafts are uploaded to github. -Tiru From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Jon Shallow Sent: Tuesday, November 28, 2017 8:49 PM To: dots@ietf.org Subject: [Dots] signal-mitigate and alias parameters I know that this is trivial, but uri and fqdn parameters are not prefixed w= ith target- as in module: ietf-dots-signal +--rw mitigation-scope +--rw client-identifier* binary +--rw scope* [mitigation-id] +--rw mitigation-id int32 +--rw target-ip* inet:ip-address +--rw target-prefix* inet:ip-prefix +--rw target-port-range* [lower-port upper-port] | +--rw lower-port inet:port-number | +--rw upper-port inet:port-number +--rw target-protocol* uint8 +--rw fqdn* inet:domain-name +--rw uri* inet:uri +--rw alias-name* string +--rw lifetime? int32 And module: ietf-dots-data-channel-identifier +--rw identifier +--rw client-identifier* binary +--rw alias* [alias-name] +--rw alias-name string +--rw target-ip* inet:ip-address +--rw target-prefix* inet:ip-prefix +--rw target-port-range* [lower-port upper-port] | +--rw lower-port inet:port-number | +--rw upper-port inet:port-number +--rw target-protocol* uint8 +--rw fqdn* inet:domain-name +--rw uri* inet:uri Does it not make sense to add in the target- for fqdn and uri for consiste= ncy ? - and update the CBOR mapping! Regards Jon --_000_DM5PR16MB17881C69E383F10C978109EEEA3B0DM5PR16MB1788namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Yes, fixe= d; updated drafts are uploaded to github.

&nbs= p;

-Tiru

 

From:<= /span> Dots [mailto:dots-bou= nces@ietf.org] On Behalf Of Jon Shallow
Sent: Tuesday, November 28, 2017 8:49 PM
To: dots@ietf.org
Subject: [Dots] signal-mitigate and alias parameters

 

I know that this is trivial, bu= t uri and fqdn parameters are not prefixed with target- as in

 

   module: ietf-dots-= signal

     &= nbsp; +--rw mitigation-scope

     &= nbsp;    +--rw client-identifier*   binary

     &= nbsp;    +--rw scope* [mitigation-id]<= /p>

     &= nbsp;       +--rw mitigation-id &nbs= p;      int32

     &= nbsp;       +--rw target-ip*  &= nbsp;        inet:ip-address<= /span>

     &= nbsp;       +--rw target-prefix* &nb= sp;     inet:ip-prefix

     &= nbsp;       +--rw target-port-range* [low= er-port upper-port]

     &= nbsp;       |  +--rw lower-port = ;   inet:port-number

     &= nbsp;       |  +--rw upper-port = ;   inet:port-number

     &= nbsp;       +--rw target-protocol* &= nbsp;   uint8

     &= nbsp;       +--rw fqdn*   =              in= et:domain-name

     &= nbsp;       +--rw uri*   &= nbsp;           &nbs= p; inet:uri

     &= nbsp;       +--rw alias-name*  =         string

     &= nbsp;       +--rw lifetime?  &n= bsp;         int32

 

And

 

   module: ietf-dots-= data-channel-identifier

     &= nbsp; +--rw identifier

     &= nbsp;    +--rw client-identifier*   binary

     &= nbsp;    +--rw alias* [alias-name]

     &= nbsp;       +--rw alias-name  &= nbsp;        string

     &= nbsp;       +--rw target-ip*  &= nbsp;        inet:ip-address<= /span>

     &= nbsp;       +--rw target-prefix* &nb= sp;     inet:ip-prefix

     &= nbsp;       +--rw target-port-range* [low= er-port upper-port]

     &= nbsp;       |  +--rw lower-port = ;   inet:port-number

     &= nbsp;       |  +--rw upper-port = ;   inet:port-number

     &= nbsp;       +--rw target-protocol* &= nbsp;   uint8

     &= nbsp;       +--rw fqdn*   =              in= et:domain-name

     &= nbsp;       +--rw uri*   &= nbsp;           &nbs= p; inet:uri

 

Does it not make sense to add i= n the target-  for fqdn and uri for consistency ?

- and update the CBOR mapping!<= o:p>

 

Regards

 

Jon

--_000_DM5PR16MB17881C69E383F10C978109EEEA3B0DM5PR16MB1788namp_-- From nobody Tue Nov 28 22:32:27 2017 Return-Path: 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 354E5126B7E for ; Tue, 28 Nov 2017 22:32:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.618 X-Spam-Level: X-Spam-Status: No, score=-2.618 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no 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 IG4-rLyVOjeX for ; Tue, 28 Nov 2017 22:32:22 -0800 (PST) Received: from orange.com (mta241.mail.business.static.orange.com [80.12.66.41]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 32D8C124C27 for ; Tue, 28 Nov 2017 22:32:22 -0800 (PST) Received: from opfedar06.francetelecom.fr (unknown [xx.xx.xx.8]) by opfedar25.francetelecom.fr (ESMTP service) with ESMTP id 68D32120C15; Wed, 29 Nov 2017 07:32:20 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.17]) by opfedar06.francetelecom.fr (ESMTP service) with ESMTP id 4034E80066; Wed, 29 Nov 2017 07:32:20 +0100 (CET) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM24.corporate.adroot.infra.ftgroup ([fe80::a1e6:3e6a:1f68:5f7e%18]) with mapi id 14.03.0361.001; Wed, 29 Nov 2017 07:32:19 +0100 From: To: "Konda, Tirumaleswar Reddy" , "Jon Shallow" , "dots@ietf.org" Thread-Topic: [Dots] signal-channel: Conflict detection and notification Thread-Index: AdNlLOxuTejE5Yr+TiWtd6n7pT4m0aJd55JwgAAKs5CAABDPgIAAEDEAgAAM/YCAAAnqQIAACYkAgADteRCiV8cf4A== Date: Wed, 29 Nov 2017 06:32:19 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93300A08307A@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <787AE7BB302AE849A7480A190F8B93300A07F4E4@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <009b01d3683a$c6158f90$5240aeb0$@jpshallow.com> <00e201d36844$b1b39ec0$151adc40$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93300A0819DB@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <011301d36853$48efb680$dacf2380$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93300A081B18@OPEXCLILMA3.corporate.adroot.infra.ftgroup> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.4] Content-Type: multipart/alternative; boundary="_000_787AE7BB302AE849A7480A190F8B93300A08307AOPEXCLILMA3corp_" MIME-Version: 1.0 Archived-At: Subject: Re: [Dots] signal-channel: Conflict detection and notification 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Nov 2017 06:32:25 -0000 --_000_787AE7BB302AE849A7480A190F8B93300A08307AOPEXCLILMA3corp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Tiru, I agree with you that discarding all conflicting requests may not be helpfu= l in some cases. In the same way that someone can argue that selecting only= one request among conflicting ones may not be useful because the server pi= cked the wrong one. I do prefer to leave this to implementation/deployment as a policy to be su= pplied. That policy will instruct the dots server about the behavior to fol= low based one specific information that is available for a given deployment= : =B7 Pick one and deactivate all the others based on some criteria =B7 Activate all of them =B7 De-activate all of them Cheers, Med De : Dots [mailto:dots-bounces@ietf.org] De la part de Konda, Tirumaleswar = Reddy Envoy=E9 : mercredi 29 novembre 2017 06:39 =C0 : BOUCADAIR Mohamed IMT/OLN; Jon Shallow; dots@ietf.org Objet : Re: [Dots] signal-channel: Conflict detection and notification Hi Med, In a deployment scenario with a DDoS Detector (or a on premise DDoS mitigat= ion system) acting as DOTS clients and a web server with in-built DDoS dete= ction capability. The web server may not have as much visibility into the e= xtent of the DDoS attack as the DDoS Detector (or IDMS) and there will be c= onflicting mitigation requests from different DOTS clients, discarding all = the mitigation requests from different clients will make the mechanism not = useful. -Tiru From: mohamed.boucadair@orange.com [ma= ilto:mohamed.boucadair@orange.com] Sent: Tuesday, November 28, 2017 8:55 PM To: Konda, Tirumaleswar Reddy >; Jon Shallow >; dots@ietf.org Subject: RE: [Dots] signal-channel: Conflict detection and notification Tiru, Please see inline. Cheers, Med De : Dots [mailto:dots-bounces@ietf.org] De la part de Konda, Tirumaleswar = Reddy Envoy=E9 : mardi 28 novembre 2017 16:02 =C0 : Jon Shallow; BOUCADAIR Mohamed IMT/OLN; dots@ietf.org Objet : Re: [Dots] signal-channel: Conflict detection and notification Within a administrative domain, there won't be many different DOTS clients = raising conflicting mitigation requests for the same target, the conflict m= ay arise between a DDoS Detector (or a on premise DDoS mitigation system) a= cting as DOTS clients and a web server with in-built DDoS detection capabil= ity. [Med] I don't think that we can speculate about the nature of the conflicts= that may happen. Misconfigured and corrupted software instances may happen= . Under what conditions does the DOTS server return "DOTS Server has detected= conflicting mitigation requests from different DOTS clients. All conflict= ing mitigation requests are inactive." ? [Med] A dots server can be typically instructed by a policy to discard conf= licting requests. The rationale is that the provider thinks that the client= s are misconfigured and something is needed to be fixed before solicited th= e server. The signal-channel does not need to call for a favorite action wh= en conflicts; that is implementation- and deployment-specific. -Tiru From: Jon Shallow [mailto:supjps-ietf@jpshallow.com] Sent: Tuesday, November 28, 2017 7:45 PM To: mohamed.boucadair@orange.com; Kond= a, Tirumaleswar Reddy >; dots@ietf.org Subject: RE: [Dots] signal-channel: Conflict detection and notification Hi Med, In principal I accept the concept of your 7, 8 & 9 status which in effect a= re part of the mitigation state as in a state diagram. However, having iss= ued a "8" status, this then needs to transition to another state which refl= ects what is actually happening - e.g. "2". The actual state could immediately be sent following the reporting of "8" (= if Observe active), else it would need to wait until the next status GET. = It is possible that the "8" message gets lost, so relying on receiving the = "8" could be dangerous. With a "9" response what then is the DOTS client allowed to do? - A retry of the original mitigation request is likely to fail again - If all the DOTS clients back off, then there will be no mitigation - Should there be a random back-off time before retrying? What is critical is that DOTS servers in the same administrative domain attempting to honor conflicting requests may flap network route or DNS information, degrading the networks attempting to participate in attack response with the DOTS clients. Should not be allowed to happen. I also do not want to lose sight of The notification SHOULD indicate the nature and scope of the conflict, for example, the overlapping prefix range in a conflicting mitigation reque= st." This potentially can be conveyed in the 4.09 message, or could be a new mit= igation status parameter such as "additional-info" with an appropriate text= value. It could be that "status" stays with "1" through "6", and (possibl= y optional) "additional-status" has 0 | This DOTS client mitigation request is being honoured 1 | DOTS Server has detected conflicting mitigation requests from different= DOTS clients. This mitigation request is currently inactive until the con= flicts are resolved. Another mitigation request is active. 2 | DOTS Server has detected conflicting mitigation requests from different= DOTS clients. This mitigation request is currently active. 3 | DOTS Server has detected conflicting mitigation requests from different= DOTS clients. All conflicting mitigation requests are inactive. And "additional-info" reports on what the nature and scope of the conflict = is. Regards Jon From: Dots [mailto: dots-bounces@ietf.org] On= Behalf Of mohamed.boucadair@orange.com Sent: 28 November 2017 13:29 To: Jon Shallow; 'Konda, Tirumaleswar Reddy'; dots@ietf.org Subject: Re: [Dots] signal-channel: Conflict detection and notification Hi Jon, all, Thank you for sharing your thoughts on this. I tend to allow for both 4.09 code and new status values in the spec. I see that you proposed this new value: =3D=3D 7 | DOTS Server has detected conflicting mitigation requests from different= DOTS clients. This mitigation request is currently inactive until the con= flicts are resolved. Another mitigation request is active. =3D=3D Please note that a server may be instructed to adopt a more strict behavior= by deactivating all conflicting requests. Further, all DOTS clients which = issued conflicting requests should be notified, not only the one for which = a request is de-activated. As such, I'm afraid we will need more values, e.= g., =3D=3D 7 | DOTS Server has detected conflicting mitigation requests from different= DOTS clients. This mitigation request is currently inactive until the con= flicts are resolved. Another mitigation request is active. 8 | DOTS Server has detected conflicting mitigation requests from different= DOTS clients. This mitigation request is currently active. 9 | DOTS Server has detected conflicting mitigation requests from different= DOTS clients. All conflicting mitigation requests are inactive. =3D=3D For example: * If the server decides to activate only one request, then 7 will be sent t= o all clients for which the request is de-activated and 8 to the client for= which the request is maintained active. * If the server decides to deactivate all requests, then 9 will be sent to = all clients. Cheers, Med De : Jon Shallow [mailto:supjps-ietf@jpshallow.com] Envoy=E9 : mardi 28 novembre 2017 13:31 =C0 : 'Konda, Tirumaleswar Reddy'; BOUCADAIR Mohamed IMT/OLN; dots@ietf.org= Objet : RE: [Dots] signal-channel: Conflict detection and notification Hi Tiru, If Client-A has invoked a mitigation, then Client-B requests a conflicting = mitigation, if the DOTS server is only allowing the first mitigation reques= t to be the valid one, then the DOTS server could send back a 4.09 to Clien= t-B. However, if the DOTS server is allowed to choose the best mitigation reques= t, decides it is Client-B, there is no simple way of sending an unsolicited= 4.09 to client-A. Hence suggestion for an additional status message which= can be sent to Client-A stating that Client-A has been de-selected because= of a mitigation request conflict. It is also possible that a mitigation state is status 1 (parameter value - = Table 2)) and needs to transition to another state - at which point the con= flict is found - possibly by the DOTS mitigator - which then needs to be re= layed back through the DOTS server. Regards Jon From: Konda, Tirumaleswar Reddy [mailto: TirumaleswarReddy_Konda@mcafee.com= ] Sent: 28 November 2017 11:42 To: Jon Shallow; mohamed.boucadair@orange.com; dots@ietf.org Subject: RE: [Dots] signal-channel: Conflict detection and notification Hi Jon, What is the problem if the DOTS server returns 4.09 (conflict) error respon= se for the conflicting mitigation request from Client-A ? The above error code is already defined https://tools.ietf.org/html/rfc8132= . -Tiru From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Jon Shallow Sent: Tuesday, November 28, 2017 4:50 PM To: mohamed.boucadair@orange.com; dots= @ietf.org Subject: Re: [Dots] signal-channel: Conflict detection and notification Hi Med, See inline Regards Jon From: Dots [mailto: dots-bounces@ietf.org] On= Behalf Of ietf-supjps-mohamed.boucadair@orange.com Sent: 24 November 2017 14:03 To: dots@ietf.org Subject: [Dots] signal-channel: Conflict detection and notification Hi all, As discussed during the last IETF meeting, we are seeking for feedback from= the WG about how to address this requirement: =3D=3D=3D=3D=3D=3D=3D=3D=3D SIG-009 Conflict Detection and Notification: Multiple DOTS clients controlled by a single administrative entity may send conflicting mitigation requests for pools of protected resources as a result of misconfiguration, operator error, or compromised DOTS clients. DOTS servers in the same administrative domain attempting to honor conflicting requests may flap network route or DNS information, degrading the networks attempting to participate in attack response with the DOTS clients. DOTS servers in a single administrative domain SHALL detect such conflicting requests, and SHALL notify the DOTS clients in conflict. The notification SHOULD indicate the nature and scope of the conflict, for example, the overlapping prefix range in a conflicting mitigation request. =3D=3D=3D=3D=3D=3D=3D=3D For example, would it be OK if we leave implementation-specific the criteri= a upon which a dots server relies to consider two requests from two clients= as conflicting, but draft-ietf-dots-signal defines only the procedure to n= otify clients when a conflict is detected? Jon> I agree that how this is done is implementation specific. However the= re is a scenario where Client-A initiates a mitigation requests which is ac= ted upon, Client-B does a conflicting mitigation request but the DOTS Serve= r decides that Client-B is the "more" valid mitigation request and effectiv= ely de-activates Client-A's request. Table 2: draft-ietf-dots-signal-chann= el-09 therefore needs an additional status parameter to indicate to client-= A there is a conflict and hence Client-A is being stood down while another = client is controlling the mitigation. A suggestion would be 7 | DOTS Server has detected conflicting mitigation requests from different= DOTS clients. This mitigation request is currently inactive until the con= flicts are resolved. Another mitigation request is active. Jon> The DOTS client can then elect to leave in the mitigation request (and= even refresh the PUT to refresh the timeout) or delete it. Jon> I do not think it appropriate that an error message be sent back (e.g.= 4.xx) if the DOTS server immediately decides there is a conflicting reques= t and closes down the new PUT request unless we come up with a specific err= or code so the DOTS client can understand why the request is getting errore= d. Likewise, would it be OK if the document does not specify which of the conf= licting actions is to be discarded (old, new, all) by the server, but draft= -ietf-dots-signal defines how to inform clients about which action was enfo= rced by the server? Jon> Again, I think that this would be implementation specific. The sugges= ted Table 2: entry above would cover this as well. The DOTS client just ne= eds to know it has been de-selected / discarded - I don't think the DOTS cl= ient needs to know how / why the DOTS server chose that particular DOTS cli= ent. Cheers, Med --_000_787AE7BB302AE849A7480A190F8B93300A08307AOPEXCLILMA3corp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Tiru,

 

I agree with you that discardin= g all conflicting requests may not be helpful in some cases. In the same wa= y that someone can argue that selecting only one request among conflicting ones may not be useful because the server picked= the wrong one.   

 

I do prefer to leave this to im= plementation/deployment as a policy to be supplied. That policy will instru= ct the dots server about the behavior to follow based one specific information that is available for a given deployment: &= nbsp;

=B7    &n= bsp;    Pick one and deactivate= all the others based on some criteria

=B7    &n= bsp;    Activate all of them

=B7    &n= bsp;    De-activate all of them

 

Cheers,

Med

 

De : Dots [mailto:dots-bounces@ietf.= org] De la part de Konda, Tirumaleswar Reddy
Envoy=E9 : mercredi 29 novembre 2017 06:39
=C0 : BOUCADAIR Mohamed IMT/OLN; Jon Shallow; dots@ietf.org
Objet : Re: [Dots] signal-channel: Conflict detection and notif= ication

 

Hi Med,

 

In a deployment scenario with a DDoS Detector (or a on premise DDoS m= itigation system) acting as DOTS clients and a web server with in-built DDo= S detection capability. The web server may not have as much visibility into the extent of the DDoS attack as the = DDoS Detector (or IDMS) and there will be conflicting mitigation requests f= rom different DOTS clients, discarding all the mitigation requests from dif= ferent clients will make the mechanism not useful.

 

-Tiru

 

From: mohamed.boucadair@orange.co= m [mailto:mohamed.bouca= dair@orange.com]
Sent: Tuesday, November 28, 2017 8:55 PM
To: Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@McAfee.com>; Jon Shallow= <supjps-ietf@jpshallow.com= >; dots@ietf.org
Subject: RE: [Dots] signal-channel: Conflict detection and notificat= ion

 

Tiru,

 

Please see inline.

 

Cheers,

Med

 

De : Dots [mailto:dots-bounces@ietf.org] De la part de Konda, Tirumaleswar Reddy
Envoy=E9 : mardi 28 novembre 2017 16:02
=C0 : Jon Shallow; BOUCADAIR Mohamed IMT/OLN; dots@ietf.org
Objet : Re: [Dots] signal-channel: Conflict detection and notif= ication

 

Within a administrative domain, there won’t be many different D= OTS clients raising conflicting mitigation requests for the same target, th= e conflict may arise between a DDoS Detector (or a on premise DDoS mitigation system) acting as DOTS clients and a web = server with in-built DDoS detection capability. 

[Med= ] I don’t think that we can speculate about the nature of the conflic= ts that may happen. Misconfigured and corrupted software instances may happen.

 

Under what conditions does the DOTS server return “DOTS Server = has detected conflicting mitigation requests from different DOTS clients.&n= bsp; All conflicting mitigation requests are inactive.” ?

[Med= ] A dots server can be typically instructed by a policy to discard conflict= ing requests. The rationale is that the provider thinks that the clients are misconfigured and something is needed to be fi= xed before solicited the server. The signal-channel does not need to call f= or a favorite action when conflicts; that is implementation- and deployment= -specific.  

 

-Tiru

 

From: Jon Shallow [mailto:s= upjps-ietf@jpshallow.com]
Sent: Tuesday, November 28, 2017 7:45 PM
To: mohamed.boucadai= r@orange.com; Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@McAfee.com>; dots@ietf.org
Subject: RE: [Dots] signal-channel: Conflict detection and notificat= ion

 

Hi Med,=

&n= bsp;

In prin= cipal I accept the concept of your 7, 8 & 9 status which in effect are = part of the mitigation state as in a state diagram.  However, having i= ssued a “8” status, this then needs to transition to another state which reflects what is actually happening – e.g. &#= 8220;2”.

&n= bsp;

The act= ual state could immediately be sent following the reporting of “8R= 21; (if Observe active), else it would need to wait until the next status G= ET.  It is possible that the “8” message gets lost, so relying on receiving the “8” could be dangerous.=

&n= bsp;

With a = “9” response what then is the DOTS client allowed to do?

- A ret= ry of the original mitigation request is likely to fail again

- If al= l the DOTS clients back off, then there will be no mitigation

- Shoul= d there be a random back-off time before retrying?

&n= bsp;

What is= critical is that

   &= nbsp;  DOTS servers in the same administrative domain attempting to ho= nor

   &= nbsp;  conflicting requests may flap network route or DNS information,=

   &= nbsp;  degrading the networks attempting to participate in attack=

   &= nbsp;  response with the DOTS clients.

Should not be allowed to happen.

&n= bsp;

I also = do not want to lose sight of

The notification SHOULD indicate the nature and scope of the conf= lict,

for example, the overlapping prefix range in a conflicting mitiga= tion request.”

This po= tentially can be conveyed in the 4.09 message, or could be a new mitigation= status parameter such as "additional-info" with an appropriate t= ext value.  It could be that “status” stays with “1” through “6”, and (possibly optional) “ad= ditional-status” has

0 | Thi= s DOTS client mitigation request is being honoured

1 | DOT= S Server has detected conflicting mitigation requests from different DOTS c= lients.  This mitigation request is currently inactive until the confl= icts are resolved. Another mitigation request is active.

2 | DOT= S Server has detected conflicting mitigation requests from different DOTS c= lients.  This mitigation request is currently active.

3 | DOT= S Server has detected conflicting mitigation requests from different DOTS c= lients.  All conflicting mitigation requests are inactive.<= /span>

And = 220;additional-info” reports on what the nature and scope of the conf= lict is.

&n= bsp;

Regards=

&n= bsp;

Jon

&n= bsp;

From:= Dots [mailto: dots-bounces@ietf.org] On B= ehalf Of mohamed.boucadair@orang= e.com
Sent: 28 November 2017 13:29
To: Jon Shallow; 'Konda, Tirumaleswar Reddy'; dots@ietf.org
Subject: Re: [Dots] signal-channel: Conflict detection and notificat= ion

 

Hi Jon, all,

 

Thank you for sharing your thou= ghts on this.

 

I tend to allow for both 4.09 c= ode and new status values in the spec.

 

I see that you proposed this ne= w value:

=3D=3D

7 | DOT= S Server has detected conflicting mitigation requests from different DOTS c= lients.  This mitigation request is currently inactive until the confl= icts are resolved. Another mitigation request is active.

=3D=3D

 

Please note that a server may b= e instructed to adopt a more strict behavior by deactivating all conflictin= g requests. Further, all DOTS clients which issued conflicting requests should be notified, not only the one for which a requ= est is de-activated. As such, I’m afraid we will need more values, e.= g.,

 

=3D=3D

7 | DOT= S Server has detected conflicting mitigation requests from different DOTS c= lients.  This mitigation request is currently inactive until the confl= icts are resolved. Another mitigation request is active.

8 | DOT= S Server has detected conflicting mitigation requests from different DOTS c= lients.  This mitigation request is currently active.

9 | DOT= S Server has detected conflicting mitigation requests from different DOTS c= lients.  All conflicting mitigation requests are inactive.<= /span>

=3D=3D

 

For example:<= /p>

* If the server decides to acti= vate only one request, then 7 will be sent to all clients for which the req= uest is de-activated and 8 to the client for which the request is maintained active.

* If the server decides to deac= tivate all requests, then 9 will be sent to all clients.  <= /span>

 

Cheers,

Med

 

J= on Shallow [mailto:supjps-ietf= @jpshallow.com]
Envoy=E9 : mardi 28 novembre 2017 13:31
=C0 : 'Konda, Tirumaleswar Reddy'; BOUCADAIR Mohamed IMT/OLN; dots@ietf.org
Objet : RE: [Dots] signal-channel: Conflict detection and notif= ication

 

Hi Tiru= ,

&n= bsp;

If Clie= nt-A has invoked a mitigation, then Client-B requests a conflicting mitigat= ion, if the DOTS server is only allowing the first mitigation request to be= the valid one, then the DOTS server could send back a 4.09 to Client-B.

&n= bsp;

However= , if the DOTS server is allowed to choose the best mitigation request, deci= des it is Client-B, there is no simple way of sending an unsolicited 4.09 t= o client-A.  Hence suggestion for an additional status message which can be sent to Client-A stating that Client-A has bee= n de-selected because of a mitigation request conflict.

&n= bsp;

It is a= lso possible that a mitigation state is status 1 (parameter value – T= able 2)) and needs to transition to another state – at which point th= e conflict is found - possibly by the DOTS mitigator - which then needs to be relayed back through the DOTS server.<= /span>

&n= bsp;

Regards=

&n= bsp;

Jon

&n= bsp;

From:= Konda, Tirumaleswar Reddy [mailto: TirumaleswarReddy_Konda@mcafee.com]
Sent: 28 November 2017 11:42
To: Jon Shallow; moh= amed.boucadair@orange.com; dots@ietf.org
Subject: RE: [Dots] signal-channel: Conflict detection and notificat= ion

 

Hi Jon,

 

What is the problem if the DOTS server returns 4.09 (conflict) error = response for the conflicting mitigation request from Client-A ?<= /span>

The above error code is already defined https://tools.ie= tf.org/html/rfc8132.

 

-Tiru

 

From: Dots [mailto:dots-bounces= @ietf.org] On Behalf Of Jon Shallow
Sent: Tuesday, November 28, 2017 4:50 PM
To: mohamed.boucadai= r@orange.com; dots@ietf.org
Subject: Re: [Dots] signal-channel: Conflict detection and notificat= ion

 

Hi Med,=

&n= bsp;

See inl= ine

&n= bsp;

Regards=

&n= bsp;

Jon

&n= bsp;

From:= Dots [mailto: dots-bounces@ietf.org] On B= ehalf Of ietf-supjps= -mohamed.boucadair@orange.com
Sent: 24 November 2017 14:03
To: dots@ietf.org
Subject: [Dots] signal-channel: Conflict detection and notification<= o:p>

 

Hi all,

 

As discussed during the last IETF meeting, = we are seeking for feedback from the WG about how to address this requireme= nt:

 

=3D=3D=3D=3D=3D=3D=3D=3D=3D

   SIG-00= 9  Conflict Detection and Notification: Multiple DOTS clients

   &= nbsp;  controlled by a single administrative entity may send conflicti= ng

   &= nbsp;  mitigation requests for pools of protected resources as a resul= t

   &= nbsp;  of misconfiguration, operator error, or compromised DOTS client= s.

   &= nbsp;  DOTS servers in the same administrative domain attempting to ho= nor

   &= nbsp;  conflicting requests may flap network route or DNS information,=

   &= nbsp;  degrading the networks attempting to participate in attack=

   &= nbsp;  response with the DOTS clients.  DOTS servers in a single<= o:p>

   &= nbsp;  administrative domain SHALL detect such conflicting requests, a= nd

   &= nbsp;  SHALL notify the DOTS clients in conflict.  The notificati= on

   &= nbsp;  SHOULD indicate the nature and scope of the conflict, for examp= le,

   &= nbsp;  the overlapping prefix range in a conflicting mitigation reques= t.

=3D=3D=3D=3D=3D=3D=3D=3D<= /p>

 

For example, would it be OK if we leave imp= lementation-specific the criteria upon which a dots server relies to consid= er two requests from two clients as conflicting, but draft-ietf-dots-signal defines only the procedure to notify clients wh= en a conflict is detected?

Jon>= I agree that how this is done is implementation specific.  However th= ere is a scenario where Client-A initiates a mitigation requests which is a= cted upon, Client-B does a conflicting mitigation request but the DOTS Server decides that Client-B is the “more”= ; valid mitigation request and effectively de-activates Client-A’s re= quest.  Table 2: draft-ietf-dots-signal-channel-09 therefore needs an = additional status parameter to indicate to client-A there is a conflict and hence Client-A is being stood down while another client = is controlling the mitigation.  A suggestion would be

&n= bsp;

7 | DOT= S Server has detected conflicting mitigation requests from different DOTS c= lients.  This mitigation request is currently inactive until the confl= icts are resolved. Another mitigation request is active.

&n= bsp;

Jon>= The DOTS client can then elect to leave in the mitigation request (and eve= n refresh the PUT to refresh the timeout) or delete it.

Jon>= I do not think it appropriate that an error message be sent back (e.g. 4.x= x) if the DOTS server immediately decides there is a conflicting request an= d closes down the new PUT request unless we come up with a specific error code so the DOTS client can understand wh= y the request is getting errored.

&n= bsp;

 

Likewise, would it be OK if the document do= es not specify which of the conflicting actions is to be discarded (old, ne= w, all) by the server, but draft-ietf-dots-signal defines how to inform clients about which action was enforced by the serve= r?

&n= bsp;

Jon>= Again, I think that this would be implementation specific.  The sugge= sted Table 2: entry above would cover this as well.  The DOTS client j= ust needs to know it has been de-selected / discarded – I don’t think the DOTS client needs to know how / why the DO= TS server chose that particular DOTS client.

 

Cheers,

Med

--_000_787AE7BB302AE849A7480A190F8B93300A08307AOPEXCLILMA3corp_-- From nobody Wed Nov 29 00:58:35 2017 Return-Path: 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 8DF4A126D05 for ; Wed, 29 Nov 2017 00:58:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.31 X-Spam-Level: X-Spam-Status: No, score=0.31 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FORGED_MUA_MOZILLA=2.309, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yahoo.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 CRGxPAGbu1LZ for ; Wed, 29 Nov 2017 00:58:32 -0800 (PST) Received: from sonic302-20.consmr.mail.gq1.yahoo.com (sonic302-20.consmr.mail.gq1.yahoo.com [98.137.68.146]) (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 A386B124B17 for ; Wed, 29 Nov 2017 00:58:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1511945912; bh=RSXkdLiQ46VRlKnXfGEIbDRMUiZMiuoe1A3su9qAnLs=; h=Date:From:To:In-Reply-To:References:Subject:From:Subject; b=gx1IVE53FxbOwTrEOB1CU3sJ3AUYuzuOlBSWD604/ZLDkL1/WzbJTDzldK3LLAZRfbkuULPuxVWPMDwjE5sjEZnLUUZ7Ng2plgHy0/TZDSN4jVxyDuXGGEf3W8uqiPJfFQDx5GrSiJ69jWSL9Av8ZpUK7ackY/hOjakYB2Bp8+gUJw50jzI27S6ngw50saSMFEFKGLwgAgtvYDYOGli6DFEcXq28fWP5XtC3L+M0a6+8EoAGLtzZtTeuN7tY51bDoKaq5v/dIfCkvZr0aqwtdhJjr3f69dSunLlEhWmG2SliZZO8hLYkfowu8cnLpJ/XMcY2EwWQBSwTAMoPOdIlgw== X-YMail-OSG: PFHGJ2cVM1lbbF9dRR4jPxLxMdp8uZp9z1LkL4VKh8gs73sj2VOnX0HXbN6nuxL QBKyqELkCzKAWv.B_5vfEGNdLUdpg48nPa.bdxG8EBRTG17VmtK81hQDZAWX5JbkCazIFi9VLRLe 8q937jWDWWyXGzKVcAvMbzHNruIFj3KZ1CKMvB2FARZ07Jo5fufVGZOh_1Fy1OA65Wd1OoI3J9nu 7ScG.YSNbejcYGrc2UGTETw3G918j3I7f0PdMdR8zB5is0q0adQArvXjCLvtmfZMLmSGx1_JsmVA 1oJsbBy4faZ_VJIYr1Ivb54yWBEpL2JdzXADEdiOVyNT44G1LJoz25w8IFAoxG1aWgSUnf8dpEd9 3h.JmSKogjC4cK_NPAj8ZzaBZPYb2_v3XEpm2kqwQ2W69dmhastVlkNSlc8xNDX_UkvN1H1tb2AC UrwUU5CUaSjZZE.qib7a7G3iYCuVzCHNP0k80S109luBxAaUh8J.MCqp5dbTCm3nW1RNvVBgvzUH FkQ-- Received: from sonic.gate.mail.ne1.yahoo.com by sonic302.consmr.mail.gq1.yahoo.com with HTTP; Wed, 29 Nov 2017 08:58:32 +0000 Date: Wed, 29 Nov 2017 08:58:27 +0000 (UTC) From: Nesredien Suleiman To: Jon Shallow , "mohamed.boucadair@orange.com" , "dots@ietf.org" , "Konda, Tirumaleswar Reddy" Message-ID: <154381142.3807572.1511945907334@mail.yahoo.com> In-Reply-To: References: <151186010967.13469.3880889839321858106@ietfa.amsl.com> <787AE7BB302AE849A7480A190F8B93300A0807FA@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <009401d36835$10212780$30637680$@jpshallow.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_3807571_234268571.1511945907331" X-Mailer: WebService/1.1.10982 YMailNorrin Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/62.0.3202.94 Safari/537.36 Archived-At: Subject: Re: [Dots] I-D Action: draft-ietf-dots-signal-channel-09.txt 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Nov 2017 08:58:35 -0000 ------=_Part_3807571_234268571.1511945907331 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hello There,First I would like to express my appreciation to everyone who = is contributing on this document. I am forwarding my minor comments as foll= ows: =20 - Though most of the readers of the document and members of this mailing= list are experts but there could be some readers who may not be that exper= t so I believe it would be better if some acronyms and abbreviations are wr= itten in full form on their first usage as it is done for others such as DD= oS. On Page 4 on the Network diagram there is an acronym CPE - It would have been good if the network diagram is explained a bit. - On Page 4 last paragraph at third line, there is grammatical error on = the phrase "Operated by an domain" I believe it should be "Operated by a do= main". - At section 4.2 CoAP URIs, Table 1 is not sited in the document. Best regards,Nesredien On Tuesday, November 28, 2017, 2:00:35 PM GMT+3, Konda, Tirumaleswar Re= ddy wrote: =20 =20 Thanks Jon, fixed both Nits (uploaded revision to github).=20 -Tiru > -----Original Message----- > From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Jon Shallow > Sent: Tuesday, November 28, 2017 4:09 PM > To: mohamed.boucadair@orange.com; dots@ietf.org > Subject: Re: [Dots] I-D Action: draft-ietf-dots-signal-channel-09.txt >=20 > I like the reformatting and use of mitigation instead of signal in the > appropriate places. >=20 > Nits >=20 > Table 2: > "DOTS client an withdraw" should be "DOTS client can withdraw" >=20 > Figure 12: > It would be good to add in the option If-Match in the example - i.e. >=C2=A0 =C2=A0 =C2=A0 Header: PUT (Code=3D0.03) >=C2=A0 =C2=A0 =C2=A0 Uri-Host: "host" >=C2=A0 =C2=A0 =C2=A0 Uri-Path: ".well-known" >=C2=A0 =C2=A0 =C2=A0 Uri-Path: "dots" >=C2=A0 =C2=A0 =C2=A0 Uri-Path: "version" >=C2=A0 =C2=A0 =C2=A0 Uri-Path: "mitigate" >=C2=A0 =C2=A0 =C2=A0 Content-Format: "application/cbor" >=C2=A0 =C2=A0 =C2=A0 If-Match: >=C2=A0 =C2=A0 =C2=A0 { >=C2=A0 =C2=A0 =C2=A0 =C2=A0 "mitigation-scope": { >=20 > Regards >=20 > Jon >=20 > -----Original Message----- > From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of ietf-supjps- > mohamed.boucadair@orange.com > Sent: 28 November 2017 09:18 > To: dots@ietf.org > Subject: Re: [Dots] I-D Action: draft-ietf-dots-signal-channel-09.txt >=20 > Hi all, >=20 > We tried to reorganize the content of the draft for a better readability.= We > also fixed many nits and checked the consistency of the overall document. >=20 > The only pending issue so far is how to handle conflicts among dots clien= ts. >=20 >=20 > Please review and share your comments. >=20 > Cheers, > Med >=20 > > -----Message d'origine----- > > De=C2=A0: I-D-Announce [mailto:i-d-announce-bounces@ietf.org] De la par= t de > > internet-drafts@ietf.org Envoy=C3=A9=C2=A0: mardi 28 novembre 2017 10:0= 8 =C3=80=C2=A0: > > i-d-announce@ietf.org Cc=C2=A0: dots@ietf.org Objet=C2=A0: I-D Action: > > draft-ietf-dots-signal-channel-09.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. > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : Di= stributed Denial-of-Service Open Threat > > Signaling (DOTS) Signal Channel > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 Authors=C2=A0 =C2=A0 =C2=A0 =C2=A0 : Tirumal= eswar Reddy > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 Mohamed Boucadair > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 Prashanth Patil > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 Andrew Mortensen > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 Nik Teague > > =C2=A0=C2=A0=C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-ietf-dot= s-signal-channel-09.txt > > =C2=A0=C2=A0=C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : 64 > > =C2=A0=C2=A0=C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : 2017= -11-28 > > > > Abstract: > >=C2=A0 =C2=A0 This document specifies the DOTS signal channel, a protoco= l for > >=C2=A0 =C2=A0 signaling the need for protection against Distributed Deni= al-of- > >=C2=A0 =C2=A0 Service (DDoS) attacks to a server capable of enabling net= work > >=C2=A0 =C2=A0 traffic mitigation on behalf of the requesting client. > > > >=C2=A0 =C2=A0 A companion document defines the DOTS data channel, a sepa= rate > >=C2=A0 =C2=A0 reliable communication layer for DOTS management and confi= guration. > > > > Editorial Note (To be removed by RFC Editor) > > > >=C2=A0 =C2=A0 Please update these statements with the RFC number to be a= ssigned to > >=C2=A0 =C2=A0 this document: > > > >=C2=A0 =C2=A0 o=C2=A0 "This version of this YANG module is part of RFC X= XXX;" > > > >=C2=A0 =C2=A0 o=C2=A0 "RFC XXXX: Distributed Denial-of-Service Open Thre= at Signaling > >=C2=A0 =C2=A0 =C2=A0 (DOTS) Signal Channel"; > > > >=C2=A0 =C2=A0 o=C2=A0 "| 3.00 | Alternate server | [RFCXXXX] |" > > > >=C2=A0 =C2=A0 o=C2=A0 reference: RFC XXXX > > > > > > The IETF datatracker status page for this draft is: > > https://datatracker.ietf.org/doc/draft-ietf-dots-signal-channel/ > > > > There are also htmlized versions available at: > > https://tools.ietf.org/html/draft-ietf-dots-signal-channel-09 > > https://datatracker.ietf.org/doc/html/draft-ietf-dots-signal-channel-0 > > 9 > > > > A diff from the previous version is available at: > > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dots-signal-channel-09 > > > > > > 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/ > > > > _______________________________________________ > > I-D-Announce mailing list > > I-D-Announce@ietf.org > > https://www.ietf.org/mailman/listinfo/i-d-announce > > Internet-Draft directories: http://www.ietf.org/shadow.html or > > ftp://ftp.ietf.org/ietf/1shadow-sites.txt >=20 > _______________________________________________ > Dots mailing list > Dots@ietf.org > https://www.ietf.org/mailman/listinfo/dots >=20 > _______________________________________________ > 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 =20 ------=_Part_3807571_234268571.1511945907331 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hello There,
First I would like to express my ap= preciation to everyone who is contributing on this document. I am forwardin= g my minor comments as follows:
  • Though most of the reader= s of the document and members of this mailing list are experts but there co= uld be some readers who may not be that expert so I believe it would be bet= ter if some acronyms and abbreviations are written in full form on their fi= rst usage as it is done for others such as DDoS. On Page 4 on the Network d= iagram there is an acronym CPE
  • It would have been good if the netwo= rk diagram is explained a bit.
  • On Page 4 last paragraph at third li= ne, there is grammatical error on the phrase "Operated by an domain" I beli= eve it should be "Operated by a domain".
  • At section 4.2 CoAP URIs, = Table 1 is not sited in the document.
Best regards,
Nesredien


=20
=20
On Tuesday, November 28, 2017, 2:00:35 PM GMT+3, Ko= nda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@McAfee.com> wrote:


Thanks Jon, fixed both Nits (uplo= aded revision to github).

-Tiru

> -----Original Message-----
> From: Dots [mailto:dots-bounces@ietf.org<= /a>] On Behalf Of Jon Shallow
> Sent: Tuesday, Novembe= r 28, 2017 4:09 PM
> To: mohamed.boucadair@orange.com; dots@ietf.org
> Subject: Re: [Dots] I-D Action: draft-ietf-dots-signal-chann= el-09.txt
>
> I like the reforma= tting and use of mitigation instead of signal in the
>= appropriate places.
>
> Nits>
> Table 2:
>= ; "DOTS client an withdraw" should be "DOTS client can withdraw"
>
> Figure 12:
> It= would be good to add in the option If-Match in the example - i.e.
>      Header: PUT (Code=3D0.03)
>      Uri-Host: "host"
> = ;     Uri-Path: ".well-known"
>   = ;   Uri-Path: "dots"
>      Uri-= Path: "version"
>      Uri-Path: "miti= gate"
>      Content-Format: "applicat= ion/cbor"
>      If-Match:
>      {
>    &nbs= p;   "mitigation-scope": {
>
&= gt; Regards
>
> Jon
>
> -----Original Message-----
> From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of ietf-supjps-
> mohamed.boucadair@orange.com
> Sent:= 28 November 2017 09:18
> To: dots@ietf.org<= br clear=3D"none">> Subject: Re: [Dots] I-D Action: draft-ietf-dots-sign= al-channel-09.txt
>
> Hi all,>
> We tried to reorganize the con= tent of the draft for a better readability. We
> also = fixed many nits and checked the consistency of the overall document.
>
> The only pending issue so far is h= ow to handle conflicts among dots clients.
>
>
> Please review and share your comment= s.
>
> Cheers,
> Med
>
> > -----Message = d'origine-----
> > De : I-D-Announce [mailto:<= a shape=3D"rect" ymailto=3D"mailto:i-d-announce-bounces@ietf.org" href=3D"m= ailto:i-d-announce-bounces@ietf.org">i-d-announce-bounces@ietf.org] De = la part de
> > internet= -drafts@ietf.org Envoy=C3=A9 : mardi 28 novembre 2017 10:08 =C3=80=  :
> > i-d-announce@ietf= .org Cc : dots@ietf.org Objet : I-D Action:
> > draft-ietf-dots-signal-channel-09.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
> &g= t; IETF.
> >
> >  &nbs= p;     Title          : Distributed De= nial-of-Service Open Threat
> > Signaling (DOTS) Si= gnal Channel
> >        Author= s        : Tirumaleswar Reddy
> &= gt;                    &n= bsp;     Mohamed Boucadair
> >  &nb= sp;                     &= nbsp; Prashanth Patil
> >      &nbs= p;                   Andrew M= ortensen
> >          &nbs= p;               Nik Teague
> >     Filename        : d= raft-ietf-dots-signal-channel-09.txt
> >  &nbs= p;  Pages          : 64
&g= t; >     Date            : = 2017-11-28
> >
> > Abstract= :
> >    This document specifies the DOTS= signal channel, a protocol for
> >    si= gnaling the need for protection against Distributed Denial-of-
> >    Service (DDoS) attacks to a server capable of = enabling network
> >    traffic mitigatio= n on behalf of the requesting client.
> >
> >    A companion document defines the DOTS data= channel, a separate
> >    reliable comm= unication layer for DOTS management and configuration.
&g= t; >
> > Editorial Note (To be removed by RFC Ed= itor)
> >
> >    = Please update these statements with the RFC number to be assigned to
> >    this document:
> &g= t;
> >    o  "This version of this Y= ANG module is part of RFC XXXX;"
> >
> >    o  "RFC XXXX: Distributed Denial-of-Service= Open Threat Signaling
> >      (DO= TS) Signal Channel";
> >
> >= ;    o  "| 3.00 | Alternate server | [RFCXXXX] |"
> >
> >    o  refere= nce: RFC XXXX
> >
> >
> > The IETF datatracker status page for this draft is:<= br clear=3D"none">> > https://data= tracker.ietf.org/doc/draft-ietf-dots-signal-channel/
= > >
> > There are also htmlized versions avai= lable at:
> > https= ://tools.ietf.org/html/draft-ietf-dots-signal-channel-09
> > https://datatracker.= ietf.org/doc/html/draft-ietf-dots-signal-channel-0
&g= t; > 9
> >
> > A diff fr= om the previous version is available at:
> > https://www.ietf.org/rfcdiff?url2=3Ddraft= -ietf-dots-signal-channel-09
> >
> >
> > Please note that it may take a co= uple of minutes from the time of
> > submission unt= il the htmlized version and diff are available at
> &g= t; tools.ietf.org.
> >
> > = Internet-Drafts are also available by anonymous FTP at:
&= gt; > ftp://ftp.ietf.org/internet-drafts/
&g= t; >
> > _______________________________________= ________
> > I-D-Announce mailing list
> > I-D-Announce@ietf.org
> > https://www.ietf.org/mailman/listinfo= /i-d-announce
> > Internet-Draft directories: <= a shape=3D"rect" href=3D"http://www.ietf.org/shadow.html " target=3D"_blank= ">http://www.ietf.org/shadow.html or
> > ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> =
> _______________________________________________
> Dots mailing list
> Dots@iet= f.org
> https://www.ietf.org/mailman/= listinfo/dots

>
> ____________________________________= ___________
> Dots mailing list
>= Dots@ietf.org
> https://www.ie= tf.org/mailman/listinfo/dots

_____= __________________________________________
Dots mailing l= ist
Dots@ietf.org
https://www.ietf.org/mailman/listinfo/dots
------=_Part_3807571_234268571.1511945907331-- From nobody Wed Nov 29 02:24:49 2017 Return-Path: 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 D7F9D126DFE for ; Wed, 29 Nov 2017 02:24:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.398 X-Spam-Level: X-Spam-Status: No, score=-5.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-2.8, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no 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 Hn31gA2269G1 for ; Wed, 29 Nov 2017 02:24:44 -0800 (PST) Received: from orange.com (mta135.mail.business.static.orange.com [80.12.70.35]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A5FB012421A for ; Wed, 29 Nov 2017 02:24:43 -0800 (PST) Received: from opfednr00.francetelecom.fr (unknown [xx.xx.xx.64]) by opfednr21.francetelecom.fr (ESMTP service) with ESMTP id 99939C0D74; Wed, 29 Nov 2017 11:24:41 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.42]) by opfednr00.francetelecom.fr (ESMTP service) with ESMTP id 6C3CF1A0069; Wed, 29 Nov 2017 11:24:41 +0100 (CET) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM41.corporate.adroot.infra.ftgroup ([fe80::c845:f762:8997:ec86%19]) with mapi id 14.03.0361.001; Wed, 29 Nov 2017 11:24:41 +0100 From: To: Nesredien Suleiman , Jon Shallow , "dots@ietf.org" , "Konda, Tirumaleswar Reddy" Thread-Topic: [Dots] I-D Action: draft-ietf-dots-signal-channel-09.txt Thread-Index: AQHTaPA96Ht8tlCIqUaC+daVG4cP5aMrJmFQ Date: Wed, 29 Nov 2017 10:24:40 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93300A083263@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <151186010967.13469.3880889839321858106@ietfa.amsl.com> <787AE7BB302AE849A7480A190F8B93300A0807FA@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <009401d36835$10212780$30637680$@jpshallow.com> <154381142.3807572.1511945907334@mail.yahoo.com> In-Reply-To: <154381142.3807572.1511945907334@mail.yahoo.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.4] Content-Type: multipart/alternative; boundary="_000_787AE7BB302AE849A7480A190F8B93300A083263OPEXCLILMA3corp_" MIME-Version: 1.0 Archived-At: Subject: Re: [Dots] I-D Action: draft-ietf-dots-signal-channel-09.txt 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Nov 2017 10:24:46 -0000 --_000_787AE7BB302AE849A7480A190F8B93300A083263OPEXCLILMA3corp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgTmVzcmVkaWVuLA0KDQpUaGFuayB5b3UgZm9yIHRoZSByZXZpZXcuDQoNCldpbGwgYmUgZml4 ZWQgaW4gdGhlIG5leHQgaXRlcmF0aW9uIG9mIHRoZSBkcmFmdCA6IGh0dHBzOi8vZ2l0aHViLmNv bS9kb3Rzd2cvZG90cy1zaWduYWwtY2hhbm5lbC9wdWxsLzkvZmlsZXMuDQoNCkNoZWVycywNCk1l ZA0KDQpEZSA6IE5lc3JlZGllbiBTdWxlaW1hbiBbbWFpbHRvOm1obnNhc0B5YWhvby5jb21dDQpF bnZvecOpIDogbWVyY3JlZGkgMjkgbm92ZW1icmUgMjAxNyAwOTo1OA0Kw4AgOiBKb24gU2hhbGxv dzsgQk9VQ0FEQUlSIE1vaGFtZWQgSU1UL09MTjsgZG90c0BpZXRmLm9yZzsgS29uZGEsIFRpcnVt YWxlc3dhciBSZWRkeQ0KT2JqZXQgOiBSZTogW0RvdHNdIEktRCBBY3Rpb246IGRyYWZ0LWlldGYt ZG90cy1zaWduYWwtY2hhbm5lbC0wOS50eHQNCg0KSGVsbG8gVGhlcmUsDQpGaXJzdCBJIHdvdWxk IGxpa2UgdG8gZXhwcmVzcyBteSBhcHByZWNpYXRpb24gdG8gZXZlcnlvbmUgd2hvIGlzIGNvbnRy aWJ1dGluZyBvbiB0aGlzIGRvY3VtZW50LiBJIGFtIGZvcndhcmRpbmcgbXkgbWlub3IgY29tbWVu dHMgYXMgZm9sbG93czoNCg0KICAqICAgVGhvdWdoIG1vc3Qgb2YgdGhlIHJlYWRlcnMgb2YgdGhl IGRvY3VtZW50IGFuZCBtZW1iZXJzIG9mIHRoaXMgbWFpbGluZyBsaXN0IGFyZSBleHBlcnRzIGJ1 dCB0aGVyZSBjb3VsZCBiZSBzb21lIHJlYWRlcnMgd2hvIG1heSBub3QgYmUgdGhhdCBleHBlcnQg c28gSSBiZWxpZXZlIGl0IHdvdWxkIGJlIGJldHRlciBpZiBzb21lIGFjcm9ueW1zIGFuZCBhYmJy ZXZpYXRpb25zIGFyZSB3cml0dGVuIGluIGZ1bGwgZm9ybSBvbiB0aGVpciBmaXJzdCB1c2FnZSBh cyBpdCBpcyBkb25lIGZvciBvdGhlcnMgc3VjaCBhcyBERG9TLiBPbiBQYWdlIDQgb24gdGhlIE5l dHdvcmsgZGlhZ3JhbSB0aGVyZSBpcyBhbiBhY3JvbnltIENQRQ0KICAqICAgSXQgd291bGQgaGF2 ZSBiZWVuIGdvb2QgaWYgdGhlIG5ldHdvcmsgZGlhZ3JhbSBpcyBleHBsYWluZWQgYSBiaXQuDQog ICogICBPbiBQYWdlIDQgbGFzdCBwYXJhZ3JhcGggYXQgdGhpcmQgbGluZSwgdGhlcmUgaXMgZ3Jh bW1hdGljYWwgZXJyb3Igb24gdGhlIHBocmFzZSAiT3BlcmF0ZWQgYnkgYW4gZG9tYWluIiBJIGJl bGlldmUgaXQgc2hvdWxkIGJlICJPcGVyYXRlZCBieSBhIGRvbWFpbiIuDQogICogICBBdCBzZWN0 aW9uIDQuMiBDb0FQIFVSSXMsIFRhYmxlIDEgaXMgbm90IHNpdGVkIGluIHRoZSBkb2N1bWVudC4N CkJlc3QgcmVnYXJkcywNCk5lc3JlZGllbg0KDQoNCk9uIFR1ZXNkYXksIE5vdmVtYmVyIDI4LCAy MDE3LCAyOjAwOjM1IFBNIEdNVCszLCBLb25kYSwgVGlydW1hbGVzd2FyIFJlZGR5IDxUaXJ1bWFs ZXN3YXJSZWRkeV9Lb25kYUBNY0FmZWUuY29tPG1haWx0bzpUaXJ1bWFsZXN3YXJSZWRkeV9Lb25k YUBNY0FmZWUuY29tPj4gd3JvdGU6DQoNCg0KVGhhbmtzIEpvbiwgZml4ZWQgYm90aCBOaXRzICh1 cGxvYWRlZCByZXZpc2lvbiB0byBnaXRodWIpLg0KDQotVGlydQ0KDQo+IC0tLS0tT3JpZ2luYWwg TWVzc2FnZS0tLS0tDQo+IEZyb206IERvdHMgW21haWx0bzpkb3RzLWJvdW5jZXNAaWV0Zi5vcmc8 bWFpbHRvOmRvdHMtYm91bmNlc0BpZXRmLm9yZz5dIE9uIEJlaGFsZiBPZiBKb24gU2hhbGxvdw0K PiBTZW50OiBUdWVzZGF5LCBOb3ZlbWJlciAyOCwgMjAxNyA0OjA5IFBNDQo+IFRvOiBtb2hhbWVk LmJvdWNhZGFpckBvcmFuZ2UuY29tPG1haWx0bzptb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29t PjsgZG90c0BpZXRmLm9yZzxtYWlsdG86ZG90c0BpZXRmLm9yZz4NCj4gU3ViamVjdDogUmU6IFtE b3RzXSBJLUQgQWN0aW9uOiBkcmFmdC1pZXRmLWRvdHMtc2lnbmFsLWNoYW5uZWwtMDkudHh0DQo+ DQo+IEkgbGlrZSB0aGUgcmVmb3JtYXR0aW5nIGFuZCB1c2Ugb2YgbWl0aWdhdGlvbiBpbnN0ZWFk IG9mIHNpZ25hbCBpbiB0aGUNCj4gYXBwcm9wcmlhdGUgcGxhY2VzLg0KPg0KPiBOaXRzDQo+DQo+ IFRhYmxlIDI6DQo+ICJET1RTIGNsaWVudCBhbiB3aXRoZHJhdyIgc2hvdWxkIGJlICJET1RTIGNs aWVudCBjYW4gd2l0aGRyYXciDQo+DQo+IEZpZ3VyZSAxMjoNCj4gSXQgd291bGQgYmUgZ29vZCB0 byBhZGQgaW4gdGhlIG9wdGlvbiBJZi1NYXRjaCBpbiB0aGUgZXhhbXBsZSAtIGkuZS4NCj4gICAg ICBIZWFkZXI6IFBVVCAoQ29kZT0wLjAzKQ0KPiAgICAgIFVyaS1Ib3N0OiAiaG9zdCINCj4gICAg ICBVcmktUGF0aDogIi53ZWxsLWtub3duIg0KPiAgICAgIFVyaS1QYXRoOiAiZG90cyINCj4gICAg ICBVcmktUGF0aDogInZlcnNpb24iDQo+ICAgICAgVXJpLVBhdGg6ICJtaXRpZ2F0ZSINCj4gICAg ICBDb250ZW50LUZvcm1hdDogImFwcGxpY2F0aW9uL2Nib3IiDQo+ICAgICAgSWYtTWF0Y2g6DQo+ ICAgICAgew0KPiAgICAgICAgIm1pdGlnYXRpb24tc2NvcGUiOiB7DQo+DQo+IFJlZ2FyZHMNCj4N Cj4gSm9uDQo+DQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IERvdHMgW21h aWx0bzogZG90cy1ib3VuY2VzQGlldGYub3JnPG1haWx0bzpkb3RzLWJvdW5jZXNAaWV0Zi5vcmc+ XSBPbiBCZWhhbGYgT2YgaWV0Zi1zdXBqcHMtDQo+IG1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5j b208bWFpbHRvOm1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20+DQo+IFNlbnQ6IDI4IE5vdmVt YmVyIDIwMTcgMDk6MTgNCj4gVG86IGRvdHNAaWV0Zi5vcmc8bWFpbHRvOmRvdHNAaWV0Zi5vcmc+ DQo+IFN1YmplY3Q6IFJlOiBbRG90c10gSS1EIEFjdGlvbjogZHJhZnQtaWV0Zi1kb3RzLXNpZ25h bC1jaGFubmVsLTA5LnR4dA0KPg0KPiBIaSBhbGwsDQo+DQo+IFdlIHRyaWVkIHRvIHJlb3JnYW5p emUgdGhlIGNvbnRlbnQgb2YgdGhlIGRyYWZ0IGZvciBhIGJldHRlciByZWFkYWJpbGl0eS4gV2UN Cj4gYWxzbyBmaXhlZCBtYW55IG5pdHMgYW5kIGNoZWNrZWQgdGhlIGNvbnNpc3RlbmN5IG9mIHRo ZSBvdmVyYWxsIGRvY3VtZW50Lg0KPg0KPiBUaGUgb25seSBwZW5kaW5nIGlzc3VlIHNvIGZhciBp cyBob3cgdG8gaGFuZGxlIGNvbmZsaWN0cyBhbW9uZyBkb3RzIGNsaWVudHMuDQo+DQo+DQo+IFBs ZWFzZSByZXZpZXcgYW5kIHNoYXJlIHlvdXIgY29tbWVudHMuDQo+DQo+IENoZWVycywNCj4gTWVk DQo+DQo+ID4gLS0tLS1NZXNzYWdlIGQnb3JpZ2luZS0tLS0tDQo+ID4gRGUgOiBJLUQtQW5ub3Vu Y2UgW21haWx0bzppLWQtYW5ub3VuY2UtYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86aS1kLWFubm91 bmNlLWJvdW5jZXNAaWV0Zi5vcmc+XSBEZSBsYSBwYXJ0IGRlDQo+ID4gaW50ZXJuZXQtZHJhZnRz QGlldGYub3JnPG1haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmc+IEVudm95w6kgOiBtYXJk aSAyOCBub3ZlbWJyZSAyMDE3IDEwOjA4IMOAIDoNCj4gPiBpLWQtYW5ub3VuY2VAaWV0Zi5vcmc8 bWFpbHRvOmktZC1hbm5vdW5jZUBpZXRmLm9yZz4gQ2MgOiBkb3RzQGlldGYub3JnPG1haWx0bzpk b3RzQGlldGYub3JnPiBPYmpldCA6IEktRCBBY3Rpb246DQo+ID4gZHJhZnQtaWV0Zi1kb3RzLXNp Z25hbC1jaGFubmVsLTA5LnR4dA0KPiA+DQo+ID4NCj4gPiBBIE5ldyBJbnRlcm5ldC1EcmFmdCBp cyBhdmFpbGFibGUgZnJvbSB0aGUgb24tbGluZSBJbnRlcm5ldC1EcmFmdHMNCj4gPiBkaXJlY3Rv cmllcy4NCj4gPiBUaGlzIGRyYWZ0IGlzIGEgd29yayBpdGVtIG9mIHRoZSBERG9TIE9wZW4gVGhy ZWF0IFNpZ25hbGluZyBXRyBvZiB0aGUNCj4gPiBJRVRGLg0KPiA+DQo+ID4gICAgICAgIFRpdGxl ICAgICAgICAgIDogRGlzdHJpYnV0ZWQgRGVuaWFsLW9mLVNlcnZpY2UgT3BlbiBUaHJlYXQNCj4g PiBTaWduYWxpbmcgKERPVFMpIFNpZ25hbCBDaGFubmVsDQo+ID4gICAgICAgIEF1dGhvcnMgICAg ICAgIDogVGlydW1hbGVzd2FyIFJlZGR5DQo+ID4gICAgICAgICAgICAgICAgICAgICAgICAgIE1v aGFtZWQgQm91Y2FkYWlyDQo+ID4gICAgICAgICAgICAgICAgICAgICAgICAgIFByYXNoYW50aCBQ YXRpbA0KPiA+ICAgICAgICAgICAgICAgICAgICAgICAgICBBbmRyZXcgTW9ydGVuc2VuDQo+ID4g ICAgICAgICAgICAgICAgICAgICAgICAgIE5payBUZWFndWUNCj4gPiAgICAgRmlsZW5hbWUgICAg ICAgIDogZHJhZnQtaWV0Zi1kb3RzLXNpZ25hbC1jaGFubmVsLTA5LnR4dA0KPiA+ICAgICBQYWdl cyAgICAgICAgICA6IDY0DQo+ID4gICAgIERhdGUgICAgICAgICAgICA6IDIwMTctMTEtMjgNCj4g Pg0KPiA+IEFic3RyYWN0Og0KPiA+ICAgIFRoaXMgZG9jdW1lbnQgc3BlY2lmaWVzIHRoZSBET1RT IHNpZ25hbCBjaGFubmVsLCBhIHByb3RvY29sIGZvcg0KPiA+ICAgIHNpZ25hbGluZyB0aGUgbmVl ZCBmb3IgcHJvdGVjdGlvbiBhZ2FpbnN0IERpc3RyaWJ1dGVkIERlbmlhbC1vZi0NCj4gPiAgICBT ZXJ2aWNlIChERG9TKSBhdHRhY2tzIHRvIGEgc2VydmVyIGNhcGFibGUgb2YgZW5hYmxpbmcgbmV0 d29yaw0KPiA+ICAgIHRyYWZmaWMgbWl0aWdhdGlvbiBvbiBiZWhhbGYgb2YgdGhlIHJlcXVlc3Rp bmcgY2xpZW50Lg0KPiA+DQo+ID4gICAgQSBjb21wYW5pb24gZG9jdW1lbnQgZGVmaW5lcyB0aGUg RE9UUyBkYXRhIGNoYW5uZWwsIGEgc2VwYXJhdGUNCj4gPiAgICByZWxpYWJsZSBjb21tdW5pY2F0 aW9uIGxheWVyIGZvciBET1RTIG1hbmFnZW1lbnQgYW5kIGNvbmZpZ3VyYXRpb24uDQo+ID4NCj4g PiBFZGl0b3JpYWwgTm90ZSAoVG8gYmUgcmVtb3ZlZCBieSBSRkMgRWRpdG9yKQ0KPiA+DQo+ID4g ICAgUGxlYXNlIHVwZGF0ZSB0aGVzZSBzdGF0ZW1lbnRzIHdpdGggdGhlIFJGQyBudW1iZXIgdG8g YmUgYXNzaWduZWQgdG8NCj4gPiAgICB0aGlzIGRvY3VtZW50Og0KPiA+DQo+ID4gICAgbyAgIlRo aXMgdmVyc2lvbiBvZiB0aGlzIFlBTkcgbW9kdWxlIGlzIHBhcnQgb2YgUkZDIFhYWFg7Ig0KPiA+ DQo+ID4gICAgbyAgIlJGQyBYWFhYOiBEaXN0cmlidXRlZCBEZW5pYWwtb2YtU2VydmljZSBPcGVu IFRocmVhdCBTaWduYWxpbmcNCj4gPiAgICAgIChET1RTKSBTaWduYWwgQ2hhbm5lbCI7DQo+ID4N Cj4gPiAgICBvICAifCAzLjAwIHwgQWx0ZXJuYXRlIHNlcnZlciB8IFtSRkNYWFhYXSB8Ig0KPiA+ DQo+ID4gICAgbyAgcmVmZXJlbmNlOiBSRkMgWFhYWA0KPiA+DQo+ID4NCj4gPiBUaGUgSUVURiBk YXRhdHJhY2tlciBzdGF0dXMgcGFnZSBmb3IgdGhpcyBkcmFmdCBpczoNCj4gPiBodHRwczovL2Rh dGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLWRvdHMtc2lnbmFsLWNoYW5uZWwvDQo+ ID4NCj4gPiBUaGVyZSBhcmUgYWxzbyBodG1saXplZCB2ZXJzaW9ucyBhdmFpbGFibGUgYXQ6DQo+ ID4gaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtZG90cy1zaWduYWwtY2hh bm5lbC0wOQ0KPiA+IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2h0bWwvZHJhZnQt aWV0Zi1kb3RzLXNpZ25hbC1jaGFubmVsLTANCj4gPiA5DQo+ID4NCj4gPiBBIGRpZmYgZnJvbSB0 aGUgcHJldmlvdXMgdmVyc2lvbiBpcyBhdmFpbGFibGUgYXQ6DQo+ID4gaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LWlldGYtZG90cy1zaWduYWwtY2hhbm5lbC0wOQ0KPiA+ DQo+ID4NCj4gPiBQbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291cGxlIG9mIG1pbnV0 ZXMgZnJvbSB0aGUgdGltZSBvZg0KPiA+IHN1Ym1pc3Npb24gdW50aWwgdGhlIGh0bWxpemVkIHZl cnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdA0KPiA+IHRvb2xzLmlldGYub3JnLg0KPiA+ DQo+ID4gSW50ZXJuZXQtRHJhZnRzIGFyZSBhbHNvIGF2YWlsYWJsZSBieSBhbm9ueW1vdXMgRlRQ IGF0Og0KPiA+IGZ0cDovL2Z0cC5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvDQo+ID4NCj4gPiBf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+IEktRC1B bm5vdW5jZSBtYWlsaW5nIGxpc3QNCj4gPiBJLUQtQW5ub3VuY2VAaWV0Zi5vcmc8bWFpbHRvOkkt RC1Bbm5vdW5jZUBpZXRmLm9yZz4NCj4gPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL2ktZC1hbm5vdW5jZQ0KPiA+IEludGVybmV0LURyYWZ0IGRpcmVjdG9yaWVzOiBodHRw Oi8vd3d3LmlldGYub3JnL3NoYWRvdy5odG1sIDxodHRwOi8vd3d3LmlldGYub3JnL3NoYWRvdy5o dG1sJTIwPiBvcg0KPiA+IGZ0cDovL2Z0cC5pZXRmLm9yZy9pZXRmLzFzaGFkb3ctc2l0ZXMudHh0 DQo+DQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ IERvdHMgbWFpbGluZyBsaXN0DQo+IERvdHNAaWV0Zi5vcmc8bWFpbHRvOkRvdHNAaWV0Zi5vcmc+ DQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZG90cw0KDQo+DQo+IF9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IERvdHMgbWFp bGluZyBsaXN0DQo+IERvdHNAaWV0Zi5vcmc8bWFpbHRvOkRvdHNAaWV0Zi5vcmc+DQo+IGh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZG90cw0KDQpfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KRG90cyBtYWlsaW5nIGxpc3QNCkRvdHNA aWV0Zi5vcmc8bWFpbHRvOkRvdHNAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL2RvdHMNCg== --_000_787AE7BB302AE849A7480A190F8B93300A083263OPEXCLILMA3corp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk6V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7 fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpXaW5nZGluZ3M7DQoJcGFub3NlLTE6NSAwIDAg MCAwIDAgMCAwIDAgMDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFu b3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpU YWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseTpWZXJkYW5hOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDMgNSA0IDQgMiA0O30NCi8q IFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNv Tm9ybWFsDQoJe21hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6 ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjt9DQphOmxp bmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpi bHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5 cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7 DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFuLkVtYWlsU3R5bGUxNw0KCXttc28t c3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ291cmllciBOZXciOw0K CWNvbG9yOmJsYWNrOw0KCWZvbnQtd2VpZ2h0Om5vcm1hbDsNCglmb250LXN0eWxlOm5vcm1hbDt9 DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNp emU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsN CgltYXJnaW46NzAuODVwdCA3MC44NXB0IDcwLjg1cHQgNzAuODVwdDt9DQpkaXYuV29yZFNlY3Rp b24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi8qIExpc3QgRGVmaW5pdGlvbnMgKi8NCkBsaXN0 IGwwDQoJe21zby1saXN0LWlkOjE2MjgxMjY3NDM7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOjEz MzIyNjgwNTQ7fQ0KQGxpc3QgbDA6bGV2ZWwxDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1 bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjM2LjBwdDsN Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsN Cgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlz dCBsMDpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZl bC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOjcyLjBwdDsNCgltc28tbGV2ZWwtbnVtYmVy LXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCgltc28tYW5zaS1mb250LXNp emU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7DQoJbXNvLWJpZGktZm9udC1m YW1pbHk6IlRpbWVzIE5ldyBSb21hbiI7fQ0KQGxpc3QgbDA6bGV2ZWwzDQoJe21zby1sZXZlbC1u dW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRh Yi1zdG9wOjEwOC4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQt aW5kZW50Oi0xOC4wcHQ7DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWls eTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDA6bGV2ZWw0DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0 OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjE0NC4w cHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4w cHQ7DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7 fQ0KQGxpc3QgbDA6bGV2ZWw1DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCglt c28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjE4MC4wcHQ7DQoJbXNvLWxl dmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJbXNvLWFu c2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDA6 bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4 dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjIxNi4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1w b3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJbXNvLWFuc2ktZm9udC1zaXpl OjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDA6bGV2ZWw3DQoJe21z by1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNv LWxldmVsLXRhYi1zdG9wOjI1Mi4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0 Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglm b250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDA6bGV2ZWw4DQoJe21zby1sZXZlbC1udW1i ZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1z dG9wOjI4OC4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5k ZW50Oi0xOC4wcHQ7DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpX aW5nZGluZ3M7fQ0KQGxpc3QgbDA6bGV2ZWw5DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1 bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjMyNC4wcHQ7 DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7 DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0K b2wNCgl7bWFyZ2luLWJvdHRvbTowY207fQ0KdWwNCgl7bWFyZ2luLWJvdHRvbTowY207fQ0KLS0+ PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9 ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBt c28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0 PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0K PC9oZWFkPg0KPGJvZHkgbGFuZz0iRlIiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRp diBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2Nv bG9yOmJsYWNrIj5IaSBOZXNyZWRpZW4sDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPlRoYW5r IHlvdSBmb3IgdGhlIHJldmlldy4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6Ymxh Y2siPldpbGwgYmUgZml4ZWQgaW4gdGhlIG5leHQgaXRlcmF0aW9uIG9mIHRoZSBkcmFmdCZuYnNw OzoNCjxhIGhyZWY9Imh0dHBzOi8vZ2l0aHViLmNvbS9kb3Rzd2cvZG90cy1zaWduYWwtY2hhbm5l bC9wdWxsLzkvZmlsZXMiPmh0dHBzOi8vZ2l0aHViLmNvbS9kb3Rzd2cvZG90cy1zaWduYWwtY2hh bm5lbC9wdWxsLzkvZmlsZXM8L2E+LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1 b3Q7O2NvbG9yOmJsYWNrIj5DaGVlcnMsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj5NZWQ8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVv dDs7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9 ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowY20gMGNt IDBjbSA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpz b2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkRlJm5ic3A7Ojwvc3Bh bj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFo b21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBOZXNyZWRpZW4gU3VsZWltYW4gW21h aWx0bzptaG5zYXNAeWFob28uY29tXQ0KPGJyPg0KPGI+RW52b3nDqSZuYnNwOzo8L2I+IG1lcmNy ZWRpIDI5IG5vdmVtYnJlIDIwMTcgMDk6NTg8YnI+DQo8Yj7DgCZuYnNwOzo8L2I+IEpvbiBTaGFs bG93OyBCT1VDQURBSVIgTW9oYW1lZCBJTVQvT0xOOyBkb3RzQGlldGYub3JnOyBLb25kYSwgVGly dW1hbGVzd2FyIFJlZGR5PGJyPg0KPGI+T2JqZXQmbmJzcDs6PC9iPiBSZTogW0RvdHNdIEktRCBB Y3Rpb246IGRyYWZ0LWlldGYtZG90cy1zaWduYWwtY2hhbm5lbC0wOS50eHQ8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LWZhbWlseTomcXVvdDtWZXJkYW5hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDsiPkhlbGxvIFRoZXJlLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtWZXJkYW5h JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZpcnN0IEkgd291bGQgbGlrZSB0byBleHBy ZXNzIG15IGFwcHJlY2lhdGlvbiB0byBldmVyeW9uZSB3aG8gaXMgY29udHJpYnV0aW5nIG9uIHRo aXMgZG9jdW1lbnQuIEkgYW0gZm9yd2FyZGluZyBteSBtaW5vciBjb21tZW50cyBhcyBmb2xsb3dz OjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjx1bCB0eXBlPSJkaXNjIj4N CjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEiPg0KPHNwYW4g c3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90OyI+VGhvdWdoIG1vc3Qgb2YgdGhlIHJlYWRlcnMgb2YgdGhlIGRvY3VtZW50IGFuZCBtZW1i ZXJzIG9mIHRoaXMgbWFpbGluZyBsaXN0IGFyZSBleHBlcnRzIGJ1dCB0aGVyZSBjb3VsZCBiZSBz b21lIHJlYWRlcnMgd2hvIG1heSBub3QgYmUgdGhhdCBleHBlcnQgc28gSSBiZWxpZXZlIGl0IHdv dWxkIGJlIGJldHRlciBpZiBzb21lIGFjcm9ueW1zIGFuZCBhYmJyZXZpYXRpb25zDQogYXJlIHdy aXR0ZW4gaW4gZnVsbCBmb3JtIG9uIHRoZWlyIGZpcnN0IHVzYWdlIGFzIGl0IGlzIGRvbmUgZm9y IG90aGVycyBzdWNoIGFzIEREb1MuIE9uIFBhZ2UgNCBvbiB0aGUgTmV0d29yayBkaWFncmFtIHRo ZXJlIGlzIGFuIGFjcm9ueW0gQ1BFPG86cD48L286cD48L3NwYW4+PC9saT48bGkgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvO21zby1saXN0OmwwIGxldmVsMSBsZm8xIj4NCjxzcGFuIHN0eWxlPSJmb250LWZh bWlseTomcXVvdDtWZXJkYW5hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkl0IHdvdWxk IGhhdmUgYmVlbiBnb29kIGlmIHRoZSBuZXR3b3JrIGRpYWdyYW0gaXMgZXhwbGFpbmVkIGEgYml0 LjxvOnA+PC9vOnA+PC9zcGFuPjwvbGk+PGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttc28tbGlzdDps MCBsZXZlbDEgbGZvMSI+DQo8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5PbiBQYWdlIDQgbGFzdCBwYXJhZ3JhcGggYXQg dGhpcmQgbGluZSwgdGhlcmUgaXMgZ3JhbW1hdGljYWwgZXJyb3Igb24gdGhlIHBocmFzZSAmcXVv dDtPcGVyYXRlZCBieSBhbiBkb21haW4mcXVvdDsgSSBiZWxpZXZlIGl0IHNob3VsZCBiZSAmcXVv dDtPcGVyYXRlZCBieSBhIGRvbWFpbiZxdW90Oy48bzpwPjwvbzpwPjwvc3Bhbj48L2xpPjxsaSBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG87bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEiPg0KPHNwYW4gc3R5bGU9 ImZvbnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+ QXQgc2VjdGlvbiA0LjIgQ29BUCBVUklzLCBUYWJsZSAxIGlzIG5vdCBzaXRlZCBpbiB0aGUgZG9j dW1lbnQuPG86cD48L286cD48L3NwYW4+PC9saT48L3VsPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtWZXJkYW5hJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDsiPkJlc3QgcmVnYXJkcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LWZhbWlseTomcXVvdDtWZXJkYW5hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPk5l c3JlZGllbjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtWZXJkYW5hJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTom cXVvdDtWZXJkYW5hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdiBpZD0ieWFob29fcXVvdGVkXzIyNjgzNzQzMDci Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMjYyODJBIj5PbiBUdWVzZGF5LCBOb3ZlbWJlciAyOCwgMjAxNywg MjowMDozNSBQTSBHTVQmIzQzOzMsIEtvbmRhLCBUaXJ1bWFsZXN3YXIgUmVkZHkgJmx0OzxhIGhy ZWY9Im1haWx0bzpUaXJ1bWFsZXN3YXJSZWRkeV9Lb25kYUBNY0FmZWUuY29tIj5UaXJ1bWFsZXN3 YXJSZWRkeV9Lb25kYUBNY0FmZWUuY29tPC9hPiZndDsNCiB3cm90ZTogPG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzI2MjgyQSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzI2MjgyQSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMyNjI4MkEiPlRoYW5rcyBKb24sIGZpeGVkIGJvdGgg Tml0cyAodXBsb2FkZWQgcmV2aXNpb24gdG8gZ2l0aHViKS4NCjxicj4NCjxicj4NCi1UaXJ1PGJy Pg0KPGJyPg0KJmd0OyAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxicj4NCiZndDsgRnJvbTog RG90cyBbbWFpbHRvOjxhIGhyZWY9Im1haWx0bzpkb3RzLWJvdW5jZXNAaWV0Zi5vcmciPmRvdHMt Ym91bmNlc0BpZXRmLm9yZzwvYT5dIE9uIEJlaGFsZiBPZiBKb24gU2hhbGxvdzxicj4NCiZndDsg U2VudDogVHVlc2RheSwgTm92ZW1iZXIgMjgsIDIwMTcgNDowOSBQTTxicj4NCiZndDsgVG86IDxh IGhyZWY9Im1haWx0bzptb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tIj5tb2hhbWVkLmJvdWNh ZGFpckBvcmFuZ2UuY29tPC9hPjsNCjxhIGhyZWY9Im1haWx0bzpkb3RzQGlldGYub3JnIj5kb3Rz QGlldGYub3JnPC9hPjxicj4NCiZndDsgU3ViamVjdDogUmU6IFtEb3RzXSBJLUQgQWN0aW9uOiBk cmFmdC1pZXRmLWRvdHMtc2lnbmFsLWNoYW5uZWwtMDkudHh0PGJyPg0KJmd0OyA8YnI+DQomZ3Q7 IEkgbGlrZSB0aGUgcmVmb3JtYXR0aW5nIGFuZCB1c2Ugb2YgbWl0aWdhdGlvbiBpbnN0ZWFkIG9m IHNpZ25hbCBpbiB0aGU8YnI+DQomZ3Q7IGFwcHJvcHJpYXRlIHBsYWNlcy48YnI+DQomZ3Q7IDxi cj4NCiZndDsgTml0czxicj4NCiZndDsgPGJyPg0KJmd0OyBUYWJsZSAyOjxicj4NCiZndDsgJnF1 b3Q7RE9UUyBjbGllbnQgYW4gd2l0aGRyYXcmcXVvdDsgc2hvdWxkIGJlICZxdW90O0RPVFMgY2xp ZW50IGNhbiB3aXRoZHJhdyZxdW90Ozxicj4NCiZndDsgPGJyPg0KJmd0OyBGaWd1cmUgMTI6PGJy Pg0KJmd0OyBJdCB3b3VsZCBiZSBnb29kIHRvIGFkZCBpbiB0aGUgb3B0aW9uIElmLU1hdGNoIGlu IHRoZSBleGFtcGxlIC0gaS5lLjxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyBIZWFkZXI6 IFBVVCAoQ29kZT0wLjAzKTxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyBVcmktSG9zdDog JnF1b3Q7aG9zdCZxdW90Ozxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyBVcmktUGF0aDog JnF1b3Q7LndlbGwta25vd24mcXVvdDs8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgVXJp LVBhdGg6ICZxdW90O2RvdHMmcXVvdDs8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgVXJp LVBhdGg6ICZxdW90O3ZlcnNpb24mcXVvdDs8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsg VXJpLVBhdGg6ICZxdW90O21pdGlnYXRlJnF1b3Q7PGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5i c3A7IENvbnRlbnQtRm9ybWF0OiAmcXVvdDthcHBsaWNhdGlvbi9jYm9yJnF1b3Q7PGJyPg0KJmd0 OyZuYnNwOyAmbmJzcDsgJm5ic3A7IElmLU1hdGNoOjxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZu YnNwOyB7PGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmcXVvdDttaXRpZ2F0 aW9uLXNjb3BlJnF1b3Q7OiB7PGJyPg0KJmd0OyA8YnI+DQomZ3Q7IFJlZ2FyZHM8YnI+DQomZ3Q7 IDxicj4NCiZndDsgSm9uPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IC0tLS0tT3JpZ2luYWwgTWVzc2Fn ZS0tLS0tPGJyPg0KJmd0OyBGcm9tOiBEb3RzIFttYWlsdG86IDxhIGhyZWY9Im1haWx0bzpkb3Rz LWJvdW5jZXNAaWV0Zi5vcmciPmRvdHMtYm91bmNlc0BpZXRmLm9yZzwvYT5dIE9uIEJlaGFsZiBP ZiBpZXRmLXN1cGpwcy08YnI+DQomZ3Q7IDxhIGhyZWY9Im1haWx0bzptb2hhbWVkLmJvdWNhZGFp ckBvcmFuZ2UuY29tIj5tb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tPC9hPjxicj4NCiZndDsg U2VudDogMjggTm92ZW1iZXIgMjAxNyAwOToxODxicj4NCiZndDsgVG86IDxhIGhyZWY9Im1haWx0 bzpkb3RzQGlldGYub3JnIj5kb3RzQGlldGYub3JnPC9hPjxicj4NCiZndDsgU3ViamVjdDogUmU6 IFtEb3RzXSBJLUQgQWN0aW9uOiBkcmFmdC1pZXRmLWRvdHMtc2lnbmFsLWNoYW5uZWwtMDkudHh0 PGJyPg0KJmd0OyA8YnI+DQomZ3Q7IEhpIGFsbCw8YnI+DQomZ3Q7IDxicj4NCiZndDsgV2UgdHJp ZWQgdG8gcmVvcmdhbml6ZSB0aGUgY29udGVudCBvZiB0aGUgZHJhZnQgZm9yIGEgYmV0dGVyIHJl YWRhYmlsaXR5LiBXZTxicj4NCiZndDsgYWxzbyBmaXhlZCBtYW55IG5pdHMgYW5kIGNoZWNrZWQg dGhlIGNvbnNpc3RlbmN5IG9mIHRoZSBvdmVyYWxsIGRvY3VtZW50Ljxicj4NCiZndDsgPGJyPg0K Jmd0OyBUaGUgb25seSBwZW5kaW5nIGlzc3VlIHNvIGZhciBpcyBob3cgdG8gaGFuZGxlIGNvbmZs aWN0cyBhbW9uZyBkb3RzIGNsaWVudHMuPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IDxicj4NCiZndDsg UGxlYXNlIHJldmlldyBhbmQgc2hhcmUgeW91ciBjb21tZW50cy48YnI+DQomZ3Q7IDxicj4NCiZn dDsgQ2hlZXJzLDxicj4NCiZndDsgTWVkPGJyPg0KJmd0OyA8YnI+DQomZ3Q7ICZndDsgLS0tLS1N ZXNzYWdlIGQnb3JpZ2luZS0tLS0tPGJyPg0KJmd0OyAmZ3Q7IERlJm5ic3A7OiBJLUQtQW5ub3Vu Y2UgW21haWx0bzo8YSBocmVmPSJtYWlsdG86aS1kLWFubm91bmNlLWJvdW5jZXNAaWV0Zi5vcmci PmktZC1hbm5vdW5jZS1ib3VuY2VzQGlldGYub3JnPC9hPl0gRGUgbGEgcGFydCBkZTxicj4NCiZn dDsgJmd0OyA8YSBocmVmPSJtYWlsdG86aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnIj5pbnRlcm5l dC1kcmFmdHNAaWV0Zi5vcmc8L2E+IEVudm95w6kmbmJzcDs6IG1hcmRpIDI4IG5vdmVtYnJlIDIw MTcgMTA6MDggw4AmbmJzcDs6PGJyPg0KJmd0OyAmZ3Q7IDxhIGhyZWY9Im1haWx0bzppLWQtYW5u b3VuY2VAaWV0Zi5vcmciPmktZC1hbm5vdW5jZUBpZXRmLm9yZzwvYT4gQ2MmbmJzcDs6IDxhIGhy ZWY9Im1haWx0bzpkb3RzQGlldGYub3JnIj4NCmRvdHNAaWV0Zi5vcmc8L2E+IE9iamV0Jm5ic3A7 OiBJLUQgQWN0aW9uOjxicj4NCiZndDsgJmd0OyBkcmFmdC1pZXRmLWRvdHMtc2lnbmFsLWNoYW5u ZWwtMDkudHh0PGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7IEEg TmV3IEludGVybmV0LURyYWZ0IGlzIGF2YWlsYWJsZSBmcm9tIHRoZSBvbi1saW5lIEludGVybmV0 LURyYWZ0czxicj4NCiZndDsgJmd0OyBkaXJlY3Rvcmllcy48YnI+DQomZ3Q7ICZndDsgVGhpcyBk cmFmdCBpcyBhIHdvcmsgaXRlbSBvZiB0aGUgRERvUyBPcGVuIFRocmVhdCBTaWduYWxpbmcgV0cg b2YgdGhlPGJyPg0KJmd0OyAmZ3Q7IElFVEYuPGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7 Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IFRpdGxlJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyA6IERpc3RyaWJ1dGVkIERlbmlhbC1vZi1TZXJ2aWNlIE9wZW4gVGhyZWF0PGJy Pg0KJmd0OyAmZ3Q7IFNpZ25hbGluZyAoRE9UUykgU2lnbmFsIENoYW5uZWw8YnI+DQomZ3Q7ICZn dDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgQXV0aG9ycyZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyA6IFRpcnVtYWxlc3dhciBSZWRkeTxicj4NCiZndDsgJmd0OyZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyBNb2hhbWVkIEJvdWNhZGFpcjxicj4NCiZndDsgJmd0OyZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBQcmFzaGFudGggUGF0aWw8YnI+DQomZ3Q7ICZn dDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgQW5kcmV3IE1vcnRlbnNlbjxicj4N CiZndDsgJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBOaWsgVGVhZ3VlPGJy Pg0KJmd0OyAmZ3Q7ICZuYnNwOyZuYnNwOyZuYnNwOyBGaWxlbmFtZSZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyA6IGRyYWZ0LWlldGYtZG90cy1zaWduYWwtY2hhbm5lbC0wOS50eHQ8YnI+DQom Z3Q7ICZndDsgJm5ic3A7Jm5ic3A7Jm5ic3A7IFBhZ2VzJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyA6IDY0PGJyPg0KJmd0OyAmZ3Q7ICZuYnNwOyZuYnNwOyZuYnNwOyBEYXRlJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgOiAyMDE3LTExLTI4PGJyPg0K Jmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7IEFic3RyYWN0Ojxicj4NCiZndDsgJmd0OyZuYnNwOyAm bmJzcDsgVGhpcyBkb2N1bWVudCBzcGVjaWZpZXMgdGhlIERPVFMgc2lnbmFsIGNoYW5uZWwsIGEg cHJvdG9jb2wgZm9yPGJyPg0KJmd0OyAmZ3Q7Jm5ic3A7ICZuYnNwOyBzaWduYWxpbmcgdGhlIG5l ZWQgZm9yIHByb3RlY3Rpb24gYWdhaW5zdCBEaXN0cmlidXRlZCBEZW5pYWwtb2YtPGJyPg0KJmd0 OyAmZ3Q7Jm5ic3A7ICZuYnNwOyBTZXJ2aWNlIChERG9TKSBhdHRhY2tzIHRvIGEgc2VydmVyIGNh cGFibGUgb2YgZW5hYmxpbmcgbmV0d29yazxicj4NCiZndDsgJmd0OyZuYnNwOyAmbmJzcDsgdHJh ZmZpYyBtaXRpZ2F0aW9uIG9uIGJlaGFsZiBvZiB0aGUgcmVxdWVzdGluZyBjbGllbnQuPGJyPg0K Jmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7Jm5ic3A7ICZuYnNwOyBBIGNvbXBhbmlvbiBkb2N1bWVu dCBkZWZpbmVzIHRoZSBET1RTIGRhdGEgY2hhbm5lbCwgYSBzZXBhcmF0ZTxicj4NCiZndDsgJmd0 OyZuYnNwOyAmbmJzcDsgcmVsaWFibGUgY29tbXVuaWNhdGlvbiBsYXllciBmb3IgRE9UUyBtYW5h Z2VtZW50IGFuZCBjb25maWd1cmF0aW9uLjxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyBF ZGl0b3JpYWwgTm90ZSAoVG8gYmUgcmVtb3ZlZCBieSBSRkMgRWRpdG9yKTxicj4NCiZndDsgJmd0 Ozxicj4NCiZndDsgJmd0OyZuYnNwOyAmbmJzcDsgUGxlYXNlIHVwZGF0ZSB0aGVzZSBzdGF0ZW1l bnRzIHdpdGggdGhlIFJGQyBudW1iZXIgdG8gYmUgYXNzaWduZWQgdG88YnI+DQomZ3Q7ICZndDsm bmJzcDsgJm5ic3A7IHRoaXMgZG9jdW1lbnQ6PGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7 Jm5ic3A7ICZuYnNwOyBvJm5ic3A7ICZxdW90O1RoaXMgdmVyc2lvbiBvZiB0aGlzIFlBTkcgbW9k dWxlIGlzIHBhcnQgb2YgUkZDIFhYWFg7JnF1b3Q7PGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAm Z3Q7Jm5ic3A7ICZuYnNwOyBvJm5ic3A7ICZxdW90O1JGQyBYWFhYOiBEaXN0cmlidXRlZCBEZW5p YWwtb2YtU2VydmljZSBPcGVuIFRocmVhdCBTaWduYWxpbmc8YnI+DQomZ3Q7ICZndDsmbmJzcDsg Jm5ic3A7ICZuYnNwOyAoRE9UUykgU2lnbmFsIENoYW5uZWwmcXVvdDs7PGJyPg0KJmd0OyAmZ3Q7 PGJyPg0KJmd0OyAmZ3Q7Jm5ic3A7ICZuYnNwOyBvJm5ic3A7ICZxdW90O3wgMy4wMCB8IEFsdGVy bmF0ZSBzZXJ2ZXIgfCBbUkZDWFhYWF0gfCZxdW90Ozxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsg Jmd0OyZuYnNwOyAmbmJzcDsgbyZuYnNwOyByZWZlcmVuY2U6IFJGQyBYWFhYPGJyPg0KJmd0OyAm Z3Q7PGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7IFRoZSBJRVRGIGRhdGF0cmFja2VyIHN0 YXR1cyBwYWdlIGZvciB0aGlzIGRyYWZ0IGlzOjxicj4NCiZndDsgJmd0OyA8YSBocmVmPSJodHRw czovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLWRvdHMtc2lnbmFsLWNoYW5u ZWwvIiB0YXJnZXQ9Il9ibGFuayI+DQpodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9k cmFmdC1pZXRmLWRvdHMtc2lnbmFsLWNoYW5uZWwvPC9hPjxicj4NCiZndDsgJmd0Ozxicj4NCiZn dDsgJmd0OyBUaGVyZSBhcmUgYWxzbyBodG1saXplZCB2ZXJzaW9ucyBhdmFpbGFibGUgYXQ6PGJy Pg0KJmd0OyAmZ3Q7IDxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1p ZXRmLWRvdHMtc2lnbmFsLWNoYW5uZWwtMDkiIHRhcmdldD0iX2JsYW5rIj4NCmh0dHBzOi8vdG9v bHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWRvdHMtc2lnbmFsLWNoYW5uZWwtMDk8L2E+PGJy Pg0KJmd0OyAmZ3Q7IDxhIGhyZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2h0 bWwvZHJhZnQtaWV0Zi1kb3RzLXNpZ25hbC1jaGFubmVsLTAiIHRhcmdldD0iX2JsYW5rIj4NCmh0 dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2h0bWwvZHJhZnQtaWV0Zi1kb3RzLXNpZ25h bC1jaGFubmVsLTA8L2E+PGJyPg0KJmd0OyAmZ3Q7IDk8YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7 ICZndDsgQSBkaWZmIGZyb20gdGhlIHByZXZpb3VzIHZlcnNpb24gaXMgYXZhaWxhYmxlIGF0Ojxi cj4NCiZndDsgJmd0OyA8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9 ZHJhZnQtaWV0Zi1kb3RzLXNpZ25hbC1jaGFubmVsLTA5IiB0YXJnZXQ9Il9ibGFuayI+DQpodHRw czovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtaWV0Zi1kb3RzLXNpZ25hbC1jaGFu bmVsLTA5PC9hPjxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyBQ bGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUg dGltZSBvZjxicj4NCiZndDsgJmd0OyBzdWJtaXNzaW9uIHVudGlsIHRoZSBodG1saXplZCB2ZXJz aW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQ8YnI+DQomZ3Q7ICZndDsgdG9vbHMuaWV0Zi5v cmcuPGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7IEludGVybmV0LURyYWZ0cyBhcmUgYWxz byBhdmFpbGFibGUgYnkgYW5vbnltb3VzIEZUUCBhdDo8YnI+DQomZ3Q7ICZndDsgPGEgaHJlZj0i ZnRwOi8vZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy8iIHRhcmdldD0iX2JsYW5rIj5mdHA6 Ly9mdHAuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzLzwvYT48YnI+DQomZ3Q7ICZndDs8YnI+DQom Z3Q7ICZndDsgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188 YnI+DQomZ3Q7ICZndDsgSS1ELUFubm91bmNlIG1haWxpbmcgbGlzdDxicj4NCiZndDsgJmd0OyA8 YSBocmVmPSJtYWlsdG86SS1ELUFubm91bmNlQGlldGYub3JnIj5JLUQtQW5ub3VuY2VAaWV0Zi5v cmc8L2E+PGJyPg0KJmd0OyAmZ3Q7IDxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vaS1kLWFubm91bmNlIiB0YXJnZXQ9Il9ibGFuayI+DQpodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2ktZC1hbm5vdW5jZTwvYT48YnI+DQomZ3Q7ICZndDsg SW50ZXJuZXQtRHJhZnQgZGlyZWN0b3JpZXM6IDxhIGhyZWY9Imh0dHA6Ly93d3cuaWV0Zi5vcmcv c2hhZG93Lmh0bWwlMjAiIHRhcmdldD0iX2JsYW5rIj4NCmh0dHA6Ly93d3cuaWV0Zi5vcmcvc2hh ZG93Lmh0bWwgPC9hPm9yPGJyPg0KJmd0OyAmZ3Q7IDxhIGhyZWY9ImZ0cDovL2Z0cC5pZXRmLm9y Zy9pZXRmLzFzaGFkb3ctc2l0ZXMudHh0IiB0YXJnZXQ9Il9ibGFuayI+ZnRwOi8vZnRwLmlldGYu b3JnL2lldGYvMXNoYWRvdy1zaXRlcy50eHQ8L2E+PGJyPg0KJmd0OyA8YnI+DQomZ3Q7IF9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KJmd0OyBEb3Rz IG1haWxpbmcgbGlzdDxicj4NCiZndDsgPGEgaHJlZj0ibWFpbHRvOkRvdHNAaWV0Zi5vcmciPkRv dHNAaWV0Zi5vcmc8L2E+PGJyPg0KJmd0OyA8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL2RvdHMiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL2RvdHM8L2E+PG86cD48L286cD48L3NwYW4+PC9wPg0KPGRpdiBp ZD0ieXF0ZmQxNDc4NCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMjYyODJBIj48YnI+DQomZ3Q7IDxicj4NCiZndDsgX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQomZ3Q7IERvdHMgbWFp bGluZyBsaXN0PGJyPg0KJmd0OyA8YSBocmVmPSJtYWlsdG86RG90c0BpZXRmLm9yZyI+RG90c0Bp ZXRmLm9yZzwvYT48YnI+DQomZ3Q7IDxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vZG90cyIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vZG90czwvYT48YnI+DQo8YnI+DQpfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCkRvdHMgbWFpbGluZyBsaXN0PGJyPg0KPGEg aHJlZj0ibWFpbHRvOkRvdHNAaWV0Zi5vcmciPkRvdHNAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJl Zj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kb3RzIiB0YXJnZXQ9Il9i bGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kb3RzPC9hPjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_787AE7BB302AE849A7480A190F8B93300A083263OPEXCLILMA3corp_-- From nobody Wed Nov 29 06:48:36 2017 Return-Path: X-Original-To: dots@ietf.org Delivered-To: dots@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id EF3D812711B; Wed, 29 Nov 2017 06:48:34 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: dots@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.66.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151196691495.8078.13426270131975196318@ietfa.amsl.com> Date: Wed, 29 Nov 2017 06:48:34 -0800 Archived-At: Subject: [Dots] I-D Action: draft-ietf-dots-data-channel-09.txt X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.22 List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Nov 2017 14:48:35 -0000 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 : Distributed Denial-of-Service Open Threat Signaling (DOTS) Data Channel Authors : Tirumaleswar Reddy Mohamed Boucadair Kaname Nishizuka Liang Xia Prashanth Patil Andrew Mortensen Nik Teague Filename : draft-ietf-dots-data-channel-09.txt Pages : 30 Date : 2017-11-29 Abstract: The document specifies a Distributed Denial-of-Service Open Threat Signaling (DOTS) data channel used for bulk exchange of data not easily or appropriately communicated through the DOTS signal channel under attack conditions. This is a companion document to the DOTS signal channel specification. Editorial Note (To be removed by RFC Editor) Please update these statements 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: Distributed Denial-of-Service Open Threat Signaling (DOTS) Data Channel"; o reference: RFC XXXX The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dots-data-channel/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-dots-data-channel-09 https://datatracker.ietf.org/doc/html/draft-ietf-dots-data-channel-09 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dots-data-channel-09 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/ From nobody Wed Nov 29 06:53:28 2017 Return-Path: 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 DFF8F126C25 for ; Wed, 29 Nov 2017 06:53:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.619 X-Spam-Level: X-Spam-Status: No, score=-2.619 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no 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 WswWn7DcpfLE for ; Wed, 29 Nov 2017 06:53:25 -0800 (PST) Received: from orange.com (mta134.mail.business.static.orange.com [80.12.70.34]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F316B1243F6 for ; Wed, 29 Nov 2017 06:53:24 -0800 (PST) Received: from opfednr04.francetelecom.fr (unknown [xx.xx.xx.68]) by opfednr27.francetelecom.fr (ESMTP service) with ESMTP id 3822BA04DE for ; Wed, 29 Nov 2017 15:53:23 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.3]) by opfednr04.francetelecom.fr (ESMTP service) with ESMTP id 6D0DA4005D for ; Wed, 29 Nov 2017 15:53:23 +0100 (CET) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM5D.corporate.adroot.infra.ftgroup ([fe80::9898:741c:bc1d:258d%19]) with mapi id 14.03.0361.001; Wed, 29 Nov 2017 15:53:22 +0100 From: To: "dots@ietf.org" Thread-Topic: [Dots] I-D Action: draft-ietf-dots-data-channel-09.txt Thread-Index: AQHTaSElGwrey/7ugU+IwlRuGIFzyKMrcHxg Date: Wed, 29 Nov 2017 14:53:22 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93300A083370@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <151196691495.8078.13426270131975196318@ietfa.amsl.com> In-Reply-To: <151196691495.8078.13426270131975196318@ietfa.amsl.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.4] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Dots] I-D Action: draft-ietf-dots-data-channel-09.txt 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Nov 2017 14:53:27 -0000 Hi all, This new version integrates the comments received so far and the following = changes: - Reorganize the content of the document - Update the YANG module to pass validation - Update the IANA section with YANG required actions - Update the security section with RESTCONF considerations.=20 Your comments are more than welcome, as usual.=20 Cheers, Med > -----Message d'origine----- > De=A0: Dots [mailto:dots-bounces@ietf.org] De la part de internet- > drafts@ietf.org > Envoy=E9=A0: mercredi 29 novembre 2017 15:49 > =C0=A0: i-d-announce@ietf.org > Cc=A0: dots@ietf.org > Objet=A0: [Dots] I-D Action: draft-ietf-dots-data-channel-09.txt >=20 >=20 > 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. >=20 > Title : Distributed Denial-of-Service Open Threat > Signaling (DOTS) Data Channel > Authors : Tirumaleswar Reddy > Mohamed Boucadair > Kaname Nishizuka > Liang Xia > Prashanth Patil > Andrew Mortensen > Nik Teague > Filename : draft-ietf-dots-data-channel-09.txt > Pages : 30 > Date : 2017-11-29 >=20 > Abstract: > The document specifies a Distributed Denial-of-Service Open Threat > Signaling (DOTS) data channel used for bulk exchange of data not > easily or appropriately communicated through the DOTS signal channel > under attack conditions. >=20 > This is a companion document to the DOTS signal channel > specification. >=20 > Editorial Note (To be removed by RFC Editor) >=20 > Please update these statements with the RFC number to be assigned to > this document: >=20 > o "This version of this YANG module is part of RFC XXXX;" >=20 > o "RFC XXXX: Distributed Denial-of-Service Open Threat Signaling > (DOTS) Data Channel"; >=20 > o reference: RFC XXXX >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-dots-data-channel/ >=20 > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-dots-data-channel-09 > https://datatracker.ietf.org/doc/html/draft-ietf-dots-data-channel-09 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dots-data-channel-09 >=20 >=20 > 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. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > Dots mailing list > Dots@ietf.org > https://www.ietf.org/mailman/listinfo/dots From nobody Thu Nov 30 01:41:55 2017 Return-Path: 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 5119D128DF3 for ; Thu, 30 Nov 2017 01:41:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.319 X-Spam-Level: X-Spam-Status: No, score=-4.319 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 0KU2n1fK1cLS for ; Thu, 30 Nov 2017 01:41:48 -0800 (PST) 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 5058A127601 for ; Thu, 30 Nov 2017 01:41:48 -0800 (PST) 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=1512034883; 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: x-originating-ip:x-ms-publictraffictype:x-microsoft-exchange-diagnostics: x-ms-exchange-antispam-srfa-diagnostics:x-ms-office365-filtering-correlation-id: x-microsoft-antispam:x-ms-traffictypediagnostic: x-microsoft-antispam-prvs:x-exchange-antispam-report-test: x-exchange-antispam-report-cfa-test:x-forefront-prvs: x-forefront-antispam-report:received-spf:authentication-results: spamdiagnosticoutput:spamdiagnosticmetadata: Content-Type: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-Transport-CrossTenantHeadersStamped: X-OriginatorOrg:X-NAI-Spam-Flag:X-NAI-Spam-Level: X-NAI-Spam-Threshold:X-NAI-Spam-Score:X-NAI-Spam-Version; bh=l+eItnKgww0vlSXcvhxfIi0J6QL3o+wn9LmXC1 4bD/I=; b=PSgcomDE69xgsHP5L+foglY2PZkLrcncZphLLz++ kvSnN6HKMf0RzZD+pVpPM2DlBN2pi0bzPu4BgbF0mVfqAhEXDc jrLUDTcKhDV/K3bFeDgriuKkOWx3DboEn2JsHs+948+7bM/i1c e+zxNviYRpSAH7t7IP63PGft92xi36o= Received: from DNVEXAPP1N06.corpzone.internalzone.com (unknown [10.44.48.90]) by DNVWSMAILOUT1.mcafee.com with smtp id 2d41_c411_d8309d74_f17a_4077_9e79_d0955941598d; Thu, 30 Nov 2017 03:41:22 -0600 Received: from DNVEXUSR1N09.corpzone.internalzone.com (10.44.48.82) by DNVEXAPP1N06.corpzone.internalzone.com (10.44.48.90) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Thu, 30 Nov 2017 02:41:17 -0700 Received: from DNVO365EDGE2.corpzone.internalzone.com (10.44.176.74) by DNVEXUSR1N09.corpzone.internalzone.com (10.44.48.82) with Microsoft SMTP Server (TLS) id 15.0.1347.2 via Frontend Transport; Thu, 30 Nov 2017 02:41:17 -0700 Received: from NAM02-BL2-obe.outbound.protection.outlook.com (10.44.176.242) by edge.mcafee.com (10.44.176.74) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Thu, 30 Nov 2017 02:41:17 -0700 Received: from DM5PR16MB1788.namprd16.prod.outlook.com (10.172.44.144) by DM5PR16MB1788.namprd16.prod.outlook.com (10.172.44.144) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.260.4; Thu, 30 Nov 2017 09:41:15 +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.20.0260.007; Thu, 30 Nov 2017 09:41:15 +0000 From: "Konda, Tirumaleswar Reddy" To: "mohamed.boucadair@orange.com" , Jon Shallow , "dots@ietf.org" Thread-Topic: [Dots] signal-channel: Conflict detection and notification Thread-Index: AQI5QycoOO+6Sl3hDoQKXRH887G99aJd55JwgAAKs5CAABDPgIAAEDEAgAAM/YCAAAnqQIAACYkAgADteRCAABAggIABvsNQ Date: Thu, 30 Nov 2017 09:41:15 +0000 Message-ID: References: <787AE7BB302AE849A7480A190F8B93300A07F4E4@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <009b01d3683a$c6158f90$5240aeb0$@jpshallow.com> <00e201d36844$b1b39ec0$151adc40$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93300A0819DB@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <011301d36853$48efb680$dacf2380$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93300A081B18@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93300A08307A@OPEXCLILMA3.corporate.adroot.infra.ftgroup> In-Reply-To: <787AE7BB302AE849A7480A190F8B93300A08307A@OPEXCLILMA3.corporate.adroot.infra.ftgroup> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [103.245.47.20] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DM5PR16MB1788; 6:sjryuzKMOLP7ZPBiFeK2YARH+qP2MtKR0N9Z7Hc7TeKwW3B2SCDIXGcuciw/n7YMzTq3kOGlHlJjwG38GGlWAxtd1oBPT2SNfTl2BAj5t7eJaEKzuFzX+fCEMinYpmIAL31neTXTOoZZ4JdEw/L4g7/ILQv9OHcoxpdr7kxtut3YfmVlG0TDDAGRHGNNUcwX0je2wbrQgVrmFthz9uXGSsP4naAWo5zb6h/kGt0GIo1ysHE8zJJh1W5l7Vrb3m2PtJ3UXun67SIHOeeXbSooeX0HLxvCK9hXEU7jfHYaQp8MeYh/QTnYXSP8usl33WQjrcn8R+lrAIm9FX7MLjITV+mUY5SAN/RM2oBk6dlxCPo=; 5:KC4Gv0vy0l1duKzUiAvkRE7qy8AGs3iQC7f5m3s4SPYYx6klYPuHL6XCj9TN8SwBfaJAKiMBRhKl3IvRaOZ/tuahWuDVYqxK8eOMvznmkKGCARtOaTEsScPc57U7AuusxiERZseu0699mW0N0mK672SAQWydYDCQb+Qf8DNooyE=; 24:j5BvIngL70iEK9/k/38kvEsgVutvYWnvUWyHIJxOu28f/Wh3lXb2aBT8Z4+05AMF7HJr+UMyBcZek6y5BsWKIrRbHrNNr8axmyR9LJH6FjY=; 7:86CvdW7HanxQuayzK7D9ldB48UyxAfBS06t6PHc2cHe34RStX7ArlWFDSt0n7ZSIU2mYwfhUSv5VJkszRc8VOqTEiJHMZPlBIaMf+o7Ga5kUrJVfISddbUDw+nZ86of5hf1x6BcI8wC3FdjANl+QPqcc7IhoBSHmRs9o4qrG4crIt32TIDDgwaKwUtA5Rkj6/kqWlA4AEN2tJv02N0QlvX2tkSlFwS4vRGxCMSVeZBJ7xqCYMyzf/ZfJP9m9pXPg x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: d1d2fc84-7846-4209-ce9d-08d537d68010 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(5600026)(4604075)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(2017052603284); SRVR:DM5PR16MB1788; x-ms-traffictypediagnostic: DM5PR16MB1788: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(190756311086443)(158342451672863)(20558992708506)(227612066756510)(18271650672692)(21748063052155)(211171220733660)(123452027830198); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(2401047)(8121501046)(5005006)(10201501046)(3002001)(93006095)(93001095)(3231022)(6041248)(20161123558100)(20161123555025)(20161123564025)(20161123562025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123560025)(6072148)(201708071742011); SRVR:DM5PR16MB1788; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:DM5PR16MB1788; x-forefront-prvs: 05079D8470 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39860400002)(376002)(346002)(366004)(53754006)(32952001)(199003)(189002)(51444003)(236005)(189998001)(561944003)(7110500001)(33656002)(106356001)(6506006)(105586002)(2900100001)(55016002)(2906002)(790700001)(3846002)(6116002)(2501003)(10710500007)(3280700002)(54356010)(14454004)(50986010)(76176010)(3660700001)(110136005)(478600001)(966005)(68736007)(606006)(15650500001)(72206003)(102836003)(8936002)(7696005)(93886005)(2420400007)(25786009)(316002)(80792005)(99286004)(97736004)(8676002)(7736002)(345774005)(81166006)(74316002)(6436002)(81156014)(229853002)(54896002)(101416001)(53946003)(66066001)(53936002)(2950100002)(77096006)(6246003)(86362001)(19609705001)(53546010)(6306002)(5660300001)(9686003)(85282002)(579004); DIR:OUT; SFP:1101; SCL:1; SRVR:DM5PR16MB1788; H:DM5PR16MB1788.namprd16.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: McAfee.com does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=TirumaleswarReddy_Konda@McAfee.com; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_DM5PR16MB1788206AD0A7E19CD9840622EA380DM5PR16MB1788namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: d1d2fc84-7846-4209-ce9d-08d537d68010 X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Nov 2017 09:41:15.2344 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4943e38c-6dd4-428c-886d-24932bc2d5de X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR16MB1788 X-OriginatorOrg: mcafee.com X-NAI-Spam-Flag: NO X-NAI-Spam-Level: X-NAI-Spam-Threshold: 15 X-NAI-Spam-Score: 0.9 X-NAI-Spam-Version: 2.3.0.9418 : core <6169> : inlines <6195> : streams <1771756> : uri <2542624> Archived-At: Subject: Re: [Dots] signal-channel: Conflict detection and notification 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Nov 2017 09:41:52 -0000 --_000_DM5PR16MB1788206AD0A7E19CD9840622EA380DM5PR16MB1788namp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable The proposal works for me, is the plan to add 7, 8 and 9 status or add a ne= w "additional-status" parameter ? -Tiru From: mohamed.boucadair@orange.com [mailto:mohamed.boucadair@orange.com] Sent: Wednesday, November 29, 2017 12:02 PM To: Konda, Tirumaleswar Reddy ; Jon Sha= llow ; dots@ietf.org Subject: RE: [Dots] signal-channel: Conflict detection and notification Hi Tiru, I agree with you that discarding all conflicting requests may not be helpfu= l in some cases. In the same way that someone can argue that selecting only= one request among conflicting ones may not be useful because the server pi= cked the wrong one. I do prefer to leave this to implementation/deployment as a policy to be su= pplied. That policy will instruct the dots server about the behavior to fol= low based one specific information that is available for a given deployment= : =B7 Pick one and deactivate all the others based on some criteria =B7 Activate all of them =B7 De-activate all of them Cheers, Med De : Dots [mailto:dots-bounces@ietf.org] De la part de Konda, Tirumaleswar = Reddy Envoy=E9 : mercredi 29 novembre 2017 06:39 =C0 : BOUCADAIR Mohamed IMT/OLN; Jon Shallow; dots@ietf.org Objet : Re: [Dots] signal-channel: Conflict detection and notification Hi Med, In a deployment scenario with a DDoS Detector (or a on premise DDoS mitigat= ion system) acting as DOTS clients and a web server with in-built DDoS dete= ction capability. The web server may not have as much visibility into the e= xtent of the DDoS attack as the DDoS Detector (or IDMS) and there will be c= onflicting mitigation requests from different DOTS clients, discarding all = the mitigation requests from different clients will make the mechanism not = useful. -Tiru From: mohamed.boucadair@orange.com [ma= ilto:mohamed.boucadair@orange.com] Sent: Tuesday, November 28, 2017 8:55 PM To: Konda, Tirumaleswar Reddy >; Jon Shallow >; dots@ietf.org Subject: RE: [Dots] signal-channel: Conflict detection and notification Tiru, Please see inline. Cheers, Med De : Dots [mailto:dots-bounces@ietf.org] De la part de Konda, Tirumaleswar = Reddy Envoy=E9 : mardi 28 novembre 2017 16:02 =C0 : Jon Shallow; BOUCADAIR Mohamed IMT/OLN; dots@ietf.org Objet : Re: [Dots] signal-channel: Conflict detection and notification Within a administrative domain, there won't be many different DOTS clients = raising conflicting mitigation requests for the same target, the conflict m= ay arise between a DDoS Detector (or a on premise DDoS mitigation system) a= cting as DOTS clients and a web server with in-built DDoS detection capabil= ity. [Med] I don't think that we can speculate about the nature of the conflicts= that may happen. Misconfigured and corrupted software instances may happen= . Under what conditions does the DOTS server return "DOTS Server has detected= conflicting mitigation requests from different DOTS clients. All conflict= ing mitigation requests are inactive." ? [Med] A dots server can be typically instructed by a policy to discard conf= licting requests. The rationale is that the provider thinks that the client= s are misconfigured and something is needed to be fixed before solicited th= e server. The signal-channel does not need to call for a favorite action wh= en conflicts; that is implementation- and deployment-specific. -Tiru From: Jon Shallow [mailto:supjps-ietf@jpshallow.com] Sent: Tuesday, November 28, 2017 7:45 PM To: mohamed.boucadair@orange.com; Kond= a, Tirumaleswar Reddy >; dots@ietf.org Subject: RE: [Dots] signal-channel: Conflict detection and notification Hi Med, In principal I accept the concept of your 7, 8 & 9 status which in effect a= re part of the mitigation state as in a state diagram. However, having iss= ued a "8" status, this then needs to transition to another state which refl= ects what is actually happening - e.g. "2". The actual state could immediately be sent following the reporting of "8" (= if Observe active), else it would need to wait until the next status GET. = It is possible that the "8" message gets lost, so relying on receiving the = "8" could be dangerous. With a "9" response what then is the DOTS client allowed to do? - A retry of the original mitigation request is likely to fail again - If all the DOTS clients back off, then there will be no mitigation - Should there be a random back-off time before retrying? What is critical is that DOTS servers in the same administrative domain attempting to honor conflicting requests may flap network route or DNS information, degrading the networks attempting to participate in attack response with the DOTS clients. Should not be allowed to happen. I also do not want to lose sight of The notification SHOULD indicate the nature and scope of the conflict, for example, the overlapping prefix range in a conflicting mitigation reque= st." This potentially can be conveyed in the 4.09 message, or could be a new mit= igation status parameter such as "additional-info" with an appropriate text= value. It could be that "status" stays with "1" through "6", and (possibl= y optional) "additional-status" has 0 | This DOTS client mitigation request is being honoured 1 | DOTS Server has detected conflicting mitigation requests from different= DOTS clients. This mitigation request is currently inactive until the con= flicts are resolved. Another mitigation request is active. 2 | DOTS Server has detected conflicting mitigation requests from different= DOTS clients. This mitigation request is currently active. 3 | DOTS Server has detected conflicting mitigation requests from different= DOTS clients. All conflicting mitigation requests are inactive. And "additional-info" reports on what the nature and scope of the conflict = is. Regards Jon From: Dots [mailto: dots-bounces@ietf.org] On= Behalf Of mohamed.boucadair@orange.com Sent: 28 November 2017 13:29 To: Jon Shallow; 'Konda, Tirumaleswar Reddy'; dots@ietf.org Subject: Re: [Dots] signal-channel: Conflict detection and notification Hi Jon, all, Thank you for sharing your thoughts on this. I tend to allow for both 4.09 code and new status values in the spec. I see that you proposed this new value: =3D=3D 7 | DOTS Server has detected conflicting mitigation requests from different= DOTS clients. This mitigation request is currently inactive until the con= flicts are resolved. Another mitigation request is active. =3D=3D Please note that a server may be instructed to adopt a more strict behavior= by deactivating all conflicting requests. Further, all DOTS clients which = issued conflicting requests should be notified, not only the one for which = a request is de-activated. As such, I'm afraid we will need more values, e.= g., =3D=3D 7 | DOTS Server has detected conflicting mitigation requests from different= DOTS clients. This mitigation request is currently inactive until the con= flicts are resolved. Another mitigation request is active. 8 | DOTS Server has detected conflicting mitigation requests from different= DOTS clients. This mitigation request is currently active. 9 | DOTS Server has detected conflicting mitigation requests from different= DOTS clients. All conflicting mitigation requests are inactive. =3D=3D For example: * If the server decides to activate only one request, then 7 will be sent t= o all clients for which the request is de-activated and 8 to the client for= which the request is maintained active. * If the server decides to deactivate all requests, then 9 will be sent to = all clients. Cheers, Med De : Jon Shallow [mailto:supjps-ietf@jpshallow.com] Envoy=E9 : mardi 28 novembre 2017 13:31 =C0 : 'Konda, Tirumaleswar Reddy'; BOUCADAIR Mohamed IMT/OLN; dots@ietf.org= Objet : RE: [Dots] signal-channel: Conflict detection and notification Hi Tiru, If Client-A has invoked a mitigation, then Client-B requests a conflicting = mitigation, if the DOTS server is only allowing the first mitigation reques= t to be the valid one, then the DOTS server could send back a 4.09 to Clien= t-B. However, if the DOTS server is allowed to choose the best mitigation reques= t, decides it is Client-B, there is no simple way of sending an unsolicited= 4.09 to client-A. Hence suggestion for an additional status message which= can be sent to Client-A stating that Client-A has been de-selected because= of a mitigation request conflict. It is also possible that a mitigation state is status 1 (parameter value - = Table 2)) and needs to transition to another state - at which point the con= flict is found - possibly by the DOTS mitigator - which then needs to be re= layed back through the DOTS server. Regards Jon From: Konda, Tirumaleswar Reddy [mailto: TirumaleswarReddy_Konda@mcafee.com= ] Sent: 28 November 2017 11:42 To: Jon Shallow; mohamed.boucadair@orange.com; dots@ietf.org Subject: RE: [Dots] signal-channel: Conflict detection and notification Hi Jon, What is the problem if the DOTS server returns 4.09 (conflict) error respon= se for the conflicting mitigation request from Client-A ? The above error code is already defined https://tools.ietf.org/html/rfc8132= . -Tiru From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Jon Shallow Sent: Tuesday, November 28, 2017 4:50 PM To: mohamed.boucadair@orange.com; dots= @ietf.org Subject: Re: [Dots] signal-channel: Conflict detection and notification Hi Med, See inline Regards Jon From: Dots [mailto: dots-bounces@ietf.org] On= Behalf Of ietf-supjps-mohamed.boucadair@orange.com Sent: 24 November 2017 14:03 To: dots@ietf.org Subject: [Dots] signal-channel: Conflict detection and notification Hi all, As discussed during the last IETF meeting, we are seeking for feedback from= the WG about how to address this requirement: =3D=3D=3D=3D=3D=3D=3D=3D=3D SIG-009 Conflict Detection and Notification: Multiple DOTS clients controlled by a single administrative entity may send conflicting mitigation requests for pools of protected resources as a result of misconfiguration, operator error, or compromised DOTS clients. DOTS servers in the same administrative domain attempting to honor conflicting requests may flap network route or DNS information, degrading the networks attempting to participate in attack response with the DOTS clients. DOTS servers in a single administrative domain SHALL detect such conflicting requests, and SHALL notify the DOTS clients in conflict. The notification SHOULD indicate the nature and scope of the conflict, for example, the overlapping prefix range in a conflicting mitigation request. =3D=3D=3D=3D=3D=3D=3D=3D For example, would it be OK if we leave implementation-specific the criteri= a upon which a dots server relies to consider two requests from two clients= as conflicting, but draft-ietf-dots-signal defines only the procedure to n= otify clients when a conflict is detected? Jon> I agree that how this is done is implementation specific. However the= re is a scenario where Client-A initiates a mitigation requests which is ac= ted upon, Client-B does a conflicting mitigation request but the DOTS Serve= r decides that Client-B is the "more" valid mitigation request and effectiv= ely de-activates Client-A's request. Table 2: draft-ietf-dots-signal-chann= el-09 therefore needs an additional status parameter to indicate to client-= A there is a conflict and hence Client-A is being stood down while another = client is controlling the mitigation. A suggestion would be 7 | DOTS Server has detected conflicting mitigation requests from different= DOTS clients. This mitigation request is currently inactive until the con= flicts are resolved. Another mitigation request is active. Jon> The DOTS client can then elect to leave in the mitigation request (and= even refresh the PUT to refresh the timeout) or delete it. Jon> I do not think it appropriate that an error message be sent back (e.g.= 4.xx) if the DOTS server immediately decides there is a conflicting reques= t and closes down the new PUT request unless we come up with a specific err= or code so the DOTS client can understand why the request is getting errore= d. Likewise, would it be OK if the document does not specify which of the conf= licting actions is to be discarded (old, new, all) by the server, but draft= -ietf-dots-signal defines how to inform clients about which action was enfo= rced by the server? Jon> Again, I think that this would be implementation specific. The sugges= ted Table 2: entry above would cover this as well. The DOTS client just ne= eds to know it has been de-selected / discarded - I don't think the DOTS cl= ient needs to know how / why the DOTS server chose that particular DOTS cli= ent. Cheers, Med --_000_DM5PR16MB1788206AD0A7E19CD9840622EA380DM5PR16MB1788namp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

The proposal works for me, is the plan to add 7, 8 and 9= status or add a new “additional-status” parameter ?=

 

-Tiru

 

From:<= /span> mohamed.boucadair@ora= nge.com [mailto:mohamed.boucadair@orange.com]
Sent: Wednesday, November 29, 2017 12:02 PM
To: Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@McAfee.com= >; Jon Shallow <supjps-ietf@jpshallow.com>; dots@ietf.org
Subject: RE: [Dots] signal-channel: Conflict detection and notificat= ion

 

Hi Tiru,

 

I agree with you that discarding all conflicti= ng requests may not be helpful in some cases. In the same way that someone = can argue that selecting only one request among conflicting ones may not be useful because the server picked the wrong one= .   

 

I do prefer to leave this to implementation/de= ployment as a policy to be supplied. That policy will instruct the dots ser= ver about the behavior to follow based one specific information that is available for a given deployment:  

=B7       Pick one and = deactivate all the others based on some criteria

=B7       Activate all = of them

=B7       De-activate a= ll of them

 

Cheers,

Med

 

De : Dots [mailto:dots-bounces@ietf.org] De la part de Konda, Tirumaleswar Reddy
Envoy=E9 : mercredi 29 novembre 2017 06:39
=C0 : BOUCADAIR Mohamed IMT/OLN; Jon Shallow; dots@ietf.org
Objet : Re: [Dots] signal-channel: Conflict detection and notif= ication

 

Hi Med,

&nbs= p;

In a depl= oyment scenario with a DDoS Detector (or a on premise DDoS mitigation syste= m) acting as DOTS clients and a web server with in-built DDoS detection cap= ability. The web server may not have as much visibility into the extent of the DDoS attack as the DDoS Detector= (or IDMS) and there will be conflicting mitigation requests from different= DOTS clients, discarding all the mitigation requests from different client= s will make the mechanism not useful.

&nbs= p;

-Tiru

&nbs= p;

From:<= /span> mohamed.boucadair@orange.co= m [mailto:mohamed.bouca= dair@orange.com]
Sent: Tuesday, November 28, 2017 8:55 PM
To: Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@McAfee.com>; Jon Shallow= <supjps-ietf@jpshallow.com= >; dots@ietf.org
Subject: RE: [Dots] signal-channel: Conflict detection and notificat= ion

 

Tiru,

 

Please see inline.

 

Cheers,

Med

 

De : Dots [mailto:dots-bounces@ietf.org] De la part de Konda, Tirumaleswar Reddy
Envoy=E9 : mardi 28 novembre 2017 16:02
=C0 : Jon Shallow; BOUCADAIR Mohamed IMT/OLN; dots@ietf.org
Objet : Re: [Dots] signal-channel: Conflict detection and notif= ication

 

Within a = administrative domain, there won’t be many different DOTS clients rai= sing conflicting mitigation requests for the same target, the conflict may = arise between a DDoS Detector (or a on premise DDoS mitigation system) acting as DOTS clients and a web server with in-bu= ilt DDoS detection capability. 

[Med] I don’t= think that we can speculate about the nature of the conflicts that may hap= pen. Misconfigured and corrupted software instances may happen.

&nbs= p;

Under wha= t conditions does the DOTS server return “DOTS Server has detected co= nflicting mitigation requests from different DOTS clients.  All confli= cting mitigation requests are inactive.” ?

[Med] A dots server= can be typically instructed by a policy to discard conflicting requests. T= he rationale is that the provider thinks that the clients are misconfigured and something is needed to be fixed before s= olicited the server. The signal-channel does not need to call for a favorit= e action when conflicts; that is implementation- and deployment-specific. &= nbsp;

&nbs= p;

-Tiru

&nbs= p;

From:<= /span> Jon Shallow [mailto:supjps-ietf@jpshallow.com]
Sent: Tuesday, November 28, 2017 7:45 PM
To: mohamed.boucadai= r@orange.com; Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@McAfee.com>; dots@ietf.org
Subject: RE: [Dots] signal-channel: Conflict detection and notificat= ion

 

Hi Med,=

&n= bsp;

In prin= cipal I accept the concept of your 7, 8 & 9 status which in effect are = part of the mitigation state as in a state diagram.  However, having i= ssued a “8” status, this then needs to transition to another state which reflects what is actually happening – e.g. &#= 8220;2”.

&n= bsp;

The act= ual state could immediately be sent following the reporting of “8R= 21; (if Observe active), else it would need to wait until the next status G= ET.  It is possible that the “8” message gets lost, so relying on receiving the “8” could be dangerous.=

&n= bsp;

With a = “9” response what then is the DOTS client allowed to do?

- A ret= ry of the original mitigation request is likely to fail again

- If al= l the DOTS clients back off, then there will be no mitigation

- Shoul= d there be a random back-off time before retrying?

&n= bsp;

What is= critical is that

      DOT= S servers in the same administrative domain attempting to honor<= /span>

      con= flicting requests may flap network route or DNS information,

      deg= rading the networks attempting to participate in attack

      res= ponse with the DOTS clients.

Should not b= e allowed to happen.

&n= bsp;

I also = do not want to lose sight of

The not= ification SHOULD indicate the nature and scope of the conflict,<= /span>

for exa= mple, the overlapping prefix range in a conflicting mitigation request.R= 21;

This po= tentially can be conveyed in the 4.09 message, or could be a new mitigation= status parameter such as "additional-info" with an appropriate t= ext value.  It could be that “status” stays with “1” through “6”, and (possibly optional) “ad= ditional-status” has

0 | Thi= s DOTS client mitigation request is being honoured

1 | DOTS Server has de= tected conflicting mitigation requests from different DOTS clients.  T= his mitigation request is currently inactive until the conflicts are resolv= ed. Another mitigation request is active.

2 | DOTS Server has de= tected conflicting mitigation requests from different DOTS clients.  T= his mitigation request is currently active.

3 | DOTS Server has de= tected conflicting mitigation requests from different DOTS clients.  A= ll conflicting mitigation requests are inactive.

And = 220;additional-info” reports on what the nature and scope of the conf= lict is.

&n= bsp;

Regards=

&n= bsp;

Jon

&n= bsp;

From: Dots [mailto: dots-bounces@ietf.org] On B= ehalf Of mohamed.boucadair@orang= e.com
Sent: 28 November 2017 13:29
To: Jon Shallow; 'Konda, Tirumaleswar Reddy'; dots@ietf.org
Subject: Re: [Dots] signal-channel: Conflict detection and notificat= ion

 

Hi Jon, all,

 

Thank you for sharing your thoughts on this.

 

I tend to allow for both 4.09 code and new sta= tus values in the spec.

 

I see that you proposed this new value:

=3D=3D

7 | DOTS Server has de= tected conflicting mitigation requests from different DOTS clients.  T= his mitigation request is currently inactive until the conflicts are resolv= ed. Another mitigation request is active.

=3D=3D

 

Please note that a server may be instructed to= adopt a more strict behavior by deactivating all conflicting requests. Fur= ther, all DOTS clients which issued conflicting requests should be notified, not only the one for which a request is de-ac= tivated. As such, I’m afraid we will need more values, e.g.,

 

=3D=3D

7 | DOTS Server has de= tected conflicting mitigation requests from different DOTS clients.  T= his mitigation request is currently inactive until the conflicts are resolv= ed. Another mitigation request is active.

8 | DOTS Server has de= tected conflicting mitigation requests from different DOTS clients.  T= his mitigation request is currently active.

9 | DOTS Server has de= tected conflicting mitigation requests from different DOTS clients.  A= ll conflicting mitigation requests are inactive.

=3D=3D

 

For example:

* If the server decides to activate only one r= equest, then 7 will be sent to all clients for which the request is de-acti= vated and 8 to the client for which the request is maintained active.

* If the server decides to deactivate all requ= ests, then 9 will be sent to all clients.  

 

Cheers,

Med

 

De : Jon Shallow [mailto:supjps-ietf@jpshallow.com]
Envoy=E9 : mardi 28 novembre 2017 13:31
=C0 : 'Konda, Tirumaleswar Reddy'; BOUCADAIR Mohamed IMT/OLN; dots@ietf.org
Objet : RE: [Dots] signal-channel: Conflict detection and notif= ication

 

Hi Tiru= ,

&n= bsp;

If Clie= nt-A has invoked a mitigation, then Client-B requests a conflicting mitigat= ion, if the DOTS server is only allowing the first mitigation request to be= the valid one, then the DOTS server could send back a 4.09 to Client-B.

&n= bsp;

However= , if the DOTS server is allowed to choose the best mitigation request, deci= des it is Client-B, there is no simple way of sending an unsolicited 4.09 t= o client-A.  Hence suggestion for an additional status message which can be sent to Client-A stating that Client-A has bee= n de-selected because of a mitigation request conflict.

&n= bsp;

It is a= lso possible that a mitigation state is status 1 (parameter value – T= able 2)) and needs to transition to another state – at which point th= e conflict is found - possibly by the DOTS mitigator - which then needs to be relayed back through the DOTS server.<= /span>

&n= bsp;

Regards=

&n= bsp;

Jon

&n= bsp;

From: Konda, Tirumaleswar Reddy [mailto: TirumaleswarReddy_Kon= da@mcafee.com]
Sent: 28 November 2017 11:42
To: Jon Shallow; moh= amed.boucadair@orange.com; dots@ietf.org
Subject: RE: [Dots] signal-channel: Conflict detection and notificat= ion

 

Hi Jon,

&nbs= p;

What is t= he problem if the DOTS server returns 4.09 (conflict) error response for th= e conflicting mitigation request from Client-A ?

The above= error code is already defined https://tools.ie= tf.org/html/rfc8132.

&nbs= p;

-Tiru

&nbs= p;

From:<= /span> Dots [mailto:dots-bounces@ietf.org] On Behalf Of Jon Shallow
Sent: Tuesday, November 28, 2017 4:50 PM
To: mohamed.boucadai= r@orange.com; dots@ietf.org
Subject: Re: [Dots] signal-channel: Conflict detection and notificat= ion

 

Hi Med,=

&n= bsp;

See inl= ine

&n= bsp;

Regards=

&n= bsp;

Jon

&n= bsp;

From: Dots [mailto: dots-bounces@ietf.org] On B= ehalf Of ietf-supjps= -mohamed.boucadair@orange.com
Sent: 24 November 2017 14:03
To: dots@ietf.org
Subject: [Dots] signal-channel: Conflict detection and notification<= o:p>

 

Hi all,

 

As discussed during the last IETF meeting, we are seeking = for feedback from the WG about how to address this requirement:<= /span>

 

=3D=3D=3D=3D=3D=3D=3D=3D=3D

   SIG-009  Conflic= t Detection and Notification: Multiple DOTS clients

      con= trolled by a single administrative entity may send conflicting

      mit= igation requests for pools of protected resources as a result

      of = misconfiguration, operator error, or compromised DOTS clients.

      DOT= S servers in the same administrative domain attempting to honor<= /span>

      con= flicting requests may flap network route or DNS information,

      deg= rading the networks attempting to participate in attack

      res= ponse with the DOTS clients.  DOTS servers in a single

      adm= inistrative domain SHALL detect such conflicting requests, and

      SHA= LL notify the DOTS clients in conflict.  The notification

      SHO= ULD indicate the nature and scope of the conflict, for example,<= /span>

      the= overlapping prefix range in a conflicting mitigation request.

=3D=3D=3D=3D=3D=3D=3D=3D

 

For example, would it be OK if we leave implementation-spe= cific the criteria upon which a dots server relies to consider two requests= from two clients as conflicting, but draft-ietf-dots-signal defines only the procedure to notify clients when a conflict is detected? =

Jon> I agree that h= ow this is done is implementation specific.  However there is a scenar= io where Client-A initiates a mitigation requests which is acted upon, Clie= nt-B does a conflicting mitigation request but the DOTS Server decides that Client-B is the “more” valid miti= gation request and effectively de-activates Client-A’s request. = Table 2: draft-ietf-dots-signal-channel-09 therefore needs an additional s= tatus parameter to indicate to client-A there is a conflict and hence Client-A is being stood down while another client is controlling= the mitigation.  A suggestion would be

 

7 | DOTS Server has de= tected conflicting mitigation requests from different DOTS clients.  T= his mitigation request is currently inactive until the conflicts are resolv= ed. Another mitigation request is active.

 

Jon> The DOTS clien= t can then elect to leave in the mitigation request (and even refresh the P= UT to refresh the timeout) or delete it.

Jon> I do not think= it appropriate that an error message be sent back (e.g. 4.xx) if the DOTS = server immediately decides there is a conflicting request and closes down t= he new PUT request unless we come up with a specific error code so the DOTS client can understand why the request is= getting errored.

 

 

Likewise, would it be OK if the document does not specify = which of the conflicting actions is to be discarded (old, new, all) by the = server, but draft-ietf-dots-signal defines how to inform clients about which action was enforced by the server?

 

Jon> Again, I think= that this would be implementation specific.  The suggested Table 2: e= ntry above would cover this as well.  The DOTS client just needs to kn= ow it has been de-selected / discarded – I don’t think the DOTS client needs to know how / why the DOTS server chose that p= articular DOTS client.

 

Cheers,

Med

--_000_DM5PR16MB1788206AD0A7E19CD9840622EA380DM5PR16MB1788namp_-- From nobody Thu Nov 30 02:26:29 2017 Return-Path: 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 AA62012940F for ; Thu, 30 Nov 2017 02:26:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.617 X-Spam-Level: X-Spam-Status: No, score=-2.617 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 Tvqmwfebr3ca for ; Thu, 30 Nov 2017 02:26:25 -0800 (PST) Received: from orange.com (mta134.mail.business.static.orange.com [80.12.70.34]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8CDA01293F2 for ; Thu, 30 Nov 2017 02:26:24 -0800 (PST) Received: from opfednr00.francetelecom.fr (unknown [xx.xx.xx.64]) by opfednr22.francetelecom.fr (ESMTP service) with ESMTP id E3E7D20B81; Thu, 30 Nov 2017 11:26:22 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.58]) by opfednr00.francetelecom.fr (ESMTP service) with ESMTP id BC3B91A026E; Thu, 30 Nov 2017 11:26:22 +0100 (CET) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM33.corporate.adroot.infra.ftgroup ([fe80::3881:fc15:b4b2:9017%19]) with mapi id 14.03.0361.001; Thu, 30 Nov 2017 11:26:22 +0100 From: To: "Konda, Tirumaleswar Reddy" , "Jon Shallow" , "dots@ietf.org" Thread-Topic: [Dots] signal-channel: Conflict detection and notification Thread-Index: AdNlLOxuTejE5Yr+TiWtd6n7pT4m0aJd55JwgAAKs5CAABDPgIAAEDEAgAAM/YCAAAnqQIAACYkAgADteRCAABAggIABvsNQolfHrJA= Date: Thu, 30 Nov 2017 10:26:21 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93300A084012@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <787AE7BB302AE849A7480A190F8B93300A07F4E4@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <009b01d3683a$c6158f90$5240aeb0$@jpshallow.com> <00e201d36844$b1b39ec0$151adc40$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93300A0819DB@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <011301d36853$48efb680$dacf2380$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93300A081B18@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93300A08307A@OPEXCLILMA3.corporate.adroot.infra.ftgroup> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.4] Content-Type: multipart/alternative; boundary="_000_787AE7BB302AE849A7480A190F8B93300A084012OPEXCLILMA3corp_" MIME-Version: 1.0 Archived-At: Subject: Re: [Dots] signal-channel: Conflict detection and notification 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Nov 2017 10:26:29 -0000 --_000_787AE7BB302AE849A7480A190F8B93300A084012OPEXCLILMA3corp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Tiru, With the "additional-status" parameter, and given the current values define= d in Table 2, I don't see which status code to return when "additional-stat= us" is set to "3 | DOTS Server has detected conflicting mitigation requests= from different DOTS clients. All conflicting mitigation requests are inac= tive". I'm afraid new status codes should be defined for this to work (e.g.= , "X: Attack mitigation is withdrawn", "Y: Attack mitigation is rejected"). Note that in both approaches, we will need to supply additional information= to characterize the conflict (conflict-information). This information shou= ld be returned to all clients. So, what about considering this direction? - Update the status table with these NEW codes: o 7: Attack mitigation is withdrawn o 8: Attack mitigation is rejected - Allow for including 'additional-status'. Define 'conflict-information'= under that parent; 'conflict-information' can include the following sub-pa= rameters: o conflict-status: three codes =A7 1 | DOTS Server has detected conflicting mitigation requests from diff= erent DOTS clients. This mitigation request is currently inactive until th= e conflicts are resolved. Another mitigation request is active. =A7 2 | DOTS Server has detected conflicting mitigation requests from diff= erent DOTS clients. This mitigation request is currently active. =A7 3 | DOTS Server has detected conflicting mitigation requests from diff= erent DOTS clients. All conflicting mitigation requests are inactive. o conflict-scope: same structure as "scope" Cheers, Med De : Konda, Tirumaleswar Reddy [mailto:TirumaleswarReddy_Konda@McAfee.com] Envoy=E9 : jeudi 30 novembre 2017 10:41 =C0 : BOUCADAIR Mohamed IMT/OLN; Jon Shallow; dots@ietf.org Objet : RE: [Dots] signal-channel: Conflict detection and notification The proposal works for me, is the plan to add 7, 8 and 9 status or add a ne= w "additional-status" parameter ? -Tiru From: mohamed.boucadair@orange.com [ma= ilto:mohamed.boucadair@orange.com] Sent: Wednesday, November 29, 2017 12:02 PM To: Konda, Tirumaleswar Reddy >; Jon Shallow >; dots@ietf.org Subject: RE: [Dots] signal-channel: Conflict detection and notification Hi Tiru, I agree with you that discarding all conflicting requests may not be helpfu= l in some cases. In the same way that someone can argue that selecting only= one request among conflicting ones may not be useful because the server pi= cked the wrong one. I do prefer to leave this to implementation/deployment as a policy to be su= pplied. That policy will instruct the dots server about the behavior to fol= low based one specific information that is available for a given deployment= : * Pick one and deactivate all the others based on some criteria * Activate all of them * De-activate all of them Cheers, Med De : Dots [mailto:dots-bounces@ietf.org] De la part de Konda, Tirumaleswar = Reddy Envoy=E9 : mercredi 29 novembre 2017 06:39 =C0 : BOUCADAIR Mohamed IMT/OLN; Jon Shallow; dots@ietf.org Objet : Re: [Dots] signal-channel: Conflict detection and notification Hi Med, In a deployment scenario with a DDoS Detector (or a on premise DDoS mitigat= ion system) acting as DOTS clients and a web server with in-built DDoS dete= ction capability. The web server may not have as much visibility into the e= xtent of the DDoS attack as the DDoS Detector (or IDMS) and there will be c= onflicting mitigation requests from different DOTS clients, discarding all = the mitigation requests from different clients will make the mechanism not = useful. -Tiru From: mohamed.boucadair@orange.com [ma= ilto:mohamed.boucadair@orange.com] Sent: Tuesday, November 28, 2017 8:55 PM To: Konda, Tirumaleswar Reddy >; Jon Shallow >; dots@ietf.org Subject: RE: [Dots] signal-channel: Conflict detection and notification Tiru, Please see inline. Cheers, Med De : Dots [mailto:dots-bounces@ietf.org] De la part de Konda, Tirumaleswar = Reddy Envoy=E9 : mardi 28 novembre 2017 16:02 =C0 : Jon Shallow; BOUCADAIR Mohamed IMT/OLN; dots@ietf.org Objet : Re: [Dots] signal-channel: Conflict detection and notification Within a administrative domain, there won't be many different DOTS clients = raising conflicting mitigation requests for the same target, the conflict m= ay arise between a DDoS Detector (or a on premise DDoS mitigation system) a= cting as DOTS clients and a web server with in-built DDoS detection capabil= ity. [Med] I don't think that we can speculate about the nature of the conflicts= that may happen. Misconfigured and corrupted software instances may happen= . Under what conditions does the DOTS server return "DOTS Server has detected= conflicting mitigation requests from different DOTS clients. All conflict= ing mitigation requests are inactive." ? [Med] A dots server can be typically instructed by a policy to discard conf= licting requests. The rationale is that the provider thinks that the client= s are misconfigured and something is needed to be fixed before solicited th= e server. The signal-channel does not need to call for a favorite action wh= en conflicts; that is implementation- and deployment-specific. -Tiru From: Jon Shallow [mailto:supjps-ietf@jpshallow.com] Sent: Tuesday, November 28, 2017 7:45 PM To: mohamed.boucadair@orange.com; Kond= a, Tirumaleswar Reddy >; dots@ietf.org Subject: RE: [Dots] signal-channel: Conflict detection and notification Hi Med, In principal I accept the concept of your 7, 8 & 9 status which in effect a= re part of the mitigation state as in a state diagram. However, having iss= ued a "8" status, this then needs to transition to another state which refl= ects what is actually happening - e.g. "2". The actual state could immediately be sent following the reporting of "8" (= if Observe active), else it would need to wait until the next status GET. = It is possible that the "8" message gets lost, so relying on receiving the = "8" could be dangerous. With a "9" response what then is the DOTS client allowed to do? - A retry of the original mitigation request is likely to fail again - If all the DOTS clients back off, then there will be no mitigation - Should there be a random back-off time before retrying? What is critical is that DOTS servers in the same administrative domain attempting to honor conflicting requests may flap network route or DNS information, degrading the networks attempting to participate in attack response with the DOTS clients. Should not be allowed to happen. I also do not want to lose sight of The notification SHOULD indicate the nature and scope of the conflict, for example, the overlapping prefix range in a conflicting mitigation reque= st." This potentially can be conveyed in the 4.09 message, or could be a new mit= igation status parameter such as "additional-info" with an appropriate text= value. It could be that "status" stays with "1" through "6", and (possibl= y optional) "additional-status" has 0 | This DOTS client mitigation request is being honoured 1 | DOTS Server has detected conflicting mitigation requests from different= DOTS clients. This mitigation request is currently inactive until the con= flicts are resolved. Another mitigation request is active. 2 | DOTS Server has detected conflicting mitigation requests from different= DOTS clients. This mitigation request is currently active. 3 | DOTS Server has detected conflicting mitigation requests from different= DOTS clients. All conflicting mitigation requests are inactive. And "additional-info" reports on what the nature and scope of the conflict = is. Regards Jon From: Dots [mailto: dots-bounces@ietf.org] On= Behalf Of mohamed.boucadair@orange.com Sent: 28 November 2017 13:29 To: Jon Shallow; 'Konda, Tirumaleswar Reddy'; dots@ietf.org Subject: Re: [Dots] signal-channel: Conflict detection and notification Hi Jon, all, Thank you for sharing your thoughts on this. I tend to allow for both 4.09 code and new status values in the spec. I see that you proposed this new value: =3D=3D 7 | DOTS Server has detected conflicting mitigation requests from different= DOTS clients. This mitigation request is currently inactive until the con= flicts are resolved. Another mitigation request is active. =3D=3D Please note that a server may be instructed to adopt a more strict behavior= by deactivating all conflicting requests. Further, all DOTS clients which = issued conflicting requests should be notified, not only the one for which = a request is de-activated. As such, I'm afraid we will need more values, e.= g., =3D=3D 7 | DOTS Server has detected conflicting mitigation requests from different= DOTS clients. This mitigation request is currently inactive until the con= flicts are resolved. Another mitigation request is active. 8 | DOTS Server has detected conflicting mitigation requests from different= DOTS clients. This mitigation request is currently active. 9 | DOTS Server has detected conflicting mitigation requests from different= DOTS clients. All conflicting mitigation requests are inactive. =3D=3D For example: * If the server decides to activate only one request, then 7 will be sent t= o all clients for which the request is de-activated and 8 to the client for= which the request is maintained active. * If the server decides to deactivate all requests, then 9 will be sent to = all clients. Cheers, Med De : Jon Shallow [mailto:supjps-ietf@jpshallow.com] Envoy=E9 : mardi 28 novembre 2017 13:31 =C0 : 'Konda, Tirumaleswar Reddy'; BOUCADAIR Mohamed IMT/OLN; dots@ietf.org= Objet : RE: [Dots] signal-channel: Conflict detection and notification Hi Tiru, If Client-A has invoked a mitigation, then Client-B requests a conflicting = mitigation, if the DOTS server is only allowing the first mitigation reques= t to be the valid one, then the DOTS server could send back a 4.09 to Clien= t-B. However, if the DOTS server is allowed to choose the best mitigation reques= t, decides it is Client-B, there is no simple way of sending an unsolicited= 4.09 to client-A. Hence suggestion for an additional status message which= can be sent to Client-A stating that Client-A has been de-selected because= of a mitigation request conflict. It is also possible that a mitigation state is status 1 (parameter value - = Table 2)) and needs to transition to another state - at which point the con= flict is found - possibly by the DOTS mitigator - which then needs to be re= layed back through the DOTS server. Regards Jon From: Konda, Tirumaleswar Reddy [mailto: TirumaleswarReddy_Konda@mcafee.com= ] Sent: 28 November 2017 11:42 To: Jon Shallow; mohamed.boucadair@orange.com; dots@ietf.org Subject: RE: [Dots] signal-channel: Conflict detection and notification Hi Jon, What is the problem if the DOTS server returns 4.09 (conflict) error respon= se for the conflicting mitigation request from Client-A ? The above error code is already defined https://tools.ietf.org/html/rfc8132= . -Tiru From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Jon Shallow Sent: Tuesday, November 28, 2017 4:50 PM To: mohamed.boucadair@orange.com; dots= @ietf.org Subject: Re: [Dots] signal-channel: Conflict detection and notification Hi Med, See inline Regards Jon From: Dots [mailto: dots-bounces@ietf.org] On= Behalf Of ietf-supjps-mohamed.boucadair@orange.com Sent: 24 November 2017 14:03 To: dots@ietf.org Subject: [Dots] signal-channel: Conflict detection and notification Hi all, As discussed during the last IETF meeting, we are seeking for feedback from= the WG about how to address this requirement: =3D=3D=3D=3D=3D=3D=3D=3D=3D SIG-009 Conflict Detection and Notification: Multiple DOTS clients controlled by a single administrative entity may send conflicting mitigation requests for pools of protected resources as a result of misconfiguration, operator error, or compromised DOTS clients. DOTS servers in the same administrative domain attempting to honor conflicting requests may flap network route or DNS information, degrading the networks attempting to participate in attack response with the DOTS clients. DOTS servers in a single administrative domain SHALL detect such conflicting requests, and SHALL notify the DOTS clients in conflict. The notification SHOULD indicate the nature and scope of the conflict, for example, the overlapping prefix range in a conflicting mitigation request. =3D=3D=3D=3D=3D=3D=3D=3D For example, would it be OK if we leave implementation-specific the criteri= a upon which a dots server relies to consider two requests from two clients= as conflicting, but draft-ietf-dots-signal defines only the procedure to n= otify clients when a conflict is detected? Jon> I agree that how this is done is implementation specific. However the= re is a scenario where Client-A initiates a mitigation requests which is ac= ted upon, Client-B does a conflicting mitigation request but the DOTS Serve= r decides that Client-B is the "more" valid mitigation request and effectiv= ely de-activates Client-A's request. Table 2: draft-ietf-dots-signal-chann= el-09 therefore needs an additional status parameter to indicate to client-= A there is a conflict and hence Client-A is being stood down while another = client is controlling the mitigation. A suggestion would be 7 | DOTS Server has detected conflicting mitigation requests from different= DOTS clients. This mitigation request is currently inactive until the con= flicts are resolved. Another mitigation request is active. Jon> The DOTS client can then elect to leave in the mitigation request (and= even refresh the PUT to refresh the timeout) or delete it. Jon> I do not think it appropriate that an error message be sent back (e.g.= 4.xx) if the DOTS server immediately decides there is a conflicting reques= t and closes down the new PUT request unless we come up with a specific err= or code so the DOTS client can understand why the request is getting errore= d. Likewise, would it be OK if the document does not specify which of the conf= licting actions is to be discarded (old, new, all) by the server, but draft= -ietf-dots-signal defines how to inform clients about which action was enfo= rced by the server? Jon> Again, I think that this would be implementation specific. The sugges= ted Table 2: entry above would cover this as well. The DOTS client just ne= eds to know it has been de-selected / discarded - I don't think the DOTS cl= ient needs to know how / why the DOTS server chose that particular DOTS cli= ent. Cheers, Med --_000_787AE7BB302AE849A7480A190F8B93300A084012OPEXCLILMA3corp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Tiru,

 

With the “additional-stat= us” parameter, and given the current values defined in Table 2, I don= ’t see which status code to return when “additional-status̶= 1; is set to “3 | DOTS Server has detected conflicting mitigation reque= sts from different DOTS clients.  All conflicting mitigation requests = are inactive”. I’m afraid new status codes should be defined fo= r this to work (e.g., “X: Attack mitigation is withdrawn”, “Y: Attack mitigation is rejected”).

 

Note that in both approaches, w= e will need to supply additional information to characterize the conflict (= conflict-information). This information should be returned to all clients.

 

So, what about considering this= direction?

-  = ;  Update the status table= with these NEW codes:

o=     7: Attack mitigation is= withdrawn

o=     8: Attack mitigation is= rejected

-  = ;  Allow for including = 216;additional-status’. Define ‘conflict-information’ und= er that parent; ‘conflict-information’ can include the followin= g sub-parameters:

o=     conflict-status: three = codes

=A7  1 | DOTS Server has det= ected conflicting mitigation requests from different DOTS clients.  Th= is mitigation request is currently inactive until the conflicts are resolved. Another mitigation request is active.

=A7  2 | DOTS Server has det= ected conflicting mitigation requests from different DOTS clients.  Th= is mitigation request is currently active.

=A7  3 | DOTS Server has det= ected conflicting mitigation requests from different DOTS clients.  Al= l conflicting mitigation requests are inactive.

o=     conflict-scope: same st= ructure as “scope”

Cheers,

Med

 

K= onda, Tirumaleswar Reddy [mailto:TirumaleswarReddy_Konda@McAfee.com]
Envoy=E9 : jeudi 30 novembre 2017 10:41
=C0 : BOUCADAIR Mohamed IMT/OLN; Jon Shallow; dots@ietf.org
Objet : RE: [Dots] signal-channel: Conflict detection and notif= ication

 

The proposal works for me, is the plan to= add 7, 8 and 9 status or add a new “additional-status” paramet= er ?

 

-Tiru

 

From: mohamed.boucadair@orange.co= m [mailto:mohamed.bouca= dair@orange.com]
Sent: Wednesday, November 29, 2017 12:02 PM
To: Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@McAfee.com>; Jon Shallow= <supjps-ietf@jpshallow.com= >; dots@ietf.org
Subject: RE: [Dots] signal-channel: Conflict detection and notificat= ion

 

Hi Tiru,

 

I agree with you that discardin= g all conflicting requests may not be helpful in some cases. In the same wa= y that someone can argue that selecting only one request among conflicting ones may not be useful because the server picked= the wrong one.   

 

I do prefer to leave this to im= plementation/deployment as a policy to be supplied. That policy will instru= ct the dots server about the behavior to follow based one specific information that is available for a given deployment: &= nbsp;

=B7<= span lang=3D"EN-US" style=3D"font-size:7.0pt;font-family:"Times New Ro= man","serif";color:black">     &nbs= p; Pick one and deactivate all the others based on= some criteria

=B7<= span lang=3D"EN-US" style=3D"font-size:7.0pt;font-family:"Times New Ro= man","serif";color:black">     &nbs= p; Activate all of them

=B7<= span lang=3D"EN-US" style=3D"font-size:7.0pt;font-family:"Times New Ro= man","serif";color:black">     &nbs= p; De-activate all of them

 

Cheers,

Med

 

De : Dots [mailto:dots-bounces@ietf.org] De la part de Konda, Tirumaleswar Reddy
Envoy=E9 : mercredi 29 novembre 2017 06:39
=C0 : BOUCADAIR Mohamed IMT/OLN; Jon Shallow; dots@ietf.org
Objet : Re: [Dots] signal-channel: Conflict detection and notif= ication

 

Hi Med,

 

In a deployment scenario with a DDoS Detector (or a on premise DDoS m= itigation system) acting as DOTS clients and a web server with in-built DDo= S detection capability. The web server may not have as much visibility into the extent of the DDoS attack as the = DDoS Detector (or IDMS) and there will be conflicting mitigation requests f= rom different DOTS clients, discarding all the mitigation requests from dif= ferent clients will make the mechanism not useful.

 

-Tiru

 

From: mohamed.boucadair@orange.co= m [mailto:mohamed.bouca= dair@orange.com]
Sent: Tuesday, November 28, 2017 8:55 PM
To: Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@McAfee.com>; Jon Shallow= <supjps-ietf@jpshallow.com= >; dots@ietf.org
Subject: RE: [Dots] signal-channel: Conflict detection and notificat= ion

 

Tiru,

 

Please see inline.

 

Cheers,

Med

 

De : Dots [mailto:dots-bounces@ietf.org] De la part de Konda, Tirumaleswar Reddy
Envoy=E9 : mardi 28 novembre 2017 16:02
=C0 : Jon Shallow; BOUCADAIR Mohamed IMT/OLN; dots@ietf.org
Objet : Re: [Dots] signal-channel: Conflict detection and notif= ication

 

Within a administrative domain, there won’t be many different D= OTS clients raising conflicting mitigation requests for the same target, th= e conflict may arise between a DDoS Detector (or a on premise DDoS mitigation system) acting as DOTS clients and a web = server with in-built DDoS detection capability. 

[Med= ] I don’t think that we can speculate about the nature of the conflic= ts that may happen. Misconfigured and corrupted software instances may happen.

 

Under what conditions does the DOTS server return “DOTS Server = has detected conflicting mitigation requests from different DOTS clients.&n= bsp; All conflicting mitigation requests are inactive.” ?

[Med= ] A dots server can be typically instructed by a policy to discard conflict= ing requests. The rationale is that the provider thinks that the clients are misconfigured and something is needed to be fi= xed before solicited the server. The signal-channel does not need to call f= or a favorite action when conflicts; that is implementation- and deployment= -specific.  

 

-Tiru

 

From: Jon Shallow [mailto:s= upjps-ietf@jpshallow.com]
Sent: Tuesday, November 28, 2017 7:45 PM
To: mohamed.boucadai= r@orange.com; Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@McAfee.com>; dots@ietf.org
Subject: RE: [Dots] signal-channel: Conflict detection and notificat= ion

 

Hi Med,=

&n= bsp;

In prin= cipal I accept the concept of your 7, 8 & 9 status which in effect are = part of the mitigation state as in a state diagram.  However, having i= ssued a “8” status, this then needs to transition to another state which reflects what is actually happening – e.g. &#= 8220;2”.

&n= bsp;

The act= ual state could immediately be sent following the reporting of “8R= 21; (if Observe active), else it would need to wait until the next status G= ET.  It is possible that the “8” message gets lost, so relying on receiving the “8” could be dangerous.=

&n= bsp;

With a = “9” response what then is the DOTS client allowed to do?

- A ret= ry of the original mitigation request is likely to fail again

- If al= l the DOTS clients back off, then there will be no mitigation

- Shoul= d there be a random back-off time before retrying?

&n= bsp;

What is= critical is that

   &= nbsp;  DOTS servers in the same administrative domain attempting to ho= nor

   &= nbsp;  conflicting requests may flap network route or DNS information,=

   &= nbsp;  degrading the networks attempting to participate in attack=

   &= nbsp;  response with the DOTS clients.

Should not be allowed to happen.

&n= bsp;

I also = do not want to lose sight of

The notification SHOULD indicate the nature and scope of the conf= lict,

for example, the overlapping prefix range in a conflicting mitiga= tion request.”

This po= tentially can be conveyed in the 4.09 message, or could be a new mitigation= status parameter such as "additional-info" with an appropriate t= ext value.  It could be that “status” stays with “1” through “6”, and (possibly optional) “ad= ditional-status” has

0 | Thi= s DOTS client mitigation request is being honoured

1 | DOT= S Server has detected conflicting mitigation requests from different DOTS c= lients.  This mitigation request is currently inactive until the confl= icts are resolved. Another mitigation request is active.

2 | DOT= S Server has detected conflicting mitigation requests from different DOTS c= lients.  This mitigation request is currently active.

3 | DOT= S Server has detected conflicting mitigation requests from different DOTS c= lients.  All conflicting mitigation requests are inactive.<= /span>

And = 220;additional-info” reports on what the nature and scope of the conf= lict is.

&n= bsp;

Regards=

&n= bsp;

Jon

&n= bsp;

From:= Dots [mailto: dots-bounces@ietf.org] On B= ehalf Of mohamed.boucadair@orang= e.com
Sent: 28 November 2017 13:29
To: Jon Shallow; 'Konda, Tirumaleswar Reddy'; dots@ietf.org
Subject: Re: [Dots] signal-channel: Conflict detection and notificat= ion

 

Hi Jon, all,

 

Thank you for sharing your thou= ghts on this.

 

I tend to allow for both 4.09 c= ode and new status values in the spec.

 

I see that you proposed this ne= w value:

=3D=3D

7 | DOT= S Server has detected conflicting mitigation requests from different DOTS c= lients.  This mitigation request is currently inactive until the confl= icts are resolved. Another mitigation request is active.

=3D=3D

 

Please note that a server may b= e instructed to adopt a more strict behavior by deactivating all conflictin= g requests. Further, all DOTS clients which issued conflicting requests should be notified, not only the one for which a requ= est is de-activated. As such, I’m afraid we will need more values, e.= g.,

 

=3D=3D

7 | DOT= S Server has detected conflicting mitigation requests from different DOTS c= lients.  This mitigation request is currently inactive until the confl= icts are resolved. Another mitigation request is active.

8 | DOT= S Server has detected conflicting mitigation requests from different DOTS c= lients.  This mitigation request is currently active.

9 | DOT= S Server has detected conflicting mitigation requests from different DOTS c= lients.  All conflicting mitigation requests are inactive.<= /span>

=3D=3D

 

For example:<= /p>

* If the server decides to acti= vate only one request, then 7 will be sent to all clients for which the req= uest is de-activated and 8 to the client for which the request is maintained active.

* If the server decides to deac= tivate all requests, then 9 will be sent to all clients.  <= /span>

 

Cheers,

Med

 

J= on Shallow [mailto:supjps-ietf= @jpshallow.com]
Envoy=E9 : mardi 28 novembre 2017 13:31
=C0 : 'Konda, Tirumaleswar Reddy'; BOUCADAIR Mohamed IMT/OLN; dots@ietf.org
Objet : RE: [Dots] signal-channel: Conflict detection and notif= ication

 

Hi Tiru= ,

&n= bsp;

If Clie= nt-A has invoked a mitigation, then Client-B requests a conflicting mitigat= ion, if the DOTS server is only allowing the first mitigation request to be= the valid one, then the DOTS server could send back a 4.09 to Client-B.

&n= bsp;

However= , if the DOTS server is allowed to choose the best mitigation request, deci= des it is Client-B, there is no simple way of sending an unsolicited 4.09 t= o client-A.  Hence suggestion for an additional status message which can be sent to Client-A stating that Client-A has bee= n de-selected because of a mitigation request conflict.

&n= bsp;

It is a= lso possible that a mitigation state is status 1 (parameter value – T= able 2)) and needs to transition to another state – at which point th= e conflict is found - possibly by the DOTS mitigator - which then needs to be relayed back through the DOTS server.<= /span>

&n= bsp;

Regards=

&n= bsp;

Jon

&n= bsp;

From:= Konda, Tirumaleswar Reddy [mailto: TirumaleswarReddy_Konda@mcafee.com]
Sent: 28 November 2017 11:42
To: Jon Shallow; moh= amed.boucadair@orange.com; dots@ietf.org
Subject: RE: [Dots] signal-channel: Conflict detection and notificat= ion

 

Hi Jon,

 

What is the problem if the DOTS server returns 4.09 (conflict) error = response for the conflicting mitigation request from Client-A ?<= /span>

The above error code is already defined https://tools.ie= tf.org/html/rfc8132.

 

-Tiru

 

From: Dots [mailto:dots-bounces= @ietf.org] On Behalf Of Jon Shallow
Sent: Tuesday, November 28, 2017 4:50 PM
To: mohamed.boucadai= r@orange.com; dots@ietf.org
Subject: Re: [Dots] signal-channel: Conflict detection and notificat= ion

 

Hi Med,=

&n= bsp;

See inl= ine

&n= bsp;

Regards=

&n= bsp;

Jon

&n= bsp;

From:= Dots [mailto: dots-bounces@ietf.org] On B= ehalf Of ietf-supjps= -mohamed.boucadair@orange.com
Sent: 24 November 2017 14:03
To: dots@ietf.org
Subject: [Dots] signal-channel: Conflict detection and notification<= o:p>

 

Hi all,

 

As discussed during the last IETF meeting, = we are seeking for feedback from the WG about how to address this requireme= nt:

 

=3D=3D=3D=3D=3D=3D=3D=3D=3D

   SIG-00= 9  Conflict Detection and Notification: Multiple DOTS clients

   &= nbsp;  controlled by a single administrative entity may send conflicti= ng

   &= nbsp;  mitigation requests for pools of protected resources as a resul= t

   &= nbsp;  of misconfiguration, operator error, or compromised DOTS client= s.

   &= nbsp;  DOTS servers in the same administrative domain attempting to ho= nor

   &= nbsp;  conflicting requests may flap network route or DNS information,=

   &= nbsp;  degrading the networks attempting to participate in attack=

   &= nbsp;  response with the DOTS clients.  DOTS servers in a single<= o:p>

   &= nbsp;  administrative domain SHALL detect such conflicting requests, a= nd

   &= nbsp;  SHALL notify the DOTS clients in conflict.  The notificati= on

   &= nbsp;  SHOULD indicate the nature and scope of the conflict, for examp= le,

   &= nbsp;  the overlapping prefix range in a conflicting mitigation reques= t.

=3D=3D=3D=3D=3D=3D=3D=3D<= /p>

 

For example, would it be OK if we leave imp= lementation-specific the criteria upon which a dots server relies to consid= er two requests from two clients as conflicting, but draft-ietf-dots-signal defines only the procedure to notify clients wh= en a conflict is detected?

Jon>= I agree that how this is done is implementation specific.  However th= ere is a scenario where Client-A initiates a mitigation requests which is a= cted upon, Client-B does a conflicting mitigation request but the DOTS Server decides that Client-B is the “more”= ; valid mitigation request and effectively de-activates Client-A’s re= quest.  Table 2: draft-ietf-dots-signal-channel-09 therefore needs an = additional status parameter to indicate to client-A there is a conflict and hence Client-A is being stood down while another client = is controlling the mitigation.  A suggestion would be

&n= bsp;

7 | DOT= S Server has detected conflicting mitigation requests from different DOTS c= lients.  This mitigation request is currently inactive until the confl= icts are resolved. Another mitigation request is active.

&n= bsp;

Jon>= The DOTS client can then elect to leave in the mitigation request (and eve= n refresh the PUT to refresh the timeout) or delete it.

Jon>= I do not think it appropriate that an error message be sent back (e.g. 4.x= x) if the DOTS server immediately decides there is a conflicting request an= d closes down the new PUT request unless we come up with a specific error code so the DOTS client can understand wh= y the request is getting errored.

&n= bsp;

 

Likewise, would it be OK if the document do= es not specify which of the conflicting actions is to be discarded (old, ne= w, all) by the server, but draft-ietf-dots-signal defines how to inform clients about which action was enforced by the serve= r?

&n= bsp;

Jon>= Again, I think that this would be implementation specific.  The sugge= sted Table 2: entry above would cover this as well.  The DOTS client j= ust needs to know it has been de-selected / discarded – I don’t think the DOTS client needs to know how / why the DO= TS server chose that particular DOTS client.

 

Cheers,

Med

--_000_787AE7BB302AE849A7480A190F8B93300A084012OPEXCLILMA3corp_-- From nobody Thu Nov 30 02:33:51 2017 Return-Path: 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 A9C27129407 for ; Thu, 30 Nov 2017 02:33:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 AorC6aBSsfBF for ; Thu, 30 Nov 2017 02:33:46 -0800 (PST) Received: from mail.jpshallow.com (mail.jpshallow.com [217.40.240.153]) (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 60C7F129329 for ; Thu, 30 Nov 2017 02:33:45 -0800 (PST) Received: from [127.0.0.1] (helo=N01332) by mail.jpshallow.com with smtps (TLSv1:ECDHE-RSA-AES256-SHA:256) (Exim 4.89) (envelope-from ) id 1eKMA2-0007dm-AE; Thu, 30 Nov 2017 10:33:42 +0000 From: "Jon Shallow" To: "'Konda, Tirumaleswar Reddy'" , , References: <787AE7BB302AE849A7480A190F8B93300A07F4E4@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <009b01d3683a$c6158f90$5240aeb0$@jpshallow.com> <00e201d36844$b1b39ec0$151adc40$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93300A0819DB@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <011301d36853$48efb680$dacf2380$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93300A081B18@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93300A08307A@OPEXCLILMA3.corporate.adroot.infra.ftgroup> In-Reply-To: Date: Thu, 30 Nov 2017 10:33:42 -0000 Message-ID: <004101d369c6$b177dce0$146796a0$@jpshallow.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0042_01D369C6.B17A4DE0" X-Mailer: Microsoft Outlook 14.0 Content-Language: en-gb Thread-Index: AQI5QycoOO+6Sl3hDoQKXRH887G99QHmvtxLArQ3BpMBrkCf6AG8EcvIAftFitMBk8OATQDr9ZOXAY4zRQIBQLfdVgD+ExMRod6TpNA= Archived-At: Subject: Re: [Dots] signal-channel: Conflict detection and notification 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Nov 2017 10:33:49 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0042_01D369C6.B17A4DE0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Tiru et al, =20 I have been having a think about this one, and do not know (from a DOTS client coding perspective) what to do if using 7, 8 and 9 method =96 in particular 8 (DOTS Server has detected conflicting mitigation requests = from different DOTS clients. This mitigation request is currently active.). =93currently active=94 could be one of status 1 through 5. =20 =20 An answer could be to have 7, 8 becomes 8-12 (to mirror the 1-5 status) = and 9 becomes 13 as an alternative to =93additional-status=94. I am = agnostic here as to which way, but do need to know the fact that the original 8 has a status subtype of 1-5, or that 1-5 have a conflict status sub-type. =20 The use of 4.09 as an immediate response to a mitigation request should = be documented as a valid response (as only few people are SME on all the = other RFCs!). 7, 8 & 9 (or the alternatives) are for after the mitigation = request has been accepted. =20 At any point the DOTS server can elect to change the status on detection = of a conflict (which could be after a DOTS mitigator detects a conflict =96 possibly from 2 different DOTS servers and reports it back to DOTS = server (how =96 out of scope)). The mitigation request will, from the DOTS = client perspective, remain in that conflict state (status) until either the conflict is resolved (e.g. another DOTS client backs off), or the DOTS client issues a DELETE. =20 The DOTS client can monitor the status using Observe. =20 If the DOTS client is intelligent enough (assume in the general case unlikely), there is nothing stopping it DELETE current mitigation = request and issue a new one with the conflict potentially resolved. =20 For reporting the conflict as per =20 The notification SHOULD indicate the nature and scope of the conflict, for example, the overlapping prefix range in a conflicting mitigation request.=94 =20 I would suggest an additional (optional) =93additional-info=94 reports = on what the nature and scope of the conflict is. This conflict report cannot be = too wordy due to packet MTU limitations. It may be that we define different conflict codes, in which case =93additional-info=94 could be = =93conflict-code=94. =20 Regards =20 Jon =20 From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of Konda, = Tirumaleswar Reddy Sent: 30 November 2017 09:41 To: mohamed.boucadair@orange.com; Jon Shallow; dots@ietf.org Subject: Re: [Dots] signal-channel: Conflict detection and notification =20 The proposal works for me, is the plan to add 7, 8 and 9 status or add a = new =93additional-status=94 parameter ? =20 -Tiru =20 From: mohamed.boucadair@orange.com [mailto:mohamed.boucadair@orange.com] = Sent: Wednesday, November 29, 2017 12:02 PM To: Konda, Tirumaleswar Reddy ; Jon Shallow ; dots@ietf.org Subject: RE: [Dots] signal-channel: Conflict detection and notification =20 Hi Tiru,=20 =20 I agree with you that discarding all conflicting requests may not be = helpful in some cases. In the same way that someone can argue that selecting = only one request among conflicting ones may not be useful because the server picked the wrong one. =20 =20 I do prefer to leave this to implementation/deployment as a policy to be supplied. That policy will instruct the dots server about the behavior = to follow based one specific information that is available for a given deployment: =20 =B7 Pick one and deactivate all the others based on some criteria =B7 Activate all of them =B7 De-activate all of them=20 =20 Cheers, Med=20 =20 De : Dots [mailto:dots-bounces@ietf.org] De la part de Konda, = Tirumaleswar Reddy Envoy=E9 : mercredi 29 novembre 2017 06:39 =C0 : BOUCADAIR Mohamed IMT/OLN; Jon Shallow; dots@ietf.org Objet : Re: [Dots] signal-channel: Conflict detection and notification =20 Hi Med, =20 In a deployment scenario with a DDoS Detector (or a on premise DDoS mitigation system) acting as DOTS clients and a web server with in-built DDoS detection capability. The web server may not have as much = visibility into the extent of the DDoS attack as the DDoS Detector (or IDMS) and = there will be conflicting mitigation requests from different DOTS clients, discarding all the mitigation requests from different clients will make = the mechanism not useful. =20 -Tiru =20 From: mohamed.boucadair@orange.com [mailto:mohamed.boucadair@orange.com] = Sent: Tuesday, November 28, 2017 8:55 PM To: Konda, Tirumaleswar Reddy ; Jon Shallow ; dots@ietf.org Subject: RE: [Dots] signal-channel: Conflict detection and notification =20 Tiru,=20 =20 Please see inline.=20 =20 Cheers, Med =20 De : Dots [mailto:dots-bounces@ietf.org] De la part de Konda, = Tirumaleswar Reddy Envoy=E9 : mardi 28 novembre 2017 16:02 =C0 : Jon Shallow; BOUCADAIR Mohamed IMT/OLN; dots@ietf.org Objet : Re: [Dots] signal-channel: Conflict detection and notification =20 Within a administrative domain, there won=92t be many different DOTS = clients raising conflicting mitigation requests for the same target, the = conflict may arise between a DDoS Detector (or a on premise DDoS mitigation = system) acting as DOTS clients and a web server with in-built DDoS detection capability. =20 [Med] I don=92t think that we can speculate about the nature of the = conflicts that may happen. Misconfigured and corrupted software instances may = happen.=20 =20 Under what conditions does the DOTS server return =93DOTS Server has = detected conflicting mitigation requests from different DOTS clients. All conflicting mitigation requests are inactive.=94 ? [Med] A dots server can be typically instructed by a policy to discard conflicting requests. The rationale is that the provider thinks that the clients are misconfigured and something is needed to be fixed before solicited the server. The signal-channel does not need to call for a favorite action when conflicts; that is implementation- and deployment-specific. =20 =20 -Tiru =20 From: Jon Shallow [mailto:supjps-ietf@jpshallow.com]=20 Sent: Tuesday, November 28, 2017 7:45 PM To: mohamed.boucadair@orange.com; Konda, Tirumaleswar Reddy ; dots@ietf.org Subject: RE: [Dots] signal-channel: Conflict detection and notification =20 Hi Med, =20 In principal I accept the concept of your 7, 8 & 9 status which in = effect are part of the mitigation state as in a state diagram. However, having issued a =938=94 status, this then needs to transition to another state = which reflects what is actually happening =96 e.g. =932=94. =20 The actual state could immediately be sent following the reporting of = =938=94 (if Observe active), else it would need to wait until the next status = GET. It is possible that the =938=94 message gets lost, so relying on = receiving the =938=94 could be dangerous. =20 With a =939=94 response what then is the DOTS client allowed to do? - A retry of the original mitigation request is likely to fail again - If all the DOTS clients back off, then there will be no mitigation - Should there be a random back-off time before retrying? =20 What is critical is that=20 DOTS servers in the same administrative domain attempting to honor conflicting requests may flap network route or DNS information, degrading the networks attempting to participate in attack response with the DOTS clients. Should not be allowed to happen. =20 I also do not want to lose sight of=20 The notification SHOULD indicate the nature and scope of the conflict, for example, the overlapping prefix range in a conflicting mitigation request.=94 This potentially can be conveyed in the 4.09 message, or could be a new mitigation status parameter such as "additional-info" with an = appropriate text value. It could be that =93status=94 stays with =931=94 through = =936=94, and (possibly optional) =93additional-status=94 has=20 0 | This DOTS client mitigation request is being honoured 1 | DOTS Server has detected conflicting mitigation requests from = different DOTS clients. This mitigation request is currently inactive until the conflicts are resolved. Another mitigation request is active. 2 | DOTS Server has detected conflicting mitigation requests from = different DOTS clients. This mitigation request is currently active.=20 3 | DOTS Server has detected conflicting mitigation requests from = different DOTS clients. All conflicting mitigation requests are inactive. And =93additional-info=94 reports on what the nature and scope of the = conflict is. =20 Regards =20 Jon =20 From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of mohamed.boucadair@orange.com Sent: 28 November 2017 13:29 To: Jon Shallow; 'Konda, Tirumaleswar Reddy'; dots@ietf.org Subject: Re: [Dots] signal-channel: Conflict detection and notification =20 Hi Jon, all, =20 Thank you for sharing your thoughts on this. =20 I tend to allow for both 4.09 code and new status values in the spec.=20 =20 I see that you proposed this new value:=20 =3D=3D 7 | DOTS Server has detected conflicting mitigation requests from = different DOTS clients. This mitigation request is currently inactive until the conflicts are resolved. Another mitigation request is active. =3D=3D =20 Please note that a server may be instructed to adopt a more strict = behavior by deactivating all conflicting requests. Further, all DOTS clients = which issued conflicting requests should be notified, not only the one for = which a request is de-activated. As such, I=92m afraid we will need more values, = e.g., =20 =3D=3D 7 | DOTS Server has detected conflicting mitigation requests from = different DOTS clients. This mitigation request is currently inactive until the conflicts are resolved. Another mitigation request is active. 8 | DOTS Server has detected conflicting mitigation requests from = different DOTS clients. This mitigation request is currently active.=20 9 | DOTS Server has detected conflicting mitigation requests from = different DOTS clients. All conflicting mitigation requests are inactive. =3D=3D =20 For example: * If the server decides to activate only one request, then 7 will be = sent to all clients for which the request is de-activated and 8 to the client = for which the request is maintained active.=20 * If the server decides to deactivate all requests, then 9 will be sent = to all clients. =20 =20 Cheers, Med =20 De : Jon Shallow [mailto:supjps-ietf@jpshallow.com]=20 Envoy=E9 : mardi 28 novembre 2017 13:31 =C0 : 'Konda, Tirumaleswar Reddy'; BOUCADAIR Mohamed IMT/OLN; = dots@ietf.org Objet : RE: [Dots] signal-channel: Conflict detection and notification =20 Hi Tiru, =20 If Client-A has invoked a mitigation, then Client-B requests a = conflicting mitigation, if the DOTS server is only allowing the first mitigation = request to be the valid one, then the DOTS server could send back a 4.09 to Client-B. =20 However, if the DOTS server is allowed to choose the best mitigation request, decides it is Client-B, there is no simple way of sending an unsolicited 4.09 to client-A. Hence suggestion for an additional status message which can be sent to Client-A stating that Client-A has been de-selected because of a mitigation request conflict. =20 It is also possible that a mitigation state is status 1 (parameter value = =96 Table 2)) and needs to transition to another state =96 at which point = the conflict is found - possibly by the DOTS mitigator - which then needs to = be relayed back through the DOTS server. =20 Regards =20 Jon =20 From: Konda, Tirumaleswar Reddy [mailto: = TirumaleswarReddy_Konda@mcafee.com] Sent: 28 November 2017 11:42 To: Jon Shallow; mohamed.boucadair@orange.com; dots@ietf.org Subject: RE: [Dots] signal-channel: Conflict detection and notification =20 Hi Jon, =20 What is the problem if the DOTS server returns 4.09 (conflict) error response for the conflicting mitigation request from Client-A ? The above error code is already defined = https://tools.ietf.org/html/rfc8132.=20 =20 -Tiru =20 From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Jon Shallow Sent: Tuesday, November 28, 2017 4:50 PM To: mohamed.boucadair@orange.com; dots@ietf.org Subject: Re: [Dots] signal-channel: Conflict detection and notification =20 Hi Med, =20 See inline =20 Regards =20 Jon =20 From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of ietf-supjps-mohamed.boucadair@orange.com Sent: 24 November 2017 14:03 To: dots@ietf.org Subject: [Dots] signal-channel: Conflict detection and notification =20 Hi all,=20 =20 As discussed during the last IETF meeting, we are seeking for feedback = from the WG about how to address this requirement: =20 =3D=3D=3D=3D=3D=3D=3D=3D=3D SIG-009 Conflict Detection and Notification: Multiple DOTS clients controlled by a single administrative entity may send conflicting mitigation requests for pools of protected resources as a result of misconfiguration, operator error, or compromised DOTS clients. DOTS servers in the same administrative domain attempting to honor conflicting requests may flap network route or DNS information, degrading the networks attempting to participate in attack response with the DOTS clients. DOTS servers in a single administrative domain SHALL detect such conflicting requests, and SHALL notify the DOTS clients in conflict. The notification SHOULD indicate the nature and scope of the conflict, for example, the overlapping prefix range in a conflicting mitigation request. =3D=3D=3D=3D=3D=3D=3D=3D =20 For example, would it be OK if we leave implementation-specific the = criteria upon which a dots server relies to consider two requests from two = clients as conflicting, but draft-ietf-dots-signal defines only the procedure to = notify clients when a conflict is detected?=20 Jon> I agree that how this is done is implementation specific. However there is a scenario where Client-A initiates a mitigation requests which = is acted upon, Client-B does a conflicting mitigation request but the DOTS Server decides that Client-B is the =93more=94 valid mitigation request = and effectively de-activates Client-A=92s request. Table 2: draft-ietf-dots-signal-channel-09 therefore needs an additional status parameter to indicate to client-A there is a conflict and hence Client-A = is being stood down while another client is controlling the mitigation. A suggestion would be=20 =20 7 | DOTS Server has detected conflicting mitigation requests from = different DOTS clients. This mitigation request is currently inactive until the conflicts are resolved. Another mitigation request is active. =20 Jon> The DOTS client can then elect to leave in the mitigation request = (and even refresh the PUT to refresh the timeout) or delete it. Jon> I do not think it appropriate that an error message be sent back = (e.g. 4.xx) if the DOTS server immediately decides there is a conflicting = request and closes down the new PUT request unless we come up with a specific = error code so the DOTS client can understand why the request is getting = errored. =20 =20 Likewise, would it be OK if the document does not specify which of the conflicting actions is to be discarded (old, new, all) by the server, = but draft-ietf-dots-signal defines how to inform clients about which action = was enforced by the server?=20 =20 Jon> Again, I think that this would be implementation specific. The suggested Table 2: entry above would cover this as well. The DOTS = client just needs to know it has been de-selected / discarded =96 I don=92t = think the DOTS client needs to know how / why the DOTS server chose that = particular DOTS client. =20 Cheers, Med=20 ------=_NextPart_000_0042_01D369C6.B17A4DE0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Tiru et al,

 

I have been having a = think about this one, and do not know (from a DOTS client coding = perspective) what to do if using 7, 8 and 9 method – in particular = 8 (DOTS Server has = detected conflicting mitigation requests from different DOTS = clients.  This mitigation request is currently active.).=A0 = “currently active” could be one of status 1 through 5.=A0 =

 

An answer = could be to have 7, 8 becomes 8-12 (to mirror the 1-5 status) and 9 = becomes 13 as an alternative to “additional-status”.=A0 I am = agnostic here as to which way, but do need to know the fact that the = original 8 has a status subtype of 1-5, or that 1-5 have a conflict = status sub-type.

 

The use of 4.09 as an = immediate response to a mitigation request should be documented as a = valid response (as only few people are SME on all the other RFCs!).=A0 = 7, 8 & 9 (or the alternatives) are for after the mitigation request = has been accepted.

 

At any point the DOTS = server can elect to change the status on detection of a conflict (which = could be after a DOTS mitigator detects a conflict – possibly from = 2 different DOTS servers and reports it back to DOTS server (how – = out of scope)).=A0 The mitigation request will, from the DOTS client = perspective, remain in that conflict state (status) until either the = conflict is resolved (e.g. another DOTS client backs off), or the DOTS = client issues a DELETE.

 

The DOTS client can = monitor the status using Observe.

 

If the DOTS client is = intelligent enough (assume in the general case unlikely), there is = nothing stopping it DELETE current mitigation request and issue a new = one with the conflict potentially resolved.

 

For reporting the = conflict as per

 

The notification SHOULD indicate the = nature and scope of the conflict,

for example, the overlapping prefix range = in a conflicting mitigation request.”

 

I would suggest an = additional (optional) “additional-info” reports on what the = nature and scope of the conflict is.=A0 This conflict report cannot be = too wordy due to packet MTU limitations.=A0 It may be that we define = different conflict codes, in which case “additional-info” = could be “conflict-code”.

 

Regards

 

Jon

 

From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of = Konda, Tirumaleswar Reddy
Sent: 30 November 2017 = 09:41
To: mohamed.boucadair@orange.com; Jon Shallow; = dots@ietf.org
Subject: Re: [Dots] signal-channel: Conflict = detection and notification

 

The proposal works for me, is the = plan to add 7, 8 and 9 status or add a new = “additional-status” parameter ?

 

-Tiru

 

From: mohamed.boucadair@orange.com= [mailto:mohamed.boucadair@ora= nge.com]
Sent: Wednesday, November 29, 2017 12:02 = PM
To: Konda, Tirumaleswar Reddy <TirumaleswarReddy_Kond= a@McAfee.com>; Jon Shallow <supjps-ietf@jpshallow.com&g= t;; dots@ietf.org
Subject: RE: = [Dots] signal-channel: Conflict detection and = notification

 

Hi Tiru,

 

I agree with you that discarding all conflicting = requests may not be helpful in some cases. In the same way that someone = can argue that selecting only one request among conflicting ones may not = be useful because the server picked the wrong one. =   

 

I do prefer to leave this to implementation/deployment = as a policy to be supplied. That policy will instruct the dots server = about the behavior to follow based one specific information that is = available for a given deployment:  

=B7       = Pick one and deactivate all the others based on some = criteria

=B7       = Activate all of them

=B7       = De-activate all of them

 

Cheers,

Med =

 

De : Dots [mailto:dots-bounces@ietf.org] = De la part de Konda, Tirumaleswar Reddy
Envoy=E9 : = mercredi 29 novembre 2017 06:39
=C0 : BOUCADAIR Mohamed = IMT/OLN; Jon Shallow; dots@ietf.org
Objet : = Re: [Dots] signal-channel: Conflict detection and = notification

 

Hi = Med,

 

In a deployment scenario with a = DDoS Detector (or a on premise DDoS mitigation system) acting as DOTS = clients and a web server with in-built DDoS detection capability. The = web server may not have as much visibility into the extent of the DDoS = attack as the DDoS Detector (or IDMS) and there will be conflicting = mitigation requests from different DOTS clients, discarding all the = mitigation requests from different clients will make the mechanism not = useful.

 

-Tiru

 

From: mohamed.boucadair@orange.com= [mailto:mohamed.boucadair@ora= nge.com]
Sent: Tuesday, November 28, 2017 8:55 = PM
To: Konda, Tirumaleswar Reddy <TirumaleswarReddy_Kond= a@McAfee.com>; Jon Shallow <supjps-ietf@jpshallow.com&g= t;; dots@ietf.org
Subject: RE: = [Dots] signal-channel: Conflict detection and = notification

 

Tiru,

 

Please see inline.

 

Cheers,

Med

 

De : Dots [mailto:dots-bounces@ietf.org] = De la part de Konda, Tirumaleswar Reddy
Envoy=E9 : = mardi 28 novembre 2017 16:02
=C0 : Jon Shallow; BOUCADAIR = Mohamed IMT/OLN; dots@ietf.org
Objet : = Re: [Dots] signal-channel: Conflict detection and = notification

 

Within a = administrative domain, there won’t be many different DOTS clients = raising conflicting mitigation requests for the same target, the = conflict may arise between a DDoS Detector (or a on premise DDoS = mitigation system) acting as DOTS clients and a web server with in-built = DDoS detection capability. 

[Med] I don’t think = that we can speculate about the nature of the conflicts that may happen. = Misconfigured and corrupted software instances may happen. =

 

Under what conditions does the DOTS = server return “DOTS Server has detected conflicting mitigation = requests from different DOTS clients.  All conflicting mitigation = requests are inactive.” ?

[Med] A dots server can be = typically instructed by a policy to discard conflicting requests. The = rationale is that the provider thinks that the clients are misconfigured = and something is needed to be fixed before solicited the server. The = signal-channel does not need to call for a favorite action when = conflicts; that is implementation- and deployment-specific. =  

 

-Tiru

 

From: Jon Shallow [mailto:supjps-ietf@jpshallow.co= m]
Sent: Tuesday, November 28, 2017 7:45 PM
To: = mohamed.boucadair@orange.com= ; Konda, Tirumaleswar Reddy <TirumaleswarReddy_Kond= a@McAfee.com>; dots@ietf.org
Subject: RE: = [Dots] signal-channel: Conflict detection and = notification

 

Hi Med,

 

In principal I accept = the concept of your 7, 8 & 9 status which in effect are part of the = mitigation state as in a state diagram.  However, having issued a = “8” status, this then needs to transition to another state = which reflects what is actually happening – e.g. = “2”.

 

The actual state could = immediately be sent following the reporting of “8” (if = Observe active), else it would need to wait until the next status = GET.  It is possible that the “8” message gets lost, so = relying on receiving the “8” could be = dangerous.

 

With a “9” = response what then is the DOTS client allowed to = do?

- A retry of the original mitigation request is = likely to fail again

- If all the DOTS clients back off, then there = will be no mitigation

- Should there be a random back-off time before = retrying?

 

What is critical is that =

      DOTS = servers in the same administrative domain attempting to = honor

      conflicting = requests may flap network route or DNS = information,

      degrading = the networks attempting to participate in attack

      response = with the DOTS clients.

Should not be allowed to = happen.

 

I also do not want to = lose sight of

The notification SHOULD indicate the = nature and scope of the conflict,

for example, the overlapping prefix range = in a conflicting mitigation request.”

This potentially can be = conveyed in the 4.09 message, or could be a new mitigation status = parameter such as "additional-info" with an appropriate text = value.  It could be that “status” stays with = “1” through “6”, and (possibly optional) = “additional-status” has

0 | This DOTS client = mitigation request is being honoured

1 | DOTS = Server has detected conflicting mitigation requests from different DOTS = clients.  This mitigation request is currently inactive until the = conflicts are resolved. Another mitigation request is = active.

2 | DOTS Server has detected conflicting = mitigation requests from different DOTS clients.  This mitigation = request is currently active.

3 | DOTS = Server has detected conflicting mitigation requests from different DOTS = clients.  All conflicting mitigation requests are = inactive.

And “additional-info” reports on = what the nature and scope of the conflict is.

 

Regards

 

Jon

 

From: Dots [mailto: dots-bounces@ietf.org] On = Behalf Of mohamed.boucadair@orange.com=
Sent: 28 November 2017 13:29
To: Jon Shallow; = 'Konda, Tirumaleswar Reddy'; dots@ietf.org
Subject: Re: = [Dots] signal-channel: Conflict detection and = notification

 

Hi Jon, all,

 

Thank you for sharing your thoughts on = this.

 

I tend to allow for both 4.09 code and new status = values in the spec.

 

I see that you proposed this new value: =

=3D=3D

7 | DOTS Server has detected = conflicting mitigation requests from different DOTS clients.  This = mitigation request is currently inactive until the conflicts are = resolved. Another mitigation request is active.

=3D=3D

 

Please note that a server may be instructed to adopt a = more strict behavior by deactivating all conflicting requests. Further, = all DOTS clients which issued conflicting requests should be notified, = not only the one for which a request is de-activated. As such, I’m = afraid we will need more values, e.g.,

 

=3D=3D

7 | DOTS Server has detected = conflicting mitigation requests from different DOTS clients.  This = mitigation request is currently inactive until the conflicts are = resolved. Another mitigation request is active.

8 | DOTS = Server has detected conflicting mitigation requests from different DOTS = clients.  This mitigation request is currently active. =

9 | DOTS Server has detected conflicting = mitigation requests from different DOTS clients.  All conflicting = mitigation requests are inactive.

=3D=3D

 

For example:

* If = the server decides to activate only one request, then 7 will be sent to = all clients for which the request is de-activated and 8 to the client = for which the request is maintained active.

* If = the server decides to deactivate all requests, then 9 will be sent to = all clients.  

 

Cheers,

Med

 

De : Jon Shallow [mailto:supjps-ietf@jpshallow.co= m]
Envoy=E9 : mardi 28 novembre 2017 = 13:31
=C0 : 'Konda, Tirumaleswar Reddy'; BOUCADAIR Mohamed IMT/OLN; dots@ietf.org
Objet : = RE: [Dots] signal-channel: Conflict detection and = notification

 

Hi Tiru,

 

If Client-A has invoked = a mitigation, then Client-B requests a conflicting mitigation, if the = DOTS server is only allowing the first mitigation request to be the = valid one, then the DOTS server could send back a 4.09 to = Client-B.

 

However, if the DOTS = server is allowed to choose the best mitigation request, decides it is = Client-B, there is no simple way of sending an unsolicited 4.09 to = client-A.  Hence suggestion for an additional status message which = can be sent to Client-A stating that Client-A has been de-selected = because of a mitigation request conflict.

 

It is also possible that = a mitigation state is status 1 (parameter value – Table 2)) and = needs to transition to another state – at which point the conflict = is found - possibly by the DOTS mitigator - which then needs to be = relayed back through the DOTS server.

 

Regards

 

Jon

 

From: Konda, Tirumaleswar Reddy [mailto: TirumaleswarReddy_Kond= a@mcafee.com]
Sent: 28 November 2017 11:42
To: = Jon Shallow; mohamed.boucadair@orange.com= ; dots@ietf.org
Subject: RE: = [Dots] signal-channel: Conflict detection and = notification

 

Hi = Jon,

 

What is the problem if the DOTS = server returns 4.09 (conflict) error response for the conflicting = mitigation request from Client-A ?

The above error code is already = defined https://tools.ietf.org/html/rfc8132<= /span>. =

 

-Tiru

 

From: Dots [mailto:dots-bounces@ietf.org] = On Behalf Of Jon Shallow
Sent: Tuesday, November 28, = 2017 4:50 PM
To: mohamed.boucadair@orange.com= ; dots@ietf.org
Subject: Re: = [Dots] signal-channel: Conflict detection and = notification

 

Hi Med,

 

See = inline

 

Regards

 

Jon

 

From: Dots [mailto: dots-bounces@ietf.org] On = Behalf Of ietf-supjps-moha= med.boucadair@orange.com
Sent: 24 November 2017 = 14:03
To: dots@ietf.org
Subject: = [Dots] signal-channel: Conflict detection and = notification

 

Hi = all,

 

As = discussed during the last IETF meeting, we are seeking for feedback from = the WG about how to address this requirement:

 

=3D=3D=3D=3D=3D=3D=3D=3D=3D

   SIG-009  Conflict = Detection and Notification: Multiple DOTS = clients

      controlled = by a single administrative entity may send = conflicting

      mitigation = requests for pools of protected resources as a = result

      of = misconfiguration, operator error, or compromised DOTS = clients.

      DOTS = servers in the same administrative domain attempting to = honor

      conflicting = requests may flap network route or DNS = information,

      degrading = the networks attempting to participate in attack

      response = with the DOTS clients.  DOTS servers in a = single

      = administrative domain SHALL detect such conflicting requests, = and

      SHALL = notify the DOTS clients in conflict.  The = notification

      SHOULD = indicate the nature and scope of the conflict, for = example,

      the = overlapping prefix range in a conflicting mitigation = request.

=3D=3D=3D=3D=3D=3D=3D=3D

 

For = example, would it be OK if we leave implementation-specific the criteria = upon which a dots server relies to consider two requests from two = clients as conflicting, but draft-ietf-dots-signal defines only the = procedure to notify clients when a conflict is detected? =

Jon> I agree that how this is done is = implementation specific.  However there is a scenario where = Client-A initiates a mitigation requests which is acted upon, Client-B = does a conflicting mitigation request but the DOTS Server decides that = Client-B is the “more” valid mitigation request and = effectively de-activates Client-A’s request.  Table 2: = draft-ietf-dots-signal-channel-09 therefore needs an additional status = parameter to indicate to client-A there is a conflict and hence Client-A = is being stood down while another client is controlling the = mitigation.  A suggestion would be

 

7 | DOTS = Server has detected conflicting mitigation requests from different DOTS = clients.  This mitigation request is currently inactive until the = conflicts are resolved. Another mitigation request is = active.

 

Jon> The = DOTS client can then elect to leave in the mitigation request (and even = refresh the PUT to refresh the timeout) or delete = it.

Jon> I do not think it appropriate that an = error message be sent back (e.g. 4.xx) if the DOTS server immediately = decides there is a conflicting request and closes down the new PUT = request unless we come up with a specific error code so the DOTS client = can understand why the request is getting = errored.

 

 

Likewise, would it be OK if the document does not specify which of = the conflicting actions is to be discarded (old, new, all) by the = server, but draft-ietf-dots-signal defines how to inform clients about = which action was enforced by the server?

 

Jon> = Again, I think that this would be implementation specific.  The = suggested Table 2: entry above would cover this as well.  The DOTS = client just needs to know it has been de-selected / discarded – I = don’t think the DOTS client needs to know how / why the DOTS = server chose that particular DOTS client.

 

Cheers,

Med =

------=_NextPart_000_0042_01D369C6.B17A4DE0-- From nobody Thu Nov 30 02:42:25 2017 Return-Path: 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 79CD1129427 for ; Thu, 30 Nov 2017 02:42:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.999 X-Spam-Level: X-Spam-Status: No, score=-6.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 ShXnEz48M7lt for ; Thu, 30 Nov 2017 02:42:21 -0800 (PST) Received: from MIVWSMAILOUT1.mcafee.com (mivwsmailout1.mcafee.com [161.69.47.167]) (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 EF652129415 for ; Thu, 30 Nov 2017 02:42:20 -0800 (PST) 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=1512038515; 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: x-originating-ip:x-ms-publictraffictype:x-microsoft-exchange-diagnostics: x-ms-exchange-antispam-srfa-diagnostics:x-ms-office365-filtering-correlation-id: x-microsoft-antispam:x-ms-traffictypediagnostic: x-microsoft-antispam-prvs:x-exchange-antispam-report-test: x-exchange-antispam-report-cfa-test:x-forefront-prvs: x-forefront-antispam-report:received-spf:authentication-results: spamdiagnosticoutput:spamdiagnosticmetadata: Content-Type: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-Transport-CrossTenantHeadersStamped: X-OriginatorOrg:X-NAI-Spam-Flag:X-NAI-Spam-Level: X-NAI-Spam-Threshold:X-NAI-Spam-Score:X-NAI-Spam-Version; bh=XH0Az9P8RpBMdW7wGEYAhoyenqHCFjRhKG3pwC /lVo0=; b=iGzrkAJZgsD8WYgchOndZ8nBug2iXt7s5xovpGwr QK9dM3CtKZooZHUVmwFC2nqGGhiTq6NBQpqrRJgdWlAI23qbT/ M9e6CxOaOBud/DXvuuwFaKX9nwIek0fmaBTbgSbDteEmfl8iv9 cbO5AFi+toj/VqWCAOalbD09VSprgTk= Received: from MIVEXAPP1N02.corpzone.internalzone.com (unknown [10.48.48.89]) by MIVWSMAILOUT1.mcafee.com with smtp id 075f_8b31_5bc6c303_509b_44be_ad1a_49c538261728; Thu, 30 Nov 2017 04:41:54 -0600 Received: from MIVEXUSR1N06.corpzone.internalzone.com (10.48.48.86) by MIVEXAPP1N02.corpzone.internalzone.com (10.48.48.89) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Thu, 30 Nov 2017 05:41:53 -0500 Received: from MIVO365EDGE4.corpzone.internalzone.com (10.48.176.87) by MIVEXUSR1N06.corpzone.internalzone.com (10.48.48.86) with Microsoft SMTP Server (TLS) id 15.0.1347.2 via Frontend Transport; Thu, 30 Nov 2017 05:41:53 -0500 Received: from NAM02-BL2-obe.outbound.protection.outlook.com (10.48.176.243) by edge.mcafee.com (10.48.176.87) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Thu, 30 Nov 2017 05:41:46 -0500 Received: from DM5PR16MB1788.namprd16.prod.outlook.com (10.172.44.144) by DM5PR16MB1788.namprd16.prod.outlook.com (10.172.44.144) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.260.4; Thu, 30 Nov 2017 10:41:45 +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.20.0260.007; Thu, 30 Nov 2017 10:41:45 +0000 From: "Konda, Tirumaleswar Reddy" To: "mohamed.boucadair@orange.com" , Jon Shallow , "dots@ietf.org" Thread-Topic: [Dots] signal-channel: Conflict detection and notification Thread-Index: AQI5QycoOO+6Sl3hDoQKXRH887G99aJd55JwgAAKs5CAABDPgIAAEDEAgAAM/YCAAAnqQIAACYkAgADteRCAABAggIABvsNQgAAU9YCAAAQ9wA== Date: Thu, 30 Nov 2017 10:41:45 +0000 Message-ID: References: <787AE7BB302AE849A7480A190F8B93300A07F4E4@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <009b01d3683a$c6158f90$5240aeb0$@jpshallow.com> <00e201d36844$b1b39ec0$151adc40$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93300A0819DB@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <011301d36853$48efb680$dacf2380$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93300A081B18@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93300A08307A@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93300A084012@OPEXCLILMA3.corporate.adroot.infra.ftgroup> In-Reply-To: <787AE7BB302AE849A7480A190F8B93300A084012@OPEXCLILMA3.corporate.adroot.infra.ftgroup> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [103.245.47.20] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DM5PR16MB1788; 6:7UQmzufc2WkbOrpDj7YLK7MstCB1PRKbudccDgD/f3sIvs9xOQWs9MelVtBwps7PWOvvna7F3MfIQ+m7CTKEkcR4g4AXLHvJYtkIGqmBf9midWqSHGy/LoKNUesCOrZgdvXx7LOEPmoJagjByr7v9UeI+vk624gqkqmQKcf9QcDQb2bdDOdNC45q/HvPJhZs0tOmztYvt2EaWlMuC27MtMBOxjBz1T5Y3zQHmTscNsGsqNa7Xkhw8RT+0OyYYnAuH7hCv30HrWiPuqxZ4XcXpMxYz25jMHStBkaoQXBE5LWYPiqwS1M99a2+PZZDEJtizANAv783eXUV4EidfNdIsUsAkojIVNWo4+Ib1Ks7v00=; 5:IGjYa5mziDtbJe4l5s09S1OjnuETIHPuCPAijpzmiioDe6UF5okfAW7+yh0lAW3VIUjj89r7/i1CDj66J/vU7tjDG1mME0+sK591KNrRHHi9XjkP77RLgSO1gDMploPZYudliE0ePuaTp/ww1eXL21oMoE9VesQQZ0FIQo7D2NQ=; 24:yxGiVgxu+CpzO6TnJEvDpPDTRISf0eXjyjtZeaLAUui0R1t4cq1Lvi/Cnql0LD4eh6FwQ7fHM2Bm4nmCv9WYlqqXVGmZzIG9dubKyFTn+eQ=; 7:mW9ImMDfBEWt1g+FKRKsmbea2XYUgc65Eee9EMgsa3d2DFk6Aykan9/75cg3BqTWBlKWzNYDNucWWFoqGbj+XMURV7nSWQsEVAw/rEkHUb4IAJ/RsOTR3qLoPgILlbGUdlPuw1TBzwwTl0ZPgkrsfqXYjrUaVC1s+o/idgxv3nZOsAR0qTQKeSXx5xZQliTDZYWGSV0VE9KR84MqQTAtlLm9RYvJX0qWFXyk0gPnyiZnwSJKUUsqGgcCm9Wifm2H x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: ce2d6eb8-e517-4dba-cfb5-08d537def3c1 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(5600026)(4604075)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(2017052603284); SRVR:DM5PR16MB1788; x-ms-traffictypediagnostic: DM5PR16MB1788: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(190756311086443)(158342451672863)(20558992708506)(227612066756510)(18271650672692)(21748063052155)(211171220733660)(123452027830198); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(2401047)(8121501046)(5005006)(10201501046)(3002001)(93006095)(93001095)(3231022)(6041248)(20161123558100)(20161123555025)(20161123564025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123562025)(20161123560025)(6072148)(201708071742011); SRVR:DM5PR16MB1788; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:DM5PR16MB1788; x-forefront-prvs: 05079D8470 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(376002)(346002)(366004)(53754006)(32952001)(199003)(189002)(51444003)(236005)(189998001)(7110500001)(561944003)(33656002)(106356001)(6506006)(105586002)(2900100001)(55016002)(2906002)(790700001)(3846002)(6116002)(10710500007)(2501003)(3280700002)(14454004)(50986010)(54356010)(3660700001)(110136005)(76176010)(478600001)(966005)(68736007)(606006)(15650500001)(72206003)(102836003)(7696005)(8936002)(93886005)(2420400007)(25786009)(316002)(80792005)(99286004)(97736004)(8676002)(7736002)(345774005)(81166006)(74316002)(6436002)(81156014)(229853002)(54896002)(101416001)(53946003)(66066001)(53936002)(2950100002)(77096006)(6246003)(19609705001)(86362001)(53546010)(6306002)(5660300001)(9686003)(85282002)(559001)(579004); DIR:OUT; SFP:1101; SCL:1; SRVR:DM5PR16MB1788; H:DM5PR16MB1788.namprd16.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: McAfee.com does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=TirumaleswarReddy_Konda@McAfee.com; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_DM5PR16MB1788984AF407D432B143CDCEEA380DM5PR16MB1788namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: ce2d6eb8-e517-4dba-cfb5-08d537def3c1 X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Nov 2017 10:41:45.3531 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4943e38c-6dd4-428c-886d-24932bc2d5de X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR16MB1788 X-OriginatorOrg: mcafee.com X-NAI-Spam-Flag: NO X-NAI-Spam-Level: X-NAI-Spam-Threshold: 15 X-NAI-Spam-Score: 0.9 X-NAI-Spam-Version: 2.3.0.9418 : core <6169> : inlines <6195> : streams <1771760> : uri <2542650> Archived-At: Subject: Re: [Dots] signal-channel: Conflict detection and notification 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Nov 2017 10:42:24 -0000 --_000_DM5PR16MB1788984AF407D432B143CDCEEA380DM5PR16MB1788namp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Looks good to me. -Tiru From: mohamed.boucadair@orange.com [mailto:mohamed.boucadair@orange.com] Sent: Thursday, November 30, 2017 3:56 PM To: Konda, Tirumaleswar Reddy ; Jon Sha= llow ; dots@ietf.org Subject: RE: [Dots] signal-channel: Conflict detection and notification Hi Tiru, With the "additional-status" parameter, and given the current values define= d in Table 2, I don't see which status code to return when "additional-stat= us" is set to "3 | DOTS Server has detected conflicting mitigation requests= from different DOTS clients. All conflicting mitigation requests are inac= tive". I'm afraid new status codes should be defined for this to work (e.g.= , "X: Attack mitigation is withdrawn", "Y: Attack mitigation is rejected"). Note that in both approaches, we will need to supply additional information= to characterize the conflict (conflict-information). This information shou= ld be returned to all clients. So, what about considering this direction? - Update the status table with these NEW codes: o 7: Attack mitigation is withdrawn o 8: Attack mitigation is rejected - Allow for including 'additional-status'. Define 'conflict-information' = under that parent; 'conflict-information' can include the following sub-par= ameters: o conflict-status: three codes =A7 1 | DOTS Server has detected conflicting mitigation requests from diff= erent DOTS clients. This mitigation request is currently inactive until th= e conflicts are resolved. Another mitigation request is active. =A7 2 | DOTS Server has detected conflicting mitigation requests from diff= erent DOTS clients. This mitigation request is currently active. =A7 3 | DOTS Server has detected conflicting mitigation requests from diff= erent DOTS clients. All conflicting mitigation requests are inactive. o conflict-scope: same structure as "scope" Cheers, Med De : Konda, Tirumaleswar Reddy [mailto:TirumaleswarReddy_Konda@McAfee.com] Envoy=E9 : jeudi 30 novembre 2017 10:41 =C0 : BOUCADAIR Mohamed IMT/OLN; Jon Shallow; dots@ietf.org Objet : RE: [Dots] signal-channel: Conflict detection and notification The proposal works for me, is the plan to add 7, 8 and 9 status or add a ne= w "additional-status" parameter ? -Tiru From: mohamed.boucadair@orange.com [ma= ilto:mohamed.boucadair@orange.com] Sent: Wednesday, November 29, 2017 12:02 PM To: Konda, Tirumaleswar Reddy >; Jon Shallow >; dots@ietf.org Subject: RE: [Dots] signal-channel: Conflict detection and notification Hi Tiru, I agree with you that discarding all conflicting requests may not be helpfu= l in some cases. In the same way that someone can argue that selecting only= one request among conflicting ones may not be useful because the server pi= cked the wrong one. I do prefer to leave this to implementation/deployment as a policy to be su= pplied. That policy will instruct the dots server about the behavior to fol= low based one specific information that is available for a given deployment= : * Pick one and deactivate all the others based on some criteria * Activate all of them * De-activate all of them Cheers, Med De : Dots [mailto:dots-bounces@ietf.org] De la part de Konda, Tirumaleswar = Reddy Envoy=E9 : mercredi 29 novembre 2017 06:39 =C0 : BOUCADAIR Mohamed IMT/OLN; Jon Shallow; dots@ietf.org Objet : Re: [Dots] signal-channel: Conflict detection and notification Hi Med, In a deployment scenario with a DDoS Detector (or a on premise DDoS mitigat= ion system) acting as DOTS clients and a web server with in-built DDoS dete= ction capability. The web server may not have as much visibility into the e= xtent of the DDoS attack as the DDoS Detector (or IDMS) and there will be c= onflicting mitigation requests from different DOTS clients, discarding all = the mitigation requests from different clients will make the mechanism not = useful. -Tiru From: mohamed.boucadair@orange.com [ma= ilto:mohamed.boucadair@orange.com] Sent: Tuesday, November 28, 2017 8:55 PM To: Konda, Tirumaleswar Reddy >; Jon Shallow >; dots@ietf.org Subject: RE: [Dots] signal-channel: Conflict detection and notification Tiru, Please see inline. Cheers, Med De : Dots [mailto:dots-bounces@ietf.org] De la part de Konda, Tirumaleswar = Reddy Envoy=E9 : mardi 28 novembre 2017 16:02 =C0 : Jon Shallow; BOUCADAIR Mohamed IMT/OLN; dots@ietf.org Objet : Re: [Dots] signal-channel: Conflict detection and notification Within a administrative domain, there won't be many different DOTS clients = raising conflicting mitigation requests for the same target, the conflict m= ay arise between a DDoS Detector (or a on premise DDoS mitigation system) a= cting as DOTS clients and a web server with in-built DDoS detection capabil= ity. [Med] I don't think that we can speculate about the nature of the conflicts= that may happen. Misconfigured and corrupted software instances may happen= . Under what conditions does the DOTS server return "DOTS Server has detected= conflicting mitigation requests from different DOTS clients. All conflict= ing mitigation requests are inactive." ? [Med] A dots server can be typically instructed by a policy to discard conf= licting requests. The rationale is that the provider thinks that the client= s are misconfigured and something is needed to be fixed before solicited th= e server. The signal-channel does not need to call for a favorite action wh= en conflicts; that is implementation- and deployment-specific. -Tiru From: Jon Shallow [mailto:supjps-ietf@jpshallow.com] Sent: Tuesday, November 28, 2017 7:45 PM To: mohamed.boucadair@orange.com; Kond= a, Tirumaleswar Reddy >; dots@ietf.org Subject: RE: [Dots] signal-channel: Conflict detection and notification Hi Med, In principal I accept the concept of your 7, 8 & 9 status which in effect a= re part of the mitigation state as in a state diagram. However, having iss= ued a "8" status, this then needs to transition to another state which refl= ects what is actually happening - e.g. "2". The actual state could immediately be sent following the reporting of "8" (= if Observe active), else it would need to wait until the next status GET. = It is possible that the "8" message gets lost, so relying on receiving the = "8" could be dangerous. With a "9" response what then is the DOTS client allowed to do? - A retry of the original mitigation request is likely to fail again - If all the DOTS clients back off, then there will be no mitigation - Should there be a random back-off time before retrying? What is critical is that DOTS servers in the same administrative domain attempting to honor conflicting requests may flap network route or DNS information, degrading the networks attempting to participate in attack response with the DOTS clients. Should not be allowed to happen. I also do not want to lose sight of The notification SHOULD indicate the nature and scope of the conflict, for example, the overlapping prefix range in a conflicting mitigation reque= st." This potentially can be conveyed in the 4.09 message, or could be a new mit= igation status parameter such as "additional-info" with an appropriate text= value. It could be that "status" stays with "1" through "6", and (possibl= y optional) "additional-status" has 0 | This DOTS client mitigation request is being honoured 1 | DOTS Server has detected conflicting mitigation requests from different= DOTS clients. This mitigation request is currently inactive until the con= flicts are resolved. Another mitigation request is active. 2 | DOTS Server has detected conflicting mitigation requests from different= DOTS clients. This mitigation request is currently active. 3 | DOTS Server has detected conflicting mitigation requests from different= DOTS clients. All conflicting mitigation requests are inactive. And "additional-info" reports on what the nature and scope of the conflict = is. Regards Jon From: Dots [mailto: dots-bounces@ietf.org] On= Behalf Of mohamed.boucadair@orange.com Sent: 28 November 2017 13:29 To: Jon Shallow; 'Konda, Tirumaleswar Reddy'; dots@ietf.org Subject: Re: [Dots] signal-channel: Conflict detection and notification Hi Jon, all, Thank you for sharing your thoughts on this. I tend to allow for both 4.09 code and new status values in the spec. I see that you proposed this new value: =3D=3D 7 | DOTS Server has detected conflicting mitigation requests from different= DOTS clients. This mitigation request is currently inactive until the con= flicts are resolved. Another mitigation request is active. =3D=3D Please note that a server may be instructed to adopt a more strict behavior= by deactivating all conflicting requests. Further, all DOTS clients which = issued conflicting requests should be notified, not only the one for which = a request is de-activated. As such, I'm afraid we will need more values, e.= g., =3D=3D 7 | DOTS Server has detected conflicting mitigation requests from different= DOTS clients. This mitigation request is currently inactive until the con= flicts are resolved. Another mitigation request is active. 8 | DOTS Server has detected conflicting mitigation requests from different= DOTS clients. This mitigation request is currently active. 9 | DOTS Server has detected conflicting mitigation requests from different= DOTS clients. All conflicting mitigation requests are inactive. =3D=3D For example: * If the server decides to activate only one request, then 7 will be sent t= o all clients for which the request is de-activated and 8 to the client for= which the request is maintained active. * If the server decides to deactivate all requests, then 9 will be sent to = all clients. Cheers, Med De : Jon Shallow [mailto:supjps-ietf@jpshallow.com] Envoy=E9 : mardi 28 novembre 2017 13:31 =C0 : 'Konda, Tirumaleswar Reddy'; BOUCADAIR Mohamed IMT/OLN; dots@ietf.org= Objet : RE: [Dots] signal-channel: Conflict detection and notification Hi Tiru, If Client-A has invoked a mitigation, then Client-B requests a conflicting = mitigation, if the DOTS server is only allowing the first mitigation reques= t to be the valid one, then the DOTS server could send back a 4.09 to Clien= t-B. However, if the DOTS server is allowed to choose the best mitigation reques= t, decides it is Client-B, there is no simple way of sending an unsolicited= 4.09 to client-A. Hence suggestion for an additional status message which= can be sent to Client-A stating that Client-A has been de-selected because= of a mitigation request conflict. It is also possible that a mitigation state is status 1 (parameter value - = Table 2)) and needs to transition to another state - at which point the con= flict is found - possibly by the DOTS mitigator - which then needs to be re= layed back through the DOTS server. Regards Jon From: Konda, Tirumaleswar Reddy [mailto: TirumaleswarReddy_Konda@mcafee.com= ] Sent: 28 November 2017 11:42 To: Jon Shallow; mohamed.boucadair@orange.com; dots@ietf.org Subject: RE: [Dots] signal-channel: Conflict detection and notification Hi Jon, What is the problem if the DOTS server returns 4.09 (conflict) error respon= se for the conflicting mitigation request from Client-A ? The above error code is already defined https://tools.ietf.org/html/rfc8132= . -Tiru From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Jon Shallow Sent: Tuesday, November 28, 2017 4:50 PM To: mohamed.boucadair@orange.com; dots= @ietf.org Subject: Re: [Dots] signal-channel: Conflict detection and notification Hi Med, See inline Regards Jon From: Dots [mailto: dots-bounces@ietf.org] On= Behalf Of ietf-supjps-mohamed.boucadair@orange.com Sent: 24 November 2017 14:03 To: dots@ietf.org Subject: [Dots] signal-channel: Conflict detection and notification Hi all, As discussed during the last IETF meeting, we are seeking for feedback from= the WG about how to address this requirement: =3D=3D=3D=3D=3D=3D=3D=3D=3D SIG-009 Conflict Detection and Notification: Multiple DOTS clients controlled by a single administrative entity may send conflicting mitigation requests for pools of protected resources as a result of misconfiguration, operator error, or compromised DOTS clients. DOTS servers in the same administrative domain attempting to honor conflicting requests may flap network route or DNS information, degrading the networks attempting to participate in attack response with the DOTS clients. DOTS servers in a single administrative domain SHALL detect such conflicting requests, and SHALL notify the DOTS clients in conflict. The notification SHOULD indicate the nature and scope of the conflict, for example, the overlapping prefix range in a conflicting mitigation request. =3D=3D=3D=3D=3D=3D=3D=3D For example, would it be OK if we leave implementation-specific the criteri= a upon which a dots server relies to consider two requests from two clients= as conflicting, but draft-ietf-dots-signal defines only the procedure to n= otify clients when a conflict is detected? Jon> I agree that how this is done is implementation specific. However the= re is a scenario where Client-A initiates a mitigation requests which is ac= ted upon, Client-B does a conflicting mitigation request but the DOTS Serve= r decides that Client-B is the "more" valid mitigation request and effectiv= ely de-activates Client-A's request. Table 2: draft-ietf-dots-signal-chann= el-09 therefore needs an additional status parameter to indicate to client-= A there is a conflict and hence Client-A is being stood down while another = client is controlling the mitigation. A suggestion would be 7 | DOTS Server has detected conflicting mitigation requests from different= DOTS clients. This mitigation request is currently inactive until the con= flicts are resolved. Another mitigation request is active. Jon> The DOTS client can then elect to leave in the mitigation request (and= even refresh the PUT to refresh the timeout) or delete it. Jon> I do not think it appropriate that an error message be sent back (e.g.= 4.xx) if the DOTS server immediately decides there is a conflicting reques= t and closes down the new PUT request unless we come up with a specific err= or code so the DOTS client can understand why the request is getting errore= d. Likewise, would it be OK if the document does not specify which of the conf= licting actions is to be discarded (old, new, all) by the server, but draft= -ietf-dots-signal defines how to inform clients about which action was enfo= rced by the server? Jon> Again, I think that this would be implementation specific. The sugges= ted Table 2: entry above would cover this as well. The DOTS client just ne= eds to know it has been de-selected / discarded - I don't think the DOTS cl= ient needs to know how / why the DOTS server chose that particular DOTS cli= ent. Cheers, Med --_000_DM5PR16MB1788984AF407D432B143CDCEEA380DM5PR16MB1788namp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Looks goo= d to me.

&nbs= p;

-Tiru

 

From:<= /span> mohamed.boucadair@ora= nge.com [mailto:mohamed.boucadair@orange.com]
Sent: Thursday, November 30, 2017 3:56 PM
To: Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@McAfee.com= >; Jon Shallow <supjps-ietf@jpshallow.com>; dots@ietf.org
Subject: RE: [Dots] signal-channel: Conflict detection and notificat= ion

 

Hi Tiru,

 

With the “additional-status” param= eter, and given the current values defined in Table 2, I don’t see wh= ich status code to return when “additional-status” is set to &#= 8220;3 | DOTS Server has detected conflicting mitigation requests from different = DOTS clients.  All conflicting mitigation requests are inactive”= . I’m afraid new status codes should be defined for this to work (e.g= ., “X: Attack mitigation is withdrawn”, “Y: Attack mitigation is rejected”).

 

Note that in both approaches, we will need to = supply additional information to characterize the conflict (conflict-inform= ation). This information should be returned to all clients.

 

So, what about considering this direction?

-   Update the st= atus table with these NEW codes:

o   7: Attack mit= igation is withdrawn

o   8: Attack mit= igation is rejected

-   Allow for inc= luding ‘additional-status’. Define ‘conflict-information&= #8217; under that parent; ‘conflict-information’ can include th= e following sub-parameters:

o   conflict-stat= us: three codes

=A7  1 | DOTS Serv= er has detected conflicting mitigation requests from different DOTS clients= .  This mitigation request is currently inactive until the conflicts are resolved. Another mitigation request is active.

=A7  2 | DOTS Serv= er has detected conflicting mitigation requests from different DOTS clients= .  This mitigation request is currently active.

=A7  3 | DOTS Serv= er has detected conflicting mitigation requests from different DOTS clients= .  All conflicting mitigation requests are inactive.=

o   conflict-scop= e: same structure as “scope”

Cheers,

Med

 

De : Konda, Tirumaleswar Reddy [mailto:TirumaleswarReddy_Konda@McAfee.com]
Envoy=E9 : jeudi 30 novembre 2017 10:41
=C0 : BOUCADAIR Mohamed IMT/OLN; Jon Shallow; dots@ietf.org
Objet : RE: [Dots] signal-channel: Conflict detection and notif= ication

 

The propo= sal works for me, is the plan to add 7, 8 and 9 status or add a new “= additional-status” parameter ?

&nbs= p;

-Tiru

&nbs= p;

From:<= /span> mohamed.boucadair@orange.co= m [mailto:mohamed.bouca= dair@orange.com]
Sent: Wednesday, November 29, 2017 12:02 PM
To: Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@McAfee.com>; Jon Shallow= <supjps-ietf@jpshallow.com= >; dots@ietf.org
Subject: RE: [Dots] signal-channel: Conflict detection and notificat= ion

 

Hi Tiru,

 

I agree with you that discarding all conflicti= ng requests may not be helpful in some cases. In the same way that someone = can argue that selecting only one request among conflicting ones may not be useful because the server picked the wrong one= .   

 

I do prefer to leave this to implementation/de= ployment as a policy to be supplied. That policy will instruct the dots ser= ver about the behavior to follow based one specific information that is available for a given deployment:  

=B7&n= bsp;      Pick one and deactivate all the others based on some criteria<= o:p>

=B7&n= bsp;      Activate all of them

=B7&n= bsp;      De-activate all of them

 

Cheers,

Med

 

De : Dots [mailto:dots-bounces@ietf.org] De la part de Konda, Tirumaleswar Reddy
Envoy=E9 : mercredi 29 novembre 2017 06:39
=C0 : BOUCADAIR Mohamed IMT/OLN; Jon Shallow; dots@ietf.org
Objet : Re: [Dots] signal-channel: Conflict detection and notif= ication

 

Hi Med,

&nbs= p;

In a depl= oyment scenario with a DDoS Detector (or a on premise DDoS mitigation syste= m) acting as DOTS clients and a web server with in-built DDoS detection cap= ability. The web server may not have as much visibility into the extent of the DDoS attack as the DDoS Detector= (or IDMS) and there will be conflicting mitigation requests from different= DOTS clients, discarding all the mitigation requests from different client= s will make the mechanism not useful.

&nbs= p;

-Tiru

&nbs= p;

From:<= /span> mohamed.boucadair@orange.co= m [mailto:mohamed.bouca= dair@orange.com]
Sent: Tuesday, November 28, 2017 8:55 PM
To: Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@McAfee.com>; Jon Shallow= <supjps-ietf@jpshallow.com= >; dots@ietf.org
Subject: RE: [Dots] signal-channel: Conflict detection and notificat= ion

 

Tiru,

 

Please see inline.

 

Cheers,

Med

 

De : Dots [mailto:dots-bounces@ietf.org] De la part de Konda, Tirumaleswar Reddy
Envoy=E9 : mardi 28 novembre 2017 16:02
=C0 : Jon Shallow; BOUCADAIR Mohamed IMT/OLN; dots@ietf.org
Objet : Re: [Dots] signal-channel: Conflict detection and notif= ication

 

Within a = administrative domain, there won’t be many different DOTS clients rai= sing conflicting mitigation requests for the same target, the conflict may = arise between a DDoS Detector (or a on premise DDoS mitigation system) acting as DOTS clients and a web server with in-bu= ilt DDoS detection capability. 

[Med] I don’t= think that we can speculate about the nature of the conflicts that may hap= pen. Misconfigured and corrupted software instances may happen.

&nbs= p;

Under wha= t conditions does the DOTS server return “DOTS Server has detected co= nflicting mitigation requests from different DOTS clients.  All confli= cting mitigation requests are inactive.” ?

[Med] A dots server= can be typically instructed by a policy to discard conflicting requests. T= he rationale is that the provider thinks that the clients are misconfigured and something is needed to be fixed before s= olicited the server. The signal-channel does not need to call for a favorit= e action when conflicts; that is implementation- and deployment-specific. &= nbsp;

&nbs= p;

-Tiru

&nbs= p;

From:<= /span> Jon Shallow [mailto:supjps-ietf@jpshallow.com]
Sent: Tuesday, November 28, 2017 7:45 PM
To: mohamed.boucadai= r@orange.com; Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@McAfee.com>; dots@ietf.org
Subject: RE: [Dots] signal-channel: Conflict detection and notificat= ion

 

Hi Med,=

&n= bsp;

In prin= cipal I accept the concept of your 7, 8 & 9 status which in effect are = part of the mitigation state as in a state diagram.  However, having i= ssued a “8” status, this then needs to transition to another state which reflects what is actually happening – e.g. &#= 8220;2”.

&n= bsp;

The act= ual state could immediately be sent following the reporting of “8R= 21; (if Observe active), else it would need to wait until the next status G= ET.  It is possible that the “8” message gets lost, so relying on receiving the “8” could be dangerous.=

&n= bsp;

With a = “9” response what then is the DOTS client allowed to do?

- A ret= ry of the original mitigation request is likely to fail again

- If al= l the DOTS clients back off, then there will be no mitigation

- Shoul= d there be a random back-off time before retrying?

&n= bsp;

What is= critical is that

      DOT= S servers in the same administrative domain attempting to honor<= /span>

      con= flicting requests may flap network route or DNS information,

      deg= rading the networks attempting to participate in attack

      res= ponse with the DOTS clients.

Should not b= e allowed to happen.

&n= bsp;

I also = do not want to lose sight of

The not= ification SHOULD indicate the nature and scope of the conflict,<= /span>

for exa= mple, the overlapping prefix range in a conflicting mitigation request.R= 21;

This po= tentially can be conveyed in the 4.09 message, or could be a new mitigation= status parameter such as "additional-info" with an appropriate t= ext value.  It could be that “status” stays with “1” through “6”, and (possibly optional) “ad= ditional-status” has

0 | Thi= s DOTS client mitigation request is being honoured

1 | DOTS Server has de= tected conflicting mitigation requests from different DOTS clients.  T= his mitigation request is currently inactive until the conflicts are resolv= ed. Another mitigation request is active.

2 | DOTS Server has de= tected conflicting mitigation requests from different DOTS clients.  T= his mitigation request is currently active.

3 | DOTS Server has de= tected conflicting mitigation requests from different DOTS clients.  A= ll conflicting mitigation requests are inactive.

And = 220;additional-info” reports on what the nature and scope of the conf= lict is.

&n= bsp;

Regards=

&n= bsp;

Jon

&n= bsp;

From: Dots [mailto: dots-bounces@ietf.org] On B= ehalf Of mohamed.boucadair@orang= e.com
Sent: 28 November 2017 13:29
To: Jon Shallow; 'Konda, Tirumaleswar Reddy'; dots@ietf.org
Subject: Re: [Dots] signal-channel: Conflict detection and notificat= ion

 

Hi Jon, all,

 

Thank you for sharing your thoughts on this.

 

I tend to allow for both 4.09 code and new sta= tus values in the spec.

 

I see that you proposed this new value:

=3D=3D

7 | DOTS Server has de= tected conflicting mitigation requests from different DOTS clients.  T= his mitigation request is currently inactive until the conflicts are resolv= ed. Another mitigation request is active.

=3D=3D

 

Please note that a server may be instructed to= adopt a more strict behavior by deactivating all conflicting requests. Fur= ther, all DOTS clients which issued conflicting requests should be notified, not only the one for which a request is de-ac= tivated. As such, I’m afraid we will need more values, e.g.,

 

=3D=3D

7 | DOTS Server has de= tected conflicting mitigation requests from different DOTS clients.  T= his mitigation request is currently inactive until the conflicts are resolv= ed. Another mitigation request is active.

8 | DOTS Server has de= tected conflicting mitigation requests from different DOTS clients.  T= his mitigation request is currently active.

9 | DOTS Server has de= tected conflicting mitigation requests from different DOTS clients.  A= ll conflicting mitigation requests are inactive.

=3D=3D

 

For example:

* If the server decides to activate only one r= equest, then 7 will be sent to all clients for which the request is de-acti= vated and 8 to the client for which the request is maintained active.

* If the server decides to deactivate all requ= ests, then 9 will be sent to all clients.  

 

Cheers,

Med

 

De : Jon Shallow [mailto:supjps-ietf@jpshallow.com]
Envoy=E9 : mardi 28 novembre 2017 13:31
=C0 : 'Konda, Tirumaleswar Reddy'; BOUCADAIR Mohamed IMT/OLN; dots@ietf.org
Objet : RE: [Dots] signal-channel: Conflict detection and notif= ication

 

Hi Tiru= ,

&n= bsp;

If Clie= nt-A has invoked a mitigation, then Client-B requests a conflicting mitigat= ion, if the DOTS server is only allowing the first mitigation request to be= the valid one, then the DOTS server could send back a 4.09 to Client-B.

&n= bsp;

However= , if the DOTS server is allowed to choose the best mitigation request, deci= des it is Client-B, there is no simple way of sending an unsolicited 4.09 t= o client-A.  Hence suggestion for an additional status message which can be sent to Client-A stating that Client-A has bee= n de-selected because of a mitigation request conflict.

&n= bsp;

It is a= lso possible that a mitigation state is status 1 (parameter value – T= able 2)) and needs to transition to another state – at which point th= e conflict is found - possibly by the DOTS mitigator - which then needs to be relayed back through the DOTS server.<= /span>

&n= bsp;

Regards=

&n= bsp;

Jon

&n= bsp;

From: Konda, Tirumaleswar Reddy [mailto: TirumaleswarReddy_Kon= da@mcafee.com]
Sent: 28 November 2017 11:42
To: Jon Shallow; moh= amed.boucadair@orange.com; dots@ietf.org
Subject: RE: [Dots] signal-channel: Conflict detection and notificat= ion

 

Hi Jon,

&nbs= p;

What is t= he problem if the DOTS server returns 4.09 (conflict) error response for th= e conflicting mitigation request from Client-A ?

The above= error code is already defined https://tools.ie= tf.org/html/rfc8132.

&nbs= p;

-Tiru

&nbs= p;

From:<= /span> Dots [mailto:dots-bounces@ietf.org] On Behalf Of Jon Shallow
Sent: Tuesday, November 28, 2017 4:50 PM
To: mohamed.boucadai= r@orange.com; dots@ietf.org
Subject: Re: [Dots] signal-channel: Conflict detection and notificat= ion

 

Hi Med,=

&n= bsp;

See inl= ine

&n= bsp;

Regards=

&n= bsp;

Jon

&n= bsp;

From: Dots [mailto: dots-bounces@ietf.org] On B= ehalf Of ietf-supjps= -mohamed.boucadair@orange.com
Sent: 24 November 2017 14:03
To: dots@ietf.org
Subject: [Dots] signal-channel: Conflict detection and notification<= o:p>

 

Hi all,

 

As discussed during the last IETF meeting, we are seeking = for feedback from the WG about how to address this requirement:<= /span>

 

=3D=3D=3D=3D=3D=3D=3D=3D=3D

   SIG-009  Conflic= t Detection and Notification: Multiple DOTS clients

      con= trolled by a single administrative entity may send conflicting

      mit= igation requests for pools of protected resources as a result

      of = misconfiguration, operator error, or compromised DOTS clients.

      DOT= S servers in the same administrative domain attempting to honor<= /span>

      con= flicting requests may flap network route or DNS information,

      deg= rading the networks attempting to participate in attack

      res= ponse with the DOTS clients.  DOTS servers in a single

      adm= inistrative domain SHALL detect such conflicting requests, and

      SHA= LL notify the DOTS clients in conflict.  The notification

      SHO= ULD indicate the nature and scope of the conflict, for example,<= /span>

      the= overlapping prefix range in a conflicting mitigation request.

=3D=3D=3D=3D=3D=3D=3D=3D

 

For example, would it be OK if we leave implementation-spe= cific the criteria upon which a dots server relies to consider two requests= from two clients as conflicting, but draft-ietf-dots-signal defines only the procedure to notify clients when a conflict is detected? =

Jon> I agree that h= ow this is done is implementation specific.  However there is a scenar= io where Client-A initiates a mitigation requests which is acted upon, Clie= nt-B does a conflicting mitigation request but the DOTS Server decides that Client-B is the “more” valid miti= gation request and effectively de-activates Client-A’s request. = Table 2: draft-ietf-dots-signal-channel-09 therefore needs an additional s= tatus parameter to indicate to client-A there is a conflict and hence Client-A is being stood down while another client is controlling= the mitigation.  A suggestion would be

 

7 | DOTS Server has de= tected conflicting mitigation requests from different DOTS clients.  T= his mitigation request is currently inactive until the conflicts are resolv= ed. Another mitigation request is active.

 

Jon> The DOTS clien= t can then elect to leave in the mitigation request (and even refresh the P= UT to refresh the timeout) or delete it.

Jon> I do not think= it appropriate that an error message be sent back (e.g. 4.xx) if the DOTS = server immediately decides there is a conflicting request and closes down t= he new PUT request unless we come up with a specific error code so the DOTS client can understand why the request is= getting errored.

 

 

Likewise, would it be OK if the document does not specify = which of the conflicting actions is to be discarded (old, new, all) by the = server, but draft-ietf-dots-signal defines how to inform clients about which action was enforced by the server?

 

Jon> Again, I think= that this would be implementation specific.  The suggested Table 2: e= ntry above would cover this as well.  The DOTS client just needs to kn= ow it has been de-selected / discarded – I don’t think the DOTS client needs to know how / why the DOTS server chose that p= articular DOTS client.

 

Cheers,

Med

--_000_DM5PR16MB1788984AF407D432B143CDCEEA380DM5PR16MB1788namp_-- From nobody Thu Nov 30 02:51:18 2017 Return-Path: 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 4A342129440 for ; Thu, 30 Nov 2017 02:51:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 5j8fepPZjBAi for ; Thu, 30 Nov 2017 02:51:11 -0800 (PST) Received: from mail.jpshallow.com (mail.jpshallow.com [217.40.240.153]) (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 7CA3E129431 for ; Thu, 30 Nov 2017 02:51:09 -0800 (PST) Received: from [127.0.0.1] (helo=N01332) by mail.jpshallow.com with smtps (TLSv1:ECDHE-RSA-AES256-SHA:256) (Exim 4.89) (envelope-from ) id 1eKMQt-0007ed-T5; Thu, 30 Nov 2017 10:51:08 +0000 From: "Jon Shallow" To: "'Konda, Tirumaleswar Reddy'" , , References: <787AE7BB302AE849A7480A190F8B93300A07F4E4@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <009b01d3683a$c6158f90$5240aeb0$@jpshallow.com> <00e201d36844$b1b39ec0$151adc40$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93300A0819DB@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <011301d36853$48efb680$dacf2380$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93300A081B18@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93300A08307A@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93300A084012@OPEXCLILMA3.corporate.adroot.infra.ftgroup> In-Reply-To: Date: Thu, 30 Nov 2017 10:51:08 -0000 Message-ID: <006901d369c9$20ad07f0$620717d0$@jpshallow.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_006A_01D369C9.20B1E9F0" X-Mailer: Microsoft Outlook 14.0 Content-Language: en-gb Thread-Index: AQI5QycoOO+6Sl3hDoQKXRH887G99QHmvtxLArQ3BpMBrkCf6AG8EcvIAftFitMBk8OATQDr9ZOXAY4zRQIBQLfdVgD+ExMRAi0RRmsCNnHIaqG7g8PQ Archived-At: Subject: Re: [Dots] signal-channel: Conflict detection and notification 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Nov 2017 10:51:16 -0000 This is a multipart message in MIME format. ------=_NextPart_000_006A_01D369C9.20B1E9F0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable This also looks good to me in principal. =20 I do not think we need the =93additional-status=94 layer =96 why not = just go straight to =93conflict-information=94? =20 I would like to see added =93conflict-reason=94 with some defined = conflict codes under =93conflict-information=94. =20 However, none of this status (including bytes-dropped etc.) is defined = in the yang module: ietf-dots-signal as ro entities. =20 Regards =20 Jon =20 From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of Konda, = Tirumaleswar Reddy Sent: 30 November 2017 10:42 To: mohamed.boucadair@orange.com; Jon Shallow; dots@ietf.org Subject: Re: [Dots] signal-channel: Conflict detection and notification =20 Looks good to me. =20 -Tiru =20 From: mohamed.boucadair@orange.com [mailto:mohamed.boucadair@orange.com] = Sent: Thursday, November 30, 2017 3:56 PM To: Konda, Tirumaleswar Reddy ; Jon Shallow ; dots@ietf.org Subject: RE: [Dots] signal-channel: Conflict detection and notification =20 Hi Tiru,=20 =20 With the =93additional-status=94 parameter, and given the current values = defined in Table 2, I don=92t see which status code to return when = =93additional-status=94 is set to =933 | DOTS Server has detected conflicting mitigation = requests from different DOTS clients. All conflicting mitigation requests are = inactive=94. I=92m afraid new status codes should be defined for this to work (e.g., = =93X: Attack mitigation is withdrawn=94, =93Y: Attack mitigation is = rejected=94).=20 =20 Note that in both approaches, we will need to supply additional = information to characterize the conflict (conflict-information). This information = should be returned to all clients. =20 So, what about considering this direction? - Update the status table with these NEW codes: o 7: Attack mitigation is withdrawn o 8: Attack mitigation is rejected - Allow for including =91additional-status=92. Define = =91conflict-information=92 under that parent; =91conflict-information=92 can include the following sub-parameters: o conflict-status: three codes=20 =A7 1 | DOTS Server has detected conflicting mitigation requests from different DOTS clients. This mitigation request is currently inactive = until the conflicts are resolved. Another mitigation request is active. =A7 2 | DOTS Server has detected conflicting mitigation requests from different DOTS clients. This mitigation request is currently active.=20 =A7 3 | DOTS Server has detected conflicting mitigation requests from different DOTS clients. All conflicting mitigation requests are = inactive. o conflict-scope: same structure as =93scope=94 Cheers, Med =20 De : Konda, Tirumaleswar Reddy = [mailto:TirumaleswarReddy_Konda@McAfee.com]=20 Envoy=E9 : jeudi 30 novembre 2017 10:41 =C0 : BOUCADAIR Mohamed IMT/OLN; Jon Shallow; dots@ietf.org Objet : RE: [Dots] signal-channel: Conflict detection and notification =20 The proposal works for me, is the plan to add 7, 8 and 9 status or add a = new =93additional-status=94 parameter ? =20 -Tiru =20 From: mohamed.boucadair@orange.com [mailto:mohamed.boucadair@orange.com] = Sent: Wednesday, November 29, 2017 12:02 PM To: Konda, Tirumaleswar Reddy ; Jon Shallow ; dots@ietf.org Subject: RE: [Dots] signal-channel: Conflict detection and notification =20 Hi Tiru,=20 =20 I agree with you that discarding all conflicting requests may not be = helpful in some cases. In the same way that someone can argue that selecting = only one request among conflicting ones may not be useful because the server picked the wrong one. =20 =20 I do prefer to leave this to implementation/deployment as a policy to be supplied. That policy will instruct the dots server about the behavior = to follow based one specific information that is available for a given deployment: =20 =B7 Pick one and deactivate all the others based on some criteria =B7 Activate all of them =B7 De-activate all of them=20 =20 Cheers, Med=20 =20 De : Dots [mailto:dots-bounces@ietf.org] De la part de Konda, = Tirumaleswar Reddy Envoy=E9 : mercredi 29 novembre 2017 06:39 =C0 : BOUCADAIR Mohamed IMT/OLN; Jon Shallow; dots@ietf.org Objet : Re: [Dots] signal-channel: Conflict detection and notification =20 Hi Med, =20 In a deployment scenario with a DDoS Detector (or a on premise DDoS mitigation system) acting as DOTS clients and a web server with in-built DDoS detection capability. The web server may not have as much = visibility into the extent of the DDoS attack as the DDoS Detector (or IDMS) and = there will be conflicting mitigation requests from different DOTS clients, discarding all the mitigation requests from different clients will make = the mechanism not useful. =20 -Tiru =20 From: mohamed.boucadair@orange.com [mailto:mohamed.boucadair@orange.com] = Sent: Tuesday, November 28, 2017 8:55 PM To: Konda, Tirumaleswar Reddy ; Jon Shallow ; dots@ietf.org Subject: RE: [Dots] signal-channel: Conflict detection and notification =20 Tiru,=20 =20 Please see inline.=20 =20 Cheers, Med =20 De : Dots [mailto:dots-bounces@ietf.org] De la part de Konda, = Tirumaleswar Reddy Envoy=E9 : mardi 28 novembre 2017 16:02 =C0 : Jon Shallow; BOUCADAIR Mohamed IMT/OLN; dots@ietf.org Objet : Re: [Dots] signal-channel: Conflict detection and notification =20 Within a administrative domain, there won=92t be many different DOTS = clients raising conflicting mitigation requests for the same target, the = conflict may arise between a DDoS Detector (or a on premise DDoS mitigation = system) acting as DOTS clients and a web server with in-built DDoS detection capability. =20 [Med] I don=92t think that we can speculate about the nature of the = conflicts that may happen. Misconfigured and corrupted software instances may = happen.=20 =20 Under what conditions does the DOTS server return =93DOTS Server has = detected conflicting mitigation requests from different DOTS clients. All conflicting mitigation requests are inactive.=94 ? [Med] A dots server can be typically instructed by a policy to discard conflicting requests. The rationale is that the provider thinks that the clients are misconfigured and something is needed to be fixed before solicited the server. The signal-channel does not need to call for a favorite action when conflicts; that is implementation- and deployment-specific. =20 =20 -Tiru =20 From: Jon Shallow [mailto:supjps-ietf@jpshallow.com]=20 Sent: Tuesday, November 28, 2017 7:45 PM To: mohamed.boucadair@orange.com; Konda, Tirumaleswar Reddy ; dots@ietf.org Subject: RE: [Dots] signal-channel: Conflict detection and notification =20 Hi Med, =20 In principal I accept the concept of your 7, 8 & 9 status which in = effect are part of the mitigation state as in a state diagram. However, having issued a =938=94 status, this then needs to transition to another state = which reflects what is actually happening =96 e.g. =932=94. =20 The actual state could immediately be sent following the reporting of = =938=94 (if Observe active), else it would need to wait until the next status = GET. It is possible that the =938=94 message gets lost, so relying on = receiving the =938=94 could be dangerous. =20 With a =939=94 response what then is the DOTS client allowed to do? - A retry of the original mitigation request is likely to fail again - If all the DOTS clients back off, then there will be no mitigation - Should there be a random back-off time before retrying? =20 What is critical is that=20 DOTS servers in the same administrative domain attempting to honor conflicting requests may flap network route or DNS information, degrading the networks attempting to participate in attack response with the DOTS clients. Should not be allowed to happen. =20 I also do not want to lose sight of=20 The notification SHOULD indicate the nature and scope of the conflict, for example, the overlapping prefix range in a conflicting mitigation request.=94 This potentially can be conveyed in the 4.09 message, or could be a new mitigation status parameter such as "additional-info" with an = appropriate text value. It could be that =93status=94 stays with =931=94 through = =936=94, and (possibly optional) =93additional-status=94 has=20 0 | This DOTS client mitigation request is being honoured 1 | DOTS Server has detected conflicting mitigation requests from = different DOTS clients. This mitigation request is currently inactive until the conflicts are resolved. Another mitigation request is active. 2 | DOTS Server has detected conflicting mitigation requests from = different DOTS clients. This mitigation request is currently active.=20 3 | DOTS Server has detected conflicting mitigation requests from = different DOTS clients. All conflicting mitigation requests are inactive. And =93additional-info=94 reports on what the nature and scope of the = conflict is. =20 Regards =20 Jon =20 From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of mohamed.boucadair@orange.com Sent: 28 November 2017 13:29 To: Jon Shallow; 'Konda, Tirumaleswar Reddy'; dots@ietf.org Subject: Re: [Dots] signal-channel: Conflict detection and notification =20 Hi Jon, all, =20 Thank you for sharing your thoughts on this. =20 I tend to allow for both 4.09 code and new status values in the spec.=20 =20 I see that you proposed this new value:=20 =3D=3D 7 | DOTS Server has detected conflicting mitigation requests from = different DOTS clients. This mitigation request is currently inactive until the conflicts are resolved. Another mitigation request is active. =3D=3D =20 Please note that a server may be instructed to adopt a more strict = behavior by deactivating all conflicting requests. Further, all DOTS clients = which issued conflicting requests should be notified, not only the one for = which a request is de-activated. As such, I=92m afraid we will need more values, = e.g., =20 =3D=3D 7 | DOTS Server has detected conflicting mitigation requests from = different DOTS clients. This mitigation request is currently inactive until the conflicts are resolved. Another mitigation request is active. 8 | DOTS Server has detected conflicting mitigation requests from = different DOTS clients. This mitigation request is currently active.=20 9 | DOTS Server has detected conflicting mitigation requests from = different DOTS clients. All conflicting mitigation requests are inactive. =3D=3D =20 For example: * If the server decides to activate only one request, then 7 will be = sent to all clients for which the request is de-activated and 8 to the client = for which the request is maintained active.=20 * If the server decides to deactivate all requests, then 9 will be sent = to all clients. =20 =20 Cheers, Med =20 De : Jon Shallow [mailto:supjps-ietf@jpshallow.com]=20 Envoy=E9 : mardi 28 novembre 2017 13:31 =C0 : 'Konda, Tirumaleswar Reddy'; BOUCADAIR Mohamed IMT/OLN; = dots@ietf.org Objet : RE: [Dots] signal-channel: Conflict detection and notification =20 Hi Tiru, =20 If Client-A has invoked a mitigation, then Client-B requests a = conflicting mitigation, if the DOTS server is only allowing the first mitigation = request to be the valid one, then the DOTS server could send back a 4.09 to Client-B. =20 However, if the DOTS server is allowed to choose the best mitigation request, decides it is Client-B, there is no simple way of sending an unsolicited 4.09 to client-A. Hence suggestion for an additional status message which can be sent to Client-A stating that Client-A has been de-selected because of a mitigation request conflict. =20 It is also possible that a mitigation state is status 1 (parameter value = =96 Table 2)) and needs to transition to another state =96 at which point = the conflict is found - possibly by the DOTS mitigator - which then needs to = be relayed back through the DOTS server. =20 Regards =20 Jon =20 From: Konda, Tirumaleswar Reddy [mailto: = TirumaleswarReddy_Konda@mcafee.com] Sent: 28 November 2017 11:42 To: Jon Shallow; mohamed.boucadair@orange.com; dots@ietf.org Subject: RE: [Dots] signal-channel: Conflict detection and notification =20 Hi Jon, =20 What is the problem if the DOTS server returns 4.09 (conflict) error response for the conflicting mitigation request from Client-A ? The above error code is already defined = https://tools.ietf.org/html/rfc8132.=20 =20 -Tiru =20 From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Jon Shallow Sent: Tuesday, November 28, 2017 4:50 PM To: mohamed.boucadair@orange.com; dots@ietf.org Subject: Re: [Dots] signal-channel: Conflict detection and notification =20 Hi Med, =20 See inline =20 Regards =20 Jon =20 From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of ietf-supjps-mohamed.boucadair@orange.com Sent: 24 November 2017 14:03 To: dots@ietf.org Subject: [Dots] signal-channel: Conflict detection and notification =20 Hi all,=20 =20 As discussed during the last IETF meeting, we are seeking for feedback = from the WG about how to address this requirement: =20 =3D=3D=3D=3D=3D=3D=3D=3D=3D SIG-009 Conflict Detection and Notification: Multiple DOTS clients controlled by a single administrative entity may send conflicting mitigation requests for pools of protected resources as a result of misconfiguration, operator error, or compromised DOTS clients. DOTS servers in the same administrative domain attempting to honor conflicting requests may flap network route or DNS information, degrading the networks attempting to participate in attack response with the DOTS clients. DOTS servers in a single administrative domain SHALL detect such conflicting requests, and SHALL notify the DOTS clients in conflict. The notification SHOULD indicate the nature and scope of the conflict, for example, the overlapping prefix range in a conflicting mitigation request. =3D=3D=3D=3D=3D=3D=3D=3D =20 For example, would it be OK if we leave implementation-specific the = criteria upon which a dots server relies to consider two requests from two = clients as conflicting, but draft-ietf-dots-signal defines only the procedure to = notify clients when a conflict is detected?=20 Jon> I agree that how this is done is implementation specific. However there is a scenario where Client-A initiates a mitigation requests which = is acted upon, Client-B does a conflicting mitigation request but the DOTS Server decides that Client-B is the =93more=94 valid mitigation request = and effectively de-activates Client-A=92s request. Table 2: draft-ietf-dots-signal-channel-09 therefore needs an additional status parameter to indicate to client-A there is a conflict and hence Client-A = is being stood down while another client is controlling the mitigation. A suggestion would be=20 =20 7 | DOTS Server has detected conflicting mitigation requests from = different DOTS clients. This mitigation request is currently inactive until the conflicts are resolved. Another mitigation request is active. =20 Jon> The DOTS client can then elect to leave in the mitigation request = (and even refresh the PUT to refresh the timeout) or delete it. Jon> I do not think it appropriate that an error message be sent back = (e.g. 4.xx) if the DOTS server immediately decides there is a conflicting = request and closes down the new PUT request unless we come up with a specific = error code so the DOTS client can understand why the request is getting = errored. =20 =20 Likewise, would it be OK if the document does not specify which of the conflicting actions is to be discarded (old, new, all) by the server, = but draft-ietf-dots-signal defines how to inform clients about which action = was enforced by the server?=20 =20 Jon> Again, I think that this would be implementation specific. The suggested Table 2: entry above would cover this as well. The DOTS = client just needs to know it has been de-selected / discarded =96 I don=92t = think the DOTS client needs to know how / why the DOTS server chose that = particular DOTS client. =20 Cheers, Med=20 ------=_NextPart_000_006A_01D369C9.20B1E9F0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

This also looks good to me in = principal.

 

I do not think we need = the “additional-status” layer – why not just go = straight to “conflict-information”?

 

I would like to see = added “conflict-reason” with some defined conflict codes = under “conflict-information”.

 

However, none of this = status (including bytes-dropped etc.) is defined in the yang module: = ietf-dots-signal as ro entities.

 

Regards

 

Jon

 

From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of = Konda, Tirumaleswar Reddy
Sent: 30 November 2017 = 10:42
To: mohamed.boucadair@orange.com; Jon Shallow; = dots@ietf.org
Subject: Re: [Dots] signal-channel: Conflict = detection and notification

 

Looks good to = me.

 

-Tiru

 

From: mohamed.boucadair@orange.com= [mailto:mohamed.boucadair@ora= nge.com]
Sent: Thursday, November 30, 2017 3:56 = PM
To: Konda, Tirumaleswar Reddy <TirumaleswarReddy_Kond= a@McAfee.com>; Jon Shallow <supjps-ietf@jpshallow.com&g= t;; dots@ietf.org
Subject: RE: = [Dots] signal-channel: Conflict detection and = notification

 

Hi Tiru,

 

With the “additional-status” parameter, = and given the current values defined in Table 2, I don’t see which = status code to return when “additional-status” is set to = “3 | DOTS Server has detected conflicting mitigation requests from = different DOTS clients.  All conflicting mitigation requests are = inactive”. I’m afraid new status codes should be defined for = this to work (e.g., “X: Attack mitigation is withdrawn”, = “Y: Attack mitigation is rejected”). =

 

Note that in both approaches, we will need to supply = additional information to characterize the conflict = (conflict-information). This information should be returned to all = clients.

 

So, what about considering this = direction?

-   Update = the status table with these NEW codes:

o   7: = Attack mitigation is withdrawn

o   8: = Attack mitigation is rejected

-   Allow = for including ‘additional-status’. Define = ‘conflict-information’ under that parent; = ‘conflict-information’ can include the following = sub-parameters:

o   conflict-status: three codes

=A7  1 | = DOTS Server has detected conflicting mitigation requests from different = DOTS clients.  This mitigation request is currently inactive until = the conflicts are resolved. Another mitigation request is = active.

=A7  2 | = DOTS Server has detected conflicting mitigation requests from different = DOTS clients.  This mitigation request is currently active. =

=A7  3 | = DOTS Server has detected conflicting mitigation requests from different = DOTS clients.  All conflicting mitigation requests are = inactive.

o   conflict-scope: same structure as = “scope”

Cheers,

Med

 

De : Konda, Tirumaleswar Reddy [mailto:TirumaleswarRed= dy_Konda@McAfee.com]
Envoy=E9 : jeudi 30 novembre = 2017 10:41
=C0 : BOUCADAIR Mohamed IMT/OLN; Jon = Shallow; dots@ietf.org
Objet : = RE: [Dots] signal-channel: Conflict detection and = notification

 

The proposal works for = me, is the plan to add 7, 8 and 9 status or add a new = “additional-status” parameter ?

 

-Tiru

 

From: mohamed.boucadair@orange.com= [mailto:mohamed.boucadair@ora= nge.com]
Sent: Wednesday, November 29, 2017 12:02 = PM
To: Konda, Tirumaleswar Reddy <TirumaleswarReddy_Kond= a@McAfee.com>; Jon Shallow <supjps-ietf@jpshallow.com&g= t;; dots@ietf.org
Subject: RE: = [Dots] signal-channel: Conflict detection and = notification

 

Hi Tiru,

 

I agree with you that discarding all conflicting = requests may not be helpful in some cases. In the same way that someone = can argue that selecting only one request among conflicting ones may not = be useful because the server picked the wrong one. =   

 

I do prefer to leave this to implementation/deployment = as a policy to be supplied. That policy will instruct the dots server = about the behavior to follow based one specific information that is = available for a given deployment:  

=B7       = Pick one and deactivate all the others based on some = criteria

=B7       = Activate all of them

=B7       = De-activate all of them

 

Cheers,

Med =

 

De : Dots [mailto:dots-bounces@ietf.org] = De la part de Konda, Tirumaleswar Reddy
Envoy=E9 : = mercredi 29 novembre 2017 06:39
=C0 : BOUCADAIR Mohamed = IMT/OLN; Jon Shallow; dots@ietf.org
Objet : = Re: [Dots] signal-channel: Conflict detection and = notification

 

Hi = Med,

 

In a deployment scenario with a = DDoS Detector (or a on premise DDoS mitigation system) acting as DOTS = clients and a web server with in-built DDoS detection capability. The = web server may not have as much visibility into the extent of the DDoS = attack as the DDoS Detector (or IDMS) and there will be conflicting = mitigation requests from different DOTS clients, discarding all the = mitigation requests from different clients will make the mechanism not = useful.

 

-Tiru

 

From: mohamed.boucadair@orange.com= [mailto:mohamed.boucadair@ora= nge.com]
Sent: Tuesday, November 28, 2017 8:55 = PM
To: Konda, Tirumaleswar Reddy <TirumaleswarReddy_Kond= a@McAfee.com>; Jon Shallow <supjps-ietf@jpshallow.com&g= t;; dots@ietf.org
Subject: RE: = [Dots] signal-channel: Conflict detection and = notification

 

Tiru,

 

Please see inline.

 

Cheers,

Med

 

De : Dots [mailto:dots-bounces@ietf.org] = De la part de Konda, Tirumaleswar Reddy
Envoy=E9 : = mardi 28 novembre 2017 16:02
=C0 : Jon Shallow; BOUCADAIR = Mohamed IMT/OLN; dots@ietf.org
Objet : = Re: [Dots] signal-channel: Conflict detection and = notification

 

Within a = administrative domain, there won’t be many different DOTS clients = raising conflicting mitigation requests for the same target, the = conflict may arise between a DDoS Detector (or a on premise DDoS = mitigation system) acting as DOTS clients and a web server with in-built = DDoS detection capability. 

[Med] I don’t think = that we can speculate about the nature of the conflicts that may happen. = Misconfigured and corrupted software instances may happen. =

 

Under what conditions does the DOTS = server return “DOTS Server has detected conflicting mitigation = requests from different DOTS clients.  All conflicting mitigation = requests are inactive.” ?

[Med] A dots server can be = typically instructed by a policy to discard conflicting requests. The = rationale is that the provider thinks that the clients are misconfigured = and something is needed to be fixed before solicited the server. The = signal-channel does not need to call for a favorite action when = conflicts; that is implementation- and deployment-specific. =  

 

-Tiru

 

From: Jon Shallow [mailto:supjps-ietf@jpshallow.co= m]
Sent: Tuesday, November 28, 2017 7:45 PM
To: = mohamed.boucadair@orange.com= ; Konda, Tirumaleswar Reddy <TirumaleswarReddy_Kond= a@McAfee.com>; dots@ietf.org
Subject: RE: = [Dots] signal-channel: Conflict detection and = notification

 

Hi Med,

 

In principal I accept = the concept of your 7, 8 & 9 status which in effect are part of the = mitigation state as in a state diagram.  However, having issued a = “8” status, this then needs to transition to another state = which reflects what is actually happening – e.g. = “2”.

 

The actual state could = immediately be sent following the reporting of “8” (if = Observe active), else it would need to wait until the next status = GET.  It is possible that the “8” message gets lost, so = relying on receiving the “8” could be = dangerous.

 

With a “9” = response what then is the DOTS client allowed to = do?

- A retry of the original mitigation request is = likely to fail again

- If all the DOTS clients back off, then there = will be no mitigation

- Should there be a random back-off time before = retrying?

 

What is critical is that =

      DOTS = servers in the same administrative domain attempting to = honor

      conflicting = requests may flap network route or DNS = information,

      degrading = the networks attempting to participate in attack

      response = with the DOTS clients.

Should not be allowed to = happen.

 

I also do not want to = lose sight of

The notification SHOULD indicate the = nature and scope of the conflict,

for example, the overlapping prefix range = in a conflicting mitigation request.”

This potentially can be = conveyed in the 4.09 message, or could be a new mitigation status = parameter such as "additional-info" with an appropriate text = value.  It could be that “status” stays with = “1” through “6”, and (possibly optional) = “additional-status” has

0 | This DOTS client = mitigation request is being honoured

1 | DOTS = Server has detected conflicting mitigation requests from different DOTS = clients.  This mitigation request is currently inactive until the = conflicts are resolved. Another mitigation request is = active.

2 | DOTS Server has detected conflicting = mitigation requests from different DOTS clients.  This mitigation = request is currently active.

3 | DOTS = Server has detected conflicting mitigation requests from different DOTS = clients.  All conflicting mitigation requests are = inactive.

And “additional-info” reports on = what the nature and scope of the conflict is.

 

Regards

 

Jon

 

From: Dots [mailto: dots-bounces@ietf.org] On = Behalf Of mohamed.boucadair@orange.com=
Sent: 28 November 2017 13:29
To: Jon Shallow; = 'Konda, Tirumaleswar Reddy'; dots@ietf.org
Subject: Re: = [Dots] signal-channel: Conflict detection and = notification

 

Hi Jon, all,

 

Thank you for sharing your thoughts on = this.

 

I tend to allow for both 4.09 code and new status = values in the spec.

 

I see that you proposed this new value: =

=3D=3D

7 | DOTS Server has detected = conflicting mitigation requests from different DOTS clients.  This = mitigation request is currently inactive until the conflicts are = resolved. Another mitigation request is active.

=3D=3D

 

Please note that a server may be instructed to adopt a = more strict behavior by deactivating all conflicting requests. Further, = all DOTS clients which issued conflicting requests should be notified, = not only the one for which a request is de-activated. As such, I’m = afraid we will need more values, e.g.,

 

=3D=3D

7 | DOTS Server has detected = conflicting mitigation requests from different DOTS clients.  This = mitigation request is currently inactive until the conflicts are = resolved. Another mitigation request is active.

8 | DOTS = Server has detected conflicting mitigation requests from different DOTS = clients.  This mitigation request is currently active. =

9 | DOTS Server has detected conflicting = mitigation requests from different DOTS clients.  All conflicting = mitigation requests are inactive.

=3D=3D

 

For example:

* If = the server decides to activate only one request, then 7 will be sent to = all clients for which the request is de-activated and 8 to the client = for which the request is maintained active.

* If = the server decides to deactivate all requests, then 9 will be sent to = all clients.  

 

Cheers,

Med

 

De : Jon Shallow [mailto:supjps-ietf@jpshallow.co= m]
Envoy=E9 : mardi 28 novembre 2017 = 13:31
=C0 : 'Konda, Tirumaleswar Reddy'; BOUCADAIR Mohamed IMT/OLN; dots@ietf.org
Objet : = RE: [Dots] signal-channel: Conflict detection and = notification

 

Hi Tiru,

 

If Client-A has invoked = a mitigation, then Client-B requests a conflicting mitigation, if the = DOTS server is only allowing the first mitigation request to be the = valid one, then the DOTS server could send back a 4.09 to = Client-B.

 

However, if the DOTS = server is allowed to choose the best mitigation request, decides it is = Client-B, there is no simple way of sending an unsolicited 4.09 to = client-A.  Hence suggestion for an additional status message which = can be sent to Client-A stating that Client-A has been de-selected = because of a mitigation request conflict.

 

It is also possible that = a mitigation state is status 1 (parameter value – Table 2)) and = needs to transition to another state – at which point the conflict = is found - possibly by the DOTS mitigator - which then needs to be = relayed back through the DOTS server.

 

Regards

 

Jon

 

From: Konda, Tirumaleswar Reddy [mailto: TirumaleswarReddy_Kond= a@mcafee.com]
Sent: 28 November 2017 11:42
To: = Jon Shallow; mohamed.boucadair@orange.com= ; dots@ietf.org
Subject: RE: = [Dots] signal-channel: Conflict detection and = notification

 

Hi = Jon,

 

What is the problem if the DOTS = server returns 4.09 (conflict) error response for the conflicting = mitigation request from Client-A ?

The above error code is already = defined https://tools.ietf.org/html/rfc8132<= /span>. =

 

-Tiru

 

From: Dots [mailto:dots-bounces@ietf.org] = On Behalf Of Jon Shallow
Sent: Tuesday, November 28, = 2017 4:50 PM
To: mohamed.boucadair@orange.com= ; dots@ietf.org
Subject: Re: = [Dots] signal-channel: Conflict detection and = notification

 

Hi Med,

 

See = inline

 

Regards

 

Jon

 

From: Dots [mailto: dots-bounces@ietf.org] On = Behalf Of ietf-supjps-moha= med.boucadair@orange.com
Sent: 24 November 2017 = 14:03
To: dots@ietf.org
Subject: = [Dots] signal-channel: Conflict detection and = notification

 

Hi = all,

 

As = discussed during the last IETF meeting, we are seeking for feedback from = the WG about how to address this requirement:

 

=3D=3D=3D=3D=3D=3D=3D=3D=3D

   SIG-009  Conflict = Detection and Notification: Multiple DOTS = clients

      controlled = by a single administrative entity may send = conflicting

      mitigation = requests for pools of protected resources as a = result

      of = misconfiguration, operator error, or compromised DOTS = clients.

      DOTS = servers in the same administrative domain attempting to = honor

      conflicting = requests may flap network route or DNS = information,

      degrading = the networks attempting to participate in attack

      response = with the DOTS clients.  DOTS servers in a = single

      = administrative domain SHALL detect such conflicting requests, = and

      SHALL = notify the DOTS clients in conflict.  The = notification

      SHOULD = indicate the nature and scope of the conflict, for = example,

      the = overlapping prefix range in a conflicting mitigation = request.

=3D=3D=3D=3D=3D=3D=3D=3D

 

For = example, would it be OK if we leave implementation-specific the criteria = upon which a dots server relies to consider two requests from two = clients as conflicting, but draft-ietf-dots-signal defines only the = procedure to notify clients when a conflict is detected? =

Jon> I agree that how this is done is = implementation specific.  However there is a scenario where = Client-A initiates a mitigation requests which is acted upon, Client-B = does a conflicting mitigation request but the DOTS Server decides that = Client-B is the “more” valid mitigation request and = effectively de-activates Client-A’s request.  Table 2: = draft-ietf-dots-signal-channel-09 therefore needs an additional status = parameter to indicate to client-A there is a conflict and hence Client-A = is being stood down while another client is controlling the = mitigation.  A suggestion would be

 

7 | DOTS = Server has detected conflicting mitigation requests from different DOTS = clients.  This mitigation request is currently inactive until the = conflicts are resolved. Another mitigation request is = active.

 

Jon> The = DOTS client can then elect to leave in the mitigation request (and even = refresh the PUT to refresh the timeout) or delete = it.

Jon> I do not think it appropriate that an = error message be sent back (e.g. 4.xx) if the DOTS server immediately = decides there is a conflicting request and closes down the new PUT = request unless we come up with a specific error code so the DOTS client = can understand why the request is getting = errored.

 

 

Likewise, would it be OK if the document does not specify which of = the conflicting actions is to be discarded (old, new, all) by the = server, but draft-ietf-dots-signal defines how to inform clients about = which action was enforced by the server?

 

Jon> = Again, I think that this would be implementation specific.  The = suggested Table 2: entry above would cover this as well.  The DOTS = client just needs to know it has been de-selected / discarded – I = don’t think the DOTS client needs to know how / why the DOTS = server chose that particular DOTS client.

 

Cheers,

Med =

------=_NextPart_000_006A_01D369C9.20B1E9F0-- From nobody Thu Nov 30 02:54:21 2017 Return-Path: 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 2A9CF12943A for ; Thu, 30 Nov 2017 02:54:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.617 X-Spam-Level: X-Spam-Status: No, score=-2.617 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 twhrnNtJFDTl for ; Thu, 30 Nov 2017 02:54:16 -0800 (PST) Received: from orange.com (mta134.mail.business.static.orange.com [80.12.70.34]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8CF0F129435 for ; Thu, 30 Nov 2017 02:54:15 -0800 (PST) Received: from opfednr00.francetelecom.fr (unknown [xx.xx.xx.64]) by opfednr23.francetelecom.fr (ESMTP service) with ESMTP id 1C821C0DDA; Thu, 30 Nov 2017 11:54:14 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.61]) by opfednr00.francetelecom.fr (ESMTP service) with ESMTP id DE01C1A00FF; Thu, 30 Nov 2017 11:54:13 +0100 (CET) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM7E.corporate.adroot.infra.ftgroup ([fe80::b91c:ea2c:ac8a:7462%19]) with mapi id 14.03.0361.001; Thu, 30 Nov 2017 11:54:13 +0100 From: To: Jon Shallow , "'Konda, Tirumaleswar Reddy'" , "dots@ietf.org" Thread-Topic: [Dots] signal-channel: Conflict detection and notification Thread-Index: AdNlLOxuTejE5Yr+TiWtd6n7pT4m0QHmvtxLArQ3BpMBrkCf6AG8EcvIAftFitMBk8OATQDr9ZOXAY4zRQIBQLfdVgD+ExMRAi0RRmsCNnHIaqG7g8PQolfRh7A= Date: Thu, 30 Nov 2017 10:54:13 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93300A084068@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <787AE7BB302AE849A7480A190F8B93300A07F4E4@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <009b01d3683a$c6158f90$5240aeb0$@jpshallow.com> <00e201d36844$b1b39ec0$151adc40$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93300A0819DB@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <011301d36853$48efb680$dacf2380$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93300A081B18@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93300A08307A@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93300A084012@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <006901d369c9$20ad07f0$620717d0$@jpshallow.com> In-Reply-To: <006901d369c9$20ad07f0$620717d0$@jpshallow.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.4] Content-Type: multipart/alternative; boundary="_000_787AE7BB302AE849A7480A190F8B93300A084068OPEXCLILMA3corp_" MIME-Version: 1.0 Archived-At: Subject: Re: [Dots] signal-channel: Conflict detection and notification 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Nov 2017 10:54:20 -0000 --_000_787AE7BB302AE849A7480A190F8B93300A084068OPEXCLILMA3corp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re-, Please see inline. Cheers, Med De : Jon Shallow [mailto:supjps-ietf@jpshallow.com] Envoy=E9 : jeudi 30 novembre 2017 11:51 =C0 : 'Konda, Tirumaleswar Reddy'; BOUCADAIR Mohamed IMT/OLN; dots@ietf.org Objet : RE: [Dots] signal-channel: Conflict detection and notification This also looks good to me in principal. I do not think we need the "additional-status" layer - why not just go stra= ight to "conflict-information"? [Med] This is to leave it extensible if we need in the future to supply mor= e information for other purposes than conflicts. Does it make sense? I would like to see added "conflict-reason" with some defined conflict code= s under "conflict-information". However, none of this status (including bytes-dropped etc.) is defined in t= he yang module: ietf-dots-signal as ro entities. Regards Jon From: Dots [mailto: dots-bounces@ietf.org] On= Behalf Of Konda, Tirumaleswar Reddy Sent: 30 November 2017 10:42 To: mohamed.boucadair@orange.com; Jon = Shallow; dots@ietf.org Subject: Re: [Dots] signal-channel: Conflict detection and notification Looks good to me. -Tiru From: mohamed.boucadair@orange.com [ma= ilto:mohamed.boucadair@orange.com] Sent: Thursday, November 30, 2017 3:56 PM To: Konda, Tirumaleswar Reddy >; Jon Shallow >; dots@ietf.org Subject: RE: [Dots] signal-channel: Conflict detection and notification Hi Tiru, With the "additional-status" parameter, and given the current values define= d in Table 2, I don't see which status code to return when "additional-stat= us" is set to "3 | DOTS Server has detected conflicting mitigation requests= from different DOTS clients. All conflicting mitigation requests are inac= tive". I'm afraid new status codes should be defined for this to work (e.g.= , "X: Attack mitigation is withdrawn", "Y: Attack mitigation is rejected"). Note that in both approaches, we will need to supply additional information= to characterize the conflict (conflict-information). This information shou= ld be returned to all clients. So, what about considering this direction? - Update the status table with these NEW codes: o 7: Attack mitigation is withdrawn o 8: Attack mitigation is rejected - Allow for including 'additional-status'. Define 'conflict-information' = under that parent; 'conflict-information' can include the following sub-par= ameters: o conflict-status: three codes * 1 | DOTS Server has detected conflicting mitigation requests from differ= ent DOTS clients. This mitigation request is currently inactive until the = conflicts are resolved. Another mitigation request is active. * 2 | DOTS Server has detected conflicting mitigation requests from differ= ent DOTS clients. This mitigation request is currently active. * 3 | DOTS Server has detected conflicting mitigation requests from differ= ent DOTS clients. All conflicting mitigation requests are inactive. o conflict-scope: same structure as "scope" Cheers, Med De : Konda, Tirumaleswar Reddy [mailto:TirumaleswarReddy_Konda@McAfee.com] Envoy=E9 : jeudi 30 novembre 2017 10:41 =C0 : BOUCADAIR Mohamed IMT/OLN; Jon Shallow; dots@ietf.org Objet : RE: [Dots] signal-channel: Conflict detection and notification The proposal works for me, is the plan to add 7, 8 and 9 status or add a ne= w "additional-status" parameter ? -Tiru From: mohamed.boucadair@orange.com [ma= ilto:mohamed.boucadair@orange.com] Sent: Wednesday, November 29, 2017 12:02 PM To: Konda, Tirumaleswar Reddy >; Jon Shallow >; dots@ietf.org Subject: RE: [Dots] signal-channel: Conflict detection and notification Hi Tiru, I agree with you that discarding all conflicting requests may not be helpfu= l in some cases. In the same way that someone can argue that selecting only= one request among conflicting ones may not be useful because the server pi= cked the wrong one. I do prefer to leave this to implementation/deployment as a policy to be su= pplied. That policy will instruct the dots server about the behavior to fol= low based one specific information that is available for a given deployment= : * Pick one and deactivate all the others based on some criteria * Activate all of them * De-activate all of them Cheers, Med De : Dots [mailto:dots-bounces@ietf.org] De la part de Konda, Tirumaleswar = Reddy Envoy=E9 : mercredi 29 novembre 2017 06:39 =C0 : BOUCADAIR Mohamed IMT/OLN; Jon Shallow; dots@ietf.org Objet : Re: [Dots] signal-channel: Conflict detection and notification Hi Med, In a deployment scenario with a DDoS Detector (or a on premise DDoS mitigat= ion system) acting as DOTS clients and a web server with in-built DDoS dete= ction capability. The web server may not have as much visibility into the e= xtent of the DDoS attack as the DDoS Detector (or IDMS) and there will be c= onflicting mitigation requests from different DOTS clients, discarding all = the mitigation requests from different clients will make the mechanism not = useful. -Tiru From: mohamed.boucadair@orange.com [ma= ilto:mohamed.boucadair@orange.com] Sent: Tuesday, November 28, 2017 8:55 PM To: Konda, Tirumaleswar Reddy >; Jon Shallow >; dots@ietf.org Subject: RE: [Dots] signal-channel: Conflict detection and notification Tiru, Please see inline. Cheers, Med De : Dots [mailto:dots-bounces@ietf.org] De la part de Konda, Tirumaleswar = Reddy Envoy=E9 : mardi 28 novembre 2017 16:02 =C0 : Jon Shallow; BOUCADAIR Mohamed IMT/OLN; dots@ietf.org Objet : Re: [Dots] signal-channel: Conflict detection and notification Within a administrative domain, there won't be many different DOTS clients = raising conflicting mitigation requests for the same target, the conflict m= ay arise between a DDoS Detector (or a on premise DDoS mitigation system) a= cting as DOTS clients and a web server with in-built DDoS detection capabil= ity. [Med] I don't think that we can speculate about the nature of the conflicts= that may happen. Misconfigured and corrupted software instances may happen= . Under what conditions does the DOTS server return "DOTS Server has detected= conflicting mitigation requests from different DOTS clients. All conflict= ing mitigation requests are inactive." ? [Med] A dots server can be typically instructed by a policy to discard conf= licting requests. The rationale is that the provider thinks that the client= s are misconfigured and something is needed to be fixed before solicited th= e server. The signal-channel does not need to call for a favorite action wh= en conflicts; that is implementation- and deployment-specific. -Tiru From: Jon Shallow [mailto:supjps-ietf@jpshallow.com] Sent: Tuesday, November 28, 2017 7:45 PM To: mohamed.boucadair@orange.com; Kond= a, Tirumaleswar Reddy >; dots@ietf.org Subject: RE: [Dots] signal-channel: Conflict detection and notification Hi Med, In principal I accept the concept of your 7, 8 & 9 status which in effect a= re part of the mitigation state as in a state diagram. However, having iss= ued a "8" status, this then needs to transition to another state which refl= ects what is actually happening - e.g. "2". The actual state could immediately be sent following the reporting of "8" (= if Observe active), else it would need to wait until the next status GET. = It is possible that the "8" message gets lost, so relying on receiving the = "8" could be dangerous. With a "9" response what then is the DOTS client allowed to do? - A retry of the original mitigation request is likely to fail again - If all the DOTS clients back off, then there will be no mitigation - Should there be a random back-off time before retrying? What is critical is that DOTS servers in the same administrative domain attempting to honor conflicting requests may flap network route or DNS information, degrading the networks attempting to participate in attack response with the DOTS clients. Should not be allowed to happen. I also do not want to lose sight of The notification SHOULD indicate the nature and scope of the conflict, for example, the overlapping prefix range in a conflicting mitigation reque= st." This potentially can be conveyed in the 4.09 message, or could be a new mit= igation status parameter such as "additional-info" with an appropriate text= value. It could be that "status" stays with "1" through "6", and (possibl= y optional) "additional-status" has 0 | This DOTS client mitigation request is being honoured 1 | DOTS Server has detected conflicting mitigation requests from different= DOTS clients. This mitigation request is currently inactive until the con= flicts are resolved. Another mitigation request is active. 2 | DOTS Server has detected conflicting mitigation requests from different= DOTS clients. This mitigation request is currently active. 3 | DOTS Server has detected conflicting mitigation requests from different= DOTS clients. All conflicting mitigation requests are inactive. And "additional-info" reports on what the nature and scope of the conflict = is. Regards Jon From: Dots [mailto: dots-bounces@ietf.org] On= Behalf Of mohamed.boucadair@orange.com Sent: 28 November 2017 13:29 To: Jon Shallow; 'Konda, Tirumaleswar Reddy'; dots@ietf.org Subject: Re: [Dots] signal-channel: Conflict detection and notification Hi Jon, all, Thank you for sharing your thoughts on this. I tend to allow for both 4.09 code and new status values in the spec. I see that you proposed this new value: =3D=3D 7 | DOTS Server has detected conflicting mitigation requests from different= DOTS clients. This mitigation request is currently inactive until the con= flicts are resolved. Another mitigation request is active. =3D=3D Please note that a server may be instructed to adopt a more strict behavior= by deactivating all conflicting requests. Further, all DOTS clients which = issued conflicting requests should be notified, not only the one for which = a request is de-activated. As such, I'm afraid we will need more values, e.= g., =3D=3D 7 | DOTS Server has detected conflicting mitigation requests from different= DOTS clients. This mitigation request is currently inactive until the con= flicts are resolved. Another mitigation request is active. 8 | DOTS Server has detected conflicting mitigation requests from different= DOTS clients. This mitigation request is currently active. 9 | DOTS Server has detected conflicting mitigation requests from different= DOTS clients. All conflicting mitigation requests are inactive. =3D=3D For example: * If the server decides to activate only one request, then 7 will be sent t= o all clients for which the request is de-activated and 8 to the client for= which the request is maintained active. * If the server decides to deactivate all requests, then 9 will be sent to = all clients. Cheers, Med De : Jon Shallow [mailto:supjps-ietf@jpshallow.com] Envoy=E9 : mardi 28 novembre 2017 13:31 =C0 : 'Konda, Tirumaleswar Reddy'; BOUCADAIR Mohamed IMT/OLN; dots@ietf.org= Objet : RE: [Dots] signal-channel: Conflict detection and notification Hi Tiru, If Client-A has invoked a mitigation, then Client-B requests a conflicting = mitigation, if the DOTS server is only allowing the first mitigation reques= t to be the valid one, then the DOTS server could send back a 4.09 to Clien= t-B. However, if the DOTS server is allowed to choose the best mitigation reques= t, decides it is Client-B, there is no simple way of sending an unsolicited= 4.09 to client-A. Hence suggestion for an additional status message which= can be sent to Client-A stating that Client-A has been de-selected because= of a mitigation request conflict. It is also possible that a mitigation state is status 1 (parameter value - = Table 2)) and needs to transition to another state - at which point the con= flict is found - possibly by the DOTS mitigator - which then needs to be re= layed back through the DOTS server. Regards Jon From: Konda, Tirumaleswar Reddy [mailto: TirumaleswarReddy_Konda@mcafee.com= ] Sent: 28 November 2017 11:42 To: Jon Shallow; mohamed.boucadair@orange.com; dots@ietf.org Subject: RE: [Dots] signal-channel: Conflict detection and notification Hi Jon, What is the problem if the DOTS server returns 4.09 (conflict) error respon= se for the conflicting mitigation request from Client-A ? The above error code is already defined https://tools.ietf.org/html/rfc8132= . -Tiru From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Jon Shallow Sent: Tuesday, November 28, 2017 4:50 PM To: mohamed.boucadair@orange.com; dots= @ietf.org Subject: Re: [Dots] signal-channel: Conflict detection and notification Hi Med, See inline Regards Jon From: Dots [mailto: dots-bounces@ietf.org] On= Behalf Of ietf-supjps-mohamed.boucadair@orange.com Sent: 24 November 2017 14:03 To: dots@ietf.org Subject: [Dots] signal-channel: Conflict detection and notification Hi all, As discussed during the last IETF meeting, we are seeking for feedback from= the WG about how to address this requirement: =3D=3D=3D=3D=3D=3D=3D=3D=3D SIG-009 Conflict Detection and Notification: Multiple DOTS clients controlled by a single administrative entity may send conflicting mitigation requests for pools of protected resources as a result of misconfiguration, operator error, or compromised DOTS clients. DOTS servers in the same administrative domain attempting to honor conflicting requests may flap network route or DNS information, degrading the networks attempting to participate in attack response with the DOTS clients. DOTS servers in a single administrative domain SHALL detect such conflicting requests, and SHALL notify the DOTS clients in conflict. The notification SHOULD indicate the nature and scope of the conflict, for example, the overlapping prefix range in a conflicting mitigation request. =3D=3D=3D=3D=3D=3D=3D=3D For example, would it be OK if we leave implementation-specific the criteri= a upon which a dots server relies to consider two requests from two clients= as conflicting, but draft-ietf-dots-signal defines only the procedure to n= otify clients when a conflict is detected? Jon> I agree that how this is done is implementation specific. However the= re is a scenario where Client-A initiates a mitigation requests which is ac= ted upon, Client-B does a conflicting mitigation request but the DOTS Serve= r decides that Client-B is the "more" valid mitigation request and effectiv= ely de-activates Client-A's request. Table 2: draft-ietf-dots-signal-chann= el-09 therefore needs an additional status parameter to indicate to client-= A there is a conflict and hence Client-A is being stood down while another = client is controlling the mitigation. A suggestion would be 7 | DOTS Server has detected conflicting mitigation requests from different= DOTS clients. This mitigation request is currently inactive until the con= flicts are resolved. Another mitigation request is active. Jon> The DOTS client can then elect to leave in the mitigation request (and= even refresh the PUT to refresh the timeout) or delete it. Jon> I do not think it appropriate that an error message be sent back (e.g.= 4.xx) if the DOTS server immediately decides there is a conflicting reques= t and closes down the new PUT request unless we come up with a specific err= or code so the DOTS client can understand why the request is getting errore= d. Likewise, would it be OK if the document does not specify which of the conf= licting actions is to be discarded (old, new, all) by the server, but draft= -ietf-dots-signal defines how to inform clients about which action was enfo= rced by the server? Jon> Again, I think that this would be implementation specific. The sugges= ted Table 2: entry above would cover this as well. The DOTS client just ne= eds to know it has been de-selected / discarded - I don't think the DOTS cl= ient needs to know how / why the DOTS server chose that particular DOTS cli= ent. Cheers, Med --_000_787AE7BB302AE849A7480A190F8B93300A084068OPEXCLILMA3corp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Re-,

 

Please see inline.

 

Cheers,

Med

 

De : Jon Shallow [mailto:supjps-ietf= @jpshallow.com]
Envoy=E9 : jeudi 30 novembre 2017 11:51
=C0 : 'Konda, Tirumaleswar Reddy'; BOUCADAIR Mohamed IMT/OLN; d= ots@ietf.org
Objet : RE: [Dots] signal-channel: Conflict detection and notif= ication

 

This al= so looks good to me in principal.

&n= bsp;

I do no= t think we need the “additional-status” layer – why not j= ust go straight to “conflict-information”?

[Med] This is to leave it exten= sible if we need in the future to supply more information for other purpose= s than conflicts. Does it make sense?

&n= bsp;

I would= like to see added “conflict-reason” with some defined conflict= codes under “conflict-information”.

&n= bsp;

However= , none of this status (including bytes-dropped etc.) is defined in the yang= module: ietf-dots-signal as ro entities.

&n= bsp;

Regards=

&n= bsp;

Jon

&n= bsp;

From:= Dots [mailto: dots-bounces@ietf.org] On B= ehalf Of Konda, Tirumaleswar Reddy
Sent: 30 November 2017 10:42
To: mohamed.boucadai= r@orange.com; Jon Shallow; dots@ietf.org
Subject: Re: [Dots] signal-channel: Conflict detection and notificat= ion

 

Looks good to me.

 

-Tiru

 

From: mohamed.boucadair@orange.co= m [mailto:mohamed.bouca= dair@orange.com]
Sent: Thursday, November 30, 2017 3:56 PM
To: Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@McAfee.com>; Jon Shallow= <supjps-ietf@jpshallow.com= >; dots@ietf.org
Subject: RE: [Dots] signal-channel: Conflict detection and notificat= ion

 

Hi Tiru,

 

With the “additional-stat= us” parameter, and given the current values defined in Table 2, I don= ’t see which status code to return when “additional-status̶= 1; is set to “3 | DOTS Server has detected conflicting mitigation reque= sts from different DOTS clients.  All conflicting mitigation requests = are inactive”. I’m afraid new status codes should be defined fo= r this to work (e.g., “X: Attack mitigation is withdrawn”, “Y: Attack mitigation is rejected”).

 

Note that in both approaches, w= e will need to supply additional information to characterize the conflict (= conflict-information). This information should be returned to all clients.

 

So, what about considering this= direction?

-   Update the status table with these NEW codes:

o=    7: Attack mitigation is withdrawn

o=    8: Attack mitigation is rejected

-   Allow for including ‘additional-status= 217;. Define ‘conflict-information’ under that parent; ‘c= onflict-information’ can include the following sub-parameters:

o=    conflict-status: three codes

=A7  1 | DOTS Server has detected conflicting mitiga= tion requests from different DOTS clients.  This mitigation request is= currently inactive until the conflicts are resolved. Another mitigation request is active.

=A7  2 | DOTS Server has detected conflicting mitiga= tion requests from different DOTS clients.  This mitigation request is= currently active.

=A7  3 | DOTS Server has detected conflicting mitiga= tion requests from different DOTS clients.  All conflicting mitigation= requests are inactive.

o=    conflict-scope: same structure as “scope&= #8221;

Cheers,

Med

 

K= onda, Tirumaleswar Reddy [mailto:Tiruma= leswarReddy_Konda@McAfee.com]
Envoy=E9 : jeudi 30 novembre 2017 10:41
=C0 : BOUCADAIR Mohamed IMT/OLN; Jon Shallow; dots@ietf.org
Objet : RE: [Dots] signal-channel: Conflict detection and notif= ication

 

The proposal works for me, is the plan to add 7, 8 and 9 status or ad= d a new “additional-status” parameter ?

 

-Tiru

 

From: mohamed.boucadair@orange.co= m [mailto:mohamed.bouca= dair@orange.com]
Sent: Wednesday, November 29, 2017 12:02 PM
To: Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@McAfee.com>; Jon Shallow= <supjps-ietf@jpshallow.com= >; dots@ietf.org
Subject: RE: [Dots] signal-channel: Conflict detection and notificat= ion

 

Hi Tiru,

 

I agree with you that discardin= g all conflicting requests may not be helpful in some cases. In the same wa= y that someone can argue that selecting only one request among conflicting ones may not be useful because the server picked= the wrong one.   

 

I do prefer to leave this to im= plementation/deployment as a policy to be supplied. That policy will instru= ct the dots server about the behavior to follow based one specific information that is available for a given deployment: &= nbsp;

=B7<= span lang=3D"EN-US" style=3D"font-size:7.0pt;font-family:"Times New Ro= man","serif";color:black">     &nbs= p; Pick one and deactivate all the others based on= some criteria

=B7<= span lang=3D"EN-US" style=3D"font-size:7.0pt;font-family:"Times New Ro= man","serif";color:black">     &nbs= p; Activate all of them

=B7<= span lang=3D"EN-US" style=3D"font-size:7.0pt;font-family:"Times New Ro= man","serif";color:black">     &nbs= p; De-activate all of them

 

Cheers,

Med

 

De : Dots [mailto:dots-bounces@ietf.org] De la part de Konda, Tirumaleswar Reddy
Envoy=E9 : mercredi 29 novembre 2017 06:39
=C0 : BOUCADAIR Mohamed IMT/OLN; Jon Shallow; dots@ietf.org
Objet : Re: [Dots] signal-channel: Conflict detection and notif= ication

 

Hi Med,

 

In a deployment scenario with a DDoS Detector (or a on premise DDoS m= itigation system) acting as DOTS clients and a web server with in-built DDo= S detection capability. The web server may not have as much visibility into the extent of the DDoS attack as the = DDoS Detector (or IDMS) and there will be conflicting mitigation requests f= rom different DOTS clients, discarding all the mitigation requests from dif= ferent clients will make the mechanism not useful.

 

-Tiru

 

From: mohamed.boucadair@orange.co= m [mailto:mohamed.bouca= dair@orange.com]
Sent: Tuesday, November 28, 2017 8:55 PM
To: Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@McAfee.com>; Jon Shallow= <supjps-ietf@jpshallow.com= >; dots@ietf.org
Subject: RE: [Dots] signal-channel: Conflict detection and notificat= ion

 

Tiru,

 

Please see inline.

 

Cheers,

Med

 

De : Dots [mailto:dots-bounces@ietf.org] De la part de Konda, Tirumaleswar Reddy
Envoy=E9 : mardi 28 novembre 2017 16:02
=C0 : Jon Shallow; BOUCADAIR Mohamed IMT/OLN; dots@ietf.org
Objet : Re: [Dots] signal-channel: Conflict detection and notif= ication

 

Within a administrative domain, there won’t be many different D= OTS clients raising conflicting mitigation requests for the same target, th= e conflict may arise between a DDoS Detector (or a on premise DDoS mitigation system) acting as DOTS clients and a web = server with in-built DDoS detection capability. 

[Med= ] I don’t think that we can speculate about the nature of the conflic= ts that may happen. Misconfigured and corrupted software instances may happen.

 

Under what conditions does the DOTS server return “DOTS Server = has detected conflicting mitigation requests from different DOTS clients.&n= bsp; All conflicting mitigation requests are inactive.” ?

[Med= ] A dots server can be typically instructed by a policy to discard conflict= ing requests. The rationale is that the provider thinks that the clients are misconfigured and something is needed to be fi= xed before solicited the server. The signal-channel does not need to call f= or a favorite action when conflicts; that is implementation- and deployment= -specific.  

 

-Tiru

 

From: Jon Shallow [mailto:s= upjps-ietf@jpshallow.com]
Sent: Tuesday, November 28, 2017 7:45 PM
To: mohamed.boucadai= r@orange.com; Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@McAfee.com>; dots@ietf.org
Subject: RE: [Dots] signal-channel: Conflict detection and notificat= ion

 

Hi Med,=

&n= bsp;

In prin= cipal I accept the concept of your 7, 8 & 9 status which in effect are = part of the mitigation state as in a state diagram.  However, having i= ssued a “8” status, this then needs to transition to another state which reflects what is actually happening – e.g. &#= 8220;2”.

&n= bsp;

The act= ual state could immediately be sent following the reporting of “8R= 21; (if Observe active), else it would need to wait until the next status G= ET.  It is possible that the “8” message gets lost, so relying on receiving the “8” could be dangerous.=

&n= bsp;

With a = “9” response what then is the DOTS client allowed to do?

- A ret= ry of the original mitigation request is likely to fail again

- If al= l the DOTS clients back off, then there will be no mitigation

- Shoul= d there be a random back-off time before retrying?

&n= bsp;

What is= critical is that

   &= nbsp;  DOTS servers in the same administrative domain attempting to ho= nor

   &= nbsp;  conflicting requests may flap network route or DNS information,=

   &= nbsp;  degrading the networks attempting to participate in attack=

   &= nbsp;  response with the DOTS clients.

Should not be allowed to happen.

&n= bsp;

I also = do not want to lose sight of

The notification SHOULD indicate the nature and scope of the conf= lict,

for example, the overlapping prefix range in a conflicting mitiga= tion request.”

This po= tentially can be conveyed in the 4.09 message, or could be a new mitigation= status parameter such as "additional-info" with an appropriate t= ext value.  It could be that “status” stays with “1” through “6”, and (possibly optional) “ad= ditional-status” has

0 | Thi= s DOTS client mitigation request is being honoured

1 | DOT= S Server has detected conflicting mitigation requests from different DOTS c= lients.  This mitigation request is currently inactive until the confl= icts are resolved. Another mitigation request is active.

2 | DOT= S Server has detected conflicting mitigation requests from different DOTS c= lients.  This mitigation request is currently active.

3 | DOT= S Server has detected conflicting mitigation requests from different DOTS c= lients.  All conflicting mitigation requests are inactive.<= /span>

And = 220;additional-info” reports on what the nature and scope of the conf= lict is.

&n= bsp;

Regards=

&n= bsp;

Jon

&n= bsp;

From:= Dots [mailto: dots-bounces@ietf.org] On B= ehalf Of mohamed.boucadair@orang= e.com
Sent: 28 November 2017 13:29
To: Jon Shallow; 'Konda, Tirumaleswar Reddy'; dots@ietf.org
Subject: Re: [Dots] signal-channel: Conflict detection and notificat= ion

 

Hi Jon, all,

 

Thank you for sharing your thou= ghts on this.

 

I tend to allow for both 4.09 c= ode and new status values in the spec.

 

I see that you proposed this ne= w value:

=3D=3D

7 | DOT= S Server has detected conflicting mitigation requests from different DOTS c= lients.  This mitigation request is currently inactive until the confl= icts are resolved. Another mitigation request is active.

=3D=3D

 

Please note that a server may b= e instructed to adopt a more strict behavior by deactivating all conflictin= g requests. Further, all DOTS clients which issued conflicting requests should be notified, not only the one for which a requ= est is de-activated. As such, I’m afraid we will need more values, e.= g.,

 

=3D=3D

7 | DOT= S Server has detected conflicting mitigation requests from different DOTS c= lients.  This mitigation request is currently inactive until the confl= icts are resolved. Another mitigation request is active.

8 | DOT= S Server has detected conflicting mitigation requests from different DOTS c= lients.  This mitigation request is currently active.

9 | DOT= S Server has detected conflicting mitigation requests from different DOTS c= lients.  All conflicting mitigation requests are inactive.<= /span>

=3D=3D

 

For example:<= /p>

* If the server decides to acti= vate only one request, then 7 will be sent to all clients for which the req= uest is de-activated and 8 to the client for which the request is maintained active.

* If the server decides to deac= tivate all requests, then 9 will be sent to all clients.  <= /span>

 

Cheers,

Med

 

J= on Shallow [mailto:supjps-ietf= @jpshallow.com]
Envoy=E9 : mardi 28 novembre 2017 13:31
=C0 : 'Konda, Tirumaleswar Reddy'; BOUCADAIR Mohamed IMT/OLN; dots@ietf.org
Objet : RE: [Dots] signal-channel: Conflict detection and notif= ication

 

Hi Tiru= ,

&n= bsp;

If Clie= nt-A has invoked a mitigation, then Client-B requests a conflicting mitigat= ion, if the DOTS server is only allowing the first mitigation request to be= the valid one, then the DOTS server could send back a 4.09 to Client-B.

&n= bsp;

However= , if the DOTS server is allowed to choose the best mitigation request, deci= des it is Client-B, there is no simple way of sending an unsolicited 4.09 t= o client-A.  Hence suggestion for an additional status message which can be sent to Client-A stating that Client-A has bee= n de-selected because of a mitigation request conflict.

&n= bsp;

It is a= lso possible that a mitigation state is status 1 (parameter value – T= able 2)) and needs to transition to another state – at which point th= e conflict is found - possibly by the DOTS mitigator - which then needs to be relayed back through the DOTS server.<= /span>

&n= bsp;

Regards=

&n= bsp;

Jon

&n= bsp;

From:= Konda, Tirumaleswar Reddy [mailto: TirumaleswarReddy_Konda@mcafee.com]
Sent: 28 November 2017 11:42
To: Jon Shallow; moh= amed.boucadair@orange.com; dots@ietf.org
Subject: RE: [Dots] signal-channel: Conflict detection and notificat= ion

 

Hi Jon,

 

What is the problem if the DOTS server returns 4.09 (conflict) error = response for the conflicting mitigation request from Client-A ?<= /span>

The above error code is already defined https://tools.ie= tf.org/html/rfc8132.

 

-Tiru

 

From: Dots [mailto:dots-bounces= @ietf.org] On Behalf Of Jon Shallow
Sent: Tuesday, November 28, 2017 4:50 PM
To: mohamed.boucadai= r@orange.com; dots@ietf.org
Subject: Re: [Dots] signal-channel: Conflict detection and notificat= ion

 

Hi Med,=

&n= bsp;

See inl= ine

&n= bsp;

Regards=

&n= bsp;

Jon

&n= bsp;

From:= Dots [mailto: dots-bounces@ietf.org] On B= ehalf Of ietf-supjps= -mohamed.boucadair@orange.com
Sent: 24 November 2017 14:03
To: dots@ietf.org
Subject: [Dots] signal-channel: Conflict detection and notification<= o:p>

 

Hi all,

 

As discussed during the last IETF meeting, = we are seeking for feedback from the WG about how to address this requireme= nt:

 

=3D=3D=3D=3D=3D=3D=3D=3D=3D

   SIG-00= 9  Conflict Detection and Notification: Multiple DOTS clients

   &= nbsp;  controlled by a single administrative entity may send conflicti= ng

   &= nbsp;  mitigation requests for pools of protected resources as a resul= t

   &= nbsp;  of misconfiguration, operator error, or compromised DOTS client= s.

   &= nbsp;  DOTS servers in the same administrative domain attempting to ho= nor

   &= nbsp;  conflicting requests may flap network route or DNS information,=

   &= nbsp;  degrading the networks attempting to participate in attack=

   &= nbsp;  response with the DOTS clients.  DOTS servers in a single<= o:p>

   &= nbsp;  administrative domain SHALL detect such conflicting requests, a= nd

   &= nbsp;  SHALL notify the DOTS clients in conflict.  The notificati= on

   &= nbsp;  SHOULD indicate the nature and scope of the conflict, for examp= le,

   &= nbsp;  the overlapping prefix range in a conflicting mitigation reques= t.

=3D=3D=3D=3D=3D=3D=3D=3D<= /p>

 

For example, would it be OK if we leave imp= lementation-specific the criteria upon which a dots server relies to consid= er two requests from two clients as conflicting, but draft-ietf-dots-signal defines only the procedure to notify clients wh= en a conflict is detected?

Jon>= I agree that how this is done is implementation specific.  However th= ere is a scenario where Client-A initiates a mitigation requests which is a= cted upon, Client-B does a conflicting mitigation request but the DOTS Server decides that Client-B is the “more”= ; valid mitigation request and effectively de-activates Client-A’s re= quest.  Table 2: draft-ietf-dots-signal-channel-09 therefore needs an = additional status parameter to indicate to client-A there is a conflict and hence Client-A is being stood down while another client = is controlling the mitigation.  A suggestion would be

&n= bsp;

7 | DOT= S Server has detected conflicting mitigation requests from different DOTS c= lients.  This mitigation request is currently inactive until the confl= icts are resolved. Another mitigation request is active.

&n= bsp;

Jon>= The DOTS client can then elect to leave in the mitigation request (and eve= n refresh the PUT to refresh the timeout) or delete it.

Jon>= I do not think it appropriate that an error message be sent back (e.g. 4.x= x) if the DOTS server immediately decides there is a conflicting request an= d closes down the new PUT request unless we come up with a specific error code so the DOTS client can understand wh= y the request is getting errored.

&n= bsp;

 

Likewise, would it be OK if the document do= es not specify which of the conflicting actions is to be discarded (old, ne= w, all) by the server, but draft-ietf-dots-signal defines how to inform clients about which action was enforced by the serve= r?

&n= bsp;

Jon>= Again, I think that this would be implementation specific.  The sugge= sted Table 2: entry above would cover this as well.  The DOTS client j= ust needs to know it has been de-selected / discarded – I don’t think the DOTS client needs to know how / why the DO= TS server chose that particular DOTS client.

 

Cheers,

Med

--_000_787AE7BB302AE849A7480A190F8B93300A084068OPEXCLILMA3corp_-- From nobody Thu Nov 30 03:14:02 2017 Return-Path: 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 A034C129436 for ; Thu, 30 Nov 2017 03:14:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.319 X-Spam-Level: X-Spam-Status: No, score=-4.319 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 guFuY4OOiJu2 for ; Thu, 30 Nov 2017 03:13:57 -0800 (PST) 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 B1D1C129431 for ; Thu, 30 Nov 2017 03:13:56 -0800 (PST) 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=1512040435; 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: x-originating-ip:x-ms-publictraffictype:x-microsoft-exchange-diagnostics: x-ms-exchange-antispam-srfa-diagnostics:x-ms-office365-filtering-correlation-id: x-microsoft-antispam:x-ms-traffictypediagnostic: x-microsoft-antispam-prvs:x-exchange-antispam-report-test: x-exchange-antispam-report-cfa-test:x-forefront-prvs: x-forefront-antispam-report:received-spf:authentication-results: spamdiagnosticoutput:spamdiagnosticmetadata: Content-Type: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-Transport-CrossTenantHeadersStamped: X-OriginatorOrg:X-NAI-Spam-Flag:X-NAI-Spam-Level: X-NAI-Spam-Threshold:X-NAI-Spam-Score:X-NAI-Spam-Version; bh=D3POjyNzq23RzFUKb5AM9yATbv1AQYsE38vvCa vwgkQ=; b=chado3aHEva+k282HBxW0HdRRqldTlvwELOZaPPN LPFGu9gVzaganJbl6NulXk0f8HLw4Oje6wHT4XIe3lpF596Lh9 CKaiu2y7ZiUCF8/pUtNdgZolbc5iODlY4ndwb3QMsNdSbNRvY2 YkP7uEsTMydqch5Dl6G9CNHSZM6H0FY= Received: from DNVEXAPP1N05.corpzone.internalzone.com (unknown [10.44.48.89]) by DNVWSMAILOUT1.mcafee.com with smtp id 2d41_5c71_ff0722d6_0568_4430_a73a_bfa8cafc88f9; Thu, 30 Nov 2017 05:13:54 -0600 Received: from DNVEXUSR1N13.corpzone.internalzone.com (10.44.48.86) by DNVEXAPP1N05.corpzone.internalzone.com (10.44.48.89) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Thu, 30 Nov 2017 04:13:35 -0700 Received: from DNVEXUSR1N09.corpzone.internalzone.com (10.44.48.82) by DNVEXUSR1N13.corpzone.internalzone.com (10.44.48.86) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Thu, 30 Nov 2017 04:13:33 -0700 Received: from DNVO365EDGE1.corpzone.internalzone.com (10.44.176.66) by DNVEXUSR1N09.corpzone.internalzone.com (10.44.48.82) with Microsoft SMTP Server (TLS) id 15.0.1347.2 via Frontend Transport; Thu, 30 Nov 2017 04:13:33 -0700 Received: from NAM01-BY2-obe.outbound.protection.outlook.com (10.44.176.243) by edge.mcafee.com (10.44.176.66) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Thu, 30 Nov 2017 04:13:32 -0700 Received: from DM5PR16MB1788.namprd16.prod.outlook.com (10.172.44.144) by DM5PR16MB1788.namprd16.prod.outlook.com (10.172.44.144) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.260.4; Thu, 30 Nov 2017 11:13:31 +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.20.0260.007; Thu, 30 Nov 2017 11:13:31 +0000 From: "Konda, Tirumaleswar Reddy" To: "mohamed.boucadair@orange.com" , Jon Shallow , "dots@ietf.org" Thread-Topic: [Dots] signal-channel: Conflict detection and notification Thread-Index: AQI5QycoOO+6Sl3hDoQKXRH887G99aJd55JwgAAKs5CAABDPgIAAEDEAgAAM/YCAAAnqQIAACYkAgADteRCAABAggIABvsNQgAAU9YCAAAQ9wIAAAq8AgAAA3YCAAAPQYA== Date: Thu, 30 Nov 2017 11:13:31 +0000 Message-ID: References: <787AE7BB302AE849A7480A190F8B93300A07F4E4@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <009b01d3683a$c6158f90$5240aeb0$@jpshallow.com> <00e201d36844$b1b39ec0$151adc40$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93300A0819DB@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <011301d36853$48efb680$dacf2380$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93300A081B18@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93300A08307A@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93300A084012@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <006901d369c9$20ad07f0$620717d0$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93300A084068@OPEXCLILMA3.corporate.adroot.infra.ftgroup> In-Reply-To: <787AE7BB302AE849A7480A190F8B93300A084068@OPEXCLILMA3.corporate.adroot.infra.ftgroup> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [103.245.47.20] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DM5PR16MB1788; 6:4bRbKabariwRmVS6NKJPpPk1D0p7HVWt94h+v/PGBVugBQL/pOFnRXz/lovb4jZK/nXVNWMgorqTAjYIeWfoN1E0kUgUna/6BuvywtoGZMM50eTK75AQI7003bMu1z0NvnK6E2/m7GwtsTJfMWp9nwRpGVcqPH1lCmAdIbiplUzc1yDsdioO3tMogiz6N7/zL69fgyoSNvRVUL8ulzLfBjJFJ1Da6BsgBMGbX9uylIktqYWToUSg35X96jwiPW0U9/oCfY9K77Fc9OavyfmkpRlm66eFNZhRx4o72DXkchRVMowugIwDxb792y4gQbkpifQo8kKSBpASy8cu/1cddLS0FqNUl44fFmBaaTNl8Hc=; 5:fppSV+e/y/rsV16S2KnEckNb0wFpem+PP7SoNtazI3+lnoXqDwC0zA9SwXh1xcD8OfcdnL6iJc4NUON8KtRcNn0FzCm9p3mzsA1l/Ept76HF96bVRkXoAjpLHbk0gMcwntZN6NNbzO/nQhIZ4J2Ym6H3HhxDgpm50Hx8lO2g0Rc=; 24:hNC2wDkVuqaVtDFbHbqH1xvTodLqt0smBgl0UBY2+v8UFNlkYFYFOoPRvo9Kve2v3yaMCBuynQPGils+xgY0xMzmG44jBykYqZUBrKylqGI=; 7:I0Vb9QWP0ks9cryYAdjHKOOcXLvLPuOMFcYT9ZPUsyMAUvSmRQ2tyCPiXFRNPEdPkSZ6CMpqJamF/eqtnUNL6EtAQAaypZ9aP8aA41onTMHTs3UziXxL+6YoMgSu6qvMCza+VNqJN1e2vxIaxsVjrJlA3fW8Rr4YGRdMYvblqSWzwZ4qKl2v+zfh5jtD+e4SswXaDLwkkgdxl20zvY6vu77/E7HGPk4FJlLec7dEmG5jRVi7gjUlxqdG/1kWeDBn x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 9d14e01b-19ee-4906-c342-08d537e363d0 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(5600026)(4604075)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(2017052603285); SRVR:DM5PR16MB1788; x-ms-traffictypediagnostic: DM5PR16MB1788: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(190756311086443)(158342451672863)(20558992708506)(227612066756510)(18271650672692)(21748063052155)(211171220733660)(123452027830198); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(2401047)(5005006)(8121501046)(93006095)(93001095)(3231022)(10201501046)(3002001)(6041248)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123560025)(20161123558100)(20161123555025)(20161123564025)(20161123562025)(6072148)(201708071742011); SRVR:DM5PR16MB1788; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:DM5PR16MB1788; x-forefront-prvs: 05079D8470 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(979002)(346002)(39860400002)(376002)(366004)(53754006)(32952001)(199003)(189002)(51444003)(236005)(189998001)(7110500001)(561944003)(33656002)(106356001)(6506006)(105586002)(2900100001)(55016002)(2906002)(790700001)(3846002)(6116002)(10710500007)(2501003)(8936002)(3280700002)(50986010)(14454004)(3660700001)(54356010)(110136005)(76176010)(478600001)(966005)(68736007)(606006)(15650500001)(72206003)(102836003)(7696005)(93886005)(2420400007)(25786009)(316002)(80792005)(99286004)(97736004)(9326002)(8676002)(345774005)(81166006)(7736002)(74316002)(6436002)(81156014)(229853002)(54896002)(101416001)(53946003)(66066001)(53936002)(2950100002)(77096006)(6246003)(19609705001)(86362001)(53546010)(6306002)(5660300001)(9686003)(85282002)(579004)(559001)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1101; SCL:1; SRVR:DM5PR16MB1788; H:DM5PR16MB1788.namprd16.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: McAfee.com does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=TirumaleswarReddy_Konda@McAfee.com; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_DM5PR16MB178820B97C5858B8CA6C590DEA380DM5PR16MB1788namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 9d14e01b-19ee-4906-c342-08d537e363d0 X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Nov 2017 11:13:31.3741 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4943e38c-6dd4-428c-886d-24932bc2d5de X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR16MB1788 X-OriginatorOrg: mcafee.com X-NAI-Spam-Flag: NO X-NAI-Spam-Level: X-NAI-Spam-Threshold: 15 X-NAI-Spam-Score: 0.9 X-NAI-Spam-Version: 2.3.0.9418 : core <6170> : inlines <6195> : streams <1771762> : uri <2542664> Archived-At: Subject: Re: [Dots] signal-channel: Conflict detection and notification 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Nov 2017 11:14:00 -0000 --_000_DM5PR16MB178820B97C5858B8CA6C590DEA380DM5PR16MB1788namp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Med, If required "additional-status" can be added in future specifications; As y= ou already know, DOTS protocol is extensible to define new standard and ven= dor-specific parameters. @Jon - Yes, ietf-dots-signal needs to be modified to include the mitigation= status parameters. -Tiru From: mohamed.boucadair@orange.com [mailto:mohamed.boucadair@orange.com] Sent: Thursday, November 30, 2017 4:24 PM To: Jon Shallow ; Konda, Tirumaleswar Reddy ; dots@ietf.org Subject: RE: [Dots] signal-channel: Conflict detection and notification Re-, Please see inline. Cheers, Med De : Jon Shallow [mailto:supjps-ietf@jpshallow.com] Envoy=E9 : jeudi 30 novembre 2017 11:51 =C0 : 'Konda, Tirumaleswar Reddy'; BOUCADAIR Mohamed IMT/OLN; dots@ietf.org= Objet : RE: [Dots] signal-channel: Conflict detection and notification This also looks good to me in principal. I do not think we need the "additional-status" layer - why not just go stra= ight to "conflict-information"? [Med] This is to leave it extensible if we need in the future to supply mor= e information for other purposes than conflicts. Does it make sense? I would like to see added "conflict-reason" with some defined conflict code= s under "conflict-information". However, none of this status (including bytes-dropped etc.) is defined in t= he yang module: ietf-dots-signal as ro entities. Regards Jon From: Dots [mailto: dots-bounces@ietf.org] On= Behalf Of Konda, Tirumaleswar Reddy Sent: 30 November 2017 10:42 To: mohamed.boucadair@orange.com; Jon = Shallow; dots@ietf.org Subject: Re: [Dots] signal-channel: Conflict detection and notification Looks good to me. -Tiru From: mohamed.boucadair@orange.com [ma= ilto:mohamed.boucadair@orange.com] Sent: Thursday, November 30, 2017 3:56 PM To: Konda, Tirumaleswar Reddy >; Jon Shallow >; dots@ietf.org Subject: RE: [Dots] signal-channel: Conflict detection and notification Hi Tiru, With the "additional-status" parameter, and given the current values define= d in Table 2, I don't see which status code to return when "additional-stat= us" is set to "3 | DOTS Server has detected conflicting mitigation requests= from different DOTS clients. All conflicting mitigation requests are inac= tive". I'm afraid new status codes should be defined for this to work (e.g.= , "X: Attack mitigation is withdrawn", "Y: Attack mitigation is rejected"). Note that in both approaches, we will need to supply additional information= to characterize the conflict (conflict-information). This information shou= ld be returned to all clients. So, what about considering this direction? - Update the status table with these NEW codes: o 7: Attack mitigation is withdrawn o 8: Attack mitigation is rejected - Allow for including 'additional-status'. Define 'conflict-information' = under that parent; 'conflict-information' can include the following sub-par= ameters: o conflict-status: three codes * 1 | DOTS Server has detected conflicting mitigation requests from differ= ent DOTS clients. This mitigation request is currently inactive until the = conflicts are resolved. Another mitigation request is active. * 2 | DOTS Server has detected conflicting mitigation requests from differ= ent DOTS clients. This mitigation request is currently active. * 3 | DOTS Server has detected conflicting mitigation requests from differ= ent DOTS clients. All conflicting mitigation requests are inactive. o conflict-scope: same structure as "scope" Cheers, Med De : Konda, Tirumaleswar Reddy [mailto:TirumaleswarReddy_Konda@McAfee.com] Envoy=E9 : jeudi 30 novembre 2017 10:41 =C0 : BOUCADAIR Mohamed IMT/OLN; Jon Shallow; dots@ietf.org Objet : RE: [Dots] signal-channel: Conflict detection and notification The proposal works for me, is the plan to add 7, 8 and 9 status or add a ne= w "additional-status" parameter ? -Tiru From: mohamed.boucadair@orange.com [ma= ilto:mohamed.boucadair@orange.com] Sent: Wednesday, November 29, 2017 12:02 PM To: Konda, Tirumaleswar Reddy >; Jon Shallow >; dots@ietf.org Subject: RE: [Dots] signal-channel: Conflict detection and notification Hi Tiru, I agree with you that discarding all conflicting requests may not be helpfu= l in some cases. In the same way that someone can argue that selecting only= one request among conflicting ones may not be useful because the server pi= cked the wrong one. I do prefer to leave this to implementation/deployment as a policy to be su= pplied. That policy will instruct the dots server about the behavior to fol= low based one specific information that is available for a given deployment= : * Pick one and deactivate all the others based on some criteria * Activate all of them * De-activate all of them Cheers, Med De : Dots [mailto:dots-bounces@ietf.org] De la part de Konda, Tirumaleswar = Reddy Envoy=E9 : mercredi 29 novembre 2017 06:39 =C0 : BOUCADAIR Mohamed IMT/OLN; Jon Shallow; dots@ietf.org Objet : Re: [Dots] signal-channel: Conflict detection and notification Hi Med, In a deployment scenario with a DDoS Detector (or a on premise DDoS mitigat= ion system) acting as DOTS clients and a web server with in-built DDoS dete= ction capability. The web server may not have as much visibility into the e= xtent of the DDoS attack as the DDoS Detector (or IDMS) and there will be c= onflicting mitigation requests from different DOTS clients, discarding all = the mitigation requests from different clients will make the mechanism not = useful. -Tiru From: mohamed.boucadair@orange.com [ma= ilto:mohamed.boucadair@orange.com] Sent: Tuesday, November 28, 2017 8:55 PM To: Konda, Tirumaleswar Reddy >; Jon Shallow >; dots@ietf.org Subject: RE: [Dots] signal-channel: Conflict detection and notification Tiru, Please see inline. Cheers, Med De : Dots [mailto:dots-bounces@ietf.org] De la part de Konda, Tirumaleswar = Reddy Envoy=E9 : mardi 28 novembre 2017 16:02 =C0 : Jon Shallow; BOUCADAIR Mohamed IMT/OLN; dots@ietf.org Objet : Re: [Dots] signal-channel: Conflict detection and notification Within a administrative domain, there won't be many different DOTS clients = raising conflicting mitigation requests for the same target, the conflict m= ay arise between a DDoS Detector (or a on premise DDoS mitigation system) a= cting as DOTS clients and a web server with in-built DDoS detection capabil= ity. [Med] I don't think that we can speculate about the nature of the conflicts= that may happen. Misconfigured and corrupted software instances may happen= . Under what conditions does the DOTS server return "DOTS Server has detected= conflicting mitigation requests from different DOTS clients. All conflict= ing mitigation requests are inactive." ? [Med] A dots server can be typically instructed by a policy to discard conf= licting requests. The rationale is that the provider thinks that the client= s are misconfigured and something is needed to be fixed before solicited th= e server. The signal-channel does not need to call for a favorite action wh= en conflicts; that is implementation- and deployment-specific. -Tiru From: Jon Shallow [mailto:supjps-ietf@jpshallow.com] Sent: Tuesday, November 28, 2017 7:45 PM To: mohamed.boucadair@orange.com; Kond= a, Tirumaleswar Reddy >; dots@ietf.org Subject: RE: [Dots] signal-channel: Conflict detection and notification Hi Med, In principal I accept the concept of your 7, 8 & 9 status which in effect a= re part of the mitigation state as in a state diagram. However, having iss= ued a "8" status, this then needs to transition to another state which refl= ects what is actually happening - e.g. "2". The actual state could immediately be sent following the reporting of "8" (= if Observe active), else it would need to wait until the next status GET. = It is possible that the "8" message gets lost, so relying on receiving the = "8" could be dangerous. With a "9" response what then is the DOTS client allowed to do? - A retry of the original mitigation request is likely to fail again - If all the DOTS clients back off, then there will be no mitigation - Should there be a random back-off time before retrying? What is critical is that DOTS servers in the same administrative domain attempting to honor conflicting requests may flap network route or DNS information, degrading the networks attempting to participate in attack response with the DOTS clients. Should not be allowed to happen. I also do not want to lose sight of The notification SHOULD indicate the nature and scope of the conflict, for example, the overlapping prefix range in a conflicting mitigation reque= st." This potentially can be conveyed in the 4.09 message, or could be a new mit= igation status parameter such as "additional-info" with an appropriate text= value. It could be that "status" stays with "1" through "6", and (possibl= y optional) "additional-status" has 0 | This DOTS client mitigation request is being honoured 1 | DOTS Server has detected conflicting mitigation requests from different= DOTS clients. This mitigation request is currently inactive until the con= flicts are resolved. Another mitigation request is active. 2 | DOTS Server has detected conflicting mitigation requests from different= DOTS clients. This mitigation request is currently active. 3 | DOTS Server has detected conflicting mitigation requests from different= DOTS clients. All conflicting mitigation requests are inactive. And "additional-info" reports on what the nature and scope of the conflict = is. Regards Jon From: Dots [mailto: dots-bounces@ietf.org] On= Behalf Of mohamed.boucadair@orange.com Sent: 28 November 2017 13:29 To: Jon Shallow; 'Konda, Tirumaleswar Reddy'; dots@ietf.org Subject: Re: [Dots] signal-channel: Conflict detection and notification Hi Jon, all, Thank you for sharing your thoughts on this. I tend to allow for both 4.09 code and new status values in the spec. I see that you proposed this new value: =3D=3D 7 | DOTS Server has detected conflicting mitigation requests from different= DOTS clients. This mitigation request is currently inactive until the con= flicts are resolved. Another mitigation request is active. =3D=3D Please note that a server may be instructed to adopt a more strict behavior= by deactivating all conflicting requests. Further, all DOTS clients which = issued conflicting requests should be notified, not only the one for which = a request is de-activated. As such, I'm afraid we will need more values, e.= g., =3D=3D 7 | DOTS Server has detected conflicting mitigation requests from different= DOTS clients. This mitigation request is currently inactive until the con= flicts are resolved. Another mitigation request is active. 8 | DOTS Server has detected conflicting mitigation requests from different= DOTS clients. This mitigation request is currently active. 9 | DOTS Server has detected conflicting mitigation requests from different= DOTS clients. All conflicting mitigation requests are inactive. =3D=3D For example: * If the server decides to activate only one request, then 7 will be sent t= o all clients for which the request is de-activated and 8 to the client for= which the request is maintained active. * If the server decides to deactivate all requests, then 9 will be sent to = all clients. Cheers, Med De : Jon Shallow [mailto:supjps-ietf@jpshallow.com] Envoy=E9 : mardi 28 novembre 2017 13:31 =C0 : 'Konda, Tirumaleswar Reddy'; BOUCADAIR Mohamed IMT/OLN; dots@ietf.org= Objet : RE: [Dots] signal-channel: Conflict detection and notification Hi Tiru, If Client-A has invoked a mitigation, then Client-B requests a conflicting = mitigation, if the DOTS server is only allowing the first mitigation reques= t to be the valid one, then the DOTS server could send back a 4.09 to Clien= t-B. However, if the DOTS server is allowed to choose the best mitigation reques= t, decides it is Client-B, there is no simple way of sending an unsolicited= 4.09 to client-A. Hence suggestion for an additional status message which= can be sent to Client-A stating that Client-A has been de-selected because= of a mitigation request conflict. It is also possible that a mitigation state is status 1 (parameter value - = Table 2)) and needs to transition to another state - at which point the con= flict is found - possibly by the DOTS mitigator - which then needs to be re= layed back through the DOTS server. Regards Jon From: Konda, Tirumaleswar Reddy [mailto: TirumaleswarReddy_Konda@mcafee.com= ] Sent: 28 November 2017 11:42 To: Jon Shallow; mohamed.boucadair@orange.com; dots@ietf.org Subject: RE: [Dots] signal-channel: Conflict detection and notification Hi Jon, What is the problem if the DOTS server returns 4.09 (conflict) error respon= se for the conflicting mitigation request from Client-A ? The above error code is already defined https://tools.ietf.org/html/rfc8132= . -Tiru From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Jon Shallow Sent: Tuesday, November 28, 2017 4:50 PM To: mohamed.boucadair@orange.com; dots= @ietf.org Subject: Re: [Dots] signal-channel: Conflict detection and notification Hi Med, See inline Regards Jon From: Dots [mailto: dots-bounces@ietf.org] On= Behalf Of ietf-supjps-mohamed.boucadair@orange.com Sent: 24 November 2017 14:03 To: dots@ietf.org Subject: [Dots] signal-channel: Conflict detection and notification Hi all, As discussed during the last IETF meeting, we are seeking for feedback from= the WG about how to address this requirement: =3D=3D=3D=3D=3D=3D=3D=3D=3D SIG-009 Conflict Detection and Notification: Multiple DOTS clients controlled by a single administrative entity may send conflicting mitigation requests for pools of protected resources as a result of misconfiguration, operator error, or compromised DOTS clients. DOTS servers in the same administrative domain attempting to honor conflicting requests may flap network route or DNS information, degrading the networks attempting to participate in attack response with the DOTS clients. DOTS servers in a single administrative domain SHALL detect such conflicting requests, and SHALL notify the DOTS clients in conflict. The notification SHOULD indicate the nature and scope of the conflict, for example, the overlapping prefix range in a conflicting mitigation request. =3D=3D=3D=3D=3D=3D=3D=3D For example, would it be OK if we leave implementation-specific the criteri= a upon which a dots server relies to consider two requests from two clients= as conflicting, but draft-ietf-dots-signal defines only the procedure to n= otify clients when a conflict is detected? Jon> I agree that how this is done is implementation specific. However the= re is a scenario where Client-A initiates a mitigation requests which is ac= ted upon, Client-B does a conflicting mitigation request but the DOTS Serve= r decides that Client-B is the "more" valid mitigation request and effectiv= ely de-activates Client-A's request. Table 2: draft-ietf-dots-signal-chann= el-09 therefore needs an additional status parameter to indicate to client-= A there is a conflict and hence Client-A is being stood down while another = client is controlling the mitigation. A suggestion would be 7 | DOTS Server has detected conflicting mitigation requests from different= DOTS clients. This mitigation request is currently inactive until the con= flicts are resolved. Another mitigation request is active. Jon> The DOTS client can then elect to leave in the mitigation request (and= even refresh the PUT to refresh the timeout) or delete it. Jon> I do not think it appropriate that an error message be sent back (e.g.= 4.xx) if the DOTS server immediately decides there is a conflicting reques= t and closes down the new PUT request unless we come up with a specific err= or code so the DOTS client can understand why the request is getting errore= d. Likewise, would it be OK if the document does not specify which of the conf= licting actions is to be discarded (old, new, all) by the server, but draft= -ietf-dots-signal defines how to inform clients about which action was enfo= rced by the server? Jon> Again, I think that this would be implementation specific. The sugges= ted Table 2: entry above would cover this as well. The DOTS client just ne= eds to know it has been de-selected / discarded - I don't think the DOTS cl= ient needs to know how / why the DOTS server chose that particular DOTS cli= ent. Cheers, Med --_000_DM5PR16MB178820B97C5858B8CA6C590DEA380DM5PR16MB1788namp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Med,

&nbs= p;

If requir= ed “additional-status” can be added in future specifications; A= s you already know, DOTS protocol is extensible to define new standard and = vendor-specific parameters.

@Jon R= 11; Yes, ietf-dots-signal needs to be modified to include the mitigation st= atus parameters.

&nbs= p;

-Tiru

 

From:<= /span> mohamed.boucadair@ora= nge.com [mailto:mohamed.boucadair@orange.com]
Sent: Thursday, November 30, 2017 4:24 PM
To: Jon Shallow <supjps-ietf@jpshallow.com>; Konda, Tirumalesw= ar Reddy <TirumaleswarReddy_Konda@McAfee.com>; dots@ietf.org
Subject: RE: [Dots] signal-channel: Conflict detection and notificat= ion

 

Re-,

 

Please see inline.

 

Cheers,

Med

 

De : Jon Shallow [mailto:supjps-ietf@jpshallow.com]
Envoy=E9 : jeudi 30 novembre 2017 11:51
=C0 : 'Konda, Tirumaleswar Reddy'; BOUCADAIR Mohamed IMT/OLN; <= a href=3D"mailto:dots@ietf.org"> dots@ietf.org
Objet : RE: [Dots] signal-channel: Conflict detection and notif= ication

 

This al= so looks good to me in principal.

&n= bsp;

I do no= t think we need the “additional-status” layer – why not j= ust go straight to “conflict-information”?

[Med] This is to leave it exten= sible if we need in the future to supply more information for other purpose= s than conflicts. Does it make sense?

&n= bsp;

I would= like to see added “conflict-reason” with some defined conflict= codes under “conflict-information”.

&n= bsp;

However= , none of this status (including bytes-dropped etc.) is defined in the yang= module: ietf-dots-signal as ro entities.

&n= bsp;

Regards=

&n= bsp;

Jon

&n= bsp;

From: Dots [mailto: dots-bounces@ietf.org] On B= ehalf Of Konda, Tirumaleswar Reddy
Sent: 30 November 2017 10:42
To: mohamed.boucadai= r@orange.com; Jon Shallow; dots@ietf.org
Subject: Re: [Dots] signal-channel: Conflict detection and notificat= ion

 

Looks goo= d to me.

&nbs= p;

-Tiru

&nbs= p;

From:<= /span> mohamed.boucadair@orange.co= m [mailto:mohamed.bouca= dair@orange.com]
Sent: Thursday, November 30, 2017 3:56 PM
To: Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@McAfee.com>; Jon Shallow= <supjps-ietf@jpshallow.com= >; dots@ietf.org
Subject: RE: [Dots] signal-channel: Conflict detection and notificat= ion

 

Hi Tiru,

 

With the “additional-status” param= eter, and given the current values defined in Table 2, I don’t see wh= ich status code to return when “additional-status” is set to &#= 8220;3 | DOTS Server has detected conflicting mitigation requests from different = DOTS clients.  All conflicting mitigation requests are inactive”= . I’m afraid new status codes should be defined for this to work (e.g= ., “X: Attack mitigation is withdrawn”, “Y: Attack mitigation is rejected”).

 

Note that in both approaches, we will need to = supply additional information to characterize the conflict (conflict-inform= ation). This information should be returned to all clients.

 

So, what about considering this direction?

-   Update the status table with these NEW codes:

o   7: Attack mitigation is withdrawn

o   8: Attack mitigation is rejected

-   Allow for including ‘additional-status’. Define &#= 8216;conflict-information’ under that parent; ‘conflict-informa= tion’ can include the following sub-parameters:

o   conflict-status: three codes

=A7  1 | DOTS Server has detected conflicting mitigation requests f= rom different DOTS clients.  This mitigation request is currently inac= tive until the conflicts are resolved. Another mitigation request is active.

=A7  2 | DOTS Server has detected conflicting mitigation requests f= rom different DOTS clients.  This mitigation request is currently acti= ve.

=A7  3 | DOTS Server has detected conflicting mitigation requests f= rom different DOTS clients.  All conflicting mitigation requests are i= nactive.

o   conflict-scope: same structure as “scope”

Cheers,

Med

 

De : Konda, Tirumaleswar Reddy [mailto:TirumaleswarReddy_Konda@McAfee.com]
Envoy=E9 : jeudi 30 novembre 2017 10:41
=C0 : BOUCADAIR Mohamed IMT/OLN; Jon Shallow; dots@ietf.org
Objet : RE: [Dots] signal-channel: Conflict detection and notif= ication

 

The propo= sal works for me, is the plan to add 7, 8 and 9 status or add a new “= additional-status” parameter ?

&nbs= p;

-Tiru

&nbs= p;

From:<= /span> mohamed.boucadair@orange.co= m [mailto:mohamed.bouca= dair@orange.com]
Sent: Wednesday, November 29, 2017 12:02 PM
To: Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@McAfee.com>; Jon Shallow= <supjps-ietf@jpshallow.com= >; dots@ietf.org
Subject: RE: [Dots] signal-channel: Conflict detection and notificat= ion

 

Hi Tiru,

 

I agree with you that discarding all conflicti= ng requests may not be helpful in some cases. In the same way that someone = can argue that selecting only one request among conflicting ones may not be useful because the server picked the wrong one= .   

 

I do prefer to leave this to implementation/de= ployment as a policy to be supplied. That policy will instruct the dots ser= ver about the behavior to follow based one specific information that is available for a given deployment:  

=B7&n= bsp;      Pick one and deactivate all the others based on some criteria<= o:p>

=B7&n= bsp;      Activate all of them

=B7&n= bsp;      De-activate all of them

 

Cheers,

Med

 

De : Dots [mailto:dots-bounces@ietf.org] De la part de Konda, Tirumaleswar Reddy
Envoy=E9 : mercredi 29 novembre 2017 06:39
=C0 : BOUCADAIR Mohamed IMT/OLN; Jon Shallow; dots@ietf.org
Objet : Re: [Dots] signal-channel: Conflict detection and notif= ication

 

Hi Med,

&nbs= p;

In a depl= oyment scenario with a DDoS Detector (or a on premise DDoS mitigation syste= m) acting as DOTS clients and a web server with in-built DDoS detection cap= ability. The web server may not have as much visibility into the extent of the DDoS attack as the DDoS Detector= (or IDMS) and there will be conflicting mitigation requests from different= DOTS clients, discarding all the mitigation requests from different client= s will make the mechanism not useful.

&nbs= p;

-Tiru

&nbs= p;

From:<= /span> mohamed.boucadair@orange.co= m [mailto:mohamed.bouca= dair@orange.com]
Sent: Tuesday, November 28, 2017 8:55 PM
To: Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@McAfee.com>; Jon Shallow= <supjps-ietf@jpshallow.com= >; dots@ietf.org
Subject: RE: [Dots] signal-channel: Conflict detection and notificat= ion

 

Tiru,

 

Please see inline.

 

Cheers,

Med

 

De : Dots [mailto:dots-bounces@ietf.org] De la part de Konda, Tirumaleswar Reddy
Envoy=E9 : mardi 28 novembre 2017 16:02
=C0 : Jon Shallow; BOUCADAIR Mohamed IMT/OLN; dots@ietf.org
Objet : Re: [Dots] signal-channel: Conflict detection and notif= ication

 

Within a = administrative domain, there won’t be many different DOTS clients rai= sing conflicting mitigation requests for the same target, the conflict may = arise between a DDoS Detector (or a on premise DDoS mitigation system) acting as DOTS clients and a web server with in-bu= ilt DDoS detection capability. 

[Med] I don’t= think that we can speculate about the nature of the conflicts that may hap= pen. Misconfigured and corrupted software instances may happen.

&nbs= p;

Under wha= t conditions does the DOTS server return “DOTS Server has detected co= nflicting mitigation requests from different DOTS clients.  All confli= cting mitigation requests are inactive.” ?

[Med] A dots server= can be typically instructed by a policy to discard conflicting requests. T= he rationale is that the provider thinks that the clients are misconfigured and something is needed to be fixed before s= olicited the server. The signal-channel does not need to call for a favorit= e action when conflicts; that is implementation- and deployment-specific. &= nbsp;

&nbs= p;

-Tiru

&nbs= p;

From:<= /span> Jon Shallow [mailto:supjps-ietf@jpshallow.com]
Sent: Tuesday, November 28, 2017 7:45 PM
To: mohamed.boucadai= r@orange.com; Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@McAfee.com>; dots@ietf.org
Subject: RE: [Dots] signal-channel: Conflict detection and notificat= ion

 

Hi Med,=

&n= bsp;

In prin= cipal I accept the concept of your 7, 8 & 9 status which in effect are = part of the mitigation state as in a state diagram.  However, having i= ssued a “8” status, this then needs to transition to another state which reflects what is actually happening – e.g. &#= 8220;2”.

&n= bsp;

The act= ual state could immediately be sent following the reporting of “8R= 21; (if Observe active), else it would need to wait until the next status G= ET.  It is possible that the “8” message gets lost, so relying on receiving the “8” could be dangerous.=

&n= bsp;

With a = “9” response what then is the DOTS client allowed to do?

- A ret= ry of the original mitigation request is likely to fail again

- If al= l the DOTS clients back off, then there will be no mitigation

- Shoul= d there be a random back-off time before retrying?

&n= bsp;

What is= critical is that

      DOT= S servers in the same administrative domain attempting to honor<= /span>

      con= flicting requests may flap network route or DNS information,

      deg= rading the networks attempting to participate in attack

      res= ponse with the DOTS clients.

Should not b= e allowed to happen.

&n= bsp;

I also = do not want to lose sight of

The not= ification SHOULD indicate the nature and scope of the conflict,<= /span>

for exa= mple, the overlapping prefix range in a conflicting mitigation request.R= 21;

This po= tentially can be conveyed in the 4.09 message, or could be a new mitigation= status parameter such as "additional-info" with an appropriate t= ext value.  It could be that “status” stays with “1” through “6”, and (possibly optional) “ad= ditional-status” has

0 | Thi= s DOTS client mitigation request is being honoured

1 | DOTS Server has de= tected conflicting mitigation requests from different DOTS clients.  T= his mitigation request is currently inactive until the conflicts are resolv= ed. Another mitigation request is active.

2 | DOTS Server has de= tected conflicting mitigation requests from different DOTS clients.  T= his mitigation request is currently active.

3 | DOTS Server has de= tected conflicting mitigation requests from different DOTS clients.  A= ll conflicting mitigation requests are inactive.

And = 220;additional-info” reports on what the nature and scope of the conf= lict is.

&n= bsp;

Regards=

&n= bsp;

Jon

&n= bsp;

From: Dots [mailto: dots-bounces@ietf.org] On B= ehalf Of mohamed.boucadair@orang= e.com
Sent: 28 November 2017 13:29
To: Jon Shallow; 'Konda, Tirumaleswar Reddy'; dots@ietf.org
Subject: Re: [Dots] signal-channel: Conflict detection and notificat= ion

 

Hi Jon, all,

 

Thank you for sharing your thoughts on this.

 

I tend to allow for both 4.09 code and new sta= tus values in the spec.

 

I see that you proposed this new value:

=3D=3D

7 | DOTS Server has de= tected conflicting mitigation requests from different DOTS clients.  T= his mitigation request is currently inactive until the conflicts are resolv= ed. Another mitigation request is active.

=3D=3D

 

Please note that a server may be instructed to= adopt a more strict behavior by deactivating all conflicting requests. Fur= ther, all DOTS clients which issued conflicting requests should be notified, not only the one for which a request is de-ac= tivated. As such, I’m afraid we will need more values, e.g.,

 

=3D=3D

7 | DOTS Server has de= tected conflicting mitigation requests from different DOTS clients.  T= his mitigation request is currently inactive until the conflicts are resolv= ed. Another mitigation request is active.

8 | DOTS Server has de= tected conflicting mitigation requests from different DOTS clients.  T= his mitigation request is currently active.

9 | DOTS Server has de= tected conflicting mitigation requests from different DOTS clients.  A= ll conflicting mitigation requests are inactive.

=3D=3D

 

For example:

* If the server decides to activate only one r= equest, then 7 will be sent to all clients for which the request is de-acti= vated and 8 to the client for which the request is maintained active.

* If the server decides to deactivate all requ= ests, then 9 will be sent to all clients.  

 

Cheers,

Med

 

De : Jon Shallow [mailto:supjps-ietf@jpshallow.com]
Envoy=E9 : mardi 28 novembre 2017 13:31
=C0 : 'Konda, Tirumaleswar Reddy'; BOUCADAIR Mohamed IMT/OLN; dots@ietf.org
Objet : RE: [Dots] signal-channel: Conflict detection and notif= ication

 

Hi Tiru= ,

&n= bsp;

If Clie= nt-A has invoked a mitigation, then Client-B requests a conflicting mitigat= ion, if the DOTS server is only allowing the first mitigation request to be= the valid one, then the DOTS server could send back a 4.09 to Client-B.

&n= bsp;

However= , if the DOTS server is allowed to choose the best mitigation request, deci= des it is Client-B, there is no simple way of sending an unsolicited 4.09 t= o client-A.  Hence suggestion for an additional status message which can be sent to Client-A stating that Client-A has bee= n de-selected because of a mitigation request conflict.

&n= bsp;

It is a= lso possible that a mitigation state is status 1 (parameter value – T= able 2)) and needs to transition to another state – at which point th= e conflict is found - possibly by the DOTS mitigator - which then needs to be relayed back through the DOTS server.<= /span>

&n= bsp;

Regards=

&n= bsp;

Jon

&n= bsp;

From: Konda, Tirumaleswar Reddy [mailto: TirumaleswarReddy_Kon= da@mcafee.com]
Sent: 28 November 2017 11:42
To: Jon Shallow; moh= amed.boucadair@orange.com; dots@ietf.org
Subject: RE: [Dots] signal-channel: Conflict detection and notificat= ion

 

Hi Jon,

&nbs= p;

What is t= he problem if the DOTS server returns 4.09 (conflict) error response for th= e conflicting mitigation request from Client-A ?

The above= error code is already defined https://tools.ie= tf.org/html/rfc8132.

&nbs= p;

-Tiru

&nbs= p;

From:<= /span> Dots [mailto:dots-bounces@ietf.org] On Behalf Of Jon Shallow
Sent: Tuesday, November 28, 2017 4:50 PM
To: mohamed.boucadai= r@orange.com; dots@ietf.org
Subject: Re: [Dots] signal-channel: Conflict detection and notificat= ion

 

Hi Med,=

&n= bsp;

See inl= ine

&n= bsp;

Regards=

&n= bsp;

Jon

&n= bsp;

From: Dots [mailto: dots-bounces@ietf.org] On B= ehalf Of ietf-supjps= -mohamed.boucadair@orange.com
Sent: 24 November 2017 14:03
To: dots@ietf.org
Subject: [Dots] signal-channel: Conflict detection and notification<= o:p>

 

Hi all,

 

As discussed during the last IETF meeting, we are seeking = for feedback from the WG about how to address this requirement:<= /span>

 

=3D=3D=3D=3D=3D=3D=3D=3D=3D

   SIG-009  Conflic= t Detection and Notification: Multiple DOTS clients

      con= trolled by a single administrative entity may send conflicting

      mit= igation requests for pools of protected resources as a result

      of = misconfiguration, operator error, or compromised DOTS clients.

      DOT= S servers in the same administrative domain attempting to honor<= /span>

      con= flicting requests may flap network route or DNS information,

      deg= rading the networks attempting to participate in attack

      res= ponse with the DOTS clients.  DOTS servers in a single

      adm= inistrative domain SHALL detect such conflicting requests, and

      SHA= LL notify the DOTS clients in conflict.  The notification

      SHO= ULD indicate the nature and scope of the conflict, for example,<= /span>

      the= overlapping prefix range in a conflicting mitigation request.

=3D=3D=3D=3D=3D=3D=3D=3D

 

For example, would it be OK if we leave implementation-spe= cific the criteria upon which a dots server relies to consider two requests= from two clients as conflicting, but draft-ietf-dots-signal defines only the procedure to notify clients when a conflict is detected? =

Jon> I agree that h= ow this is done is implementation specific.  However there is a scenar= io where Client-A initiates a mitigation requests which is acted upon, Clie= nt-B does a conflicting mitigation request but the DOTS Server decides that Client-B is the “more” valid miti= gation request and effectively de-activates Client-A’s request. = Table 2: draft-ietf-dots-signal-channel-09 therefore needs an additional s= tatus parameter to indicate to client-A there is a conflict and hence Client-A is being stood down while another client is controlling= the mitigation.  A suggestion would be

 

7 | DOTS Server has de= tected conflicting mitigation requests from different DOTS clients.  T= his mitigation request is currently inactive until the conflicts are resolv= ed. Another mitigation request is active.

 

Jon> The DOTS clien= t can then elect to leave in the mitigation request (and even refresh the P= UT to refresh the timeout) or delete it.

Jon> I do not think= it appropriate that an error message be sent back (e.g. 4.xx) if the DOTS = server immediately decides there is a conflicting request and closes down t= he new PUT request unless we come up with a specific error code so the DOTS client can understand why the request is= getting errored.

 

 

Likewise, would it be OK if the document does not specify = which of the conflicting actions is to be discarded (old, new, all) by the = server, but draft-ietf-dots-signal defines how to inform clients about which action was enforced by the server?

 

Jon> Again, I think= that this would be implementation specific.  The suggested Table 2: e= ntry above would cover this as well.  The DOTS client just needs to kn= ow it has been de-selected / discarded – I don’t think the DOTS client needs to know how / why the DOTS server chose that p= articular DOTS client.

 

Cheers,

Med

--_000_DM5PR16MB178820B97C5858B8CA6C590DEA380DM5PR16MB1788namp_--