From nobody Mon Mar 2 00:31:38 2020 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 8D20D3A0FCB; Mon, 2 Mar 2020 00:31:35 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: dots@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.119.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: dots@ietf.org Message-ID: <158313789545.21225.8584305619220219100@ietfa.amsl.com> Date: Mon, 02 Mar 2020 00:31:35 -0800 Archived-At: Subject: [Dots] I-D Action: draft-ietf-dots-signal-filter-control-03.txt X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.29 List-Id: "List for 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, 02 Mar 2020 08:31:36 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DDoS Open Threat Signaling WG of the IETF. Title : Controlling Filtering Rules Using Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal Channel Authors : Kaname Nishizuka Mohamed Boucadair Tirumaleswar Reddy Takahiko Nagata Filename : draft-ietf-dots-signal-filter-control-03.txt Pages : 26 Date : 2020-03-02 Abstract: This document specifies an extension to the DOTS signal channel protocol so that DOTS clients can control their filtering rules when an attack mitigation is active. Particularly, this extension allows a DOTS client to activate or de- activate existing filtering rules during a DDoS attack. The characterization of these filtering rules is supposed to be conveyed by a DOTS client during an idle time by means of the DOTS data channel protocol. Editorial Note (To be removed by RFC Editor) Please update these statements within the document with the RFC number to be assigned to this document: o "This version of this YANG module is part of RFC XXXX;" o "RFC XXXX: Controlling Filtering Rules Using Distributed Denial- of-Service Open Threat Signaling (DOTS) Signal Channel"; o reference: RFC XXXX o [RFCXXXX] Please update these statements with the RFC number to be assigned to the following documents: o "RFC SSSS: Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal Channel Specification" (used to be [I-D.ietf-dots-signal-channel]) o "RFC DDDD: Distributed Denial-of-Service Open Threat Signaling (DOTS) Data Channel Specification" (used to be [I-D.ietf-dots-data-channel]) Please update the "revision" date of the YANG module. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dots-signal-filter-control/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-dots-signal-filter-control-03 https://datatracker.ietf.org/doc/html/draft-ietf-dots-signal-filter-control-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dots-signal-filter-control-03 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 2 00:48:07 2020 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 314D43A1010 for ; Mon, 2 Mar 2020 00:48:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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=orange.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 1CjffNFK1THl for ; Mon, 2 Mar 2020 00:48:03 -0800 (PST) Received: from relais-inet.orange.com (relais-inet.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 46AB73A100F for ; Mon, 2 Mar 2020 00:48:03 -0800 (PST) Received: from opfedar04.francetelecom.fr (unknown [xx.xx.xx.6]) by opfedar26.francetelecom.fr (ESMTP service) with ESMTP id 48WDLT61c5zFq3J; Mon, 2 Mar 2020 09:48:01 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1583138881; bh=F2zZag5qQo0Gsv7vwyKBsKJ9CWFPHMJcYFxjh6+D0bg=; h=From:To:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=gxQY5tTqRUgLz5NQ9ajzgVQsQyGX/H8gSQQYZnraqnXzPQOigEHwYnwHm8A+dNV66 v+D41WFlKZfY4Lgh88xQ6Kkz+5+HzpH8lh+Z7YBkCGb6BCF8p96Ovdrc6yDmGy1yQM C6Wl1y+3MbcCrF2kQzmyQegBWrTuB/ng+5RXAWi/0U1FzNHyk/9jcroFEXT+zwi3Sb o8gfgyKdzPip2BN2r0rCwe1F8waKtK0nXhx9xGO47/avDbAkF+U6YHP2MBM71dD5bR OzjFHXULPF31W+lIa8STrFwsTZxYPhaGAuLso0lmQcCkltAdp5xp8etZKKbo0oR+6I cFsOzL1XIp69A== Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.35]) by opfedar04.francetelecom.fr (ESMTP service) with ESMTP id 48WDLT59JLz1xpr; Mon, 2 Mar 2020 09:48:01 +0100 (CET) Received: from OPEXCAUBMA2.corporate.adroot.infra.ftgroup ([fe80::e878:bd0:c89e:5b42]) by OPEXCAUBM6C.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0487.000; Mon, 2 Mar 2020 09:48:01 +0100 From: To: "dots@ietf.org" CC: "Benjamin Kaduk (kaduk@mit.edu)" Thread-Topic: [Dots] I-D Action: draft-ietf-dots-signal-filter-control-03.txt Thread-Index: AQHV8G0D+V9uLllelUmwgEF929JY06g0+wiA Date: Mon, 2 Mar 2020 08:48:01 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93303145B38E@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> References: <158313789545.21225.8584305619220219100@ietfa.amsl.com> In-Reply-To: <158313789545.21225.8584305619220219100@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.114.13.247] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Dots] I-D Action: draft-ietf-dots-signal-filter-control-03.txt X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Mar 2020 08:48:05 -0000 Hi all,=20 As discussed in the DOTS telemetry thread, this version registers "ietf-dot= s-signal-control:acl-list" and " ietf-dots-signal-control:acl-name" rather = than using the key values already assigned to "acl-list" and "acl-name". I prefer to fix this now so that Ben can use this version for his review.=20 Cheers, Med > -----Message d'origine----- > De=A0: Dots [mailto:dots-bounces@ietf.org] De la part de internet- > drafts@ietf.org > Envoy=E9=A0: lundi 2 mars 2020 09:32 > =C0=A0: i-d-announce@ietf.org > Cc=A0: dots@ietf.org > Objet=A0: [Dots] I-D Action: draft-ietf-dots-signal-filter-control- > 03.txt >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the DDoS Open Threat Signaling WG of the > IETF. >=20 > Title : Controlling Filtering Rules Using > Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal > Channel > Authors : Kaname Nishizuka > Mohamed Boucadair > Tirumaleswar Reddy > Takahiko Nagata > Filename : draft-ietf-dots-signal-filter-control-03.txt > Pages : 26 > Date : 2020-03-02 >=20 > Abstract: > This document specifies an extension to the DOTS signal channel > protocol so that DOTS clients can control their filtering rules > when > an attack mitigation is active. >=20 > Particularly, this extension allows a DOTS client to activate or > de- > activate existing filtering rules during a DDoS attack. The > characterization of these filtering rules is supposed to be > conveyed > by a DOTS client during an idle time by means of the DOTS data > channel protocol. >=20 > Editorial Note (To be removed by RFC Editor) >=20 > Please update these statements within the document 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: Controlling Filtering Rules Using Distributed Denial- > of-Service Open Threat Signaling (DOTS) Signal Channel"; >=20 > o reference: RFC XXXX >=20 > o [RFCXXXX] >=20 > Please update these statements with the RFC number to be assigned > to > the following documents: >=20 > o "RFC SSSS: Distributed Denial-of-Service Open Threat Signaling > (DOTS) Signal Channel Specification" (used to be > [I-D.ietf-dots-signal-channel]) >=20 > o "RFC DDDD: Distributed Denial-of-Service Open Threat Signaling > (DOTS) Data Channel Specification" (used to be > [I-D.ietf-dots-data-channel]) >=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-signal-filter- > control/ >=20 > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-dots-signal-filter-control-03 > https://datatracker.ietf.org/doc/html/draft-ietf-dots-signal-filter- > control-03 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dots-signal-filter- > control-03 >=20 >=20 > Please note that it may take a couple of minutes from the time of > submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 >=20 > _______________________________________________ > Dots mailing list > Dots@ietf.org > https://www.ietf.org/mailman/listinfo/dots From nobody Mon Mar 2 01:20:13 2020 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 BB15E3A1095; Mon, 2 Mar 2020 01:20:06 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: dots@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.119.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: dots@ietf.org Message-ID: <158314080667.21883.7273061359054440668@ietfa.amsl.com> Date: Mon, 02 Mar 2020 01:20:06 -0800 Archived-At: Subject: [Dots] I-D Action: draft-ietf-dots-signal-call-home-08.txt X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.29 List-Id: "List for 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, 02 Mar 2020 09:20:07 -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 Call Home Authors : Tirumaleswar Reddy Mohamed Boucadair Jon Shallow Filename : draft-ietf-dots-signal-call-home-08.txt Pages : 37 Date : 2020-03-02 Abstract: This document specifies the DOTS signal channel Call Home, which enables a DOTS server to initiate a secure connection to a DOTS client, and to receive the attack traffic information from the DOTS client. The DOTS server in turn uses the attack traffic information to identify the compromised devices launching the outgoing DDoS attack and takes appropriate mitigation action(s). The DOTS signal channel Call Home is not specific to the home networks; the solution targets any deployment which requires to block DDoS attack traffic closer to the source(s) of a DDoS attack. Editorial Note (To be removed by RFC Editor) Please update these statements within the document with the RFC number to be assigned to this document: o "This version of this YANG module is part of RFC XXXX;" o "RFC XXXX: Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal Channel Call Home"; o "| [RFCXXXX] |" o reference: RFC XXXX Please update this statement with the RFC number to be assigned to the following documents: o "RFC YYYY: Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal Channel Specification (used to be I-D.ietf-dots- signal-channel) Please update TBD statements with the assignment made by IANA to DOTS Signal Channel Call Home. 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-call-home/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-dots-signal-call-home-08 https://datatracker.ietf.org/doc/html/draft-ietf-dots-signal-call-home-08 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dots-signal-call-home-08 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Mar 2 01:23:53 2020 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 A495F3A10AE for ; Mon, 2 Mar 2020 01:23:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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=orange.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 cRyOl8nCSpxQ for ; Mon, 2 Mar 2020 01:23:50 -0800 (PST) Received: from relais-inet.orange.com (relais-inet.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 76C923A10AC for ; Mon, 2 Mar 2020 01:23:50 -0800 (PST) Received: from opfednr06.francetelecom.fr (unknown [xx.xx.xx.70]) by opfednr22.francetelecom.fr (ESMTP service) with ESMTP id 48WF7m5Yx0zys3; Mon, 2 Mar 2020 10:23:48 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1583141028; bh=gu2W+ZnCpTrXRtxJomr0rMD+QEy6P4B3E2B1wTVnHvo=; h=From:To:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=Vk4dx3KYQtcFSEo5KMQt+0vVkCp+a09wc6KgcjX5rSeeFx17ZJXGDWIngEiRlDAQE Bk1cKMRkiS5DjGQlJftsVEtzppWY+klEpL02w/qrpp+GkrUZ8f6ID2EoAk8TYppyX4 Upb/bH3+aMxty5GamBx6dGm8MCtTiHojnLmGyXzmHKsYnAyzzDl/MDjWLDIcBVjYZG rCsWRok4/XTbJtlNw8UW9VoSErCxpg8fVQR2iTvjcqb6ijP6DTO+DgmHJ0BwMG1SzF 0tJ6MClYJyHgR123Zdiu13eBwAAIMy8EellahhP7NBE5lug8KV8LU+yCAJLrTOY260 YUF4FjG6vmq/A== Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.79]) by opfednr06.francetelecom.fr (ESMTP service) with ESMTP id 48WF7m4wFvzDq80; Mon, 2 Mar 2020 10:23:48 +0100 (CET) Received: from OPEXCAUBMA2.corporate.adroot.infra.ftgroup ([fe80::e878:bd0:c89e:5b42]) by OPEXCAUBM6E.corporate.adroot.infra.ftgroup ([fe80::d89a:9017:59c2:9724%21]) with mapi id 14.03.0487.000; Mon, 2 Mar 2020 10:23:48 +0100 From: To: "dots@ietf.org" CC: "Benjamin Kaduk (kaduk@mit.edu)" Thread-Topic: I-D Action: draft-ietf-dots-signal-call-home-08.txt Thread-Index: AQHV8HPV7XiwHXDK50OpGr69hLpGK6g1BtVA Date: Mon, 2 Mar 2020 09:23:48 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93303145B3ED@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> References: <158314080667.21883.7273061359054440668@ietfa.amsl.com> In-Reply-To: <158314080667.21883.7273061359054440668@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.114.13.247] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Dots] I-D Action: draft-ietf-dots-signal-call-home-08.txt X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Mar 2020 09:23:53 -0000 Hi all, The IANA section is updated to be aligned with the outcome of the DOTS tele= metry discussion. Attributes are prefixes with the name of the module.=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: lundi 2 mars 2020 10:20 > =C0=A0: i-d-announce@ietf.org > Cc=A0: dots@ietf.org > Objet=A0: I-D Action: draft-ietf-dots-signal-call-home-08.txt >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the DDoS Open Threat Signaling WG of the > IETF. >=20 > Title : Distributed Denial-of-Service Open Threat > Signaling (DOTS) Signal Channel Call Home > Authors : Tirumaleswar Reddy > Mohamed Boucadair > Jon Shallow > Filename : draft-ietf-dots-signal-call-home-08.txt > Pages : 37 > Date : 2020-03-02 >=20 > Abstract: > This document specifies the DOTS signal channel Call Home, which > enables a DOTS server to initiate a secure connection to a DOTS > client, and to receive the attack traffic information from the DOTS > client. The DOTS server in turn uses the attack traffic > information > to identify the compromised devices launching the outgoing DDoS > attack and takes appropriate mitigation action(s). >=20 > The DOTS signal channel Call Home is not specific to the home > networks; the solution targets any deployment which requires to > block > DDoS attack traffic closer to the source(s) of a DDoS attack. >=20 > Editorial Note (To be removed by RFC Editor) >=20 > Please update these statements within the document with the RFC > number to be assigned to this document: >=20 > o "This version of this YANG module is part of RFC XXXX;" >=20 > o "RFC XXXX: Distributed Denial-of-Service Open Threat Signaling > (DOTS) Signal Channel Call Home"; >=20 > o "| [RFCXXXX] |" >=20 > o reference: RFC XXXX >=20 > Please update this statement with the RFC number to be assigned to > the following documents: >=20 > o "RFC YYYY: Distributed Denial-of-Service Open Threat Signaling > (DOTS) Signal Channel Specification (used to be I-D.ietf-dots- > signal-channel) >=20 > Please update TBD statements with the assignment made by IANA to > DOTS > Signal Channel Call Home. >=20 > Also, 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-signal-call-home/ >=20 > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-dots-signal-call-home-08 > https://datatracker.ietf.org/doc/html/draft-ietf-dots-signal-call- > home-08 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dots-signal-call-home-08 >=20 >=20 > Please note that it may take a couple of minutes from the time of > submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 >=20 > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From nobody Mon Mar 2 03:11:34 2020 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 11B603A086D for ; Mon, 2 Mar 2020 03:11:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, 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 G96f-gA72_Y6 for ; Mon, 2 Mar 2020 03:11:30 -0800 (PST) Received: from mail-oi1-x235.google.com (mail-oi1-x235.google.com [IPv6:2607:f8b0:4864:20::235]) (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 E27623A086C for ; Mon, 2 Mar 2020 03:11:29 -0800 (PST) Received: by mail-oi1-x235.google.com with SMTP id t24so2680809oij.3 for ; Mon, 02 Mar 2020 03:11:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :content-transfer-encoding; bh=Uz6kn7fqh6wXI5kPWtcj7s1y+bQOmWzDz/XeTwdMw7w=; b=tUw0yvpxT3mu6YAlCH2mY3vcJISIhrXV/XOLROC6K3pcQFh3X0o9yA7F4NGjg+BwNs ju8eYFRGAxsbnD5rAwzoioD+qfJN91mkfS2XYB2Q+RFu7RWMon6aM9yeUKJyBDj/BFCh u7VF1q8vrq6KLw/UAXjlfo7ugbz5sYHN2bNapPoXGYRaBa/h3dfeuZqGT1RQ46iSARcS KtVK4R/PvVYNBxIpWhHO80ho528r3QwMJNX/4ypolzsIyDGoDCCDES2z+5POmoZGmaWD i0bfo2QqdzCqX+sWXHP67dUyigP1fsfh/E6ooprL9pKG7fuPT0pRF1DJ20G/st79pTun bfCw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:content-transfer-encoding; bh=Uz6kn7fqh6wXI5kPWtcj7s1y+bQOmWzDz/XeTwdMw7w=; b=B32I+nBwnvwlqDVuqyuS1wby9AoUrS92hmngbjfZQ0Lf5M32qD0EXfqpnqB2C+PDES Om/kKR6oyaMbidqlrRwUQ/Q3ACfSqdgLK3bYSi2FDIqQVEx8LHIEd0qENN4zntlX9+EE QH3gmNFNFKQJpJr0il5arbMJF0qjPo3ikgBCTQY5xpE2g686g5CwjoURhi5Ycoo6uhsS xN7iJP2Z3JV8dlnLNF/43dYSdjUtWFvEgr/rOIQULYnNPYQRNQmK4nvrDRpIbfgtCLVE /Vm9f0j+EWCbNdzsUG08Lsqf/SU2djA6ergpo73q96Y63Ep3wKcTG38pJZvEG+5oFIqk M/sw== X-Gm-Message-State: ANhLgQ2oQ6N7SKaXGkzalq8v/NI+0dSYo8BdAfvBQZmHUTxmeMiWvvRK jt4Kx0IIME5an3Xh1i+yZLCUI5Vm6EguA6xX+KwqPha1 X-Google-Smtp-Source: ADFU+vvEpzOSEOOOzjlymhySQRm3TNTer7WvecAM7HaOlSBfEPIw5a28x5GnoYfqluim+hqwYKi2sadxRBS1QQDu1qY= X-Received: by 2002:aca:110f:: with SMTP id 15mr377500oir.114.1583147488774; Mon, 02 Mar 2020 03:11:28 -0800 (PST) MIME-Version: 1.0 References: <158314699648.20483.11088240536435242028@ietfa.amsl.com> In-Reply-To: <158314699648.20483.11088240536435242028@ietfa.amsl.com> From: H Y Date: Mon, 2 Mar 2020 20:11:19 +0900 Message-ID: To: dots Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: [Dots] Fwd: I-D Action: draft-hayashi-dots-telemetry-use-cases-00.txt X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Mar 2020 11:11:32 -0000 Hi all, As I promised at IETF 106, I wrote DOTS Telemetry use case draft. https://datatracker.ietf.org/doc/minutes-106-dots/ # Meiling, thank you for your help! Comments, suggestions, and questions are more than welcome. We are also looking for co-authors. :-) Thanks, Yuhei ---------- Forwarded message --------- From: Date: 2020=E5=B9=B43=E6=9C=882=E6=97=A5(=E6=9C=88) 20:03 Subject: I-D Action: draft-hayashi-dots-telemetry-use-cases-00.txt To: A New Internet-Draft is available from the on-line Internet-Drafts director= ies. Title : Use Cases for DDoS Open Threat Signaling (DOTS) Telemetry Authors : Yuhei Hayashi Meiling Chen Filename : draft-hayashi-dots-telemetry-use-cases-00.txt Pages : 14 Date : 2020-03-02 Abstract: Denial-of-service Open Threat Signaling (DOTS) Telemetry enriches the base DOTS protocols to assist the mitigator in using efficient DDoS- attack-mitigation techniques in a network. This document presents sample use cases for DOTS Telemetry: what components are deployed in the network, how they cooperate, and what information is exchanged to effectively use these techniques. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-hayashi-dots-telemetry-use-cases/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-hayashi-dots-telemetry-use-cases-00 https://datatracker.ietf.org/doc/html/draft-hayashi-dots-telemetry-use-case= s-00 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/ _______________________________________________ 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 -- ---------------------------------- Yuuhei HAYASHI 08065300884 yuuhei.hayashi@gmail.com iehuuy_0220@docomo.ne.jp ---------------------------------- From nobody Mon Mar 2 04:55:35 2020 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 E15493A0AD8; Mon, 2 Mar 2020 04:55:21 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: dots@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.119.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: dots@ietf.org Message-ID: <158315372184.27406.1842679318468497719@ietfa.amsl.com> Date: Mon, 02 Mar 2020 04:55:21 -0800 Archived-At: Subject: [Dots] I-D Action: draft-ietf-dots-telemetry-03.txt X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.29 List-Id: "List for 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, 02 Mar 2020 12:55:22 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DDoS Open Threat Signaling WG of the IETF. Title : Distributed Denial-of-Service Open Threat Signaling (DOTS) Telemetry Authors : Mohamed Boucadair Tirumaleswar Reddy Ehud Doron Meiling Chen Filename : draft-ietf-dots-telemetry-03.txt Pages : 79 Date : 2020-03-02 Abstract: This document aims to enrich DOTS signal channel protocol with various telemetry attributes allowing optimal DDoS attack mitigation. This document specifies the normal traffic baseline and attack traffic telemetry attributes a DOTS client can convey to its DOTS server in the mitigation request, the mitigation status telemetry attributes a DOTS server can communicate to a DOTS client, and the mitigation efficacy telemetry attributes a DOTS client can communicate to a DOTS server. The telemetry attributes can assist the mitigator to choose the DDoS mitigation techniques and perform optimal DDoS attack mitigation. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dots-telemetry/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-dots-telemetry-03 https://datatracker.ietf.org/doc/html/draft-ietf-dots-telemetry-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dots-telemetry-03 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 2 05:10:39 2020 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 04EC53A0B74 for ; Mon, 2 Mar 2020 05:10:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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=orange.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 Q0MjS8t0ngaZ for ; Mon, 2 Mar 2020 05:10:30 -0800 (PST) Received: from relais-inet.orange.com (relais-inet.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 3349F3A0B68 for ; Mon, 2 Mar 2020 05:10:30 -0800 (PST) Received: from opfedar04.francetelecom.fr (unknown [xx.xx.xx.6]) by opfedar20.francetelecom.fr (ESMTP service) with ESMTP id 48WL9J3yHZz8sjR for ; Mon, 2 Mar 2020 14:10:28 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1583154628; bh=Dg+1bl0tg9izApeutR2xbZdQ7cpTLSlZBvtV0SDhDZQ=; h=From:To:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=kp8hTqLKwCPJneKV4ejXwnKELU663de0+tlMtN3ECpRZgMaaCjQDCRYM4/PvpY9S8 mjgC/Mz0S01bnA/uOZgMZLXyVqDlQdlt2jhyewVpjwoLiQhv9exwsR/p25VBUe0DJU 2dLtS/ypP+1LGB8zJyLFGSnJPXc3iyO3nlbWis9k6JImEt1X5ALC5fZ16AmuvNcjX5 XMTOZ+5orzKezKFgrpO2KFefJUNw3kQIRyXVfaSMLm+DUxTNajwFlSsZpyjFQ2nzu4 oAtXPVppCci/b+ZFRLmRvdEVlYvTu59qx1hIfWttPVh3JV1SLQ3XwlJGjFSFad3yNf TSNTwlrJPORqg== Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.107]) by opfedar04.francetelecom.fr (ESMTP service) with ESMTP id 48WL9J37k5z1xpb for ; Mon, 2 Mar 2020 14:10:28 +0100 (CET) Received: from OPEXCAUBMA2.corporate.adroot.infra.ftgroup ([fe80::e878:bd0:c89e:5b42]) by OPEXCAUBM8F.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0487.000; Mon, 2 Mar 2020 14:10:28 +0100 From: To: "dots@ietf.org" Thread-Topic: I-D Action: draft-ietf-dots-telemetry-03.txt Thread-Index: AQHV8JHiGPzKfwEktUGxPAc6lzaOvqg1RUiA Date: Mon, 2 Mar 2020 13:10:27 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93303145B63A@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> References: <158315372184.27406.1842679318468497719@ietfa.amsl.com> In-Reply-To: <158315372184.27406.1842679318468497719@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.114.13.247] 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-telemetry-03.txt X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Mar 2020 13:10:37 -0000 Re-, This version integrates the following changes: * clarify why we are using enumerations instead of identities. * allow for a telemetry request to include a pointer mitigation requests. * update the CBOR key values table to request whenever it makes sense for "= X" and " ietf-dots-telemetry:X". 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: lundi 2 mars 2020 13:55 > =C0=A0: i-d-announce@ietf.org > Cc=A0: dots@ietf.org > Objet=A0: I-D Action: draft-ietf-dots-telemetry-03.txt >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the DDoS Open Threat Signaling WG of the > IETF. >=20 > Title : Distributed Denial-of-Service Open Threat > Signaling (DOTS) Telemetry > Authors : Mohamed Boucadair > Tirumaleswar Reddy > Ehud Doron > Meiling Chen > Filename : draft-ietf-dots-telemetry-03.txt > Pages : 79 > Date : 2020-03-02 >=20 > Abstract: > This document aims to enrich DOTS signal channel protocol with > various telemetry attributes allowing optimal DDoS attack > mitigation. > This document specifies the normal traffic baseline and attack > traffic telemetry attributes a DOTS client can convey to its DOTS > server in the mitigation request, the mitigation status telemetry > attributes a DOTS server can communicate to a DOTS client, and the > mitigation efficacy telemetry attributes a DOTS client can > communicate to a DOTS server. The telemetry attributes can assist > the mitigator to choose the DDoS mitigation techniques and perform > optimal DDoS attack mitigation. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-dots-telemetry/ >=20 > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-dots-telemetry-03 > https://datatracker.ietf.org/doc/html/draft-ietf-dots-telemetry-03 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dots-telemetry-03 >=20 >=20 > Please note that it may take a couple of minutes from the time of > submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 >=20 > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From nobody Fri Mar 6 21:50:24 2020 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 6BE073A0A47; Fri, 6 Mar 2020 21:49:54 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: dots@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.119.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: dots@ietf.org Message-ID: <158356019436.2278.3714378093356500843@ietfa.amsl.com> Date: Fri, 06 Mar 2020 21:49:54 -0800 Archived-At: Subject: [Dots] I-D Action: draft-ietf-dots-architecture-18.txt X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.29 List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Mar 2020 05:49:55 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DDoS Open Threat Signaling WG of the IETF. Title : Distributed-Denial-of-Service Open Threat Signaling (DOTS) Architecture Authors : Andrew Mortensen Tirumaleswar Reddy Flemming Andreasen Nik Teague Rich Compton Filename : draft-ietf-dots-architecture-18.txt Pages : 36 Date : 2020-03-06 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-18 https://datatracker.ietf.org/doc/html/draft-ietf-dots-architecture-18 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dots-architecture-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 11 03:30:38 2020 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 8DE883A1679 for ; Wed, 11 Mar 2020 03:30:35 -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, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, 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=nttv6.jp 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 9mUDst2yFEzx for ; Wed, 11 Mar 2020 03:30:31 -0700 (PDT) Received: from guri.nttv6.jp (guri.nttv6.jp [115.69.228.140]) by ietfa.amsl.com (Postfix) with ESMTP id 489D33A1677 for ; Wed, 11 Mar 2020 03:30:30 -0700 (PDT) Received: from z.nttv6.jp (z.nttv6.jp [IPv6:2402:c800:ff06:6::f]) by guri.nttv6.jp (NTTv6MTA) with ESMTP id 724AB25F6B8; Wed, 11 Mar 2020 19:30:29 +0900 (JST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nttv6.jp; s=20180820; t=1583922629; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=N8vMl+aB5Hdz/3Xn7zzbCk72IpsVFIYKQBotgy2VKmo=; b=CHkPfD1d+WHhUxiaTCbIDn2PG/njctUijEwig+Z/GYtFUlxTkCg3q/Dx9soBl6SJk6bCau 2KtupMgjuFbfgcRrmS2EROQV5DeFVaXoBJxLAJ+5MF3CUbwgwBwSFEfq6bzJV7LFLO0IxO lonKa30Gn+PfGE/tCVpTKSk3j6u+r1g= Received: from MacBook-Pro-17.local (fujiko.nttv6.jp [IPv6:2402:c800:ff06:136::141]) by z.nttv6.jp (NTTv6MTA) with ESMTP id 581AA75900F; Wed, 11 Mar 2020 19:30:29 +0900 (JST) To: Jon Shallow , mohamed.boucadair@orange.com, "Konda, Tirumaleswar Reddy" , dots@ietf.org References: <188801d5e830$635d97d0$2a18c770$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93303143DAF8@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <191b01d5e8a8$886d1e60$99475b20$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93303143DE2E@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <197301d5e8cd$f31384a0$d93a8de0$@jpshallow.com> From: kaname nishizuka Message-ID: <559c1aa6-255d-4f1a-c513-87944995774f@nttv6.jp> Date: Wed, 11 Mar 2020 19:30:28 +0900 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:68.0) Gecko/20100101 Thunderbird/68.5.0 MIME-Version: 1.0 In-Reply-To: <197301d5e8cd$f31384a0$d93a8de0$@jpshallow.com> Content-Type: multipart/alternative; boundary="------------8347B590A9C0DADAF41070C3" Content-Language: en-US Authentication-Results: guri.nttv6.jp; spf=pass smtp.mailfrom=kaname@nttv6.jp Archived-At: Subject: Re: [Dots] DOTS telemetry questions X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Mar 2020 10:30:36 -0000 This is a multi-part message in MIME format. --------------8347B590A9C0DADAF41070C3 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Hi, With regard to 4) Proposal: change MUST to SHOULD here. ``` DOTS agents MUST bind pre-mitigation telemetry data with mitigation    requests relying upon the target clause. (snip)  An example illustrating requests correlation by means of 'target-prefix'    is shown in Figure 22. ``` It is acceptable to relax this bind especially in the case of Figure 22 from operational perspective. In this case, Pre-mitigation telemetry from the DOTS server to the client can be a hint to the upcoming mitigation request. But it's not necessary to use the same prefix if an operator of the DOTS client wanted to do so. Like that, it's not necessary to correlate this pre-mitigation telemetry and the mitigation request from the view point of the DOTS server because acknowledging there is the correlation will not affect the behavior of the DOTS server. But, It IS necessary to correlate the mitigation request by mid with further telemetry information from DOTS server (maybe namely "post-mitigation" telemetry). regards, Kaname On 2020/02/22 0:45, Jon Shallow wrote: > > Hi, > > See inline Jon1> > > Regards > > Jon > > *From:*Dots [mailto: dots-bounces@ietf.org] *On Behalf Of *mohamed.boucadair@orange.com > *Sent:* 21 February 2020 13:32 > *To:* Jon Shallow; Konda, Tirumaleswar Reddy; kaname nishizuka; dots@ietf.org > *Subject:* Re: [Dots] DOTS telemetry questions > > Re-, > > Please see inline. > > Cheers, > > Med > > *De :*Jon Shallow [mailto:supjps-ietf@jpshallow.com] > *Envoyé :* vendredi 21 février 2020 12:18 > *À :* BOUCADAIR Mohamed TGI/OLN; Konda, Tirumaleswar Reddy; kaname nishizuka; dots@ietf.org > *Objet :* RE: [Dots] DOTS telemetry questions > > Hi Med et al, > > See inline Jon> > > Regards > > Jon > > *From:*Dots [mailto: dots-bounces@ietf.org] *On Behalf Of *mohamed.boucadair@orange.com > *Sent:* 21 February 2020 07:00 > *To:* Jon Shallow; Konda, Tirumaleswar Reddy; kaname nishizuka > *Cc:* dots@ietf.org > *Subject:* Re: [Dots] DOTS telemetry questions > > Hi Jon, > > (ccing the WG to track the changes). > > Please see inline. > > Cheers, > > Med > > *De :*Jon Shallow [mailto:supjps-ietf@jpshallow.com] > *Envoyé :* jeudi 20 février 2020 21:58 > *À :* BOUCADAIR Mohamed TGI/OLN; Konda, Tirumaleswar Reddy; kaname nishizuka > *Objet :* DOTS telemetry questions > > Hi Guys, > > 1)For example CBOR mappings > >      Header: PUT (Code=0.03) > >      Uri-Path: ".well-known" > >      Uri-Path: "dots" > >      Uri-Path: "mitigate" > >      Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw" > >      Uri-Path: "mid=123" > >      If-Match: > >      Content-Format: "application/dots+cbor" > >      { > > "ietf-dots-signal-channel:mitigation-scope": { > >         "scope": [ > >           { > > "alias-name": [ > > "myserver" > >              ], > > "attack-status": "under-attack", > >             "*/ietf-dots-telemetry:total-attack-traffic/*": [ > >               { > > "ietf-dots-telemetry:unit": "megabytes-ps", > > "ietf-dots-telemetry:mid-percentile-g": "900" > >               } > >             ] > >           } > >         ] > >       } > >      } > >     Figure 33: An Example of Mitigation Efficacy Update with Telemetry > > Attributes > > And yet the mapping table only has (no ietf-dots-telemetry: prefix) > > | total-attack-traffic | list        |32794 | 4 array       | Array  | > > I appreciate that ietf-dots-telemetry:total-attack-traffic and total-attack traffic are the same CBOR value (or are they?) > > */[Med] The same value is used but I didn’t check if there are side effects. /* > > Jon> Need to think this through.  My implementation maps the CBOR into JSON and then works on the JSON to do what is necessary and then converts the JSON response back into CBOR. > > */[Med] An issue with namespaces will be the encountered if the conversion is the same for the attribute when it is carried in a “pure” telemetry message or in an existing signal channel message./* > > Jon1> Correct – I don’t like the concept of having 2 mapping tables for mapping the CBOR value back into JSON. > > Jon> We  have the same naming issues in draft-ietf-dots-signal-filter-control-00 where we do not have the ietf-dots-signal-control: prefix in the JSON examples (Fig 10) > */[Med] Fig 10 is a “normal” mitigation request. Why should it need to include “ietf-dots-signal-control:” prefix?/* > > Jon1> My bad – I was looking at draft-ietf-dots-signal-filter-control-00, not draft-ietf-dots-signal-filter-control-02. However, https://tools.ietf.org/html/draft-ietf-dots-signal-filter-control-02#section-5.1 only defines “activation-type” without the prefix, and acl-list and acl-name have the incorrect prefix: added to, for example, Figure 1. > > */Please note that we have this note is section 10:/* > > *//* > > */==/* > >    o  Some of these attributes should be prepended with "ietf-dots- > > telemetry:" > > */==/* > > *//* > > but when mapping the CBOR back to JSON the variant of JSON parameter is context (Uri-Path: mitigate or tm) dependent. > > 2)why do we not have a “enum megabit-ps” in “typedef unit” in the YANG Module? > */[Med]  This can be added to the list as ‘units()’ are negotiated. *-bytes are more used for aggregates, but let’s be consistent and have both bit/bytes in the units./* > Jon> Megabytes works with aggregates, megabits works with pipes. > */[Med] I added the unit to the module. BTW, in order to easily define new units, I updated the module so that units are defined as identities, not enumerations. The updated mapping table is: https://github.com/boucadair/draft-dots-telemetry/blob/master/mapping-table.txt (or https://github.com/boucadair/draft-dots-telemetry/blob/master/draft-ietf-dots-telemetry-03.txt) /* > Jon1> Typo in megabite-ps > Jon1> I am not sure about the usage of identityref. https://tools.ietf.org/html/rfc7951#section-6.8 states that the value is represented as a string (currently the CBOR mapping entry says it is an integer), and furthermore it is likely that the namespace-qualified form is required. This is a huge increase in the number of bytes needed whenever unit (and measurement-interval Etc.) are used.  I think that this is a bad change.*//* > 3)I think that I have worked out that server-originated-telemetry if set allows telemetry included in the mitigation status rather than only returned using Uri-path: tm – correct? > */[Med] I confirm. Note that including pre-mitigation returned using “Uri-path:tm” is controlled by PUT/GET (Section 7.3)./* > Jon> Agreed. > > 4)I am confused by “pre-mitigation” which can be transmitted pre any mitigation taking place, or actually during when mitigation is taking place (or so I think) and would simply be better described as “attack-details” – especially with a statement such as > >    DOTS agents MUST bind pre-mitigation telemetry data with mitigation >    requests relying upon the target clause. > *//* > */[Med] That’s an option but the current design allows to have the telemetry in // in order to supply more data ** without impacting the placement of a mitigation request ** hence the need to bind both (if any). If telemetry attributes are defined as mandatory (discussed in another thread), this would mean that the server will reject a mitigation that includes such attributes. With the current design, we have a functionality that can be safely enabled independently of the decision that we will make about whether telemetry attributes are mandatory to be supported or not./* > Jon> My primary point here was the use of the term “pre-mitigation” – this telemetry is also needs during a mitigation and the attack keeps on morphing into something else. > */[Med] I see your point. We will see if we can find a better term./**//* > Jon1> Agreed – it is the “pre” that certainly does not work for me.  Something like “attack information” ? > *//* > *//* > */Another point we can check to ease correlation between a mitigation request and pre-mitigation telemetry is to signal the “mid” in the telemetry message./* > Jon> could be – need to think this through > */[Med] Let’s think about this one further./* > Jon1> Sure – this may come out in the wash as we try to implement this stuff. > Regards > Jon --------------8347B590A9C0DADAF41070C3 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit Hi,

With regard to 4)

Proposal: change MUST to SHOULD here.
```
DOTS agents MUST bind pre-mitigation telemetry data with mitigation
   requests relying upon the target clause.
(snip)
 An example illustrating requests correlation by means of 'target-prefix'
   is shown in Figure 22.
```

It is acceptable to relax this bind especially in the case of Figure 22 from operational perspective.
In this case, Pre-mitigation telemetry from the DOTS server to the client can be a hint to the upcoming mitigation request.
But it's not necessary to use the same prefix if an operator of the DOTS client wanted to do so.
Like that, it's not necessary to correlate this pre-mitigation telemetry and the mitigation request from the view point of the DOTS server because acknowledging there is the correlation will not affect the behavior of the DOTS server.

But, It IS necessary to correlate the mitigation request by mid with further telemetry information from DOTS server (maybe namely "post-mitigation" telemetry).

regards,
Kaname

On 2020/02/22 0:45, Jon Shallow wrote:

Hi,

 

See inline Jon1>

 

Regards

 

Jon

 

From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of mohamed.boucadair@orange.com
Sent: 21 February 2020 13:32
To: Jon Shallow; Konda, Tirumaleswar Reddy; kaname nishizuka; dots@ietf.org
Subject: Re: [Dots] DOTS telemetry questions

 

Re-,

 

Please see inline.

 

Cheers,

Med

 

De : Jon Shallow [mailto:supjps-ietf@jpshallow.com]
Envoyé : vendredi 21 février 2020 12:18
À : BOUCADAIR Mohamed TGI/OLN; Konda, Tirumaleswar Reddy; kaname nishizuka; dots@ietf.org
Objet : RE: [Dots] DOTS telemetry questions

 

Hi Med et al,

 

See inline Jon>

 

Regards

 

Jon

 

From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of mohamed.boucadair@orange.com
Sent: 21 February 2020 07:00
To: Jon Shallow; Konda, Tirumaleswar Reddy; kaname nishizuka
Cc: dots@ietf.org
Subject: Re: [Dots] DOTS telemetry questions

 

Hi Jon,

 

(ccing the WG to track the changes).

 

Please see inline.

 

Cheers,

Med

 

De : Jon Shallow [mailto:supjps-ietf@jpshallow.com]
Envoyé : jeudi 20 février 2020 21:58
À : BOUCADAIR Mohamed TGI/OLN; Konda, Tirumaleswar Reddy; kaname nishizuka
Objet : DOTS telemetry questions

 

Hi Guys,

 

1)      For example CBOR mappings

 

     Header: PUT (Code=0.03)

     Uri-Path: ".well-known"

     Uri-Path: "dots"

     Uri-Path: "mitigate"

     Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw"

     Uri-Path: "mid=123"

     If-Match:

     Content-Format: "application/dots+cbor"

 

     {

      "ietf-dots-signal-channel:mitigation-scope": {

        "scope": [

          {

            "alias-name": [

               "myserver"

             ],

            "attack-status": "under-attack",

            "ietf-dots-telemetry:total-attack-traffic": [

              {

                "ietf-dots-telemetry:unit": "megabytes-ps",

                "ietf-dots-telemetry:mid-percentile-g": "900"

              }

            ]

          }

        ]

      }

     }

 

    Figure 33: An Example of Mitigation Efficacy Update with Telemetry

                                Attributes

 

And yet the mapping table only has (no ietf-dots-telemetry: prefix)

 

    | total-attack-traffic | list        |32794 | 4 array       | Array  |

 

I appreciate that ietf-dots-telemetry:total-attack-traffic and total-attack traffic are the same CBOR value (or are they?)

[Med] The same value is used but I didn’t check if there are side effects.

Jon> Need to think this through.  My implementation maps the CBOR into JSON and then works on the JSON to do what is necessary and then converts the JSON response back into CBOR.

[Med] An issue with namespaces will be the encountered if the conversion is the same for the attribute when it is carried in a “pure” telemetry message or in an existing signal channel message.

Jon1> Correct – I don’t like the concept of having 2 mapping tables for mapping the CBOR value back into JSON.

 

Jon> We  have the same naming issues in draft-ietf-dots-signal-filter-control-00 where we do not have the ietf-dots-signal-control: prefix in the JSON examples (Fig 10)
[Med] Fig 10 is a “normal” mitigation request. Why should it need to include “ietf-dots-signal-control:” prefix?
 

Jon1> My bad – I was looking at draft-ietf-dots-signal-filter-control-00, not draft-ietf-dots-signal-filter-control-02.  However, https://tools.ietf.org/html/draft-ietf-dots-signal-filter-control-02#section-5.1 only defines “activation-type” without the prefix, and acl-list and acl-name have the incorrect prefix: added to, for example, Figure 1.

 

Please note that we have this note is section 10:

 

==

   o  Some of these attributes should be prepended with "ietf-dots-

      telemetry:"

==

 

but when mapping the CBOR back to JSON the variant of JSON parameter is context (Uri-Path: mitigate or tm) dependent.

 
2)      why do we not have a “enum megabit-ps” in “typedef unit” in the YANG Module?
[Med]  This can be added to the list as ‘units()’ are negotiated. *-bytes are more used for aggregates, but let’s be consistent and have both bit/bytes in the units.
Jon> Megabytes works with aggregates, megabits works with pipes.
[Med] I added the unit to the module. BTW, in order to easily define new units, I updated the module so that units are defined as identities, not enumerations. The updated mapping table is: https://github.com/boucadair/draft-dots-telemetry/blob/master/mapping-table.txt (or https://github.com/boucadair/draft-dots-telemetry/blob/master/draft-ietf-dots-telemetry-03.txt) 
Jon1> Typo in megabite-ps
Jon1> I am not sure about the usage of identityref.  https://tools.ietf.org/html/rfc7951#section-6.8 states that the value is represented as a string (currently the CBOR mapping entry says it is an integer), and furthermore it is likely that the namespace-qualified form is required. This is a huge increase in the number of bytes needed whenever unit (and measurement-interval Etc.) are used.  I think that this is a bad change.  
 
3)      I think that I have worked out that server-originated-telemetry if set allows telemetry included in the mitigation status rather than only returned using Uri-path: tm – correct?
[Med] I confirm. Note that including pre-mitigation returned using “Uri-path:tm” is controlled by PUT/GET (Section 7.3).
Jon> Agreed. 

 

4)      I am confused by “pre-mitigation” which can be transmitted pre any mitigation taking place, or actually during when mitigation is taking place (or so I think) and would simply be better described as “attack-details” – especially with a statement such as

 

   DOTS agents MUST bind pre-mitigation telemetry data with mitigation
   requests relying upon the target clause.
 
[Med] That’s an option but the current design allows to have the telemetry in // in order to supply more data ** without impacting the placement of a mitigation request ** hence the need to bind both (if any). If telemetry attributes are defined as mandatory (discussed in another thread), this would mean that the server will reject a mitigation that includes such attributes. With the current design, we have a functionality that can be safely enabled independently of the decision that we will make about whether telemetry attributes are mandatory to be supported or not.
Jon> My primary point here was the use of the term “pre-mitigation” – this telemetry is also needs during a mitigation and the attack keeps on morphing into something else.
[Med] I see your point. We will see if we can find a better term.
Jon1> Agreed – it is the “pre” that certainly does not work for me.  Something like “attack information” ?
 
 
Another point we can check to ease correlation between a mitigation request and pre-mitigation telemetry is to signal the “mid” in the telemetry message.
Jon> could be – need to think this through
[Med] Let’s think about this one further.
Jon1> Sure – this may come out in the wash as we try to implement this stuff.


Regards
 
Jon

--------------8347B590A9C0DADAF41070C3-- From nobody Tue Mar 17 01:08:17 2020 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 50BFA3A1A78 for ; Tue, 17 Mar 2020 01:08:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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=orange.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 OriByet-3_Lm for ; Tue, 17 Mar 2020 01:08:12 -0700 (PDT) Received: from relais-inet.orange.com (relais-inet.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 5E9B43A1A7A for ; Tue, 17 Mar 2020 01:08:12 -0700 (PDT) Received: from opfednr02.francetelecom.fr (unknown [xx.xx.xx.66]) by opfednr25.francetelecom.fr (ESMTP service) with ESMTP id 48hQlb0SF8zCrT1; Tue, 17 Mar 2020 09:08:11 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1584432491; bh=YQLTYPW/O8WwovHtAAKKHf4CJdk7Iw60dTlfBAH3L88=; h=From:To:Subject:Date:Message-ID:Content-Type:MIME-Version; b=gAOPLHWVpGr7D16u/O9+kvPqnV/hyR9abvLhGMDzCGuoT7jKPHTGENmSzTB6Mqj1x UvzoYxqCloZUbqt6JbHcdpTYvnVmPKM7sLkNIOgFP16X85xe8eK9kr6/ZrV3fdYyV2 rv3vzN1mm8vwmCtiPSm2KUte0MGpfPCJ0tk0mvH5+EE8SQxi0nrr66ETu3c4KUk9V7 jM3uyNTrIX7GH2yNyrzOa1hRUIpPDl6vGrLurvuZ/Ym1ypuqtN9bGjuKK5kIE+lUSM +/KSByLnAY4cXEcB4U9RuE6WMFv04wtcfpJ99uuevc2Uhnft7v4je7pfeh57oAdoys fFYOpVl+i3NnA== Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.38]) by opfednr02.francetelecom.fr (ESMTP service) with ESMTP id 48hQlZ6kbpz8sYl; Tue, 17 Mar 2020 09:08:10 +0100 (CET) From: To: kaname nishizuka , Jon Shallow , "Konda, Tirumaleswar Reddy" , "dots@ietf.org" Thread-Topic: [Dots] DOTS telemetry questions Thread-Index: AQHV95AZTSaDwsKSIU6/wHOb1OfjPahMdvlw Date: Tue, 17 Mar 2020 08:08:10 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B933031471E3B@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> References: <188801d5e830$635d97d0$2a18c770$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93303143DAF8@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <191b01d5e8a8$886d1e60$99475b20$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93303143DE2E@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <197301d5e8cd$f31384a0$d93a8de0$@jpshallow.com> <559c1aa6-255d-4f1a-c513-87944995774f@nttv6.jp> In-Reply-To: <559c1aa6-255d-4f1a-c513-87944995774f@nttv6.jp> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.114.13.245] Content-Type: multipart/alternative; boundary="_000_787AE7BB302AE849A7480A190F8B933031471E3BOPEXCAUBMA2corp_" MIME-Version: 1.0 Archived-At: Subject: Re: [Dots] DOTS telemetry questions X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Mar 2020 08:08:16 -0000 --_000_787AE7BB302AE849A7480A190F8B933031471E3BOPEXCAUBMA2corp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Kaname, Will be fixed in -04. Thank you. Cheers, Med De : kaname nishizuka [mailto:kaname@nttv6.jp] Envoy=E9 : mercredi 11 mars 2020 11:30 =C0 : Jon Shallow; BOUCADAIR Mohamed TGI/OLN; Konda, Tirumaleswar Reddy; do= ts@ietf.org Objet : Re: [Dots] DOTS telemetry questions Hi, With regard to 4) Proposal: change MUST to SHOULD here. ``` DOTS agents MUST bind pre-mitigation telemetry data with mitigation requests relying upon the target clause. (snip) An example illustrating requests correlation by means of 'target-prefix' is shown in Figure 22. ``` It is acceptable to relax this bind especially in the case of Figure 22 fro= m operational perspective. In this case, Pre-mitigation telemetry from the DOTS server to the client c= an be a hint to the upcoming mitigation request. But it's not necessary to use the same prefix if an operator of the DOTS cl= ient wanted to do so. Like that, it's not necessary to correlate this pre-mitigation telemetry an= d the mitigation request from the view point of the DOTS server because ack= nowledging there is the correlation will not affect the behavior of the DOT= S server. But, It IS necessary to correlate the mitigation request by mid with furthe= r telemetry information from DOTS server (maybe namely "post-mitigation" te= lemetry). regards, Kaname On 2020/02/22 0:45, Jon Shallow wrote: Hi, See inline Jon1> Regards Jon From: Dots [mailto: dots-bounces@ietf.org] On= Behalf Of mohamed.boucadair@orange.com Sent: 21 February 2020 13:32 To: Jon Shallow; Konda, Tirumaleswar Reddy; kaname nishizuka; dots@ietf.org= Subject: Re: [Dots] DOTS telemetry questions Re-, Please see inline. Cheers, Med De : Jon Shallow [mailto:supjps-ietf@jpshallow.com] Envoy=E9 : vendredi 21 f=E9vrier 2020 12:18 =C0 : BOUCADAIR Mohamed TGI/OLN; Konda, Tirumaleswar Reddy; kaname nishizuk= a; dots@ietf.org Objet : RE: [Dots] DOTS telemetry questions Hi Med et al, See inline Jon> Regards Jon From: Dots [mailto: dots-bounces@ietf.org] On= Behalf Of mohamed.boucadair@orange.com Sent: 21 February 2020 07:00 To: Jon Shallow; Konda, Tirumaleswar Reddy; kaname nishizuka Cc: dots@ietf.org Subject: Re: [Dots] DOTS telemetry questions Hi Jon, (ccing the WG to track the changes). Please see inline. Cheers, Med De : Jon Shallow [mailto:supjps-ietf@jpshallow.com] Envoy=E9 : jeudi 20 f=E9vrier 2020 21:58 =C0 : BOUCADAIR Mohamed TGI/OLN; Konda, Tirumaleswar Reddy; kaname nishizuk= a Objet : DOTS telemetry questions Hi Guys, 1) For example CBOR mappings Header: PUT (Code=3D0.03) Uri-Path: ".well-known" Uri-Path: "dots" Uri-Path: "mitigate" Uri-Path: "cuid=3Ddz6pHjaADkaFTbjr0JGBpw" Uri-Path: "mid=3D123" If-Match: Content-Format: "application/dots+cbor" { "ietf-dots-signal-channel:mitigation-scope": { "scope": [ { "alias-name": [ "myserver" ], "attack-status": "under-attack", "ietf-dots-telemetry:total-attack-traffic": [ { "ietf-dots-telemetry:unit": "megabytes-ps", "ietf-dots-telemetry:mid-percentile-g": "900" } ] } ] } } Figure 33: An Example of Mitigation Efficacy Update with Telemetry Attributes And yet the mapping table only has (no ietf-dots-telemetry: prefix) | total-attack-traffic | list |32794 | 4 array | Array | I appreciate that ietf-dots-telemetry:total-attack-traffic and total-attack= traffic are the same CBOR value (or are they?) [Med] The same value is used but I didn't check if there are side effects. Jon> Need to think this through. My implementation maps the CBOR into JSON= and then works on the JSON to do what is necessary and then converts the J= SON response back into CBOR. [Med] An issue with namespaces will be the encountered if the conversion is= the same for the attribute when it is carried in a "pure" telemetry messag= e or in an existing signal channel message. Jon1> Correct - I don't like the concept of having 2 mapping tables for map= ping the CBOR value back into JSON. Jon> We have the same naming issues in draft-ietf-dots-signal-filter-contr= ol-00 where we do not have the ietf-dots-signal-control: prefix in the JSON= examples (Fig 10) [Med] Fig 10 is a "normal" mitigation request. Why should it need to includ= e "ietf-dots-signal-control:" prefix? Jon1> My bad - I was looking at draft-ietf-dots-signal-filter-control-00, n= ot draft-ietf-dots-signal-filter-control-02. However, https://tools.ietf.o= rg/html/draft-ietf-dots-signal-filter-control-02#section-5.1 only defines "= activation-type" without the prefix, and acl-list and acl-name have the inc= orrect prefix: added to, for example, Figure 1. Please note that we have this note is section 10: =3D=3D o Some of these attributes should be prepended with "ietf-dots- telemetry:" =3D=3D but when mapping the CBOR back to JSON the variant of JSON parameter is con= text (Uri-Path: mitigate or tm) dependent. 2) why do we not have a "enum megabit-ps" in "typedef unit" in the YAN= G Module? [Med] This can be added to the list as 'units()' are negotiated. *-bytes a= re more used for aggregates, but let's be consistent and have both bit/byte= s in the units. Jon> Megabytes works with aggregates, megabits works with pipes. [Med] I added the unit to the module. BTW, in order to easily define new un= its, I updated the module so that units are defined as identities, not enum= erations. The updated mapping table is: https://github.com/boucadair/draft-= dots-telemetry/blob/master/mapping-table.txt (or https://github.com/boucada= ir/draft-dots-telemetry/blob/master/draft-ietf-dots-telemetry-03.txt) Jon1> Typo in megabite-ps Jon1> I am not sure about the usage of identityref. https://tools.ietf.org= /html/rfc7951#section-6.8 states that the value is represented as a string = (currently the CBOR mapping entry says it is an integer), and furthermore i= t is likely that the namespace-qualified form is required. This is a huge i= ncrease in the number of bytes needed whenever unit (and measurement-interv= al Etc.) are used. I think that this is a bad change. 3) I think that I have worked out that server-originated-telemetry if = set allows telemetry included in the mitigation status rather than only ret= urned using Uri-path: tm - correct? [Med] I confirm. Note that including pre-mitigation returned using "Uri-pat= h:tm" is controlled by PUT/GET (Section 7.3). Jon> Agreed. 4) I am confused by "pre-mitigation" which can be transmitted pre any = mitigation taking place, or actually during when mitigation is taking place= (or so I think) and would simply be better described as "attack-details" -= especially with a statement such as DOTS agents MUST bind pre-mitigation telemetry data with mitigation requests relying upon the target clause. [Med] That's an option but the current design allows to have the telemetry = in // in order to supply more data ** without impacting the placement of a = mitigation request ** hence the need to bind both (if any). If telemetry at= tributes are defined as mandatory (discussed in another thread), this would= mean that the server will reject a mitigation that includes such attribute= s. With the current design, we have a functionality that can be safely enab= led independently of the decision that we will make about whether telemetry= attributes are mandatory to be supported or not. Jon> My primary point here was the use of the term "pre-mitigation" - this = telemetry is also needs during a mitigation and the attack keeps on morphin= g into something else. [Med] I see your point. We will see if we can find a better term. Jon1> Agreed - it is the "pre" that certainly does not work for me. Someth= ing like "attack information" ? Another point we can check to ease correlation between a mitigation request= and pre-mitigation telemetry is to signal the "mid" in the telemetry messa= ge. Jon> could be - need to think this through [Med] Let's think about this one further. Jon1> Sure - this may come out in the wash as we try to implement this stuf= f. Regards Jon --_000_787AE7BB302AE849A7480A190F8B933031471E3BOPEXCAUBMA2corp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Kaname,

 

Will be fixed in -04. Thank you.

 

Cheers,

Med

 

De : kana= me nishizuka [mailto:kaname@nttv6.jp]
Envoy=E9 : mercredi 11 mars 2020 11:30
=C0 : Jon Shallow; BOUCADAIR Moh= amed TGI/OLN; Konda, Tirumaleswar Reddy; dots@ietf.org
Objet : Re: [Dots] DOTS telemetry questions

 

Hi,

With regard to 4)

Proposal: change MUST to SHOULD here.
```
DOTS agents MUST bind pre-mitigation telemetry data with mitigation
   requests relying upon the target clause.
(snip)
 An example illustrating requests correlation by means of 'target-pref= ix'
   is shown in Figure 22.
```

It is acceptable to relax this bind especially in the case of Figure 22 fro= m operational perspective.
In this case, Pre-mitigation telemetry from the DOTS server to the client c= an be a hint to the upcoming mitigation request.
But it's not necessary to use the same prefix if an operator of the DOTS cl= ient wanted to do so.
Like that, it's not necessary to correlate this pre-mitigation telemetry an= d the mitigation request from the view point of the DOTS server because ack= nowledging there is the correlation will not affect the behavior of the DOT= S server.

But, It IS necessary to correlate the mitigation request by mid with furthe= r telemetry information from DOTS server (maybe namely "post-mitigatio= n" telemetry).

regards,
Kaname

On 2020/02/22 0:45, Jon Shallow wrote:

Hi,<= /p>

 

See inline Jon1>

 

Regards

 

Jon<= /p>

 

From: Dots [ma= ilto: dots-bounces@ietf.org] On B= ehalf Of mohamed.boucadair@orang= e.com
Sent: 21 February 2020 13:32
To: Jon Shallow; Konda, Tirumaleswar Reddy; kaname nishizuka; dots@ietf.org
Subject: Re: [Dots] DOTS telemetry questions

 

Re-,

 

Please see inline.

 

Cheers,

Med

 

De : Jon Shallow [mailto:supjps-ietf@jpshallow.com]
Envoy=E9 : vendredi 21 f=E9vrier 2020 12:18
=C0 : BOUCADAIR Mohamed TGI/OLN; Konda, Tirumaleswar Reddy; kan= ame nishizuka; dots@ietf.org
Objet : RE: [Dots] DOTS telemetry questions

 

Hi Med et al,

 

See inline Jon>

 

Regards

 

Jon<= /p>

 

From: Dots [ma= ilto: dots-bounces@ietf.org] On B= ehalf Of mohamed.boucadair@orang= e.com
Sent: 21 February 2020 07:00
To: Jon Shallow; Konda, Tirumaleswar Reddy; kaname nishizuka
Cc: dots@ietf.org
Subject: Re: [Dots] DOTS telemetry questions

 

Hi Jon,

 

(ccing the WG to track the changes).

 

Please see inline.

 

Cheers,

Med

 

De : Jon Shallow [mailto:supjps-ietf@jpshallow.com]
Envoy=E9 : jeudi 20 f=E9vrier 2020 21:58
=C0 : BOUCADAIR Mohamed TGI/OLN; Konda, Tirumaleswar Reddy; kan= ame nishizuka
Objet : DOTS telemetry questions

 

Hi Guys,

 

1)      For example CBOR mappings

 

     Header: = PUT (Code=3D0.03)

     Uri-Path= : ".well-known"

     Uri-Path= : "dots"

     Uri-Path= : "mitigate"

     Uri-Path= : "cuid=3Ddz6pHjaADkaFTbjr0JGBpw"

     Uri-Path= : "mid=3D123"

     If-Match= :

     Content-= Format: "application/dots+cbor"

 

     {=

      &q= uot;ietf-dots-signal-channel:mitigation-scope": {

     &nb= sp;  "scope": [

     &nb= sp;    {

     &nb= sp;      "alias-name": [

     &nb= sp;         "myserver"

     &nb= sp;       ],

     &nb= sp;      "attack-status": "under-at= tack",

     &nb= sp;      "ietf-dots-telemetry:total-att= ack-traffic": [

     &nb= sp;        {

     &nb= sp;          "ietf-dots-t= elemetry:unit": "megabytes-ps",

     &nb= sp;          "ietf-dots-t= elemetry:mid-percentile-g": "900"

     &nb= sp;        }

     &nb= sp;      ]

     &nb= sp;    }

     &nb= sp;  ]

      }<= /span>

     }=

 

    Figure 33: An = Example of Mitigation Efficacy Update with Telemetry

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

 

And yet the mapping table only has (no ietf-dots-tel= emetry: prefix)

 

    |= total-attack-traffic | list        |327= 94 | 4 array       | Array  |

 

I appreciate that ietf-dots-telemetry:total-attack-t= raffic and total-attack traffic are the same CBOR value (or are they?)=

[Med] The same value is used but I didn’= t check if there are side effects.

Jon> Need to think = this through.  My implementation maps the CBOR into JSON and then work= s on the JSON to do what is necessary and then converts the JSON response b= ack into CBOR.

[Med] An issue with namespaces will be the enc= ountered if the conversion is the same for the attribute when it is carried= in a “pure” telemetry message or in an existing signal channel= message.

Jon1> Correct ̵= 1; I don’t like the concept of having 2 mapping tables for mapping th= e CBOR value back into JSON.

 

Jon&g=
t; We  have the same naming issues in draft-ietf-dots-signal-filter-co=
ntrol-00 where we do not have the ietf-dots-signal-control: pr=
efix in the JSON examples (Fig 10)
[Med] Fig 10 is a “normal”=
 mitigation request. Why should it need to include “ietf-dots-signal-=
control:” prefix?
 =
;

Jon1> My bad – I was looking at draft-ietf-dots-signal-filter-control-00, not draft-ietf-dots-signal-filter= -control-02.  However, https://tools.ietf.org/html/draft-ietf-dots-signal-filter-control-02#sectio= n-5.1 only defines “activation-type” without the prefix, an= d acl-list and acl-name have the incorrect prefix: added to, for example, F= igure 1.

 

Please note that we have this note is section = 10:

 

=3D=3D

   o  Some of the= se attributes should be prepended with "ietf-dots-

      t= elemetry:"

=3D=3D

 

but when mapping the CBOR back to JSON the variant o= f JSON parameter is context (Uri-Path: mitigate or tm) dependent.

 
2)      why do we not have a “enum megabit-ps” in =
220;typedef unit” in the YANG Module?
Jon> Megabytes works with aggregates,=
 megabits works with pipes.
https://github.c=
om/boucadair/draft-dots-telemetry/blob/master/mapping-table.txt (or https://github.com/boucadair/draft-dots-teleme=
try/blob/master/draft-ietf-dots-telemetry-03.txt) <=
/o:p>
Jon1=
> Typo in megabite-ps
Jon1=
> I am not sure about the usage of identityref.  https://tools.ietf.org/html/rfc79=
51#section-6.8 states that the value is represented as a string (curren=
tly the CBOR mapping entry says it is an integer), and furthermore it is li=
kely that the namespace-qualified form is required. This is a huge increase=
 in the number of bytes needed whenever unit (and measureme=
nt-interval Etc.) are used.  I think that this is a bad change.=
&nb=
sp; 
 
3)      I think that I have worked out that server-originated-tel=
emetry if set allows telemetry included in the mitigation status rather tha=
n only returned using Uri-path: tm – correct?
Jon> Agreed.  =

 

4)      I am confused by “pre-mitigation” which can b=
e transmitted pre any mitigation taking place, or actually during when miti=
gation is taking place (or so I think) and would simply be better described=
 as “attack-details” – especially with a statement such a=
s

 

   DOTS agents MUST bind pre-mi=
tigation telemetry data with mitigation
   requests relying upon the ta=
rget clause.
Jon> My primary point here was the us=
e of the term “pre-mitigation” – this telemetry is also n=
eeds during a mitigation and the attack keeps on morphing into something el=
se.
Jon1> Agreed – it is the “=
;pre” that certainly does not work for me.  Something like ̶=
0;attack information” ?
Jon&=
gt; could be – need to think this through
Jon1> Sure – this may come out =
in the wash as we try to implement this stuff.
 
Regards
 
Jon

 

--_000_787AE7BB302AE849A7480A190F8B933031471E3BOPEXCAUBMA2corp_-- From nobody Thu Mar 19 11:02:37 2020 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 40F603A0C5E; Thu, 19 Mar 2020 11:02:24 -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.121.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: dots@ietf.org Message-ID: <158464094415.15707.13537470735384860225@ietfa.amsl.com> Date: Thu, 19 Mar 2020 11:02:24 -0700 Archived-At: Subject: [Dots] I-D Action: draft-ietf-dots-telemetry-04.txt X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.29 List-Id: "List for 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, 19 Mar 2020 18:02:25 -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) Telemetry Authors : Mohamed Boucadair Tirumaleswar Reddy Ehud Doron Meiling Chen Filename : draft-ietf-dots-telemetry-04.txt Pages : 82 Date : 2020-03-19 Abstract: This document aims to enrich DOTS signal channel protocol with various telemetry attributes allowing optimal DDoS attack mitigation. This document specifies the normal traffic baseline and attack traffic telemetry attributes a DOTS client can convey to its DOTS server in the mitigation request, the mitigation status telemetry attributes a DOTS server can communicate to a DOTS client, and the mitigation efficacy telemetry attributes a DOTS client can communicate to a DOTS server. The telemetry attributes can assist the mitigator to choose the DDoS mitigation techniques and perform optimal DDoS attack mitigation. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dots-telemetry/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-dots-telemetry-04 https://datatracker.ietf.org/doc/html/draft-ietf-dots-telemetry-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dots-telemetry-04 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 19 11:08:05 2020 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 251C93A0C75 for ; Thu, 19 Mar 2020 11:08:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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=orange.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 oAYbIdOro2mc for ; Thu, 19 Mar 2020 11:08:01 -0700 (PDT) Received: from relais-inet.orange.com (relais-inet.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 CF38C3A0C6E for ; Thu, 19 Mar 2020 11:08:00 -0700 (PDT) Received: from opfednr07.francetelecom.fr (unknown [xx.xx.xx.71]) by opfednr21.francetelecom.fr (ESMTP service) with ESMTP id 48jvyl2hmBz5wHJ for ; Thu, 19 Mar 2020 19:07:59 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1584641279; bh=YiWHEjyIJvhBp8nUWHa1gy9eJZ//8c5AVhRpmlKaMl0=; h=From:To:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=hmrCNZHIgHnGAjSgBlig1B4uTRNoWHL7aGX67ZtRgqw/ulhZqjlhOWqaIrNvNxLV3 yjIaorYG/R5i6Gd3qoyd3guLscVyQXIB5hlVR4MHE8apiBOMpMgEk77iUkrGkq+pC+ Q1Cl2x/6t/pnI56Foak7huDkjSnmSVMsj4q5HQ2SpvuEobJbRgzxSz8e2UCBa6k6Fm TxKCtz8psMZU49AWHLLt3u19+QGqExNRV21IrlqpQ7+dnhYY6k4RAzhsQBidg1UN4l XxJn3Ujk2DZcyuYOL4At5iMJ1F+9MgtSe8bxUSXjiA9MmSVU3rDli2+nh/HUq7MMuy xSYB3QLJ7/o5A== Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.48]) by opfednr07.francetelecom.fr (ESMTP service) with ESMTP id 48jvyl24y6zFpWb for ; Thu, 19 Mar 2020 19:07:59 +0100 (CET) From: To: "dots@ietf.org" Thread-Topic: [Dots] I-D Action: draft-ietf-dots-telemetry-04.txt Thread-Index: AQHV/hiVLxlUwsHkHUmRlSfJHYu99ahQNQ+A Date: Thu, 19 Mar 2020 18:07:58 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B933031476F63@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> References: <158464094415.15707.13537470735384860225@ietfa.amsl.com> In-Reply-To: <158464094415.15707.13537470735384860225@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.114.13.247] 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-telemetry-04.txt X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Mar 2020 18:08:04 -0000 Hi all,=20 This version takes into account the comments from Jon and Kaname. The main = changes are: * add some text about auto-scaling so that an agent picks the appropriate u= nit when sending telemetry data. * add some source-* attributes to echo what we do already have in the call = home. * add some text about how long telemetry data is logged and updated.=20 * add text about retrieval of timid when a client crashes.=20 And some other edits and nits fixed.=20 Cheers, Med > -----Message d'origine----- > De=A0: Dots [mailto:dots-bounces@ietf.org] De la part de internet- > drafts@ietf.org > Envoy=E9=A0: jeudi 19 mars 2020 19:02 > =C0=A0: i-d-announce@ietf.org > Cc=A0: dots@ietf.org > Objet=A0: [Dots] I-D Action: draft-ietf-dots-telemetry-04.txt >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the DDoS Open Threat Signaling WG of the > IETF. >=20 > Title : Distributed Denial-of-Service Open Threat > Signaling (DOTS) Telemetry > Authors : Mohamed Boucadair > Tirumaleswar Reddy > Ehud Doron > Meiling Chen > Filename : draft-ietf-dots-telemetry-04.txt > Pages : 82 > Date : 2020-03-19 >=20 > Abstract: > This document aims to enrich DOTS signal channel protocol with > various telemetry attributes allowing optimal DDoS attack > mitigation. > This document specifies the normal traffic baseline and attack > traffic telemetry attributes a DOTS client can convey to its DOTS > server in the mitigation request, the mitigation status telemetry > attributes a DOTS server can communicate to a DOTS client, and the > mitigation efficacy telemetry attributes a DOTS client can > communicate to a DOTS server. The telemetry attributes can assist > the mitigator to choose the DDoS mitigation techniques and perform > optimal DDoS attack mitigation. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-dots-telemetry/ >=20 > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-dots-telemetry-04 > https://datatracker.ietf.org/doc/html/draft-ietf-dots-telemetry-04 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dots-telemetry-04 >=20 >=20 > Please note that it may take a couple of minutes from the time of > submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 >=20 > _______________________________________________ > Dots mailing list > Dots@ietf.org > https://www.ietf.org/mailman/listinfo/dots From nobody Mon Mar 23 00:18:53 2020 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 3C4D53A087F; Mon, 23 Mar 2020 00:18:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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=orange.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 Uf2iNhmUW1Yt; Mon, 23 Mar 2020 00:18:41 -0700 (PDT) Received: from relais-inet.orange.com (relais-inet.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 7607B3A087E; Mon, 23 Mar 2020 00:18:41 -0700 (PDT) Received: from opfedar00.francetelecom.fr (unknown [xx.xx.xx.11]) by opfedar23.francetelecom.fr (ESMTP service) with ESMTP id 48m5Mg61jvzBrlD; Mon, 23 Mar 2020 08:18:39 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1584947919; bh=R0+X/I7R3bP6tLMwa82YA7j9Yrga9Iyj6TvFnSP0mTo=; h=From:To:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=sVsAsBd7W/QvJduYEwu8L3TtvuOy2K4Z2P5VxUDA26F9MrPJzEYLjOWptCxsxQHIn YRt2tJrZ95zfpGuAkGQbsGIwdPPsg/wVXKmpMxqVoP0RH+BozCyYDZTlgXfIeJx0Hf vBxxVY3EqdaDPevDbqAhQPIG0pmtwYaSiTgNpvGQRkl0TgT8q2S+sQcMr/yQI1pA7r C3tTBwiusjYOEffygGnovKVFcwZWxXJvXtRE8SzhlTDbOFPhqPw72YlVKq5cnFx4DZ IMqZuE2Q/ZQn6hInDKiQfUHcnF7N+BELB9/YY8j19vAgnxRnNc7ug/56afg8kWqy6y yJnUhp7XriphA== Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.64]) by opfedar00.francetelecom.fr (ESMTP service) with ESMTP id 48m5Mg4yrdzCqkG; Mon, 23 Mar 2020 08:18:39 +0100 (CET) From: To: Carsten Bormann CC: "dots@ietf.org" , "core@ietf.org" Thread-Topic: [core] RFC 8768 on Constrained Application Protocol (CoAP) Hop-Limit Option Thread-Index: AQHV/zh0o79CF5P8k0SY1cBIdSPMTKhSlxIAgAMvPRA= Date: Mon, 23 Mar 2020 07:18:39 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93303147B5EA@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> References: <20200321042126.5078DF40713@rfc-editor.org> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.114.13.247] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [Dots] [core] RFC 8768 on Constrained Application Protocol (CoAP) Hop-Limit Option X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2020 07:18:45 -0000 SGkgQ2FydHNlbiwgDQoNClRoYW5rIHlvdSBDYXJzdGVuIGFuZCB0aGUgY29yZSBXRyBmb3IgaGVs cGluZyB0byBnZXQgdGhpcyB0aHJvdWdoLiANCg0KVGhlcmUgd2FzIGEgcG9pbnQgcmFpc2VkIGR1 cmluZyB0aGUgcHVibGljYXRpb24gb2YgdGhpcyBSRkM6IEhUVFAgb3B0aW9uIGVuY2Fwc3VsYXRp bmcgQ29BUCBvbmVzLiBJIGhvcGUgdGhhdCBzb21lb25lIGNhbiB0YWtlIHRoYXQgd29yay4gDQoN CkNoZWVycywNCk1lZA0KDQo+IC0tLS0tTWVzc2FnZSBkJ29yaWdpbmUtLS0tLQ0KPiBEZcKgOiBj b3JlIFttYWlsdG86Y29yZS1ib3VuY2VzQGlldGYub3JnXSBEZSBsYSBwYXJ0IGRlIENhcnN0ZW4g Qm9ybWFubg0KPiBFbnZvecOpwqA6IHNhbWVkaSAyMSBtYXJzIDIwMjAgMDg6MzQNCj4gw4DCoDog Y29yZUBpZXRmLm9yZyBXRw0KPiBPYmpldMKgOiBSZTogW2NvcmVdIFJGQyA4NzY4IG9uIENvbnN0 cmFpbmVkIEFwcGxpY2F0aW9uIFByb3RvY29sIChDb0FQKQ0KPiBIb3AtTGltaXQgT3B0aW9uDQo+ IA0KPiBDb25ncmF0dWxhdGlvbnMgZm9yIHRoZSBwdWJsaWNhdGlvbiBvZiB0aGUgMTN0aCBSRkMg ZnJvbSB0aGlzIFdHIQ0KPiANCj4gVGhlIG9yaWdpbmFsIC0wMCB3YXMgc3VibWl0dGVkIDIwMTgt MDgtMTYsIHNvIGl0IHRvb2sgYSBiaXQgbW9yZSB0aGFuDQo+IDHCvSB5ZWFycyB0byBnZXQgdGhp cyBwdWJsaXNoZWQgKGluaXRpYWwgc3VibWlzc2lvbiB0byBhcHByb3ZhbCB3YXMNCj4gMjAxOC0w OC0xNiB0byAyMDE5LTExLTI2LCBzbyAxwrwgeWVhcnMpLg0KPiANCj4gVGhpcyBDb1JFIFJGQyBp cyBub3RhYmxlIGluIHRoYXQgaXQgb3JpZ2luYXRlZCBpbiBhIG5vbi1Jb1QgV0csIHRoZQ0KPiBE T1RTIFdHIChERG9TIE9wZW4gVGhyZWF0IFNpZ25hbGluZykuICBJIHRoaW5rIHRoZXJlIHdhcyBz b21lIHJvb20gZm9yDQo+IGltcHJvdmVtZW50IGluIGhvdyB3ZSgqKSBoYW5kbGVkIHRoaXMsIGJ1 dCB3ZSBkaWQgc3VjY2VlZCwgYW5kIGluIGENCj4gdGltZSBmcmFtZSB0aGF0IGlzIHN0aWxsIHF1 aXRlIHJlYXNvbmFibGUuDQo+IA0KPiBUaGFua3MgdG8gdGhlIGF1dGhvcnMgZm9yIGJyaW5naW5n IHRoaXMgdG8gdGhlIENvUkUgV0chDQo+IA0KPiBHcsO8w59lLCBDYXJzdGVuDQo+IA0KPiAoKikg SSB0aGluayBJIGNhbiBzYXkgdGhhdCBiZWNhdXNlIGl04oCZcyBtb3N0bHkgbWUgdGhhdCBpcyB0 byBibGFtZQ0KPiBoZXJlLCBhbmQgSSBhbSBvcHRpbWlzdGljIHRoZSBjdXJyZW50IGNoYWlycyBj YW4gYmUgYmV0dGVyIHRoYW4gbXkNCj4gY29udHJpYnV0aW9uIGF0IHRoZSB0aW1lIHdhcy4uLg0K PiANCj4gDQo+ID4gT24gMjAyMC0wMy0yMSwgYXQgMDU6MjEsIHJmYy1lZGl0b3JAcmZjLWVkaXRv ci5vcmcgd3JvdGU6DQo+ID4NCj4gPiBBIG5ldyBSZXF1ZXN0IGZvciBDb21tZW50cyBpcyBub3cg YXZhaWxhYmxlIGluIG9ubGluZSBSRkMgbGlicmFyaWVzLg0KPiA+DQo+ID4NCj4gPiAgICAgICAg UkZDIDg3NjgNCj4gPg0KPiA+ICAgICAgICBUaXRsZTogICAgICBDb25zdHJhaW5lZCBBcHBsaWNh dGlvbiBQcm90b2NvbCAoQ29BUCkNCj4gPiAgICAgICAgICAgICAgICAgICAgSG9wLUxpbWl0IE9w dGlvbg0KPiA+ICAgICAgICBBdXRob3I6ICAgICBNLiBCb3VjYWRhaXIsDQo+ID4gICAgICAgICAg ICAgICAgICAgIFQuIFJlZGR5LkssDQo+ID4gICAgICAgICAgICAgICAgICAgIEouIFNoYWxsb3cN Cj4gPiAgICAgICAgU3RhdHVzOiAgICAgU3RhbmRhcmRzIFRyYWNrDQo+ID4gICAgICAgIFN0cmVh bTogICAgIElFVEYNCj4gPiAgICAgICAgRGF0ZTogICAgICAgTWFyY2ggMjAyMA0KPiA+ICAgICAg ICBNYWlsYm94OiAgICBtb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tLA0KPiA+ICAgICAgICAg ICAgICAgICAgICBrb25kdGlyQGdtYWlsLmNvbSwNCj4gPiAgICAgICAgICAgICAgICAgICAgc3Vw anBzLWlldGZAanBzaGFsbG93LmNvbQ0KPiA+ICAgICAgICBQYWdlczogICAgICA4DQo+ID4gICAg ICAgIFVwZGF0ZXMvT2Jzb2xldGVzL1NlZUFsc286ICAgTm9uZQ0KPiA+DQo+ID4gICAgICAgIEkt RCBUYWc6ICAgIGRyYWZ0LWlldGYtY29yZS1ob3AtbGltaXQtMDcudHh0DQo+ID4NCj4gPiAgICAg ICAgVVJMOiAgICAgICAgaHR0cHM6Ly93d3cucmZjLWVkaXRvci5vcmcvaW5mby9yZmM4NzY4DQo+ ID4NCj4gPiAgICAgICAgRE9JOiAgICAgICAgMTAuMTc0ODcvUkZDODc2OA0KPiA+DQo+ID4gVGhl IHByZXNlbmNlIG9mIENvbnN0cmFpbmVkIEFwcGxpY2F0aW9uIFByb3RvY29sIChDb0FQKSBwcm94 aWVzIG1heQ0KPiA+IGxlYWQgdG8gaW5maW5pdGUgZm9yd2FyZGluZyBsb29wcywgd2hpY2ggaXMg dW5kZXNpcmFibGUuIFRvIHByZXZlbnQNCj4gPiBhbmQgZGV0ZWN0IHN1Y2ggbG9vcHMsIHRoaXMg ZG9jdW1lbnQgc3BlY2lmaWVzIHRoZSBIb3AtTGltaXQgQ29BUA0KPiA+IG9wdGlvbi4NCj4gPg0K PiA+IFRoaXMgZG9jdW1lbnQgaXMgYSBwcm9kdWN0IG9mIHRoZSBDb25zdHJhaW5lZCBSRVNUZnVs IEVudmlyb25tZW50cw0KPiBXb3JraW5nIEdyb3VwIG9mIHRoZSBJRVRGLg0KPiA+DQo+ID4gVGhp cyBpcyBub3cgYSBQcm9wb3NlZCBTdGFuZGFyZC4NCj4gPg0KPiA+IFNUQU5EQVJEUyBUUkFDSzog VGhpcyBkb2N1bWVudCBzcGVjaWZpZXMgYW4gSW50ZXJuZXQgU3RhbmRhcmRzIFRyYWNrDQo+ID4g cHJvdG9jb2wgZm9yIHRoZSBJbnRlcm5ldCBjb21tdW5pdHksIGFuZCByZXF1ZXN0cyBkaXNjdXNz aW9uIGFuZA0KPiBzdWdnZXN0aW9ucw0KPiA+IGZvciBpbXByb3ZlbWVudHMuICBQbGVhc2UgcmVm ZXIgdG8gdGhlIGN1cnJlbnQgZWRpdGlvbiBvZiB0aGUNCj4gT2ZmaWNpYWwNCj4gPiBJbnRlcm5l dCBQcm90b2NvbCBTdGFuZGFyZHMgKGh0dHBzOi8vd3d3LnJmYy1lZGl0b3Iub3JnL3N0YW5kYXJk cykNCj4gZm9yIHRoZQ0KPiA+IHN0YW5kYXJkaXphdGlvbiBzdGF0ZSBhbmQgc3RhdHVzIG9mIHRo aXMgcHJvdG9jb2wuICBEaXN0cmlidXRpb24gb2YNCj4gdGhpcw0KPiA+IG1lbW8gaXMgdW5saW1p dGVkLg0KPiA+DQo+ID4gVGhpcyBhbm5vdW5jZW1lbnQgaXMgc2VudCB0byB0aGUgSUVURi1Bbm5v dW5jZSBhbmQgcmZjLWRpc3QgbGlzdHMuDQo+ID4gVG8gc3Vic2NyaWJlIG9yIHVuc3Vic2NyaWJl LCBzZWUNCj4gPiAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pZXRmLWFu bm91bmNlDQo+ID4gIGh0dHBzOi8vbWFpbG1hbi5yZmMtZWRpdG9yLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL3JmYy1kaXN0DQo+ID4NCj4gPiBGb3Igc2VhcmNoaW5nIHRoZSBSRkMgc2VyaWVzLCBzZWUg aHR0cHM6Ly93d3cucmZjLWVkaXRvci5vcmcvc2VhcmNoDQo+ID4gRm9yIGRvd25sb2FkaW5nIFJG Q3MsIHNlZSBodHRwczovL3d3dy5yZmMtZWRpdG9yLm9yZy9yZXRyaWV2ZS9idWxrDQo+ID4NCj4g PiBSZXF1ZXN0cyBmb3Igc3BlY2lhbCBkaXN0cmlidXRpb24gc2hvdWxkIGJlIGFkZHJlc3NlZCB0 byBlaXRoZXIgdGhlDQo+ID4gYXV0aG9yIG9mIHRoZSBSRkMgaW4gcXVlc3Rpb24sIG9yIHRvIHJm Yy1lZGl0b3JAcmZjLWVkaXRvci5vcmcuDQo+IFVubGVzcw0KPiA+IHNwZWNpZmljYWxseSBub3Rl ZCBvdGhlcndpc2Ugb24gdGhlIFJGQyBpdHNlbGYsIGFsbCBSRkNzIGFyZSBmb3INCj4gPiB1bmxp bWl0ZWQgZGlzdHJpYnV0aW9uLg0KPiA+DQo+ID4NCj4gPiBUaGUgUkZDIEVkaXRvciBUZWFtDQo+ ID4gQXNzb2NpYXRpb24gTWFuYWdlbWVudCBTb2x1dGlvbnMsIExMQw0KPiA+DQo+ID4gX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPiBJRVRGLUFubm91 bmNlIG1haWxpbmcgbGlzdA0KPiA+IElFVEYtQW5ub3VuY2VAaWV0Zi5vcmcNCj4gPiBodHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lldGYtYW5ub3VuY2UNCj4gDQo+IF9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IGNvcmUgbWFpbGlu ZyBsaXN0DQo+IGNvcmVAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9jb3JlDQo= From nobody Mon Mar 23 00:24:35 2020 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 995333A0879; Mon, 23 Mar 2020 00:24:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wDsBPUzxNijK; Mon, 23 Mar 2020 00:24:31 -0700 (PDT) Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DCAE63A0861; Mon, 23 Mar 2020 00:24:30 -0700 (PDT) Received: from [192.168.217.147] (p548DCD70.dip0.t-ipconnect.de [84.141.205.112]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 48m5VN72DZzyws; Mon, 23 Mar 2020 08:24:28 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.60.0.2.5\)) From: Carsten Bormann In-Reply-To: <787AE7BB302AE849A7480A190F8B93303147B5EA@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> Date: Mon, 23 Mar 2020 08:24:28 +0100 Cc: "dots@ietf.org" , "core@ietf.org" X-Mao-Original-Outgoing-Id: 606641068.7406729-4bfbbd449e01cb3ffb1965fa5bb8b5cc Content-Transfer-Encoding: quoted-printable Message-Id: <02223369-0FA8-4B77-B64D-732911C936BE@tzi.org> References: <20200321042126.5078DF40713@rfc-editor.org> <787AE7BB302AE849A7480A190F8B93303147B5EA@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> To: mohamed.boucadair@orange.com X-Mailer: Apple Mail (2.3608.60.0.2.5) Archived-At: Subject: Re: [Dots] [core] RFC 8768 on Constrained Application Protocol (CoAP) Hop-Limit Option X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2020 07:24:34 -0000 On 2020-03-23, at 08:18, mohamed.boucadair@orange.com wrote: >=20 > There was a point raised during the publication of this RFC: HTTP = option encapsulating CoAP ones. I hope that someone can take that work.=20= It=E2=80=99s on my to-do list. Anyone who wants to help? Gr=C3=BC=C3=9Fe, Carsten From nobody Fri Mar 27 08:56:20 2020 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 485353A0F0C; Fri, 27 Mar 2020 08:56:09 -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.123.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: dots@ietf.org Message-ID: <158532456916.24330.1573350617716535733@ietfa.amsl.com> Date: Fri, 27 Mar 2020 08:56:09 -0700 Archived-At: Subject: [Dots] I-D Action: draft-ietf-dots-telemetry-05.txt X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.29 List-Id: "List for 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, 27 Mar 2020 15:56:19 -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) Telemetry Authors : Mohamed Boucadair Tirumaleswar Reddy Ehud Doron Meiling Chen Filename : draft-ietf-dots-telemetry-05.txt Pages : 83 Date : 2020-03-27 Abstract: This document aims to enrich DOTS signal channel protocol with various telemetry attributes allowing optimal DDoS attack mitigation. It specifies the normal traffic baseline and attack traffic telemetry attributes a DOTS client can convey to its DOTS server in the mitigation request, the mitigation status telemetry attributes a DOTS server can communicate to a DOTS client, and the mitigation efficacy telemetry attributes a DOTS client can communicate to a DOTS server. The telemetry attributes can assist the mitigator to choose the DDoS mitigation techniques and perform optimal DDoS attack mitigation. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dots-telemetry/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-dots-telemetry-05 https://datatracker.ietf.org/doc/html/draft-ietf-dots-telemetry-05 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dots-telemetry-05 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 Fri Mar 27 09:01:03 2020 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 38CA63A0FF4 for ; Fri, 27 Mar 2020 09:00:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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=orange.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 TNh1PDiqwcKo for ; Fri, 27 Mar 2020 09:00:50 -0700 (PDT) Received: from relais-inet.orange.com (relais-inet.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 E96453A0FF5 for ; Fri, 27 Mar 2020 09:00:03 -0700 (PDT) Received: from opfedar02.francetelecom.fr (unknown [xx.xx.xx.4]) by opfedar26.francetelecom.fr (ESMTP service) with ESMTP id 48pmlQ0GYyzFq9f for ; Fri, 27 Mar 2020 17:00:02 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1585324802; bh=uGH5k42x2TF3XTxfyOxgOEOczTUnmpCLpJh5Ke92Yoo=; h=From:To:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=Zq0SuccDwksh0Uigxnc5D6JzjegRSL8Jg0WUbr0rep5tKOEaW/TP2BrCyKMwHbIbQ QRfuYlBJAUdKBoqphoGX7qCKf2x1EjyVeFkRi92XKWwbLrVyyJD3OAVNdMDuBxGFg7 yzQcLNsEV7toOYsPJZ0RI3Ev9/Y6z1t+pc1UudD9L6P4t82lEGlKX6anwW9kK4pSYz 6lGrUZe/1O3GWrNYs68OaFGLQ+EkHWDnu6zOBKrpiVrZG3iR38Oeh0+nOlbQdM9pGp g/YgPBAm+OyiDTNjmJdgaAXYAwg6KM8hO2g0bQKFzTNToeH7WMrmuyW+iLMhM4zlf/ vRhUz2UqmshsQ== Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.26]) by opfedar02.francetelecom.fr (ESMTP service) with ESMTP id 48pmlP6GnKzCqkj for ; Fri, 27 Mar 2020 17:00:01 +0100 (CET) From: To: "dots@ietf.org" Thread-Topic: New Version Notification for draft-ietf-dots-telemetry-05.txt Thread-Index: AQHWBFBAYpRN0teAMUW+CSq0Fo/I6ahcmAqA Date: Fri, 27 Mar 2020 16:00:01 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93303148203F@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> References: <158532456961.24330.9684049527965442282@ietfa.amsl.com> In-Reply-To: <158532456961.24330.9684049527965442282@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.114.13.247] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [Dots] New Version Notification for draft-ietf-dots-telemetry-05.txt X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Mar 2020 16:01:01 -0000 SGkgYWxsLA0KDQpUaGlzIGEgbWlub3IgcmV2aXNpb24gdGhhdCBmaXhlcyBzb21lIG5pdHMgYW5k IGNsYXJpZmllcyB0aGUgdXNlIG9mIHVuaXRzIHRoYXQgY2FuIGJlIGNvbmZpZ3VyZWQgYW5kIGNv bnRyb2xsZWQgYnkgYSBET1RTIGNsaWVudHMuDQpUaGlzIHZlcnNpb24gdGFrZXMgaW50byBhY2Nv dW50IHRoZSBmZWVkYmFjayByZWNlaXZlZCBmcm9tIEpvbiBhbmQgS2FuYW1lIHdobyBhcmUgY3Vy cmVudGx5IGNvbmR1Y3RpbmcgaW50ZXJvcCB0ZXN0aW5nLg0KSSB3aWxsIGxldCBKb24gYW5kIEth bmFtZSBzaGFyZSBtb3JlIGFib3V0IHRoZSBpbnRlcm9wLiANCg0KQ2hlZXJzLA0KTWVkDQoNCj4g LS0tLS1NZXNzYWdlIGQnb3JpZ2luZS0tLS0tDQo+IERlwqA6IGludGVybmV0LWRyYWZ0c0BpZXRm Lm9yZyBbbWFpbHRvOmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZ10NCj4gRW52b3nDqcKgOiB2ZW5k cmVkaSAyNyBtYXJzIDIwMjAgMTY6NTYNCj4gw4DCoDogTWVpbGluZyBDaGVuOyBFaHVkIERvcm9u OyBUaXJ1bWFsZXN3YXIgUmVkZHkuSzsgVGlydW1hbGVzd2FyDQo+IFJlZGR5OyBjaGVubWVpbGlu ZzsgQk9VQ0FEQUlSIE1vaGFtZWQgVEdJL09MTg0KPiBPYmpldMKgOiBOZXcgVmVyc2lvbiBOb3Rp ZmljYXRpb24gZm9yIGRyYWZ0LWlldGYtZG90cy10ZWxlbWV0cnktMDUudHh0DQo+IA0KPiANCj4g QSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0LWlldGYtZG90cy10ZWxlbWV0cnktMDUudHh0DQo+ IGhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgTW9oYW1lZCBCb3VjYWRhaXIgYW5k IHBvc3RlZCB0byB0aGUNCj4gSUVURiByZXBvc2l0b3J5Lg0KPiANCj4gTmFtZToJCWRyYWZ0LWll dGYtZG90cy10ZWxlbWV0cnkNCj4gUmV2aXNpb246CTA1DQo+IFRpdGxlOgkJRGlzdHJpYnV0ZWQg RGVuaWFsLW9mLVNlcnZpY2UgT3BlbiBUaHJlYXQgU2lnbmFsaW5nDQo+IChET1RTKSBUZWxlbWV0 cnkNCj4gRG9jdW1lbnQgZGF0ZToJMjAyMC0wMy0yNw0KPiBHcm91cDoJCWRvdHMNCj4gUGFnZXM6 CQk4Mw0KPiBVUkw6ICAgICAgICAgICAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJh ZnRzL2RyYWZ0LWlldGYtZG90cy0NCj4gdGVsZW1ldHJ5LTA1LnR4dA0KPiBTdGF0dXM6ICAgICAg ICAgaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1kb3RzLQ0KPiB0 ZWxlbWV0cnkvDQo+IEh0bWxpemVkOiAgICAgICBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwv ZHJhZnQtaWV0Zi1kb3RzLXRlbGVtZXRyeS0NCj4gMDUNCj4gSHRtbGl6ZWQ6ICAgICAgIGh0dHBz Oi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2h0bWwvZHJhZnQtaWV0Zi1kb3RzLQ0KPiB0ZWxl bWV0cnkNCj4gRGlmZjogICAgICAgICAgIGh0dHBzOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJs Mj1kcmFmdC1pZXRmLWRvdHMtDQo+IHRlbGVtZXRyeS0wNQ0KPiANCj4gQWJzdHJhY3Q6DQo+ICAg IFRoaXMgZG9jdW1lbnQgYWltcyB0byBlbnJpY2ggRE9UUyBzaWduYWwgY2hhbm5lbCBwcm90b2Nv bCB3aXRoDQo+ICAgIHZhcmlvdXMgdGVsZW1ldHJ5IGF0dHJpYnV0ZXMgYWxsb3dpbmcgb3B0aW1h bCBERG9TIGF0dGFjaw0KPiBtaXRpZ2F0aW9uLg0KPiAgICBJdCBzcGVjaWZpZXMgdGhlIG5vcm1h bCB0cmFmZmljIGJhc2VsaW5lIGFuZCBhdHRhY2sgdHJhZmZpYw0KPiB0ZWxlbWV0cnkNCj4gICAg YXR0cmlidXRlcyBhIERPVFMgY2xpZW50IGNhbiBjb252ZXkgdG8gaXRzIERPVFMgc2VydmVyIGlu IHRoZQ0KPiAgICBtaXRpZ2F0aW9uIHJlcXVlc3QsIHRoZSBtaXRpZ2F0aW9uIHN0YXR1cyB0ZWxl bWV0cnkgYXR0cmlidXRlcyBhDQo+IERPVFMNCj4gICAgc2VydmVyIGNhbiBjb21tdW5pY2F0ZSB0 byBhIERPVFMgY2xpZW50LCBhbmQgdGhlIG1pdGlnYXRpb24NCj4gZWZmaWNhY3kNCj4gICAgdGVs ZW1ldHJ5IGF0dHJpYnV0ZXMgYSBET1RTIGNsaWVudCBjYW4gY29tbXVuaWNhdGUgdG8gYSBET1RT DQo+IHNlcnZlci4NCj4gICAgVGhlIHRlbGVtZXRyeSBhdHRyaWJ1dGVzIGNhbiBhc3Npc3QgdGhl IG1pdGlnYXRvciB0byBjaG9vc2UgdGhlDQo+IEREb1MNCj4gICAgbWl0aWdhdGlvbiB0ZWNobmlx dWVzIGFuZCBwZXJmb3JtIG9wdGltYWwgRERvUyBhdHRhY2sgbWl0aWdhdGlvbi4NCj4gDQo+IA0K PiANCj4gDQo+IFBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUgb2YgbWludXRl cyBmcm9tIHRoZSB0aW1lIG9mDQo+IHN1Ym1pc3Npb24NCj4gdW50aWwgdGhlIGh0bWxpemVkIHZl cnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdCB0b29scy5pZXRmLm9yZy4NCj4gDQo+IFRo ZSBJRVRGIFNlY3JldGFyaWF0DQo+IA0KDQo=