From nobody Tue Jan 2 00:48:40 2018 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 4DB231200B9 for ; Tue, 2 Jan 2018 00:48:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.01 X-Spam-Level: X-Spam-Status: No, score=-7.01 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, T_RP_MATCHES_RCVD=-0.01] 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 JkUHmYgg5Wxu for ; Tue, 2 Jan 2018 00:48:35 -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 7565E126CC4 for ; Tue, 2 Jan 2018 00: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=1514882912; 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:x-microsoft-antispam-message-info: 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=U kV5zTTbPlZEjOxGt5fjnXrV47SS4+yieUjN+LALxX 8=; b=cWqqEH7nn2vIuWoGTPewH3ULv3z4sHBqBK1orSkWxvoZ UxtUIxBPKJk30YXGMs0NNzgviTZdZCBiIn8OK51uNrYiKVP/zQ WZI2R5X9guyI2FZ8ZILpmSECaf7JdsCMRQqpq0CnU4OpaGUf+G L+g42KO9JqYS02txwvJ9jOK38GM= Received: from MIVEXAPP1N01.corpzone.internalzone.com (mivexapp1n01.corpzone.internalzone.com [10.48.48.88]) by MIVWSMAILOUT1.mcafee.com with smtp (TLS: TLSv1/SSLv3,256bits,ECDHE-RSA-AES256-SHA384) id 390f_91f9_91cb60e0_2770_436d_a064_e3981d2e4345; Tue, 02 Jan 2018 02:48:31 -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; Tue, 2 Jan 2018 03:48:26 -0500 Received: from MIVEXUSR1N04.corpzone.internalzone.com (10.48.48.84) by MIVEXUSR1N04.corpzone.internalzone.com (10.48.48.84) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Tue, 2 Jan 2018 03:48:25 -0500 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; Tue, 2 Jan 2018 03:48:25 -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; Tue, 2 Jan 2018 03:48:24 -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.366.8; Tue, 2 Jan 2018 08:48: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.0366.007; Tue, 2 Jan 2018 08:48:23 +0000 From: "Konda, Tirumaleswar Reddy" To: Jon Shallow , "dots@ietf.org" Thread-Topic: [Dots] Using SNI Thread-Index: AdOBYSmGAk9KbyE4TFyYKC/j9TeHqgCRKPHw Date: Tue, 2 Jan 2018 08:48:23 +0000 Message-ID: References: <0a1201d38161$299ef350$7cdcd9f0$@jpshallow.com> In-Reply-To: <0a1201d38161$299ef350$7cdcd9f0$@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; 7:8KLBH9JoiHWTv09y6Q4SmcQUJftU8y1nfoRl3LmdoWg4/bR84eyTS76NKMIMYf3biAeTkZVgr9kyjZupmotDZ46OGFuPpCZmXJWzzCSToXAWP9HFn7O4M1jOr3TlKzklMIgEN53nBtI6Yky/oh5abeT8viLc5Nb5hf0nKi7uTlWaxjEghmZl6rnOSNyQQXQZN/J3O4ymDQqnVVX5VOWF0MTgbN+/jfRv/EYeb7qWncutvXbbhA9+Eh2NOBtB7zQO x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: eaa274ba-4d45-4fc4-9ed2-08d551bd952f x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(5600026)(4604075)(3008032)(2017052603307)(7153060); SRVR:DM5PR16MB1786; x-ms-traffictypediagnostic: DM5PR16MB1786: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(192374486261705)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040470)(2401047)(5005006)(8121501046)(3002001)(3231023)(944501075)(93006095)(93001095)(10201501046)(6041268)(20161123562045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(20161123564045)(20161123558120)(6072148)(201708071742011); SRVR:DM5PR16MB1786; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:DM5PR16MB1786; x-forefront-prvs: 0540846A1D x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(376002)(39860400002)(39380400002)(346002)(396003)(366004)(199004)(189003)(32952001)(51444003)(80792005)(2900100001)(97736004)(25786009)(2501003)(19609705001)(99286004)(2906002)(229853002)(66066001)(2950100002)(68736007)(8936002)(9326002)(53546011)(6506007)(5660300001)(6246003)(86362001)(6116002)(790700001)(3846002)(102836004)(105586002)(8676002)(81166006)(81156014)(74316002)(55016002)(7736002)(106356001)(7696005)(59450400001)(14454004)(3660700001)(76176011)(53936002)(72206003)(316002)(3280700002)(9686003)(77096006)(478600001)(33656002)(6306002)(54896002)(110136005)(6436002)(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) x-microsoft-antispam-message-info: C1DijSjeqPFSwwAVzNednUsMR326UPivnyxGb8LNoR0XN4pQmgLiFAIgXlsmlJAp+VURX1BBSpYenvnI5QkSaQ== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_DM5PR16MB1788DFD34B28059887A7E690EA190DM5PR16MB1788namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: eaa274ba-4d45-4fc4-9ed2-08d551bd952f X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Jan 2018 08:48:23.5606 (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 <6190> : inlines <6292> : streams <1774871> : uri <2561642> Archived-At: Subject: Re: [Dots] Using SNI 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, 02 Jan 2018 08:48:38 -0000 --_000_DM5PR16MB1788DFD34B28059887A7E690EA190DM5PR16MB1788namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Jon, Both signal and data channel drafts refer to RFC7525 for secure use of (D)T= LS and RFC7525 mandates TLS implementations to support SNI. I don't see the= need to explicitly discuss SNI in these drafts. Regards, -Tiru From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Jon Shallow Sent: Saturday, December 30, 2017 4:57 PM To: dots@ietf.org Subject: [Dots] Using SNI Hi WG, When providing a DOTS server data channel service in my environment, this s= hares the same ip / port which also provides other services (e.g. GUI / RES= T server etc.). Even if the Root Discovery points to another IP and or por= t for the actual data channel activity, the TLS exchanges for the Root Disc= overy have to correctly work. I suspect that I am not the only DOTS vendor= who will have this type of requirement of a single IP providing multiple T= LS services. As DOTS requires mutual authentication, this is a different security requir= ement than required by the GUI environment (DOTS requires client cert to be= presented, GUI does not and providing certificates to every GUI client is = not a practical option). This can be handled by using SNI by using 2 different FQDNs and requiring t= he DOTS client to include the DOTS specific FQDN in the TLS Client Hello. = Whether the GUI client does or does not (likely does with modern browsers) = include a SNI FQDN when connecting to the non DOTS FQDN does not really mat= ter - for DOTS it is recognizing the DOTS specific FQDN and setting up the = TLS as appropriate. To make sure interoperability between DOTS vendors, I would like to see som= ething like added to the data channel spec "DOTS clients MUST include the D= OTS server FQDN in the TLS Client Hello packet by using Server Name Indicat= ion (SNI) RFC 3546". In addition, I think that this would be a good idea as well for the signal = draft - thereby giving DOTS vendors the opportunity to host multiple DOTS s= ervers (likely to be different security requirements for their different cl= ient) on a single IP / port. Thoughts / comments? Regards Jon --_000_DM5PR16MB1788DFD34B28059887A7E690EA190DM5PR16MB1788namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Jon,

&nbs= p;

Both sign= al and data channel drafts refer to RFC7525 for secure use of (D)TLS and RF= C7525 mandates TLS implementations to support SNI. I don’t see the ne= ed to explicitly discuss SNI in these drafts.


Regards,

-Tiru

 

From:<= /span> Dots [mailto:dots-bou= nces@ietf.org] On Behalf Of Jon Shallow
Sent: Saturday, December 30, 2017 4:57 PM
To: dots@ietf.org
Subject: [Dots] Using SNI

 

Hi WG,

 

When providing a DOTS server da= ta channel service in my environment, this shares the same ip / port which = also provides other services (e.g. GUI / REST server etc.).  Even if t= he Root Discovery points to another IP and or port for the actual data channel activity, the TLS exchanges for the Ro= ot Discovery have to correctly work.  I suspect that I am not the only= DOTS vendor who will have this type of requirement of a single IP providin= g multiple TLS services.

 

As DOTS requires mutual authent= ication, this is a different security requirement than required by the GUI = environment (DOTS requires client cert to be presented, GUI does not and pr= oviding certificates to every GUI client is not a practical option).

 

This can be handled by using SN= I by using 2 different FQDNs and requiring the DOTS client to include the D= OTS specific FQDN in the TLS Client Hello.  Whether the GUI client doe= s or does not (likely does with modern browsers) include a SNI FQDN when connecting to the non DOTS FQDN does not really ma= tter – for DOTS it is recognizing the DOTS specific FQDN and setting = up the TLS as appropriate.

 

To make sure interoperability b= etween DOTS vendors, I would like to see something like added to the data c= hannel spec “DOTS clients MUST include the DOTS server FQDN in the TL= S Client Hello packet by using Server Name Indication (SNI) RFC 3546”.

 

In addition, I think that this = would be a good idea as well for the signal draft – thereby giving DO= TS vendors the opportunity to host multiple DOTS servers (likely to be diff= erent security requirements for their different client) on a single IP / port.

 

Thoughts / comments?=

 

Regards

 

Jon

--_000_DM5PR16MB1788DFD34B28059887A7E690EA190DM5PR16MB1788namp_-- From nobody Tue Jan 2 01:01:17 2018 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 59AD4126D3F for ; Tue, 2 Jan 2018 01:01:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.01 X-Spam-Level: X-Spam-Status: No, score=-7.01 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, T_RP_MATCHES_RCVD=-0.01] 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 rR-uDOTv-Q6i for ; Tue, 2 Jan 2018 01:01:12 -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 DCE2D126CD6 for ; Tue, 2 Jan 2018 01:01:11 -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=1514883670; 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: x-microsoft-antispam-message-info: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=HaBY3AiPUbKdhvPLQq0mQiGV52hRredYLKRPr6 O9qTY=; b=otNg2ZiI/oNAkNa7OXUqowpLgxZVR705ixgvSPPl zn+XdwXsQa+/aruecNBCwjBMm+8gxlQQrufqeHG8yc0y2IBOTO hA5GfBRXDb9Wol1SaKattkrlFljB41wA+euCMUl8VQSnrHzZql CX2U1bq2s1Xo90rdFD+5Pv28m+7BvJ8= Received: from MIVEXAPP1N01.corpzone.internalzone.com (mivexapp1n01.corpzone.internalzone.com [10.48.48.88]) by MIVWSMAILOUT1.mcafee.com with smtp (TLS: TLSv1/SSLv3,256bits,ECDHE-RSA-AES256-SHA384) id 390f_9bea_02f7afb4_cc59_4894_a91a_ba6b8f6c32cb; Tue, 02 Jan 2018 03:01:10 -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; Tue, 2 Jan 2018 04:01:08 -0500 Received: from MIVEXAPP1N01.corpzone.internalzone.com (10.48.48.88) by MIVEXUSR1N07.corpzone.internalzone.com (10.48.48.87) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Tue, 2 Jan 2018 04:01:07 -0500 Received: from MIVO365EDGE4.corpzone.internalzone.com (10.48.176.87) by MIVEXAPP1N01.corpzone.internalzone.com (10.48.48.88) with Microsoft SMTP Server (TLS) id 15.0.1347.2 via Frontend Transport; Tue, 2 Jan 2018 04:01:07 -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, 2 Jan 2018 04:01:05 -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.366.8; Tue, 2 Jan 2018 09:01:05 +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.0366.007; Tue, 2 Jan 2018 09:01:05 +0000 From: "Konda, Tirumaleswar Reddy" To: Jon Shallow , "dots@ietf.org" Thread-Topic: [Dots] source-ip-prefix in signal mitigation request. Thread-Index: AdOAwHWSK0qslD93TEaNhsHenXcqSQC5mwMg Date: Tue, 2 Jan 2018 09:01:05 +0000 Message-ID: References: <09c301d380c0$75b1d060$61157120$@jpshallow.com> In-Reply-To: <09c301d380c0$75b1d060$61157120$@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; 7:l4pTmoaBsDYlbIFZZ5t/cxljkZ7nlWTCBnLdQ8fXc3f17AyvEcDPENhUgzET1aMjr/WLdqyaW4h2Wb+dbpAxv4h8fdBtzK2AKuLu2CSlrG8vcWsoARewZiP50U0NBg9Xvq6ae3np61mYOryVQFXaTdRQvWuIjXMgdGNTuus9R7u3UCEvwnBNJPYIBF90mmI1FKl1DrQi6/PhRW6J8UNtwAa9S++GsNliJafNZAs1KLc9wMR36OXV3f9uoTIPE9Qb x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: c3ba7432-024a-4eba-1b40-08d551bf5b65 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(5600026)(4604075)(3008032)(2017052603307)(7153060); SRVR:DM5PR16MB1788; x-ms-traffictypediagnostic: DM5PR16MB1788: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040470)(2401047)(8121501046)(5005006)(10201501046)(3002001)(93006095)(93001095)(3231023)(944501075)(6041268)(20161123562045)(20161123558120)(20161123564045)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(6072148)(201708071742011); SRVR:DM5PR16MB1788; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:DM5PR16MB1788; x-forefront-prvs: 0540846A1D x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39850400004)(396003)(366004)(346002)(39380400002)(376002)(32952001)(189003)(199004)(2950100002)(54896002)(99286004)(86362001)(6246003)(6436002)(105586002)(76176011)(966005)(106356001)(229853002)(2501003)(316002)(77096006)(74316002)(9326002)(19609705001)(25786009)(81166006)(81156014)(236005)(8676002)(7696005)(230783001)(478600001)(6306002)(9686003)(8936002)(110136005)(2900100001)(2906002)(14454004)(66066001)(33656002)(80792005)(53546011)(53936002)(68736007)(55016002)(5660300001)(3846002)(6116002)(72206003)(97736004)(3280700002)(3660700001)(59450400001)(102836004)(790700001)(7736002)(606006)(6506007)(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; x-microsoft-antispam-message-info: Hsb03jHyeidE670nqEvLnpOliJZnd+3/llhCG95ALSwIAeuEqAdLh2Mju18IiUK8geFG5NF2nGPG2bH+yBy4iA== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_DM5PR16MB1788597C9C6A9BC52EB84EB8EA190DM5PR16MB1788namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: c3ba7432-024a-4eba-1b40-08d551bf5b65 X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Jan 2018 09:01:05.6124 (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 <6190> : inlines <6292> : streams <1774872> : uri <2561649> Archived-At: Subject: Re: [Dots] source-ip-prefix in signal mitigation request. 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, 02 Jan 2018 09:01:14 -0000 --_000_DM5PR16MB1788597C9C6A9BC52EB84EB8EA190DM5PR16MB1788namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Jon, We had published a draft https://tools.ietf.org/html/draft-doron-dots-telem= etry-00 that discusses DOTS telemetry to optimize the DDoS mitigation servi= ce, the feedback we received from the WG was to take it up after the initial DOTS WG milestones are met. Cheers, -Tiru From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Jon Shallow Sent: Friday, December 29, 2017 9:47 PM To: dots@ietf.org Subject: [Dots] source-ip-prefix in signal mitigation request. Hi WG, Currently, the signal spec only allows for target-* definitions with the op= tion for Vendor-Specific CBOR Key values. We have already seen from ietf-100 interoperability tests that there is pot= entially already one Vendor-Specific definition of source-ip-prefix. Does it make sense to have "source-ip-prefix" as a standard, optional param= eter? There will be a limitation of number of source IPs that can be defined due = to packet MTU. The mitigation overlapping rules (e.g. same "target-ip") where the highest = "mitigation-id" is the active rule will also constrain the number of source= IPs. It does however give the flexibility of, say, temporarily black-listing cer= tain IPs that an intelligent DOTS client has determined to be the most acti= ve in an attack. Comments? Regards Jon --_000_DM5PR16MB1788597C9C6A9BC52EB84EB8EA190DM5PR16MB1788namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Jon,

&nbs= p;

We had pu= blished a draft https= ://tools.ietf.org/html/draft-doron-dots-telemetry-00 that discusses DOT= S telemetry to optimize the DDoS mitigation service, the feedback we receiv= ed from the WG

was to ta= ke it up after the initial DOTS WG milestones are met.

&nbs= p;

Cheers,

-Tiru

 

From:<= /span> Dots [mailto:dots-bou= nces@ietf.org] On Behalf Of Jon Shallow
Sent: Friday, December 29, 2017 9:47 PM
To: dots@ietf.org
Subject: [Dots] source-ip-prefix in signal mitigation request.<= /o:p>

 

Hi WG,

 

Currently, the signal spec only= allows for target-* definitions with the option for Vendor-Specific CBOR K= ey values.

 

We have already seen from ietf-= 100 interoperability tests that there is potentially already one Vendor-Spe= cific definition of source-ip-prefix.

 

Does it make sense to have R= 20;source-ip-prefix” as a standard, optional parameter?

 

There will be a limitation of n= umber of source IPs that can be defined due to packet MTU.

 

The mitigation overlapping rule= s (e.g. same “target-ip”) where the highest “mitigation-i= d” is the active rule will also constrain the number of source IPs.

 

It does however give the flexib= ility of, say, temporarily black-listing certain IPs that an intelligent DO= TS client has determined to be the most active in an attack.

 

Comments?

 

Regards

 

Jon

--_000_DM5PR16MB1788597C9C6A9BC52EB84EB8EA190DM5PR16MB1788namp_-- From nobody Tue Jan 2 01:40:08 2018 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 50659126D45 for ; Tue, 2 Jan 2018 01:40:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 6FB_4I-wnVx8 for ; Tue, 2 Jan 2018 01:40:04 -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 87C961200B9 for ; Tue, 2 Jan 2018 01:40:04 -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 1eWJ3B-0006fU-Mt; Tue, 02 Jan 2018 09:40:01 +0000 From: "Jon Shallow" To: "'Konda, Tirumaleswar Reddy'" , References: <0a1201d38161$299ef350$7cdcd9f0$@jpshallow.com> In-Reply-To: Date: Tue, 2 Jan 2018 09:40:00 -0000 Message-ID: <0b2301d383ad$a8822a40$f9867ec0$@jpshallow.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0B24_01D383AD.A8822A40" X-Mailer: Microsoft Outlook 14.0 Content-Language: en-gb Thread-Index: AQIpdHJXTEWkUmLWfrWfFs+hkFSqvAJ19VeLoqDBoBA= Archived-At: Subject: Re: [Dots] Using SNI 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, 02 Jan 2018 09:40:07 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0B24_01D383AD.A8822A40 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Tiru, I agree that (indirectly through RFC7525 reference) SNI is mandated to be supported (but not necessarily has to be used). However, to guarantee interoperability between different DOTS vendors, I am saying that the use of SNI is a MUST - in particular for the data channel. Regards Jon From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of Konda, Tirumaleswar Reddy Sent: 02 January 2018 08:48 To: Jon Shallow; dots@ietf.org Subject: Re: [Dots] Using SNI Hi Jon, Both signal and data channel drafts refer to RFC7525 for secure use of (D)TLS and RFC7525 mandates TLS implementations to support SNI. I don't see the need to explicitly discuss SNI in these drafts. Regards, -Tiru From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Jon Shallow Sent: Saturday, December 30, 2017 4:57 PM To: dots@ietf.org Subject: [Dots] Using SNI Hi WG, When providing a DOTS server data channel service in my environment, this shares the same ip / port which also provides other services (e.g. GUI / REST server etc.). Even if the Root Discovery points to another IP and or port for the actual data channel activity, the TLS exchanges for the Root Discovery have to correctly work. I suspect that I am not the only DOTS vendor who will have this type of requirement of a single IP providing multiple TLS services. As DOTS requires mutual authentication, this is a different security requirement than required by the GUI environment (DOTS requires client cert to be presented, GUI does not and providing certificates to every GUI client is not a practical option). This can be handled by using SNI by using 2 different FQDNs and requiring the DOTS client to include the DOTS specific FQDN in the TLS Client Hello. Whether the GUI client does or does not (likely does with modern browsers) include a SNI FQDN when connecting to the non DOTS FQDN does not really matter - for DOTS it is recognizing the DOTS specific FQDN and setting up the TLS as appropriate. To make sure interoperability between DOTS vendors, I would like to see something like added to the data channel spec "DOTS clients MUST include the DOTS server FQDN in the TLS Client Hello packet by using Server Name Indication (SNI) RFC 3546". In addition, I think that this would be a good idea as well for the signal draft - thereby giving DOTS vendors the opportunity to host multiple DOTS servers (likely to be different security requirements for their different client) on a single IP / port. Thoughts / comments? Regards Jon ------=_NextPart_000_0B24_01D383AD.A8822A40 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Tiru,

 

I agree that (indirectly = through RFC7525 reference) SNI is mandated to be supported (but not = necessarily has to be used).

 

However, to guarantee = interoperability between different DOTS vendors, I am saying that the = use of SNI is a MUST – in particular for the data = channel.

 

Regards

 

Jon

 

From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of = Konda, Tirumaleswar Reddy
Sent: 02 January 2018 = 08:48
To: Jon Shallow; dots@ietf.org
Subject: Re: = [Dots] Using SNI

 

Hi = Jon,

 

Both signal and data channel drafts = refer to RFC7525 for secure use of (D)TLS and RFC7525 mandates TLS = implementations to support SNI. I don’t see the need to explicitly = discuss SNI in these drafts.


Regards,

-Tiru

 

From: Dots [mailto:dots-bounces@ietf.org] = On Behalf Of Jon Shallow
Sent: Saturday, December 30, = 2017 4:57 PM
To: dots@ietf.org
Subject: = [Dots] Using SNI

 

Hi WG,

 

When = providing a DOTS server data channel service in my environment, this = shares the same ip / port which also provides other services (e.g. GUI / = REST server etc.).  Even if the Root Discovery points to another IP = and or port for the actual data channel activity, the TLS exchanges for = the Root Discovery have to correctly work.  I suspect that I am not = the only DOTS vendor who will have this type of requirement of a single = IP providing multiple TLS services.

 

As DOTS = requires mutual authentication, this is a different security requirement = than required by the GUI environment (DOTS requires client cert to be = presented, GUI does not and providing certificates to every GUI client = is not a practical option).

 

This can be = handled by using SNI by using 2 different FQDNs and requiring the DOTS = client to include the DOTS specific FQDN in the TLS Client Hello.  = Whether the GUI client does or does not (likely does with modern = browsers) include a SNI FQDN when connecting to the non DOTS FQDN does = not really matter – for DOTS it is recognizing the DOTS specific = FQDN and setting up the TLS as appropriate.

 

To make sure = interoperability between DOTS vendors, I would like to see something = like added to the data channel spec “DOTS clients MUST include the = DOTS server FQDN in the TLS Client Hello packet by using Server Name = Indication (SNI) RFC 3546”.

 

In addition, = I think that this would be a good idea as well for the signal draft = – thereby giving DOTS vendors the opportunity to host multiple = DOTS servers (likely to be different security requirements for their = different client) on a single IP / port.

 

Thoughts / = comments?

 

Regards

 

Jon

------=_NextPart_000_0B24_01D383AD.A8822A40-- From nobody Tue Jan 2 01:43:31 2018 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 159151200B9 for ; Tue, 2 Jan 2018 01:43:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.01 X-Spam-Level: X-Spam-Status: No, score=-7.01 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, T_RP_MATCHES_RCVD=-0.01] 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 uHfwubWKNBTf for ; Tue, 2 Jan 2018 01:43:26 -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 CEA4B126DFF for ; Tue, 2 Jan 2018 01:43:23 -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=1514886202; 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:x-microsoft-antispam-message-info: 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=AHOIN8SwfImz5I8V4mY1zBD6dY8TBfH9mL3rBm F7uk4=; b=Ej3GJy/0spF6I8fgoDSSXEjjZgb48SK4CicW0nm1 CvTFnm1Qal7dxlAmeboBnFnaY7NUQZiMJ+aG5AIp8gmKYLTN6G OaM07Uc91n+cmRpezIy9E77PcuNawdjg0NNLL073W2jS4ejZ/T rPfHd6INTygMfqnEutX2Wa2XjrKTE8U= Received: from MIVEXAPP1N02.corpzone.internalzone.com (unknown [10.48.48.89]) by MIVWSMAILOUT1.mcafee.com with smtp (TLS: TLSv1/SSLv3,256bits,ECDHE-RSA-AES256-SHA384) id 390f_b66c_5db9f937_01ea_4903_95b7_5c42b5b92d74; Tue, 02 Jan 2018 03:43:21 -0600 Received: from MIVEXUSR1N03.corpzone.internalzone.com (10.48.48.83) by MIVEXAPP1N02.corpzone.internalzone.com (10.48.48.89) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Tue, 2 Jan 2018 04:43:20 -0500 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; Tue, 2 Jan 2018 04:43:19 -0500 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; Tue, 2 Jan 2018 04:43:19 -0500 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; Tue, 2 Jan 2018 04:43:17 -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.366.8; Tue, 2 Jan 2018 09:43: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.0366.009; Tue, 2 Jan 2018 09:43:17 +0000 From: "Konda, Tirumaleswar Reddy" To: Jon Shallow , "dots@ietf.org" Thread-Topic: [Dots] Signal CBOR / JSON Mapping Thread-Index: AdN7R9961HXkMq2tTZepG2+xKMly9QAclUqwARk68QAA4qNgAA== Date: Tue, 2 Jan 2018 09:43:16 +0000 Message-ID: References: <073001d37b47$e6f27460$b4d75d20$@jpshallow.com> <094a01d3801f$20d94dd0$628be970$@jpshallow.com> In-Reply-To: <094a01d3801f$20d94dd0$628be970$@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; 7:vPDxZoekvalKG4iAIHlItTZicNyIBcgSpnN6ep+e7uTaYUGjTiSuJAZCZ9tKXepvIbkCnRhf9Si6UN25SCWHqZjVcT5rjEDv5+7nkfqvsAWy8Nt4boIGDCEbuMJTLSdphIiU5GIhYIJBKtr/NJbWMnTDbxPaHr9b2/RWg2pPxQ0fZOgUGosGJL2nZqcpy8iAsOYSGnN+hhLgf2E+sPYvUTBFwbGCGnlr3U73xK8DbM3wqtqKWVLzBApeLyQWxF1d x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 4e02036d-df59-460c-5dbf-08d551c54048 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(5600026)(4604075)(3008032)(2017052603307)(7153060); SRVR:DM5PR16MB1787; x-ms-traffictypediagnostic: DM5PR16MB1787: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(278428928389397)(21748063052155)(123452027830198); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040470)(2401047)(5005006)(8121501046)(10201501046)(93006095)(93001095)(3231023)(944501075)(3002001)(6041268)(20161123558120)(20161123564045)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123562045)(6072148)(201708071742011); SRVR:DM5PR16MB1787; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:DM5PR16MB1787; x-forefront-prvs: 0540846A1D x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(376002)(346002)(39860400002)(39380400002)(396003)(366004)(189003)(199004)(32952001)(86362001)(2900100001)(8676002)(110136005)(2906002)(9686003)(25786009)(19609705001)(790700001)(3846002)(478600001)(6116002)(7736002)(72206003)(80792005)(2950100002)(77096006)(606006)(966005)(105586002)(33656002)(5660300001)(97736004)(106356001)(74316002)(14454004)(2501003)(6246003)(236005)(66066001)(229853002)(55016002)(68736007)(53946003)(6506007)(6436002)(53936002)(9326002)(3660700001)(81156014)(81166006)(99286004)(7696005)(53546011)(3280700002)(316002)(54896002)(6306002)(76176011)(102836004)(59450400001)(8936002)(21314002)(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) x-microsoft-antispam-message-info: vatSK2d0ydWNNS0/k9lZma8MzEwutyLaKDiZVk8z90Ls312SNdyvl+sW+AJLEUcDsq42e0ndzdrCsgYPfNO9TA== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_DM5PR16MB178877EB3866F7BE32152310EA190DM5PR16MB1788namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 4e02036d-df59-460c-5dbf-08d551c54048 X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Jan 2018 09:43:17.0278 (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 <6190> : inlines <6292> : streams <1774875> : uri <2561666> Archived-At: Subject: Re: [Dots] Signal CBOR / JSON Mapping 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, 02 Jan 2018 09:43:30 -0000 --_000_DM5PR16MB178877EB3866F7BE32152310EA190DM5PR16MB1788namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Jon, Please see inline From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Jon Shallow Sent: Friday, December 29, 2017 2:32 AM To: Konda, Tirumaleswar Reddy ; dots@ie= tf.org Subject: Re: [Dots] Signal CBOR / JSON Mapping Hi Tiru, Thanks for pointing me to these references. RFC7951 6.1. Numeric Types A value of the "int8", "int16", "int32", "uint8", "uint16", or "uint32" type is represented as a JSON number. A value of the "int64", "uint64", or "decimal64" type is represented as a JSON string whose content is the lexical representation of the corresponding YANG type as specified in Sections 9.2.1 and 9.3.1 of [RFC7950]. For example, if the type of the leaf "foo" in Section 5.1 was "uint64" instead of "uint8", the instance would have to be encoded as "foo": "123" -- So, we now have a way of handling int64/uint64 which should be used moving = forward. However, my JSON implementation (as well as many others I suspect) natively= supports decimal64, so does not necessarily need to display it as a lexica= l representation string. Do we follow RFC7951 here as well? [TR] Let's not deviate from RFC7951 otherwise both drafts will end-up defin= ing it's our own set of rules for encoding the YANG configuration data as J= SON/CBOR text deviating from the existing standards. I do not think that we should be following the augmented JSON parameter nam= ing in RFC7951 "4. Names and Namespaces" otherwise we will start ending up = with JSON/CBOR parameter names such as "ietf-dots-signal:mitigation-scope".= If we do go with this, then the CBOR mapping table will need to get exten= ded to cover the old, but some parameter name in different places. Comment= s? [TR] Both drafts should follow the naming in RFC7951. As we are working with YANG, JSON and CBOR interrelation , I still think we= need a table similar to below to aid implementers - referring as appropria= te to the different RFCs - no-one has full knowledge of all the evolving RF= Cs. [TR] I don't see the need to repeat, its already discussed in detail in htt= ps://tools.ietf.org/html/rfc8040#section-5.2 and similarly DOTS signal chan= nel draft already refers to draft-ietf-core-yang-cbor-05. -Tiru Regards Jon From: Dots [mailto: dots-bounces@ietf.org] On= Behalf Of Konda, Tirumaleswar Reddy Sent: 23 December 2017 07:06 To: Jon Shallow; dots@ietf.org Subject: Re: [Dots] Signal CBOR / JSON Mapping We should just follow the CBOR Encoding of Data Modeled with YANG defined i= n https://tools.ietf.org/html/draft-ietf-core-yang-cbor-05 and JSON Encodin= g of Data Modeled with YANG defined in https://tools.ietf.org/html/rfc7951. -Tiru From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Jon Shallow Sent: Friday, December 22, 2017 10:41 PM To: dots@ietf.org Subject: [Dots] Signal CBOR / JSON Mapping Hi WG, There are a lot of YANG parameters that we are using that are defined as in= t64. JSON only safely supports up to 53 bits of precision. RFC 7493 2.2 Numbers An I-JSON sender cannot expect a receiver to treat an integer whose absolute value is greater than 9007199254740991 (i.e., that is outside the range [-(2**53)+1, (2**53)-1]) as an exact value. For applications that require the exact interchange of numbers with greater magnitude or precision, it is RECOMMENDED to encode them in JSON string values. This requires that the receiving program understand the intended semantic of the value. An example would be 64-bit integers, even though modern hardware can deal with them, because of the limited scope of JavaScript numbers. RFC7049 3.6 Numbers CBOR-based protocols should take into account that different language environments pose different restrictions on the range and precision of numbers that are representable. For example, the JavaScript number system treats all numbers as floating point, which may result in silent loss of precision in decoding integers with more than 53 significant bits. A protocol that uses numbers should define its expectations on the handling of non-trivial numbers in decoders and receiving applications. =3D=3D=3D=3D An option is to make all of these int64 decimal64 for the signal channel, b= ut that does not cover the 64 bit counters in the netmod-acl. However, as = the netmod-acl counters are also fed back via the mitigate status, we do no= t necessarily need to support the netmod-acl counters. If, however, we follow RFC 7493, in CBOR the data can be passed across as 6= 4 bits, and as the parameter is a CBOR mapping, we can know how to encode /= decode the JSON value as appropriate. However, RFC 7493 does not say whet= her this should be base64, base64url or numeric string representation (i.e.= "1234567890"). RFC7049 refers to bignum (major type 6, tag value 2 or 3) = should be encoded as base64url (4.1 Converting from CBOR to JSON) - but int= 64 can be held in CBOR as type 0 or 1. I prefer the numeric string representation as it is humanly easy to read an= d easy to convert into 64 bit integers. If we take this approach of using the parameter which is a CBOR mapping key= to key off how to encode / decode the JSON, I would suggest that we could = extend this to include IP addresses, Dates and client-identifiers (or their= possible new names of request-nonce and client-domain-hash) to further min= imize the actual number of bytes sent in a COAP packet. The CBOR mapping Table could then be extended to look something like (but i= t is too wide I think) /----------------------+-------------+------+---------------+--------+-----= ----\ | Parameter name | YANG type | CBOR | CBOR major | JSON | JSON= | | | | key | type | type | Exam= ple | |----------------------+-------------+------+---------------+--------+-----= ----| | mitigation-scope | grouping | 1 | 5 map | Object | = | | scope | list | 2 | 4 array | Array | = | | mitigation-id | int32 | 3 | 0 unsigned | Number | 5432= 1 | | acl-list | list | 4 | 4 array | Array | = | | target-port-range | list | 5 | 4 array | Array | = | | lower-port | port-number | 6 | 0 number | Number | 1111= | | upper-port | port-number | 7 | 0 number | Number | 1111= | | target-protocol | leaf-list | | 4 array | Array | = | | | uint8 | 8 | 0 number | Number | 6 = | | target-fqdn | leaf-list | | 4 array | Array | = | | | domain-name | 9 | 3 text string | String | "a.c= om" | | target-uri | leaf-list | | 4 array | Array | = | | | uri | 10 | 3 text string | String | = | | alias-name | leaf-list | | 4 array | Array | = | | | string | 11 | 3 text string | String | "web= " | | lifetime | int32 | 12 | 0 number | Number | = | | attack-status | enumeration | 13 | 0 number | Number | 1 = | | signal-config | grouping | 14 | 5 map | Object | = | | heartbeat-interval | grouping | 15 | 5 map | Object | = | | max-retransmit | grouping | 16 | 5 map | Object | = | | ack-timeout | grouping | 17 | 5 map | Object | = | | ack-random-factor | grouping | 18 | 5 map | Object | = | | min-value | int16 | 19 | 0 number | Number | 1 = | | max-value | int16 | 20 | 0 number | Number | 1 = | | status | enumeration | 21 | 0 number | Number | 1 = | | conflict-information | grouping | 22 | 5 map | Object | = | | conflict-status | enumeration | 23 | 0 number | Number | 1 = | | conflict-cause | enumeration | 24 | 0 number | Number | 1 = | | retry-timer | int32 | 25 | 0 number | Number | 1800= | | bytes-dropped | counter64 | 26 | 0 number | String | "123= 4" | | bps-dropped | counter64 | 27 | 0 number | String | "123= 4" | | pkts-dropped | counter64 | 28 | 0 number | String | "123= 4" | | pps-dropped | counter64 | 29 | 0 number | String | "123= 4" | | session-id | int32 | 30 | 0 number | Number | 6543= 2 | | trigger-mitigation | boolean | 31 | 7 simple | T / F | = | | missing-hb-allowed | grouping | 32 | 5 map | Object | = | | current-value | int16 | 33 | 0 number | Number | 10 = | | mitigation-start | decimal64 | 34 | 7 FP | Number | 10.2= 1 | | target-prefix | leaf-list | | 4 array | Array | = | | | ip-prefix | 35 | 3 text string | String | = | | client-domain-hash | leaf-list | | 4 array | Array | = | | | binary | 36 | 2 byte string | String | "abc= df" | | alt-server | string | 37 | 3 text string | String | = | | alt-server-record | list | 38 | 4 array | Array | = | | addr | string | 39 | 3 text string | String | = | | ttl | int32 | 40 | 0 number | Number | 1800= | | conflict-scope | grouping | 41 | 5 map | Object | = | | acl-name | string | 42 | 3 text string | String | "ana= me" | | acl-type | string | 43 | 3 text string | String | "ipv= 4" | | config-interval | int32 | 44 | 0 number | Number | 11 = | | mitigating-config | grouping | 45 | 5 map | Object | = | | idle-config | grouping | 46 | 5 map | Object | = | | request-nonce | binary | 47 | 2 byte string | String | "xxx= " | | min-value-decimal | decimal64 | 48 | 7 FP | Number | 1.1 = | | max-value-decimal | decimal64 | 49 | 7 FP | Number | 1.1 = | | current-value-decimal| decimal64 | 50 | 7 FP | Number | 1.1 = | \----------------------+-------------+------+---------------+--------+-----= ----/ Comments / suggestions? Regards Jon --_000_DM5PR16MB178877EB3866F7BE32152310EA190DM5PR16MB1788namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Jon,

&nbs= p;

Please se= e inline

 

From:<= /span> Dots [mailto:dots-bou= nces@ietf.org] On Behalf Of Jon Shallow
Sent: Friday, December 29, 2017 2:32 AM
To: Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@McAfee.com= >; dots@ietf.org
Subject: Re: [Dots] Signal CBOR / JSON Mapping

 

Hi Tiru= ,

&n= bsp;

Thanks = for pointing me to these references.

&n= bsp;

RFC7951=

6.1.&nb= sp; Numeric Types

&n= bsp;

 &= nbsp; A value of the "int8", "int16", "int32"= , "uint8", "uint16", or

 &= nbsp; "uint32" type is represented as a JSON number.

&n= bsp;

 &= nbsp; A value of the "int64", "uint64", or "decima= l64" type is represented

 &= nbsp; as a JSON string whose content is the lexical representation of the

 &= nbsp; corresponding YANG type as specified in Sections 9.2.1 and 9.3.1 of

 &= nbsp; [RFC7950].

&n= bsp;

 &= nbsp; For example, if the type of the leaf "foo" in Section 5.1 w= as

 &= nbsp; "uint64" instead of "uint8", the instance would h= ave to be encoded as

&n= bsp;

 &= nbsp; "foo": "123"

--=

&n= bsp;

So, we = now have a way of handling int64/uint64 which should be used moving forward= .

&n= bsp;

However= , my JSON implementation (as well as many others I suspect) natively suppor= ts decimal64, so does not necessarily need to display it as a lexical repre= sentation string.  Do we follow RFC7951 here as well?

 

[TR] Let’s not deviate fr= om RFC7951 otherwise both drafts will end-up defining it’s our own se= t of rules for encoding the YANG configuration data as JSON/CBOR text devia= ting from the existing standards.

&n= bsp;

I do no= t think that we should be following the augmented JSON parameter naming in = RFC7951 “4. Names and Namespaces” otherwise we will start endin= g up with JSON/CBOR parameter names such as “ietf-dots-signal:mitigat= ion-scope”.  If we do go with this, then the CBOR mapping table will need to get extend= ed to cover the old, but some parameter name in different places.  Com= ments?

 

[TR] Both drafts should follow = the naming in RFC7951.

&n= bsp;

As we a= re working with YANG, JSON and CBOR interrelation , I still think we need a= table similar to below to aid implementers – referring as appropriat= e to the different RFCs – no-one has full knowledge of all the evolving RFCs.

 

[TR] I don’t see the need= to repeat, its already discussed in detail in https://tools.i= etf.org/html/rfc8040#section-5.2 and similarly DOTS signal channel draf= t already refers to draft-ietf-core-yang-cbor-05.

 

-Tiru

Regards=

&n= bsp;

Jon

&n= bsp;

From: Dots [mailto: dots-bounces@ietf.org] On B= ehalf Of Konda, Tirumaleswar Reddy
Sent: 23 December 2017 07:06
To: Jon Shallow; dots@ietf.org<= br> Subject: Re: [Dots] Signal CBOR / JSON Mapping

 

We should= just follow the CBOR Encoding of Data Modeled with YANG defined in https:= //tools.ietf.org/html/draft-ietf-core-yang-cbor-05 and JSON Encoding of= Data Modeled with YANG

defined i= n https://tools.ietf.org/html/rfc7951.

&nbs= p;

-Tiru

&nbs= p;

From:<= /span> Dots [mailto:dots-bounces@ietf.org] On Behalf Of Jon Shallow
Sent: Friday, December 22, 2017 10:41 PM
To: dots@ietf.org
Subject: [Dots] Signal CBOR / JSON Mapping

 

Hi WG,

 

There are a lot of YANG paramet= ers that we are using that are defined as int64.  JSON only safely sup= ports up to 53 bits of precision.

 

RFC 7493 2.2 Numbers=

 

   An I-JSON sender c= annot expect a receiver to treat an integer whose

   absolute value is = greater than 9007199254740991 (i.e., that is

   outside the range = [-(2**53)+1, (2**53)-1]) as an exact value.

 

   For applications t= hat require the exact interchange of numbers with

   greater magnitude = or precision, it is RECOMMENDED to encode them in

   JSON string values= .  This requires that the receiving program

   understand the int= ended semantic of the value.  An example would be

   64-bit integers, e= ven though modern hardware can deal with them,

   because of the lim= ited scope of JavaScript numbers.

 

RFC7049 3.6 Numbers<= /span>

 

   CBOR-based protoco= ls should take into account that different language

   environments pose = different restrictions on the range and precision

   of numbers that ar= e representable.  For example, the JavaScript

   number system trea= ts all numbers as floating point, which may result

   in silent loss of = precision in decoding integers with more than 53

   significant bits.&= nbsp; A protocol that uses numbers should define its

   expectations on th= e handling of non-trivial numbers in decoders and

   receiving applicat= ions.

 

=3D=3D=3D=3D<= /p>

 

An option is to make all of the= se int64 decimal64 for the signal channel, but that does not cover the 64 b= it counters in the netmod-acl.  However, as the netmod-acl counters ar= e also fed back via the mitigate status, we do not necessarily need to support the netmod-acl counters.<= /span>

 

If, however, we follow RFC 7493= , in CBOR the data can be passed across as 64 bits, and as the parameter is= a CBOR mapping, we can know how to encode / decode the JSON value as appro= priate.  However, RFC 7493 does not say whether this should be base64, base64url or numeric string representat= ion (i.e. “1234567890”).  RFC7049 refers to bignum (major = type 6, tag value 2 or 3) should be encoded as base64url (4.1 Converting fr= om CBOR to JSON) – but int64 can be held in CBOR as type 0 or 1.

 

I prefer the numeric string rep= resentation as it is humanly easy to read and easy to convert into 64 bit i= ntegers.

 

If we take this approach of usi= ng the parameter which is a CBOR mapping key to key off how to encode / dec= ode the JSON, I would suggest that we could extend this to include IP addre= sses, Dates and client-identifiers (or their possible new names of request-nonce and client-domain-hash) to furth= er minimize the actual number of bytes sent in a COAP packet.

 

The CBOR mapping Table could th= en be extended to look something like (but it is too wide I think)

 

/----------------------+-------------= 3;------+---------------+--------+---------\<= /p>

| Parameter name    &nbs= p;  | YANG type   | CBOR | CBOR major    | JS= ON   | JSON    | 

|       &= nbsp;           &nbs= p;  |           = ;  | key  | type        &= nbsp; | type   | Example |

|----------------------+-------------= 3;------+---------------+--------+---------|<= /p>

| mitigation-scope     |= grouping    |   1  | 5 map   =       | Object |     &nbs= p;   | 

| scope      &= nbsp;         | list  &nb= sp;     |   2  | 4 array  &nbs= p;    | Array  |      &nb= sp;  | 

| mitigation-id     = ;   | int32       |   3&n= bsp; | 0 unsigned    | Number | 54321   | 

| acl-list     &nbs= p;       | list     =    |   4  | 4 array     &= nbsp; | Array  |         |&nbs= p;

| target-port-range    | list=         |   5  | 4 array&= nbsp;      | Array  |    =      | 

| lower-port     &n= bsp;     | port-number |   6  | 0 number=       | Number | 1111    | 

| upper-port     &n= bsp;     | port-number |   7  | 0 number=       | Number | 1111    | 

| target-protocol    &nb= sp; | leaf-list   |      | 4 array =       | Array  |     = ;    | 

|       &= nbsp;           &nbs= p;  | uint8       |   8  = | 0 number      | Number | 6   &nbs= p;   |

| target-fqdn     &= nbsp;    | leaf-list   |    &n= bsp; | 4 array       | Array  | &nb= sp;       |

|       &= nbsp;           &nbs= p;  | domain-name |   9  | 3 text string | String | &qu= ot;a.com" |

| target-uri     &n= bsp;     | leaf-list   |    &n= bsp; | 4 array       | Array  |&nbs= p;        | 

|       &= nbsp;           &nbs= p;  | uri         |  10&n= bsp; | 3 text string | String |       &n= bsp; |

| alias-name     &n= bsp;     | leaf-list   |    &n= bsp; | 4 array       | Array  | &nb= sp;       | 

|        =             &nb= sp; | string      |  11  | 3 text s= tring | String | "web"   | 

| lifetime     &nbs= p;       | int32     = ;  |  12  | 0 number      | Number = |         | 

| attack-status     = ;   | enumeration |  13  | 0 number   &n= bsp;  | Number | 1       | 

| signal-config     = ;   | grouping    |  14  | 5 map &n= bsp;       | Object |    =      | 

| heartbeat-interval   | grouping&= nbsp;   |  15  | 5 map     &nb= sp;   | Object |         = | 

| max-retransmit    &nbs= p;  | grouping    |  16  | 5 map  &= nbsp;      | Object |     = ;    | 

| ack-timeout     &= nbsp;    | grouping    |  17  | 5 m= ap         | Object |  &n= bsp;      | 

| ack-random-factor    | grou= ping    |  18  | 5 map    &nbs= p;    | Object |       &n= bsp; | 

| min-value      &n= bsp;     | int16     &nbs= p; |  19  | 0 number      | Number | 1&n= bsp;      | 

| max-value     &nb= sp;      | int16     &nbs= p; |  20  | 0 number      | Number | 1&n= bsp;      | 

| status      =          | enumeration |  21&n= bsp; | 0 number      | Number | 1   = ;    | 

| conflict-information | grouping  = ;  |  22  | 5 map       &= nbsp; | Object |         | 

| conflict-status    &nb= sp; | enumeration |  23  | 0 number     = | Number | 1       | 

| conflict-cause    &nbs= p;  | enumeration |  24  | 0 number    &= nbsp; | Number | 1       | 

| retry-timer     &= nbsp;    | int32       | = 25  | 0 number      | Number | 1800 &nb= sp;  | 

| bytes-dropped     = ;   | counter64   |  26  | 0 number &nbs= p;    | String | "1234"  | 

| bps-dropped     &= nbsp;    | counter64   |  27  | 0 number=       | String | "1234"  | 

| pkts-dropped     =     | counter64   |  28  | 0 number = ;     | String | "1234"  | 

| pps-dropped     &= nbsp;    | counter64   |  29  | 0 number=       | String | "1234"  | 

| session-id     &n= bsp;     | int32       |&= nbsp; 30  | 0 number      | Number | 65432&nb= sp;  | 

| trigger-mitigation   | boolean&n= bsp;    |  31  | 7 simple    &= nbsp; | T / F  |         |&nbs= p;

| missing-hb-allowed   | grouping&= nbsp;   |  32  | 5 map     &nb= sp;   | Object |         = | 

| current-value     = ;   | int16       |  33  = | 0 number      | Number | 10   &nb= sp;  | 

| mitigation-start     |= decimal64   |  34  | 7 FP     = ;     | Number | 10.21   | 

| target-prefix     = ;   | leaf-list   |      | 4 a= rray       | Array  |   &= nbsp;     | 

|        =             &nb= sp; | ip-prefix   |  35  | 3 text string | String = |         | 

| client-domain-hash   | leaf-list=    |      | 4 array   &nb= sp;   | Array  |       &n= bsp; |

|        =             &nb= sp; | binary      |  36  | 2 byte s= tring | String | "abcdf" |

| alt-server     &n= bsp;     | string      | = 37  | 3 text string | String |      &nb= sp;  | 

| alt-server-record    | list=         |  38  | 4 array =       | Array  |     = ;    | 

| addr      &n= bsp;          | string &n= bsp;    |  39  | 3 text string | String | &nb= sp;       | 

| ttl      &nb= sp;           | int32&nbs= p;      |  40  | 0 number  &nb= sp;   | Number | 1800    | 

| conflict-scope    &nbs= p;  | grouping    |  41  | 5 map  &= nbsp;      | Object |     = ;    | 

| acl-name     &nbs= p;       | string    &nbs= p; |  42  | 3 text string | String | "aname" | 

| acl-type     &nbs= p;       | string    &nbs= p; |  43  | 3 text string | String | "ipv4"  |&nbs= p;

| config-interval    &nb= sp; | int32       |  44  | 0 number=       | Number | 11      = | 

| mitigating-config    | grou= ping    |  45  | 5 map    &nbs= p;    | Object |       &n= bsp; | 

| idle-config     &= nbsp;    | grouping    |  46  | 5 m= ap         | Object |  &n= bsp;      | 

| request-nonce     = ;   | binary      |  47  | 2 b= yte string | String | "xxx"   | 

| min-value-decimal    | deci= mal64   |  48  | 7 FP     &nbs= p;    | Number | 1.1     | 

| max-value-decimal    | deci= mal64   |  49  | 7 FP     &nbs= p;    | Number | 1.1     | 

| current-value-decimal| decimal64 &nbs= p; |  50  | 7 FP        &= nbsp; | Number | 1.1     | 

\----------------------+-------------= 3;------+---------------+--------+---------/<= /p>

 

 

Comments / suggestions?

 

Regards

 

Jon

--_000_DM5PR16MB178877EB3866F7BE32152310EA190DM5PR16MB1788namp_-- From nobody Tue Jan 2 01:55:11 2018 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 443C9126DCA for ; Tue, 2 Jan 2018 01:55:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.33 X-Spam-Level: X-Spam-Status: No, score=-4.33 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, T_RP_MATCHES_RCVD=-0.01] 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 fc_4E7MwAE94 for ; Tue, 2 Jan 2018 01:55:06 -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 796781200B9 for ; Tue, 2 Jan 2018 01:55:06 -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=1514886898; 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: x-microsoft-antispam-message-info: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=u 7oRYcw+qKX393yygM8zEZWLeP841cXrzxLi3oigDE s=; b=qWQq2cJqucFP5uY8vJoyImDLVJa7yh/YUD5SJXDef2lY 3u4KS7Sr9J5Z3v+pgi4ikMOXt36G4vtQiD00PcRO6nh+QfwluN NX993+BRG/LfUjrF5EIjExR+7uDJ3TAXZogvXdw6btDxqCpvj7 i1rsGdrKw3VoJBCobMK7/PF3vr0= Received: from DNVEXAPP1N05.corpzone.internalzone.com (unknown [10.44.48.89]) by DNVWSMAILOUT1.mcafee.com with smtp (TLS: TLSv1/SSLv3,256bits,ECDHE-RSA-AES256-SHA384) id 49c8_312c_3154c190_6e0a_4aab_afb7_e5c8c1fd3949; Tue, 02 Jan 2018 03:54:57 -0600 Received: from DNVEXUSR1N08.corpzone.internalzone.com (10.44.48.81) by DNVEXAPP1N05.corpzone.internalzone.com (10.44.48.89) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Tue, 2 Jan 2018 02:54:43 -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; Tue, 2 Jan 2018 02:54:43 -0700 Received: from NAM03-DM3-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; Tue, 2 Jan 2018 02:54:42 -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.366.8; Tue, 2 Jan 2018 09:54: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.0366.009; Tue, 2 Jan 2018 09:54:41 +0000 From: "Konda, Tirumaleswar Reddy" To: Jon Shallow , "dots@ietf.org" Thread-Topic: [Dots] Using SNI Thread-Index: AdOBYSmGAk9KbyE4TFyYKC/j9TeHqgCRKPHwAAH2wAAAAHaCkA== Date: Tue, 2 Jan 2018 09:54:41 +0000 Message-ID: References: <0a1201d38161$299ef350$7cdcd9f0$@jpshallow.com> <0b2301d383ad$a8822a40$f9867ec0$@jpshallow.com> In-Reply-To: <0b2301d383ad$a8822a40$f9867ec0$@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; 7:cHhfLa0VK6Nxrp5CbO+JNPCwIB5DdTx4+yBfI45PhSaiHv5ZsjUUdwGkEab42CYC2eFhEzYlkREreZzZ/GMIoBvMeejqGK40JBg5nJ/KzakPAcqKJ32Lhh4+8CrOXbUwCZUEEIcJphWp0jBv9Lj+tFLBMtGbnTAQecMJN492/j5DTrxXHpLaAuoKFmZ8cHLIwlV9lyql3LPlwaaq0lau0vZGuNxrAMR5HASiXngw38gfHtyRE9Izea4Jocb/FW1W x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 19e92641-0179-4f82-35d3-08d551c6d818 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(5600026)(4604075)(3008032)(2017052603307)(7153060); SRVR:DM5PR16MB1788; x-ms-traffictypediagnostic: DM5PR16MB1788: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(192374486261705)(21748063052155)(123452027830198); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040470)(2401047)(8121501046)(5005006)(3002001)(3231023)(944501075)(93006095)(93001095)(10201501046)(6041268)(20161123562045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(20161123564045)(20161123558120)(6072148)(201708071742011); SRVR:DM5PR16MB1788; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:DM5PR16MB1788; x-forefront-prvs: 0540846A1D x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39380400002)(376002)(396003)(39860400002)(366004)(346002)(32952001)(51444003)(189003)(199004)(102836004)(53936002)(97736004)(2906002)(6506007)(14454004)(229853002)(81166006)(81156014)(59450400001)(80792005)(68736007)(99286004)(6436002)(25786009)(8676002)(55016002)(77096006)(53546011)(33656002)(6246003)(7696005)(76176011)(5660300001)(74316002)(8936002)(3846002)(790700001)(86362001)(72206003)(236005)(478600001)(6306002)(54896002)(2950100002)(9686003)(6116002)(9326002)(3660700001)(2501003)(105586002)(66066001)(106356001)(2900100001)(7736002)(316002)(110136005)(3280700002)(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; x-microsoft-antispam-message-info: plFNihu9utSRh7/PwWLRwD0YkJNjII9LOslhd3p9OW5uMl5lJdIz5TkSmW+nM2cMllEKT4M3tti54L8WllceZA== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_DM5PR16MB1788B90200439A2BA9909F9EEA190DM5PR16MB1788namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 19e92641-0179-4f82-35d3-08d551c6d818 X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Jan 2018 09:54:41.2539 (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 <6190> : inlines <6292> : streams <1774876> : uri <2561671> Archived-At: Subject: Re: [Dots] Using SNI 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, 02 Jan 2018 09:55:09 -0000 --_000_DM5PR16MB1788B90200439A2BA9909F9EEA190DM5PR16MB1788namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Jon, RESTCONF does not mandate client authentication based on TLS client certifi= cate, we can say the following instead: If TLS client certificate is used to authenticate the DOTS client, the DOTS= client MUST include the DOTS server FQDN in server name indication extensi= on (Section 3 of RFC6066). Cheers, -Tiru From: Jon Shallow [mailto:supjps-ietf@jpshallow.com] Sent: Tuesday, January 2, 2018 3:10 PM To: Konda, Tirumaleswar Reddy ; dots@ie= tf.org Subject: RE: [Dots] Using SNI Hi Tiru, I agree that (indirectly through RFC7525 reference) SNI is mandated to be s= upported (but not necessarily has to be used). However, to guarantee interoperability between different DOTS vendors, I am= saying that the use of SNI is a MUST - in particular for the data channel. Regards Jon From: Dots [mailto: dots-bounces@ietf.org] On= Behalf Of Konda, Tirumaleswar Reddy Sent: 02 January 2018 08:48 To: Jon Shallow; dots@ietf.org Subject: Re: [Dots] Using SNI Hi Jon, Both signal and data channel drafts refer to RFC7525 for secure use of (D)T= LS and RFC7525 mandates TLS implementations to support SNI. I don't see the= need to explicitly discuss SNI in these drafts. Regards, -Tiru From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Jon Shallow Sent: Saturday, December 30, 2017 4:57 PM To: dots@ietf.org Subject: [Dots] Using SNI Hi WG, When providing a DOTS server data channel service in my environment, this s= hares the same ip / port which also provides other services (e.g. GUI / RES= T server etc.). Even if the Root Discovery points to another IP and or por= t for the actual data channel activity, the TLS exchanges for the Root Disc= overy have to correctly work. I suspect that I am not the only DOTS vendor= who will have this type of requirement of a single IP providing multiple T= LS services. As DOTS requires mutual authentication, this is a different security requir= ement than required by the GUI environment (DOTS requires client cert to be= presented, GUI does not and providing certificates to every GUI client is = not a practical option). This can be handled by using SNI by using 2 different FQDNs and requiring t= he DOTS client to include the DOTS specific FQDN in the TLS Client Hello. = Whether the GUI client does or does not (likely does with modern browsers) = include a SNI FQDN when connecting to the non DOTS FQDN does not really mat= ter - for DOTS it is recognizing the DOTS specific FQDN and setting up the = TLS as appropriate. To make sure interoperability between DOTS vendors, I would like to see som= ething like added to the data channel spec "DOTS clients MUST include the D= OTS server FQDN in the TLS Client Hello packet by using Server Name Indicat= ion (SNI) RFC 3546". In addition, I think that this would be a good idea as well for the signal = draft - thereby giving DOTS vendors the opportunity to host multiple DOTS s= ervers (likely to be different security requirements for their different cl= ient) on a single IP / port. Thoughts / comments? Regards Jon --_000_DM5PR16MB1788B90200439A2BA9909F9EEA190DM5PR16MB1788namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 
Hi Jon,
 
RESTCONF does not mandate client authentication based on TLS client c=
ertificate, we can say the following instead:
If TLS client certificate is used to authenticate the DOTS client, th=
e DOTS client MUST include the DOTS server FQDN in server name indication e=
xtension (Section 3 of RFC6066).
 
Cheers,
-Tiru
 =

From:<= /span> Jon Shallow [mailto:s= upjps-ietf@jpshallow.com]
Sent: Tuesday, January 2, 2018 3:10 PM
To: Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@McAfee.com= >; dots@ietf.org
Subject: RE: [Dots] Using SNI

 

Hi Tiru= ,

&n= bsp;

I agree= that (indirectly through RFC7525 reference) SNI is mandated to be supporte= d (but not necessarily has to be used).

&n= bsp;

However= , to guarantee interoperability between different DOTS vendors, I am saying= that the use of SNI is a MUST – in particular for the data channel.<= o:p>

&n= bsp;

Regards=

&n= bsp;

Jon

&n= bsp;

From: Dots [mailto: dots-bounces@ietf.org] On B= ehalf Of Konda, Tirumaleswar Reddy
Sent: 02 January 2018 08:48
To: Jon Shallow; dots@ietf.org<= br> Subject: Re: [Dots] Using SNI

 

Hi Jon,

&nbs= p;

Both sign= al and data channel drafts refer to RFC7525 for secure use of (D)TLS and RF= C7525 mandates TLS implementations to support SNI. I don’t see the ne= ed to explicitly discuss SNI in these drafts.


Regards,

-Tiru

&nbs= p;

From:<= /span> Dots [mailto:dots-bounces@ietf.org] On Behalf Of Jon Shallow
Sent: Saturday, December 30, 2017 4:57 PM
To: dots@ietf.org
Subject: [Dots] Using SNI

 

Hi WG,

 

When providing a DOTS server da= ta channel service in my environment, this shares the same ip / port which = also provides other services (e.g. GUI / REST server etc.).  Even if t= he Root Discovery points to another IP and or port for the actual data channel activity, the TLS exchanges for the Ro= ot Discovery have to correctly work.  I suspect that I am not the only= DOTS vendor who will have this type of requirement of a single IP providin= g multiple TLS services.

 

As DOTS requires mutual authent= ication, this is a different security requirement than required by the GUI = environment (DOTS requires client cert to be presented, GUI does not and pr= oviding certificates to every GUI client is not a practical option).

 

This can be handled by using SN= I by using 2 different FQDNs and requiring the DOTS client to include the D= OTS specific FQDN in the TLS Client Hello.  Whether the GUI client doe= s or does not (likely does with modern browsers) include a SNI FQDN when connecting to the non DOTS FQDN does not really ma= tter – for DOTS it is recognizing the DOTS specific FQDN and setting = up the TLS as appropriate.

 

To make sure interoperability b= etween DOTS vendors, I would like to see something like added to the data c= hannel spec “DOTS clients MUST include the DOTS server FQDN in the TL= S Client Hello packet by using Server Name Indication (SNI) RFC 3546”.

 

In addition, I think that this = would be a good idea as well for the signal draft – thereby giving DO= TS vendors the opportunity to host multiple DOTS servers (likely to be diff= erent security requirements for their different client) on a single IP / port.

 

Thoughts / comments?=

 

Regards

 

Jon

--_000_DM5PR16MB1788B90200439A2BA9909F9EEA190DM5PR16MB1788namp_-- From nobody Tue Jan 2 02:00:24 2018 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 1F1F6126DCA for ; Tue, 2 Jan 2018 02:00:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 LJhgyY-8GWDj for ; Tue, 2 Jan 2018 02:00:06 -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 385171200B9 for ; Tue, 2 Jan 2018 02:00:06 -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 1eWJMa-0006gZ-Nj; Tue, 02 Jan 2018 10:00:04 +0000 From: "Jon Shallow" To: "'Konda, Tirumaleswar Reddy'" , References: <0a1201d38161$299ef350$7cdcd9f0$@jpshallow.com> <0b2301d383ad$a8822a40$f9867ec0$@jpshallow.com> In-Reply-To: Date: Tue, 2 Jan 2018 10:00:03 -0000 Message-ID: <0b4b01d383b0$758f1370$60ad3a50$@jpshallow.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0B4C_01D383B0.75915D60" X-Mailer: Microsoft Outlook 14.0 Content-Language: en-gb Thread-Index: AQIpdHJXTEWkUmLWfrWfFs+hkFSqvAJ19VeLAlAhTlAB/1BuRaJ+TKmg Archived-At: Subject: Re: [Dots] Using SNI 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, 02 Jan 2018 10:00:23 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0B4C_01D383B0.75915D60 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Tiru, That certainly works for me - thanks Regards Jon From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of Konda, Tirumaleswar Reddy Sent: 02 January 2018 09:55 To: Jon Shallow; dots@ietf.org Subject: Re: [Dots] Using SNI Hi Jon, RESTCONF does not mandate client authentication based on TLS client certificate, we can say the following instead: If TLS client certificate is used to authenticate the DOTS client, the DOTS client MUST include the DOTS server FQDN in server name indication extension (Section 3 of RFC6066). Cheers, -Tiru From: Jon Shallow [mailto:supjps-ietf@jpshallow.com] Sent: Tuesday, January 2, 2018 3:10 PM To: Konda, Tirumaleswar Reddy ; dots@ietf.org Subject: RE: [Dots] Using SNI Hi Tiru, I agree that (indirectly through RFC7525 reference) SNI is mandated to be supported (but not necessarily has to be used). However, to guarantee interoperability between different DOTS vendors, I am saying that the use of SNI is a MUST - in particular for the data channel. Regards Jon From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of Konda, Tirumaleswar Reddy Sent: 02 January 2018 08:48 To: Jon Shallow; dots@ietf.org Subject: Re: [Dots] Using SNI Hi Jon, Both signal and data channel drafts refer to RFC7525 for secure use of (D)TLS and RFC7525 mandates TLS implementations to support SNI. I don't see the need to explicitly discuss SNI in these drafts. Regards, -Tiru From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Jon Shallow Sent: Saturday, December 30, 2017 4:57 PM To: dots@ietf.org Subject: [Dots] Using SNI Hi WG, When providing a DOTS server data channel service in my environment, this shares the same ip / port which also provides other services (e.g. GUI / REST server etc.). Even if the Root Discovery points to another IP and or port for the actual data channel activity, the TLS exchanges for the Root Discovery have to correctly work. I suspect that I am not the only DOTS vendor who will have this type of requirement of a single IP providing multiple TLS services. As DOTS requires mutual authentication, this is a different security requirement than required by the GUI environment (DOTS requires client cert to be presented, GUI does not and providing certificates to every GUI client is not a practical option). This can be handled by using SNI by using 2 different FQDNs and requiring the DOTS client to include the DOTS specific FQDN in the TLS Client Hello. Whether the GUI client does or does not (likely does with modern browsers) include a SNI FQDN when connecting to the non DOTS FQDN does not really matter - for DOTS it is recognizing the DOTS specific FQDN and setting up the TLS as appropriate. To make sure interoperability between DOTS vendors, I would like to see something like added to the data channel spec "DOTS clients MUST include the DOTS server FQDN in the TLS Client Hello packet by using Server Name Indication (SNI) RFC 3546". In addition, I think that this would be a good idea as well for the signal draft - thereby giving DOTS vendors the opportunity to host multiple DOTS servers (likely to be different security requirements for their different client) on a single IP / port. Thoughts / comments? Regards Jon ------=_NextPart_000_0B4C_01D383B0.75915D60 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Tiru,

 

That certainly works for = me – thanks

 

Regards

 

Jon

 

From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of = Konda, Tirumaleswar Reddy
Sent: 02 January 2018 = 09:55
To: Jon Shallow; dots@ietf.org
Subject: Re: = [Dots] Using SNI

 

Hi =
Jon,
 =

RESTCONF =
does not mandate client authentication based on TLS client certificate, =
we can say the following instead:
If TLS =
client certificate is used to authenticate the DOTS client, the DOTS =
client MUST include the DOTS server FQDN in server name indication =
extension (Section 3 of RFC6066).
 =

Cheers,
-Tiru
 =

From: Jon Shallow [mailto:supjps-ietf@jpshallow.co= m]
Sent: Tuesday, January 2, 2018 3:10 PM
To: = Konda, Tirumaleswar Reddy <TirumaleswarReddy_Kond= a@McAfee.com>; dots@ietf.org
Subject: RE: = [Dots] Using SNI

 

Hi = Tiru,

 

I agree that (indirectly = through RFC7525 reference) SNI is mandated to be supported (but not = necessarily has to be used).

 

However, to guarantee = interoperability between different DOTS vendors, I am saying that the = use of SNI is a MUST – in particular for the data = channel.

 

Regards

 

Jon

 

From: Dots [mailto: dots-bounces@ietf.org] On = Behalf Of Konda, Tirumaleswar Reddy
Sent: 02 January 2018 = 08:48
To: Jon Shallow; dots@ietf.org
Subject: Re: = [Dots] Using SNI

 

Hi = Jon,

 

Both signal and data channel drafts = refer to RFC7525 for secure use of (D)TLS and RFC7525 mandates TLS = implementations to support SNI. I don’t see the need to explicitly = discuss SNI in these drafts.


Regards,

-Tiru

 

From: Dots [mailto:dots-bounces@ietf.org] = On Behalf Of Jon Shallow
Sent: Saturday, December 30, = 2017 4:57 PM
To: dots@ietf.org
Subject: = [Dots] Using SNI

 

Hi WG,

 

When = providing a DOTS server data channel service in my environment, this = shares the same ip / port which also provides other services (e.g. GUI / = REST server etc.).  Even if the Root Discovery points to another IP = and or port for the actual data channel activity, the TLS exchanges for = the Root Discovery have to correctly work.  I suspect that I am not = the only DOTS vendor who will have this type of requirement of a single = IP providing multiple TLS services.

 

As DOTS = requires mutual authentication, this is a different security requirement = than required by the GUI environment (DOTS requires client cert to be = presented, GUI does not and providing certificates to every GUI client = is not a practical option).

 

This can be = handled by using SNI by using 2 different FQDNs and requiring the DOTS = client to include the DOTS specific FQDN in the TLS Client Hello.  = Whether the GUI client does or does not (likely does with modern = browsers) include a SNI FQDN when connecting to the non DOTS FQDN does = not really matter – for DOTS it is recognizing the DOTS specific = FQDN and setting up the TLS as appropriate.

 

To make sure = interoperability between DOTS vendors, I would like to see something = like added to the data channel spec “DOTS clients MUST include the = DOTS server FQDN in the TLS Client Hello packet by using Server Name = Indication (SNI) RFC 3546”.

 

In addition, = I think that this would be a good idea as well for the signal draft = – thereby giving DOTS vendors the opportunity to host multiple = DOTS servers (likely to be different security requirements for their = different client) on a single IP / port.

 

Thoughts / = comments?

 

Regards

 

Jon

------=_NextPart_000_0B4C_01D383B0.75915D60-- From nobody Tue Jan 2 02:34:43 2018 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 32CC6126E01 for ; Tue, 2 Jan 2018 02:34:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 8sZJMhtZevIC for ; Tue, 2 Jan 2018 02:34:39 -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 9859A12702E for ; Tue, 2 Jan 2018 02:34: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 1eWJu0-0006hU-VC; Tue, 02 Jan 2018 10:34:37 +0000 From: "Jon Shallow" To: "'Konda, Tirumaleswar Reddy'" , References: <073001d37b47$e6f27460$b4d75d20$@jpshallow.com> <094a01d3801f$20d94dd0$628be970$@jpshallow.com> In-Reply-To: Date: Tue, 2 Jan 2018 10:34:35 -0000 Message-ID: <0b6101d383b5$48b29a20$da17ce60$@jpshallow.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0B62_01D383B5.48B691C0" X-Mailer: Microsoft Outlook 14.0 Content-Language: en-gb Thread-Index: AQJTmGwWHKq+N1BT2oAOspP+fqvZXQF5x90cAibGkTgCTX2+C6IwxbNQ Archived-At: Subject: Re: [Dots] Signal CBOR / JSON Mapping 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, 02 Jan 2018 10:34:42 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0B62_01D383B5.48B691C0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Tiru, See inline. Regards Jon From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of Konda, Tirumaleswar Reddy Sent: 02 January 2018 09:43 To: Jon Shallow; dots@ietf.org Subject: Re: [Dots] Signal CBOR / JSON Mapping Hi Jon, Please see inline From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Jon Shallow Sent: Friday, December 29, 2017 2:32 AM To: Konda, Tirumaleswar Reddy ; dots@ietf.org Subject: Re: [Dots] Signal CBOR / JSON Mapping Hi Tiru, Thanks for pointing me to these references. RFC7951 6.1. Numeric Types A value of the "int8", "int16", "int32", "uint8", "uint16", or "uint32" type is represented as a JSON number. A value of the "int64", "uint64", or "decimal64" type is represented as a JSON string whose content is the lexical representation of the corresponding YANG type as specified in Sections 9.2.1 and 9.3.1 of [RFC7950]. For example, if the type of the leaf "foo" in Section 5.1 was "uint64" instead of "uint8", the instance would have to be encoded as "foo": "123" -- So, we now have a way of handling int64/uint64 which should be used moving forward. However, my JSON implementation (as well as many others I suspect) natively supports decimal64, so does not necessarily need to display it as a lexical representation string. Do we follow RFC7951 here as well? [TR] Let's not deviate from RFC7951 otherwise both drafts will end-up defining it's our own set of rules for encoding the YANG configuration data as JSON/CBOR text deviating from the existing standards. [Jon] Agreed I do not think that we should be following the augmented JSON parameter naming in RFC7951 "4. Names and Namespaces" otherwise we will start ending up with JSON/CBOR parameter names such as "ietf-dots-signal:mitigation-scope". If we do go with this, then the CBOR mapping table will need to get extended to cover the old, but some parameter name in different places. Comments? [TR] Both drafts should follow the naming in RFC7951. [Jon] I'm neutral on this, but agree to following standards - there will be however a lot of long parameter names which fortunately will get compressed by the CBOR mapping. However, draft-ietf-netmod-acl-model (albeit in xml not json) does not have parameter names such as "ietf-access-control-list:access-lists" As we are working with YANG, JSON and CBOR interrelation , I still think we need a table similar to below to aid implementers - referring as appropriate to the different RFCs - no-one has full knowledge of all the evolving RFCs. [TR] I don't see the need to repeat, its already discussed in detail in https://tools.ietf.org/html/rfc8040#section-5.2 and similarly DOTS signal channel draft already refers to draft-ietf-core-yang-cbor-05. [Jon] Given the number of times we have been inconsistent with the YANG / JSON and CBOR definitions of a specific parameter, having a single place where all 3 variants are on the same line certainly helps me as an implementer. -Tiru Regards Jon From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of Konda, Tirumaleswar Reddy Sent: 23 December 2017 07:06 To: Jon Shallow; dots@ietf.org Subject: Re: [Dots] Signal CBOR / JSON Mapping We should just follow the CBOR Encoding of Data Modeled with YANG defined in https://tools.ietf.org/html/draft-ietf-core-yang-cbor-05 and JSON Encoding of Data Modeled with YANG defined in https://tools.ietf.org/html/rfc7951. -Tiru From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Jon Shallow Sent: Friday, December 22, 2017 10:41 PM To: dots@ietf.org Subject: [Dots] Signal CBOR / JSON Mapping Hi WG, There are a lot of YANG parameters that we are using that are defined as int64. JSON only safely supports up to 53 bits of precision. RFC 7493 2.2 Numbers An I-JSON sender cannot expect a receiver to treat an integer whose absolute value is greater than 9007199254740991 (i.e., that is outside the range [-(2**53)+1, (2**53)-1]) as an exact value. For applications that require the exact interchange of numbers with greater magnitude or precision, it is RECOMMENDED to encode them in JSON string values. This requires that the receiving program understand the intended semantic of the value. An example would be 64-bit integers, even though modern hardware can deal with them, because of the limited scope of JavaScript numbers. RFC7049 3.6 Numbers CBOR-based protocols should take into account that different language environments pose different restrictions on the range and precision of numbers that are representable. For example, the JavaScript number system treats all numbers as floating point, which may result in silent loss of precision in decoding integers with more than 53 significant bits. A protocol that uses numbers should define its expectations on the handling of non-trivial numbers in decoders and receiving applications. ==== An option is to make all of these int64 decimal64 for the signal channel, but that does not cover the 64 bit counters in the netmod-acl. However, as the netmod-acl counters are also fed back via the mitigate status, we do not necessarily need to support the netmod-acl counters. If, however, we follow RFC 7493, in CBOR the data can be passed across as 64 bits, and as the parameter is a CBOR mapping, we can know how to encode / decode the JSON value as appropriate. However, RFC 7493 does not say whether this should be base64, base64url or numeric string representation (i.e. "1234567890"). RFC7049 refers to bignum (major type 6, tag value 2 or 3) should be encoded as base64url (4.1 Converting from CBOR to JSON) - but int64 can be held in CBOR as type 0 or 1. I prefer the numeric string representation as it is humanly easy to read and easy to convert into 64 bit integers. If we take this approach of using the parameter which is a CBOR mapping key to key off how to encode / decode the JSON, I would suggest that we could extend this to include IP addresses, Dates and client-identifiers (or their possible new names of request-nonce and client-domain-hash) to further minimize the actual number of bytes sent in a COAP packet. The CBOR mapping Table could then be extended to look something like (but it is too wide I think) /----------------------+-------------+------+---------------+--------+------ ---\ | Parameter name | YANG type | CBOR | CBOR major | JSON | JSON | | | | key | type | type | Example | |----------------------+-------------+------+---------------+--------+------ ---| | mitigation-scope | grouping | 1 | 5 map | Object | | | scope | list | 2 | 4 array | Array | | | mitigation-id | int32 | 3 | 0 unsigned | Number | 54321 | | acl-list | list | 4 | 4 array | Array | | | target-port-range | list | 5 | 4 array | Array | | | lower-port | port-number | 6 | 0 number | Number | 1111 | | upper-port | port-number | 7 | 0 number | Number | 1111 | | target-protocol | leaf-list | | 4 array | Array | | | | uint8 | 8 | 0 number | Number | 6 | | target-fqdn | leaf-list | | 4 array | Array | | | | domain-name | 9 | 3 text string | String | "a.com" | | target-uri | leaf-list | | 4 array | Array | | | | uri | 10 | 3 text string | String | | | alias-name | leaf-list | | 4 array | Array | | | | string | 11 | 3 text string | String | "web" | | lifetime | int32 | 12 | 0 number | Number | | | attack-status | enumeration | 13 | 0 number | Number | 1 | | signal-config | grouping | 14 | 5 map | Object | | | heartbeat-interval | grouping | 15 | 5 map | Object | | | max-retransmit | grouping | 16 | 5 map | Object | | | ack-timeout | grouping | 17 | 5 map | Object | | | ack-random-factor | grouping | 18 | 5 map | Object | | | min-value | int16 | 19 | 0 number | Number | 1 | | max-value | int16 | 20 | 0 number | Number | 1 | | status | enumeration | 21 | 0 number | Number | 1 | | conflict-information | grouping | 22 | 5 map | Object | | | conflict-status | enumeration | 23 | 0 number | Number | 1 | | conflict-cause | enumeration | 24 | 0 number | Number | 1 | | retry-timer | int32 | 25 | 0 number | Number | 1800 | | bytes-dropped | counter64 | 26 | 0 number | String | "1234" | | bps-dropped | counter64 | 27 | 0 number | String | "1234" | | pkts-dropped | counter64 | 28 | 0 number | String | "1234" | | pps-dropped | counter64 | 29 | 0 number | String | "1234" | | session-id | int32 | 30 | 0 number | Number | 65432 | | trigger-mitigation | boolean | 31 | 7 simple | T / F | | | missing-hb-allowed | grouping | 32 | 5 map | Object | | | current-value | int16 | 33 | 0 number | Number | 10 | | mitigation-start | decimal64 | 34 | 7 FP | Number | 10.21 | | target-prefix | leaf-list | | 4 array | Array | | | | ip-prefix | 35 | 3 text string | String | | | client-domain-hash | leaf-list | | 4 array | Array | | | | binary | 36 | 2 byte string | String | "abcdf" | | alt-server | string | 37 | 3 text string | String | | | alt-server-record | list | 38 | 4 array | Array | | | addr | string | 39 | 3 text string | String | | | ttl | int32 | 40 | 0 number | Number | 1800 | | conflict-scope | grouping | 41 | 5 map | Object | | | acl-name | string | 42 | 3 text string | String | "aname" | | acl-type | string | 43 | 3 text string | String | "ipv4" | | config-interval | int32 | 44 | 0 number | Number | 11 | | mitigating-config | grouping | 45 | 5 map | Object | | | idle-config | grouping | 46 | 5 map | Object | | | request-nonce | binary | 47 | 2 byte string | String | "xxx" | | min-value-decimal | decimal64 | 48 | 7 FP | Number | 1.1 | | max-value-decimal | decimal64 | 49 | 7 FP | Number | 1.1 | | current-value-decimal| decimal64 | 50 | 7 FP | Number | 1.1 | \----------------------+-------------+------+---------------+--------+------ ---/ Comments / suggestions? Regards Jon ------=_NextPart_000_0B62_01D383B5.48B691C0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Tiru,

 

See = inline.

 

Regards

 

Jon

 

From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of = Konda, Tirumaleswar Reddy
Sent: 02 January 2018 = 09:43
To: Jon Shallow; dots@ietf.org
Subject: Re: = [Dots] Signal CBOR / JSON Mapping

 

Hi = Jon,

 

Please see = inline

 

From: Dots [mailto:dots-bounces@ietf.org] = On Behalf Of Jon Shallow
Sent: Friday, December 29, = 2017 2:32 AM
To: Konda, Tirumaleswar Reddy <TirumaleswarReddy_Kond= a@McAfee.com>; dots@ietf.org
Subject: Re: = [Dots] Signal CBOR / JSON Mapping

 

Hi = Tiru,

 

Thanks for pointing me = to these references.

 

RFC7951

6.1.  Numeric = Types

 

   A value of = the "int8", "int16", "int32", = "uint8", "uint16", or

   = "uint32" type is represented as a JSON = number.

 

   A value of = the "int64", "uint64", or "decimal64" type = is represented

   as a JSON string whose content is = the lexical representation of the

   = corresponding YANG type as specified in Sections 9.2.1 and 9.3.1 = of

   [RFC7950].

 

   For = example, if the type of the leaf "foo" in Section 5.1 = was

   "uint64" instead of = "uint8", the instance would have to be encoded = as

 

   = "foo": "123"

--

 

So, we now have a way of = handling int64/uint64 which should be used moving = forward.

 

However, my JSON = implementation (as well as many others I suspect) natively supports = decimal64, so does not necessarily need to display it as a lexical = representation string.  Do we follow RFC7951 here as = well?

 

[TR] Let’s not deviate from RFC7951 otherwise = both drafts will end-up defining it’s our own set of rules for = encoding the YANG configuration data as JSON/CBOR text deviating from = the existing standards.

[Jon] Agreed

 

I do not think that we = should be following the augmented JSON parameter naming in RFC7951 = “4. Names and Namespaces” otherwise we will start ending up = with JSON/CBOR parameter names such as = “ietf-dots-signal:mitigation-scope”.  If we do go with = this, then the CBOR mapping table will need to get extended to cover the = old, but some parameter name in different places.  = Comments?

 

[TR] Both = drafts should follow the naming in RFC7951.

[Jon] I’m neutral on this, but agree to = following standards – there will be however a lot of long = parameter names which fortunately will get compressed by the CBOR = mapping.  However, draft-ietf-netmod-acl-model (albeit in xml not = json) does not have parameter names such as = “ietf-access-control-list:access-lists”

=

 

As we are working with = YANG, JSON and CBOR interrelation , I still think we need a table = similar to below to aid implementers – referring as appropriate to = the different RFCs – no-one has full knowledge of all the evolving = RFCs.

 

[TR] I don’t see the need to repeat, its already = discussed in detail in https://tools.ie= tf.org/html/rfc8040#section-5.2 and similarly DOTS signal channel = draft already refers to draft-ietf-core-yang-cbor-05.

[Jon] Given the number = of times we have been inconsistent with the YANG / JSON and CBOR = definitions of a specific parameter, having a single place where all 3 = variants are on the same line certainly helps me as an = implementer.

 

-Tiru

 

Regards

 

Jon

 

From: Dots [mailto: dots-bounces@ietf.org] On = Behalf Of Konda, Tirumaleswar Reddy
Sent: 23 December 2017 = 07:06
To: Jon Shallow; dots@ietf.org
Subject: Re: = [Dots] Signal CBOR / JSON Mapping

 

We should just follow = the CBOR Encoding of Data Modeled with YANG defined in https:/= /tools.ietf.org/html/draft-ietf-core-yang-cbor-05 and JSON Encoding = of Data Modeled with YANG

defined in https://tools.ietf.org/html/= rfc7951.

 

-Tiru

 

From: Dots [mailto:dots-bounces@ietf.org] = On Behalf Of Jon Shallow
Sent: Friday, December 22, = 2017 10:41 PM
To: dots@ietf.org
Subject: = [Dots] Signal CBOR / JSON Mapping

 

Hi WG,

 

There are a = lot of YANG parameters that we are using that are defined as = int64.  JSON only safely supports up to 53 bits of = precision.

 

RFC 7493 2.2 Numbers

 

   = An I-JSON sender cannot expect a receiver to treat an integer = whose

   absolute value is = greater than 9007199254740991 (i.e., that is

   outside the range [-(2**53)+1, = (2**53)-1]) as an exact value.

 

   = For applications that require the exact interchange of numbers = with

   greater magnitude = or precision, it is RECOMMENDED to encode them in

   JSON string values.  This requires = that the receiving program

   understand the intended semantic of the = value.  An example would be

   64-bit integers, even though modern = hardware can deal with them,

   because of the limited scope of = JavaScript numbers.

 

RFC7049 3.6 = Numbers

 

   CBOR-based protocols should take into = account that different language

   environments pose different restrictions = on the range and precision

   of numbers that are representable.  = For example, the JavaScript

   number system treats all numbers as = floating point, which may result

   in silent loss of precision in decoding = integers with more than 53

   significant bits.  A protocol that = uses numbers should define its

   expectations on the handling of = non-trivial numbers in decoders and

   receiving applications.

 

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

 

An option is = to make all of these int64 decimal64 for the signal channel, but that = does not cover the 64 bit counters in the netmod-acl.  However, as = the netmod-acl counters are also fed back via the mitigate status, we do = not necessarily need to support the netmod-acl = counters.

 

If, however, we follow RFC 7493, in CBOR the data can = be passed across as 64 bits, and as the parameter is a CBOR mapping, we = can know how to encode / decode the JSON value as appropriate.  = However, RFC 7493 does not say whether this should be base64, base64url = or numeric string representation (i.e. “1234567890”). =  RFC7049 refers to bignum (major type 6, tag value 2 or 3) should = be encoded as base64url (4.1 Converting from CBOR to JSON) – but = int64 can be held in CBOR as type 0 or 1.

 

I prefer the = numeric string representation as it is humanly easy to read and easy to = convert into 64 bit integers.

 

If we take = this approach of using the parameter which is a CBOR mapping key to key = off how to encode / decode the JSON, I would suggest that we could = extend this to include IP addresses, Dates and client-identifiers (or = their possible new names of request-nonce and client-domain-hash) to = further minimize the actual number of bytes sent in a COAP = packet.

 

The CBOR mapping Table could then be extended to look = something like (but it is too wide I think)

 

/----------------------+-------------+------+--------------= -+--------+---------\

| Parameter = name       | YANG type   | CBOR = | CBOR major    | JSON   | = JSON    | 

|         &nbs= p;            = |            = | key  | = type          | = type   | Example |

|----------------------+-------------+------+--------------= -+--------+---------|

| = mitigation-scope     | grouping    = |   1  | 5 = map         | Object = |         |  =

| = scope           &n= bsp;    | list        = |   2  | 4 array       | = Array  |         |  =

| = mitigation-id        | = int32       |   3  | 0 = unsigned    | Number | 54321   |  =

| = acl-list        =      | = list        |   4  | 4 = array       | Array  = |         |  =

| = target-port-range    | = list        |   5  | 4 = array       | Array  = |         |  =

| = lower-port           | = port-number |   6  | 0 = number      | Number | 1111    = | 

| = upper-port           | = port-number |   7  | 0 = number      | Number | 1111    = | 

| = target-protocol      | leaf-list   = |      | 4 = array       | Array  = |         |  =

|         &nbs= p;            | = uint8       |   8  | 0 = number      | Number | = 6       |

| = target-fqdn          | = leaf-list   |      | 4 = array       | Array  = |         = |

|         &nbs= p;            | = domain-name |   9  | 3 text string | String | = "a.com" |

| = target-uri           | = leaf-list   |      | 4 = array       | Array  = |         |  =

|         &nbs= p;            | = uri         |  10  | 3 = text string | String |         = |

| = alias-name           | = leaf-list   |      | 4 = array       | Array  | =         |  =

| =             &= nbsp;        | = string      |  11  | 3 text string | = String | "web"   | 

| = lifetime           = ;  | int32       |  12  | 0 = number      | Number = |         |  =

| = attack-status        | enumeration = |  13  | 0 number      | Number | = 1       | 

| signal-config        = | grouping    |  14  | 5 = map         | Object = |         |  =

| = heartbeat-interval   | grouping    |  = 15  | 5 map         | = Object |         |  =

| = max-retransmit       | = grouping    |  16  | 5 = map         | Object = |         |  =

| = ack-timeout          | = grouping    |  17  | 5 = map         | Object = |         |  =

| = ack-random-factor    | grouping    |  = 18  | 5 map         | = Object |         |  =

| = min-value   =          | = int16       |  19  | 0 = number      | Number | = 1       | 

| = max-value          &nbs= p; | int16       |  20  | 0 = number      | Number | = 1       | 

| = status           &= nbsp;   | enumeration |  21  | 0 = number      | Number | = 1       | 

| conflict-information | grouping    = |  22  | 5 map         = | Object |         |  =

| = conflict-status      | enumeration |  = 23  | 0 number      | Number | = 1       | 

| conflict-cause       | = enumeration |  24  | 0 number      | = Number | 1       |  =

| = retry-timer          | = int32       |  25  | 0 = number      | Number | 1800    = | 

| = bytes-dropped        | = counter64   |  26  | 0 = number      | String | "1234"  = | 

| = bps-dropped          | = counter64   |  27  | 0 = number      | String | "1234"  = | 

| = pkts-dropped         | counter64 =   |  28  | 0 number      | = String | "1234"  | 

| = pps-dropped          | = counter64   |  29  | 0 = number      | String | "1234"  = | 

| = session-id           | = int32       |  30  | 0 = number      | Number | 65432   = | 

| = trigger-mitigation   | boolean     |  = 31  | 7 simple      | T / F  = |         |  =

| = missing-hb-allowed   | grouping    |  = 32  | 5 map         | = Object |         |  =

| = current-value        | = int16       |  33  | 0 = number      | Number | = 10      | 

| mitigation-start     | = decimal64   |  34  | 7 = FP          | Number | = 10.21   | 

| target-prefix        = | leaf-list   |      | 4 = array       | Array  = |         |  =

| =             &= nbsp;        | = ip-prefix   |  35  | 3 text string | String = |         |  =

| = client-domain-hash   | leaf-list   |  =     | 4 array       | = Array  |         = |

| =             &= nbsp;        | = binary      |  36  | 2 byte string | = String | "abcdf" |

| = alt-server           | = string      |  37  | 3 text string | = String |         |  =

| = alt-server-record    | = list        |  38  | 4 = array       | Array  = |         |  =

| = addr           &nb= sp;     | string      = |  39  | 3 text string | String = |         |  =

| = ttl           &nbs= p;      | = int32       |  40  | 0 = number      | Number | 1800    = | 

| = conflict-scope       | = grouping    |  41  | 5 = map         | Object = |         |  =

| = acl-name           = ;  | string      |  42  | 3 text = string | String | "aname" | 

| = acl-type           = ;  | string      |  43  | 3 text = string | String | "ipv4"  |  =

| = config-interval      | = int32       |  44  | 0 = number      | Number | = 11      | 

| mitigating-config    | = grouping    |  45  | 5 = map         | Object = |         |  =

| = idle-config          | = grouping    |  46  | 5 = map         | Object = |         |  =

| = request-nonce        | = binary      |  47  | 2 byte string | = String | "xxx"   | 

| min-value-decimal    | = decimal64   |  48  | 7 = FP          | Number | = 1.1     | 

| max-value-decimal    | = decimal64   |  49  | 7 = FP          | Number | = 1.1     | 

| current-value-decimal| decimal64   |  = 50  | 7 FP          | = Number | 1.1     | 

\----------------------+-------------+------+--------------= -+--------+---------/

 

 

Comments / = suggestions?

 

Regards

 

Jon

------=_NextPart_000_0B62_01D383B5.48B691C0-- From nobody Tue Jan 2 02:47:55 2018 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 45C53126FDC for ; Tue, 2 Jan 2018 02:47:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.011 X-Spam-Level: X-Spam-Status: No, score=-7.011 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, T_RP_MATCHES_RCVD=-0.01] 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 3BfNw7fSVZ-a for ; Tue, 2 Jan 2018 02:47:51 -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 E6000126BF7 for ; Tue, 2 Jan 2018 02:47:50 -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=1514890052; 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: x-microsoft-antispam-message-info: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=d jgpI6JgjYR4Nyd+H9uRWsjG242opajEPR5zL3oVZR o=; b=J9kC0djDK+3PFP1Ja26acYhc+pWs/BmZOWqm4IlTaa40 zcJTyG5YFQ8RA+B0gALr2XXcCXHr7jVrDUNbUy2Gjd6cYluuqM e+Vpzsq2iq4fRp3gROkVMiAPjS4MMBipnjpxqzIIPv/gKlr7Y1 McRS+ZzSN7eRqRbQ3vQob9BuhbQ= Received: from MIVEXAPP1N01.corpzone.internalzone.com (mivexapp1n01.corpzone.internalzone.com [10.48.48.88]) by MIVWSMAILOUT1.mcafee.com with smtp (TLS: TLSv1/SSLv3,256bits,ECDHE-RSA-AES256-SHA384) id 390f_e048_81d85a45_61c5_42d6_80f7_050ad90d3d0c; Tue, 02 Jan 2018 04:47:32 -0600 Received: from MIVEXAPP1N02.corpzone.internalzone.com (10.48.48.89) by MIVEXAPP1N01.corpzone.internalzone.com (10.48.48.88) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Tue, 2 Jan 2018 05:47:23 -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, 2 Jan 2018 05:47:22 -0500 Received: from NAM03-CO1-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, 2 Jan 2018 05:47:20 -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.366.8; Tue, 2 Jan 2018 10:47:18 +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.0366.009; Tue, 2 Jan 2018 10:47:18 +0000 From: "Konda, Tirumaleswar Reddy" To: Jon Shallow , kaname nishizuka , "dots@ietf.org" Thread-Topic: [Dots] [signal-channel-draft] CoAP libraries have problems with the DOTS spec Thread-Index: AQHTf8LysSrBqL8kXEaeN1Zbh0iz4KNZPmiAgADuooCABjh4gA== Date: Tue, 2 Jan 2018 10:47:17 +0000 Message-ID: References: <094801d3801e$f7ab01b0$e7010510$@jpshallow.com> <099601d38096$487c9410$d975bc30$@jpshallow.com> In-Reply-To: <099601d38096$487c9410$d975bc30$@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; 7:Yo9S5yiFjLrfqlnP0VHzli7IRZtsjrHXJmsJtcXl8GhclAhhqNLP/LCsF1lO8ZB2sxBT8/+Qnzc4OwVtSU5detTVplB+blWCkwDsR1UTJOgMaeoePeR65C59bMLg2kPVpLw4KFO4GGj7BVpPYaYTgpIA6m0yA1NONd/SpANRJ4plTJEjFuNL2lxG57t3d6s93oGIYBZhzSH0iMs0/Vn+CqLnJ+q8xlRyUlRRC3k/OcJnhkxmlQzFEMyyf2evngUk x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: e812ce20-3a8b-42e2-5b3c-08d551ce319e x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(5600026)(4604075)(3008032)(2017052603307)(7153060); SRVR:DM5PR16MB1788; x-ms-traffictypediagnostic: DM5PR16MB1788: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(190756311086443)(158342451672863); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040470)(2401047)(5005006)(8121501046)(10201501046)(93006095)(93001095)(3231023)(944501075)(3002001)(6041268)(20161123558120)(20161123564045)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123562045)(6072148)(201708071742011); SRVR:DM5PR16MB1788; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:DM5PR16MB1788; x-forefront-prvs: 0540846A1D x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39380400002)(376002)(39860400002)(366004)(396003)(346002)(32952001)(53754006)(189003)(13464003)(199004)(102836004)(305945005)(53936002)(97736004)(2906002)(6506007)(14454004)(229853002)(81156014)(81166006)(59450400001)(80792005)(68736007)(99286004)(6436002)(25786009)(8676002)(55016002)(77096006)(53546011)(33656002)(6246003)(7696005)(76176011)(5660300001)(74316002)(8936002)(3846002)(86362001)(72206003)(230783001)(478600001)(9686003)(6116002)(2950100002)(6306002)(966005)(2501003)(2900100001)(3660700001)(105586002)(66066001)(106356001)(7736002)(316002)(110136005)(3280700002)(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; x-microsoft-antispam-message-info: 0ra10TSmXsl6JiXtzY2TdnZBq3WEgt4nwPL1EKxPuNyy80vpc7B7ype+A4pFTHTIK8nuKqSOFzTvn6G33FHZQQ== 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: e812ce20-3a8b-42e2-5b3c-08d551ce319e X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Jan 2018 10:47:17.9117 (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 <6190> : inlines <6292> : streams <1774879> : uri <2561697> Archived-At: Subject: Re: [Dots] [signal-channel-draft] CoAP libraries have problems with the DOTS spec 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, 02 Jan 2018 10:47:54 -0000 Please see inline=20 > -----Original Message----- > From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Jon Shallow > Sent: Friday, December 29, 2017 4:45 PM > To: kaname nishizuka ; dots@ietf.org > Subject: Re: [Dots] [signal-channel-draft] CoAP libraries have problems w= ith > the DOTS spec >=20 > Hi all, >=20 > After thinking about this, I have added some additional comments inline > [Jon1]. >=20 > This response is applicable to more than just Kaname. >=20 > Regards >=20 > Jon >=20 > -----Original Message----- > From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of Jon Shallow > Sent: 28 December 2017 21:01 > To: 'kaname nishizuka'; dots@ietf.org > Subject: Re: [Dots] [signal-channel-draft] CoAP libraries have problems w= ith > the DOTS spec >=20 > Hi Kaname, >=20 > See inline [Jon]. >=20 > Regards >=20 > Jon >=20 > -----Original Message----- > From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of kaname nishizuka > Sent: 28 December 2017 10:02 > To: dots@ietf.org > Subject: [Dots] [signal-channel-draft] CoAP libraries have problems with = the > DOTS spec >=20 > Hi, >=20 > Last week, Jon and I did the second interoperability test based on the -1= 3 > version of the signal channel draft. > We made significant improvements of each implementation. Several > feedbacks to the WG have been made by Jon already. >=20 > Based on the experience, I encountered the problems between CoAP > libraries and the specification of the DOTS. >=20 > 1. resource identification of GET methods. >=20 > In signal channel spec, the target resource in GET method is identified i= n the > BODY of the message, that is mitigation-id (and client-identifier). > However, CoAP libraries, at least we investigated, only see the Request U= RI, > so it cannot locate the resource because it doesn't see the BODY. >=20 > So the question is, why does the DOTS spec use CoAP Body for resource > identifier? >=20 > [Jon] A very good question. I had just assumed that this was the way to = do it, > but had noted that this was not done when using HTTP etc. and so was > different. See later comments >=20 > Most of CoAP libraries only support request URI in CoAP GET/observe, whic= h > is the spec from RFC7252. > https://tools.ietf.org/html/rfc7252 > 5.8.1.GET > The GET method retrieves a representation for the information that > currently corresponds to the resource identified by the request URI. > [Jon] RFC 7252 states also > 5.10.1. Uri-Host, Uri-Port, Uri-Path, and Uri-Query >=20 > The Uri-Host, Uri-Port, Uri-Path, and Uri-Query Options are used to > specify the target resource of a request to a CoAP origin server. > [Jon] So it looks like the target resource should only be in Uri-Path and= /or > Uri-Query. > [Jon] In my CoAP Library, I have to define each individual resource (it d= oes a > lookup against a hash of the complete Uri to find whether the resource is > known or not), so, when say mitigation-id=3D2 is added, I need to registe= r the > resource .well-known/dots/v1/mitigate/migration-is=3D2 with an associated > handler. This is not difficult to do, but potentially could consume a lo= t of > DOTS server resources if many mitigations are active. > [Jon] Doing it as a Query Option I think is my preference - Comments? > [Jon] The same is true for GET signal configuration as well. Yes, will update draft to use Query option for GET method.=20 >=20 > [Jon1] I am now leaning towards doing it in the Uri-Path but still not su= re. > The CoAP layer responds with a 4.04 with my CoAP library if the resource > (Uri-Path) is unknown. > [Jon1] We need to define the order in the path - e.g. client-identifier (= or > request-none etc. if that is accepted) then mitigation-id, so that resour= ces > are built consistently from a mitigation request. Agreed.=20 > [Jon1] However doing this means we also need to include PUT and DELETE > with the resource specified in the Uri-Path. My library then runs into a > chicken and egg situation with PUT - the PUT is defining the new resource= , > but as the resource is not defined (yet) in the CoAP layer, it gets rejec= ted > with a > 4.04 in the CoAP layer (as mentioned above). The way around this is to u= se > POST to create new mitigation requests (and will respond with appropriate > Location-Path to give the new UI) and PUT if we are refreshing the resour= ce. >=20 > [Jon1] Thoughts? PUT can also be used to create a new resource, and the draft uses PUT inste= ad of POST because it is idempotent and during a volumetric DDoS attack sa= turating the incoming link to the DOTS client, DOTS client will most likely= not=20 receive the server-side responses. Is this an implementation bug ? -Tiru >=20 > 2. Confirmable vs NonConfirmable at Mitigation Request >=20 > A CoAP library (dustin/go-coap) stops listening right after sending out t= he > NonConfirmable message because NonConfirmable messages do not require > acknowledgements. >=20 > [Jon] As there is a good chance during attack scenarios that responses ma= y > not be able to get back, it makes sense to me that these "GET mitigation" > requests are non-confirmable. Certainly "PUT mitigation" needs to be > thought of as a one way signal. There are times that the client has to r= un > "blind" during attack scenarios. > [Jon]If they were confirmable, then the request will get sent multiple ti= mes > to the DOTS server - which could be handled by the server, but then the > confirmable responses would retried whilst sending back to the DOTS clien= t > and eventually retry timeout. A large scale attack could swamp a DOTS > server with all the yet to be confirmed confirmable responses. > [Jon] As per RFC7252 "2.2. Request/Response Model", a response to a non- > confirmable request is expected to be handled as in:- > If a request is sent in a Non-confirmable message, then the response > is sent using a new Non-confirmable message, although the server may > instead send a Confirmable message. This type of exchange is > illustrated in Figure 6. >=20 > Client Server > | | > | NON [0x7a11] | > | GET /temperature | > | (Token 0x74) | > +----------------->| > | | > | NON [0x23bc] | > | 2.05 Content | > | (Token 0x74) | > | "22.5 C" | > |<-----------------+ > | | >=20 > Figure 6: A Request and a Response Carried in Non-confirmable > Messages [Jon] So I would expect any CoA= P library to > support this non-confirmation mechanism by receiving a new non- > confirmable message. It would be the responsibility of the DOTS layer to > associate the Tokens together to handle the responses with the requests. > [Jon] In addition, when Observe is enabled, the DOTS server will continue= to > generate non-confirmable messages with the same Token. Again, the DOTS > client will need to know what to do with the Token (which could be to upd= ate > things, or to send a RST if no more packets with the same Token should be > sent. >=20 >=20 > The spec of Confirmable message already have the retransmission > mechanism, so using Confirmable message is an easier way to notice that t= he > message has been lost during the attack time. >=20 > [Jon] The DOTS client will know something is wrong as it will be seeing > heartbeat issues. >=20 > I'm afraid I'm missing some previous discussions we made on the ML and at > the WG meeting, but we have a problem with the CoAP library regarding thi= s > spec. >=20 > * At the -08 version of the signal channel draft, this change was made: > DOTS mitigation request/response are marked as non-confirmable messages. >=20 > thank you, > Kaname >=20 >=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 >=20 > _______________________________________________ > Dots mailing list > Dots@ietf.org > https://www.ietf.org/mailman/listinfo/dots From nobody Tue Jan 2 03:20:29 2018 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 09711127241 for ; Tue, 2 Jan 2018 03:20:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 6C3zzEHW7HuI for ; Tue, 2 Jan 2018 03:20:24 -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 D9C4E126FB3 for ; Tue, 2 Jan 2018 03:20:23 -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 1eWKcF-0006j5-Vn; Tue, 02 Jan 2018 11:20:20 +0000 From: "Jon Shallow" To: "'Konda, Tirumaleswar Reddy'" , , "kaname nishizuka" References: <094801d3801e$f7ab01b0$e7010510$@jpshallow.com> <099601d38096$487c9410$d975bc30$@jpshallow.com> In-Reply-To: Date: Tue, 2 Jan 2018 11:20:18 -0000 Message-ID: <0b7a01d383bb$aba5f720$02f1e560$@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: AQLSq4q/0bL2TF/Kn5VRXUOjWNcfvgJYRDCAAhO9FZgBoHWANKExtsVA Archived-At: Subject: Re: [Dots] [signal-channel-draft] CoAP libraries have problems with the DOTS spec 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, 02 Jan 2018 11:20:27 -0000 Hi all, Please see inline [Jon2]. Regards Jon -----Original Message----- From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of Konda, Tirumaleswar Reddy Sent: 02 January 2018 10:47 To: Jon Shallow; kaname nishizuka; dots@ietf.org Subject: Re: [Dots] [signal-channel-draft] CoAP libraries have problems with the DOTS spec Please see inline > -----Original Message----- > From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Jon Shallow > Sent: Friday, December 29, 2017 4:45 PM > To: kaname nishizuka ; dots@ietf.org > Subject: Re: [Dots] [signal-channel-draft] CoAP libraries have > problems with the DOTS spec > > Hi all, > > After thinking about this, I have added some additional comments > inline [Jon1]. > > This response is applicable to more than just Kaname. > > Regards > > Jon > > -----Original Message----- > From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of Jon Shallow > Sent: 28 December 2017 21:01 > To: 'kaname nishizuka'; dots@ietf.org > Subject: Re: [Dots] [signal-channel-draft] CoAP libraries have > problems with the DOTS spec > > Hi Kaname, > > See inline [Jon]. > > Regards > > Jon > > -----Original Message----- > From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of kaname > nishizuka > Sent: 28 December 2017 10:02 > To: dots@ietf.org > Subject: [Dots] [signal-channel-draft] CoAP libraries have problems > with the DOTS spec > > Hi, > > Last week, Jon and I did the second interoperability test based on the > -13 version of the signal channel draft. > We made significant improvements of each implementation. Several > feedbacks to the WG have been made by Jon already. > > Based on the experience, I encountered the problems between CoAP > libraries and the specification of the DOTS. > > 1. resource identification of GET methods. > > In signal channel spec, the target resource in GET method is > identified in the BODY of the message, that is mitigation-id (and client-identifier). > However, CoAP libraries, at least we investigated, only see the > Request URI, so it cannot locate the resource because it doesn't see the BODY. > > So the question is, why does the DOTS spec use CoAP Body for resource > identifier? > > [Jon] A very good question. I had just assumed that this was the way > to do it, but had noted that this was not done when using HTTP etc. > and so was different. See later comments > > Most of CoAP libraries only support request URI in CoAP GET/observe, > which is the spec from RFC7252. > https://tools.ietf.org/html/rfc7252 > 5.8.1.GET > The GET method retrieves a representation for the information that > currently corresponds to the resource identified by the request URI. > [Jon] RFC 7252 states also > 5.10.1. Uri-Host, Uri-Port, Uri-Path, and Uri-Query > > The Uri-Host, Uri-Port, Uri-Path, and Uri-Query Options are used to > specify the target resource of a request to a CoAP origin server. > [Jon] So it looks like the target resource should only be in Uri-Path > and/or Uri-Query. > [Jon] In my CoAP Library, I have to define each individual resource > (it does a lookup against a hash of the complete Uri to find whether > the resource is known or not), so, when say mitigation-id=2 is added, > I need to register the resource > .well-known/dots/v1/mitigate/migration-is=2 with an associated > handler. This is not difficult to do, but potentially could consume a lot of DOTS server resources if many mitigations are active. > [Jon] Doing it as a Query Option I think is my preference - Comments? > [Jon] The same is true for GET signal configuration as well. Yes, will update draft to use Query option for GET method. [Jon2] This works for me, but does not feel right when this is extended for "PUT .../mitigate Query mitigation-id-2" to create the mitigation-id. I think that the complete "resource" should be specified for consistency and just leave the c=? as being the required valid Query option. > > [Jon1] I am now leaning towards doing it in the Uri-Path but still not sure. > The CoAP layer responds with a 4.04 with my CoAP library if the > resource > (Uri-Path) is unknown. > [Jon1] We need to define the order in the path - e.g. > client-identifier (or request-none etc. if that is accepted) then > mitigation-id, so that resources are built consistently from a mitigation request. Agreed. [Jon2] then something similar to the above specifying ordering needs to be put into the draft. > [Jon1] However doing this means we also need to include PUT and DELETE > with the resource specified in the Uri-Path. My library then runs > into a chicken and egg situation with PUT - the PUT is defining the > new resource, but as the resource is not defined (yet) in the CoAP > layer, it gets rejected with a > 4.04 in the CoAP layer (as mentioned above). The way around this is > to use POST to create new mitigation requests (and will respond with > appropriate Location-Path to give the new UI) and PUT if we are refreshing the resource. > > [Jon1] Thoughts? PUT can also be used to create a new resource, and the draft uses PUT instead of POST because it is idempotent and during a volumetric DDoS attack saturating the incoming link to the DOTS client, DOTS client will most likely not receive the server-side responses. Is this an implementation bug ? [Jon2] I agree that it is a bug in the libcoap I am using [https://github.com/obgm/libcoap]. RFC7252 5.8.3. PUT states "The PUT method requests that the resource identified by the request URI be updated or created". I can try to fix the library to keep on stripping off the last UriPath and then doing a hash lookup on the sub path until a match is found in the case of doing a PUT. It would then (in my case - not needed in the draft) be the responsibility of creating a new resource if needed in the DOTS layer. -Tiru > > 2. Confirmable vs NonConfirmable at Mitigation Request > > A CoAP library (dustin/go-coap) stops listening right after sending > out the NonConfirmable message because NonConfirmable messages do not > require acknowledgements. > > [Jon] As there is a good chance during attack scenarios that responses > may not be able to get back, it makes sense to me that these "GET mitigation" > requests are non-confirmable. Certainly "PUT mitigation" needs to be > thought of as a one way signal. There are times that the client has > to run "blind" during attack scenarios. > [Jon]If they were confirmable, then the request will get sent multiple > times to the DOTS server - which could be handled by the server, but > then the confirmable responses would retried whilst sending back to > the DOTS client and eventually retry timeout. A large scale attack > could swamp a DOTS server with all the yet to be confirmed confirmable responses. > [Jon] As per RFC7252 "2.2. Request/Response Model", a response to a > non- confirmable request is expected to be handled as in:- > If a request is sent in a Non-confirmable message, then the response > is sent using a new Non-confirmable message, although the server may > instead send a Confirmable message. This type of exchange is > illustrated in Figure 6. > > Client Server > | | > | NON [0x7a11] | > | GET /temperature | > | (Token 0x74) | > +----------------->| > | | > | NON [0x23bc] | > | 2.05 Content | > | (Token 0x74) | > | "22.5 C" | > |<-----------------+ > | | > > Figure 6: A Request and a Response Carried in Non-confirmable > Messages [Jon] So I would expect any > CoAP library to support this non-confirmation mechanism by receiving a > new non- confirmable message. It would be the responsibility of the > DOTS layer to associate the Tokens together to handle the responses with the requests. > [Jon] In addition, when Observe is enabled, the DOTS server will > continue to generate non-confirmable messages with the same Token. > Again, the DOTS client will need to know what to do with the Token > (which could be to update things, or to send a RST if no more packets > with the same Token should be sent. > > > The spec of Confirmable message already have the retransmission > mechanism, so using Confirmable message is an easier way to notice > that the message has been lost during the attack time. > > [Jon] The DOTS client will know something is wrong as it will be > seeing heartbeat issues. > > I'm afraid I'm missing some previous discussions we made on the ML and > at the WG meeting, but we have a problem with the CoAP library > regarding this spec. > > * At the -08 version of the signal channel draft, this change was made: > DOTS mitigation request/response are marked as non-confirmable messages. > > thank you, > Kaname > > > _______________________________________________ > Dots mailing list > Dots@ietf.org > https://www.ietf.org/mailman/listinfo/dots > > _______________________________________________ > Dots mailing list > Dots@ietf.org > https://www.ietf.org/mailman/listinfo/dots > > _______________________________________________ > Dots mailing list > Dots@ietf.org > https://www.ietf.org/mailman/listinfo/dots _______________________________________________ Dots mailing list Dots@ietf.org https://www.ietf.org/mailman/listinfo/dots From nobody Tue Jan 2 03:29:30 2018 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 6DF22127342 for ; Tue, 2 Jan 2018 03:29:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.331 X-Spam-Level: X-Spam-Status: No, score=-4.331 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, T_RP_MATCHES_RCVD=-0.01] 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 1sP_Ugy8YlJu for ; Tue, 2 Jan 2018 03:29:25 -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 9E697127241 for ; Tue, 2 Jan 2018 03:29:25 -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=1514892556; 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:x-microsoft-antispam-message-info: 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=RrgEwhVypEhnvZL8z1kmKb2Fg6acFav9t1d+Rf 8WbFM=; b=VBYsc1vXCIKa/6Kx7cICr71ozBWtFPCMnImazikb eidZckvW1LeWApkzOsKCtGJHYutedH9SyV/+UI8wjclvGyn2Mx j+4/uV/P1uTtvVGL7axYo7pKBHYHuuHjMXh3nVZ0/M7adU18O1 57X9E3VqFhQqwg2HJUp5Y3Q02uX34KY= Received: from DNVEXAPP1N06.corpzone.internalzone.com (unknown [10.44.48.90]) by DNVWSMAILOUT1.mcafee.com with smtp (TLS: TLSv1/SSLv3,256bits,ECDHE-RSA-AES256-SHA384) id 49c8_5579_ec632c7d_e661_4e7a_92fb_82b0ccc91b0d; Tue, 02 Jan 2018 05:29:16 -0600 Received: from DNVEXAPP1N04.corpzone.internalzone.com (10.44.48.88) by DNVEXAPP1N06.corpzone.internalzone.com (10.44.48.90) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Tue, 2 Jan 2018 04:29:05 -0700 Received: from DNVO365EDGE2.corpzone.internalzone.com (10.44.176.74) by DNVEXAPP1N04.corpzone.internalzone.com (10.44.48.88) with Microsoft SMTP Server (TLS) id 15.0.1347.2 via Frontend Transport; Tue, 2 Jan 2018 04:29:05 -0700 Received: from NAM02-CY1-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, 2 Jan 2018 04:29:03 -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.366.8; Tue, 2 Jan 2018 11:29:03 +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.0366.009; Tue, 2 Jan 2018 11:29:03 +0000 From: "Konda, Tirumaleswar Reddy" To: Jon Shallow , "dots@ietf.org" , kaname nishizuka Thread-Topic: [Dots] [signal-channel-draft] CoAP libraries have problems with the DOTS spec Thread-Index: AQHTf8LysSrBqL8kXEaeN1Zbh0iz4KNZPmiAgADuooCABjh4gIAAEk4AgAAA90A= Date: Tue, 2 Jan 2018 11:29:03 +0000 Message-ID: References: <094801d3801e$f7ab01b0$e7010510$@jpshallow.com> <099601d38096$487c9410$d975bc30$@jpshallow.com> <0b7a01d383bb$aba5f720$02f1e560$@jpshallow.com> In-Reply-To: <0b7a01d383bb$aba5f720$02f1e560$@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; 7:Eu2jHCg9vqkDbRV5zHgLGMxdJfK7UrLqFuRntJhW9XW/W28/pKfLvMmDkYm+iTPlRM26AHiq7Uu6z/8ZP8w6usF7beeqReomfl4eFoZw3f3sE469QtHf8jEY+o1+KigvpTrXV5u7OIAABpJF4nD4I9tEJK5U94LMmhcee1bJUZPTLu7odv4eiRM2Vy0PSQeKXNxID/OPHRcVg7aQzWzYIbS3UBm7/dZYL9Uy3g0JNnn575wne79GD/FK/cQCuc0s x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 494b90ba-1d01-4ea2-9da8-08d551d406d4 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(5600026)(4604075)(3008032)(2017052603307)(7153060); SRVR:DM5PR16MB1787; x-ms-traffictypediagnostic: DM5PR16MB1787: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(190756311086443)(158342451672863)(166708455590820)(123452027830198); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040470)(2401047)(5005006)(8121501046)(10201501046)(93006095)(93001095)(3231023)(944501075)(3002001)(6041268)(20161123558120)(20161123564045)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123562045)(6072148)(201708071742011); SRVR:DM5PR16MB1787; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:DM5PR16MB1787; x-forefront-prvs: 0540846A1D x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39860400002)(366004)(396003)(39380400002)(346002)(376002)(53754006)(32952001)(199004)(189003)(13464003)(68736007)(93886005)(66066001)(2501003)(6246003)(55016002)(229853002)(316002)(59450400001)(8936002)(6306002)(102836004)(76176011)(53936002)(6436002)(6506007)(53546011)(3280700002)(7696005)(81166006)(81156014)(3660700001)(99286004)(8676002)(9686003)(110136005)(2900100001)(2906002)(3846002)(478600001)(230783001)(6116002)(25786009)(86362001)(33656002)(5660300001)(74316002)(305945005)(14454004)(106356001)(97736004)(80792005)(77096006)(7736002)(72206003)(2950100002)(105586002)(966005)(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) x-microsoft-antispam-message-info: 4bJwnBU6BxCeMPB5nl5Yvk3dBnVFb+ReL8WVwOvXqO6a5CepGUjLx96B5IAym5cSmmQc953HixjSEE/ttfdbcA== 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: 494b90ba-1d01-4ea2-9da8-08d551d406d4 X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Jan 2018 11:29:03.0900 (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 <6190> : inlines <6292> : streams <1774882> : uri <2561716> Archived-At: Subject: Re: [Dots] [signal-channel-draft] CoAP libraries have problems with the DOTS spec 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, 02 Jan 2018 11:29:28 -0000 Hi Jon, Please see inline > -----Original Message----- > From: Jon Shallow [mailto:supjps-ietf@jpshallow.com] > Sent: Tuesday, January 2, 2018 4:50 PM > To: Konda, Tirumaleswar Reddy > ; dots@ietf.org; kaname > nishizuka > Subject: RE: [Dots] [signal-channel-draft] CoAP libraries have problems w= ith > the DOTS spec >=20 > Hi all, >=20 > Please see inline [Jon2]. >=20 > Regards >=20 > Jon >=20 > -----Original Message----- > From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of Konda, > Tirumaleswar Reddy > Sent: 02 January 2018 10:47 > To: Jon Shallow; kaname nishizuka; dots@ietf.org > Subject: Re: [Dots] [signal-channel-draft] CoAP libraries have problems w= ith > the DOTS spec >=20 > Please see inline >=20 > > -----Original Message----- > > From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Jon Shallow > > Sent: Friday, December 29, 2017 4:45 PM > > To: kaname nishizuka ; dots@ietf.org > > Subject: Re: [Dots] [signal-channel-draft] CoAP libraries have > > problems with the DOTS spec > > > > Hi all, > > > > After thinking about this, I have added some additional comments > > inline [Jon1]. > > > > This response is applicable to more than just Kaname. > > > > Regards > > > > Jon > > > > -----Original Message----- > > From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of Jon Shallow > > Sent: 28 December 2017 21:01 > > To: 'kaname nishizuka'; dots@ietf.org > > Subject: Re: [Dots] [signal-channel-draft] CoAP libraries have > > problems with the DOTS spec > > > > Hi Kaname, > > > > See inline [Jon]. > > > > Regards > > > > Jon > > > > -----Original Message----- > > From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of kaname > > nishizuka > > Sent: 28 December 2017 10:02 > > To: dots@ietf.org > > Subject: [Dots] [signal-channel-draft] CoAP libraries have problems > > with the DOTS spec > > > > Hi, > > > > Last week, Jon and I did the second interoperability test based on the > > -13 version of the signal channel draft. > > We made significant improvements of each implementation. Several > > feedbacks to the WG have been made by Jon already. > > > > Based on the experience, I encountered the problems between CoAP > > libraries and the specification of the DOTS. > > > > 1. resource identification of GET methods. > > > > In signal channel spec, the target resource in GET method is > > identified in the BODY of the message, that is mitigation-id (and > client-identifier). > > However, CoAP libraries, at least we investigated, only see the > > Request URI, so it cannot locate the resource because it doesn't see > > the > BODY. > > > > So the question is, why does the DOTS spec use CoAP Body for resource > > identifier? > > > > [Jon] A very good question. I had just assumed that this was the way > > to do it, but had noted that this was not done when using HTTP etc. > > and so was different. See later comments > > > > Most of CoAP libraries only support request URI in CoAP GET/observe, > > which is the spec from RFC7252. > > https://tools.ietf.org/html/rfc7252 > > 5.8.1.GET > > The GET method retrieves a representation for the information that > > currently corresponds to the resource identified by the request URI. > > [Jon] RFC 7252 states also > > 5.10.1. Uri-Host, Uri-Port, Uri-Path, and Uri-Query > > > > The Uri-Host, Uri-Port, Uri-Path, and Uri-Query Options are used to > > specify the target resource of a request to a CoAP origin server. > > [Jon] So it looks like the target resource should only be in Uri-Path > > and/or Uri-Query. > > [Jon] In my CoAP Library, I have to define each individual resource > > (it does a lookup against a hash of the complete Uri to find whether > > the resource is known or not), so, when say mitigation-id=3D2 is added, > > I need to register the resource > > .well-known/dots/v1/mitigate/migration-is=3D2 with an associated > > handler. This is not difficult to do, but potentially could consume a > > lot > of DOTS server resources if many mitigations are active. > > [Jon] Doing it as a Query Option I think is my preference - Comments? > > [Jon] The same is true for GET signal configuration as well. >=20 > Yes, will update draft to use Query option for GET method. > [Jon2] This works for me, but does not feel right when this is extended f= or > "PUT .../mitigate Query mitigation-id-2" to create the mitigation-id. I = think > that the complete "resource" should be specified for consistency and just > leave the c=3D? as being the required valid Query option. PUT method does not need to convey the Query Option (for example please see= https://tools.ietf.org/html/rfc7967#section-4.1.1, the resource is specifi= ed in the URI-path option itself). >=20 > > > > [Jon1] I am now leaning towards doing it in the Uri-Path but still not > sure. > > The CoAP layer responds with a 4.04 with my CoAP library if the > > resource > > (Uri-Path) is unknown. > > [Jon1] We need to define the order in the path - e.g. > > client-identifier (or request-none etc. if that is accepted) then > > mitigation-id, so that resources are built consistently from a > > mitigation > request. >=20 > Agreed. > [Jon2] then something similar to the above specifying ordering needs to b= e > put into the draft. Yes.=20 >=20 > > [Jon1] However doing this means we also need to include PUT and DELETE > > with the resource specified in the Uri-Path. My library then runs > > into a chicken and egg situation with PUT - the PUT is defining the > > new resource, but as the resource is not defined (yet) in the CoAP > > layer, it gets rejected with a > > 4.04 in the CoAP layer (as mentioned above). The way around this is > > to use POST to create new mitigation requests (and will respond with > > appropriate Location-Path to give the new UI) and PUT if we are > > refreshing > the resource. > > > > [Jon1] Thoughts? >=20 > PUT can also be used to create a new resource, and the draft uses PUT > instead of POST because it is idempotent and during a volumetric DDoS > attack saturating the incoming link to the DOTS client, DOTS client will = most > likely not receive the server-side responses. Is this an implementation b= ug ? >=20 > [Jon2] I agree that it is a bug in the libcoap I am using > [https://github.com/obgm/libcoap]. RFC7252 5.8.3. PUT states "The PUT > method requests that the resource identified by the request URI be update= d > or created". I can try to fix the library to keep on stripping off the l= ast UriPath > and then doing a hash lookup on the sub path until a match is found in th= e > case of doing a PUT. It would then (in my case - not needed in the > draft) be the responsibility of creating a new resource if needed in the = DOTS > layer. Thanks. Cheers, Tiru >=20 > -Tiru >=20 > > > > 2. Confirmable vs NonConfirmable at Mitigation Request > > > > A CoAP library (dustin/go-coap) stops listening right after sending > > out the NonConfirmable message because NonConfirmable messages do > not > > require acknowledgements. > > > > [Jon] As there is a good chance during attack scenarios that responses > > may not be able to get back, it makes sense to me that these "GET > mitigation" > > requests are non-confirmable. Certainly "PUT mitigation" needs to be > > thought of as a one way signal. There are times that the client has > > to run "blind" during attack scenarios. > > [Jon]If they were confirmable, then the request will get sent multiple > > times to the DOTS server - which could be handled by the server, but > > then the confirmable responses would retried whilst sending back to > > the DOTS client and eventually retry timeout. A large scale attack > > could swamp a DOTS server with all the yet to be confirmed confirmable > responses. > > [Jon] As per RFC7252 "2.2. Request/Response Model", a response to a > > non- confirmable request is expected to be handled as in:- > > If a request is sent in a Non-confirmable message, then the response > > is sent using a new Non-confirmable message, although the server may > > instead send a Confirmable message. This type of exchange is > > illustrated in Figure 6. > > > > Client Server > > | | > > | NON [0x7a11] | > > | GET /temperature | > > | (Token 0x74) | > > +----------------->| > > | | > > | NON [0x23bc] | > > | 2.05 Content | > > | (Token 0x74) | > > | "22.5 C" | > > |<-----------------+ > > | | > > > > Figure 6: A Request and a Response Carried in Non-confirmable > > Messages [Jon] So I would expect any > > CoAP library to support this non-confirmation mechanism by receiving a > > new non- confirmable message. It would be the responsibility of the > > DOTS layer to associate the Tokens together to handle the responses > > with > the requests. > > [Jon] In addition, when Observe is enabled, the DOTS server will > > continue to generate non-confirmable messages with the same Token. > > Again, the DOTS client will need to know what to do with the Token > > (which could be to update things, or to send a RST if no more packets > > with the same Token should be sent. > > > > > > The spec of Confirmable message already have the retransmission > > mechanism, so using Confirmable message is an easier way to notice > > that the message has been lost during the attack time. > > > > [Jon] The DOTS client will know something is wrong as it will be > > seeing heartbeat issues. > > > > I'm afraid I'm missing some previous discussions we made on the ML and > > at the WG meeting, but we have a problem with the CoAP library > > regarding this spec. > > > > * At the -08 version of the signal channel draft, this change was made: > > DOTS mitigation request/response are marked as non-confirmable > messages. > > > > thank you, > > Kaname > > > > > > _______________________________________________ > > 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 >=20 > _______________________________________________ > Dots mailing list > Dots@ietf.org > https://www.ietf.org/mailman/listinfo/dots From nobody Tue Jan 2 03:34:21 2018 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 50597127241 for ; Tue, 2 Jan 2018 03:34:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.01 X-Spam-Level: X-Spam-Status: No, score=-7.01 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, T_RP_MATCHES_RCVD=-0.01] 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 1qNH2d0mq0u6 for ; Tue, 2 Jan 2018 03:34: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 10547127342 for ; Tue, 2 Jan 2018 03:34:14 -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=1514892854; 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:x-microsoft-antispam-message-info: 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=yroyX7xxQn7sljyroeeUM6FLD5eipiekYBU1JP PcruY=; b=Noj73eUoMtbpMQ/8vJiamPTqVVWNJCH1Mp1ULN6n F+wjQLd+FQcNEFHocKd36UTYdOyyjgVd2bnDVsQIsuhA6umpel OV9Ce5k5Q0oV+Y0qBrir6+FVBRuG/7rmxiQJ55FJ2LDBCiAore 0JOdvwLLNOu2MaqUJR9Ub2e6fv7+70Q= Received: from MIVEXAPP1N01.corpzone.internalzone.com (unknown [10.48.48.88]) by MIVWSMAILOUT1.mcafee.com with smtp (TLS: TLSv1/SSLv3,256bits,ECDHE-RSA-AES256-SHA384) id 2e15_003e_c6d4b261_c57c_4def_84e0_0b5f199b66ae; Tue, 02 Jan 2018 05:34:12 -0600 Received: from MIVEXUSR1N01.corpzone.internalzone.com (10.48.48.81) by MIVEXAPP1N01.corpzone.internalzone.com (10.48.48.88) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Tue, 2 Jan 2018 06:34:05 -0500 Received: from MIVEXUSR1N03.corpzone.internalzone.com (10.48.48.83) by MIVEXUSR1N01.corpzone.internalzone.com (10.48.48.81) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Tue, 2 Jan 2018 06:34:04 -0500 Received: from MIVO365EDGE4.corpzone.internalzone.com (10.48.176.87) by MIVEXUSR1N03.corpzone.internalzone.com (10.48.48.83) with Microsoft SMTP Server (TLS) id 15.0.1347.2 via Frontend Transport; Tue, 2 Jan 2018 06:34:04 -0500 Received: from NAM02-SN1-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, 2 Jan 2018 06:34: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.366.8; Tue, 2 Jan 2018 11:34: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.0366.009; Tue, 2 Jan 2018 11:34:02 +0000 From: "Konda, Tirumaleswar Reddy" To: Jon Shallow , "dots@ietf.org" Thread-Topic: [Dots] Signal CBOR / JSON Mapping Thread-Index: AdN7R9961HXkMq2tTZepG2+xKMly9QAclUqwARk68QAA4qNgAAAC5pyAAAHp+uA= Date: Tue, 2 Jan 2018 11:34:02 +0000 Message-ID: References: <073001d37b47$e6f27460$b4d75d20$@jpshallow.com> <094a01d3801f$20d94dd0$628be970$@jpshallow.com> <0b6101d383b5$48b29a20$da17ce60$@jpshallow.com> In-Reply-To: <0b6101d383b5$48b29a20$da17ce60$@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; 7:tEZagbuTWkklDShWkK0rB/OK6ARPJY9iQOD86qhqZBLL6VqTK47Tnr88+SZhJ06tT/O6ZLCYRHqpEMC9EJWdNSE6ThI/LKSqo4RMn8KtS4O3cKUwci59pkCzPBTvUw6jfzjzOm1DA0ZKaCWeJFXnzVWl7qHfFoH7x1qSToRWzgI3mD+1h2dW8e9A5Maac6x1goqjtTNrYApKldJN7R6DFylVFbogBYP9Jci5XmMdlBPHnR+TfaG0wyzCcbaxYunC x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 79c19e21-4c59-4cb6-36a6-08d551d4b96a x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(5600026)(4604075)(3008032)(2017052603307)(7153060); SRVR:DM5PR16MB1785; x-ms-traffictypediagnostic: DM5PR16MB1785: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(278428928389397)(21748063052155)(123452027830198); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040470)(2401047)(5005006)(8121501046)(10201501046)(93006095)(93001095)(3231023)(944501075)(3002001)(6041268)(20161123558120)(20161123564045)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123562045)(6072148)(201708071742011); SRVR:DM5PR16MB1785; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:DM5PR16MB1785; x-forefront-prvs: 0540846A1D x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(366004)(39860400002)(396003)(39380400002)(346002)(376002)(189003)(199004)(57704003)(32952001)(66066001)(77096006)(5660300001)(229853002)(3846002)(790700001)(93886005)(6116002)(2906002)(53946003)(33656002)(97736004)(54896002)(6306002)(86362001)(6246003)(106356001)(236005)(105586002)(55016002)(9686003)(74316002)(3280700002)(53936002)(3660700001)(6436002)(19609705001)(80792005)(8936002)(606006)(7736002)(81156014)(59450400001)(81166006)(14454004)(2900100001)(8676002)(68736007)(478600001)(110136005)(9326002)(966005)(102836004)(72206003)(6506007)(316002)(2950100002)(7696005)(25786009)(76176011)(2501003)(53546011)(99286004)(21314002)(85282002)(579004); 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) x-microsoft-antispam-message-info: g6mTMYISXVs7zQW0c1cszUhiTDNVQolCse/3GbCGHi8is2yrtTr2eacZIOQ0x1BPirXr/qpueqhpePO8s5vGaA== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_DM5PR16MB178860C403689689A7241807EA190DM5PR16MB1788namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 79c19e21-4c59-4cb6-36a6-08d551d4b96a X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Jan 2018 11:34:02.6694 (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 <6190> : inlines <6292> : streams <1774882> : uri <2561719> Archived-At: Subject: Re: [Dots] Signal CBOR / JSON Mapping 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, 02 Jan 2018 11:34:19 -0000 --_000_DM5PR16MB178860C403689689A7241807EA190DM5PR16MB1788namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Jon, Please see inline [TR1] From: Jon Shallow [mailto:supjps-ietf@jpshallow.com] Sent: Tuesday, January 2, 2018 4:05 PM To: Konda, Tirumaleswar Reddy ; dots@ie= tf.org Subject: RE: [Dots] Signal CBOR / JSON Mapping Hi Tiru, See inline. Regards Jon From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of Konda, Tirumaleswar= Reddy Sent: 02 January 2018 09:43 To: Jon Shallow; dots@ietf.org Subject: Re: [Dots] Signal CBOR / JSON Mapping Hi Jon, Please see inline From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Jon Shallow Sent: Friday, December 29, 2017 2:32 AM To: Konda, Tirumaleswar Reddy >; dots@ietf.org Subject: Re: [Dots] Signal CBOR / JSON Mapping Hi Tiru, Thanks for pointing me to these references. RFC7951 6.1. Numeric Types A value of the "int8", "int16", "int32", "uint8", "uint16", or "uint32" type is represented as a JSON number. A value of the "int64", "uint64", or "decimal64" type is represented as a JSON string whose content is the lexical representation of the corresponding YANG type as specified in Sections 9.2.1 and 9.3.1 of [RFC7950]. For example, if the type of the leaf "foo" in Section 5.1 was "uint64" instead of "uint8", the instance would have to be encoded as "foo": "123" -- So, we now have a way of handling int64/uint64 which should be used moving = forward. However, my JSON implementation (as well as many others I suspect) natively= supports decimal64, so does not necessarily need to display it as a lexica= l representation string. Do we follow RFC7951 here as well? [TR] Let's not deviate from RFC7951 otherwise both drafts will end-up defin= ing it's our own set of rules for encoding the YANG configuration data as J= SON/CBOR text deviating from the existing standards. [Jon] Agreed I do not think that we should be following the augmented JSON parameter nam= ing in RFC7951 "4. Names and Namespaces" otherwise we will start ending up = with JSON/CBOR parameter names such as "ietf-dots-signal:mitigation-scope".= If we do go with this, then the CBOR mapping table will need to get exten= ded to cover the old, but some parameter name in different places. Comment= s? [TR] Both drafts should follow the naming in RFC7951. [Jon] I'm neutral on this, but agree to following standards - there will be= however a lot of long parameter names which fortunately will get compresse= d by the CBOR mapping. However, draft-ietf-netmod-acl-model (albeit in xml= not json) does not have parameter names such as "ietf-access-control-list:= access-lists" As we are working with YANG, JSON and CBOR interrelation , I still think we= need a table similar to below to aid implementers - referring as appropria= te to the different RFCs - no-one has full knowledge of all the evolving RF= Cs. [TR] I don't see the need to repeat, its already discussed in detail in htt= ps://tools.ietf.org/html/rfc8040#section-5.2 and similarly DOTS signal chan= nel draft already refers to draft-ietf-core-yang-cbor-05. [Jon] Given the number of times we have been inconsistent with the YANG / J= SON and CBOR definitions of a specific parameter, having a single place whe= re all 3 variants are on the same line certainly helps me as an implementer= . [TR1] I am trying to keep the CBOR mapping table simple (not too wide :)), = it can be updated to add YANG type. Why do we need the corresponding JSON t= ype and JSON examples in the table ? -Tiru Regards Jon From: Dots [mailto: dots-bounces@ietf.org] On= Behalf Of Konda, Tirumaleswar Reddy Sent: 23 December 2017 07:06 To: Jon Shallow; dots@ietf.org Subject: Re: [Dots] Signal CBOR / JSON Mapping We should just follow the CBOR Encoding of Data Modeled with YANG defined i= n https://tools.ietf.org/html/draft-ietf-core-yang-cbor-05 and JSON Encodin= g of Data Modeled with YANG defined in https://tools.ietf.org/html/rfc7951. -Tiru From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Jon Shallow Sent: Friday, December 22, 2017 10:41 PM To: dots@ietf.org Subject: [Dots] Signal CBOR / JSON Mapping Hi WG, There are a lot of YANG parameters that we are using that are defined as in= t64. JSON only safely supports up to 53 bits of precision. RFC 7493 2.2 Numbers An I-JSON sender cannot expect a receiver to treat an integer whose absolute value is greater than 9007199254740991 (i.e., that is outside the range [-(2**53)+1, (2**53)-1]) as an exact value. For applications that require the exact interchange of numbers with greater magnitude or precision, it is RECOMMENDED to encode them in JSON string values. This requires that the receiving program understand the intended semantic of the value. An example would be 64-bit integers, even though modern hardware can deal with them, because of the limited scope of JavaScript numbers. RFC7049 3.6 Numbers CBOR-based protocols should take into account that different language environments pose different restrictions on the range and precision of numbers that are representable. For example, the JavaScript number system treats all numbers as floating point, which may result in silent loss of precision in decoding integers with more than 53 significant bits. A protocol that uses numbers should define its expectations on the handling of non-trivial numbers in decoders and receiving applications. =3D=3D=3D=3D An option is to make all of these int64 decimal64 for the signal channel, b= ut that does not cover the 64 bit counters in the netmod-acl. However, as = the netmod-acl counters are also fed back via the mitigate status, we do no= t necessarily need to support the netmod-acl counters. If, however, we follow RFC 7493, in CBOR the data can be passed across as 6= 4 bits, and as the parameter is a CBOR mapping, we can know how to encode /= decode the JSON value as appropriate. However, RFC 7493 does not say whet= her this should be base64, base64url or numeric string representation (i.e.= "1234567890"). RFC7049 refers to bignum (major type 6, tag value 2 or 3) = should be encoded as base64url (4.1 Converting from CBOR to JSON) - but int= 64 can be held in CBOR as type 0 or 1. I prefer the numeric string representation as it is humanly easy to read an= d easy to convert into 64 bit integers. If we take this approach of using the parameter which is a CBOR mapping key= to key off how to encode / decode the JSON, I would suggest that we could = extend this to include IP addresses, Dates and client-identifiers (or their= possible new names of request-nonce and client-domain-hash) to further min= imize the actual number of bytes sent in a COAP packet. The CBOR mapping Table could then be extended to look something like (but i= t is too wide I think) /----------------------+-------------+------+---------------+--------+-----= ----\ | Parameter name | YANG type | CBOR | CBOR major | JSON | JSON= | | | | key | type | type | Exam= ple | |----------------------+-------------+------+---------------+--------+-----= ----| | mitigation-scope | grouping | 1 | 5 map | Object | = | | scope | list | 2 | 4 array | Array | = | | mitigation-id | int32 | 3 | 0 unsigned | Number | 5432= 1 | | acl-list | list | 4 | 4 array | Array | = | | target-port-range | list | 5 | 4 array | Array | = | | lower-port | port-number | 6 | 0 number | Number | 1111= | | upper-port | port-number | 7 | 0 number | Number | 1111= | | target-protocol | leaf-list | | 4 array | Array | = | | | uint8 | 8 | 0 number | Number | 6 = | | target-fqdn | leaf-list | | 4 array | Array | = | | | domain-name | 9 | 3 text string | String | "a.c= om" | | target-uri | leaf-list | | 4 array | Array | = | | | uri | 10 | 3 text string | String | = | | alias-name | leaf-list | | 4 array | Array | = | | | string | 11 | 3 text string | String | "web= " | | lifetime | int32 | 12 | 0 number | Number | = | | attack-status | enumeration | 13 | 0 number | Number | 1 = | | signal-config | grouping | 14 | 5 map | Object | = | | heartbeat-interval | grouping | 15 | 5 map | Object | = | | max-retransmit | grouping | 16 | 5 map | Object | = | | ack-timeout | grouping | 17 | 5 map | Object | = | | ack-random-factor | grouping | 18 | 5 map | Object | = | | min-value | int16 | 19 | 0 number | Number | 1 = | | max-value | int16 | 20 | 0 number | Number | 1 = | | status | enumeration | 21 | 0 number | Number | 1 = | | conflict-information | grouping | 22 | 5 map | Object | = | | conflict-status | enumeration | 23 | 0 number | Number | 1 = | | conflict-cause | enumeration | 24 | 0 number | Number | 1 = | | retry-timer | int32 | 25 | 0 number | Number | 1800= | | bytes-dropped | counter64 | 26 | 0 number | String | "123= 4" | | bps-dropped | counter64 | 27 | 0 number | String | "123= 4" | | pkts-dropped | counter64 | 28 | 0 number | String | "123= 4" | | pps-dropped | counter64 | 29 | 0 number | String | "123= 4" | | session-id | int32 | 30 | 0 number | Number | 6543= 2 | | trigger-mitigation | boolean | 31 | 7 simple | T / F | = | | missing-hb-allowed | grouping | 32 | 5 map | Object | = | | current-value | int16 | 33 | 0 number | Number | 10 = | | mitigation-start | decimal64 | 34 | 7 FP | Number | 10.2= 1 | | target-prefix | leaf-list | | 4 array | Array | = | | | ip-prefix | 35 | 3 text string | String | = | | client-domain-hash | leaf-list | | 4 array | Array | = | | | binary | 36 | 2 byte string | String | "abc= df" | | alt-server | string | 37 | 3 text string | String | = | | alt-server-record | list | 38 | 4 array | Array | = | | addr | string | 39 | 3 text string | String | = | | ttl | int32 | 40 | 0 number | Number | 1800= | | conflict-scope | grouping | 41 | 5 map | Object | = | | acl-name | string | 42 | 3 text string | String | "ana= me" | | acl-type | string | 43 | 3 text string | String | "ipv= 4" | | config-interval | int32 | 44 | 0 number | Number | 11 = | | mitigating-config | grouping | 45 | 5 map | Object | = | | idle-config | grouping | 46 | 5 map | Object | = | | request-nonce | binary | 47 | 2 byte string | String | "xxx= " | | min-value-decimal | decimal64 | 48 | 7 FP | Number | 1.1 = | | max-value-decimal | decimal64 | 49 | 7 FP | Number | 1.1 = | | current-value-decimal| decimal64 | 50 | 7 FP | Number | 1.1 = | \----------------------+-------------+------+---------------+--------+-----= ----/ Comments / suggestions? Regards Jon --_000_DM5PR16MB178860C403689689A7241807EA190DM5PR16MB1788namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Jon,

&nbs= p;

Please se= e inline [TR1]

 

From:<= /span> Jon Shallow [mailto:s= upjps-ietf@jpshallow.com]
Sent: Tuesday, January 2, 2018 4:05 PM
To: Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@McAfee.com= >; dots@ietf.org
Subject: RE: [Dots] Signal CBOR / JSON Mapping

 

Hi Tiru= ,

&n= bsp;

See inl= ine.

&n= bsp;

Regards=

&n= bsp;

Jon

&n= bsp;

From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of Konda, Tirumaleswar Reddy
Sent: 02 January 2018 09:43
To: Jon Shallow; dots@ietf.org
Subject: Re: [Dots] Signal CBOR / JSON Mapping

 

Hi Jon,

&nbs= p;

Please se= e inline

&nbs= p;

From:<= /span> Dots [mailto:dots-bounces@ietf.org] On Behalf Of Jon Shallow
Sent: Friday, December 29, 2017 2:32 AM
To: Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@McAfee.com>; dots@ietf.org
Subject: Re: [Dots] Signal CBOR / JSON Mapping

 

Hi Tiru= ,

&n= bsp;

Thanks = for pointing me to these references.

&n= bsp;

RFC7951=

6.1.&nb= sp; Numeric Types

&n= bsp;

 &= nbsp; A value of the "int8", "int16", "int32"= , "uint8", "uint16", or

 &= nbsp; "uint32" type is represented as a JSON number.

&n= bsp;

 &= nbsp; A value of the "int64", "uint64", or "decima= l64" type is represented

 &= nbsp; as a JSON string whose content is the lexical representation of the

 &= nbsp; corresponding YANG type as specified in Sections 9.2.1 and 9.3.1 of

 &= nbsp; [RFC7950].

&n= bsp;

 &= nbsp; For example, if the type of the leaf "foo" in Section 5.1 w= as

 &= nbsp; "uint64" instead of "uint8", the instance would h= ave to be encoded as

&n= bsp;

 &= nbsp; "foo": "123"

--=

&n= bsp;

So, we = now have a way of handling int64/uint64 which should be used moving forward= .

&n= bsp;

However= , my JSON implementation (as well as many others I suspect) natively suppor= ts decimal64, so does not necessarily need to display it as a lexical repre= sentation string.  Do we follow RFC7951 here as well?

 

[TR] Let’s not deviate fr= om RFC7951 otherwise both drafts will end-up defining it’s our own se= t of rules for encoding the YANG configuration data as JSON/CBOR text devia= ting from the existing standards.

[Jon] A= greed

&n= bsp;

I do no= t think that we should be following the augmented JSON parameter naming in = RFC7951 “4. Names and Namespaces” otherwise we will start endin= g up with JSON/CBOR parameter names such as “ietf-dots-signal:mitigat= ion-scope”.  If we do go with this, then the CBOR mapping table will need to get extend= ed to cover the old, but some parameter name in different places.  Com= ments?

 

[TR] Both drafts should follow = the naming in RFC7951.

[Jon] I= ’m neutral on this, but agree to following standards – there wi= ll be however a lot of long parameter names which fortunately will get comp= ressed by the CBOR mapping.  However, draft-ietf-netmod-acl-model (albeit in xml not json) does not have parameter names such as “ietf= -access-control-list:access-lists”

 

As we a= re working with YANG, JSON and CBOR interrelation , I still think we need a= table similar to below to aid implementers – referring as appropriat= e to the different RFCs – no-one has full knowledge of all the evolving RFCs.

 

[TR] I don’t see the need= to repeat, its already discussed in detail in https://tools.i= etf.org/html/rfc8040#section-5.2 and similarly DOTS signal channel draf= t already refers to draft-ietf-core-yang-cbor-05.

[Jon] G= iven the number of times we have been inconsistent with the YANG / JSON and= CBOR definitions of a specific parameter, having a single place where all = 3 variants are on the same line certainly helps me as an implementer.

 

[TR1] I am trying to keep the C= BOR mapping table simple (not too wide J), it can be updated to add YANG type. Why do we need the cor= responding JSON type and JSON examples in the table ?

 

-Tiru

 

Regards=

&n= bsp;

Jon

&n= bsp;

From: Dots [mailto: dots-bounces@ietf.org] On B= ehalf Of Konda, Tirumaleswar Reddy
Sent: 23 December 2017 07:06
To: Jon Shallow; dots@ietf.org<= br> Subject: Re: [Dots] Signal CBOR / JSON Mapping

 

We should= just follow the CBOR Encoding of Data Modeled with YANG defined in https:= //tools.ietf.org/html/draft-ietf-core-yang-cbor-05 and JSON Encoding of= Data Modeled with YANG

defined i= n https://tools.ietf.org/html/rfc7951.

&nbs= p;

-Tiru

&nbs= p;

From:<= /span> Dots [mailto:dots-bounces@ietf.org] On Behalf Of Jon Shallow
Sent: Friday, December 22, 2017 10:41 PM
To: dots@ietf.org
Subject: [Dots] Signal CBOR / JSON Mapping

 

Hi WG,

 

There are a lot of YANG paramet= ers that we are using that are defined as int64.  JSON only safely sup= ports up to 53 bits of precision.

 

RFC 7493 2.2 Numbers=

 

   An I-JSON sender c= annot expect a receiver to treat an integer whose

   absolute value is = greater than 9007199254740991 (i.e., that is

   outside the range = [-(2**53)+1, (2**53)-1]) as an exact value.

 

   For applications t= hat require the exact interchange of numbers with

   greater magnitude = or precision, it is RECOMMENDED to encode them in

   JSON string values= .  This requires that the receiving program

   understand the int= ended semantic of the value.  An example would be

   64-bit integers, e= ven though modern hardware can deal with them,

   because of the lim= ited scope of JavaScript numbers.

 

RFC7049 3.6 Numbers<= /span>

 

   CBOR-based protoco= ls should take into account that different language

   environments pose = different restrictions on the range and precision

   of numbers that ar= e representable.  For example, the JavaScript

   number system trea= ts all numbers as floating point, which may result

   in silent loss of = precision in decoding integers with more than 53

   significant bits.&= nbsp; A protocol that uses numbers should define its

   expectations on th= e handling of non-trivial numbers in decoders and

   receiving applicat= ions.

 

=3D=3D=3D=3D<= /p>

 

An option is to make all of the= se int64 decimal64 for the signal channel, but that does not cover the 64 b= it counters in the netmod-acl.  However, as the netmod-acl counters ar= e also fed back via the mitigate status, we do not necessarily need to support the netmod-acl counters.<= /span>

 

If, however, we follow RFC 7493= , in CBOR the data can be passed across as 64 bits, and as the parameter is= a CBOR mapping, we can know how to encode / decode the JSON value as appro= priate.  However, RFC 7493 does not say whether this should be base64, base64url or numeric string representat= ion (i.e. “1234567890”).  RFC7049 refers to bignum (major = type 6, tag value 2 or 3) should be encoded as base64url (4.1 Converting fr= om CBOR to JSON) – but int64 can be held in CBOR as type 0 or 1.

 

I prefer the numeric string rep= resentation as it is humanly easy to read and easy to convert into 64 bit i= ntegers.

 

If we take this approach of usi= ng the parameter which is a CBOR mapping key to key off how to encode / dec= ode the JSON, I would suggest that we could extend this to include IP addre= sses, Dates and client-identifiers (or their possible new names of request-nonce and client-domain-hash) to furth= er minimize the actual number of bytes sent in a COAP packet.

 

The CBOR mapping Table could th= en be extended to look something like (but it is too wide I think)

 

/----------------------+-------------= 3;------+---------------+--------+---------\<= /p>

| Parameter name    &nbs= p;  | YANG type   | CBOR | CBOR major    | JS= ON   | JSON    | 

|       &= nbsp;           &nbs= p;  |           = ;  | key  | type        &= nbsp; | type   | Example |

|----------------------+-------------= 3;------+---------------+--------+---------|<= /p>

| mitigation-scope     |= grouping    |   1  | 5 map   =       | Object |     &nbs= p;   | 

| scope      &= nbsp;         | list  &nb= sp;     |   2  | 4 array  &nbs= p;    | Array  |      &nb= sp;  | 

| mitigation-id     = ;   | int32       |   3&n= bsp; | 0 unsigned    | Number | 54321   | 

| acl-list     &nbs= p;       | list     =    |   4  | 4 array     &= nbsp; | Array  |         |&nbs= p;

| target-port-range    | list=         |   5  | 4 array&= nbsp;      | Array  |    =      | 

| lower-port     &n= bsp;     | port-number |   6  | 0 number=       | Number | 1111    | 

| upper-port     &n= bsp;     | port-number |   7  | 0 number=       | Number | 1111    | 

| target-protocol    &nb= sp; | leaf-list   |      | 4 array =       | Array  |     = ;    | 

|       &= nbsp;           &nbs= p;  | uint8       |   8  = | 0 number      | Number | 6   &nbs= p;   |

| target-fqdn     &= nbsp;    | leaf-list   |    &n= bsp; | 4 array       | Array  | &nb= sp;       |

|       &= nbsp;           &nbs= p;  | domain-name |   9  | 3 text string | String | &qu= ot;a.com" |

| target-uri     &n= bsp;     | leaf-list   |    &n= bsp; | 4 array       | Array  |&nbs= p;        | 

|       &= nbsp;           &nbs= p;  | uri         |  10&n= bsp; | 3 text string | String |       &n= bsp; |

| alias-name     &n= bsp;     | leaf-list   |    &n= bsp; | 4 array       | Array  | &nb= sp;       | 

|        =             &nb= sp; | string      |  11  | 3 text s= tring | String | "web"   | 

| lifetime     &nbs= p;       | int32     = ;  |  12  | 0 number      | Number = |         | 

| attack-status     = ;   | enumeration |  13  | 0 number   &n= bsp;  | Number | 1       | 

| signal-config     = ;   | grouping    |  14  | 5 map &n= bsp;       | Object |    =      | 

| heartbeat-interval   | grouping&= nbsp;   |  15  | 5 map     &nb= sp;   | Object |         = | 

| max-retransmit    &nbs= p;  | grouping    |  16  | 5 map  &= nbsp;      | Object |     = ;    | 

| ack-timeout     &= nbsp;    | grouping    |  17  | 5 m= ap         | Object |  &n= bsp;      | 

| ack-random-factor    | grou= ping    |  18  | 5 map    &nbs= p;    | Object |       &n= bsp; | 

| min-value      &n= bsp;     | int16     &nbs= p; |  19  | 0 number      | Number | 1&n= bsp;      | 

| max-value     &nb= sp;      | int16     &nbs= p; |  20  | 0 number      | Number | 1&n= bsp;      | 

| status      =          | enumeration |  21&n= bsp; | 0 number      | Number | 1   = ;    | 

| conflict-information | grouping  = ;  |  22  | 5 map       &= nbsp; | Object |         | 

| conflict-status    &nb= sp; | enumeration |  23  | 0 number     = | Number | 1       | 

| conflict-cause    &nbs= p;  | enumeration |  24  | 0 number    &= nbsp; | Number | 1       | 

| retry-timer     &= nbsp;    | int32       | = 25  | 0 number      | Number | 1800 &nb= sp;  | 

| bytes-dropped     = ;   | counter64   |  26  | 0 number &nbs= p;    | String | "1234"  | 

| bps-dropped     &= nbsp;    | counter64   |  27  | 0 number=       | String | "1234"  | 

| pkts-dropped     =     | counter64   |  28  | 0 number = ;     | String | "1234"  | 

| pps-dropped     &= nbsp;    | counter64   |  29  | 0 number=       | String | "1234"  | 

| session-id     &n= bsp;     | int32       |&= nbsp; 30  | 0 number      | Number | 65432&nb= sp;  | 

| trigger-mitigation   | boolean&n= bsp;    |  31  | 7 simple    &= nbsp; | T / F  |         |&nbs= p;

| missing-hb-allowed   | grouping&= nbsp;   |  32  | 5 map     &nb= sp;   | Object |         = | 

| current-value     = ;   | int16       |  33  = | 0 number      | Number | 10   &nb= sp;  | 

| mitigation-start     |= decimal64   |  34  | 7 FP     = ;     | Number | 10.21   | 

| target-prefix     = ;   | leaf-list   |      | 4 a= rray       | Array  |   &= nbsp;     | 

|        =             &nb= sp; | ip-prefix   |  35  | 3 text string | String = |         | 

| client-domain-hash   | leaf-list=    |      | 4 array   &nb= sp;   | Array  |       &n= bsp; |

|        =             &nb= sp; | binary      |  36  | 2 byte s= tring | String | "abcdf" |

| alt-server     &n= bsp;     | string      | = 37  | 3 text string | String |      &nb= sp;  | 

| alt-server-record    | list=         |  38  | 4 array =       | Array  |     = ;    | 

| addr      &n= bsp;          | string &n= bsp;    |  39  | 3 text string | String | &nb= sp;       | 

| ttl      &nb= sp;           | int32&nbs= p;      |  40  | 0 number  &nb= sp;   | Number | 1800    | 

| conflict-scope    &nbs= p;  | grouping    |  41  | 5 map  &= nbsp;      | Object |     = ;    | 

| acl-name     &nbs= p;       | string    &nbs= p; |  42  | 3 text string | String | "aname" | 

| acl-type     &nbs= p;       | string    &nbs= p; |  43  | 3 text string | String | "ipv4"  |&nbs= p;

| config-interval    &nb= sp; | int32       |  44  | 0 number=       | Number | 11      = | 

| mitigating-config    | grou= ping    |  45  | 5 map    &nbs= p;    | Object |       &n= bsp; | 

| idle-config     &= nbsp;    | grouping    |  46  | 5 m= ap         | Object |  &n= bsp;      | 

| request-nonce     = ;   | binary      |  47  | 2 b= yte string | String | "xxx"   | 

| min-value-decimal    | deci= mal64   |  48  | 7 FP     &nbs= p;    | Number | 1.1     | 

| max-value-decimal    | deci= mal64   |  49  | 7 FP     &nbs= p;    | Number | 1.1     | 

| current-value-decimal| decimal64 &nbs= p; |  50  | 7 FP        &= nbsp; | Number | 1.1     | 

\----------------------+-------------= 3;------+---------------+--------+---------/<= /p>

 

 

Comments / suggestions?

 

Regards

 

Jon

--_000_DM5PR16MB178860C403689689A7241807EA190DM5PR16MB1788namp_-- From nobody Tue Jan 2 03:43:21 2018 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 1E4B91275C5 for ; Tue, 2 Jan 2018 03:43:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 oTcCEHbrxEAv for ; Tue, 2 Jan 2018 03:43:18 -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 1449B126D05 for ; Tue, 2 Jan 2018 03:43:18 -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 1eWKyR-0006k6-8t; Tue, 02 Jan 2018 11:43:15 +0000 From: "Jon Shallow" To: "'Konda, Tirumaleswar Reddy'" , , "kaname nishizuka" References: <094801d3801e$f7ab01b0$e7010510$@jpshallow.com> <099601d38096$487c9410$d975bc30$@jpshallow.com> <0b7a01d383bb$aba5f720$02f1e560$@jpshallow.com> In-Reply-To: Date: Tue, 2 Jan 2018 11:43:13 -0000 Message-ID: <0b8501d383be$df5ec030$9e1c4090$@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: AQLSq4q/0bL2TF/Kn5VRXUOjWNcfvgJYRDCAAhO9FZgBoHWANAIl/Wr3An6e4NyhDJqnoA== Archived-At: Subject: Re: [Dots] [signal-channel-draft] CoAP libraries have problems with the DOTS spec 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, 02 Jan 2018 11:43:21 -0000 Hi all, See inline [Jon3] I've striped out a lot of .. "See inline" .. Regards Jon > > -----Original Message----- > > From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of kaname > > nishizuka > > Sent: 28 December 2017 10:02 > > To: dots@ietf.org > > Subject: [Dots] [signal-channel-draft] CoAP libraries have problems > > with the DOTS spec > > > > Hi, > > > > Last week, Jon and I did the second interoperability test based on > > the > > -13 version of the signal channel draft. > > We made significant improvements of each implementation. Several > > feedbacks to the WG have been made by Jon already. > > > > Based on the experience, I encountered the problems between CoAP > > libraries and the specification of the DOTS. > > > > 1. resource identification of GET methods. > > > > In signal channel spec, the target resource in GET method is > > identified in the BODY of the message, that is mitigation-id (and > client-identifier). > > However, CoAP libraries, at least we investigated, only see the > > Request URI, so it cannot locate the resource because it doesn't see > > the > BODY. > > > > So the question is, why does the DOTS spec use CoAP Body for > > resource identifier? > > > > [Jon] A very good question. I had just assumed that this was the > > way to do it, but had noted that this was not done when using HTTP etc. > > and so was different. See later comments > > > > Most of CoAP libraries only support request URI in CoAP GET/observe, > > which is the spec from RFC7252. > > https://tools.ietf.org/html/rfc7252 > > 5.8.1.GET > > The GET method retrieves a representation for the information that > > currently corresponds to the resource identified by the request URI. > > [Jon] RFC 7252 states also > > 5.10.1. Uri-Host, Uri-Port, Uri-Path, and Uri-Query > > > > The Uri-Host, Uri-Port, Uri-Path, and Uri-Query Options are used to > > specify the target resource of a request to a CoAP origin server. > > [Jon] So it looks like the target resource should only be in > > Uri-Path and/or Uri-Query. > > [Jon] In my CoAP Library, I have to define each individual resource > > (it does a lookup against a hash of the complete Uri to find whether > > the resource is known or not), so, when say mitigation-id=2 is > > added, I need to register the resource > > .well-known/dots/v1/mitigate/migration-is=2 with an associated > > handler. This is not difficult to do, but potentially could consume > > a lot > of DOTS server resources if many mitigations are active. > > [Jon] Doing it as a Query Option I think is my preference - Comments? > > [Jon] The same is true for GET signal configuration as well. > > Yes, will update draft to use Query option for GET method. > [Jon2] This works for me, but does not feel right when this is > extended for "PUT .../mitigate Query mitigation-id-2" to create the > mitigation-id. I think that the complete "resource" should be > specified for consistency and just leave the c=? as being the required valid Query option. PUT method does not need to convey the Query Option (for example please see https://tools.ietf.org/html/rfc7967#section-4.1.1, the resource is specified in the URI-path option itself). [Jon3] Agreed - and think that the full resource needs to be specified for the DELETE (need to fix my libcoap library to not respond with 4.04 if resource does not exist as per RFC7252) as well that the GET. However, "GET .../mitigate" should return all current mitigations if the mitigation-id is not specified in the Uri-Path.. [Jon3] The same is for configuration (GET, PUT & DELETE) - which then begs the question - do we really need "session-id" ? > > > > > [Jon1] I am now leaning towards doing it in the Uri-Path but still > > not > sure. > > The CoAP layer responds with a 4.04 with my CoAP library if the > > resource > > (Uri-Path) is unknown. > > [Jon1] We need to define the order in the path - e.g. > > client-identifier (or request-none etc. if that is accepted) then > > mitigation-id, so that resources are built consistently from a > > mitigation > request. > > Agreed. > [Jon2] then something similar to the above specifying ordering needs > to be put into the draft. Yes. > > > [Jon1] However doing this means we also need to include PUT and > > DELETE with the resource specified in the Uri-Path. My library then > > runs into a chicken and egg situation with PUT - the PUT is defining > > the new resource, but as the resource is not defined (yet) in the > > CoAP layer, it gets rejected with a > > 4.04 in the CoAP layer (as mentioned above). The way around this is > > to use POST to create new mitigation requests (and will respond with > > appropriate Location-Path to give the new UI) and PUT if we are > > refreshing > the resource. > > > > [Jon1] Thoughts? > > PUT can also be used to create a new resource, and the draft uses PUT > instead of POST because it is idempotent and during a volumetric DDoS > attack saturating the incoming link to the DOTS client, DOTS client > will most likely not receive the server-side responses. Is this an implementation bug ? > > [Jon2] I agree that it is a bug in the libcoap I am using > [https://github.com/obgm/libcoap]. RFC7252 5.8.3. PUT states "The PUT > method requests that the resource identified by the request URI be > updated or created". I can try to fix the library to keep on > stripping off the last UriPath and then doing a hash lookup on the sub > path until a match is found in the case of doing a PUT. It would then > (in my case - not needed in the > draft) be the responsibility of creating a new resource if needed in > the DOTS layer. Thanks. Cheers, Tiru > > -Tiru > > > > > 2. Confirmable vs NonConfirmable at Mitigation Request > > > > A CoAP library (dustin/go-coap) stops listening right after sending > > out the NonConfirmable message because NonConfirmable messages do > not > > require acknowledgements. > > > > [Jon] As there is a good chance during attack scenarios that > > responses may not be able to get back, it makes sense to me that > > these "GET > mitigation" > > requests are non-confirmable. Certainly "PUT mitigation" needs to > > be thought of as a one way signal. There are times that the client > > has to run "blind" during attack scenarios. > > [Jon]If they were confirmable, then the request will get sent > > multiple times to the DOTS server - which could be handled by the > > server, but then the confirmable responses would retried whilst > > sending back to the DOTS client and eventually retry timeout. A > > large scale attack could swamp a DOTS server with all the yet to be > > confirmed confirmable > responses. > > [Jon] As per RFC7252 "2.2. Request/Response Model", a response to a > > non- confirmable request is expected to be handled as in:- > > If a request is sent in a Non-confirmable message, then the response > > is sent using a new Non-confirmable message, although the server may > > instead send a Confirmable message. This type of exchange is > > illustrated in Figure 6. > > > > Client Server > > | | > > | NON [0x7a11] | > > | GET /temperature | > > | (Token 0x74) | > > +----------------->| > > | | > > | NON [0x23bc] | > > | 2.05 Content | > > | (Token 0x74) | > > | "22.5 C" | > > |<-----------------+ > > | | > > > > Figure 6: A Request and a Response Carried in Non-confirmable > > Messages [Jon] So I would expect > > any CoAP library to support this non-confirmation mechanism by > > receiving a new non- confirmable message. It would be the > > responsibility of the DOTS layer to associate the Tokens together to > > handle the responses with > the requests. > > [Jon] In addition, when Observe is enabled, the DOTS server will > > continue to generate non-confirmable messages with the same Token. > > Again, the DOTS client will need to know what to do with the Token > > (which could be to update things, or to send a RST if no more > > packets with the same Token should be sent. > > > > > > The spec of Confirmable message already have the retransmission > > mechanism, so using Confirmable message is an easier way to notice > > that the message has been lost during the attack time. > > > > [Jon] The DOTS client will know something is wrong as it will be > > seeing heartbeat issues. > > > > I'm afraid I'm missing some previous discussions we made on the ML > > and at the WG meeting, but we have a problem with the CoAP library > > regarding this spec. > > > > * At the -08 version of the signal channel draft, this change was made: > > DOTS mitigation request/response are marked as non-confirmable > messages. > > > > thank you, > > Kaname > > > > > > _______________________________________________ > > Dots mailing list > > Dots@ietf.org > > https://www.ietf.org/mailman/listinfo/dots > > > > _______________________________________________ > > Dots mailing list > > Dots@ietf.org > > https://www.ietf.org/mailman/listinfo/dots > > > > _______________________________________________ > > Dots mailing list > > Dots@ietf.org > > https://www.ietf.org/mailman/listinfo/dots > > _______________________________________________ > Dots mailing list > Dots@ietf.org > https://www.ietf.org/mailman/listinfo/dots _______________________________________________ Dots mailing list Dots@ietf.org https://www.ietf.org/mailman/listinfo/dots From nobody Tue Jan 2 04:31:39 2018 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 25DAA126D05 for ; Tue, 2 Jan 2018 04:31:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 bP4jvHgNQifK for ; Tue, 2 Jan 2018 04:31:34 -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 00F9A120725 for ; Tue, 2 Jan 2018 04:31:33 -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 1eWLjA-0006lz-6K; Tue, 02 Jan 2018 12:31:32 +0000 From: "Jon Shallow" To: "'Konda, Tirumaleswar Reddy'" , References: <073001d37b47$e6f27460$b4d75d20$@jpshallow.com> <094a01d3801f$20d94dd0$628be970$@jpshallow.com> <0b6101d383b5$48b29a20$da17ce60$@jpshallow.com> In-Reply-To: Date: Tue, 2 Jan 2018 12:31:30 -0000 Message-ID: <0b8d01d383c5$9e0e4e50$da2aeaf0$@jpshallow.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0B8E_01D383C5.9E133050" X-Mailer: Microsoft Outlook 14.0 Content-Language: en-gb Thread-Index: AQJTmGwWHKq+N1BT2oAOspP+fqvZXQF5x90cAibGkTgCTX2+CwJVOoraAgmqY9eiDez8cA== Archived-At: Subject: Re: [Dots] Signal CBOR / JSON Mapping 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, 02 Jan 2018 12:31:38 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0B8E_01D383C5.9E133050 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Tiru et al, See inline [Jon1]. Regards Jon From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Jon Shallow Sent: Friday, December 29, 2017 2:32 AM To: Konda, Tirumaleswar Reddy ; dots@ietf.org Subject: Re: [Dots] Signal CBOR / JSON Mapping Hi Tiru, Thanks for pointing me to these references. RFC7951 6.1. Numeric Types A value of the "int8", "int16", "int32", "uint8", "uint16", or "uint32" type is represented as a JSON number. A value of the "int64", "uint64", or "decimal64" type is represented as a JSON string whose content is the lexical representation of the corresponding YANG type as specified in Sections 9.2.1 and 9.3.1 of [RFC7950]. For example, if the type of the leaf "foo" in Section 5.1 was "uint64" instead of "uint8", the instance would have to be encoded as "foo": "123" -- So, we now have a way of handling int64/uint64 which should be used moving forward. However, my JSON implementation (as well as many others I suspect) natively supports decimal64, so does not necessarily need to display it as a lexical representation string. Do we follow RFC7951 here as well? [TR] Let's not deviate from RFC7951 otherwise both drafts will end-up defining it's our own set of rules for encoding the YANG configuration data as JSON/CBOR text deviating from the existing standards. [Jon] Agreed I do not think that we should be following the augmented JSON parameter naming in RFC7951 "4. Names and Namespaces" otherwise we will start ending up with JSON/CBOR parameter names such as "ietf-dots-signal:mitigation-scope". If we do go with this, then the CBOR mapping table will need to get extended to cover the old, but some parameter name in different places. Comments? [TR] Both drafts should follow the naming in RFC7951. [Jon] I'm neutral on this, but agree to following standards - there will be however a lot of long parameter names which fortunately will get compressed by the CBOR mapping. However, draft-ietf-netmod-acl-model (albeit in xml not json) does not have parameter names such as "ietf-access-control-list:access-lists" [Jon1] We really need to come to an agreement on this one. I think I prefer simpler names, but any program based YANG -> JSON translator following RFC7951 will come up with the long names.. However as I understand "A namespace-qualified member name MUST be used for all members of a top-level JSON object and then also whenever the namespaces of the data node and its parent node are different. In all other cases, the simple form of the member name MUST be used." This probably only means that "ietf-dots-signal:mitigation-scope", "ietf-acl:acl-name", "ietf-acl:acl-type" and "ietf-dots-signal:signal-config" are the changes (yes, acl-name & acl-type may be redefined in netconf-acl - do we really need acl-type?). As we are working with YANG, JSON and CBOR interrelation , I still think we need a table similar to below to aid implementers - referring as appropriate to the different RFCs - no-one has full knowledge of all the evolving RFCs. [TR] I don't see the need to repeat, its already discussed in detail in https://tools.ietf.org/html/rfc8040#section-5.2 and similarly DOTS signal channel draft already refers to draft-ietf-core-yang-cbor-05. [Jon] Given the number of times we have been inconsistent with the YANG / JSON and CBOR definitions of a specific parameter, having a single place where all 3 variants are on the same line certainly helps me as an implementer. [TR1] I am trying to keep the CBOR mapping table simple (not too wide J), it can be updated to add YANG type. Why do we need the corresponding JSON type and JSON examples in the table ? [Jon1] I agree that we have a 72 character width limit. I do not think we need the JSON examples column, but do think we need the JSON type so we have YANG, CBOR and JSON equivalent types in one place. However, if the parameter names get long -e.g. "ietf-dots-signal:mitigation-scope", we will run out of width unless they are split over 2 lines. [Jon1] NOTE. If we have to do changes to parameter names, this may be a suitable break point to re-sort the list by parameter name for ease of readability / lookup - especially if/as we are doing a lot of other fundamental changes post -14 with all the other discussions - time to clean things up! -Tiru Regards Jon From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of Konda, Tirumaleswar Reddy Sent: 23 December 2017 07:06 To: Jon Shallow; dots@ietf.org Subject: Re: [Dots] Signal CBOR / JSON Mapping We should just follow the CBOR Encoding of Data Modeled with YANG defined in https://tools.ietf.org/html/draft-ietf-core-yang-cbor-05 and JSON Encoding of Data Modeled with YANG defined in https://tools.ietf.org/html/rfc7951. -Tiru From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Jon Shallow Sent: Friday, December 22, 2017 10:41 PM To: dots@ietf.org Subject: [Dots] Signal CBOR / JSON Mapping Hi WG, There are a lot of YANG parameters that we are using that are defined as int64. JSON only safely supports up to 53 bits of precision. RFC 7493 2.2 Numbers An I-JSON sender cannot expect a receiver to treat an integer whose absolute value is greater than 9007199254740991 (i.e., that is outside the range [-(2**53)+1, (2**53)-1]) as an exact value. For applications that require the exact interchange of numbers with greater magnitude or precision, it is RECOMMENDED to encode them in JSON string values. This requires that the receiving program understand the intended semantic of the value. An example would be 64-bit integers, even though modern hardware can deal with them, because of the limited scope of JavaScript numbers. RFC7049 3.6 Numbers CBOR-based protocols should take into account that different language environments pose different restrictions on the range and precision of numbers that are representable. For example, the JavaScript number system treats all numbers as floating point, which may result in silent loss of precision in decoding integers with more than 53 significant bits. A protocol that uses numbers should define its expectations on the handling of non-trivial numbers in decoders and receiving applications. ==== An option is to make all of these int64 decimal64 for the signal channel, but that does not cover the 64 bit counters in the netmod-acl. However, as the netmod-acl counters are also fed back via the mitigate status, we do not necessarily need to support the netmod-acl counters. If, however, we follow RFC 7493, in CBOR the data can be passed across as 64 bits, and as the parameter is a CBOR mapping, we can know how to encode / decode the JSON value as appropriate. However, RFC 7493 does not say whether this should be base64, base64url or numeric string representation (i.e. "1234567890"). RFC7049 refers to bignum (major type 6, tag value 2 or 3) should be encoded as base64url (4.1 Converting from CBOR to JSON) - but int64 can be held in CBOR as type 0 or 1. I prefer the numeric string representation as it is humanly easy to read and easy to convert into 64 bit integers. If we take this approach of using the parameter which is a CBOR mapping key to key off how to encode / decode the JSON, I would suggest that we could extend this to include IP addresses, Dates and client-identifiers (or their possible new names of request-nonce and client-domain-hash) to further minimize the actual number of bytes sent in a COAP packet. The CBOR mapping Table could then be extended to look something like (but it is too wide I think) /----------------------+-------------+------+---------------+--------+------ ---\ | Parameter name | YANG type | CBOR | CBOR major | JSON | JSON | | | | key | type | type | Example | |----------------------+-------------+------+---------------+--------+------ ---| | mitigation-scope | grouping | 1 | 5 map | Object | | | scope | list | 2 | 4 array | Array | | | mitigation-id | int32 | 3 | 0 unsigned | Number | 54321 | | acl-list | list | 4 | 4 array | Array | | | target-port-range | list | 5 | 4 array | Array | | | lower-port | port-number | 6 | 0 number | Number | 1111 | | upper-port | port-number | 7 | 0 number | Number | 1111 | | target-protocol | leaf-list | | 4 array | Array | | | | uint8 | 8 | 0 number | Number | 6 | | target-fqdn | leaf-list | | 4 array | Array | | | | domain-name | 9 | 3 text string | String | "a.com" | | target-uri | leaf-list | | 4 array | Array | | | | uri | 10 | 3 text string | String | | | alias-name | leaf-list | | 4 array | Array | | | | string | 11 | 3 text string | String | "web" | | lifetime | int32 | 12 | 0 number | Number | | | attack-status | enumeration | 13 | 0 number | Number | 1 | | signal-config | grouping | 14 | 5 map | Object | | | heartbeat-interval | grouping | 15 | 5 map | Object | | | max-retransmit | grouping | 16 | 5 map | Object | | | ack-timeout | grouping | 17 | 5 map | Object | | | ack-random-factor | grouping | 18 | 5 map | Object | | | min-value | int16 | 19 | 0 number | Number | 1 | | max-value | int16 | 20 | 0 number | Number | 1 | | status | enumeration | 21 | 0 number | Number | 1 | | conflict-information | grouping | 22 | 5 map | Object | | | conflict-status | enumeration | 23 | 0 number | Number | 1 | | conflict-cause | enumeration | 24 | 0 number | Number | 1 | | retry-timer | int32 | 25 | 0 number | Number | 1800 | | bytes-dropped | counter64 | 26 | 0 number | String | "1234" | | bps-dropped | counter64 | 27 | 0 number | String | "1234" | | pkts-dropped | counter64 | 28 | 0 number | String | "1234" | | pps-dropped | counter64 | 29 | 0 number | String | "1234" | | session-id | int32 | 30 | 0 number | Number | 65432 | | trigger-mitigation | boolean | 31 | 7 simple | T / F | | | missing-hb-allowed | grouping | 32 | 5 map | Object | | | current-value | int16 | 33 | 0 number | Number | 10 | | mitigation-start | decimal64 | 34 | 7 FP | Number | 10.21 | | target-prefix | leaf-list | | 4 array | Array | | | | ip-prefix | 35 | 3 text string | String | | | client-domain-hash | leaf-list | | 4 array | Array | | | | binary | 36 | 2 byte string | String | "abcdf" | | alt-server | string | 37 | 3 text string | String | | | alt-server-record | list | 38 | 4 array | Array | | | addr | string | 39 | 3 text string | String | | | ttl | int32 | 40 | 0 number | Number | 1800 | | conflict-scope | grouping | 41 | 5 map | Object | | | acl-name | string | 42 | 3 text string | String | "aname" | | acl-type | string | 43 | 3 text string | String | "ipv4" | | config-interval | int32 | 44 | 0 number | Number | 11 | | mitigating-config | grouping | 45 | 5 map | Object | | | idle-config | grouping | 46 | 5 map | Object | | | request-nonce | binary | 47 | 2 byte string | String | "xxx" | | min-value-decimal | decimal64 | 48 | 7 FP | Number | 1.1 | | max-value-decimal | decimal64 | 49 | 7 FP | Number | 1.1 | | current-value-decimal| decimal64 | 50 | 7 FP | Number | 1.1 | \----------------------+-------------+------+---------------+--------+------ ---/ Comments / suggestions? Regards Jon ------=_NextPart_000_0B8E_01D383C5.9E133050 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Tiru et al,

 

See inline = [Jon1].

 

Regards

 

Jon

 

 

From: Dots [mailto:dots-bounces@ietf.org] = On Behalf Of Jon Shallow
Sent: Friday, December 29, = 2017 2:32 AM
To: Konda, Tirumaleswar Reddy <TirumaleswarReddy_Kond= a@McAfee.com>; dots@ietf.org
Subject: Re: = [Dots] Signal CBOR / JSON Mapping

 

Hi = Tiru,

 

Thanks for pointing me = to these references.

 

RFC7951

6.1.  Numeric = Types

 

   A value of = the "int8", "int16", "int32", = "uint8", "uint16", or

   = "uint32" type is represented as a JSON = number.

 

   A value of = the "int64", "uint64", or "decimal64" type = is represented

   as a JSON string whose content is = the lexical representation of the

   = corresponding YANG type as specified in Sections 9.2.1 and 9.3.1 = of

   [RFC7950].

 

   For = example, if the type of the leaf "foo" in Section 5.1 = was

   "uint64" instead of = "uint8", the instance would have to be encoded = as

 

   = "foo": "123"

--

 

So, we now have a way of = handling int64/uint64 which should be used moving = forward.

 

However, my JSON = implementation (as well as many others I suspect) natively supports = decimal64, so does not necessarily need to display it as a lexical = representation string.  Do we follow RFC7951 here as = well?

 

[TR] Let’s not deviate from RFC7951 otherwise = both drafts will end-up defining it’s our own set of rules for = encoding the YANG configuration data as JSON/CBOR text deviating from = the existing standards.

[Jon] Agreed

 

I do not think that we = should be following the augmented JSON parameter naming in RFC7951 = “4. Names and Namespaces” otherwise we will start ending up = with JSON/CBOR parameter names such as = “ietf-dots-signal:mitigation-scope”.  If we do go with = this, then the CBOR mapping table will need to get extended to cover the = old, but some parameter name in different places.  = Comments?

 

[TR] Both = drafts should follow the naming in RFC7951.

[Jon] I’m neutral on this, but agree to = following standards – there will be however a lot of long = parameter names which fortunately will get compressed by the CBOR = mapping.  However, draft-ietf-netmod-acl-model (albeit in xml not = json) does not have parameter names such as = “ietf-access-control-list:access-lists”

=

[Jon1] We really need = to come to an agreement on this one.  I think I prefer simpler = names, but any program based YANG -> JSON translator following = RFC7951 will come up with the long names….  However as I = understand

“A = namespace-qualified member name MUST be used for all members of = a

   = top-level JSON object and then also whenever the namespaces of = the

   = data node and its parent node are different.  In all other cases, = the

   simple form of the member name MUST = be used.”

This probably only means that “ietf-dots-signal:mitigation-scope”, = “ietf-acl:acl-name”, “ietf-acl:acl-type” and = “ietf-dots-signal:signal-config” are the changes (yes, = acl-name & acl-type may be redefined in netconf-acl – do we = really need acl-type?).

 

As we are working with YANG, JSON and CBOR = interrelation , I still think we need a table similar to below to aid = implementers – referring as appropriate to the different RFCs = – no-one has full knowledge of all the evolving RFCs. =

 

[TR] I don’t see the need to repeat, its already = discussed in detail in https://tools.ie= tf.org/html/rfc8040#section-5.2 and similarly DOTS signal channel = draft already refers to draft-ietf-core-yang-cbor-05.

[Jon] Given the number = of times we have been inconsistent with the YANG / JSON and CBOR = definitions of a specific parameter, having a single place where all 3 = variants are on the same line certainly helps me as an = implementer.

 

[TR1] I am = trying to keep the CBOR mapping table simple (not too wide J), it can be updated to add YANG = type. Why do we need the corresponding JSON type and JSON examples in = the table ?

[Jon1] I agree that we have a 72 character width = limit.  I do not think we need the JSON examples column, but do = think we need the JSON type so we have YANG, CBOR and JSON equivalent = types in one place.  However, if the parameter names get long = –e.g. “ietf-dots-signal:mitigation-scope”, = we will run out of width unless they are split over 2 = lines.

[Jon1] NOTE.  If we have to do changes to = parameter names, this may be a suitable break point to re-sort the list = by parameter name for ease of readability / lookup – especially = if/as we are doing a lot of other fundamental changes post -14 with all = the other discussions – time to clean things up!

 

-Tiru

 

Regards

 

Jon

 

From: Dots [mailto: dots-bounces@ietf.org] On = Behalf Of Konda, Tirumaleswar Reddy
Sent: 23 December 2017 = 07:06
To: Jon Shallow; dots@ietf.org
Subject: Re: = [Dots] Signal CBOR / JSON Mapping

 

We should just follow = the CBOR Encoding of Data Modeled with YANG defined in https:/= /tools.ietf.org/html/draft-ietf-core-yang-cbor-05 and JSON Encoding = of Data Modeled with YANG

defined in https://tools.ietf.org/html/= rfc7951.

 

-Tiru

 

From: Dots [mailto:dots-bounces@ietf.org] = On Behalf Of Jon Shallow
Sent: Friday, December 22, = 2017 10:41 PM
To: dots@ietf.org
Subject: = [Dots] Signal CBOR / JSON Mapping

 

Hi WG,

 

There are a = lot of YANG parameters that we are using that are defined as = int64.  JSON only safely supports up to 53 bits of = precision.

 

RFC 7493 2.2 Numbers

 

   = An I-JSON sender cannot expect a receiver to treat an integer = whose

   absolute value is = greater than 9007199254740991 (i.e., that is

   outside the range [-(2**53)+1, = (2**53)-1]) as an exact value.

 

   = For applications that require the exact interchange of numbers = with

   greater magnitude = or precision, it is RECOMMENDED to encode them in

   JSON string values.  This requires = that the receiving program

   understand the intended semantic of the = value.  An example would be

   64-bit integers, even though modern = hardware can deal with them,

   because of the limited scope of = JavaScript numbers.

 

RFC7049 3.6 = Numbers

 

   CBOR-based protocols should take into = account that different language

   environments pose different restrictions = on the range and precision

   of numbers that are representable.  = For example, the JavaScript

   number system treats all numbers as = floating point, which may result

   in silent loss of precision in decoding = integers with more than 53

   significant bits.  A protocol that = uses numbers should define its

   expectations on the handling of = non-trivial numbers in decoders and

   receiving applications.

 

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

 

An option is = to make all of these int64 decimal64 for the signal channel, but that = does not cover the 64 bit counters in the netmod-acl.  However, as = the netmod-acl counters are also fed back via the mitigate status, we do = not necessarily need to support the netmod-acl = counters.

 

If, however, we follow RFC 7493, in CBOR the data can = be passed across as 64 bits, and as the parameter is a CBOR mapping, we = can know how to encode / decode the JSON value as appropriate.  = However, RFC 7493 does not say whether this should be base64, base64url = or numeric string representation (i.e. “1234567890”). =  RFC7049 refers to bignum (major type 6, tag value 2 or 3) should = be encoded as base64url (4.1 Converting from CBOR to JSON) – but = int64 can be held in CBOR as type 0 or 1.

 

I prefer the = numeric string representation as it is humanly easy to read and easy to = convert into 64 bit integers.

 

If we take = this approach of using the parameter which is a CBOR mapping key to key = off how to encode / decode the JSON, I would suggest that we could = extend this to include IP addresses, Dates and client-identifiers (or = their possible new names of request-nonce and client-domain-hash) to = further minimize the actual number of bytes sent in a COAP = packet.

 

The CBOR mapping Table could then be extended to look = something like (but it is too wide I think)

 

/----------------------+-------------+------+--------------= -+--------+---------\

| Parameter = name       | YANG type   | CBOR = | CBOR major    | JSON   | = JSON    | 

|         &nbs= p;            = |            = | key  | = type          | = type   | Example |

|----------------------+-------------+------+--------------= -+--------+---------|

| = mitigation-scope     | grouping    = |   1  | 5 = map         | Object = |         |  =

| = scope           &n= bsp;    | list        = |   2  | 4 array       | = Array  |         |  =

| = mitigation-id        | = int32       |   3  | 0 = unsigned    | Number | 54321   |  =

| = acl-list        =      | = list        |   4  | 4 = array       | Array  = |         |  =

| = target-port-range    | = list        |   5  | 4 = array       | Array  = |         |  =

| = lower-port           | = port-number |   6  | 0 = number      | Number | 1111    = | 

| = upper-port           | = port-number |   7  | 0 = number      | Number | 1111    = | 

| = target-protocol      | leaf-list   = |      | 4 = array       | Array  = |         |  =

|         &nbs= p;            | = uint8       |   8  | 0 = number      | Number | = 6       |

| = target-fqdn          | = leaf-list   |      | 4 = array       | Array  = |         = |

|         &nbs= p;            | = domain-name |   9  | 3 text string | String | = "a.com" |

| = target-uri           | = leaf-list   |      | 4 = array       | Array  = |         |  =

|         &nbs= p;            | = uri         |  10  | 3 = text string | String |         = |

| = alias-name           | = leaf-list   |      | 4 = array       | Array  | =         |  =

| =             &= nbsp;        | = string      |  11  | 3 text string | = String | "web"   | 

| = lifetime           = ;  | int32       |  12  | 0 = number      | Number = |         |  =

| = attack-status        | enumeration = |  13  | 0 number      | Number | = 1       | 

| signal-config        = | grouping    |  14  | 5 = map         | Object = |         |  =

| = heartbeat-interval   | grouping    |  = 15  | 5 map         | = Object |         |  =

| = max-retransmit       | = grouping    |  16  | 5 = map         | Object = |         |  =

| = ack-timeout          | = grouping    |  17  | 5 = map         | Object = |         |  =

| = ack-random-factor    | grouping    |  = 18  | 5 map         | = Object |         |  =

| = min-value   =          | = int16       |  19  | 0 = number      | Number | = 1       | 

| = max-value          &nbs= p; | int16       |  20  | 0 = number      | Number | = 1       | 

| = status           &= nbsp;   | enumeration |  21  | 0 = number      | Number | = 1       | 

| conflict-information | grouping    = |  22  | 5 map         = | Object |         |  =

| = conflict-status      | enumeration |  = 23  | 0 number      | Number | = 1       | 

| conflict-cause       | = enumeration |  24  | 0 number      | = Number | 1       |  =

| = retry-timer          | = int32       |  25  | 0 = number      | Number | 1800    = | 

| = bytes-dropped        | = counter64   |  26  | 0 = number      | String | "1234"  = | 

| = bps-dropped          | = counter64   |  27  | 0 = number      | String | "1234"  = | 

| = pkts-dropped         | counter64 =   |  28  | 0 number      | = String | "1234"  | 

| = pps-dropped          | = counter64   |  29  | 0 = number      | String | "1234"  = | 

| = session-id           | = int32       |  30  | 0 = number      | Number | 65432   = | 

| = trigger-mitigation   | boolean     |  = 31  | 7 simple      | T / F  = |         |  =

| = missing-hb-allowed   | grouping    |  = 32  | 5 map         | = Object |         |  =

| = current-value        | = int16       |  33  | 0 = number      | Number | = 10      | 

| mitigation-start     | = decimal64   |  34  | 7 = FP          | Number | = 10.21   | 

| target-prefix        = | leaf-list   |      | 4 = array       | Array  = |         |  =

| =             &= nbsp;        | = ip-prefix   |  35  | 3 text string | String = |         |  =

| = client-domain-hash   | leaf-list   |  =     | 4 array       | = Array  |         = |

| =             &= nbsp;        | = binary      |  36  | 2 byte string | = String | "abcdf" |

| = alt-server           | = string      |  37  | 3 text string | = String |         |  =

| = alt-server-record    | = list        |  38  | 4 = array       | Array  = |         |  =

| = addr           &nb= sp;     | string      = |  39  | 3 text string | String = |         |  =

| = ttl           &nbs= p;      | = int32       |  40  | 0 = number      | Number | 1800    = | 

| = conflict-scope       | = grouping    |  41  | 5 = map         | Object = |         |  =

| = acl-name           = ;  | string      |  42  | 3 text = string | String | "aname" | 

| = acl-type           = ;  | string      |  43  | 3 text = string | String | "ipv4"  |  =

| = config-interval      | = int32       |  44  | 0 = number      | Number | = 11      | 

| mitigating-config    | = grouping    |  45  | 5 = map         | Object = |         |  =

| = idle-config          | = grouping    |  46  | 5 = map         | Object = |         |  =

| = request-nonce        | = binary      |  47  | 2 byte string | = String | "xxx"   | 

| min-value-decimal    | = decimal64   |  48  | 7 = FP          | Number | = 1.1     | 

| max-value-decimal    | = decimal64   |  49  | 7 = FP          | Number | = 1.1     | 

| current-value-decimal| decimal64   |  = 50  | 7 FP          | = Number | 1.1     | 

\----------------------+-------------+------+--------------= -+--------+---------/

 

 

Comments / = suggestions?

 

Regards

 

Jon

------=_NextPart_000_0B8E_01D383C5.9E133050-- From nobody Tue Jan 2 04:53:40 2018 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 DAFED1241F3 for ; Tue, 2 Jan 2018 04:53:39 -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 lHWUlfel1I2s for ; Tue, 2 Jan 2018 04:53:38 -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 1011A120725 for ; Tue, 2 Jan 2018 04:53:37 -0800 (PST) Received: from delp.sei.cmu.edu (delp.sei.cmu.edu [10.64.21.31]) by veto.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id w02Craii010633 for ; Tue, 2 Jan 2018 07:53:36 -0500 DKIM-Filter: OpenDKIM Filter v2.11.0 veto.sei.cmu.edu w02Craii010633 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cert.org; s=yc2bmwvrj62m; t=1514897616; bh=jB9a1Cl6q3ZWUOJWuuf/6mhS9r2X0oZUsW5XA+OskoY=; h=From:To:Subject:Date:From; b=S1if4jQYzlJCCARj9DQYKee+0G56pymTNslGV8ha0RbAvxOLQTsf0gUMn2mp5R40y 5rekUv910YNs0kp5eF7Lwr8gy7fqla654PtD/GsozvyvRBJ9slosN0G/3OFtOqBxK6 JB4Rc6wIaZoQ2+E3L9+C87NYLkw1FRW49YCzVj0I= Received: from CASSINA.ad.sei.cmu.edu (cassina.ad.sei.cmu.edu [10.64.28.249]) by delp.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id w02CrTxq034310 for ; Tue, 2 Jan 2018 07:53:29 -0500 Received: from MARATHON.ad.sei.cmu.edu ([10.64.28.250]) by CASSINA.ad.sei.cmu.edu ([10.64.28.249]) with mapi id 14.03.0361.001; Tue, 2 Jan 2018 07:53:29 -0500 From: Roman Danyliw To: "dots@ietf.org" Thread-Topic: REMINDER -- WGLC on DOTS Requirements Thread-Index: AdODyALhnnAGTGsSQxOgc1tiV4V/lw== Date: Tue, 2 Jan 2018 12:53:28 +0000 Message-ID: <359EC4B99E040048A7131E0F4E113AFC0131355A04@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] REMINDER -- WGLC on DOTS 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: Tue, 02 Jan 2018 12:53:40 -0000 Hello! Happy New Year! The WGLC for the DOTS requirements draft will be closing s= oon. Please provide any final comments. Thanks, Roman -----Original Message----- From: Roman Danyliw=20 Sent: Thursday, December 7, 2017 3:51 PM To: dots@ietf.org Subject: WGLC on DOTS Requirements Hello! Consistent with our discussion at the Singapore meeting and with the concur= rence of the draft authors, we are starting a working group last call (WGLC= ) for the DOTS Requirements draft: Distributed Denial of Service (DDoS) Open Threat Signaling Requirements draft-ietf-dots-requirements-08 https://tools.ietf.org/html/draft-ietf-dots-requirements-08 Please send all comments to the DOTS mailing list. This WGLC will end on January 2, 2018 (~3 weeks to account for end-of-the-c= alendar year vacations). Thanks, Roman From nobody Tue Jan 2 05:29:42 2018 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 E93FE1274D2 for ; Tue, 2 Jan 2018 05:29:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.331 X-Spam-Level: X-Spam-Status: No, score=-4.331 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, T_RP_MATCHES_RCVD=-0.01] 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 B5dTBSYDxcZA for ; Tue, 2 Jan 2018 05:29:37 -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 C1C6B127011 for ; Tue, 2 Jan 2018 05:29: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=1514899769; 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: x-microsoft-antispam-message-info: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=nF35FwI0vH3X2ZhNuzozudHpJaDEUMLfoCYX98 VVkTI=; b=PxMFNwKNdreDfg3E+agW4mKZR6YlF2WRmrX2/ThQ Qpl9TZv19Fsn/OMxyDfnjz8AXd+yDjfKsJn526+WsCK1Q1mMYB Qc6xVVSJ5cQOTka8+WlCYSm+dji7Ptng9N/DLnVq8SuY6jpX7Q ZFfEggvV2r18X833nIgFvk2xuFVNEVY= Received: from DNVEXAPP1N06.corpzone.internalzone.com (unknown [10.44.48.90]) by DNVWSMAILOUT1.mcafee.com with smtp (TLS: TLSv1/SSLv3,256bits,ECDHE-RSA-AES256-SHA384) id 0d37_8d66_2c17ac6e_26f3_4613_a200_77fe9ef5495c; Tue, 02 Jan 2018 07:29:28 -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; Tue, 2 Jan 2018 06:29:24 -0700 Received: from DNVEXAPP1N06.corpzone.internalzone.com (10.44.48.90) by DNVEXUSR1N09.corpzone.internalzone.com (10.44.48.82) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Tue, 2 Jan 2018 06:29:23 -0700 Received: from DNVO365EDGE1.corpzone.internalzone.com (10.44.176.66) by DNVEXAPP1N06.corpzone.internalzone.com (10.44.48.90) with Microsoft SMTP Server (TLS) id 15.0.1347.2 via Frontend Transport; Tue, 2 Jan 2018 06:29:23 -0700 Received: from NAM01-BN3-obe.outbound.protection.outlook.com (10.44.176.242) by edge.mcafee.com (10.44.176.66) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Tue, 2 Jan 2018 06:29:22 -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.366.8; Tue, 2 Jan 2018 13:29:21 +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.0366.009; Tue, 2 Jan 2018 13:29:21 +0000 From: "Konda, Tirumaleswar Reddy" To: Jon Shallow , "dots@ietf.org" , kaname nishizuka Thread-Topic: [Dots] [signal-channel-draft] CoAP libraries have problems with the DOTS spec Thread-Index: AQHTf8LysSrBqL8kXEaeN1Zbh0iz4KNZPmiAgADuooCABjh4gIAAEk4AgAAA90CAAAVwgIAAG7Xw Date: Tue, 2 Jan 2018 13:29:20 +0000 Message-ID: References: <094801d3801e$f7ab01b0$e7010510$@jpshallow.com> <099601d38096$487c9410$d975bc30$@jpshallow.com> <0b7a01d383bb$aba5f720$02f1e560$@jpshallow.com> <0b8501d383be$df5ec030$9e1c4090$@jpshallow.com> In-Reply-To: <0b8501d383be$df5ec030$9e1c4090$@jpshallow.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [122.172.72.75] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DM5PR16MB1788; 7:fqVE08ug3Pqvjb472Qpwc6yLlcV9uPvq0nz0YiIA1SW1eLKMZQJUt4LrlGJpDtoY43RTeK8LP4IsrIX6ei/j5nFcYcGigws3Agh0nYlnzb4y2V5ZiX7Nx0AwWUdvHf7YKoU0Dz1OLHlurAwCPDS/vfPIj1Gkmny3YCX/I3wqrgeNHtgGLKsRI0KT/UeXwrlekl0Y0VBdvIXlVe/vFd4J0nKYq3nEJ/PuGBffF2b4JNLXydCWHea9IE90XSBSok95 x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 22e03a5b-eefa-4f19-bc27-08d551e4d504 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(5600026)(4604075)(3008032)(2017052603307)(7153060); SRVR:DM5PR16MB1788; x-ms-traffictypediagnostic: DM5PR16MB1788: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(190756311086443)(158342451672863)(166708455590820)(123452027830198); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040470)(2401047)(5005006)(8121501046)(10201501046)(93006095)(93001095)(3231023)(944501075)(3002001)(6041268)(20161123558120)(20161123564045)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123562045)(6072148)(201708071742011); SRVR:DM5PR16MB1788; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:DM5PR16MB1788; x-forefront-prvs: 0540846A1D x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(396003)(39860400002)(366004)(376002)(346002)(39380400002)(51444003)(13464003)(199004)(189003)(53754006)(32952001)(230783001)(86362001)(9686003)(72206003)(2950100002)(6306002)(6116002)(966005)(478600001)(3846002)(8936002)(5660300001)(74316002)(316002)(7736002)(93886005)(3280700002)(110136005)(2501003)(3660700001)(2900100001)(106356001)(105586002)(66066001)(14454004)(229853002)(99286004)(80792005)(81156014)(68736007)(81166006)(59450400001)(305945005)(102836004)(97736004)(6506007)(2906002)(53936002)(6246003)(33656002)(53546011)(7696005)(76176011)(8676002)(6436002)(25786009)(55016002)(77096006)(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; x-microsoft-antispam-message-info: qPgqJ4Nlnb6bNb2yoxbgU+OR47aRxT7JwvG4tCJvBhtl3FVnZyFzVsUSRF8Za25BR/fd47OeuBbnTTMF6iLEvQ== 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: 22e03a5b-eefa-4f19-bc27-08d551e4d504 X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Jan 2018 13:29:21.0106 (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 <6191> : inlines <6292> : streams <1774890> : uri <2561774> Archived-At: Subject: Re: [Dots] [signal-channel-draft] CoAP libraries have problems with the DOTS spec 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, 02 Jan 2018 13:29:40 -0000 Hi Jon, Please see inline > -----Original Message----- > From: Jon Shallow [mailto:supjps-ietf@jpshallow.com] > Sent: Tuesday, January 2, 2018 5:13 PM > To: Konda, Tirumaleswar Reddy > ; dots@ietf.org; kaname > nishizuka > Subject: RE: [Dots] [signal-channel-draft] CoAP libraries have problems w= ith > the DOTS spec >=20 > Hi all, >=20 > See inline [Jon3] >=20 > I've striped out a lot of .. "See inline" .. >=20 > Regards >=20 > Jon >=20 > > > -----Original Message----- > > > From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of kaname > > > nishizuka > > > Sent: 28 December 2017 10:02 > > > To: dots@ietf.org > > > Subject: [Dots] [signal-channel-draft] CoAP libraries have problems > > > with the DOTS spec > > > > > > Hi, > > > > > > Last week, Jon and I did the second interoperability test based on > > > the > > > -13 version of the signal channel draft. > > > We made significant improvements of each implementation. Several > > > feedbacks to the WG have been made by Jon already. > > > > > > Based on the experience, I encountered the problems between CoAP > > > libraries and the specification of the DOTS. > > > > > > 1. resource identification of GET methods. > > > > > > In signal channel spec, the target resource in GET method is > > > identified in the BODY of the message, that is mitigation-id (and > > client-identifier). > > > However, CoAP libraries, at least we investigated, only see the > > > Request URI, so it cannot locate the resource because it doesn't see > > > the > > BODY. > > > > > > So the question is, why does the DOTS spec use CoAP Body for > > > resource identifier? > > > > > > [Jon] A very good question. I had just assumed that this was the > > > way to do it, but had noted that this was not done when using HTTP et= c. > > > and so was different. See later comments > > > > > > Most of CoAP libraries only support request URI in CoAP GET/observe, > > > which is the spec from RFC7252. > > > https://tools.ietf.org/html/rfc7252 > > > 5.8.1.GET > > > The GET method retrieves a representation for the information that > > > currently corresponds to the resource identified by the request UR= I. > > > [Jon] RFC 7252 states also > > > 5.10.1. Uri-Host, Uri-Port, Uri-Path, and Uri-Query > > > > > > The Uri-Host, Uri-Port, Uri-Path, and Uri-Query Options are used t= o > > > specify the target resource of a request to a CoAP origin server. > > > [Jon] So it looks like the target resource should only be in > > > Uri-Path and/or Uri-Query. > > > [Jon] In my CoAP Library, I have to define each individual resource > > > (it does a lookup against a hash of the complete Uri to find whether > > > the resource is known or not), so, when say mitigation-id=3D2 is > > > added, I need to register the resource > > > .well-known/dots/v1/mitigate/migration-is=3D2 with an associated > > > handler. This is not difficult to do, but potentially could consume > > > a lot > > of DOTS server resources if many mitigations are active. > > > [Jon] Doing it as a Query Option I think is my preference - Comments? > > > [Jon] The same is true for GET signal configuration as well. > > > > Yes, will update draft to use Query option for GET method. > > [Jon2] This works for me, but does not feel right when this is > > extended for "PUT .../mitigate Query mitigation-id-2" to create the > > mitigation-id. I think that the complete "resource" should be > > specified for consistency and just leave the c=3D? as being the require= d > valid Query option. >=20 > PUT method does not need to convey the Query Option (for example please > see https://tools.ietf.org/html/rfc7967#section-4.1.1, the resource is > specified in the URI-path option itself). >=20 > [Jon3] Agreed - and think that the full resource needs to be specified f= or the > DELETE (need to fix my libcoap library to not respond with 4.04 if resour= ce > does not exist as per RFC7252) as well that the GET. However, > "GET .../mitigate" should return all current mitigations if the mitigatio= n-id is > not specified in the Uri-Path.. Yes.=20 >=20 > [Jon3] The same is for configuration (GET, PUT & DELETE) - which then beg= s > the question - do we really need "session-id" ? session-id is introduced to handle out-of-order delivery of PUT requests, t= he PUT request with a higher numeric 'session-id' value overrides the DOTS signal channel session configuration data installed by a PUT request with a lower numeric 'session-id' value. -Tiru >=20 > > > > > > > > [Jon1] I am now leaning towards doing it in the Uri-Path but still > > > not > > sure. > > > The CoAP layer responds with a 4.04 with my CoAP library if the > > > resource > > > (Uri-Path) is unknown. > > > [Jon1] We need to define the order in the path - e.g. > > > client-identifier (or request-none etc. if that is accepted) then > > > mitigation-id, so that resources are built consistently from a > > > mitigation > > request. > > > > Agreed. > > [Jon2] then something similar to the above specifying ordering needs > > to be put into the draft. >=20 > Yes. >=20 > > > > > [Jon1] However doing this means we also need to include PUT and > > > DELETE with the resource specified in the Uri-Path. My library then > > > runs into a chicken and egg situation with PUT - the PUT is defining > > > the new resource, but as the resource is not defined (yet) in the > > > CoAP layer, it gets rejected with a > > > 4.04 in the CoAP layer (as mentioned above). The way around this is > > > to use POST to create new mitigation requests (and will respond with > > > appropriate Location-Path to give the new UI) and PUT if we are > > > refreshing > > the resource. > > > > > > [Jon1] Thoughts? > > > > PUT can also be used to create a new resource, and the draft uses PUT > > instead of POST because it is idempotent and during a volumetric DDoS > > attack saturating the incoming link to the DOTS client, DOTS client > > will most likely not receive the server-side responses. Is this an > implementation bug ? > > > > [Jon2] I agree that it is a bug in the libcoap I am using > > [https://github.com/obgm/libcoap]. RFC7252 5.8.3. PUT states "The PUT > > method requests that the resource identified by the request URI be > > updated or created". I can try to fix the library to keep on > > stripping off the last UriPath and then doing a hash lookup on the sub > > path until a match is found in the case of doing a PUT. It would then > > (in my case - not needed in the > > draft) be the responsibility of creating a new resource if needed in > > the DOTS layer. >=20 > Thanks. >=20 > Cheers, > Tiru >=20 > > > > -Tiru > > > > > > > > 2. Confirmable vs NonConfirmable at Mitigation Request > > > > > > A CoAP library (dustin/go-coap) stops listening right after sending > > > out the NonConfirmable message because NonConfirmable messages do > > not > > > require acknowledgements. > > > > > > [Jon] As there is a good chance during attack scenarios that > > > responses may not be able to get back, it makes sense to me that > > > these "GET > > mitigation" > > > requests are non-confirmable. Certainly "PUT mitigation" needs to > > > be thought of as a one way signal. There are times that the client > > > has to run "blind" during attack scenarios. > > > [Jon]If they were confirmable, then the request will get sent > > > multiple times to the DOTS server - which could be handled by the > > > server, but then the confirmable responses would retried whilst > > > sending back to the DOTS client and eventually retry timeout. A > > > large scale attack could swamp a DOTS server with all the yet to be > > > confirmed confirmable > > responses. > > > [Jon] As per RFC7252 "2.2. Request/Response Model", a response to a > > > non- confirmable request is expected to be handled as in:- > > > If a request is sent in a Non-confirmable message, then the respon= se > > > is sent using a new Non-confirmable message, although the server m= ay > > > instead send a Confirmable message. This type of exchange is > > > illustrated in Figure 6. > > > > > > Client Server > > > | | > > > | NON [0x7a11] | > > > | GET /temperature | > > > | (Token 0x74) | > > > +----------------->| > > > | | > > > | NON [0x23bc] | > > > | 2.05 Content | > > > | (Token 0x74) | > > > | "22.5 C" | > > > |<-----------------+ > > > | | > > > > > > Figure 6: A Request and a Response Carried in Non-confirmable > > > Messages [Jon] So I would expect > > > any CoAP library to support this non-confirmation mechanism by > > > receiving a new non- confirmable message. It would be the > > > responsibility of the DOTS layer to associate the Tokens together to > > > handle the responses with > > the requests. > > > [Jon] In addition, when Observe is enabled, the DOTS server will > > > continue to generate non-confirmable messages with the same Token. > > > Again, the DOTS client will need to know what to do with the Token > > > (which could be to update things, or to send a RST if no more > > > packets with the same Token should be sent. > > > > > > > > > The spec of Confirmable message already have the retransmission > > > mechanism, so using Confirmable message is an easier way to notice > > > that the message has been lost during the attack time. > > > > > > [Jon] The DOTS client will know something is wrong as it will be > > > seeing heartbeat issues. > > > > > > I'm afraid I'm missing some previous discussions we made on the ML > > > and at the WG meeting, but we have a problem with the CoAP library > > > regarding this spec. > > > > > > * At the -08 version of the signal channel draft, this change was mad= e: > > > DOTS mitigation request/response are marked as non-confirmable > > messages. > > > > > > thank you, > > > Kaname > > > > > > > > > _______________________________________________ > > > Dots mailing list > > > Dots@ietf.org > > > https://www.ietf.org/mailman/listinfo/dots > > > > > > _______________________________________________ > > > Dots mailing list > > > Dots@ietf.org > > > https://www.ietf.org/mailman/listinfo/dots > > > > > > _______________________________________________ > > > Dots mailing list > > > Dots@ietf.org > > > https://www.ietf.org/mailman/listinfo/dots > > > > _______________________________________________ > > Dots mailing list > > Dots@ietf.org > > https://www.ietf.org/mailman/listinfo/dots >=20 > _______________________________________________ > Dots mailing list > Dots@ietf.org > https://www.ietf.org/mailman/listinfo/dots From nobody Tue Jan 2 05:37:36 2018 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 51227126DFF for ; Tue, 2 Jan 2018 05:37:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.33 X-Spam-Level: X-Spam-Status: No, score=-4.33 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, T_RP_MATCHES_RCVD=-0.01] 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 l9TPoRFIl5WH for ; Tue, 2 Jan 2018 05:37:32 -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 5BCAE1201F8 for ; Tue, 2 Jan 2018 05:37:32 -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=1514900251; 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:x-microsoft-antispam-message-info: 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=XQ5N3k0o/kvw5vNNl5ctuZKjbiutu9G7d32nb0 43gII=; b=lpR+Vk16VM2SdoDMgNJ3rzc00/Kq1QdhXVgjUfug PRSZtQbFbaZDcTxTodv9Lqt+2V6jXD19DgTQ20b9NFu6aqg3QT mbOlshrZaOK8zAx88U8rx/hSietwU7lHvDiV6PDFiqkbQGoJpV 7E4/YdepiRF4+ITivs11YCTMNlrCdrY= Received: from DNVEXAPP1N04.corpzone.internalzone.com (DNVEXAPP1N04.corpzone.internalzone.com [10.44.48.88]) by DNVWSMAILOUT1.mcafee.com with smtp (TLS: TLSv1/SSLv3,256bits,ECDHE-RSA-AES256-SHA384) id 1717_0a8f_43eaa6b3_c0fe_4f54_aeea_d31024a16bfd; Tue, 02 Jan 2018 07:37:31 -0600 Received: from DNVEXUSR1N09.corpzone.internalzone.com (10.44.48.82) by DNVEXAPP1N04.corpzone.internalzone.com (10.44.48.88) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Tue, 2 Jan 2018 06:37:24 -0700 Received: from DNVEXUSR1N08.corpzone.internalzone.com (10.44.48.81) by DNVEXUSR1N09.corpzone.internalzone.com (10.44.48.82) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Tue, 2 Jan 2018 06:37:23 -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; Tue, 2 Jan 2018 06:37:23 -0700 Received: from NAM03-DM3-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; Tue, 2 Jan 2018 06:37:22 -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.366.8; Tue, 2 Jan 2018 13:37: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.0366.009; Tue, 2 Jan 2018 13:37:21 +0000 From: "Konda, Tirumaleswar Reddy" To: Jon Shallow , "dots@ietf.org" Thread-Topic: [Dots] Signal CBOR / JSON Mapping Thread-Index: AdN7R9961HXkMq2tTZepG2+xKMly9QAclUqwARk68QAA4qNgAAAC5pyAAAHp+uAAAitXAAACB1IA Date: Tue, 2 Jan 2018 13:37:21 +0000 Message-ID: References: <073001d37b47$e6f27460$b4d75d20$@jpshallow.com> <094a01d3801f$20d94dd0$628be970$@jpshallow.com> <0b6101d383b5$48b29a20$da17ce60$@jpshallow.com> <0b8d01d383c5$9e0e4e50$da2aeaf0$@jpshallow.com> In-Reply-To: <0b8d01d383c5$9e0e4e50$da2aeaf0$@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.72.75] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DM5PR16MB1785; 7:Be0QFI+by7wd9fXNJqRsCEv+JfzYkjxTI0+2GiOopauwDhKuf9T9kPjzg8WMPq2fT1/qJ01kVvaKDnY0v18NwgYsU6NVMZlFofPcLLm64bZQ5xfCc++PXlzAtEoHKxlo2tjYsyU1iiyu3ekT9W6xYdrxqg61vMN+RYDq6S+c5HOSiC3JZ6rTGztcFptSX51mmgX4bk6PWwJ0qjUF8eAhvjeVK3jb982yFM85JNYFKq3vj1P2/b92iY3leaF90Pck x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 7d8c8760-e976-4024-f100-08d551e5f3a0 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(5600026)(4604075)(3008032)(2017052603307)(7153060); SRVR:DM5PR16MB1785; x-ms-traffictypediagnostic: DM5PR16MB1785: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(278428928389397)(21748063052155)(123452027830198); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040470)(2401047)(5005006)(8121501046)(3002001)(3231023)(944501075)(93006095)(93001095)(10201501046)(6041268)(20161123562045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(20161123558120)(20161123564045)(6072148)(201708071742011); SRVR:DM5PR16MB1785; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:DM5PR16MB1785; x-forefront-prvs: 0540846A1D x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39380400002)(346002)(39850400004)(396003)(366004)(376002)(32952001)(57704003)(189003)(199004)(110136005)(102836004)(478600001)(68736007)(9326002)(966005)(606006)(7736002)(14454004)(2900100001)(81166006)(81156014)(8676002)(59450400001)(2950100002)(76176011)(2501003)(8936002)(53546011)(99286004)(25786009)(72206003)(6506007)(316002)(7696005)(93886005)(790700001)(6116002)(77096006)(66066001)(5660300001)(3846002)(229853002)(3280700002)(74316002)(19609705001)(80792005)(3660700001)(6436002)(9686003)(53936002)(33656002)(53946003)(97736004)(2906002)(106356001)(86362001)(54896002)(6306002)(236005)(105586002)(55016002)(6246003)(21314002)(85282002)(579004); 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) x-microsoft-antispam-message-info: xNroFSwZau00IZPF5/VjVtP/nHKj5cx8XGsCm0Qiw7XfNStuFxwi+S16ibo/H9hwDiS5rO2aGhkibOZ+rYOKuQ== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_DM5PR16MB178894626744733419C573FFEA190DM5PR16MB1788namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 7d8c8760-e976-4024-f100-08d551e5f3a0 X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Jan 2018 13:37:21.8939 (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 <6191> : inlines <6292> : streams <1774890> : uri <2561776> Archived-At: Subject: Re: [Dots] Signal CBOR / JSON Mapping 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, 02 Jan 2018 13:37:35 -0000 --_000_DM5PR16MB178894626744733419C573FFEA190DM5PR16MB1788namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Jon, Please see inline [TR2] From: Jon Shallow [mailto:supjps-ietf@jpshallow.com] Sent: Tuesday, January 2, 2018 6:02 PM To: Konda, Tirumaleswar Reddy ; dots@ie= tf.org Subject: RE: [Dots] Signal CBOR / JSON Mapping Hi Tiru et al, See inline [Jon1]. Regards Jon From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Jon Shallow Sent: Friday, December 29, 2017 2:32 AM To: Konda, Tirumaleswar Reddy >; dots@ietf.org Subject: Re: [Dots] Signal CBOR / JSON Mapping Hi Tiru, Thanks for pointing me to these references. RFC7951 6.1. Numeric Types A value of the "int8", "int16", "int32", "uint8", "uint16", or "uint32" type is represented as a JSON number. A value of the "int64", "uint64", or "decimal64" type is represented as a JSON string whose content is the lexical representation of the corresponding YANG type as specified in Sections 9.2.1 and 9.3.1 of [RFC7950]. For example, if the type of the leaf "foo" in Section 5.1 was "uint64" instead of "uint8", the instance would have to be encoded as "foo": "123" -- So, we now have a way of handling int64/uint64 which should be used moving = forward. However, my JSON implementation (as well as many others I suspect) natively= supports decimal64, so does not necessarily need to display it as a lexica= l representation string. Do we follow RFC7951 here as well? [TR] Let's not deviate from RFC7951 otherwise both drafts will end-up defin= ing it's our own set of rules for encoding the YANG configuration data as J= SON/CBOR text deviating from the existing standards. [Jon] Agreed I do not think that we should be following the augmented JSON parameter nam= ing in RFC7951 "4. Names and Namespaces" otherwise we will start ending up = with JSON/CBOR parameter names such as "ietf-dots-signal:mitigation-scope".= If we do go with this, then the CBOR mapping table will need to get exten= ded to cover the old, but some parameter name in different places. Comment= s? [TR] Both drafts should follow the naming in RFC7951. [Jon] I'm neutral on this, but agree to following standards - there will be= however a lot of long parameter names which fortunately will get compresse= d by the CBOR mapping. However, draft-ietf-netmod-acl-model (albeit in xml= not json) does not have parameter names such as "ietf-access-control-list:= access-lists" [Jon1] We really need to come to an agreement on this one. I think I prefe= r simpler names, but any program based YANG -> JSON translator following RF= C7951 will come up with the long names.... However as I understand "A namespace-qualified member name MUST be used for all members of a top-level JSON object and then also whenever the namespaces of the data node and its parent node are different. In all other cases, the simple form of the member name MUST be used." This probably only means that "ietf-dots-signal:mitigation-scope", "ietf-ac= l:acl-name", "ietf-acl:acl-type" and "ietf-dots-signal:signal-config" are t= he changes [TR2] Yes. (yes, acl-name & acl-type may be redefined in netconf-acl - do we really ne= ed acl-type?). [TR2] I did not get the above question ! As we are working with YANG, JSON and CBOR interrelation , I still think we= need a table similar to below to aid implementers - referring as appropria= te to the different RFCs - no-one has full knowledge of all the evolving RF= Cs. [TR] I don't see the need to repeat, its already discussed in detail in htt= ps://tools.ietf.org/html/rfc8040#section-5.2 and similarly DOTS signal chan= nel draft already refers to draft-ietf-core-yang-cbor-05. [Jon] Given the number of times we have been inconsistent with the YANG / J= SON and CBOR definitions of a specific parameter, having a single place whe= re all 3 variants are on the same line certainly helps me as an implementer= . [TR1] I am trying to keep the CBOR mapping table simple (not too wide :)), = it can be updated to add YANG type. Why do we need the corresponding JSON t= ype and JSON examples in the table ? [Jon1] I agree that we have a 72 character width limit. I do not think we = need the JSON examples column, but do think we need the JSON type so we hav= e YANG, CBOR and JSON equivalent types in one place. However, if the param= eter names get long -e.g. "ietf-dots-signal:mitigation-scope", we will run = out of width unless they are split over 2 lines. [TR2] Yes, some of the parameter names need to be split into 2 lines. DOTS = signal channel does not deal with JSON encoding, what is the need to discus= s equivalent JSON type in the signal channel draft ? [Jon1] NOTE. If we have to do changes to parameter names, this may be a su= itable break point to re-sort the list by parameter name for ease of readab= ility / lookup - especially if/as we are doing a lot of other fundamental c= hanges post -14 with all the other discussions - time to clean things up! [TR] Sure. -Tiru Regards Jon From: Dots [mailto: dots-bounces@ietf.org] On= Behalf Of Konda, Tirumaleswar Reddy Sent: 23 December 2017 07:06 To: Jon Shallow; dots@ietf.org Subject: Re: [Dots] Signal CBOR / JSON Mapping We should just follow the CBOR Encoding of Data Modeled with YANG defined i= n https://tools.ietf.org/html/draft-ietf-core-yang-cbor-05 and JSON Encodin= g of Data Modeled with YANG defined in https://tools.ietf.org/html/rfc7951. -Tiru From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Jon Shallow Sent: Friday, December 22, 2017 10:41 PM To: dots@ietf.org Subject: [Dots] Signal CBOR / JSON Mapping Hi WG, There are a lot of YANG parameters that we are using that are defined as in= t64. JSON only safely supports up to 53 bits of precision. RFC 7493 2.2 Numbers An I-JSON sender cannot expect a receiver to treat an integer whose absolute value is greater than 9007199254740991 (i.e., that is outside the range [-(2**53)+1, (2**53)-1]) as an exact value. For applications that require the exact interchange of numbers with greater magnitude or precision, it is RECOMMENDED to encode them in JSON string values. This requires that the receiving program understand the intended semantic of the value. An example would be 64-bit integers, even though modern hardware can deal with them, because of the limited scope of JavaScript numbers. RFC7049 3.6 Numbers CBOR-based protocols should take into account that different language environments pose different restrictions on the range and precision of numbers that are representable. For example, the JavaScript number system treats all numbers as floating point, which may result in silent loss of precision in decoding integers with more than 53 significant bits. A protocol that uses numbers should define its expectations on the handling of non-trivial numbers in decoders and receiving applications. =3D=3D=3D=3D An option is to make all of these int64 decimal64 for the signal channel, b= ut that does not cover the 64 bit counters in the netmod-acl. However, as = the netmod-acl counters are also fed back via the mitigate status, we do no= t necessarily need to support the netmod-acl counters. If, however, we follow RFC 7493, in CBOR the data can be passed across as 6= 4 bits, and as the parameter is a CBOR mapping, we can know how to encode /= decode the JSON value as appropriate. However, RFC 7493 does not say whet= her this should be base64, base64url or numeric string representation (i.e.= "1234567890"). RFC7049 refers to bignum (major type 6, tag value 2 or 3) = should be encoded as base64url (4.1 Converting from CBOR to JSON) - but int= 64 can be held in CBOR as type 0 or 1. I prefer the numeric string representation as it is humanly easy to read an= d easy to convert into 64 bit integers. If we take this approach of using the parameter which is a CBOR mapping key= to key off how to encode / decode the JSON, I would suggest that we could = extend this to include IP addresses, Dates and client-identifiers (or their= possible new names of request-nonce and client-domain-hash) to further min= imize the actual number of bytes sent in a COAP packet. The CBOR mapping Table could then be extended to look something like (but i= t is too wide I think) /----------------------+-------------+------+---------------+--------+-----= ----\ | Parameter name | YANG type | CBOR | CBOR major | JSON | JSON= | | | | key | type | type | Exam= ple | |----------------------+-------------+------+---------------+--------+-----= ----| | mitigation-scope | grouping | 1 | 5 map | Object | = | | scope | list | 2 | 4 array | Array | = | | mitigation-id | int32 | 3 | 0 unsigned | Number | 5432= 1 | | acl-list | list | 4 | 4 array | Array | = | | target-port-range | list | 5 | 4 array | Array | = | | lower-port | port-number | 6 | 0 number | Number | 1111= | | upper-port | port-number | 7 | 0 number | Number | 1111= | | target-protocol | leaf-list | | 4 array | Array | = | | | uint8 | 8 | 0 number | Number | 6 = | | target-fqdn | leaf-list | | 4 array | Array | = | | | domain-name | 9 | 3 text string | String | "a.c= om" | | target-uri | leaf-list | | 4 array | Array | = | | | uri | 10 | 3 text string | String | = | | alias-name | leaf-list | | 4 array | Array | = | | | string | 11 | 3 text string | String | "web= " | | lifetime | int32 | 12 | 0 number | Number | = | | attack-status | enumeration | 13 | 0 number | Number | 1 = | | signal-config | grouping | 14 | 5 map | Object | = | | heartbeat-interval | grouping | 15 | 5 map | Object | = | | max-retransmit | grouping | 16 | 5 map | Object | = | | ack-timeout | grouping | 17 | 5 map | Object | = | | ack-random-factor | grouping | 18 | 5 map | Object | = | | min-value | int16 | 19 | 0 number | Number | 1 = | | max-value | int16 | 20 | 0 number | Number | 1 = | | status | enumeration | 21 | 0 number | Number | 1 = | | conflict-information | grouping | 22 | 5 map | Object | = | | conflict-status | enumeration | 23 | 0 number | Number | 1 = | | conflict-cause | enumeration | 24 | 0 number | Number | 1 = | | retry-timer | int32 | 25 | 0 number | Number | 1800= | | bytes-dropped | counter64 | 26 | 0 number | String | "123= 4" | | bps-dropped | counter64 | 27 | 0 number | String | "123= 4" | | pkts-dropped | counter64 | 28 | 0 number | String | "123= 4" | | pps-dropped | counter64 | 29 | 0 number | String | "123= 4" | | session-id | int32 | 30 | 0 number | Number | 6543= 2 | | trigger-mitigation | boolean | 31 | 7 simple | T / F | = | | missing-hb-allowed | grouping | 32 | 5 map | Object | = | | current-value | int16 | 33 | 0 number | Number | 10 = | | mitigation-start | decimal64 | 34 | 7 FP | Number | 10.2= 1 | | target-prefix | leaf-list | | 4 array | Array | = | | | ip-prefix | 35 | 3 text string | String | = | | client-domain-hash | leaf-list | | 4 array | Array | = | | | binary | 36 | 2 byte string | String | "abc= df" | | alt-server | string | 37 | 3 text string | String | = | | alt-server-record | list | 38 | 4 array | Array | = | | addr | string | 39 | 3 text string | String | = | | ttl | int32 | 40 | 0 number | Number | 1800= | | conflict-scope | grouping | 41 | 5 map | Object | = | | acl-name | string | 42 | 3 text string | String | "ana= me" | | acl-type | string | 43 | 3 text string | String | "ipv= 4" | | config-interval | int32 | 44 | 0 number | Number | 11 = | | mitigating-config | grouping | 45 | 5 map | Object | = | | idle-config | grouping | 46 | 5 map | Object | = | | request-nonce | binary | 47 | 2 byte string | String | "xxx= " | | min-value-decimal | decimal64 | 48 | 7 FP | Number | 1.1 = | | max-value-decimal | decimal64 | 49 | 7 FP | Number | 1.1 = | | current-value-decimal| decimal64 | 50 | 7 FP | Number | 1.1 = | \----------------------+-------------+------+---------------+--------+-----= ----/ Comments / suggestions? Regards Jon --_000_DM5PR16MB178894626744733419C573FFEA190DM5PR16MB1788namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Jon,

&nbs= p;

Please se= e inline [TR2]

 

From:<= /span> Jon Shallow [mailto:s= upjps-ietf@jpshallow.com]
Sent: Tuesday, January 2, 2018 6:02 PM
To: Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@McAfee.com= >; dots@ietf.org
Subject: RE: [Dots] Signal CBOR / JSON Mapping

 

Hi Tiru= et al,

&n= bsp;

See inl= ine [Jon1].

&n= bsp;

Regards=

&n= bsp;

Jon

&n= bsp;

&nbs= p;

From:<= /span> Dots [mailto:dots-bounces@ietf.org] On Behalf Of Jon Shallow
Sent: Friday, December 29, 2017 2:32 AM
To: Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@McAfee.com>; dots@ietf.org
Subject: Re: [Dots] Signal CBOR / JSON Mapping

 

Hi Tiru= ,

&n= bsp;

Thanks = for pointing me to these references.

&n= bsp;

RFC7951=

6.1.&nb= sp; Numeric Types

&n= bsp;

 &= nbsp; A value of the "int8", "int16", "int32"= , "uint8", "uint16", or

 &= nbsp; "uint32" type is represented as a JSON number.

&n= bsp;

 &= nbsp; A value of the "int64", "uint64", or "decima= l64" type is represented

 &= nbsp; as a JSON string whose content is the lexical representation of the

 &= nbsp; corresponding YANG type as specified in Sections 9.2.1 and 9.3.1 of

 &= nbsp; [RFC7950].

&n= bsp;

 &= nbsp; For example, if the type of the leaf "foo" in Section 5.1 w= as

 &= nbsp; "uint64" instead of "uint8", the instance would h= ave to be encoded as

&n= bsp;

 &= nbsp; "foo": "123"

--=

&n= bsp;

So, we = now have a way of handling int64/uint64 which should be used moving forward= .

&n= bsp;

However= , my JSON implementation (as well as many others I suspect) natively suppor= ts decimal64, so does not necessarily need to display it as a lexical repre= sentation string.  Do we follow RFC7951 here as well?

 

[TR] Let’s not deviate fr= om RFC7951 otherwise both drafts will end-up defining it’s our own se= t of rules for encoding the YANG configuration data as JSON/CBOR text devia= ting from the existing standards.

[Jon] A= greed

&n= bsp;

I do no= t think that we should be following the augmented JSON parameter naming in = RFC7951 “4. Names and Namespaces” otherwise we will start endin= g up with JSON/CBOR parameter names such as “ietf-dots-signal:mitigat= ion-scope”.  If we do go with this, then the CBOR mapping table will need to get extend= ed to cover the old, but some parameter name in different places.  Com= ments?

 

[TR] Both drafts should follow = the naming in RFC7951.

[Jon] I= ’m neutral on this, but agree to following standards – there wi= ll be however a lot of long parameter names which fortunately will get comp= ressed by the CBOR mapping.  However, draft-ietf-netmod-acl-model (albeit in xml not json) does not have parameter names such as “ietf= -access-control-list:access-lists”

[Jon1] = We really need to come to an agreement on this one.  I think I prefer = simpler names, but any program based YANG -> JSON translator following R= FC7951 will come up with the long names….  However as I understand

“A namespace-qualified member name MUST be used= for all members of a

   top-level JSON object and then also when= ever the namespaces of the

   data node and its parent node are differ= ent.  In all other cases, the

 &= nbsp; simple form of the member name MUST be used.”=

This pr= obably only means that “ietf-dots-signal:mitigation-scope”, = 220;ietf-acl:acl-name”, “ietf-acl:acl-type” and “ie= tf-dots-signal:signal-config” are the changes

 

[TR2] Yes.

 

(yes, a= cl-name & acl-type may be redefined in netconf-acl – do we really= need acl-type?).

 

[TR2] I did not get the above q= uestion !

 

As we a= re working with YANG, JSON and CBOR interrelation , I still think we need a= table similar to below to aid implementers – referring as appropriat= e to the different RFCs – no-one has full knowledge of all the evolving RFCs.

 

[TR] I don’t see the need= to repeat, its already discussed in detail in https://tools.i= etf.org/html/rfc8040#section-5.2 and similarly DOTS signal channel draf= t already refers to draft-ietf-core-yang-cbor-05.

[Jon] G= iven the number of times we have been inconsistent with the YANG / JSON and= CBOR definitions of a specific parameter, having a single place where all = 3 variants are on the same line certainly helps me as an implementer.

 

[TR1] I am trying to keep the C= BOR mapping table simple (not too wide J), it can be updated to add YANG type. Why do we need the cor= responding JSON type and JSON examples in the table ?

[Jon1] = I agree that we have a 72 character width limit.  I do not think we ne= ed the JSON examples column, but do think we need the JSON type so we have = YANG, CBOR and JSON equivalent types in one place.  However, if the parameter names get long –e.g. “i= etf-dots-signal:mitigation-scope”, we will run out of width unless th= ey are split over 2 lines.

 

[TR2] Yes, some of the paramete= r names need to be split into 2 lines. DOTS signal channel does not deal wi= th JSON encoding, what is the need to discuss equivalent JSON type in the s= ignal channel draft  ?

 

[Jon1] = NOTE.  If we have to do changes to parameter names, this may be a suit= able break point to re-sort the list by parameter name for ease of readabil= ity / lookup – especially if/as we are doing a lot of other fundamental changes post -14 with all the other discussions= – time to clean things up!

 

[TR] Sure.

 

-Tiru

 

Regards=

&n= bsp;

Jon

&n= bsp;

From: Dots [mailto: dots-bounces@ietf.org] On B= ehalf Of Konda, Tirumaleswar Reddy
Sent: 23 December 2017 07:06
To: Jon Shallow; dots@ietf.org<= br> Subject: Re: [Dots] Signal CBOR / JSON Mapping

 

We should= just follow the CBOR Encoding of Data Modeled with YANG defined in https:= //tools.ietf.org/html/draft-ietf-core-yang-cbor-05 and JSON Encoding of= Data Modeled with YANG

defined i= n https://tools.ietf.org/html/rfc7951.

&nbs= p;

-Tiru

&nbs= p;

From:<= /span> Dots [mailto:dots-bounces@ietf.org] On Behalf Of Jon Shallow
Sent: Friday, December 22, 2017 10:41 PM
To: dots@ietf.org
Subject: [Dots] Signal CBOR / JSON Mapping

 

Hi WG,

 

There are a lot of YANG paramet= ers that we are using that are defined as int64.  JSON only safely sup= ports up to 53 bits of precision.

 

RFC 7493 2.2 Numbers=

 

   An I-JSON sender c= annot expect a receiver to treat an integer whose

   absolute value is = greater than 9007199254740991 (i.e., that is

   outside the range = [-(2**53)+1, (2**53)-1]) as an exact value.

 

   For applications t= hat require the exact interchange of numbers with

   greater magnitude = or precision, it is RECOMMENDED to encode them in

   JSON string values= .  This requires that the receiving program

   understand the int= ended semantic of the value.  An example would be

   64-bit integers, e= ven though modern hardware can deal with them,

   because of the lim= ited scope of JavaScript numbers.

 

RFC7049 3.6 Numbers<= /span>

 

   CBOR-based protoco= ls should take into account that different language

   environments pose = different restrictions on the range and precision

   of numbers that ar= e representable.  For example, the JavaScript

   number system trea= ts all numbers as floating point, which may result

   in silent loss of = precision in decoding integers with more than 53

   significant bits.&= nbsp; A protocol that uses numbers should define its

   expectations on th= e handling of non-trivial numbers in decoders and

   receiving applicat= ions.

 

=3D=3D=3D=3D<= /p>

 

An option is to make all of the= se int64 decimal64 for the signal channel, but that does not cover the 64 b= it counters in the netmod-acl.  However, as the netmod-acl counters ar= e also fed back via the mitigate status, we do not necessarily need to support the netmod-acl counters.<= /span>

 

If, however, we follow RFC 7493= , in CBOR the data can be passed across as 64 bits, and as the parameter is= a CBOR mapping, we can know how to encode / decode the JSON value as appro= priate.  However, RFC 7493 does not say whether this should be base64, base64url or numeric string representat= ion (i.e. “1234567890”).  RFC7049 refers to bignum (major = type 6, tag value 2 or 3) should be encoded as base64url (4.1 Converting fr= om CBOR to JSON) – but int64 can be held in CBOR as type 0 or 1.

 

I prefer the numeric string rep= resentation as it is humanly easy to read and easy to convert into 64 bit i= ntegers.

 

If we take this approach of usi= ng the parameter which is a CBOR mapping key to key off how to encode / dec= ode the JSON, I would suggest that we could extend this to include IP addre= sses, Dates and client-identifiers (or their possible new names of request-nonce and client-domain-hash) to furth= er minimize the actual number of bytes sent in a COAP packet.

 

The CBOR mapping Table could th= en be extended to look something like (but it is too wide I think)

 

/----------------------+-------------= 3;------+---------------+--------+---------\<= /p>

| Parameter name    &nbs= p;  | YANG type   | CBOR | CBOR major    | JS= ON   | JSON    | 

|       &= nbsp;           &nbs= p;  |           = ;  | key  | type        &= nbsp; | type   | Example |

|----------------------+-------------= 3;------+---------------+--------+---------|<= /p>

| mitigation-scope     |= grouping    |   1  | 5 map   =       | Object |     &nbs= p;   | 

| scope      &= nbsp;         | list  &nb= sp;     |   2  | 4 array  &nbs= p;    | Array  |      &nb= sp;  | 

| mitigation-id     = ;   | int32       |   3&n= bsp; | 0 unsigned    | Number | 54321   | 

| acl-list     &nbs= p;       | list     =    |   4  | 4 array     &= nbsp; | Array  |         |&nbs= p;

| target-port-range    | list=         |   5  | 4 array&= nbsp;      | Array  |    =      | 

| lower-port     &n= bsp;     | port-number |   6  | 0 number=       | Number | 1111    | 

| upper-port     &n= bsp;     | port-number |   7  | 0 number=       | Number | 1111    | 

| target-protocol    &nb= sp; | leaf-list   |      | 4 array =       | Array  |     = ;    | 

|       &= nbsp;           &nbs= p;  | uint8       |   8  = | 0 number      | Number | 6   &nbs= p;   |

| target-fqdn     &= nbsp;    | leaf-list   |    &n= bsp; | 4 array       | Array  | &nb= sp;       |

|       &= nbsp;           &nbs= p;  | domain-name |   9  | 3 text string | String | &qu= ot;a.com" |

| target-uri     &n= bsp;     | leaf-list   |    &n= bsp; | 4 array       | Array  |&nbs= p;        | 

|       &= nbsp;           &nbs= p;  | uri         |  10&n= bsp; | 3 text string | String |       &n= bsp; |

| alias-name     &n= bsp;     | leaf-list   |    &n= bsp; | 4 array       | Array  | &nb= sp;       | 

|        =             &nb= sp; | string      |  11  | 3 text s= tring | String | "web"   | 

| lifetime     &nbs= p;       | int32     = ;  |  12  | 0 number      | Number = |         | 

| attack-status     = ;   | enumeration |  13  | 0 number   &n= bsp;  | Number | 1       | 

| signal-config     = ;   | grouping    |  14  | 5 map &n= bsp;       | Object |    =      | 

| heartbeat-interval   | grouping&= nbsp;   |  15  | 5 map     &nb= sp;   | Object |         = | 

| max-retransmit    &nbs= p;  | grouping    |  16  | 5 map  &= nbsp;      | Object |     = ;    | 

| ack-timeout     &= nbsp;    | grouping    |  17  | 5 m= ap         | Object |  &n= bsp;      | 

| ack-random-factor    | grou= ping    |  18  | 5 map    &nbs= p;    | Object |       &n= bsp; | 

| min-value      &n= bsp;     | int16     &nbs= p; |  19  | 0 number      | Number | 1&n= bsp;      | 

| max-value     &nb= sp;      | int16     &nbs= p; |  20  | 0 number      | Number | 1&n= bsp;      | 

| status      =          | enumeration |  21&n= bsp; | 0 number      | Number | 1   = ;    | 

| conflict-information | grouping  = ;  |  22  | 5 map       &= nbsp; | Object |         | 

| conflict-status    &nb= sp; | enumeration |  23  | 0 number     = | Number | 1       | 

| conflict-cause    &nbs= p;  | enumeration |  24  | 0 number    &= nbsp; | Number | 1       | 

| retry-timer     &= nbsp;    | int32       | = 25  | 0 number      | Number | 1800 &nb= sp;  | 

| bytes-dropped     = ;   | counter64   |  26  | 0 number &nbs= p;    | String | "1234"  | 

| bps-dropped     &= nbsp;    | counter64   |  27  | 0 number=       | String | "1234"  | 

| pkts-dropped     =     | counter64   |  28  | 0 number = ;     | String | "1234"  | 

| pps-dropped     &= nbsp;    | counter64   |  29  | 0 number=       | String | "1234"  | 

| session-id     &n= bsp;     | int32       |&= nbsp; 30  | 0 number      | Number | 65432&nb= sp;  | 

| trigger-mitigation   | boolean&n= bsp;    |  31  | 7 simple    &= nbsp; | T / F  |         |&nbs= p;

| missing-hb-allowed   | grouping&= nbsp;   |  32  | 5 map     &nb= sp;   | Object |         = | 

| current-value     = ;   | int16       |  33  = | 0 number      | Number | 10   &nb= sp;  | 

| mitigation-start     |= decimal64   |  34  | 7 FP     = ;     | Number | 10.21   | 

| target-prefix     = ;   | leaf-list   |      | 4 a= rray       | Array  |   &= nbsp;     | 

|        =             &nb= sp; | ip-prefix   |  35  | 3 text string | String = |         | 

| client-domain-hash   | leaf-list=    |      | 4 array   &nb= sp;   | Array  |       &n= bsp; |

|        =             &nb= sp; | binary      |  36  | 2 byte s= tring | String | "abcdf" |

| alt-server     &n= bsp;     | string      | = 37  | 3 text string | String |      &nb= sp;  | 

| alt-server-record    | list=         |  38  | 4 array =       | Array  |     = ;    | 

| addr      &n= bsp;          | string &n= bsp;    |  39  | 3 text string | String | &nb= sp;       | 

| ttl      &nb= sp;           | int32&nbs= p;      |  40  | 0 number  &nb= sp;   | Number | 1800    | 

| conflict-scope    &nbs= p;  | grouping    |  41  | 5 map  &= nbsp;      | Object |     = ;    | 

| acl-name     &nbs= p;       | string    &nbs= p; |  42  | 3 text string | String | "aname" | 

| acl-type     &nbs= p;       | string    &nbs= p; |  43  | 3 text string | String | "ipv4"  |&nbs= p;

| config-interval    &nb= sp; | int32       |  44  | 0 number=       | Number | 11      = | 

| mitigating-config    | grou= ping    |  45  | 5 map    &nbs= p;    | Object |       &n= bsp; | 

| idle-config     &= nbsp;    | grouping    |  46  | 5 m= ap         | Object |  &n= bsp;      | 

| request-nonce     = ;   | binary      |  47  | 2 b= yte string | String | "xxx"   | 

| min-value-decimal    | deci= mal64   |  48  | 7 FP     &nbs= p;    | Number | 1.1     | 

| max-value-decimal    | deci= mal64   |  49  | 7 FP     &nbs= p;    | Number | 1.1     | 

| current-value-decimal| decimal64 &nbs= p; |  50  | 7 FP        &= nbsp; | Number | 1.1     | 

\----------------------+-------------= 3;------+---------------+--------+---------/<= /p>

 

 

Comments / suggestions?

 

Regards

 

Jon

--_000_DM5PR16MB178894626744733419C573FFEA190DM5PR16MB1788namp_-- From nobody Tue Jan 2 05:43:31 2018 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 552861274D2 for ; Tue, 2 Jan 2018 05:43:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 dosG--wRKKQm for ; Tue, 2 Jan 2018 05:43:28 -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 9E4F712708C for ; Tue, 2 Jan 2018 05:43:28 -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 1eWMqk-0006oJ-Tb; Tue, 02 Jan 2018 13:43:26 +0000 From: "Jon Shallow" To: "'Roman Danyliw'" , References: <359EC4B99E040048A7131E0F4E113AFC0131355A04@marathon> In-Reply-To: <359EC4B99E040048A7131E0F4E113AFC0131355A04@marathon> Date: Tue, 2 Jan 2018 13:43:25 -0000 Message-ID: <0baf01d383cf$a9cefd20$fd6cf760$@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: AQHdM/Qz99z/7IXDUi62LZwazkCMeKNNK62w Archived-At: Subject: Re: [Dots] REMINDER -- WGLC on DOTS 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: Tue, 02 Jan 2018 13:43:30 -0000 Hi Roman, Comment # 1 I still have clarity issues with the usage of the terms "client-side" and "server-side" with reference to DOTS gateways They are used both as a prefix and/or suffix to 'DOTS gateways', yet have different meaning based on positioning. What does "client-side DOTS gateway server-side" actually mean? "client-side DOTS gateway server-side" means as I understand it "The 'DOTS client' component of the DOTS gateway that is sitting in a client domain", not "The 'DOTS server' component of the DOTS gateway that is sitting in a client domain". "client-domain DOTS gateway server-facing-side" is a lot clearer to me. - See discussions on https://mailarchive.ietf.org/arch/msg/dots/7-27y3X9-nw6-aRuGflzTaSoy3s Whatever the decision on naming, it needs to be explicitly defined, not as a passing reference under "DOTS gateway" definition. Comment # 2 While Filter is defined, it does not appear to be used / required, unless Black-List / White-List are using Filter only as a mechanism. Should there be a DATA-005 for this as a requirement (i.e. using the flexibility of netconf-acl? Regards Jon -----Original Message----- From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of Roman Danyliw Sent: 02 January 2018 12:53 To: dots@ietf.org Subject: [Dots] REMINDER -- WGLC on DOTS Requirements Hello! Happy New Year! The WGLC for the DOTS requirements draft will be closing soon. Please provide any final comments. Thanks, Roman -----Original Message----- From: Roman Danyliw Sent: Thursday, December 7, 2017 3:51 PM To: dots@ietf.org Subject: WGLC on DOTS Requirements Hello! Consistent with our discussion at the Singapore meeting and with the concurrence of the draft authors, we are starting a working group last call (WGLC) for the DOTS Requirements draft: Distributed Denial of Service (DDoS) Open Threat Signaling Requirements draft-ietf-dots-requirements-08 https://tools.ietf.org/html/draft-ietf-dots-requirements-08 Please send all comments to the DOTS mailing list. This WGLC will end on January 2, 2018 (~3 weeks to account for end-of-the-calendar year vacations). Thanks, Roman _______________________________________________ Dots mailing list Dots@ietf.org https://www.ietf.org/mailman/listinfo/dots From nobody Tue Jan 2 06:06:00 2018 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 C7455126DEE for ; Tue, 2 Jan 2018 06:05:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 fvCLVB8MY2Gg for ; Tue, 2 Jan 2018 06:05:56 -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 7B68E1201F8 for ; Tue, 2 Jan 2018 06:05:56 -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 1eWNCS-0006pQ-Bh; Tue, 02 Jan 2018 14:05:52 +0000 From: "Jon Shallow" To: "'Konda, Tirumaleswar Reddy'" , , "kaname nishizuka" References: <094801d3801e$f7ab01b0$e7010510$@jpshallow.com> <099601d38096$487c9410$d975bc30$@jpshallow.com> <0b7a01d383bb$aba5f720$02f1e560$@jpshallow.com> <0b8501d383be$df5ec030$9e1c4090$@jpshallow.com> In-Reply-To: Date: Tue, 2 Jan 2018 14:05:50 -0000 Message-ID: <0bb401d383d2$cbbdc9e0$63395da0$@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: AQLSq4q/0bL2TF/Kn5VRXUOjWNcfvgJYRDCAAhO9FZgBoHWANAIl/Wr3An6e4NwCKRTIOQIYzMyooOqun5A= Archived-At: Subject: Re: [Dots] [signal-channel-draft] CoAP libraries have problems with the DOTS spec 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, 02 Jan 2018 14:05:59 -0000 Hi Tiru, See inline [Jon4] Regards Jon > > > > -----Original Message----- > > > From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of kaname > > > nishizuka > > > Sent: 28 December 2017 10:02 > > > To: dots@ietf.org > > > Subject: [Dots] [signal-channel-draft] CoAP libraries have > > > problems with the DOTS spec > > > > > > Hi, > > > > > > Last week, Jon and I did the second interoperability test based on > > > the > > > -13 version of the signal channel draft. > > > We made significant improvements of each implementation. Several > > > feedbacks to the WG have been made by Jon already. > > > > > > Based on the experience, I encountered the problems between CoAP > > > libraries and the specification of the DOTS. > > > > > > 1. resource identification of GET methods. > > > > > > In signal channel spec, the target resource in GET method is > > > identified in the BODY of the message, that is mitigation-id (and > > client-identifier). > > > However, CoAP libraries, at least we investigated, only see the > > > Request URI, so it cannot locate the resource because it doesn't > > > see the > > BODY. > > > > > > So the question is, why does the DOTS spec use CoAP Body for > > > resource identifier? > > > > > > [Jon] A very good question. I had just assumed that this was the > > > way to do it, but had noted that this was not done when using HTTP etc. > > > and so was different. See later comments > > > > > > Most of CoAP libraries only support request URI in CoAP > > > GET/observe, which is the spec from RFC7252. > > > https://tools.ietf.org/html/rfc7252 > > > 5.8.1.GET > > > The GET method retrieves a representation for the information that > > > currently corresponds to the resource identified by the request URI. > > > [Jon] RFC 7252 states also > > > 5.10.1. Uri-Host, Uri-Port, Uri-Path, and Uri-Query > > > > > > The Uri-Host, Uri-Port, Uri-Path, and Uri-Query Options are used to > > > specify the target resource of a request to a CoAP origin server. > > > [Jon] So it looks like the target resource should only be in > > > Uri-Path and/or Uri-Query. > > > [Jon] In my CoAP Library, I have to define each individual > > > resource (it does a lookup against a hash of the complete Uri to > > > find whether the resource is known or not), so, when say > > > mitigation-id=2 is added, I need to register the resource > > > .well-known/dots/v1/mitigate/migration-is=2 with an associated > > > handler. This is not difficult to do, but potentially could > > > consume a lot > > of DOTS server resources if many mitigations are active. > > > [Jon] Doing it as a Query Option I think is my preference - Comments? > > > [Jon] The same is true for GET signal configuration as well. > > > > Yes, will update draft to use Query option for GET method. > > [Jon2] This works for me, but does not feel right when this is > > extended for "PUT .../mitigate Query mitigation-id-2" to create the > > mitigation-id. I think that the complete "resource" should be > > specified for consistency and just leave the c=? as being the > > required > valid Query option. > > PUT method does not need to convey the Query Option (for example > please see https://tools.ietf.org/html/rfc7967#section-4.1.1, the > resource is specified in the URI-path option itself). > > [Jon3] Agreed - and think that the full resource needs to be > specified for the DELETE (need to fix my libcoap library to not > respond with 4.04 if resource does not exist as per RFC7252) as well > that the GET. However, "GET .../mitigate" should return all current > mitigations if the mitigation-id is not specified in the Uri-Path.. Yes. [Jon4] mitigation-id needs to be included as a parameter in the body in response to "GET .../mitigate". I assume for consistency, it should also be returned as a parameter for "GET .../mitigate/mitigation-id=ZZ". [Jon4] So when doing "PUT .../mitigate/mitigation-id=ZZ", do we also include in the PUT data body the parameter mitigation-id = ZZ? What happens if they are different? > > [Jon3] The same is for configuration (GET, PUT & DELETE) - which then > begs the question - do we really need "session-id" ? session-id is introduced to handle out-of-order delivery of PUT requests, the PUT request with a higher numeric 'session-id' value overrides the DOTS signal channel session configuration data installed by a PUT request with a lower numeric 'session-id' value. [Jon4] Understood. And the lesser session-id resource would be no more (i.e. the resource is deleted). [Jon4] As this signal configuration is only defining a specific session (there may be multiple sessions) between 2 DOTS peers, "client-identifier" (or "request-nonce") are not really needed to be supported as a part of the resource. [Jon4] We need a "GET .../config" to get the server sides (initial) notion of what is supported for configuration. We would then support "GET .../config/session-id=YY" (only can be done following a PUT otherwise session-id is unknown). The PUT would definitely have to be "PUT ../config/session-id-YY". The DELETE would be either "DELETE .../config" or "DELETE .../config/session-id=YY" where both of them reset the signal configuration back to the defaults. "DELETE .../config" would get rid of any session-ids for that particular session. -Tiru > > > > > > > > > [Jon1] I am now leaning towards doing it in the Uri-Path but still > > > not > > sure. > > > The CoAP layer responds with a 4.04 with my CoAP library if the > > > resource > > > (Uri-Path) is unknown. > > > [Jon1] We need to define the order in the path - e.g. > > > client-identifier (or request-none etc. if that is accepted) then > > > mitigation-id, so that resources are built consistently from a > > > mitigation > > request. > > > > Agreed. > > [Jon2] then something similar to the above specifying ordering needs > > to be put into the draft. > > Yes. > > > > > > [Jon1] However doing this means we also need to include PUT and > > > DELETE with the resource specified in the Uri-Path. My library > > > then runs into a chicken and egg situation with PUT - the PUT is > > > defining the new resource, but as the resource is not defined > > > (yet) in the CoAP layer, it gets rejected with a > > > 4.04 in the CoAP layer (as mentioned above). The way around this > > > is to use POST to create new mitigation requests (and will respond > > > with appropriate Location-Path to give the new UI) and PUT if we > > > are refreshing > > the resource. > > > > > > [Jon1] Thoughts? > > > > PUT can also be used to create a new resource, and the draft uses > > PUT instead of POST because it is idempotent and during a > > volumetric DDoS attack saturating the incoming link to the DOTS > > client, DOTS client will most likely not receive the server-side > > responses. Is this an > implementation bug ? > > > > [Jon2] I agree that it is a bug in the libcoap I am using > > [https://github.com/obgm/libcoap]. RFC7252 5.8.3. PUT states "The > > PUT method requests that the resource identified by the request URI > > be updated or created". I can try to fix the library to keep on > > stripping off the last UriPath and then doing a hash lookup on the > > sub path until a match is found in the case of doing a PUT. It > > would then (in my case - not needed in the > > draft) be the responsibility of creating a new resource if needed in > > the DOTS layer. > > Thanks. > > Cheers, > Tiru > > > > > -Tiru > > > > > > > > 2. Confirmable vs NonConfirmable at Mitigation Request > > > > > > A CoAP library (dustin/go-coap) stops listening right after > > > sending out the NonConfirmable message because NonConfirmable > > > messages do > > not > > > require acknowledgements. > > > > > > [Jon] As there is a good chance during attack scenarios that > > > responses may not be able to get back, it makes sense to me that > > > these "GET > > mitigation" > > > requests are non-confirmable. Certainly "PUT mitigation" needs to > > > be thought of as a one way signal. There are times that the > > > client has to run "blind" during attack scenarios. > > > [Jon]If they were confirmable, then the request will get sent > > > multiple times to the DOTS server - which could be handled by the > > > server, but then the confirmable responses would retried whilst > > > sending back to the DOTS client and eventually retry timeout. A > > > large scale attack could swamp a DOTS server with all the yet to > > > be confirmed confirmable > > responses. > > > [Jon] As per RFC7252 "2.2. Request/Response Model", a response to > > > a > > > non- confirmable request is expected to be handled as in:- > > > If a request is sent in a Non-confirmable message, then the response > > > is sent using a new Non-confirmable message, although the server may > > > instead send a Confirmable message. This type of exchange is > > > illustrated in Figure 6. > > > > > > Client Server > > > | | > > > | NON [0x7a11] | > > > | GET /temperature | > > > | (Token 0x74) | > > > +----------------->| > > > | | > > > | NON [0x23bc] | > > > | 2.05 Content | > > > | (Token 0x74) | > > > | "22.5 C" | > > > |<-----------------+ > > > | | > > > > > > Figure 6: A Request and a Response Carried in Non-confirmable > > > Messages [Jon] So I would expect > > > any CoAP library to support this non-confirmation mechanism by > > > receiving a new non- confirmable message. It would be the > > > responsibility of the DOTS layer to associate the Tokens together > > > to handle the responses with > > the requests. > > > [Jon] In addition, when Observe is enabled, the DOTS server will > > > continue to generate non-confirmable messages with the same Token. > > > Again, the DOTS client will need to know what to do with the Token > > > (which could be to update things, or to send a RST if no more > > > packets with the same Token should be sent. > > > > > > > > > The spec of Confirmable message already have the retransmission > > > mechanism, so using Confirmable message is an easier way to notice > > > that the message has been lost during the attack time. > > > > > > [Jon] The DOTS client will know something is wrong as it will be > > > seeing heartbeat issues. > > > > > > I'm afraid I'm missing some previous discussions we made on the ML > > > and at the WG meeting, but we have a problem with the CoAP library > > > regarding this spec. > > > > > > * At the -08 version of the signal channel draft, this change was made: > > > DOTS mitigation request/response are marked as non-confirmable > > messages. > > > > > > thank you, > > > Kaname > > > > > > > > > _______________________________________________ > > > Dots mailing list > > > Dots@ietf.org > > > https://www.ietf.org/mailman/listinfo/dots > > > > > > _______________________________________________ > > > Dots mailing list > > > Dots@ietf.org > > > https://www.ietf.org/mailman/listinfo/dots > > > > > > _______________________________________________ > > > Dots mailing list > > > Dots@ietf.org > > > https://www.ietf.org/mailman/listinfo/dots > > > > _______________________________________________ > > Dots mailing list > > Dots@ietf.org > > https://www.ietf.org/mailman/listinfo/dots > > _______________________________________________ > Dots mailing list > Dots@ietf.org > https://www.ietf.org/mailman/listinfo/dots _______________________________________________ Dots mailing list Dots@ietf.org https://www.ietf.org/mailman/listinfo/dots From nobody Tue Jan 2 06:28:35 2018 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 9FF33126CD8 for ; Tue, 2 Jan 2018 06:28:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 TTV9gBU2jjjR for ; Tue, 2 Jan 2018 06:28:32 -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 D6C151201F8 for ; Tue, 2 Jan 2018 06:28:31 -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 1eWNYM-0006q0-4U; Tue, 02 Jan 2018 14:28:30 +0000 From: "Jon Shallow" To: "'Konda, Tirumaleswar Reddy'" , References: <073001d37b47$e6f27460$b4d75d20$@jpshallow.com> <094a01d3801f$20d94dd0$628be970$@jpshallow.com> <0b6101d383b5$48b29a20$da17ce60$@jpshallow.com> <0b8d01d383c5$9e0e4e50$da2aeaf0$@jpshallow.com> In-Reply-To: Date: Tue, 2 Jan 2018 14:28:28 -0000 Message-ID: <0bb601d383d5$f5084930$df18db90$@jpshallow.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0BB7_01D383D5.F50D0420" X-Mailer: Microsoft Outlook 14.0 Content-Language: en-gb Thread-Index: AQJTmGwWHKq+N1BT2oAOspP+fqvZXQF5x90cAibGkTgCTX2+CwJVOoraAgmqY9cC2iseVgDjex+aofAZy2A= Archived-At: Subject: Re: [Dots] Signal CBOR / JSON Mapping 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, 02 Jan 2018 14:28:35 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0BB7_01D383D5.F50D0420 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Tiru, See inline [Jon2] Regards Jon From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Jon Shallow Sent: Friday, December 29, 2017 2:32 AM To: Konda, Tirumaleswar Reddy ; dots@ietf.org Subject: Re: [Dots] Signal CBOR / JSON Mapping Hi Tiru, Thanks for pointing me to these references. RFC7951 6.1. Numeric Types A value of the "int8", "int16", "int32", "uint8", "uint16", or "uint32" type is represented as a JSON number. A value of the "int64", "uint64", or "decimal64" type is represented as a JSON string whose content is the lexical representation of the corresponding YANG type as specified in Sections 9.2.1 and 9.3.1 of [RFC7950]. For example, if the type of the leaf "foo" in Section 5.1 was "uint64" instead of "uint8", the instance would have to be encoded as "foo": "123" -- So, we now have a way of handling int64/uint64 which should be used moving forward. However, my JSON implementation (as well as many others I suspect) natively supports decimal64, so does not necessarily need to display it as a lexical representation string. Do we follow RFC7951 here as well? [TR] Let's not deviate from RFC7951 otherwise both drafts will end-up defining it's our own set of rules for encoding the YANG configuration data as JSON/CBOR text deviating from the existing standards. [Jon] Agreed I do not think that we should be following the augmented JSON parameter naming in RFC7951 "4. Names and Namespaces" otherwise we will start ending up with JSON/CBOR parameter names such as "ietf-dots-signal:mitigation-scope". If we do go with this, then the CBOR mapping table will need to get extended to cover the old, but some parameter name in different places. Comments? [TR] Both drafts should follow the naming in RFC7951. [Jon] I'm neutral on this, but agree to following standards - there will be however a lot of long parameter names which fortunately will get compressed by the CBOR mapping. However, draft-ietf-netmod-acl-model (albeit in xml not json) does not have parameter names such as "ietf-access-control-list:access-lists" [Jon1] We really need to come to an agreement on this one. I think I prefer simpler names, but any program based YANG -> JSON translator following RFC7951 will come up with the long names.. However as I understand "A namespace-qualified member name MUST be used for all members of a top-level JSON object and then also whenever the namespaces of the data node and its parent node are different. In all other cases, the simple form of the member name MUST be used." This probably only means that "ietf-dots-signal:mitigation-scope", "ietf-acl:acl-name", "ietf-acl:acl-type" and "ietf-dots-signal:signal-config" are the changes [TR2] Yes. (yes, acl-name & acl-type may be redefined in netconf-acl - do we really need acl-type?). [TR2] I did not get the above question ! [Jon2] In netconf-acl, acl-name and acl-type (a proposal is outstanding to rename them to name and type) both are a must when defined as a part of netconf-acl. However, acl-type is just a hint as to how to parse / handle the rest of the definitions. My question really was - as we are recording the acl-name as the conflict, do we also need to record acl-type as well. As we are working with YANG, JSON and CBOR interrelation , I still think we need a table similar to below to aid implementers - referring as appropriate to the different RFCs - no-one has full knowledge of all the evolving RFCs. [TR] I don't see the need to repeat, its already discussed in detail in https://tools.ietf.org/html/rfc8040#section-5.2 and similarly DOTS signal channel draft already refers to draft-ietf-core-yang-cbor-05. [Jon] Given the number of times we have been inconsistent with the YANG / JSON and CBOR definitions of a specific parameter, having a single place where all 3 variants are on the same line certainly helps me as an implementer. [TR1] I am trying to keep the CBOR mapping table simple (not too wide J), it can be updated to add YANG type. Why do we need the corresponding JSON type and JSON examples in the table ? [Jon1] I agree that we have a 72 character width limit. I do not think we need the JSON examples column, but do think we need the JSON type so we have YANG, CBOR and JSON equivalent types in one place. However, if the parameter names get long -e.g. "ietf-dots-signal:mitigation-scope", we will run out of width unless they are split over 2 lines. [TR2] Yes, some of the parameter names need to be split into 2 lines. DOTS signal channel does not deal with JSON encoding, what is the need to discuss equivalent JSON type in the signal channel draft ? [Jon2] I agree that all the data interchange between the DOTS peers will be in CBOR format, derived from the YANG model definition. However, the data channel has aliases defined in JSON from the YANG model definition, and at some point there has to be a mapping between CBOR and JSON when handling aliases. As all the examples of GET, PUT etc. in the signal draft are using JSON, making sure that JSON and CBOR is correctly mapped is helpful to me and maybe others (I read JSON better than CBOR!). [Jon1] NOTE. If we have to do changes to parameter names, this may be a suitable break point to re-sort the list by parameter name for ease of readability / lookup - especially if/as we are doing a lot of other fundamental changes post -14 with all the other discussions - time to clean things up! [TR] Sure. -Tiru Regards Jon From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of Konda, Tirumaleswar Reddy Sent: 23 December 2017 07:06 To: Jon Shallow; dots@ietf.org Subject: Re: [Dots] Signal CBOR / JSON Mapping We should just follow the CBOR Encoding of Data Modeled with YANG defined in https://tools.ietf.org/html/draft-ietf-core-yang-cbor-05 and JSON Encoding of Data Modeled with YANG defined in https://tools.ietf.org/html/rfc7951. -Tiru From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Jon Shallow Sent: Friday, December 22, 2017 10:41 PM To: dots@ietf.org Subject: [Dots] Signal CBOR / JSON Mapping Hi WG, There are a lot of YANG parameters that we are using that are defined as int64. JSON only safely supports up to 53 bits of precision. RFC 7493 2.2 Numbers An I-JSON sender cannot expect a receiver to treat an integer whose absolute value is greater than 9007199254740991 (i.e., that is outside the range [-(2**53)+1, (2**53)-1]) as an exact value. For applications that require the exact interchange of numbers with greater magnitude or precision, it is RECOMMENDED to encode them in JSON string values. This requires that the receiving program understand the intended semantic of the value. An example would be 64-bit integers, even though modern hardware can deal with them, because of the limited scope of JavaScript numbers. RFC7049 3.6 Numbers CBOR-based protocols should take into account that different language environments pose different restrictions on the range and precision of numbers that are representable. For example, the JavaScript number system treats all numbers as floating point, which may result in silent loss of precision in decoding integers with more than 53 significant bits. A protocol that uses numbers should define its expectations on the handling of non-trivial numbers in decoders and receiving applications. ==== An option is to make all of these int64 decimal64 for the signal channel, but that does not cover the 64 bit counters in the netmod-acl. However, as the netmod-acl counters are also fed back via the mitigate status, we do not necessarily need to support the netmod-acl counters. If, however, we follow RFC 7493, in CBOR the data can be passed across as 64 bits, and as the parameter is a CBOR mapping, we can know how to encode / decode the JSON value as appropriate. However, RFC 7493 does not say whether this should be base64, base64url or numeric string representation (i.e. "1234567890"). RFC7049 refers to bignum (major type 6, tag value 2 or 3) should be encoded as base64url (4.1 Converting from CBOR to JSON) - but int64 can be held in CBOR as type 0 or 1. I prefer the numeric string representation as it is humanly easy to read and easy to convert into 64 bit integers. If we take this approach of using the parameter which is a CBOR mapping key to key off how to encode / decode the JSON, I would suggest that we could extend this to include IP addresses, Dates and client-identifiers (or their possible new names of request-nonce and client-domain-hash) to further minimize the actual number of bytes sent in a COAP packet. The CBOR mapping Table could then be extended to look something like (but it is too wide I think) /----------------------+-------------+------+---------------+--------+------ ---\ | Parameter name | YANG type | CBOR | CBOR major | JSON | JSON | | | | key | type | type | Example | |----------------------+-------------+------+---------------+--------+------ ---| | mitigation-scope | grouping | 1 | 5 map | Object | | | scope | list | 2 | 4 array | Array | | | mitigation-id | int32 | 3 | 0 unsigned | Number | 54321 | | acl-list | list | 4 | 4 array | Array | | | target-port-range | list | 5 | 4 array | Array | | | lower-port | port-number | 6 | 0 number | Number | 1111 | | upper-port | port-number | 7 | 0 number | Number | 1111 | | target-protocol | leaf-list | | 4 array | Array | | | | uint8 | 8 | 0 number | Number | 6 | | target-fqdn | leaf-list | | 4 array | Array | | | | domain-name | 9 | 3 text string | String | "a.com" | | target-uri | leaf-list | | 4 array | Array | | | | uri | 10 | 3 text string | String | | | alias-name | leaf-list | | 4 array | Array | | | | string | 11 | 3 text string | String | "web" | | lifetime | int32 | 12 | 0 number | Number | | | attack-status | enumeration | 13 | 0 number | Number | 1 | | signal-config | grouping | 14 | 5 map | Object | | | heartbeat-interval | grouping | 15 | 5 map | Object | | | max-retransmit | grouping | 16 | 5 map | Object | | | ack-timeout | grouping | 17 | 5 map | Object | | | ack-random-factor | grouping | 18 | 5 map | Object | | | min-value | int16 | 19 | 0 number | Number | 1 | | max-value | int16 | 20 | 0 number | Number | 1 | | status | enumeration | 21 | 0 number | Number | 1 | | conflict-information | grouping | 22 | 5 map | Object | | | conflict-status | enumeration | 23 | 0 number | Number | 1 | | conflict-cause | enumeration | 24 | 0 number | Number | 1 | | retry-timer | int32 | 25 | 0 number | Number | 1800 | | bytes-dropped | counter64 | 26 | 0 number | String | "1234" | | bps-dropped | counter64 | 27 | 0 number | String | "1234" | | pkts-dropped | counter64 | 28 | 0 number | String | "1234" | | pps-dropped | counter64 | 29 | 0 number | String | "1234" | | session-id | int32 | 30 | 0 number | Number | 65432 | | trigger-mitigation | boolean | 31 | 7 simple | T / F | | | missing-hb-allowed | grouping | 32 | 5 map | Object | | | current-value | int16 | 33 | 0 number | Number | 10 | | mitigation-start | decimal64 | 34 | 7 FP | Number | 10.21 | | target-prefix | leaf-list | | 4 array | Array | | | | ip-prefix | 35 | 3 text string | String | | | client-domain-hash | leaf-list | | 4 array | Array | | | | binary | 36 | 2 byte string | String | "abcdf" | | alt-server | string | 37 | 3 text string | String | | | alt-server-record | list | 38 | 4 array | Array | | | addr | string | 39 | 3 text string | String | | | ttl | int32 | 40 | 0 number | Number | 1800 | | conflict-scope | grouping | 41 | 5 map | Object | | | acl-name | string | 42 | 3 text string | String | "aname" | | acl-type | string | 43 | 3 text string | String | "ipv4" | | config-interval | int32 | 44 | 0 number | Number | 11 | | mitigating-config | grouping | 45 | 5 map | Object | | | idle-config | grouping | 46 | 5 map | Object | | | request-nonce | binary | 47 | 2 byte string | String | "xxx" | | min-value-decimal | decimal64 | 48 | 7 FP | Number | 1.1 | | max-value-decimal | decimal64 | 49 | 7 FP | Number | 1.1 | | current-value-decimal| decimal64 | 50 | 7 FP | Number | 1.1 | \----------------------+-------------+------+---------------+--------+------ ---/ Comments / suggestions? Regards Jon ------=_NextPart_000_0BB7_01D383D5.F50D0420 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Tiru,

 

See inline = [Jon2]

 

Regards

 

Jon

 

 

 

From: Dots [mailto:dots-bounces@ietf.org] = On Behalf Of Jon Shallow
Sent: Friday, December 29, = 2017 2:32 AM
To: Konda, Tirumaleswar Reddy <TirumaleswarReddy_Kond= a@McAfee.com>; dots@ietf.org
Subject: Re: = [Dots] Signal CBOR / JSON Mapping

 

Hi = Tiru,

 

Thanks for pointing me = to these references.

 

RFC7951

6.1.  Numeric = Types

 

   A value of = the "int8", "int16", "int32", = "uint8", "uint16", or

   = "uint32" type is represented as a JSON = number.

 

   A value of = the "int64", "uint64", or "decimal64" type = is represented

   as a JSON string whose content is = the lexical representation of the

   = corresponding YANG type as specified in Sections 9.2.1 and 9.3.1 = of

   [RFC7950].

 

   For = example, if the type of the leaf "foo" in Section 5.1 = was

   "uint64" instead of = "uint8", the instance would have to be encoded = as

 

   = "foo": "123"

--

 

So, we now have a way of = handling int64/uint64 which should be used moving = forward.

 

However, my JSON = implementation (as well as many others I suspect) natively supports = decimal64, so does not necessarily need to display it as a lexical = representation string.  Do we follow RFC7951 here as = well?

 

[TR] Let’s not deviate from RFC7951 otherwise = both drafts will end-up defining it’s our own set of rules for = encoding the YANG configuration data as JSON/CBOR text deviating from = the existing standards.

[Jon] Agreed

 

I do not think that we = should be following the augmented JSON parameter naming in RFC7951 = “4. Names and Namespaces” otherwise we will start ending up = with JSON/CBOR parameter names such as = “ietf-dots-signal:mitigation-scope”.  If we do go with = this, then the CBOR mapping table will need to get extended to cover the = old, but some parameter name in different places.  = Comments?

 

[TR] Both = drafts should follow the naming in RFC7951.

[Jon] I’m neutral on this, but agree to = following standards – there will be however a lot of long = parameter names which fortunately will get compressed by the CBOR = mapping.  However, draft-ietf-netmod-acl-model (albeit in xml not = json) does not have parameter names such as = “ietf-access-control-list:access-lists”

=

[Jon1] We really need = to come to an agreement on this one.  I think I prefer simpler = names, but any program based YANG -> JSON translator following = RFC7951 will come up with the long names….  However as I = understand

“A = namespace-qualified member name MUST be used for all members of = a

   = top-level JSON object and then also whenever the namespaces of = the

   = data node and its parent node are different.  In all other cases, = the

   simple form of the member name MUST = be used.”

This probably only means that = “ietf-dots-signal:mitigation-scope”, = “ietf-acl:acl-name”, “ietf-acl:acl-type” and = “ietf-dots-signal:signal-config” are the changes =

 

[TR2] Yes.

 

(yes, acl-name & acl-type may be redefined = in netconf-acl – do we really need = acl-type?).

 

[TR2] I did = not get the above question !

 

[Jon2] In netconf-acl, = acl-name and acl-type (a proposal is outstanding to rename them to name = and type) both are a must when defined as a part of netconf-acl.  = However, acl-type is just a hint as to how to parse / handle the rest of = the definitions.  My question really was - as we are recording the = acl-name as the conflict, do we also need to record acl-type as = well.

 

As we are working with = YANG, JSON and CBOR interrelation , I still think we need a table = similar to below to aid implementers – referring as appropriate to = the different RFCs – no-one has full knowledge of all the evolving = RFCs.

 

[TR] I don’t see the need to repeat, its already = discussed in detail in https://tools.ie= tf.org/html/rfc8040#section-5.2 and similarly DOTS signal channel = draft already refers to draft-ietf-core-yang-cbor-05.

[Jon] Given the number = of times we have been inconsistent with the YANG / JSON and CBOR = definitions of a specific parameter, having a single place where all 3 = variants are on the same line certainly helps me as an = implementer.

 

[TR1] I am = trying to keep the CBOR mapping table simple (not too wide J), it can be updated to add YANG = type. Why do we need the corresponding JSON type and JSON examples in = the table ?

[Jon1] I agree that we have a 72 character width = limit.  I do not think we need the JSON examples column, but do = think we need the JSON type so we have YANG, CBOR and JSON equivalent = types in one place.  However, if the parameter names get long = –e.g. “ietf-dots-signal:mitigation-scope”, we will run = out of width unless they are split over 2 lines.

 

[TR2] Yes, = some of the parameter names need to be split into 2 lines. DOTS signal = channel does not deal with JSON encoding, what is the need to discuss = equivalent JSON type in the signal channel draft =  ?

 

[Jon2] I agree that all = the data interchange between the DOTS peers will be in CBOR format, = derived from the YANG model definition.  However, the data channel = has aliases defined in JSON from the YANG model definition, and at some = point there has to be a mapping between CBOR and JSON when handling = aliases.  As all the examples of GET, PUT etc. in the signal draft = are using JSON, making sure that JSON and CBOR is correctly mapped is = helpful to me and maybe others (I read JSON better than CBOR!).  =

 

[Jon1] NOTE.  If we = have to do changes to parameter names, this may be a suitable break = point to re-sort the list by parameter name for ease of readability / = lookup – especially if/as we are doing a lot of other fundamental = changes post -14 with all the other discussions – time to clean = things up!

 

[TR] Sure. =

 

-Tiru

 

Regards

 

Jon

 

From: Dots [mailto: dots-bounces@ietf.org] On = Behalf Of Konda, Tirumaleswar Reddy
Sent: 23 December 2017 = 07:06
To: Jon Shallow; dots@ietf.org
Subject: Re: = [Dots] Signal CBOR / JSON Mapping

 

We should just follow = the CBOR Encoding of Data Modeled with YANG defined in https:/= /tools.ietf.org/html/draft-ietf-core-yang-cbor-05 and JSON Encoding = of Data Modeled with YANG

defined in https://tools.ietf.org/html/= rfc7951.

 

-Tiru

 

From: Dots [mailto:dots-bounces@ietf.org] = On Behalf Of Jon Shallow
Sent: Friday, December 22, = 2017 10:41 PM
To: dots@ietf.org
Subject: = [Dots] Signal CBOR / JSON Mapping

 

Hi WG,

 

There are a = lot of YANG parameters that we are using that are defined as = int64.  JSON only safely supports up to 53 bits of = precision.

 

RFC 7493 2.2 Numbers

 

   = An I-JSON sender cannot expect a receiver to treat an integer = whose

   absolute value is = greater than 9007199254740991 (i.e., that is

   outside the range [-(2**53)+1, = (2**53)-1]) as an exact value.

 

   = For applications that require the exact interchange of numbers = with

   greater magnitude = or precision, it is RECOMMENDED to encode them in

   JSON string values.  This requires = that the receiving program

   understand the intended semantic of the = value.  An example would be

   64-bit integers, even though modern = hardware can deal with them,

   because of the limited scope of = JavaScript numbers.

 

RFC7049 3.6 = Numbers

 

   CBOR-based protocols should take into = account that different language

   environments pose different restrictions = on the range and precision

   of numbers that are representable.  = For example, the JavaScript

   number system treats all numbers as = floating point, which may result

   in silent loss of precision in decoding = integers with more than 53

   significant bits.  A protocol that = uses numbers should define its

   expectations on the handling of = non-trivial numbers in decoders and

   receiving applications.

 

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

 

An option is = to make all of these int64 decimal64 for the signal channel, but that = does not cover the 64 bit counters in the netmod-acl.  However, as = the netmod-acl counters are also fed back via the mitigate status, we do = not necessarily need to support the netmod-acl = counters.

 

If, however, we follow RFC 7493, in CBOR the data can = be passed across as 64 bits, and as the parameter is a CBOR mapping, we = can know how to encode / decode the JSON value as appropriate.  = However, RFC 7493 does not say whether this should be base64, base64url = or numeric string representation (i.e. “1234567890”). =  RFC7049 refers to bignum (major type 6, tag value 2 or 3) should = be encoded as base64url (4.1 Converting from CBOR to JSON) – but = int64 can be held in CBOR as type 0 or 1.

 

I prefer the = numeric string representation as it is humanly easy to read and easy to = convert into 64 bit integers.

 

If we take = this approach of using the parameter which is a CBOR mapping key to key = off how to encode / decode the JSON, I would suggest that we could = extend this to include IP addresses, Dates and client-identifiers (or = their possible new names of request-nonce and client-domain-hash) to = further minimize the actual number of bytes sent in a COAP = packet.

 

The CBOR mapping Table could then be extended to look = something like (but it is too wide I think)

 

/----------------------+-------------+------+--------------= -+--------+---------\

| Parameter = name       | YANG type   | CBOR = | CBOR major    | JSON   | = JSON    | 

|         &nbs= p;            = |            = | key  | = type          | = type   | Example |

|----------------------+-------------+------+--------------= -+--------+---------|

| = mitigation-scope     | grouping    = |   1  | 5 = map         | Object = |         |  =

| = scope           &n= bsp;    | list        = |   2  | 4 array       | = Array  |         |  =

| = mitigation-id        | = int32       |   3  | 0 = unsigned    | Number | 54321   |  =

| = acl-list        =      | = list        |   4  | 4 = array       | Array  = |         |  =

| = target-port-range    | = list        |   5  | 4 = array       | Array  = |         |  =

| = lower-port           | = port-number |   6  | 0 = number      | Number | 1111    = | 

| = upper-port           | = port-number |   7  | 0 = number      | Number | 1111    = | 

| = target-protocol      | leaf-list   = |      | 4 = array       | Array  = |         |  =

|         &nbs= p;            | = uint8       |   8  | 0 = number      | Number | = 6       |

| = target-fqdn          | = leaf-list   |      | 4 = array       | Array  = |         = |

|         &nbs= p;            | = domain-name |   9  | 3 text string | String | = "a.com" |

| = target-uri           | = leaf-list   |      | 4 = array       | Array  = |         |  =

|         &nbs= p;            | = uri         |  10  | 3 = text string | String |         = |

| = alias-name           | = leaf-list   |      | 4 = array       | Array  | =         |  =

| =             &= nbsp;        | = string      |  11  | 3 text string | = String | "web"   | 

| = lifetime           = ;  | int32       |  12  | 0 = number      | Number = |         |  =

| = attack-status        | enumeration = |  13  | 0 number      | Number | = 1       | 

| signal-config        = | grouping    |  14  | 5 = map         | Object = |         |  =

| = heartbeat-interval   | grouping    |  = 15  | 5 map         | = Object |         |  =

| = max-retransmit       | = grouping    |  16  | 5 = map         | Object = |         |  =

| = ack-timeout          | = grouping    |  17  | 5 = map         | Object = |         |  =

| = ack-random-factor    | grouping    |  = 18  | 5 map         | = Object |         |  =

| = min-value   =          | = int16       |  19  | 0 = number      | Number | = 1       | 

| = max-value          &nbs= p; | int16       |  20  | 0 = number      | Number | = 1       | 

| = status           &= nbsp;   | enumeration |  21  | 0 = number      | Number | = 1       | 

| conflict-information | grouping    = |  22  | 5 map         = | Object |         |  =

| = conflict-status      | enumeration |  = 23  | 0 number      | Number | = 1       | 

| conflict-cause       | = enumeration |  24  | 0 number      | = Number | 1       |  =

| = retry-timer          | = int32       |  25  | 0 = number      | Number | 1800    = | 

| = bytes-dropped        | = counter64   |  26  | 0 = number      | String | "1234"  = | 

| = bps-dropped          | = counter64   |  27  | 0 = number      | String | "1234"  = | 

| = pkts-dropped         | counter64 =   |  28  | 0 number      | = String | "1234"  | 

| = pps-dropped          | = counter64   |  29  | 0 = number      | String | "1234"  = | 

| = session-id           | = int32       |  30  | 0 = number      | Number | 65432   = | 

| = trigger-mitigation   | boolean     |  = 31  | 7 simple      | T / F  = |         |  =

| = missing-hb-allowed   | grouping    |  = 32  | 5 map         | = Object |         |  =

| = current-value        | = int16       |  33  | 0 = number      | Number | = 10      | 

| mitigation-start     | = decimal64   |  34  | 7 = FP          | Number | = 10.21   | 

| target-prefix        = | leaf-list   |      | 4 = array       | Array  = |         |  =

| =             &= nbsp;        | = ip-prefix   |  35  | 3 text string | String = |         |  =

| = client-domain-hash   | leaf-list   |  =     | 4 array       | = Array  |         = |

| =             &= nbsp;        | = binary      |  36  | 2 byte string | = String | "abcdf" |

| = alt-server           | = string      |  37  | 3 text string | = String |         |  =

| = alt-server-record    | = list        |  38  | 4 = array       | Array  = |         |  =

| = addr           &nb= sp;     | string      = |  39  | 3 text string | String = |         |  =

| = ttl           &nbs= p;      | = int32       |  40  | 0 = number      | Number | 1800    = | 

| = conflict-scope       | = grouping    |  41  | 5 = map         | Object = |         |  =

| = acl-name           = ;  | string      |  42  | 3 text = string | String | "aname" | 

| = acl-type           = ;  | string      |  43  | 3 text = string | String | "ipv4"  |  =

| = config-interval      | = int32       |  44  | 0 = number      | Number | = 11      | 

| mitigating-config    | = grouping    |  45  | 5 = map         | Object = |         |  =

| = idle-config          | = grouping    |  46  | 5 = map         | Object = |         |  =

| = request-nonce        | = binary      |  47  | 2 byte string | = String | "xxx"   | 

| min-value-decimal    | = decimal64   |  48  | 7 = FP          | Number | = 1.1     | 

| max-value-decimal    | = decimal64   |  49  | 7 = FP          | Number | = 1.1     | 

| current-value-decimal| decimal64   |  = 50  | 7 FP          | = Number | 1.1     | 

\----------------------+-------------+------+--------------= -+--------+---------/

 

 

Comments / = suggestions?

 

Regards

 

Jon

= ------=_NextPart_000_0BB7_01D383D5.F50D0420-- From nobody Tue Jan 2 07:04:14 2018 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 BB1FA126CD8 for ; Tue, 2 Jan 2018 07:04:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.33 X-Spam-Level: X-Spam-Status: No, score=-4.33 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, T_RP_MATCHES_RCVD=-0.01] 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 C1SjUpqVkgAJ for ; Tue, 2 Jan 2018 07:04:09 -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 616A6124BAC for ; Tue, 2 Jan 2018 07:04: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=1514905448; 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:x-microsoft-antispam-message-info: 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=Zh48ve6NMmwuV/9wdBjsDEM4HQNjI6Bs1UilkM otKB4=; b=V+8BfuDVr7+0GLb10e3htUt5VGW+93/VTknuPLw3 ResVL5mazZZpjwrZyn97Klu4MmfsKP3puQQkwNmWvnunNuMz4U 8KTQNc0KmOInF/v+wu40fycGV1iHzCPiR7+1T5DG2lQ8TX74xT jGAdIDKrnIBErrFq1dkSVOrfqu+axVI= Received: from DNVEXAPP1N05.corpzone.internalzone.com (unknown [10.44.48.89]) by DNVWSMAILOUT1.mcafee.com with smtp (TLS: TLSv1/SSLv3,256bits,ECDHE-RSA-AES256-SHA384) id 1717_6a6a_8a9c3a98_fbe6_4018_a18c_c33819ac2750; Tue, 02 Jan 2018 09:04:07 -0600 Received: from DNVEXUSR1N11.corpzone.internalzone.com (10.44.48.84) by DNVEXAPP1N05.corpzone.internalzone.com (10.44.48.89) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Tue, 2 Jan 2018 08:04:06 -0700 Received: from DNVEXUSR1N12.corpzone.internalzone.com (10.44.48.85) by DNVEXUSR1N11.corpzone.internalzone.com (10.44.48.84) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Tue, 2 Jan 2018 08:04:04 -0700 Received: from DNVO365EDGE2.corpzone.internalzone.com (10.44.176.74) by DNVEXUSR1N12.corpzone.internalzone.com (10.44.48.85) with Microsoft SMTP Server (TLS) id 15.0.1347.2 via Frontend Transport; Tue, 2 Jan 2018 08:04:04 -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; Tue, 2 Jan 2018 08:04:02 -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.366.8; Tue, 2 Jan 2018 15:04: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.0366.009; Tue, 2 Jan 2018 15:04:02 +0000 From: "Konda, Tirumaleswar Reddy" To: Jon Shallow , "dots@ietf.org" Thread-Topic: [Dots] Signal CBOR / JSON Mapping Thread-Index: AdN7R9961HXkMq2tTZepG2+xKMly9QAclUqwARk68QAA4qNgAAAC5pyAAAHp+uAAAitXAAACB1IAAAIOcgAAARQUIA== Date: Tue, 2 Jan 2018 15:04:02 +0000 Message-ID: References: <073001d37b47$e6f27460$b4d75d20$@jpshallow.com> <094a01d3801f$20d94dd0$628be970$@jpshallow.com> <0b6101d383b5$48b29a20$da17ce60$@jpshallow.com> <0b8d01d383c5$9e0e4e50$da2aeaf0$@jpshallow.com> <0bb601d383d5$f5084930$df18db90$@jpshallow.com> In-Reply-To: <0bb601d383d5$f5084930$df18db90$@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.72.75] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DM5PR16MB1787; 7:MtNWoRxrrD9eW+sxzGq8Wg1KkmASLMCEK5pOm5XTcWc1lC7XeNU282+Gst6+H1ZqTEgM1osxqtjw8ajuvUJwj6Ss1Y1kt5Sy4vJ5wZqRNWsXCdcBKPERo71y97MvXcrE8W0whhdP/3q3A25r43hiAWb3f2oOA50CzrCfduJ0feVU/LZOc7ZBkYyimsjAUc0paE6Sc+opbrc/tN89qo1xVrFX7bTj37m+JpU+PGcP9mjTUc2ekLvTzCOt0Jg8TukS x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: ffeb818e-6ccf-4248-e67a-08d551f20f7c x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(5600026)(4604075)(3008032)(2017052603307)(7153060); SRVR:DM5PR16MB1787; x-ms-traffictypediagnostic: DM5PR16MB1787: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(278428928389397)(21748063052155)(123452027830198); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040470)(2401047)(8121501046)(5005006)(10201501046)(93006095)(93001095)(3231023)(944501075)(3002001)(6041268)(20161123560045)(20161123558120)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123562045)(20161123564045)(6072148)(201708071742011); SRVR:DM5PR16MB1787; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:DM5PR16MB1787; x-forefront-prvs: 0540846A1D x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39860400002)(346002)(366004)(39380400002)(396003)(376002)(57704003)(189003)(199004)(32952001)(86362001)(561944003)(110136005)(8676002)(2906002)(2900100001)(9686003)(25786009)(790700001)(19609705001)(3846002)(6116002)(478600001)(7736002)(72206003)(80792005)(77096006)(2950100002)(966005)(606006)(105586002)(5660300001)(33656002)(74316002)(97736004)(14454004)(106356001)(2501003)(6246003)(93886005)(236005)(66066001)(229853002)(55016002)(68736007)(53946003)(6436002)(6506007)(9326002)(53936002)(81166006)(81156014)(3660700001)(7696005)(53546011)(3280700002)(99286004)(316002)(54896002)(6306002)(76176011)(102836004)(59450400001)(8936002)(21314002)(85282002)(579004); 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) x-microsoft-antispam-message-info: wiZV8eM4X3jci7mkS4Ug7XQhhqjFbRTwNJOSrnyYnn5Ij48vJGdzQNRsedHAcgORLVvA3U/My+PYgcyBIx1oUw== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_DM5PR16MB1788A6BF1D42084013466C82EA190DM5PR16MB1788namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: ffeb818e-6ccf-4248-e67a-08d551f20f7c X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Jan 2018 15:04:02.5322 (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 <6191> : inlines <6292> : streams <1774896> : uri <2561812> Archived-At: Subject: Re: [Dots] Signal CBOR / JSON Mapping 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, 02 Jan 2018 15:04:14 -0000 --_000_DM5PR16MB1788A6BF1D42084013466C82EA190DM5PR16MB1788namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Jon, Please see inline [TR3] From: Jon Shallow [mailto:supjps-ietf@jpshallow.com] Sent: Tuesday, January 2, 2018 7:58 PM To: Konda, Tirumaleswar Reddy ; dots@ie= tf.org Subject: RE: [Dots] Signal CBOR / JSON Mapping Hi Tiru, See inline [Jon2] Regards Jon From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Jon Shallow Sent: Friday, December 29, 2017 2:32 AM To: Konda, Tirumaleswar Reddy >; dots@ietf.org Subject: Re: [Dots] Signal CBOR / JSON Mapping Hi Tiru, Thanks for pointing me to these references. RFC7951 6.1. Numeric Types A value of the "int8", "int16", "int32", "uint8", "uint16", or "uint32" type is represented as a JSON number. A value of the "int64", "uint64", or "decimal64" type is represented as a JSON string whose content is the lexical representation of the corresponding YANG type as specified in Sections 9.2.1 and 9.3.1 of [RFC7950]. For example, if the type of the leaf "foo" in Section 5.1 was "uint64" instead of "uint8", the instance would have to be encoded as "foo": "123" -- So, we now have a way of handling int64/uint64 which should be used moving = forward. However, my JSON implementation (as well as many others I suspect) natively= supports decimal64, so does not necessarily need to display it as a lexica= l representation string. Do we follow RFC7951 here as well? [TR] Let's not deviate from RFC7951 otherwise both drafts will end-up defin= ing it's our own set of rules for encoding the YANG configuration data as J= SON/CBOR text deviating from the existing standards. [Jon] Agreed I do not think that we should be following the augmented JSON parameter nam= ing in RFC7951 "4. Names and Namespaces" otherwise we will start ending up = with JSON/CBOR parameter names such as "ietf-dots-signal:mitigation-scope".= If we do go with this, then the CBOR mapping table will need to get exten= ded to cover the old, but some parameter name in different places. Comment= s? [TR] Both drafts should follow the naming in RFC7951. [Jon] I'm neutral on this, but agree to following standards - there will be= however a lot of long parameter names which fortunately will get compresse= d by the CBOR mapping. However, draft-ietf-netmod-acl-model (albeit in xml= not json) does not have parameter names such as "ietf-access-control-list:= access-lists" [Jon1] We really need to come to an agreement on this one. I think I prefe= r simpler names, but any program based YANG -> JSON translator following RF= C7951 will come up with the long names.... However as I understand "A namespace-qualified member name MUST be used for all members of a top-level JSON object and then also whenever the namespaces of the data node and its parent node are different. In all other cases, the simple form of the member name MUST be used." This probably only means that "ietf-dots-signal:mitigation-scope", "ietf-ac= l:acl-name", "ietf-acl:acl-type" and "ietf-dots-signal:signal-config" are t= he changes [TR2] Yes. (yes, acl-name & acl-type may be redefined in netconf-acl - do we really ne= ed acl-type?). [TR2] I did not get the above question ! [Jon2] In netconf-acl, acl-name and acl-type (a proposal is outstanding to = rename them to name and type) both are a must when defined as a part of net= conf-acl. However, acl-type is just a hint as to how to parse / handle the= rest of the definitions. My question really was - as we are recording the= acl-name as the conflict, do we also need to record acl-type as well. [TR3] Yes. As we are working with YANG, JSON and CBOR interrelation , I still think we= need a table similar to below to aid implementers - referring as appropria= te to the different RFCs - no-one has full knowledge of all the evolving RF= Cs. [TR] I don't see the need to repeat, its already discussed in detail in htt= ps://tools.ietf.org/html/rfc8040#section-5.2 and similarly DOTS signal chan= nel draft already refers to draft-ietf-core-yang-cbor-05. [Jon] Given the number of times we have been inconsistent with the YANG / J= SON and CBOR definitions of a specific parameter, having a single place whe= re all 3 variants are on the same line certainly helps me as an implementer= . [TR1] I am trying to keep the CBOR mapping table simple (not too wide :)), = it can be updated to add YANG type. Why do we need the corresponding JSON t= ype and JSON examples in the table ? [Jon1] I agree that we have a 72 character width limit. I do not think we = need the JSON examples column, but do think we need the JSON type so we hav= e YANG, CBOR and JSON equivalent types in one place. However, if the param= eter names get long -e.g. "ietf-dots-signal:mitigation-scope", we will run = out of width unless they are split over 2 lines. [TR2] Yes, some of the parameter names need to be split into 2 lines. DOTS = signal channel does not deal with JSON encoding, what is the need to discus= s equivalent JSON type in the signal channel draft ? [Jon2] I agree that all the data interchange between the DOTS peers will be= in CBOR format, derived from the YANG model definition. However, the data= channel has aliases defined in JSON from the YANG model definition, and at= some point there has to be a mapping between CBOR and JSON when handling a= liases. As all the examples of GET, PUT etc. in the signal draft are using= JSON, making sure that JSON and CBOR is correctly mapped is helpful to me = and maybe others (I read JSON better than CBOR!). [TR3] Okay, will update the table to include YANG and JSON types. -Tiru [Jon1] NOTE. If we have to do changes to parameter names, this may be a su= itable break point to re-sort the list by parameter name for ease of readab= ility / lookup - especially if/as we are doing a lot of other fundamental c= hanges post -14 with all the other discussions - time to clean things up! [TR] Sure. -Tiru Regards Jon From: Dots [mailto: dots-bounces@ietf.org] On= Behalf Of Konda, Tirumaleswar Reddy Sent: 23 December 2017 07:06 To: Jon Shallow; dots@ietf.org Subject: Re: [Dots] Signal CBOR / JSON Mapping We should just follow the CBOR Encoding of Data Modeled with YANG defined i= n https://tools.ietf.org/html/draft-ietf-core-yang-cbor-05 and JSON Encodin= g of Data Modeled with YANG defined in https://tools.ietf.org/html/rfc7951. -Tiru From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Jon Shallow Sent: Friday, December 22, 2017 10:41 PM To: dots@ietf.org Subject: [Dots] Signal CBOR / JSON Mapping Hi WG, There are a lot of YANG parameters that we are using that are defined as in= t64. JSON only safely supports up to 53 bits of precision. RFC 7493 2.2 Numbers An I-JSON sender cannot expect a receiver to treat an integer whose absolute value is greater than 9007199254740991 (i.e., that is outside the range [-(2**53)+1, (2**53)-1]) as an exact value. For applications that require the exact interchange of numbers with greater magnitude or precision, it is RECOMMENDED to encode them in JSON string values. This requires that the receiving program understand the intended semantic of the value. An example would be 64-bit integers, even though modern hardware can deal with them, because of the limited scope of JavaScript numbers. RFC7049 3.6 Numbers CBOR-based protocols should take into account that different language environments pose different restrictions on the range and precision of numbers that are representable. For example, the JavaScript number system treats all numbers as floating point, which may result in silent loss of precision in decoding integers with more than 53 significant bits. A protocol that uses numbers should define its expectations on the handling of non-trivial numbers in decoders and receiving applications. =3D=3D=3D=3D An option is to make all of these int64 decimal64 for the signal channel, b= ut that does not cover the 64 bit counters in the netmod-acl. However, as = the netmod-acl counters are also fed back via the mitigate status, we do no= t necessarily need to support the netmod-acl counters. If, however, we follow RFC 7493, in CBOR the data can be passed across as 6= 4 bits, and as the parameter is a CBOR mapping, we can know how to encode /= decode the JSON value as appropriate. However, RFC 7493 does not say whet= her this should be base64, base64url or numeric string representation (i.e.= "1234567890"). RFC7049 refers to bignum (major type 6, tag value 2 or 3) = should be encoded as base64url (4.1 Converting from CBOR to JSON) - but int= 64 can be held in CBOR as type 0 or 1. I prefer the numeric string representation as it is humanly easy to read an= d easy to convert into 64 bit integers. If we take this approach of using the parameter which is a CBOR mapping key= to key off how to encode / decode the JSON, I would suggest that we could = extend this to include IP addresses, Dates and client-identifiers (or their= possible new names of request-nonce and client-domain-hash) to further min= imize the actual number of bytes sent in a COAP packet. The CBOR mapping Table could then be extended to look something like (but i= t is too wide I think) /----------------------+-------------+------+---------------+--------+-----= ----\ | Parameter name | YANG type | CBOR | CBOR major | JSON | JSON= | | | | key | type | type | Exam= ple | |----------------------+-------------+------+---------------+--------+-----= ----| | mitigation-scope | grouping | 1 | 5 map | Object | = | | scope | list | 2 | 4 array | Array | = | | mitigation-id | int32 | 3 | 0 unsigned | Number | 5432= 1 | | acl-list | list | 4 | 4 array | Array | = | | target-port-range | list | 5 | 4 array | Array | = | | lower-port | port-number | 6 | 0 number | Number | 1111= | | upper-port | port-number | 7 | 0 number | Number | 1111= | | target-protocol | leaf-list | | 4 array | Array | = | | | uint8 | 8 | 0 number | Number | 6 = | | target-fqdn | leaf-list | | 4 array | Array | = | | | domain-name | 9 | 3 text string | String | "a.c= om" | | target-uri | leaf-list | | 4 array | Array | = | | | uri | 10 | 3 text string | String | = | | alias-name | leaf-list | | 4 array | Array | = | | | string | 11 | 3 text string | String | "web= " | | lifetime | int32 | 12 | 0 number | Number | = | | attack-status | enumeration | 13 | 0 number | Number | 1 = | | signal-config | grouping | 14 | 5 map | Object | = | | heartbeat-interval | grouping | 15 | 5 map | Object | = | | max-retransmit | grouping | 16 | 5 map | Object | = | | ack-timeout | grouping | 17 | 5 map | Object | = | | ack-random-factor | grouping | 18 | 5 map | Object | = | | min-value | int16 | 19 | 0 number | Number | 1 = | | max-value | int16 | 20 | 0 number | Number | 1 = | | status | enumeration | 21 | 0 number | Number | 1 = | | conflict-information | grouping | 22 | 5 map | Object | = | | conflict-status | enumeration | 23 | 0 number | Number | 1 = | | conflict-cause | enumeration | 24 | 0 number | Number | 1 = | | retry-timer | int32 | 25 | 0 number | Number | 1800= | | bytes-dropped | counter64 | 26 | 0 number | String | "123= 4" | | bps-dropped | counter64 | 27 | 0 number | String | "123= 4" | | pkts-dropped | counter64 | 28 | 0 number | String | "123= 4" | | pps-dropped | counter64 | 29 | 0 number | String | "123= 4" | | session-id | int32 | 30 | 0 number | Number | 6543= 2 | | trigger-mitigation | boolean | 31 | 7 simple | T / F | = | | missing-hb-allowed | grouping | 32 | 5 map | Object | = | | current-value | int16 | 33 | 0 number | Number | 10 = | | mitigation-start | decimal64 | 34 | 7 FP | Number | 10.2= 1 | | target-prefix | leaf-list | | 4 array | Array | = | | | ip-prefix | 35 | 3 text string | String | = | | client-domain-hash | leaf-list | | 4 array | Array | = | | | binary | 36 | 2 byte string | String | "abc= df" | | alt-server | string | 37 | 3 text string | String | = | | alt-server-record | list | 38 | 4 array | Array | = | | addr | string | 39 | 3 text string | String | = | | ttl | int32 | 40 | 0 number | Number | 1800= | | conflict-scope | grouping | 41 | 5 map | Object | = | | acl-name | string | 42 | 3 text string | String | "ana= me" | | acl-type | string | 43 | 3 text string | String | "ipv= 4" | | config-interval | int32 | 44 | 0 number | Number | 11 = | | mitigating-config | grouping | 45 | 5 map | Object | = | | idle-config | grouping | 46 | 5 map | Object | = | | request-nonce | binary | 47 | 2 byte string | String | "xxx= " | | min-value-decimal | decimal64 | 48 | 7 FP | Number | 1.1 = | | max-value-decimal | decimal64 | 49 | 7 FP | Number | 1.1 = | | current-value-decimal| decimal64 | 50 | 7 FP | Number | 1.1 = | \----------------------+-------------+------+---------------+--------+-----= ----/ Comments / suggestions? Regards Jon --_000_DM5PR16MB1788A6BF1D42084013466C82EA190DM5PR16MB1788namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Jon,

&nbs= p;

Please se= e inline [TR3]

 

From:<= /span> Jon Shallow [mailto:s= upjps-ietf@jpshallow.com]
Sent: Tuesday, January 2, 2018 7:58 PM
To: Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@McAfee.com= >; dots@ietf.org
Subject: RE: [Dots] Signal CBOR / JSON Mapping

 

Hi Tiru= ,

&n= bsp;

See inl= ine [Jon2]

&n= bsp;

Regards=

&n= bsp;

Jon

&n= bsp;

&n= bsp;

&nbs= p;

From:<= /span> Dots [mailto:dots-bounces@ietf.org] On Behalf Of Jon Shallow
Sent: Friday, December 29, 2017 2:32 AM
To: Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@McAfee.com>; dots@ietf.org
Subject: Re: [Dots] Signal CBOR / JSON Mapping

 

Hi Tiru= ,

&n= bsp;

Thanks = for pointing me to these references.

&n= bsp;

RFC7951=

6.1.&nb= sp; Numeric Types

&n= bsp;

 &= nbsp; A value of the "int8", "int16", "int32"= , "uint8", "uint16", or

 &= nbsp; "uint32" type is represented as a JSON number.

&n= bsp;

 &= nbsp; A value of the "int64", "uint64", or "decima= l64" type is represented

 &= nbsp; as a JSON string whose content is the lexical representation of the

 &= nbsp; corresponding YANG type as specified in Sections 9.2.1 and 9.3.1 of

 &= nbsp; [RFC7950].

&n= bsp;

 &= nbsp; For example, if the type of the leaf "foo" in Section 5.1 w= as

 &= nbsp; "uint64" instead of "uint8", the instance would h= ave to be encoded as

&n= bsp;

 &= nbsp; "foo": "123"

--=

&n= bsp;

So, we = now have a way of handling int64/uint64 which should be used moving forward= .

&n= bsp;

However= , my JSON implementation (as well as many others I suspect) natively suppor= ts decimal64, so does not necessarily need to display it as a lexical repre= sentation string.  Do we follow RFC7951 here as well?

 

[TR] Let’s not deviate fr= om RFC7951 otherwise both drafts will end-up defining it’s our own se= t of rules for encoding the YANG configuration data as JSON/CBOR text devia= ting from the existing standards.

[Jon] A= greed

&n= bsp;

I do no= t think that we should be following the augmented JSON parameter naming in = RFC7951 “4. Names and Namespaces” otherwise we will start endin= g up with JSON/CBOR parameter names such as “ietf-dots-signal:mitigat= ion-scope”.  If we do go with this, then the CBOR mapping table will need to get extend= ed to cover the old, but some parameter name in different places.  Com= ments?

 

[TR] Both drafts should follow = the naming in RFC7951.

[Jon] I= ’m neutral on this, but agree to following standards – there wi= ll be however a lot of long parameter names which fortunately will get comp= ressed by the CBOR mapping.  However, draft-ietf-netmod-acl-model (albeit in xml not json) does not have parameter names such as “ietf= -access-control-list:access-lists”

[Jon1] = We really need to come to an agreement on this one.  I think I prefer = simpler names, but any program based YANG -> JSON translator following R= FC7951 will come up with the long names….  However as I understand

“A namespace-qualified member name MUST be used= for all members of a

   top-level JSON object and then also when= ever the namespaces of the

   data node and its parent node are differ= ent.  In all other cases, the

 &= nbsp; simple form of the member name MUST be used.”=

This pr= obably only means that “ietf-dots-signal:mitigation-scope”, = 220;ietf-acl:acl-name”, “ietf-acl:acl-type” and “ie= tf-dots-signal:signal-config” are the changes

 

[TR2] Yes.

 

(yes, a= cl-name & acl-type may be redefined in netconf-acl – do we really= need acl-type?).

 

[TR2] I did not get the above q= uestion !

&n= bsp;

[Jon2] = In netconf-acl, acl-name and acl-type (a proposal is outstanding to rename = them to name and type) both are a must when defined as a part of netconf-ac= l.  However, acl-type is just a hint as to how to parse / handle the rest of the definitions.  My question re= ally was - as we are recording the acl-name as the conflict, do we also nee= d to record acl-type as well.

 

[TR3] Yes.

 

As we a= re working with YANG, JSON and CBOR interrelation , I still think we need a= table similar to below to aid implementers – referring as appropriat= e to the different RFCs – no-one has full knowledge of all the evolving RFCs.

 

[TR] I don’t see the need= to repeat, its already discussed in detail in https://tools.i= etf.org/html/rfc8040#section-5.2 and similarly DOTS signal channel draf= t already refers to draft-ietf-core-yang-cbor-05.

[Jon] G= iven the number of times we have been inconsistent with the YANG / JSON and= CBOR definitions of a specific parameter, having a single place where all = 3 variants are on the same line certainly helps me as an implementer.

 

[TR1] I am trying to keep the C= BOR mapping table simple (not too wide J), it can be updated to add YANG type. Why do we need the cor= responding JSON type and JSON examples in the table ?

[Jon1] = I agree that we have a 72 character width limit.  I do not think we ne= ed the JSON examples column, but do think we need the JSON type so we have = YANG, CBOR and JSON equivalent types in one place.  However, if the parameter names get long –e.g. “i= etf-dots-signal:mitigation-scope”, we will run out of width unless th= ey are split over 2 lines.

 

[TR2] Yes, some of the paramete= r names need to be split into 2 lines. DOTS signal channel does not deal wi= th JSON encoding, what is the need to discuss equivalent JSON type in the s= ignal channel draft  ?

&n= bsp;

[Jon2] = I agree that all the data interchange between the DOTS peers will be in CBO= R format, derived from the YANG model definition.  However, the data c= hannel has aliases defined in JSON from the YANG model definition, and at some point there has to be a mapping between= CBOR and JSON when handling aliases.  As all the examples of GET, PUT= etc. in the signal draft are using JSON, making sure that JSON and CBOR is= correctly mapped is helpful to me and maybe others (I read JSON better than CBOR!). 

 

[TR3] Okay, will update the tab= le to include YANG and JSON types.

 

-Tiru

 

[Jon1] = NOTE.  If we have to do changes to parameter names, this may be a suit= able break point to re-sort the list by parameter name for ease of readabil= ity / lookup – especially if/as we are doing a lot of other fundamental changes post -14 with all the other discussions= – time to clean things up!

 

[TR] Sure.

 

-Tiru

 

Regards=

&n= bsp;

Jon

&n= bsp;

From: Dots [mailto: dots-bounces@ietf.org] On B= ehalf Of Konda, Tirumaleswar Reddy
Sent: 23 December 2017 07:06
To: Jon Shallow; dots@ietf.org<= br> Subject: Re: [Dots] Signal CBOR / JSON Mapping

 

We should= just follow the CBOR Encoding of Data Modeled with YANG defined in https:= //tools.ietf.org/html/draft-ietf-core-yang-cbor-05 and JSON Encoding of= Data Modeled with YANG

defined i= n https://tools.ietf.org/html/rfc7951.

&nbs= p;

-Tiru

&nbs= p;

From:<= /span> Dots [mailto:dots-bounces@ietf.org] On Behalf Of Jon Shallow
Sent: Friday, December 22, 2017 10:41 PM
To: dots@ietf.org
Subject: [Dots] Signal CBOR / JSON Mapping

 

Hi WG,

 

There are a lot of YANG paramet= ers that we are using that are defined as int64.  JSON only safely sup= ports up to 53 bits of precision.

 

RFC 7493 2.2 Numbers=

 

   An I-JSON sender c= annot expect a receiver to treat an integer whose

   absolute value is = greater than 9007199254740991 (i.e., that is

   outside the range = [-(2**53)+1, (2**53)-1]) as an exact value.

 

   For applications t= hat require the exact interchange of numbers with

   greater magnitude = or precision, it is RECOMMENDED to encode them in

   JSON string values= .  This requires that the receiving program

   understand the int= ended semantic of the value.  An example would be

   64-bit integers, e= ven though modern hardware can deal with them,

   because of the lim= ited scope of JavaScript numbers.

 

RFC7049 3.6 Numbers<= /span>

 

   CBOR-based protoco= ls should take into account that different language

   environments pose = different restrictions on the range and precision

   of numbers that ar= e representable.  For example, the JavaScript

   number system trea= ts all numbers as floating point, which may result

   in silent loss of = precision in decoding integers with more than 53

   significant bits.&= nbsp; A protocol that uses numbers should define its

   expectations on th= e handling of non-trivial numbers in decoders and

   receiving applicat= ions.

 

=3D=3D=3D=3D<= /p>

 

An option is to make all of the= se int64 decimal64 for the signal channel, but that does not cover the 64 b= it counters in the netmod-acl.  However, as the netmod-acl counters ar= e also fed back via the mitigate status, we do not necessarily need to support the netmod-acl counters.<= /span>

 

If, however, we follow RFC 7493= , in CBOR the data can be passed across as 64 bits, and as the parameter is= a CBOR mapping, we can know how to encode / decode the JSON value as appro= priate.  However, RFC 7493 does not say whether this should be base64, base64url or numeric string representat= ion (i.e. “1234567890”).  RFC7049 refers to bignum (major = type 6, tag value 2 or 3) should be encoded as base64url (4.1 Converting fr= om CBOR to JSON) – but int64 can be held in CBOR as type 0 or 1.

 

I prefer the numeric string rep= resentation as it is humanly easy to read and easy to convert into 64 bit i= ntegers.

 

If we take this approach of usi= ng the parameter which is a CBOR mapping key to key off how to encode / dec= ode the JSON, I would suggest that we could extend this to include IP addre= sses, Dates and client-identifiers (or their possible new names of request-nonce and client-domain-hash) to furth= er minimize the actual number of bytes sent in a COAP packet.

 

The CBOR mapping Table could th= en be extended to look something like (but it is too wide I think)

 

/----------------------+-------------= 3;------+---------------+--------+---------\<= /p>

| Parameter name    &nbs= p;  | YANG type   | CBOR | CBOR major    | JS= ON   | JSON    | 

|       &= nbsp;           &nbs= p;  |           = ;  | key  | type        &= nbsp; | type   | Example |

|----------------------+-------------= 3;------+---------------+--------+---------|<= /p>

| mitigation-scope     |= grouping    |   1  | 5 map   =       | Object |     &nbs= p;   | 

| scope      &= nbsp;         | list  &nb= sp;     |   2  | 4 array  &nbs= p;    | Array  |      &nb= sp;  | 

| mitigation-id     = ;   | int32       |   3&n= bsp; | 0 unsigned    | Number | 54321   | 

| acl-list     &nbs= p;       | list     =    |   4  | 4 array     &= nbsp; | Array  |         |&nbs= p;

| target-port-range    | list=         |   5  | 4 array&= nbsp;      | Array  |    =      | 

| lower-port     &n= bsp;     | port-number |   6  | 0 number=       | Number | 1111    | 

| upper-port     &n= bsp;     | port-number |   7  | 0 number=       | Number | 1111    | 

| target-protocol    &nb= sp; | leaf-list   |      | 4 array =       | Array  |     = ;    | 

|       &= nbsp;           &nbs= p;  | uint8       |   8  = | 0 number      | Number | 6   &nbs= p;   |

| target-fqdn     &= nbsp;    | leaf-list   |    &n= bsp; | 4 array       | Array  | &nb= sp;       |

|       &= nbsp;           &nbs= p;  | domain-name |   9  | 3 text string | String | &qu= ot;a.com" |

| target-uri     &n= bsp;     | leaf-list   |    &n= bsp; | 4 array       | Array  |&nbs= p;        | 

|       &= nbsp;           &nbs= p;  | uri         |  10&n= bsp; | 3 text string | String |       &n= bsp; |

| alias-name     &n= bsp;     | leaf-list   |    &n= bsp; | 4 array       | Array  | &nb= sp;       | 

|        =             &nb= sp; | string      |  11  | 3 text s= tring | String | "web"   | 

| lifetime     &nbs= p;       | int32     = ;  |  12  | 0 number      | Number = |         | 

| attack-status     = ;   | enumeration |  13  | 0 number   &n= bsp;  | Number | 1       | 

| signal-config     = ;   | grouping    |  14  | 5 map &n= bsp;       | Object |    =      | 

| heartbeat-interval   | grouping&= nbsp;   |  15  | 5 map     &nb= sp;   | Object |         = | 

| max-retransmit    &nbs= p;  | grouping    |  16  | 5 map  &= nbsp;      | Object |     = ;    | 

| ack-timeout     &= nbsp;    | grouping    |  17  | 5 m= ap         | Object |  &n= bsp;      | 

| ack-random-factor    | grou= ping    |  18  | 5 map    &nbs= p;    | Object |       &n= bsp; | 

| min-value      &n= bsp;     | int16     &nbs= p; |  19  | 0 number      | Number | 1&n= bsp;      | 

| max-value     &nb= sp;      | int16     &nbs= p; |  20  | 0 number      | Number | 1&n= bsp;      | 

| status      =          | enumeration |  21&n= bsp; | 0 number      | Number | 1   = ;    | 

| conflict-information | grouping  = ;  |  22  | 5 map       &= nbsp; | Object |         | 

| conflict-status    &nb= sp; | enumeration |  23  | 0 number     = | Number | 1       | 

| conflict-cause    &nbs= p;  | enumeration |  24  | 0 number    &= nbsp; | Number | 1       | 

| retry-timer     &= nbsp;    | int32       | = 25  | 0 number      | Number | 1800 &nb= sp;  | 

| bytes-dropped     = ;   | counter64   |  26  | 0 number &nbs= p;    | String | "1234"  | 

| bps-dropped     &= nbsp;    | counter64   |  27  | 0 number=       | String | "1234"  | 

| pkts-dropped     =     | counter64   |  28  | 0 number = ;     | String | "1234"  | 

| pps-dropped     &= nbsp;    | counter64   |  29  | 0 number=       | String | "1234"  | 

| session-id     &n= bsp;     | int32       |&= nbsp; 30  | 0 number      | Number | 65432&nb= sp;  | 

| trigger-mitigation   | boolean&n= bsp;    |  31  | 7 simple    &= nbsp; | T / F  |         |&nbs= p;

| missing-hb-allowed   | grouping&= nbsp;   |  32  | 5 map     &nb= sp;   | Object |         = | 

| current-value     = ;   | int16       |  33  = | 0 number      | Number | 10   &nb= sp;  | 

| mitigation-start     |= decimal64   |  34  | 7 FP     = ;     | Number | 10.21   | 

| target-prefix     = ;   | leaf-list   |      | 4 a= rray       | Array  |   &= nbsp;     | 

|        =             &nb= sp; | ip-prefix   |  35  | 3 text string | String = |         | 

| client-domain-hash   | leaf-list=    |      | 4 array   &nb= sp;   | Array  |       &n= bsp; |

|        =             &nb= sp; | binary      |  36  | 2 byte s= tring | String | "abcdf" |

| alt-server     &n= bsp;     | string      | = 37  | 3 text string | String |      &nb= sp;  | 

| alt-server-record    | list=         |  38  | 4 array =       | Array  |     = ;    | 

| addr      &n= bsp;          | string &n= bsp;    |  39  | 3 text string | String | &nb= sp;       | 

| ttl      &nb= sp;           | int32&nbs= p;      |  40  | 0 number  &nb= sp;   | Number | 1800    | 

| conflict-scope    &nbs= p;  | grouping    |  41  | 5 map  &= nbsp;      | Object |     = ;    | 

| acl-name     &nbs= p;       | string    &nbs= p; |  42  | 3 text string | String | "aname" | 

| acl-type     &nbs= p;       | string    &nbs= p; |  43  | 3 text string | String | "ipv4"  |&nbs= p;

| config-interval    &nb= sp; | int32       |  44  | 0 number=       | Number | 11      = | 

| mitigating-config    | grou= ping    |  45  | 5 map    &nbs= p;    | Object |       &n= bsp; | 

| idle-config     &= nbsp;    | grouping    |  46  | 5 m= ap         | Object |  &n= bsp;      | 

| request-nonce     = ;   | binary      |  47  | 2 b= yte string | String | "xxx"   | 

| min-value-decimal    | deci= mal64   |  48  | 7 FP     &nbs= p;    | Number | 1.1     | 

| max-value-decimal    | deci= mal64   |  49  | 7 FP     &nbs= p;    | Number | 1.1     | 

| current-value-decimal| decimal64 &nbs= p; |  50  | 7 FP        &= nbsp; | Number | 1.1     | 

\----------------------+-------------= 3;------+---------------+--------+---------/<= /p>

 

 

Comments / suggestions?

 

Regards

 

Jon

--_000_DM5PR16MB1788A6BF1D42084013466C82EA190DM5PR16MB1788namp_-- From nobody Tue Jan 2 07:10:33 2018 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 D8819124BAC for ; Tue, 2 Jan 2018 07:10:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.011 X-Spam-Level: X-Spam-Status: No, score=-7.011 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, T_RP_MATCHES_RCVD=-0.01] 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 QlrOxp1PNZ9O for ; Tue, 2 Jan 2018 07:10:30 -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 9C65B1241F5 for ; Tue, 2 Jan 2018 07:10:29 -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=1514905818; 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:x-microsoft-antispam-message-info: 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=X LJD4Yfmc80mMqmUXviBbHQ+M99EPFXD2Fk5OEqaO+ o=; b=KldL3ReQMfhnwQYSdFP+SGd1VYBKkWCosElsarHEs3oU D0PWII2HelK1P4PVLuvtTbIbSwOdUudEX9+iyxnpopjwiWatKU eJ9HLtALPrYvBkxBxjdHa7PEE2qnsvBpzFkmMjakSJdnEJwX63 qu86ZOQy3p6cFAJIj2WczaVB+Tk= Received: from MIVEXAPP1N03.corpzone.internalzone.com (unknown [10.48.48.90]) by MIVWSMAILOUT1.mcafee.com with smtp (TLS: TLSv1/SSLv3,256bits,ECDHE-RSA-AES256-SHA384) id 5ab6_0dbc_5ddbc7b9_515f_4a9a_afff_28bed0b57d4a; Tue, 02 Jan 2018 09:10:17 -0600 Received: from MIVEXUSR1N01.corpzone.internalzone.com (10.48.48.81) by MIVEXAPP1N03.corpzone.internalzone.com (10.48.48.90) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Tue, 2 Jan 2018 10:10:15 -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, 2 Jan 2018 10:10:15 -0500 Received: from NAM01-BN3-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, 2 Jan 2018 10:10:12 -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.366.8; Tue, 2 Jan 2018 15:10: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.0366.009; Tue, 2 Jan 2018 15:10:13 +0000 From: "Konda, Tirumaleswar Reddy" To: Jon Shallow , "dots@ietf.org" , kaname nishizuka Thread-Topic: [Dots] [signal-channel-draft] CoAP libraries have problems with the DOTS spec Thread-Index: AQHTf8LysSrBqL8kXEaeN1Zbh0iz4KNZPmiAgADuooCABjh4gIAAEk4AgAAA90CAAAVwgIAAG7XwgAAMJACAABBP0A== Date: Tue, 2 Jan 2018 15:10:13 +0000 Message-ID: References: <094801d3801e$f7ab01b0$e7010510$@jpshallow.com> <099601d38096$487c9410$d975bc30$@jpshallow.com> <0b7a01d383bb$aba5f720$02f1e560$@jpshallow.com> <0b8501d383be$df5ec030$9e1c4090$@jpshallow.com> <0bb401d383d2$cbbdc9e0$63395da0$@jpshallow.com> In-Reply-To: <0bb401d383d2$cbbdc9e0$63395da0$@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.72.75] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DM5PR16MB1786; 6:Ur9sQ6311L5lbsvNt/eIGSrdZY/Ku247jCPj3GwNj++oVvKa4FZYEmSjIGcaIiJGDQouZOS1I2SufD50LpbH7/p9miHQQOsfBuDdhTOrfaI0V9z9sZqbkNs27tmC0qCYCboxeHSsOtsrk0WXFLakcbFZeiseH/cT1e199sOEFmrqS0gaBo4xhtUOt6ta8m4ywQMMphunsbBeH2ka77BG6EHi4PFdRpEfMb4MrxMXyYSxkXjqiVWSsOfu65BtQdURsGipJm2nUcUwR0BVC/xAWum1MTnCPcA7SDysLxPwHXP/PnFpze4zo/T3YAw2EpSziYbeJloNRSqfG227X/4kfwCkatpckadB7TVdNRtNdxVuLe1SsbGGgf/g4kvk3cuN; 5:Lc6EOcae6bMkAfkaZbaolPWsDe6yHWPxO8nA4afSx08zCbDAUx9eIp0koe9EKaIVhUWlgSn1VvGUgiKXezOZrUj6QHZhSDTDd3XR6BMQuyiGgAUNkcFc5ZpHpvQEic86Z9DU+mziSViE0sndGT12B/IAYIjByQ7czOUw8o+8B34=; 24:o78j3Z6iP0lg9/s40VnlF7dheYYOe3bMXUcELW5g53LLEgEELXAsza37zv3Hdzpr0ieAKOg8a0C1kkz2lFkfFIph0vuFSpMVUIgHaJwcu0E=; 7:slungnbX/vmcpOl46pi5OvEMVEM+HqWXoZlhsf9BCMQ2RtXcX5QbZUabPotjShjccIhiW8NpHaFXS/TxpEtN6kHkTDYe0PD28qbhzOWbp0metC9Cf8IPhYYMLyT4EgZxCRpaarbTRXMcKZ5U6a14Jp61zaFe1aqW1dE9I4uC5gE/d0bGs7+d9EsYRPji3nqdXHNa29Ep2G0t8Nj7Ce9PrPGlOJqpvI8RfJkFF0SvZ0rTMmRG8wzhkLTNbUhS47h4 x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 2519f4ba-004a-40dc-5d75-08d551f2ecbe x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(5600026)(4604075)(3008032)(2017052603307)(7153060); SRVR:DM5PR16MB1786; x-ms-traffictypediagnostic: DM5PR16MB1786: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(190756311086443)(158342451672863)(166708455590820)(123452027830198); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040470)(2401047)(5005006)(8121501046)(3002001)(3231023)(944501075)(93006095)(93001095)(10201501046)(6041268)(20161123562045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(20161123558120)(20161123564045)(6072148)(201708071742011); SRVR:DM5PR16MB1786; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:DM5PR16MB1786; x-forefront-prvs: 0540846A1D x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39860400002)(366004)(39380400002)(346002)(376002)(396003)(32952001)(51444003)(189003)(199004)(13464003)(14454004)(59450400001)(7696005)(53936002)(3660700001)(76176011)(81166006)(8676002)(81156014)(105586002)(106356001)(74316002)(7736002)(305945005)(55016002)(33656002)(77096006)(478600001)(966005)(9686003)(6306002)(6436002)(110136005)(230783001)(72206003)(316002)(3280700002)(2906002)(99286004)(229853002)(66066001)(93886005)(80792005)(25786009)(2501003)(97736004)(6116002)(3846002)(86362001)(102836004)(68736007)(2950100002)(8936002)(6506007)(6246003)(53546011)(5660300001)(2900100001)(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) x-microsoft-antispam-message-info: hjvOxUTORibL7UoJZp9qFvXjxgoDcCZ11yyfplO1KA6hSXOoNCPUqJPw98q23tc7U2mhbgCUJPLgEsZm8ppm4g== 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: 2519f4ba-004a-40dc-5d75-08d551f2ecbe X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Jan 2018 15:10:13.7221 (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 <6191> : inlines <6292> : streams <1774896> : uri <2561815> Archived-At: Subject: Re: [Dots] [signal-channel-draft] CoAP libraries have problems with the DOTS spec 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, 02 Jan 2018 15:10:33 -0000 > -----Original Message----- > From: Jon Shallow [mailto:supjps-ietf@jpshallow.com] > Sent: Tuesday, January 2, 2018 7:36 PM > To: Konda, Tirumaleswar Reddy > ; dots@ietf.org; kaname > nishizuka > Subject: RE: [Dots] [signal-channel-draft] CoAP libraries have problems w= ith > the DOTS spec >=20 > Hi Tiru, >=20 > See inline [Jon4] >=20 > Regards >=20 > Jon >=20 > > > > > > -----Original Message----- > > > > From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of kaname > > > > nishizuka > > > > Sent: 28 December 2017 10:02 > > > > To: dots@ietf.org > > > > Subject: [Dots] [signal-channel-draft] CoAP libraries have > > > > problems with the DOTS spec > > > > > > > > Hi, > > > > > > > > Last week, Jon and I did the second interoperability test based on > > > > the > > > > -13 version of the signal channel draft. > > > > We made significant improvements of each implementation. Several > > > > feedbacks to the WG have been made by Jon already. > > > > > > > > Based on the experience, I encountered the problems between CoAP > > > > libraries and the specification of the DOTS. > > > > > > > > 1. resource identification of GET methods. > > > > > > > > In signal channel spec, the target resource in GET method is > > > > identified in the BODY of the message, that is mitigation-id (and > > > client-identifier). > > > > However, CoAP libraries, at least we investigated, only see the > > > > Request URI, so it cannot locate the resource because it doesn't > > > > see the > > > BODY. > > > > > > > > So the question is, why does the DOTS spec use CoAP Body for > > > > resource identifier? > > > > > > > > [Jon] A very good question. I had just assumed that this was the > > > > way to do it, but had noted that this was not done when using HTTP > etc. > > > > and so was different. See later comments > > > > > > > > Most of CoAP libraries only support request URI in CoAP > > > > GET/observe, which is the spec from RFC7252. > > > > https://tools.ietf.org/html/rfc7252 > > > > 5.8.1.GET > > > > The GET method retrieves a representation for the information th= at > > > > currently corresponds to the resource identified by the request > URI. > > > > [Jon] RFC 7252 states also > > > > 5.10.1. Uri-Host, Uri-Port, Uri-Path, and Uri-Query > > > > > > > > The Uri-Host, Uri-Port, Uri-Path, and Uri-Query Options are used= to > > > > specify the target resource of a request to a CoAP origin server= . > > > > [Jon] So it looks like the target resource should only be in > > > > Uri-Path and/or Uri-Query. > > > > [Jon] In my CoAP Library, I have to define each individual > > > > resource (it does a lookup against a hash of the complete Uri to > > > > find whether the resource is known or not), so, when say > > > > mitigation-id=3D2 is added, I need to register the resource > > > > .well-known/dots/v1/mitigate/migration-is=3D2 with an associated > > > > handler. This is not difficult to do, but potentially could > > > > consume a lot > > > of DOTS server resources if many mitigations are active. > > > > [Jon] Doing it as a Query Option I think is my preference - Comment= s? > > > > [Jon] The same is true for GET signal configuration as well. > > > > > > Yes, will update draft to use Query option for GET method. > > > [Jon2] This works for me, but does not feel right when this is > > > extended for "PUT .../mitigate Query mitigation-id-2" to create the > > > mitigation-id. I think that the complete "resource" should be > > > specified for consistency and just leave the c=3D? as being the > > > required > > valid Query option. > > > > PUT method does not need to convey the Query Option (for example > > please see https://tools.ietf.org/html/rfc7967#section-4.1.1, the > > resource is specified in the URI-path option itself). > > > > [Jon3] Agreed - and think that the full resource needs to be > > specified for the DELETE (need to fix my libcoap library to not > > respond with 4.04 if resource does not exist as per RFC7252) as well > > that the GET. However, "GET .../mitigate" should return all current > > mitigations if the mitigation-id is not specified in the Uri-Path.. >=20 > Yes. >=20 > [Jon4] mitigation-id needs to be included as a parameter in the body in > response to "GET .../mitigate". I assume for consistency, it should also= be > returned as a parameter for "GET .../mitigate/mitigation-id=3DZZ". Yes.=20 > [Jon4] So when doing "PUT .../mitigate/mitigation-id=3DZZ", do we also in= clude > in the PUT data body the parameter mitigation-id =3D ZZ? What happens if > they are different? I don't see the need to convey "mitigation-id=3DZZ" in the PUT body if it i= s conveyed in the Uri-Path.=20 >=20 > > > > [Jon3] The same is for configuration (GET, PUT & DELETE) - which then > > begs the question - do we really need "session-id" ? >=20 > session-id is introduced to handle out-of-order delivery of PUT requests,= the > PUT request with a higher numeric 'session-id' value overrides the DOTS > signal channel session configuration data installed by a PUT request with= a > lower numeric 'session-id' value. >=20 > [Jon4] Understood. And the lesser session-id resource would be no more > (i.e. the resource is deleted). > [Jon4] As this signal configuration is only defining a specific session (= there > may be multiple sessions) between 2 DOTS peers, "client-identifier" > (or "request-nonce") are not really needed to be supported as a part of t= he > resource. Yes.=20 > [Jon4] We need a "GET .../config" to get the server sides (initial) notio= n of > what is supported for configuration. We would then support > "GET .../config/session-id=3DYY" (only can be done following a PUT otherw= ise > session-id is unknown). The PUT would definitely have to be > "PUT ../config/session-id-YY". The DELETE would be either > "DELETE .../config" or "DELETE .../config/session-id=3DYY" where both of = them > reset the signal configuration back to the defaults. "DELETE .../config"= would > get rid of any session-ids for that particular session. Agreed. -Tiru >=20 > -Tiru >=20 > > > > > > > > > > > > > [Jon1] I am now leaning towards doing it in the Uri-Path but still > > > > not > > > sure. > > > > The CoAP layer responds with a 4.04 with my CoAP library if the > > > > resource > > > > (Uri-Path) is unknown. > > > > [Jon1] We need to define the order in the path - e.g. > > > > client-identifier (or request-none etc. if that is accepted) then > > > > mitigation-id, so that resources are built consistently from a > > > > mitigation > > > request. > > > > > > Agreed. > > > [Jon2] then something similar to the above specifying ordering needs > > > to be put into the draft. > > > > Yes. > > > > > > > > > [Jon1] However doing this means we also need to include PUT and > > > > DELETE with the resource specified in the Uri-Path. My library > > > > then runs into a chicken and egg situation with PUT - the PUT is > > > > defining the new resource, but as the resource is not defined > > > > (yet) in the CoAP layer, it gets rejected with a > > > > 4.04 in the CoAP layer (as mentioned above). The way around this > > > > is to use POST to create new mitigation requests (and will respond > > > > with appropriate Location-Path to give the new UI) and PUT if we > > > > are refreshing > > > the resource. > > > > > > > > [Jon1] Thoughts? > > > > > > PUT can also be used to create a new resource, and the draft uses > > > PUT instead of POST because it is idempotent and during a > > > volumetric DDoS attack saturating the incoming link to the DOTS > > > client, DOTS client will most likely not receive the server-side > > > responses. Is this an > > implementation bug ? > > > > > > [Jon2] I agree that it is a bug in the libcoap I am using > > > [https://github.com/obgm/libcoap]. RFC7252 5.8.3. PUT states "The > > > PUT method requests that the resource identified by the request URI > > > be updated or created". I can try to fix the library to keep on > > > stripping off the last UriPath and then doing a hash lookup on the > > > sub path until a match is found in the case of doing a PUT. It > > > would then (in my case - not needed in the > > > draft) be the responsibility of creating a new resource if needed in > > > the DOTS layer. > > > > Thanks. > > > > Cheers, > > Tiru > > > > > > > > -Tiru > > > > > > > > > > > 2. Confirmable vs NonConfirmable at Mitigation Request > > > > > > > > A CoAP library (dustin/go-coap) stops listening right after > > > > sending out the NonConfirmable message because NonConfirmable > > > > messages do > > > not > > > > require acknowledgements. > > > > > > > > [Jon] As there is a good chance during attack scenarios that > > > > responses may not be able to get back, it makes sense to me that > > > > these "GET > > > mitigation" > > > > requests are non-confirmable. Certainly "PUT mitigation" needs to > > > > be thought of as a one way signal. There are times that the > > > > client has to run "blind" during attack scenarios. > > > > [Jon]If they were confirmable, then the request will get sent > > > > multiple times to the DOTS server - which could be handled by the > > > > server, but then the confirmable responses would retried whilst > > > > sending back to the DOTS client and eventually retry timeout. A > > > > large scale attack could swamp a DOTS server with all the yet to > > > > be confirmed confirmable > > > responses. > > > > [Jon] As per RFC7252 "2.2. Request/Response Model", a response to > > > > a > > > > non- confirmable request is expected to be handled as in:- > > > > If a request is sent in a Non-confirmable message, then the > response > > > > is sent using a new Non-confirmable message, although the > > > > server > may > > > > instead send a Confirmable message. This type of exchange is > > > > illustrated in Figure 6. > > > > > > > > Client Server > > > > | | > > > > | NON [0x7a11] | > > > > | GET /temperature | > > > > | (Token 0x74) | > > > > +----------------->| > > > > | | > > > > | NON [0x23bc] | > > > > | 2.05 Content | > > > > | (Token 0x74) | > > > > | "22.5 C" | > > > > |<-----------------+ > > > > | | > > > > > > > > Figure 6: A Request and a Response Carried in Non-confirmabl= e > > > > Messages [Jon] So I would expect > > > > any CoAP library to support this non-confirmation mechanism by > > > > receiving a new non- confirmable message. It would be the > > > > responsibility of the DOTS layer to associate the Tokens together > > > > to handle the responses with > > > the requests. > > > > [Jon] In addition, when Observe is enabled, the DOTS server will > > > > continue to generate non-confirmable messages with the same Token. > > > > Again, the DOTS client will need to know what to do with the Token > > > > (which could be to update things, or to send a RST if no more > > > > packets with the same Token should be sent. > > > > > > > > > > > > The spec of Confirmable message already have the retransmission > > > > mechanism, so using Confirmable message is an easier way to notice > > > > that the message has been lost during the attack time. > > > > > > > > [Jon] The DOTS client will know something is wrong as it will be > > > > seeing heartbeat issues. > > > > > > > > I'm afraid I'm missing some previous discussions we made on the ML > > > > and at the WG meeting, but we have a problem with the CoAP library > > > > regarding this spec. > > > > > > > > * At the -08 version of the signal channel draft, this change was > made: > > > > DOTS mitigation request/response are marked as non-confirmable > > > messages. > > > > > > > > thank you, > > > > Kaname > > > > > > > > > > > > _______________________________________________ > > > > Dots mailing list > > > > Dots@ietf.org > > > > https://www.ietf.org/mailman/listinfo/dots > > > > > > > > _______________________________________________ > > > > Dots mailing list > > > > Dots@ietf.org > > > > https://www.ietf.org/mailman/listinfo/dots > > > > > > > > _______________________________________________ > > > > Dots mailing list > > > > Dots@ietf.org > > > > https://www.ietf.org/mailman/listinfo/dots > > > > > > _______________________________________________ > > > Dots mailing list > > > Dots@ietf.org > > > https://www.ietf.org/mailman/listinfo/dots > > > > _______________________________________________ > > Dots mailing list > > Dots@ietf.org > > https://www.ietf.org/mailman/listinfo/dots >=20 > _______________________________________________ > Dots mailing list > Dots@ietf.org > https://www.ietf.org/mailman/listinfo/dots From nobody Tue Jan 2 07:48:26 2018 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 37B6412706D for ; Tue, 2 Jan 2018 07:48:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 K6LgKEhevlpH for ; Tue, 2 Jan 2018 07:48: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 94D7712AF6E for ; Tue, 2 Jan 2018 07:48: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 1eWOna-0006sL-RB; Tue, 02 Jan 2018 15:48:19 +0000 From: "Jon Shallow" To: "'Konda, Tirumaleswar Reddy'" , References: <073001d37b47$e6f27460$b4d75d20$@jpshallow.com> <094a01d3801f$20d94dd0$628be970$@jpshallow.com> <0b6101d383b5$48b29a20$da17ce60$@jpshallow.com> <0b8d01d383c5$9e0e4e50$da2aeaf0$@jpshallow.com> <0bb601d383d5$f5084930$df18db90$@jpshallow.com> In-Reply-To: Date: Tue, 2 Jan 2018 15:48:17 -0000 Message-ID: <0bd501d383e1$1b4b8250$51e286f0$@jpshallow.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0BD6_01D383E1.1B503D40" X-Mailer: Microsoft Outlook 14.0 Content-Language: en-gb Thread-Index: AQJTmGwWHKq+N1BT2oAOspP+fqvZXQF5x90cAibGkTgCTX2+CwJVOoraAgmqY9cC2iseVgDjex+aAhN2ZLcDXlCnl6HErjuA Archived-At: Subject: Re: [Dots] Signal CBOR / JSON Mapping 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, 02 Jan 2018 15:48:25 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0BD6_01D383E1.1B503D40 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Tiru, Thanks - I think we are good to go on this one. Regards Jon From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of Konda, Tirumaleswar Reddy Sent: 02 January 2018 15:04 To: Jon Shallow; dots@ietf.org Subject: Re: [Dots] Signal CBOR / JSON Mapping Hi Jon, Please see inline [TR3] From: Jon Shallow [mailto:supjps-ietf@jpshallow.com] Sent: Tuesday, January 2, 2018 7:58 PM To: Konda, Tirumaleswar Reddy ; dots@ietf.org Subject: RE: [Dots] Signal CBOR / JSON Mapping Hi Tiru, See inline [Jon2] Regards Jon From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Jon Shallow Sent: Friday, December 29, 2017 2:32 AM To: Konda, Tirumaleswar Reddy ; dots@ietf.org Subject: Re: [Dots] Signal CBOR / JSON Mapping Hi Tiru, Thanks for pointing me to these references. RFC7951 6.1. Numeric Types A value of the "int8", "int16", "int32", "uint8", "uint16", or "uint32" type is represented as a JSON number. A value of the "int64", "uint64", or "decimal64" type is represented as a JSON string whose content is the lexical representation of the corresponding YANG type as specified in Sections 9.2.1 and 9.3.1 of [RFC7950]. For example, if the type of the leaf "foo" in Section 5.1 was "uint64" instead of "uint8", the instance would have to be encoded as "foo": "123" -- So, we now have a way of handling int64/uint64 which should be used moving forward. However, my JSON implementation (as well as many others I suspect) natively supports decimal64, so does not necessarily need to display it as a lexical representation string. Do we follow RFC7951 here as well? [TR] Let's not deviate from RFC7951 otherwise both drafts will end-up defining it's our own set of rules for encoding the YANG configuration data as JSON/CBOR text deviating from the existing standards. [Jon] Agreed I do not think that we should be following the augmented JSON parameter naming in RFC7951 "4. Names and Namespaces" otherwise we will start ending up with JSON/CBOR parameter names such as "ietf-dots-signal:mitigation-scope". If we do go with this, then the CBOR mapping table will need to get extended to cover the old, but some parameter name in different places. Comments? [TR] Both drafts should follow the naming in RFC7951. [Jon] I'm neutral on this, but agree to following standards - there will be however a lot of long parameter names which fortunately will get compressed by the CBOR mapping. However, draft-ietf-netmod-acl-model (albeit in xml not json) does not have parameter names such as "ietf-access-control-list:access-lists" [Jon1] We really need to come to an agreement on this one. I think I prefer simpler names, but any program based YANG -> JSON translator following RFC7951 will come up with the long names.. However as I understand "A namespace-qualified member name MUST be used for all members of a top-level JSON object and then also whenever the namespaces of the data node and its parent node are different. In all other cases, the simple form of the member name MUST be used." This probably only means that "ietf-dots-signal:mitigation-scope", "ietf-acl:acl-name", "ietf-acl:acl-type" and "ietf-dots-signal:signal-config" are the changes [TR2] Yes. (yes, acl-name & acl-type may be redefined in netconf-acl - do we really need acl-type?). [TR2] I did not get the above question ! [Jon2] In netconf-acl, acl-name and acl-type (a proposal is outstanding to rename them to name and type) both are a must when defined as a part of netconf-acl. However, acl-type is just a hint as to how to parse / handle the rest of the definitions. My question really was - as we are recording the acl-name as the conflict, do we also need to record acl-type as well. [TR3] Yes. As we are working with YANG, JSON and CBOR interrelation , I still think we need a table similar to below to aid implementers - referring as appropriate to the different RFCs - no-one has full knowledge of all the evolving RFCs. [TR] I don't see the need to repeat, its already discussed in detail in https://tools.ietf.org/html/rfc8040#section-5.2 and similarly DOTS signal channel draft already refers to draft-ietf-core-yang-cbor-05. [Jon] Given the number of times we have been inconsistent with the YANG / JSON and CBOR definitions of a specific parameter, having a single place where all 3 variants are on the same line certainly helps me as an implementer. [TR1] I am trying to keep the CBOR mapping table simple (not too wide J), it can be updated to add YANG type. Why do we need the corresponding JSON type and JSON examples in the table ? [Jon1] I agree that we have a 72 character width limit. I do not think we need the JSON examples column, but do think we need the JSON type so we have YANG, CBOR and JSON equivalent types in one place. However, if the parameter names get long -e.g. "ietf-dots-signal:mitigation-scope", we will run out of width unless they are split over 2 lines. [TR2] Yes, some of the parameter names need to be split into 2 lines. DOTS signal channel does not deal with JSON encoding, what is the need to discuss equivalent JSON type in the signal channel draft ? [Jon2] I agree that all the data interchange between the DOTS peers will be in CBOR format, derived from the YANG model definition. However, the data channel has aliases defined in JSON from the YANG model definition, and at some point there has to be a mapping between CBOR and JSON when handling aliases. As all the examples of GET, PUT etc. in the signal draft are using JSON, making sure that JSON and CBOR is correctly mapped is helpful to me and maybe others (I read JSON better than CBOR!). [TR3] Okay, will update the table to include YANG and JSON types. -Tiru [Jon1] NOTE. If we have to do changes to parameter names, this may be a suitable break point to re-sort the list by parameter name for ease of readability / lookup - especially if/as we are doing a lot of other fundamental changes post -14 with all the other discussions - time to clean things up! [TR] Sure. -Tiru Regards Jon From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of Konda, Tirumaleswar Reddy Sent: 23 December 2017 07:06 To: Jon Shallow; dots@ietf.org Subject: Re: [Dots] Signal CBOR / JSON Mapping We should just follow the CBOR Encoding of Data Modeled with YANG defined in https://tools.ietf.org/html/draft-ietf-core-yang-cbor-05 and JSON Encoding of Data Modeled with YANG defined in https://tools.ietf.org/html/rfc7951. -Tiru From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Jon Shallow Sent: Friday, December 22, 2017 10:41 PM To: dots@ietf.org Subject: [Dots] Signal CBOR / JSON Mapping Hi WG, There are a lot of YANG parameters that we are using that are defined as int64. JSON only safely supports up to 53 bits of precision. RFC 7493 2.2 Numbers An I-JSON sender cannot expect a receiver to treat an integer whose absolute value is greater than 9007199254740991 (i.e., that is outside the range [-(2**53)+1, (2**53)-1]) as an exact value. For applications that require the exact interchange of numbers with greater magnitude or precision, it is RECOMMENDED to encode them in JSON string values. This requires that the receiving program understand the intended semantic of the value. An example would be 64-bit integers, even though modern hardware can deal with them, because of the limited scope of JavaScript numbers. RFC7049 3.6 Numbers CBOR-based protocols should take into account that different language environments pose different restrictions on the range and precision of numbers that are representable. For example, the JavaScript number system treats all numbers as floating point, which may result in silent loss of precision in decoding integers with more than 53 significant bits. A protocol that uses numbers should define its expectations on the handling of non-trivial numbers in decoders and receiving applications. ==== An option is to make all of these int64 decimal64 for the signal channel, but that does not cover the 64 bit counters in the netmod-acl. However, as the netmod-acl counters are also fed back via the mitigate status, we do not necessarily need to support the netmod-acl counters. If, however, we follow RFC 7493, in CBOR the data can be passed across as 64 bits, and as the parameter is a CBOR mapping, we can know how to encode / decode the JSON value as appropriate. However, RFC 7493 does not say whether this should be base64, base64url or numeric string representation (i.e. "1234567890"). RFC7049 refers to bignum (major type 6, tag value 2 or 3) should be encoded as base64url (4.1 Converting from CBOR to JSON) - but int64 can be held in CBOR as type 0 or 1. I prefer the numeric string representation as it is humanly easy to read and easy to convert into 64 bit integers. If we take this approach of using the parameter which is a CBOR mapping key to key off how to encode / decode the JSON, I would suggest that we could extend this to include IP addresses, Dates and client-identifiers (or their possible new names of request-nonce and client-domain-hash) to further minimize the actual number of bytes sent in a COAP packet. The CBOR mapping Table could then be extended to look something like (but it is too wide I think) /----------------------+-------------+------+---------------+--------+------ ---\ | Parameter name | YANG type | CBOR | CBOR major | JSON | JSON | | | | key | type | type | Example | |----------------------+-------------+------+---------------+--------+------ ---| | mitigation-scope | grouping | 1 | 5 map | Object | | | scope | list | 2 | 4 array | Array | | | mitigation-id | int32 | 3 | 0 unsigned | Number | 54321 | | acl-list | list | 4 | 4 array | Array | | | target-port-range | list | 5 | 4 array | Array | | | lower-port | port-number | 6 | 0 number | Number | 1111 | | upper-port | port-number | 7 | 0 number | Number | 1111 | | target-protocol | leaf-list | | 4 array | Array | | | | uint8 | 8 | 0 number | Number | 6 | | target-fqdn | leaf-list | | 4 array | Array | | | | domain-name | 9 | 3 text string | String | "a.com" | | target-uri | leaf-list | | 4 array | Array | | | | uri | 10 | 3 text string | String | | | alias-name | leaf-list | | 4 array | Array | | | | string | 11 | 3 text string | String | "web" | | lifetime | int32 | 12 | 0 number | Number | | | attack-status | enumeration | 13 | 0 number | Number | 1 | | signal-config | grouping | 14 | 5 map | Object | | | heartbeat-interval | grouping | 15 | 5 map | Object | | | max-retransmit | grouping | 16 | 5 map | Object | | | ack-timeout | grouping | 17 | 5 map | Object | | | ack-random-factor | grouping | 18 | 5 map | Object | | | min-value | int16 | 19 | 0 number | Number | 1 | | max-value | int16 | 20 | 0 number | Number | 1 | | status | enumeration | 21 | 0 number | Number | 1 | | conflict-information | grouping | 22 | 5 map | Object | | | conflict-status | enumeration | 23 | 0 number | Number | 1 | | conflict-cause | enumeration | 24 | 0 number | Number | 1 | | retry-timer | int32 | 25 | 0 number | Number | 1800 | | bytes-dropped | counter64 | 26 | 0 number | String | "1234" | | bps-dropped | counter64 | 27 | 0 number | String | "1234" | | pkts-dropped | counter64 | 28 | 0 number | String | "1234" | | pps-dropped | counter64 | 29 | 0 number | String | "1234" | | session-id | int32 | 30 | 0 number | Number | 65432 | | trigger-mitigation | boolean | 31 | 7 simple | T / F | | | missing-hb-allowed | grouping | 32 | 5 map | Object | | | current-value | int16 | 33 | 0 number | Number | 10 | | mitigation-start | decimal64 | 34 | 7 FP | Number | 10.21 | | target-prefix | leaf-list | | 4 array | Array | | | | ip-prefix | 35 | 3 text string | String | | | client-domain-hash | leaf-list | | 4 array | Array | | | | binary | 36 | 2 byte string | String | "abcdf" | | alt-server | string | 37 | 3 text string | String | | | alt-server-record | list | 38 | 4 array | Array | | | addr | string | 39 | 3 text string | String | | | ttl | int32 | 40 | 0 number | Number | 1800 | | conflict-scope | grouping | 41 | 5 map | Object | | | acl-name | string | 42 | 3 text string | String | "aname" | | acl-type | string | 43 | 3 text string | String | "ipv4" | | config-interval | int32 | 44 | 0 number | Number | 11 | | mitigating-config | grouping | 45 | 5 map | Object | | | idle-config | grouping | 46 | 5 map | Object | | | request-nonce | binary | 47 | 2 byte string | String | "xxx" | | min-value-decimal | decimal64 | 48 | 7 FP | Number | 1.1 | | max-value-decimal | decimal64 | 49 | 7 FP | Number | 1.1 | | current-value-decimal| decimal64 | 50 | 7 FP | Number | 1.1 | \----------------------+-------------+------+---------------+--------+------ ---/ Comments / suggestions? Regards Jon ------=_NextPart_000_0BD6_01D383E1.1B503D40 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Tiru,

 

Thanks – I think = we are good to go on this one.

 

Regards

 

Jon

 

From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of = Konda, Tirumaleswar Reddy
Sent: 02 January 2018 = 15:04
To: Jon Shallow; dots@ietf.org
Subject: Re: = [Dots] Signal CBOR / JSON Mapping

 

Hi = Jon,

 

Please see inline = [TR3]

 

From: Jon Shallow [mailto:supjps-ietf@jpshallow.co= m]
Sent: Tuesday, January 2, 2018 7:58 PM
To: = Konda, Tirumaleswar Reddy <TirumaleswarReddy_Kond= a@McAfee.com>; dots@ietf.org
Subject: RE: = [Dots] Signal CBOR / JSON Mapping

 

Hi = Tiru,

 

See inline = [Jon2]

 

Regards

 

Jon

 

 

 

From: Dots [mailto:dots-bounces@ietf.org] = On Behalf Of Jon Shallow
Sent: Friday, December 29, = 2017 2:32 AM
To: Konda, Tirumaleswar Reddy <TirumaleswarReddy_Kond= a@McAfee.com>; dots@ietf.org
Subject: Re: = [Dots] Signal CBOR / JSON Mapping

 

Hi = Tiru,

 

Thanks for pointing me = to these references.

 

RFC7951

6.1.  Numeric = Types

 

   A value of = the "int8", "int16", "int32", = "uint8", "uint16", or

   = "uint32" type is represented as a JSON = number.

 

   A value of = the "int64", "uint64", or "decimal64" type = is represented

   as a JSON string whose content is = the lexical representation of the

   = corresponding YANG type as specified in Sections 9.2.1 and 9.3.1 = of

   [RFC7950].

 

   For = example, if the type of the leaf "foo" in Section 5.1 = was

   "uint64" instead of = "uint8", the instance would have to be encoded = as

 

   = "foo": "123"

--

 

So, we now have a way of = handling int64/uint64 which should be used moving = forward.

 

However, my JSON = implementation (as well as many others I suspect) natively supports = decimal64, so does not necessarily need to display it as a lexical = representation string.  Do we follow RFC7951 here as = well?

 

[TR] Let’s not deviate from RFC7951 otherwise = both drafts will end-up defining it’s our own set of rules for = encoding the YANG configuration data as JSON/CBOR text deviating from = the existing standards.

[Jon] Agreed

 

I do not think that we = should be following the augmented JSON parameter naming in RFC7951 = “4. Names and Namespaces” otherwise we will start ending up = with JSON/CBOR parameter names such as = “ietf-dots-signal:mitigation-scope”.  If we do go with = this, then the CBOR mapping table will need to get extended to cover the = old, but some parameter name in different places.  = Comments?

 

[TR] Both = drafts should follow the naming in RFC7951.

[Jon] I’m neutral on this, but agree to = following standards – there will be however a lot of long = parameter names which fortunately will get compressed by the CBOR = mapping.  However, draft-ietf-netmod-acl-model (albeit in xml not = json) does not have parameter names such as = “ietf-access-control-list:access-lists”

=

[Jon1] We really need = to come to an agreement on this one.  I think I prefer simpler = names, but any program based YANG -> JSON translator following = RFC7951 will come up with the long names….  However as I = understand

“A = namespace-qualified member name MUST be used for all members of = a

   = top-level JSON object and then also whenever the namespaces of = the

   = data node and its parent node are different.  In all other cases, = the

   simple form of the member name MUST = be used.”

This probably only means that = “ietf-dots-signal:mitigation-scope”, = “ietf-acl:acl-name”, “ietf-acl:acl-type” and = “ietf-dots-signal:signal-config” are the changes =

 

[TR2] Yes.

 

(yes, acl-name & acl-type may be redefined = in netconf-acl – do we really need = acl-type?).

 

[TR2] I did = not get the above question !

 

[Jon2] In netconf-acl, = acl-name and acl-type (a proposal is outstanding to rename them to name = and type) both are a must when defined as a part of netconf-acl.  = However, acl-type is just a hint as to how to parse / handle the rest of = the definitions.  My question really was - as we are recording the = acl-name as the conflict, do we also need to record acl-type as = well.

 

[TR3] Yes.

 

As we are working with YANG, JSON and CBOR = interrelation , I still think we need a table similar to below to aid = implementers – referring as appropriate to the different RFCs = – no-one has full knowledge of all the evolving RFCs. =

 

[TR] I don’t see the need to repeat, its already = discussed in detail in https://tools.ie= tf.org/html/rfc8040#section-5.2 and similarly DOTS signal channel = draft already refers to draft-ietf-core-yang-cbor-05.

[Jon] Given the number = of times we have been inconsistent with the YANG / JSON and CBOR = definitions of a specific parameter, having a single place where all 3 = variants are on the same line certainly helps me as an = implementer.

 

[TR1] I am = trying to keep the CBOR mapping table simple (not too wide J), it can be updated to add YANG = type. Why do we need the corresponding JSON type and JSON examples in = the table ?

[Jon1] I agree that we have a 72 character width = limit.  I do not think we need the JSON examples column, but do = think we need the JSON type so we have YANG, CBOR and JSON equivalent = types in one place.  However, if the parameter names get long = –e.g. “ietf-dots-signal:mitigation-scope”, we will run = out of width unless they are split over 2 lines.

 

[TR2] Yes, = some of the parameter names need to be split into 2 lines. DOTS signal = channel does not deal with JSON encoding, what is the need to discuss = equivalent JSON type in the signal channel draft =  ?

 

[Jon2] I agree that all = the data interchange between the DOTS peers will be in CBOR format, = derived from the YANG model definition.  However, the data channel = has aliases defined in JSON from the YANG model definition, and at some = point there has to be a mapping between CBOR and JSON when handling = aliases.  As all the examples of GET, PUT etc. in the signal draft = are using JSON, making sure that JSON and CBOR is correctly mapped is = helpful to me and maybe others (I read JSON better than CBOR!).  =

 

[TR3] Okay, will update the table to include YANG and = JSON types.

 

-Tiru

 

[Jon1] NOTE.  If we have to do changes to = parameter names, this may be a suitable break point to re-sort the list = by parameter name for ease of readability / lookup – especially = if/as we are doing a lot of other fundamental changes post -14 with all = the other discussions – time to clean things = up!

 

[TR] Sure.

 

-Tiru

 

Regards

 

Jon

 

From: Dots [mailto: dots-bounces@ietf.org] On = Behalf Of Konda, Tirumaleswar Reddy
Sent: 23 December 2017 = 07:06
To: Jon Shallow; dots@ietf.org
Subject: Re: = [Dots] Signal CBOR / JSON Mapping

 

We should just follow = the CBOR Encoding of Data Modeled with YANG defined in https:/= /tools.ietf.org/html/draft-ietf-core-yang-cbor-05 and JSON Encoding = of Data Modeled with YANG

defined in https://tools.ietf.org/html/= rfc7951.

 

-Tiru

 

From: Dots [mailto:dots-bounces@ietf.org] = On Behalf Of Jon Shallow
Sent: Friday, December 22, = 2017 10:41 PM
To: dots@ietf.org
Subject: = [Dots] Signal CBOR / JSON Mapping

 

Hi WG,

 

There are a = lot of YANG parameters that we are using that are defined as = int64.  JSON only safely supports up to 53 bits of = precision.

 

RFC 7493 2.2 Numbers

 

   = An I-JSON sender cannot expect a receiver to treat an integer = whose

   absolute value is = greater than 9007199254740991 (i.e., that is

   outside the range [-(2**53)+1, = (2**53)-1]) as an exact value.

 

   = For applications that require the exact interchange of numbers = with

   greater magnitude = or precision, it is RECOMMENDED to encode them in

   JSON string values.  This requires = that the receiving program

   understand the intended semantic of the = value.  An example would be

   64-bit integers, even though modern = hardware can deal with them,

   because of the limited scope of = JavaScript numbers.

 

RFC7049 3.6 = Numbers

 

   CBOR-based protocols should take into = account that different language

   environments pose different restrictions = on the range and precision

   of numbers that are representable.  = For example, the JavaScript

   number system treats all numbers as = floating point, which may result

   in silent loss of precision in decoding = integers with more than 53

   significant bits.  A protocol that = uses numbers should define its

   expectations on the handling of = non-trivial numbers in decoders and

   receiving applications.

 

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

 

An option is = to make all of these int64 decimal64 for the signal channel, but that = does not cover the 64 bit counters in the netmod-acl.  However, as = the netmod-acl counters are also fed back via the mitigate status, we do = not necessarily need to support the netmod-acl = counters.

 

If, however, we follow RFC 7493, in CBOR the data can = be passed across as 64 bits, and as the parameter is a CBOR mapping, we = can know how to encode / decode the JSON value as appropriate.  = However, RFC 7493 does not say whether this should be base64, base64url = or numeric string representation (i.e. “1234567890”). =  RFC7049 refers to bignum (major type 6, tag value 2 or 3) should = be encoded as base64url (4.1 Converting from CBOR to JSON) – but = int64 can be held in CBOR as type 0 or 1.

 

I prefer the = numeric string representation as it is humanly easy to read and easy to = convert into 64 bit integers.

 

If we take = this approach of using the parameter which is a CBOR mapping key to key = off how to encode / decode the JSON, I would suggest that we could = extend this to include IP addresses, Dates and client-identifiers (or = their possible new names of request-nonce and client-domain-hash) to = further minimize the actual number of bytes sent in a COAP = packet.

 

The CBOR mapping Table could then be extended to look = something like (but it is too wide I think)

 

/----------------------+-------------+------+--------------= -+--------+---------\

| Parameter = name       | YANG type   | CBOR = | CBOR major    | JSON   | = JSON    | 

|         &nbs= p;            = |            = | key  | = type          | = type   | Example |

|----------------------+-------------+------+--------------= -+--------+---------|

| = mitigation-scope     | grouping    = |   1  | 5 = map         | Object = |         |  =

| = scope           &n= bsp;    | list        = |   2  | 4 array       | = Array  |         |  =

| = mitigation-id        | = int32       |   3  | 0 = unsigned    | Number | 54321   |  =

| = acl-list        =      | = list        |   4  | 4 = array       | Array  = |         |  =

| = target-port-range    | = list        |   5  | 4 = array       | Array  = |         |  =

| = lower-port           | = port-number |   6  | 0 = number      | Number | 1111    = | 

| = upper-port           | = port-number |   7  | 0 = number      | Number | 1111    = | 

| = target-protocol      | leaf-list   = |      | 4 = array       | Array  = |         |  =

|         &nbs= p;            | = uint8       |   8  | 0 = number      | Number | = 6       |

| = target-fqdn          | = leaf-list   |      | 4 = array       | Array  = |         = |

|         &nbs= p;            | = domain-name |   9  | 3 text string | String | = "a.com" |

| = target-uri           | = leaf-list   |      | 4 = array       | Array  = |         |  =

|         &nbs= p;            | = uri         |  10  | 3 = text string | String |         = |

| = alias-name           | = leaf-list   |      | 4 = array       | Array  | =         |  =

| =             &= nbsp;        | = string      |  11  | 3 text string | = String | "web"   | 

| = lifetime           = ;  | int32       |  12  | 0 = number      | Number = |         |  =

| = attack-status        | enumeration = |  13  | 0 number      | Number | = 1       | 

| signal-config        = | grouping    |  14  | 5 = map         | Object = |         |  =

| = heartbeat-interval   | grouping    |  = 15  | 5 map         | = Object |         |  =

| = max-retransmit       | = grouping    |  16  | 5 = map         | Object = |         |  =

| = ack-timeout          | = grouping    |  17  | 5 = map         | Object = |         |  =

| = ack-random-factor    | grouping    |  = 18  | 5 map         | = Object |         |  =

| = min-value   =          | = int16       |  19  | 0 = number      | Number | = 1       | 

| = max-value          &nbs= p; | int16       |  20  | 0 = number      | Number | = 1       | 

| = status           &= nbsp;   | enumeration |  21  | 0 = number      | Number | = 1       | 

| conflict-information | grouping    = |  22  | 5 map         = | Object |         |  =

| = conflict-status      | enumeration |  = 23  | 0 number      | Number | = 1       | 

| conflict-cause       | = enumeration |  24  | 0 number      | = Number | 1       |  =

| = retry-timer          | = int32       |  25  | 0 = number      | Number | 1800    = | 

| = bytes-dropped        | = counter64   |  26  | 0 = number      | String | "1234"  = | 

| = bps-dropped          | = counter64   |  27  | 0 = number      | String | "1234"  = | 

| = pkts-dropped         | counter64 =   |  28  | 0 number      | = String | "1234"  | 

| = pps-dropped          | = counter64   |  29  | 0 = number      | String | "1234"  = | 

| = session-id           | = int32       |  30  | 0 = number      | Number | 65432   = | 

| = trigger-mitigation   | boolean     |  = 31  | 7 simple      | T / F  = |         |  =

| = missing-hb-allowed   | grouping    |  = 32  | 5 map         | = Object |         |  =

| = current-value        | = int16       |  33  | 0 = number      | Number | = 10      | 

| mitigation-start     | = decimal64   |  34  | 7 = FP          | Number | = 10.21   | 

| target-prefix        = | leaf-list   |      | 4 = array       | Array  = |         |  =

| =             &= nbsp;        | = ip-prefix   |  35  | 3 text string | String = |         |  =

| = client-domain-hash   | leaf-list   |  =     | 4 array       | = Array  |         = |

| =             &= nbsp;        | = binary      |  36  | 2 byte string | = String | "abcdf" |

| = alt-server           | = string      |  37  | 3 text string | = String |         |  =

| = alt-server-record    | = list        |  38  | 4 = array       | Array  = |         |  =

| = addr           &nb= sp;     | string      = |  39  | 3 text string | String = |         |  =

| = ttl           &nbs= p;      | = int32       |  40  | 0 = number      | Number | 1800    = | 

| = conflict-scope       | = grouping    |  41  | 5 = map         | Object = |         |  =

| = acl-name           = ;  | string      |  42  | 3 text = string | String | "aname" | 

| = acl-type           = ;  | string      |  43  | 3 text = string | String | "ipv4"  |  =

| = config-interval      | = int32       |  44  | 0 = number      | Number | = 11      | 

| mitigating-config    | = grouping    |  45  | 5 = map         | Object = |         |  =

| = idle-config          | = grouping    |  46  | 5 = map         | Object = |         |  =

| = request-nonce        | = binary      |  47  | 2 byte string | = String | "xxx"   | 

| min-value-decimal    | = decimal64   |  48  | 7 = FP          | Number | = 1.1     | 

| max-value-decimal    | = decimal64   |  49  | 7 = FP          | Number | = 1.1     | 

| current-value-decimal| decimal64   |  = 50  | 7 FP          | = Number | 1.1     | 

\----------------------+-------------+------+--------------= -+--------+---------/

 

 

Comments / = suggestions?

 

Regards

 

Jon

<= /body> ------=_NextPart_000_0BD6_01D383E1.1B503D40-- From nobody Tue Jan 2 07:50:09 2018 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 0393312D574 for ; Tue, 2 Jan 2018 07:50:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 IGhHK-39al0D for ; Tue, 2 Jan 2018 07:50:05 -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 E606C12AF77 for ; Tue, 2 Jan 2018 07:50:04 -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 1eWOpG-0006sb-6k; Tue, 02 Jan 2018 15:50:02 +0000 From: "Jon Shallow" To: "'Konda, Tirumaleswar Reddy'" , , "kaname nishizuka" References: <094801d3801e$f7ab01b0$e7010510$@jpshallow.com> <099601d38096$487c9410$d975bc30$@jpshallow.com> <0b7a01d383bb$aba5f720$02f1e560$@jpshallow.com> <0b8501d383be$df5ec030$9e1c4090$@jpshallow.com> <0bb401d383d2$cbbdc9e0$63395da0$@jpshallow.com> In-Reply-To: Date: Tue, 2 Jan 2018 15:50:00 -0000 Message-ID: <0be801d383e1$58e74c70$0ab5e550$@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: AQLSq4q/0bL2TF/Kn5VRXUOjWNcfvgJYRDCAAhO9FZgBoHWANAIl/Wr3An6e4NwCKRTIOQIYzMyoAvRMDxABonzsT6DGHT6A Archived-At: Subject: Re: [Dots] [signal-channel-draft] CoAP libraries have problems with the DOTS spec 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, 02 Jan 2018 15:50:08 -0000 Hi Tiru, Thanks - I think we are good to go with this one. Thanks Kaname for pointing this issue out. Regards Jon -----Original Message----- From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of Konda, Tirumaleswar Reddy Sent: 02 January 2018 15:10 To: Jon Shallow; dots@ietf.org; kaname nishizuka Subject: Re: [Dots] [signal-channel-draft] CoAP libraries have problems with the DOTS spec > -----Original Message----- > From: Jon Shallow [mailto:supjps-ietf@jpshallow.com] > Sent: Tuesday, January 2, 2018 7:36 PM > To: Konda, Tirumaleswar Reddy > ; dots@ietf.org; kaname nishizuka > > Subject: RE: [Dots] [signal-channel-draft] CoAP libraries have > problems with the DOTS spec > > Hi Tiru, > > See inline [Jon4] > > Regards > > Jon > > > > > > > -----Original Message----- > > > > From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of kaname > > > > nishizuka > > > > Sent: 28 December 2017 10:02 > > > > To: dots@ietf.org > > > > Subject: [Dots] [signal-channel-draft] CoAP libraries have > > > > problems with the DOTS spec > > > > > > > > Hi, > > > > > > > > Last week, Jon and I did the second interoperability test based > > > > on the > > > > -13 version of the signal channel draft. > > > > We made significant improvements of each implementation. Several > > > > feedbacks to the WG have been made by Jon already. > > > > > > > > Based on the experience, I encountered the problems between CoAP > > > > libraries and the specification of the DOTS. > > > > > > > > 1. resource identification of GET methods. > > > > > > > > In signal channel spec, the target resource in GET method is > > > > identified in the BODY of the message, that is mitigation-id > > > > (and > > > client-identifier). > > > > However, CoAP libraries, at least we investigated, only see the > > > > Request URI, so it cannot locate the resource because it doesn't > > > > see the > > > BODY. > > > > > > > > So the question is, why does the DOTS spec use CoAP Body for > > > > resource identifier? > > > > > > > > [Jon] A very good question. I had just assumed that this was > > > > the way to do it, but had noted that this was not done when > > > > using HTTP > etc. > > > > and so was different. See later comments > > > > > > > > Most of CoAP libraries only support request URI in CoAP > > > > GET/observe, which is the spec from RFC7252. > > > > https://tools.ietf.org/html/rfc7252 > > > > 5.8.1.GET > > > > The GET method retrieves a representation for the information that > > > > currently corresponds to the resource identified by the > > > > request > URI. > > > > [Jon] RFC 7252 states also > > > > 5.10.1. Uri-Host, Uri-Port, Uri-Path, and Uri-Query > > > > > > > > The Uri-Host, Uri-Port, Uri-Path, and Uri-Query Options are used to > > > > specify the target resource of a request to a CoAP origin server. > > > > [Jon] So it looks like the target resource should only be in > > > > Uri-Path and/or Uri-Query. > > > > [Jon] In my CoAP Library, I have to define each individual > > > > resource (it does a lookup against a hash of the complete Uri to > > > > find whether the resource is known or not), so, when say > > > > mitigation-id=2 is added, I need to register the resource > > > > .well-known/dots/v1/mitigate/migration-is=2 with an associated > > > > handler. This is not difficult to do, but potentially could > > > > consume a lot > > > of DOTS server resources if many mitigations are active. > > > > [Jon] Doing it as a Query Option I think is my preference - Comments? > > > > [Jon] The same is true for GET signal configuration as well. > > > > > > Yes, will update draft to use Query option for GET method. > > > [Jon2] This works for me, but does not feel right when this is > > > extended for "PUT .../mitigate Query mitigation-id-2" to create > > > the mitigation-id. I think that the complete "resource" should be > > > specified for consistency and just leave the c=? as being the > > > required > > valid Query option. > > > > PUT method does not need to convey the Query Option (for example > > please see https://tools.ietf.org/html/rfc7967#section-4.1.1, the > > resource is specified in the URI-path option itself). > > > > [Jon3] Agreed - and think that the full resource needs to be > > specified for the DELETE (need to fix my libcoap library to not > > respond with 4.04 if resource does not exist as per RFC7252) as well > > that the GET. However, "GET .../mitigate" should return all current > > mitigations if the mitigation-id is not specified in the Uri-Path.. > > Yes. > > [Jon4] mitigation-id needs to be included as a parameter in the body > in response to "GET .../mitigate". I assume for consistency, it > should also be returned as a parameter for "GET .../mitigate/mitigation-id=ZZ". Yes. > [Jon4] So when doing "PUT .../mitigate/mitigation-id=ZZ", do we also > include in the PUT data body the parameter mitigation-id = ZZ? What > happens if they are different? I don't see the need to convey "mitigation-id=ZZ" in the PUT body if it is conveyed in the Uri-Path. > > > > > [Jon3] The same is for configuration (GET, PUT & DELETE) - which > > then begs the question - do we really need "session-id" ? > > session-id is introduced to handle out-of-order delivery of PUT > requests, the PUT request with a higher numeric 'session-id' value > overrides the DOTS signal channel session configuration data installed > by a PUT request with a lower numeric 'session-id' value. > > [Jon4] Understood. And the lesser session-id resource would be no > more (i.e. the resource is deleted). > [Jon4] As this signal configuration is only defining a specific > session (there may be multiple sessions) between 2 DOTS peers, "client-identifier" > (or "request-nonce") are not really needed to be supported as a part > of the resource. Yes. > [Jon4] We need a "GET .../config" to get the server sides (initial) > notion of what is supported for configuration. We would then support > "GET .../config/session-id=YY" (only can be done following a PUT > otherwise session-id is unknown). The PUT would definitely have to be > "PUT ../config/session-id-YY". The DELETE would be either "DELETE > .../config" or "DELETE .../config/session-id=YY" where both of them > reset the signal configuration back to the defaults. "DELETE > .../config" would get rid of any session-ids for that particular session. Agreed. -Tiru > > -Tiru > > > > > > > > > > > > > > [Jon1] I am now leaning towards doing it in the Uri-Path but > > > > still not > > > sure. > > > > The CoAP layer responds with a 4.04 with my CoAP library if the > > > > resource > > > > (Uri-Path) is unknown. > > > > [Jon1] We need to define the order in the path - e.g. > > > > client-identifier (or request-none etc. if that is accepted) > > > > then mitigation-id, so that resources are built consistently > > > > from a mitigation > > > request. > > > > > > Agreed. > > > [Jon2] then something similar to the above specifying ordering > > > needs to be put into the draft. > > > > Yes. > > > > > > > > > [Jon1] However doing this means we also need to include PUT and > > > > DELETE with the resource specified in the Uri-Path. My library > > > > then runs into a chicken and egg situation with PUT - the PUT is > > > > defining the new resource, but as the resource is not defined > > > > (yet) in the CoAP layer, it gets rejected with a > > > > 4.04 in the CoAP layer (as mentioned above). The way around > > > > this is to use POST to create new mitigation requests (and will > > > > respond with appropriate Location-Path to give the new UI) and > > > > PUT if we are refreshing > > > the resource. > > > > > > > > [Jon1] Thoughts? > > > > > > PUT can also be used to create a new resource, and the draft uses > > > PUT instead of POST because it is idempotent and during a > > > volumetric DDoS attack saturating the incoming link to the DOTS > > > client, DOTS client will most likely not receive the server-side > > > responses. Is this an > > implementation bug ? > > > > > > [Jon2] I agree that it is a bug in the libcoap I am using > > > [https://github.com/obgm/libcoap]. RFC7252 5.8.3. PUT states "The > > > PUT method requests that the resource identified by the request > > > URI be updated or created". I can try to fix the library to keep > > > on stripping off the last UriPath and then doing a hash lookup on > > > the sub path until a match is found in the case of doing a PUT. > > > It would then (in my case - not needed in the > > > draft) be the responsibility of creating a new resource if needed > > > in the DOTS layer. > > > > Thanks. > > > > Cheers, > > Tiru > > > > > > > > -Tiru > > > > > > > > > > > 2. Confirmable vs NonConfirmable at Mitigation Request > > > > > > > > A CoAP library (dustin/go-coap) stops listening right after > > > > sending out the NonConfirmable message because NonConfirmable > > > > messages do > > > not > > > > require acknowledgements. > > > > > > > > [Jon] As there is a good chance during attack scenarios that > > > > responses may not be able to get back, it makes sense to me that > > > > these "GET > > > mitigation" > > > > requests are non-confirmable. Certainly "PUT mitigation" needs > > > > to be thought of as a one way signal. There are times that the > > > > client has to run "blind" during attack scenarios. > > > > [Jon]If they were confirmable, then the request will get sent > > > > multiple times to the DOTS server - which could be handled by > > > > the server, but then the confirmable responses would retried > > > > whilst sending back to the DOTS client and eventually retry > > > > timeout. A large scale attack could swamp a DOTS server with > > > > all the yet to be confirmed confirmable > > > responses. > > > > [Jon] As per RFC7252 "2.2. Request/Response Model", a response > > > > to a > > > > non- confirmable request is expected to be handled as in:- > > > > If a request is sent in a Non-confirmable message, then the > response > > > > is sent using a new Non-confirmable message, although the > > > > server > may > > > > instead send a Confirmable message. This type of exchange is > > > > illustrated in Figure 6. > > > > > > > > Client Server > > > > | | > > > > | NON [0x7a11] | > > > > | GET /temperature | > > > > | (Token 0x74) | > > > > +----------------->| > > > > | | > > > > | NON [0x23bc] | > > > > | 2.05 Content | > > > > | (Token 0x74) | > > > > | "22.5 C" | > > > > |<-----------------+ > > > > | | > > > > > > > > Figure 6: A Request and a Response Carried in Non-confirmable > > > > Messages [Jon] So I would > > > > expect any CoAP library to support this non-confirmation > > > > mechanism by receiving a new non- confirmable message. It would > > > > be the responsibility of the DOTS layer to associate the Tokens > > > > together to handle the responses with > > > the requests. > > > > [Jon] In addition, when Observe is enabled, the DOTS server will > > > > continue to generate non-confirmable messages with the same Token. > > > > Again, the DOTS client will need to know what to do with the > > > > Token (which could be to update things, or to send a RST if no > > > > more packets with the same Token should be sent. > > > > > > > > > > > > The spec of Confirmable message already have the retransmission > > > > mechanism, so using Confirmable message is an easier way to > > > > notice that the message has been lost during the attack time. > > > > > > > > [Jon] The DOTS client will know something is wrong as it will be > > > > seeing heartbeat issues. > > > > > > > > I'm afraid I'm missing some previous discussions we made on the > > > > ML and at the WG meeting, but we have a problem with the CoAP > > > > library regarding this spec. > > > > > > > > * At the -08 version of the signal channel draft, this change > > > > was > made: > > > > DOTS mitigation request/response are marked as non-confirmable > > > messages. > > > > > > > > thank you, > > > > Kaname > > > > > > > > > > > > _______________________________________________ > > > > Dots mailing list > > > > Dots@ietf.org > > > > https://www.ietf.org/mailman/listinfo/dots > > > > > > > > _______________________________________________ > > > > Dots mailing list > > > > Dots@ietf.org > > > > https://www.ietf.org/mailman/listinfo/dots > > > > > > > > _______________________________________________ > > > > Dots mailing list > > > > Dots@ietf.org > > > > https://www.ietf.org/mailman/listinfo/dots > > > > > > _______________________________________________ > > > Dots mailing list > > > Dots@ietf.org > > > https://www.ietf.org/mailman/listinfo/dots > > > > _______________________________________________ > > Dots mailing list > > Dots@ietf.org > > https://www.ietf.org/mailman/listinfo/dots > > _______________________________________________ > Dots mailing list > Dots@ietf.org > https://www.ietf.org/mailman/listinfo/dots _______________________________________________ Dots mailing list Dots@ietf.org https://www.ietf.org/mailman/listinfo/dots From nobody Tue Jan 2 08:30:02 2018 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 71B91127978 for ; Tue, 2 Jan 2018 08:30:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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] 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 C70IARa7yovz for ; Tue, 2 Jan 2018 08:29:59 -0800 (PST) Received: from mail-pg0-x232.google.com (mail-pg0-x232.google.com [IPv6:2607:f8b0:400e:c05::232]) (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 5489A124319 for ; Tue, 2 Jan 2018 08:29:59 -0800 (PST) Received: by mail-pg0-x232.google.com with SMTP id f18so7823838pga.10 for ; Tue, 02 Jan 2018 08:29:59 -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:content-transfer-encoding; bh=hHNLEfLYkwlNEZmJn23/qvTHkyyuHDbOjWF5rAK9Svs=; b=Cb5Z9mHNNbXXmhN5MRVfcEd6RHFQAfTBCAY/a5KEa+dB5qoTtqfRkVpPVkqNLPzQbb 31U1rMZEpeiTq0qIRpJDFTIpI4aZwkh7H4X/zCAtCWctS7SVOWOFUVEh1xsuGJngRzk0 cIG8CfgWXRn0QJuspyLanSs/UrsYKT7ql/NFQVzxb7IZ37VW5/GcLpn+sTaRv0FXn7L1 a3aBNfpOAsZoRDYja2K4q9rQ+wuQdX7CdCqJc7Zn8Bjjyvlx6TJR+87avYrwMjZ9p40n CKuHw/400bHetOqAVZbIvztdGQrBxdyn0ZQQYjxI/vnUJoDuewRRXImavln7csUkusNC EYZQ== 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:content-transfer-encoding; bh=hHNLEfLYkwlNEZmJn23/qvTHkyyuHDbOjWF5rAK9Svs=; b=mQOWBmisw+6PNNf4pUhmzLL8SNV2siAz1fGGSzQazCXSSwttnuQFj5AJifm3z2HR34 9FLittD147ZixQcftGEvczPtTClDpYUi/ewz8ADDLvSy3dgHdv3XYrr2aOB3qfVxhVVT XV0kgYu8MdyHkkl6zTT7HUoEKAj2+5jBz0VVoD5K+y8dQGyQ5nMERwFyPqbzAQLTz1cF g+gjks16PM/xE0ePf1n1lcNnZlaCsZnAl2Vc8WWVV3Jjh57XL088mpYaXT9YF7cUWHHf Rltw6kKaol8HqTt9XGZaZhBNrpicdyZn6LeeBNQ0zYhdKeCXWf9U8zXs5rAIX/KxBidq Yfgg== X-Gm-Message-State: AKGB3mLFg+L+u01rChY0W8r9HHcquxTsDoyF7Vu6e64J5Je5J2nnTWzt RKcOfJTOTeIGsZqTXtDWmRPbSC6LjcYZKbwgbaw= X-Google-Smtp-Source: ACJfBotCUUrdr40xQRUesckprIxQ0Bpno5OqN751Ta2/pJ65lwEvEmdgjmw0yMm7hlZn4ZSozF8fVP6RY0ompkY/1j4= X-Received: by 10.98.72.69 with SMTP id v66mr45774115pfa.135.1514910598763; Tue, 02 Jan 2018 08:29:58 -0800 (PST) MIME-Version: 1.0 Received: by 10.100.186.208 with HTTP; Tue, 2 Jan 2018 08:29:18 -0800 (PST) In-Reply-To: <0b4b01d383b0$758f1370$60ad3a50$@jpshallow.com> References: <0a1201d38161$299ef350$7cdcd9f0$@jpshallow.com> <0b2301d383ad$a8822a40$f9867ec0$@jpshallow.com> <0b4b01d383b0$758f1370$60ad3a50$@jpshallow.com> From: Kathleen Moriarty Date: Tue, 2 Jan 2018 11:29:18 -0500 Message-ID: To: Jon Shallow Cc: "Konda, Tirumaleswar Reddy" , dots@ietf.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Dots] Using SNI 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, 02 Jan 2018 16:30:01 -0000 Hello, You might want to discuss your use of SNI on the TLS mailing list after reviewing this adopted draft: https://tools.ietf.org/html/draft-ietf-tls-sni-encryption-00 It'll just be an option in TLS 1.3, but will prevent your use of SNI as a middlebox if/when implemented. Best regards, Kathleen On Tue, Jan 2, 2018 at 5:00 AM, Jon Shallow wro= te: > Hi Tiru, > > > > That certainly works for me =E2=80=93 thanks > > > > Regards > > > > Jon > > > > From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of Konda, Tirumalesw= ar > Reddy > Sent: 02 January 2018 09:55 > > > To: Jon Shallow; dots@ietf.org > Subject: Re: [Dots] Using SNI > > > > Hi Jon, > > > > RESTCONF does not mandate client authentication based on TLS client > certificate, we can say the following instead: > > If TLS client certificate is used to authenticate the DOTS client, the DO= TS > client MUST include the DOTS server FQDN in server name indication extens= ion > (Section 3 of RFC6066). > > > > Cheers, > > -Tiru > > > > From: Jon Shallow [mailto:supjps-ietf@jpshallow.com] > Sent: Tuesday, January 2, 2018 3:10 PM > To: Konda, Tirumaleswar Reddy ; > dots@ietf.org > Subject: RE: [Dots] Using SNI > > > > Hi Tiru, > > > > I agree that (indirectly through RFC7525 reference) SNI is mandated to be > supported (but not necessarily has to be used). > > > > However, to guarantee interoperability between different DOTS vendors, I = am > saying that the use of SNI is a MUST =E2=80=93 in particular for the data= channel. > > > > Regards > > > > Jon > > > > From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of Konda, Tirumalesw= ar > Reddy > Sent: 02 January 2018 08:48 > To: Jon Shallow; dots@ietf.org > Subject: Re: [Dots] Using SNI > > > > Hi Jon, > > > > Both signal and data channel drafts refer to RFC7525 for secure use of > (D)TLS and RFC7525 mandates TLS implementations to support SNI. I don=E2= =80=99t see > the need to explicitly discuss SNI in these drafts. > > > Regards, > > -Tiru > > > > From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Jon Shallow > Sent: Saturday, December 30, 2017 4:57 PM > To: dots@ietf.org > Subject: [Dots] Using SNI > > > > Hi WG, > > > > When providing a DOTS server data channel service in my environment, this > shares the same ip / port which also provides other services (e.g. GUI / > REST server etc.). Even if the Root Discovery points to another IP and o= r > port for the actual data channel activity, the TLS exchanges for the Root > Discovery have to correctly work. I suspect that I am not the only DOTS > vendor who will have this type of requirement of a single IP providing > multiple TLS services. > > > > As DOTS requires mutual authentication, this is a different security > requirement than required by the GUI environment (DOTS requires client ce= rt > to be presented, GUI does not and providing certificates to every GUI cli= ent > is not a practical option). > > > > This can be handled by using SNI by using 2 different FQDNs and requiring > the DOTS client to include the DOTS specific FQDN in the TLS Client Hello= . > Whether the GUI client does or does not (likely does with modern browsers= ) > include a SNI FQDN when connecting to the non DOTS FQDN does not really > matter =E2=80=93 for DOTS it is recognizing the DOTS specific FQDN and se= tting up > the TLS as appropriate. > > > > To make sure interoperability between DOTS vendors, I would like to see > something like added to the data channel spec =E2=80=9CDOTS clients MUST = include the > DOTS server FQDN in the TLS Client Hello packet by using Server Name > Indication (SNI) RFC 3546=E2=80=9D. > > > > In addition, I think that this would be a good idea as well for the signa= l > draft =E2=80=93 thereby giving DOTS vendors the opportunity to host multi= ple DOTS > servers (likely to be different security requirements for their different > client) on a single IP / port. > > > > Thoughts / comments? > > > > Regards > > > > Jon > > > _______________________________________________ > Dots mailing list > Dots@ietf.org > https://www.ietf.org/mailman/listinfo/dots > --=20 Best regards, Kathleen From nobody Tue Jan 2 08:52:01 2018 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 77764124BFA for ; Tue, 2 Jan 2018 08:51:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 9Of0niGQywSC for ; Tue, 2 Jan 2018 08:51:57 -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 46133124319 for ; Tue, 2 Jan 2018 08:51:57 -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 1eWPn9-0006uM-ET; Tue, 02 Jan 2018 16:51:55 +0000 From: "Jon Shallow" To: "'Kathleen Moriarty'" , "Konda, Tirumaleswar Reddy" , References: <0a1201d38161$299ef350$7cdcd9f0$@jpshallow.com> <0b2301d383ad$a8822a40$f9867ec0$@jpshallow.com> <0b4b01d383b0$758f1370$60ad3a50$@jpshallow.com> In-Reply-To: Date: Tue, 2 Jan 2018 16:51:53 -0000 Message-ID: <0bed01d383e9$fe2543b0$fa6fcb10$@jpshallow.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Content-Language: en-gb Thread-Index: AQIpdHJXTEWkUmLWfrWfFs+hkFSqvAJ19VeLAlAhTlAB/1BuRQHRwg9pAKRe7UKiawtaIA== Archived-At: Subject: Re: [Dots] Using SNI 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, 02 Jan 2018 16:51:59 -0000 Hi Kathleen. Thanks for keeping a watch out for things like this. However, the use of SNI would be on a hop by hop basis - a DOTS client = would be talking directly to the next hop DOTS server by resolving its = FQDN and using server_name extension in the client_hello - the = connection terminating on the DOTS server. If the DOTS server was a = part of a DOTS gateway, then the new connection from the DOTS gateway to = the next DOTS server would be using a different FQDN so I do not think = we will have an issue here. Regards Jon -----Original Message----- From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of Kathleen = Moriarty Sent: 02 January 2018 16:29 To: Jon Shallow Cc: Konda, Tirumaleswar Reddy; dots@ietf.org Subject: Re: [Dots] Using SNI Hello, You might want to discuss your use of SNI on the TLS mailing list after = reviewing this adopted draft: https://tools.ietf.org/html/draft-ietf-tls-sni-encryption-00 It'll just be an option in TLS 1.3, but will prevent your use of SNI as = a middlebox if/when implemented. Best regards, Kathleen On Tue, Jan 2, 2018 at 5:00 AM, Jon Shallow = wrote: > Hi Tiru, > > > > That certainly works for me =E2=80=93 thanks > > > > Regards > > > > Jon > > > > From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of Konda,=20 > Tirumaleswar Reddy > Sent: 02 January 2018 09:55 > > > To: Jon Shallow; dots@ietf.org > Subject: Re: [Dots] Using SNI > > > > Hi Jon, > > > > RESTCONF does not mandate client authentication based on TLS client=20 > certificate, we can say the following instead: > > If TLS client certificate is used to authenticate the DOTS client, the = > DOTS client MUST include the DOTS server FQDN in server name=20 > indication extension (Section 3 of RFC6066). > > > > Cheers, > > -Tiru > > > > From: Jon Shallow [mailto:supjps-ietf@jpshallow.com] > Sent: Tuesday, January 2, 2018 3:10 PM > To: Konda, Tirumaleswar Reddy ; > dots@ietf.org > Subject: RE: [Dots] Using SNI > > > > Hi Tiru, > > > > I agree that (indirectly through RFC7525 reference) SNI is mandated to = > be supported (but not necessarily has to be used). > > > > However, to guarantee interoperability between different DOTS vendors, = > I am saying that the use of SNI is a MUST =E2=80=93 in particular for = the data channel. > > > > Regards > > > > Jon > > > > From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of Konda,=20 > Tirumaleswar Reddy > Sent: 02 January 2018 08:48 > To: Jon Shallow; dots@ietf.org > Subject: Re: [Dots] Using SNI > > > > Hi Jon, > > > > Both signal and data channel drafts refer to RFC7525 for secure use of = > (D)TLS and RFC7525 mandates TLS implementations to support SNI. I=20 > don=E2=80=99t see the need to explicitly discuss SNI in these drafts. > > > Regards, > > -Tiru > > > > From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Jon Shallow > Sent: Saturday, December 30, 2017 4:57 PM > To: dots@ietf.org > Subject: [Dots] Using SNI > > > > Hi WG, > > > > When providing a DOTS server data channel service in my environment,=20 > this shares the same ip / port which also provides other services=20 > (e.g. GUI / REST server etc.). Even if the Root Discovery points to=20 > another IP and or port for the actual data channel activity, the TLS=20 > exchanges for the Root Discovery have to correctly work. I suspect=20 > that I am not the only DOTS vendor who will have this type of=20 > requirement of a single IP providing multiple TLS services. > > > > As DOTS requires mutual authentication, this is a different security=20 > requirement than required by the GUI environment (DOTS requires client = > cert to be presented, GUI does not and providing certificates to every = > GUI client is not a practical option). > > > > This can be handled by using SNI by using 2 different FQDNs and=20 > requiring the DOTS client to include the DOTS specific FQDN in the TLS = Client Hello. > Whether the GUI client does or does not (likely does with modern=20 > browsers) include a SNI FQDN when connecting to the non DOTS FQDN does = > not really matter =E2=80=93 for DOTS it is recognizing the DOTS = specific FQDN=20 > and setting up the TLS as appropriate. > > > > To make sure interoperability between DOTS vendors, I would like to=20 > see something like added to the data channel spec =E2=80=9CDOTS = clients MUST=20 > include the DOTS server FQDN in the TLS Client Hello packet by using=20 > Server Name Indication (SNI) RFC 3546=E2=80=9D. > > > > In addition, I think that this would be a good idea as well for the=20 > signal draft =E2=80=93 thereby giving DOTS vendors the opportunity to = host=20 > multiple DOTS servers (likely to be different security requirements=20 > for their different > client) on a single IP / port. > > > > Thoughts / comments? > > > > Regards > > > > Jon > > > _______________________________________________ > Dots mailing list > Dots@ietf.org > https://www.ietf.org/mailman/listinfo/dots > --=20 Best regards, Kathleen _______________________________________________ Dots mailing list Dots@ietf.org https://www.ietf.org/mailman/listinfo/dots From nobody Tue Jan 2 08:56:45 2018 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 17392124BFA for ; Tue, 2 Jan 2018 08:56:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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] 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 FFrcxjglGEdL for ; Tue, 2 Jan 2018 08:56:40 -0800 (PST) Received: from mail-pl0-x232.google.com (mail-pl0-x232.google.com [IPv6:2607:f8b0:400e:c01::232]) (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 C3027124319 for ; Tue, 2 Jan 2018 08:56:40 -0800 (PST) Received: by mail-pl0-x232.google.com with SMTP id d21so28991378pll.1 for ; Tue, 02 Jan 2018 08:56:40 -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:content-transfer-encoding; bh=wVkzFb2iiXAmBr9IBejcOCjg9GYbzWkKbMHkxQ2Y1VQ=; b=kW5KJ9YXT6XgLGHvu/ihl2lqeHKGfRCK9on+LFAcvqpxaOajX7xziOR4kNsw8o29Ik l1hYtKXN1qbT0mWWkrac/h+sJHZEHWbPxnkt1vTT+urx3TRJDaIyzr26pcgaCt1Q9Q4P s5NpKp0GjBpv9B9llFtGUpo/I7/2Ym5JCPKAQLsqD68/Qt06GtCjwKIFzhYtE0mJ1Fcc a1cTXM6xStmsiIjWj3tdnDBwokgIQrOSBkOZJiEwcLDzBwbHmrWSxv6soStBhq7esy7c 6lQhzVxai26uPQqTBP6CDKf6tXMuNT6sWrQ8PoD/JUMWyKy6MtpiQWtpAnafKHgzbHCg MdgA== 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:content-transfer-encoding; bh=wVkzFb2iiXAmBr9IBejcOCjg9GYbzWkKbMHkxQ2Y1VQ=; b=tKj4x8C59gqxgOFgNHSrT6XZvjLjv2yJJL/3DXAFcJaxTEX9/7RasULxwirTxs0ld3 1hAnqq8epHa3TkE2gv+r4SM8IUw3Pk8jn3qXWurWLLLgBw0OVFmzIh0xfgCstip8D+uw 4ER0CnV/8F/epWsQCalmeb9CkLWQDIYGYmW/oyAG1xQOGR+WtgrqonrKMo61sh39Tgf5 9SN3V6tr6zDQ/2Ac0WXW8wlkH3ezeJ+qSleLRLQ/vab/jFKyDSBGEzBFbBH4orcJ5xVK cuFd2dK3p2ysSM/arqvzPujljz3gJgX+vkBKumfTlEbLVmM4vD9awoXcFnirNyMVw1uK 0Bpg== X-Gm-Message-State: AKGB3mKjNIKm1OX08FeOKqkKfMx8yzFz19YHBVW7xxF72f/vqLLRwTWN dvJkupDLBz863j0tEm5HLJe9tytXwN175MlJ/po= X-Google-Smtp-Source: ACJfBouxXA1ApuaKf+8zT32KCVrxZqaRo/o5iZ1ySVlcpsxXOC9V9DsTFe7qyOBCQYI0lnE0Mh92+4q0HVCh2GjKZlo= X-Received: by 10.159.197.5 with SMTP id bj5mr46503071plb.219.1514912200326; Tue, 02 Jan 2018 08:56:40 -0800 (PST) MIME-Version: 1.0 Received: by 10.100.186.208 with HTTP; Tue, 2 Jan 2018 08:55:59 -0800 (PST) In-Reply-To: <0bed01d383e9$fe2543b0$fa6fcb10$@jpshallow.com> References: <0a1201d38161$299ef350$7cdcd9f0$@jpshallow.com> <0b2301d383ad$a8822a40$f9867ec0$@jpshallow.com> <0b4b01d383b0$758f1370$60ad3a50$@jpshallow.com> <0bed01d383e9$fe2543b0$fa6fcb10$@jpshallow.com> From: Kathleen Moriarty Date: Tue, 2 Jan 2018 11:55:59 -0500 Message-ID: To: Jon Shallow Cc: "Konda, Tirumaleswar Reddy" , dots@ietf.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Dots] Using SNI 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, 02 Jan 2018 16:56:43 -0000 Hi Jon, Thanks for the detailed explanation of your usage. Best, Kathleen On Tue, Jan 2, 2018 at 11:51 AM, Jon Shallow wr= ote: > Hi Kathleen. > > Thanks for keeping a watch out for things like this. > > However, the use of SNI would be on a hop by hop basis - a DOTS client wo= uld be talking directly to the next hop DOTS server by resolving its FQDN = and using server_name extension in the client_hello - the connection termin= ating on the DOTS server. If the DOTS server was a part of a DOTS gateway,= then the new connection from the DOTS gateway to the next DOTS server woul= d be using a different FQDN so I do not think we will have an issue here. > > Regards > > Jon > > -----Original Message----- > From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of Kathleen Moriarty > Sent: 02 January 2018 16:29 > To: Jon Shallow > Cc: Konda, Tirumaleswar Reddy; dots@ietf.org > Subject: Re: [Dots] Using SNI > > Hello, > > You might want to discuss your use of SNI on the TLS mailing list after r= eviewing this adopted draft: > https://tools.ietf.org/html/draft-ietf-tls-sni-encryption-00 > > It'll just be an option in TLS 1.3, but will prevent your use of SNI as a= middlebox if/when implemented. > > Best regards, > Kathleen > > On Tue, Jan 2, 2018 at 5:00 AM, Jon Shallow w= rote: >> Hi Tiru, >> >> >> >> That certainly works for me =E2=80=93 thanks >> >> >> >> Regards >> >> >> >> Jon >> >> >> >> From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of Konda, >> Tirumaleswar Reddy >> Sent: 02 January 2018 09:55 >> >> >> To: Jon Shallow; dots@ietf.org >> Subject: Re: [Dots] Using SNI >> >> >> >> Hi Jon, >> >> >> >> RESTCONF does not mandate client authentication based on TLS client >> certificate, we can say the following instead: >> >> If TLS client certificate is used to authenticate the DOTS client, the >> DOTS client MUST include the DOTS server FQDN in server name >> indication extension (Section 3 of RFC6066). >> >> >> >> Cheers, >> >> -Tiru >> >> >> >> From: Jon Shallow [mailto:supjps-ietf@jpshallow.com] >> Sent: Tuesday, January 2, 2018 3:10 PM >> To: Konda, Tirumaleswar Reddy ; >> dots@ietf.org >> Subject: RE: [Dots] Using SNI >> >> >> >> Hi Tiru, >> >> >> >> I agree that (indirectly through RFC7525 reference) SNI is mandated to >> be supported (but not necessarily has to be used). >> >> >> >> However, to guarantee interoperability between different DOTS vendors, >> I am saying that the use of SNI is a MUST =E2=80=93 in particular for th= e data channel. >> >> >> >> Regards >> >> >> >> Jon >> >> >> >> From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of Konda, >> Tirumaleswar Reddy >> Sent: 02 January 2018 08:48 >> To: Jon Shallow; dots@ietf.org >> Subject: Re: [Dots] Using SNI >> >> >> >> Hi Jon, >> >> >> >> Both signal and data channel drafts refer to RFC7525 for secure use of >> (D)TLS and RFC7525 mandates TLS implementations to support SNI. I >> don=E2=80=99t see the need to explicitly discuss SNI in these drafts. >> >> >> Regards, >> >> -Tiru >> >> >> >> From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Jon Shallow >> Sent: Saturday, December 30, 2017 4:57 PM >> To: dots@ietf.org >> Subject: [Dots] Using SNI >> >> >> >> Hi WG, >> >> >> >> When providing a DOTS server data channel service in my environment, >> this shares the same ip / port which also provides other services >> (e.g. GUI / REST server etc.). Even if the Root Discovery points to >> another IP and or port for the actual data channel activity, the TLS >> exchanges for the Root Discovery have to correctly work. I suspect >> that I am not the only DOTS vendor who will have this type of >> requirement of a single IP providing multiple TLS services. >> >> >> >> As DOTS requires mutual authentication, this is a different security >> requirement than required by the GUI environment (DOTS requires client >> cert to be presented, GUI does not and providing certificates to every >> GUI client is not a practical option). >> >> >> >> This can be handled by using SNI by using 2 different FQDNs and >> requiring the DOTS client to include the DOTS specific FQDN in the TLS C= lient Hello. >> Whether the GUI client does or does not (likely does with modern >> browsers) include a SNI FQDN when connecting to the non DOTS FQDN does >> not really matter =E2=80=93 for DOTS it is recognizing the DOTS specific= FQDN >> and setting up the TLS as appropriate. >> >> >> >> To make sure interoperability between DOTS vendors, I would like to >> see something like added to the data channel spec =E2=80=9CDOTS clients = MUST >> include the DOTS server FQDN in the TLS Client Hello packet by using >> Server Name Indication (SNI) RFC 3546=E2=80=9D. >> >> >> >> In addition, I think that this would be a good idea as well for the >> signal draft =E2=80=93 thereby giving DOTS vendors the opportunity to ho= st >> multiple DOTS servers (likely to be different security requirements >> for their different >> client) on a single IP / port. >> >> >> >> Thoughts / comments? >> >> >> >> Regards >> >> >> >> Jon >> >> >> _______________________________________________ >> Dots mailing list >> Dots@ietf.org >> https://www.ietf.org/mailman/listinfo/dots >> > > > > -- > > Best regards, > Kathleen > > _______________________________________________ > Dots mailing list > Dots@ietf.org > https://www.ietf.org/mailman/listinfo/dots > --=20 Best regards, Kathleen From nobody Tue Jan 2 09:19:27 2018 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 9623812D77B for ; Tue, 2 Jan 2018 09:19:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 fnUGSePoZp8U for ; Tue, 2 Jan 2018 09:19: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 19986124239 for ; Tue, 2 Jan 2018 09:19: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 1eWQDY-0006ve-JR for ietf-supjps-dots@ietf.org; Tue, 02 Jan 2018 17:19:12 +0000 From: "Jon Shallow" To: Date: Tue, 2 Jan 2018 17:19:10 -0000 Message-ID: <0bf201d383ed$cdf63970$69e2ac50$@jpshallow.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0BF3_01D383ED.CDF63970" X-Mailer: Microsoft Outlook 14.0 Content-Language: en-gb Thread-Index: AdOD7c3U3eTi3IQ0SPSETf2VuKuPkw== Archived-At: Subject: [Dots] Mutual Authentication between DOTS peers 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, 02 Jan 2018 17:19:15 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0BF3_01D383ED.CDF63970 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi WG, Mutual Authentication is required between 2 DOTS peers, but then the drafts do not make any suggestions that I have found as to how to do it other than referring to EST. I want to make sure we have a set of alternatives in place as a minimum requirement for DOTS vendor interoperability. What I am planning to put into place (be more enforcing) in my DOTS implementation - comments welcome as well as additional suggestions. PKI Client and Server Certificates have to be signed by the same CA. The CA does not need to get exchanged during (D)TLS session set up. The CA does not need to go back to a well-known root CA. PSK The DOTS client 'identity' (potentially FQDN of client) is used for validating the client by the server, and the DOTS server 'identity-hint' (potentially FQDN of server) is used by the client for validating the server. Obviously they both share the same PSK! RPK Nothing in place so far as I have not worked out how to get OpenSSL to do this for me so far, so have no suggestions here. Regards Jon ------=_NextPart_000_0BF3_01D383ED.CDF63970 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi = WG,

 

Mutual Authentication is required between 2 DOTS = peers, but then the drafts do not make any suggestions that I have found = as to how to do it other than referring to EST.

 

I want to = make sure we have a set of alternatives in place as a minimum = requirement for DOTS vendor interoperability.

 

What I am = planning to put into place (be more enforcing) in my DOTS implementation = – comments welcome as well as additional = suggestions.

 

PKI

 

Client and = Server Certificates have to be signed by the same CA.  The CA does = not need to get exchanged during (D)TLS session set up.  The CA = does not need to go back to a well-known root CA.

 

PSK

 

The DOTS = client ‘identity’ (potentially FQDN of client) is used for = validating the client by the server, and the DOTS server = ‘identity-hint’ (potentially FQDN of server) is used by the = client for validating the server.  Obviously they both share the = same PSK!

 

RPK

 

Nothing in = place so far as I have not worked out how to get OpenSSL to do this for = me so far, so have no suggestions here.

 

 

Regards

 

Jon

------=_NextPart_000_0BF3_01D383ED.CDF63970-- From nobody Tue Jan 2 11:01:17 2018 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 274361267BB for ; Tue, 2 Jan 2018 11:01:15 -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 4ufXtXQ1OV9F for ; Tue, 2 Jan 2018 11:01:12 -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 C30361200F3 for ; Tue, 2 Jan 2018 11:01:11 -0800 (PST) Received: from pps.filterd (m0072399.ppops.net [127.0.0.1]) by mx0b-00196b01.pphosted.com (8.16.0.21/8.16.0.21) with SMTP id w02IuVTC031962; Tue, 2 Jan 2018 14:01:07 -0500 Received: from nam02-sn1-obe.outbound.protection.outlook.com (mail-sn1nam02lp0023.outbound.protection.outlook.com [216.32.180.23]) by mx0b-00196b01.pphosted.com with ESMTP id 2f64x0txy8-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Tue, 02 Jan 2018 14:01:07 -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=kLdGj/hUKKUQbZ/lLTLxbT9ijmzMZgjcPdn1qObnmtM=; b=CYf3X/tJgoYpA9FrSVtqpy97RAsBm2PJ8CxMKppJfGbUPVyobkD/HK5BC8FbgC5ljmymlwjDh93eDU1qn7XVFmMyhJxdnG/Au+cV0jSXuBqTH9UBuMaeMCCzCOp9NueS6iDoBS0c9zUbdlzpKJfEG0LFM/MXmh55kDWrCeMaEns= Received: from CO2PR01MB1989.prod.exchangelabs.com (10.166.90.142) by CO2PR01MB1991.prod.exchangelabs.com (10.166.90.144) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.366.8; Tue, 2 Jan 2018 19:01:04 +0000 Received: from CO2PR01MB1989.prod.exchangelabs.com ([10.166.90.142]) by CO2PR01MB1989.prod.exchangelabs.com ([10.166.90.142]) with mapi id 15.20.0366.007; Tue, 2 Jan 2018 19:01:04 +0000 From: "Mortensen, Andrew" To: Jon Shallow CC: Roman Danyliw , "dots@ietf.org" Thread-Topic: [Dots] REMINDER -- WGLC on DOTS Requirements Thread-Index: AdODyALhnnAGTGsSQxOgc1tiV4V/lwAB6auAAAsX3YA= Date: Tue, 2 Jan 2018 19:01:04 +0000 Message-ID: <37171F06-94DE-44E7-8548-7ADD4B919AA6@arbor.net> References: <359EC4B99E040048A7131E0F4E113AFC0131355A04@marathon> <0baf01d383cf$a9cefd20$fd6cf760$@jpshallow.com> In-Reply-To: <0baf01d383cf$a9cefd20$fd6cf760$@jpshallow.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [216.130.192.4] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; CO2PR01MB1991; 7:KUbrhvx4RqHcBAsHELjnVI5LJos4RS4y/kBo3aCamI+pIiUF4xPSqcAViaNngKoF53mCFbXdx7WEgG5qC0laYYqkjMq12i8/MWqY9X8lB7YjdaaVmWFXIgLQPZb97tkbRO6FsyZBAH93pFNT63TU8epDiuEb1U+uMaj0cUfc7inpSwocU4QzLm4HPeBl4UaKPu1SvpkFckn+0g2mnX6Ob8p5d5CqewecpF4Ipd/jnM2+NFWROu3798OIVkshEoVz x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 8e2c79ac-725d-4a08-d81b-08d552132c56 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(5600026)(4604075)(3008032)(2017052603307)(7153060); SRVR:CO2PR01MB1991; x-ms-traffictypediagnostic: CO2PR01MB1991: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(10436049006162); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040470)(2401047)(8121501046)(5005006)(3002001)(10201501046)(93006095)(93001095)(3231023)(944501075)(6041268)(20161123562045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(20161123564045)(20161123558120)(6072148)(201708071742011); SRVR:CO2PR01MB1991; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:CO2PR01MB1991; x-forefront-prvs: 0540846A1D x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39380400002)(376002)(39850400004)(346002)(366004)(396003)(189003)(199004)(57704003)(12213003)(24454002)(13464003)(76176011)(33656002)(3280700002)(575784001)(6246003)(86362001)(106356001)(478600001)(606006)(14454004)(25786009)(7736002)(229853002)(66066001)(97736004)(105586002)(81166006)(102836004)(6116002)(6512007)(53546011)(236005)(54906003)(59450400001)(4326008)(36756003)(6436002)(81156014)(8936002)(2950100002)(3660700001)(6916009)(8676002)(6306002)(966005)(99286004)(53946003)(82746002)(68736007)(5660300001)(6506007)(3846002)(316002)(53936002)(2906002)(6486002)(83716003)(54896002)(2900100001)(77096006)(579004); DIR:OUT; SFP:1102; SCL:1; SRVR:CO2PR01MB1991; H:CO2PR01MB1989.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) x-microsoft-antispam-message-info: cM9bLZWihhcBle+fn0bkBXon9MBycIDUmHuod0KOeHgYzzhL6e21a+xJY98OE4y9ZBXVkv3ACXX3NC+6FHZBLA== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_37171F0694DE44E785487ADD4B919AA6arbornet_" MIME-Version: 1.0 X-OriginatorOrg: arbor.net X-MS-Exchange-CrossTenant-Network-Message-Id: 8e2c79ac-725d-4a08-d81b-08d552132c56 X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Jan 2018 19:01:04.3444 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 54f11205-d4aa-4809-bd36-0b542199c5b2 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO2PR01MB1991 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-01-02_14:, , 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 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1801020268 Archived-At: Subject: Re: [Dots] REMINDER -- WGLC on DOTS 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: Tue, 02 Jan 2018 19:01:15 -0000 --_000_37171F0694DE44E785487ADD4B919AA6arbornet_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQpPbiBKYW4gMiwgMjAxOCwgYXQgODo0MyBBTSwgSm9uIFNoYWxsb3cgPHN1cGpwcy1pZXRmQGpw c2hhbGxvdy5jb208bWFpbHRvOnN1cGpwcy1pZXRmQGpwc2hhbGxvdy5jb20+PiB3cm90ZToNCg0K SGkgUm9tYW4sDQoNCkNvbW1lbnQgIyAxDQoNCkkgc3RpbGwgaGF2ZSBjbGFyaXR5IGlzc3VlcyB3 aXRoIHRoZSB1c2FnZSBvZiB0aGUgdGVybXMgImNsaWVudC1zaWRlIiBhbmQNCiJzZXJ2ZXItc2lk ZSIgd2l0aCByZWZlcmVuY2UgdG8gRE9UUyBnYXRld2F5cyAgVGhleSBhcmUgdXNlZCBib3RoIGFz IGENCnByZWZpeCBhbmQvb3Igc3VmZml4IHRvICdET1RTIGdhdGV3YXlzJywgeWV0IGhhdmUgZGlm ZmVyZW50IG1lYW5pbmcgYmFzZWQgb24NCnBvc2l0aW9uaW5nLiAgV2hhdCBkb2VzICJjbGllbnQt c2lkZSBET1RTIGdhdGV3YXkgc2VydmVyLXNpZGUiIGFjdHVhbGx5DQptZWFuPw0KDQoiY2xpZW50 LXNpZGUgRE9UUyBnYXRld2F5IHNlcnZlci1zaWRlIiBtZWFucyBhcyBJIHVuZGVyc3RhbmQgaXQg IlRoZSAnRE9UUw0KY2xpZW50JyBjb21wb25lbnQgb2YgdGhlIERPVFMgZ2F0ZXdheSB0aGF0IGlz IHNpdHRpbmcgaW4gYSBjbGllbnQgZG9tYWluIiwNCm5vdCAiVGhlICdET1RTIHNlcnZlcicgY29t cG9uZW50IG9mIHRoZSBET1RTIGdhdGV3YXkgdGhhdCBpcyBzaXR0aW5nIGluIGENCmNsaWVudCBk b21haW4iLg0KDQoiY2xpZW50LWRvbWFpbiBET1RTIGdhdGV3YXkgc2VydmVyLWZhY2luZy1zaWRl IiBpcyBhIGxvdCBjbGVhcmVyIHRvIG1lLg0KDQpUaGUgb25seSB0ZXJtaW5vbG9neSBhZmZlY3Rl ZCBpbiB0aGUgcmVxdWlyZW1lbnRzIGRyYWZ0IGlzIHRoZSBmb2xsb3dpbmc6DQoNCiAgICAgIENs aWVudC1zaWRlIERPVFMgZ2F0ZXdheXMgYXJlIERPVFMgZ2F0ZXdheXMgdGhhdCBhcmUgaW4gdGhl IERPVFMNCiAgICAgIGNsaWVudCdzIGRvbWFpbiwgd2hpbGUgIHNlcnZlci1zaWRlIERPVFMgZ2F0 ZXdheXMgZGVub3RlIERPVFMgZ2F0ZXdheXMNCiAgICAgIHRoYXQgYXJlIGluIHRoZSBET1RTIHNl cnZlcidzIGRvbWFpbi4NCg0KSSBoYXZlIGNoYW5nZWQgY2xpZW50LXNpZGUgYW5kIHNlcnZlci1z aWRlIHRvIGNsaWVudC1kb21haW4gYW5kIHNlcnZlci1kb21haW4sIHJlc3BlY3RpdmVseS4gRG8g d2UgbmVlZCB0byBtYWtlIHRoZSBzZXJ2ZXIvY2xpZW50LWZhY2luZy1zaWRlIGRpc3RpbmN0aW9u IGluIHRoZSByZXF1aXJlbWVudHMgZHJhZnQsIG9yIGNhbiB3ZSBhZGRyZXNzIHRoYXQgaW4gdGhl IGFyY2hpdGVjdHVyZSBkcmFmdD8NCg0KDQpDb21tZW50ICMgMg0KDQpXaGlsZSBGaWx0ZXIgaXMg ZGVmaW5lZCwgaXQgZG9lcyBub3QgYXBwZWFyIHRvIGJlIHVzZWQgLyByZXF1aXJlZCwgdW5sZXNz DQpCbGFjay1MaXN0IC8gV2hpdGUtTGlzdCBhcmUgdXNpbmcgRmlsdGVyIG9ubHkgYXMgYSBtZWNo YW5pc20uICBTaG91bGQgdGhlcmUNCmJlIGEgREFUQS0wMDUgZm9yIHRoaXMgYXMgYSByZXF1aXJl bWVudCAoaS5lLiB1c2luZyB0aGUgZmxleGliaWxpdHkgb2YNCm5ldGNvbmYtYWNsPw0KDQpUaGlz IGRvZXNu4oCZdCBzZWVtIHVucmVhc29uYWJsZSB0byBtZSBhcyBsb25nIGFzIHdlIG1ha2UgaXQg Y2xlYXIgdGhhdCwgbGlrZSBCL1cgbGlzdHMsIGZpbHRlcnMgYXJlIG1heSBiZSByZWplY3RlZCBk dWUgdG8gY2FwYWNpdHkgbGltaXRhdGlvbnMgb3IgcG9saWN5IHJlc3RyaWN0aW9ucy4NCg0KYW5k cmV3DQoNCg0KDQoNCg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogRG90cyBb bWFpbHRvOiBkb3RzLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOmRvdHMtYm91bmNlc0BpZXRmLm9y Zz5dIE9uIEJlaGFsZiBPZiBSb21hbiBEYW55bGl3DQpTZW50OiAwMiBKYW51YXJ5IDIwMTggMTI6 NTMNClRvOiBkb3RzQGlldGYub3JnPG1haWx0bzpkb3RzQGlldGYub3JnPg0KU3ViamVjdDogW0Rv dHNdIFJFTUlOREVSIC0tIFdHTEMgb24gRE9UUyBSZXF1aXJlbWVudHMNCg0KSGVsbG8hDQoNCkhh cHB5IE5ldyBZZWFyISAgVGhlIFdHTEMgZm9yIHRoZSBET1RTIHJlcXVpcmVtZW50cyBkcmFmdCB3 aWxsIGJlIGNsb3NpbmcNCnNvb24uICBQbGVhc2UgcHJvdmlkZSBhbnkgZmluYWwgY29tbWVudHMu DQoNClRoYW5rcywNClJvbWFuDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBS b21hbiBEYW55bGl3DQpTZW50OiBUaHVyc2RheSwgRGVjZW1iZXIgNywgMjAxNyAzOjUxIFBNDQpU bzogZG90c0BpZXRmLm9yZzxtYWlsdG86ZG90c0BpZXRmLm9yZz4NClN1YmplY3Q6IFdHTEMgb24g RE9UUyBSZXF1aXJlbWVudHMNCg0KSGVsbG8hDQoNCkNvbnNpc3RlbnQgd2l0aCBvdXIgZGlzY3Vz c2lvbiBhdCB0aGUgU2luZ2Fwb3JlIG1lZXRpbmcgYW5kIHdpdGggdGhlDQpjb25jdXJyZW5jZSBv ZiB0aGUgZHJhZnQgYXV0aG9ycywgd2UgYXJlIHN0YXJ0aW5nIGEgd29ya2luZyBncm91cCBsYXN0 IGNhbGwNCihXR0xDKSBmb3IgdGhlIERPVFMgUmVxdWlyZW1lbnRzIGRyYWZ0Og0KDQpEaXN0cmli dXRlZCBEZW5pYWwgb2YgU2VydmljZSAoRERvUykgT3BlbiBUaHJlYXQgU2lnbmFsaW5nIFJlcXVp cmVtZW50cw0KZHJhZnQtaWV0Zi1kb3RzLXJlcXVpcmVtZW50cy0wOA0KaHR0cHM6Ly91cmxkZWZl bnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTNBX190b29scy5pZXRmLm9yZ19odG1s X2RyYWZ0LTJEaWV0Zi0yRGRvdHMtMkRyZXF1aXJlbWVudHMtMkQwOCZkPUR3SUNBZyZjPUhsdnBy cW9ucjVMdUNOOVRONjV4Tncmcj1NLTBfQ3FFVlhhOU9Rdm1KMmdNdFhBekw2djZKc1pIdHNSa21h Uno0dXJFJm09cVozUmloQWhnSEdib0gtWWZXMUt2VmhIOERFcjlXMUYwSGxQQ0RXOGtYbyZzPU00 eEJuSnV1UmgyY3RnUU5lbzFZb1gxZW1maU50VHVTRzBVeWM2akhreWMmZT0NCg0KUGxlYXNlIHNl bmQgYWxsIGNvbW1lbnRzIHRvIHRoZSBET1RTIG1haWxpbmcgbGlzdC4NCg0KVGhpcyBXR0xDIHdp bGwgZW5kIG9uIEphbnVhcnkgMiwgMjAxOCAofjMgd2Vla3MgdG8gYWNjb3VudCBmb3INCmVuZC1v Zi10aGUtY2FsZW5kYXIgeWVhciB2YWNhdGlvbnMpLg0KDQpUaGFua3MsDQpSb21hbg0KDQpfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KRG90cyBtYWlsaW5n IGxpc3QNCkRvdHNAaWV0Zi5vcmc8bWFpbHRvOkRvdHNAaWV0Zi5vcmc+DQpodHRwczovL3VybGRl ZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtM0FfX3d3dy5pZXRmLm9yZ19tYWls bWFuX2xpc3RpbmZvX2RvdHMmZD1Ed0lDQWcmYz1IbHZwcnFvbnI1THVDTjlUTjY1eE53JnI9TS0w X0NxRVZYYTlPUXZtSjJnTXRYQXpMNnY2SnNaSHRzUmttYVJ6NHVyRSZtPXFaM1JpaEFoZ0hHYm9I LVlmVzFLdlZoSDhERXI5VzFGMEhsUENEVzhrWG8mcz1WTDE3S1BPdHh3aVpaTzIwMld6UUludk1Y UE9HRUtQUG5LZkRYUEh2bmZ3JmU9DQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fDQpEb3RzIG1haWxpbmcgbGlzdA0KRG90c0BpZXRmLm9yZzxtYWlsdG86 RG90c0BpZXRmLm9yZz4NCmh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/ dT1odHRwcy0zQV9fd3d3LmlldGYub3JnX21haWxtYW5fbGlzdGluZm9fZG90cyZkPUR3SUNBZyZj PUhsdnBycW9ucjVMdUNOOVRONjV4Tncmcj1NLTBfQ3FFVlhhOU9Rdm1KMmdNdFhBekw2djZKc1pI dHNSa21hUno0dXJFJm09cVozUmloQWhnSEdib0gtWWZXMUt2VmhIOERFcjlXMUYwSGxQQ0RXOGtY byZzPVZMMTdLUE90eHdpWlpPMjAyV3pRSW52TVhQT0dFS1BQbktmRFhQSHZuZncmZT0NCg0K --_000_37171F0694DE44E785487ADD4B919AA6arbornet_ Content-Type: text/html; charset="utf-8" Content-ID: <81AA234D0B4E3A4895AB931AF0B25A38@prod.exchangelabs.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KPGRpdj4N CjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj5PbiBKYW4g MiwgMjAxOCwgYXQgODo0MyBBTSwgSm9uIFNoYWxsb3cgJmx0OzxhIGhyZWY9Im1haWx0bzpzdXBq cHMtaWV0ZkBqcHNoYWxsb3cuY29tIiBjbGFzcz0iIj5zdXBqcHMtaWV0ZkBqcHNoYWxsb3cuY29t PC9hPiZndDsgd3JvdGU6PC9kaXY+DQo8YnIgY2xhc3M9IkFwcGxlLWludGVyY2hhbmdlLW5ld2xp bmUiPg0KPGRpdiBjbGFzcz0iIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6IEhlbHZldGljYTsg Zm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudC1jYXBzOiBu b3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IHRleHQt YWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hp dGUtc3BhY2U6IG5vcm1hbDsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Ut d2lkdGg6IDBweDsgZmxvYXQ6IG5vbmU7IGRpc3BsYXk6IGlubGluZSAhaW1wb3J0YW50OyIgY2xh c3M9IiI+SGkNCiBSb21hbiw8L3NwYW4+PGJyIHN0eWxlPSJmb250LWZhbWlseTogSGVsdmV0aWNh OyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWNhcHM6 IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgdGV4 dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3 aGl0ZS1zcGFjZTogbm9ybWFsOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9r ZS13aWR0aDogMHB4OyIgY2xhc3M9IiI+DQo8YnIgc3R5bGU9ImZvbnQtZmFtaWx5OiBIZWx2ZXRp Y2E7IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fw czogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyB0 ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7 IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ry b2tlLXdpZHRoOiAwcHg7IiBjbGFzcz0iIj4NCjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTogSGVs dmV0aWNhOyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50 LWNhcHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1h bDsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBu b25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0 LXN0cm9rZS13aWR0aDogMHB4OyBmbG9hdDogbm9uZTsgZGlzcGxheTogaW5saW5lICFpbXBvcnRh bnQ7IiBjbGFzcz0iIj5Db21tZW50DQogIyAxPC9zcGFuPjxiciBzdHlsZT0iZm9udC1mYW1pbHk6 IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFy aWFudC1jYXBzOiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBu b3JtYWw7IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9y bTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQt dGV4dC1zdHJva2Utd2lkdGg6IDBweDsiIGNsYXNzPSIiPg0KPGJyIHN0eWxlPSJmb250LWZhbWls eTogSGVsdmV0aWNhOyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12 YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6 IG5vcm1hbDsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNm b3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtp dC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyIgY2xhc3M9IiI+DQo8c3BhbiBzdHlsZT0iZm9udC1m YW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZv bnQtdmFyaWFudC1jYXBzOiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFj aW5nOiBub3JtYWw7IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRy YW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd29yZC1zcGFjaW5nOiAwcHg7IC13 ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsgZmxvYXQ6IG5vbmU7IGRpc3BsYXk6IGlubGlu ZSAhaW1wb3J0YW50OyIgY2xhc3M9IiI+SQ0KIHN0aWxsIGhhdmUgY2xhcml0eSBpc3N1ZXMgd2l0 aCB0aGUgdXNhZ2Ugb2YgdGhlIHRlcm1zICZxdW90O2NsaWVudC1zaWRlJnF1b3Q7IGFuZDwvc3Bh bj48YnIgc3R5bGU9ImZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsgZm9u dC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsOyBmb250LXdlaWdodDog bm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1p bmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdv cmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IiBjbGFzcz0i Ij4NCjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6IDEycHg7 IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9udC13ZWln aHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgdGV4dC1hbGlnbjogc3RhcnQ7IHRl eHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFs OyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyBmbG9h dDogbm9uZTsgZGlzcGxheTogaW5saW5lICFpbXBvcnRhbnQ7IiBjbGFzcz0iIj4mcXVvdDtzZXJ2 ZXItc2lkZSZxdW90Ow0KIHdpdGggcmVmZXJlbmNlIHRvIERPVFMgZ2F0ZXdheXMgJm5ic3A7VGhl eSBhcmUgdXNlZCBib3RoIGFzIGE8L3NwYW4+PGJyIHN0eWxlPSJmb250LWZhbWlseTogSGVsdmV0 aWNhOyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWNh cHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsg dGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25l OyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0 cm9rZS13aWR0aDogMHB4OyIgY2xhc3M9IiI+DQo8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6IEhl bHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFu dC1jYXBzOiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3Jt YWw7IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTog bm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4 dC1zdHJva2Utd2lkdGg6IDBweDsgZmxvYXQ6IG5vbmU7IGRpc3BsYXk6IGlubGluZSAhaW1wb3J0 YW50OyIgY2xhc3M9IiI+cHJlZml4DQogYW5kL29yIHN1ZmZpeCB0byAnRE9UUyBnYXRld2F5cycs IHlldCBoYXZlIGRpZmZlcmVudCBtZWFuaW5nIGJhc2VkIG9uPC9zcGFuPjxiciBzdHlsZT0iZm9u dC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7 IGZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1z cGFjaW5nOiBub3JtYWw7IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0 LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd29yZC1zcGFjaW5nOiAwcHg7 IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsiIGNsYXNzPSIiPg0KPHNwYW4gc3R5bGU9 ImZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9y bWFsOyBmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0 ZXItc3BhY2luZzogbm9ybWFsOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsg dGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdvcmQtc3BhY2luZzog MHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IGZsb2F0OiBub25lOyBkaXNwbGF5 OiBpbmxpbmUgIWltcG9ydGFudDsiIGNsYXNzPSIiPnBvc2l0aW9uaW5nLg0KICZuYnNwO1doYXQg ZG9lcyAmcXVvdDtjbGllbnQtc2lkZSBET1RTIGdhdGV3YXkgc2VydmVyLXNpZGUmcXVvdDsgYWN0 dWFsbHk8L3NwYW4+PGJyIHN0eWxlPSJmb250LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6 IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9u dC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgdGV4dC1hbGlnbjogc3Rh cnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTog bm9ybWFsOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4 OyIgY2xhc3M9IiI+DQo8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1z aXplOiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7 IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IHRleHQtYWxpZ246 IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3Bh Y2U6IG5vcm1hbDsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6 IDBweDsgZmxvYXQ6IG5vbmU7IGRpc3BsYXk6IGlubGluZSAhaW1wb3J0YW50OyIgY2xhc3M9IiI+ bWVhbj88L3NwYW4+PGJyIHN0eWxlPSJmb250LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6 IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9u dC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgdGV4dC1hbGlnbjogc3Rh cnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTog bm9ybWFsOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4 OyIgY2xhc3M9IiI+DQo8YnIgc3R5bGU9ImZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6 ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsOyBm b250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyB0ZXh0LWFsaWduOiBz dGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNl OiBub3JtYWw7IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAw cHg7IiBjbGFzcz0iIj4NCjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTogSGVsdmV0aWNhOyBmb250 LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWNhcHM6IG5vcm1h bDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgdGV4dC1hbGln bjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1z cGFjZTogbm9ybWFsOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0 aDogMHB4OyBmbG9hdDogbm9uZTsgZGlzcGxheTogaW5saW5lICFpbXBvcnRhbnQ7IiBjbGFzcz0i Ij4mcXVvdDtjbGllbnQtc2lkZQ0KIERPVFMgZ2F0ZXdheSBzZXJ2ZXItc2lkZSZxdW90OyBtZWFu cyBhcyBJIHVuZGVyc3RhbmQgaXQgJnF1b3Q7VGhlICdET1RTPC9zcGFuPjxiciBzdHlsZT0iZm9u dC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7 IGZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1z cGFjaW5nOiBub3JtYWw7IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0 LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd29yZC1zcGFjaW5nOiAwcHg7 IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsiIGNsYXNzPSIiPg0KPHNwYW4gc3R5bGU9 ImZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9y bWFsOyBmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0 ZXItc3BhY2luZzogbm9ybWFsOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsg dGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdvcmQtc3BhY2luZzog MHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IGZsb2F0OiBub25lOyBkaXNwbGF5 OiBpbmxpbmUgIWltcG9ydGFudDsiIGNsYXNzPSIiPmNsaWVudCcNCiBjb21wb25lbnQgb2YgdGhl IERPVFMgZ2F0ZXdheSB0aGF0IGlzIHNpdHRpbmcgaW4gYSBjbGllbnQgZG9tYWluJnF1b3Q7LDwv c3Bhbj48YnIgc3R5bGU9ImZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsg Zm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsOyBmb250LXdlaWdo dDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4 dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7 IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IiBjbGFz cz0iIj4NCjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6IDEy cHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9udC13 ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgdGV4dC1hbGlnbjogc3RhcnQ7 IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9y bWFsOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyBm bG9hdDogbm9uZTsgZGlzcGxheTogaW5saW5lICFpbXBvcnRhbnQ7IiBjbGFzcz0iIj5ub3QNCiAm cXVvdDtUaGUgJ0RPVFMgc2VydmVyJyBjb21wb25lbnQgb2YgdGhlIERPVFMgZ2F0ZXdheSB0aGF0 IGlzIHNpdHRpbmcgaW4gYTwvc3Bhbj48YnIgc3R5bGU9ImZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7 IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fwczog bm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyB0ZXh0 LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdo aXRlLXNwYWNlOiBub3JtYWw7IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tl LXdpZHRoOiAwcHg7IiBjbGFzcz0iIj4NCjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTogSGVsdmV0 aWNhOyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWNh cHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsg dGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25l OyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0 cm9rZS13aWR0aDogMHB4OyBmbG9hdDogbm9uZTsgZGlzcGxheTogaW5saW5lICFpbXBvcnRhbnQ7 IiBjbGFzcz0iIj5jbGllbnQNCiBkb21haW4mcXVvdDsuPC9zcGFuPjxiciBzdHlsZT0iZm9udC1m YW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZv bnQtdmFyaWFudC1jYXBzOiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFj aW5nOiBub3JtYWw7IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRy YW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd29yZC1zcGFjaW5nOiAwcHg7IC13 ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsiIGNsYXNzPSIiPg0KPGJyIHN0eWxlPSJmb250 LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsg Zm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNw YWNpbmc6IG5vcm1hbDsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQt dHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3b3JkLXNwYWNpbmc6IDBweDsg LXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyIgY2xhc3M9IiI+DQo8c3BhbiBzdHlsZT0i Zm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBub3Jt YWw7IGZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRl ci1zcGFjaW5nOiBub3JtYWw7IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0 ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd29yZC1zcGFjaW5nOiAw cHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsgZmxvYXQ6IG5vbmU7IGRpc3BsYXk6 IGlubGluZSAhaW1wb3J0YW50OyIgY2xhc3M9IiI+JnF1b3Q7Y2xpZW50LWRvbWFpbg0KIERPVFMg Z2F0ZXdheSBzZXJ2ZXItZmFjaW5nLXNpZGUmcXVvdDsgaXMgYSBsb3QgY2xlYXJlciB0byBtZS48 L3NwYW4+PGJyIHN0eWxlPSJmb250LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6IDEycHg7 IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9udC13ZWln aHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgdGV4dC1hbGlnbjogc3RhcnQ7IHRl eHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFs OyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyIgY2xh c3M9IiI+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+PGJyIGNsYXNzPSIiPg0KPC9kaXY+ DQo8ZGl2PlRoZSBvbmx5IHRlcm1pbm9sb2d5IGFmZmVjdGVkIGluIHRoZSByZXF1aXJlbWVudHMg ZHJhZnQgaXMgdGhlIGZvbGxvd2luZzo8L2Rpdj4NCjxkaXY+PGJyIGNsYXNzPSIiPg0KPC9kaXY+ DQo8ZGl2Pg0KPGRpdiBjbGFzcz0iIj4mbmJzcDsgJm5ic3A7ICZuYnNwOyBDbGllbnQtc2lkZSBE T1RTIGdhdGV3YXlzIGFyZSBET1RTIGdhdGV3YXlzIHRoYXQgYXJlIGluIHRoZSBET1RTPC9kaXY+ DQo8ZGl2IGNsYXNzPSIiPiZuYnNwOyAmbmJzcDsgJm5ic3A7IGNsaWVudCdzIGRvbWFpbiwgd2hp bGUgJm5ic3A7c2VydmVyLXNpZGUgRE9UUyBnYXRld2F5cyBkZW5vdGUgRE9UUyBnYXRld2F5czwv ZGl2Pg0KPGRpdiBjbGFzcz0iIj4mbmJzcDsgJm5ic3A7ICZuYnNwOyB0aGF0IGFyZSBpbiB0aGUg RE9UUyBzZXJ2ZXIncyBkb21haW4uPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4N CjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5JIGhhdmUgY2hhbmdlZCBjbGllbnQtc2lkZSBhbmQgc2Vy dmVyLXNpZGUgdG8gY2xpZW50LWRvbWFpbiBhbmQgc2VydmVyLWRvbWFpbiwgcmVzcGVjdGl2ZWx5 LiBEbyB3ZSBuZWVkIHRvIG1ha2UgdGhlIHNlcnZlci9jbGllbnQtZmFjaW5nLXNpZGUgZGlzdGlu Y3Rpb24gaW4gdGhlIHJlcXVpcmVtZW50cyBkcmFmdCwgb3IgY2FuIHdlIGFkZHJlc3MgdGhhdCBp biB0aGUgYXJjaGl0ZWN0dXJlIGRyYWZ0PzwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9 IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8L2Rpdj4N CjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj48c3BhbiBz dHlsZT0iZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxl OiBub3JtYWw7IGZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7 IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDog MHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd29yZC1zcGFj aW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsgZmxvYXQ6IG5vbmU7IGRp c3BsYXk6IGlubGluZSAhaW1wb3J0YW50OyIgY2xhc3M9IiI+Q29tbWVudA0KICMgMjwvc3Bhbj48 YnIgc3R5bGU9ImZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsgZm9udC1z dHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsOyBmb250LXdlaWdodDogbm9y bWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRl bnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdvcmQt c3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IiBjbGFzcz0iIj4N CjxiciBzdHlsZT0iZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250 LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBu b3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWlu ZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd29y ZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsiIGNsYXNzPSIi Pg0KPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsg Zm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsOyBmb250LXdlaWdo dDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4 dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7 IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IGZsb2F0 OiBub25lOyBkaXNwbGF5OiBpbmxpbmUgIWltcG9ydGFudDsiIGNsYXNzPSIiPldoaWxlDQogRmls dGVyIGlzIGRlZmluZWQsIGl0IGRvZXMgbm90IGFwcGVhciB0byBiZSB1c2VkIC8gcmVxdWlyZWQs IHVubGVzczwvc3Bhbj48YnIgc3R5bGU9ImZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6 ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsOyBm b250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyB0ZXh0LWFsaWduOiBz dGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNl OiBub3JtYWw7IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAw cHg7IiBjbGFzcz0iIj4NCjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTogSGVsdmV0aWNhOyBmb250 LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWNhcHM6IG5vcm1h bDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgdGV4dC1hbGln bjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1z cGFjZTogbm9ybWFsOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0 aDogMHB4OyBmbG9hdDogbm9uZTsgZGlzcGxheTogaW5saW5lICFpbXBvcnRhbnQ7IiBjbGFzcz0i Ij5CbGFjay1MaXN0DQogLyBXaGl0ZS1MaXN0IGFyZSB1c2luZyBGaWx0ZXIgb25seSBhcyBhIG1l Y2hhbmlzbS4gJm5ic3A7U2hvdWxkIHRoZXJlPC9zcGFuPjxiciBzdHlsZT0iZm9udC1mYW1pbHk6 IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFy aWFudC1jYXBzOiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBu b3JtYWw7IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9y bTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQt dGV4dC1zdHJva2Utd2lkdGg6IDBweDsiIGNsYXNzPSIiPg0KPHNwYW4gc3R5bGU9ImZvbnQtZmFt aWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250 LXZhcmlhbnQtY2Fwczogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2lu Zzogbm9ybWFsOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFu c2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdvcmQtc3BhY2luZzogMHB4OyAtd2Vi a2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IGZsb2F0OiBub25lOyBkaXNwbGF5OiBpbmxpbmUg IWltcG9ydGFudDsiIGNsYXNzPSIiPmJlDQogYSBEQVRBLTAwNSBmb3IgdGhpcyBhcyBhIHJlcXVp cmVtZW50IChpLmUuIHVzaW5nIHRoZSBmbGV4aWJpbGl0eSBvZjwvc3Bhbj48YnIgc3R5bGU9ImZv bnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFs OyBmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXIt c3BhY2luZzogbm9ybWFsOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4 dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdvcmQtc3BhY2luZzogMHB4 OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IiBjbGFzcz0iIj4NCjxzcGFuIHN0eWxl PSJmb250LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5v cm1hbDsgZm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0 dGVyLXNwYWNpbmc6IG5vcm1hbDsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7 IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3b3JkLXNwYWNpbmc6 IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyBmbG9hdDogbm9uZTsgZGlzcGxh eTogaW5saW5lICFpbXBvcnRhbnQ7IiBjbGFzcz0iIj5uZXRjb25mLWFjbD88L3NwYW4+PGJyIHN0 eWxlPSJmb250LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6 IG5vcm1hbDsgZm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsg bGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAw cHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3b3JkLXNwYWNp bmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyIgY2xhc3M9IiI+DQo8L2Rp dj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2PlRoaXMg ZG9lc27igJl0IHNlZW0gdW5yZWFzb25hYmxlIHRvIG1lIGFzIGxvbmcgYXMgd2UgbWFrZSBpdCBj bGVhciB0aGF0LCBsaWtlIEIvVyBsaXN0cywgZmlsdGVycyBhcmUgbWF5IGJlIHJlamVjdGVkIGR1 ZSB0byBjYXBhY2l0eSBsaW1pdGF0aW9ucyBvciBwb2xpY3kgcmVzdHJpY3Rpb25zLjwvZGl2Pg0K PGRpdj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXY+YW5kcmV3PC9kaXY+DQo8ZGl2PjxiciBj bGFzcz0iIj4NCjwvZGl2Pg0KPGRpdj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXY+PGJyIGNs YXNzPSIiPg0KPC9kaXY+DQo8ZGl2PjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGJyIGNsYXNzPSIi Pg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPjxiciBz dHlsZT0iZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxl OiBub3JtYWw7IGZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7 IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDog MHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd29yZC1zcGFj aW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsiIGNsYXNzPSIiPg0KPHNw YW4gc3R5bGU9ImZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsgZm9udC1z dHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsOyBmb250LXdlaWdodDogbm9y bWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRl bnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdvcmQt c3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IGZsb2F0OiBub25l OyBkaXNwbGF5OiBpbmxpbmUgIWltcG9ydGFudDsiIGNsYXNzPSIiPi0tLS0tT3JpZ2luYWwNCiBN ZXNzYWdlLS0tLS08L3NwYW4+PGJyIHN0eWxlPSJmb250LWZhbWlseTogSGVsdmV0aWNhOyBmb250 LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWNhcHM6IG5vcm1h bDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgdGV4dC1hbGln bjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1z cGFjZTogbm9ybWFsOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0 aDogMHB4OyIgY2xhc3M9IiI+DQo8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6IEhlbHZldGljYTsg Zm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudC1jYXBzOiBu b3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IHRleHQt YWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hp dGUtc3BhY2U6IG5vcm1hbDsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Ut d2lkdGg6IDBweDsgZmxvYXQ6IG5vbmU7IGRpc3BsYXk6IGlubGluZSAhaW1wb3J0YW50OyIgY2xh c3M9IiI+RnJvbToNCiBEb3RzIFttYWlsdG86PHNwYW4gY2xhc3M9IkFwcGxlLWNvbnZlcnRlZC1z cGFjZSI+Jm5ic3A7PC9zcGFuPjwvc3Bhbj48YSBocmVmPSJtYWlsdG86ZG90cy1ib3VuY2VzQGll dGYub3JnIiBzdHlsZT0iZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBm b250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7IGZvbnQtd2VpZ2h0 OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IG9ycGhhbnM6IGF1dG87IHRleHQtYWxp Z246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUt c3BhY2U6IG5vcm1hbDsgd2lkb3dzOiBhdXRvOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10 ZXh0LXNpemUtYWRqdXN0OiBhdXRvOyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IiBj bGFzcz0iIj5kb3RzLWJvdW5jZXNAaWV0Zi5vcmc8L2E+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5 OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZh cmlhbnQtY2Fwczogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzog bm9ybWFsOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zv cm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0 LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IGZsb2F0OiBub25lOyBkaXNwbGF5OiBpbmxpbmUgIWlt cG9ydGFudDsiIGNsYXNzPSIiPl0NCiBPbiBCZWhhbGYgT2YgUm9tYW4gRGFueWxpdzwvc3Bhbj48 YnIgc3R5bGU9ImZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsgZm9udC1z dHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsOyBmb250LXdlaWdodDogbm9y bWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRl bnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdvcmQt c3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IiBjbGFzcz0iIj4N CjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6IDEycHg7IGZv bnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6 IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQt aW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3 b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyBmbG9hdDog bm9uZTsgZGlzcGxheTogaW5saW5lICFpbXBvcnRhbnQ7IiBjbGFzcz0iIj5TZW50Og0KIDAyIEph bnVhcnkgMjAxOCAxMjo1Mzwvc3Bhbj48YnIgc3R5bGU9ImZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7 IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fwczog bm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyB0ZXh0 LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdo aXRlLXNwYWNlOiBub3JtYWw7IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tl LXdpZHRoOiAwcHg7IiBjbGFzcz0iIj4NCjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTogSGVsdmV0 aWNhOyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWNh cHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsg dGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25l OyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0 cm9rZS13aWR0aDogMHB4OyBmbG9hdDogbm9uZTsgZGlzcGxheTogaW5saW5lICFpbXBvcnRhbnQ7 IiBjbGFzcz0iIj5Ubzo8c3BhbiBjbGFzcz0iQXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8 L3NwYW4+PC9zcGFuPjxhIGhyZWY9Im1haWx0bzpkb3RzQGlldGYub3JnIiBzdHlsZT0iZm9udC1m YW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZv bnQtdmFyaWFudC1jYXBzOiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFj aW5nOiBub3JtYWw7IG9ycGhhbnM6IGF1dG87IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVu dDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd2lkb3dz OiBhdXRvOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXNpemUtYWRqdXN0OiBhdXRv OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IiBjbGFzcz0iIj5kb3RzQGlldGYub3Jn PC9hPjxiciBzdHlsZT0iZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBm b250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7IGZvbnQtd2VpZ2h0 OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0 LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsg d29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsiIGNsYXNz PSIiPg0KPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJw eDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsOyBmb250LXdl aWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyB0ZXh0LWFsaWduOiBzdGFydDsg dGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3Jt YWw7IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IGZs b2F0OiBub25lOyBkaXNwbGF5OiBpbmxpbmUgIWltcG9ydGFudDsiIGNsYXNzPSIiPlN1YmplY3Q6 DQogW0RvdHNdIFJFTUlOREVSIC0tIFdHTEMgb24gRE9UUyBSZXF1aXJlbWVudHM8L3NwYW4+PGJy IHN0eWxlPSJmb250LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5 bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1h bDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50 OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3b3JkLXNw YWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyIgY2xhc3M9IiI+DQo8 YnIgc3R5bGU9ImZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsgZm9udC1z dHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsOyBmb250LXdlaWdodDogbm9y bWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRl bnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdvcmQt c3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IiBjbGFzcz0iIj4N CjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6IDEycHg7IGZv bnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6 IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQt aW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3 b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyBmbG9hdDog bm9uZTsgZGlzcGxheTogaW5saW5lICFpbXBvcnRhbnQ7IiBjbGFzcz0iIj5IZWxsbyE8L3NwYW4+ PGJyIHN0eWxlPSJmb250LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6IDEycHg7IGZvbnQt c3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5v cm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5k ZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3b3Jk LXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyIgY2xhc3M9IiI+ DQo8YnIgc3R5bGU9ImZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsgZm9u dC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsOyBmb250LXdlaWdodDog bm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1p bmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdv cmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IiBjbGFzcz0i Ij4NCjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6IDEycHg7 IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9udC13ZWln aHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgdGV4dC1hbGlnbjogc3RhcnQ7IHRl eHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFs OyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyBmbG9h dDogbm9uZTsgZGlzcGxheTogaW5saW5lICFpbXBvcnRhbnQ7IiBjbGFzcz0iIj5IYXBweQ0KIE5l dyBZZWFyISAmbmJzcDtUaGUgV0dMQyBmb3IgdGhlIERPVFMgcmVxdWlyZW1lbnRzIGRyYWZ0IHdp bGwgYmUgY2xvc2luZzwvc3Bhbj48YnIgc3R5bGU9ImZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZv bnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fwczogbm9y bWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyB0ZXh0LWFs aWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRl LXNwYWNlOiBub3JtYWw7IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdp ZHRoOiAwcHg7IiBjbGFzcz0iIj4NCjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTogSGVsdmV0aWNh OyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWNhcHM6 IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgdGV4 dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3 aGl0ZS1zcGFjZTogbm9ybWFsOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9r ZS13aWR0aDogMHB4OyBmbG9hdDogbm9uZTsgZGlzcGxheTogaW5saW5lICFpbXBvcnRhbnQ7IiBj bGFzcz0iIj5zb29uLg0KICZuYnNwO1BsZWFzZSBwcm92aWRlIGFueSBmaW5hbCBjb21tZW50cy48 L3NwYW4+PGJyIHN0eWxlPSJmb250LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6IDEycHg7 IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9udC13ZWln aHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgdGV4dC1hbGlnbjogc3RhcnQ7IHRl eHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFs OyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyIgY2xh c3M9IiI+DQo8YnIgc3R5bGU9ImZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJw eDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsOyBmb250LXdl aWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyB0ZXh0LWFsaWduOiBzdGFydDsg dGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3Jt YWw7IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IiBj bGFzcz0iIj4NCjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6 IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9u dC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgdGV4dC1hbGlnbjogc3Rh cnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTog bm9ybWFsOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4 OyBmbG9hdDogbm9uZTsgZGlzcGxheTogaW5saW5lICFpbXBvcnRhbnQ7IiBjbGFzcz0iIj5UaGFu a3MsPC9zcGFuPjxiciBzdHlsZT0iZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAx MnB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7IGZvbnQt d2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IHRleHQtYWxpZ246IHN0YXJ0 OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5v cm1hbDsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsi IGNsYXNzPSIiPg0KPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6 ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsOyBm b250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyB0ZXh0LWFsaWduOiBz dGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNl OiBub3JtYWw7IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAw cHg7IGZsb2F0OiBub25lOyBkaXNwbGF5OiBpbmxpbmUgIWltcG9ydGFudDsiIGNsYXNzPSIiPlJv bWFuPC9zcGFuPjxiciBzdHlsZT0iZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAx MnB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7IGZvbnQt d2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IHRleHQtYWxpZ246IHN0YXJ0 OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5v cm1hbDsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsi IGNsYXNzPSIiPg0KPGJyIHN0eWxlPSJmb250LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6 IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9u dC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgdGV4dC1hbGlnbjogc3Rh cnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTog bm9ybWFsOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4 OyIgY2xhc3M9IiI+DQo8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1z aXplOiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7 IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IHRleHQtYWxpZ246 IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3Bh Y2U6IG5vcm1hbDsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6 IDBweDsgZmxvYXQ6IG5vbmU7IGRpc3BsYXk6IGlubGluZSAhaW1wb3J0YW50OyIgY2xhc3M9IiI+ LS0tLS1PcmlnaW5hbA0KIE1lc3NhZ2UtLS0tLTwvc3Bhbj48YnIgc3R5bGU9ImZvbnQtZmFtaWx5 OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZh cmlhbnQtY2Fwczogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzog bm9ybWFsOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zv cm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0 LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IiBjbGFzcz0iIj4NCjxzcGFuIHN0eWxlPSJmb250LWZh bWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9u dC12YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNp bmc6IG5vcm1hbDsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJh bnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdl YmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyBmbG9hdDogbm9uZTsgZGlzcGxheTogaW5saW5l ICFpbXBvcnRhbnQ7IiBjbGFzcz0iIj5Gcm9tOg0KIFJvbWFuIERhbnlsaXc8c3BhbiBjbGFzcz0i QXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PC9zcGFuPjxiciBzdHlsZT0iZm9u dC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7 IGZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1z cGFjaW5nOiBub3JtYWw7IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0 LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd29yZC1zcGFjaW5nOiAwcHg7 IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsiIGNsYXNzPSIiPg0KPHNwYW4gc3R5bGU9 ImZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9y bWFsOyBmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0 ZXItc3BhY2luZzogbm9ybWFsOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsg dGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdvcmQtc3BhY2luZzog MHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IGZsb2F0OiBub25lOyBkaXNwbGF5 OiBpbmxpbmUgIWltcG9ydGFudDsiIGNsYXNzPSIiPlNlbnQ6DQogVGh1cnNkYXksIERlY2VtYmVy IDcsIDIwMTcgMzo1MSBQTTwvc3Bhbj48YnIgc3R5bGU9ImZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7 IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fwczog bm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyB0ZXh0 LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdo aXRlLXNwYWNlOiBub3JtYWw7IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tl LXdpZHRoOiAwcHg7IiBjbGFzcz0iIj4NCjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTogSGVsdmV0 aWNhOyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWNh cHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsg dGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25l OyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0 cm9rZS13aWR0aDogMHB4OyBmbG9hdDogbm9uZTsgZGlzcGxheTogaW5saW5lICFpbXBvcnRhbnQ7 IiBjbGFzcz0iIj5UbzoNCjxhIGhyZWY9Im1haWx0bzpkb3RzQGlldGYub3JnIiBjbGFzcz0iIj5k b3RzQGlldGYub3JnPC9hPjwvc3Bhbj48YnIgc3R5bGU9ImZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7 IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fwczog bm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyB0ZXh0 LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdo aXRlLXNwYWNlOiBub3JtYWw7IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tl LXdpZHRoOiAwcHg7IiBjbGFzcz0iIj4NCjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTogSGVsdmV0 aWNhOyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWNh cHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsg dGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25l OyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0 cm9rZS13aWR0aDogMHB4OyBmbG9hdDogbm9uZTsgZGlzcGxheTogaW5saW5lICFpbXBvcnRhbnQ7 IiBjbGFzcz0iIj5TdWJqZWN0Og0KIFdHTEMgb24gRE9UUyBSZXF1aXJlbWVudHM8L3NwYW4+PGJy IHN0eWxlPSJmb250LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5 bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1h bDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50 OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3b3JkLXNw YWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyIgY2xhc3M9IiI+DQo8 YnIgc3R5bGU9ImZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsgZm9udC1z dHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsOyBmb250LXdlaWdodDogbm9y bWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRl bnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdvcmQt c3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IiBjbGFzcz0iIj4N CjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6IDEycHg7IGZv bnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6 IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQt aW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3 b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyBmbG9hdDog bm9uZTsgZGlzcGxheTogaW5saW5lICFpbXBvcnRhbnQ7IiBjbGFzcz0iIj5IZWxsbyE8L3NwYW4+ PGJyIHN0eWxlPSJmb250LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6IDEycHg7IGZvbnQt c3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5v cm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5k ZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3b3Jk LXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyIgY2xhc3M9IiI+ DQo8YnIgc3R5bGU9ImZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsgZm9u dC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsOyBmb250LXdlaWdodDog bm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1p bmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdv cmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IiBjbGFzcz0i Ij4NCjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6IDEycHg7 IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9udC13ZWln aHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgdGV4dC1hbGlnbjogc3RhcnQ7IHRl eHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFs OyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyBmbG9h dDogbm9uZTsgZGlzcGxheTogaW5saW5lICFpbXBvcnRhbnQ7IiBjbGFzcz0iIj5Db25zaXN0ZW50 DQogd2l0aCBvdXIgZGlzY3Vzc2lvbiBhdCB0aGUgU2luZ2Fwb3JlIG1lZXRpbmcgYW5kIHdpdGgg dGhlPC9zcGFuPjxiciBzdHlsZT0iZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAx MnB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7IGZvbnQt d2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IHRleHQtYWxpZ246IHN0YXJ0 OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5v cm1hbDsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsi IGNsYXNzPSIiPg0KPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6 ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsOyBm b250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyB0ZXh0LWFsaWduOiBz dGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNl OiBub3JtYWw7IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAw cHg7IGZsb2F0OiBub25lOyBkaXNwbGF5OiBpbmxpbmUgIWltcG9ydGFudDsiIGNsYXNzPSIiPmNv bmN1cnJlbmNlDQogb2YgdGhlIGRyYWZ0IGF1dGhvcnMsIHdlIGFyZSBzdGFydGluZyBhIHdvcmtp bmcgZ3JvdXAgbGFzdCBjYWxsPC9zcGFuPjxiciBzdHlsZT0iZm9udC1mYW1pbHk6IEhlbHZldGlj YTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudC1jYXBz OiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IHRl eHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsg d2hpdGUtc3BhY2U6IG5vcm1hbDsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJv a2Utd2lkdGg6IDBweDsiIGNsYXNzPSIiPg0KPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiBIZWx2 ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQt Y2Fwczogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFs OyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5v bmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQt c3Ryb2tlLXdpZHRoOiAwcHg7IGZsb2F0OiBub25lOyBkaXNwbGF5OiBpbmxpbmUgIWltcG9ydGFu dDsiIGNsYXNzPSIiPihXR0xDKQ0KIGZvciB0aGUgRE9UUyBSZXF1aXJlbWVudHMgZHJhZnQ6PC9z cGFuPjxiciBzdHlsZT0iZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBm b250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7IGZvbnQtd2VpZ2h0 OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0 LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsg d29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsiIGNsYXNz PSIiPg0KPGJyIHN0eWxlPSJmb250LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6IDEycHg7 IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9udC13ZWln aHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgdGV4dC1hbGlnbjogc3RhcnQ7IHRl eHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFs OyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyIgY2xh c3M9IiI+DQo8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAx MnB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7IGZvbnQt d2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IHRleHQtYWxpZ246IHN0YXJ0 OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5v cm1hbDsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsg ZmxvYXQ6IG5vbmU7IGRpc3BsYXk6IGlubGluZSAhaW1wb3J0YW50OyIgY2xhc3M9IiI+RGlzdHJp YnV0ZWQNCiBEZW5pYWwgb2YgU2VydmljZSAoRERvUykgT3BlbiBUaHJlYXQgU2lnbmFsaW5nIFJl cXVpcmVtZW50czwvc3Bhbj48YnIgc3R5bGU9ImZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQt c2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fwczogbm9ybWFs OyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyB0ZXh0LWFsaWdu OiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNw YWNlOiBub3JtYWw7IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRo OiAwcHg7IiBjbGFzcz0iIj4NCjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTogSGVsdmV0aWNhOyBm b250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWNhcHM6IG5v cm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgdGV4dC1h bGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0 ZS1zcGFjZTogbm9ybWFsOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13 aWR0aDogMHB4OyBmbG9hdDogbm9uZTsgZGlzcGxheTogaW5saW5lICFpbXBvcnRhbnQ7IiBjbGFz cz0iIj5kcmFmdC1pZXRmLWRvdHMtcmVxdWlyZW1lbnRzLTA4PC9zcGFuPjxiciBzdHlsZT0iZm9u dC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7 IGZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1z cGFjaW5nOiBub3JtYWw7IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0 LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd29yZC1zcGFjaW5nOiAwcHg7 IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsiIGNsYXNzPSIiPg0KPGEgaHJlZj0iaHR0 cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTNBX190b29scy5p ZXRmLm9yZ19odG1sX2RyYWZ0LTJEaWV0Zi0yRGRvdHMtMkRyZXF1aXJlbWVudHMtMkQwOCZhbXA7 ZD1Ed0lDQWcmYW1wO2M9SGx2cHJxb25yNUx1Q045VE42NXhOdyZhbXA7cj1NLTBfQ3FFVlhhOU9R dm1KMmdNdFhBekw2djZKc1pIdHNSa21hUno0dXJFJmFtcDttPXFaM1JpaEFoZ0hHYm9ILVlmVzFL dlZoSDhERXI5VzFGMEhsUENEVzhrWG8mYW1wO3M9TTR4Qm5KdXVSaDJjdGdRTmVvMVlvWDFlbWZp TnRUdVNHMFV5YzZqSGt5YyZhbXA7ZT0iIHN0eWxlPSJmb250LWZhbWlseTogSGVsdmV0aWNhOyBm b250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWNhcHM6IG5v cm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgb3JwaGFu czogYXV0bzsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNm b3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3aWRvd3M6IGF1dG87IHdvcmQtc3BhY2lu ZzogMHB4OyAtd2Via2l0LXRleHQtc2l6ZS1hZGp1c3Q6IGF1dG87IC13ZWJraXQtdGV4dC1zdHJv a2Utd2lkdGg6IDBweDsiIGNsYXNzPSIiPmh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNv bS92Mi91cmw/dT1odHRwcy0zQV9fdG9vbHMuaWV0Zi5vcmdfaHRtbF9kcmFmdC0yRGlldGYtMkRk b3RzLTJEcmVxdWlyZW1lbnRzLTJEMDgmYW1wO2Q9RHdJQ0FnJmFtcDtjPUhsdnBycW9ucjVMdUNO OVRONjV4TncmYW1wO3I9TS0wX0NxRVZYYTlPUXZtSjJnTXRYQXpMNnY2SnNaSHRzUmttYVJ6NHVy RSZhbXA7bT1xWjNSaWhBaGdIR2JvSC1ZZlcxS3ZWaEg4REVyOVcxRjBIbFBDRFc4a1hvJmFtcDtz PU00eEJuSnV1UmgyY3RnUU5lbzFZb1gxZW1maU50VHVTRzBVeWM2akhreWMmYW1wO2U9PC9hPjxi ciBzdHlsZT0iZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0 eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3Jt YWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVu dDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd29yZC1z cGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsiIGNsYXNzPSIiPg0K PGJyIHN0eWxlPSJmb250LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6IDEycHg7IGZvbnQt c3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5v cm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5k ZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3b3Jk LXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyIgY2xhc3M9IiI+ DQo8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBm b250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7IGZvbnQtd2VpZ2h0 OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0 LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsg d29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsgZmxvYXQ6 IG5vbmU7IGRpc3BsYXk6IGlubGluZSAhaW1wb3J0YW50OyIgY2xhc3M9IiI+UGxlYXNlDQogc2Vu ZCBhbGwgY29tbWVudHMgdG8gdGhlIERPVFMgbWFpbGluZyBsaXN0Ljwvc3Bhbj48YnIgc3R5bGU9 ImZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9y bWFsOyBmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0 ZXItc3BhY2luZzogbm9ybWFsOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsg dGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdvcmQtc3BhY2luZzog MHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IiBjbGFzcz0iIj4NCjxiciBzdHls ZT0iZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBu b3JtYWw7IGZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxl dHRlci1zcGFjaW5nOiBub3JtYWw7IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4 OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd29yZC1zcGFjaW5n OiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsiIGNsYXNzPSIiPg0KPHNwYW4g c3R5bGU9ImZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHls ZTogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFs OyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6 IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdvcmQtc3Bh Y2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IGZsb2F0OiBub25lOyBk aXNwbGF5OiBpbmxpbmUgIWltcG9ydGFudDsiIGNsYXNzPSIiPlRoaXMNCiBXR0xDIHdpbGwgZW5k IG9uIEphbnVhcnkgMiwgMjAxOCAofjMgd2Vla3MgdG8gYWNjb3VudCBmb3I8L3NwYW4+PGJyIHN0 eWxlPSJmb250LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6 IG5vcm1hbDsgZm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsg bGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAw cHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3b3JkLXNwYWNp bmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyIgY2xhc3M9IiI+DQo8c3Bh biBzdHlsZT0iZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0 eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3Jt YWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVu dDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd29yZC1z cGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsgZmxvYXQ6IG5vbmU7 IGRpc3BsYXk6IGlubGluZSAhaW1wb3J0YW50OyIgY2xhc3M9IiI+ZW5kLW9mLXRoZS1jYWxlbmRh cg0KIHllYXIgdmFjYXRpb25zKS48L3NwYW4+PGJyIHN0eWxlPSJmb250LWZhbWlseTogSGVsdmV0 aWNhOyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWNh cHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsg dGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25l OyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0 cm9rZS13aWR0aDogMHB4OyIgY2xhc3M9IiI+DQo8YnIgc3R5bGU9ImZvbnQtZmFtaWx5OiBIZWx2 ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQt Y2Fwczogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFs OyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5v bmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQt c3Ryb2tlLXdpZHRoOiAwcHg7IiBjbGFzcz0iIj4NCjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTog SGVsdmV0aWNhOyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJp YW50LWNhcHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5v cm1hbDsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3Jt OiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10 ZXh0LXN0cm9rZS13aWR0aDogMHB4OyBmbG9hdDogbm9uZTsgZGlzcGxheTogaW5saW5lICFpbXBv cnRhbnQ7IiBjbGFzcz0iIj5UaGFua3MsPC9zcGFuPjxiciBzdHlsZT0iZm9udC1mYW1pbHk6IEhl bHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFu dC1jYXBzOiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3Jt YWw7IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTog bm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4 dC1zdHJva2Utd2lkdGg6IDBweDsiIGNsYXNzPSIiPg0KPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5 OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZh cmlhbnQtY2Fwczogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzog bm9ybWFsOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zv cm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0 LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IGZsb2F0OiBub25lOyBkaXNwbGF5OiBpbmxpbmUgIWlt cG9ydGFudDsiIGNsYXNzPSIiPlJvbWFuPC9zcGFuPjxiciBzdHlsZT0iZm9udC1mYW1pbHk6IEhl bHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFu dC1jYXBzOiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3Jt YWw7IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTog bm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4 dC1zdHJva2Utd2lkdGg6IDBweDsiIGNsYXNzPSIiPg0KPGJyIHN0eWxlPSJmb250LWZhbWlseTog SGVsdmV0aWNhOyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJp YW50LWNhcHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5v cm1hbDsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3Jt OiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10 ZXh0LXN0cm9rZS13aWR0aDogMHB4OyIgY2xhc3M9IiI+DQo8c3BhbiBzdHlsZT0iZm9udC1mYW1p bHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQt dmFyaWFudC1jYXBzOiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5n OiBub3JtYWw7IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5z Zm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJr aXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsgZmxvYXQ6IG5vbmU7IGRpc3BsYXk6IGlubGluZSAh aW1wb3J0YW50OyIgY2xhc3M9IiI+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX188L3NwYW4+PGJyIHN0eWxlPSJmb250LWZhbWlseTogSGVsdmV0aWNhOyBmb250 LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWNhcHM6IG5vcm1h bDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgdGV4dC1hbGln bjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1z cGFjZTogbm9ybWFsOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0 aDogMHB4OyIgY2xhc3M9IiI+DQo8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6IEhlbHZldGljYTsg Zm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudC1jYXBzOiBu b3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IHRleHQt YWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hp dGUtc3BhY2U6IG5vcm1hbDsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Ut d2lkdGg6IDBweDsgZmxvYXQ6IG5vbmU7IGRpc3BsYXk6IGlubGluZSAhaW1wb3J0YW50OyIgY2xh c3M9IiI+RG90cw0KIG1haWxpbmcgbGlzdDwvc3Bhbj48YnIgc3R5bGU9ImZvbnQtZmFtaWx5OiBI ZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlh bnQtY2Fwczogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9y bWFsOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06 IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRl eHQtc3Ryb2tlLXdpZHRoOiAwcHg7IiBjbGFzcz0iIj4NCjxhIGhyZWY9Im1haWx0bzpEb3RzQGll dGYub3JnIiBzdHlsZT0iZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBm b250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7IGZvbnQtd2VpZ2h0 OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IG9ycGhhbnM6IGF1dG87IHRleHQtYWxp Z246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUt c3BhY2U6IG5vcm1hbDsgd2lkb3dzOiBhdXRvOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10 ZXh0LXNpemUtYWRqdXN0OiBhdXRvOyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IiBj bGFzcz0iIj5Eb3RzQGlldGYub3JnPC9hPjxiciBzdHlsZT0iZm9udC1mYW1pbHk6IEhlbHZldGlj YTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudC1jYXBz OiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IHRl eHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsg d2hpdGUtc3BhY2U6IG5vcm1hbDsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJv a2Utd2lkdGg6IDBweDsiIGNsYXNzPSIiPg0KPGEgaHJlZj0iaHR0cHM6Ly91cmxkZWZlbnNlLnBy b29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTNBX193d3cuaWV0Zi5vcmdfbWFpbG1hbl9saXN0 aW5mb19kb3RzJmFtcDtkPUR3SUNBZyZhbXA7Yz1IbHZwcnFvbnI1THVDTjlUTjY1eE53JmFtcDty PU0tMF9DcUVWWGE5T1F2bUoyZ010WEF6TDZ2NkpzWkh0c1JrbWFSejR1ckUmYW1wO209cVozUmlo QWhnSEdib0gtWWZXMUt2VmhIOERFcjlXMUYwSGxQQ0RXOGtYbyZhbXA7cz1WTDE3S1BPdHh3aVpa TzIwMld6UUludk1YUE9HRUtQUG5LZkRYUEh2bmZ3JmFtcDtlPSIgc3R5bGU9ImZvbnQtZmFtaWx5 OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZh cmlhbnQtY2Fwczogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzog bm9ybWFsOyBvcnBoYW5zOiBhdXRvOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBw eDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdpZG93czogYXV0 bzsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zaXplLWFkanVzdDogYXV0bzsgLXdl YmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyIgY2xhc3M9IiI+aHR0cHM6Ly91cmxkZWZlbnNl LnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTNBX193d3cuaWV0Zi5vcmdfbWFpbG1hbl9s aXN0aW5mb19kb3RzJmFtcDtkPUR3SUNBZyZhbXA7Yz1IbHZwcnFvbnI1THVDTjlUTjY1eE53JmFt cDtyPU0tMF9DcUVWWGE5T1F2bUoyZ010WEF6TDZ2NkpzWkh0c1JrbWFSejR1ckUmYW1wO209cVoz UmloQWhnSEdib0gtWWZXMUt2VmhIOERFcjlXMUYwSGxQQ0RXOGtYbyZhbXA7cz1WTDE3S1BPdHh3 aVpaTzIwMld6UUludk1YUE9HRUtQUG5LZkRYUEh2bmZ3JmFtcDtlPTwvYT48YnIgc3R5bGU9ImZv bnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFs OyBmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXIt c3BhY2luZzogbm9ybWFsOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4 dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdvcmQtc3BhY2luZzogMHB4 OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IiBjbGFzcz0iIj4NCjxiciBzdHlsZT0i Zm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBub3Jt YWw7IGZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRl ci1zcGFjaW5nOiBub3JtYWw7IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0 ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd29yZC1zcGFjaW5nOiAw cHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsiIGNsYXNzPSIiPg0KPHNwYW4gc3R5 bGU9ImZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTog bm9ybWFsOyBmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBs ZXR0ZXItc3BhY2luZzogbm9ybWFsOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBw eDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdvcmQtc3BhY2lu ZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IGZsb2F0OiBub25lOyBkaXNw bGF5OiBpbmxpbmUgIWltcG9ydGFudDsiIGNsYXNzPSIiPl9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fPC9zcGFuPjxiciBzdHlsZT0iZm9udC1mYW1pbHk6IEhl bHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFu dC1jYXBzOiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3Jt YWw7IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTog bm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4 dC1zdHJva2Utd2lkdGg6IDBweDsiIGNsYXNzPSIiPg0KPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5 OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZh cmlhbnQtY2Fwczogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzog bm9ybWFsOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zv cm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0 LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IGZsb2F0OiBub25lOyBkaXNwbGF5OiBpbmxpbmUgIWlt cG9ydGFudDsiIGNsYXNzPSIiPkRvdHMNCiBtYWlsaW5nIGxpc3Q8L3NwYW4+PGJyIHN0eWxlPSJm b250LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1h bDsgZm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVy LXNwYWNpbmc6IG5vcm1hbDsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRl eHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3b3JkLXNwYWNpbmc6IDBw eDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyIgY2xhc3M9IiI+DQo8YSBocmVmPSJt YWlsdG86RG90c0BpZXRmLm9yZyIgc3R5bGU9ImZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQt c2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fwczogbm9ybWFs OyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyBvcnBoYW5zOiBh dXRvOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06 IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdpZG93czogYXV0bzsgd29yZC1zcGFjaW5nOiAw cHg7IC13ZWJraXQtdGV4dC1zaXplLWFkanVzdDogYXV0bzsgLXdlYmtpdC10ZXh0LXN0cm9rZS13 aWR0aDogMHB4OyIgY2xhc3M9IiI+RG90c0BpZXRmLm9yZzwvYT48YnIgc3R5bGU9ImZvbnQtZmFt aWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250 LXZhcmlhbnQtY2Fwczogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2lu Zzogbm9ybWFsOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFu c2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdvcmQtc3BhY2luZzogMHB4OyAtd2Vi a2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IiBjbGFzcz0iIj4NCjxhIGhyZWY9Imh0dHBzOi8v dXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fd3d3LmlldGYub3Jn X21haWxtYW5fbGlzdGluZm9fZG90cyZhbXA7ZD1Ed0lDQWcmYW1wO2M9SGx2cHJxb25yNUx1Q045 VE42NXhOdyZhbXA7cj1NLTBfQ3FFVlhhOU9Rdm1KMmdNdFhBekw2djZKc1pIdHNSa21hUno0dXJF JmFtcDttPXFaM1JpaEFoZ0hHYm9ILVlmVzFLdlZoSDhERXI5VzFGMEhsUENEVzhrWG8mYW1wO3M9 VkwxN0tQT3R4d2laWk8yMDJXelFJbnZNWFBPR0VLUFBuS2ZEWFBIdm5mdyZhbXA7ZT0iIHN0eWxl PSJmb250LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5v cm1hbDsgZm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0 dGVyLXNwYWNpbmc6IG5vcm1hbDsgb3JwaGFuczogYXV0bzsgdGV4dC1hbGlnbjogc3RhcnQ7IHRl eHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFs OyB3aWRvd3M6IGF1dG87IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc2l6ZS1hZGp1 c3Q6IGF1dG87IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsiIGNsYXNzPSIiPmh0dHBz Oi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fd3d3LmlldGYu b3JnX21haWxtYW5fbGlzdGluZm9fZG90cyZhbXA7ZD1Ed0lDQWcmYW1wO2M9SGx2cHJxb25yNUx1 Q045VE42NXhOdyZhbXA7cj1NLTBfQ3FFVlhhOU9Rdm1KMmdNdFhBekw2djZKc1pIdHNSa21hUno0 dXJFJmFtcDttPXFaM1JpaEFoZ0hHYm9ILVlmVzFLdlZoSDhERXI5VzFGMEhsUENEVzhrWG8mYW1w O3M9VkwxN0tQT3R4d2laWk8yMDJXelFJbnZNWFBPR0VLUFBuS2ZEWFBIdm5mdyZhbXA7ZT08L2E+ PC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxiciBjbGFzcz0iIj4NCjwvYm9keT4NCjwv aHRtbD4NCg== --_000_37171F0694DE44E785487ADD4B919AA6arbornet_-- From nobody Tue Jan 2 11:23:28 2018 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 E370D126CF6 for ; Tue, 2 Jan 2018 11:23:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.531 X-Spam-Level: X-Spam-Status: No, score=-14.531 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_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 q4V2cLvUu8Q7 for ; Tue, 2 Jan 2018 11:23:24 -0800 (PST) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AF6051200C1 for ; Tue, 2 Jan 2018 11:23:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2012; q=dns/txt; s=iport; t=1514921004; x=1516130604; h=subject:to:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=WuWCK5PRH13Uv0QJQy+dIrub04POi4tXi5qgtOlycRw=; b=fSVgUC9P78eiZB4rPgBrbFa1knpVcUSqw33YicYGCazqTvVqwAUD6mFl HFnGr73Cy3hNtR3KNI2rtHbJ1z37K/0Y0qtS+qUUVgX389jYYdYBLfc8Z KCJn2hFk5a6cyqrxbrAmiZ06cUBDACO3y32Gdxmnxv36TLANkN2LyqWcD g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AbAQCN20ta/4oNJK1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYM+ZnQnhAeKJI8aggGOfIVGgmgUggEKGAuFGAKEMD8YAQEBAQE?= =?us-ascii?q?BAQEBayiFJAEBAQMBASEPAQU2GwsOCgICERUCAicwBgEMBgIBAYodDRCyTYIni?= =?us-ascii?q?jkBAQEBAQEBAQEBAQEBAQEBAQEBGgWBD4J9gSpogVaBaSmDBYMvAYEpL1WCWIJ?= =?us-ascii?q?lBZMykBqIA4ZRhmGCF4YWg2yHZI0kiV+BPB85gU9MIxU9gimEdSM3iRIBAQE?= X-IronPort-AV: E=Sophos;i="5.45,498,1508803200"; d="scan'208";a="336603632" Received: from alln-core-5.cisco.com ([173.36.13.138]) by rcdn-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 02 Jan 2018 19:23:23 +0000 Received: from [10.82.219.227] (rtp-vpn3-991.cisco.com [10.82.219.227]) by alln-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id w02JNMoa000700; Tue, 2 Jan 2018 19:23:23 GMT To: Roman Danyliw , "dots@ietf.org" References: <359EC4B99E040048A7131E0F4E113AFC0131340FC1@marathon> From: Flemming Andreasen Message-ID: <32a94e81-eb33-abda-4f3a-163494fe2f96@cisco.com> Date: Tue, 2 Jan 2018 14:23:22 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: <359EC4B99E040048A7131E0F4E113AFC0131340FC1@marathon> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [Dots] WGLC on DOTS 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: Tue, 02 Jan 2018 19:23:27 -0000 Greetings I have reviewed the -09 version of the Requirements draft. I found a couple of nits, which I have submitted a Pull Request for separately (I will let the authors decide how/if they want to address those). I also found two minor issues that I would like to see addressed: 1) SIG-007 says that URI mitigation scope support is OPTIONAL, but then goes on to say that DOTS servers MUST be able to resolve URIs. This seems inconsistent. 2) SEC-002 says: For example, when a DOTS gateway   consisting of a DOTS server and DOTS client is running on the same logical   device, they must be within the same process security boundary. I think this is overly prescriptive, and even though the must is a lower-case, I think we should delete this whole sentence. Alternatively we could make it much weaker by reprasing this as one possible implementation option, e.g.: For example, when a DOTS gateway consisting of a DOTS server and DOTS client is running on the same logical device, the two DOTS agents could be implemented within the same process security boundary. Other than that, I think the draft is ready for Publication Request. Thanks -- Flemming On 12/7/17 3:50 PM, Roman Danyliw wrote: > Hello! > > Consistent with our discussion at the Singapore meeting and with the concurrence of the draft authors, we are starting a working group last call (WGLC) for the DOTS Requirements draft: > > Distributed Denial of Service (DDoS) Open Threat Signaling Requirements > draft-ietf-dots-requirements-08 > https://tools.ietf.org/html/draft-ietf-dots-requirements-08 > > Please send all comments to the DOTS mailing list. > > This WGLC will end on January 2, 2018 (~3 weeks to account for end-of-the-calendar year vacations). > > Thanks, > Roman > > _______________________________________________ > Dots mailing list > Dots@ietf.org > https://www.ietf.org/mailman/listinfo/dots > . > From nobody Tue Jan 2 11:58:25 2018 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 E189712D82E for ; Tue, 2 Jan 2018 11:58:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 I6HBMnAydUS2 for ; Tue, 2 Jan 2018 11:58:20 -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 B12AB12D82D for ; Tue, 2 Jan 2018 11:58:19 -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 1eWShU-000709-Qs; Tue, 02 Jan 2018 19:58:16 +0000 From: "Jon Shallow" To: "'Mortensen, Andrew'" , , References: <359EC4B99E040048A7131E0F4E113AFC0131355A04@marathon> <0baf01d383cf$a9cefd20$fd6cf760$@jpshallow.com> <37171F06-94DE-44E7-8548-7ADD4B919AA6@arbor.net> In-Reply-To: <37171F06-94DE-44E7-8548-7ADD4B919AA6@arbor.net> Date: Tue, 2 Jan 2018 19:58:15 -0000 Message-ID: <0c1701d38404$06b3f930$141beb90$@jpshallow.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0C18_01D38404.06B66A30" X-Mailer: Microsoft Outlook 14.0 Content-Language: en-gb Thread-Index: AQHdM/Qz99z/7IXDUi62LZwazkCMeAJMpXyoAUEu9cOjMSxWkA== Archived-At: Subject: Re: [Dots] REMINDER -- WGLC on DOTS 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: Tue, 02 Jan 2018 19:58:24 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0C18_01D38404.06B66A30 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hi Andrew et al, =20 Thanks for this =E2=80=93 see inline. =20 Regards =20 Jon =20 From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of Mortensen, = Andrew Sent: 02 January 2018 19:01 To: Jon Shallow Cc: Roman Danyliw; dots@ietf.org Subject: Re: [Dots] REMINDER -- WGLC on DOTS Requirements =20 =20 On Jan 2, 2018, at 8:43 AM, Jon Shallow = wrote: =20 Hi Roman, Comment # 1 I still have clarity issues with the usage of the terms "client-side" = and "server-side" with reference to DOTS gateways They are used both as a prefix and/or suffix to 'DOTS gateways', yet have different meaning = based on positioning. What does "client-side DOTS gateway server-side" actually mean? "client-side DOTS gateway server-side" means as I understand it "The = 'DOTS client' component of the DOTS gateway that is sitting in a client = domain", not "The 'DOTS server' component of the DOTS gateway that is sitting in = a client domain". "client-domain DOTS gateway server-facing-side" is a lot clearer to me. =20 The only terminology affected in the requirements draft is the = following: =20 Client-side DOTS gateways are DOTS gateways that are in the DOTS client's domain, while server-side DOTS gateways denote DOTS = gateways that are in the DOTS server's domain. =20 I have changed client-side and server-side to client-domain and = server-domain, respectively. Do we need to make the = server/client-facing-side distinction in the requirements draft, or can = we address that in the architecture draft? =20 [Jon] It really is in the signal-draft that the suffix = server/client-side is used =E2=80=93 but it is only in the requirements = draft that terms are defined =E2=80=93 hence why I raised it here. The = architecture draft will also need the prefix server/client-side updated = in most, but not all of the places =E2=80=93 e.g. 2. DOTS Architecture = =E2=80=9CAt some point, the DOTS client may decide to terminate the = server-side attack mitigation, which it indicates to the DOTS server = over the signal channel.=E2=80=9D should not be changed to = server-domain. =20 =20 Comment # 2 While Filter is defined, it does not appear to be used / required, = unless Black-List / White-List are using Filter only as a mechanism. Should = there be a DATA-005 for this as a requirement (i.e. using the flexibility of netconf-acl? =20 This doesn=E2=80=99t seem unreasonable to me as long as we make it clear = that, like B/W lists, filters are may be rejected due to capacity = limitations or policy restrictions. =20 andrew =20 =20 =20 =20 -----Original Message----- From: Dots [mailto: = dots-bounces@ietf.org] On Behalf Of Roman Danyliw Sent: 02 January 2018 12:53 To: dots@ietf.org Subject: [Dots] REMINDER -- WGLC on DOTS Requirements Hello! Happy New Year! The WGLC for the DOTS requirements draft will be = closing soon. Please provide any final comments. Thanks, Roman -----Original Message----- From: Roman Danyliw=20 Sent: Thursday, December 7, 2017 3:51 PM To: dots@ietf.org Subject: WGLC on DOTS Requirements Hello! Consistent with our discussion at the Singapore meeting and with the concurrence of the draft authors, we are starting a working group last = call (WGLC) for the DOTS Requirements draft: Distributed Denial of Service (DDoS) Open Threat Signaling Requirements draft-ietf-dots-requirements-08 = = https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__tools.ietf.org_htm= l_draft-2Dietf-2Ddots-2Drequirements-2D08&d=3DDwICAg&c=3DHlvprqonr5LuCN9T= N65xNw&r=3DM-0_CqEVXa9OQvmJ2gMtXAzL6v6JsZHtsRkmaRz4urE&m=3DqZ3RihAhgHGboH= -YfW1KvVhH8DEr9W1F0HlPCDW8kXo&s=3DM4xBnJuuRh2ctgQNeo1YoX1emfiNtTuSG0Uyc6j= Hkyc&e=3D Please send all comments to the DOTS mailing list. This WGLC will end on January 2, 2018 (~3 weeks to account for end-of-the-calendar year vacations). Thanks, Roman _______________________________________________ Dots mailing list Dots@ietf.org = = https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailm= an_listinfo_dots&d=3DDwICAg&c=3DHlvprqonr5LuCN9TN65xNw&r=3DM-0_CqEVXa9OQv= mJ2gMtXAzL6v6JsZHtsRkmaRz4urE&m=3DqZ3RihAhgHGboH-YfW1KvVhH8DEr9W1F0HlPCDW= 8kXo&s=3DVL17KPOtxwiZZO202WzQInvMXPOGEKPPnKfDXPHvnfw&e=3D _______________________________________________ Dots mailing list Dots@ietf.org = = https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailm= an_listinfo_dots&d=3DDwICAg&c=3DHlvprqonr5LuCN9TN65xNw&r=3DM-0_CqEVXa9OQv= mJ2gMtXAzL6v6JsZHtsRkmaRz4urE&m=3DqZ3RihAhgHGboH-YfW1KvVhH8DEr9W1F0HlPCDW= 8kXo&s=3DVL17KPOtxwiZZO202WzQInvMXPOGEKPPnKfDXPHvnfw&e=3D =20 ------=_NextPart_000_0C18_01D38404.06B66A30 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Hi Andrew et al,

 

Thanks for this =E2=80=93 see inline.

 

Regards

 

Jon

 

From:= Dots = [mailto: dots-bounces@ietf.org] On Behalf Of Mortensen, = Andrew
Sent: 02 January 2018 19:01
To: Jon = Shallow
Cc: Roman Danyliw; dots@ietf.org
Subject: = Re: [Dots] REMINDER -- WGLC on DOTS = Requirements

 

 

On Jan 2, 2018, at 8:43 AM, Jon Shallow <supjps-ietf@jpshallow.com&g= t; wrote:

 

Hi = Roman,

Comment # 1

I still have clarity issues with the = usage of the terms "client-side" = and
"server-side" with reference to DOTS gateways =  They are used both as a
prefix and/or suffix to 'DOTS = gateways', yet have different meaning based on
positioning. =  What does "client-side DOTS gateway server-side" = actually
mean?

"client-side DOTS gateway = server-side" means as I understand it "The 'DOTS
client' = component of the DOTS gateway that is sitting in a client = domain",
not "The 'DOTS server' component of the DOTS = gateway that is sitting in a
client = domain".

"client-domain DOTS gateway = server-facing-side" is a lot clearer to = me.

 

The only terminology affected in the requirements = draft is the following:

 

      Client-side DOTS gateways are = DOTS gateways that are in the DOTS

      client's domain, while =  server-side DOTS gateways denote DOTS = gateways

    =   that are in the DOTS server's domain.

 

I = have changed client-side and server-side to client-domain and = server-domain, respectively. Do we need to make the = server/client-facing-side distinction in the requirements draft, or can = we address that in the architecture draft?

 

[Jon] It really is in the signal-draft that the suffix = server/client-side is used =E2=80=93 but it is only in the requirements = draft that terms are defined =E2=80=93 hence why I raised it here.=C2=A0 = The architecture draft will also need the prefix server/client-side = updated in most, but not all of the places =E2=80=93 e.g. 2. DOTS = Architecture =E2=80=9CAt some point, the DOTS client may decide to = terminate the server-side attack mitigation, which it indicates to the = DOTS server over the signal channel.=E2=80=9D should not be changed to = server-domain.

 

 

Comment # = 2

While Filter is defined, it does not appear to be used / = required, unless
Black-List / White-List are using Filter only as a = mechanism.  Should there
be a DATA-005 for this as a requirement = (i.e. using the flexibility = of
netconf-acl?

 

This doesn=E2=80=99t seem unreasonable to me as long = as we make it clear that, like B/W lists, filters are may be rejected = due to capacity limitations or policy = restrictions.

 

andrew

 

 

 

 




-----O= riginal Message-----
From: Dots [mailto: dots-bounc= es@ietf.org] On = Behalf Of Roman Danyliw
Sent: 02 January 2018 12:53
To: dots@ietf.= org
Subjec= t: [Dots] REMINDER -- WGLC on DOTS = Requirements

Hello!

Happy New Year!  The WGLC for the = DOTS requirements draft will be closing
soon.  Please provide = any final comments.

Thanks,
Roman

-----Original = Message-----
From: Roman Danyliw 
Sent: Thursday, December = 7, 2017 3:51 PM
To: dots@ietf.org
Subject: WGLC on DOTS = Requirements

Hello!

Consistent with our discussion at the = Singapore meeting and with the
concurrence of the draft authors, we = are starting a working group last call
(WGLC) for the DOTS = Requirements draft:

Distributed Denial of Service (DDoS) Open = Threat Signaling = Requirements
draft-ietf-dots-requirements-08
https://ur= ldefense.proofpoint.com/v2/url?u=3Dhttps-3A__tools.ietf.org_html_draft-2D= ietf-2Ddots-2Drequirements-2D08&d=3DDwICAg&c=3DHlvprqonr5LuCN9TN6= 5xNw&r=3DM-0_CqEVXa9OQvmJ2gMtXAzL6v6JsZHtsRkmaRz4urE&m=3DqZ3RihAh= gHGboH-YfW1KvVhH8DEr9W1F0HlPCDW8kXo&s=3DM4xBnJuuRh2ctgQNeo1YoX1emfiNt= TuSG0Uyc6jHkyc&e=3D

Pl= ease send all comments to the DOTS mailing list.

This WGLC will = end on January 2, 2018 (~3 weeks to account for
end-of-the-calendar = year = vacations).

Thanks,
Roman

______________________________= _________________
Dots mailing list
Dots@ietf.= org
https://ur= ldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailman_listinf= o_dots&d=3DDwICAg&c=3DHlvprqonr5LuCN9TN65xNw&r=3DM-0_CqEVXa9O= QvmJ2gMtXAzL6v6JsZHtsRkmaRz4urE&m=3DqZ3RihAhgHGboH-YfW1KvVhH8DEr9W1F0= HlPCDW8kXo&s=3DVL17KPOtxwiZZO202WzQInvMXPOGEKPPnKfDXPHvnfw&e=3D

__= _____________________________________________
Dots mailing = list
Dots@ietf.= org
https://ur= ldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailman_listinf= o_dots&d=3DDwICAg&c=3DHlvprqonr5LuCN9TN65xNw&r=3DM-0_CqEVXa9O= QvmJ2gMtXAzL6v6JsZHtsRkmaRz4urE&m=3DqZ3RihAhgHGboH-YfW1KvVhH8DEr9W1F0= HlPCDW8kXo&s=3DVL17KPOtxwiZZO202WzQInvMXPOGEKPPnKfDXPHvnfw&e=3D

 

------=_NextPart_000_0C18_01D38404.06B66A30-- From nobody Tue Jan 2 13:58:07 2018 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 8C7F412D84D for ; Tue, 2 Jan 2018 13:58:06 -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 64o-rWtBwtY8 for ; Tue, 2 Jan 2018 13:58:04 -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 9C7E41242F7 for ; Tue, 2 Jan 2018 13:58:04 -0800 (PST) Received: from delp.sei.cmu.edu (delp.sei.cmu.edu [10.64.21.31]) by veto.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id w02Lw3BI040396 for ; Tue, 2 Jan 2018 16:58:03 -0500 DKIM-Filter: OpenDKIM Filter v2.11.0 veto.sei.cmu.edu w02Lw3BI040396 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cert.org; s=yc2bmwvrj62m; t=1514930283; bh=WA/WjB4KqBvdSHddjSOKp/DtOhBNJ8XECYYcZosWGCs=; h=From:To:Subject:Date:References:In-Reply-To:From; b=UIFdjxa7bvb/qbxkrU6RwJjXPJcD8e5saEUXbtGNBftq/HtU453m61wDMl9xVith9 cy10oHhBNPa1bNCu6yw8dEVu2tqNoYzli6Vu9cUJ/TqdW6SCONtvm/7G5HGHmImo0H ClVBc2529usyFNa3D9ZZ0DdFhtEjBE27TvoAFtfo= Received: from CASSINA.ad.sei.cmu.edu (cassina.ad.sei.cmu.edu [10.64.28.249]) by delp.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id w02Lw0Hl023147 for ; Tue, 2 Jan 2018 16:58:00 -0500 Received: from MARATHON.ad.sei.cmu.edu ([10.64.28.250]) by CASSINA.ad.sei.cmu.edu ([10.64.28.249]) with mapi id 14.03.0361.001; Tue, 2 Jan 2018 16:58:00 -0500 From: Roman Danyliw To: "dots@ietf.org" Thread-Topic: [Dots] REMINDER -- WGLC on DOTS Requirements Thread-Index: AQHThBTA0EGvMqSpOEOKRZUGU6TZ2Q== Date: Tue, 2 Jan 2018 21:57:59 +0000 Message-ID: References: <359EC4B99E040048A7131E0F4E113AFC0131355A04@marathon> In-Reply-To: <359EC4B99E040048A7131E0F4E113AFC0131355A04@marathon> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Dots] REMINDER -- WGLC on DOTS 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: Tue, 02 Jan 2018 21:58:06 -0000 Hello again! Given that some are just returning from their holiday, this WGLC will be ex= tended one more day =97 till Wednesday, January 3rd. Thanks, Roman > On Jan 2, 2018, at 07:53, Roman Danyliw wrote: >=20 > Hello! >=20 > Happy New Year! The WGLC for the DOTS requirements draft will be closing= soon. Please provide any final comments. >=20 > Thanks, > Roman >=20 > -----Original Message----- > From: Roman Danyliw=20 > Sent: Thursday, December 7, 2017 3:51 PM > To: dots@ietf.org > Subject: WGLC on DOTS Requirements >=20 > Hello! >=20 > Consistent with our discussion at the Singapore meeting and with the conc= urrence of the draft authors, we are starting a working group last call (WG= LC) for the DOTS Requirements draft: >=20 > Distributed Denial of Service (DDoS) Open Threat Signaling Requirements > draft-ietf-dots-requirements-08 > https://tools.ietf.org/html/draft-ietf-dots-requirements-08 >=20 > Please send all comments to the DOTS mailing list. >=20 > This WGLC will end on January 2, 2018 (~3 weeks to account for end-of-the= -calendar year vacations). >=20 > Thanks, > Roman >=20 > _______________________________________________ > Dots mailing list > Dots@ietf.org > https://www.ietf.org/mailman/listinfo/dots >=20 From nobody Tue Jan 2 20:59:37 2018 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 5379B1200FC; Tue, 2 Jan 2018 20:59:36 -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.68.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151495557630.30935.18008555521121942771@ietfa.amsl.com> Date: Tue, 02 Jan 2018 20:59:36 -0800 Archived-At: Subject: [Dots] I-D Action: draft-ietf-dots-requirements-10.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, 03 Jan 2018 04:59:36 -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 (DDoS) Open Threat Signaling Requirements Authors : Andrew Mortensen Robert Moskowitz Tirumaleswar Reddy Filename : draft-ietf-dots-requirements-10.txt Pages : 20 Date : 2018-01-02 Abstract: This document defines the requirements for the Distributed Denial of Service (DDoS) Open Threat Signaling (DOTS) protocols coordinating attack response against DDoS attacks. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dots-requirements/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-dots-requirements-10 https://datatracker.ietf.org/doc/html/draft-ietf-dots-requirements-10 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dots-requirements-10 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 Jan 2 21:01:12 2018 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 46B6C1252BA for ; Tue, 2 Jan 2018 21:01:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 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, 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 FjLEQ1GEO9AK for ; Tue, 2 Jan 2018 21:01:09 -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 2586A1200FC for ; Tue, 2 Jan 2018 21:01:09 -0800 (PST) Received: from pps.filterd (m0096263.ppops.net [127.0.0.1]) by mx0a-00196b01.pphosted.com (8.16.0.21/8.16.0.21) with SMTP id w03517rl003792 for ; Wed, 3 Jan 2018 00:01:07 -0500 Received: from nam03-co1-obe.outbound.protection.outlook.com (mail-co1nam03lp0020.outbound.protection.outlook.com [216.32.181.20]) by mx0a-00196b01.pphosted.com with ESMTP id 2f68dpu218-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT) for ; Wed, 03 Jan 2018 00:01:07 -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=nMihlSo/qqUaEFaqrSEa/6CBbDz2nsd/y0GFDhojBtw=; b=Enm8SD4IxiAaQoL8iXeX8tDafWDN+S/gpe7aJGpA2KyLfbnIYKLiG+AvZfSFbnWb/028AzDZQn9QJe9M8e1wC4+GiqMb9/kSW5WWt43T73L07B9wgJvHOoX9kGq4Q+NFbpHKetkrozBsjDCqm3g7I4LAYpm9oNSi8GPCjzAWxJI= Received: from BN3PR01MB1987.prod.exchangelabs.com (10.166.71.144) by BN3PR01MB1986.prod.exchangelabs.com (10.166.71.143) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.386.5; Wed, 3 Jan 2018 05:01:04 +0000 Received: from BN3PR01MB1987.prod.exchangelabs.com ([10.166.71.144]) by BN3PR01MB1987.prod.exchangelabs.com ([10.166.71.144]) with mapi id 15.20.0386.005; Wed, 3 Jan 2018 05:01:04 +0000 From: "Mortensen, Andrew" To: "dots@ietf.org" Thread-Topic: [Dots] I-D Action: draft-ietf-dots-requirements-10.txt Thread-Index: AQHThE+q+2u3HIWprEmAb+o/HbTdag== Date: Wed, 3 Jan 2018 05:01:04 +0000 Message-ID: <3875AC52-085A-4DCA-B819-31F42441E6E6@arbor.net> References: <151495557630.30935.18008555521121942771@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [68.49.167.203] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BN3PR01MB1986; 7:GikNsabfhgnkbFC8ThYfGTonHOKH5jVrtkjIex5V+NXmGdrntnqxIB+uEm4hSDzxOJnUebo+ZHJH+DzvXP8Y37CAeRf0Ps2IBWBPc/xqXT5AF/s2mQAg5hsYHXsKltIOmV3LGg/oDRAXa/io0YrumzUfzBcPkqDsggQXucrb9lF+IApW5z4tEvBzqiEyd3qTScjvbpztSslW7xsILMxZyqPDjvVhwJgT7EnNRFtp7rkP2EQ3YcD9lk3yMknj57Yz x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 9fa50903-db61-4b60-9377-08d55266fdee x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(5600026)(4604075)(3008032)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(2017052603307)(7153060); SRVR:BN3PR01MB1986; x-ms-traffictypediagnostic: BN3PR01MB1986: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040470)(2401047)(8121501046)(5005006)(10201501046)(3002001)(93006095)(93001095)(3231023)(944501075)(6041268)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123564045)(20161123558120)(20161123562045)(6072148)(201708071742011); SRVR:BN3PR01MB1986; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:BN3PR01MB1986; x-forefront-prvs: 0541031FF6 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(346002)(376002)(366004)(39380400002)(39850400004)(396003)(377424004)(199004)(189003)(97736004)(86362001)(5640700003)(76176011)(106356001)(105586002)(5660300001)(8936002)(7736002)(83716003)(82746002)(2501003)(236005)(6436002)(53936002)(478600001)(102836004)(66066001)(68736007)(54896002)(77096006)(14454004)(6486002)(6506007)(230783001)(6116002)(3660700001)(3846002)(1730700003)(3280700002)(316002)(2900100001)(81156014)(229853002)(6916009)(33656002)(81166006)(6512007)(25786009)(2351001)(8676002)(99286004)(2473003)(2906002)(36756003); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR01MB1986; H:BN3PR01MB1987.prod.exchangelabs.com; 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-antispam-message-info: MymQxRRITXtgzxVh5EFe616b+wDLJv4rzeecEhx6ATJhFl1LXM8Ftd/stePWveOuSuAT7RKXuVJDCclPx0T0aw== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_3875AC52085A4DCAB81931F42441E6E6arbornet_" MIME-Version: 1.0 X-OriginatorOrg: arbor.net X-MS-Exchange-CrossTenant-Network-Message-Id: 9fa50903-db61-4b60-9377-08d55266fdee X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Jan 2018 05:01:04.0706 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 54f11205-d4aa-4809-bd36-0b542199c5b2 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR01MB1986 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-01-03_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 mlxscore=0 impostorscore=0 mlxlogscore=729 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1801030069 Archived-At: Subject: [Dots] Fwd: I-D Action: draft-ietf-dots-requirements-10.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, 03 Jan 2018 05:01:11 -0000 --_000_3875AC52085A4DCAB81931F42441E6E6arbornet_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable This revision incorporates recent WGLC feedback. andrew Begin forwarded message: From: internet-drafts@ietf.org Subject: [Dots] I-D Action: draft-ietf-dots-requirements-10.txt Date: January 2, 2018 at 11:59:36 PM EST To: > Cc: dots@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the DDoS Open Threat Signaling WG of the IETF. Title : Distributed Denial of Service (DDoS) Open Threat S= ignaling Requirements Authors : Andrew Mortensen Robert Moskowitz Tirumaleswar Reddy Filename : draft-ietf-dots-requirements-10.txt Pages : 20 Date : 2018-01-02 Abstract: This document defines the requirements for the Distributed Denial of Service (DDoS) Open Threat Signaling (DOTS) protocols coordinating attack response against DDoS attacks. --_000_3875AC52085A4DCAB81931F42441E6E6arbornet_ Content-Type: text/html; charset="us-ascii" Content-ID: <42FA2A2E742E4A4ABE417A952F69D8A9@prod.exchangelabs.com> Content-Transfer-Encoding: quoted-printable This revision incorporates recent WGLC feedback.

andrew



Begin forwarded message:

From: internet-drafts@ietf.org
Subject: [Dots] I-D Action: draft-= ietf-dots-requirements-10.txt
Date: January 2, 2018 at 11:59:36 PM EST
To: <i-d-announce@ietf.org>
Cc: dots@ietf.org


A New Internet-Draft is available from the on-line Internet-Drafts director= ies.
This draft is a work item of the DDoS Open Threat Signaling WG of the IETF.=

       Title     &nb= sp;     : Distributed Denial of Service (DDoS) Ope= n Threat Signaling Requirements
       Authors     &= nbsp;   : Andrew Mortensen
            &nb= sp;            = Robert Moskowitz
            &nb= sp;            = Tirumaleswar Reddy
Filename &n= bsp;      : draft-ietf-dots-requirements-10.t= xt
Pages  = ;         : 20
Date  =           : 2018-01-02
Abstract:
  This document defines the requirements for the Distributed Deni= al of
  Service (DDoS) Open Threat Signaling (DOTS) protocols coordinat= ing
  attack response against DDoS attacks.
--_000_3875AC52085A4DCAB81931F42441E6E6arbornet_-- From nobody Tue Jan 2 23:20:52 2018 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 103A0126B72 for ; Tue, 2 Jan 2018 23:20:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.009 X-Spam-Level: X-Spam-Status: No, score=-7.009 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, T_RP_MATCHES_RCVD=-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 MOtCf942CEco for ; Tue, 2 Jan 2018 23:20: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 BCDC3120227 for ; Tue, 2 Jan 2018 23:20: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=1514964036; 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:x-microsoft-antispam-message-info: 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=D AIvgYGoCrwSEIBOh+ud06wiKc3l/Lg4vd5wvZteM/ k=; b=KfsMaP1PGf5cUvSsFdguFkJ5hiqOMdC6asDMBgR4+xcb e6L6XUkprWihktZCnZ3pfI/793AFpiF8AiMq67WxUe/tM0elC7 o6iKFK0GJjSncjLDKORnhTgZRdqP/GqgHTX4TEy4nEQIygRK4E ioKGq47/Doi0wQzsOOSTaQ3peb4= Received: from MIVEXAPP1N01.corpzone.internalzone.com (mivexapp1n01.corpzone.internalzone.com [10.48.48.88]) by MIVWSMAILOUT1.mcafee.com with smtp (TLS: TLSv1/SSLv3,256bits,ECDHE-RSA-AES256-SHA384) id 1148_3a26_e64b5ab5_74a8_489d_9aea_683d68876254; Wed, 03 Jan 2018 01:20:35 -0600 Received: from MIVEXUSR1N01.corpzone.internalzone.com (10.48.48.81) by MIVEXAPP1N01.corpzone.internalzone.com (10.48.48.88) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Wed, 3 Jan 2018 02:20:32 -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, 3 Jan 2018 02:20:32 -0500 Received: from NAM01-BN3-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, 3 Jan 2018 02:20:31 -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.366.8; Wed, 3 Jan 2018 07:20:30 +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.0366.009; Wed, 3 Jan 2018 07:20:30 +0000 From: "Konda, Tirumaleswar Reddy" To: Jon Shallow , "dots@ietf.org" Thread-Topic: [Dots] Using SNI Thread-Index: AdOBYSmGAk9KbyE4TFyYKC/j9TeHqgCRKPHwAAH2wAAAAHaCkAAAPMGAACycgwA= Date: Wed, 3 Jan 2018 07:20:30 +0000 Message-ID: References: <0a1201d38161$299ef350$7cdcd9f0$@jpshallow.com> <0b2301d383ad$a8822a40$f9867ec0$@jpshallow.com> <0b4b01d383b0$758f1370$60ad3a50$@jpshallow.com> In-Reply-To: <0b4b01d383b0$758f1370$60ad3a50$@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:I8pZ4Tnntld7CdLMewsr2ElFxqzDdQ5bUxT57d9DdQJ8JY4KsW8crXLGTZ9aKE4p2i/wqoKVME4WOWkWNlnBYqOy/R7Bi2Zui/YMW60SXIJi0QFS2Mgcqq4Oimh9rA1Dg8K+Tm/ITNiRHMKZFmJdawx68hR2E3lDf90yDPObTP7YWqpR0DeU/EVZpmsFeBsQlEGzYMGd+fAFtQJUuDokTU+r7Efk1N3K670T7DCsTqJxDXAjsTiiMNazVRYrSpTEGQ/sEezOvWJvwiJCOdSDL1Ymx8FgOTsMECePvKR8n7ZJWAgKoD75eb7AGjqrjRm9EU73akWpTY+hZ9CcFsjs+n98kN7G2lTc66Y3lDF+4c43ditUaGjZ5xBBHo89eYS/; 5:kqQt8ZuZ5zvaXl7r7PtCbRoPGzq/IVbGUVkukKfQiyAixC5JXDyPVgQV/3MpvppKNeuPBfBBHlrXEZyusups709mce/JsCOzfkUFdlp2kXY8cuqxo6qFbkz82dhF91tkdDuCsetTLJi/Rj83dCUYeVIVVrFI2jsTKrDRucOTVO8=; 24:y/OWs88qBUr4Cq8qB9avHeHWb4PsvROW/FQTbEjviIvaOECxeYWZxtOe1E0UOOfbmscFKog7zfRlgSgPHBvYZXLcWLp752tZAk/cBbbYol8=; 7:aRCSxF0sID5bMC7Dkt+nhk/yU9kzzu2/bszDhfoxodsdFexkLzmHl2+6vo7zUPXRNsAYgWGeSXf9goCeXBBIu/KWzVRpjH0ZPiJ0t6NxyhtUXWziWOg77cCWqkrZrBBYB0CDECxgwF4TdCVu/DOdDSyHvrDSHIqDB9wr6x/AcPJ/9DMWCKLjfw5asByNHgyVpYT/YFXBf9jG8j/jscw7KnUW2dLIxGjnjWiZHeEcF5CZL2FAAWiLOAkccMc9wfCy x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: d79eade5-9909-4d84-153e-08d5527a7887 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(5600026)(4604075)(3008032)(2017052603307)(7153060); SRVR:DM5PR16MB1785; x-ms-traffictypediagnostic: DM5PR16MB1785: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(192374486261705)(21748063052155)(123452027830198); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040470)(2401047)(5005006)(8121501046)(3002001)(3231023)(944501075)(93006095)(93001095)(10201501046)(6041268)(20161123564045)(20161123562045)(20161123560045)(20161123558120)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(6072148)(201708071742011); SRVR:DM5PR16MB1785; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:DM5PR16MB1785; x-forefront-prvs: 0541031FF6 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(346002)(396003)(39860400002)(366004)(376002)(39380400002)(32952001)(51444003)(199004)(189003)(110136005)(478600001)(59450400001)(9326002)(102836004)(2900100001)(81156014)(14454004)(7736002)(81166006)(68736007)(25786009)(2950100002)(53546011)(76176011)(2501003)(8936002)(99286004)(6506007)(72206003)(7696005)(316002)(77096006)(790700001)(93886005)(66066001)(5660300001)(3846002)(229853002)(6116002)(53936002)(3280700002)(74316002)(6246003)(19609705001)(86362001)(3660700001)(6436002)(9686003)(33656002)(80792005)(8676002)(97736004)(2906002)(6306002)(106356001)(54896002)(55016002)(236005)(105586002)(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) x-microsoft-antispam-message-info: vIHv/YxtjAxn2Lq2aElmabMyKHSIAUSppln25OMKL0OONkXp12L2k4alzyMejj4VCY/vTWmmV9eqejj8kKMGmA== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_DM5PR16MB1788C665C625731E6AF1C7B9EA1E0DM5PR16MB1788namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: d79eade5-9909-4d84-153e-08d5527a7887 X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Jan 2018 07:20:30.2993 (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 <6191> : inlines <6293> : streams <1774961> : uri <2562238> Archived-At: Subject: Re: [Dots] Using SNI 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, 03 Jan 2018 07:20:51 -0000 --_000_DM5PR16MB1788C665C625731E6AF1C7B9EA1E0DM5PR16MB1788namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Jon, We may want to use "SHOULD" instead of "MUST" in the below line (for exampl= e, SNI is not required if the DOTS client and server are in the same enterp= rise network). -TIru From: Jon Shallow [mailto:supjps-ietf@jpshallow.com] Sent: Tuesday, January 2, 2018 3:30 PM To: Konda, Tirumaleswar Reddy ; dots@ie= tf.org Subject: RE: [Dots] Using SNI Hi Tiru, That certainly works for me - thanks Regards Jon From: Dots [mailto: dots-bounces@ietf.org] On= Behalf Of Konda, Tirumaleswar Reddy Sent: 02 January 2018 09:55 To: Jon Shallow; dots@ietf.org Subject: Re: [Dots] Using SNI Hi Jon, RESTCONF does not mandate client authentication based on TLS client certifi= cate, we can say the following instead: If TLS client certificate is used to authenticate the DOTS client, the DOTS= client MUST include the DOTS server FQDN in server name indication extensi= on (Section 3 of RFC6066). Cheers, -Tiru From: Jon Shallow [mailto:supjps-ietf@jpshallow.com] Sent: Tuesday, January 2, 2018 3:10 PM To: Konda, Tirumaleswar Reddy >; dots@ietf.org Subject: RE: [Dots] Using SNI Hi Tiru, I agree that (indirectly through RFC7525 reference) SNI is mandated to be s= upported (but not necessarily has to be used). However, to guarantee interoperability between different DOTS vendors, I am= saying that the use of SNI is a MUST - in particular for the data channel. Regards Jon From: Dots [mailto: dots-bounces@ietf.org] On= Behalf Of Konda, Tirumaleswar Reddy Sent: 02 January 2018 08:48 To: Jon Shallow; dots@ietf.org Subject: Re: [Dots] Using SNI Hi Jon, Both signal and data channel drafts refer to RFC7525 for secure use of (D)T= LS and RFC7525 mandates TLS implementations to support SNI. I don't see the= need to explicitly discuss SNI in these drafts. Regards, -Tiru From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Jon Shallow Sent: Saturday, December 30, 2017 4:57 PM To: dots@ietf.org Subject: [Dots] Using SNI Hi WG, When providing a DOTS server data channel service in my environment, this s= hares the same ip / port which also provides other services (e.g. GUI / RES= T server etc.). Even if the Root Discovery points to another IP and or por= t for the actual data channel activity, the TLS exchanges for the Root Disc= overy have to correctly work. I suspect that I am not the only DOTS vendor= who will have this type of requirement of a single IP providing multiple T= LS services. As DOTS requires mutual authentication, this is a different security requir= ement than required by the GUI environment (DOTS requires client cert to be= presented, GUI does not and providing certificates to every GUI client is = not a practical option). This can be handled by using SNI by using 2 different FQDNs and requiring t= he DOTS client to include the DOTS specific FQDN in the TLS Client Hello. = Whether the GUI client does or does not (likely does with modern browsers) = include a SNI FQDN when connecting to the non DOTS FQDN does not really mat= ter - for DOTS it is recognizing the DOTS specific FQDN and setting up the = TLS as appropriate. To make sure interoperability between DOTS vendors, I would like to see som= ething like added to the data channel spec "DOTS clients MUST include the D= OTS server FQDN in the TLS Client Hello packet by using Server Name Indicat= ion (SNI) RFC 3546". In addition, I think that this would be a good idea as well for the signal = draft - thereby giving DOTS vendors the opportunity to host multiple DOTS s= ervers (likely to be different security requirements for their different cl= ient) on a single IP / port. Thoughts / comments? Regards Jon --_000_DM5PR16MB1788C665C625731E6AF1C7B9EA1E0DM5PR16MB1788namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Jon,

&nbs= p;

We may wa= nt to use “SHOULD” instead of “MUST” in the below l= ine (for example, SNI is not required if the DOTS client and server are in = the same enterprise network).

&nbs= p;

-TIru

 

From:<= /span> Jon Shallow [mailto:s= upjps-ietf@jpshallow.com]
Sent: Tuesday, January 2, 2018 3:30 PM
To: Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@McAfee.com= >; dots@ietf.org
Subject: RE: [Dots] Using SNI

 

Hi Tiru= ,

&n= bsp;

That ce= rtainly works for 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: 02 January 2018 09:55
To: Jon Shallow; dots@ietf.org<= br> Subject: Re: [Dots] Using SNI

 

Hi Jon,
 
RESTCONF does not mandate client authentication based on TLS client c=
ertificate, we can say the following instead:
If TLS client certificate is used to authenticate the DOTS client, th=
e DOTS client MUST include the DOTS server FQDN in server name indication e=
xtension (Section 3 of RFC6066).
 
Cheers,
-Tiru
 

From:<= /span> Jon Shallow [mailto:supjps-ietf@jpshallow.com]
Sent: Tuesday, January 2, 2018 3:10 PM
To: Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@McAfee.com>; dots@ietf.org
Subject: RE: [Dots] Using SNI

 

Hi Tiru= ,

&n= bsp;

I agree= that (indirectly through RFC7525 reference) SNI is mandated to be supporte= d (but not necessarily has to be used).

&n= bsp;

However= , to guarantee interoperability between different DOTS vendors, I am saying= that the use of SNI is a MUST – in particular for the data channel.<= o:p>

&n= bsp;

Regards=

&n= bsp;

Jon

&n= bsp;

From: Dots [mailto: dots-bounces@ietf.org] On B= ehalf Of Konda, Tirumaleswar Reddy
Sent: 02 January 2018 08:48
To: Jon Shallow; dots@ietf.org<= br> Subject: Re: [Dots] Using SNI

 

Hi Jon,

&nbs= p;

Both sign= al and data channel drafts refer to RFC7525 for secure use of (D)TLS and RF= C7525 mandates TLS implementations to support SNI. I don’t see the ne= ed to explicitly discuss SNI in these drafts.


Regards,

-Tiru

&nbs= p;

From:<= /span> Dots [mailto:dots-bounces@ietf.org] On Behalf Of Jon Shallow
Sent: Saturday, December 30, 2017 4:57 PM
To: dots@ietf.org
Subject: [Dots] Using SNI

 

Hi WG,

 

When providing a DOTS server da= ta channel service in my environment, this shares the same ip / port which = also provides other services (e.g. GUI / REST server etc.).  Even if t= he Root Discovery points to another IP and or port for the actual data channel activity, the TLS exchanges for the Ro= ot Discovery have to correctly work.  I suspect that I am not the only= DOTS vendor who will have this type of requirement of a single IP providin= g multiple TLS services.

 

As DOTS requires mutual authent= ication, this is a different security requirement than required by the GUI = environment (DOTS requires client cert to be presented, GUI does not and pr= oviding certificates to every GUI client is not a practical option).

 

This can be handled by using SN= I by using 2 different FQDNs and requiring the DOTS client to include the D= OTS specific FQDN in the TLS Client Hello.  Whether the GUI client doe= s or does not (likely does with modern browsers) include a SNI FQDN when connecting to the non DOTS FQDN does not really ma= tter – for DOTS it is recognizing the DOTS specific FQDN and setting = up the TLS as appropriate.

 

To make sure interoperability b= etween DOTS vendors, I would like to see something like added to the data c= hannel spec “DOTS clients MUST include the DOTS server FQDN in the TL= S Client Hello packet by using Server Name Indication (SNI) RFC 3546”.

 

In addition, I think that this = would be a good idea as well for the signal draft – thereby giving DO= TS vendors the opportunity to host multiple DOTS servers (likely to be diff= erent security requirements for their different client) on a single IP / port.

 

Thoughts / comments?=

 

Regards

 

Jon

--_000_DM5PR16MB1788C665C625731E6AF1C7B9EA1E0DM5PR16MB1788namp_-- From nobody Tue Jan 2 23:38:20 2018 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 A3B37126B72 for ; Tue, 2 Jan 2018 23:38:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.009 X-Spam-Level: X-Spam-Status: No, score=-7.009 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, T_RP_MATCHES_RCVD=-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 U6fHaPv7kLx0 for ; Tue, 2 Jan 2018 23:38:17 -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 57B13120227 for ; Tue, 2 Jan 2018 23:38: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=1514965096; 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: x-microsoft-antispam-message-info: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=zOIzJAucMkwGCwdwpCOg0MrA8zaxNGB1g9xIBG hK09g=; b=iZRpxXEx1nSi8zAH2IkzUKZyuQ4bPvJAscsm2UIp HQ1MszSEFtjHhxE74bYV49O9Y+W0a+mKEhU5js6smZZgW+QwgP CUW9rZh8UKgo8HawHMKmjxGwTGj/4gMGO1QMnOPcg6iNVHJ1ky PiN/XTz2k3FrhYajgu8P/OL+Fu+lsGY= Received: from MIVEXAPP1N03.corpzone.internalzone.com (unknown [10.48.48.90]) by MIVWSMAILOUT1.mcafee.com with smtp (TLS: TLSv1/SSLv3,256bits,ECDHE-RSA-AES256-SHA384) id 113e_06c8_cfc20809_7692_4de2_a12b_768af15b8fa5; Wed, 03 Jan 2018 01:38:15 -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; Wed, 3 Jan 2018 02:38:15 -0500 Received: from MIVEXUSR1N02.corpzone.internalzone.com (10.48.48.82) by MIVEXUSR1N06.corpzone.internalzone.com (10.48.48.86) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Wed, 3 Jan 2018 02:38:14 -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; Wed, 3 Jan 2018 02:38:13 -0500 Received: from NAM01-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; Wed, 3 Jan 2018 02:38:13 -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.366.8; Wed, 3 Jan 2018 07:38: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.0366.009; Wed, 3 Jan 2018 07:38:12 +0000 From: "Konda, Tirumaleswar Reddy" To: Jon Shallow , "dots@ietf.org" Thread-Topic: [Dots] Mutual Authentication between DOTS peers Thread-Index: AdOD7c3U3eTi3IQ0SPSETf2VuKuPkwAdoEmg Date: Wed, 3 Jan 2018 07:38:12 +0000 Message-ID: References: <0bf201d383ed$cdf63970$69e2ac50$@jpshallow.com> In-Reply-To: <0bf201d383ed$cdf63970$69e2ac50$@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; 7:vBmezCJSjaw1OtmM/7q1ndOMjTUSIKWng53q4mODpDzr+cevvV/TCzClf8pigX+VQx7JJmFrjfbdfPOvAcd8nSsXeMDExNeyQWKjoW9WMeax1oV9syB/Fx6gKEwTXB9UdblwSRxyPdQhfR5PoSEr+zTcQK7Ad3FAEir4GZStUBo0Ph8p6S/kkFVHf25RxS4lTi1Fm0Yhl4UMQ3Ui+ZrZT9WxomdCzndwpz4ayjC1n03VqGHJNtfrL2R+gL1d6bLP x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: e547ed72-4823-429a-6077-08d5527cf1b3 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(5600026)(4604075)(3008032)(2017052603307)(7153060); SRVR:DM5PR16MB1788; x-ms-traffictypediagnostic: DM5PR16MB1788: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040470)(2401047)(5005006)(8121501046)(10201501046)(93006095)(93001095)(3231023)(944501075)(3002001)(6041268)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(20161123564045)(20161123558120)(20161123562045)(6072148)(201708071742011); SRVR:DM5PR16MB1788; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:DM5PR16MB1788; x-forefront-prvs: 0541031FF6 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(366004)(376002)(39380400002)(346002)(396003)(39860400002)(189003)(199004)(51914003)(32952001)(9326002)(6306002)(72206003)(86362001)(236005)(6116002)(2950100002)(966005)(478600001)(74316002)(5660300001)(8936002)(54896002)(3846002)(790700001)(7736002)(316002)(66066001)(3280700002)(9686003)(110136005)(606006)(2900100001)(3660700001)(2501003)(105586002)(106356001)(81166006)(80792005)(14454004)(68736007)(229853002)(53546011)(97736004)(102836004)(6506007)(2906002)(99286004)(81156014)(53936002)(33656002)(6246003)(19609705001)(77096006)(6436002)(76176011)(7696005)(8676002)(25786009)(55016002)(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; x-microsoft-antispam-message-info: 2cSB0GaHjhz5hFLYQUYwthcS4DoCX9FFxH7Z+mFAzpnBf0ldfAAvHlZFfTsPa74MvVjUi3qq6KBHxFnpfZ0I3w== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_DM5PR16MB1788563B2CB2B40107DBDEB7EA1E0DM5PR16MB1788namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: e547ed72-4823-429a-6077-08d5527cf1b3 X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Jan 2018 07:38:12.5717 (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 <6191> : inlines <6293> : streams <1774962> : uri <2562246> Archived-At: Subject: Re: [Dots] Mutual Authentication between DOTS peers 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, 03 Jan 2018 07:38:19 -0000 --_000_DM5PR16MB1788563B2CB2B40107DBDEB7EA1E0DM5PR16MB1788namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Jon, Thanks for the comments, please see inline. From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Jon Shallow Sent: Tuesday, January 2, 2018 10:49 PM To: dots@ietf.org Subject: [Dots] Mutual Authentication between DOTS peers Hi WG, Mutual Authentication is required between 2 DOTS peers, but then the drafts= do not make any suggestions that I have found as to how to do it other tha= n referring to EST. [TR] No, https://tools.ietf.org/html/draft-ietf-dots-signal-channel-14#sect= ion-7.1 discusses PKI, PSK and RPK and the data channel draft refers to thi= s section for mutual authentication b/w the DOTS agents. I want to make sure we have a set of alternatives in place as a minimum req= uirement for DOTS vendor interoperability. What I am planning to put into place (be more enforcing) in my DOTS impleme= ntation - comments welcome as well as additional suggestions. PKI Client and Server Certificates have to be signed by the same CA. The CA do= es not need to get exchanged during (D)TLS session set up. The CA does not= need to go back to a well-known root CA. PSK The DOTS client 'identity' (potentially FQDN of client) is used for validat= ing the client by the server, and the DOTS server 'identity-hint' (potentia= lly FQDN of server) is used by the client for validating the server. Obvio= usly they both share the same PSK! [TR] The "PSK_Identity" and "PSK identity hint" need not be FQDNs of the DO= TS client and server, https://tools.ietf.org/html/rfc4279#section-5 does no= t mandate a particular type of identity. -Tiru RPK Nothing in place so far as I have not worked out how to get OpenSSL to do t= his for me so far, so have no suggestions here. Regards Jon --_000_DM5PR16MB1788563B2CB2B40107DBDEB7EA1E0DM5PR16MB1788namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Jon,

&nbs= p;

Thanks fo= r the comments, please see inline.

 

From:<= /span> Dots [mailto:dots-bou= nces@ietf.org] On Behalf Of Jon Shallow
Sent: Tuesday, January 2, 2018 10:49 PM
To: dots@ietf.org
Subject: [Dots] Mutual Authentication between DOTS peers<= /span>

 

Hi WG,

 

Mutual Authentication is requir= ed between 2 DOTS peers, but then the drafts do not make any suggestions th= at I have found as to how to do it other than referring to EST.<= /span>

 

[TR] No, https://tools.ietf.org/html/draft-ietf-dots-signal-channel-14#sectio= n-7.1 discusses PKI, PSK and RPK and the data channel draft refers to this= section for mutual authentication b/w the DOTS agents.

 

I want to make sure we have a s= et of alternatives in place as a minimum requirement for DOTS vendor intero= perability.

 

What I am planning to put into = place (be more enforcing) in my DOTS implementation – comments welcom= e as well as additional suggestions.

 

PKI

 

Client and Server Certificates = have to be signed by the same CA.  The CA does not need to get exchang= ed during (D)TLS session set up.  The CA does not need to go back to a= well-known root CA.

 

PSK

 

The DOTS client ‘identity= ’ (potentially FQDN of client) is used for validating the client by t= he server, and the DOTS server ‘identity-hint’ (potentially FQD= N of server) is used by the client for validating the server.  Obviously they both share the same PSK!

 

[TR] The “PSK_Identity= 221; and "PSK identity hint" need not be FQDNs of the DOTS client= and server, https://tools.iet= f.org/html/rfc4279#section-5 does not mandate a particular type of iden= tity.

 

-Tiru

 

RPK

 

Nothing in place so far as I ha= ve not worked out how to get OpenSSL to do this for me so far, so have no s= uggestions here.

 

 

 

Regards

 

Jon

--_000_DM5PR16MB1788563B2CB2B40107DBDEB7EA1E0DM5PR16MB1788namp_-- From nobody Wed Jan 3 02:26:54 2018 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 0A9CE12D864 for ; Wed, 3 Jan 2018 02:26:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 p5U-SRlyPZYc for ; Wed, 3 Jan 2018 02:26: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 75E4B12421A for ; Wed, 3 Jan 2018 02:26:50 -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 1eWgFy-0007Tw-8g; Wed, 03 Jan 2018 10:26:46 +0000 From: "Jon Shallow" To: "'Roman Danyliw'" , References: <359EC4B99E040048A7131E0F4E113AFC0131355A04@marathon> In-Reply-To: Date: Wed, 3 Jan 2018 10:26:45 -0000 Message-ID: <0c8a01d3847d$5ae59490$10b0bdb0$@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: AQHdM/Qz99z/7IXDUi62LZwazkCMeAEh8AEto0WCWwA= Archived-At: Subject: Re: [Dots] REMINDER -- WGLC on DOTS 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, 03 Jan 2018 10:26:53 -0000 Version draft-ietf-dots-requirements-10.txt looks good to me and is ready to be moved forward. Thanks to all those who have given input and to all those who have updated the draft accordingly with carefully thought through updates. Regards Jon -----Original Message----- From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of Roman Danyliw Sent: 02 January 2018 21:58 To: dots@ietf.org Subject: Re: [Dots] REMINDER -- WGLC on DOTS Requirements Hello again! Given that some are just returning from their holiday, this WGLC will be extended one more day - till Wednesday, January 3rd. Thanks, Roman > On Jan 2, 2018, at 07:53, Roman Danyliw wrote: > > Hello! > > Happy New Year! The WGLC for the DOTS requirements draft will be closing soon. Please provide any final comments. > > Thanks, > Roman > > -----Original Message----- > From: Roman Danyliw > Sent: Thursday, December 7, 2017 3:51 PM > To: dots@ietf.org > Subject: WGLC on DOTS Requirements > > Hello! > > Consistent with our discussion at the Singapore meeting and with the concurrence of the draft authors, we are starting a working group last call (WGLC) for the DOTS Requirements draft: > > Distributed Denial of Service (DDoS) Open Threat Signaling Requirements > draft-ietf-dots-requirements-08 > https://tools.ietf.org/html/draft-ietf-dots-requirements-08 > > Please send all comments to the DOTS mailing list. > > This WGLC will end on January 2, 2018 (~3 weeks to account for end-of-the-calendar year vacations). > > Thanks, > 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 Wed Jan 3 02:47:27 2018 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 EBE7912D872 for ; Wed, 3 Jan 2018 02:47:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 qt1FEHPN-uPL for ; Wed, 3 Jan 2018 02:47: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 F21C6126579 for ; Wed, 3 Jan 2018 02:47: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 1eWgZs-0007UQ-9C; Wed, 03 Jan 2018 10:47:20 +0000 From: "Jon Shallow" To: "'Konda, Tirumaleswar Reddy'" , References: <0a1201d38161$299ef350$7cdcd9f0$@jpshallow.com> <0b2301d383ad$a8822a40$f9867ec0$@jpshallow.com> <0b4b01d383b0$758f1370$60ad3a50$@jpshallow.com> In-Reply-To: Date: Wed, 3 Jan 2018 10:47:19 -0000 Message-ID: <0c8c01d38480$3a6ba5d0$af42f170$@jpshallow.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0C8D_01D38480.3A6D7A90" X-Mailer: Microsoft Outlook 14.0 Content-Language: en-gb Thread-Index: AQIpdHJXTEWkUmLWfrWfFs+hkFSqvAJ19VeLAlAhTlAB/1BuRQHRwg9pAM+YE+eiatvjcA== Archived-At: Subject: Re: [Dots] Using SNI 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, 03 Jan 2018 10:47:24 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0C8D_01D38480.3A6D7A90 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Tiru, My main goal here is to make sure that we can have DOTS vendor interoperability. As found during my implementation, having certain things in place helps considerably - providing strong hints to the implementer as to what should be available for interoperability helps. Instead of "If TLS client certificate is used to authenticate the DOTS client, the DOTS client MUST include the DOTS server FQDN in server name indication extension (Section 3 of RFC6066)." We could perhaps have "The DOTS client MUST support enabling the use of SNI (Section 3 of RFC6066). When enabled, this SHOULD include the DOTS server FQDN in the server name indication extension." As an aside, I have been able to get my DOTS server to support both PKI and PSK, thus supporting a mix of PKI and PSK DOTS clients being active at the same time (I agree this is not a generally recommended case). This was not done using SNI, but would have been considerably easier to implement if using SNI and the PSK clients talked to psk-dotsserver.somewhere.com and PKI clients talked to pki-dotsserver.somewhere.com - both DNS resolving to the same IP. So being able to use SNI in both the signal and data channels makes sense to me. Regards Jon From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of Konda, Tirumaleswar Reddy Sent: 03 January 2018 07:21 To: Jon Shallow; dots@ietf.org Subject: Re: [Dots] Using SNI Hi Jon, We may want to use "SHOULD" instead of "MUST" in the below line (for example, SNI is not required if the DOTS client and server are in the same enterprise network). -TIru From: Jon Shallow [mailto:supjps-ietf@jpshallow.com] Sent: Tuesday, January 2, 2018 3:30 PM To: Konda, Tirumaleswar Reddy ; dots@ietf.org Subject: RE: [Dots] Using SNI Hi Tiru, That certainly works for me - thanks Regards Jon From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of Konda, Tirumaleswar Reddy Sent: 02 January 2018 09:55 To: Jon Shallow; dots@ietf.org Subject: Re: [Dots] Using SNI Hi Jon, RESTCONF does not mandate client authentication based on TLS client certificate, we can say the following instead: If TLS client certificate is used to authenticate the DOTS client, the DOTS client MUST include the DOTS server FQDN in server name indication extension (Section 3 of RFC6066). Cheers, -Tiru From: Jon Shallow [mailto:supjps-ietf@jpshallow.com] Sent: Tuesday, January 2, 2018 3:10 PM To: Konda, Tirumaleswar Reddy ; dots@ietf.org Subject: RE: [Dots] Using SNI Hi Tiru, I agree that (indirectly through RFC7525 reference) SNI is mandated to be supported (but not necessarily has to be used). However, to guarantee interoperability between different DOTS vendors, I am saying that the use of SNI is a MUST - in particular for the data channel. Regards Jon From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of Konda, Tirumaleswar Reddy Sent: 02 January 2018 08:48 To: Jon Shallow; dots@ietf.org Subject: Re: [Dots] Using SNI Hi Jon, Both signal and data channel drafts refer to RFC7525 for secure use of (D)TLS and RFC7525 mandates TLS implementations to support SNI. I don't see the need to explicitly discuss SNI in these drafts. Regards, -Tiru From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Jon Shallow Sent: Saturday, December 30, 2017 4:57 PM To: dots@ietf.org Subject: [Dots] Using SNI Hi WG, When providing a DOTS server data channel service in my environment, this shares the same ip / port which also provides other services (e.g. GUI / REST server etc.). Even if the Root Discovery points to another IP and or port for the actual data channel activity, the TLS exchanges for the Root Discovery have to correctly work. I suspect that I am not the only DOTS vendor who will have this type of requirement of a single IP providing multiple TLS services. As DOTS requires mutual authentication, this is a different security requirement than required by the GUI environment (DOTS requires client cert to be presented, GUI does not and providing certificates to every GUI client is not a practical option). This can be handled by using SNI by using 2 different FQDNs and requiring the DOTS client to include the DOTS specific FQDN in the TLS Client Hello. Whether the GUI client does or does not (likely does with modern browsers) include a SNI FQDN when connecting to the non DOTS FQDN does not really matter - for DOTS it is recognizing the DOTS specific FQDN and setting up the TLS as appropriate. To make sure interoperability between DOTS vendors, I would like to see something like added to the data channel spec "DOTS clients MUST include the DOTS server FQDN in the TLS Client Hello packet by using Server Name Indication (SNI) RFC 3546". In addition, I think that this would be a good idea as well for the signal draft - thereby giving DOTS vendors the opportunity to host multiple DOTS servers (likely to be different security requirements for their different client) on a single IP / port. Thoughts / comments? Regards Jon ------=_NextPart_000_0C8D_01D38480.3A6D7A90 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Tiru,

 

My main goal here is to = make sure that we can have DOTS vendor interoperability.  As found = during my implementation, having certain things in place helps = considerably – providing strong hints to the implementer as to = what should be available for interoperability = helps.

 

Instead of =

 
“=
If TLS =
client certificate is used to authenticate the DOTS client, the DOTS =
client MUST include the DOTS server FQDN in server name indication =
extension (Section 3 of =
RFC6066).”
 =

We could =
perhaps have
 =

“The =
DOTS client MUST support enabling the use of SNI (Section 3 of =
RFC6066).  When enabled, this SHOULD include the DOTS server FQDN =
in the server name indication =
extension.”
 =

As an =
aside, I have been able to get my DOTS server to support both PKI and =
PSK, thus supporting a mix of PKI and PSK DOTS clients being active at =
the same time (I agree this is not a generally recommended case).  =
This was not done using SNI, but would have been considerably easier to =
implement if using SNI and the PSK clients talked to =
psk-dotsserver.somewhere.com and PKI clients talked to =
pki-dotsserver.somewhere.com – both DNS resolving to the same =
IP.
 =

So being =
able to use SNI in both the signal and data channels makes sense to =
me.

 

Regards

 

Jon

 

From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of = Konda, Tirumaleswar Reddy
Sent: 03 January 2018 = 07:21
To: Jon Shallow; dots@ietf.org
Subject: Re: = [Dots] Using SNI

 

Hi = Jon,

 

We may want to use = “SHOULD” instead of “MUST” in the below line = (for example, SNI is not required if the DOTS client and server are in = the same enterprise network).

 

-TIru

 

From: Jon Shallow [mailto:supjps-ietf@jpshallow.co= m]
Sent: Tuesday, January 2, 2018 3:30 PM
To: = Konda, Tirumaleswar Reddy <TirumaleswarReddy_Kond= a@McAfee.com>; dots@ietf.org
Subject: RE: = [Dots] Using SNI

 

Hi = Tiru,

 

That certainly works for = me – thanks

 

Regards

 

Jon

 

From: Dots [mailto: dots-bounces@ietf.org] On = Behalf Of Konda, Tirumaleswar Reddy
Sent: 02 January 2018 = 09:55
To: Jon Shallow; dots@ietf.org
Subject: Re: = [Dots] Using SNI

 

Hi =
Jon,
 =

RESTCONF =
does not mandate client authentication based on TLS client certificate, =
we can say the following instead:
If TLS =
client certificate is used to authenticate the DOTS client, the DOTS =
client MUST include the DOTS server FQDN in server name indication =
extension (Section 3 of RFC6066).
 =

Cheers,
-Tiru<=
/o:p>
 =

From: Jon Shallow [mailto:supjps-ietf@jpshallow.co= m]
Sent: Tuesday, January 2, 2018 3:10 PM
To: = Konda, Tirumaleswar Reddy <TirumaleswarReddy_Kond= a@McAfee.com>; dots@ietf.org
Subject: RE: = [Dots] Using SNI

 

Hi = Tiru,

 

I agree that (indirectly = through RFC7525 reference) SNI is mandated to be supported (but not = necessarily has to be used).

 

However, to guarantee = interoperability between different DOTS vendors, I am saying that the = use of SNI is a MUST – in particular for the data = channel.

 

Regards

 

Jon

 

From: Dots [mailto: dots-bounces@ietf.org] On = Behalf Of Konda, Tirumaleswar Reddy
Sent: 02 January 2018 = 08:48
To: Jon Shallow; dots@ietf.org
Subject: Re: = [Dots] Using SNI

 

Hi = Jon,

 

Both signal and data channel drafts = refer to RFC7525 for secure use of (D)TLS and RFC7525 mandates TLS = implementations to support SNI. I don’t see the need to explicitly = discuss SNI in these drafts.


Regards,

-Tiru

 

From: Dots [mailto:dots-bounces@ietf.org] = On Behalf Of Jon Shallow
Sent: Saturday, December 30, = 2017 4:57 PM
To: dots@ietf.org
Subject: = [Dots] Using SNI

 

Hi WG,

 

When = providing a DOTS server data channel service in my environment, this = shares the same ip / port which also provides other services (e.g. GUI / = REST server etc.).  Even if the Root Discovery points to another IP = and or port for the actual data channel activity, the TLS exchanges for = the Root Discovery have to correctly work.  I suspect that I am not = the only DOTS vendor who will have this type of requirement of a single = IP providing multiple TLS services.

 

As DOTS = requires mutual authentication, this is a different security requirement = than required by the GUI environment (DOTS requires client cert to be = presented, GUI does not and providing certificates to every GUI client = is not a practical option).

 

This can be = handled by using SNI by using 2 different FQDNs and requiring the DOTS = client to include the DOTS specific FQDN in the TLS Client Hello.  = Whether the GUI client does or does not (likely does with modern = browsers) include a SNI FQDN when connecting to the non DOTS FQDN does = not really matter – for DOTS it is recognizing the DOTS specific = FQDN and setting up the TLS as appropriate.

 

To make sure = interoperability between DOTS vendors, I would like to see something = like added to the data channel spec “DOTS clients MUST include the = DOTS server FQDN in the TLS Client Hello packet by using Server Name = Indication (SNI) RFC 3546”.

 

In addition, = I think that this would be a good idea as well for the signal draft = – thereby giving DOTS vendors the opportunity to host multiple = DOTS servers (likely to be different security requirements for their = different client) on a single IP / port.

 

Thoughts / = comments?

 

Regards

 

Jon

------=_NextPart_000_0C8D_01D38480.3A6D7A90-- From nobody Wed Jan 3 03:27:54 2018 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 DC5C3126CD6 for ; Wed, 3 Jan 2018 03:27:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 dOJnXQXgcpbi for ; Wed, 3 Jan 2018 03:27: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 3E8D4126579 for ; Wed, 3 Jan 2018 03:27:50 -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 1eWhD2-0007Vw-G5; Wed, 03 Jan 2018 11:27:48 +0000 From: "Jon Shallow" To: "'Konda, Tirumaleswar Reddy'" , References: <0bf201d383ed$cdf63970$69e2ac50$@jpshallow.com> In-Reply-To: Date: Wed, 3 Jan 2018 11:27:47 -0000 Message-ID: <0cab01d38485$e1bc09b0$a5341d10$@jpshallow.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0CAC_01D38485.E1BD1B20" X-Mailer: Microsoft Outlook 14.0 Content-Language: en-gb Thread-Index: AQEUNxveIYc4ZCOzHroaiQF/rTb0VAHMTx0JpNIv1IA= Archived-At: Subject: Re: [Dots] Mutual Authentication between DOTS peers 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, 03 Jan 2018 11:27:53 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0CAC_01D38485.E1BD1B20 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Tiru, See inline [Jon] Regards Jon From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of Konda, Tirumaleswar Reddy Sent: 03 January 2018 07:38 To: Jon Shallow; dots@ietf.org Subject: Re: [Dots] Mutual Authentication between DOTS peers Hi Jon, Thanks for the comments, please see inline. From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Jon Shallow Sent: Tuesday, January 2, 2018 10:49 PM To: dots@ietf.org Subject: [Dots] Mutual Authentication between DOTS peers Hi WG, Mutual Authentication is required between 2 DOTS peers, but then the drafts do not make any suggestions that I have found as to how to do it other than referring to EST. [TR] No, https://tools.ietf.org/html/draft-ietf-dots-signal-channel-14#section-7.1 discusses PKI, PSK and RPK and the data channel draft refers to this section for mutual authentication b/w the DOTS agents. [Jon] I think I did not phrase this correctly. I was looking for (and hence defining as a best practice for DOTS) the specifics of what need to be checked (enforced) for mutual authentication. 7.1 does refer to a DOTS server may present a PKIX certificate which the DOTS client then has to verify, but nothing about how the DOTS server verifies the DOTS client. [I should have referred to PKIX in my statement above]. [Jon] My DOTS server for instance (if PKI) requests the Peer Certificate from the DOTS client - if it is not given, not authorized (CN or Subject Alternative Name is not valid) or does not have common CA that signed both the DOTS server and DOTS client certificates, then mutual authentication from the DOTS server perspective fails. [Jon] To me, it is the DOTS client that is most likely to be the rogue element. I want to make sure we have a set of alternatives in place as a minimum requirement for DOTS vendor interoperability. What I am planning to put into place (be more enforcing) in my DOTS implementation - comments welcome as well as additional suggestions. PKI Client and Server Certificates have to be signed by the same CA. The CA does not need to get exchanged during (D)TLS session set up. The CA does not need to go back to a well-known root CA. PSK The DOTS client 'identity' (potentially FQDN of client) is used for validating the client by the server, and the DOTS server 'identity-hint' (potentially FQDN of server) is used by the client for validating the server. Obviously they both share the same PSK! [TR] The "PSK_Identity" and "PSK identity hint" need not be FQDNs of the DOTS client and server, https://tools.ietf.org/html/rfc4279#section-5 does not mandate a particular type of identity. [Jon] The next paragraph goes on to state "However, the TLS client and server clearly have to agree on the identities and keys to be used." [Jon] Again for DOTS vendor interoperability, I think we should indicate what is acceptable / best practice for DOTS. [Jon] While the DOTS server and DOTS client may be in the same client domain, it is possible that different DOTS vendors are supplying different components. -Tiru RPK Nothing in place so far as I have not worked out how to get OpenSSL to do this for me so far, so have no suggestions here. Regards Jon ------=_NextPart_000_0CAC_01D38485.E1BD1B20 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Tiru,

 

See inline = [Jon]

 

Regards

 

Jon

 

From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of = Konda, Tirumaleswar Reddy
Sent: 03 January 2018 = 07:38
To: Jon Shallow; dots@ietf.org
Subject: Re: = [Dots] Mutual Authentication between DOTS = peers

 

Hi = Jon,

 

Thanks for the comments, please see = inline.

 

From: Dots [mailto:dots-bounces@ietf.org] = On Behalf Of Jon Shallow
Sent: Tuesday, January 2, 2018 = 10:49 PM
To: dots@ietf.org
Subject: = [Dots] Mutual Authentication between DOTS = peers

 

Hi = WG,

 

Mutual Authentication is required between 2 DOTS = peers, but then the drafts do not make any suggestions that I have found = as to how to do it other than referring to EST.

 

[TR] No, https://tools.ietf.org/html/draft-ietf-dots-signal-channel-1= 4#section-7.1 discusses PKI, PSK = and RPK and the data channel draft refers to this section for mutual = authentication b/w the DOTS agents.

 

[Jon] I = think I did not phrase this correctly.  I was looking for (and = hence defining as a best practice for DOTS) the specifics of what need = to be checked (enforced) for mutual authentication. 7.1 does refer to a = DOTS server may present a PKIX certificate which the DOTS client then = has to verify, but nothing about how the DOTS server verifies the DOTS = client.  [I should have referred to PKIX in my statement = above].

 

[Jon] My = DOTS server for instance (if PKI) requests the Peer Certificate from the = DOTS client – if it is not given, not authorized (CN or Subject = Alternative Name is not valid) or does not have common CA that signed = both the DOTS server and DOTS client certificates, then mutual = authentication from the DOTS server perspective = fails.

 

[Jon] To = me, it is the DOTS client that is most likely to be the rogue = element.

=

 

I want to = make sure we have a set of alternatives in place as a minimum = requirement for DOTS vendor interoperability.

 

What I am = planning to put into place (be more enforcing) in my DOTS implementation = – comments welcome as well as additional = suggestions.

 

PKI

 

Client and = Server Certificates have to be signed by the same CA.  The CA does = not need to get exchanged during (D)TLS session set up.  The CA = does not need to go back to a well-known root CA.

 

PSK

 

The DOTS = client ‘identity’ (potentially FQDN of client) is used for = validating the client by the server, and the DOTS server = ‘identity-hint’ (potentially FQDN of server) is used by the = client for validating the server.  Obviously they both share the = same PSK!

 

[TR] The “PSK_Identity” and "PSK = identity hint" need not be FQDNs of the DOTS client and server, https://tools.ietf= .org/html/rfc4279#section-5 does not mandate a particular type of = identity.

[Jon] The next paragraph goes on to state = “However, the TLS client and server clearly have to agree on the = identities and keys to be used.”

 

[Jon] Again for DOTS = vendor interoperability, I think we should indicate what is acceptable / = best practice for DOTS.

[Jon] While the DOTS server and DOTS client may = be in the same client domain, it is possible that different DOTS vendors = are supplying different components.

 

-Tiru

 

RPK

 

Nothing in = place so far as I have not worked out how to get OpenSSL to do this for = me so far, so have no suggestions here.

 

 

 

Regards

 

Jon

------=_NextPart_000_0CAC_01D38485.E1BD1B20-- From nobody Wed Jan 3 05:14:15 2018 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 EA1FC127023 for ; Wed, 3 Jan 2018 05:14:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 aANWmHDycDMs for ; Wed, 3 Jan 2018 05:14:12 -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 755A81201F8 for ; Wed, 3 Jan 2018 05:14:12 -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 1eWiry-0007ZG-Sv for ietf-supjps-dots@ietf.org; Wed, 03 Jan 2018 13:14:10 +0000 From: "Jon Shallow" To: Date: Wed, 3 Jan 2018 13:14:09 -0000 Message-ID: <0ccd01d38494$bde6eb90$39b4c2b0$@jpshallow.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0CCE_01D38494.BDE787D0" X-Mailer: Microsoft Outlook 14.0 Content-Language: en-gb Thread-Index: AdOElLupXJwi3futTSeJ+aMxa41Elg== Archived-At: Subject: [Dots] Clarity in use of ampersand in data channel 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, 03 Jan 2018 13:14:14 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0CCE_01D38494.BDE787D0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi All, Should we be using & as a separator in the namespace-uri of a RESTCONF request? For example, in 7.3. Remove Filtering Rules, we have DELETE /restconf/data/ietf-dots-data-channel:access-lists\ /client-identifier=dz6pHjaADkaFTbjr0JGBpw\ /acl-name=sample-ipv4-acl&\ acl-type=ipv4-acl HTTP/1.1 Host: {host}:{port} Where there is ./acl-name=sample-ipv4-acl&acl-type=ipv4-acl . I understand the intent of this as acl-name= and acl-type= are an associated pair, but in the uri path should this really be ./acl-name=sample-ipv4-acl/acl-type=ipv4-acl ? We have separated out .. /client-identifier=dz6pHjaADkaFTbjr0JGBpw/.. as a separate path component, so it makes sense to me to also use / instead of & for splitting out acl-name= and acl-type=. NOTE: we need to be careful about defining parameter ordering here in the uri. Although DOTS does not use such YANG parameter name format, it would appear that, for example, "bill&joe" is a valid entity in its own rights, so using & as a parameter separator could be problematic.. RFC8040 only has / separators prior to a ? in its examples. Comments welcome. Regards Jon ------=_NextPart_000_0CCE_01D38494.BDE787D0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi = All,

 

Should we be using & as a separator in the = namespace-uri of a RESTCONF request?

 

For example, = in 7.3. Remove Filtering Rules, we have

 

     DELETE = /restconf/data/ietf-dots-data-channel:access-lists\

         &= nbsp;  /client-identifier=3Ddz6pHjaADkaFTbjr0JGBpw\<= /p>

         &= nbsp;  /acl-name=3Dsample-ipv4-acl&\

         &= nbsp;  acl-type=3Dipv4-acl HTTP/1.1

     Host: = {host}:{port}

 

Where there is = …/acl-name=3Dsample-ipv4-acl&acl-type=3Dipv4-acl .  I = understand the intent of this as acl-name=3D and acl-type=3D are an = associated pair, but in the uri path should this really be = …/acl-name=3Dsample-ipv4-acl/acl-type=3Dipv4-acl = ?

 

We have separated out .. = /client-identifier=3Ddz6pHjaADkaFTbjr0JGBpw/.. as a separate path = component, so it makes sense to me to also use / instead of & for = splitting out acl-name=3D and acl-type=3D.  NOTE: we need to be = careful about defining parameter ordering here in the = uri.

 

Although DOTS does not use such YANG parameter name = format, it would appear that, for example, “bill&joe” is = a valid entity in its own rights, so using & as a parameter = separator could be problematic..

 

RFC8040 only = has / separators prior to a ? in its examples.

 

Comments = welcome.

 

Regards

 

Jon

 

 

------=_NextPart_000_0CCE_01D38494.BDE787D0-- From nobody Wed Jan 3 14:33:13 2018 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 A1D7D12D7ED for ; Wed, 3 Jan 2018 14:33:09 -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 uYCNR0LzA2bh for ; Wed, 3 Jan 2018 14:33:00 -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 AC4D7127698 for ; Wed, 3 Jan 2018 14:33:00 -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 w03MWxB2011635 for ; Wed, 3 Jan 2018 17:32:59 -0500 DKIM-Filter: OpenDKIM Filter v2.11.0 veto.sei.cmu.edu w03MWxB2011635 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cert.org; s=yc2bmwvrj62m; t=1515018779; bh=+Xxxpp2tWO5qM4UH3sggbKnwYA0c07lSNt3REEiZRHs=; h=From:To:Subject:Date:From; b=miIT8cMYmDfBVulH0b/YvwQYWU37D8cC8brvEjvbyoFuy7Paiedof9lLHb2VFn0ai iqZaRDCZjKs3qlJmzBZN1fJ+PFhl87HRW5m866Od+L37JTLeCQewctNoE8xvr5UoDk xcJ6cNfe9Tk9dZ8Gg8pfpLU5CxIJCb4EyPPm56PE= Received: from CASSINA.ad.sei.cmu.edu (cassina.ad.sei.cmu.edu [10.64.28.249]) by korb.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id w03MWudf026240 for ; Wed, 3 Jan 2018 17:32:56 -0500 Received: from MARATHON.ad.sei.cmu.edu ([10.64.28.250]) by CASSINA.ad.sei.cmu.edu ([10.64.28.249]) with mapi id 14.03.0361.001; Wed, 3 Jan 2018 17:32:56 -0500 From: Roman Danyliw To: "dots@ietf.org" Thread-Topic: Feedback on draft-ietf-dots-requirements Thread-Index: AdOE4a/XR+KnbzsFQl+L7JY1uUa37w== Date: Wed, 3 Jan 2018 22:32:55 +0000 Message-ID: <359EC4B99E040048A7131E0F4E113AFC0131356BB5@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] Feedback on draft-ietf-dots-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, 03 Jan 2018 22:33:10 -0000 Hello! (chair hat off) The following is feedback for the WGLC on -09 of draft-ietf-dots-requiremen= ts. Even with the -10 update, these should apply. Other than the feedback= below, I believe the draft is ready to proceed. (1) Abstract. Editorial. - "This document defines the requirements for the Distributed Denial of Ser= vice (DDoS) Open Threat Signaling (DOTS) protocols coordinating attack resp= onse against DDoS attacks." + "This document defines the requirements for the Distributed Denial of Ser= vice (DDoS) Open Threat Signaling (DOTS) protocols that enable the coordina= tion of and response to DDoS attacks." (2) Section 1.1, paragraph 1, Editorial. - Distributed Denial of Service (DDoS) attacks continue to plague network operators around the globe, from Tier-1 service providers on down to enterprises and small businesses. Attack scale and frequency similarly have continued to increase, in part as a result of software vulnerabilities leading to reflection and amplification attacks. High-volume attacks saturating inbound links are now common, and the impact of larger-scale attacks attract the attention of international press agencies. + Distributed Denial of Service (DDoS) attacks plague network operators at service providers and down to enterprises of all sizes. =20 High-volume attacks saturating inbound links are now common. =20 Similarly, attack scale and frequency have continued to increase. (3) Section 1.1, paragraph 2, Editorial. - The greater impact of contemporary DDoS attacks has led to increased focus on coordinated attack response. Many institutions and enterprises lack the resources or expertise to operate on-premises attack mitigation solutions themselves, or simply find themselves constrained by local bandwidth limitations. To address such gaps, security service providers have begun to offer on-demand traffic scrubbing services, which aim to separate the DDoS traffic from legitimate traffic and forward only the latter. Today each such service offers a proprietary invocation interface for subscribers to request attack mitigation, tying subscribers to proprietary signaling implementations while also limiting the subset of network elements capable of participating in the attack mitigation. As a result of signaling interface incompatibility, attack responses may be fragmentary or otherwise incomplete, leaving key players in the attack path unable to assist in the defense. + The prevalence and impact of these DDoS attacks has led to an increased focus on coordinated attack response. However, many enterprises=20 lack the resources or expertise to operate on-premises attack mitigation solutions themselves, or are constrained by local bandwidth limitations. To address such gaps, service providers have begun to offer on-demand traffic scrubbing services, which aim to separate the DDoS attack traffic from legitimate traffic and forward only the latter. =20 Today, these services offers a proprietary interface for subscribers to request attack mitigation. Such proprietary interfaces tie a subscriber= =20 to a service while also limiting the network elements capable of participating in the attack mitigation. As a result of signaling interface incompatibility, attack responses may be fragmented or otherwise incomplete, leaving operators in the attack path unable to assist in the defense. (4) Section 1.1, paragraph 3, Editorial (simplification) - The lack of a common method to coordinate a real-time response among involved actors and network domains inhibits the speed and effectiveness of DDoS attack mitigation. This document describes the required characteristics of protocols enabling requests for DDoS attack mitigation, reducing attack impact and leading to more efficient defensive strategies. + A standardized method to coordinate a real-time response among involved o= perators will increase the speed and effectiveness of DDoS attack mitigatio= n, and reduce the impact of these attacks. This document describes the req= uired characteristics of protocols that enable attack coordination and miti= gation of DDoS attacks. (5) Section 1.1, paragraph 4, Editorial (simplification) - DDoS Open Threat Signaling (DOTS) communicates the need for defensive action in anticipation of or in response to an attack, but does not dictate the form any defensive action takes. DOTS supplements calls for help with pertinent details about the detected attack, allowing entities participating in DOTS to form ad hoc, adaptive alliances against DDoS attacks as described in the DOTS use cases [I-D.ietf-dots-use-cases]. The requirements in this document are derived from those use cases and [I-D.ietf-dots-architecture]. + DDoS Open Threat Signaling (DOTS) communicates the need for defensive ac= tion in anticipation of or in response to an attack, but does not dictate t= he implementation of these actions. The requirements in this document are = derived from [I-D.ietf-dots-use-cases] and [I-D.ietf-dots-architecture]. (6) Section 1.2, Terminology, DDoS. Editorial (subject-verb agreement): - A distributed denial-of-service attack, in which traffic originating from= multiple sources are ... =20 + A distributed denial-of-service attack, in which traffic originating from= multiple sources is ... =20 (7) Section 1.2, Terminology, DDoS. Editorial (don't redefine attack targe= t): - DDoS attacks are intended to cause a negative impact on the availability = of servers, services, applications, and/or other functionality of an attac= k target. =20 + DDoS attacks are intended to cause a negative impact on the availability = and/or other functionality of an attack target. =20 (8) Section 1.2, Terminology, Mitigation. The difference between counterme= asure and mitigation isn't clear to me given the current text. (9) Section 1.2, Terminology, Mitigator. Editorial (clarity) - ... For the purposes of this document, this entity is a black box capable of mitigation, making no assumptions about availability or design of countermeasures, nor about the programmable interface(s) between this entity and other network elements. =20 + The means by which this entity performs these mitigations and how they ar= e requested of it are out of scope. (10) Section 1.2, Terminology, Mitigator. In the sentence "The mitigator a= nd invoked DOTS server are assumed to belong to the same administrative ent= ity", what is an "invoked server" isn't clear in the text. (11) Section 1.2, Terminology, DOTS server. Editorial. - A DOTS server may also be colocated with a mitigator. + A DOTS server may be colocated with a mitigator. (12) Section 1.2, Terminology, DOTS server. In the sentence, " A DOTS serv= er may also be colocated with a mitigator", what does "collocated" mean in= this context? (13) Section 1.2, Terminology, DOTS gateway. Editorial (clarity) - A DOTS-aware software module resulting from the logical concatenation of a DOTS server and a DOTS client, analogous to a Session Initiation Protocol (SIP) [RFC3261] Back- to-Back User Agent (B2BUA) [RFC7092]. + A DOTS-aware software module resulting from the logical concatenation of = the functionality of a DOTS server and a DOTS client into a single DOTS age= nt. This functionality is analogous to a Session Initiation Protocol (SIP)= [RFC3261] Back-to-Back User Agent (B2BUA) [RFC7092]. (14) Section 1.2 Terminology, signal channel. Editorial - A bidirectional, mutually authenticated communication channel between two DOTS agents characterized by resilience even in conditions leading to severe packet loss, such as a volumetric DDoS attack causing network congestion. + A bidirectional, mutually authenticated communication channel between DOT= S agents that is resilient even in conditions leading to severe packet loss= , such as a volumetric DDoS attack causing network congestion. (15) Section 1.2, Terminology, DOTS signal. From this definition, it isn't= clear if a DOTS signal is part of the signal channel. (16) Section 1.2, Terminology, Data channel. Why is the terminology "secur= e communication layer" used here when the definition of the signal channel = uses "...bidirectional, mutually authenticated communication channel"? I w= ould recommend using the same language in both places. (17) Section 1.2, Terminology, Blacklist. The sentence " A filter list of = addresses, prefixes, and/or other identifiers ..." seems to redefine filter= . I recommend: - A filter list of addresses, prefixes, and/or other identifiers indicating ... + A list of filters indicating ... (18) Section 1.2, Terminology, Whitelist. Unlike the definition of a black= list, this definition doesn't used the word filter at all. Perhaps these d= efinitions should be consistent. - A list of addresses, prefixes , and/or other identifiers indicating ... + A list of filters indicating ... (19) Section 2, Requirements. In "The DOTS protocol must at a minimum make= it possible for a DOTS client to request a mitigator's aid mounting a defe= nse, coordinated by a DOTS server, against a suspected attack, signaling within or betwee= n domains as requested by local operators.", it seems odd to say that a DOT= S client is requesting a mitigators aid. Isn't the interface used by a cli= ent a DOTS server? The rest is opaque to the client. =20 (20) Section 2, Requirements. Per the last sentence of the second paragrap= h, "Furthermore, multi-homing considerations are out of scope." Does that= mean that the technique for selecting the appropriate server in a multi-ho= med environment is out of scope. If so, I'd recommend being more explicit. (21) Section 2, Requirements. Editorial. - Regular feedback between DOTS clients and DOTS servers supplement the defensive alliance by maintaining a common understanding of the DOTS agents' health and activity. Bidirectional communication between DOTS clients and DOTS servers is therefore critical. + Regular communication between DOTS clients and servers enable a common = understanding of the DOTS agents' health and activity. =20 (22) Section 2, Requirements. Editorial. - Operators of peer DOTS-enabled domains may enable quality- or class- of-service traffic tagging to increase the probability of successful DOTS signal delivery, but DOTS does not require such policies be in place. The DOTS solution indeed must be viable especially in their absence. + Operators of peer DOTS-enabled domains may enable quality- or class-of-= service traffic tagging to increase the probability of successful DOTS sign= al delivery, but DOTS does not require such policies be in place and should= be viable in their absence (23) Section 2, Requirements. Per the paragraph, "On the other hand, DOTS = must include protections ensuring message confidentiality, integrity and au= thenticity to keep the protocol from ...", isn't the majority of this conte= nt already covered in SEC-001, SEC-002, SEC-003? (24) Section 2, Requirements. Editorial. - The DOTS server and client must also have some common method of defining the scope of any mitigation performed by a mitigator, as well as making adjustments to other commonly configurable features, such as targeted port numbers, exchanging black- and white-lists, and so on.=20 + The DOTS server and client must also have some standardized method of de= fining the scope of any mitigation; and negotiating related mitigation comm= unication and actions and communications. (25) Section 2.1, GEN-001. Editorial. - Protocols and data models developed as part of DOTS MUST be extensible in order to keep DOTS adaptable to future operational and proprietary DDoS defenses. + Protocols and data models developed as part of DOTS MUST be extensible in order to keep DOTS adaptable to future operational and proprietary DDoS practices. (26) Section 2.1, GEN-002. Editorial. - The signaling protocol MUST be designed to maximize the probability of signal delivery even under the severely constrained network conditions imposed by ... + The signaling protocol MUST be designed to maximize the probability of signal delivery even under the severely constrained network conditions caused by ... (27) Section 2.1, GEN-003. Editorial. - To support peer health detection, to maintain an open signal channel, and to increase the probability of signal delivery during an attack, ... + To support peer health detection,=20 maintain an open signal channel, and increase the probability of signal delivery during an attack, ... (28) Section 2.1, GEN-003. Is it an "open signal channel" or an "active si= gnal channel"? (29) Section 2.2, SIG-003. "The heartbeat interval during active mitigatio= n is not specified ..." Does that mean in this draft, or that is isn't spe= cified in the protocol drafts? I ask be cause a default value is specified= in the protocol draft. (30) Section 2.2, SIG-003. Per "DOTS servers SHOULD monitor the attack, us= ing feedback from the mitigator and other available sources, and MAY use th= e absence of attack traffic and lack of client heartbeats as an indication = the signal channel is defunct.", I have some concern that this is a "SHOUL= D". This indicates that a protocol mechanism needs to be specified for int= eracting with the mitigator -- isn't that out of scope for DOTS? (31) Section 2.2, SIG-004. Per "DOTS clients MAY attempt abbreviated secur= ity negotiation methods supported by the protocol, such as DTLS session res= umption, but MUST be prepared to negotiate new security state with the redi= rection target DOTS server.", I have some concerns that abbreviated securit= y negotiation is a "MAY" without even knowing what the chosen protocol migh= t be (and the assumption in the abbreviated negotiation of this unknown pro= tocol). I recommend removing or softening this language. (32) Section 2.2, SIG-004. Editorial. - Due to the increased likelihood of packet loss caused by link congestion during an attack, DOTS servers SHOULD NOT redirect while mitigation is enabled during an active attack against a target in the DOTS client's domain. + Due to the increased likelihood of packet loss caused by link congestion = during an attack, DOTS servers SHOULD NOT redirect active attack against a = target in the DOTS client's domain while a mitigation is enabled. (33) Section 2.2, SIG-005. Editorial (clarity) - DOTS servers MUST send mitigation request status in response to granted DOTS clients requests for mitigation. + DOTS servers MUST send status to the DOTS clients about mitigation reques= ts=20 (34) Section 2.2., SIG-005. Per, "For example, if there is a financial rel= ationship between the DOTS client and server domains, the DOTS client cease= s incurring cost at this point.", I feel that this crosses too much into op= erational matters. I recommend removal. (35) Section 2.2, SIG-006. Editorial. - DOTS servers MUST support mitigation lifetimes, ... + DOTS servers MUST support mitigations for a negotiated time interval or l= ifetime, ... (36) Section 2.2, SIG-009. Per "Multiple DOTS clients controlled by a sing= le administrative entity may send conflicting mitigation requests for pools= of protected resources as a result of misconfiguration, ...", what are "p= ools of protected resources"? (37) Section 2.2, SIG-010. Per "Regardless of transport, DOTS protocols MU= ST follow established best common practices (BCPs) for NAT traversal.", whi= ch BCPs to follow as a "MUST" aren't clear (unless you just meant RFC8085?)= . (38) Section 2.3, Data Channel Requirement. As a style note, this section,= unlike the signal channel section has a list of un-numbered requirements i= n the introduction. (39) Section 2.3, Data Channel Requirement. Editorial. - Unlike the signal channel, which must operate nominally even when confronted with signal degradation due to significant packet loss, the data channel is not expected to be constructed to deal with attack conditions. + Unlike the signal channel, the data channel is not expected to operate un= der with attack conditions. (40) Section 2.3, Data Channel Requirement. Per "The DOTS data channel pro= tocol MUST be extensible.", isn't this thinking already stated in GEN-001? (41) Section 2.3, Data Channel Requirement. Per "We anticipate the data ch= annel will be used for such purposes as configuration or resource discovery= . ...", isn't this statement mostly covered in GEN-004? Could it be merged= there instead? (42) Section 2.3, Data Channel Requirement. Per "The transactional nature = of such data exchanges suggests a separate set of requirements for the data= channel, while the potentially sensitive content sent between DOTS agents = requires extra precautions to ensure data privacy and authenticity.", isn't= this statement the same as DATA-002? (43) Section 2.3, DATA-002. Concur with the requirement. Does the signal = channel need an analogous requirement? (44) Section 2.3, DATA-002. Some of these statements seem to overlap with = SEC-001 and SEC-002, especially with regard to the need for confidentiality= and authentication. (45) Section 2.3, DATA-003. Editorial. - To help meet the general and signal channel requirements in Sections 2.2, DOTS server ... + To help meet the general and signal channel requirements in Sections 2.1 = and 2.2, DOTS server ... (46) Section 2.4, SEC-001 and SEC-002. Editorial. s/industry best practices/IETF best practices/ (47) Section 2.5, Data Model Requirements. - The value of DOTS is in standardizing a mechanism to permit elements, networks or domains under threat of DDoS attack to request aid mitigating the effects of any such attack. A well-structured DOTS data model is therefore critical to the development of successful DOTS protocols. + A well-structured DOTS data model is critical to the development of succe= ssful DOTS protocols. (48) Section 2.5, DM-001: Per " The data model structure for the DOTS proto= col may be described by a single module, or be divided into related collec= tions of hierarchical modules and sub-modules.", should this be a "MAY" (no= t a "may")? (49) Section 4, Security considerations. I'd recommend (a) explicitly say = that this draft doesn't have its own security considerations but is used to= inform future protocols under development; and (b) discuss the bulleted at= tacks in a bit more detail. Regards, Roman From nobody Wed Jan 3 17:56:38 2018 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 0F4ED12D7F0 for ; Wed, 3 Jan 2018 17:56:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 HcY1sd9xXCcy for ; Wed, 3 Jan 2018 17:56:33 -0800 (PST) Received: from guri.nttv6.jp (guri.nttv6.jp [115.69.228.140]) by ietfa.amsl.com (Postfix) with ESMTP id 66CDA124D37 for ; Wed, 3 Jan 2018 17:56:33 -0800 (PST) Received: from z.nttv6.jp (z.nttv6.jp [192.168.8.15]) by guri.nttv6.jp (NTTv6MTA) with ESMTP id 0D7C825F692; Thu, 4 Jan 2018 10:56:31 +0900 (JST) Received: from SR2-nishizuka.lv4.nttv6.jp (fujiko.nttv6.jp [115.69.228.141]) by z.nttv6.jp (NTTv6MTA) with ESMTP id F067E76350E; Thu, 4 Jan 2018 10:56:30 +0900 (JST) To: Jon Shallow , "'Konda, Tirumaleswar Reddy'" , dots@ietf.org References: <094801d3801e$f7ab01b0$e7010510$@jpshallow.com> <099601d38096$487c9410$d975bc30$@jpshallow.com> <0b7a01d383bb$aba5f720$02f1e560$@jpshallow.com> <0b8501d383be$df5ec030$9e1c4090$@jpshallow.com> <0bb401d383d2$cbbdc9e0$63395da0$@jpshallow.com> <0be801d383e1$58e74c70$0ab5e550$@jpshallow.com> From: kaname nishizuka Message-ID: <7f8ee53d-7bd2-91a1-6784-e5118bb74c50@nttv6.jp> Date: Thu, 4 Jan 2018 10:56:30 +0900 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: <0be801d383e1$58e74c70$0ab5e550$@jpshallow.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [Dots] [signal-channel-draft] CoAP libraries have problems with the DOTS spec 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, 04 Jan 2018 01:56:37 -0000 Hi Jon, Tiru, Sorry for late reply. I was out for the New Year Holidays. I've read all of the replies and I think we are going to a right direction. thanks, Kaname On 2018/01/03 0:50, Jon Shallow wrote: > Hi Tiru, > > Thanks - I think we are good to go with this one. Thanks Kaname for > pointing this issue out. > > Regards > > Jon > > -----Original Message----- > From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of Konda, Tirumaleswar > Reddy > Sent: 02 January 2018 15:10 > To: Jon Shallow; dots@ietf.org; kaname nishizuka > Subject: Re: [Dots] [signal-channel-draft] CoAP libraries have problems with > the DOTS spec > >> -----Original Message----- >> From: Jon Shallow [mailto:supjps-ietf@jpshallow.com] >> Sent: Tuesday, January 2, 2018 7:36 PM >> To: Konda, Tirumaleswar Reddy >> ; dots@ietf.org; kaname nishizuka >> >> Subject: RE: [Dots] [signal-channel-draft] CoAP libraries have >> problems with the DOTS spec >> >> Hi Tiru, >> >> See inline [Jon4] >> >> Regards >> >> Jon >> >>>>> -----Original Message----- >>>>> From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of kaname >>>>> nishizuka >>>>> Sent: 28 December 2017 10:02 >>>>> To: dots@ietf.org >>>>> Subject: [Dots] [signal-channel-draft] CoAP libraries have >>>>> problems with the DOTS spec >>>>> >>>>> Hi, >>>>> >>>>> Last week, Jon and I did the second interoperability test based >>>>> on the >>>>> -13 version of the signal channel draft. >>>>> We made significant improvements of each implementation. Several >>>>> feedbacks to the WG have been made by Jon already. >>>>> >>>>> Based on the experience, I encountered the problems between CoAP >>>>> libraries and the specification of the DOTS. >>>>> >>>>> 1. resource identification of GET methods. >>>>> >>>>> In signal channel spec, the target resource in GET method is >>>>> identified in the BODY of the message, that is mitigation-id >>>>> (and >>>> client-identifier). >>>>> However, CoAP libraries, at least we investigated, only see the >>>>> Request URI, so it cannot locate the resource because it doesn't >>>>> see the >>>> BODY. >>>>> So the question is, why does the DOTS spec use CoAP Body for >>>>> resource identifier? >>>>> >>>>> [Jon] A very good question. I had just assumed that this was >>>>> the way to do it, but had noted that this was not done when >>>>> using HTTP >> etc. >>>>> and so was different. See later comments >>>>> >>>>> Most of CoAP libraries only support request URI in CoAP >>>>> GET/observe, which is the spec from RFC7252. >>>>> https://tools.ietf.org/html/rfc7252 >>>>> 5.8.1.GET >>>>> The GET method retrieves a representation for the information > that >>>>> currently corresponds to the resource identified by the >>>>> request >> URI. >>>>> [Jon] RFC 7252 states also >>>>> 5.10.1. Uri-Host, Uri-Port, Uri-Path, and Uri-Query >>>>> >>>>> The Uri-Host, Uri-Port, Uri-Path, and Uri-Query Options are used > to >>>>> specify the target resource of a request to a CoAP origin server. >>>>> [Jon] So it looks like the target resource should only be in >>>>> Uri-Path and/or Uri-Query. >>>>> [Jon] In my CoAP Library, I have to define each individual >>>>> resource (it does a lookup against a hash of the complete Uri to >>>>> find whether the resource is known or not), so, when say >>>>> mitigation-id=2 is added, I need to register the resource >>>>> .well-known/dots/v1/mitigate/migration-is=2 with an associated >>>>> handler. This is not difficult to do, but potentially could >>>>> consume a lot >>>> of DOTS server resources if many mitigations are active. >>>>> [Jon] Doing it as a Query Option I think is my preference - > Comments? >>>>> [Jon] The same is true for GET signal configuration as well. >>>> Yes, will update draft to use Query option for GET method. >>>> [Jon2] This works for me, but does not feel right when this is >>>> extended for "PUT .../mitigate Query mitigation-id-2" to create >>>> the mitigation-id. I think that the complete "resource" should be >>>> specified for consistency and just leave the c=? as being the >>>> required >>> valid Query option. >>> >>> PUT method does not need to convey the Query Option (for example >>> please see https://tools.ietf.org/html/rfc7967#section-4.1.1, the >>> resource is specified in the URI-path option itself). >>> >>> [Jon3] Agreed - and think that the full resource needs to be >>> specified for the DELETE (need to fix my libcoap library to not >>> respond with 4.04 if resource does not exist as per RFC7252) as well >>> that the GET. However, "GET .../mitigate" should return all current >>> mitigations if the mitigation-id is not specified in the Uri-Path.. >> Yes. >> >> [Jon4] mitigation-id needs to be included as a parameter in the body >> in response to "GET .../mitigate". I assume for consistency, it >> should also be returned as a parameter for "GET > .../mitigate/mitigation-id=ZZ". > > Yes. > >> [Jon4] So when doing "PUT .../mitigate/mitigation-id=ZZ", do we also >> include in the PUT data body the parameter mitigation-id = ZZ? What >> happens if they are different? > I don't see the need to convey "mitigation-id=ZZ" in the PUT body if it is > conveyed in the Uri-Path. > >>> [Jon3] The same is for configuration (GET, PUT & DELETE) - which >>> then begs the question - do we really need "session-id" ? >> session-id is introduced to handle out-of-order delivery of PUT >> requests, the PUT request with a higher numeric 'session-id' value >> overrides the DOTS signal channel session configuration data installed >> by a PUT request with a lower numeric 'session-id' value. >> >> [Jon4] Understood. And the lesser session-id resource would be no >> more (i.e. the resource is deleted). >> [Jon4] As this signal configuration is only defining a specific >> session (there may be multiple sessions) between 2 DOTS peers, > "client-identifier" >> (or "request-nonce") are not really needed to be supported as a part >> of the resource. > Yes. > >> [Jon4] We need a "GET .../config" to get the server sides (initial) >> notion of what is supported for configuration. We would then support >> "GET .../config/session-id=YY" (only can be done following a PUT >> otherwise session-id is unknown). The PUT would definitely have to be >> "PUT ../config/session-id-YY". The DELETE would be either "DELETE >> .../config" or "DELETE .../config/session-id=YY" where both of them >> reset the signal configuration back to the defaults. "DELETE >> .../config" would get rid of any session-ids for that particular session. > Agreed. > > -Tiru > >> -Tiru >> >>>>> [Jon1] I am now leaning towards doing it in the Uri-Path but >>>>> still not >>>> sure. >>>>> The CoAP layer responds with a 4.04 with my CoAP library if the >>>>> resource >>>>> (Uri-Path) is unknown. >>>>> [Jon1] We need to define the order in the path - e.g. >>>>> client-identifier (or request-none etc. if that is accepted) >>>>> then mitigation-id, so that resources are built consistently >>>>> from a mitigation >>>> request. >>>> >>>> Agreed. >>>> [Jon2] then something similar to the above specifying ordering >>>> needs to be put into the draft. >>> Yes. >>> >>>>> [Jon1] However doing this means we also need to include PUT and >>>>> DELETE with the resource specified in the Uri-Path. My library >>>>> then runs into a chicken and egg situation with PUT - the PUT is >>>>> defining the new resource, but as the resource is not defined >>>>> (yet) in the CoAP layer, it gets rejected with a >>>>> 4.04 in the CoAP layer (as mentioned above). The way around >>>>> this is to use POST to create new mitigation requests (and will >>>>> respond with appropriate Location-Path to give the new UI) and >>>>> PUT if we are refreshing >>>> the resource. >>>>> [Jon1] Thoughts? >>>> PUT can also be used to create a new resource, and the draft uses >>>> PUT instead of POST because it is idempotent and during a >>>> volumetric DDoS attack saturating the incoming link to the DOTS >>>> client, DOTS client will most likely not receive the server-side >>>> responses. Is this an >>> implementation bug ? >>>> [Jon2] I agree that it is a bug in the libcoap I am using >>>> [https://github.com/obgm/libcoap]. RFC7252 5.8.3. PUT states "The >>>> PUT method requests that the resource identified by the request >>>> URI be updated or created". I can try to fix the library to keep >>>> on stripping off the last UriPath and then doing a hash lookup on >>>> the sub path until a match is found in the case of doing a PUT. >>>> It would then (in my case - not needed in the >>>> draft) be the responsibility of creating a new resource if needed >>>> in the DOTS layer. >>> Thanks. >>> >>> Cheers, >>> Tiru >>> >>>> -Tiru >>>> >>>>> 2. Confirmable vs NonConfirmable at Mitigation Request >>>>> >>>>> A CoAP library (dustin/go-coap) stops listening right after >>>>> sending out the NonConfirmable message because NonConfirmable >>>>> messages do >>>> not >>>>> require acknowledgements. >>>>> >>>>> [Jon] As there is a good chance during attack scenarios that >>>>> responses may not be able to get back, it makes sense to me that >>>>> these "GET >>>> mitigation" >>>>> requests are non-confirmable. Certainly "PUT mitigation" needs >>>>> to be thought of as a one way signal. There are times that the >>>>> client has to run "blind" during attack scenarios. >>>>> [Jon]If they were confirmable, then the request will get sent >>>>> multiple times to the DOTS server - which could be handled by >>>>> the server, but then the confirmable responses would retried >>>>> whilst sending back to the DOTS client and eventually retry >>>>> timeout. A large scale attack could swamp a DOTS server with >>>>> all the yet to be confirmed confirmable >>>> responses. >>>>> [Jon] As per RFC7252 "2.2. Request/Response Model", a response >>>>> to a >>>>> non- confirmable request is expected to be handled as in:- >>>>> If a request is sent in a Non-confirmable message, then the >> response >>>>> is sent using a new Non-confirmable message, although the >>>>> server >> may >>>>> instead send a Confirmable message. This type of exchange is >>>>> illustrated in Figure 6. >>>>> >>>>> Client Server >>>>> | | >>>>> | NON [0x7a11] | >>>>> | GET /temperature | >>>>> | (Token 0x74) | >>>>> +----------------->| >>>>> | | >>>>> | NON [0x23bc] | >>>>> | 2.05 Content | >>>>> | (Token 0x74) | >>>>> | "22.5 C" | >>>>> |<-----------------+ >>>>> | | >>>>> >>>>> Figure 6: A Request and a Response Carried in Non-confirmable >>>>> Messages [Jon] So I would >>>>> expect any CoAP library to support this non-confirmation >>>>> mechanism by receiving a new non- confirmable message. It would >>>>> be the responsibility of the DOTS layer to associate the Tokens >>>>> together to handle the responses with >>>> the requests. >>>>> [Jon] In addition, when Observe is enabled, the DOTS server will >>>>> continue to generate non-confirmable messages with the same Token. >>>>> Again, the DOTS client will need to know what to do with the >>>>> Token (which could be to update things, or to send a RST if no >>>>> more packets with the same Token should be sent. >>>>> >>>>> >>>>> The spec of Confirmable message already have the retransmission >>>>> mechanism, so using Confirmable message is an easier way to >>>>> notice that the message has been lost during the attack time. >>>>> >>>>> [Jon] The DOTS client will know something is wrong as it will be >>>>> seeing heartbeat issues. >>>>> >>>>> I'm afraid I'm missing some previous discussions we made on the >>>>> ML and at the WG meeting, but we have a problem with the CoAP >>>>> library regarding this spec. >>>>> >>>>> * At the -08 version of the signal channel draft, this change >>>>> was >> made: >>>>> DOTS mitigation request/response are marked as non-confirmable >>>> messages. >>>>> thank you, >>>>> Kaname >>>>> >>>>> >>>>> _______________________________________________ >>>>> Dots mailing list >>>>> Dots@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/dots >>>>> >>>>> _______________________________________________ >>>>> Dots mailing list >>>>> Dots@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/dots >>>>> >>>>> _______________________________________________ >>>>> Dots mailing list >>>>> Dots@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/dots >>>> _______________________________________________ >>>> Dots mailing list >>>> Dots@ietf.org >>>> https://www.ietf.org/mailman/listinfo/dots >>> _______________________________________________ >>> Dots mailing list >>> Dots@ietf.org >>> https://www.ietf.org/mailman/listinfo/dots >> _______________________________________________ >> Dots mailing list >> Dots@ietf.org >> https://www.ietf.org/mailman/listinfo/dots > _______________________________________________ > Dots mailing list > Dots@ietf.org > https://www.ietf.org/mailman/listinfo/dots > > _______________________________________________ > Dots mailing list > Dots@ietf.org > https://www.ietf.org/mailman/listinfo/dots From nobody Wed Jan 3 18:33:58 2018 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 4EB9312D850 for ; Wed, 3 Jan 2018 18:33:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 XpiLkU97tutS for ; Wed, 3 Jan 2018 18:33:41 -0800 (PST) Received: from guri.nttv6.jp (guri.nttv6.jp [115.69.228.140]) by ietfa.amsl.com (Postfix) with ESMTP id 4C71C12D84D for ; Wed, 3 Jan 2018 18:33:41 -0800 (PST) Received: from z.nttv6.jp (z.nttv6.jp [192.168.8.15]) by guri.nttv6.jp (NTTv6MTA) with ESMTP id 0130425F691; Thu, 4 Jan 2018 11:33:40 +0900 (JST) Received: from SR2-nishizuka.lv4.nttv6.jp (fujiko.nttv6.jp [115.69.228.141]) by z.nttv6.jp (NTTv6MTA) with ESMTP id E2A047634F9; Thu, 4 Jan 2018 11:33:39 +0900 (JST) To: Roman Danyliw , "dots@ietf.org" References: <359EC4B99E040048A7131E0F4E113AFC0131355A04@marathon> From: kaname nishizuka Message-ID: Date: Thu, 4 Jan 2018 11:33:38 +0900 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [Dots] REMINDER -- WGLC on DOTS 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: Thu, 04 Jan 2018 02:33:50 -0000 Hello, I'm satisfied with the changes of the terminology of the DOTS gateway. All of the content is worth to move it forward. thanks, Kaname On 2018/01/03 6:57, Roman Danyliw wrote: > Hello again! > > Given that some are just returning from their holiday, this WGLC will be extended one more day — till Wednesday, January 3rd. > > Thanks, > Roman > >> On Jan 2, 2018, at 07:53, Roman Danyliw wrote: >> >> Hello! >> >> Happy New Year! The WGLC for the DOTS requirements draft will be closing soon. Please provide any final comments. >> >> Thanks, >> Roman >> >> -----Original Message----- >> From: Roman Danyliw >> Sent: Thursday, December 7, 2017 3:51 PM >> To: dots@ietf.org >> Subject: WGLC on DOTS Requirements >> >> Hello! >> >> Consistent with our discussion at the Singapore meeting and with the concurrence of the draft authors, we are starting a working group last call (WGLC) for the DOTS Requirements draft: >> >> Distributed Denial of Service (DDoS) Open Threat Signaling Requirements >> draft-ietf-dots-requirements-08 >> https://tools.ietf.org/html/draft-ietf-dots-requirements-08 >> >> Please send all comments to the DOTS mailing list. >> >> This WGLC will end on January 2, 2018 (~3 weeks to account for end-of-the-calendar year vacations). >> >> Thanks, >> 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 Wed Jan 3 23:18:51 2018 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 13A4112D7F8 for ; Wed, 3 Jan 2018 23:18:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.33 X-Spam-Level: X-Spam-Status: No, score=-4.33 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, T_RP_MATCHES_RCVD=-0.01] 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 I4D23tB0-x0J for ; Wed, 3 Jan 2018 23:18:46 -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 40113124205 for ; Wed, 3 Jan 2018 23:18: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=1515050325; 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: x-microsoft-antispam-message-info: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=2 kSprK2+C9MoPJytMeU0R025dC3FSJ1aA2zqNtga2Q Y=; b=WBmjFiGWCvi2U6E7NOP/h9T9GFuZKEuyfdN6sMN+vUiU yganLS084Jb1vNOHjwBpsxdDrhvEaMdVy7sGnPRQTOwr9rABLJ QJFErAfaH99RE9x6UeGUpFoODM3Muv/5snLRQFpKVDfTGofq7U /Ebupb5OwlFJdN0IQ6nqvuCN2YI= Received: from DNVEXAPP1N06.corpzone.internalzone.com (unknown [10.44.48.90]) by DNVWSMAILOUT1.mcafee.com with smtp (TLS: TLSv1/SSLv3,256bits,ECDHE-RSA-AES256-SHA384) id 3f34_a735_b6ca8b91_584d_44dd_9b40_f1f550486300; Thu, 04 Jan 2018 01:18:44 -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; Thu, 4 Jan 2018 00:18: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; Thu, 4 Jan 2018 00:18:42 -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; Thu, 4 Jan 2018 00:18:42 -0700 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; Thu, 4 Jan 2018 00:18:41 -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.366.8; Thu, 4 Jan 2018 07:18:39 +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.0366.009; Thu, 4 Jan 2018 07:18:39 +0000 From: "Konda, Tirumaleswar Reddy" To: Jon Shallow , "dots@ietf.org" Thread-Topic: [Dots] Using SNI Thread-Index: AdOBYSmGAk9KbyE4TFyYKC/j9TeHqgCRKPHwAAH2wAAAAHaCkAAAPMGAACycgwAAB1SwgAABIhDA Date: Thu, 4 Jan 2018 07:18:39 +0000 Message-ID: References: <0a1201d38161$299ef350$7cdcd9f0$@jpshallow.com> <0b2301d383ad$a8822a40$f9867ec0$@jpshallow.com> <0b4b01d383b0$758f1370$60ad3a50$@jpshallow.com> <0c8c01d38480$3a6ba5d0$af42f170$@jpshallow.com> In-Reply-To: <0c8c01d38480$3a6ba5d0$af42f170$@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:Rcurj5ETre1QW3MaOdU7V8MwxI09YiM4iGZnrCsB3dWCIXlo1mUzEXKar39MtdqpPqp5ZsdlGSC3s9uteq4vx5nsPPqIBhSf2x7We70ZFOwt+iT8No8brcfwkuTC822wVnRyqNxCpaucy9l1L/6NdnBqEg+Ga7LqNfMn55pADdOPJMXVbASGCKfeeUV/+hy+w0dqiU5LkgqHKHlBHuC/IiOsAHDfMro8zNZ5l6Ko3m5+RPiAwMX7bBebf767oppqE2LXEUUp8H+XWhD2yqmvB4M/etrR5LmoByXxjRXf9932QPBz61+2SNbVquaNnOcHHXTVU3RNnL3wVD1hbaGuELpa2yqT4+JXLmmdBfKrITonsozmtnbOTrH6+gwMOi42; 5:Hauwj6NHVDlcZeykwRaAkoKN9P9Va509R0Youv4975T5VhAcxbPHm1m0m95nth5MMYW6IV9itJWdD7MKAUfCHaV+yIBBjCnDssvhmhS6xxqHQmCyX79cxa285QlqcYmetDjAR+7HFOrQu3Kau18Z4SMVB62XdbTR8l6CGsgFIR4=; 24:obpLkzdBP7A0zcJ/DQJc76+2zGXwxpuUUH2lculBzR5hALn9+mZFAHSBLwBR4YsU519jLN8JnVbxTPcjSXrRzVL7BJDbSU/ptXOGCyHrPDM=; 7:S30ITlbimU2gF2mSlNgXwGoKD4bKL4u4aOrUZ/cz1Zgb+7qqlhnJMWa0E6M0+dgqGfUd+4PhNgihqHDbxhaVQs9gjuxBmdPEd8Ieens8IbewJbWIkYqxFRbnbYVIC+3ypPNr9brprBqnrJz2e6H753NRNQgE7VcGcpxUFC4VSW4uZwHvUNlEo43VLQ0HSgZW8tBNQ1+GDJCuv6FACZjyb+B+I9XeHsIG9G79IXd+KWf7lWxI8cmzKAl1MoI8JiYt x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 1202a6eb-029d-49db-05dc-08d5534360db x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(5600026)(4604075)(3008032)(2017052603307)(7153060); SRVR:DM5PR16MB1788; x-ms-traffictypediagnostic: DM5PR16MB1788: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(192374486261705)(21748063052155)(123452027830198); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040470)(2401047)(5005006)(8121501046)(10201501046)(93006095)(93001095)(3231023)(944501075)(3002001)(6041268)(20161123564045)(20161123558120)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123562045)(6072148)(201708071742011); SRVR:DM5PR16MB1788; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:DM5PR16MB1788; x-forefront-prvs: 054231DC40 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39860400002)(376002)(39380400002)(396003)(346002)(366004)(32952001)(51444003)(189003)(199004)(19609705001)(3660700001)(53546011)(53936002)(99286004)(2906002)(81156014)(6506007)(229853002)(80792005)(14454004)(102836004)(59450400001)(81166006)(8676002)(7696005)(97736004)(68736007)(25786009)(76176011)(77096006)(33656002)(6246003)(6436002)(55016002)(72206003)(74316002)(8936002)(790700001)(9326002)(5660300001)(236005)(6116002)(6306002)(3846002)(2950100002)(54896002)(478600001)(2501003)(2900100001)(316002)(106356001)(105586002)(7736002)(66066001)(9686003)(110136005)(93886005)(3280700002)(86362001)(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; x-microsoft-antispam-message-info: l553Tk4X0vMb8iNQRvkTI02Y7N7/zltpjF5I8veSuTNk1G5QL3yW0GQy27Yq1v2qlwhUHVKMH/Xw6N+HW2/uNw== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_DM5PR16MB17887114B87C6EB701BE880EEA1F0DM5PR16MB1788namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 1202a6eb-029d-49db-05dc-08d5534360db X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Jan 2018 07:18:39.4111 (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 <6192> : inlines <6293> : streams <1775057> : uri <2562815> Archived-At: Subject: Re: [Dots] Using SNI 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, 04 Jan 2018 07:18:49 -0000 --_000_DM5PR16MB17887114B87C6EB701BE880EEA1F0DM5PR16MB1788namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Jon, How about the following line instead ? "If PKI-based authentication is used by the DOTS client to validate the DOT= S server identity, the DOTS client SHOULD include DOTS server FQDN in the s= erver name indication extension (Section 3 of RFC6066)." Cheers, -Tiru From: Jon Shallow [mailto:supjps-ietf@jpshallow.com] Sent: Wednesday, January 3, 2018 4:17 PM To: Konda, Tirumaleswar Reddy ; dots@ie= tf.org Subject: RE: [Dots] Using SNI Hi Tiru, My main goal here is to make sure that we can have DOTS vendor interoperabi= lity. As found during my implementation, having certain things in place he= lps considerably - providing strong hints to the implementer as to what sho= uld be available for interoperability helps. Instead of "If TLS client certificate is used to authenticate the DOTS client, the DOT= S client MUST include the DOTS server FQDN in server name indication extens= ion (Section 3 of RFC6066)." We could perhaps have "The DOTS client MUST support enabling the use of SNI (Section 3 of RFC6066= ). When enabled, this SHOULD include the DOTS server FQDN in the server na= me indication extension." As an aside, I have been able to get my DOTS server to support both PKI and= PSK, thus supporting a mix of PKI and PSK DOTS clients being active at the= same time (I agree this is not a generally recommended case). This was no= t done using SNI, but would have been considerably easier to implement if u= sing SNI and the PSK clients talked to psk-dotsserver.somewhere.com and PKI= clients talked to pki-dotsserver.somewhere.com - both DNS resolving to the= same IP. So being able to use SNI in both the signal and data channels makes sense t= o me. Regards Jon From: Dots [mailto: dots-bounces@ietf.org] On= Behalf Of Konda, Tirumaleswar Reddy Sent: 03 January 2018 07:21 To: Jon Shallow; dots@ietf.org Subject: Re: [Dots] Using SNI Hi Jon, We may want to use "SHOULD" instead of "MUST" in the below line (for exampl= e, SNI is not required if the DOTS client and server are in the same enterp= rise network). -TIru From: Jon Shallow [mailto:supjps-ietf@jpshallow.com] Sent: Tuesday, January 2, 2018 3:30 PM To: Konda, Tirumaleswar Reddy >; dots@ietf.org Subject: RE: [Dots] Using SNI Hi Tiru, That certainly works for me - thanks Regards Jon From: Dots [mailto: dots-bounces@ietf.org] On= Behalf Of Konda, Tirumaleswar Reddy Sent: 02 January 2018 09:55 To: Jon Shallow; dots@ietf.org Subject: Re: [Dots] Using SNI Hi Jon, RESTCONF does not mandate client authentication based on TLS client certifi= cate, we can say the following instead: If TLS client certificate is used to authenticate the DOTS client, the DOTS= client MUST include the DOTS server FQDN in server name indication extensi= on (Section 3 of RFC6066). Cheers, -Tiru From: Jon Shallow [mailto:supjps-ietf@jpshallow.com] Sent: Tuesday, January 2, 2018 3:10 PM To: Konda, Tirumaleswar Reddy >; dots@ietf.org Subject: RE: [Dots] Using SNI Hi Tiru, I agree that (indirectly through RFC7525 reference) SNI is mandated to be s= upported (but not necessarily has to be used). However, to guarantee interoperability between different DOTS vendors, I am= saying that the use of SNI is a MUST - in particular for the data channel. Regards Jon From: Dots [mailto: dots-bounces@ietf.org] On= Behalf Of Konda, Tirumaleswar Reddy Sent: 02 January 2018 08:48 To: Jon Shallow; dots@ietf.org Subject: Re: [Dots] Using SNI Hi Jon, Both signal and data channel drafts refer to RFC7525 for secure use of (D)T= LS and RFC7525 mandates TLS implementations to support SNI. I don't see the= need to explicitly discuss SNI in these drafts. Regards, -Tiru From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Jon Shallow Sent: Saturday, December 30, 2017 4:57 PM To: dots@ietf.org Subject: [Dots] Using SNI Hi WG, When providing a DOTS server data channel service in my environment, this s= hares the same ip / port which also provides other services (e.g. GUI / RES= T server etc.). Even if the Root Discovery points to another IP and or por= t for the actual data channel activity, the TLS exchanges for the Root Disc= overy have to correctly work. I suspect that I am not the only DOTS vendor= who will have this type of requirement of a single IP providing multiple T= LS services. As DOTS requires mutual authentication, this is a different security requir= ement than required by the GUI environment (DOTS requires client cert to be= presented, GUI does not and providing certificates to every GUI client is = not a practical option). This can be handled by using SNI by using 2 different FQDNs and requiring t= he DOTS client to include the DOTS specific FQDN in the TLS Client Hello. = Whether the GUI client does or does not (likely does with modern browsers) = include a SNI FQDN when connecting to the non DOTS FQDN does not really mat= ter - for DOTS it is recognizing the DOTS specific FQDN and setting up the = TLS as appropriate. To make sure interoperability between DOTS vendors, I would like to see som= ething like added to the data channel spec "DOTS clients MUST include the D= OTS server FQDN in the TLS Client Hello packet by using Server Name Indicat= ion (SNI) RFC 3546". In addition, I think that this would be a good idea as well for the signal = draft - thereby giving DOTS vendors the opportunity to host multiple DOTS s= ervers (likely to be different security requirements for their different cl= ient) on a single IP / port. Thoughts / comments? Regards Jon --_000_DM5PR16MB17887114B87C6EB701BE880EEA1F0DM5PR16MB1788namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Jon,

&nbs= p;

How about= the following line instead ?

“If= PKI-based authentication is used by the DOTS client to validate the DOTS s= erver identity, the DOTS client SHOULD include DOTS server FQDN in the serv= er name indication extension (Section 3 of RFC6066).”

Cheers,

-Tiru

 

From:<= /span> Jon Shallow [mailto:s= upjps-ietf@jpshallow.com]
Sent: Wednesday, January 3, 2018 4:17 PM
To: Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@McAfee.com= >; dots@ietf.org
Subject: RE: [Dots] Using SNI

 

Hi Tiru= ,

&n= bsp;

My main= goal here is to make sure that we can have DOTS vendor interoperability.&n= bsp; As found during my implementation, having certain things in place help= s considerably – providing strong hints to the implementer as to what should be available for interoperability helps.=

&n= bsp;

Instead of 
 
“If TLS client certificate is used to authe=
nticate the DOTS client, the DOTS client MUST include the DOTS server FQDN =
in server name indication extension (Section 3 of RFC6066).”
 
We could perhaps have
 
“The DOTS client MUST support enabling the use of SNI (Section =
3 of RFC6066).  When enabled, this SHOULD include the DOTS server FQDN=
 in the server name indication extension.”
 
As an aside, I have been able to get my DOTS server to support both P=
KI and PSK, thus supporting a mix of PKI and PSK DOTS clients being active =
at the same time (I agree this is not a generally recommended case).  =
This was not done using SNI, but would have been considerably easier to imp=
lement if using SNI and the PSK clients talked to psk-dotsserver.somewhere.=
com and PKI clients talked to pki-dotsserver.somewhere.com – both DNS=
 resolving to the same IP.
 
So being able to use SNI in both the signal and data channels makes s=
ense to me.

&n= bsp;

Regards=

&n= bsp;

Jon

&n= bsp;

From: Dots [mailto: dots-bounces@ietf.org] On B= ehalf Of Konda, Tirumaleswar Reddy
Sent: 03 January 2018 07:21
To: Jon Shallow; dots@ietf.org<= br> Subject: Re: [Dots] Using SNI

 

Hi Jon,

&nbs= p;

We may wa= nt to use “SHOULD” instead of “MUST” in the below l= ine (for example, SNI is not required if the DOTS client and server are in = the same enterprise network).

&nbs= p;

-TIru

&nbs= p;

From:<= /span> Jon Shallow [mailto:supjps-ietf@jpshallow.com]
Sent: Tuesday, January 2, 2018 3:30 PM
To: Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@McAfee.com>; dots@ietf.org
Subject: RE: [Dots] Using SNI

 

Hi Tiru= ,

&n= bsp;

That ce= rtainly works for 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: 02 January 2018 09:55
To: Jon Shallow; dots@ietf.org<= br> Subject: Re: [Dots] Using SNI

 

Hi Jon,
 
RESTCONF does not mandate client authentication based on TLS client c=
ertificate, we can say the following instead:
If TLS client certificate is used to authenticate the DOTS client, th=
e DOTS client MUST include the DOTS server FQDN in server name indication e=
xtension (Section 3 of RFC6066).
 
Cheers,
-Tiru
 

From:<= /span> Jon Shallow [mailto:supjps-ietf@jpshallow.com]
Sent: Tuesday, January 2, 2018 3:10 PM
To: Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@McAfee.com>; dots@ietf.org
Subject: RE: [Dots] Using SNI

 

Hi Tiru= ,

&n= bsp;

I agree= that (indirectly through RFC7525 reference) SNI is mandated to be supporte= d (but not necessarily has to be used).

&n= bsp;

However= , to guarantee interoperability between different DOTS vendors, I am saying= that the use of SNI is a MUST – in particular for the data channel.<= o:p>

&n= bsp;

Regards=

&n= bsp;

Jon

&n= bsp;

From: Dots [mailto: dots-bounces@ietf.org] On B= ehalf Of Konda, Tirumaleswar Reddy
Sent: 02 January 2018 08:48
To: Jon Shallow; dots@ietf.org<= br> Subject: Re: [Dots] Using SNI

 

Hi Jon,

&nbs= p;

Both sign= al and data channel drafts refer to RFC7525 for secure use of (D)TLS and RF= C7525 mandates TLS implementations to support SNI. I don’t see the ne= ed to explicitly discuss SNI in these drafts.


Regards,

-Tiru

&nbs= p;

From:<= /span> Dots [mailto:dots-bounces@ietf.org] On Behalf Of Jon Shallow
Sent: Saturday, December 30, 2017 4:57 PM
To: dots@ietf.org
Subject: [Dots] Using SNI

 

Hi WG,

 

When providing a DOTS server da= ta channel service in my environment, this shares the same ip / port which = also provides other services (e.g. GUI / REST server etc.).  Even if t= he Root Discovery points to another IP and or port for the actual data channel activity, the TLS exchanges for the Ro= ot Discovery have to correctly work.  I suspect that I am not the only= DOTS vendor who will have this type of requirement of a single IP providin= g multiple TLS services.

 

As DOTS requires mutual authent= ication, this is a different security requirement than required by the GUI = environment (DOTS requires client cert to be presented, GUI does not and pr= oviding certificates to every GUI client is not a practical option).

 

This can be handled by using SN= I by using 2 different FQDNs and requiring the DOTS client to include the D= OTS specific FQDN in the TLS Client Hello.  Whether the GUI client doe= s or does not (likely does with modern browsers) include a SNI FQDN when connecting to the non DOTS FQDN does not really ma= tter – for DOTS it is recognizing the DOTS specific FQDN and setting = up the TLS as appropriate.

 

To make sure interoperability b= etween DOTS vendors, I would like to see something like added to the data c= hannel spec “DOTS clients MUST include the DOTS server FQDN in the TL= S Client Hello packet by using Server Name Indication (SNI) RFC 3546”.

 

In addition, I think that this = would be a good idea as well for the signal draft – thereby giving DO= TS vendors the opportunity to host multiple DOTS servers (likely to be diff= erent security requirements for their different client) on a single IP / port.

 

Thoughts / comments?=

 

Regards

 

Jon

--_000_DM5PR16MB17887114B87C6EB701BE880EEA1F0DM5PR16MB1788namp_-- From nobody Thu Jan 4 00:15:18 2018 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 C603212751F for ; Thu, 4 Jan 2018 00:15:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 jL5u85irLa3X for ; Thu, 4 Jan 2018 00:15:15 -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 C1154126DD9 for ; Thu, 4 Jan 2018 00:15: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 1eX0gB-0008Cr-LN; Thu, 04 Jan 2018 08:15:11 +0000 From: "Jon Shallow" To: "'Konda, Tirumaleswar Reddy'" , References: <0a1201d38161$299ef350$7cdcd9f0$@jpshallow.com> <0b2301d383ad$a8822a40$f9867ec0$@jpshallow.com> <0b4b01d383b0$758f1370$60ad3a50$@jpshallow.com> <0c8c01d38480$3a6ba5d0$af42f170$@jpshallow.com> In-Reply-To: Date: Thu, 4 Jan 2018 08:15:10 -0000 Message-ID: <0d4901d38534$23d56ea0$6b804be0$@jpshallow.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0D4A_01D38534.23D7B890" X-Mailer: Microsoft Outlook 14.0 Content-Language: en-gb Thread-Index: AQIpdHJXTEWkUmLWfrWfFs+hkFSqvAJ19VeLAlAhTlAB/1BuRQHRwg9pAM+YE+cClEN/FAIrAz1UokZHaUA= Archived-At: Subject: Re: [Dots] Using SNI 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, 04 Jan 2018 08:15:18 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0D4A_01D38534.23D7B890 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Tiru, I do not think that this is about validation, and unlikely to be used by the DOTS client to validate the DOTS server identity (yes, the DOTS server could present different certificates based on the SNI, but not sure how that helps the DOS client to validate). To me, it is all about the ability of the DOTS server to be able to decide which security policy to install for the incoming connection - is this a DOTS connection or is this a request to access a GUI or is this for a RESTful interface etc. etc. ? - all on the same IP and port - the decision is keyed off the SNI information. Part of the challenge I have here is that the data channel root discovery against port 443 ideally has to have the same security requirements as when the data channel is used for aliases and filter updating. So even if root discovery redirects the DOTS connection to a different port, the correct security policy still needs to applied to DOTS client root discovery and a different policy applied for the GUI connection. If a peer certificate is to be requested for mutual authentication checks in a DOTS connection, requesting a peer certificate from a browser fails (unless a specific peer cert is installed in the browser - impractical scaling request) and so GUI access will fail. One policy (DOTS) needs to request the peer cert, the other (GUI) must not request a peer cert. SNI is the only way I have found to handle this. I also do not think it is limited to PKI for DOTS - as mentioned below, accessing psk-dotsserver.somewhere.com or pki-dotsserver.somewhere.com along with the appropriate SNI information, the DOTS server can easily decide to install a PSK or PKI security policy. The DOTS client needs to be able to provide the SNI information - it is up to the DOTS server as to how it is used (which could be to ignore it) - to provide DOTS vender interoperability. So, no, I am not comfortable with your suggestion. Regards Jon From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of Konda, Tirumaleswar Reddy Sent: 04 January 2018 07:19 To: Jon Shallow; dots@ietf.org Subject: Re: [Dots] Using SNI Hi Jon, How about the following line instead ? "If PKI-based authentication is used by the DOTS client to validate the DOTS server identity, the DOTS client SHOULD include DOTS server FQDN in the server name indication extension (Section 3 of RFC6066)." Cheers, -Tiru From: Jon Shallow [mailto:supjps-ietf@jpshallow.com] Sent: Wednesday, January 3, 2018 4:17 PM To: Konda, Tirumaleswar Reddy ; dots@ietf.org Subject: RE: [Dots] Using SNI Hi Tiru, My main goal here is to make sure that we can have DOTS vendor interoperability. As found during my implementation, having certain things in place helps considerably - providing strong hints to the implementer as to what should be available for interoperability helps. Instead of "If TLS client certificate is used to authenticate the DOTS client, the DOTS client MUST include the DOTS server FQDN in server name indication extension (Section 3 of RFC6066)." We could perhaps have "The DOTS client MUST support enabling the use of SNI (Section 3 of RFC6066). When enabled, this SHOULD include the DOTS server FQDN in the server name indication extension." As an aside, I have been able to get my DOTS server to support both PKI and PSK, thus supporting a mix of PKI and PSK DOTS clients being active at the same time (I agree this is not a generally recommended case). This was not done using SNI, but would have been considerably easier to implement if using SNI and the PSK clients talked to psk-dotsserver.somewhere.com and PKI clients talked to pki-dotsserver.somewhere.com - both DNS resolving to the same IP. So being able to use SNI in both the signal and data channels makes sense to me. Regards Jon From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of Konda, Tirumaleswar Reddy Sent: 03 January 2018 07:21 To: Jon Shallow; dots@ietf.org Subject: Re: [Dots] Using SNI Hi Jon, We may want to use "SHOULD" instead of "MUST" in the below line (for example, SNI is not required if the DOTS client and server are in the same enterprise network). -TIru From: Jon Shallow [mailto:supjps-ietf@jpshallow.com] Sent: Tuesday, January 2, 2018 3:30 PM To: Konda, Tirumaleswar Reddy ; dots@ietf.org Subject: RE: [Dots] Using SNI Hi Tiru, That certainly works for me - thanks Regards Jon From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of Konda, Tirumaleswar Reddy Sent: 02 January 2018 09:55 To: Jon Shallow; dots@ietf.org Subject: Re: [Dots] Using SNI Hi Jon, RESTCONF does not mandate client authentication based on TLS client certificate, we can say the following instead: If TLS client certificate is used to authenticate the DOTS client, the DOTS client MUST include the DOTS server FQDN in server name indication extension (Section 3 of RFC6066). Cheers, -Tiru From: Jon Shallow [mailto:supjps-ietf@jpshallow.com] Sent: Tuesday, January 2, 2018 3:10 PM To: Konda, Tirumaleswar Reddy ; dots@ietf.org Subject: RE: [Dots] Using SNI Hi Tiru, I agree that (indirectly through RFC7525 reference) SNI is mandated to be supported (but not necessarily has to be used). However, to guarantee interoperability between different DOTS vendors, I am saying that the use of SNI is a MUST - in particular for the data channel. Regards Jon From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of Konda, Tirumaleswar Reddy Sent: 02 January 2018 08:48 To: Jon Shallow; dots@ietf.org Subject: Re: [Dots] Using SNI Hi Jon, Both signal and data channel drafts refer to RFC7525 for secure use of (D)TLS and RFC7525 mandates TLS implementations to support SNI. I don't see the need to explicitly discuss SNI in these drafts. Regards, -Tiru From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Jon Shallow Sent: Saturday, December 30, 2017 4:57 PM To: dots@ietf.org Subject: [Dots] Using SNI Hi WG, When providing a DOTS server data channel service in my environment, this shares the same ip / port which also provides other services (e.g. GUI / REST server etc.). Even if the Root Discovery points to another IP and or port for the actual data channel activity, the TLS exchanges for the Root Discovery have to correctly work. I suspect that I am not the only DOTS vendor who will have this type of requirement of a single IP providing multiple TLS services. As DOTS requires mutual authentication, this is a different security requirement than required by the GUI environment (DOTS requires client cert to be presented, GUI does not and providing certificates to every GUI client is not a practical option). This can be handled by using SNI by using 2 different FQDNs and requiring the DOTS client to include the DOTS specific FQDN in the TLS Client Hello. Whether the GUI client does or does not (likely does with modern browsers) include a SNI FQDN when connecting to the non DOTS FQDN does not really matter - for DOTS it is recognizing the DOTS specific FQDN and setting up the TLS as appropriate. To make sure interoperability between DOTS vendors, I would like to see something like added to the data channel spec "DOTS clients MUST include the DOTS server FQDN in the TLS Client Hello packet by using Server Name Indication (SNI) RFC 3546". In addition, I think that this would be a good idea as well for the signal draft - thereby giving DOTS vendors the opportunity to host multiple DOTS servers (likely to be different security requirements for their different client) on a single IP / port. Thoughts / comments? Regards Jon ------=_NextPart_000_0D4A_01D38534.23D7B890 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Tiru,

 

I do not think that this = is about validation, and unlikely to be used by the DOTS client to = validate the DOTS server identity (yes, the DOTS server could present = different certificates based on the SNI, but not sure how that helps the = DOS client to validate).

 

To me, it is all about = the ability of the DOTS server to be able to decide which security = policy to install for the incoming connection – is this a DOTS = connection or is this a request to access a GUI or is this for a RESTful = interface etc. etc. ? – all on the same IP and port – the = decision is keyed off the SNI information.

 

Part of the challenge I = have here is that the data channel root discovery against port 443 = ideally has to have the same security requirements as when the data = channel is used for aliases and filter updating.  So even if root = discovery redirects the DOTS connection to a different port, the correct = security policy still needs to applied to DOTS client root discovery and = a different policy applied for the GUI connection.  If a peer = certificate is to be requested for mutual authentication checks in a = DOTS connection, requesting a peer certificate from a browser fails = (unless a specific peer cert is installed in the browser – = impractical scaling request) and so GUI access will fail.  One = policy (DOTS) needs to request the peer cert, the other (GUI) must not = request a peer cert.  SNI is the only way I have found to handle = this.

 

I also do not think it = is limited to PKI for DOTS – as mentioned below, accessing = psk-dotsserver.somewhere.com or = pki-dotsserver.somewhere.com along with the appropriate SNI information, = the DOTS server can easily decide to install a PSK or PKI security = policy.

 

The DOTS client needs to be able to provide the SNI = information – it is up to the DOTS server as to how it is used = (which could be to ignore it) – to provide DOTS vender = interoperability.

 

So, no, I am not comfortable with your = suggestion.

 

Regards

 

Jon

 

From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of = Konda, Tirumaleswar Reddy
Sent: 04 January 2018 = 07:19
To: Jon Shallow; dots@ietf.org
Subject: Re: = [Dots] Using SNI

 

Hi = Jon,

 

How about the following line = instead ?

“If PKI-based authentication = is used by the DOTS client to validate the DOTS server identity, the = DOTS client SHOULD include DOTS server FQDN in the server name = indication extension (Section 3 of = RFC6066).”

Cheers,

-Tiru

 

From: Jon Shallow [mailto:supjps-ietf@jpshallow.co= m]
Sent: Wednesday, January 3, 2018 4:17 PM
To: = Konda, Tirumaleswar Reddy <TirumaleswarReddy_Kond= a@McAfee.com>; dots@ietf.org
Subject: RE: = [Dots] Using SNI

 

Hi = Tiru,

 

My main goal here is to = make sure that we can have DOTS vendor interoperability.  As found = during my implementation, having certain things in place helps = considerably – providing strong hints to the implementer as to = what should be available for interoperability = helps.

 

Instead of =

 
“=
If TLS =
client certificate is used to authenticate the DOTS client, the DOTS =
client MUST include the DOTS server FQDN in server name indication =
extension (Section 3 of =
RFC6066).”
 =

We could =
perhaps have
 =

“The =
DOTS client MUST support enabling the use of SNI (Section 3 of =
RFC6066).  When enabled, this SHOULD include the DOTS server FQDN =
in the server name indication =
extension.”
 =

As an =
aside, I have been able to get my DOTS server to support both PKI and =
PSK, thus supporting a mix of PKI and PSK DOTS clients being active at =
the same time (I agree this is not a generally recommended case).  =
This was not done using SNI, but would have been considerably easier to =
implement if using SNI and the PSK clients talked to =
psk-dotsserver.somewhere.com and PKI clients talked to =
pki-dotsserver.somewhere.com – both DNS resolving to the same =
IP.
 =

So being =
able to use SNI in both the signal and data channels makes sense to =
me.

 

Regards

 

Jon

 

From: Dots [mailto: dots-bounces@ietf.org] On = Behalf Of Konda, Tirumaleswar Reddy
Sent: 03 January 2018 = 07:21
To: Jon Shallow; dots@ietf.org
Subject: Re: = [Dots] Using SNI

 

Hi = Jon,

 

We may want to use = “SHOULD” instead of “MUST” in the below line = (for example, SNI is not required if the DOTS client and server are in = the same enterprise network).

 

-TIru

 

From: Jon Shallow [mailto:supjps-ietf@jpshallow.co= m]
Sent: Tuesday, January 2, 2018 3:30 PM
To: = Konda, Tirumaleswar Reddy <TirumaleswarReddy_Kond= a@McAfee.com>; dots@ietf.org
Subject: RE: = [Dots] Using SNI

 

Hi = Tiru,

 

That certainly works for = me – thanks

 

Regards

 

Jon

 

From: Dots [mailto: dots-bounces@ietf.org] On = Behalf Of Konda, Tirumaleswar Reddy
Sent: 02 January 2018 = 09:55
To: Jon Shallow; dots@ietf.org
Subject: Re: = [Dots] Using SNI

 

Hi =
Jon,
 =

RESTCONF =
does not mandate client authentication based on TLS client certificate, =
we can say the following instead:
If TLS =
client certificate is used to authenticate the DOTS client, the DOTS =
client MUST include the DOTS server FQDN in server name indication =
extension (Section 3 of RFC6066).
 =

Cheers,
-Tiru<=
/o:p>
 =

From: Jon Shallow [mailto:supjps-ietf@jpshallow.co= m]
Sent: Tuesday, January 2, 2018 3:10 PM
To: = Konda, Tirumaleswar Reddy <TirumaleswarReddy_Kond= a@McAfee.com>; dots@ietf.org
Subject: RE: = [Dots] Using SNI

 

Hi = Tiru,

 

I agree that (indirectly = through RFC7525 reference) SNI is mandated to be supported (but not = necessarily has to be used).

 

However, to guarantee = interoperability between different DOTS vendors, I am saying that the = use of SNI is a MUST – in particular for the data = channel.

 

Regards

 

Jon

 

From: Dots [mailto: dots-bounces@ietf.org] On = Behalf Of Konda, Tirumaleswar Reddy
Sent: 02 January 2018 = 08:48
To: Jon Shallow; dots@ietf.org
Subject: Re: = [Dots] Using SNI

 

Hi = Jon,

 

Both signal and data channel drafts = refer to RFC7525 for secure use of (D)TLS and RFC7525 mandates TLS = implementations to support SNI. I don’t see the need to explicitly = discuss SNI in these drafts.


Regards,

-Tiru

 

From: Dots [mailto:dots-bounces@ietf.org] = On Behalf Of Jon Shallow
Sent: Saturday, December 30, = 2017 4:57 PM
To: dots@ietf.org
Subject: = [Dots] Using SNI

 

Hi WG,

 

When = providing a DOTS server data channel service in my environment, this = shares the same ip / port which also provides other services (e.g. GUI / = REST server etc.).  Even if the Root Discovery points to another IP = and or port for the actual data channel activity, the TLS exchanges for = the Root Discovery have to correctly work.  I suspect that I am not = the only DOTS vendor who will have this type of requirement of a single = IP providing multiple TLS services.

 

As DOTS = requires mutual authentication, this is a different security requirement = than required by the GUI environment (DOTS requires client cert to be = presented, GUI does not and providing certificates to every GUI client = is not a practical option).

 

This can be = handled by using SNI by using 2 different FQDNs and requiring the DOTS = client to include the DOTS specific FQDN in the TLS Client Hello.  = Whether the GUI client does or does not (likely does with modern = browsers) include a SNI FQDN when connecting to the non DOTS FQDN does = not really matter – for DOTS it is recognizing the DOTS specific = FQDN and setting up the TLS as appropriate.

 

To make sure = interoperability between DOTS vendors, I would like to see something = like added to the data channel spec “DOTS clients MUST include the = DOTS server FQDN in the TLS Client Hello packet by using Server Name = Indication (SNI) RFC 3546”.

 

In addition, = I think that this would be a good idea as well for the signal draft = – thereby giving DOTS vendors the opportunity to host multiple = DOTS servers (likely to be different security requirements for their = different client) on a single IP / port.

 

Thoughts / = comments?

 

Regards

 

Jon

= ------=_NextPart_000_0D4A_01D38534.23D7B890-- From nobody Thu Jan 4 02:47:46 2018 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 29748126D73 for ; Thu, 4 Jan 2018 02:47:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.33 X-Spam-Level: X-Spam-Status: No, score=-4.33 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, T_RP_MATCHES_RCVD=-0.01] 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 5vIu1W0qfYra for ; Thu, 4 Jan 2018 02:47:40 -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 B315E1200C5 for ; Thu, 4 Jan 2018 02:47:39 -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=1515062858; 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:x-microsoft-antispam-message-info: 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 ShONqRQXNtefiWxbEKuQWyk4uU1YX/VcZuBY9XHSC g=; b=p3Vd/pO3phr8z3ENFF6XQnneImxC80Io0WhJ19joxxiR /4Jeb/mIFxk907nOU124lmHXqq88HJU+E0KvhyKLDl1j5eVjdG c6MT+KaEjpGDiUae8Vbq0hzdFfg5LvS4qa6c5wzK9IALjT+9M4 CVaRaoFogj1zNwiN8Ysh6kqd6Yo= Received: from DNVEXAPP1N04.corpzone.internalzone.com (unknown [10.44.48.88]) by DNVWSMAILOUT1.mcafee.com with smtp (TLS: TLSv1/SSLv3,256bits,ECDHE-RSA-AES256-SHA384) id 3f34_9e65_ff4e64dc_6c0d_41b7_b428_5798b3e94cc7; Thu, 04 Jan 2018 04:47:38 -0600 Received: from DNVEXUSR1N12.corpzone.internalzone.com (10.44.48.85) by DNVEXAPP1N04.corpzone.internalzone.com (10.44.48.88) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Thu, 4 Jan 2018 03:47:36 -0700 Received: from DNVEXUSR1N08.corpzone.internalzone.com (10.44.48.81) by DNVEXUSR1N12.corpzone.internalzone.com (10.44.48.85) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Thu, 4 Jan 2018 03:47:35 -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; Thu, 4 Jan 2018 03:47:35 -0700 Received: from NAM02-SN1-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, 4 Jan 2018 03:47:34 -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.366.8; Thu, 4 Jan 2018 10:47:34 +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.0366.009; Thu, 4 Jan 2018 10:47:34 +0000 From: "Konda, Tirumaleswar Reddy" To: Jon Shallow , "dots@ietf.org" Thread-Topic: [Dots] Using SNI Thread-Index: AdOBYSmGAk9KbyE4TFyYKC/j9TeHqgCRKPHwAAH2wAAAAHaCkAAAPMGAACycgwAAB1SwgAABIhDAACvYNwAABJpNMA== Date: Thu, 4 Jan 2018 10:47:33 +0000 Message-ID: References: <0a1201d38161$299ef350$7cdcd9f0$@jpshallow.com> <0b2301d383ad$a8822a40$f9867ec0$@jpshallow.com> <0b4b01d383b0$758f1370$60ad3a50$@jpshallow.com> <0c8c01d38480$3a6ba5d0$af42f170$@jpshallow.com> <0d4901d38534$23d56ea0$6b804be0$@jpshallow.com> In-Reply-To: <0d4901d38534$23d56ea0$6b804be0$@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; 7:993+FeFAiuIiradzIAI1rONqlMAiGFwacjVt94UbsgqtkuypZZBb7vKmq0I9L9G9qkV6WKdKc9uHFCOO/GM8gbI9HCOxSu/VThvCAEPtaMBcKZPXT/t5vCUJViVarcHIL09hAfw6FzLTrW7yZ08EID8LKSWCpYCTxe/mSxQQJK6C1d4yimDDgeCLCHhmLaFE63CerIx2eibZe0CPP2KK7io59lKRF3DaGtaG/VRC5Dc/gF1rOq88TkXzz8tYoy9L x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: a308c440-7c84-4314-cb8b-08d553608ffe x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(5600026)(4604075)(3008032)(2017052603307)(7153060); SRVR:DM5PR16MB1785; x-ms-traffictypediagnostic: DM5PR16MB1785: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(192374486261705)(21748063052155)(123452027830198); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040470)(2401047)(5005006)(8121501046)(3002001)(3231023)(944501075)(93006095)(93001095)(10201501046)(6041268)(20161123558120)(20161123560045)(20161123564045)(20161123562045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(6072148)(201708071742011); SRVR:DM5PR16MB1785; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:DM5PR16MB1785; x-forefront-prvs: 054231DC40 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39380400002)(346002)(396003)(366004)(376002)(39860400002)(32952001)(51444003)(15404003)(199004)(189003)(110136005)(7736002)(59450400001)(9326002)(14454004)(478600001)(81166006)(2900100001)(81156014)(2950100002)(316002)(76176011)(8936002)(99286004)(102836004)(68736007)(7696005)(2501003)(72206003)(53546011)(6506007)(25786009)(77096006)(66066001)(3280700002)(5660300001)(6116002)(3846002)(790700001)(229853002)(6246003)(53936002)(74316002)(86362001)(8676002)(6436002)(106356001)(19609705001)(9686003)(54896002)(2906002)(33656002)(80792005)(236005)(97736004)(6306002)(3660700001)(55016002)(105586002)(93886005)(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) x-microsoft-antispam-message-info: dcQlPUk2pjud4yowT0DF0qJKEmFvHqFqZ5rtttUNQki+nIPb2j6GEHkbma/EUtBD+6w4xWGuBbJHtl/TarNrBw== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_DM5PR16MB1788EF16E29C70152D0B8865EA1F0DM5PR16MB1788namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: a308c440-7c84-4314-cb8b-08d553608ffe X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Jan 2018 10:47:33.8411 (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 <6192> : inlines <6293> : streams <1775070> : uri <2562906> Archived-At: Subject: Re: [Dots] Using SNI 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, 04 Jan 2018 10:47:44 -0000 --_000_DM5PR16MB1788EF16E29C70152D0B8865EA1F0DM5PR16MB1788namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Jon, Thanks, I now understand your concerns :) Proposed text: The SNI extension [RFC6066] defines a mechanism for a client to tell a (D)T= LS server the name of the server it wants to contact. This is a useful ext= ension for hosting environments where multiple virtual servers are run on a= single IP address. The DOTS client may or may not know if it is interactin= g with a DOTS server in the hosting environment, so the DOTS client SHOULD = include the DOTS server FQDN in the SNI extension. Cheers, -Tiru From: Jon Shallow [mailto:supjps-ietf@jpshallow.com] Sent: Thursday, January 4, 2018 1:45 PM To: Konda, Tirumaleswar Reddy ; dots@ie= tf.org Subject: RE: [Dots] Using SNI Hi Tiru, I do not think that this is about validation, and unlikely to be used by th= e DOTS client to validate the DOTS server identity (yes, the DOTS server co= uld present different certificates based on the SNI, but not sure how that = helps the DOS client to validate). To me, it is all about the ability of the DOTS server to be able to decide = which security policy to install for the incoming connection - is this a DO= TS connection or is this a request to access a GUI or is this for a RESTful= interface etc. etc. ? - all on the same IP and port - the decision is keye= d off the SNI information. Part of the challenge I have here is that the data channel root discovery a= gainst port 443 ideally has to have the same security requirements as when = the data channel is used for aliases and filter updating. So even if root = discovery redirects the DOTS connection to a different port, the correct se= curity policy still needs to applied to DOTS client root discovery and a di= fferent policy applied for the GUI connection. If a peer certificate is to= be requested for mutual authentication checks in a DOTS connection, reques= ting a peer certificate from a browser fails (unless a specific peer cert i= s installed in the browser - impractical scaling request) and so GUI access= will fail. One policy (DOTS) needs to request the peer cert, the other (G= UI) must not request a peer cert. SNI is the only way I have found to hand= le this. I also do not think it is limited to PKI for DOTS - as mentioned below, acc= essing psk-dotsserver.somewhere.com or pki-dotsserver.somewhere.com along w= ith the appropriate SNI information, the DOTS server can easily decide to i= nstall a PSK or PKI security policy. The DOTS client needs to be able to provide the SNI information - it is up = to the DOTS server as to how it is used (which could be to ignore it) - to = provide DOTS vender interoperability. So, no, I am not comfortable with your suggestion. Regards Jon From: Dots [mailto: dots-bounces@ietf.org] On= Behalf Of Konda, Tirumaleswar Reddy Sent: 04 January 2018 07:19 To: Jon Shallow; dots@ietf.org Subject: Re: [Dots] Using SNI Hi Jon, How about the following line instead ? "If PKI-based authentication is used by the DOTS client to validate the DOT= S server identity, the DOTS client SHOULD include DOTS server FQDN in the s= erver name indication extension (Section 3 of RFC6066)." Cheers, -Tiru From: Jon Shallow [mailto:supjps-ietf@jpshallow.com] Sent: Wednesday, January 3, 2018 4:17 PM To: Konda, Tirumaleswar Reddy >; dots@ietf.org Subject: RE: [Dots] Using SNI Hi Tiru, My main goal here is to make sure that we can have DOTS vendor interoperabi= lity. As found during my implementation, having certain things in place he= lps considerably - providing strong hints to the implementer as to what sho= uld be available for interoperability helps. Instead of "If TLS client certificate is used to authenticate the DOTS client, the DOT= S client MUST include the DOTS server FQDN in server name indication extens= ion (Section 3 of RFC6066)." We could perhaps have "The DOTS client MUST support enabling the use of SNI (Section 3 of RFC6066= ). When enabled, this SHOULD include the DOTS server FQDN in the server na= me indication extension." As an aside, I have been able to get my DOTS server to support both PKI and= PSK, thus supporting a mix of PKI and PSK DOTS clients being active at the= same time (I agree this is not a generally recommended case). This was no= t done using SNI, but would have been considerably easier to implement if u= sing SNI and the PSK clients talked to psk-dotsserver.somewhere.com and PKI= clients talked to pki-dotsserver.somewhere.com - both DNS resolving to the= same IP. So being able to use SNI in both the signal and data channels makes sense t= o me. Regards Jon From: Dots [mailto: dots-bounces@ietf.org] On= Behalf Of Konda, Tirumaleswar Reddy Sent: 03 January 2018 07:21 To: Jon Shallow; dots@ietf.org Subject: Re: [Dots] Using SNI Hi Jon, We may want to use "SHOULD" instead of "MUST" in the below line (for exampl= e, SNI is not required if the DOTS client and server are in the same enterp= rise network). -TIru From: Jon Shallow [mailto:supjps-ietf@jpshallow.com] Sent: Tuesday, January 2, 2018 3:30 PM To: Konda, Tirumaleswar Reddy >; dots@ietf.org Subject: RE: [Dots] Using SNI Hi Tiru, That certainly works for me - thanks Regards Jon From: Dots [mailto: dots-bounces@ietf.org] On= Behalf Of Konda, Tirumaleswar Reddy Sent: 02 January 2018 09:55 To: Jon Shallow; dots@ietf.org Subject: Re: [Dots] Using SNI Hi Jon, RESTCONF does not mandate client authentication based on TLS client certifi= cate, we can say the following instead: If TLS client certificate is used to authenticate the DOTS client, the DOTS= client MUST include the DOTS server FQDN in server name indication extensi= on (Section 3 of RFC6066). Cheers, -Tiru From: Jon Shallow [mailto:supjps-ietf@jpshallow.com] Sent: Tuesday, January 2, 2018 3:10 PM To: Konda, Tirumaleswar Reddy >; dots@ietf.org Subject: RE: [Dots] Using SNI Hi Tiru, I agree that (indirectly through RFC7525 reference) SNI is mandated to be s= upported (but not necessarily has to be used). However, to guarantee interoperability between different DOTS vendors, I am= saying that the use of SNI is a MUST - in particular for the data channel. Regards Jon From: Dots [mailto: dots-bounces@ietf.org] On= Behalf Of Konda, Tirumaleswar Reddy Sent: 02 January 2018 08:48 To: Jon Shallow; dots@ietf.org Subject: Re: [Dots] Using SNI Hi Jon, Both signal and data channel drafts refer to RFC7525 for secure use of (D)T= LS and RFC7525 mandates TLS implementations to support SNI. I don't see the= need to explicitly discuss SNI in these drafts. Regards, -Tiru From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Jon Shallow Sent: Saturday, December 30, 2017 4:57 PM To: dots@ietf.org Subject: [Dots] Using SNI Hi WG, When providing a DOTS server data channel service in my environment, this s= hares the same ip / port which also provides other services (e.g. GUI / RES= T server etc.). Even if the Root Discovery points to another IP and or por= t for the actual data channel activity, the TLS exchanges for the Root Disc= overy have to correctly work. I suspect that I am not the only DOTS vendor= who will have this type of requirement of a single IP providing multiple T= LS services. As DOTS requires mutual authentication, this is a different security requir= ement than required by the GUI environment (DOTS requires client cert to be= presented, GUI does not and providing certificates to every GUI client is = not a practical option). This can be handled by using SNI by using 2 different FQDNs and requiring t= he DOTS client to include the DOTS specific FQDN in the TLS Client Hello. = Whether the GUI client does or does not (likely does with modern browsers) = include a SNI FQDN when connecting to the non DOTS FQDN does not really mat= ter - for DOTS it is recognizing the DOTS specific FQDN and setting up the = TLS as appropriate. To make sure interoperability between DOTS vendors, I would like to see som= ething like added to the data channel spec "DOTS clients MUST include the D= OTS server FQDN in the TLS Client Hello packet by using Server Name Indicat= ion (SNI) RFC 3546". In addition, I think that this would be a good idea as well for the signal = draft - thereby giving DOTS vendors the opportunity to host multiple DOTS s= ervers (likely to be different security requirements for their different cl= ient) on a single IP / port. Thoughts / comments? Regards Jon --_000_DM5PR16MB1788EF16E29C70152D0B8865EA1F0DM5PR16MB1788namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Jon,

&nbs= p;

Thanks, I= now understand your concerns J  

&nbs= p;

Proposed = text:

The SNI e= xtension [RFC6066] defines a mechanism for a client to tell a (D)TLS server= the name of the server it wants to contact.  This is a useful extensi= on for hosting environments where multiple virtual servers are run on a single IP address. The DOTS client may or may= not know if it is interacting with a DOTS server in the hosting environmen= t, so the DOTS client SHOULD include the DOTS server FQDN in the SNI extens= ion.

&nbs= p;

Cheers,

-Tiru

 

From:<= /span> Jon Shallow [mailto:s= upjps-ietf@jpshallow.com]
Sent: Thursday, January 4, 2018 1:45 PM
To: Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@McAfee.com= >; dots@ietf.org
Subject: RE: [Dots] Using SNI

 

Hi Tiru= ,

&n= bsp;

I do no= t think that this is about validation, and unlikely to be used by the DOTS = client to validate the DOTS server identity (yes, the DOTS server could pre= sent different certificates based on the SNI, but not sure how that helps the DOS client to validate).

&n= bsp;

To me, = it is all about the ability of the DOTS server to be able to decide which s= ecurity policy to install for the incoming connection – is this a DOT= S connection or is this a request to access a GUI or is this for a RESTful interface etc. etc. ? – all on the sa= me IP and port – the decision is keyed off the SNI information.<= /o:p>

&n= bsp;

Part of= the challenge I have here is that the data channel root discovery against = port 443 ideally has to have the same security requirements as when the dat= a channel is used for aliases and filter updating.  So even if root discovery redirects the DOTS connection to= a different port, the correct security policy still needs to applied to DO= TS client root discovery and a different policy applied for the GUI connect= ion.  If a peer certificate is to be requested for mutual authentication checks in a DOTS connection, requestin= g a peer certificate from a browser fails (unless a specific peer cert is i= nstalled in the browser – impractical scaling request) and so GUI acc= ess will fail.  One policy (DOTS) needs to request the peer cert, the other (GUI) must not request a peer cert.&nb= sp; SNI is the only way I have found to handle this.

&n= bsp;

I also = do not think it is limited to PKI for DOTS – as mentioned below, acce= ssing psk-dotsserver.somewhere.com or pki-dotsserver.somewhere.com along w= ith the appropriate SNI information, the DOTS server can easily decide to i= nstall a PSK or PKI security policy.

 

The DOTS client needs to be able to provide the SNI = information – it is up to the DOTS server as to how it is used (which= could be to ignore it) – to provide DOTS vender interoperability.

 

So, no, I am not comfortable with your suggestion.

 

Regards

 

Jon

&n= bsp;

From: Dots [mailto: dots-bounces@ietf.org] On B= ehalf Of Konda, Tirumaleswar Reddy
Sent: 04 January 2018 07:19
To: Jon Shallow; dots@ietf.org<= br> Subject: Re: [Dots] Using SNI

 

Hi Jon,

&nbs= p;

How about= the following line instead ?

“If PKI-based authentication is used by the DOT= S client to validate the DOTS server identity, the DOTS client SHOULD inclu= de DOTS server FQDN in the server name indication extension (Section 3 of RFC6066).”

Cheers,

-Tiru

&nbs= p;

From:<= /span> Jon Shallow [mailto:supjps-ietf@jpshallow.com]
Sent: Wednesday, January 3, 2018 4:17 PM
To: Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@McAfee.com>; dots@ietf.org
Subject: RE: [Dots] Using SNI

 

Hi Tiru= ,

&n= bsp;

My main= goal here is to make sure that we can have DOTS vendor interoperability.&n= bsp; As found during my implementation, having certain things in place help= s considerably – providing strong hints to the implementer as to what should be available for interoperability helps.=

&n= bsp;

Instead of 
 
“If TLS client certificate is used to authe=
nticate the DOTS client, the DOTS client MUST include the DOTS server FQDN =
in server name indication extension (Section 3 of RFC6066).”
 
We could perhaps have
 
“The DOTS client MUST support enabling the use of SNI (Section =
3 of RFC6066).  When enabled, this SHOULD include the DOTS server FQDN=
 in the server name indication extension.”
 
As an aside, I have been able to get my DOTS server to support both P=
KI and PSK, thus supporting a mix of PKI and PSK DOTS clients being active =
at the same time (I agree this is not a generally recommended case).  =
This was not done using SNI, but would have been considerably easier to imp=
lement if using SNI and the PSK clients talked to psk-dotsserver.somewhere.=
com and PKI clients talked to pki-dotsserver.somewhere.com – both DNS=
 resolving to the same IP.
 
So being able to use SNI in both the signal and data channels makes s=
ense to me.

&n= bsp;

Regards=

&n= bsp;

Jon

&n= bsp;

From: Dots [mailto: dots-bounces@ietf.org] On B= ehalf Of Konda, Tirumaleswar Reddy
Sent: 03 January 2018 07:21
To: Jon Shallow; dots@ietf.org<= br> Subject: Re: [Dots] Using SNI

 

Hi Jon,

&nbs= p;

We may wa= nt to use “SHOULD” instead of “MUST” in the below l= ine (for example, SNI is not required if the DOTS client and server are in = the same enterprise network).

&nbs= p;

-TIru

&nbs= p;

From:<= /span> Jon Shallow [mailto:supjps-ietf@jpshallow.com]
Sent: Tuesday, January 2, 2018 3:30 PM
To: Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@McAfee.com>; dots@ietf.org
Subject: RE: [Dots] Using SNI

 

Hi Tiru= ,

&n= bsp;

That ce= rtainly works for 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: 02 January 2018 09:55
To: Jon Shallow; dots@ietf.org<= br> Subject: Re: [Dots] Using SNI

 

Hi Jon,
 
RESTCONF does not mandate client authentication based on TLS client c=
ertificate, we can say the following instead:
If TLS client certificate is used to authenticate the DOTS client, th=
e DOTS client MUST include the DOTS server FQDN in server name indication e=
xtension (Section 3 of RFC6066).
 
Cheers,
-Tiru
 

From:<= /span> Jon Shallow [mailto:supjps-ietf@jpshallow.com]
Sent: Tuesday, January 2, 2018 3:10 PM
To: Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@McAfee.com>; dots@ietf.org
Subject: RE: [Dots] Using SNI

 

Hi Tiru= ,

&n= bsp;

I agree= that (indirectly through RFC7525 reference) SNI is mandated to be supporte= d (but not necessarily has to be used).

&n= bsp;

However= , to guarantee interoperability between different DOTS vendors, I am saying= that the use of SNI is a MUST – in particular for the data channel.<= o:p>

&n= bsp;

Regards=

&n= bsp;

Jon

&n= bsp;

From: Dots [mailto: dots-bounces@ietf.org] On B= ehalf Of Konda, Tirumaleswar Reddy
Sent: 02 January 2018 08:48
To: Jon Shallow; dots@ietf.org<= br> Subject: Re: [Dots] Using SNI

 

Hi Jon,

&nbs= p;

Both sign= al and data channel drafts refer to RFC7525 for secure use of (D)TLS and RF= C7525 mandates TLS implementations to support SNI. I don’t see the ne= ed to explicitly discuss SNI in these drafts.


Regards,

-Tiru

&nbs= p;

From:<= /span> Dots [mailto:dots-bounces@ietf.org] On Behalf Of Jon Shallow
Sent: Saturday, December 30, 2017 4:57 PM
To: dots@ietf.org
Subject: [Dots] Using SNI

 

Hi WG,

 

When providing a DOTS server da= ta channel service in my environment, this shares the same ip / port which = also provides other services (e.g. GUI / REST server etc.).  Even if t= he Root Discovery points to another IP and or port for the actual data channel activity, the TLS exchanges for the Ro= ot Discovery have to correctly work.  I suspect that I am not the only= DOTS vendor who will have this type of requirement of a single IP providin= g multiple TLS services.

 

As DOTS requires mutual authent= ication, this is a different security requirement than required by the GUI = environment (DOTS requires client cert to be presented, GUI does not and pr= oviding certificates to every GUI client is not a practical option).

 

This can be handled by using SN= I by using 2 different FQDNs and requiring the DOTS client to include the D= OTS specific FQDN in the TLS Client Hello.  Whether the GUI client doe= s or does not (likely does with modern browsers) include a SNI FQDN when connecting to the non DOTS FQDN does not really ma= tter – for DOTS it is recognizing the DOTS specific FQDN and setting = up the TLS as appropriate.

 

To make sure interoperability b= etween DOTS vendors, I would like to see something like added to the data c= hannel spec “DOTS clients MUST include the DOTS server FQDN in the TL= S Client Hello packet by using Server Name Indication (SNI) RFC 3546”.

 

In addition, I think that this = would be a good idea as well for the signal draft – thereby giving DO= TS vendors the opportunity to host multiple DOTS servers (likely to be diff= erent security requirements for their different client) on a single IP / port.

 

Thoughts / comments?=

 

Regards

 

Jon

--_000_DM5PR16MB1788EF16E29C70152D0B8865EA1F0DM5PR16MB1788namp_-- From nobody Thu Jan 4 02:54:40 2018 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 D40F01200C5 for ; Thu, 4 Jan 2018 02:54:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.33 X-Spam-Level: X-Spam-Status: No, score=-4.33 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, T_RP_MATCHES_RCVD=-0.01] 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 hmJsHd47HK6w for ; Thu, 4 Jan 2018 02:54: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 8AF15120727 for ; Thu, 4 Jan 2018 02:54:35 -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=1515063274; 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: x-microsoft-antispam-message-info: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=p8viwfBHeV9iWcqlkvqIqT6C1nH2ccsFV2RUdi /ojSw=; b=G9zO1o3xKATLbDR7W6lS2Sf20XQWLDDQSu0Bk/Dz gt3RWz4hrvuErMAi8ZSM4v50hdA4qROhMRdy299HbOTpaAjejq nB1PYWG2+GXi/1DomCctV1LutNC1d8BrXs0qnLFUPJ+zzEJJLW RN1eVXCuwRJe9R/rklw9z96uV5nr5u0= Received: from DNVEXAPP1N06.corpzone.internalzone.com (unknown [10.44.48.90]) by DNVWSMAILOUT1.mcafee.com with smtp (TLS: TLSv1/SSLv3,256bits,ECDHE-RSA-AES256-SHA384) id 3f34_a753_ceb971b7_cb6a_474d_a4b9_7b894fc5634d; Thu, 04 Jan 2018 04:54:34 -0600 Received: from DNVEXUSR1N12.corpzone.internalzone.com (10.44.48.85) by DNVEXAPP1N06.corpzone.internalzone.com (10.44.48.90) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Thu, 4 Jan 2018 03:54:33 -0700 Received: from DNVEXAPP1N04.corpzone.internalzone.com (10.44.48.88) by DNVEXUSR1N12.corpzone.internalzone.com (10.44.48.85) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Thu, 4 Jan 2018 03:54:32 -0700 Received: from DNVO365EDGE1.corpzone.internalzone.com (10.44.176.66) by DNVEXAPP1N04.corpzone.internalzone.com (10.44.48.88) with Microsoft SMTP Server (TLS) id 15.0.1347.2 via Frontend Transport; Thu, 4 Jan 2018 03:54:32 -0700 Received: from NAM03-DM3-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, 4 Jan 2018 03:54:31 -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.366.8; Thu, 4 Jan 2018 10:54: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.0366.009; Thu, 4 Jan 2018 10:54:31 +0000 From: "Konda, Tirumaleswar Reddy" To: Jon Shallow , "dots@ietf.org" Thread-Topic: [Dots] Mutual Authentication between DOTS peers Thread-Index: AdOD7c3U3eTi3IQ0SPSETf2VuKuPkwAdoEmgAAhkl4AAKgva4A== Date: Thu, 4 Jan 2018 10:54:30 +0000 Message-ID: References: <0bf201d383ed$cdf63970$69e2ac50$@jpshallow.com> <0cab01d38485$e1bc09b0$a5341d10$@jpshallow.com> In-Reply-To: <0cab01d38485$e1bc09b0$a5341d10$@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; 7:LSIUbZiIGu2gVEqVA7GvIok2i4S6LE8H0XuK7/asMSvQjX4xxwTEQASdmbuKUXI5NT+VFvYNS5Sh+7Y3U7I+QQ7H4O+bQqi+fgTusiZBfQA5kwOFqIRwkdjGFkQh2vcQr5lKC7pHBWXzSsEBBpiTd+dbWr3W7RiLNJMIse1VaR1Ujk1FM5hV5D5V01D0zXduEZayp1+Q49siDl5sJMvfoJY8P/FMyYu8zBX/+/M2PlpLxvNncG5rAdJQ0mhvlKjL x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 7ee27315-21f8-47fe-8172-08d553618893 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(5600026)(4604075)(3008032)(2017052603307)(7153060); SRVR:DM5PR16MB1788; x-ms-traffictypediagnostic: DM5PR16MB1788: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(21748063052155)(123452027830198); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040470)(2401047)(8121501046)(5005006)(10201501046)(93006095)(93001095)(3231023)(944501075)(3002001)(6041268)(20161123558120)(20161123564045)(20161123560045)(20161123562045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(6072148)(201708071742011); SRVR:DM5PR16MB1788; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:DM5PR16MB1788; x-forefront-prvs: 054231DC40 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39380400002)(346002)(376002)(366004)(39840400004)(396003)(32952001)(189003)(51914003)(199004)(3660700001)(19609705001)(53936002)(99286004)(2906002)(81156014)(6506007)(80792005)(14454004)(102836004)(53546011)(59450400001)(81166006)(229853002)(76176011)(8676002)(7696005)(97736004)(68736007)(25786009)(33656002)(6246003)(6436002)(55016002)(72206003)(74316002)(8936002)(790700001)(9326002)(5660300001)(6116002)(2950100002)(3846002)(6306002)(77096006)(966005)(478600001)(54896002)(236005)(2501003)(2900100001)(106356001)(316002)(105586002)(3280700002)(606006)(7736002)(66066001)(9686003)(110136005)(86362001)(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; x-microsoft-antispam-message-info: 8DwuIP5NkU1a/kIayB2U6ON7UTXdUNpi7Y4CeG721xNYwPjnzuDes7S9OiX1WbtkreKSk7LmV+f2smPvRRz1TA== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_DM5PR16MB178840C86EEE06A4F723570DEA1F0DM5PR16MB1788namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 7ee27315-21f8-47fe-8172-08d553618893 X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Jan 2018 10:54:30.9375 (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 <6192> : inlines <6293> : streams <1775071> : uri <2562910> Archived-At: Subject: Re: [Dots] Mutual Authentication between DOTS peers 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, 04 Jan 2018 10:54:39 -0000 --_000_DM5PR16MB178840C86EEE06A4F723570DEA1F0DM5PR16MB1788namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Jon, Please see inline [TR2] From: Jon Shallow [mailto:supjps-ietf@jpshallow.com] Sent: Wednesday, January 3, 2018 4:58 PM To: Konda, Tirumaleswar Reddy ; dots@ie= tf.org Subject: RE: [Dots] Mutual Authentication between DOTS peers Hi Tiru, See inline [Jon] Regards Jon From: Dots [mailto: dots-bounces@ietf.org] On= Behalf Of Konda, Tirumaleswar Reddy Sent: 03 January 2018 07:38 To: Jon Shallow; dots@ietf.org Subject: Re: [Dots] Mutual Authentication between DOTS peers Hi Jon, Thanks for the comments, please see inline. From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Jon Shallow Sent: Tuesday, January 2, 2018 10:49 PM To: dots@ietf.org Subject: [Dots] Mutual Authentication between DOTS peers Hi WG, Mutual Authentication is required between 2 DOTS peers, but then the drafts= do not make any suggestions that I have found as to how to do it other tha= n referring to EST. [TR] No, https://tools.ietf.org/html/draft-ietf-dots-signal-channel-14#sect= ion-7.1 discusses PKI, PSK and RPK and the data channel draft refers to thi= s section for mutual authentication b/w the DOTS agents. [Jon] I think I did not phrase this correctly. I was looking for (and henc= e defining as a best practice for DOTS) the specifics of what need to be ch= ecked (enforced) for mutual authentication. 7.1 does refer to a DOTS server= may present a PKIX certificate which the DOTS client then has to verify, b= ut nothing about how the DOTS server verifies the DOTS client. [I should h= ave referred to PKIX in my statement above]. [Jon] My DOTS server for instance (if PKI) requests the Peer Certificate fr= om the DOTS client - if it is not given, not authorized (CN or Subject Alte= rnative Name is not valid) or does not have common CA that signed both the = DOTS server and DOTS client certificates, then mutual authentication from t= he DOTS server perspective fails. [Jon] To me, it is the DOTS client that is most likely to be the rogue elem= ent. [TR] Good point, proposed text: The DOTS server SHOULD support certificate-based client authentication and = the DOTS client SHOULD respond to the DOTS server's TLS certificate request= message with the PKIX certificate held by the DOTS client. DOTS client certificate validatio= n MUST be performed as per [RFC5280] and the DOTS client certificate MUST c= onform to the [RFC5280] certificate profile. If a DOTS client does not support TLS cl= ient certificate authentication, then it MUST support pre-shared key based = or raw public key based client authentication. I want to make sure we have a set of alternatives in place as a minimum req= uirement for DOTS vendor interoperability. What I am planning to put into place (be more enforcing) in my DOTS impleme= ntation - comments welcome as well as additional suggestions. PKI Client and Server Certificates have to be signed by the same CA. The CA do= es not need to get exchanged during (D)TLS session set up. The CA does not= need to go back to a well-known root CA. PSK The DOTS client 'identity' (potentially FQDN of client) is used for validat= ing the client by the server, and the DOTS server 'identity-hint' (potentia= lly FQDN of server) is used by the client for validating the server. Obvio= usly they both share the same PSK! [TR] The "PSK_Identity" and "PSK identity hint" need not be FQDNs of the DO= TS client and server, https://tools.ietf.org/html/rfc4279#section-5 does no= t mandate a particular type of identity. [Jon] The next paragraph goes on to state "However, the TLS client and serv= er clearly have to agree on the identities and keys to be used." [Jon] Again for DOTS vendor interoperability, I think we should indicate wh= at is acceptable / best practice for DOTS. [Jon] While the DOTS server and DOTS client may be in the same client domai= n, it is possible that different DOTS vendors are supplying different compo= nents. [TR2] I don't see a DOTS vendor interoperability problem, using some out-of= -band mechanism DOTS client and DOTS server have to be provisioned with the= secret key and PSK identity. The DOTS client and server do not have to int= erpret or validate the PSK identity, it is only used to pick the associated= shared secret key. -Tiru RPK Nothing in place so far as I have not worked out how to get OpenSSL to do t= his for me so far, so have no suggestions here. Regards Jon --_000_DM5PR16MB178840C86EEE06A4F723570DEA1F0DM5PR16MB1788namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Jon,

&nbs= p;

Please se= e inline [TR2]

 

From:<= /span> Jon Shallow [mailto:s= upjps-ietf@jpshallow.com]
Sent: Wednesday, January 3, 2018 4:58 PM
To: Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@McAfee.com= >; dots@ietf.org
Subject: RE: [Dots] Mutual Authentication between DOTS peers

 

Hi Tiru,

 = ;

See inline= [Jon]

 = ;

Regards=

&n= bsp;

Jon

&n= bsp;

From: Dots [mailto: = dots-bounces@ietf.org] On Behalf Of Konda, Tirumaleswar Reddy
Sent: 03 January 2018 07:38
To: Jon Shallow; dots@ietf.org
Subject: Re: [Dots] Mutual Authentication between DOTS peers

 

Hi Jon,

&nbs= p;

Thanks fo= r the comments, please see inline.

&nbs= p;

From:<= /span> Dots [mailto:dots-bounces@ietf.org] On Behalf Of Jon Shallow
Sent: Tuesday, January 2, 2018 10:49 PM
To: dots@ietf.org
Subject: [Dots] Mutual Authentication between DOTS peers<= /span>

 

Hi WG,

 

Mutual Authentication is requir= ed between 2 DOTS peers, but then the drafts do not make any suggestions th= at I have found as to how to do it other than referring to EST.<= /span>

 

[TR] No, https://tools.ietf.org/html/draft-ietf-dots-signal-channel-14#section-7.1 discusses PKI, PSK and RPK and the data channel draft refers to this sec= tion for mutual authentication b/w the DOTS agents.

 

[Jon] I think I did no= t phrase this correctly.  I was looking for (and hence defining as a b= est practice for DOTS) the specifics of what need to be checked (enforced) = for mutual authentication. 7.1 does refer to a DOTS server may present a PKIX certificate which the DOTS client then= has to verify, but nothing about how the DOTS server verifies the DOTS cli= ent.  [I should have referred to PKIX in my statement above].

 

[Jon] My DOTS server f= or instance (if PKI) requests the Peer Certificate from the DOTS client = 211; if it is not given, not authorized (CN or Subject Alternative Name is = not valid) or does not have common CA that signed both the DOTS server and DOTS client certificates, then mutual auth= entication from the DOTS server perspective fails.

 

[Jon] To me, it is the= DOTS client that is most likely to be the rogue element.=

 

 

[TR] Good point, proposed text:

 

The DOTS server SHOULD = support certificate-based client authentication and the DOTS client SHOULD = respond to the DOTS server's TLS certificate request message with the

PKIX certificate held b= y the DOTS client. DOTS client certificate validation MUST be performed as = per [RFC5280] and the DOTS client certificate MUST conform to

the [RFC5280] certifica= te profile. If a DOTS client does not support TLS client certificate authen= tication, then it MUST support pre-shared key based or raw public key based

    client authentication.<= /o:p>

 

 

 

I want to make sure we have a s= et of alternatives in place as a minimum requirement for DOTS vendor intero= perability.

 

What I am planning to put into = place (be more enforcing) in my DOTS implementation – comments welcom= e as well as additional suggestions.

 

PKI

 

Client and Server Certificates = have to be signed by the same CA.  The CA does not need to get exchang= ed during (D)TLS session set up.  The CA does not need to go back to a= well-known root CA.

 

PSK

 

The DOTS client ‘identity= ’ (potentially FQDN of client) is used for validating the client by t= he server, and the DOTS server ‘identity-hint’ (potentially FQD= N of server) is used by the client for validating the server.  Obviously they both share the same PSK!

 

[TR] The “PSK_Identity= 221; and "PSK identity hint" need not be FQDNs of the DOTS client= and server, https://tools.ietf.org/html/rfc4279#section-5 does not mandate a particular type of identity.

 

[Jon] T= he next paragraph goes on to state “However, the TLS client and serve= r clearly have to agree on the identities and keys to be used.”<= /o:p>

&n= bsp;

[Jon] A= gain for DOTS vendor interoperability, I think we should indicate what is a= cceptable / best practice for DOTS.

[Jon] W= hile the DOTS server and DOTS client may be in the same client domain, it i= s possible that different DOTS vendors are supplying different components.<= o:p>

 

[TR2] I don’t see a DOTS = vendor interoperability problem, using some out-of-band mechanism DOTS clie= nt and DOTS server have to be provisioned with the secret key and PSK ident= ity. The DOTS client and server do not have to interpret or validate the PSK identity, it is only used to pick the ass= ociated shared secret key.

 

-Tiru

 

RPK

 

Nothing in place so far as I ha= ve not worked out how to get OpenSSL to do this for me so far, so have no s= uggestions here.

 

 

 

Regards

 

Jon

--_000_DM5PR16MB178840C86EEE06A4F723570DEA1F0DM5PR16MB1788namp_-- From nobody Thu Jan 4 02:55:22 2018 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 30229120727 for ; Thu, 4 Jan 2018 02:55:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 XFMqbP-DRttP for ; Thu, 4 Jan 2018 02:55:15 -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 A33921200C5 for ; Thu, 4 Jan 2018 02:55: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 1eX3B3-0008JP-1k; Thu, 04 Jan 2018 10:55:13 +0000 From: "Jon Shallow" To: "'Konda, Tirumaleswar Reddy'" , References: <0a1201d38161$299ef350$7cdcd9f0$@jpshallow.com> <0b2301d383ad$a8822a40$f9867ec0$@jpshallow.com> <0b4b01d383b0$758f1370$60ad3a50$@jpshallow.com> <0c8c01d38480$3a6ba5d0$af42f170$@jpshallow.com> <0d4901d38534$23d56ea0$6b804be0$@jpshallow.com> In-Reply-To: Date: Thu, 4 Jan 2018 10:55:12 -0000 Message-ID: <0da101d3854a$7ea84f30$7bf8ed90$@jpshallow.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0DA2_01D3854A.7EAA9920" X-Mailer: Microsoft Outlook 14.0 Content-Language: en-gb Thread-Index: AQIpdHJXTEWkUmLWfrWfFs+hkFSqvAJ19VeLAlAhTlAB/1BuRQHRwg9pAM+YE+cClEN/FAIrAz1UAluQDYgCdtUB9qIf57kA Archived-At: Subject: Re: [Dots] Using SNI 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, 04 Jan 2018 10:55:19 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0DA2_01D3854A.7EAA9920 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Tiru, That is much better. However for additional clarity, it may be better to say The SNI extension [RFC6066] defines a mechanism for a client to tell a (D)TLS server the name of the server it wants to contact. This is a useful extension for hosting environments where multiple virtual servers are run on a single IP address. The DOTS client may or may not know if it is interacting with a DOTS server in a virtual server hosting environment, so the DOTS client SHOULD include the DOTS server FQDN in the SNI extension. Regards Jon From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of Konda, Tirumaleswar Reddy Sent: 04 January 2018 10:48 To: Jon Shallow; dots@ietf.org Subject: Re: [Dots] Using SNI Hi Jon, Thanks, I now understand your concerns J Proposed text: The SNI extension [RFC6066] defines a mechanism for a client to tell a (D)TLS server the name of the server it wants to contact. This is a useful extension for hosting environments where multiple virtual servers are run on a single IP address. The DOTS client may or may not know if it is interacting with a DOTS server in the hosting environment, so the DOTS client SHOULD include the DOTS server FQDN in the SNI extension. Cheers, -Tiru From: Jon Shallow [mailto:supjps-ietf@jpshallow.com] Sent: Thursday, January 4, 2018 1:45 PM To: Konda, Tirumaleswar Reddy ; dots@ietf.org Subject: RE: [Dots] Using SNI Hi Tiru, I do not think that this is about validation, and unlikely to be used by the DOTS client to validate the DOTS server identity (yes, the DOTS server could present different certificates based on the SNI, but not sure how that helps the DOS client to validate). To me, it is all about the ability of the DOTS server to be able to decide which security policy to install for the incoming connection - is this a DOTS connection or is this a request to access a GUI or is this for a RESTful interface etc. etc. ? - all on the same IP and port - the decision is keyed off the SNI information. Part of the challenge I have here is that the data channel root discovery against port 443 ideally has to have the same security requirements as when the data channel is used for aliases and filter updating. So even if root discovery redirects the DOTS connection to a different port, the correct security policy still needs to applied to DOTS client root discovery and a different policy applied for the GUI connection. If a peer certificate is to be requested for mutual authentication checks in a DOTS connection, requesting a peer certificate from a browser fails (unless a specific peer cert is installed in the browser - impractical scaling request) and so GUI access will fail. One policy (DOTS) needs to request the peer cert, the other (GUI) must not request a peer cert. SNI is the only way I have found to handle this. I also do not think it is limited to PKI for DOTS - as mentioned below, accessing psk-dotsserver.somewhere.com or pki-dotsserver.somewhere.com along with the appropriate SNI information, the DOTS server can easily decide to install a PSK or PKI security policy. The DOTS client needs to be able to provide the SNI information - it is up to the DOTS server as to how it is used (which could be to ignore it) - to provide DOTS vender interoperability. So, no, I am not comfortable with your suggestion. Regards Jon From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of Konda, Tirumaleswar Reddy Sent: 04 January 2018 07:19 To: Jon Shallow; dots@ietf.org Subject: Re: [Dots] Using SNI Hi Jon, How about the following line instead ? "If PKI-based authentication is used by the DOTS client to validate the DOTS server identity, the DOTS client SHOULD include DOTS server FQDN in the server name indication extension (Section 3 of RFC6066)." Cheers, -Tiru From: Jon Shallow [mailto:supjps-ietf@jpshallow.com] Sent: Wednesday, January 3, 2018 4:17 PM To: Konda, Tirumaleswar Reddy ; dots@ietf.org Subject: RE: [Dots] Using SNI Hi Tiru, My main goal here is to make sure that we can have DOTS vendor interoperability. As found during my implementation, having certain things in place helps considerably - providing strong hints to the implementer as to what should be available for interoperability helps. Instead of "If TLS client certificate is used to authenticate the DOTS client, the DOTS client MUST include the DOTS server FQDN in server name indication extension (Section 3 of RFC6066)." We could perhaps have "The DOTS client MUST support enabling the use of SNI (Section 3 of RFC6066). When enabled, this SHOULD include the DOTS server FQDN in the server name indication extension." As an aside, I have been able to get my DOTS server to support both PKI and PSK, thus supporting a mix of PKI and PSK DOTS clients being active at the same time (I agree this is not a generally recommended case). This was not done using SNI, but would have been considerably easier to implement if using SNI and the PSK clients talked to psk-dotsserver.somewhere.com and PKI clients talked to pki-dotsserver.somewhere.com - both DNS resolving to the same IP. So being able to use SNI in both the signal and data channels makes sense to me. Regards Jon From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of Konda, Tirumaleswar Reddy Sent: 03 January 2018 07:21 To: Jon Shallow; dots@ietf.org Subject: Re: [Dots] Using SNI Hi Jon, We may want to use "SHOULD" instead of "MUST" in the below line (for example, SNI is not required if the DOTS client and server are in the same enterprise network). -TIru From: Jon Shallow [mailto:supjps-ietf@jpshallow.com] Sent: Tuesday, January 2, 2018 3:30 PM To: Konda, Tirumaleswar Reddy ; dots@ietf.org Subject: RE: [Dots] Using SNI Hi Tiru, That certainly works for me - thanks Regards Jon From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of Konda, Tirumaleswar Reddy Sent: 02 January 2018 09:55 To: Jon Shallow; dots@ietf.org Subject: Re: [Dots] Using SNI Hi Jon, RESTCONF does not mandate client authentication based on TLS client certificate, we can say the following instead: If TLS client certificate is used to authenticate the DOTS client, the DOTS client MUST include the DOTS server FQDN in server name indication extension (Section 3 of RFC6066). Cheers, -Tiru From: Jon Shallow [mailto:supjps-ietf@jpshallow.com] Sent: Tuesday, January 2, 2018 3:10 PM To: Konda, Tirumaleswar Reddy ; dots@ietf.org Subject: RE: [Dots] Using SNI Hi Tiru, I agree that (indirectly through RFC7525 reference) SNI is mandated to be supported (but not necessarily has to be used). However, to guarantee interoperability between different DOTS vendors, I am saying that the use of SNI is a MUST - in particular for the data channel. Regards Jon From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of Konda, Tirumaleswar Reddy Sent: 02 January 2018 08:48 To: Jon Shallow; dots@ietf.org Subject: Re: [Dots] Using SNI Hi Jon, Both signal and data channel drafts refer to RFC7525 for secure use of (D)TLS and RFC7525 mandates TLS implementations to support SNI. I don't see the need to explicitly discuss SNI in these drafts. Regards, -Tiru From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Jon Shallow Sent: Saturday, December 30, 2017 4:57 PM To: dots@ietf.org Subject: [Dots] Using SNI Hi WG, When providing a DOTS server data channel service in my environment, this shares the same ip / port which also provides other services (e.g. GUI / REST server etc.). Even if the Root Discovery points to another IP and or port for the actual data channel activity, the TLS exchanges for the Root Discovery have to correctly work. I suspect that I am not the only DOTS vendor who will have this type of requirement of a single IP providing multiple TLS services. As DOTS requires mutual authentication, this is a different security requirement than required by the GUI environment (DOTS requires client cert to be presented, GUI does not and providing certificates to every GUI client is not a practical option). This can be handled by using SNI by using 2 different FQDNs and requiring the DOTS client to include the DOTS specific FQDN in the TLS Client Hello. Whether the GUI client does or does not (likely does with modern browsers) include a SNI FQDN when connecting to the non DOTS FQDN does not really matter - for DOTS it is recognizing the DOTS specific FQDN and setting up the TLS as appropriate. To make sure interoperability between DOTS vendors, I would like to see something like added to the data channel spec "DOTS clients MUST include the DOTS server FQDN in the TLS Client Hello packet by using Server Name Indication (SNI) RFC 3546". In addition, I think that this would be a good idea as well for the signal draft - thereby giving DOTS vendors the opportunity to host multiple DOTS servers (likely to be different security requirements for their different client) on a single IP / port. Thoughts / comments? Regards Jon ------=_NextPart_000_0DA2_01D3854A.7EAA9920 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Tiru,

 

That is much = better.  However for additional clarity, it may be better to = say

 

The SNI extension [RFC6066] defines = a mechanism for a client to tell a (D)TLS server the name of the server = it wants to contact.  This is a useful extension for hosting = environments where multiple virtual servers are run on a single IP = address. The DOTS client may or may not know if it is interacting with a = DOTS server in a virtual server hosting environment, so = the DOTS client SHOULD include the DOTS server FQDN in the SNI = extension.

 

Regards

 

Jon

 

From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of = Konda, Tirumaleswar Reddy
Sent: 04 January 2018 = 10:48
To: Jon Shallow; dots@ietf.org
Subject: Re: = [Dots] Using SNI

 

Hi = Jon,

 

Thanks, I now understand your = concerns J =  

 

Proposed = text:

The SNI extension [RFC6066] defines = a mechanism for a client to tell a (D)TLS server the name of the server = it wants to contact.  This is a useful extension for hosting = environments where multiple virtual servers are run on a single IP = address. The DOTS client may or may not know if it is interacting with a = DOTS server in the hosting environment, so the DOTS client SHOULD = include the DOTS server FQDN in the SNI = extension.

 

Cheers,

-Tiru

 

From: Jon Shallow [mailto:supjps-ietf@jpshallow.co= m]
Sent: Thursday, January 4, 2018 1:45 PM
To: = Konda, Tirumaleswar Reddy <TirumaleswarReddy_Kond= a@McAfee.com>; dots@ietf.org
Subject: RE: = [Dots] Using SNI

 

Hi = Tiru,

 

I do not think that this = is about validation, and unlikely to be used by the DOTS client to = validate the DOTS server identity (yes, the DOTS server could present = different certificates based on the SNI, but not sure how that helps the = DOS client to validate).

 

To me, it is all about = the ability of the DOTS server to be able to decide which security = policy to install for the incoming connection – is this a DOTS = connection or is this a request to access a GUI or is this for a RESTful = interface etc. etc. ? – all on the same IP and port – the = decision is keyed off the SNI information.

 

Part of the challenge I = have here is that the data channel root discovery against port 443 = ideally has to have the same security requirements as when the data = channel is used for aliases and filter updating.  So even if root = discovery redirects the DOTS connection to a different port, the correct = security policy still needs to applied to DOTS client root discovery and = a different policy applied for the GUI connection.  If a peer = certificate is to be requested for mutual authentication checks in a = DOTS connection, requesting a peer certificate from a browser fails = (unless a specific peer cert is installed in the browser – = impractical scaling request) and so GUI access will fail.  One = policy (DOTS) needs to request the peer cert, the other (GUI) must not = request a peer cert.  SNI is the only way I have found to handle = this.

 

I also do not think it = is limited to PKI for DOTS – as mentioned below, accessing = psk-dotsserver.somewhere.com or = pki-dotsserver.somewhere.com along with the appropriate SNI information, = the DOTS server can easily decide to install a PSK or PKI security = policy.

 

The DOTS client needs to be able to provide the SNI = information – it is up to the DOTS server as to how it is used = (which could be to ignore it) – to provide DOTS vender = interoperability.

 

So, no, I am not comfortable with your = suggestion.

 

Regards

 

Jon

 

From: Dots [mailto: dots-bounces@ietf.org] On = Behalf Of Konda, Tirumaleswar Reddy
Sent: 04 January 2018 = 07:19
To: Jon Shallow; dots@ietf.org
Subject: Re: = [Dots] Using SNI

 

Hi = Jon,

 

How about the following line = instead ?

“If PKI-based authentication = is used by the DOTS client to validate the DOTS server identity, the = DOTS client SHOULD include DOTS server FQDN in the server name = indication extension (Section 3 of = RFC6066).”

Cheers,

-Tiru

 

From: Jon Shallow [mailto:supjps-ietf@jpshallow.co= m]
Sent: Wednesday, January 3, 2018 4:17 PM
To: = Konda, Tirumaleswar Reddy <TirumaleswarReddy_Kond= a@McAfee.com>; dots@ietf.org
Subject: RE: = [Dots] Using SNI

 

Hi = Tiru,

 

My main goal here is to = make sure that we can have DOTS vendor interoperability.  As found = during my implementation, having certain things in place helps = considerably – providing strong hints to the implementer as to = what should be available for interoperability = helps.

 

Instead of =

 
“=
If TLS =
client certificate is used to authenticate the DOTS client, the DOTS =
client MUST include the DOTS server FQDN in server name indication =
extension (Section 3 of =
RFC6066).”
 =

We could =
perhaps have
 =

“The =
DOTS client MUST support enabling the use of SNI (Section 3 of =
RFC6066).  When enabled, this SHOULD include the DOTS server FQDN =
in the server name indication =
extension.”
 =

As an =
aside, I have been able to get my DOTS server to support both PKI and =
PSK, thus supporting a mix of PKI and PSK DOTS clients being active at =
the same time (I agree this is not a generally recommended case).  =
This was not done using SNI, but would have been considerably easier to =
implement if using SNI and the PSK clients talked to =
psk-dotsserver.somewhere.com and PKI clients talked to =
pki-dotsserver.somewhere.com – both DNS resolving to the same =
IP.
 =

So being =
able to use SNI in both the signal and data channels makes sense to =
me.

 

Regards

 

Jon

 

From: Dots [mailto: dots-bounces@ietf.org] On = Behalf Of Konda, Tirumaleswar Reddy
Sent: 03 January 2018 = 07:21
To: Jon Shallow; dots@ietf.org
Subject: Re: = [Dots] Using SNI

 

Hi = Jon,

 

We may want to use = “SHOULD” instead of “MUST” in the below line = (for example, SNI is not required if the DOTS client and server are in = the same enterprise network).

 

-TIru

 

From: Jon Shallow [mailto:supjps-ietf@jpshallow.co= m]
Sent: Tuesday, January 2, 2018 3:30 PM
To: = Konda, Tirumaleswar Reddy <TirumaleswarReddy_Kond= a@McAfee.com>; dots@ietf.org
Subject: RE: = [Dots] Using SNI

 

Hi = Tiru,

 

That certainly works for = me – thanks

 

Regards

 

Jon

 

From: Dots [mailto: dots-bounces@ietf.org] On = Behalf Of Konda, Tirumaleswar Reddy
Sent: 02 January 2018 = 09:55
To: Jon Shallow; dots@ietf.org
Subject: Re: = [Dots] Using SNI

 

Hi =
Jon,
 =

RESTCONF =
does not mandate client authentication based on TLS client certificate, =
we can say the following instead:
If TLS =
client certificate is used to authenticate the DOTS client, the DOTS =
client MUST include the DOTS server FQDN in server name indication =
extension (Section 3 of RFC6066).
 =

Cheers,
-Tiru<=
/o:p>
 =

From: Jon Shallow [mailto:supjps-ietf@jpshallow.co= m]
Sent: Tuesday, January 2, 2018 3:10 PM
To: = Konda, Tirumaleswar Reddy <TirumaleswarReddy_Kond= a@McAfee.com>; dots@ietf.org
Subject: RE: = [Dots] Using SNI

 

Hi = Tiru,

 

I agree that (indirectly = through RFC7525 reference) SNI is mandated to be supported (but not = necessarily has to be used).

 

However, to guarantee = interoperability between different DOTS vendors, I am saying that the = use of SNI is a MUST – in particular for the data = channel.

 

Regards

 

Jon

 

From: Dots [mailto: dots-bounces@ietf.org] On = Behalf Of Konda, Tirumaleswar Reddy
Sent: 02 January 2018 = 08:48
To: Jon Shallow; dots@ietf.org
Subject: Re: = [Dots] Using SNI

 

Hi = Jon,

 

Both signal and data channel drafts = refer to RFC7525 for secure use of (D)TLS and RFC7525 mandates TLS = implementations to support SNI. I don’t see the need to explicitly = discuss SNI in these drafts.


Regards,

-Tiru

 

From: Dots [mailto:dots-bounces@ietf.org] = On Behalf Of Jon Shallow
Sent: Saturday, December 30, = 2017 4:57 PM
To: dots@ietf.org
Subject: = [Dots] Using SNI

 

Hi WG,

 

When = providing a DOTS server data channel service in my environment, this = shares the same ip / port which also provides other services (e.g. GUI / = REST server etc.).  Even if the Root Discovery points to another IP = and or port for the actual data channel activity, the TLS exchanges for = the Root Discovery have to correctly work.  I suspect that I am not = the only DOTS vendor who will have this type of requirement of a single = IP providing multiple TLS services.

 

As DOTS = requires mutual authentication, this is a different security requirement = than required by the GUI environment (DOTS requires client cert to be = presented, GUI does not and providing certificates to every GUI client = is not a practical option).

 

This can be = handled by using SNI by using 2 different FQDNs and requiring the DOTS = client to include the DOTS specific FQDN in the TLS Client Hello.  = Whether the GUI client does or does not (likely does with modern = browsers) include a SNI FQDN when connecting to the non DOTS FQDN does = not really matter – for DOTS it is recognizing the DOTS specific = FQDN and setting up the TLS as appropriate.

 

To make sure = interoperability between DOTS vendors, I would like to see something = like added to the data channel spec “DOTS clients MUST include the = DOTS server FQDN in the TLS Client Hello packet by using Server Name = Indication (SNI) RFC 3546”.

 

In addition, = I think that this would be a good idea as well for the signal draft = – thereby giving DOTS vendors the opportunity to host multiple = DOTS servers (likely to be different security requirements for their = different client) on a single IP / port.

 

Thoughts / = comments?

 

Regards

 

Jon

<= /body> ------=_NextPart_000_0DA2_01D3854A.7EAA9920-- From nobody Thu Jan 4 02:57:52 2018 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 43B9F1200C5 for ; Thu, 4 Jan 2018 02:57:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.33 X-Spam-Level: X-Spam-Status: No, score=-4.33 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, T_RP_MATCHES_RCVD=-0.01] 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 LyrzhInBUd1N for ; Thu, 4 Jan 2018 02:57:45 -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 8DF4C120727 for ; Thu, 4 Jan 2018 02:57:45 -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=1515063464; 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: x-microsoft-antispam-message-info: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=v z385WuKdYa1f8hSos6dauflnUYuJ2INY8ZluFxAP1 M=; b=LiZDfdzUvZbLjYsliIH2MsFgkWpx2ZEgL4ITe5lCM3JT Kv3axY1KYAp+wPsipN+EvnVL4xrmGGblwacrXaOT2ew5l2n9cq G34s6hB9a2ksBBzgVbfP0aAMTyay1S1HtgqnGXiNzJX+e9N6J/ Lu/4WcbSZSeiSj+P2v53pmI1764= Received: from DNVEXAPP1N06.corpzone.internalzone.com (unknown [10.44.48.90]) by DNVWSMAILOUT1.mcafee.com with smtp (TLS: TLSv1/SSLv3,256bits,ECDHE-RSA-AES256-SHA384) id 3f34_aad7_9857194b_b083_441a_95b5_65588230e1ea; Thu, 04 Jan 2018 04:57:44 -0600 Received: from DNVEXAPP1N06.corpzone.internalzone.com (10.44.48.90) by DNVEXAPP1N06.corpzone.internalzone.com (10.44.48.90) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Thu, 4 Jan 2018 03:57:43 -0700 Received: from DNVEX10N01.corpzone.internalzone.com (10.44.82.192) by DNVEXAPP1N06.corpzone.internalzone.com (10.44.48.90) with Microsoft SMTP Server (TLS) id 15.0.1347.2 via Frontend Transport; Thu, 4 Jan 2018 03:57:43 -0700 Received: from DNVO365EDGE1.corpzone.internalzone.com (10.44.176.66) by DNVEX10N01.corpzone.internalzone.com (10.44.82.192) with Microsoft SMTP Server (TLS) id 14.3.210.2; Thu, 4 Jan 2018 03:57:42 -0700 Received: from NAM03-DM3-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, 4 Jan 2018 03:57:42 -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.366.8; Thu, 4 Jan 2018 10:57: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.0366.009; Thu, 4 Jan 2018 10:57:41 +0000 From: "Konda, Tirumaleswar Reddy" To: Jon Shallow , "dots@ietf.org" Thread-Topic: [Dots] Using SNI Thread-Index: AdOBYSmGAk9KbyE4TFyYKC/j9TeHqgCRKPHwAAH2wAAAAHaCkAAAPMGAACycgwAAB1SwgAABIhDAACvYNwAABJpNMAAA/IIAAAAP+XA= Date: Thu, 4 Jan 2018 10:57:41 +0000 Message-ID: References: <0a1201d38161$299ef350$7cdcd9f0$@jpshallow.com> <0b2301d383ad$a8822a40$f9867ec0$@jpshallow.com> <0b4b01d383b0$758f1370$60ad3a50$@jpshallow.com> <0c8c01d38480$3a6ba5d0$af42f170$@jpshallow.com> <0d4901d38534$23d56ea0$6b804be0$@jpshallow.com> <0da101d3854a$7ea84f30$7bf8ed90$@jpshallow.com> In-Reply-To: <0da101d3854a$7ea84f30$7bf8ed90$@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; 7:RBAj25yN0BlKSt5qHWPBZY0FCs7/xdwQ/FGsokUH4apD5pFKWH82UKl9HSGtsvhq3vqb6ejqsrojKauRouLQTZgzbi+4d3KC3UYNbGnKemfqsO+zapFqHXb0qj55NgAw4ZL+o2VOYVYtMXAUQ73NBr/lXGxZur5QP0JPC243+DUmM2OAA3eW02DSlhPP/aZCb3hPxEPgnPW836CbZTs6xW3hbvxDmUfoB7oeM8h74JkI3IKYFdnDMFiaTmPn7voC x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: a2ea0ddf-77cc-4717-25f9-08d55361fa16 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(5600026)(4604075)(3008032)(2017052603307)(7153060); SRVR:DM5PR16MB1788; x-ms-traffictypediagnostic: DM5PR16MB1788: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(192374486261705)(21748063052155)(123452027830198); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040470)(2401047)(8121501046)(5005006)(10201501046)(93006095)(93001095)(3231023)(944501075)(3002001)(6041268)(20161123558120)(20161123564045)(20161123560045)(20161123562045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(6072148)(201708071742011); SRVR:DM5PR16MB1788; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:DM5PR16MB1788; x-forefront-prvs: 054231DC40 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39380400002)(346002)(376002)(366004)(396003)(39860400002)(32952001)(51444003)(189003)(15404003)(199004)(3660700001)(19609705001)(53936002)(99286004)(2906002)(81156014)(6506007)(80792005)(14454004)(102836004)(53546011)(59450400001)(81166006)(229853002)(76176011)(8676002)(7696005)(97736004)(68736007)(25786009)(33656002)(6246003)(6436002)(55016002)(72206003)(74316002)(8936002)(790700001)(5660300001)(6116002)(2950100002)(3846002)(6306002)(77096006)(478600001)(54896002)(236005)(2501003)(2900100001)(106356001)(316002)(105586002)(3280700002)(93886005)(7736002)(66066001)(9686003)(110136005)(86362001)(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; x-microsoft-antispam-message-info: snNzROFgHtQil3OTh7XgPkY9yAj8tincecaFFbsv3D5EWrgWPZDG9W/OJpbLTwv2bZEM+xQsy+i3GU67Jxlk4g== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_DM5PR16MB17884CE194FADFF75521066EEA1F0DM5PR16MB1788namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: a2ea0ddf-77cc-4717-25f9-08d55361fa16 X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Jan 2018 10:57:41.3606 (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 <6192> : inlines <6293> : streams <1775071> : uri <2562911> Archived-At: Subject: Re: [Dots] Using SNI 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, 04 Jan 2018 10:57:50 -0000 --_000_DM5PR16MB17884CE194FADFF75521066EEA1F0DM5PR16MB1788namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thanks, works for me. -Tiru From: Jon Shallow [mailto:supjps-ietf@jpshallow.com] Sent: Thursday, January 4, 2018 4:25 PM To: Konda, Tirumaleswar Reddy ; dots@ie= tf.org Subject: RE: [Dots] Using SNI Hi Tiru, That is much better. However for additional clarity, it may be better to s= ay The SNI extension [RFC6066] defines a mechanism for a client to tell a (D)T= LS server the name of the server it wants to contact. This is a useful ext= ension for hosting environments where multiple virtual servers are run on a= single IP address. The DOTS client may or may not know if it is interactin= g with a DOTS server in a virtual server hosting environment, so the DOTS c= lient SHOULD include the DOTS server FQDN in the SNI extension. Regards Jon From: Dots [mailto: dots-bounces@ietf.org] On= Behalf Of Konda, Tirumaleswar Reddy Sent: 04 January 2018 10:48 To: Jon Shallow; dots@ietf.org Subject: Re: [Dots] Using SNI Hi Jon, Thanks, I now understand your concerns :) Proposed text: The SNI extension [RFC6066] defines a mechanism for a client to tell a (D)T= LS server the name of the server it wants to contact. This is a useful ext= ension for hosting environments where multiple virtual servers are run on a= single IP address. The DOTS client may or may not know if it is interactin= g with a DOTS server in the hosting environment, so the DOTS client SHOULD = include the DOTS server FQDN in the SNI extension. Cheers, -Tiru From: Jon Shallow [mailto:supjps-ietf@jpshallow.com] Sent: Thursday, January 4, 2018 1:45 PM To: Konda, Tirumaleswar Reddy >; dots@ietf.org Subject: RE: [Dots] Using SNI Hi Tiru, I do not think that this is about validation, and unlikely to be used by th= e DOTS client to validate the DOTS server identity (yes, the DOTS server co= uld present different certificates based on the SNI, but not sure how that = helps the DOS client to validate). To me, it is all about the ability of the DOTS server to be able to decide = which security policy to install for the incoming connection - is this a DO= TS connection or is this a request to access a GUI or is this for a RESTful= interface etc. etc. ? - all on the same IP and port - the decision is keye= d off the SNI information. Part of the challenge I have here is that the data channel root discovery a= gainst port 443 ideally has to have the same security requirements as when = the data channel is used for aliases and filter updating. So even if root = discovery redirects the DOTS connection to a different port, the correct se= curity policy still needs to applied to DOTS client root discovery and a di= fferent policy applied for the GUI connection. If a peer certificate is to= be requested for mutual authentication checks in a DOTS connection, reques= ting a peer certificate from a browser fails (unless a specific peer cert i= s installed in the browser - impractical scaling request) and so GUI access= will fail. One policy (DOTS) needs to request the peer cert, the other (G= UI) must not request a peer cert. SNI is the only way I have found to hand= le this. I also do not think it is limited to PKI for DOTS - as mentioned below, acc= essing psk-dotsserver.somewhere.com or pki-dotsserver.somewhere.com along w= ith the appropriate SNI information, the DOTS server can easily decide to i= nstall a PSK or PKI security policy. The DOTS client needs to be able to provide the SNI information - it is up = to the DOTS server as to how it is used (which could be to ignore it) - to = provide DOTS vender interoperability. So, no, I am not comfortable with your suggestion. Regards Jon From: Dots [mailto: dots-bounces@ietf.org] On= Behalf Of Konda, Tirumaleswar Reddy Sent: 04 January 2018 07:19 To: Jon Shallow; dots@ietf.org Subject: Re: [Dots] Using SNI Hi Jon, How about the following line instead ? "If PKI-based authentication is used by the DOTS client to validate the DOT= S server identity, the DOTS client SHOULD include DOTS server FQDN in the s= erver name indication extension (Section 3 of RFC6066)." Cheers, -Tiru From: Jon Shallow [mailto:supjps-ietf@jpshallow.com] Sent: Wednesday, January 3, 2018 4:17 PM To: Konda, Tirumaleswar Reddy >; dots@ietf.org Subject: RE: [Dots] Using SNI Hi Tiru, My main goal here is to make sure that we can have DOTS vendor interoperabi= lity. As found during my implementation, having certain things in place he= lps considerably - providing strong hints to the implementer as to what sho= uld be available for interoperability helps. Instead of "If TLS client certificate is used to authenticate the DOTS client, the DOT= S client MUST include the DOTS server FQDN in server name indication extens= ion (Section 3 of RFC6066)." We could perhaps have "The DOTS client MUST support enabling the use of SNI (Section 3 of RFC6066= ). When enabled, this SHOULD include the DOTS server FQDN in the server na= me indication extension." As an aside, I have been able to get my DOTS server to support both PKI and= PSK, thus supporting a mix of PKI and PSK DOTS clients being active at the= same time (I agree this is not a generally recommended case). This was no= t done using SNI, but would have been considerably easier to implement if u= sing SNI and the PSK clients talked to psk-dotsserver.somewhere.com and PKI= clients talked to pki-dotsserver.somewhere.com - both DNS resolving to the= same IP. So being able to use SNI in both the signal and data channels makes sense t= o me. Regards Jon From: Dots [mailto: dots-bounces@ietf.org] On= Behalf Of Konda, Tirumaleswar Reddy Sent: 03 January 2018 07:21 To: Jon Shallow; dots@ietf.org Subject: Re: [Dots] Using SNI Hi Jon, We may want to use "SHOULD" instead of "MUST" in the below line (for exampl= e, SNI is not required if the DOTS client and server are in the same enterp= rise network). -TIru From: Jon Shallow [mailto:supjps-ietf@jpshallow.com] Sent: Tuesday, January 2, 2018 3:30 PM To: Konda, Tirumaleswar Reddy >; dots@ietf.org Subject: RE: [Dots] Using SNI Hi Tiru, That certainly works for me - thanks Regards Jon From: Dots [mailto: dots-bounces@ietf.org] On= Behalf Of Konda, Tirumaleswar Reddy Sent: 02 January 2018 09:55 To: Jon Shallow; dots@ietf.org Subject: Re: [Dots] Using SNI Hi Jon, RESTCONF does not mandate client authentication based on TLS client certifi= cate, we can say the following instead: If TLS client certificate is used to authenticate the DOTS client, the DOTS= client MUST include the DOTS server FQDN in server name indication extensi= on (Section 3 of RFC6066). Cheers, -Tiru From: Jon Shallow [mailto:supjps-ietf@jpshallow.com] Sent: Tuesday, January 2, 2018 3:10 PM To: Konda, Tirumaleswar Reddy >; dots@ietf.org Subject: RE: [Dots] Using SNI Hi Tiru, I agree that (indirectly through RFC7525 reference) SNI is mandated to be s= upported (but not necessarily has to be used). However, to guarantee interoperability between different DOTS vendors, I am= saying that the use of SNI is a MUST - in particular for the data channel. Regards Jon From: Dots [mailto: dots-bounces@ietf.org] On= Behalf Of Konda, Tirumaleswar Reddy Sent: 02 January 2018 08:48 To: Jon Shallow; dots@ietf.org Subject: Re: [Dots] Using SNI Hi Jon, Both signal and data channel drafts refer to RFC7525 for secure use of (D)T= LS and RFC7525 mandates TLS implementations to support SNI. I don't see the= need to explicitly discuss SNI in these drafts. Regards, -Tiru From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Jon Shallow Sent: Saturday, December 30, 2017 4:57 PM To: dots@ietf.org Subject: [Dots] Using SNI Hi WG, When providing a DOTS server data channel service in my environment, this s= hares the same ip / port which also provides other services (e.g. GUI / RES= T server etc.). Even if the Root Discovery points to another IP and or por= t for the actual data channel activity, the TLS exchanges for the Root Disc= overy have to correctly work. I suspect that I am not the only DOTS vendor= who will have this type of requirement of a single IP providing multiple T= LS services. As DOTS requires mutual authentication, this is a different security requir= ement than required by the GUI environment (DOTS requires client cert to be= presented, GUI does not and providing certificates to every GUI client is = not a practical option). This can be handled by using SNI by using 2 different FQDNs and requiring t= he DOTS client to include the DOTS specific FQDN in the TLS Client Hello. = Whether the GUI client does or does not (likely does with modern browsers) = include a SNI FQDN when connecting to the non DOTS FQDN does not really mat= ter - for DOTS it is recognizing the DOTS specific FQDN and setting up the = TLS as appropriate. To make sure interoperability between DOTS vendors, I would like to see som= ething like added to the data channel spec "DOTS clients MUST include the D= OTS server FQDN in the TLS Client Hello packet by using Server Name Indicat= ion (SNI) RFC 3546". In addition, I think that this would be a good idea as well for the signal = draft - thereby giving DOTS vendors the opportunity to host multiple DOTS s= ervers (likely to be different security requirements for their different cl= ient) on a single IP / port. Thoughts / comments? Regards Jon --_000_DM5PR16MB17884CE194FADFF75521066EEA1F0DM5PR16MB1788namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Thanks, w= orks for me.

&nbs= p;

-Tiru

 

From:<= /span> Jon Shallow [mailto:s= upjps-ietf@jpshallow.com]
Sent: Thursday, January 4, 2018 4:25 PM
To: Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@McAfee.com= >; dots@ietf.org
Subject: RE: [Dots] Using SNI

 

Hi Tiru= ,

&n= bsp;

That is= much better.  However for additional clarity, it may be better to say=

&n= bsp;

The SNI e= xtension [RFC6066] defines a mechanism for a client to tell a (D)TLS server= the name of the server it wants to contact.  This is a useful extensi= on for hosting environments where multiple virtual servers are run on a single IP address. The DOTS client may or may= not know if it is interacting with a DOTS server in a virtual server hosting environment, so the DOTS client SHOU= LD include the DOTS server FQDN in the SNI extension.

&n= bsp;

Regards=

&n= bsp;

Jon

&n= bsp;

From: Dots [mailto: dots-bounces@ietf.org] On B= ehalf Of Konda, Tirumaleswar Reddy
Sent: 04 January 2018 10:48
To: Jon Shallow; dots@ietf.org<= br> Subject: Re: [Dots] Using SNI

 

Hi Jon,

&nbs= p;

Thanks, I= now understand your concerns J  

&nbs= p;

Proposed = text:

The SNI e= xtension [RFC6066] defines a mechanism for a client to tell a (D)TLS server= the name of the server it wants to contact.  This is a useful extensi= on for hosting environments where multiple virtual servers are run on a single IP address. The DOTS client may or may= not know if it is interacting with a DOTS server in the hosting environmen= t, so the DOTS client SHOULD include the DOTS server FQDN in the SNI extens= ion.

&nbs= p;

Cheers,

-Tiru

&nbs= p;

From:<= /span> Jon Shallow [mailto:supjps-ietf@jpshallow.com]
Sent: Thursday, January 4, 2018 1:45 PM
To: Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@McAfee.com>; dots@ietf.org
Subject: RE: [Dots] Using SNI

 

Hi Tiru= ,

&n= bsp;

I do no= t think that this is about validation, and unlikely to be used by the DOTS = client to validate the DOTS server identity (yes, the DOTS server could pre= sent different certificates based on the SNI, but not sure how that helps the DOS client to validate).

&n= bsp;

To me, = it is all about the ability of the DOTS server to be able to decide which s= ecurity policy to install for the incoming connection – is this a DOT= S connection or is this a request to access a GUI or is this for a RESTful interface etc. etc. ? – all on the sa= me IP and port – the decision is keyed off the SNI information.<= /o:p>

&n= bsp;

Part of= the challenge I have here is that the data channel root discovery against = port 443 ideally has to have the same security requirements as when the dat= a channel is used for aliases and filter updating.  So even if root discovery redirects the DOTS connection to= a different port, the correct security policy still needs to applied to DO= TS client root discovery and a different policy applied for the GUI connect= ion.  If a peer certificate is to be requested for mutual authentication checks in a DOTS connection, requestin= g a peer certificate from a browser fails (unless a specific peer cert is i= nstalled in the browser – impractical scaling request) and so GUI acc= ess will fail.  One policy (DOTS) needs to request the peer cert, the other (GUI) must not request a peer cert.&nb= sp; SNI is the only way I have found to handle this.

&n= bsp;

I also = do not think it is limited to PKI for DOTS – as mentioned below, acce= ssing psk-dotsserver.somewhere.com or pki-dotsserver.somewhere.com along w= ith the appropriate SNI information, the DOTS server can easily decide to i= nstall a PSK or PKI security policy.

 

The DOTS client needs to be able to provide the SNI = information – it is up to the DOTS server as to how it is used (which= could be to ignore it) – to provide DOTS vender interoperability.

 

So, no, I am not comfortable with your suggestion.

 

Regards

 

Jon

&n= bsp;

From: Dots [mailto: dots-bounces@ietf.org] On B= ehalf Of Konda, Tirumaleswar Reddy
Sent: 04 January 2018 07:19
To: Jon Shallow; dots@ietf.org<= br> Subject: Re: [Dots] Using SNI

 

Hi Jon,

&nbs= p;

How about= the following line instead ?

“If PKI-based authentication is used by the DOT= S client to validate the DOTS server identity, the DOTS client SHOULD inclu= de DOTS server FQDN in the server name indication extension (Section 3 of RFC6066).”

Cheers,

-Tiru

&nbs= p;

From:<= /span> Jon Shallow [mailto:supjps-ietf@jpshallow.com]
Sent: Wednesday, January 3, 2018 4:17 PM
To: Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@McAfee.com>; dots@ietf.org
Subject: RE: [Dots] Using SNI

 

Hi Tiru= ,

&n= bsp;

My main= goal here is to make sure that we can have DOTS vendor interoperability.&n= bsp; As found during my implementation, having certain things in place help= s considerably – providing strong hints to the implementer as to what should be available for interoperability helps.=

&n= bsp;

Instead of 
 
“If TLS client certificate is used to authe=
nticate the DOTS client, the DOTS client MUST include the DOTS server FQDN =
in server name indication extension (Section 3 of RFC6066).”
 
We could perhaps have
 
“The DOTS client MUST support enabling the use of SNI (Section =
3 of RFC6066).  When enabled, this SHOULD include the DOTS server FQDN=
 in the server name indication extension.”
 
As an aside, I have been able to get my DOTS server to support both P=
KI and PSK, thus supporting a mix of PKI and PSK DOTS clients being active =
at the same time (I agree this is not a generally recommended case).  =
This was not done using SNI, but would have been considerably easier to imp=
lement if using SNI and the PSK clients talked to psk-dotsserver.somewhere.=
com and PKI clients talked to pki-dotsserver.somewhere.com – both DNS=
 resolving to the same IP.
 
So being able to use SNI in both the signal and data channels makes s=
ense to me.

&n= bsp;

Regards=

&n= bsp;

Jon

&n= bsp;

From: Dots [mailto: dots-bounces@ietf.org] On B= ehalf Of Konda, Tirumaleswar Reddy
Sent: 03 January 2018 07:21
To: Jon Shallow; dots@ietf.org<= br> Subject: Re: [Dots] Using SNI

 

Hi Jon,

&nbs= p;

We may wa= nt to use “SHOULD” instead of “MUST” in the below l= ine (for example, SNI is not required if the DOTS client and server are in = the same enterprise network).

&nbs= p;

-TIru

&nbs= p;

From:<= /span> Jon Shallow [mailto:supjps-ietf@jpshallow.com]
Sent: Tuesday, January 2, 2018 3:30 PM
To: Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@McAfee.com>; dots@ietf.org
Subject: RE: [Dots] Using SNI

 

Hi Tiru= ,

&n= bsp;

That ce= rtainly works for 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: 02 January 2018 09:55
To: Jon Shallow; dots@ietf.org<= br> Subject: Re: [Dots] Using SNI

 

Hi Jon,
 
RESTCONF does not mandate client authentication based on TLS client c=
ertificate, we can say the following instead:
If TLS client certificate is used to authenticate the DOTS client, th=
e DOTS client MUST include the DOTS server FQDN in server name indication e=
xtension (Section 3 of RFC6066).
 
Cheers,
-Tiru
 

From:<= /span> Jon Shallow [mailto:supjps-ietf@jpshallow.com]
Sent: Tuesday, January 2, 2018 3:10 PM
To: Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@McAfee.com>; dots@ietf.org
Subject: RE: [Dots] Using SNI

 

Hi Tiru= ,

&n= bsp;

I agree= that (indirectly through RFC7525 reference) SNI is mandated to be supporte= d (but not necessarily has to be used).

&n= bsp;

However= , to guarantee interoperability between different DOTS vendors, I am saying= that the use of SNI is a MUST – in particular for the data channel.<= o:p>

&n= bsp;

Regards=

&n= bsp;

Jon

&n= bsp;

From: Dots [mailto: dots-bounces@ietf.org] On B= ehalf Of Konda, Tirumaleswar Reddy
Sent: 02 January 2018 08:48
To: Jon Shallow; dots@ietf.org<= br> Subject: Re: [Dots] Using SNI

 

Hi Jon,

&nbs= p;

Both sign= al and data channel drafts refer to RFC7525 for secure use of (D)TLS and RF= C7525 mandates TLS implementations to support SNI. I don’t see the ne= ed to explicitly discuss SNI in these drafts.


Regards,

-Tiru

&nbs= p;

From:<= /span> Dots [mailto:dots-bounces@ietf.org] On Behalf Of Jon Shallow
Sent: Saturday, December 30, 2017 4:57 PM
To: dots@ietf.org
Subject: [Dots] Using SNI

 

Hi WG,

 

When providing a DOTS server da= ta channel service in my environment, this shares the same ip / port which = also provides other services (e.g. GUI / REST server etc.).  Even if t= he Root Discovery points to another IP and or port for the actual data channel activity, the TLS exchanges for the Ro= ot Discovery have to correctly work.  I suspect that I am not the only= DOTS vendor who will have this type of requirement of a single IP providin= g multiple TLS services.

 

As DOTS requires mutual authent= ication, this is a different security requirement than required by the GUI = environment (DOTS requires client cert to be presented, GUI does not and pr= oviding certificates to every GUI client is not a practical option).

 

This can be handled by using SN= I by using 2 different FQDNs and requiring the DOTS client to include the D= OTS specific FQDN in the TLS Client Hello.  Whether the GUI client doe= s or does not (likely does with modern browsers) include a SNI FQDN when connecting to the non DOTS FQDN does not really ma= tter – for DOTS it is recognizing the DOTS specific FQDN and setting = up the TLS as appropriate.

 

To make sure interoperability b= etween DOTS vendors, I would like to see something like added to the data c= hannel spec “DOTS clients MUST include the DOTS server FQDN in the TL= S Client Hello packet by using Server Name Indication (SNI) RFC 3546”.

 

In addition, I think that this = would be a good idea as well for the signal draft – thereby giving DO= TS vendors the opportunity to host multiple DOTS servers (likely to be diff= erent security requirements for their different client) on a single IP / port.

 

Thoughts / comments?=

 

Regards

 

Jon

--_000_DM5PR16MB17884CE194FADFF75521066EEA1F0DM5PR16MB1788namp_-- From nobody Thu Jan 4 03:12:13 2018 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 6A13B126D46 for ; Thu, 4 Jan 2018 03:12:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.33 X-Spam-Level: X-Spam-Status: No, score=-4.33 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, T_RP_MATCHES_RCVD=-0.01] 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 BNxXi2YFIz1k for ; Thu, 4 Jan 2018 03:12:10 -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 680C0126CB6 for ; Thu, 4 Jan 2018 03:12: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=1515064329; 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:x-microsoft-antispam-message-info: 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=j vXbXjkb/Fj1omFV/YD8LiNIS16qe4RiaHXOKmuX+0 I=; b=hUPiyvW24yq7aLHP8TlrdcsTaCmuZa+LCR4NmLFVyb0O Xjgvg7Yqx5Bu0d/Haf5iWka799e054YK/SAf4mZu00HFjIBHPW PQBTwVMdOTcaAAJ8FNHrvHE/dj5UXE6Ihg69ToK0w35cXQEdz/ x6QPxNXLrq3eiwu5c8RGEz5QbIg= Received: from DNVEXAPP1N06.corpzone.internalzone.com (unknown [10.44.48.90]) by DNVWSMAILOUT1.mcafee.com with smtp (TLS: TLSv1/SSLv3,256bits,ECDHE-RSA-AES256-SHA384) id 3f34_c1bc_1d4f948f_875f_4dae_887e_e1193e3aecc3; Thu, 04 Jan 2018 05:12:09 -0600 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; Thu, 4 Jan 2018 04:12:08 -0700 Received: from DNVEXUSR1N11.corpzone.internalzone.com (10.44.48.84) by DNVEXUSR1N14.corpzone.internalzone.com (10.44.48.87) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Thu, 4 Jan 2018 04:12:07 -0700 Received: from DNVO365EDGE1.corpzone.internalzone.com (10.44.176.66) by DNVEXUSR1N11.corpzone.internalzone.com (10.44.48.84) with Microsoft SMTP Server (TLS) id 15.0.1347.2 via Frontend Transport; Thu, 4 Jan 2018 04:12:07 -0700 Received: from NAM02-BL2-obe.outbound.protection.outlook.com (10.44.176.242) by edge.mcafee.com (10.44.176.66) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Thu, 4 Jan 2018 04:12:06 -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.366.8; Thu, 4 Jan 2018 11:12: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.0366.009; Thu, 4 Jan 2018 11:12:06 +0000 From: "Konda, Tirumaleswar Reddy" To: Jon Shallow , "dots@ietf.org" Thread-Topic: [Dots] Clarity in use of ampersand in data channel Thread-Index: AdOElLupXJwi3futTSeJ+aMxa41ElgAt/YpA Date: Thu, 4 Jan 2018 11:12:05 +0000 Message-ID: References: <0ccd01d38494$bde6eb90$39b4c2b0$@jpshallow.com> In-Reply-To: <0ccd01d38494$bde6eb90$39b4c2b0$@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:So9PLZBQegQkBUY/qqi21SoDedKd1lytqplPGCq++r3IoZoKRdOzIUd0oBCJfJSs0p86ewaJVKQfJKR05x43nWq6oA/2fxSwo7Numu/ckYXA3OYtmKZ5+4/Om+I4Nxes/UEaUKhVTXS0HxdRSlHL0iMl0ubQAwMZWnciKOK7NRlT2cOJOGnDNQZIL+OO3htwgXclvFYSMXHGXnlPGZGmyItl+9h/z7i1Abvxmdle68PHT5tlvPIiUHjMKQ5JElwiFEZRTwzTCw/IKfobzZvsS9vsWJN5/pYcPqIWXNylgwkKMBmACHuT6k6f/ycAUpEVgI0mAWVHXt192ywoSgQjCuJc+5uZSNvu3sc1SR3zapkAe/sO7ZeedBICWbvmaMJi; 5:GNtS7oHOxQi9kZwXZAzYWN3T+ByLLbhuCq73rJm5T37ie2bHxQo3vSycCl57l8sGmkbOFqSPW/wnePwUbz9ZUDDZq3LEQTCYz2kHZUXxDdBb1pXEp5I2OMjcTFnOxXTAZqDV1wMvzqWDwc5lawqj700R9YblxeVyR3qRUQgqpxc=; 24:WfKO2lwZ0x9Qs8JqUPxdvH+pJWYjb+1OYWotamv+ACe7c1i0ggf1LVXNh2CG2O1HmtrBZ+R3trSVUYhXyRgvgVYF7+lFEu5yruR7sFodUYk=; 7:K6fB2xqeA7eU45biqnrLHGhbRC2sMAdqnWptHbta8MqpXWmgeqAOt7eJaoBr/3EubBRo/QFCVtunAGu2v84Y8rcDSQJj0/DiOHhPUtfLJteX1zmhYQMeKqmCfpeyUkhIdOhhlybgMcRV5O0xH48+gl7QM/y1YN9arBABadfkcSXT/HntZ/2OHkE6/ZAfUNBG1Jrw6u5siKR3532tp1+4gR5pWxE0H7aG1fP5LT82n7wUd9UIXaEBte8gNbRaqXkL x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 0042c6d0-f59f-47ed-74e3-08d55363fd5a x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(5600026)(4604075)(3008032)(2017052603307)(7153060); SRVR:DM5PR16MB1785; x-ms-traffictypediagnostic: DM5PR16MB1785: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040470)(2401047)(5005006)(8121501046)(3002001)(3231023)(944501075)(93006095)(93001095)(10201501046)(6041268)(20161123558120)(20161123560045)(20161123564045)(20161123562045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(6072148)(201708071742011); SRVR:DM5PR16MB1785; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:DM5PR16MB1785; x-forefront-prvs: 054231DC40 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(366004)(346002)(39380400002)(396003)(39860400002)(376002)(32952001)(53754006)(199004)(189003)(110136005)(7736002)(59450400001)(14454004)(478600001)(81166006)(2900100001)(81156014)(2950100002)(316002)(76176011)(8936002)(25786009)(99286004)(102836004)(68736007)(7696005)(2501003)(72206003)(53546011)(6506007)(77096006)(66066001)(3280700002)(5660300001)(6116002)(3846002)(790700001)(229853002)(6246003)(53936002)(74316002)(575784001)(54896002)(86362001)(8676002)(6436002)(106356001)(19609705001)(9686003)(2906002)(33656002)(80792005)(97736004)(6306002)(3660700001)(55016002)(105586002)(87944003)(85282002)(19627235001); 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) x-microsoft-antispam-message-info: HtIjkpXv9XQzVyw2C1maCfCChdIjr0lZ529/xlNXFtx09pdR+8A+I5PRup0j5ZcaFwngh6QSYHcgxgylzsPeOw== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_DM5PR16MB1788D907DAD514C3C0978ED8EA1F0DM5PR16MB1788namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 0042c6d0-f59f-47ed-74e3-08d55363fd5a X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Jan 2018 11:12:05.8193 (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 <6192> : inlines <6293> : streams <1775072> : uri <2562917> Archived-At: Subject: Re: [Dots] Clarity in use of ampersand in data channel 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, 04 Jan 2018 11:12:12 -0000 --_000_DM5PR16MB1788D907DAD514C3C0978ED8EA1F0DM5PR16MB1788namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Jon Shallow Sent: Wednesday, January 3, 2018 6:44 PM To: dots@ietf.org Subject: [Dots] Clarity in use of ampersand in data channel Hi All, Should we be using & as a separator in the namespace-uri of a RESTCONF requ= est? For example, in 7.3. Remove Filtering Rules, we have DELETE /restconf/data/ietf-dots-data-channel:access-lists\ /client-identifier=3Ddz6pHjaADkaFTbjr0JGBpw\ /acl-name=3Dsample-ipv4-acl&\ acl-type=3Dipv4-acl HTTP/1.1 Host: {host}:{port} Where there is .../acl-name=3Dsample-ipv4-acl&acl-type=3Dipv4-acl . I unde= rstand the intent of this as acl-name=3D and acl-type=3D are an associated = pair, but in the uri path should this really be .../acl-name=3Dsample-ipv4-= acl/acl-type=3Dipv4-acl ? We have separated out .. /client-identifier=3Ddz6pHjaADkaFTbjr0JGBpw/.. as = a separate path component, so it makes sense to me to also use / instead of= & for splitting out acl-name=3D and acl-type=3D. NOTE: we need to be care= ful about defining parameter ordering here in the uri. Although DOTS does not use such YANG parameter name format, it would appear= that, for example, "bill&joe" is a valid entity in its own rights, so usin= g & as a parameter separator could be problematic.. RFC8040 only has / separators prior to a ? in its examples. [TR] Yes, will update draft to use / separator. -Tiru Comments welcome. Regards Jon --_000_DM5PR16MB1788D907DAD514C3C0978ED8EA1F0DM5PR16MB1788namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

From:<= /span> Dots [mailto:dots-bou= nces@ietf.org] On Behalf Of Jon Shallow
Sent: Wednesday, January 3, 2018 6:44 PM
To: dots@ietf.org
Subject: [Dots] Clarity in use of ampersand in data channel

 

Hi All,

 

Should we be using & as a s= eparator in the namespace-uri of a RESTCONF request?

 

For example, in 7.3. Remove Fil= tering Rules, we have

 

     DELETE= /restconf/data/ietf-dots-data-channel:access-lists\

     &= nbsp;      /client-identifier=3Ddz6pHjaADkaFT= bjr0JGBpw\

     &= nbsp;      /acl-name=3Dsample-ipv4-acl&\<= /o:p>

     &= nbsp;      acl-type=3Dipv4-acl HTTP/1.1=

     Host: = {host}:{port}

 

Where there is …/acl-name= =3Dsample-ipv4-acl&acl-type=3Dipv4-acl .  I understand the intent = of this as acl-name=3D and acl-type=3D are an associated pair, but in the u= ri path should this really be …/acl-name=3Dsample-ipv4-acl/acl-type= =3Dipv4-acl ?

 

We have separated out .. /clien= t-identifier=3Ddz6pHjaADkaFTbjr0JGBpw/.. as a separate path component, so i= t makes sense to me to also use / instead of & for splitting out acl-na= me=3D and acl-type=3D.  NOTE: we need to be careful about defining parameter ordering here in the uri.

 

Although DOTS does not use such= YANG parameter name format, it would appear that, for example, “bill= &joe” is a valid entity in its own rights, so using & as a pa= rameter separator could be problematic..

 

RFC8040 only has / separators p= rior to a ? in its examples.

 

[TR] Yes, will update draft to = use / separator.

 

-Tiru

 

Comments welcome.

 

Regards

 

Jon

 

 

--_000_DM5PR16MB1788D907DAD514C3C0978ED8EA1F0DM5PR16MB1788namp_-- From nobody Thu Jan 4 06:02:07 2018 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 30E2F126579 for ; Thu, 4 Jan 2018 06:02:06 -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, T_MIME_MALF=0.01, T_RP_MATCHES_RCVD=-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 0mMdJIYf6IVD for ; Thu, 4 Jan 2018 06:02:04 -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 AC11112D867 for ; Thu, 4 Jan 2018 06:02: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 1eX65o-0008Pt-Up for ietf-supjps-dots@ietf.org; Thu, 04 Jan 2018 14:02:01 +0000 From: "Jon Shallow" To: Date: Thu, 4 Jan 2018 14:01:59 -0000 Message-ID: <0e0201d38564$97046db0$c50d4910$@jpshallow.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0E03_01D38564.9706DEB0" X-Mailer: Microsoft Outlook 14.0 Content-Language: en-gb Thread-Index: AdOFZJIYFWzZLX3YSl+jjYu0kjYH7w== Archived-At: Subject: [Dots] Data Channel POST challenges 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, 04 Jan 2018 14:02:06 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0E03_01D38564.9706DEB0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi there, With the merge of aliases and filters into a common YANG data model, I think the POST examples are now incorrect in the data channel draft, but still am challenged as to what to actually use. My understanding is below, but open to correction. [I also think identifier should be renamed to something like aliases to be more meaningful - to contrast access-lists] E.g. 6.1. Create Identifiers POST /restconf/data/ietf-dots-data-channel HTTP/1.1 Host: {host}:{port} Content-Type: application/yang-data+json { "ietf-dots-data-channel:identifier": { "client-identifier": [ "string" ], "alias": [ { "alias-name": "string", Should read [RFC8040 4.4.1. Create Resource Mode] as we are defining where we want to put the resource POST /restconf/data HTTP/1.1 Host: {host}:{port} Content-Type: application/yang-data+json { "ietf-dots-data-channel:identifier": { "client-identifier": [ "string" ], "alias": [ { "alias-name": "string", And the returned Location: header would contain "https://{host}:{port}/restconf/data/ietf-dots-data-channel:identifier" NOTE: [RFC8040 4.4.1. Create Resource Mode] "If the data resource already exists, then the POST request MUST fail and a "409 Conflict" status-line MUST be returned." This means to me that we can only create one alias set using POST when the resource is /restconf/data, and if we want to update the alias set at /restconf/data, we must do a DELETE followed by another POST, or use PUT. The PUT equivalent would be (I think) for creating or completing replacing the complete list of aliases [RFC8040 4.5. PUT] PUT /restconf/data HTTP/1.1 Host: {host}:{port} Content-Type: application/yang-data+json { "ietf-dots-data-channel:identifier": { "client-identifier": [ "string" ], "alias": [ { "alias-name": "string", Or to create / update a new alias-name (but what happens to client-identifier ? I think it is put in the path) - "string" in the URI will contain the actual value without quotes POST /restconf/data/ietf-dots-data-channel:identifier/client-identifier="string" HTTP/1.1 Host: {host}:{port} Content-Type: application/yang-data+json { "ietf-dots-data-channel:alias": [ { "alias-name": "string", Or ("string" replaced in URI as appropriate) PUT /restconf/data/ietf-dots-data-channel:identifier/client-identifier="string"/ alias="string" HTTP/1.1 Host: {host}:{port} Content-Type: application/yang-data+json { "ietf-dots-data-channel:alias": [ { "alias-name": "string", The same thing is needed for the access-lists, but also need to consider "insert" and "point". Comments / help needed! Regards Jon ------=_NextPart_000_0E03_01D38564.9706DEB0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi = there,

 

With the merge of aliases and filters into a common = YANG data model, I think the POST examples are now incorrect in the data = channel draft, but still am challenged as to what to actually use.  = My understanding is below, but open to correction.

 

[I also = think identifier should be renamed to something like aliases to be more = meaningful – to contrast access-lists]

 

E.g. 6.1. = Create Identifiers

 

    POST = /restconf/data/ietf-dots-data-channel HTTP/1.1

    Host: = {host}:{port}

    = Content-Type: application/yang-data+json

    {

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

       = "client-identifier": [

         &= nbsp;  "string"

   =     ],

       = "alias": [

         = {

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

 

 

Should read = [RFC8040 4.4.1. Create Resource Mode] as we are defining where we want = to put the resource

 

    POST /restconf/data = HTTP/1.1

    Host: = {host}:{port}

    = Content-Type: application/yang-data+json

    {

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

       = "client-identifier": [

         &= nbsp;  "string"

   =     ],

       = "alias": [

         = {

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

 

And the = returned Location: header would contain = “https://{host}:{port}/restconf/data/ietf-dots-data-channel:identif= ier”

 

NOTE:  [RFC8040 4.4.1. Create Resource Mode] = “If the data resource already exists, then the POST request MUST = fail

   and a "409 = Conflict" status-line MUST be returned.”

 

This means = to me that we can only create one alias set using POST when the resource = is /restconf/data, and if we want to update the alias set at = /restconf/data, we must do a DELETE followed by another POST, or use = PUT.

 

The PUT equivalent would be (I think) for creating or = completing replacing the complete list of aliases [RFC8040 4.5. = PUT]

 

    PUT /restconf/data = HTTP/1.1

    Host: = {host}:{port}

    = Content-Type: application/yang-data+json

    {

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

       = "client-identifier": [

         &= nbsp;  "string"

   =     ],

       = "alias": [

         = {

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

 

Or to create = / update a new alias-name (but what happens to client-identifier ?  = I think it is put in the path) – “string” in the URI = will contain the actual value without quotes

 

    POST = /restconf/data/ietf-dots-data-channel:identifier/client-identifier=3DR= 21;string” HTTP/1.1

    Host: = {host}:{port}

    = Content-Type: application/yang-data+json

    {

       = "ietf-dots-data-channel:alias": [

         = {

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

 

Or = (“string” replaced in URI as appropriate)

 

    PUT = /restconf/data/ietf-dots-data-channel:identifier/client-identifier=3DR= 21;string”/alias=3D”string” HTTP/1.1

    Host: = {host}:{port}

    = Content-Type: application/yang-data+json

    {

       = "ietf-dots-data-channel:alias": [

         = {

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

 

 

The same = thing is needed for the access-lists, but also need to consider = “insert” and “point”.

Comments / help = needed!

 

Regards

 

Jon

------=_NextPart_000_0E03_01D38564.9706DEB0-- From nobody Thu Jan 4 06:17:30 2018 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 A9AA212D862; Thu, 4 Jan 2018 06:17:28 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Meeting Session Request Tool To: Cc: rdd@cert.org, dots-chairs@ietf.org, Kathleen.Moriarty.ietf@gmail.com, dots@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.68.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151507544864.23762.9762820758592708739.idtracker@ietfa.amsl.com> Date: Thu, 04 Jan 2018 06:17:28 -0800 Archived-At: Subject: [Dots] dots - New Meeting Session Request for IETF 101 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, 04 Jan 2018 14:17:28 -0000 A new meeting session request has just been submitted by Roman Danyliw, a Chair of the dots working group. --------------------------------------------------------- Working Group Name: DDoS Open Threat Signaling Area Name: Security Area Session Requester: Roman Danyliw Number of Sessions: 1 Length of Session(s): 2 Hours Number of Attendees: 80 Conflicts to Avoid: First Priority: mile i2nsf sacm saag Second Priority: opsawg People who must be present: Kathleen Moriarty Roman Danyliw Tobias Gondrom Resources Requested: Special Requests: --------------------------------------------------------- From nobody Thu Jan 4 07:20:17 2018 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 B0B0C12D879 for ; Thu, 4 Jan 2018 07:20:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.375 X-Spam-Level: X-Spam-Status: No, score=-4.375 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, HTTP_ESCAPED_HOST=1.125, RCVD_IN_DNSWL_HI=-5, RCVD_IN_SORBS_WEB=1.5, SPF_PASS=-0.001, T_MIME_MALF=0.01, T_RP_MATCHES_RCVD=-0.01] 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 ZA5YeG7v-26I for ; Thu, 4 Jan 2018 07:20:13 -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 484871267BB for ; Thu, 4 Jan 2018 07:20: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=1515079212; 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:x-microsoft-antispam-message-info: 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=EagosVPU9OlDOXGjZU9eHUUDh9lFaKHIMr79KU r6Xfk=; b=ICFSNhCSZvSRgk4tzKNNKnhNtongTK17TI8lIQVJ 4t8hSYBRCaMkjmbht8e4sybcxnEkYH5DwhEqSMvtBAvWdndJvH dn2L/tRGwsEdT+kImR2QYyo5UjNkNOfL9iH5nAEZwDRI8aV7ub 61v7zcPNmT1rF4ZCRv+0OwKG2MFBbSM= Received: from MIVEXAPP1N03.corpzone.internalzone.com (unknown [10.48.48.90]) by MIVWSMAILOUT1.mcafee.com with smtp (TLS: TLSv1/SSLv3,256bits,ECDHE-RSA-AES256-SHA384) id 013e_8d00_a958759f_dbb4_451d_ab24_d2cedf27ab64; Thu, 04 Jan 2018 09:20:11 -0600 Received: from MIVEXUSR1N01.corpzone.internalzone.com (10.48.48.81) by MIVEXAPP1N03.corpzone.internalzone.com (10.48.48.90) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Thu, 4 Jan 2018 10:20:10 -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; Thu, 4 Jan 2018 10:20:09 -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, 4 Jan 2018 10:20:09 -0500 Received: from NAM03-DM3-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, 4 Jan 2018 10:20:05 -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.366.8; Thu, 4 Jan 2018 15:20:05 +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.0366.009; Thu, 4 Jan 2018 15:20:05 +0000 From: "Konda, Tirumaleswar Reddy" To: Jon Shallow , "dots@ietf.org" Thread-Topic: [Dots] Data Channel POST challenges Thread-Index: AdOFZJIYFWzZLX3YSl+jjYu0kjYH7wACsXzQ Date: Thu, 4 Jan 2018 15:20:05 +0000 Message-ID: References: <0e0201d38564$97046db0$c50d4910$@jpshallow.com> In-Reply-To: <0e0201d38564$97046db0$c50d4910$@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.16.166] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DM5PR16MB1786; 7:wnJNnFlYOTgJbv+S/5Kx1hXMKL1rhXGdRcU2R25OvMnKIU2G7pMLQv0INmSf1XEMPFT7fbV6Hdl9Dzn7HdW3OoVoHkSQfwl2TG+Y6Z7sZJBSHWp7BBoT7Ce2wpEcmw8GS23gh4UuPqqRzsCr8O7Sc+XxKIvl52uCyE0gZuo5jRDxv9aQr6sFmJBgI3IuRAMNG3gv5Fsx+QD1nxLSD94ABqu89gm7/MbKNCmFM4TVXXb665Luwy7qBD1vIQ0P61Ux x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 933a3ed8-d260-45af-f40e-08d55386a23a x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(5600026)(4604075)(3008032)(2017052603307)(7153060); SRVR:DM5PR16MB1786; x-ms-traffictypediagnostic: DM5PR16MB1786: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040470)(2401047)(8121501046)(5005006)(3002001)(3231023)(944501075)(93006095)(93001095)(10201501046)(6041268)(20161123558120)(20161123560045)(20161123562045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123564045)(6072148)(201708071742011); SRVR:DM5PR16MB1786; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:DM5PR16MB1786; x-forefront-prvs: 054231DC40 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(396003)(366004)(346002)(39380400002)(376002)(39850400004)(32952001)(189003)(199004)(14454004)(59450400001)(81166006)(81156014)(55016002)(7696005)(3660700001)(53936002)(76176011)(7736002)(8676002)(106356001)(105586002)(33656002)(478600001)(3280700002)(966005)(606006)(77096006)(9686003)(6436002)(72206003)(6306002)(236005)(316002)(54896002)(110136005)(74316002)(99286004)(229853002)(2906002)(80792005)(2501003)(66066001)(19609705001)(25786009)(97736004)(86362001)(2900100001)(53546011)(3846002)(790700001)(6116002)(9326002)(6506007)(6246003)(102836004)(68736007)(2950100002)(5660300001)(8936002)(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) x-microsoft-antispam-message-info: tmfrwvEoKs75yxNRx69dOtiT6dje99RZv9G7ofJlR8CjqR5gOfI5Fd1Lg5xpl8A7cfMcl8YiYaKjcT04D5RU2A== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_DM5PR16MB1788DA2747ECEA3702A8C04DEA1F0DM5PR16MB1788namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 933a3ed8-d260-45af-f40e-08d55386a23a X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Jan 2018 15:20:05.4195 (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 <6193> : inlines <6294> : streams <1775089> : uri <2563036> Archived-At: Subject: Re: [Dots] Data Channel POST challenges 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, 04 Jan 2018 15:20:16 -0000 --_000_DM5PR16MB1788DA2747ECEA3702A8C04DEA1F0DM5PR16MB1788namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Jon, Please see inline From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Jon Shallow Sent: Thursday, January 4, 2018 7:32 PM To: dots@ietf.org Subject: [Dots] Data Channel POST challenges Hi there, With the merge of aliases and filters into a common YANG data model, I thin= k the POST examples are now incorrect in the data channel draft, but still = am challenged as to what to actually use. My understanding is below, but o= pen to correction. [I also think identifier should be renamed to something like aliases to be = more meaningful - to contrast access-lists] E.g. 6.1. Create Identifiers POST /restconf/data/ietf-dots-data-channel HTTP/1.1 Host: {host}:{port} Content-Type: application/yang-data+json { "ietf-dots-data-channel:identifier": { "client-identifier": [ "string" ], "alias": [ { "alias-name": "string", Should read [RFC8040 4.4.1. Create Resource Mode] as we are defining where = we want to put the resource POST /restconf/data HTTP/1.1 Host: {host}:{port} Content-Type: application/yang-data+json { "ietf-dots-data-channel:identifier": { "client-identifier": [ "string" ], "alias": [ { "alias-name": "string", And the returned Location: header would contain "https://{host}:{port}/rest= conf/data/ietf-dots-data-channel:identifier" [TR] The above examples you provided do not look correct, please see https:= //tools.ietf.org/html/rfc8040#appendix-B.2.1 -Tiru NOTE: [RFC8040 4.4.1. Create Resource Mode] "If the data resource already = exists, then the POST request MUST fail and a "409 Conflict" status-line MUST be returned." This means to me that we can only create one alias set using POST when the = resource is /restconf/data, and if we want to update the alias set at /rest= conf/data, we must do a DELETE followed by another POST, or use PUT. The PUT equivalent would be (I think) for creating or completing replacing = the complete list of aliases [RFC8040 4.5. PUT] PUT /restconf/data HTTP/1.1 Host: {host}:{port} Content-Type: application/yang-data+json { "ietf-dots-data-channel:identifier": { "client-identifier": [ "string" ], "alias": [ { "alias-name": "string", Or to create / update a new alias-name (but what happens to client-identifi= er ? I think it is put in the path) - "string" in the URI will contain the= actual value without quotes POST /restconf/data/ietf-dots-data-channel:identifier/client-identifier= =3D"string" HTTP/1.1 Host: {host}:{port} Content-Type: application/yang-data+json { "ietf-dots-data-channel:alias": [ { "alias-name": "string", Or ("string" replaced in URI as appropriate) PUT /restconf/data/ietf-dots-data-channel:identifier/client-identifier= =3D"string"/alias=3D"string" HTTP/1.1 Host: {host}:{port} Content-Type: application/yang-data+json { "ietf-dots-data-channel:alias": [ { "alias-name": "string", The same thing is needed for the access-lists, but also need to consider "i= nsert" and "point". Comments / help needed! Regards Jon --_000_DM5PR16MB1788DA2747ECEA3702A8C04DEA1F0DM5PR16MB1788namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Jon,

&nbs= p;

Please se= e inline

 

From:<= /span> Dots [mailto:dots-bou= nces@ietf.org] On Behalf Of Jon Shallow
Sent: Thursday, January 4, 2018 7:32 PM
To: dots@ietf.org
Subject: [Dots] Data Channel POST challenges

 

Hi there,

 

With the merge of aliases and f= ilters into a common YANG data model, I think the POST examples are now inc= orrect in the data channel draft, but still am challenged as to what to act= ually use.  My understanding is below, but open to correction.

 

[I also think identifier should= be renamed to something like aliases to be more meaningful – to cont= rast access-lists]

 

E.g. 6.1. Create Identifiers

 

    POST /restco= nf/data/ietf-dots-data-channel HTTP/1.1

    Host: {host}= :{port}

    Content-Type= : application/yang-data+json

    {=

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

     &= nbsp; "client-identifier": [

     &= nbsp;      "string"

      =  ],

     &= nbsp; "alias": [

     &= nbsp;   {

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

 

 

Should read [RFC8040 4.4.1. Cre= ate Resource Mode] as we are defining where we want to put the resource

 

    POST /restco= nf/data HTTP/1.1

    Host: {host}= :{port}

    Content-Type= : application/yang-data+json

    {=

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

     &= nbsp; "client-identifier": [

     &= nbsp;      "string"

      =  ],

     &= nbsp; "alias": [

     &= nbsp;   {

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

 

And the returned Location: head= er would contain “https://{host}:{port}/restconf/data/= ietf-dots-data-channel:identifier”

 

[TR] The above examples you pro= vided do not look correct, please see https://tool= s.ietf.org/html/rfc8040#appendix-B.2.1

 

-Tiru

 

NOTE:  [RFC8040 4.4.1. Cre= ate Resource Mode] “If the data resource already exists, then the POS= T request MUST fail

   and a "409 Co= nflict" status-line MUST be returned.”

 

This means to me that we can on= ly create one alias set using POST when the resource is /restconf/data, and= if we want to update the alias set at /restconf/data, we must do a DELETE = followed by another POST, or use PUT.

 

The PUT equivalent would be (I = think) for creating or completing replacing the complete list of aliases [R= FC8040 4.5. PUT]

 

    PUT /restcon= f/data HTTP/1.1

    Host: {host}= :{port}

    Content-Type= : application/yang-data+json

    {=

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

     &= nbsp; "client-identifier": [

     &= nbsp;      "string"

      =  ],

     &= nbsp; "alias": [

     &= nbsp;   {

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

 

Or to create / update a new ali= as-name (but what happens to client-identifier ?  I think it is put in= the path) – “string” in the URI will contain the actual = value without quotes

 

    POST /restco= nf/data/ietf-dots-data-channel:identifier/client-identifier=3D”string= ” HTTP/1.1

    Host: {host}= :{port}

    Content-Type= : application/yang-data+json

    {=

     &= nbsp; "ietf-dots-data-channel:alias": [

     &= nbsp;   {

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

 

Or (“string” replac= ed in URI as appropriate)

 

    PUT /restcon= f/data/ietf-dots-data-channel:identifier/client-identifier=3D”string&= #8221;/alias=3D”string” HTTP/1.1

    Host: {host}= :{port}

    Content-Type= : application/yang-data+json

    {=

     &= nbsp; "ietf-dots-data-channel:alias": [

     &= nbsp;   {

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

 

 

The same thing is needed for th= e access-lists, but also need to consider “insert” and “p= oint”.

 

Comments / help needed!

 

Regards

 

Jon

--_000_DM5PR16MB1788DA2747ECEA3702A8C04DEA1F0DM5PR16MB1788namp_-- From nobody Thu Jan 4 07:36:32 2018 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 3778F126BFD for ; Thu, 4 Jan 2018 07:36:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.775 X-Spam-Level: X-Spam-Status: No, score=-0.775 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTTP_ESCAPED_HOST=1.125, SPF_PASS=-0.001, T_MIME_MALF=0.01, T_RP_MATCHES_RCVD=-0.01] autolearn=no 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 HsJzucR0xtKk for ; Thu, 4 Jan 2018 07:36:28 -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 452D61267BB for ; Thu, 4 Jan 2018 07:36:28 -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 1eX7ZB-0008TQ-LP; Thu, 04 Jan 2018 15:36:25 +0000 From: "Jon Shallow" To: "'Konda, Tirumaleswar Reddy'" , References: <0e0201d38564$97046db0$c50d4910$@jpshallow.com> In-Reply-To: Date: Thu, 4 Jan 2018 15:36:24 -0000 Message-ID: <0e2701d38571$c7699360$563cba20$@jpshallow.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0E28_01D38571.C76C0460" X-Mailer: Microsoft Outlook 14.0 Content-Language: en-gb Thread-Index: AQH3N10FNy2Z82aDvlBGG5IuSUEn0wL9ZeElowSF3JA= Archived-At: Subject: Re: [Dots] Data Channel POST challenges 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, 04 Jan 2018 15:36:30 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0E28_01D38571.C76C0460 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Tiru, See inline Regards Jon From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of Konda, Tirumaleswar Reddy Sent: 04 January 2018 15:20 To: Jon Shallow; dots@ietf.org Subject: Re: [Dots] Data Channel POST challenges Hi Jon, Please see inline From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Jon Shallow Sent: Thursday, January 4, 2018 7:32 PM To: dots@ietf.org Subject: [Dots] Data Channel POST challenges Hi there, With the merge of aliases and filters into a common YANG data model, I think the POST examples are now incorrect in the data channel draft, but still am challenged as to what to actually use. My understanding is below, but open to correction. [I also think identifier should be renamed to something like aliases to be more meaningful - to contrast access-lists] E.g. 6.1. Create Identifiers POST /restconf/data/ietf-dots-data-channel HTTP/1.1 Host: {host}:{port} Content-Type: application/yang-data+json { "ietf-dots-data-channel:identifier": { "client-identifier": [ "string" ], "alias": [ { "alias-name": "string", Should read [RFC8040 4.4.1. Create Resource Mode] as we are defining where we want to put the resource POST /restconf/data HTTP/1.1 Host: {host}:{port} Content-Type: application/yang-data+json { "ietf-dots-data-channel:identifier": { "client-identifier": [ "string" ], "alias": [ { "alias-name": "string", And the returned Location: header would contain "https://{host}:{port}/restconf/data/ietf-dots-data-channel:identifier " [TR] The above examples you provided do not look correct, please see https://tools.ietf.org/html/rfc8040#appendix-B.2.1 [Jon] The above example is for the complete replacement of the data container (B.2.4), or first addition of an entry (POST 4.4.1) (i.e. working with a datastore resource) that defines everything, the below last 2 examples are in-line with B.2.1 (creating a data resource within a data resource) as I read the RFC. -Tiru NOTE: [RFC8040 4.4.1. Create Resource Mode] "If the data resource already exists, then the POST request MUST fail and a "409 Conflict" status-line MUST be returned." This means to me that we can only create one alias set using POST when the resource is /restconf/data, and if we want to update the alias set at /restconf/data, we must do a DELETE followed by another POST, or use PUT. The PUT equivalent would be (I think) for creating or completing replacing the complete list of aliases [RFC8040 4.5. PUT] PUT /restconf/data HTTP/1.1 Host: {host}:{port} Content-Type: application/yang-data+json { "ietf-dots-data-channel:identifier": { "client-identifier": [ "string" ], "alias": [ { "alias-name": "string", Or to create / update a new alias-name (but what happens to client-identifier ? I think it is put in the path) - "string" in the URI will contain the actual value without quotes POST /restconf/data/ietf-dots-data-channel:identifier/client-identifier="string" HTTP/1.1 Host: {host}:{port} Content-Type: application/yang-data+json { "ietf-dots-data-channel:alias": [ { "alias-name": "string", Or ("string" replaced in URI as appropriate) PUT /restconf/data/ietf-dots-data-channel:identifier/client-identifier="string"/ alias="string" HTTP/1.1 Host: {host}:{port} Content-Type: application/yang-data+json { "ietf-dots-data-channel:alias": [ { "alias-name": "string", The same thing is needed for the access-lists, but also need to consider "insert" and "point". Comments / help needed! Regards Jon ------=_NextPart_000_0E28_01D38571.C76C0460 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Tiru,

 

See = inline

 

Regards

 

Jon

 

From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of = Konda, Tirumaleswar Reddy
Sent: 04 January 2018 = 15:20
To: Jon Shallow; dots@ietf.org
Subject: Re: = [Dots] Data Channel POST challenges

 

Hi = Jon,

 

Please see inline =

 

From: Dots [mailto:dots-bounces@ietf.org] = On Behalf Of Jon Shallow
Sent: Thursday, January 4, = 2018 7:32 PM
To: dots@ietf.org
Subject: = [Dots] Data Channel POST challenges

 

Hi there,

 

With the = merge of aliases and filters into a common YANG data model, I think the = POST examples are now incorrect in the data channel draft, but still am = challenged as to what to actually use.  My understanding is below, = but open to correction.

 

[I also = think identifier should be renamed to something like aliases to be more = meaningful – to contrast access-lists]

 

E.g. 6.1. = Create Identifiers

 

    POST = /restconf/data/ietf-dots-data-channel HTTP/1.1

    Host: = {host}:{port}

    = Content-Type: application/yang-data+json

    {

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

       = "client-identifier": [

         &= nbsp;  "string"

   =     ],

       = "alias": [

         = {

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

 

 

Should read = [RFC8040 4.4.1. Create Resource Mode] as we are defining where we want = to put the resource

 

    POST /restconf/data = HTTP/1.1

    Host: = {host}:{port}

    = Content-Type: application/yang-data+json

    {

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

       = "client-identifier": [

         &= nbsp;  "string"

   =     ],

       = "alias": [

         = {

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

 

And the = returned Location: header would contain “https://{host}:{port}/restconf/data/ietf-dots-data-channel:= identifier”

 

[TR] The = above examples you provided do not look correct, please see https://tools= .ietf.org/html/rfc8040#appendix-B.2.1

 

[Jon] The above example = is for the complete replacement of the data container (B.2.4), or first = addition of an entry (POST 4.4.1) (i.e. working with a datastore = resource) that defines everything, the below last 2 examples are in-line = with B.2.1 (creating a data resource within a data resource) as I read = the RFC.

 

-Tiru

 

NOTE: =  [RFC8040 4.4.1. Create Resource Mode] “If the data resource = already exists, then the POST request MUST fail

   and a "409 Conflict" = status-line MUST be returned.”

 

This means = to me that we can only create one alias set using POST when the resource = is /restconf/data, and if we want to update the alias set at = /restconf/data, we must do a DELETE followed by another POST, or use = PUT.

 

The PUT equivalent would be (I think) for creating or = completing replacing the complete list of aliases [RFC8040 4.5. = PUT]

 

    PUT /restconf/data = HTTP/1.1

    Host: = {host}:{port}

    = Content-Type: application/yang-data+json

    {

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

       = "client-identifier": [

         &= nbsp;  "string"

   =     ],

       = "alias": [

         = {

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

 

Or to create = / update a new alias-name (but what happens to client-identifier ?  = I think it is put in the path) – “string” in the URI = will contain the actual value without quotes

 

    POST = /restconf/data/ietf-dots-data-channel:identifier/client-identifier=3DR= 21;string” HTTP/1.1

    Host: = {host}:{port}

    = Content-Type: application/yang-data+json

    {

       = "ietf-dots-data-channel:alias": [

         = {

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

 

Or = (“string” replaced in URI as appropriate)

 

    PUT = /restconf/data/ietf-dots-data-channel:identifier/client-identifier=3DR= 21;string”/alias=3D”string” HTTP/1.1

    Host: = {host}:{port}

    = Content-Type: application/yang-data+json

    {

       = "ietf-dots-data-channel:alias": [

         = {

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

 

 

The same = thing is needed for the access-lists, but also need to consider = “insert” and “point”.

 

Comments / = help needed!

 

Regards

 

Jon

------=_NextPart_000_0E28_01D38571.C76C0460-- From nobody Thu Jan 4 10:32:20 2018 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 80E9B12AF6E for ; Thu, 4 Jan 2018 10:32:19 -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 L5qeTo9IGFaC for ; Thu, 4 Jan 2018 10:32:17 -0800 (PST) Received: from taper.sei.cmu.edu (taper.sei.cmu.edu [147.72.252.16]) (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 454381270A3 for ; Thu, 4 Jan 2018 10:32:17 -0800 (PST) Received: from delp.sei.cmu.edu (delp.sei.cmu.edu [10.64.21.31]) by taper.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id w04IWFtK012396 for ; Thu, 4 Jan 2018 13:32:15 -0500 DKIM-Filter: OpenDKIM Filter v2.11.0 taper.sei.cmu.edu w04IWFtK012396 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cert.org; s=yc2bmwvrj62m; t=1515090735; bh=LnOajQo4OPdBVyuLAKs6FoufyE+FupcCghwta3hGxeU=; h=From:To:Subject:Date:From; b=kju5X8frd5qFagZ1namKxafvIpl+DphhiDumWyhwFhW+YnUMlfHecTLrWeaMU5IYx 9w3SA7LWUVGpZmI3VzIg/2nuWh6Wjgn9RDf0aa4he74ya9QE2KVqOJKKa5dVpUZ3j2 Ho1z2p5gu9ryKVRhF/4PSSt4583GhiQmEWgVagUI= Received: from CASCADE.ad.sei.cmu.edu (cascade.ad.sei.cmu.edu [10.64.28.248]) by delp.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id w04IWBPM011894 for ; Thu, 4 Jan 2018 13:32:12 -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; Thu, 4 Jan 2018 13:32:11 -0500 From: Roman Danyliw To: "dots@ietf.org" Thread-Topic: Closing the WGLC on draft-ietf-dots-requirements Thread-Index: AdOFh4cTAD490ejCRnOZk2LBZMApJA== Date: Thu, 4 Jan 2018 18:32:11 +0000 Message-ID: <359EC4B99E040048A7131E0F4E113AFC0131357BC7@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] Closing the WGLC on draft-ietf-dots-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: Thu, 04 Jan 2018 18:32:19 -0000 Hello! The period for the working group last call (WGLC) for draft-ietf-dots-requi= rements ended. Thank you Mohamed Boucadair, Jon Shallow, Kaname Nishizuka,= Flemming Andreasen, and Liang Xia for providing public feedback. Major issues don't appear to have been identified. A -10 draft was publish= ed during the call to address some of the identified issues. Another updat= e will be required to cover the rest. We'll let the authors of the draft p= arse that feedback and iterate with the reviewers as needed to produce this= update. As reference, the following messages start the unique discussion threads th= at identify issues with the draft: ** From: Mohamed Boucadair https://www.ietf.org/mail-archive/web/dots/current/msg01729.html https://www.ietf.org/mail-archive/web/dots/current/msg01769.html ** From: Jon Shallow https://www.ietf.org/mail-archive/web/dots/current/msg01778.html https://www.ietf.org/mail-archive/web/dots/current/msg01850.html ** From: Flemming Andreasen=20 https://www.ietf.org/mail-archive/web/dots/current/msg01862.html ** From: Roman Danyliw https://www.ietf.org/mail-archive/web/dots/current/msg01873.html Regards, Roman From nobody Thu Jan 4 11:30:45 2018 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 DBC20129C6B for ; Thu, 4 Jan 2018 11:30:44 -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 z_PpgoRFs8mk for ; Thu, 4 Jan 2018 11:30:42 -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 609F2124E15 for ; Thu, 4 Jan 2018 11:30:42 -0800 (PST) Received: from pps.filterd (m0096263.ppops.net [127.0.0.1]) by mx0a-00196b01.pphosted.com (8.16.0.21/8.16.0.21) with SMTP id w04JQD64011061; Thu, 4 Jan 2018 14:30:38 -0500 Received: from nam02-cy1-obe.outbound.protection.outlook.com (mail-cys01nam02lp0048.outbound.protection.outlook.com [207.46.163.48]) by mx0a-00196b01.pphosted.com with ESMTP id 2f9adggy55-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Thu, 04 Jan 2018 14:30:38 -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=hrxVBMXAL34r09T6C/NdII7GHDoc8gVgpllpKoJmENc=; b=idrD5nyu9abhjR81pC60HBlZQPHr/JkRh3O9tFWgwddKOgc2mtxpos+kpsPtAq+NgDflCdsWtiLkFMaJO7NwQwquSuCY8eLWEuuhVWAHqMKEHf04Ccz4ov9MoUmscu4E15wBXI2U5XQtviSSdj8eJ7tpuQ5cOCLa7lux3qI1hJQ= Received: from BN3PR01MB1987.prod.exchangelabs.com (10.166.71.144) by BN3PR01MB1987.prod.exchangelabs.com (10.166.71.144) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.386.5; Thu, 4 Jan 2018 19:30:36 +0000 Received: from BN3PR01MB1987.prod.exchangelabs.com ([10.166.71.144]) by BN3PR01MB1987.prod.exchangelabs.com ([10.166.71.144]) with mapi id 15.20.0386.006; Thu, 4 Jan 2018 19:30:36 +0000 From: "Mortensen, Andrew" To: Roman Danyliw CC: "dots@ietf.org" Thread-Topic: [Dots] Feedback on draft-ietf-dots-requirements Thread-Index: AdOE4a/XR+KnbzsFQl+L7JY1uUa37wAsM4yA Date: Thu, 4 Jan 2018 19:30:36 +0000 Message-ID: <59B81C16-86E7-4EAF-8AEB-CFDF53A5E11E@arbor.net> References: <359EC4B99E040048A7131E0F4E113AFC0131356BB5@marathon> In-Reply-To: <359EC4B99E040048A7131E0F4E113AFC0131356BB5@marathon> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2620:11e:1000:10:bdfc:d19f:87c0:ab57] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BN3PR01MB1987; 7:Zy646UV9BOzSxvQRLQgZ/dG4ccjCYs9p/ljUTBrssSy/3uSX0jZfn0vGnbPE1yibjFcvy7FsSOvmwjg6SUMui7ugHAq/uW9vvIRTouIU66jbX3rSTV2rKmMXkFnTwElsx3NBeXsxIJQgClO7V4m2ZtkbSAWQ5SnejsG7cmoCgBHCkLcPKJJy3kFlod5lKqRC9U3VEIEOuMkUuSDRcs1f4ukxpuYI5K9BXp0OEo6ffKDp57ba2NZvBmE+8wUNgTnF x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: f598abda-5ead-4310-a1d7-08d553a9a153 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(5600026)(4604075)(3008032)(2017052603307)(7153060); SRVR:BN3PR01MB1987; x-ms-traffictypediagnostic: BN3PR01MB1987: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(192374486261705); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040470)(2401047)(5005006)(8121501046)(3231023)(944501075)(3002001)(10201501046)(93006095)(93001095)(6041268)(20161123558120)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(20161123564045)(20161123562045)(6072148)(201708071742011); SRVR:BN3PR01MB1987; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:BN3PR01MB1987; x-forefront-prvs: 054231DC40 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(346002)(39380400002)(396003)(376002)(39850400004)(366004)(51914003)(51444003)(199004)(189003)(24454002)(4326008)(305945005)(478600001)(7736002)(76176011)(25786009)(6436002)(106356001)(8936002)(68736007)(81156014)(3280700002)(81166006)(14454004)(3660700001)(105586002)(8676002)(33656002)(82746002)(83716003)(2950100002)(6916009)(53936002)(2900100001)(97736004)(5660300001)(316002)(6486002)(6116002)(59450400001)(53546011)(6506007)(6246003)(86362001)(6512007)(36756003)(99286004)(229853002)(230783001)(102836004)(77096006)(2906002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR01MB1987; H:BN3PR01MB1987.prod.exchangelabs.com; 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-antispam-message-info: JzccBZyH9l49PBBLQcgq146CRb2+O0NUILYO63+jJjaIpHbpOvHU7ud0in4GBL9grOeLQpxqZGU4c7l0HeuteQ== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: <8DFD1A5789ED974BA9A0E9825CFB3983@prod.exchangelabs.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: arbor.net X-MS-Exchange-CrossTenant-Network-Message-Id: f598abda-5ead-4310-a1d7-08d553a9a153 X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Jan 2018 19:30:36.1953 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 54f11205-d4aa-4809-bd36-0b542199c5b2 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR01MB1987 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-01-04_08:, , 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 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1801040266 Archived-At: Subject: Re: [Dots] Feedback on draft-ietf-dots-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: Thu, 04 Jan 2018 19:30:45 -0000 VGhhbmtzIGZvciB0aGUgdmVyeSBjbG9zZSByZWFkaW5nLCBSb21hbi4gSW4gZ2VuZXJhbCB0aGUg ZWRpdG9yaWFsIGNoYW5nZXMgbG9vayBmaW5lLiBBIGZldyBjb21tZW50cyBhbmQgcXVlc3Rpb25z IGlubGluZSBiZWxvdy4NCg0KYW5kcmV3DQoNCg0KPiBPbiBKYW4gMywgMjAxOCwgYXQgNTozMiBQ TSwgUm9tYW4gRGFueWxpdyA8cmRkQGNlcnQub3JnPiB3cm90ZToNCj4gDQo+IEhlbGxvIQ0KPiAo Y2hhaXIgaGF0IG9mZikNCj4gDQo+IFRoZSBmb2xsb3dpbmcgaXMgZmVlZGJhY2sgZm9yIHRoZSBX R0xDIG9uIC0wOSBvZiBkcmFmdC1pZXRmLWRvdHMtcmVxdWlyZW1lbnRzLiAgRXZlbiB3aXRoIHRo ZSAtMTAgdXBkYXRlLCB0aGVzZSBzaG91bGQgYXBwbHkuICBPdGhlciB0aGFuIHRoZSBmZWVkYmFj ayBiZWxvdywgSSBiZWxpZXZlIHRoZSBkcmFmdCBpcyByZWFkeSB0byBwcm9jZWVkLg0KPiANCj4g KDEpIEFic3RyYWN0LiAgRWRpdG9yaWFsLg0KPiANCj4gLSAiVGhpcyBkb2N1bWVudCBkZWZpbmVz IHRoZSByZXF1aXJlbWVudHMgZm9yIHRoZSBEaXN0cmlidXRlZCBEZW5pYWwgb2YgU2VydmljZSAo RERvUykgT3BlbiBUaHJlYXQgU2lnbmFsaW5nIChET1RTKSBwcm90b2NvbHMgY29vcmRpbmF0aW5n IGF0dGFjayByZXNwb25zZSBhZ2FpbnN0IEREb1MgYXR0YWNrcy4iDQo+ICsgIlRoaXMgZG9jdW1l bnQgZGVmaW5lcyB0aGUgcmVxdWlyZW1lbnRzIGZvciB0aGUgRGlzdHJpYnV0ZWQgRGVuaWFsIG9m IFNlcnZpY2UgKEREb1MpIE9wZW4gVGhyZWF0IFNpZ25hbGluZyAoRE9UUykgcHJvdG9jb2xzIHRo YXQgZW5hYmxlIHRoZSBjb29yZGluYXRpb24gb2YgYW5kICByZXNwb25zZSB0byBERG9TIGF0dGFj a3Mu4oCdDQoNCkkgdGhpbmsgd2UganVzdCB3YW50IOKAnOKApmVuYWJsZSBjb29yZGluYXRpb24g b2YgcmVzcG9uc2UgdG/igKbigJ0sIHNpbmNlIHdl4oCZcmUgb3RoZXJ3aXNlIGxlZnQgd2l0aCDi gJzigKZjb29yZGluYXRpb24gb2bigKZERG9TIGF0dGFja3PigJ0sIHdoaWNoIGlzIGNsZWFybHkg bm90IHRoZSBtZWFuaW5nIHdl4oCZcmUgc2hvb3RpbmcgZm9yLg0KDQoNCj4g4oCmc25pcC4uLg0K PiANCj4gKDkpIFNlY3Rpb24gMS4yLCBUZXJtaW5vbG9neSwgTWl0aWdhdG9yLiBFZGl0b3JpYWwg KGNsYXJpdHkpDQo+IA0KPiAtIC4uLiAgRm9yDQo+ICAgICAgdGhlIHB1cnBvc2VzIG9mIHRoaXMg ZG9jdW1lbnQsIHRoaXMgZW50aXR5IGlzIGEgYmxhY2sgYm94IGNhcGFibGUNCj4gICAgICBvZiBt aXRpZ2F0aW9uLCBtYWtpbmcgbm8gYXNzdW1wdGlvbnMgYWJvdXQgYXZhaWxhYmlsaXR5IG9yIGRl c2lnbg0KPiAgICAgIG9mIGNvdW50ZXJtZWFzdXJlcywgbm9yIGFib3V0IHRoZSBwcm9ncmFtbWFi bGUgaW50ZXJmYWNlKHMpDQo+ICAgICAgYmV0d2VlbiB0aGlzIGVudGl0eSBhbmQgb3RoZXIgbmV0 d29yayBlbGVtZW50cy4gIA0KPiANCj4gKyBUaGUgbWVhbnMgYnkgd2hpY2ggdGhpcyBlbnRpdHkg cGVyZm9ybXMgdGhlc2UgbWl0aWdhdGlvbnMgYW5kIGhvdyB0aGV5IGFyZSByZXF1ZXN0ZWQgb2Yg aXQgYXJlIG91dCBvZiBzY29wZS4NCg0KTWF5YmUg4oCc4oCmaG93IHRoZXkgYXJlIGNvbmZpZ3Vy ZWQgYW5kIG1hbmFnZWQgW29yIG1haW50YWluZWRd4oCm4oCdIGluc3RlYWQ/IFRoZSB0ZXJtIOKA nG1pdGlnYXRpb24gcmVxdWVzdOKAnSBoYXMgYSB2ZXJ5IHNwZWNpZmljIG1lYW5pbmcgaW4gRE9U Uy4NCg0KDQo+IOKApnNuaXAuLi4NCj4gDQo+ICgxMikgU2VjdGlvbiAxLjIsIFRlcm1pbm9sb2d5 LCBET1RTIHNlcnZlci4gIEluIHRoZSBzZW50ZW5jZSwgIiBBIERPVFMgc2VydmVyIG1heSBhbHNv IGJlIGNvbG9jYXRlZCAgd2l0aCBhIG1pdGlnYXRvciIsIHdoYXQgZG9lcyAiY29sbG9jYXRlZCIg bWVhbiBpbiB0aGlzIGNvbnRleHQ/DQoNClRoZSBvcmlnaW5hbCBjb25jbHVkaW5nIHNlbnRlbmNl IHdhcyDigJxBIERPVFMgc2VydmVyIE1BWSBhbHNvIGJlIGEgbWl0aWdhdG9y4oCdICh3aXRoIHVu bmVjZXNzYXJ5IFJGQyAyMTE5IHRlcm0pLiBBZnRlciB0aGlua2luZyBhYm91dCBpdCBhIGJpdCwg SeKAmW0gbm90IHN1cmUgdGhhdCBlaXRoZXIgdGhlIGN1cnJlbnQgcGhyYXNpbmcgb3IgdGhlIG9y aWdpbmFsIGFyZSBuZWNlc3NhcnkgdG8gdGhlIGRyYWZ0LiBEb2VzIGFueW9uZSBvYmplY3QgdG8g cmVtb3ZpbmcgaXQ/DQoNCg0KPiDigKZzbmlw4oCmDQo+IA0KPiAoMjUpIFNlY3Rpb24gMi4xLCBH RU4tMDAxLiAgRWRpdG9yaWFsLg0KPiANCj4gLSBQcm90b2NvbHMgYW5kIGRhdGEgbW9kZWxzIGRl dmVsb3BlZCBhcyBwYXJ0DQo+ICAgICAgb2YgRE9UUyBNVVNUIGJlIGV4dGVuc2libGUgaW4gb3Jk ZXIgdG8ga2VlcCBET1RTIGFkYXB0YWJsZSB0bw0KPiAgICAgIGZ1dHVyZSBvcGVyYXRpb25hbCBh bmQgcHJvcHJpZXRhcnkgRERvUyBkZWZlbnNlcy4NCj4gDQo+ICsgUHJvdG9jb2xzIGFuZCBkYXRh IG1vZGVscyBkZXZlbG9wZWQgYXMgcGFydA0KPiAgICAgIG9mIERPVFMgTVVTVCBiZSBleHRlbnNp YmxlIGluIG9yZGVyIHRvIGtlZXAgRE9UUyBhZGFwdGFibGUgdG8NCj4gICAgICBmdXR1cmUgb3Bl cmF0aW9uYWwgYW5kIHByb3ByaWV0YXJ5IEREb1MgcHJhY3RpY2VzLg0KDQpJIHRoaW5rIOKAnOKA pkREb1MgZGVmZW5zaXZlIHByYWN0aWNlc+KAnSBvciBzb21ldGhpbmcgc2ltaWxhciBlbXBoYXNp emluZyBkZWZlbnNpdmUgbWVhc3VyZXMsIG5vPyBPdGhlcndpc2Ugd2XigJlyZSBjb25mdXNpbmcg dGhlIGRpc2Vhc2Ugd2l0aCB0aGUgY3VyZS4NCg0KDQo+IOKApnNuaXDigKYNCj4gDQo+ICgyOCkg U2VjdGlvbiAyLjEsIEdFTi0wMDMuICBJcyBpdCBhbiAib3BlbiBzaWduYWwgY2hhbm5lbCIgb3Ig YW4gImFjdGl2ZSBzaWduYWwgY2hhbm5lbOKAnT8NCg0KSSB0aGluayDigJxhY3RpdmUiLCB0aGFu a3MgZm9yIHBvaW50aW5nIHRoaXMgb25lIG91dC4NCg0KDQo+IOKApnNuaXAuLi4NCj4gDQo+ICgz MCkgU2VjdGlvbiAyLjIsIFNJRy0wMDMuICBQZXIgIkRPVFMgc2VydmVycyBTSE9VTEQgbW9uaXRv ciB0aGUgYXR0YWNrLCB1c2luZyBmZWVkYmFjayBmcm9tIHRoZSBtaXRpZ2F0b3IgYW5kIG90aGVy IGF2YWlsYWJsZSBzb3VyY2VzLCBhbmQgTUFZIHVzZSB0aGUgYWJzZW5jZSBvZiBhdHRhY2sgdHJh ZmZpYyBhbmQgbGFjayBvZiBjbGllbnQgaGVhcnRiZWF0cyBhcyBhbiBpbmRpY2F0aW9uIHRoZSBz aWduYWwgY2hhbm5lbCBpcyBkZWZ1bmN0LiIsICBJIGhhdmUgc29tZSBjb25jZXJuIHRoYXQgdGhp cyBpcyBhICJTSE9VTEQiLiAgVGhpcyBpbmRpY2F0ZXMgdGhhdCBhIHByb3RvY29sIG1lY2hhbmlz bSBuZWVkcyB0byBiZSBzcGVjaWZpZWQgZm9yIGludGVyYWN0aW5nIHdpdGggdGhlIG1pdGlnYXRv ciAtLSBpc24ndCB0aGF0IG91dCBvZiBzY29wZSBmb3IgRE9UUz8NCg0KWWVzLCBnb29kIHBvaW50 LiBEb2VzIGNoYW5naW5nIGZyb20gU0hPVUxEIHRvIE1BWSBtb25pdG9yIHNlZW0gYWNjZXB0YWJs ZSB0byB0aGUgV0c/DQoNCg0KPiAoMzEpIFNlY3Rpb24gMi4yLCBTSUctMDA0LiAgUGVyICJET1RT IGNsaWVudHMgTUFZIGF0dGVtcHQgYWJicmV2aWF0ZWQgc2VjdXJpdHkgbmVnb3RpYXRpb24gbWV0 aG9kcyBzdXBwb3J0ZWQgYnkgdGhlIHByb3RvY29sLCBzdWNoIGFzIERUTFMgc2Vzc2lvbiByZXN1 bXB0aW9uLCBidXQgTVVTVCBiZSBwcmVwYXJlZCB0byBuZWdvdGlhdGUgbmV3IHNlY3VyaXR5IHN0 YXRlIHdpdGggdGhlIHJlZGlyZWN0aW9uIHRhcmdldCBET1RTIHNlcnZlci4iLCBJIGhhdmUgc29t ZSBjb25jZXJucyB0aGF0IGFiYnJldmlhdGVkIHNlY3VyaXR5IG5lZ290aWF0aW9uIGlzIGEgIk1B WSIgd2l0aG91dCBldmVuIGtub3dpbmcgd2hhdCB0aGUgY2hvc2VuIHByb3RvY29sIG1pZ2h0IGJl IChhbmQgdGhlIGFzc3VtcHRpb24gaW4gdGhlIGFiYnJldmlhdGVkIG5lZ290aWF0aW9uIG9mIHRo aXMgdW5rbm93biBwcm90b2NvbCkuICBJIHJlY29tbWVuZCByZW1vdmluZyBvciBzb2Z0ZW5pbmcg dGhpcyBsYW5ndWFnZS4NCg0KSWYgd2UgcmVtb3ZlIHRoZSBSRkMyMTE5IGxhbmd1YWdlIGFuZCBj aGFuZ2UgdG8g4oCcRE9UUyBjbGllbnRzIGNhbiBhdHRlbXB0IGFiYnJldmlhdGVk4oCm4oCdIChv ciDigJwuLi5hcmUgZnJlZSB0b+KApuKAnSksIGRvZXMgdGhhdCBzb2Z0ZW4gdGhlIGxhbmd1YWdl IHN1ZmZpY2llbnRseT8NCg0KDQo+ICgzMikgU2VjdGlvbiAyLjIsIFNJRy0wMDQuICBFZGl0b3Jp YWwuDQo+IA0KPiAtIER1ZSB0byB0aGUgaW5jcmVhc2VkIGxpa2VsaWhvb2Qgb2YgcGFja2V0IGxv c3MgY2F1c2VkIGJ5IGxpbmsNCj4gICAgICBjb25nZXN0aW9uIGR1cmluZyBhbiBhdHRhY2ssIERP VFMgc2VydmVycyBTSE9VTEQgTk9UIHJlZGlyZWN0DQo+ICAgICAgd2hpbGUgbWl0aWdhdGlvbiBp cyBlbmFibGVkIGR1cmluZyBhbiBhY3RpdmUgYXR0YWNrIGFnYWluc3QgYQ0KPiAgICAgIHRhcmdl dCBpbiB0aGUgRE9UUyBjbGllbnQncyBkb21haW4uDQo+IA0KPiArIER1ZSB0byB0aGUgaW5jcmVh c2VkIGxpa2VsaWhvb2Qgb2YgcGFja2V0IGxvc3MgY2F1c2VkIGJ5IGxpbmsgY29uZ2VzdGlvbiBk dXJpbmcgYW4gYXR0YWNrLCBET1RTIHNlcnZlcnMgU0hPVUxEIE5PVCByZWRpcmVjdCBhY3RpdmUg YXR0YWNrIGFnYWluc3QgYSB0YXJnZXQgaW4gdGhlIERPVFMgY2xpZW50J3MgZG9tYWluIHdoaWxl IGEgbWl0aWdhdGlvbiBpcyBlbmFibGVkLg0KDQpJIGZpbmQgdGhpcyBvbmUgY29uZnVzaW5nLiBB cmUgeW91IGhvcGluZyB0byBlbXBoYXNpemUgdGhlIGltcG9ydGFuY2Ugb2Ygbm90IHJlZGlyZWN0 aW5nIHdoaWxlIGEgbWl0aWdhdGlvbiBpcyBhY3RpdmVseSBmZW5kaW5nIG9mZiBhbiBhdHRhY2s/ IEkgdGhpbmsgdGhhdOKAmXMgYSBwb3RlbnRpYWxseSB1c2VmdWwgcG9pbnQsIHNpbmNlIGFuIGFs d2F5cy1vbiBtaXRpZ2F0aW9uIG1heSBub3QgYWx3YXlzIGJlIGZpbHRlcmluZyBhdHRhY2sgdHJh ZmZpYywgYnV0IEkgZG9u4oCZdCB0aGluayB0aGUgbW9kaWZpY2F0aW9uIGhlbHBzIG1ha2UgdGhh dCBjYXNlLiBNYXliZSBzb21ldGhpbmcgbGlrZSDigJzigKZTSE9VTEQgTk9UIHJlZGlyZWN0IHdo aWxlIGEgbWl0aWdhdGlvbiBpcyBhY3RpdmVseSBmaWx0ZXJpbmcgYXR0YWNrIHRyYWZmaWPigJ0/ DQoNCg0KPiDigKZzbmlwLi4uDQo+IA0KPiAoMzYpIFNlY3Rpb24gMi4yLCBTSUctMDA5LiAgUGVy ICJNdWx0aXBsZSBET1RTIGNsaWVudHMgY29udHJvbGxlZCBieSBhIHNpbmdsZSBhZG1pbmlzdHJh dGl2ZSBlbnRpdHkgbWF5IHNlbmQgY29uZmxpY3RpbmcgbWl0aWdhdGlvbiByZXF1ZXN0cyBmb3Ig cG9vbHMgb2YgcHJvdGVjdGVkIHJlc291cmNlcyAgYXMgYSByZXN1bHQgb2YgbWlzY29uZmlndXJh dGlvbiwgLi4uIiwgd2hhdCBhcmUgInBvb2xzIG9mIHByb3RlY3RlZCByZXNvdXJjZXPigJ0/DQoN CkkgdGhpbmsgd2UgY2FuIHNhZmVseSByZW1vdmUgdGhhdCBwaHJhc2UgYW5kIHJldGFpbiB0aGUg aW50ZW5kZWQgbWVhbmluZy4NCg0KDQo+ICgzNykgU2VjdGlvbiAyLjIsIFNJRy0wMTAuICBQZXIg IlJlZ2FyZGxlc3Mgb2YgdHJhbnNwb3J0LCBET1RTIHByb3RvY29scyBNVVNUIGZvbGxvdyBlc3Rh Ymxpc2hlZCBiZXN0IGNvbW1vbiBwcmFjdGljZXMgKEJDUHMpIGZvciBOQVQgdHJhdmVyc2FsLiIs IHdoaWNoIEJDUHMgdG8gZm9sbG93IGFzIGEgIk1VU1QiIGFyZW4ndCBjbGVhciAodW5sZXNzIHlv dSBqdXN0IG1lYW50IFJGQzgwODU/KS4NCg0KSW5kZWVkLCBqdXN0IFJGQzgwODUuDQoNCg0K From nobody Fri Jan 5 03:58:12 2018 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 4F876127077 for ; Fri, 5 Jan 2018 03:58:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.874 X-Spam-Level: X-Spam-Status: No, score=-5.874 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, HTTP_ESCAPED_HOST=1.125, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_MIME_MALF=0.01, T_RP_MATCHES_RCVD=-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 13nUEMkVETEy for ; Fri, 5 Jan 2018 03:58:08 -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 451A9126D46 for ; Fri, 5 Jan 2018 03:58:08 -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=1515153486; 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:x-microsoft-antispam-message-info: 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=xuGcfg9HUjmu7UebxtO9yu1njWrZUG5pztzS0U nUwOI=; b=J3aJWqfdZ6ymyKDo7gX+WNZjr/isBAi+Ov9Do5zs gJp6KQpL/yIWbN4gODbYjNdrvm66aYLiFBi2D3Zb+PQXSt4QLf ZJsi6ttsCwM2sgZL+4VPQVPlwc9GtFjKQafWhR9Xyl6U3kpJ6u 1FEcZd9zPNZbKCDP2m1wNS/9Cc37ofs= Received: from MIVEXAPP1N03.corpzone.internalzone.com (unknown [10.48.48.90]) by MIVWSMAILOUT1.mcafee.com with smtp (TLS: TLSv1/SSLv3,256bits,ECDHE-RSA-AES256-SHA384) id 772e_14d8_c4ba79c7_ce29_4580_986d_32098bf246ec; Fri, 05 Jan 2018 05:58:06 -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; Fri, 5 Jan 2018 06:57:56 -0500 Received: from MIVEXUSR1N07.corpzone.internalzone.com (10.48.48.87) by MIVEXUSR1N02.corpzone.internalzone.com (10.48.48.82) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Fri, 5 Jan 2018 06:57:55 -0500 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; Fri, 5 Jan 2018 06:57:55 -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; Fri, 5 Jan 2018 06:57:53 -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.386.5; Fri, 5 Jan 2018 11:57: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.0366.011; Fri, 5 Jan 2018 11:57:54 +0000 From: "Konda, Tirumaleswar Reddy" To: Jon Shallow , "dots@ietf.org" Thread-Topic: [Dots] Data Channel POST challenges Thread-Index: AdOFZJIYFWzZLX3YSl+jjYu0kjYH7wACsXzQAACbvAAAJzluwA== Date: Fri, 5 Jan 2018 11:57:53 +0000 Message-ID: References: <0e0201d38564$97046db0$c50d4910$@jpshallow.com> <0e2701d38571$c7699360$563cba20$@jpshallow.com> In-Reply-To: <0e2701d38571$c7699360$563cba20$@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; 7:GTRQ0N2gNCqJMk+0XtzRSRtVa9YLd5belJr8JEOwpg/aEhywabPA6OOn97lHiVUsoIV9xCUS/A3h+e7ZMR/H2Mp2FFGc5Nv3jBcd04xPiPO2BofSU9M789X5+llBXk9bbJ1mjW+LjUPhqVwYo7kmXO1Xu1erIuiae2AvbFOKLpZsbz5ukk55gVGcUYiKUwCNPz0Xw2v2gtVsZHMWDAbCoNWYWg3IdON6k1kgF0RqU66HNcR/PN42Hj2VA3ZAG2NL x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 70f68a64-f92b-4630-9684-08d554338dcd x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(5600026)(4604075)(3008032)(2017052603307)(7153060); SRVR:DM5PR16MB1787; x-ms-traffictypediagnostic: DM5PR16MB1787: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(21748063052155)(123452027830198); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040470)(2401047)(5005006)(8121501046)(93006095)(93001095)(10201501046)(3002001)(3231023)(944501075)(6041268)(20161123558120)(20161123564045)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123562045)(6072148)(201708071742011); SRVR:DM5PR16MB1787; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:DM5PR16MB1787; x-forefront-prvs: 05437568AA x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39860400002)(366004)(346002)(39380400002)(376002)(396003)(32952001)(199004)(189003)(68736007)(2501003)(81156014)(14454004)(2900100001)(966005)(229853002)(9326002)(2906002)(7696005)(81166006)(8676002)(8936002)(97736004)(76176011)(80792005)(2950100002)(66066001)(25786009)(74316002)(3280700002)(102836004)(33656002)(478600001)(6246003)(72206003)(3660700001)(59450400001)(7736002)(53546011)(6506007)(316002)(236005)(86362001)(6116002)(3846002)(9686003)(790700001)(54896002)(6306002)(5660300001)(19609705001)(105586002)(106356001)(110136005)(53936002)(606006)(6436002)(99286004)(77096006)(55016002)(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) x-microsoft-antispam-message-info: fVYf8gQyiqE+I2seQ/A/FBfVSpgVHtrQ1GpwZ725HgP1Nolmi0HRoI9DTZY4wP3itmLv1/e6stQCQVQcfRUJ7g== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_DM5PR16MB17883B21D4F2101F61F848C6EA1C0DM5PR16MB1788namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 70f68a64-f92b-4630-9684-08d554338dcd X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Jan 2018 11:57:53.9106 (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 <6193> : inlines <6295> : streams <1775171> : uri <2563620> Archived-At: Subject: Re: [Dots] Data Channel POST challenges 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, 05 Jan 2018 11:58:11 -0000 --_000_DM5PR16MB17883B21D4F2101F61F848C6EA1C0DM5PR16MB1788namp_ 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: Thursday, January 4, 2018 9:06 PM To: Konda, Tirumaleswar Reddy ; dots@ie= tf.org Subject: RE: [Dots] Data Channel POST challenges Hi Tiru, See inline Regards Jon From: Dots [mailto: dots-bounces@ietf.org] On= Behalf Of Konda, Tirumaleswar Reddy Sent: 04 January 2018 15:20 To: Jon Shallow; dots@ietf.org Subject: Re: [Dots] Data Channel POST challenges Hi Jon, Please see inline From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Jon Shallow Sent: Thursday, January 4, 2018 7:32 PM To: dots@ietf.org Subject: [Dots] Data Channel POST challenges Hi there, With the merge of aliases and filters into a common YANG data model, I thin= k the POST examples are now incorrect in the data channel draft, but still = am challenged as to what to actually use. My understanding is below, but o= pen to correction. [I also think identifier should be renamed to something like aliases to be = more meaningful - to contrast access-lists] E.g. 6.1. Create Identifiers POST /restconf/data/ietf-dots-data-channel HTTP/1.1 Host: {host}:{port} Content-Type: application/yang-data+json { "ietf-dots-data-channel:identifier": { "client-identifier": [ "string" ], "alias": [ { "alias-name": "string", Should read [RFC8040 4.4.1. Create Resource Mode] as we are defining where = we want to put the resource POST /restconf/data HTTP/1.1 Host: {host}:{port} Content-Type: application/yang-data+json { "ietf-dots-data-channel:identifier": { "client-identifier": [ "string" ], "alias": [ { "alias-name": "string", And the returned Location: header would contain "https://{host}:{port}/rest= conf/data/ietf-dots-data-channel:identifier" [TR] The above examples you provided do not look correct, please see https:= //tools.ietf.org/html/rfc8040#appendix-B.2.1 [Jon] The above example is for the complete replacement of the data contain= er (B.2.4), or first addition of an entry (POST 4.4.1) (i.e. working with a= datastore resource) that defines everything, the below last 2 examples are= in-line with B.2.1 (creating a data resource within a data resource) as I = read the RFC. [TR2] I meant if the above example is only supposed to create a new "identi= fier" resource then the request body should not carry client-identifier and= alias parameters (just like the "jukebox" example given in Section 4.4.1). -Tiru NOTE: [RFC8040 4.4.1. Create Resource Mode] "If the data resource already = exists, then the POST request MUST fail and a "409 Conflict" status-line MUST be returned." This means to me that we can only create one alias set using POST when the = resource is /restconf/data, and if we want to update the alias set at /rest= conf/data, we must do a DELETE followed by another POST, or use PUT. The PUT equivalent would be (I think) for creating or completing replacing = the complete list of aliases [RFC8040 4.5. PUT] PUT /restconf/data HTTP/1.1 Host: {host}:{port} Content-Type: application/yang-data+json { "ietf-dots-data-channel:identifier": { "client-identifier": [ "string" ], "alias": [ { "alias-name": "string", Or to create / update a new alias-name (but what happens to client-identifi= er ? I think it is put in the path) - "string" in the URI will contain the= actual value without quotes POST /restconf/data/ietf-dots-data-channel:identifier/client-identifier= =3D"string" HTTP/1.1 Host: {host}:{port} Content-Type: application/yang-data+json { "ietf-dots-data-channel:alias": [ { "alias-name": "string", Or ("string" replaced in URI as appropriate) PUT /restconf/data/ietf-dots-data-channel:identifier/client-identifier= =3D"string"/alias=3D"string" HTTP/1.1 Host: {host}:{port} Content-Type: application/yang-data+json { "ietf-dots-data-channel:alias": [ { "alias-name": "string", The same thing is needed for the access-lists, but also need to consider "i= nsert" and "point". Comments / help needed! Regards Jon --_000_DM5PR16MB17883B21D4F2101F61F848C6EA1C0DM5PR16MB1788namp_ 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: Thursday, January 4, 2018 9:06 PM
To: Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@McAfee.com= >; dots@ietf.org
Subject: RE: [Dots] Data Channel POST challenges

 

Hi Tiru= ,

&n= bsp;

See inl= ine

&n= bsp;

Regards=

&n= bsp;

Jon

&n= bsp;

From: Dots [mailto: dots-bounces@ietf.org] On B= ehalf Of Konda, Tirumaleswar Reddy
Sent: 04 January 2018 15:20
To: Jon Shallow; dots@ietf.org<= br> Subject: Re: [Dots] Data Channel POST challenges

 

Hi Jon,

&nbs= p;

Please se= e inline

&nbs= p;

From:<= /span> Dots [mailto:dots-bounces@ietf.org] On Behalf Of Jon Shallow
Sent: Thursday, January 4, 2018 7:32 PM
To: dots@ietf.org
Subject: [Dots] Data Channel POST challenges

 

Hi there,

 

With the merge of aliases and f= ilters into a common YANG data model, I think the POST examples are now inc= orrect in the data channel draft, but still am challenged as to what to act= ually use.  My understanding is below, but open to correction.

 

[I also think identifier should= be renamed to something like aliases to be more meaningful – to cont= rast access-lists]

 

E.g. 6.1. Create Identifiers

 

    POST /restco= nf/data/ietf-dots-data-channel HTTP/1.1

    Host: {host}= :{port}

    Content-Type= : application/yang-data+json

    {=

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

     &= nbsp; "client-identifier": [

     &= nbsp;      "string"

      =  ],

     &= nbsp; "alias": [

     &= nbsp;   {

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

 

 

Should read [RFC8040 4.4.1. Cre= ate Resource Mode] as we are defining where we want to put the resource

 

    POST /restco= nf/data HTTP/1.1

    Host: {host}= :{port}

    Content-Type= : application/yang-data+json

    {=

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

     &= nbsp; "client-identifier": [

     &= nbsp;      "string"

      =  ],

     &= nbsp; "alias": [

     &= nbsp;   {

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

 

And the returned Location: head= er would contain “https://{host}:{port}/restconf/data/= ietf-dots-data-channel:identifier”

 

[TR] The above examples you pro= vided do not look correct, please see https://tool= s.ietf.org/html/rfc8040#appendix-B.2.1

&n= bsp;

[Jon] T= he above example is for the complete replacement of the data container (B.2= .4), or first addition of an entry (POST 4.4.1) (i.e. working with a datast= ore resource) that defines everything, the below last 2 examples are in-line with B.2.1 (creating a data resource= within a data resource) as I read the RFC.

 

[TR2] I meant if the above exam= ple is only supposed to create a new “identifier” resource then= the request body should not carry client-identifier and alias parameters (= just like the “jukebox” example given in Section 4.4.1).

 

-Tiru

 

NOTE:  [RFC8040 4.4.1. Cre= ate Resource Mode] “If the data resource already exists, then the POS= T request MUST fail

   and a "409 Co= nflict" status-line MUST be returned.”

 

This means to me that we can on= ly create one alias set using POST when the resource is /restconf/data, and= if we want to update the alias set at /restconf/data, we must do a DELETE = followed by another POST, or use PUT.

 

The PUT equivalent would be (I = think) for creating or completing replacing the complete list of aliases [R= FC8040 4.5. PUT]

 

    PUT /restcon= f/data HTTP/1.1

    Host: {host}= :{port}

    Content-Type= : application/yang-data+json

    {=

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

     &= nbsp; "client-identifier": [

     &= nbsp;      "string"

      =  ],

     &= nbsp; "alias": [

     &= nbsp;   {

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

 

Or to create / update a new ali= as-name (but what happens to client-identifier ?  I think it is put in= the path) – “string” in the URI will contain the actual = value without quotes

 

    POST /restco= nf/data/ietf-dots-data-channel:identifier/client-identifier=3D”string= ” HTTP/1.1

    Host: {host}= :{port}

    Content-Type= : application/yang-data+json

    {=

     &= nbsp; "ietf-dots-data-channel:alias": [

     &= nbsp;   {

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

 

Or (“string” replac= ed in URI as appropriate)

 

    PUT /restcon= f/data/ietf-dots-data-channel:identifier/client-identifier=3D”string&= #8221;/alias=3D”string” HTTP/1.1

    Host: {host}= :{port}

    Content-Type= : application/yang-data+json

    {=

     &= nbsp; "ietf-dots-data-channel:alias": [

     &= nbsp;   {

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

 

 

The same thing is needed for th= e access-lists, but also need to consider “insert” and “p= oint”.

 

Comments / help needed!

 

Regards

 

Jon

--_000_DM5PR16MB17883B21D4F2101F61F848C6EA1C0DM5PR16MB1788namp_-- From nobody Fri Jan 5 09:31:07 2018 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 CBDF9127871 for ; Fri, 5 Jan 2018 09:31:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, URIBL_BLOCKED=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 b2pW6qFjm6T7 for ; Fri, 5 Jan 2018 09:31:03 -0800 (PST) Received: from taper.sei.cmu.edu (taper.sei.cmu.edu [147.72.252.16]) (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 9707512708C for ; Fri, 5 Jan 2018 09:31:03 -0800 (PST) Received: from korb.sei.cmu.edu (korb.sei.cmu.edu [10.64.21.30]) by taper.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id w05HUwsR021755; Fri, 5 Jan 2018 12:30:58 -0500 DKIM-Filter: OpenDKIM Filter v2.11.0 taper.sei.cmu.edu w05HUwsR021755 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cert.org; s=yc2bmwvrj62m; t=1515173459; bh=L0YyQeJMmYgTeye7zkvRvFpg2nyqEJF7EqXdfNqHxYg=; h=From:To:CC:Subject:Date:References:In-Reply-To:From; b=eZk6i8XgLdrge34QeyMeO6CIRO/fi4aetoRH/+tUHBMSWrVbFBgd9NeVEFKGmtkCM vvkkCPKmVX/hcj5MxXbFPVcldk/+0CTJxhdaTsqs2Q6lNb/KAKMWuDYPBSjTy1gyKp aHQ8CUqvLqiWvqDPf+G6NIQkG9u4okcHfb79h5k4= 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 w05HUtuq022394; Fri, 5 Jan 2018 12:30:55 -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; Fri, 5 Jan 2018 12:30:55 -0500 From: Roman Danyliw To: "Mortensen, Andrew" CC: "dots@ietf.org" Thread-Topic: [Dots] Feedback on draft-ietf-dots-requirements Thread-Index: AdOE4a/XR+KnbzsFQl+L7JY1uUa37wAsM4yAAC26MBA= Date: Fri, 5 Jan 2018 17:30:55 +0000 Message-ID: <359EC4B99E040048A7131E0F4E113AFC0131358FB1@marathon> References: <359EC4B99E040048A7131E0F4E113AFC0131356BB5@marathon> <59B81C16-86E7-4EAF-8AEB-CFDF53A5E11E@arbor.net> In-Reply-To: <59B81C16-86E7-4EAF-8AEB-CFDF53A5E11E@arbor.net> 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="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [Dots] Feedback on draft-ietf-dots-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: Fri, 05 Jan 2018 17:31:06 -0000 SGkgQW5kcmV3IQ0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IE1vcnRl bnNlbiwgQW5kcmV3IFttYWlsdG86YW1vcnRlbnNlbkBhcmJvci5uZXRdDQo+IFNlbnQ6IFRodXJz ZGF5LCBKYW51YXJ5IDA0LCAyMDE4IDI6MzEgUE0NCj4gVG86IFJvbWFuIERhbnlsaXcgPHJkZEBj ZXJ0Lm9yZz4NCj4gQ2M6IGRvdHNAaWV0Zi5vcmcNCj4gU3ViamVjdDogUmU6IFtEb3RzXSBGZWVk YmFjayBvbiBkcmFmdC1pZXRmLWRvdHMtcmVxdWlyZW1lbnRzDQo+IA0KPiBUaGFua3MgZm9yIHRo ZSB2ZXJ5IGNsb3NlIHJlYWRpbmcsIFJvbWFuLiBJbiBnZW5lcmFsIHRoZSBlZGl0b3JpYWwgY2hh bmdlcw0KPiBsb29rIGZpbmUuIEEgZmV3IGNvbW1lbnRzIGFuZCBxdWVzdGlvbnMgaW5saW5lIGJl bG93Lg0KPiANCj4gYW5kcmV3DQo+IA0KPiANCj4gPiBPbiBKYW4gMywgMjAxOCwgYXQgNTozMiBQ TSwgUm9tYW4gRGFueWxpdyA8cmRkQGNlcnQub3JnPiB3cm90ZToNCj4gPg0KPiA+IEhlbGxvIQ0K PiA+IChjaGFpciBoYXQgb2ZmKQ0KPiA+DQo+ID4gVGhlIGZvbGxvd2luZyBpcyBmZWVkYmFjayBm b3IgdGhlIFdHTEMgb24gLTA5IG9mIGRyYWZ0LWlldGYtZG90cy0NCj4gcmVxdWlyZW1lbnRzLiAg RXZlbiB3aXRoIHRoZSAtMTAgdXBkYXRlLCB0aGVzZSBzaG91bGQgYXBwbHkuICBPdGhlciB0aGFu IHRoZQ0KPiBmZWVkYmFjayBiZWxvdywgSSBiZWxpZXZlIHRoZSBkcmFmdCBpcyByZWFkeSB0byBw cm9jZWVkLg0KPiA+DQo+ID4gKDEpIEFic3RyYWN0LiAgRWRpdG9yaWFsLg0KPiA+DQo+ID4gLSAi VGhpcyBkb2N1bWVudCBkZWZpbmVzIHRoZSByZXF1aXJlbWVudHMgZm9yIHRoZSBEaXN0cmlidXRl ZCBEZW5pYWwgb2YNCj4gU2VydmljZSAoRERvUykgT3BlbiBUaHJlYXQgU2lnbmFsaW5nIChET1RT KSBwcm90b2NvbHMgY29vcmRpbmF0aW5nIGF0dGFjaw0KPiByZXNwb25zZSBhZ2FpbnN0IEREb1Mg YXR0YWNrcy4iDQo+ID4gKyAiVGhpcyBkb2N1bWVudCBkZWZpbmVzIHRoZSByZXF1aXJlbWVudHMg Zm9yIHRoZSBEaXN0cmlidXRlZCBEZW5pYWwgb2YNCj4gU2VydmljZSAoRERvUykgT3BlbiBUaHJl YXQgU2lnbmFsaW5nIChET1RTKSBwcm90b2NvbHMgdGhhdCBlbmFibGUgdGhlDQo+IGNvb3JkaW5h dGlvbiBvZiBhbmQgIHJlc3BvbnNlIHRvIEREb1MgYXR0YWNrcy7igJ0NCj4gDQo+IEkgdGhpbmsg d2UganVzdCB3YW50IOKAnOKApmVuYWJsZSBjb29yZGluYXRpb24gb2YgcmVzcG9uc2UgdG/igKbi gJ0sIHNpbmNlIHdl4oCZcmUNCj4gb3RoZXJ3aXNlIGxlZnQgd2l0aCDigJzigKZjb29yZGluYXRp b24gb2bigKZERG9TIGF0dGFja3PigJ0sIHdoaWNoIGlzIGNsZWFybHkgbm90IHRoZQ0KPiBtZWFu aW5nIHdl4oCZcmUgc2hvb3RpbmcgZm9yLg0KDQpPSy4gIEkgdW5kZXJzdGFuZCBub3cuDQogDQo+ ID4g4oCmc25pcC4uLg0KPiA+DQo+ID4gKDkpIFNlY3Rpb24gMS4yLCBUZXJtaW5vbG9neSwgTWl0 aWdhdG9yLiBFZGl0b3JpYWwgKGNsYXJpdHkpDQo+ID4NCj4gPiAtIC4uLiAgRm9yDQo+ID4gICAg ICB0aGUgcHVycG9zZXMgb2YgdGhpcyBkb2N1bWVudCwgdGhpcyBlbnRpdHkgaXMgYSBibGFjayBi b3ggY2FwYWJsZQ0KPiA+ICAgICAgb2YgbWl0aWdhdGlvbiwgbWFraW5nIG5vIGFzc3VtcHRpb25z IGFib3V0IGF2YWlsYWJpbGl0eSBvciBkZXNpZ24NCj4gPiAgICAgIG9mIGNvdW50ZXJtZWFzdXJl cywgbm9yIGFib3V0IHRoZSBwcm9ncmFtbWFibGUgaW50ZXJmYWNlKHMpDQo+ID4gICAgICBiZXR3 ZWVuIHRoaXMgZW50aXR5IGFuZCBvdGhlciBuZXR3b3JrIGVsZW1lbnRzLg0KPiA+DQo+ID4gKyBU aGUgbWVhbnMgYnkgd2hpY2ggdGhpcyBlbnRpdHkgcGVyZm9ybXMgdGhlc2UgbWl0aWdhdGlvbnMg YW5kIGhvdyB0aGV5DQo+IGFyZSByZXF1ZXN0ZWQgb2YgaXQgYXJlIG91dCBvZiBzY29wZS4NCj4g DQo+IE1heWJlIOKAnOKApmhvdyB0aGV5IGFyZSBjb25maWd1cmVkIGFuZCBtYW5hZ2VkIFtvciBt YWludGFpbmVkXeKApuKAnSBpbnN0ZWFkPw0KPiBUaGUgdGVybSDigJxtaXRpZ2F0aW9uIHJlcXVl c3TigJ0gaGFzIGEgdmVyeSBzcGVjaWZpYyBtZWFuaW5nIGluIERPVFMuDQoNCk9LLiAgVGhpcyBw cm9wb3NlZCB0ZXh0IHdvcmtzIGZvciBtZS4NCg0KPiA+IOKApnNuaXAuLi4NCj4gPg0KPiA+ICgx MikgU2VjdGlvbiAxLjIsIFRlcm1pbm9sb2d5LCBET1RTIHNlcnZlci4gIEluIHRoZSBzZW50ZW5j ZSwgIiBBIERPVFMNCj4gc2VydmVyIG1heSBhbHNvIGJlIGNvbG9jYXRlZCAgd2l0aCBhIG1pdGln YXRvciIsIHdoYXQgZG9lcyAiY29sbG9jYXRlZCIgbWVhbg0KPiBpbiB0aGlzIGNvbnRleHQ/DQo+ IA0KPiBUaGUgb3JpZ2luYWwgY29uY2x1ZGluZyBzZW50ZW5jZSB3YXMg4oCcQSBET1RTIHNlcnZl ciBNQVkgYWxzbyBiZSBhDQo+IG1pdGlnYXRvcuKAnSAod2l0aCB1bm5lY2Vzc2FyeSBSRkMgMjEx OSB0ZXJtKS4gQWZ0ZXIgdGhpbmtpbmcgYWJvdXQgaXQgYSBiaXQsIEnigJltDQo+IG5vdCBzdXJl IHRoYXQgZWl0aGVyIHRoZSBjdXJyZW50IHBocmFzaW5nIG9yIHRoZSBvcmlnaW5hbCBhcmUgbmVj ZXNzYXJ5IHRvIHRoZQ0KPiBkcmFmdC4gRG9lcyBhbnlvbmUgb2JqZWN0IHRvIHJlbW92aW5nIGl0 Pw0KDQpJIGVuZG9yc2UgcmVtb3ZpbmcgdGhlIHRleHQuDQogDQo+ID4g4oCmc25pcOKApg0KPiA+ DQo+ID4gKDI1KSBTZWN0aW9uIDIuMSwgR0VOLTAwMS4gIEVkaXRvcmlhbC4NCj4gPg0KPiA+IC0g UHJvdG9jb2xzIGFuZCBkYXRhIG1vZGVscyBkZXZlbG9wZWQgYXMgcGFydA0KPiA+ICAgICAgb2Yg RE9UUyBNVVNUIGJlIGV4dGVuc2libGUgaW4gb3JkZXIgdG8ga2VlcCBET1RTIGFkYXB0YWJsZSB0 bw0KPiA+ICAgICAgZnV0dXJlIG9wZXJhdGlvbmFsIGFuZCBwcm9wcmlldGFyeSBERG9TIGRlZmVu c2VzLg0KPiA+DQo+ID4gKyBQcm90b2NvbHMgYW5kIGRhdGEgbW9kZWxzIGRldmVsb3BlZCBhcyBw YXJ0DQo+ID4gICAgICBvZiBET1RTIE1VU1QgYmUgZXh0ZW5zaWJsZSBpbiBvcmRlciB0byBrZWVw IERPVFMgYWRhcHRhYmxlIHRvDQo+ID4gICAgICBmdXR1cmUgb3BlcmF0aW9uYWwgYW5kIHByb3By aWV0YXJ5IEREb1MgcHJhY3RpY2VzLg0KPiANCj4gSSB0aGluayDigJzigKZERG9TIGRlZmVuc2l2 ZSBwcmFjdGljZXPigJ0gb3Igc29tZXRoaW5nIHNpbWlsYXIgZW1waGFzaXppbmcNCj4gZGVmZW5z aXZlIG1lYXN1cmVzLCBubz8gT3RoZXJ3aXNlIHdl4oCZcmUgY29uZnVzaW5nIHRoZSBkaXNlYXNl IHdpdGggdGhlDQo+IGN1cmUuDQoNClRoaXMgd2FzIHZlcnkgc3R5bGUtc3BlY2lmaWMgZmVlZGJh Y2suICBPbiByZWZsZWN0aW9uLCBqdXN0IGtlZXAgdGhlIG9yaWdpbmFsIHRleHQuICANCiANCj4g PiDigKZzbmlw4oCmDQo+ID4gKDMwKSBTZWN0aW9uIDIuMiwgU0lHLTAwMy4gIFBlciAiRE9UUyBz ZXJ2ZXJzIFNIT1VMRCBtb25pdG9yIHRoZSBhdHRhY2ssDQo+IHVzaW5nIGZlZWRiYWNrIGZyb20g dGhlIG1pdGlnYXRvciBhbmQgb3RoZXIgYXZhaWxhYmxlIHNvdXJjZXMsIGFuZCBNQVkgdXNlDQo+ IHRoZSBhYnNlbmNlIG9mIGF0dGFjayB0cmFmZmljIGFuZCBsYWNrIG9mIGNsaWVudCBoZWFydGJl YXRzIGFzIGFuIGluZGljYXRpb24gdGhlDQo+IHNpZ25hbCBjaGFubmVsIGlzIGRlZnVuY3QuIiwg IEkgaGF2ZSBzb21lIGNvbmNlcm4gdGhhdCB0aGlzIGlzIGEgIlNIT1VMRCIuICBUaGlzDQo+IGlu ZGljYXRlcyB0aGF0IGEgcHJvdG9jb2wgbWVjaGFuaXNtIG5lZWRzIHRvIGJlIHNwZWNpZmllZCBm b3IgaW50ZXJhY3RpbmcNCj4gd2l0aCB0aGUgbWl0aWdhdG9yIC0tIGlzbid0IHRoYXQgb3V0IG9m IHNjb3BlIGZvciBET1RTPw0KPiANCj4gWWVzLCBnb29kIHBvaW50LiBEb2VzIGNoYW5naW5nIGZy b20gU0hPVUxEIHRvIE1BWSBtb25pdG9yIHNlZW0NCj4gYWNjZXB0YWJsZSB0byB0aGUgV0c/DQoN CkknZCBwcm9wb3NlIHNvbWV0aGluZyB3ZWFrZXIgbGlrZSAiY291bGQiIChubyBSRkMyMTE5IGxh bmd1YWdlKSB0byBrZWVwIHRoZSBib3VuZGFyaWVzIGNsZWFyLiAgSSdtIGludGVyZXN0ZWQgdG8g aGVhciBob3cgb3RoZXIgZmVlbC4NCg0KID4gPiAoMzEpIFNlY3Rpb24gMi4yLCBTSUctMDA0LiAg UGVyICJET1RTIGNsaWVudHMgTUFZIGF0dGVtcHQgYWJicmV2aWF0ZWQNCj4gc2VjdXJpdHkgbmVn b3RpYXRpb24gbWV0aG9kcyBzdXBwb3J0ZWQgYnkgdGhlIHByb3RvY29sLCBzdWNoIGFzIERUTFMN Cj4gc2Vzc2lvbiByZXN1bXB0aW9uLCBidXQgTVVTVCBiZSBwcmVwYXJlZCB0byBuZWdvdGlhdGUg bmV3IHNlY3VyaXR5IHN0YXRlDQo+IHdpdGggdGhlIHJlZGlyZWN0aW9uIHRhcmdldCBET1RTIHNl cnZlci4iLCBJIGhhdmUgc29tZSBjb25jZXJucyB0aGF0DQo+IGFiYnJldmlhdGVkIHNlY3VyaXR5 IG5lZ290aWF0aW9uIGlzIGEgIk1BWSIgd2l0aG91dCBldmVuIGtub3dpbmcgd2hhdCB0aGUNCj4g Y2hvc2VuIHByb3RvY29sIG1pZ2h0IGJlIChhbmQgdGhlIGFzc3VtcHRpb24gaW4gdGhlIGFiYnJl dmlhdGVkDQo+IG5lZ290aWF0aW9uIG9mIHRoaXMgdW5rbm93biBwcm90b2NvbCkuICBJIHJlY29t bWVuZCByZW1vdmluZyBvciBzb2Z0ZW5pbmcNCj4gdGhpcyBsYW5ndWFnZS4NCj4gDQo+IElmIHdl IHJlbW92ZSB0aGUgUkZDMjExOSBsYW5ndWFnZSBhbmQgY2hhbmdlIHRvIOKAnERPVFMgY2xpZW50 cyBjYW4gYXR0ZW1wdA0KPiBhYmJyZXZpYXRlZOKApuKAnSAob3Ig4oCcLi4uYXJlIGZyZWUgdG/i gKbigJ0pLCBkb2VzIHRoYXQgc29mdGVuIHRoZSBsYW5ndWFnZQ0KPiBzdWZmaWNpZW50bHk/DQoN Clllcy4gIEkgbGlrZSB5b3VyIHByb3Bvc2VkIHNvZnRlciBsYW5ndWFnZS4NCg0KPiA+ICgzMikg U2VjdGlvbiAyLjIsIFNJRy0wMDQuICBFZGl0b3JpYWwuDQo+ID4NCj4gPiAtIER1ZSB0byB0aGUg aW5jcmVhc2VkIGxpa2VsaWhvb2Qgb2YgcGFja2V0IGxvc3MgY2F1c2VkIGJ5IGxpbmsNCj4gPiAg ICAgIGNvbmdlc3Rpb24gZHVyaW5nIGFuIGF0dGFjaywgRE9UUyBzZXJ2ZXJzIFNIT1VMRCBOT1Qg cmVkaXJlY3QNCj4gPiAgICAgIHdoaWxlIG1pdGlnYXRpb24gaXMgZW5hYmxlZCBkdXJpbmcgYW4g YWN0aXZlIGF0dGFjayBhZ2FpbnN0IGENCj4gPiAgICAgIHRhcmdldCBpbiB0aGUgRE9UUyBjbGll bnQncyBkb21haW4uDQo+ID4NCj4gPiArIER1ZSB0byB0aGUgaW5jcmVhc2VkIGxpa2VsaWhvb2Qg b2YgcGFja2V0IGxvc3MgY2F1c2VkIGJ5IGxpbmsgY29uZ2VzdGlvbg0KPiBkdXJpbmcgYW4gYXR0 YWNrLCBET1RTIHNlcnZlcnMgU0hPVUxEIE5PVCByZWRpcmVjdCBhY3RpdmUgYXR0YWNrIGFnYWlu c3QgYQ0KPiB0YXJnZXQgaW4gdGhlIERPVFMgY2xpZW50J3MgZG9tYWluIHdoaWxlIGEgbWl0aWdh dGlvbiBpcyBlbmFibGVkLg0KPiANCj4gSSBmaW5kIHRoaXMgb25lIGNvbmZ1c2luZy4gQXJlIHlv dSBob3BpbmcgdG8gZW1waGFzaXplIHRoZSBpbXBvcnRhbmNlIG9mIG5vdA0KPiByZWRpcmVjdGlu ZyB3aGlsZSBhIG1pdGlnYXRpb24gaXMgYWN0aXZlbHkgZmVuZGluZyBvZmYgYW4gYXR0YWNrPyBJ IHRoaW5rIHRoYXTigJlzIGENCj4gcG90ZW50aWFsbHkgdXNlZnVsIHBvaW50LCBzaW5jZSBhbiBh bHdheXMtb24gbWl0aWdhdGlvbiBtYXkgbm90IGFsd2F5cyBiZQ0KPiBmaWx0ZXJpbmcgYXR0YWNr IHRyYWZmaWMsIGJ1dCBJIGRvbuKAmXQgdGhpbmsgdGhlIG1vZGlmaWNhdGlvbiBoZWxwcyBtYWtl IHRoYXQgY2FzZS4NCj4gTWF5YmUgc29tZXRoaW5nIGxpa2Ug4oCc4oCmU0hPVUxEIE5PVCByZWRp cmVjdCB3aGlsZSBhIG1pdGlnYXRpb24gaXMgYWN0aXZlbHkNCj4gZmlsdGVyaW5nIGF0dGFjayB0 cmFmZmlj4oCdPw0KDQpPb3BzLiAgSSB0cmFuc3Bvc2VkIHdvcmRzIGluIG15IHN1Z2dlc3Rpb24u ICBJIG1lYW50IHRvIHNheToNCg0KIkR1ZSB0byB0aGUgaW5jcmVhc2VkIGxpa2VsaWhvb2Qgb2Yg cGFja2V0IGxvc3MgY2F1c2VkIGJ5IGxpbmsgY29uZ2VzdGlvbiBkdXJpbmcgYW4gYXR0YWNrLCBE T1RTIHNlcnZlcnMgU0hPVUxEIE5PVCByZWRpcmVjdCBkdXJpbmcgYW4gYWN0aXZlIGF0dGFjayBh Z2FpbnN0IGEgdGFyZ2V0IGluIHRoZSBET1RTIGNsaWVudCdzIGRvbWFpbiB3aGlsZSBhIG1pdGln YXRpb24gaXMgZW5hYmxlZC4iDQoNClRoaXMgd2FzIHZlcnkgc3R5bGUtc3BlY2lmaWMgZmVlZGJh Y2suICBPbiByZWZsZWN0aW9uLCBqdXN0IGtlZXAgdGhlIG9yaWdpbmFsIHRleHQNCg0KUm9tYW4N Cg== From nobody Fri Jan 5 09:59:04 2018 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 52E96126D3F for ; Fri, 5 Jan 2018 09:59:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, URIBL_BLOCKED=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 c6QZn2ld-F7I for ; Fri, 5 Jan 2018 09:59:01 -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 B9BE5126BFD for ; Fri, 5 Jan 2018 09:59:01 -0800 (PST) Received: from delp.sei.cmu.edu (delp.sei.cmu.edu [10.64.21.31]) by veto.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id w05Hx0jr024672 for ; Fri, 5 Jan 2018 12:59:00 -0500 DKIM-Filter: OpenDKIM Filter v2.11.0 veto.sei.cmu.edu w05Hx0jr024672 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cert.org; s=yc2bmwvrj62m; t=1515175140; bh=AhCT6UxVBKAPYeRNBDq0CRBZKSFVvG9AJXK4/rkZxJU=; h=From:To:Subject:Date:From; b=jDj856PNgsTvg0+zNEZpUwn1wrDwzDawT59QFtREa3qsw7IB/w0EaQBYkiByzvQSZ UW9aY/8Ghs3uTQ2M59CdCIhh8XggDUqkrgS8Ih4FwjXwv1XnSOyGTJ/mrzZ3S6uwMq wdDtNnwhF34zD1POU014eE0Tq4ABgta6TVWz6fTI= Received: from CASSINA.ad.sei.cmu.edu (cassina.ad.sei.cmu.edu [10.64.28.249]) by delp.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id w05Hwx8W022759 for ; Fri, 5 Jan 2018 12:58:59 -0500 Received: from MARATHON.ad.sei.cmu.edu ([10.64.28.250]) by CASSINA.ad.sei.cmu.edu ([10.64.28.249]) with mapi id 14.03.0361.001; Fri, 5 Jan 2018 12:58:59 -0500 From: Roman Danyliw To: "dots@ietf.org" Thread-Topic: February 2018 Virtual Interim Meeting Scheduling Poll Thread-Index: AdOGSzD/y9k3QC9STDe4AWWsTpWbuA== Date: Fri, 5 Jan 2018 17:58:59 +0000 Message-ID: <359EC4B99E040048A7131E0F4E113AFC0131359016@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] February 2018 Virtual Interim Meeting Scheduling Poll 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, 05 Jan 2018 17:59:03 -0000 Hello WG! We're approaching the half-way point between the Singapore and upcoming Lon= don meeting and would benefit from synchronizing with a virtual interim mee= ting. The proposed agenda would be a subset of the following: ** Implementation feedback ** Signal and Data channel drafts ** Hackathon participation Help suggest the best day to virtually meet during the week of February 5th= , 2018 by completing a Doodle poll -- https://doodle.com/poll/3pfpzvn3sdqk6= 4ai. Your input would be appreciated by Friday, January 12, 2018 and results wil= l be announced on Saturday, January 13, 2018. Regards, Roman From nobody Mon Jan 8 00:29:56 2018 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 16787124234 for ; Mon, 8 Jan 2018 00:29:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.63 X-Spam-Level: X-Spam-Status: No, score=-2.63 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 AztYQlqt4r_9 for ; Mon, 8 Jan 2018 00:29:51 -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 D4C32126DFF for ; Mon, 8 Jan 2018 00:29:50 -0800 (PST) Received: from opfedar07.francetelecom.fr (unknown [xx.xx.xx.9]) by opfedar23.francetelecom.fr (ESMTP service) with ESMTP id 8545D160771; Mon, 8 Jan 2018 09:29:49 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.33]) by opfedar07.francetelecom.fr (ESMTP service) with ESMTP id 5F892C0068; Mon, 8 Jan 2018 09:29:49 +0100 (CET) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM42.corporate.adroot.infra.ftgroup ([fe80::d5fd:9c7d:2ee3:39d9%19]) with mapi id 14.03.0361.001; Mon, 8 Jan 2018 09:29:49 +0100 From: To: Jon Shallow , "dots@ietf.org" Thread-Topic: [Dots] I-D Action: draft-ietf-dots-signal-channel-14.txt Thread-Index: AQDAx+IWe1SBtvp2XUqJiA0/nltgOwDl0/WwAY8iFjgA0Y+5z6VZK6oggBvDSnA= Date: Mon, 8 Jan 2018 08:29:48 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93300A0AD168@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <151369676873.7503.16975686179952810632@ietfa.amsl.com> <787AE7BB302AE849A7480A190F8B93300A09ADFB@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <05e001d37a64$bec4c080$3c4e4180$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93300A09C160@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <061e01d37a7b$9cb303a0$d6190ae0$@jpshallow.com> In-Reply-To: <061e01d37a7b$9cb303a0$d6190ae0$@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.2] 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-14.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, 08 Jan 2018 08:29:54 -0000 Hi Jon, all, Apologies for the delay to answer this message (I was out of office). Please see inline. Cheers, Med > -----Message d'origine----- > De=A0: Jon Shallow [mailto:supjps-ietf@jpshallow.com] > Envoy=E9=A0: jeudi 21 d=E9cembre 2017 17:49 > =C0=A0: BOUCADAIR Mohamed IMT/OLN; dots@ietf.org > Objet=A0: RE: [Dots] I-D Action: draft-ietf-dots-signal-channel-14.txt >=20 > Hi Med, >=20 > See inline [Jon]. >=20 > Regards >=20 > Jon >=20 > -----Original Message----- > From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of > mohamed.boucadair@orange.com > Sent: 21 December 2017 14:55 > To: Jon Shallow; dots@ietf.org > Subject: Re: [Dots] I-D Action: draft-ietf-dots-signal-channel-14.txt >=20 > Re-, >=20 > Thank you for the review. >=20 > Please see inline. >=20 > Cheers, > Med >=20 > > -----Message d'origine----- > > De=A0: Jon Shallow [mailto:supjps-ietf@jpshallow.com] > > Envoy=E9=A0: jeudi 21 d=E9cembre 2017 15:05 > > =C0=A0: BOUCADAIR Mohamed IMT/OLN; dots@ietf.org Objet=A0: RE: [Dots] I= -D > > Action: draft-ietf-dots-signal-channel-14.txt > > > > Hi Med, > > > > Comments in my first pass through the -14 version > > > > 3. Design Overview > > > > "in [RFC7951] combined with JSON/CBOR conversion rules in [RFC7049]. ." > > > > Second trailing period not needed. >=20 > [Med] Already fixed in my local copy. Thanks. >=20 > > > > 4.4.1. Request Mitigation > > > > "Attributes with emty values" should read " Attributes with empty > values" >=20 > [Med] Idem as above. >=20 > > > > 4.5 DOTS Channel Session Configuration > > > > Replace > > > > If distinct configuration are > > used, DOTS agents MUST follow the appropriate configuration set as > > a > > > > with (plural) > > > > If distinct configurations are > > used, DOTS agents MUST follow the appropriate configuration set as > > a > > >=20 > [Med] Fixed. >=20 > > > > 4.5.2 Convey DOTS Signal Channel Session Configuration > > > > I think config-interval should be defined in seconds - to be > > consistent with lifetime, heartbeat-interval etc. >=20 > [Med] Works for me. >=20 > > > > Replace > > > > If a non-null value of 'config-interval' is received by a DOTS > > agent, it has to issue a PUT request to refresh the > > configuration > > > > with > > > > If a non-zero value of 'config-interval' is received by a DOTS > > client, it has to issue a PUT request to refresh the > > configuration > > >=20 > [Med] OK. > [Jon] Not yet updated [Med] Fixed. >=20 > > Replace (peace-time may now be idle-config, and attack-time-config may > > now be mitigating-config) > > > > peace-time-config: Set of configuration parameters to use during > > peacetime. This attribute has the same structure as 'attack-time= - > > config'. > > > > With > > > > idle-config: Set of configuration parameters to use during > > peacetime. This attribute has the same structure as 'mitigating- > > config'. If this parameter is not defined, then the peacetime > > configuration 'idle-config' is assumed to be the same as > > 'mitigating-config'. > > >=20 > [Med] We do already have a default behavior: >=20 > The DOTS agents MUST use the negotiated > values for message transmission parameters and default values for > non-negotiated message transmission parameters. >=20 > This means that the default values will be used if not specified. >=20 > If the same config is to be used for both idle-mitigation, both should be > returned. >=20 > Actually, this is what I meant in this discussion: >=20 > =3D=3D > [Jon] A minor comment - is the following more logical and more > descriptive? > [Med] I considered this but favored the other one because it is more > compact. For example, when the same config is to be used for both > peace/attack times, you just need to omit "peace-time-config", while you > need to include the same value twice for the other proposal. Do you have = a > strong preference? > =3D=3D=3D=3D > [Jon] OK - having both is fine by me - and if something is not defined > then > it takes on the default values. >=20 > > Figure 18: config-interval should have a current-value > > > > Should Figure 19 include config-interval ? >=20 > [Med] This is on purpose to indicate that config-interval can be omitted. > [Jon] OK >=20 > > > > 5.1 Tree structure > > > > Should > > > > | | +--ro acl-name -> > > /ietf-acl:access-lists/acl/acl-name > > | | +--ro acl-type -> > > /ietf-acl:access-lists/acl/acl-type > > > > Be (data channel definition is OK - other than perhaps 'set-name' > > really should be name', and 'type' should be 'type' due to netmod-acl > > potential > > changes) > > > > | | +--ro acl-name -> > > /ietf-dots-data-channel:access-lists/acl/name > > | | +--ro acl-type -> / > > ietf-dots-data-channel:access-lists/acl/type > > >=20 > [Med] No, the initial one is correct. > [Jon] OK >=20 > > 'config-interval' also needs a current/min/max -value setting (as you > > have in Figure 17) unless the DOTS server is going to control this > absolutely. > > Figure 18 will need updating as well. >=20 > [Med] Good catch. Figure 17 is wrong. >=20 > There is no value for having this for config-interval, because it is > always > up to the server to decide which value to put. >=20 > I will update figures 17/18 accordingly. > [Jon] You currently have in your local copy draft config-interval only fo= r > PUT, not GET, so config-interval is not under the control of the server. >=20 >=20 > > > > yang:zero-based-counter64 is not supported by JSON (a JavaScript > > limitation as I understand it) > > RFC7159 6. Numbers > > Note that when such software is used, numbers that are integers and > > are in the range [-(2**53)+1, (2**53)-1] are interoperable in the > > sense that implementations will agree exactly on their numeric > > values. >=20 > [Med] I guess we need to encode them as strings. RFC7493#section-2.2 says > the following: >=20 > An I-JSON sender cannot expect a receiver to treat an integer whose > absolute value is greater than 9007199254740991 (i.e., that is > outside the range [-(2**53)+1, (2**53)-1]) as an exact value. >=20 > For applications that require the exact interchange of numbers with > greater magnitude or precision, it is RECOMMENDED to encode them in > JSON string values. This requires that the receiving program > understand the intended semantic of the value. An example would be > 64-bit integers, even though modern hardware can deal with them, > because of the limited scope of JavaScript numbers. >=20 > [Jon] Oh - yuk - this means that there will be bloat in the COAP packet i= n > the 5 places where int64 (or uint64) are used. > [Jon] In all cases, I think that decimal64 will give us sufficient > precision, as well as handle the numbers getting very large (e.g. bytes > dropped). > [Jon] If we do go with the string version, then there has to be extra > logic > (and context knowledge) to convert any JSON into 64bit numbers to do any > math on. [Med] I'm afraid that we need to go with string, refer to 6.1 of RFC7951 wh= ich endorses the above recommendation. > > > > 5.2 YANG module > > > > ack-random-factor was a float - and so current-value etc. subtypes of > > ack-random-factor should be floats, not int16. I suggest that we use > > a different name - i.e. current-value-decimal. > > >=20 > [Med] I guess you are referring to section 6. >=20 > It seems that we will need *-value for major type 7. > [Jon] Correct - I see that you have updated this in your local copy draft= . >=20 > > Regards > > > > Jon > > > > -----Original Message----- > > From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of > > mohamed.boucadair@orange.com > > Sent: 19 December 2017 15:35 > > To: dots@ietf.org > > Subject: Re: [Dots] I-D Action: draft-ietf-dots-signal-channel-14.txt > > > > Re-, > > > > This version integrates the outcomes of the mailing list discussion, > > in > > particular: > > - Multiple client-id values does not mean anymore that multiple GWs > > have injected a value each. > > - Introduce attack-time-config and peace-time-config > > - Add some text to suggest dots servers to send heartbeats immediately > > after receiving the one from the peer dots client. > > - Refreshing the configuration must not occur during attack times. > > > > The document is still using client-side and server-side DOTS GW terms. > > The text will be aligned with the requirements I-D. > > > > Jon, please double check. > > > > All, please review and share your comments. > > > > Cheers, > > Med > > > > > -----Message d'origine----- > > > De=A0: Dots [mailto:dots-bounces@ietf.org] De la part de internet- > > > drafts@ietf.org Envoy=E9=A0: mardi 19 d=E9cembre 2017 16:19 =C0=A0: > > > i-d-announce@ietf.org Cc=A0: dots@ietf.org Objet=A0: [Dots] I-D Actio= n: > > > draft-ietf-dots-signal-channel-14.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-14.txt > > > Pages : 84 > > > Date : 2017-12-19 > > > > > > 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 > > > purposes. > > > > > > 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 > > > > > > o This RFC > > > > > > Please update TBD statements with the port number to be assigned t= o > > > DOTS Signal Channel Protocol. > > > > > > > > > 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-14 > > > https://datatracker.ietf.org/doc/html/draft-ietf-dots-signal-channel > > > -1 > > > 4 > > > > > > A diff from the previous version is available at: > > > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dots-signal-channel-14 > > > > > > > > > Please note that it may take a couple of minutes from the time of > > > submission until the htmlized version and diff are available at > > > tools.ietf.org. > > > > > > Internet-Drafts are also available by anonymous FTP at: > > > ftp://ftp.ietf.org/internet-drafts/ > > > > > > _______________________________________________ > > > Dots mailing list > > > Dots@ietf.org > > > https://www.ietf.org/mailman/listinfo/dots > > > > _______________________________________________ > > Dots mailing list > > Dots@ietf.org > > https://www.ietf.org/mailman/listinfo/dots >=20 > _______________________________________________ > Dots mailing list > Dots@ietf.org > https://www.ietf.org/mailman/listinfo/dots From nobody Mon Jan 8 00:44:14 2018 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 8ECF9124234 for ; Mon, 8 Jan 2018 00:44:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.629 X-Spam-Level: X-Spam-Status: No, score=-2.629 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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, T_RP_MATCHES_RCVD=-0.01, 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 C4V7R6l66Dz7 for ; Mon, 8 Jan 2018 00:44:11 -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 186ED12702E for ; Mon, 8 Jan 2018 00:44:11 -0800 (PST) Received: from opfednr06.francetelecom.fr (unknown [xx.xx.xx.70]) by opfednr27.francetelecom.fr (ESMTP service) with ESMTP id 74BDCA11D9; Mon, 8 Jan 2018 09:44:09 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.2]) by opfednr06.francetelecom.fr (ESMTP service) with ESMTP id 53F301A0065; Mon, 8 Jan 2018 09:44:09 +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; Mon, 8 Jan 2018 09:44:09 +0100 From: To: Jon Shallow , "dots@ietf.org" Thread-Topic: [Dots] DATA Channel: Filtering Lifetime Thread-Index: AdN6QMhuu4yNaHSDQRGxvfzspSLSRwALc5wAA3oFzkA= Date: Mon, 8 Jan 2018 08:44:08 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93300A0AD195@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <787AE7BB302AE849A7480A190F8B93300A09BE21@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <05fc01d37a76$f8d080e0$ea7182a0$@jpshallow.com> In-Reply-To: <05fc01d37a76$f8d080e0$ea7182a0$@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.2] Content-Type: multipart/alternative; boundary="_000_787AE7BB302AE849A7480A190F8B93300A0AD195OPEXCLILMA3corp_" MIME-Version: 1.0 Archived-At: Subject: Re: [Dots] DATA Channel: Filtering Lifetime 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, 08 Jan 2018 08:44:13 -0000 --_000_787AE7BB302AE849A7480A190F8B93300A0AD195OPEXCLILMA3corp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re-, This change will appear in the next version of the draft. The lifetime will= be defined at the acl level. Given that the parameter is likely to include long values, using "minutes" = instead of "seconds" seems more appropriate here. Cheers, Med De : Jon Shallow [mailto:supjps-ietf@jpshallow.com] Envoy=E9 : jeudi 21 d=E9cembre 2017 17:16 =C0 : BOUCADAIR Mohamed IMT/OLN; dots@ietf.org Objet : RE: [Dots] DATA Channel: Filtering Lifetime Hi Med, Instead of doing this at the ace level (of which there could be many per fi= lter definition), I would prefer this to be done at the dots-acl-order + ac= l-set level, or at the acl level. I think the lifetime needs to be sufficiently long to prevent frequent refr= eshes, but not too long that stale entries never get flushed. A day feels = too small, a week feels about right and a month is too long. Otherwise, this makes sense to me. Regards Jon From: Dots [mailto: dots-bounces@ietf.org] On= Behalf Of mohamed.boucadair@orange.com Sent: 21 December 2017 09:48 To: dots@ietf.org Subject: [Dots] DATA Channel: Filtering Lifetime Hi all, I suggest to add a lifetime attribute to the ACL entry so that we avoid sta= le rules be maintained by the server indefinitely. The change would look li= ke: augment /ietf-acl:access-lists/ietf-acl:acl/ietf-acl:aces/ietf-acl:ace: +--rw lifetime? int32 Motivation: This will be a first guard, for example, to soften maintaining stale entrie= s when a network renumbers but forgot to update/delete old filtering rules. ACLs are today enforced by an administrator (operator) for its own usages. = He/she can modify them based on local criteria. Scripts are usually used to= delete/add/etc. The game changes with DOTS as the rules are instructed by = a third party. The mitigation provider may end with a long list if stale en= tries because DOTS clients didn't cleared...which is undesirable. Of course= , a mitigation server provider may accept filtering rules with indefinite l= ifetime; this is deployment-specific. Lifetime is an information to be maintained at the DOTS server level, not a= t the device level. Network devices do not require to support the lifetime.= Clearing invalid entries will be managed through the DOTS server. The text will indicate that a DOTS server MUST NOT clear an expired entry w= hen an attack mitigation is ongoing. Any objection to this change? Opinions about the recommended value are also welcome. Cheers, Med --_000_787AE7BB302AE849A7480A190F8B93300A0AD195OPEXCLILMA3corp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Re-,

 

This change will appear in the = next version of the draft. The lifetime will be defined at the acl level.

 

Given that the parameter is lik= ely to include long values, using “minutes” instead of “s= econds” seems more appropriate here.

 

Cheers,

Med

 

J= on Shallow [mailto:supjps-ietf@jpshallow.com]
Envoy=E9 : jeudi 21 d=E9cembre 2017 17:16
=C0 : BOUCADAIR Mohamed IMT/OLN; dots@ietf.org
Objet : RE: [Dots] DATA Channel: Filtering Lifetime<= /span>

 

Hi Med,=

&n= bsp;

Instead= of doing this at the ace level (of which there could be many per filter de= finition), I would prefer this to be done at the dots-acl-order + acl-s= et level, or at the acl level.

&n= bsp;

I think= the lifetime needs to be sufficiently long to prevent frequent refreshes, = but not too long that stale entries never get flushed.  A day feels to= o small, a week feels about right and a month is too long.

&n= bsp;

Otherwi= se, this makes sense to me.

&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: 21 December 2017 09:48
To: dots@ietf.org
Subject: [Dots] DATA Channel: Filtering Lifetime

 

Hi all,

 

I suggest to add a lifetime attribute to th= e ACL entry so that we avoid stale rules be maintained by the server indefi= nitely. The change would look like:

 

  augment /iet= f-acl:access-lists/ietf-acl:acl/ietf-acl:aces/ietf-acl:ace:

    = +--rw lifetime?   int32

 

Motivation:

 

This will be a first guard, for example, to= soften maintaining stale entries when a network renumbers but forgot to up= date/delete old filtering rules.

 

ACLs are today enforced by an administrator= (operator) for its own usages. He/she can modify them based on local crite= ria. Scripts are usually used to delete/add/etc. The game changes with DOTS as the rules are instructed by a third party. T= he mitigation provider may end with a long list if stale entries because DO= TS clients didn’t cleared…which is undesirable. Of course, a mi= tigation server provider may accept filtering rules with indefinite lifetime; this is deployment-specific.

 

Life= time is an information to be maintained at the DOTS server level, not at th= e device level. Network devices do not require to support the lifetime. Clearing invalid entries will be managed through the= DOTS server.

 

The text will indicate that a DOTS server M= UST NOT clear an expired entry when an attack mitigation is ongoing.

 

Any = objection to this change?

 

Opin= ions about the recommended value are also welcome.

 

Chee= rs,

Med<= o:p>

 

 

 

 

 

 

 

 

--_000_787AE7BB302AE849A7480A190F8B93300A0AD195OPEXCLILMA3corp_-- From nobody Mon Jan 8 01:23:02 2018 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 2FE591250B8 for ; Mon, 8 Jan 2018 01:23:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 QpuTbGVIkBMQ for ; Mon, 8 Jan 2018 01:22:58 -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 F23021201F8 for ; Mon, 8 Jan 2018 01:22:57 -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 1eYTdu-0005Ky-8d; Mon, 08 Jan 2018 09:22:54 +0000 From: "Jon Shallow" To: , References: <787AE7BB302AE849A7480A190F8B93300A09BE21@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <05fc01d37a76$f8d080e0$ea7182a0$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93300A0AD195@OPEXCLILMA3.corporate.adroot.infra.ftgroup> In-Reply-To: <787AE7BB302AE849A7480A190F8B93300A0AD195@OPEXCLILMA3.corporate.adroot.infra.ftgroup> Date: Mon, 8 Jan 2018 09:22:54 -0000 Message-ID: <00cf01d38862$43cd7ff0$cb687fd0$@jpshallow.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00D0_01D38862.43CEDF80" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHI8ce6aBcw0ieOAMgV8dXqRX48dQFv55VZAczYQw2jZPnyEA== Content-Language: en-gb Archived-At: Subject: Re: [Dots] DATA Channel: Filtering Lifetime 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, 08 Jan 2018 09:23:00 -0000 This is a multipart message in MIME format. ------=_NextPart_000_00D0_01D38862.43CEDF80 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Med, =20 If we go for lifetime in minutes, it needs to obviously be clear in the surrounding documentation, but I think the variable ought to be named =91lifetime-minutes=92 for clarity. =20 Regards =20 Jon =20 From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of ietf-supjps-mohamed.boucadair@orange.com Sent: 08 January 2018 08:44 To: Jon Shallow; dots@ietf.org Subject: Re: [Dots] DATA Channel: Filtering Lifetime =20 Re-, =20 This change will appear in the next version of the draft. The lifetime = will be defined at the acl level.=20 =20 Given that the parameter is likely to include long values, using = =93minutes=94 instead of =93seconds=94 seems more appropriate here.=20 =20 Cheers, Med =20 De : Jon Shallow [mailto:supjps-ietf@jpshallow.com]=20 Envoy=E9 : jeudi 21 d=E9cembre 2017 17:16 =C0 : BOUCADAIR Mohamed IMT/OLN; dots@ietf.org Objet : RE: [Dots] DATA Channel: Filtering Lifetime =20 Hi Med, =20 Instead of doing this at the ace level (of which there could be many per filter definition), I would prefer this to be done at the dots-acl-order = + acl-set level, or at the acl level. =20 I think the lifetime needs to be sufficiently long to prevent frequent refreshes, but not too long that stale entries never get flushed. A day feels too small, a week feels about right and a month is too long. =20 Otherwise, this makes sense to me. =20 Regards =20 Jon =20 From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of mohamed.boucadair@orange.com Sent: 21 December 2017 09:48 To: dots@ietf.org Subject: [Dots] DATA Channel: Filtering Lifetime =20 Hi all,=20 =20 I suggest to add a lifetime attribute to the ACL entry so that we avoid stale rules be maintained by the server indefinitely. The change would = look like: =20 augment = /ietf-acl:access-lists/ietf-acl:acl/ietf-acl:aces/ietf-acl:ace: +--rw lifetime? int32 =20 Motivation:=20 =20 This will be a first guard, for example, to soften maintaining stale = entries when a network renumbers but forgot to update/delete old filtering = rules.=20 =20 ACLs are today enforced by an administrator (operator) for its own = usages. He/she can modify them based on local criteria. Scripts are usually used = to delete/add/etc. The game changes with DOTS as the rules are instructed = by a third party. The mitigation provider may end with a long list if stale entries because DOTS clients didn=92t cleared=85which is undesirable. Of = course, a mitigation server provider may accept filtering rules with indefinite lifetime; this is deployment-specific.=20 =20 Lifetime is an information to be maintained at the DOTS server level, = not at the device level. Network devices do not require to support the = lifetime. Clearing invalid entries will be managed through the DOTS server.=20 =20 The text will indicate that a DOTS server MUST NOT clear an expired = entry when an attack mitigation is ongoing.=20 =20 Any objection to this change? =20 Opinions about the recommended value are also welcome.=20 =20 Cheers, Med =20 =20 =20 =20 =20 =20 =20 =20 ------=_NextPart_000_00D0_01D38862.43CEDF80 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Med,

 

If we go for lifetime in = minutes,=A0 it needs to obviously be clear in the surrounding = documentation, but I think the variable ought to be named = ‘lifetime-minutes’ for clarity.

 

Regards

 

Jon

 

From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of = ietf-supjps-mohamed.boucadair@orange.com
Sent: 08 January = 2018 08:44
To: Jon Shallow; dots@ietf.org
Subject: = Re: [Dots] DATA Channel: Filtering = Lifetime

 

Re-,

 

This change will appear in the next version of the = draft. The lifetime will be defined at the acl level. =

 

Given that the parameter is likely to include long = values, using “minutes” instead of “seconds” = seems more appropriate here.

 

Cheers,

Med

 

De : Jon Shallow [mailto:supjps-ietf@jpshallow.co= m]
Envoy=E9 : jeudi 21 d=E9cembre 2017 = 17:16
=C0 : BOUCADAIR Mohamed IMT/OLN; dots@ietf.org
Objet : = RE: [Dots] DATA Channel: Filtering = Lifetime

 

Hi Med,

 

Instead of doing this at = the ace level (of which there could be many per filter definition), I = would prefer this to be done at the dots-acl-order + acl-set level, or = at the acl level.

 

I think the lifetime = needs to be sufficiently long to prevent frequent refreshes, but not too = long that stale entries never get flushed.  A day feels too small, = a week feels about right and a month is too = long.

 

Otherwise, this makes = sense to me.

 

Regards

 

Jon

 

From: Dots [mailto: dots-bounces@ietf.org] On = Behalf Of mohamed.boucadair@orange.com=
Sent: 21 December 2017 09:48
To: dots@ietf.org
Subject: = [Dots] DATA Channel: Filtering = Lifetime

 

Hi all, =

 

I = suggest to add a lifetime attribute to the ACL entry so that we avoid = stale rules be maintained by the server indefinitely. The change would = look like:

 

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

    +--rw = lifetime?   int32

 

Motivation:

 

This = will be a first guard, for example, to soften maintaining stale entries = when a network renumbers but forgot to update/delete old filtering = rules.

 

ACLs = are today enforced by an administrator (operator) for its own usages. = He/she can modify them based on local criteria. Scripts are usually used = to delete/add/etc. The game changes with DOTS as the rules are = instructed by a third party. The mitigation provider may end with a long = list if stale entries because DOTS clients didn’t = cleared…which is undesirable. Of course, a mitigation server = provider may accept filtering rules with indefinite lifetime; this is = deployment-specific.

 

Lifetime is an information = to be maintained at the DOTS server level, not at the device level. = Network devices do not require to support the lifetime. Clearing invalid = entries will be managed through the DOTS server. =

 

=

The text will = indicate that a DOTS server MUST NOT clear an expired entry when an = attack mitigation is ongoing.

 

=

Any objection to this = change?

 

=

Opinions about the = recommended value are also welcome.

 

=

Cheers,

Med

 

=

 

 

 

 

 

 

 

------=_NextPart_000_00D0_01D38862.43CEDF80-- From nobody Mon Jan 8 02:42:39 2018 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 32EA71273E2 for ; Mon, 8 Jan 2018 02:42:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 tU55oCFyPMMS for ; Mon, 8 Jan 2018 02:42: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 67302127342 for ; Mon, 8 Jan 2018 02:42: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 1eYUt0-0005OM-Sv for ietf-supjps-dots@ietf.org; Mon, 08 Jan 2018 10:42:34 +0000 From: "Jon Shallow" To: Date: Mon, 8 Jan 2018 10:42:35 -0000 Message-ID: <010a01d3886d$6540ba70$2fc22f50$@jpshallow.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_010B_01D3886D.654156B0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdOIbWMCs1bdiqx3T82q0wJiBaxkfA== Content-Language: en-gb Archived-At: Subject: [Dots] Filter name clashes 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, 08 Jan 2018 10:42:38 -0000 This is a multipart message in MIME format. ------=_NextPart_000_010B_01D3886D.654156B0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi there, I have realised that we have a serious filter name overwrite issue with the current data channel spec. Client-A can define "my-filter" by either going directly through "access-lists/acl", or "data-channel:client-identifier=ABC/set-name=my-filter/type=xx". Client-B can also define "my-filter" - using "access-lists/acl" which will overwrite Client-A's version, and actually so will "data-channel:client-identifier=DEF/set-name=my-filter/type=xx" even though client-identifier= will be different from that of Client A. I have posted an issue to the netmod-acl https://github.com/netmod-wg/acl-model/issues asking whether access-lists could be made a grouping or not. If this was to happen, we could use "uses access-lists" underneath a client-identifier. The alternative could be that we build our own higher level access-lists/ace/acl etc. tree and then cherry pick the actual "matches" and "actions" that we want for DOTS (which will save a lot of "augments") - for example l2 matches make no real sense to DOTS. Regards Jon ------=_NextPart_000_010B_01D3886D.654156B0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi there,

 

I have realised that we = have a serious filter name overwrite issue with the current data channel = spec.

 

Client-A can define = “my-filter” by either going directly through = “access-lists/acl”, or = “data-channel:client-identifier=3DABC/set-name=3Dmy-filter/type=3Dx= x”.

 

Client-B can also define = “my-filter” – using “access-lists/acl” = which will overwrite Client-A’s version, and actually so will = “data-channel:client-identifier=3DDEF/set-name=3Dmy-filter/type=3Dx= x” even though client-identifier=3D will be different from that of = Client A.

 

I have posted an issue = to the netmod-acl https://github.com= /netmod-wg/acl-model/issues asking whether access-lists could be = made a grouping or not.  If this was to happen, we could use = “uses access-lists” underneath a = client-identifier.

 

The alternative could be = that we build our own higher level access-lists/ace/acl etc. tree and = then cherry pick the actual “matches” and = “actions” that we want for DOTS (which will save a lot of = “augments”) – for example l2 matches make no real = sense to DOTS.

 

Regards

 

Jon

------=_NextPart_000_010B_01D3886D.654156B0-- From nobody Mon Jan 8 03:17:29 2018 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 566F112700F for ; Mon, 8 Jan 2018 03:17:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.33 X-Spam-Level: X-Spam-Status: No, score=-4.33 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, T_RP_MATCHES_RCVD=-0.01] 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 4xEYBTHeGyif for ; Mon, 8 Jan 2018 03:17:24 -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 943581243FE for ; Mon, 8 Jan 2018 03:17:24 -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=1515410243; 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:x-microsoft-antispam-message-info: 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=6oyDMDSAY/tuCb1BhGa24kGWooJYmw9MquhFdy 8wcG0=; b=SABxNgXjcS3jJIR2XKQtpq9u7yeFgd8AAQSnBzRv clQZSnIj49PLW3w8wtjwck8G9aupWdmI6jCphffvWdi9vcl9wy HSFw3GnSPJhtkpj0jlUF9jlfrSWhGjCLl2MLq4DbNwRE9NZJZl q+lnZpzSZr0uUU9oso5B95KhF0ufwpU= Received: from DNVEXAPP1N06.corpzone.internalzone.com (unknown [10.44.48.90]) by DNVWSMAILOUT1.mcafee.com with smtp (TLS: TLSv1/SSLv3,256bits,ECDHE-RSA-AES256-SHA384) id 3e64_01b6_fcd57fd7_a591_4a60_9f90_4a72f9f024df; Mon, 08 Jan 2018 05:17:22 -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; Mon, 8 Jan 2018 04:17:22 -0700 Received: from DNVEXUSR1N10.corpzone.internalzone.com (10.44.48.83) by DNVEXUSR1N10.corpzone.internalzone.com (10.44.48.83) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Mon, 8 Jan 2018 04:17:21 -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; Mon, 8 Jan 2018 04:17:21 -0700 Received: from NAM03-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; Mon, 8 Jan 2018 04:17:19 -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.386.5; Mon, 8 Jan 2018 11:17:19 +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.0386.008; Mon, 8 Jan 2018 11:17:19 +0000 From: "Konda, Tirumaleswar Reddy" To: Jon Shallow , "dots@ietf.org" Thread-Topic: [Dots] Filter name clashes Thread-Index: AdOIbWMCs1bdiqx3T82q0wJiBaxkfAAA1I4w Date: Mon, 8 Jan 2018 11:17:19 +0000 Message-ID: References: <010a01d3886d$6540ba70$2fc22f50$@jpshallow.com> In-Reply-To: <010a01d3886d$6540ba70$2fc22f50$@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; 7:yqYKAYAshNgteAB8kbcQ6brwKQ5z40/qEua5v9nxVl+Ovc1kM2T/XkoCJ3vGJVc4stEtD0fghr9DFnnolZPo9U0wJBYV6XzAMZP/TSuXHtO1XiB/JmQzYlYZwzT2o+bJ2cIXRt4qPNQYokoXRNcKCdI3BIb5Iv6/EiLLmA8MBlwigzhnl8pR3n5ETWik0tAs9ckBJ/Vr2cQxJcuomckggNh9jFXQEZMWBVjm4Lm1Yih/7tLXsOjGivbXw+IEnr55 x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: e161a689-9e3f-42d3-c5a1-08d556896209 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(5600026)(4604075)(3008032)(2017052603307)(7153060)(7193020); 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:(158342451672863)(166708455590820)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040470)(2401047)(8121501046)(5005006)(3231023)(944501075)(3002001)(10201501046)(93006095)(93001095)(6041268)(20161123558120)(20161123564045)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123562045)(6072148)(201708071742011); SRVR:DM5PR16MB1788; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:DM5PR16MB1788; x-forefront-prvs: 054642504A x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39380400002)(346002)(396003)(366004)(376002)(39860400002)(32952001)(189003)(199004)(966005)(7696005)(6246003)(77096006)(33656002)(86362001)(236005)(6306002)(54896002)(9686003)(55016002)(72206003)(53936002)(6436002)(316002)(2906002)(66066001)(3846002)(7736002)(6116002)(81166006)(790700001)(105586002)(25786009)(8936002)(478600001)(2501003)(74316002)(8676002)(81156014)(76176011)(110136005)(106356001)(3280700002)(19609705001)(99286004)(606006)(102836004)(229853002)(97736004)(80792005)(3660700001)(2900100001)(53546011)(2950100002)(14454004)(59450400001)(68736007)(5660300001)(6506007)(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) x-microsoft-antispam-message-info: hHuv2K5jsEp5gcr1n/WlDBxwvQmK8kFhALcCHsk4RC1W+k8ZMPGqPO6Hvwe6z3s41R4a8J6w+Z942F35BJgbvg== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_DM5PR16MB1788CAB3C4B49EF7BDB0C9A4EA130DM5PR16MB1788namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: e161a689-9e3f-42d3-c5a1-08d556896209 X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Jan 2018 11:17:19.7484 (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 <6194> : inlines <6296> : streams <1775455> : uri <2565668> Archived-At: Subject: Re: [Dots] Filter name clashes 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, 08 Jan 2018 11:17:27 -0000 --_000_DM5PR16MB1788CAB3C4B49EF7BDB0C9A4EA130DM5PR16MB1788namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Jon, Even if client-A and client-B use the same ACL name "my-filter", the same A= CL name is created by two different clients with different client identitie= s, the server will not override the ACL rule created by one client with ano= ther client (i.e. one of the reasons for introducing client-unique). The cl= ient must create a ACL rule by using "data-channel:client-unique=3DABC/set-= name=3Dmy-filter/type=3Dxx" and not just use "access-lists/acl". Cheers, -Tiru From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Jon Shallow Sent: Monday, January 8, 2018 4:13 PM To: dots@ietf.org Subject: [Dots] Filter name clashes Hi there, I have realised that we have a serious filter name overwrite issue with the= current data channel spec. Client-A can define "my-filter" by either going directly through "access-li= sts/acl", or "data-channel:client-identifier=3DABC/set-name=3Dmy-filter/typ= e=3Dxx". Client-B can also define "my-filter" - using "access-lists/acl" which will = overwrite Client-A's version, and actually so will "data-channel:client-ide= ntifier=3DDEF/set-name=3Dmy-filter/type=3Dxx" even though client-identifier= =3D will be different from that of Client A. I have posted an issue to the netmod-acl https://github.com/netmod-wg/acl-m= odel/issues asking whether access-lists could be made a grouping or not. I= f this was to happen, we could use "uses access-lists" underneath a client-= identifier. The alternative could be that we build our own higher level access-lists/ac= e/acl etc. tree and then cherry pick the actual "matches" and "actions" tha= t we want for DOTS (which will save a lot of "augments") - for example l2 m= atches make no real sense to DOTS. Regards Jon --_000_DM5PR16MB1788CAB3C4B49EF7BDB0C9A4EA130DM5PR16MB1788namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Jon,

 

Even if client-A and client-B use the s= ame ACL name “my-filter”, the same ACL name is created by two d= ifferent clients with different client identities, the server will not override the ACL rule created by one client with anoth= er client (i.e. one of the reasons for introducing client-unique). The clie= nt must create a ACL rule by using “data-channel:client-unique=3DABC/= set-name=3Dmy-filter/type=3Dxx” and not just use “access-lists/acl”.

 

Cheers,

-Tiru

 

From:<= /span> Dots [mailto:dots-bou= nces@ietf.org] On Behalf Of Jon Shallow
Sent: Monday, January 8, 2018 4:13 PM
To: dots@ietf.org
Subject: [Dots] Filter name clashes

 

Hi ther= e,

&n= bsp;

I have = realised that we have a serious filter name overwrite issue with the curren= t data channel spec.

&n= bsp;

Client-= A can define “my-filter” by either going directly through ̶= 0;access-lists/acl”, or “data-channel:client-identifier=3DABC/s= et-name=3Dmy-filter/type=3Dxx”.

&n= bsp;

Client-= B can also define “my-filter” – using “access-lists= /acl” which will overwrite Client-A’s version, and actually so = will “data-channel:client-identifier=3DDEF/set-name=3Dmy-filter/type= =3Dxx” even though client-identifier=3D will be different from that of Client A.<= /o:p>

&n= bsp;

I have = posted an issue to the netmod-acl https://github.co= m/netmod-wg/acl-model/issues asking whether access-lists could be made = a grouping or not.  If this was to happen, we could use “uses ac= cess-lists” underneath a client-identifier.

&n= bsp;

The alt= ernative could be that we build our own higher level access-lists/ace/acl e= tc. tree and then cherry pick the actual “matches” and “a= ctions” that we want for DOTS (which will save a lot of “augments”) – for example l2 matches make no real sense = to DOTS.

&n= bsp;

Regards=

&n= bsp;

Jon

--_000_DM5PR16MB1788CAB3C4B49EF7BDB0C9A4EA130DM5PR16MB1788namp_-- From nobody Mon Jan 8 03:40:59 2018 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 D4DEF1273E2 for ; Mon, 8 Jan 2018 03:40:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 FzeF8A70MLlS for ; Mon, 8 Jan 2018 03:40:55 -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 0FB481204DA for ; Mon, 8 Jan 2018 03:40:55 -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 1eYVnR-0005RM-BJ; Mon, 08 Jan 2018 11:40:53 +0000 From: "Jon Shallow" To: "'Konda, Tirumaleswar Reddy'" , References: <010a01d3886d$6540ba70$2fc22f50$@jpshallow.com> In-Reply-To: Date: Mon, 8 Jan 2018 11:40:53 -0000 Message-ID: <014501d38875$8a7968c0$9f6c3a40$@jpshallow.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0146_01D38875.8A7AC850" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQGObXliLbib6O6yLV/NQ5+C+6q1sAHzJUIso+RzQgA= Content-Language: en-gb Archived-At: Subject: Re: [Dots] Filter name clashes 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, 08 Jan 2018 11:40:58 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0146_01D38875.8A7AC850 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Tiru, Actually no, there is not uniqueness, as I understand it, in the contents of "my-filter". As per the current YANG model (-11) augment /ietf-acl:access-lists: +--rw client-identifier* binary 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 module: ietf-access-control-list +--rw access-lists +--rw acl* [acl-type acl-name] | +--rw acl-name string | ... +--rw data-channel:client-identifier* binary +--rw data-channel:dots-acl-order +--rw data-channel:acl-set* [set-name type] +--rw data-channel:set-name -> /ietf-acl:access-lists/acl/acl-name +--rw data-channel:type -> /ietf-acl:access-lists/acl/acl-type The set-name points to the common acl-name in "/ietf-acl:access-lists/acl/acl-name" which will also be "my-filter". We also do need a way to stop a (rogue) client using "access-lists/acl". Regards Jon From: Konda, Tirumaleswar Reddy [mailto:ietf-supjps-TirumaleswarReddy_Konda@mcafee.com] Sent: 08 January 2018 11:17 To: Jon Shallow; dots@ietf.org Subject: RE: [Dots] Filter name clashes Hi Jon, Even if client-A and client-B use the same ACL name "my-filter", the same ACL name is created by two different clients with different client identities, the server will not override the ACL rule created by one client with another client (i.e. one of the reasons for introducing client-unique). The client must create a ACL rule by using "data-channel:client-unique=ABC/set-name=my-filter/type=xx" and not just use "access-lists/acl". Cheers, -Tiru From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Jon Shallow Sent: Monday, January 8, 2018 4:13 PM To: dots@ietf.org Subject: [Dots] Filter name clashes Hi there, I have realised that we have a serious filter name overwrite issue with the current data channel spec. Client-A can define "my-filter" by either going directly through "access-lists/acl", or "data-channel:client-identifier=ABC/set-name=my-filter/type=xx". Client-B can also define "my-filter" - using "access-lists/acl" which will overwrite Client-A's version, and actually so will "data-channel:client-identifier=DEF/set-name=my-filter/type=xx" even though client-identifier= will be different from that of Client A. I have posted an issue to the netmod-acl https://github.com/netmod-wg/acl-model/issues asking whether access-lists could be made a grouping or not. If this was to happen, we could use "uses access-lists" underneath a client-identifier. The alternative could be that we build our own higher level access-lists/ace/acl etc. tree and then cherry pick the actual "matches" and "actions" that we want for DOTS (which will save a lot of "augments") - for example l2 matches make no real sense to DOTS. Regards Jon ------=_NextPart_000_0146_01D38875.8A7AC850 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Tiru,

 

Actually no, there is = not uniqueness, as I understand it, in the contents of = “my-filter”.  As per the current YANG model = (-11)

 

  =
augment /ietf-acl:access-lists:
    +--rw =
client-identifier*   binary

  augment = /ietf-acl:access-lists:

    +--rw = dots-acl-order

    &nbs= p;  +--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

 

=

module: = ietf-access-control-list

    +--rw = access-lists

    &nbs= p;  +--rw acl* [acl-type acl-name]

    &nbs= p;  |  +--rw acl-name    = string

    &nbs= p;  |  ...

    &nbs= p;  +--rw data-channel:client-identifier*   = binary

    &nbs= p;  +--rw data-channel:dots-acl-order

    &nbs= p;     +--rw data-channel:acl-set* [set-name = type]

    &nbs= p;        +--rw = data-channel:set-name    -> = /ietf-acl:access-lists/acl/acl-name

    &nbs= p;        +--rw = data-channel:type        -> = /ietf-acl:access-lists/acl/acl-type

 

The set-name points to = the common acl-name in “/ietf-acl:access-lists/acl/acl-name” = which will also be “my-filter”.

 

We also do need a way to = stop a (rogue) client using “access-lists/acl”.=

 

Regards

 

Jon

From: Konda, Tirumaleswar Reddy = [mailto:ietf-supjps-TirumaleswarReddy_Konda@mcafee.com]
Sent: = 08 January 2018 11:17
To: Jon Shallow; = dots@ietf.org
Subject: RE: [Dots] Filter name = clashes

 

Hi Jon,

 

Even if client-A and client-B use = the same ACL name “my-filter”, the same ACL name is created = by two different clients with different client identities, the server = will not override the ACL rule created by one client with another client = (i.e. one of the reasons for introducing client-unique). The client must = create a ACL rule by using = “data-channel:client-unique=3DABC/set-name=3Dmy-filter/type=3Dxx= 221; and not just use = “access-lists/acl”.

 

Cheers,

-Tiru

 

From: Dots [mailto:dots-bounces@ietf.org] = On Behalf Of Jon Shallow
Sent: Monday, January 8, 2018 = 4:13 PM
To: dots@ietf.org
Subject: = [Dots] Filter name clashes

 

Hi = there,

 

I have realised that we = have a serious filter name overwrite issue with the current data channel = spec.

 

Client-A can define = “my-filter” by either going directly through = “access-lists/acl”, or = “data-channel:client-identifier=3DABC/set-name=3Dmy-filter/type=3Dx= x”.

 

Client-B can also define = “my-filter” – using “access-lists/acl” = which will overwrite Client-A’s version, and actually so will = “data-channel:client-identifier=3DDEF/set-name=3Dmy-filter/type=3Dx= x” even though client-identifier=3D will be different from that of = Client A.

 

I have posted an issue = to the netmod-acl https://github.com= /netmod-wg/acl-model/issues asking whether access-lists could be = made a grouping or not.  If this was to happen, we could use = “uses access-lists” underneath a = client-identifier.

 

The alternative could be = that we build our own higher level access-lists/ace/acl etc. tree and = then cherry pick the actual “matches” and = “actions” that we want for DOTS (which will save a lot of = “augments”) – for example l2 matches make no real = sense to DOTS.

 

Regards

 

Jon

------=_NextPart_000_0146_01D38875.8A7AC850-- From nobody Mon Jan 8 05:37:15 2018 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 3444E127863 for ; Mon, 8 Jan 2018 05:37:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.629 X-Spam-Level: X-Spam-Status: No, score=-2.629 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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, T_RP_MATCHES_RCVD=-0.01, 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 sNDQvEo4YVf0 for ; Mon, 8 Jan 2018 05:37:12 -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 45548120227 for ; Mon, 8 Jan 2018 05:37:12 -0800 (PST) Received: from opfednr07.francetelecom.fr (unknown [xx.xx.xx.71]) by opfednr22.francetelecom.fr (ESMTP service) with ESMTP id 6E9CB21019; Mon, 8 Jan 2018 14:37:10 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.61]) by opfednr07.francetelecom.fr (ESMTP service) with ESMTP id 4FA081C0077; Mon, 8 Jan 2018 14:37:10 +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; Mon, 8 Jan 2018 14:37:10 +0100 From: To: "Konda, Tirumaleswar Reddy" , "Jon Shallow" , "dots@ietf.org" Thread-Topic: [Dots] DOTS gateway loop handling Thread-Index: AdN7BmUWqzqWF8J/Qkebpl5qeIXshwAB7v7w///ytQCAAACQAP/lD6SA Date: Mon, 8 Jan 2018 13:37:09 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93300A0AD4D3@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <06a901d37b06$681bf800$3853e800$@jpshallow.com> <06ce01d37b0f$de1d3ba0$9a57b2e0$@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.2] Content-Type: multipart/alternative; boundary="_000_787AE7BB302AE849A7480A190F8B93300A0AD4D3OPEXCLILMA3corp_" MIME-Version: 1.0 Archived-At: Subject: Re: [Dots] DOTS gateway loop handling 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, 08 Jan 2018 13:37:14 -0000 --_000_787AE7BB302AE849A7480A190F8B93300A0AD4D3OPEXCLILMA3corp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Tiru, Jon, all, Please find below a tentative text to cover this issue: =3D=3D hop-limit: This attribute is used to detect and prevent infinite loops. This attribute is typically inserted by a DOTS gateway. Each intermediate DOTS agent involved in the handling of a DOTS message MUST decrement the hop-limit value by 1 prior to forwarding upstream. DOTS messages MUST NOT be forwarded if the value of hop-limit is set to '0' after decrement. Messages that cannot be forwarded because of exhausted hop-limit SHOULD be logged. The initial hop-limit value SHOULD be configurable. If no initial value is explicitly provided, the default initial hop-limit value of 16 (32/64?) MUST be used. Because forwarding errors may occur if inadequate hop-limit values are used, DOTS agents at the boundaries of an administrative domain MAY be instructed to rewrite the value of hop-limit carried in received messages (that is, ignore the value of hop-limit received in a message). This is an optional attribute. =3D=3D=3D Cheers, Med De : Dots [mailto:dots-bounces@ietf.org] De la part de Konda, Tirumaleswar = Reddy Envoy=E9 : vendredi 22 d=E9cembre 2017 11:32 =C0 : Jon Shallow; dots@ietf.org Objet : Re: [Dots] DOTS gateway loop handling Yes, I meant as CBOR and JSON parameters. -Tiru From: Jon Shallow [mailto:supjps-ietf@jpshallow.com] Sent: Friday, December 22, 2017 4:00 PM To: Konda, Tirumaleswar Reddy >; dots@ietf.org Subject: RE: [Dots] DOTS gateway loop handling Hi Tiru, I'm not sure that we can necessarily support this as a Header, but certainl= y as a parameter in the CBOR / JSON I think the most likely scenario for this loop to happen is if DNS is not w= orking as expected. Regards Jon From: Dots [mailto: dots-bounces@ietf.org] On= Behalf Of Konda, Tirumaleswar Reddy Sent: 22 December 2017 10:24 To: Jon Shallow; dots@ietf.org Subject: Re: [Dots] DOTS gateway loop handling Good point, both drafts can use a mechanism similar to the one discussed in= https://tools.ietf.org/html/rfc7332#section-5 (Max-forwards header). -Tiru From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Jon Shallow Sent: Friday, December 22, 2017 2:53 PM To: dots@ietf.org Subject: [Dots] DOTS gateway loop handling Hi WG, While there never should be a loop in DOTS traffic going via DOTS gateways,= if there is a mis-configuration a request can end up getting bounced betwe= en a set of (not necessarily adjacent) DOTS gateways. We need to make sure that this loop is broken - possibly by using a mechani= sm similar to TTL in IP packets. If we agree that loops need to get broken, this "feature" needs to get adde= d into both the signal and data channels. Regards Jon --_000_787AE7BB302AE849A7480A190F8B93300A0AD4D3OPEXCLILMA3corp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Tiru, Jon, all,

 

Please find below a tentative t= ext to cover this issue:

 

=3D=3D

   hop-limit:  This attribute is u=
sed to detect and prevent infinite
      loops.  This =
attribute is typically inserted by a DOTS gateway.
 
      Each intermediate =
DOTS agent involved in the handling of a DOTS
      message MUST decre=
ment the hop-limit value by 1 prior to
      forwarding upstrea=
m.  DOTS messages MUST NOT be forwarded if the
      value of hop-limit=
 is set to '0' after decrement.  Messages that
      cannot be forwarde=
d because of exhausted hop-limit SHOULD be
      logged.=

 
      The initial hop-li=
mit value SHOULD be configurable.  If no initial

      value is explicitl=
y provided, the default initial hop-limit value


      of 16 (32/64?) MUS=
T be used.


 


      Because forwarding=
 errors may occur if inadequate hop-limit values


      are used, DOTS age=
nts at the boundaries of an administrative


      domain MAY be inst=
ructed to rewrite the value of hop-limit carried


      in received messag=
es (that is, ignore the value of hop-limit


      received in a mess=
age).


 


      This is an optiona=
l attribute.


=3D=3D=3D


 


Cheers,


Med


 








De : Dots [mailto:dots-bounces@ietf.=
org]
De la part de Konda, Tirumaleswar Reddy

Envoy=E9 : vendredi 22 d=E9cembre 2017 11:32

=C0 : Jon Shallow; dots@ietf.org

Objet : Re: [Dots] DOTS gateway loop handling=







 


Yes, I meant as CBOR and JSON parameters.


 


-Tiru


 








From: Jon Shallow [mailto:s=
upjps-ietf@jpshallow.com]


Sent: Friday, December 22, 2017 4:00 PM

To: Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@McAfee.com>;
dots@ietf.org

Subject: RE: [Dots] DOTS gateway loop handling






 


Hi Tiru=
,


&n=
bsp;


I’=
;m not sure that we can necessarily support this as a Header, but certainly=
 as a parameter in the CBOR / JSON


&n=
bsp;


I think=
 the most likely scenario for this loop to happen is if DNS is not working =
as expected.


&n=
bsp;


Regards=



&n=
bsp;


Jon


&n=
bsp;






From:=
 Dots [mailto:
dots-bounces@ietf.org] On B=
ehalf Of
Konda, Tirumaleswar Reddy

Sent: 22 December 2017 10:24

To: Jon Shallow; dots@ietf.org<=
br>
Subject: Re: [Dots] DOTS gateway loop handling






 


Good point, both drafts can use a mechanism similar to the one discus=
sed in
https://tools.iet=
f.org/html/rfc7332#section-5 (Max-forwards header).

 


-Tiru


 








From: Dots [mailto:dots-bounces=
@ietf.org]
On Behalf Of Jon Shallow

Sent: Friday, December 22, 2017 2:53 PM

To: dots@ietf.org

Subject: [Dots] DOTS gateway loop handling






 


Hi WG,


 


While there never should be a l=
oop in DOTS traffic going via DOTS gateways, if there is a mis-configuratio=
n a request can end up getting bounced between a set of (not necessarily ad=
jacent) DOTS gateways.


 


We need to make sure that this =
loop is broken – possibly by using a mechanism similar to TTL in IP p=
ackets.


 


If we agree that loops need to =
get broken, this “feature” needs to get added into both the sig=
nal and data channels.


 


Regards


 


Jon
--_000_787AE7BB302AE849A7480A190F8B93300A0AD4D3OPEXCLILMA3corp_-- From nobody Mon Jan 8 06:09:57 2018 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 7F65212895E for ; Mon, 8 Jan 2018 06:09:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.51 X-Spam-Level: X-Spam-Status: No, score=-5.51 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_RP_MATCHES_RCVD=-0.01] 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 IqTAtgkvfkaE for ; Mon, 8 Jan 2018 06:09:53 -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 29E28128959 for ; Mon, 8 Jan 2018 06:09:52 -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=1515420592; 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:x-microsoft-antispam-message-info: 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 NXzLal5azXAx16NvGNr5fG/Nz1BYq5GYh/Vk9ybJH 8=; b=CY+kfZhvi7El80ZhulP5WG4sUJ1PgVxVP9hiWk/32Lg4 lAyTDDfGit+AalZ572VNoUAXxRsl0peKNRFwKkd9GJjsNM85LY HuTnFM0nkw3mTwmbMigjpaFE+YgDQLapZp5+2k2yv9MhWRvYQy CGDP8MA5ansjPDhbOz7C+LFlR2Q= Received: from MIVEXAPP1N02.corpzone.internalzone.com (mivexapp1n02.corpzone.internalzone.com [10.48.48.89]) by MIVWSMAILOUT1.mcafee.com with smtp (TLS: TLSv1/SSLv3,256bits,ECDHE-RSA-AES256-SHA384) id 5b8d_7d2c_4f02170b_1367_46a5_8f52_a285925297e6; Mon, 08 Jan 2018 08:09:51 -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; Mon, 8 Jan 2018 09:09:47 -0500 Received: from MIVEXUSR1N01.corpzone.internalzone.com (10.48.48.81) by MIVEXUSR1N02.corpzone.internalzone.com (10.48.48.82) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Mon, 8 Jan 2018 09:09:45 -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; Mon, 8 Jan 2018 09:09:46 -0500 Received: from NAM02-SN1-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; Mon, 8 Jan 2018 09:09:42 -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.386.5; Mon, 8 Jan 2018 14:09:42 +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.0386.008; Mon, 8 Jan 2018 14:09:42 +0000 From: "Konda, Tirumaleswar Reddy" To: "mohamed.boucadair@orange.com" , Jon Shallow , "dots@ietf.org" Thread-Topic: [Dots] DOTS gateway loop handling Thread-Index: AdN7BmUWqzqWF8J/Qkebpl5qeIXshwAB7v7wAABvMAAAAAi8kANdccuAAAEUZ6A= Date: Mon, 8 Jan 2018 14:09:42 +0000 Message-ID: References: <06a901d37b06$681bf800$3853e800$@jpshallow.com> <06ce01d37b0f$de1d3ba0$9a57b2e0$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93300A0AD4D3@OPEXCLILMA3.corporate.adroot.infra.ftgroup> In-Reply-To: <787AE7BB302AE849A7480A190F8B93300A0AD4D3@OPEXCLILMA3.corporate.adroot.infra.ftgroup> 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.16.166] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DM5PR16MB1785; 7:YsVKgANXk5erjOb8WfKbXxZxIELvLwpeNKBn3aAm0M2tiDt/ZBl7zg3Lo8su6SKDd04V/Gm9n5DPZpY+wvGVNi7E/APdcaeBb6RNa0ndfvQ9nTHtK5IjgmOLCbMxZAtZRHFs3/FYyIUM3/0eX99Ku+7y0Fl1Ikvr9p7OS5mEzLP97cz6C5+CRkA0Li1Q/oqNc6wh//fJBRKjlAeR2I7JTS6CdIlcXBC1QPVGDJXep+nQ35NBzgwtFEKkinPM1KFK x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: dfbb4bdf-a505-4a92-e1c1-08d556a1768e x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(5600026)(4604075)(3008032)(2017052603307)(7153060)(7193020); SRVR:DM5PR16MB1785; x-ms-traffictypediagnostic: DM5PR16MB1785: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(18271650672692)(21748063052155)(123452027830198); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040470)(2401047)(8121501046)(5005006)(3231023)(944501075)(3002001)(10201501046)(93006095)(93001095)(6041268)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123564045)(20161123560045)(20161123562045)(20161123558120)(6072148)(201708071742011); SRVR:DM5PR16MB1785; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:DM5PR16MB1785; x-forefront-prvs: 054642504A x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(396003)(39860400002)(39380400002)(346002)(376002)(366004)(32952001)(189003)(199004)(53546011)(7696005)(8676002)(81156014)(2900100001)(316002)(110136005)(9326002)(2950100002)(6246003)(8936002)(99286004)(68736007)(81166006)(86362001)(3280700002)(3660700001)(25786009)(2906002)(59450400001)(93886005)(77096006)(3846002)(6116002)(229853002)(19609705001)(7736002)(6506007)(74316002)(33656002)(106356001)(105586002)(72206003)(53936002)(6436002)(54896002)(5660300001)(102836004)(80792005)(97736004)(76176011)(55016002)(236005)(2501003)(9686003)(6306002)(478600001)(606006)(66066001)(790700001)(966005)(14454004)(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) x-microsoft-antispam-message-info: YjkWQNEEAf6C5wq+zXm7oLpswVN7WBSqFqzyVeqER2+IwZ3EO7qdgos987rNvXJ7FzrtGsU6wkgwHQAqH+bEfA== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_DM5PR16MB17880A4496181372F9DADDD2EA130DM5PR16MB1788namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: dfbb4bdf-a505-4a92-e1c1-08d556a1768e X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Jan 2018 14:09:42.0341 (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 <6195> : inlines <6296> : streams <1775467> : uri <2565755> Archived-At: Subject: Re: [Dots] DOTS gateway loop handling 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, 08 Jan 2018 14:09:55 -0000 --_000_DM5PR16MB17880A4496181372F9DADDD2EA130DM5PR16MB1788namp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Med, Looks good, an error response is required to identify the request has not r= eached the final DOTS server. Cheers, -Tiru From: mohamed.boucadair@orange.com [mailto:mohamed.boucadair@orange.com] Sent: Monday, January 8, 2018 7:07 PM To: Konda, Tirumaleswar Reddy ; Jon Sha= llow ; dots@ietf.org Subject: RE: [Dots] DOTS gateway loop handling Hi Tiru, Jon, all, Please find below a tentative text to cover this issue: =3D=3D hop-limit: This attribute is used to detect and prevent infinite loops. This attribute is typically inserted by a DOTS gateway. Each intermediate DOTS agent involved in the handling of a DOTS message MUST decrement the hop-limit value by 1 prior to forwarding upstream. DOTS messages MUST NOT be forwarded if the value of hop-limit is set to '0' after decrement. Messages that cannot be forwarded because of exhausted hop-limit SHOULD be logged. The initial hop-limit value SHOULD be configurable. If no initial value is explicitly provided, the default initial hop-limit value of 16 (32/64?) MUST be used. Because forwarding errors may occur if inadequate hop-limit values are used, DOTS agents at the boundaries of an administrative domain MAY be instructed to rewrite the value of hop-limit carried in received messages (that is, ignore the value of hop-limit received in a message). This is an optional attribute. =3D=3D=3D Cheers, Med De : Dots [mailto:dots-bounces@ietf.org] De la part de Konda, Tirumaleswar = Reddy Envoy=E9 : vendredi 22 d=E9cembre 2017 11:32 =C0 : Jon Shallow; dots@ietf.org Objet : Re: [Dots] DOTS gateway loop handling Yes, I meant as CBOR and JSON parameters. -Tiru From: Jon Shallow [mailto:supjps-ietf@jpshallow.com] Sent: Friday, December 22, 2017 4:00 PM To: Konda, Tirumaleswar Reddy >; dots@ietf.org Subject: RE: [Dots] DOTS gateway loop handling Hi Tiru, I'm not sure that we can necessarily support this as a Header, but certainl= y as a parameter in the CBOR / JSON I think the most likely scenario for this loop to happen is if DNS is not w= orking as expected. Regards Jon From: Dots [mailto: dots-bounces@ietf.org] On= Behalf Of Konda, Tirumaleswar Reddy Sent: 22 December 2017 10:24 To: Jon Shallow; dots@ietf.org Subject: Re: [Dots] DOTS gateway loop handling Good point, both drafts can use a mechanism similar to the one discussed in= https://tools.ietf.org/html/rfc7332#section-5 (Max-forwards header). -Tiru From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Jon Shallow Sent: Friday, December 22, 2017 2:53 PM To: dots@ietf.org Subject: [Dots] DOTS gateway loop handling Hi WG, While there never should be a loop in DOTS traffic going via DOTS gateways,= if there is a mis-configuration a request can end up getting bounced betwe= en a set of (not necessarily adjacent) DOTS gateways. We need to make sure that this loop is broken - possibly by using a mechani= sm similar to TTL in IP packets. If we agree that loops need to get broken, this "feature" needs to get adde= d into both the signal and data channels. Regards Jon --_000_DM5PR16MB17880A4496181372F9DADDD2EA130DM5PR16MB1788namp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Med,

&nbs= p;

Looks goo= d, an error response is required to identify the request has not reached th= e final DOTS server.

&nbs= p;

Cheers,

-Tiru

 

From:<= /span> mohamed.boucadair@ora= nge.com [mailto:mohamed.boucadair@orange.com]
Sent: Monday, January 8, 2018 7:07 PM
To: Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@McAfee.com= >; Jon Shallow <supjps-ietf@jpshallow.com>; dots@ietf.org
Subject: RE: [Dots] DOTS gateway loop handling

 

Hi Tiru, Jon, all,

 

Please find below a tentative text to cover th= is issue:

 

=3D=3D

   hop-limit:  This attribute is used to detect and pre=
vent infinite
      loops.  This attribute is typicall=
y inserted by a DOTS gateway.
 
      Each intermediate DOTS agent involved i=
n the handling of a DOTS
      message MUST decrement the hop-limit va=
lue by 1 prior to
      forwarding upstream.  DOTS message=
s MUST NOT be forwarded if the
      value of hop-limit is set to '0' after =
decrement.  Messages that
      cannot be forwarded because of exhauste=
d hop-limit SHOULD be
      logged.
 
      The initial hop-limit value SHOULD be c=
onfigurable.  If no initial
      value is explicitly provided, the defau=
lt initial hop-limit value
      of 16 (32/64?) MUST be used.=

 
      Because forwarding errors may occur if =
inadequate hop-limit values
      are used, DOTS agents at the boundaries=
 of an administrative
      domain MAY be instructed to rewrite the=
 value of hop-limit carried
      in received messages (that is, ignore t=
he value of hop-limit
      received in a message).

 


      This is an optional attribute.


=3D=3D=3D


 


Cheers,


Med


 








De : Dots [mailto:dots-bounces@ietf.org]
De la part de Konda, Tirumaleswar Reddy

Envoy=E9 : vendredi 22 d=E9cembre 2017 11:32

=C0 : Jon Shallow; dots@ietf.o=
rg

Objet : Re: [Dots] DOTS gateway loop handling=







 


Yes, I me=
ant as CBOR and JSON parameters.


&nbs=
p;


-Tiru


&nbs=
p;








From:<=
/span> Jon Shallow [mailto:supjps-ietf@jpshallow.com]


Sent: Friday, December 22, 2017 4:00 PM

To: Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@McAfee.com>;
dots@ietf.org

Subject: RE: [Dots] DOTS gateway loop handling






 


Hi Tiru=
,


&n=
bsp;


I’=
;m not sure that we can necessarily support this as a Header, but certainly=
 as a parameter in the CBOR / JSON


&n=
bsp;


I think=
 the most likely scenario for this loop to happen is if DNS is not working =
as expected.


&n=
bsp;


Regards=



&n=
bsp;


Jon


&n=
bsp;






From: Dots [mailto:
dots-bounces@ietf.org] On B=
ehalf Of
Konda, Tirumaleswar Reddy

Sent: 22 December 2017 10:24

To: Jon Shallow; dots@ietf.org<=
br>
Subject: Re: [Dots] DOTS gateway loop handling






 


Good poin=
t, both drafts can use a mechanism similar to the one discussed in
https://tools.iet=
f.org/html/rfc7332#section-5 (Max-forwards header).

&nbs=
p;


-Tiru


&nbs=
p;








From:<=
/span> Dots [mailto:dots-bounces@ietf.org]
On Behalf Of Jon Shallow

Sent: Friday, December 22, 2017 2:53 PM

To: dots@ietf.org

Subject: [Dots] DOTS gateway loop handling






 


Hi WG,


 


While there never should be a l=
oop in DOTS traffic going via DOTS gateways, if there is a mis-configuratio=
n a request can end up getting bounced between a set of (not necessarily ad=
jacent) DOTS gateways.


 


We need to make sure that this =
loop is broken – possibly by using a mechanism similar to TTL in IP p=
ackets.


 


If we agree that loops need to =
get broken, this “feature” needs to get added into both the sig=
nal and data channels.


 


Regards


 


Jon
--_000_DM5PR16MB17880A4496181372F9DADDD2EA130DM5PR16MB1788namp_-- From nobody Mon Jan 8 06:29:33 2018 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 9630A12895E for ; Mon, 8 Jan 2018 06:29:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 SUEyQu7CulqP for ; Mon, 8 Jan 2018 06:29:29 -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 C8EF81205F0 for ; Mon, 8 Jan 2018 06:29:28 -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 1eYYQZ-0005Yz-5E; Mon, 08 Jan 2018 14:29:27 +0000 From: "Jon Shallow" To: "'Konda, Tirumaleswar Reddy'" , , References: <06a901d37b06$681bf800$3853e800$@jpshallow.com> <06ce01d37b0f$de1d3ba0$9a57b2e0$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93300A0AD4D3@OPEXCLILMA3.corporate.adroot.infra.ftgroup> In-Reply-To: Date: Mon, 8 Jan 2018 14:29:27 -0000 Message-ID: <01ad01d3888d$16b763c0$44262b40$@jpshallow.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_01AE_01D3888D.16B95F90" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQH2IO4WJuCy0mWHgjECz8GquwZNogGntdEDA3dEaSACceR8iQGqELItAfT2e9Siy1eaUA== Content-Language: en-gb Archived-At: Subject: Re: [Dots] DOTS gateway loop handling 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, 08 Jan 2018 14:29:31 -0000 This is a multipart message in MIME format. ------=_NextPart_000_01AE_01D3888D.16B95F90 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Med, =20 Agree with Titu=92s comment. =20 We do however have =93MUST decrement=94 and =93This is an optional = parameter=94. I then we need to modify the MUST component from =20 MUST decrement the hop-limit value by 1 prior to forwarding upstream.=20 =20 To =20 MUST decrement the hop-limit value by 1 prior to forwarding upstream if this parameter exists.=20 =20 I do however think that this should be a required parameter for a DOTS gateway, and to insert if it does not already exist (i.e. insert if = missing, decrement if existing) to prevent the possibility of any looping. =20 Regards =20 Jon From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of Konda, = Tirumaleswar Reddy Sent: 08 January 2018 14:10 To: mohamed.boucadair@orange.com; Jon Shallow; dots@ietf.org Subject: Re: [Dots] DOTS gateway loop handling =20 Hi Med, =20 Looks good, an error response is required to identify the request has = not reached the final DOTS server. =20 Cheers, -Tiru =20 From: mohamed.boucadair@orange.com [mailto:mohamed.boucadair@orange.com] = Sent: Monday, January 8, 2018 7:07 PM To: Konda, Tirumaleswar Reddy ; Jon Shallow ; dots@ietf.org Subject: RE: [Dots] DOTS gateway loop handling =20 Hi Tiru, Jon, all,=20 =20 Please find below a tentative text to cover this issue:=20 =20 =3D=3D hop-limit: This attribute is used to detect and prevent infinite loops. This attribute is typically inserted by a DOTS gateway. =20 Each intermediate DOTS agent involved in the handling of a DOTS message MUST decrement the hop-limit value by 1 prior to forwarding upstream. DOTS messages MUST NOT be forwarded if the value of hop-limit is set to '0' after decrement. Messages that cannot be forwarded because of exhausted hop-limit SHOULD be logged. =20 The initial hop-limit value SHOULD be configurable. If no initial value is explicitly provided, the default initial hop-limit value of 16 (32/64?) MUST be used. =20 Because forwarding errors may occur if inadequate hop-limit values are used, DOTS agents at the boundaries of an administrative domain MAY be instructed to rewrite the value of hop-limit carried in received messages (that is, ignore the value of hop-limit received in a message). =20 This is an optional attribute. =3D=3D=3D =20 Cheers, Med =20 De : Dots [mailto:dots-bounces@ietf.org] De la part de Konda, = Tirumaleswar Reddy Envoy=E9 : vendredi 22 d=E9cembre 2017 11:32 =C0 : Jon Shallow; dots@ietf.org Objet : Re: [Dots] DOTS gateway loop handling =20 Yes, I meant as CBOR and JSON parameters. =20 -Tiru =20 From: Jon Shallow [mailto:supjps-ietf@jpshallow.com]=20 Sent: Friday, December 22, 2017 4:00 PM To: Konda, Tirumaleswar Reddy ; dots@ietf.org Subject: RE: [Dots] DOTS gateway loop handling =20 Hi Tiru, =20 I=92m not sure that we can necessarily support this as a Header, but = certainly as a parameter in the CBOR / JSON =20 I think the most likely scenario for this loop to happen is if DNS is = not working as expected. =20 Regards =20 Jon =20 From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of Konda, = Tirumaleswar Reddy Sent: 22 December 2017 10:24 To: Jon Shallow; dots@ietf.org Subject: Re: [Dots] DOTS gateway loop handling =20 Good point, both drafts can use a mechanism similar to the one discussed = in https://tools.ietf.org/html/rfc7332#section-5 (Max-forwards header). =20 -Tiru =20 From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Jon Shallow Sent: Friday, December 22, 2017 2:53 PM To: dots@ietf.org Subject: [Dots] DOTS gateway loop handling =20 Hi WG, =20 While there never should be a loop in DOTS traffic going via DOTS = gateways, if there is a mis-configuration a request can end up getting bounced = between a set of (not necessarily adjacent) DOTS gateways. =20 We need to make sure that this loop is broken =96 possibly by using a mechanism similar to TTL in IP packets. =20 If we agree that loops need to get broken, this =93feature=94 needs to = get added into both the signal and data channels. =20 Regards =20 Jon ------=_NextPart_000_01AE_01D3888D.16B95F90 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Med,

 

Agree with Titu’s = comment.

 

We do however have = “MUST decrement” and “This is an optional = parameter”.=A0 I then we need to modify the MUST component = from

 

MUST decrement the hop-limit =
value by 1 prior to

      forwarding = upstream. 

 

To

 

MUST decrement the hop-limit value by 1 prior =
to

      forwarding upstream if this = parameter exists. 

 

I do however think that = this should be a required parameter for a DOTS gateway, and to insert if = it does not already exist (i.e. insert if missing, decrement if = existing) to prevent the possibility of any = looping.

 

Regards

 

Jon

From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of = Konda, Tirumaleswar Reddy
Sent: 08 January 2018 = 14:10
To: mohamed.boucadair@orange.com; Jon Shallow; = dots@ietf.org
Subject: Re: [Dots] DOTS gateway loop = handling

 

Hi = Med,

 

Looks good, an error response is = required to identify the request has not reached the final DOTS = server.

 

Cheers,

-Tiru

 

From: mohamed.boucadair@orange.com= [mailto:mohamed.boucadair@ora= nge.com]
Sent: Monday, January 8, 2018 7:07 = PM
To: Konda, Tirumaleswar Reddy <TirumaleswarReddy_Kond= a@McAfee.com>; Jon Shallow <supjps-ietf@jpshallow.com&g= t;; dots@ietf.org
Subject: RE: = [Dots] DOTS gateway loop handling

 

Hi = Tiru, Jon, all,

 

Please find below a tentative text to cover this = issue:

 

=3D=3D

   hop-limit:  This attribute is used to =
detect and prevent infinite
      loops.  This attribute =
is typically inserted by a DOTS =
gateway.
 
      Each intermediate DOTS agent =
involved in the handling of a DOTS
      message MUST decrement the =
hop-limit value by 1 prior to
      forwarding upstream.  =
DOTS messages MUST NOT be forwarded if =
the
      value of hop-limit is set to =
'0' after decrement.  Messages =
that
      cannot be forwarded because =
of exhausted hop-limit SHOULD be
      =
logged.
 
      The initial hop-limit value =
SHOULD be configurable.  If no =
initial
      value is explicitly =
provided, the default initial hop-limit =
value
      of 16 (32/64?) MUST be =
used.
 
      Because forwarding errors =
may occur if inadequate hop-limit =
values
      are used, DOTS agents at the =
boundaries of an administrative
      domain MAY be instructed to =
rewrite the value of hop-limit carried
      in received messages (that =
is, ignore the value of hop-limit
      received in a =
message).
 
      This is an optional =
attribute.

=3D=3D=3D

 

Cheers,

Med

 

De : Dots [mailto:dots-bounces@ietf.org] = De la part de Konda, Tirumaleswar Reddy
Envoy=E9 : = vendredi 22 d=E9cembre 2017 11:32
=C0 : Jon Shallow; dots@ietf.org
Objet : = Re: [Dots] DOTS gateway loop = handling

 

Yes, I meant as CBOR = and JSON parameters.

 

-Tiru

 

From: Jon Shallow [mailto:supjps-ietf@jpshallow.co= m]
Sent: Friday, December 22, 2017 4:00 PM
To: = Konda, Tirumaleswar Reddy <TirumaleswarReddy_Kond= a@McAfee.com>; dots@ietf.org
Subject: RE: = [Dots] DOTS gateway loop handling

 

Hi = Tiru,

 

I’m not sure that = we can necessarily support this as a Header, but certainly as a = parameter in the CBOR / JSON

 

I think the most likely = scenario for this loop to happen is if DNS is not working as = expected.

 

Regards

 

Jon

 

From: Dots [mailto: dots-bounces@ietf.org] On = Behalf Of Konda, Tirumaleswar Reddy
Sent: 22 December 2017 = 10:24
To: Jon Shallow; dots@ietf.org
Subject: Re: = [Dots] DOTS gateway loop handling

 

Good point, both = drafts can use a mechanism similar to the one discussed in https://tools.ietf= .org/html/rfc7332#section-5 (Max-forwards = header).

 

-Tiru

 

From: Dots [mailto:dots-bounces@ietf.org] = On Behalf Of Jon Shallow
Sent: Friday, December 22, = 2017 2:53 PM
To: dots@ietf.org
Subject: = [Dots] DOTS gateway loop handling

 

Hi WG,

 

While there = never should be a loop in DOTS traffic going via DOTS gateways, if there = is a mis-configuration a request can end up getting bounced between a = set of (not necessarily adjacent) DOTS gateways.

 

We need to = make sure that this loop is broken – possibly by using a mechanism = similar to TTL in IP packets.

 

If we agree = that loops need to get broken, this “feature” needs to get = added into both the signal and data channels.

 

Regards

 

Jon

= ------=_NextPart_000_01AE_01D3888D.16B95F90-- From nobody Mon Jan 8 06:32:09 2018 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 089F312895E for ; Mon, 8 Jan 2018 06:32:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.83 X-Spam-Level: X-Spam-Status: No, score=-2.83 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, RCVD_IN_SORBS_WEB=1.5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 Dp8G8W_YRV7m for ; Mon, 8 Jan 2018 06:32:06 -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 53809128D2E for ; Mon, 8 Jan 2018 06:32:06 -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=1515421912; 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:x-microsoft-antispam-message-info: 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=8 AC47Rhgdek8HagFUzKqeMQ2HADmGIckdduL3Igl/w A=; b=qxJNvqfq3O5qrPaOxXCe+ddQpNLDc/I08APXsnKYuU8D Y67HCH2/CRkjBXoIwaIeYh/XYR+kwhLUEtfLVmk2GMnPbxjTRC DDMA67JA8xOmlu2r8Wc07rJKsnnZzbyoZQM/Uoez7ivP+ZTQm8 /TKxyNb0Fnpn8L+5biXWkqaYrMU= Received: from DNVEXAPP1N04.corpzone.internalzone.com (unknown [10.44.48.88]) by DNVWSMAILOUT1.mcafee.com with smtp (TLS: TLSv1/SSLv3,256bits,ECDHE-RSA-AES256-SHA384) id 3e64_3f05_95962c60_899b_466e_9992_54a3bc6f9b05; Mon, 08 Jan 2018 08:31:52 -0600 Received: from DNVEXUSR1N12.corpzone.internalzone.com (10.44.48.85) by DNVEXAPP1N04.corpzone.internalzone.com (10.44.48.88) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Mon, 8 Jan 2018 07:31:37 -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; Mon, 8 Jan 2018 07:31:36 -0700 Received: from NAM02-SN1-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; Mon, 8 Jan 2018 07:31:35 -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.386.5; Mon, 8 Jan 2018 14:31:35 +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.0386.008; Mon, 8 Jan 2018 14:31:34 +0000 From: "Konda, Tirumaleswar Reddy" To: Jon Shallow , "dots@ietf.org" Thread-Topic: [Dots] Filter name clashes Thread-Index: AdOIbWMCs1bdiqx3T82q0wJiBaxkfAAA1I4wAAE1K4AABUC/AA== Date: Mon, 8 Jan 2018 14:31:34 +0000 Message-ID: References: <010a01d3886d$6540ba70$2fc22f50$@jpshallow.com> <014501d38875$8a7968c0$9f6c3a40$@jpshallow.com> In-Reply-To: <014501d38875$8a7968c0$9f6c3a40$@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.16.166] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DM5PR16MB1785; 7:XizbsmRd5m+vZcLuHZdzKgiIfwc6MxFw1UGhHWo2CseJcYbM1otH9mPOOCZBO2fCIvYwr8GLZg0wqk79lrPTDWHxgSgi57TWLCeiN2driqaAnhe+ZxxYc/T/xhPtQzjFsI0IzjfY7oawiG7YfQrGH1bZuQ2QBCFZtzvbz928hdxee01U10HttIFKhzsEVqSCQZsXB6mistDtVF4Jpjyt+kFJr2xwsasf1DcI0S6dY6dCYgUBtJpXHX2PuRnkMoqX x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: a396b5f6-c903-4993-2e94-08d556a48512 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(5600026)(4604075)(3008032)(2017052603307)(7153060)(7193020); SRVR:DM5PR16MB1785; x-ms-traffictypediagnostic: DM5PR16MB1785: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(166708455590820)(21748063052155)(123452027830198); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040470)(2401047)(5005006)(8121501046)(93006095)(93001095)(10201501046)(3002001)(3231023)(944501075)(6041268)(20161123564045)(20161123560045)(20161123562045)(20161123558120)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(6072148)(201708071742011); SRVR:DM5PR16MB1785; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:DM5PR16MB1785; x-forefront-prvs: 054642504A x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39860400002)(396003)(39380400002)(366004)(346002)(376002)(32952001)(199004)(189003)(53546011)(7696005)(8676002)(81156014)(2900100001)(316002)(110136005)(2906002)(2950100002)(6246003)(99286004)(8936002)(68736007)(81166006)(86362001)(3280700002)(3660700001)(25786009)(59450400001)(77096006)(3846002)(6116002)(229853002)(19609705001)(7736002)(6506007)(74316002)(33656002)(106356001)(105586002)(72206003)(53936002)(6436002)(54896002)(5660300001)(102836004)(80792005)(97736004)(76176011)(55016002)(236005)(2501003)(9686003)(6306002)(478600001)(606006)(66066001)(790700001)(966005)(14454004)(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) x-microsoft-antispam-message-info: XJI7sLnsUyQnsG9dCfyXgQYcGBenRQTh9A0SytWg0m2XN52tYip+RA5zfIqe7UuhVwjPlc9kPgoZIsVcLE5z7w== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_DM5PR16MB17883F22F3F5D854EEFF1AD7EA130DM5PR16MB1788namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: a396b5f6-c903-4993-2e94-08d556a48512 X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Jan 2018 14:31:34.8729 (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 <6195> : inlines <6296> : streams <1775468> : uri <2565765> Archived-At: Subject: Re: [Dots] Filter name clashes 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, 08 Jan 2018 14:32:09 -0000 --_000_DM5PR16MB17883F22F3F5D854EEFF1AD7EA130DM5PR16MB1788namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Jon Shallow Sent: Monday, January 8, 2018 5:11 PM To: Konda, Tirumaleswar Reddy ; dots@ie= tf.org Subject: Re: [Dots] Filter name clashes Hi Tiru, Actually no, there is not uniqueness, as I understand it, in the contents o= f "my-filter". As per the current YANG model (-11) augment /ietf-acl:access-lists: +--rw client-identifier* binary 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 module: ietf-access-control-list +--rw access-lists +--rw acl* [acl-type acl-name] | +--rw acl-name string | ... +--rw data-channel:client-identifier* binary +--rw data-channel:dots-acl-order +--rw data-channel:acl-set* [set-name type] +--rw data-channel:set-name -> /ietf-acl:access-lists/acl/a= cl-name +--rw data-channel:type -> /ietf-acl:access-lists/acl/a= cl-type The set-name points to the common acl-name in "/ietf-acl:access-lists/acl/a= cl-name" which will also be "my-filter". [TR] Yes, but the DOTS server can use both "my-filter" and "client-unique" = (or the CUID) to uniquely identify the ACL from a DOTS client. For example,= an DOTS server implementation can combine the "acl-name" + "CUID" values t= o create a unique ACL name. We also do need a way to stop a (rogue) client using "access-lists/acl". [TR] DOTS server will not allow unauthorized and unauthenticated DOTS clien= t to install filtering rules; its already discussed in the draft. -Tiru Regards Jon From: Konda, Tirumaleswar Reddy [mailto:ietf-supjps-TirumaleswarReddy_Konda= @mcafee.com] Sent: 08 January 2018 11:17 To: Jon Shallow; dots@ietf.org Subject: RE: [Dots] Filter name clashes Hi Jon, Even if client-A and client-B use the same ACL name "my-filter", the same A= CL name is created by two different clients with different client identitie= s, the server will not override the ACL rule created by one client with ano= ther client (i.e. one of the reasons for introducing client-unique). The cl= ient must create a ACL rule by using "data-channel:client-unique=3DABC/set-= name=3Dmy-filter/type=3Dxx" and not just use "access-lists/acl". Cheers, -Tiru From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Jon Shallow Sent: Monday, January 8, 2018 4:13 PM To: dots@ietf.org Subject: [Dots] Filter name clashes Hi there, I have realised that we have a serious filter name overwrite issue with the= current data channel spec. Client-A can define "my-filter" by either going directly through "access-li= sts/acl", or "data-channel:client-identifier=3DABC/set-name=3Dmy-filter/typ= e=3Dxx". Client-B can also define "my-filter" - using "access-lists/acl" which will = overwrite Client-A's version, and actually so will "data-channel:client-ide= ntifier=3DDEF/set-name=3Dmy-filter/type=3Dxx" even though client-identifier= =3D will be different from that of Client A. I have posted an issue to the netmod-acl https://github.com/netmod-wg/acl-m= odel/issues asking whether access-lists could be made a grouping or not. I= f this was to happen, we could use "uses access-lists" underneath a client-= identifier. The alternative could be that we build our own higher level access-lists/ac= e/acl etc. tree and then cherry pick the actual "matches" and "actions" tha= t we want for DOTS (which will save a lot of "augments") - for example l2 m= atches make no real sense to DOTS. Regards Jon --_000_DM5PR16MB17883F22F3F5D854EEFF1AD7EA130DM5PR16MB1788namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

From:<= /span> Dots [mailto:dots-bou= nces@ietf.org] On Behalf Of Jon Shallow
Sent: Monday, January 8, 2018 5:11 PM
To: Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@McAfee.com= >; dots@ietf.org
Subject: Re: [Dots] Filter name clashes

 

Hi Tiru= ,

&n= bsp;

Actuall= y no, there is not uniqueness, as I understand it, in the contents of ̶= 0;my-filter”.  As per the current YANG model (-11)

&n= bsp;

  augment /ietf-acl:access-lists:
    +--rw client-identifier*   binary<=
o:p>

  augment /ietf-acl:access-lists:<= /o:p>

    +--rw dots-acl-order<= o:p>

       +--= rw acl-set* [set-name type]

       &n= bsp;  +--rw set-name    -> /ietf-acl:access-list= s/acl/acl-name

       &n= bsp;  +--rw type        -> /= ietf-acl:access-lists/acl/acl-type

 

module: ietf-access-control-list<= /span>

    +--rw access-lists

       +--= rw acl* [acl-type acl-name]

       | = +--rw acl-name    string

       |  = ;...

       +--= rw data-channel:client-identifier*   binary

       +--= rw data-channel:dots-acl-order

       &n= bsp;  +--rw data-channel:acl-set* [set-name type]

       &n= bsp;     +--rw data-channel:set-name  &nb= sp; -> /ietf-acl:access-lists/acl/acl-name

       &n= bsp;     +--rw data-channel:type   &= nbsp;    -> /ietf-acl:access-lists/acl/acl-type

&n= bsp;

The set= -name points to the common acl-name in “/ietf-acl:access-lists/acl/ac= l-name” which will also be “my-filter”.=

 

[TR] Yes, but the DOTS server c= an use both “my-filter” and “client-unique” (or the= CUID) to uniquely identify the ACL from a DOTS client. For example, an DOT= S server implementation can combine the “acl-name” + “= ;CUID” values to create a unique ACL name.

&n= bsp;

We also= do need a way to stop a (rogue) client using “access-lists/acl&#= 8221;.

&nbs= p;

[TR] DOTS= server will not allow unauthorized and unauthenticated DOTS client to inst= all filtering rules; its already discussed in the draft.

&nbs= p;

-Tiru

&n= bsp;

Regards=

&n= bsp;

Jon

From: Konda, Tirumaleswar Reddy [mailto:ietf-supjps-TirumaleswarRedd= y_Konda@mcafee.com]
Sent: 08 January 2018 11:17
To: Jon Shallow; dots@ietf.org<= br> Subject: RE: [Dots] Filter name clashes

 

Hi Jon,

&nbs= p;

Even if c= lient-A and client-B use the same ACL name “my-filter”, the sam= e ACL name is created by two different clients with different client identi= ties, the server will not override the ACL rule created by one client with another client (i.e. one of the reasons for int= roducing client-unique). The client must create a ACL rule by using “= data-channel:client-unique=3DABC/set-name=3Dmy-filter/type=3Dxx” and = not just use “access-lists/acl”.

&nbs= p;

Cheers,

-Tiru

&nbs= p;

From:<= /span> Dots [mailto:dots-bounces@ietf.org] On Behalf Of Jon Shallow
Sent: Monday, January 8, 2018 4:13 PM
To: dots@ietf.org
Subject: [Dots] Filter name clashes

 

Hi ther= e,

&n= bsp;

I have = realised that we have a serious filter name overwrite issue with the curren= t data channel spec.

&n= bsp;

Client-= A can define “my-filter” by either going directly through ̶= 0;access-lists/acl”, or “data-channel:client-identifier=3DABC/s= et-name=3Dmy-filter/type=3Dxx”.

&n= bsp;

Client-= B can also define “my-filter” – using “access-lists= /acl” which will overwrite Client-A’s version, and actually so = will “data-channel:client-identifier=3DDEF/set-name=3Dmy-filter/type= =3Dxx” even though client-identifier=3D will be different from that of Client A.<= /o:p>

&n= bsp;

I have = posted an issue to the netmod-acl https://github.co= m/netmod-wg/acl-model/issues asking whether access-lists could be made = a grouping or not.  If this was to happen, we could use “uses ac= cess-lists” underneath a client-identifier.

&n= bsp;

The alt= ernative could be that we build our own higher level access-lists/ace/acl e= tc. tree and then cherry pick the actual “matches” and “a= ctions” that we want for DOTS (which will save a lot of “augments”) – for example l2 matches make no real sense = to DOTS.

&n= bsp;

Regards=

&n= bsp;

Jon

--_000_DM5PR16MB17883F22F3F5D854EEFF1AD7EA130DM5PR16MB1788namp_-- From nobody Mon Jan 8 06:43:42 2018 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 7D308128D2E for ; Mon, 8 Jan 2018 06:43:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 gDzXBnsEw-8s for ; Mon, 8 Jan 2018 06:43:37 -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 0527F129515 for ; Mon, 8 Jan 2018 06:43:37 -0800 (PST) Received: from opfedar07.francetelecom.fr (unknown [xx.xx.xx.9]) by opfedar24.francetelecom.fr (ESMTP service) with ESMTP id 897D4C0F20; Mon, 8 Jan 2018 15:43:35 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.13]) by opfedar07.francetelecom.fr (ESMTP service) with ESMTP id 62D76C0062; Mon, 8 Jan 2018 15:43:35 +0100 (CET) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM6D.corporate.adroot.infra.ftgroup ([fe80::54f9:a6c3:c013:cbc7%19]) with mapi id 14.03.0361.001; Mon, 8 Jan 2018 15:43:35 +0100 From: To: "Konda, Tirumaleswar Reddy" , "Jon Shallow" , "dots@ietf.org" Thread-Topic: [Dots] DOTS gateway loop handling Thread-Index: AdN7BmUWqzqWF8J/Qkebpl5qeIXshwAB7v7wAABvMAAAAAi8kANdccuAAAEUZ6AAANsEwA== Date: Mon, 8 Jan 2018 14:43:35 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93300A0AD58C@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <06a901d37b06$681bf800$3853e800$@jpshallow.com> <06ce01d37b0f$de1d3ba0$9a57b2e0$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93300A0AD4D3@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.2] Content-Type: multipart/alternative; boundary="_000_787AE7BB302AE849A7480A190F8B93300A0AD58COPEXCLILMA3corp_" MIME-Version: 1.0 Archived-At: Subject: Re: [Dots] DOTS gateway loop handling 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, 08 Jan 2018 14:43:39 -0000 --_000_787AE7BB302AE849A7480A190F8B93300A0AD58COPEXCLILMA3corp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re-, A new error code would be required for this (e.g., 5.xy "hop limit reached"= ). Then, we do need to answer these questions: - What a client is supposed to do when such error is received? - Should the DOTS gateway that is responsible for setting the hop-limit = tracks the error messages so that it can adjust the setting in forthcoming = messages? Or we should be silent about this? Cheers, Med De : Dots [mailto:dots-bounces@ietf.org] De la part de Konda, Tirumaleswar = Reddy Envoy=E9 : lundi 8 janvier 2018 15:10 =C0 : BOUCADAIR Mohamed IMT/OLN; Jon Shallow; dots@ietf.org Objet : Re: [Dots] DOTS gateway loop handling Hi Med, Looks good, an error response is required to identify the request has not r= eached the final DOTS server. Cheers, -Tiru From: mohamed.boucadair@orange.com [ma= ilto:mohamed.boucadair@orange.com] Sent: Monday, January 8, 2018 7:07 PM To: Konda, Tirumaleswar Reddy >; Jon Shallow >; dots@ietf.org Subject: RE: [Dots] DOTS gateway loop handling Hi Tiru, Jon, all, Please find below a tentative text to cover this issue: =3D=3D hop-limit: This attribute is used to detect and prevent infinite loops. This attribute is typically inserted by a DOTS gateway. Each intermediate DOTS agent involved in the handling of a DOTS message MUST decrement the hop-limit value by 1 prior to forwarding upstream. DOTS messages MUST NOT be forwarded if the value of hop-limit is set to '0' after decrement. Messages that cannot be forwarded because of exhausted hop-limit SHOULD be logged. The initial hop-limit value SHOULD be configurable. If no initial value is explicitly provided, the default initial hop-limit value of 16 (32/64?) MUST be used. Because forwarding errors may occur if inadequate hop-limit values are used, DOTS agents at the boundaries of an administrative domain MAY be instructed to rewrite the value of hop-limit carried in received messages (that is, ignore the value of hop-limit received in a message). This is an optional attribute. =3D=3D=3D Cheers, Med De : Dots [mailto:dots-bounces@ietf.org] De la part de Konda, Tirumaleswar = Reddy Envoy=E9 : vendredi 22 d=E9cembre 2017 11:32 =C0 : Jon Shallow; dots@ietf.org Objet : Re: [Dots] DOTS gateway loop handling Yes, I meant as CBOR and JSON parameters. -Tiru From: Jon Shallow [mailto:supjps-ietf@jpshallow.com] Sent: Friday, December 22, 2017 4:00 PM To: Konda, Tirumaleswar Reddy >; dots@ietf.org Subject: RE: [Dots] DOTS gateway loop handling Hi Tiru, I'm not sure that we can necessarily support this as a Header, but certainl= y as a parameter in the CBOR / JSON I think the most likely scenario for this loop to happen is if DNS is not w= orking as expected. Regards Jon From: Dots [mailto: dots-bounces@ietf.org] On= Behalf Of Konda, Tirumaleswar Reddy Sent: 22 December 2017 10:24 To: Jon Shallow; dots@ietf.org Subject: Re: [Dots] DOTS gateway loop handling Good point, both drafts can use a mechanism similar to the one discussed in= https://tools.ietf.org/html/rfc7332#section-5 (Max-forwards header). -Tiru From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Jon Shallow Sent: Friday, December 22, 2017 2:53 PM To: dots@ietf.org Subject: [Dots] DOTS gateway loop handling Hi WG, While there never should be a loop in DOTS traffic going via DOTS gateways,= if there is a mis-configuration a request can end up getting bounced betwe= en a set of (not necessarily adjacent) DOTS gateways. We need to make sure that this loop is broken - possibly by using a mechani= sm similar to TTL in IP packets. If we agree that loops need to get broken, this "feature" needs to get adde= d into both the signal and data channels. Regards Jon --_000_787AE7BB302AE849A7480A190F8B93300A0AD58COPEXCLILMA3corp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Re-,

 

A new error code would be requi= red for this (e.g., 5.xy “hop limit reached”).

 

Then, we do need to answer thes= e questions:

-  = ;  What a client is suppos= ed to do when such error is received?

-  = ;  Should the DOTS gateway= that is responsible for setting the hop-limit tracks the error messages so= that it can adjust the setting in forthcoming messages? Or we should be silent about this?   

 

Cheers,

Med

 

D= ots [mailto:dots-bounces@ietf.org] De la part de Konda, Tirumaleswar Reddy
Envoy=E9 : lundi 8 janvier 2018 15:10
=C0 : BOUCADAIR Mohamed IMT/OLN; Jon Shallow; dots@ietf.org
Objet : Re: [Dots] DOTS gateway loop handling=

 

Hi Med,

 

Looks good, an error response is required to identify the request has= not reached the final DOTS server.

 

Cheers,

-Tiru

 

From: mohamed.boucadair@orange.co= m [mailto:mohamed.bouca= dair@orange.com]
Sent: Monday, January 8, 2018 7:07 PM
To: Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@McAfee.com>; Jon Shallow= <supjps-ietf@jpshallow.com= >; dots@ietf.org
Subject: RE: [Dots] DOTS gateway loop handling

 

Hi Tiru, Jon, all,

 

Please find below a tentative t= ext to cover this issue:

 

=3D=3D

   hop-limit:  This at=
tribute is used to detect and prevent infinite
      loops.=
  This attribute is typically inserted by a DOTS gateway.
 
      Each i=
ntermediate DOTS agent involved in the handling of a DOTS=

      messag=
e MUST decrement the hop-limit value by 1 prior to
      forwar=
ding upstream.  DOTS messages MUST NOT be forwarded if the<=
/span>
      value =
of hop-limit is set to '0' after decrement.  Messages that<=
/span>
      cannot=
 be forwarded because of exhausted hop-limit SHOULD be

      logged=
.


 


      The in=
itial hop-limit value SHOULD be configurable.  If no initial


      value =
is explicitly provided, the default initial hop-limit value


      of 16 =
(32/64?) MUST be used.


 


      Becaus=
e forwarding errors may occur if inadequate hop-limit values


      are us=
ed, DOTS agents at the boundaries of an administrative

      domain=
 MAY be instructed to rewrite the value of hop-limit carried


      in rec=
eived messages (that is, ignore the value of hop-limit

      receiv=
ed in a message).


 


      This i=
s an optional attribute.


=3D=3D=3D


 


Cheers,


Med


 








De : Dots [mailto:dots-bounces@ietf.org]
De la part de Konda, Tirumaleswar Reddy

Envoy=E9 : vendredi 22 d=E9cembre 2017 11:32

=C0 : Jon Shallow; dots@ietf.o=
rg

Objet : Re: [Dots] DOTS gateway loop handling=







 


Yes, I meant as CBOR and JSON parameters.


 


-Tiru


 








From: Jon Shallow [mailto:s=
upjps-ietf@jpshallow.com]


Sent: Friday, December 22, 2017 4:00 PM

To: Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@McAfee.com>;
dots@ietf.org

Subject: RE: [Dots] DOTS gateway loop handling






 


Hi Tiru=
,


&n=
bsp;


I’=
;m not sure that we can necessarily support this as a Header, but certainly=
 as a parameter in the CBOR / JSON


&n=
bsp;


I think=
 the most likely scenario for this loop to happen is if DNS is not working =
as expected.


&n=
bsp;


Regards=



&n=
bsp;


Jon


&n=
bsp;






From:=
 Dots [mailto:
dots-bounces@ietf.org] On B=
ehalf Of
Konda, Tirumaleswar Reddy

Sent: 22 December 2017 10:24

To: Jon Shallow; dots@ietf.org<=
br>
Subject: Re: [Dots] DOTS gateway loop handling






 


Good point, both drafts can use a mechanism similar to the one discus=
sed in
https://tools.iet=
f.org/html/rfc7332#section-5 (Max-forwards header).

 


-Tiru


 








From: Dots [mailto:dots-bounces=
@ietf.org]
On Behalf Of Jon Shallow

Sent: Friday, December 22, 2017 2:53 PM

To: dots@ietf.org

Subject: [Dots] DOTS gateway loop handling






 


Hi WG,


 


While there never should be a l=
oop in DOTS traffic going via DOTS gateways, if there is a mis-configuratio=
n a request can end up getting bounced between a set of (not necessarily ad=
jacent) DOTS gateways.


 


We need to make sure that this =
loop is broken – possibly by using a mechanism similar to TTL in IP p=
ackets.


 


If we agree that loops need to =
get broken, this “feature” needs to get added into both the sig=
nal and data channels.


 


Regards


 


Jon
--_000_787AE7BB302AE849A7480A190F8B93300A0AD58COPEXCLILMA3corp_-- From nobody Mon Jan 8 06:54:05 2018 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 C6C88129C56 for ; Mon, 8 Jan 2018 06:54:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.629 X-Spam-Level: X-Spam-Status: No, score=-2.629 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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, T_RP_MATCHES_RCVD=-0.01, 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 QNyhrtRnhRJl for ; Mon, 8 Jan 2018 06:54:01 -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 CFC8E128896 for ; Mon, 8 Jan 2018 06:54:00 -0800 (PST) Received: from opfednr04.francetelecom.fr (unknown [xx.xx.xx.68]) by opfednr26.francetelecom.fr (ESMTP service) with ESMTP id 253E32081A; Mon, 8 Jan 2018 15:53:59 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.3]) by opfednr04.francetelecom.fr (ESMTP service) with ESMTP id 0917A4006B; Mon, 8 Jan 2018 15:53:59 +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; Mon, 8 Jan 2018 15:53:58 +0100 From: To: Jon Shallow , "'Konda, Tirumaleswar Reddy'" , "dots@ietf.org" Thread-Topic: [Dots] DOTS gateway loop handling Thread-Index: AQH2IO4WJuCy0mWHgjECz8GquwZNogGntdEDA3dEaSACceR8iQGqELItAfT2e9Siy1eaUIAABYKg Date: Mon, 8 Jan 2018 14:53:58 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93300A0AD5C8@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <06a901d37b06$681bf800$3853e800$@jpshallow.com> <06ce01d37b0f$de1d3ba0$9a57b2e0$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93300A0AD4D3@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <01ad01d3888d$16b763c0$44262b40$@jpshallow.com> In-Reply-To: <01ad01d3888d$16b763c0$44262b40$@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.2] Content-Type: multipart/alternative; boundary="_000_787AE7BB302AE849A7480A190F8B93300A0AD5C8OPEXCLILMA3corp_" MIME-Version: 1.0 Archived-At: Subject: Re: [Dots] DOTS gateway loop handling 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, 08 Jan 2018 14:54:04 -0000 --_000_787AE7BB302AE849A7480A190F8B93300A0AD5C8OPEXCLILMA3corp_ 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 : lundi 8 janvier 2018 15:29 =C0 : 'Konda, Tirumaleswar Reddy'; BOUCADAIR Mohamed IMT/OLN; dots@ietf.org Objet : RE: [Dots] DOTS gateway loop handling Hi Med, Agree with Titu's comment. We do however have "MUST decrement" and "This is an optional parameter". I= then we need to modify the MUST component from MUST decrement the hop-limit value by 1 prior to forwarding upstream. To MUST decrement the hop-limit value by 1 prior to forwarding upstream if this parameter exists. [Med] Works for me. I do however think that this should be a required parameter for a DOTS gate= way, and to insert if it does not already exist (i.e. insert if missing, de= crement if existing) to prevent the possibility of any looping. [Med] The current text covers the following cases: - Insert by the gw - Trust + decrement - To not trust + rewrite Would it be helpful of we add this NEW text? "DOTS gateways SHOULD support this attribute" Regards Jon From: Dots [mailto: dots-bounces@ietf.org] On= Behalf Of Konda, Tirumaleswar Reddy Sent: 08 January 2018 14:10 To: mohamed.boucadair@orange.com; Jon = Shallow; dots@ietf.org Subject: Re: [Dots] DOTS gateway loop handling Hi Med, Looks good, an error response is required to identify the request has not r= eached the final DOTS server. Cheers, -Tiru From: mohamed.boucadair@orange.com [ma= ilto:mohamed.boucadair@orange.com] Sent: Monday, January 8, 2018 7:07 PM To: Konda, Tirumaleswar Reddy >; Jon Shallow >; dots@ietf.org Subject: RE: [Dots] DOTS gateway loop handling Hi Tiru, Jon, all, Please find below a tentative text to cover this issue: =3D=3D hop-limit: This attribute is used to detect and prevent infinite loops. This attribute is typically inserted by a DOTS gateway. Each intermediate DOTS agent involved in the handling of a DOTS message MUST decrement the hop-limit value by 1 prior to forwarding upstream. DOTS messages MUST NOT be forwarded if the value of hop-limit is set to '0' after decrement. Messages that cannot be forwarded because of exhausted hop-limit SHOULD be logged. The initial hop-limit value SHOULD be configurable. If no initial value is explicitly provided, the default initial hop-limit value of 16 (32/64?) MUST be used. Because forwarding errors may occur if inadequate hop-limit values are used, DOTS agents at the boundaries of an administrative domain MAY be instructed to rewrite the value of hop-limit carried in received messages (that is, ignore the value of hop-limit received in a message). This is an optional attribute. =3D=3D=3D Cheers, Med De : Dots [mailto:dots-bounces@ietf.org] De la part de Konda, Tirumaleswar = Reddy Envoy=E9 : vendredi 22 d=E9cembre 2017 11:32 =C0 : Jon Shallow; dots@ietf.org Objet : Re: [Dots] DOTS gateway loop handling Yes, I meant as CBOR and JSON parameters. -Tiru From: Jon Shallow [mailto:supjps-ietf@jpshallow.com] Sent: Friday, December 22, 2017 4:00 PM To: Konda, Tirumaleswar Reddy >; dots@ietf.org Subject: RE: [Dots] DOTS gateway loop handling Hi Tiru, I'm not sure that we can necessarily support this as a Header, but certainl= y as a parameter in the CBOR / JSON I think the most likely scenario for this loop to happen is if DNS is not w= orking as expected. Regards Jon From: Dots [mailto: dots-bounces@ietf.org] On= Behalf Of Konda, Tirumaleswar Reddy Sent: 22 December 2017 10:24 To: Jon Shallow; dots@ietf.org Subject: Re: [Dots] DOTS gateway loop handling Good point, both drafts can use a mechanism similar to the one discussed in= https://tools.ietf.org/html/rfc7332#section-5 (Max-forwards header). -Tiru From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Jon Shallow Sent: Friday, December 22, 2017 2:53 PM To: dots@ietf.org Subject: [Dots] DOTS gateway loop handling Hi WG, While there never should be a loop in DOTS traffic going via DOTS gateways,= if there is a mis-configuration a request can end up getting bounced betwe= en a set of (not necessarily adjacent) DOTS gateways. We need to make sure that this loop is broken - possibly by using a mechani= sm similar to TTL in IP packets. If we agree that loops need to get broken, this "feature" needs to get adde= d into both the signal and data channels. Regards Jon --_000_787AE7BB302AE849A7480A190F8B93300A0AD5C8OPEXCLILMA3corp_ 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 : lundi 8 janvier 2018 15:29
=C0 : 'Konda, Tirumaleswar Reddy'; BOUCADAIR Mohamed IMT/OLN; d= ots@ietf.org
Objet : RE: [Dots] DOTS gateway loop handling=

 

Hi Med,=

&n= bsp;

Agree w= ith Titu’s comment.

&n= bsp;

We do h= owever have “MUST decrement” and “This is an optional par= ameter”.  I then we need to modify the MUST component from<= /o:p>

&n= bsp;

MUST decrement the hop-limit value by =
1 prior to

      forwarding up= stream. 

 

To

 

MUST decrement the hop-limit value by =
1 prior to

      forwarding up= stream if this parameter exists. 

 

[Med] Works for me.<= /span>

&n= bsp;

I do ho= wever think that this should be a required parameter for a DOTS gateway, an= d to insert if it does not already exist (i.e. insert if missing, decrement= if existing) to prevent the possibility of any looping.

[Med] The current text covers t= he following cases:

-  = ;  Insert by the gw=

-  = ;  Trust + decrement

-  = ;  To not trust + rewr= ite

&nbs= p;

Would it = be helpful of we add this NEW text?

&nbs= p;

“DO= TS gateways SHOULD support this attribute”

&nbs= p;

&nbs= p;

Regards=

&n= bsp;

Jon

From:= Dots [mailto: dots-bounces@ietf.org] On B= ehalf Of Konda, Tirumaleswar Reddy
Sent: 08 January 2018 14:10
To: mohamed.boucadai= r@orange.com; Jon Shallow; dots@ietf.org
Subject: Re: [Dots] DOTS gateway loop handling

 

Hi Med,

 

Looks good, an error response is required to identify the request has= not reached the final DOTS server.

 

Cheers,

-Tiru

 

From: mohamed.boucadair@orange.co= m [mailto:mohamed.bouca= dair@orange.com]
Sent: Monday, January 8, 2018 7:07 PM
To: Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@McAfee.com>; Jon Shallow= <supjps-ietf@jpshallow.com= >; dots@ietf.org
Subject: RE: [Dots] DOTS gateway loop handling

 

Hi Tiru, Jon, all,

 

Please find below a tentative t= ext to cover this issue:

 

=3D=3D

   hop-limit:  This at=
tribute is used to detect and prevent infinite
      loops.=
  This attribute is typically inserted by a DOTS gateway.
 
      Each i=
ntermediate DOTS agent involved in the handling of a DOTS=

      messag=
e MUST decrement the hop-limit value by 1 prior to
      forwar=
ding upstream.  DOTS messages MUST NOT be forwarded if the<=
/span>
      value =
of hop-limit is set to '0' after decrement.  Messages that<=
/span>
      cannot=
 be forwarded because of exhausted hop-limit SHOULD be

      logged=
.


 


      The in=
itial hop-limit value SHOULD be configurable.  If no initial


      value =
is explicitly provided, the default initial hop-limit value


      of 16 =
(32/64?) MUST be used.


 


      Becaus=
e forwarding errors may occur if inadequate hop-limit values


      are us=
ed, DOTS agents at the boundaries of an administrative

      domain=
 MAY be instructed to rewrite the value of hop-limit carried


      in rec=
eived messages (that is, ignore the value of hop-limit

      receiv=
ed in a message).


 


      This i=
s an optional attribute.


=3D=3D=3D


 


Cheers,


Med


 








De : Dots [mailto:dots-bounces@ietf.org]
De la part de Konda, Tirumaleswar Reddy

Envoy=E9 : vendredi 22 d=E9cembre 2017 11:32

=C0 : Jon Shallow; dots@ietf.o=
rg

Objet : Re: [Dots] DOTS gateway loop handling=







 


Yes, I meant as CBOR and JSON parameters.


 


-Tiru


 








From: Jon Shallow [mailto:s=
upjps-ietf@jpshallow.com]


Sent: Friday, December 22, 2017 4:00 PM

To: Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@McAfee.com>;
dots@ietf.org

Subject: RE: [Dots] DOTS gateway loop handling






 


Hi Tiru=
,


&n=
bsp;


I’=
;m not sure that we can necessarily support this as a Header, but certainly=
 as a parameter in the CBOR / JSON


&n=
bsp;


I think=
 the most likely scenario for this loop to happen is if DNS is not working =
as expected.


&n=
bsp;


Regards=



&n=
bsp;


Jon


&n=
bsp;






From:=
 Dots [mailto:
dots-bounces@ietf.org] On B=
ehalf Of
Konda, Tirumaleswar Reddy

Sent: 22 December 2017 10:24

To: Jon Shallow; dots@ietf.org<=
br>
Subject: Re: [Dots] DOTS gateway loop handling






 


Good point, both drafts can use a mechanism similar to the one discus=
sed in
https://tools.iet=
f.org/html/rfc7332#section-5 (Max-forwards header).

 


-Tiru


 








From: Dots [mailto:dots-bounces=
@ietf.org]
On Behalf Of Jon Shallow

Sent: Friday, December 22, 2017 2:53 PM

To: dots@ietf.org

Subject: [Dots] DOTS gateway loop handling






 


Hi WG,


 


While there never should be a l=
oop in DOTS traffic going via DOTS gateways, if there is a mis-configuratio=
n a request can end up getting bounced between a set of (not necessarily ad=
jacent) DOTS gateways.


 


We need to make sure that this =
loop is broken – possibly by using a mechanism similar to TTL in IP p=
ackets.


 


If we agree that loops need to =
get broken, this “feature” needs to get added into both the sig=
nal and data channels.


 


Regards


 


Jon
--_000_787AE7BB302AE849A7480A190F8B93300A0AD5C8OPEXCLILMA3corp_-- From nobody Mon Jan 8 06:57:42 2018 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 D71E5128896 for ; Mon, 8 Jan 2018 06:57:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.51 X-Spam-Level: X-Spam-Status: No, score=-5.51 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_RP_MATCHES_RCVD=-0.01] 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 GIVExgFUL908 for ; Mon, 8 Jan 2018 06:57:37 -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 D580C127137 for ; Mon, 8 Jan 2018 06:57: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=1515423455; 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:x-microsoft-antispam-message-info: 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=n XmVKrMqQLf7H1Pa0WZ+BxUjmeHc4Uv1rpapVtNaeq Y=; b=Yd3LF+8H34x8hjK67VEhaxIE8UhAtgwXoIfXnmXM+IHR b1Ejx5fKcsxBJ3ZlJ2Knf1K5viIofDB7mDovLUQCtJNM6XbDpr ENZAW8P5piAM2LGWQNl/6WgkrkXCQK6JBfCQVQi+z9T9pa3Wcg TT2p22/r/871hTvFyJz8RlZ4Zmc= Received: from MIVEXAPP1N02.corpzone.internalzone.com (mivexapp1n02.corpzone.internalzone.com [10.48.48.89]) by MIVWSMAILOUT1.mcafee.com with smtp (TLS: TLSv1/SSLv3,256bits,ECDHE-RSA-AES256-SHA384) id 5b8d_a0a0_bd52a50d_2b5e_47ec_b581_d5d9242b0d15; Mon, 08 Jan 2018 08:57:34 -0600 Received: from MIVEXUSR1N04.corpzone.internalzone.com (10.48.48.84) by MIVEXAPP1N02.corpzone.internalzone.com (10.48.48.89) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Mon, 8 Jan 2018 09:57:15 -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, 8 Jan 2018 09:57:14 -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, 8 Jan 2018 09:57:14 -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; Mon, 8 Jan 2018 09:57:04 -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.386.5; Mon, 8 Jan 2018 14:57:04 +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.0386.008; Mon, 8 Jan 2018 14:57:04 +0000 From: "Konda, Tirumaleswar Reddy" To: "mohamed.boucadair@orange.com" , Jon Shallow , "dots@ietf.org" Thread-Topic: [Dots] DOTS gateway loop handling Thread-Index: AdN7BmUWqzqWF8J/Qkebpl5qeIXshwAB7v7wAABvMAAAAAi8kANdccuAAAEUZ6AAANsEwAAAdexA Date: Mon, 8 Jan 2018 14:57:04 +0000 Message-ID: References: <06a901d37b06$681bf800$3853e800$@jpshallow.com> <06ce01d37b0f$de1d3ba0$9a57b2e0$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93300A0AD4D3@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93300A0AD58C@OPEXCLILMA3.corporate.adroot.infra.ftgroup> In-Reply-To: <787AE7BB302AE849A7480A190F8B93300A0AD58C@OPEXCLILMA3.corporate.adroot.infra.ftgroup> 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.16.166] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DM5PR16MB1786; 7:Ck8xmYxDnHTMSiaYpJGiqo6DoWbvUml5roAweAyICe1yj5pyywXKFAEiJHg2znYT/vl3KD1VH3Yuj/SsICPC5C80CqLN8aS6ksBdpC06wjCXEHeYEtkWzWpnAtnrf3kgHuMkzLxDUyEcXuw0ZljjQWINdP2xDdTmHBh9o7PuE3XnTxS3+GWcVvUE9LRpJRgJogURLxOwHpyorj+HlI8dWVTR+sLW0IW8FdOi7psBo6k/wkWXzDsTQr4b/K7GwvXM x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 736d5937-b648-424b-42a1-08d556a8149c x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(5600026)(4604075)(3008032)(2017052603307)(7153060)(7193020); SRVR:DM5PR16MB1786; x-ms-traffictypediagnostic: DM5PR16MB1786: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(18271650672692)(21748063052155)(123452027830198); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040470)(2401047)(8121501046)(5005006)(3231023)(944501075)(3002001)(10201501046)(93006095)(93001095)(6041268)(20161123564045)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123558120)(20161123562045)(6072148)(201708071742011); SRVR:DM5PR16MB1786; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:DM5PR16MB1786; x-forefront-prvs: 054642504A x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(366004)(396003)(39860400002)(346002)(39380400002)(376002)(32952001)(189003)(199004)(3846002)(33656002)(2900100001)(3280700002)(77096006)(3660700001)(2906002)(316002)(790700001)(6116002)(66066001)(6436002)(110136005)(6246003)(53936002)(478600001)(99286004)(59450400001)(97736004)(68736007)(229853002)(25786009)(54896002)(106356001)(6306002)(105586002)(72206003)(80792005)(19609705001)(966005)(2950100002)(236005)(9686003)(53546011)(6506007)(74316002)(2501003)(7736002)(86362001)(93886005)(14454004)(8936002)(55016002)(76176011)(7696005)(102836004)(81156014)(81166006)(5660300001)(8676002)(606006)(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) x-microsoft-antispam-message-info: 6/B+qx9FTCsEJ3U6FSzY3+3JsyIiuwcsojpLWgo1uGy+2bk7iNZyIbItzdTiPm0WZguZWOrlOeEjtS7Ob89ouw== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_DM5PR16MB17882B232BC23E2351ABC4DCEA130DM5PR16MB1788namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 736d5937-b648-424b-42a1-08d556a8149c X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Jan 2018 14:57:04.1353 (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 <6195> : inlines <6296> : streams <1775470> : uri <2565777> Archived-At: Subject: Re: [Dots] DOTS gateway loop handling 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, 08 Jan 2018 14:57:40 -0000 --_000_DM5PR16MB17882B232BC23E2351ABC4DCEA130DM5PR16MB1788namp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hop-limit is required for both DOTS signal and data channels. The default v= alue of 16 looks large enough to indicate looping, DOTS client cannot do an= ything but the on-path DOTS gateway administrators can look the misconfigur= ation problem once the 5.xy error is received. On reflection, the misconfig= uration though looks likely unlikely, it has to happen both at DNS and trus= t anchor database (Is it really required ?) ! -Tiru From: mohamed.boucadair@orange.com [mailto:mohamed.boucadair@orange.com] Sent: Monday, January 8, 2018 8:14 PM To: Konda, Tirumaleswar Reddy ; Jon Sha= llow ; dots@ietf.org Subject: RE: [Dots] DOTS gateway loop handling Re-, A new error code would be required for this (e.g., 5.xy "hop limit reached"= ). Then, we do need to answer these questions: - What a client is supposed to do when such error is received? - Should the DOTS gateway that is responsible for setting the hop-limit = tracks the error messages so that it can adjust the setting in forthcoming = messages? Or we should be silent about this? Cheers, Med De : Dots [mailto:dots-bounces@ietf.org] De la part de Konda, Tirumaleswar = Reddy Envoy=E9 : lundi 8 janvier 2018 15:10 =C0 : BOUCADAIR Mohamed IMT/OLN; Jon Shallow; dots@ietf.org Objet : Re: [Dots] DOTS gateway loop handling Hi Med, Looks good, an error response is required to identify the request has not r= eached the final DOTS server. Cheers, -Tiru From: mohamed.boucadair@orange.com [ma= ilto:mohamed.boucadair@orange.com] Sent: Monday, January 8, 2018 7:07 PM To: Konda, Tirumaleswar Reddy >; Jon Shallow >; dots@ietf.org Subject: RE: [Dots] DOTS gateway loop handling Hi Tiru, Jon, all, Please find below a tentative text to cover this issue: =3D=3D hop-limit: This attribute is used to detect and prevent infinite loops. This attribute is typically inserted by a DOTS gateway. Each intermediate DOTS agent involved in the handling of a DOTS message MUST decrement the hop-limit value by 1 prior to forwarding upstream. DOTS messages MUST NOT be forwarded if the value of hop-limit is set to '0' after decrement. Messages that cannot be forwarded because of exhausted hop-limit SHOULD be logged. The initial hop-limit value SHOULD be configurable. If no initial value is explicitly provided, the default initial hop-limit value of 16 (32/64?) MUST be used. Because forwarding errors may occur if inadequate hop-limit values are used, DOTS agents at the boundaries of an administrative domain MAY be instructed to rewrite the value of hop-limit carried in received messages (that is, ignore the value of hop-limit received in a message). This is an optional attribute. =3D=3D=3D Cheers, Med De : Dots [mailto:dots-bounces@ietf.org] De la part de Konda, Tirumaleswar = Reddy Envoy=E9 : vendredi 22 d=E9cembre 2017 11:32 =C0 : Jon Shallow; dots@ietf.org Objet : Re: [Dots] DOTS gateway loop handling Yes, I meant as CBOR and JSON parameters. -Tiru From: Jon Shallow [mailto:supjps-ietf@jpshallow.com] Sent: Friday, December 22, 2017 4:00 PM To: Konda, Tirumaleswar Reddy >; dots@ietf.org Subject: RE: [Dots] DOTS gateway loop handling Hi Tiru, I'm not sure that we can necessarily support this as a Header, but certainl= y as a parameter in the CBOR / JSON I think the most likely scenario for this loop to happen is if DNS is not w= orking as expected. Regards Jon From: Dots [mailto: dots-bounces@ietf.org] On= Behalf Of Konda, Tirumaleswar Reddy Sent: 22 December 2017 10:24 To: Jon Shallow; dots@ietf.org Subject: Re: [Dots] DOTS gateway loop handling Good point, both drafts can use a mechanism similar to the one discussed in= https://tools.ietf.org/html/rfc7332#section-5 (Max-forwards header). -Tiru From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Jon Shallow Sent: Friday, December 22, 2017 2:53 PM To: dots@ietf.org Subject: [Dots] DOTS gateway loop handling Hi WG, While there never should be a loop in DOTS traffic going via DOTS gateways,= if there is a mis-configuration a request can end up getting bounced betwe= en a set of (not necessarily adjacent) DOTS gateways. We need to make sure that this loop is broken - possibly by using a mechani= sm similar to TTL in IP packets. If we agree that loops need to get broken, this "feature" needs to get adde= d into both the signal and data channels. Regards Jon --_000_DM5PR16MB17882B232BC23E2351ABC4DCEA130DM5PR16MB1788namp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hop-limit= is required for both DOTS signal and data channels. The default value of 16 looks large enough to i= ndicate looping, DOTS client cannot do anything but the on-path DOTS gatewa= y administrators can look the misconfiguration problem once the 5.xy error = is received. On reflection, the misconfiguration though looks likely unlikely, it has to happen both at DNS and trust ancho= r database (Is it really required ?) !

 

-Tiru

 

From:<= /span> mohamed.boucadair@ora= nge.com [mailto:mohamed.boucadair@orange.com]
Sent: Monday, January 8, 2018 8:14 PM
To: Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@McAfee.com= >; Jon Shallow <supjps-ietf@jpshallow.com>; dots@ietf.org
Subject: RE: [Dots] DOTS gateway loop handling

 

Re-,

 

A new error code would be required for this (e= .g., 5.xy “hop limit reached”).

 

Then, we do need to answer these questions:

-    What a client= is supposed to do when such error is received?

-    Should the DO= TS gateway that is responsible for setting the hop-limit tracks the error m= essages so that it can adjust the setting in forthcoming messages? Or we should be silent about this?   

 

Cheers,

Med

 

De : Dots [mailto:d= ots-bounces@ietf.org] De la part de Konda, Tirumaleswar Reddy
Envoy=E9 : lundi 8 janvier 2018 15:10
=C0 : BOUCADAIR Mohamed IMT/OLN; Jon Shallow; dots@ietf.org
Objet : Re: [Dots] DOTS gateway loop handling=

 

Hi Med,

&nbs= p;

Looks goo= d, an error response is required to identify the request has not reached th= e final DOTS server.

&nbs= p;

Cheers,

-Tiru

&nbs= p;

From:<= /span> mohamed.boucadair@orange.co= m [mailto:mohamed.bouca= dair@orange.com]
Sent: Monday, January 8, 2018 7:07 PM
To: Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@McAfee.com>; Jon Shallow= <supjps-ietf@jpshallow.com= >; dots@ietf.org
Subject: RE: [Dots] DOTS gateway loop handling

 

Hi Tiru, Jon, all,

 

Please find below a tentative text to cover th= is issue:

 

=3D=3D

   hop-limit:  This attribute is used=
 to detect and prevent infinite
      loops.  This att=
ribute is typically inserted by a DOTS gateway.
 
      Each intermediate DOT=
S agent involved in the handling of a DOTS
      message MUST decremen=
t the hop-limit value by 1 prior to
      forwarding upstream.&=
nbsp; DOTS messages MUST NOT be forwarded if the
      value of hop-limit is=
 set to '0' after decrement.  Messages that
      cannot be forwarded b=
ecause of exhausted hop-limit SHOULD be
      logged.
 
      The initial hop-limit=
 value SHOULD be configurable.  If no initial
      value is explicitly p=
rovided, the default initial hop-limit value
      of 16 (32/64?) MUST b=
e used.
 
      Because forwarding er=
rors may occur if inadequate hop-limit values
      are used, DOTS agents=
 at the boundaries of an administrative
      domain MAY be instruc=
ted to rewrite the value of hop-limit carried
      in received messages =
(that is, ignore the value of hop-limit
      received in a message=
).
 
      This is an optional a=
ttribute.

=3D=3D=3D

 

Cheers,

Med

 

De : Dots [mailto:dots-bounces@ietf.org] De la part de Konda, Tirumaleswar Reddy
Envoy=E9 : vendredi 22 d=E9cembre 2017 11:32
=C0 : Jon Shallow; dots@ietf.o= rg
Objet : Re: [Dots] DOTS gateway loop handling=

 

Yes, I me= ant as CBOR and JSON parameters.

&nbs= p;

-Tiru

&nbs= p;

From:<= /span> Jon Shallow [mailto:supjps-ietf@jpshallow.com]
Sent: Friday, December 22, 2017 4:00 PM
To: Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@McAfee.com>; dots@ietf.org
Subject: RE: [Dots] DOTS gateway loop handling

 

Hi Tiru= ,

&n= bsp;

I’= ;m not sure that we can necessarily support this as a Header, but certainly= as a parameter in the CBOR / JSON

&n= bsp;

I think= the most likely scenario for this loop to happen is if DNS is not working = as expected.

&n= bsp;

Regards=

&n= bsp;

Jon

&n= bsp;

From: Dots [mailto: dots-bounces@ietf.org] On B= ehalf Of Konda, Tirumaleswar Reddy
Sent: 22 December 2017 10:24
To: Jon Shallow; dots@ietf.org<= br> Subject: Re: [Dots] DOTS gateway loop handling

 

Good poin= t, both drafts can use a mechanism similar to the one discussed in https://tools.iet= f.org/html/rfc7332#section-5 (Max-forwards header).

&nbs= p;

-Tiru

&nbs= p;

From:<= /span> Dots [mailto:dots-bounces@ietf.org] On Behalf Of Jon Shallow
Sent: Friday, December 22, 2017 2:53 PM
To: dots@ietf.org
Subject: [Dots] DOTS gateway loop handling

 

Hi WG,

 

While there never should be a l= oop in DOTS traffic going via DOTS gateways, if there is a mis-configuratio= n a request can end up getting bounced between a set of (not necessarily ad= jacent) DOTS gateways.

 

We need to make sure that this = loop is broken – possibly by using a mechanism similar to TTL in IP p= ackets.

 

If we agree that loops need to = get broken, this “feature” needs to get added into both the sig= nal and data channels.

 

Regards

 

Jon

--_000_DM5PR16MB17882B232BC23E2351ABC4DCEA130DM5PR16MB1788namp_-- From nobody Mon Jan 8 13:13:31 2018 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 9010A12D7F8 for ; Mon, 8 Jan 2018 13:13:29 -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 b8VI_7yyyRqw for ; Mon, 8 Jan 2018 13:13:26 -0800 (PST) Received: from taper.sei.cmu.edu (taper.sei.cmu.edu [147.72.252.16]) (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 11E35124205 for ; Mon, 8 Jan 2018 13:13:25 -0800 (PST) Received: from delp.sei.cmu.edu (delp.sei.cmu.edu [10.64.21.31]) by taper.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id w08LDOZ1027506 for ; Mon, 8 Jan 2018 16:13:24 -0500 DKIM-Filter: OpenDKIM Filter v2.11.0 taper.sei.cmu.edu w08LDOZ1027506 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cert.org; s=yc2bmwvrj62m; t=1515446004; bh=vOMhfDRHmAbPbUkhBj6ZhrJOa2mL9VQeqZOZs+AN45k=; h=From:To:Subject:Date:References:In-Reply-To:From; b=blQJC+Yb2ObvO9iZiLwv8MHWicUIkUbFLwNXs8eWUq7oWc2aEAQX6qxzkS5QpL+mN HDisN6YBopZ1kt5hnK3bHrxlp+dEGnBBov89mCdeYqFtYElEhdqvrxTcvQ2czLBzjx rQTxoG5cm970CcobmzBhGaHqGAsJRFVwDGN1UVsc= Received: from CASCADE.ad.sei.cmu.edu (cascade.ad.sei.cmu.edu [10.64.28.248]) by delp.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id w08LDOQv011760 for ; Mon, 8 Jan 2018 16:13:24 -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, 8 Jan 2018 16:13:24 -0500 From: Roman Danyliw To: "dots@ietf.org" Thread-Topic: Consensus call for early port allocation Thread-Index: AdNwNhVMEAJ7dCaQQ5e1tQiY+SmmtQYjvGHA Date: Mon, 8 Jan 2018 21:13:23 +0000 Message-ID: <359EC4B99E040048A7131E0F4E113AFC013135C058@marathon> References: <359EC4B99E040048A7131E0F4E113AFC0131341BBB@marathon> In-Reply-To: <359EC4B99E040048A7131E0F4E113AFC0131341BBB@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: Re: [Dots] Consensus call for early port allocation 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, 08 Jan 2018 21:13:29 -0000 Hello all! We've been remiss in publically closing this call. Sorry. Thanks to all t= hat responded. =20 Based on the unanimous positive response, a request for this early allocati= on has been sent to our AD per Step #4 of Section 3.1 of RFC7120. Regards, Roman > -----Original Message----- > From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Roman Danyliw > Sent: Friday, December 08, 2017 10:27 AM > To: dots@ietf.org > Subject: [Dots] Consensus call for early port allocation >=20 > Hello WG! >=20 > The authors of the DOTS signal draft (draft-ietf-dots-signal-channel) hav= e > requested an early allocation of a port number from IANA per RFC7120. Se= e > https://www.ietf.org/mail-archive/web/dots/current/msg01730.html. >=20 > To proceed, WG consensus on this allocation is required (per step 3 of > Section 3.1 of RFC7120). Please provide feedback on the mailing list on = this > topic by Friday, December 15. >=20 > Regards, > Roman and Tobias >=20 > _______________________________________________ > Dots mailing list > Dots@ietf.org > https://www.ietf.org/mailman/listinfo/dots From nobody Tue Jan 9 01:38:28 2018 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 7B01D126FB3 for ; Tue, 9 Jan 2018 01:38:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.629 X-Spam-Level: X-Spam-Status: No, score=-2.629 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 ETDxtZTpw_vo for ; Tue, 9 Jan 2018 01:38:26 -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 C50AB126D85 for ; Tue, 9 Jan 2018 01:38:25 -0800 (PST) Received: from opfednr02.francetelecom.fr (unknown [xx.xx.xx.66]) by opfednr25.francetelecom.fr (ESMTP service) with ESMTP id 7E884181452; Tue, 9 Jan 2018 10:38:24 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.27]) by opfednr02.francetelecom.fr (ESMTP service) with ESMTP id 59FE2120074; Tue, 9 Jan 2018 10:38:24 +0100 (CET) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM7C.corporate.adroot.infra.ftgroup ([fe80::8007:17b:c3b4:d68b%19]) with mapi id 14.03.0361.001; Tue, 9 Jan 2018 10:38:24 +0100 From: To: kaname nishizuka , "dots@ietf.org" Thread-Topic: [Dots] I-D Action: draft-ietf-dots-signal-channel-14.txt Thread-Index: AQHTet4+e1SBtvp2XUqJiA0/nltgO6NrZU1A Date: Tue, 9 Jan 2018 09:38:23 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93300A0ADD3F@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <151369676873.7503.16975686179952810632@ietfa.amsl.com> <787AE7BB302AE849A7480A190F8B93300A09ADFB@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <76fa8956-d96b-f900-9125-86e5644895c2@nttv6.jp> In-Reply-To: <76fa8956-d96b-f900-9125-86e5644895c2@nttv6.jp> 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="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [Dots] I-D Action: draft-ietf-dots-signal-channel-14.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, 09 Jan 2018 09:38:27 -0000 SGkgS2FuYW1lLCANCg0KVGhhbmsgeW91IGZvciB0aGUgY2FyZWZ1bCByZWFkaW5nLiANCg0KRml4 ZWQgaW4gbXkgbG9jYWwgY29weS4gDQoNCkNoZWVycywNCk1lZA0KDQo+IC0tLS0tTWVzc2FnZSBk J29yaWdpbmUtLS0tLQ0KPiBEZcKgOiBrYW5hbWUgbmlzaGl6dWthIFttYWlsdG86a2FuYW1lQG50 dHY2LmpwXQ0KPiBFbnZvecOpwqA6IHZlbmRyZWRpIDIyIGTDqWNlbWJyZSAyMDE3IDA1OjM1DQo+ IMOAwqA6IEJPVUNBREFJUiBNb2hhbWVkIElNVC9PTE47IGRvdHNAaWV0Zi5vcmcNCj4gT2JqZXTC oDogUmU6IFtEb3RzXSBJLUQgQWN0aW9uOiBkcmFmdC1pZXRmLWRvdHMtc2lnbmFsLWNoYW5uZWwt MTQudHh0DQo+IA0KPiBzbWFsbCBuaXRzIGluIHRoZSBDQk9SIG1hcHBpbmcgZXhhbXBsZSB3ZXJl IGZvdW5kOg0KPiANCj4gNC40LjEuwqAgUmVxdWVzdCBNaXRpZ2F0aW9uDQo+IEZpZ3VyZSA3OiBQ VVQgZm9yIERPVFMgc2lnbmFsIChDQk9SKQ0KPiANCj4gbGluZSA0OiBjbGllbnQgaWRlbnRpZmll cg0KPiAgwqAxOCAyMMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgICMgdW5zaWduZWQoMzIpDQo+ICDCoGl0IG11c3QgYmU6DQo+ICDCoDE4IDI0 IMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCAj IHVuc2lnbmVkKDM2KQ0KPiANCj4gbGluZSAxMzogdGFyZ2V0LXByZWZpeA0KPiAgwqDCoMKgwqAg MDTCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCAjIHVu c2lnbmVkKDQpDQo+ICDCoGl0IG11c3QgYmU6DQo+ICDCoMKgwqAgMTggMjPCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCAjIHVuc2lnbmVkKDM1KQ0KPiANCj4gcmVn YXJkcywNCj4gS2FuYW1lDQo+IA0KPiBPbiAyMDE3LzEyLzIwIDA6MzQsIG1vaGFtZWQuYm91Y2Fk YWlyQG9yYW5nZS5jb20gd3JvdGU6DQo+ID4gUmUtLA0KPiA+DQo+ID4gVGhpcyB2ZXJzaW9uIGlu dGVncmF0ZXMgdGhlIG91dGNvbWVzIG9mIHRoZSBtYWlsaW5nIGxpc3QgZGlzY3Vzc2lvbiwgaW4N Cj4gcGFydGljdWxhcjoNCj4gPiAtIE11bHRpcGxlIGNsaWVudC1pZCB2YWx1ZXMgZG9lcyBub3Qg bWVhbiBhbnltb3JlIHRoYXQgbXVsdGlwbGUgR1dzIGhhdmUNCj4gaW5qZWN0ZWQgYSB2YWx1ZSBl YWNoLg0KPiA+IC0gSW50cm9kdWNlIGF0dGFjay10aW1lLWNvbmZpZyBhbmQgcGVhY2UtdGltZS1j b25maWcNCj4gPiAtIEFkZCBzb21lIHRleHQgdG8gc3VnZ2VzdCBkb3RzIHNlcnZlcnMgdG8gc2Vu ZCBoZWFydGJlYXRzIGltbWVkaWF0ZWx5DQo+IGFmdGVyIHJlY2VpdmluZyB0aGUgb25lIGZyb20g dGhlIHBlZXIgZG90cyBjbGllbnQuDQo+ID4gLSBSZWZyZXNoaW5nIHRoZSBjb25maWd1cmF0aW9u IG11c3Qgbm90IG9jY3VyIGR1cmluZyBhdHRhY2sgdGltZXMuDQo+ID4NCj4gPiBUaGUgZG9jdW1l bnQgaXMgc3RpbGwgdXNpbmcgY2xpZW50LXNpZGUgYW5kIHNlcnZlci1zaWRlIERPVFMgR1cgdGVy bXMuDQo+IFRoZSB0ZXh0IHdpbGwgYmUgYWxpZ25lZCB3aXRoIHRoZSByZXF1aXJlbWVudHMgSS1E Lg0KPiA+DQo+ID4gSm9uLCBwbGVhc2UgZG91YmxlIGNoZWNrLg0KPiA+DQo+ID4gQWxsLCBwbGVh c2UgcmV2aWV3IGFuZCBzaGFyZSB5b3VyIGNvbW1lbnRzLg0KPiA+DQo+ID4gQ2hlZXJzLA0KPiA+ IE1lZA0KPiA+DQo+ID4+IC0tLS0tTWVzc2FnZSBkJ29yaWdpbmUtLS0tLQ0KPiA+PiBEZcKgOiBE b3RzIFttYWlsdG86ZG90cy1ib3VuY2VzQGlldGYub3JnXSBEZSBsYSBwYXJ0IGRlIGludGVybmV0 LQ0KPiA+PiBkcmFmdHNAaWV0Zi5vcmcNCj4gPj4gRW52b3nDqcKgOiBtYXJkaSAxOSBkw6ljZW1i cmUgMjAxNyAxNjoxOQ0KPiA+PiDDgMKgOiBpLWQtYW5ub3VuY2VAaWV0Zi5vcmcNCj4gPj4gQ2PC oDogZG90c0BpZXRmLm9yZw0KPiA+PiBPYmpldMKgOiBbRG90c10gSS1EIEFjdGlvbjogZHJhZnQt aWV0Zi1kb3RzLXNpZ25hbC1jaGFubmVsLTE0LnR4dA0KPiA+Pg0KPiA+Pg0KPiA+PiBBIE5ldyBJ bnRlcm5ldC1EcmFmdCBpcyBhdmFpbGFibGUgZnJvbSB0aGUgb24tbGluZSBJbnRlcm5ldC1EcmFm dHMNCj4gPj4gZGlyZWN0b3JpZXMuDQo+ID4+IFRoaXMgZHJhZnQgaXMgYSB3b3JrIGl0ZW0gb2Yg dGhlIEREb1MgT3BlbiBUaHJlYXQgU2lnbmFsaW5nIFdHIG9mIHRoZQ0KPiA+PiBJRVRGLg0KPiA+ Pg0KPiA+PiAgICAgICAgICBUaXRsZSAgICAgICAgICAgOiBEaXN0cmlidXRlZCBEZW5pYWwtb2Yt U2VydmljZSBPcGVuIFRocmVhdA0KPiA+PiBTaWduYWxpbmcgKERPVFMpIFNpZ25hbCBDaGFubmVs DQo+ID4+ICAgICAgICAgIEF1dGhvcnMgICAgICAgICA6IFRpcnVtYWxlc3dhciBSZWRkeQ0KPiA+ PiAgICAgICAgICAgICAgICAgICAgICAgICAgICBNb2hhbWVkIEJvdWNhZGFpcg0KPiA+PiAgICAg ICAgICAgICAgICAgICAgICAgICAgICBQcmFzaGFudGggUGF0aWwNCj4gPj4gICAgICAgICAgICAg ICAgICAgICAgICAgICAgQW5kcmV3IE1vcnRlbnNlbg0KPiA+PiAgICAgICAgICAgICAgICAgICAg ICAgICAgICBOaWsgVGVhZ3VlDQo+ID4+IAlGaWxlbmFtZSAgICAgICAgOiBkcmFmdC1pZXRmLWRv dHMtc2lnbmFsLWNoYW5uZWwtMTQudHh0DQo+ID4+IAlQYWdlcyAgICAgICAgICAgOiA4NA0KPiA+ PiAJRGF0ZSAgICAgICAgICAgIDogMjAxNy0xMi0xOQ0KPiA+Pg0KPiA+PiBBYnN0cmFjdDoNCj4g Pj4gICAgIFRoaXMgZG9jdW1lbnQgc3BlY2lmaWVzIHRoZSBET1RTIHNpZ25hbCBjaGFubmVsLCBh IHByb3RvY29sIGZvcg0KPiA+PiAgICAgc2lnbmFsaW5nIHRoZSBuZWVkIGZvciBwcm90ZWN0aW9u IGFnYWluc3QgRGlzdHJpYnV0ZWQgRGVuaWFsLW9mLQ0KPiA+PiAgICAgU2VydmljZSAoRERvUykg YXR0YWNrcyB0byBhIHNlcnZlciBjYXBhYmxlIG9mIGVuYWJsaW5nIG5ldHdvcmsNCj4gPj4gICAg IHRyYWZmaWMgbWl0aWdhdGlvbiBvbiBiZWhhbGYgb2YgdGhlIHJlcXVlc3RpbmcgY2xpZW50Lg0K PiA+Pg0KPiA+PiAgICAgQSBjb21wYW5pb24gZG9jdW1lbnQgZGVmaW5lcyB0aGUgRE9UUyBkYXRh IGNoYW5uZWwsIGEgc2VwYXJhdGUNCj4gPj4gICAgIHJlbGlhYmxlIGNvbW11bmljYXRpb24gbGF5 ZXIgZm9yIERPVFMgbWFuYWdlbWVudCBhbmQgY29uZmlndXJhdGlvbg0KPiA+PiAgICAgcHVycG9z ZXMuDQo+ID4+DQo+ID4+IEVkaXRvcmlhbCBOb3RlIChUbyBiZSByZW1vdmVkIGJ5IFJGQyBFZGl0 b3IpDQo+ID4+DQo+ID4+ICAgICBQbGVhc2UgdXBkYXRlIHRoZXNlIHN0YXRlbWVudHMgd2l0aCB0 aGUgUkZDIG51bWJlciB0byBiZSBhc3NpZ25lZA0KPiB0bw0KPiA+PiAgICAgdGhpcyBkb2N1bWVu dDoNCj4gPj4NCj4gPj4gICAgIG8gICJUaGlzIHZlcnNpb24gb2YgdGhpcyBZQU5HIG1vZHVsZSBp cyBwYXJ0IG9mIFJGQyBYWFhYOyINCj4gPj4NCj4gPj4gICAgIG8gICJSRkMgWFhYWDogRGlzdHJp YnV0ZWQgRGVuaWFsLW9mLVNlcnZpY2UgT3BlbiBUaHJlYXQgU2lnbmFsaW5nDQo+ID4+ICAgICAg ICAoRE9UUykgU2lnbmFsIENoYW5uZWwiOw0KPiA+Pg0KPiA+PiAgICAgbyAgInwgMy4wMCB8IEFs dGVybmF0ZSBzZXJ2ZXIgfCBbUkZDWFhYWF0gfCINCj4gPj4NCj4gPj4gICAgIG8gIHJlZmVyZW5j ZTogUkZDIFhYWFgNCj4gPj4NCj4gPj4gICAgIG8gIFRoaXMgUkZDDQo+ID4+DQo+ID4+ICAgICBQ bGVhc2UgdXBkYXRlIFRCRCBzdGF0ZW1lbnRzIHdpdGggdGhlIHBvcnQgbnVtYmVyIHRvIGJlIGFz c2lnbmVkIHRvDQo+ID4+ICAgICBET1RTIFNpZ25hbCBDaGFubmVsIFByb3RvY29sLg0KPiA+Pg0K PiA+Pg0KPiA+PiBUaGUgSUVURiBkYXRhdHJhY2tlciBzdGF0dXMgcGFnZSBmb3IgdGhpcyBkcmFm dCBpczoNCj4gPj4gaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1k b3RzLXNpZ25hbC1jaGFubmVsLw0KPiA+Pg0KPiA+PiBUaGVyZSBhcmUgYWxzbyBodG1saXplZCB2 ZXJzaW9ucyBhdmFpbGFibGUgYXQ6DQo+ID4+IGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9k cmFmdC1pZXRmLWRvdHMtc2lnbmFsLWNoYW5uZWwtMTQNCj4gPj4gaHR0cHM6Ly9kYXRhdHJhY2tl ci5pZXRmLm9yZy9kb2MvaHRtbC9kcmFmdC1pZXRmLWRvdHMtc2lnbmFsLWNoYW5uZWwtMTQNCj4g Pj4NCj4gPj4gQSBkaWZmIGZyb20gdGhlIHByZXZpb3VzIHZlcnNpb24gaXMgYXZhaWxhYmxlIGF0 Og0KPiA+PiBodHRwczovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtaWV0Zi1kb3Rz LXNpZ25hbC1jaGFubmVsLTE0DQo+ID4+DQo+ID4+DQo+ID4+IFBsZWFzZSBub3RlIHRoYXQgaXQg bWF5IHRha2UgYSBjb3VwbGUgb2YgbWludXRlcyBmcm9tIHRoZSB0aW1lIG9mDQo+ID4+IHN1Ym1p c3Npb24NCj4gPj4gdW50aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWls YWJsZSBhdCB0b29scy5pZXRmLm9yZy4NCj4gPj4NCj4gPj4gSW50ZXJuZXQtRHJhZnRzIGFyZSBh bHNvIGF2YWlsYWJsZSBieSBhbm9ueW1vdXMgRlRQIGF0Og0KPiA+PiBmdHA6Ly9mdHAuaWV0Zi5v cmcvaW50ZXJuZXQtZHJhZnRzLw0KPiA+Pg0KPiA+PiBfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXw0KPiA+PiBEb3RzIG1haWxpbmcgbGlzdA0KPiA+PiBEb3Rz QGlldGYub3JnDQo+ID4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZG90 cw0KPiA+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ ID4gRG90cyBtYWlsaW5nIGxpc3QNCj4gPiBEb3RzQGlldGYub3JnDQo+ID4gaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kb3RzDQoNCg== From nobody Tue Jan 9 02:01:37 2018 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 E847B12D80F for ; Tue, 9 Jan 2018 02:01:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.628 X-Spam-Level: X-Spam-Status: No, score=-2.628 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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, T_RP_MATCHES_RCVD=-0.01, 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 KKn6rdNbI6PY for ; Tue, 9 Jan 2018 02:01:27 -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 AC0C81270A0 for ; Tue, 9 Jan 2018 02:01:13 -0800 (PST) Received: from opfednr00.francetelecom.fr (unknown [xx.xx.xx.64]) by opfednr25.francetelecom.fr (ESMTP service) with ESMTP id 5BD961814C2; Tue, 9 Jan 2018 11:01:12 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.60]) by opfednr00.francetelecom.fr (ESMTP service) with ESMTP id 2BE071A0065; Tue, 9 Jan 2018 11:01:12 +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, 9 Jan 2018 11:01:11 +0100 From: To: "Konda, Tirumaleswar Reddy" , "Jon Shallow" , "dots@ietf.org" Thread-Topic: [Dots] Filter name clashes Thread-Index: AdOIbWMCs1bdiqx3T82q0wJiBaxkfAAA1I4wAC7ZvOA= Date: Tue, 9 Jan 2018 10:01:12 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93300A0ADD8E@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <010a01d3886d$6540ba70$2fc22f50$@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_787AE7BB302AE849A7480A190F8B93300A0ADD8EOPEXCLILMA3corp_" MIME-Version: 1.0 Archived-At: Subject: Re: [Dots] Filter name clashes 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, 09 Jan 2018 10:01:35 -0000 --_000_787AE7BB302AE849A7480A190F8B93300A0ADD8EOPEXCLILMA3corp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi all, Agree with Tiru. ACLs need to be bound to a DOTS client(-domain). Cheers, Med De : Dots [mailto:dots-bounces@ietf.org] De la part de Konda, Tirumaleswar = Reddy Envoy=E9 : lundi 8 janvier 2018 12:17 =C0 : Jon Shallow; dots@ietf.org Objet : Re: [Dots] Filter name clashes Hi Jon, Even if client-A and client-B use the same ACL name "my-filter", the same A= CL name is created by two different clients with different client identitie= s, the server will not override the ACL rule created by one client with ano= ther client (i.e. one of the reasons for introducing client-unique). The cl= ient must create a ACL rule by using "data-channel:client-unique=3DABC/set-= name=3Dmy-filter/type=3Dxx" and not just use "access-lists/acl". Cheers, -Tiru From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Jon Shallow Sent: Monday, January 8, 2018 4:13 PM To: dots@ietf.org Subject: [Dots] Filter name clashes Hi there, I have realised that we have a serious filter name overwrite issue with the= current data channel spec. Client-A can define "my-filter" by either going directly through "access-li= sts/acl", or "data-channel:client-identifier=3DABC/set-name=3Dmy-filter/typ= e=3Dxx". Client-B can also define "my-filter" - using "access-lists/acl" which will = overwrite Client-A's version, and actually so will "data-channel:client-ide= ntifier=3DDEF/set-name=3Dmy-filter/type=3Dxx" even though client-identifier= =3D will be different from that of Client A. I have posted an issue to the netmod-acl https://github.com/netmod-wg/acl-m= odel/issues asking whether access-lists could be made a grouping or not. I= f this was to happen, we could use "uses access-lists" underneath a client-= identifier. The alternative could be that we build our own higher level access-lists/ac= e/acl etc. tree and then cherry pick the actual "matches" and "actions" tha= t we want for DOTS (which will save a lot of "augments") - for example l2 m= atches make no real sense to DOTS. Regards Jon --_000_787AE7BB302AE849A7480A190F8B93300A0ADD8EOPEXCLILMA3corp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi all,

 

Agree with Tiru.

 

ACLs need to be bound to a DOTS= client(-domain).

 

Cheers,

Med

 

De : Dots [mailto:dots-bounces@ietf.= org] De la part de Konda, Tirumaleswar Reddy
Envoy=E9 : lundi 8 janvier 2018 12:17
=C0 : Jon Shallow; dots@ietf.org
Objet : Re: [Dots] Filter name clashes

 

Hi Jon,

 

Even if client-A and client-B use the same ACL name “my-filter&= #8221;, the same ACL name is created by two different clients with differen= t client identities, the server will not override the ACL rule created by one client with another client (i.e. one of the re= asons for introducing client-unique). The client must create a ACL rule by = using “data-channel:client-unique=3DABC/set-name=3Dmy-filter/type=3Dx= x” and not just use “access-lists/acl”.=

 

Cheers,

-Tiru

 

From: Dots [mailto:dots-bounces= @ietf.org] On Behalf Of Jon Shallow
Sent: Monday, January 8, 2018 4:13 PM
To: dots@ietf.org
Subject: [Dots] Filter name clashes

 

Hi ther= e,

&n= bsp;

I have = realised that we have a serious filter name overwrite issue with the curren= t data channel spec.

&n= bsp;

Client-= A can define “my-filter” by either going directly through ̶= 0;access-lists/acl”, or “data-channel:client-identifier=3DABC/s= et-name=3Dmy-filter/type=3Dxx”.

&n= bsp;

Client-= B can also define “my-filter” – using “access-lists= /acl” which will overwrite Client-A’s version, and actually so = will “data-channel:client-identifier=3DDEF/set-name=3Dmy-filter/type= =3Dxx” even though client-identifier=3D will be different from that of Client A.<= /o:p>

&n= bsp;

I have = posted an issue to the netmod-acl https://github.co= m/netmod-wg/acl-model/issues asking whether access-lists could be made = a grouping or not.  If this was to happen, we could use “uses ac= cess-lists” underneath a client-identifier.

&n= bsp;

The alt= ernative could be that we build our own higher level access-lists/ace/acl e= tc. tree and then cherry pick the actual “matches” and “a= ctions” that we want for DOTS (which will save a lot of “augments”) – for example l2 matches make no real sense = to DOTS.

&n= bsp;

Regards=

&n= bsp;

Jon

--_000_787AE7BB302AE849A7480A190F8B93300A0ADD8EOPEXCLILMA3corp_-- From nobody Tue Jan 9 02:29:20 2018 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 91755126D3F for ; Tue, 9 Jan 2018 02:29:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 vOhs5jbTaAeV for ; Tue, 9 Jan 2018 02:29:16 -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 3FD501270AE for ; Tue, 9 Jan 2018 02:29:16 -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 1eYr9d-0006XY-KQ; Tue, 09 Jan 2018 10:29:13 +0000 From: "Jon Shallow" To: "'Konda, Tirumaleswar Reddy'" , , References: <06a901d37b06$681bf800$3853e800$@jpshallow.com> <06ce01d37b0f$de1d3ba0$9a57b2e0$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93300A0AD4D3@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93300A0AD58C@OPEXCLILMA3.corporate.adroot.infra.ftgroup> In-Reply-To: Date: Tue, 9 Jan 2018 10:29:14 -0000 Message-ID: <02b601d38934$b27d7ef0$17787cd0$@jpshallow.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_02B7_01D38934.B2803E10" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQH2IO4WJuCy0mWHgjECz8GquwZNogGntdEDA3dEaSACceR8iQGqELItAfT2e9QCd+0O/gGMidPzoqx6o6A= Content-Language: en-gb Archived-At: Subject: Re: [Dots] DOTS gateway loop handling 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, 09 Jan 2018 10:29:18 -0000 This is a multipart message in MIME format. ------=_NextPart_000_02B7_01D38934.B2803E10 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable While I agree that this =93loop=94 is very unlikely to occur, I still = think that we have to defend against this edge case which could be used as an = attack vector against DOTS. =20 In answer to Med=92s questions. =20 1) I think a default hop count of 16 is fine, but could make it 32 = so that it is larger than any likely hop count. If it is to be = configurable, then it should not be less than 16. =20 2) If a client gets back an error, there is a either a loop, or the =93hop-limit count=94 is insufficient. The client should record / = report the failure =96 and possibly the DOTS gateway that inserted the first = occurrence of hop-limit as there is either a network issue, or a misconfiguration issue. =20 3) I do not think that the inserting DOTS gateway should auto = change the =93hop-limit count=94 based on a failure =96 as there could be an = upstream loop. =20 If there is a loop failure, the DOTS client will not get back a response (using UDP or TCP) if no diagnostic message is sent back, so will have = to handle the =93no response=94 condition anyway. Having a diagnostic 5.xy = is a helpful addition. =20 Regards =20 Jon =20 From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of Konda, = Tirumaleswar Reddy Sent: 08 January 2018 14:57 To: mohamed.boucadair@orange.com; Jon Shallow; dots@ietf.org Subject: Re: [Dots] DOTS gateway loop handling =20 Hop-limit is required for both DOTS signal and data channels. The = default value of 16 looks large enough to indicate looping, DOTS client cannot = do anything but the on-path DOTS gateway administrators can look the misconfiguration problem once the 5.xy error is received. On reflection, = the misconfiguration though looks likely unlikely, it has to happen both at = DNS and trust anchor database (Is it really required ?) ! =20 -Tiru =20 From: mohamed.boucadair@orange.com [mailto:mohamed.boucadair@orange.com] = Sent: Monday, January 8, 2018 8:14 PM To: Konda, Tirumaleswar Reddy ; Jon Shallow ; dots@ietf.org Subject: RE: [Dots] DOTS gateway loop handling =20 Re-, =20 A new error code would be required for this (e.g., 5.xy =93hop limit reached=94).=20 =20 Then, we do need to answer these questions:=20 - What a client is supposed to do when such error is received?=20 - Should the DOTS gateway that is responsible for setting the = hop-limit tracks the error messages so that it can adjust the setting in = forthcoming messages? Or we should be silent about this? =20 =20 Cheers, Med =20 De : Dots [mailto:dots-bounces@ietf.org] De la part de Konda, = Tirumaleswar Reddy Envoy=E9 : lundi 8 janvier 2018 15:10 =C0 : BOUCADAIR Mohamed IMT/OLN; Jon Shallow; dots@ietf.org Objet : Re: [Dots] DOTS gateway loop handling =20 Hi Med, =20 Looks good, an error response is required to identify the request has = not reached the final DOTS server. =20 Cheers, -Tiru =20 From: mohamed.boucadair@orange.com [mailto:mohamed.boucadair@orange.com] = Sent: Monday, January 8, 2018 7:07 PM To: Konda, Tirumaleswar Reddy ; Jon Shallow ; dots@ietf.org Subject: RE: [Dots] DOTS gateway loop handling =20 Hi Tiru, Jon, all,=20 =20 Please find below a tentative text to cover this issue:=20 =20 =3D=3D hop-limit: This attribute is used to detect and prevent infinite loops. This attribute is typically inserted by a DOTS gateway. =20 Each intermediate DOTS agent involved in the handling of a DOTS message MUST decrement the hop-limit value by 1 prior to forwarding upstream. DOTS messages MUST NOT be forwarded if the value of hop-limit is set to '0' after decrement. Messages that cannot be forwarded because of exhausted hop-limit SHOULD be logged. =20 The initial hop-limit value SHOULD be configurable. If no initial value is explicitly provided, the default initial hop-limit value of 16 (32/64?) MUST be used. =20 Because forwarding errors may occur if inadequate hop-limit values are used, DOTS agents at the boundaries of an administrative domain MAY be instructed to rewrite the value of hop-limit carried in received messages (that is, ignore the value of hop-limit received in a message). =20 This is an optional attribute. =3D=3D=3D =20 Cheers, Med =20 De : Dots [mailto:dots-bounces@ietf.org] De la part de Konda, = Tirumaleswar Reddy Envoy=E9 : vendredi 22 d=E9cembre 2017 11:32 =C0 : Jon Shallow; dots@ietf.org Objet : Re: [Dots] DOTS gateway loop handling =20 Yes, I meant as CBOR and JSON parameters. =20 -Tiru =20 From: Jon Shallow [mailto:supjps-ietf@jpshallow.com]=20 Sent: Friday, December 22, 2017 4:00 PM To: Konda, Tirumaleswar Reddy ; dots@ietf.org Subject: RE: [Dots] DOTS gateway loop handling =20 Hi Tiru, =20 I=92m not sure that we can necessarily support this as a Header, but = certainly as a parameter in the CBOR / JSON =20 I think the most likely scenario for this loop to happen is if DNS is = not working as expected. =20 Regards =20 Jon =20 From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of Konda, = Tirumaleswar Reddy Sent: 22 December 2017 10:24 To: Jon Shallow; dots@ietf.org Subject: Re: [Dots] DOTS gateway loop handling =20 Good point, both drafts can use a mechanism similar to the one discussed = in https://tools.ietf.org/html/rfc7332#section-5 (Max-forwards header). =20 -Tiru =20 From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Jon Shallow Sent: Friday, December 22, 2017 2:53 PM To: dots@ietf.org Subject: [Dots] DOTS gateway loop handling =20 Hi WG, =20 While there never should be a loop in DOTS traffic going via DOTS = gateways, if there is a mis-configuration a request can end up getting bounced = between a set of (not necessarily adjacent) DOTS gateways. =20 We need to make sure that this loop is broken =96 possibly by using a mechanism similar to TTL in IP packets. =20 If we agree that loops need to get broken, this =93feature=94 needs to = get added into both the signal and data channels. =20 Regards =20 Jon ------=_NextPart_000_02B7_01D38934.B2803E10 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

While I agree that this “loop” is = very unlikely to occur, I still think that we have to defend against = this edge case which could be used as an attack vector against = DOTS.

 

In answer to Med’s = questions.

 

1)      = I think a = default hop count of 16 is fine, but could make it 32 so that it is = larger than any likely hop count.=A0 If it is to be configurable, then = it should not be less than 16.

 

2)      = If a client = gets back an error, there is a either a loop, or the “hop-limit = count” is insufficient.=A0 The client should record / report the = failure – and possibly the DOTS gateway that inserted the first = occurrence of hop-limit as there is either a network issue, or a = misconfiguration issue.

 

3)      = I do not = think that the inserting DOTS gateway should auto change the = “hop-limit count” based on a failure – as there could = be an upstream loop.

 

If there is a loop = failure, the DOTS client will not get back a response (using UDP or TCP) = if no diagnostic message is sent back, so will have to handle the = “no response” condition anyway. =A0Having a diagnostic 5.xy = is a helpful addition.

 

Regards

 

Jon

 

From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of = Konda, Tirumaleswar Reddy
Sent: 08 January 2018 = 14:57
To: mohamed.boucadair@orange.com; Jon Shallow; = dots@ietf.org
Subject: Re: [Dots] DOTS gateway loop = handling

 

Hop-limit is required = for both DOTS signal and data channels. The = default value of 16 looks large enough to indicate looping, DOTS client = cannot do anything but the on-path DOTS gateway administrators can look = the misconfiguration problem once the 5.xy error is received. On = reflection, the misconfiguration though looks likely unlikely, it has to = happen both at DNS and trust anchor database (Is it really required ?) = !

 

-Tiru

 

From: mohamed.boucadair@orange.com= [mailto:mohamed.boucadair@ora= nge.com]
Sent: Monday, January 8, 2018 8:14 = PM
To: Konda, Tirumaleswar Reddy <TirumaleswarReddy_Kond= a@McAfee.com>; Jon Shallow <supjps-ietf@jpshallow.com&g= t;; dots@ietf.org
Subject: RE: = [Dots] DOTS gateway loop handling

 

Re-,

 

A new error code would be required for this (e.g., = 5.xy “hop limit reached”).

 

Then, we do need to answer these questions: =

-    What a = client is supposed to do when such error is received? =

-    Should = the DOTS gateway that is responsible for setting the hop-limit tracks = the error messages so that it can adjust the setting in forthcoming = messages? Or we should be silent about this? =   

 

Cheers,

Med

 

De : Dots [mailto:dots-bounces@ietf.org] = De la part de Konda, Tirumaleswar Reddy
Envoy=E9 : = lundi 8 janvier 2018 15:10
=C0 : BOUCADAIR Mohamed IMT/OLN; Jon = Shallow; dots@ietf.org
Objet : = Re: [Dots] DOTS gateway loop = handling

 

Hi = Med,

 

Looks good, an error response is = required to identify the request has not reached the final DOTS = server.

 

Cheers,

-Tiru

 

From: mohamed.boucadair@orange.com= [mailto:mohamed.boucadair@ora= nge.com]
Sent: Monday, January 8, 2018 7:07 = PM
To: Konda, Tirumaleswar Reddy <TirumaleswarReddy_Kond= a@McAfee.com>; Jon Shallow <supjps-ietf@jpshallow.com&g= t;; dots@ietf.org
Subject: RE: = [Dots] DOTS gateway loop handling

 

Hi = Tiru, Jon, all,

 

Please find below a tentative text to cover this = issue:

 

=3D=3D

   hop-limit:  This =
attribute is used to detect and prevent =
infinite
      =
loops.  This attribute is typically inserted by a DOTS =
gateway.
 
      Each =
intermediate DOTS agent involved in the handling of a =
DOTS
      message =
MUST decrement the hop-limit value by 1 prior =
to
      forwarding =
upstream.  DOTS messages MUST NOT be forwarded if =
the
      value of =
hop-limit is set to '0' after decrement.  Messages =
that
      cannot be =
forwarded because of exhausted hop-limit SHOULD =
be
      =
logged.
 
      The initial =
hop-limit value SHOULD be configurable.  If no =
initial
      value is =
explicitly provided, the default initial hop-limit =
value
      of 16 =
(32/64?) MUST be used.
 
      Because =
forwarding errors may occur if inadequate hop-limit =
values
      are used, =
DOTS agents at the boundaries of an =
administrative
      domain MAY =
be instructed to rewrite the value of hop-limit =
carried
      in received =
messages (that is, ignore the value of =
hop-limit
      received in =
a message).
 
      This is an =
optional attribute.

=3D=3D=3D

 

Cheers,

Med

 

De : Dots [mailto:dots-bounces@ietf.org] = De la part de Konda, Tirumaleswar Reddy
Envoy=E9 : = vendredi 22 d=E9cembre 2017 11:32
=C0 : Jon Shallow; dots@ietf.org
Objet : = Re: [Dots] DOTS gateway loop = handling

 

Yes, I meant as CBOR = and JSON parameters.

 

-Tiru

 

From: Jon Shallow [mailto:supjps-ietf@jpshallow.co= m]
Sent: Friday, December 22, 2017 4:00 PM
To: = Konda, Tirumaleswar Reddy <TirumaleswarReddy_Kond= a@McAfee.com>; dots@ietf.org
Subject: RE: = [Dots] DOTS gateway loop handling

 

Hi = Tiru,

 

I’m not sure that = we can necessarily support this as a Header, but certainly as a = parameter in the CBOR / JSON

 

I think the most likely = scenario for this loop to happen is if DNS is not working as = expected.

 

Regards

 

Jon

 

From: Dots [mailto: dots-bounces@ietf.org] On = Behalf Of Konda, Tirumaleswar Reddy
Sent: 22 December 2017 = 10:24
To: Jon Shallow; dots@ietf.org
Subject: Re: = [Dots] DOTS gateway loop handling

 

Good point, both = drafts can use a mechanism similar to the one discussed in https://tools.ietf= .org/html/rfc7332#section-5 (Max-forwards = header).

 

-Tiru

 

From: Dots [mailto:dots-bounces@ietf.org] = On Behalf Of Jon Shallow
Sent: Friday, December 22, = 2017 2:53 PM
To: dots@ietf.org
Subject: = [Dots] DOTS gateway loop handling

 

Hi WG,

 

While there = never should be a loop in DOTS traffic going via DOTS gateways, if there = is a mis-configuration a request can end up getting bounced between a = set of (not necessarily adjacent) DOTS gateways.

 

We need to = make sure that this loop is broken – possibly by using a mechanism = similar to TTL in IP packets.

 

If we agree = that loops need to get broken, this “feature” needs to get = added into both the signal and data channels.

 

Regards

 

Jon

<= /div> ------=_NextPart_000_02B7_01D38934.B2803E10-- From nobody Tue Jan 9 04:34:44 2018 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 15B7912D832 for ; Tue, 9 Jan 2018 04:34:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.628 X-Spam-Level: X-Spam-Status: No, score=-2.628 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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, T_RP_MATCHES_RCVD=-0.01, 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 KLT4j20_qRp8 for ; Tue, 9 Jan 2018 04:34:39 -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 C3C1512D7E8 for ; Tue, 9 Jan 2018 04:34:38 -0800 (PST) Received: from opfedar00.francetelecom.fr (unknown [xx.xx.xx.11]) by opfedar25.francetelecom.fr (ESMTP service) with ESMTP id ECE2B121532; Tue, 9 Jan 2018 13:34:36 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.32]) by opfedar00.francetelecom.fr (ESMTP service) with ESMTP id C59A9180063; Tue, 9 Jan 2018 13:34:36 +0100 (CET) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM32.corporate.adroot.infra.ftgroup ([fe80::8924:188:2124:a046%19]) with mapi id 14.03.0361.001; Tue, 9 Jan 2018 13:34:36 +0100 From: To: Jon Shallow , "'Konda, Tirumaleswar Reddy'" , "dots@ietf.org" Thread-Topic: [Dots] DOTS gateway loop handling Thread-Index: AQH2IO4WJuCy0mWHgjECz8GquwZNogGntdEDA3dEaSACceR8iQGqELItAfT2e9QCd+0O/gGMidPzoqx6o6CAAA4acA== Date: Tue, 9 Jan 2018 12:34:36 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93300A0ADFDC@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <06a901d37b06$681bf800$3853e800$@jpshallow.com> <06ce01d37b0f$de1d3ba0$9a57b2e0$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93300A0AD4D3@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93300A0AD58C@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <02b601d38934$b27d7ef0$17787cd0$@jpshallow.com> In-Reply-To: <02b601d38934$b27d7ef0$17787cd0$@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_787AE7BB302AE849A7480A190F8B93300A0ADFDCOPEXCLILMA3corp_" MIME-Version: 1.0 Archived-At: Subject: Re: [Dots] DOTS gateway loop handling 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, 09 Jan 2018 12:34:41 -0000 --_000_787AE7BB302AE849A7480A190F8B93300A0ADFDCOPEXCLILMA3corp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Jon, I don't think that we can mandate a minimum value. It is up to entity deplo= ying a GW to decide whether the default value or another one (even less tha= n 16) has to be used. We should not interfere with deployment decisions, IM= HO. Cheers, Med De : Jon Shallow [mailto:supjps-ietf@jpshallow.com] Envoy=E9 : mardi 9 janvier 2018 11:29 =C0 : 'Konda, Tirumaleswar Reddy'; BOUCADAIR Mohamed IMT/OLN; dots@ietf.org Objet : RE: [Dots] DOTS gateway loop handling While I agree that this "loop" is very unlikely to occur, I still think tha= t we have to defend against this edge case which could be used as an attack= vector against DOTS. In answer to Med's questions. 1) I think a default hop count of 16 is fine, but could make it 32 so = that it is larger than any likely hop count. If it is to be configurable, = then it should not be less than 16. 2) If a client gets back an error, there is a either a loop, or the "h= op-limit count" is insufficient. The client should record / report the fai= lure - and possibly the DOTS gateway that inserted the first occurrence of = hop-limit as there is either a network issue, or a misconfiguration issue. 3) I do not think that the inserting DOTS gateway should auto change t= he "hop-limit count" based on a failure - as there could be an upstream loo= p. If there is a loop failure, the DOTS client will not get back a response (u= sing UDP or TCP) if no diagnostic message is sent back, so will have to han= dle the "no response" condition anyway. Having a diagnostic 5.xy is a help= ful addition. Regards Jon From: Dots [mailto: dots-bounces@ietf.org] On= Behalf Of Konda, Tirumaleswar Reddy Sent: 08 January 2018 14:57 To: mohamed.boucadair@orange.com; Jon = Shallow; dots@ietf.org Subject: Re: [Dots] DOTS gateway loop handling Hop-limit is required for both DOTS signal and data channels. The default v= alue of 16 looks large enough to indicate looping, DOTS client cannot do an= ything but the on-path DOTS gateway administrators can look the misconfigur= ation problem once the 5.xy error is received. On reflection, the misconfig= uration though looks likely unlikely, it has to happen both at DNS and trus= t anchor database (Is it really required ?) ! -Tiru From: mohamed.boucadair@orange.com [ma= ilto:mohamed.boucadair@orange.com] Sent: Monday, January 8, 2018 8:14 PM To: Konda, Tirumaleswar Reddy >; Jon Shallow >; dots@ietf.org Subject: RE: [Dots] DOTS gateway loop handling Re-, A new error code would be required for this (e.g., 5.xy "hop limit reached"= ). Then, we do need to answer these questions: - What a client is supposed to do when such error is received? - Should the DOTS gateway that is responsible for setting the hop-limit = tracks the error messages so that it can adjust the setting in forthcoming = messages? Or we should be silent about this? Cheers, Med De : Dots [mailto:dots-bounces@ietf.org] De la part de Konda, Tirumaleswar = Reddy Envoy=E9 : lundi 8 janvier 2018 15:10 =C0 : BOUCADAIR Mohamed IMT/OLN; Jon Shallow; dots@ietf.org Objet : Re: [Dots] DOTS gateway loop handling Hi Med, Looks good, an error response is required to identify the request has not r= eached the final DOTS server. Cheers, -Tiru From: mohamed.boucadair@orange.com [ma= ilto:mohamed.boucadair@orange.com] Sent: Monday, January 8, 2018 7:07 PM To: Konda, Tirumaleswar Reddy >; Jon Shallow >; dots@ietf.org Subject: RE: [Dots] DOTS gateway loop handling Hi Tiru, Jon, all, Please find below a tentative text to cover this issue: =3D=3D hop-limit: This attribute is used to detect and prevent infinite loops. This attribute is typically inserted by a DOTS gateway. Each intermediate DOTS agent involved in the handling of a DOTS message MUST decrement the hop-limit value by 1 prior to forwarding upstream. DOTS messages MUST NOT be forwarded if the value of hop-limit is set to '0' after decrement. Messages that cannot be forwarded because of exhausted hop-limit SHOULD be logged. The initial hop-limit value SHOULD be configurable. If no initial value is explicitly provided, the default initial hop-limit value of 16 (32/64?) MUST be used. Because forwarding errors may occur if inadequate hop-limit values are used, DOTS agents at the boundaries of an administrative domain MAY be instructed to rewrite the value of hop-limit carried in received messages (that is, ignore the value of hop-limit received in a message). This is an optional attribute. =3D=3D=3D Cheers, Med De : Dots [mailto:dots-bounces@ietf.org] De la part de Konda, Tirumaleswar = Reddy Envoy=E9 : vendredi 22 d=E9cembre 2017 11:32 =C0 : Jon Shallow; dots@ietf.org Objet : Re: [Dots] DOTS gateway loop handling Yes, I meant as CBOR and JSON parameters. -Tiru From: Jon Shallow [mailto:supjps-ietf@jpshallow.com] Sent: Friday, December 22, 2017 4:00 PM To: Konda, Tirumaleswar Reddy >; dots@ietf.org Subject: RE: [Dots] DOTS gateway loop handling Hi Tiru, I'm not sure that we can necessarily support this as a Header, but certainl= y as a parameter in the CBOR / JSON I think the most likely scenario for this loop to happen is if DNS is not w= orking as expected. Regards Jon From: Dots [mailto: dots-bounces@ietf.org] On= Behalf Of Konda, Tirumaleswar Reddy Sent: 22 December 2017 10:24 To: Jon Shallow; dots@ietf.org Subject: Re: [Dots] DOTS gateway loop handling Good point, both drafts can use a mechanism similar to the one discussed in= https://tools.ietf.org/html/rfc7332#section-5 (Max-forwards header). -Tiru From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Jon Shallow Sent: Friday, December 22, 2017 2:53 PM To: dots@ietf.org Subject: [Dots] DOTS gateway loop handling Hi WG, While there never should be a loop in DOTS traffic going via DOTS gateways,= if there is a mis-configuration a request can end up getting bounced betwe= en a set of (not necessarily adjacent) DOTS gateways. We need to make sure that this loop is broken - possibly by using a mechani= sm similar to TTL in IP packets. If we agree that loops need to get broken, this "feature" needs to get adde= d into both the signal and data channels. Regards Jon --_000_787AE7BB302AE849A7480A190F8B93300A0ADFDCOPEXCLILMA3corp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Jon,

 

I don’t think that we can= mandate a minimum value. It is up to entity deploying a GW to decide wheth= er the default value or another one (even less than 16) has to be used. We should not interfere with deployment decisions, IMHO. &= nbsp;

 

Cheers,

Med

 

De : Jon Shallow [mailto:supjps-ietf= @jpshallow.com]
Envoy=E9 : mardi 9 janvier 2018 11:29
=C0 : 'Konda, Tirumaleswar Reddy'; BOUCADAIR Mohamed IMT/OLN; d= ots@ietf.org
Objet : RE: [Dots] DOTS gateway loop handling=

 

While I= agree that this “loop” is very unlikely to occur, I still thin= k that we have to defend against this edge case which could be used as an a= ttack vector against DOTS.

&n= bsp;

In answ= er to Med’s questions.

&n= bsp;

= 1)      I think a default hop count of 16 is fine, but could make it 32 so that it= is larger than any likely hop count.  If it is to be configurable, th= en it should not be less than 16.

&n= bsp;

= 2)      If a client gets back an error, there is a either a loop, or the “ho= p-limit count” is insufficient.  The client should record / repo= rt the failure – and possibly the DOTS gateway that inserted the first occurrence of hop-limit as there is either a network issue, or a= misconfiguration issue.

&n= bsp;

= 3)      I do not think that the inserting DOTS gateway should auto change the R= 20;hop-limit count” based on a failure – as there could be an u= pstream loop.

&n= bsp;

If ther= e is a loop failure, the DOTS client will not get back a response (using UD= P or TCP) if no diagnostic message is sent back, so will have to handle the= “no response” condition anyway.  Having a diagnostic 5.xy is a helpful addition.

&n= bsp;

Regards=

&n= bsp;

Jon

&n= bsp;

From:= Dots [mailto: dots-bounces@ietf.org] On B= ehalf Of Konda, Tirumaleswar Reddy
Sent: 08 January 2018 14:57
To: mohamed.boucadai= r@orange.com; Jon Shallow; dots@ietf.org
Subject: Re: [Dots] DOTS gateway loop handling

 

Hop-limit is required for both DOTS signal and data channels. The default value of 16 looks large enough to i= ndicate looping, DOTS client cannot do anything but the on-path DOTS gatewa= y administrators can look the misconfiguration problem once the 5.xy error = is received. On reflection, the misconfiguration though looks likely unlikely, it has to happen both at DNS and trust ancho= r database (Is it really required ?) !

 

-Tiru

 

From: mohamed.boucadair@orange.co= m [mailto:mohamed.bouca= dair@orange.com]
Sent: Monday, January 8, 2018 8:14 PM
To: Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@McAfee.com>; Jon Shallow= <supjps-ietf@jpshallow.com= >; dots@ietf.org
Subject: RE: [Dots] DOTS gateway loop handling

 

Re-,

 

A new error code would be requi= red for this (e.g., 5.xy “hop limit reached”).

 

Then, we do need to answer thes= e questions:

-    What a client is supposed to do when such error= is received?

-    Should the DOTS gateway that is responsible for= setting the hop-limit tracks the error messages so that it can adjust the = setting in forthcoming messages? Or we should be silent about this?   

 

Cheers,

Med

 

 

Hi Med,

 

Looks good, an error response is required to identify the request has= not reached the final DOTS server.

 

Cheers,

-Tiru

 

From: mohamed.boucadair@orange.co= m [mailto:mohamed.bouca= dair@orange.com]
Sent: Monday, January 8, 2018 7:07 PM
To: Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@McAfee.com>; Jon Shallow= <supjps-ietf@jpshallow.com= >; dots@ietf.org
Subject: RE: [Dots] DOTS gateway loop handling

 

Hi Tiru, Jon, all,

 

Please find below a tentative t= ext to cover this issue:

 

=3D=3D

   hop-limit:  This at=
tribute is used to detect and prevent infinite
      loops.=
  This attribute is typically inserted by a DOTS gateway.
 
      Each i=
ntermediate DOTS agent involved in the handling of a DOTS=

      messag=
e MUST decrement the hop-limit value by 1 prior to
      forwar=
ding upstream.  DOTS messages MUST NOT be forwarded if the<=
/span>
      value =
of hop-limit is set to '0' after decrement.  Messages that<=
/span>
      cannot=
 be forwarded because of exhausted hop-limit SHOULD be

      logged=
.


 


      The in=
itial hop-limit value SHOULD be configurable.  If no initial


      value =
is explicitly provided, the default initial hop-limit value


      of 16 =
(32/64?) MUST be used.


 


      Becaus=
e forwarding errors may occur if inadequate hop-limit values


      are us=
ed, DOTS agents at the boundaries of an administrative

      domain=
 MAY be instructed to rewrite the value of hop-limit carried


      in rec=
eived messages (that is, ignore the value of hop-limit

      receiv=
ed in a message).


 


      This i=
s an optional attribute.


=3D=3D=3D


 


Cheers,


Med


 








De : Dots [mailto:dots-bounces@ietf.org]
De la part de Konda, Tirumaleswar Reddy

Envoy=E9 : vendredi 22 d=E9cembre 2017 11:32

=C0 : Jon Shallow; dots@ietf.o=
rg

Objet : Re: [Dots] DOTS gateway loop handling=







 


Yes, I meant as CBOR and JSON parameters.


 


-Tiru


 








From: Jon Shallow [mailto:s=
upjps-ietf@jpshallow.com]


Sent: Friday, December 22, 2017 4:00 PM

To: Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@McAfee.com>;
dots@ietf.org

Subject: RE: [Dots] DOTS gateway loop handling






 


Hi Tiru=
,


&n=
bsp;


I’=
;m not sure that we can necessarily support this as a Header, but certainly=
 as a parameter in the CBOR / JSON


&n=
bsp;


I think=
 the most likely scenario for this loop to happen is if DNS is not working =
as expected.


&n=
bsp;


Regards=



&n=
bsp;


Jon


&n=
bsp;






From:=
 Dots [mailto:
dots-bounces@ietf.org] On B=
ehalf Of
Konda, Tirumaleswar Reddy

Sent: 22 December 2017 10:24

To: Jon Shallow; dots@ietf.org<=
br>
Subject: Re: [Dots] DOTS gateway loop handling






 


Good point, both drafts can use a mechanism similar to the one discus=
sed in
https://tools.iet=
f.org/html/rfc7332#section-5 (Max-forwards header).

 


-Tiru


 








From: Dots [mailto:dots-bounces=
@ietf.org]
On Behalf Of Jon Shallow

Sent: Friday, December 22, 2017 2:53 PM

To: dots@ietf.org

Subject: [Dots] DOTS gateway loop handling






 


Hi WG,


 


While there never should be a l=
oop in DOTS traffic going via DOTS gateways, if there is a mis-configuratio=
n a request can end up getting bounced between a set of (not necessarily ad=
jacent) DOTS gateways.


 


We need to make sure that this =
loop is broken – possibly by using a mechanism similar to TTL in IP p=
ackets.


 


If we agree that loops need to =
get broken, this “feature” needs to get added into both the sig=
nal and data channels.


 


Regards


 


Jon
--_000_787AE7BB302AE849A7480A190F8B93300A0ADFDCOPEXCLILMA3corp_-- From nobody Tue Jan 9 04:44:21 2018 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 7073D1276AF for ; Tue, 9 Jan 2018 04:44:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 Jb1wYB4ixdLA for ; Tue, 9 Jan 2018 04:44:16 -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 6057012D832 for ; Tue, 9 Jan 2018 04:44:16 -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 1eYtGI-0006c4-I2; Tue, 09 Jan 2018 12:44:14 +0000 From: "Jon Shallow" To: , "Konda, Tirumaleswar Reddy" , References: <010a01d3886d$6540ba70$2fc22f50$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93300A0ADD8E@OPEXCLILMA3.corporate.adroot.infra.ftgroup> In-Reply-To: <787AE7BB302AE849A7480A190F8B93300A0ADD8E@OPEXCLILMA3.corporate.adroot.infra.ftgroup> Date: Tue, 9 Jan 2018 12:44:15 -0000 Message-ID: <02e101d38947$8ef80aa0$ace81fe0$@jpshallow.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_02E2_01D38947.8EF99140" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQGObXliLbib6O6yLV/NQ5+C+6q1sAHzJUIsAmVBfouj0sRDwA== Content-Language: en-gb Archived-At: Subject: Re: [Dots] Filter name clashes 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, 09 Jan 2018 12:44:19 -0000 This is a multipart message in MIME format. ------=_NextPart_000_02E2_01D38947.8EF99140 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi there, =20 Agreed that the ACLS MUST be bound to a DOTS client or DOTS = client-domain if there is aggregation done by client-domain DOTS gateway (aggregation = methods out of scope). =20 However, my confusion is over the contents of the final acl-name entry. = The current YANG tree after augments that we have is =20 module: ietf-dots-data-channel +--rw identifier +--rw client-identifier* binary +--rw alias* [alias-name] +--rw alias-name string +--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 target-fqdn* inet:domain-name +--rw target-uri* inet:uri module: ietf-access-control-list +--rw access-lists +--rw acl* [acl-type acl-name] | +--rw acl-name string | +--rw acl-type acl-type | +--rw aces | ... +--rw data-channel:client-identifier* binary +--rw data-channel:dots-acl-order +--rw data-channel:acl-set* [set-name type] +--rw data-channel:set-name -> /ietf-acl:access-lists/acl/acl-name +--rw data-channel:type -> /ietf-acl:access-lists/acl/acl-type =20 So, set-name + CUID is unique, but it points to =93/ietf-acl:access-lists/acl/acl-name=94 to select a particular = acl-name. So how, when going through the YANG tree do we make sure that =93cuid=3DABC/set-name=3Dmy-filter=94 and = =93cuid=3DDEF/set-name=3Dmy-filter=94 =96 both pointing to the common =93acl-name=3Dmy-filter=94 end up with 2 = =93my-filters=94 that have the same name (my-filter) but different contents in the = =93access-list=94 branch? =20 Or are we expecting the DOTS server to somehow combine the entry under =93access-lists=94 to include both the cuid and my-filter in the = acl-name? =20 I agree that we must enforce no access if an agent goes directly to the =93access-list=94 branch. =20 Regards =20 Jon =20 From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of mohamed.boucadair@orange.com Sent: 09 January 2018 10:01 To: Konda, Tirumaleswar Reddy; Jon Shallow; dots@ietf.org Subject: Re: [Dots] Filter name clashes =20 Hi all,=20 =20 Agree with Tiru.=20 =20 ACLs need to be bound to a DOTS client(-domain).=20 =20 Cheers, Med =20 De : Dots [mailto:dots-bounces@ietf.org] De la part de Konda, = Tirumaleswar Reddy Envoy=E9 : lundi 8 janvier 2018 12:17 =C0 : Jon Shallow; dots@ietf.org Objet : Re: [Dots] Filter name clashes =20 Hi Jon, =20 Even if client-A and client-B use the same ACL name =93my-filter=94, the = same ACL name is created by two different clients with different client identities, the server will not override the ACL rule created by one = client with another client (i.e. one of the reasons for introducing = client-unique). The client must create a ACL rule by using =93data-channel:client-unique=3DABC/set-name=3Dmy-filter/type=3Dxx=94 = and not just use =93access-lists/acl=94. =20 Cheers, -Tiru =20 From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Jon Shallow Sent: Monday, January 8, 2018 4:13 PM To: dots@ietf.org Subject: [Dots] Filter name clashes =20 Hi there, =20 I have realised that we have a serious filter name overwrite issue with = the current data channel spec. =20 Client-A can define =93my-filter=94 by either going directly through =93access-lists/acl=94, or =93data-channel:client-identifier=3DABC/set-name=3Dmy-filter/type=3Dxx=94= . =20 Client-B can also define =93my-filter=94 =96 using = =93access-lists/acl=94 which will overwrite Client-A=92s version, and actually so will =93data-channel:client-identifier=3DDEF/set-name=3Dmy-filter/type=3Dxx=94= even though client-identifier=3D will be different from that of Client A. =20 I have posted an issue to the netmod-acl https://github.com/netmod-wg/acl-model/issues asking whether = access-lists could be made a grouping or not. If this was to happen, we could use = =93uses access-lists=94 underneath a client-identifier. =20 The alternative could be that we build our own higher level access-lists/ace/acl etc. tree and then cherry pick the actual = =93matches=94 and =93actions=94 that we want for DOTS (which will save a lot of = =93augments=94) =96 for example l2 matches make no real sense to DOTS. =20 Regards =20 Jon ------=_NextPart_000_02E2_01D38947.8EF99140 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi there,

 

Agreed that the ACLS = MUST be bound to a DOTS client or DOTS client-domain if there is = aggregation done by client-domain DOTS gateway (aggregation methods out = of scope).

 

However, my confusion is = over the contents of the final acl-name entry.=A0 The current YANG tree = after augments that we have is

 

module: = ietf-dots-data-channel

=A0=A0=A0 +--rw identifier

=A0=A0=A0=A0=A0=A0 +--rw client-identifier*=A0=A0 = binary

=A0=A0=A0=A0=A0=A0 +--rw alias* = [alias-name]

=A0=A0=A0=A0=A0=A0=A0=A0=A0 +--rw = alias-name=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 string

=A0=A0=A0=A0=A0=A0=A0=A0=A0 +--rw = target-prefix*=A0=A0=A0=A0=A0=A0 inet:ip-prefix

=A0=A0=A0=A0=A0=A0=A0=A0=A0 +--rw target-port-range* = [lower-port upper-port]

=A0=A0=A0=A0=A0 =A0=A0=A0=A0|=A0 +--rw = lower-port=A0=A0=A0 inet:port-number

=A0=A0=A0=A0=A0=A0=A0=A0=A0 |=A0 +--rw = upper-port=A0=A0=A0 inet:port-number

=A0=A0=A0=A0=A0=A0=A0=A0=A0 +--rw = target-protocol*=A0=A0=A0=A0 uint8

=A0=A0=A0=A0=A0=A0=A0=A0=A0 +--rw = target-fqdn*=A0=A0=A0=A0=A0=A0=A0=A0 = inet:domain-name

=A0=A0=A0=A0=A0=A0=A0=A0=A0 +--rw = target-uri*=A0=A0=A0=A0=A0=A0=A0=A0=A0 inet:uri

module: = ietf-access-control-list

=A0=A0=A0 +--rw access-lists

=A0=A0=A0=A0=A0=A0 +--rw acl* [acl-type = acl-name]

=A0=A0=A0=A0=A0=A0 |=A0 +--rw acl-name=A0=A0=A0 = string

=A0=A0=A0=A0=A0=A0 |=A0 +--rw acl-type=A0=A0=A0 = acl-type

=A0=A0=A0=A0=A0=A0 |=A0 +--rw = aces

=A0=A0=A0=A0=A0=A0 | =A0...

=A0=A0=A0=A0=A0=A0 +--rw = data-channel:client-identifier*=A0=A0 binary

=A0=A0=A0=A0=A0=A0 +--rw = data-channel:dots-acl-order

=A0=A0=A0=A0=A0=A0=A0=A0=A0 +--rw = data-channel:acl-set* [set-name type]

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 +--rw = data-channel:set-name=A0=A0=A0 -> = /ietf-acl:access-lists/acl/acl-name

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 +--rw = data-channel:type=A0=A0=A0=A0=A0=A0=A0 -> = /ietf-acl:access-lists/acl/acl-type

 

So, set-name + CUID is = unique, but it points to “/ietf-acl:access-lists/acl/acl-name” to = select a particular acl-name.=A0 So how, when going through the YANG = tree do we make sure that = “cuid=3DABC/set-name=3Dmy-filter” and = “cuid=3DDEF/set-name=3Dmy-filter” – both = pointing to the common “acl-name=3Dmy-filter” end up with 2 = “my-filters” that have the same name (my-filter) but = different contents in the “access-list” = branch?

 

Or are we expecting the = DOTS server to somehow combine the entry under = “access-lists” to include both the cuid and my-filter in the = acl-name?

 

I agree that we must = enforce no access if an agent goes directly to the = “access-list” branch.

 

Regards

 

Jon

 

From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of = mohamed.boucadair@orange.com
Sent: 09 January 2018 = 10:01
To: Konda, Tirumaleswar Reddy; Jon Shallow; = dots@ietf.org
Subject: Re: [Dots] Filter name = clashes

 

Hi all,

 

Agree with Tiru.

 

ACLs need to be bound to a DOTS client(-domain). =

 

Cheers,

Med

 

De : Dots [mailto:dots-bounces@ietf.org] = De la part de Konda, Tirumaleswar Reddy
Envoy=E9 : = lundi 8 janvier 2018 12:17
=C0 : Jon Shallow; dots@ietf.org
Objet : = Re: [Dots] Filter name clashes

 

Hi Jon,

 

Even if client-A and client-B use = the same ACL name “my-filter”, the same ACL name is created = by two different clients with different client identities, the server = will not override the ACL rule created by one client with another client = (i.e. one of the reasons for introducing client-unique). The client must = create a ACL rule by using = “data-channel:client-unique=3DABC/set-name=3Dmy-filter/type=3Dxx= 221; and not just use = “access-lists/acl”.

 

Cheers,

-Tiru

 

From: Dots [mailto:dots-bounces@ietf.org] = On Behalf Of Jon Shallow
Sent: Monday, January 8, 2018 = 4:13 PM
To: dots@ietf.org
Subject: = [Dots] Filter name clashes

 

Hi = there,

 

I have realised that we = have a serious filter name overwrite issue with the current data channel = spec.

 

Client-A can define = “my-filter” by either going directly through = “access-lists/acl”, or = “data-channel:client-identifier=3DABC/set-name=3Dmy-filter/type=3Dx= x”.

 

Client-B can also define = “my-filter” – using “access-lists/acl” = which will overwrite Client-A’s version, and actually so will = “data-channel:client-identifier=3DDEF/set-name=3Dmy-filter/type=3Dx= x” even though client-identifier=3D will be different from that of = Client A.

 

I have posted an issue = to the netmod-acl https://github.com= /netmod-wg/acl-model/issues asking whether access-lists could be = made a grouping or not.  If this was to happen, we could use = “uses access-lists” underneath a = client-identifier.

 

The alternative could be = that we build our own higher level access-lists/ace/acl etc. tree and = then cherry pick the actual “matches” and = “actions” that we want for DOTS (which will save a lot of = “augments”) – for example l2 matches make no real = sense to DOTS.

 

Regards

 

Jon

------=_NextPart_000_02E2_01D38947.8EF99140-- From nobody Tue Jan 9 05:11:39 2018 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 2A6AA127058 for ; Tue, 9 Jan 2018 05:11:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.628 X-Spam-Level: X-Spam-Status: No, score=-2.628 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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, T_RP_MATCHES_RCVD=-0.01, 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 0ZcMaTW1FdXP for ; Tue, 9 Jan 2018 05:11:34 -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 284E31204DA for ; Tue, 9 Jan 2018 05:11:34 -0800 (PST) Received: from opfednr04.francetelecom.fr (unknown [xx.xx.xx.68]) by opfednr22.francetelecom.fr (ESMTP service) with ESMTP id A3D5721432; Tue, 9 Jan 2018 14:11:32 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.59]) by opfednr04.francetelecom.fr (ESMTP service) with ESMTP id 8138E40075; Tue, 9 Jan 2018 14:11:32 +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, 9 Jan 2018 14:11:32 +0100 From: To: Jon Shallow , "Konda, Tirumaleswar Reddy" , "dots@ietf.org" Thread-Topic: [Dots] Filter name clashes Thread-Index: AQGObXliLbib6O6yLV/NQ5+C+6q1sAHzJUIsAmVBfouj0sRDwIAAMdvA Date: Tue, 9 Jan 2018 13:11:31 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93300A0AE078@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <010a01d3886d$6540ba70$2fc22f50$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93300A0ADD8E@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <02e101d38947$8ef80aa0$ace81fe0$@jpshallow.com> In-Reply-To: <02e101d38947$8ef80aa0$ace81fe0$@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_787AE7BB302AE849A7480A190F8B93300A0AE078OPEXCLILMA3corp_" MIME-Version: 1.0 Archived-At: Subject: Re: [Dots] Filter name clashes 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, 09 Jan 2018 13:11:37 -0000 --_000_787AE7BB302AE849A7480A190F8B93300A0AE078OPEXCLILMA3corp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re-, A first implementation option would be that the server maintains a reposito= ry for each DOTS client(-domain). This approach does not require a change t= o the current YANG module. The server will invoke the appropriate repositor= y as a function of the client's identity. The association between the repos= itory and the client identity is a local glue. A second approach consists in using one single repository for all DOTS clie= nt(-domains). For this one to work, the module has to be augmented to inclu= de a reference to the client identity. The client identity can be the uniqu= e identifier (cuid, used to be request-nonce) that is injected by a DOTS cl= ient itself and/or, eventually, the identity used for authentication purpos= es. Cheers, Med De : Jon Shallow [mailto:supjps-ietf@jpshallow.com] Envoy=E9 : mardi 9 janvier 2018 13:44 =C0 : BOUCADAIR Mohamed IMT/OLN; Konda, Tirumaleswar Reddy; dots@ietf.org Objet : RE: [Dots] Filter name clashes Hi there, Agreed that the ACLS MUST be bound to a DOTS client or DOTS client-domain i= f there is aggregation done by client-domain DOTS gateway (aggregation meth= ods out of scope). However, my confusion is over the contents of the final acl-name entry. Th= e current YANG tree after augments that we have is module: ietf-dots-data-channel +--rw identifier +--rw client-identifier* binary +--rw alias* [alias-name] +--rw alias-name string +--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 target-fqdn* inet:domain-name +--rw target-uri* inet:uri module: ietf-access-control-list +--rw access-lists +--rw acl* [acl-type acl-name] | +--rw acl-name string | +--rw acl-type acl-type | +--rw aces | ... +--rw data-channel:client-identifier* binary +--rw data-channel:dots-acl-order +--rw data-channel:acl-set* [set-name type] +--rw data-channel:set-name -> /ietf-acl:access-lists/acl/a= cl-name +--rw data-channel:type -> /ietf-acl:access-lists/acl/a= cl-type So, set-name + CUID is unique, but it points to "/ietf-acl:access-lists/acl= /acl-name" to select a particular acl-name. So how, when going through the= YANG tree do we make sure that "cuid=3DABC/set-name=3Dmy-filter" and "cuid= =3DDEF/set-name=3Dmy-filter" - both pointing to the common "acl-name=3Dmy-f= ilter" end up with 2 "my-filters" that have the same name (my-filter) but d= ifferent contents in the "access-list" branch? Or are we expecting the DOTS server to somehow combine the entry under "acc= ess-lists" to include both the cuid and my-filter in the acl-name? I agree that we must enforce no access if an agent goes directly to the "ac= cess-list" branch. Regards Jon From: Dots [mailto: dots-bounces@ietf.org] On= Behalf Of mohamed.boucadair@orange.com Sent: 09 January 2018 10:01 To: Konda, Tirumaleswar Reddy; Jon Shallow; dots@ietf.org Subject: Re: [Dots] Filter name clashes Hi all, Agree with Tiru. ACLs need to be bound to a DOTS client(-domain). Cheers, Med De : Dots [mailto:dots-bounces@ietf.org] De la part de Konda, Tirumaleswar = Reddy Envoy=E9 : lundi 8 janvier 2018 12:17 =C0 : Jon Shallow; dots@ietf.org Objet : Re: [Dots] Filter name clashes Hi Jon, Even if client-A and client-B use the same ACL name "my-filter", the same A= CL name is created by two different clients with different client identitie= s, the server will not override the ACL rule created by one client with ano= ther client (i.e. one of the reasons for introducing client-unique). The cl= ient must create a ACL rule by using "data-channel:client-unique=3DABC/set-= name=3Dmy-filter/type=3Dxx" and not just use "access-lists/acl". Cheers, -Tiru From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Jon Shallow Sent: Monday, January 8, 2018 4:13 PM To: dots@ietf.org Subject: [Dots] Filter name clashes Hi there, I have realised that we have a serious filter name overwrite issue with the= current data channel spec. Client-A can define "my-filter" by either going directly through "access-li= sts/acl", or "data-channel:client-identifier=3DABC/set-name=3Dmy-filter/typ= e=3Dxx". Client-B can also define "my-filter" - using "access-lists/acl" which will = overwrite Client-A's version, and actually so will "data-channel:client-ide= ntifier=3DDEF/set-name=3Dmy-filter/type=3Dxx" even though client-identifier= =3D will be different from that of Client A. I have posted an issue to the netmod-acl https://github.com/netmod-wg/acl-m= odel/issues asking whether access-lists could be made a grouping or not. I= f this was to happen, we could use "uses access-lists" underneath a client-= identifier. The alternative could be that we build our own higher level access-lists/ac= e/acl etc. tree and then cherry pick the actual "matches" and "actions" tha= t we want for DOTS (which will save a lot of "augments") - for example l2 m= atches make no real sense to DOTS. Regards Jon --_000_787AE7BB302AE849A7480A190F8B93300A0AE078OPEXCLILMA3corp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Re-,

 

A first implementation option w= ould be that the server maintains a repository for each DOTS client(-domain= ). This approach does not require a change to the current YANG module. The server will invoke the appropriate repository as = a function of the client’s identity. The association between the repo= sitory and the client identity is a local glue.

 

A second approach consists in u= sing one single repository for all DOTS client(-domains). For this one to w= ork, the module has to be augmented to include a reference to the client identity. The client identity can be the unique id= entifier (cuid, used to be request-nonce) that is injected by a DOTS client= itself and/or, eventually, the identity used for authentication purposes.<= o:p>

 

Cheers,

Med

 

De : Jon Shallow [mailto:supjps-ietf= @jpshallow.com]
Envoy=E9 : mardi 9 janvier 2018 13:44
=C0 : BOUCADAIR Mohamed IMT/OLN; Konda, Tirumaleswar Reddy; dot= s@ietf.org
Objet : RE: [Dots] Filter name clashes

 

Hi ther= e,

&n= bsp;

Agreed = that the ACLS MUST be bound to a DOTS client or DOTS client-domain if there= is aggregation done by client-domain DOTS gateway (aggregation methods out= of scope).

&n= bsp;

However= , my confusion is over the contents of the final acl-name entry.  The = current YANG tree after augments that we have is

&n= bsp;

module: ietf-dots-data-channel=

    +--rw i= dentifier

     =   +--rw client-identifier*   binary

     =   +--rw alias* [alias-name]

     =      +--rw alias-name     =       string

     =      +--rw target-prefix*    &n= bsp;  inet:ip-prefix

     =      +--rw target-port-range* [lower-port upper-por= t]

     =     |  +--rw lower-port    ine= t:port-number

     =      |  +--rw upper-port    ine= t:port-number

     =      +--rw target-protocol*    = uint8

     =      +--rw target-fqdn*    &nbs= p;    inet:domain-name

     =      +--rw target-uri*     = ;     inet:uri

module: ietf-access-control-li= st

    +--rw a= ccess-lists

     =   +--rw acl* [acl-type acl-name]

     =   |  +--rw acl-name    string

     =   |  +--rw acl-type    acl-type

     =   |  +--rw aces

     =   |  ...

     =   +--rw data-channel:client-identifier*   binary

     =   +--rw data-channel:dots-acl-order

     =      +--rw data-channel:acl-set* [set-name type]

     =         +--rw data-channel:set-name&= nbsp;   -> /ietf-acl:access-lists/acl/acl-name

     =         +--rw data-channel:type = ;       -> /ietf-acl:access-lists/acl/acl-= type

&n= bsp;

So, set= -name + CUID is unique, but it points to “/ietf-acl:access-lists/= acl/acl-name” to select a particular acl-name.  So how, when goi= ng through the YANG tree do we make sure that “cuid=3DABC/set-= name=3Dmy-filter” and “cuid=3DDEF/set-name=3Dmy-filter” – both poin= ting to the common “acl-name=3Dmy-filter” end up with 2 “= my-filters” that have the same name (my-filter) but different content= s in the “access-list” branch?

&n= bsp;

Or are = we expecting the DOTS server to somehow combine the entry under “acce= ss-lists” to include both the cuid and my-filter in the acl-name?

&n= bsp;

I agree= that we must enforce no access if an agent goes directly to the “acc= ess-list” branch.

&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: 09 January 2018 10:01
To: Konda, Tirumaleswar Reddy; Jon Shallow; dots@ietf.org
Subject: Re: [Dots] Filter name clashes

 

Hi all,

 

Agree with Tiru.

 

ACLs need to be bound to a DOTS= client(-domain).

 

Cheers,

Med

 

De : Dots [mailto:dots-bounces@ietf.org] De la part de Konda, Tirumaleswar Reddy
Envoy=E9 : lundi 8 janvier 2018 12:17
=C0 : Jon Shallow; dots@ietf.o= rg
Objet : Re: [Dots] Filter name clashes

 

Hi Jon,

 

Even if client-A and client-B use the same ACL name “my-filter&= #8221;, the same ACL name is created by two different clients with differen= t client identities, the server will not override the ACL rule created by one client with another client (i.e. one of the re= asons for introducing client-unique). The client must create a ACL rule by = using “data-channel:client-unique=3DABC/set-name=3Dmy-filter/type=3Dx= x” and not just use “access-lists/acl”.=

 

Cheers,

-Tiru

 

From: Dots [mailto:dots-bounces= @ietf.org] On Behalf Of Jon Shallow
Sent: Monday, January 8, 2018 4:13 PM
To: dots@ietf.org
Subject: [Dots] Filter name clashes

 

Hi ther= e,

&n= bsp;

I have = realised that we have a serious filter name overwrite issue with the curren= t data channel spec.

&n= bsp;

Client-= A can define “my-filter” by either going directly through ̶= 0;access-lists/acl”, or “data-channel:client-identifier=3DABC/s= et-name=3Dmy-filter/type=3Dxx”.

&n= bsp;

Client-= B can also define “my-filter” – using “access-lists= /acl” which will overwrite Client-A’s version, and actually so = will “data-channel:client-identifier=3DDEF/set-name=3Dmy-filter/type= =3Dxx” even though client-identifier=3D will be different from that of Client A.<= /o:p>

&n= bsp;

I have = posted an issue to the netmod-acl https://github.co= m/netmod-wg/acl-model/issues asking whether access-lists could be made = a grouping or not.  If this was to happen, we could use “uses ac= cess-lists” underneath a client-identifier.

&n= bsp;

The alt= ernative could be that we build our own higher level access-lists/ace/acl e= tc. tree and then cherry pick the actual “matches” and “a= ctions” that we want for DOTS (which will save a lot of “augments”) – for example l2 matches make no real sense = to DOTS.

&n= bsp;

Regards=

&n= bsp;

Jon

--_000_787AE7BB302AE849A7480A190F8B93300A0AE078OPEXCLILMA3corp_-- From nobody Tue Jan 9 05:22:07 2018 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 422EE1277BB for ; Tue, 9 Jan 2018 05:22:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.509 X-Spam-Level: X-Spam-Status: No, score=-5.509 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_RP_MATCHES_RCVD=-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 9TxHAxQhu-CK for ; Tue, 9 Jan 2018 05:22:02 -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 306711204DA for ; Tue, 9 Jan 2018 05:22:01 -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=1515504108; 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:x-microsoft-antispam-message-info: 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 4nNktmALKYQgHnH2ULLQKtM2H0rF1j/9eNzApqs4g Q=; b=nkfZGUY5CQNKQowwnLqWIz87O0ZmgwmHk6tbvXwUSMoP nVqiiQw5v8QJOFNeLqxsRBqPJJyy19d8pREPiscK5pDvtsReNN vWrBuQD3J2IMiEKa1N/TrGgb1CNaN2RphjDcdzNlO0eG4452h9 qEklaAajAs5Mp1jrsrIUXK9hHvI= Received: from MIVEXAPP1N02.corpzone.internalzone.com (unknown [10.48.48.89]) by MIVWSMAILOUT1.mcafee.com with smtp (TLS: TLSv1/SSLv3,256bits,ECDHE-RSA-AES256-SHA384) id 4a9a_2cca_9d051bf3_7b5d_46dc_8eb2_84b846ac68ef; Tue, 09 Jan 2018 07:21:47 -0600 Received: from MIVEXUSR1N03.corpzone.internalzone.com (10.48.48.83) by MIVEXAPP1N02.corpzone.internalzone.com (10.48.48.89) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Tue, 9 Jan 2018 08:21:46 -0500 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; Tue, 9 Jan 2018 08:21:46 -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, 9 Jan 2018 08:21:44 -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.386.5; Tue, 9 Jan 2018 13:21: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.0386.008; Tue, 9 Jan 2018 13:21:44 +0000 From: "Konda, Tirumaleswar Reddy" To: Jon Shallow , "mohamed.boucadair@orange.com" , "dots@ietf.org" Thread-Topic: [Dots] DOTS gateway loop handling Thread-Index: AdN7BmUWqzqWF8J/Qkebpl5qeIXshwAB7v7wAABvMAAAAAi8kANdccuAAAEUZ6AAANsEwAAAdexAAClVKAAABfvZEA== Date: Tue, 9 Jan 2018 13:21:44 +0000 Message-ID: References: <06a901d37b06$681bf800$3853e800$@jpshallow.com> <06ce01d37b0f$de1d3ba0$9a57b2e0$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93300A0AD4D3@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93300A0AD58C@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <02b601d38934$b27d7ef0$17787cd0$@jpshallow.com> In-Reply-To: <02b601d38934$b27d7ef0$17787cd0$@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.16.166] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DM5PR16MB1785; 7:6BhsWX4hbf0dwZPs/PKtqgIk7IuULqE0mGKjhh/B8XjXcFXR4hXUcFXC/R86jk1alJN4aJvusVqHsjeucrsHXeU2YcjYbRXGEsDRAsAdpuv+ShuiV/SC9i8LgCjeEHngublq28ZMArbJbR8MkbpVUYgN32S01BrVDLOyGn/4Sq+a2UCI0oeTYbI+N/qJ5j6qatkas2kMysaO7qtWueVHUk+ZCf+4nbqxa0KaLIPmIUL6n/oIkdqh/t8qcmBkOdlO x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 9988d2da-6e5f-490f-953f-08d55763ee04 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(5600026)(4604075)(3008032)(2017052603307)(7153060)(7193020); SRVR:DM5PR16MB1785; x-ms-traffictypediagnostic: DM5PR16MB1785: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(18271650672692)(21748063052155)(123452027830198); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040470)(2401047)(8121501046)(5005006)(3231023)(944501075)(3002001)(10201501046)(93006095)(93001095)(6041268)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123564045)(20161123562045)(20161123560045)(20161123558120)(6072148)(201708071742011); SRVR:DM5PR16MB1785; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:DM5PR16MB1785; x-forefront-prvs: 0547116B72 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(346002)(396003)(39380400002)(376002)(39860400002)(366004)(32952001)(189003)(199004)(74316002)(72206003)(80792005)(105586002)(77096006)(106356001)(6506007)(236005)(33656002)(229853002)(6116002)(93886005)(7736002)(3846002)(19609705001)(966005)(606006)(478600001)(14454004)(66066001)(55016002)(790700001)(102836004)(2501003)(59450400001)(5660300001)(53936002)(54896002)(76176011)(6436002)(97736004)(6306002)(9686003)(8676002)(110136005)(316002)(81156014)(53546011)(2201001)(7696005)(9326002)(25786009)(3660700001)(3280700002)(2950100002)(6246003)(2906002)(8936002)(86362001)(81166006)(99286004)(68736007)(2900100001)(91024005)(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) x-microsoft-antispam-message-info: xScFd99y1+OJ8YjEiEoXYTXFnmyfgcBRK4nsci10IUZtm5I8GsxwSWnB2iPqIZPeIshxcNcekY4twI155u2MHQ== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_DM5PR16MB17881ED612B3693FA9D603D6EA100DM5PR16MB1788namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 9988d2da-6e5f-490f-953f-08d55763ee04 X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Jan 2018 13:21:44.7731 (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 <6196> : inlines <6299> : streams <1775559> : uri <2566444> Archived-At: Subject: Re: [Dots] DOTS gateway loop handling 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, 09 Jan 2018 13:22:05 -0000 --_000_DM5PR16MB17881ED612B3693FA9D603D6EA100DM5PR16MB1788namp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Jon, Please explain how attackers can create this attack vector against DOTS ? -Tiru From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Jon Shallow Sent: Tuesday, January 9, 2018 3:59 PM To: Konda, Tirumaleswar Reddy ; mohamed= .boucadair@orange.com; dots@ietf.org Subject: Re: [Dots] DOTS gateway loop handling While I agree that this "loop" is very unlikely to occur, I still think tha= t we have to defend against this edge case which could be used as an attack= vector against DOTS. In answer to Med's questions. 1) I think a default hop count of 16 is fine, but could make it 32 so = that it is larger than any likely hop count. If it is to be configurable, = then it should not be less than 16. 2) If a client gets back an error, there is a either a loop, or the "h= op-limit count" is insufficient. The client should record / report the fai= lure - and possibly the DOTS gateway that inserted the first occurrence of = hop-limit as there is either a network issue, or a misconfiguration issue. 3) I do not think that the inserting DOTS gateway should auto change t= he "hop-limit count" based on a failure - as there could be an upstream loo= p. If there is a loop failure, the DOTS client will not get back a response (u= sing UDP or TCP) if no diagnostic message is sent back, so will have to han= dle the "no response" condition anyway. Having a diagnostic 5.xy is a help= ful addition. Regards Jon From: Dots [mailto: dots-bounces@ietf.org] On= Behalf Of Konda, Tirumaleswar Reddy Sent: 08 January 2018 14:57 To: mohamed.boucadair@orange.com; Jon = Shallow; dots@ietf.org Subject: Re: [Dots] DOTS gateway loop handling Hop-limit is required for both DOTS signal and data channels. The default v= alue of 16 looks large enough to indicate looping, DOTS client cannot do an= ything but the on-path DOTS gateway administrators can look the misconfigur= ation problem once the 5.xy error is received. On reflection, the misconfig= uration though looks likely unlikely, it has to happen both at DNS and trus= t anchor database (Is it really required ?) ! -Tiru From: mohamed.boucadair@orange.com [ma= ilto:mohamed.boucadair@orange.com] Sent: Monday, January 8, 2018 8:14 PM To: Konda, Tirumaleswar Reddy >; Jon Shallow >; dots@ietf.org Subject: RE: [Dots] DOTS gateway loop handling Re-, A new error code would be required for this (e.g., 5.xy "hop limit reached"= ). Then, we do need to answer these questions: - What a client is supposed to do when such error is received? - Should the DOTS gateway that is responsible for setting the hop-limit = tracks the error messages so that it can adjust the setting in forthcoming = messages? Or we should be silent about this? Cheers, Med De : Dots [mailto:dots-bounces@ietf.org] De la part de Konda, Tirumaleswar = Reddy Envoy=E9 : lundi 8 janvier 2018 15:10 =C0 : BOUCADAIR Mohamed IMT/OLN; Jon Shallow; dots@ietf.org Objet : Re: [Dots] DOTS gateway loop handling Hi Med, Looks good, an error response is required to identify the request has not r= eached the final DOTS server. Cheers, -Tiru From: mohamed.boucadair@orange.com [ma= ilto:mohamed.boucadair@orange.com] Sent: Monday, January 8, 2018 7:07 PM To: Konda, Tirumaleswar Reddy >; Jon Shallow >; dots@ietf.org Subject: RE: [Dots] DOTS gateway loop handling Hi Tiru, Jon, all, Please find below a tentative text to cover this issue: =3D=3D hop-limit: This attribute is used to detect and prevent infinite loops. This attribute is typically inserted by a DOTS gateway. Each intermediate DOTS agent involved in the handling of a DOTS message MUST decrement the hop-limit value by 1 prior to forwarding upstream. DOTS messages MUST NOT be forwarded if the value of hop-limit is set to '0' after decrement. Messages that cannot be forwarded because of exhausted hop-limit SHOULD be logged. The initial hop-limit value SHOULD be configurable. If no initial value is explicitly provided, the default initial hop-limit value of 16 (32/64?) MUST be used. Because forwarding errors may occur if inadequate hop-limit values are used, DOTS agents at the boundaries of an administrative domain MAY be instructed to rewrite the value of hop-limit carried in received messages (that is, ignore the value of hop-limit received in a message). This is an optional attribute. =3D=3D=3D Cheers, Med De : Dots [mailto:dots-bounces@ietf.org] De la part de Konda, Tirumaleswar = Reddy Envoy=E9 : vendredi 22 d=E9cembre 2017 11:32 =C0 : Jon Shallow; dots@ietf.org Objet : Re: [Dots] DOTS gateway loop handling Yes, I meant as CBOR and JSON parameters. -Tiru From: Jon Shallow [mailto:supjps-ietf@jpshallow.com] Sent: Friday, December 22, 2017 4:00 PM To: Konda, Tirumaleswar Reddy >; dots@ietf.org Subject: RE: [Dots] DOTS gateway loop handling Hi Tiru, I'm not sure that we can necessarily support this as a Header, but certainl= y as a parameter in the CBOR / JSON I think the most likely scenario for this loop to happen is if DNS is not w= orking as expected. Regards Jon From: Dots [mailto: dots-bounces@ietf.org] On= Behalf Of Konda, Tirumaleswar Reddy Sent: 22 December 2017 10:24 To: Jon Shallow; dots@ietf.org Subject: Re: [Dots] DOTS gateway loop handling Good point, both drafts can use a mechanism similar to the one discussed in= https://tools.ietf.org/html/rfc7332#section-5 (Max-forwards header). -Tiru From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Jon Shallow Sent: Friday, December 22, 2017 2:53 PM To: dots@ietf.org Subject: [Dots] DOTS gateway loop handling Hi WG, While there never should be a loop in DOTS traffic going via DOTS gateways,= if there is a mis-configuration a request can end up getting bounced betwe= en a set of (not necessarily adjacent) DOTS gateways. We need to make sure that this loop is broken - possibly by using a mechani= sm similar to TTL in IP packets. If we agree that loops need to get broken, this "feature" needs to get adde= d into both the signal and data channels. Regards Jon --_000_DM5PR16MB17881ED612B3693FA9D603D6EA100DM5PR16MB1788namp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Jon,

&nbs= p;

Please ex= plain how attackers can create this attack vector against DOTS ?=

&nbs= p;

-Tiru

 

From:<= /span> Dots [mailto:dots-bou= nces@ietf.org] On Behalf Of Jon Shallow
Sent: Tuesday, January 9, 2018 3:59 PM
To: Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@McAfee.com= >; mohamed.boucadair@orange.com; dots@ietf.org
Subject: Re: [Dots] DOTS gateway loop handling

 

While I= agree that this “loop” is very unlikely to occur, I still thin= k that we have to defend against this edge case which could be used as an a= ttack vector against DOTS.

&n= bsp;

In answ= er to Med’s questions.

&n= bsp;

<= span style=3D"mso-list:Ignore">1)      I think a default hop count of 16 is fine, but co= uld make it 32 so that it is larger than any likely hop count.  If it = is to be configurable, then it should not be less than 16.

&n= bsp;

<= span style=3D"mso-list:Ignore">2)      If a client gets back an error, there is a either= a loop, or the “hop-limit count” is insufficient.  The cl= ient should record / report the failure – and possibly the DOTS gateway that inserted the first occurrence of hop-limit as there = is either a network issue, or a misconfiguration issue.

&n= bsp;

<= span style=3D"mso-list:Ignore">3)      I do not think that the inserting DOTS gateway sh= ould auto change the “hop-limit count” based on a failure ̵= 1; as there could be an upstream loop.

&n= bsp;

If ther= e is a loop failure, the DOTS client will not get back a response (using UD= P or TCP) if no diagnostic message is sent back, so will have to handle the= “no response” condition anyway.  Having a diagnostic 5.xy is a helpful addition.

&n= bsp;

Regards=

&n= bsp;

Jon

&n= bsp;

From: Dots [mailto: dots-bounces@ietf.org] On B= ehalf Of Konda, Tirumaleswar Reddy
Sent: 08 January 2018 14:57
To: mohamed.boucadai= r@orange.com; Jon Shallow; dots@ietf.org
Subject: Re: [Dots] DOTS gateway loop handling

 

Hop-limit= is required for both DOTS signal and data channels. The default value of 1= 6 looks large enough to indicate looping, DOTS client cannot do anything bu= t the on-path DOTS gateway administrators can look the misconfiguration problem once the 5.xy error is received. On = reflection, the misconfiguration though looks likely unlikely, it has to ha= ppen both at DNS and trust anchor database (Is it really required ?) !=

&nbs= p;

-Tiru

&nbs= p;

From:<= /span> mohamed.boucadair@orange.co= m [mailto:mohamed.bouca= dair@orange.com]
Sent: Monday, January 8, 2018 8:14 PM
To: Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@McAfee.com>; Jon Shallow= <supjps-ietf@jpshallow.com= >; dots@ietf.org
Subject: RE: [Dots] DOTS gateway loop handling

 

Re-,

 

A new error code would be required for this (e= .g., 5.xy “hop limit reached”).

 

Then, we do need to answer these questions:

-    What a client is supposed to do when such error is received?

-    Should the DOTS gateway that is responsible for setting the ho= p-limit tracks the error messages so that it can adjust the setting in fort= hcoming messages? Or we should be silent about this?   

 

Cheers,

Med

 

De : Dots [mailto:d= ots-bounces@ietf.org] De la part de Konda, Tirumaleswar Reddy
Envoy=E9 : lundi 8 janvier 2018 15:10
=C0 : BOUCADAIR Mohamed IMT/OLN; Jon Shallow; dots@ietf.org
Objet : Re: [Dots] DOTS gateway loop handling=

 

Hi Med,

&nbs= p;

Looks goo= d, an error response is required to identify the request has not reached th= e final DOTS server.

&nbs= p;

Cheers,

-Tiru

&nbs= p;

From:<= /span> mohamed.boucadair@orange.co= m [mailto:mohamed.bouca= dair@orange.com]
Sent: Monday, January 8, 2018 7:07 PM
To: Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@McAfee.com>; Jon Shallow= <supjps-ietf@jpshallow.com= >; dots@ietf.org
Subject: RE: [Dots] DOTS gateway loop handling

 

Hi Tiru, Jon, all,

 

Please find below a tentative text to cover th= is issue:

 

=3D=3D

   hop-limit:  This attribute is used=
 to detect and prevent infinite
      loops.  This att=
ribute is typically inserted by a DOTS gateway.
 
      Each intermediate DOT=
S agent involved in the handling of a DOTS
      message MUST decremen=
t the hop-limit value by 1 prior to
      forwarding upstream.&=
nbsp; DOTS messages MUST NOT be forwarded if the
      value of hop-limit is=
 set to '0' after decrement.  Messages that
      cannot be forwarded b=
ecause of exhausted hop-limit SHOULD be
      logged.
 
      The initial hop-limit=
 value SHOULD be configurable.  If no initial
      value is explicitly p=
rovided, the default initial hop-limit value
      of 16 (32/64?) MUST b=
e used.
 
      Because forwarding er=
rors may occur if inadequate hop-limit values
      are used, DOTS agents=
 at the boundaries of an administrative
      domain MAY be instruc=
ted to rewrite the value of hop-limit carried
      in received messages =
(that is, ignore the value of hop-limit
      received in a message=
).
 
      This is an optional a=
ttribute.

=3D=3D=3D

 

Cheers,

Med

 

De : Dots [mailto:dots-bounces@ietf.org] De la part de Konda, Tirumaleswar Reddy
Envoy=E9 : vendredi 22 d=E9cembre 2017 11:32
=C0 : Jon Shallow; dots@ietf.o= rg
Objet : Re: [Dots] DOTS gateway loop handling=

 

Yes, I me= ant as CBOR and JSON parameters.

&nbs= p;

-Tiru

&nbs= p;

From:<= /span> Jon Shallow [mailto:supjps-ietf@jpshallow.com]
Sent: Friday, December 22, 2017 4:00 PM
To: Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@McAfee.com>; dots@ietf.org
Subject: RE: [Dots] DOTS gateway loop handling

 

Hi Tiru= ,

&n= bsp;

I’= ;m not sure that we can necessarily support this as a Header, but certainly= as a parameter in the CBOR / JSON

&n= bsp;

I think= the most likely scenario for this loop to happen is if DNS is not working = as expected.

&n= bsp;

Regards=

&n= bsp;

Jon

&n= bsp;

From: Dots [mailto: dots-bounces@ietf.org] On B= ehalf Of Konda, Tirumaleswar Reddy
Sent: 22 December 2017 10:24
To: Jon Shallow; dots@ietf.org<= br> Subject: Re: [Dots] DOTS gateway loop handling

 

Good poin= t, both drafts can use a mechanism similar to the one discussed in https://tools.iet= f.org/html/rfc7332#section-5 (Max-forwards header).

&nbs= p;

-Tiru

&nbs= p;

From:<= /span> Dots [mailto:dots-bounces@ietf.org] On Behalf Of Jon Shallow
Sent: Friday, December 22, 2017 2:53 PM
To: dots@ietf.org
Subject: [Dots] DOTS gateway loop handling

 

Hi WG,

 

While there never should be a l= oop in DOTS traffic going via DOTS gateways, if there is a mis-configuratio= n a request can end up getting bounced between a set of (not necessarily ad= jacent) DOTS gateways.

 

We need to make sure that this = loop is broken – possibly by using a mechanism similar to TTL in IP p= ackets.

 

If we agree that loops need to = get broken, this “feature” needs to get added into both the sig= nal and data channels.

 

Regards

 

Jon

--_000_DM5PR16MB17881ED612B3693FA9D603D6EA100DM5PR16MB1788namp_-- From nobody Tue Jan 9 05:34:39 2018 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 25E3212D85E for ; Tue, 9 Jan 2018 05:34:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 24ft8iTmJEIo for ; Tue, 9 Jan 2018 05:34: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 35DC312D855 for ; Tue, 9 Jan 2018 05:34: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 1eYu2z-0006eV-Hy; Tue, 09 Jan 2018 13:34:33 +0000 From: "Jon Shallow" To: "'Konda, Tirumaleswar Reddy'" , , References: <06a901d37b06$681bf800$3853e800$@jpshallow.com> <06ce01d37b0f$de1d3ba0$9a57b2e0$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93300A0AD4D3@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93300A0AD58C@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <02b601d38934$b27d7ef0$17787cd0$@jpshallow.com> In-Reply-To: Date: Tue, 9 Jan 2018 13:34:34 -0000 Message-ID: <031201d3894e$9669d910$c33d8b30$@jpshallow.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0313_01D3894E.966C9830" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQH2IO4WJuCy0mWHgjECz8GquwZNogGntdEDA3dEaSACceR8iQGqELItAfT2e9QCd+0O/gGMidPzARcD4sUCIbd6LqKS76UA Content-Language: en-gb Archived-At: Subject: Re: [Dots] DOTS gateway loop handling 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, 09 Jan 2018 13:34:38 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0313_01D3894E.966C9830 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Tiru, =20 Poisoning a DNS server entry of an upstream DOTS server to cause a DOTS gateway server-facing-side to either talk to the IP of its client-facing-side, or possibly the IP of a client-facing-side of a = previous DOTS gateway would to me be a starting point. The DOTS peer trust relationships should break this loop though unless this was not getting properly enforced (in, say a client-domain). =20 Otherwise, a misconfiguration at set up time could cause this loop. =20 Regards =20 Jon =20 From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of Konda, = Tirumaleswar Reddy Sent: 09 January 2018 13:22 To: Jon Shallow; mohamed.boucadair@orange.com; dots@ietf.org Subject: Re: [Dots] DOTS gateway loop handling =20 Hi Jon, =20 Please explain how attackers can create this attack vector against DOTS = ? =20 -Tiru =20 From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Jon Shallow Sent: Tuesday, January 9, 2018 3:59 PM To: Konda, Tirumaleswar Reddy ; mohamed.boucadair@orange.com; dots@ietf.org Subject: Re: [Dots] DOTS gateway loop handling =20 While I agree that this =93loop=94 is very unlikely to occur, I still = think that we have to defend against this edge case which could be used as an = attack vector against DOTS. =20 In answer to Med=92s questions. =20 1) I think a default hop count of 16 is fine, but could make it 32 = so that it is larger than any likely hop count. If it is to be = configurable, then it should not be less than 16. =20 2) If a client gets back an error, there is a either a loop, or the =93hop-limit count=94 is insufficient. The client should record / = report the failure =96 and possibly the DOTS gateway that inserted the first = occurrence of hop-limit as there is either a network issue, or a misconfiguration issue. =20 3) I do not think that the inserting DOTS gateway should auto = change the =93hop-limit count=94 based on a failure =96 as there could be an = upstream loop. =20 If there is a loop failure, the DOTS client will not get back a response (using UDP or TCP) if no diagnostic message is sent back, so will have = to handle the =93no response=94 condition anyway. Having a diagnostic 5.xy = is a helpful addition. =20 Regards =20 Jon =20 From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of Konda, = Tirumaleswar Reddy Sent: 08 January 2018 14:57 To: mohamed.boucadair@orange.com; Jon Shallow; dots@ietf.org Subject: Re: [Dots] DOTS gateway loop handling =20 Hop-limit is required for both DOTS signal and data channels. The = default value of 16 looks large enough to indicate looping, DOTS client cannot = do anything but the on-path DOTS gateway administrators can look the misconfiguration problem once the 5.xy error is received. On reflection, = the misconfiguration though looks likely unlikely, it has to happen both at = DNS and trust anchor database (Is it really required ?) ! =20 -Tiru =20 From: mohamed.boucadair@orange.com [mailto:mohamed.boucadair@orange.com] = Sent: Monday, January 8, 2018 8:14 PM To: Konda, Tirumaleswar Reddy ; Jon Shallow ; dots@ietf.org Subject: RE: [Dots] DOTS gateway loop handling =20 Re-, =20 A new error code would be required for this (e.g., 5.xy =93hop limit reached=94).=20 =20 Then, we do need to answer these questions:=20 - What a client is supposed to do when such error is received?=20 - Should the DOTS gateway that is responsible for setting the = hop-limit tracks the error messages so that it can adjust the setting in = forthcoming messages? Or we should be silent about this? =20 =20 Cheers, Med =20 De : Dots [mailto:dots-bounces@ietf.org] De la part de Konda, = Tirumaleswar Reddy Envoy=E9 : lundi 8 janvier 2018 15:10 =C0 : BOUCADAIR Mohamed IMT/OLN; Jon Shallow; dots@ietf.org Objet : Re: [Dots] DOTS gateway loop handling =20 Hi Med, =20 Looks good, an error response is required to identify the request has = not reached the final DOTS server. =20 Cheers, -Tiru =20 From: mohamed.boucadair@orange.com [mailto:mohamed.boucadair@orange.com] = Sent: Monday, January 8, 2018 7:07 PM To: Konda, Tirumaleswar Reddy ; Jon Shallow ; dots@ietf.org Subject: RE: [Dots] DOTS gateway loop handling =20 Hi Tiru, Jon, all,=20 =20 Please find below a tentative text to cover this issue:=20 =20 =3D=3D hop-limit: This attribute is used to detect and prevent infinite loops. This attribute is typically inserted by a DOTS gateway. =20 Each intermediate DOTS agent involved in the handling of a DOTS message MUST decrement the hop-limit value by 1 prior to forwarding upstream. DOTS messages MUST NOT be forwarded if the value of hop-limit is set to '0' after decrement. Messages that cannot be forwarded because of exhausted hop-limit SHOULD be logged. =20 The initial hop-limit value SHOULD be configurable. If no initial value is explicitly provided, the default initial hop-limit value of 16 (32/64?) MUST be used. =20 Because forwarding errors may occur if inadequate hop-limit values are used, DOTS agents at the boundaries of an administrative domain MAY be instructed to rewrite the value of hop-limit carried in received messages (that is, ignore the value of hop-limit received in a message). =20 This is an optional attribute. =3D=3D=3D =20 Cheers, Med =20 De : Dots [mailto:dots-bounces@ietf.org] De la part de Konda, = Tirumaleswar Reddy Envoy=E9 : vendredi 22 d=E9cembre 2017 11:32 =C0 : Jon Shallow; dots@ietf.org Objet : Re: [Dots] DOTS gateway loop handling =20 Yes, I meant as CBOR and JSON parameters. =20 -Tiru =20 From: Jon Shallow [mailto:supjps-ietf@jpshallow.com]=20 Sent: Friday, December 22, 2017 4:00 PM To: Konda, Tirumaleswar Reddy ; dots@ietf.org Subject: RE: [Dots] DOTS gateway loop handling =20 Hi Tiru, =20 I=92m not sure that we can necessarily support this as a Header, but = certainly as a parameter in the CBOR / JSON =20 I think the most likely scenario for this loop to happen is if DNS is = not working as expected. =20 Regards =20 Jon =20 From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of Konda, = Tirumaleswar Reddy Sent: 22 December 2017 10:24 To: Jon Shallow; dots@ietf.org Subject: Re: [Dots] DOTS gateway loop handling =20 Good point, both drafts can use a mechanism similar to the one discussed = in https://tools.ietf.org/html/rfc7332#section-5 (Max-forwards header). =20 -Tiru =20 From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Jon Shallow Sent: Friday, December 22, 2017 2:53 PM To: dots@ietf.org Subject: [Dots] DOTS gateway loop handling =20 Hi WG, =20 While there never should be a loop in DOTS traffic going via DOTS = gateways, if there is a mis-configuration a request can end up getting bounced = between a set of (not necessarily adjacent) DOTS gateways. =20 We need to make sure that this loop is broken =96 possibly by using a mechanism similar to TTL in IP packets. =20 If we agree that loops need to get broken, this =93feature=94 needs to = get added into both the signal and data channels. =20 Regards =20 Jon ------=_NextPart_000_0313_01D3894E.966C9830 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Tiru,

 

Poisoning a DNS server = entry of an upstream DOTS server to cause a DOTS gateway = server-facing-side to either talk to the IP of its client-facing-side, = or possibly the IP of a client-facing-side of a previous DOTS gateway = would to me be a starting point.=A0 The DOTS peer trust relationships = should break this loop though unless this was not getting properly = enforced (in, say a client-domain).

 

Otherwise, a = misconfiguration at set up time could cause this = loop.

 

Regards

 

Jon

 

From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of = Konda, Tirumaleswar Reddy
Sent: 09 January 2018 = 13:22
To: Jon Shallow; mohamed.boucadair@orange.com; = dots@ietf.org
Subject: Re: [Dots] DOTS gateway loop = handling

 

Hi = Jon,

 

Please explain how attackers can = create this attack vector against DOTS ?

 

-Tiru

 

From: Dots [mailto:dots-bounces@ietf.org] = On Behalf Of Jon Shallow
Sent: Tuesday, January 9, 2018 = 3:59 PM
To: Konda, Tirumaleswar Reddy <TirumaleswarReddy_Kond= a@McAfee.com>; mohamed.boucadair@orange.com= ; dots@ietf.org
Subject: Re: = [Dots] DOTS gateway loop handling

 

While I agree that this = “loop” is very unlikely to occur, I still think that we have = to defend against this edge case which could be used as an attack vector = against DOTS.

 

In answer to Med’s = questions.

 

1)      = I think a default hop count of 16 = is fine, but could make it 32 so that it is larger than any likely hop = count.  If it is to be configurable, then it should not be less = than 16.

 

2)      = If a client gets back an error, = there is a either a loop, or the “hop-limit count” is = insufficient.  The client should record / report the failure = – and possibly the DOTS gateway that inserted the first occurrence = of hop-limit as there is either a network issue, or a misconfiguration = issue.

 

3)      = I do not think that the inserting = DOTS gateway should auto change the “hop-limit count” based = on a failure – as there could be an upstream = loop.

 

If there is a loop = failure, the DOTS client will not get back a response (using UDP or TCP) = if no diagnostic message is sent back, so will have to handle the = “no response” condition anyway.  Having a diagnostic = 5.xy is a helpful addition.

 

Regards

 

Jon

 

From: Dots [mailto: dots-bounces@ietf.org] On = Behalf Of Konda, Tirumaleswar Reddy
Sent: 08 January 2018 = 14:57
To: mohamed.boucadair@orange.com= ; Jon Shallow; dots@ietf.org
Subject: Re: = [Dots] DOTS gateway loop handling

 

Hop-limit is required = for both DOTS signal and data channels. The default value of 16 looks = large enough to indicate looping, DOTS client cannot do anything but the = on-path DOTS gateway administrators can look the misconfiguration = problem once the 5.xy error is received. On reflection, the = misconfiguration though looks likely unlikely, it has to happen both at = DNS and trust anchor database (Is it really required ?) = !

 

-Tiru

 

From: mohamed.boucadair@orange.com= [mailto:mohamed.boucadair@ora= nge.com]
Sent: Monday, January 8, 2018 8:14 = PM
To: Konda, Tirumaleswar Reddy <TirumaleswarReddy_Kond= a@McAfee.com>; Jon Shallow <supjps-ietf@jpshallow.com&g= t;; dots@ietf.org
Subject: RE: = [Dots] DOTS gateway loop handling

 

Re-,

 

A new error code would be required for this (e.g., = 5.xy “hop limit reached”).

 

Then, we do need to answer these questions: =

-    What a = client is supposed to do when such error is received? =

-    Should = the DOTS gateway that is responsible for setting the hop-limit tracks = the error messages so that it can adjust the setting in forthcoming = messages? Or we should be silent about this? =   

 

Cheers,

Med

 

De : Dots [mailto:dots-bounces@ietf.org] = De la part de Konda, Tirumaleswar Reddy
Envoy=E9 : = lundi 8 janvier 2018 15:10
=C0 : BOUCADAIR Mohamed IMT/OLN; Jon = Shallow; dots@ietf.org
Objet : = Re: [Dots] DOTS gateway loop = handling

 

Hi = Med,

 

Looks good, an error response is = required to identify the request has not reached the final DOTS = server.

 

Cheers,

-Tiru

 

From: mohamed.boucadair@orange.com= [mailto:mohamed.boucadair@ora= nge.com]
Sent: Monday, January 8, 2018 7:07 = PM
To: Konda, Tirumaleswar Reddy <TirumaleswarReddy_Kond= a@McAfee.com>; Jon Shallow <supjps-ietf@jpshallow.com&g= t;; dots@ietf.org
Subject: RE: = [Dots] DOTS gateway loop handling

 

Hi = Tiru, Jon, all,

 

Please find below a tentative text to cover this = issue:

 

=3D=3D

   hop-limit:  This =
attribute is used to detect and prevent =
infinite
      =
loops.  This attribute is typically inserted by a DOTS =
gateway.
 
      Each =
intermediate DOTS agent involved in the handling of a =
DOTS
      message =
MUST decrement the hop-limit value by 1 prior =
to
      forwarding =
upstream.  DOTS messages MUST NOT be forwarded if =
the
      value of =
hop-limit is set to '0' after decrement.  Messages =
that
      cannot be =
forwarded because of exhausted hop-limit SHOULD =
be
      =
logged.
 
      The initial =
hop-limit value SHOULD be configurable.  If no =
initial
      value is =
explicitly provided, the default initial hop-limit =
value
      of 16 =
(32/64?) MUST be used.
 
      Because =
forwarding errors may occur if inadequate hop-limit =
values
      are used, =
DOTS agents at the boundaries of an =
administrative
      domain MAY =
be instructed to rewrite the value of hop-limit =
carried
      in received =
messages (that is, ignore the value of =
hop-limit
      received in =
a message).
 
      This is an =
optional attribute.

=3D=3D=3D

 

Cheers,

Med

 

De : Dots [mailto:dots-bounces@ietf.org] = De la part de Konda, Tirumaleswar Reddy
Envoy=E9 : = vendredi 22 d=E9cembre 2017 11:32
=C0 : Jon Shallow; dots@ietf.org
Objet : = Re: [Dots] DOTS gateway loop = handling

 

Yes, I meant as CBOR = and JSON parameters.

 

-Tiru

 

From: Jon Shallow [mailto:supjps-ietf@jpshallow.co= m]
Sent: Friday, December 22, 2017 4:00 PM
To: = Konda, Tirumaleswar Reddy <TirumaleswarReddy_Kond= a@McAfee.com>; dots@ietf.org
Subject: RE: = [Dots] DOTS gateway loop handling

 

Hi = Tiru,

 

I’m not sure that = we can necessarily support this as a Header, but certainly as a = parameter in the CBOR / JSON

 

I think the most likely = scenario for this loop to happen is if DNS is not working as = expected.

 

Regards

 

Jon

 

From: Dots [mailto: dots-bounces@ietf.org] On = Behalf Of Konda, Tirumaleswar Reddy
Sent: 22 December 2017 = 10:24
To: Jon Shallow; dots@ietf.org
Subject: Re: = [Dots] DOTS gateway loop handling

 

Good point, both = drafts can use a mechanism similar to the one discussed in https://tools.ietf= .org/html/rfc7332#section-5 (Max-forwards = header).

 

-Tiru

 

From: Dots [mailto:dots-bounces@ietf.org] = On Behalf Of Jon Shallow
Sent: Friday, December 22, = 2017 2:53 PM
To: dots@ietf.org
Subject: = [Dots] DOTS gateway loop handling

 

Hi WG,

 

While there = never should be a loop in DOTS traffic going via DOTS gateways, if there = is a mis-configuration a request can end up getting bounced between a = set of (not necessarily adjacent) DOTS gateways.

 

We need to = make sure that this loop is broken – possibly by using a mechanism = similar to TTL in IP packets.

 

If we agree = that loops need to get broken, this “feature” needs to get = added into both the signal and data channels.

 

Regards

 

Jon

<= /div>
------=_NextPart_000_0313_01D3894E.966C9830-- From nobody Tue Jan 9 05:46:13 2018 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 AEFE212D85E for ; Tue, 9 Jan 2018 05:46:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.829 X-Spam-Level: X-Spam-Status: No, score=-2.829 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, RCVD_IN_SORBS_WEB=1.5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 qJS0xdfuJyBV for ; Tue, 9 Jan 2018 05:46:03 -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 29BE812D851 for ; Tue, 9 Jan 2018 05:46: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=1515505562; 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:x-microsoft-antispam-message-info: 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=6 +T9O51wjVIX4jf+6k1dMHDDLQ0HwZOOzeHCMPQ0wG o=; b=M47pZg6ZTzIReezQ9KT1KyK0emG2wF8rFBcOVfMiOBcX 1ul904QzwEEDd9XBqMX2WML43Xe0wJm5GEYxspRQQqNI0mFX14 +HyJ4sc37AD+NMLW+pR9vIze4u90WWQ8zUS6MWYUblCNrs85Rd Kfcrh09z38uUrYGn5JNG9+irIcQ= Received: from DNVEXAPP1N06.corpzone.internalzone.com (unknown [10.44.48.90]) by DNVWSMAILOUT1.mcafee.com with smtp (TLS: TLSv1/SSLv3,256bits,ECDHE-RSA-AES256-SHA384) id 7c9c_b8f2_2c6c7a55_9194_4473_94b1_cb2245f1d454; Tue, 09 Jan 2018 07:46:01 -0600 Received: from DNVEXUSR1N12.corpzone.internalzone.com (10.44.48.85) by DNVEXAPP1N06.corpzone.internalzone.com (10.44.48.90) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Tue, 9 Jan 2018 06:46:00 -0700 Received: from DNVEXUSR1N08.corpzone.internalzone.com (10.44.48.81) by DNVEXUSR1N12.corpzone.internalzone.com (10.44.48.85) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Tue, 9 Jan 2018 06:45:59 -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; Tue, 9 Jan 2018 06:45:59 -0700 Received: from NAM01-SN1-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; Tue, 9 Jan 2018 06:45:57 -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.386.5; Tue, 9 Jan 2018 13:45: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.0386.008; Tue, 9 Jan 2018 13:45:57 +0000 From: "Konda, Tirumaleswar Reddy" To: Jon Shallow , "mohamed.boucadair@orange.com" , "dots@ietf.org" Thread-Topic: [Dots] DOTS gateway loop handling Thread-Index: AdN7BmUWqzqWF8J/Qkebpl5qeIXshwAB7v7wAABvMAAAAAi8kANdccuAAAEUZ6AAANsEwAAAdexAAClVKAAABfvZEAAAfSoAAAAyyFA= Date: Tue, 9 Jan 2018 13:45:57 +0000 Message-ID: References: <06a901d37b06$681bf800$3853e800$@jpshallow.com> <06ce01d37b0f$de1d3ba0$9a57b2e0$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93300A0AD4D3@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93300A0AD58C@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <02b601d38934$b27d7ef0$17787cd0$@jpshallow.com> <031201d3894e$9669d910$c33d8b30$@jpshallow.com> In-Reply-To: <031201d3894e$9669d910$c33d8b30$@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.16.166] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DM5PR16MB1786; 6:KbSqjVSBMCBTPZ9VvzrYOyc2uAZ4Tj+Tpahj6u8Oe0Q54hvnIim5+x90idu8hMzkHgt2pYgG4aWZaHMBdiosQhLUqt3selgkv/QFacCIZ7GabMLEgM9zeSjh22e77JkKR/9RuvdvBieFBAPNxUr1kvkn46NOhiTFLMdjnTMAVi+2td8bzq5KZvfgtdkkahhC3+2/77Ve/RRxaLjaxSB3DesjNdZS4eyZVlpGwkim+O0bnaKLZZYvTrjTJ7rBn1Ldrn9gFhBSdVm4mvVxGEh2dTpuLkj7GF8ycrNcYsk0QMvn/A7+VFGeK+kMW1WBdhKrrOPxnQ58eATPiiZkRSVn0Z9PWnCfYa9hCpR1BDFqggevtBaqQPiLeZ8ZDC+9/v1d; 5:iMP1UwT9qu/SEhUH5XihCOEmpy6Yrg3KIBU9Mithfu59a6OKzbncS7C6Y4GZodluUkVHkV3wOt8ll+ptd9ajidUUOuAY+ld4Ra0k3rFlVAuTnyXw8FLBpD/GMVH0MvFQiR+eoQAoCH1YSlGOBJMLwf14brq1aW4l8Od4k/HMsj4=; 24:+oM7P5l67SG2xwOYQ5ObWBVDVhilcn5SSYaWXLguZzXX0ZKxVX3ofQbTu1j6l/oXm1YnBkN0GUubvHZWS6HGKNX2XZ6frkH92QUgmhCJ3AY=; 7:ovg11BcaxlXGdSOkZDTGE7n+/icfMi/C46nxwWY2qX9JsLmH6wUheEo0D5xY1p72p71lhUo+dohKBVXvoe5JJcb1KDk+71wlj/vJxPb9dVnNQJQROYUMfKGEZjqIScGVfqBm+VLcmrCGdtrYgw70FNsS4d4dl3YP/bZOE5QDNyvZGCdhZCxAQZAZemi+C6VuN2V9AfcXRMn6YjthaP9AGOxSfR214zdfjOrc+OR8Ekh1+OAj2zhKAvZ5ObWkZU+0 x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: d39e4e28-4572-4619-23eb-08d557674fc1 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(5600026)(4604075)(3008032)(2017052603307)(7153060)(7193020); SRVR:DM5PR16MB1786; x-ms-traffictypediagnostic: DM5PR16MB1786: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(158342451672863)(18271650672692)(21748063052155)(123452027830198); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040470)(2401047)(8121501046)(5005006)(3231023)(944501075)(3002001)(10201501046)(93006095)(93001095)(6041268)(20161123562045)(20161123558120)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(20161123564045)(6072148)(201708071742011); SRVR:DM5PR16MB1786; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:DM5PR16MB1786; x-forefront-prvs: 0547116B72 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39860400002)(396003)(346002)(376002)(39380400002)(366004)(32952001)(199004)(189003)(74316002)(76176011)(7696005)(53546011)(236005)(7736002)(6506007)(86362001)(2501003)(9686003)(2201001)(2950100002)(966005)(8676002)(5660300001)(606006)(102836004)(14454004)(8936002)(93886005)(81156014)(81166006)(55016002)(3846002)(66066001)(6436002)(53946003)(316002)(2906002)(478600001)(53936002)(110136005)(2900100001)(6246003)(80792005)(3280700002)(3660700001)(77096006)(33656002)(105586002)(72206003)(99286004)(19609705001)(97736004)(68736007)(229853002)(59450400001)(106356001)(6306002)(54896002)(790700001)(6116002)(9326002)(25786009)(91024005)(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) x-microsoft-antispam-message-info: HpGrUE3Qg7XA9V71Zm3n231j3uNkORhzg8POJRYT4kdJpE0CEV+H52uQ1nOwpTQrHpEJ28aYDl5bVl+LCtrlVw== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_DM5PR16MB1788B1713F3D1802BAE1CA62EA100DM5PR16MB1788namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: d39e4e28-4572-4619-23eb-08d557674fc1 X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Jan 2018 13:45:57.2848 (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 <6196> : inlines <6299> : streams <1775561> : uri <2566459> Archived-At: Subject: Re: [Dots] DOTS gateway loop handling 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, 09 Jan 2018 13:46:12 -0000 --_000_DM5PR16MB1788B1713F3D1802BAE1CA62EA100DM5PR16MB1788namp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Jon, I don't see an successful attack, DNS cache poisoning will be detected the = by the DOTS gateway by validating the peer DOTS agent identity. -Tiru From: Jon Shallow [mailto:supjps-ietf@jpshallow.com] Sent: Tuesday, January 9, 2018 7:05 PM To: Konda, Tirumaleswar Reddy ; mohamed= .boucadair@orange.com; dots@ietf.org Subject: RE: [Dots] DOTS gateway loop handling Hi Tiru, Poisoning a DNS server entry of an upstream DOTS server to cause a DOTS gat= eway server-facing-side to either talk to the IP of its client-facing-side,= or possibly the IP of a client-facing-side of a previous DOTS gateway woul= d to me be a starting point. The DOTS peer trust relationships should brea= k this loop though unless this was not getting properly enforced (in, say a= client-domain). Otherwise, a misconfiguration at set up time could cause this loop. Regards Jon From: Dots [mailto: dots-bounces@ietf.org] On= Behalf Of Konda, Tirumaleswar Reddy Sent: 09 January 2018 13:22 To: Jon Shallow; mohamed.boucadair@orange.com; dots@ietf.org Subject: Re: [Dots] DOTS gateway loop handling Hi Jon, Please explain how attackers can create this attack vector against DOTS ? -Tiru From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Jon Shallow Sent: Tuesday, January 9, 2018 3:59 PM To: Konda, Tirumaleswar Reddy >; mohamed.boucadair@orange.com; dots@ietf.org Subject: Re: [Dots] DOTS gateway loop handling While I agree that this "loop" is very unlikely to occur, I still think tha= t we have to defend against this edge case which could be used as an attack= vector against DOTS. In answer to Med's questions. 1) I think a default hop count of 16 is fine, but could make it 32 so = that it is larger than any likely hop count. If it is to be configurable, = then it should not be less than 16. 2) If a client gets back an error, there is a either a loop, or the "h= op-limit count" is insufficient. The client should record / report the fai= lure - and possibly the DOTS gateway that inserted the first occurrence of = hop-limit as there is either a network issue, or a misconfiguration issue. 3) I do not think that the inserting DOTS gateway should auto change t= he "hop-limit count" based on a failure - as there could be an upstream loo= p. If there is a loop failure, the DOTS client will not get back a response (u= sing UDP or TCP) if no diagnostic message is sent back, so will have to han= dle the "no response" condition anyway. Having a diagnostic 5.xy is a help= ful addition. Regards Jon From: Dots [mailto: dots-bounces@ietf.org] On= Behalf Of Konda, Tirumaleswar Reddy Sent: 08 January 2018 14:57 To: mohamed.boucadair@orange.com; Jon = Shallow; dots@ietf.org Subject: Re: [Dots] DOTS gateway loop handling Hop-limit is required for both DOTS signal and data channels. The default v= alue of 16 looks large enough to indicate looping, DOTS client cannot do an= ything but the on-path DOTS gateway administrators can look the misconfigur= ation problem once the 5.xy error is received. On reflection, the misconfig= uration though looks likely unlikely, it has to happen both at DNS and trus= t anchor database (Is it really required ?) ! -Tiru From: mohamed.boucadair@orange.com [ma= ilto:mohamed.boucadair@orange.com] Sent: Monday, January 8, 2018 8:14 PM To: Konda, Tirumaleswar Reddy >; Jon Shallow >; dots@ietf.org Subject: RE: [Dots] DOTS gateway loop handling Re-, A new error code would be required for this (e.g., 5.xy "hop limit reached"= ). Then, we do need to answer these questions: - What a client is supposed to do when such error is received? - Should the DOTS gateway that is responsible for setting the hop-limit = tracks the error messages so that it can adjust the setting in forthcoming = messages? Or we should be silent about this? Cheers, Med De : Dots [mailto:dots-bounces@ietf.org] De la part de Konda, Tirumaleswar = Reddy Envoy=E9 : lundi 8 janvier 2018 15:10 =C0 : BOUCADAIR Mohamed IMT/OLN; Jon Shallow; dots@ietf.org Objet : Re: [Dots] DOTS gateway loop handling Hi Med, Looks good, an error response is required to identify the request has not r= eached the final DOTS server. Cheers, -Tiru From: mohamed.boucadair@orange.com [ma= ilto:mohamed.boucadair@orange.com] Sent: Monday, January 8, 2018 7:07 PM To: Konda, Tirumaleswar Reddy >; Jon Shallow >; dots@ietf.org Subject: RE: [Dots] DOTS gateway loop handling Hi Tiru, Jon, all, Please find below a tentative text to cover this issue: =3D=3D hop-limit: This attribute is used to detect and prevent infinite loops. This attribute is typically inserted by a DOTS gateway. Each intermediate DOTS agent involved in the handling of a DOTS message MUST decrement the hop-limit value by 1 prior to forwarding upstream. DOTS messages MUST NOT be forwarded if the value of hop-limit is set to '0' after decrement. Messages that cannot be forwarded because of exhausted hop-limit SHOULD be logged. The initial hop-limit value SHOULD be configurable. If no initial value is explicitly provided, the default initial hop-limit value of 16 (32/64?) MUST be used. Because forwarding errors may occur if inadequate hop-limit values are used, DOTS agents at the boundaries of an administrative domain MAY be instructed to rewrite the value of hop-limit carried in received messages (that is, ignore the value of hop-limit received in a message). This is an optional attribute. =3D=3D=3D Cheers, Med De : Dots [mailto:dots-bounces@ietf.org] De la part de Konda, Tirumaleswar = Reddy Envoy=E9 : vendredi 22 d=E9cembre 2017 11:32 =C0 : Jon Shallow; dots@ietf.org Objet : Re: [Dots] DOTS gateway loop handling Yes, I meant as CBOR and JSON parameters. -Tiru From: Jon Shallow [mailto:supjps-ietf@jpshallow.com] Sent: Friday, December 22, 2017 4:00 PM To: Konda, Tirumaleswar Reddy >; dots@ietf.org Subject: RE: [Dots] DOTS gateway loop handling Hi Tiru, I'm not sure that we can necessarily support this as a Header, but certainl= y as a parameter in the CBOR / JSON I think the most likely scenario for this loop to happen is if DNS is not w= orking as expected. Regards Jon From: Dots [mailto: dots-bounces@ietf.org] On= Behalf Of Konda, Tirumaleswar Reddy Sent: 22 December 2017 10:24 To: Jon Shallow; dots@ietf.org Subject: Re: [Dots] DOTS gateway loop handling Good point, both drafts can use a mechanism similar to the one discussed in= https://tools.ietf.org/html/rfc7332#section-5 (Max-forwards header). -Tiru From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Jon Shallow Sent: Friday, December 22, 2017 2:53 PM To: dots@ietf.org Subject: [Dots] DOTS gateway loop handling Hi WG, While there never should be a loop in DOTS traffic going via DOTS gateways,= if there is a mis-configuration a request can end up getting bounced betwe= en a set of (not necessarily adjacent) DOTS gateways. We need to make sure that this loop is broken - possibly by using a mechani= sm similar to TTL in IP packets. If we agree that loops need to get broken, this "feature" needs to get adde= d into both the signal and data channels. Regards Jon --_000_DM5PR16MB1788B1713F3D1802BAE1CA62EA100DM5PR16MB1788namp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Jon,

&nbs= p;

I donR= 17;t see an successful attack, DNS cache poisoning will be detected the by = the DOTS gateway by validating the peer DOTS agent identity.

&nbs= p;

-Tiru

 

From:<= /span> Jon Shallow [mailto:s= upjps-ietf@jpshallow.com]
Sent: Tuesday, January 9, 2018 7:05 PM
To: Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@McAfee.com= >; mohamed.boucadair@orange.com; dots@ietf.org
Subject: RE: [Dots] DOTS gateway loop handling

 

Hi Tiru= ,

&n= bsp;

Poisoni= ng a DNS server entry of an upstream DOTS server to cause a DOTS gateway se= rver-facing-side to either talk to the IP of its client-facing-side, or pos= sibly the IP of a client-facing-side of a previous DOTS gateway would to me be a starting point.  The DOTS pe= er trust relationships should break this loop though unless this was not ge= tting properly enforced (in, say a client-domain).

&n= bsp;

Otherwi= se, a misconfiguration at set up time could cause this loop.

&n= bsp;

Regards=

&n= bsp;

Jon

&n= bsp;

From: Dots [mailto: dots-bounces@ietf.org] On B= ehalf Of Konda, Tirumaleswar Reddy
Sent: 09 January 2018 13:22
To: Jon Shallow; moh= amed.boucadair@orange.com; dots@ietf.org
Subject: Re: [Dots] DOTS gateway loop handling

 

Hi Jon,

&nbs= p;

Please ex= plain how attackers can create this attack vector against DOTS ?=

&nbs= p;

-Tiru

&nbs= p;

From:<= /span> Dots [mailto:dots-bounces@ietf.org] On Behalf Of Jon Shallow
Sent: Tuesday, January 9, 2018 3:59 PM
To: Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@McAfee.com>; mohamed.boucadair@orange.co= m; dots@ietf.org
Subject: Re: [Dots] DOTS gateway loop handling

 

While I= agree that this “loop” is very unlikely to occur, I still thin= k that we have to defend against this edge case which could be used as an a= ttack vector against DOTS.

&n= bsp;

In answ= er to Med’s questions.

&n= bsp;

1) = ;     I think a default hop c= ount of 16 is fine, but could make it 32 so that it is larger than any like= ly hop count.  If it is to be configurable, then it should not be less= than 16.

&n= bsp;

2) = ;     If a client gets back a= n error, there is a either a loop, or the “hop-limit count” is = insufficient.  The client should record / report the failure – a= nd possibly the DOTS gateway that inserted the first occurrence of hop-limit as there is either a network issue, or a misconfiguration iss= ue.

&n= bsp;

3) = ;     I do not think that the= inserting DOTS gateway should auto change the “hop-limit count”= ; based on a failure – as there could be an upstream loop.=

&n= bsp;

If ther= e is a loop failure, the DOTS client will not get back a response (using UD= P or TCP) if no diagnostic message is sent back, so will have to handle the= “no response” condition anyway.  Having a diagnostic 5.xy is a helpful addition.

&n= bsp;

Regards=

&n= bsp;

Jon

&n= bsp;

From: Dots [mailto: dots-bounces@ietf.org] On B= ehalf Of Konda, Tirumaleswar Reddy
Sent: 08 January 2018 14:57
To: mohamed.boucadai= r@orange.com; Jon Shallow; dots@ietf.org
Subject: Re: [Dots] DOTS gateway loop handling

 

Hop-limit= is required for both DOTS signal and data channels. The default value of 1= 6 looks large enough to indicate looping, DOTS client cannot do anything bu= t the on-path DOTS gateway administrators can look the misconfiguration problem once the 5.xy error is received. On = reflection, the misconfiguration though looks likely unlikely, it has to ha= ppen both at DNS and trust anchor database (Is it really required ?) !=

&nbs= p;

-Tiru

&nbs= p;

From:<= /span> mohamed.boucadair@orange.co= m [mailto:mohamed.bouca= dair@orange.com]
Sent: Monday, January 8, 2018 8:14 PM
To: Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@McAfee.com>; Jon Shallow= <supjps-ietf@jpshallow.com= >; dots@ietf.org
Subject: RE: [Dots] DOTS gateway loop handling

 

Re-,

 

A new error code would be required for this (e= .g., 5.xy “hop limit reached”).

 

Then, we do need to answer these questions:

-    What a client is supposed to do when such error is received?

-    Should the DOTS gateway that is responsible for setting the ho= p-limit tracks the error messages so that it can adjust the setting in fort= hcoming messages? Or we should be silent about this?   

 

Cheers,

Med

 

De : Dots [mailto:d= ots-bounces@ietf.org] De la part de Konda, Tirumaleswar Reddy
Envoy=E9 : lundi 8 janvier 2018 15:10
=C0 : BOUCADAIR Mohamed IMT/OLN; Jon Shallow; dots@ietf.org
Objet : Re: [Dots] DOTS gateway loop handling=

 

Hi Med,

&nbs= p;

Looks goo= d, an error response is required to identify the request has not reached th= e final DOTS server.

&nbs= p;

Cheers,

-Tiru

&nbs= p;

From:<= /span> mohamed.boucadair@orange.co= m [mailto:mohamed.bouca= dair@orange.com]
Sent: Monday, January 8, 2018 7:07 PM
To: Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@McAfee.com>; Jon Shallow= <supjps-ietf@jpshallow.com= >; dots@ietf.org
Subject: RE: [Dots] DOTS gateway loop handling

 

Hi Tiru, Jon, all,

 

Please find below a tentative text to cover th= is issue:

 

=3D=3D

   hop-limit:  This attribute is used=
 to detect and prevent infinite
      loops.  This att=
ribute is typically inserted by a DOTS gateway.
 
      Each intermediate DOT=
S agent involved in the handling of a DOTS
      message MUST decremen=
t the hop-limit value by 1 prior to
      forwarding upstream.&=
nbsp; DOTS messages MUST NOT be forwarded if the
      value of hop-limit is=
 set to '0' after decrement.  Messages that
      cannot be forwarded b=
ecause of exhausted hop-limit SHOULD be
      logged.
 
      The initial hop-limit=
 value SHOULD be configurable.  If no initial
      value is explicitly p=
rovided, the default initial hop-limit value
      of 16 (32/64?) MUST b=
e used.
 
      Because forwarding er=
rors may occur if inadequate hop-limit values
      are used, DOTS agents=
 at the boundaries of an administrative
      domain MAY be instruc=
ted to rewrite the value of hop-limit carried
      in received messages =
(that is, ignore the value of hop-limit
      received in a message=
).
 
      This is an optional a=
ttribute.

=3D=3D=3D

 

Cheers,

Med

 

De : Dots [mailto:dots-bounces@ietf.org] De la part de Konda, Tirumaleswar Reddy
Envoy=E9 : vendredi 22 d=E9cembre 2017 11:32
=C0 : Jon Shallow; dots@ietf.o= rg
Objet : Re: [Dots] DOTS gateway loop handling=

 

Yes, I me= ant as CBOR and JSON parameters.

&nbs= p;

-Tiru

&nbs= p;

From:<= /span> Jon Shallow [mailto:supjps-ietf@jpshallow.com]
Sent: Friday, December 22, 2017 4:00 PM
To: Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@McAfee.com>; dots@ietf.org
Subject: RE: [Dots] DOTS gateway loop handling

 

Hi Tiru= ,

&n= bsp;

I’= ;m not sure that we can necessarily support this as a Header, but certainly= as a parameter in the CBOR / JSON

&n= bsp;

I think= the most likely scenario for this loop to happen is if DNS is not working = as expected.

&n= bsp;

Regards=

&n= bsp;

Jon

&n= bsp;

From: Dots [mailto: dots-bounces@ietf.org] On B= ehalf Of Konda, Tirumaleswar Reddy
Sent: 22 December 2017 10:24
To: Jon Shallow; dots@ietf.org<= br> Subject: Re: [Dots] DOTS gateway loop handling

 

Good poin= t, both drafts can use a mechanism similar to the one discussed in https://tools.iet= f.org/html/rfc7332#section-5 (Max-forwards header).

&nbs= p;

-Tiru

&nbs= p;

From:<= /span> Dots [mailto:dots-bounces@ietf.org] On Behalf Of Jon Shallow
Sent: Friday, December 22, 2017 2:53 PM
To: dots@ietf.org
Subject: [Dots] DOTS gateway loop handling

 

Hi WG,

 

While there never should be a l= oop in DOTS traffic going via DOTS gateways, if there is a mis-configuratio= n a request can end up getting bounced between a set of (not necessarily ad= jacent) DOTS gateways.

 

We need to make sure that this = loop is broken – possibly by using a mechanism similar to TTL in IP p= ackets.

 

If we agree that loops need to = get broken, this “feature” needs to get added into both the sig= nal and data channels.

 

Regards

 

Jon

--_000_DM5PR16MB1788B1713F3D1802BAE1CA62EA100DM5PR16MB1788namp_-- From nobody Wed Jan 10 05:06:43 2018 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 525451200B9; Wed, 10 Jan 2018 05:06:41 -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.68.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151558960128.3874.13496978563847191742@ietfa.amsl.com> Date: Wed, 10 Jan 2018 05:06:41 -0800 Archived-At: Subject: [Dots] I-D Action: draft-ietf-dots-signal-channel-15.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, 10 Jan 2018 13:06:41 -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-15.txt Pages : 89 Date : 2018-01-10 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 purposes. 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 o This RFC Please update TBD statements with the port number to be assigned to DOTS Signal Channel Protocol. 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-15 https://datatracker.ietf.org/doc/html/draft-ietf-dots-signal-channel-15 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dots-signal-channel-15 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 Jan 10 05:23:31 2018 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 37BFA124319 for ; Wed, 10 Jan 2018 05:23:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.63 X-Spam-Level: X-Spam-Status: No, score=-2.63 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 zpYqHibquNss for ; Wed, 10 Jan 2018 05:23:27 -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 F2A2212420B for ; Wed, 10 Jan 2018 05:23:26 -0800 (PST) Received: from opfedar02.francetelecom.fr (unknown [xx.xx.xx.4]) by opfedar22.francetelecom.fr (ESMTP service) with ESMTP id 8605261668 for ; Wed, 10 Jan 2018 14:23:25 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.19]) by opfedar02.francetelecom.fr (ESMTP service) with ESMTP id 6D12518006F for ; Wed, 10 Jan 2018 14:23:25 +0100 (CET) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM44.corporate.adroot.infra.ftgroup ([fe80::b08d:5b75:e92c:a45f%18]) with mapi id 14.03.0361.001; Wed, 10 Jan 2018 14:23:25 +0100 From: To: "dots@ietf.org" Thread-Topic: [Dots] I-D Action: draft-ietf-dots-signal-channel-15.txt Thread-Index: AQHTihPeEcbaxknpDEGbJ+tzHQbzZaNtE6eg Date: Wed, 10 Jan 2018 13:23:24 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93300A0AEC5D@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <151558960128.3874.13496978563847191742@ietfa.amsl.com> In-Reply-To: <151558960128.3874.13496978563847191742@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.6] 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-15.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, 10 Jan 2018 13:23:29 -0000 Hi all,=20 This new version integrates almost all received comments. In particular, th= e changes in this version are as follows:=20 * Introduce CUID (Client Unique Identifier) which meant to disambiguate cli= ents that belong to the same domain.=20 * Rename client-identifier to client-domain-hash: This parameter is inserte= d by a server-domain gateway to supply the identity of the origin client do= main to the server. This information will be used by the server to enforce = policies. Only single-valued client-domain-hash are allowed. * Fix the target resource to be included in the options, not the message bo= dy. * Rename "attack-time-config and peace-time-config" to "mitigating-config a= nd idle-config" =20 * Update the YANG module with some missing attributes (e.g., redirected sig= naling) * Discuss SNI support * Add some text about authentication There is still one pending comment from Jon: hop-limit. We have prepared so= me text for it, but it is not included in -15 because we do need more feedb= ack from the WG to further assess if this feature is really useful. FWIW, I= 'm inserting the description below: =20 =3D=3D hop-limit: This attribute is used to detect and prevent infinite loops. This attribute is typically inserted by a DOTS gateway. Each intermediate DOTS agent involved in the handling of a DOTS message MUST decrement the hop-limit value by 1 prior to forwarding upstream if this parameter exists. DOTS messages MUST NOT be forwarded if the value of hop-limit is set to '0' after decrement. Messages that cannot be forwarded because of exhausted hop-limit SHOULD be logged with a 5.06 (Hop Limit Reached) error message sent back to the DOTS peer. It is RECOMMENDED that DOTS clients and gateways support means to alert administrators about loop errors so that appropriate actions are undertaken. The initial hop-limit value SHOULD be configurable. If no initial value is explicitly provided, the default initial hop-limit value of 16 MUST be used. Because forwarding errors may occur if inadequate hop-limit values are used, DOTS agents at the boundaries of an administrative domain MAY be instructed to rewrite the value of hop-limit carried in received messages (that is, ignore the value of hop-limit received in a message). This is an optional attribute. =3D=3D Please review and share comments.=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 10 janvier 2018 14:07 > =C0=A0: i-d-announce@ietf.org > Cc=A0: dots@ietf.org > Objet=A0: [Dots] I-D Action: draft-ietf-dots-signal-channel-15.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-15.txt > Pages : 89 > Date : 2018-01-10 >=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 > purposes. >=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 > o This RFC >=20 > Please update TBD statements with the port number to be assigned to > DOTS Signal Channel Protocol. >=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-15 > https://datatracker.ietf.org/doc/html/draft-ietf-dots-signal-channel-15 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dots-signal-channel-15 >=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 Jan 11 06:57:38 2018 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 67CB51204DA; Thu, 11 Jan 2018 06:57:32 -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.68.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151568265234.29478.1772033314182451877@ietfa.amsl.com> Date: Thu, 11 Jan 2018 06:57:32 -0800 Archived-At: Subject: [Dots] I-D Action: draft-ietf-dots-signal-channel-16.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, 11 Jan 2018 14:57:32 -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-16.txt Pages : 89 Date : 2018-01-11 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 purposes. 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 o This RFC Please update TBD statements with the port number to be assigned to DOTS Signal Channel Protocol. 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-16 https://datatracker.ietf.org/doc/html/draft-ietf-dots-signal-channel-16 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dots-signal-channel-16 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 Jan 11 07:35:07 2018 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 B46FC12D7EB for ; Thu, 11 Jan 2018 07:35:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.629 X-Spam-Level: X-Spam-Status: No, score=-2.629 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 bt203SO_aWkp for ; Thu, 11 Jan 2018 07:35:03 -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 6729112EABD for ; Thu, 11 Jan 2018 07:35:03 -0800 (PST) Received: from opfednr01.francetelecom.fr (unknown [xx.xx.xx.65]) by opfednr22.francetelecom.fr (ESMTP service) with ESMTP id B154D21362 for ; Thu, 11 Jan 2018 16:35:01 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.69]) by opfednr01.francetelecom.fr (ESMTP service) with ESMTP id 996701A0056 for ; Thu, 11 Jan 2018 16:35:01 +0100 (CET) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILMA2.corporate.adroot.infra.ftgroup ([fe80::bc1c:ad2f:eda3:8c3d%18]) with mapi id 14.03.0361.001; Thu, 11 Jan 2018 16:35:00 +0100 From: To: "dots@ietf.org" Thread-Topic: I-D Action: draft-ietf-dots-signal-channel-16.txt Thread-Index: AQHTiuyJY8GKB1q1eEKMPilwocoFoaNuw4BA Date: Thu, 11 Jan 2018 15:34:59 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93300A0AFA85@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <151568265234.29478.1772033314182451877@ietfa.amsl.com> In-Reply-To: <151568265234.29478.1772033314182451877@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.2] 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-16.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, 11 Jan 2018 15:35:07 -0000 Hi all,=20 This version integrates the remaining comments we had in our to-do list:=20 * Update the CBOR mapping table to include JSON types * fix the problem with CoAP libraries, mitigation-id appears in the uri opt= ion * and some other minor edits.=20 Please review. Cheers, Med=20 > -----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: jeudi 11 janvier 2018 15:58 > =C0=A0: i-d-announce@ietf.org > Cc=A0: dots@ietf.org > Objet=A0: I-D Action: draft-ietf-dots-signal-channel-16.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-16.txt > Pages : 89 > Date : 2018-01-11 >=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 > purposes. >=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 > o This RFC >=20 > Please update TBD statements with the port number to be assigned to > DOTS Signal Channel Protocol. >=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-16 > https://datatracker.ietf.org/doc/html/draft-ietf-dots-signal-channel-16 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dots-signal-channel-16 >=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 Thu Jan 11 07:58:19 2018 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 0DA8C12EBB2; Thu, 11 Jan 2018 07:58:16 -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.68.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151568629601.29470.12213056611720774787@ietfa.amsl.com> Date: Thu, 11 Jan 2018 07:58:16 -0800 Archived-At: Subject: [Dots] I-D Action: draft-ietf-dots-data-channel-12.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, 11 Jan 2018 15:58:16 -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-12.txt Pages : 36 Date : 2018-01-11 Abstract: The document specifies a Distributed Denial-of-Service Open Threat Signaling (DOTS) data channel used for bulk exchange of data that cannot 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-12 https://datatracker.ietf.org/doc/html/draft-ietf-dots-data-channel-12 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dots-data-channel-12 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 Jan 11 08:04:24 2018 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 22ECE12EBB7 for ; Thu, 11 Jan 2018 08:04:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.629 X-Spam-Level: X-Spam-Status: No, score=-2.629 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 BIOFHJLXgERV for ; Thu, 11 Jan 2018 08:04:14 -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 D0F0112D943 for ; Thu, 11 Jan 2018 08:04:13 -0800 (PST) Received: from opfednr02.francetelecom.fr (unknown [xx.xx.xx.66]) by opfednr22.francetelecom.fr (ESMTP service) with ESMTP id A6247212E9 for ; Thu, 11 Jan 2018 17:04:12 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.60]) by opfednr02.francetelecom.fr (ESMTP service) with ESMTP id 8AA5F120073 for ; Thu, 11 Jan 2018 17:04:12 +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; Thu, 11 Jan 2018 17:04:10 +0100 From: To: "dots@ietf.org" CC: JACQUENET Christian IMT/OLN Thread-Topic: [Dots] I-D Action: draft-ietf-dots-data-channel-12.txt Thread-Index: AQHTivUCNBIH8+ROJ0qOpD5/JVp+36Nu1Cyw Date: Thu, 11 Jan 2018 16:04:09 +0000 Message-ID: References: <151568629601.29470.12213056611720774787@ietfa.amsl.com> In-Reply-To: <151568629601.29470.12213056611720774787@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.2] 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-12.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, 11 Jan 2018 16:04:16 -0000 Re-, The main changes in this version are as follows:=20 * Integrate the comments from Christian (https://mailarchive.ietf.org/arch/= msg/dots/Bx8n_I3zWxYYEcHtlLWw7X8p3Jw) * Align with the signal-channel spec, e.g., introduce cuid * Introduce the lifetime to avoid maintaining stale ACL entries * Specify the DOTS ACL profile * Fix the examples * Remove the JSON registry ...and many other edits.=20 Please review and share your comments.=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: jeudi 11 janvier 2018 16:58 > =C0=A0: i-d-announce@ietf.org > Cc=A0: dots@ietf.org > Objet=A0: [Dots] I-D Action: draft-ietf-dots-data-channel-12.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-12.txt > Pages : 36 > Date : 2018-01-11 >=20 > Abstract: > The document specifies a Distributed Denial-of-Service Open Threat > Signaling (DOTS) data channel used for bulk exchange of data that > cannot 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-12 > https://datatracker.ietf.org/doc/html/draft-ietf-dots-data-channel-12 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dots-data-channel-12 >=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 Fri Jan 12 06:58:31 2018 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 2067912E887 for ; Fri, 12 Jan 2018 06:58:29 -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 PIczgcTZ7PMg for ; Fri, 12 Jan 2018 06:58: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 11E66127775 for ; Fri, 12 Jan 2018 06:58:26 -0800 (PST) Received: from delp.sei.cmu.edu (delp.sei.cmu.edu [10.64.21.31]) by veto.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id w0CEwPVA036682 for ; Fri, 12 Jan 2018 09:58:25 -0500 DKIM-Filter: OpenDKIM Filter v2.11.0 veto.sei.cmu.edu w0CEwPVA036682 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cert.org; s=yc2bmwvrj62m; t=1515769105; bh=YeObpXNdK8sQnKiMpTub2Gy0/TWZ2wpiuoD74WGKpUY=; h=From:To:Subject:Date:From; b=erb7y5cMHLAf92PjVQ1kSLtLuEilx7nksYuc/AuUMbmh2ci+P/oxdrUbqf9nHk6Z3 vRVvxbTHFZs7Z+8s3S9b0iFIYNNj5n0hyEZNopGRVCh2DDc/Xp4kjGDBlWrP5jvVuX pHLTJpQ5zLubknGiWgF36qMhylJDtz21J+zcmsb8= Received: from CASSINA.ad.sei.cmu.edu (cassina.ad.sei.cmu.edu [10.64.28.249]) by delp.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id w0CEwP48020508 for ; Fri, 12 Jan 2018 09:58:25 -0500 Received: from MARATHON.ad.sei.cmu.edu ([10.64.28.250]) by CASSINA.ad.sei.cmu.edu ([10.64.28.249]) with mapi id 14.03.0361.001; Fri, 12 Jan 2018 09:58:24 -0500 From: Roman Danyliw To: "dots@ietf.org" Thread-Topic: Reminder -- February 2018 Virtual Interim Meeting Scheduling Poll Thread-Index: AdOLtYayhF8F0KugRJayYcD8xi9L5Q== Date: Fri, 12 Jan 2018 14:58:24 +0000 Message-ID: <359EC4B99E040048A7131E0F4E113AFC0131361149@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] Reminder -- February 2018 Virtual Interim Meeting Scheduling Poll 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, 12 Jan 2018 14:58:29 -0000 Hello WG! A reminder to please add your availability for a virtual interim meeting to= the poll, https://doodle.com/poll/3pfpzvn3sdqk64ai Regards, Roman -----Original Message----- From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Roman Danyliw Sent: Friday, January 5, 2018 12:59 PM To: dots@ietf.org Subject: [Dots] February 2018 Virtual Interim Meeting Scheduling Poll Hello WG! We're approaching the half-way point between the Singapore and upcoming Lon= don meeting and would benefit from synchronizing with a virtual interim mee= ting. The proposed agenda would be a subset of the following: ** Implementation feedback ** Signal and Data channel drafts ** Hackathon participation Help suggest the best day to virtually meet during the week of February 5th= , 2018 by completing a Doodle poll -- https://doodle.com/poll/3pfpzvn3sdqk6= 4ai. Your input would be appreciated by Friday, January 12, 2018 and results wil= l be announced on Saturday, January 13, 2018. Regards, Roman _______________________________________________ Dots mailing list Dots@ietf.org https://www.ietf.org/mailman/listinfo/dots From nobody Sun Jan 14 09:32:43 2018 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 34EBE12D863 for ; Sun, 14 Jan 2018 09:32:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.102 X-Spam-Level: X-Spam-Status: No, score=-0.102 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, 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 ih8PhYLDvsT5 for ; Sun, 14 Jan 2018 09:32:39 -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 EE0FB126DC2 for ; Sun, 14 Jan 2018 09:32:38 -0800 (PST) Received: from delp.sei.cmu.edu (delp.sei.cmu.edu [10.64.21.31]) by veto.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id w0EHWb0u007880 for ; Sun, 14 Jan 2018 12:32:37 -0500 DKIM-Filter: OpenDKIM Filter v2.11.0 veto.sei.cmu.edu w0EHWb0u007880 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cert.org; s=yc2bmwvrj62m; t=1515951157; bh=v0vfmnyeRSULRidsQLGAYEEh5kr53jaFYpjoWKNdYUw=; h=From:To:Subject:Date:From; b=nhputx8LMcre2V/+Bs/7RzEdndgFCj9QqlTRg0F0EjKzLKhRVP++WHTbGAijapJy7 h7zO0AnnRQBIML6dG2zkHt7igEkKd4PMs7AHCqymBtj1jdYyqFYcI5jsMQJIxqhaoB 4OkE1fhSoOkGp4zBo+PL6QAROMwziV5tBAljfiZg= Received: from CASSINA.ad.sei.cmu.edu (cassina.ad.sei.cmu.edu [10.64.28.249]) by delp.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id w0EHWY29008779 for ; Sun, 14 Jan 2018 12:32:34 -0500 Received: from MARATHON.ad.sei.cmu.edu ([10.64.28.250]) by CASSINA.ad.sei.cmu.edu ([10.64.28.249]) with mapi id 14.03.0361.001; Sun, 14 Jan 2018 12:32:33 -0500 From: Roman Danyliw To: "dots@ietf.org" Thread-Topic: Virtual Interim Meeting: Wednesday, February 7, 2018 Thread-Index: AdONXIDndmrnPL5jS8mk9+migHb44A== Date: Sun, 14 Jan 2018 17:32:33 +0000 Message-ID: <359EC4B99E040048A7131E0F4E113AFC0131368858@marathon> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.64.22.6] Content-Type: multipart/mixed; boundary="_002_359EC4B99E040048A7131E0F4E113AFC0131368858marathon_" MIME-Version: 1.0 Archived-At: Subject: [Dots] Virtual Interim Meeting: Wednesday, February 7, 2018 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, 14 Jan 2018 17:32:41 -0000 --_002_359EC4B99E040048A7131E0F4E113AFC0131368858marathon_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello WG! Based on the scheduling poll, a DOTS virtual interim meeting has been sched= uled for Wednesday, February 7, 2018 from 15:00 - 16:30 UTC. Thank you for= everyone's participation in choosing this date and your flexibility in sch= eduling. Please send any requests for time on the agenda to the chairs. =3D=3D[ Date/Time ]=3D=3D Wednesday, February 7, 2018 15:00 - 16:30 UTC Start time in select local time zones =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=3D=3D San Francisco, USA -- February 7, 2018 at 7:00 am=20 New York, USA -- February 7, 2018 at 10:00 am=20 UTC (GMT) -- February 7, 2018 at 3:00 pm =20 London, UK -- February 7, 2018 at 3:00 pm =20 Berlin, Germany -- February 7, 2018 at 4:00 pm=20 New Delhi, India -- February 7, 2018 at 8:30 pm=20 Bangkok, Thailand -- February 7, 2018 at 10:00 pm=20 Beijing, China -- February 7, 2018 at 11:00 pm =3D=3D[ Tentative Agenda ]=3D=3D 1. Note well, logistics and introduction (chairs, 10 min) 2. Use Case Discussion (10 min)=20 3. Architecture Discussion (10 min) 4. IETF 101 Hackathon Coordination (10 min) 5. Protocol Drafts (45 min) - Implementation Reports - Signal and Data Channel drafts=20 6. Closing (chairs, 5 min) =3D=3D[ WebEx Information ]=3D=3D Meeting URL: https://ietf.webex.com/ietf/j.php?MTID=3Dm7918038a2dcc50d69146acbfa69c31eb Meeting number: 640 129 123=20 Meeting password: AT2ShnfU=20 =20 Dial-in Numbers: 1-877-668-4493 Call-in toll free number (US/Canada) 1-650-479-3208 Call-in toll number (US/Canada) Access code: 640 129 123=20 =3D=3D=3D=3D --_002_359EC4B99E040048A7131E0F4E113AFC0131368858marathon_ Content-Type: text/calendar; name="WebEx_Meeting.ics" Content-Description: WebEx_Meeting.ics Content-Disposition: attachment; filename="WebEx_Meeting.ics"; size=3715; creation-date="Sun, 14 Jan 2018 17:24:14 GMT"; modification-date="Sun, 14 Jan 2018 17:19:06 GMT" Content-Transfer-Encoding: base64 QkVHSU46VkNBTEVOREFSClBST0RJRDotLy9NaWNyb3NvZnQgQ29ycG9yYXRpb24vL091dGxvb2sg MTAuMCBNSU1FRElSLy9FTgpWRVJTSU9OOjIuMApNRVRIT0Q6UkVRVUVTVApCRUdJTjpWVElNRVpP TkUKVFpJRDpFYXN0ZXJuIFRpbWUKQkVHSU46U1RBTkRBUkQKRFRTVEFSVDoyMDE2MTEwMVQwMjAw MDAKUlJVTEU6RlJFUT1ZRUFSTFk7SU5URVJWQUw9MTtCWURBWT0xU1U7QllNT05USD0xMQpUWk9G RlNFVEZST006LTA0MDAKVFpPRkZTRVRUTzotMDUwMApUWk5BTUU6U3RhbmRhcmQgVGltZQpFTkQ6 U1RBTkRBUkQKQkVHSU46REFZTElHSFQKRFRTVEFSVDoyMDE2MDMwMVQwMjAwMDAKUlJVTEU6RlJF UT1ZRUFSTFk7SU5URVJWQUw9MTtCWURBWT0yU1U7QllNT05USD0zClRaT0ZGU0VURlJPTTotMDUw MApUWk9GRlNFVFRPOi0wNDAwClRaTkFNRTpEYXlsaWdodCBTYXZpbmdzIFRpbWUKRU5EOkRBWUxJ R0hUCkVORDpWVElNRVpPTkUKQkVHSU46VkVWRU5UCkFUVEVOREVFO0NOPSJERG9TIE9wZW4gVGhy ZWF0IFNpZ25hbGluZyBXb3JraW5nIEdyb3VwIjtST0xFPVJFUS1QQVJUSUNJUEFOVDtSU1ZQPUZB TFNFOk1BSUxUTzpkb3RzLWNoYWlyc0BpZXRmLm9yZwpPUkdBTklaRVI7Q049IndlYmV4IjpNQUlM VE86bWVzc2VuZ2VyQHdlYmV4LmNvbQpEVFNUQVJUO1RaSUQ9IkVhc3Rlcm4gVGltZSI6MjAxODAy MDdUMTAwMDAwCkRURU5EO1RaSUQ9IkVhc3Rlcm4gVGltZSI6MjAxODAyMDdUMTEzMDAwCkxPQ0FU SU9OOmh0dHBzOi8vaWV0Zi53ZWJleC5jb20vaWV0ZgpUUkFOU1A6T1BBUVVFClNFUVVFTkNFOjE1 MTU5NTAzNDEKVUlEOmUxNDUxMDg2LTJlMTMtNDVmYy1iMjI5LTI2MDJmYzIyYTY5MwpEVFNUQU1Q OjIwMTgwMjA3VDE1MDAwMFoKREVTQ1JJUFRJT046XG5cbkpPSU4gV0VCRVggTUVFVElOR1xuaHR0 cHM6Ly9pZXRmLndlYmV4LmNvbS9pZXRmL2oucGhwP01USUQ9bTgyZDJjMjE1OTY5NWZjZDk3Yzk4 ZTM0MWUzNzNiZjE2XG5NZWV0aW5nIG51bWJlciAoYWNjZXNzIGNvZGUpOiA2NDAgMTI5IDEyM1xu SG9zdCBrZXk6IDk2NzIzMFxuTWVldGluZyBwYXNzd29yZDogQVQyU2huZlVcblxuXG5cbkpPSU4g QlkgUEhPTkVcbjEtODc3LTY2OC00NDkzIENhbGwtaW4gdG9sbCBmcmVlIG51bWJlciAoVVMvQ2Fu YWRhKSBcbjEtNjUwLTQ3OS0zMjA4IENhbGwtaW4gdG9sbCBudW1iZXIgKFVTL0NhbmFkYSlcblxu VG9sbC1mcmVlIGRpYWxpbmcgcmVzdHJpY3Rpb25zOiBcbmh0dHBzOi8vd3d3LndlYmV4LmNvbS9w ZGYvdG9sbGZyZWVfcmVzdHJpY3Rpb25zLnBkZlxuXG5cblxuQ2FuJ3Qgam9pbiB0aGUgbWVldGlu Zz8gQ29udGFjdCBzdXBwb3J0IGhlcmU6XG5odHRwczovL2lldGYud2ViZXguY29tL2lldGYvbWNc blxuXG5JTVBPUlRBTlQgTk9USUNFOiBQbGVhc2Ugbm90ZSB0aGF0IHRoaXMgV2ViRXggc2Vydmlj ZSBhbGxvd3MgYXVkaW8gYW5kIG90aGVyIGluZm9ybWF0aW9uIHNlbnQgZHVyaW5nIHRoZSBzZXNz aW9uIHRvIGJlIHJlY29yZGVkLCB3aGljaCBtYXkgYmUgZGlzY292ZXJhYmxlIGluIGEgbGVnYWwg bWF0dGVyLiBZb3Ugc2hvdWxkIGluZm9ybSBhbGwgbWVldGluZyBhdHRlbmRlZXMgcHJpb3IgdG8g cmVjb3JkaW5nIGlmIHlvdSBpbnRlbmQgdG8gcmVjb3JkIHRoZSBtZWV0aW5nLlxuClgtQUxULURF U0M7Rk1UVFlQRT10ZXh0L2h0bWw6CTxGT05UIFNJWkU9IjEiIEZBQ0U9IkFSSUFMIj48Rk9OVCBT SVpFPSI0IiBGQUNFPSJBUklBTCI+CQk8YSBocmVmPSJodHRwczovL2lldGYud2ViZXguY29tL2ll dGYvai5waHA/TVRJRD1tODJkMmMyMTU5Njk1ZmNkOTdjOThlMzQxZTM3M2JmMTYiPjxGT05UIFNJ WkU9IjMiIENPTE9SPSIjMDBBRkY5IiBGQUNFPSJBcmlhbCI+Sm9pbiBXZWJFeCBtZWV0aW5nPC9G T05UPjwvYT4JCQk8dGFibGU+CQkJCTx0cj4JCQkJCTx0ZD4JCQkJCQk8Rk9OVCBTSVpFPSIyIiBD T0xPUj0iIzY2NjY2NiIgRkFDRT0iYXJpYWwiPk1lZXRpbmcgbnVtYmVyIChhY2Nlc3MgY29kZSk6 IDY0MCAxMjkgMTIzPC9GT05UPgkJCQkJPC90ZD4JCQkJPC90cj4JCQk8L3RhYmxlPgkJCTx0YWJs ZT4JCQkJPHRyPgkJCQkJPHRkPgkJCQkJCTxGT05UIFNJWkU9IjIiIENPTE9SPSIjNjY2NjY2IiBG QUNFPSJhcmlhbCI+SG9zdCBrZXk6IDk2NzIzMDwvRk9OVD4JCQkJCTwvdGQ+CQkJCTwvdHI+CQkJ PC90YWJsZT4JCQk8dGFibGU+PHRyPjx0ZD48Rk9OVCBTSVpFPSIyIiBDT0xPUj0iIzY2NjY2NiIg RkFDRT0iYXJpYWwiPk1lZXRpbmcgcGFzc3dvcmQ6PC9GT05UPjwvdGQ+PHRkPjxGT05UIFNJWkU9 IjIiICBDT0xPUj0iIzY2NjY2NiIgRkFDRT0iYXJpYWwiPkFUMlNobmZVPC9GT05UPjwvdGQ+PC90 cj48L3RhYmxlPgkJPC9GT05UPjxicj48Rk9OVCBzaXplPSIyIiBDT0xPUj0iI0ZGMDAwMCI+PC9G T05UPjxicj48Rk9OVCBTSVpFPSIxIiBGQUNFPSJBUklBTCI+Jm5ic3A7PEJSPiZuYnNwOzxCUj48 L0ZPTlQ+PEZPTlQgU0laRT0iNCIgRkFDRT0iQVJJQUwiPjxGT05UIFNJWkU9IjMiIENPTE9SPSIj NjY2NjY2IiBGQUNFPSJhcmlhbCI+Sm9pbiBieSBwaG9uZTwvRk9OVD4mbmJzcDsgPEJSPjxGT05U IFNJWkU9IjIiIENPTE9SPSIjNjY2NjY2IiBGQUNFPSJhcmlhbCI+PHN0cm9uZz4xLTg3Ny02Njgt NDQ5Mzwvc3Ryb25nPiZuYnNwO0NhbGwtaW4gdG9sbCBmcmVlIG51bWJlciAoVVMvQ2FuYWRhKTwv Rk9OVD4mbmJzcDsgPEJSPjxGT05UIFNJWkU9IjIiIENPTE9SPSIjNjY2NjY2IiBGQUNFPSJhcmlh bCI+PHN0cm9uZz4xLTY1MC00NzktMzIwODwvc3Ryb25nPiZuYnNwO0NhbGwtaW4gdG9sbCBudW1i ZXIgKFVTL0NhbmFkYSk8L0ZPTlQ+Jm5ic3A7IDxCUj48YSBocmVmPSJodHRwczovL3d3dy53ZWJl eC5jb20vcGRmL3RvbGxmcmVlX3Jlc3RyaWN0aW9ucy5wZGYiPjxGT05UIFNJWkU9IjEiIENPTE9S PSIjMDBBRkY5IiBGQUNFPSJhcmlhbCI+VG9sbC1mcmVlIGNhbGxpbmcgcmVzdHJpY3Rpb25zPC9G T05UPjwvYT4gJm5ic3A7IDxCUj48L0ZPTlQ+PEJSPjxCUj4JJm5ic3A7PEJSPgk8Rk9OVCBTSVpF PSIxIiBDT0xPUj0iIzY2NjY2NiIgRkFDRT0iYXJpYWwiPgkJCQlDYW4ndCBqb2luIHRoZSBtZWV0 aW5nPzwvRk9OVD4JPGEgaHJlZj0iaHR0cHM6Ly9pZXRmLndlYmV4LmNvbS9pZXRmL21jIj4JPEZP TlQgU0laRT0iMSIgQ09MT1I9IiMwMEFGRjkiIEZBQ0U9IkFyaWFsIj5Db250YWN0IHN1cHBvcnQu PC9GT05UPjwvYT4JJm5ic3A7PEJSPiZuYnNwOzxCUj48Rk9OVCBDT0xPUj0iI0EwQTBBMCIgc2l6 ZT0iMSIgRkFDRT0iYXJpYWwiPklNUE9SVEFOVCBOT1RJQ0U6IFBsZWFzZSBub3RlIHRoYXQgdGhp cyBXZWJFeCBzZXJ2aWNlIGFsbG93cyBhdWRpbyBhbmQgb3RoZXIgaW5mb3JtYXRpb24gc2VudCBk dXJpbmcgdGhlIHNlc3Npb24gdG8gYmUgcmVjb3JkZWQsIHdoaWNoIG1heSBiZSBkaXNjb3ZlcmFi bGUgaW4gYSBsZWdhbCBtYXR0ZXIuIFlvdSBzaG91bGQgaW5mb3JtIGFsbCBtZWV0aW5nIGF0dGVu ZGVlcyBwcmlvciB0byByZWNvcmRpbmcgaWYgeW91IGludGVuZCB0byByZWNvcmQgdGhlIG1lZXRp bmcuPC9GT05UPjwvRk9OVD4KU1VNTUFSWTpET1RTIFdHIFZpcnR1YWwgSW50ZXJpbSBNZWV0aW5n ClBSSU9SSVRZOjUKQ0xBU1M6UFVCTElDCkJFR0lOOlZBTEFSTQpUUklHR0VSOi1QVDVNCkFDVElP TjpESVNQTEFZCkRFU0NSSVBUSU9OOlJlbWluZGVyCkVORDpWQUxBUk0KRU5EOlZFVkVOVApFTkQ6 VkNBTEVOREFSCg== --_002_359EC4B99E040048A7131E0F4E113AFC0131368858marathon_-- From nobody Mon Jan 15 09:16:10 2018 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 31A1E12E89E; Mon, 15 Jan 2018 09:15:58 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IESG Secretary To: "IETF-Announce" Cc: dots@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.68.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151603655769.28451.11840905931307281396@ietfa.amsl.com> Date: Mon, 15 Jan 2018 09:15:58 -0800 Archived-At: Subject: [Dots] DDoS Open Threat Signaling (dots) WG Virtual Meeting: 2018-02-07 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, 15 Jan 2018 17:16:06 -0000 The DDoS Open Threat Signaling (dots) Working Group will hold a virtual interim meeting on 2018-02-07 from 10:00 to 11:30 America/New_York. Agenda: ==[ Tentative Agenda ]== 1. Note well, logistics and introduction (chairs, 10 min) 2. Use Case Discussion (10 min) 3. Architecture Discussion (10 min) 4. IETF 101 Hackathon Coordination (10 min) 5. Protocol Drafts (45 min) - Implementation Reports - Signal and Data Channel drafts 6. Closing (chairs, 5 min) Information about remote participation: https://ietf.webex.com/ietf/j.php?MTID=m7918038a2dcc50d69146acbfa69c31eb https://mailarchive.ietf.org/arch/msg/dots/RzxkbNIL6n0ROfokZxyHjT8xe0M From nobody Mon Jan 22 08:03:56 2018 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 74F53127444 for ; Mon, 22 Jan 2018 08:03:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.629 X-Spam-Level: X-Spam-Status: No, score=-2.629 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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, T_RP_MATCHES_RCVD=-0.01, 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 3LsjQozl6sVK for ; Mon, 22 Jan 2018 08:03:53 -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 B017F126DD9 for ; Mon, 22 Jan 2018 08:03:52 -0800 (PST) Received: from opfedar00.francetelecom.fr (unknown [xx.xx.xx.11]) by opfedar20.francetelecom.fr (ESMTP service) with ESMTP id 366FB120961; Mon, 22 Jan 2018 17:03:51 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.69]) by opfedar00.francetelecom.fr (ESMTP service) with ESMTP id 0E4B518003F; Mon, 22 Jan 2018 17:03:51 +0100 (CET) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILMA2.corporate.adroot.infra.ftgroup ([fe80::bc1c:ad2f:eda3:8c3d%18]) with mapi id 14.03.0382.000; Mon, 22 Jan 2018 17:03:50 +0100 From: To: "dots@ietf.org" CC: "Konda, Tirumaleswar Reddy (TirumaleswarReddy_Konda@McAfee.com)" , "Jon Shallow (supjps-ietf@jpshallow.com)" Thread-Topic: draft-ietf-dots-data-channel: RESTCONF/draft-ietf-netmod-acl-model Thread-Index: AdOTmpbqvDSQETmlQ6yiGuxH0/F2IQ== Date: Mon, 22 Jan 2018 16:03:50 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93300A0C4DB6@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.4] Content-Type: multipart/alternative; boundary="_000_787AE7BB302AE849A7480A190F8B93300A0C4DB6OPEXCLILMA3corp_" MIME-Version: 1.0 Archived-At: Subject: [Dots] draft-ietf-dots-data-channel: RESTCONF/draft-ietf-netmod-acl-model 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, 22 Jan 2018 16:03:54 -0000 --_000_787AE7BB302AE849A7480A190F8B93300A0C4DB6OPEXCLILMA3corp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, We started to integrate the changes in -15 version of the ACL YANG publishe= d last week. FWIW, a working copy of draft-ietf-dots-data-channel is availa= ble at: https://github.com/boucadair/IETF-Drafts-Reviews/blob/master/wdiff%20draft-= ietf-dots-data-channel-12.txt%20draft-ietf-dots-data-channel-13.pdf We have many issues to be handled, but we will focus in this message on the= one related to the ACL YANG module. Because of the implications of augmenting the ACL module, we are struggling= how to achieve the following operations using RESTCONF: * Retrieve a filtering entry (or all entries) created by a DOTS cli= ent. A DOTS client is allowed to see only its entries. The same acl name ma= y be used by distinct DOTS clients. * Delete a filtering entry that was instantiated by a given DOTS cl= ient. Those operations could be achieved if we managed to have a module that woul= d look like the following: ... +--rw dots-client* [cuid] +--rw cuid string +--rw cdid? string +--rw acl* [name] +--rw name string +--rw type? acl-type +--rw lifetime int32 +--rw aces +--rw ace* [name] +--rw name string +--rw matches | +--rw (l3)? | | +--:(ipv4) .. Jon, Tiru, and muself are discussing the proposed updated module at: https:= //github.com/boucadair/IETF-Drafts-Reviews/blob/master/ietf-dots-data-chann= el%402018-01-22.yang All: Can you please let us know if you have any objection if we proceed wit= h that proposal instead of the augments? Chairs: We do think that it would be useful to liaise with netmod WG to let= them know about the DOTS requirements that are not easily met by augmentin= g the current ACL module. Further, we have investigated other alternate sol= utions such mount schema, but those are not suitable for what we want to ac= hieve. Can you please let know how we should proceed? Thank you. Cheers, Tiru & Med --_000_787AE7BB302AE849A7480A190F8B93300A0C4DB6OPEXCLILMA3corp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi all,

 

We started to integrate the changes in -15 = version of the ACL YANG published last week. FWIW, a working copy of draft-= ietf-dots-data-channel is available at:

https://github.com/boucadair/IETF-Draf= ts-Reviews/blob/master/wdiff%20draft-ietf-dots-data-channel-12.txt%20draft-= ietf-dots-data-channel-13.pdf

 

We have many issues to be handled, but we w= ill focus in this message on the one related to the ACL YANG module.

 

Because of the implications of augmenting t= he ACL module, we are struggling how to achieve the following operations us= ing RESTCONF:

·         Retrieve a filtering entry (or all entries) created by a DO= TS client. A DOTS client is allowed to see only its entries. The same acl n= ame may be used by distinct DOTS clients.

·         Delete a filtering entry that was instantiated by a given D= OTS client.

 

Those operations could be achieved if we ma= naged to have a module that would look like the following:

 

   &= nbsp;   …

   &= nbsp;   +--rw dots-client* [cuid]

   &= nbsp;      +--rw cuid    string=

   &= nbsp;      +--rw cdid?   string=

   &= nbsp;      +--rw acl* [name]=

   &= nbsp;         +--rw name &= nbsp;      string

   &= nbsp;         +--rw type? =       acl-type

   &= nbsp;         +--rw lifetime&nb= sp;   int32

   &= nbsp;         +--rw aces

   &= nbsp;            = 3;--rw ace* [name]

   &= nbsp;           &nbs= p;   +--rw name       &nbs= p;  string

   &= nbsp;           &nbs= p;   +--rw matches

   &= nbsp;           &nbs= p;   |  +--rw (l3)?

   &= nbsp;           &nbs= p;   |  |  +--:(ipv4)

   &= nbsp;           &nbs= p;     ..

 

 

Jon, Tiru, and muself are discussing the pr= oposed updated module at: https://github.com/boucadair/IETF-Drafts-Reviews/blob/master/ietf-dots-data= -channel%402018-01-22.yang  

 

All: Can you please let us know if you have= any objection if we proceed with that proposal instead of the augments?

 

Chairs: We do think that it would be useful= to liaise with netmod WG to let them know about the DOTS requirements that= are not easily met by augmenting the current ACL module. Further, we have investigated other alternate solutions such mount= schema, but those are not suitable for what we want to achieve. Can you pl= ease let know how we should proceed?

 

Thank you.

 

Cheers,

Tiru & Med

 

--_000_787AE7BB302AE849A7480A190F8B93300A0C4DB6OPEXCLILMA3corp_-- From nobody Tue Jan 23 02:16:54 2018 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 41C64126CD8; Tue, 23 Jan 2018 02:16:53 -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.69.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151670261321.29635.6386409409623203114@ietfa.amsl.com> Date: Tue, 23 Jan 2018 02:16:53 -0800 Archived-At: Subject: [Dots] I-D Action: draft-ietf-dots-signal-channel-17.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, 23 Jan 2018 10:16:53 -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 Specification Authors : Tirumaleswar Reddy Mohamed Boucadair Prashanth Patil Andrew Mortensen Nik Teague Filename : draft-ietf-dots-signal-channel-17.txt Pages : 84 Date : 2018-01-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 purposes. 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 Please update TBD statements with the port number to be assigned to DOTS Signal Channel Protocol. 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-17 https://datatracker.ietf.org/doc/html/draft-ietf-dots-signal-channel-17 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dots-signal-channel-17 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 Jan 23 02:35:21 2018 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 0189612D96A for ; Tue, 23 Jan 2018 02:35:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.629 X-Spam-Level: X-Spam-Status: No, score=-2.629 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 KkqLIFscEgoU for ; Tue, 23 Jan 2018 02:34:57 -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 A8FAC12DA02 for ; Tue, 23 Jan 2018 02:34:39 -0800 (PST) Received: from opfedar07.francetelecom.fr (unknown [xx.xx.xx.9]) by opfedar27.francetelecom.fr (ESMTP service) with ESMTP id 28DE5614AB for ; Tue, 23 Jan 2018 11:34:38 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.43]) by opfedar07.francetelecom.fr (ESMTP service) with ESMTP id 0F865C008E for ; Tue, 23 Jan 2018 11:34:38 +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.0382.000; Tue, 23 Jan 2018 11:34:38 +0100 From: To: "dots@ietf.org" Thread-Topic: [Dots] I-D Action: draft-ietf-dots-signal-channel-17.txt Thread-Index: AQHTlDNN1hMe4T89wUuZjRVUZ7pIUqOBPksQ Date: Tue, 23 Jan 2018 10:34:37 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93300A0C54D7@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <151670261321.29635.6386409409623203114@ietfa.amsl.com> In-Reply-To: <151670261321.29635.6386409409623203114@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.2] 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-17.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, 23 Jan 2018 10:35:11 -0000 Hi all,=20 A new version of this document is available online. The changes are as foll= ows: * Clarify the use of cuid and cdid parameters.=20 * Update the CBOR mapping table to include JSON and YANG types. Also, param= eters was reordered to follow the YANG tree structure. *** This change has = a consequence on implementations. *** * Double check the use of uri-path and query parameters + call out when the= se parameters are mandatory + shorten the name of uri-*. * Reorganize some parts of the text for better readability=20 * Clarify that the signal channel YANG module is meant to govern the signal= -channel messages; the YANG module to be used for server management purpose= s is clearly out of scope. * and fix nits. Many thanks to Jon who helped to enhance this specification. Jon validated = many pieces of the specification using his implementation. Much appreciated= !=20 As an editor of the document, I do think that this version is (almost) stab= le and unless there are major concerns, the plan is to have a WGLC for the = document.=20 In the meantime, please review and share your comments. We will be more tha= n happy to discuss and address them.=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: mardi 23 janvier 2018 11:17 > =C0=A0: i-d-announce@ietf.org > Cc=A0: dots@ietf.org > Objet=A0: [Dots] I-D Action: draft-ietf-dots-signal-channel-17.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 Specification > Authors : Tirumaleswar Reddy > Mohamed Boucadair > Prashanth Patil > Andrew Mortensen > Nik Teague > Filename : draft-ietf-dots-signal-channel-17.txt > Pages : 84 > Date : 2018-01-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. >=20 > A companion document defines the DOTS data channel, a separate > reliable communication layer for DOTS management and configuration > purposes. >=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 > Please update TBD statements with the port number to be assigned to > DOTS Signal Channel Protocol. >=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-17 > https://datatracker.ietf.org/doc/html/draft-ietf-dots-signal-channel-17 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dots-signal-channel-17 >=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 Tue Jan 23 14:27:01 2018 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 04DBC12D84E; Tue, 23 Jan 2018 14:26:55 -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.69.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151674641498.15562.4768813409058823004@ietfa.amsl.com> Date: Tue, 23 Jan 2018 14:26:55 -0800 Archived-At: Subject: [Dots] I-D Action: draft-ietf-dots-requirements-11.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, 23 Jan 2018 22:26:55 -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 (DDoS) Open Threat Signaling Requirements Authors : Andrew Mortensen Robert Moskowitz Tirumaleswar Reddy Filename : draft-ietf-dots-requirements-11.txt Pages : 20 Date : 2018-01-23 Abstract: This document defines the requirements for the Distributed Denial of Service (DDoS) Open Threat Signaling (DOTS) protocols enabling coordinated response to DDoS attacks. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dots-requirements/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-dots-requirements-11 https://datatracker.ietf.org/doc/html/draft-ietf-dots-requirements-11 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dots-requirements-11 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 Jan 23 14:29:41 2018 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 5927112D863 for ; Tue, 23 Jan 2018 14:29:39 -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 cMQ4xrK6jYLI for ; Tue, 23 Jan 2018 14:29:37 -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 5931F12D84E for ; Tue, 23 Jan 2018 14:29:37 -0800 (PST) Received: from pps.filterd (m0072399.ppops.net [127.0.0.1]) by mx0b-00196b01.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w0NMR2uD031487 for ; Tue, 23 Jan 2018 17:29:35 -0500 Received: from nam03-co1-obe.outbound.protection.outlook.com (mail-co1nam03lp0020.outbound.protection.outlook.com [216.32.181.20]) by mx0b-00196b01.pphosted.com with ESMTP id 2fkyvymje2-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT) for ; Tue, 23 Jan 2018 17:29:35 -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=DCbiZ1uOiuSJ58v4CgGWN1Zypayx24r+Ch758nnndlU=; b=krkey35Q7KNsYM+4B8T4u3hG5XfN1Wsg9Gusj0Qs0RzNPlbU5bhrkD+ydXnKCtDLp6tx6G3sTcUgQBQEdUGZGyM5Ri5Uo2KB0rvCI0s9ANYiQ+GruacHB1tiU3ZZwEi+ZyXjWMbzJ+fYDqXWNWz8lixEJBnzOI+X2fXl14yR8UQ= Received: from CO2PR01MB1989.prod.exchangelabs.com (10.166.90.142) by CO2PR01MB1990.prod.exchangelabs.com (10.166.90.143) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.428.17; Tue, 23 Jan 2018 22:29:32 +0000 Received: from CO2PR01MB1989.prod.exchangelabs.com ([10.166.90.142]) by CO2PR01MB1989.prod.exchangelabs.com ([10.166.90.142]) with mapi id 15.20.0428.019; Tue, 23 Jan 2018 22:29:32 +0000 From: "Mortensen, Andrew" To: dots Thread-Topic: [Dots] I-D Action: draft-ietf-dots-requirements-11.txt Thread-Index: AQHTlJlNES/+1tFsdU6+psOAvXkKNKOCChOA Date: Tue, 23 Jan 2018 22:29:32 +0000 Message-ID: <1867660E-4B54-405F-B87E-3CDBC2D46442@arbor.net> References: <151674641498.15562.4768813409058823004@ietfa.amsl.com> In-Reply-To: <151674641498.15562.4768813409058823004@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2620:11e:1000:10:b1a3:67cc:42d7:9096] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; CO2PR01MB1990; 6:ouj4aKvv+K0RFO6Ltnodzb/3BfEfNr4WsCFck3S3jA5e+8Sk6sxW/DuwQbCUloM4iMtKG8T32EdnIStehA+v5IpUHK3V3IGGCYbtqmHKVU5b+XiWqGGNgt9Ezrj2enCmZobU3phCuVvirW8tLPEpt2Z+zhMVPp68raAvVH0mPAEJwu5RMiak6umEeVPtqnTfgbT7yStIJIkncuB7TjNDV/Fu2+or+6sO3a8rkCKhq5JQcBWXAyuHCgtWXgSWVlN62Jg4XfqVaPcge/BLk3zVrZaA23c7aG8p2rYn1nMulaNhwcFy8kRL4zkGmrkRzAvjs584v19cCqfUirF0IbKIncyXYh+yMHoXoh1uyGkBU60B1PRy2V+Jk+mJGc0tmaBJ; 5:jhl7QvhZZ3fz5Ui07OoeyHbzfcbkjXXWgWmTgwwYovpFIuGIqnesOrtZDk5/3dy/NN71ONciXTAA6BUoQHeoePl8dj1l4MpCOFuFuY5i22gj1Ym0smqsN/6wPEl7J8AVJPlBUul/j7xkcmKy3N9EikqpEzz2nDRGroqRtPbOEFU=; 24:rDw/boY5vC+NqYjtFeXlt+/a+f8l4dKi0oghAMHgxkwqIpO+hQ/buDb9fe9YPYuQXDuvXY4fc9BBba4VABi4TR19jDieFvF4rCHd9vE7OcI=; 7:Xx6wOLTR5C7nLsNK72jGB4IoEW++RgenbI1gKcZRyT3yEOIqo4Wd04yKgflFXyeRk5FMa+YRKqayKA6mDXU55G+JemuCCqDCsGKVQrrkUqQ2GwB6IqZaFKjOMjvHwF6Y+vEt/AiPVLzx2raI/DJuxT28Tm6d4Y/z1YhBjefGU+kSVaSCJGJKUK8D0Pqx+HTKqxCuMie6VpsEgsbZAa2Xrjj4rbh4qxkkjd8yPEpoKx4pcxiuFpjALGXQNHT3DREH x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: db36f96d-7edb-4adb-e12d-08d562b0c68f x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(4604075)(3008032)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603307)(7153060)(7193020); SRVR:CO2PR01MB1990; x-ms-traffictypediagnostic: CO2PR01MB1990: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(192374486261705); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040501)(2401047)(5005006)(8121501046)(93006095)(93001095)(3002001)(3231023)(2400081)(944501161)(10201501046)(6041288)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123562045)(20161123560045)(20161123564045)(20161123558120)(6072148)(201708071742011); SRVR:CO2PR01MB1990; BCL:0; PCL:0; RULEID:; SRVR:CO2PR01MB1990; x-forefront-prvs: 05610E64EE x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(396003)(39860400002)(346002)(376002)(39380400002)(366004)(199004)(189003)(377424004)(36756003)(8676002)(6916009)(478600001)(5660300001)(6436002)(6512007)(83716003)(33656002)(2950100002)(53936002)(81156014)(230783001)(102836004)(99286004)(81166006)(229853002)(76176011)(6506007)(59450400001)(53546011)(68736007)(14454004)(106356001)(77096007)(6486002)(105586002)(82746002)(305945005)(86362001)(6246003)(2900100001)(3660700001)(3280700002)(7736002)(6116002)(97736004)(2906002)(8936002)(25786009)(316002); DIR:OUT; SFP:1102; SCL:1; SRVR:CO2PR01MB1990; H:CO2PR01MB1989.prod.exchangelabs.com; 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-antispam-message-info: WvI8NbajGWn7VoIdljdioRjb80+2WbGAGwuj8RekVvvUZ+L7ZjDgmLkj+hP/SGPrF36fvnXiIBthsIleM5ufkA== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-ID: <86010EFDBD24FF4FBA4B4918FF07FAA7@prod.exchangelabs.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: arbor.net X-MS-Exchange-CrossTenant-Network-Message-Id: db36f96d-7edb-4adb-e12d-08d562b0c68f X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Jan 2018 22:29:32.6314 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 54f11205-d4aa-4809-bd36-0b542199c5b2 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO2PR01MB1990 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-01-23_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 mlxscore=0 impostorscore=0 mlxlogscore=797 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1801230290 Archived-At: Subject: Re: [Dots] I-D Action: draft-ietf-dots-requirements-11.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, 23 Jan 2018 22:29:39 -0000 This revision incorporates all WGLC feedback, including an expanded securit= y considerations section. andrew > On Jan 23, 2018, at 5:26 PM, internet-drafts@ietf.org wrote: >=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 (DDoS) Open Threat= Signaling Requirements > Authors : Andrew Mortensen > Robert Moskowitz > Tirumaleswar Reddy > Filename : draft-ietf-dots-requirements-11.txt > Pages : 20 > Date : 2018-01-23 >=20 > Abstract: > This document defines the requirements for the Distributed Denial of > Service (DDoS) Open Threat Signaling (DOTS) protocols enabling > coordinated response to DDoS attacks. From nobody Wed Jan 24 00:57:19 2018 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 6CB1D12D965 for ; Wed, 24 Jan 2018 00:57:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.63 X-Spam-Level: X-Spam-Status: No, score=-2.63 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 90yAJ5HPnyGV for ; Wed, 24 Jan 2018 00:57:15 -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 BF3DE12D847 for ; Wed, 24 Jan 2018 00:57:15 -0800 (PST) Received: from opfednr06.francetelecom.fr (unknown [xx.xx.xx.70]) by opfednr24.francetelecom.fr (ESMTP service) with ESMTP id 5A516413CC; Wed, 24 Jan 2018 09:57:14 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.17]) by opfednr06.francetelecom.fr (ESMTP service) with ESMTP id 406851A00B5; Wed, 24 Jan 2018 09:57:14 +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.0382.000; Wed, 24 Jan 2018 09:57:14 +0100 From: To: "Mortensen, Andrew" , dots Thread-Topic: [Dots] I-D Action: draft-ietf-dots-requirements-11.txt Thread-Index: AQHTlJlNZWUvt9Zb0EudHMZk2DWVeaOB+VEAgACYnTA= Date: Wed, 24 Jan 2018 08:57:13 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93300A0C5F86@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <151674641498.15562.4768813409058823004@ietfa.amsl.com> <1867660E-4B54-405F-B87E-3CDBC2D46442@arbor.net> In-Reply-To: <1867660E-4B54-405F-B87E-3CDBC2D46442@arbor.net> 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-requirements-11.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, 24 Jan 2018 08:57:17 -0000 Hi Andrew,=20 Thank you for this updated version.=20 Looks good to me.=20 Some very minor comments below, FWIW:=20 * I don't parse this one:=20 The DOTS server and client must also have some standardized method of defining the scope of any mitigation, and negotiating related mitigation communication and actions and communications. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ * s/for a negotiated time interval or lifetime/for a negotiated time interv= al * s/SIG-010: Network Address Translator Traversal:/ SIG-010 Network Addres= s Translator Traversal: * s/"DM-001: Structure:"/"DM-001 Structure:" * Same change as above for DM-002-DM-009 * s/channel requirements in Section 2.1 and Section 2.2/channel requirement= s in Sections 2.1 and 2.2 * I don't parse this one "Blocking communication between DOTS agents-signal= blocking-has the..." * Add an "IANA Considerations" which basically says: "This document does no= t require any IANA action.".=20 * Remove RFC5405 from the references=20 Cheers, Med > -----Message d'origine----- > De=A0: Dots [mailto:dots-bounces@ietf.org] De la part de Mortensen, Andre= w > Envoy=E9=A0: mardi 23 janvier 2018 23:30 > =C0=A0: dots > Objet=A0: Re: [Dots] I-D Action: draft-ietf-dots-requirements-11.txt >=20 > This revision incorporates all WGLC feedback, including an expanded > security considerations section. >=20 > andrew >=20 >=20 > > On Jan 23, 2018, at 5:26 PM, internet-drafts@ietf.org wrote: > > > > > > 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 (DDoS) Open > Threat Signaling Requirements > > Authors : Andrew Mortensen > > Robert Moskowitz > > Tirumaleswar Reddy > > Filename : draft-ietf-dots-requirements-11.txt > > Pages : 20 > > Date : 2018-01-23 > > > > Abstract: > > This document defines the requirements for the Distributed Denial of > > Service (DDoS) Open Threat Signaling (DOTS) protocols enabling > > coordinated response to DDoS attacks. >=20 > _______________________________________________ > Dots mailing list > Dots@ietf.org > https://www.ietf.org/mailman/listinfo/dots From nobody Wed Jan 24 04:23:00 2018 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 BCB1A1200F1 for ; Wed, 24 Jan 2018 04:22:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 P9LEYrpN5dVc for ; Wed, 24 Jan 2018 04:22:56 -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 6F0811200E5 for ; Wed, 24 Jan 2018 04:22:56 -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 1eeK4q-0002fQ-UN; Wed, 24 Jan 2018 12:22:53 +0000 From: "Jon Shallow" To: "Mortensen, Andrew" , References: <151674641498.15562.4768813409058823004@ietfa.amsl.com> <1867660E-4B54-405F-B87E-3CDBC2D46442@arbor.net> <787AE7BB302AE849A7480A190F8B93300A0C5F86@OPEXCLILMA3.corporate.adroot.infra.ftgroup> In-Reply-To: <787AE7BB302AE849A7480A190F8B93300A0C5F86@OPEXCLILMA3.corporate.adroot.infra.ftgroup> Date: Wed, 24 Jan 2018 12:22:52 -0000 Message-ID: <0cb501d3950e$0e956970$2bc03c50$@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 Content-Language: en-gb Thread-Index: AQJ5ab1ci+yv597yyML+ycymhWTtfQLExSLWAhr2hxqiEEUFgA== Archived-At: Subject: Re: [Dots] I-D Action: draft-ietf-dots-requirements-11.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, 24 Jan 2018 12:22:59 -0000 Hi Andrew, There are 2 pending resolution issues raised about the signal / data channels which may need to be included in the requirements draft. I was planning on raising the 2 pending resolutions at the upcoming Virtual Meeting. 1) Signal/Data path loop detection protection. There is some proposed text by Med about loop detection by the use of a hop-limit parameter. Do we need tis? https://mailarchive.ietf.org/arch/msg/dots/63MfwLTldONbO9gO_sdT6FG2DxQ=20 2) Signal Channel support for Filter usage Should a signal channel mitigation request be able to specify which = Filters to use as set up by the Data channel? https://mailarchive.ietf.org/arch/msg/dots/kuINxI8XrcIgL1IuxjI-mvo2U1E=20 Regards Jon -----Original Message----- From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of mohamed.boucadair@orange.com Sent: 24 January 2018 08:57 To: Mortensen, Andrew; dots Subject: Re: [Dots] I-D Action: draft-ietf-dots-requirements-11.txt Hi Andrew,=20 Thank you for this updated version.=20 Looks good to me.=20 Some very minor comments below, FWIW:=20 * I don't parse this one:=20 The DOTS server and client must also have some standardized method of defining the scope of any mitigation, and negotiating related mitigation communication and actions and communications. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ * s/for a negotiated time interval or lifetime/for a negotiated time interval * s/SIG-010: Network Address Translator Traversal:/ SIG-010 Network = Address Translator Traversal: * s/"DM-001: Structure:"/"DM-001 Structure:" * Same change as above for DM-002-DM-009 * s/channel requirements in Section 2.1 and Section 2.2/channel = requirements in Sections 2.1 and 2.2 * I don't parse this one "Blocking communication between DOTS = agents-signal blocking-has the..." * Add an "IANA Considerations" which basically says: "This document does = not require any IANA action.".=20 * Remove RFC5405 from the references=20 Cheers, Med > -----Message d'origine----- > De=A0: Dots [mailto:dots-bounces@ietf.org] De la part de Mortensen,=20 > Andrew Envoy=E9=A0: mardi 23 janvier 2018 23:30 =C0=A0: dots Objet=A0: = Re:=20 > [Dots] I-D Action: draft-ietf-dots-requirements-11.txt >=20 > This revision incorporates all WGLC feedback, including an expanded=20 > security considerations section. >=20 > andrew >=20 >=20 > > On Jan 23, 2018, at 5:26 PM, internet-drafts@ietf.org wrote: > > > > > > 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=20 > > the > IETF. > > > > Title : Distributed Denial of Service (DDoS) Open > Threat Signaling Requirements > > Authors : Andrew Mortensen > > Robert Moskowitz > > Tirumaleswar Reddy > > Filename : draft-ietf-dots-requirements-11.txt > > Pages : 20 > > Date : 2018-01-23 > > > > Abstract: > > This document defines the requirements for the Distributed Denial = of > > Service (DDoS) Open Threat Signaling (DOTS) protocols enabling > > coordinated response to DDoS attacks. >=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 From nobody Wed Jan 24 05:26:30 2018 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 3417B124207 for ; Wed, 24 Jan 2018 05:26:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.011 X-Spam-Level: X-Spam-Status: No, score=-7.011 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, T_RP_MATCHES_RCVD=-0.01] 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 bxF3Rc-AJQAL for ; Wed, 24 Jan 2018 05:26:25 -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 729391241FC for ; Wed, 24 Jan 2018 05:26:25 -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=1516800383; h=From: To:Subject:Thread-Topic:Thread-Index:Date: Message-ID:References:In-Reply-To:Accept-Language: Content-Language:X-MS-Has-Attach:X-MS-TNEF-Correlator: dlp-product:dlp-version:dlp-reaction: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: x-microsoft-antispam-message-info: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 Mz0Mf/EUtGQoQDyNhZUpJ8Vwo8QeO3m3pftaGMXaZ 4=; b=idDq+3mm1Esw70vJuTBReieqFej/2+5zTbl1wgNiY+ts 2aERTjPy4nQUUmTyXF+VBDfYEIhJjK/bYgrbxVsX8nyOZyczR5 qVys5HjpAbHWw0uz67IbaM+/ZZOOplSAUS0gUCxM9rWW5IaJlh qOEWmgij1dDbCaIL3z5piYJb+3M= Received: from MIVEXAPP1N03.corpzone.internalzone.com (unknown [10.48.48.90]) by MIVWSMAILOUT1.mcafee.com with smtp (TLS: TLSv1/SSLv3,256bits,ECDHE-RSA-AES256-SHA384) id 0a3d_1029_a98500a9_977f_4ea7_b259_dc4d4e5b9420; Wed, 24 Jan 2018 07:26:23 -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; Wed, 24 Jan 2018 08:26:21 -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; Wed, 24 Jan 2018 08:26:20 -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, 24 Jan 2018 08:26:20 -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; Wed, 24 Jan 2018 08:26:17 -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.428.17; Wed, 24 Jan 2018 13:26:16 +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.0428.019; Wed, 24 Jan 2018 13:26:16 +0000 From: "Konda, Tirumaleswar Reddy" To: Jon Shallow , "Mortensen, Andrew" , "dots@ietf.org" Thread-Topic: [Dots] I-D Action: draft-ietf-dots-requirements-11.txt Thread-Index: AQHTlJlfRJI5svGx70KmFmcv7D1Xz6OCChQAgACvX4CAADl2AIAAETXw Date: Wed, 24 Jan 2018 13:26:16 +0000 Message-ID: References: <151674641498.15562.4768813409058823004@ietfa.amsl.com> <1867660E-4B54-405F-B87E-3CDBC2D46442@arbor.net> <787AE7BB302AE849A7480A190F8B93300A0C5F86@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <0cb501d3950e$0e956970$2bc03c50$@jpshallow.com> In-Reply-To: <0cb501d3950e$0e956970$2bc03c50$@jpshallow.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-version: 11.0.130.24 dlp-reaction: no-action x-originating-ip: [122.171.111.5] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DM5PR16MB1788; 7:oO0TLdVks+pP8t7crx06WFofbTDmIUjkoDZPuLPmsOp7YmT16QkBUQRbVDL9qHLDuasVTCAo8ToR09lZswWsHT3xnCKpr8NdyePT+LD8OvBdbCoYQuoT6Az0AHOj6n9180YKDt8Qs3ivCjbzYJb6en5Cl/gNXCOKMGoIiGA2ALafBx92jNDvdqbO9RS1inzvPJj4bKt3YNZ1focBLpkoOOdlriPyVCsxbsM7MH6xtmlfm3qgDId+QZzrpAWYqMN4 x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 9c0fdae6-cd16-41ea-e740-08d5632e0c13 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(4534165)(4627221)(201703031133081)(201702281549075)(5600026)(4604075)(3008032)(2017052603307)(7153060)(7193020); SRVR:DM5PR16MB1788; x-ms-traffictypediagnostic: DM5PR16MB1788: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(192374486261705)(18271650672692); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040501)(2401047)(8121501046)(5005006)(10201501046)(3231023)(2400081)(944501161)(93006095)(93001095)(3002001)(6041288)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123562045)(20161123558120)(20161123564045)(6072148)(201708071742011); SRVR:DM5PR16MB1788; BCL:0; PCL:0; RULEID:; SRVR:DM5PR16MB1788; x-forefront-prvs: 056297E276 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39860400002)(39380400002)(346002)(376002)(396003)(366004)(32952001)(55784002)(13464003)(377424004)(57704003)(199004)(189003)(72206003)(230783001)(345774005)(14454004)(966005)(478600001)(76176011)(93886005)(2900100001)(7696005)(316002)(6436002)(66066001)(55016002)(9686003)(6306002)(59450400001)(53936002)(110136005)(229853002)(3660700001)(53546011)(6506007)(102836004)(2501003)(86362001)(106356001)(2950100002)(97736004)(5660300001)(8676002)(6346003)(81166006)(81156014)(74316002)(25786009)(77096007)(105586002)(305945005)(2906002)(7736002)(80792005)(3280700002)(6246003)(3846002)(33656002)(99286004)(26005)(6116002)(8936002)(68736007)(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; x-microsoft-antispam-message-info: eAIi6ygPyAQ2Y372N7kgQAb/ZRBmNPjxywJAFwczUc+QbEAyiLhEeC/YtgP/Mpsg/AeC58PJzS6ZVYo8eoYhPA== 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: 9c0fdae6-cd16-41ea-e740-08d5632e0c13 X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Jan 2018 13:26:16.3819 (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 <6207> : inlines <6335> : streams <1776963> : uri <2578273> Archived-At: Subject: Re: [Dots] I-D Action: draft-ietf-dots-requirements-11.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, 24 Jan 2018 13:26:28 -0000 > -----Original Message----- > From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Jon Shallow > Sent: Wednesday, January 24, 2018 5:53 PM > To: Mortensen, Andrew ; dots@ietf.org > Subject: Re: [Dots] I-D Action: draft-ietf-dots-requirements-11.txt >=20 > Hi Andrew, >=20 > There are 2 pending resolution issues raised about the signal / data chan= nels > which may need to be included in the requirements draft. I was planning = on > raising the 2 pending resolutions at the upcoming Virtual Meeting. >=20 > 1) Signal/Data path loop detection protection. >=20 > There is some proposed text by Med about loop detection by the use of a > hop-limit parameter. Do we need tis? > https://mailarchive.ietf.org/arch/msg/dots/63MfwLTldONbO9gO_sdT6FG2D > xQ I don't see an agreement on this one, please see my last response https://m= ailarchive.ietf.org/arch/msg/dots/p3TaRiNkZOrZ5PKr3UIXe10g9CU -Tiru >=20 > 2) Signal Channel support for Filter usage >=20 > Should a signal channel mitigation request be able to specify which Filte= rs to > use as set up by the Data channel? > https://mailarchive.ietf.org/arch/msg/dots/kuINxI8XrcIgL1IuxjI-mvo2U1E >=20 >=20 >=20 > Regards >=20 > Jon >=20 > -----Original Message----- > From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of > mohamed.boucadair@orange.com > Sent: 24 January 2018 08:57 > To: Mortensen, Andrew; dots > Subject: Re: [Dots] I-D Action: draft-ietf-dots-requirements-11.txt >=20 > Hi Andrew, >=20 > Thank you for this updated version. >=20 > Looks good to me. >=20 > Some very minor comments below, FWIW: >=20 > * I don't parse this one: >=20 > The DOTS server and client must also have some standardized method of > defining the scope of any mitigation, and negotiating related > mitigation communication and actions and communications. > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >=20 > * s/for a negotiated time interval or lifetime/for a negotiated time inte= rval > * s/SIG-010: Network Address Translator Traversal:/ SIG-010 Network > Address Translator Traversal: > * s/"DM-001: Structure:"/"DM-001 Structure:" > * Same change as above for DM-002-DM-009 > * s/channel requirements in Section 2.1 and Section 2.2/channel > requirements in Sections 2.1 and 2.2 > * I don't parse this one "Blocking communication between DOTS agents- > signal blocking-has the..." > * Add an "IANA Considerations" which basically says: "This document does > not require any IANA action.". > * Remove RFC5405 from the references >=20 > Cheers, > Med >=20 > > -----Message d'origine----- > > De=A0: Dots [mailto:dots-bounces@ietf.org] De la part de Mortensen, > > Andrew Envoy=E9=A0: mardi 23 janvier 2018 23:30 =C0=A0: dots Objet=A0: = Re: > > [Dots] I-D Action: draft-ietf-dots-requirements-11.txt > > > > This revision incorporates all WGLC feedback, including an expanded > > security considerations section. > > > > andrew > > > > > > > On Jan 23, 2018, at 5:26 PM, internet-drafts@ietf.org wrote: > > > > > > > > > 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 (DDoS) Open > > Threat Signaling Requirements > > > Authors : Andrew Mortensen > > > Robert Moskowitz > > > Tirumaleswar Reddy > > > Filename : draft-ietf-dots-requirements-11.txt > > > Pages : 20 > > > Date : 2018-01-23 > > > > > > Abstract: > > > This document defines the requirements for the Distributed Denial o= f > > > Service (DDoS) Open Threat Signaling (DOTS) protocols enabling > > > coordinated response to DDoS attacks. > > > > _______________________________________________ > > 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 >=20 > _______________________________________________ > Dots mailing list > Dots@ietf.org > https://www.ietf.org/mailman/listinfo/dots From nobody Wed Jan 24 05:28:47 2018 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 E1533124207 for ; Wed, 24 Jan 2018 05:28:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.629 X-Spam-Level: X-Spam-Status: No, score=-2.629 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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, T_RP_MATCHES_RCVD=-0.01, 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 yLrpUC__VYyc for ; Wed, 24 Jan 2018 05:28:43 -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 609E81241FC for ; Wed, 24 Jan 2018 05:28:43 -0800 (PST) Received: from opfedar01.francetelecom.fr (unknown [xx.xx.xx.2]) by opfedar20.francetelecom.fr (ESMTP service) with ESMTP id AF2E6121478; Wed, 24 Jan 2018 14:28:41 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.63]) by opfedar01.francetelecom.fr (ESMTP service) with ESMTP id 915E61600AA; Wed, 24 Jan 2018 14:28:41 +0100 (CET) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM6E.corporate.adroot.infra.ftgroup ([fe80::f5a7:eab1:c095:d9ec%18]) with mapi id 14.03.0382.000; Wed, 24 Jan 2018 14:28:41 +0100 From: To: Jon Shallow , "dots@ietf.org" Thread-Topic: [Dots] Filter usage Thread-Index: AdOAvMIC7WALjv/0TF6u38Ag24OGtAUWIAig Date: Wed, 24 Jan 2018 13:28:41 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93300A0C624D@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <09aa01d380bc$c8e5d9b0$5ab18d10$@jpshallow.com> In-Reply-To: <09aa01d380bc$c8e5d9b0$5ab18d10$@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_787AE7BB302AE849A7480A190F8B93300A0C624DOPEXCLILMA3corp_" MIME-Version: 1.0 Archived-At: Subject: Re: [Dots] Filter usage 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, 24 Jan 2018 13:28:46 -0000 --_000_787AE7BB302AE849A7480A190F8B93300A0C624DOPEXCLILMA3corp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Jon, Some comments below: =B7 Providing =AB hints =BB to the server may be misleading for the= server in some cases. This may influence the contractual responsibility en= gaged by a mitigation providers (e.g., observe long delays to soften an att= ack because the hint was misleading). =B7 A hint is by definition optional, as such it can be defined as = a separate extension (if needed). The signal-channel should IMHO focus on t= he minimum required information to achieve its intended function. I would not add such feature to the base spec. Cheers, Med De : Dots [mailto:dots-bounces@ietf.org] De la part de Jon Shallow Envoy=E9 : vendredi 29 d=E9cembre 2017 16:51 =C0 : dots@ietf.org Objet : [Dots] Filter usage Hi WG, Should a mitigation request be able to define which filters to use? This has been raised in the past but there was no real closure - but other = related things did get fixed. An ACL can comprise of a src/dest IP prefix, port etc. and an action - drop= , allow or rate-limit. A Filter definition can contain multiple ACLs - the ACLs are now orderable. An individual DOTS client can now define multiple Filters - the Filters are= now orderable. However, today, when a mitigation request comes into the DOTS server, all t= he Filter rules associated with a DOTS client are taken and passed over to = a DOTS mitigation (how etc. out of scope of DOTS, as well as what the mitig= ator does with them is out of scope). The primary use of the Filters would be for White / Black listed IPs (the s= rc IP prefix and action defined in an ACL) and there is an implied assumpti= on that the DOTS mitigator would only apply these White / Black lists to th= e IPs that are to be mitigated (i.e. an implicit dest IP prefix is defined = / added in). These White / Black lists would tend to be fairly static and = normally would be updated during peace time. However, by using draft-ietf-netconf-acl-model as the basis for these filte= rs adds in the potential for intelligent DOTS clients to come up with speci= fic ACLs and hence filters which could be used as hints for the DOTS mitiga= tor. The different filters can easily be created / deleted during peace ti= me - but if an attack is ongoing, a DOTS client may not be able to update t= he current set of Filters. This therefore potentially limits potential use= of special filters (which potentially needing updating as an attack morphs= ) matching the current attack characteristics. There is one camp that thinks that Filters (other than black/white lists) s= hould not be supported (for a variety of reasons - e.g. DOTS is not to repr= oduce FlowSpec, complexity and numbers of ACLs will overwhelm the infrastru= cture etc.) as well as the other camp who like the possibility of flexibili= ty, and in addition say the numbers of ACLs will not be that much different= from the black/white list requirements. To provide this full flexibility, a mitigation request over the signal chan= nel needs to be able to specify an array of Filters (in the same way that a= n array of Alias-names is specified) to use - thereby being able to select = out of a pre-attack configured set Filters which ones to use. This would b= e an update the signal mitigation requirements. Comments welcome. Regards Jon --_000_787AE7BB302AE849A7480A190F8B93300A0C624DOPEXCLILMA3corp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Jon,

 

Some comments below:

=B7    &n= bsp;    Providing =AB hint= s =BB to the server may be misleading for the server in some cases. Th= is may influence the contractual responsibility engaged by a mitigation providers (e.g., observe long delays to soften an attack becaus= e the hint was misleading).

=B7    &n= bsp;    A hint is by definition= optional, as such it can be defined as a separate extension (if needed). T= he signal-channel should IMHO focus on the minimum required information to achieve its intended function.

 

I would not add such feature to= the base spec.

 

Cheers,

Med

 

D= ots [mailto:dots-bounces@ietf.org] De la part de Jon Shallow
Envoy=E9 : vendredi 29 d=E9cembre 2017 16:51
=C0 : dots@ietf.org<= br> Objet : [Dots] Filter usage

 

Hi WG,

 

Should a mitigation request be = able to define which filters to use?

 

This has been raised in the pas= t but there was no real closure – but other related things did get fi= xed.

 

An ACL can comprise of a src/de= st IP prefix, port etc. and an action – drop, allow or rate-limit.

A Filter definition can contain= multiple ACLs – the ACLs are now orderable.

An individual DOTS client can n= ow define multiple Filters – the Filters are now orderable.

 

However, today, when a mitigati= on request comes into the DOTS server, all the Filter rules associated with= a DOTS client are taken and passed over to a DOTS mitigation (how etc. out= of scope of DOTS, as well as what the mitigator does with them is out of scope).

 

The primary use of the Filters = would be for White / Black listed IPs (the src IP prefix and action defined= in an ACL) and there is an implied assumption that the DOTS mitigator woul= d only apply these White / Black lists to the IPs that are to be mitigated (i.e. an implicit dest IP prefix is de= fined / added in).  These White / Black lists would tend to be fairly = static and normally would be updated during peace time.

 

However, by using draft-ietf-ne= tconf-acl-model as the basis for these filters adds in the potential for in= telligent DOTS clients to come up with specific ACLs and hence filters whic= h could be used as hints for the DOTS mitigator.  The different filters can easily be created / deleted dur= ing peace time – but if an attack is ongoing, a DOTS client may not b= e able to update the current set of Filters.  This therefore potential= ly limits potential use of special filters (which potentially needing updating as an attack morphs) matching the current att= ack characteristics.

 

There is one camp that thinks t= hat Filters (other than black/white lists) should not be supported (for a v= ariety of reasons – e.g. DOTS is not to reproduce FlowSpec, complexit= y and numbers of ACLs will overwhelm the infrastructure etc.) as well as the other camp who like the possibility of flexibility, a= nd in addition say the numbers of ACLs will not be that much different from= the black/white list requirements.

 

To provide this full flexibilit= y, a mitigation request over the signal channel needs to be able to specify= an array of Filters (in the same way that an array of Alias-names is speci= fied) to use – thereby being able to select out of a pre-attack configured set Filters which ones to use. = This would be an update the signal mitigation requirements.

 

Comments welcome.

 

Regards

 

Jon

--_000_787AE7BB302AE849A7480A190F8B93300A0C624DOPEXCLILMA3corp_-- From nobody Wed Jan 24 06:02:41 2018 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 E801D1242EA for ; Wed, 24 Jan 2018 06:02:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.331 X-Spam-Level: X-Spam-Status: No, score=-4.331 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, T_RP_MATCHES_RCVD=-0.01] 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 s4E-HmnLLBhH for ; Wed, 24 Jan 2018 06:02: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 A3F6C12426E for ; Wed, 24 Jan 2018 06:02: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=1516802555; h=From: To:Subject:Thread-Topic:Thread-Index:Date: Message-ID:References:In-Reply-To:Accept-Language: Content-Language:X-MS-Has-Attach:X-MS-TNEF-Correlator: dlp-product:dlp-version:dlp-reaction:authentication-results: x-originating-ip:x-ms-publictraffictype:x-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:x-microsoft-antispam-message-info: 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=d/ybHmoQ7CmEPGON/GhifsmM+NsUgSjXjUF/Zb 2Bnbw=; b=ATe7gWQN3+GL/xAisgiShhl2FjwScmLqDRH8eNKK Vp7q27j6imF8PkDb3MKWvxUSGK/z7KhfDfiU9NF3V/R6t2zsmP 62OxkCTgVTi9UJ57vnSp0V0UMBPq1PvyrqoUoGPwVvpWJn4+Rr mq4hpQuogWZr14/hzS3FGQLWv85ZLug= Received: from DNVEXAPP1N04.corpzone.internalzone.com (unknown [10.44.48.88]) by DNVWSMAILOUT1.mcafee.com with smtp (TLS: TLSv1/SSLv3,256bits,ECDHE-RSA-AES256-SHA384) id 391c_415b_9f499a01_6d03_4463_8277_cecfe0d1a61f; Wed, 24 Jan 2018 08:02:34 -0600 Received: from DNVEXUSR1N09.corpzone.internalzone.com (10.44.48.82) by DNVEXAPP1N04.corpzone.internalzone.com (10.44.48.88) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Wed, 24 Jan 2018 07:02:34 -0700 Received: from DNVEXAPP1N04.corpzone.internalzone.com (10.44.48.88) by DNVEXUSR1N09.corpzone.internalzone.com (10.44.48.82) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Wed, 24 Jan 2018 07:02:33 -0700 Received: from DNVO365EDGE2.corpzone.internalzone.com (10.44.176.74) by DNVEXAPP1N04.corpzone.internalzone.com (10.44.48.88) with Microsoft SMTP Server (TLS) id 15.0.1347.2 via Frontend Transport; Wed, 24 Jan 2018 07:02:33 -0700 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, 24 Jan 2018 07:02:31 -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.428.17; Wed, 24 Jan 2018 14:02: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.0428.019; Wed, 24 Jan 2018 14:02:31 +0000 From: "Konda, Tirumaleswar Reddy" To: "Mortensen, Andrew" , dots Thread-Topic: [Dots] I-D Action: draft-ietf-dots-requirements-11.txt Thread-Index: AQHTlJlfRJI5svGx70KmFmcv7D1Xz6OCChQAgAEC5RA= Date: Wed, 24 Jan 2018 14:02:31 +0000 Message-ID: References: <151674641498.15562.4768813409058823004@ietfa.amsl.com> <1867660E-4B54-405F-B87E-3CDBC2D46442@arbor.net> In-Reply-To: <1867660E-4B54-405F-B87E-3CDBC2D46442@arbor.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-version: 11.0.130.24 dlp-reaction: no-action authentication-results: spf=none (sender IP is ) smtp.mailfrom=TirumaleswarReddy_Konda@McAfee.com; x-originating-ip: [122.171.111.5] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DM5PR16MB1786; 7:KyoZ+RWLgPye8vgRlgqyVG0PvIpJaKgggblM1QgmqE3HcyeJUAs6bo42uxOxEVlL+kh12kSpGQdyfAQE/fw4wRE+nrnmPvW4OLxTUU9bdC5vbE4QJ6252gBiC37F9AwFSN2qODY8Sfdg94NTo0unPBR/tw6AT3dM0oQke/crgh2rIhGnPaa+H33NvQb2TDh/lLNObYWJFR1rJMfrmIY7cBxlUG75/YK90nop5ryNB9D6EGGPbq98xgf0/1KYxop4 x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: a5846e36-646d-4f1f-7685-08d563331c80 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(4534165)(4627221)(201703031133081)(201702281549075)(5600026)(4604075)(3008032)(2017052603307)(7153060)(7193020); SRVR:DM5PR16MB1786; x-ms-traffictypediagnostic: DM5PR16MB1786: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(192374486261705); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040501)(2401047)(8121501046)(5005006)(10201501046)(3002001)(93006095)(93001095)(3231023)(2400081)(944501161)(6041288)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(20161123564045)(20161123562045)(20161123558120)(6072148)(201708071742011); SRVR:DM5PR16MB1786; BCL:0; PCL:0; RULEID:; SRVR:DM5PR16MB1786; x-forefront-prvs: 056297E276 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(979002)(376002)(39380400002)(39840400004)(346002)(396003)(366004)(32952001)(199004)(189003)(13464003)(377424004)(3846002)(6506007)(81166006)(68736007)(8936002)(316002)(305945005)(53546011)(6436002)(6306002)(9686003)(81156014)(99286004)(76176011)(74316002)(8676002)(7696005)(55016002)(6116002)(80792005)(2906002)(97736004)(72206003)(102836004)(7736002)(110136005)(66066001)(966005)(229853002)(26005)(3660700001)(77096007)(3280700002)(106356001)(33656002)(86362001)(5660300001)(105586002)(6246003)(25786009)(14454004)(478600001)(2950100002)(230783001)(2900100001)(59450400001)(53936002)(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; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: McAfee.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: blRpjvsqY3teqP9RvkTGCw1PdQ6ND6so+POQwoStF/W7sidz3gdqau5ith3ZqUaktxIdqA6R+ULft2LxjlsLRg== 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: a5846e36-646d-4f1f-7685-08d563331c80 X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Jan 2018 14:02:31.4518 (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 <6207> : inlines <6335> : streams <1776965> : uri <2578292> Archived-At: Subject: Re: [Dots] I-D Action: draft-ietf-dots-requirements-11.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, 24 Jan 2018 14:02:39 -0000 Comments on the security considerations section 1) Traffic injection into a naive DOTS deployment could allow an attacker to affect DOTS operations selectively. Rather than impersonating a DOTS agent directly, the attacker crafts DOTS signal or data channel messages in such a way that the targeted DOTS agent treats them as if they originated with a legitimate DOTS agent, for example, by spoofing the sender's IP address. =20 Comment> Sender IP address is not used by the DOTS server to authenticate = the DOTS client and vice-versa. The only way an attacker can impersonate th= e DOTS agent is by stealing its credentials or compromising the agent. 2) As with agent impersonation, the attacker capable of injecting traffic c= an affect the network path to addresses for which the DOTS client is authorized to request mitigation. Comment> I did not get the above line.=20 3) As detailed in Section 2.4, DOTS implementations require mutual authentication of DOTS agents in order to make agent impersonation and traffic injection more difficult. However, impersonation or traffic injection may still be possible as a result of credential theft, implementation flaws, or compromise of DOTS agents. Operators should take steps to reduce attack surfaces through current secure network communications best practices. Comment> Current best secure network communications will not defend from cr= edential theft or compromise of DOTS agents. DOTS agents need auditing, ana= lytics tools etc.=20 to detect a compromised peer DOTS agent. -Tiru > -----Original Message----- > From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Mortensen, > Andrew > Sent: Wednesday, January 24, 2018 4:00 AM > To: dots > Subject: Re: [Dots] I-D Action: draft-ietf-dots-requirements-11.txt >=20 > This revision incorporates all WGLC feedback, including an expanded secur= ity > considerations section. >=20 > andrew >=20 >=20 > > On Jan 23, 2018, at 5:26 PM, internet-drafts@ietf.org wrote: > > > > > > 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 I= ETF. > > > > Title : Distributed Denial of Service (DDoS) Open Thre= at Signaling > Requirements > > Authors : Andrew Mortensen > > Robert Moskowitz > > Tirumaleswar Reddy > > Filename : draft-ietf-dots-requirements-11.txt > > Pages : 20 > > Date : 2018-01-23 > > > > Abstract: > > This document defines the requirements for the Distributed Denial of > > Service (DDoS) Open Threat Signaling (DOTS) protocols enabling > > coordinated response to DDoS attacks. >=20 > _______________________________________________ > Dots mailing list > Dots@ietf.org > https://www.ietf.org/mailman/listinfo/dots From nobody Wed Jan 24 12:37:18 2018 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 4CB3D129511 for ; Wed, 24 Jan 2018 12:37:17 -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 xTqxvXY-g6Qi for ; Wed, 24 Jan 2018 12:37:15 -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 571C4128961 for ; Wed, 24 Jan 2018 12:37:15 -0800 (PST) Received: from pps.filterd (m0096263.ppops.net [127.0.0.1]) by mx0a-00196b01.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w0OKbFDc005599; Wed, 24 Jan 2018 15:37:15 -0500 Received: from nam01-by2-obe.outbound.protection.outlook.com (mail-by2nam01lp0178.outbound.protection.outlook.com [216.32.181.178]) by mx0a-00196b01.pphosted.com with ESMTP id 2fpk2ts5e1-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Wed, 24 Jan 2018 15:37:15 -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=usdLub5In9765FvImNRVJtGh9JIqehVAYmg2Hnv/4RE=; b=m+QTb7XZ6e9BcVpcn6qjcZwXTfmtwAjZv67jrxpaSZZTQ86whUR8/MN0RkL80cO0Iq4+rTY/ePKQEznzT0I46SSCEk/pWwB9P/US9CSNxySdZYm/gWPUCj1oGZKaHcPLDejXLK/1Hx9FJalxgOWrZ/hn7Xy1Wcm+M7okQC475RI= Received: from BN3PR01MB1987.prod.exchangelabs.com (10.166.71.144) by BN3PR01MB1365.prod.exchangelabs.com (10.163.36.145) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.444.14; Wed, 24 Jan 2018 20:37:12 +0000 Received: from BN3PR01MB1987.prod.exchangelabs.com ([10.166.71.144]) by BN3PR01MB1987.prod.exchangelabs.com ([10.166.71.144]) with mapi id 15.20.0444.015; Wed, 24 Jan 2018 20:37:12 +0000 From: "Mortensen, Andrew" To: "Konda, Tirumaleswar Reddy" CC: dots Thread-Topic: [Dots] I-D Action: draft-ietf-dots-requirements-11.txt Thread-Index: AQHTlJlNES/+1tFsdU6+psOAvXkKNKOCChOAgAEErYCAAG5FgA== Date: Wed, 24 Jan 2018 20:37:12 +0000 Message-ID: References: <151674641498.15562.4768813409058823004@ietfa.amsl.com> <1867660E-4B54-405F-B87E-3CDBC2D46442@arbor.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2620:11e:1000:10:31e1:a74e:4118:5f7f] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BN3PR01MB1365; 7:aEca9U5bUYnZtrXgKNsnSTjM4hwqvbh7I/swCzutROTORkTHOVxwGHcsifJqDbF3OnIkKDUAght9NPe8xrk9FWzQCbWgZHJjywZCB8ir9BZuGWnM6LtwGmeTzmqgqYVNjmVmKXsGhbJJIO6aOhTFbKuuE4fgSHPvUdsq04avDuxXGoDyqAhfoHQLovWUnGuqfD0aOLlX6cZ+nWTqXV5Y9d8LAgyWMAObaQvoTnh6sfRAKFYEwtklpqmgayEBsv9E x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: e9d3fc80-14a0-4694-982d-08d5636a3f73 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(4534165)(4627221)(201703031133081)(201702281549075)(5600026)(4604075)(3008032)(2017052603307)(7153060)(7193020); SRVR:BN3PR01MB1365; x-ms-traffictypediagnostic: BN3PR01MB1365: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(192374486261705)(123452027830198); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040501)(2401047)(5005006)(8121501046)(3231023)(2400081)(944501161)(3002001)(10201501046)(93006095)(93001095)(6041288)(20161123558120)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123564045)(20161123560045)(20161123562045)(6072148)(201708071742011); SRVR:BN3PR01MB1365; BCL:0; PCL:0; RULEID:; SRVR:BN3PR01MB1365; x-forefront-prvs: 056297E276 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(376002)(346002)(396003)(366004)(39860400002)(39380400002)(189003)(199004)(6512007)(99286004)(25786009)(2950100002)(97736004)(4326008)(229853002)(14454004)(6916009)(53546011)(3280700002)(3660700001)(6506007)(186003)(68736007)(102836004)(59450400001)(2900100001)(316002)(81166006)(82746002)(81156014)(7736002)(33656002)(105586002)(6246003)(8676002)(8936002)(77096007)(230783001)(305945005)(5660300001)(106356001)(6116002)(478600001)(2906002)(86362001)(76176011)(53936002)(36756003)(6486002)(83716003)(6436002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR01MB1365; H:BN3PR01MB1987.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) x-microsoft-antispam-message-info: Jas0NPewmRqGxSZvKwJW1H1xaBekT7s99lBe1KmuhFfzC5L7vX5aBtoiC2NLXow26tO9L1X+V3+ZxF9CJCxOZw== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: arbor.net X-MS-Exchange-CrossTenant-Network-Message-Id: e9d3fc80-14a0-4694-982d-08d5636a3f73 X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Jan 2018 20:37:12.4079 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 54f11205-d4aa-4809-bd36-0b542199c5b2 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR01MB1365 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-01-24_08:, , 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 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1801240270 Archived-At: Subject: Re: [Dots] I-D Action: draft-ietf-dots-requirements-11.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, 24 Jan 2018 20:37:17 -0000 VGhhbmtzLCBUaXJ1LiBDb21tZW50cyBpbmxpbmUuDQoNCg0KPiBPbiBKYW4gMjQsIDIwMTgsIGF0 IDk6MDIgQU0sIEtvbmRhLCBUaXJ1bWFsZXN3YXIgUmVkZHkgPFRpcnVtYWxlc3dhclJlZGR5X0tv bmRhQE1jQWZlZS5jb20+IHdyb3RlOg0KPiANCj4g4oCmIHNuaXAgLi4uDQo+IENvbW1lbnQ+ICBT ZW5kZXIgSVAgYWRkcmVzcyBpcyBub3QgdXNlZCBieSB0aGUgRE9UUyBzZXJ2ZXIgdG8gYXV0aGVu dGljYXRlIHRoZSBET1RTIGNsaWVudCBhbmQgdmljZS12ZXJzYS4gVGhlIG9ubHkgd2F5IGFuIGF0 dGFja2VyIGNhbiBpbXBlcnNvbmF0ZSB0aGUgRE9UUyBhZ2VudCBpcyBieSBzdGVhbGluZyBpdHMg Y3JlZGVudGlhbHMgb3IgY29tcHJvbWlzaW5nIHRoZSBhZ2VudC4NCg0KSSBhZ3JlZSB3aXRoIHlv dS4gSXQgc2VlbWVkIGxpa2UgYSBzdHJldGNoIGluIHRoZSBwcmV2aW91cyByZXZpc2lvbiBvZiB0 aGUgc2VjdXJpdHkgY29uc2lkZXJhdGlvbnMuIEFyZSB0aGVyZSBvYmplY3Rpb25zIHRvIGRyb3Bw aW5nIHRyYWZmaWMgaW5qZWN0aW9uIHBlciBzZSBhcyBhIHNlY3VyaXR5IGNvbnNpZGVyYXRpb24/ IEl0IHNlZW1zIHJlYXNvbmFibGUgdG8gc3Vic3VtZSBpdCBpbnRvIGEgZGlzY3Vzc2lvbiBvZiBh Z2VudCBpbXBlcnNvbmF0aW9uLg0KDQoNCj4gDQo+IDIpDQo+ICAgQXMgd2l0aCBhZ2VudCBpbXBl cnNvbmF0aW9uLCB0aGUgYXR0YWNrZXIgY2FwYWJsZSBvZiBpbmplY3RpbmcgdHJhZmZpYyBjYW4g YWZmZWN0DQo+ICAgdGhlIG5ldHdvcmsgcGF0aCB0byBhZGRyZXNzZXMgZm9yIHdoaWNoIHRoZSBE T1RTIGNsaWVudCBpcyBhdXRob3JpemVkDQo+ICAgdG8gcmVxdWVzdCBtaXRpZ2F0aW9uLg0KPiAN Cj4gQ29tbWVudD4gSSBkaWQgbm90IGdldCB0aGUgYWJvdmUgbGluZS4NCg0KSSBoYWQgbWVhbnQg YW4gYXR0YWNrZXIgY2FwYWJsZSBvZiBpbmplY3RpbmcgbWVzc2FnZXMgY291bGQgdG9nZ2xlIG1p dGlnYXRpb24gYXJiaXRyYXJpbHksIHBvdGVudGlhbGx5IHN3aW5naW5nIHRyYWZmaWMgdG8gb3Ig YXdheSBmcm9tIHNjcnViYmluZyBjZW50ZXJzLCBvciBvdGhlcndpc2UgaW5mbHVlbmNpbmcgdHJh ZmZpYyB0byB0aGUgRE9UUyBjbGllbnTigJlzIGRvbWFpbi4gV291bGQgZ28gYXdheSBpZiB3ZSBk cm9wIHRyYWZmaWMgaW5qZWN0aW9uIGFzIGEgY29uc2lkZXJhdGlvbi4NCg0KDQo+IOKApiBzbmlw IC4uLg0KPiBDb21tZW50PiBDdXJyZW50IGJlc3Qgc2VjdXJlIG5ldHdvcmsgY29tbXVuaWNhdGlv bnMgd2lsbCBub3QgZGVmZW5kIGZyb20gY3JlZGVudGlhbCB0aGVmdCBvciBjb21wcm9taXNlIG9m IERPVFMgYWdlbnRzLiBET1RTIGFnZW50cyBuZWVkIGF1ZGl0aW5nLCBhbmFseXRpY3MgdG9vbHMg ZXRjLiANCj4gdG8gZGV0ZWN0IGEgY29tcHJvbWlzZWQgcGVlciBET1RTIGFnZW50Lg0KDQpBZ3Jl ZWQsIHdpbGwgdXBkYXRlLg0KDQphbmRyZXc= From nobody Wed Jan 24 21:48:43 2018 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 470D912DA03 for ; Wed, 24 Jan 2018 21:48:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.01 X-Spam-Level: X-Spam-Status: No, score=-7.01 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, T_RP_MATCHES_RCVD=-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 TxmV8XST7S7e for ; Wed, 24 Jan 2018 21:48:40 -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 3B796126C2F for ; Wed, 24 Jan 2018 21:48:40 -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=1516859319; h=From: To:CC:Subject:Thread-Topic:Thread-Index:Date: Message-ID:References:In-Reply-To:Accept-Language: Content-Language:X-MS-Has-Attach:X-MS-TNEF-Correlator: dlp-product:dlp-version:dlp-reaction: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: x-microsoft-antispam-message-info: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=lFP5XjzVTwUskiJEz1opMshQbpVGYXmJRmjckS htrs0=; b=Za7zKiIocYtNXaD6lfLIxplDohN4nKmW5DPzKGZQ PuiACRlvwZGP+TLxwRyh/f6NQpkx6vGjMQBDp/ZLIURjkr9QCf 5+Y/RGzK/NBd7GRevMTJwWbOkmKLJhf7Ze0nlbyT4LE8vCFUY+ okxIli/QNtHK401ZAsUeBRTAqphg3n4= Received: from MIVEXAPP1N03.corpzone.internalzone.com (unknown [10.48.48.90]) by MIVWSMAILOUT1.mcafee.com with smtp (TLS: TLSv1/SSLv3,256bits,ECDHE-RSA-AES256-SHA384) id 7d12_0795_a183efce_1b0d_4029_b34d_e1035af4de0b; Wed, 24 Jan 2018 23:48:39 -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; Thu, 25 Jan 2018 00:48:37 -0500 Received: from MIVEXUSR1N02.corpzone.internalzone.com (10.48.48.82) by MIVEXUSR1N07.corpzone.internalzone.com (10.48.48.87) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Thu, 25 Jan 2018 00:48:36 -0500 Received: from MIVO365EDGE4.corpzone.internalzone.com (10.48.176.87) by MIVEXUSR1N02.corpzone.internalzone.com (10.48.48.82) with Microsoft SMTP Server (TLS) id 15.0.1347.2 via Frontend Transport; Thu, 25 Jan 2018 00:48:36 -0500 Received: from NAM03-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, 25 Jan 2018 00:48:35 -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.428.17; Thu, 25 Jan 2018 05:48:34 +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.0428.024; Thu, 25 Jan 2018 05:48:34 +0000 From: "Konda, Tirumaleswar Reddy" To: "Mortensen, Andrew" CC: dots Thread-Topic: [Dots] I-D Action: draft-ietf-dots-requirements-11.txt Thread-Index: AQHTlJlfRJI5svGx70KmFmcv7D1Xz6OCChQAgAEC5RCAAHANAIAAmXkQ Date: Thu, 25 Jan 2018 05:48:34 +0000 Message-ID: References: <151674641498.15562.4768813409058823004@ietfa.amsl.com> <1867660E-4B54-405F-B87E-3CDBC2D46442@arbor.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-version: 11.0.130.24 dlp-reaction: no-action x-originating-ip: [185.221.69.10] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DM5PR16MB1788; 7:gatWOK6e/jv5zwvyGkEMiSvsJlghvubhNM200oHTCnN6VVkVTDN95EwjIol3tE/Yzjk6fnMXE674uC7ndgWJHzyzyiuc1GSLmPB2iIoftku7ef6IMtHbsPMVo5pFUYzGN0JXDynQVA6u+oWXVQcmsPyJ7rIkmf5Jmc73JpxpgF9jqsG8t5RDSdJOTqfvGNdPKMNYFAXCTY71sFiYsPm31RPfiqqf0p2jCAFgkEoSeGP8spBeS0lHK3jJLgNb0i63 x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 4eb8b520-ca7c-4e07-cd55-08d563b745f3 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(4534165)(4627221)(201703031133081)(201702281549075)(5600026)(4604075)(3008032)(2017052603307)(7153060)(7193020); SRVR:DM5PR16MB1788; x-ms-traffictypediagnostic: DM5PR16MB1788: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(192374486261705)(123452027830198); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040501)(2401047)(8121501046)(5005006)(3002001)(10201501046)(3231023)(2400081)(944501161)(93006095)(93001095)(6041288)(20161123564045)(20161123558120)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123562045)(20161123560045)(6072148)(201708071742011); SRVR:DM5PR16MB1788; BCL:0; PCL:0; RULEID:; SRVR:DM5PR16MB1788; x-forefront-prvs: 0563F2E8B7 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(366004)(396003)(376002)(346002)(39860400002)(39380400002)(189003)(199004)(13464003)(32952001)(8676002)(81166006)(81156014)(186003)(68736007)(230783001)(4326008)(6246003)(106356001)(86362001)(99286004)(97736004)(80792005)(7736002)(8936002)(26005)(25786009)(77096007)(6116002)(66066001)(3846002)(93886005)(33656002)(59450400001)(6436002)(6506007)(53546011)(3660700001)(3280700002)(14454004)(74316002)(53936002)(5660300001)(2900100001)(305945005)(966005)(55016002)(76176011)(72206003)(2906002)(6306002)(316002)(9686003)(478600001)(7696005)(6346003)(105586002)(229853002)(2950100002)(102836004)(6916009)(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; x-microsoft-antispam-message-info: mOmSvvCygNO67Z7XllOdEDfk19+sg3VId+PidXE3D6M9gw9kw9T1cEN2aVCg0eX+X8qR0Xl+hgAEHrfnE3bSYQ== 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: 4eb8b520-ca7c-4e07-cd55-08d563b745f3 X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Jan 2018 05:48:34.5001 (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 <6207> : inlines <6338> : streams <1777028> : uri <2578752> Archived-At: Subject: Re: [Dots] I-D Action: draft-ietf-dots-requirements-11.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, 25 Jan 2018 05:48:42 -0000 PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBEb3RzIFttYWlsdG86ZG90cy1i b3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgTW9ydGVuc2VuLA0KPiBBbmRyZXcNCj4gU2Vu dDogVGh1cnNkYXksIEphbnVhcnkgMjUsIDIwMTggMjowNyBBTQ0KPiBUbzogS29uZGEsIFRpcnVt YWxlc3dhciBSZWRkeSA8VGlydW1hbGVzd2FyUmVkZHlfS29uZGFATWNBZmVlLmNvbT4NCj4gQ2M6 IGRvdHMgPGRvdHNAaWV0Zi5vcmc+DQo+IFN1YmplY3Q6IFJlOiBbRG90c10gSS1EIEFjdGlvbjog ZHJhZnQtaWV0Zi1kb3RzLXJlcXVpcmVtZW50cy0xMS50eHQNCj4gDQo+IFRoYW5rcywgVGlydS4g Q29tbWVudHMgaW5saW5lLg0KPiANCj4gDQo+ID4gT24gSmFuIDI0LCAyMDE4LCBhdCA5OjAyIEFN LCBLb25kYSwgVGlydW1hbGVzd2FyIFJlZGR5DQo+IDxUaXJ1bWFsZXN3YXJSZWRkeV9Lb25kYUBN Y0FmZWUuY29tPiB3cm90ZToNCj4gPg0KPiA+IOKApiBzbmlwIC4uLg0KPiA+IENvbW1lbnQ+ICBT ZW5kZXIgSVAgYWRkcmVzcyBpcyBub3QgdXNlZCBieSB0aGUgRE9UUyBzZXJ2ZXIgdG8NCj4gYXV0 aGVudGljYXRlIHRoZSBET1RTIGNsaWVudCBhbmQgdmljZS12ZXJzYS4gVGhlIG9ubHkgd2F5IGFu IGF0dGFja2VyIGNhbg0KPiBpbXBlcnNvbmF0ZSB0aGUgRE9UUyBhZ2VudCBpcyBieSBzdGVhbGlu ZyBpdHMgY3JlZGVudGlhbHMgb3IgY29tcHJvbWlzaW5nDQo+IHRoZSBhZ2VudC4NCj4gDQo+IEkg YWdyZWUgd2l0aCB5b3UuIEl0IHNlZW1lZCBsaWtlIGEgc3RyZXRjaCBpbiB0aGUgcHJldmlvdXMg cmV2aXNpb24gb2YgdGhlDQo+IHNlY3VyaXR5IGNvbnNpZGVyYXRpb25zLiBBcmUgdGhlcmUgb2Jq ZWN0aW9ucyB0byBkcm9wcGluZyB0cmFmZmljIGluamVjdGlvbiBwZXINCj4gc2UgYXMgYSBzZWN1 cml0eSBjb25zaWRlcmF0aW9uPyANCg0KTm8gb2JqZWN0aW9uIGZyb20gbXkgc2lkZS4gDQoNCkNo ZWVycywNCi1UaXJ1DQoNCj4gSXQgc2VlbXMgcmVhc29uYWJsZSB0byBzdWJzdW1lIGl0IGludG8g YQ0KPiBkaXNjdXNzaW9uIG9mIGFnZW50IGltcGVyc29uYXRpb24uDQo+IA0KPiANCj4gPg0KPiA+ IDIpDQo+ID4gICBBcyB3aXRoIGFnZW50IGltcGVyc29uYXRpb24sIHRoZSBhdHRhY2tlciBjYXBh YmxlIG9mIGluamVjdGluZyB0cmFmZmljIGNhbg0KPiBhZmZlY3QNCj4gPiAgIHRoZSBuZXR3b3Jr IHBhdGggdG8gYWRkcmVzc2VzIGZvciB3aGljaCB0aGUgRE9UUyBjbGllbnQgaXMgYXV0aG9yaXpl ZA0KPiA+ICAgdG8gcmVxdWVzdCBtaXRpZ2F0aW9uLg0KPiA+DQo+ID4gQ29tbWVudD4gSSBkaWQg bm90IGdldCB0aGUgYWJvdmUgbGluZS4NCj4gDQo+IEkgaGFkIG1lYW50IGFuIGF0dGFja2VyIGNh cGFibGUgb2YgaW5qZWN0aW5nIG1lc3NhZ2VzIGNvdWxkIHRvZ2dsZSBtaXRpZ2F0aW9uDQo+IGFy Yml0cmFyaWx5LCBwb3RlbnRpYWxseSBzd2luZ2luZyB0cmFmZmljIHRvIG9yIGF3YXkgZnJvbSBz Y3J1YmJpbmcgY2VudGVycywgb3INCj4gb3RoZXJ3aXNlIGluZmx1ZW5jaW5nIHRyYWZmaWMgdG8g dGhlIERPVFMgY2xpZW504oCZcyBkb21haW4uIFdvdWxkIGdvIGF3YXkgaWYNCj4gd2UgZHJvcCB0 cmFmZmljIGluamVjdGlvbiBhcyBhIGNvbnNpZGVyYXRpb24uDQo+IA0KPiANCj4gPiDigKYgc25p cCAuLi4NCj4gPiBDb21tZW50PiBDdXJyZW50IGJlc3Qgc2VjdXJlIG5ldHdvcmsgY29tbXVuaWNh dGlvbnMgd2lsbCBub3QgZGVmZW5kDQo+IGZyb20gY3JlZGVudGlhbCB0aGVmdCBvciBjb21wcm9t aXNlIG9mIERPVFMgYWdlbnRzLiBET1RTIGFnZW50cyBuZWVkDQo+IGF1ZGl0aW5nLCBhbmFseXRp Y3MgdG9vbHMgZXRjLg0KPiA+IHRvIGRldGVjdCBhIGNvbXByb21pc2VkIHBlZXIgRE9UUyBhZ2Vu dC4NCj4gDQo+IEFncmVlZCwgd2lsbCB1cGRhdGUuDQo+IA0KPiBhbmRyZXcNCj4gX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gRG90cyBtYWlsaW5nIGxp c3QNCj4gRG90c0BpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL2RvdHMNCg== From nobody Thu Jan 25 01:19:07 2018 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 D96D212DA08 for ; Thu, 25 Jan 2018 01:19:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.629 X-Spam-Level: X-Spam-Status: No, score=-2.629 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 luDbGCUKKg_p for ; Thu, 25 Jan 2018 01:19:04 -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 F2E3312D868 for ; Thu, 25 Jan 2018 01:19:03 -0800 (PST) Received: from opfednr01.francetelecom.fr (unknown [xx.xx.xx.65]) by opfednr24.francetelecom.fr (ESMTP service) with ESMTP id CDDEF40C0A; Thu, 25 Jan 2018 10:19:02 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.13]) by opfednr01.francetelecom.fr (ESMTP service) with ESMTP id B2D671A0072; Thu, 25 Jan 2018 10:19:02 +0100 (CET) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM6D.corporate.adroot.infra.ftgroup ([fe80::54f9:a6c3:c013:cbc7%19]) with mapi id 14.03.0382.000; Thu, 25 Jan 2018 10:19:02 +0100 From: To: "Mortensen, Andrew" , "Konda, Tirumaleswar Reddy" CC: dots Thread-Topic: [Dots] I-D Action: draft-ietf-dots-requirements-11.txt Thread-Index: AQHTlJlNES/+1tFsdU6+psOAvXkKNKOCChOAgAEErYCAAG5FgIAA0yKg Date: Thu, 25 Jan 2018 09:19:01 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93300A0C6C7D@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <151674641498.15562.4768813409058823004@ietfa.amsl.com> <1867660E-4B54-405F-B87E-3CDBC2D46442@arbor.net> 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.6] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [Dots] I-D Action: draft-ietf-dots-requirements-11.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, 25 Jan 2018 09:19:06 -0000 SGkgQW5kcmV3LCBUaXJ1LCANCg0KVGhhdCB0ZXh0IGlzIGFib3V0IGEgIm5haXZlIERPVFMgZGVw bG95bWVudCIsIHdoYXRldmVyIHRoYXQgbWVhbnMuIEl0IGhhcyB0aGUgbWVyaXQgdG8gaWRlbnRp ZnkgYSB2YWxpZCBhdHRhY2sgdmVjdG9yIGluIGEgIm5hw692ZSIgZGVwbG95bWVudC4gDQoNCkkg d291bGQgbWFpbnRhaW4gdGhhdCB0ZXh0LCBidXQgdXBkYXRlIGl0IHRvIGluZGljYXRlIHRoYXQg aWYgdGhlIHJlcXVpcmVtZW50cyBpbiBTZWN0aW9uIDIuNCBhcmUgaG9ub3JlZCwgdGhlbiBpbXBs ZW1lbnRpbmcgdGhpcyBhdHRhY2sgcmVxdWlyZXMgc3RlYWxpbmcgc2VjdXJpdHkgY3JlZGVudGlh bHMuIA0KDQpDaGVlcnMsDQpNZWQNCg0KPiAtLS0tLU1lc3NhZ2UgZCdvcmlnaW5lLS0tLS0NCj4g RGXCoDogRG90cyBbbWFpbHRvOmRvdHMtYm91bmNlc0BpZXRmLm9yZ10gRGUgbGEgcGFydCBkZSBN b3J0ZW5zZW4sIEFuZHJldw0KPiBFbnZvecOpwqA6IG1lcmNyZWRpIDI0IGphbnZpZXIgMjAxOCAy MTozNw0KPiDDgMKgOiBLb25kYSwgVGlydW1hbGVzd2FyIFJlZGR5DQo+IENjwqA6IGRvdHMNCj4g T2JqZXTCoDogUmU6IFtEb3RzXSBJLUQgQWN0aW9uOiBkcmFmdC1pZXRmLWRvdHMtcmVxdWlyZW1l bnRzLTExLnR4dA0KPiANCj4gVGhhbmtzLCBUaXJ1LiBDb21tZW50cyBpbmxpbmUuDQo+IA0KPiAN Cj4gPiBPbiBKYW4gMjQsIDIwMTgsIGF0IDk6MDIgQU0sIEtvbmRhLCBUaXJ1bWFsZXN3YXIgUmVk ZHkNCj4gPFRpcnVtYWxlc3dhclJlZGR5X0tvbmRhQE1jQWZlZS5jb20+IHdyb3RlOg0KPiA+DQo+ ID4g4oCmIHNuaXAgLi4uDQo+ID4gQ29tbWVudD4gIFNlbmRlciBJUCBhZGRyZXNzIGlzIG5vdCB1 c2VkIGJ5IHRoZSBET1RTIHNlcnZlciB0byBhdXRoZW50aWNhdGUNCj4gdGhlIERPVFMgY2xpZW50 IGFuZCB2aWNlLXZlcnNhLiBUaGUgb25seSB3YXkgYW4gYXR0YWNrZXIgY2FuIGltcGVyc29uYXRl IHRoZQ0KPiBET1RTIGFnZW50IGlzIGJ5IHN0ZWFsaW5nIGl0cyBjcmVkZW50aWFscyBvciBjb21w cm9taXNpbmcgdGhlIGFnZW50Lg0KPiANCj4gSSBhZ3JlZSB3aXRoIHlvdS4gSXQgc2VlbWVkIGxp a2UgYSBzdHJldGNoIGluIHRoZSBwcmV2aW91cyByZXZpc2lvbiBvZiB0aGUNCj4gc2VjdXJpdHkg Y29uc2lkZXJhdGlvbnMuIEFyZSB0aGVyZSBvYmplY3Rpb25zIHRvIGRyb3BwaW5nIHRyYWZmaWMg aW5qZWN0aW9uDQo+IHBlciBzZSBhcyBhIHNlY3VyaXR5IGNvbnNpZGVyYXRpb24/IEl0IHNlZW1z IHJlYXNvbmFibGUgdG8gc3Vic3VtZSBpdCBpbnRvIGENCj4gZGlzY3Vzc2lvbiBvZiBhZ2VudCBp bXBlcnNvbmF0aW9uLg0KPiANCj4gDQo+ID4NCj4gPiAyKQ0KPiA+ICAgQXMgd2l0aCBhZ2VudCBp bXBlcnNvbmF0aW9uLCB0aGUgYXR0YWNrZXIgY2FwYWJsZSBvZiBpbmplY3RpbmcgdHJhZmZpYw0K PiBjYW4gYWZmZWN0DQo+ID4gICB0aGUgbmV0d29yayBwYXRoIHRvIGFkZHJlc3NlcyBmb3Igd2hp Y2ggdGhlIERPVFMgY2xpZW50IGlzIGF1dGhvcml6ZWQNCj4gPiAgIHRvIHJlcXVlc3QgbWl0aWdh dGlvbi4NCj4gPg0KPiA+IENvbW1lbnQ+IEkgZGlkIG5vdCBnZXQgdGhlIGFib3ZlIGxpbmUuDQo+ IA0KPiBJIGhhZCBtZWFudCBhbiBhdHRhY2tlciBjYXBhYmxlIG9mIGluamVjdGluZyBtZXNzYWdl cyBjb3VsZCB0b2dnbGUgbWl0aWdhdGlvbg0KPiBhcmJpdHJhcmlseSwgcG90ZW50aWFsbHkgc3dp bmdpbmcgdHJhZmZpYyB0byBvciBhd2F5IGZyb20gc2NydWJiaW5nIGNlbnRlcnMsDQo+IG9yIG90 aGVyd2lzZSBpbmZsdWVuY2luZyB0cmFmZmljIHRvIHRoZSBET1RTIGNsaWVudOKAmXMgZG9tYWlu LiBXb3VsZCBnbyBhd2F5DQo+IGlmIHdlIGRyb3AgdHJhZmZpYyBpbmplY3Rpb24gYXMgYSBjb25z aWRlcmF0aW9uLg0KPiANCj4gDQo+ID4g4oCmIHNuaXAgLi4uDQo+ID4gQ29tbWVudD4gQ3VycmVu dCBiZXN0IHNlY3VyZSBuZXR3b3JrIGNvbW11bmljYXRpb25zIHdpbGwgbm90IGRlZmVuZCBmcm9t DQo+IGNyZWRlbnRpYWwgdGhlZnQgb3IgY29tcHJvbWlzZSBvZiBET1RTIGFnZW50cy4gRE9UUyBh Z2VudHMgbmVlZCBhdWRpdGluZywNCj4gYW5hbHl0aWNzIHRvb2xzIGV0Yy4NCj4gPiB0byBkZXRl Y3QgYSBjb21wcm9taXNlZCBwZWVyIERPVFMgYWdlbnQuDQo+IA0KPiBBZ3JlZWQsIHdpbGwgdXBk YXRlLg0KPiANCj4gYW5kcmV3DQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fDQo+IERvdHMgbWFpbGluZyBsaXN0DQo+IERvdHNAaWV0Zi5vcmcNCj4gaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kb3RzDQo= From nobody Thu Jan 25 12:58:11 2018 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 83302129516; Thu, 25 Jan 2018 12:58:05 -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.70.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151691388550.8370.13774001949651932861@ietfa.amsl.com> Date: Thu, 25 Jan 2018 12:58:05 -0800 Archived-At: Subject: [Dots] I-D Action: draft-ietf-dots-requirements-12.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, 25 Jan 2018 20:58:05 -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 (DDoS) Open Threat Signaling Requirements Authors : Andrew Mortensen Robert Moskowitz Tirumaleswar Reddy Filename : draft-ietf-dots-requirements-12.txt Pages : 20 Date : 2018-01-25 Abstract: This document defines the requirements for the Distributed Denial of Service (DDoS) Open Threat Signaling (DOTS) protocols enabling coordinated response to DDoS attacks. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dots-requirements/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-dots-requirements-12 https://datatracker.ietf.org/doc/html/draft-ietf-dots-requirements-12 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dots-requirements-12 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 Jan 25 13:01:29 2018 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 89C4712700F for ; Thu, 25 Jan 2018 13:01:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 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, 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 hG6M8P_Ni0oa for ; Thu, 25 Jan 2018 13:01:26 -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 1CA9812E89E for ; Thu, 25 Jan 2018 13:01:26 -0800 (PST) Received: from pps.filterd (m0096262.ppops.net [127.0.0.1]) by mx0b-00196b01.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w0PKwv7J011696 for ; Thu, 25 Jan 2018 16:01:24 -0500 Received: from nam02-sn1-obe.outbound.protection.outlook.com (mail-sn1nam02lp0019.outbound.protection.outlook.com [216.32.180.19]) by mx0b-00196b01.pphosted.com with ESMTP id 2fpxyh1r01-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT) for ; Thu, 25 Jan 2018 16:01:23 -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=TiXYyR+gck/Gee7RocUbquQQLLx/7WxjK4SuajANuzY=; b=g7ykjtOC1pkgr7bISvtn8gfcg2wbL4MGF3Co6sXMHhFlxgu6wz1HkWUOt6yTBM0zCDl9X6OHQrE3aIWWDlPbeZynWyg9nip2ZYVV80w8zXxck9PTgtjA5v8tiuaFBjjFhnvTp0n03jqqtRPpF1mGnBTNAtORBkNX0Dg1KEkzVak= Received: from BN3PR01MB1987.prod.exchangelabs.com (10.166.71.144) by BN3PR01MB2084.prod.exchangelabs.com (10.166.72.148) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.444.14; Thu, 25 Jan 2018 21:01:21 +0000 Received: from BN3PR01MB1987.prod.exchangelabs.com ([10.166.71.144]) by BN3PR01MB1987.prod.exchangelabs.com ([10.166.71.144]) with mapi id 15.20.0444.016; Thu, 25 Jan 2018 21:01:21 +0000 From: "Mortensen, Andrew" To: "dots@ietf.org" Thread-Topic: [Dots] I-D Action: draft-ietf-dots-requirements-12.txt Thread-Index: AQHTlh85VR2l4XWeXU+K7wXRtQMhvg== Date: Thu, 25 Jan 2018 21:01:21 +0000 Message-ID: <29157DEF-CE88-4180-BB97-121BB05387EF@arbor.net> References: <151691388550.8370.13774001949651932861@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [216.130.192.4] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BN3PR01MB2084; 7:SCCpHz7x0Th34/EEkkj4DXKa/zZOt3Z4nNW9cvxtO3SQ8B3tYLk44nwow5HCLEvCiSL3XIDtSb3kjbhjCrzoLKfdkFYdcqoQz/hDkd6N95JqvVU/aeI1EjmJ5Wx3gHuB2Sq3uB6t+cltpq+wbcYKmLjYw8KY0HILSGLLEaKoTJqcnDM7dDNq9VdX79i51/IexD3hs51j1TdYtlIXjfkG4sNCvDU70J5UPRnmipqH4j1+qMp1jKKOe1fDdDLzH5n6 x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 61586093-78d5-48e2-fe8a-08d56436c982 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(4534165)(4627221)(201703031133081)(201702281549075)(5600026)(4604075)(3008032)(2017052603307)(7153060)(7193020); SRVR:BN3PR01MB2084; x-ms-traffictypediagnostic: BN3PR01MB2084: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040501)(2401047)(5005006)(8121501046)(10201501046)(3231023)(2400081)(944501161)(3002001)(93006095)(93001095)(6041288)(20161123564045)(20161123560045)(20161123558120)(20161123562045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(6072148)(201708071742011); SRVR:BN3PR01MB2084; BCL:0; PCL:0; RULEID:; SRVR:BN3PR01MB2084; x-forefront-prvs: 0563F2E8B7 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39380400002)(376002)(396003)(366004)(39860400002)(346002)(377424004)(199004)(189003)(14454004)(77096007)(26005)(230783001)(2501003)(3280700002)(66066001)(81166006)(102836004)(33656002)(316002)(478600001)(3660700001)(105586002)(6506007)(8936002)(106356001)(25786009)(5660300001)(68736007)(53936002)(6916009)(186003)(82746002)(1730700003)(83716003)(97736004)(236005)(7736002)(6512007)(2473003)(54896002)(6486002)(99286004)(36756003)(2351001)(2906002)(3846002)(229853002)(6436002)(81156014)(2900100001)(76176011)(5640700003)(6116002)(86362001)(8676002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR01MB2084; H:BN3PR01MB1987.prod.exchangelabs.com; 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-antispam-message-info: Ih5NpirQYW5twogiXbtv2TXcBRiPDX4npXTyUpKWg4nCwy/9mbm0gfITRjc6/7VrOcagZDG8E6fK3jORMzqGkQ== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_29157DEFCE884180BB97121BB05387EFarbornet_" MIME-Version: 1.0 X-OriginatorOrg: arbor.net X-MS-Exchange-CrossTenant-Network-Message-Id: 61586093-78d5-48e2-fe8a-08d56436c982 X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Jan 2018 21:01:21.3047 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 54f11205-d4aa-4809-bd36-0b542199c5b2 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR01MB2084 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-01-25_08:, , 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 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1801250278 Archived-At: Subject: [Dots] Fwd: I-D Action: draft-ietf-dots-requirements-12.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, 25 Jan 2018 21:01:28 -0000 --_000_29157DEFCE884180BB97121BB05387EFarbornet_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable This revision addresses recent feedback from Tiru and Med on the -11 draft.= At this point I do not see agreement on either point Jon raised following = publication of the previous revision. andrew Begin forwarded message: From: internet-drafts@ietf.org Subject: [Dots] I-D Action: draft-ietf-dots-requirements-12.txt Date: January 25, 2018 at 3:58:05 PM EST To: > Cc: dots@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the DDoS Open Threat Signaling WG of the IETF. Title : Distributed Denial of Service (DDoS) Open Threat S= ignaling Requirements Authors : Andrew Mortensen Robert Moskowitz Tirumaleswar Reddy Filename : draft-ietf-dots-requirements-12.txt Pages : 20 Date : 2018-01-25 Abstract: This document defines the requirements for the Distributed Denial of Service (DDoS) Open Threat Signaling (DOTS) protocols enabling coordinated response to DDoS attacks. --_000_29157DEFCE884180BB97121BB05387EFarbornet_ Content-Type: text/html; charset="us-ascii" Content-ID: <11B1DAF526091946B26B29A4FEE67443@prod.exchangelabs.com> Content-Transfer-Encoding: quoted-printable This revision addresses recent feedback from Tiru and Med on the -11 draft.= At this point I do not see agreement on either point Jon raised following = publication of the previous revision.

andrew



Begin forwarded message:

From: internet-drafts@ietf.org
Subject: [Dots] I-D Action: draft-= ietf-dots-requirements-12.txt
Date: January 25, 2018 at 3:58:05 PM EST
To: <i-d-announce@ietf.org>
Cc: dots@ietf.org


A New Internet-Draft is available from the on-line Internet-Drafts director= ies.
This draft is a work item of the DDoS Open Threat Signaling WG of the IETF.=

       Title     &nb= sp;     : Distributed Denial of Service (DDoS) Ope= n Threat Signaling Requirements
       Authors     &= nbsp;   : Andrew Mortensen
            &nb= sp;            = Robert Moskowitz
            &nb= sp;            = Tirumaleswar Reddy
Filename &n= bsp;      : draft-ietf-dots-requirements-12.t= xt
Pages  = ;         : 20
Date  =           : 2018-01-25
Abstract:
  This document defines the requirements for the Distributed Deni= al of
  Service (DDoS) Open Threat Signaling (DOTS) protocols enabling<= br class=3D"">   coordinated response to DDoS attacks.
--_000_29157DEFCE884180BB97121BB05387EFarbornet_-- From nobody Fri Jan 26 07:28:50 2018 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 E8B68124234 for ; Fri, 26 Jan 2018 07:28:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 bl6r2_DQ6ix3 for ; Fri, 26 Jan 2018 07:28: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 47B9E1241FC for ; Fri, 26 Jan 2018 07:28:46 -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 1ef5vn-0004cH-0n; Fri, 26 Jan 2018 15:28:43 +0000 From: "Jon Shallow" To: "'Mortensen, Andrew'" , References: <151691388550.8370.13774001949651932861@ietfa.amsl.com> <29157DEF-CE88-4180-BB97-121BB05387EF@arbor.net> In-Reply-To: <29157DEF-CE88-4180-BB97-121BB05387EF@arbor.net> Date: Fri, 26 Jan 2018 15:28:43 -0000 Message-ID: <10b801d396ba$59d76c50$0d8644f0$@jpshallow.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_10B9_01D396BA.59D8A4D0" X-Mailer: Microsoft Outlook 14.0 Content-Language: en-gb Thread-Index: AQIeBS4Buq0KT1pKyqfRHeY9l6vKWgIcdfDSouBx2lA= Archived-At: Subject: Re: [Dots] Fwd: I-D Action: draft-ietf-dots-requirements-12.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, 26 Jan 2018 15:28:49 -0000 This is a multipart message in MIME format. ------=_NextPart_000_10B9_01D396BA.59D8A4D0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Andrew / WG, Signal/Data path loop detection protection. I can think of 2 scenarios where hop-limit mechanism can prevent an infinite loop taking down DOTS clients / servers. They are triggered by misconfiguration, but the misconfiguration may not be detected for some time - until another event occurs. I believe that it would be prudent to have this sort of loop detection protection mechanism in place when DOTS gateways are deployed. Med's suggested text works for me. Background to the configuration set up for the scenarios The DOTS server component of the GW has all DOTS client identities (e.g. DNS-ID) configured, so they not only mutually authenticate, but are authorized to be valid DOTS clients. In error, the client identity of the DOTS client component of the GW is also included in the DOTS server list (i.e. someone simply did a push of all the valid client identities to the server component). The issuer of all the certificates/private keys is the same for the DOTS gateway and the upstream DOTS server, so any client cert will mutually authenticate with a server cert. Under normal operations, this 'push all client identities' error would not be spotted as it was not causing any issues, which could be the case for months/years. Scenario 1 DNS poisoning. I know DNSSEC is recommended in the drafts, but it is not universally adopted. Someone poisons (or is misconfigured in error) the upstream DOTS server FQDN so that it points back to the IP address of the client-facing-side of the DOTS gateway. You then have a forwarding loop. Scenario 2 The DOTS gateway server-facing-side receives a server redirection (SIG-004). There was an error in the redirected FQDN / IP address, and the DOTS gateway server-facing-side is redirected to the DOTS gateway client-facing-side IP. You then have a forwarding loop. It could be said that you should detect that the DOTS gateway is sending to itself by checking src/dest IPs, but if there is a chain of DOTS gateways, the end of the chain could in error loop back to the beginning of the chain which is more difficult to detect. There potentially are other loop scenarios that have not yet been discovered. Should loop detection be included (for both signal and data channels) - comments? Regards Jon From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of Mortensen, Andrew Sent: 25 January 2018 21:01 To: dots@ietf.org Subject: [Dots] Fwd: I-D Action: draft-ietf-dots-requirements-12.txt This revision addresses recent feedback from Tiru and Med on the -11 draft. At this point I do not see agreement on either point Jon raised following publication of the previous revision. andrew Begin forwarded message: From: internet-drafts@ietf.org Subject: [Dots] I-D Action: draft-ietf-dots-requirements-12.txt Date: January 25, 2018 at 3:58:05 PM EST To: Cc: dots@ietf.org 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 (DDoS) Open Threat Signaling Requirements Authors : Andrew Mortensen Robert Moskowitz Tirumaleswar Reddy Filename : draft-ietf-dots-requirements-12.txt Pages : 20 Date : 2018-01-25 Abstract: This document defines the requirements for the Distributed Denial of Service (DDoS) Open Threat Signaling (DOTS) protocols enabling coordinated response to DDoS attacks. ------=_NextPart_000_10B9_01D396BA.59D8A4D0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Andrew / WG,

 

Signal/Data path = loop detection protection.

 

I can think of 2 scenarios where hop-limit mechanism can prevent an = infinite loop taking down DOTS clients / servers.  They are = triggered by misconfiguration, but the misconfiguration may not be = detected for some time – until another event = occurs.

 

I believe that it would be prudent to have this sort of loop = detection protection mechanism in place when DOTS gateways are = deployed.  Med’s suggested text works for = me.

 

Background to the configuration set up for the = scenarios

 

The DOTS server component of the GW has all DOTS client identities = (e.g. DNS-ID) configured, so they not only mutually authenticate, but = are authorized to be valid DOTS clients.  In error, the client = identity of the DOTS client component of the GW is also included in the = DOTS server list (i.e. someone simply did a push of all the valid client = identities to the server component).  The issuer of all the = certificates/private keys is the same for the DOTS gateway and the = upstream DOTS server, so any client cert will mutually authenticate with = a server cert.

 

Under normal operations, this ‘push all client = identities’ error would not be spotted as it was not causing any = issues, which could be the case for = months/years.

 

Scenario 1

 

DNS poisoning.  I know DNSSEC is recommended in the drafts, but = it is not universally adopted.  Someone poisons (or is = misconfigured in error) the upstream DOTS server FQDN so that it points = back to the IP address of the client-facing-side of the DOTS = gateway.  You then have a forwarding loop.

 

Scenario 2

 

The DOTS gateway server-facing-side receives a server redirection = (SIG-004).  There was an error in the redirected FQDN / IP address, = and the DOTS gateway server-facing-side is redirected to the DOTS = gateway client-facing-side IP.  You then have a forwarding = loop.

 

It could be said that you should detect that the DOTS gateway is = sending to itself by checking src/dest IPs, but if there is a chain of = DOTS gateways, the end of the chain could in error loop back to the = beginning of the chain which is more difficult to = detect.

 

There potentially are other loop scenarios that have not yet been = discovered.

 

Should loop detection be included (for both signal and data channels) = – comments?

 

Regards

 

Jon

 

From:= Dots = [mailto: dots-bounces@ietf.org] On Behalf Of Mortensen, = Andrew
Sent: 25 January 2018 21:01
To: = dots@ietf.org
Subject: [Dots] Fwd: I-D Action: = draft-ietf-dots-requirements-12.txt

 

This = revision addresses recent feedback from Tiru and Med on the -11 draft. = At this point I do not see agreement on either point Jon raised = following publication of the previous revision.

 

andrew

 

 



Begin = forwarded message:

 

Subject: [Dots] I-D Action: = draft-ietf-dots-requirements-12.txt

<= p class=3DMsoNormal>Date: January 25, 2018 at 3:58:05 PM = EST

Cc: dots@ietf.org

 


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 (DDoS) Open Threat Signaling = Requirements
       Authors =         : Andrew = Mortensen
          =             &= nbsp;  Robert = Moskowitz
          =             &= nbsp;  Tirumaleswar Reddy
Filename =        : = draft-ietf-dots-requirements-12.txt
Pages =           : 20
Date =            : = 2018-01-25

Abstract:
  This document defines the = requirements for the Distributed Denial of
  Service (DDoS) = Open Threat Signaling (DOTS) protocols = enabling
  coordinated response to DDoS = attacks.

------=_NextPart_000_10B9_01D396BA.59D8A4D0-- From nobody Mon Jan 29 13:51:49 2018 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 41892124234 for ; Mon, 29 Jan 2018 13:51:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, URIBL_BLOCKED=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 vXRh9sXwcgr9 for ; Mon, 29 Jan 2018 13:51:45 -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 405C012DA53 for ; Mon, 29 Jan 2018 13:51:45 -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 w0TLpgXO019417; Mon, 29 Jan 2018 16:51:42 -0500 DKIM-Filter: OpenDKIM Filter v2.11.0 veto.sei.cmu.edu w0TLpgXO019417 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cert.org; s=yc2bmwvrj62m; t=1517262703; bh=5nvsIOzIKVMNP39+8LAR2Vma6ek6ItxQ6METUiPFsP4=; h=From:To:Subject:Date:References:In-Reply-To:From; b=qjAXWALD2RQG69nb+NBnWvV7JRJbJxxfNK07uej9Byq5j5fW0h3ksLwQYem7xaw45 lF51AMXiiGx3h4+pPsvvRsTcj5XncsTfJZWXWMpymILG3a2bPDzrVqMQrmVD7scxCU gvZI1+QUgauuG68FXm1A2patJ5tIn6F309UqMBTg= Received: from CASSINA.ad.sei.cmu.edu (cassina.ad.sei.cmu.edu [10.64.28.249]) by korb.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id w0TLpdYQ014001; Mon, 29 Jan 2018 16:51:39 -0500 Received: from MARATHON.ad.sei.cmu.edu ([10.64.28.250]) by CASSINA.ad.sei.cmu.edu ([10.64.28.249]) with mapi id 14.03.0361.001; Mon, 29 Jan 2018 16:51:38 -0500 From: Roman Danyliw To: "Konda, Tirumaleswar Reddy" , "Jon Shallow" , "Mortensen, Andrew" , "dots@ietf.org" Thread-Topic: [Dots] I-D Action: draft-ietf-dots-requirements-11.txt Thread-Index: AQHTlJlPxIhCm2bGJEyiSql5zL/gnaOCXeYAgACvX4CAADl1AIAAEbcAgAgSUAA= Date: Mon, 29 Jan 2018 21:51:38 +0000 Message-ID: <359EC4B99E040048A7131E0F4E113AFC0137507E0A@marathon> References: <151674641498.15562.4768813409058823004@ietfa.amsl.com> <1867660E-4B54-405F-B87E-3CDBC2D46442@arbor.net> <787AE7BB302AE849A7480A190F8B93300A0C5F86@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <0cb501d3950e$0e956970$2bc03c50$@jpshallow.com> In-Reply-To: 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: Re: [Dots] I-D Action: draft-ietf-dots-requirements-11.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, 29 Jan 2018 21:51:47 -0000 Hi Tiru, Jon and Andrew! > -----Original Message----- > From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Konda, > Tirumaleswar Reddy > Sent: Wednesday, January 24, 2018 8:26 AM > To: Jon Shallow ; Mortensen, Andrew > ; dots@ietf.org > Subject: Re: [Dots] I-D Action: draft-ietf-dots-requirements-11.txt >=20 > > -----Original Message----- > > From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Jon Shallow > > Sent: Wednesday, January 24, 2018 5:53 PM > > To: Mortensen, Andrew ; dots@ietf.org > > Subject: Re: [Dots] I-D Action: draft-ietf-dots-requirements-11.txt > > > > Hi Andrew, > > > > There are 2 pending resolution issues raised about the signal / data > > channels which may need to be included in the requirements draft. I > > was planning on raising the 2 pending resolutions at the upcoming Virtu= al > Meeting. > > > > 1) Signal/Data path loop detection protection. > > > > There is some proposed text by Med about loop detection by the use of > > a hop-limit parameter. Do we need tis? > > > https://mailarchive.ietf.org/arch/msg/dots/63MfwLTldONbO9gO_sdT6FG2D > > xQ >=20 > I don't see an agreement on this one, please see my last response > https://mailarchive.ietf.org/arch/msg/dots/p3TaRiNkZOrZ5PKr3UIXe10g9CU I see the lack of consensus on how to handle loops. Does this issue need t= o be resolved with text in the requirements draft? Could a simple requirem= ent acknowledging the possibility of the problem be made (e.g., such as "th= e signal/data protocols needs to deal with communication loops ...") and th= e rest be worked out in the protocol drafts? Roman From nobody Mon Jan 29 14:02:08 2018 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 13AD91200C5 for ; Mon, 29 Jan 2018 14:02:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, URIBL_BLOCKED=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 1hY6L79UKMfy for ; Mon, 29 Jan 2018 14:01:51 -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 257CE13144A for ; Mon, 29 Jan 2018 14:01:44 -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 w0TM1hAf020536 for ; Mon, 29 Jan 2018 17:01:43 -0500 DKIM-Filter: OpenDKIM Filter v2.11.0 veto.sei.cmu.edu w0TM1hAf020536 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cert.org; s=yc2bmwvrj62m; t=1517263303; bh=gRWJA5YT/7/8XtNNcUkjIfVnD6yoTujvHb0YCgClprk=; h=From:To:Subject:Date:From; b=FcEzyoVgnFTOkztwO1Ff6WaOf1dH67YZX+b/nviLd41qR1s4W1G+JLVaQ47Cvea3N u9K8FIZnQkzwSwuoc58q/hYPOOlG6IoMMEv3yvvCWl3MajeDuri53K/gmPNWtaZIWc ojV7WwNfv/N13+EGh89nfjivW8fFIALhpUIypeJE= 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 w0TM1dLJ016171 for ; Mon, 29 Jan 2018 17:01:39 -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, 29 Jan 2018 17:01:39 -0500 From: Roman Danyliw To: "dots@ietf.org" Thread-Topic: Second call for agenda items for Virtual Interim Meeting on February 7, 2018 Thread-Index: AdOZTLaarjPWNTtAQ0Gjp9qU9JQPrg== Date: Mon, 29 Jan 2018 22:01:37 +0000 Message-ID: <359EC4B99E040048A7131E0F4E113AFC0137507E3C@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] Second call for agenda items for Virtual Interim Meeting on February 7, 2018 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, 29 Jan 2018 22:02:07 -0000 Hello WG! Again, if you would like time on the agenda, please send a request to the c= hairs. Also, if you have an implementation report or plan to participate i= n the IETF 101 Hackathon, please let us know so we can better organize thos= e items on the agenda. Regards, Roman and Tobias > -----Original Message----- > From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Roman Danyliw > Sent: Sunday, January 14, 2018 12:33 PM > To: dots@ietf.org > Subject: [Dots] Virtual Interim Meeting: Wednesday, February 7, 2018 >=20 > Hello WG! >=20 > Based on the scheduling poll, a DOTS virtual interim meeting has been > scheduled for Wednesday, February 7, 2018 from 15:00 - 16:30 UTC. Thank > you for everyone's participation in choosing this date and your flexibili= ty in > scheduling. >=20 > Please send any requests for time on the agenda to the chairs. >=20 > =3D=3D[ Date/Time ]=3D=3D > Wednesday, February 7, 2018 > 15:00 - 16:30 UTC >=20 > Start time in select local time zones > =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=3D=3D > San Francisco, USA -- February 7, 2018 at 7:00 am > New York, USA -- February 7, 2018 at 10:00 am > UTC (GMT) -- February 7, 2018 at 3:00 pm > London, UK -- February 7, 2018 at 3:00 pm > Berlin, Germany -- February 7, 2018 at 4:00 pm > New Delhi, India -- February 7, 2018 at 8:30 pm > Bangkok, Thailand -- February 7, 2018 at 10:00 pm > Beijing, China -- February 7, 2018 at 11:00 pm >=20 > =3D=3D[ Tentative Agenda ]=3D=3D > 1. Note well, logistics and introduction (chairs, 10 min) >=20 > 2. Use Case Discussion (10 min) >=20 > 3. Architecture Discussion (10 min) >=20 > 4. IETF 101 Hackathon Coordination (10 min) >=20 > 5. Protocol Drafts (45 min) > - Implementation Reports > - Signal and Data Channel drafts >=20 > 6. Closing (chairs, 5 min) >=20 > =3D=3D[ WebEx Information ]=3D=3D > Meeting URL: > https://ietf.webex.com/ietf/j.php?MTID=3Dm7918038a2dcc50d69146acbfa69c3 > 1eb >=20 > Meeting number: 640 129 123 > Meeting password: AT2ShnfU >=20 > Dial-in Numbers: > 1-877-668-4493 Call-in toll free number (US/Canada) > 1-650-479-3208 Call-in toll number (US/Canada) Access code: 640 129 123 > =3D=3D=3D=3D >=20 From nobody Tue Jan 30 04:15:48 2018 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 1827C131775 for ; Tue, 30 Jan 2018 04:15:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 pyPTFbZdZvZp for ; Tue, 30 Jan 2018 04:15:44 -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 DE38B13181C for ; Tue, 30 Jan 2018 04:11:29 -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 1egUl2-00037R-4t; Tue, 30 Jan 2018 12:11:24 +0000 From: "Jon Shallow" To: "'Roman Danyliw'" , "Konda, Tirumaleswar Reddy" , "Mortensen, Andrew" , References: <151674641498.15562.4768813409058823004@ietfa.amsl.com> <1867660E-4B54-405F-B87E-3CDBC2D46442@arbor.net> <787AE7BB302AE849A7480A190F8B93300A0C5F86@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <0cb501d3950e$0e956970$2bc03c50$@jpshallow.com> <359EC4B99E040048A7131E0F4E113AFC0137507E0A@marathon> In-Reply-To: <359EC4B99E040048A7131E0F4E113AFC0137507E0A@marathon> Date: Tue, 30 Jan 2018 12:11:26 -0000 Message-ID: <13d401d399c3$73b635f0$5b22a1d0$@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: AQJ5ab1ci+yv597yyML+ycymhWTtfQLExSLWAhr2hxoBEskMywHQibuGAuaHpnah62LzYA== Archived-At: Subject: Re: [Dots] I-D Action: draft-ietf-dots-requirements-11.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, 30 Jan 2018 12:15:47 -0000 Hi Roman, "I see the lack of consensus on how to handle loops. Does this issue need to be resolved with text in the requirements draft? Could a simple requirement acknowledging the possibility of the problem be made (e.g., such as "the signal/data protocols needs to deal with communication loops ...") and the rest be worked out in the protocol drafts?" I do not believe that how to do this needs to be spelt out in the requirements draft. Your suggested text works for me and is a good starting point for possibly adding at the end of "GEN-002 Resilience and Robustness", even though that section is primarily for signalling. Regards Jon -----Original Message----- From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of Roman Danyliw Sent: 29 January 2018 21:52 To: Konda, Tirumaleswar Reddy; Jon Shallow; Mortensen, Andrew; dots@ietf.org Subject: Re: [Dots] I-D Action: draft-ietf-dots-requirements-11.txt Hi Tiru, Jon and Andrew! > -----Original Message----- > From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Konda, > Tirumaleswar Reddy > Sent: Wednesday, January 24, 2018 8:26 AM > To: Jon Shallow ; Mortensen, Andrew > ; dots@ietf.org > Subject: Re: [Dots] I-D Action: draft-ietf-dots-requirements-11.txt > > > -----Original Message----- > > From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Jon Shallow > > Sent: Wednesday, January 24, 2018 5:53 PM > > To: Mortensen, Andrew ; dots@ietf.org > > Subject: Re: [Dots] I-D Action: draft-ietf-dots-requirements-11.txt > > > > Hi Andrew, > > > > There are 2 pending resolution issues raised about the signal / data > > channels which may need to be included in the requirements draft. I > > was planning on raising the 2 pending resolutions at the upcoming > > Virtual > Meeting. > > > > 1) Signal/Data path loop detection protection. > > > > There is some proposed text by Med about loop detection by the use > > of a hop-limit parameter. Do we need tis? > > > https://mailarchive.ietf.org/arch/msg/dots/63MfwLTldONbO9gO_sdT6FG2D > > xQ > > I don't see an agreement on this one, please see my last response > https://mailarchive.ietf.org/arch/msg/dots/p3TaRiNkZOrZ5PKr3UIXe10g9CU I see the lack of consensus on how to handle loops. Does this issue need to be resolved with text in the requirements draft? Could a simple requirement acknowledging the possibility of the problem be made (e.g., such as "the signal/data protocols needs to deal with communication loops ...") and the rest be worked out in the protocol drafts? Roman _______________________________________________ Dots mailing list Dots@ietf.org https://www.ietf.org/mailman/listinfo/dots From nobody Tue Jan 30 05:10:28 2018 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 CCF67131839; Tue, 30 Jan 2018 05:10:21 -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.70.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151731782180.27516.3977853494149710938@ietfa.amsl.com> Date: Tue, 30 Jan 2018 05:10:21 -0800 Archived-At: Subject: [Dots] I-D Action: draft-ietf-dots-data-channel-13.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, 30 Jan 2018 13:10:22 -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 Specification Authors : Tirumaleswar Reddy Mohamed Boucadair Kaname Nishizuka Liang Xia Prashanth Patil Andrew Mortensen Nik Teague Filename : draft-ietf-dots-data-channel-13.txt Pages : 40 Date : 2018-01-30 Abstract: The document specifies a Distributed Denial-of-Service Open Threat Signaling (DOTS) data channel used for bulk exchange of data that cannot 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 Specification"; o reference: RFC XXXX Please update this statement with the RFC number to be assigned to the following documents: o "RFC YYYY: Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal Channel Specification"; o "RFC ZZZZ: Network Access Control List (ACL) YANG Data Model"; 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-13 https://datatracker.ietf.org/doc/html/draft-ietf-dots-data-channel-13 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dots-data-channel-13 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 Jan 30 05:27:00 2018 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 D750712DA02 for ; Tue, 30 Jan 2018 05:26:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.629 X-Spam-Level: X-Spam-Status: No, score=-2.629 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 Vtzes6UfCUp7 for ; Tue, 30 Jan 2018 05:26:56 -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 A548012EAF8 for ; Tue, 30 Jan 2018 05:26:10 -0800 (PST) Received: from opfednr03.francetelecom.fr (unknown [xx.xx.xx.67]) by opfednr27.francetelecom.fr (ESMTP service) with ESMTP id 47D35A0CDD for ; Tue, 30 Jan 2018 14:26:09 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.34]) by opfednr03.francetelecom.fr (ESMTP service) with ESMTP id 301C01A0093 for ; Tue, 30 Jan 2018 14:26:09 +0100 (CET) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM6F.corporate.adroot.infra.ftgroup ([fe80::bd00:88f8:8552:3349%17]) with mapi id 14.03.0382.000; Tue, 30 Jan 2018 14:26:08 +0100 From: To: "dots@ietf.org" Thread-Topic: I-D Action: draft-ietf-dots-data-channel-13.txt Thread-Index: AQHTmcvJxO21nCUt8EeHOPCS6A9UjqOMZBzA Date: Tue, 30 Jan 2018 13:26:08 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93300A0C8E04@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <151731782180.27516.3977853494149710938@ietfa.amsl.com> In-Reply-To: <151731782180.27516.3977853494149710938@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-13.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, 30 Jan 2018 13:26:59 -0000 Hi all,=20 As a preparation for the new interim meeting, I'm pleased to share this upd= ated version of this data channel spec.=20 This new version addresses all the requirements set by the WG. Some major c= hanges were made to achieve that, e.g.,=20 * Given the constraints imposed by RESTCONF and the structure of the ACL YA= NG module, the draft does not augment anymore the ACL YANG module. The new = design is more simple + still rely upon I-D.ietf-netmod-acl-model. Motivati= on for such design is further discussed in the document.=20 * Indicate that filtering rules assume a default direction (destination is = the DOTS client' domain) * In order to avoid stale alias/filtering entries, lifetimes are now mandat= ory to be included.=20 * Add some validation rules on the target-prefix * Fix the request-uri in the examples * Update the security considerations (rate-limit, resource quota, ..) Please review and share your comments, questions, and suggestions.=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 30 janvier 2018 14:10 > =C0=A0: i-d-announce@ietf.org > Cc=A0: dots@ietf.org > Objet=A0: I-D Action: draft-ietf-dots-data-channel-13.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 IET= F. >=20 > Title : Distributed Denial-of-Service Open Threat Signa= ling > (DOTS) Data Channel Specification > Authors : Tirumaleswar Reddy > Mohamed Boucadair > Kaname Nishizuka > Liang Xia > Prashanth Patil > Andrew Mortensen > Nik Teague > Filename : draft-ietf-dots-data-channel-13.txt > Pages : 40 > Date : 2018-01-30 >=20 > Abstract: > The document specifies a Distributed Denial-of-Service Open Threat > Signaling (DOTS) data channel used for bulk exchange of data that > cannot 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 Specification"; >=20 > o reference: RFC XXXX >=20 > Please update this statement with the RFC number to be assigned to > the following documents: >=20 > o "RFC YYYY: Distributed Denial-of-Service Open Threat Signaling > (DOTS) Signal Channel Specification"; > o "RFC ZZZZ: Network Access Control List (ACL) YANG Data Model"; >=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-13 > https://datatracker.ietf.org/doc/html/draft-ietf-dots-data-channel-13 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dots-data-channel-13 >=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 > _______________________________________________ > 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 Jan 30 09:31:49 2018 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 AD44112EC7B for ; Tue, 30 Jan 2018 09:31:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 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, 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 oI8YGcVZfsdv for ; Tue, 30 Jan 2018 09:31:44 -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 9FE6B12EBBB for ; Tue, 30 Jan 2018 09:31:44 -0800 (PST) Received: from pps.filterd (m0072398.ppops.net [127.0.0.1]) by mx0a-00196b01.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w0UHVYIW005250; Tue, 30 Jan 2018 12:31:41 -0500 Received: from nam01-by2-obe.outbound.protection.outlook.com (mail-by2nam01lp0179.outbound.protection.outlook.com [216.32.181.179]) by mx0a-00196b01.pphosted.com with ESMTP id 2frpeur74g-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Tue, 30 Jan 2018 12:31:40 -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=vFVWelcTjZ3sBB0bRXnhe9iJYRdwRlDFO2ynytnZfrA=; b=np2zQ1ldFW9pOaOz6r5sAQNjzrX6yI2ZXvFVDY5aHX7lNnRns8lRRY6M7ahrzaiUY3YfZ28raHA4YBf9BUy0TQp0K24nxr/QxjjuMujkLcRW+tJykEldD2gNDFS3t/tb7AnkOxkQRoJooNkBlU/q/jp3xKl6AnZzKtDJo4kUtVY= Received: from BN3PR01MB1987.prod.exchangelabs.com (10.166.71.144) by BN3PR01MB2067.prod.exchangelabs.com (10.166.72.143) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.444.14; Tue, 30 Jan 2018 17:31:38 +0000 Received: from BN3PR01MB1987.prod.exchangelabs.com ([10.166.71.144]) by BN3PR01MB1987.prod.exchangelabs.com ([10.166.71.144]) with mapi id 15.20.0444.016; Tue, 30 Jan 2018 17:31:38 +0000 From: "Mortensen, Andrew" To: Jon Shallow CC: Roman Danyliw , "Konda, Tirumaleswar Reddy" , "dots@ietf.org" Thread-Topic: [Dots] I-D Action: draft-ietf-dots-requirements-11.txt Thread-Index: AQHTlJlNES/+1tFsdU6+psOAvXkKNKOCChOAgACvYYCAADl1AIAAEbcAgAho2gCAAPA6AIAAWXIA Date: Tue, 30 Jan 2018 17:31:37 +0000 Message-ID: <992FCC41-586F-4AE4-B179-4F35D2995848@arbor.net> References: <151674641498.15562.4768813409058823004@ietfa.amsl.com> <1867660E-4B54-405F-B87E-3CDBC2D46442@arbor.net> <787AE7BB302AE849A7480A190F8B93300A0C5F86@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <0cb501d3950e$0e956970$2bc03c50$@jpshallow.com> <359EC4B99E040048A7131E0F4E113AFC0137507E0A@marathon> <13d401d399c3$73b635f0$5b22a1d0$@jpshallow.com> In-Reply-To: <13d401d399c3$73b635f0$5b22a1d0$@jpshallow.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2620:11e:1000:10:b8fb:1585:2ce3:954a] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BN3PR01MB2067; 7:H1O1ytiadimFXQ0XdT6ONHdBq7AzDLFEc0IYeGktQnXPJYhngUUug8lsfReM84Yt2MlD2muCdHwxcae5QsZrxgjuCmzCNDm3OsMdY0AZObJulwxv7TY2l6JOhKD2ybJWcAteYSj5r2F4LwHvCGmdRWlDKSM6uOCBw9Nq2HONAtNrunKyKy/C6gbvVpUXTkEOC/mZ/Bo0l8/qmIAT0FfyTVpgapPBWWcumOhRWVHDvRufn7iwF8Eq4DwvXbKdxAfX x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 9c7c7734-c1a2-4072-67d6-08d56807514a x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(4534165)(4627221)(201703031133081)(201702281549075)(5600026)(4604075)(3008032)(2017052603307)(7153060)(7193020); SRVR:BN3PR01MB2067; x-ms-traffictypediagnostic: BN3PR01MB2067: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(10436049006162)(100405760836317); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040501)(2401047)(5005006)(8121501046)(10201501046)(93006095)(93001095)(3231101)(944501161)(3002001)(6041288)(20161123562045)(20161123558120)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123564045)(6072148)(201708071742011); SRVR:BN3PR01MB2067; BCL:0; PCL:0; RULEID:; SRVR:BN3PR01MB2067; x-forefront-prvs: 0568F32D91 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39380400002)(346002)(376002)(366004)(396003)(39860400002)(199004)(57704003)(189003)(13464003)(6512007)(97736004)(77096007)(33656002)(606006)(2900100001)(68736007)(53546011)(106356001)(6436002)(54896002)(6116002)(6486002)(236005)(99286004)(93886005)(6306002)(4326008)(229853002)(2906002)(6506007)(6246003)(25786009)(3280700002)(81156014)(316002)(2950100002)(6916009)(82746002)(3660700001)(54906003)(81166006)(8676002)(59450400001)(186003)(575784001)(36756003)(53936002)(102836004)(7736002)(76176011)(966005)(105586002)(478600001)(86362001)(14454004)(5660300001)(83716003)(8936002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR01MB2067; H:BN3PR01MB1987.prod.exchangelabs.com; 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-antispam-message-info: PRBP9VdAbd4I/uJjabdLuCb2gaRqEND9rjZ9mDVBVn54S4grscnmRBX3uH7e4pkG6GL0grFVLa79puFw63vZ7A== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_992FCC41586F4AE4B1794F35D2995848arbornet_" MIME-Version: 1.0 X-OriginatorOrg: arbor.net X-MS-Exchange-CrossTenant-Network-Message-Id: 9c7c7734-c1a2-4072-67d6-08d56807514a X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Jan 2018 17:31:37.9589 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 54f11205-d4aa-4809-bd36-0b542199c5b2 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR01MB2067 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-01-30_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 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1801300217 Archived-At: Subject: Re: [Dots] I-D Action: draft-ietf-dots-requirements-11.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, 30 Jan 2018 17:31:48 -0000 --_000_992FCC41586F4AE4B1794F35D2995848arbornet_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQpPbiBKYW4gMzAsIDIwMTgsIGF0IDc6MTEgQU0sIEpvbiBTaGFsbG93IDxzdXBqcHMtaWV0ZkBq cHNoYWxsb3cuY29tPG1haWx0bzpzdXBqcHMtaWV0ZkBqcHNoYWxsb3cuY29tPj4gd3JvdGU6DQoN CuKApiBzbmlwIC4uLg0KDQp0aGUgc2lnbmFsL2RhdGEgcHJvdG9jb2xzIG5lZWRzIHRvIGRlYWwg d2l0aCBjb21tdW5pY2F0aW9uIGxvb3BzIC4uLiIpDQphbmQgdGhlIHJlc3QgYmUgd29ya2VkIG91 dCBpbiB0aGUgcHJvdG9jb2wgZHJhZnRzPyINCg0KSSBkbyBub3QgYmVsaWV2ZSB0aGF0IGhvdyB0 byBkbyB0aGlzIG5lZWRzIHRvIGJlIHNwZWx0IG91dCBpbiB0aGUNCnJlcXVpcmVtZW50cyBkcmFm dC4gIFlvdXIgc3VnZ2VzdGVkIHRleHQgd29ya3MgZm9yIG1lIGFuZCBpcyBhIGdvb2Qgc3RhcnRp bmcNCnBvaW50IGZvciBwb3NzaWJseSBhZGRpbmcgYXQgdGhlIGVuZCBvZiAiR0VOLTAwMiBSZXNp bGllbmNlIGFuZCBSb2J1c3RuZXNz4oCdLA0KDQpJIGNhbiBkbyB0aGlzLg0KDQpldmVuIHRob3Vn aCB0aGF0IHNlY3Rpb24gaXMgcHJpbWFyaWx5IGZvciBzaWduYWxsaW5nLg0KDQpOb3cgd291bGQg YmUgYSBncmVhdCB0aW1lIHRvIGhlYXIgY29uY2VybnMgYWJvdXQgZG9jdW1lbnQgc3RydWN0dXJl LiBBcmUgeW91IHN1Z2dlc3RpbmcgdGhlIGdlbmVyYWwgcmVxdWlyZW1lbnRzIHNlY3Rpb24gc2hv dWxkIGJl4oCmZ2VuZXJhbGx54oCmc3Vic3VtZWQgaW50byB0aGUgc2lnbmFsIGFuZCBkYXRhIGNo YW5uZWwgcmVxcyBzZWN0aW9uPw0KDQphbmRyZXcNCg0KDQoNCg0KLS0tLS1PcmlnaW5hbCBNZXNz YWdlLS0tLS0NCkZyb206IERvdHMgW21haWx0bzogZG90cy1ib3VuY2VzQGlldGYub3JnPG1haWx0 bzpkb3RzLWJvdW5jZXNAaWV0Zi5vcmc+XSBPbiBCZWhhbGYgT2YgUm9tYW4gRGFueWxpdw0KU2Vu dDogMjkgSmFudWFyeSAyMDE4IDIxOjUyDQpUbzogS29uZGEsIFRpcnVtYWxlc3dhciBSZWRkeTsg Sm9uIFNoYWxsb3c7IE1vcnRlbnNlbiwgQW5kcmV3OyBkb3RzQGlldGYub3JnPG1haWx0bzpkb3Rz QGlldGYub3JnPg0KU3ViamVjdDogUmU6IFtEb3RzXSBJLUQgQWN0aW9uOiBkcmFmdC1pZXRmLWRv dHMtcmVxdWlyZW1lbnRzLTExLnR4dA0KDQpIaSBUaXJ1LCBKb24gYW5kIEFuZHJldyENCg0KLS0t LS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IERvdHMgW21haWx0bzpkb3RzLWJvdW5jZXNA aWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBLb25kYSwNClRpcnVtYWxlc3dhciBSZWRkeQ0KU2VudDog V2VkbmVzZGF5LCBKYW51YXJ5IDI0LCAyMDE4IDg6MjYgQU0NClRvOiBKb24gU2hhbGxvdyA8c3Vw anBzLWlldGZAanBzaGFsbG93LmNvbTxtYWlsdG86c3VwanBzLWlldGZAanBzaGFsbG93LmNvbT4+ OyBNb3J0ZW5zZW4sIEFuZHJldw0KPGFtb3J0ZW5zZW5AYXJib3IubmV0PG1haWx0bzphbW9ydGVu c2VuQGFyYm9yLm5ldD4+OyBkb3RzQGlldGYub3JnPG1haWx0bzpkb3RzQGlldGYub3JnPg0KU3Vi amVjdDogUmU6IFtEb3RzXSBJLUQgQWN0aW9uOiBkcmFmdC1pZXRmLWRvdHMtcmVxdWlyZW1lbnRz LTExLnR4dA0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogRG90cyBbbWFpbHRv OmRvdHMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEpvbiBTaGFsbG93DQpTZW50OiBX ZWRuZXNkYXksIEphbnVhcnkgMjQsIDIwMTggNTo1MyBQTQ0KVG86IE1vcnRlbnNlbiwgQW5kcmV3 IDxhbW9ydGVuc2VuQGFyYm9yLm5ldDxtYWlsdG86YW1vcnRlbnNlbkBhcmJvci5uZXQ+PjsgZG90 c0BpZXRmLm9yZzxtYWlsdG86ZG90c0BpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbRG90c10gSS1E IEFjdGlvbjogZHJhZnQtaWV0Zi1kb3RzLXJlcXVpcmVtZW50cy0xMS50eHQNCg0KSGkgQW5kcmV3 LA0KDQpUaGVyZSBhcmUgMiBwZW5kaW5nIHJlc29sdXRpb24gaXNzdWVzIHJhaXNlZCBhYm91dCB0 aGUgc2lnbmFsIC8gZGF0YQ0KY2hhbm5lbHMgd2hpY2ggbWF5IG5lZWQgdG8gYmUgaW5jbHVkZWQg aW4gdGhlIHJlcXVpcmVtZW50cyBkcmFmdC4gIEkNCndhcyBwbGFubmluZyBvbiByYWlzaW5nIHRo ZSAyIHBlbmRpbmcgcmVzb2x1dGlvbnMgYXQgdGhlIHVwY29taW5nDQpWaXJ0dWFsDQpNZWV0aW5n Lg0KDQoxKSBTaWduYWwvRGF0YSBwYXRoIGxvb3AgZGV0ZWN0aW9uIHByb3RlY3Rpb24uDQoNClRo ZXJlIGlzIHNvbWUgcHJvcG9zZWQgdGV4dCBieSBNZWQgYWJvdXQgbG9vcCBkZXRlY3Rpb24gYnkg dGhlIHVzZQ0Kb2YgYSBob3AtbGltaXQgcGFyYW1ldGVyLiAgRG8gd2UgbmVlZCB0aXM/DQoNCmh0 dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fbWFpbGFy Y2hpdmUuaWV0Zi5vcmdfYXJjaF9tc2dfZG90c182M01md0xUbGRPTmJPOWdPLTVGc2RUNkZHMkQm ZD1Ed0lDQWcmYz1IbHZwcnFvbnI1THVDTjlUTjY1eE53JnI9TS0wX0NxRVZYYTlPUXZtSjJnTXRY QXpMNnY2SnNaSHRzUmttYVJ6NHVyRSZtPURQeHd6dTFQcU1MeUt0bmJnWUszRC1rX19LcGJuR19u dnlGYVVKZmhaZEUmcz1aQzVWWTY1UjV1QUpTQWk2SWJKNzgtR3Fhc0hoNFd2V2VGQW9mX1RwczJR JmU9DQp4UQ0KDQpJIGRvbid0IHNlZSBhbiBhZ3JlZW1lbnQgb24gdGhpcyBvbmUsIHBsZWFzZSBz ZWUgbXkgbGFzdCByZXNwb25zZQ0KaHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3Yy L3VybD91PWh0dHBzLTNBX19tYWlsYXJjaGl2ZS5pZXRmLm9yZ19hcmNoX21zZ19kb3RzX3AzVGFS aU5rWk9yWjVQS3IzVUlYZTEwZzlDVSZkPUR3SUNBZyZjPUhsdnBycW9ucjVMdUNOOVRONjV4Tncm cj1NLTBfQ3FFVlhhOU9Rdm1KMmdNdFhBekw2djZKc1pIdHNSa21hUno0dXJFJm09RFB4d3p1MVBx TUx5S3RuYmdZSzNELWtfX0twYm5HX252eUZhVUpmaFpkRSZzPVVzejBWdU12VV9DVlBxaUdodU5f SldxSUtaOUpSME1HYV9heFZMb2cyZGcmZT0NCg0KSSBzZWUgdGhlIGxhY2sgb2YgY29uc2Vuc3Vz IG9uIGhvdyB0byBoYW5kbGUgbG9vcHMuICBEb2VzIHRoaXMgaXNzdWUgbmVlZCB0bw0KYmUgcmVz b2x2ZWQgd2l0aCB0ZXh0IGluIHRoZSByZXF1aXJlbWVudHMgZHJhZnQ/ICBDb3VsZCBhIHNpbXBs ZSByZXF1aXJlbWVudA0KYWNrbm93bGVkZ2luZyB0aGUgcG9zc2liaWxpdHkgb2YgdGhlIHByb2Js ZW0gYmUgbWFkZSAoZS5nLiwgc3VjaCBhcyAidGhlDQpzaWduYWwvZGF0YSBwcm90b2NvbHMgbmVl ZHMgdG8gZGVhbCB3aXRoIGNvbW11bmljYXRpb24gbG9vcHMgLi4uIikgYW5kIHRoZQ0KcmVzdCBi ZSB3b3JrZWQgb3V0IGluIHRoZSBwcm90b2NvbCBkcmFmdHM/DQoNClJvbWFuDQoNCl9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpEb3RzIG1haWxpbmcgbGlz dA0KRG90c0BpZXRmLm9yZzxtYWlsdG86RG90c0BpZXRmLm9yZz4NCmh0dHBzOi8vdXJsZGVmZW5z ZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fd3d3LmlldGYub3JnX21haWxtYW5f bGlzdGluZm9fZG90cyZkPUR3SUNBZyZjPUhsdnBycW9ucjVMdUNOOVRONjV4Tncmcj1NLTBfQ3FF VlhhOU9Rdm1KMmdNdFhBekw2djZKc1pIdHNSa21hUno0dXJFJm09RFB4d3p1MVBxTUx5S3RuYmdZ SzNELWtfX0twYm5HX252eUZhVUpmaFpkRSZzPWhfRi15WEV5UFZjc3pNRlc3X1lHZGQ0b3JDNThm LU1feDI5Rl9vSGw5aE0mZT0NCg0K --_000_992FCC41586F4AE4B1794F35D2995848arbornet_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KPGRpdj4N CjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj5PbiBKYW4g MzAsIDIwMTgsIGF0IDc6MTEgQU0sIEpvbiBTaGFsbG93ICZsdDs8YSBocmVmPSJtYWlsdG86c3Vw anBzLWlldGZAanBzaGFsbG93LmNvbSIgY2xhc3M9IiI+c3VwanBzLWlldGZAanBzaGFsbG93LmNv bTwvYT4mZ3Q7IHdyb3RlOjwvZGl2Pg0KPGJyIGNsYXNzPSJBcHBsZS1pbnRlcmNoYW5nZS1uZXds aW5lIj4NCjxkaXYgY2xhc3M9IiI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7 IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fwczog bm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyB0ZXh0 LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdo aXRlLXNwYWNlOiBub3JtYWw7IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tl LXdpZHRoOiAwcHg7IGZsb2F0OiBub25lOyBkaXNwbGF5OiBpbmxpbmUgIWltcG9ydGFudDsiIGNs YXNzPSIiPuKApg0KIHNuaXAgLi4uPC9zcGFuPjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4N CjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvYmxvY2tx dW90ZT4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xhc3M9IiI+DQo8ZGl2IGNs YXNzPSIiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6IDEy cHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9udC13 ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgdGV4dC1hbGlnbjogc3RhcnQ7 IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9y bWFsOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyBm bG9hdDogbm9uZTsgZGlzcGxheTogaW5saW5lICFpbXBvcnRhbnQ7IiBjbGFzcz0iIj50aGUNCiBz aWduYWwvZGF0YSBwcm90b2NvbHMgbmVlZHMgdG8gZGVhbCB3aXRoIGNvbW11bmljYXRpb24gbG9v cHMgLi4uJnF1b3Q7KTwvc3Bhbj48YnIgc3R5bGU9ImZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZv bnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fwczogbm9y bWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyB0ZXh0LWFs aWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRl LXNwYWNlOiBub3JtYWw7IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdp ZHRoOiAwcHg7IiBjbGFzcz0iIj4NCjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTogSGVsdmV0aWNh OyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWNhcHM6 IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgdGV4 dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3 aGl0ZS1zcGFjZTogbm9ybWFsOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9r ZS13aWR0aDogMHB4OyBmbG9hdDogbm9uZTsgZGlzcGxheTogaW5saW5lICFpbXBvcnRhbnQ7IiBj bGFzcz0iIj5hbmQNCiB0aGUgcmVzdCBiZSB3b3JrZWQgb3V0IGluIHRoZSBwcm90b2NvbCBkcmFm dHM/JnF1b3Q7PC9zcGFuPjxiciBzdHlsZT0iZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1z aXplOiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7 IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IHRleHQtYWxpZ246 IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3Bh Y2U6IG5vcm1hbDsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6 IDBweDsiIGNsYXNzPSIiPg0KPGJyIHN0eWxlPSJmb250LWZhbWlseTogSGVsdmV0aWNhOyBmb250 LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWNhcHM6IG5vcm1h bDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgdGV4dC1hbGln bjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1z cGFjZTogbm9ybWFsOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0 aDogMHB4OyIgY2xhc3M9IiI+DQo8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6IEhlbHZldGljYTsg Zm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudC1jYXBzOiBu b3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IHRleHQt YWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hp dGUtc3BhY2U6IG5vcm1hbDsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Ut d2lkdGg6IDBweDsgZmxvYXQ6IG5vbmU7IGRpc3BsYXk6IGlubGluZSAhaW1wb3J0YW50OyIgY2xh c3M9IiI+SQ0KIGRvIG5vdCBiZWxpZXZlIHRoYXQgaG93IHRvIGRvIHRoaXMgbmVlZHMgdG8gYmUg c3BlbHQgb3V0IGluIHRoZTwvc3Bhbj48YnIgc3R5bGU9ImZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7 IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fwczog bm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyB0ZXh0 LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdo aXRlLXNwYWNlOiBub3JtYWw7IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tl LXdpZHRoOiAwcHg7IiBjbGFzcz0iIj4NCjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTogSGVsdmV0 aWNhOyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWNh cHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsg dGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25l OyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0 cm9rZS13aWR0aDogMHB4OyBmbG9hdDogbm9uZTsgZGlzcGxheTogaW5saW5lICFpbXBvcnRhbnQ7 IiBjbGFzcz0iIj5yZXF1aXJlbWVudHMNCiBkcmFmdC4gJm5ic3A7WW91ciBzdWdnZXN0ZWQgdGV4 dCB3b3JrcyBmb3IgbWUgYW5kIGlzIGEgZ29vZCBzdGFydGluZzwvc3Bhbj48YnIgc3R5bGU9ImZv bnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFs OyBmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXIt c3BhY2luZzogbm9ybWFsOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4 dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdvcmQtc3BhY2luZzogMHB4 OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IiBjbGFzcz0iIj4NCjxzcGFuIHN0eWxl PSJmb250LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5v cm1hbDsgZm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0 dGVyLXNwYWNpbmc6IG5vcm1hbDsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7 IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3b3JkLXNwYWNpbmc6 IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyBmbG9hdDogbm9uZTsgZGlzcGxh eTogaW5saW5lICFpbXBvcnRhbnQ7IiBjbGFzcz0iIj5wb2ludA0KIGZvciBwb3NzaWJseSBhZGRp bmcgYXQgdGhlIGVuZCBvZiAmcXVvdDtHRU4tMDAyIFJlc2lsaWVuY2UgYW5kIFJvYnVzdG5lc3Pi gJ0sPC9zcGFuPjxiciBzdHlsZT0iZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAx MnB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7IGZvbnQt d2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IHRleHQtYWxpZ246IHN0YXJ0 OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5v cm1hbDsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsi IGNsYXNzPSIiPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2PjxiciBjbGFzcz0iIj4NCjwv ZGl2Pg0KPGRpdj5JIGNhbiBkbyB0aGlzLjwvZGl2Pg0KPGJyIGNsYXNzPSIiPg0KPGJsb2NrcXVv dGUgdHlwZT0iY2l0ZSIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPjxzcGFuIHN0eWxlPSJmb250 LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsg Zm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNw YWNpbmc6IG5vcm1hbDsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQt dHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3b3JkLXNwYWNpbmc6IDBweDsg LXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyBmbG9hdDogbm9uZTsgZGlzcGxheTogaW5s aW5lICFpbXBvcnRhbnQ7IiBjbGFzcz0iIj5ldmVuDQogdGhvdWdoIHRoYXQgc2VjdGlvbiBpcyBw cmltYXJpbHkgZm9yIHNpZ25hbGxpbmcuPC9zcGFuPjxiciBzdHlsZT0iZm9udC1mYW1pbHk6IEhl bHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFu dC1jYXBzOiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3Jt YWw7IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTog bm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4 dC1zdHJva2Utd2lkdGg6IDBweDsiIGNsYXNzPSIiPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8 ZGl2PjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdj5Ob3cgd291bGQgYmUgYSBncmVhdCB0aW1l IHRvIGhlYXIgY29uY2VybnMgYWJvdXQgZG9jdW1lbnQgc3RydWN0dXJlLiBBcmUgeW91IHN1Z2dl c3RpbmcgdGhlIGdlbmVyYWwgcmVxdWlyZW1lbnRzIHNlY3Rpb24gc2hvdWxkIGJl4oCmZ2VuZXJh bGx54oCmc3Vic3VtZWQgaW50byB0aGUgc2lnbmFsIGFuZCBkYXRhIGNoYW5uZWwgcmVxcyBzZWN0 aW9uPzwvZGl2Pg0KPGRpdj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXY+YW5kcmV3PC9kaXY+ DQo8ZGl2PjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4N CjxkaXY+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8YnIgY2xhc3M9IiI+DQo8YmxvY2txdW90ZSB0 eXBlPSJjaXRlIiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+PHNwYW4gc3R5bGU9ImZvbnQtZmFt aWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250 LXZhcmlhbnQtY2Fwczogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2lu Zzogbm9ybWFsOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFu c2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdvcmQtc3BhY2luZzogMHB4OyAtd2Vi a2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IGZsb2F0OiBub25lOyBkaXNwbGF5OiBpbmxpbmUg IWltcG9ydGFudDsiIGNsYXNzPSIiPi0tLS0tT3JpZ2luYWwNCiBNZXNzYWdlLS0tLS08L3NwYW4+ PGJyIHN0eWxlPSJmb250LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6IDEycHg7IGZvbnQt c3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5v cm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5k ZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3b3Jk LXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyIgY2xhc3M9IiI+ DQo8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBm b250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7IGZvbnQtd2VpZ2h0 OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0 LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsg d29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsgZmxvYXQ6 IG5vbmU7IGRpc3BsYXk6IGlubGluZSAhaW1wb3J0YW50OyIgY2xhc3M9IiI+RnJvbToNCiBEb3Rz IFttYWlsdG86PHNwYW4gY2xhc3M9IkFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFu Pjwvc3Bhbj48YSBocmVmPSJtYWlsdG86ZG90cy1ib3VuY2VzQGlldGYub3JnIiBzdHlsZT0iZm9u dC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7 IGZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1z cGFjaW5nOiBub3JtYWw7IG9ycGhhbnM6IGF1dG87IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWlu ZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd2lk b3dzOiBhdXRvOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXNpemUtYWRqdXN0OiBh dXRvOyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IiBjbGFzcz0iIj5kb3RzLWJvdW5j ZXNAaWV0Zi5vcmc8L2E+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQt c2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fwczogbm9ybWFs OyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyB0ZXh0LWFsaWdu OiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNw YWNlOiBub3JtYWw7IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRo OiAwcHg7IGZsb2F0OiBub25lOyBkaXNwbGF5OiBpbmxpbmUgIWltcG9ydGFudDsiIGNsYXNzPSIi Pl0NCiBPbiBCZWhhbGYgT2YgUm9tYW4gRGFueWxpdzwvc3Bhbj48YnIgc3R5bGU9ImZvbnQtZmFt aWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250 LXZhcmlhbnQtY2Fwczogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2lu Zzogbm9ybWFsOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFu c2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdvcmQtc3BhY2luZzogMHB4OyAtd2Vi a2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IiBjbGFzcz0iIj4NCjxzcGFuIHN0eWxlPSJmb250 LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsg Zm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNw YWNpbmc6IG5vcm1hbDsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQt dHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3b3JkLXNwYWNpbmc6IDBweDsg LXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyBmbG9hdDogbm9uZTsgZGlzcGxheTogaW5s aW5lICFpbXBvcnRhbnQ7IiBjbGFzcz0iIj5TZW50Og0KIDI5IEphbnVhcnkgMjAxOCAyMTo1Mjwv c3Bhbj48YnIgc3R5bGU9ImZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsg Zm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsOyBmb250LXdlaWdo dDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4 dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7 IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IiBjbGFz cz0iIj4NCjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6IDEy cHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9udC13 ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgdGV4dC1hbGlnbjogc3RhcnQ7 IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9y bWFsOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyBm bG9hdDogbm9uZTsgZGlzcGxheTogaW5saW5lICFpbXBvcnRhbnQ7IiBjbGFzcz0iIj5UbzoNCiBL b25kYSwgVGlydW1hbGVzd2FyIFJlZGR5OyBKb24gU2hhbGxvdzsgTW9ydGVuc2VuLCBBbmRyZXc7 PHNwYW4gY2xhc3M9IkFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjwvc3Bhbj48 YSBocmVmPSJtYWlsdG86ZG90c0BpZXRmLm9yZyIgc3R5bGU9ImZvbnQtZmFtaWx5OiBIZWx2ZXRp Y2E7IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fw czogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyBv cnBoYW5zOiBhdXRvOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10 cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdpZG93czogYXV0bzsgd29yZC1z cGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zaXplLWFkanVzdDogYXV0bzsgLXdlYmtpdC10ZXh0 LXN0cm9rZS13aWR0aDogMHB4OyIgY2xhc3M9IiI+ZG90c0BpZXRmLm9yZzwvYT48YnIgc3R5bGU9 ImZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9y bWFsOyBmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0 ZXItc3BhY2luZzogbm9ybWFsOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsg dGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdvcmQtc3BhY2luZzog MHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IiBjbGFzcz0iIj4NCjxzcGFuIHN0 eWxlPSJmb250LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6 IG5vcm1hbDsgZm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsg bGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAw cHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3b3JkLXNwYWNp bmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyBmbG9hdDogbm9uZTsgZGlz cGxheTogaW5saW5lICFpbXBvcnRhbnQ7IiBjbGFzcz0iIj5TdWJqZWN0Og0KIFJlOiBbRG90c10g SS1EIEFjdGlvbjogZHJhZnQtaWV0Zi1kb3RzLXJlcXVpcmVtZW50cy0xMS50eHQ8L3NwYW4+PGJy IHN0eWxlPSJmb250LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5 bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1h bDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50 OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3b3JkLXNw YWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyIgY2xhc3M9IiI+DQo8 YnIgc3R5bGU9ImZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsgZm9udC1z dHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsOyBmb250LXdlaWdodDogbm9y bWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRl bnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdvcmQt c3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IiBjbGFzcz0iIj4N CjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6IDEycHg7IGZv bnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6 IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQt aW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3 b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyBmbG9hdDog bm9uZTsgZGlzcGxheTogaW5saW5lICFpbXBvcnRhbnQ7IiBjbGFzcz0iIj5IaQ0KIFRpcnUsIEpv biBhbmQgQW5kcmV3ITwvc3Bhbj48YnIgc3R5bGU9ImZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZv bnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fwczogbm9y bWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyB0ZXh0LWFs aWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRl LXNwYWNlOiBub3JtYWw7IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdp ZHRoOiAwcHg7IiBjbGFzcz0iIj4NCjxiciBzdHlsZT0iZm9udC1mYW1pbHk6IEhlbHZldGljYTsg Zm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudC1jYXBzOiBu b3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IHRleHQt YWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hp dGUtc3BhY2U6IG5vcm1hbDsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Ut d2lkdGg6IDBweDsiIGNsYXNzPSIiPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgc3R5bGU9ImZv bnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFs OyBmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXIt c3BhY2luZzogbm9ybWFsOyBvcnBoYW5zOiBhdXRvOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1p bmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdp ZG93czogYXV0bzsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zaXplLWFkanVzdDog YXV0bzsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyIgY2xhc3M9IiI+DQotLS0tLU9y aWdpbmFsIE1lc3NhZ2UtLS0tLTxiciBjbGFzcz0iIj4NCkZyb206IERvdHMgWzxhIGhyZWY9Im1h aWx0bzpkb3RzLWJvdW5jZXNAaWV0Zi5vcmciIGNsYXNzPSIiPm1haWx0bzpkb3RzLWJvdW5jZXNA aWV0Zi5vcmc8L2E+XSBPbiBCZWhhbGYgT2YgS29uZGEsPHNwYW4gY2xhc3M9IkFwcGxlLWNvbnZl cnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxiciBjbGFzcz0iIj4NClRpcnVtYWxlc3dhciBSZWRk eTxiciBjbGFzcz0iIj4NClNlbnQ6IFdlZG5lc2RheSwgSmFudWFyeSAyNCwgMjAxOCA4OjI2IEFN PGJyIGNsYXNzPSIiPg0KVG86IEpvbiBTaGFsbG93ICZsdDs8YSBocmVmPSJtYWlsdG86c3VwanBz LWlldGZAanBzaGFsbG93LmNvbSIgY2xhc3M9IiI+c3VwanBzLWlldGZAanBzaGFsbG93LmNvbTwv YT4mZ3Q7OyBNb3J0ZW5zZW4sIEFuZHJldzxzcGFuIGNsYXNzPSJBcHBsZS1jb252ZXJ0ZWQtc3Bh Y2UiPiZuYnNwOzwvc3Bhbj48YnIgY2xhc3M9IiI+DQombHQ7PGEgaHJlZj0ibWFpbHRvOmFtb3J0 ZW5zZW5AYXJib3IubmV0IiBjbGFzcz0iIj5hbW9ydGVuc2VuQGFyYm9yLm5ldDwvYT4mZ3Q7OyA8 YSBocmVmPSJtYWlsdG86ZG90c0BpZXRmLm9yZyIgY2xhc3M9IiI+DQpkb3RzQGlldGYub3JnPC9h PjxiciBjbGFzcz0iIj4NClN1YmplY3Q6IFJlOiBbRG90c10gSS1EIEFjdGlvbjogZHJhZnQtaWV0 Zi1kb3RzLXJlcXVpcmVtZW50cy0xMS50eHQ8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQo8 YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj4tLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0t LTxiciBjbGFzcz0iIj4NCkZyb206IERvdHMgWzxhIGhyZWY9Im1haWx0bzpkb3RzLWJvdW5jZXNA aWV0Zi5vcmciIGNsYXNzPSIiPm1haWx0bzpkb3RzLWJvdW5jZXNAaWV0Zi5vcmc8L2E+XSBPbiBC ZWhhbGYgT2YgSm9uIFNoYWxsb3c8YnIgY2xhc3M9IiI+DQpTZW50OiBXZWRuZXNkYXksIEphbnVh cnkgMjQsIDIwMTggNTo1MyBQTTxiciBjbGFzcz0iIj4NClRvOiBNb3J0ZW5zZW4sIEFuZHJldyAm bHQ7PGEgaHJlZj0ibWFpbHRvOmFtb3J0ZW5zZW5AYXJib3IubmV0IiBjbGFzcz0iIj5hbW9ydGVu c2VuQGFyYm9yLm5ldDwvYT4mZ3Q7Ow0KPGEgaHJlZj0ibWFpbHRvOmRvdHNAaWV0Zi5vcmciIGNs YXNzPSIiPmRvdHNAaWV0Zi5vcmc8L2E+PGJyIGNsYXNzPSIiPg0KU3ViamVjdDogUmU6IFtEb3Rz XSBJLUQgQWN0aW9uOiBkcmFmdC1pZXRmLWRvdHMtcmVxdWlyZW1lbnRzLTExLnR4dDxiciBjbGFz cz0iIj4NCjxiciBjbGFzcz0iIj4NCkhpIEFuZHJldyw8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9 IiI+DQpUaGVyZSBhcmUgMiBwZW5kaW5nIHJlc29sdXRpb24gaXNzdWVzIHJhaXNlZCBhYm91dCB0 aGUgc2lnbmFsIC8gZGF0YTxzcGFuIGNsYXNzPSJBcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNw Ozwvc3Bhbj48YnIgY2xhc3M9IiI+DQpjaGFubmVscyB3aGljaCBtYXkgbmVlZCB0byBiZSBpbmNs dWRlZCBpbiB0aGUgcmVxdWlyZW1lbnRzIGRyYWZ0LiAmbmJzcDtJPHNwYW4gY2xhc3M9IkFwcGxl LWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxiciBjbGFzcz0iIj4NCndhcyBwbGFubmlu ZyBvbiByYWlzaW5nIHRoZSAyIHBlbmRpbmcgcmVzb2x1dGlvbnMgYXQgdGhlIHVwY29taW5nPHNw YW4gY2xhc3M9IkFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxiciBjbGFzcz0i Ij4NClZpcnR1YWw8YnIgY2xhc3M9IiI+DQo8L2Jsb2NrcXVvdGU+DQpNZWV0aW5nLjxiciBjbGFz cz0iIj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjEp IFNpZ25hbC9EYXRhIHBhdGggbG9vcCBkZXRlY3Rpb24gcHJvdGVjdGlvbi48YnIgY2xhc3M9IiI+ DQo8YnIgY2xhc3M9IiI+DQpUaGVyZSBpcyBzb21lIHByb3Bvc2VkIHRleHQgYnkgTWVkIGFib3V0 IGxvb3AgZGV0ZWN0aW9uIGJ5IHRoZSB1c2U8c3BhbiBjbGFzcz0iQXBwbGUtY29udmVydGVkLXNw YWNlIj4mbmJzcDs8L3NwYW4+PGJyIGNsYXNzPSIiPg0Kb2YgYSBob3AtbGltaXQgcGFyYW1ldGVy LiAmbmJzcDtEbyB3ZSBuZWVkIHRpcz88YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQo8L2Js b2NrcXVvdGU+DQo8YSBocmVmPSJodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIv dXJsP3U9aHR0cHMtM0FfX21haWxhcmNoaXZlLmlldGYub3JnX2FyY2hfbXNnX2RvdHNfNjNNZndM VGxkT05iTzlnTy01RnNkVDZGRzJEJmFtcDtkPUR3SUNBZyZhbXA7Yz1IbHZwcnFvbnI1THVDTjlU TjY1eE53JmFtcDtyPU0tMF9DcUVWWGE5T1F2bUoyZ010WEF6TDZ2NkpzWkh0c1JrbWFSejR1ckUm YW1wO209RFB4d3p1MVBxTUx5S3RuYmdZSzNELWtfX0twYm5HX252eUZhVUpmaFpkRSZhbXA7cz1a QzVWWTY1UjV1QUpTQWk2SWJKNzgtR3Fhc0hoNFd2V2VGQW9mX1RwczJRJmFtcDtlPSIgY2xhc3M9 IiI+aHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTNBX19t YWlsYXJjaGl2ZS5pZXRmLm9yZ19hcmNoX21zZ19kb3RzXzYzTWZ3TFRsZE9OYk85Z08tNUZzZFQ2 RkcyRCZhbXA7ZD1Ed0lDQWcmYW1wO2M9SGx2cHJxb25yNUx1Q045VE42NXhOdyZhbXA7cj1NLTBf Q3FFVlhhOU9Rdm1KMmdNdFhBekw2djZKc1pIdHNSa21hUno0dXJFJmFtcDttPURQeHd6dTFQcU1M eUt0bmJnWUszRC1rX19LcGJuR19udnlGYVVKZmhaZEUmYW1wO3M9WkM1Vlk2NVI1dUFKU0FpNkli Sjc4LUdxYXNIaDRXdldlRkFvZl9UcHMyUSZhbXA7ZT08L2E+PGJyIGNsYXNzPSIiPg0KPGJsb2Nr cXVvdGUgdHlwZT0iY2l0ZSIgY2xhc3M9IiI+eFE8YnIgY2xhc3M9IiI+DQo8L2Jsb2NrcXVvdGU+ DQo8YnIgY2xhc3M9IiI+DQpJIGRvbid0IHNlZSBhbiBhZ3JlZW1lbnQgb24gdGhpcyBvbmUsIHBs ZWFzZSBzZWUgbXkgbGFzdCByZXNwb25zZTxzcGFuIGNsYXNzPSJBcHBsZS1jb252ZXJ0ZWQtc3Bh Y2UiPiZuYnNwOzwvc3Bhbj48YnIgY2xhc3M9IiI+DQo8YSBocmVmPSJodHRwczovL3VybGRlZmVu c2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtM0FfX21haWxhcmNoaXZlLmlldGYub3Jn X2FyY2hfbXNnX2RvdHNfcDNUYVJpTmtaT3JaNVBLcjNVSVhlMTBnOUNVJmFtcDtkPUR3SUNBZyZh bXA7Yz1IbHZwcnFvbnI1THVDTjlUTjY1eE53JmFtcDtyPU0tMF9DcUVWWGE5T1F2bUoyZ010WEF6 TDZ2NkpzWkh0c1JrbWFSejR1ckUmYW1wO209RFB4d3p1MVBxTUx5S3RuYmdZSzNELWtfX0twYm5H X252eUZhVUpmaFpkRSZhbXA7cz1Vc3owVnVNdlVfQ1ZQcWlHaHVOX0pXcUlLWjlKUjBNR2FfYXhW TG9nMmRnJmFtcDtlPSIgY2xhc3M9IiI+aHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29t L3YyL3VybD91PWh0dHBzLTNBX19tYWlsYXJjaGl2ZS5pZXRmLm9yZ19hcmNoX21zZ19kb3RzX3Az VGFSaU5rWk9yWjVQS3IzVUlYZTEwZzlDVSZhbXA7ZD1Ed0lDQWcmYW1wO2M9SGx2cHJxb25yNUx1 Q045VE42NXhOdyZhbXA7cj1NLTBfQ3FFVlhhOU9Rdm1KMmdNdFhBekw2djZKc1pIdHNSa21hUno0 dXJFJmFtcDttPURQeHd6dTFQcU1MeUt0bmJnWUszRC1rX19LcGJuR19udnlGYVVKZmhaZEUmYW1w O3M9VXN6MFZ1TXZVX0NWUHFpR2h1Tl9KV3FJS1o5SlIwTUdhX2F4VkxvZzJkZyZhbXA7ZT08L2E+ PGJyIGNsYXNzPSIiPg0KPC9ibG9ja3F1b3RlPg0KPGJyIHN0eWxlPSJmb250LWZhbWlseTogSGVs dmV0aWNhOyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50 LWNhcHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1h bDsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBu b25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0 LXN0cm9rZS13aWR0aDogMHB4OyIgY2xhc3M9IiI+DQo8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6 IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFy aWFudC1jYXBzOiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBu b3JtYWw7IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9y bTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQt dGV4dC1zdHJva2Utd2lkdGg6IDBweDsgZmxvYXQ6IG5vbmU7IGRpc3BsYXk6IGlubGluZSAhaW1w b3J0YW50OyIgY2xhc3M9IiI+SQ0KIHNlZSB0aGUgbGFjayBvZiBjb25zZW5zdXMgb24gaG93IHRv IGhhbmRsZSBsb29wcy4gJm5ic3A7RG9lcyB0aGlzIGlzc3VlIG5lZWQgdG88L3NwYW4+PGJyIHN0 eWxlPSJmb250LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6 IG5vcm1hbDsgZm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsg bGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAw cHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3b3JkLXNwYWNp bmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyIgY2xhc3M9IiI+DQo8c3Bh biBzdHlsZT0iZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0 eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3Jt YWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVu dDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd29yZC1z cGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsgZmxvYXQ6IG5vbmU7 IGRpc3BsYXk6IGlubGluZSAhaW1wb3J0YW50OyIgY2xhc3M9IiI+YmUNCiByZXNvbHZlZCB3aXRo IHRleHQgaW4gdGhlIHJlcXVpcmVtZW50cyBkcmFmdD8gJm5ic3A7Q291bGQgYSBzaW1wbGUgcmVx dWlyZW1lbnQ8L3NwYW4+PGJyIHN0eWxlPSJmb250LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNp emU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDsg Zm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgdGV4dC1hbGlnbjog c3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFj ZTogbm9ybWFsOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDog MHB4OyIgY2xhc3M9IiI+DQo8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9u dC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudC1jYXBzOiBub3Jt YWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IHRleHQtYWxp Z246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUt c3BhY2U6IG5vcm1hbDsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lk dGg6IDBweDsgZmxvYXQ6IG5vbmU7IGRpc3BsYXk6IGlubGluZSAhaW1wb3J0YW50OyIgY2xhc3M9 IiI+YWNrbm93bGVkZ2luZw0KIHRoZSBwb3NzaWJpbGl0eSBvZiB0aGUgcHJvYmxlbSBiZSBtYWRl IChlLmcuLCBzdWNoIGFzICZxdW90O3RoZTwvc3Bhbj48YnIgc3R5bGU9ImZvbnQtZmFtaWx5OiBI ZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlh bnQtY2Fwczogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9y bWFsOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06 IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRl eHQtc3Ryb2tlLXdpZHRoOiAwcHg7IiBjbGFzcz0iIj4NCjxzcGFuIHN0eWxlPSJmb250LWZhbWls eTogSGVsdmV0aWNhOyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12 YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6 IG5vcm1hbDsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNm b3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtp dC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyBmbG9hdDogbm9uZTsgZGlzcGxheTogaW5saW5lICFp bXBvcnRhbnQ7IiBjbGFzcz0iIj5zaWduYWwvZGF0YQ0KIHByb3RvY29scyBuZWVkcyB0byBkZWFs IHdpdGggY29tbXVuaWNhdGlvbiBsb29wcyAuLi4mcXVvdDspIGFuZCB0aGU8L3NwYW4+PGJyIHN0 eWxlPSJmb250LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6 IG5vcm1hbDsgZm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsg bGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAw cHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3b3JkLXNwYWNp bmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyIgY2xhc3M9IiI+DQo8c3Bh biBzdHlsZT0iZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0 eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3Jt YWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVu dDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd29yZC1z cGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsgZmxvYXQ6IG5vbmU7 IGRpc3BsYXk6IGlubGluZSAhaW1wb3J0YW50OyIgY2xhc3M9IiI+cmVzdA0KIGJlIHdvcmtlZCBv dXQgaW4gdGhlIHByb3RvY29sIGRyYWZ0cz88L3NwYW4+PGJyIHN0eWxlPSJmb250LWZhbWlseTog SGVsdmV0aWNhOyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJp YW50LWNhcHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5v cm1hbDsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3Jt OiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10 ZXh0LXN0cm9rZS13aWR0aDogMHB4OyIgY2xhc3M9IiI+DQo8YnIgc3R5bGU9ImZvbnQtZmFtaWx5 OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZh cmlhbnQtY2Fwczogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzog bm9ybWFsOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zv cm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0 LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IiBjbGFzcz0iIj4NCjxzcGFuIHN0eWxlPSJmb250LWZh bWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9u dC12YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNp bmc6IG5vcm1hbDsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJh bnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdl YmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyBmbG9hdDogbm9uZTsgZGlzcGxheTogaW5saW5l ICFpbXBvcnRhbnQ7IiBjbGFzcz0iIj5Sb21hbjwvc3Bhbj48YnIgc3R5bGU9ImZvbnQtZmFtaWx5 OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZh cmlhbnQtY2Fwczogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzog bm9ybWFsOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zv cm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0 LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IiBjbGFzcz0iIj4NCjxiciBzdHlsZT0iZm9udC1mYW1p bHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQt dmFyaWFudC1jYXBzOiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5n OiBub3JtYWw7IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5z Zm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJr aXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsiIGNsYXNzPSIiPg0KPHNwYW4gc3R5bGU9ImZvbnQt ZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFsOyBm b250LXZhcmlhbnQtY2Fwczogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3Bh Y2luZzogbm9ybWFsOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10 cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdvcmQtc3BhY2luZzogMHB4OyAt d2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IGZsb2F0OiBub25lOyBkaXNwbGF5OiBpbmxp bmUgIWltcG9ydGFudDsiIGNsYXNzPSIiPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fPC9zcGFuPjxiciBzdHlsZT0iZm9udC1mYW1pbHk6IEhlbHZldGljYTsg Zm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudC1jYXBzOiBu b3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IHRleHQt YWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hp dGUtc3BhY2U6IG5vcm1hbDsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Ut d2lkdGg6IDBweDsiIGNsYXNzPSIiPg0KPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiBIZWx2ZXRp Y2E7IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fw czogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyB0 ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7 IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ry b2tlLXdpZHRoOiAwcHg7IGZsb2F0OiBub25lOyBkaXNwbGF5OiBpbmxpbmUgIWltcG9ydGFudDsi IGNsYXNzPSIiPkRvdHMNCiBtYWlsaW5nIGxpc3Q8L3NwYW4+PGJyIHN0eWxlPSJmb250LWZhbWls eTogSGVsdmV0aWNhOyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12 YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6 IG5vcm1hbDsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNm b3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtp dC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyIgY2xhc3M9IiI+DQo8YSBocmVmPSJtYWlsdG86RG90 c0BpZXRmLm9yZyIgc3R5bGU9ImZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJw eDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsOyBmb250LXdl aWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyBvcnBoYW5zOiBhdXRvOyB0ZXh0 LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdo aXRlLXNwYWNlOiBub3JtYWw7IHdpZG93czogYXV0bzsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJr aXQtdGV4dC1zaXplLWFkanVzdDogYXV0bzsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4 OyIgY2xhc3M9IiI+RG90c0BpZXRmLm9yZzwvYT48YnIgc3R5bGU9ImZvbnQtZmFtaWx5OiBIZWx2 ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQt Y2Fwczogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFs OyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5v bmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQt c3Ryb2tlLXdpZHRoOiAwcHg7IiBjbGFzcz0iIj4NCjxhIGhyZWY9Imh0dHBzOi8vdXJsZGVmZW5z ZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fd3d3LmlldGYub3JnX21haWxtYW5f bGlzdGluZm9fZG90cyZhbXA7ZD1Ed0lDQWcmYW1wO2M9SGx2cHJxb25yNUx1Q045VE42NXhOdyZh bXA7cj1NLTBfQ3FFVlhhOU9Rdm1KMmdNdFhBekw2djZKc1pIdHNSa21hUno0dXJFJmFtcDttPURQ eHd6dTFQcU1MeUt0bmJnWUszRC1rX19LcGJuR19udnlGYVVKZmhaZEUmYW1wO3M9aF9GLXlYRXlQ VmNzek1GVzdfWUdkZDRvckM1OGYtTV94MjlGX29IbDloTSZhbXA7ZT0iIHN0eWxlPSJmb250LWZh bWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9u dC12YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNp bmc6IG5vcm1hbDsgb3JwaGFuczogYXV0bzsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50 OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3aWRvd3M6 IGF1dG87IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc2l6ZS1hZGp1c3Q6IGF1dG87 IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsiIGNsYXNzPSIiPmh0dHBzOi8vdXJsZGVm ZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fd3d3LmlldGYub3JnX21haWxt YW5fbGlzdGluZm9fZG90cyZhbXA7ZD1Ed0lDQWcmYW1wO2M9SGx2cHJxb25yNUx1Q045VE42NXhO dyZhbXA7cj1NLTBfQ3FFVlhhOU9Rdm1KMmdNdFhBekw2djZKc1pIdHNSa21hUno0dXJFJmFtcDtt PURQeHd6dTFQcU1MeUt0bmJnWUszRC1rX19LcGJuR19udnlGYVVKZmhaZEUmYW1wO3M9aF9GLXlY RXlQVmNzek1GVzdfWUdkZDRvckM1OGYtTV94MjlGX29IbDloTSZhbXA7ZT08L2E+PC9kaXY+DQo8 L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxiciBjbGFzcz0iIj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_992FCC41586F4AE4B1794F35D2995848arbornet_-- From nobody Tue Jan 30 11:28:29 2018 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 F3FAC124B18 for ; Tue, 30 Jan 2018 11:28:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 2R1ikr4sV4Wk for ; Tue, 30 Jan 2018 11:28:24 -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 A7A9113170B for ; Tue, 30 Jan 2018 11:28:16 -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 1egbZm-0003O3-Ty; Tue, 30 Jan 2018 19:28:15 +0000 From: "Jon Shallow" To: "'Mortensen, Andrew'" , , "Konda, Tirumaleswar Reddy" , References: <151674641498.15562.4768813409058823004@ietfa.amsl.com> <1867660E-4B54-405F-B87E-3CDBC2D46442@arbor.net> <787AE7BB302AE849A7480A190F8B93300A0C5F86@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <0cb501d3950e$0e956970$2bc03c50$@jpshallow.com> <359EC4B99E040048A7131E0F4E113AFC0137507E0A@marathon> <13d401d399c3$73b635f0$5b22a1d0$@jpshallow.com> <992FCC41-586F-4AE4-B179-4F35D2995848@arbor.net> In-Reply-To: <992FCC41-586F-4AE4-B179-4F35D2995848@arbor.net> Date: Tue, 30 Jan 2018 19:28:17 -0000 Message-ID: <145401d39a00$7aa7ef60$6ff7ce20$@jpshallow.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_1455_01D39A00.7AA94EF0" X-Mailer: Microsoft Outlook 14.0 Content-Language: en-gb Thread-Index: AQJ5ab1ci+yv597yyML+ycymhWTtfQLExSLWAhr2hxoBEskMywHQibuGAuaHpnYCH86lWQIfLfXvocnonYA= Archived-At: Subject: Re: [Dots] I-D Action: draft-ietf-dots-requirements-11.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, 30 Jan 2018 19:28:28 -0000 This is a multipart message in MIME format. ------=_NextPart_000_1455_01D39A00.7AA94EF0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hi Andrew, =20 Apologies =E2=80=93 I did not make myself clear =E2=80=93 I was = referring to the GEN-002 section in my comment, not the whole of the = General Requirements Section. =20 I do think that there should be a =E2=80=98General Requirements=E2=80=99 = that cover both signal and data that does not fit under Data Model = Requirements or Security Requirements. =20 That said, GEN-003 could be moved to under SIG- as Bidirectionality is = signal specific. =20 Regards =20 Jon =20 =20 From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Mortensen, Andrew Sent: 30 January 2018 17:32 To: Jon Shallow Cc: Roman Danyliw; Konda, Tirumaleswar Reddy; dots@ietf.org Subject: Re: [Dots] I-D Action: draft-ietf-dots-requirements-11.txt =20 =20 On Jan 30, 2018, at 7:11 AM, Jon Shallow = wrote: =20 =E2=80=A6 snip ... =20 the signal/data protocols needs to deal with communication loops ...") and the rest be worked out in the protocol drafts?" I do not believe that how to do this needs to be spelt out in the requirements draft. Your suggested text works for me and is a good = starting point for possibly adding at the end of "GEN-002 Resilience and = Robustness=E2=80=9D, =20 I can do this. even though that section is primarily for signalling. =20 Now would be a great time to hear concerns about document structure. Are = you suggesting the general requirements section should = be=E2=80=A6generally=E2=80=A6subsumed into the signal and data channel = reqs section? =20 andrew =20 =20 =20 -----Original Message----- From: Dots [mailto: = dots-bounces@ietf.org] On Behalf Of Roman Danyliw Sent: 29 January 2018 21:52 To: Konda, Tirumaleswar Reddy; Jon Shallow; Mortensen, Andrew; = dots@ietf.org Subject: Re: [Dots] I-D Action: draft-ietf-dots-requirements-11.txt Hi Tiru, Jon and Andrew! -----Original Message----- From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Konda,=20 Tirumaleswar Reddy Sent: Wednesday, January 24, 2018 8:26 AM To: Jon Shallow ; Mortensen, Andrew=20 ; dots@ietf.org Subject: Re: [Dots] I-D Action: draft-ietf-dots-requirements-11.txt -----Original Message----- From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Jon Shallow Sent: Wednesday, January 24, 2018 5:53 PM To: Mortensen, Andrew ; dots@ietf.org Subject: Re: [Dots] I-D Action: draft-ietf-dots-requirements-11.txt Hi Andrew, There are 2 pending resolution issues raised about the signal / data=20 channels which may need to be included in the requirements draft. I=20 was planning on raising the 2 pending resolutions at the upcoming=20 Virtual Meeting. 1) Signal/Data path loop detection protection. There is some proposed text by Med about loop detection by the use=20 of a hop-limit parameter. Do we need tis? https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__mailarchive.ietf.o= rg_arch_msg_dots_63MfwLTldONbO9gO-5FsdT6FG2D = = &d=3DDwICAg&c=3DHlvprqonr5LuCN9TN65xNw&r=3DM-0_CqEVXa9OQvmJ2gMtXAzL6v6JsZ= HtsRkmaRz4urE&m=3DDPxwzu1PqMLyKtnbgYK3D-k__KpbnG_nvyFaUJfhZdE&s=3DZC5VY65= R5uAJSAi6IbJ78-GqasHh4WvWeFAof_Tps2Q&e=3D xQ I don't see an agreement on this one, please see my last response=20 https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__mailarchive.ietf.o= rg_arch_msg_dots_p3TaRiNkZOrZ5PKr3UIXe10g9CU = = &d=3DDwICAg&c=3DHlvprqonr5LuCN9TN65xNw&r=3DM-0_CqEVXa9OQvmJ2gMtXAzL6v6JsZ= HtsRkmaRz4urE&m=3DDPxwzu1PqMLyKtnbgYK3D-k__KpbnG_nvyFaUJfhZdE&s=3DUsz0VuM= vU_CVPqiGhuN_JWqIKZ9JR0MGa_axVLog2dg&e=3D I see the lack of consensus on how to handle loops. Does this issue = need to be resolved with text in the requirements draft? Could a simple = requirement acknowledging the possibility of the problem be made (e.g., such as "the signal/data protocols needs to deal with communication loops ...") and = the rest be worked out in the protocol drafts? Roman _______________________________________________ Dots mailing list Dots@ietf.org = = https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailm= an_listinfo_dots&d=3DDwICAg&c=3DHlvprqonr5LuCN9TN65xNw&r=3DM-0_CqEVXa9OQv= mJ2gMtXAzL6v6JsZHtsRkmaRz4urE&m=3DDPxwzu1PqMLyKtnbgYK3D-k__KpbnG_nvyFaUJf= hZdE&s=3Dh_F-yXEyPVcszMFW7_YGdd4orC58f-M_x29F_oHl9hM&e=3D =20 ------=_NextPart_000_1455_01D39A00.7AA94EF0 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Hi Andrew,

 

Apologies =E2=80=93 I did not make myself clear =E2=80=93 I was = referring to the GEN-002 section in my comment, not the whole of the = General Requirements Section.

 

I do think that there should be a =E2=80=98General = Requirements=E2=80=99 that cover both signal and data that does not fit = under Data Model Requirements or Security = Requirements.

 

That said, GEN-003 could be moved to under SIG- as Bidirectionality =  is signal specific.

 

Regards

 

Jon

 

 

From:= Dots = [mailto:dots-bounces@ietf.org] On Behalf Of Mortensen, = Andrew
Sent: 30 January 2018 17:32
To: Jon = Shallow
Cc: Roman Danyliw; Konda, Tirumaleswar Reddy; = dots@ietf.org
Subject: Re: [Dots] I-D Action: = draft-ietf-dots-requirements-11.txt

 

 

On Jan 30, 2018, at 7:11 AM, Jon Shallow <supjps-ietf@jpshallow.com&g= t; wrote:

 

=E2=80=A6 = snip ...

 

the = signal/data protocols needs to deal with communication loops = ...")
and the rest be worked out in the protocol = drafts?"

I do not believe that how to do this needs to be = spelt out in the
requirements draft.  Your suggested text works = for me and is a good starting
point for possibly adding at the end of = "GEN-002 Resilience and = Robustness=E2=80=9D,

 

I = can do this.



even = though that section is primarily for = signalling.

 

Now would be a great time to hear concerns about = document structure. Are you suggesting the general requirements section = should be=E2=80=A6generally=E2=80=A6subsumed into the signal and data = channel reqs section?

 

andrew

 

 

 



-----Origi= nal Message-----
From: Dots [mailto: dots-bounc= es@ietf.org] On = Behalf Of Roman Danyliw
Sent: 29 January 2018 21:52
To: Konda, = Tirumaleswar Reddy; Jon Shallow; Mortensen, Andrew; dots@ietf.= org
Subjec= t: Re: [Dots] I-D Action: draft-ietf-dots-requirements-11.txt

Hi = Tiru, Jon and Andrew!


-----Origi= nal Message-----
From: Dots [mailto:dots-bounces@ietf.org] = On Behalf Of Konda, 
Tirumaleswar = Reddy
Sent: Wednesday, January 24, 2018 8:26 AM
To: Jon Shallow = <supjps-ietf@jpshallow.com&g= t;; Mortensen, Andrew 
<amortensen@arbor.net>; dots@ietf.org
Subject: Re: [Dots] = I-D Action: = draft-ietf-dots-requirements-11.txt


-----Origi= nal Message-----
From: Dots [mailto:dots-bounces@ietf.org] = On Behalf Of Jon Shallow
Sent: Wednesday, January 24, 2018 5:53 = PM
To: Mortensen, Andrew <amortensen@arbor.net>; dots@ietf.org
Subject: Re: [Dots] = I-D Action: draft-ietf-dots-requirements-11.txt

Hi = Andrew,

There are 2 pending resolution issues raised about the = signal / data 
channels which may need = to be included in the requirements draft.  I 
was planning on raising = the 2 pending resolutions at the upcoming 
Virtual<= /p>

Meeting.


1) = Signal/Data path loop detection protection.

There is some = proposed text by Med about loop detection by the use 
of a hop-limit parameter. =  Do we need tis?

https://urldefense.proofpoi= nt.com/v2/url?u=3Dhttps-3A__mailarchive.ietf.org_arch_msg_dots_63MfwLTldO= NbO9gO-5FsdT6FG2D&d=3DDwICAg&c=3DHlvprqonr5LuCN9TN65xNw&r=3DM= -0_CqEVXa9OQvmJ2gMtXAzL6v6JsZHtsRkmaRz4urE&m=3DDPxwzu1PqMLyKtnbgYK3D-= k__KpbnG_nvyFaUJfhZdE&s=3DZC5VY65R5uAJSAi6IbJ78-GqasHh4WvWeFAof_Tps2Q= &e=3D

xQ


I = don't see an agreement on this one, please see my last response 
https://urldefense.proofpoi= nt.com/v2/url?u=3Dhttps-3A__mailarchive.ietf.org_arch_msg_dots_p3TaRiNkZO= rZ5PKr3UIXe10g9CU&d=3DDwICAg&c=3DHlvprqonr5LuCN9TN65xNw&r=3DM= -0_CqEVXa9OQvmJ2gMtXAzL6v6JsZHtsRkmaRz4urE&m=3DDPxwzu1PqMLyKtnbgYK3D-= k__KpbnG_nvyFaUJfhZdE&s=3DUsz0VuMvU_CVPqiGhuN_JWqIKZ9JR0MGa_axVLog2dg= &e=3D


I see = the lack of consensus on how to handle loops.  Does this issue need = to
be resolved with text in the requirements draft?  Could a = simple requirement
acknowledging the possibility of the problem be = made (e.g., such as "the
signal/data protocols needs to deal = with communication loops ...") and the
rest be worked out in the = protocol = drafts?

Roman

_____________________________________________= __
Dots mailing list
Dots@ietf.= org
https://ur= ldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailman_listinf= o_dots&d=3DDwICAg&c=3DHlvprqonr5LuCN9TN65xNw&r=3DM-0_CqEVXa9O= QvmJ2gMtXAzL6v6JsZHtsRkmaRz4urE&m=3DDPxwzu1PqMLyKtnbgYK3D-k__KpbnG_nv= yFaUJfhZdE&s=3Dh_F-yXEyPVcszMFW7_YGdd4orC58f-M_x29F_oHl9hM&e=3D

 

------=_NextPart_000_1455_01D39A00.7AA94EF0--