From nobody Tue May 5 09:26:08 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 D4B9F3A0979 for ; Tue, 5 May 2020 09:26:05 -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, HTML_MESSAGE=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=smyslov.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id raMFY-I0HRSR for ; Tue, 5 May 2020 09:26:02 -0700 (PDT) Received: from direct.host-care.com (direct.host-care.com [198.136.54.115]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D8D3A3A0970 for ; Tue, 5 May 2020 09:26:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=smyslov.net ; s=default; h=Content-Type:MIME-Version:Message-ID:Date:Subject:In-Reply-To: References:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=Qu63vO44nXJyPWWjTcdyk+nSFOl0jCPGgnnaz5OYbfc=; b=l8IZnQnWXvGbFD1E5egaOYYMpF oq9TSHy+wDvCazkrv4fr8WIJcvnzr5ErzQ1xNiTsteswk7A78oQfOlpE01c+SKr0X6HRjB7GhzMIH 76V8v1S8otEZkiqjRM5sSZvpIBlmL8obcybmzoP09/hOnm18TJfAGcVqoH+MjyylmQeKfvPK15wVj ++QbdI1g4C841FJcenXmrmhd9tOHEyXBlBFA7nFcJQqRuyYTwPYzxTgUJGsM2P6OQSRoUEZJ2AIrZ iJWzHwXc6tCVRgo3dUq5/mS2Vvc9KD0wR7DPj1AzVBwFx7D9bdvFDtenYvXkHz4irrt/LzNxEgnmX o6gmR7lQ==; Received: from 95-27-147-103.broadband.corbina.ru ([95.27.147.103]:51528 helo=chichi) by direct.host-care.com with esmtpsa (TLS1.2) tls TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.93) (envelope-from ) id 1jW0ON-0006Wm-JQ; Tue, 05 May 2020 12:26:00 -0400 From: "Valery Smyslov" To: Cc: "'Xialiang \(Frank, Network Standard & Patent Dept\)'" References: <158857581528.28405.17372040856513106617@ietfa.amsl.com> In-Reply-To: Date: Tue, 5 May 2020 19:25:57 +0300 Message-ID: <006001d622f9$dcab4020$9601c060$@smyslov.net> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0061_01D62313.01FF2EE0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQKU0/ZP1efMZWaDgo/riqXyfDi3SQG8JsZNpw5pk9A= Content-Language: ru X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - direct.host-care.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - smyslov.net X-Get-Message-Sender-Via: direct.host-care.com: authenticated_id: valery@smyslov.net X-Authenticated-Sender: direct.host-care.com: valery@smyslov.net Archived-At: Subject: [Dots] FW: Reminder: Survey on planning for possible online IETF meetings 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, 05 May 2020 16:26:06 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0061_01D62313.01FF2EE0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, forwarded on request from the IETF chair. Please participate in the survey. Regards, Valery. Begin forwarded message: From: IETF Executive Director < exec-director@ietf.org> Subject: Reminder: Survey on planning for possible online IETF meetings Date: May 4, 2020 at 3:03:35 AM EDT To: "IETF Announcement List" Reply-To: ietf108planning@ietf.org This is a reminder that we need the IETF community to help us plan for the possibility that one or more upcoming IETF meetings in 2020 and possibly 2021 may not be able to go ahead in person. You can help us with this by filling out the following survey: https://www.surveymonkey.com/r/5328FFJ So far we have 114 responses and we would ideally like 500 or more. The survey contains the following pages and will take 15-20 minutes to complete: 1. Welcome 2. Online IETF 107 and the subsequent virtual interims 3. Replacing a cancelled in-person meeting 4. Online meeting format and timezone 5. Replicating humming 6. Replicating the hallway environment 7. Fees 8. Thanks and anything else We run the survey in anonymous mode which means that we only see data that you explicitly provide. Thank you in advance for your help. -- Alissa Cooper, IETF Chair Jay Daley, IETF Executive Director Colin Perkins, IRTF Chair _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce ------=_NextPart_000_0061_01D62313.01FF2EE0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

forwarded = on request from the IETF chair. Please participate in the = survey.

 

Regards,

Valery.



Begin forwarded = message:

 

From: IETF = Executive Director <exec-director@ietf.org>

Subject: Reminder: Survey = on planning for possible online IETF = meetings

Date: May 4, 2020 at 3:03:35 AM = EDT

To: "IETF Announcement = List" <ietf-announce@ietf.org>

 

This is a reminder that we need the IETF community to = help us plan for the possibility that one or more upcoming IETF meetings = in 2020 and possibly 2021 may not be able to go ahead in person. =  You can help us with this by filling out the following survey: =

        &n= bsp;   https://www.surveymonkey.= com/r/5328FFJ

So far we have 114 responses and we would = ideally like 500 or more.

The survey contains the following pages = and will take 15-20 minutes to complete:

1. Welcome
2. Online = IETF 107 and the subsequent virtual interims
3. Replacing a cancelled = in-person meeting
4. Online meeting format and timezone
5. = Replicating humming
6. Replicating the hallway environment
7. = Fees
8. Thanks and anything else

We run the survey in = anonymous mode which means that we only see data that you explicitly = provide.

Thank you in advance for your help.

--
Alissa = Cooper, IETF Chair
Jay Daley, IETF Executive Director
Colin = Perkins, IRTF = Chair

_______________________________________________
IETF-Anno= unce mailing = list
IETF-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/i= etf-announce

 

------=_NextPart_000_0061_01D62313.01FF2EE0-- From nobody Wed May 6 01:43:46 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 4EAE33A00AD for ; Wed, 6 May 2020 01:43:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.095 X-Spam-Level: X-Spam-Status: No, score=-2.095 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, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=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 hxdDufK-2H0i for ; Wed, 6 May 2020 01:43:41 -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 7FD733A0064 for ; Wed, 6 May 2020 01:43:41 -0700 (PDT) Received: from opfednr04.francetelecom.fr (unknown [xx.xx.xx.68]) by opfednr22.francetelecom.fr (ESMTP service) with ESMTP id 49H99Q5RrZz10CC; Wed, 6 May 2020 10:43:38 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1588754618; bh=0vE7wxPL9V9OVyGBhTpS68UW9gYmsifaSexyguBDw+c=; h=From:To:Subject:Date:Message-ID:Content-Type:MIME-Version; b=Tm0U/cfaTHkVB8ab3WLx4qGCG2l20tCZ9+LweNz4Txj2SwVhzVCsUdGIq38Ami07H XP7iW6GfSuHabUil3OohKSMC9kCVn0vTH1tNso4CvU0H2jdHfkSz1biuVef2LBZ1zu NC89ozv4CRSzp2OIr9IhFUBImhfat9kqUid3Y58eZaz7dQMdGzUXh8JMpw4E9GcXnS 4ufPafou9TTeiaa3WFT1MBrlvXURy1l/k9pmrSZLhA49sHq0agOW8oQvGpmwwCEE2C pUh2ddxiUl9U5vlyp7z/0sWQjpEdB2UC65qhgsg9a2xaWVH97okX1NTAAsifDpL/uD Q2wXF36HRLuGg== Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.70]) by opfednr04.francetelecom.fr (ESMTP service) with ESMTP id 49H99Q4K9Rz1xpF; Wed, 6 May 2020 10:43:38 +0200 (CEST) From: To: Jon Shallow , "dots@ietf.org" Thread-Topic: [Dots] Telemetry draft: Vendor Specific data reduction Thread-Index: AQHtT51ggH6aH9X9eXlnZao+3cestAGwV+RpAmslRWUBi4S2MAK1mQgLAgiedYICVX/EVAFMNLHJApZBsHgCOgQTJAC9JjJup8T1C3CACs0/cA== Date: Wed, 6 May 2020 08:43:38 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B9330314A7C8E@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> References: <020a01d61954$64b50320$2e1f0960$@jpshallow.com> <00a301d61d37$219f1990$64dd4cb0$@jpshallow.com> <787AE7BB302AE849A7480A190F8B9330314A0CED@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <017201d61d6f$e40b75e0$ac2261a0$@jpshallow.com> <787AE7BB302AE849A7480A190F8B9330314A10FF@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <01d301d61d92$94c9c450$be5d4cf0$@jpshallow.com> <787AE7BB302AE849A7480A190F8B9330314A1A69@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <02e901d61e06$169244d0$43b6ce70$@jpshallow.com> <787AE7BB302AE849A7480A190F8B9330314A1AF9@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <031a01d61e13$52554460$f6ffcd20$@jpshallow.com> <787AE7BB302AE849A7480A190F8B9330314A1B9C@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <035601d61e1d$61d40ca0$257c25e0$@jpshallow.com> In-Reply-To: <035601d61e1d$61d40ca0$257c25e0$@jpshallow.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.245] Content-Type: multipart/alternative; boundary="_000_787AE7BB302AE849A7480A190F8B9330314A7C8EOPEXCAUBMA2corp_" MIME-Version: 1.0 Archived-At: Subject: Re: [Dots] Telemetry draft: Vendor Specific data reduction 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, 06 May 2020 08:43:44 -0000 --_000_787AE7BB302AE849A7480A190F8B9330314A7C8EOPEXCAUBMA2corp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Jon, Agree. I will updated the draft to reflect the outcome of this thread. Cheers, Med De : Jon Shallow [mailto:supjps-ietf@jpshallow.com] Envoy=E9 : mercredi 29 avril 2020 13:58 =C0 : BOUCADAIR Mohamed TGI/OLN; dots@ietf.org Objet : RE: [Dots] Telemetry draft: Vendor Specific data reduction Hi Med, See inline Jon1> Regards Jon From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of mohamed.boucadair@o= range.com Sent: 29 April 2020 12:37 To: Jon Shallow; dots@ietf.org Subject: Re: [Dots] Telemetry draft: Vendor Specific data reduction Re-, The augment to the data channel would be: augment /ietf-data:dots-data/ietf-data:dots-client: +--rw vendor-mapping {dots-telemetry}? +--rw attack-detail* [vendor-id attack-id] +--rw vendor-id uint32 +--rw attack-id string +--rw attack-name string augment /ietf-data:dots-data/ietf-data:capabilities: +--ro vendor-mapping {dots-telemetry}? +--ro attack-detail* [vendor-id attack-id] +--ro vendor-id uint32 +--ro attack-id string +--ro attack-name string Please see inline. Cheers, Med De : Jon Shallow [mailto:supjps-ietf@jpshallow.com] Envoy=E9 : mercredi 29 avril 2020 12:46 =C0 : BOUCADAIR Mohamed TGI/OLN; dots@ietf.org Objet : RE: [Dots] Telemetry draft: Vendor Specific data reduction It is my belief that the client should share the mappings with the server a= s well, even though the server may actually have the mappings because the s= erver is supplied by the same vendor. [Med] Not sure to understand the last part of your sentence. Jon1> If the server and client are provided by the same vendor, then they w= ill both know the vendor-id specific mappings so for the client to send the= m (or the server to respond to respond with them) is not necessarily needed= , but is useful for consistency across all vendors. There is no harm on the server reporting any differences - there is the pos= sibility that 2 clients have 2 different mitigator release versions though = what the client does with the differences (other than log them), I am not s= ure. [Med] The mapping is per client, not per domain. A diff can't be interprete= d as a conflict. Jon1> Good thinking - not an issue. However, the client and server from th= e same vendor may be on different code releases (or attack matching details= ) and so there could be a difference (but I would have expected that one of= the mappings is a superset of the other, not with any replacements, but th= ere may be local modifications ....). However, if the client tells the ser= ver, the server than updates its local, per client, mapping and only uses t= hat mapping for any reporting etc. Similarly, when the client pulls back = the server version of the mapping, it updates the active mapping table to u= se for telemetry being sent by the server, but continues to use the mapping= tables it told the server for telemetry from client to server. ~Jon1 Regards Jon From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of mohamed.boucadair@o= range.com Sent: 29 April 2020 11:29 To: Jon Shallow; dots@ietf.org Subject: Re: [Dots] Telemetry draft: Vendor Specific data reduction Re-, We need to agree if the client has to share its mappings with the server as= well. The use of the data channel would make sense as id/name mapping is s= imilar to the alias handling functionality. Vendor-id should be a key too. Cheers, Med --_000_787AE7BB302AE849A7480A190F8B9330314A7C8EOPEXCAUBMA2corp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Jon,

 

Agree.

 

I will updated the draft to reflect the outcome of this threa= d.

 

Cheers,

Med

 

De : Jon Shallow [mailto:supjps-ietf@jpshallow.com]
Envoy=E9 : mercredi 29 avril 2020 13:58
=C0 : BOUCADAIR Mohamed TGI/OLN; dots@ietf.org
Objet : RE: [Dots] Telemetry draft: Vendor Specific data reduct= ion

 

Hi Med,=

&n= bsp;

See inl= ine Jon1>

&n= bsp;

Regards=

&n= bsp;

Jon

&n= bsp;

From: Dots [ma= ilto: dots-bounces@ietf.org] On Behalf Of mohamed.boucadair@orange.com
Sent: 29 April 2020 12:37
To: Jon Shallow; dots@ietf.org
Subject: Re: [Dots] Telemetry draft: Vendor Specific data reduction<= o:p>

 

Re-,

 

The augment to the data channel would be:

 

  augment /ietf-data:= dots-data/ietf-data:dots-client:

    +--= rw vendor-mapping {dots-telemetry}?

    &n= bsp;  +--rw attack-detail* [vendor-id attack-id]=

    &n= bsp;     +--rw vendor-id    &nb= sp; uint32

    &n= bsp;     +--rw attack-id    &nb= sp; string

    &n= bsp;     +--rw attack-name    string=

  augment /ietf-data:= dots-data/ietf-data:capabilities:

    +--= ro vendor-mapping {dots-telemetry}?

    &n= bsp;  +--ro attack-detail* [vendor-id attack-id]=

    &n= bsp;     +--ro vendor-id    &nb= sp; uint32

    &n= bsp;     +--ro attack-id    &nb= sp; string

    &n= bsp;     +--ro attack-name    string=

 

Please see inline.

 

Cheers,

Med

 

De : Jon Shallow [mailto:supjps-ietf@jpshallow.com]
Envoy=E9 : mercredi 29 avril 2020 12:46
=C0 : BOUCADAIR Mohamed TGI/OLN; dots@ietf.org
Objet : RE: [Dots] Telemetry draft: Vendor Specific data reduct= ion

 

It is m= y belief that the client should share the mappings with the server as well,= even though the server may actually have the mappings because the server i= s supplied by the same vendor.

[Med] Not sure to understand the last pa= rt of your sentence.

<= o:p> 

Jon1>= ; If the server and client are provided by the same vendor, then they will = both know the vendor-id specific mappings so for the client to send them (o= r the server to respond to respond with them) is not necessarily needed, but is useful for consistency across all vendor= s.

 

&n= bsp;

There i= s no harm on the server reporting any differences – there is the poss= ibility that 2 clients have 2 different mitigator release versions though w= hat the client does with the differences (other than log them), I am not sure.

[Med] The mapping is per client, not per= domain. A diff can’t be interpreted as a conflict.

Jon1>= ; Good thinking – not an issue.  However, the client and server = from the same vendor may be on different code releases (or attack matching = details) and so there could be a difference (but I would have expected that one of the mappings is a superset of the other, not wit= h any replacements, but there may be local modifications ….).  H= owever, if the client tells the server, the server than updates its local, = per client, mapping and only uses that mapping for any reporting etc.  Similarly,  when the client pulls back t= he server version of the mapping, it updates the active mapping table to us= e for telemetry being sent by the server, but continues to use the mapping = tables it told the server for telemetry from client to server.

~Jon1

 

&n= bsp;

Regards=

&n= bsp;

Jon

&n= bsp;

From: Dots [ma= ilto: dots-bounces@ietf.org] On Behalf Of mohamed.boucadair@orange.com
Sent: 29 April 2020 11:29
To: Jon Shallow; dots@ietf.org
Subject: Re: [Dots] Telemetry draft: Vendor Specific data reduction<= o:p>

 

Re-,

 

We need to agree if the client has to share its mappings with= the server as well. The use of the data channel would make sense as id/nam= e mapping is similar to the alias handling functionality.=

 

Vendor-id should be a key too.

 

Cheers,

Med<= o:p>

 

--_000_787AE7BB302AE849A7480A190F8B9330314A7C8EOPEXCAUBMA2corp_-- From nobody Fri May 8 04:24:32 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 B1B413A098D; Fri, 8 May 2020 04:24:29 -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.129.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: dots@ietf.org Message-ID: <158893706966.17149.5265528517875494019@ietfa.amsl.com> Date: Fri, 08 May 2020 04:24:29 -0700 Archived-At: Subject: [Dots] I-D Action: draft-ietf-dots-telemetry-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: Fri, 08 May 2020 11:24:30 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DDoS Open Threat Signaling WG of the IETF. Title : Distributed Denial-of-Service Open Threat Signaling (DOTS) Telemetry Authors : Mohamed Boucadair Tirumaleswar Reddy Ehud Doron Meiling Chen Jon Shallow Filename : draft-ietf-dots-telemetry-08.txt Pages : 107 Date : 2020-05-08 Abstract: This document aims to enrich DOTS signal channel protocol with various telemetry attributes allowing optimal Distributed Denial-of- Service 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-08 https://datatracker.ietf.org/doc/html/draft-ietf-dots-telemetry-08 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dots-telemetry-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 May 11 00:08:52 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 E64943A07D6 for ; Mon, 11 May 2020 00:08:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: X-Spam-Status: No, score=-2.096 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, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=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 pH4rXeOQXw5v for ; Mon, 11 May 2020 00:08:48 -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 EC3D93A08AB for ; Mon, 11 May 2020 00:08:47 -0700 (PDT) Received: from opfedar03.francetelecom.fr (unknown [xx.xx.xx.5]) by opfedar26.francetelecom.fr (ESMTP service) with ESMTP id 49LBqf0Q4rzFpqd for ; Mon, 11 May 2020 09:08:46 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1589180926; bh=z5WlLiwCDRplr4VESyVuD9j40XzcA8CQGgQkby1VgQ0=; h=From:To:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=FSiOmaaHdsNXZt/A8H6lqw4M1RtqsKkdK4nts7H9ZdYg8+B1+hjQ/FJK0U8Qe91/U q33cceu/mAx+LZJg0j84l2SJtBk7M0YMeWYBPNSS6fXEFOW06K/dD/IJ7ZcYiJU8ZB n5x0T9SDhDRsE78pjGrC+2P2HbSTKwUXbWI6ePnXMzlommrNuu6UTQEIO1QZw277ZG ryYHbz75iYwsB7L3P6i25TZBsaX0XvO1t1je0f7EGLiVCBoWD2px7eixnPoZs2G0Oo mtTIrGjv6qYjp2dxQXeAorqfVLqsKlnwlZRucwb6O5fDKPdbuRk9GfOqHe2a8iXj3D QobifrbDodaUA== Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.73]) by opfedar03.francetelecom.fr (ESMTP service) with ESMTP id 49LBqd6lNvzCqks for ; Mon, 11 May 2020 09:08:45 +0200 (CEST) From: To: "dots@ietf.org" Thread-Topic: [Dots] I-D Action: draft-ietf-dots-telemetry-08.txt Thread-Index: AQHWJStEMLJnjeWm80SHPugcQgE/SqiieZmA Date: Mon, 11 May 2020 07:08:44 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B9330314B4C20@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> References: <158893706966.17149.5265528517875494019@ietfa.amsl.com> In-Reply-To: <158893706966.17149.5265528517875494019@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.245] 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-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, 11 May 2020 07:08:50 -0000 Hi all,=20 This version integrates the following changes agreed on the list: * the severity level uses the values defined in RFC7970. * the data channel is used to exchange the attack mapping details * telemetry data can be filtered using source-info * ranges and wildcard values can be used in the Uri-Query options We also updated the security considerations section and added Jon as a co-a= uthor. =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: vendredi 8 mai 2020 13:24 > =C0=A0: i-d-announce@ietf.org > Cc=A0: dots@ietf.org > Objet=A0: [Dots] I-D Action: draft-ietf-dots-telemetry-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) Telemetry > Authors : Mohamed Boucadair > Tirumaleswar Reddy > Ehud Doron > Meiling Chen > Jon Shallow > Filename : draft-ietf-dots-telemetry-08.txt > Pages : 107 > Date : 2020-05-08 >=20 > Abstract: > This document aims to enrich DOTS signal channel protocol with > various telemetry attributes allowing optimal Distributed Denial- > of- > Service 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. >=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-08 > https://datatracker.ietf.org/doc/html/draft-ietf-dots-telemetry-08 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dots-telemetry-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 > _______________________________________________ > Dots mailing list > Dots@ietf.org > https://www.ietf.org/mailman/listinfo/dots From nobody Tue May 12 13:22:18 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 2A2A83A0A6A; Tue, 12 May 2020 13:22:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ahK2l5NweknH; Tue, 12 May 2020 13:22:14 -0700 (PDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AC0783A0A65; Tue, 12 May 2020 13:22:10 -0700 (PDT) Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 04CKM6oM014353 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 12 May 2020 16:22:08 -0400 Date: Tue, 12 May 2020 13:22:05 -0700 From: Benjamin Kaduk To: draft-ietf-dots-use-cases.all@ietf.org Cc: dots@ietf.org Message-ID: <20200512202205.GF27494@kduck.mit.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.12.1 (2019-06-15) Archived-At: Subject: [Dots] AD evaluation of draft-ietf-dots-use-cases-20 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, 12 May 2020 20:22:16 -0000 Hi all, This one is in pretty good shape -- I don't have any major comments on it. I did write up some editorial nit-level stuff as a github pull request: https://github.com/dotswg/dots-use-cases/pull/12 . I think that nothing there should be controversial, but please let me know if I am wrong about that. Please confirm that all six authors made significant contributions: I will need to defend this to the rest of the IESG, since per RFC 7322 the author count is generally limited to five individuals. Right now I don't have a good response when someone asks. Section 1 As DDoS solutions are broadly heterogeneous among vendors, the primary goal of DOTS is to provide high-level interaction amongst differing DDoS solutions, such as detecting, initiating, terminating DDoS mitigation assistance or requesting the status of a DDoS mitigation. nit: the list structure is not properly parallel. It looks like the various clauses are meant to be "detecting DDoS", "initiating/terminating mitigation assistance", and "requesting mitigation status", so maybe this could become: % As DDoS solutions are broadly heterogeneous among vendors, the % primary goal of DOTS is to provide high-level interaction amongst % differing DDoS solutions, such as detecting DDoS attacks, % initiating/terminating DDoS mitigation assistance, or requesting the % status of a DDoS mitigation. Section 3.1 Over the course of the attack, the DOTS server of the ITP periodically informs the DOTS client on the enterprise DMS mitigation status, statistics related to DDoS attack traffic mitigation, and related information. Once the DDoS attack has ended, or decreased to the certain level that the enterprise DMS can handle by itself, the DOTS server signals the enterprise DMS DOTS client that the attack has subsided. It's interesting that this is worded in such a way that the (ITP) DOTS server knows the specific threshold for what level of attack traffic the enterprise DMS can handle, since it's the DOTS server signalling to the client that "the attack has subsided". Section 3.3 Upon receipt of the DOTS mitigation request from the DDoS telemetry system, the orchestrator DOTS server responds with an acknowledgment, to avoid retransmission of the request for mitigation. The orchestrator may begin collecting additional fine-grained and specific information from various DDoS telemetry systems in order to correlate the measurements and provide an analysis of the event. Eventually, the orchestrator may ask for additional information from the DDoS telemetry system; however, the collection of this information is out of scope. The last sentence seems to say that how the orchestrator gets data from the initial DOTS client telemtry system is out-of-scope, but the previous sentence talks about the orchestrator collecting information from (other) DOTS telemetry systems. Is that similarly out of scope? If so, then the fact that they are specifically *DOTS* telemetry systems seems irrelevant and we should probably just describe them as generic telemetry or monitoring systems. Upon receiving a request to mitigate a DDoS attack performed over a target, the orchestrator may evaluate the volumetry of the attack as nit(?): is "performed over" a conventional usage? I would have expected something more like "aimed at" given my personal background, but could just be ignorant of typical usage. Also, I think "volumetry" is not the right word here, and just "volume" suffices. filter the traffic. In this case, the DDoS mitigation system implements a DOTS client while the orchestrator implements a DOTS server. Similar to other DOTS use cases, the offloading scenario assumes that some validation checks are followed by the DMS, the orchestrator, or both (e.g., avoid exhausting the resources of the forwarding nodes or disrupting the service). These validation checks are part of the mitigation, and are therefore out of the scope of the document. I know we added this last chunk of text after a long exchange during the last WGLC, and understand the desire to avoid going into too many details on a topic that is mostly out of scope for DOTS. That said, I'd suggest adding a couple more words around "disrupting the service" (especially since some level of service disruption during an attack might be expected!) to help the reader make the link to what kind of validation is expected, perhaps something like "inadvertent disruption of legitimate services". Section 4 In light of my previous comment I don't want to go too far here, but I could see it being relevant to have a note that in the "orchestration" case it's possible for something that locally to one telemetry system looks like an attack is not actually an attack when seen from the broader scope (e.g., of the orchestrator). In the Third Party MSP case we mention BGP as a way to steer traffic to the mitigation service. We could consider (but don't have to) mentioning that efforts to secure BGP will need to be considered when making pre-arrangements for how traffic is to be moved, since in some contexts such BGP announcements could themselves be considered to be an attack. I guess it probably goes without saying that when you add a third-party DMS to your setup, you depend on that third party to be operational in order for your setup to work properly. Section 7 We'll probably get someone asking to move RFC 8612 to be a Normative reference since we use it for terminology, but I don't mind leaving it be for now. Thanks, Ben From nobody Tue May 12 19:12:37 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 131053A0CCE; Tue, 12 May 2020 19:12:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.272 X-Spam-Level: X-Spam-Status: No, score=-2.272 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.173, 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, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.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 8G_k-gTFBXHU; Tue, 12 May 2020 19:12:33 -0700 (PDT) Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0699A3A0CCC; Tue, 12 May 2020 19:12:29 -0700 (PDT) Received: from pps.filterd (m0122331.ppops.net [127.0.0.1]) by mx0b-00190b01.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id 04D23xV6011953; Wed, 13 May 2020 03:12:29 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=date : from : to : cc : subject : message-id : mime-version : content-type; s=jan2016.eng; bh=40YunzrUKgVQPQ+78HZMawqMptGEXrDAKdd62fLvKAA=; b=fAQw8LE3DNDMh5YX/JTBwKJB2DidrscXZd3GKUNOHWFp5olHexfb5Od5HGvqxJK9QXAy wNiMB6PGhWzggEXFCGITu/2CdfHGjRpgXGQyVq+Vnhl4K6RIAU0cfx6d8DwuCQM7ix2m LSZHLtABPaH3L9rIALXiI/7x3kgcqYOJnZ5CM2NxsfPHVP2HDV/Iit/LtJm6yZcnF1nm IZweoMR2GUASLl2ZkpwsGwmdmlWbuKoqZxEFmjyVOLnY8rm6t5+w+rTVEfYDLrU9ScK8 NyzBvp83nZsP5KrduMJLuDLp69jjO1ItguvHkgfRHLTTRBlCnVZQgAs594h6MS6/SXHs QA== Received: from prod-mail-ppoint5 (prod-mail-ppoint5.akamai.com [184.51.33.60] (may be forged)) by mx0b-00190b01.pphosted.com with ESMTP id 3100wmmx92-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 13 May 2020 03:12:29 +0100 Received: from pps.filterd (prod-mail-ppoint5.akamai.com [127.0.0.1]) by prod-mail-ppoint5.akamai.com (8.16.0.27/8.16.0.27) with SMTP id 04D22RTr020706; Tue, 12 May 2020 19:12:28 -0700 Received: from prod-mail-relay11.akamai.com ([172.27.118.250]) by prod-mail-ppoint5.akamai.com with ESMTP id 31016d9u9t-2; Tue, 12 May 2020 19:12:24 -0700 Received: from akamai.com (sea-lp9yo.kendall.corp.akamai.com [172.19.16.134]) by prod-mail-relay11.akamai.com (Postfix) with ESMTP id 9EAE221B83; Wed, 13 May 2020 02:12:23 +0000 (GMT) Date: Tue, 12 May 2020 19:12:22 -0700 From: Benjamin Kaduk To: draft-ietf-dots-signal-filter-control.all@ietf.org, kaduk@mit.edu Cc: dots@ietf.org Message-ID: <20200513021222.GY3811@akamai.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.9.4 (2018-02-28) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.216, 18.0.676 definitions=2020-05-12_08:2020-05-11, 2020-05-12 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-2004280000 definitions=main-2005130017 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.216, 18.0.676 definitions=2020-05-12_08:2020-05-11, 2020-05-12 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 bulkscore=0 priorityscore=1501 lowpriorityscore=0 malwarescore=0 adultscore=0 mlxscore=0 phishscore=0 spamscore=0 suspectscore=0 cotscore=-2147483648 impostorscore=0 mlxlogscore=999 clxscore=1011 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2004280000 definitions=main-2005130017 Archived-At: Subject: [Dots] AD evaluation of draft-ietf-dots-signal-filter-control-03 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, 13 May 2020 02:12:35 -0000 Hi all, This one is also generally in good shape, with mostly nit-level comments. (I didn't find it on github, so those are inline.) I have a nagging suspicion that I'm repeating some comments I made on the core protocol documents (having forgotten the response and thus why the change in question should not be made; my apologies in advance for my poor memory. Section 1.1 The DOTS data channel protocol [I-D.ietf-dots-data-channel] is used for bulk data exchange between DOTS agents to improve the coordination of parties involved in the response to the Distributed nit: s/the/a/ the inbound link to the DOTS client domain. In other words, the DOTS client cannot use the DOTS data channel protocol to withdraw the accept-list filters when a DDoS attack is in progress. This assumes that this DOTS client is the owner of the filtering rule. nit: the last sentence feels a little disconnected from the previous discussion at the moment; I'd suggest adding at the end ", since otherwise this DOTS client would not be authorized to modify it anyway" or similar. Section 1.2 This specification addresses the problems discussed in Section 1.1 by adding the capability of managing filtering rules using the DOTS signal channel protocol, which enables a DOTS client to request the activation (or deactivation) of filtering rules during a DDoS attack. nit: the grammar here does not quite match up ("capability of" vs. "using"); perhaps s/the capability of/a capability for/ (though other fixes are possible). Sample examples are provided in Section 4, in particular: nit: "sample examples" feels redundant; maybe "some examples" or just "examples"? o Section 4.1 illustrates how the filter control extension is used when conflicts with Access Control List (ACLs) are detected and reported by a DOTS server. nit: s/List/Lists/ Section 3.1 A filtering rule controlled by the DOTS signal channel is identified by its ACL name (Section 7.2 of [I-D.ietf-dots-data-channel]). Note The referenced section is just an example; the actual YANG definition is in Section 4.3 thereof. The activation or deactivation of an ACL by the DOTS signal channel overrides the 'activation-type' (defined in Section 7.2 of [I-D.ietf-dots-data-channel]) a priori conveyed with the filtering rules using the DOTS data channel protocol. Is there a way to "cancel" the signal-channel-made changes and revert to the previous activation-type? Or do we just make the client remember the previous status and manually set that status in such a case? Section 3.2.1 Why is the acl-name an optional attribute? What would the interpretation be if it was not provided? intended control of configured filtering rules. Concretely, the DOTS client conveys 'acl-list' attribute with the following sub-attributes in the CBOR body of a mitigation request (see the YANG-encoded structure in Section 3.2.2.1): nit: YANG is a data description language, not an encoding; perhaps "YANG-formatted structure" or just "YANG structure" is better. As the attack evolves, DOTS clients can adjust the 'activation-type' of an ACL conveyed in a mitigation request or control other filters as necessary. This can be achieved by sending a PUT request with a new 'mid' value. This potentially involves a lot of new 'mid' values if many change are made using signal-channel filtering control over the course of a given mitigation. Is this going to cause a noticeable increase in the amount of state required at the DOTS server? If the DOTS client receives a 5.03 (Service Unavailable) with a diagnostic payload indicating a failed ACL update as a response to an initial mitigation or a mitigation with adjusted scope, the DOTS client MUST immediately send a new request which repeats all the parameters as sent in the failed mitigation request but without including the ACL attributes. After the expiry of Max-Age returned Why does this need to be a MUST-level requirement? What if the situation has changed in the interim and the mitigation update is no longer needed? in the 5.03 (Service Unavailable) response, the DOTS client retries with a new mitigation request (i.e., a new 'mid') that repeats all the parameters as sent in the failed mitigation request. Perhaps mention "including the ACL update" for clarity? Section 3.2.2.1 +--rw acl-list* [acl-name] {control-filtering}? A question for the YANG doctor, no doubt, but is there a need for a feature indicator that gates the entire content of a given module (as opposed to just using module-level granularity to indicate support)? Section 3.2.2.2 namespace "urn:ietf:params:xml:ns:yang:ietf-dots-signal-control"; prefix signal-control; Can we think of anything else that might be in scope in the future for which "signal-control" would be ambiguous or a name conflict? list acl-list { key "acl-name"; Seeing this reminds me of a shadow of a memory that list keys are implicitly mandatory, which seems relevant for an earlier comment. [...] } leaf activation-type { type ietf-data:activation-type; default "activate-when-mitigating"; description "Sets the activation type of an ACL."; This structure seems to bind us to having a single activation-type that applies lto all of the ACLs in the acl-list; furthermore, the global structure of where we augment means that we can only have one (acl-list, activation-type) pair within a given mitigation request. I *believe* that is consistent with the core signal protocol in terms of what's expected to be in a single message, but please confirm. Section 4 (The section heading should probably get the same treatment of "Sample Examples" as was previously used, and the body text here as well.) Section 4.1 Host: {host}:{port} nit(?): the data-channel doc just uses "example.com" for the host header field; it's not clear that we need to diverge from that style (applies throughout). The DOTS client can also decide to send a PUT request to deactivate the "an-accept-list" ACL, if suspect traffic is received from an accept-listed source (2001:db8:1234::/48). The structure of that PUT is the same as the one shown in Figure 5. [...] Uri-Path: "mid=124" Just as a sanity-check: this "mid" of 124 is consistent with the note in Section 3.2.1 that adjusting the 'activation-type' "[...] can be achieved by sending a PUT request with a new 'mid' value", so the 124 (vs. 123) is intentional and correct. "ietf-dots-signal-control:acl-list": [ { "ietf-dots-signal-control:acl-name": "an-accept-list", "ietf-dots-signal-control:activation-type": "deactivate" } ] "lifetime": 3600 Shouldn't there be a comma after the ']'? (Have the examples been run through a JSON validator?) Section 4.3 Consider a DOTS client that contacts its DOTS server during 'idle' time to install an accept-list that rate-limits all (or a part thereof) traffic to be forwarded to 2001:db8:123::/48 as a last resort countermeasure whenever required. It does so by sending, for nit: I could imagine a little confusion as to whether the action referenced by "it does so" is the installation of the accept-list (my belief) or the rate-limiting. Perhaps "Installing the accpe-list can be done by sending, [...]"? example, a PUT request shown in Figure 9. The DOTS server installs nit: either "the PUT request shown" or "a PUT request as shown". "actions": { "forwarding": "accept", "rate-limit": "20.00" 20 bytes per second? That seems rather small. For some reason (e.g., the DOTS server, or the mitigator, is lacking a capability or capacity), the DOTS client is still receiving the attack traffic which saturates available links. To soften the nit: I think s/the attack traffic/attack traffic/ is fine grammar. Section 5.1 o Note to the RFC Editor: Please delete (TBA1-TBA2-TBA3) once the CBOR key is assigned from the 1-16383 range. Please update Table 1 accordingly. IIRC the unallocated values in this range include both values with a 2-byte encoding and with a 3-byte encoding; do we have a reason to prefer one or the other? Since we're allocating from an "IETF Review" range, we get to suggest a value to IANA and it's not immediately clear to me how much say the DEs have in which value gets used. Section 6 We may get someone asking "this document uses YANG; why aren't you using the YANG security considerations template?" I guess the signal-channel doc made it through without any particular note in that regard, so maybe we'll be safe for this one, too. I'd consider mentioning that with both signal and data channels available for updating ACL activation status, there is potential for "skew" wherein an update made in one place is ~immediately overridden by another update. Fortunately, there was already some degree of asynchronicity/external-changes possible, so clients should already be prepared for this sort of situation and will cope properly by polling/OBSERVE notification. We could also consider saying something about how the restriction to only changing activation status over the signal channel (but not creating new ACLS entirely) means that if a client hasn't prepared adequately prior to an attack, it can get stuck in a bad place. This, of course, is also not really new with this document, but is a pretty relevant consideration for its use. Similarly, a reminder that bad things happen when a DOTS server fails to maintain namespace separation across clients for ACL names could be in order (but is not required). A compromised DOTS client can use the filtering control capability to exacerbate an ongoing attack. Likewise, such compromised DOTS client may abstain from reacting to an ACL conflict notification received nit: singular/plural mismatch "DOTS client"/"such compromised" (so either "such a compromised" or "DOTS clients"). Thanks, Ben From nobody Tue May 12 20:26:27 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 4F5C23A0D18; Tue, 12 May 2020 20:26:25 -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, FREEMAIL_FROM=0.001, HTML_MESSAGE=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 xVEmr2UfYPDZ; Tue, 12 May 2020 20:26:23 -0700 (PDT) Received: from mail-vs1-xe34.google.com (mail-vs1-xe34.google.com [IPv6:2607:f8b0:4864:20::e34]) (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 130AE3A07C2; Tue, 12 May 2020 20:26:23 -0700 (PDT) Received: by mail-vs1-xe34.google.com with SMTP id e10so9205380vsp.12; Tue, 12 May 2020 20:26:23 -0700 (PDT) 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 :cc; bh=FPN5rPKvbc1eh4WOaRabC1HOepv2ChzBb4ff/eQ7HL4=; b=e2Uo6sAOKB0scq8rsNu3mIEx8lB1z2h92GdmMSY2tA03AydrX34yyxW0OOPOPD+pzr fIOmq1olZj44hljQ/1KfXXmncH1nQNN3/3sJyWNOrA5trLIGTOQcSdhb5V6fjZDxPlaj SJdKMfPortGRKqqLarOu1DciyiOtcmqplg07KTZTTkcoMM6/lCZXfljAs7L1dUFpwyod 9Ftk5EZklwZ1denehu4J+Ls6Fhcny+kt74lcFsu2lniI0MDVY+OfR92H76AT2HjJUNic AZSvOixG7Mpxt/IgwKTXiglD6bQpt9lfcrL0NJ2TXUuopMuv4Dc25iQ/RNwWbYvTIB6Z iBhA== 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:cc; bh=FPN5rPKvbc1eh4WOaRabC1HOepv2ChzBb4ff/eQ7HL4=; b=Hki/1jksdCN+EU7Nfuxp/u3X0oBc+rtv1YI++3sZXTRrEIGna6YdaRbBKps3SADyJM 1i2Cg2aV3BmEoA684gTrTRwmBP9cKq4CJ+awJXUioBh17lk0zs3JEde8L/I+kiXz85+Z Iypg+BR3bD/seZ1eWmOBN51+Fn7BpANjjhx3MSuNyi6gpMsYbBLRvyUQfm/L25mKYHK4 mmPExw9ctEKK3wGe61pVpRxnlxGiKXHHYNBhQLFgWxQibGwrVTGAWuz5CUoj3J0JOFSA +PNZBb8blpvy5SFCwBrxT1Pj0Q+ZLsd1IVVcORVc7Hs0VcVhwtVu8rcSNDUYzfeA7PLx CcmQ== X-Gm-Message-State: AGi0PuYZQUQc4/RuBrk+92AXezArrHpm+0kfZUo3iFBWis92knAsxv+P EWue9boCFqEOourC7EZV0cnkmsFBILPSDo6MRpA= X-Google-Smtp-Source: APiQypKy1UwCx4lsdxJV1My6Mja8hv+7D86bNdTQ3vrKqLhv2rLCDFCN12Wkn1/2xKhBH3e2qp36oX5CRYiopFM9mRw= X-Received: by 2002:a67:2e01:: with SMTP id u1mr17241395vsu.31.1589340381776; Tue, 12 May 2020 20:26:21 -0700 (PDT) MIME-Version: 1.0 References: <20200512202205.GF27494@kduck.mit.edu> In-Reply-To: <20200512202205.GF27494@kduck.mit.edu> From: Daniel Migault Date: Tue, 12 May 2020 23:26:11 -0400 Message-ID: To: Benjamin Kaduk Cc: draft-ietf-dots-use-cases.all@ietf.org, dots Content-Type: multipart/alternative; boundary="000000000000e210cc05a57f24ef" Archived-At: Subject: Re: [Dots] AD evaluation of draft-ietf-dots-use-cases-20 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, 13 May 2020 03:26:25 -0000 --000000000000e210cc05a57f24ef Content-Type: text/plain; charset="UTF-8" Hi Ben, Thank you for the comments. I merge your pull request and will go through the comments in the email in the next two days. Yours, Daniel On Tue, May 12, 2020 at 4:22 PM Benjamin Kaduk wrote: > Hi all, > > This one is in pretty good shape -- I don't have any major comments on it. > I did write up some editorial nit-level stuff as a github pull request: > https://github.com/dotswg/dots-use-cases/pull/12 . I think that nothing > there should be controversial, but please let me know if I am wrong about > that. > > Please confirm that all six authors made significant contributions: I > will need to defend this to the rest of the IESG, since per RFC 7322 the > author count is generally limited to five individuals. Right now I don't > have a good response when someone asks. > > Section 1 > > As DDoS solutions are broadly heterogeneous among vendors, the > primary goal of DOTS is to provide high-level interaction amongst > differing DDoS solutions, such as detecting, initiating, terminating > DDoS mitigation assistance or requesting the status of a DDoS > mitigation. > > nit: the list structure is not properly parallel. It looks like the > various clauses are meant to be "detecting DDoS", > "initiating/terminating mitigation assistance", and "requesting > mitigation status", so maybe this could become: > > % As DDoS solutions are broadly heterogeneous among vendors, the > % primary goal of DOTS is to provide high-level interaction amongst > % differing DDoS solutions, such as detecting DDoS attacks, > % initiating/terminating DDoS mitigation assistance, or requesting the > % status of a DDoS mitigation. > > Section 3.1 > > Over the course of the attack, the DOTS server of the ITP > periodically informs the DOTS client on the enterprise DMS mitigation > status, statistics related to DDoS attack traffic mitigation, and > related information. Once the DDoS attack has ended, or decreased to > the certain level that the enterprise DMS can handle by itself, the > DOTS server signals the enterprise DMS DOTS client that the attack > has subsided. > > It's interesting that this is worded in such a way that the (ITP) DOTS > server knows the specific threshold for what level of attack traffic the > enterprise DMS can handle, since it's the DOTS server signalling to the > client that "the attack has subsided". > > Section 3.3 > > Upon receipt of the DOTS mitigation request from the DDoS telemetry > system, the orchestrator DOTS server responds with an acknowledgment, > to avoid retransmission of the request for mitigation. The > orchestrator may begin collecting additional fine-grained and > specific information from various DDoS telemetry systems in order to > correlate the measurements and provide an analysis of the event. > Eventually, the orchestrator may ask for additional information from > the DDoS telemetry system; however, the collection of this > information is out of scope. > > The last sentence seems to say that how the orchestrator gets data from > the initial DOTS client telemtry system is out-of-scope, but the > previous sentence talks about the orchestrator collecting information > from (other) DOTS telemetry systems. Is that similarly out of scope? > If so, then the fact that they are specifically *DOTS* telemetry systems > seems irrelevant and we should probably just describe them as generic > telemetry or monitoring systems. > > Upon receiving a request to mitigate a DDoS attack performed over a > target, the orchestrator may evaluate the volumetry of the attack as > > nit(?): is "performed over" a conventional usage? I would have expected > something more like "aimed at" given my personal background, but could > just be ignorant of typical usage. > > Also, I think "volumetry" is not the right word here, and just "volume" > suffices. > > filter the traffic. In this case, the DDoS mitigation system > implements a DOTS client while the orchestrator implements a DOTS > server. Similar to other DOTS use cases, the offloading scenario > assumes that some validation checks are followed by the DMS, the > orchestrator, or both (e.g., avoid exhausting the resources of the > forwarding nodes or disrupting the service). These validation checks > are part of the mitigation, and are therefore out of the scope of the > document. > > I know we added this last chunk of text after a long exchange during the > last WGLC, and understand the desire to avoid going into too many > details on a topic that is mostly out of scope for DOTS. That said, I'd > suggest adding a couple more words around "disrupting the service" > (especially since some level of service disruption during an attack > might be expected!) to help the reader make the link to what kind of > validation is expected, perhaps something like "inadvertent disruption > of legitimate services". > > Section 4 > > In light of my previous comment I don't want to go too far here, but I > could see it being relevant to have a note that in the "orchestration" > case it's possible for something that locally to one telemetry system > looks like an attack is not actually an attack when seen from the > broader scope (e.g., of the orchestrator). > > In the Third Party MSP case we mention BGP as a way to steer traffic to > the mitigation service. We could consider (but don't have to) > mentioning that efforts to secure BGP will need to be considered when > making pre-arrangements for how traffic is to be moved, since in some > contexts such BGP announcements could themselves be considered to be an > attack. > > I guess it probably goes without saying that when you add a third-party > DMS to your setup, you depend on that third party to be operational in > order for your setup to work properly. > > Section 7 > > We'll probably get someone asking to move RFC 8612 to be a Normative > reference since we use it for terminology, but I don't mind leaving it > be for now. > > Thanks, > > Ben > > _______________________________________________ > Dots mailing list > Dots@ietf.org > https://www.ietf.org/mailman/listinfo/dots > -- Daniel Migault Ericsson --000000000000e210cc05a57f24ef Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Ben,=C2=A0

Thank you for the comment= s. I merge your pull request and will go through the comments in the email = in the next two days.=C2=A0

Yours,=C2=A0
Daniel
=

On Tue, May 12, 2020 at 4:22 PM Benjamin Kaduk <kaduk@mit.edu> wrote:
Hi all,

This one is in pretty good shape -- I don't have any major comments on = it.
I did write up some editorial nit-level stuff as a github pull request:
https://github.com/dotswg/dots-use-cases/pull/12= .=C2=A0 I think that nothing
there should be controversial, but please let me know if I am wrong about that.

Please confirm that all six authors made significant contributions: I
will need to defend this to the rest of the IESG, since per RFC 7322 the author count is generally limited to five individuals.=C2=A0 Right now I do= n't
have a good response when someone asks.

Section 1

=C2=A0 =C2=A0As DDoS solutions are broadly heterogeneous among vendors, the=
=C2=A0 =C2=A0primary goal of DOTS is to provide high-level interaction amon= gst
=C2=A0 =C2=A0differing DDoS solutions, such as detecting, initiating, termi= nating
=C2=A0 =C2=A0DDoS mitigation assistance or requesting the status of a DDoS<= br> =C2=A0 =C2=A0mitigation.

nit: the list structure is not properly parallel.=C2=A0 It looks like the various clauses are meant to be "detecting DDoS",
"initiating/terminating mitigation assistance", and "request= ing
mitigation status", so maybe this could become:

% As DDoS solutions are broadly heterogeneous among vendors, the
% primary goal of DOTS is to provide high-level interaction amongst
% differing DDoS solutions, such as detecting DDoS attacks,
% initiating/terminating DDoS mitigation assistance, or requesting the
% status of a DDoS mitigation.

Section 3.1

=C2=A0 =C2=A0Over the course of the attack, the DOTS server of the ITP
=C2=A0 =C2=A0periodically informs the DOTS client on the enterprise DMS mit= igation
=C2=A0 =C2=A0status, statistics related to DDoS attack traffic mitigation, = and
=C2=A0 =C2=A0related information.=C2=A0 Once the DDoS attack has ended, or = decreased to
=C2=A0 =C2=A0the certain level that the enterprise DMS can handle by itself= , the
=C2=A0 =C2=A0DOTS server signals the enterprise DMS DOTS client that the at= tack
=C2=A0 =C2=A0has subsided.

It's interesting that this is worded in such a way that the (ITP) DOTS<= br> server knows the specific threshold for what level of attack traffic the enterprise DMS can handle, since it's the DOTS server signalling to the=
client that "the attack has subsided".

Section 3.3

=C2=A0 =C2=A0Upon receipt of the DOTS mitigation request from the DDoS tele= metry
=C2=A0 =C2=A0system, the orchestrator DOTS server responds with an acknowle= dgment,
=C2=A0 =C2=A0to avoid retransmission of the request for mitigation.=C2=A0 T= he
=C2=A0 =C2=A0orchestrator may begin collecting additional fine-grained and<= br> =C2=A0 =C2=A0specific information from various DDoS telemetry systems in or= der to
=C2=A0 =C2=A0correlate the measurements and provide an analysis of the even= t.
=C2=A0 =C2=A0Eventually, the orchestrator may ask for additional informatio= n from
=C2=A0 =C2=A0the DDoS telemetry system; however, the collection of this
=C2=A0 =C2=A0information is out of scope.

The last sentence seems to say that how the orchestrator gets data from
the initial DOTS client telemtry system is out-of-scope, but the
previous sentence talks about the orchestrator collecting information
from (other) DOTS telemetry systems.=C2=A0 Is that similarly out of scope?<= br> If so, then the fact that they are specifically *DOTS* telemetry systems seems irrelevant and we should probably just describe them as generic
telemetry or monitoring systems.

=C2=A0 =C2=A0Upon receiving a request to mitigate a DDoS attack performed o= ver a
=C2=A0 =C2=A0target, the orchestrator may evaluate the volumetry of the att= ack as

nit(?): is "performed over" a conventional usage?=C2=A0 I would h= ave expected
something more like "aimed at" given my personal background, but = could
just be ignorant of typical usage.

Also, I think "volumetry" is not the right word here, and just &q= uot;volume"
suffices.

=C2=A0 =C2=A0filter the traffic.=C2=A0 In this case, the DDoS mitigation sy= stem
=C2=A0 =C2=A0implements a DOTS client while the orchestrator implements a D= OTS
=C2=A0 =C2=A0server.=C2=A0 Similar to other DOTS use cases, the offloading = scenario
=C2=A0 =C2=A0assumes that some validation checks are followed by the DMS, t= he
=C2=A0 =C2=A0orchestrator, or both (e.g., avoid exhausting the resources of= the
=C2=A0 =C2=A0forwarding nodes or disrupting the service).=C2=A0 These valid= ation checks
=C2=A0 =C2=A0are part of the mitigation, and are therefore out of the scope= of the
=C2=A0 =C2=A0document.

I know we added this last chunk of text after a long exchange during the last WGLC, and understand the desire to avoid going into too many
details on a topic that is mostly out of scope for DOTS.=C2=A0 That said, I= 'd
suggest adding a couple more words around "disrupting the service"= ;
(especially since some level of service disruption during an attack
might be expected!) to help the reader make the link to what kind of
validation is expected, perhaps something like "inadvertent disruption=
of legitimate services".

Section 4

In light of my previous comment I don't want to go too far here, but I<= br> could see it being relevant to have a note that in the "orchestration&= quot;
case it's possible for something that locally to one telemetry system looks like an attack is not actually an attack when seen from the
broader scope (e.g., of the orchestrator).

In the Third Party MSP case we mention BGP as a way to steer traffic to
the mitigation service.=C2=A0 We could consider (but don't have to)
mentioning that efforts to secure BGP will need to be considered when
making pre-arrangements for how traffic is to be moved, since in some
contexts such BGP announcements could themselves be considered to be an
attack.

I guess it probably goes without saying that when you add a third-party
DMS to your setup, you depend on that third party to be operational in
order for your setup to work properly.

Section 7

We'll probably get someone asking to move RFC 8612 to be a Normative reference since we use it for terminology, but I don't mind leaving it<= br> be for now.

Thanks,

Ben

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


--
Daniel Migault
Ericsson
--000000000000e210cc05a57f24ef-- From nobody Wed May 13 03:48:04 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 B5BFE3A0DEA; Wed, 13 May 2020 03:48:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: X-Spam-Status: No, score=-2.096 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, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=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 C2eG9Ipt2xtZ; Wed, 13 May 2020 03:48:00 -0700 (PDT) Received: from relais-inet.orange.com (relais-inet.orange.com [80.12.70.34]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8C8DA3A0982; Wed, 13 May 2020 03:47:59 -0700 (PDT) Received: from opfednr06.francetelecom.fr (unknown [xx.xx.xx.70]) by opfednr24.francetelecom.fr (ESMTP service) with ESMTP id 49MWbd5HVwz1ySj; Wed, 13 May 2020 12:47:57 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1589366877; bh=9FwDQ99hPzWMNLY76clBHVF3cAicP6L2n+Hm9fAqU7E=; h=From:To:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=gu3NWTHuRyRO7kjAa194k4RMjA1aGE2gl2b4iFxXrI6gWYC6VG/7aT8/KsG4SMvcp DgVZLnilHGLG96Du3GNbVxucsiceCTcTtMadaDJh95eSCwf3nvQLEjihKBu1V0zIOq fT/+8H1vvyvDCNEPp+XjozEo6r2YcWiTC3G0Boi+TVvJPW1Ycs8VhPR/5Umjq/2pJG D3qzyMMEqH3nxiEN81mj4ddhVrPeLZvxWUxhOPm8mebXWHBMhHEhT2DKXSmZhNm8dl WQX0YEJrfQ3aeVROLNHBPjIHD2X0ymwBVPhaSmh+PQNPhTwHPtHjYSKIWQwXMHTpri MUKPpcGX4kdtw== Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.26]) by opfednr06.francetelecom.fr (ESMTP service) with ESMTP id 49MWbd2ttPzDq7L; Wed, 13 May 2020 12:47:57 +0200 (CEST) From: To: Benjamin Kaduk , "draft-ietf-dots-signal-filter-control.all@ietf.org" , "kaduk@mit.edu" CC: "dots@ietf.org" Thread-Topic: AD evaluation of draft-ietf-dots-signal-filter-control-03 Thread-Index: AQHWKMv5PQcY3V6c0EmI3bO/wMNtRKiln6rg Date: Wed, 13 May 2020 10:47:56 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B9330314B9EE0@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> References: <20200513021222.GY3811@akamai.com> In-Reply-To: <20200513021222.GY3811@akamai.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] AD evaluation of draft-ietf-dots-signal-filter-control-03 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, 13 May 2020 10:48:02 -0000 Hi Ben,=20 Thank you for the review.=20 Please see inline. Cheers, Med > -----Message d'origine----- > De=A0: Benjamin Kaduk [mailto:bkaduk@akamai.com] > Envoy=E9=A0: mercredi 13 mai 2020 04:12 > =C0=A0: draft-ietf-dots-signal-filter-control.all@ietf.org; kaduk@mit.edu > Cc=A0: dots@ietf.org > Objet=A0: AD evaluation of draft-ietf-dots-signal-filter-control-03 >=20 > Hi all, >=20 > This one is also generally in good shape, with mostly nit-level > comments. > (I didn't find it on github, so those are inline.) >=20 > I have a nagging suspicion that I'm repeating some comments I made on > the core protocol documents (having forgotten the response and thus > why > the change in question should not be made; my apologies in advance for > my poor memory. >=20 > Section 1.1 >=20 > The DOTS data channel protocol [I-D.ietf-dots-data-channel] is used > for bulk data exchange between DOTS agents to improve the > coordination of parties involved in the response to the Distributed >=20 > nit: s/the/a/ >=20 [Med] Fixed. Thanks. > the inbound link to the DOTS client domain. In other words, the > DOTS > client cannot use the DOTS data channel protocol to withdraw the > accept-list filters when a DDoS attack is in progress. This > assumes > that this DOTS client is the owner of the filtering rule. >=20 > nit: the last sentence feels a little disconnected from the previous > discussion at the moment; I'd suggest adding at the end ", since > otherwise this DOTS client would not be authorized to modify it > anyway" > or similar. [Med] After rereading, I think we can get rid of it. I deleted that part of= the sentence.=20 >=20 > Section 1.2 >=20 > This specification addresses the problems discussed in Section 1.1 > by > adding the capability of managing filtering rules using the DOTS > signal channel protocol, which enables a DOTS client to request the > activation (or deactivation) of filtering rules during a DDoS > attack. >=20 > nit: the grammar here does not quite match up ("capability of" vs. > "using"); perhaps s/the capability of/a capability for/ (though other > fixes are possible). [Med] Fixed.=20 >=20 > Sample examples are provided in Section 4, in particular: >=20 > nit: "sample examples" feels redundant; maybe "some examples" or just > "examples"? >=20 > o Section 4.1 illustrates how the filter control extension is used > when conflicts with Access Control List (ACLs) are detected and > reported by a DOTS server. >=20 > nit: s/List/Lists/ [Med] Fixed. Thanks. >=20 > Section 3.1 >=20 > A filtering rule controlled by the DOTS signal channel is > identified > by its ACL name (Section 7.2 of [I-D.ietf-dots-data-channel]). > Note >=20 > The referenced section is just an example; the actual YANG definition > is > in Section 4.3 thereof. [Med] pointing to section 4.3 is better. Fixed.=20 >=20 > The activation or deactivation of an ACL by the DOTS signal channel > overrides the 'activation-type' (defined in Section 7.2 of > [I-D.ietf-dots-data-channel]) a priori conveyed with the filtering > rules using the DOTS data channel protocol. >=20 > Is there a way to "cancel" the signal-channel-made changes and revert > to > the previous activation-type? [Med] This is up to the DOTS client to tweak these filtering rules as a fun= ction of the context. For example,=20 - if a rule was deactivated because of a conflict, the client may delete th= at rule - if the rule was a rate-limit, the client will deactivate the rule. =20 I added this NEW text: Once the attack is mitigated, the DOTS client may use the data channel to control the 'activation-type' (e.g., revert to a default value) of some of the filtering rules controlled by the DOTS signal channel or delete some of these filters. This behavior is deployment specific.=20 Do we need to say more? Or do we just make the client remember > the previous status and manually set that status in such a case? >=20 > Section 3.2.1 >=20 > Why is the acl-name an optional attribute?=20 [Med] Because: This specification extends the mitigation request defined in Section 4.4.1 of [I-D.ietf-dots-signal-channel] to convey the intended control of configured filtering rules. A mitigation request does not need to include an acl name to be valid.=20 What would the > interpretation be if it was not provided? [Med] This will be a mitigation request as defined in draft-ietf-dots-signa= l-channel. >=20 > intended control of configured filtering rules. Concretely, the > DOTS > client conveys 'acl-list' attribute with the following sub- > attributes > in the CBOR body of a mitigation request (see the YANG-encoded > structure in Section 3.2.2.1): >=20 > nit: YANG is a data description language, not an encoding; perhaps > "YANG-formatted structure" or just "YANG structure" is better. [Med] Changed to "YANG structure". >=20 > As the attack evolves, DOTS clients can adjust the 'activation- > type' > of an ACL conveyed in a mitigation request or control other filters > as necessary. This can be achieved by sending a PUT request with a > new 'mid' value. >=20 > This potentially involves a lot of new 'mid' values if many change are > made using signal-channel filtering control over the course of a given > mitigation. Is this going to cause a noticeable increase in the > amount > of state required at the DOTS server? [Med] No. Only the request with the highest 'mid' value will be maintained.= =20 We can add a reminder if you think this is useful.=20 >=20 > If the DOTS client receives a 5.03 (Service Unavailable) with a > diagnostic payload indicating a failed ACL update as a response to > an > initial mitigation or a mitigation with adjusted scope, the DOTS > client MUST immediately send a new request which repeats all the > parameters as sent in the failed mitigation request but without > including the ACL attributes. After the expiry of Max-Age returned >=20 > Why does this need to be a MUST-level requirement? What if the > situation has changed in the interim and the mitigation update is no > longer needed? [Med] These requests are supposed to happen in a short interval and clients= have to immediately place a mitigation request to avoid the inconvenience = of including the ACLs.=20 What about the following: =20 s/client MUST immediately/client MUST by default immediately =20 >=20 > in the 5.03 (Service Unavailable) response, the DOTS client retries > with a new mitigation request (i.e., a new 'mid') that repeats all > the parameters as sent in the failed mitigation request. >=20 > Perhaps mention "including the ACL update" for clarity? >=20 [Med] Works for me.=20 > Section 3.2.2.1 >=20 > +--rw acl-list* [acl-name] {control-filtering}? >=20 > A question for the YANG doctor, no doubt, but is there a need for a > feature indicator that gates the entire content of a given module (as > opposed to just using module-level granularity to indicate support)? [Med] I'm not a YANG doctor, but a feature needs to be defined within the m= odule itself to mark parts that are conditional. I don't quite see why a mo= dule need to be explicitly taged as optional. This is actually why it is re= commended that if you have a module with a large set of nodes with an if-fe= ature, to define these nodes in a separate module. >=20 > Section 3.2.2.2 >=20 > namespace > "urn:ietf:params:xml:ns:yang:ietf-dots-signal-control"; > prefix signal-control; >=20 > Can we think of anything else that might be in scope in the future for > which "signal-control" would be ambiguous or a name conflict? [Med] What about "dots-control"? >=20 > list acl-list { > key "acl-name"; >=20 > Seeing this reminds me of a shadow of a memory that list keys are > implicitly mandatory, which seems relevant for an earlier comment. >=20 [Med] If an acl-list is present, then acl-name must be present. Nevertheles= s, an acl-list is not a mandatory.=20 > [...] > } > leaf activation-type { > type ietf-data:activation-type; > default "activate-when-mitigating"; > description > "Sets the activation type of an ACL."; >=20 > This structure seems to bind us to having a single activation-type > that > applies lto all of the ACLs in the acl-list; [Med] Actually, no. We do have an activation-type value for each acl-name i= n the list.=20 furthermore, the global > structure of where we augment means that we can only have one (acl- > list, > activation-type) pair within a given mitigation request. I *believe* > that is consistent with the core signal protocol in terms of what's > expected to be in a single message, but please confirm. >=20 > Section 4 >=20 > (The section heading should probably get the same treatment of "Sample > Examples" as was previously used, and the body text here as well.) [Med] Not sure about this one. Can you please clarify? >=20 > Section 4.1 >=20 > Host: {host}:{port} >=20 > nit(?): the data-channel doc just uses "example.com" for the host > header > field; it's not clear that we need to diverge from that style (applies > throughout). [Med] Good catch. Fixed. Thanks.=20 >=20 > The DOTS client can also decide to send a PUT request to deactivate > the "an-accept-list" ACL, if suspect traffic is received from an > accept-listed source (2001:db8:1234::/48). The structure of that > PUT > is the same as the one shown in Figure 5. >=20 > [...] > Uri-Path: "mid=3D124" >=20 > Just as a sanity-check: this "mid" of 124 is consistent with the note > in > Section 3.2.1 that adjusting the 'activation-type' "[...] can be > achieved by sending a PUT request with a new 'mid' value", so the 124 > (vs. 123) is intentional and correct. [Med] I confirm. >=20 > "ietf-dots-signal-control:acl-list": [ > { > "ietf-dots-signal-control:acl-name": "an-accept-list", > "ietf-dots-signal-control:activation-type": > "deactivate" > } > ] > "lifetime": 3600 >=20 > Shouldn't there be a comma after the ']'? [Med] Yes. Thanks for catching this.=20 > (Have the examples been run through a JSON validator?) [Med] will double check.=20 >=20 > Section 4.3 >=20 > Consider a DOTS client that contacts its DOTS server during 'idle' > time to install an accept-list that rate-limits all (or a part > thereof) traffic to be forwarded to 2001:db8:123::/48 as a last > resort countermeasure whenever required. It does so by sending, > for >=20 > nit: I could imagine a little confusion as to whether the action > referenced by "it does so" is the installation of the accept-list (my > belief) or the rate-limiting. Perhaps "Installing the accpe-list can > be > done by sending, [...]"? [Med] Fixed.=20 >=20 > example, a PUT request shown in Figure 9. The DOTS server installs >=20 > nit: either "the PUT request shown" or "a PUT request as shown". [Med] Fixed. =20 >=20 > "actions": { > "forwarding": "accept", > "rate-limit": "20.00" >=20 > 20 bytes per second? That seems rather small. [Med] Indeed. Will increase the value used in the example. >=20 > For some reason (e.g., the DOTS server, or the mitigator, is > lacking > a capability or capacity), the DOTS client is still receiving the > attack traffic which saturates available links. To soften the >=20 > nit: I think s/the attack traffic/attack traffic/ is fine grammar. >=20 [Med] Fixed.=20 > Section 5.1 >=20 > o Note to the RFC Editor: Please delete (TBA1-TBA2-TBA3) once the > CBOR key is assigned from the 1-16383 range. Please update > Table 1 accordingly. >=20 > IIRC the unallocated values in this range include both values with a > 2-byte encoding and with a 3-byte encoding; do we have a reason to > prefer one or the other? [Med] 2-byte encoding is preferred to keep the message compact.=20 Since we're allocating from an "IETF Review" > range, we get to suggest a value to IANA and it's not immediately > clear > to me how much say the DEs have in which value gets used. [Med] Updated the table to suggest 52/53/54 values.=20 >=20 > Section 6 >=20 > We may get someone asking "this document uses YANG; why aren't you > using > the YANG security considerations template?" I guess the signal- > channel > doc made it through without any particular note in that regard, so > maybe > we'll be safe for this one, too. [Med] Agree. We do say explicitly the following in the signal channel: =3D This YANG module is not intended to be used via NETCONF/ RESTCONF for DOTS server management purposes; such module is out of the scope of this document. It serves only to provide a data model and encoding, but not a management data model. =3D=3D >=20 > I'd consider mentioning that with both signal and data channels > available for updating ACL activation status, there is potential for > "skew" wherein an update made in one place is ~immediately overridden > by > another update. Fortunately, there was already some degree of > asynchronicity/external-changes possible, so clients should already be > prepared for this sort of situation and will cope properly by > polling/OBSERVE notification. [Med] Yeah. =20 >=20 > We could also consider saying something about how the restriction to > only changing activation status over the signal channel (but not > creating new ACLS entirely) means that if a client hasn't prepared > adequately prior to an attack, it can get stuck in a bad place. This, > of course, is also not really new with this document, but is a pretty > relevant consideration for its use. [Med] Good point. Added this NEW text: This specification does not allow to create new filtering rules, which is the responsibility of the DOTS data channel. DOTS client domains should be adequately prepared prior to an attack, e.g., by creating filters that will be activated on demand when an attack is detected. >=20 > Similarly, a reminder that bad things happen when a DOTS server fails > to > maintain namespace separation across clients for ACL names could be in > order (but is not required). [Med] Added this NEW text: As a reminder, DOTS servers must associate filtering rules with the DOTS client that created these resources. Failure to ensure such association by a DOTS server will have severe impact on DOTS client domains. >=20 > A compromised DOTS client can use the filtering control capability > to > exacerbate an ongoing attack. Likewise, such compromised DOTS > client > may abstain from reacting to an ACL conflict notification received >=20 > nit: singular/plural mismatch "DOTS client"/"such compromised" (so > either "such a compromised" or "DOTS clients"). [Med] Fixed. Thanks. >=20 > Thanks, >=20 > Ben From nobody Wed May 13 09:07: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 D3D293A0B7C; Wed, 13 May 2020 09:07:01 -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, FREEMAIL_FROM=0.001, HTML_MESSAGE=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 wA1TaoQSDUfP; Wed, 13 May 2020 09:06:57 -0700 (PDT) Received: from mail-vs1-xe29.google.com (mail-vs1-xe29.google.com [IPv6:2607:f8b0:4864:20::e29]) (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 68B813A1065; Wed, 13 May 2020 09:06:57 -0700 (PDT) Received: by mail-vs1-xe29.google.com with SMTP id m24so86782vsq.10; Wed, 13 May 2020 09:06:57 -0700 (PDT) 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 :cc; bh=xwlVh1QS6B439EoP1T4PCkhvVH3wotdJ9u5ekn3OawM=; b=D+IH01yPstJ2AkZ742+/NbKZ10CpQGivSvCUxcvefgFIs7qGMPbvKdD3BADyyvjNty G04O4c0kT0Mz4dMNb9utOa7nv7uxnEXOsf2L+sE5ZlG/lmy7n6z4SyZEM3DRvoF/1j19 CfunrmZs3AxXOPdS+euP8AdzmMWnnc0D9Guf/7Sqs0LebVy5ullAwO7fKhOk0/zjNAyu uLNzxLChTkEzg1rbCD02azOL42uXjmpV4dLwizHL+cyIBn+OEIqCxeB18Sn97/bAoeYW 1tWyxCn4SKGxS67IBXuT5HQSM6blNSLKDtv658bC7ZgwHkD15sXZu+qPZps+Ht0td+0c 0ZbA== 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:cc; bh=xwlVh1QS6B439EoP1T4PCkhvVH3wotdJ9u5ekn3OawM=; b=nJLcAhLLuHmbLQ7KNR4PNeBK/rftK1FQLrrKILJAwP1p+aqXhzG8Mqba4GhNTRchT3 CDWHIPOEt0YHq9hmNkjgaN0Zn4vAJJP5hOZXpzX6s826LtmA3G+S4dlWMdWqw8FHVF6O 8fhA7k5meUyoTDn9GCyFI+bScLPUT6a4ZMXrrV/m9JsGEcGT2089IfimFe5po70dxI4z cLjErBTLPBpBeWaeBTVgWQLjySMJJt98LP02qXFNfyto2ZJkCaMEBDbCz6/oqYc2QW0S bWJ+QTw4V4Jq020njbFl42Uzdld76GeIZ/sJiYbMKI0y3j75EfYPuJZ0FffgIP2PJn8J mMiw== X-Gm-Message-State: AGi0Pubg6IRVCoJEiNXdYRDf6Qn1ckKHBjqfnHW/1YVhEaUHqsE2HiTh 9U7uUVJ5DRyH1CTQESUbc8G978ofLcIV6dK9SPfNnKW0 X-Google-Smtp-Source: APiQypLhCH8+R+SX7zZ3JI/7B7vYHILQBb4ocgHPuoQmBGrSeCn4CE1D+z//94ikQUT82pIl5Q0h3YPTAHAebzDzJa8= X-Received: by 2002:a67:fc46:: with SMTP id p6mr22056757vsq.169.1589386016163; Wed, 13 May 2020 09:06:56 -0700 (PDT) MIME-Version: 1.0 References: <20200512202205.GF27494@kduck.mit.edu> In-Reply-To: <20200512202205.GF27494@kduck.mit.edu> From: Daniel Migault Date: Wed, 13 May 2020 12:06:45 -0400 Message-ID: To: Benjamin Kaduk Cc: draft-ietf-dots-use-cases.all@ietf.org, dots Content-Type: multipart/alternative; boundary="000000000000e7a2ee05a589c481" Archived-At: Subject: Re: [Dots] AD evaluation of draft-ietf-dots-use-cases-20 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, 13 May 2020 16:07:02 -0000 --000000000000e7a2ee05a589c481 Content-Type: text/plain; charset="UTF-8" Hi, Thank you Ben for you comments. Please find inline how these have been addressed. The updated version has been pushed to [1]. The main questions I have for the co-authors are: * does the change of volumetry to volume causes any concern ? * I guess we could be a little be more specific regarding the delegation and the pre-arrangement, in particular if BGP is secured. Please update the text that has been proposed. Yours, Daniel [1] https://github.com/dotswg/dots-use-cases On Tue, May 12, 2020 at 4:22 PM Benjamin Kaduk wrote: > Hi all, > > This one is in pretty good shape -- I don't have any major comments on it. > I did write up some editorial nit-level stuff as a github pull request: > https://github.com/dotswg/dots-use-cases/pull/12 . I think that nothing > there should be controversial, but please let me know if I am wrong about > that. > > Please confirm that all six authors made significant contributions: I > will need to defend this to the rest of the IESG, since per RFC 7322 the > author count is generally limited to five individuals. Right now I don't > have a good response when someone asks. > As far as I know all authors mentioned significantly contributed to the document. It is true that there are many co-authors, but I think that reflected that DOTS needs to coordinate multiple actors that were not so much coordinated before. > > Section 1 > > As DDoS solutions are broadly heterogeneous among vendors, the > primary goal of DOTS is to provide high-level interaction amongst > differing DDoS solutions, such as detecting, initiating, terminating > DDoS mitigation assistance or requesting the status of a DDoS > mitigation. > > nit: the list structure is not properly parallel. It looks like the > various clauses are meant to be "detecting DDoS", > "initiating/terminating mitigation assistance", and "requesting > mitigation status", so maybe this could become: > > % As DDoS solutions are broadly heterogeneous among vendors, the > % primary goal of DOTS is to provide high-level interaction amongst > % differing DDoS solutions, such as detecting DDoS attacks, > % initiating/terminating DDoS mitigation assistance, or requesting the > % status of a DDoS mitigation. > > fixed > Section 3.1 > > Over the course of the attack, the DOTS server of the ITP > periodically informs the DOTS client on the enterprise DMS mitigation > status, statistics related to DDoS attack traffic mitigation, and > related information. Once the DDoS attack has ended, or decreased to > the certain level that the enterprise DMS can handle by itself, the > DOTS server signals the enterprise DMS DOTS client that the attack > has subsided. > > It's interesting that this is worded in such a way that the (ITP) DOTS > server knows the specific threshold for what level of attack traffic the > enterprise DMS can handle, since it's the DOTS server signalling to the > client that "the attack has subsided". > > In most cases, if I recall correctly, we expect this to reflect a contractual relation. That said, it is ultimately the DOTS client that terminates the mitigation. To remove the impression that the ITP sort of controls the DOTS client, I propose to change "can handle" by "may handle". Here is the updated text: Once the DDoS attack has ended, or decreased to the certain level that the enterprise DMS may handle by itself, the DOTS server signals the enterprise DMS DOTS client that the attack has subsided. Section 3.3 > > Upon receipt of the DOTS mitigation request from the DDoS telemetry > system, the orchestrator DOTS server responds with an acknowledgment, > to avoid retransmission of the request for mitigation. The > orchestrator may begin collecting additional fine-grained and > specific information from various DDoS telemetry systems in order to > correlate the measurements and provide an analysis of the event. > Eventually, the orchestrator may ask for additional information from > the DDoS telemetry system; however, the collection of this > information is out of scope. > > The last sentence seems to say that how the orchestrator gets data from > the initial DOTS client telemtry system is out-of-scope, but the > previous sentence talks about the orchestrator collecting information > from (other) DOTS telemetry systems. Is that similarly out of scope? > If so, then the fact that they are specifically *DOTS* telemetry systems > seems irrelevant and we should probably just describe them as generic > telemetry or monitoring systems. > > I agree that we should not have DOTS telemetry systems and leave them as DDoS telemetry systems. I checked the current version and there is no mention of DOTS telemetry but only DDoS telemetry. I also suggest the we specify that such collection is out of scope of DOTS. with the following sentence: the collection of this information is out of scope of DOTS. > Upon receiving a request to mitigate a DDoS attack performed over a > target, the orchestrator may evaluate the volumetry of the attack as > > nit(?): is "performed over" a conventional usage? I would have expected > something more like "aimed at" given my personal background, but could > just be ignorant of typical usage. > changed. > > Also, I think "volumetry" is not the right word here, and just "volume" > suffices. > I am fine either way. The current version changed to volume, but I am waiting co-authors to confirm they agree with the change. > > filter the traffic. In this case, the DDoS mitigation system > implements a DOTS client while the orchestrator implements a DOTS > server. Similar to other DOTS use cases, the offloading scenario > assumes that some validation checks are followed by the DMS, the > orchestrator, or both (e.g., avoid exhausting the resources of the > forwarding nodes or disrupting the service). These validation checks > are part of the mitigation, and are therefore out of the scope of the > document. > > I know we added this last chunk of text after a long exchange during the > last WGLC, and understand the desire to avoid going into too many > details on a topic that is mostly out of scope for DOTS. That said, I'd > suggest adding a couple more words around "disrupting the service" > (especially since some level of service disruption during an attack > might be expected!) to help the reader make the link to what kind of > validation is expected, perhaps something like "inadvertent disruption > of legitimate services". > > fixed with the follwoing snetence: Similar to other DOTS use cases, the offloading scenario assumes that some validation checks are followed by the DMS, the orchestrator, or both (e.g., avoid exhausting the resources of the forwarding nodes or inadvertent disruption of legitimate services). > Section 4 > > In light of my previous comment I don't want to go too far here, but I > could see it being relevant to have a note that in the "orchestration" > case it's possible for something that locally to one telemetry system > looks like an attack is not actually an attack when seen from the > broader scope (e.g., of the orchestrator). > > I added the note in the following paragraph. These systems are configured so that when an event or some measurement indicators reach a predefined level their associated DOTS client sends a DOTS mitigation request to the orchestrator DOTS server. The DOTS mitigation request may be associated with some optional mitigation hints to let the orchestrator know what has triggered the request. In particular, it's possible for something that locally to one telemetry system looks like an attack is not actually an attack when seen from the broader scope (e.g., of the orchestrator) In the Third Party MSP case we mention BGP as a way to steer traffic to > the mitigation service. We could consider (but don't have to) > mentioning that efforts to secure BGP will need to be considered when > making pre-arrangements for how traffic is to be moved, since in some > contexts such BGP announcements could themselves be considered to be an > attack. > > Being ignorant on BGP, I am wondering if you are thinking of a BGP procedure to announce routes or some procedure for enabling a delegation when BGPsec is considered. I porpose the following text: These exact mechanisms used for traffic steering are out of scope of DOTS, but will need to be pre-arranged, while in some context such changed could be detected and considered as an attack. > I guess it probably goes without saying that when you add a third-party > DMS to your setup, you depend on that third party to be operational in > order for your setup to work properly. > > Section 7 > > We'll probably get someone asking to move RFC 8612 to be a Normative > reference since we use it for terminology, but I don't mind leaving it > be for now. > I put it as normative. > > Thanks, > > Ben > > _______________________________________________ > Dots mailing list > Dots@ietf.org > https://www.ietf.org/mailman/listinfo/dots > -- Daniel Migault Ericsson --000000000000e7a2ee05a589c481 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,=C2=A0

Thank you Ben for = you comments. Please find inline how these have been addressed. The updated= version has been pushed to [1].=C2=A0

The main qu= estions I have for the co-authors are:
* does the change of volum= etry to volume causes any concern ?
* I guess we could be a littl= e be more specific regarding the delegation and the pre-arrangement, in par= ticular if BGP is secured. Please update the=C2=A0text that has been propos= ed.=C2=A0

Yours,=C2=A0
Daniel=C2=A0 =C2= =A0


[1]=C2=A0https://github.com/dotswg/dots-use-cases
=
On Tue= , May 12, 2020 at 4:22 PM Benjamin Kaduk <kaduk@mit.edu> wrote:
Hi all,

This one is in pretty good shape -- I don't have any major comments on = it.
I did write up some editorial nit-level stuff as a github pull request:
https://github.com/dotswg/dots-use-cases/pull/12= .=C2=A0 I think that nothing
there should be controversial, but please let me know if I am wrong about that.

Please confirm that all six authors made significant contributions: I
will need to defend this to the rest of the IESG, since per RFC 7322 the author count is generally limited to five individuals.=C2=A0 Right now I do= n't
have a good response when someone asks.

<mglt>
As far as I know all authors mentioned significantl= y contributed to the document. It is true that there are many co-authors, b= ut I think that reflected that DOTS needs to coordinate multiple actors tha= t were not so much coordinated before.=C2=A0
</mglt>=C2=A0<= /div>

Section 1

=C2=A0 =C2=A0As DDoS solutions are broadly heterogeneous among vendors, the=
=C2=A0 =C2=A0primary goal of DOTS is to provide high-level interaction amon= gst
=C2=A0 =C2=A0differing DDoS solutions, such as detecting, initiating, termi= nating
=C2=A0 =C2=A0DDoS mitigation assistance or requesting the status of a DDoS<= br> =C2=A0 =C2=A0mitigation.

nit: the list structure is not properly parallel.=C2=A0 It looks like the various clauses are meant to be "detecting DDoS",
"initiating/terminating mitigation assistance", and "request= ing
mitigation status", so maybe this could become:

% As DDoS solutions are broadly heterogeneous among vendors, the
% primary goal of DOTS is to provide high-level interaction amongst
% differing DDoS solutions, such as detecting DDoS attacks,
% initiating/terminating DDoS mitigation assistance, or requesting the
% status of a DDoS mitigation.

<mglt>
fixed
</mglt>= =C2=A0
Section 3.1

=C2=A0 =C2=A0Over the course of the attack, the DOTS server of the ITP
=C2=A0 =C2=A0periodically informs the DOTS client on the enterprise DMS mit= igation
=C2=A0 =C2=A0status, statistics related to DDoS attack traffic mitigation, = and
=C2=A0 =C2=A0related information.=C2=A0 Once the DDoS attack has ended, or = decreased to
=C2=A0 =C2=A0the certain level that the enterprise DMS can handle by itself= , the
=C2=A0 =C2=A0DOTS server signals the enterprise DMS DOTS client that the at= tack
=C2=A0 =C2=A0has subsided.

It's interesting that this is worded in such a way that the (ITP) DOTS<= br> server knows the specific threshold for what level of attack traffic the enterprise DMS can handle, since it's the DOTS server signalling to the=
client that "the attack has subsided".

<mglt>
In most cases, if I recall cor= rectly, we expect this to reflect a contractual relation. That said, it is = ultimately the DOTS client that terminates the mitigation. To remove the im= pression that the ITP sort of controls the DOTS client, I propose to change= "can handle" by "may handle".=C2=A0 Here is the update= d text:

Once the DDoS attack has ended, or decreas= ed to the certain
level that the enterprise DMS may handle by itself, th= e DOTS server
signals the enterprise DMS DOTS client that the attack has= subsided.
</mglt>=C2=A0

Section 3.3

=C2=A0 =C2=A0Upon receipt of the DOTS mitigation request from the DDoS tele= metry
=C2=A0 =C2=A0system, the orchestrator DOTS server responds with an acknowle= dgment,
=C2=A0 =C2=A0to avoid retransmission of the request for mitigation.=C2=A0 T= he
=C2=A0 =C2=A0orchestrator may begin collecting additional fine-grained and<= br> =C2=A0 =C2=A0specific information from various DDoS telemetry systems in or= der to
=C2=A0 =C2=A0correlate the measurements and provide an analysis of the even= t.
=C2=A0 =C2=A0Eventually, the orchestrator may ask for additional informatio= n from
=C2=A0 =C2=A0the DDoS telemetry system; however, the collection of this
=C2=A0 =C2=A0information is out of scope.

The last sentence seems to say that how the orchestrator gets data from
the initial DOTS client telemtry system is out-of-scope, but the
previous sentence talks about the orchestrator collecting information
from (other) DOTS telemetry systems.=C2=A0 Is that similarly out of scope?<= br> If so, then the fact that they are specifically *DOTS* telemetry systems seems irrelevant and we should probably just describe them as generic
telemetry or monitoring systems.

<mglt>
I agree that we should not hav= e DOTS telemetry systems and leave them as DDoS telemetry systems. I checke= d the current version and there is no mention of DOTS telemetry but only DD= oS telemetry.=C2=A0
I also suggest the we specify that such colle= ction is out of scope of DOTS. with the following sentence:

<= /div>
the collection of this information is out of scope of DOTS.
</mglt>
=C2=A0
=C2=A0 =C2=A0Upon receiving a request to mitigate a DDoS attack performed o= ver a
=C2=A0 =C2=A0target, the orchestrator may evaluate the volumetry of the att= ack as

nit(?): is "performed over" a conventional usage?=C2=A0 I would h= ave expected
something more like "aimed at" given my personal background, but = could
just be ignorant of typical usage.
<mglt>
<= div>changed.
</mglt>=C2=A0

Also, I think "volumetry" is not the right word here, and just &q= uot;volume"
suffices.
<mglt>
I am fine either way.= The current version changed to volume, but I am waiting co-authors to conf= irm they agree with the change.=C2=A0
</mglt>=C2=A0

=C2=A0 =C2=A0filter the traffic.=C2=A0 In this case, the DDoS mitigation sy= stem
=C2=A0 =C2=A0implements a DOTS client while the orchestrator implements a D= OTS
=C2=A0 =C2=A0server.=C2=A0 Similar to other DOTS use cases, the offloading = scenario
=C2=A0 =C2=A0assumes that some validation checks are followed by the DMS, t= he
=C2=A0 =C2=A0orchestrator, or both (e.g., avoid exhausting the resources of= the
=C2=A0 =C2=A0forwarding nodes or disrupting the service).=C2=A0 These valid= ation checks
=C2=A0 =C2=A0are part of the mitigation, and are therefore out of the scope= of the
=C2=A0 =C2=A0document.

I know we added this last chunk of text after a long exchange during the last WGLC, and understand the desire to avoid going into too many
details on a topic that is mostly out of scope for DOTS.=C2=A0 That said, I= 'd
suggest adding a couple more words around "disrupting the service"= ;
(especially since some level of service disruption during an attack
might be expected!) to help the reader make the link to what kind of
validation is expected, perhaps something like "inadvertent disruption=
of legitimate services".

<mglt>
fixed with the follwoing snete= nce:

Similar to other DOTS use cases, the offloadi= ng scenario assumes that some validation checks are followed by the DMS, th= e orchestrator, or both (e.g., avoid exhausting the resources of the forwar= ding nodes or inadvertent disruption of legitimate services).
</mglt>=C2=A0
Section 4

In light of my previous comment I don't want to go too far here, but I<= br> could see it being relevant to have a note that in the "orchestration&= quot;
case it's possible for something that locally to one telemetry system looks like an attack is not actually an attack when seen from the
broader scope (e.g., of the orchestrator).

<mglt>
I added the note in the follow= ing paragraph.=C2=A0

These systems are configured = so that when an event or some measurement
indicators reach a predefined = level their associated DOTS client sends a
DOTS mitigation request to th= e orchestrator DOTS server. The DOTS
mitigation request may be associate= d with some optional mitigation hints
to let the orchestrator know what = has triggered the request. In particular, it's possible for something t= hat locally to one telemetry system looks like an attack is not actually an= attack when seen from the broader scope (e.g., of the orchestrator)
</mglt>=C2=A0

In the Third Party MSP case we mention BGP as a way to steer traffic to
the mitigation service.=C2=A0 We could consider (but don't have to)
mentioning that efforts to secure BGP will need to be considered when
making pre-arrangements for how traffic is to be moved, since in some
contexts such BGP announcements could themselves be considered to be an
attack.

<mglt>
Being ignorant on BGP, I am wo= ndering if you are thinking of a BGP procedure to announce=C2=A0routes or s= ome procedure for enabling a delegation when BGPsec is considered.=C2=A0
I porpose=C2=A0the following text:

These e= xact mechanisms
used for traffic steering are out of scope of DOTS, but = will need to be pre-arranged, while in some context such changed could be d= etected and considered as an attack.

</mglt>=C2=A0<= /div>
I guess it probably goes without saying that when you add a third-party
DMS to your setup, you depend on that third party to be operational in
order for your setup to work properly.

Section 7

We'll probably get someone asking to move RFC 8612 to be a Normative reference since we use it for terminology, but I don't mind leaving it<= br> be for now.

<mglt>
I pu= t it as normative.=C2=A0
</mglt>=C2=A0

Thanks,

Ben

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


--
Daniel Migault
Ericsson
--000000000000e7a2ee05a589c481-- From nobody Wed May 13 10:06:40 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 320763A0BD8 for ; Wed, 13 May 2020 10:06:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.432 X-Spam-Level: X-Spam-Status: No, score=-1.432 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_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ironmountain.co.uk Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GvzfzjiGt-Wb for ; Wed, 13 May 2020 10:06:33 -0700 (PDT) Received: from mail-ej1-x630.google.com (mail-ej1-x630.google.com [IPv6:2a00:1450:4864:20::630]) (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 9D5A93A0BC5 for ; Wed, 13 May 2020 10:06:33 -0700 (PDT) Received: by mail-ej1-x630.google.com with SMTP id s21so165831ejd.2 for ; Wed, 13 May 2020 10:06:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ironmountain.co.uk; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=8QeETYIxIfRsk4wqgz7Vv4igPueacwXsEG3QxnmaBHE=; b=SZHwfuKni+aRJQgpzi4ICFxN3MrzQY77sQyT4Wwrk+UBT9j04ZqIOHLc31nhd5QJ0G T8UotulplXmc0nEpx4DSXSMW6KOf2Y4f259H3X9LjETCORkHDBYluL+J/a0SMViXyPYm TJrVQzTm5kTIBZNfh9YM6c15WSbO2bUtSHQfI= 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:cc; bh=8QeETYIxIfRsk4wqgz7Vv4igPueacwXsEG3QxnmaBHE=; b=ACMcZ32/Piw3Ly6MK2oCvw/XF2P8gGWb5swbTI9iGYD8J2Q9NbJVO6pNoqqz/hstG6 pZkEENKgFuZ5SQ6DmHiWG1yHOg01wB5mweKXeQVzupJD9gr8YlMzM6dd9tUWlpmtMgiG zruGKtocuyLpdrz2lFeB1gxaeKHSLqIigE3ln+exsRS9MkcnCuemvRiG8K3+vorlPmXE ZMxuOCStUho8hNCURP5UIdoHYUIgy4fzGCYh/7rYye/TcINTXt83BJVCjLqs+7H2BERr 3b+OHPDqP28/83jSvuNStFi7DLdaTRi3kv7wNpTnsBlO/Eas6ff/bNPNcOkfKnURNOYG SKow== X-Gm-Message-State: AGi0PuaTezDyCSUrT+XaoaC/ILFUutK+D+1Mtu1ynb3kCDkPocU8w00f nCTKzoK3HfmhH1Zy1tXEqrU7jD91l4m+D4qYzwm5WMn2pa7fRuOPGY3eqZ5pOftB2Kmc+zS7Ix9 e41FfNOmvguxRb9Y4 X-Google-Smtp-Source: APiQypLPd9arjD5OFbGz0TzoOkFlrLQmaOfzJBGm/GVaosSM1iR40NvxK2PCRqclOm3ldRykBfOrpNDsGYWsyzAgFr4= X-Received: by 2002:a17:906:86d6:: with SMTP id j22mr16321813ejy.1.1589389591307; Wed, 13 May 2020 10:06:31 -0700 (PDT) MIME-Version: 1.0 References: <20200512202205.GF27494@kduck.mit.edu> In-Reply-To: From: "Teague, Francis" Date: Wed, 13 May 2020 18:06:19 +0100 Message-ID: To: Daniel Migault Cc: Benjamin Kaduk , draft-ietf-dots-use-cases.all@ietf.org, dots Content-Type: multipart/alternative; boundary="000000000000007ad105a58a9a5c" Archived-At: Subject: Re: [Dots] AD evaluation of draft-ietf-dots-use-cases-20 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, 13 May 2020 17:06:39 -0000 --000000000000007ad105a58a9a5c Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi, Volumetry is awkward - generally an attack is characterized as volumetric so volume would be correct IMO. On the BGP side - My 2c - There are methods such as RPKI etc. which present concerns for BGP based mitigations where implemented, however, these may be overcome in a number of ways (the mitigator being authorized to originate prefixes using the customer ASN for example during an attack). The methods used to overcome these challenges while remaining compliant with a particular mechanism are really between the requestor and mitigator to thrash out. I'm not sure we should call it out as its part of the wider relationship/onboarding process. It's probably a topic for its own BCP though. Thanks, -Nik On Wed, 13 May 2020 at 17:07, Daniel Migault wrote: > Hi, > > Thank you Ben for you comments. Please find inline how these have been > addressed. The updated version has been pushed to [1]. > > The main questions I have for the co-authors are: > * does the change of volumetry to volume causes any concern ? > * I guess we could be a little be more specific regarding the delegation > and the pre-arrangement, in particular if BGP is secured. Please update > the text that has been proposed. > > Yours, > Daniel > > > [1] https://github.com/dotswg/dots-use-cases > > On Tue, May 12, 2020 at 4:22 PM Benjamin Kaduk wrote: > >> Hi all, >> >> This one is in pretty good shape -- I don't have any major comments on i= t. >> I did write up some editorial nit-level stuff as a github pull request: >> https://github.com/dotswg/dots-use-cases/pull/12 . I think that nothing >> there should be controversial, but please let me know if I am wrong abou= t >> that. >> >> Please confirm that all six authors made significant contributions: I >> will need to defend this to the rest of the IESG, since per RFC 7322 the >> author count is generally limited to five individuals. Right now I don'= t >> have a good response when someone asks. >> > > > As far as I know all authors mentioned significantly contributed to the > document. It is true that there are many co-authors, but I think that > reflected that DOTS needs to coordinate multiple actors that were not so > much coordinated before. > > >> >> Section 1 >> >> As DDoS solutions are broadly heterogeneous among vendors, the >> primary goal of DOTS is to provide high-level interaction amongst >> differing DDoS solutions, such as detecting, initiating, terminating >> DDoS mitigation assistance or requesting the status of a DDoS >> mitigation. >> >> nit: the list structure is not properly parallel. It looks like the >> various clauses are meant to be "detecting DDoS", >> "initiating/terminating mitigation assistance", and "requesting >> mitigation status", so maybe this could become: >> >> % As DDoS solutions are broadly heterogeneous among vendors, the >> % primary goal of DOTS is to provide high-level interaction amongst >> % differing DDoS solutions, such as detecting DDoS attacks, >> % initiating/terminating DDoS mitigation assistance, or requesting the >> % status of a DDoS mitigation. >> >> > fixed > > >> Section 3.1 >> >> Over the course of the attack, the DOTS server of the ITP >> periodically informs the DOTS client on the enterprise DMS mitigation >> status, statistics related to DDoS attack traffic mitigation, and >> related information. Once the DDoS attack has ended, or decreased to >> the certain level that the enterprise DMS can handle by itself, the >> DOTS server signals the enterprise DMS DOTS client that the attack >> has subsided. >> >> It's interesting that this is worded in such a way that the (ITP) DOTS >> server knows the specific threshold for what level of attack traffic the >> enterprise DMS can handle, since it's the DOTS server signalling to the >> client that "the attack has subsided". >> >> > In most cases, if I recall correctly, we expect this to reflect a > contractual relation. That said, it is ultimately the DOTS client that > terminates the mitigation. To remove the impression that the ITP sort of > controls the DOTS client, I propose to change "can handle" by "may > handle". Here is the updated text: > > Once the DDoS attack has ended, or decreased to the certain > level that the enterprise DMS may handle by itself, the DOTS server > signals the enterprise DMS DOTS client that the attack has subsided. > > > Section 3.3 >> >> Upon receipt of the DOTS mitigation request from the DDoS telemetry >> system, the orchestrator DOTS server responds with an acknowledgment, >> to avoid retransmission of the request for mitigation. The >> orchestrator may begin collecting additional fine-grained and >> specific information from various DDoS telemetry systems in order to >> correlate the measurements and provide an analysis of the event. >> Eventually, the orchestrator may ask for additional information from >> the DDoS telemetry system; however, the collection of this >> information is out of scope. >> >> The last sentence seems to say that how the orchestrator gets data from >> the initial DOTS client telemtry system is out-of-scope, but the >> previous sentence talks about the orchestrator collecting information >> from (other) DOTS telemetry systems. Is that similarly out of scope? >> If so, then the fact that they are specifically *DOTS* telemetry systems >> seems irrelevant and we should probably just describe them as generic >> telemetry or monitoring systems. >> >> > I agree that we should not have DOTS telemetry systems and leave them as > DDoS telemetry systems. I checked the current version and there is no > mention of DOTS telemetry but only DDoS telemetry. > I also suggest the we specify that such collection is out of scope of > DOTS. with the following sentence: > > the collection of this information is out of scope of DOTS. > > > >> Upon receiving a request to mitigate a DDoS attack performed over a >> target, the orchestrator may evaluate the volumetry of the attack as >> >> nit(?): is "performed over" a conventional usage? I would have expected >> something more like "aimed at" given my personal background, but could >> just be ignorant of typical usage. >> > > changed. > > >> >> Also, I think "volumetry" is not the right word here, and just "volume" >> suffices. >> > > I am fine either way. The current version changed to volume, but I am > waiting co-authors to confirm they agree with the change. > > >> >> filter the traffic. In this case, the DDoS mitigation system >> implements a DOTS client while the orchestrator implements a DOTS >> server. Similar to other DOTS use cases, the offloading scenario >> assumes that some validation checks are followed by the DMS, the >> orchestrator, or both (e.g., avoid exhausting the resources of the >> forwarding nodes or disrupting the service). These validation checks >> are part of the mitigation, and are therefore out of the scope of the >> document. >> >> I know we added this last chunk of text after a long exchange during the >> last WGLC, and understand the desire to avoid going into too many >> details on a topic that is mostly out of scope for DOTS. That said, I'd >> suggest adding a couple more words around "disrupting the service" >> (especially since some level of service disruption during an attack >> might be expected!) to help the reader make the link to what kind of >> validation is expected, perhaps something like "inadvertent disruption >> of legitimate services". >> >> > fixed with the follwoing snetence: > > Similar to other DOTS use cases, the offloading scenario assumes that som= e > validation checks are followed by the DMS, the orchestrator, or both (e.g= ., > avoid exhausting the resources of the forwarding nodes or inadvertent > disruption of legitimate services). > > >> Section 4 >> >> In light of my previous comment I don't want to go too far here, but I >> could see it being relevant to have a note that in the "orchestration" >> case it's possible for something that locally to one telemetry system >> looks like an attack is not actually an attack when seen from the >> broader scope (e.g., of the orchestrator). >> >> > I added the note in the following paragraph. > > These systems are configured so that when an event or some measurement > indicators reach a predefined level their associated DOTS client sends a > DOTS mitigation request to the orchestrator DOTS server. The DOTS > mitigation request may be associated with some optional mitigation hints > to let the orchestrator know what has triggered the request. In > particular, it's possible for something that locally to one telemetry > system looks like an attack is not actually an attack when seen from the > broader scope (e.g., of the orchestrator) > > > In the Third Party MSP case we mention BGP as a way to steer traffic to >> the mitigation service. We could consider (but don't have to) >> mentioning that efforts to secure BGP will need to be considered when >> making pre-arrangements for how traffic is to be moved, since in some >> contexts such BGP announcements could themselves be considered to be an >> attack. >> >> > Being ignorant on BGP, I am wondering if you are thinking of a BGP > procedure to announce routes or some procedure for enabling a delegation > when BGPsec is considered. > I porpose the following text: > > These exact mechanisms > used for traffic steering are out of scope of DOTS, but will need to be > pre-arranged, while in some context such changed could be detected and > considered as an attack. > > > >> I guess it probably goes without saying that when you add a third-party >> DMS to your setup, you depend on that third party to be operational in >> order for your setup to work properly. >> >> Section 7 >> >> We'll probably get someone asking to move RFC 8612 to be a Normative >> reference since we use it for terminology, but I don't mind leaving it >> be for now. >> > > > I put it as normative. > > >> >> Thanks, >> >> Ben >> >> _______________________________________________ >> Dots mailing list >> Dots@ietf.org >> https://www.ietf.org/mailman/listinfo/dots >> > > > -- > Daniel Migault > Ericsson > --=20 The information contained in this email message and its attachments is=20 intended only for the private and confidential use of the recipient(s)=20 named above, unless the sender expressly agrees otherwise. Transmission of= =20 email over the Internet is not a secure communications medium. If you are= =20 requesting or have requested the transmittal of personal data, as defined= =20 in applicable privacy laws by means of email or in an attachment to email,= =20 you must select a more secure alternate means of transmittal that supports= =20 your obligations to protect such personal data.=C2=A0 If the reader of this=20 message is not the intended recipient and/or you have received this email= =20 in error, you must take no action based on the information in this email=20 and you are hereby notified that any dissemination, misuse or copying or=20 disclosure of this communication is strictly prohibited. If you have=20 received this communication in error, please notify us immediately by email= =20 and delete the original message.=C2=A0 --000000000000007ad105a58a9a5c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

Volumetry is awkwa= rd - generally an attack is characterized as volumetric=C2=A0so volume woul= d be correct IMO.

On the BGP side - My 2c - There = are methods such as RPKI etc. which present concerns=C2=A0for BGP based mit= igations where implemented, however, these may be overcome=C2=A0in a number= of ways (the mitigator being authorized to originate prefixes using the cu= stomer ASN for example during an attack).=C2=A0 The methods used to overcom= e these challenges while remaining compliant with a particular mechanism ar= e really between the requestor and mitigator to thrash out.=C2=A0 I'm n= ot sure we should call it out as its part of the wider relationship/onboard= ing process.=C2=A0 It's probably a topic for its own BCP though.
<= div>
Thanks,

-Nik

On Wed, 13 Ma= y 2020 at 17:07, Daniel Migault <mglt.ietf@gmail.com> wrote:
Hi,=C2=A0
<= div>
Thank you Ben for you comments. Please find inline how t= hese have been addressed. The updated version has been pushed to [1].=C2=A0=

The main questions I have for the co-authors are:=
* does the change of volumetry to volume causes any concern ?
* I guess we could be a little be more specific regarding the deleg= ation and the pre-arrangement, in particular if BGP is secured. Please upda= te the=C2=A0text that has been proposed.=C2=A0

You= rs,=C2=A0
Daniel=C2=A0 =C2=A0


= [1]=C2=A0https://github.com/dotswg/dots-use-cases

On Tue, May 12, 2020 at 4:2= 2 PM Benjamin Kaduk <= kaduk@mit.edu> wrote:
Hi all,

This one is in pretty good shape -- I don't have any major comments on = it.
I did write up some editorial nit-level stuff as a github pull request:
https://github.com/dotswg/dots-use-cases/pull/12= .=C2=A0 I think that nothing
there should be controversial, but please let me know if I am wrong about that.

Please confirm that all six authors made significant contributions: I
will need to defend this to the rest of the IESG, since per RFC 7322 the author count is generally limited to five individuals.=C2=A0 Right now I do= n't
have a good response when someone asks.

<mglt>
As far as I know all authors mentioned significantl= y contributed to the document. It is true that there are many co-authors, b= ut I think that reflected that DOTS needs to coordinate multiple actors tha= t were not so much coordinated before.=C2=A0
</mglt>=C2=A0<= /div>

Section 1

=C2=A0 =C2=A0As DDoS solutions are broadly heterogeneous among vendors, the=
=C2=A0 =C2=A0primary goal of DOTS is to provide high-level interaction amon= gst
=C2=A0 =C2=A0differing DDoS solutions, such as detecting, initiating, termi= nating
=C2=A0 =C2=A0DDoS mitigation assistance or requesting the status of a DDoS<= br> =C2=A0 =C2=A0mitigation.

nit: the list structure is not properly parallel.=C2=A0 It looks like the various clauses are meant to be "detecting DDoS",
"initiating/terminating mitigation assistance", and "request= ing
mitigation status", so maybe this could become:

% As DDoS solutions are broadly heterogeneous among vendors, the
% primary goal of DOTS is to provide high-level interaction amongst
% differing DDoS solutions, such as detecting DDoS attacks,
% initiating/terminating DDoS mitigation assistance, or requesting the
% status of a DDoS mitigation.

<mglt>
fixed
</mglt>= =C2=A0
Section 3.1

=C2=A0 =C2=A0Over the course of the attack, the DOTS server of the ITP
=C2=A0 =C2=A0periodically informs the DOTS client on the enterprise DMS mit= igation
=C2=A0 =C2=A0status, statistics related to DDoS attack traffic mitigation, = and
=C2=A0 =C2=A0related information.=C2=A0 Once the DDoS attack has ended, or = decreased to
=C2=A0 =C2=A0the certain level that the enterprise DMS can handle by itself= , the
=C2=A0 =C2=A0DOTS server signals the enterprise DMS DOTS client that the at= tack
=C2=A0 =C2=A0has subsided.

It's interesting that this is worded in such a way that the (ITP) DOTS<= br> server knows the specific threshold for what level of attack traffic the enterprise DMS can handle, since it's the DOTS server signalling to the=
client that "the attack has subsided".

<mglt>
In most cases, if I recall cor= rectly, we expect this to reflect a contractual relation. That said, it is = ultimately the DOTS client that terminates the mitigation. To remove the im= pression that the ITP sort of controls the DOTS client, I propose to change= "can handle" by "may handle".=C2=A0 Here is the update= d text:

Once the DDoS attack has ended, or decreas= ed to the certain
level that the enterprise DMS may handle by itself, th= e DOTS server
signals the enterprise DMS DOTS client that the attack has= subsided.
</mglt>=C2=A0

Section 3.3

=C2=A0 =C2=A0Upon receipt of the DOTS mitigation request from the DDoS tele= metry
=C2=A0 =C2=A0system, the orchestrator DOTS server responds with an acknowle= dgment,
=C2=A0 =C2=A0to avoid retransmission of the request for mitigation.=C2=A0 T= he
=C2=A0 =C2=A0orchestrator may begin collecting additional fine-grained and<= br> =C2=A0 =C2=A0specific information from various DDoS telemetry systems in or= der to
=C2=A0 =C2=A0correlate the measurements and provide an analysis of the even= t.
=C2=A0 =C2=A0Eventually, the orchestrator may ask for additional informatio= n from
=C2=A0 =C2=A0the DDoS telemetry system; however, the collection of this
=C2=A0 =C2=A0information is out of scope.

The last sentence seems to say that how the orchestrator gets data from
the initial DOTS client telemtry system is out-of-scope, but the
previous sentence talks about the orchestrator collecting information
from (other) DOTS telemetry systems.=C2=A0 Is that similarly out of scope?<= br> If so, then the fact that they are specifically *DOTS* telemetry systems seems irrelevant and we should probably just describe them as generic
telemetry or monitoring systems.

<mglt>
I agree that we should not hav= e DOTS telemetry systems and leave them as DDoS telemetry systems. I checke= d the current version and there is no mention of DOTS telemetry but only DD= oS telemetry.=C2=A0
I also suggest the we specify that such colle= ction is out of scope of DOTS. with the following sentence:

<= /div>
the collection of this information is out of scope of DOTS.
</mglt>
=C2=A0
=C2=A0 =C2=A0Upon receiving a request to mitigate a DDoS attack performed o= ver a
=C2=A0 =C2=A0target, the orchestrator may evaluate the volumetry of the att= ack as

nit(?): is "performed over" a conventional usage?=C2=A0 I would h= ave expected
something more like "aimed at" given my personal background, but = could
just be ignorant of typical usage.
<mglt>
<= div>changed.
</mglt>=C2=A0

Also, I think "volumetry" is not the right word here, and just &q= uot;volume"
suffices.
<mglt>
I am fine either way.= The current version changed to volume, but I am waiting co-authors to conf= irm they agree with the change.=C2=A0
</mglt>=C2=A0

=C2=A0 =C2=A0filter the traffic.=C2=A0 In this case, the DDoS mitigation sy= stem
=C2=A0 =C2=A0implements a DOTS client while the orchestrator implements a D= OTS
=C2=A0 =C2=A0server.=C2=A0 Similar to other DOTS use cases, the offloading = scenario
=C2=A0 =C2=A0assumes that some validation checks are followed by the DMS, t= he
=C2=A0 =C2=A0orchestrator, or both (e.g., avoid exhausting the resources of= the
=C2=A0 =C2=A0forwarding nodes or disrupting the service).=C2=A0 These valid= ation checks
=C2=A0 =C2=A0are part of the mitigation, and are therefore out of the scope= of the
=C2=A0 =C2=A0document.

I know we added this last chunk of text after a long exchange during the last WGLC, and understand the desire to avoid going into too many
details on a topic that is mostly out of scope for DOTS.=C2=A0 That said, I= 'd
suggest adding a couple more words around "disrupting the service"= ;
(especially since some level of service disruption during an attack
might be expected!) to help the reader make the link to what kind of
validation is expected, perhaps something like "inadvertent disruption=
of legitimate services".

<mglt>
fixed with the follwoing snete= nce:

Similar to other DOTS use cases, the offloadi= ng scenario assumes that some validation checks are followed by the DMS, th= e orchestrator, or both (e.g., avoid exhausting the resources of the forwar= ding nodes or inadvertent disruption of legitimate services).
</mglt>=C2=A0
Section 4

In light of my previous comment I don't want to go too far here, but I<= br> could see it being relevant to have a note that in the "orchestration&= quot;
case it's possible for something that locally to one telemetry system looks like an attack is not actually an attack when seen from the
broader scope (e.g., of the orchestrator).

<mglt>
I added the note in the follow= ing paragraph.=C2=A0

These systems are configured = so that when an event or some measurement
indicators reach a predefined = level their associated DOTS client sends a
DOTS mitigation request to th= e orchestrator DOTS server. The DOTS
mitigation request may be associate= d with some optional mitigation hints
to let the orchestrator know what = has triggered the request. In particular, it's possible for something t= hat locally to one telemetry system looks like an attack is not actually an= attack when seen from the broader scope (e.g., of the orchestrator)
</mglt>=C2=A0

In the Third Party MSP case we mention BGP as a way to steer traffic to
the mitigation service.=C2=A0 We could consider (but don't have to)
mentioning that efforts to secure BGP will need to be considered when
making pre-arrangements for how traffic is to be moved, since in some
contexts such BGP announcements could themselves be considered to be an
attack.

<mglt>
Being ignorant on BGP, I am wo= ndering if you are thinking of a BGP procedure to announce=C2=A0routes or s= ome procedure for enabling a delegation when BGPsec is considered.=C2=A0
I porpose=C2=A0the following text:

These e= xact mechanisms
used for traffic steering are out of scope of DOTS, but = will need to be pre-arranged, while in some context such changed could be d= etected and considered as an attack.

</mglt>=C2=A0<= /div>
I guess it probably goes without saying that when you add a third-party
DMS to your setup, you depend on that third party to be operational in
order for your setup to work properly.

Section 7

We'll probably get someone asking to move RFC 8612 to be a Normative reference since we use it for terminology, but I don't mind leaving it<= br> be for now.

<mglt>
I pu= t it as normative.=C2=A0
</mglt>=C2=A0

Thanks,

Ben

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


--
Daniel Migault
Ericsson

= The information contained in this email message and its attachments is inte= nded only for the private and confidential use of the recipient(s) named ab= ove, unless the sender expressly agrees otherwise. Transmission of email ov= er the Internet is not a secure communications medium. If you are requestin= g or have requested the transmittal of personal data, as defined in applica= ble privacy laws by means of email or in an attachment to email, you must s= elect a more secure alternate means of transmittal that supports your oblig= ations to protect such personal data.=C2=A0

If the reader of this message is not the intended recipient= and/or you have received this email in error, you must take no action base= d on the information in this email and you are hereby notified that any dis= semination, misuse or copying or disclosure of this communication is strict= ly prohibited. If you have received this communication in error, please not= ify us immediately by email and delete the original message.=C2=A0
--000000000000007ad105a58a9a5c-- From nobody Wed May 13 19:24:19 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 CA5C83A0926; Wed, 13 May 2020 19:24:16 -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, FREEMAIL_FROM=0.001, HTML_MESSAGE=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 I8JeZv-oGJc8; Wed, 13 May 2020 19:24:13 -0700 (PDT) Received: from mail-vs1-xe36.google.com (mail-vs1-xe36.google.com [IPv6:2607:f8b0:4864:20::e36]) (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 053AC3A080C; Wed, 13 May 2020 19:24:12 -0700 (PDT) Received: by mail-vs1-xe36.google.com with SMTP id z1so1045029vsn.11; Wed, 13 May 2020 19:24:12 -0700 (PDT) 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 :cc; bh=nynzSq3MdQHvO2UPBKuZHIQ7jDJz6X30y958RMV+sns=; b=ccB+MywwUhDS3MeFLi6gK3RHgdsis3Oeb1JwBK0NgxLcnMrVddWh8IuglpWb2pxwuH fkBV57f7cMQo+39ke/R/eJW7o3TJbMFUhCkNAqAGDIFwZxudIQ9hqY92WoN2MUIxDG9h KMRw8Z0Z7eV+CUX1lFJPY5xyX3q4EhY8AXN7QX504b6hgeOJ02MuExGNeh9AVJ1SNxSJ 95O4W3PQYNIdSpBWaUXgcC7rObzKn9v6d4q+7Tdu75hVL0SyHBqllS+AFjwA66S9qd93 zxFtgHZV/FXMJx4XZMXlgqJPUplHxEXM8WJsyI0kIgQBdPZk1sI6/dv/x1W9DQ0xD0ek KWbA== 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:cc; bh=nynzSq3MdQHvO2UPBKuZHIQ7jDJz6X30y958RMV+sns=; b=jNfK2djrTuWqbXgEaQ75tjM0i6hgRF5NedVj/8YjyjK4ZFBYYO50KkZdL2AFi9L0sK fFfZ9W1dE/q9o4MHuuwC2eoUKfDbjS6+LodkIUQQ7BWGnSX4x8Xbe6DwU2nmnvaaanJK 7JCvIhtE8eOuqSeEPEGjQ2wdGaXGgTsq7OjW+KT60MCsZ60X5ayWY7JPXuKluKRkiagh Yl8JJ+Hd/s7ABO5ljxzaHE5FhqOppoS1RZsDt54QF9XeGHXKNLnerD+PzFRaD/NkvouJ otFivKW/itU1uitA3KEEzGeoV8lMAStBds2461WUBuCzsLpvTlg8r4PaoUm5tKVwM7MU yk3w== X-Gm-Message-State: AOAM530URLchC3H/XfFD1qTsq8TAAt5LEHrVaO4uqUabBqESn3yDh8TX w+VAYw/oeqamkrcBSkNx1aCgOKCaSlJ5SVWlwmc= X-Google-Smtp-Source: ABdhPJydK4Yj8zI5XgaaqLlrBMz6cMQEbXZPvVsSUuEIenxtWZWa9noWvgCr3h424KtNsUhewirJikNUvSBQV32Jdt0= X-Received: by 2002:a67:fc46:: with SMTP id p6mr1785377vsq.169.1589423051638; Wed, 13 May 2020 19:24:11 -0700 (PDT) MIME-Version: 1.0 References: <20200512202205.GF27494@kduck.mit.edu> In-Reply-To: From: Daniel Migault Date: Wed, 13 May 2020 22:24:00 -0400 Message-ID: To: "Teague, Francis" Cc: Benjamin Kaduk , draft-ietf-dots-use-cases.all@ietf.org, dots Content-Type: multipart/alternative; boundary="000000000000640d3a05a5926466" Archived-At: Subject: Re: [Dots] AD evaluation of draft-ietf-dots-use-cases-20 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, 14 May 2020 02:24:18 -0000 --000000000000640d3a05a5926466 Content-Type: text/plain; charset="UTF-8" Thanks for the feed back Nick. I sort of understand that the current text fits your comment, but prefer to double check before publishing the next version. Feel free to change the text as you wish. Here is the text in question: """ These exact mechanisms used for traffic steering are out of scope of DOTS, but will need to be pre-arranged, while in some context such changed could be detected and considered as an attack. """ Yours, Daniel On Wed, May 13, 2020 at 1:06 PM Teague, Francis wrote: > Hi, > > Volumetry is awkward - generally an attack is characterized as > volumetric so volume would be correct IMO. > > On the BGP side - My 2c - There are methods such as RPKI etc. which > present concerns for BGP based mitigations where implemented, however, > these may be overcome in a number of ways (the mitigator being authorized > to originate prefixes using the customer ASN for example during an > attack). The methods used to overcome these challenges while remaining > compliant with a particular mechanism are really between the requestor and > mitigator to thrash out. I'm not sure we should call it out as its part of > the wider relationship/onboarding process. It's probably a topic for its > own BCP though. > > Thanks, > > -Nik > > On Wed, 13 May 2020 at 17:07, Daniel Migault wrote: > >> Hi, >> >> Thank you Ben for you comments. Please find inline how these have been >> addressed. The updated version has been pushed to [1]. >> >> The main questions I have for the co-authors are: >> * does the change of volumetry to volume causes any concern ? >> * I guess we could be a little be more specific regarding the delegation >> and the pre-arrangement, in particular if BGP is secured. Please update >> the text that has been proposed. >> >> Yours, >> Daniel >> >> >> [1] https://github.com/dotswg/dots-use-cases >> >> On Tue, May 12, 2020 at 4:22 PM Benjamin Kaduk wrote: >> >>> Hi all, >>> >>> This one is in pretty good shape -- I don't have any major comments on >>> it. >>> I did write up some editorial nit-level stuff as a github pull request: >>> https://github.com/dotswg/dots-use-cases/pull/12 . I think that nothing >>> there should be controversial, but please let me know if I am wrong about >>> that. >>> >>> Please confirm that all six authors made significant contributions: I >>> will need to defend this to the rest of the IESG, since per RFC 7322 the >>> author count is generally limited to five individuals. Right now I don't >>> have a good response when someone asks. >>> >> >> >> As far as I know all authors mentioned significantly contributed to the >> document. It is true that there are many co-authors, but I think that >> reflected that DOTS needs to coordinate multiple actors that were not so >> much coordinated before. >> >> >>> >>> Section 1 >>> >>> As DDoS solutions are broadly heterogeneous among vendors, the >>> primary goal of DOTS is to provide high-level interaction amongst >>> differing DDoS solutions, such as detecting, initiating, terminating >>> DDoS mitigation assistance or requesting the status of a DDoS >>> mitigation. >>> >>> nit: the list structure is not properly parallel. It looks like the >>> various clauses are meant to be "detecting DDoS", >>> "initiating/terminating mitigation assistance", and "requesting >>> mitigation status", so maybe this could become: >>> >>> % As DDoS solutions are broadly heterogeneous among vendors, the >>> % primary goal of DOTS is to provide high-level interaction amongst >>> % differing DDoS solutions, such as detecting DDoS attacks, >>> % initiating/terminating DDoS mitigation assistance, or requesting the >>> % status of a DDoS mitigation. >>> >>> >> fixed >> >> >>> Section 3.1 >>> >>> Over the course of the attack, the DOTS server of the ITP >>> periodically informs the DOTS client on the enterprise DMS mitigation >>> status, statistics related to DDoS attack traffic mitigation, and >>> related information. Once the DDoS attack has ended, or decreased to >>> the certain level that the enterprise DMS can handle by itself, the >>> DOTS server signals the enterprise DMS DOTS client that the attack >>> has subsided. >>> >>> It's interesting that this is worded in such a way that the (ITP) DOTS >>> server knows the specific threshold for what level of attack traffic the >>> enterprise DMS can handle, since it's the DOTS server signalling to the >>> client that "the attack has subsided". >>> >>> >> In most cases, if I recall correctly, we expect this to reflect a >> contractual relation. That said, it is ultimately the DOTS client that >> terminates the mitigation. To remove the impression that the ITP sort of >> controls the DOTS client, I propose to change "can handle" by "may >> handle". Here is the updated text: >> >> Once the DDoS attack has ended, or decreased to the certain >> level that the enterprise DMS may handle by itself, the DOTS server >> signals the enterprise DMS DOTS client that the attack has subsided. >> >> >> Section 3.3 >>> >>> Upon receipt of the DOTS mitigation request from the DDoS telemetry >>> system, the orchestrator DOTS server responds with an acknowledgment, >>> to avoid retransmission of the request for mitigation. The >>> orchestrator may begin collecting additional fine-grained and >>> specific information from various DDoS telemetry systems in order to >>> correlate the measurements and provide an analysis of the event. >>> Eventually, the orchestrator may ask for additional information from >>> the DDoS telemetry system; however, the collection of this >>> information is out of scope. >>> >>> The last sentence seems to say that how the orchestrator gets data from >>> the initial DOTS client telemtry system is out-of-scope, but the >>> previous sentence talks about the orchestrator collecting information >>> from (other) DOTS telemetry systems. Is that similarly out of scope? >>> If so, then the fact that they are specifically *DOTS* telemetry systems >>> seems irrelevant and we should probably just describe them as generic >>> telemetry or monitoring systems. >>> >>> >> I agree that we should not have DOTS telemetry systems and leave them as >> DDoS telemetry systems. I checked the current version and there is no >> mention of DOTS telemetry but only DDoS telemetry. >> I also suggest the we specify that such collection is out of scope of >> DOTS. with the following sentence: >> >> the collection of this information is out of scope of DOTS. >> >> >> >>> Upon receiving a request to mitigate a DDoS attack performed over a >>> target, the orchestrator may evaluate the volumetry of the attack as >>> >>> nit(?): is "performed over" a conventional usage? I would have expected >>> something more like "aimed at" given my personal background, but could >>> just be ignorant of typical usage. >>> >> >> changed. >> >> >>> >>> Also, I think "volumetry" is not the right word here, and just "volume" >>> suffices. >>> >> >> I am fine either way. The current version changed to volume, but I am >> waiting co-authors to confirm they agree with the change. >> >> >>> >>> filter the traffic. In this case, the DDoS mitigation system >>> implements a DOTS client while the orchestrator implements a DOTS >>> server. Similar to other DOTS use cases, the offloading scenario >>> assumes that some validation checks are followed by the DMS, the >>> orchestrator, or both (e.g., avoid exhausting the resources of the >>> forwarding nodes or disrupting the service). These validation checks >>> are part of the mitigation, and are therefore out of the scope of the >>> document. >>> >>> I know we added this last chunk of text after a long exchange during the >>> last WGLC, and understand the desire to avoid going into too many >>> details on a topic that is mostly out of scope for DOTS. That said, I'd >>> suggest adding a couple more words around "disrupting the service" >>> (especially since some level of service disruption during an attack >>> might be expected!) to help the reader make the link to what kind of >>> validation is expected, perhaps something like "inadvertent disruption >>> of legitimate services". >>> >>> >> fixed with the follwoing snetence: >> >> Similar to other DOTS use cases, the offloading scenario assumes that >> some validation checks are followed by the DMS, the orchestrator, or both >> (e.g., avoid exhausting the resources of the forwarding nodes or >> inadvertent disruption of legitimate services). >> >> >>> Section 4 >>> >>> In light of my previous comment I don't want to go too far here, but I >>> could see it being relevant to have a note that in the "orchestration" >>> case it's possible for something that locally to one telemetry system >>> looks like an attack is not actually an attack when seen from the >>> broader scope (e.g., of the orchestrator). >>> >>> >> I added the note in the following paragraph. >> >> These systems are configured so that when an event or some measurement >> indicators reach a predefined level their associated DOTS client sends a >> DOTS mitigation request to the orchestrator DOTS server. The DOTS >> mitigation request may be associated with some optional mitigation hints >> to let the orchestrator know what has triggered the request. In >> particular, it's possible for something that locally to one telemetry >> system looks like an attack is not actually an attack when seen from the >> broader scope (e.g., of the orchestrator) >> >> >> In the Third Party MSP case we mention BGP as a way to steer traffic to >>> the mitigation service. We could consider (but don't have to) >>> mentioning that efforts to secure BGP will need to be considered when >>> making pre-arrangements for how traffic is to be moved, since in some >>> contexts such BGP announcements could themselves be considered to be an >>> attack. >>> >>> >> Being ignorant on BGP, I am wondering if you are thinking of a BGP >> procedure to announce routes or some procedure for enabling a delegation >> when BGPsec is considered. >> I porpose the following text: >> >> These exact mechanisms >> used for traffic steering are out of scope of DOTS, but will need to be >> pre-arranged, while in some context such changed could be detected and >> considered as an attack. >> >> >> >>> I guess it probably goes without saying that when you add a third-party >>> DMS to your setup, you depend on that third party to be operational in >>> order for your setup to work properly. >>> >>> Section 7 >>> >>> We'll probably get someone asking to move RFC 8612 to be a Normative >>> reference since we use it for terminology, but I don't mind leaving it >>> be for now. >>> >> >> >> I put it as normative. >> >> >>> >>> Thanks, >>> >>> Ben >>> >>> _______________________________________________ >>> Dots mailing list >>> Dots@ietf.org >>> https://www.ietf.org/mailman/listinfo/dots >>> >> >> >> -- >> Daniel Migault >> Ericsson >> > > The information contained in this email message and its attachments is > intended only for the private and confidential use of the recipient(s) > named above, unless the sender expressly agrees otherwise. Transmission of > email over the Internet is not a secure communications medium. If you are > requesting or have requested the transmittal of personal data, as defined > in applicable privacy laws by means of email or in an attachment to email, > you must select a more secure alternate means of transmittal that supports > your obligations to protect such personal data. > > If the reader of this message is not the intended recipient and/or you > have received this email in error, you must take no action based on the > information in this email and you are hereby notified that any > dissemination, misuse or copying or disclosure of this communication is > strictly prohibited. If you have received this communication in error, > please notify us immediately by email and delete the original message. > -- Daniel Migault Ericsson --000000000000640d3a05a5926466 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks for the feed back=C2=A0Nick. I sort of understand t= hat the current text fits your comment, but prefer to double check before p= ublishing the next version. Feel free to change the text as you wish.=C2=A0=

Here is the text in question:
""&qu= ot;
These exact mechanisms
used for traffic steering are out of = scope of DOTS, but will need to be pre-arranged, while in some context such= changed could be detected and considered as an attack.
"""

Yours,=C2=A0
Daniel<= /div>

On Wed, May 13, 2020 at 1:06 PM Teague, Francis <nteague@ironmountain.co.uk> wrote:
Hi,

Volumetry is awkward - generally an att= ack is characterized as volumetric=C2=A0so volume would be correct IMO.

On the BGP side - My 2c - There are methods such as R= PKI etc. which present concerns=C2=A0for BGP based mitigations where implem= ented, however, these may be overcome=C2=A0in a number of ways (the mitigat= or being authorized to originate prefixes using the customer ASN for exampl= e during an attack).=C2=A0 The methods used to overcome these challenges wh= ile remaining compliant with a particular mechanism are really between the = requestor and mitigator to thrash out.=C2=A0 I'm not sure we should cal= l it out as its part of the wider relationship/onboarding process.=C2=A0 It= 's probably a topic for its own BCP though.

Th= anks,

-Nik

On Wed, 13 May 2020 at 17:07, Dani= el Migault <mgl= t.ietf@gmail.com> wrote:
Hi,=C2=A0

Th= ank you Ben for you comments. Please find inline how these have been addres= sed. The updated version has been pushed to [1].=C2=A0

=
The main questions I have for the co-authors are:
* does the= change of volumetry to volume causes any concern ?
* I guess we = could be a little be more specific regarding the delegation and the pre-arr= angement, in particular if BGP is secured. Please update the=C2=A0text that= has been proposed.=C2=A0

Yours,=C2=A0
D= aniel=C2=A0 =C2=A0


[1]=C2=A0https://github.c= om/dotswg/dots-use-cases

On Tue, May 12, 2020 at 4:22 PM Benjamin Kaduk &= lt;kaduk@mit.edu>= wrote:
Hi all,<= br>
This one is in pretty good shape -- I don't have any major comments on = it.
I did write up some editorial nit-level stuff as a github pull request:
https://github.com/dotswg/dots-use-cases/pull/12= .=C2=A0 I think that nothing
there should be controversial, but please let me know if I am wrong about that.

Please confirm that all six authors made significant contributions: I
will need to defend this to the rest of the IESG, since per RFC 7322 the author count is generally limited to five individuals.=C2=A0 Right now I do= n't
have a good response when someone asks.

<mglt>
As far as I know all authors mentioned significantl= y contributed to the document. It is true that there are many co-authors, b= ut I think that reflected that DOTS needs to coordinate multiple actors tha= t were not so much coordinated before.=C2=A0
</mglt>=C2=A0<= /div>

Section 1

=C2=A0 =C2=A0As DDoS solutions are broadly heterogeneous among vendors, the=
=C2=A0 =C2=A0primary goal of DOTS is to provide high-level interaction amon= gst
=C2=A0 =C2=A0differing DDoS solutions, such as detecting, initiating, termi= nating
=C2=A0 =C2=A0DDoS mitigation assistance or requesting the status of a DDoS<= br> =C2=A0 =C2=A0mitigation.

nit: the list structure is not properly parallel.=C2=A0 It looks like the various clauses are meant to be "detecting DDoS",
"initiating/terminating mitigation assistance", and "request= ing
mitigation status", so maybe this could become:

% As DDoS solutions are broadly heterogeneous among vendors, the
% primary goal of DOTS is to provide high-level interaction amongst
% differing DDoS solutions, such as detecting DDoS attacks,
% initiating/terminating DDoS mitigation assistance, or requesting the
% status of a DDoS mitigation.

<mglt>
fixed
</mglt>= =C2=A0
Section 3.1

=C2=A0 =C2=A0Over the course of the attack, the DOTS server of the ITP
=C2=A0 =C2=A0periodically informs the DOTS client on the enterprise DMS mit= igation
=C2=A0 =C2=A0status, statistics related to DDoS attack traffic mitigation, = and
=C2=A0 =C2=A0related information.=C2=A0 Once the DDoS attack has ended, or = decreased to
=C2=A0 =C2=A0the certain level that the enterprise DMS can handle by itself= , the
=C2=A0 =C2=A0DOTS server signals the enterprise DMS DOTS client that the at= tack
=C2=A0 =C2=A0has subsided.

It's interesting that this is worded in such a way that the (ITP) DOTS<= br> server knows the specific threshold for what level of attack traffic the enterprise DMS can handle, since it's the DOTS server signalling to the=
client that "the attack has subsided".

<mglt>
In most cases, if I recall cor= rectly, we expect this to reflect a contractual relation. That said, it is = ultimately the DOTS client that terminates the mitigation. To remove the im= pression that the ITP sort of controls the DOTS client, I propose to change= "can handle" by "may handle".=C2=A0 Here is the update= d text:

Once the DDoS attack has ended, or decreas= ed to the certain
level that the enterprise DMS may handle by itself, th= e DOTS server
signals the enterprise DMS DOTS client that the attack has= subsided.
</mglt>=C2=A0

Section 3.3

=C2=A0 =C2=A0Upon receipt of the DOTS mitigation request from the DDoS tele= metry
=C2=A0 =C2=A0system, the orchestrator DOTS server responds with an acknowle= dgment,
=C2=A0 =C2=A0to avoid retransmission of the request for mitigation.=C2=A0 T= he
=C2=A0 =C2=A0orchestrator may begin collecting additional fine-grained and<= br> =C2=A0 =C2=A0specific information from various DDoS telemetry systems in or= der to
=C2=A0 =C2=A0correlate the measurements and provide an analysis of the even= t.
=C2=A0 =C2=A0Eventually, the orchestrator may ask for additional informatio= n from
=C2=A0 =C2=A0the DDoS telemetry system; however, the collection of this
=C2=A0 =C2=A0information is out of scope.

The last sentence seems to say that how the orchestrator gets data from
the initial DOTS client telemtry system is out-of-scope, but the
previous sentence talks about the orchestrator collecting information
from (other) DOTS telemetry systems.=C2=A0 Is that similarly out of scope?<= br> If so, then the fact that they are specifically *DOTS* telemetry systems seems irrelevant and we should probably just describe them as generic
telemetry or monitoring systems.

<mglt>
I agree that we should not hav= e DOTS telemetry systems and leave them as DDoS telemetry systems. I checke= d the current version and there is no mention of DOTS telemetry but only DD= oS telemetry.=C2=A0
I also suggest the we specify that such colle= ction is out of scope of DOTS. with the following sentence:

<= /div>
the collection of this information is out of scope of DOTS.
</mglt>
=C2=A0
=C2=A0 =C2=A0Upon receiving a request to mitigate a DDoS attack performed o= ver a
=C2=A0 =C2=A0target, the orchestrator may evaluate the volumetry of the att= ack as

nit(?): is "performed over" a conventional usage?=C2=A0 I would h= ave expected
something more like "aimed at" given my personal background, but = could
just be ignorant of typical usage.
<mglt>
<= div>changed.
</mglt>=C2=A0

Also, I think "volumetry" is not the right word here, and just &q= uot;volume"
suffices.
<mglt>
I am fine either way.= The current version changed to volume, but I am waiting co-authors to conf= irm they agree with the change.=C2=A0
</mglt>=C2=A0

=C2=A0 =C2=A0filter the traffic.=C2=A0 In this case, the DDoS mitigation sy= stem
=C2=A0 =C2=A0implements a DOTS client while the orchestrator implements a D= OTS
=C2=A0 =C2=A0server.=C2=A0 Similar to other DOTS use cases, the offloading = scenario
=C2=A0 =C2=A0assumes that some validation checks are followed by the DMS, t= he
=C2=A0 =C2=A0orchestrator, or both (e.g., avoid exhausting the resources of= the
=C2=A0 =C2=A0forwarding nodes or disrupting the service).=C2=A0 These valid= ation checks
=C2=A0 =C2=A0are part of the mitigation, and are therefore out of the scope= of the
=C2=A0 =C2=A0document.

I know we added this last chunk of text after a long exchange during the last WGLC, and understand the desire to avoid going into too many
details on a topic that is mostly out of scope for DOTS.=C2=A0 That said, I= 'd
suggest adding a couple more words around "disrupting the service"= ;
(especially since some level of service disruption during an attack
might be expected!) to help the reader make the link to what kind of
validation is expected, perhaps something like "inadvertent disruption=
of legitimate services".

<mglt>
fixed with the follwoing snete= nce:

Similar to other DOTS use cases, the offloadi= ng scenario assumes that some validation checks are followed by the DMS, th= e orchestrator, or both (e.g., avoid exhausting the resources of the forwar= ding nodes or inadvertent disruption of legitimate services).
</mglt>=C2=A0
Section 4

In light of my previous comment I don't want to go too far here, but I<= br> could see it being relevant to have a note that in the "orchestration&= quot;
case it's possible for something that locally to one telemetry system looks like an attack is not actually an attack when seen from the
broader scope (e.g., of the orchestrator).

<mglt>
I added the note in the follow= ing paragraph.=C2=A0

These systems are configured = so that when an event or some measurement
indicators reach a predefined = level their associated DOTS client sends a
DOTS mitigation request to th= e orchestrator DOTS server. The DOTS
mitigation request may be associate= d with some optional mitigation hints
to let the orchestrator know what = has triggered the request. In particular, it's possible for something t= hat locally to one telemetry system looks like an attack is not actually an= attack when seen from the broader scope (e.g., of the orchestrator)
</mglt>=C2=A0

In the Third Party MSP case we mention BGP as a way to steer traffic to
the mitigation service.=C2=A0 We could consider (but don't have to)
mentioning that efforts to secure BGP will need to be considered when
making pre-arrangements for how traffic is to be moved, since in some
contexts such BGP announcements could themselves be considered to be an
attack.

<mglt>
Being ignorant on BGP, I am wo= ndering if you are thinking of a BGP procedure to announce=C2=A0routes or s= ome procedure for enabling a delegation when BGPsec is considered.=C2=A0
I porpose=C2=A0the following text:

These e= xact mechanisms
used for traffic steering are out of scope of DOTS, but = will need to be pre-arranged, while in some context such changed could be d= etected and considered as an attack.

</mglt>=C2=A0<= /div>
I guess it probably goes without saying that when you add a third-party
DMS to your setup, you depend on that third party to be operational in
order for your setup to work properly.

Section 7

We'll probably get someone asking to move RFC 8612 to be a Normative reference since we use it for terminology, but I don't mind leaving it<= br> be for now.

<mglt>
I pu= t it as normative.=C2=A0
</mglt>=C2=A0

Thanks,

Ben

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


--
Daniel Migault
Ericsson

= The information contained in this email message and its attachments is inte= nded only for the private and confidential use of the recipient(s) named ab= ove, unless the sender expressly agrees otherwise. Transmission of email ov= er the Internet is not a secure communications medium. If you are requestin= g or have requested the transmittal of personal data, as defined in applica= ble privacy laws by means of email or in an attachment to email, you must s= elect a more secure alternate means of transmittal that supports your oblig= ations to protect such personal data.=C2=A0

If the reader of this message is not the intended recipient= and/or you have received this email in error, you must take no action base= d on the information in this email and you are hereby notified that any dis= semination, misuse or copying or disclosure of this communication is strict= ly prohibited. If you have received this communication in error, please not= ify us immediately by email and delete the original message.=C2=A0


--
Daniel Migault<= br>
Ericsson
--000000000000640d3a05a5926466-- From nobody Wed May 13 19:41:23 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 9A37F3A092E; Wed, 13 May 2020 19:41:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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 F6TGc118TkVz; Wed, 13 May 2020 19:41:18 -0700 (PDT) Received: from guri.nttv6.jp (guri.nttv6.jp [115.69.228.140]) by ietfa.amsl.com (Postfix) with ESMTP id 6B3933A092B; Wed, 13 May 2020 19:41:17 -0700 (PDT) Received: from z.nttv6.jp (z.nttv6.jp [IPv6:2402:c800:ff06:6::f]) by guri.nttv6.jp (NTTv6MTA) with ESMTP id 7ECB125F6BB; Thu, 14 May 2020 11:41:15 +0900 (JST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nttv6.jp; s=20180820; t=1589424075; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=yDkBtkRaNXGtwqqr5G1kucXZvS0fuJaqoP84+MtpPig=; b=WmTOuAYasdZ2T8F63zxiZXR9nyFCgIODpa2iE4VQnaxpRsTD5Fg2eAYiHTHovUPy7OHemN EsuSixo9VyvIs05YlbDRIHAMcJqNbIx70hN8BJZhvj16z40UMKSl24Ynh+nr7K5WHBdC3s vw7bAnlRBbBB280sDpYMg58RgAay5to= Received: from UG023-kaname.local (fujiko.nttv6.jp [IPv6:2402:c800:ff06:136::141]) by z.nttv6.jp (NTTv6MTA) with ESMTP id 5AF7375900E; Thu, 14 May 2020 11:41:15 +0900 (JST) To: "Teague, Francis" , Daniel Migault Cc: draft-ietf-dots-use-cases.all@ietf.org, Benjamin Kaduk , dots References: <20200512202205.GF27494@kduck.mit.edu> From: kaname nishizuka Message-ID: Date: Thu, 14 May 2020 11:41:15 +0900 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------D5F3A282A120F9F68134F8F3" Content-Language: en-US Authentication-Results: guri.nttv6.jp; spf=pass smtp.mailfrom=kaname@nttv6.jp Archived-At: Subject: Re: [Dots] AD evaluation of draft-ietf-dots-use-cases-20 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, 14 May 2020 02:41:22 -0000 This is a multi-part message in MIME format. --------------D5F3A282A120F9F68134F8F3 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Hi, 1. "the volume of the attack" is more understandable. 2. "These exact mechanisms used for traffic steering are out of scope of DOTS, but will need to be pre-arranged, while in some context such changed could be detected and considered as an attack." The proposed text seems sufficient to me. +1 to Nik's comments. > It's probably a topic for its own BCP thanks, Kaname On 2020/05/14 2:06, Teague, Francis wrote: > Hi, > > Volumetry is awkward - generally an attack is characterized as volumetric so volume would be correct IMO. > > On the BGP side - My 2c - There are methods such as RPKI etc. which present concerns for BGP based mitigations where implemented, however, these may be overcome in a number of ways (the mitigator being authorized to originate prefixes using the customer ASN for example during an attack).  The methods used to overcome these challenges while remaining compliant with a particular mechanism are really between the requestor and mitigator to thrash out.  I'm not sure we should call it out as its part of the wider relationship/onboarding process.  It's probably a topic for its own BCP though. > > Thanks, > > -Nik > > On Wed, 13 May 2020 at 17:07, Daniel Migault > wrote: > > Hi, > > Thank you Ben for you comments. Please find inline how these have been addressed. The updated version has been pushed to [1]. > > The main questions I have for the co-authors are: > * does the change of volumetry to volume causes any concern ? > * I guess we could be a little be more specific regarding the delegation and the pre-arrangement, in particular if BGP is secured. Please update the text that has been proposed. > > Yours, > Daniel > > > [1] https://github.com/dotswg/dots-use-cases > > On Tue, May 12, 2020 at 4:22 PM Benjamin Kaduk > wrote: > > Hi all, > > This one is in pretty good shape -- I don't have any major comments on it. > I did write up some editorial nit-level stuff as a github pull request: > https://github.com/dotswg/dots-use-cases/pull/12 .  I think that nothing > there should be controversial, but please let me know if I am wrong about > that. > > Please confirm that all six authors made significant contributions: I > will need to defend this to the rest of the IESG, since per RFC 7322 the > author count is generally limited to five individuals.  Right now I don't > have a good response when someone asks. > > > > As far as I know all authors mentioned significantly contributed to the document. It is true that there are many co-authors, but I think that reflected that DOTS needs to coordinate multiple actors that were not so much coordinated before. > > > > Section 1 > >    As DDoS solutions are broadly heterogeneous among vendors, the >    primary goal of DOTS is to provide high-level interaction amongst >    differing DDoS solutions, such as detecting, initiating, terminating >    DDoS mitigation assistance or requesting the status of a DDoS >    mitigation. > > nit: the list structure is not properly parallel. It looks like the > various clauses are meant to be "detecting DDoS", > "initiating/terminating mitigation assistance", and "requesting > mitigation status", so maybe this could become: > > % As DDoS solutions are broadly heterogeneous among vendors, the > % primary goal of DOTS is to provide high-level interaction amongst > % differing DDoS solutions, such as detecting DDoS attacks, > % initiating/terminating DDoS mitigation assistance, or requesting the > % status of a DDoS mitigation. > > > fixed > > > Section 3.1 > >    Over the course of the attack, the DOTS server of the ITP >    periodically informs the DOTS client on the enterprise DMS mitigation >    status, statistics related to DDoS attack traffic mitigation, and >    related information.  Once the DDoS attack has ended, or decreased to >    the certain level that the enterprise DMS can handle by itself, the >    DOTS server signals the enterprise DMS DOTS client that the attack >    has subsided. > > It's interesting that this is worded in such a way that the (ITP) DOTS > server knows the specific threshold for what level of attack traffic the > enterprise DMS can handle, since it's the DOTS server signalling to the > client that "the attack has subsided". > > > In most cases, if I recall correctly, we expect this to reflect a contractual relation. That said, it is ultimately the DOTS client that terminates the mitigation. To remove the impression that the ITP sort of controls the DOTS client, I propose to change "can handle" by "may handle".  Here is the updated text: > > Once the DDoS attack has ended, or decreased to the certain > level that the enterprise DMS may handle by itself, the DOTS server > signals the enterprise DMS DOTS client that the attack has subsided. > > > Section 3.3 > >    Upon receipt of the DOTS mitigation request from the DDoS telemetry >    system, the orchestrator DOTS server responds with an acknowledgment, >    to avoid retransmission of the request for mitigation.  The >    orchestrator may begin collecting additional fine-grained and >    specific information from various DDoS telemetry systems in order to >    correlate the measurements and provide an analysis of the event. >    Eventually, the orchestrator may ask for additional information from >    the DDoS telemetry system; however, the collection of this >    information is out of scope. > > The last sentence seems to say that how the orchestrator gets data from > the initial DOTS client telemtry system is out-of-scope, but the > previous sentence talks about the orchestrator collecting information > from (other) DOTS telemetry systems.  Is that similarly out of scope? > If so, then the fact that they are specifically *DOTS* telemetry systems > seems irrelevant and we should probably just describe them as generic > telemetry or monitoring systems. > > > I agree that we should not have DOTS telemetry systems and leave them as DDoS telemetry systems. I checked the current version and there is no mention of DOTS telemetry but only DDoS telemetry. > I also suggest the we specify that such collection is out of scope of DOTS. with the following sentence: > > the collection of this information is out of scope of DOTS. > > >    Upon receiving a request to mitigate a DDoS attack performed over a >    target, the orchestrator may evaluate the volumetry of the attack as > > nit(?): is "performed over" a conventional usage?  I would have expected > something more like "aimed at" given my personal background, but could > just be ignorant of typical usage. > > > changed. > > > > Also, I think "volumetry" is not the right word here, and just "volume" > suffices. > > > I am fine either way. The current version changed to volume, but I am waiting co-authors to confirm they agree with the change. > > > >    filter the traffic.  In this case, the DDoS mitigation system >    implements a DOTS client while the orchestrator implements a DOTS >    server.  Similar to other DOTS use cases, the offloading scenario >    assumes that some validation checks are followed by the DMS, the >    orchestrator, or both (e.g., avoid exhausting the resources of the >    forwarding nodes or disrupting the service). These validation checks >    are part of the mitigation, and are therefore out of the scope of the >    document. > > I know we added this last chunk of text after a long exchange during the > last WGLC, and understand the desire to avoid going into too many > details on a topic that is mostly out of scope for DOTS.  That said, I'd > suggest adding a couple more words around "disrupting the service" > (especially since some level of service disruption during an attack > might be expected!) to help the reader make the link to what kind of > validation is expected, perhaps something like "inadvertent disruption > of legitimate services". > > > fixed with the follwoing snetence: > > Similar to other DOTS use cases, the offloading scenario assumes that some validation checks are followed by the DMS, the orchestrator, or both (e.g., avoid exhausting the resources of the forwarding nodes or inadvertent disruption of legitimate services). > > > Section 4 > > In light of my previous comment I don't want to go too far here, but I > could see it being relevant to have a note that in the "orchestration" > case it's possible for something that locally to one telemetry system > looks like an attack is not actually an attack when seen from the > broader scope (e.g., of the orchestrator). > > > I added the note in the following paragraph. > > These systems are configured so that when an event or some measurement > indicators reach a predefined level their associated DOTS client sends a > DOTS mitigation request to the orchestrator DOTS server. The DOTS > mitigation request may be associated with some optional mitigation hints > to let the orchestrator know what has triggered the request. In particular, it's possible for something that locally to one telemetry system looks like an attack is not actually an attack when seen from the broader scope (e.g., of the orchestrator) > > > In the Third Party MSP case we mention BGP as a way to steer traffic to > the mitigation service.  We could consider (but don't have to) > mentioning that efforts to secure BGP will need to be considered when > making pre-arrangements for how traffic is to be moved, since in some > contexts such BGP announcements could themselves be considered to be an > attack. > > > Being ignorant on BGP, I am wondering if you are thinking of a BGP procedure to announce routes or some procedure for enabling a delegation when BGPsec is considered. > I porpose the following text: > > These exact mechanisms > used for traffic steering are out of scope of DOTS, but will need to be pre-arranged, while in some context such changed could be detected and considered as an attack. > > > > I guess it probably goes without saying that when you add a third-party > DMS to your setup, you depend on that third party to be operational in > order for your setup to work properly. > > Section 7 > > We'll probably get someone asking to move RFC 8612 to be a Normative > reference since we use it for terminology, but I don't mind leaving it > be for now. > > > > I put it as normative. > > > > Thanks, > > Ben > > _______________________________________________ > Dots mailing list > Dots@ietf.org > https://www.ietf.org/mailman/listinfo/dots > > > > -- > Daniel Migault > Ericsson > > > The information contained in this email message and its attachments is intended only for the private and confidential use of the recipient(s) named above, unless the sender expressly agrees otherwise. Transmission of email over the Internet is not a secure communications medium. If you are requesting or have requested the transmittal of personal data, as defined in applicable privacy laws by means of email or in an attachment to email, you must select a more secure alternate means of transmittal that supports your obligations to protect such personal data. > > If the reader of this message is not the intended recipient and/or you have received this email in error, you must take no action based on the information in this email and you are hereby notified that any dissemination, misuse or copying or disclosure of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by email and delete the original message. > > _______________________________________________ > Dots mailing list > Dots@ietf.org > https://www.ietf.org/mailman/listinfo/dots --------------D5F3A282A120F9F68134F8F3 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Hi,

1. "the volume of the attack" is more understandable.

2. "These exact mechanisms used for traffic steering are out of scope of DOTS, but will need to be pre-arranged, while in some context such changed could be detected and considered as an attack."
The proposed text seems sufficient to me. +1 to Nik's comments. > It's probably a topic for its own BCP

thanks,
Kaname

On 2020/05/14 2:06, Teague, Francis wrote:
Hi,

Volumetry is awkward - generally an attack is characterized as volumetric so volume would be correct IMO.

On the BGP side - My 2c - There are methods such as RPKI etc. which present concerns for BGP based mitigations where implemented, however, these may be overcome in a number of ways (the mitigator being authorized to originate prefixes using the customer ASN for example during an attack).  The methods used to overcome these challenges while remaining compliant with a particular mechanism are really between the requestor and mitigator to thrash out.  I'm not sure we should call it out as its part of the wider relationship/onboarding process.  It's probably a topic for its own BCP though.

Thanks,

-Nik

On Wed, 13 May 2020 at 17:07, Daniel Migault <mglt.ietf@gmail.com> wrote:
Hi, 

Thank you Ben for you comments. Please find inline how these have been addressed. The updated version has been pushed to [1]. 

The main questions I have for the co-authors are:
* does the change of volumetry to volume causes any concern ?
* I guess we could be a little be more specific regarding the delegation and the pre-arrangement, in particular if BGP is secured. Please update the text that has been proposed. 

Yours, 
Daniel   


[1] https://github.com/dotswg/dots-use-cases

On Tue, May 12, 2020 at 4:22 PM Benjamin Kaduk <kaduk@mit.edu> wrote:
Hi all,

This one is in pretty good shape -- I don't have any major comments on it.
I did write up some editorial nit-level stuff as a github pull request:
https://github.com/dotswg/dots-use-cases/pull/12 .  I think that nothing
there should be controversial, but please let me know if I am wrong about
that.

Please confirm that all six authors made significant contributions: I
will need to defend this to the rest of the IESG, since per RFC 7322 the
author count is generally limited to five individuals.  Right now I don't
have a good response when someone asks.

<mglt>
As far as I know all authors mentioned significantly contributed to the document. It is true that there are many co-authors, but I think that reflected that DOTS needs to coordinate multiple actors that were not so much coordinated before. 
</mglt> 

Section 1

   As DDoS solutions are broadly heterogeneous among vendors, the
   primary goal of DOTS is to provide high-level interaction amongst
   differing DDoS solutions, such as detecting, initiating, terminating
   DDoS mitigation assistance or requesting the status of a DDoS
   mitigation.

nit: the list structure is not properly parallel.  It looks like the
various clauses are meant to be "detecting DDoS",
"initiating/terminating mitigation assistance", and "requesting
mitigation status", so maybe this could become:

% As DDoS solutions are broadly heterogeneous among vendors, the
% primary goal of DOTS is to provide high-level interaction amongst
% differing DDoS solutions, such as detecting DDoS attacks,
% initiating/terminating DDoS mitigation assistance, or requesting the
% status of a DDoS mitigation.

<mglt>
fixed
</mglt> 
Section 3.1

   Over the course of the attack, the DOTS server of the ITP
   periodically informs the DOTS client on the enterprise DMS mitigation
   status, statistics related to DDoS attack traffic mitigation, and
   related information.  Once the DDoS attack has ended, or decreased to
   the certain level that the enterprise DMS can handle by itself, the
   DOTS server signals the enterprise DMS DOTS client that the attack
   has subsided.

It's interesting that this is worded in such a way that the (ITP) DOTS
server knows the specific threshold for what level of attack traffic the
enterprise DMS can handle, since it's the DOTS server signalling to the
client that "the attack has subsided".

<mglt>
In most cases, if I recall correctly, we expect this to reflect a contractual relation. That said, it is ultimately the DOTS client that terminates the mitigation. To remove the impression that the ITP sort of controls the DOTS client, I propose to change "can handle" by "may handle".  Here is the updated text:

Once the DDoS attack has ended, or decreased to the certain
level that the enterprise DMS may handle by itself, the DOTS server
signals the enterprise DMS DOTS client that the attack has subsided.
</mglt> 

Section 3.3

   Upon receipt of the DOTS mitigation request from the DDoS telemetry
   system, the orchestrator DOTS server responds with an acknowledgment,
   to avoid retransmission of the request for mitigation.  The
   orchestrator may begin collecting additional fine-grained and
   specific information from various DDoS telemetry systems in order to
   correlate the measurements and provide an analysis of the event.
   Eventually, the orchestrator may ask for additional information from
   the DDoS telemetry system; however, the collection of this
   information is out of scope.

The last sentence seems to say that how the orchestrator gets data from
the initial DOTS client telemtry system is out-of-scope, but the
previous sentence talks about the orchestrator collecting information
from (other) DOTS telemetry systems.  Is that similarly out of scope?
If so, then the fact that they are specifically *DOTS* telemetry systems
seems irrelevant and we should probably just describe them as generic
telemetry or monitoring systems.

<mglt>
I agree that we should not have DOTS telemetry systems and leave them as DDoS telemetry systems. I checked the current version and there is no mention of DOTS telemetry but only DDoS telemetry. 
I also suggest the we specify that such collection is out of scope of DOTS. with the following sentence:

the collection of this information is out of scope of DOTS.
</mglt>
 
   Upon receiving a request to mitigate a DDoS attack performed over a
   target, the orchestrator may evaluate the volumetry of the attack as

nit(?): is "performed over" a conventional usage?  I would have expected
something more like "aimed at" given my personal background, but could
just be ignorant of typical usage.
<mglt>
changed.
</mglt> 

Also, I think "volumetry" is not the right word here, and just "volume"
suffices.
<mglt>
I am fine either way. The current version changed to volume, but I am waiting co-authors to confirm they agree with the change. 
</mglt> 

   filter the traffic.  In this case, the DDoS mitigation system
   implements a DOTS client while the orchestrator implements a DOTS
   server.  Similar to other DOTS use cases, the offloading scenario
   assumes that some validation checks are followed by the DMS, the
   orchestrator, or both (e.g., avoid exhausting the resources of the
   forwarding nodes or disrupting the service).  These validation checks
   are part of the mitigation, and are therefore out of the scope of the
   document.

I know we added this last chunk of text after a long exchange during the
last WGLC, and understand the desire to avoid going into too many
details on a topic that is mostly out of scope for DOTS.  That said, I'd
suggest adding a couple more words around "disrupting the service"
(especially since some level of service disruption during an attack
might be expected!) to help the reader make the link to what kind of
validation is expected, perhaps something like "inadvertent disruption
of legitimate services".

<mglt>
fixed with the follwoing snetence:

Similar to other DOTS use cases, the offloading scenario assumes that some validation checks are followed by the DMS, the orchestrator, or both (e.g., avoid exhausting the resources of the forwarding nodes or inadvertent disruption of legitimate services).
</mglt> 
Section 4

In light of my previous comment I don't want to go too far here, but I
could see it being relevant to have a note that in the "orchestration"
case it's possible for something that locally to one telemetry system
looks like an attack is not actually an attack when seen from the
broader scope (e.g., of the orchestrator).

<mglt>
I added the note in the following paragraph. 

These systems are configured so that when an event or some measurement
indicators reach a predefined level their associated DOTS client sends a
DOTS mitigation request to the orchestrator DOTS server. The DOTS
mitigation request may be associated with some optional mitigation hints
to let the orchestrator know what has triggered the request. In particular, it's possible for something that locally to one telemetry system looks like an attack is not actually an attack when seen from the broader scope (e.g., of the orchestrator)
</mglt> 

In the Third Party MSP case we mention BGP as a way to steer traffic to
the mitigation service.  We could consider (but don't have to)
mentioning that efforts to secure BGP will need to be considered when
making pre-arrangements for how traffic is to be moved, since in some
contexts such BGP announcements could themselves be considered to be an
attack.

<mglt>
Being ignorant on BGP, I am wondering if you are thinking of a BGP procedure to announce routes or some procedure for enabling a delegation when BGPsec is considered. 
I porpose the following text:

These exact mechanisms
used for traffic steering are out of scope of DOTS, but will need to be pre-arranged, while in some context such changed could be detected and considered as an attack.

</mglt> 
I guess it probably goes without saying that when you add a third-party
DMS to your setup, you depend on that third party to be operational in
order for your setup to work properly.

Section 7

We'll probably get someone asking to move RFC 8612 to be a Normative
reference since we use it for terminology, but I don't mind leaving it
be for now.

<mglt>
I put it as normative. 
</mglt> 

Thanks,

Ben

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


--
Daniel Migault
Ericsson

The information contained in this email message and its attachments is intended only for the private and confidential use of the recipient(s) named above, unless the sender expressly agrees otherwise. Transmission of email over the Internet is not a secure communications medium. If you are requesting or have requested the transmittal of personal data, as defined in applicable privacy laws by means of email or in an attachment to email, you must select a more secure alternate means of transmittal that supports your obligations to protect such personal data. 

If the reader of this message is not the intended recipient and/or you have received this email in error, you must take no action based on the information in this email and you are hereby notified that any dissemination, misuse or copying or disclosure of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by email and delete the original message. 

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

--------------D5F3A282A120F9F68134F8F3-- From nobody Wed May 13 19:49:30 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 7B7703A0934; Wed, 13 May 2020 19:49:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ps2sRW2paqzI; Wed, 13 May 2020 19:49:24 -0700 (PDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 735A83A0933; Wed, 13 May 2020 19:49:23 -0700 (PDT) Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 04E2nIW5002628 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 13 May 2020 22:49:20 -0400 Date: Wed, 13 May 2020 19:49:18 -0700 From: Benjamin Kaduk To: Daniel Migault Cc: draft-ietf-dots-use-cases.all@ietf.org, dots Message-ID: <20200514024918.GQ27494@kduck.mit.edu> References: <20200512202205.GF27494@kduck.mit.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.12.1 (2019-06-15) Archived-At: Subject: Re: [Dots] AD evaluation of draft-ietf-dots-use-cases-20 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, 14 May 2020 02:49:27 -0000 Hi Daniel, Just a few replies inline. On Wed, May 13, 2020 at 12:06:45PM -0400, Daniel Migault wrote: > Hi, > > Thank you Ben for you comments. Please find inline how these have been > addressed. The updated version has been pushed to [1]. > > The main questions I have for the co-authors are: > * does the change of volumetry to volume causes any concern ? > * I guess we could be a little be more specific regarding the delegation > and the pre-arrangement, in particular if BGP is secured. Please update > the text that has been proposed. > > Yours, > Daniel > > > [1] https://github.com/dotswg/dots-use-cases > > On Tue, May 12, 2020 at 4:22 PM Benjamin Kaduk wrote: > > > Hi all, > > > > This one is in pretty good shape -- I don't have any major comments on it. > > I did write up some editorial nit-level stuff as a github pull request: > > https://github.com/dotswg/dots-use-cases/pull/12 . I think that nothing > > there should be controversial, but please let me know if I am wrong about > > that. > > > > Please confirm that all six authors made significant contributions: I > > will need to defend this to the rest of the IESG, since per RFC 7322 the > > author count is generally limited to five individuals. Right now I don't > > have a good response when someone asks. > > > > > As far as I know all authors mentioned significantly contributed to the > document. It is true that there are many co-authors, but I think that > reflected that DOTS needs to coordinate multiple actors that were not so > much coordinated before. > Thanks, that is good to know. > > > > Section 1 > > > > As DDoS solutions are broadly heterogeneous among vendors, the > > primary goal of DOTS is to provide high-level interaction amongst > > differing DDoS solutions, such as detecting, initiating, terminating > > DDoS mitigation assistance or requesting the status of a DDoS > > mitigation. > > > > nit: the list structure is not properly parallel. It looks like the > > various clauses are meant to be "detecting DDoS", > > "initiating/terminating mitigation assistance", and "requesting > > mitigation status", so maybe this could become: > > > > % As DDoS solutions are broadly heterogeneous among vendors, the > > % primary goal of DOTS is to provide high-level interaction amongst > > % differing DDoS solutions, such as detecting DDoS attacks, > > % initiating/terminating DDoS mitigation assistance, or requesting the > > % status of a DDoS mitigation. > > > > > fixed > > > > Section 3.1 > > > > Over the course of the attack, the DOTS server of the ITP > > periodically informs the DOTS client on the enterprise DMS mitigation > > status, statistics related to DDoS attack traffic mitigation, and > > related information. Once the DDoS attack has ended, or decreased to > > the certain level that the enterprise DMS can handle by itself, the > > DOTS server signals the enterprise DMS DOTS client that the attack > > has subsided. > > > > It's interesting that this is worded in such a way that the (ITP) DOTS > > server knows the specific threshold for what level of attack traffic the > > enterprise DMS can handle, since it's the DOTS server signalling to the > > client that "the attack has subsided". > > > > > In most cases, if I recall correctly, we expect this to reflect a > contractual relation. That said, it is ultimately the DOTS client that > terminates the mitigation. To remove the impression that the ITP sort of > controls the DOTS client, I propose to change "can handle" by "may > handle". Here is the updated text: > > Once the DDoS attack has ended, or decreased to the certain > level that the enterprise DMS may handle by itself, the DOTS server > signals the enterprise DMS DOTS client that the attack has subsided. > I'd consider "might" instead of "may", since sometimes in English "may" has a connotation of granting permission. > Section 3.3 > > > > Upon receipt of the DOTS mitigation request from the DDoS telemetry > > system, the orchestrator DOTS server responds with an acknowledgment, > > to avoid retransmission of the request for mitigation. The > > orchestrator may begin collecting additional fine-grained and > > specific information from various DDoS telemetry systems in order to > > correlate the measurements and provide an analysis of the event. > > Eventually, the orchestrator may ask for additional information from > > the DDoS telemetry system; however, the collection of this > > information is out of scope. > > > > The last sentence seems to say that how the orchestrator gets data from > > the initial DOTS client telemtry system is out-of-scope, but the > > previous sentence talks about the orchestrator collecting information > > from (other) DOTS telemetry systems. Is that similarly out of scope? > > If so, then the fact that they are specifically *DOTS* telemetry systems > > seems irrelevant and we should probably just describe them as generic > > telemetry or monitoring systems. > > > > > I agree that we should not have DOTS telemetry systems and leave them as > DDoS telemetry systems. I checked the current version and there is no > mention of DOTS telemetry but only DDoS telemetry. Oops, I seem to have misread this text! Of course, generic DDoS telemetry systems make sense in this context. > I also suggest the we specify that such collection is out of scope of DOTS. > with the following sentence: > > the collection of this information is out of scope of DOTS. Okay. > > > > > Upon receiving a request to mitigate a DDoS attack performed over a > > target, the orchestrator may evaluate the volumetry of the attack as > > > > nit(?): is "performed over" a conventional usage? I would have expected > > something more like "aimed at" given my personal background, but could > > just be ignorant of typical usage. > > > > changed. > > > > > > Also, I think "volumetry" is not the right word here, and just "volume" > > suffices. > > > > I am fine either way. The current version changed to volume, but I am > waiting co-authors to confirm they agree with the change. > > > > > > filter the traffic. In this case, the DDoS mitigation system > > implements a DOTS client while the orchestrator implements a DOTS > > server. Similar to other DOTS use cases, the offloading scenario > > assumes that some validation checks are followed by the DMS, the > > orchestrator, or both (e.g., avoid exhausting the resources of the > > forwarding nodes or disrupting the service). These validation checks > > are part of the mitigation, and are therefore out of the scope of the > > document. > > > > I know we added this last chunk of text after a long exchange during the > > last WGLC, and understand the desire to avoid going into too many > > details on a topic that is mostly out of scope for DOTS. That said, I'd > > suggest adding a couple more words around "disrupting the service" > > (especially since some level of service disruption during an attack > > might be expected!) to help the reader make the link to what kind of > > validation is expected, perhaps something like "inadvertent disruption > > of legitimate services". > > > > > fixed with the follwoing snetence: > > Similar to other DOTS use cases, the offloading scenario assumes that some > validation checks are followed by the DMS, the orchestrator, or both (e.g., > avoid exhausting the resources of the forwarding nodes or inadvertent > disruption of legitimate services). > > > > Section 4 > > > > In light of my previous comment I don't want to go too far here, but I > > could see it being relevant to have a note that in the "orchestration" > > case it's possible for something that locally to one telemetry system > > looks like an attack is not actually an attack when seen from the > > broader scope (e.g., of the orchestrator). > > > > > I added the note in the following paragraph. > > These systems are configured so that when an event or some measurement > indicators reach a predefined level their associated DOTS client sends a > DOTS mitigation request to the orchestrator DOTS server. The DOTS > mitigation request may be associated with some optional mitigation hints > to let the orchestrator know what has triggered the request. In particular, > it's possible for something that locally to one telemetry system looks like > an attack is not actually an attack when seen from the broader scope (e.g., > of the orchestrator) > > > In the Third Party MSP case we mention BGP as a way to steer traffic to > > the mitigation service. We could consider (but don't have to) > > mentioning that efforts to secure BGP will need to be considered when > > making pre-arrangements for how traffic is to be moved, since in some > > contexts such BGP announcements could themselves be considered to be an > > attack. > > > > > Being ignorant on BGP, I am wondering if you are thinking of a BGP > procedure to announce routes or some procedure for enabling a delegation > when BGPsec is considered. I think either could be problmatic in some (rare?) circumstances -- I believe in some cases there are allow-lists for which neighbors' announcements of which prefixes are acted upon, and of course when the RPKI comes into play that needs to validate properly as well. > I porpose the following text: > > These exact mechanisms > used for traffic steering are out of scope of DOTS, but will need to be > pre-arranged, while in some context such changed could be detected and > considered as an attack. I agree with the other commenters that a separate BCP is where the details should be covered. > > > > I guess it probably goes without saying that when you add a third-party > > DMS to your setup, you depend on that third party to be operational in > > order for your setup to work properly. > > > > Section 7 > > > > We'll probably get someone asking to move RFC 8612 to be a Normative > > reference since we use it for terminology, but I don't mind leaving it > > be for now. > > > > > I put it as normative. Thanks, Ben From nobody Wed May 13 19:55:25 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 54C9F3A0939; Wed, 13 May 2020 19:55:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 2mCMp2ONsT6L; Wed, 13 May 2020 19:55:21 -0700 (PDT) Received: from guri.nttv6.jp (guri.nttv6.jp [IPv6:2402:c800:ff06:136::140]) by ietfa.amsl.com (Postfix) with ESMTP id A40123A0937; Wed, 13 May 2020 19:55:20 -0700 (PDT) Received: from z.nttv6.jp (z.nttv6.jp [192.168.8.15]) by guri.nttv6.jp (NTTv6MTA) with ESMTP id ABC2B25F6BB; Thu, 14 May 2020 11:55:17 +0900 (JST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nttv6.jp; s=20180820; t=1589424917; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=/RsgKaO7MhgDA/QH84KQHDhGw7BFJNDGoEh238T21vw=; b=DsM4TMeyQu1Xvj0oWM9cAK5ue2NyHAn9y/+IYDSrMHmxREo/+YjRfXJHpwQR02lPNpM/BR n4o5YdfI87bf3uwfNp3mer4N38nyE4I8KGrNrCrofkQiCFGiKeMxHEDtJ7sCyYUGvJmOpr 1MeT5xaTWiThWGRBWzIAPjyhNtJZ3As= Received: from UG023-kaname.local (fujiko.nttv6.jp [IPv6:2402:c800:ff06:136::141]) by z.nttv6.jp (NTTv6MTA) with ESMTP id 7451375900E; Thu, 14 May 2020 11:55:17 +0900 (JST) To: mohamed.boucadair@orange.com, Benjamin Kaduk , "draft-ietf-dots-signal-filter-control.all@ietf.org" , "kaduk@mit.edu" Cc: "dots@ietf.org" References: <20200513021222.GY3811@akamai.com> <787AE7BB302AE849A7480A190F8B9330314B9EE0@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> From: kaname nishizuka Message-ID: <7c1c37a2-61ea-093f-a930-dcbf571dba83@nttv6.jp> Date: Thu, 14 May 2020 11:55:17 +0900 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 MIME-Version: 1.0 In-Reply-To: <787AE7BB302AE849A7480A190F8B9330314B9EE0@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [Dots] AD evaluation of draft-ietf-dots-signal-filter-control-03 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, 14 May 2020 02:55:24 -0000 Hi Ben, Med, Thank you for the detailed review. All the changes and the proposal texts looks good to me. thanks Med for catching them all. thanks, Kaname On 2020/05/13 19:47, mohamed.boucadair@orange.com wrote: > Hi Ben, > > Thank you for the review. > > Please see inline. > > Cheers, > Med > >> -----Message d'origine----- >> De : Benjamin Kaduk [mailto:bkaduk@akamai.com] >> Envoyé : mercredi 13 mai 2020 04:12 >> À : draft-ietf-dots-signal-filter-control.all@ietf.org; kaduk@mit.edu >> Cc : dots@ietf.org >> Objet : AD evaluation of draft-ietf-dots-signal-filter-control-03 >> >> Hi all, >> >> This one is also generally in good shape, with mostly nit-level >> comments. >> (I didn't find it on github, so those are inline.) >> >> I have a nagging suspicion that I'm repeating some comments I made on >> the core protocol documents (having forgotten the response and thus >> why >> the change in question should not be made; my apologies in advance for >> my poor memory. >> >> Section 1.1 >> >> The DOTS data channel protocol [I-D.ietf-dots-data-channel] is used >> for bulk data exchange between DOTS agents to improve the >> coordination of parties involved in the response to the Distributed >> >> nit: s/the/a/ >> > [Med] Fixed. Thanks. > >> the inbound link to the DOTS client domain. In other words, the >> DOTS >> client cannot use the DOTS data channel protocol to withdraw the >> accept-list filters when a DDoS attack is in progress. This >> assumes >> that this DOTS client is the owner of the filtering rule. >> >> nit: the last sentence feels a little disconnected from the previous >> discussion at the moment; I'd suggest adding at the end ", since >> otherwise this DOTS client would not be authorized to modify it >> anyway" >> or similar. > [Med] After rereading, I think we can get rid of it. I deleted that part of the sentence. > >> Section 1.2 >> >> This specification addresses the problems discussed in Section 1.1 >> by >> adding the capability of managing filtering rules using the DOTS >> signal channel protocol, which enables a DOTS client to request the >> activation (or deactivation) of filtering rules during a DDoS >> attack. >> >> nit: the grammar here does not quite match up ("capability of" vs. >> "using"); perhaps s/the capability of/a capability for/ (though other >> fixes are possible). > [Med] Fixed. > >> Sample examples are provided in Section 4, in particular: >> >> nit: "sample examples" feels redundant; maybe "some examples" or just >> "examples"? >> >> o Section 4.1 illustrates how the filter control extension is used >> when conflicts with Access Control List (ACLs) are detected and >> reported by a DOTS server. >> >> nit: s/List/Lists/ > [Med] Fixed. Thanks. > >> Section 3.1 >> >> A filtering rule controlled by the DOTS signal channel is >> identified >> by its ACL name (Section 7.2 of [I-D.ietf-dots-data-channel]). >> Note >> >> The referenced section is just an example; the actual YANG definition >> is >> in Section 4.3 thereof. > [Med] pointing to section 4.3 is better. Fixed. > >> The activation or deactivation of an ACL by the DOTS signal channel >> overrides the 'activation-type' (defined in Section 7.2 of >> [I-D.ietf-dots-data-channel]) a priori conveyed with the filtering >> rules using the DOTS data channel protocol. >> >> Is there a way to "cancel" the signal-channel-made changes and revert >> to >> the previous activation-type? > [Med] This is up to the DOTS client to tweak these filtering rules as a function of the context. For example, > - if a rule was deactivated because of a conflict, the client may delete that rule > - if the rule was a rate-limit, the client will deactivate the rule. > > I added this NEW text: > > Once the attack is mitigated, the DOTS client may use the data > channel to control the 'activation-type' (e.g., revert to a default > value) of some of the filtering rules controlled by the DOTS signal > channel or delete some of these filters. This behavior is deployment > specific. > > Do we need to say more? > > Or do we just make the client remember >> the previous status and manually set that status in such a case? >> >> Section 3.2.1 >> >> Why is the acl-name an optional attribute? > [Med] Because: > > This specification extends the mitigation request defined in > Section 4.4.1 of [I-D.ietf-dots-signal-channel] to convey the > intended control of configured filtering rules. > > A mitigation request does not need to include an acl name to be valid. > > What would the >> interpretation be if it was not provided? > [Med] This will be a mitigation request as defined in draft-ietf-dots-signal-channel. > >> intended control of configured filtering rules. Concretely, the >> DOTS >> client conveys 'acl-list' attribute with the following sub- >> attributes >> in the CBOR body of a mitigation request (see the YANG-encoded >> structure in Section 3.2.2.1): >> >> nit: YANG is a data description language, not an encoding; perhaps >> "YANG-formatted structure" or just "YANG structure" is better. > [Med] Changed to "YANG structure". > >> As the attack evolves, DOTS clients can adjust the 'activation- >> type' >> of an ACL conveyed in a mitigation request or control other filters >> as necessary. This can be achieved by sending a PUT request with a >> new 'mid' value. >> >> This potentially involves a lot of new 'mid' values if many change are >> made using signal-channel filtering control over the course of a given >> mitigation. Is this going to cause a noticeable increase in the >> amount >> of state required at the DOTS server? > [Med] No. Only the request with the highest 'mid' value will be maintained. > > We can add a reminder if you think this is useful. > >> If the DOTS client receives a 5.03 (Service Unavailable) with a >> diagnostic payload indicating a failed ACL update as a response to >> an >> initial mitigation or a mitigation with adjusted scope, the DOTS >> client MUST immediately send a new request which repeats all the >> parameters as sent in the failed mitigation request but without >> including the ACL attributes. After the expiry of Max-Age returned >> >> Why does this need to be a MUST-level requirement? What if the >> situation has changed in the interim and the mitigation update is no >> longer needed? > [Med] These requests are supposed to happen in a short interval and clients have to immediately place a mitigation request to avoid the inconvenience of including the ACLs. > > What about the following: > > s/client MUST immediately/client MUST by default immediately > >> in the 5.03 (Service Unavailable) response, the DOTS client retries >> with a new mitigation request (i.e., a new 'mid') that repeats all >> the parameters as sent in the failed mitigation request. >> >> Perhaps mention "including the ACL update" for clarity? >> > [Med] Works for me. > >> Section 3.2.2.1 >> >> +--rw acl-list* [acl-name] {control-filtering}? >> >> A question for the YANG doctor, no doubt, but is there a need for a >> feature indicator that gates the entire content of a given module (as >> opposed to just using module-level granularity to indicate support)? > [Med] I'm not a YANG doctor, but a feature needs to be defined within the module itself to mark parts that are conditional. I don't quite see why a module need to be explicitly taged as optional. This is actually why it is recommended that if you have a module with a large set of nodes with an if-feature, to define these nodes in a separate module. > >> Section 3.2.2.2 >> >> namespace >> "urn:ietf:params:xml:ns:yang:ietf-dots-signal-control"; >> prefix signal-control; >> >> Can we think of anything else that might be in scope in the future for >> which "signal-control" would be ambiguous or a name conflict? > [Med] What about "dots-control"? > >> list acl-list { >> key "acl-name"; >> >> Seeing this reminds me of a shadow of a memory that list keys are >> implicitly mandatory, which seems relevant for an earlier comment. >> > [Med] If an acl-list is present, then acl-name must be present. Nevertheless, an acl-list is not a mandatory. > >> [...] >> } >> leaf activation-type { >> type ietf-data:activation-type; >> default "activate-when-mitigating"; >> description >> "Sets the activation type of an ACL."; >> >> This structure seems to bind us to having a single activation-type >> that >> applies lto all of the ACLs in the acl-list; > [Med] Actually, no. We do have an activation-type value for each acl-name in the list. > > > furthermore, the global >> structure of where we augment means that we can only have one (acl- >> list, >> activation-type) pair within a given mitigation request. I *believe* >> that is consistent with the core signal protocol in terms of what's >> expected to be in a single message, but please confirm. >> >> Section 4 >> >> (The section heading should probably get the same treatment of "Sample >> Examples" as was previously used, and the body text here as well.) > [Med] Not sure about this one. Can you please clarify? > >> Section 4.1 >> >> Host: {host}:{port} >> >> nit(?): the data-channel doc just uses "example.com" for the host >> header >> field; it's not clear that we need to diverge from that style (applies >> throughout). > [Med] Good catch. Fixed. Thanks. > >> The DOTS client can also decide to send a PUT request to deactivate >> the "an-accept-list" ACL, if suspect traffic is received from an >> accept-listed source (2001:db8:1234::/48). The structure of that >> PUT >> is the same as the one shown in Figure 5. >> >> [...] >> Uri-Path: "mid=124" >> >> Just as a sanity-check: this "mid" of 124 is consistent with the note >> in >> Section 3.2.1 that adjusting the 'activation-type' "[...] can be >> achieved by sending a PUT request with a new 'mid' value", so the 124 >> (vs. 123) is intentional and correct. > [Med] I confirm. > >> "ietf-dots-signal-control:acl-list": [ >> { >> "ietf-dots-signal-control:acl-name": "an-accept-list", >> "ietf-dots-signal-control:activation-type": >> "deactivate" >> } >> ] >> "lifetime": 3600 >> >> Shouldn't there be a comma after the ']'? > [Med] Yes. Thanks for catching this. > >> (Have the examples been run through a JSON validator?) > [Med] will double check. > >> Section 4.3 >> >> Consider a DOTS client that contacts its DOTS server during 'idle' >> time to install an accept-list that rate-limits all (or a part >> thereof) traffic to be forwarded to 2001:db8:123::/48 as a last >> resort countermeasure whenever required. It does so by sending, >> for >> >> nit: I could imagine a little confusion as to whether the action >> referenced by "it does so" is the installation of the accept-list (my >> belief) or the rate-limiting. Perhaps "Installing the accpe-list can >> be >> done by sending, [...]"? > [Med] Fixed. > > >> example, a PUT request shown in Figure 9. The DOTS server installs >> >> nit: either "the PUT request shown" or "a PUT request as shown". > [Med] Fixed. > >> "actions": { >> "forwarding": "accept", >> "rate-limit": "20.00" >> >> 20 bytes per second? That seems rather small. > [Med] Indeed. Will increase the value used in the example. > >> For some reason (e.g., the DOTS server, or the mitigator, is >> lacking >> a capability or capacity), the DOTS client is still receiving the >> attack traffic which saturates available links. To soften the >> >> nit: I think s/the attack traffic/attack traffic/ is fine grammar. >> > [Med] Fixed. > >> Section 5.1 >> >> o Note to the RFC Editor: Please delete (TBA1-TBA2-TBA3) once the >> CBOR key is assigned from the 1-16383 range. Please update >> Table 1 accordingly. >> >> IIRC the unallocated values in this range include both values with a >> 2-byte encoding and with a 3-byte encoding; do we have a reason to >> prefer one or the other? > [Med] 2-byte encoding is preferred to keep the message compact. > > Since we're allocating from an "IETF Review" >> range, we get to suggest a value to IANA and it's not immediately >> clear >> to me how much say the DEs have in which value gets used. > [Med] Updated the table to suggest 52/53/54 values. > >> Section 6 >> >> We may get someone asking "this document uses YANG; why aren't you >> using >> the YANG security considerations template?" I guess the signal- >> channel >> doc made it through without any particular note in that regard, so >> maybe >> we'll be safe for this one, too. > [Med] Agree. We do say explicitly the following in the signal channel: > > = > This YANG module is not intended to be used via NETCONF/ > RESTCONF for DOTS server management purposes; such module is out of > the scope of this document. It serves only to provide a data model > and encoding, but not a management data model. > == > >> I'd consider mentioning that with both signal and data channels >> available for updating ACL activation status, there is potential for >> "skew" wherein an update made in one place is ~immediately overridden >> by >> another update. Fortunately, there was already some degree of >> asynchronicity/external-changes possible, so clients should already be >> prepared for this sort of situation and will cope properly by >> polling/OBSERVE notification. > [Med] Yeah. > >> We could also consider saying something about how the restriction to >> only changing activation status over the signal channel (but not >> creating new ACLS entirely) means that if a client hasn't prepared >> adequately prior to an attack, it can get stuck in a bad place. This, >> of course, is also not really new with this document, but is a pretty >> relevant consideration for its use. > [Med] Good point. Added this NEW text: > > This specification does not allow to create new filtering rules, > which is the responsibility of the DOTS data channel. DOTS client > domains should be adequately prepared prior to an attack, e.g., by > creating filters that will be activated on demand when an attack is > detected. > >> Similarly, a reminder that bad things happen when a DOTS server fails >> to >> maintain namespace separation across clients for ACL names could be in >> order (but is not required). > [Med] Added this NEW text: > > As a reminder, > DOTS servers must associate filtering rules with the DOTS client that > created these resources. Failure to ensure such association by a > DOTS server will have severe impact on DOTS client domains. > >> A compromised DOTS client can use the filtering control capability >> to >> exacerbate an ongoing attack. Likewise, such compromised DOTS >> client >> may abstain from reacting to an ACL conflict notification received >> >> nit: singular/plural mismatch "DOTS client"/"such compromised" (so >> either "such a compromised" or "DOTS clients"). > [Med] Fixed. Thanks. > >> Thanks, >> >> Ben > _______________________________________________ > Dots mailing list > Dots@ietf.org > https://www.ietf.org/mailman/listinfo/dots From nobody Thu May 14 01:28: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 B64E43A0775; Thu, 14 May 2020 01:28:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 fmDdX_vhC2gL; Thu, 14 May 2020 01:28:46 -0700 (PDT) Received: from mail.jpshallow.com (mail.jpshallow.com [217.40.240.153]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 664CC3A076C; Thu, 14 May 2020 01:28:45 -0700 (PDT) Received: from mail2.jpshallow.com ([192.168.0.3] helo=N01332) by mail.jpshallow.com with esmtp (Exim 4.92.3) (envelope-from ) id 1jZ9EN-0003YX-0F; Thu, 14 May 2020 09:28:39 +0100 From: "Jon Shallow" To: "'Daniel Migault'" , , "Benjamin Kaduk" , , References: <20200512202205.GF27494@kduck.mit.edu> In-Reply-To: Date: Thu, 14 May 2020 09:28:32 +0100 Message-ID: <134501d629c9$a74ec150$f5ec43f0$@jpshallow.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_1346_01D629D2.09160F80" X-Mailer: Microsoft Outlook 14.0 Content-Language: en-gb Thread-Index: AQKzIiZd+VfLYWZUXP6zIzno9dCSdAIA8f8DAWiy/JwB5GRVnabC3V9Q Archived-At: Subject: Re: [Dots] AD evaluation of draft-ietf-dots-use-cases-20 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, 14 May 2020 08:28:50 -0000 This is a multipart message in MIME format. ------=_NextPart_000_1346_01D629D2.09160F80 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Daniel, =20 The suggested text needs correcting OLD in some context such changed could NEW in some contexts such changes could =20 Regards =20 Jon =20 From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of Daniel Migault Sent: 14 May 2020 03:24 To: Teague, Francis Cc: draft-ietf-dots-use-cases.all@ietf.org; Benjamin Kaduk; dots Subject: Re: [Dots] AD evaluation of draft-ietf-dots-use-cases-20 =20 Thanks for the feed back Nick. I sort of understand that the current = text fits your comment, but prefer to double check before publishing the = next version. Feel free to change the text as you wish.=20 =20 Here is the text in question: """ These exact mechanisms used for traffic steering are out of scope of DOTS, but will need to be = pre-arranged, while in some context such changed could be detected and = considered as an attack. """ =20 Yours,=20 Daniel =20 On Wed, May 13, 2020 at 1:06 PM Teague, Francis = wrote: Hi, =20 Volumetry is awkward - generally an attack is characterized as = volumetric so volume would be correct IMO. =20 On the BGP side - My 2c - There are methods such as RPKI etc. which = present concerns for BGP based mitigations where implemented, however, = these may be overcome in a number of ways (the mitigator being = authorized to originate prefixes using the customer ASN for example = during an attack). The methods used to overcome these challenges while = remaining compliant with a particular mechanism are really between the = requestor and mitigator to thrash out. I'm not sure we should call it = out as its part of the wider relationship/onboarding process. It's = probably a topic for its own BCP though. =20 Thanks, =20 -Nik =20 On Wed, 13 May 2020 at 17:07, Daniel Migault = wrote: Hi,=20 =20 Thank you Ben for you comments. Please find inline how these have been = addressed. The updated version has been pushed to [1].=20 =20 The main questions I have for the co-authors are: * does the change of volumetry to volume causes any concern ? * I guess we could be a little be more specific regarding the delegation = and the pre-arrangement, in particular if BGP is secured. Please update = the text that has been proposed.=20 =20 Yours,=20 Daniel =20 =20 =20 [1] https://github.com/dotswg/dots-use-cases =20 On Tue, May 12, 2020 at 4:22 PM Benjamin Kaduk wrote: Hi all, This one is in pretty good shape -- I don't have any major comments on = it. I did write up some editorial nit-level stuff as a github pull request: https://github.com/dotswg/dots-use-cases/pull/12 . I think that nothing there should be controversial, but please let me know if I am wrong = about that. Please confirm that all six authors made significant contributions: I will need to defend this to the rest of the IESG, since per RFC 7322 the author count is generally limited to five individuals. Right now I = don't have a good response when someone asks. =20 As far as I know all authors mentioned significantly contributed to the = document. It is true that there are many co-authors, but I think that = reflected that DOTS needs to coordinate multiple actors that were not so = much coordinated before.=20 =20 Section 1 As DDoS solutions are broadly heterogeneous among vendors, the primary goal of DOTS is to provide high-level interaction amongst differing DDoS solutions, such as detecting, initiating, terminating DDoS mitigation assistance or requesting the status of a DDoS mitigation. nit: the list structure is not properly parallel. It looks like the various clauses are meant to be "detecting DDoS", "initiating/terminating mitigation assistance", and "requesting mitigation status", so maybe this could become: % As DDoS solutions are broadly heterogeneous among vendors, the % primary goal of DOTS is to provide high-level interaction amongst % differing DDoS solutions, such as detecting DDoS attacks, % initiating/terminating DDoS mitigation assistance, or requesting the % status of a DDoS mitigation. fixed =20 Section 3.1 Over the course of the attack, the DOTS server of the ITP periodically informs the DOTS client on the enterprise DMS mitigation status, statistics related to DDoS attack traffic mitigation, and related information. Once the DDoS attack has ended, or decreased to the certain level that the enterprise DMS can handle by itself, the DOTS server signals the enterprise DMS DOTS client that the attack has subsided. It's interesting that this is worded in such a way that the (ITP) DOTS server knows the specific threshold for what level of attack traffic the enterprise DMS can handle, since it's the DOTS server signalling to the client that "the attack has subsided". In most cases, if I recall correctly, we expect this to reflect a = contractual relation. That said, it is ultimately the DOTS client that = terminates the mitigation. To remove the impression that the ITP sort of = controls the DOTS client, I propose to change "can handle" by "may = handle". Here is the updated text: =20 Once the DDoS attack has ended, or decreased to the certain level that the enterprise DMS may handle by itself, the DOTS server signals the enterprise DMS DOTS client that the attack has subsided. =20 =20 Section 3.3 Upon receipt of the DOTS mitigation request from the DDoS telemetry system, the orchestrator DOTS server responds with an acknowledgment, to avoid retransmission of the request for mitigation. The orchestrator may begin collecting additional fine-grained and specific information from various DDoS telemetry systems in order to correlate the measurements and provide an analysis of the event. Eventually, the orchestrator may ask for additional information from the DDoS telemetry system; however, the collection of this information is out of scope. The last sentence seems to say that how the orchestrator gets data from the initial DOTS client telemtry system is out-of-scope, but the previous sentence talks about the orchestrator collecting information from (other) DOTS telemetry systems. Is that similarly out of scope? If so, then the fact that they are specifically *DOTS* telemetry systems seems irrelevant and we should probably just describe them as generic telemetry or monitoring systems. I agree that we should not have DOTS telemetry systems and leave them as = DDoS telemetry systems. I checked the current version and there is no = mention of DOTS telemetry but only DDoS telemetry.=20 I also suggest the we specify that such collection is out of scope of = DOTS. with the following sentence: =20 the collection of this information is out of scope of DOTS. =20 Upon receiving a request to mitigate a DDoS attack performed over a target, the orchestrator may evaluate the volumetry of the attack as nit(?): is "performed over" a conventional usage? I would have expected something more like "aimed at" given my personal background, but could just be ignorant of typical usage. changed. =20 Also, I think "volumetry" is not the right word here, and just "volume" suffices. I am fine either way. The current version changed to volume, but I am = waiting co-authors to confirm they agree with the change.=20 =20 filter the traffic. In this case, the DDoS mitigation system implements a DOTS client while the orchestrator implements a DOTS server. Similar to other DOTS use cases, the offloading scenario assumes that some validation checks are followed by the DMS, the orchestrator, or both (e.g., avoid exhausting the resources of the forwarding nodes or disrupting the service). These validation checks are part of the mitigation, and are therefore out of the scope of the document. I know we added this last chunk of text after a long exchange during the last WGLC, and understand the desire to avoid going into too many details on a topic that is mostly out of scope for DOTS. That said, I'd suggest adding a couple more words around "disrupting the service" (especially since some level of service disruption during an attack might be expected!) to help the reader make the link to what kind of validation is expected, perhaps something like "inadvertent disruption of legitimate services". fixed with the follwoing snetence: =20 Similar to other DOTS use cases, the offloading scenario assumes that = some validation checks are followed by the DMS, the orchestrator, or = both (e.g., avoid exhausting the resources of the forwarding nodes or = inadvertent disruption of legitimate services). =20 Section 4 In light of my previous comment I don't want to go too far here, but I could see it being relevant to have a note that in the "orchestration" case it's possible for something that locally to one telemetry system looks like an attack is not actually an attack when seen from the broader scope (e.g., of the orchestrator). I added the note in the following paragraph.=20 =20 These systems are configured so that when an event or some measurement indicators reach a predefined level their associated DOTS client sends a DOTS mitigation request to the orchestrator DOTS server. The DOTS mitigation request may be associated with some optional mitigation hints to let the orchestrator know what has triggered the request. In = particular, it's possible for something that locally to one telemetry = system looks like an attack is not actually an attack when seen from the = broader scope (e.g., of the orchestrator) =20 =20 In the Third Party MSP case we mention BGP as a way to steer traffic to the mitigation service. We could consider (but don't have to) mentioning that efforts to secure BGP will need to be considered when making pre-arrangements for how traffic is to be moved, since in some contexts such BGP announcements could themselves be considered to be an attack. Being ignorant on BGP, I am wondering if you are thinking of a BGP = procedure to announce routes or some procedure for enabling a delegation = when BGPsec is considered.=20 I porpose the following text: =20 These exact mechanisms used for traffic steering are out of scope of DOTS, but will need to be = pre-arranged, while in some context such changed could be detected and = considered as an attack. =20 I guess it probably goes without saying that when you add a third-party DMS to your setup, you depend on that third party to be operational in order for your setup to work properly. Section 7 We'll probably get someone asking to move RFC 8612 to be a Normative reference since we use it for terminology, but I don't mind leaving it be for now. =20 I put it as normative.=20 =20 Thanks, Ben _______________________________________________ Dots mailing list Dots@ietf.org https://www.ietf.org/mailman/listinfo/dots =20 --=20 Daniel Migault Ericsson The information contained in this email message and its attachments is = intended only for the private and confidential use of the recipient(s) = named above, unless the sender expressly agrees otherwise. Transmission = of email over the Internet is not a secure communications medium. If you = are requesting or have requested the transmittal of personal data, as = defined in applicable privacy laws by means of email or in an attachment = to email, you must select a more secure alternate means of transmittal = that supports your obligations to protect such personal data.=20 =20 If the reader of this message is not the intended recipient and/or you = have received this email in error, you must take no action based on the = information in this email and you are hereby notified that any = dissemination, misuse or copying or disclosure of this communication is = strictly prohibited. If you have received this communication in error, = please notify us immediately by email and delete the original message.=20 =20 --=20 Daniel Migault Ericsson ------=_NextPart_000_1346_01D629D2.09160F80 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Hi Daniel,

 

The suggested text needs correcting

OLD

in some context such = changed could

NEW

in some contexts such changes could

 

Regards

 

Jon

 

From:= Dots = [mailto: dots-bounces@ietf.org] On Behalf Of Daniel = Migault
Sent: 14 May 2020 03:24
To: Teague, = Francis
Cc: draft-ietf-dots-use-cases.all@ietf.org; Benjamin = Kaduk; dots
Subject: Re: [Dots] AD evaluation of = draft-ietf-dots-use-cases-20

 

Thanks = for the feed back Nick. I sort of understand that the current text = fits your comment, but prefer to double check before publishing the next = version. Feel free to change the text as you = wish. 

 

Here is the text in = question:

"""

These exact mechanisms
used for traffic steering = are out of scope of DOTS, but will need to be pre-arranged, while in = some context such changed could be detected and considered as an = attack.

"""

 

Yours, 

Daniel

 

On = Wed, May 13, 2020 at 1:06 PM Teague, Francis <nteague@ironmountain.co.uk= > wrote:

Hi,

 

Volumetry is awkward - generally an attack is = characterized as volumetric so volume would be correct = IMO.

 

On the BGP side - My 2c - There are methods such as = RPKI etc. which present concerns for BGP based mitigations where = implemented, however, these may be overcome in a number of ways = (the mitigator being authorized to originate prefixes using the customer = ASN for example during an attack).  The methods used to overcome = these challenges while remaining compliant with a particular mechanism = are really between the requestor and mitigator to thrash out.  I'm = not sure we should call it out as its part of the wider = relationship/onboarding process.  It's probably a topic for its own = BCP though.

 

Thanks,

 

-Nik

 

On = Wed, 13 May 2020 at 17:07, Daniel Migault <mglt.ietf@gmail.com> = wrote:

Hi, 

 

Thank you Ben for you comments. Please find inline how = these have been addressed. The updated version has been pushed to = [1]. 

 

The main questions I have for the co-authors = are:

* does the change of = volumetry to volume causes any concern ?

* I guess we could be a little be more specific = regarding the delegation and the pre-arrangement, in particular if BGP = is secured. Please update the text that has been = proposed. 

 

Yours, 

Daniel   

 

 

[1] https://github.com/dotswg/dots-use-cases=

 

On Tue, May 12, 2020 at 4:22 PM Benjamin Kaduk <kaduk@mit.edu> = wrote:

Hi = all,

This one is in pretty good shape -- I don't have any major = comments on it.
I did write up some editorial nit-level stuff as a = github pull request:
https://github.com/dotswg/dots-use-cases/pull/12 = .  I think that nothing
there should be controversial, but = please let me know if I am wrong about
that.

Please confirm = that all six authors made significant contributions: I
will need to = defend this to the rest of the IESG, since per RFC 7322 the
author = count is generally limited to five individuals.  Right now I = don't
have a good response when someone = asks.

 

<mglt>

As far as I know all authors mentioned significantly = contributed to the document. It is true that there are many co-authors, = but I think that reflected that DOTS needs to coordinate multiple actors = that were not so much coordinated = before. 

</mglt> 


Section 1

   As DDoS = solutions are broadly heterogeneous among vendors, the
  =  primary goal of DOTS is to provide high-level interaction = amongst
   differing DDoS solutions, such as detecting, = initiating, terminating
   DDoS mitigation assistance or = requesting the status of a DDoS
   mitigation.

nit: = the list structure is not properly parallel.  It looks like = the
various clauses are meant to be "detecting = DDoS",
"initiating/terminating mitigation assistance", = and "requesting
mitigation status", so maybe this could = become:

% As DDoS solutions are broadly heterogeneous among = vendors, the
% primary goal of DOTS is to provide high-level = interaction amongst
% differing DDoS solutions, such as detecting = DDoS attacks,
% initiating/terminating DDoS mitigation assistance, or = requesting the
% status of a DDoS = mitigation.

<mglt>

fixed

</mglt> 

Section = 3.1

   Over the course of the attack, the DOTS server = of the ITP
   periodically informs the DOTS client on the = enterprise DMS mitigation
   status, statistics related to = DDoS attack traffic mitigation, and
   related = information.  Once the DDoS attack has ended, or decreased = to
   the certain level that the enterprise DMS can handle = by itself, the
   DOTS server signals the enterprise DMS = DOTS client that the attack
   has subsided.

It's = interesting that this is worded in such a way that the (ITP) = DOTS
server knows the specific threshold for what level of attack = traffic the
enterprise DMS can handle, since it's the DOTS server = signalling to the
client that "the attack has = subsided".

<mglt>

In most cases, if I recall correctly, we expect this = to reflect a contractual relation. That said, it is ultimately the DOTS = client that terminates the mitigation. To remove the impression that the = ITP sort of controls the DOTS client, I propose to change "can = handle" by "may handle".  Here is the updated = text:

 

Once the DDoS attack has ended, or decreased to the = certain
level that the enterprise DMS may handle by itself, the DOTS = server
signals the enterprise DMS DOTS client that the attack has = subsided.

</mglt> 

 

Section 3.3

   Upon = receipt of the DOTS mitigation request from the DDoS telemetry
  =  system, the orchestrator DOTS server responds with an = acknowledgment,
   to avoid retransmission of the request = for mitigation.  The
   orchestrator may begin = collecting additional fine-grained and
   specific = information from various DDoS telemetry systems in order to
  =  correlate the measurements and provide an analysis of the = event.
   Eventually, the orchestrator may ask for = additional information from
   the DDoS telemetry system; = however, the collection of this
   information is out of = scope.

The last sentence seems to say that how the orchestrator = gets data from
the initial DOTS client telemtry system is = out-of-scope, but the
previous sentence talks about the orchestrator = collecting information
from (other) DOTS telemetry systems.  Is = that similarly out of scope?
If so, then the fact that they are = specifically *DOTS* telemetry systems
seems irrelevant and we should = probably just describe them as generic
telemetry or monitoring = systems.

<mglt>

I agree that we should not have DOTS telemetry systems = and leave them as DDoS telemetry systems. I checked the current version = and there is no mention of DOTS telemetry but only DDoS = telemetry. 

I also = suggest the we specify that such collection is out of scope of DOTS. = with the following sentence:

 

the collection of this information is out of scope of = DOTS.

</mglt>

 

  =  Upon receiving a request to mitigate a DDoS attack performed over = a
   target, the orchestrator may evaluate the volumetry of = the attack as

nit(?): is "performed over" a = conventional usage?  I would have expected
something more like = "aimed at" given my personal background, but could
just be = ignorant of typical usage.

<mglt>

changed.

</mglt> 


Also, = I think "volumetry" is not the right word here, and just = "volume"
suffices.

<mglt>

I am fine either way. The current version changed to = volume, but I am waiting co-authors to confirm they agree with the = change. 

</mglt> 


   filter the = traffic.  In this case, the DDoS mitigation system
  =  implements a DOTS client while the orchestrator implements a = DOTS
   server.  Similar to other DOTS use cases, the = offloading scenario
   assumes that some validation checks = are followed by the DMS, the
   orchestrator, or both = (e.g., avoid exhausting the resources of the
   forwarding = nodes or disrupting the service).  These validation = checks
   are part of the mitigation, and are therefore out = of the scope of the
   document.

I know we added = this last chunk of text after a long exchange during the
last WGLC, = and understand the desire to avoid going into too many
details on a = topic that is mostly out of scope for DOTS.  That said, = I'd
suggest adding a couple more words around "disrupting the = service"
(especially since some level of service disruption = during an attack
might be expected!) to help the reader make the link = to what kind of
validation is expected, perhaps something like = "inadvertent disruption
of legitimate = services".

<mglt>

fixed with the follwoing = snetence:

 

Similar to other DOTS use cases, the offloading = scenario assumes that some validation checks are followed by the DMS, = the orchestrator, or both (e.g., avoid exhausting the resources of the = forwarding nodes or inadvertent disruption of legitimate = services).

</mglt> 

Section 4

In light of my previous = comment I don't want to go too far here, but I
could see it being = relevant to have a note that in the "orchestration"
case = it's possible for something that locally to one telemetry = system
looks like an attack is not actually an attack when seen from = the
broader scope (e.g., of the = orchestrator).

<mglt>

I added the note in the following = paragraph. 

 

These systems are configured so that when an event or = some measurement
indicators reach a predefined level their associated = DOTS client sends a
DOTS mitigation request to the orchestrator DOTS = server. The DOTS
mitigation request may be associated with some = optional mitigation hints
to let the orchestrator know what has = triggered the request. In particular, it's possible for something that = locally to one telemetry system looks like an attack is not actually an = attack when seen from the broader scope (e.g., of the = orchestrator)

</mglt> 

 

In the Third Party MSP case we mention = BGP as a way to steer traffic to
the mitigation service.  We = could consider (but don't have to)
mentioning that efforts to secure = BGP will need to be considered when
making pre-arrangements for how = traffic is to be moved, since in some
contexts such BGP announcements = could themselves be considered to be = an
attack.

<mglt>

Being ignorant on BGP, I am wondering if you are = thinking of a BGP procedure to announce routes or some procedure = for enabling a delegation when BGPsec is = considered. 

I = porpose the following text:

 

These exact mechanisms
used for = traffic steering are out of scope of DOTS, but will need to be = pre-arranged, while in some context such changed could be detected and = considered as an attack.

</mglt> 

I guess = it probably goes without saying that when you add a third-party
DMS = to your setup, you depend on that third party to be operational = in
order for your setup to work properly.

Section = 7

We'll probably get someone asking to move RFC 8612 to be a = Normative
reference since we use it for terminology, but I don't mind = leaving it
be for now.

 

<mglt>

I put it as = normative. 

</mglt> 


Thanks,

Ben

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


 

-- =

Daniel = Migault

Ericsson


The = information contained in this email message and its attachments is = intended only for the private and confidential use of the recipient(s) = named above, unless the sender expressly agrees otherwise. Transmission = of email over the Internet is not a secure communications medium. If you = are requesting or have requested the transmittal of personal data, as = defined in applicable privacy laws by means of email or in an attachment = to email, you must select a more secure alternate means of transmittal = that supports your obligations to protect such personal = data. 

 

If the = reader of this message is not the intended recipient and/or you have = received this email in error, you must take no action based on the = information in this email and you are hereby notified that any = dissemination, misuse or copying or disclosure of this communication is = strictly prohibited. If you have received this communication in error, = please notify us immediately by email and delete the original = message. 


 

-- =

Daniel = Migault

Ericsson

------=_NextPart_000_1346_01D629D2.09160F80-- From nobody Fri May 15 12:59:51 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 B02033A08B3; Fri, 15 May 2020 12:59:49 -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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jAxSoJFo4vy3; Fri, 15 May 2020 12:59:46 -0700 (PDT) Received: from mail-vs1-xe34.google.com (mail-vs1-xe34.google.com [IPv6:2607:f8b0:4864:20::e34]) (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 84EE03A08B1; Fri, 15 May 2020 12:59:46 -0700 (PDT) Received: by mail-vs1-xe34.google.com with SMTP id e20so1398980vsb.5; Fri, 15 May 2020 12:59:46 -0700 (PDT) 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 :cc; bh=tR9cOUCsQBTAq+YbJuk1HdgqsqVMCb5OVka3yO0NVuU=; b=BPM6lLPBte+G3NqZTQYGNfAq4YGnwmhv4ASq/wicdTIl7F+b+yMfmQbjscxk8+1bD1 2DoekBoYA4EcAsoAaVAnZEI28d368kaCtmoX0VlzDXURQaWdSHTAfG9Mt+oVErACmjPW J61yvyseOu4AHmCxAM5xmekgxW55VJYdgSRkFWhw145VfeAbFM/FvlwFXeLeruFbbb3J +gFWVcG/4GScZdQzFTQbSEzPF6PJUbEU5A4exSY3Y4nm5rQ8CtRIOwnO/oX7UGiBOMx8 RlsSK+HIc9AlGwxDT7R4Ydawzm5kdcxdP3D06tnJJCrHRBDlFzAP8oukDKIGE4FXo9N2 DYQg== 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:cc; bh=tR9cOUCsQBTAq+YbJuk1HdgqsqVMCb5OVka3yO0NVuU=; b=XIIYnVfns9nMsiGUibmVKgpQ7fp81cLzvXghmHYwZpY5QJ3gdeC0uRUjwpYlM7LQ8q iV28vUEN4rrBCOTpISFAIBuM7I3b2koNcPtCBr6iTlZZmEUD2jm6wLjmap9Y+QY04HoX aHqroMJpXjoj9AIHiFib6Yhhawt677xz+iVgN6L8WMQaOpSPgJoz0yAALvFbJ2dO20cn zyU8m2duAui2A7J6iRGklbCUMcRQnam19thB81kll40m+PM/CYsBCflfCL7yN3Ox/qj0 7xkMyLS7+WhRX52Ydf7wzqm7678j7cGNSoZo2uB2RDl/8Mssps6VMvLBh/DvTMpzKAr4 NYHw== X-Gm-Message-State: AOAM532rspbhRcZgQdBl2miEmWbDDV0mxCt8Gz5RY8omLxwuuurmT0gr 4cdnQ/LZqyn2HvfcU17FmUqyqbU3KhjXcMgMrSo= X-Google-Smtp-Source: ABdhPJxWabqGrtW2cpKkq93TboOZ7dP3CtCkNHT9EOPJI+OQZgHpM5oTueYPUKrlqCyduXd7ylUMt+wvNiOOcZ/oDs8= X-Received: by 2002:a67:2e01:: with SMTP id u1mr3886560vsu.31.1589572785425; Fri, 15 May 2020 12:59:45 -0700 (PDT) MIME-Version: 1.0 References: <20200512202205.GF27494@kduck.mit.edu> <20200514024918.GQ27494@kduck.mit.edu> In-Reply-To: <20200514024918.GQ27494@kduck.mit.edu> From: Daniel Migault Date: Fri, 15 May 2020 15:59:34 -0400 Message-ID: To: Benjamin Kaduk Cc: draft-ietf-dots-use-cases.all@ietf.org, dots Content-Type: multipart/alternative; boundary="0000000000003850e905a5b5417c" Archived-At: Subject: Re: [Dots] AD evaluation of draft-ietf-dots-use-cases-20 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, 15 May 2020 19:59:50 -0000 --0000000000003850e905a5b5417c Content-Type: text/plain; charset="UTF-8" Hi Ben, Thanks for the follow up. I believe I implemented the changes, and will publish a new version. Yours, Daniel On Wed, May 13, 2020 at 10:49 PM Benjamin Kaduk wrote: > Hi Daniel, > > Just a few replies inline. > > On Wed, May 13, 2020 at 12:06:45PM -0400, Daniel Migault wrote: > > Hi, > > > > Thank you Ben for you comments. Please find inline how these have been > > addressed. The updated version has been pushed to [1]. > > > > The main questions I have for the co-authors are: > > * does the change of volumetry to volume causes any concern ? > > * I guess we could be a little be more specific regarding the delegation > > and the pre-arrangement, in particular if BGP is secured. Please update > > the text that has been proposed. > > > > Yours, > > Daniel > > > > > > [1] https://github.com/dotswg/dots-use-cases > > > > On Tue, May 12, 2020 at 4:22 PM Benjamin Kaduk wrote: > > > > > Hi all, > > > > > > This one is in pretty good shape -- I don't have any major comments on > it. > > > I did write up some editorial nit-level stuff as a github pull request: > > > https://github.com/dotswg/dots-use-cases/pull/12 . I think that > nothing > > > there should be controversial, but please let me know if I am wrong > about > > > that. > > > > > > Please confirm that all six authors made significant contributions: I > > > will need to defend this to the rest of the IESG, since per RFC 7322 > the > > > author count is generally limited to five individuals. Right now I > don't > > > have a good response when someone asks. > > > > > > > > > As far as I know all authors mentioned significantly contributed to the > > document. It is true that there are many co-authors, but I think that > > reflected that DOTS needs to coordinate multiple actors that were not so > > much coordinated before. > > > > Thanks, that is good to know. > > > > > > > Section 1 > > > > > > As DDoS solutions are broadly heterogeneous among vendors, the > > > primary goal of DOTS is to provide high-level interaction amongst > > > differing DDoS solutions, such as detecting, initiating, terminating > > > DDoS mitigation assistance or requesting the status of a DDoS > > > mitigation. > > > > > > nit: the list structure is not properly parallel. It looks like the > > > various clauses are meant to be "detecting DDoS", > > > "initiating/terminating mitigation assistance", and "requesting > > > mitigation status", so maybe this could become: > > > > > > % As DDoS solutions are broadly heterogeneous among vendors, the > > > % primary goal of DOTS is to provide high-level interaction amongst > > > % differing DDoS solutions, such as detecting DDoS attacks, > > > % initiating/terminating DDoS mitigation assistance, or requesting the > > > % status of a DDoS mitigation. > > > > > > > > fixed > > > > > > > Section 3.1 > > > > > > Over the course of the attack, the DOTS server of the ITP > > > periodically informs the DOTS client on the enterprise DMS > mitigation > > > status, statistics related to DDoS attack traffic mitigation, and > > > related information. Once the DDoS attack has ended, or decreased > to > > > the certain level that the enterprise DMS can handle by itself, the > > > DOTS server signals the enterprise DMS DOTS client that the attack > > > has subsided. > > > > > > It's interesting that this is worded in such a way that the (ITP) DOTS > > > server knows the specific threshold for what level of attack traffic > the > > > enterprise DMS can handle, since it's the DOTS server signalling to the > > > client that "the attack has subsided". > > > > > > > > In most cases, if I recall correctly, we expect this to reflect a > > contractual relation. That said, it is ultimately the DOTS client that > > terminates the mitigation. To remove the impression that the ITP sort of > > controls the DOTS client, I propose to change "can handle" by "may > > handle". Here is the updated text: > > > > Once the DDoS attack has ended, or decreased to the certain > > level that the enterprise DMS may handle by itself, the DOTS server > > signals the enterprise DMS DOTS client that the attack has subsided. > > > > I'd consider "might" instead of "may", since sometimes in English "may" has > a connotation of granting permission. > changed. > > > Section 3.3 > > > > > > Upon receipt of the DOTS mitigation request from the DDoS telemetry > > > system, the orchestrator DOTS server responds with an > acknowledgment, > > > to avoid retransmission of the request for mitigation. The > > > orchestrator may begin collecting additional fine-grained and > > > specific information from various DDoS telemetry systems in order to > > > correlate the measurements and provide an analysis of the event. > > > Eventually, the orchestrator may ask for additional information from > > > the DDoS telemetry system; however, the collection of this > > > information is out of scope. > > > > > > The last sentence seems to say that how the orchestrator gets data from > > > the initial DOTS client telemtry system is out-of-scope, but the > > > previous sentence talks about the orchestrator collecting information > > > from (other) DOTS telemetry systems. Is that similarly out of scope? > > > If so, then the fact that they are specifically *DOTS* telemetry > systems > > > seems irrelevant and we should probably just describe them as generic > > > telemetry or monitoring systems. > > > > > > > > I agree that we should not have DOTS telemetry systems and leave them as > > DDoS telemetry systems. I checked the current version and there is no > > mention of DOTS telemetry but only DDoS telemetry. > > Oops, I seem to have misread this text! Of course, generic DDoS telemetry > systems make sense in this context. > > > I also suggest the we specify that such collection is out of scope of > DOTS. > > with the following sentence: > > > > the collection of this information is out of scope of DOTS. > > Okay. > > > > > > > > > > Upon receiving a request to mitigate a DDoS attack performed over a > > > target, the orchestrator may evaluate the volumetry of the attack as > > > > > > nit(?): is "performed over" a conventional usage? I would have > expected > > > something more like "aimed at" given my personal background, but could > > > just be ignorant of typical usage. > > > > > > > changed. > > > > > > > > > > Also, I think "volumetry" is not the right word here, and just "volume" > > > suffices. > > > > > > > I am fine either way. The current version changed to volume, but I am > > waiting co-authors to confirm they agree with the change. > > > > > > > > > > filter the traffic. In this case, the DDoS mitigation system > > > implements a DOTS client while the orchestrator implements a DOTS > > > server. Similar to other DOTS use cases, the offloading scenario > > > assumes that some validation checks are followed by the DMS, the > > > orchestrator, or both (e.g., avoid exhausting the resources of the > > > forwarding nodes or disrupting the service). These validation > checks > > > are part of the mitigation, and are therefore out of the scope of > the > > > document. > > > > > > I know we added this last chunk of text after a long exchange during > the > > > last WGLC, and understand the desire to avoid going into too many > > > details on a topic that is mostly out of scope for DOTS. That said, > I'd > > > suggest adding a couple more words around "disrupting the service" > > > (especially since some level of service disruption during an attack > > > might be expected!) to help the reader make the link to what kind of > > > validation is expected, perhaps something like "inadvertent disruption > > > of legitimate services". > > > > > > > > fixed with the follwoing snetence: > > > > Similar to other DOTS use cases, the offloading scenario assumes that > some > > validation checks are followed by the DMS, the orchestrator, or both > (e.g., > > avoid exhausting the resources of the forwarding nodes or inadvertent > > disruption of legitimate services). > > > > > > > Section 4 > > > > > > In light of my previous comment I don't want to go too far here, but I > > > could see it being relevant to have a note that in the "orchestration" > > > case it's possible for something that locally to one telemetry system > > > looks like an attack is not actually an attack when seen from the > > > broader scope (e.g., of the orchestrator). > > > > > > > > I added the note in the following paragraph. > > > > These systems are configured so that when an event or some measurement > > indicators reach a predefined level their associated DOTS client sends a > > DOTS mitigation request to the orchestrator DOTS server. The DOTS > > mitigation request may be associated with some optional mitigation hints > > to let the orchestrator know what has triggered the request. In > particular, > > it's possible for something that locally to one telemetry system looks > like > > an attack is not actually an attack when seen from the broader scope > (e.g., > > of the orchestrator) > > > > > > In the Third Party MSP case we mention BGP as a way to steer traffic to > > > the mitigation service. We could consider (but don't have to) > > > mentioning that efforts to secure BGP will need to be considered when > > > making pre-arrangements for how traffic is to be moved, since in some > > > contexts such BGP announcements could themselves be considered to be an > > > attack. > > > > > > > > Being ignorant on BGP, I am wondering if you are thinking of a BGP > > procedure to announce routes or some procedure for enabling a delegation > > when BGPsec is considered. > > I think either could be problmatic in some (rare?) circumstances -- I > believe in some cases there are allow-lists for which neighbors' > announcements of which prefixes are acted upon, and of course when the RPKI > comes into play that needs to validate properly as well. > > > I porpose the following text: > > > > These exact mechanisms > > used for traffic steering are out of scope of DOTS, but will need to be > > pre-arranged, while in some context such changed could be detected and > > considered as an attack. > > I agree with the other commenters that a separate BCP is where the details > should be covered. > > > > > > > > I guess it probably goes without saying that when you add a third-party > > > DMS to your setup, you depend on that third party to be operational in > > > order for your setup to work properly. > > > > > > Section 7 > > > > > > We'll probably get someone asking to move RFC 8612 to be a Normative > > > reference since we use it for terminology, but I don't mind leaving it > > > be for now. > > > > > > > > > I put it as normative. > > Thanks, > > Ben > -- Daniel Migault Ericsson --0000000000003850e905a5b5417c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Ben,=C2=A0

Thanks for the= follow up. I believe I implemented the changes, and will publish a new ver= sion.=C2=A0
Yours,=C2=A0
Daniel=C2=A0
On Wed, May 13, 2020 at = 10:49 PM Benjamin Kaduk <kaduk@mit.edu<= /a>> wrote:
H= i Daniel,

Just a few replies inline.

On Wed, May 13, 2020 at 12:06:45PM -0400, Daniel Migault wrote:
> Hi,
>
> Thank you Ben for you comments. Please find inline how these have been=
> addressed. The updated version has been pushed to [1].
>
> The main questions I have for the co-authors are:
> * does the change of volumetry to volume causes any concern ?
> * I guess we could be a little be more specific regarding the delegati= on
> and the pre-arrangement, in particular if BGP is secured. Please updat= e
> the text that has been proposed.
>
> Yours,
> Daniel
>
>
> [1] https://github.com/dotswg/dots-use-cases
>
> On Tue, May 12, 2020 at 4:22 PM Benjamin Kaduk <kaduk@mit.edu> wrote:
>
> > Hi all,
> >
> > This one is in pretty good shape -- I don't have any major co= mments on it.
> > I did write up some editorial nit-level stuff as a github pull re= quest:
> > https://github.com/dotswg/dots-use-cases/= pull/12 .=C2=A0 I think that nothing
> > there should be controversial, but please let me know if I am wro= ng about
> > that.
> >
> > Please confirm that all six authors made significant contribution= s: I
> > will need to defend this to the rest of the IESG, since per RFC 7= 322 the
> > author count is generally limited to five individuals.=C2=A0 Righ= t now I don't
> > have a good response when someone asks.
> >
>
> <mglt>
> As far as I know all authors mentioned significantly contributed to th= e
> document. It is true that there are many co-authors, but I think that<= br> > reflected that DOTS needs to coordinate multiple actors that were not = so
> much coordinated before.
> </mglt>

Thanks, that is good to know.

> >
> > Section 1
> >
> >=C2=A0 =C2=A0 As DDoS solutions are broadly heterogeneous among ve= ndors, the
> >=C2=A0 =C2=A0 primary goal of DOTS is to provide high-level intera= ction amongst
> >=C2=A0 =C2=A0 differing DDoS solutions, such as detecting, initiat= ing, terminating
> >=C2=A0 =C2=A0 DDoS mitigation assistance or requesting the status = of a DDoS
> >=C2=A0 =C2=A0 mitigation.
> >
> > nit: the list structure is not properly parallel.=C2=A0 It looks = like the
> > various clauses are meant to be "detecting DDoS",
> > "initiating/terminating mitigation assistance", and &qu= ot;requesting
> > mitigation status", so maybe this could become:
> >
> > % As DDoS solutions are broadly heterogeneous among vendors, the<= br> > > % primary goal of DOTS is to provide high-level interaction among= st
> > % differing DDoS solutions, such as detecting DDoS attacks,
> > % initiating/terminating DDoS mitigation assistance, or requestin= g the
> > % status of a DDoS mitigation.
> >
> > <mglt>
> fixed
> </mglt>
>
> > Section 3.1
> >
> >=C2=A0 =C2=A0 Over the course of the attack, the DOTS server of th= e ITP
> >=C2=A0 =C2=A0 periodically informs the DOTS client on the enterpri= se DMS mitigation
> >=C2=A0 =C2=A0 status, statistics related to DDoS attack traffic mi= tigation, and
> >=C2=A0 =C2=A0 related information.=C2=A0 Once the DDoS attack has = ended, or decreased to
> >=C2=A0 =C2=A0 the certain level that the enterprise DMS can handle= by itself, the
> >=C2=A0 =C2=A0 DOTS server signals the enterprise DMS DOTS client t= hat the attack
> >=C2=A0 =C2=A0 has subsided.
> >
> > It's interesting that this is worded in such a way that the (= ITP) DOTS
> > server knows the specific threshold for what level of attack traf= fic the
> > enterprise DMS can handle, since it's the DOTS server signall= ing to the
> > client that "the attack has subsided".
> >
> > <mglt>
> In most cases, if I recall correctly, we expect this to reflect a
> contractual relation. That said, it is ultimately the DOTS client that=
> terminates the mitigation. To remove the impression that the ITP sort = of
> controls the DOTS client, I propose to change "can handle" b= y "may
> handle".=C2=A0 Here is the updated text:
>
> Once the DDoS attack has ended, or decreased to the certain
> level that the enterprise DMS may handle by itself, the DOTS server > signals the enterprise DMS DOTS client that the attack has subsided. > </mglt>

I'd consider "might" instead of "may", since someti= mes in English "may" has
a connotation of granting permission.
<mglt>
changed.
</mglt>=C2=A0

> Section 3.3
> >
> >=C2=A0 =C2=A0 Upon receipt of the DOTS mitigation request from the= DDoS telemetry
> >=C2=A0 =C2=A0 system, the orchestrator DOTS server responds with a= n acknowledgment,
> >=C2=A0 =C2=A0 to avoid retransmission of the request for mitigatio= n.=C2=A0 The
> >=C2=A0 =C2=A0 orchestrator may begin collecting additional fine-gr= ained and
> >=C2=A0 =C2=A0 specific information from various DDoS telemetry sys= tems in order to
> >=C2=A0 =C2=A0 correlate the measurements and provide an analysis o= f the event.
> >=C2=A0 =C2=A0 Eventually, the orchestrator may ask for additional = information from
> >=C2=A0 =C2=A0 the DDoS telemetry system; however, the collection o= f this
> >=C2=A0 =C2=A0 information is out of scope.
> >
> > The last sentence seems to say that how the orchestrator gets dat= a from
> > the initial DOTS client telemtry system is out-of-scope, but the<= br> > > previous sentence talks about the orchestrator collecting informa= tion
> > from (other) DOTS telemetry systems.=C2=A0 Is that similarly out = of scope?
> > If so, then the fact that they are specifically *DOTS* telemetry = systems
> > seems irrelevant and we should probably just describe them as gen= eric
> > telemetry or monitoring systems.
> >
> > <mglt>
> I agree that we should not have DOTS telemetry systems and leave them = as
> DDoS telemetry systems. I checked the current version and there is no<= br> > mention of DOTS telemetry but only DDoS telemetry.

Oops, I seem to have misread this text!=C2=A0 Of course, generic DDoS telem= etry
systems make sense in this context.

> I also suggest the we specify that such collection is out of scope of = DOTS.
> with the following sentence:
>
> the collection of this information is out of scope of DOTS.

Okay.

> </mglt>
>
>
> >=C2=A0 =C2=A0 Upon receiving a request to mitigate a DDoS attack p= erformed over a
> >=C2=A0 =C2=A0 target, the orchestrator may evaluate the volumetry = of the attack as
> >
> > nit(?): is "performed over" a conventional usage?=C2=A0= I would have expected
> > something more like "aimed at" given my personal backgr= ound, but could
> > just be ignorant of typical usage.
> >
> <mglt>
> changed.
> </mglt>
>
> >
> > Also, I think "volumetry" is not the right word here, a= nd just "volume"
> > suffices.
> >
> <mglt>
> I am fine either way. The current version changed to volume, but I am<= br> > waiting co-authors to confirm they agree with the change.
> </mglt>
>
> >
> >=C2=A0 =C2=A0 filter the traffic.=C2=A0 In this case, the DDoS mit= igation system
> >=C2=A0 =C2=A0 implements a DOTS client while the orchestrator impl= ements a DOTS
> >=C2=A0 =C2=A0 server.=C2=A0 Similar to other DOTS use cases, the o= ffloading scenario
> >=C2=A0 =C2=A0 assumes that some validation checks are followed by = the DMS, the
> >=C2=A0 =C2=A0 orchestrator, or both (e.g., avoid exhausting the re= sources of the
> >=C2=A0 =C2=A0 forwarding nodes or disrupting the service).=C2=A0 T= hese validation checks
> >=C2=A0 =C2=A0 are part of the mitigation, and are therefore out of= the scope of the
> >=C2=A0 =C2=A0 document.
> >
> > I know we added this last chunk of text after a long exchange dur= ing the
> > last WGLC, and understand the desire to avoid going into too many=
> > details on a topic that is mostly out of scope for DOTS.=C2=A0 Th= at said, I'd
> > suggest adding a couple more words around "disrupting the se= rvice"
> > (especially since some level of service disruption during an atta= ck
> > might be expected!) to help the reader make the link to what kind= of
> > validation is expected, perhaps something like "inadvertent = disruption
> > of legitimate services".
> >
> > <mglt>
> fixed with the follwoing snetence:
>
> Similar to other DOTS use cases, the offloading scenario assumes that = some
> validation checks are followed by the DMS, the orchestrator, or both (= e.g.,
> avoid exhausting the resources of the forwarding nodes or inadvertent<= br> > disruption of legitimate services).
> </mglt>
>
> > Section 4
> >
> > In light of my previous comment I don't want to go too far he= re, but I
> > could see it being relevant to have a note that in the "orch= estration"
> > case it's possible for something that locally to one telemetr= y system
> > looks like an attack is not actually an attack when seen from the=
> > broader scope (e.g., of the orchestrator).
> >
> > <mglt>
> I added the note in the following paragraph.
>
> These systems are configured so that when an event or some measurement=
> indicators reach a predefined level their associated DOTS client sends= a
> DOTS mitigation request to the orchestrator DOTS server. The DOTS
> mitigation request may be associated with some optional mitigation hin= ts
> to let the orchestrator know what has triggered the request. In partic= ular,
> it's possible for something that locally to one telemetry system l= ooks like
> an attack is not actually an attack when seen from the broader scope (= e.g.,
> of the orchestrator)
> </mglt>
>
> In the Third Party MSP case we mention BGP as a way to steer traffic t= o
> > the mitigation service.=C2=A0 We could consider (but don't ha= ve to)
> > mentioning that efforts to secure BGP will need to be considered = when
> > making pre-arrangements for how traffic is to be moved, since in = some
> > contexts such BGP announcements could themselves be considered to= be an
> > attack.
> >
> > <mglt>
> Being ignorant on BGP, I am wondering if you are thinking of a BGP
> procedure to announce routes or some procedure for enabling a delegati= on
> when BGPsec is considered.

I think either could be problmatic in some (rare?) circumstances -- I
believe in some cases there are allow-lists for which neighbors'
announcements of which prefixes are acted upon, and of course when the RPKI=
comes into play that needs to validate properly as well.

> I porpose the following text:
>
> These exact mechanisms
> used for traffic steering are out of scope of DOTS, but will need to b= e
> pre-arranged, while in some context such changed could be detected and=
> considered as an attack.

I agree with the other commenters that a separate BCP is where the details<= br> should be covered.

> </mglt>
>
> > I guess it probably goes without saying that when you add a third= -party
> > DMS to your setup, you depend on that third party to be operation= al in
> > order for your setup to work properly.
> >
> > Section 7
> >
> > We'll probably get someone asking to move RFC 8612 to be a No= rmative
> > reference since we use it for terminology, but I don't mind l= eaving it
> > be for now.
> >
>
> <mglt>
> I put it as normative.

Thanks,

Ben


--
Daniel Migault
Ericsson
--0000000000003850e905a5b5417c-- From nobody Fri May 15 13:00:31 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 B76033A08B3; Fri, 15 May 2020 13:00:28 -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, FREEMAIL_FROM=0.001, HTML_MESSAGE=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 8v4AvTVHLn6q; Fri, 15 May 2020 13:00:25 -0700 (PDT) Received: from mail-vk1-xa2a.google.com (mail-vk1-xa2a.google.com [IPv6:2607:f8b0:4864:20::a2a]) (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 2AAB13A08B1; Fri, 15 May 2020 13:00:25 -0700 (PDT) Received: by mail-vk1-xa2a.google.com with SMTP id 134so909270vky.2; Fri, 15 May 2020 13:00:25 -0700 (PDT) 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 :cc; bh=NJ4gjRk8lBBzElXKmfrI0ykw66CP2WSyoAH5WUVq13c=; b=P3NS9u6lEUYw+fA9+iHehO0xFOdXucOCoIHJ+uyoxvfiIiTvq7pSPcNbDRtQXI5tWb DSFHSTJjGK33a1Qs18JKJv+nYFKUP+og4MzFOIprhg+VnbMGaEakWaBncfXCL0XVaIgx i4dSsaFi/hadnKl5IHafatiG3nqRFxoNywmXcTXJ/4BW/lEIPCZYfaA2HLsmUT5qtkUh FzvqYdm4ORA7GVwTY1YRyuWZwT/nSIlMuTnpP7hs607rDS+juKVGhYwDqB4WnsIBS0fJ apQm0kuAH5bUAjQvWiQXKyjm2G3hsntQJuO0VFd7ROA+wXQQ1lyP0DSqvHkhAAAVuHeS Z/rw== 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:cc; bh=NJ4gjRk8lBBzElXKmfrI0ykw66CP2WSyoAH5WUVq13c=; b=RQCkihLel95gnFdjZK4HCWQVRxqdLUocAkKQp5f87hVgJJGA+rzraMX60crqzzTcW8 ne2Ca2Fu/xnX8A1uEiK0EIXh9KYILZbZvRty4t5GGf+hgbVAKgEdv0AFHhlSC7V5nwbe kllTfCDhHYW05C1Fr2jy/4kNPIh00Kv9KwJwVkDMybQ1vH3K+8vmv/YkjPY9njTOuElB Ax0s35JLUeOJHrM1UTMOhhZWUNsKUfMXJ27d049FsZcTyTDWUEg+/wg9oRN5Kbixcs+x eKSAelP9iQWmLhzw11IOeVeGXY8ESwccLVWGZ0RYXqXKT9lrfp33dmhZ/YN96hLywyeY uo+w== X-Gm-Message-State: AOAM531pL2xMTCbFBhxbqxeKY9fyCyBEDxYD2Igs7XK6Qm/0fnhywUje 6ucZH84uAoA8Lc2ARnmLCdaZsnC4JPng5DVkur4= X-Google-Smtp-Source: ABdhPJw4kr72n7XOh67DMu2O6sclmQ+L5aB7Lmm10cYhIWkUoqLgdsoH+gjW8X4Mngc6bqmR3wyGEKnIPWLyT6Y5ymo= X-Received: by 2002:a1f:5c16:: with SMTP id q22mr2383181vkb.89.1589572824140; Fri, 15 May 2020 13:00:24 -0700 (PDT) MIME-Version: 1.0 References: <20200512202205.GF27494@kduck.mit.edu> <134501d629c9$a74ec150$f5ec43f0$@jpshallow.com> In-Reply-To: <134501d629c9$a74ec150$f5ec43f0$@jpshallow.com> From: Daniel Migault Date: Fri, 15 May 2020 16:00:13 -0400 Message-ID: To: Jon Shallow Cc: dots , Benjamin Kaduk , "Teague, Francis" , draft-ietf-dots-use-cases.all@ietf.org Content-Type: multipart/alternative; boundary="000000000000870e1d05a5b543b8" Archived-At: Subject: Re: [Dots] AD evaluation of draft-ietf-dots-use-cases-20 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, 15 May 2020 20:00:29 -0000 --000000000000870e1d05a5b543b8 Content-Type: text/plain; charset="UTF-8" Thanks Jon for the comment. I updated the text. Thanks! Yours, Daniel On Thu, May 14, 2020 at 4:28 AM Jon Shallow wrote: > Hi Daniel, > > > > The suggested text needs correcting > > OLD > > in some context such changed could > > NEW > > in some contexts such changes could > > > > Regards > > > > Jon > > > > *From:* Dots [mailto: dots-bounces@ietf.org] *On Behalf Of *Daniel Migault > *Sent:* 14 May 2020 03:24 > *To:* Teague, Francis > *Cc:* draft-ietf-dots-use-cases.all@ietf.org; Benjamin Kaduk; dots > *Subject:* Re: [Dots] AD evaluation of draft-ietf-dots-use-cases-20 > > > > Thanks for the feed back Nick. I sort of understand that the current text > fits your comment, but prefer to double check before publishing the next > version. Feel free to change the text as you wish. > > > > Here is the text in question: > > """ > > These exact mechanisms > used for traffic steering are out of scope of DOTS, but will need to be > pre-arranged, while in some context such changed could be detected and > considered as an attack. > > """ > > > > Yours, > > Daniel > > > > On Wed, May 13, 2020 at 1:06 PM Teague, Francis < > nteague@ironmountain.co.uk> wrote: > > Hi, > > > > Volumetry is awkward - generally an attack is characterized as > volumetric so volume would be correct IMO. > > > > On the BGP side - My 2c - There are methods such as RPKI etc. which > present concerns for BGP based mitigations where implemented, however, > these may be overcome in a number of ways (the mitigator being authorized > to originate prefixes using the customer ASN for example during an > attack). The methods used to overcome these challenges while remaining > compliant with a particular mechanism are really between the requestor and > mitigator to thrash out. I'm not sure we should call it out as its part of > the wider relationship/onboarding process. It's probably a topic for its > own BCP though. > > > > Thanks, > > > > -Nik > > > > On Wed, 13 May 2020 at 17:07, Daniel Migault wrote: > > Hi, > > > > Thank you Ben for you comments. Please find inline how these have been > addressed. The updated version has been pushed to [1]. > > > > The main questions I have for the co-authors are: > > * does the change of volumetry to volume causes any concern ? > > * I guess we could be a little be more specific regarding the delegation > and the pre-arrangement, in particular if BGP is secured. Please update > the text that has been proposed. > > > > Yours, > > Daniel > > > > > > [1] https://github.com/dotswg/dots-use-cases > > > > On Tue, May 12, 2020 at 4:22 PM Benjamin Kaduk wrote: > > Hi all, > > This one is in pretty good shape -- I don't have any major comments on it. > I did write up some editorial nit-level stuff as a github pull request: > https://github.com/dotswg/dots-use-cases/pull/12 . I think that nothing > there should be controversial, but please let me know if I am wrong about > that. > > Please confirm that all six authors made significant contributions: I > will need to defend this to the rest of the IESG, since per RFC 7322 the > author count is generally limited to five individuals. Right now I don't > have a good response when someone asks. > > > > > > As far as I know all authors mentioned significantly contributed to the > document. It is true that there are many co-authors, but I think that > reflected that DOTS needs to coordinate multiple actors that were not so > much coordinated before. > > > > > Section 1 > > As DDoS solutions are broadly heterogeneous among vendors, the > primary goal of DOTS is to provide high-level interaction amongst > differing DDoS solutions, such as detecting, initiating, terminating > DDoS mitigation assistance or requesting the status of a DDoS > mitigation. > > nit: the list structure is not properly parallel. It looks like the > various clauses are meant to be "detecting DDoS", > "initiating/terminating mitigation assistance", and "requesting > mitigation status", so maybe this could become: > > % As DDoS solutions are broadly heterogeneous among vendors, the > % primary goal of DOTS is to provide high-level interaction amongst > % differing DDoS solutions, such as detecting DDoS attacks, > % initiating/terminating DDoS mitigation assistance, or requesting the > % status of a DDoS mitigation. > > > > fixed > > > > Section 3.1 > > Over the course of the attack, the DOTS server of the ITP > periodically informs the DOTS client on the enterprise DMS mitigation > status, statistics related to DDoS attack traffic mitigation, and > related information. Once the DDoS attack has ended, or decreased to > the certain level that the enterprise DMS can handle by itself, the > DOTS server signals the enterprise DMS DOTS client that the attack > has subsided. > > It's interesting that this is worded in such a way that the (ITP) DOTS > server knows the specific threshold for what level of attack traffic the > enterprise DMS can handle, since it's the DOTS server signalling to the > client that "the attack has subsided". > > > > In most cases, if I recall correctly, we expect this to reflect a > contractual relation. That said, it is ultimately the DOTS client that > terminates the mitigation. To remove the impression that the ITP sort of > controls the DOTS client, I propose to change "can handle" by "may > handle". Here is the updated text: > > > > Once the DDoS attack has ended, or decreased to the certain > level that the enterprise DMS may handle by itself, the DOTS server > signals the enterprise DMS DOTS client that the attack has subsided. > > > > > > Section 3.3 > > Upon receipt of the DOTS mitigation request from the DDoS telemetry > system, the orchestrator DOTS server responds with an acknowledgment, > to avoid retransmission of the request for mitigation. The > orchestrator may begin collecting additional fine-grained and > specific information from various DDoS telemetry systems in order to > correlate the measurements and provide an analysis of the event. > Eventually, the orchestrator may ask for additional information from > the DDoS telemetry system; however, the collection of this > information is out of scope. > > The last sentence seems to say that how the orchestrator gets data from > the initial DOTS client telemtry system is out-of-scope, but the > previous sentence talks about the orchestrator collecting information > from (other) DOTS telemetry systems. Is that similarly out of scope? > If so, then the fact that they are specifically *DOTS* telemetry systems > seems irrelevant and we should probably just describe them as generic > telemetry or monitoring systems. > > > > I agree that we should not have DOTS telemetry systems and leave them as > DDoS telemetry systems. I checked the current version and there is no > mention of DOTS telemetry but only DDoS telemetry. > > I also suggest the we specify that such collection is out of scope of > DOTS. with the following sentence: > > > > the collection of this information is out of scope of DOTS. > > > > > > Upon receiving a request to mitigate a DDoS attack performed over a > target, the orchestrator may evaluate the volumetry of the attack as > > nit(?): is "performed over" a conventional usage? I would have expected > something more like "aimed at" given my personal background, but could > just be ignorant of typical usage. > > > > changed. > > > > > Also, I think "volumetry" is not the right word here, and just "volume" > suffices. > > > > I am fine either way. The current version changed to volume, but I am > waiting co-authors to confirm they agree with the change. > > > > > filter the traffic. In this case, the DDoS mitigation system > implements a DOTS client while the orchestrator implements a DOTS > server. Similar to other DOTS use cases, the offloading scenario > assumes that some validation checks are followed by the DMS, the > orchestrator, or both (e.g., avoid exhausting the resources of the > forwarding nodes or disrupting the service). These validation checks > are part of the mitigation, and are therefore out of the scope of the > document. > > I know we added this last chunk of text after a long exchange during the > last WGLC, and understand the desire to avoid going into too many > details on a topic that is mostly out of scope for DOTS. That said, I'd > suggest adding a couple more words around "disrupting the service" > (especially since some level of service disruption during an attack > might be expected!) to help the reader make the link to what kind of > validation is expected, perhaps something like "inadvertent disruption > of legitimate services". > > > > fixed with the follwoing snetence: > > > > Similar to other DOTS use cases, the offloading scenario assumes that some > validation checks are followed by the DMS, the orchestrator, or both (e.g., > avoid exhausting the resources of the forwarding nodes or inadvertent > disruption of legitimate services). > > > > Section 4 > > In light of my previous comment I don't want to go too far here, but I > could see it being relevant to have a note that in the "orchestration" > case it's possible for something that locally to one telemetry system > looks like an attack is not actually an attack when seen from the > broader scope (e.g., of the orchestrator). > > > > I added the note in the following paragraph. > > > > These systems are configured so that when an event or some measurement > indicators reach a predefined level their associated DOTS client sends a > DOTS mitigation request to the orchestrator DOTS server. The DOTS > mitigation request may be associated with some optional mitigation hints > to let the orchestrator know what has triggered the request. In > particular, it's possible for something that locally to one telemetry > system looks like an attack is not actually an attack when seen from the > broader scope (e.g., of the orchestrator) > > > > > > In the Third Party MSP case we mention BGP as a way to steer traffic to > the mitigation service. We could consider (but don't have to) > mentioning that efforts to secure BGP will need to be considered when > making pre-arrangements for how traffic is to be moved, since in some > contexts such BGP announcements could themselves be considered to be an > attack. > > > > Being ignorant on BGP, I am wondering if you are thinking of a BGP > procedure to announce routes or some procedure for enabling a delegation > when BGPsec is considered. > > I porpose the following text: > > > > These exact mechanisms > used for traffic steering are out of scope of DOTS, but will need to be > pre-arranged, while in some context such changed could be detected and > considered as an attack. > > > > I guess it probably goes without saying that when you add a third-party > DMS to your setup, you depend on that third party to be operational in > order for your setup to work properly. > > Section 7 > > We'll probably get someone asking to move RFC 8612 to be a Normative > reference since we use it for terminology, but I don't mind leaving it > be for now. > > > > > > I put it as normative. > > > > > Thanks, > > Ben > > _______________________________________________ > Dots mailing list > Dots@ietf.org > https://www.ietf.org/mailman/listinfo/dots > > > > > -- > > Daniel Migault > > Ericsson > > > The information contained in this email message and its attachments is > intended only for the private and confidential use of the recipient(s) > named above, unless the sender expressly agrees otherwise. Transmission of > email over the Internet is not a secure communications medium. If you are > requesting or have requested the transmittal of personal data, as defined > in applicable privacy laws by means of email or in an attachment to email, > you must select a more secure alternate means of transmittal that supports > your obligations to protect such personal data. > > > > If the reader of this message is not the intended recipient and/or you > have received this email in error, you must take no action based on the > information in this email and you are hereby notified that any > dissemination, misuse or copying or disclosure of this communication is > strictly prohibited. If you have received this communication in error, > please notify us immediately by email and delete the original message. > > > > > -- > > Daniel Migault > > Ericsson > -- Daniel Migault Ericsson --000000000000870e1d05a5b543b8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks Jon for the comment. I updated the text. Thanks!Yours,=C2=A0
Daniel

<= div dir=3D"ltr" class=3D"gmail_attr">On Thu, May 14, 2020 at 4:28 AM Jon Sh= allow <supjps-ietf@jpshallo= w.com> wrote:

Hi Daniel,

=C2=A0

The suggested text needs correcting

=

OLD

in some context such changed could

NEW

in some contexts such ch= anges could

=C2=A0

Regards

= =C2=A0

Jon

=C2=A0

From: Dots [ma= ilto: dots-bounc= es@ietf.org] On Behalf Of Daniel Migault
Sent: 14 May = 2020 03:24
To: Teague, Francis
Cc: draft-ietf-dots-use= -cases.all@ietf.org; Benjamin Kaduk; dots
Subject: Re: [Dots]= AD evaluation of draft-ietf-dots-use-cases-20

=C2=A0

Thanks for the feed back=C2=A0Nick. I sort of understand that the c= urrent text fits your comment, but prefer to double check before publishing= the next version. Feel free to change the text as you wish.=C2=A0

=C2=A0

Here is the text in question:

"""

These exact mechanisms
used for traffic steering are out = of scope of DOTS, but will need to be pre-arranged, while in some context s= uch changed could be detected and considered as an attack.

"""

=C2=A0

Yours,=C2=A0

Daniel

= =C2=A0

On Wed, May 13, 2020 at 1= :06 PM Teague, Francis <nteague@ironmountain.co.uk> wrote:

=

Hi,=

=C2=A0

Volumetry is awkward - generally an attack is characteri= zed as volumetric=C2=A0so volume would be correct IMO.

=C2=A0

On the BGP side - My 2c - There are methods such as RPKI etc= . which present concerns=C2=A0for BGP based mitigations where implemented, = however, these may be overcome=C2=A0in a number of ways (the mitigator bein= g authorized to originate prefixes using the customer ASN for example durin= g an attack).=C2=A0 The methods used to overcome these challenges while rem= aining compliant with a particular mechanism are really between the request= or and mitigator to thrash out.=C2=A0 I'm not sure we should call it ou= t as its part of the wider relationship/onboarding process.=C2=A0 It's = probably a topic for its own BCP though.

=C2=A0

= Thanks,

=C2=A0=

-Nik

=C2=A0

On Wed, 13 May 2020 at 17:07, Daniel Migault <mglt.ietf@gmail.com> wrote:<= /u>

Hi,=C2=A0

=C2=A0=

Thank you Ben for you comments= . Please find inline how these have been addressed. The updated version has= been pushed to [1].=C2=A0

=C2=A0

The main quest= ions I have for the co-authors are:

* does the change of volumetry to volume causes any concern ?

* I guess we could be a l= ittle be more specific regarding the delegation and the pre-arrangement, in= particular if BGP is secured. Please update the=C2=A0text that has been pr= oposed.=C2=A0

=C2= =A0

Yours,=C2=A0<= /p>

Daniel=C2=A0 =C2=A0

<= /div>

=C2=A0

=C2=A0

[1]=C2= =A0h= ttps://github.com/dotswg/dots-use-cases

=C2=A0

On = Tue, May 12, 2020 at 4:22 PM Benjamin Kaduk <kaduk@mit.edu> wrote:

Hi all,

This one is i= n pretty good shape -- I don't have any major comments on it.
I did = write up some editorial nit-level stuff as a github pull request:
ht= tps://github.com/dotswg/dots-use-cases/pull/12 .=C2=A0 I think that not= hing
there should be controversial, but please let me know if I am wrong= about
that.

Please confirm that all six authors made significant= contributions: I
will need to defend this to the rest of the IESG, sinc= e per RFC 7322 the
author count is generally limited to five individuals= .=C2=A0 Right now I don't
have a good response when someone asks.=

=C2=A0

<mglt>

=

As far as I know all authors mentioned signific= antly contributed to the document. It is true that there are many co-author= s, but I think that reflected that DOTS needs to coordinate multiple actors= that were not so much coordinated before.=C2=A0

</mglt>=C2=A0


Sec= tion 1

=C2=A0 =C2=A0As DDoS solutions are broadly heterogeneous amon= g vendors, the
=C2=A0 =C2=A0primary goal of DOTS is to provide high-leve= l interaction amongst
=C2=A0 =C2=A0differing DDoS solutions, such as det= ecting, initiating, terminating
=C2=A0 =C2=A0DDoS mitigation assistance = or requesting the status of a DDoS
=C2=A0 =C2=A0mitigation.

nit: = the list structure is not properly parallel.=C2=A0 It looks like the
var= ious clauses are meant to be "detecting DDoS",
"initiatin= g/terminating mitigation assistance", and "requesting
mitigati= on status", so maybe this could become:

% As DDoS solutions are= broadly heterogeneous among vendors, the
% primary goal of DOTS is to p= rovide high-level interaction amongst
% differing DDoS solutions, such a= s detecting DDoS attacks,
% initiating/terminating DDoS mitigation assis= tance, or requesting the
% status of a DDoS mitigation.

<mglt>

fixed

</mglt>=C2=A0

Section 3.1

=C2=A0 = =C2=A0Over the course of the attack, the DOTS server of the ITP
=C2=A0 = =C2=A0periodically informs the DOTS client on the enterprise DMS mitigation=
=C2=A0 =C2=A0status, statistics related to DDoS attack traffic mitigati= on, and
=C2=A0 =C2=A0related information.=C2=A0 Once the DDoS attack has= ended, or decreased to
=C2=A0 =C2=A0the certain level that the enterpri= se DMS can handle by itself, the
=C2=A0 =C2=A0DOTS server signals the en= terprise DMS DOTS client that the attack
=C2=A0 =C2=A0has subsided.
<= br>It's interesting that this is worded in such a way that the (ITP) DO= TS
server knows the specific threshold for what level of attack traffic = the
enterprise DMS can handle, since it's the DOTS server signalling= to the
client that "the attack has subsided".

<mglt>

In most cases, if I recall correctly, we ex= pect this to reflect a contractual relation. That said, it is ultimately th= e DOTS client that terminates the mitigation. To remove the impression that= the ITP sort of controls the DOTS client, I propose to change "can ha= ndle" by "may handle".=C2=A0 Here is the updated text:

=C2=A0

Once the DDoS attack has ended, or decreased t= o the certain
level that the enterprise DMS may handle by itself, the DO= TS server
signals the enterprise DMS DOTS client that the attack has sub= sided.

</mglt>=C2= =A0

=C2=A0=

Section 3.3

=C2=A0 =C2=A0Upon receipt of the DOTS mitigati= on request from the DDoS telemetry
=C2=A0 =C2=A0system, the orchestrator= DOTS server responds with an acknowledgment,
=C2=A0 =C2=A0to avoid retr= ansmission of the request for mitigation.=C2=A0 The
=C2=A0 =C2=A0orchest= rator may begin collecting additional fine-grained and
=C2=A0 =C2=A0spec= ific information from various DDoS telemetry systems in order to
=C2=A0 = =C2=A0correlate the measurements and provide an analysis of the event.
= =C2=A0 =C2=A0Eventually, the orchestrator may ask for additional informatio= n from
=C2=A0 =C2=A0the DDoS telemetry system; however, the collection o= f this
=C2=A0 =C2=A0information is out of scope.

The last sentenc= e seems to say that how the orchestrator gets data from
the initial DOTS= client telemtry system is out-of-scope, but the
previous sentence talks= about the orchestrator collecting information
from (other) DOTS telemet= ry systems.=C2=A0 Is that similarly out of scope?
If so, then the fact t= hat they are specifically *DOTS* telemetry systems
seems irrelevant and = we should probably just describe them as generic
telemetry or monitoring= systems.

<mgl= t>

I agree that we sh= ould not have DOTS telemetry systems and leave them as DDoS telemetry syste= ms. I checked the current version and there is no mention of DOTS telemetry= but only DDoS telemetry.=C2=A0

I also suggest the we specify that such collection is out of scope = of DOTS. with the following sentence:

=C2=A0

th= e collection of this information is out of scope of DOTS.

=

</mglt>

=C2=A0

=C2=A0 =C2=A0Upon receiving a request to mitigate = a DDoS attack performed over a
=C2=A0 =C2=A0target, the orchestrator may= evaluate the volumetry of the attack as

nit(?): is "performed = over" a conventional usage?=C2=A0 I would have expected
something m= ore like "aimed at" given my personal background, but could
ju= st be ignorant of typical usage.

<mglt>

changed.

</mglt&= gt;=C2=A0


Also, I think "volumetry" is not the right word here, and= just "volume"
suffices.

<mglt>

I am fine either way. The current version changed to volume, but = I am waiting co-authors to confirm they agree with the change.=C2=A0=

</mglt>=C2=A0<= /u>


=C2=A0 =C2=A0filter the traffic.=C2=A0 In this case, the D= DoS mitigation system
=C2=A0 =C2=A0implements a DOTS client while the or= chestrator implements a DOTS
=C2=A0 =C2=A0server.=C2=A0 Similar to other= DOTS use cases, the offloading scenario
=C2=A0 =C2=A0assumes that some = validation checks are followed by the DMS, the
=C2=A0 =C2=A0orchestrator= , or both (e.g., avoid exhausting the resources of the
=C2=A0 =C2=A0forw= arding nodes or disrupting the service).=C2=A0 These validation checks
= =C2=A0 =C2=A0are part of the mitigation, and are therefore out of the scope= of the
=C2=A0 =C2=A0document.

I know we added this last chunk of= text after a long exchange during the
last WGLC, and understand the des= ire to avoid going into too many
details on a topic that is mostly out o= f scope for DOTS.=C2=A0 That said, I'd
suggest adding a couple more = words around "disrupting the service"
(especially since some l= evel of service disruption during an attack
might be expected!) to help = the reader make the link to what kind of
validation is expected, perhaps= something like "inadvertent disruption
of legitimate services"= ;.

<mglt>

fixed with the follwoing = snetence:

=C2=A0<= u>

Similar to other DOTS use cases= , the offloading scenario assumes that some validation checks are followed = by the DMS, the orchestrator, or both (e.g., avoid exhausting the resources= of the forwarding nodes or inadvertent disruption of legitimate services).=

</mglt>=C2=A0<= /u>

Section 4

In light of my previous comment I don&= #39;t want to go too far here, but I
could see it being relevant to have= a note that in the "orchestration"
case it's possible for= something that locally to one telemetry system
looks like an attack is = not actually an attack when seen from the
broader scope (e.g., of the or= chestrator).

<= mglt>

I added the not= e in the following paragraph.=C2=A0

=C2=A0

These= systems are configured so that when an event or some measurement
indica= tors reach a predefined level their associated DOTS client sends a
DOTS = mitigation request to the orchestrator DOTS server. The DOTS
mitigation = request may be associated with some optional mitigation hints
to let the= orchestrator know what has triggered the request. In particular, it's = possible for something that locally to one telemetry system looks like an a= ttack is not actually an attack when seen from the broader scope (e.g., of = the orchestrator)

</m= glt>=C2=A0

=C2= =A0

In the Third Party MSP case we mention BGP as a way to = steer traffic to
the mitigation service.=C2=A0 We could consider (but do= n't have to)
mentioning that efforts to secure BGP will need to be c= onsidered when
making pre-arrangements for how traffic is to be moved, s= ince in some
contexts such BGP announcements could themselves be conside= red to be an
attack.

<mglt>

Bein= g ignorant on BGP, I am wondering if you are thinking of a BGP procedure to= announce=C2=A0routes or some procedure for enabling a delegation when BGPs= ec is considered.=C2=A0

= I porpose=C2=A0the following text:

=C2=A0

These exact mechanisms
used for traffic steering= are out of scope of DOTS, but will need to be pre-arranged, while in some = context such changed could be detected and considered as an attack.<= u>

</mglt>=C2=A0

I guess it probab= ly goes without saying that when you add a third-party
DMS to your setup= , you depend on that third party to be operational in
order for your set= up to work properly.

Section 7

We'll probably get someone= asking to move RFC 8612 to be a Normative
reference since we use it for= terminology, but I don't mind leaving it
be for now.<= /p>

=C2=A0

<= div>

<mglt>

I put it as normative.=C2=A0

</mglt>=C2=A0


Thanks,

Ben

__________= _____________________________________
Dots mailing list
Dots@ietf.org
https://www.ietf.o= rg/mailman/listinfo/dots


=C2=A0

-- <= /p>

Daniel Migault

Ericsson


The information contained= in this email message and its attachments is intended only for the private= and confidential use of the recipient(s) named above, unless the sender ex= pressly agrees otherwise. Transmission of email over the Internet is not a = secure communications medium. If you are requesting or have requested the t= ransmittal of personal data, as defined in applicable privacy laws by means= of email or in an attachment to email, you must select a more secure alter= nate means of transmittal that supports your obligations to protect such pe= rsonal data.=C2=A0

<= /u>=C2=A0

If the reader of this message is not= the intended recipient and/or you have received this email in error, you m= ust take no action based on the information in this email and you are hereb= y notified that any dissemination, misuse or copying or disclosure of this = communication is strictly prohibited. If you have received this communicati= on in error, please notify us immediately by email and delete the original = message.=C2=A0


=C2=A0

--

=

Daniel Migault

Ericsson



--
=
Daniel Mig= ault
Ericsson
--000000000000870e1d05a5b543b8-- From nobody Fri May 15 13:03:52 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 0F29E3A0899; Fri, 15 May 2020 13:03:39 -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.130.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: dots@ietf.org Message-ID: <158957301895.29701.8440784154944173156@ietfa.amsl.com> Date: Fri, 15 May 2020 13:03:39 -0700 Archived-At: Subject: [Dots] I-D Action: draft-ietf-dots-use-cases-21.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, 15 May 2020 20:03:39 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DDoS Open Threat Signaling WG of the IETF. Title : Use cases for DDoS Open Threat Signaling Authors : Roland Dobbins Daniel Migault Robert Moskowitz Nik Teague Liang Xia Kaname Nishizuka Filename : draft-ietf-dots-use-cases-21.txt Pages : 15 Date : 2020-05-15 Abstract: The DDoS Open Threat Signaling (DOTS) effort is intended to provide protocols to facilitate interoperability across disparate DDoS mitigation solutions. This document presents sample use cases which describe the interactions expected between the DOTS components as well as DOTS messaging exchanges. These use cases are meant to identify the interacting DOTS components, how they collaborate, and what are the typical information to be exchanged. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dots-use-cases/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-dots-use-cases-21 https://datatracker.ietf.org/doc/html/draft-ietf-dots-use-cases-21 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dots-use-cases-21 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 May 15 13:05:44 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 3EC003A0923 for ; Fri, 15 May 2020 13:05:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.273 X-Spam-Level: X-Spam-Status: No, score=-2.273 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.173, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-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=ericsson.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xbgq0haDuwRC for ; Fri, 15 May 2020 13:05:31 -0700 (PDT) Received: from NAM12-DM6-obe.outbound.protection.outlook.com (mail-dm6nam12on2079.outbound.protection.outlook.com [40.107.243.79]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E94113A08DE for ; Fri, 15 May 2020 13:05:30 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=TpfUk2fox6vvMMj0M6cXCJXO3LGjHPpVXfnKULlytr4QSSRFZHlH/cSYeZPC90T5XGAm/xr4oWqIKsLjTR2j2xYlA3JKMtPIH7T0EcxwBj/+DE9DNBLpXMJZQ7VPjNRfQrMtfW5yN+FdaLEWJvTr+uJVa7xuYHSEKBnAniX3kKlglwA8U8FAIWGy5nUVpb6gIYrHREr4SRpAArfyonBquLZF0n4x27qtf8AJT9xuk5TC5fay1CNDtFrOQDKO9Tc3RIA4SM2+hf8+d290WteQ096Eapc+pyaRJpA+qhIwfyuPg2DkZgKOUB7xdVhOwLkuC7bzapSMT4uQ4GNNt4LkjA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Vnrsax/N4WUpxtpx/Ipk1em9vZX4uWme6h0oN6RPDoQ=; b=fVIl22Pu1yLUatnUVGPpfvLTuaSuT3XSZ8IKfwIGCeob8gG0MsLmfAWKkk8BVaWzmNapoN9KjGigDNTJu39WfDwE9AykCm/18PvukgE+E9lghP+VAlW8MNeY/i1MkdP6DqKbeNzlTid31GLw8oiuYHsrgfopIrC6Q0SWX6xDub6OxcaYtnERaOp1kLvhigzzZQgv0FxCB8ooSnfys2mYdwQT9qidMXf3Fm88WJjONavk7HwK7+MIpAiqEJW3KpqQoDhLUiWXrXp7sRNf3nf+Zn8qpzyC6753Ir3CpPN/14ZmqZ/u6MiMwSdiqd8u8WrMt+W8dJ1XSTG4OPk+bVEaLA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Vnrsax/N4WUpxtpx/Ipk1em9vZX4uWme6h0oN6RPDoQ=; b=BnkoqKivCNQBjK791v7cTitTo+4kPq8OSJKNa/tr9+E/i0172Odt32qS7PqRavCjO42qDpJslbRNNbJl9TZvkMxZsC70sOxDRYOFoT9i5gLuAYjY5mVzydTGRKGY4cvC1y3JZSIHrRycCRcmb2SRofWRL7r0VB/XepsIAeWbIyA= Received: from SA0PR15MB3791.namprd15.prod.outlook.com (2603:10b6:806:8d::10) by SA0PR15MB3791.namprd15.prod.outlook.com (2603:10b6:806:8d::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3000.25; Fri, 15 May 2020 20:05:29 +0000 Received: from SA0PR15MB3791.namprd15.prod.outlook.com ([fe80::1de5:cb5a:2993:706b]) by SA0PR15MB3791.namprd15.prod.outlook.com ([fe80::1de5:cb5a:2993:706b%5]) with mapi id 15.20.3000.022; Fri, 15 May 2020 20:05:29 +0000 From: Daniel Migault To: "dots@ietf.org" Thread-Topic: New Version Notification for draft-ietf-dots-use-cases-21.txt Thread-Index: AQHWKvPyyxHe8DGgZEWpN2V1AKsq66ipkiRW Date: Fri, 15 May 2020 20:05:29 +0000 Message-ID: References: <158957301931.29701.7665561022279853821@ietfa.amsl.com> In-Reply-To: <158957301931.29701.7665561022279853821@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=ericsson.com; x-originating-ip: [96.22.11.129] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: ca794548-172d-40f1-8989-08d7f90b50e0 x-ms-traffictypediagnostic: SA0PR15MB3791: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 04041A2886 x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 5syhDpgvQcEN+Y1/RuHJB5HXQNlhzkxlQg3vUnmVulnPSusx8/kahE94eIjo/BshiPsi/OBJYS6hKxDOoNhHFOogSd4VPOD1vz3vW8I9msZU1PfXyNvxGTqRvOHr2qOH5SFRebF4YWi8xDW8bt8TbhxwPvMtFWF2iAXzYZ46dNChQlonuMz4u0QmSBgdCPwyTfcXacL4SPobvYCtp5KmQUv987dhGu9cezN2yNidZusNdHHa3PzeTQMoYVD6CjWd+FMwv2dLaEql3b0TBRQ+tkSmoYZWCWx3C+cuJ27uQk3FMg50xUQlHVP7ek6YbB718QVcN5/ffTSyVL54BV2TLk23TfoExHNQO29panIPrtoSvz0YiD1jvP0+8wLKNcoHDjWDNUQ370xKySnpthOQs/Rcn4/pp3uSwjS0TFePHAUcQqyWUuuzqkJ9ttvLN8hlLfzBP7L62fmDUYzgzy2KoTteXl8U9WFD2+LwHb7szHA5wGU0R1hvxgZA4XLM3ZSoAJGm7WEBKKdTXkvpu/+5CQ== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:SA0PR15MB3791.namprd15.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(136003)(39860400002)(346002)(376002)(396003)(366004)(19627405001)(966005)(316002)(2906002)(53546011)(8936002)(52536014)(6506007)(8676002)(7696005)(6916009)(186003)(15650500001)(86362001)(26005)(44832011)(66574014)(166002)(66946007)(71200400001)(5660300002)(76116006)(66446008)(91956017)(64756008)(9686003)(55016002)(33656002)(66556008)(66476007)(478600001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: xVEOXPHDhcIBppqXScBmxPBkCKaKy0o0QHz/dav44b7IwOmgQyjp2z39zR51rwY9mwPyZrnnAWrAIm+ouJ4593HdzrBlvNzZ1pWszdhAIC8J1LDPvkxeXI0JmJHvzNvkeqUzodBLO3be10mBqc0OcFU7uzZ6eKc9WWV8vv88vJ8iC0z613SFI6wMfOy7BG/DLhmJR8hggUTBYJHfQhS0t+fSQcaUCTGLhR5bzukwtcKDxCApN8jtmsldWmS3pm8/b2XhhlJcbekSd9z9MXzskt1U0aVtBO78lKcBs5xAKkA4fia1KOrOJVTS0jhXSSXMeF+bjI5e4mDWa7qzpPnvXDHUf2oD31ieQQo55/TPkBVgkuq34XoR3bRJ2LMOfA+VyZnxtftgA5MrxaGQMrKK0NDU0hEhgTJ/2bWH/CfNUetYpuIdRZupQUXRZmBt0GqqzQVVLZe20sp7u+POGW2EG7dcxKn+6VKMzOFqIX1zlLk= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_SA0PR15MB3791D92F14A1D56E7EEC0813E3BD0SA0PR15MB3791namp_" MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: ca794548-172d-40f1-8989-08d7f90b50e0 X-MS-Exchange-CrossTenant-originalarrivaltime: 15 May 2020 20:05:29.1918 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: jNm7FzIhBIHg0AWxGJEb0FeaBpaiH/JKdYVQ+KIa74ywGOsHSPz6ukwJbqZ3Ro6XPbrclpCoS70qV3D7mu1xHSWzKGUVtkHqs0N51pDi7ss= X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA0PR15MB3791 Archived-At: Subject: [Dots] Fw: New Version Notification for draft-ietf-dots-use-cases-21.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, 15 May 2020 20:05:42 -0000 --_000_SA0PR15MB3791D92F14A1D56E7EEC0813E3BD0SA0PR15MB3791namp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Please find the version 21 that considers all feed backs - or at least my u= nderstanding of them - that we received until now. Thanks for the feed backs! Yours, Daniel ________________________________________ From: internet-drafts@ietf.org Sent: Friday, May 15, 2020 4:03 PM To: Daniel Migault; Robert Moskowitz; Roland Dobbins; Nik Teague; Liang Xia= ; Kaname Nishizuka; Liang Xia; dots-chairs@ietf.org Subject: New Version Notification for draft-ietf-dots-use-cases-21.txt A new version of I-D, draft-ietf-dots-use-cases-21.txt has been successfully submitted by Daniel Migault and posted to the IETF repository. Name: draft-ietf-dots-use-cases Revision: 21 Title: Use cases for DDoS Open Threat Signaling Document date: 2020-05-15 Group: dots Pages: 15 URL: https://www.ietf.org/internet-drafts/draft-ietf-dots-use-ca= ses-21.txt Status: https://datatracker.ietf.org/doc/draft-ietf-dots-use-cases/ Htmlized: https://tools.ietf.org/html/draft-ietf-dots-use-cases-21 Htmlized: https://datatracker.ietf.org/doc/html/draft-ietf-dots-use-c= ases Diff: https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dots-use-cas= es-21 Abstract: The DDoS Open Threat Signaling (DOTS) effort is intended to provide protocols to facilitate interoperability across disparate DDoS mitigation solutions. This document presents sample use cases which describe the interactions expected between the DOTS components as well as DOTS messaging exchanges. These use cases are meant to identify the interacting DOTS components, how they collaborate, and what are the typical information to be exchanged. 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. The IETF Secretariat --_000_SA0PR15MB3791D92F14A1D56E7EEC0813E3BD0SA0PR15MB3791namp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Please find the version 21 that considers all feed backs - or at least my u= nderstanding of them - that we received until now. 

Thanks for the feed backs!

Yours, 
Daniel


________________________________________
From: internet-drafts@ietf.org <internet-drafts@ietf.org>
Sent: Friday, May 15, 2020 4:03 PM
To: Daniel Migault; Robert Moskowitz; Roland Dobbins; Nik Teague; Liang Xia= ; Kaname Nishizuka; Liang Xia; dots-chairs@ietf.org
Subject: New Version Notification for draft-ietf-dots-use-cases-21.txt

A new version of I-D, draft-ietf-dots-use-cases-21.txt
has been successfully submitted by Daniel Migault and posted to the
IETF repository.

Name:           draft-iet= f-dots-use-cases
Revision:       21
Title:          Use cases for = DDoS Open Threat Signaling
Document date:  2020-05-15
Group:          dots
Pages:          15
URL:            https://www.ietf.org/internet-drafts/draft-ietf-dots-use-cases-21.txt Status:         https://datatracker.ietf.org/doc/draft-ietf-dots-use-cases/
Htmlized:       https://tools.ietf.org/html/draft-ietf-dots-use-cases-21
Htmlized:       https://datatracker.ietf.org/doc/html/draft-ietf-dots-use-cases
Diff:           https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dots-use-cases-21

Abstract:
   The DDoS Open Threat Signaling (DOTS) effort is intended to pr= ovide
   protocols to facilitate interoperability across disparate DDoS=
   mitigation solutions.  This document presents sample use = cases which
   describe the interactions expected between the DOTS components= as
   well as DOTS messaging exchanges.  These use cases are me= ant to
   identify the interacting DOTS components, how they collaborate= , and
   what are the typical information to be exchanged.




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.

The IETF Secretariat


--_000_SA0PR15MB3791D92F14A1D56E7EEC0813E3BD0SA0PR15MB3791namp_-- From nobody Mon May 18 00:12:22 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 3B2D53A08FF; Mon, 18 May 2020 00:12:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.196 X-Spam-Level: X-Spam-Status: No, score=-0.196 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=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 oBOEzdnX2i28; Mon, 18 May 2020 00:12:18 -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 517CA3A08FD; Mon, 18 May 2020 00:12:18 -0700 (PDT) Received: from opfednr05.francetelecom.fr (unknown [xx.xx.xx.69]) by opfednr26.francetelecom.fr (ESMTP service) with ESMTP id 49QVZS65xjz10H1; Mon, 18 May 2020 09:12:16 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1589785936; bh=YZvRz/AyMduNqCUNyw6tlrtuutd6G3tLqAzVKMx+boc=; h=From:To:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=RYKwpIxvdGl7qgpVmUU2fbE8YUryMInCz6nd29ftFzbzpVpxJkKMIHZL2BBeLStCB pqyab4iFvYW/PRnoowYRo4S54ycY6/ZIu8hhAxoKBQZxIAV2qFWqlaToEUr4FaVasW 16YPu/8waetnClyHMAnT30V3ULq95i6cRaCPACA9koEyqMvWFc7bLVTCPyVkqE4Vrw QD1di/FnFRGIJDjHuofjf53PYPPHoFkWppZFa7qiGi3u6WEbOkB+oTd5tGqKrRLIfe VMyI58petiVD737JkGqGq3sqyJAbSYBqN47GcQZqi7gk2JLpUMPgwGaUZsKaTvWGBf WdDCtCdl3RpMQ== Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.92]) by opfednr05.francetelecom.fr (ESMTP service) with ESMTP id 49QVZS4yyNzyQG; Mon, 18 May 2020 09:12:16 +0200 (CEST) From: To: Benjamin Kaduk , "draft-ietf-dots-signal-filter-control.all@ietf.org" , "kaduk@mit.edu" CC: "dots@ietf.org" Thread-Topic: AD evaluation of draft-ietf-dots-signal-filter-control-03 Thread-Index: AQHWKMv5PQcY3V6c0EmI3bO/wMNtRKiln6rggAfVbYA= Date: Mon, 18 May 2020 07:12:15 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B9330314BE8AC@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> References: <20200513021222.GY3811@akamai.com> <787AE7BB302AE849A7480A190F8B9330314B9EE0@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> In-Reply-To: <787AE7BB302AE849A7480A190F8B9330314B9EE0@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.114.13.245] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Dots] AD evaluation of draft-ietf-dots-signal-filter-control-03 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, 18 May 2020 07:12:21 -0000 Hi Ben, all,=20 FWIW, a candidate version is available at: https://github.com/boucadair/filter-control/blob/master/draft-ietf-dots-sig= nal-filter-control-04.txt =20 Diff: https://github.com/boucadair/filter-control/blob/master/AD-Review.pdf= =20 Cheer, Med > -----Message d'origine----- > De=A0: mohamed.boucadair@orange.com > [mailto:mohamed.boucadair@orange.com] > Envoy=E9=A0: mercredi 13 mai 2020 12:48 > =C0=A0: Benjamin Kaduk; draft-ietf-dots-signal-filter- > control.all@ietf.org; kaduk@mit.edu > Cc=A0: dots@ietf.org > Objet=A0: RE: AD evaluation of draft-ietf-dots-signal-filter-control-03 >=20 > Hi Ben, >=20 > Thank you for the review. >=20 > Please see inline. >=20 > Cheers, > Med >=20 > > -----Message d'origine----- > > De=A0: Benjamin Kaduk [mailto:bkaduk@akamai.com] > > Envoy=E9=A0: mercredi 13 mai 2020 04:12 > > =C0=A0: draft-ietf-dots-signal-filter-control.all@ietf.org; > kaduk@mit.edu > > Cc=A0: dots@ietf.org > > Objet=A0: AD evaluation of draft-ietf-dots-signal-filter-control-03 > > > > Hi all, > > > > This one is also generally in good shape, with mostly nit-level > > comments. > > (I didn't find it on github, so those are inline.) > > > > I have a nagging suspicion that I'm repeating some comments I made > on > > the core protocol documents (having forgotten the response and thus > > why > > the change in question should not be made; my apologies in advance > for > > my poor memory. > > > > Section 1.1 > > > > The DOTS data channel protocol [I-D.ietf-dots-data-channel] is > used > > for bulk data exchange between DOTS agents to improve the > > coordination of parties involved in the response to the > Distributed > > > > nit: s/the/a/ > > >=20 > [Med] Fixed. Thanks. >=20 > > the inbound link to the DOTS client domain. In other words, the > > DOTS > > client cannot use the DOTS data channel protocol to withdraw the > > accept-list filters when a DDoS attack is in progress. This > > assumes > > that this DOTS client is the owner of the filtering rule. > > > > nit: the last sentence feels a little disconnected from the previous > > discussion at the moment; I'd suggest adding at the end ", since > > otherwise this DOTS client would not be authorized to modify it > > anyway" > > or similar. >=20 > [Med] After rereading, I think we can get rid of it. I deleted that > part of the sentence. >=20 > > > > Section 1.2 > > > > This specification addresses the problems discussed in Section > 1.1 > > by > > adding the capability of managing filtering rules using the DOTS > > signal channel protocol, which enables a DOTS client to request > the > > activation (or deactivation) of filtering rules during a DDoS > > attack. > > > > nit: the grammar here does not quite match up ("capability of" vs. > > "using"); perhaps s/the capability of/a capability for/ (though > other > > fixes are possible). >=20 > [Med] Fixed. >=20 > > > > Sample examples are provided in Section 4, in particular: > > > > nit: "sample examples" feels redundant; maybe "some examples" or > just > > "examples"? > > > > o Section 4.1 illustrates how the filter control extension is > used > > when conflicts with Access Control List (ACLs) are detected > and > > reported by a DOTS server. > > > > nit: s/List/Lists/ >=20 > [Med] Fixed. Thanks. >=20 > > > > Section 3.1 > > > > A filtering rule controlled by the DOTS signal channel is > > identified > > by its ACL name (Section 7.2 of [I-D.ietf-dots-data-channel]). > > Note > > > > The referenced section is just an example; the actual YANG > definition > > is > > in Section 4.3 thereof. >=20 > [Med] pointing to section 4.3 is better. Fixed. >=20 > > > > The activation or deactivation of an ACL by the DOTS signal > channel > > overrides the 'activation-type' (defined in Section 7.2 of > > [I-D.ietf-dots-data-channel]) a priori conveyed with the > filtering > > rules using the DOTS data channel protocol. > > > > Is there a way to "cancel" the signal-channel-made changes and > revert > > to > > the previous activation-type? >=20 > [Med] This is up to the DOTS client to tweak these filtering rules as > a function of the context. For example, > - if a rule was deactivated because of a conflict, the client may > delete that rule > - if the rule was a rate-limit, the client will deactivate the rule. >=20 > I added this NEW text: >=20 > Once the attack is mitigated, the DOTS client may use the data > channel to control the 'activation-type' (e.g., revert to a default > value) of some of the filtering rules controlled by the DOTS signal > channel or delete some of these filters. This behavior is > deployment > specific. >=20 > Do we need to say more? >=20 > Or do we just make the client remember > > the previous status and manually set that status in such a case? > > > > Section 3.2.1 > > > > Why is the acl-name an optional attribute? >=20 > [Med] Because: >=20 > This specification extends the mitigation request defined in > Section 4.4.1 of [I-D.ietf-dots-signal-channel] to convey the > intended control of configured filtering rules. >=20 > A mitigation request does not need to include an acl name to be valid. >=20 > What would the > > interpretation be if it was not provided? >=20 > [Med] This will be a mitigation request as defined in draft-ietf-dots- > signal-channel. >=20 > > > > intended control of configured filtering rules. Concretely, the > > DOTS > > client conveys 'acl-list' attribute with the following sub- > > attributes > > in the CBOR body of a mitigation request (see the YANG-encoded > > structure in Section 3.2.2.1): > > > > nit: YANG is a data description language, not an encoding; perhaps > > "YANG-formatted structure" or just "YANG structure" is better. >=20 > [Med] Changed to "YANG structure". >=20 > > > > As the attack evolves, DOTS clients can adjust the 'activation- > > type' > > of an ACL conveyed in a mitigation request or control other > filters > > as necessary. This can be achieved by sending a PUT request with > a > > new 'mid' value. > > > > This potentially involves a lot of new 'mid' values if many change > are > > made using signal-channel filtering control over the course of a > given > > mitigation. Is this going to cause a noticeable increase in the > > amount > > of state required at the DOTS server? >=20 > [Med] No. Only the request with the highest 'mid' value will be > maintained. >=20 > We can add a reminder if you think this is useful. >=20 > > > > If the DOTS client receives a 5.03 (Service Unavailable) with a > > diagnostic payload indicating a failed ACL update as a response > to > > an > > initial mitigation or a mitigation with adjusted scope, the DOTS > > client MUST immediately send a new request which repeats all the > > parameters as sent in the failed mitigation request but without > > including the ACL attributes. After the expiry of Max-Age > returned > > > > Why does this need to be a MUST-level requirement? What if the > > situation has changed in the interim and the mitigation update is no > > longer needed? >=20 > [Med] These requests are supposed to happen in a short interval and > clients have to immediately place a mitigation request to avoid the > inconvenience of including the ACLs. >=20 > What about the following: >=20 > s/client MUST immediately/client MUST by default immediately >=20 > > > > in the 5.03 (Service Unavailable) response, the DOTS client > retries > > with a new mitigation request (i.e., a new 'mid') that repeats > all > > the parameters as sent in the failed mitigation request. > > > > Perhaps mention "including the ACL update" for clarity? > > >=20 > [Med] Works for me. >=20 > > Section 3.2.2.1 > > > > +--rw acl-list* [acl-name] {control-filtering}? > > > > A question for the YANG doctor, no doubt, but is there a need for a > > feature indicator that gates the entire content of a given module > (as > > opposed to just using module-level granularity to indicate support)? >=20 > [Med] I'm not a YANG doctor, but a feature needs to be defined within > the module itself to mark parts that are conditional. I don't quite > see why a module need to be explicitly taged as optional. This is > actually why it is recommended that if you have a module with a large > set of nodes with an if-feature, to define these nodes in a separate > module. >=20 > > > > Section 3.2.2.2 > > > > namespace > > "urn:ietf:params:xml:ns:yang:ietf-dots-signal-control"; > > prefix signal-control; > > > > Can we think of anything else that might be in scope in the future > for > > which "signal-control" would be ambiguous or a name conflict? >=20 > [Med] What about "dots-control"? >=20 > > > > list acl-list { > > key "acl-name"; > > > > Seeing this reminds me of a shadow of a memory that list keys are > > implicitly mandatory, which seems relevant for an earlier comment. > > >=20 > [Med] If an acl-list is present, then acl-name must be present. > Nevertheless, an acl-list is not a mandatory. >=20 > > [...] > > } > > leaf activation-type { > > type ietf-data:activation-type; > > default "activate-when-mitigating"; > > description > > "Sets the activation type of an ACL."; > > > > This structure seems to bind us to having a single activation-type > > that > > applies lto all of the ACLs in the acl-list; >=20 > [Med] Actually, no. We do have an activation-type value for each acl- > name in the list. >=20 >=20 > furthermore, the global > > structure of where we augment means that we can only have one (acl- > > list, > > activation-type) pair within a given mitigation request. I > *believe* > > that is consistent with the core signal protocol in terms of what's > > expected to be in a single message, but please confirm. > > > > Section 4 > > > > (The section heading should probably get the same treatment of > "Sample > > Examples" as was previously used, and the body text here as well.) >=20 > [Med] Not sure about this one. Can you please clarify? >=20 > > > > Section 4.1 > > > > Host: {host}:{port} > > > > nit(?): the data-channel doc just uses "example.com" for the host > > header > > field; it's not clear that we need to diverge from that style > (applies > > throughout). >=20 > [Med] Good catch. Fixed. Thanks. >=20 > > > > The DOTS client can also decide to send a PUT request to > deactivate > > the "an-accept-list" ACL, if suspect traffic is received from an > > accept-listed source (2001:db8:1234::/48). The structure of that > > PUT > > is the same as the one shown in Figure 5. > > > > [...] > > Uri-Path: "mid=3D124" > > > > Just as a sanity-check: this "mid" of 124 is consistent with the > note > > in > > Section 3.2.1 that adjusting the 'activation-type' "[...] can be > > achieved by sending a PUT request with a new 'mid' value", so the > 124 > > (vs. 123) is intentional and correct. >=20 > [Med] I confirm. >=20 > > > > "ietf-dots-signal-control:acl-list": [ > > { > > "ietf-dots-signal-control:acl-name": "an-accept- > list", > > "ietf-dots-signal-control:activation-type": > > "deactivate" > > } > > ] > > "lifetime": 3600 > > > > Shouldn't there be a comma after the ']'? >=20 > [Med] Yes. Thanks for catching this. >=20 > > (Have the examples been run through a JSON validator?) >=20 > [Med] will double check. >=20 > > > > Section 4.3 > > > > Consider a DOTS client that contacts its DOTS server during > 'idle' > > time to install an accept-list that rate-limits all (or a part > > thereof) traffic to be forwarded to 2001:db8:123::/48 as a last > > resort countermeasure whenever required. It does so by sending, > > for > > > > nit: I could imagine a little confusion as to whether the action > > referenced by "it does so" is the installation of the accept-list > (my > > belief) or the rate-limiting. Perhaps "Installing the accpe-list > can > > be > > done by sending, [...]"? >=20 > [Med] Fixed. >=20 >=20 > > > > example, a PUT request shown in Figure 9. The DOTS server > installs > > > > nit: either "the PUT request shown" or "a PUT request as shown". >=20 > [Med] Fixed. >=20 > > > > "actions": { > > "forwarding": "accept", > > "rate-limit": "20.00" > > > > 20 bytes per second? That seems rather small. >=20 > [Med] Indeed. Will increase the value used in the example. >=20 > > > > For some reason (e.g., the DOTS server, or the mitigator, is > > lacking > > a capability or capacity), the DOTS client is still receiving the > > attack traffic which saturates available links. To soften the > > > > nit: I think s/the attack traffic/attack traffic/ is fine grammar. > > >=20 > [Med] Fixed. >=20 > > Section 5.1 > > > > o Note to the RFC Editor: Please delete (TBA1-TBA2-TBA3) once > the > > CBOR key is assigned from the 1-16383 range. Please update > > Table 1 accordingly. > > > > IIRC the unallocated values in this range include both values with a > > 2-byte encoding and with a 3-byte encoding; do we have a reason to > > prefer one or the other? >=20 > [Med] 2-byte encoding is preferred to keep the message compact. >=20 > Since we're allocating from an "IETF Review" > > range, we get to suggest a value to IANA and it's not immediately > > clear > > to me how much say the DEs have in which value gets used. >=20 > [Med] Updated the table to suggest 52/53/54 values. >=20 > > > > Section 6 > > > > We may get someone asking "this document uses YANG; why aren't you > > using > > the YANG security considerations template?" I guess the signal- > > channel > > doc made it through without any particular note in that regard, so > > maybe > > we'll be safe for this one, too. >=20 > [Med] Agree. We do say explicitly the following in the signal channel: >=20 > =3D > This YANG module is not intended to be used via NETCONF/ > RESTCONF for DOTS server management purposes; such module is out of > the scope of this document. It serves only to provide a data model > and encoding, but not a management data model. > =3D=3D >=20 > > > > I'd consider mentioning that with both signal and data channels > > available for updating ACL activation status, there is potential for > > "skew" wherein an update made in one place is ~immediately > overridden > > by > > another update. Fortunately, there was already some degree of > > asynchronicity/external-changes possible, so clients should already > be > > prepared for this sort of situation and will cope properly by > > polling/OBSERVE notification. >=20 > [Med] Yeah. >=20 > > > > We could also consider saying something about how the restriction to > > only changing activation status over the signal channel (but not > > creating new ACLS entirely) means that if a client hasn't prepared > > adequately prior to an attack, it can get stuck in a bad place. > This, > > of course, is also not really new with this document, but is a > pretty > > relevant consideration for its use. >=20 > [Med] Good point. Added this NEW text: >=20 > This specification does not allow to create new filtering rules, > which is the responsibility of the DOTS data channel. DOTS client > domains should be adequately prepared prior to an attack, e.g., by > creating filters that will be activated on demand when an attack is > detected. >=20 > > > > Similarly, a reminder that bad things happen when a DOTS server > fails > > to > > maintain namespace separation across clients for ACL names could be > in > > order (but is not required). >=20 > [Med] Added this NEW text: >=20 > As a reminder, > DOTS servers must associate filtering rules with the DOTS client > that > created these resources. Failure to ensure such association by a > DOTS server will have severe impact on DOTS client domains. >=20 > > > > A compromised DOTS client can use the filtering control > capability > > to > > exacerbate an ongoing attack. Likewise, such compromised DOTS > > client > > may abstain from reacting to an ACL conflict notification > received > > > > nit: singular/plural mismatch "DOTS client"/"such compromised" (so > > either "such a compromised" or "DOTS clients"). >=20 > [Med] Fixed. Thanks. >=20 > > > > Thanks, > > > > Ben From nobody Mon May 18 01:45:45 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 A9E0B3A09AB; Mon, 18 May 2020 01:45:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[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 FDmaoXJ9d_Ta; Mon, 18 May 2020 01:45:39 -0700 (PDT) Received: from mail.jpshallow.com (mail.jpshallow.com [217.40.240.153]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 263A83A09AA; Mon, 18 May 2020 01:45:38 -0700 (PDT) Received: from mail2.jpshallow.com ([192.168.0.3] helo=N01332) by mail.jpshallow.com with esmtp (Exim 4.92.3) (envelope-from ) id 1jabOx-0001rm-04; Mon, 18 May 2020 09:45:35 +0100 From: "Jon Shallow" To: , , "Benjamin Kaduk" , , References: <20200513021222.GY3811@akamai.com> <787AE7BB302AE849A7480A190F8B9330314B9EE0@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B9330314BE8AC@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> In-Reply-To: <787AE7BB302AE849A7480A190F8B9330314BE8AC@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> Date: Mon, 18 May 2020 09:45:24 +0100 Message-ID: <160d01d62cf0$ac6483d0$052d8b70$@jpshallow.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Content-Language: en-gb Thread-Index: AQGisrOXyhwNK3pQOv6q511TckQ6SgKPiEPMAYHfqICo8+5I4A== Archived-At: Subject: Re: [Dots] AD evaluation of draft-ietf-dots-signal-filter-control-03 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, 18 May 2020 08:45:43 -0000 Hi Med, Old: Installing the accpe-list New: Installing the accept-list There have been some changes for I-D.ietf-dots-data-channel and I-D.ietf-dots-signal-channel into their (new) respective RFCs, but not = all of them. Regards Jon > -----Original Message----- > From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of mohamed.boucadair@orange.com > Sent: 18 May 2020 08:12 > To: Benjamin Kaduk; = draft-ietf-dots-signal-filter-control.all@ietf.org; > kaduk@mit.edu > Cc: dots@ietf.org > Subject: Re: [Dots] AD evaluation of draft-ietf-dots-signal-filter-control-03 >=20 > Hi Ben, all, >=20 > FWIW, a candidate version is available at: > = https://github.com/boucadair/filter-control/blob/master/draft-ietf-dots- > signal-filter-control-04.txt >=20 > Diff: https://github.com/boucadair/filter-control/blob/master/AD- > Review.pdf >=20 > Cheer, > Med >=20 > > -----Message d'origine----- > > De=A0: mohamed.boucadair@orange.com > > [mailto:mohamed.boucadair@orange.com] > > Envoy=E9=A0: mercredi 13 mai 2020 12:48 > > =C0=A0: Benjamin Kaduk; draft-ietf-dots-signal-filter- > > control.all@ietf.org; kaduk@mit.edu > > Cc=A0: dots@ietf.org > > Objet=A0: RE: AD evaluation of = draft-ietf-dots-signal-filter-control-03 > > > > Hi Ben, > > > > Thank you for the review. > > > > Please see inline. > > > > Cheers, > > Med > > > > > -----Message d'origine----- > > > De=A0: Benjamin Kaduk [mailto:bkaduk@akamai.com] > > > Envoy=E9=A0: mercredi 13 mai 2020 04:12 > > > =C0=A0: draft-ietf-dots-signal-filter-control.all@ietf.org; > > kaduk@mit.edu > > > Cc=A0: dots@ietf.org > > > Objet=A0: AD evaluation of = draft-ietf-dots-signal-filter-control-03 > > > > > > Hi all, > > > > > > This one is also generally in good shape, with mostly nit-level > > > comments. > > > (I didn't find it on github, so those are inline.) > > > > > > I have a nagging suspicion that I'm repeating some comments I made > > on > > > the core protocol documents (having forgotten the response and = thus > > > why > > > the change in question should not be made; my apologies in advance > > for > > > my poor memory. > > > > > > Section 1.1 > > > > > > The DOTS data channel protocol [I-D.ietf-dots-data-channel] is > > used > > > for bulk data exchange between DOTS agents to improve the > > > coordination of parties involved in the response to the > > Distributed > > > > > > nit: s/the/a/ > > > > > > > [Med] Fixed. Thanks. > > > > > the inbound link to the DOTS client domain. In other words, = the > > > DOTS > > > client cannot use the DOTS data channel protocol to withdraw = the > > > accept-list filters when a DDoS attack is in progress. This > > > assumes > > > that this DOTS client is the owner of the filtering rule. > > > > > > nit: the last sentence feels a little disconnected from the = previous > > > discussion at the moment; I'd suggest adding at the end ", since > > > otherwise this DOTS client would not be authorized to modify it > > > anyway" > > > or similar. > > > > [Med] After rereading, I think we can get rid of it. I deleted that > > part of the sentence. > > > > > > > > Section 1.2 > > > > > > This specification addresses the problems discussed in Section > > 1.1 > > > by > > > adding the capability of managing filtering rules using the = DOTS > > > signal channel protocol, which enables a DOTS client to request > > the > > > activation (or deactivation) of filtering rules during a DDoS > > > attack. > > > > > > nit: the grammar here does not quite match up ("capability of" vs. > > > "using"); perhaps s/the capability of/a capability for/ (though > > other > > > fixes are possible). > > > > [Med] Fixed. > > > > > > > > Sample examples are provided in Section 4, in particular: > > > > > > nit: "sample examples" feels redundant; maybe "some examples" or > > just > > > "examples"? > > > > > > o Section 4.1 illustrates how the filter control extension is > > used > > > when conflicts with Access Control List (ACLs) are detected > > and > > > reported by a DOTS server. > > > > > > nit: s/List/Lists/ > > > > [Med] Fixed. Thanks. > > > > > > > > Section 3.1 > > > > > > A filtering rule controlled by the DOTS signal channel is > > > identified > > > by its ACL name (Section 7.2 of [I-D.ietf-dots-data-channel]). > > > Note > > > > > > The referenced section is just an example; the actual YANG > > definition > > > is > > > in Section 4.3 thereof. > > > > [Med] pointing to section 4.3 is better. Fixed. > > > > > > > > The activation or deactivation of an ACL by the DOTS signal > > channel > > > overrides the 'activation-type' (defined in Section 7.2 of > > > [I-D.ietf-dots-data-channel]) a priori conveyed with the > > filtering > > > rules using the DOTS data channel protocol. > > > > > > Is there a way to "cancel" the signal-channel-made changes and > > revert > > > to > > > the previous activation-type? > > > > [Med] This is up to the DOTS client to tweak these filtering rules = as > > a function of the context. For example, > > - if a rule was deactivated because of a conflict, the client may > > delete that rule > > - if the rule was a rate-limit, the client will deactivate the rule. > > > > I added this NEW text: > > > > Once the attack is mitigated, the DOTS client may use the data > > channel to control the 'activation-type' (e.g., revert to a = default > > value) of some of the filtering rules controlled by the DOTS = signal > > channel or delete some of these filters. This behavior is > > deployment > > specific. > > > > Do we need to say more? > > > > Or do we just make the client remember > > > the previous status and manually set that status in such a case? > > > > > > Section 3.2.1 > > > > > > Why is the acl-name an optional attribute? > > > > [Med] Because: > > > > This specification extends the mitigation request defined in > > Section 4.4.1 of [I-D.ietf-dots-signal-channel] to convey the > > intended control of configured filtering rules. > > > > A mitigation request does not need to include an acl name to be = valid. > > > > What would the > > > interpretation be if it was not provided? > > > > [Med] This will be a mitigation request as defined in = draft-ietf-dots- > > signal-channel. > > > > > > > > intended control of configured filtering rules. Concretely, = the > > > DOTS > > > client conveys 'acl-list' attribute with the following sub- > > > attributes > > > in the CBOR body of a mitigation request (see the YANG-encoded > > > structure in Section 3.2.2.1): > > > > > > nit: YANG is a data description language, not an encoding; perhaps > > > "YANG-formatted structure" or just "YANG structure" is better. > > > > [Med] Changed to "YANG structure". > > > > > > > > As the attack evolves, DOTS clients can adjust the 'activation- > > > type' > > > of an ACL conveyed in a mitigation request or control other > > filters > > > as necessary. This can be achieved by sending a PUT request = with > > a > > > new 'mid' value. > > > > > > This potentially involves a lot of new 'mid' values if many change > > are > > > made using signal-channel filtering control over the course of a > > given > > > mitigation. Is this going to cause a noticeable increase in the > > > amount > > > of state required at the DOTS server? > > > > [Med] No. Only the request with the highest 'mid' value will be > > maintained. > > > > We can add a reminder if you think this is useful. > > > > > > > > If the DOTS client receives a 5.03 (Service Unavailable) with a > > > diagnostic payload indicating a failed ACL update as a response > > to > > > an > > > initial mitigation or a mitigation with adjusted scope, the = DOTS > > > client MUST immediately send a new request which repeats all = the > > > parameters as sent in the failed mitigation request but without > > > including the ACL attributes. After the expiry of Max-Age > > returned > > > > > > Why does this need to be a MUST-level requirement? What if the > > > situation has changed in the interim and the mitigation update is = no > > > longer needed? > > > > [Med] These requests are supposed to happen in a short interval and > > clients have to immediately place a mitigation request to avoid the > > inconvenience of including the ACLs. > > > > What about the following: > > > > s/client MUST immediately/client MUST by default immediately > > > > > > > > in the 5.03 (Service Unavailable) response, the DOTS client > > retries > > > with a new mitigation request (i.e., a new 'mid') that repeats > > all > > > the parameters as sent in the failed mitigation request. > > > > > > Perhaps mention "including the ACL update" for clarity? > > > > > > > [Med] Works for me. > > > > > Section 3.2.2.1 > > > > > > +--rw acl-list* [acl-name] {control-filtering}? > > > > > > A question for the YANG doctor, no doubt, but is there a need for = a > > > feature indicator that gates the entire content of a given module > > (as > > > opposed to just using module-level granularity to indicate = support)? > > > > [Med] I'm not a YANG doctor, but a feature needs to be defined = within > > the module itself to mark parts that are conditional. I don't quite > > see why a module need to be explicitly taged as optional. This is > > actually why it is recommended that if you have a module with a = large > > set of nodes with an if-feature, to define these nodes in a separate > > module. > > > > > > > > Section 3.2.2.2 > > > > > > namespace > > > "urn:ietf:params:xml:ns:yang:ietf-dots-signal-control"; > > > prefix signal-control; > > > > > > Can we think of anything else that might be in scope in the future > > for > > > which "signal-control" would be ambiguous or a name conflict? > > > > [Med] What about "dots-control"? > > > > > > > > list acl-list { > > > key "acl-name"; > > > > > > Seeing this reminds me of a shadow of a memory that list keys are > > > implicitly mandatory, which seems relevant for an earlier comment. > > > > > > > [Med] If an acl-list is present, then acl-name must be present. > > Nevertheless, an acl-list is not a mandatory. > > > > > [...] > > > } > > > leaf activation-type { > > > type ietf-data:activation-type; > > > default "activate-when-mitigating"; > > > description > > > "Sets the activation type of an ACL."; > > > > > > This structure seems to bind us to having a single activation-type > > > that > > > applies lto all of the ACLs in the acl-list; > > > > [Med] Actually, no. We do have an activation-type value for each = acl- > > name in the list. > > > > > > furthermore, the global > > > structure of where we augment means that we can only have one = (acl- > > > list, > > > activation-type) pair within a given mitigation request. I > > *believe* > > > that is consistent with the core signal protocol in terms of = what's > > > expected to be in a single message, but please confirm. > > > > > > Section 4 > > > > > > (The section heading should probably get the same treatment of > > "Sample > > > Examples" as was previously used, and the body text here as well.) > > > > [Med] Not sure about this one. Can you please clarify? > > > > > > > > Section 4.1 > > > > > > Host: {host}:{port} > > > > > > nit(?): the data-channel doc just uses "example.com" for the host > > > header > > > field; it's not clear that we need to diverge from that style > > (applies > > > throughout). > > > > [Med] Good catch. Fixed. Thanks. > > > > > > > > The DOTS client can also decide to send a PUT request to > > deactivate > > > the "an-accept-list" ACL, if suspect traffic is received from = an > > > accept-listed source (2001:db8:1234::/48). The structure of = that > > > PUT > > > is the same as the one shown in Figure 5. > > > > > > [...] > > > Uri-Path: "mid=3D124" > > > > > > Just as a sanity-check: this "mid" of 124 is consistent with the > > note > > > in > > > Section 3.2.1 that adjusting the 'activation-type' "[...] can be > > > achieved by sending a PUT request with a new 'mid' value", so the > > 124 > > > (vs. 123) is intentional and correct. > > > > [Med] I confirm. > > > > > > > > "ietf-dots-signal-control:acl-list": [ > > > { > > > "ietf-dots-signal-control:acl-name": "an-accept- > > list", > > > "ietf-dots-signal-control:activation-type": > > > "deactivate" > > > } > > > ] > > > "lifetime": 3600 > > > > > > Shouldn't there be a comma after the ']'? > > > > [Med] Yes. Thanks for catching this. > > > > > (Have the examples been run through a JSON validator?) > > > > [Med] will double check. > > > > > > > > Section 4.3 > > > > > > Consider a DOTS client that contacts its DOTS server during > > 'idle' > > > time to install an accept-list that rate-limits all (or a part > > > thereof) traffic to be forwarded to 2001:db8:123::/48 as a last > > > resort countermeasure whenever required. It does so by = sending, > > > for > > > > > > nit: I could imagine a little confusion as to whether the action > > > referenced by "it does so" is the installation of the accept-list > > (my > > > belief) or the rate-limiting. Perhaps "Installing the accpe-list > > can > > > be > > > done by sending, [...]"? > > > > [Med] Fixed. > > > > > > > > > > example, a PUT request shown in Figure 9. The DOTS server > > installs > > > > > > nit: either "the PUT request shown" or "a PUT request as shown". > > > > [Med] Fixed. > > > > > > > > "actions": { > > > "forwarding": "accept", > > > "rate-limit": "20.00" > > > > > > 20 bytes per second? That seems rather small. > > > > [Med] Indeed. Will increase the value used in the example. > > > > > > > > For some reason (e.g., the DOTS server, or the mitigator, is > > > lacking > > > a capability or capacity), the DOTS client is still receiving = the > > > attack traffic which saturates available links. To soften the > > > > > > nit: I think s/the attack traffic/attack traffic/ is fine grammar. > > > > > > > [Med] Fixed. > > > > > Section 5.1 > > > > > > o Note to the RFC Editor: Please delete (TBA1-TBA2-TBA3) once > > the > > > CBOR key is assigned from the 1-16383 range. Please update > > > Table 1 accordingly. > > > > > > IIRC the unallocated values in this range include both values with = a > > > 2-byte encoding and with a 3-byte encoding; do we have a reason to > > > prefer one or the other? > > > > [Med] 2-byte encoding is preferred to keep the message compact. > > > > Since we're allocating from an "IETF Review" > > > range, we get to suggest a value to IANA and it's not immediately > > > clear > > > to me how much say the DEs have in which value gets used. > > > > [Med] Updated the table to suggest 52/53/54 values. > > > > > > > > Section 6 > > > > > > We may get someone asking "this document uses YANG; why aren't you > > > using > > > the YANG security considerations template?" I guess the signal- > > > channel > > > doc made it through without any particular note in that regard, so > > > maybe > > > we'll be safe for this one, too. > > > > [Med] Agree. We do say explicitly the following in the signal = channel: > > > > =3D > > This YANG module is not intended to be used via NETCONF/ > > RESTCONF for DOTS server management purposes; such module is out = of > > the scope of this document. It serves only to provide a data = model > > and encoding, but not a management data model. > > =3D=3D > > > > > > > > I'd consider mentioning that with both signal and data channels > > > available for updating ACL activation status, there is potential = for > > > "skew" wherein an update made in one place is ~immediately > > overridden > > > by > > > another update. Fortunately, there was already some degree of > > > asynchronicity/external-changes possible, so clients should = already > > be > > > prepared for this sort of situation and will cope properly by > > > polling/OBSERVE notification. > > > > [Med] Yeah. > > > > > > > > We could also consider saying something about how the restriction = to > > > only changing activation status over the signal channel (but not > > > creating new ACLS entirely) means that if a client hasn't prepared > > > adequately prior to an attack, it can get stuck in a bad place. > > This, > > > of course, is also not really new with this document, but is a > > pretty > > > relevant consideration for its use. > > > > [Med] Good point. Added this NEW text: > > > > This specification does not allow to create new filtering rules, > > which is the responsibility of the DOTS data channel. DOTS = client > > domains should be adequately prepared prior to an attack, e.g., = by > > creating filters that will be activated on demand when an attack = is > > detected. > > > > > > > > Similarly, a reminder that bad things happen when a DOTS server > > fails > > > to > > > maintain namespace separation across clients for ACL names could = be > > in > > > order (but is not required). > > > > [Med] Added this NEW text: > > > > As a reminder, > > DOTS servers must associate filtering rules with the DOTS client > > that > > created these resources. Failure to ensure such association by a > > DOTS server will have severe impact on DOTS client domains. > > > > > > > > A compromised DOTS client can use the filtering control > > capability > > > to > > > exacerbate an ongoing attack. Likewise, such compromised DOTS > > > client > > > may abstain from reacting to an ACL conflict notification > > received > > > > > > nit: singular/plural mismatch "DOTS client"/"such compromised" (so > > > either "such a compromised" or "DOTS clients"). > > > > [Med] Fixed. Thanks. > > > > > > > > Thanks, > > > > > > Ben >=20 > _______________________________________________ > Dots mailing list > Dots@ietf.org > https://www.ietf.org/mailman/listinfo/dots From nobody Mon May 18 01:59: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 5D3E23A09D7; Mon, 18 May 2020 01:59:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.196 X-Spam-Level: X-Spam-Status: No, score=-0.196 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=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 LXlU5Ll0LCiT; Mon, 18 May 2020 01:59:37 -0700 (PDT) Received: from relais-inet.orange.com (relais-inet.orange.com [80.12.66.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0C6693A09E0; Mon, 18 May 2020 01:59:37 -0700 (PDT) Received: from opfedar00.francetelecom.fr (unknown [xx.xx.xx.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by opfedar23.francetelecom.fr (ESMTP service) with ESMTPS id 49QXyH3mspzBrwj; Mon, 18 May 2020 10:59:35 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1589792375; bh=CdQ/UcuhZbi1wLdl+hMbdNj+UwVbLBvbbD09qN3Tr6Y=; h=From:To:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=CveLg0HDHQdOtCRAvwSVVMa7E2WfmQKCe5zqZ+Yy6QouJXgeg28g43SvDoLg/Dbdf jsVe/OBCG/i5ngI+gNZUlhtFOU3TtfJGPDuHfMGetL2tl1ml5BGbRFZcgLHjPqBkl2 6tfW2uAwIiCzxM5/RAY5xwNBvWL47eo3Jq/VQ6+BFUeNC1Fo3WNdCaMfJD6xFZH+aM phKqb0ZHPaeEtiBEIaI9QIjYZa4cOPUrcweGy6nWzfjctNs0h5qypSvHOXjYpa5TDP xt1VKkBy4YKfyUEtwiFyC5+cpzE+i/ywyPfcmLsRsVCkYK2nEGRHFWcXpcmt1bGWWv J5vG+6PreIAqA== Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.20]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by opfedar00.francetelecom.fr (ESMTP service) with ESMTPS id 49QXyH2QBVzCqjy; Mon, 18 May 2020 10:59:35 +0200 (CEST) From: To: Jon Shallow , "dots@ietf.org" , Benjamin Kaduk , "draft-ietf-dots-signal-filter-control.all@ietf.org" , "bkaduk@akamai.com" Thread-Topic: [Dots] AD evaluation of draft-ietf-dots-signal-filter-control-03 Thread-Index: AQGisrOXyhwNK3pQOv6q511TckQ6SgKPiEPMAYHfqICo8+5I4IAABWuQ Date: Mon, 18 May 2020 08:59:34 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B9330314BEA32@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> References: <20200513021222.GY3811@akamai.com> <787AE7BB302AE849A7480A190F8B9330314B9EE0@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B9330314BE8AC@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <160d01d62cf0$ac6483d0$052d8b70$@jpshallow.com> In-Reply-To: <160d01d62cf0$ac6483d0$052d8b70$@jpshallow.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] AD evaluation of draft-ietf-dots-signal-filter-control-03 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, 18 May 2020 08:59:38 -0000 Hi Jon, Please see inline.=20 Cheers, Med > -----Message d'origine----- > De=A0: Jon Shallow [mailto:supjps-ietf@jpshallow.com] > Envoy=E9=A0: lundi 18 mai 2020 10:45 > =C0=A0: BOUCADAIR Mohamed TGI/OLN; dots@ietf.org; Benjamin Kaduk; draft- > ietf-dots-signal-filter-control.all@ietf.org; bkaduk@akamai.com > Objet=A0: RE: [Dots] AD evaluation of draft-ietf-dots-signal-filter- > control-03 >=20 > Hi Med, >=20 > Old: > Installing the accpe-list > New: > Installing the accept-list >=20 [Med] Fixed. Thanks. > There have been some changes for I-D.ietf-dots-data-channel and > I-D.ietf-dots-signal-channel into their (new) respective RFCs, but not > all > of them. [Med] Only the embedded refs in the YANG module was updated. For the others= , this will be done when the RFCs will be published. =20 >=20 > Regards >=20 > Jon >=20 > > -----Original Message----- > > From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of > mohamed.boucadair@orange.com > > Sent: 18 May 2020 08:12 > > To: Benjamin Kaduk; draft-ietf-dots-signal-filter- > control.all@ietf.org; > > kaduk@mit.edu > > Cc: dots@ietf.org > > Subject: Re: [Dots] AD evaluation of > draft-ietf-dots-signal-filter-control-03 > > > > Hi Ben, all, > > > > FWIW, a candidate version is available at: > > https://github.com/boucadair/filter-control/blob/master/draft-ietf- > dots- > > signal-filter-control-04.txt > > > > Diff: https://github.com/boucadair/filter-control/blob/master/AD- > > Review.pdf > > > > Cheer, > > Med > > From nobody Wed May 27 10:14:11 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 17BB63A0FE2; Wed, 27 May 2020 10:14:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 ugP1k7_Qrxqh; Wed, 27 May 2020 10:14:07 -0700 (PDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D53F53A0FDF; Wed, 27 May 2020 10:14:06 -0700 (PDT) Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 04RHE0p5026267 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 27 May 2020 13:14:03 -0400 Date: Wed, 27 May 2020 10:14:00 -0700 From: Benjamin Kaduk To: mohamed.boucadair@orange.com Cc: Benjamin Kaduk , "draft-ietf-dots-signal-filter-control.all@ietf.org" , "dots@ietf.org" Message-ID: <20200527171400.GA58497@kduck.mit.edu> References: <20200513021222.GY3811@akamai.com> <787AE7BB302AE849A7480A190F8B9330314B9EE0@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <787AE7BB302AE849A7480A190F8B9330314B9EE0@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> User-Agent: Mutt/1.12.1 (2019-06-15) Archived-At: Subject: Re: [Dots] AD evaluation of draft-ietf-dots-signal-filter-control-03 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, 27 May 2020 17:14:09 -0000 Hi Med, Please go ahead and upload the new rev; the changes at https://github.com/boucadair/filter-control/blob/master/AD-Review.pdf look good. A little bit of commentary inline. On Wed, May 13, 2020 at 10:47:56AM +0000, mohamed.boucadair@orange.com wrote: > Hi Ben, > > Thank you for the review. > > Please see inline. > > Cheers, > Med > > > -----Message d'origine----- > > De : Benjamin Kaduk [mailto:bkaduk@akamai.com] > > Envoyé : mercredi 13 mai 2020 04:12 > > À : draft-ietf-dots-signal-filter-control.all@ietf.org; kaduk@mit.edu > > Cc : dots@ietf.org > > Objet : AD evaluation of draft-ietf-dots-signal-filter-control-03 > > > > Hi all, > > > > This one is also generally in good shape, with mostly nit-level > > comments. > > (I didn't find it on github, so those are inline.) > > > > I have a nagging suspicion that I'm repeating some comments I made on > > the core protocol documents (having forgotten the response and thus > > why > > the change in question should not be made; my apologies in advance for > > my poor memory. > > > > Section 1.1 > > > > The DOTS data channel protocol [I-D.ietf-dots-data-channel] is used > > for bulk data exchange between DOTS agents to improve the > > coordination of parties involved in the response to the Distributed > > > > nit: s/the/a/ > > > > [Med] Fixed. Thanks. > > > the inbound link to the DOTS client domain. In other words, the > > DOTS > > client cannot use the DOTS data channel protocol to withdraw the > > accept-list filters when a DDoS attack is in progress. This > > assumes > > that this DOTS client is the owner of the filtering rule. > > > > nit: the last sentence feels a little disconnected from the previous > > discussion at the moment; I'd suggest adding at the end ", since > > otherwise this DOTS client would not be authorized to modify it > > anyway" > > or similar. > > [Med] After rereading, I think we can get rid of it. I deleted that part of the sentence. Good point. The new text in the security considerations covers this point anyway. > > > > Section 1.2 > > > > This specification addresses the problems discussed in Section 1.1 > > by > > adding the capability of managing filtering rules using the DOTS > > signal channel protocol, which enables a DOTS client to request the > > activation (or deactivation) of filtering rules during a DDoS > > attack. > > > > nit: the grammar here does not quite match up ("capability of" vs. > > "using"); perhaps s/the capability of/a capability for/ (though other > > fixes are possible). > > [Med] Fixed. > > > > > Sample examples are provided in Section 4, in particular: > > > > nit: "sample examples" feels redundant; maybe "some examples" or just > > "examples"? > > > > o Section 4.1 illustrates how the filter control extension is used > > when conflicts with Access Control List (ACLs) are detected and > > reported by a DOTS server. > > > > nit: s/List/Lists/ > > [Med] Fixed. Thanks. > > > > > Section 3.1 > > > > A filtering rule controlled by the DOTS signal channel is > > identified > > by its ACL name (Section 7.2 of [I-D.ietf-dots-data-channel]). > > Note > > > > The referenced section is just an example; the actual YANG definition > > is > > in Section 4.3 thereof. > > [Med] pointing to section 4.3 is better. Fixed. > > > > > The activation or deactivation of an ACL by the DOTS signal channel > > overrides the 'activation-type' (defined in Section 7.2 of > > [I-D.ietf-dots-data-channel]) a priori conveyed with the filtering > > rules using the DOTS data channel protocol. > > > > Is there a way to "cancel" the signal-channel-made changes and revert > > to > > the previous activation-type? > > [Med] This is up to the DOTS client to tweak these filtering rules as a function of the context. For example, > - if a rule was deactivated because of a conflict, the client may delete that rule > - if the rule was a rate-limit, the client will deactivate the rule. > > I added this NEW text: > > Once the attack is mitigated, the DOTS client may use the data > channel to control the 'activation-type' (e.g., revert to a default > value) of some of the filtering rules controlled by the DOTS signal > channel or delete some of these filters. This behavior is deployment > specific. > > Do we need to say more? What you added is just right; thanks. (My original mental model was that the signal-filter-control operation was an "override" and thus that the override would be reverted at some point; subsequent discussion has clarified that it's just another mechanism to update the status, and not an override at all. Your text describes this nicely.) > Or do we just make the client remember > > the previous status and manually set that status in such a case? > > > > Section 3.2.1 > > > > Why is the acl-name an optional attribute? > > [Med] Because: > > This specification extends the mitigation request defined in > Section 4.4.1 of [I-D.ietf-dots-signal-channel] to convey the > intended control of configured filtering rules. > > A mitigation request does not need to include an acl name to be valid. > > What would the > > interpretation be if it was not provided? > > [Med] This will be a mitigation request as defined in draft-ietf-dots-signal-channel. I see. Thanks for the new text about "mandatory attribute when 'acl-list' is included". > > > > intended control of configured filtering rules. Concretely, the > > DOTS > > client conveys 'acl-list' attribute with the following sub- > > attributes > > in the CBOR body of a mitigation request (see the YANG-encoded > > structure in Section 3.2.2.1): > > > > nit: YANG is a data description language, not an encoding; perhaps > > "YANG-formatted structure" or just "YANG structure" is better. > > [Med] Changed to "YANG structure". > > > > > As the attack evolves, DOTS clients can adjust the 'activation- > > type' > > of an ACL conveyed in a mitigation request or control other filters > > as necessary. This can be achieved by sending a PUT request with a > > new 'mid' value. > > > > This potentially involves a lot of new 'mid' values if many change are > > made using signal-channel filtering control over the course of a given > > mitigation. Is this going to cause a noticeable increase in the > > amount > > of state required at the DOTS server? > > [Med] No. Only the request with the highest 'mid' value will be maintained. > > We can add a reminder if you think this is useful. I don't think we need a reminder in the document; it's pretty clear in the main signal-channel doc but I hadn't read that recently enough. > > > > If the DOTS client receives a 5.03 (Service Unavailable) with a > > diagnostic payload indicating a failed ACL update as a response to > > an > > initial mitigation or a mitigation with adjusted scope, the DOTS > > client MUST immediately send a new request which repeats all the > > parameters as sent in the failed mitigation request but without > > including the ACL attributes. After the expiry of Max-Age returned > > > > Why does this need to be a MUST-level requirement? What if the > > situation has changed in the interim and the mitigation update is no > > longer needed? > > [Med] These requests are supposed to happen in a short interval and clients have to immediately place a mitigation request to avoid the inconvenience of including the ACLs. > > What about the following: > > s/client MUST immediately/client MUST by default immediately I don't have a particular preference between those versions. Your explanation makes sense to me, so we can probably leave this as-is for now. > > > > in the 5.03 (Service Unavailable) response, the DOTS client retries > > with a new mitigation request (i.e., a new 'mid') that repeats all > > the parameters as sent in the failed mitigation request. > > > > Perhaps mention "including the ACL update" for clarity? > > > > [Med] Works for me. > > > Section 3.2.2.1 > > > > +--rw acl-list* [acl-name] {control-filtering}? > > > > A question for the YANG doctor, no doubt, but is there a need for a > > feature indicator that gates the entire content of a given module (as > > opposed to just using module-level granularity to indicate support)? > > [Med] I'm not a YANG doctor, but a feature needs to be defined within the module itself to mark parts that are conditional. I don't quite see why a module need to be explicitly taged as optional. This is actually why it is recommended that if you have a module with a large set of nodes with an if-feature, to define these nodes in a separate module. I think we are on the same page as to how the YANG features are intended to work. What I'm still not sure about is whether there's anything in ietf-dots-signal-control other than the acl-list (that is to say, whether it makes sense to implement ieft-dots-signal-control but not support the control-filtering feature). > > > > Section 3.2.2.2 > > > > namespace > > "urn:ietf:params:xml:ns:yang:ietf-dots-signal-control"; > > prefix signal-control; > > > > Can we think of anything else that might be in scope in the future for > > which "signal-control" would be ambiguous or a name conflict? > > [Med] What about "dots-control"? Sure. > > > > list acl-list { > > key "acl-name"; > > > > Seeing this reminds me of a shadow of a memory that list keys are > > implicitly mandatory, which seems relevant for an earlier comment. > > > > [Med] If an acl-list is present, then acl-name must be present. Nevertheless, an acl-list is not a mandatory. > > > [...] > > } > > leaf activation-type { > > type ietf-data:activation-type; > > default "activate-when-mitigating"; > > description > > "Sets the activation type of an ACL."; > > > > This structure seems to bind us to having a single activation-type > > that > > applies lto all of the ACLs in the acl-list; > > [Med] Actually, no. We do have an activation-type value for each acl-name in the list. It looks like I misread the scope; sorry! > > furthermore, the global > > structure of where we augment means that we can only have one (acl- > > list, > > activation-type) pair within a given mitigation request. I *believe* > > that is consistent with the core signal protocol in terms of what's > > expected to be in a single message, but please confirm. > > > > Section 4 > > > > (The section heading should probably get the same treatment of "Sample > > Examples" as was previously used, and the body text here as well.) > > [Med] Not sure about this one. Can you please clarify? This referred back to a previous comment: % nit: "sample examples" feels redundant; maybe "some examples" or just % "examples"? > > > > Section 4.1 > > > > Host: {host}:{port} > > > > nit(?): the data-channel doc just uses "example.com" for the host > > header > > field; it's not clear that we need to diverge from that style (applies > > throughout). > > [Med] Good catch. Fixed. Thanks. > > > > > The DOTS client can also decide to send a PUT request to deactivate > > the "an-accept-list" ACL, if suspect traffic is received from an > > accept-listed source (2001:db8:1234::/48). The structure of that > > PUT > > is the same as the one shown in Figure 5. > > > > [...] > > Uri-Path: "mid=124" > > > > Just as a sanity-check: this "mid" of 124 is consistent with the note > > in > > Section 3.2.1 that adjusting the 'activation-type' "[...] can be > > achieved by sending a PUT request with a new 'mid' value", so the 124 > > (vs. 123) is intentional and correct. > > [Med] I confirm. Thanks! > > > > "ietf-dots-signal-control:acl-list": [ > > { > > "ietf-dots-signal-control:acl-name": "an-accept-list", > > "ietf-dots-signal-control:activation-type": > > "deactivate" > > } > > ] > > "lifetime": 3600 > > > > Shouldn't there be a comma after the ']'? > > [Med] Yes. Thanks for catching this. > > > (Have the examples been run through a JSON validator?) > > [Med] will double check. > > > > > Section 4.3 > > > > Consider a DOTS client that contacts its DOTS server during 'idle' > > time to install an accept-list that rate-limits all (or a part > > thereof) traffic to be forwarded to 2001:db8:123::/48 as a last > > resort countermeasure whenever required. It does so by sending, > > for > > > > nit: I could imagine a little confusion as to whether the action > > referenced by "it does so" is the installation of the accept-list (my > > belief) or the rate-limiting. Perhaps "Installing the accpe-list can > > be > > done by sending, [...]"? > > [Med] Fixed. > > > > > > example, a PUT request shown in Figure 9. The DOTS server installs > > > > nit: either "the PUT request shown" or "a PUT request as shown". > > [Med] Fixed. > > > > > "actions": { > > "forwarding": "accept", > > "rate-limit": "20.00" > > > > 20 bytes per second? That seems rather small. > > [Med] Indeed. Will increase the value used in the example. > > > > > For some reason (e.g., the DOTS server, or the mitigator, is > > lacking > > a capability or capacity), the DOTS client is still receiving the > > attack traffic which saturates available links. To soften the > > > > nit: I think s/the attack traffic/attack traffic/ is fine grammar. > > > > [Med] Fixed. > > > Section 5.1 > > > > o Note to the RFC Editor: Please delete (TBA1-TBA2-TBA3) once the > > CBOR key is assigned from the 1-16383 range. Please update > > Table 1 accordingly. > > > > IIRC the unallocated values in this range include both values with a > > 2-byte encoding and with a 3-byte encoding; do we have a reason to > > prefer one or the other? > > [Med] 2-byte encoding is preferred to keep the message compact. > > Since we're allocating from an "IETF Review" > > range, we get to suggest a value to IANA and it's not immediately > > clear > > to me how much say the DEs have in which value gets used. > > [Med] Updated the table to suggest 52/53/54 values. > > > > > Section 6 > > > > We may get someone asking "this document uses YANG; why aren't you > > using > > the YANG security considerations template?" I guess the signal- > > channel > > doc made it through without any particular note in that regard, so > > maybe > > we'll be safe for this one, too. > > [Med] Agree. We do say explicitly the following in the signal channel: > > = > This YANG module is not intended to be used via NETCONF/ > RESTCONF for DOTS server management purposes; such module is out of > the scope of this document. It serves only to provide a data model > and encoding, but not a management data model. > == > > > > > I'd consider mentioning that with both signal and data channels > > available for updating ACL activation status, there is potential for > > "skew" wherein an update made in one place is ~immediately overridden > > by > > another update. Fortunately, there was already some degree of > > asynchronicity/external-changes possible, so clients should already be > > prepared for this sort of situation and will cope properly by > > polling/OBSERVE notification. > > [Med] Yeah. > > > > > We could also consider saying something about how the restriction to > > only changing activation status over the signal channel (but not > > creating new ACLS entirely) means that if a client hasn't prepared > > adequately prior to an attack, it can get stuck in a bad place. This, > > of course, is also not really new with this document, but is a pretty > > relevant consideration for its use. > > [Med] Good point. Added this NEW text: > > This specification does not allow to create new filtering rules, > which is the responsibility of the DOTS data channel. DOTS client > domains should be adequately prepared prior to an attack, e.g., by > creating filters that will be activated on demand when an attack is > detected. > > > > > Similarly, a reminder that bad things happen when a DOTS server fails > > to > > maintain namespace separation across clients for ACL names could be in > > order (but is not required). > > [Med] Added this NEW text: > > As a reminder, > DOTS servers must associate filtering rules with the DOTS client that > created these resources. Failure to ensure such association by a > DOTS server will have severe impact on DOTS client domains. > > > > > A compromised DOTS client can use the filtering control capability > > to > > exacerbate an ongoing attack. Likewise, such compromised DOTS > > client > > may abstain from reacting to an ACL conflict notification received > > > > nit: singular/plural mismatch "DOTS client"/"such compromised" (so > > either "such a compromised" or "DOTS clients"). > > [Med] Fixed. Thanks. Thanks for all these fixes! -Ben From nobody Wed May 27 10:33: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 748813A0F5F; Wed, 27 May 2020 10:33:11 -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: 7.1.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: dots@ietf.org Message-ID: <159060079142.8187.4269211663255478698@ietfa.amsl.com> Date: Wed, 27 May 2020 10:33:11 -0700 Archived-At: Subject: [Dots] I-D Action: draft-ietf-dots-signal-filter-control-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: Wed, 27 May 2020 17:33:12 -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-04.txt Pages : 27 Date : 2020-05-27 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 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-04 https://datatracker.ietf.org/doc/html/draft-ietf-dots-signal-filter-control-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dots-signal-filter-control-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 Wed May 27 10:37:56 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 5EDAF3A0029 for ; Wed, 27 May 2020 10:37:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: X-Spam-Status: No, score=-2.096 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, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=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 QpjrTlrFgxQI for ; Wed, 27 May 2020 10:37:53 -0700 (PDT) Received: from relais-inet.orange.com (relais-inet.orange.com [80.12.70.34]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ABD413A0028 for ; Wed, 27 May 2020 10:37:52 -0700 (PDT) Received: from opfednr02.francetelecom.fr (unknown [xx.xx.xx.66]) by opfednr23.francetelecom.fr (ESMTP service) with ESMTP id 49XJ272wgNz5wRk; Wed, 27 May 2020 19:37:51 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1590601071; bh=2Y6LzpsqwCYyyXLB4IkBMBju1AG5kG2QICMLyH99tAY=; h=From:To:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=EBnHfTg7gkeix4KZzdvFB9WZNsd+xm2KWyV++3zh0hBtQ189REbgyh6gJ8l8rGO+/ t88dWNijj9yzUNLakv8O307F9rrqHVOCNVeDufZQ0STccqsu2+wAwvoTC3BpCWyqWe VBAcvuDa9jc11NJDITZ188a9QoqY8i18axDaqcGGVosOZRbWOZofRmoMo7emCtB90J zGNVYJtU7AUOc1OFpg9NxWRGAw6cVvcBUmPIFf0z40TeWITbse2ZDj9fGXw7H+ALEV E8SL8CnDtOyxmsIlBDM0+nwv32lAzwnujr1obtkeWL7ggLwjo4ZdNydHGkkPt6O5pn ROigzcH49iz8g== Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.45]) by opfednr02.francetelecom.fr (ESMTP service) with ESMTP id 49XJ27237nz8sYK; Wed, 27 May 2020 19:37:51 +0200 (CEST) From: To: "dots@ietf.org" , "Benjamin Kaduk (kaduk@mit.edu)" Thread-Topic: [Dots] I-D Action: draft-ietf-dots-signal-filter-control-04.txt Thread-Index: AQHWNEzq9BgWQv0d1Eylun28+mGHcqi8Mj9A Date: Wed, 27 May 2020 17:37:50 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B9330314C6AF8@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> References: <159060079142.8187.4269211663255478698@ietfa.amsl.com> In-Reply-To: <159060079142.8187.4269211663255478698@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.245] 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-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: Wed, 27 May 2020 17:37:54 -0000 Hi all,=20 This version takes into account the AD review. Many thanks, Ben.=20 Cheers, Med > -----Message d'origine----- > De=A0: Dots [mailto:dots-bounces@ietf.org] De la part de internet- > drafts@ietf.org > Envoy=E9=A0: mercredi 27 mai 2020 19:33 > =C0=A0: i-d-announce@ietf.org > Cc=A0: dots@ietf.org > Objet=A0: [Dots] I-D Action: draft-ietf-dots-signal-filter-control- > 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 : 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-04.txt > Pages : 27 > Date : 2020-05-27 >=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 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-04 > https://datatracker.ietf.org/doc/html/draft-ietf-dots-signal-filter- > control-04 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dots-signal-filter- > control-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 Wed May 27 19:17: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 E61CF3A0A7B for ; Wed, 27 May 2020 19:17:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 aTi8nTP6l8v5 for ; Wed, 27 May 2020 19:17:31 -0700 (PDT) Received: from guri.nttv6.jp (guri.nttv6.jp [115.69.228.140]) by ietfa.amsl.com (Postfix) with ESMTP id AF98F3A053E for ; Wed, 27 May 2020 19:17:31 -0700 (PDT) Received: from z.nttv6.jp (z.nttv6.jp [IPv6:2402:c800:ff06:6::f]) by guri.nttv6.jp (NTTv6MTA) with ESMTP id 633CC25F6C3; Thu, 28 May 2020 11:17:28 +0900 (JST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nttv6.jp; s=20180820; t=1590632248; 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:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=K/IwXWq39mMAsE3bxJtnLuctVfYcX6xgE8c8v001SJM=; b=IqjK8XqSqFvNEEueLUDwly96DSSNsgrJD7kfHOiGC0B6pJ4/3sw8ZefTUTXTKCIqqRQ7Uj WXxASG9cBCIEIb/bunrs5ZPAdfRX7054WM+THoeIduDYc8eZnrliNFb1IR9bnZUBAQ0IdX vgfUyZ41v7PjNCPI/S59FGn6yYDBjj0= Received: from UG023-kaname.local (fujiko.nttv6.jp [IPv6:2402:c800:ff06:136::141]) by z.nttv6.jp (NTTv6MTA) with ESMTP id 4A3217634ED; Thu, 28 May 2020 11:17:28 +0900 (JST) To: mohamed.boucadair@orange.com, "dots@ietf.org" , "Benjamin Kaduk (kaduk@mit.edu)" References: <159060079142.8187.4269211663255478698@ietfa.amsl.com> <787AE7BB302AE849A7480A190F8B9330314C6AF8@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> From: kaname nishizuka Message-ID: <1d4df13e-3f1f-9970-3893-201f81ece8cb@nttv6.jp> Date: Thu, 28 May 2020 11:17:28 +0900 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:68.0) Gecko/20100101 Thunderbird/68.8.1 MIME-Version: 1.0 In-Reply-To: <787AE7BB302AE849A7480A190F8B9330314C6AF8@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Authentication-Results: guri.nttv6.jp; spf=pass smtp.mailfrom=kaname@nttv6.jp Archived-At: Subject: Re: [Dots] I-D Action: draft-ietf-dots-signal-filter-control-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, 28 May 2020 02:17:34 -0000 Hi, Thank you very much, Ben and Med for sorting things out. thanks, Kaname On 2020/05/28 2:37, mohamed.boucadair@orange.com wrote: > Hi all, > > This version takes into account the AD review. > > Many thanks, Ben. > > Cheers, > Med > >> -----Message d'origine----- >> De : Dots [mailto:dots-bounces@ietf.org] De la part de internet- >> drafts@ietf.org >> Envoyé : mercredi 27 mai 2020 19:33 >> À : i-d-announce@ietf.org >> Cc : dots@ietf.org >> Objet : [Dots] I-D Action: draft-ietf-dots-signal-filter-control- >> 04.txt >> >> >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> This draft is a work item of the DDoS Open Threat Signaling WG of the >> IETF. >> >> Title : 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-04.txt >> Pages : 27 >> Date : 2020-05-27 >> >> 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 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-04 >> https://datatracker.ietf.org/doc/html/draft-ietf-dots-signal-filter- >> control-04 >> >> A diff from the previous version is available at: >> https://www.ietf.org/rfcdiff?url2=draft-ietf-dots-signal-filter- >> control-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/ >> >> >> _______________________________________________ >> Dots mailing list >> Dots@ietf.org >> https://www.ietf.org/mailman/listinfo/dots > _______________________________________________ > Dots mailing list > Dots@ietf.org > https://www.ietf.org/mailman/listinfo/dots From nobody Wed May 27 22:44:15 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 CC5013A0AC7 for ; Wed, 27 May 2020 22:44:13 -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, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=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 (1024-bit key) header.d=mcafee.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CJX_-wJme5LF for ; Wed, 27 May 2020 22:44:11 -0700 (PDT) Received: from us-smtp-delivery-140.mimecast.com (us-smtp-delivery-140.mimecast.com [216.205.24.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A722C3A0AC6 for ; Wed, 27 May 2020 22:44:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mcafee.com; s=mimecast20190606; t=1590644650; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=yLD2+v+pXW7woT+b1xYaFeJpaukIg9ppcp+da6n6enA=; b=b+1SwopPpyh5PHkWJFNkUbEQ4AgOORsW6aBAdeb2GcN4lAt7UEjIKpB6ExsrJVtdGTpWmG zv/k+nm81FZ+b2eDXoeGgb7khmY03we5phjfAsA5Ju5ewC7l0MogxRTUQxObyevan8FoLa Ng/E5YPWiK7LXIPHc1/pKeqjjIaYt6w= Received: from NAM11-CO1-obe.outbound.protection.outlook.com (mail-co1nam11lp2176.outbound.protection.outlook.com [104.47.56.176]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-455-7SH2OhkiOJyr9OQ5Fzcfkg-1; Thu, 28 May 2020 01:44:09 -0400 X-MC-Unique: 7SH2OhkiOJyr9OQ5Fzcfkg-1 Received: from CY4PR1601MB1254.namprd16.prod.outlook.com (2603:10b6:903:d4::12) by CY4PR1601MB1206.namprd16.prod.outlook.com (2603:10b6:903:d6::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3045.17; Thu, 28 May 2020 05:44:05 +0000 Received: from CY4PR1601MB1254.namprd16.prod.outlook.com ([fe80::4c91:5cab:ab79:5ec6]) by CY4PR1601MB1254.namprd16.prod.outlook.com ([fe80::4c91:5cab:ab79:5ec6%10]) with mapi id 15.20.3021.029; Thu, 28 May 2020 05:44:05 +0000 From: "Konda, Tirumaleswar Reddy" To: kaname nishizuka , "mohamed.boucadair@orange.com" , "dots@ietf.org" , "Benjamin Kaduk (kaduk@mit.edu)" Thread-Topic: [Dots] I-D Action: draft-ietf-dots-signal-filter-control-04.txt Thread-Index: AQHWNEzta+nrgb2wQ0+R3d+4U4nHyqi8MnsAgACRLwCAADmUQA== Date: Thu, 28 May 2020 05:44:05 +0000 Message-ID: References: <159060079142.8187.4269211663255478698@ietfa.amsl.com> <787AE7BB302AE849A7480A190F8B9330314C6AF8@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <1d4df13e-3f1f-9970-3893-201f81ece8cb@nttv6.jp> In-Reply-To: <1d4df13e-3f1f-9970-3893-201f81ece8cb@nttv6.jp> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-version: 11.5.0.60 dlp-reaction: no-action x-originating-ip: [49.37.202.192] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 90da2893-2bba-4920-31fa-08d802ca2220 x-ms-traffictypediagnostic: CY4PR1601MB1206: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:6790; x-forefront-prvs: 0417A3FFD2 x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: F5ENw4X+JtMlEmVhIywRGHf1zW/G7o5xvRSt3wiJx4qIpJkxHz9WFJAK1XV4wLmnNXfDvUku0Xh7LXNZ8W8DY0pyvmPXCs3c7BF9vaEv75ps9Bxpe/KrUM6BC0pWQDbOiw61u5ac7KQ8v7HeQFiPBJM1CfRjVTZvKuqVTSZrH2A2UDeefaagHZY/+VZkVUPhUeKMA4U3Tik8acbqwl/JfaAcyXqif44B9CaCWZBOb66zAd5eqXgyBDqZgx30SE996euaBRVBTapAJFEkgUnlQ8D7QhiZsP9QXq2e7dwxKWB4lTc3KB/vaQR4IgcQfLI6qH5n4k/1hPQ2sMW4IEeoy9E0Ofp7vWVNZSUf3A7CL4TsFsPErLDkuqbkiX49CyHpcmQvnc0qNMOSlmdkVZggyN2ZOoa8FP24vo0viuJKtbcGEfnTVEHVbgu/SmMMWMu+OKvA9AYKYO639KuDEu3BLsuh+E55pW7Giyf6lNtyiGg= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:CY4PR1601MB1254.namprd16.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(376002)(366004)(346002)(396003)(39860400002)(136003)(32952001)(26005)(186003)(110136005)(52536014)(7696005)(66556008)(66946007)(33656002)(316002)(66476007)(86362001)(66574014)(83380400001)(76116006)(64756008)(66446008)(5660300002)(6506007)(71200400001)(53546011)(8676002)(9686003)(55016002)(8936002)(478600001)(2906002)(966005)(85282002); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: WG1MYfep6348urUtEeStGkyeNymmFNZsevzLzP27QdonwJyJiGrtyLJojE1JpDB7c/kCGqfkUr62BIHd6AiwlSmenvc8ou458TiPxJaLfGz5sJkFH2YJ1/+/6IYkTkFtOb7WjXTzDrNwUUVUcm3N9+Rkw0pAu8U1JHzcT7uUjLvkSFNSpfudN/jaGkDe5kKq3fRK+upxXTBKoGGRRQjAAvOe/jve/SHVUq0Yeg4ySDX4+zCShCJFQjUKyukmbKDHKPoLyHVwnkPAIyGqsTHGpF+0zCSANnm8Ks0g95jphel6WwhWsY6iBooFhIm8pAri0Wi6hVJGaMPxQM1i7yvvZAi/L/moLs9R3Xvz8N1c9ZmGA8AN5DzlVaq2I7UB1JKflIs4xS8Vyrga4KpCqsajPaKQt86qhTHEejFePXo/kGmLKH1NmUMOjsHAAcIaD/n+f+ek3LmerzAR1L0W+/vSVmpkAdqmmelWdSRKrir6oac= x-ms-exchange-transport-forked: True MIME-Version: 1.0 X-OriginatorOrg: mcafee.com X-MS-Exchange-CrossTenant-Network-Message-Id: 90da2893-2bba-4920-31fa-08d802ca2220 X-MS-Exchange-CrossTenant-originalarrivaltime: 28 May 2020 05:44:05.1270 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4943e38c-6dd4-428c-886d-24932bc2d5de X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: i+6wj2EtwmZQieYz1NMpzlERbRxpxl/AiskvScMGmx3yg0TG71s6D0hmYFfR7MtjDK8KshFlBDBPkLZVlXbGwlVEevxceL2jI+JtYcMHUSdNUp3+9+5PoScufrvHmx56 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR1601MB1206 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: mcafee.com Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 Archived-At: Subject: Re: [Dots] I-D Action: draft-ietf-dots-signal-filter-control-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, 28 May 2020 05:44:14 -0000 VXBkYXRlIGxvb2tzIGdvb2QgdG8gbWUuDQoNCi1UaXJ1DQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNz YWdlLS0tLS0NCj4gRnJvbTogRG90cyA8ZG90cy1ib3VuY2VzQGlldGYub3JnPiBPbiBCZWhhbGYg T2Yga2FuYW1lIG5pc2hpenVrYQ0KPiBTZW50OiBUaHVyc2RheSwgTWF5IDI4LCAyMDIwIDc6NDcg QU0NCj4gVG86IG1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb207IGRvdHNAaWV0Zi5vcmc7IEJl bmphbWluIEthZHVrDQo+IChrYWR1a0BtaXQuZWR1KSA8a2FkdWtAbWl0LmVkdT4NCj4gU3ViamVj dDogUmU6IFtEb3RzXSBJLUQgQWN0aW9uOiBkcmFmdC1pZXRmLWRvdHMtc2lnbmFsLWZpbHRlci1j b250cm9sLTA0LnR4dA0KPiANCj4gQ0FVVElPTjogRXh0ZXJuYWwgZW1haWwuIERvIG5vdCBjbGlj ayBsaW5rcyBvciBvcGVuIGF0dGFjaG1lbnRzIHVubGVzcyB5b3UNCj4gcmVjb2duaXplIHRoZSBz ZW5kZXIgYW5kIGtub3cgdGhlIGNvbnRlbnQgaXMgc2FmZS4NCj4gDQo+IEhpLA0KPiANCj4gVGhh bmsgeW91IHZlcnkgbXVjaCwgQmVuIGFuZCBNZWQgZm9yIHNvcnRpbmcgdGhpbmdzIG91dC4NCj4g DQo+IHRoYW5rcywNCj4gS2FuYW1lDQo+IA0KPiBPbiAyMDIwLzA1LzI4IDI6MzcsIG1vaGFtZWQu Ym91Y2FkYWlyQG9yYW5nZS5jb20gd3JvdGU6DQo+ID4gSGkgYWxsLA0KPiA+DQo+ID4gVGhpcyB2 ZXJzaW9uIHRha2VzIGludG8gYWNjb3VudCB0aGUgQUQgcmV2aWV3Lg0KPiA+DQo+ID4gTWFueSB0 aGFua3MsIEJlbi4NCj4gPg0KPiA+IENoZWVycywNCj4gPiBNZWQNCj4gPg0KPiA+PiAtLS0tLU1l c3NhZ2UgZCdvcmlnaW5lLS0tLS0NCj4gPj4gRGXCoDogRG90cyBbbWFpbHRvOmRvdHMtYm91bmNl c0BpZXRmLm9yZ10gRGUgbGEgcGFydCBkZSBpbnRlcm5ldC0NCj4gPj4gZHJhZnRzQGlldGYub3Jn IEVudm95w6nCoDogbWVyY3JlZGkgMjcgbWFpIDIwMjAgMTk6MzMgw4DCoDoNCj4gPj4gaS1kLWFu bm91bmNlQGlldGYub3JnIENjwqA6IGRvdHNAaWV0Zi5vcmcgT2JqZXTCoDogW0RvdHNdIEktRCBB Y3Rpb246DQo+ID4+IGRyYWZ0LWlldGYtZG90cy1zaWduYWwtZmlsdGVyLWNvbnRyb2wtDQo+ID4+ IDA0LnR4dA0KPiA+Pg0KPiA+Pg0KPiA+PiBBIE5ldyBJbnRlcm5ldC1EcmFmdCBpcyBhdmFpbGFi bGUgZnJvbSB0aGUgb24tbGluZSBJbnRlcm5ldC1EcmFmdHMNCj4gPj4gZGlyZWN0b3JpZXMuDQo+ ID4+IFRoaXMgZHJhZnQgaXMgYSB3b3JrIGl0ZW0gb2YgdGhlIEREb1MgT3BlbiBUaHJlYXQgU2ln bmFsaW5nIFdHIG9mIHRoZQ0KPiA+PiBJRVRGLg0KPiA+Pg0KPiA+PiAgICAgICAgICBUaXRsZSAg ICAgICAgICAgOiBDb250cm9sbGluZyBGaWx0ZXJpbmcgUnVsZXMgVXNpbmcNCj4gPj4gRGlzdHJp YnV0ZWQgRGVuaWFsLW9mLVNlcnZpY2UgT3BlbiBUaHJlYXQgU2lnbmFsaW5nIChET1RTKSBTaWdu YWwNCj4gPj4gQ2hhbm5lbA0KPiA+PiAgICAgICAgICBBdXRob3JzICAgICAgICAgOiBLYW5hbWUg TmlzaGl6dWthDQo+ID4+ICAgICAgICAgICAgICAgICAgICAgICAgICAgIE1vaGFtZWQgQm91Y2Fk YWlyDQo+ID4+ICAgICAgICAgICAgICAgICAgICAgICAgICAgIFRpcnVtYWxlc3dhciBSZWRkeQ0K PiA+PiAgICAgICAgICAgICAgICAgICAgICAgICAgICBUYWthaGlrbyBOYWdhdGENCj4gPj4gCUZp bGVuYW1lICAgICAgICA6IGRyYWZ0LWlldGYtZG90cy1zaWduYWwtZmlsdGVyLWNvbnRyb2wtMDQu dHh0DQo+ID4+IAlQYWdlcyAgICAgICAgICAgOiAyNw0KPiA+PiAJRGF0ZSAgICAgICAgICAgIDog MjAyMC0wNS0yNw0KPiA+Pg0KPiA+PiBBYnN0cmFjdDoNCj4gPj4gICAgIFRoaXMgZG9jdW1lbnQg c3BlY2lmaWVzIGFuIGV4dGVuc2lvbiB0byB0aGUgRE9UUyBzaWduYWwgY2hhbm5lbA0KPiA+PiAg ICAgcHJvdG9jb2wgc28gdGhhdCBET1RTIGNsaWVudHMgY2FuIGNvbnRyb2wgdGhlaXIgZmlsdGVy aW5nIHJ1bGVzDQo+ID4+IHdoZW4NCj4gPj4gICAgIGFuIGF0dGFjayBtaXRpZ2F0aW9uIGlzIGFj dGl2ZS4NCj4gPj4NCj4gPj4gICAgIFBhcnRpY3VsYXJseSwgdGhpcyBleHRlbnNpb24gYWxsb3dz IGEgRE9UUyBjbGllbnQgdG8gYWN0aXZhdGUgb3INCj4gPj4gZGUtDQo+ID4+ICAgICBhY3RpdmF0 ZSBleGlzdGluZyBmaWx0ZXJpbmcgcnVsZXMgZHVyaW5nIGEgRERvUyBhdHRhY2suICBUaGUNCj4g Pj4gICAgIGNoYXJhY3Rlcml6YXRpb24gb2YgdGhlc2UgZmlsdGVyaW5nIHJ1bGVzIGlzIHN1cHBv c2VkIHRvIGJlDQo+ID4+IGNvbnZleWVkDQo+ID4+ICAgICBieSBhIERPVFMgY2xpZW50IGR1cmlu ZyBhbiBpZGxlIHRpbWUgYnkgbWVhbnMgb2YgdGhlIERPVFMgZGF0YQ0KPiA+PiAgICAgY2hhbm5l bCBwcm90b2NvbC4NCj4gPj4NCj4gPj4gRWRpdG9yaWFsIE5vdGUgKFRvIGJlIHJlbW92ZWQgYnkg UkZDIEVkaXRvcikNCj4gPj4NCj4gPj4gICAgIFBsZWFzZSB1cGRhdGUgdGhlc2Ugc3RhdGVtZW50 cyB3aXRoaW4gdGhlIGRvY3VtZW50IHdpdGggdGhlIFJGQw0KPiA+PiAgICAgbnVtYmVyIHRvIGJl IGFzc2lnbmVkIHRvIHRoaXMgZG9jdW1lbnQ6DQo+ID4+DQo+ID4+ICAgICBvICAiVGhpcyB2ZXJz aW9uIG9mIHRoaXMgWUFORyBtb2R1bGUgaXMgcGFydCBvZiBSRkMgWFhYWDsiDQo+ID4+DQo+ID4+ ICAgICBvICAiUkZDIFhYWFg6IENvbnRyb2xsaW5nIEZpbHRlcmluZyBSdWxlcyBVc2luZyBEaXN0 cmlidXRlZCBEZW5pYWwtDQo+ID4+ICAgICAgICBvZi1TZXJ2aWNlIE9wZW4gVGhyZWF0IFNpZ25h bGluZyAoRE9UUykgU2lnbmFsIENoYW5uZWwiOw0KPiA+Pg0KPiA+PiAgICAgbyAgcmVmZXJlbmNl OiBSRkMgWFhYWA0KPiA+Pg0KPiA+PiAgICAgbyAgW1JGQ1hYWFhdDQo+ID4+DQo+ID4+ICAgICBQ bGVhc2UgdXBkYXRlIHRoZSAicmV2aXNpb24iIGRhdGUgb2YgdGhlIFlBTkcgbW9kdWxlLg0KPiA+ Pg0KPiA+Pg0KPiA+PiBUaGUgSUVURiBkYXRhdHJhY2tlciBzdGF0dXMgcGFnZSBmb3IgdGhpcyBk cmFmdCBpczoNCj4gPj4gaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0 Zi1kb3RzLXNpZ25hbC1maWx0ZXItDQo+ID4+IGNvbnRyb2wvDQo+ID4+DQo+ID4+IFRoZXJlIGFy ZSBhbHNvIGh0bWxpemVkIHZlcnNpb25zIGF2YWlsYWJsZSBhdDoNCj4gPj4gaHR0cHM6Ly90b29s cy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtZG90cy1zaWduYWwtZmlsdGVyLWNvbnRyb2wtMDQN Cj4gPj4gaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvaHRtbC9kcmFmdC1pZXRmLWRv dHMtc2lnbmFsLWZpbHRlci0NCj4gPj4gY29udHJvbC0wNA0KPiA+Pg0KPiA+PiBBIGRpZmYgZnJv bSB0aGUgcHJldmlvdXMgdmVyc2lvbiBpcyBhdmFpbGFibGUgYXQ6DQo+ID4+IGh0dHBzOi8vd3d3 LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1pZXRmLWRvdHMtc2lnbmFsLWZpbHRlci0NCj4g Pj4gY29udHJvbC0wNA0KPiA+Pg0KPiA+Pg0KPiA+PiBQbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0 YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBvZg0KPiA+PiBzdWJtaXNzaW9u DQo+ID4+IHVudGlsIHRoZSBodG1saXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFibGUg YXQgdG9vbHMuaWV0Zi5vcmcuDQo+ID4+DQo+ID4+IEludGVybmV0LURyYWZ0cyBhcmUgYWxzbyBh dmFpbGFibGUgYnkgYW5vbnltb3VzIEZUUCBhdDoNCj4gPj4gZnRwOi8vZnRwLmlldGYub3JnL2lu dGVybmV0LWRyYWZ0cy8NCj4gPj4NCj4gPj4NCj4gPj4gX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18NCj4gPj4gRG90cyBtYWlsaW5nIGxpc3QNCj4gPj4gRG90 c0BpZXRmLm9yZw0KPiA+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2Rv dHMNCj4gPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K PiA+IERvdHMgbWFpbGluZyBsaXN0DQo+ID4gRG90c0BpZXRmLm9yZw0KPiA+IGh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZG90cw0KPiANCj4gX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gRG90cyBtYWlsaW5nIGxpc3QNCj4gRG90 c0BpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RvdHMN Cg0K From nobody Thu May 28 13:55:04 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 C356A3A0E72; Thu, 28 May 2020 13:55:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CO1FjuwJk80d; Thu, 28 May 2020 13:55:01 -0700 (PDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 33B963A0E71; Thu, 28 May 2020 13:55:00 -0700 (PDT) Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 04SKsuoT021886 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 28 May 2020 16:54:59 -0400 Date: Thu, 28 May 2020 13:54:55 -0700 From: Benjamin Kaduk To: Daniel Migault Cc: "dots@ietf.org" Message-ID: <20200528205455.GI58497@kduck.mit.edu> References: <158957301931.29701.7665561022279853821@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.12.1 (2019-06-15) Archived-At: Subject: Re: [Dots] Fw: New Version Notification for draft-ietf-dots-use-cases-21.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, 28 May 2020 20:55:03 -0000 On Fri, May 15, 2020 at 08:05:29PM +0000, Daniel Migault wrote: > Please find the version 21 that considers all feed backs - or at least my understanding of them - that we received until now. Thanks for the updates; I'll go ahead and kick off the IETF LC. It does look like one of my editorial comments was not understood as I intended, but we can treat that as we would a LC comment: Section 1 As DDoS solutions are broadly heterogeneous among vendors, the primary goal of DOTS is to provide high-level interaction amongst differing DDoS solutions, such as detecting, initiating, terminating DDoS mitigation assistance or requesting the status of a DDoS mitigation. nit: the list structure is not properly parallel. It looks like the various clauses are meant to be "detecting DDoS", "initiating/terminating mitigation assistance", and "requesting mitigation status", so maybe this could become: % As DDoS solutions are broadly heterogeneous among vendors, the % primary goal of DOTS is to provide high-level interaction amongst % differing DDoS solutions, such as detecting DDoS attacks, % initiating/terminating DDoS mitigation assistance, or requesting the % status of a DDoS mitigation. The -21 adds the '/' in "initiating/terminating DDoS mitigation assistance" but there were a few other changes in my proposal that are needed to make the list structure parallel. E.g., the full phrase "detecting DDoS attacks" and the serial comma. Thanks, Ben From nobody Thu May 28 14:00:32 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 CFA933A0BA3; Thu, 28 May 2020 14:00:26 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 7.1.0 Auto-Submitted: auto-generated Precedence: bulk CC: draft-ietf-dots-use-cases@ietf.org, dots-chairs@ietf.org, valery@smyslov.net, kaduk@mit.edu, dots@ietf.org, Valery Smyslov Reply-To: last-call@ietf.org Sender: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-ID: <159069962676.9175.4321849187713348659@ietfa.amsl.com> Date: Thu, 28 May 2020 14:00:26 -0700 Archived-At: Subject: [Dots] Last Call: (Use cases for DDoS Open Threat Signaling) to Informational RFC 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, 28 May 2020 21:00:27 -0000 The IESG has received a request from the DDoS Open Threat Signaling WG (dots) to consider the following document: - 'Use cases for DDoS Open Threat Signaling' as Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the last-call@ietf.org mailing lists by 2020-06-11. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract The DDoS Open Threat Signaling (DOTS) effort is intended to provide protocols to facilitate interoperability across disparate DDoS mitigation solutions. This document presents sample use cases which describe the interactions expected between the DOTS components as well as DOTS messaging exchanges. These use cases are meant to identify the interacting DOTS components, how they collaborate, and what are the typical information to be exchanged. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-dots-use-cases/ No IPR declarations have been submitted directly on this I-D. From nobody Fri May 29 05:42:56 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 8703D3A07E6 for ; Fri, 29 May 2020 05:42:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: X-Spam-Status: No, score=-2.096 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, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=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 6YsMHNd7vJSl for ; Fri, 29 May 2020 05:42:54 -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 011D93A07E5 for ; Fri, 29 May 2020 05:42:53 -0700 (PDT) Received: from opfedar00.francetelecom.fr (unknown [xx.xx.xx.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by opfedar26.francetelecom.fr (ESMTP service) with ESMTPS id 49YPNr27nNzFppR; Fri, 29 May 2020 14:42:52 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1590756172; bh=mhYbYH7/J2GeCBu0gJLF/Kfw8HAyyR4I6/K+7LTjffc=; h=From:To:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=VylR6O6xWURNEOF+agU+8V9QeZh/LCxhblYjTzgEXmqeJIfJW221RPlzcAbIuP69j vsSUkdIx2jEKIZ4UjoPZTqwoS/2IQjwwgJw0Oj7NuZmogCg0BmIvgka7SQq0LqHWFj D7e0ynhfRfD+nUpjwHTDi3y0AldDSMXp1i3z0sxVVoEGpy0mu3ZtyygfCnlqie06UI V0VMGW67Hk8FXAPz7fU3zQEdwMv31AJX/V4deDCFTO93P9BNS/SJA03XhScAf85V7H mFpiuJWFuaNpraNCkwu1A8+IZIFqZ8ylbA/2GYJhyaTNP8CEFgowFTzmM4cXnjeSyz q7fR4CBIlmmgg== Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.104]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by opfedar00.francetelecom.fr (ESMTP service) with ESMTPS id 49YPNr0YzyzCqjh; Fri, 29 May 2020 14:42:52 +0200 (CEST) From: To: "Daniel Migault (daniel.migault@ericsson.com)" CC: "dots@ietf.org" , Benjamin Kaduk Thread-Topic: [Dots] Fw: New Version Notification for draft-ietf-dots-use-cases-21.txt Thread-Index: AQHWNTJI/aDZ5ZfXyE2CTZOVjsxzcKi+9/Zw Date: Fri, 29 May 2020 12:42:51 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B9330314D4830@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> References: <158957301931.29701.7665561022279853821@ietfa.amsl.com> <20200528205455.GI58497@kduck.mit.edu> In-Reply-To: <20200528205455.GI58497@kduck.mit.edu> 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: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Dots] Fw: New Version Notification for draft-ietf-dots-use-cases-21.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, 29 May 2020 12:42:56 -0000 Hi Daniel, all, Apologies for the late comment, but can you please make the following chang= e in the next iteration of the draft:=20 OLD:=20 This document provides sample use cases that provided input for the design of the DOTS protocols. NEW: This document provides sample use cases that provided input for the design of the DOTS protocols [RFC8772][RFC8773]. Thank you.=20 Cheers, Med > -----Message d'origine----- > De=A0: Dots [mailto:dots-bounces@ietf.org] De la part de Benjamin Kaduk > Envoy=E9=A0: jeudi 28 mai 2020 22:55 > =C0=A0: Daniel Migault > Cc=A0: dots@ietf.org > Objet=A0: Re: [Dots] Fw: New Version Notification for draft-ietf-dots- > use-cases-21.txt >=20 > On Fri, May 15, 2020 at 08:05:29PM +0000, Daniel Migault wrote: > > Please find the version 21 that considers all feed backs - or at > least my understanding of them - that we received until now. >=20 > Thanks for the updates; I'll go ahead and kick off the IETF LC. >=20 > It does look like one of my editorial comments was not understood as I > intended, but we can treat that as we would a LC comment: >=20 >=20 > Section 1 >=20 > As DDoS solutions are broadly heterogeneous among vendors, the > primary goal of DOTS is to provide high-level interaction amongst > differing DDoS solutions, such as detecting, initiating, > terminating > DDoS mitigation assistance or requesting the status of a DDoS > mitigation. >=20 > nit: the list structure is not properly parallel. It looks like the > various clauses are meant to be "detecting DDoS", > "initiating/terminating mitigation assistance", and "requesting > mitigation status", so maybe this could become: >=20 > % As DDoS solutions are broadly heterogeneous among vendors, the > % primary goal of DOTS is to provide high-level interaction amongst > % differing DDoS solutions, such as detecting DDoS attacks, > % initiating/terminating DDoS mitigation assistance, or requesting the > % status of a DDoS mitigation. >=20 > The -21 adds the '/' in "initiating/terminating DDoS mitigation > assistance" > but there were a few other changes in my proposal that are needed to > make > the list structure parallel. E.g., the full phrase "detecting DDoS > attacks" and the serial comma. >=20 > Thanks, >=20 > Ben >=20 > _______________________________________________ > Dots mailing list > Dots@ietf.org > https://www.ietf.org/mailman/listinfo/dots From nobody Fri May 29 06:13:09 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 4E7863A083B for ; Fri, 29 May 2020 06:13:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.095 X-Spam-Level: X-Spam-Status: No, score=-2.095 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, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=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 4Ax7F6v2u6rH for ; Fri, 29 May 2020 06:13:07 -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 ABF603A0838 for ; Fri, 29 May 2020 06:13:06 -0700 (PDT) Received: from opfedar01.francetelecom.fr (unknown [xx.xx.xx.2]) by opfedar26.francetelecom.fr (ESMTP service) with ESMTP id 49YQ3j19qtzFqFQ; Fri, 29 May 2020 15:13:05 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1590757985; bh=JeZyiWl6ucbUa+cAEIFAEB6oy/zy2qn0iJ0h57shT4A=; h=From:To:Subject:Date:Message-ID:Content-Type:MIME-Version; b=gq1KWFT1To4nZOvorn1ZsFdVcRtDwpVuZuXOJiJXVFV6W3M4/UmCIENFX/ZP+fo7t bQQM3kZHauZgvPGcTwlAGaRb2T3rBdNXNw/UUt9Lz4isgPIN+JnTrjHphgmK1vloi+ L+hWrlE1E+/VWZZ1V5Chn1dtEpig36f+OUU5SUR0QEYJKw+NPQNF10F+cnYG3C3j1Q kg/cslhGfv9gF/7jbb+zuvWSjKMyv8+syY3sPE48cl+/x5exms7WvrzPlGgrbQ0mCL 5iuMSRDPTukHrA3iGgnB5bFM/6Z7zDj/PbSXJhi/kgNmpVO4JJQe9Ltf8iQjVKYADS DJhk99R2ULSnQ== Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.29]) by opfedar01.francetelecom.fr (ESMTP service) with ESMTP id 49YQ3j07cKzBrLT; Fri, 29 May 2020 15:13:05 +0200 (CEST) From: To: "dots@ietf.org" CC: "Jon Shallow (supjps-ietf@jpshallow.com)" Thread-Topic: [core] Large asynchronous notifications under DDoS: New BLOCK Option? Thread-Index: AQHWNbriZqhi8cEsakucaMkYG0gq7A== Date: Fri, 29 May 2020 13:13:03 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B9330314D48B4@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> References: <787AE7BB302AE849A7480A190F8B933031490173@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> In-Reply-To: <787AE7BB302AE849A7480A190F8B933031490173@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.114.13.245] Content-Type: multipart/alternative; boundary="_000_787AE7BB302AE849A7480A190F8B9330314D48B4OPEXCAUBMA2corp_" MIME-Version: 1.0 Archived-At: Subject: Re: [Dots] [core] Large asynchronous notifications under DDoS: New BLOCK 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: Fri, 29 May 2020 13:13:08 -0000 --_000_787AE7BB302AE849A7480A190F8B9330314D48B4OPEXCAUBMA2corp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi all, Please find below an update about this DOTS telemetry issue: =B7 A proposal to handle the issue was made: https://tools.ietf.org= /html/draft-bosh-core-new-block-00. =B7 The core wg dedicated an interim meeting to discuss the proposa= l (May, 13). o The slides presented in the meeting ca be seen here: https://datatracke= r.ietf.org/meeting/interim-2020-core-04/materials/slides-interim-2020-core-= 04-sessa-new-coap-block-wise-transfer-options-draft-bosh-core-new-block. o The minutes can be seen at: https://datatracker.ietf.org/doc/minutes-in= terim-2020-core-04-202005131600/. =B7 An updated version to address the comments received from the co= re wg (and especially during the interim) is available at: https://tools.ie= tf.org/html/draft-bosh-core-new-block-01. =B7 The current plan is to avoid adding a normative dependency to t= he telemetry spec. We will report back to the WG as appropriate. Cheers, Jon & Med De : core [mailto:core-bounces@ietf.org] De la part de mohamed.boucadair@or= ange.com Envoy=E9 : mardi 7 avril 2020 13:11 =C0 : core@ietf.org Cc : Jon Shallow (supjps-ietf@jpshallow.com); dots@ietf.org Objet : [core] Large asynchronous notifications under DDoS: New BLOCK Optio= n? Hi all, We are using Observe to receive notifications during attack events. These n= otifications are set as NON messages for reasons specific to DDoS condition= s. With DDoS telemetry information included (see draft-ietf-dots-telemetry), a= notification may not fit one single message. The use of BLOCK2 is not conv= enient during attack times. A full description of the issue is described he= re: https://mailarchive.ietf.org/arch/msg/dots/Gbtf8bBWpxD9CWNBhS_TZtsWeP4/ We are considering some mechanisms to solve this issue. One of them is to d= efine a new BLOCK option (similar to BLOCK2) that does not require the obse= rver to send a GET to receive the next fragment. The server will send all t= he fragments. The observer will follow a SACK-like approach to request retr= ansmission of missing fragments. Please let us know whether you think this is a generic issue that should be= solved at the CoAP or not. Suggestions are welcome. Thank you. Cheers, Jon & Med --_000_787AE7BB302AE849A7480A190F8B9330314D48B4OPEXCAUBMA2corp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi all,

 

Please find below an update about this DOTS= telemetry issue:

 

=B7         A proposal to handle the issue was = made: https:= //tools.ietf.org/html/draft-bosh-core-new-block-00.

=B7         The core wg dedicated an interim me= eting to discuss the proposal (May, 13).

o   The slides presented in the meeting= ca be seen here: https://datatracker.ietf.org/meeting/interim-2020-core-04/materials/slides-= interim-2020-core-04-sessa-new-coap-block-wise-transfer-options-draft-bosh-= core-new-block.

o   The minutes can be seen at: https://datatracker.ietf.org/doc/minutes-interim-2020-core-04-202005131600/= .   

=B7         An updated version to address the c= omments received from the core wg (and especially during the interim) is av= ailable at: https:= //tools.ietf.org/html/draft-bosh-core-new-block-01.

=B7         The current plan is to avoid adding= a normative dependency to the telemetry spec.

 

We will report back to the WG as appropriat= e.

 

Cheers,

Jon & Med

 

De : core= [mailto:core-bounces@ietf.org] De la part de mohamed.boucadair@orange.com
Envoy=E9 : mardi 7 avril 2020 13= :11
=C0 : core@ietf.org
Cc : Jon Shallow (supjps-ietf@jpshallow.com); dots@ietf.org
Objet : [core] Large asynchronous notifications under DDoS: New= BLOCK Option?

 

Hi all,

 

We are using Observe to receive notifications during atta= ck events. These notifications are set as NON messages for reasons specific= to DDoS conditions.

 

With DDoS telemetry information included (see draft-ietf-= dots-telemetry), a notification may not fit one single message. The use of = BLOCK2 is not convenient during attack times. A full description of the issue is described here: https://mailarchive.ietf.org/arch/msg/dots/Gbtf8bBWpxD9CWNBhS_TZtsWeP4/  

We are considering some mechanisms to solve this issue. O= ne of them is to define a new BLOCK option (similar to BLOCK2) that does no= t require the observer to send a GET to receive the next fragment. The server will send all the fragments. The observer will follow= a SACK-like approach to request retransmission of missing fragments.

 

Please let us know whether you think this is a generic is= sue that should be solved at the CoAP or not. Suggestions are welcome.=

 

Thank you.

 

Cheers,

Jon & Med

--_000_787AE7BB302AE849A7480A190F8B9330314D48B4OPEXCAUBMA2corp_-- From nobody Fri May 29 06:22:33 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 C1B563A0850; Fri, 29 May 2020 06:22:26 -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: 7.1.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: dots@ietf.org Message-ID: <159075854673.20469.15845978361785967326@ietfa.amsl.com> Date: Fri, 29 May 2020 06:22:26 -0700 Archived-At: Subject: [Dots] I-D Action: draft-ietf-dots-use-cases-22.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, 29 May 2020 13:22:27 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DDoS Open Threat Signaling WG of the IETF. Title : Use cases for DDoS Open Threat Signaling Authors : Roland Dobbins Daniel Migault Robert Moskowitz Nik Teague Liang Xia Kaname Nishizuka Filename : draft-ietf-dots-use-cases-22.txt Pages : 15 Date : 2020-05-29 Abstract: The DDoS Open Threat Signaling (DOTS) effort is intended to provide protocols to facilitate interoperability across disparate DDoS mitigation solutions. This document presents sample use cases which describe the interactions expected between the DOTS components as well as DOTS messaging exchanges. These use cases are meant to identify the interacting DOTS components, how they collaborate, and what are the typical information to be exchanged. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dots-use-cases/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-dots-use-cases-22 https://datatracker.ietf.org/doc/html/draft-ietf-dots-use-cases-22 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dots-use-cases-22 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 May 29 06:33:59 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 2F68F3A087F for ; Fri, 29 May 2020 06:33:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: X-Spam-Status: No, score=-2.096 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, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=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 uZ4aQGRde-f0 for ; Fri, 29 May 2020 06:33:54 -0700 (PDT) Received: from relais-inet.orange.com (relais-inet.orange.com [80.12.66.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C218A3A0880 for ; Fri, 29 May 2020 06:33:53 -0700 (PDT) Received: from opfedar05.francetelecom.fr (unknown [xx.xx.xx.7]) by opfedar26.francetelecom.fr (ESMTP service) with ESMTP id 49YQWh2zkRzFqBd; Fri, 29 May 2020 15:33:52 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1590759232; bh=3d4THA14it6GA8YUBMcxG5XxgSZtlInPKOtbCzvcPvI=; h=From:To:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=dTxaNhML3HtemkoQ7C0FSIOYkkAuxnBZf5sFQlpmXLunGUttvB2wq0+FjCj4LDpfY E5rVw8QXlIHifOU2Kc/gcuzbWGqC7AHwSlkM5RQAdij7grCcXbK9ZwXy73VDKxa4Kb k13oGzyZV6h+ygP/drW9D+0DQoIMCkHGaqXpyYswdRR7CvVpMx/veujCdmt1xbJ8y2 FcqpcdHWmY7WyW1XaFjUuMXqIU8YVLu7A4EWBwjhZPvz1qm3s9MmeW3VkP0uGBuzr9 tmB1Nue3DvGdb9L/NNHXDDFDtNvLZUd1B3YcVo6Mq/Akuhu76B0bZZPX+ltNS6gCAI 7CG+W9VfpmcIQ== Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.57]) by opfedar05.francetelecom.fr (ESMTP service) with ESMTP id 49YQWh1nH8z2xC2; Fri, 29 May 2020 15:33:52 +0200 (CEST) From: To: "Daniel Migault (daniel.migault@ericsson.com)" CC: "dots@ietf.org" , Benjamin Kaduk Thread-Topic: [Dots] Fw: New Version Notification for draft-ietf-dots-use-cases-21.txt Thread-Index: AQHWNTJI/aDZ5ZfXyE2CTZOVjsxzcKi+9/ZwgAAYvhA= Date: Fri, 29 May 2020 13:33:51 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B9330314D4921@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> References: <158957301931.29701.7665561022279853821@ietfa.amsl.com> <20200528205455.GI58497@kduck.mit.edu> <787AE7BB302AE849A7480A190F8B9330314D4830@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> In-Reply-To: <787AE7BB302AE849A7480A190F8B9330314D4830@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.114.13.245] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Dots] Fw: New Version Notification for draft-ietf-dots-use-cases-21.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, 29 May 2020 13:33:57 -0000 Re-,=20 Apologies, I meant [RFC8782][RFC8783] that should normally be available by = the end of the IETF LC for this draft.=20 Thank you. =20 Cheers, Med > -----Message d'origine----- > De=A0: Dots [mailto:dots-bounces@ietf.org] De la part de > mohamed.boucadair@orange.com > Envoy=E9=A0: vendredi 29 mai 2020 14:43 > =C0=A0: Daniel Migault (daniel.migault@ericsson.com) > Cc=A0: dots@ietf.org; Benjamin Kaduk > Objet=A0: Re: [Dots] Fw: New Version Notification for draft-ietf-dots- > use-cases-21.txt >=20 > Hi Daniel, all, >=20 > Apologies for the late comment, but can you please make the following > change in the next iteration of the draft: >=20 > OLD: > This document provides sample use cases that provided input for the > design of the DOTS protocols. >=20 > NEW: > This document provides sample use cases that provided input for the > design of the DOTS protocols [RFC8772][RFC8773]. >=20 > Thank you. >=20 > Cheers, > Med >=20 > > -----Message d'origine----- > > De=A0: Dots [mailto:dots-bounces@ietf.org] De la part de Benjamin > Kaduk > > Envoy=E9=A0: jeudi 28 mai 2020 22:55 > > =C0=A0: Daniel Migault > > Cc=A0: dots@ietf.org > > Objet=A0: Re: [Dots] Fw: New Version Notification for draft-ietf-dots- > > use-cases-21.txt > > > > On Fri, May 15, 2020 at 08:05:29PM +0000, Daniel Migault wrote: > > > Please find the version 21 that considers all feed backs - or at > > least my understanding of them - that we received until now. > > > > Thanks for the updates; I'll go ahead and kick off the IETF LC. > > > > It does look like one of my editorial comments was not understood as > I > > intended, but we can treat that as we would a LC comment: > > > > > > Section 1 > > > > As DDoS solutions are broadly heterogeneous among vendors, the > > primary goal of DOTS is to provide high-level interaction amongst > > differing DDoS solutions, such as detecting, initiating, > > terminating > > DDoS mitigation assistance or requesting the status of a DDoS > > mitigation. > > > > nit: the list structure is not properly parallel. It looks like the > > various clauses are meant to be "detecting DDoS", > > "initiating/terminating mitigation assistance", and "requesting > > mitigation status", so maybe this could become: > > > > % As DDoS solutions are broadly heterogeneous among vendors, the > > % primary goal of DOTS is to provide high-level interaction amongst > > % differing DDoS solutions, such as detecting DDoS attacks, > > % initiating/terminating DDoS mitigation assistance, or requesting > the > > % status of a DDoS mitigation. > > > > The -21 adds the '/' in "initiating/terminating DDoS mitigation > > assistance" > > but there were a few other changes in my proposal that are needed to > > make > > the list structure parallel. E.g., the full phrase "detecting DDoS > > attacks" and the serial comma. > > > > Thanks, > > > > Ben > > > > _______________________________________________ > > Dots mailing list > > Dots@ietf.org > > https://www.ietf.org/mailman/listinfo/dots >=20 > _______________________________________________ > Dots mailing list > Dots@ietf.org > https://www.ietf.org/mailman/listinfo/dots From nobody Fri May 29 06:48:17 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 E00B13A08C1; Fri, 29 May 2020 06:48:11 -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: 7.1.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: dots@ietf.org Message-ID: <159076009186.5035.11864707427348226805@ietfa.amsl.com> Date: Fri, 29 May 2020 06:48:11 -0700 Archived-At: Subject: [Dots] I-D Action: draft-ietf-dots-multihoming-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: Fri, 29 May 2020 13:48:12 -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 : Multi-homing Deployment Considerations for Distributed-Denial-of-Service Open Threat Signaling (DOTS) Authors : Mohamed Boucadair Tirumaleswar Reddy Wei Pan Filename : draft-ietf-dots-multihoming-04.txt Pages : 15 Date : 2020-05-29 Abstract: This document discusses multi-homing considerations for Distributed- Denial-of-Service Open Threat Signaling (DOTS). The goal is to provide some guidance for DOTS clients/gateways when multihomed. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dots-multihoming/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-dots-multihoming-04 https://datatracker.ietf.org/doc/html/draft-ietf-dots-multihoming-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dots-multihoming-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 Fri May 29 06:52:33 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 D51CB3A08CF for ; Fri, 29 May 2020 06:52:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: X-Spam-Status: No, score=-2.096 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, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=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 wQXqSVPwBWJg for ; Fri, 29 May 2020 06:52:31 -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 7608E3A08CB for ; Fri, 29 May 2020 06:52:31 -0700 (PDT) Received: from opfedar04.francetelecom.fr (unknown [xx.xx.xx.6]) by opfedar23.francetelecom.fr (ESMTP service) with ESMTP id 49YQx95yQ8zBs10 for ; Fri, 29 May 2020 15:52:29 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1590760349; bh=HNe+DPR075IUu1RUIrTJ9/YMWfi6WLjriIx2GJJcw6E=; h=From:To:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=Bp2kRbbl1vdQ7xJZ43Xa96SEm2/wX40tXrBN0kjP3N4Z7VuJW+hYDaItfz1KIiNn0 p3gj6Hdfmv6hAT1q1w8s6+c5NqwP28piU1u3Yc8VaUShssvqlrtkqU2j+Xn2DXd2wg P53EuaE2NWlelRW1yQytly3JDAP5ZeIdn0AvDSYBKSLPMJT0z4/wQXnPvQkEvG+A/q Ce93OANgYoduDHfWZnDNcmHkWByHES3m+bPM69iIac1RmwnBRXgGVi89D7ZSe9tjLD 6+yjCO4BhYBP/JflCcVDqb1J9P0ig6XnR7tFgM5QFEXpNV51gz0SSLTkXFFSnfqlYL QMtkKsIbD8ssg== Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.23]) by opfedar04.francetelecom.fr (ESMTP service) with ESMTP id 49YQx95Fzlz1xpK for ; Fri, 29 May 2020 15:52:29 +0200 (CEST) From: To: "dots@ietf.org" Thread-Topic: I-D Action: draft-ietf-dots-multihoming-04.txt Thread-Index: AQHWNb/V9ZSPu7PpdkSQkg/0e2by0ai/FDbg Date: Fri, 29 May 2020 13:52:29 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B9330314D495A@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> References: <159076009186.5035.11864707427348226805@ietfa.amsl.com> In-Reply-To: <159076009186.5035.11864707427348226805@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.245] 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-multihoming-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: Fri, 29 May 2020 13:52:33 -0000 All, This is a minor update of this document. A diff is provided below.=20 We really need your help. So, please review and share comments.=20 Cheers, Med > -----Message d'origine----- > De=A0: I-D-Announce [mailto:i-d-announce-bounces@ietf.org] De la part de > internet-drafts@ietf.org > Envoy=E9=A0: vendredi 29 mai 2020 15:48 > =C0=A0: i-d-announce@ietf.org > Cc=A0: dots@ietf.org > Objet=A0: I-D Action: draft-ietf-dots-multihoming-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 : Multi-homing Deployment Considerations for > Distributed-Denial-of-Service Open Threat Signaling (DOTS) > Authors : Mohamed Boucadair > Tirumaleswar Reddy > Wei Pan > Filename : draft-ietf-dots-multihoming-04.txt > Pages : 15 > Date : 2020-05-29 >=20 > Abstract: > This document discusses multi-homing considerations for > Distributed- > Denial-of-Service Open Threat Signaling (DOTS). The goal is to > provide some guidance for DOTS clients/gateways when multihomed. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-dots-multihoming/ >=20 > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-dots-multihoming-04 > https://datatracker.ietf.org/doc/html/draft-ietf-dots-multihoming-04 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dots-multihoming-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 > _______________________________________________ > 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 May 29 07:13: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 A24C93A0A63; Fri, 29 May 2020 07:13:11 -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: 7.1.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: dots@ietf.org Message-ID: <159076159161.21124.12265047541277916372@ietfa.amsl.com> Date: Fri, 29 May 2020 07:13:11 -0700 Archived-At: Subject: [Dots] I-D Action: draft-ietf-dots-use-cases-23.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, 29 May 2020 14:13: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 : Use cases for DDoS Open Threat Signaling Authors : Roland Dobbins Daniel Migault Robert Moskowitz Nik Teague Liang Xia Kaname Nishizuka Filename : draft-ietf-dots-use-cases-23.txt Pages : 15 Date : 2020-05-29 Abstract: The DDoS Open Threat Signaling (DOTS) effort is intended to provide protocols to facilitate interoperability across disparate DDoS mitigation solutions. This document presents sample use cases which describe the interactions expected between the DOTS components as well as DOTS messaging exchanges. These use cases are meant to identify the interacting DOTS components, how they collaborate, and what are the typical information to be exchanged. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dots-use-cases/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-dots-use-cases-23 https://datatracker.ietf.org/doc/html/draft-ietf-dots-use-cases-23 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dots-use-cases-23 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 May 29 07:18:43 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 AF27C3A0A01 for ; Fri, 29 May 2020 07:18:35 -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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 0xKwBf1sLoL0 for ; Fri, 29 May 2020 07:18:34 -0700 (PDT) Received: from mail-vs1-xe35.google.com (mail-vs1-xe35.google.com [IPv6:2607:f8b0:4864:20::e35]) (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 00EC83A09D3 for ; Fri, 29 May 2020 07:18:33 -0700 (PDT) Received: by mail-vs1-xe35.google.com with SMTP id u7so1565451vsp.7 for ; Fri, 29 May 2020 07:18:33 -0700 (PDT) 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 :cc; bh=7PjKFFAd2uhmrqpzrhFC2m6e5MBooYtB95tiwjZIq+0=; b=kPK+dK6u3sW4ik1qjR8bzwilA3dbEuaRe6YCTZUjqWi5gk29DCmff8LZ6WpnwF7kbl 4jQqAcsvs4NSncT+UKKQuQWs3dkNfbUVivyckxgoJmS6vyyM1PPRqv+4iDGghCWP5B7B RdEGLKpYI4QMhxNI21q6WpHovnmWM8+Lf1+AHzA7EnB94VqComLG0+zafQO/EcGHIFC5 qXwWdbVlbgR4nYRtPu3jxrSVz/yMqTHRAsiM7JPh85hZOXOlKs7dBWu3c8WoFZPQRsgd lH4xQnzcS1jpAWKl1SsXoe80bkmgHD5fFmHSWe1C4G2GWzZbcS40sc+uDJtSG5zpKwE4 GfCQ== 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:cc; bh=7PjKFFAd2uhmrqpzrhFC2m6e5MBooYtB95tiwjZIq+0=; b=FI/yzzoN1/MPaHrDE6F4sxwkDuJ6exbA79+1yCIn5/7N9vxWue7prngG+5JvbZ2way 5Qt4Ac9lIhRcGgeZG8TGGk6KVyI3VKEIjZdGvzpERLL4UP6YSttT5F79DFCCHpboJnwd r5vJq59E5xkfSbaIHdIebl4MEvWqV3W4lu8N48I2low7+VlYYw3A2FWxQlPgys57699z WTLXBpc3j9x4kzZVqwXz9Y5IgPEzfBQJXzuibbN4pn27dyBWPgYMyBN2n41BNOGMVNKl UoD9qYsHLHx47FuM3/1tQgHuglNZwvpqcL+rnu/ZjDEBcgX4xVhzFKzZMsdPAeIDlIDV B8JQ== X-Gm-Message-State: AOAM532B/D05elxViA5TLZ+3R6SHHwbl/wLLxMBNUfrOc14ZIbSFnJzA SPVSugNVcQvn9mbMKJvbrWcSG0aAlenlU7ILxeg= X-Google-Smtp-Source: ABdhPJx/DtMc1giZBGNqjrMyZg2Y82+JIc4ExiXPNWSxkf4lpTRwtivDiP3aLtNuQnDmyXacKnNfKbnlKVbW+HoB2+4= X-Received: by 2002:a67:edc9:: with SMTP id e9mr6046873vsp.69.1590761911927; Fri, 29 May 2020 07:18:31 -0700 (PDT) MIME-Version: 1.0 References: <158957301931.29701.7665561022279853821@ietfa.amsl.com> <20200528205455.GI58497@kduck.mit.edu> In-Reply-To: <20200528205455.GI58497@kduck.mit.edu> From: Daniel Migault Date: Fri, 29 May 2020 10:18:20 -0400 Message-ID: To: Benjamin Kaduk Cc: Daniel Migault , "dots@ietf.org" Content-Type: multipart/alternative; boundary="000000000000aec68305a6ca1ec4" Archived-At: Subject: Re: [Dots] Fw: New Version Notification for draft-ietf-dots-use-cases-21.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, 29 May 2020 14:18:43 -0000 --000000000000aec68305a6ca1ec4 Content-Type: text/plain; charset="UTF-8" Hi Ben, Thanks for the follow up. I think all changes have been considered in the new version. Yours, Daniel On Thu, May 28, 2020 at 4:55 PM Benjamin Kaduk wrote: > On Fri, May 15, 2020 at 08:05:29PM +0000, Daniel Migault wrote: > > Please find the version 21 that considers all feed backs - or at least > my understanding of them - that we received until now. > > Thanks for the updates; I'll go ahead and kick off the IETF LC. > > It does look like one of my editorial comments was not understood as I > intended, but we can treat that as we would a LC comment: > > > Section 1 > > As DDoS solutions are broadly heterogeneous among vendors, the > primary goal of DOTS is to provide high-level interaction amongst > differing DDoS solutions, such as detecting, initiating, terminating > DDoS mitigation assistance or requesting the status of a DDoS > mitigation. > > nit: the list structure is not properly parallel. It looks like the > various clauses are meant to be "detecting DDoS", > "initiating/terminating mitigation assistance", and "requesting > mitigation status", so maybe this could become: > > % As DDoS solutions are broadly heterogeneous among vendors, the > % primary goal of DOTS is to provide high-level interaction amongst > % differing DDoS solutions, such as detecting DDoS attacks, > % initiating/terminating DDoS mitigation assistance, or requesting the > % status of a DDoS mitigation. > > The -21 adds the '/' in "initiating/terminating DDoS mitigation assistance" > but there were a few other changes in my proposal that are needed to make > the list structure parallel. E.g., the full phrase "detecting DDoS > attacks" and the serial comma. > > Thanks, > > Ben > > _______________________________________________ > Dots mailing list > Dots@ietf.org > https://www.ietf.org/mailman/listinfo/dots > -- Daniel Migault Ericsson --000000000000aec68305a6ca1ec4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Ben,=C2=A0

Thanks for the follow up.= I think all changes have been considered in the new version.=C2=A0

Yours,=C2=A0
Daniel

On Thu, May 28, 2020= at 4:55 PM Benjamin Kaduk <kaduk@mit.e= du> wrote:
Dots@ietf.org
https://www.ietf.org/mailman/listinfo/dots


--
Daniel Migault
Ericsson
--000000000000aec68305a6ca1ec4-- From nobody Fri May 29 07:21:28 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 ED3A23A0914 for ; Fri, 29 May 2020 07:21:25 -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, FREEMAIL_FROM=0.001, HTML_MESSAGE=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 hBSSeyE6TiZP for ; Fri, 29 May 2020 07:21:24 -0700 (PDT) Received: from mail-ua1-x932.google.com (mail-ua1-x932.google.com [IPv6:2607:f8b0:4864:20::932]) (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 777AB3A0916 for ; Fri, 29 May 2020 07:21:23 -0700 (PDT) Received: by mail-ua1-x932.google.com with SMTP id g34so848371uah.4 for ; Fri, 29 May 2020 07:21:23 -0700 (PDT) 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 :cc; bh=aX1P8N3aPAdtOy1TbN5jgyymqOKeGFMQBmuY/VKGV8k=; b=un4npEYVqVpZfOlbbDgf+JFnYopIjR7V9Hw/P7jd8NZffApVXUU2pooU1R/Dh6ksCg 6ir1Gx0dzNz7ZiEGAVgBKSUxhzNYU7unxactp3EAE7NC4ZQTPPSEXK24OmbDWR+Y9NFg MpEZZDHrWVbzkqRQayS5QsEl76qGmeCnVFxjgZvm1eOaRnw5mPjbzot/w1Junul9SPrx cOP6yNx4sLue7UQHJjBxK9K1T1UTPfKboqnntwwVHEl2/jGHpifKawGM9UizvGzUngcZ 5FMcqPTtdQnItEgaCIFyyItnYdmq3QSg/PAqau+17IqB58sSnkFGlA81+Ycq3wK0dfoh 5cLQ== 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:cc; bh=aX1P8N3aPAdtOy1TbN5jgyymqOKeGFMQBmuY/VKGV8k=; b=FgPcGDPcNeqQKj5V3UABiLnJJbtFhhXfRL9daVAsA3qIirZjHf08GYxv9IOOUv4d2o broC6nH7Xvr+hqIoSDb1Lw6zrDDAtUPNAcc4Jwho+VkFdI8P87lg+NmeEoHfscQ5JTdh u94YFK5fIo5YnWmP6RUHOTY4JImL9chEuX3mxXFL/0tL2iGD0z5O9VK+qL8dwbne4Z99 Nx+SMwpAvzf3ZcciDJ4uH1oBPiF3WUod6HzbM6gwNoYRVGXs/3MDTai1zNTGuPfd88oL DvdbaRw7YEgCILU5PqqiNd/Hg4Z0oAX95VhCZx5JxiVimuMS+QGHpBrZFaGS7ruDPw9h Kaqg== X-Gm-Message-State: AOAM533uVRAyNa35B/7wrg8VBmV0LYzh0tPdTn7PGItNGRHD47dPNtcd OWs2cYaM6dY8Or5hwyIIWq9W6eyObvg/Fl65sE8= X-Google-Smtp-Source: ABdhPJz7txVNDle8EvfKQ/N9YytT2diQoZDizlP0MpjQDcopxZjSGOTgGrISz0pqhNlGgmA8MjhVf23Rm+TqjbNSQD8= X-Received: by 2002:ab0:2c02:: with SMTP id l2mr6066781uar.66.1590762082471; Fri, 29 May 2020 07:21:22 -0700 (PDT) MIME-Version: 1.0 References: <158957301931.29701.7665561022279853821@ietfa.amsl.com> <20200528205455.GI58497@kduck.mit.edu> <787AE7BB302AE849A7480A190F8B9330314D4830@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B9330314D4921@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> In-Reply-To: <787AE7BB302AE849A7480A190F8B9330314D4921@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> From: Daniel Migault Date: Fri, 29 May 2020 10:21:11 -0400 Message-ID: To: mohamed.boucadair@orange.com Cc: "dots@ietf.org" , Benjamin Kaduk Content-Type: multipart/alternative; boundary="000000000000d9129e05a6ca28d6" Archived-At: Subject: Re: [Dots] Fw: New Version Notification for draft-ietf-dots-use-cases-21.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, 29 May 2020 14:21:26 -0000 --000000000000d9129e05a6ca28d6 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Med, Thanks. I also got distracted to check the right number... but this is now done. Yours, Daniel On Fri, May 29, 2020 at 9:34 AM wrote: > Re-, > > Apologies, I meant [RFC8782][RFC8783] that should normally be available b= y > the end of the IETF LC for this draft. > > Thank you. > > Cheers, > Med > > > -----Message d'origine----- > > De : Dots [mailto:dots-bounces@ietf.org] De la part de > > mohamed.boucadair@orange.com > > Envoy=C3=A9 : vendredi 29 mai 2020 14:43 > > =C3=80 : Daniel Migault (daniel.migault@ericsson.com) > > Cc : dots@ietf.org; Benjamin Kaduk > > Objet : Re: [Dots] Fw: New Version Notification for draft-ietf-dots- > > use-cases-21.txt > > > > Hi Daniel, all, > > > > Apologies for the late comment, but can you please make the following > > change in the next iteration of the draft: > > > > OLD: > > This document provides sample use cases that provided input for the > > design of the DOTS protocols. > > > > NEW: > > This document provides sample use cases that provided input for the > > design of the DOTS protocols [RFC8772][RFC8773]. > > > > Thank you. > > > > Cheers, > > Med > > > > > -----Message d'origine----- > > > De : Dots [mailto:dots-bounces@ietf.org] De la part de Benjamin > > Kaduk > > > Envoy=C3=A9 : jeudi 28 mai 2020 22:55 > > > =C3=80 : Daniel Migault > > > Cc : dots@ietf.org > > > Objet : Re: [Dots] Fw: New Version Notification for draft-ietf-dots- > > > use-cases-21.txt > > > > > > On Fri, May 15, 2020 at 08:05:29PM +0000, Daniel Migault wrote: > > > > Please find the version 21 that considers all feed backs - or at > > > least my understanding of them - that we received until now. > > > > > > Thanks for the updates; I'll go ahead and kick off the IETF LC. > > > > > > It does look like one of my editorial comments was not understood as > > I > > > intended, but we can treat that as we would a LC comment: > > > > > > > > > Section 1 > > > > > > As DDoS solutions are broadly heterogeneous among vendors, the > > > primary goal of DOTS is to provide high-level interaction amongst > > > differing DDoS solutions, such as detecting, initiating, > > > terminating > > > DDoS mitigation assistance or requesting the status of a DDoS > > > mitigation. > > > > > > nit: the list structure is not properly parallel. It looks like the > > > various clauses are meant to be "detecting DDoS", > > > "initiating/terminating mitigation assistance", and "requesting > > > mitigation status", so maybe this could become: > > > > > > % As DDoS solutions are broadly heterogeneous among vendors, the > > > % primary goal of DOTS is to provide high-level interaction amongst > > > % differing DDoS solutions, such as detecting DDoS attacks, > > > % initiating/terminating DDoS mitigation assistance, or requesting > > the > > > % status of a DDoS mitigation. > > > > > > The -21 adds the '/' in "initiating/terminating DDoS mitigation > > > assistance" > > > but there were a few other changes in my proposal that are needed to > > > make > > > the list structure parallel. E.g., the full phrase "detecting DDoS > > > attacks" and the serial comma. > > > > > > Thanks, > > > > > > Ben > > > > > > _______________________________________________ > > > Dots mailing list > > > Dots@ietf.org > > > https://www.ietf.org/mailman/listinfo/dots > > > > _______________________________________________ > > Dots mailing list > > Dots@ietf.org > > https://www.ietf.org/mailman/listinfo/dots > > _______________________________________________ > Dots mailing list > Dots@ietf.org > https://www.ietf.org/mailman/listinfo/dots > --=20 Daniel Migault Ericsson --000000000000d9129e05a6ca28d6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Med,=C2=A0

Thanks. I also got distra= cted to check the right number... but this is now done.=C2=A0
Yours,=C2=A0
Daniel

On Fri, May 29, 2020 at 9:34 AM <= ;mohamed.boucadair@orange.c= om> wrote:
dots-bounces@ietf.org] De la part de
> moha= med.boucadair@orange.com
> Envoy=C3=A9=C2=A0: vendredi 29 mai 2020 14:43
> =C3=80=C2=A0: Daniel Migault (daniel.migault@ericsson.com)
> Cc=C2=A0: dots@ietf= .org; Benjamin Kaduk
> Objet=C2=A0: Re: [Dots] Fw: New Version Notification for draft-ietf-do= ts-
> use-cases-21.txt
>
> Hi Daniel, all,
>
> Apologies for the late comment, but can you please make the following<= br> > change in the next iteration of the draft:
>
> OLD:
>=C2=A0 =C2=A0 This document provides sample use cases that provided inp= ut for the
>=C2=A0 =C2=A0 design of the DOTS protocols.
>
> NEW:
>=C2=A0 =C2=A0 This document provides sample use cases that provided inp= ut for the
>=C2=A0 =C2=A0 design of the DOTS protocols [RFC8772][RFC8773].
>
> Thank you.
>
> Cheers,
> Med
>
> > -----Message d'origine-----
> > De=C2=A0: Dots [mailto:dots-bounces@ietf.org] De la part de Benjamin
> Kaduk
> > Envoy=C3=A9=C2=A0: jeudi 28 mai 2020 22:55
> > =C3=80=C2=A0: Daniel Migault
> > Cc=C2=A0: dots= @ietf.org
> > Objet=C2=A0: Re: [Dots] Fw: New Version Notification for draft-ie= tf-dots-
> > use-cases-21.txt
> >
> > On Fri, May 15, 2020 at 08:05:29PM +0000, Daniel Migault wrote: > > > Please find the version 21 that considers all feed backs - o= r at
> > least my understanding of them - that we received until now.
> >
> > Thanks for the updates; I'll go ahead and kick off the IETF L= C.
> >
> > It does look like one of my editorial comments was not understood= as
> I
> > intended, but we can treat that as we would a LC comment:
> >
> >
> > Section 1
> >
> >=C2=A0 =C2=A0 As DDoS solutions are broadly heterogeneous among ve= ndors, the
> >=C2=A0 =C2=A0 primary goal of DOTS is to provide high-level intera= ction amongst
> >=C2=A0 =C2=A0 differing DDoS solutions, such as detecting, initiat= ing,
> > terminating
> >=C2=A0 =C2=A0 DDoS mitigation assistance or requesting the status = of a DDoS
> >=C2=A0 =C2=A0 mitigation.
> >
> > nit: the list structure is not properly parallel.=C2=A0 It looks = like the
> > various clauses are meant to be "detecting DDoS",
> > "initiating/terminating mitigation assistance", and &qu= ot;requesting
> > mitigation status", so maybe this could become:
> >
> > % As DDoS solutions are broadly heterogeneous among vendors, the<= br> > > % primary goal of DOTS is to provide high-level interaction among= st
> > % differing DDoS solutions, such as detecting DDoS attacks,
> > % initiating/terminating DDoS mitigation assistance, or requestin= g
> the
> > % status of a DDoS mitigation.
> >
> > The -21 adds the '/' in "initiating/terminating DDoS= mitigation
> > assistance"
> > but there were a few other changes in my proposal that are needed= to
> > make
> > the list structure parallel.=C2=A0 E.g., the full phrase "de= tecting DDoS
> > attacks" and the serial comma.
> >
> > Thanks,
> >
> > Ben
> >
> > _______________________________________________
> > Dots mailing list
> > Dots@ietf.org<= /a>
> > https://www.ietf.org/mailman/listinfo/dots >
> _______________________________________________
> Dots mailing list
> Dots@ietf.org > https://www.ietf.org/mailman/listinfo/dots

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


--
Daniel Migault
Ericsson
--000000000000d9129e05a6ca28d6-- From nobody Sat May 30 23:14: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 9510C3A1264; Sat, 30 May 2020 23:14:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WOI4gxjD4fjU; Sat, 30 May 2020 23:13:58 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 814333A1261; Sat, 30 May 2020 23:13:58 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 2C772F4071C; Sat, 30 May 2020 23:13:43 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org X-PHP-Originating-Script: 1005:ams_util_lib.php From: rfc-editor@rfc-editor.org Cc: rfc-editor@rfc-editor.org, drafts-update-ref@iana.org, dots@ietf.org Content-type: text/plain; charset=UTF-8 Message-Id: <20200531061343.2C772F4071C@rfc-editor.org> Date: Sat, 30 May 2020 23:13:43 -0700 (PDT) Archived-At: Subject: [Dots] =?utf-8?q?RFC_8782_on_Distributed_Denial-of-Service_Open_?= =?utf-8?q?Threat_Signaling_=28DOTS=29_Signal_Channel_Specification?= 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: Sun, 31 May 2020 06:14:02 -0000 A new Request for Comments is now available in online RFC libraries. RFC 8782 Title: Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal Channel Specification Author: T. Reddy.K, Ed., M. Boucadair, Ed., P. Patil, A. Mortensen, N. Teague Status: Standards Track Stream: IETF Date: May 2020 Mailbox: kondtir@gmail.com, mohamed.boucadair@orange.com, praspati@cisco.com, andrew@moretension.com, nteague@ironmountain.co.uk Pages: 100 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-dots-signal-channel-41.txt URL: https://www.rfc-editor.org/info/rfc8782 DOI: 10.17487/RFC8782 This document specifies the Distributed Denial-of-Service Open Threat Signaling (DOTS) signal channel, a protocol for signaling the need for protection against Distributed Denial-of-Service (DDoS) attacks to a server capable of enabling network traffic mitigation on behalf of the requesting client. A companion document defines the DOTS data channel, a separate reliable communication layer for DOTS management and configuration purposes. This document is a product of the DDoS Open Threat Signaling Working Group of the IETF. This is now a Proposed Standard. STANDARDS TRACK: This document specifies an Internet Standards Track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the Official Internet Protocol Standards (https://www.rfc-editor.org/standards) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From nobody Sat May 30 23:14:11 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 39BE93A1277; Sat, 30 May 2020 23:14:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SUAmWOGV5rpH; Sat, 30 May 2020 23:14:03 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9CB003A1263; Sat, 30 May 2020 23:14:03 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 475A0F40739; Sat, 30 May 2020 23:13:48 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org X-PHP-Originating-Script: 1005:ams_util_lib.php From: rfc-editor@rfc-editor.org Cc: rfc-editor@rfc-editor.org, drafts-update-ref@iana.org, dots@ietf.org Content-type: text/plain; charset=UTF-8 Message-Id: <20200531061348.475A0F40739@rfc-editor.org> Date: Sat, 30 May 2020 23:13:48 -0700 (PDT) Archived-At: Subject: [Dots] =?utf-8?q?RFC_8783_on_Distributed_Denial-of-Service_Open_?= =?utf-8?q?Threat_Signaling_=28DOTS=29_Data_Channel_Specification?= 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: Sun, 31 May 2020 06:14:07 -0000 A new Request for Comments is now available in online RFC libraries. RFC 8783 Title: Distributed Denial-of-Service Open Threat Signaling (DOTS) Data Channel Specification Author: M. Boucadair, Ed., T. Reddy.K, Ed. Status: Standards Track Stream: IETF Date: May 2020 Mailbox: mohamed.boucadair@orange.com, kondtir@gmail.com Pages: 66 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-dots-data-channel-31.txt URL: https://www.rfc-editor.org/info/rfc8783 DOI: 10.17487/RFC8783 The document specifies a Distributed Denial-of-Service Open Threat Signaling (DOTS) data channel used for bulk exchange of data that cannot easily or appropriately communicated through the DOTS signal channel under attack conditions. This is a companion document to "Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal Channel Specification" (RFC 8782). This document is a product of the DDoS Open Threat Signaling Working Group of the IETF. This is now a Proposed Standard. STANDARDS TRACK: This document specifies an Internet Standards Track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the Official Internet Protocol Standards (https://www.rfc-editor.org/standards) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC