From nobody Fri Mar 2 05:06: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 5E750126BF6 for ; Fri, 2 Mar 2018 05:06: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, 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 9kByF6T_OeTX for ; Fri, 2 Mar 2018 05:06:52 -0800 (PST) Received: from mail.jpshallow.com (mail.jpshallow.com [217.40.240.153]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DFFF2124E15 for ; Fri, 2 Mar 2018 05:06:51 -0800 (PST) Received: from [127.0.0.1] (helo=N01332) by mail.jpshallow.com with smtps (TLSv1:ECDHE-RSA-AES256-SHA:256) (Exim 4.89) (envelope-from ) id 1erkOf-0003ZZ-04 for ietf-supjps-dots@ietf.org; Fri, 02 Mar 2018 13:06:49 +0000 From: "Jon Shallow" To: Date: Fri, 2 Mar 2018 13:06:51 -0000 Message-ID: <051501d3b227$54ca2940$fe5e7bc0$@jpshallow.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0516_01D3B227.54CAC580" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdOyJ1OPH1rWUvGJQ7iqkYAQVKZXdA== Content-Language: en-gb Archived-At: Subject: [Dots] Data Channel DOTS Gateways 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, 02 Mar 2018 13:06:53 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0516_01D3B227.54CAC580 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi there, I'm currently having an implementation challenge when using a DOTS gateway in the data channel. If the DOTS Gateway knows about 2 upstream DOTS servers (perhaps 2 different ISPs), what should be done when an alias/acl update comes in from the original DOTS clients. Should the request be forwarded on to both servers? With the signal channel, I am currently sending the mitigation request to the first defined server that is "alive". The current text reads 3. DOTS Data Channel: Design Overview Some paragraphs later If a DOTS gateway is involved, the DOTS gateway verifies that the DOTS client is authorized to undertake a data channel action (e.g., instantiate filtering rules). If the DOTS client is authorized, it propagates the rules to the upstream DOTS server. Likewise, the DOTS server verifies that the DOTS gateway is authorized to relay data channel actions. For example, to create or purge filters, a DOTS client sends its request to its DOTS gateway. The DOTS gateway validates the rules in the request and proxies the requests containing the filtering rules to its DOTS server. When the DOTS gateway receives the associated response from the DOTS server, it propagates the response back to the DOTS client. where both "propagate" and "proxies" are used. If the request is propagated to both Servers, but one server sends back a different response code, what should be done? Do we just take the first valid server? - I think the answer is no, but what do we do? What happens about synchronization of the alias/acl information (I know that this is in one sense out of scope, but..) between all the final DOTs servers if there are multiple servers - possibly across multiple DOTS mitigation services(ISPs)? Regards Jon ------=_NextPart_000_0516_01D3B227.54CAC580 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi = there,

 

I’m currently having an implementation challenge = when using a DOTS gateway in the data channel.

 

If the DOTS = Gateway knows about 2 upstream DOTS servers (perhaps 2 different ISPs), = what should be done when an alias/acl update comes in from the original = DOTS clients.  Should the request be forwarded on to both = servers?

 

With the signal channel, I am currently sending the = mitigation request to the first defined server that is = “alive”.

 

The current = text reads

 

3.  DOTS Data Channel: Design = Overview

Some paragraphs = later

   If a DOTS gateway = is involved, the DOTS gateway verifies that the

   DOTS client is authorized to undertake a = data channel action (e.g.,

   instantiate filtering rules).  If = the DOTS client is authorized, it

   propagates the rules to the upstream DOTS = server.  Likewise, the DOTS

   server verifies that the DOTS gateway is = authorized to relay data

   = channel actions.  For example, to create or purge filters, a = DOTS

   client sends its = request to its DOTS gateway.  The DOTS gateway

   validates the rules in the request and = proxies the requests

   = containing the filtering rules to its DOTS server.  When the = DOTS

   gateway receives = the associated response from the DOTS server, it

   propagates the response back to the DOTS = client.

 

where both “propagate” and = “proxies” are used.   If the request is propagated = to both Servers, but one server sends back a different response code, = what should be done?

 

Do we just = take the first valid server?

- I = think the answer is no, but what do we do?

 

What happens = about synchronization of the alias/acl information (I know that this is = in one sense out of scope, but..) between all the final DOTs servers if = there are multiple servers – possibly across multiple DOTS = mitigation services(ISPs)?

 

Regards

 

Jon

------=_NextPart_000_0516_01D3B227.54CAC580-- From nobody Fri Mar 2 05:48: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 14A6C1267BB for ; Fri, 2 Mar 2018 05:48:09 -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 COsvw8QOERYy for ; Fri, 2 Mar 2018 05:48:07 -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 DDC8C124B18 for ; Fri, 2 Mar 2018 05:48:06 -0800 (PST) Received: from opfedar04.francetelecom.fr (unknown [xx.xx.xx.6]) by opfedar20.francetelecom.fr (ESMTP service) with ESMTP id A9F65120FDD; Fri, 2 Mar 2018 14:48:05 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.32]) by opfedar04.francetelecom.fr (ESMTP service) with ESMTP id 8410A40079; Fri, 2 Mar 2018 14:48:05 +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.0382.000; Fri, 2 Mar 2018 14:48:05 +0100 From: To: Jon Shallow , "dots@ietf.org" Thread-Topic: [Dots] Data Channel DOTS Gateways Thread-Index: AdOyJ1OPH1rWUvGJQ7iqkYAQVKZXdAAA5Vxw Date: Fri, 2 Mar 2018 13:48:04 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93300A0E30BC@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <051501d3b227$54ca2940$fe5e7bc0$@jpshallow.com> In-Reply-To: <051501d3b227$54ca2940$fe5e7bc0$@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_787AE7BB302AE849A7480A190F8B93300A0E30BCOPEXCLILMA3corp_" MIME-Version: 1.0 Archived-At: Subject: Re: [Dots] Data Channel DOTS Gateways 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, 02 Mar 2018 13:48:09 -0000 --_000_787AE7BB302AE849A7480A190F8B93300A0E30BCOPEXCLILMA3corp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Jon, Please see inline. Cheers, Med De : Dots [mailto:dots-bounces@ietf.org] De la part de Jon Shallow Envoy=E9 : vendredi 2 mars 2018 14:07 =C0 : dots@ietf.org Objet : [Dots] Data Channel DOTS Gateways Hi there, I'm currently having an implementation challenge when using a DOTS gateway = in the data channel. If the DOTS Gateway knows about 2 upstream DOTS servers (perhaps 2 differen= t ISPs), what should be done when an alias/acl update comes in from the ori= ginal DOTS clients. Should the request be forwarded on to both servers? [Med] It depends. Please check https://tools.ietf.org/html/draft-boucadair-= dots-multihoming-02 (the discussion about PI/PA). With the signal channel, I am currently sending the mitigation request to t= he first defined server that is "alive". [Med] Idem as above, sending a request to a server which cannot act on a gi= ven resource is not helpful. Please refer to the multi-homing I-D. The current text reads 3. DOTS Data Channel: Design Overview Some paragraphs later If a DOTS gateway is involved, the DOTS gateway verifies that the DOTS client is authorized to undertake a data channel action (e.g., instantiate filtering rules). If the DOTS client is authorized, it propagates the rules to the upstream DOTS server. Likewise, the DOTS server verifies that the DOTS gateway is authorized to relay data channel actions. For example, to create or purge filters, a DOTS client sends its request to its DOTS gateway. The DOTS gateway validates the rules in the request and proxies the requests containing the filtering rules to its DOTS server. When the DOTS gateway receives the associated response from the DOTS server, it propagates the response back to the DOTS client. [Med] Please note that this text is mainly for single-homed GWs. How a requ= est is forked or how a server is selected to place a request are not covere= d here. Those considerations are discussed in draft-boucadair-dots-multihom= ing. where both "propagate" and "proxies" are used. If the request is propagat= ed to both Servers, but one server sends back a different response code, wh= at should be done? Do we just take the first valid server? - I think the answer is no, but what do we do? [Med] For client-domain GWs, this may make sense if, in addition, partial f= ailure is managed directly by the GW to fix some issues (e.g., fix a confli= ct that may prevent a request to be honoured by one of the servers). In suc= h case, the GW does not need to propagate an error to the client. What happens about synchronization of the alias/acl information (I know tha= t this is in one sense out of scope, but..) between all the final DOTs serv= ers if there are multiple servers - possibly across multiple DOTS mitigatio= n services(ISPs)? [Med] This is a yet to be defined behavior. Comments and inputs to draft-bo= ucadair-dots-multihoming are more than welcome. Regards Jon --_000_787AE7BB302AE849A7480A190F8B93300A0E30BCOPEXCLILMA3corp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Jon,

 

Please see inline.

 

Cheers,

Med

 

De : Dots [mailto:dots-bounces@ietf.= org] De la part de Jon Shallow
Envoy=E9 : vendredi 2 mars 2018 14:07
=C0 : dots@ietf.org
Objet : [Dots] Data Channel DOTS Gateways

 

Hi there,

 

I’m currently having an i= mplementation challenge when using a DOTS gateway in the data channel.=

 

If the DOTS Gateway knows about= 2 upstream DOTS servers (perhaps 2 different ISPs), what should be done wh= en an alias/acl update comes in from the original DOTS clients.  Shoul= d the request be forwarded on to both servers?

 

[Med] It depends. Please check https://tools.ietf.org/html/draft-boucadair-dots-multihoming-02 (the d= iscussion about PI/PA).

 

With the signal channel, I am c= urrently sending the mitigation request to the first defined server that is= “alive”.

 

[Med] Idem as above, sending a = request to a server which cannot act on a given resource is not helpful. Pl= ease refer to the multi-homing I-D.

 

The current text reads

 

3.  DOTS Data Channel: Des= ign Overview

Some paragraphs later

   If a DOTS gateway = is involved, the DOTS gateway verifies that the

   DOTS client is aut= horized to undertake a data channel action (e.g.,

   instantiate filter= ing rules).  If the DOTS client is authorized, it

   propagates the rul= es to the upstream DOTS server.  Likewise, the DOTS<= /p>

   server verifies th= at the DOTS gateway is authorized to relay data

   channel actions.&n= bsp; For example, to create or purge filters, a DOTS

   client sends its r= equest to its DOTS gateway.  The DOTS gateway

   validates the rule= s in the request and proxies the requests

   containing the fil= tering rules to its DOTS server.  When the DOTS

   gateway receives t= he associated response from the DOTS server, it

   propagates the res= ponse back to the DOTS client.

&nbs= p;

[Med] Please note that this tex= t is mainly for single-homed GWs. How a request is forked or how a server i= s selected to place a request are not covered here. Those considerations are discussed in <= span lang=3D"EN-GB" style=3D"font-size:10.0pt;font-family:"Courier New= ";color:black">draft-boucadair-dots-multihoming.

 

where both “propagateR= 21; and “proxies” are used.   If the request is propa= gated to both Servers, but one server sends back a different response code,= what should be done?

Do we just take the first valid= server?

- I think the answer is no, but= what do we do?

 

[Med] For client-domain GWs, th= is may make sense if, in addition, partial failure is managed directly by t= he GW to fix some issues (e.g., fix a conflict that may prevent a request to be honoured by one of the servers). In such case,= the GW does not need to propagate an error to the client.   &nbs= p;  

 

What happens about synchronizat= ion of the alias/acl information (I know that this is in one sense out of s= cope, but..) between all the final DOTs servers if there are multiple serve= rs – possibly across multiple DOTS mitigation services(ISPs)?

[Med] This is a yet to be defin= ed behavior. Comments and inputs to draft-boucadair-dots-multihoming are mo= re than welcome.

 

Regards

 

Jon

--_000_787AE7BB302AE849A7480A190F8B93300A0E30BCOPEXCLILMA3corp_-- From nobody Wed Mar 7 06:56: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 2BC1C1270A3 for ; Wed, 7 Mar 2018 06:56:58 -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 fq_KoD5gO2RW for ; Wed, 7 Mar 2018 06:56:56 -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 853331241FC for ; Wed, 7 Mar 2018 06:56:56 -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 w27Eut7m033320 for ; Wed, 7 Mar 2018 09:56:55 -0500 DKIM-Filter: OpenDKIM Filter v2.11.0 veto.sei.cmu.edu w27Eut7m033320 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cert.org; s=yc2bmwvrj62m; t=1520434615; bh=NHlVVEhiYNOQBQOnqnPV/Hfzt5mZFE4FBGJ7/RE/wq4=; h=From:To:Subject:Date:From; b=HNXKnb/NiLdrKqpMJ1wsXBkoEE0mqf9juYAGzclSffXEpCJo3eC+CZ8vOtpxDvCcf z5Ip/ca6wOfAjvrk8JS5oSAT7vQsxg3XRDg7aHu21nJWr6AANQmWnbTH58W6TiQrcp M2F+y57VjrqTkG5ye0v9imkS2zpx1iPrgN0C4Kh0= 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 w27EunNd001637 for ; Wed, 7 Mar 2018 09:56:49 -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; Wed, 7 Mar 2018 09:56:49 -0500 From: Roman Danyliw To: "dots@ietf.org" Thread-Topic: Reminder -- Call for agenda items for DOTS at IETF 101 Thread-Index: AdO2JG8eSMoLJSKKRP25F0zsAKkzYQ== Date: Wed, 7 Mar 2018 14:56:48 +0000 Message-ID: <359EC4B99E040048A7131E0F4E113AFC0137F71442@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 -- Call for agenda items for DOTS at IETF 101 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, 07 Mar 2018 14:56:58 -0000 Hello! If you'd like time on the agenda please send your request to the chairs. Roman -----Original Message----- From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Roman Danyliw Sent: Monday, February 26, 2018 1:59 PM To: dots@ietf.org Subject: [Dots] Call for agenda items for DOTS at IETF 101 Hello! DOTS has been scheduled at IETF 101 on Tuesday (March 20) at 1550-1820. If= you would like time on the agenda, send your request to the chairs. Regards, Roman and Tobias _______________________________________________ Dots mailing list Dots@ietf.org https://www.ietf.org/mailman/listinfo/dots From nobody Wed Mar 7 09:29:08 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 6C76D12D885 for ; Wed, 7 Mar 2018 09:29:06 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: X-Test-IDTracker: no X-IETF-IDTracker: 6.74.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152044374643.17621.16314772847218351445.idtracker@ietfa.amsl.com> Date: Wed, 07 Mar 2018 09:29:06 -0800 From: IETF Secretariat Archived-At: Subject: [Dots] Milestones changed for dots WG 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, 07 Mar 2018 17:29:06 -0000 Changed milestone "Requirements document to WGLC", set due date to December 2017 from July 2017. Changed milestone "Use case document to WGLC", set due date to March 2018 from July 2017. Changed milestone "Architecture document to WGLC", set due date to March 2018 from September 2017. Changed milestone "Signal channel document as proposed standard to WGLC", set due date to August 2018 from December 2017, added draft-ietf-dots-signal-channel to milestone. Changed milestone "Data channel document as proposed standard to WGLC", set due date to August 2018 from December 2017, added draft-ietf-dots-data-channel to milestone. URL: https://datatracker.ietf.org/wg/dots/about/ From nobody Thu Mar 8 01:03:23 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 5A67812426E for ; Thu, 8 Mar 2018 01:03:21 -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 kAr7Hy3r3M-a for ; Thu, 8 Mar 2018 01:03:19 -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 3FB921205F0 for ; Thu, 8 Mar 2018 01:03: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.90_1) (envelope-from ) id 1etrSG-000803-IC for ietf-supjps-dots@ietf.org; Thu, 08 Mar 2018 09:03:16 +0000 From: "Jon Shallow" To: Date: Thu, 8 Mar 2018 09:03:16 -0000 Message-ID: <02c601d3b6bc$4bcf2590$e36d70b0$@jpshallow.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_02C7_01D3B6BC.4BCF2590" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdO2vDgpziPgx8tcT0iIvzTD3rhHdw== Content-Language: en-gb Archived-At: Subject: [Dots] Signal Observe implementation issue 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, 08 Mar 2018 09:03:21 -0000 This is a multipart message in MIME format. ------=_NextPart_000_02C7_01D3B6BC.4BCF2590 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi there, We currently cannot support multiple Observe requests per client. A simple change fixes the issue. In the signal-17 draft, we have Header: GET (Code=0.01) Uri-Host: "host" Uri-Path: ".well-known" Uri-Path: "dots" Uri-Path: "v1" Uri-Path: "mitigate" Uri-Query: "cuid=dz6pHjaADkaFTbjr0JGBpw" Uri-Query: "mid=12332" Observe: 0 Figure 12: GET to Retrieve a Specific DOTS Mitigation Request Where the resource to Observe is a combination of the Uri-Path: and Uri-Query. RFC7252 supports have the 'request URI' as a combination of both, so this is legal. However, in the libcoap I am using, it only supports one Query per Token per Resource (the resource in this case being ".wellknown/dots/v1/mitigate") for Observe. The Token should remain constant as per RFC7252 5.3.1. Token .. The client SHOULD generate tokens in such a way that tokens currently in use for a given source/destination endpoint pair are unique and then RFC7641 4.1. Request .. The entry in the list of observers is keyed by the client endpoint and the token specified by the client in the request. If an entry with a matching endpoint/token pair is already present in the list (which, for example, happens when the client wishes to reinforce its interest in a resource), the server MUST NOT add a new entry but MUST replace or update the existing one. So, a subsequent different Query using the same Token is overwritten - the previous Observe is deleted and the new one invoked. The libcoap is correct in what it is doing. Can we therefore have this as (to support the monitoring of multiple mitigation requests per client) 4.4.2 . 'cuid' is a mandatory Uri-Path parameter for GET requests. Uri-Path parameters with empty values MUST NOT be present in a request. The same considerations for manipulating 'cdid' parameter by server- domain DOTS gateways specified in Section 4.4.1 MUST be followed for GET requests. If the DOTS server does not find the 'mid' Uri-Path value conveyed in the GET request in its configuration data for the requesting DOTS client, it MUST respond with a 4.04 (Not Found) error response code. Likewise, the same error MUST be returned as a response to a request to retrieve all mitigation records (i.e., 'mid' Uri-Path is not defined) of a given DOTS client if the DOTS server does not find any mitigation record for that DOTS client. As a reminder, a DOTS client is identified by its identity (e.g., client certificate, 'cuid') and optionally the 'cdid' . Header: GET (Code=0.01) Uri-Host: "host" Uri-Path: ".well-known" Uri-Path: "dots" Uri-Path: "v1" Uri-Path: "mitigate" Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw" Uri-Path: "mid=12332" Observe: 0 Figure 12: GET to Retrieve a Specific DOTS Mitigation Request And for consistency 4.4.4 . 'cuid' and 'mid' are mandatory Uri-Path parameters for DELETE requests. Header: DELETE (Code=0.04) Uri-Host: "host" Uri-Path: ".well-known" Uri-Path: "dots" Uri-Path: "v1" Uri-Path: "mitigate" Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw" Uri-Path: "mid=123" Figure 16: Withdraw a DOTS Mitigation 4.5.3 . Header: DELETE (Code=0.04) Uri-Host: "host" Uri-Path: ".well-known" Uri-Path: "dots" Uri-Path: "v1" Uri-Path: "config" Uri-Path: "sid=123" Figure 22: DELETE Configuration Regards Jon ------=_NextPart_000_02C7_01D3B6BC.4BCF2590 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi = there,

 

We currently cannot support multiple Observe requests = per client.  A simple change fixes the issue.

 

In the = signal-17 draft, we have

 

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

     Uri-Host: = "host"

     Uri-Path: = ".well-known"

     Uri-Path: = "dots"

     Uri-Path: = "v1"

     Uri-Path: = "mitigate"

     Uri-Query: = "cuid=3Ddz6pHjaADkaFTbjr0JGBpw"

     Uri-Query: = "mid=3D12332"

     Observe: 0

 

       Figure 12: GET to = Retrieve a Specific DOTS Mitigation Request

 

Where the = resource to Observe is a combination of the Uri-Path: and = Uri-Query.  RFC7252 supports have the ‘request URI’ as = a combination of both, so this is legal. 

 

However, in = the libcoap I am using, it only supports one Query per Token per = Resource (the resource in this case being = “.wellknown/dots/v1/mitigate”) for Observe.  The Token = should remain constant as per

 

RFC7252 = 5.3.1.  Token

..

   The = client SHOULD generate tokens in such a way that tokens = currently

   in use for a = given source/destination endpoint pair are unique

 

and = then

 

RFC7641 4.1.  Request

….

   The entry in the list of observers is = keyed by the client endpoint

   and the token specified by the client in = the request.  If an entry

   with a matching endpoint/token pair is = already present in the list

   (which, for example, happens when the = client wishes to reinforce its

   interest in a resource), the server MUST = NOT add a new entry but MUST

   replace or update the existing = one.

 

So, a subsequent different Query using the same Token = is overwritten – the previous Observe is deleted and the new one = invoked.  The libcoap is correct in what it is = doing.

 

Can we therefore have this as (to support the = monitoring of multiple mitigation requests per client)

 

4.4.2

…

  = 'cuid' is a mandatory Uri-Path = parameter for GET requests.

 

   = Uri-Path parameters with empty values MUST NOT be = present in a

   = request.

 

   The same considerations for manipulating = 'cdid' parameter by server-

   domain DOTS gateways specified in Section = 4.4.1 MUST be followed for

   GET requests.

 

   = If the DOTS server does not find the 'mid' Uri-Path = value conveyed

   in = the GET request in its configuration data for the requesting = DOTS

   client, it MUST = respond with a 4.04 (Not Found) error response code.

   Likewise, the same error MUST be returned = as a response to a request

   to retrieve all mitigation records (i.e., = 'mid' Uri-Path is not

   defined) of a given DOTS client if the = DOTS server does not find any

   mitigation record for that DOTS = client.  As a reminder, a DOTS client

   is identified by its identity (e.g., = client certificate, 'cuid') and

   optionally the 'cdid'

…

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

     Uri-Host: = "host"

     Uri-Path: = ".well-known"

     Uri-Path: = "dots"

     Uri-Path: = "v1"

     Uri-Path: = "mitigate"

     Uri-Path: = "cuid=3Ddz6pHjaADkaFTbjr0JGBpw"

     Uri-Path: = "mid=3D12332"

     Observe: 0

 

       Figure 12: GET to = Retrieve a Specific DOTS Mitigation Request

 

And for = consistency

 

4.4.4

…

   'cuid' and 'mid' are mandatory = Uri-Path parameters for = DELETE

   = requests.

 

     Header: DELETE = (Code=3D0.04)

     Uri-Host: = "host"

     Uri-Path: = ".well-known"

     Uri-Path: = "dots"

     Uri-Path: = "v1"

     Uri-Path: = "mitigate"

     Uri-Path: = "cuid=3Ddz6pHjaADkaFTbjr0JGBpw"

     Uri-Path: = "mid=3D123"

 

        =            Figure = 16: Withdraw a DOTS Mitigation

 

4.5.3

…

     Header: DELETE = (Code=3D0.04)

     Uri-Host: = "host"

     Uri-Path: = ".well-known"

     Uri-Path: = "dots"

     Uri-Path: = "v1"

     Uri-Path: = "config"

     Uri-Path: = "sid=3D123"

 

         &= nbsp;            = Figure 22: DELETE Configuration

 

Regards

 

Jon

------=_NextPart_000_02C7_01D3B6BC.4BCF2590-- From nobody Thu Mar 8 08:16: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 4BCB71270A3 for ; Thu, 8 Mar 2018 08:16:30 -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 NWpaCgRY6Qo3 for ; Thu, 8 Mar 2018 08:16: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 957241241FC for ; Thu, 8 Mar 2018 08:16: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.90_1) (envelope-from ) id 1etyDQ-0008Go-Ur; Thu, 08 Mar 2018 16:16:25 +0000 From: "Jon Shallow" To: "'Konda, Tirumaleswar Reddy'" , "Mortensen, Andrew" , References: <151802313846.4823.7164614843343039635@ietfa.amsl.com> <158A2A94-1165-4938-A675-C776DE7444CF@arbor.net> <2C2EA5A2-0A09-4ED0-BD2A-4A0F786ADEE9@arbor.net> In-Reply-To: Date: Thu, 8 Mar 2018 16:16:24 -0000 Message-ID: <039801d3b6f8$cdf22720$69d67560$@jpshallow.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0399_01D3B6F8.CDF49820" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHPwh9Q9Mf9ZoqId9W7yhJIp8wRGwEDLIKeAf2cglMC/CDa5wFMquJ+o5Qfo2A= Content-Language: en-gb Archived-At: Subject: Re: [Dots] Fwd: I-D Action: draft-ietf-dots-requirements-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: Thu, 08 Mar 2018 16:16:30 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0399_01D3B6F8.CDF49820 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi there, =20 To close the loop (as I raised the initial questions), GEN-004 and = GEN-005 give me (and the WG) the flexibility to add in additional = information to the signal/data specs should it be needed. =20 Regards =20 Jon =20 From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of Konda, = Tirumaleswar Reddy Sent: 08 February 2018 05:37 To: Mortensen, Andrew Cc: dots Subject: Re: [Dots] Fwd: I-D Action: draft-ietf-dots-requirements-13.txt =20 From: Mortensen, Andrew [mailto:amortensen@arbor.net]=20 Sent: Thursday, February 8, 2018 10:34 AM To: Konda, Tirumaleswar Reddy Cc: dots Subject: Re: [Dots] Fwd: I-D Action: draft-ietf-dots-requirements-13.txt =20 =20 On Feb 7, 2018, at 10:26 PM, Konda, Tirumaleswar Reddy = wrote: =20 1) GEN-005 Loop Handling: In specific scenarios, it may be possible for communication between DOTS agents to loop, for example as a result of misconfiguration or aggressive caching. =20 comment> The looping attack Jon discussed in the mailing list is because = of misconfiguration and DNS cache poisoning. What do you mean by "aggressive = caching=E2=80=9D ? =20 Sorry, I had meant to provide a specific example of misconfiguration, = and didn=E2=80=99t finish the thought. I=E2=80=99m skeptical of the DNS = cache poisoning example for the same reason you cited on the list. =20 Let=E2=80=99s remove =E2=80=9Caggressive caching=E2=80=9D. =20 =20 2) Mitigation hints MAY be transmitted across either signal or data = channel. =20 comment> I don't think the DOTS client will know the mitigation hints = during peace time to convey the hints in the data channel ! =20 I had in mind always-on mitigation. I wanted to leave open the = possibility that the DOTS client operators might provide hints to inform = the shape of that always-on mitigation. Since the conversation leading = to this requirement addition concluded with what seemed to be an = agreement that we wanted to create space for undefined forms of hinting, = it seemed reasonable to assume a DOTS operator could have some form of = threat intelligence which could be provided in such a scenario. =20 Got it, thanks. =20 Cheers, -Tiru =20 andrew =20 =20 =20 From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Mortensen, Andrew Sent: Wednesday, February 7, 2018 10:39 PM To: dots Subject: [Dots] Fwd: I-D Action: draft-ietf-dots-requirements-13.txt =20 Not wanting to lose momentum from today=E2=80=99s interim meeting, = I=E2=80=99ve updated the requirements draft to address the remaining = issues. Please take a close look at GEN-004 and -005, which add the = mitigation hinting and loop handling general requirements, respectively. = As discussed during today=E2=80=99s meeting, the bidirectionality = requirement (formerly GEN-003) has been moved under the signal channel = requirements as SIG-003. =20 andrew =20 =20 Begin forwarded message: =20 From: internet-drafts@ietf.org Subject: [Dots] I-D Action: draft-ietf-dots-requirements-13.txt Date: February 7, 2018 at 12:05:38 PM EST To: < i-d-announce@ietf.org> Cc: dots@ietf.org =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. Title : Distributed Denial of Service (DDoS) Open = Threat Signaling Requirements Authors : Andrew Mortensen Robert Moskowitz Tirumaleswar Reddy Filename : draft-ietf-dots-requirements-13.txt Pages : 20 Date : 2018-02-07 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 ------=_NextPart_000_0399_01D3B6F8.CDF49820 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Hi there,

 

To close the loop (as I raised the initial questions), GEN-004 and = GEN-005 give me (and the WG) the flexibility to add in additional = information to the signal/data specs should it be = needed.

 

Regards

 

Jon

 

From:= Dots = [mailto: dots-bounces@ietf.org] On Behalf Of Konda, Tirumaleswar = Reddy
Sent: 08 February 2018 05:37
To: Mortensen, = Andrew
Cc: dots
Subject: Re: [Dots] Fwd: I-D Action: = draft-ietf-dots-requirements-13.txt

 

From: = Mortensen, Andrew [mailto:amortensen@arbor.net] =
Sent: Thursday, February 8, 2018 10:34 AM
To: = Konda, Tirumaleswar Reddy <TirumaleswarReddy_Kond= a@McAfee.com>
Cc: dots <dots@ietf.org>
Subject: = Re: [Dots] Fwd: I-D Action: = draft-ietf-dots-requirements-13.txt

 

 

On Feb 7, 2018, at 10:26 PM, Konda, = Tirumaleswar Reddy <TirumaleswarReddy_Kond= a@McAfee.com> wrote:

 

1)

  = ;GEN-005  Loop Handling: In specific scenarios, it may be possible = for

  = ;    communication between DOTS agents to loop, for = example as a result

  = ;    of misconfiguration or aggressive = caching.

 

comment>= The looping attack Jon discussed in the mailing list is because of = misconfiguration

and DNS = cache poisoning. What do you mean by "aggressive caching=E2=80=9D = ?

 

Sorry, I had meant to provide a = specific example of misconfiguration, and didn=E2=80=99t finish the = thought. I=E2=80=99m skeptical of the DNS cache poisoning example for = the same reason you cited on the list.

 =

Let=E2=80=99= s remove =E2=80=9Caggressive caching=E2=80=9D. =  

 

 2)&nb= sp; Mitigation hints MAY be transmitted across either signal or data = channel.

 

comment>= I don't think the DOTS client will know the mitigation hints during = peace time to convey the hints in the data channel !

 

I had in mind always-on mitigation. = I wanted to leave open the possibility that the DOTS client operators = might provide hints to inform the shape of that always-on mitigation. = Since the conversation leading to this requirement addition concluded = with what seemed to be an agreement that we wanted to create space for = undefined forms of hinting, it seemed reasonable to assume a DOTS = operator could have some form of threat intelligence which could be = provided in such a scenario.

 =

Got it, = thanks.

 =

Cheers,

-Tiru<= /o:p>

 

andrew

 

 

 

From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Mortensen, = Andrew
Sent: Wednesday, February 7, 2018 = 10:39 PM
To: dots <dots@ietf.org>
Subject: [Dots] Fwd: I-D Action: = draft-ietf-dots-requirements-13.txt

 

Not wanting to lose momentum from = today=E2=80=99s interim meeting, I=E2=80=99ve updated the requirements = draft to address the remaining issues. Please take a close look at = GEN-004 and -005, which add the mitigation hinting and loop handling = general requirements, respectively. As discussed during today=E2=80=99s = meeting, the bidirectionality requirement (formerly GEN-003) has been = moved under the signal channel requirements as = SIG-003.

 

andrew

 

 

Begin forwarded = message:

 

Subject: [Dots] I-D = Action: draft-ietf-dots-requirements-13.txt

Date: February 7, 2018 at = 12:05:38 PM EST

 


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-13.txt
Pages =           : 20
Date =            : = 2018-02-07

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_0399_01D3B6F8.CDF49820-- From nobody Thu Mar 8 18:56: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 019E612025C for ; Thu, 8 Mar 2018 18:56: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 Baaeqj_WLuCf for ; Thu, 8 Mar 2018 18:56:15 -0800 (PST) Received: from guri.nttv6.jp (guri.nttv6.jp [IPv6:2402:c800:ff06:136::140]) by ietfa.amsl.com (Postfix) with ESMTP id 295351200E5 for ; Thu, 8 Mar 2018 18:56:15 -0800 (PST) Received: from z.nttv6.jp (z.nttv6.jp [192.168.8.15]) by guri.nttv6.jp (NTTv6MTA) with ESMTP id 6BF1025F691; Fri, 9 Mar 2018 11:56:13 +0900 (JST) Received: from [IPv6:::1] (fujiko.nttv6.jp [115.69.228.141]) by z.nttv6.jp (NTTv6MTA) with ESMTP id 10C5E763427; Fri, 9 Mar 2018 11:56:12 +0900 (JST) To: Jon Shallow , dots@ietf.org References: <02c601d3b6bc$4bcf2590$e36d70b0$@jpshallow.com> From: kaname nishizuka Message-ID: Date: Fri, 9 Mar 2018 11:56:12 +0900 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <02c601d3b6bc$4bcf2590$e36d70b0$@jpshallow.com> Content-Type: multipart/alternative; boundary="------------8DD0D5584117BAD7E165224F" Content-Language: en-US Archived-At: Subject: Re: [Dots] Signal Observe implementation issue 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, 09 Mar 2018 02:56:18 -0000 This is a multi-part message in MIME format. --------------8DD0D5584117BAD7E165224F Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Hi WG, This is a significant issue and I strongly support this proposal. thanks, Kaname On 2018/03/08 18:03, Jon Shallow wrote: > > Hi there, > > We currently cannot support multiple Observe requests per client.  A simple change fixes the issue. > > In the signal-17 draft, we have > >      Header: GET (Code=0.01) > >      Uri-Host: "host" > >      Uri-Path: ".well-known" > >      Uri-Path: "dots" > >      Uri-Path: "v1" > >      Uri-Path: "mitigate" > >      Uri-Query: "cuid=dz6pHjaADkaFTbjr0JGBpw" > >      Uri-Query: "mid=12332" > >      Observe: 0 > >        Figure 12: GET to Retrieve a Specific DOTS Mitigation Request > > Where the resource to Observe is a combination of the Uri-Path: and Uri-Query.  RFC7252 supports have the ‘request URI’ as a combination of both, so this is legal. > > However, in the libcoap I am using, it only supports one Query per Token per Resource (the resource in this case being “.wellknown/dots/v1/mitigate”) for Observe. The Token should remain constant as per > > RFC7252 5.3.1.  Token > > .. > >    The client SHOULD generate tokens in such a way that tokens currently > >    in use for a given source/destination endpoint pair are unique > > and then > > RFC7641 4.1.  Request > > …. > >    The entry in the list of observers is keyed by the client endpoint > >    and the token specified by the client in the request.  If an entry > >    with a matching endpoint/token pair is already present in the list > >    (which, for example, happens when the client wishes to reinforce its > >    interest in a resource), the server MUST NOT add a new entry but MUST > >    replace or update the existing one. > > So, a subsequent different Query using the same Token is overwritten – the previous Observe is deleted and the new one invoked.  The libcoap is correct in what it is doing. > > Can we therefore have this as (to support the monitoring of multiple mitigation requests per client) > > 4.4.2 > > … > >   'cuid' is a mandatory Uri-*Path*parameter for GET requests. > >    Uri-*Path*parameters with empty values MUST NOT be present in a > >    request. > >    The same considerations for manipulating 'cdid' parameter by server- > >    domain DOTS gateways specified in Section 4.4.1 MUST be followed for > >    GET requests. > >    If the DOTS server does not find the 'mid' Uri-*Path*value conveyed > >    in the GET request in its configuration data for the requesting DOTS > >    client, it MUST respond with a 4.04 (Not Found) error response code. > >    Likewise, the same error MUST be returned as a response to a request > >    to retrieve all mitigation records (i.e., 'mid' Uri-*Path*is not > >    defined) of a given DOTS client if the DOTS server does not find any > >    mitigation record for that DOTS client. As a reminder, a DOTS client > >    is identified by its identity (e.g., client certificate, 'cuid') and > >    optionally the 'cdid' > > … > >      Header: GET (Code=0.01) > >      Uri-Host: "host" > >      Uri-Path: ".well-known" > >      Uri-Path: "dots" > >      Uri-Path: "v1" > >      Uri-Path: "mitigate" > >      Uri-*Path*: "cuid=dz6pHjaADkaFTbjr0JGBpw" > >      Uri-*Path*: "mid=12332" > >      Observe: 0 > >        Figure 12: GET to Retrieve a Specific DOTS Mitigation Request > > And for consistency > > 4.4.4 > > … > >    'cuid' and 'mid' are mandatory Uri-*Path* parameters for DELETE > >    requests. > >      Header: DELETE (Code=0.04) > >      Uri-Host: "host" > >      Uri-Path: ".well-known" > >      Uri-Path: "dots" > >      Uri-Path: "v1" > >      Uri-Path: "mitigate" > >      Uri-*Path*: "cuid=dz6pHjaADkaFTbjr0JGBpw" > >      Uri-*Path*: "mid=123" > >                    Figure 16: Withdraw a DOTS Mitigation > > 4.5.3 > > … > >      Header: DELETE (Code=0.04) > >      Uri-Host: "host" > >      Uri-Path: ".well-known" > >      Uri-Path: "dots" > >      Uri-Path: "v1" > >      Uri-Path: "config" > >      Uri-*Path*: "sid=123" > >                       Figure 22: DELETE Configuration > > Regards > > Jon > > > > _______________________________________________ > Dots mailing list > Dots@ietf.org > https://www.ietf.org/mailman/listinfo/dots --------------8DD0D5584117BAD7E165224F Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit Hi WG,

This is a significant issue and I strongly support this proposal.

thanks,
Kaname


On 2018/03/08 18:03, Jon Shallow wrote:

Hi there,

 

We currently cannot support multiple Observe requests per client.  A simple change fixes the issue.

 

In the signal-17 draft, we have

 

     Header: GET (Code=0.01)

     Uri-Host: "host"

     Uri-Path: ".well-known"

     Uri-Path: "dots"

     Uri-Path: "v1"

     Uri-Path: "mitigate"

     Uri-Query: "cuid=dz6pHjaADkaFTbjr0JGBpw"

     Uri-Query: "mid=12332"

     Observe: 0

 

       Figure 12: GET to Retrieve a Specific DOTS Mitigation Request

 

Where the resource to Observe is a combination of the Uri-Path: and Uri-Query.  RFC7252 supports have the ‘request URI’ as a combination of both, so this is legal. 

 

However, in the libcoap I am using, it only supports one Query per Token per Resource (the resource in this case being “.wellknown/dots/v1/mitigate”) for Observe.  The Token should remain constant as per

 

RFC7252 5.3.1.  Token

..

   The client SHOULD generate tokens in such a way that tokens currently

   in use for a given source/destination endpoint pair are unique

 

and then

 

RFC7641 4.1.  Request

….

   The entry in the list of observers is keyed by the client endpoint

   and the token specified by the client in the request.  If an entry

   with a matching endpoint/token pair is already present in the list

   (which, for example, happens when the client wishes to reinforce its

   interest in a resource), the server MUST NOT add a new entry but MUST

   replace or update the existing one.

 

So, a subsequent different Query using the same Token is overwritten – the previous Observe is deleted and the new one invoked.  The libcoap is correct in what it is doing.

 

Can we therefore have this as (to support the monitoring of multiple mitigation requests per client)

 

4.4.2

…

  'cuid' is a mandatory Uri-Path parameter for GET requests.

 

   Uri-Path parameters with empty values MUST NOT be present in a

   request.

 

   The same considerations for manipulating 'cdid' parameter by server-

   domain DOTS gateways specified in Section 4.4.1 MUST be followed for

   GET requests.

 

   If the DOTS server does not find the 'mid' Uri-Path value conveyed

   in the GET request in its configuration data for the requesting DOTS

   client, it MUST respond with a 4.04 (Not Found) error response code.

   Likewise, the same error MUST be returned as a response to a request

   to retrieve all mitigation records (i.e., 'mid' Uri-Path is not

   defined) of a given DOTS client if the DOTS server does not find any

   mitigation record for that DOTS client.  As a reminder, a DOTS client

   is identified by its identity (e.g., client certificate, 'cuid') and

   optionally the 'cdid'

…

     Header: GET (Code=0.01)

     Uri-Host: "host"

     Uri-Path: ".well-known"

     Uri-Path: "dots"

     Uri-Path: "v1"

     Uri-Path: "mitigate"

     Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw"

     Uri-Path: "mid=12332"

     Observe: 0

 

       Figure 12: GET to Retrieve a Specific DOTS Mitigation Request

 

And for consistency

 

4.4.4

…

   'cuid' and 'mid' are mandatory Uri-Path parameters for DELETE

   requests.

 

     Header: DELETE (Code=0.04)

     Uri-Host: "host"

     Uri-Path: ".well-known"

     Uri-Path: "dots"

     Uri-Path: "v1"

     Uri-Path: "mitigate"

     Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw"

     Uri-Path: "mid=123"

 

                   Figure 16: Withdraw a DOTS Mitigation

 

4.5.3

…

     Header: DELETE (Code=0.04)

     Uri-Host: "host"

     Uri-Path: ".well-known"

     Uri-Path: "dots"

     Uri-Path: "v1"

     Uri-Path: "config"

     Uri-Path: "sid=123"

 

                      Figure 22: DELETE Configuration

 

Regards

 

Jon



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

--------------8DD0D5584117BAD7E165224F-- From nobody Thu Mar 8 20:18: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 C90EC126BFD for ; Thu, 8 Mar 2018 20:18:08 -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 2HneNhVNw-W2 for ; Thu, 8 Mar 2018 20:18:06 -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 295F9120227 for ; Thu, 8 Mar 2018 20:18:06 -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 w294GlIw029167; Thu, 8 Mar 2018 23:18:05 -0500 Received: from nam03-co1-obe.outbound.protection.outlook.com (mail-co1nam03lp0021.outbound.protection.outlook.com [216.32.181.21]) by mx0a-00196b01.pphosted.com with ESMTP id 2gk206hhpe-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Thu, 08 Mar 2018 23:18:05 -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=p9u4RRfpZDuNTK5299SyL8V0NDMkf4Zd9p8uKZnC6J4=; b=UBKmT0OJYbUtQGzuB1qNVQ71aF0nkhdL3fBXIDv+6eKc3KSz21d04nRPPZjrLUdpSn8p2rTrQwRqSGvJpUW2b91ZR2CGkKrt51qsi6O08XDvSLdEUZK48ME8PWmcR5zN4bQ0AdBC/pldEFFbXEgrt4CKid6Dxx3BqgPT2L2nNKc= Received: from SN2PR01MB2063.prod.exchangelabs.com (10.166.208.138) by SN2PR01MB1965.prod.exchangelabs.com (10.166.208.6) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.548.13; Fri, 9 Mar 2018 04:18:03 +0000 Received: from SN2PR01MB2063.prod.exchangelabs.com ([fe80::a4ce:8607:3de7:7e9]) by SN2PR01MB2063.prod.exchangelabs.com ([fe80::a4ce:8607:3de7:7e9%17]) with mapi id 15.20.0548.018; Fri, 9 Mar 2018 04:18:02 +0000 From: "Mortensen, Andrew" To: kaname nishizuka CC: Jon Shallow , "dots@ietf.org" Thread-Topic: [Dots] Signal Observe implementation issue Thread-Index: AdO2vDgpziPgx8tcT0iIvzTD3rhHdwAlfZgAAALbgIA= Date: Fri, 9 Mar 2018 04:18:02 +0000 Message-ID: <53222336-0F10-4425-ACB0-47D9E1B201C0@arbor.net> References: <02c601d3b6bc$4bcf2590$e36d70b0$@jpshallow.com> In-Reply-To: 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; SN2PR01MB1965; 7:dhkZHLjhL9vDD4Jibua3iUiTeR37tVQhqbJlbofpi5/rZo7QjyuVgu6OoL2mb9ZPFN1gS+bDSrgnZ6CyniwDVlTwCj00bk61SSxogesmlGsf7ZiETG2kkXnjYg/FTnPYwSMNM34ngldZphfEp6cCde8IQbEbJQkQS8jR2mfsMyVnUENAe4CA4JpmKCn9Sz2x7lEHE6WnnDifwtr50eNbfkaoS7Zyh6+OUcAOKN9SGcpu6UpAoUmXPvnrC1Hc13C5 x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 9ff02218-cc9b-4ea9-693b-08d58574c021 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(4604075)(3008032)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7153060)(7193020); SRVR:SN2PR01MB1965; x-ms-traffictypediagnostic: SN2PR01MB1965: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(190756311086443)(158342451672863)(72170088055959)(788757137089); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040522)(2401047)(8121501046)(5005006)(10201501046)(3002001)(3231220)(944501244)(52105095)(93006095)(93001095)(6041310)(20161123562045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(20161123564045)(20161123558120)(6072148)(201708071742011); SRVR:SN2PR01MB1965; BCL:0; PCL:0; RULEID:; SRVR:SN2PR01MB1965; x-forefront-prvs: 0606BBEB39 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(376002)(346002)(39380400002)(39860400002)(366004)(396003)(199004)(189003)(236005)(6506007)(68736007)(966005)(186003)(53936002)(575784001)(6512007)(54896002)(6306002)(8676002)(33656002)(229853002)(2900100001)(81156014)(8936002)(14454004)(53546011)(6916009)(316002)(3660700001)(26005)(97736004)(6246003)(81166006)(5660300001)(59450400001)(6486002)(105586002)(83716003)(102836004)(6436002)(5250100002)(7736002)(2950100002)(86362001)(606006)(106356001)(76176011)(99286004)(25786009)(54906003)(82746002)(4326008)(66066001)(561944003)(3846002)(6116002)(2906002)(478600001)(3280700002)(36756003); DIR:OUT; SFP:1102; SCL:1; SRVR:SN2PR01MB1965; H:SN2PR01MB2063.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: 4vw/Hh75IZtlrHc/UnF7huvEYDzYbj/rXmDrwUnhwv2oanIIjwQghE4T7QLa9gEl1+yriPciQgfSPNJRhtPFFtL1kZyecZAQ/hvewLgtKp+GWgR/wAGDLH51K7ZWLLKsGWYU4/zoa43vyrfPa3OZTCSKKnwo02Zq7RgwxJTpcBNzHjjBKtLeemZkj2intx21TrfC9d1EmcMY530xG/OlVT9g3ZszMQoFjsnEzRlo0b3d5RHzA5sw5ZaXwZpk0FSyS/V+jbHLL0oh7kdeiKZdmSrpNtvOPGt88CE7ZIERCVZ1y9woMIwLww2j40aA6aC7KYBMldft9xl/12lRC8FClQ== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_532223360F104425ACB047D9E1B201C0arbornet_" MIME-Version: 1.0 X-OriginatorOrg: arbor.net X-MS-Exchange-CrossTenant-Network-Message-Id: 9ff02218-cc9b-4ea9-693b-08d58574c021 X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Mar 2018 04:18:02.7502 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 54f11205-d4aa-4809-bd36-0b542199c5b2 X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN2PR01MB1965 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-03-09_02:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1803090054 Archived-At: Subject: Re: [Dots] Signal Observe implementation issue 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, 09 Mar 2018 04:18:09 -0000 --_000_532223360F104425ACB047D9E1B201C0arbornet_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQpPbiBNYXIgOCwgMjAxOCwgYXQgOTo1NiBQTSwga2FuYW1lIG5pc2hpenVrYSA8a2FuYW1lQG50 dHY2LmpwPG1haWx0bzprYW5hbWVAbnR0djYuanA+PiB3cm90ZToNCg0KSGkgV0csDQoNClRoaXMg aXMgYSBzaWduaWZpY2FudCBpc3N1ZSBhbmQgSSBzdHJvbmdseSBzdXBwb3J0IHRoaXMgcHJvcG9z YWwuDQoNCisxDQoNCmFuZHJldw0KDQoNCg0KDQoNCk9uIDIwMTgvMDMvMDggMTg6MDMsIEpvbiBT aGFsbG93IHdyb3RlOg0KSGkgdGhlcmUsDQoNCldlIGN1cnJlbnRseSBjYW5ub3Qgc3VwcG9ydCBt dWx0aXBsZSBPYnNlcnZlIHJlcXVlc3RzIHBlciBjbGllbnQuICBBIHNpbXBsZSBjaGFuZ2UgZml4 ZXMgdGhlIGlzc3VlLg0KDQpJbiB0aGUgc2lnbmFsLTE3IGRyYWZ0LCB3ZSBoYXZlDQoNCiAgICAg SGVhZGVyOiBHRVQgKENvZGU9MC4wMSkNCiAgICAgVXJpLUhvc3Q6ICJob3N0Ig0KICAgICBVcmkt UGF0aDogIi53ZWxsLWtub3duIg0KICAgICBVcmktUGF0aDogImRvdHMiDQogICAgIFVyaS1QYXRo OiAidjEiDQogICAgIFVyaS1QYXRoOiAibWl0aWdhdGUiDQogICAgIFVyaS1RdWVyeTogImN1aWQ9 ZHo2cEhqYUFEa2FGVGJqcjBKR0JwdyINCiAgICAgVXJpLVF1ZXJ5OiAibWlkPTEyMzMyIg0KICAg ICBPYnNlcnZlOiAwDQoNCiAgICAgICBGaWd1cmUgMTI6IEdFVCB0byBSZXRyaWV2ZSBhIFNwZWNp ZmljIERPVFMgTWl0aWdhdGlvbiBSZXF1ZXN0DQoNCldoZXJlIHRoZSByZXNvdXJjZSB0byBPYnNl cnZlIGlzIGEgY29tYmluYXRpb24gb2YgdGhlIFVyaS1QYXRoOiBhbmQgVXJpLVF1ZXJ5LiAgUkZD NzI1MiBzdXBwb3J0cyBoYXZlIHRoZSDigJhyZXF1ZXN0IFVSSeKAmSBhcyBhIGNvbWJpbmF0aW9u IG9mIGJvdGgsIHNvIHRoaXMgaXMgbGVnYWwuDQoNCkhvd2V2ZXIsIGluIHRoZSBsaWJjb2FwIEkg YW0gdXNpbmcsIGl0IG9ubHkgc3VwcG9ydHMgb25lIFF1ZXJ5IHBlciBUb2tlbiBwZXIgUmVzb3Vy Y2UgKHRoZSByZXNvdXJjZSBpbiB0aGlzIGNhc2UgYmVpbmcg4oCcLndlbGxrbm93bi9kb3RzL3Yx L21pdGlnYXRl4oCdKSBmb3IgT2JzZXJ2ZS4gIFRoZSBUb2tlbiBzaG91bGQgcmVtYWluIGNvbnN0 YW50IGFzIHBlcg0KDQpSRkM3MjUyIDUuMy4xLiAgVG9rZW4NCi4uDQogICBUaGUgY2xpZW50IFNI T1VMRCBnZW5lcmF0ZSB0b2tlbnMgaW4gc3VjaCBhIHdheSB0aGF0IHRva2VucyBjdXJyZW50bHkN CiAgIGluIHVzZSBmb3IgYSBnaXZlbiBzb3VyY2UvZGVzdGluYXRpb24gZW5kcG9pbnQgcGFpciBh cmUgdW5pcXVlDQoNCmFuZCB0aGVuDQoNClJGQzc2NDEgNC4xLiAgUmVxdWVzdA0K4oCmLg0KICAg VGhlIGVudHJ5IGluIHRoZSBsaXN0IG9mIG9ic2VydmVycyBpcyBrZXllZCBieSB0aGUgY2xpZW50 IGVuZHBvaW50DQogICBhbmQgdGhlIHRva2VuIHNwZWNpZmllZCBieSB0aGUgY2xpZW50IGluIHRo ZSByZXF1ZXN0LiAgSWYgYW4gZW50cnkNCiAgIHdpdGggYSBtYXRjaGluZyBlbmRwb2ludC90b2tl biBwYWlyIGlzIGFscmVhZHkgcHJlc2VudCBpbiB0aGUgbGlzdA0KICAgKHdoaWNoLCBmb3IgZXhh bXBsZSwgaGFwcGVucyB3aGVuIHRoZSBjbGllbnQgd2lzaGVzIHRvIHJlaW5mb3JjZSBpdHMNCiAg IGludGVyZXN0IGluIGEgcmVzb3VyY2UpLCB0aGUgc2VydmVyIE1VU1QgTk9UIGFkZCBhIG5ldyBl bnRyeSBidXQgTVVTVA0KICAgcmVwbGFjZSBvciB1cGRhdGUgdGhlIGV4aXN0aW5nIG9uZS4NCg0K U28sIGEgc3Vic2VxdWVudCBkaWZmZXJlbnQgUXVlcnkgdXNpbmcgdGhlIHNhbWUgVG9rZW4gaXMg b3ZlcndyaXR0ZW4g4oCTIHRoZSBwcmV2aW91cyBPYnNlcnZlIGlzIGRlbGV0ZWQgYW5kIHRoZSBu ZXcgb25lIGludm9rZWQuICBUaGUgbGliY29hcCBpcyBjb3JyZWN0IGluIHdoYXQgaXQgaXMgZG9p bmcuDQoNCkNhbiB3ZSB0aGVyZWZvcmUgaGF2ZSB0aGlzIGFzICh0byBzdXBwb3J0IHRoZSBtb25p dG9yaW5nIG9mIG11bHRpcGxlIG1pdGlnYXRpb24gcmVxdWVzdHMgcGVyIGNsaWVudCkNCg0KNC40 LjINCuKApg0KICAnY3VpZCcgaXMgYSBtYW5kYXRvcnkgVXJpLVBhdGggcGFyYW1ldGVyIGZvciBH RVQgcmVxdWVzdHMuDQoNCiAgIFVyaS1QYXRoIHBhcmFtZXRlcnMgd2l0aCBlbXB0eSB2YWx1ZXMg TVVTVCBOT1QgYmUgcHJlc2VudCBpbiBhDQogICByZXF1ZXN0Lg0KDQogICBUaGUgc2FtZSBjb25z aWRlcmF0aW9ucyBmb3IgbWFuaXB1bGF0aW5nICdjZGlkJyBwYXJhbWV0ZXIgYnkgc2VydmVyLQ0K ICAgZG9tYWluIERPVFMgZ2F0ZXdheXMgc3BlY2lmaWVkIGluIFNlY3Rpb24gNC40LjEgTVVTVCBi ZSBmb2xsb3dlZCBmb3INCiAgIEdFVCByZXF1ZXN0cy4NCg0KICAgSWYgdGhlIERPVFMgc2VydmVy IGRvZXMgbm90IGZpbmQgdGhlICdtaWQnIFVyaS1QYXRoIHZhbHVlIGNvbnZleWVkDQogICBpbiB0 aGUgR0VUIHJlcXVlc3QgaW4gaXRzIGNvbmZpZ3VyYXRpb24gZGF0YSBmb3IgdGhlIHJlcXVlc3Rp bmcgRE9UUw0KICAgY2xpZW50LCBpdCBNVVNUIHJlc3BvbmQgd2l0aCBhIDQuMDQgKE5vdCBGb3Vu ZCkgZXJyb3IgcmVzcG9uc2UgY29kZS4NCiAgIExpa2V3aXNlLCB0aGUgc2FtZSBlcnJvciBNVVNU IGJlIHJldHVybmVkIGFzIGEgcmVzcG9uc2UgdG8gYSByZXF1ZXN0DQogICB0byByZXRyaWV2ZSBh bGwgbWl0aWdhdGlvbiByZWNvcmRzIChpLmUuLCAnbWlkJyBVcmktUGF0aCBpcyBub3QNCiAgIGRl ZmluZWQpIG9mIGEgZ2l2ZW4gRE9UUyBjbGllbnQgaWYgdGhlIERPVFMgc2VydmVyIGRvZXMgbm90 IGZpbmQgYW55DQogICBtaXRpZ2F0aW9uIHJlY29yZCBmb3IgdGhhdCBET1RTIGNsaWVudC4gIEFz IGEgcmVtaW5kZXIsIGEgRE9UUyBjbGllbnQNCiAgIGlzIGlkZW50aWZpZWQgYnkgaXRzIGlkZW50 aXR5IChlLmcuLCBjbGllbnQgY2VydGlmaWNhdGUsICdjdWlkJykgYW5kDQogICBvcHRpb25hbGx5 IHRoZSAnY2RpZCcNCuKApg0KICAgICBIZWFkZXI6IEdFVCAoQ29kZT0wLjAxKQ0KICAgICBVcmkt SG9zdDogImhvc3QiDQogICAgIFVyaS1QYXRoOiAiLndlbGwta25vd24iDQogICAgIFVyaS1QYXRo OiAiZG90cyINCiAgICAgVXJpLVBhdGg6ICJ2MSINCiAgICAgVXJpLVBhdGg6ICJtaXRpZ2F0ZSIN CiAgICAgVXJpLVBhdGg6ICJjdWlkPWR6NnBIamFBRGthRlRianIwSkdCcHciDQogICAgIFVyaS1Q YXRoOiAibWlkPTEyMzMyIg0KICAgICBPYnNlcnZlOiAwDQoNCiAgICAgICBGaWd1cmUgMTI6IEdF VCB0byBSZXRyaWV2ZSBhIFNwZWNpZmljIERPVFMgTWl0aWdhdGlvbiBSZXF1ZXN0DQoNCkFuZCBm b3IgY29uc2lzdGVuY3kNCg0KNC40LjQNCuKApg0KICAgJ2N1aWQnIGFuZCAnbWlkJyBhcmUgbWFu ZGF0b3J5IFVyaS1QYXRoIHBhcmFtZXRlcnMgZm9yIERFTEVURQ0KICAgcmVxdWVzdHMuDQoNCiAg ICAgSGVhZGVyOiBERUxFVEUgKENvZGU9MC4wNCkNCiAgICAgVXJpLUhvc3Q6ICJob3N0Ig0KICAg ICBVcmktUGF0aDogIi53ZWxsLWtub3duIg0KICAgICBVcmktUGF0aDogImRvdHMiDQogICAgIFVy aS1QYXRoOiAidjEiDQogICAgIFVyaS1QYXRoOiAibWl0aWdhdGUiDQogICAgIFVyaS1QYXRoOiAi Y3VpZD1kejZwSGphQURrYUZUYmpyMEpHQnB3Ig0KICAgICBVcmktUGF0aDogIm1pZD0xMjMiDQoN CiAgICAgICAgICAgICAgICAgICBGaWd1cmUgMTY6IFdpdGhkcmF3IGEgRE9UUyBNaXRpZ2F0aW9u DQoNCjQuNS4zDQrigKYNCiAgICAgSGVhZGVyOiBERUxFVEUgKENvZGU9MC4wNCkNCiAgICAgVXJp LUhvc3Q6ICJob3N0Ig0KICAgICBVcmktUGF0aDogIi53ZWxsLWtub3duIg0KICAgICBVcmktUGF0 aDogImRvdHMiDQogICAgIFVyaS1QYXRoOiAidjEiDQogICAgIFVyaS1QYXRoOiAiY29uZmlnIg0K ICAgICBVcmktUGF0aDogInNpZD0xMjMiDQoNCiAgICAgICAgICAgICAgICAgICAgICBGaWd1cmUg MjI6IERFTEVURSBDb25maWd1cmF0aW9uDQoNClJlZ2FyZHMNCg0KSm9uDQoNCg0KDQpfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KRG90cyBtYWlsaW5nIGxp c3QNCkRvdHNAaWV0Zi5vcmc8bWFpbHRvOkRvdHNAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RvdHMNCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXw0KRG90cyBtYWlsaW5nIGxpc3QNCkRvdHNAaWV0Zi5vcmc8 bWFpbHRvOkRvdHNAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL2RvdHMNCg0K --_000_532223360F104425ACB047D9E1B201C0arbornet_ Content-Type: text/html; charset="utf-8" Content-ID: <019D47C43D3E3945BEB0F390372BA202@prod.exchangelabs.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KPGRpdj4N CjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj5PbiBNYXIg OCwgMjAxOCwgYXQgOTo1NiBQTSwga2FuYW1lIG5pc2hpenVrYSAmbHQ7PGEgaHJlZj0ibWFpbHRv OmthbmFtZUBudHR2Ni5qcCIgY2xhc3M9IiI+a2FuYW1lQG50dHY2LmpwPC9hPiZndDsgd3JvdGU6 PC9kaXY+DQo8YnIgY2xhc3M9IkFwcGxlLWludGVyY2hhbmdlLW5ld2xpbmUiPg0KPGRpdiBjbGFz cz0iIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4 OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7IGZvbnQtd2Vp Z2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IHRleHQtYWxpZ246IHN0YXJ0OyB0 ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1h bDsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsgYmFj a2dyb3VuZC1jb2xvcjogcmdiKDI1NSwgMjU1LCAyNTUpOyBmbG9hdDogbm9uZTsgZGlzcGxheTog aW5saW5lICFpbXBvcnRhbnQ7IiBjbGFzcz0iIj5IaQ0KIFdHLDwvc3Bhbj48YnIgc3R5bGU9ImZv bnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFs OyBmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXIt c3BhY2luZzogbm9ybWFsOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4 dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdvcmQtc3BhY2luZzogMHB4 OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IGJhY2tncm91bmQtY29sb3I6IHJnYigy NTUsIDI1NSwgMjU1KTsiIGNsYXNzPSIiPg0KPGJyIHN0eWxlPSJmb250LWZhbWlseTogSGVsdmV0 aWNhOyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWNh cHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsg dGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25l OyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0 cm9rZS13aWR0aDogMHB4OyBiYWNrZ3JvdW5kLWNvbG9yOiByZ2IoMjU1LCAyNTUsIDI1NSk7IiBj bGFzcz0iIj4NCjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6 IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9u dC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgdGV4dC1hbGlnbjogc3Rh cnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTog bm9ybWFsOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4 OyBiYWNrZ3JvdW5kLWNvbG9yOiByZ2IoMjU1LCAyNTUsIDI1NSk7IGZsb2F0OiBub25lOyBkaXNw bGF5OiBpbmxpbmUgIWltcG9ydGFudDsiIGNsYXNzPSIiPlRoaXMNCiBpcyBhIHNpZ25pZmljYW50 IGlzc3VlIGFuZCBJIHN0cm9uZ2x5IHN1cHBvcnQgdGhpcyBwcm9wb3NhbC48L3NwYW4+PGJyIHN0 eWxlPSJmb250LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6 IG5vcm1hbDsgZm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsg bGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAw cHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3b3JkLXNwYWNp bmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyBiYWNrZ3JvdW5kLWNvbG9y OiByZ2IoMjU1LCAyNTUsIDI1NSk7IiBjbGFzcz0iIj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0K PGRpdj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXY+JiM0MzsxPC9kaXY+DQo8ZGl2PjxiciBj bGFzcz0iIj4NCjwvZGl2Pg0KPGRpdj5hbmRyZXc8L2Rpdj4NCjxkaXY+PGJyIGNsYXNzPSIiPg0K PC9kaXY+DQo8ZGl2PjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdj48YnIgY2xhc3M9IiI+DQo8 L2Rpdj4NCjxiciBjbGFzcz0iIj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIiPg0K PGRpdiBjbGFzcz0iIj48YnIgc3R5bGU9ImZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6 ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsOyBm b250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyB0ZXh0LWFsaWduOiBz dGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNl OiBub3JtYWw7IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAw cHg7IGJhY2tncm91bmQtY29sb3I6IHJnYigyNTUsIDI1NSwgMjU1KTsiIGNsYXNzPSIiPg0KPGRp diBjbGFzcz0ibW96LWNpdGUtcHJlZml4IiBzdHlsZT0iZm9udC1mYW1pbHk6IEhlbHZldGljYTsg Zm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudC1jYXBzOiBu b3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IHRleHQt YWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hp dGUtc3BhY2U6IG5vcm1hbDsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Ut d2lkdGg6IDBweDsgYmFja2dyb3VuZC1jb2xvcjogcmdiKDI1NSwgMjU1LCAyNTUpOyI+DQpPbiAy MDE4LzAzLzA4IDE4OjAzLCBKb24gU2hhbGxvdyB3cm90ZTo8YnIgY2xhc3M9IiI+DQo8L2Rpdj4N CjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNpdGU9Im1pZDowMmM2MDFkM2I2YmMkNGJjZjI1OTAk ZTM2ZDcwYjAkQGpwc2hhbGxvdy5jb20iIHN0eWxlPSJmb250LWZhbWlseTogSGVsdmV0aWNhOyBm b250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWNhcHM6IG5v cm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgb3JwaGFu czogYXV0bzsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNm b3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3aWRvd3M6IGF1dG87IHdvcmQtc3BhY2lu ZzogMHB4OyAtd2Via2l0LXRleHQtc2l6ZS1hZGp1c3Q6IGF1dG87IC13ZWJraXQtdGV4dC1zdHJv a2Utd2lkdGg6IDBweDsgYmFja2dyb3VuZC1jb2xvcjogcmdiKDI1NSwgMjU1LCAyNTUpOyIgY2xh c3M9IiI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiIHN0eWxlPSJwYWdlOiBXb3JkU2VjdGlv bjE7Ij4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGNtIDBjbSAwLjAwMDFwdDsgZm9udC1zaXplOiAx MXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiIGNsYXNzPSIiPg0KSGkgdGhl cmUsPG86cCBjbGFzcz0iIj48L286cD48L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGNtIDBj bSAwLjAwMDFwdDsgZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1z ZXJpZjsiIGNsYXNzPSIiPg0KPG86cCBjbGFzcz0iIj4mbmJzcDs8L286cD48L2Rpdj4NCjxkaXYg c3R5bGU9Im1hcmdpbjogMGNtIDBjbSAwLjAwMDFwdDsgZm9udC1zaXplOiAxMXB0OyBmb250LWZh bWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiIGNsYXNzPSIiPg0KV2UgY3VycmVudGx5IGNhbm5v dCBzdXBwb3J0IG11bHRpcGxlIE9ic2VydmUgcmVxdWVzdHMgcGVyIGNsaWVudC4mbmJzcDsgQSBz aW1wbGUgY2hhbmdlIGZpeGVzIHRoZSBpc3N1ZS48bzpwIGNsYXNzPSIiPjwvbzpwPjwvZGl2Pg0K PGRpdiBzdHlsZT0ibWFyZ2luOiAwY20gMGNtIDAuMDAwMXB0OyBmb250LXNpemU6IDExcHQ7IGZv bnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyIgY2xhc3M9IiI+DQo8bzpwIGNsYXNzPSIi PiZuYnNwOzwvbzpwPjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwY20gMGNtIDAuMDAwMXB0 OyBmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyIgY2xh c3M9IiI+DQpJbiB0aGUgc2lnbmFsLTE3IGRyYWZ0LCB3ZSBoYXZlPHNwYW4gY2xhc3M9IkFwcGxl LWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxvOnAgY2xhc3M9IiI+PC9vOnA+PC9kaXY+ DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBjbSAwY20gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTFwdDsg Zm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IiBjbGFzcz0iIj4NCjxvOnAgY2xhc3M9 IiI+Jm5ic3A7PC9vOnA+PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBjbSAwY20gMC4wMDAx cHQ7IGZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IiBj bGFzcz0iIj4NCiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBIZWFkZXI6IEdFVCAoQ29kZT0wLjAx KTxvOnAgY2xhc3M9IiI+PC9vOnA+PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBjbSAwY20g MC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2Vy aWY7IiBjbGFzcz0iIj4NCiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBVcmktSG9zdDogJnF1b3Q7 aG9zdCZxdW90OzxvOnAgY2xhc3M9IiI+PC9vOnA+PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46 IDBjbSAwY20gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmks IHNhbnMtc2VyaWY7IiBjbGFzcz0iIj4NCiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBVcmktUGF0 aDogJnF1b3Q7LndlbGwta25vd24mcXVvdDs8bzpwIGNsYXNzPSIiPjwvbzpwPjwvZGl2Pg0KPGRp diBzdHlsZT0ibWFyZ2luOiAwY20gMGNtIDAuMDAwMXB0OyBmb250LXNpemU6IDExcHQ7IGZvbnQt ZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyIgY2xhc3M9IiI+DQombmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgVXJpLVBhdGg6ICZxdW90O2RvdHMmcXVvdDs8bzpwIGNsYXNzPSIiPjwvbzpwPjwv ZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwY20gMGNtIDAuMDAwMXB0OyBmb250LXNpemU6IDEx cHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyIgY2xhc3M9IiI+DQombmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgVXJpLVBhdGg6ICZxdW90O3YxJnF1b3Q7PG86cCBjbGFzcz0iIj48 L286cD48L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGNtIDBjbSAwLjAwMDFwdDsgZm9udC1z aXplOiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiIGNsYXNzPSIiPg0K Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFVyaS1QYXRoOiAmcXVvdDttaXRpZ2F0ZSZxdW90Ozxv OnAgY2xhc3M9IiI+PC9vOnA+PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBjbSAwY20gMC4w MDAxcHQ7IGZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7 IiBjbGFzcz0iIj4NCiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBVcmktUXVlcnk6ICZxdW90O2N1 aWQ9ZHo2cEhqYUFEa2FGVGJqcjBKR0JwdyZxdW90OzxvOnAgY2xhc3M9IiI+PC9vOnA+PC9kaXY+ DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBjbSAwY20gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTFwdDsg Zm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IiBjbGFzcz0iIj4NCiZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyBVcmktUXVlcnk6ICZxdW90O21pZD0xMjMzMiZxdW90OzxvOnAgY2xhc3M9 IiI+PC9vOnA+PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBjbSAwY20gMC4wMDAxcHQ7IGZv bnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IiBjbGFzcz0i Ij4NCiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBPYnNlcnZlOiAwPG86cCBjbGFzcz0iIj48L286 cD48L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGNtIDBjbSAwLjAwMDFwdDsgZm9udC1zaXpl OiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiIGNsYXNzPSIiPg0KPG86 cCBjbGFzcz0iIj4mbmJzcDs8L286cD48L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGNtIDBj bSAwLjAwMDFwdDsgZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1z ZXJpZjsiIGNsYXNzPSIiPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IEZp Z3VyZSAxMjogR0VUIHRvIFJldHJpZXZlIGEgU3BlY2lmaWMgRE9UUyBNaXRpZ2F0aW9uIFJlcXVl c3Q8bzpwIGNsYXNzPSIiPjwvbzpwPjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwY20gMGNt IDAuMDAwMXB0OyBmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNl cmlmOyIgY2xhc3M9IiI+DQo8bzpwIGNsYXNzPSIiPiZuYnNwOzwvbzpwPjwvZGl2Pg0KPGRpdiBz dHlsZT0ibWFyZ2luOiAwY20gMGNtIDAuMDAwMXB0OyBmb250LXNpemU6IDExcHQ7IGZvbnQtZmFt aWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyIgY2xhc3M9IiI+DQpXaGVyZSB0aGUgcmVzb3VyY2Ug dG8gT2JzZXJ2ZSBpcyBhIGNvbWJpbmF0aW9uIG9mIHRoZSBVcmktUGF0aDogYW5kIFVyaS1RdWVy eS4mbmJzcDsgUkZDNzI1MiBzdXBwb3J0cyBoYXZlIHRoZSDigJhyZXF1ZXN0IFVSSeKAmSBhcyBh IGNvbWJpbmF0aW9uIG9mIGJvdGgsIHNvIHRoaXMgaXMgbGVnYWwuJm5ic3A7PHNwYW4gY2xhc3M9 IkFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxvOnAgY2xhc3M9IiI+PC9vOnA+ PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBjbSAwY20gMC4wMDAxcHQ7IGZvbnQtc2l6ZTog MTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IiBjbGFzcz0iIj4NCjxvOnAg Y2xhc3M9IiI+Jm5ic3A7PC9vOnA+PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBjbSAwY20g MC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2Vy aWY7IiBjbGFzcz0iIj4NCkhvd2V2ZXIsIGluIHRoZSBsaWJjb2FwIEkgYW0gdXNpbmcsIGl0IG9u bHkgc3VwcG9ydHMgb25lIFF1ZXJ5IHBlciBUb2tlbiBwZXIgUmVzb3VyY2UgKHRoZSByZXNvdXJj ZSBpbiB0aGlzIGNhc2UgYmVpbmcg4oCcLndlbGxrbm93bi9kb3RzL3YxL21pdGlnYXRl4oCdKSBm b3IgT2JzZXJ2ZS4mbmJzcDsgVGhlIFRva2VuIHNob3VsZCByZW1haW4gY29uc3RhbnQgYXMgcGVy PHNwYW4gY2xhc3M9IkFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxvOnAgY2xh c3M9IiI+PC9vOnA+PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBjbSAwY20gMC4wMDAxcHQ7 IGZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IiBjbGFz cz0iIj4NCjxvOnAgY2xhc3M9IiI+Jm5ic3A7PC9vOnA+PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJn aW46IDBjbSAwY20gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGli cmksIHNhbnMtc2VyaWY7IiBjbGFzcz0iIj4NClJGQzcyNTIgNS4zLjEuJm5ic3A7IFRva2VuPG86 cCBjbGFzcz0iIj48L286cD48L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGNtIDBjbSAwLjAw MDFwdDsgZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsi IGNsYXNzPSIiPg0KLi48bzpwIGNsYXNzPSIiPjwvbzpwPjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFy Z2luOiAwY20gMGNtIDAuMDAwMXB0OyBmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxp YnJpLCBzYW5zLXNlcmlmOyIgY2xhc3M9IiI+DQombmJzcDsmbmJzcDsgVGhlIGNsaWVudCBTSE9V TEQgZ2VuZXJhdGUgdG9rZW5zIGluIHN1Y2ggYSB3YXkgdGhhdCB0b2tlbnMgY3VycmVudGx5PG86 cCBjbGFzcz0iIj48L286cD48L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGNtIDBjbSAwLjAw MDFwdDsgZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsi IGNsYXNzPSIiPg0KJm5ic3A7Jm5ic3A7IGluIHVzZSBmb3IgYSBnaXZlbiBzb3VyY2UvZGVzdGlu YXRpb24gZW5kcG9pbnQgcGFpciBhcmUgdW5pcXVlPG86cCBjbGFzcz0iIj48L286cD48L2Rpdj4N CjxkaXYgc3R5bGU9Im1hcmdpbjogMGNtIDBjbSAwLjAwMDFwdDsgZm9udC1zaXplOiAxMXB0OyBm b250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiIGNsYXNzPSIiPg0KPG86cCBjbGFzcz0i Ij4mbmJzcDs8L286cD48L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGNtIDBjbSAwLjAwMDFw dDsgZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiIGNs YXNzPSIiPg0KYW5kIHRoZW48bzpwIGNsYXNzPSIiPjwvbzpwPjwvZGl2Pg0KPGRpdiBzdHlsZT0i bWFyZ2luOiAwY20gMGNtIDAuMDAwMXB0OyBmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBD YWxpYnJpLCBzYW5zLXNlcmlmOyIgY2xhc3M9IiI+DQo8bzpwIGNsYXNzPSIiPiZuYnNwOzwvbzpw PjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwY20gMGNtIDAuMDAwMXB0OyBmb250LXNpemU6 IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyIgY2xhc3M9IiI+DQpSRkM3 NjQxIDQuMS4mbmJzcDsgUmVxdWVzdDxvOnAgY2xhc3M9IiI+PC9vOnA+PC9kaXY+DQo8ZGl2IHN0 eWxlPSJtYXJnaW46IDBjbSAwY20gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1p bHk6IENhbGlicmksIHNhbnMtc2VyaWY7IiBjbGFzcz0iIj4NCuKApi48bzpwIGNsYXNzPSIiPjwv bzpwPjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwY20gMGNtIDAuMDAwMXB0OyBmb250LXNp emU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyIgY2xhc3M9IiI+DQom bmJzcDsmbmJzcDsgVGhlIGVudHJ5IGluIHRoZSBsaXN0IG9mIG9ic2VydmVycyBpcyBrZXllZCBi eSB0aGUgY2xpZW50IGVuZHBvaW50PG86cCBjbGFzcz0iIj48L286cD48L2Rpdj4NCjxkaXYgc3R5 bGU9Im1hcmdpbjogMGNtIDBjbSAwLjAwMDFwdDsgZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWls eTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiIGNsYXNzPSIiPg0KJm5ic3A7Jm5ic3A7IGFuZCB0aGUg dG9rZW4gc3BlY2lmaWVkIGJ5IHRoZSBjbGllbnQgaW4gdGhlIHJlcXVlc3QuJm5ic3A7IElmIGFu IGVudHJ5PG86cCBjbGFzcz0iIj48L286cD48L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGNt IDBjbSAwLjAwMDFwdDsgZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fu cy1zZXJpZjsiIGNsYXNzPSIiPg0KJm5ic3A7Jm5ic3A7IHdpdGggYSBtYXRjaGluZyBlbmRwb2lu dC90b2tlbiBwYWlyIGlzIGFscmVhZHkgcHJlc2VudCBpbiB0aGUgbGlzdDxvOnAgY2xhc3M9IiI+ PC9vOnA+PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBjbSAwY20gMC4wMDAxcHQ7IGZvbnQt c2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IiBjbGFzcz0iIj4N CiZuYnNwOyZuYnNwOyAod2hpY2gsIGZvciBleGFtcGxlLCBoYXBwZW5zIHdoZW4gdGhlIGNsaWVu dCB3aXNoZXMgdG8gcmVpbmZvcmNlIGl0czxvOnAgY2xhc3M9IiI+PC9vOnA+PC9kaXY+DQo8ZGl2 IHN0eWxlPSJtYXJnaW46IDBjbSAwY20gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTFwdDsgZm9udC1m YW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IiBjbGFzcz0iIj4NCiZuYnNwOyZuYnNwOyBpbnRl cmVzdCBpbiBhIHJlc291cmNlKSwgdGhlIHNlcnZlciBNVVNUIE5PVCBhZGQgYSBuZXcgZW50cnkg YnV0IE1VU1Q8bzpwIGNsYXNzPSIiPjwvbzpwPjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAw Y20gMGNtIDAuMDAwMXB0OyBmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBz YW5zLXNlcmlmOyIgY2xhc3M9IiI+DQombmJzcDsmbmJzcDsgcmVwbGFjZSBvciB1cGRhdGUgdGhl IGV4aXN0aW5nIG9uZS48bzpwIGNsYXNzPSIiPjwvbzpwPjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFy Z2luOiAwY20gMGNtIDAuMDAwMXB0OyBmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxp YnJpLCBzYW5zLXNlcmlmOyIgY2xhc3M9IiI+DQo8bzpwIGNsYXNzPSIiPiZuYnNwOzwvbzpwPjwv ZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwY20gMGNtIDAuMDAwMXB0OyBmb250LXNpemU6IDEx cHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyIgY2xhc3M9IiI+DQpTbywgYSBz dWJzZXF1ZW50IGRpZmZlcmVudCBRdWVyeSB1c2luZyB0aGUgc2FtZSBUb2tlbiBpcyBvdmVyd3Jp dHRlbiDigJMgdGhlIHByZXZpb3VzIE9ic2VydmUgaXMgZGVsZXRlZCBhbmQgdGhlIG5ldyBvbmUg aW52b2tlZC4mbmJzcDsgVGhlIGxpYmNvYXAgaXMgY29ycmVjdCBpbiB3aGF0IGl0IGlzIGRvaW5n LjxvOnAgY2xhc3M9IiI+PC9vOnA+PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBjbSAwY20g MC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2Vy aWY7IiBjbGFzcz0iIj4NCjxvOnAgY2xhc3M9IiI+Jm5ic3A7PC9vOnA+PC9kaXY+DQo8ZGl2IHN0 eWxlPSJtYXJnaW46IDBjbSAwY20gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1p bHk6IENhbGlicmksIHNhbnMtc2VyaWY7IiBjbGFzcz0iIj4NCkNhbiB3ZSB0aGVyZWZvcmUgaGF2 ZSB0aGlzIGFzICh0byBzdXBwb3J0IHRoZSBtb25pdG9yaW5nIG9mIG11bHRpcGxlIG1pdGlnYXRp b24gcmVxdWVzdHMgcGVyIGNsaWVudCk8bzpwIGNsYXNzPSIiPjwvbzpwPjwvZGl2Pg0KPGRpdiBz dHlsZT0ibWFyZ2luOiAwY20gMGNtIDAuMDAwMXB0OyBmb250LXNpemU6IDExcHQ7IGZvbnQtZmFt aWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyIgY2xhc3M9IiI+DQo8bzpwIGNsYXNzPSIiPiZuYnNw OzwvbzpwPjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwY20gMGNtIDAuMDAwMXB0OyBmb250 LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyIgY2xhc3M9IiI+ DQo0LjQuMjxvOnAgY2xhc3M9IiI+PC9vOnA+PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBj bSAwY20gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNh bnMtc2VyaWY7IiBjbGFzcz0iIj4NCuKApjxvOnAgY2xhc3M9IiI+PC9vOnA+PC9kaXY+DQo8ZGl2 IHN0eWxlPSJtYXJnaW46IDBjbSAwY20gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTFwdDsgZm9udC1m YW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IiBjbGFzcz0iIj4NCiZuYnNwOyAnY3VpZCcgaXMg YSBtYW5kYXRvcnkgVXJpLTxiIGNsYXNzPSIiPjxzcGFuIHN0eWxlPSJjb2xvcjogcmVkOyIgY2xh c3M9IiI+UGF0aDwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImNvbG9yOiByZWQ7IiBjbGFzcz0iIj48 c3BhbiBjbGFzcz0iQXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PC9zcGFuPnBh cmFtZXRlciBmb3IgR0VUIHJlcXVlc3RzLjxvOnAgY2xhc3M9IiI+PC9vOnA+PC9kaXY+DQo8ZGl2 IHN0eWxlPSJtYXJnaW46IDBjbSAwY20gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTFwdDsgZm9udC1m YW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IiBjbGFzcz0iIj4NCjxvOnAgY2xhc3M9IiI+Jm5i c3A7PC9vOnA+PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBjbSAwY20gMC4wMDAxcHQ7IGZv bnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IiBjbGFzcz0i Ij4NCiZuYnNwOyZuYnNwOyBVcmktPGIgY2xhc3M9IiI+PHNwYW4gc3R5bGU9ImNvbG9yOiByZWQ7 IiBjbGFzcz0iIj5QYXRoPC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iY29sb3I6IHJlZDsiIGNsYXNz PSIiPjxzcGFuIGNsYXNzPSJBcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48L3Nw YW4+cGFyYW1ldGVycyB3aXRoIGVtcHR5IHZhbHVlcyBNVVNUIE5PVCBiZSBwcmVzZW50IGluIGE8 bzpwIGNsYXNzPSIiPjwvbzpwPjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwY20gMGNtIDAu MDAwMXB0OyBmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlm OyIgY2xhc3M9IiI+DQombmJzcDsmbmJzcDsgcmVxdWVzdC48bzpwIGNsYXNzPSIiPjwvbzpwPjwv ZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwY20gMGNtIDAuMDAwMXB0OyBmb250LXNpemU6IDEx cHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyIgY2xhc3M9IiI+DQo8bzpwIGNs YXNzPSIiPiZuYnNwOzwvbzpwPjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwY20gMGNtIDAu MDAwMXB0OyBmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlm OyIgY2xhc3M9IiI+DQombmJzcDsmbmJzcDsgVGhlIHNhbWUgY29uc2lkZXJhdGlvbnMgZm9yIG1h bmlwdWxhdGluZyAnY2RpZCcgcGFyYW1ldGVyIGJ5IHNlcnZlci08bzpwIGNsYXNzPSIiPjwvbzpw PjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwY20gMGNtIDAuMDAwMXB0OyBmb250LXNpemU6 IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyIgY2xhc3M9IiI+DQombmJz cDsmbmJzcDsgZG9tYWluIERPVFMgZ2F0ZXdheXMgc3BlY2lmaWVkIGluIFNlY3Rpb24gNC40LjEg TVVTVCBiZSBmb2xsb3dlZCBmb3I8bzpwIGNsYXNzPSIiPjwvbzpwPjwvZGl2Pg0KPGRpdiBzdHls ZT0ibWFyZ2luOiAwY20gMGNtIDAuMDAwMXB0OyBmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5 OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyIgY2xhc3M9IiI+DQombmJzcDsmbmJzcDsgR0VUIHJlcXVl c3RzLjxvOnAgY2xhc3M9IiI+PC9vOnA+PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBjbSAw Y20gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMt c2VyaWY7IiBjbGFzcz0iIj4NCjxvOnAgY2xhc3M9IiI+Jm5ic3A7PC9vOnA+PC9kaXY+DQo8ZGl2 IHN0eWxlPSJtYXJnaW46IDBjbSAwY20gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTFwdDsgZm9udC1m YW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IiBjbGFzcz0iIj4NCiZuYnNwOyZuYnNwOyBJZiB0 aGUgRE9UUyBzZXJ2ZXIgZG9lcyBub3QgZmluZCB0aGUgJ21pZCcgVXJpLTxiIGNsYXNzPSIiPjxz cGFuIHN0eWxlPSJjb2xvcjogcmVkOyIgY2xhc3M9IiI+UGF0aDwvc3Bhbj48L2I+PHNwYW4gc3R5 bGU9ImNvbG9yOiByZWQ7IiBjbGFzcz0iIj48c3BhbiBjbGFzcz0iQXBwbGUtY29udmVydGVkLXNw YWNlIj4mbmJzcDs8L3NwYW4+PC9zcGFuPnZhbHVlIGNvbnZleWVkPG86cCBjbGFzcz0iIj48L286 cD48L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGNtIDBjbSAwLjAwMDFwdDsgZm9udC1zaXpl OiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiIGNsYXNzPSIiPg0KJm5i c3A7Jm5ic3A7IGluIHRoZSBHRVQgcmVxdWVzdCBpbiBpdHMgY29uZmlndXJhdGlvbiBkYXRhIGZv ciB0aGUgcmVxdWVzdGluZyBET1RTPG86cCBjbGFzcz0iIj48L286cD48L2Rpdj4NCjxkaXYgc3R5 bGU9Im1hcmdpbjogMGNtIDBjbSAwLjAwMDFwdDsgZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWls eTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiIGNsYXNzPSIiPg0KJm5ic3A7Jm5ic3A7IGNsaWVudCwg aXQgTVVTVCByZXNwb25kIHdpdGggYSA0LjA0IChOb3QgRm91bmQpIGVycm9yIHJlc3BvbnNlIGNv ZGUuPG86cCBjbGFzcz0iIj48L286cD48L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGNtIDBj bSAwLjAwMDFwdDsgZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1z ZXJpZjsiIGNsYXNzPSIiPg0KJm5ic3A7Jm5ic3A7IExpa2V3aXNlLCB0aGUgc2FtZSBlcnJvciBN VVNUIGJlIHJldHVybmVkIGFzIGEgcmVzcG9uc2UgdG8gYSByZXF1ZXN0PG86cCBjbGFzcz0iIj48 L286cD48L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGNtIDBjbSAwLjAwMDFwdDsgZm9udC1z aXplOiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiIGNsYXNzPSIiPg0K Jm5ic3A7Jm5ic3A7IHRvIHJldHJpZXZlIGFsbCBtaXRpZ2F0aW9uIHJlY29yZHMgKGkuZS4sICdt aWQnIFVyaS08YiBjbGFzcz0iIj48c3BhbiBzdHlsZT0iY29sb3I6IHJlZDsiIGNsYXNzPSIiPlBh dGg8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJjb2xvcjogcmVkOyIgY2xhc3M9IiI+PHNwYW4gY2xh c3M9IkFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjwvc3Bhbj5pcyBub3Q8bzpw IGNsYXNzPSIiPjwvbzpwPjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwY20gMGNtIDAuMDAw MXB0OyBmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyIg Y2xhc3M9IiI+DQombmJzcDsmbmJzcDsgZGVmaW5lZCkgb2YgYSBnaXZlbiBET1RTIGNsaWVudCBp ZiB0aGUgRE9UUyBzZXJ2ZXIgZG9lcyBub3QgZmluZCBhbnk8bzpwIGNsYXNzPSIiPjwvbzpwPjwv ZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwY20gMGNtIDAuMDAwMXB0OyBmb250LXNpemU6IDEx cHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyIgY2xhc3M9IiI+DQombmJzcDsm bmJzcDsgbWl0aWdhdGlvbiByZWNvcmQgZm9yIHRoYXQgRE9UUyBjbGllbnQuJm5ic3A7IEFzIGEg cmVtaW5kZXIsIGEgRE9UUyBjbGllbnQ8bzpwIGNsYXNzPSIiPjwvbzpwPjwvZGl2Pg0KPGRpdiBz dHlsZT0ibWFyZ2luOiAwY20gMGNtIDAuMDAwMXB0OyBmb250LXNpemU6IDExcHQ7IGZvbnQtZmFt aWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyIgY2xhc3M9IiI+DQombmJzcDsmbmJzcDsgaXMgaWRl bnRpZmllZCBieSBpdHMgaWRlbnRpdHkgKGUuZy4sIGNsaWVudCBjZXJ0aWZpY2F0ZSwgJ2N1aWQn KSBhbmQ8bzpwIGNsYXNzPSIiPjwvbzpwPjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwY20g MGNtIDAuMDAwMXB0OyBmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5z LXNlcmlmOyIgY2xhc3M9IiI+DQombmJzcDsmbmJzcDsgb3B0aW9uYWxseSB0aGUgJ2NkaWQnPG86 cCBjbGFzcz0iIj48L286cD48L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGNtIDBjbSAwLjAw MDFwdDsgZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsi IGNsYXNzPSIiPg0K4oCmPG86cCBjbGFzcz0iIj48L286cD48L2Rpdj4NCjxkaXYgc3R5bGU9Im1h cmdpbjogMGNtIDBjbSAwLjAwMDFwdDsgZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogQ2Fs aWJyaSwgc2Fucy1zZXJpZjsiIGNsYXNzPSIiPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IEhl YWRlcjogR0VUIChDb2RlPTAuMDEpPG86cCBjbGFzcz0iIj48L286cD48L2Rpdj4NCjxkaXYgc3R5 bGU9Im1hcmdpbjogMGNtIDBjbSAwLjAwMDFwdDsgZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWls eTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiIGNsYXNzPSIiPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7IFVyaS1Ib3N0OiAmcXVvdDtob3N0JnF1b3Q7PG86cCBjbGFzcz0iIj48L286cD48L2Rpdj4N CjxkaXYgc3R5bGU9Im1hcmdpbjogMGNtIDBjbSAwLjAwMDFwdDsgZm9udC1zaXplOiAxMXB0OyBm b250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiIGNsYXNzPSIiPg0KJm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7IFVyaS1QYXRoOiAmcXVvdDsud2VsbC1rbm93biZxdW90OzxvOnAgY2xhc3M9 IiI+PC9vOnA+PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBjbSAwY20gMC4wMDAxcHQ7IGZv bnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IiBjbGFzcz0i Ij4NCiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBVcmktUGF0aDogJnF1b3Q7ZG90cyZxdW90Ozxv OnAgY2xhc3M9IiI+PC9vOnA+PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBjbSAwY20gMC4w MDAxcHQ7IGZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7 IiBjbGFzcz0iIj4NCiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBVcmktUGF0aDogJnF1b3Q7djEm cXVvdDs8bzpwIGNsYXNzPSIiPjwvbzpwPjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwY20g MGNtIDAuMDAwMXB0OyBmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5z LXNlcmlmOyIgY2xhc3M9IiI+DQombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgVXJpLVBhdGg6ICZx dW90O21pdGlnYXRlJnF1b3Q7PG86cCBjbGFzcz0iIj48L286cD48L2Rpdj4NCjxkaXYgc3R5bGU9 Im1hcmdpbjogMGNtIDBjbSAwLjAwMDFwdDsgZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTog Q2FsaWJyaSwgc2Fucy1zZXJpZjsiIGNsYXNzPSIiPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 IFVyaS08YiBjbGFzcz0iIj48c3BhbiBzdHlsZT0iY29sb3I6IHJlZDsiIGNsYXNzPSIiPlBhdGg8 L3NwYW4+PC9iPjogJnF1b3Q7Y3VpZD1kejZwSGphQURrYUZUYmpyMEpHQnB3JnF1b3Q7PG86cCBj bGFzcz0iIj48L286cD48L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGNtIDBjbSAwLjAwMDFw dDsgZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiIGNs YXNzPSIiPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFVyaS08YiBjbGFzcz0iIj48c3BhbiBz dHlsZT0iY29sb3I6IHJlZDsiIGNsYXNzPSIiPlBhdGg8L3NwYW4+PC9iPjogJnF1b3Q7bWlkPTEy MzMyJnF1b3Q7PG86cCBjbGFzcz0iIj48L286cD48L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjog MGNtIDBjbSAwLjAwMDFwdDsgZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwg c2Fucy1zZXJpZjsiIGNsYXNzPSIiPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IE9ic2VydmU6 IDA8bzpwIGNsYXNzPSIiPjwvbzpwPjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwY20gMGNt IDAuMDAwMXB0OyBmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNl cmlmOyIgY2xhc3M9IiI+DQo8bzpwIGNsYXNzPSIiPiZuYnNwOzwvbzpwPjwvZGl2Pg0KPGRpdiBz dHlsZT0ibWFyZ2luOiAwY20gMGNtIDAuMDAwMXB0OyBmb250LXNpemU6IDExcHQ7IGZvbnQtZmFt aWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyIgY2xhc3M9IiI+DQombmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgRmlndXJlIDEyOiBHRVQgdG8gUmV0cmlldmUgYSBTcGVjaWZpYyBE T1RTIE1pdGlnYXRpb24gUmVxdWVzdDxvOnAgY2xhc3M9IiI+PC9vOnA+PC9kaXY+DQo8ZGl2IHN0 eWxlPSJtYXJnaW46IDBjbSAwY20gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1p bHk6IENhbGlicmksIHNhbnMtc2VyaWY7IiBjbGFzcz0iIj4NCjxvOnAgY2xhc3M9IiI+Jm5ic3A7 PC9vOnA+PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBjbSAwY20gMC4wMDAxcHQ7IGZvbnQt c2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IiBjbGFzcz0iIj4N CkFuZCBmb3IgY29uc2lzdGVuY3k8bzpwIGNsYXNzPSIiPjwvbzpwPjwvZGl2Pg0KPGRpdiBzdHls ZT0ibWFyZ2luOiAwY20gMGNtIDAuMDAwMXB0OyBmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5 OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyIgY2xhc3M9IiI+DQo8bzpwIGNsYXNzPSIiPiZuYnNwOzwv bzpwPjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwY20gMGNtIDAuMDAwMXB0OyBmb250LXNp emU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyIgY2xhc3M9IiI+DQo0 LjQuNDxvOnAgY2xhc3M9IiI+PC9vOnA+PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBjbSAw Y20gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMt c2VyaWY7IiBjbGFzcz0iIj4NCuKApjxvOnAgY2xhc3M9IiI+PC9vOnA+PC9kaXY+DQo8ZGl2IHN0 eWxlPSJtYXJnaW46IDBjbSAwY20gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1p bHk6IENhbGlicmksIHNhbnMtc2VyaWY7IiBjbGFzcz0iIj4NCiZuYnNwOyZuYnNwOyAnY3VpZCcg YW5kICdtaWQnIGFyZSBtYW5kYXRvcnkgVXJpLTxiIGNsYXNzPSIiPjxzcGFuIHN0eWxlPSJjb2xv cjogcmVkOyIgY2xhc3M9IiI+UGF0aDwvc3Bhbj48L2I+PHNwYW4gY2xhc3M9IkFwcGxlLWNvbnZl cnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPnBhcmFtZXRlcnMgZm9yIERFTEVURTxvOnAgY2xhc3M9 IiI+PC9vOnA+PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBjbSAwY20gMC4wMDAxcHQ7IGZv bnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IiBjbGFzcz0i Ij4NCiZuYnNwOyZuYnNwOyByZXF1ZXN0cy48bzpwIGNsYXNzPSIiPjwvbzpwPjwvZGl2Pg0KPGRp diBzdHlsZT0ibWFyZ2luOiAwY20gMGNtIDAuMDAwMXB0OyBmb250LXNpemU6IDExcHQ7IGZvbnQt ZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyIgY2xhc3M9IiI+DQo8bzpwIGNsYXNzPSIiPiZu YnNwOzwvbzpwPjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwY20gMGNtIDAuMDAwMXB0OyBm b250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyIgY2xhc3M9 IiI+DQombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgSGVhZGVyOiBERUxFVEUgKENvZGU9MC4wNCk8 bzpwIGNsYXNzPSIiPjwvbzpwPjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwY20gMGNtIDAu MDAwMXB0OyBmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlm OyIgY2xhc3M9IiI+DQombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgVXJpLUhvc3Q6ICZxdW90O2hv c3QmcXVvdDs8bzpwIGNsYXNzPSIiPjwvbzpwPjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAw Y20gMGNtIDAuMDAwMXB0OyBmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBz YW5zLXNlcmlmOyIgY2xhc3M9IiI+DQombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgVXJpLVBhdGg6 ICZxdW90Oy53ZWxsLWtub3duJnF1b3Q7PG86cCBjbGFzcz0iIj48L286cD48L2Rpdj4NCjxkaXYg c3R5bGU9Im1hcmdpbjogMGNtIDBjbSAwLjAwMDFwdDsgZm9udC1zaXplOiAxMXB0OyBmb250LWZh bWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiIGNsYXNzPSIiPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7IFVyaS1QYXRoOiAmcXVvdDtkb3RzJnF1b3Q7PG86cCBjbGFzcz0iIj48L286cD48L2Rp dj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGNtIDBjbSAwLjAwMDFwdDsgZm9udC1zaXplOiAxMXB0 OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiIGNsYXNzPSIiPg0KJm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7IFVyaS1QYXRoOiAmcXVvdDt2MSZxdW90OzxvOnAgY2xhc3M9IiI+PC9v OnA+PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBjbSAwY20gMC4wMDAxcHQ7IGZvbnQtc2l6 ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IiBjbGFzcz0iIj4NCiZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBVcmktUGF0aDogJnF1b3Q7bWl0aWdhdGUmcXVvdDs8bzpw IGNsYXNzPSIiPjwvbzpwPjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwY20gMGNtIDAuMDAw MXB0OyBmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyIg Y2xhc3M9IiI+DQombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgVXJpLTxiIGNsYXNzPSIiPjxzcGFu IHN0eWxlPSJjb2xvcjogcmVkOyIgY2xhc3M9IiI+UGF0aDwvc3Bhbj48L2I+OiAmcXVvdDtjdWlk PWR6NnBIamFBRGthRlRianIwSkdCcHcmcXVvdDs8bzpwIGNsYXNzPSIiPjwvbzpwPjwvZGl2Pg0K PGRpdiBzdHlsZT0ibWFyZ2luOiAwY20gMGNtIDAuMDAwMXB0OyBmb250LXNpemU6IDExcHQ7IGZv bnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyIgY2xhc3M9IiI+DQombmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgVXJpLTxiIGNsYXNzPSIiPjxzcGFuIHN0eWxlPSJjb2xvcjogcmVkOyIgY2xh c3M9IiI+UGF0aDwvc3Bhbj48L2I+OiAmcXVvdDttaWQ9MTIzJnF1b3Q7PG86cCBjbGFzcz0iIj48 L286cD48L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGNtIDBjbSAwLjAwMDFwdDsgZm9udC1z aXplOiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiIGNsYXNzPSIiPg0K PG86cCBjbGFzcz0iIj4mbmJzcDs8L286cD48L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGNt IDBjbSAwLjAwMDFwdDsgZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fu cy1zZXJpZjsiIGNsYXNzPSIiPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7ICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwO0ZpZ3VyZSAxNjogV2l0aGRyYXcgYSBET1RTIE1pdGlnYXRpb248bzpw IGNsYXNzPSIiPjwvbzpwPjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwY20gMGNtIDAuMDAw MXB0OyBmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyIg Y2xhc3M9IiI+DQo8bzpwIGNsYXNzPSIiPiZuYnNwOzwvbzpwPjwvZGl2Pg0KPGRpdiBzdHlsZT0i bWFyZ2luOiAwY20gMGNtIDAuMDAwMXB0OyBmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBD YWxpYnJpLCBzYW5zLXNlcmlmOyIgY2xhc3M9IiI+DQo0LjUuMzxvOnAgY2xhc3M9IiI+PC9vOnA+ PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBjbSAwY20gMC4wMDAxcHQ7IGZvbnQtc2l6ZTog MTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IiBjbGFzcz0iIj4NCuKApjxv OnAgY2xhc3M9IiI+PC9vOnA+PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBjbSAwY20gMC4w MDAxcHQ7IGZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7 IiBjbGFzcz0iIj4NCiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBIZWFkZXI6IERFTEVURSAoQ29k ZT0wLjA0KTxvOnAgY2xhc3M9IiI+PC9vOnA+PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBj bSAwY20gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNh bnMtc2VyaWY7IiBjbGFzcz0iIj4NCiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBVcmktSG9zdDog JnF1b3Q7aG9zdCZxdW90OzxvOnAgY2xhc3M9IiI+PC9vOnA+PC9kaXY+DQo8ZGl2IHN0eWxlPSJt YXJnaW46IDBjbSAwY20gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENh bGlicmksIHNhbnMtc2VyaWY7IiBjbGFzcz0iIj4NCiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBV cmktUGF0aDogJnF1b3Q7LndlbGwta25vd24mcXVvdDs8bzpwIGNsYXNzPSIiPjwvbzpwPjwvZGl2 Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwY20gMGNtIDAuMDAwMXB0OyBmb250LXNpemU6IDExcHQ7 IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyIgY2xhc3M9IiI+DQombmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgVXJpLVBhdGg6ICZxdW90O2RvdHMmcXVvdDs8bzpwIGNsYXNzPSIiPjwv bzpwPjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwY20gMGNtIDAuMDAwMXB0OyBmb250LXNp emU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyIgY2xhc3M9IiI+DQom bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgVXJpLVBhdGg6ICZxdW90O3YxJnF1b3Q7PG86cCBjbGFz cz0iIj48L286cD48L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGNtIDBjbSAwLjAwMDFwdDsg Zm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiIGNsYXNz PSIiPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFVyaS1QYXRoOiAmcXVvdDtjb25maWcmcXVv dDs8bzpwIGNsYXNzPSIiPjwvbzpwPjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwY20gMGNt IDAuMDAwMXB0OyBmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNl cmlmOyIgY2xhc3M9IiI+DQombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgVXJpLTxiIGNsYXNzPSIi PjxzcGFuIHN0eWxlPSJjb2xvcjogcmVkOyIgY2xhc3M9IiI+UGF0aDwvc3Bhbj48L2I+OiAmcXVv dDtzaWQ9MTIzJnF1b3Q7PG86cCBjbGFzcz0iIj48L286cD48L2Rpdj4NCjxkaXYgc3R5bGU9Im1h cmdpbjogMGNtIDBjbSAwLjAwMDFwdDsgZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogQ2Fs aWJyaSwgc2Fucy1zZXJpZjsiIGNsYXNzPSIiPg0KPG86cCBjbGFzcz0iIj4mbmJzcDs8L286cD48 L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGNtIDBjbSAwLjAwMDFwdDsgZm9udC1zaXplOiAx MXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiIGNsYXNzPSIiPg0KJm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7IEZpZ3VyZSAyMjogREVMRVRFIENvbmZpZ3VyYXRpb248bzpwIGNsYXNzPSIiPjwvbzpw PjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwY20gMGNtIDAuMDAwMXB0OyBmb250LXNpemU6 IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyIgY2xhc3M9IiI+DQo8bzpw IGNsYXNzPSIiPiZuYnNwOzwvbzpwPjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwY20gMGNt IDAuMDAwMXB0OyBmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNl cmlmOyIgY2xhc3M9IiI+DQpSZWdhcmRzPG86cCBjbGFzcz0iIj48L286cD48L2Rpdj4NCjxkaXYg c3R5bGU9Im1hcmdpbjogMGNtIDBjbSAwLjAwMDFwdDsgZm9udC1zaXplOiAxMXB0OyBmb250LWZh bWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiIGNsYXNzPSIiPg0KPG86cCBjbGFzcz0iIj4mbmJz cDs8L286cD48L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGNtIDBjbSAwLjAwMDFwdDsgZm9u dC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiIGNsYXNzPSIi Pg0KSm9uPG86cCBjbGFzcz0iIj48L286cD48L2Rpdj4NCjwvZGl2Pg0KPGJyIGNsYXNzPSIiPg0K PGZpZWxkc2V0IGNsYXNzPSJtaW1lQXR0YWNobWVudEhlYWRlciI+PC9maWVsZHNldD48YnIgY2xh c3M9IiI+DQo8cHJlIHdyYXA9IiIgY2xhc3M9IiI+X19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18NCkRvdHMgbWFpbGluZyBsaXN0DQo8YSBjbGFzcz0ibW96LXR4 dC1saW5rLWFiYnJldmlhdGVkIiBocmVmPSJtYWlsdG86RG90c0BpZXRmLm9yZyIgc3R5bGU9ImNv bG9yOiBwdXJwbGU7IHRleHQtZGVjb3JhdGlvbjogdW5kZXJsaW5lOyI+RG90c0BpZXRmLm9yZzwv YT4NCjxhIGNsYXNzPSJtb3otdHh0LWxpbmstZnJlZXRleHQiIGhyZWY9Imh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vZG90cyIgc3R5bGU9ImNvbG9yOiBwdXJwbGU7IHRleHQt ZGVjb3JhdGlvbjogdW5kZXJsaW5lOyI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9kb3RzPC9hPg0KPC9wcmU+DQo8L2Jsb2NrcXVvdGU+DQo8YnIgc3R5bGU9ImZvbnQtZmFt aWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250 LXZhcmlhbnQtY2Fwczogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2lu Zzogbm9ybWFsOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFu c2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdvcmQtc3BhY2luZzogMHB4OyAtd2Vi a2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IGJhY2tncm91bmQtY29sb3I6IHJnYigyNTUsIDI1 NSwgMjU1KTsiIGNsYXNzPSIiPg0KPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7 IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fwczog bm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyB0ZXh0 LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdo aXRlLXNwYWNlOiBub3JtYWw7IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tl LXdpZHRoOiAwcHg7IGJhY2tncm91bmQtY29sb3I6IHJnYigyNTUsIDI1NSwgMjU1KTsgZmxvYXQ6 IG5vbmU7IGRpc3BsYXk6IGlubGluZSAhaW1wb3J0YW50OyIgY2xhc3M9IiI+X19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188L3NwYW4+PGJyIHN0eWxlPSJmb250 LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsg Zm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNw YWNpbmc6IG5vcm1hbDsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQt dHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3b3JkLXNwYWNpbmc6IDBweDsg LXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyBiYWNrZ3JvdW5kLWNvbG9yOiByZ2IoMjU1 LCAyNTUsIDI1NSk7IiBjbGFzcz0iIj4NCjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTogSGVsdmV0 aWNhOyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWNh cHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsg dGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25l OyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0 cm9rZS13aWR0aDogMHB4OyBiYWNrZ3JvdW5kLWNvbG9yOiByZ2IoMjU1LCAyNTUsIDI1NSk7IGZs b2F0OiBub25lOyBkaXNwbGF5OiBpbmxpbmUgIWltcG9ydGFudDsiIGNsYXNzPSIiPkRvdHMNCiBt YWlsaW5nIGxpc3Q8L3NwYW4+PGJyIHN0eWxlPSJmb250LWZhbWlseTogSGVsdmV0aWNhOyBmb250 LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWNhcHM6IG5vcm1h bDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgdGV4dC1hbGln bjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1z cGFjZTogbm9ybWFsOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0 aDogMHB4OyBiYWNrZ3JvdW5kLWNvbG9yOiByZ2IoMjU1LCAyNTUsIDI1NSk7IiBjbGFzcz0iIj4N CjxhIGhyZWY9Im1haWx0bzpEb3RzQGlldGYub3JnIiBzdHlsZT0iY29sb3I6IHB1cnBsZTsgdGV4 dC1kZWNvcmF0aW9uOiB1bmRlcmxpbmU7IGZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6 ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsOyBm b250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyBvcnBoYW5zOiBhdXRv OyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5v bmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdpZG93czogYXV0bzsgd29yZC1zcGFjaW5nOiAwcHg7 IC13ZWJraXQtdGV4dC1zaXplLWFkanVzdDogYXV0bzsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0 aDogMHB4OyBiYWNrZ3JvdW5kLWNvbG9yOiByZ2IoMjU1LCAyNTUsIDI1NSk7IiBjbGFzcz0iIj5E b3RzQGlldGYub3JnPC9hPjxiciBzdHlsZT0iZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1z aXplOiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7 IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IHRleHQtYWxpZ246 IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3Bh Y2U6IG5vcm1hbDsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6 IDBweDsgYmFja2dyb3VuZC1jb2xvcjogcmdiKDI1NSwgMjU1LCAyNTUpOyIgY2xhc3M9IiI+DQo8 YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RvdHMiIHN0eWxl PSJjb2xvcjogcHVycGxlOyB0ZXh0LWRlY29yYXRpb246IHVuZGVybGluZTsgZm9udC1mYW1pbHk6 IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFy aWFudC1jYXBzOiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBu b3JtYWw7IG9ycGhhbnM6IGF1dG87IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4 OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd2lkb3dzOiBhdXRv OyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXNpemUtYWRqdXN0OiBhdXRvOyAtd2Vi a2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IGJhY2tncm91bmQtY29sb3I6IHJnYigyNTUsIDI1 NSwgMjU1KTsiIGNsYXNzPSIiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v ZG90czwvYT48YnIgc3R5bGU9ImZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJw eDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsOyBmb250LXdl aWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyB0ZXh0LWFsaWduOiBzdGFydDsg dGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3Jt YWw7IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IGJh Y2tncm91bmQtY29sb3I6IHJnYigyNTUsIDI1NSwgMjU1KTsiIGNsYXNzPSIiPg0KPC9kaXY+DQo8 L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxiciBjbGFzcz0iIj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_532223360F104425ACB047D9E1B201C0arbornet_-- From nobody Thu Mar 8 22:51: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 A8D921241F3 for ; Thu, 8 Mar 2018 22:51:27 -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 OEEUrj8z5DaF for ; Thu, 8 Mar 2018 22:51:25 -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 651EE1201FA for ; Thu, 8 Mar 2018 22:51:25 -0800 (PST) Received: from opfedar04.francetelecom.fr (unknown [xx.xx.xx.6]) by opfedar25.francetelecom.fr (ESMTP service) with ESMTP id 66C6D120ACB; Fri, 9 Mar 2018 07:51:23 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.59]) by opfedar04.francetelecom.fr (ESMTP service) with ESMTP id 49D4340058; Fri, 9 Mar 2018 07:51:23 +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.0382.000; Fri, 9 Mar 2018 07:51:22 +0100 From: To: Jon Shallow , "dots@ietf.org" Thread-Topic: [Dots] Signal Observe implementation issue Thread-Index: AdO2vDgpziPgx8tcT0iIvzTD3rhHdwAtQEoQ Date: Fri, 9 Mar 2018 06:51:23 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93300A0E9D89@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <02c601d3b6bc$4bcf2590$e36d70b0$@jpshallow.com> In-Reply-To: <02c601d3b6bc$4bcf2590$e36d70b0$@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_787AE7BB302AE849A7480A190F8B93300A0E9D89OPEXCLILMA3corp_" MIME-Version: 1.0 Archived-At: Subject: Re: [Dots] Signal Observe implementation issue 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, 09 Mar 2018 06:51:28 -0000 --_000_787AE7BB302AE849A7480A190F8B93300A0E9D89OPEXCLILMA3corp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Jon, Seems pragmatic. Please check at: https://github.com/boucadair/draft-ietf-d= ots-signal-channel In the meantime RFC 7252 says the following: A token is intended for use as a client-local identifier for differentiating between concurrent requests (see Section 5.3); it could have been called a "request ID". An implementation that follows this "spirit" would assign distinct tokens f= or concurrent requests involving the same endpoints pair. IMO, the SHOULD text is broken because it assumes that only one request is = likely to be active between two endpoints. Cheers, Med De : Dots [mailto:dots-bounces@ietf.org] De la part de Jon Shallow Envoy=E9 : jeudi 8 mars 2018 10:03 =C0 : dots@ietf.org Objet : [Dots] Signal Observe implementation issue Hi there, We currently cannot support multiple Observe requests per client. A simple= change fixes the issue. In the signal-17 draft, we have Header: GET (Code=3D0.01) Uri-Host: "host" Uri-Path: ".well-known" Uri-Path: "dots" Uri-Path: "v1" Uri-Path: "mitigate" Uri-Query: "cuid=3Ddz6pHjaADkaFTbjr0JGBpw" Uri-Query: "mid=3D12332" Observe: 0 Figure 12: GET to Retrieve a Specific DOTS Mitigation Request Where the resource to Observe is a combination of the Uri-Path: and Uri-Que= ry. RFC7252 supports have the 'request URI' as a combination of both, so t= his is legal. However, in the libcoap I am using, it only supports one Query per Token pe= r Resource (the resource in this case being ".wellknown/dots/v1/mitigate") = for Observe. The Token should remain constant as per RFC7252 5.3.1. Token .. The client SHOULD generate tokens in such a way that tokens currently in use for a given source/destination endpoint pair are unique and then RFC7641 4.1. Request .... The entry in the list of observers is keyed by the client endpoint and the token specified by the client in the request. If an entry with a matching endpoint/token pair is already present in the list (which, for example, happens when the client wishes to reinforce its interest in a resource), the server MUST NOT add a new entry but MUST replace or update the existing one. So, a subsequent different Query using the same Token is overwritten - the = previous Observe is deleted and the new one invoked. The libcoap is correc= t in what it is doing. Can we therefore have this as (to support the monitoring of multiple mitiga= tion requests per client) 4.4.2 ... 'cuid' is a mandatory Uri-Path parameter for GET requests. Uri-Path parameters with empty values MUST NOT be present in a request. The same considerations for manipulating 'cdid' parameter by server- domain DOTS gateways specified in Section 4.4.1 MUST be followed for GET requests. If the DOTS server does not find the 'mid' Uri-Path value conveyed in the GET request in its configuration data for the requesting DOTS client, it MUST respond with a 4.04 (Not Found) error response code. Likewise, the same error MUST be returned as a response to a request to retrieve all mitigation records (i.e., 'mid' Uri-Path is not defined) of a given DOTS client if the DOTS server does not find any mitigation record for that DOTS client. As a reminder, a DOTS client is identified by its identity (e.g., client certificate, 'cuid') and optionally the 'cdid' ... Header: GET (Code=3D0.01) Uri-Host: "host" Uri-Path: ".well-known" Uri-Path: "dots" Uri-Path: "v1" Uri-Path: "mitigate" Uri-Path: "cuid=3Ddz6pHjaADkaFTbjr0JGBpw" Uri-Path: "mid=3D12332" Observe: 0 Figure 12: GET to Retrieve a Specific DOTS Mitigation Request And for consistency 4.4.4 ... 'cuid' and 'mid' are mandatory Uri-Path parameters for DELETE requests. Header: DELETE (Code=3D0.04) Uri-Host: "host" Uri-Path: ".well-known" Uri-Path: "dots" Uri-Path: "v1" Uri-Path: "mitigate" Uri-Path: "cuid=3Ddz6pHjaADkaFTbjr0JGBpw" Uri-Path: "mid=3D123" Figure 16: Withdraw a DOTS Mitigation 4.5.3 ... Header: DELETE (Code=3D0.04) Uri-Host: "host" Uri-Path: ".well-known" Uri-Path: "dots" Uri-Path: "v1" Uri-Path: "config" Uri-Path: "sid=3D123" Figure 22: DELETE Configuration Regards Jon --_000_787AE7BB302AE849A7480A190F8B93300A0E9D89OPEXCLILMA3corp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Jon,

 

Seems pragmatic. Please check a= t: htt= ps://github.com/boucadair/draft-ietf-dots-signal-channel

 

In the meantime RFC 7252 says t= he following:

 

   A toke= n is intended for use as a client-local identifier for

   differ= entiating between concurrent requests (see Section 5.3); it

   could = have been called a "request ID".

 

An implementation t= hat follows this “spirit” would assign distinct tokens for conc= urrent requests involving the same endpoints pair.

 

IMO, the SHOULD tex= t is broken because it assumes that only one request is likely to be active= between two endpoints.

 

Cheers,<= /span>

Med

 

D= ots [mailto:dots-bounces@ietf.org] De la part de Jon Shallow
Envoy=E9 : jeudi 8 mars 2018 10:03
=C0 : dots@ietf.org<= br> Objet : [Dots] Signal Observe implementation issue

 

Hi there,

 

We currently cannot support mul= tiple Observe requests per client.  A simple change fixes the issue.

 

In the signal-17 draft, we have=

 

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

     Uri-Ho= st: "host"

     Uri-Pa= th: ".well-known"

     Uri-Pa= th: "dots"

     Uri-Pa= th: "v1"

     Uri-Pa= th: "mitigate"

     Uri-Qu= ery: "cuid=3Ddz6pHjaADkaFTbjr0JGBpw"

     Uri-Qu= ery: "mid=3D12332"

     Observ= e: 0

 

     &= nbsp; Figure 12: GET to Retrieve a Specific DOTS Mitigation Request

 

Where the resource to Observe i= s a combination of the Uri-Path: and Uri-Query.  RFC7252 supports have= the ‘request URI’ as a combination of both, so this is legal.&= nbsp;

 

However, in the libcoap I am us= ing, it only supports one Query per Token per Resource (the resource in thi= s case being “.wellknown/dots/v1/mitigate”) for Observe.  = The Token should remain constant as per

 

RFC7252 5.3.1.  Token=

..

   The client SHOULD = generate tokens in such a way that tokens currently

   in use for a given= source/destination endpoint pair are unique

 

and then

 

RFC7641 4.1.  Request=

….

   The entry in the l= ist of observers is keyed by the client endpoint

   and the token spec= ified by the client in the request.  If an entry

   with a matching en= dpoint/token pair is already present in the list

   (which, for exampl= e, happens when the client wishes to reinforce its

   interest in a reso= urce), the server MUST NOT add a new entry but MUST

   replace or update = the existing one.

 

So, a subsequent different Quer= y using the same Token is overwritten – the previous Observe is delet= ed and the new one invoked.  The libcoap is correct in what it is doin= g.

 

Can we therefore have this as (= to support the monitoring of multiple mitigation requests per client)<= /o:p>

 

4.4.2

…

  'cuid' is a mandatory Ur= i-Path parameter for GET requests.

 

   Uri-Path parameters with empty values MUST NOT be present in a

   request.

 

   The same considera= tions for manipulating 'cdid' parameter by server-

   domain DOTS gatewa= ys specified in Section 4.4.1 MUST be followed for

   GET requests.=

 

   If the DOTS server= does not find the 'mid' Uri-Path value conveyed

   in the GET request= in its configuration data for the requesting DOTS

   client, it MUST re= spond with a 4.04 (Not Found) error response code.

   Likewise, the same= error MUST be returned as a response to a request

   to retrieve all mi= tigation records (i.e., 'mid' Uri-Path<= /b> is not

   defined) of a give= n DOTS client if the DOTS server does not find any

   mitigation record = for that DOTS client.  As a reminder, a DOTS client<= /p>

   is identified by i= ts identity (e.g., client certificate, 'cuid') and

   optionally the 'cd= id'

…

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

     Uri-Ho= st: "host"

     Uri-Pa= th: ".well-known"

     Uri-Pa= th: "dots"

     Uri-Pa= th: "v1"

     Uri-Pa= th: "mitigate"

     Uri-Path: "cuid=3Ddz6pHjaADkaFTbjr0J= GBpw"

     Uri-Path: "mid=3D12332"

     Observ= e: 0

 

     &= nbsp; Figure 12: GET to Retrieve a Specific DOTS Mitigation Request

 

And for consistency<= /span>

 

4.4.4

…

   'cuid' and 'mid' a= re mandatory Uri-Path parameters fo= r DELETE

   requests.

 

     Header= : DELETE (Code=3D0.04)

     Uri-Ho= st: "host"

     Uri-Pa= th: ".well-known"

     Uri-Pa= th: "dots"

     Uri-Pa= th: "v1"

     Uri-Pa= th: "mitigate"

     Uri-Path: "cuid=3Ddz6pHjaADkaFTbjr0J= GBpw"

     Uri-Path: "mid=3D123"

 

     &= nbsp;            &nb= sp;Figure 16: Withdraw a DOTS Mitigation

 

4.5.3

…

     Header= : DELETE (Code=3D0.04)

     Uri-Ho= st: "host"

     Uri-Pa= th: ".well-known"

     Uri-Pa= th: "dots"

     Uri-Pa= th: "v1"

     Uri-Pa= th: "config"

     Uri-Path: "sid=3D123"

 

     &= nbsp;           &nbs= p;    Figure 22: DELETE Configuration

 

Regards

 

Jon

--_000_787AE7BB302AE849A7480A190F8B93300A0E9D89OPEXCLILMA3corp_-- From nobody Fri Mar 9 01:14: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 76F1C129502 for ; Fri, 9 Mar 2018 01:14:37 -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 ZQ6Qne6uLoPg for ; Fri, 9 Mar 2018 01:14: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 4E663126C83 for ; Fri, 9 Mar 2018 01:14: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.90_1) (envelope-from ) id 1euE6i-0000VE-IY; Fri, 09 Mar 2018 09:14:32 +0000 From: "Jon Shallow" To: , References: <02c601d3b6bc$4bcf2590$e36d70b0$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93300A0E9D89@OPEXCLILMA3.corporate.adroot.infra.ftgroup> In-Reply-To: <787AE7BB302AE849A7480A190F8B93300A0E9D89@OPEXCLILMA3.corporate.adroot.infra.ftgroup> Date: Fri, 9 Mar 2018 09:14:32 -0000 Message-ID: <044d01d3b787$095eebc0$1c1cc340$@jpshallow.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_044E_01D3B787.0960E790" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQG9dsO1PTM2aIJaWUAmMzo5zdfI7QKJz4abo9/N3yA= Content-Language: en-gb Archived-At: Subject: Re: [Dots] Signal Observe implementation issue 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, 09 Mar 2018 09:14:37 -0000 This is a multipart message in MIME format. ------=_NextPart_000_044E_01D3B787.0960E790 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Med, =20 I agree with you that the SHOULD is causing confusion, and a better text = for RFC7252 could read =20 The client SHOULD generate tokens in such a way that tokens currently in use for a given source/destination endpoint are unique per request =20 However, I do think that the changes to the draft are the right way to = go as it gets rid of any possible issues here. =20 [My client code now uses a different tokens for each request] =20 Regards =20 Jon =20 From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of mohamed.boucadair@orange.com Sent: 09 March 2018 06:51 To: Jon Shallow; dots@ietf.org Subject: Re: [Dots] Signal Observe implementation issue =20 Hi Jon,=20 =20 Seems pragmatic. Please check at: https://github.com/boucadair/draft-ietf-dots-signal-channel=20 =20 In the meantime RFC 7252 says the following:=20 =20 A token is intended for use as a client-local identifier for differentiating between concurrent requests (see Section 5.3); it could have been called a "request ID". =20 An implementation that follows this =93spirit=94 would assign distinct = tokens for concurrent requests involving the same endpoints pair.=20 =20 IMO, the SHOULD text is broken because it assumes that only one request = is likely to be active between two endpoints.=20 =20 Cheers, Med =20 De : Dots [mailto:dots-bounces@ietf.org] De la part de Jon Shallow Envoy=E9 : jeudi 8 mars 2018 10:03 =C0 : d ots@ietf.org Objet : [Dots] Signal Observe implementation issue =20 Hi there, =20 We currently cannot support multiple Observe requests per client. A = simple change fixes the issue. =20 In the signal-17 draft, we have=20 =20 Header: GET (Code=3D0.01) Uri-Host: "host" Uri-Path: ".well-known" Uri-Path: "dots" Uri-Path: "v1" Uri-Path: "mitigate" Uri-Query: "cuid=3Ddz6pHjaADkaFTbjr0JGBpw" Uri-Query: "mid=3D12332" Observe: 0 =20 Figure 12: GET to Retrieve a Specific DOTS Mitigation Request =20 Where the resource to Observe is a combination of the Uri-Path: and Uri-Query. RFC7252 supports have the =91request URI=92 as a combination = of both, so this is legal. =20 =20 However, in the libcoap I am using, it only supports one Query per Token = per Resource (the resource in this case being = =93.wellknown/dots/v1/mitigate=94) for Observe. The Token should remain constant as per=20 =20 RFC7252 5.3.1. Token .. The client SHOULD generate tokens in such a way that tokens currently in use for a given source/destination endpoint pair are unique =20 and then =20 RFC7641 4.1. Request =85. The entry in the list of observers is keyed by the client endpoint and the token specified by the client in the request. If an entry with a matching endpoint/token pair is already present in the list (which, for example, happens when the client wishes to reinforce its interest in a resource), the server MUST NOT add a new entry but MUST replace or update the existing one. =20 So, a subsequent different Query using the same Token is overwritten =96 = the previous Observe is deleted and the new one invoked. The libcoap is = correct in what it is doing. =20 Can we therefore have this as (to support the monitoring of multiple mitigation requests per client) =20 4.4.2 =85 'cuid' is a mandatory Uri-Path parameter for GET requests. =20 Uri-Path parameters with empty values MUST NOT be present in a request. =20 The same considerations for manipulating 'cdid' parameter by server- domain DOTS gateways specified in Section 4.4.1 MUST be followed for GET requests. =20 If the DOTS server does not find the 'mid' Uri-Path value conveyed in the GET request in its configuration data for the requesting DOTS client, it MUST respond with a 4.04 (Not Found) error response code. Likewise, the same error MUST be returned as a response to a request to retrieve all mitigation records (i.e., 'mid' Uri-Path is not defined) of a given DOTS client if the DOTS server does not find any mitigation record for that DOTS client. As a reminder, a DOTS client is identified by its identity (e.g., client certificate, 'cuid') and optionally the 'cdid' =85 Header: GET (Code=3D0.01) Uri-Host: "host" Uri-Path: ".well-known" Uri-Path: "dots" Uri-Path: "v1" Uri-Path: "mitigate" Uri-Path: "cuid=3Ddz6pHjaADkaFTbjr0JGBpw" Uri-Path: "mid=3D12332" Observe: 0 =20 Figure 12: GET to Retrieve a Specific DOTS Mitigation Request =20 And for consistency =20 4.4.4 =85 'cuid' and 'mid' are mandatory Uri-Path parameters for DELETE requests. =20 Header: DELETE (Code=3D0.04) Uri-Host: "host" Uri-Path: ".well-known" Uri-Path: "dots" Uri-Path: "v1" Uri-Path: "mitigate" Uri-Path: "cuid=3Ddz6pHjaADkaFTbjr0JGBpw" Uri-Path: "mid=3D123" =20 Figure 16: Withdraw a DOTS Mitigation =20 4.5.3 =85 Header: DELETE (Code=3D0.04) Uri-Host: "host" Uri-Path: ".well-known" Uri-Path: "dots" Uri-Path: "v1" Uri-Path: "config" Uri-Path: "sid=3D123" =20 Figure 22: DELETE Configuration =20 Regards =20 Jon ------=_NextPart_000_044E_01D3B787.0960E790 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Med,

 

I agree with you that = the SHOULD is causing confusion, and a better text for RFC7252 could = read

 

   The client SHOULD generate tokens in such = a way that tokens currently

   in use for a given source/destination = endpoint are unique per request

 

However, I do think that = the changes to the draft are the right way to go as it gets rid of any = possible issues here.

 

[My client code now uses = a different tokens for each request]

 

Regards

 

Jon

 

From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of = mohamed.boucadair@orange.com
Sent: 09 March 2018 = 06:51
To: Jon Shallow; dots@ietf.org
Subject: Re: = [Dots] Signal Observe implementation = issue

 

Hi Jon,

 

Seems pragmatic. Please check at: http= s://github.com/boucadair/draft-ietf-dots-signal-channel =

 

In the meantime RFC 7252 says the following: =

 

   A token is intended for use = as a client-local identifier for

   differentiating between = concurrent requests (see Section 5.3); it

   could have been called a = "request ID".

 

An implementation that follows this = “spirit” would assign distinct tokens for concurrent = requests involving the same endpoints pair.

 

IMO, the SHOULD text is broken because it = assumes that only one request is likely to be active between two = endpoints.

 

Cheers,

Med

 

De : Dots [mailto:dots-bounces@ietf.org] = De la part de Jon Shallow
Envoy=E9 : jeudi 8 mars = 2018 10:03
=C0 : dots@ietf.org
Objet : [Dots] Signal Observe implementation = issue

 

Hi = there,

 

We currently cannot support multiple Observe requests = per client.  A simple change fixes the issue.

 

In the = signal-17 draft, we have

 

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

     Uri-Host: = "host"

     Uri-Path: = ".well-known"

     Uri-Path: = "dots"

     Uri-Path: = "v1"

     Uri-Path: = "mitigate"

     Uri-Query: = "cuid=3Ddz6pHjaADkaFTbjr0JGBpw"

     Uri-Query: = "mid=3D12332"

     Observe: 0

 

       Figure 12: GET to = Retrieve a Specific DOTS Mitigation Request

 

Where the = resource to Observe is a combination of the Uri-Path: and = Uri-Query.  RFC7252 supports have the ‘request URI’ as = a combination of both, so this is legal. 

 

However, in = the libcoap I am using, it only supports one Query per Token per = Resource (the resource in this case being = “.wellknown/dots/v1/mitigate”) for Observe.  The Token = should remain constant as per

 

RFC7252 = 5.3.1.  Token

..

   The = client SHOULD generate tokens in such a way that tokens = currently

   in use for a = given source/destination endpoint pair are unique

 

and = then

 

RFC7641 4.1.  Request

….

   The entry in the list of observers is = keyed by the client endpoint

   and the token specified by the client in = the request.  If an entry

   with a matching endpoint/token pair is = already present in the list

   (which, for example, happens when the = client wishes to reinforce its

   interest in a resource), the server MUST = NOT add a new entry but MUST

   replace or update the existing = one.

 

So, a subsequent different Query using the same Token = is overwritten – the previous Observe is deleted and the new one = invoked.  The libcoap is correct in what it is = doing.

 

Can we therefore have this as (to support the = monitoring of multiple mitigation requests per client)

 

4.4.2

…

  = 'cuid' is a mandatory Uri-Path = parameter for GET requests.

 

   = Uri-Path parameters with empty values MUST NOT be = present in a

   = request.

 

   The same considerations for manipulating = 'cdid' parameter by server-

   domain DOTS gateways specified in Section = 4.4.1 MUST be followed for

   GET requests.

 

   = If the DOTS server does not find the 'mid' Uri-Path = value conveyed

   in = the GET request in its configuration data for the requesting = DOTS

   client, it MUST = respond with a 4.04 (Not Found) error response code.

   Likewise, the same error MUST be returned = as a response to a request

   to retrieve all mitigation records (i.e., = 'mid' Uri-Path is not

   defined) of a given DOTS client if the = DOTS server does not find any

   mitigation record for that DOTS = client.  As a reminder, a DOTS client

   is identified by its identity (e.g., = client certificate, 'cuid') and

   optionally the 'cdid'

…

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

     Uri-Host: = "host"

     Uri-Path: = ".well-known"

     Uri-Path: = "dots"

     Uri-Path: = "v1"

     Uri-Path: = "mitigate"

     Uri-Path: = "cuid=3Ddz6pHjaADkaFTbjr0JGBpw"

     Uri-Path: = "mid=3D12332"

     Observe: 0

 

       Figure 12: GET to = Retrieve a Specific DOTS Mitigation Request

 

And for = consistency

 

4.4.4

…

   'cuid' and 'mid' are mandatory = Uri-Path parameters for = DELETE

   = requests.

 

     Header: DELETE = (Code=3D0.04)

     Uri-Host: = "host"

     Uri-Path: = ".well-known"

     Uri-Path: = "dots"

     Uri-Path: = "v1"

     Uri-Path: = "mitigate"

     Uri-Path: = "cuid=3Ddz6pHjaADkaFTbjr0JGBpw"

     Uri-Path: = "mid=3D123"

 

        =            Figure = 16: Withdraw a DOTS Mitigation

 

4.5.3

…

     Header: DELETE = (Code=3D0.04)

     Uri-Host: = "host"

     Uri-Path: = ".well-known"

     Uri-Path: = "dots"

     Uri-Path: = "v1"

     Uri-Path: = "config"

     Uri-Path: = "sid=3D123"

 

         &= nbsp;            = Figure 22: DELETE Configuration

 

Regards

 

Jon

------=_NextPart_000_044E_01D3B787.0960E790-- From nobody Fri Mar 9 01:37: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 82C0A129C70 for ; Fri, 9 Mar 2018 01:37:46 -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 OQCOTWKJF_JS for ; Fri, 9 Mar 2018 01:37:44 -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 DDDB8129C6D for ; Fri, 9 Mar 2018 01:37:43 -0800 (PST) Received: from opfedar01.francetelecom.fr (unknown [xx.xx.xx.2]) by opfedar27.francetelecom.fr (ESMTP service) with ESMTP id 3zyMjy51Nlz2y98; Fri, 9 Mar 2018 10:37:42 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.42]) by opfedar01.francetelecom.fr (ESMTP service) with ESMTP id 8B9B8160071; Fri, 9 Mar 2018 10:37:42 +0100 (CET) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM41.corporate.adroot.infra.ftgroup ([fe80::c845:f762:8997:ec86%19]) with mapi id 14.03.0382.000; Fri, 9 Mar 2018 10:37:42 +0100 From: To: Jon Shallow , "dots@ietf.org" Thread-Topic: [Dots] Signal Observe implementation issue Thread-Index: AQG9dsO1PTM2aIJaWUAmMzo5zdfI7QKJz4abo9/N3yCAAAou0A== Date: Fri, 9 Mar 2018 09:37:41 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93300A0E9EF0@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <02c601d3b6bc$4bcf2590$e36d70b0$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93300A0E9D89@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <044d01d3b787$095eebc0$1c1cc340$@jpshallow.com> In-Reply-To: <044d01d3b787$095eebc0$1c1cc340$@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_787AE7BB302AE849A7480A190F8B93300A0E9EF0OPEXCLILMA3corp_" MIME-Version: 1.0 Archived-At: Subject: Re: [Dots] Signal Observe implementation issue 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, 09 Mar 2018 09:37:46 -0000 --_000_787AE7BB302AE849A7480A190F8B93300A0E9EF0OPEXCLILMA3corp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re-, Agree. This is why I went with the change in the draft. FWIW, I submitted an errata available at https://www.rfc-editor.org/errata_= search.php?rfc=3D7252 (Errata ID: 5284). Cheers, Med De : Jon Shallow [mailto:supjps-ietf@jpshallow.com] Envoy=E9 : vendredi 9 mars 2018 10:15 =C0 : BOUCADAIR Mohamed IMT/OLN; dots@ietf.org Objet : RE: [Dots] Signal Observe implementation issue Hi Med, I agree with you that the SHOULD is causing confusion, and a better text fo= r RFC7252 could read The client SHOULD generate tokens in such a way that tokens currently in use for a given source/destination endpoint are unique per request However, I do think that the changes to the draft are the right way to go a= s it gets rid of any possible issues here. [My client code now uses a different tokens for each request] Regards Jon From: Dots [mailto: dots-bounces@ietf.org] On= Behalf Of mohamed.boucadair@orange.com Sent: 09 March 2018 06:51 To: Jon Shallow; dots@ietf.org Subject: Re: [Dots] Signal Observe implementation issue Hi Jon, Seems pragmatic. Please check at: https://github.com/boucadair/draft-ietf-d= ots-signal-channel In the meantime RFC 7252 says the following: A token is intended for use as a client-local identifier for differentiating between concurrent requests (see Section 5.3); it could have been called a "request ID". An implementation that follows this "spirit" would assign distinct tokens f= or concurrent requests involving the same endpoints pair. IMO, the SHOULD text is broken because it assumes that only one request is = likely to be active between two endpoints. Cheers, Med De : Dots [mailto:dots-bounces@ietf.org] De la part de Jon Shallow Envoy=E9 : jeudi 8 mars 2018 10:03 =C0 : dots@ietf.org Objet : [Dots] Signal Observe implementation issue Hi there, We currently cannot support multiple Observe requests per client. A simple= change fixes the issue. In the signal-17 draft, we have Header: GET (Code=3D0.01) Uri-Host: "host" Uri-Path: ".well-known" Uri-Path: "dots" Uri-Path: "v1" Uri-Path: "mitigate" Uri-Query: "cuid=3Ddz6pHjaADkaFTbjr0JGBpw" Uri-Query: "mid=3D12332" Observe: 0 Figure 12: GET to Retrieve a Specific DOTS Mitigation Request Where the resource to Observe is a combination of the Uri-Path: and Uri-Que= ry. RFC7252 supports have the 'request URI' as a combination of both, so t= his is legal. However, in the libcoap I am using, it only supports one Query per Token pe= r Resource (the resource in this case being ".wellknown/dots/v1/mitigate") = for Observe. The Token should remain constant as per RFC7252 5.3.1. Token .. The client SHOULD generate tokens in such a way that tokens currently in use for a given source/destination endpoint pair are unique and then RFC7641 4.1. Request .... The entry in the list of observers is keyed by the client endpoint and the token specified by the client in the request. If an entry with a matching endpoint/token pair is already present in the list (which, for example, happens when the client wishes to reinforce its interest in a resource), the server MUST NOT add a new entry but MUST replace or update the existing one. So, a subsequent different Query using the same Token is overwritten - the = previous Observe is deleted and the new one invoked. The libcoap is correc= t in what it is doing. Can we therefore have this as (to support the monitoring of multiple mitiga= tion requests per client) 4.4.2 ... 'cuid' is a mandatory Uri-Path parameter for GET requests. Uri-Path parameters with empty values MUST NOT be present in a request. The same considerations for manipulating 'cdid' parameter by server- domain DOTS gateways specified in Section 4.4.1 MUST be followed for GET requests. If the DOTS server does not find the 'mid' Uri-Path value conveyed in the GET request in its configuration data for the requesting DOTS client, it MUST respond with a 4.04 (Not Found) error response code. Likewise, the same error MUST be returned as a response to a request to retrieve all mitigation records (i.e., 'mid' Uri-Path is not defined) of a given DOTS client if the DOTS server does not find any mitigation record for that DOTS client. As a reminder, a DOTS client is identified by its identity (e.g., client certificate, 'cuid') and optionally the 'cdid' ... Header: GET (Code=3D0.01) Uri-Host: "host" Uri-Path: ".well-known" Uri-Path: "dots" Uri-Path: "v1" Uri-Path: "mitigate" Uri-Path: "cuid=3Ddz6pHjaADkaFTbjr0JGBpw" Uri-Path: "mid=3D12332" Observe: 0 Figure 12: GET to Retrieve a Specific DOTS Mitigation Request And for consistency 4.4.4 ... 'cuid' and 'mid' are mandatory Uri-Path parameters for DELETE requests. Header: DELETE (Code=3D0.04) Uri-Host: "host" Uri-Path: ".well-known" Uri-Path: "dots" Uri-Path: "v1" Uri-Path: "mitigate" Uri-Path: "cuid=3Ddz6pHjaADkaFTbjr0JGBpw" Uri-Path: "mid=3D123" Figure 16: Withdraw a DOTS Mitigation 4.5.3 ... Header: DELETE (Code=3D0.04) Uri-Host: "host" Uri-Path: ".well-known" Uri-Path: "dots" Uri-Path: "v1" Uri-Path: "config" Uri-Path: "sid=3D123" Figure 22: DELETE Configuration Regards Jon --_000_787AE7BB302AE849A7480A190F8B93300A0E9EF0OPEXCLILMA3corp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Re-,

 

Agree. This is why I went with = the change in the draft.

 

FWIW, I submitted an errata ava= ilable at https:/= /www.rfc-editor.org/errata_search.php?rfc=3D7252 (Errata ID: 5284).

 

Cheers,

Med

 

De : Jon Shallow [mailto:supjps-ietf= @jpshallow.com]
Envoy=E9 : vendredi 9 mars 2018 10:15
=C0 : BOUCADAIR Mohamed IMT/OLN; dots@ietf.org
Objet : RE: [Dots] Signal Observe implementation issue

 

Hi Med,=

&n= bsp;

I agree= with you that the SHOULD is causing confusion, and a better text for RFC72= 52 could read

&n= bsp;

   The client SHOULD = generate tokens in such a way that tokens currently

   in use for a given= source/destination endpoint are unique per request

&n= bsp;

However= , I do think that the changes to the draft are the right way to go as it ge= ts rid of any possible issues here.

&n= bsp;

[My cli= ent code now uses a different tokens for each request]

&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 March 2018 06:51
To: Jon Shallow; dots@ietf.org<= br> Subject: Re: [Dots] Signal Observe implementation issue

 

Hi Jon,

 

Seems pragmatic. Please check a= t: htt= ps://github.com/boucadair/draft-ietf-dots-signal-channel

 

In the meantime RFC 7252 says t= he following:

 

   A toke= n is intended for use as a client-local identifier for

   differ= entiating between concurrent requests (see Section 5.3); it

   could = have been called a "request ID".

 

An implementation t= hat follows this “spirit” would assign distinct tokens for conc= urrent requests involving the same endpoints pair.

 

IMO, the SHOULD tex= t is broken because it assumes that only one request is likely to be active= between two endpoints.

 

Cheers,<= /span>

Med

 

 

Hi there,

 

We currently cannot support mul= tiple Observe requests per client.  A simple change fixes the issue.

 

In the signal-17 draft, we have=

 

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

     Uri-Ho= st: "host"

     Uri-Pa= th: ".well-known"

     Uri-Pa= th: "dots"

     Uri-Pa= th: "v1"

     Uri-Pa= th: "mitigate"

     Uri-Qu= ery: "cuid=3Ddz6pHjaADkaFTbjr0JGBpw"

     Uri-Qu= ery: "mid=3D12332"

     Observ= e: 0

 

     &= nbsp; Figure 12: GET to Retrieve a Specific DOTS Mitigation Request

 

Where the resource to Observe i= s a combination of the Uri-Path: and Uri-Query.  RFC7252 supports have= the ‘request URI’ as a combination of both, so this is legal.&= nbsp;

 

However, in the libcoap I am us= ing, it only supports one Query per Token per Resource (the resource in thi= s case being “.wellknown/dots/v1/mitigate”) for Observe.  = The Token should remain constant as per

 

RFC7252 5.3.1.  Token=

..

   The client SHOULD = generate tokens in such a way that tokens currently

   in use for a given= source/destination endpoint pair are unique

 

and then

 

RFC7641 4.1.  Request=

….

   The entry in the l= ist of observers is keyed by the client endpoint

   and the token spec= ified by the client in the request.  If an entry

   with a matching en= dpoint/token pair is already present in the list

   (which, for exampl= e, happens when the client wishes to reinforce its

   interest in a reso= urce), the server MUST NOT add a new entry but MUST

   replace or update = the existing one.

 

So, a subsequent different Quer= y using the same Token is overwritten – the previous Observe is delet= ed and the new one invoked.  The libcoap is correct in what it is doin= g.

 

Can we therefore have this as (= to support the monitoring of multiple mitigation requests per client)<= /o:p>

 

4.4.2

…

  'cuid' is a mandatory Ur= i-Path parameter for GET requests.

 

   Uri-Path parameters with empty values MUST NOT be present in a

   request.

 

   The same considera= tions for manipulating 'cdid' parameter by server-

   domain DOTS gatewa= ys specified in Section 4.4.1 MUST be followed for

   GET requests.=

 

   If the DOTS server= does not find the 'mid' Uri-Path value conveyed

   in the GET request= in its configuration data for the requesting DOTS

   client, it MUST re= spond with a 4.04 (Not Found) error response code.

   Likewise, the same= error MUST be returned as a response to a request

   to retrieve all mi= tigation records (i.e., 'mid' Uri-Path<= /b> is not

   defined) of a give= n DOTS client if the DOTS server does not find any

   mitigation record = for that DOTS client.  As a reminder, a DOTS client<= /p>

   is identified by i= ts identity (e.g., client certificate, 'cuid') and

   optionally the 'cd= id'

…

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

     Uri-Ho= st: "host"

     Uri-Pa= th: ".well-known"

     Uri-Pa= th: "dots"

     Uri-Pa= th: "v1"

     Uri-Pa= th: "mitigate"

     Uri-Path: "cuid=3Ddz6pHjaADkaFTbjr0J= GBpw"

     Uri-Path: "mid=3D12332"

     Observ= e: 0

 

     &= nbsp; Figure 12: GET to Retrieve a Specific DOTS Mitigation Request

 

And for consistency<= /span>

 

4.4.4

…

   'cuid' and 'mid' a= re mandatory Uri-Path parameters fo= r DELETE

   requests.

 

     Header= : DELETE (Code=3D0.04)

     Uri-Ho= st: "host"

     Uri-Pa= th: ".well-known"

     Uri-Pa= th: "dots"

     Uri-Pa= th: "v1"

     Uri-Pa= th: "mitigate"

     Uri-Path: "cuid=3Ddz6pHjaADkaFTbjr0J= GBpw"

     Uri-Path: "mid=3D123"

 

     &= nbsp;            &nb= sp;Figure 16: Withdraw a DOTS Mitigation

 

4.5.3

…

     Header= : DELETE (Code=3D0.04)

     Uri-Ho= st: "host"

     Uri-Pa= th: ".well-known"

     Uri-Pa= th: "dots"

     Uri-Pa= th: "v1"

     Uri-Pa= th: "config"

     Uri-Path: "sid=3D123"

 

     &= nbsp;           &nbs= p;    Figure 22: DELETE Configuration

 

Regards

 

Jon

--_000_787AE7BB302AE849A7480A190F8B93300A0E9EF0OPEXCLILMA3corp_-- From nobody Fri Mar 9 05:58: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 1EEB9126CF9 for ; Fri, 9 Mar 2018 05:58:08 -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 mRvV2BFt-A-U for ; Fri, 9 Mar 2018 05:58:06 -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 52EEA126C3D for ; Fri, 9 Mar 2018 05:58:06 -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 w29Dw5Dh015785 for ; Fri, 9 Mar 2018 08:58:05 -0500 DKIM-Filter: OpenDKIM Filter v2.11.0 taper.sei.cmu.edu w29Dw5Dh015785 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cert.org; s=yc2bmwvrj62m; t=1520603885; bh=SMmxzy/qJxCIZLoRhNHf45lOWfOjXEkK+AHCnpYNaPo=; h=From:To:Subject:Date:From; b=PsRHD/D0L0INoUaOQN+bIlnWlw87qG9ES4yhLBsJazaO3atmyMZwwTxnwUt8FaE1H miC8lw+XKzY+kw/ZNY8AjDWNar/r9Djh39FqVPyUnCFD/pScTgjrWGhwpo9RYqkVd3 OmkPx+pOW/+ViwyGVfqQFdk2voGwQ87VzMQynQRY= 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 w29Dw2Sd031930 for ; Fri, 9 Mar 2018 08:58:02 -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, 9 Mar 2018 08:58:02 -0500 From: Roman Danyliw To: "dots@ietf.org" Thread-Topic: Draft agenda for IETF 101 Thread-Index: AdO3rllAjFIlhGRZSRGml4FnLtTNZw== Date: Fri, 9 Mar 2018 13:58:01 +0000 Message-ID: <359EC4B99E040048A7131E0F4E113AFC0137F73141@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] Draft agenda for IETF 101 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, 09 Mar 2018 13:58:08 -0000 Hello WG! The DOTS WG is scheduled to meet on Tuesday, March 20, 2018 from 15:50-18:2= 0. A draft agenda has been posted [1]. --[ draft agenda ]-- 1. Note well, logistics and introduction (chairs, 5 min) 2. Hackathon Report(s) (Hackathon participants/TBD, 20 min) 3. Additional Implementation Reports (open mic, 10 min) 4. Protocol drafts (30 min) (a) draft-ietf-dots-signal-channel-17 (Mohamed Boucadair) (b) draft-ietf-dots-data-channel-13 (Mohamed Boucadair) 5. Architecture (draft-ietf-dots-architecture-05) (10 min) 6. Use Cases (draft-ietf-dots-use-cases-09) (10 min) 7. Closing (chairs, 5 min) --[ end ]-- Regards, Roman [1] https://datatracker.ietf.org/doc/agenda-101-dots/ From nobody Thu Mar 15 07:46: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 43E1C126BF3 for ; Thu, 15 Mar 2018 07:46:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.289 X-Spam-Level: X-Spam-Status: No, score=-4.289 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, SPF_PASS=-0.001, T_FILL_THIS_FORM_SHORT=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 vYx6j2PfHgb8 for ; Thu, 15 Mar 2018 07:46:45 -0700 (PDT) Received: from usplmg21.ericsson.net (usplmg21.ericsson.net [198.24.6.65]) (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 D527F12D88A for ; Thu, 15 Mar 2018 07:46:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1521125204; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=pSdPCH/FL0oJQ/cWVSOG8yXtI+BkjhPllS+Kh08nVbA=; b=EgMrAvv+ZVLN3x0LtMU78cW4EmoDimDFTWpePnCff+OFfoZPl+eJiGj5rgNr5typ tQTGO4XiJvWU6IvDn5AaJYCSzU2Y/vdxutC1ajsZBe/6x1+I6+bAecsX3iOlk74r JGxidmHqNgQwty1wXLXolcie+1NpOVrpBl55csLZy9Y=; X-AuditID: c6180641-81dff70000007a40-d3-5aaa87531125 Received: from EUSAAHC005.ericsson.se (Unknown_Domain [147.117.188.87]) by usplmg21.ericsson.net (Symantec Mail Security) with SMTP id F6.8D.31296.3578AAA5; Thu, 15 Mar 2018 15:46:43 +0100 (CET) Received: from EUSAAMB107.ericsson.se ([147.117.188.124]) by EUSAAHC005.ericsson.se ([147.117.188.87]) with mapi id 14.03.0382.000; Thu, 15 Mar 2018 10:46:42 -0400 From: Daniel Migault To: "dots@ietf.org" Thread-Topic: comments on the use case draft 09 Thread-Index: AdO8a1xL+QahbCxNRomdfKBAyFn4pQ== Date: Thu, 15 Mar 2018 14:46:41 +0000 Message-ID: <2DD56D786E600F45AC6BDE7DA4E8A8C118DF3250@eusaamb107.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.223] Content-Type: multipart/alternative; boundary="_000_2DD56D786E600F45AC6BDE7DA4E8A8C118DF3250eusaamb107erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrNLMWRmVeSWpSXmKPExsUyuXRPuG5w+6oogx291hZr3xxhdWD0WLLk J1MAYxSXTUpqTmZZapG+XQJXxqHON4wF8z/zVizcOoO9gfHKA+4uRk4OCQETiZc3z7B1MXJx CAkcYZRofb+GGcJZziixf+UiRpAqNgEjibZD/ewgtoiAssTOprtgcWEBLYnOCzeg4voSq5bN ZIGw9SQeHzkPFOfgYBFQlTjzWgkkzCvgK/GwYyMziM0oICbx/dQaJhCbWUBc4taT+UwQBwlI LNlznhnCFpV4+fgfK4StLPFo4Q9GiPp8iVsffrBCzBSUODnzCcsERsFZSEbNQlI2C0kZRFxH YsHuT2wQtrbEsoWvmWHsMwceMyGLL2BkX8XIUVpckJObbmS4iREY5Mck2Bx3MO7t9TzEKMDB qMTD+z9qVZQQa2JZcWXuIUYJDmYlEV6fAqAQb0piZVVqUX58UWlOavEhRmkOFiVx3nOevFFC AumJJanZqakFqUUwWSYOTqkGxm3Hem9OW/05cNUkWyEdLrva5PCU8MS/vheWtHP3nHvnv+G5 c7Fv2LO3x25OdM6OcPx66o/I3A+uNhWpb68nRBhlXffnCMlXWLns6nv/G8ufrBaTfsFdd9R5 NsuPRxsX6T0+zZmwc8bTiM78fx0T71+rS11pGCt82Z7zSdd33dlZKqGntzFc/6DEUpyRaKjF XFScCAADhZArbgIAAA== Archived-At: Subject: [Dots] comments on the use case draft 09 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, 15 Mar 2018 14:46:53 -0000 --_000_2DD56D786E600F45AC6BDE7DA4E8A8C118DF3250eusaamb107erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, Please find my personal comments on the current draft. Co-authors have deci= ded to bring their comments to the WG mailing list so the WG can be informe= d of the evolution of the draft. A version is expected to come very soon. Feel free to comment! Yours, Daniel looking at the different inter domain use cases, my feeling is that the mos= t generic use case is the use case described in the current section 3.1.2.= 2. "MSSP as an end-customer requesting overflow DDoS mitigation assistance= from other MSSPs". The use case "Upstream Transit Providers Offering DDoS = Mitigation Services" seems to me related to the "Overlay MSSPs Offering DDo= S Mitigation Services" with the addition that the ddos mitigation is bound = to a specific link. This constraint, in case multiple links adds some manag= ements between providers. With that perspective, I would favor to start with the use case described i= n the current section 3.1.2.2. "MSSP as an end-customer requesting overfl= ow DDoS mitigation assistance from other MSSPs" and then follow up with the= "Upstream Transit Providers Offering DDoS Mitigation Services" as another = use case. I would expect the "Overlay MSSPs Offering DDoS Mitigation Servic= es" to have the complete description that is currently provided in section = 3.1.1.1 while the "Upstream Transit Providers Offering DDoS Mitigation Serv= ices" only document the additional constraint of binding ddos mitigation to= the upstream link, the motivation for adding this constraints as well as t= he additional management overhead associated to that constraint. I do not t= hink that repeating the complete steps as currently described in 3.1.1.1. w= ould be necessary since these would already be described before. In my opinion, reducing the number of use cases would ease the reading of t= he document. These are the use cases I would consider, each being summed up= into a single section/subsection. * Use Case1 : "End-customer with an overlay DDoS mitigation managed securi= ty service provider (MSSP)" (current section 3.1.2.2) * Use Case2: Upstream Transit Providers Offering DDoS Mitigation Services (= current section 3.1.1.) * Use Case 3: DDoS Orchestration (current section 3.2.3) I read section 3.1.3 as specific implementations of Use Case 1-2-3, and As = such I would split the information of section section 1-2-3 into the sectio= n related in each Use case. I read section MSSP as an end-customer requesting overflow DDoS mitigation = assistance from other MSSPs ( current section 3.1.2.2.) as redundant with 3= .2.3. DDoS Orchestration, and so remove this subsection. I read section 3.2.2. "Home Network DDoS Detection Collaboration for ISP ne= twork management" as very close to 3.1.1.1. End-customer with a single ups= tream transit provider offering DDoS mitigation services or 3.1.1.2. End-c= ustomer with multiple upstream transit providers offering DDoS mitigation s= ervices. I would expect that all these section be merged into UseCase2. I also agree with the text in section 3.2. """ The DOTS communications model in these scenarios are largely identical to that described in Section 3.1, except that all the DOTS communications take place within the same span of administrative control and the same network. These variations are mainly of interest from the operational point of view, as they illustrate processes, procedures, and topological details which are externalities from the standpoint of the DOTS ecosystem, but which are of great importance for network operators and DDoS mitigation service providers. """ As a result, I see this section as duplicating of the previous use cases. I= would rather add the complementary information as a note added to each use= case and remove the distinction between internal external. This would resu= lt in restructuring the current section 3 as: * section 3.1 use case 1 * section 3.2 use case 2 * section 3.3 use case 3 Eventually an additional use case may be added Use Case 2b: where the initi= ation of the DDoS mitigation is handled by the upstream provider instead of= the CPE. Other comments are added directly in the text: DOTS R. Dobbins Internet-Draft Arbor Networks Intended status: Informational D. Migault Expires: May 17, 2018 Ericsson S. Fouant R. Moskowitz HTT Consulting N. Teague Verisign L. Xia Huawei K. Nishizuka NTT Communications November 13, 2017 Use cases for DDoS Open Threat Signaling draft-ietf-dots-use-cases-09 Abstract The DDoS Open Threat Signaling (DOTS) effort is intended to provide a protocol to facilitate interoperability between multivendor DDoS mitigation solutions and services. This document presents use cases which describe the interactions expected between the DOTS components as well as DOTS messaging exchanges. The purpose of describing use cases is to identify the interacting DOTS components, how they collaborate and what are the types of information to be exchanged. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on May 17, 2018. Dobbins, et al. Expires May 17, 2018 [Page 1] Internet-Draft DOTS Use Cases November 2017 Copyright Notice Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Terminology and Acronyms . . . . . . . . . . . . . . . . . . 3 2.1. Requirements Terminology . . . . . . . . . . . . . . . . 4 3. Use Cases Scenarios . . . . . . . . . . . . . . . . . . . . . 4 3.1. Inter-domain Use Cases . . . . . . . . . . . . . . . . . 4 3.1.1. Upstream Transit Providers Offering DDoS Mitigation Services . . . . . . . . . . . . . . . . . . . . . . 5 3.1.2. Overlay MSSPs Offering DDoS Mitigation Services . . . 10 3.1.3. Examples of DOTS clients integrated with applications, services, and network infrastructure devices . . . . . . . . . . . . . . . . . . . . . . . 12 3.2. Intra-domain Use Cases . . . . . . . . . . . . . . . . . 13 3.2.1. Suppression of outbound DDoS traffic originating from a consumer broadband access network . . . . . . . . . 14 3.2.2. Home Network DDoS Detection Collaboration for ISP network management . . . . . . . . . . . . . . . . . 16 3.2.3. DDoS Orchestration . . . . . . . . . . . . . . . . . 19 4. Security Considerations . . . . . . . . . . . . . . . . . . . 21 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 22 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 22 7.1. Normative References . . . . . . . . . . . . . . . . . . 22 7.2. Informative References . . . . . . . . . . . . . . . . . 22 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 1. Introduction Currently, distributed denial-of-service (DDoS) attack mitigation solutions are largely based upon siloed, proprietary communications schemes which result in vendor lock-in. As a side-effect, this makes the configuration, provisioning, operation, and activation of these Dobbins, et al. Expires May 17, 2018 [Page 2] Internet-Draft DOTS Use Cases November 2017 solutions a highly manual and often time-consuming process. Additionally, coordination of multiple DDoS mitigation solutions simultaneously engaged in defending the same organization (resources) against DDoS attacks is fraught with both technical and process- related hurdles. This greatly increase operational complexity and often results in suboptimal DDoS attack mitigation efficacy. The DDoS Open Threat Signaling (DOTS) effort is intended to specify a protocol that facilitates interoperability between multivendor DDoS mitigation solutions and ensures more automation in term of mitigation requests and attack characterization patterns. As DDoS solutions are broadly heterogeneous among vendors, the primary goal of DOTS is to provide high-level interaction amongst differeing DDoS nits solutions, such as initiating or terminating DDoS mitigation assistance. It should be noted that DOTS is not intended toperform orchestration nits functions; rather, DOTS is intended to allowdevices, services, and nits applications to request DDoS attack mitigation assistance and receive mitigation status updates. These use cases are expected to provide inputs for the design of the DOTS protocol(s). 2. Terminology and Acronyms This document makes use of the terms defined in [I-D.ietf-dots-requirements]. In addition, this document introduces the following terms: Inter-domain: a DOTS communications relationship between distinct organizations with separate spans of administrative control. Typical inter-domain DOTS communication relationships would be between a DDoS mitigation service provider and an end-customer who requires DDoS mitigation assistance; between multiple DDoS mitigation service providers coordinating mutual defense of a mutual end-customer; or between DDoS mitigation service providers which are requesting additional DDoS mitigation assistance in for attacks which exceed their inherent DDoS mitigation capacities and/or capabilities. Intra-domain: a DOTS communications relationship between various (network) elements that are owned and operated by the same administrative entity. A typical intra-domain DOTS communications relationship would be between DOTS agents [I-D.ietf-dots- requirements] within the same organization. Dobbins, et al. Expires May 17, 2018 [Page 3] Internet-Draft DOTS Use Cases November 2017 2.1. Requirements Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. 3. Use Cases Scenarios This section provides a high-level description of scenarios addressed by DOTS. In both sub-sections, the scenarios are provided in order to illustrate the use of DOTS in typical DDoS attack scenarios. They are not definitive, and other use cases are expected to emerge with widespread DOTS deployment. All scenarios present a coordination between the targeted organization, the DDoS attack telemetry and the mitigator. The coordination and communication between these entities depends, for example, on the characteristic or functionality of the entity itself, the reliability of the information provided by DDoS attack telemetry, and the business relationship between the DDoS target domain and the mitigator. More explicitly, in some cases, the DDoS attack telemetry may simply activate a DDoS mitigation, whereas in other cases, it may collaborate by providing some information about an attack. In some cases, the DDoS mitigation may be orchestrated, which includes selecting a specific appliance as well as starting/ending a mitigation. 3.1. Inter-domain Use Cases Inter-domain DOTS deployment scenarios encompass two or more distinct spans of administrative control. A typical inter-domain DOTS deployment may consist of an endpoint network such as an Internet- connected enterprise requesting DDoS mitigation assistance from one or more upstream transit providers offering DDoS mitigation services, or from a topologically-distant MSSP offering cloud-based overlay DDoS mitigation services. DOTS may also be used to facilitate coordination of DDoS mitigation activities between mitigation providers. Coordination between organizations making use of DOTS in such scenarios is necessary. Along with DOTS-specific tasks such as DOTS peering and validating the exchange of DOTS messaging between the relevant organizations, externalities relating to routing advertisements, authoritative DNS records (for DNS-based diversion), network access policies for DOTS nodes, service-level agreements (SLAs), and DDoS mitigation provisioning are required. Dobbins, et al. Expires May 17, 2018 [Page 4] Internet-Draft DOTS Use Cases November 2017 3.1.1. Upstream Transit Providers Offering DDoS Mitigation Services The use-cases in this section reflect scenarios in which the immediate upstream transit network(s) offer DDoS mitigation services to their end-customers. The DOTS communications models in these use- cases are largely identical with that decribed in Section 3.1.1.1, with the exceptions of Section 3.1.1.4 and Section 3.1.1.5. These variations are mainly of interest from the operational point of view, as they illustrate processes, procedures, and topological details which are externalities from the standpoint of the DOTS ecosystem, but which are of great importance for network operators and DDoS mitigation service providers. 3.1.1.1. End-customer with a single upstream transit provider offering DDoS mitigation services In this scenario, an enterprise network with self-hosted Internet- facing properties such as Web servers, authoritative DNS servers, and VoIP PBXes has an intelligent DDoS mitigation system (IDMS) deployed to protect those servers and applications from DDoS attacks. In addition to their on-premise DDoS defense capability, they have contracted with their Internet transit provider for DDoS mitigation services which threaten to overwhelm their transit link bandwidth. The IDMS is configured such that if the incoming Internet traffic volume exceeds 50% of the provisioned upstream Internet transit link capacity, the IDMS will request DDoS mitigation assistance from the upstream transit provider. The requests to trigger, manage, and finalize a DDoS mitigation between the enterprise IDMS and the transit provider is performed using DOTS. The enterprise IDMS implements a DOTS client while the transit provider implements a DOTS server which is integrated with their DDoS mitigation orchestration system. When the IDMS detects an inbound DDoS attack targeting the enterprise servers and applications, it immediately begins mitigating the attack. During the course of the attack, the inbound traffic volume exceeds the 50% threshold; the IDMS DOTS client signals the DOTS server on the upstream transit provider network to initiate DDoS mitigation. The DOTS server signals the DOTS client that it can service this request, and mitigation is initiated on the transit provider network. Over the course of the attack, the DOTS server on the transit provider network periodically signals the DOTS client on the enterprise IDMS in order to provide mitigation status information, Dobbins, et al. Expires May 17, 2018 [Page 5] Internet-Draft DOTS Use Cases November 2017 statistics related to DDoS attack traffic mitigation, and related information. Once the DDoS attack has ended, the DOTS server signals the enterprise IDMS DOTS client that the attack has subsided. The enterprise IDMS then requests that DDoS mitigation services on the upstream transit provider network be terminated. The DOTS server on the transit provider network receives this request, communicates with the transit provider orchestration system controlling its DDoS mitigation system to terminate attack mitigation, and once the mitigation has ended, confirms the end of upstream DDoS mitigation service to the enterprise IDMS DOTS client. Note that communications between the enterprise DOTS client and the upstream transit provider DOTS server may take place in-band within the main Internet transit link between the enterprise and the transit provider; out-of-band via a separate, dedicated wireline network link utilized solely for DOTS signaling; or out-of-band via some other form of network connectivity such as a third-party wireless 4G network link. The following is an overview of the DOTS communication model for this use-case: (a) A DDoS attack is initiated against online properties of an organization which has deployed a DOTS-client-capable IDMS. (b) The IDMS detects, classifies, and begins mitigating the DDoS attack. (c) The IDMS determines that its capacity and/or capability to mitigate the DDoS attack is insufficient, and utilize its DOTS client functionality to send a DOTS mitigation service initiation request to one or more DOTS servers residing on the upstream transit networks. This DOTS mitigation service initiation request is automatically initiated by the DOTS client. (d) The DOTS servers which receive the DOTS mitigation service initiation requests determine that they have been configured to honor requests from the requesting DOTS client, and initiate situationally- appropriate DDoS mitigation service. (e) The DOTS servers transmit a DOTS service status message to the DOTS client indicating that upstream DDoS mitigation service has been initiated. (f) While DDoS mitigation services are active, the DOTS servers regularly transmit DOTS mitigation status updates to the DOTS client. Dobbins, et al. Expires May 17, 2018 [Page 6] Internet-Draft DOTS Use Cases November 2017 (g) While DDoS mitigation services are active, the DOTS client may optionally regularly transmit DOTS mitigation efficacy updates to the DOTS server. (h) When the upstream DDoS mitigators determine that the DDoS attack has ceased, they indicate this change in status to the DOTS server. I see that the upstream provides measurements, but it seems that the = end of the attack should be determined by the client based on the indicator= s of the server. More specifically, when an attack reaches picks every 15 m= in, maybe the client is better of remaining under the protection of the ups= tream mitigation. Maybe we could clarify this point but to me it could be r= emoved. (i) The DOTS server transmist a DOTS mitigation status update to the DOTS client indicating that the DDoS attack has ceased. (j) The DOTS client transmits a DOTS mitigation service termination request to the DOTS server. (k) The DOTS server terminates DDoS mitigation service. I do not think that l and m brings much information to understand th= e use-case. It seems more a protocol issue when both parties must ensure th= ey are in synch. I would remove l and m . (l) The DOTS server transmis a DOTS mitigation status update to the DOTS client indicating that DDoS mitigation services have been terminated. (m) The DOTS client transmits a DOTS mitigation termination status acknowledgement to the DOTS servers. 3.1.1.2. End-customer with multiple upstream transit providers offering DDoS mitigation services This scenario shares many characteristics with Section 3.1.1.1, but with the key difference that the enterprise in question is multi- homed, i.e., has two or more upstream transit providers, and that they all provide DDoS mitigation services. In most cases, the communications model for a multi-homed model would be the same as in the single-homed model, merely duplicated in parallel. However, if two or more of the upstream transit providers have entered into a mutual DDoS mitigation agreement and have established DOTS peering relationships, DDoS mitigation status messages may exchanged between their respective DOTS servers in order to provide a more complete picture of the DDoS attack scope. This will also allow for either automated or operator-assisted programmatic cooperative DDoS mitigation activities on the part of the DOTS-peered transit providers. The addtional DOTS communications between the upstream transit providers will consist of mitigation start, mitigation status, and mitigation termination messages. My very personal opinion is that this use case is very similar and st= raight forward to the previous one. I would remove this section. Dobbins, et al. Expires May 17, 2018 [Page 7] Internet-Draft DOTS Use Cases November 2017 3.1.1.3. End-customer with multiple upstream transit providers, but only a single upstream transit provider offering DDoS mitigation services This scenario is similar to that outlined in Section 3.1.1.2; however, only one of the upstream transit providers in question offers DDoS mitigation services. In this situation, the enterprise would cease advertising the relevant network prefixes via the transit providers which do not provide DDoS mitigation services - or, in the case where the enterprise does not control its own routing, request that the upstream transit providers which do not offer DDoS mitigation services stop advertising the relevant network prefixes on their behalf. Once it has been determined that the DDoS attack has ceased, the enterprise once again announces the relevant routes to the upstream transit providers which do not offer DDoS mitigation services, or requests that they resume announcing the relevant routes on behalf of the enterprise. Note that falling back to a single transit provider has the effect of reducing available inbound transit bandwidth during a DDoS attack. Without proper planning and sufficient provisioning of both the link capacity and DDoS mitigation capacity of the sole transit provider offering DDoS mitigation services, this reduction of available bandwidth could lead to network link congestion caused by legitimate inbound network traffic. Therefore, careful planning and provisioning of both upstream transit bandwidth as well as DDoS mitigation capacity is required in scenarios of this nature. The withdrawal and announcement of routing prefixes described in this use-case falls outside the scope of DOTS, although they could conceivably be triggered as a result of provider-specific orchestration triggered by the receipt of specific DOTS messages from the enterprise in question. 3.1.1.2 and 3.1.1.3 describes a need to manage mitigation services wh= en those are associated to a specific link. I do not think that is necessar= y to have these examples, but I agree that 3.1.1.3 may be interesting. If w= e decide to keep them I would merge them into a single section. 3.1.1.4. End-customer with an upstream transit provider offering DDoS mitigation services on an ongoing basis This scenario is similar to that described in Section 3.1.1.1, except that due to the lack of a capable local IDMS solution, strict uptime requirements, or other considerations, the end-customer has previously arranged for continuous active DDoS mitigation coverage; thus, the concepts of initiating or terminating DDoS mitigation services do not apply. During an attack, the DOTS server on the upstream transit provider network immediately notifies the DOTS client on the enterprise Dobbins, et al. Expires May 17, 2018 [Page 8] Internet-Draft DOTS Use Cases November 2017 network about the attack and periodically signals the DOTS client in order to provide mitigation status information and related information. The end-customer may then use this information to add capacity or implement configuration changes intended to increase resilience, to plan maintenance windows or changes to routing policies, etc. 3.1.1.5. End-customer with an upstream transit provider offering DDoS mitigation services, but DDoS mitigation service is refused This scenario is similar to that described in Section 3.1.1.1, except that the upstream transit provider is unable to honor the DDoS mitigation service request from the end-customer due to mitigation capacity limitations, technical faults, or other circumstances. The end-customer DOTS client may be configured to make repeated attempts to engage DDoS mitigation service from the refusing provider, or alternately may be configured to request DDoS mitigation service from alternate providers. I believe that the text above is sufficient and shoudl be moved to 3= .1.1.1. The text below is straight forward. The following is an overview of the DOTS communication model for this use-case: (a) A DDoS attack is initiated against online properties of an organization which has deployed a DOTS-client-capable IDMS. (b) The IDMS detects, classifies, and begins mitigating the DDoS attack. (c) The IDMS determines that its capacity and/or capability to mitigate the DDoS attack is insufficient, and utilizes its DOTS client functionality to send a DOTS mitigation service initiation request to a DOTS server residing on an upstream transit network. (d) The DOTS servers which receives the DOTS mitigation service initiation requests determines that it has been configured to honor requests from the requesting DOTS client, and attempts to initiate situationally-appropriate DDoS mitigation service. (e) The DDoS mitigators on the upstream network report back to the DOTS server that they are unable to initiate DDoS mitigation service for the requesting organization due to mitigation capacity constraints, bandwidth constraints, functionality constraints, hardware casualties, or other impediments. (f) The DOTS servers transmits a DOTS service status message to the DOTS client indicating that upstream DDoS mitigation service cannot be initiated as requested. Dobbins, et al. Expires May 17, 2018 [Page 9] Internet-Draft DOTS Use Cases November 2017 (g) The DOTS client may optionally regularly re-transmit DOTS mitigation status request messages to the DOTS server until receiving acknowledgement that DDos mitigation services have been initiated. (h) The DOTS client may optionally transmit a DOTS mitigation service initiation request to a DOTS server associated with a configured fallback upstream DDoS mitigation service. Multiple fallback DDoS mitigation services may optionally be configured. (i) The process describe above cyclically continues until the DDoS mitigation service request is fulfilled; the DOTS client determines that the DDoS attack volume has decreased to a level and/or complexity which it can successfully mitigate; the DDoS attack has ceased; or manual intervention by personnel of the requesting organization has taken place. 3.1.2. Overlay MSSPs Offering DDoS Mitigation Services The use-cases in this section reflect scenarios in which topologically-distant managed security service providers (MSSPs) offer DDoS mitigation services to end-customers. The DOTS communications models in these use-cases are largely identical with that decribed in Section 3.1.1.1. These variations are mainly of interest from the operational point of view, as they illustrate processes, procedures, and topological details which are externalities from the standpoint of the DOTS ecosystem, but which are of great importance for network operators and DDoS mitigation service providers. 3.1.2.1. End-customer with an overlay DDoS mitigation managed security service provider (MSSP) This use case details an enterprise that has a local DDoS detection and classification capability and may or may not have an on-premise mitigation capability. The enterprise is contracted with an overlay DDoS mitigation MSSP, topologically distant from the enterprise network (i.e., not a direct upstream transit provider), which can redirect (divert) traffic away from the enterprise, provide DDoS mitigation services services, and then forward (re-inject) legitimate traffic to the enterprise on an on-demand basis. In this scenario, diversion of Internet traffic destined for the enterprise network into the overlay DDoS mitigation MSSP network is typically accomplished via eBGP announcements of the relevant enterprise network CIDR blocks, or via authoritative DNS subdomain-based mechanisms (other mechanisms are not precluded, these are merely the most common ones in use today). Dobbins, et al. Expires May 17, 2018 [Page 10] Internet-Draft DOTS Use Cases November 2017 The enterprise determines thresholds at which a request for mitigation is triggered indicating to the MSSP that inbound network traffic should be diverted into the MSSP network and that DDoS mitigation should be initiated. The enterprise may also elect to manually request diversion and mitigation via the MSSP network as desired. The communications required to initiate, manage, and terminate active DDoS mitigation by the MSSP is performed using DOTS. The enterprise DDoS detection/classification system implements a DOTS client, while the MSSP implements a DOTS server integrated with its DDoS mitigation orchestration system. One or more out-of-band methods for initiating a mitigation request, such as a Web portal, a smartphone app, or voice support hotline, may also be made available by the MSSP. When an attack is detected, an automated or manual DOTS mitigation request is generated by the enterprise and sent to the MSSP. The enterprise DOTS mitigation request is processed by the MSSP DOTS server, which validates the origin of the request and passes it to the MSSP DDoS mitigation orchestration system, which then initiates active DDoS mitigation. This action will usually involve the diversion of all network traffic destined for the targeted enterprise into the MSSP DDoS mitigation network, where it will be subjected to further scrutiny, with DDoS attack traffic filtered by the MSSP. Successful mitigation of the DDoS attack will not only result preserving the availability of services and applications resident on the enterprise network, but will also prevent DDoS attack traffic from ingressing the networks of the enterprise upstream transit providers and/or peers. The MSSP should signal via DOTS to the enterprise that a mitigation request has been received and acted upon, and should also include an update of the mitigation status. The MSSP may respond periodically with additional updates on the mitigation status to in order to enable the enterprise to make an informed decision on whether to maintain or terminate the mitigation. An alternative approach would be for the DOTS client mitigation request to include a time to live (TTL) for the mitigation, which may also be extended by the client should the attack still be ongoing as the TTL reaches expiration. A variation of this use case may be that the enterprise is providing a DDoS monitoring and analysis service to customers whose networks may be protected by any one of a number of third-party providers. The enterprise in question may integrate with these third-party providers using DOTS and signal accordingly when a customer is attacked - the MSSP may then manage the life-cycle of the attack mitigation on behalf of the enterprise. Dobbins, et al. Expires May 17, 2018 [Page 11] Internet-Draft DOTS Use Cases November 2017 3.1.2.2. MSSP as an end-customer requesting overflow DDoS mitigation assistance from other MSSPs This is a more complex use-case involving multiple DDoS MSSPs, whether transit operators, overlay MSSPs, or both. In this scenario, an MSSP has entered into a pre-arranged DDoS mitigation assistance agreement with one or more other DDoS MSSPs in order to ensure that sufficient DDoS mitigation capacity and/or capabilities may be activated in the event that a given DDoS attack threatens to overwhelm the ability of a given DDoS MSSP to mitigate the attack on its own. BGP-based diversion (including relevant Letters of Authorization, or LoAs), DNS-based diversion (including relevant LoAs), traffic re- injection mechanisms such as Generic Routing Encapsulation (GRE) tunnels, provisioning of DDoS orchestration systems, et. al,. must be arranged in advance between the DDoS MSSPs which are parties to the agreement. They should also be tested on a regular basis. When a DDoS MSSP which is party to the agreement is nearing its capacity or ability to mitigate a given DDoS attack traffic, the DOTS client integrated with the MSSP DDoS mitigation orchestration system signals partner MSSPs to initiate network traffic diversion and DDoS mitigation activities. Ongoing attack and mitigation status messages may be passed between the DDoS MSSPs, and between the requesting MSSP and the ultimate end-customer of the attack. Once the requesting DDoS MSSP is confident that the DDoS attack has either ceased or has fallen to levels of traffic/complexity which they can handle on their own, the requesting DDoS MSSP DOTS client sends mitigation termination requests to the participating overflow DDoS MSSPs. 3.1.3. Examples of DOTS clients integrated with applications, services, and network infrastructure devices The use-cases in this section reflect scenarios in which DOTS clients are integrated into devices and services which have heretofore been unable to request DDoS mitigation services on an as-needed basis. The DOTS communications models in these use-cases are largely identical with those decribed in {{interdomain-use-cases}. These variations are mainly of interest because they illustrate how DOTS allows DDoS mitigation services to expand in scope and utility. Dobbins, et al. Expires May 17, 2018 [Page 12] Internet-Draft DOTS Use Cases November 2017 3.1.3.1. End-customer operating an application or service with an integrated DOTS client In this scenario, a Web server has a built-in mechanism to detect and classify DDoS attacks, which also incorporates a DOTS client. When an attack is detected, the self-defense mechanism is activated, and local DDoS mitigation is initiated. The DOTS client built into the Web server has been configured to request DDoS mitigation services from an upstream transit provider or overlay MSSP once specific attack traffic thresholds have been reached, or certain network traffic conditions prevail. Once attack traffic subsides below configured thresholds and/or the specified network traffic conditions no longer apply, the DOTS client requests the termination of DDoS mitigation services. 3.1.3.2. End-customer operating a CPE network infrastructure device with an integrated DOTS client Similar to the above use-case featuring applications or services with built-in DDoS attack detection/classification and DOTS client capabilities, in this scenario, an end-customer network infrastructure CPE device such as a router, layer-3 switch, firewall, IDS/IPS, Web application firewall or load-balancer incorporates both the functionality required to detect and classify incoming DDoS attacks as well as DOTS client functionality. 3.1.3.3. End-customer with an out-of-band smartphone application featuring DOTS client capabilities This scenario would typically apply in a small office or home office (SOHO) setting, where the end-customer does not have CPE equipment or software capable of detecting/classifying/mitigating DDoS attack, yet still has a requirement for on-demand DDoS mitigation services. A smartphone application containing a DOTS client would be provided by the upstream transit mitigation provider or overlay DDoS MSSP to the SOHO end-customer; this application would allow a manual 'panic- button' to request the initiation and termination of DDoS mitigation services. The end-customer DOTS client application will display mitigation status information while DDoS mitigation activities are taking place. 3.2. Intra-domain Use Cases While many of the DOTS-specific elements of inter-domain DOTS deployment scenarios apply to intra-domain scenarios, it is expected that many externalities such as coordination of and authorization for routing advertisements and authoritative DNS updates may be automated Dobbins, et al. Expires May 17, 2018 [Page 13] Internet-Draft DOTS Use Cases November 2017 to a higher degree than is practicable in inter-domain scenarios, given that the scope of required activities and authorizations are confined to a single organization. In theory, provisioning and change-control related both to DOTS itself as well as relevant externalities may require less administrative overhead and less implementation lead-times. The scope of potential DDoS mitigation actions may also be broader in intra-organizational scenarios, as presumably an organization will have a higher degree of autonomy with regards to both techically and administratively feasible activities. The DOTS communications model in these scenarios are largely identical to that described in Section 3.1, except that all the DOTS communications take place within the same span of administrative control and the same network. These variations are mainly of interest from the operational point of view, as they illustrate processes, procedures, and topological details which are externalities from the standpoint of the DOTS ecosystem, but which are of great importance for network operators and DDoS mitigation service providers. 3.2.1. Suppression of outbound DDoS traffic originating from a consumer broadband access network While most DDoS defenses concentrate on inbound DDoS attacks ingressing from direct peering links or upstream transit providers, the DDoS attack traffic in question originates from one or more Internet-connected networks. In some cases, compromised devices residing on the local networks of broadband access customers are used to directly generate this DDoS attack traffic; in others, misconfigured devices residing on said local customer networks are exploited by attackers to launch reflection/amplification DDoS attacks. In either scenario, the outbound DDoS traffic emanating from these devices can be just as disruptive as an inbound DDoS attack, and can cause disruption for substantial proportions of the broadband access network operator's customer base. Some broadband access network operators provide CPE devices (DSL modems/routers, cablemodems, FTTH routers, etc.) to their end- customers. Others allow end-customers to provide their own CPE devices. Many will either provide CPE devices or allow end-customers to supply their own. Broadband access network operators typically have mechanisms to detect and classify both inbound and outbound DDoS attacks, utilizing flow telemetry exported from their peering/transit and customer aggregation routers. In the event of an outbound DDoS attack, they Dobbins, et al. Expires May 17, 2018 [Page 14] Internet-Draft DOTS Use Cases November 2017 may make use of internally-developed systems which leverage their subscriber-management systems to de-provision end-customers who are sourcing outbound DDoS traffic; in some cases, they may have implemented quarantine systems to block all outbound traffic sourced from the offending end-customers. In either case, the perceived disruption of the end-customer's Internet access often prompts a help-desk call, which erodes the margins of the broadband access provider and can cause end-customer dissatisfaction. Increasingly, CPE devices themselves are targeted by attackers who exploit security flaws in these devices in order to compromise them and subsume them into botnets, and then leverage them to launch outbound DDoS attacks. In all of the described scenarios, the end- customers are unaware that their computers and/or CPE devices have been compromised and are being used to launch outbound DDoS attacks - however, they may notice a degradation of their Internet connectivity as a result of outbound bandwidth consumption or other disruption. By deploying DOTS-enabled telemetry systems and CPE devices (and possibly requiring DOTS functionality in customer-provided CPE devices), broadband access providers can utilize a standards-based mechanism to suppress outbound DDoS attack traffic while optionally allowing legitimate end-customer traffic to proceed unmolested. In order to achieve this capability, the telemetry analysis system utilized by the broadband access provider must have DOTS client functionality, and the end-customer CPE devices must have DOTS server functionality. When the telemetry analysis system detects and classifies an outbound DDoS attack sourced from one or more end- customer networks/devices, the DOTS client of the telemetry analysis system sends a DOTS request to the DOTS server implemented on the CPE devices, requesting local mitigation assistance in suppressing either the identified outbound DDoS traffic, or all outbound traffic sourced from the end-customer networks/devices. The DOTS server residing within the CPE device(s) would then perform predefined actions such as implementing on-board access-control lists (ACLs) to suppress the outbound traffic in question and prevent it from leaving the local end-customer network(s). Broadband access network operators may choose to implement a quarantine of all or selected network traffic originating from end- customer networks/devices which are sourcing outbound DDoS traffic, redirecting traffic from interactive applications such as Web browsers to an internal portal which informs the end-customer of the quarantine action, and providing instructions for self-remediation and/or helpdesk contact information. Dobbins, et al. Expires May 17, 2018 [Page 15] Internet-Draft DOTS Use Cases November 2017 Quarantine systems for broadband access networks are typically custom-developed and -maintained, and are generally deployed only by a relatively small number of broadband access providers with considerable internal software development and support capabilities. By requiring the manufacturers of operator-supplied CPE devices to implement DOTS server functionality, and requiring customer-provided CPE devices to feature DOTS server functionality, broadband access network operators who previously could not afford the development expense of creating custom quarantine systems to integrate DOTS- enabled network telemetry systems to act as DOTS clients and perform effective quarantine of end-customer networks and devices until such time as they have been remediated. The DOTS communications model in this scenario resembles that described in Section 3.1.1.1, except that all the DOTS communications take place within the same span of administrative control and the same network. 3.2.2. Home Network DDoS Detection Collaboration for ISP network management Home networks run with (limited) bandwidth as well as limited routing resources, while they are expected to provide services reachable from the outside [RFC7368]. This makes such networks some easy targets to DDoS attacks via their WAN interface. As these DDoS attacks are easy to perform, they may remain undetected by the upstream ISP. When the CPE is congested, the customer is likely to call the ISP hotline. In order to improve the quality of experience of the connectivity as well as to automate the request for DDoS mitigation, ISPs are likely to consider a standard mean for CPEs to automatically inform a dedicated service mitigation platform when they are under a suspected DDoS. Note also that this section only considers DDoS attacks CPE or services in the home network are encountering. This differs from DDoS attacks the CPE or any device within the home network may take part of - such as botnets. In the later attacks, the home network generates traffic under the control of a botmaster. Such attacks may only be detected once the attacks have been characterized. It would be tempting to consider a feature in the DOTS protocol to allow a DOTS server to inform a CPE that some suspect traffic is being sent by the CPE so that appropriate actions are undertaken by the CPE/ user. Nevertheless, this feature would require some interaction with the CPE administrator. Such scenario is outside the scope of this document. In this use case, ISPs are willing to prevent their customer undergoing DDoS attacks in order to enhance the quality of experience Dobbins, et al. Expires May 17, 2018 [Page 16] Internet-Draft DOTS Use Cases November 2017 of their customers, to avoid unnecessary costly call on hot lines as well as to optimize the bandwidth of their network. A key challenge for the ISP is to detect DDoS attacks. In fact, DDoS detection is not only fine grained but is also expected to be different for each home network or small businesses networks (SOHO), and the ISP is unlikely to have sufficient resource to inspect the traffic of all its customers. In order to address these challenges, ISPs are delegating the DDoS detection to CPE of home network or SOHO. Outsourcing the detection on the CPE provides the following advantages to the ISP: 1) Avoid the ISP to dedicate a huge amount of resource for deep packet inspection over a large amount of traffic with a specific security policies associated to each home network. It is expected that such traffic only constitutes a small fraction of the total traffic the ISP is responsible for. 2) DDoS detection is deployed in a scalable way. 3) Provide more deterministic DDoS attack detection. For example, what could be suspected to be an UDP flood by the ISP may be consented by the terminating point hosted in the home network or SOHO. In fact, without specific home network security policies, the ISP is likely to detect DDoS attack over regular traffic or to miss DDoS attacks targeting a specific home network or CPE. In the first case, this would result in the ISP spending unnecessary resources and in the second case this would directly impact the quality of experience of the customer. Note that in this scenario slightly differs from the "Enterprise with an upstream transit provider DDoS mitigation Service" scenario described in Section 3.1.1. In this scenario, the detection DDoS is motivated by the ISP in order to operate appropriately its network. For that purpose, it requires some collaboration with the home network. In Section 3.1.1, the target network requests a mitigation service from the upstream transit provider in order to operate its services. Even though the motivations differ, there are still significant advantages for the home network to collaborate. On the home network or SOHO perspective such collaboration provides the following advantages: 1) If it removes the flows contributing to a DDoS attacks, then it enhances the quality of experience of the users of the targeted services or the entire home network. 2) If mitigation is being handled by the ISP rather then the home network, then it reduces the management of DDoS attacks by the network administrator which involves detection as well as mitigation as well as the provisioning of extra resources. 3) If the DDoS detection is based on information specific to the home network, such as for example the description of the services, the hosts capacities or the network Dobbins, et al. Expires May 17, 2018 [Page 17] Internet-Draft DOTS Use Cases November 2017 topology, then performing the DDoS detection by the home network instead of the ISP avoids the home network to leak private information to the ISP. In that sense, it better preserves the home network or SOHO privacy while enabling a better detection. However, the request for mitigation may still leak some informations. ISPs must not retrieve sensitive data without the consent of the user. This is usually captured in administrative contracts that are out of scope of this document. When the CPE suspects an attack, it notifies automatically or the ISP. The contact address of the DDoS Mitigation service of the ISP may be hard coded or may be configured manually or automatically (e.g., eventually the DHCP server may provide the DDoS mitigation service via specific DHCP options). The communication to trigger a DDoS mitigation between the home network and the ISP is performed using DOTS. The home network CPE implements a DOTS client while the ISP implements a DOTS server. The DOTS client on the CPE monitors the status of CPE's resource and WAN link bandwidth usage. If something unusual happens based on preconfigured throughput, traffic patter, explicit action from the user, or some heuristics methods, the DOTS client sends a DOTS mitigation request to the ISP DOTS server. Typically, a default configuration with no additional information associated to the DOTS mitigation request is expected. The ISP derives traffic to mitigate from the CPE IP address. In some cases, the DOTS mitigation request contains options such as some IP addresses or prefixes that belongs to a whitelist or a blacklist. In this case, the white and black lists are not associated to some analysis performed by the CPE - as the CPE is clearly not expected to analyze such attacks. Instead these are part of some configuration parameters. For example, in the case of small business, one may indicate specific legitimate IP addresses such as those used for VPNs, or third party services the company is likely to set a session. Similarly, the CPE may provide the IP addresses targeting the assets to be protected inside the network. Note that the IP address is the IP address used to reach the asset from the internet, and as such is expected to be globally routable. Such options may include the IP address as well as a service description. Similarly to the previous blacklist and whitelist, such information are likely not derived from a traffic analysis performed by the CPE, but instead are more related to configuration parameters. Upon receiving the DOTS mitigation request, the DOTS server acknowledges its reception and confirms DDoS mitigation starts or Dobbins, et al. Expires May 17, 2018 [Page 18] Internet-Draft DOTS Use Cases November 2017 not. Such feed back is mostly to avoid retransmission of the request. Note that the ISP is connected to multiple CPEs and as such the CPE can potentially perform DDoS attack to the DOTS server. ISP may use gateways to absorbs the traffic. These gateways, will typically aggregate a smaller number of CPEs and retransmit to the destination DOTS Server a selected information. Note that such gateways may somehow act as a DOTS relay, which is implemented with a DOTS Server and a DOTS Client. Note also that the case of a large DDoS attack targeting simultaneously multiple CPEs is expected to be detected and mitigated by the upstream architecture, eventually without DOTS alerts sent by each single CPE. ISP may activate mitigation for the traffic associated to the CPE sending the alert or instead to the traffic associated to all CPE. Such decisions are not part of DOTS, but instead depend on the policies of the ISP. It is unlikely the CPE will follow the status of the mitigation. The ISP is only expected to inform the CPE the mitigation has been stopped. Upon receipt of such notification the CPE may, for example, re- activate the monitoring jobs and thus is likely to provide some further DOTS alert. 3.2.3. DDoS Orchestration In this use case, one or more DDoS telemetry systems or monitoring devices such as a flow telemetry collector monitor a network -- typically an ISP network. Upon detection of a DDoS attack, these telemetry systems alert an orchestrator in charge of coordinating the various DDoS mitigation systems within the domain. The telemetry systems may be configured to provide necessary and useful pieces of information, such as a preliminary analysis of the observation to the orchestrator. The orchestrator analyses the various information it receives from specialized equipement, and elaborates one or multiple DDoS mitigation strategies. In some case, a manual confirmation may also be required to choose a proposed strategy or to initiate a DDoS mitigation. The DDoS mitigation may consist of multiple steps such as configuring the network, various hardware, or updating already instantiated DDoS mitigation functions. In some cases, some specific virtual DDoS mitigation functions must be instantiated and properly ordered. Eventually, the coordination of the mitigation may involve Dobbins, et al. Expires May 17, 2018 [Page 19] Internet-Draft DOTS Use Cases November 2017 external DDoS resources such as a transit provider (Section 3.1.1.1) or an MSSP (Section 3.1.2.1). The communications used to trigger a DDoS mitigation between the telemetry and monitoring systems and the orchestrator is performed using DOTS. The telemetry systems implements a DOTS client while the orchestrator implements a DOTS server. The communication between a network administrator and the orchestrator is also performed using DOTS. The network administrator via its web interfaces implements a DOTS client, while the Orchestrator implements a DOTS server. The communication between the Orchestrator and the DDoS mitigation systems is performed using DOTS. The Orchestrator implements a DOTS client while the DDoS mitigation systems implement a DOTS server. The configuration aspects of each DDoS mitigation system, as well as the instantiations of DDoS mitigation functions or network configuration is not part of DOTS. Similarly, the discovery of available DDoS mitigation functions is not part of DOTS. +----------+ | network |C | adminis |<-+ | trator | | +----------+ | | (internal) +----------+ | S+--------------+ +-----------+ |telemetry/| +->| |C S| DDoS |+ |monitoring|<--->| Orchestrator |<--->| mitigation|| |systems |C S| |<-+ | systems || +----------+ +--------------+C | +-----------+| | +----------+ | | (external) | +-----------+ | S| DDoS | +->| mitigation| | systems | +-----------+ * C is for DOTS client functionality * S is for DOTS server functionality Figure 1: DDoS Orchestration Dobbins, et al. Expires May 17, 2018 [Page 20] Internet-Draft DOTS Use Cases November 2017 The telemetry systems monitor various traffic network and perform their measurement tasks. They are configured so that when an event or some measurements reach a predefined level to report a DOTS mitigation request to the Orchestrator. The DOTS mitigation request may be associated with some element such as specific reporting. Upon receipt of the DOTS mitigation request from the telemetry system, the Orchestrator responds with an acknowledgement, to avoid retransmission of the request for mitigation. The status of the DDoS mitigation indicates the Orchestrator is in an analysing phase. The Orchestrator begins collecting various information from various telemetry systems in order to correlate the measurements and provide an analysis of the event. Eventually, the Orchestrator may ask additional information to the telemetry system, however, the collection of these information is performed outside DOTS. The orchestrator may be configured to start a DDoS mitigation upon approval from a network administrator. The analysis from the orchestrator is reported to the network administrator via a web interface. If the network administrator decides to start the mitigation, she orders through her web interface a DOTS client to send a request for DDoS mitigation. This request is expected to be associated with a context that identifies the DDoS mitigation selected. Upon receiving the DOTS request for DDoS mitigation from the network administrator, the orchestrator orchestrates the DDoS mitigation according to the specified strategy. Its status indicates the DDoS mitigation is starting while not effective. Orchestration of the DDoS mitigation systems works similarly as described in Section 3.1.1.1 and Section 3.1.2.1. The Orchestrator indicates with its status whether the DDoS Mitigation is effective. When the DDoS mitigation is finished on the DDoS mitigation systems, the orchestrator indicates to the Telemetry systems as well as to the network administrator the DDoS mitigation is finished. 4. Security Considerations DOTS is at risk from four primary forms of attack: DOTS agent impersonation, traffic injection, signal-blocking, and DDoS attacks. Associated security requirements and additional ones are defined in [I-D.ietf-dots-requirements]. These security risks can be managed through current secure communications best practices. DOTS is not subject to anything new or unique in this area. Dobbins, et al. Expires May 17, 2018 [Page 21] Internet-Draft DOTS Use Cases November 2017 5. IANA Considerations No IANA considerations exist for this document at this time. 6. Acknowledgments The authors would like to thank among others Tirumaleswar Reddy; Andrew Mortensen; Mohamed Boucadaire; Artyom Gavrichenkov; and the DOTS WG chairs, Roman D. Danyliw and Tobias Gondrom, for their valuable feedback. 7. References 7.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . 7.2. Informative References [I-D.ietf-dots-requirements] Mortensen, A., Moskowitz, R., and T. Reddy, "Distributed Denial of Service (DDoS) Open Threat Signaling Requirements", draft-ietf-dots-requirements-07 (work in progress), October 2017. [RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S. Cheshire, "Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry", BCP 165, RFC 6335, DOI 10.17487/RFC6335, August 2011, . [RFC7368] Chown, T., Ed., Arkko, J., Brandt, A., Troan, O., and J. Weil, "IPv6 Home Networking Architecture Principles", RFC 7368, DOI 10.17487/RFC7368, October 2014, . Authors' Addresses Roland Dobbins Arbor Networks Singapore EMail: rdobbins@arbor.net Dobbins, et al. Expires May 17, 2018 [Page 22] Internet-Draft DOTS Use Cases November 2017 Daniel Migault Ericsson 8400 boulevard Decarie Montreal, QC H4P 2N2 Canada EMail: daniel.migault@ericsson.com Stefan Fouant USA EMail: stefan.fouant@copperriverit.com Robert Moskowitz HTT Consulting Oak Park, MI 48237 USA EMail: rgm@labs.htt-consult.com Nik Teague Verisign 12061 Bluemont Way Reston, VA 20190 EMail: nteague@verisign.com Liang Xia Huawei No. 101, Software Avenue, Yuhuatai District Nanjing China EMail: Frank.xialiang@huawei.com Kaname Nishizuka NTT Communications GranPark 16F 3-4-1 Shibaura, Minato-ku Tokyo 108-8118 Japan EMail: kaname@nttv6.jp Dobbins, et al. Expires May 17, 2018 [Page 23] --_000_2DD56D786E600F45AC6BDE7DA4E8A8C118DF3250eusaamb107erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi all,

 

Please find my personal comments on the current d= raft. Co-authors have decided to bring their comments to the WG mailing lis= t so the WG can be informed of the evolution of the draft. A version is exp= ected to come very soon.

 

Feel free to comment!

 

 

Yours,

 

Daniel

 

looking at the different inter domain use cases, = my feeling is that the most generic use case is the use case described in t= he  current section 3.1.2.2.  "MSSP as an end-customer reque= sting overflow DDoS mitigation assistance from other MSSPs". The use case "Upstream Transit Providers Offering DDoS M= itigation Services" seems to me related to the "Overlay MSSPs Off= ering DDoS Mitigation Services" with the addition that the ddos mitiga= tion is bound to a specific link. This constraint, in case multiple links adds some managements between providers.

 

With that perspective, I would favor to start wit= h the use case described in the  current section 3.1.2.2.  "= MSSP as an end-customer requesting overflow DDoS mitigation assistance from= other MSSPs" and then follow up with the "Upstream Transit Providers Offering DDoS Mitigation Services" as another use c= ase. I would expect the "Overlay MSSPs Offering DDoS Mitigation Servic= es" to have the complete description that is currently provided in sec= tion 3.1.1.1 while the "Upstream Transit Providers Offering DDoS Mitigation Services" only document the additional const= raint of binding ddos mitigation to the upstream link, the motivation for a= dding this constraints as well as the additional management overhead associ= ated to that constraint. I do not think that repeating the complete steps as currently described in 3.1.1.1. would= be necessary since these would already be described before.

 

In my opinion, reducing the number of use cases w= ould ease the reading of the document. These are the use cases I would cons= ider, each being summed up into a single section/subsection.

* Use Case1 :  "End-customer with an ov= erlay DDoS mitigation managed security service provider (MSSP)" (curre= nt section 3.1.2.2)

* Use Case2: Upstream Transit Providers Offering = DDoS Mitigation Services (current section 3.1.1.)

* Use Case 3:  DDoS Orchestration (current s= ection 3.2.3)

 

 

I read section 3.1.3 as specific implementations = of Use Case 1-2-3, and As such I would split the information of section sec= tion 1-2-3 into the section related in each Use case.

 

I read section MSSP as an end-customer requesting= overflow DDoS mitigation assistance from other MSSPs ( current section 3.1= .2.2.) as redundant with 3.2.3.  DDoS Orchestration, and so remove thi= s subsection.

 

I read section 3.2.2. "Home Network DDoS Det= ection Collaboration for ISP network management" as very close to 3.1.= 1.1.  End-customer with a single upstream transit provider offering DD= oS mitigation services or 3.1.1.2.  End-customer with multiple upstream transit providers offering DDoS mitigation services= . I would expect that all these section be merged into UseCase2.

 

 

I also agree with the text in section 3.2. &= nbsp;

 

"""

   The DOTS communications model in the= se scenarios are largely

   identical to that described in Secti= on 3.1, except that all the DOTS

   communications take place within the= same span of administrative

   control and the same network.  = These variations are mainly of

   interest from the operational point = of view, as they illustrate

   processes, procedures, and topologic= al details which are

   externalities from the standpoint of= the DOTS ecosystem, but which

   are of great importance for network = operators and DDoS mitigation

   service providers.

"""

 

As a result, I see this section as duplicating of= the previous use cases. I would rather add the complementary information a= s a note added to each use case and remove the distinction between internal= external. This would result in restructuring the current section 3 as:

* section 3.1 use case 1

* section 3.2 use case 2

* section 3.3 use case 3

 

 

Eventually an additional use case may be added Us= e Case 2b: where the initiation of the DDoS mitigation is handled by the up= stream provider instead of the CPE. 

 

Other comments are added directly in the text:

 

 

 

 

 

DOTS       &nb= sp;            =             &nb= sp;            =              R.= Dobbins

Internet-Draft      = ;            &n= bsp;            = ;             A= rbor Networks

Intended status: Informational   &= nbsp;           &nbs= p;            &= nbsp;   D. Migault

Expires: May 17, 2018    &nbs= p;            &= nbsp;           &nbs= p;             = Ericsson

        &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;    S. Fouant

 

        &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp; R. Moskowitz

        &= nbsp;           &nbs= p;            &= nbsp;            &nb= sp;           HTT Co= nsulting

        &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;    N. Teague

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

        &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;       L. Xia

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

        &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp; K. Nishizuka

        &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;        NTT Communications<= /p>

        &= nbsp;           &nbs= p;            &= nbsp;            &nb= sp;        November 13, 2017

 

 

        &= nbsp;       Use cases for DDoS Open Threat Si= gnaling

        &= nbsp;           &nbs= p; draft-ietf-dots-use-cases-09

 

Abstract

 

   The DDoS Open Threat Signaling (DOTS= ) effort is intended to provide a

   protocol to facilitate interoperabil= ity between multivendor DDoS

   mitigation solutions and services.&n= bsp; This document presents use cases

   which describe the interactions expe= cted between the DOTS components

   as well as DOTS messaging exchanges.=   The purpose of describing use

   cases is to identify the interacting= DOTS components, how they

   collaborate and what are the types o= f information to be exchanged.

 

Status of This Memo

 

   This Internet-Draft is submitted in = full conformance with the

   provisions of BCP 78 and BCP 79.

 

   Internet-Drafts are working document= s of the Internet Engineering

   Task Force (IETF).  Note that o= ther groups may also distribute

   working documents as Internet-Drafts= .  The list of current Internet-

   Drafts is at http://datatracker.ietf.org/drafts/current/.

 

   Internet-Drafts are draft documents = valid for a maximum of six months

   and may be updated, replaced, or obs= oleted by other documents at any

   time.  It is inappropriate to u= se Internet-Drafts as reference

   material or to cite them other than = as "work in progress."

 

   This Internet-Draft will expire on M= ay 17, 2018.

 

 

 

 

 

Dobbins, et al.  &nbs= p;        Expires May 17, 2018 &nbs= p;            &= nbsp;   [Page 1]

 

 

Internet-Draft      = ;         DOTS Use Cases  = ;             &= nbsp;November 2017

 

 

Copyright Notice

 

   Copyright (c) 2017 IETF Trust and th= e persons identified as the

   document authors.  All rights r= eserved.

 

   This document is subject to BCP 78 a= nd the IETF Trust's Legal

   Provisions Relating to IETF Document= s

   (http://trustee.ietf.org/license-info) in effect on the da= te of

   publication of this document.  = Please review these documents

   carefully, as they describe your rig= hts and restrictions with respect

   to this document.  Code Compone= nts extracted from this document must

   include Simplified BSD License text = as described in Section 4.e of

   the Trust Legal Provisions and are p= rovided without warranty as

   described in the Simplified BSD Lice= nse.

 

Table of Contents

 

   1.  Introduction  . . . . = . . . . . . . . . . . . . . . . . . . .   2

   2.  Terminology and Acronyms&nb= sp; . . . . . . . . . . . . . . . . . .   3

     2.1.  Requirements = Terminology  . . . . . . . . . . . . . . . .   4<= /p>

   3.  Use Cases Scenarios . . . .= . . . . . . . . . . . . . . . . .   4

     3.1.  Inter-domain = Use Cases  . . . . . . . . . . . . . . . . .   4<= /p>

       3.1.1. = Upstream Transit Providers Offering DDoS Mitigation

        &= nbsp;      Services  . . . . . . . . . . . . = . . . . . . . . . .   5

       3.1.2. = Overlay MSSPs Offering DDoS Mitigation Services . . .  10<= /p>

       3.1.3. = Examples of DOTS clients integrated with

        &= nbsp;      applications, services, and network inf= rastructure

        &= nbsp;      devices . . . . . . . . . . . . . . . .= . . . . . . .  12

     3.2.  Intra-domain = Use Cases  . . . . . . . . . . . . . . . . .  13

       3.2.1. = Suppression of outbound DDoS traffic originating from

        &= nbsp;      a consumer broadband access network . .= . . . . . . .  14

       3.2.2. = Home Network DDoS Detection Collaboration for ISP

        &= nbsp;      network management  . . . . . . . = . . . . . . . . . .  16

       3.2.3. = DDoS Orchestration  . . . . . . . . . . . . . . . . .  19

   4.  Security Considerations . .= . . . . . . . . . . . . . . . . .  21

   5.  IANA Considerations . . . .= . . . . . . . . . . . . . . . . .  22

   6.  Acknowledgments . . . . . .= . . . . . . . . . . . . . . . . .  22

   7.  References  . . . . . = . . . . . . . . . . . . . . . . . . . .  22

     7.1.  Normative Ref= erences  . . . . . . . . . . . . . . . . . .  22

     7.2.  Informative R= eferences  . . . . . . . . . . . . . . . . .  22

   Authors' Addresses  . . . . . .= . . . . . . . . . . . . . . . . .  22

 

1.  Introduction

 

   Currently, distributed denial-of-ser= vice (DDoS) attack mitigation

   solutions are largely based upon sil= oed, proprietary communications

   schemes which result in vendor lock-= in.  As a side-effect, this makes

   the configuration, provisioning, ope= ration, and activation of these

 

 

 

Dobbins, et al.  &nbs= p;        Expires May 17, 2018 &nbs= p;            &= nbsp;   [Page 2]

 

 

Internet-Draft      = ;         DOTS Use Cases  = ;            &n= bsp; November 2017

 

 

   solutions a highly manual and often = time-consuming process.

   Additionally, coordination of multip= le DDoS mitigation solutions

   simultaneously engaged in defending = the same organization (resources)

   against DDoS attacks is fraught with= both technical and process-

   related hurdles.  This greatly = increase operational complexity and

   often results in suboptimal DDoS att= ack mitigation efficacy.

 

   The DDoS Open Threat Signaling (DOTS= ) effort is intended to specify a

   protocol that facilitates interopera= bility between multivendor DDoS

   mitigation solutions and ensures mor= e automation in term of

   mitigation requests and attack chara= cterization patterns.  As DDoS

   solutions are broadly heterogeneous = among vendors, the primary goal

   of DOTS is to provide high-level int= eraction amongst differeing DDoS

<mglt>nits</mglt>

   solutions, such as initiating or ter= minating DDoS mitigation

   assistance.

 

   It should be noted that DOTS is not = intended toperform orchestration

 

<mglt>nits</mglt>

   functions; rather, DOTS is inte= nded to allowdevices, services, and

<mglt>nits</mglt>

   applications to request DDoS attack = mitigation assistance and receive

   mitigation status updates.

 

   These use cases are expected to prov= ide inputs for the design of the

   DOTS protocol(s).

 

2.  Terminology and Acronyms

 

   This document makes use of the terms= defined in

   [I-D.ietf-dots-requirements].

 

   In addition, this document introduce= s the following terms:

 

     Inter-domain: a DOTS com= munications relationship between distinct

     organizations with separ= ate spans of administrative control.

     Typical inter-domain DOT= S communication relationships would be

     between a DDoS mitigatio= n service provider and an end-customer who

     requires DDoS mitigation= assistance; between multiple DDoS

     mitigation service provi= ders coordinating mutual defense of a

     mutual end-customer; or = between DDoS mitigation service providers

     which are requesting add= itional DDoS mitigation assistance in for

     attacks which exceed the= ir inherent DDoS mitigation capacities

     and/or capabilities.

 

     Intra-domain: a DOTS com= munications relationship between various

     (network) elements that = are owned and operated by the same

     administrative entity.&n= bsp; A typical intra-domain DOTS communications

     relationship would be be= tween DOTS agents [I-D.ietf-dots-

     requirements] within the= same organization.

 

 

 

 

Dobbins, et al.  &nbs= p;        Expires May 17, 2018 &nbs= p;            &= nbsp;   [Page 3]

 

 

Internet-Draft      = ;         DOTS Use Cases  = ;            &n= bsp; November 2017

 

 

2.1.  Requirements Terminology

 

   The key words "MUST", &quo= t;MUST NOT", "REQUIRED", "SHALL", "SHALL NOT&= quot;,

   "SHOULD", "SHOULD NOT= ", "RECOMMENDED", "MAY", and "OPTIONAL" = in this

   document are to be interpreted as de= scribed in RFC 2119 [RFC2119].

 

3.  Use Cases Scenarios

 

   This section provides a high-level d= escription of scenarios addressed

   by DOTS.  In both sub-sections,= the scenarios are provided in order

   to illustrate the use of DOTS in typ= ical DDoS attack scenarios.  They

   are not definitive, and other use ca= ses are expected to emerge with

   widespread DOTS deployment.

 

   All scenarios present a coordination= between the targeted

   organization, the DDoS attack teleme= try and the mitigator.  The

   coordination and communication betwe= en these entities depends, for

   example, on the characteristic or fu= nctionality of the entity itself,

   the reliability of the information p= rovided by DDoS attack telemetry,

   and the business relationship betwee= n the DDoS target domain and the

   mitigator.

 

   More explicitly, in some cases, the = DDoS attack telemetry may simply

   activate a DDoS mitigation, whereas = in other cases, it may

   collaborate by providing some inform= ation about an attack.  In some

   cases, the DDoS mitigation may be or= chestrated, which includes

   selecting a specific appliance as we= ll as starting/ending a

   mitigation.

 

3.1.  Inter-domain Use Cases

 

   Inter-domain DOTS deployment scenari= os encompass two or more distinct

   spans of administrative control.&nbs= p; A typical inter-domain DOTS

   deployment may consist of an endpoin= t network such as an Internet-

   connected enterprise requesting DDoS= mitigation assistance from one

   or more upstream transit providers o= ffering DDoS mitigation services,

   or from a topologically-distant MSSP= offering cloud-based overlay

   DDoS mitigation services.  DOTS= may also be used to facilitate

   coordination of DDoS mitigation acti= vities between mitigation

   providers.

 

   Coordination between organizations m= aking use of DOTS in such

   scenarios is necessary.  Along = with DOTS-specific tasks such as DOTS

   peering and validating the exchange = of DOTS messaging between the

   relevant organizations, externalitie= s relating to routing

   advertisements, authoritative DNS re= cords (for DNS-based diversion),

   network access policies for DOTS nod= es, service-level agreements

   (SLAs), and DDoS mitigation provisio= ning are required.

 

 

 

Dobbins, et al.  &nbs= p;        Expires May 17, 2018 &nbs= p;            &= nbsp;   [Page 4]

 

 

Internet-Draft      = ;         DOTS Use Cases  = ;            &n= bsp; November 2017

 

 

3.1.1.  Upstream Transit Providers Offering = DDoS Mitigation Services

 

   The use-cases in this section reflec= t scenarios in which the

   immediate upstream transit network(s= ) offer DDoS mitigation services

   to their end-customers.  The DO= TS communications models in these use-

   cases are largely identical with tha= t decribed in Section 3.1.1.1,

   with the exceptions of Section 3.1.1= .4 and Section 3.1.1.5.  These

   variations are mainly of interest fr= om the operational point of view,

   as they illustrate processes, proced= ures, and topological details

   which are externalities from the sta= ndpoint of the DOTS ecosystem,

   but which are of great importance fo= r network operators and DDoS

   mitigation service providers.

 

3.1.1.1.  End-customer with a single upstrea= m transit provider offering

        &= nbsp; DDoS mitigation services

 

   In this scenario, an enterprise netw= ork with self-hosted Internet-

   facing properties such as Web server= s, authoritative DNS servers, and

   VoIP PBXes has an intelligent DDoS m= itigation system (IDMS) deployed

   to protect those servers and applica= tions from DDoS attacks.  In

   addition to their on-premise DDoS de= fense capability, they have

   contracted with their Internet trans= it provider for DDoS mitigation

   services which threaten to overwhelm= their transit link bandwidth.

 

   The IDMS is configured such that if = the incoming Internet traffic

   volume exceeds 50% of the provisione= d upstream Internet transit link

   capacity, the IDMS will request DDoS= mitigation assistance from the

   upstream transit provider.

 

   The requests to trigger, manage, and= finalize a DDoS mitigation

   between the enterprise IDMS and the = transit provider is performed

   using DOTS.  The enterprise IDM= S implements a DOTS client while the

   transit provider implements a DOTS s= erver which is integrated with

   their DDoS mitigation orchestration = system.

 

   When the IDMS detects an inbound DDo= S attack targeting the enterprise

   servers and applications, it immedia= tely begins mitigating the

   attack.

 

   During the course of the attack, the= inbound traffic volume exceeds

   the 50% threshold; the IDMS DOTS cli= ent signals the DOTS server on

   the upstream transit provider networ= k to initiate DDoS mitigation.

   The DOTS server signals the DOTS cli= ent that it can service this

   request, and mitigation is initiated= on the transit provider network.

 

   Over the course of the attack, the D= OTS server on the transit

   provider network periodically signal= s the DOTS client on the

   enterprise IDMS in order to provide = mitigation status information,

 

 

 

Dobbins, et al.  &nbs= p;        Expires May 17, 2018 &nbs= p;            &= nbsp;   [Page 5]

 

 

Internet-Draft      = ;         DOTS Use Cases  = ;             &= nbsp;November 2017

 

 

   statistics related to DDoS attack tr= affic mitigation, and related

   information.  Once the DDoS att= ack has ended, the DOTS server signals

   the enterprise IDMS DOTS client that= the attack has subsided.

 

   The enterprise IDMS then requests th= at DDoS mitigation services on

   the upstream transit provider networ= k be terminated.  The DOTS server

   on the transit provider network rece= ives this request, communicates

   with the transit provider orchestrat= ion system controlling its DDoS

   mitigation system to terminate attac= k mitigation, and once the

   mitigation has ended, confirms the e= nd of upstream DDoS mitigation

   service to the enterprise IDMS DOTS = client.

 

   Note that communications between the= enterprise DOTS client and the

   upstream transit provider DOTS serve= r may take place in-band within

   the main Internet transit link betwe= en the enterprise and the transit

   provider; out-of-band via a separate= , dedicated wireline network link

   utilized solely for DOTS signaling; = or out-of-band via some other

   form of network connectivity such as= a third-party wireless 4G

   network link.

 

   The following is an overview of the = DOTS communication model for this

   use-case:

 

   (a) A DDoS attack is initiated again= st online properties of an

   organization which has deployed a DO= TS-client-capable IDMS.

 

   (b) The IDMS detects, classifies, an= d begins mitigating the DDoS

   attack.

 

   (c) The IDMS determines that its cap= acity and/or capability to

   mitigate the DDoS attack is insuffic= ient, and utilize its DOTS client

   functionality to send a DOTS mitigat= ion service initiation request to

   one or more DOTS servers residing on= the upstream transit networks.

   This DOTS mitigation service initiat= ion request is automatically

   initiated by the DOTS client.

 

   (d) The DOTS servers which receive t= he DOTS mitigation service

   initiation requests determine that t= hey have been configured to honor

   requests from the requesting DOTS cl= ient, and initiate situationally-

   appropriate DDoS mitigation service.=

 

   (e) The DOTS servers transmit a DOTS= service status message to the

   DOTS client indicating that upstream= DDoS mitigation service has been

   initiated.

 

   (f) While DDoS mitigation services a= re active, the DOTS servers

   regularly transmit DOTS mitigation s= tatus updates to the DOTS client.

 

 

 

 

Dobbins, et al.  &nbs= p;        Expires May 17, 2018 &nbs= p;            &= nbsp;   [Page 6]

 

 

Internet-Draft      = ;         DOTS Use Cases  = ;            &n= bsp; November 2017

 

 

   (g) While DDoS mitigation services a= re active, the DOTS client may

   optionally regularly transmit DOTS m= itigation efficacy updates to the

   DOTS server.

 

   (h) When the upstream DDoS mitigator= s determine that the DDoS attack

   has ceased, they indicate this chang= e in status to the DOTS server.

 

<mglt>I see that the upstream provides meas= urements, but it seems that the end of the attack should be determined by t= he client based on the indicators of the server. More specifically, when an= attack reaches picks every 15 min, maybe the client is better of remaining under the protection of the upstream mit= igation. Maybe we could clarify this point but to me it could be removed.&l= t;/mglt>

 

   (i) The DOTS server transmist a DOTS= mitigation status update to the

  DOTS client indicating that the DDoS = attack has ceased.

 

   (j) The DOTS client transmits a DOTS= mitigation service termination

   request to the DOTS server.

 

   (k) The DOTS server terminates DDoS = mitigation service.

 

<mglt> I do not think that l and m brings m= uch information to understand the use-case. It seems more a protocol issue = when both parties must ensure they are in synch. I would remove l and m .&l= t;/mglt>

 

   (l) The DOTS server transmis a DOTS = mitigation status update to the

   DOTS client indicating that DDoS mit= igation services have been

   terminated.

 

   (m) The DOTS client transmits a DOTS= mitigation termination status

   acknowledgement to the DOTS servers.=

 

3.1.1.2.  End-customer with multiple upstrea= m transit providers offering

         =  DDoS mitigation services

 

   This scenario shares many characteri= stics with Section 3.1.1.1, but

   with the key difference that the ent= erprise in question is multi-

   homed, i.e., has two or more upstrea= m transit providers, and that

   they all provide DDoS mitigation ser= vices.

 

   In most cases, the communications mo= del for a multi-homed model would

   be the same as in the single-homed m= odel, merely duplicated in

   parallel.  However, if two or m= ore of the upstream transit providers

   have entered into a mutual DDoS miti= gation agreement and have

   established DOTS peering relationshi= ps, DDoS mitigation status

   messages may exchanged between their= respective DOTS servers in order

   to provide a more complete picture o= f the DDoS attack scope.  This

   will also allow for either automated= or operator-assisted

   programmatic cooperative DDoS mitiga= tion activities on the part of

   the DOTS-peered transit providers.

 

   The addtional DOTS communications be= tween the upstream transit

   providers will consist of mitigation= start, mitigation status, and

   mitigation termination messages.

 

 

<mglt>My very personal opinion is that this= use case is very similar and straight forward to the previous one. I would= remove this section.</mglt>

 

 

 

 

Dobbins, et al.     &nbs= p;     Expires May 17, 2018    &nbs= p;             = [Page 7]

 

 

Internet-Draft      = ;         DOTS Use Cases  = ;            &n= bsp; November 2017

 

 

3.1.1.3.  End-customer with multiple upstrea= m transit providers, but

        &= nbsp; only a single upstream transit provider offering DDoS

        &= nbsp; mitigation services

 

   This scenario is similar to that out= lined in Section 3.1.1.2;

   however, only one of the upstream tr= ansit providers in question

   offers DDoS mitigation services.&nbs= p; In this situation, the enterprise

   would cease advertising the relevant= network prefixes via the transit

   providers which do not provide DDoS = mitigation services - or, in the

   case where the enterprise does not c= ontrol its own routing, request

   that the upstream transit providers = which do not offer DDoS

   mitigation services stop advertising= the relevant network prefixes on

   their behalf.

 

   Once it has been determined that the= DDoS attack has ceased, the

   enterprise once again announces the = relevant routes to the upstream

   transit providers which do not offer= DDoS mitigation services, or

   requests that they resume announcing= the relevant routes on behalf of

   the enterprise.

 

   Note that falling back to a single t= ransit provider has the effect of

   reducing available inbound transit b= andwidth during a DDoS attack.

   Without proper planning and sufficie= nt provisioning of both the link

   capacity and DDoS mitigation capacit= y of the sole transit provider

   offering DDoS mitigation services, t= his reduction of available

   bandwidth could lead to network link= congestion caused by legitimate

   inbound network traffic.  There= fore, careful planning and

   provisioning of both upstream transi= t bandwidth as well as DDoS

   mitigation capacity is required in s= cenarios of this nature.

 

   The withdrawal and announcement of r= outing prefixes described in this

   use-case falls outside the scope of = DOTS, although they could

   conceivably be triggered as a result= of provider-specific

   orchestration triggered by the recei= pt of specific DOTS messages from

   the enterprise in question.

 

<mglt>3.1.1.2 and 3.1.1.3 describes a need = to manage mitigation services when those are associated to a specific link.= I do not think that is necessary to have these examples, but I agree that = 3.1.1.3 may be interesting. If we decide to keep them I would merge them into a single section.</mglt>

 

 

3.1.1.4.  End-customer with an upstream tran= sit provider offering DDoS

        &= nbsp; mitigation services on an ongoing basis

 

   This scenario is similar to that des= cribed in Section 3.1.1.1, except

   that due to the lack of a capable lo= cal IDMS solution, strict uptime

   requirements, or other consideration= s, the end-customer has

   previously arranged for continuous a= ctive DDoS mitigation coverage;

   thus, the concepts of initiating or = terminating DDoS mitigation

   services do not apply.

 

   During an attack, the DOTS server on= the upstream transit provider

   network immediately notifies the DOT= S client on the enterprise

 

 

 

Dobbins, et al.  &nbs= p;        Expires May 17, 2018 &nbs= p;            &= nbsp;   [Page 8]

 

 

Internet-Draft      = ;         DOTS Use Cases  = ;            &n= bsp; November 2017

 

 

   network about the attack and periodi= cally signals the DOTS client in

   order to provide mitigation status i= nformation and related

   information.  The end-customer = may then use this information to add

   capacity or implement configuration = changes intended to increase

   resilience, to plan maintenance wind= ows or changes to routing

   policies, etc.

 

 

 

3.1.1.5.  End-customer with an upstream tran= sit provider offering DDoS

        &= nbsp; mitigation services, but DDoS mitigation service is refused

 

   This scenario is similar to that des= cribed in Section 3.1.1.1, except

   that the upstream transit provider i= s unable to honor the DDoS

   mitigation service request from the = end-customer due to mitigation

   capacity limitations, technical faul= ts, or other circumstances.  The

   end-customer DOTS client may be conf= igured to make repeated attempts

   to engage DDoS mitigation service fr= om the refusing provider, or

   alternately may be configured to req= uest DDoS mitigation service from

   alternate providers.

 

<mglt> I believe that the text above is suf= ficient and shoudl be moved to 3.1.1.1. The text below is straight forward.= </mglt>

 

   The following is an overview of the = DOTS communication model for this

   use-case:

 

   (a) A DDoS attack is initiated again= st online properties of an

   organization which has deployed a DO= TS-client-capable IDMS.

 

   (b) The IDMS detects, classifies, an= d begins mitigating the DDoS

   attack.

 

   (c) The IDMS determines that its cap= acity and/or capability to

   mitigate the DDoS attack is insuffic= ient, and utilizes its DOTS

   client functionality to send a DOTS = mitigation service initiation

   request to a DOTS server residing on= an upstream transit network.

 

   (d) The DOTS servers which receives = the DOTS mitigation service

   initiation requests determines that = it has been configured to honor

   requests from the requesting DOTS cl= ient, and attempts to initiate

   situationally-appropriate DDoS mitig= ation service.

 

   (e) The DDoS mitigators on the upstr= eam network report back to the

   DOTS server that they are unable to = initiate DDoS mitigation service

   for the requesting organization due = to mitigation capacity

   constraints, bandwidth constraints, = functionality constraints,

   hardware casualties, or other impedi= ments.

 

   (f) The DOTS servers transmits a DOT= S service status message to the

   DOTS client indicating that upstream= DDoS mitigation service cannot

   be initiated as requested.

 

 

 

 

Dobbins, et al.     &nbs= p;     Expires May 17, 2018    &nbs= p;             = [Page 9]

 

 

Internet-Draft      = ;         DOTS Use Cases  = ;            &n= bsp; November 2017

 

 

   (g) The DOTS client may optionally r= egularly re-transmit DOTS

   mitigation status request messages t= o the DOTS server until receiving

   acknowledgement that DDos mitigation= services have been initiated.

 

   (h) The DOTS client may optionally t= ransmit a DOTS mitigation service

   initiation request to a DOTS server = associated with a configured

   fallback upstream DDoS mitigation se= rvice.  Multiple fallback DDoS

   mitigation services may optionally b= e configured.

 

   (i) The process describe above cycli= cally continues until the DDoS

   mitigation service request is fulfil= led; the DOTS client determines

   that the DDoS attack volume has decr= eased to a level and/or

   complexity which it can successfully= mitigate; the DDoS attack has

   ceased; or manual intervention by pe= rsonnel of the requesting

   organization has taken place.

 

 

3.1.2.  Overlay MSSPs Offering DDoS Mitigati= on Services

 

   The use-cases in this section reflec= t scenarios in which

   topologically-distant managed securi= ty service providers (MSSPs)

   offer DDoS mitigation services to en= d-customers.  The DOTS

   communications models in these use-c= ases are largely identical with

   that decribed in Section 3.1.1.1.&nb= sp; These variations are mainly of

   interest from the operational point = of view, as they illustrate

   processes, procedures, and topologic= al details which are

   externalities from the standpoint of= the DOTS ecosystem, but which

   are of great importance for network = operators and DDoS mitigation

   service providers.

 

 

3.1.2.1.  End-customer with an overlay DDoS = mitigation managed security

        &= nbsp; service provider (MSSP)

 

   This use case details an enterprise = that has a local DDoS detection

   and classification capability and ma= y or may not have an on-premise

   mitigation capability.  The ent= erprise is contracted with an overlay

   DDoS mitigation MSSP, topologically = distant from the enterprise

   network (i.e., not a direct upstream= transit provider), which can

   redirect (divert) traffic away from = the enterprise, provide DDoS

   mitigation services services, and th= en forward (re-inject) legitimate

   traffic to the enterprise on an on-d= emand basis.  In this scenario,

   diversion of Internet traffic destin= ed for the enterprise network

   into the overlay DDoS mitigation MSS= P network is typically

   accomplished via eBGP announcements = of the relevant enterprise

   network CIDR blocks, or via authorit= ative DNS subdomain-based

   mechanisms (other mechanisms are not= precluded, these are merely the

   most common ones in use today).=

 

 

 

 

 

Dobbins, et al.  &nbs= p;        Expires May 17, 2018 &nbs= p;            &= nbsp;  [Page 10]

 

 

Internet-Draft      = ;         DOTS Use Cases  = ;            &n= bsp; November 2017

 

 

   The enterprise determines thresholds= at which a request for

   mitigation is triggered indicating t= o the MSSP that inbound network

   traffic should be diverted into the = MSSP network and that DDoS

   mitigation should be initiated. = ; The enterprise may also elect to

   manually request diversion and mitig= ation via the MSSP network as

   desired.

 

   The communications required to initi= ate, manage, and terminate active

   DDoS mitigation by the MSSP is perfo= rmed using DOTS.  The enterprise

   DDoS detection/classification system= implements a DOTS client, while

   the MSSP implements a DOTS server in= tegrated with its DDoS mitigation

   orchestration system.  One or m= ore out-of-band methods for initiating

   a mitigation request, such as a Web = portal, a smartphone app, or

   voice support hotline, may also be m= ade available by the MSSP.

 

   When an attack is detected, an autom= ated or manual DOTS mitigation

   request is generated by the enterpri= se and sent to the MSSP.  The

   enterprise DOTS mitigation request i= s processed by the MSSP DOTS

   server, which validates the origin o= f the request and passes it to

   the MSSP DDoS mitigation orchestrati= on system, which then initiates

   active DDoS mitigation.  This a= ction will usually involve the

   diversion of all network traffic des= tined for the targeted enterprise

   into the MSSP DDoS mitigation networ= k, where it will be subjected to

   further scrutiny, with DDoS attack t= raffic filtered by the MSSP.

   Successful mitigation of the DDoS at= tack will not only result

   preserving the availability of servi= ces and applications resident on

   the enterprise network, but will als= o prevent DDoS attack traffic

   from ingressing the networks of the = enterprise upstream transit

   providers and/or peers.

 

   The MSSP should signal via DOTS to t= he enterprise that a mitigation

   request has been received and acted = upon, and should also include an

   update of the mitigation status.&nbs= p; The MSSP may respond periodically

   with additional updates on the mitig= ation status to in order to

   enable the enterprise to make an inf= ormed decision on whether to

   maintain or terminate the mitigation= .  An alternative approach would

   be for the DOTS client mitigation re= quest to include a time to live

   (TTL) for the mitigation, which may = also be extended by the client

   should the attack still be ongoing a= s the TTL reaches expiration.

 

   A variation of this use case may be = that the enterprise is providing

   a DDoS monitoring and analysis servi= ce to customers whose networks

   may be protected by any one of a num= ber of third-party providers.

   The enterprise in question may integ= rate with these third-party

   providers using DOTS and signal acco= rdingly when a customer is

   attacked - the MSSP may then manage = the life-cycle of the attack

   mitigation on behalf of the enterpri= se.

 

 

 

 

Dobbins, et al.  &nbs= p;        Expires May 17, 2018 &nbs= p;            &= nbsp;  [Page 11]

 

 

Internet-Draft      = ;         DOTS Use Cases  = ;            &n= bsp; November 2017

 

 

3.1.2.2.  MSSP as an end-customer requesting= overflow DDoS mitigation

        &= nbsp; assistance from other MSSPs

 

   This is a more complex use-case invo= lving multiple DDoS MSSPs,

   whether transit operators, overlay M= SSPs, or both.  In this scenario,

   an MSSP has entered into a pre-arran= ged DDoS mitigation assistance

   agreement with one or more other DDo= S MSSPs in order to ensure that

   sufficient DDoS mitigation capacity = and/or capabilities may be

   activated in the event that a given = DDoS attack threatens to

   overwhelm the ability of a given DDo= S MSSP to mitigate the attack on

   its own.

 

   BGP-based diversion (including relev= ant Letters of Authorization, or

   LoAs), DNS-based diversion (includin= g relevant LoAs), traffic re-

   injection mechanisms such as Generic= Routing Encapsulation (GRE)

   tunnels, provisioning of DDoS orches= tration systems, et. al,. must be

   arranged in advance between the DDoS= MSSPs which are parties to the

   agreement.  They should also be= tested on a regular basis.

 

   When a DDoS MSSP which is party to t= he agreement is nearing its

   capacity or ability to mitigate a gi= ven DDoS attack traffic, the DOTS

   client integrated with the MSSP DDoS= mitigation orchestration system

   signals partner MSSPs to initiate ne= twork traffic diversion and DDoS

   mitigation activities.  Ongoing= attack and mitigation status messages

   may be passed between the DDoS MSSPs= , and between the requesting MSSP

   and the ultimate end-customer of the= attack.

 

   Once the requesting DDoS MSSP is con= fident that the DDoS attack has

   either ceased or has fallen to level= s of traffic/complexity which

   they can handle on their own, the re= questing DDoS MSSP DOTS client

   sends mitigation termination request= s to the participating overflow

   DDoS MSSPs.

 

 

 

 

3.1.3.  Examples of DOTS clients integrated = with applications, services,

        and ne= twork infrastructure devices

 

   The use-cases in this section reflec= t scenarios in which DOTS clients

   are integrated into devices and serv= ices which have heretofore been

   unable to request DDoS mitigation se= rvices on an as-needed basis.

   The DOTS communications models in th= ese use-cases are largely

   identical with those decribed in {{i= nterdomain-use-cases}.  These

   variations are mainly of interest be= cause they illustrate how DOTS

   allows DDoS mitigation services to e= xpand in scope and utility.

 

 

 

 

 

 

 

 

Dobbins, et al.  &nbs= p;        Expires May 17, 2018 &nbs= p;            &= nbsp;  [Page 12]

 

 

Internet-Draft      = ;         DOTS Use Cases  = ;            &n= bsp; November 2017

 

 

3.1.3.1.  End-customer operating an applicat= ion or service with an

        &= nbsp; integrated DOTS client

 

   In this scenario, a Web server has a= built-in mechanism to detect and

   classify DDoS attacks, which also in= corporates a DOTS client.  When

   an attack is detected, the self-defe= nse mechanism is activated, and

   local DDoS mitigation is initiated.<= o:p>

 

   The DOTS client built into the Web s= erver has been configured to

   request DDoS mitigation services fro= m an upstream transit provider or

   overlay MSSP once specific attack tr= affic thresholds have been

   reached, or certain network traffic = conditions prevail.  Once attack

   traffic subsides below configured th= resholds and/or the specified

   network traffic conditions no longer= apply, the DOTS client requests

   the termination of DDoS mitigation s= ervices.

 

3.1.3.2.  End-customer operating a CPE netwo= rk infrastructure device

        &= nbsp; with an integrated DOTS client

 

   Similar to the above use-case featur= ing applications or services with

   built-in DDoS attack detection/class= ification and DOTS client

   capabilities, in this scenario, an e= nd-customer network

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

   IDS/IPS, Web application firewall or= load-balancer incorporates both

   the functionality required to detect= and classify incoming DDoS

   attacks as well as DOTS client funct= ionality.

 

3.1.3.3.  End-customer with an out-of-band s= martphone application

        &= nbsp; featuring DOTS client capabilities

 

   This scenario would typically apply = in a small office or home office

   (SOHO) setting, where the end-custom= er does not have CPE equipment or

   software capable of detecting/classi= fying/mitigating DDoS attack, yet

   still has a requirement for on-deman= d DDoS mitigation services.  A

   smartphone application containing a = DOTS client would be provided by

   the upstream transit mitigation prov= ider or overlay DDoS MSSP to the

   SOHO end-customer; this application = would allow a manual 'panic-

   button' to request the initiation an= d termination of DDoS mitigation

   services.  The end-customer DOT= S client application will display

   mitigation status information while = DDoS mitigation activities are

   taking place.

 

3.2.  Intra-domain Use Cases

 

   While many of the DOTS-specific elem= ents of inter-domain DOTS

   deployment scenarios apply to intra-= domain scenarios, it is expected

   that many externalities such as coor= dination of and authorization for

   routing advertisements and authorita= tive DNS updates may be automated

 

 

 

Dobbins, et al.  &nbs= p;        Expires May 17, 2018 &nbs= p;            &= nbsp;  [Page 13]

 

 

Internet-Draft      = ;         DOTS Use Cases  = ;            &n= bsp; November 2017

 

 

   to a higher degree than is practicab= le in inter-domain scenarios,

   given that the scope of required act= ivities and authorizations are

   confined to a single organization.&n= bsp; In theory, provisioning and

   change-control related both to DOTS = itself as well as relevant

   externalities may require less admin= istrative overhead and less

   implementation lead-times.

 

   The scope of potential DDoS mitigati= on actions may also be broader in

   intra-organizational scenarios, as p= resumably an organization will

   have a higher degree of autonomy wit= h regards to both techically and

   administratively feasible activities= .

 

   The DOTS communications model in the= se scenarios are largely

   identical to that described in Secti= on 3.1, except that all the DOTS

   communications take place within the= same span of administrative

   control and the same network.  = These variations are mainly of

   interest from the operational point = of view, as they illustrate

   processes, procedures, and topologic= al details which are

   externalities from the standpoint of= the DOTS ecosystem, but which

   are of great importance for network = operators and DDoS mitigation

   service providers.

 

3.2.1.  Suppression of outbound DDoS traffic= originating from a consumer

        broadb= and access network

 

   While most DDoS defenses concentrate= on inbound DDoS attacks

   ingressing from direct peering links= or upstream transit providers,

   the DDoS attack traffic in question = originates from one or more

   Internet-connected networks.  I= n some cases, compromised devices

   residing on the local networks of br= oadband access customers are used

   to directly generate this DDoS attac= k traffic; in others,

   misconfigured devices residing on sa= id local customer networks are

   exploited by attackers to launch ref= lection/amplification DDoS

   attacks.  In either scenario, t= he outbound DDoS traffic emanating

   from these devices can be just as di= sruptive as an inbound DDoS

   attack, and can cause disruption for= substantial proportions of the

   broadband access network operator's = customer base.

 

   Some broadband access network operat= ors provide CPE devices (DSL

   modems/routers, cablemodems, FTTH ro= uters, etc.) to their end-

   customers.  Others allow end-cu= stomers to provide their own CPE

   devices.  Many will either prov= ide CPE devices or allow end-customers

   to supply their own.

 

   Broadband access network operators t= ypically have mechanisms to

   detect and classify both inbound and= outbound DDoS attacks, utilizing

   flow telemetry exported from their p= eering/transit and customer

   aggregation routers.  In the ev= ent of an outbound DDoS attack, they

 

 

 

Dobbins, et al.  &nbs= p;        Expires May 17, 2018 &nbs= p;            &= nbsp;  [Page 14]

 

 

Internet-Draft      = ;         DOTS Use Cases  = ;            &n= bsp; November 2017

 

 

   may make use of internally-developed= systems which leverage their

   subscriber-management systems to de-= provision end-customers who are

   sourcing outbound DDoS traffic; in s= ome cases, they may have

   implemented quarantine systems to bl= ock all outbound traffic sourced

   from the offending end-customers.&nb= sp; In either case, the perceived

   disruption of the end-customer's Int= ernet access often prompts a

   help-desk call, which erodes the mar= gins of the broadband access

   provider and can cause end-customer = dissatisfaction.

 

   Increasingly, CPE devices themselves= are targeted by attackers who

   exploit security flaws in these devi= ces in order to compromise them

   and subsume them into botnets, and t= hen leverage them to launch

   outbound DDoS attacks.  In all = of the described scenarios, the end-

   customers are unaware that their com= puters and/or CPE devices have

   been compromised and are being used = to launch outbound DDoS attacks -

   however, they may notice a degradati= on of their Internet connectivity

   as a result of outbound bandwidth co= nsumption or other disruption.

 

   By deploying DOTS-enabled telemetry = systems and CPE devices (and

   possibly requiring DOTS functionalit= y in customer-provided CPE

   devices), broadband access providers= can utilize a standards-based

   mechanism to suppress outbound DDoS = attack traffic while optionally

   allowing legitimate end-customer tra= ffic to proceed unmolested.

 

   In order to achieve this capability,= the telemetry analysis system

   utilized by the broadband access pro= vider must have DOTS client

   functionality, and the end-customer = CPE devices must have DOTS server

   functionality.  When the teleme= try analysis system detects and

   classifies an outbound DDoS attack s= ourced from one or more end-

   customer networks/devices, the DOTS = client of the telemetry analysis

   system sends a DOTS request to the D= OTS server implemented on the CPE

   devices, requesting local mitigation= assistance in suppressing either

   the identified outbound DDoS traffic= , or all outbound traffic sourced

   from the end-customer networks/devic= es.  The DOTS server residing

   within the CPE device(s) would then = perform predefined actions such

   as implementing on-board access-cont= rol lists (ACLs) to suppress the

   outbound traffic in question and pre= vent it from leaving the local

   end-customer network(s).<= /p>

 

   Broadband access network operators m= ay choose to implement a

   quarantine of all or selected networ= k traffic originating from end-

   customer networks/devices which are = sourcing outbound DDoS traffic,

   redirecting traffic from interactive= applications such as Web

   browsers to an internal portal which= informs the end-customer of the

   quarantine action, and providing ins= tructions for self-remediation

   and/or helpdesk contact information.=

 

 

 

 

 

Dobbins, et al.  &nbs= p;        Expires May 17, 2018 &nbs= p;            &= nbsp;  [Page 15]

 

 

Internet-Draft      = ;         DOTS Use Cases  = ;            &n= bsp; November 2017

 

 

   Quarantine systems for broadband acc= ess networks are typically

   custom-developed and -maintained, an= d are generally deployed only by

   a relatively small number of broadba= nd access providers with

   considerable internal software devel= opment and support capabilities.

   By requiring the manufacturers of op= erator-supplied CPE devices to

   implement DOTS server functionality,= and requiring customer-provided

   CPE devices to feature DOTS server f= unctionality, broadband access

   network operators who previously cou= ld not afford the development

   expense of creating custom quarantin= e systems to integrate DOTS-

   enabled network telemetry systems to= act as DOTS clients and perform

   effective quarantine of end-customer= networks and devices until such

  time as they have been remediated.

 

   The DOTS communications model in thi= s scenario resembles that

   described in Section 3.1.1.1, except= that all the DOTS communications

   take place within the same span of a= dministrative control and the

   same network.

 

3.2.2.  Home Network DDoS Detection Collabor= ation for ISP network

        manage= ment

 

   Home networks run with (limited) ban= dwidth as well as limited routing

   resources, while they are expected t= o provide services reachable from

   the outside [RFC7368].  This ma= kes such networks some easy targets to

   DDoS attacks via their WAN interface= .  As these DDoS attacks are easy

   to perform, they may remain undetect= ed by the upstream ISP.  When the

   CPE is congested, the customer is li= kely to call the ISP hotline.  In

   order to improve the quality of expe= rience of the connectivity as

   well as to automate the request for = DDoS mitigation, ISPs are likely

   to consider a standard mean for CPEs= to automatically inform a

   dedicated service mitigation platfor= m when they are under a suspected

   DDoS.

 

   Note also that this section only con= siders DDoS attacks CPE or

   services in the home network are enc= ountering.  This differs from

   DDoS attacks the CPE or any device w= ithin the home network may take

   part of - such as botnets.  In = the later attacks, the home network

   generates traffic under the control = of a botmaster.  Such attacks may

   only be detected once the attacks ha= ve been characterized.  It would

   be tempting to consider a feature in= the DOTS protocol to allow a

   DOTS server to inform a CPE that som= e suspect traffic is being sent

   by the CPE so that appropriate actio= ns are undertaken by the CPE/

   user.  Nevertheless, this featu= re would require some interaction with

   the CPE administrator.  Such sc= enario is outside the scope of this

   document.

 

   In this use case, ISPs are willing t= o prevent their customer

   undergoing DDoS attacks in order to = enhance the quality of experience

 

 

 

Dobbins, et al.  &nbs= p;        Expires May 17, 2018 &nbs= p;            &= nbsp;  [Page 16]

 

 

Internet-Draft      = ;         DOTS Use Cases  = ;            &n= bsp; November 2017

 

 

   of their customers, to avoid unneces= sary costly call on hot lines as

   well as to optimize the bandwidth of= their network.  A key challenge

   for the ISP is to detect DDoS attack= s.  In fact, DDoS detection is

   not only fine grained but is also ex= pected to be different for each

   home network or small businesses net= works (SOHO), and the ISP is

   unlikely to have sufficient resource= to inspect the traffic of all

   its customers.

 

   In order to address these challenges= , ISPs are delegating the DDoS

   detection to CPE of home network or = SOHO.  Outsourcing the detection

   on the CPE provides the following ad= vantages to the ISP: 1) Avoid the

   ISP to dedicate a huge amount of res= ource for deep packet inspection

   over a large amount of traffic with = a specific security policies

   associated to each home network.&nbs= p; It is expected that such traffic

   only constitutes a small fraction of= the total traffic the ISP is

   responsible for. 2) DDoS detection i= s deployed in a scalable way. 3)

   Provide more deterministic DDoS atta= ck detection.  For example, what

   could be suspected to be an UDP floo= d by the ISP may be consented by

   the terminating point hosted in the = home network or SOHO.  In fact,

   without specific home network securi= ty policies, the ISP is likely to

   detect DDoS attack over regular traf= fic or to miss DDoS attacks

   targeting a specific home network or= CPE.  In the first case, this

   would result in the ISP spending unn= ecessary resources and in the

   second case this would directly impa= ct the quality of experience of

   the customer.

 

   Note that in this scenario slightly = differs from the "Enterprise with

   an upstream transit provider DDoS mi= tigation Service" scenario

   described in Section 3.1.1.  In= this scenario, the detection DDoS is

   motivated by the ISP in order to ope= rate appropriately its network.

 

   For that purpose, it requires some c= ollaboration with the home

   network.  In Section 3.1.1, the= target network requests a mitigation

   service from the upstream transit pr= ovider in order to operate its

   services.

 

   Even though the motivations differ, = there are still significant

   advantages for the home network to c= ollaborate.  On the home network

   or SOHO perspective such collaborati= on provides the following

   advantages: 1) If it removes the flo= ws contributing to a DDoS

   attacks, then it enhances the qualit= y of experience of the users of

   the targeted services or the entire = home network. 2) If mitigation is

   being handled by the ISP rather then= the home network, then it

   reduces the management of DDoS attac= ks by the network administrator

   which involves detection as well as = mitigation as well as the

   provisioning of extra resources. 3) = If the DDoS detection is based on

   information specific to the home net= work, such as for example the

   description of the services, the hos= ts capacities or the network

 

 

 

Dobbins, et al.  &nbs= p;        Expires May 17, 2018 &nbs= p;            &= nbsp;  [Page 17]

 

 

Internet-Draft      = ;         DOTS Use Cases  = ;            &n= bsp; November 2017

 

 

   topology, then performing the DDoS d= etection by the home network

   instead of the ISP avoids the home n= etwork to leak private

   information to the ISP.  In tha= t sense, it better preserves the home

   network or SOHO privacy while enabli= ng a better detection.  However,

   the request for mitigation may still= leak some informations.  ISPs

   must not retrieve sensitive data wit= hout the consent of the user.

   This is usually captured in administ= rative contracts that are out of

   scope of this document.

 

   When the CPE suspects an attack, it = notifies automatically or the

   ISP.  The contact address of th= e DDoS Mitigation service of the ISP

   may be hard coded or may be configur= ed manually or automatically

   (e.g., eventually the DHCP server ma= y provide the DDoS mitigation

   service via specific DHCP options).<= o:p>

 

   The communication to trigger a DDoS = mitigation between the home

   network and the ISP is performed usi= ng DOTS.  The home network CPE

   implements a DOTS client while the I= SP implements a DOTS server.

 

   The DOTS client on the CPE monitors = the status of CPE's resource and

   WAN link bandwidth usage.  If s= omething unusual happens based on

   preconfigured throughput, traffic pa= tter, explicit action from the

   user, or some heuristics methods, th= e DOTS client sends a DOTS

   mitigation request to the ISP DOTS s= erver.  Typically, a default

   configuration with no additional inf= ormation associated to the DOTS

   mitigation request is expected. = ; The ISP derives traffic to mitigate

   from the CPE IP address.<= /p>

 

   In some cases, the DOTS mitigation r= equest contains options such as

   some IP addresses or prefixes that b= elongs to a whitelist or a

   blacklist.  In this case, the w= hite and black lists are not

   associated to some analysis performe= d by the CPE - as the CPE is

   clearly not expected to analyze such= attacks.  Instead these are part

   of some configuration parameters.&nb= sp; For example, in the case of small

   business, one may indicate specific = legitimate IP addresses such as

   those used for VPNs, or third party = services the company is likely to

   set a session.  Similarly, the = CPE may provide the IP addresses

   targeting the assets to be protected= inside the network.  Note that

   the IP address is the IP address use= d to reach the asset from the

   internet, and as such is expected to= be globally routable.  Such

   options may include the IP address a= s well as a service description.

   Similarly to the previous blacklist = and whitelist, such information

   are likely not derived from a traffi= c analysis performed by the CPE,

   but instead are more related to conf= iguration parameters.

 

   Upon receiving the DOTS mitigation r= equest, the DOTS server

   acknowledges its reception and confi= rms DDoS mitigation starts or

 

 

 

 

Dobbins, et al.  &nbs= p;        Expires May 17, 2018 &nbs= p;            &= nbsp;  [Page 18]

 

 

Internet-Draft      = ;         DOTS Use Cases  = ;            &n= bsp; November 2017

 

 

   not.  Such feed back is mostly = to avoid retransmission of the

   request.

 

   Note that the ISP is connected to mu= ltiple CPEs and as such the CPE

   can potentially perform DDoS attack = to the DOTS server.  ISP may use

   gateways to absorbs the traffic.&nbs= p; These gateways, will typically

   aggregate a smaller number of CPEs a= nd retransmit to the destination

   DOTS Server a selected information.&= nbsp; Note that such gateways may

   somehow act as a DOTS relay, which i= s implemented with a DOTS Server

   and a DOTS Client.  Note also t= hat the case of a large DDoS attack

   targeting simultaneously multiple CP= Es is expected to be detected and

   mitigated by the upstream architectu= re, eventually without DOTS

   alerts sent by each single CPE.=

 

   ISP may activate mitigation for the = traffic associated to the CPE

   sending the alert or instead to the = traffic associated to all CPE.

   Such decisions are not part of DOTS,= but instead depend on the

   policies of the ISP.

 

   It is unlikely the CPE will follow t= he status of the mitigation.  The

   ISP is only expected to inform the C= PE the mitigation has been

   stopped.

 

   Upon receipt of such notification th= e CPE may, for example, re-

   activate the monitoring jobs and thu= s is likely to provide some

   further DOTS alert.

 

3.2.3.  DDoS Orchestration

 

   In this use case, one or more DDoS t= elemetry systems or monitoring

   devices such as a flow telemetry col= lector monitor a network --

   typically an ISP network.  Upon= detection of a DDoS attack, these

   telemetry systems alert an orchestra= tor in charge of coordinating the

   various DDoS mitigation systems with= in the domain.  The telemetry

   systems may be configured to provide= necessary and useful pieces of

   information, such as a preliminary a= nalysis of the observation to the

   orchestrator.

 

   The orchestrator analyses the variou= s information it receives from

   specialized equipement, and elaborat= es one or multiple DDoS

   mitigation strategies.  In some= case, a manual confirmation may also

   be required to choose a proposed str= ategy or to initiate a DDoS

   mitigation.  The DDoS mitigatio= n may consist of multiple steps such

   as configuring the network, various = hardware, or updating already

   instantiated DDoS mitigation functio= ns.  In some cases, some specific

   virtual DDoS mitigation functions mu= st be instantiated and properly

   ordered.  Eventually, the coord= ination of the mitigation may involve

 

 

 

 

Dobbins, et al.  &nbs= p;        Expires May 17, 2018 &nbs= p;            &= nbsp;  [Page 19]

 

 

Internet-Draft      = ;         DOTS Use Cases  = ;            &n= bsp; November 2017

 

 

   external DDoS resources such as a tr= ansit provider (Section 3.1.1.1)

   or an MSSP (Section 3.1.2.1).

 

   The communications used to trigger a= DDoS mitigation between the

   telemetry and monitoring systems and= the orchestrator is performed

   using DOTS.  The telemetry syst= ems implements a DOTS client while the

   orchestrator implements a DOTS serve= r.

 

   The communication between a network = administrator and the

   orchestrator is also performed using= DOTS.  The network administrator

   via its web interfaces implements a = DOTS client, while the

   Orchestrator implements a DOTS serve= r.

 

   The communication between the Orches= trator and the DDoS mitigation

   systems is performed using DOTS.&nbs= p; The Orchestrator implements a DOTS

   client while the DDoS mitigation sys= tems implement a DOTS server.

 

   The configuration aspects of each DD= oS mitigation system, as well as

   the instantiations of DDoS mitigatio= n functions or network

   configuration is not part of DOTS.&n= bsp; Similarly, the discovery of

   available DDoS mitigation functions = is not part of DOTS.

 

 

        &= nbsp;     +----------+

        &= nbsp;     | network  |C

        &= nbsp;     | adminis  |<-+

        &= nbsp;     | trator   |  |

        &= nbsp;     +----------+  |

        &= nbsp;           &nbs= p;       |      = ;            &n= bsp;    (internal)

        &= nbsp;     +----------+  | S+----------= ----+     +-----------+

        &= nbsp;     |telemetry/|  +->|  &nb= sp;           |C &nb= sp; S| DDoS      |+

        &= nbsp;     |monitoring|<--->| Orchestrator |<--= ->| mitigation||

        &= nbsp;     |systems   |C   S| &= nbsp;            |&l= t;-+  | systems   ||

        &= nbsp;     +----------+     = +--------------+C |  +-----------+|

        &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;   |    +----------+

        &= nbsp;            &nb= sp;            =             &nb= sp;  |

        &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;   |  (external)

        &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;   |  +-----------+

        &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;   | S| DDoS      |

        &= nbsp;           &nbs= p;             =             &nb= sp;  +->| mitigation|

        &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;      | systems   |

        &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;      +-----------+

        &= nbsp;     * C is for DOTS client functionality

        &= nbsp;     * S is for DOTS server functionality

 

      = Figure 1: DDoS Orchestration

 

 

 

 

 

Dobbins, et al.  &nbs= p;        Expires May 17, 2018&nb= sp;            =     [Page 20]

 

 

Internet-Draft      = ;         DOTS Use Cases  = ;            &n= bsp; November 2017

 

 

   The telemetry systems monitor variou= s traffic network and perform

   their measurement tasks.  They = are configured so that when an event

   or some measurements reach a predefi= ned level to report a DOTS

   mitigation request to the Orchestrat= or.  The DOTS mitigation request

   may be associated with some element = such as specific reporting.

 

   Upon receipt of the DOTS mitigation = request from the telemetry

   system, the Orchestrator responds wi= th an acknowledgement, to avoid

   retransmission of the request for mi= tigation.  The status of the DDoS

   mitigation indicates the Orchestrato= r is in an analysing phase.  The

   Orchestrator begins collecting vario= us information from various

   telemetry systems in order to correl= ate the measurements and provide

  an analysis of the event.  Event= ually, the Orchestrator may ask

   additional information to the teleme= try system, however, the

   collection of these information is p= erformed outside DOTS.

 

   The orchestrator may be configured t= o start a DDoS mitigation upon

   approval from a network administrato= r.  The analysis from the

   orchestrator is reported to the netw= ork administrator via a web

   interface.  If the network admi= nistrator decides to start the

   mitigation, she orders through her w= eb interface a DOTS client to

   send a request for DDoS mitigation.&= nbsp; This request is expected to be

   associated with a context that ident= ifies the DDoS mitigation

   selected.

 

   Upon receiving the DOTS request for = DDoS mitigation from the network

   administrator, the orchestrator orch= estrates the DDoS mitigation

   according to the specified strategy.=   Its status indicates the DDoS

   mitigation is starting while not eff= ective.

 

   Orchestration of the DDoS mitigation= systems works similarly as

   described in Section 3.1.1.1 and Sec= tion 3.1.2.1.  The Orchestrator

   indicates with its status whether th= e DDoS Mitigation is effective.

 

   When the DDoS mitigation is finished= on the DDoS mitigation systems,

   the orchestrator indicates to the Te= lemetry systems as well as to the

   network administrator the DDoS mitig= ation is finished.

 

4.  Security Considerations

 

   DOTS is at risk from four primary fo= rms of attack: DOTS agent

   impersonation, traffic injection, si= gnal-blocking, and DDoS attacks.

  Associated security requirements and = additional ones are defined in

   [I-D.ietf-dots-requirements].

 

   These security risks can be managed = through current secure

   communications best practices.<= /o:p>

   DOTS is not subject to anything new = or unique in this area.

 

 

 

Dobbins, et al.  &nbs= p;        Expires May 17, 2018 &nbs= p;            &= nbsp;  [Page 21]

 

 

Internet-Draft      = ;         DOTS Use Cases  = ;            &n= bsp; November 2017

 

 

5.  IANA Considerations

 

   No IANA considerations exist for thi= s document at this time.

 

6.  Acknowledgments

 

   The authors would like to thank amon= g others Tirumaleswar Reddy;

   Andrew Mortensen; Mohamed Boucadaire= ; Artyom Gavrichenkov; and the

   DOTS WG chairs, Roman D.  Danyl= iw and Tobias Gondrom, for their

   valuable feedback.

 

7.  References

 

7.1.  Normative References

 

   [RFC2119]  Bradner, S., "K= ey words for use in RFCs to Indicate

        &= nbsp;     Requirement Levels", BCP 14, RFC 2119,

        &= nbsp;     DOI 10.17487/RFC2119, March 1997, <https:/= /www.rfc-

        &= nbsp;     editor.org/info/rfc2119>.

 

7.2.  Informative References

 

   [I-D.ietf-dots-requirements]

        &= nbsp;     Mortensen, A., Moskowitz, R., and T. Reddy, &= quot;Distributed

        &= nbsp;     Denial of Service (DDoS) Open Threat Signalin= g

        &= nbsp;     Requirements", draft-ietf-dots-requireme= nts-07 (work in

        &= nbsp;     progress), October 2017.

 

   [RFC6335]  Cotton, M., Eggert, = L., Touch, J., Westerlund, M., and S.

        &= nbsp;     Cheshire, "Internet Assigned Numbers Aut= hority (IANA)

        &= nbsp;     Procedures for the Management of the Service = Name and

        &= nbsp;     Transport Protocol Port Number Registry"= , BCP 165,

        &= nbsp;     RFC 6335, DOI 10.17487/RFC6335, August 2011,<= o:p>

        &= nbsp;     <https://www.rfc-editor.org/info/rfc6335&g= t;.

 

   [RFC7368]  Chown, T., Ed., Arkk= o, J., Brandt, A., Troan, O., and J.

        &= nbsp;     Weil, "IPv6 Home Networking Architecture= Principles",

        &= nbsp;     RFC 7368, DOI 10.17487/RFC7368, October 2014,=

        &= nbsp;     <https://www.rfc-editor.org/info/rfc7368&g= t;.

 

Authors' Addresses

 

   Roland Dobbins

   Arbor Networks

   Singapore

 

   EMail: rdobbins@arbor.net=

 

 

 

 

Dobbins, et al.  &nbs= p;        Expires May 17, 2018 &nbs= p;            &= nbsp;  [Page 22]

 

 

Internet-Draft      = ;         DOTS Use Cases  = ;            &n= bsp; November 2017

 

 

   Daniel Migault

   Ericsson

   8400 boulevard Decarie

   Montreal, QC  H4P 2N2

   Canada

 

   EMail: daniel.migault@ericsson.com

 

 

   Stefan Fouant

   USA

 

   EMail: stefan.fouant@copperriverit.c= om

 

 

   Robert Moskowitz

   HTT Consulting

   Oak Park, MI  48237<= /p>

   USA

 

   EMail: rgm@labs.ht= t-consult.com

 

 

   Nik Teague<= o:p>

   Verisign

   12061 Bluemont Way

   Reston, VA  20190

 

   EMail: nteague@ver= isign.com

 

 

   Liang Xia

   Huawei=

   No. 101, Software Avenue, Yuhuatai D= istrict

   Nanjing

   China

 

   EMail: Frank.xialiang@huawei.com

 

 

   Kaname Nishizuka

   NTT Communications

   GranPark 16F 3-4-1 Shibaura, Minato-= ku

   Tokyo  108-81= 18

   Japan

 

   EMail: kaname@nttv= 6.jp

 

 

 

 

Dobbins, et al.  &nbs= p;        Expires May 17, 2018 &nbs= p;            &= nbsp;  [Page 23]

 

--_000_2DD56D786E600F45AC6BDE7DA4E8A8C118DF3250eusaamb107erics_-- From nobody Mon Mar 19 23:35:57 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 5869B120724; Mon, 19 Mar 2018 23:35:56 -0700 (PDT) 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.75.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152152775630.9917.15460684978435417819@ietfa.amsl.com> Date: Mon, 19 Mar 2018 23:35:56 -0700 Archived-At: Subject: [Dots] I-D Action: draft-ietf-dots-architecture-06.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, 20 Mar 2018 06:35:56 -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) Architecture Authors : Andrew Mortensen Flemming Andreasen Tirumaleswar Reddy Christopher Gray Rich Compton Nik Teague Filename : draft-ietf-dots-architecture-06.txt Pages : 32 Date : 2018-03-19 Abstract: This document describes an architecture for establishing and maintaining Distributed Denial of Service (DDoS) Open Threat Signaling (DOTS) within and between domains. The document does not specify protocols or protocol extensions, instead focusing on defining architectural relationships, components and concepts used in a DOTS deployment. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dots-architecture/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-dots-architecture-06 https://datatracker.ietf.org/doc/html/draft-ietf-dots-architecture-06 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dots-architecture-06 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 Mon Mar 19 23:37: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 A21F8124D68 for ; Mon, 19 Mar 2018 23:37:24 -0700 (PDT) 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 oB8WJI0MToFa for ; Mon, 19 Mar 2018 23:37:22 -0700 (PDT) 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 48910120724 for ; Mon, 19 Mar 2018 23:37:22 -0700 (PDT) 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 w2K6axeh021975 for ; Tue, 20 Mar 2018 02:37:21 -0400 Received: from nam01-bn3-obe.outbound.protection.outlook.com (mail-bn3nam01lp0181.outbound.protection.outlook.com [216.32.180.181]) by mx0b-00196b01.pphosted.com with ESMTP id 2grv8vjrur-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT) for ; Tue, 20 Mar 2018 02:37:21 -0400 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=rGt1NkMv2JtxLMDku4MBZIjh97tBbsmslXlxrDaK1Dw=; b=FE7Li9KTnw6vH15HicjJI7PpxRL9VRgpfAOwYa6fjCcfM67uY2hzIJYG082wJCxFDK5q+zCENQetvL1AIvSl4XtcuXlRZ7AJOegD6vXatKf81Irc+c29ZqqpXbbv5i/XtvbBfoG0EyeA7MEKCE1EKsm/sKxWNUy+quqDT2eIt5I= Received: from SN2PR01MB2063.prod.exchangelabs.com (10.166.208.138) by SN2PR01MB2095.prod.exchangelabs.com (10.166.208.146) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.588.14; Tue, 20 Mar 2018 06:37:18 +0000 Received: from SN2PR01MB2063.prod.exchangelabs.com ([fe80::a4ce:8607:3de7:7e9]) by SN2PR01MB2063.prod.exchangelabs.com ([fe80::a4ce:8607:3de7:7e9%17]) with mapi id 15.20.0588.017; Tue, 20 Mar 2018 06:37:18 +0000 From: "Mortensen, Andrew" To: dots Thread-Topic: [Dots] I-D Action: draft-ietf-dots-architecture-06.txt Thread-Index: AQHTwBW2lzOJddNcyEiUJ9wfyyDozg== Date: Tue, 20 Mar 2018 06:37:18 +0000 Message-ID: References: <152152775630.9917.15460684978435417819@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; SN2PR01MB2095; 7:FoSBaH3eUHZZlXnd6/Fj8w9jXZ51Z0OCHQe+NwNhqG853Q3kVJh4vn4NPmlY/AF4GzqHZTAtd0pJWoOHyykeDvyqNaPNndrF3K6t/MO6a2H9bieertTa9oWvRPB1b58Dzn0sSyX8ztMyG2ZZc3ADEJbczp+2lpuYkp6J02s4mtLnfKCCNsWmZl06oFVqQSJDVDo+9T0lMdpT0/VS6ewvgCljLh9n8YOJr9Nc/Q1qnD7FaO80xB1znN3YkVAtKHah x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: ff876a56-2f29-4807-9387-08d58e2d06e8 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(4604075)(3008032)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7153060)(7193020); SRVR:SN2PR01MB2095; x-ms-traffictypediagnostic: SN2PR01MB2095: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(120809045254105); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040522)(2401047)(5005006)(8121501046)(3231221)(944501308)(52105095)(10201501046)(93006095)(93001095)(3002001)(6041310)(20161123558120)(20161123562045)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123564045)(6072148)(201708071742011); SRVR:SN2PR01MB2095; BCL:0; PCL:0; RULEID:; SRVR:SN2PR01MB2095; x-forefront-prvs: 061725F016 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39380400002)(376002)(396003)(346002)(366004)(39860400002)(377424004)(189003)(199004)(316002)(97736004)(6506007)(36756003)(2906002)(14454004)(7736002)(606006)(8676002)(2900100001)(8936002)(5250100002)(81156014)(81166006)(3660700001)(5660300001)(33656002)(102836004)(186003)(26005)(68736007)(229853002)(6486002)(6306002)(6512007)(54896002)(236005)(105586002)(66066001)(3280700002)(25786009)(76176011)(6916009)(99286004)(966005)(106356001)(53936002)(6436002)(3846002)(6116002)(83716003)(2473003)(82746002)(86362001)(478600001); DIR:OUT; SFP:1102; SCL:1; SRVR:SN2PR01MB2095; H:SN2PR01MB2063.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: v2KGB3ga6u0aGFSTTuRawayuHXU/O2rfawKspw2fRu0ryAC6Yb7T3dRnxVFPLAZCEYCao7uvpA7EQEaEscGaFrFOGPAVNyDnUO/1fjeVD3jraxc8HI7XIW0DV4wJ6UBVphKlGA5dFFTm/fslrv5rqh5NjEHWhOEcWd8Mizm9KJdSmcD12bm2I7yV0OVm+xzd7pTF1Id7HxC3LTJGe6QEYDIy7Ic+kg2oBDC34ibjp4Ugs2ggOf3zxy6nHLxUKdJ7xxT8Sriqi06phKZVFmDszbI/nr+B3xiUkmtqM4T4Ae4dtGVDWwiRpx7gNBVNNvBP7giJiB1TPnH58ofd7DZ3fQ== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_B7E91B57D9C9448AB0881A660C1713C4arbornet_" MIME-Version: 1.0 X-OriginatorOrg: arbor.net X-MS-Exchange-CrossTenant-Network-Message-Id: ff876a56-2f29-4807-9387-08d58e2d06e8 X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Mar 2018 06:37:18.2121 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 54f11205-d4aa-4809-bd36-0b542199c5b2 X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN2PR01MB2095 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-03-20_02:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1803200080 Archived-At: Subject: [Dots] Fwd: I-D Action: draft-ietf-dots-architecture-06.txt X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Mar 2018 06:37:24 -0000 --_000_B7E91B57D9C9448AB0881A660C1713C4arbornet_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable This revision adds a new NAT considerations section, mostly covering how to= address mapping an internal address to a public mitigation scope. andrew Begin forwarded message: From: internet-drafts@ietf.org Subject: [Dots] I-D Action: draft-ietf-dots-architecture-06.txt Date: March 20, 2018 at 2:35:56 AM EDT 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 Open Threat Signalin= g (DOTS) Architecture Authors : Andrew Mortensen Flemming Andreasen Tirumaleswar Reddy Christopher Gray Rich Compton Nik Teague Filename : draft-ietf-dots-architecture-06.txt Pages : 32 Date : 2018-03-19 Abstract: This document describes an architecture for establishing and maintaining Distributed Denial of Service (DDoS) Open Threat Signaling (DOTS) within and between domains. The document does not specify protocols or protocol extensions, instead focusing on defining architectural relationships, components and concepts used in a DOTS deployment. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dots-architecture/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-dots-architecture-06 https://datatracker.ietf.org/doc/html/draft-ietf-dots-architecture-06 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dots-architecture-06 Please note that it may take a couple of minutes from the time of submissio= n 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 --_000_B7E91B57D9C9448AB0881A660C1713C4arbornet_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable This revision adds a new NAT considerations section, mostly covering how to= address mapping an internal address to a public mitigation scope.

andrew


Begin forwarded message:

From: internet-drafts@ietf.org
Subject: [Dots] I-D Action: draft-= ietf-dots-architecture-06.txt
Date: March 20, 2018 at 2:35:56 AM EDT
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 Open Threa= t Signaling (DOTS) Architecture
       Authors     &= nbsp;   : Andrew Mortensen
            &nb= sp;            = Flemming Andreasen
            &nb= sp;            = Tirumaleswar Reddy
            &nb= sp;            = Christopher Gray
            &nb= sp;            = Rich Compton
            &nb= sp;            = Nik Teague
Filename &n= bsp;      : draft-ietf-dots-architecture-06.t= xt
Pages  = ;         : 32
Date  =           : 2018-03-19
Abstract:
  This document describes an architecture for establishing and   maintaining Distributed Denial of Service (DDoS) Open Threat   Signaling (DOTS) within and between domains.  The document= does not
  specify protocols or protocol extensions, instead focusing on   defining architectural relationships, components and concepts u= sed in
  a DOTS deployment.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-dots-architecture/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-dots-architecture-06
https://datatracker.ietf.org/doc/html/draft-ietf-dots-architecture-06

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dots-architecture-06


Please note that it may take a couple of minutes from the time of submissio= n
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

--_000_B7E91B57D9C9448AB0881A660C1713C4arbornet_-- From nobody Tue Mar 20 01: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 7D8251201F2 for ; Tue, 20 Mar 2018 01:32:00 -0700 (PDT) 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 KsDQHM2z2Lim for ; Tue, 20 Mar 2018 01:31:58 -0700 (PDT) Received: from DNVWSMAILOUT1.mcafee.com (dnvwsmailout1.mcafee.com [161.69.31.173]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E65111200C5 for ; Tue, 20 Mar 2018 01:31:57 -0700 (PDT) X-NAI-Header: Modified by McAfee Email Gateway (5500) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mcafee.com; s=s_mcafee; t=1521534712; 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:MIME-Version:X-MS-Exchange-CrossTenant-Network-Message-Id: X-MS-Exchange-CrossTenant-originalarrivaltime: X-MS-Exchange-CrossTenant-fromentityheader: X-MS-Exchange-CrossTenant-id:X-MS-Exchange-Transport-CrossTenantHeadersStamped: X-OriginatorOrg:X-NAI-Spam-Flag:X-NAI-Spam-Threshold: X-NAI-Spam-Score:X-NAI-Spam-Version; bh=q wOy12x587UQMrSYfzbdEfS82dWQQV91glffbL3jkX 0=; b=J3btRS/zTOBI6qhCyz5AX3Yn+X9uZojs5VYQUaOz3EQv SXdXyAYx2A+TXm64u4tnrb0YRG377SN9tsNsupce24OvR1S/C9 XvXh5vSlJrBTodggiIuKUMQIey6NxfcDvoyBYpGgFsvZ3eIdLM P/gtLPayEho9rLnsOVwpWb4ATJU= 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 6013_de49_06be507c_b6c5_40dc_840f_5681ff0bd4d8; Tue, 20 Mar 2018 03:31:52 -0500 Received: from DNVEXAPP1N04.corpzone.internalzone.com (10.44.48.88) by DNVEXAPP1N04.corpzone.internalzone.com (10.44.48.88) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Tue, 20 Mar 2018 02:31:25 -0600 Received: from DNVO365EDGE1.corpzone.internalzone.com (10.44.176.66) by DNVEXAPP1N04.corpzone.internalzone.com (10.44.48.88) with Microsoft SMTP Server (TLS) id 15.0.1347.2 via Frontend Transport; Tue, 20 Mar 2018 02:31:25 -0600 Received: from NAM03-BY2-obe.outbound.protection.outlook.com (10.44.176.243) by edge.mcafee.com (10.44.176.66) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Tue, 20 Mar 2018 02:31:24 -0600 Received: from BN6PR16MB1425.namprd16.prod.outlook.com (10.172.207.19) by BN6PR16MB1827.namprd16.prod.outlook.com (10.172.29.10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.567.14; Tue, 20 Mar 2018 08:31:24 +0000 Received: from BN6PR16MB1425.namprd16.prod.outlook.com ([10.172.207.19]) by BN6PR16MB1425.namprd16.prod.outlook.com ([10.172.207.19]) with mapi id 15.20.0588.017; Tue, 20 Mar 2018 08:31:24 +0000 From: "Konda, Tirumaleswar Reddy" To: "Mortensen, Andrew" , dots Thread-Topic: [Dots] Fwd: I-D Action: draft-ietf-dots-architecture-06.txt Thread-Index: AQHTwBYDXdaQAYYfiEahktd6LaKAP6PYyuMA Date: Tue, 20 Mar 2018 08:31:23 +0000 Message-ID: References: <152152775630.9917.15460684978435417819@ietfa.amsl.com> 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.200.100 dlp-reaction: no-action authentication-results: spf=none (sender IP is ) smtp.mailfrom=TirumaleswarReddy_Konda@McAfee.com; x-originating-ip: [185.125.226.2] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BN6PR16MB1827; 7:+v2eJ7eIndiZr6Y7esWUclk5VSPX22oEg0sdPKRy2GaqXmlZDKGaCfHQvDoVSUBvckS7AjV9E4xelL178lzHzTAxwCCjAuyRKQfPHyLxcvwURwV5iDerKEvwGFZQo+a1eq7/63dxYAP0uYc3MhxWpHFGG6rE231m2XRfrOJpk/iaOXQsgumk2fzaQuxc4Uhtl53JlQ/WWm6g0OOr55+OppY0D/Nwx5cUMDRuNe+6XsGxFzaRPMu7l2V7MgXQRmHM x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: 1f129e7a-c903-4cd8-5336-08d58e3cf74b x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(4604075)(3008032)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7153060)(7193020); SRVR:BN6PR16MB1827; x-ms-traffictypediagnostic: BN6PR16MB1827: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(158342451672863)(120809045254105)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(10201501046)(3002001)(3231221)(944501309)(52105095)(93006095)(93001095)(6041310)(20161123562045)(20161123560045)(20161123558120)(20161123564045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(6072148)(201708071742011); SRVR:BN6PR16MB1827; BCL:0; PCL:0; RULEID:; SRVR:BN6PR16MB1827; x-forefront-prvs: 061725F016 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39860400002)(396003)(39380400002)(346002)(366004)(376002)(377424004)(32952001)(189003)(199004)(55016002)(9686003)(236005)(97736004)(6116002)(790700001)(66066001)(2900100001)(54896002)(6306002)(6436002)(86362001)(53936002)(606006)(7696005)(2906002)(99286004)(25786009)(80792005)(2950100002)(74316002)(3280700002)(3846002)(229853002)(6246003)(110136005)(81166006)(186003)(5660300001)(316002)(3660700001)(102836004)(59450400001)(478600001)(6506007)(105586002)(7736002)(33656002)(26005)(77096007)(72206003)(966005)(68736007)(76176011)(19609705001)(9326002)(8936002)(14454004)(81156014)(8676002)(106356001)(53546011)(85282002); DIR:OUT; SFP:1101; SCL:1; SRVR:BN6PR16MB1827; H:BN6PR16MB1425.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: YX7z7J0E+zGMkiQn4jU2pVn7C8YJ17qcY8sfvYLBgTz1BjOS01hShqo9s9xIr5MpCP+aX8OnFs1rIifNLQkWZ78rY+PyWvQ0AzQ6tPGXxNberWJdkUZMKQ28G5/uXOW+knxzi/FiR44Hpc26LdKpwne4rZ0/rBm4/utd6QjRzlDbW3sWZwLbhVCpqNzvCl/n1Vm7utCIOoIvTk0W6eV0KfmZ6Rm60U5RXdfXPsHW2mfU94WNJg7rk3JFejKzgwzpXK1Ug3ztBNpSfNAfr6Y/XcIu1T12xeVmJAlikOZbCf3PNH9tMBT2M/2eMQZuvQsUv86wEWye00HCty4Ncs3ymg== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BN6PR16MB142506557151746C4804E0C3EAAB0BN6PR16MB1425namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 1f129e7a-c903-4cd8-5336-08d58e3cf74b X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Mar 2018 08:31:23.8582 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4943e38c-6dd4-428c-886d-24932bc2d5de X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR16MB1827 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 <6245> : inlines <6506> : streams <1781727> : uri <2611534> Archived-At: Subject: Re: [Dots] Fwd: I-D Action: draft-ietf-dots-architecture-06.txt X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Mar 2018 08:32:00 -0000 --_000_BN6PR16MB142506557151746C4804E0C3EAAB0BN6PR16MB1425namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Andrew, Section 3.2.5.2> 1) If internal resources are behind NAT, they are mostly likely behind double NAT (NAT444), STUN discovers the public IP address and port created by the NAT closest to the server. The proposed text uses both external address and reflexive transport addres= s (external IP address and port) You may want to use "reflexive transport address" and point to RFC5389 for = its definition. 2) Public STUN servers typically use clear text, without message-integrity and= the response can be modified by a man-in-the-middle attacker (TRAM WG has recently standardized STUN ove= r DTLS, but I don't think is widely deployed). ICE connectivity checks is used by the media endpoints to detect the above = attack. The internal resource needs to use a mechanism like ICE, TURN (authenticate= d TURN server) or secure transport to the STUN server to validate that the STUN response is authentic. 3) STUN will not work if the internal resource is behind NAT that uses Address= -Dependent Mapping (see https://tools.ietf.org/html/rfc5780#section-4.3). 4) You are assuming DOTS client and internal resource are not co-located (An a= pplication can also have an integrated DOTS server). 5) Section 3.2.5.3, reverse DNS lookup can be spoofed unless the response is s= igned. 6) Section 3.2.5.1, How will direct-mapping work in the most deployments where= the mapping is dynamic (other than NPTv6) ? Cheers, Tiru From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Mortensen, Andrew Sent: Tuesday, March 20, 2018 6:37 AM To: dots Subject: [Dots] Fwd: I-D Action: draft-ietf-dots-architecture-06.txt This revision adds a new NAT considerations section, mostly covering how to= address mapping an internal address to a public mitigation scope. andrew Begin forwarded message: From: internet-drafts@ietf.org Subject: [Dots] I-D Action: draft-ietf-dots-architecture-06.txt Date: March 20, 2018 at 2:35:56 AM EDT 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 Open Threat Signalin= g (DOTS) Architecture Authors : Andrew Mortensen Flemming Andreasen Tirumaleswar Reddy Christopher Gray Rich Compton Nik Teague Filename : draft-ietf-dots-architecture-06.txt Pages : 32 Date : 2018-03-19 Abstract: This document describes an architecture for establishing and maintaining Distributed Denial of Service (DDoS) Open Threat Signaling (DOTS) within and between domains. The document does not specify protocols or protocol extensions, instead focusing on defining architectural relationships, components and concepts used in a DOTS deployment. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dots-architecture/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-dots-architecture-06 https://datatracker.ietf.org/doc/html/draft-ietf-dots-architecture-06 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dots-architecture-06 Please note that it may take a couple of minutes from the time of submissio= n 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 --_000_BN6PR16MB142506557151746C4804E0C3EAAB0BN6PR16MB1425namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Andrew,

 

Section 3.2.5.2>

 

1)

If internal resources are behind NAT, they are =

mostly likely behind double NAT (NAT444), STUN<= /o:p>

discovers the public IP address and port created

by the NAT closest to the server.

 

The proposed text uses both external address and ref= lexive transport address (external IP address and port)

You may want to use "reflexive transport addres= s" and point to RFC5389 for its definition.

 

2)

Public STUN servers typically use clear text, withou= t message-integrity and the response can be modified

by a man-in-the-middle attacker (TRAM WG has recentl= y standardized STUN over DTLS, but I don't think is widely deployed).

ICE connectivity checks is used by the media endpoin= ts to detect the above attack.

 

The internal resource needs to use a mechanism like = ICE, TURN (authenticated TURN server) or secure transport to the STUN serve= r

to validate that the STUN response is authentic.

 

3)

STUN will not work if the internal resource is behin= d NAT that uses Address-Dependent Mapping

(see https://tools.ietf.org/html/rfc5780#section-4.3= ).

 

4)

You are assuming DOTS client and internal resource a= re not co-located (An application

can also have an integrated DOTS server).

 

 

5)

Section 3.2.5.3, reverse DNS lookup can be spoofed u= nless the response is signed.

 

6)

Section 3.2.5.1, How will direct-mapping work in the= most deployments where the mapping is dynamic (other than NPTv6) ?

 

Cheers,

Tiru

 

From: Dots [mailto:dots-bounces@ietf.org] = On Behalf Of Mortensen, Andrew
Sent: Tuesday, March 20, 2018 6:37 AM
To: dots <dots@ietf.org>
Subject: [Dots] Fwd: I-D Action: draft-ietf-dots-architecture-06.txt=

 

This revision adds a new NAT considerations section,= mostly covering how to address mapping an internal address to a public mit= igation scope.

 

andrew

 



Begin forwarded message:

 

From: internet-drafts@ietf.org<= /o:p>

Subject: [Dots] I-D Action: draft-ietf-dots-architecture-06.txt=

Date: March 20, = 2018 at 2:35:56 AM EDT


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 Open Threa= t Signaling (DOTS) Architecture
       Authors     &= nbsp;   : Andrew Mortensen
            &nb= sp;            = Flemming Andreasen
            &nb= sp;            = Tirumaleswar Reddy
            &nb= sp;            = Christopher Gray
            &nb= sp;            = Rich Compton
            &nb= sp;            = Nik Teague
Filename        : draft-ietf-dots-archit= ecture-06.txt
Pages           : 32
Date            : 20= 18-03-19

Abstract:
  This document describes an architecture for establishing and   maintaining Distributed Denial of Service (DDoS) Open Threat   Signaling (DOTS) within and between domains.  The document= does not
  specify protocols or protocol extensions, instead focusing on   defining architectural relationships, components and concepts u= sed in
  a DOTS deployment.


The IETF datatracker status page for this draft is:
= https://datatracker.ietf.org/doc/draft-ietf-dots-architecture/

There are also htmlized versions available at:
htt= ps://tools.ietf.org/html/draft-ietf-dots-architecture-06
https://datatracker.ietf.org/doc/html/draft-ietf-dots-architecture-0= 6

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dots-architecture-06


Please note that it may take a couple of minutes from the time of submissio= n
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

 

--_000_BN6PR16MB142506557151746C4804E0C3EAAB0BN6PR16MB1425namp_-- From nobody Tue Mar 20 04:14:18 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 DAE91126CD6; Tue, 20 Mar 2018 04:14:17 -0700 (PDT) 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.75.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152154445784.9909.9322881790753347280@ietfa.amsl.com> Date: Tue, 20 Mar 2018 04:14:17 -0700 Archived-At: Subject: [Dots] I-D Action: draft-ietf-dots-use-cases-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: Tue, 20 Mar 2018 11:14:18 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DDoS Open Threat Signaling WG of the IETF. Title : Use cases for DDoS Open Threat Signaling Authors : Roland Dobbins Daniel Migault Stefan Fouant Robert Moskowitz Nik Teague Liang Xia Kaname Nishizuka Filename : draft-ietf-dots-use-cases-10.txt Pages : 23 Date : 2018-03-20 Abstract: The DDoS Open Threat Signaling (DOTS) effort is intended to provide a protocol to facilitate interoperability between multivendor DDoS mitigation solutions and services. This document presents use cases which describe the interactions expected between the DOTS components as well as DOTS messaging exchanges. The purpose of describing use cases is to identify the interacting DOTS components, how they collaborate and what are the types of information to be exchanged. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dots-use-cases/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-dots-use-cases-10 https://datatracker.ietf.org/doc/html/draft-ietf-dots-use-cases-10 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dots-use-cases-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 Mar 20 04:16: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 3F5AE126CD8 for ; Tue, 20 Mar 2018 04:16:54 -0700 (PDT) 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 XA5l9_I9Nmsw for ; Tue, 20 Mar 2018 04:16:52 -0700 (PDT) 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 C0C39126D0C for ; Tue, 20 Mar 2018 04:16:45 -0700 (PDT) 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 w2KB30qX004026 for ; Tue, 20 Mar 2018 07:16:43 -0400 Received: from nam03-by2-obe.outbound.protection.outlook.com (mail-by2nam03lp0047.outbound.protection.outlook.com [216.32.180.47]) by mx0b-00196b01.pphosted.com with ESMTP id 2grv8vjy47-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Tue, 20 Mar 2018 07:16:43 -0400 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=VOUXXObtS/Q2aJHgWZtMAP7Otm2nzSJHSFDWqzWKu88=; b=Oyy1pzOXUkSiejJei9t8cx244r7rHcM27M4foFCWJGOE2nYc8WGG5u6hD2Jt4CS7hyU+/STmjqTD4oRkV10d7xUKh4cTi82/q8Yi44BOylzQGtBH6JlSnrSwTvuKiO833/4ZkLFNYhRW9UkkTED8sIQVpJWwLYbTXskldsOH+u0= Received: from [172.19.254.106] (184.82.238.239) by CY4PR0101MB3175.prod.exchangelabs.com (2603:10b6:910:3f::23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.567.14; Tue, 20 Mar 2018 11:16:37 +0000 From: "Roland Dobbins" To: dots@ietf.org Date: Tue, 20 Mar 2018 18:16:22 +0700 X-Mailer: MailMate (1.11r5462) Message-ID: In-Reply-To: <152154445784.9909.9322881790753347280@ietfa.amsl.com> References: <152154445784.9909.9322881790753347280@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Originating-IP: [184.82.238.239] X-ClientProxiedBy: SG2PR06CA0100.apcprd06.prod.outlook.com (2603:1096:3:14::26) To CY4PR0101MB3175.prod.exchangelabs.com (2603:10b6:910:3f::23) X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: c236d7ed-eeef-4a2c-1beb-08d58e540cb5 X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(4604075)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7153060)(7193020); SRVR:CY4PR0101MB3175; X-Microsoft-Exchange-Diagnostics: 1; CY4PR0101MB3175; 3:/sFOzzEPny5XJEtFLKuxOI38br8CHN8Hmu5e7NdOu671XesUr86ftlmEulCySeJgs9w45IHOWxnWIu81XCB2Byz/rgWDt6Qh6G2JUe+ephP7B5Qp8Exwf0+3/jlxoo4w0cFMxoKa7WqjNjL403uXQZTz9nG6Xjt86Z/hCPz13Vvqzji+yY/QzllUHTdW+uNn7ujZyniMYoyrHFzzVILu86x5iiZBAMAicsf0lDLsCuJBnGBvkp7rcq23V5FnaGYb; 25:31VnLhN/J934pP/LdoSHTbcuTs/n1plks/ZBgySuxo8sEck9sZAej+aIZ5ghM2iyMC0HZrPJslf4yTvNYmxdFWP8C8o0RUkQ04/vsNnRf2Tu5fe0HxNULtT+NcnYhKB49PIadizOGzY1DmcYkfIsULg1pUXSMCRxV5qUoF4HRLmZGqwy3p2Ai+U274dpzGNJv7jkBgiiNsjeXX5cch8ak/Kctav/hEVgkbLxh5H9sW2LPSqHaFgUWYY6UBgH+RURZrhz9HwHfti76EIlLnhnvFnVcPDvfEllXMpnTxm3A8GUsZR2wz/eogLaGskFXdCirBKjzekepMwp2uOETGKnog==; 31:iQF4KmG/xFM1Dx32aqsjqMkal97QKsuHwvFMvv3h9DukBety4IP88ep/xof+JCEONHW6XrkUfqyZF0AXGnXMYgc4pae/hMPAb96balgOsGttu6OtHxrskMx8iCZkrUqMUaWsvUzCRpKV4UtYcVorT2nnYD4zk10AUgvpHuPBhgOJWT+MvSi0yqiPXEH8Mj/7aWHfZJhhQwlPt1zO5ZrkEJEV55Bt7AlxKQ2x7YbtBrQ= X-MS-TrafficTypeDiagnostic: CY4PR0101MB3175: X-Microsoft-Exchange-Diagnostics: 1; CY4PR0101MB3175; 20:oxzWafxED+BTxk/OOZ3cDBI0bBexDNTkfx5iEqnue7QVvvWgL1ZuzmqXAcddc9RK9JKhTi2fCIAKCFTcHZlN5tcqukd8HtJgbWPK/9SfaGiHfXiaJoGdY4pBRCXp5OYgi2rCIlq8JYYmpJVL2B5gM5OoYHD2+HG2IQT9Py/+l/kcex/I9hnEN5kRDALMJogdle0+FyoCW9U0+vmPlh+4iv43p5ukrQlrOQ5Ti02b93pbjXf+o7VSY2uZR8mEqKd6CNDslFr7hjHJykiyJAJ7m5eTEfB9JJstu0eM3GjfzVBuIGZvCRn9Brradx+y/i5J9mPv56DO/0CeRuU0PpmNDQ==; 4:xNN08G9v4GofqbtadEwbNgDIMZIa3/n5J/lhKIYPxI+e8OdhwwAJS5IcjhFHG/Z38JWnYlLV/618RiSR1K/XYc9gdvEWk68cE03eAalT9uy/cceE8bDmic1OLB/+Ilo/2CQIM2R6KRfUxCF1zdzXz9sTPSd/BAWzLESkX61SfObD9LGCm7sFHY3sw+lszm/5GBmIGjvZKh5PQN6rnadoXisrHA7enUtDhMkBcAohyShrE4OVZz1S/K4+tGAMoKzfkXZ/MzhzA3xpt7SpodB4Mg== X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040522)(2401047)(5005006)(8121501046)(93006095)(93001095)(3002001)(10201501046)(3231221)(944501244)(52105095)(6041310)(20161123560045)(20161123564045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123558120)(20161123562045)(6072148)(201708071742011); SRVR:CY4PR0101MB3175; BCL:0; PCL:0; RULEID:; SRVR:CY4PR0101MB3175; X-Forefront-PRVS: 061725F016 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(6049001)(39380400002)(39860400002)(366004)(396003)(346002)(376002)(189003)(199004)(186003)(86362001)(53936002)(7736002)(478600001)(3846002)(6666003)(2950100002)(6116002)(26005)(16576012)(77096007)(105586002)(2361001)(316002)(8936002)(83716003)(229853002)(53546011)(16526019)(6916009)(305945005)(25786009)(386003)(2351001)(47776003)(81156014)(82746002)(51416003)(52116002)(67846002)(76176011)(66066001)(106356001)(50466002)(81166006)(558084003)(8676002)(2906002)(33656002)(5660300001)(36756003)(68736007)(16586007)(6486002)(50226002)(6246003)(97736004); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR0101MB3175; H:[172.19.254.106]; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Received-SPF: None (protection.outlook.com: arbor.net does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; CY4PR0101MB3175; 23:gpnZ6GsOLGWulXMnIyl1KIopwQdaaBOLzGK9tVz?= =?us-ascii?Q?WBrE3zaScJlMhoyZY+G9POnCaHKxoYCdaWceHJxuNqVuI4ajzalKofIlR0nN?= =?us-ascii?Q?La3Piv3L2pTm4vscZkqyBvoqebr8JA4f5BlYfM1FTs2PsYkaNoJdPR/QuycR?= =?us-ascii?Q?Z8a8vs+oB/T97pQGd5Y4HeQknV3fWWoEEidHMdc7yItjsrVR2OQnfPJ6oaBo?= =?us-ascii?Q?JO7Nzx7J/BcKNm6mB5QiF75zjtGGLzOhpx1oazyTXAyv1rTToaYdpL0V/jNy?= =?us-ascii?Q?BiWo/7PVE+foUztXVAWJU07mNyl+C8YacXDljgFkf9XoL+4zqVZSlGT82be1?= =?us-ascii?Q?ozmLpzYCPsyJBqiIdbLDEQGZZj0m8cjK61wQuBE7/AzbI8h8gZ7hTjVHuUi+?= =?us-ascii?Q?72hPIqE4mos1U2WcX/nKfAmvQlP4uocCA2xmzEjr+3sNr1abLp646r7Y9m7S?= =?us-ascii?Q?fdbDrU747NwwcY0aEOd5oQCkuVaVdYU8QnYoglJf/2BcHpYE7Oe+ucJHAywV?= =?us-ascii?Q?1FXTPGNbgy/Y/ClONKb7ql2hoZ92t19C1aqw9KIvpwAzkrqfofsA4MAMUKkT?= =?us-ascii?Q?GTq//YW9BQ8cjB3+2gU5Kwm4hmNqfJvIETp2JDj5srKX/WijhmTvd+xQ5jQ7?= =?us-ascii?Q?Z/CvRMBe5kjwBoauf6GyHc+BQ/x0qu9XVrJvMndB87gR/otS0wkmNDhEQuqh?= =?us-ascii?Q?VCJphlUQfT190VFifSu/9a6BN0dfBQVlS1r/zCYLWyOD1WMwrhbZL0oaXJSp?= =?us-ascii?Q?jDnQYBEAyEfnWD3M5lDeWVVVDf5mui6nZLlt9w4hhH257lss/x8jFG51pnrL?= =?us-ascii?Q?l1y5G2EYzc41a9vDqAXxB+eh8PFfzBUhssNgbfTg7P5cjRpbaN1LjKJmo0iv?= =?us-ascii?Q?/kLmLR5WjCnNZFF69ZsxRoQ4HhF+C3a9hRTJTaGEXjc0hWvvQZJFw59ZhUBm?= =?us-ascii?Q?gsGj4IgAurXGW/oQ2l43sfHCkwv9sgz8tdiQpwpnSG9NVqZOgSq5MNc9sXI3?= =?us-ascii?Q?j2AeVv9nteM9k3L/08PRIcT3go63ILR+Pdgcwj1ddGt2wDQeG5+GhQ3DeV1+?= =?us-ascii?Q?in9cdiUra8J4UyQ3n+Q5vdH6XGwsMuTWcvrqwkWE547jfMLQmIaL66frmj4R?= =?us-ascii?Q?5Fe9QSnJHtFyt7v2y2E1AEHJW5sk7ryvXXh+eElGDgzgES37929sxFTiy8I3?= =?us-ascii?Q?fWboDwUGM/T+IS8yvQw2u7WVlscluRoZKUW/B/m3Ki5F61aibHdnuWO8rsz6?= =?us-ascii?Q?AstDCaRueX9IB4G9eqaRC7IUBJm6FvNiogq6u+jVRJaaRN6mic5Ts9wgYzXJ?= =?us-ascii?Q?KiA=3D=3D?= X-Microsoft-Antispam-Message-Info: YzpuqGKHfHTbpKo2NaNNkIVvww8P0eQhfQ6GLe2QUd6Og8aUua05I2A9Fh2z2cBhQOpEYAMGKbl6V3ErjYocj+ei7pu1UeWPXCGasZtDjBpeingcm8cN/Kbsrfc4+MOFzZJ0sOGL7u8Fgbiee4nARO1bKO1oZhhmgMv5VdjAcnEs2NjHMxC4EjA2bvk7Pfo9 X-Microsoft-Exchange-Diagnostics: 1; CY4PR0101MB3175; 6:uMIeCQfGE5ASmlJ2Jw+kUVGsTRL1k8ckgDvl8JNAQUiwaq2qd2CZDF0SQdUmxg/ln5lf5M+GvSaaB20+88JWK9gxFVLEvmASgyUB41RYAWXHOkhqJbWB/vM/K3RO5xA8XnKJDzxVXNMCpYVDCBiFD9Zi4Vau080HxtE4DcXpIKr4+KzuEwsWNBO0cZW9sodHyzCAOGt0hUJxMcwyVrZ4IwcWKO0npYEaL5SDJS8hPRsWIPNI2VwX+10/XT5FiGYGevm63kiZblTVQi7NVNKnQYQhqUDA7EKbZnjMLhk0x802E/13xOHo1GpHMDxHr+uMpyQvOrJq8072ZweXz8goap9CsYffBYlQFJPEL4yRqfU=; 5:vZU1bsd4Hn8a2B9G4ZX8+I68/32iQZ4mNTpuORGMUcELwf2YRb80lS54+AOzVLEBFM+uMQpuA6uf8dKqGebx4Tj0k5VuFOBuZNsimNLsgI1atrR5HZqGnvTAafGtGM7vO/7Z87rVq1Ec8V8jkcT5D3jRU/0z6RxMzN1NuJDq3ME=; 24:RKp8vQ6Lsn+PrpNHsi91hMy4HQy/HEgUhB0L7NwJ5x6vqkKG8ulHGFzgPYj/7UUdVSXyKH1c6w+UDJE5K95q7yhYTGzCbH0wqwdip7NTRoU=; 7:dDeBDzCUqn+40S6p8nQqqM7icIfH5Fd+TUfjk7FLp9q4KPkn3il9cdMU1IJZzLMBjGWDOROrHYhVJo+2cMw6RGaLhuUqhUJZqmzRoLQ30Z0dxk9YzxSVNHpyv/+5kS6ckxm1i9O3tbgeGh/vZ3oF3M+Elv36j2QvGR1hMqQkhlp4fdoH7Qs7+zxHAciYWt+DPyRJA7JKTwMMdqDASFmy4pBWgZRcpHtbHx+yo0gPrtEMusRYR0QE6R3dYxCclEvb SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: arbor.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 20 Mar 2018 11:16:37.6729 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: c236d7ed-eeef-4a2c-1beb-08d58e540cb5 X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 54f11205-d4aa-4809-bd36-0b542199c5b2 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR0101MB3175 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-03-20_05:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 priorityscore=1501 malwarescore=0 suspectscore=13 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=690 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1803200131 Archived-At: Subject: Re: [Dots] I-D Action: draft-ietf-dots-use-cases-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: Tue, 20 Mar 2018 11:16:54 -0000 On 20 Mar 2018, at 18:14, internet-drafts@ietf.org wrote: > Filename : draft-ietf-dots-use-cases-10.txt This version fixes nits and some grammatical errors, but does not contain any substantive revisions. ----------------------------------- Roland Dobbins From nobody Tue Mar 20 16:12: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 2BFE212D77B for ; Tue, 20 Mar 2018 16:12:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, 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 (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 jzKZH4vWgOe5 for ; Tue, 20 Mar 2018 16:12:37 -0700 (PDT) Received: from mail-lf0-x230.google.com (mail-lf0-x230.google.com [IPv6:2a00:1450:4010:c07::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4CA9312D77A for ; Tue, 20 Mar 2018 16:12:37 -0700 (PDT) Received: by mail-lf0-x230.google.com with SMTP id l4-v6so792344lfg.12 for ; Tue, 20 Mar 2018 16:12:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:from:date:message-id:subject:to; bh=Lk/ePewVzgGQGbGyxl03sWKGrZ9H/FXHP2ASfm5WquU=; b=MJhAd33ckgWl6zpH/b/8vvnzMdSLHmMbXk2x4ITiMyZ5GHlxVYKtPRVRFXZXQ6gXmO 06feitPcKrQx0rGinlbh1t/mMWS59nRgQ6/TyenYn6+gy9/9wBbklTrir5QkFTeW3TCS PiWCkdb40kMW2SVAEKo4ldolf6/e97WpeNZyoZhOJIwgKdKNc93V+iFU/k74ksUP8XfR qSyA3CKKNQMlgNjlzOPSDs/pInMP+yAzCg9IqjKxVVuvjsX7LCXqrhckuFDa6pwUOXEu T05BIXw+Kvuc6VXAWNys839Eb4qa+YUaRYekz7tMwyBkAYIPD+MNsdJObU7XInR/MHH6 04fQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:from:date:message-id:subject :to; bh=Lk/ePewVzgGQGbGyxl03sWKGrZ9H/FXHP2ASfm5WquU=; b=Q+FvrYQeqa1M2sjpk3C76nwHcyxz/bsrLEaNzQOdyL1rodcpa45agmchgCrQFJO6Sa tutPRdojfJWICWUeiZ/KhFdE3BcrsrUqtkNXKsIxNbEIjvRpGG9vCEggtoona1ihZGLs 9jiV/pVP6mUNP4Lq1TiYmPnmSJk9uZ+g+OpQpyHk19pnJVSAdK+lt9ysaF18LOP4iyzv sMW1u9OywRCtIK7QoExKNoI+c9vnRu+6DlS3jKPwTYdq/tyHtwy4IVaCJSFmW9K5HRhg /KGE9BZlH7HvtQiTmJsvb2ixgnx7cYLIZ/AoltqAqaZAzxaX1AvbFlVKMy0gCndPizG6 zqxQ== X-Gm-Message-State: AElRT7H//zkEal6eFUs9tfXIXSiXPamR/vnGBr2gqkDLriaY8LO5QDkt r9hEXGFY6dUtUvtGVIaEFZJVdiynFFSupbAZ6174kw== X-Google-Smtp-Source: AG47ELuc6W2j/TYKYnDmcCD3mZkXNLxHLUuqtQ2vtoxh2Pf6yS0Wm9Gz/gzegw64+jHbtvhe8lcm9gCQUrg0IdD5kvY= X-Received: by 10.46.155.9 with SMTP id u9mr7203786lji.54.1521587555323; Tue, 20 Mar 2018 16:12:35 -0700 (PDT) MIME-Version: 1.0 Sender: mglt.ietf@gmail.com Received: by 10.46.129.5 with HTTP; Tue, 20 Mar 2018 16:12:34 -0700 (PDT) From: Daniel Migault Date: Tue, 20 Mar 2018 19:12:34 -0400 X-Google-Sender-Auth: L8qtdcsoujaq5xIton4BauIajMY Message-ID: To: dots@ietf.org Content-Type: multipart/alternative; boundary="883d24f17d20bad4850567e0353c" Archived-At: Subject: [Dots] use case draft 11 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, 20 Mar 2018 23:12:39 -0000 --883d24f17d20bad4850567e0353c Content-Type: text/plain; charset="UTF-8" Hi, I push on the git an initial version of the draft-ietf-dots-use-cases-11. If you have any comment, please feel free to send them on the mailing list or directly to the git. If some of you are willing to discuss and work on it at 13:30, feel free to let me know. Yours, Daniel https://github.com/dotswg/dots-use-cases/pull/6/commits/f46dcf2c71b93621729be7fafc93de1d52e9a5c4 --883d24f17d20bad4850567e0353c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

I push on the git an initial version of t= he draft-ietf-dots-use-cases-11. If you have any comment, please feel free = to send them on the mailing list or directly to the git. If some of you are= willing to discuss and work on it at 13:30, feel free to let me know.
=
Yours,
Daniel

--883d24f17d20bad4850567e0353c-- From nobody Wed Mar 21 00:11:53 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 34F03120454 for ; Wed, 21 Mar 2018 00:11:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.229 X-Spam-Level: X-Spam-Status: No, score=-4.229 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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, 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 CZT7LMx45x-B for ; Wed, 21 Mar 2018 00:11:50 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 11DD61201FA for ; Wed, 21 Mar 2018 00:11:50 -0700 (PDT) Received: from lhreml702-cah.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id 6F3156841AA47; Wed, 21 Mar 2018 07:11:46 +0000 (GMT) Received: from DGGEML421-HUB.china.huawei.com (10.1.199.38) by lhreml702-cah.china.huawei.com (10.201.108.43) with Microsoft SMTP Server (TLS) id 14.3.382.0; Wed, 21 Mar 2018 07:11:48 +0000 Received: from DGGEML502-MBS.china.huawei.com ([169.254.3.252]) by dggeml421-hub.china.huawei.com ([10.1.199.38]) with mapi id 14.03.0361.001; Wed, 21 Mar 2018 15:11:41 +0800 From: "Xialiang (Frank, Network Integration Technology Research Dept)" To: Daniel Migault CC: "dots@ietf.org" Thread-Topic: [Dots] use case draft 11 Thread-Index: AQHTwKD3UCXz9oIJgUGbqWP/MpKIm6PaRhrQ Date: Wed, 21 Mar 2018 07:11:41 +0000 Message-ID: References: In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.82.13] Content-Type: multipart/alternative; boundary="_000_C02846B1344F344EB4FAA6FA7AF481F12BD0AC11DGGEML502MBSchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: [Dots] =?utf-8?b?562U5aSNOiAgdXNlIGNhc2UgZHJhZnQgMTE=?= 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, 21 Mar 2018 07:11:52 -0000 --_000_C02846B1344F344EB4FAA6FA7AF481F12BD0AC11DGGEML502MBSchi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgRGFuaWVsLA0KVGhhbmtzIGZvciB5b3VyIGxlYWRpbmcgd29yaywgSSB3aWxsIGZvbGxvdyBp dCBhbmQgY29udHJpYnV0ZSBkZWZpbml0ZWx5Lg0KDQpCLlIuDQpGcmFuaw0KDQrlj5Hku7bkuro6 IERvdHMgW21haWx0bzpkb3RzLWJvdW5jZXNAaWV0Zi5vcmddIOS7o+ihqCBEYW5pZWwgTWlnYXVs dA0K5Y+R6YCB5pe26Ze0OiAyMDE45bm0M+aciDIw5pelIDIzOjEzDQrmlLbku7bkuro6IGRvdHNA aWV0Zi5vcmcNCuS4u+mimDogW0RvdHNdIHVzZSBjYXNlIGRyYWZ0IDExDQoNCkhpLA0KDQpJIHB1 c2ggb24gdGhlIGdpdCBhbiBpbml0aWFsIHZlcnNpb24gb2YgdGhlIGRyYWZ0LWlldGYtZG90cy11 c2UtY2FzZXMtMTEuIElmIHlvdSBoYXZlIGFueSBjb21tZW50LCBwbGVhc2UgZmVlbCBmcmVlIHRv IHNlbmQgdGhlbSBvbiB0aGUgbWFpbGluZyBsaXN0IG9yIGRpcmVjdGx5IHRvIHRoZSBnaXQuIElm IHNvbWUgb2YgeW91IGFyZSB3aWxsaW5nIHRvIGRpc2N1c3MgYW5kIHdvcmsgb24gaXQgYXQgMTM6 MzAsIGZlZWwgZnJlZSB0byBsZXQgbWUga25vdy4NCllvdXJzLA0KRGFuaWVsDQoNCmh0dHBzOi8v Z2l0aHViLmNvbS9kb3Rzd2cvZG90cy11c2UtY2FzZXMvcHVsbC82L2NvbW1pdHMvZjQ2ZGNmMmM3 MWI5MzYyMTcyOWJlN2ZhZmM5M2RlMWQ1MmU5YTVjNA0K --_000_C02846B1344F344EB4FAA6FA7AF481F12BD0AC11DGGEML502MBSchi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 5a6L5L2TOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OuW+rui9r+mbhem7kTsN CglwYW5vc2UtMToyIDExIDUgMyAyIDIgNCAyIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFt aWx5OiJcQOWui+S9kyI7DQoJcGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OiJcQOW+rui9r+mbhem7kSI7DQoJcGFub3NlLTE6MiAxMSA1IDMg MiAyIDQgMiAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5N c29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4w MDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseTrlrovkvZM7fQ0KYTpsaW5r LCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1 ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBl cmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0K CXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNvLXN0 eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2Vy aWY7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpl eHBvcnQtb25seTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpAcGFnZSBX b3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA5MC4w cHQgNzIuMHB0IDkwLjBwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24x O30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRz IHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtp ZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1h cCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRp Zl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IlpILUNOIiBsaW5rPSJibHVlIiB2bGluaz0icHVy cGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkhpIERhbmllbCw8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPlRoYW5rcyBmb3IgeW91ciBsZWFkaW5nIHdvcmss IEkgd2lsbCBmb2xsb3cgaXQgYW5kIGNvbnRyaWJ1dGUgZGVmaW5pdGVseS48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+ Qi5SLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+RnJhbms8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O+W+rui9r+mbhem7kSZxdW90OyxzYW5zLXNlcmlmIj7lj5Hku7bkuro8c3BhbiBsYW5nPSJF Ti1VUyI+Ojwvc3Bhbj48L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDvlvq7ova/pm4Xpu5EmcXVvdDssc2Fucy1zZXJp ZiI+IERvdHMgW21haWx0bzpkb3RzLWJvdW5jZXNAaWV0Zi5vcmddDQo8L3NwYW4+PGI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q75b6u6L2v6ZuF6buRJnF1 b3Q7LHNhbnMtc2VyaWYiPuS7o+ihqCA8L3NwYW4+DQo8L2I+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O+W+rui9r+mbhem7kSZxdW90 OyxzYW5zLXNlcmlmIj5EYW5pZWwgTWlnYXVsdDxicj4NCjwvc3Bhbj48Yj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDvlvq7ova/pm4Xpu5EmcXVvdDssc2Fu cy1zZXJpZiI+5Y+R6YCB5pe26Ze0PHNwYW4gbGFuZz0iRU4tVVMiPjo8L3NwYW4+PC9zcGFuPjwv Yj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q75b6u6L2v6ZuF6buRJnF1b3Q7LHNhbnMtc2VyaWYiPiAyMDE4PC9zcGFuPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O+W+rui9r+mbhem7kSZxdW90 OyxzYW5zLXNlcmlmIj7lubQ8c3BhbiBsYW5nPSJFTi1VUyI+Mzwvc3Bhbj7mnIg8c3BhbiBsYW5n PSJFTi1VUyI+MjA8L3NwYW4+5pelPHNwYW4gbGFuZz0iRU4tVVMiPg0KIDIzOjEzPGJyPg0KPC9z cGFuPjxiPuaUtuS7tuS6ujxzcGFuIGxhbmc9IkVOLVVTIj46PC9zcGFuPjwvYj48c3BhbiBsYW5n PSJFTi1VUyI+IGRvdHNAaWV0Zi5vcmc8YnI+DQo8L3NwYW4+PGI+5Li76aKYPHNwYW4gbGFuZz0i RU4tVVMiPjo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIj4gW0RvdHNdIHVzZSBjYXNlIGRy YWZ0IDExPG86cD48L286cD48L3NwYW4+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+ PHNwYW4gbGFuZz0iRU4tVVMiPkhpLCA8YnI+DQo8YnI+DQpJIHB1c2ggb24gdGhlIGdpdCBhbiBp bml0aWFsIHZlcnNpb24gb2YgdGhlIGRyYWZ0LWlldGYtZG90cy11c2UtY2FzZXMtMTEuIElmIHlv dSBoYXZlIGFueSBjb21tZW50LCBwbGVhc2UgZmVlbCBmcmVlIHRvIHNlbmQgdGhlbSBvbiB0aGUg bWFpbGluZyBsaXN0IG9yIGRpcmVjdGx5IHRvIHRoZSBnaXQuIElmIHNvbWUgb2YgeW91IGFyZSB3 aWxsaW5nIHRvIGRpc2N1c3MgYW5kIHdvcmsgb24gaXQgYXQgMTM6MzAsIGZlZWwgZnJlZSB0byBs ZXQgbWUga25vdy4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5Zb3VycywgPG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdp bi1ib3R0b206MTIuMHB0Ij48c3BhbiBsYW5nPSJFTi1VUyI+RGFuaWVsPG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tVVMiPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vZ2l0aHViLmNvbS9kb3Rzd2cvZG90cy11c2Ut Y2FzZXMvcHVsbC82L2NvbW1pdHMvZjQ2ZGNmMmM3MWI5MzYyMTcyOWJlN2ZhZmM5M2RlMWQ1MmU5 YTVjNCI+aHR0cHM6Ly9naXRodWIuY29tL2RvdHN3Zy9kb3RzLXVzZS1jYXNlcy9wdWxsLzYvY29t bWl0cy9mNDZkY2YyYzcxYjkzNjIxNzI5YmU3ZmFmYzkzZGUxZDUyZTlhNWM0PC9hPjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4N Cg== --_000_C02846B1344F344EB4FAA6FA7AF481F12BD0AC11DGGEML502MBSchi_-- From nobody Wed Mar 21 02:36:25 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 F23BE12D95D; Wed, 21 Mar 2018 02:36:20 -0700 (PDT) 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.75.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152162498094.6107.11843109575931027587@ietfa.amsl.com> Date: Wed, 21 Mar 2018 02:36:20 -0700 Archived-At: Subject: [Dots] I-D Action: draft-ietf-dots-signal-channel-18.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, 21 Mar 2018 09:36:21 -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-18.txt Pages : 86 Date : 2018-03-21 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 Specification"; o "| [RFCXXXX] |" o reference: RFC XXXX Please update TBD statements with the port number to be assigned to DOTS Signal Channel Protocol. Also, please update the "revision" date of the YANG module. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dots-signal-channel/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-dots-signal-channel-18 https://datatracker.ietf.org/doc/html/draft-ietf-dots-signal-channel-18 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dots-signal-channel-18 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 Mar 21 03:15: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 710F212DA17 for ; Wed, 21 Mar 2018 03:15:38 -0700 (PDT) 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 VMoVEPlrKaVh for ; Wed, 21 Mar 2018 03:15:36 -0700 (PDT) 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 B1057124F57 for ; Wed, 21 Mar 2018 03:15:36 -0700 (PDT) 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 w2LAFXEq045999 for ; Wed, 21 Mar 2018 06:15:33 -0400 DKIM-Filter: OpenDKIM Filter v2.11.0 veto.sei.cmu.edu w2LAFXEq045999 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cert.org; s=yc2bmwvrj62m; t=1521627333; bh=ioBapT3cLJs6oc774taPQPTlzlkgzrGEm+XT3mTyHV0=; h=From:To:Subject:Date:From; b=Fr9hI9qX3pPkW1PreVuGdtlnLpQ/FUZQEe2adjDiY1XcDImU4eI/ZtnHMq2l9ECaj qfmnWZLp5X92xo8tbbjQ5cnqMtJITco6+KQkpTfMaGM4ApBRNY9wPE/180oNvR5r6F Gw+KTHX5h1MBgMAhWSriRL4RPCzz4gTyK65ufLr8= 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 w2LAFWtt020094 for ; Wed, 21 Mar 2018 06:15:32 -0400 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; Wed, 21 Mar 2018 06:15:31 -0400 From: Roman Danyliw To: "dots@ietf.org" Thread-Topic: Second WGLC on DOTS Requirements Thread-Index: AdPA+oGkaVa8XBIIQ8eK5rKDFxYNQA== Date: Wed, 21 Mar 2018 10:15:31 +0000 Message-ID: <359EC4B99E040048A7131E0F4E113AFC014C36B7BB@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 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, 21 Mar 2018 10:15:38 -0000 Hello! Consistent with our discussion at the London meeting, we are starting a sec= ond working group last call (WGLC) for the DOTS Requirements draft: Distributed Denial of Service (DDoS) Open Threat Signaling Requirements draft-ietf-dots-requirements-14 https://tools.ietf.org/html/draft-ietf-dots-requirements-14 Please send comments to the DOTS mailing list. The WG welcomes feedback on= needed changes as well as endorsements that this draft is ready. This second WGLC will end on April 4, 2018. Thanks, Roman From nobody Wed Mar 21 03:19: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 84C87124F57 for ; Wed, 21 Mar 2018 03:19:48 -0700 (PDT) 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 rtFG_EPOwKdy for ; Wed, 21 Mar 2018 03:19:46 -0700 (PDT) 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 78E2012420B for ; Wed, 21 Mar 2018 03:19:46 -0700 (PDT) Received: from opfednr02.francetelecom.fr (unknown [xx.xx.xx.66]) by opfednr21.francetelecom.fr (ESMTP service) with ESMTP id F1C93C082F; Wed, 21 Mar 2018 11:19:44 +0100 (CET) Received: from Exchangemail-eme3.itn.ftgroup (unknown [xx.xx.50.58]) by opfednr02.francetelecom.fr (ESMTP service) with ESMTP id D89CD120079; Wed, 21 Mar 2018 11:19:44 +0100 (CET) Received: from OPEXCNORMAD.corporate.adroot.infra.ftgroup ([fe80::f1a0:3c6b:bc7b:3aaf]) by OPEXCNORM72.corporate.adroot.infra.ftgroup ([fe80::b14e:a56e:a38:474d%21]) with mapi id 14.03.0382.000; Wed, 21 Mar 2018 11:19:44 +0100 From: To: Roman Danyliw , "dots@ietf.org" Thread-Topic: Second WGLC on DOTS Requirements Thread-Index: AdPA+oGkaVa8XBIIQ8eK5rKDFxYNQAAA3RVg Date: Wed, 21 Mar 2018 10:19:43 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93302DEE4CDC@OPEXCNORMAD.corporate.adroot.infra.ftgroup> References: <359EC4B99E040048A7131E0F4E113AFC014C36B7BB@marathon> In-Reply-To: <359EC4B99E040048A7131E0F4E113AFC014C36B7BB@marathon> 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] Second 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, 21 Mar 2018 10:19:49 -0000 Hi all,=20 I support the document to advance in the publication process. I reviewed it several times and all my comments were addressed.=20 Cheers, Med > -----Message d'origine----- > De=A0: Dots [mailto:dots-bounces@ietf.org] De la part de Roman Danyliw > Envoy=E9=A0: mercredi 21 mars 2018 10:16 > =C0=A0: dots@ietf.org > Objet=A0: [Dots] Second WGLC on DOTS Requirements >=20 > Hello! >=20 > Consistent with our discussion at the London meeting, we are starting a > second working group last call (WGLC) for the DOTS Requirements draft: >=20 > Distributed Denial of Service (DDoS) Open Threat Signaling Requirements > draft-ietf-dots-requirements-14 > https://tools.ietf.org/html/draft-ietf-dots-requirements-14 >=20 > Please send comments to the DOTS mailing list. The WG welcomes feedback = on > needed changes as well as endorsements that this draft is ready. >=20 > This second WGLC will end on April 4, 2018. >=20 > Thanks, > Roman >=20 > _______________________________________________ > Dots mailing list > Dots@ietf.org > https://www.ietf.org/mailman/listinfo/dots From nobody Wed Mar 21 03: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 53CEF12DA4B for ; Wed, 21 Mar 2018 03:33:12 -0700 (PDT) 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 ep5zlqp7A6Qu for ; Wed, 21 Mar 2018 03:33:10 -0700 (PDT) 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 9E6FA12DA17 for ; Wed, 21 Mar 2018 03:33:10 -0700 (PDT) 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 w2LAX9F9005146 for ; Wed, 21 Mar 2018 06:33:09 -0400 DKIM-Filter: OpenDKIM Filter v2.11.0 taper.sei.cmu.edu w2LAX9F9005146 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cert.org; s=yc2bmwvrj62m; t=1521628389; bh=Lf1hxu+p6pihMYcnV+Rn72P0At8Xg1xDBAKp6iIT9bQ=; h=From:To:Subject:Date:From; b=AUUKQ7RuP5iUmUTOumb+Pr/yaiFI6PlJoE415JIIw0knjYV30OK9rbyAK7P+d3aMG 8hj9uROIDrE/CtX+1xidi1rYS+Y+oTzUr/7W3yPVWpdi8cUe6L52unq2p77dRadjnr 6xSbThgpiE/NhvYuNhvp5Bhm+LBLRii5L7G3JljY= 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 w2LAWxJn024131 for ; Wed, 21 Mar 2018 06:32:59 -0400 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; Wed, 21 Mar 2018 06:32:59 -0400 From: Roman Danyliw To: "dots@ietf.org" Thread-Topic: WGLC on DOTS Signal Channel Thread-Index: AdPA/2I8r8JGmyBkSmyI9HwbArIJBw== Date: Wed, 21 Mar 2018 10:32:58 +0000 Message-ID: <359EC4B99E040048A7131E0F4E113AFC014C36B932@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] WGLC on DOTS Signal 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, 21 Mar 2018 10:33:12 -0000 Hello! Consistent with our discussion at the London meeting, we are starting a wor= king group last call (WGLC) for the DOTS Signal Channel draft: DOTS Signal Channel Specification draft-ietf-dots-signal-channel-18 https://tools.ietf.org/html/draft-ietf-dots-signal-channel-18 Please send comments to the DOTS mailing list -- feedback on remaining issu= es or needed changes; as well as endorsements that this draft is ready. This WGLC will end on April 6, 2018. Thanks, Roman From nobody Fri Mar 23 08:35:16 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 0E83E12D86E for ; Fri, 23 Mar 2018 08:35:14 -0700 (PDT) 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 rBVDqiTU4Lhs for ; Fri, 23 Mar 2018 08:35:12 -0700 (PDT) Received: from mail.jpshallow.com (mail.jpshallow.com [217.40.240.153]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1640F126DFB for ; Fri, 23 Mar 2018 08:35:12 -0700 (PDT) Received: from [127.0.0.1] (helo=N01332) by mail.jpshallow.com with smtps (TLSv1:ECDHE-RSA-AES256-SHA:256) (Exim 4.90_1) (envelope-from ) id 1ezOij-0005xc-5m for ietf-supjps-dots@ietf.org; Fri, 23 Mar 2018 15:35:09 +0000 From: "Jon Shallow" To: Date: Fri, 23 Mar 2018 15:35:11 -0000 Message-ID: <05c801d3c2bc$88171290$984537b0$@jpshallow.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_05C9_01D3C2BC.88182400" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdPCvGoIR6UZkNdQToaxFBBessPIQQ== Content-Language: en-gb Archived-At: Subject: [Dots] WGLC signal-18 Draft Hop Limit tidy up 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, 23 Mar 2018 15:35:14 -0000 This is a multipart message in MIME format. ------=_NextPart_000_05C9_01D3C2BC.88182400 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi there, I believe that there are a couple of changes required for the hop-limit definition - see [Jon] inline. hop-limit: This option (see Section 9.4) is used to detect and prevent infinite loops. This option is typically inserted by a DOTS gateway. The length of the hop-limit option is 1 byte. The value of the hop-limit option is encoded as an unsigned integer (see Section 3.2 of [RFC7252]). Each intermediate DOTS agent involved in the handling of a DOTS message MUST decrement the hop-limit option value by 1 prior to forwarding upstream if this parameter exists. DOTS messages MUST NOT be forwarded if the hop-limit option 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. [Jon] We need to add in something like:- Each intermediate DOTS agent SHOULD add in the hop-limit option with the initial default value if it does not exist before forwarding upstream any information. [Jon] We need to define the format of the 5.06 CoAP diagnostic message so that it is potentially parseable by the DOTS client as well as by any other potential RFC that make use of this 5.06 code. In addition, it would be good if each intermediate DOTS agent appended its own IP (prefixed by a blank) to the end of the diagnostic message as the 5.06 response gets passed back through the DOST agents to enable troubleshooting at the DOTS client. The diagnostic message length would need to be restricted to something like 1000 bytes to prevent UDP fragmentation. Suggestions welcome here. 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 option. [Jon] This should read "This is an optional CoAP Option". Regards Jon ------=_NextPart_000_05C9_01D3C2BC.88182400 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi = there,

 

I believe that there are a couple of changes required = for the hop-limit definition – see [Jon] inline.

 

         &= nbsp; hop-limit:  This option (see Section 9.4) is used to detect = and

         &= nbsp;    prevent infinite loops.  This option is = typically inserted by a

         &= nbsp;    DOTS gateway.

 

         &= nbsp;    The length of the hop-limit option is 1 = byte.

 

         &= nbsp;    The value of the hop-limit option is encoded as = an unsigned

         &= nbsp;    integer (see Section 3.2 of = [RFC7252]).

 

         &= nbsp;    Each intermediate DOTS agent involved in the = handling of a DOTS

         &= nbsp;    message MUST decrement the hop-limit option = value by 1 prior to

         &= nbsp;    forwarding upstream if this parameter = exists.  DOTS messages MUST

         &= nbsp;    NOT be forwarded if the hop-limit option is set = to '0' after

         &= nbsp;    decrement.  Messages that cannot be = forwarded because of exhausted

         &= nbsp;    hop-limit SHOULD be logged with a 5.06 (Hop = Limit Reached) error

         &= nbsp;    message sent back to the DOTS peer.  It is = RECOMMENDED that DOTS

         &= nbsp;    clients and gateways support means to alert = administrators about

         &= nbsp;    loop errors so that appropriate actions are = undertaken.

[Jon] We need to add in = something like:-

Each intermediate = DOTS agent SHOULD add in the hop-limit option with the initial default = value if it does not exist before forwarding upstream any = information.

 

[Jon] We need to define the format of the 5.06 CoAP = diagnostic message so that it is potentially parseable by the DOTS = client as well as by any other potential RFC that make use of this 5.06 = code.  In addition, it would be good if each intermediate DOTS = agent appended its own IP (prefixed by a blank) to the end of the = diagnostic message as the 5.06 response gets passed back through the = DOST agents to enable troubleshooting at the DOTS client.  The = diagnostic message length would need to be restricted to something like = 1000 bytes to prevent UDP fragmentation.  Suggestions welcome = here.

 

         &= nbsp;    The initial hop-limit value SHOULD be = configurable.  If no initial

         &= nbsp;    value is explicitly provided, the default = initial hop-limit value

         &= nbsp;    of 16 MUST be used.

 

         &= nbsp;    Because forwarding errors may occur if = inadequate hop-limit values

         &= nbsp;    are used, DOTS agents at the boundaries of an = administrative

          =     domain MAY be instructed to rewrite the value of = hop-limit carried

         &= nbsp;    in received messages (that is, ignore the value = of hop-limit

         &= nbsp;    received in a message).

 

         &= nbsp;    This is an optional option.

[Jon] This should read “This is an optional CoAP = Option”.

 

 

Regards

 

Jon

------=_NextPart_000_05C9_01D3C2BC.88182400-- From nobody Sat Mar 24 18:01:23 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 371C312706D for ; Sat, 24 Mar 2018 18:01:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, 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 (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 YMYTI2aDIR4n for ; Sat, 24 Mar 2018 18:01:19 -0700 (PDT) Received: from mail-lf0-x236.google.com (mail-lf0-x236.google.com [IPv6:2a00:1450:4010:c07::236]) (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 5550A12025C for ; Sat, 24 Mar 2018 18:01:19 -0700 (PDT) Received: by mail-lf0-x236.google.com with SMTP id a22-v6so23283378lfg.9 for ; Sat, 24 Mar 2018 18:01:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:from:date:message-id:subject:to; bh=yqLVz1ck3ubPDMtmvWs4sW9pTzpKvBqSHuusEzEUjys=; b=daYaIomkuHTA38bANTWGIbV60v09WB1OTctmy3LrJ+Jj4M9q6EDnRWTbTzTPWWfPDe 5b6rxVYQPUAzyEuQlViVh/yip+pWIybwOaYp5LyXkSArSOodVmlVPkJBNf0jeqteUtC8 qiFm/RRXTP+t2ufDsgeJHa9xkrxcZHmZYzrE8LWtmeMm8AaNDkF4OR+gCT17RSGeWTEu Cjp1c0VFWUf/Qa2sUDi098bPL+rXBGvKtsMkgTFcULvjsm8/90rlx7OeTdGd39ua+U4y B/e0aDlWkxANA6t6KkamxjJtasmqqoG3hv7LemFCxnM6to4L8k6mGuKuI4DwiR4xzP3u hKdA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:from:date:message-id:subject :to; bh=yqLVz1ck3ubPDMtmvWs4sW9pTzpKvBqSHuusEzEUjys=; b=Qtgoj0EwPe6ztEjiwn/t2tfzXF01Awsv0aJyHq/4G855kT6o86wVRdew6PhMy5V/qB F2XitcIJe8xBznCDDKNeoLYxsHgwqiSiI8Js4Wp1wXGsF3bGBkBAFXMLeKI6wt2Cjc+e pfmW//L02DK6X0oyxzvtHKR2qZJY0yBeXY7ABkWlyTHpM5/PtQ0gw0WW2dq6szfMNHR/ rWwnq4fq0AstLteAOx0QuiehrBhZQi3loR770F59F39S+ZbfV9SfQqGSJI605+laB88i 5Z4Db671gycaMDwEOPyb8Di/YqfZ+ERPv/ej0jfgCq/vnwUjUX2U8zHodA/x3wjYOIVg gB/A== X-Gm-Message-State: AElRT7HSl3L9FG2ZZ/v0VO0ijDA64cFceadoJz40Y8aLXvOpS3DrfsOn LVdCwqRvNfSakCaBJ8TdDG5ub+ziq5ScjHDpYPbCZg== X-Google-Smtp-Source: AG47ELsJWjdvFFlFcl+tTm2Jrbq/CZpGlLi2i0T9UOe3zBorOsqsSkHZJS6plAfjW9CIlHENfg9XBsodxDqN+mYiRq4= X-Received: by 2002:a19:e9cc:: with SMTP id j73-v6mr20503067lfk.99.1521939677390; Sat, 24 Mar 2018 18:01:17 -0700 (PDT) MIME-Version: 1.0 Sender: mglt.ietf@gmail.com Received: by 10.46.134.22 with HTTP; Sat, 24 Mar 2018 18:01:16 -0700 (PDT) From: Daniel Migault Date: Sat, 24 Mar 2018 21:01:16 -0400 X-Google-Sender-Auth: as-XGV31dwPnXFsekf5vpMrZWPs Message-ID: To: dots@ietf.org Content-Type: multipart/alternative; boundary="000000000000d72b4805683231ea" Archived-At: Subject: [Dots] dots-use-case 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, 25 Mar 2018 01:01:21 -0000 --000000000000d72b4805683231ea Content-Type: text/plain; charset="UTF-8" Hi, Here is an update for the next iteration of the use case draft. Feel free to provide comments or directly addressing your comments via pull request by Tuesday March 27. I am expecting publishing version 11 on March 28. Yours, Daniel [1] https://github.com/dotswg/dots-use-cases --000000000000d72b4805683231ea Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

Here is an update for the= next iteration of the use case draft. Feel free to provide comments or dir= ectly addressing your comments via pull request by Tuesday March 27. I am e= xpecting publishing version 11 on March 28.

Yours,
= Daniel
--000000000000d72b4805683231ea-- From nobody Mon Mar 26 05:22: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 22390127201 for ; Mon, 26 Mar 2018 05:22:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.011 X-Spam-Level: X-Spam-Status: No, score=-0.011 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, 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 ICPZduTsxhCG for ; Mon, 26 Mar 2018 05:22:43 -0700 (PDT) Received: from mail.jpshallow.com (mail.jpshallow.com [217.40.240.153]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 87E50127137 for ; Mon, 26 Mar 2018 05:22:43 -0700 (PDT) Received: from [127.0.0.1] (helo=N01332) by mail.jpshallow.com with smtps (TLSv1:ECDHE-RSA-AES256-SHA:256) (Exim 4.90_1) (envelope-from ) id 1f0R96-0007wk-BO for ietf-supjps-dots@ietf.org; Mon, 26 Mar 2018 13:22:40 +0100 From: "Jon Shallow" To: Date: Mon, 26 Mar 2018 13:22:38 +0100 Message-ID: <008401d3c4fd$216d0840$644718c0$@jpshallow.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0085_01D3C505.83323390" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdPE/QAkDtOD9YeqSAaov9+szxQnSQ== Content-Language: en-gb Archived-At: Subject: [Dots] IETF 101 Presentation Data Channel Issue #4 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, 26 Mar 2018 12:22:45 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0085_01D3C505.83323390 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi there, As per Med's presentation to the IETF 101 Issue #4: Per-Domain or Per-client Filters? . Conclusion - Filters that are activated only during mitigation time are on a per-client basis . Filters are per-domain when are immediately applied "Filters are per-domain when are immediately applied" is what I have an challenge with. If we have a compromised or rogue DOTS client, the simple use of something like curl, along with the client certificates etc. can be used to generate any ACL with activation-type := 'immediate' which is then immediately applied for all traffic within the domain as per the above. So, a ACL that blacklists the DNS server, or drops all port 443 traffic etc. can easily cause all of the other clients / devices within the domain to be taken off air. Putting the intelligence into the DOTS server to not allow this to happen could be a challenge. [The signal channel is much harder to compromise and affect traffic flows to other areas within the domain] I believe that an ACL instantiated by a DOTS client (immediate or when-mitigating) should only apply to the DOTS client's traffic which means that the destination-network has to be a part of the ACL, whether implicitly added by the DOTS server, or by the DOTS client and suitably validated. There is nothing to stop the DOTS server or DOTS mitigator merging common ACLs to reduce the number of ACLs within the mitigation device. As a side note "mitigation-time" is perhaps a bad name as it implies a time period - something like "when-mitigating" to me is clearer. Regards Jon ------=_NextPart_000_0085_01D3C505.83323390 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi = there,

 

As per Med’s presentation to the IETF = 101

 

Issue #4: Per-Domain or Per-client = Filters?

 

• Conclusion

– Filters that are activated only during = mitigation time are on a per-client basis

   • Filters are per-domain when are = immediately applied

 

“Filters are per-domain when are immediately = applied” is what I have an challenge with.

 

If we have a = compromised or rogue DOTS client, the simple use of something like curl, = along with the client certificates etc. can be used to generate any ACL = with activation-type :=3D ‘immediate’ which is then = immediately applied for all traffic within the domain as per the = above.

 

So, a ACL that blacklists the DNS server, or drops all = port 443 traffic etc. can easily cause all of the other clients / = devices within the domain to be taken off air.  Putting the = intelligence into the DOTS server to not allow this to happen could be a = challenge.

[The signal channel is = much harder to compromise and affect traffic flows to other areas within = the domain]

 

I believe that an ACL instantiated by a DOTS client = (immediate or when-mitigating) should only apply to the DOTS = client’s traffic which means that the destination-network has to = be a part of the ACL, whether implicitly added by the DOTS server, or by = the DOTS client and suitably validated.

 

There is = nothing to stop the DOTS server or DOTS mitigator merging common ACLs to = reduce the number of ACLs within the mitigation device.

 

As a side = note “mitigation-time” is perhaps a bad name as it implies a = time period – something like “when-mitigating” to me = is clearer.

 

Regards

 

Jon

------=_NextPart_000_0085_01D3C505.83323390-- From nobody Mon Mar 26 05:27: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 D451D127201 for ; Mon, 26 Mar 2018 05:27:09 -0700 (PDT) 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 0wFbI5eXo916 for ; Mon, 26 Mar 2018 05:27:08 -0700 (PDT) Received: from mail.jpshallow.com (mail.jpshallow.com [217.40.240.153]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9353F127137 for ; Mon, 26 Mar 2018 05:27:08 -0700 (PDT) Received: from [127.0.0.1] (helo=N01332) by mail.jpshallow.com with smtps (TLSv1:ECDHE-RSA-AES256-SHA:256) (Exim 4.90_1) (envelope-from ) id 1f0RDP-0007x5-4F for ietf-supjps-dots@ietf.org; Mon, 26 Mar 2018 13:27:07 +0100 From: "Jon Shallow" To: Date: Mon, 26 Mar 2018 13:27:02 +0100 Message-ID: <009a01d3c4fd$c06ff8d0$414fea70$@jpshallow.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_009B_01D3C506.22352420" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdPE/b5w8YrYLrt/SrCsO86WDdlJeA== Content-Language: en-gb Archived-At: Subject: [Dots] WGLC signal-18 ack-timeout Nits 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, 26 Mar 2018 12:27:10 -0000 This is a multipart message in MIME format. ------=_NextPart_000_009B_01D3C506.22352420 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi there, a) "ack-timeout": { "max-value-decimal": 30, "min-value-decimal": 1, "current-value-decimal": 2 }, b) ack-timeout (2 seconds) c) "ack-timeout": { "current-value-decimal": 5 }, Should really read (for clarity as they are now decimal numbers) in various places "ack-timeout": { "max-value-decimal": 30.0, "min-value-decimal": 1.0, "current-value-decimal": 2.0 }, ack-timeout (2.0 seconds) "ack-timeout": { "current-value-decimal": 5.0 }, [I would prefer this to be 2.0, not 5.0 as it should not normally be changed and people are known to slavishly copy examples, and Figure 20: is really about changing the heartbeat interval. Likewise, max-transmit should really be 3, not 7 in Figure 20:] Regards Jon ------=_NextPart_000_009B_01D3C506.22352420 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi = there,

 

a)

         = "ack-timeout": {

         &= nbsp; "max-value-decimal": 30,

         &= nbsp; "min-value-decimal": 1,

         &= nbsp; "current-value-decimal": 2

         = },

b)

ack-timeout (2 seconds)

 

c)

         &= nbsp; "ack-timeout": {

         &= nbsp;   "current-value-decimal": 5

         &= nbsp; },

 

Should really read (for clarity as they are now = decimal numbers) in various places

 

         = "ack-timeout": {

         &= nbsp; "max-value-decimal": 30.0,

         &= nbsp; "min-value-decimal": 1.0,

         &= nbsp; "current-value-decimal": 2.0

         = },

 

ack-timeout (2.0 seconds)

 

         &= nbsp; "ack-timeout": {

         &= nbsp;   "current-value-decimal": = 5.0

         &= nbsp; },

[I would prefer this to be = 2.0, not 5.0 as it should not normally be changed and people are known = to slavishly copy examples, and Figure 20: is really about changing the = heartbeat interval.  Likewise, max-transmit should really be 3, not = 7 in Figure 20:]

 

Regards

 

Jon

------=_NextPart_000_009B_01D3C506.22352420-- From nobody Tue Mar 27 00:39: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 3058E12D872 for ; Tue, 27 Mar 2018 00:39:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.608 X-Spam-Level: X-Spam-Status: No, score=-2.608 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 7mlp4nvL25LI for ; Tue, 27 Mar 2018 00:39:08 -0700 (PDT) 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 15EBD12D86F for ; Tue, 27 Mar 2018 00:39:08 -0700 (PDT) Received: from opfedar02.francetelecom.fr (unknown [xx.xx.xx.4]) by opfedar23.francetelecom.fr (ESMTP service) with ESMTP id 436BB160243; Tue, 27 Mar 2018 09:39:06 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.24]) by opfedar02.francetelecom.fr (ESMTP service) with ESMTP id 23CFA180062; Tue, 27 Mar 2018 09:39:06 +0200 (CEST) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM7D.corporate.adroot.infra.ftgroup ([fe80::9044:c5ee:4dd2:4f16%19]) with mapi id 14.03.0382.000; Tue, 27 Mar 2018 09:39:06 +0200 From: To: Jon Shallow , "dots@ietf.org" Thread-Topic: [Dots] IETF 101 Presentation Data Channel Issue #4 Thread-Index: AdPE/QAkDtOD9YeqSAaov9+szxQnSQAoMdfA Date: Tue, 27 Mar 2018 07:39:05 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93302DEF1067@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <008401d3c4fd$216d0840$644718c0$@jpshallow.com> In-Reply-To: <008401d3c4fd$216d0840$644718c0$@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.6] Content-Type: multipart/alternative; boundary="_000_787AE7BB302AE849A7480A190F8B93302DEF1067OPEXCLILMA3corp_" MIME-Version: 1.0 Archived-At: Subject: Re: [Dots] IETF 101 Presentation Data Channel Issue #4 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, 27 Mar 2018 07:39:10 -0000 --_000_787AE7BB302AE849A7480A190F8B93302DEF1067OPEXCLILMA3corp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Jon, Thank you for the comments. Please see inline. Cheers, Med De : Dots [mailto:dots-bounces@ietf.org] De la part de Jon Shallow Envoy=E9 : lundi 26 mars 2018 14:23 =C0 : dots@ietf.org Objet : [Dots] IETF 101 Presentation Data Channel Issue #4 Hi there, As per Med's presentation to the IETF 101 Issue #4: Per-Domain or Per-client Filters? * Conclusion - Filters that are activated only during mitigation time are on a per-clien= t basis * Filters are per-domain when are immediately applied "Filters are per-domain when are immediately applied" is what I have an cha= llenge with. If we have a compromised or rogue DOTS client, the simple use of something = like curl, along with the client certificates etc. can be used to generate = any ACL with activation-type :=3D 'immediate' which is then immediately app= lied for all traffic within the domain as per the above. [Med] Yes. FWIW, this attack is called out in the security considerations s= ection: "Nevertheless, an attacker who can access a DOTS client is technically capable of launching various attacks, such as: ..; o Set invalid ACL entries, which may prevent legitimate traffic from being forwarded. Likewise, invalid ACL entries may lead to forward DDoS traffic. " So, a ACL that blacklists the DNS server, or drops all port 443 traffic etc= . can easily cause all of the other clients / devices within the domain to = be taken off air. Putting the intelligence into the DOTS server to not all= ow this to happen could be a challenge. [The signal channel is much harder to compromise and affect traffic flows t= o other areas within the domain] I believe that an ACL instantiated by a DOTS client (immediate or when-miti= gating) should only apply to the DOTS client's traffic which means that the= destination-network has to be a part of the ACL, whether implicitly added = by the DOTS server, or by the DOTS client and suitably validated. [Med] Putting aside that I don't parse "DOTS client's traffic", I interpret= your answer as a support to this question raised for issue #4: - "Should we mandate destination-network to be present for immediately e= nforced filters?" There is nothing to stop the DOTS server or DOTS mitigator merging common A= CLs to reduce the number of ACLs within the mitigation device. As a side note "mitigation-time" is perhaps a bad name as it implies a time= period - something like "when-mitigating" to me is clearer. [Med] Fixed in my local copy. Thank you. Regards Jon --_000_787AE7BB302AE849A7480A190F8B93302DEF1067OPEXCLILMA3corp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Jon,

 

Thank you for the comments.

 

Please see inline.

 

Cheers,

Med

 

De : Dots [mailto:dots-bounces@ietf.= org] De la part de Jon Shallow
Envoy=E9 : lundi 26 mars 2018 14:23
=C0 : dots@ietf.org
Objet : [Dots] IETF 101 Presentation Data Channel Issue #4=

 

Hi there,

 

As per Med’s presentation= to the IETF 101

 

Issue #4: Per-Domain or Per-cli= ent Filters?

 

• Conclusion

– Filters that are activa= ted only during mitigation time are on a per-client basis=

   • Filters ar= e per-domain when are immediately applied

 

“Filters are per-domain w= hen are immediately applied” is what I have an challenge with.

 

If we have a compromised or rog= ue DOTS client, the simple use of something like curl, along with the clien= t certificates etc. can be used to generate any ACL with activation-type := =3D ‘immediate’ which is then immediately applied for all traffic within the domain as per the above.

 

[Med] Yes. FWIW, this attack is= called out in the security considerations section:

 

“Nevertheless, an

   attack= er who can access a DOTS client is technically capable of=

   launch= ing various attacks, such as:

 

..;

 

   o  Set invalid ACL entries, whi=
ch may prevent legitimate traffic from
      being forwarded.&n=
bsp; Likewise, invalid ACL entries may lead to
      forward DDo=
S traffic.

“

 

So, a ACL that blacklists the D= NS server, or drops all port 443 traffic etc. can easily cause all of the o= ther clients / devices within the domain to be taken off air.  Putting= the intelligence into the DOTS server to not allow this to happen could be a challenge.

[The signal channel is much har= der to compromise and affect traffic flows to other areas within the domain= ]

 

I believe that an ACL instantia= ted by a DOTS client (immediate or when-mitigating) should only apply to th= e DOTS client’s traffic which means that the destination-network has = to be a part of the ACL, whether implicitly added by the DOTS server, or by the DOTS client and suitably validated.

 

[Med] Putting aside that I don&= #8217;t parse “DOTS client’s traffic”, I interpret your a= nswer as a support to this question raised for issue #4:<= /p>

–    “Should we mandate destination-network to be present for immediately enforced filters?”

 

There is nothing to stop the DO= TS server or DOTS mitigator merging common ACLs to reduce the number of ACL= s within the mitigation device.

 

As a side note “mitigatio= n-time” is perhaps a bad name as it implies a time period – som= ething like “when-mitigating” to me is clearer.

[Med] Fixed in my local copy. T= hank you.

 

Regards

 

Jon

--_000_787AE7BB302AE849A7480A190F8B93302DEF1067OPEXCLILMA3corp_-- From nobody Tue Mar 27 01:21: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 41D9F12D872 for ; Tue, 27 Mar 2018 01:21:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.608 X-Spam-Level: X-Spam-Status: No, score=-2.608 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 t1iM3djcZKi2 for ; Tue, 27 Mar 2018 01:21:38 -0700 (PDT) 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 2B2FE126B7E for ; Tue, 27 Mar 2018 01:21:38 -0700 (PDT) Received: from opfedar04.francetelecom.fr (unknown [xx.xx.xx.6]) by opfedar24.francetelecom.fr (ESMTP service) with ESMTP id A9A89C06B1; Tue, 27 Mar 2018 10:21:36 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.58]) by opfedar04.francetelecom.fr (ESMTP service) with ESMTP id 812E040058; Tue, 27 Mar 2018 10:21:36 +0200 (CEST) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM33.corporate.adroot.infra.ftgroup ([fe80::3881:fc15:b4b2:9017%19]) with mapi id 14.03.0382.000; Tue, 27 Mar 2018 10:21:36 +0200 From: To: Jon Shallow , "dots@ietf.org" Thread-Topic: [Dots] WGLC signal-18 Draft Hop Limit tidy up Thread-Index: AdPCvGoIR6UZkNdQToaxFBBessPIQQC4lpWQ Date: Tue, 27 Mar 2018 08:21:35 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93302DEF10B4@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <05c801d3c2bc$88171290$984537b0$@jpshallow.com> In-Reply-To: <05c801d3c2bc$88171290$984537b0$@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.6] Content-Type: multipart/alternative; boundary="_000_787AE7BB302AE849A7480A190F8B93302DEF10B4OPEXCLILMA3corp_" MIME-Version: 1.0 Archived-At: Subject: Re: [Dots] WGLC signal-18 Draft Hop Limit tidy up 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, 27 Mar 2018 08:21:40 -0000 --_000_787AE7BB302AE849A7480A190F8B93302DEF10B4OPEXCLILMA3corp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Jon, Please see inline. Cheers, Med De : Dots [mailto:dots-bounces@ietf.org] De la part de Jon Shallow Envoy=E9 : vendredi 23 mars 2018 16:35 =C0 : dots@ietf.org Objet : [Dots] WGLC signal-18 Draft Hop Limit tidy up Hi there, I believe that there are a couple of changes required for the hop-limit def= inition - see [Jon] inline. hop-limit: This option (see Section 9.4) is used to detect and prevent infinite loops. This option is typically inserted by= a DOTS gateway. The length of the hop-limit option is 1 byte. The value of the hop-limit option is encoded as an unsigned integer (see Section 3.2 of [RFC7252]). Each intermediate DOTS agent involved in the handling of a DO= TS message MUST decrement the hop-limit option value by 1 prior = to forwarding upstream if this parameter exists. DOTS messages = MUST NOT be forwarded if the hop-limit option is set to '0' after decrement. Messages that cannot be forwarded because of exha= usted hop-limit SHOULD be logged with a 5.06 (Hop Limit Reached) er= ror message sent back to the DOTS peer. It is RECOMMENDED that D= OTS clients and gateways support means to alert administrators ab= out loop errors so that appropriate actions are undertaken. [Jon] We need to add in something like:- Each intermediate DOTS agent SHOULD add in the hop-limit option with the in= itial default value if it does not exist before forwarding upstream any inf= ormation. [Med] I'm not sure to understand this one. Please note that the text says "= A DOTS gateway may add the following CoAP option". This is typically a GW w= hich is instructed to insert the option will inject the option and follows = the setting of the initial value. [Jon] We need to define the format of the 5.06 CoAP diagnostic message so t= hat it is potentially parseable by the DOTS client as well as by any other = potential RFC that make use of this 5.06 code. In addition, it would be go= od if each intermediate DOTS agent appended its own IP (prefixed by a blank= ) to the end of the diagnostic message as the 5.06 response gets passed bac= k through the DOST agents to enable troubleshooting at the DOTS client. Th= e diagnostic message length would need to be restricted to something like 1= 000 bytes to prevent UDP fragmentation. Suggestions welcome here. [Med] I can see a value in recording the list of GWs involved in a loop for= debugging purposes at the DOTS server domain, but I'm not sure there is a = value to pass that list to the DOTS client. For example, a server domain ma= y want to hide its internal topology (list of GWs and servers involved in h= andling a mitigation request). Below a text proposal for discussion: To ease debugging and troubleshooting, the DOTS gateway which detects a loop SHOULD include its information (e.g., server name, alias, IP address) in the diagnostic payload under the conditions detailed in Section 5.5.2 of [RFC7252]. Each intermediate DOTS gateway involved in relaying a 5.06 (Hop Limit Reached) error message SHOULD prepend its own information in the diagnostic payload with a space character used as separator. The ultimate DOTS gateway SHOULD remove the diagnostic payload before forwarding the 5.06 (Hop Limit Reached) error message to a DOTS client domain. The initial hop-limit value SHOULD be configurable. If no in= itial value is explicitly provided, the default initial hop-limit v= alue of 16 MUST be used. Because forwarding errors may occur if inadequate hop-limit v= alues are used, DOTS agents at the boundaries of an administrative domain MAY be instructed to rewrite the value of hop-limit ca= rried in received messages (that is, ignore the value of hop-limit received in a message). This is an optional option. [Jon] This should read "This is an optional CoAP Option". [Med] I can make the change. Please note that the text starts with "A DOTS = gateway may add the following CoAP option" which is clear enough this is ab= out an optional CoAP option. Regards Jon --_000_787AE7BB302AE849A7480A190F8B93302DEF10B4OPEXCLILMA3corp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Jon,

 

Please see inline.

 

Cheers,

Med

 

De : Dots [mailto:dots-bounces@ietf.= org] De la part de Jon Shallow
Envoy=E9 : vendredi 23 mars 2018 16:35
=C0 : dots@ietf.org
Objet : [Dots] WGLC signal-18 Draft Hop Limit tidy up

 

Hi there,

 

I believe that there are a coup= le of changes required for the hop-limit definition – see [Jon] inlin= e.

 

     &= nbsp;     hop-limit:  This option (see Section 9.4= ) is used to detect and

     &= nbsp;        prevent infinite loops.&nbs= p; This option is typically inserted by a

     &= nbsp;        DOTS gateway.

 

     &= nbsp;        The length of the hop-limit= option is 1 byte.

 

     &= nbsp;        The value of the hop-limit = option is encoded as an unsigned

     &= nbsp;        integer (see Section 3.2 of= [RFC7252]).

 

     &= nbsp;        Each intermediate DOTS agen= t involved in the handling of a DOTS

     &= nbsp;        message MUST decrement the = hop-limit option value by 1 prior to

     &= nbsp;        forwarding upstream if this= parameter exists.  DOTS messages MUST

     &= nbsp;        NOT be forwarded if the hop= -limit option is set to '0' after

     &= nbsp;        decrement.  Messages t= hat cannot be forwarded because of exhausted

     &= nbsp;        hop-limit SHOULD be logged = with a 5.06 (Hop Limit Reached) error

     &= nbsp;        message sent back to the DO= TS peer.  It is RECOMMENDED that DOTS

     &= nbsp;        clients and gateways suppor= t means to alert administrators about

     &= nbsp;        loop errors so that appropr= iate actions are undertaken.

[Jon] We need to add in somethi= ng like:-

Each intermediate DOTS agent SH= OULD add in the hop-limit option with the initial default value if it does = not exist before forwarding upstream any information.

 

[Med] I’m not sure to und= erstand this one. Please note that the text says “A DOTS gateway may = add the following CoAP option”. This is typically a GW which is instructed to insert the option will inject the option and follows the = setting of the initial value.

 

[Jon] We need to define the for= mat of the 5.06 CoAP diagnostic message so that it is potentially parseable= by the DOTS client as well as by any other potential RFC that make use of = this 5.06 code.  In addition, it would be good if each intermediate DOTS agent appended its own IP (prefixed by a= blank) to the end of the diagnostic message as the 5.06 response gets pass= ed back through the DOST agents to enable troubleshooting at the DOTS clien= t.  The diagnostic message length would need to be restricted to something like 1000 bytes to prevent UDP fr= agmentation.  Suggestions welcome here.

 

[Med] I can see a value in reco= rding the list of GWs involved in a loop for debugging purposes at the DOTS= server domain, but I’m not sure there is a value to pass that list to the DOTS client. For example, a server domain may wan= t to hide its internal topology (list of GWs and servers involved in handli= ng a mitigation request). Below a  text proposal for discussion:<= /o:p>

 

   &= nbsp;  To ease debugging and troubleshooting, the DOTS gateway which

   &= nbsp;  detects a loop SHOULD include its information (e.g., server nam= e,

   &= nbsp;  alias, IP address) in the diagnostic payload under the conditio= ns

   &= nbsp;  detailed in Section 5.5.2 of [RFC7252].  Each intermediate= DOTS

   &= nbsp;  gateway involved in relaying a 5.06 (Hop Limit Reached) error

   &= nbsp;  message SHOULD prepend its own information in the diagnostic

   &= nbsp;  payload with a space character used as separator.  The ult= imate

   &= nbsp;  DOTS gateway SHOULD remove the diagnostic payload before

   &= nbsp;  forwarding the 5.06 (Hop Limit Reached) error message to a DOTS=

   &= nbsp;  client domain.

 

&nbs= p;

     &= nbsp;        The initial hop-limit value= SHOULD be configurable.  If no initial

     &= nbsp;        value is explicitly provide= d, the default initial hop-limit value

     &= nbsp;        of 16 MUST be used.

 

     &= nbsp;        Because forwarding errors m= ay occur if inadequate hop-limit values

     &= nbsp;        are used, DOTS agents at th= e boundaries of an administrative

     &= nbsp;        domain MAY be instructed to= rewrite the value of hop-limit carried

     &= nbsp;        in received messages (that = is, ignore the value of hop-limit

     &= nbsp;        received in a message).

 

     &= nbsp;        This is an optional option.=

[Jon] This should read “T= his is an optional CoAP Option”.

&nbs= p;

[Med] I can make the change. Pl= ease note that the text starts with “A DOTS gateway may add the follo= wing CoAP option” which is clear enough this is about an optional CoAP option.

 

Regards

 

Jon

--_000_787AE7BB302AE849A7480A190F8B93302DEF10B4OPEXCLILMA3corp_-- From nobody Tue Mar 27 01:34:06 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 97AF512D876 for ; Tue, 27 Mar 2018 01:34:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.608 X-Spam-Level: X-Spam-Status: No, score=-2.608 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 QMW-YXkhRRaN for ; Tue, 27 Mar 2018 01:34:03 -0700 (PDT) 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 DCB4012D873 for ; Tue, 27 Mar 2018 01:34:02 -0700 (PDT) Received: from opfednr00.francetelecom.fr (unknown [xx.xx.xx.64]) by opfednr20.francetelecom.fr (ESMTP service) with ESMTP id 2ED164073F; Tue, 27 Mar 2018 10:34:01 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.59]) by opfednr00.francetelecom.fr (ESMTP service) with ESMTP id 0B2E31A0074; Tue, 27 Mar 2018 10:34:01 +0200 (CEST) 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.0382.000; Tue, 27 Mar 2018 10:34:00 +0200 From: To: Jon Shallow , "dots@ietf.org" Thread-Topic: [Dots] WGLC signal-18 ack-timeout Nits Thread-Index: AdPE/b5w8YrYLrt/SrCsO86WDdlJeAApwFDA Date: Tue, 27 Mar 2018 08:34:00 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93302DEF10D1@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <009a01d3c4fd$c06ff8d0$414fea70$@jpshallow.com> In-Reply-To: <009a01d3c4fd$c06ff8d0$414fea70$@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.6] Content-Type: multipart/alternative; boundary="_000_787AE7BB302AE849A7480A190F8B93302DEF10D1OPEXCLILMA3corp_" MIME-Version: 1.0 Archived-At: Subject: Re: [Dots] WGLC signal-18 ack-timeout Nits 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, 27 Mar 2018 08:34:04 -0000 --_000_787AE7BB302AE849A7480A190F8B93302DEF10D1OPEXCLILMA3corp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Jon, Fixed to avoid misinterpreting the spec through the examples. Cheers, Med De : Dots [mailto:dots-bounces@ietf.org] De la part de Jon Shallow Envoy=E9 : lundi 26 mars 2018 14:27 =C0 : dots@ietf.org Objet : [Dots] WGLC signal-18 ack-timeout Nits Hi there, a) "ack-timeout": { "max-value-decimal": 30, "min-value-decimal": 1, "current-value-decimal": 2 }, b) ack-timeout (2 seconds) c) "ack-timeout": { "current-value-decimal": 5 }, Should really read (for clarity as they are now decimal numbers) in various= places "ack-timeout": { "max-value-decimal": 30.0, "min-value-decimal": 1.0, "current-value-decimal": 2.0 }, ack-timeout (2.0 seconds) "ack-timeout": { "current-value-decimal": 5.0 }, [I would prefer this to be 2.0, not 5.0 as it should not normally be change= d and people are known to slavishly copy examples, and Figure 20: is really= about changing the heartbeat interval. Likewise, max-transmit should real= ly be 3, not 7 in Figure 20:] Regards Jon --_000_787AE7BB302AE849A7480A190F8B93302DEF10D1OPEXCLILMA3corp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Jon,

 

Fixed to avoid misinterpreting = the spec through the examples.

 

Cheers,

Med

 

De : Dots [mailto:dots-bounces@ietf.= org] De la part de Jon Shallow
Envoy=E9 : lundi 26 mars 2018 14:27
=C0 : dots@ietf.org
Objet : [Dots] WGLC signal-18 ack-timeout Nits

 

Hi there,

 

a)

     &= nbsp;   "ack-timeout": {

     &= nbsp;     "max-value-decimal": 30,=

     &= nbsp;     "min-value-decimal": 1,<= /span>

     &= nbsp;     "current-value-decimal": 2

     &= nbsp;   },

b)

ack-timeout (2 seconds)

 

c)

     &= nbsp;     "ack-timeout": {<= /p>

     &= nbsp;       "current-value-decimal"= : 5

     &= nbsp;     },

 

Should really read (for clarity= as they are now decimal numbers) in various places

 

     &= nbsp;   "ack-timeout": {

     &= nbsp;     "max-value-decimal": 30.0,

     &= nbsp;     "min-value-decimal": 1.0,

     &= nbsp;     "current-value-decimal": 2.0

     &= nbsp;   },

 

ack-timeout (2.0 seconds)<= /o:p>

 

     &= nbsp;     "ack-timeout": {<= /p>

     &= nbsp;       "current-value-decimal"= : 5.0

     &= nbsp;     },

[I would prefer this to be 2.0,= not 5.0 as it should not normally be changed and people are known to slavi= shly copy examples, and Figure 20: is really about changing the heartbeat i= nterval.  Likewise, max-transmit should really be 3, not 7 in Figure 20:]

 

Regards

 

Jon

--_000_787AE7BB302AE849A7480A190F8B93302DEF10D1OPEXCLILMA3corp_-- From nobody Tue Mar 27 01:47: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 5450812D878 for ; Tue, 27 Mar 2018 01:47:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.309 X-Spam-Level: X-Spam-Status: No, score=-4.309 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, 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 laFzZy2cv5A4 for ; Tue, 27 Mar 2018 01:47:39 -0700 (PDT) Received: from DNVWSMAILOUT1.mcafee.com (dnvwsmailout1.mcafee.com [161.69.31.173]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DC51F12D873 for ; Tue, 27 Mar 2018 01:47:38 -0700 (PDT) X-NAI-Header: Modified by McAfee Email Gateway (5500) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mcafee.com; s=s_mcafee; t=1522140447; 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: 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-Threshold: X-NAI-Spam-Score:X-NAI-Spam-Version; bh=N FmpK2OMf4C4v2zk1Y4I2nbToxh4CuDJAcjLp94e8x M=; b=TiHMFE5y9DuVVMrtua/InXdvKa2p8JHftpOX7U1ZHC9G OFiCPsAsjF55bZd10rSGoWB6pM+ltNRcmzttsRKddSkpacpeXf rGujUr94fUN25L45HC05A+5qyXGhV68X+ivoNyFEXqAw1ICqSr 4qbL23mKb4JnDkFID9o2E3eirgA= 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 31de_edc6_3ea8cef1_f721_4bc9_9b95_958b98c52049; Tue, 27 Mar 2018 03:47:27 -0500 Received: from DNVEXUSR1N14.corpzone.internalzone.com (10.44.48.87) by DNVEXAPP1N05.corpzone.internalzone.com (10.44.48.89) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Tue, 27 Mar 2018 02:47:10 -0600 Received: from DNVO365EDGE2.corpzone.internalzone.com (10.44.176.74) by DNVEXUSR1N14.corpzone.internalzone.com (10.44.48.87) with Microsoft SMTP Server (TLS) id 15.0.1347.2 via Frontend Transport; Tue, 27 Mar 2018 02:47:11 -0600 Received: from NAM02-CY1-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, 27 Mar 2018 02:47:09 -0600 Received: from BN6PR16MB1425.namprd16.prod.outlook.com (10.172.207.19) by BN6PR16MB1634.namprd16.prod.outlook.com (10.172.27.140) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.609.10; Tue, 27 Mar 2018 08:47:08 +0000 Received: from BN6PR16MB1425.namprd16.prod.outlook.com ([fe80::b9d0:eb7e:fb41:137d]) by BN6PR16MB1425.namprd16.prod.outlook.com ([fe80::b9d0:eb7e:fb41:137d%2]) with mapi id 15.20.0609.012; Tue, 27 Mar 2018 08:47:08 +0000 From: "Konda, Tirumaleswar Reddy" To: "mohamed.boucadair@orange.com" , Jon Shallow , "dots@ietf.org" Thread-Topic: [Dots] IETF 101 Presentation Data Channel Issue #4 Thread-Index: AdPE/QAkDtOD9YeqSAaov9+szxQnSQAoMdfAAAKPC+A= Date: Tue, 27 Mar 2018 08:47:08 +0000 Message-ID: References: <008401d3c4fd$216d0840$644718c0$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93302DEF1067@OPEXCLILMA3.corporate.adroot.infra.ftgroup> In-Reply-To: <787AE7BB302AE849A7480A190F8B93302DEF1067@OPEXCLILMA3.corporate.adroot.infra.ftgroup> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-version: 11.0.200.100 dlp-reaction: no-action x-originating-ip: [103.245.47.20] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BN6PR16MB1634; 7:LuYCvd8CDkDpwDeH0J2YsFJ/+MTnoSbjowgdgiyCGqQe7tG3XDiK7LfII248CgnAsyaxM2Rgr7cEPzGs/25Deh/683QyxskWVj/YnKzZbOaFImQItwb3si9jA+L7A36pdUMmZNg6bYRMY0yknmKg+a6d6x3wPDCHkNc5qk1woW5RBogVDozfwrg0aVwTVT67PFW7P/xyUWJxY+nhyBwoyzvhFqjpvL+ViLp9igEORUQ6x8OkXFbf7Y1tKee9/q0g x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: 4157c29c-8c61-4a33-c5ea-08d593bf5349 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(4604075)(3008032)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7153060)(7193020); SRVR:BN6PR16MB1634; x-ms-traffictypediagnostic: BN6PR16MB1634: authentication-results: spf=none (sender IP is ) smtp.mailfrom=TirumaleswarReddy_Konda@McAfee.com; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(158342451672863)(192374486261705)(18271650672692)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(5005006)(8121501046)(3231221)(944501327)(52105095)(93006095)(93001095)(10201501046)(3002001)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123558120)(20161123564045)(20161123560045)(20161123562045)(6072148)(201708071742011); SRVR:BN6PR16MB1634; BCL:0; PCL:0; RULEID:; SRVR:BN6PR16MB1634; x-forefront-prvs: 0624A2429E x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39380400002)(396003)(376002)(366004)(346002)(39860400002)(32952001)(5383002)(199004)(189003)(33656002)(68736007)(2900100001)(6246003)(7736002)(3280700002)(55016002)(76176011)(6436002)(97736004)(66066001)(7696005)(6116002)(53546011)(316002)(3846002)(486005)(74316002)(486005)(54896002)(476003)(790700001)(6306002)(9686003)(53936002)(19609705001)(80792005)(8936002)(81166006)(14454004)(81156014)(229853002)(5250100002)(106356001)(72206003)(236005)(110136005)(2906002)(6506007)(59450400001)(25786009)(345774005)(8676002)(5660300001)(2501003)(11346002)(102836004)(105586002)(446003)(478600001)(86362001)(186003)(26005)(99286004)(3660700001)(91024005)(85282002); DIR:OUT; SFP:1101; SCL:1; SRVR:BN6PR16MB1634; H:BN6PR16MB1425.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: pIKBYM6R4d+33mhsFjOiY0aIwDcLjVsWm9ozI6BtSXxJMlWhcU6hS/Mq7B+wn/q4Z2wE12qgVPG4DX97Q/DXXhVeuL2P3nNJR4GZcn+EnsRiXv3+IL21S0YIJCi7J9/jrUVf+ZqWMMatJ/PNgis0nzWIOHR+mbb2nWK4Oj89lz8bVRCu7QYwYszlA9CigoWBG+uLzaSzbI/wa/6yfdTWTIZzpiJuxdIJTolApGgZVqLNt3mqRuNQLLB910INTATXMCBDKIj+nXbNetDbDlhf2OwT8zrNNuKFSQzJe2BfAiTng+CiHwWJGhatiATvrfQrxqZWTvvEQbFWOWYwpvSh6A== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BN6PR16MB142505FE4513755531EA7EFCEAAC0BN6PR16MB1425namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 4157c29c-8c61-4a33-c5ea-08d593bf5349 X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Mar 2018 08:47:08.7633 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4943e38c-6dd4-428c-886d-24932bc2d5de X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR16MB1634 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 <6250> : inlines <6520> : streams <1782395> : uri <2615613> Archived-At: Subject: Re: [Dots] IETF 101 Presentation Data Channel Issue #4 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, 27 Mar 2018 08:47:41 -0000 --_000_BN6PR16MB142505FE4513755531EA7EFCEAAC0BN6PR16MB1425namp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I also support to mandate destination-network for immediately enforced filt= ering rules. -Tiru From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of mohamed.boucadair@or= ange.com Sent: Tuesday, March 27, 2018 1:09 PM To: Jon Shallow ; dots@ietf.org Subject: Re: [Dots] IETF 101 Presentation Data Channel Issue #4 Hi Jon, Thank you for the comments. Please see inline. Cheers, Med De : Dots [mailto:dots-bounces@ietf.org] De la part de Jon Shallow Envoy=E9 : lundi 26 mars 2018 14:23 =C0 : dots@ietf.org Objet : [Dots] IETF 101 Presentation Data Channel Issue #4 Hi there, As per Med's presentation to the IETF 101 Issue #4: Per-Domain or Per-client Filters? * Conclusion - Filters that are activated only during mitigation time are on a per-clien= t basis * Filters are per-domain when are immediately applied "Filters are per-domain when are immediately applied" is what I have an cha= llenge with. If we have a compromised or rogue DOTS client, the simple use of something = like curl, along with the client certificates etc. can be used to generate = any ACL with activation-type :=3D 'immediate' which is then immediately app= lied for all traffic within the domain as per the above. [Med] Yes. FWIW, this attack is called out in the security considerations s= ection: "Nevertheless, an attacker who can access a DOTS client is technically capable of launching various attacks, such as: ..; o Set invalid ACL entries, which may prevent legitimate traffic from being forwarded. Likewise, invalid ACL entries may lead to forward DDoS traffic. " So, a ACL that blacklists the DNS server, or drops all port 443 traffic etc= . can easily cause all of the other clients / devices within the domain to = be taken off air. Putting the intelligence into the DOTS server to not all= ow this to happen could be a challenge. [The signal channel is much harder to compromise and affect traffic flows t= o other areas within the domain] I believe that an ACL instantiated by a DOTS client (immediate or when-miti= gating) should only apply to the DOTS client's traffic which means that the= destination-network has to be a part of the ACL, whether implicitly added = by the DOTS server, or by the DOTS client and suitably validated. [Med] Putting aside that I don't parse "DOTS client's traffic", I interpret= your answer as a support to this question raised for issue #4: * "Should we mandate destination-network to be present for immediate= ly enforced filters?" There is nothing to stop the DOTS server or DOTS mitigator merging common A= CLs to reduce the number of ACLs within the mitigation device. As a side note "mitigation-time" is perhaps a bad name as it implies a time= period - something like "when-mitigating" to me is clearer. [Med] Fixed in my local copy. Thank you. Regards Jon --_000_BN6PR16MB142505FE4513755531EA7EFCEAAC0BN6PR16MB1425namp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

I also su= pport to mandate destination-network for immediately enforced filtering rul= es.

&nbs= p;

-Tiru

 

From:<= /span> Dots [mailto:dots-bou= nces@ietf.org] On Behalf Of mohamed.boucadair@orange.com
Sent: Tuesday, March 27, 2018 1:09 PM
To: Jon Shallow <supjps-ietf@jpshallow.com>; dots@ietf.org
Subject: Re: [Dots] IETF 101 Presentation Data Channel Issue #4=

 

Hi Jon,

 

Thank you for the comments.<= /p>

 

Please see inline.

 

Cheers,

Med

 

De : Dots [mailto:dots-bounces@ietf.org] De la part de Jon Shallow
Envoy=E9 : lundi 26 mars 2018 14:23
=C0 : dots@ietf.org
Objet : [Dots] IETF 101 Presentation Data Channel Issue #4=

 

Hi there,

 

As per Med’s presentation= to the IETF 101

 

Issue #4: Per-Domain or Per-cli= ent Filters?

 

• Conclusion

– Filters that are activa= ted only during mitigation time are on a per-client basis=

   • Filters ar= e per-domain when are immediately applied

 

“Filters are per-domain w= hen are immediately applied” is what I have an challenge with.

 

If we have a compromised or rog= ue DOTS client, the simple use of something like curl, along with the clien= t certificates etc. can be used to generate any ACL with activation-type := =3D ‘immediate’ which is then immediately applied for all traffic within the domain as per the above.

 

[Med] Yes. FWIW, this attack is= called out in the security considerations section:

 

“Nevertheless,=
 an

   attacker who can acce= ss a DOTS client is technically capable of

   launching various att= acks, such as:

 

..;

 

   o  Set invalid ACL entries, which may prevent legiti=
mate traffic from
      being forwarded.  Likewise, invali=
d ACL entries may lead to
      forward DDoS traffic.=

“

 

So, a ACL that blacklists the D= NS server, or drops all port 443 traffic etc. can easily cause all of the o= ther clients / devices within the domain to be taken off air.  Putting= the intelligence into the DOTS server to not allow this to happen could be a challenge.

[The signal channel is much har= der to compromise and affect traffic flows to other areas within the domain= ]

 

I believe that an ACL instantia= ted by a DOTS client (immediate or when-mitigating) should only apply to th= e DOTS client’s traffic which means that the destination-network has = to be a part of the ACL, whether implicitly added by the DOTS server, or by the DOTS client and suitably validated.

 

[Med] Putting aside that I don&= #8217;t parse “DOTS client’s traffic”, I interpret your a= nswer as a support to this question raised for issue #4:<= /p>

    • “Should we mandate destination-network to be present for immediately enforced filters?”

 

There is nothing to stop the DO= TS server or DOTS mitigator merging common ACLs to reduce the number of ACL= s within the mitigation device.

 

As a side note “mitigatio= n-time” is perhaps a bad name as it implies a time period – som= ething like “when-mitigating” to me is clearer.

[Med] Fixed in my local copy. T= hank you.

 

Regards

 

Jon

--_000_BN6PR16MB142505FE4513755531EA7EFCEAAC0BN6PR16MB1425namp_-- From nobody Tue Mar 27 03:37: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 0075912D942 for ; Tue, 27 Mar 2018 03:37:25 -0700 (PDT) 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 vwpiqfSocOqe for ; Tue, 27 Mar 2018 03:37:22 -0700 (PDT) Received: from mail.jpshallow.com (mail.jpshallow.com [217.40.240.153]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4B32C12D88D for ; Tue, 27 Mar 2018 03:37:22 -0700 (PDT) Received: from [127.0.0.1] (helo=N01332) by mail.jpshallow.com with smtps (TLSv1:ECDHE-RSA-AES256-SHA:256) (Exim 4.90_1) (envelope-from ) id 1f0lyh-0000DR-DW; Tue, 27 Mar 2018 11:37:19 +0100 From: "Jon Shallow" To: "'Konda, Tirumaleswar Reddy'" , , References: <008401d3c4fd$216d0840$644718c0$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93302DEF1067@OPEXCLILMA3.corporate.adroot.infra.ftgroup> In-Reply-To: Date: Tue, 27 Mar 2018 11:37:18 +0100 Message-ID: <014801d3c5b7$94c67f00$be537d00$@jpshallow.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0149_01D3C5BF.F68CBBC0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQGlexwLZckIYJuvKwEmwuQr1rXL6AKpdMHOAgMRKpKkGxDm8A== Content-Language: en-gb Archived-At: Subject: Re: [Dots] IETF 101 Presentation Data Channel Issue #4 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, 27 Mar 2018 10:37:25 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0149_01D3C5BF.F68CBBC0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Tiru / Med =20 See inline [Jon] =20 Regards =20 Jon =20 From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of Konda, = Tirumaleswar Reddy Sent: 27 March 2018 09:47 To: mohamed.boucadair@orange.com; Jon Shallow; dots@ietf.org Subject: Re: [Dots] IETF 101 Presentation Data Channel Issue #4 =20 I also support to mandate destination-network for immediately enforced filtering rules. [Jon] This can be enforced / inserted by the DOTS Server for all the destination networks of the domain that the DOTS client =91belongs=92 = to. That said, it would be good to always have the destination network in an ACL = as it can be validated and cross-checked whenever the legitimate set of = domain protected IPs are updated. [Jon] However, what happens to the Destination network in the case of a = call home DOTS client that becomes a quasi DOTS server and the Destination networks are somewhere out on the Internet? =20 -Tiru =20 From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of mohamed.boucadair@orange.com Sent: Tuesday, March 27, 2018 1:09 PM To: Jon Shallow ; dots@ietf.org Subject: Re: [Dots] IETF 101 Presentation Data Channel Issue #4 =20 Hi Jon,=20 =20 Thank you for the comments. =20 Please see inline. =20 Cheers, Med =20 De : Dots [mailto:dots-bounces@ietf.org] De la part de Jon Shallow Envoy=E9 : lundi 26 mars 2018 14:23 =C0 : dots@ietf.org Objet : [Dots] IETF 101 Presentation Data Channel Issue #4 =20 Hi there, =20 As per Med=92s presentation to the IETF 101 =20 Issue #4: Per-Domain or Per-client Filters? =20 =95 Conclusion =96 Filters that are activated only during mitigation time are on a = per-client basis =95 Filters are per-domain when are immediately applied =20 =93Filters are per-domain when are immediately applied=94 is what I have = an challenge with. =20 If we have a compromised or rogue DOTS client, the simple use of = something like curl, along with the client certificates etc. can be used to = generate any ACL with activation-type :=3D =91immediate=92 which is then = immediately applied for all traffic within the domain as per the above. =20 [Med] Yes. FWIW, this attack is called out in the security = considerations section:=20 =20 =93Nevertheless, an attacker who can access a DOTS client is technically capable of launching various attacks, such as: =20 ..; =20 o Set invalid ACL entries, which may prevent legitimate traffic from being forwarded. Likewise, invalid ACL entries may lead to forward DDoS traffic. =93 [Jon] Agreed that the attack is covered off in the Security section, but = we should be limiting the possibility / scope of the attack vector by = enforcing some rules as to what is / is not allowed. Allowing a DOTS client to be able to affect all the traffic within the domain is a huge risk to me = and should not be allowed. So, a ACL that blacklists the DNS server, or drops all port 443 traffic = etc. can easily cause all of the other clients / devices within the domain to = be taken off air. Putting the intelligence into the DOTS server to not = allow this to happen could be a challenge. [The signal channel is much harder to compromise and affect traffic = flows to other areas within the domain] =20 I believe that an ACL instantiated by a DOTS client (immediate or when-mitigating) should only apply to the DOTS client=92s traffic which = means that the destination-network has to be a part of the ACL, whether = implicitly added by the DOTS server, or by the DOTS client and suitably validated. =20 [Med] Putting aside that I don=92t parse =93DOTS client=92s traffic=94, [Jon] I was referring to all the traffic flows that a DOTS client can legitimately request control of to the DOTS server that are within the = scope of what the DOTS client is protecting (which may or may not be the DOTS client=92s IP address). I interpret your answer as a support to this question raised for issue = #4: * =93Should we mandate destination-network to be present for immediately enforced filters?=94 [Jon] See response to Tiru=92s Agreement above. ~Jon There is nothing to stop the DOTS server or DOTS mitigator merging = common ACLs to reduce the number of ACLs within the mitigation device. =20 As a side note =93mitigation-time=94 is perhaps a bad name as it implies = a time period =96 something like =93when-mitigating=94 to me is clearer. [Med] Fixed in my local copy. Thank you. =20 Regards =20 Jon ------=_NextPart_000_0149_01D3C5BF.F68CBBC0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Tiru / Med

 

See inline = [Jon]

 

Regards

 

Jon

 

From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of = Konda, Tirumaleswar Reddy
Sent: 27 March 2018 = 09:47
To: mohamed.boucadair@orange.com; Jon Shallow; = dots@ietf.org
Subject: Re: [Dots] IETF 101 Presentation Data = Channel Issue #4

 

I also support to = mandate destination-network for immediately enforced filtering = rules.

[Jon] This can be = enforced / inserted by the DOTS Server for all the destination networks = of the domain that the DOTS client ‘belongs’ to.=A0 That = said, it would be good to always have the destination network in an ACL = as it can be validated and cross-checked whenever the legitimate set of = domain protected IPs are updated.

[Jon] However, what = happens to the Destination network in the case of a call home DOTS = client that becomes a quasi DOTS server and the Destination networks are = somewhere out on the Internet?

 

-Tiru

 

From: Dots [mailto:dots-bounces@ietf.org] = On Behalf Of mohamed.boucadair@orange.com=
Sent: Tuesday, March 27, 2018 1:09 PM
To: Jon = Shallow <supjps-ietf@jpshallow.com&g= t;; dots@ietf.org
Subject: Re: = [Dots] IETF 101 Presentation Data Channel Issue = #4

 

Hi Jon,

 

Thank you for the comments.

 

Please see inline.

 

Cheers,

Med

 

De : Dots [mailto:dots-bounces@ietf.org] = De la part de Jon Shallow
Envoy=E9 : lundi 26 mars = 2018 14:23
=C0 : dots@ietf.org
Objet : = [Dots] IETF 101 Presentation Data Channel Issue = #4

 

Hi = there,

 

As per Med’s presentation to the IETF = 101

 

Issue #4: Per-Domain or Per-client = Filters?

 

• Conclusion

– Filters that are activated only during = mitigation time are on a per-client basis

   • Filters are per-domain when are = immediately applied

 

“Filters are per-domain when are immediately = applied” is what I have an challenge with.

 

If we have a = compromised or rogue DOTS client, the simple use of something like curl, = along with the client certificates etc. can be used to generate any ACL = with activation-type :=3D ‘immediate’ which is then = immediately applied for all traffic within the domain as per the = above.

 

[Med] = Yes. FWIW, this attack is called out in the security considerations = section:

 

“Nevertheless, =
an

   attacker who can access a = DOTS client is technically capable of

   launching various attacks, = such as:

 

..;

 

   o  Set invalid ACL entries, which may =
prevent legitimate traffic from
      being forwarded.  =
Likewise, invalid ACL entries may lead =
to
      forward DDoS traffic.

“

[Jon] Agreed that the = attack is covered off in the Security section, but we should be limiting = the possibility / scope of the attack vector by enforcing some rules as = to what is / is not allowed.=A0 Allowing a DOTS client to be able to = affect all the traffic within the domain is a huge risk to me and should = not be allowed.

So, = a ACL that blacklists the DNS server, or drops all port 443 traffic etc. = can easily cause all of the other clients / devices within the domain to = be taken off air.  Putting the intelligence into the DOTS server to = not allow this to happen could be a challenge.

[The signal channel is much harder to compromise and = affect traffic flows to other areas within the domain]

 

I believe = that an ACL instantiated by a DOTS client (immediate or when-mitigating) = should only apply to the DOTS client’s traffic which means that = the destination-network has to be a part of the ACL, whether implicitly = added by the DOTS server, or by the DOTS client and suitably = validated.

 

[Med] = Putting aside that I don’t parse “DOTS client’s = traffic”,

[Jon] I was referring to all the traffic flows = that a DOTS client can legitimately request control of to the DOTS = server that are within the scope of what the DOTS client is protecting = (which may or may not be the DOTS client’s IP = address).

I = interpret your answer as a support to this question raised for issue = #4:

    • “Should = we mandate destination-network to be present for immediately enforced = filters?”

[Jon] See response to = Tiru’s Agreement above.

~Jon

There is nothing to stop the DOTS server or DOTS = mitigator merging common ACLs to reduce the number of ACLs within the = mitigation device.

 

As a side = note “mitigation-time” is perhaps a bad name as it implies a = time period – something like “when-mitigating” to me = is clearer.

[Med] = Fixed in my local copy. Thank you.

 

Regards

 

Jon

------=_NextPart_000_0149_01D3C5BF.F68CBBC0-- From nobody Tue Mar 27 03:38: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 DE91512D942 for ; Tue, 27 Mar 2018 03:38:13 -0700 (PDT) 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 V4onFRoKszcX for ; Tue, 27 Mar 2018 03:38:12 -0700 (PDT) Received: from mail.jpshallow.com (mail.jpshallow.com [217.40.240.153]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8AB0A12D88D for ; Tue, 27 Mar 2018 03:38:12 -0700 (PDT) Received: from [127.0.0.1] (helo=N01332) by mail.jpshallow.com with smtps (TLSv1:ECDHE-RSA-AES256-SHA:256) (Exim 4.90_1) (envelope-from ) id 1f0lzX-0000Df-3J; Tue, 27 Mar 2018 11:38:11 +0100 From: "Jon Shallow" To: , References: <009a01d3c4fd$c06ff8d0$414fea70$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93302DEF10D1@OPEXCLILMA3.corporate.adroot.infra.ftgroup> In-Reply-To: <787AE7BB302AE849A7480A190F8B93302DEF10D1@OPEXCLILMA3.corporate.adroot.infra.ftgroup> Date: Tue, 27 Mar 2018 11:38:07 +0100 Message-ID: <015501d3c5b7$b394b230$1abe1690$@jpshallow.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0156_01D3C5C0.155A2BA0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQF7IfC73fh/hyFpFCfivkUz6ZC8VQKLxNXJpIDNQQA= Content-Language: en-gb Archived-At: Subject: Re: [Dots] WGLC signal-18 ack-timeout Nits 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, 27 Mar 2018 10:38:14 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0156_01D3C5C0.155A2BA0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Thanks =20 From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of mohamed.boucadair@orange.com Sent: 27 March 2018 09:34 To: Jon Shallow; dots@ietf.org Subject: Re: [Dots] WGLC signal-18 ack-timeout Nits =20 Hi Jon, =20 Fixed to avoid misinterpreting the spec through the examples.=20 =20 Cheers, Med =20 De : Dots [mailto:dots-bounces@ietf.org] De la part de Jon Shallow Envoy=E9 : lundi 26 mars 2018 14:27 =C0 : dots@ietf.org Objet : [Dots] WGLC signal-18 ack-timeout Nits =20 Hi there, =20 a) "ack-timeout": { "max-value-decimal": 30, "min-value-decimal": 1, "current-value-decimal": 2 }, b) ack-timeout (2 seconds) =20 c) "ack-timeout": { "current-value-decimal": 5 }, =20 Should really read (for clarity as they are now decimal numbers) in = various places =20 "ack-timeout": { "max-value-decimal": 30.0, "min-value-decimal": 1.0, "current-value-decimal": 2.0 }, =20 ack-timeout (2.0 seconds) =20 "ack-timeout": { "current-value-decimal": 5.0 }, [I would prefer this to be 2.0, not 5.0 as it should not normally be = changed and people are known to slavishly copy examples, and Figure 20: is = really about changing the heartbeat interval. Likewise, max-transmit should = really be 3, not 7 in Figure 20:] =20 Regards =20 Jon ------=_NextPart_000_0156_01D3C5C0.155A2BA0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Thanks

 

From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of = mohamed.boucadair@orange.com
Sent: 27 March 2018 = 09:34
To: Jon Shallow; dots@ietf.org
Subject: Re: = [Dots] WGLC signal-18 ack-timeout = Nits

 

Hi Jon,

 

Fixed to avoid misinterpreting the spec through the = examples.

 

Cheers,

Med

 

De : Dots [mailto:dots-bounces@ietf.org] = De la part de Jon Shallow
Envoy=E9 : lundi 26 mars = 2018 14:27
=C0 : dots@ietf.org
Objet : = [Dots] WGLC signal-18 ack-timeout = Nits

 

Hi = there,

 

a)

         = "ack-timeout": {

         &= nbsp; "max-value-decimal": 30,

         &= nbsp; "min-value-decimal": 1,

         &= nbsp; "current-value-decimal": 2

         = },

b)

ack-timeout (2 seconds)

 

c)

         &= nbsp; "ack-timeout": {

         &= nbsp;   "current-value-decimal": 5

         &= nbsp; },

 

Should really read (for clarity as they are now = decimal numbers) in various places

 

         = "ack-timeout": {

         &= nbsp; "max-value-decimal": 30.0,

         &= nbsp; "min-value-decimal": 1.0,

         &= nbsp; "current-value-decimal": 2.0

         = },

 

ack-timeout (2.0 seconds)

 

         &= nbsp; "ack-timeout": {

         &= nbsp;   "current-value-decimal": = 5.0

         &= nbsp; },

[I would prefer this to be = 2.0, not 5.0 as it should not normally be changed and people are known = to slavishly copy examples, and Figure 20: is really about changing the = heartbeat interval.  Likewise, max-transmit should really be 3, not = 7 in Figure 20:]

 

Regards

 

Jon

------=_NextPart_000_0156_01D3C5C0.155A2BA0-- From nobody Tue Mar 27 05:35:03 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 03F8512D95E for ; Tue, 27 Mar 2018 05:35:02 -0700 (PDT) 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 t9FFT-4P-2wR for ; Tue, 27 Mar 2018 05:35:00 -0700 (PDT) Received: from mail.jpshallow.com (mail.jpshallow.com [217.40.240.153]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2CB9D12D954 for ; Tue, 27 Mar 2018 05:35:00 -0700 (PDT) Received: from [127.0.0.1] (helo=N01332) by mail.jpshallow.com with smtps (TLSv1:ECDHE-RSA-AES256-SHA:256) (Exim 4.90_1) (envelope-from ) id 1f0noY-0000H8-Hm; Tue, 27 Mar 2018 13:34:58 +0100 From: "Jon Shallow" To: , References: <05c801d3c2bc$88171290$984537b0$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93302DEF10B4@OPEXCLILMA3.corporate.adroot.infra.ftgroup> In-Reply-To: <787AE7BB302AE849A7480A190F8B93302DEF10B4@OPEXCLILMA3.corporate.adroot.infra.ftgroup> Date: Tue, 27 Mar 2018 13:34:57 +0100 Message-ID: <018701d3c5c8$044db950$0ce92bf0$@jpshallow.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0188_01D3C5D0.6613F610" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQLZExA96e11tdoJyqOqcaxu1U7VtQIUMridocin9GA= Content-Language: en-gb Archived-At: Subject: Re: [Dots] WGLC signal-18 Draft Hop Limit tidy up 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, 27 Mar 2018 12:35:02 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0188_01D3C5D0.6613F610 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Med, =20 See inline [Jon1] =20 Regards =20 Jon =20 From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of mohamed.boucadair@orange.com Sent: 27 March 2018 09:22 To: Jon Shallow; dots@ietf.org Subject: Re: [Dots] WGLC signal-18 Draft Hop Limit tidy up =20 Hi Jon,=20 =20 Please see inline.=20 =20 Cheers, Med =20 De : Dots [mailto:dots-bounces@ietf.org] De la part de Jon Shallow Envoy=E9 : vendredi 23 mars 2018 16:35 =C0 : dots@ietf.org Objet : [Dots] WGLC signal-18 Draft Hop Limit tidy up =20 Hi there, =20 I believe that there are a couple of changes required for the hop-limit definition =96 see [Jon] inline. =20 hop-limit: This option (see Section 9.4) is used to detect = and prevent infinite loops. This option is typically inserted = by a DOTS gateway. =20 The length of the hop-limit option is 1 byte. =20 The value of the hop-limit option is encoded as an = unsigned integer (see Section 3.2 of [RFC7252]). =20 Each intermediate DOTS agent involved in the handling of a DOTS message MUST decrement the hop-limit option value by 1 = prior to forwarding upstream if this parameter exists. DOTS = messages MUST NOT be forwarded if the hop-limit option 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. [Jon] We need to add in something like:- Each intermediate DOTS agent SHOULD add in the hop-limit option with the initial default value if it does not exist before forwarding upstream = any information. =20 [Med] I=92m not sure to understand this one. Please note that the text = says =93A DOTS gateway may add the following CoAP option=94. This is typically a = GW which is instructed to insert the option will inject the option and = follows the setting of the initial value. =20 [Jon1] I guess that I am trying to differentiate between updating an existing Hop-Limit and not injecting a new one alongside a previous one. Having multiple Hop-Limit options could get interesting! =20 [Jon] We need to define the format of the 5.06 CoAP diagnostic message = so that it is potentially parseable by the DOTS client as well as by any = other potential RFC that make use of this 5.06 code. In addition, it would be good if each intermediate DOTS agent appended its own IP (prefixed by a blank) to the end of the diagnostic message as the 5.06 response gets = passed back through the DOST agents to enable troubleshooting at the DOTS = client. The diagnostic message length would need to be restricted to something = like 1000 bytes to prevent UDP fragmentation. Suggestions welcome here. =20 [Med] I can see a value in recording the list of GWs involved in a loop = for debugging purposes at the DOTS server domain, but I=92m not sure there = is a value to pass that list to the DOTS client. For example, a server domain = may want to hide its internal topology (list of GWs and servers involved in handling a mitigation request). Below a text proposal for discussion: =20 To ease debugging and troubleshooting, the DOTS gateway which detects a loop SHOULD include its information (e.g., server name, alias, IP address) in the diagnostic payload under the conditions detailed in Section 5.5.2 of [RFC7252]. Each intermediate DOTS gateway involved in relaying a 5.06 (Hop Limit Reached) error message SHOULD prepend its own information in the diagnostic payload with a space character used as separator. The ultimate DOTS gateway SHOULD remove the diagnostic payload before forwarding the 5.06 (Hop Limit Reached) error message to a DOTS client domain. [Jon1] I have no issues if a server domain really wants to strip out its internal hops =96 but troubleshooting is more of a challenge and would = not recommend it. [Jon1] However, when setting up a DOTS client, which is failing to work = for whatever reason, it would be good to have a reasonable level of = diagnostics on the Client =96 separately invoking someone to look at a DOTS = server=92s logs may take time to get responded to =96 and you as a novice DOTS client = user will have no idea as to what to tell the DOTS server guy to look for in = the server=92s busy logs. [Jon1] I would also like the structure of the diagnostic message to be = well formatted (e.g., no leading text, only one of server name / alias / IP address, blank separator etc.) so it can easily be documented in user manuals etc. as well as perhaps parsed by a receiver of the 5.06 message (interim hop or final destination). All other responses (albeit in = cbor) are pretty well documented. =20 =20 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. =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 option. [Jon] This should read =93This is an optional CoAP Option=94. =20 [Med] I can make the change. Please note that the text starts with =93A = DOTS gateway may add the following CoAP option=94 which is clear enough this = is about an optional CoAP option. =20 [Jon1] I guess I am being picky! ~jon1 Regards =20 Jon ------=_NextPart_000_0188_01D3C5D0.6613F610 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Med,

 

See inline = [Jon1]

 

Regards

 

Jon

 

From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of = mohamed.boucadair@orange.com
Sent: 27 March 2018 = 09:22
To: Jon Shallow; dots@ietf.org
Subject: Re: = [Dots] WGLC signal-18 Draft Hop Limit tidy = up

 

Hi Jon,

 

Please see inline.

 

Cheers,

Med

 

De : Dots [mailto:dots-bounces@ietf.org] = De la part de Jon Shallow
Envoy=E9 : vendredi 23 = mars 2018 16:35
=C0 : dots@ietf.org
Objet : = [Dots] WGLC signal-18 Draft Hop Limit tidy = up

 

Hi = there,

 

I believe that there are a couple of changes required = for the hop-limit definition – see [Jon] inline.

 

         &= nbsp; hop-limit:  This option (see Section 9.4) is used to detect = and

         &= nbsp;    prevent infinite loops.  This option is = typically inserted by a

         &= nbsp;    DOTS gateway.

 

         &= nbsp;    The length of the hop-limit option is 1 = byte.

 

         &= nbsp;    The value of the hop-limit option is encoded as = an unsigned

         &= nbsp;    integer (see Section 3.2 of = [RFC7252]).

 

         &= nbsp;    Each intermediate DOTS agent involved in the = handling of a DOTS

         &= nbsp;    message MUST decrement the hop-limit option = value by 1 prior to

         &= nbsp;    forwarding upstream if this parameter = exists.  DOTS messages MUST

         &= nbsp;    NOT be forwarded if the hop-limit option is set = to '0' after

         &= nbsp;    decrement.  Messages that cannot be = forwarded because of exhausted

         &= nbsp;    hop-limit SHOULD be logged with a 5.06 (Hop = Limit Reached) error

         &= nbsp;    message sent back to the DOTS peer.  It is = RECOMMENDED that DOTS

         &= nbsp;    clients and gateways support means to alert = administrators about

         &= nbsp;    loop errors so that appropriate actions are = undertaken.

[Jon] We need to add in = something like:-

Each intermediate = DOTS agent SHOULD add in the hop-limit option with the initial default = value if it does not exist before forwarding upstream any = information.

 

[Med] = I’m not sure to understand this one. Please note that the text = says “A DOTS gateway may add the following CoAP option”. = This is typically a GW which is instructed to insert the option will = inject the option and follows the setting of the initial = value.

 

[Jon1] I guess that I am = trying to differentiate between updating an existing Hop-Limit and not = injecting a new one alongside a previous one.=A0 Having multiple = Hop-Limit options could get interesting!

 

[Jon] We need to define the format of the 5.06 CoAP = diagnostic message so that it is potentially parseable by the DOTS = client as well as by any other potential RFC that make use of this 5.06 = code.  In addition, it would be good if each intermediate DOTS = agent appended its own IP (prefixed by a blank) to the end of the = diagnostic message as the 5.06 response gets passed back through the = DOST agents to enable troubleshooting at the DOTS client.  The = diagnostic message length would need to be restricted to something like = 1000 bytes to prevent UDP fragmentation.  Suggestions welcome = here.

 

[Med] I = can see a value in recording the list of GWs involved in a loop for = debugging purposes at the DOTS server domain, but I’m not sure = there is a value to pass that list to the DOTS client. For example, a = server domain may want to hide its internal topology (list of GWs and = servers involved in handling a mitigation request). Below a  text = proposal for discussion:

 

      To ease = debugging and troubleshooting, the DOTS gateway = which

      detects a = loop SHOULD include its information (e.g., server = name,

      alias, IP = address) in the diagnostic payload under the = conditions

      detailed in = Section 5.5.2 of [RFC7252].  Each intermediate = DOTS

      gateway = involved in relaying a 5.06 (Hop Limit Reached) = error

      message = SHOULD prepend its own information in the = diagnostic

      payload = with a space character used as separator.  The = ultimate

      DOTS = gateway SHOULD remove the diagnostic payload = before

      forwarding = the 5.06 (Hop Limit Reached) error message to a = DOTS

      = client domain.

[Jon1] I have no issues = if a server domain really wants to strip out its internal hops – = but troubleshooting is more of a challenge and would not recommend = it.

[Jon1] However, when setting up a DOTS client, = which is failing to work for whatever reason, it would be good to have a = reasonable level of diagnostics on the Client – separately = invoking someone to look at a DOTS server’s logs may take time to = get responded to – and you as a novice DOTS client user will have = no idea as to what to tell the DOTS server guy to look for in the = server’s busy logs.

[Jon1] I would also like = the structure of the diagnostic message to be well formatted (e.g., no = leading text, only one of server name / alias / IP address, blank = separator etc.) so it can easily be documented in user manuals etc. as = well as perhaps parsed by a receiver of the 5.06 message (interim hop or = final destination). =A0All other responses (albeit in cbor) are pretty = well documented.

 

 

         &= nbsp;    The initial hop-limit value SHOULD be = configurable.  If no initial

         &= nbsp;    value is explicitly provided, the default = initial hop-limit value

         &= nbsp;    of 16 MUST be used.

 

         &= nbsp;    Because forwarding errors may occur if = inadequate hop-limit values

         &= nbsp;    are used, DOTS agents at the boundaries of an = administrative

          =     domain MAY be instructed to rewrite the value of = hop-limit carried

         &= nbsp;    in received messages (that is, ignore the value = of hop-limit

         &= nbsp;    received in a message).

 

         &= nbsp;    This is an optional option.

[Jon] This should read “This is an optional CoAP = Option”.

 

[Med] I can make the change. Please note that the text = starts with “A DOTS gateway may add the following = CoAP option” = which is clear enough this is about an optional CoAP = option.

 

[Jon1] I guess I am = being picky!

~jon1

Regards

 

Jon

------=_NextPart_000_0188_01D3C5D0.6613F610-- From nobody Tue Mar 27 05:49: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 8A62D127286 for ; Tue, 27 Mar 2018 05:49:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.309 X-Spam-Level: X-Spam-Status: No, score=-4.309 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, 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 5RWLK4qFFZ2m for ; Tue, 27 Mar 2018 05:49:40 -0700 (PDT) Received: from DNVWSMAILOUT1.mcafee.com (dnvwsmailout1.mcafee.com [161.69.31.173]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CD776127342 for ; Tue, 27 Mar 2018 05:49:39 -0700 (PDT) X-NAI-Header: Modified by McAfee Email Gateway (5500) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mcafee.com; s=s_mcafee; t=1522154964; 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:MIME-Version:X-MS-Exchange-CrossTenant-Network-Message-Id: X-MS-Exchange-CrossTenant-originalarrivaltime: X-MS-Exchange-CrossTenant-fromentityheader: X-MS-Exchange-CrossTenant-id:X-MS-Exchange-Transport-CrossTenantHeadersStamped: X-OriginatorOrg:X-NAI-Spam-Flag:X-NAI-Spam-Threshold: X-NAI-Spam-Score:X-NAI-Spam-Version; bh=z 9lCM0jleDLjbW6lFBCyAmjNoh3HaGTJeCcOAdBJ+y g=; b=YFlcFaeao6DFI11dLGDyYqrgOIYT09uEVRdrGhcEKh9i WHHaKXmiWM+sWt85VjVb4EvwGQ2D25cfClBHaE/EpUEJGRiuVv QoSV4szd4qhg8l18EoLB8ilZSvMTg8io/xE5ACDmMfDrhVx+PC AK6KeUcqx6NXbocwzotCzr6BR98= 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 31de_dce4_b71f440f_aeec_4696_b1f5_a15ae65f529a; Tue, 27 Mar 2018 07:49:23 -0500 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; Tue, 27 Mar 2018 06:48:33 -0600 Received: from DNVO365EDGE2.corpzone.internalzone.com (10.44.176.74) by DNVEXUSR1N10.corpzone.internalzone.com (10.44.48.83) with Microsoft SMTP Server (TLS) id 15.0.1347.2 via Frontend Transport; Tue, 27 Mar 2018 06:48:33 -0600 Received: from NAM03-DM3-obe.outbound.protection.outlook.com (10.44.176.242) by edge.mcafee.com (10.44.176.74) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Tue, 27 Mar 2018 06:48:31 -0600 Received: from BN6PR16MB1425.namprd16.prod.outlook.com (10.172.207.19) by BN6PR16MB1458.namprd16.prod.outlook.com (10.172.207.140) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.609.10; Tue, 27 Mar 2018 12:48:31 +0000 Received: from BN6PR16MB1425.namprd16.prod.outlook.com ([fe80::b9d0:eb7e:fb41:137d]) by BN6PR16MB1425.namprd16.prod.outlook.com ([fe80::b9d0:eb7e:fb41:137d%2]) with mapi id 15.20.0609.012; Tue, 27 Mar 2018 12:48:31 +0000 From: "Konda, Tirumaleswar Reddy" To: Jon Shallow , "mohamed.boucadair@orange.com" , "dots@ietf.org" Thread-Topic: [Dots] IETF 101 Presentation Data Channel Issue #4 Thread-Index: AdPE/QAkDtOD9YeqSAaov9+szxQnSQAoMdfAAAKPC+AAA+QiAAAEVj7w Date: Tue, 27 Mar 2018 12:48:31 +0000 Message-ID: References: <008401d3c4fd$216d0840$644718c0$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93302DEF1067@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <014801d3c5b7$94c67f00$be537d00$@jpshallow.com> In-Reply-To: <014801d3c5b7$94c67f00$be537d00$@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.200.100 dlp-reaction: no-action authentication-results: spf=none (sender IP is ) smtp.mailfrom=TirumaleswarReddy_Konda@McAfee.com; x-originating-ip: [122.166.138.210] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BN6PR16MB1458; 7:9mGqEjsFd8TXQv7h8Nvuq2L7puVnGxuEk7mb+pOUD/p7mck7t8RwAKJCYBDnruUlcbHyMh+gquPCrtoS2HWbmb1VyssKcewaQ7KQg4zP03T+I8khBNQvlPWzWPrYHGle+dU/+4jdChogvkUu1K5A3PXesqULe2tTuf4s72/3UZcwOfcB7go1gZ6y9ampS8uiopUqXuO4G67yx8UgaOkEWRG8usBkl0yNsTCldrzTuo2QmAyXKaCJgybRCImwi8mo x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: 0c1d2b14-c24c-4a01-cfbd-08d593e10bbc x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(4604075)(3008032)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7153060)(7193020); SRVR:BN6PR16MB1458; x-ms-traffictypediagnostic: BN6PR16MB1458: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(158342451672863)(192374486261705)(18271650672692)(21748063052155)(123452027830198); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(3002001)(10201501046)(3231221)(944501327)(52105095)(93006095)(93001095)(6041310)(20161123562045)(20161123558120)(20161123564045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(6072148)(201708071742011); SRVR:BN6PR16MB1458; BCL:0; PCL:0; RULEID:; SRVR:BN6PR16MB1458; x-forefront-prvs: 0624A2429E x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(979002)(39380400002)(39860400002)(396003)(366004)(376002)(346002)(32952001)(189003)(199004)(5383002)(76176011)(74316002)(110136005)(72206003)(99286004)(102836004)(53936002)(229853002)(7736002)(86362001)(2201001)(66066001)(486005)(476003)(80792005)(486005)(14454004)(26005)(345774005)(186003)(5250100002)(19609705001)(81156014)(81166006)(478600001)(8676002)(316002)(236005)(2906002)(3660700001)(7696005)(97736004)(5660300001)(3280700002)(2900100001)(55016002)(446003)(68736007)(6116002)(11346002)(33656002)(6506007)(106356001)(9686003)(93886005)(6436002)(105586002)(54896002)(6246003)(53546011)(6306002)(3846002)(790700001)(25786009)(59450400001)(2501003)(8936002)(91024005)(85282002)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1101; SCL:1; SRVR:BN6PR16MB1458; H:BN6PR16MB1425.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: qRmWyup+ZO7WwMiN0e34GbZsLcR5kG0q/GwUK2FrriLiSu21Be9oaogRseNXcubHGozqQFPZUAjkx5e0Wo94AicwV+qo1ZsZKuWFwYwKhbqRz92qWlJdiIqA/wFphhxhrbucDk614x/Umw3yqV7IK1aQOas7WVGmR7vCSXDPjUeNepGB7sc8YVkV4f7hPW+s+03Z5lXjg5IrUBvXJBGarQVFPQI7xsgkzeadGhOXy03xjp8ky+xr/p8lmz+igxCjYaTNzCLk84u6jLLO4m89wNQSnfZRaKy2ZYQSQ2wGVG1n+dZdT4ryvU0u3vc7twEw4l/XCm+o05atDc7UixoMAQ== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BN6PR16MB1425E0546012F3651B6F997AEAAC0BN6PR16MB1425namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 0c1d2b14-c24c-4a01-cfbd-08d593e10bbc X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Mar 2018 12:48:31.6172 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4943e38c-6dd4-428c-886d-24932bc2d5de X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR16MB1458 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 <6251> : inlines <6520> : streams <1782411> : uri <2615714> Archived-At: Subject: Re: [Dots] IETF 101 Presentation Data Channel Issue #4 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, 27 Mar 2018 12:49:42 -0000 --_000_BN6PR16MB1425E0546012F3651B6F997AEAAC0BN6PR16MB1425namp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Please see inline [TR] From: Jon Shallow [mailto:supjps-ietf@jpshallow.com] Sent: Tuesday, March 27, 2018 4:07 PM To: Konda, Tirumaleswar Reddy ; mohamed= .boucadair@orange.com; dots@ietf.org Subject: RE: [Dots] IETF 101 Presentation Data Channel Issue #4 Hi Tiru / Med See inline [Jon] Regards Jon From: Dots [mailto: dots-bounces@ietf.org] On= Behalf Of Konda, Tirumaleswar Reddy Sent: 27 March 2018 09:47 To: mohamed.boucadair@orange.com; Jon = Shallow; dots@ietf.org Subject: Re: [Dots] IETF 101 Presentation Data Channel Issue #4 I also support to mandate destination-network for immediately enforced filt= ering rules. [Jon] This can be enforced / inserted by the DOTS Server for all the destin= ation networks of the domain that the DOTS client 'belongs' to. That said,= it would be good to always have the destination network in an ACL as it ca= n be validated and cross-checked whenever the legitimate set of domain prot= ected IPs are updated. [Jon] However, what happens to the Destination network in the case of a cal= l home DOTS client that becomes a quasi DOTS server and the Destination net= works are somewhere out on the Internet? [TR] DDOS is a targeted attack, so the DOTS client can specify the destinat= ion network targeted by devices in the DOTS server domain and the DOTS serv= er can validate if the destination network is indeed targeted by its device= s. -Tiru From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of mohamed.boucadair@or= ange.com Sent: Tuesday, March 27, 2018 1:09 PM To: Jon Shallow >; dots@ietf.org Subject: Re: [Dots] IETF 101 Presentation Data Channel Issue #4 Hi Jon, Thank you for the comments. Please see inline. Cheers, Med De : Dots [mailto:dots-bounces@ietf.org] De la part de Jon Shallow Envoy=E9 : lundi 26 mars 2018 14:23 =C0 : dots@ietf.org Objet : [Dots] IETF 101 Presentation Data Channel Issue #4 Hi there, As per Med's presentation to the IETF 101 Issue #4: Per-Domain or Per-client Filters? * Conclusion - Filters that are activated only during mitigation time are on a per-clien= t basis * Filters are per-domain when are immediately applied "Filters are per-domain when are immediately applied" is what I have an cha= llenge with. If we have a compromised or rogue DOTS client, the simple use of something = like curl, along with the client certificates etc. can be used to generate = any ACL with activation-type :=3D 'immediate' which is then immediately app= lied for all traffic within the domain as per the above. [Med] Yes. FWIW, this attack is called out in the security considerations s= ection: "Nevertheless, an attacker who can access a DOTS client is technically capable of launching various attacks, such as: ..; o Set invalid ACL entries, which may prevent legitimate traffic from being forwarded. Likewise, invalid ACL entries may lead to forward DDoS traffic. " [Jon] Agreed that the attack is covered off in the Security section, but we= should be limiting the possibility / scope of the attack vector by enforci= ng some rules as to what is / is not allowed. Allowing a DOTS client to be= able to affect all the traffic within the domain is a huge risk to me and = should not be allowed. So, a ACL that blacklists the DNS server, or drops all port 443 traffic etc= . can easily cause all of the other clients / devices within the domain to = be taken off air. Putting the intelligence into the DOTS server to not all= ow this to happen could be a challenge. [The signal channel is much harder to compromise and affect traffic flows t= o other areas within the domain] I believe that an ACL instantiated by a DOTS client (immediate or when-miti= gating) should only apply to the DOTS client's traffic which means that the= destination-network has to be a part of the ACL, whether implicitly added = by the DOTS server, or by the DOTS client and suitably validated. [Med] Putting aside that I don't parse "DOTS client's traffic", [Jon] I was referring to all the traffic flows that a DOTS client can legit= imately request control of to the DOTS server that are within the scope of = what the DOTS client is protecting (which may or may not be the DOTS client= 's IP address). I interpret your answer as a support to this question raised for issue #4: * "Should we mandate destination-network to be present for immediate= ly enforced filters?" [Jon] See response to Tiru's Agreement above. ~Jon There is nothing to stop the DOTS server or DOTS mitigator merging common A= CLs to reduce the number of ACLs within the mitigation device. As a side note "mitigation-time" is perhaps a bad name as it implies a time= period - something like "when-mitigating" to me is clearer. [Med] Fixed in my local copy. Thank you. Regards Jon --_000_BN6PR16MB1425E0546012F3651B6F997AEAAC0BN6PR16MB1425namp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Please se= e inline [TR]

 

From:<= /span> Jon Shallow [mailto:s= upjps-ietf@jpshallow.com]
Sent: Tuesday, March 27, 2018 4:07 PM
To: Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@McAfee.com= >; mohamed.boucadair@orange.com; dots@ietf.org
Subject: RE: [Dots] IETF 101 Presentation Data Channel Issue #4=

 

Hi Tiru= / Med

&n= bsp;

See inl= ine [Jon]

&n= bsp;

Regards=

&n= bsp;

Jon

&n= bsp;

From: Dots [mailto: dots-bounces@ietf.org] On B= ehalf Of Konda, Tirumaleswar Reddy
Sent: 27 March 2018 09:47
To: mohamed.boucadai= r@orange.com; Jon Shallow; dots@ietf.org
Subject: Re: [Dots] IETF 101 Presentation Data Channel Issue #4=

 

I also su= pport to mandate destination-network for immediately enforced filtering rul= es.

[Jon] This can be enforced / inserted by the DOTS Server for all the d= estination networks of the domain that the DOTS client ‘belongs’= ; to.  That said, it would be good to always have the destination network in an ACL as it can be validated and cross-checked= whenever the legitimate set of domain protected IPs are updated.

[Jon] However, what happens to the Destination network in the case of = a call home DOTS client that becomes a quasi DOTS server and the Destinatio= n networks are somewhere out on the Internet?

&nbs= p;

[TR] DDOS= is a targeted attack, so the DOTS client can specify the destination netwo= rk targeted by devices in the DOTS server domain and the DOTS server can va= lidate if the destination network is indeed targeted by its devices.

&nbs= p;

-Tiru

&nbs= p;

From:<= /span> Dots [mailto:dots-bounces@ietf.org] On Behalf Of mohamed= .boucadair@orange.com
Sent: Tuesday, March 27, 2018 1:09 PM
To: Jon Shallow <sup= jps-ietf@jpshallow.com>; dots@ietf.org
Subject: Re: [Dots] IETF 101 Presentation Data Channel Issue #4=

 

Hi Jon,

 

Thank you for the comments.<= /p>

 

Please see inline.

 

Cheers,

Med

 

De : Dots [mailto:dots-bounces@ietf.org] De la part de Jon Shallow
Envoy=E9 : lundi 26 mars 2018 14:23
=C0 : dots@ietf.org
Objet : [Dots] IETF 101 Presentation Data Channel Issue #4=

 

Hi there,

 

As per Med’s presentation= to the IETF 101

 

Issue #4: Per-Domain or Per-cli= ent Filters?

 

• Conclusion

– Filters that are activa= ted only during mitigation time are on a per-client basis=

   • Filters ar= e per-domain when are immediately applied

 

“Filters are per-domain w= hen are immediately applied” is what I have an challenge with.

 

If we have a compromised or rog= ue DOTS client, the simple use of something like curl, along with the clien= t certificates etc. can be used to generate any ACL with activation-type := =3D ‘immediate’ which is then immediately applied for all traffic within the domain as per the above.

 

[Med] Yes. FWIW, this attack is= called out in the security considerations section:

 

“Nevertheless,=
 an

   attacker who can acce= ss a DOTS client is technically capable of

   launching various att= acks, such as:

 

..;

 

   o  Set invalid ACL entries, which may prevent legiti=
mate traffic from
      being forwarded.  Likewise, invali=
d ACL entries may lead to
      forward DDoS traffic.=

“

[Jon] A= greed that the attack is covered off in the Security section, but we should= be limiting the possibility / scope of the attack vector by enforcing some= rules as to what is / is not allowed.  Allowing a DOTS client to be able to affect all the traffic within the dom= ain is a huge risk to me and should not be allowed.

 

So, a ACL that blacklists the D= NS server, or drops all port 443 traffic etc. can easily cause all of the o= ther clients / devices within the domain to be taken off air.  Putting= the intelligence into the DOTS server to not allow this to happen could be a challenge.

[The signal channel is much har= der to compromise and affect traffic flows to other areas within the domain= ]

 

I believe that an ACL instantia= ted by a DOTS client (immediate or when-mitigating) should only apply to th= e DOTS client’s traffic which means that the destination-network has = to be a part of the ACL, whether implicitly added by the DOTS server, or by the DOTS client and suitably validated.

 

[Med] Putting aside that I don&= #8217;t parse “DOTS client’s traffic”,

[Jon] I= was referring to all the traffic flows that a DOTS client can legitimately= request control of to the DOTS server that are within the scope of what th= e DOTS client is protecting (which may or may not be the DOTS client’s IP address).

I interpret your answer as a su= pport to this question raised for issue #4:

    • “Should we mandate destination-network to be present for immediately enforced filters?”

[Jon] S= ee response to Tiru’s Agreement above.

~Jon

There is nothing to stop the DO= TS server or DOTS mitigator merging common ACLs to reduce the number of ACL= s within the mitigation device.

 

As a side note “mitigatio= n-time” is perhaps a bad name as it implies a time period – som= ething like “when-mitigating” to me is clearer.

[Med] Fixed in my local copy. T= hank you.

 

Regards

 

Jon

--_000_BN6PR16MB1425E0546012F3651B6F997AEAAC0BN6PR16MB1425namp_-- From nobody Tue Mar 27 07:14: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 3E12E12D7E6 for ; Tue, 27 Mar 2018 07:14:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.608 X-Spam-Level: X-Spam-Status: No, score=-2.608 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 ygSzeYfgHcpE for ; Tue, 27 Mar 2018 07:14:09 -0700 (PDT) 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 D2085124D68 for ; Tue, 27 Mar 2018 07:14:08 -0700 (PDT) Received: from opfednr05.francetelecom.fr (unknown [xx.xx.xx.69]) by opfednr22.francetelecom.fr (ESMTP service) with ESMTP id A4F6020920; Tue, 27 Mar 2018 16:14:07 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.17]) by opfednr05.francetelecom.fr (ESMTP service) with ESMTP id 8109420074; Tue, 27 Mar 2018 16:14:07 +0200 (CEST) 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; Tue, 27 Mar 2018 16:14:04 +0200 From: To: Jon Shallow , "dots@ietf.org" Thread-Topic: [Dots] WGLC signal-18 Draft Hop Limit tidy up Thread-Index: AQLZExA96e11tdoJyqOqcaxu1U7VtQIUMridocin9GCAADc7IA== Date: Tue, 27 Mar 2018 14:13:58 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93302DEF3579@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <05c801d3c2bc$88171290$984537b0$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93302DEF10B4@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <018701d3c5c8$044db950$0ce92bf0$@jpshallow.com> In-Reply-To: <018701d3c5c8$044db950$0ce92bf0$@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.6] Content-Type: multipart/alternative; boundary="_000_787AE7BB302AE849A7480A190F8B93302DEF3579OPEXCLILMA3corp_" MIME-Version: 1.0 Archived-At: Subject: Re: [Dots] WGLC signal-18 Draft Hop Limit tidy up 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, 27 Mar 2018 14:14:11 -0000 --_000_787AE7BB302AE849A7480A190F8B93302DEF3579OPEXCLILMA3corp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re-, Please see inline. Cheers, Med De : Jon Shallow [mailto:supjps-ietf@jpshallow.com] Envoy=E9 : mardi 27 mars 2018 14:35 =C0 : BOUCADAIR Mohamed IMT/OLN; dots@ietf.org Objet : RE: [Dots] WGLC signal-18 Draft Hop Limit tidy up Hi Med, See inline [Jon1] Regards Jon From: Dots [mailto: dots-bounces@ietf.org] On= Behalf Of mohamed.boucadair@orange.com Sent: 27 March 2018 09:22 To: Jon Shallow; dots@ietf.org Subject: Re: [Dots] WGLC signal-18 Draft Hop Limit tidy up Hi Jon, Please see inline. Cheers, Med De : Dots [mailto:dots-bounces@ietf.org] De la part de Jon Shallow Envoy=E9 : vendredi 23 mars 2018 16:35 =C0 : dots@ietf.org Objet : [Dots] WGLC signal-18 Draft Hop Limit tidy up Hi there, I believe that there are a couple of changes required for the hop-limit def= inition - see [Jon] inline. hop-limit: This option (see Section 9.4) is used to detect and prevent infinite loops. This option is typically inserted by= a DOTS gateway. The length of the hop-limit option is 1 byte. The value of the hop-limit option is encoded as an unsigned integer (see Section 3.2 of [RFC7252]). Each intermediate DOTS agent involved in the handling of a DO= TS message MUST decrement the hop-limit option value by 1 prior = to forwarding upstream if this parameter exists. DOTS messages = MUST NOT be forwarded if the hop-limit option is set to '0' after decrement. Messages that cannot be forwarded because of exha= usted hop-limit SHOULD be logged with a 5.06 (Hop Limit Reached) er= ror message sent back to the DOTS peer. It is RECOMMENDED that D= OTS clients and gateways support means to alert administrators ab= out loop errors so that appropriate actions are undertaken. [Jon] We need to add in something like:- Each intermediate DOTS agent SHOULD add in the hop-limit option with the in= itial default value if it does not exist before forwarding upstream any inf= ormation. [Med] I'm not sure to understand this one. Please note that the text says "= A DOTS gateway may add the following CoAP option". This is typically a GW w= hich is instructed to insert the option will inject the option and follows = the setting of the initial value. [Jon1] I guess that I am trying to differentiate between updating an existi= ng Hop-Limit and not injecting a new one alongside a previous one. Having = multiple Hop-Limit options could get interesting! [Med] OK, I get your point. What about adding : NEW: Only one single instance of the option is allowed in a message. [Jon] We need to define the format of the 5.06 CoAP diagnostic message so t= hat it is potentially parseable by the DOTS client as well as by any other = potential RFC that make use of this 5.06 code. In addition, it would be go= od if each intermediate DOTS agent appended its own IP (prefixed by a blank= ) to the end of the diagnostic message as the 5.06 response gets passed bac= k through the DOST agents to enable troubleshooting at the DOTS client. Th= e diagnostic message length would need to be restricted to something like 1= 000 bytes to prevent UDP fragmentation. Suggestions welcome here. [Med] I can see a value in recording the list of GWs involved in a loop for= debugging purposes at the DOTS server domain, but I'm not sure there is a = value to pass that list to the DOTS client. For example, a server domain ma= y want to hide its internal topology (list of GWs and servers involved in h= andling a mitigation request). Below a text proposal for discussion: To ease debugging and troubleshooting, the DOTS gateway which detects a loop SHOULD include its information (e.g., server name, alias, IP address) in the diagnostic payload under the conditions detailed in Section 5.5.2 of [RFC7252]. Each intermediate DOTS gateway involved in relaying a 5.06 (Hop Limit Reached) error message SHOULD prepend its own information in the diagnostic payload with a space character used as separator. The ultimate DOTS gateway SHOULD remove the diagnostic payload before forwarding the 5.06 (Hop Limit Reached) error message to a DOTS client domain. [Jon1] I have no issues if a server domain really wants to strip out its in= ternal hops - but troubleshooting is more of a challenge and would not reco= mmend it. [Jon1] However, when setting up a DOTS client, which is failing to work for= whatever reason, it would be good to have a reasonable level of diagnostic= s on the Client - separately invoking someone to look at a DOTS server's lo= gs may take time to get responded to - and you as a novice DOTS client user will have no ide= a as to what to tell the DOTS server guy to look for in the server's busy l= ogs. [Med] I hear that you are for: s/DOTS gateway SHOULD remove the diagnostic = payload before/DOTS gateway MAY remove the diagnostic payload before. Right= ? [Jon1] I would also like the structure of the diagnostic message to be well= formatted (e.g., no leading text, only one of server name / alias / IP add= ress, blank separator etc.) so it can easily be documented in user manuals = etc. as well as perhaps parsed by a receiver of the 5.06 message (interim h= op or final destination). All other responses (albeit in cbor) are pretty = well documented. [Med] Isn't this covered in the above text? The initial hop-limit value SHOULD be configurable. If no in= itial value is explicitly provided, the default initial hop-limit v= alue of 16 MUST be used. Because forwarding errors may occur if inadequate hop-limit v= alues are used, DOTS agents at the boundaries of an administrative domain MAY be instructed to rewrite the value of hop-limit ca= rried in received messages (that is, ignore the value of hop-limit received in a message). This is an optional option. [Jon] This should read "This is an optional CoAP Option". [Med] I can make the change. Please note that the text starts with "A DOTS = gateway may add the following CoAP option" which is clear enough this is ab= out an optional CoAP option. [Jon1] I guess I am being picky! ~jon1 Regards Jon --_000_787AE7BB302AE849A7480A190F8B93302DEF3579OPEXCLILMA3corp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Re-,

 

Please see inline.

 

Cheers,

Med

 

De : Jon Shallow [mailto:supjps-ietf= @jpshallow.com]
Envoy=E9 : mardi 27 mars 2018 14:35
=C0 : BOUCADAIR Mohamed IMT/OLN; dots@ietf.org
Objet : RE: [Dots] WGLC signal-18 Draft Hop Limit tidy up<= /o:p>

 

Hi Med,=

&n= bsp;

See inl= ine [Jon1]

&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: 27 March 2018 09:22
To: Jon Shallow; dots@ietf.org<= br> Subject: Re: [Dots] WGLC signal-18 Draft Hop Limit tidy up

 

Hi Jon,

 

Please see inline.

 

Cheers,

Med

 

De : Dots [mailto:dots-bounces@ietf.org] De la part de Jon Shallow
Envoy=E9 : vendredi 23 mars 2018 16:35
=C0 : dots@ietf.org
Objet : [Dots] WGLC signal-18 Draft Hop Limit tidy up

 

Hi there,

 

I believe that there are a coup= le of changes required for the hop-limit definition – see [Jon] inlin= e.

 

     &= nbsp;     hop-limit:  This option (see Section 9.4= ) is used to detect and

     &= nbsp;        prevent infinite loops.&nbs= p; This option is typically inserted by a

     &= nbsp;        DOTS gateway.

 

     &= nbsp;        The length of the hop-limit= option is 1 byte.

 

     &= nbsp;        The value of the hop-limit = option is encoded as an unsigned

     &= nbsp;        integer (see Section 3.2 of= [RFC7252]).

 

     &= nbsp;        Each intermediate DOTS agen= t involved in the handling of a DOTS

     &= nbsp;        message MUST decrement the = hop-limit option value by 1 prior to

     &= nbsp;        forwarding upstream if this= parameter exists.  DOTS messages MUST

     &= nbsp;        NOT be forwarded if the hop= -limit option is set to '0' after

     &= nbsp;        decrement.  Messages t= hat cannot be forwarded because of exhausted

     &= nbsp;        hop-limit SHOULD be logged = with a 5.06 (Hop Limit Reached) error

     &= nbsp;        message sent back to the DO= TS peer.  It is RECOMMENDED that DOTS

     &= nbsp;        clients and gateways suppor= t means to alert administrators about

     &= nbsp;        loop errors so that appropr= iate actions are undertaken.

[Jon] We need to add in somethi= ng like:-

Each intermediate DOTS agent SH= OULD add in the hop-limit option with the initial default value if it does = not exist before forwarding upstream any information.

 

[Med] I’m not sure to und= erstand this one. Please note that the text says “A DOTS gateway may = add the following CoAP option”. This is typically a GW which is instructed to insert the option will inject the option and follows the = setting of the initial value.

&n= bsp;

[Jon1] = I guess that I am trying to differentiate between updating an existing Hop-= Limit and not injecting a new one alongside a previous one.  Having mu= ltiple Hop-Limit options could get interesting!

[Med] OK, I get your point. Wha= t about adding :

NEW:

 Only one single instance = of the option is allowed in a message.

&n= bsp;

[Jon] We need to define the for= mat of the 5.06 CoAP diagnostic message so that it is potentially parseable= by the DOTS client as well as by any other potential RFC that make use of = this 5.06 code.  In addition, it would be good if each intermediate DOTS agent appended its own IP (prefixed by a= blank) to the end of the diagnostic message as the 5.06 response gets pass= ed back through the DOST agents to enable troubleshooting at the DOTS clien= t.  The diagnostic message length would need to be restricted to something like 1000 bytes to prevent UDP fr= agmentation.  Suggestions welcome here.

 

[Med] I can see a value in reco= rding the list of GWs involved in a loop for debugging purposes at the DOTS= server domain, but I’m not sure there is a value to pass that list to the DOTS client. For example, a server domain may wan= t to hide its internal topology (list of GWs and servers involved in handli= ng a mitigation request). Below a  text proposal for discussion:<= /o:p>

 

   &= nbsp;  To ease debugging and troubleshooting, the DOTS gateway which

   &= nbsp;  detects a loop SHOULD include its information (e.g., server nam= e,

   &= nbsp;  alias, IP address) in the diagnostic payload under the conditio= ns

   &= nbsp;  detailed in Section 5.5.2 of [RFC7252].  Each intermediate= DOTS

   &= nbsp;  gateway involved in relaying a 5.06 (Hop Limit Reached) error

   &= nbsp;  message SHOULD prepend its own information in the diagnostic

   &= nbsp;  payload with a space character used as separator.  The ult= imate

   &= nbsp;  DOTS gateway SHOULD remove the diagnostic payload before

   &= nbsp;  forwarding the 5.06 (Hop Limit Reached) error message to a DOTS=

   &= nbsp;  client domain.

[Jon1] = I have no issues if a server domain really wants to strip out its internal = hops – but troubleshooting is more of a challenge and would not recom= mend it.

[Jon1] = However, when setting up a DOTS client, which is failing to work for whatev= er reason, it would be good to have a reasonable level of diagnostics on th= e Client – separately invoking someone to look at a DOTS server’s logs may take time

to get = responded to – and you as a novice DOTS client user will have no idea= as to what to tell the DOTS server guy to look for in the server’s b= usy logs.

[Med] I hear that you are for: = s/DOTS gateway SHOULD remove the diagnostic payload before/DOTS gateway MAY remove the diagnosti= c payload before. Right?

 

[Jon1] = I would also like the structure of the diagnostic message to be well format= ted (e.g., no leading text, only one of server name / alias / IP address, b= lank separator etc.) so it can easily be documented in user manuals etc. as well as perhaps parsed by a receiver= of the 5.06 message (interim hop or final destination).  All other re= sponses (albeit in cbor) are pretty well documented.

[Med] Isn’t this covered = in the above text?

&nbs= p;

     &= nbsp;        The initial hop-limit value= SHOULD be configurable.  If no initial

     &= nbsp;        value is explicitly provide= d, the default initial hop-limit value

     &= nbsp;        of 16 MUST be used.

 

     &= nbsp;        Because forwarding errors m= ay occur if inadequate hop-limit values

     &= nbsp;        are used, DOTS agents at th= e boundaries of an administrative

     &= nbsp;        domain MAY be instructed to= rewrite the value of hop-limit carried

     &= nbsp;        in received messages (that = is, ignore the value of hop-limit

     &= nbsp;        received in a message).

 

     &= nbsp;        This is an optional option.=

[Jon] This should read “T= his is an optional CoAP Option”.

&nbs= p;

[Med] I can make the change. Pl= ease note that the text starts with “A DOTS gateway may add the follo= wing CoAP option” which is clear enough this is about an optional CoAP option.

&n= bsp;

[Jon1] = I guess I am being picky!

~jon1

Regards

 

Jon

--_000_787AE7BB302AE849A7480A190F8B93302DEF3579OPEXCLILMA3corp_-- From nobody Tue Mar 27 08:14: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 C2A2112D964 for ; Tue, 27 Mar 2018 08:14:15 -0700 (PDT) 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 UbqIpn9zwI9P for ; Tue, 27 Mar 2018 08:14:11 -0700 (PDT) Received: from mail.jpshallow.com (mail.jpshallow.com [217.40.240.153]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 23C151275AB for ; Tue, 27 Mar 2018 08:14:11 -0700 (PDT) Received: from [127.0.0.1] (helo=N01332) by mail.jpshallow.com with smtps (TLSv1:ECDHE-RSA-AES256-SHA:256) (Exim 4.90_1) (envelope-from ) id 1f0qIb-0000NA-GA; Tue, 27 Mar 2018 16:14:09 +0100 From: "Jon Shallow" To: , References: <05c801d3c2bc$88171290$984537b0$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93302DEF10B4@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <018701d3c5c8$044db950$0ce92bf0$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93302DEF3579@OPEXCLILMA3.corporate.adroot.infra.ftgroup> In-Reply-To: <787AE7BB302AE849A7480A190F8B93302DEF3579@OPEXCLILMA3.corporate.adroot.infra.ftgroup> Date: Tue, 27 Mar 2018 16:14:08 +0100 Message-ID: <01d001d3c5de$410e3ca0$c32ab5e0$@jpshallow.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_01D1_01D3C5E6.A2D4A070" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQLZExA96e11tdoJyqOqcaxu1U7VtQIUMridAPIe3SYBQh+XjaG3UWyw Content-Language: en-gb Archived-At: Subject: Re: [Dots] WGLC signal-18 Draft Hop Limit tidy up 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, 27 Mar 2018 15:14:16 -0000 This is a multipart message in MIME format. ------=_NextPart_000_01D1_01D3C5E6.A2D4A070 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Med, =20 See inline [Jon2] =20 Regards =20 Jon =20 =20 De : Dots [mailto:dots-bounces@ietf.org] De la part de Jon Shallow Envoy=E9 : vendredi 23 mars 2018 16:35 =C0 : dots@ietf.org Objet : [Dots] WGLC signal-18 Draft Hop Limit tidy up =20 Hi there, =20 I believe that there are a couple of changes required for the hop-limit definition =96 see [Jon] inline. =20 hop-limit: This option (see Section 9.4) is used to detect = and prevent infinite loops. This option is typically inserted = by a DOTS gateway. =20 The length of the hop-limit option is 1 byte. =20 The value of the hop-limit option is encoded as an = unsigned integer (see Section 3.2 of [RFC7252]). =20 Each intermediate DOTS agent involved in the handling of a DOTS message MUST decrement the hop-limit option value by 1 = prior to forwarding upstream if this parameter exists. DOTS = messages MUST NOT be forwarded if the hop-limit option 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. [Jon] We need to add in something like:- Each intermediate DOTS agent SHOULD add in the hop-limit option with the initial default value if it does not exist before forwarding upstream = any information. =20 [Med] I=92m not sure to understand this one. Please note that the text = says =93A DOTS gateway may add the following CoAP option=94. This is typically a = GW which is instructed to insert the option will inject the option and = follows the setting of the initial value. =20 [Jon1] I guess that I am trying to differentiate between updating an existing Hop-Limit and not injecting a new one alongside a previous one. Having multiple Hop-Limit options could get interesting! [Med] OK, I get your point. What about adding :=20 NEW: Only one single instance of the option is allowed in a message. [Jon2] Works for me =20 [Jon] We need to define the format of the 5.06 CoAP diagnostic message = so that it is potentially parseable by the DOTS client as well as by any = other potential RFC that make use of this 5.06 code. In addition, it would be good if each intermediate DOTS agent appended its own IP (prefixed by a blank) to the end of the diagnostic message as the 5.06 response gets = passed back through the DOST agents to enable troubleshooting at the DOTS = client. The diagnostic message length would need to be restricted to something = like 1000 bytes to prevent UDP fragmentation. Suggestions welcome here. =20 [Med] I can see a value in recording the list of GWs involved in a loop = for debugging purposes at the DOTS server domain, but I=92m not sure there = is a value to pass that list to the DOTS client. For example, a server domain = may want to hide its internal topology (list of GWs and servers involved in handling a mitigation request). Below a text proposal for discussion: =20 To ease debugging and troubleshooting, the DOTS gateway which detects a loop SHOULD include its information (e.g., server name, alias, IP address) in the diagnostic payload under the conditions detailed in Section 5.5.2 of [RFC7252]. Each intermediate DOTS gateway involved in relaying a 5.06 (Hop Limit Reached) error message SHOULD prepend its own information in the diagnostic payload with a space character used as separator. The ultimate DOTS gateway SHOULD remove the diagnostic payload before forwarding the 5.06 (Hop Limit Reached) error message to a DOTS client domain. [Jon1] I have no issues if a server domain really wants to strip out its internal hops =96 but troubleshooting is more of a challenge and would = not recommend it. [Jon1] However, when setting up a DOTS client, which is failing to work = for whatever reason, it would be good to have a reasonable level of = diagnostics on the Client =96 separately invoking someone to look at a DOTS = server=92s logs may take time=20 to get responded to =96 and you as a novice DOTS client user will have = no idea as to what to tell the DOTS server guy to look for in the server=92s = busy logs. [Med] I hear that you are for: s/DOTS gateway SHOULD remove the = diagnostic payload before/DOTS gateway MAY remove the diagnostic payload before. = Right? [Jon2] I feel a lot happier with MAY =20 [Jon1] I would also like the structure of the diagnostic message to be = well formatted (e.g., no leading text, only one of server name / alias / IP address, blank separator etc.) so it can easily be documented in user manuals etc. as well as perhaps parsed by a receiver of the 5.06 message (interim hop or final destination). All other responses (albeit in = cbor) are pretty well documented. [Med] Isn=92t this covered in the above text? [Jon2] Dyslexia rules =96 I read =91prepend=92 as =91append=92 - sorry. = Prepending will do what I am looking for in part. [Jon2] However, adding in more than one of server name / alias / IP = address per hop might be a bit confusing when you =93count=94 the hops. ~Jon2 =20 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. =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 option. [Jon] This should read =93This is an optional CoAP Option=94. =20 [Med] I can make the change. Please note that the text starts with =93A = DOTS gateway may add the following CoAP option=94 which is clear enough this = is about an optional CoAP option. =20 [Jon1] I guess I am being picky! ~jon1 Regards =20 Jon ------=_NextPart_000_01D1_01D3C5E6.A2D4A070 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Med,

 

See inline = [Jon2]

 

Regards

 

Jon

 

 

De : Dots [mailto:dots-bounces@ietf.org] = De la part de Jon Shallow
Envoy=E9 : vendredi 23 = mars 2018 16:35
=C0 : dots@ietf.org
Objet : = [Dots] WGLC signal-18 Draft Hop Limit tidy = up

 

Hi = there,

 

I believe that there are a couple of changes required = for the hop-limit definition – see [Jon] inline.

 

         &= nbsp; hop-limit:  This option (see Section 9.4) is used to detect = and

         &= nbsp;    prevent infinite loops.  This option is = typically inserted by a

         &= nbsp;    DOTS gateway.

 

         &= nbsp;    The length of the hop-limit option is 1 = byte.

 

         &= nbsp;    The value of the hop-limit option is encoded as = an unsigned

         &= nbsp;    integer (see Section 3.2 of = [RFC7252]).

 

         &= nbsp;    Each intermediate DOTS agent involved in the = handling of a DOTS

         &= nbsp;    message MUST decrement the hop-limit option = value by 1 prior to

         &= nbsp;    forwarding upstream if this parameter = exists.  DOTS messages MUST

         &= nbsp;    NOT be forwarded if the hop-limit option is set = to '0' after

         &= nbsp;    decrement.  Messages that cannot be = forwarded because of exhausted

         &= nbsp;    hop-limit SHOULD be logged with a 5.06 (Hop = Limit Reached) error

         &= nbsp;    message sent back to the DOTS peer.  It is = RECOMMENDED that DOTS

         &= nbsp;    clients and gateways support means to alert = administrators about

         &= nbsp;    loop errors so that appropriate actions are = undertaken.

[Jon] We need to add in = something like:-

Each intermediate = DOTS agent SHOULD add in the hop-limit option with the initial default = value if it does not exist before forwarding upstream any = information.

 

[Med] = I’m not sure to understand this one. Please note that the text = says “A DOTS gateway may add the following CoAP option”. = This is typically a GW which is instructed to insert the option will = inject the option and follows the setting of the initial = value.

 

[Jon1] I guess that I am = trying to differentiate between updating an existing Hop-Limit and not = injecting a new one alongside a previous one.  Having multiple = Hop-Limit options could get interesting!

[Med] OK, I get your point. What about adding : =

NEW:

 Only one single instance of the option is = allowed in a message.

[Jon2] Works for me

 

[Jon] We need to define the format of the 5.06 CoAP = diagnostic message so that it is potentially parseable by the DOTS = client as well as by any other potential RFC that make use of this 5.06 = code.  In addition, it would be good if each intermediate DOTS = agent appended its own IP (prefixed by a blank) to the end of the = diagnostic message as the 5.06 response gets passed back through the = DOST agents to enable troubleshooting at the DOTS client.  The = diagnostic message length would need to be restricted to something like = 1000 bytes to prevent UDP fragmentation.  Suggestions welcome = here.

 

[Med] I = can see a value in recording the list of GWs involved in a loop for = debugging purposes at the DOTS server domain, but I’m not sure = there is a value to pass that list to the DOTS client. For example, a = server domain may want to hide its internal topology (list of GWs and = servers involved in handling a mitigation request). Below a  text = proposal for discussion:

 

      To ease = debugging and troubleshooting, the DOTS gateway = which

      detects a = loop SHOULD include its information (e.g., server = name,

      alias, IP = address) in the diagnostic payload under the = conditions

      detailed in = Section 5.5.2 of [RFC7252].  Each intermediate = DOTS

      gateway = involved in relaying a 5.06 (Hop Limit Reached) = error

      message = SHOULD prepend its own information in the = diagnostic

      payload = with a space character used as separator.  The = ultimate

      DOTS = gateway SHOULD remove the diagnostic payload = before

      forwarding = the 5.06 (Hop Limit Reached) error message to a = DOTS

      = client domain.

[Jon1] I have no issues = if a server domain really wants to strip out its internal hops – = but troubleshooting is more of a challenge and would not recommend = it.

[Jon1] However, when setting up a DOTS client, = which is failing to work for whatever reason, it would be good to have a = reasonable level of diagnostics on the Client – separately = invoking someone to look at a DOTS server’s logs may take time =

to get responded to = – and you as a novice DOTS client user will have no idea as to = what to tell the DOTS server guy to look for in the server’s busy = logs.

[Med] I = hear that you are for: s/DOTS gateway SHOULD remove the diagnostic = payload before/DOTS gateway MAY remove the diagnostic payload before. = Right?

[Jon2] I feel a lot = happier with MAY

 

[Jon1] I would also like the structure of the = diagnostic message to be well formatted (e.g., no leading text, only one = of server name / alias / IP address, blank separator etc.) so it can = easily be documented in user manuals etc. as well as perhaps parsed by a = receiver of the 5.06 message (interim hop or final destination). =  All other responses (albeit in cbor) are pretty well = documented.

[Med] = Isn’t this covered in the above text?

[Jon2] Dyslexia rules – I read = ‘prepend’ as ‘append’ - sorry.=A0 Prepending = will do what I am looking for in part.

[Jon2] However, adding = in more than one of =A0server name = / alias / IP address per hop might be a bit confusing when you = “count” the hops.

~Jon2

=

 

         &= nbsp;    The initial hop-limit value SHOULD be = configurable.  If no initial

         &= nbsp;    value is explicitly provided, the default = initial hop-limit value

         &= nbsp;    of 16 MUST be used.

 

         &= nbsp;    Because forwarding errors may occur if = inadequate hop-limit values

         &= nbsp;    are used, DOTS agents at the boundaries of an = administrative

          =     domain MAY be instructed to rewrite the value of = hop-limit carried

         &= nbsp;    in received messages (that is, ignore the value = of hop-limit

         &= nbsp;    received in a message).

 

         &= nbsp;    This is an optional option.

[Jon] This should read “This is an optional CoAP = Option”.

 

[Med] I can make the change. Please note that the text = starts with “A DOTS gateway may add the following = CoAP option” = which is clear enough this is about an optional CoAP = option.

 

[Jon1] I guess I am = being picky!

~jon1

Regards

 

Jon

------=_NextPart_000_01D1_01D3C5E6.A2D4A070-- From nobody Wed Mar 28 02:09: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 ACA3C124C27 for ; Wed, 28 Mar 2018 02:09:47 -0700 (PDT) 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 Kv4YfRW_yoyn for ; Wed, 28 Mar 2018 02:09:46 -0700 (PDT) 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 AF2021200C1 for ; Wed, 28 Mar 2018 02:09:45 -0700 (PDT) Received: from opfednr07.francetelecom.fr (unknown [xx.xx.xx.71]) by opfednr27.francetelecom.fr (ESMTP service) with ESMTP id E46DDA09D2; Wed, 28 Mar 2018 11:09:43 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.21]) by opfednr07.francetelecom.fr (ESMTP service) with ESMTP id CA1B81C0080; Wed, 28 Mar 2018 11:09:43 +0200 (CEST) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM6C.corporate.adroot.infra.ftgroup ([fe80::d9f5:9741:7525:a199%18]) with mapi id 14.03.0382.000; Wed, 28 Mar 2018 11:09:43 +0200 From: To: Jon Shallow , "dots@ietf.org" Thread-Topic: [Dots] WGLC signal-18 Draft Hop Limit tidy up Thread-Index: AQLZExA96e11tdoJyqOqcaxu1U7VtQIUMridAPIe3SYBQh+XjaG3UWywgAEpF5A= Date: Wed, 28 Mar 2018 09:09:43 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93302DEF3B49@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <05c801d3c2bc$88171290$984537b0$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93302DEF10B4@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <018701d3c5c8$044db950$0ce92bf0$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93302DEF3579@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <01d001d3c5de$410e3ca0$c32ab5e0$@jpshallow.com> In-Reply-To: <01d001d3c5de$410e3ca0$c32ab5e0$@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_787AE7BB302AE849A7480A190F8B93302DEF3B49OPEXCLILMA3corp_" MIME-Version: 1.0 Archived-At: Subject: Re: [Dots] WGLC signal-18 Draft Hop Limit tidy up 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, 28 Mar 2018 09:09:47 -0000 --_000_787AE7BB302AE849A7480A190F8B93302DEF3B49OPEXCLILMA3corp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Jon, Please see inline. Cheers, Med De : Jon Shallow [mailto:supjps-ietf@jpshallow.com] Envoy=E9 : mardi 27 mars 2018 17:14 =C0 : BOUCADAIR Mohamed IMT/OLN; dots@ietf.org Objet : RE: [Dots] WGLC signal-18 Draft Hop Limit tidy up Hi Med, See inline [Jon2] Regards Jon De : Dots [mailto:dots-bounces@ietf.org] De la part de Jon Shallow Envoy=E9 : vendredi 23 mars 2018 16:35 =C0 : dots@ietf.org Objet : [Dots] WGLC signal-18 Draft Hop Limit tidy up Hi there, I believe that there are a couple of changes required for the hop-limit def= inition - see [Jon] inline. hop-limit: This option (see Section 9.4) is used to detect and prevent infinite loops. This option is typically inserted by= a DOTS gateway. The length of the hop-limit option is 1 byte. The value of the hop-limit option is encoded as an unsigned integer (see Section 3.2 of [RFC7252]). Each intermediate DOTS agent involved in the handling of a DO= TS message MUST decrement the hop-limit option value by 1 prior = to forwarding upstream if this parameter exists. DOTS messages = MUST NOT be forwarded if the hop-limit option is set to '0' after decrement. Messages that cannot be forwarded because of exha= usted hop-limit SHOULD be logged with a 5.06 (Hop Limit Reached) er= ror message sent back to the DOTS peer. It is RECOMMENDED that D= OTS clients and gateways support means to alert administrators ab= out loop errors so that appropriate actions are undertaken. [Jon] We need to add in something like:- Each intermediate DOTS agent SHOULD add in the hop-limit option with the in= itial default value if it does not exist before forwarding upstream any inf= ormation. [Med] I'm not sure to understand this one. Please note that the text says "= A DOTS gateway may add the following CoAP option". This is typically a GW w= hich is instructed to insert the option will inject the option and follows = the setting of the initial value. [Jon1] I guess that I am trying to differentiate between updating an existi= ng Hop-Limit and not injecting a new one alongside a previous one. Having = multiple Hop-Limit options could get interesting! [Med] OK, I get your point. What about adding : NEW: Only one single instance of the option is allowed in a message. [Jon2] Works for me [Med] OK, thanks. [Jon] We need to define the format of the 5.06 CoAP diagnostic message so t= hat it is potentially parseable by the DOTS client as well as by any other = potential RFC that make use of this 5.06 code. In addition, it would be go= od if each intermediate DOTS agent appended its own IP (prefixed by a blank= ) to the end of the diagnostic message as the 5.06 response gets passed bac= k through the DOST agents to enable troubleshooting at the DOTS client. Th= e diagnostic message length would need to be restricted to something like 1= 000 bytes to prevent UDP fragmentation. Suggestions welcome here. [Med] I can see a value in recording the list of GWs involved in a loop for= debugging purposes at the DOTS server domain, but I'm not sure there is a = value to pass that list to the DOTS client. For example, a server domain ma= y want to hide its internal topology (list of GWs and servers involved in h= andling a mitigation request). Below a text proposal for discussion: To ease debugging and troubleshooting, the DOTS gateway which detects a loop SHOULD include its information (e.g., server name, alias, IP address) in the diagnostic payload under the conditions detailed in Section 5.5.2 of [RFC7252]. Each intermediate DOTS gateway involved in relaying a 5.06 (Hop Limit Reached) error message SHOULD prepend its own information in the diagnostic payload with a space character used as separator. The ultimate DOTS gateway SHOULD remove the diagnostic payload before forwarding the 5.06 (Hop Limit Reached) error message to a DOTS client domain. [Jon1] I have no issues if a server domain really wants to strip out its in= ternal hops - but troubleshooting is more of a challenge and would not reco= mmend it. [Jon1] However, when setting up a DOTS client, which is failing to work for= whatever reason, it would be good to have a reasonable level of diagnostic= s on the Client - separately invoking someone to look at a DOTS server's lo= gs may take time to get responded to - and you as a novice DOTS client user will have no ide= a as to what to tell the DOTS server guy to look for in the server's busy l= ogs. [Med] I hear that you are for: s/DOTS gateway SHOULD remove the diagnostic = payload before/DOTS gateway MAY remove the diagnostic payload before. Right= ? [Jon2] I feel a lot happier with MAY [Med] OK. [Jon1] I would also like the structure of the diagnostic message to be well= formatted (e.g., no leading text, only one of server name / alias / IP add= ress, blank separator etc.) so it can easily be documented in user manuals = etc. as well as perhaps parsed by a receiver of the 5.06 message (interim h= op or final destination). All other responses (albeit in cbor) are pretty = well documented. [Med] Isn't this covered in the above text? [Jon2] Dyslexia rules - I read 'prepend' as 'append' - sorry. Prepending w= ill do what I am looking for in part. [Med] Great! [Jon2] However, adding in more than one of server name / alias / IP addres= s per hop might be a bit confusing when you "count" the hops. [Med] This is exactly why the provided examples are not plural "(e.g., serv= er name, alias, IP address)". I agree that we can use a more strict languag= e. I can add this NEW sentence: "Only one information per DOTS gateway MUST appear in the diagnostic payloa= d." ~Jon2 The initial hop-limit value SHOULD be configurable. If no in= itial value is explicitly provided, the default initial hop-limit v= alue of 16 MUST be used. Because forwarding errors may occur if inadequate hop-limit v= alues are used, DOTS agents at the boundaries of an administrative domain MAY be instructed to rewrite the value of hop-limit ca= rried in received messages (that is, ignore the value of hop-limit received in a message). This is an optional option. [Jon] This should read "This is an optional CoAP Option". [Med] I can make the change. Please note that the text starts with "A DOTS = gateway may add the following CoAP option" which is clear enough this is ab= out an optional CoAP option. [Jon1] I guess I am being picky! ~jon1 Regards Jon --_000_787AE7BB302AE849A7480A190F8B93302DEF3B49OPEXCLILMA3corp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Jon,

 

Please see inline.

 

Cheers,

Med

 

De : Jon Shallow [mailto:supjps-ietf= @jpshallow.com]
Envoy=E9 : mardi 27 mars 2018 17:14
=C0 : BOUCADAIR Mohamed IMT/OLN; dots@ietf.org
Objet : RE: [Dots] WGLC signal-18 Draft Hop Limit tidy up<= /o:p>

 

Hi Med,=

&n= bsp;

See inl= ine [Jon2]

&n= bsp;

Regards=

&n= bsp;

Jon

&n= bsp;

 

De : Dots [mailto:dots-bounces@ietf.org] De la part de Jon Shallow
Envoy=E9 : vendredi 23 mars 2018 16:35
=C0 : dots@ietf.org
Objet : [Dots] WGLC signal-18 Draft Hop Limit tidy up

 

Hi there,

 

I believe that there are a coup= le of changes required for the hop-limit definition – see [Jon] inlin= e.

 

     &= nbsp;     hop-limit:  This option (see Section 9.4= ) is used to detect and

     &= nbsp;        prevent infinite loops.&nbs= p; This option is typically inserted by a

     &= nbsp;        DOTS gateway.

 

     &= nbsp;        The length of the hop-limit= option is 1 byte.

 

     &= nbsp;        The value of the hop-limit = option is encoded as an unsigned

     &= nbsp;        integer (see Section 3.2 of= [RFC7252]).

 

     &= nbsp;        Each intermediate DOTS agen= t involved in the handling of a DOTS

     &= nbsp;        message MUST decrement the = hop-limit option value by 1 prior to

     &= nbsp;        forwarding upstream if this= parameter exists.  DOTS messages MUST

     &= nbsp;        NOT be forwarded if the hop= -limit option is set to '0' after

     &= nbsp;        decrement.  Messages t= hat cannot be forwarded because of exhausted

     &= nbsp;        hop-limit SHOULD be logged = with a 5.06 (Hop Limit Reached) error

     &= nbsp;        message sent back to the DO= TS peer.  It is RECOMMENDED that DOTS

     &= nbsp;        clients and gateways suppor= t means to alert administrators about

     &= nbsp;        loop errors so that appropr= iate actions are undertaken.

[Jon] We need to add in somethi= ng like:-

Each intermediate DOTS agent SH= OULD add in the hop-limit option with the initial default value if it does = not exist before forwarding upstream any information.

 

[Med] I’m not sure to und= erstand this one. Please note that the text says “A DOTS gateway may = add the following CoAP option”. This is typically a GW which is instructed to insert the option will inject the option and follows the = setting of the initial value.

&n= bsp;

[Jon1] = I guess that I am trying to differentiate between updating an existing Hop-= Limit and not injecting a new one alongside a previous one.  Having mu= ltiple Hop-Limit options could get interesting!

[Med] OK, I get your point. Wha= t about adding :

NEW:

 Only one single instance = of the option is allowed in a message.

[Jon2] = Works for me

[Med] OK, thanks.

&n= bsp;

[Jon] We need to define the for= mat of the 5.06 CoAP diagnostic message so that it is potentially parseable= by the DOTS client as well as by any other potential RFC that make use of = this 5.06 code.  In addition, it would be good if each intermediate DOTS agent appended its own IP (prefixed by a= blank) to the end of the diagnostic message as the 5.06 response gets pass= ed back through the DOST agents to enable troubleshooting at the DOTS clien= t.  The diagnostic message length would need to be restricted to something like 1000 bytes to prevent UDP fr= agmentation.  Suggestions welcome here.

 

[Med] I can see a value in reco= rding the list of GWs involved in a loop for debugging purposes at the DOTS= server domain, but I’m not sure there is a value to pass that list to the DOTS client. For example, a server domain may wan= t to hide its internal topology (list of GWs and servers involved in handli= ng a mitigation request). Below a  text proposal for discussion:<= /o:p>

 

   &= nbsp;  To ease debugging and troubleshooting, the DOTS gateway which

   &= nbsp;  detects a loop SHOULD include its information (e.g., server nam= e,

   &= nbsp;  alias, IP address) in the diagnostic payload under the conditio= ns

   &= nbsp;  detailed in Section 5.5.2 of [RFC7252].  Each intermediate= DOTS

   &= nbsp;  gateway involved in relaying a 5.06 (Hop Limit Reached) error

   &= nbsp;  message SHOULD prepend its own information in the diagnostic

   &= nbsp;  payload with a space character used as separator.  The ult= imate

   &= nbsp;  DOTS gateway SHOULD remove the diagnostic payload before

   &= nbsp;  forwarding the 5.06 (Hop Limit Reached) error message to a DOTS=

   &= nbsp;  client domain.

[Jon1] = I have no issues if a server domain really wants to strip out its internal = hops – but troubleshooting is more of a challenge and would not recom= mend it.

[Jon1] = However, when setting up a DOTS client, which is failing to work for whatev= er reason, it would be good to have a reasonable level of diagnostics on th= e Client – separately invoking someone to look at a DOTS server’s logs may take time

to get = responded to – and you as a novice DOTS client user will have no idea= as to what to tell the DOTS server guy to look for in the server’s b= usy logs.

[Med] I hear that you are for: = s/DOTS gateway SHOULD remove the diagnostic payload before/DOTS gateway MAY remove the diagnosti= c payload before. Right?

[Jon2] = I feel a lot happier with MAY

[Med] OK.

 

[Jon1] = I would also like the structure of the diagnostic message to be well format= ted (e.g., no leading text, only one of server name / alias / IP address, b= lank separator etc.) so it can easily be documented in user manuals etc. as well as perhaps parsed by a receiver= of the 5.06 message (interim hop or final destination).  All other re= sponses (albeit in cbor) are pretty well documented.

[Med] Isn’t this covered = in the above text?

[Jon2] = Dyslexia rules – I read ‘prepend’ as ‘append’= - sorry.  Prepending will do what I am looking for in part.

[Med] Great!

[Jon2] = However, adding in more than one of  server name / alias / IP address = per hop might be a bit confusing when you “count” the hops.

[Med] This is exactly why the p= rovided examples are not plural “(e.g., server name, alias, IP address)”. I agree that we can use a more strict language. I can add this NEW sentence:  

“Only one information per= DOTS gateway MUST appear in the diagnostic payload.”

 

~Jon2

 

&nbs= p;

     &= nbsp;        The initial hop-limit value= SHOULD be configurable.  If no initial

     &= nbsp;        value is explicitly provide= d, the default initial hop-limit value

     &= nbsp;        of 16 MUST be used.

 

     &= nbsp;        Because forwarding errors m= ay occur if inadequate hop-limit values

     &= nbsp;        are used, DOTS agents at th= e boundaries of an administrative

     &= nbsp;        domain MAY be instructed to= rewrite the value of hop-limit carried

     &= nbsp;        in received messages (that = is, ignore the value of hop-limit

     &= nbsp;        received in a message).

 

     &= nbsp;        This is an optional option.=

[Jon] This should read “T= his is an optional CoAP Option”.

&nbs= p;

[Med] I can make the change. Pl= ease note that the text starts with “A DOTS gateway may add the follo= wing CoAP option” which is clear enough this is about an optional CoAP option.

&n= bsp;

[Jon1] = I guess I am being picky!

~jon1

Regards

 

Jon

--_000_787AE7BB302AE849A7480A190F8B93302DEF3B49OPEXCLILMA3corp_-- From nobody Wed Mar 28 02:37: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 410AB126D73 for ; Wed, 28 Mar 2018 02:37:48 -0700 (PDT) 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 Ykx9ffgifOlq for ; Wed, 28 Mar 2018 02:37:46 -0700 (PDT) Received: from mail.jpshallow.com (mail.jpshallow.com [217.40.240.153]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C2093126BF6 for ; Wed, 28 Mar 2018 02:37:45 -0700 (PDT) Received: from [127.0.0.1] (helo=N01332) by mail.jpshallow.com with smtps (TLSv1:ECDHE-RSA-AES256-SHA:256) (Exim 4.90_1) (envelope-from ) id 1f17WZ-0000yo-3w; Wed, 28 Mar 2018 10:37:43 +0100 From: "Jon Shallow" To: , References: <05c801d3c2bc$88171290$984537b0$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93302DEF10B4@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <018701d3c5c8$044db950$0ce92bf0$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93302DEF3579@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <01d001d3c5de$410e3ca0$c32ab5e0$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93302DEF3B49@OPEXCLILMA3.corporate.adroot.infra.ftgroup> In-Reply-To: <787AE7BB302AE849A7480A190F8B93302DEF3B49@OPEXCLILMA3.corporate.adroot.infra.ftgroup> Date: Wed, 28 Mar 2018 10:37:42 +0100 Message-ID: <026a01d3c678$6bb62270$43226750$@jpshallow.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_026B_01D3C680.CD7C8640" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQLZExA96e11tdoJyqOqcaxu1U7VtQIUMridAPIe3SYBQh+XjQFy2griAn3xOeShmPrOAA== Content-Language: en-gb Archived-At: Subject: Re: [Dots] WGLC signal-18 Draft Hop Limit tidy up 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, 28 Mar 2018 09:37:48 -0000 This is a multipart message in MIME format. ------=_NextPart_000_026B_01D3C680.CD7C8640 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Med, =20 See inline [Jon3] =20 Regards =20 Jon =20 =20 =20 =20 De : Dots [mailto:dots-bounces@ietf.org] De la part de Jon Shallow Envoy=E9 : vendredi 23 mars 2018 16:35 =C0 : dots@ietf.org Objet : [Dots] WGLC signal-18 Draft Hop Limit tidy up =20 Hi there, =20 I believe that there are a couple of changes required for the hop-limit definition =96 see [Jon] inline. =20 hop-limit: This option (see Section 9.4) is used to detect = and prevent infinite loops. This option is typically inserted = by a DOTS gateway. =20 The length of the hop-limit option is 1 byte. =20 The value of the hop-limit option is encoded as an = unsigned integer (see Section 3.2 of [RFC7252]). =20 Each intermediate DOTS agent involved in the handling of a DOTS message MUST decrement the hop-limit option value by 1 = prior to forwarding upstream if this parameter exists. DOTS = messages MUST NOT be forwarded if the hop-limit option 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. [Jon] We need to add in something like:- Each intermediate DOTS agent SHOULD add in the hop-limit option with the initial default value if it does not exist before forwarding upstream = any information. =20 [Med] I=92m not sure to understand this one. Please note that the text = says =93A DOTS gateway may add the following CoAP option=94. This is typically a = GW which is instructed to insert the option will inject the option and = follows the setting of the initial value. =20 [Jon1] I guess that I am trying to differentiate between updating an existing Hop-Limit and not injecting a new one alongside a previous one. Having multiple Hop-Limit options could get interesting! [Med] OK, I get your point. What about adding :=20 NEW: Only one single instance of the option is allowed in a message. [Jon2] Works for me [Med] OK, thanks. =20 [Jon] We need to define the format of the 5.06 CoAP diagnostic message = so that it is potentially parseable by the DOTS client as well as by any = other potential RFC that make use of this 5.06 code. In addition, it would be good if each intermediate DOTS agent appended its own IP (prefixed by a blank) to the end of the diagnostic message as the 5.06 response gets = passed back through the DOST agents to enable troubleshooting at the DOTS = client. The diagnostic message length would need to be restricted to something = like 1000 bytes to prevent UDP fragmentation. Suggestions welcome here. =20 [Med] I can see a value in recording the list of GWs involved in a loop = for debugging purposes at the DOTS server domain, but I=92m not sure there = is a value to pass that list to the DOTS client. For example, a server domain = may want to hide its internal topology (list of GWs and servers involved in handling a mitigation request). Below a text proposal for discussion: =20 To ease debugging and troubleshooting, the DOTS gateway which detects a loop SHOULD include its information (e.g., server name, alias, IP address) in the diagnostic payload under the conditions detailed in Section 5.5.2 of [RFC7252]. Each intermediate DOTS gateway involved in relaying a 5.06 (Hop Limit Reached) error message SHOULD prepend its own information in the diagnostic payload with a space character used as separator. The ultimate DOTS gateway SHOULD remove the diagnostic payload before forwarding the 5.06 (Hop Limit Reached) error message to a DOTS client domain. [Jon1] I have no issues if a server domain really wants to strip out its internal hops =96 but troubleshooting is more of a challenge and would = not recommend it. [Jon1] However, when setting up a DOTS client, which is failing to work = for whatever reason, it would be good to have a reasonable level of = diagnostics on the Client =96 separately invoking someone to look at a DOTS = server=92s logs may take time=20 to get responded to =96 and you as a novice DOTS client user will have = no idea as to what to tell the DOTS server guy to look for in the server=92s = busy logs. [Med] I hear that you are for: s/DOTS gateway SHOULD remove the = diagnostic payload before/DOTS gateway MAY remove the diagnostic payload before. = Right? [Jon2] I feel a lot happier with MAY [Med] OK. =20 [Jon1] I would also like the structure of the diagnostic message to be = well formatted (e.g., no leading text, only one of server name / alias / IP address, blank separator etc.) so it can easily be documented in user manuals etc. as well as perhaps parsed by a receiver of the 5.06 message (interim hop or final destination). All other responses (albeit in = cbor) are pretty well documented. [Med] Isn=92t this covered in the above text? [Jon2] Dyslexia rules =96 I read =91prepend=92 as =91append=92 - sorry. = Prepending will do what I am looking for in part. [Med] Great!=20 [Jon2] However, adding in more than one of server name / alias / IP = address per hop might be a bit confusing when you =93count=94 the hops. [Med] This is exactly why the provided examples are not plural =93(e.g., server name, alias, IP address)=94. I agree that we can use a more = strict language. I can add this NEW sentence: =20 =93Only one information per DOTS gateway MUST appear in the diagnostic payload.=94 [Jon3] Yes please. ~jon3 ~Jon2 =20 =20 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. =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 option. [Jon] This should read =93This is an optional CoAP Option=94. =20 [Med] I can make the change. Please note that the text starts with =93A = DOTS gateway may add the following CoAP option=94 which is clear enough this = is about an optional CoAP option. =20 [Jon1] I guess I am being picky! ~jon1 Regards =20 Jon ------=_NextPart_000_026B_01D3C680.CD7C8640 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Med,

 

See inline = [Jon3]

 

Regards

 

Jon

 

 

 

 

De : Dots [mailto:dots-bounces@ietf.org] = De la part de Jon Shallow
Envoy=E9 : vendredi 23 = mars 2018 16:35
=C0 : dots@ietf.org
Objet : = [Dots] WGLC signal-18 Draft Hop Limit tidy = up

 

Hi = there,

 

I believe that there are a couple of changes required = for the hop-limit definition – see [Jon] inline.

 

         &= nbsp; hop-limit:  This option (see Section 9.4) is used to detect = and

         &= nbsp;    prevent infinite loops.  This option is = typically inserted by a

         &= nbsp;    DOTS gateway.

 

         &= nbsp;    The length of the hop-limit option is 1 = byte.

 

         &= nbsp;    The value of the hop-limit option is encoded as = an unsigned

         &= nbsp;    integer (see Section 3.2 of = [RFC7252]).

 

         &= nbsp;    Each intermediate DOTS agent involved in the = handling of a DOTS

         &= nbsp;    message MUST decrement the hop-limit option = value by 1 prior to

         &= nbsp;    forwarding upstream if this parameter = exists.  DOTS messages MUST

         &= nbsp;    NOT be forwarded if the hop-limit option is set = to '0' after

         &= nbsp;    decrement.  Messages that cannot be = forwarded because of exhausted

         &= nbsp;    hop-limit SHOULD be logged with a 5.06 (Hop = Limit Reached) error

         &= nbsp;    message sent back to the DOTS peer.  It is = RECOMMENDED that DOTS

         &= nbsp;    clients and gateways support means to alert = administrators about

         &= nbsp;    loop errors so that appropriate actions are = undertaken.

[Jon] We need to add in = something like:-

Each intermediate = DOTS agent SHOULD add in the hop-limit option with the initial default = value if it does not exist before forwarding upstream any = information.

 

[Med] = I’m not sure to understand this one. Please note that the text = says “A DOTS gateway may add the following CoAP option”. = This is typically a GW which is instructed to insert the option will = inject the option and follows the setting of the initial = value.

 

[Jon1] I guess that I am = trying to differentiate between updating an existing Hop-Limit and not = injecting a new one alongside a previous one.  Having multiple = Hop-Limit options could get interesting!

[Med] OK, I get your point. What about adding : =

NEW:

 Only one single instance of the option is = allowed in a message.

[Jon2] Works for me

[Med] OK, thanks.

 

[Jon] We need to define the format of the 5.06 CoAP = diagnostic message so that it is potentially parseable by the DOTS = client as well as by any other potential RFC that make use of this 5.06 = code.  In addition, it would be good if each intermediate DOTS = agent appended its own IP (prefixed by a blank) to the end of the = diagnostic message as the 5.06 response gets passed back through the = DOST agents to enable troubleshooting at the DOTS client.  The = diagnostic message length would need to be restricted to something like = 1000 bytes to prevent UDP fragmentation.  Suggestions welcome = here.

 

[Med] I = can see a value in recording the list of GWs involved in a loop for = debugging purposes at the DOTS server domain, but I’m not sure = there is a value to pass that list to the DOTS client. For example, a = server domain may want to hide its internal topology (list of GWs and = servers involved in handling a mitigation request). Below a  text = proposal for discussion:

 

      To ease = debugging and troubleshooting, the DOTS gateway = which

      detects a = loop SHOULD include its information (e.g., server = name,

      alias, IP = address) in the diagnostic payload under the = conditions

      detailed in = Section 5.5.2 of [RFC7252].  Each intermediate = DOTS

      gateway = involved in relaying a 5.06 (Hop Limit Reached) = error

      message = SHOULD prepend its own information in the = diagnostic

      payload = with a space character used as separator.  The = ultimate

      DOTS = gateway SHOULD remove the diagnostic payload = before

      forwarding = the 5.06 (Hop Limit Reached) error message to a = DOTS

      = client domain.

[Jon1] I have no issues = if a server domain really wants to strip out its internal hops – = but troubleshooting is more of a challenge and would not recommend = it.

[Jon1] However, when setting up a DOTS client, = which is failing to work for whatever reason, it would be good to have a = reasonable level of diagnostics on the Client – separately = invoking someone to look at a DOTS server’s logs may take time =

to get responded to = – and you as a novice DOTS client user will have no idea as to = what to tell the DOTS server guy to look for in the server’s busy = logs.

[Med] I = hear that you are for: s/DOTS gateway SHOULD remove the diagnostic = payload before/DOTS gateway MAY remove the diagnostic payload before. = Right?

[Jon2] I feel a lot = happier with MAY

[Med] = OK.

 

[Jon1] I would also like the structure of the = diagnostic message to be well formatted (e.g., no leading text, only one = of server name / alias / IP address, blank separator etc.) so it can = easily be documented in user manuals etc. as well as perhaps parsed by a = receiver of the 5.06 message (interim hop or final destination). =  All other responses (albeit in cbor) are pretty well = documented.

[Med] = Isn’t this covered in the above text?

[Jon2] Dyslexia rules – I read = ‘prepend’ as ‘append’ - sorry.  Prepending = will do what I am looking for in part.

[Med] Great!

[Jon2] However, adding = in more than one of  server name / alias / IP address per hop might = be a bit confusing when you “count” the = hops.

[Med] = This is exactly why the provided examples are not plural “(e.g., = server name, alias, IP address)”. I agree that we can use a more strict = language. I can add this NEW sentence:  

“Only one information per DOTS gateway MUST = appear in the diagnostic payload.”

[Jon3] Yes please.

~jon3

~Jon2

 

 

         &= nbsp;    The initial hop-limit value SHOULD be = configurable.  If no initial

         &= nbsp;    value is explicitly provided, the default = initial hop-limit value

         &= nbsp;    of 16 MUST be used.

 

         &= nbsp;    Because forwarding errors may occur if = inadequate hop-limit values

         &= nbsp;    are used, DOTS agents at the boundaries of an = administrative

          =     domain MAY be instructed to rewrite the value of = hop-limit carried

         &= nbsp;    in received messages (that is, ignore the value = of hop-limit

         &= nbsp;    received in a message).

 

         &= nbsp;    This is an optional option.

[Jon] This should read “This is an optional CoAP = Option”.

 

[Med] I can make the change. Please note that the text = starts with “A DOTS gateway may add the following = CoAP option” = which is clear enough this is about an optional CoAP = option.

 

[Jon1] I guess I am = being picky!

~jon1

Regards

 

Jon

------=_NextPart_000_026B_01D3C680.CD7C8640-- From nobody Wed Mar 28 04:58:10 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 17AE8126E01 for ; Wed, 28 Mar 2018 04:58:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.609 X-Spam-Level: X-Spam-Status: No, score=-2.609 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 H0V7xvLdMR9D for ; Wed, 28 Mar 2018 04:58:07 -0700 (PDT) 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 7B4251267BB for ; Wed, 28 Mar 2018 04:58:06 -0700 (PDT) Received: from opfedar07.francetelecom.fr (unknown [xx.xx.xx.9]) by opfedar25.francetelecom.fr (ESMTP service) with ESMTP id 9F9991209CB; Wed, 28 Mar 2018 13:58:04 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.27]) by opfedar07.francetelecom.fr (ESMTP service) with ESMTP id 7D8E0C005C; Wed, 28 Mar 2018 13:58:04 +0200 (CEST) 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.0382.000; Wed, 28 Mar 2018 13:58:04 +0200 From: To: Jon Shallow , "dots@ietf.org" Thread-Topic: [Dots] WGLC signal-18 Draft Hop Limit tidy up Thread-Index: AQLZExA96e11tdoJyqOqcaxu1U7VtQIUMridAPIe3SYBQh+XjQFy2griAn3xOeShmPrOAIAAK34g Date: Wed, 28 Mar 2018 11:58:04 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93302DEF3CE9@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <05c801d3c2bc$88171290$984537b0$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93302DEF10B4@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <018701d3c5c8$044db950$0ce92bf0$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93302DEF3579@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <01d001d3c5de$410e3ca0$c32ab5e0$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93302DEF3B49@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <026a01d3c678$6bb62270$43226750$@jpshallow.com> In-Reply-To: <026a01d3c678$6bb62270$43226750$@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_787AE7BB302AE849A7480A190F8B93302DEF3CE9OPEXCLILMA3corp_" MIME-Version: 1.0 Archived-At: Subject: Re: [Dots] WGLC signal-18 Draft Hop Limit tidy up 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, 28 Mar 2018 11:58:09 -0000 --_000_787AE7BB302AE849A7480A190F8B93302DEF3CE9OPEXCLILMA3corp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re-, I confirm that I implemented the changes we agreed in my local copy. You may double check at: https://github.com/boucadair/draft-ietf-dots-signa= l-channel Cheers, Med De : Jon Shallow [mailto:supjps-ietf@jpshallow.com] Envoy=E9 : mercredi 28 mars 2018 11:38 =C0 : BOUCADAIR Mohamed IMT/OLN; dots@ietf.org Objet : RE: [Dots] WGLC signal-18 Draft Hop Limit tidy up Hi Med, See inline [Jon3] Regards Jon De : Dots [mailto:dots-bounces@ietf.org] De la part de Jon Shallow Envoy=E9 : vendredi 23 mars 2018 16:35 =C0 : dots@ietf.org Objet : [Dots] WGLC signal-18 Draft Hop Limit tidy up Hi there, I believe that there are a couple of changes required for the hop-limit def= inition - see [Jon] inline. hop-limit: This option (see Section 9.4) is used to detect and prevent infinite loops. This option is typically inserted by= a DOTS gateway. The length of the hop-limit option is 1 byte. The value of the hop-limit option is encoded as an unsigned integer (see Section 3.2 of [RFC7252]). Each intermediate DOTS agent involved in the handling of a DO= TS message MUST decrement the hop-limit option value by 1 prior = to forwarding upstream if this parameter exists. DOTS messages = MUST NOT be forwarded if the hop-limit option is set to '0' after decrement. Messages that cannot be forwarded because of exha= usted hop-limit SHOULD be logged with a 5.06 (Hop Limit Reached) er= ror message sent back to the DOTS peer. It is RECOMMENDED that D= OTS clients and gateways support means to alert administrators ab= out loop errors so that appropriate actions are undertaken. [Jon] We need to add in something like:- Each intermediate DOTS agent SHOULD add in the hop-limit option with the in= itial default value if it does not exist before forwarding upstream any inf= ormation. [Med] I'm not sure to understand this one. Please note that the text says "= A DOTS gateway may add the following CoAP option". This is typically a GW w= hich is instructed to insert the option will inject the option and follows = the setting of the initial value. [Jon1] I guess that I am trying to differentiate between updating an existi= ng Hop-Limit and not injecting a new one alongside a previous one. Having = multiple Hop-Limit options could get interesting! [Med] OK, I get your point. What about adding : NEW: Only one single instance of the option is allowed in a message. [Jon2] Works for me [Med] OK, thanks. [Jon] We need to define the format of the 5.06 CoAP diagnostic message so t= hat it is potentially parseable by the DOTS client as well as by any other = potential RFC that make use of this 5.06 code. In addition, it would be go= od if each intermediate DOTS agent appended its own IP (prefixed by a blank= ) to the end of the diagnostic message as the 5.06 response gets passed bac= k through the DOST agents to enable troubleshooting at the DOTS client. Th= e diagnostic message length would need to be restricted to something like 1= 000 bytes to prevent UDP fragmentation. Suggestions welcome here. [Med] I can see a value in recording the list of GWs involved in a loop for= debugging purposes at the DOTS server domain, but I'm not sure there is a = value to pass that list to the DOTS client. For example, a server domain ma= y want to hide its internal topology (list of GWs and servers involved in h= andling a mitigation request). Below a text proposal for discussion: To ease debugging and troubleshooting, the DOTS gateway which detects a loop SHOULD include its information (e.g., server name, alias, IP address) in the diagnostic payload under the conditions detailed in Section 5.5.2 of [RFC7252]. Each intermediate DOTS gateway involved in relaying a 5.06 (Hop Limit Reached) error message SHOULD prepend its own information in the diagnostic payload with a space character used as separator. The ultimate DOTS gateway SHOULD remove the diagnostic payload before forwarding the 5.06 (Hop Limit Reached) error message to a DOTS client domain. [Jon1] I have no issues if a server domain really wants to strip out its in= ternal hops - but troubleshooting is more of a challenge and would not reco= mmend it. [Jon1] However, when setting up a DOTS client, which is failing to work for= whatever reason, it would be good to have a reasonable level of diagnostic= s on the Client - separately invoking someone to look at a DOTS server's lo= gs may take time to get responded to - and you as a novice DOTS client user will have no ide= a as to what to tell the DOTS server guy to look for in the server's busy l= ogs. [Med] I hear that you are for: s/DOTS gateway SHOULD remove the diagnostic = payload before/DOTS gateway MAY remove the diagnostic payload before. Right= ? [Jon2] I feel a lot happier with MAY [Med] OK. [Jon1] I would also like the structure of the diagnostic message to be well= formatted (e.g., no leading text, only one of server name / alias / IP add= ress, blank separator etc.) so it can easily be documented in user manuals = etc. as well as perhaps parsed by a receiver of the 5.06 message (interim h= op or final destination). All other responses (albeit in cbor) are pretty = well documented. [Med] Isn't this covered in the above text? [Jon2] Dyslexia rules - I read 'prepend' as 'append' - sorry. Prepending w= ill do what I am looking for in part. [Med] Great! [Jon2] However, adding in more than one of server name / alias / IP addres= s per hop might be a bit confusing when you "count" the hops. [Med] This is exactly why the provided examples are not plural "(e.g., serv= er name, alias, IP address)". I agree that we can use a more strict languag= e. I can add this NEW sentence: "Only one information per DOTS gateway MUST appear in the diagnostic payloa= d." [Jon3] Yes please. ~jon3 ~Jon2 The initial hop-limit value SHOULD be configurable. If no in= itial value is explicitly provided, the default initial hop-limit v= alue of 16 MUST be used. Because forwarding errors may occur if inadequate hop-limit v= alues are used, DOTS agents at the boundaries of an administrative domain MAY be instructed to rewrite the value of hop-limit ca= rried in received messages (that is, ignore the value of hop-limit received in a message). This is an optional option. [Jon] This should read "This is an optional CoAP Option". [Med] I can make the change. Please note that the text starts with "A DOTS = gateway may add the following CoAP option" which is clear enough this is ab= out an optional CoAP option. [Jon1] I guess I am being picky! ~jon1 Regards Jon --_000_787AE7BB302AE849A7480A190F8B93302DEF3CE9OPEXCLILMA3corp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Re-,

 

I confirm that I implemented th= e changes we agreed in my local copy.

 

You may double check at: htt= ps://github.com/boucadair/draft-ietf-dots-signal-channel

 

Cheers,

Med

 

De : Jon Shallow [mailto:supjps-ietf= @jpshallow.com]
Envoy=E9 : mercredi 28 mars 2018 11:38
=C0 : BOUCADAIR Mohamed IMT/OLN; dots@ietf.org
Objet : RE: [Dots] WGLC signal-18 Draft Hop Limit tidy up<= /o:p>

 

Hi Med,=

&n= bsp;

See inl= ine [Jon3]

&n= bsp;

Regards=

&n= bsp;

Jon

&n= bsp;

&n= bsp;

&n= bsp;

 

De : Dots [mailto:dots-bounces@ietf.org] De la part de Jon Shallow
Envoy=E9 : vendredi 23 mars 2018 16:35
=C0 : dots@ietf.org
Objet : [Dots] WGLC signal-18 Draft Hop Limit tidy up

 

Hi there,

 

I believe that there are a coup= le of changes required for the hop-limit definition – see [Jon] inlin= e.

 

     &= nbsp;     hop-limit:  This option (see Section 9.4= ) is used to detect and

     &= nbsp;        prevent infinite loops.&nbs= p; This option is typically inserted by a

     &= nbsp;        DOTS gateway.

 

     &= nbsp;        The length of the hop-limit= option is 1 byte.

 

     &= nbsp;        The value of the hop-limit = option is encoded as an unsigned

     &= nbsp;        integer (see Section 3.2 of= [RFC7252]).

 

     &= nbsp;        Each intermediate DOTS agen= t involved in the handling of a DOTS

     &= nbsp;        message MUST decrement the = hop-limit option value by 1 prior to

     &= nbsp;        forwarding upstream if this= parameter exists.  DOTS messages MUST

     &= nbsp;        NOT be forwarded if the hop= -limit option is set to '0' after

     &= nbsp;        decrement.  Messages t= hat cannot be forwarded because of exhausted

     &= nbsp;        hop-limit SHOULD be logged = with a 5.06 (Hop Limit Reached) error

     &= nbsp;        message sent back to the DO= TS peer.  It is RECOMMENDED that DOTS

     &= nbsp;        clients and gateways suppor= t means to alert administrators about

     &= nbsp;        loop errors so that appropr= iate actions are undertaken.

[Jon] We need to add in somethi= ng like:-

Each intermediate DOTS agent SH= OULD add in the hop-limit option with the initial default value if it does = not exist before forwarding upstream any information.

 

[Med] I’m not sure to und= erstand this one. Please note that the text says “A DOTS gateway may = add the following CoAP option”. This is typically a GW which is instructed to insert the option will inject the option and follows the = setting of the initial value.

&n= bsp;

[Jon1] = I guess that I am trying to differentiate between updating an existing Hop-= Limit and not injecting a new one alongside a previous one.  Having mu= ltiple Hop-Limit options could get interesting!

[Med] OK, I get your point. Wha= t about adding :

NEW:

 Only one single instance = of the option is allowed in a message.

[Jon2] = Works for me

[Med] OK, thanks.

&n= bsp;

[Jon] We need to define the for= mat of the 5.06 CoAP diagnostic message so that it is potentially parseable= by the DOTS client as well as by any other potential RFC that make use of = this 5.06 code.  In addition, it would be good if each intermediate DOTS agent appended its own IP (prefixed by a= blank) to the end of the diagnostic message as the 5.06 response gets pass= ed back through the DOST agents to enable troubleshooting at the DOTS clien= t.  The diagnostic message length would need to be restricted to something like 1000 bytes to prevent UDP fr= agmentation.  Suggestions welcome here.

 

[Med] I can see a value in reco= rding the list of GWs involved in a loop for debugging purposes at the DOTS= server domain, but I’m not sure there is a value to pass that list to the DOTS client. For example, a server domain may wan= t to hide its internal topology (list of GWs and servers involved in handli= ng a mitigation request). Below a  text proposal for discussion:<= /o:p>

 

   &= nbsp;  To ease debugging and troubleshooting, the DOTS gateway which

   &= nbsp;  detects a loop SHOULD include its information (e.g., server nam= e,

   &= nbsp;  alias, IP address) in the diagnostic payload under the conditio= ns

   &= nbsp;  detailed in Section 5.5.2 of [RFC7252].  Each intermediate= DOTS

   &= nbsp;  gateway involved in relaying a 5.06 (Hop Limit Reached) error

   &= nbsp;  message SHOULD prepend its own information in the diagnostic

   &= nbsp;  payload with a space character used as separator.  The ult= imate

   &= nbsp;  DOTS gateway SHOULD remove the diagnostic payload before

   &= nbsp;  forwarding the 5.06 (Hop Limit Reached) error message to a DOTS=

   &= nbsp;  client domain.

[Jon1] = I have no issues if a server domain really wants to strip out its internal = hops – but troubleshooting is more of a challenge and would not recom= mend it.

[Jon1] = However, when setting up a DOTS client, which is failing to work for whatev= er reason, it would be good to have a reasonable level of diagnostics on th= e Client – separately invoking someone to look at a DOTS server’s logs may take time

to get = responded to – and you as a novice DOTS client user will have no idea= as to what to tell the DOTS server guy to look for in the server’s b= usy logs.

[Med] I hear that you are for: = s/DOTS gateway SHOULD remove the diagnostic payload before/DOTS gateway MAY remove the diagnosti= c payload before. Right?

[Jon2] = I feel a lot happier with MAY

[Med] OK.

 

[Jon1] = I would also like the structure of the diagnostic message to be well format= ted (e.g., no leading text, only one of server name / alias / IP address, b= lank separator etc.) so it can easily be documented in user manuals etc. as well as perhaps parsed by a receiver= of the 5.06 message (interim hop or final destination).  All other re= sponses (albeit in cbor) are pretty well documented.

[Med] Isn’t this covered = in the above text?

[Jon2] = Dyslexia rules – I read ‘prepend’ as ‘append’= - sorry.  Prepending will do what I am looking for in part.

[Med] Great!

[Jon2] = However, adding in more than one of  server name / alias / IP address = per hop might be a bit confusing when you “count” the hops.

[Med] This is exactly why the p= rovided examples are not plural “(e.g., server name, alias, IP address)”. I agree that we can use a more strict language. I can add this NEW sentence:  

“Only one information per= DOTS gateway MUST appear in the diagnostic payload.”

[Jon3] = Yes please.

~jon3

~Jon2

 

&nbs= p;

     &= nbsp;        The initial hop-limit value= SHOULD be configurable.  If no initial

     &= nbsp;        value is explicitly provide= d, the default initial hop-limit value

     &= nbsp;        of 16 MUST be used.

 

     &= nbsp;        Because forwarding errors m= ay occur if inadequate hop-limit values

     &= nbsp;        are used, DOTS agents at th= e boundaries of an administrative

     &= nbsp;        domain MAY be instructed to= rewrite the value of hop-limit carried

     &= nbsp;        in received messages (that = is, ignore the value of hop-limit

     &= nbsp;        received in a message).

 

     &= nbsp;        This is an optional option.=

[Jon] This should read “T= his is an optional CoAP Option”.

&nbs= p;

[Med] I can make the change. Pl= ease note that the text starts with “A DOTS gateway may add the follo= wing CoAP option” which is clear enough this is about an optional CoAP option.

&n= bsp;

[Jon1] = I guess I am being picky!

~jon1

Regards

 

Jon

--_000_787AE7BB302AE849A7480A190F8B93302DEF3CE9OPEXCLILMA3corp_-- From lucasmatheussan@gmail.com Wed Mar 28 05:08:16 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 AF5561267BB for ; Wed, 28 Mar 2018 05:08:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=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 E-TV9QU_ln-f for ; Wed, 28 Mar 2018 05:08:15 -0700 (PDT) Received: from mail-vk0-x241.google.com (mail-vk0-x241.google.com [IPv6:2607:f8b0:400c:c05::241]) (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 30B52126E01 for ; Wed, 28 Mar 2018 05:08:15 -0700 (PDT) Received: by mail-vk0-x241.google.com with SMTP id f124so1218204vkg.13 for ; Wed, 28 Mar 2018 05:08:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=PQfe0m7xc/vIXS+WIXaKH7LQ9e7DI74B9pzlPGp03xs=; b=MKLOKZaG5bVA0itxcWHOlsGd1JC/7DVE5mpG89+DY/30kn3VRtlQA64kLn3SDHNxc9 eOsZSD3fmN0wHUBdJ0rdwBrFId20x6q+YeZc5nfkTjWsvTFnRl8y8OfI808KfDfkEsRo XjeBeE3hZvNpgcsTB7YMcfWHsalANpJVSmcR18ZxiiXR5qyA1ZG7N42Z6XAbw4Sy6ICw wWx7pI8d+p4ToUZKU0UgSUzAqcnFzKr6pWD/n6A2Kngwmm6W8Nm/Np2nJltmOmLbHE9d grkDyS2J1/+HEwHM6jcUGvukg9+xCXbgwcYo1u3HfZlBuiBSnUlIfRNZSss3fIhClHiB 9M3w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=PQfe0m7xc/vIXS+WIXaKH7LQ9e7DI74B9pzlPGp03xs=; b=R8yFJQsrn2RFgUYh6upzNaJ8U3zf6iQArHxrkORto+L5vR+GR++bYJBoGKHJL38LkJ gtULKzg0X6gLskjAj6vXLikXKB9cXLVHO4emH2uC1BIMin3embKiJ0GSg2UlKkqVDjUe VIQXx3L0sLbIHFm0BJ07GB06pXNUa+DBG1Uvip8hvuMa5XvahTRzRAyVMZyTQGUsPxCp 7giiVOfAKkoI+rh/HE/GHmpJHXqBt40oAojlJl/oNQUGyVy68Yj35Xf5U8wWggv6Zxp0 tkF6lzrC6+92YY+TSL15+3f6QVxecGJ0asTUJfpyo3AiuF355c2zfyZg9BFPtvp2n5km 3paA== X-Gm-Message-State: AElRT7Fnae86IMVHCpiwt7DFD7kTFoajWjrRwAmaM7AHlZ/qnxWtNq8I YukQemFezwfCGIW2vYYa27adYMbFKZENEX9cnGrY8Q== X-Google-Smtp-Source: AIpwx48HdXK+6QecxKXwxTimh51GRDkFuVledxwjONVMxu90YLiwPNfYT1V6WWNKrFyYM6d/EalcH0hPl77+gP0ENJs= X-Received: by 10.31.6.72 with SMTP id 69mr2029369vkg.68.1522238893908; Wed, 28 Mar 2018 05:08:13 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.158.194 with HTTP; Wed, 28 Mar 2018 05:08:13 -0700 (PDT) From: Lucas Matheus Date: Wed, 28 Mar 2018 09:08:13 -0300 Message-ID: To: dots@ietf.org Content-Type: multipart/alternative; boundary="001a1143dc6c88e91d056877dc5b" Archived-At: Subject: [Dots] =?utf-8?b?SGksIEnCtG0gbmV3?= 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, 28 Mar 2018 12:11:15 -0000 --001a1143dc6c88e91d056877dc5b Content-Type: text/plain; charset="UTF-8" Hello guys, I'm new to this working group and IETF community. I want to contribute to the formation of new standards and the advancement of the internet. I'm a graduate student in computing in Brazil. How do I contribute to this WG? Can anyone help me in those first steps? Thank you --001a1143dc6c88e91d056877dc5b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello guys,

I'm new to this w= orking group and IETF community.=C2=A0I want to contribute to the formation= of new standards=C2=A0and the advancement of the internet.=C2=A0
I'= m a graduate student in computing in Brazil.
How do I contribute t= o this WG?
Can anyone help me in those first steps?

<= /div>
Thank you

--001a1143dc6c88e91d056877dc5b-- From nobody Wed Mar 28 05:13: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 163BE126E01 for ; Wed, 28 Mar 2018 05:13:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.271 X-Spam-Level: X-Spam-Status: No, score=-2.271 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, HTML_MESSAGE=0.001, MIME_HTML_MOSTLY=0.428, RCVD_IN_DNSWL_LOW=-0.7, 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 N_MIWYa27mpf for ; Wed, 28 Mar 2018 05:13:09 -0700 (PDT) Received: from mail-vk0-x22f.google.com (mail-vk0-x22f.google.com [IPv6:2607:f8b0:400c:c05::22f]) (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 AB0FD1267BB for ; Wed, 28 Mar 2018 05:13:09 -0700 (PDT) Received: by mail-vk0-x22f.google.com with SMTP id x5so1230235vkd.7 for ; Wed, 28 Mar 2018 05:13:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=2cx3lWUZMqfWhlT7XBYD+cBI9t+BFTGllG46Buf8URE=; b=mL0vHWYD3tglZL+7XMZXWOXW62dWblC3jRhxRG0pIZ/t0NU/T2atKTkXP1Nabbc+kP xCi/CxVz4tjmIubKALe8OvgUs5IyM0xo3OWBNxVQTa2yZT1YBD1KbcrDcPiU8P4g/bNQ w0wsjj8Uj5i9MQ81y7INYFqtgQ66UTY76hAG2yu9Brgsgfxf+F2GXd/YrfoFXDt1X8l4 0punjtXvY/MbynI3Lrfdn8RqRBOt5x+D4H75SmLIVgnNKRx158DV+mBRy3k90tr5Vzzm bRDN4PECd7wSfjhBgU2vfvR2QWs2EoCjcdEm991txr8jku5G3sCvrWstDLKBm2YMIyKw L0TQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=2cx3lWUZMqfWhlT7XBYD+cBI9t+BFTGllG46Buf8URE=; b=ftApJLiCH8Ciqvobttc0ooxTGuof96mwD9k0y4wEwLYvYRu1heG4UZL0xFRHgtIjmS DJw53G21yDo1HBItnn43bsgCWG0SmFWt8q545puj40VES1kbqUYLnbZXmEnPS+LhMjEM UDTRszzi+ASwCfrJmYzkxHg2+H/u5QPw3sjEeIy6rvjAmRgbUaTdRBhUzMpHXfqTdJ3J 1SEXVB2j8qHwZWuaPYzc0aJKBgh7E5IuIAXMPH8mlBb1+DANsnxpnb4wU0hHpRz/PJE/ VywVFs5iSS86S/o2YH1ja/Bvu9IhPHEZxOCabzTFVFYd93vdsvg00/eUVPdg1pbVe+4h T0Ig== X-Gm-Message-State: AElRT7GyScLjh7JgPom/HReyurToyvpP5Njkz7nJI4Dx83VyaNctn+7+ S81zhWeqCHfE81XfS4a37cFNQJqDR1XwpzMKWDwOoPVT X-Google-Smtp-Source: AIpwx4/hCIap/kSLwQyNMezrx0hl0rzCUxDxUuUbaUhqIb3pPeP6ousvsVqdfaMlo8aBK1ST1Fd3mWd4fWWW38Ezzr0= X-Received: by 10.31.185.144 with SMTP id j138mr2094442vkf.52.1522239188473; Wed, 28 Mar 2018 05:13:08 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.158.194 with HTTP; Wed, 28 Mar 2018 05:13:08 -0700 (PDT) From: Lucas Matheus Date: Wed, 28 Mar 2018 09:13:08 -0300 Message-ID: To: dots@ietfa.amsl.com Content-Type: multipart/alternative; boundary="001a114397a6179db8056877eea9" Archived-At: Subject: Re: [Dots] (no subject) 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, 28 Mar 2018 12:13:11 -0000 --001a114397a6179db8056877eea9 Content-Type: text/plain; charset="UTF-8" ok --001a114397a6179db8056877eea9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
ok
--001a114397a6179db8056877eea9-- From nobody Wed Mar 28 06:03: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 4B1E6126D85 for ; Wed, 28 Mar 2018 06:03:14 -0700 (PDT) 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, HTML_MESSAGE=0.001, 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 kJA8QJAxsol9 for ; Wed, 28 Mar 2018 06:03:12 -0700 (PDT) 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 E074A1242F7 for ; Wed, 28 Mar 2018 06:03:11 -0700 (PDT) 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 w2SD39fT014825; Wed, 28 Mar 2018 09:03:10 -0400 DKIM-Filter: OpenDKIM Filter v2.11.0 taper.sei.cmu.edu w2SD39fT014825 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cert.org; s=yc2bmwvrj62m; t=1522242190; bh=qZgjaVzk1f3Z6S27Y+6bPc9pUGZw8vQi7FX4ebJG8xQ=; h=From:To:Subject:Date:References:In-Reply-To:From; b=D/LT3NB7rARy6/DfE2QHJ788cvZw01VP2GXpe+3zSQRaJy8KHPDZteqYtkVAeUTuz TAjkgy58ry7TtOUw9L+u2ICQeJjddRvxduXg0yI9r0zdt0kJfyxANhQL0Z61w3JBwt DbJnmYb+qgaPUppB+7Mk80jDu+Nda/bzbwW85g9g= 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 w2SD35V0006816; Wed, 28 Mar 2018 09:03:06 -0400 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; Wed, 28 Mar 2018 09:03:05 -0400 From: Roman Danyliw To: Lucas Matheus , "dots@ietf.org" Thread-Topic: =?utf-8?B?W0RvdHNdIEhpLCBJwrRtIG5ldw==?= Thread-Index: AQHTxo3lUW3TfeuovEOkshZtlleT06Plmkeg Date: Wed, 28 Mar 2018 13:03:04 +0000 Message-ID: <359EC4B99E040048A7131E0F4E113AFC014C372000@marathon> References: 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: multipart/alternative; boundary="_000_359EC4B99E040048A7131E0F4E113AFC014C372000marathon_" MIME-Version: 1.0 Archived-At: Subject: Re: [Dots] =?utf-8?b?SGksIEnCtG0gbmV3?= 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, 28 Mar 2018 13:03:14 -0000 --_000_359EC4B99E040048A7131E0F4E113AFC014C372000marathon_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGVsbG8gTHVjYXMhDQoNCldlbGNvbWUhICBBbiBlYXN5IHdheSB0byBjb250cmlidXRlIGlzIGJ5 IHJldmlld2luZyB0aGUgZG9jdW1lbnRzIHVuZGVyIGRldmVsb3BtZW50IGJ5IHRoZSB3b3JraW5n IGdyb3VwIGFuZCBwcm92aWRpbmcgZmVlZGJhY2suICBUaGV5IGNhbiBiZSBmb3VuZCBoZXJlOg0K DQpodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL3dnL2RvdHMvZG9jdW1lbnRzLw0KDQpZb3Ug Y2FuIHRyYWNrIHRoZSBjdXJyZW50IGRpc2N1c3Npb24gb24gZWFjaCBvZiB0aGUgZG9jdW1lbnRz IGJ5IHJlYWRpbmcgdGhlIG1haWxpbmcgbGlzdC4gIERvY3VtZW50IHVwZGF0ZXMgbm90IHlldCBw dWJsaXNoZWQgY2FuIGJlIGZvdW5kIGluIGdpdGh1YjoNCg0KaHR0cHM6Ly9naXRodWIuY29tL2Rv dHN3Zy8NCg0KVGhlIHdvcmtpbmcgZ3JvdXAgaXMgYWxzbyBhbHdheXMgc2Vla2luZyBmZWVkYmFj ayBmcm9tIGltcGxlbWVudGF0aW9ucy4gIEN1cnJlbnQgd29yayBpcyBkb2N1bWVudGVkIGhlcmU6 DQoNCmh0dHBzOi8vdHJhYy5pZXRmLm9yZy90cmFjL2RvdHMvd2lraQ0KDQpUbyBsZWFybiBob3cg SUVURiBwcm9jZXNzZXMgd29yaywgY29uc3VsdCBUaGUgVGFvIG9mIHRoZSBJRVRGOg0KDQpodHRw czovL3d3dy5pZXRmLm9yZy90YW8uaHRtbA0KDQpJZiB5b3UgaGF2ZSBtb3JlIHF1ZXN0aW9ucywg cGxlYXNlIGp1c3QgYXNrLg0KDQpSb21hbg0KDQpGcm9tOiBEb3RzIFttYWlsdG86ZG90cy1ib3Vu Y2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgTHVjYXMgTWF0aGV1cw0KU2VudDogV2VkbmVzZGF5 LCBNYXJjaCAyOCwgMjAxOCA4OjA4IEFNDQpUbzogZG90c0BpZXRmLm9yZw0KU3ViamVjdDogW0Rv dHNdIEhpLCBJwrRtIG5ldw0KDQpIZWxsbyBndXlzLA0KDQpJJ20gbmV3IHRvIHRoaXMgd29ya2lu ZyBncm91cCBhbmQgSUVURiBjb21tdW5pdHkuIEkgd2FudCB0byBjb250cmlidXRlIHRvIHRoZSBm b3JtYXRpb24gb2YgbmV3IHN0YW5kYXJkcyBhbmQgdGhlIGFkdmFuY2VtZW50IG9mIHRoZSBpbnRl cm5ldC4NCkknbSBhIGdyYWR1YXRlIHN0dWRlbnQgaW4gY29tcHV0aW5nIGluIEJyYXppbC4NCkhv dyBkbyBJIGNvbnRyaWJ1dGUgdG8gdGhpcyBXRz8NCkNhbiBhbnlvbmUgaGVscCBtZSBpbiB0aG9z ZSBmaXJzdCBzdGVwcz8NCg0KVGhhbmsgeW91DQoNCg== --_000_359EC4B99E040048A7131E0F4E113AFC014C372000marathon_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjojMDU2M0MxOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBz cGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv cjojOTU0RjcyOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxl MTcNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGli cmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28t c3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJp Zjt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEu MGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2Vj dGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVm YXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48 IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxv OmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwh W2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9IiMwNTYzQzEiIHZs aW5rPSIjOTU0RjcyIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+SGVsbG8gTHVjYXMhPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2Nv bG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5XZWxjb21lISAmbmJzcDtBbiBl YXN5IHdheSB0byBjb250cmlidXRlIGlzIGJ5IHJldmlld2luZyB0aGUgZG9jdW1lbnRzIHVuZGVy IGRldmVsb3BtZW50IGJ5IHRoZSB3b3JraW5nIGdyb3VwIGFuZCBwcm92aWRpbmcgZmVlZGJhY2su Jm5ic3A7IFRoZXkgY2FuIGJlIGZvdW5kIGhlcmU6PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp Zjtjb2xvcjojMUY0OTdEIj48YSBocmVmPSJodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL3dn L2RvdHMvZG9jdW1lbnRzLyI+aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy93Zy9kb3RzL2Rv Y3VtZW50cy88L2E+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5Z b3UgY2FuIHRyYWNrIHRoZSBjdXJyZW50IGRpc2N1c3Npb24gb24gZWFjaCBvZiB0aGUgZG9jdW1l bnRzIGJ5IHJlYWRpbmcgdGhlIG1haWxpbmcgbGlzdC4mbmJzcDsgRG9jdW1lbnQgdXBkYXRlcyBu b3QgeWV0IHB1Ymxpc2hlZCBjYW4gYmUgZm91bmQgaW4gZ2l0aHViOjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdE Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PGEgaHJlZj0iaHR0cHM6Ly9naXRodWIuY29tL2Rv dHN3Zy8iPmh0dHBzOi8vZ2l0aHViLmNvbS9kb3Rzd2cvPC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+VGhlIHdvcmtpbmcgZ3JvdXAgaXMgYWxzbyBhbHdheXMg c2Vla2luZyBmZWVkYmFjayBmcm9tIGltcGxlbWVudGF0aW9ucy4mbmJzcDsgQ3VycmVudCB3b3Jr IGlzIGRvY3VtZW50ZWQgaGVyZTo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMx RjQ5N0QiPjxhIGhyZWY9Imh0dHBzOi8vdHJhYy5pZXRmLm9yZy90cmFjL2RvdHMvd2lraSI+aHR0 cHM6Ly90cmFjLmlldGYub3JnL3RyYWMvZG90cy93aWtpPC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+VG8gbGVhcm4gaG93IElFVEYgcHJvY2Vzc2VzIHdvcmss IGNvbnN1bHQgVGhlIFRhbyBvZiB0aGUgSUVURjo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOiMxRjQ5N0QiPjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL3Rhby5odG1sIj5o dHRwczovL3d3dy5pZXRmLm9yZy90YW8uaHRtbDwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOiMxRjQ5N0QiPklmIHlvdSBoYXZlIG1vcmUgcXVlc3Rpb25zLCBwbGVhc2UganVz dCBhc2suPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5Sb21hbjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxhIG5hbWU9Il9NYWls RW5kQ29tcG9zZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvYT48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpz b2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNC4wcHQiPg0KPGRpdj4NCjxkaXYg c3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5n OjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+IERvdHMgW21haWx0bzpkb3Rz LWJvdW5jZXNAaWV0Zi5vcmddDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPkx1Y2FzIE1hdGhldXM8YnI+ DQo8Yj5TZW50OjwvYj4gV2VkbmVzZGF5LCBNYXJjaCAyOCwgMjAxOCA4OjA4IEFNPGJyPg0KPGI+ VG86PC9iPiBkb3RzQGlldGYub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFtEb3RzXSBIaSwgScK0 bSBuZXc8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOiMyMjIyMjI7YmFja2dyb3VuZDp3aGl0ZSI+SGVsbG8gZ3V5 cyw8L3NwYW4+PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS41cHQ7Zm9udC1m YW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMjIyMjIyIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjVwdDtm b250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMyMjIyMjIiPkkn bSBuZXcgdG8gdGhpcyB3b3JraW5nIGdyb3VwIGFuZCBJRVRGIGNvbW11bml0eS4mbmJzcDtJIHdh bnQgdG8gY29udHJpYnV0ZSB0byB0aGUgZm9ybWF0aW9uIG9mIG5ldyBzdGFuZGFyZHMmbmJzcDth bmQgdGhlIGFkdmFuY2VtZW50IG9mIHRoZSBpbnRlcm5ldC4mbmJzcDs8YnI+DQpJJ20gYSBncmFk dWF0ZSBzdHVkZW50IGluIGNvbXB1dGluZyBpbiBCcmF6aWwuPG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6 d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJp YWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMjIyMjIyIj5Ib3cgZG8gSSBjb250cmlidXRlIHRv IHRoaXMgV0c/PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6OS41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjoj MjIyMjIyIj5DYW4gYW55b25lIGhlbHAgbWUgaW4gdGhvc2UgZmlyc3Qgc3RlcHM/PG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS41cHQ7Zm9udC1mYW1p bHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMjIyMjIyIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjVwdDtmb250 LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMyMjIyMjIiPlRoYW5r IHlvdTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8 L2h0bWw+DQo= --_000_359EC4B99E040048A7131E0F4E113AFC014C372000marathon_-- From nobody Wed Mar 28 06:19: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 72805126FDC for ; Wed, 28 Mar 2018 06:19:19 -0700 (PDT) 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 STcMk-NJaFAr for ; Wed, 28 Mar 2018 06:19:16 -0700 (PDT) Received: from mail.jpshallow.com (mail.jpshallow.com [217.40.240.153]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F19351242F7 for ; Wed, 28 Mar 2018 06:19:15 -0700 (PDT) Received: from [127.0.0.1] (helo=N01332) by mail.jpshallow.com with smtps (TLSv1:ECDHE-RSA-AES256-SHA:256) (Exim 4.90_1) (envelope-from ) id 1f1Ayw-00016p-Es; Wed, 28 Mar 2018 14:19:14 +0100 From: "Jon Shallow" To: , References: <05c801d3c2bc$88171290$984537b0$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93302DEF10B4@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <018701d3c5c8$044db950$0ce92bf0$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93302DEF3579@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <01d001d3c5de$410e3ca0$c32ab5e0$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93302DEF3B49@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <026a01d3c678$6bb62270$43226750$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93302DEF3CE9@OPEXCLILMA3.corporate.adroot.infra.ftgroup> In-Reply-To: <787AE7BB302AE849A7480A190F8B93302DEF3CE9@OPEXCLILMA3.corporate.adroot.infra.ftgroup> Date: Wed, 28 Mar 2018 14:19:11 +0100 Message-ID: <02ed01d3c697$5de338d0$19a9aa70$@jpshallow.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_02EE_01D3C69F.BFAB2340" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQLZExA96e11tdoJyqOqcaxu1U7VtQIUMridAPIe3SYBQh+XjQFy2griAn3xOeQCNYLpVgIv3jouoXYQeVA= Content-Language: en-gb Archived-At: Subject: Re: [Dots] WGLC signal-18 Draft Hop Limit tidy up 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, 28 Mar 2018 13:19:19 -0000 This is a multipart message in MIME format. ------=_NextPart_000_02EE_01D3C69F.BFAB2340 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Med, =20 One thing that I earlier commented on appears to have slipped through = the net (and I missed spotting it in your update) =20 =93The diagnostic message length would need to be restricted to = something like 1000 bytes to prevent UDP fragmentation.=94 =20 This could be applied to all CoAP diagnostic messages (RFC7252 does not = seem to pick this up) or just to the hop-limit response (which could get = large). =20 Perhaps the text could read something like:- =93Each intermediate DOTS gateway involved in relaying a 5.06 (Hop Limit Reached) error message SHOULD prepend its own information in the diagnostic payload with a space character used as separator, subject to there being sufficient extra space in the diagnostic payload so that the = overall packet does not exceed the IP MTU (RFC7252 4.6. Message Size) .=94 =20 Regards =20 Jon =20 From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of mohamed.boucadair@orange.com Sent: 28 March 2018 12:58 To: Jon Shallow; dots@ietf.org Subject: Re: [Dots] WGLC signal-18 Draft Hop Limit tidy up =20 Re-, =20 I confirm that I implemented the changes we agreed in my local copy.=20 =20 You may double check at: https://github.com/boucadair/draft-ietf-dots-signal-channel=20 =20 Cheers, Med =20 De : Jon Shallow [mailto:supjps-ietf@jpshallow.com]=20 Envoy=E9 : mercredi 28 mars 2018 11:38 =C0 : BOUCADAIR Mohamed IMT/OLN; dots@ietf.org Objet : RE: [Dots] WGLC signal-18 Draft Hop Limit tidy up =20 Hi Med, =20 See inline [Jon3] =20 Regards =20 Jon =20 =20 =20 =20 De : Dots [mailto:dots-bounces@ietf.org] De la part de Jon Shallow Envoy=E9 : vendredi 23 mars 2018 16:35 =C0 : dots@ietf.org Objet : [Dots] WGLC signal-18 Draft Hop Limit tidy up =20 Hi there, =20 I believe that there are a couple of changes required for the hop-limit definition =96 see [Jon] inline. =20 hop-limit: This option (see Section 9.4) is used to detect = and prevent infinite loops. This option is typically inserted = by a DOTS gateway. =20 The length of the hop-limit option is 1 byte. =20 The value of the hop-limit option is encoded as an = unsigned integer (see Section 3.2 of [RFC7252]). =20 Each intermediate DOTS agent involved in the handling of a DOTS message MUST decrement the hop-limit option value by 1 = prior to forwarding upstream if this parameter exists. DOTS = messages MUST NOT be forwarded if the hop-limit option 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. [Jon] We need to add in something like:- Each intermediate DOTS agent SHOULD add in the hop-limit option with the initial default value if it does not exist before forwarding upstream = any information. =20 [Med] I=92m not sure to understand this one. Please note that the text = says =93A DOTS gateway may add the following CoAP option=94. This is typically a = GW which is instructed to insert the option will inject the option and = follows the setting of the initial value. =20 [Jon1] I guess that I am trying to differentiate between updating an existing Hop-Limit and not injecting a new one alongside a previous one. Having multiple Hop-Limit options could get interesting! [Med] OK, I get your point. What about adding :=20 NEW: Only one single instance of the option is allowed in a message. [Jon2] Works for me [Med] OK, thanks. =20 [Jon] We need to define the format of the 5.06 CoAP diagnostic message = so that it is potentially parseable by the DOTS client as well as by any = other potential RFC that make use of this 5.06 code. In addition, it would be good if each intermediate DOTS agent appended its own IP (prefixed by a blank) to the end of the diagnostic message as the 5.06 response gets = passed back through the DOST agents to enable troubleshooting at the DOTS = client. The diagnostic message length would need to be restricted to something = like 1000 bytes to prevent UDP fragmentation. Suggestions welcome here. =20 [Med] I can see a value in recording the list of GWs involved in a loop = for debugging purposes at the DOTS server domain, but I=92m not sure there = is a value to pass that list to the DOTS client. For example, a server domain = may want to hide its internal topology (list of GWs and servers involved in handling a mitigation request). Below a text proposal for discussion: =20 To ease debugging and troubleshooting, the DOTS gateway which detects a loop SHOULD include its information (e.g., server name, alias, IP address) in the diagnostic payload under the conditions detailed in Section 5.5.2 of [RFC7252]. Each intermediate DOTS gateway involved in relaying a 5.06 (Hop Limit Reached) error message SHOULD prepend its own information in the diagnostic payload with a space character used as separator. The ultimate DOTS gateway SHOULD remove the diagnostic payload before forwarding the 5.06 (Hop Limit Reached) error message to a DOTS client domain. [Jon1] I have no issues if a server domain really wants to strip out its internal hops =96 but troubleshooting is more of a challenge and would = not recommend it. [Jon1] However, when setting up a DOTS client, which is failing to work = for whatever reason, it would be good to have a reasonable level of = diagnostics on the Client =96 separately invoking someone to look at a DOTS = server=92s logs may take time=20 to get responded to =96 and you as a novice DOTS client user will have = no idea as to what to tell the DOTS server guy to look for in the server=92s = busy logs. [Med] I hear that you are for: s/DOTS gateway SHOULD remove the = diagnostic payload before/DOTS gateway MAY remove the diagnostic payload before. = Right? [Jon2] I feel a lot happier with MAY [Med] OK. =20 [Jon1] I would also like the structure of the diagnostic message to be = well formatted (e.g., no leading text, only one of server name / alias / IP address, blank separator etc.) so it can easily be documented in user manuals etc. as well as perhaps parsed by a receiver of the 5.06 message (interim hop or final destination). All other responses (albeit in = cbor) are pretty well documented. [Med] Isn=92t this covered in the above text? [Jon2] Dyslexia rules =96 I read =91prepend=92 as =91append=92 - sorry. = Prepending will do what I am looking for in part. [Med] Great!=20 [Jon2] However, adding in more than one of server name / alias / IP = address per hop might be a bit confusing when you =93count=94 the hops. [Med] This is exactly why the provided examples are not plural =93(e.g., server name, alias, IP address)=94. I agree that we can use a more = strict language. I can add this NEW sentence: =20 =93Only one information per DOTS gateway MUST appear in the diagnostic payload.=94 [Jon3] Yes please. ~jon3 ~Jon2 =20 =20 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. =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 option. [Jon] This should read =93This is an optional CoAP Option=94. =20 [Med] I can make the change. Please note that the text starts with =93A = DOTS gateway may add the following CoAP option=94 which is clear enough this = is about an optional CoAP option. =20 [Jon1] I guess I am being picky! ~jon1 Regards =20 Jon ------=_NextPart_000_02EE_01D3C69F.BFAB2340 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Med,

 

One thing that I earlier = commented on appears to have slipped through the net (and I missed = spotting it in your update)

 

“The diagnostic message length would need to be = restricted to something like 1000 bytes to prevent UDP = fragmentation.”

 

This could = be applied to all CoAP diagnostic messages (RFC7252 does not seem to = pick this up) or just to the hop-limit response (which could get = large).

 

Perhaps the text could read something = like:-

=A0=A0=A0=A0=A0 “Each = intermediate DOTS

=A0=A0=A0=A0=A0 = gateway involved in relaying a 5.06 (Hop Limit Reached) = error

=A0=A0=A0=A0=A0 message SHOULD = prepend its own information in the diagnostic

=A0=A0=A0=A0=A0 payload with a space character used as = separator, subject to there being sufficient extra space in the = diagnostic payload so that the overall packet does not exceed the IP MTU = (RFC7252 4.6. Message Size) .”

 

Regards

 

Jon

 

From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of = mohamed.boucadair@orange.com
Sent: 28 March 2018 = 12:58
To: Jon Shallow; dots@ietf.org
Subject: Re: = [Dots] WGLC signal-18 Draft Hop Limit tidy = up

 

Re-,

 

I confirm that I implemented the changes we agreed in = my local copy.

 

You may double check at: http= s://github.com/boucadair/draft-ietf-dots-signal-channel =

 

Cheers,

Med

 

De : Jon Shallow [mailto:supjps-ietf@jpshallow.co= m]
Envoy=E9 : mercredi 28 mars 2018 = 11:38
=C0 : BOUCADAIR Mohamed IMT/OLN; dots@ietf.org
Objet : = RE: [Dots] WGLC signal-18 Draft Hop Limit tidy = up

 

Hi Med,

 

See inline = [Jon3]

 

Regards

 

Jon

 

 

 

 

De : Dots [mailto:dots-bounces@ietf.org] = De la part de Jon Shallow
Envoy=E9 : vendredi 23 = mars 2018 16:35
=C0 : dots@ietf.org
Objet : = [Dots] WGLC signal-18 Draft Hop Limit tidy = up

 

Hi = there,

 

I believe that there are a couple of changes required = for the hop-limit definition – see [Jon] inline.

 

         &= nbsp; hop-limit:  This option (see Section 9.4) is used to detect = and

         &= nbsp;    prevent infinite loops.  This option is = typically inserted by a

         &= nbsp;    DOTS gateway.

 

         &= nbsp;    The length of the hop-limit option is 1 = byte.

 

         &= nbsp;    The value of the hop-limit option is encoded as = an unsigned

         &= nbsp;    integer (see Section 3.2 of = [RFC7252]).

 

         &= nbsp;    Each intermediate DOTS agent involved in the = handling of a DOTS

         &= nbsp;    message MUST decrement the hop-limit option = value by 1 prior to

         &= nbsp;    forwarding upstream if this parameter = exists.  DOTS messages MUST

         &= nbsp;    NOT be forwarded if the hop-limit option is set = to '0' after

         &= nbsp;    decrement.  Messages that cannot be = forwarded because of exhausted

         &= nbsp;    hop-limit SHOULD be logged with a 5.06 (Hop = Limit Reached) error

         &= nbsp;    message sent back to the DOTS peer.  It is = RECOMMENDED that DOTS

         &= nbsp;    clients and gateways support means to alert = administrators about

         &= nbsp;    loop errors so that appropriate actions are = undertaken.

[Jon] We need to add in = something like:-

Each intermediate = DOTS agent SHOULD add in the hop-limit option with the initial default = value if it does not exist before forwarding upstream any = information.

 

[Med] = I’m not sure to understand this one. Please note that the text = says “A DOTS gateway may add the following CoAP option”. = This is typically a GW which is instructed to insert the option will = inject the option and follows the setting of the initial = value.

 

[Jon1] I guess that I am = trying to differentiate between updating an existing Hop-Limit and not = injecting a new one alongside a previous one.  Having multiple = Hop-Limit options could get interesting!

[Med] OK, I get your point. What about adding : =

NEW:

 Only one single instance of the option is = allowed in a message.

[Jon2] Works for me

[Med] OK, thanks.

 

[Jon] We need to define the format of the 5.06 CoAP = diagnostic message so that it is potentially parseable by the DOTS = client as well as by any other potential RFC that make use of this 5.06 = code.  In addition, it would be good if each intermediate DOTS = agent appended its own IP (prefixed by a blank) to the end of the = diagnostic message as the 5.06 response gets passed back through the = DOST agents to enable troubleshooting at the DOTS client.  The = diagnostic message length would need to be restricted to something like = 1000 bytes to prevent UDP fragmentation.  Suggestions welcome = here.

 

[Med] I = can see a value in recording the list of GWs involved in a loop for = debugging purposes at the DOTS server domain, but I’m not sure = there is a value to pass that list to the DOTS client. For example, a = server domain may want to hide its internal topology (list of GWs and = servers involved in handling a mitigation request). Below a  text = proposal for discussion:

 

      To ease = debugging and troubleshooting, the DOTS gateway = which

      detects a = loop SHOULD include its information (e.g., server = name,

      alias, IP = address) in the diagnostic payload under the = conditions

      detailed in = Section 5.5.2 of [RFC7252].  Each intermediate = DOTS

      gateway = involved in relaying a 5.06 (Hop Limit Reached) = error

      message = SHOULD prepend its own information in the = diagnostic

      payload = with a space character used as separator.  The = ultimate

      DOTS = gateway SHOULD remove the diagnostic payload = before

      forwarding = the 5.06 (Hop Limit Reached) error message to a = DOTS

      = client domain.

[Jon1] I have no issues = if a server domain really wants to strip out its internal hops – = but troubleshooting is more of a challenge and would not recommend = it.

[Jon1] However, when setting up a DOTS client, = which is failing to work for whatever reason, it would be good to have a = reasonable level of diagnostics on the Client – separately = invoking someone to look at a DOTS server’s logs may take time =

to get responded to = – and you as a novice DOTS client user will have no idea as to = what to tell the DOTS server guy to look for in the server’s busy = logs.

[Med] I = hear that you are for: s/DOTS gateway SHOULD remove the diagnostic = payload before/DOTS gateway MAY remove the diagnostic payload before. = Right?

[Jon2] I feel a lot = happier with MAY

[Med] = OK.

 

[Jon1] I would also like the structure of the = diagnostic message to be well formatted (e.g., no leading text, only one = of server name / alias / IP address, blank separator etc.) so it can = easily be documented in user manuals etc. as well as perhaps parsed by a = receiver of the 5.06 message (interim hop or final destination). =  All other responses (albeit in cbor) are pretty well = documented.

[Med] = Isn’t this covered in the above text?

[Jon2] Dyslexia rules – I read = ‘prepend’ as ‘append’ - sorry.  Prepending = will do what I am looking for in part.

[Med] Great!

[Jon2] However, adding = in more than one of  server name / alias / IP address per hop might = be a bit confusing when you “count” the = hops.

[Med] = This is exactly why the provided examples are not plural “(e.g., = server name, alias, IP address)”. I agree that we can use a more strict = language. I can add this NEW sentence:  

“Only one information per DOTS gateway MUST = appear in the diagnostic payload.”

[Jon3] Yes please.

~jon3

~Jon2

 

 

         &= nbsp;    The initial hop-limit value SHOULD be = configurable.  If no initial

         &= nbsp;    value is explicitly provided, the default = initial hop-limit value

         &= nbsp;    of 16 MUST be used.

 

         &= nbsp;    Because forwarding errors may occur if = inadequate hop-limit values

         &= nbsp;    are used, DOTS agents at the boundaries of an = administrative

          =     domain MAY be instructed to rewrite the value of = hop-limit carried

         &= nbsp;    in received messages (that is, ignore the value = of hop-limit

         &= nbsp;    received in a message).

 

         &= nbsp;    This is an optional option.

[Jon] This should read “This is an optional CoAP = Option”.

 

[Med] I can make the change. Please note that the text = starts with “A DOTS gateway may add the following = CoAP option” = which is clear enough this is about an optional CoAP = option.

 

[Jon1] I guess I am = being picky!

~jon1

Regards

 

Jon

= ------=_NextPart_000_02EE_01D3C69F.BFAB2340-- From nobody Wed Mar 28 07:03:50 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 804ED12711B; Wed, 28 Mar 2018 07:03:42 -0700 (PDT) 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.76.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152224582246.29792.10081268790644743940@ietfa.amsl.com> Date: Wed, 28 Mar 2018 07:03:42 -0700 Archived-At: Subject: [Dots] I-D Action: draft-ietf-dots-use-cases-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: Wed, 28 Mar 2018 14:03:42 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DDoS Open Threat Signaling WG of the IETF. Title : Use cases for DDoS Open Threat Signaling Authors : Roland Dobbins Daniel Migault Stefan Fouant Robert Moskowitz Nik Teague Liang Xia Kaname Nishizuka Filename : draft-ietf-dots-use-cases-11.txt Pages : 14 Date : 2018-03-28 Abstract: The DDoS Open Threat Signaling (DOTS) effort is intended to provide a protocol to facilitate interoperability across disparate DDoS mitigation solutions and services. This document presents use cases which describe the interactions expected between the DOTS components as well as DOTS messaging exchanges. The purpose of describing use cases is to identify the interacting DOTS components, how they collaborate and what are the types of information to be exchanged. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dots-use-cases/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-dots-use-cases-11 https://datatracker.ietf.org/doc/html/draft-ietf-dots-use-cases-11 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dots-use-cases-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 Wed Mar 28 07:16: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 A72A812711B for ; Wed, 28 Mar 2018 07:15:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.609 X-Spam-Level: X-Spam-Status: No, score=-2.609 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 VDIMRdLs6KlA for ; Wed, 28 Mar 2018 07:15:55 -0700 (PDT) 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 8EFA4127286 for ; Wed, 28 Mar 2018 07:15:50 -0700 (PDT) Received: from opfedar00.francetelecom.fr (unknown [xx.xx.xx.11]) by opfedar24.francetelecom.fr (ESMTP service) with ESMTP id 17885C0844; Wed, 28 Mar 2018 16:15:49 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.13]) by opfedar00.francetelecom.fr (ESMTP service) with ESMTP id EF3B418007B; Wed, 28 Mar 2018 16:15:48 +0200 (CEST) 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; Wed, 28 Mar 2018 16:15:48 +0200 From: To: Jon Shallow , "dots@ietf.org" Thread-Topic: [Dots] WGLC signal-18 Draft Hop Limit tidy up Thread-Index: AQLZExA96e11tdoJyqOqcaxu1U7VtQIUMridAPIe3SYBQh+XjQFy2griAn3xOeQCNYLpVgIv3jouoXYQeVCAABE+EA== Date: Wed, 28 Mar 2018 14:15:48 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93302DEF3F98@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <05c801d3c2bc$88171290$984537b0$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93302DEF10B4@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <018701d3c5c8$044db950$0ce92bf0$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93302DEF3579@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <01d001d3c5de$410e3ca0$c32ab5e0$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93302DEF3B49@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <026a01d3c678$6bb62270$43226750$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93302DEF3CE9@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <02ed01d3c697$5de338d0$19a9aa70$@jpshallow.com> In-Reply-To: <02ed01d3c697$5de338d0$19a9aa70$@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_787AE7BB302AE849A7480A190F8B93302DEF3F98OPEXCLILMA3corp_" MIME-Version: 1.0 Archived-At: Subject: Re: [Dots] WGLC signal-18 Draft Hop Limit tidy up 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, 28 Mar 2018 14:15:59 -0000 --_000_787AE7BB302AE849A7480A190F8B93302DEF3F98OPEXCLILMA3corp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Jon, RFC7252 does already mention the following : If the Path MTU is not known for a destination, an IP MTU of 1280 bytes SHOULD be assumed; if nothing is known about the size of the headers, good upper bounds are 1152 bytes for the message size and 1024 bytes for the payload size. We do already refer to that section in the draft. We don't need to call out= again for this particular case. Thank you. Cheers, Med De : Jon Shallow [mailto:supjps-ietf@jpshallow.com] Envoy=E9 : mercredi 28 mars 2018 15:19 =C0 : BOUCADAIR Mohamed IMT/OLN; dots@ietf.org Objet : RE: [Dots] WGLC signal-18 Draft Hop Limit tidy up Hi Med, One thing that I earlier commented on appears to have slipped through the n= et (and I missed spotting it in your update) "The diagnostic message length would need to be restricted to something lik= e 1000 bytes to prevent UDP fragmentation." This could be applied to all CoAP diagnostic messages (RFC7252 does not see= m to pick this up) or just to the hop-limit response (which could get large= ). Perhaps the text could read something like:- "Each intermediate DOTS gateway involved in relaying a 5.06 (Hop Limit Reached) error message SHOULD prepend its own information in the diagnostic payload with a space character used as separator, subject to there be= ing sufficient extra space in the diagnostic payload so that the overall pa= cket does not exceed the IP MTU (RFC7252 4.6. Message Size) ." Regards Jon From: Dots [mailto: dots-bounces@ietf.org] On= Behalf Of mohamed.boucadair@orange.com Sent: 28 March 2018 12:58 To: Jon Shallow; dots@ietf.org Subject: Re: [Dots] WGLC signal-18 Draft Hop Limit tidy up Re-, I confirm that I implemented the changes we agreed in my local copy. You may double check at: https://github.com/boucadair/draft-ietf-dots-signa= l-channel Cheers, Med De : Jon Shallow [mailto:supjps-ietf@jpshallow.com] Envoy=E9 : mercredi 28 mars 2018 11:38 =C0 : BOUCADAIR Mohamed IMT/OLN; dots@ietf.org Objet : RE: [Dots] WGLC signal-18 Draft Hop Limit tidy up Hi Med, See inline [Jon3] Regards Jon De : Dots [mailto:dots-bounces@ietf.org] De la part de Jon Shallow Envoy=E9 : vendredi 23 mars 2018 16:35 =C0 : dots@ietf.org Objet : [Dots] WGLC signal-18 Draft Hop Limit tidy up Hi there, I believe that there are a couple of changes required for the hop-limit def= inition - see [Jon] inline. hop-limit: This option (see Section 9.4) is used to detect and prevent infinite loops. This option is typically inserted by= a DOTS gateway. The length of the hop-limit option is 1 byte. The value of the hop-limit option is encoded as an unsigned integer (see Section 3.2 of [RFC7252]). Each intermediate DOTS agent involved in the handling of a DO= TS message MUST decrement the hop-limit option value by 1 prior = to forwarding upstream if this parameter exists. DOTS messages = MUST NOT be forwarded if the hop-limit option is set to '0' after decrement. Messages that cannot be forwarded because of exha= usted hop-limit SHOULD be logged with a 5.06 (Hop Limit Reached) er= ror message sent back to the DOTS peer. It is RECOMMENDED that D= OTS clients and gateways support means to alert administrators ab= out loop errors so that appropriate actions are undertaken. [Jon] We need to add in something like:- Each intermediate DOTS agent SHOULD add in the hop-limit option with the in= itial default value if it does not exist before forwarding upstream any inf= ormation. [Med] I'm not sure to understand this one. Please note that the text says "= A DOTS gateway may add the following CoAP option". This is typically a GW w= hich is instructed to insert the option will inject the option and follows = the setting of the initial value. [Jon1] I guess that I am trying to differentiate between updating an existi= ng Hop-Limit and not injecting a new one alongside a previous one. Having = multiple Hop-Limit options could get interesting! [Med] OK, I get your point. What about adding : NEW: Only one single instance of the option is allowed in a message. [Jon2] Works for me [Med] OK, thanks. [Jon] We need to define the format of the 5.06 CoAP diagnostic message so t= hat it is potentially parseable by the DOTS client as well as by any other = potential RFC that make use of this 5.06 code. In addition, it would be go= od if each intermediate DOTS agent appended its own IP (prefixed by a blank= ) to the end of the diagnostic message as the 5.06 response gets passed bac= k through the DOST agents to enable troubleshooting at the DOTS client. Th= e diagnostic message length would need to be restricted to something like 1= 000 bytes to prevent UDP fragmentation. Suggestions welcome here. [Med] I can see a value in recording the list of GWs involved in a loop for= debugging purposes at the DOTS server domain, but I'm not sure there is a = value to pass that list to the DOTS client. For example, a server domain ma= y want to hide its internal topology (list of GWs and servers involved in h= andling a mitigation request). Below a text proposal for discussion: To ease debugging and troubleshooting, the DOTS gateway which detects a loop SHOULD include its information (e.g., server name, alias, IP address) in the diagnostic payload under the conditions detailed in Section 5.5.2 of [RFC7252]. Each intermediate DOTS gateway involved in relaying a 5.06 (Hop Limit Reached) error message SHOULD prepend its own information in the diagnostic payload with a space character used as separator. The ultimate DOTS gateway SHOULD remove the diagnostic payload before forwarding the 5.06 (Hop Limit Reached) error message to a DOTS client domain. [Jon1] I have no issues if a server domain really wants to strip out its in= ternal hops - but troubleshooting is more of a challenge and would not reco= mmend it. [Jon1] However, when setting up a DOTS client, which is failing to work for= whatever reason, it would be good to have a reasonable level of diagnostic= s on the Client - separately invoking someone to look at a DOTS server's lo= gs may take time to get responded to - and you as a novice DOTS client user will have no ide= a as to what to tell the DOTS server guy to look for in the server's busy l= ogs. [Med] I hear that you are for: s/DOTS gateway SHOULD remove the diagnostic = payload before/DOTS gateway MAY remove the diagnostic payload before. Right= ? [Jon2] I feel a lot happier with MAY [Med] OK. [Jon1] I would also like the structure of the diagnostic message to be well= formatted (e.g., no leading text, only one of server name / alias / IP add= ress, blank separator etc.) so it can easily be documented in user manuals = etc. as well as perhaps parsed by a receiver of the 5.06 message (interim h= op or final destination). All other responses (albeit in cbor) are pretty = well documented. [Med] Isn't this covered in the above text? [Jon2] Dyslexia rules - I read 'prepend' as 'append' - sorry. Prepending w= ill do what I am looking for in part. [Med] Great! [Jon2] However, adding in more than one of server name / alias / IP addres= s per hop might be a bit confusing when you "count" the hops. [Med] This is exactly why the provided examples are not plural "(e.g., serv= er name, alias, IP address)". I agree that we can use a more strict languag= e. I can add this NEW sentence: "Only one information per DOTS gateway MUST appear in the diagnostic payloa= d." [Jon3] Yes please. ~jon3 ~Jon2 The initial hop-limit value SHOULD be configurable. If no in= itial value is explicitly provided, the default initial hop-limit v= alue of 16 MUST be used. Because forwarding errors may occur if inadequate hop-limit v= alues are used, DOTS agents at the boundaries of an administrative domain MAY be instructed to rewrite the value of hop-limit ca= rried in received messages (that is, ignore the value of hop-limit received in a message). This is an optional option. [Jon] This should read "This is an optional CoAP Option". [Med] I can make the change. Please note that the text starts with "A DOTS = gateway may add the following CoAP option" which is clear enough this is ab= out an optional CoAP option. [Jon1] I guess I am being picky! ~jon1 Regards Jon --_000_787AE7BB302AE849A7480A190F8B93302DEF3F98OPEXCLILMA3corp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Jon,

 

RFC7252 does already mention th= e following :

 

   If the= Path MTU is not known for a destination, an IP MTU of 1280

   bytes = SHOULD be assumed; if nothing is known about the size of the

   header= s, good upper bounds are 1152 bytes for the message size and

   1024 b= ytes for the payload size.

 

We do already refer to that sec= tion in the draft. We don’t need to call out again for this particula= r case.

 

Thank you.

 

Cheers,

Med

 

De : Jon Shallow [mailto:supjps-ietf= @jpshallow.com]
Envoy=E9 : mercredi 28 mars 2018 15:19
=C0 : BOUCADAIR Mohamed IMT/OLN; dots@ietf.org
Objet : RE: [Dots] WGLC signal-18 Draft Hop Limit tidy up<= /o:p>

 

Hi Med,=

&n= bsp;

One thi= ng that I earlier commented on appears to have slipped through the net (and= I missed spotting it in your update)

&n= bsp;

“The diagnostic message l= ength would need to be restricted to something like 1000 bytes to prevent U= DP fragmentation.”

 

This could be applied to all Co= AP diagnostic messages (RFC7252 does not seem to pick this up) or just to t= he hop-limit response (which could get large).

 

Perhaps the text could read som= ething like:-

      = “Each intermediate DOTS

      = gateway involved in relaying a 5.06 (Hop Limit Reached) error

      = message SHOULD prepend its own information in the diagnostic

      = payload with a space character used as separator, subject to there being su= fficient extra space in the diagnostic payload so that the overall packet d= oes not exceed the IP MTU (RFC7252 4.6. Message Size) .”

 

Regards=

&n= bsp;

Jon

&n= bsp;

From:= Dots [mailto: dots-bounces@ietf.org] On B= ehalf Of mohamed.boucadair@orang= e.com
Sent: 28 March 2018 12:58
To: Jon Shallow; dots@ietf.org<= br> Subject: Re: [Dots] WGLC signal-18 Draft Hop Limit tidy up

 

Re-,

 

I confirm that I implemented th= e changes we agreed in my local copy.

 

You may double check at: htt= ps://github.com/boucadair/draft-ietf-dots-signal-channel

 

Cheers,

Med

 

De : Jon Shallow [mailto:supjps-ietf@jpshallow.com]
Envoy=E9 : mercredi 28 mars 2018 11:38
=C0 : BOUCADAIR Mohamed IMT/OLN; dots@ietf.org
Objet : RE: [Dots] WGLC signal-18 Draft Hop Limit tidy up<= /o:p>

 

Hi Med,=

&n= bsp;

See inl= ine [Jon3]

&n= bsp;

Regards=

&n= bsp;

Jon

&n= bsp;

&n= bsp;

&n= bsp;

 

De : Dots [mailto:dots-bounces@ietf.org] De la part de Jon Shallow
Envoy=E9 : vendredi 23 mars 2018 16:35
=C0 : dots@ietf.org
Objet : [Dots] WGLC signal-18 Draft Hop Limit tidy up

 

Hi there,

 

I believe that there are a coup= le of changes required for the hop-limit definition – see [Jon] inlin= e.

 

     &= nbsp;     hop-limit:  This option (see Section 9.4= ) is used to detect and

     &= nbsp;        prevent infinite loops.&nbs= p; This option is typically inserted by a

     &= nbsp;        DOTS gateway.

 

     &= nbsp;        The length of the hop-limit= option is 1 byte.

 

     &= nbsp;        The value of the hop-limit = option is encoded as an unsigned

     &= nbsp;        integer (see Section 3.2 of= [RFC7252]).

 

     &= nbsp;        Each intermediate DOTS agen= t involved in the handling of a DOTS

     &= nbsp;        message MUST decrement the = hop-limit option value by 1 prior to

     &= nbsp;        forwarding upstream if this= parameter exists.  DOTS messages MUST

     &= nbsp;        NOT be forwarded if the hop= -limit option is set to '0' after

     &= nbsp;        decrement.  Messages t= hat cannot be forwarded because of exhausted

     &= nbsp;        hop-limit SHOULD be logged = with a 5.06 (Hop Limit Reached) error

     &= nbsp;        message sent back to the DO= TS peer.  It is RECOMMENDED that DOTS

     &= nbsp;        clients and gateways suppor= t means to alert administrators about

     &= nbsp;        loop errors so that appropr= iate actions are undertaken.

[Jon] We need to add in somethi= ng like:-

Each intermediate DOTS agent SH= OULD add in the hop-limit option with the initial default value if it does = not exist before forwarding upstream any information.

 

[Med] I’m not sure to und= erstand this one. Please note that the text says “A DOTS gateway may = add the following CoAP option”. This is typically a GW which is instructed to insert the option will inject the option and follows the = setting of the initial value.

&n= bsp;

[Jon1] = I guess that I am trying to differentiate between updating an existing Hop-= Limit and not injecting a new one alongside a previous one.  Having mu= ltiple Hop-Limit options could get interesting!

[Med] OK, I get your point. Wha= t about adding :

NEW:

 Only one single instance = of the option is allowed in a message.

[Jon2] = Works for me

[Med] OK, thanks.

&n= bsp;

[Jon] We need to define the for= mat of the 5.06 CoAP diagnostic message so that it is potentially parseable= by the DOTS client as well as by any other potential RFC that make use of = this 5.06 code.  In addition, it would be good if each intermediate DOTS agent appended its own IP (prefixed by a= blank) to the end of the diagnostic message as the 5.06 response gets pass= ed back through the DOST agents to enable troubleshooting at the DOTS clien= t.  The diagnostic message length would need to be restricted to something like 1000 bytes to prevent UDP fr= agmentation.  Suggestions welcome here.

 

[Med] I can see a value in reco= rding the list of GWs involved in a loop for debugging purposes at the DOTS= server domain, but I’m not sure there is a value to pass that list to the DOTS client. For example, a server domain may wan= t to hide its internal topology (list of GWs and servers involved in handli= ng a mitigation request). Below a  text proposal for discussion:<= /o:p>

 

   &= nbsp;  To ease debugging and troubleshooting, the DOTS gateway which

   &= nbsp;  detects a loop SHOULD include its information (e.g., server nam= e,

   &= nbsp;  alias, IP address) in the diagnostic payload under the conditio= ns

   &= nbsp;  detailed in Section 5.5.2 of [RFC7252].  Each intermediate= DOTS

   &= nbsp;  gateway involved in relaying a 5.06 (Hop Limit Reached) error

   &= nbsp;  message SHOULD prepend its own information in the diagnostic

   &= nbsp;  payload with a space character used as separator.  The ult= imate

   &= nbsp;  DOTS gateway SHOULD remove the diagnostic payload before

   &= nbsp;  forwarding the 5.06 (Hop Limit Reached) error message to a DOTS=

   &= nbsp;  client domain.

[Jon1] = I have no issues if a server domain really wants to strip out its internal = hops – but troubleshooting is more of a challenge and would not recom= mend it.

[Jon1] = However, when setting up a DOTS client, which is failing to work for whatev= er reason, it would be good to have a reasonable level of diagnostics on th= e Client – separately invoking someone to look at a DOTS server’s logs may take time

to get = responded to – and you as a novice DOTS client user will have no idea= as to what to tell the DOTS server guy to look for in the server’s b= usy logs.

[Med] I hear that you are for: = s/DOTS gateway SHOULD remove the diagnostic payload before/DOTS gateway MAY remove the diagnosti= c payload before. Right?

[Jon2] = I feel a lot happier with MAY

[Med] OK.

 

[Jon1] = I would also like the structure of the diagnostic message to be well format= ted (e.g., no leading text, only one of server name / alias / IP address, b= lank separator etc.) so it can easily be documented in user manuals etc. as well as perhaps parsed by a receiver= of the 5.06 message (interim hop or final destination).  All other re= sponses (albeit in cbor) are pretty well documented.

[Med] Isn’t this covered = in the above text?

[Jon2] = Dyslexia rules – I read ‘prepend’ as ‘append’= - sorry.  Prepending will do what I am looking for in part.

[Med] Great!

[Jon2] = However, adding in more than one of  server name / alias / IP address = per hop might be a bit confusing when you “count” the hops.

[Med] This is exactly why the p= rovided examples are not plural “(e.g., server name, alias, IP address)”. I agree that we can use a more strict language. I can add this NEW sentence:  

“Only one information per= DOTS gateway MUST appear in the diagnostic payload.”

[Jon3] = Yes please.

~jon3

~Jon2

 

&nbs= p;

     &= nbsp;        The initial hop-limit value= SHOULD be configurable.  If no initial

     &= nbsp;        value is explicitly provide= d, the default initial hop-limit value

     &= nbsp;        of 16 MUST be used.

 

     &= nbsp;        Because forwarding errors m= ay occur if inadequate hop-limit values

     &= nbsp;        are used, DOTS agents at th= e boundaries of an administrative

     &= nbsp;        domain MAY be instructed to= rewrite the value of hop-limit carried

     &= nbsp;        in received messages (that = is, ignore the value of hop-limit

     &= nbsp;        received in a message).

 

     &= nbsp;        This is an optional option.=

[Jon] This should read “T= his is an optional CoAP Option”.

&nbs= p;

[Med] I can make the change. Pl= ease note that the text starts with “A DOTS gateway may add the follo= wing CoAP option” which is clear enough this is about an optional CoAP option.

&n= bsp;

[Jon1] = I guess I am being picky!

~jon1

Regards

 

Jon

--_000_787AE7BB302AE849A7480A190F8B93302DEF3F98OPEXCLILMA3corp_-- From nobody Wed Mar 28 07:24: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 D6CA412711B for ; Wed, 28 Mar 2018 07:24:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 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, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X-jSuxA5ZDtw for ; Wed, 28 Mar 2018 07:24:20 -0700 (PDT) Received: from usplmg20.ericsson.net (usplmg20.ericsson.net [198.24.6.45]) (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 B3CA51270FC for ; Wed, 28 Mar 2018 07:24:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1522247059; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=q4OfEvlz00DQxBrafLfDWNlxRvNKtSE6kM+HXyppP+U=; b=gdO3kdmxocjb1Pm+fWFLePYg4aP/d6JSVARk7B+elJNLFXVRCx1Ky76l2UhFRFJe ncRaUI1e89TAN7OGvx76xaEK9pOaM1Psgbcj2iW67fCUEpV6Lle4W2Nkhoj8Feg2 Najtu/gxi3wjS5ZdbqMuEBmn5g0UpSWSBxAyB+u+Apg=; X-AuditID: c618062d-8d7ff70000004288-51-5abba593a75b Received: from EUSAAHC006.ericsson.se (Unknown_Domain [147.117.188.90]) by usplmg20.ericsson.net (Symantec Mail Security) with SMTP id 53.D2.17032.395ABBA5; Wed, 28 Mar 2018 16:24:19 +0200 (CEST) Received: from EUSAAMB107.ericsson.se ([147.117.188.124]) by EUSAAHC006.ericsson.se ([147.117.188.90]) with mapi id 14.03.0382.000; Wed, 28 Mar 2018 10:24:18 -0400 From: Daniel Migault To: "dots@ietf.org" Thread-Topic: New Version Notification for draft-ietf-dots-use-cases-11.txt Thread-Index: AQHTxp2XA/TKD8ITgUKM0ho3ak8psKPlrgKg Date: Wed, 28 Mar 2018 14:24:18 +0000 Message-ID: <2DD56D786E600F45AC6BDE7DA4E8A8C118E01184@eusaamb107.ericsson.se> References: <152224582267.29792.2214827071198414612.idtracker@ietfa.amsl.com> In-Reply-To: <152224582267.29792.2214827071198414612.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.214] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrOLMWRmVeSWpSXmKPExsUyuXRPlO7kpbujDC5NsLFY++YIqwOjx5Il P5kCGKO4bFJSczLLUov07RK4Mo48385asEahYsnN5ewNjAfkuxg5OCQETCQaNil1MXJxCAkc ZZRY+vskE4SznFFi9pVDbF2MnBxsAkYSbYf62UFsEQFliZ1NdxlBbGEBL4kb966wQcS9JX4t W8MEYRtJLN28HKyeRUBVom3mbLA4r4CvxPVz01hBbCEge8K6S8wgNqeAn8Sn9gNgNYwCYhLf T0HMYRYQl7j1ZD6YLSEgILFkz3lmCFtU4uXjf6wQtrJE44f7jCDPMAtoSqzfpQ/Rqigxpfsh O8RaQYmTM5+wTGAUmYVk6iyEjllIOmYh6VjAyLKKkaO0uCAnN93IYBMjMLiPSbDp7mC8P93z EKMAB6MSD2/GlN1RQqyJZcWVuYcYJTiYlUR432sAhXhTEiurUovy44tKc1KLDzFKc7AoifOe 8eSNEhJITyxJzU5NLUgtgskycXBKNTAK9/aYyzOsVRK5MyV7cWXq8r7V/xgP3imROnNSY3vA LoHN5l8OOwd+75kWdetuSukOlmn/dHI44558/Hsn/Jb3f59F9qIHy6Q8pQWsRFTtnzR9mfys tcbmpfrut4Xr9mRetrwU/Hr/oi8cEuIBvqmv/nNOWBz66vsK1YdWSy3eFB27uv5tps4JJZbi jERDLeai4kQAF9cd+GoCAAA= Archived-At: Subject: [Dots] FW: New Version Notification for draft-ietf-dots-use-cases-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, 28 Mar 2018 14:24:23 -0000 SGkgZXZlcnlvbmUhDQoNClBsZWFzZSBmaW5kIHRoZSBkcmFmdC1pZXRmLWRvdHMtdXNlLWNhc2Vz LTExIFsxXS4gSW4gb3JkZXIgdG8gbWVldCB0aGUgYWdncmVzc2l2ZSBzY2hlZHVsZSBhZ3JlZWQg ZHVyaW5nIHRoZSBzZXNzaW9uIGluIExvbmRvbiwgd2Ugd291bGQgZ3JlYXRseSBhcHByZWNpYXRl IHlvdXIgZmVlZCBiYWNrcyBieSB0aGUgZW5kIG9mIHRoZSB3ZWVrICEgDQoNClRoZSBjdXJyZW50 IGRvY3VtZW50IGlzIGxpbWl0ZWQgdG8gMyB1c2UgY2FzZXMgZGVzY3JpYmVkIG92ZXIgMTBpc2gg cGFnZXMuIFdlIGJlbGlldmUgdGhlIGN1cnJlbnQgZG9jdW1lbnQgYWRkcmVzc2VzIHRoZSBmZWVk IGJhY2tzIGFuZCBjb21tZW50cyB3ZSByZWNlaXZlZCBmcm9tIHRoZSBMb25kb24gc2Vzc2lvbi4g SWYgeW91IGJlbGlldmUgb3RoZXJ3aXNlLCBmZWVsIGZyZWUgdG8gYnJpbmcgdGhpcyBvbiB0aGUg bWFpbGluZyBsaXN0Lg0KDQpXZSBleHBlY3QgdG8gcHVibGlzaCB2ZXJzaW9uIDEyIG9uIFR1ZXNk YXkgQXByaWwgMy4gVGhpcyB2ZXJzaW9uIGlzIGV4cGVjdGVkIHRvIGFkZHJlc3MgdGhlIHJlY2Vp dmVkIGNvbW1lbnRzIGFuZCBiZSByZWFkeSB0byBXR0xDLiANCg0KQ29tbWVudHMgY2FuIGJlIGFk ZHJlc3NlZCBkaXJlY3RseSB0byB0aGUgbWFpbGluZyBsaXN0IG9yIHVzaW5nIGdpdGh1YiBwdWxs IHJlcXVlc3RzIG9uIHRoZSBta2QgdmVyc2lvbiBbMl0uIElmIHlvdSBiZWxpZXZlIHNvbWUgZGlz Y3Vzc2lvbnMgYXJlIG5lZWRlZCwgcGxlYXNlIGNvbnNpZGVyIGRpc2N1c3NpbmcgdGhvc2Ugb24g dGhlIG1haWxpbmcgbGlzdC4gDQoNCllvdXJzLCANCkRhbmllbA0KWzFdIGh0dHBzOi8vZGF0YXRy YWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtZG90cy11c2UtY2FzZXMvDQpbMl0gIGh0dHBz Oi8vZ2l0aHViLmNvbS9kb3Rzd2cvZG90cy11c2UtY2FzZXMvYmxvYi9tYXN0ZXIvZHJhZnQtaWV0 Zi1kb3RzLXVzZS1jYXNlcy5ta2QNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206 IGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZyBbbWFpbHRvOmludGVybmV0LWRyYWZ0c0BpZXRmLm9y Z10gDQpTZW50OiBXZWRuZXNkYXksIE1hcmNoIDI4LCAyMDE4IDEwOjA0IEFNDQpUbzogS2FuYW1l IE5pc2hpenVrYSA8a2FuYW1lQG50dHY2LmpwPjsgTmlrIFRlYWd1ZSA8bnRlYWd1ZUB2ZXJpc2ln bi5jb20+OyBEYW5pZWwgTWlnYXVsdCA8ZGFuaWVsLm1pZ2F1bHRAZXJpY3Nzb24uY29tPjsgUm9i ZXJ0IE1vc2tvd2l0eiA8cmdtQGxhYnMuaHR0LWNvbnN1bHQuY29tPjsgU3RlZmFuIEZvdWFudCA8 c3RlZmFuLmZvdWFudEBjb3BwZXJyaXZlcml0LmNvbT47IGRvdHMtY2hhaXJzQGlldGYub3JnOyBS b2xhbmQgRG9iYmlucyA8cmRvYmJpbnNAYXJib3IubmV0PjsgTGlhbmcgWGlhIDxmcmFuay54aWFs aWFuZ0BodWF3ZWkuY29tPjsgTGlhbmcgWGlhIDxGcmFuay54aWFsaWFuZ0BodWF3ZWkuY29tPg0K U3ViamVjdDogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1pZXRmLWRvdHMtdXNl LWNhc2VzLTExLnR4dA0KDQoNCkEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC1pZXRmLWRvdHMt dXNlLWNhc2VzLTExLnR4dCBoYXMgYmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0dGVkIGJ5IERhbmll bCBNaWdhdWx0IGFuZCBwb3N0ZWQgdG8gdGhlIElFVEYgcmVwb3NpdG9yeS4NCg0KTmFtZToJCWRy YWZ0LWlldGYtZG90cy11c2UtY2FzZXMNClJldmlzaW9uOgkxMQ0KVGl0bGU6CQlVc2UgY2FzZXMg Zm9yIEREb1MgT3BlbiBUaHJlYXQgU2lnbmFsaW5nDQpEb2N1bWVudCBkYXRlOgkyMDE4LTAzLTI4 DQpHcm91cDoJCWRvdHMNClBhZ2VzOgkJMTQNClVSTDogICAgICAgICAgICBodHRwczovL3d3dy5p ZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtaWV0Zi1kb3RzLXVzZS1jYXNlcy0xMS50eHQN ClN0YXR1czogICAgICAgICBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1p ZXRmLWRvdHMtdXNlLWNhc2VzLw0KSHRtbGl6ZWQ6ICAgICAgIGh0dHBzOi8vdG9vbHMuaWV0Zi5v cmcvaHRtbC9kcmFmdC1pZXRmLWRvdHMtdXNlLWNhc2VzLTExDQpIdG1saXplZDogICAgICAgaHR0 cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvaHRtbC9kcmFmdC1pZXRmLWRvdHMtdXNlLWNh c2VzDQpEaWZmOiAgICAgICAgICAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRy YWZ0LWlldGYtZG90cy11c2UtY2FzZXMtMTENCg0KQWJzdHJhY3Q6DQogICBUaGUgRERvUyBPcGVu IFRocmVhdCBTaWduYWxpbmcgKERPVFMpIGVmZm9ydCBpcyBpbnRlbmRlZCB0byBwcm92aWRlIGEN CiAgIHByb3RvY29sIHRvIGZhY2lsaXRhdGUgaW50ZXJvcGVyYWJpbGl0eSBhY3Jvc3MgZGlzcGFy YXRlIEREb1MNCiAgIG1pdGlnYXRpb24gc29sdXRpb25zIGFuZCBzZXJ2aWNlcy4gIFRoaXMgZG9j dW1lbnQgcHJlc2VudHMgdXNlIGNhc2VzDQogICB3aGljaCBkZXNjcmliZSB0aGUgaW50ZXJhY3Rp b25zIGV4cGVjdGVkIGJldHdlZW4gdGhlIERPVFMgY29tcG9uZW50cw0KICAgYXMgd2VsbCBhcyBE T1RTIG1lc3NhZ2luZyBleGNoYW5nZXMuICBUaGUgcHVycG9zZSBvZiBkZXNjcmliaW5nIHVzZQ0K ICAgY2FzZXMgaXMgdG8gaWRlbnRpZnkgdGhlIGludGVyYWN0aW5nIERPVFMgY29tcG9uZW50cywg aG93IHRoZXkNCiAgIGNvbGxhYm9yYXRlIGFuZCB3aGF0IGFyZSB0aGUgdHlwZXMgb2YgaW5mb3Jt YXRpb24gdG8gYmUgZXhjaGFuZ2VkLg0KDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgDQoNCg0K UGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhl IHRpbWUgb2Ygc3VibWlzc2lvbiB1bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBh cmUgYXZhaWxhYmxlIGF0IHRvb2xzLmlldGYub3JnLg0KDQpUaGUgSUVURiBTZWNyZXRhcmlhdA0K DQo= From nobody Wed Mar 28 07:35: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 25740120454 for ; Wed, 28 Mar 2018 07:35:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, 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 (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 0qeNXr0MyJiU for ; Wed, 28 Mar 2018 07:35:23 -0700 (PDT) Received: from mail-lf0-x230.google.com (mail-lf0-x230.google.com [IPv6:2a00:1450:4010:c07::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5DAD21201FA for ; Wed, 28 Mar 2018 07:35:23 -0700 (PDT) Received: by mail-lf0-x230.google.com with SMTP id q5-v6so3814531lff.12 for ; Wed, 28 Mar 2018 07:35:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=ioXGiGq8jzL0s53RjASIgY/UvBYdT48zVB+VAKzdp4U=; b=f0DsL72jVoFxWdm8IUeRQx54pUsyadZq2XVt1m5CqSUZKgI+8dxI6OaVKRsJn6w6tF bXDvhoeHfvUPZ72Qgsi7ffFbgPYOG7EPT0oYCWGfOOwyF2TBNJ15QSJlDaFz8xBWrw7f gD27db2jFLoCS6Oll21c/p4xxW1Hb8PyiDxcUQ7L6yB3fnQpvh62F1oZp73X+gQJ51IK VO2oyDQTMrJF438/jruFXz9obR4hlig6UlO0kD47VmrGqg0F5dw805OVolsY+Fx3BOxV CUJ1hEwYTW7TGsaY5BJEDP9pwE2zPrNRE+bS6Y/iNhtr3k7BjCYKu93Q3GuC1tL24OLo eLtA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=ioXGiGq8jzL0s53RjASIgY/UvBYdT48zVB+VAKzdp4U=; b=Z/PCQMqgNyKm3yG1FEymR46CVdNCnQCKJVAyMdHBKs5xzb73hZicXJq9YvPanbLkpP OU0XE2oK5bxMmWWv87Xht8Enkt4A7b1ACnObRkdataWHMga7GnM/E+DK+5wyczNcM2Y9 Sl91lH9WQ8fMNJGFaekauoxkvK+94gEmddMRiK0oNOYCwe8JF62ZsycxamczQsLlo6vz 20UCbBLjnXfdWgfsVt/uAHaX4+8SPnVtg8vaD1xqcRByhNTKdt1sOuFqCW7l96iizW4Y NJWloU9goKthCn1bKpEhBgyq+ZNuXd0nHwtI9B1BgAWdnpWt+A0ImxP91syaUqpW4WM3 Mrww== X-Gm-Message-State: AElRT7Fnw5iZJ1SLpeHGaWeN81spsGztMWBk+lpNSGAeHadUJnfDOmc3 ozkqwV44nIlw1PscTxqmIoX6npQgk21V2c3IFXg= X-Google-Smtp-Source: AIpwx4/6lALsbRjjBsrSBpWB8OpyeLBPjxsjGWKAwqQ9NNkFkuwEHR1hbMgz6oJ/tPA5nqC67PxNOi/1NpzbxuZCFtw= X-Received: by 2002:a19:7103:: with SMTP id m3-v6mr2540596lfc.29.1522247721734; Wed, 28 Mar 2018 07:35:21 -0700 (PDT) MIME-Version: 1.0 Sender: mglt.ietf@gmail.com Received: by 10.46.158.19 with HTTP; Wed, 28 Mar 2018 07:35:21 -0700 (PDT) In-Reply-To: <359EC4B99E040048A7131E0F4E113AFC014C372000@marathon> References: <359EC4B99E040048A7131E0F4E113AFC014C372000@marathon> From: Daniel Migault Date: Wed, 28 Mar 2018 10:35:21 -0400 X-Google-Sender-Auth: g0M4VgMqa2J9k-R8tWyAh_kODKE Message-ID: To: Roman Danyliw Cc: Lucas Matheus , "dots@ietf.org" Content-Type: multipart/alternative; boundary="000000000000b6d80f056879ea15" Archived-At: Subject: Re: [Dots] =?utf-8?b?SGksIEnCtG0gbmV3?= 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, 28 Mar 2018 14:35:26 -0000 --000000000000b6d80f056879ea15 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable HI Lucas, Feel free to review the the use case document and share your concerns on the mailing list. These would be greatly appreciated. Yours, Daniel On Wed, Mar 28, 2018 at 9:03 AM, Roman Danyliw wrote: > Hello Lucas! > > > > Welcome! An easy way to contribute is by reviewing the documents under > development by the working group and providing feedback. They can be fou= nd > here: > > > > https://datatracker.ietf.org/wg/dots/documents/ > > > > You can track the current discussion on each of the documents by reading > the mailing list. Document updates not yet published can be found in > github: > > > > https://github.com/dotswg/ > > > > The working group is also always seeking feedback from implementations. > Current work is documented here: > > > > https://trac.ietf.org/trac/dots/wiki > > > > To learn how IETF processes work, consult The Tao of the IETF: > > > > https://www.ietf.org/tao.html > > > > If you have more questions, please just ask. > > > > Roman > > > > *From:* Dots [mailto:dots-bounces@ietf.org] *On Behalf Of *Lucas Matheus > *Sent:* Wednesday, March 28, 2018 8:08 AM > *To:* dots@ietf.org > *Subject:* [Dots] Hi, I=C2=B4m new > > > > Hello guys, > > > > I'm new to this working group and IETF community. I want to contribute to > the formation of new standards and the advancement of the internet. > I'm a graduate student in computing in Brazil. > > How do I contribute to this WG? > > Can anyone help me in those first steps? > > > > Thank you > > > > _______________________________________________ > Dots mailing list > Dots@ietf.org > https://www.ietf.org/mailman/listinfo/dots > > --000000000000b6d80f056879ea15 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
HI Lucas,

Feel free to review= the the use case document and share your concerns on the mailing list. The= se would be greatly appreciated.

Yours,
Daniel

On Wed, Mar 2= 8, 2018 at 9:03 AM, Roman Danyliw <rdd@cert.org> wrote:

Hello Lucas!

=C2=A0

Welcome!=C2=A0 An easy way to contrib= ute is by reviewing the documents under development by the working group an= d providing feedback.=C2=A0 They can be found here:

=C2=A0

https://datatracker.ietf.org/= wg/dots/documents/

=C2=A0

You can track the current discussion = on each of the documents by reading the mailing list.=C2=A0 Document update= s not yet published can be found in github:

=C2=A0

https://github.com/dotswg/

=C2=A0

The working group is also always seek= ing feedback from implementations.=C2=A0 Current work is documented here:

=C2=A0

https://trac.ietf.org/trac/dots/wiki=

=C2=A0

To learn how IETF processes work, con= sult The Tao of the IETF:

=C2=A0

https://www.ietf.org/tao.html

=C2=A0

If you have more questions, please ju= st ask.

=C2=A0

Roman

<= span style=3D"font-size:11.0pt;font-family:"Calibri",sans-serif;c= olor:#1f497d">=C2=A0

From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Lucas Matheus
Sent: Wednesday, March 28, 2018 8:08 AM
To: dots@ietf.org=
Subject: [Dots] Hi, I=C2=B4m new

=C2=A0

Hello guys,

=C2=A0=

I'm new t= o this working group and IETF community.=C2=A0I want to contribute to the f= ormation of new standards=C2=A0and the advancement of the internet.=C2=A0 I'm a graduate student in computing in Brazil.

How do I cont= ribute to this WG?

Can anyone he= lp me in those first steps?

=C2=A0=

Thank you<= /u>

=C2=A0


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


--000000000000b6d80f056879ea15-- From nobody Thu Mar 29 04:44: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 8078F12DA05 for ; Thu, 29 Mar 2018 04:44:28 -0700 (PDT) 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 YpQVSoDR2Fe5 for ; Thu, 29 Mar 2018 04:44:26 -0700 (PDT) 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 6EA851200B9 for ; Thu, 29 Mar 2018 04:44:26 -0700 (PDT) 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 w2TBiNnr021336 for ; Thu, 29 Mar 2018 07:44:23 -0400 DKIM-Filter: OpenDKIM Filter v2.11.0 taper.sei.cmu.edu w2TBiNnr021336 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cert.org; s=yc2bmwvrj62m; t=1522323863; bh=gz+TWsoeFk8ZJmStfeaFxpPWrEA83QLCN+MSw58lvoA=; h=From:To:Subject:Date:From; b=QcW2xan3D1K1Wp+mnXqG+EVw8hTC0GCsQBpo8tMotfZjBMe5BIJVMExQKG/vh/8bp /52GRG4RT3SyBDjzDpGwnBQ3kYXPJBIjFSVrwUXESd6rDjy9VESWYltijYhEW3xlFT cJXKD0kG6WETNtiJoDmnhVxakGaHzfGpP9no7aj4= 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 w2TBiIHp005351 for ; Thu, 29 Mar 2018 07:44:18 -0400 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, 29 Mar 2018 07:44:18 -0400 From: Roman Danyliw To: "dots@ietf.org" Thread-Topic: Reminder -- RE: Second WGLC on DOTS Requirements Thread-Index: AdPHUx1uV7kt/EM9SgiPI6YX09np6A== Date: Thu, 29 Mar 2018 11:44:18 +0000 Message-ID: <359EC4B99E040048A7131E0F4E113AFC014C373711@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 -- RE: Second 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, 29 Mar 2018 11:44:28 -0000 Hello! As a reminder, this WGLC closes on April 4, 2018. Please provide any comme= nts by then. Thank, Roman > -----Original Message----- > From: Dots [mailto:dots-bounces@ietf.org] On Behalf Of Roman Danyliw > Sent: Wednesday, March 21, 2018 6:16 AM > To: dots@ietf.org > Subject: [Dots] Second WGLC on DOTS Requirements >=20 > Hello! >=20 > Consistent with our discussion at the London meeting, we are starting a s= econd > working group last call (WGLC) for the DOTS Requirements draft: >=20 > Distributed Denial of Service (DDoS) Open Threat Signaling Requirements > draft-ietf-dots-requirements-14 > https://tools.ietf.org/html/draft-ietf-dots-requirements-14 >=20 > Please send comments to the DOTS mailing list. The WG welcomes feedback > on needed changes as well as endorsements that this draft is ready. >=20 > This second WGLC will end on April 4, 2018. >=20 > Thanks, > Roman >=20 > _______________________________________________ > Dots mailing list > Dots@ietf.org > https://www.ietf.org/mailman/listinfo/dots From nobody Thu Mar 29 06:03:08 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 469DF1267BB; Thu, 29 Mar 2018 06:03:02 -0700 (PDT) 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.76.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152232858223.9188.4348095145078395761@ietfa.amsl.com> Date: Thu, 29 Mar 2018 06:03:02 -0700 Archived-At: Subject: [Dots] I-D Action: draft-ietf-dots-data-channel-14.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, 29 Mar 2018 13:03:02 -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-14.txt Pages : 56 Date : 2018-03-29 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 these statements 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" (used to be [I-D.ietf-dots-signal-channel]) o "RFC ZZZZ: Network Access Control List (ACL) YANG Data Model" (used to be [I-D.ietf-netmod-acl-model]) Please update the "revision" date of the YANG module. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dots-data-channel/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-dots-data-channel-14 https://datatracker.ietf.org/doc/html/draft-ietf-dots-data-channel-14 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dots-data-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/ From nobody Thu Mar 29 06:07: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 1601712D88F for ; Thu, 29 Mar 2018 06:07:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.609 X-Spam-Level: X-Spam-Status: No, score=-2.609 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 O7sRKV1lx6rg for ; Thu, 29 Mar 2018 06:07:01 -0700 (PDT) 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 CD81112D951 for ; Thu, 29 Mar 2018 06:07:00 -0700 (PDT) Received: from opfednr02.francetelecom.fr (unknown [xx.xx.xx.66]) by opfednr22.francetelecom.fr (ESMTP service) with ESMTP id 8503620800 for ; Thu, 29 Mar 2018 15:06:59 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.69]) by opfednr02.francetelecom.fr (ESMTP service) with ESMTP id 6D6B812006B for ; Thu, 29 Mar 2018 15:06:59 +0200 (CEST) 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; Thu, 29 Mar 2018 15:06:59 +0200 From: To: "dots@ietf.org" Thread-Topic: I-D Action: draft-ietf-dots-data-channel-14.txt Thread-Index: AQHTx15RTzQ1qeUcEkaew1RMNXCy1qPnLlJA Date: Thu, 29 Mar 2018 13:06:58 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93302DEF4B32@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <152232858223.9188.4348095145078395761@ietfa.amsl.com> In-Reply-To: <152232858223.9188.4348095145078395761@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-data-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: Thu, 29 Mar 2018 13:07:03 -0000 Hi all,=20 The new version integrates the comments received so far and implements the = conclusions of the issues discussed on the mailing list.=20 Please review and share your comments.=20 Cheers, Med > -----Message d'origine----- > De=A0: I-D-Announce [mailto:i-d-announce-bounces@ietf.org] De la part de > internet-drafts@ietf.org > Envoy=E9=A0: jeudi 29 mars 2018 15:03 > =C0=A0: i-d-announce@ietf.org > Cc=A0: dots@ietf.org > Objet=A0: I-D Action: draft-ietf-dots-data-channel-14.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-14.txt > Pages : 56 > Date : 2018-03-29 >=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 these statements 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" (used to be > [I-D.ietf-dots-signal-channel]) >=20 > o "RFC ZZZZ: Network Access Control List (ACL) YANG Data Model" > (used to be [I-D.ietf-netmod-acl-model]) >=20 > Please update the "revision" date of the YANG module. >=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-14 > https://datatracker.ietf.org/doc/html/draft-ietf-dots-data-channel-14 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dots-data-channel-14 >=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