From nobody Mon Feb 3 01:36:47 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 11F0712002E for ; Mon, 3 Feb 2020 01:36:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B--9b6bXJYHc for ; Mon, 3 Feb 2020 01:36:42 -0800 (PST) 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 2721912001E for ; Mon, 3 Feb 2020 01:36:42 -0800 (PST) Received: from opfedar00.francetelecom.fr (unknown [xx.xx.xx.11]) by opfedar27.francetelecom.fr (ESMTP service) with ESMTP id 48B2lX3RBNz2yFC; Mon, 3 Feb 2020 10:36:40 +0100 (CET) Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.51]) by opfedar00.francetelecom.fr (ESMTP service) with ESMTP id 48B2lX2YW9zCqlZ; Mon, 3 Feb 2020 10:36:40 +0100 (CET) Received: from OPEXCAUBMA2.corporate.adroot.infra.ftgroup ([fe80::e878:bd0:c89e:5b42]) by OPEXCAUBM22.corporate.adroot.infra.ftgroup ([fe80::954c:232a:f07d:25af%21]) with mapi id 14.03.0468.000; Mon, 3 Feb 2020 10:36:40 +0100 From: To: "Jon Shallow (supjps-ietf@jpshallow.com)" , "dots@ietf.org" Thread-Topic: [Dots] I-D Action: draft-ietf-dots-telemetry-01.txt Thread-Index: AQHV2EXz9yDIgoBiC0qPIDVW/PbWkKgE4JlQgAQ3oMA= Date: Mon, 3 Feb 2020 09:36:39 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B933031414F55@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> References: <158048229416.21195.16114328651657501634@ietfa.amsl.com> <787AE7BB302AE849A7480A190F8B93303141473A@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> In-Reply-To: <787AE7BB302AE849A7480A190F8B93303141473A@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.247] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Dots] I-D Action: draft-ietf-dots-telemetry-01.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, 03 Feb 2020 09:36:45 -0000 Hi all,=20 FYI, a review from Jon is available at: https://github.com/boucadair/draft-= dots-telemetry/raw/master/DOTS%20Telemetry%2001-rev%20Jon-res%20Med.docx=20 -02 will integrate almost all comments from Jon. Please find below some po= ints we would like to hear more from the working group: (1) key value range for telemetry: Jon raised this point "These keys requir= es 3 bytes - and telemetry information is going to be difficult to fit into= a packet. I appreciate that comprehension-required Is for numbers less than 0x8000 - perhaps the comprehension-required range = is reduced and also has a section higher up so the total of 0x8000 still st= ands so less bytes can be used here." +----------------------+-------+-------+------------+---------------+ | Parameter Name | CBOR | CBOR | Change | Specification | | | Key | Major | Controller | Document(s) | | | Value | Type | | | +----------------------+-------+-------+------------+---------------+ | ietf-dots-signal-cha | 32776 | 5 | IESG | [RFCXXXX] | | nnel:telemetry | | | | |=20 Med: This is a major one. We need to assess the gain, but it is possible in= theory to update our assignment policies and reassign, e.g., 128-255 range= to be comprehension-optional (specific for telemetry). This would mean tha= t the telemetry spec will be tagged as updating the base signal channel spe= c. We need more discussion.=20 (2) server-initiated-telemetry: "Having server-initiated-telemetry under ma= x-config-values, but not min-config-values makes no sense to me. I think i= t should be under telemetry-config at the level of current-config and possi= bly removed from current-config as well." Med:=20 A. It is in the max container because setting that value to "false" under t= hat container has a special meaning: the server does not support sending pr= e-mitigation telemetry. We can put it under min as well but do we have a ca= se where setting it to "true" has a meaning? B. I do agree that 'server-initiated-telemetry' can be removed from the cur= rent configuration because the same functionality is achieved using a GET+O= bserve but we left it there for the moment as we need to work further the d= etails for subscribing to pre-mitigation from the servers. =20 (3) "vendor-id is missing from the cbor table": Med: This was done on purpose to try to optimize the number of CBOR key val= ues + encourage attributes reuse. E.g., We replaced "telemetry-id", "baseli= ne-id", and "vendor-id" with a single "id" (as we only use those for the mo= ment in the message body) but the YANG module includes the meaning of each = "id" in the definition clause. We may need to revise this if we conclude th= at, e.g., "telemetry-id" (tmid) has to be defined as Path-URI. =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 31 janvier 2020 16:18 > =C0=A0: dots@ietf.org > Objet=A0: Re: [Dots] I-D Action: draft-ietf-dots-telemetry-01.txt >=20 > Hi all, >=20 > We prepared with Tiru a major revision of the telemetry draft. A diff > is provided below to track the changes. We will now focus on sections > 7 and 8. >=20 > Please review and share comments. >=20 > Cheers, > Med >=20 > > -----Message d'origine----- > > De=A0: Dots [mailto:dots-bounces@ietf.org] De la part de internet- > > drafts@ietf.org > > Envoy=E9=A0: vendredi 31 janvier 2020 15:52 > > =C0=A0: i-d-announce@ietf.org > > Cc=A0: dots@ietf.org > > Objet=A0: [Dots] I-D Action: draft-ietf-dots-telemetry-01.txt > > > > > > A New Internet-Draft is available from the on-line Internet-Drafts > > directories. > > This draft is a work item of the DDoS Open Threat Signaling WG of > the > > IETF. > > > > Title : Distributed Denial-of-Service Open Threat > > Signaling (DOTS) Telemetry > > Authors : Mohamed Boucadair > > Tirumaleswar Reddy > > Ehud Doron > > Meiling Chen > > Filename : draft-ietf-dots-telemetry-01.txt > > Pages : 70 > > Date : 2020-01-31 > > > > Abstract: > > This document aims to enrich DOTS signal channel protocol with > > various telemetry attributes allowing optimal DDoS attack > > mitigation. > > This document specifies the normal traffic baseline and attack > > traffic telemetry attributes a DOTS client can convey to its DOTS > > server in the mitigation request, the mitigation status telemetry > > attributes a DOTS server can communicate to a DOTS client, and > the > > mitigation efficacy telemetry attributes a DOTS client can > > communicate to a DOTS server. The telemetry attributes can > assist > > the mitigator to choose the DDoS mitigation techniques and > perform > > optimal DDoS attack mitigation. > > > > > > The IETF datatracker status page for this draft is: > > https://datatracker.ietf.org/doc/draft-ietf-dots-telemetry/ > > > > There are also htmlized versions available at: > > https://tools.ietf.org/html/draft-ietf-dots-telemetry-01 > > https://datatracker.ietf.org/doc/html/draft-ietf-dots-telemetry-01 > > > > A diff from the previous version is available at: > > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dots-telemetry-01 > > > > > > 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 >=20 > _______________________________________________ > Dots mailing list > Dots@ietf.org > https://www.ietf.org/mailman/listinfo/dots From nobody Mon Feb 3 02:18: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 A9A5E12001A; Mon, 3 Feb 2020 02:18:47 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: =?utf-8?q?=C3=89ric_Vyncke_via_Datatracker?= To: "The IESG" Cc: draft-ietf-dots-architecture@ietf.org, Roman Danyliw , Valery Smyslov , dots-chairs@ietf.org, valery@smyslov.net, dots@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.116.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: =?utf-8?q?=C3=89ric_Vyncke?= Message-ID: <158072512768.28459.10822203567819861277.idtracker@ietfa.amsl.com> Date: Mon, 03 Feb 2020 02:18:47 -0800 Archived-At: Subject: [Dots] =?utf-8?q?=C3=89ric_Vyncke=27s_No_Objection_on_draft-ietf?= =?utf-8?q?-dots-architecture-16=3A_=28with_COMMENT=29?= X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.29 List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Feb 2020 10:18:48 -0000 Éric Vyncke has entered the following ballot position for draft-ietf-dots-architecture-16: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-dots-architecture/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Dear authors, Thank you for the work put into this document. As a side note, I really liked the section about the manual/over-the-phone part of it. Until now, I have read only this document (dots-architecture) from the dots WG, so, please accept my ignorance for details. But, I have a couple of non-blocking questions where your reply will be welcome and appreciated: Q1) is the monetary cost part of the DOTS signaling ? (I.e., the mitigator telling the target that it will cost so many EUR per hour) Q2) Using DOTS in an under-attack network, did you consider recommending dual-stack signaling to cope with the rare case where IPv4 is disrupted while IPv6 still works (of course if the DoS is plain flooding this won't help a lot probably; and the dual proposition exists). Q3) While I appreciate the value of Anycast DOTS server, hence UDP is mostly required for signaling transport, I wonder whether the choice of UDP (often used AFAIK as volumetric attack as it is easier to spoof) is a good choice compared to TCP or DSCP or ... Q4) When having multiple DOTS servers, I assume that the case of a dual-stack DOTS server is also covered. Therefore, a word on whether Happy Eyeball (RFC 8305) should probably be useful **IF** applicable Regards -éric Regards, -éric From nobody Mon Feb 3 03:25:46 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 5C2941200C5; Mon, 3 Feb 2020 03:25:45 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: =?utf-8?q?Mirja_K=C3=BChlewind_via_Datatracker?= To: "The IESG" Cc: draft-ietf-dots-architecture@ietf.org, Roman Danyliw , Valery Smyslov , dots-chairs@ietf.org, valery@smyslov.net, dots@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.116.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: =?utf-8?q?Mirja_K=C3=BChlewind?= Message-ID: <158072914537.28494.3365896645105885199.idtracker@ietfa.amsl.com> Date: Mon, 03 Feb 2020 03:25:45 -0800 Archived-At: Subject: [Dots] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft-?= =?utf-8?q?ietf-dots-architecture-16=3A_=28with_COMMENT=29?= X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.29 List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Feb 2020 11:25:45 -0000 Mirja Kühlewind has entered the following ballot position for draft-ietf-dots-architecture-16: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-dots-architecture/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Maybe double-check use of normative language. There seem to be a few occasions where normative language could be used but isn't. From nobody Mon Feb 3 19:12: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 9BF7712003E; Mon, 3 Feb 2020 19:12:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_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 hU1pVSgIVSkt; Mon, 3 Feb 2020 19:12:41 -0800 (PST) Received: from mail-io1-xd31.google.com (mail-io1-xd31.google.com [IPv6:2607:f8b0:4864:20::d31]) (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 7E37812002F; Mon, 3 Feb 2020 19:12:41 -0800 (PST) Received: by mail-io1-xd31.google.com with SMTP id i11so19191797ioi.12; Mon, 03 Feb 2020 19:12:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=J2VoPQvlz0SBZ2WxzKh2RNPyntPGMZ1gRbyyPMH24J0=; b=s0T98/0J8jjipapeDxortt8lm7okHjTwDOFC7SF68Jo75CETj4QOFc2xzZ8haBjsIT H5EIKgZrH8VsuQmJ0889ScK1CHKsb6u5gUpNW4fe7QaDrOH2BSwJGCbGoew06n+WHIOa QGI3q3m/Qx9YHH6MBB42bArC7QpLRaNkiLj7yYgJ9gnT+Eiw9Uk7C5frz4yK0aH4rr46 GGC4I6ZoT4ml/bokkHY7HSmKBywXxYwM+i9MCaZCVAOIM4QA9M9q+6X3wKirJF1PDROQ wdi8n3HMVor39mE1TcVvORFuy79mu7qnR1QR83AsGTpje+CBQMkoOEH4FdVozfGWxk6l TFVg== 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=J2VoPQvlz0SBZ2WxzKh2RNPyntPGMZ1gRbyyPMH24J0=; b=sFKhXkPdSue/v0MAx53gpgy7riWiYSueNJFmkRblGpV9ijM6YqEpsBWVrOKlqjX7XQ 6shSAzdfpAmeluV9XBjjmz1X9QMHAMbBiuet7zgn93OfhAxonLq86m6nobqUni7RZ0h3 lcJVfZxf5iKfZq2m8QOSdDIRinqfaFD9In0dQj+x7JiEvchEwpTz8k5eOJ2UCyYGSVy9 +LhQmrcn7m9Pvyqp8qvhokkHSZKDrzKS2zRrjjHUepy5YbveBkapZhK9pBylOh6cRPAu uyZzXbexYbAFNhQd/JpKTeqPCTjnNXYP9T6O3eTqMqw3UXmstCjDcQ5uUzAhQ1dqdStD xQEA== X-Gm-Message-State: APjAAAVqGp39AGF1TFaRVb4qTi3USMG2Phq62myQEGBcymNpEl8SYAp/ sGOUqCnaz+sv+IXKZaTmXtMX/Ubh42PRG6TqAgs= X-Google-Smtp-Source: APXvYqxRJOH2QRNULfdm/Px9iz57Yp8RgCefuqVw8YtUf5c9y6vTzKaGK0Cp0tZhKIDu+PSDZZOpaR+Wmj/pH3izO5g= X-Received: by 2002:a6b:7c04:: with SMTP id m4mr22113996iok.208.1580785960674; Mon, 03 Feb 2020 19:12:40 -0800 (PST) MIME-Version: 1.0 References: <158072512768.28459.10822203567819861277.idtracker@ietfa.amsl.com> In-Reply-To: <158072512768.28459.10822203567819861277.idtracker@ietfa.amsl.com> From: tirumal reddy Date: Tue, 4 Feb 2020 08:42:26 +0530 Message-ID: To: =?UTF-8?B?w4lyaWMgVnluY2tl?= Cc: The IESG , draft-ietf-dots-architecture@ietf.org, Roman Danyliw , Valery Smyslov , dots-chairs@ietf.org, dots@ietf.org Content-Type: multipart/alternative; boundary="000000000000a6ef77059db7699a" Archived-At: Subject: Re: [Dots] =?utf-8?q?=C3=89ric_Vyncke=27s_No_Objection_on_draft-ietf?= =?utf-8?q?-dots-architecture-16=3A_=28with_COMMENT=29?= 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, 04 Feb 2020 03:12:44 -0000 --000000000000a6ef77059db7699a Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Eric, Thanks for the review. Please see inline On Mon, 3 Feb 2020 at 15:48, =C3=89ric Vyncke via Datatracker wrote: > =C3=89ric Vyncke has entered the following ballot position for > draft-ietf-dots-architecture-16: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-dots-architecture/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Dear authors, > > Thank you for the work put into this document. As a side note, I really > liked > the section about the manual/over-the-phone part of it. > > Until now, I have read only this document (dots-architecture) from the > dots WG, > so, please accept my ignorance for details. But, I have a couple of > non-blocking questions where your reply will be welcome and appreciated: > > Q1) is the monetary cost part of the DOTS signaling ? (I.e., the mitigato= r > telling the target that it will cost so many EUR per hour) > No, monetary cost is not part of the DOTS signaling. > > Q2) Using DOTS in an under-attack network, did you consider recommending > dual-stack signaling to cope with the rare case where IPv4 is disrupted > while > IPv6 still works (of course if the DoS is plain flooding this won't help = a > lot > probably; and the dual proposition exists). > Yes, Happy Eyeballs for DOTS signal channel is discussed in https://tools.ietf.org/html/draft-ietf-dots-signal-channel-41#section-4.3 > > Q3) While I appreciate the value of Anycast DOTS server, hence UDP is > mostly > required for signaling transport, I wonder whether the choice of UDP (oft= en > used AFAIK as volumetric attack as it is easier to spoof) is a good choic= e > compared to TCP or DSCP or ... > Both DTLS over UDP and TLS over TCP is used by the DOTS signal channel (UDP is given higher precedence than TCP). DTLS is capable of defending against DoS attack by using the stateless cookie mechanism (see https://tools.ietf.org/html/rfc6347#section-4.2.1) > > Q4) When having multiple DOTS servers, I assume that the case of a > dual-stack > DOTS server is also covered. Therefore, a word on whether Happy Eyeball > (RFC > 8305) should probably be useful **IF** applicable > Happy Eyeball is discussed in detail in the DOTS signal channel protocol specification. Cheers, -Tiru > > Regards > > -=C3=A9ric > > Regards, > > -=C3=A9ric > > > --000000000000a6ef77059db7699a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Eric,

Thanks for the revi= ew. Please see inline

On Mon, 3 Feb 2020 at 15:48, =C3=89ric Vyncke via Data= tracker <noreply@ietf.org> wr= ote:
=C3=89ric V= yncke has entered the following ballot position for
draft-ietf-dots-architecture-16: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/s= tatement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft= -ietf-dots-architecture/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Dear authors,

Thank you for the work put into this document. As a side note, I really lik= ed
the section about the manual/over-the-phone part of it.

Until now, I have read only this document (dots-architecture) from the dots= WG,
so, please accept my ignorance for details. But, I have a couple of
non-blocking questions where your reply will be welcome and appreciated:
Q1) is the monetary cost part of the DOTS signaling ? (I.e., the mitigator<= br> telling the target that it will cost so many EUR per hour)
=

No, monetary cost is not part of the DOTS signaling.
=C2=A0

Q2) Using DOTS in an under-attack network, did you consider recommending dual-stack signaling to cope with the rare case where IPv4 is disrupted whi= le
IPv6 still works (of course if the DoS is plain flooding this won't hel= p a lot
probably; and the dual proposition exists).

=
Yes, Happy Eyeballs for DOTS signal channel is discussed in=C2=A0https://tools.ietf.org/html/draft-ietf-dots-signal-channel-41#section= -4.3
=C2=A0

Q3) While I appreciate the value of Anycast DOTS server, hence UDP is mostl= y
required for signaling transport, I wonder whether the choice of UDP (often=
used AFAIK as volumetric attack as it is easier to spoof) is a good choice<= br> compared to TCP or DSCP or ...

Both DTL= S over UDP and TLS over TCP is used by the DOTS signal channel (UDP is give= n higher precedence than TCP).
DTLS is capable of defending again= st DoS attack by using the stateless cookie mechanism (see=C2=A0https://tools.ietf.org/h= tml/rfc6347#section-4.2.1)=C2=A0
=C2=A0

Q4) When having multiple DOTS servers, I assume that the case of a dual-sta= ck
DOTS server is also covered. Therefore, a word on whether Happy Eyeball (RF= C
8305) should probably be useful **IF** applicable

=
Happy Eyeball is discussed in detail in the DOTS signal channel = protocol specification.

Cheers,
-Tiru
=C2=A0

Regards

-=C3=A9ric

Regards,

-=C3=A9ric


--000000000000a6ef77059db7699a-- From nobody Mon Feb 3 22:58:41 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 CDE57120043; Mon, 3 Feb 2020 22:58:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.497 X-Spam-Level: X-Spam-Status: No, score=-14.497 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=ASJoKmIF; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=y14oTG0D Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 54BQrWZu4CZ0; Mon, 3 Feb 2020 22:58:19 -0800 (PST) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4FCDD120013; Mon, 3 Feb 2020 22:58:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=17703; q=dns/txt; s=iport; t=1580799487; x=1582009087; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=M0qIT5s4gL96W/IU/fBPzK8d49BSw9FI6hVHw7bC9pE=; b=ASJoKmIFEkBPP62QrlVR0iD/v9agm1FDWtxbKowKJoThkDbvDredr1/i PrcHwMg8z1o+sXSu06QXzyu4j3ApKkj7SQ4OclqA1z7h9lCxIZ5Y+LjJi rQzqBn+m5X6OQWMrZeeLivT/jBzr0hQZe82FhgGarjqz6EwZ4u1nY/kh4 8=; IronPort-PHdr: =?us-ascii?q?9a23=3AgHHJZhU4fo4rsymq4al9GjMQM7nV8LGuZFwc94?= =?us-ascii?q?YnhrRSc6+q45XlOgnF6O5wiEPSA92J8OpK3uzRta2oGXcN55qMqjgjSNRNTF?= =?us-ascii?q?dE7KdehAk8GIiAAEz/IuTtank3AtVEX1xo13q6KkNSXs35Yg6arw=3D=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DxAADeFDle/4ENJK1lHAEBAQEBBwE?= =?us-ascii?q?BEQEEBAEBgWkFAQELAYEkL1AFbFggBAsqCoQKg0YDinmCX4EBiGCJTIRigS4?= =?us-ascii?q?UgRADVAkBAQEMAQElCAIBAYRAAheCHSQ2Bw4CAw0BAQQBAQECAQUEbYU3DIV?= =?us-ascii?q?mAQEBAQMSER0BATcBDwIBCBEBAgECKAMCAgIfERQDAwMIAgQOBSKDBAGBfU0?= =?us-ascii?q?DLgEDC6EeAoE5iGJ1gTKCfwEBBYFDQYMfDQuCDAMGgTgBiVaCSRqBQT+BESc?= =?us-ascii?q?gghc1PoIbSQEBAQEBAYEnBQESAQk4DQmCWjKCLI1QEoI6O4VgiXmOckQKgju?= =?us-ascii?q?HRopQBIQmG4JIiA6ESItqg0mTf4IokAsCBAIEBQIOAQEFgVkMJmdYEQhwFWU?= =?us-ascii?q?BgkFQGA2OHQwXFYM7hRSFP3QCAYEmiy6BIgGBDwEB?= X-IronPort-AV: E=Sophos;i="5.70,398,1574121600"; d="scan'208,217";a="627368874" Received: from alln-core-9.cisco.com ([173.36.13.129]) by rcdn-iport-9.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 04 Feb 2020 06:58:05 +0000 Received: from XCH-RCD-010.cisco.com (xch-rcd-010.cisco.com [173.37.102.20]) by alln-core-9.cisco.com (8.15.2/8.15.2) with ESMTPS id 0146w682002042 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 4 Feb 2020 06:58:06 GMT Received: from xhs-rtp-002.cisco.com (64.101.210.229) by XCH-RCD-010.cisco.com (173.37.102.20) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 4 Feb 2020 00:58:05 -0600 Received: from xhs-rcd-002.cisco.com (173.37.227.247) by xhs-rtp-002.cisco.com (64.101.210.229) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 4 Feb 2020 01:58:04 -0500 Received: from NAM12-DM6-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-002.cisco.com (173.37.227.247) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Tue, 4 Feb 2020 00:58:03 -0600 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=ZZvYyeJXvtdH491fJ2FPjhNwh9/S4YdYHdN9OigkPcBXITX19slNoE+4pNZb0kZtS7iCpsyTVCBZtkaaQhj9BGGT1JjlvZ0D37mfuXXZke3eCYcU/xrPSy6lNiLnnP8Dc7YkKIuKgPQoWvHY3c9o2vI42I7lZI6H7p4nHDJwJ2AKz0N+hzf6tTYNGFUYHEWfEvyhPI8+6xGh2E7ap83XGgDMeonY3TQKUeMTq1Dgq1RFMW4KxD9kuLcj3xcOvb9J557L4hNhnCR0EQtfmgBN5euLDxG+f4ryc08gMYlrQSe9pBox4Sk3pTqxfCMIsHM1WONOJs7viLVg64kCDyG0Cw== 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=M0qIT5s4gL96W/IU/fBPzK8d49BSw9FI6hVHw7bC9pE=; b=HhJ16FyAmWtcYiHahqqVESyk4Syri2tz3VBeSnht8/X/trqKZHpaZJbbe0BluSjiqksp4t7qzweI8NnALI6Cv2nFAjtB24tM+xs2xsci0zQu+Q2+VOifIxr/NC2RJihL3sCsqAJbDMWdtp6JtmIMQxjE4L8IQjIUgyrLrbziNI5m/791kalagsOXdOzXEbI/5t5Hgr3FwJ6PBE0q8d18TXfSm6gL8Xe0TWBgrWtgWXYXHhjx6keWcYw2YHevFFKgJzTX6NmtTC26nv46nOhmeF3iHn8JDa4QrmcwRx3WDXmjMGXAy9DJh1IIfNxvRyy9CybJR+O8lQU/3msj1Pouug== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=M0qIT5s4gL96W/IU/fBPzK8d49BSw9FI6hVHw7bC9pE=; b=y14oTG0DVAB5PXQ8TsiCLoChcTdn2XUo4tne4emyPa9Ppm2XGTOkwQzixS4KKOfkAeGMNttzGTAyXsz+ZKPsd8z32enWgoTAzq/BClDb47nNGbANVEHckRQiBaPwmLdjZzuLKOICSB+aAPl3X/wHGvOptMeVrs1IUxR7NtVJCsw= Received: from DM5PR11MB1753.namprd11.prod.outlook.com (10.175.88.141) by DM5PR11MB1481.namprd11.prod.outlook.com (10.172.36.140) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2686.32; Tue, 4 Feb 2020 06:58:02 +0000 Received: from DM5PR11MB1753.namprd11.prod.outlook.com ([fe80::bcaa:91e6:c27b:b8ff]) by DM5PR11MB1753.namprd11.prod.outlook.com ([fe80::bcaa:91e6:c27b:b8ff%11]) with mapi id 15.20.2686.031; Tue, 4 Feb 2020 06:58:02 +0000 From: "Eric Vyncke (evyncke)" To: tirumal reddy CC: Roman Danyliw , Valery Smyslov , "draft-ietf-dots-architecture@ietf.org" , "dots@ietf.org" , The IESG , "dots-chairs@ietf.org" Thread-Topic: =?utf-8?B?w4lyaWMgVnluY2tlJ3MgTm8gT2JqZWN0aW9uIG9uIGRyYWZ0LWlldGYtZG90?= =?utf-8?Q?s-architecture-16:_(with_COMMENT)?= Thread-Index: AQHV2wkFS+QZC5FdwkW3TOGEDqhA5KgKq5KA Date: Tue, 4 Feb 2020 06:58:02 +0000 Message-ID: References: <158072512768.28459.10822203567819861277.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: fr-BE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.21.0.200113 authentication-results: spf=none (sender IP is ) smtp.mailfrom=evyncke@cisco.com; x-originating-ip: [92.184.117.8] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: c91058b0-d4b0-45cd-d90c-08d7a93f93d6 x-ms-traffictypediagnostic: DM5PR11MB1481: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 03030B9493 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(346002)(396003)(366004)(136003)(39860400002)(376002)(189003)(199004)(53546011)(21615005)(6506007)(2906002)(36756003)(966005)(478600001)(4326008)(33656002)(186003)(8936002)(6486002)(81156014)(316002)(81166006)(54906003)(86362001)(2616005)(6916009)(26005)(5660300002)(66446008)(71200400001)(224303003)(66556008)(66946007)(64756008)(91956017)(6512007)(76116006)(66476007); DIR:OUT; SFP:1101; SCL:1; SRVR:DM5PR11MB1481; H:DM5PR11MB1753.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: IKxZJoDdl+69BHJysfLFps2kFTXn3YG2Mqy9bbNMY82yF0Ma5Q6DwGkD8WJUfU/pociclwM8cHTwopuarJUBqtGHzPJn3dPq/5F1CS8uIaqdYOL2WfDEdYhe7+6LQpJiMi8PSAvOh5F54hVMg7E6hR61oRgPjxakcv7SkKNdodYlabjzcTXPAfZgT+J5DnW6Fcq86D+XgFoaIKDiqHPImJoPgO67lITxfLnYOPPLLRVd+UpEiHBRYivqD2P/eb3p8BxwUGN2iRLCwr4DJfYGhqSx9omTJh+rYuT3kxGTO4fWr+jiLksZ3PIKf5KifJ2oXysi7TM4StRpnP3lBy6IDdvfyIg/pIFVjs2rTJyP7K9rvifVBxWKk7Y7eQKQTnxakS4uWTTIfcl6n/8Uf86Yi71v6lXZLu9Hsbvr1qkv3l0+Utdlen0ICdMfRQhJLR4O2JINfNGFi716pFwx67FOBVHQSNQhOYk3A+Xvf6DEe5nBzeQk1bQRbapmJMlRna+kMOdsn1mVY9GwOoZAwQiGWg== x-ms-exchange-antispam-messagedata: paCCBCm+xGTO4ApskpQuN24absswp6iDfee7kd/ZYsXCR14Ldaa/jqfmMxneJm1rbLdC1xbdEQd9pyea4MUfdUW3rTguPPSD2ngm3wFtYjJacuXE2Ugwm9JT0aRfQ3lQWC2R670C2h0LgTp+9LeUkA== x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_DF09511EC7054E9A8A794B6E40BA774Aciscocom_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: c91058b0-d4b0-45cd-d90c-08d7a93f93d6 X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Feb 2020 06:58:02.3229 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: dOLXxFqJPeHqJrq0TUPIJ1KQ2Vj+d5Z0RJZ0I+uWvhYGZ4lnhlm6xMHdWx7uApFBsc5mH57IyLnWY9/po45WrA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR11MB1481 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.20, xch-rcd-010.cisco.com X-Outbound-Node: alln-core-9.cisco.com Archived-At: Subject: Re: [Dots] =?utf-8?q?=C3=89ric_Vyncke=27s_No_Objection_on_draft-ietf?= =?utf-8?q?-dots-architecture-16=3A_=28with_COMMENT=29?= 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, 04 Feb 2020 06:58:23 -0000 --_000_DF09511EC7054E9A8A794B6E40BA774Aciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGlydSwNCg0KVGhhbmsgeW91IGZvciB0aGUgcHJvbXB0IHJlcGx5Lg0KDQpNeSBjb21tZW50cy9x dWVzdGlvbnMgd2VyZSBub3QgYmxvY2tpbmcgYnV0IEkgYXBwcmVjaWF0ZSB5b3VyIHJlcGx5Lg0K DQpSZWdhcmRzDQoNCi3DqXJpYw0KDQoNCkZyb206IGllc2cgPGllc2ctYm91bmNlc0BpZXRmLm9y Zz4gb24gYmVoYWxmIG9mIHRpcnVtYWwgcmVkZHkgPGtvbmR0aXJAZ21haWwuY29tPg0KRGF0ZTog VHVlc2RheSwgNCBGZWJydWFyeSAyMDIwIGF0IDA0OjEzDQpUbzogRXJpYyBWeW5ja2UgPGV2eW5j a2VAY2lzY28uY29tPg0KQ2M6IFJvbWFuIERhbnlsaXcgPHJkZEBjZXJ0Lm9yZz4sIFZhbGVyeSBT bXlzbG92IDx2YWxlcnlAc215c2xvdi5uZXQ+LCAiZHJhZnQtaWV0Zi1kb3RzLWFyY2hpdGVjdHVy ZUBpZXRmLm9yZyIgPGRyYWZ0LWlldGYtZG90cy1hcmNoaXRlY3R1cmVAaWV0Zi5vcmc+LCAiZG90 c0BpZXRmLm9yZyIgPGRvdHNAaWV0Zi5vcmc+LCBUaGUgSUVTRyA8aWVzZ0BpZXRmLm9yZz4sICJk b3RzLWNoYWlyc0BpZXRmLm9yZyIgPGRvdHMtY2hhaXJzQGlldGYub3JnPg0KU3ViamVjdDogUmU6 IMOJcmljIFZ5bmNrZSdzIE5vIE9iamVjdGlvbiBvbiBkcmFmdC1pZXRmLWRvdHMtYXJjaGl0ZWN0 dXJlLTE2OiAod2l0aCBDT01NRU5UKQ0KDQpIaSBFcmljLA0KDQpUaGFua3MgZm9yIHRoZSByZXZp ZXcuIFBsZWFzZSBzZWUgaW5saW5lDQoNCk9uIE1vbiwgMyBGZWIgMjAyMCBhdCAxNTo0OCwgw4ly aWMgVnluY2tlIHZpYSBEYXRhdHJhY2tlciA8bm9yZXBseUBpZXRmLm9yZzxtYWlsdG86bm9yZXBs eUBpZXRmLm9yZz4+IHdyb3RlOg0Kw4lyaWMgVnluY2tlIGhhcyBlbnRlcmVkIHRoZSBmb2xsb3dp bmcgYmFsbG90IHBvc2l0aW9uIGZvcg0KZHJhZnQtaWV0Zi1kb3RzLWFyY2hpdGVjdHVyZS0xNjog Tm8gT2JqZWN0aW9uDQoNCldoZW4gcmVzcG9uZGluZywgcGxlYXNlIGtlZXAgdGhlIHN1YmplY3Qg bGluZSBpbnRhY3QgYW5kIHJlcGx5IHRvIGFsbA0KZW1haWwgYWRkcmVzc2VzIGluY2x1ZGVkIGlu IHRoZSBUbyBhbmQgQ0MgbGluZXMuIChGZWVsIGZyZWUgdG8gY3V0IHRoaXMNCmludHJvZHVjdG9y eSBwYXJhZ3JhcGgsIGhvd2V2ZXIuKQ0KDQoNClBsZWFzZSByZWZlciB0byBodHRwczovL3d3dy5p ZXRmLm9yZy9pZXNnL3N0YXRlbWVudC9kaXNjdXNzLWNyaXRlcmlhLmh0bWwNCmZvciBtb3JlIGlu Zm9ybWF0aW9uIGFib3V0IElFU0cgRElTQ1VTUyBhbmQgQ09NTUVOVCBwb3NpdGlvbnMuDQoNCg0K VGhlIGRvY3VtZW50LCBhbG9uZyB3aXRoIG90aGVyIGJhbGxvdCBwb3NpdGlvbnMsIGNhbiBiZSBm b3VuZCBoZXJlOg0KaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1k b3RzLWFyY2hpdGVjdHVyZS8NCg0KDQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCkNPTU1FTlQ6DQotLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tDQoNCkRlYXIgYXV0aG9ycywNCg0KVGhhbmsgeW91IGZvciB0aGUgd29yayBwdXQgaW50 byB0aGlzIGRvY3VtZW50LiBBcyBhIHNpZGUgbm90ZSwgSSByZWFsbHkgbGlrZWQNCnRoZSBzZWN0 aW9uIGFib3V0IHRoZSBtYW51YWwvb3Zlci10aGUtcGhvbmUgcGFydCBvZiBpdC4NCg0KVW50aWwg bm93LCBJIGhhdmUgcmVhZCBvbmx5IHRoaXMgZG9jdW1lbnQgKGRvdHMtYXJjaGl0ZWN0dXJlKSBm cm9tIHRoZSBkb3RzIFdHLA0Kc28sIHBsZWFzZSBhY2NlcHQgbXkgaWdub3JhbmNlIGZvciBkZXRh aWxzLiBCdXQsIEkgaGF2ZSBhIGNvdXBsZSBvZg0Kbm9uLWJsb2NraW5nIHF1ZXN0aW9ucyB3aGVy ZSB5b3VyIHJlcGx5IHdpbGwgYmUgd2VsY29tZSBhbmQgYXBwcmVjaWF0ZWQ6DQoNClExKSBpcyB0 aGUgbW9uZXRhcnkgY29zdCBwYXJ0IG9mIHRoZSBET1RTIHNpZ25hbGluZyA/IChJLmUuLCB0aGUg bWl0aWdhdG9yDQp0ZWxsaW5nIHRoZSB0YXJnZXQgdGhhdCBpdCB3aWxsIGNvc3Qgc28gbWFueSBF VVIgcGVyIGhvdXIpDQoNCk5vLCBtb25ldGFyeSBjb3N0IGlzIG5vdCBwYXJ0IG9mIHRoZSBET1RT IHNpZ25hbGluZy4NCg0KDQpRMikgVXNpbmcgRE9UUyBpbiBhbiB1bmRlci1hdHRhY2sgbmV0d29y aywgZGlkIHlvdSBjb25zaWRlciByZWNvbW1lbmRpbmcNCmR1YWwtc3RhY2sgc2lnbmFsaW5nIHRv IGNvcGUgd2l0aCB0aGUgcmFyZSBjYXNlIHdoZXJlIElQdjQgaXMgZGlzcnVwdGVkIHdoaWxlDQpJ UHY2IHN0aWxsIHdvcmtzIChvZiBjb3Vyc2UgaWYgdGhlIERvUyBpcyBwbGFpbiBmbG9vZGluZyB0 aGlzIHdvbid0IGhlbHAgYSBsb3QNCnByb2JhYmx5OyBhbmQgdGhlIGR1YWwgcHJvcG9zaXRpb24g ZXhpc3RzKS4NCg0KWWVzLCBIYXBweSBFeWViYWxscyBmb3IgRE9UUyBzaWduYWwgY2hhbm5lbCBp cyBkaXNjdXNzZWQgaW4gaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtZG90 cy1zaWduYWwtY2hhbm5lbC00MSNzZWN0aW9uLTQuMw0KDQoNClEzKSBXaGlsZSBJIGFwcHJlY2lh dGUgdGhlIHZhbHVlIG9mIEFueWNhc3QgRE9UUyBzZXJ2ZXIsIGhlbmNlIFVEUCBpcyBtb3N0bHkN CnJlcXVpcmVkIGZvciBzaWduYWxpbmcgdHJhbnNwb3J0LCBJIHdvbmRlciB3aGV0aGVyIHRoZSBj aG9pY2Ugb2YgVURQIChvZnRlbg0KdXNlZCBBRkFJSyBhcyB2b2x1bWV0cmljIGF0dGFjayBhcyBp dCBpcyBlYXNpZXIgdG8gc3Bvb2YpIGlzIGEgZ29vZCBjaG9pY2UNCmNvbXBhcmVkIHRvIFRDUCBv ciBEU0NQIG9yIC4uLg0KDQpCb3RoIERUTFMgb3ZlciBVRFAgYW5kIFRMUyBvdmVyIFRDUCBpcyB1 c2VkIGJ5IHRoZSBET1RTIHNpZ25hbCBjaGFubmVsIChVRFAgaXMgZ2l2ZW4gaGlnaGVyIHByZWNl ZGVuY2UgdGhhbiBUQ1ApLg0KRFRMUyBpcyBjYXBhYmxlIG9mIGRlZmVuZGluZyBhZ2FpbnN0IERv UyBhdHRhY2sgYnkgdXNpbmcgdGhlIHN0YXRlbGVzcyBjb29raWUgbWVjaGFuaXNtIChzZWUgaHR0 cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzYzNDcjc2VjdGlvbi00LjIuMSkNCg0KDQpRNCkg V2hlbiBoYXZpbmcgbXVsdGlwbGUgRE9UUyBzZXJ2ZXJzLCBJIGFzc3VtZSB0aGF0IHRoZSBjYXNl IG9mIGEgZHVhbC1zdGFjaw0KRE9UUyBzZXJ2ZXIgaXMgYWxzbyBjb3ZlcmVkLiBUaGVyZWZvcmUs IGEgd29yZCBvbiB3aGV0aGVyIEhhcHB5IEV5ZWJhbGwgKFJGQw0KODMwNSkgc2hvdWxkIHByb2Jh Ymx5IGJlIHVzZWZ1bCAqKklGKiogYXBwbGljYWJsZQ0KDQpIYXBweSBFeWViYWxsIGlzIGRpc2N1 c3NlZCBpbiBkZXRhaWwgaW4gdGhlIERPVFMgc2lnbmFsIGNoYW5uZWwgcHJvdG9jb2wgc3BlY2lm aWNhdGlvbi4NCg0KQ2hlZXJzLA0KLVRpcnUNCg0KDQpSZWdhcmRzDQoNCi3DqXJpYw0KDQpSZWdh cmRzLA0KDQotw6lyaWMNCg0K --_000_DF09511EC7054E9A8A794B6E40BA774Aciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3Jt YWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1i b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpz cGFuLkVtYWlsU3R5bGUxOA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250 LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCi5Nc29D aHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4w cHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdp bjo3Mi4wcHQgNzIuMHB0IDcyLjBwdCA3Mi4wcHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdl OldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iZW4tQkUi IGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5UaXJ1LDxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1VUyI+VGhhbmsgeW91IGZvciB0aGUgcHJvbXB0IHJlcGx5LiA8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t VVMiPk15IGNvbW1lbnRzL3F1ZXN0aW9ucyB3ZXJlIG5vdCBibG9ja2luZyBidXQgSSBhcHByZWNp YXRlIHlvdXIgcmVwbHkuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5SZWdhcmRzPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LVVTIj4tw6lyaWM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9u ZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBj bSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48Yj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjpibGFjayI+RnJvbToNCjwvc3Bhbj48 L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPmllc2cgJmx0O2ll c2ctYm91bmNlc0BpZXRmLm9yZyZndDsgb24gYmVoYWxmIG9mIHRpcnVtYWwgcmVkZHkgJmx0O2tv bmR0aXJAZ21haWwuY29tJmd0Ozxicj4NCjxiPkRhdGU6IDwvYj5UdWVzZGF5LCA0IEZlYnJ1YXJ5 IDIwMjAgYXQgMDQ6MTM8YnI+DQo8Yj5UbzogPC9iPkVyaWMgVnluY2tlICZsdDtldnluY2tlQGNp c2NvLmNvbSZndDs8YnI+DQo8Yj5DYzogPC9iPlJvbWFuIERhbnlsaXcgJmx0O3JkZEBjZXJ0Lm9y ZyZndDssIFZhbGVyeSBTbXlzbG92ICZsdDt2YWxlcnlAc215c2xvdi5uZXQmZ3Q7LCAmcXVvdDtk cmFmdC1pZXRmLWRvdHMtYXJjaGl0ZWN0dXJlQGlldGYub3JnJnF1b3Q7ICZsdDtkcmFmdC1pZXRm LWRvdHMtYXJjaGl0ZWN0dXJlQGlldGYub3JnJmd0OywgJnF1b3Q7ZG90c0BpZXRmLm9yZyZxdW90 OyAmbHQ7ZG90c0BpZXRmLm9yZyZndDssIFRoZSBJRVNHICZsdDtpZXNnQGlldGYub3JnJmd0Oywg JnF1b3Q7ZG90cy1jaGFpcnNAaWV0Zi5vcmcmcXVvdDsgJmx0O2RvdHMtY2hhaXJzQGlldGYub3Jn Jmd0Ozxicj4NCjxiPlN1YmplY3Q6IDwvYj5SZTogw4lyaWMgVnluY2tlJ3MgTm8gT2JqZWN0aW9u IG9uIGRyYWZ0LWlldGYtZG90cy1hcmNoaXRlY3R1cmUtMTY6ICh3aXRoIENPTU1FTlQpPG86cD48 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBw dCI+SGkgRXJpYyw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2 LjBwdCI+VGhhbmtzIGZvciB0aGUgcmV2aWV3LiBQbGVhc2Ugc2VlIGlubGluZTxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYu MHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+T24gTW9uLCAzIEZlYiAyMDIwIGF0IDE1 OjQ4LCDDiXJpYyBWeW5ja2UgdmlhIERhdGF0cmFja2VyICZsdDs8YSBocmVmPSJtYWlsdG86bm9y ZXBseUBpZXRmLm9yZyI+bm9yZXBseUBpZXRmLm9yZzwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6 c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0 OjQuOHB0O21hcmdpbi1yaWdodDowY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1h cmdpbi1sZWZ0OjM2LjBwdCI+w4lyaWMgVnluY2tlIGhhcyBlbnRlcmVkIHRoZSBmb2xsb3dpbmcg YmFsbG90IHBvc2l0aW9uIGZvcjxicj4NCmRyYWZ0LWlldGYtZG90cy1hcmNoaXRlY3R1cmUtMTY6 IE5vIE9iamVjdGlvbjxicj4NCjxicj4NCldoZW4gcmVzcG9uZGluZywgcGxlYXNlIGtlZXAgdGhl IHN1YmplY3QgbGluZSBpbnRhY3QgYW5kIHJlcGx5IHRvIGFsbDxicj4NCmVtYWlsIGFkZHJlc3Nl cyBpbmNsdWRlZCBpbiB0aGUgVG8gYW5kIENDIGxpbmVzLiAoRmVlbCBmcmVlIHRvIGN1dCB0aGlz PGJyPg0KaW50cm9kdWN0b3J5IHBhcmFncmFwaCwgaG93ZXZlci4pPGJyPg0KPGJyPg0KPGJyPg0K UGxlYXNlIHJlZmVyIHRvIDxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL2llc2cvc3RhdGVt ZW50L2Rpc2N1c3MtY3JpdGVyaWEuaHRtbCIgdGFyZ2V0PSJfYmxhbmsiPg0KaHR0cHM6Ly93d3cu aWV0Zi5vcmcvaWVzZy9zdGF0ZW1lbnQvZGlzY3Vzcy1jcml0ZXJpYS5odG1sPC9hPjxicj4NCmZv ciBtb3JlIGluZm9ybWF0aW9uIGFib3V0IElFU0cgRElTQ1VTUyBhbmQgQ09NTUVOVCBwb3NpdGlv bnMuPGJyPg0KPGJyPg0KPGJyPg0KVGhlIGRvY3VtZW50LCBhbG9uZyB3aXRoIG90aGVyIGJhbGxv dCBwb3NpdGlvbnMsIGNhbiBiZSBmb3VuZCBoZXJlOjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vZGF0 YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtZG90cy1hcmNoaXRlY3R1cmUvIiB0YXJn ZXQ9Il9ibGFuayI+aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1k b3RzLWFyY2hpdGVjdHVyZS88L2E+PGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LTxicj4NCkNPTU1FTlQ6PGJyPg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLTxicj4NCjxicj4NCkRlYXIgYXV0aG9y cyw8YnI+DQo8YnI+DQpUaGFuayB5b3UgZm9yIHRoZSB3b3JrIHB1dCBpbnRvIHRoaXMgZG9jdW1l bnQuIEFzIGEgc2lkZSBub3RlLCBJIHJlYWxseSBsaWtlZDxicj4NCnRoZSBzZWN0aW9uIGFib3V0 IHRoZSBtYW51YWwvb3Zlci10aGUtcGhvbmUgcGFydCBvZiBpdC48YnI+DQo8YnI+DQpVbnRpbCBu b3csIEkgaGF2ZSByZWFkIG9ubHkgdGhpcyBkb2N1bWVudCAoZG90cy1hcmNoaXRlY3R1cmUpIGZy b20gdGhlIGRvdHMgV0csPGJyPg0Kc28sIHBsZWFzZSBhY2NlcHQgbXkgaWdub3JhbmNlIGZvciBk ZXRhaWxzLiBCdXQsIEkgaGF2ZSBhIGNvdXBsZSBvZjxicj4NCm5vbi1ibG9ja2luZyBxdWVzdGlv bnMgd2hlcmUgeW91ciByZXBseSB3aWxsIGJlIHdlbGNvbWUgYW5kIGFwcHJlY2lhdGVkOjxicj4N Cjxicj4NClExKSBpcyB0aGUgbW9uZXRhcnkgY29zdCBwYXJ0IG9mIHRoZSBET1RTIHNpZ25hbGlu ZyA/IChJLmUuLCB0aGUgbWl0aWdhdG9yPGJyPg0KdGVsbGluZyB0aGUgdGFyZ2V0IHRoYXQgaXQg d2lsbCBjb3N0IHNvIG1hbnkgRVVSIHBlciBob3VyKTxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1 b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4w cHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+Tm8sIG1vbmV0YXJ5IGNvc3QgaXMgbm90 IHBhcnQgb2YgdGhlIERPVFMgc2lnbmFsaW5nLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+Jm5ic3A7 PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTti b3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7 bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48YnI+DQpRMikgVXNpbmcgRE9UUyBpbiBhbiB1 bmRlci1hdHRhY2sgbmV0d29yaywgZGlkIHlvdSBjb25zaWRlciByZWNvbW1lbmRpbmc8YnI+DQpk dWFsLXN0YWNrIHNpZ25hbGluZyB0byBjb3BlIHdpdGggdGhlIHJhcmUgY2FzZSB3aGVyZSBJUHY0 IGlzIGRpc3J1cHRlZCB3aGlsZTxicj4NCklQdjYgc3RpbGwgd29ya3MgKG9mIGNvdXJzZSBpZiB0 aGUgRG9TIGlzIHBsYWluIGZsb29kaW5nIHRoaXMgd29uJ3QgaGVscCBhIGxvdDxicj4NCnByb2Jh Ymx5OyBhbmQgdGhlIGR1YWwgcHJvcG9zaXRpb24gZXhpc3RzKS48bzpwPjwvbzpwPjwvcD4NCjwv YmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxl ZnQ6MzYuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPlllcywgSGFwcHkgRXllYmFs bHMgZm9yIERPVFMgc2lnbmFsIGNoYW5uZWwgaXMgZGlzY3Vzc2VkIGluJm5ic3A7PGEgaHJlZj0i aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtZG90cy1zaWduYWwtY2hhbm5l bC00MSNzZWN0aW9uLTQuMyI+aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYt ZG90cy1zaWduYWwtY2hhbm5lbC00MSNzZWN0aW9uLTQuMzwvYT48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4w cHQiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9y ZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAwY20g MGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowY20iPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PGJyPg0KUTMpIFdoaWxlIEkg YXBwcmVjaWF0ZSB0aGUgdmFsdWUgb2YgQW55Y2FzdCBET1RTIHNlcnZlciwgaGVuY2UgVURQIGlz IG1vc3RseTxicj4NCnJlcXVpcmVkIGZvciBzaWduYWxpbmcgdHJhbnNwb3J0LCBJIHdvbmRlciB3 aGV0aGVyIHRoZSBjaG9pY2Ugb2YgVURQIChvZnRlbjxicj4NCnVzZWQgQUZBSUsgYXMgdm9sdW1l dHJpYyBhdHRhY2sgYXMgaXQgaXMgZWFzaWVyIHRvIHNwb29mKSBpcyBhIGdvb2QgY2hvaWNlPGJy Pg0KY29tcGFyZWQgdG8gVENQIG9yIERTQ1Agb3IgLi4uPG86cD48L286cD48L3A+DQo8L2Jsb2Nr cXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2 LjBwdCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij5Cb3RoIERUTFMgb3ZlciBVRFAgYW5k IFRMUyBvdmVyIFRDUCBpcyB1c2VkIGJ5IHRoZSBET1RTIHNpZ25hbCBjaGFubmVsIChVRFAgaXMg Z2l2ZW4gaGlnaGVyIHByZWNlZGVuY2UgdGhhbiBUQ1ApLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+ RFRMUyBpcyBjYXBhYmxlIG9mIGRlZmVuZGluZyBhZ2FpbnN0IERvUyBhdHRhY2sgYnkgdXNpbmcg dGhlIHN0YXRlbGVzcyBjb29raWUgbWVjaGFuaXNtIChzZWUmbmJzcDs8YSBocmVmPSJodHRwczov L3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNjM0NyNzZWN0aW9uLTQuMi4xIj5odHRwczovL3Rvb2xz LmlldGYub3JnL2h0bWwvcmZjNjM0NyNzZWN0aW9uLTQuMi4xPC9hPikmbmJzcDs8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4t bGVmdDozNi4wcHQiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBz dHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5n OjBjbSAwY20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowY20iPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PGJyPg0KUTQp IFdoZW4gaGF2aW5nIG11bHRpcGxlIERPVFMgc2VydmVycywgSSBhc3N1bWUgdGhhdCB0aGUgY2Fz ZSBvZiBhIGR1YWwtc3RhY2s8YnI+DQpET1RTIHNlcnZlciBpcyBhbHNvIGNvdmVyZWQuIFRoZXJl Zm9yZSwgYSB3b3JkIG9uIHdoZXRoZXIgSGFwcHkgRXllYmFsbCAoUkZDPGJyPg0KODMwNSkgc2hv dWxkIHByb2JhYmx5IGJlIHVzZWZ1bCAqKklGKiogYXBwbGljYWJsZTxvOnA+PC9vOnA+PC9wPg0K PC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4t bGVmdDozNi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+SGFwcHkgRXllYmFsbCBp cyBkaXNjdXNzZWQgaW4gZGV0YWlsIGluIHRoZSBET1RTIHNpZ25hbCBjaGFubmVsIHByb3RvY29s IHNwZWNpZmljYXRpb24uPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVm dDozNi4wcHQiPkNoZWVycyw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPi1UaXJ1PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxl ZnQ6MzYuMHB0Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5 bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzow Y20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGNtIj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6MGNtO21hcmdpbi1y aWdodDowY207bWFyZ2luLWJvdHRvbToxMi4wcHQ7bWFyZ2luLWxlZnQ6MzYuMHB0Ij4NCjxicj4N ClJlZ2FyZHM8YnI+DQo8YnI+DQotw6lyaWM8YnI+DQo8YnI+DQpSZWdhcmRzLDxicj4NCjxicj4N Ci3DqXJpYzxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_DF09511EC7054E9A8A794B6E40BA774Aciscocom_-- From nobody Tue Feb 4 16:23:55 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 D4F7B120152; Tue, 4 Feb 2020 16:23:51 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Adam Roach via Datatracker To: "The IESG" Cc: draft-ietf-dots-architecture@ietf.org, Roman Danyliw , Valery Smyslov , dots-chairs@ietf.org, valery@smyslov.net, dots@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.116.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Adam Roach Message-ID: <158086223186.15730.8548298399281753843.idtracker@ietfa.amsl.com> Date: Tue, 04 Feb 2020 16:23:51 -0800 Archived-At: Subject: [Dots] Adam Roach's No Objection on draft-ietf-dots-architecture-16: (with COMMENT) 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, 05 Feb 2020 00:23:52 -0000 Adam Roach has entered the following ballot position for draft-ietf-dots-architecture-16: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-dots-architecture/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for the work that went into creating this architecture document. I found it a useful introduction to DOTS. --------------------------------------------------------------------------- §3.2.5: Without needing to go into too much detail, it seems that this section would benefit from citations to RFC 6886, RFC 7659, and ISO/IEC 29341-1-2:2017 as alternate means to learn about NAT mappings. From nobody Tue Feb 4 19:25:05 2020 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA90D1201A3 for ; Tue, 4 Feb 2020 19:25:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable 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 PVf86kMP12Qr for ; Tue, 4 Feb 2020 19:25:02 -0800 (PST) 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 6910812001A for ; Tue, 4 Feb 2020 19:25:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mcafee.com; s=mimecast20190606; t=1580873101; h=from:from: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=Nv8TpojJ2k+02EmJmwEeXpFDZT4fOtESRQooCQd/ZTw=; b=M6p6vXv2wgeJPx0O4XkMgNqxb6CL54JzTxZ5OVyccszI6r3WC4/uEErzkURsThj5k1xNi2 TSeUohjsElOgFP0yAZ9e0Awu5zNaLZm+P+0ty56kmc3eSXSUPFtMBfTDLSQqLRra+IT1xn nuRzeXtaOFcIye3nk76H1FQ7Z4+n6YU= Received: from NAM10-BN7-obe.outbound.protection.outlook.com (mail-bn7nam10lp2105.outbound.protection.outlook.com [104.47.70.105]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-402-6N1PnPOOPZq6AmmtJVnTaw-1; Tue, 04 Feb 2020 22:22:58 -0500 Received: from CY4PR1601MB1254.namprd16.prod.outlook.com (10.172.118.12) by CY4PR1601MB1141.namprd16.prod.outlook.com (10.172.117.15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2686.28; Wed, 5 Feb 2020 03:22:56 +0000 Received: from CY4PR1601MB1254.namprd16.prod.outlook.com ([fe80::e851:20e8:57bd:fedd]) by CY4PR1601MB1254.namprd16.prod.outlook.com ([fe80::e851:20e8:57bd:fedd%12]) with mapi id 15.20.2686.034; Wed, 5 Feb 2020 03:22:56 +0000 From: "Konda, Tirumaleswar Reddy" To: Adam Roach , The IESG CC: Roman Danyliw , "dots-chairs@ietf.org" , "valery@smyslov.net" , "dots@ietf.org" , "draft-ietf-dots-architecture@ietf.org" Thread-Topic: [Dots] Adam Roach's No Objection on draft-ietf-dots-architecture-16: (with COMMENT) Thread-Index: AQHV27qRhnwa8U/3mU+jIaT0c/tf6KgL6Iaw Date: Wed, 5 Feb 2020 03:22:56 +0000 Message-ID: References: <158086223186.15730.8548298399281753843.idtracker@ietfa.amsl.com> In-Reply-To: <158086223186.15730.8548298399281753843.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-version: 11.4.0.45 dlp-reaction: no-action x-originating-ip: [49.37.206.28] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 593382ea-f862-4c3e-515a-08d7a9eab1e4 x-ms-traffictypediagnostic: CY4PR1601MB1141: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8882; x-forefront-prvs: 0304E36CA3 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(366004)(39860400002)(396003)(136003)(346002)(376002)(32952001)(189003)(199004)(6506007)(52536014)(86362001)(186003)(53546011)(2906002)(81166006)(81156014)(8936002)(76116006)(66556008)(66446008)(26005)(33656002)(66946007)(8676002)(64756008)(66476007)(966005)(4326008)(478600001)(71200400001)(7696005)(316002)(54906003)(110136005)(9686003)(5660300002)(55016002)(85282002); DIR:OUT; SFP:1101; SCL:1; SRVR:CY4PR1601MB1141; H:CY4PR1601MB1254.namprd16.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: pqEA6LwwIDIWCi1dMfrBkHapd02f1lRdwMu4B8IX4Gb21FzyYKedfNFVuivfEgL95MR+QXWNSpI7l+khgUD3YL8MSFb2G34lRcWDIn7jtfRgv25FyP26//sgSovymX0J8hLbMnbCpOfc1JiGrn33bvwgooAiCh858LQfZKuJUoQ4RaOgzcL6/Ob2ke4cbYFFD3Gt1w18J7I5i+RK3LXqykussrz7JE1/gCsoFB4zFNdnhR8lt13eajKg6OIQTDTekjKTraIO5Qr6I5vfB0gvUxvS9KnhMAU4Znk+O5Kj6jgcq1hsa7cPwCznS54g6SRMfE20CVd1y8aKGUBpBMoHYS6JJYsFzkSNmKnoyjYLE4ntVqINmeXhnktq1CEMUn2/YvQoKw44gcwpUVpNG/MhmC9xPgcXjgJSq7f6p6dcBi9OWJKUMpM/cTFQqBLgLOA8zKGTAT1CNhCTUfgM8uXLhzMwy6Q+FayOeGIkwwqd4d+Ic1TvBIcb+b95T+ekSnwX+/zIrwKZZHZl3AW0oIqEoTQQE1NPiNAqbKNWSCz7N2Lvv6WUZEFJirwRXj/WGqQSNKUnF+vSxMWF6V68iLWv1eaRWcS1BnA3Tc4728WxtHo= x-ms-exchange-antispam-messagedata: 4tHboU3Se9JR3ZOd4EBY0ZrbF7SVVl6kD7HtMsIRTFyDrxeIzBemVmSbzmhFs0q72Y/VJTv5c6aGKCuoQzBycwstCkVCgozhvAk5XBLxI2ViapHMkVjAACn4U1jOOlITm5+R9ZU9SdMaTikA5qH9VQ== x-ms-exchange-transport-forked: True MIME-Version: 1.0 X-OriginatorOrg: mcafee.com X-MS-Exchange-CrossTenant-Network-Message-Id: 593382ea-f862-4c3e-515a-08d7a9eab1e4 X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Feb 2020 03:22:56.7406 (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: FAEKG7Zi672OIUV9M1U8s87+ZLctPvYG9Zf4qoJDEw71/Brzp3vx0U4bR6I1d2NRU0Xwm662aWRQvaQCjCdJDhVX1/i+aSvQcdKfyuB8+Km37hkFMLMGaG4d1dwYgRxU X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR1601MB1141 X-MC-Unique: 6N1PnPOOPZq6AmmtJVnTaw-1 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] Adam Roach's No Objection on draft-ietf-dots-architecture-16: (with COMMENT) 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, 05 Feb 2020 03:25:04 -0000 SGkgQWRhbSwNCg0KVGhhbmtzIGZvciB0aGUgcmV2aWV3LiBQbGVhc2Ugc2VlIGlubGluZSANCg0K PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBEb3RzIDxkb3RzLWJvdW5jZXNA aWV0Zi5vcmc+IE9uIEJlaGFsZiBPZiBBZGFtIFJvYWNoIHZpYQ0KPiBEYXRhdHJhY2tlcg0KPiBT ZW50OiBXZWRuZXNkYXksIEZlYnJ1YXJ5IDUsIDIwMjAgNTo1NCBBTQ0KPiBUbzogVGhlIElFU0cg PGllc2dAaWV0Zi5vcmc+DQo+IENjOiBSb21hbiBEYW55bGl3IDxyZGRAY2VydC5vcmc+OyBkb3Rz LWNoYWlyc0BpZXRmLm9yZzsNCj4gdmFsZXJ5QHNteXNsb3YubmV0OyBkb3RzQGlldGYub3JnOyBk cmFmdC1pZXRmLWRvdHMtYXJjaGl0ZWN0dXJlQGlldGYub3JnDQo+IFN1YmplY3Q6IFtEb3RzXSBB ZGFtIFJvYWNoJ3MgTm8gT2JqZWN0aW9uIG9uIGRyYWZ0LWlldGYtZG90cy1hcmNoaXRlY3R1cmUt DQo+IDE2OiAod2l0aCBDT01NRU5UKQ0KPiANCj4gQ0FVVElPTjogRXh0ZXJuYWwgZW1haWwuIERv IG5vdCBjbGljayBsaW5rcyBvciBvcGVuIGF0dGFjaG1lbnRzIHVubGVzcyB5b3UNCj4gcmVjb2du aXplIHRoZSBzZW5kZXIgYW5kIGtub3cgdGhlIGNvbnRlbnQgaXMgc2FmZS4NCj4gDQo+IEFkYW0g Um9hY2ggaGFzIGVudGVyZWQgdGhlIGZvbGxvd2luZyBiYWxsb3QgcG9zaXRpb24gZm9yDQo+IGRy YWZ0LWlldGYtZG90cy1hcmNoaXRlY3R1cmUtMTY6IE5vIE9iamVjdGlvbg0KPiANCj4gV2hlbiBy ZXNwb25kaW5nLCBwbGVhc2Uga2VlcCB0aGUgc3ViamVjdCBsaW5lIGludGFjdCBhbmQgcmVwbHkg dG8gYWxsIGVtYWlsDQo+IGFkZHJlc3NlcyBpbmNsdWRlZCBpbiB0aGUgVG8gYW5kIENDIGxpbmVz LiAoRmVlbCBmcmVlIHRvIGN1dCB0aGlzIGludHJvZHVjdG9yeQ0KPiBwYXJhZ3JhcGgsIGhvd2V2 ZXIuKQ0KPiANCj4gDQo+IFBsZWFzZSByZWZlciB0byBodHRwczovL3d3dy5pZXRmLm9yZy9pZXNn L3N0YXRlbWVudC9kaXNjdXNzLWNyaXRlcmlhLmh0bWwNCj4gZm9yIG1vcmUgaW5mb3JtYXRpb24g YWJvdXQgSUVTRyBESVNDVVNTIGFuZCBDT01NRU5UIHBvc2l0aW9ucy4NCj4gDQo+IA0KPiBUaGUg ZG9jdW1lbnQsIGFsb25nIHdpdGggb3RoZXIgYmFsbG90IHBvc2l0aW9ucywgY2FuIGJlIGZvdW5k IGhlcmU6DQo+IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtZG90 cy1hcmNoaXRlY3R1cmUvDQo+IA0KPiANCj4gDQo+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gQ09NTUVOVDoN Cj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLQ0KPiANCj4gVGhhbmtzIGZvciB0aGUgd29yayB0aGF0IHdlbnQgaW50 byBjcmVhdGluZyB0aGlzIGFyY2hpdGVjdHVyZSBkb2N1bWVudC4NCj4gSSBmb3VuZCBpdCBhIHVz ZWZ1bCBpbnRyb2R1Y3Rpb24gdG8gRE9UUy4NCj4gDQo+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiAN Cj4gwqczLjIuNToNCj4gDQo+IFdpdGhvdXQgbmVlZGluZyB0byBnbyBpbnRvIHRvbyBtdWNoIGRl dGFpbCwgaXQgc2VlbXMgdGhhdCB0aGlzIHNlY3Rpb24gd291bGQNCj4gYmVuZWZpdCBmcm9tIGNp dGF0aW9ucyB0byBSRkMgNjg4NiwgUkZDIDc2NTksIGFuZCBJU08vSUVDIDI5MzQxLTEtMjoyMDE3 IGFzDQo+IGFsdGVybmF0ZSBtZWFucyB0byBsZWFybiBhYm91dCBOQVQgbWFwcGluZ3MuDQoNClBD UCBzdWNjZWVkcyBOQVQtUE1QIChzZWUgaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzY4 ODYjc2VjdGlvbi0xLjEpLiAgRE9UUyBjbGllbnRzIG9ubHkgbmVlZCBsZWFybiB0aGVpciBleHRl cm5hbCBJUCBhZGRyZXNzL3BvcnQgZG9uJ3QgaGF2ZSB0byB1c2UgTkFUIE1JQiAoUkZDNzY1OSku IElTTy9JRUMgMjkzNDEtMS0yOjIwMTcgZGlzY3Vzc2VzIHVQblAsIGl0IGRvZXMgbm90IHdvcmsg d2l0aCBtdWx0aXBsZSBOQVRzIChQQ1Agd29ya3Mgd2l0aCBOQVRzIG9uIHRoZSBwYXRoKS4gIFRo ZSBkb2N1bWVudCByZWZlcnMgdG8gU1RVTiBhbmQgUENQIGJvdGggd2lkZWx5IGFkb3B0ZWQgYnkg dGhlIEluZHVzdHJ5Lg0KDQpDaGVlcnMsDQotVGlydQ0KDQo+IA0KPiANCj4gX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gRG90cyBtYWlsaW5nIGxpc3QN Cj4gRG90c0BpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L2RvdHMNCg0K From nobody Tue Feb 4 22:59: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 86F751201DB for ; Tue, 4 Feb 2020 22:59:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 ShYa8vNaqy9G for ; Tue, 4 Feb 2020 22:59:03 -0800 (PST) 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 79E36120045 for ; Tue, 4 Feb 2020 22:59:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mcafee.com; s=mimecast20190606; t=1580885942; 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=+JK1HhlRSu9VLSwTDESORZpYybfId8BcT4A7AYdQsOY=; b=Ih1weFVEqaQzzYgz2KWA1c2TmSeblIbA+VoAe4HHhQ9wVXYNSXZomYcyn+J+KVO090ZXm0 oG17Of4zQwH83eQdT8HKdQpNT/G1X+/xjF24JpOC6VTbBkq6IMceyzNfyAOGLidJPTaiMo bXSbQ5AAVfZfMSxCVNo0NoNJsnK9IxU= Received: from NAM12-BN8-obe.outbound.protection.outlook.com (mail-bn8nam12lp2175.outbound.protection.outlook.com [104.47.55.175]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-61-MJPAPjs5NwO7BXuId4O5vw-1; Wed, 05 Feb 2020 01:58:45 -0500 Received: from CY4PR1601MB1254.namprd16.prod.outlook.com (10.172.118.12) by CY4PR1601MB1110.namprd16.prod.outlook.com (10.172.116.139) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2686.32; Wed, 5 Feb 2020 06:58:43 +0000 Received: from CY4PR1601MB1254.namprd16.prod.outlook.com ([fe80::e851:20e8:57bd:fedd]) by CY4PR1601MB1254.namprd16.prod.outlook.com ([fe80::e851:20e8:57bd:fedd%12]) with mapi id 15.20.2686.034; Wed, 5 Feb 2020 06:58:43 +0000 From: "Konda, Tirumaleswar Reddy" To: "mohamed.boucadair@orange.com" , "Jon Shallow (supjps-ietf@jpshallow.com)" , "dots@ietf.org" Thread-Topic: [Dots] I-D Action: draft-ietf-dots-telemetry-01.txt Thread-Index: AQHV2EX1YQ9eUkWY2E+gQ7j9EgylIKgE4pYAgARXvICAAvfD0A== Date: Wed, 5 Feb 2020 06:58:42 +0000 Message-ID: References: <158048229416.21195.16114328651657501634@ietfa.amsl.com> <787AE7BB302AE849A7480A190F8B93303141473A@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B933031414F55@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> In-Reply-To: <787AE7BB302AE849A7480A190F8B933031414F55@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-version: 11.4.0.45 dlp-reaction: no-action x-originating-ip: [49.37.206.28] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 17c6e0fd-8581-4cff-3efc-08d7aa08d689 x-ms-traffictypediagnostic: CY4PR1601MB1110: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 0304E36CA3 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(366004)(376002)(136003)(346002)(396003)(39860400002)(189003)(199004)(32952001)(2906002)(52536014)(86362001)(64756008)(66446008)(9686003)(66556008)(478600001)(966005)(55016002)(66476007)(8676002)(66574012)(6506007)(8936002)(81156014)(81166006)(66946007)(76116006)(5660300002)(53546011)(71200400001)(186003)(316002)(110136005)(33656002)(26005)(7696005)(85282002); DIR:OUT; SFP:1101; SCL:1; SRVR:CY4PR1601MB1110; H:CY4PR1601MB1254.namprd16.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 6MNfZ/RAt7dBb3DUpePPMPR3zkqT0NYEc7f3ySWERaisFZSGjgyomqcrKZRhNUHdPMQ1W5hIP+JbLIDiEO86S/Kf6L85SSlRMzyXleH1t8pgiBa4SqTcldnrFaj9qXvdCK+lFmNYfP8s4RK4cI/qrACkMCI8iTe1jsE24e8dhtSL98Y7PMqe4d24ttP/QXl9ZAqh13pdCUeWgWYEVANFswMOtTWLpOb274ixxAgJ5JfS9h0PXs7d5Bvy6A3pxf9St53oFD1QdjSR39yYunn6GFVYaLuIrqzIjgHU3xAMFv0mi1wYQfE8s56frE0NG/KSIzALCb0FykQ42tS8drOK0nYqToqALJiBM7EIjWWLgV2dHvRGzsyEh2DIAOcTKJKK65gsPgAszbf0M20xmSKMFmvVObdlMILB/ib+zWa0rYBFhOKdNkqbjlUw264yKmmRmZNGi/TMwEv4slU8czNCpCZEuoKkA81Xck0ceZygDWnfSIvAjSAqTh1ibleFwkWTYP4AGSCoLnzoYJEgvID/NS9H8RdZWV9I0UY8qjwzUlYBbIeIJDDWTdPIplS1hBevc1m/+i8PohBQjTkt4bir959B+PteQuA1ym+qSQ4WaN8= x-ms-exchange-antispam-messagedata: wYxYWAEo4MEETFek+rIs+uTSoRapeyTWNzjmlCS5T5O5IvCm0ixLA4C98oIyCBduC0GLDUURRiC0KxsPCbb+vKwgB/Qr/feof6hQ80TNoKsdpuUZcOUfVLCstoGqYTYNUvYu9EwdHkE3EyQjwAblEQ== x-ms-exchange-transport-forked: True MIME-Version: 1.0 X-OriginatorOrg: mcafee.com X-MS-Exchange-CrossTenant-Network-Message-Id: 17c6e0fd-8581-4cff-3efc-08d7aa08d689 X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Feb 2020 06:58:43.1094 (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: nONIGqEaMCI18IijDDng0YecB+cD5s8fqmQjMasA8HALq1CabXV4+Xtx96GW4/val3F4o4vHb3lYDv+6kE71Di5uChkDArl+1p2nqRqEtT7K+cah7Cksf2kcrCBQ450D X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR1601MB1110 X-MC-Unique: MJPAPjs5NwO7BXuId4O5vw-1 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: mcafee.com Content-Type: text/plain; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Dots] I-D Action: draft-ietf-dots-telemetry-01.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, 05 Feb 2020 06:59:10 -0000 X-List-Received-Date: Wed, 05 Feb 2020 06:59:10 -0000 > -----Original Message----- > From: Dots On Behalf Of > mohamed.boucadair@orange.com > Sent: Monday, February 3, 2020 3:07 PM > To: Jon Shallow (supjps-ietf@jpshallow.com) ; > dots@ietf.org > Subject: Re: [Dots] I-D Action: draft-ietf-dots-telemetry-01.txt >=20 > CAUTION: External email. Do not click links or open attachments unless yo= u > recognize the sender and know the content is safe. >=20 > Hi all, >=20 > FYI, a review from Jon is available at: https://github.com/boucadair/draf= t- > dots-telemetry/raw/master/DOTS%20Telemetry%2001-rev%20Jon- > res%20Med.docx >=20 > -02 will integrate almost all comments from Jon. Please find below some > points we would like to hear more from the working group: >=20 > (1) key value range for telemetry: Jon raised this point "These keys requ= ires 3 > bytes - and telemetry information is going to be difficult to fit into a = packet. I > appreciate that comprehension-required Is for numbers less than 0x8000 - > perhaps the comprehension-required range is reduced and also has a sectio= n > higher up so the total of 0x8000 still stands so less bytes can be used h= ere." >=20 > +----------------------+-------+-------+------------+---------------+ > | Parameter Name | CBOR | CBOR | Change | Specification | > | | Key | Major | Controller | Document(s) | > | | Value | Type | | | > +----------------------+-------+-------+------------+---------------+ > | ietf-dots-signal-cha | 32776 | 5 | IESG | [RFCXXXX] | > | nnel:telemetry | | | | | >=20 > Med: This is a major one. We need to assess the gain, but it is possible = in > theory to update our assignment policies and reassign, e.g., 128-255 rang= e to > be comprehension-optional (specific for telemetry). This would mean that > the telemetry spec will be tagged as updating the base signal channel spe= c. > We need more discussion. Why not change the DOTS telemetry attributes to comprehension-required ? If the server does not understand the DOTS telemetry attributes, it will re= spond with 4.00 error response, and the client can re-send the request with= out the DOTS telemetry attributes. Cheers, -Tiru >=20 > (2) server-initiated-telemetry: "Having server-initiated-telemetry under > max-config-values, but not min-config-values makes no sense to me. I thi= nk > it should be under telemetry-config at the level of current-config and > possibly removed from current-config as well." >=20 > Med: >=20 > A. It is in the max container because setting that value to "false" under= that > container has a special meaning: the server does not support sending pre- > mitigation telemetry. We can put it under min as well but do we have a ca= se > where setting it to "true" has a meaning? > B. I do agree that 'server-initiated-telemetry' can be removed from the > current configuration because the same functionality is achieved using a > GET+Observe but we left it there for the moment as we need to work > further the details for subscribing to pre-mitigation from the servers. >=20 > (3) "vendor-id is missing from the cbor table": >=20 > Med: This was done on purpose to try to optimize the number of CBOR key > values + encourage attributes reuse. E.g., We replaced "telemetry-id", > "baseline-id", and "vendor-id" with a single "id" (as we only use those f= or the > moment in the message body) but the YANG module includes the meaning > of each "id" in the definition clause. We may need to revise this if we > conclude that, e.g., "telemetry-id" (tmid) has to be defined as Path-URI. >=20 > Cheers, > Med >=20 > > -----Message d'origine----- > > De=A0: Dots [mailto:dots-bounces@ietf.org] De la part de > > mohamed.boucadair@orange.com Envoy=E9=A0: vendredi 31 janvier 2020 16:1= 8 > =C0 > > : dots@ietf.org Objet=A0: Re: [Dots] I-D Action: > > draft-ietf-dots-telemetry-01.txt > > > > Hi all, > > > > We prepared with Tiru a major revision of the telemetry draft. A diff > > is provided below to track the changes. We will now focus on sections > > 7 and 8. > > > > Please review and share comments. > > > > Cheers, > > Med > > > > > -----Message d'origine----- > > > De=A0: Dots [mailto:dots-bounces@ietf.org] De la part de internet- > > > drafts@ietf.org Envoy=E9=A0: vendredi 31 janvier 2020 15:52 =C0=A0: > > > i-d-announce@ietf.org Cc=A0: dots@ietf.org Objet=A0: [Dots] I-D Actio= n: > > > draft-ietf-dots-telemetry-01.txt > > > > > > > > > A New Internet-Draft is available from the on-line Internet-Drafts > > > directories. > > > This draft is a work item of the DDoS Open Threat Signaling WG of > > the > > > IETF. > > > > > > Title : Distributed Denial-of-Service Open Threat > > > Signaling (DOTS) Telemetry > > > Authors : Mohamed Boucadair > > > Tirumaleswar Reddy > > > Ehud Doron > > > Meiling Chen > > > =09Filename : draft-ietf-dots-telemetry-01.txt > > > =09Pages : 70 > > > =09Date : 2020-01-31 > > > > > > Abstract: > > > This document aims to enrich DOTS signal channel protocol with > > > various telemetry attributes allowing optimal DDoS attack > > > mitigation. > > > This document specifies the normal traffic baseline and attack > > > traffic telemetry attributes a DOTS client can convey to its DOTS > > > server in the mitigation request, the mitigation status telemetry > > > attributes a DOTS server can communicate to a DOTS client, and > > the > > > mitigation efficacy telemetry attributes a DOTS client can > > > communicate to a DOTS server. The telemetry attributes can > > assist > > > the mitigator to choose the DDoS mitigation techniques and > > perform > > > optimal DDoS attack mitigation. > > > > > > > > > The IETF datatracker status page for this draft is: > > > https://datatracker.ietf.org/doc/draft-ietf-dots-telemetry/ > > > > > > There are also htmlized versions available at: > > > https://tools.ietf.org/html/draft-ietf-dots-telemetry-01 > > > https://datatracker.ietf.org/doc/html/draft-ietf-dots-telemetry-01 > > > > > > A diff from the previous version is available at: > > > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dots-telemetry-01 > > > > > > > > > Please note that it may take a couple of minutes from the time of > > > submission until the htmlized version and diff are available at > > > tools.ietf.org. > > > > > > Internet-Drafts are also available by anonymous FTP at: > > > ftp://ftp.ietf.org/internet-drafts/ > > > > > > _______________________________________________ > > > Dots mailing list > > > Dots@ietf.org > > > https://www.ietf.org/mailman/listinfo/dots > > > > _______________________________________________ > > Dots mailing list > > Dots@ietf.org > > https://www.ietf.org/mailman/listinfo/dots >=20 > _______________________________________________ > Dots mailing list > Dots@ietf.org > https://www.ietf.org/mailman/listinfo/dots From nobody Tue Feb 4 23:09:43 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 B0D80120024; Tue, 4 Feb 2020 23:09:41 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Barry Leiba via Datatracker To: "The IESG" Cc: draft-ietf-dots-architecture@ietf.org, Roman Danyliw , Valery Smyslov , dots-chairs@ietf.org, valery@smyslov.net, dots@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.116.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Barry Leiba Message-ID: <158088658171.15681.14587346571684701270.idtracker@ietfa.amsl.com> Date: Tue, 04 Feb 2020 23:09:41 -0800 Archived-At: Subject: [Dots] Barry Leiba's No Objection on draft-ietf-dots-architecture-16: (with COMMENT) 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, 05 Feb 2020 07:09:42 -0000 Barry Leiba has entered the following ballot position for draft-ietf-dots-architecture-16: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-dots-architecture/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- A well done document; thanks, I have just a few minor comments: — Section 1.1.1 — You don’t *quite* have the BCP 14 boilerplate verbatim; please fix that. — Section 1.3 — o The signal and data channels are loosely coupled, and may not terminate on the same DOTS server. I suggest “might not”, lest someone misread it to mean that they are not permitted to (the strict English meaning of “may not”). Look for “may not” elsewhere also: I saw it in Section 2 as well, and one or two other places. — Section 2 — Thus, DOTS neither specifies how an attack target decides it is under DDoS attack, nor does DOTS specify how a mitigator may actually mitigate such an attack. The structure of this “neither...nor” doesn’t work. NEW Thus, DOTS specifies neither how an attack target decides it is under DDoS attack, nor how a mitigator may actually mitigate such an attack. END From nobody Tue Feb 4 23:38:49 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 9A3C812022D for ; Tue, 4 Feb 2020 23:38:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 VhLm1RJzG9Ju for ; Tue, 4 Feb 2020 23:38:45 -0800 (PST) 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 865CB12004A for ; Tue, 4 Feb 2020 23:38:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mcafee.com; s=mimecast20190606; t=1580888324; h=from:from: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=4LI+co3Ve/qt6RhAAlyEG3U0TxqHTUa6Rh9cyMFJ6hc=; b=MbhMHegy6rs3U1RrihnPNOZ2xxTSjj1xUsEZm/Axh0KVTEtnIMnrTSQtbFHpn1F5QaN5mm 35IbtPmsAa/2X/+CZVA/o5GxMOEehQ78O+Xc95P/jKhOQfENKoyyoqOrfr8lUyzdBIPEYs yBJ1rUoFA/vycX4n7u/HQqd4zMCpSyY= Received: from NAM12-DM6-obe.outbound.protection.outlook.com (mail-dm6nam12lp2171.outbound.protection.outlook.com [104.47.59.171]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-345-i7GJ-_OcOvKpyoXkaDolZA-1; Wed, 05 Feb 2020 02:38:39 -0500 Received: from CY4PR1601MB1254.namprd16.prod.outlook.com (10.172.118.12) by CY4PR1601MB1160.namprd16.prod.outlook.com (10.172.115.138) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2707.21; Wed, 5 Feb 2020 07:38:38 +0000 Received: from CY4PR1601MB1254.namprd16.prod.outlook.com ([fe80::e851:20e8:57bd:fedd]) by CY4PR1601MB1254.namprd16.prod.outlook.com ([fe80::e851:20e8:57bd:fedd%12]) with mapi id 15.20.2686.034; Wed, 5 Feb 2020 07:38:38 +0000 From: "Konda, Tirumaleswar Reddy" To: Barry Leiba , The IESG CC: Roman Danyliw , "dots-chairs@ietf.org" , "valery@smyslov.net" , "dots@ietf.org" , "draft-ietf-dots-architecture@ietf.org" Thread-Topic: [Dots] Barry Leiba's No Objection on draft-ietf-dots-architecture-16: (with COMMENT) Thread-Index: AQHV2/NFf3ywOqTl2EyDW8JybZd7T6gMNSIA Date: Wed, 5 Feb 2020 07:38:37 +0000 Message-ID: References: <158088658171.15681.14587346571684701270.idtracker@ietfa.amsl.com> In-Reply-To: <158088658171.15681.14587346571684701270.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-version: 11.4.0.45 dlp-reaction: no-action x-originating-ip: [49.37.206.28] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: f2e14d22-ac31-4abf-a52b-08d7aa0e6a02 x-ms-traffictypediagnostic: CY4PR1601MB1160: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 0304E36CA3 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(39860400002)(136003)(366004)(396003)(346002)(376002)(32952001)(199004)(189003)(55016002)(2906002)(7696005)(478600001)(71200400001)(86362001)(966005)(81156014)(8676002)(8936002)(5660300002)(81166006)(186003)(52536014)(33656002)(26005)(4326008)(6506007)(76116006)(53546011)(66556008)(316002)(66946007)(110136005)(9686003)(64756008)(54906003)(66446008)(66476007)(85282002); DIR:OUT; SFP:1101; SCL:1; SRVR:CY4PR1601MB1160; H:CY4PR1601MB1254.namprd16.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: Wbm0IzJiIHy0XahHi40bj788ctG5cYxmpFLHN7vg/9PPuQxJR+djRtXrv46IS4hP5FCDEQQp3LJAQhC3g9gnxaS1ww9WygRf9VlgP1I/46hnLwrLtJAs8Q5qBIlbgqAlLcAur4V7NrnVwTkML/mr8C9Wc4UbxCxm8cVoJVowJEYXaP5SpeC4E1Aoh3rnQoLIE/XbpZnrZuCantlccXA1M4ylK/1Npkf/LasVNZgIDdq2j8z2ZBbaPkSRRyRthfesgExoZNbhBKemFewmL5e7VraTpoc1VfSJYirK3//5def6mH6bBie/qf/nxvFlSgPjc9fmHAqQ1rHxV6u/PFESN0eT//6ssOQA61G+bsfsgkWvX/QdCfjloRcR7lbuAiMLQ+doLP5xdUBOIWiuraUDnIVLtoDf3axSfsvMAxAUs/BEACntGonmWN3UQD0/puOI4C1MzMVc27onw+T04Snylr9C5ZaaRtIJLbdqJIqy+ZVv6CkRgj3cZhMA0oMsmSeL/MGtzNiyg/obHQVqc69H6IL9oNneZz9n8+FMe6VaaAgj6PbxgRhlGIJvriB8NVSg57vl46qXKIqcxzxfL1JqpKmGJ0Y2om4pww0mOsFp4nw= x-ms-exchange-antispam-messagedata: qk0jQUtNlgqgaRUPc6k6MXfN6FQMEEI5bYF4LQBZWdpx1Ov+t1hRgEciFnW3asRU48pkhVe3eanUZ/qnhrq1/UxZELAViDvElCcf0W7ecf3COh/EHgzO/YflyHaEAqwGFgwUhVx7D00VS0rrf3m2WQ== x-ms-exchange-transport-forked: True MIME-Version: 1.0 X-OriginatorOrg: mcafee.com X-MS-Exchange-CrossTenant-Network-Message-Id: f2e14d22-ac31-4abf-a52b-08d7aa0e6a02 X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Feb 2020 07:38:37.9897 (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: gGgduEYqhosDQhCo3hbKCIZ7qfHqnXA8jtw8Muq0Ho0DZPtrAsuSFtU050J+BrWvqDBprMH9fbn8HT5+CgNfVuVyylz4fjp3fyLgqZrZbyzj9KPAglbMCrMJ4/3TT69J X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR1601MB1160 X-MC-Unique: i7GJ-_OcOvKpyoXkaDolZA-1 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] Barry Leiba's No Objection on draft-ietf-dots-architecture-16: (with COMMENT) 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, 05 Feb 2020 07:38:48 -0000 PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBEb3RzIDxkb3RzLWJvdW5jZXNA aWV0Zi5vcmc+IE9uIEJlaGFsZiBPZiBCYXJyeSBMZWliYSB2aWENCj4gRGF0YXRyYWNrZXINCj4g U2VudDogV2VkbmVzZGF5LCBGZWJydWFyeSA1LCAyMDIwIDEyOjQwIFBNDQo+IFRvOiBUaGUgSUVT RyA8aWVzZ0BpZXRmLm9yZz4NCj4gQ2M6IFJvbWFuIERhbnlsaXcgPHJkZEBjZXJ0Lm9yZz47IGRv dHMtY2hhaXJzQGlldGYub3JnOw0KPiB2YWxlcnlAc215c2xvdi5uZXQ7IGRvdHNAaWV0Zi5vcmc7 IGRyYWZ0LWlldGYtZG90cy1hcmNoaXRlY3R1cmVAaWV0Zi5vcmcNCj4gU3ViamVjdDogW0RvdHNd IEJhcnJ5IExlaWJhJ3MgTm8gT2JqZWN0aW9uIG9uIGRyYWZ0LWlldGYtZG90cy1hcmNoaXRlY3R1 cmUtMTY6DQo+ICh3aXRoIENPTU1FTlQpDQo+IA0KPiBDQVVUSU9OOiBFeHRlcm5hbCBlbWFpbC4g RG8gbm90IGNsaWNrIGxpbmtzIG9yIG9wZW4gYXR0YWNobWVudHMgdW5sZXNzIHlvdQ0KPiByZWNv Z25pemUgdGhlIHNlbmRlciBhbmQga25vdyB0aGUgY29udGVudCBpcyBzYWZlLg0KPiANCj4gQmFy cnkgTGVpYmEgaGFzIGVudGVyZWQgdGhlIGZvbGxvd2luZyBiYWxsb3QgcG9zaXRpb24gZm9yDQo+ IGRyYWZ0LWlldGYtZG90cy1hcmNoaXRlY3R1cmUtMTY6IE5vIE9iamVjdGlvbg0KPiANCj4gV2hl biByZXNwb25kaW5nLCBwbGVhc2Uga2VlcCB0aGUgc3ViamVjdCBsaW5lIGludGFjdCBhbmQgcmVw bHkgdG8gYWxsIGVtYWlsDQo+IGFkZHJlc3NlcyBpbmNsdWRlZCBpbiB0aGUgVG8gYW5kIENDIGxp bmVzLiAoRmVlbCBmcmVlIHRvIGN1dCB0aGlzIGludHJvZHVjdG9yeQ0KPiBwYXJhZ3JhcGgsIGhv d2V2ZXIuKQ0KPiANCj4gDQo+IFBsZWFzZSByZWZlciB0byBodHRwczovL3d3dy5pZXRmLm9yZy9p ZXNnL3N0YXRlbWVudC9kaXNjdXNzLWNyaXRlcmlhLmh0bWwNCj4gZm9yIG1vcmUgaW5mb3JtYXRp b24gYWJvdXQgSUVTRyBESVNDVVNTIGFuZCBDT01NRU5UIHBvc2l0aW9ucy4NCj4gDQo+IA0KPiBU aGUgZG9jdW1lbnQsIGFsb25nIHdpdGggb3RoZXIgYmFsbG90IHBvc2l0aW9ucywgY2FuIGJlIGZv dW5kIGhlcmU6DQo+IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYt ZG90cy1hcmNoaXRlY3R1cmUvDQo+IA0KPiANCj4gDQo+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gQ09NTUVO VDoNCj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiANCj4gQSB3ZWxsIGRvbmUgZG9jdW1lbnQ7IHRoYW5rcywg IEkgaGF2ZSBqdXN0IGEgZmV3IG1pbm9yIGNvbW1lbnRzOg0KPiANCj4g4oCUIFNlY3Rpb24gMS4x LjEg4oCUDQo+IFlvdSBkb27igJl0ICpxdWl0ZSogaGF2ZSB0aGUgQkNQIDE0IGJvaWxlcnBsYXRl IHZlcmJhdGltOyBwbGVhc2UgZml4IHRoYXQuDQoNCkZpeGVkLiANCg0KPiANCj4g4oCUIFNlY3Rp b24gMS4zIOKAlA0KPiANCj4gICAgbyAgVGhlIHNpZ25hbCBhbmQgZGF0YSBjaGFubmVscyBhcmUg bG9vc2VseSBjb3VwbGVkLCBhbmQgbWF5IG5vdA0KPiAgICAgICB0ZXJtaW5hdGUgb24gdGhlIHNh bWUgRE9UUyBzZXJ2ZXIuDQo+IA0KPiBJIHN1Z2dlc3Qg4oCcbWlnaHQgbm904oCdLCBsZXN0IHNv bWVvbmUgbWlzcmVhZCBpdCB0byBtZWFuIHRoYXQgdGhleSBhcmUgbm90DQo+IHBlcm1pdHRlZCB0 byAodGhlIHN0cmljdCBFbmdsaXNoIG1lYW5pbmcgb2Yg4oCcbWF5IG5vdOKAnSkuICBMb29rIGZv ciDigJxtYXkgbm904oCdDQo+IGVsc2V3aGVyZSBhbHNvOiBJIHNhdyBpdCBpbiBTZWN0aW9uIDIg YXMgd2VsbCwgYW5kIG9uZSBvciB0d28gb3RoZXIgcGxhY2VzLg0KDQpUaGFua3MsIGNvcnJlY3Rl ZCBpbiBvdGhlciBwbGFjZXMgKFNlY3Rpb25zIDEuMywgMiBhbmQgMy4yLjQuMSkuIA0KDQo+IA0K PiDigJQgU2VjdGlvbiAyIOKAlA0KPiANCj4gICAgVGh1cywgRE9UUyBuZWl0aGVyIHNwZWNpZmll cyBob3cgYW4gYXR0YWNrIHRhcmdldCBkZWNpZGVzIGl0IGlzIHVuZGVyDQo+ICAgIEREb1MgYXR0 YWNrLCBub3IgZG9lcyBET1RTIHNwZWNpZnkgaG93IGEgbWl0aWdhdG9yIG1heSBhY3R1YWxseQ0K PiAgICBtaXRpZ2F0ZSBzdWNoIGFuIGF0dGFjay4NCj4gDQo+IFRoZSBzdHJ1Y3R1cmUgb2YgdGhp cyDigJxuZWl0aGVyLi4ubm9y4oCdIGRvZXNu4oCZdCB3b3JrLg0KPiANCj4gTkVXDQo+ICAgIFRo dXMsIERPVFMgc3BlY2lmaWVzIG5laXRoZXIgaG93IGFuIGF0dGFjayB0YXJnZXQgZGVjaWRlcyBp dCBpcyB1bmRlcg0KPiAgICBERG9TIGF0dGFjaywgbm9yIGhvdyBhIG1pdGlnYXRvciBtYXkgYWN0 dWFsbHkgbWl0aWdhdGUgc3VjaCBhbiBhdHRhY2suDQo+IEVORA0KDQpVcGRhdGVkIGluIG15IGxv Y2FsIGNvcHkuDQoNCkNoZWVycywNCi1UaXJ1DQoNCj4gDQo+IA0KPiBfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBEb3RzIG1haWxpbmcgbGlzdA0KPiBE b3RzQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZG90 cw0KDQo= From nobody Wed Feb 5 06:20:01 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 84889120059; Wed, 5 Feb 2020 06:19:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.401 X-Spam-Level: X-Spam-Status: No, score=-1.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lxvahSCViEHu; Wed, 5 Feb 2020 06:19:54 -0800 (PST) Received: from mail-il1-f174.google.com (mail-il1-f174.google.com [209.85.166.174]) (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 EDD5F120026; Wed, 5 Feb 2020 06:19:53 -0800 (PST) Received: by mail-il1-f174.google.com with SMTP id l4so2015676ilj.1; Wed, 05 Feb 2020 06:19:53 -0800 (PST) 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:content-transfer-encoding; bh=pafx2THT31L8ck5UwweMy+qIBnE8mx/tB4IPmCCdDAY=; b=nFUy+aVtWIdqZT6lqxuYxyJs7B81eaVKx656AihbGn+bCZW8ysTHdSp05Why4Z7Vv7 WC9IWi2vVu1XLR1vu3RwFBA1oe8lCEz3e3R6ZcJESHTBveRlzIJqVgwvZ7Ntrwo66Ttf poJdrIdF7QQIk+8s/h4nBTNreRSyOXIubYUajgAqTfTUw2Wo4U//uh8xAl2frL4t61Fq W7bSaT5NIFFaUkVlwMcP4mm0KVaj4c8rvkhUl1CEsbgg5J1z73XdAP1DAxKtRV7GafqF 3pt8iMSIsmA+BO0j6fTMPLMedq86Wn7or3m80zdRVHaJzvfbb7zwROpyJHRB1ynubh0F w/Gg== X-Gm-Message-State: APjAAAW6FAMimFi0f25k4Qen22YBcHxWYO9aR0vceZn6gI4UQLEABVAz i7VJMSM8z6IsBOzK6nlXF8hzjpNVqs4VQXrX3Cg= X-Google-Smtp-Source: APXvYqxrU3jJZlZrnTLBHn0T7+97P/h5te7z24A2Sc+2cV60nf1hao3/d6o/G87nKIlBOu/MnlA0hGW8iAThgk2BkGM= X-Received: by 2002:a92:508:: with SMTP id q8mr25345945ile.187.1580912393036; Wed, 05 Feb 2020 06:19:53 -0800 (PST) MIME-Version: 1.0 References: <158088658171.15681.14587346571684701270.idtracker@ietfa.amsl.com> In-Reply-To: From: Barry Leiba Date: Wed, 5 Feb 2020 09:19:41 -0500 Message-ID: To: "Konda, Tirumaleswar Reddy" Cc: The IESG , Roman Danyliw , "dots-chairs@ietf.org" , "valery@smyslov.net" , "dots@ietf.org" , "draft-ietf-dots-architecture@ietf.org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Dots] Barry Leiba's No Objection on draft-ietf-dots-architecture-16: (with COMMENT) 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, 05 Feb 2020 14:19:56 -0000 Thanks for the quick reply and the fixes, Tiru! Barry On Wed, Feb 5, 2020 at 2:38 AM Konda, Tirumaleswar Reddy wrote: > > > -----Original Message----- > > From: Dots On Behalf Of Barry Leiba via > > Datatracker > > Sent: Wednesday, February 5, 2020 12:40 PM > > To: The IESG > > Cc: Roman Danyliw ; dots-chairs@ietf.org; > > valery@smyslov.net; dots@ietf.org; draft-ietf-dots-architecture@ietf.or= g > > Subject: [Dots] Barry Leiba's No Objection on draft-ietf-dots-architect= ure-16: > > (with COMMENT) > > > > CAUTION: External email. Do not click links or open attachments unless = you > > recognize the sender and know the content is safe. > > > > Barry Leiba has entered the following ballot position for > > draft-ietf-dots-architecture-16: No Objection > > > > When responding, please keep the subject line intact and reply to all e= mail > > addresses included in the To and CC lines. (Feel free to cut this intro= ductory > > paragraph, however.) > > > > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.ht= ml > > for more information about IESG DISCUSS and COMMENT positions. > > > > > > The document, along with other ballot positions, can be found here: > > https://datatracker.ietf.org/doc/draft-ietf-dots-architecture/ > > > > > > > > ---------------------------------------------------------------------- > > COMMENT: > > ---------------------------------------------------------------------- > > > > A well done document; thanks, I have just a few minor comments: > > > > =E2=80=94 Section 1.1.1 =E2=80=94 > > You don=E2=80=99t *quite* have the BCP 14 boilerplate verbatim; please = fix that. > > Fixed. > > > > > =E2=80=94 Section 1.3 =E2=80=94 > > > > o The signal and data channels are loosely coupled, and may not > > terminate on the same DOTS server. > > > > I suggest =E2=80=9Cmight not=E2=80=9D, lest someone misread it to mean = that they are not > > permitted to (the strict English meaning of =E2=80=9Cmay not=E2=80=9D).= Look for =E2=80=9Cmay not=E2=80=9D > > elsewhere also: I saw it in Section 2 as well, and one or two other pla= ces. > > Thanks, corrected in other places (Sections 1.3, 2 and 3.2.4.1). > > > > > =E2=80=94 Section 2 =E2=80=94 > > > > Thus, DOTS neither specifies how an attack target decides it is unde= r > > DDoS attack, nor does DOTS specify how a mitigator may actually > > mitigate such an attack. > > > > The structure of this =E2=80=9Cneither...nor=E2=80=9D doesn=E2=80=99t w= ork. > > > > NEW > > Thus, DOTS specifies neither how an attack target decides it is unde= r > > DDoS attack, nor how a mitigator may actually mitigate such an attac= k. > > END > > Updated in my local copy. > > Cheers, > -Tiru > > > > > > > _______________________________________________ > > Dots mailing list > > Dots@ietf.org > > https://www.ietf.org/mailman/listinfo/dots > From nobody Wed Feb 5 09:31:03 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 302921200BA; Wed, 5 Feb 2020 09:31:01 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Warren Kumari via Datatracker To: "The IESG" Cc: draft-ietf-dots-architecture@ietf.org, Roman Danyliw , Valery Smyslov , dots-chairs@ietf.org, valery@smyslov.net, dots@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.116.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Warren Kumari Message-ID: <158092386119.12787.6879612110839501695.idtracker@ietfa.amsl.com> Date: Wed, 05 Feb 2020 09:31:01 -0800 Archived-At: Subject: [Dots] Warren Kumari's No Objection on draft-ietf-dots-architecture-16: (with COMMENT) 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, 05 Feb 2020 17:31:01 -0000 Warren Kumari has entered the following ballot position for draft-ietf-dots-architecture-16: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-dots-architecture/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Firstly, thank you for a well written, and easy to understand document -- I personally always find architecture type documents helpful... I do have a few non-blocking comments: 1: "For example, if the DOTS client domain leverages the DDoS mitigation service of its Internet Transit Provider (ITP), the ITP knows the prefixes assigned to the DOTS client domain. However, if the DDoS Mitigation is offered by a third party DDoS mitigation service provider, it does not know the resources owned by the DOTS client domain." This is vastly oversimplifying the real-world, to the point that it is harmful / propagates dangerous misconceptions. ISPs may or may not know the prefixes assigned to their customers - they really *should* know the prefixes that the client is choosing to announce to them, but the client may have other prefixes which they only announce through other transits (yes, in this case this ISP would only be providing mitigations for prefixes announced to it, but this isn't clear). In addition, if the DDoS mitigation is provides by a 3rd party, it could know what resources are owned by the client -- in fact, it kind of has to if it is going to agree to mitigate for those prefixes. Note that I *almost* made this a DISCUSS point - I really really think that this bit should be either carefully revised, or, better yet, just struck... 2: "Signal loss is not caused by links congested with attack traffic alone, and as such mitigation requests triggered by signal channel degradation in either direction may incur unnecessary costs, in network performance and operational expense alike." The "operational expense" is vary vague - enabling DDoS mitigations is almost definitely going to cause a user visible impact, especially in the case where the mitigator announces a BGP route to attract traffic. Is this covered by 'operational expense'? This section also leaves out the fact that there is likely a financial impact. 3: "The signal and data channels are loosely coupled, and may not terminate on the same DOTS server." - s/may not/might not/. Every-time I'm sitting on a plane and the safety briefing says that oxygen mask will fall from the ceiling and that "the bag may not inflate" I have visions of IETFers (and similar pedants!) sitting there and squeezing the bag to ensure that it doesn't... "the bag *might* not inflate" is what is intended, and is also what you want :-P From nobody Wed Feb 5 12:04:44 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 45C25120147; Wed, 5 Feb 2020 12:04:42 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Alissa Cooper via Datatracker To: "The IESG" Cc: draft-ietf-dots-architecture@ietf.org, Roman Danyliw , Valery Smyslov , dots-chairs@ietf.org, valery@smyslov.net, dots@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.116.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Alissa Cooper Message-ID: <158093308227.12807.16380242192940998379.idtracker@ietfa.amsl.com> Date: Wed, 05 Feb 2020 12:04:42 -0800 Archived-At: Subject: [Dots] Alissa Cooper's No Objection on draft-ietf-dots-architecture-16: (with COMMENT) 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, 05 Feb 2020 20:04:42 -0000 Alissa Cooper has entered the following ballot position for draft-ietf-dots-architecture-16: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-dots-architecture/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Section 3.2.5.4: "as long as the name is internally and externally resolvable by the same name." I get what this means but I think it could be stated in a less circular fashion. From nobody Wed Feb 5 12:24:29 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 20D53120289 for ; Wed, 5 Feb 2020 12:24:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_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 zSfg3Klzgkm7 for ; Wed, 5 Feb 2020 12:24:22 -0800 (PST) Received: from mail.jpshallow.com (mail.jpshallow.com [217.40.240.153]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ED523120805 for ; Wed, 5 Feb 2020 12:24:21 -0800 (PST) Received: from mail2.jpshallow.com ([192.168.0.3] helo=N01332) by mail.jpshallow.com with esmtp (Exim 4.92.3) (envelope-from ) id 1izRDb-0005LR-W0; Wed, 05 Feb 2020 20:24:16 +0000 From: "Jon Shallow" To: "'Konda, Tirumaleswar Reddy'" , , References: <158048229416.21195.16114328651657501634@ietfa.amsl.com> <787AE7BB302AE849A7480A190F8B93303141473A@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B933031414F55@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> In-Reply-To: Date: Wed, 5 Feb 2020 20:24:08 -0000 Message-ID: <0a3001d5dc62$37f49820$a7ddc860$@jpshallow.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHr206TCH7qdtBwuLa4j7/r9QPmPgFoCT98AYq79nABByZIcqfBOr1w Content-Language: en-gb Archived-At: Subject: Re: [Dots] I-D Action: draft-ietf-dots-telemetry-01.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, 05 Feb 2020 20:24:28 -0000 See inline Regards Jon > -----Original Message----- > From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of Konda, > Tirumaleswar Reddy > Sent: 05 February 2020 06:59 > To: mohamed.boucadair@orange.com; Jon Shallow (supjps- > ietf@jpshallow.com); dots@ietf.org > Subject: Re: [Dots] I-D Action: draft-ietf-dots-telemetry-01.txt >=20 > > -----Original Message----- > > From: Dots On Behalf Of > > mohamed.boucadair@orange.com > > Sent: Monday, February 3, 2020 3:07 PM > > To: Jon Shallow (supjps-ietf@jpshallow.com) ietf@jpshallow.com>; > > dots@ietf.org > > Subject: Re: [Dots] I-D Action: draft-ietf-dots-telemetry-01.txt > > > > CAUTION: External email. Do not click links or open attachments = unless > you > > recognize the sender and know the content is safe. > > > > Hi all, > > > > FYI, a review from Jon is available at: https://github.com/boucadair/draft- > > dots-telemetry/raw/master/DOTS%20Telemetry%2001-rev%20Jon- > > res%20Med.docx > > > > -02 will integrate almost all comments from Jon. Please find below = some > > points we would like to hear more from the working group: > > > > (1) key value range for telemetry: Jon raised this point "These keys > requires 3 > > bytes - and telemetry information is going to be difficult to fit = into a > packet. I > > appreciate that comprehension-required Is for numbers less than = 0x8000 - > > perhaps the comprehension-required range is reduced and also has a > section > > higher up so the total of 0x8000 still stands so less bytes can be = used > here." > > > > = +----------------------+-------+-------+------------+---------------+ > > | Parameter Name | CBOR | CBOR | Change | = Specification | > > | | Key | Major | Controller | Document(s) = | > > | | Value | Type | | = | > > = +----------------------+-------+-------+------------+---------------+ > > | ietf-dots-signal-cha | 32776 | 5 | IESG | [RFCXXXX] = | > > | nnel:telemetry | | | | = | > > > > Med: This is a major one. We need to assess the gain, but it is = possible in > > theory to update our assignment policies and reassign, e.g., 128-255 range > to > > be comprehension-optional (specific for telemetry). This would mean = that > > the telemetry spec will be tagged as updating the base signal = channel > spec. > > We need more discussion. >=20 > Why not change the DOTS telemetry attributes to comprehension-required > ? > If the server does not understand the DOTS telemetry attributes, it = will > respond with 4.00 error response, and the client can re-send the = request > without the DOTS telemetry attributes. Jon> Telemetry is also gated by a different sets of Path-URIs. However, source-prefix attribute comes from draft-ietf-dots-signal-call-home and = also occupies 3 bytes - do we change the source-prefix CBOR Key type to comprehension-required? >=20 > Cheers, > -Tiru >=20 > > > > (2) server-initiated-telemetry: "Having server-initiated-telemetry = under > > max-config-values, but not min-config-values makes no sense to me. = I > think > > it should be under telemetry-config at the level of current-config = and > > possibly removed from current-config as well." > > > > Med: > > > > A. It is in the max container because setting that value to "false" under > that > > container has a special meaning: the server does not support sending pre- > > mitigation telemetry. We can put it under min as well but do we have = a > case > > where setting it to "true" has a meaning? > > B. I do agree that 'server-initiated-telemetry' can be removed from = the > > current configuration because the same functionality is achieved = using a > > GET+Observe but we left it there for the moment as we need to work > > further the details for subscribing to pre-mitigation from the = servers. > > > > (3) "vendor-id is missing from the cbor table": > > > > Med: This was done on purpose to try to optimize the number of CBOR = key > > values + encourage attributes reuse. E.g., We replaced = "telemetry-id", > > "baseline-id", and "vendor-id" with a single "id" (as we only use = those for > the > > moment in the message body) but the YANG module includes the > meaning > > of each "id" in the definition clause. We may need to revise this if = we > > conclude that, e.g., "telemetry-id" (tmid) has to be defined as Path-URI. Jon> Hmm - need to think through tmid + Path-URI. ~jon > > > > 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 31 janvier 2020 > 16:18 > > =C0 > > > : dots@ietf.org Objet=A0: Re: [Dots] I-D Action: > > > draft-ietf-dots-telemetry-01.txt > > > > > > Hi all, > > > > > > We prepared with Tiru a major revision of the telemetry draft. A = diff > > > is provided below to track the changes. We will now focus on = sections > > > 7 and 8. > > > > > > Please review and share comments. > > > > > > Cheers, > > > Med > > > > > > > -----Message d'origine----- > > > > De=A0: Dots [mailto:dots-bounces@ietf.org] De la part de = internet- > > > > drafts@ietf.org Envoy=E9=A0: vendredi 31 janvier 2020 15:52 = =C0=A0: > > > > i-d-announce@ietf.org Cc=A0: dots@ietf.org Objet=A0: [Dots] I-D = Action: > > > > draft-ietf-dots-telemetry-01.txt > > > > > > > > > > > > A New Internet-Draft is available from the on-line = Internet-Drafts > > > > directories. > > > > This draft is a work item of the DDoS Open Threat Signaling WG = of > > > the > > > > IETF. > > > > > > > > Title : Distributed Denial-of-Service Open = Threat > > > > Signaling (DOTS) Telemetry > > > > Authors : Mohamed Boucadair > > > > Tirumaleswar Reddy > > > > Ehud Doron > > > > Meiling Chen > > > > Filename : draft-ietf-dots-telemetry-01.txt > > > > Pages : 70 > > > > Date : 2020-01-31 > > > > > > > > Abstract: > > > > This document aims to enrich DOTS signal channel protocol = with > > > > various telemetry attributes allowing optimal DDoS attack > > > > mitigation. > > > > This document specifies the normal traffic baseline and = attack > > > > traffic telemetry attributes a DOTS client can convey to its = DOTS > > > > server in the mitigation request, the mitigation status = telemetry > > > > attributes a DOTS server can communicate to a DOTS client, = and > > > the > > > > mitigation efficacy telemetry attributes a DOTS client can > > > > communicate to a DOTS server. The telemetry attributes can > > > assist > > > > the mitigator to choose the DDoS mitigation techniques and > > > perform > > > > optimal DDoS attack mitigation. > > > > > > > > > > > > The IETF datatracker status page for this draft is: > > > > https://datatracker.ietf.org/doc/draft-ietf-dots-telemetry/ > > > > > > > > There are also htmlized versions available at: > > > > https://tools.ietf.org/html/draft-ietf-dots-telemetry-01 > > > > = https://datatracker.ietf.org/doc/html/draft-ietf-dots-telemetry-01 > > > > > > > > A diff from the previous version is available at: > > > > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dots-telemetry-01 > > > > > > > > > > > > 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 > > > > _______________________________________________ > > Dots mailing list > > Dots@ietf.org > > https://www.ietf.org/mailman/listinfo/dots >=20 > _______________________________________________ > Dots mailing list > Dots@ietf.org > https://www.ietf.org/mailman/listinfo/dots From nobody Wed Feb 5 21:45:48 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 53F78120120; Wed, 5 Feb 2020 21:45:46 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Benjamin Kaduk via Datatracker To: "The IESG" Cc: draft-ietf-dots-architecture@ietf.org, Roman Danyliw , Valery Smyslov , dots-chairs@ietf.org, valery@smyslov.net, dots@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.117.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Benjamin Kaduk Message-ID: <158096794633.30610.7698585491429934350.idtracker@ietfa.amsl.com> Date: Wed, 05 Feb 2020 21:45:46 -0800 Archived-At: Subject: [Dots] Benjamin Kaduk's Yes on draft-ietf-dots-architecture-16: (with COMMENT) 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, 06 Feb 2020 05:45:47 -0000 Benjamin Kaduk has entered the following ballot position for draft-ietf-dots-architecture-16: Yes When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-dots-architecture/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for this well-written document! It's a great high-level summary of DOTS and I just have some fairly minor comments. There might be a bit of mismatch between describing the signal channel session as associated with "an ephemeral security association" in Section 3.1 and as "expected to be long-lived" in Section 3.2.4.1. Section 2.2.3 The DOTS gateway MUST perform full stack DOTS session termination and reorigination between its client and server side. The details of how this is achieved are implementation specific. The DOTS protocol does not include any special features related to DOTS gateways, and hence from a DOTS perspective, whenever a DOTS gateway is present, the DOTS session simply terminates/originates there. Does the 'cdid' count as a "special feature"? Section 2.3.1 An example is a DOTS gateway at the network client's side, and another one at the server side. The first gateway can be located at a CPE to aggregate requests from multiple DOTS clients enabled in an nit: "CPE" does not appear as "well known" at https://www.rfc-editor.org/materials/abbrev.expansion.txt and should be expanded on first use. Section 3.2.3 We could mention that the recursing gateway (e.g., Cn in Figure 12) must still be authorized to request mitigation for the resources (also) controlled by client Cc (though perhaps the closing discussion about there typically being a SLA among client, recursed, and recursing domain suffices). Section 3.2.4.1 DOTS client to initialize a new DOTS session. This challenge might in part be mitigated by use of resumption via a PSK in TLS 1.3 [RFC8446] and DTLS 1.3 [I-D.ietf-tls-dtls13] (session resumption in TLS 1.2 [RFC5246] and DTLS 1.2 [RFC6347]), but keying material must be available to all DOTS servers sharing the anycast Service Address in that case. "which has operational challenges of its own", perhaps. session may involve diverting traffic to a scrubbing center. If the DOTS session flaps due to anycast changes as described above, mitigation may also flap as the DOTS servers sharing the anycast DOTS service address toggles mitigation on detecting DOTS session loss, depending on whether the client has configured mitigation on loss of signal. I am not sure if we've mentioned configuring mitigation on loss of signal, yet. A forward reference to Section 3.3.3 might help. Section 3.2.5 Network address translators (NATs) are expected to be a common feature of DOTS deployments. The Middlebox Traversal Guidelines in [RFC8085] include general NAT considerations for DOTS deployments when the signal channel is established over UDP. nit: the guidelines in 8085 are not specifically about DOTS deployments, so probably we should say "that are applicable to" DOTS deployments. Section 3.2.5.1 request accurate mitigation scopes. To that aim, the DOTS client can rely on mechanisms, such as [RFC8512] to retrieve static explicit mappings. This document does not prescribe the method by which nit: no comma. Section 3.3.3 The impact of mitigating due to loss of signal in either direction must be considered carefully before enabling it. Signal loss is not caused by links congested with attack traffic alone, and as such mitigation requests triggered by signal channel degradation in either nit: I think this could be parsed as "links are congested by attack traffic and other traffic", whereas we intend to say that "attack traffic is not the only possible cause of link congestion". Perhaps "Attack traffic congesting links is not the only reason why signal could be lost" is more clear. Section 5 DOTS is at risk from three primary attack vectors: agent impersonation, traffic injection and signal blocking. These vectors We seem to only partially discuss countermeasures for these attacks in the rest of the section; one piece that seems noteworthy in its absence is the requirement (already described in the body text) to authenticate the peer and perform authorization checks on client requests. Mitigating against signal blocking is in general hard, but we could consider mentioning again that the automated mitigation on loss of signal discussed in Section 3.3.3 is an option, albeit one with risks of its own. Section 8.2 One could perhaps argue that RFC 4033 and RFC 6887 should be normative ("[RFC4033] must be used where [...]", "[RFC6887] may be used to [...]"). There's a stronger case that RFC 4786 should be normative, as we use a BCP 14 keyword allowing its deployment. From nobody Wed Feb 5 22:39:10 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 EEED91200B4 for ; Wed, 5 Feb 2020 22:39:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, 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 KS0_9VsittiW for ; Wed, 5 Feb 2020 22:39:05 -0800 (PST) Received: from relais-inet.orange.com (relais-inet.orange.com [80.12.70.36]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0C60B12003E for ; Wed, 5 Feb 2020 22:39:05 -0800 (PST) Received: from opfednr05.francetelecom.fr (unknown [xx.xx.xx.69]) by opfednr27.francetelecom.fr (ESMTP service) with ESMTP id 48CpgC07Dmz4wGm; Thu, 6 Feb 2020 07:39:03 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1580971143; bh=Nc+6aIqBOQc1WmJGQkSVx4U6J2cCHdTXvKdsNeqR0XM=; h=From:To:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=VYzsiyofjLH99PVWA846mjU85yDFdi7gPIWBOs7tG+iJXDFcic2xoSwYxEWcaIdpX YHD1iVDCXnZGS7uArjMQ3jtHkN6An5Avm5ubFqzWCTOCI0dXCHcj+K0H4hpwQlDPNO y0OHeopiZkAFy9C/lBVkfePp7UBG1PS0bxfwsNeSsi3GSE7uFp8+3H2Owt0jkntvBX nhIkn74gKGSsl0mAuK52KL1Q/wstQja9GDMmosfFzrTsHrVuI5pIQFQM9g/0SaG50s a/JhJ7ftlNGE6zrbPq8VYAItwH5BktJtP+FOnS4XJhGXMaw8cd/XTPyamXzZ8dW3i8 38x6GmqI/9qlA== Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.20]) by opfednr05.francetelecom.fr (ESMTP service) with ESMTP id 48CpgB6BZdzyTB; Thu, 6 Feb 2020 07:39:02 +0100 (CET) Received: from OPEXCAUBMA2.corporate.adroot.infra.ftgroup ([fe80::e878:bd0:c89e:5b42]) by OPEXCAUBMA1.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0468.000; Thu, 6 Feb 2020 07:39:02 +0100 From: To: Jon Shallow , "'Konda, Tirumaleswar Reddy'" , "dots@ietf.org" Thread-Topic: [Dots] I-D Action: draft-ietf-dots-telemetry-01.txt Thread-Index: AQHr206TYQ9eUkWY2E+gQ7j9EgylIAFoCT98AYq79nABByZIcqfBOr1wgACo+TA= Date: Thu, 6 Feb 2020 06:39:02 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93303142D65C@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> References: <158048229416.21195.16114328651657501634@ietfa.amsl.com> <787AE7BB302AE849A7480A190F8B93303141473A@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B933031414F55@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <0a3001d5dc62$37f49820$a7ddc860$@jpshallow.com> In-Reply-To: <0a3001d5dc62$37f49820$a7ddc860$@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: 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-01.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, 06 Feb 2020 06:39:08 -0000 Hi Jon, all,=20 Please see inline.=20 Cheers, Med > -----Message d'origine----- > De=A0: Jon Shallow [mailto:supjps-ietf@jpshallow.com] > Envoy=E9=A0: mercredi 5 f=E9vrier 2020 21:24 > =C0=A0: 'Konda, Tirumaleswar Reddy'; BOUCADAIR Mohamed TGI/OLN; > dots@ietf.org > Objet=A0: RE: [Dots] I-D Action: draft-ietf-dots-telemetry-01.txt >=20 > See inline >=20 > Regards >=20 > Jon >=20 ... > > > > > > (1) key value range for telemetry: Jon raised this point "These > keys > > requires 3 > > > bytes - and telemetry information is going to be difficult to fit > into a > > packet. I > > > appreciate that comprehension-required Is for numbers less than > 0x8000 - > > > perhaps the comprehension-required range is reduced and also has a > > section > > > higher up so the total of 0x8000 still stands so less bytes can be > used > > here." > > > > > > +----------------------+-------+-------+------------+---------- > -----+ > > > | Parameter Name | CBOR | CBOR | Change | > Specification | > > > | | Key | Major | Controller | > Document(s) | > > > | | Value | Type | | > | > > > +----------------------+-------+-------+------------+---------- > -----+ > > > | ietf-dots-signal-cha | 32776 | 5 | IESG | > [RFCXXXX] | > > > | nnel:telemetry | | | | > | > > > > > > Med: This is a major one. We need to assess the gain, but it is > possible > in > > > theory to update our assignment policies and reassign, e.g., 128- > 255 > range > > to > > > be comprehension-optional (specific for telemetry). This would > mean that > > > the telemetry spec will be tagged as updating the base signal > channel > > spec. > > > We need more discussion. > > > > Why not change the DOTS telemetry attributes to comprehension- > required > > ? [Med] Telemetry attributes are not mandatory for the signal channel to func= tion. A signal channel message enriched with telemetry data should not exac= erbate message failure.=20 > > If the server does not understand the DOTS telemetry attributes, it > will > > respond with 4.00 error response, and the client can re-send the > request > > without the DOTS telemetry attributes. >=20 > Jon> Telemetry is also gated by a different sets of Path-URIs. [Med] Except when telemetry is also included in an update during a mitigati= on (S-C or S-C). What I have for this one in my local copy is as follows: In order to make use of this feature, DOTS clients MUST establish a telemetry setup session with the DOTS server in 'idle' time and MUST set the 'server-originated-telemetry' attribute to 'true'. DOTS servers MUST NOT include telemetry attributes in mitigation status updates sent to DOTS clients for which 'server-originated- telemetry' attribute is set to 'false'.=20 > However, > source-prefix attribute comes from draft-ietf-dots-signal-call-home > and also > occupies 3 bytes - do we change the source-prefix CBOR Key type to > comprehension-required? >=20 [Med] Including a source prefix in a signal channel message while not suppo= rted by the server must not lead to an error. That attribute cannot be set = a comprehension-required. I suggest we don't touch that part.=20 From nobody Wed Feb 5 22:47: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 C7F6C12003E; Wed, 5 Feb 2020 22:47:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, 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 JDehC-8xwnGA; Wed, 5 Feb 2020 22:47:07 -0800 (PST) Received: from relais-inet.orange.com (relais-inet.orange.com [80.12.66.41]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D4B6B120033; Wed, 5 Feb 2020 22:47:06 -0800 (PST) Received: from opfedar06.francetelecom.fr (unknown [xx.xx.xx.8]) by opfedar23.francetelecom.fr (ESMTP service) with ESMTP id 48CprS5V2FzBrsS; Thu, 6 Feb 2020 07:47:04 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1580971624; bh=ToQv2X6LCZhqsZRYKme0FnvGPowxmexmHbGjskUk6ao=; h=From:To:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=a/plw/W0cHOyH4o4fvaqQaoD+ZigXzgeUFzCZOGfumEwt+xktMAbWjrG7ofWsphqB WPJcspBv+V9hR9JzwS4zDKVBRNXhQWVs8i0DFXsKkxsrcuDEhN7EWPeq5NgnBzCPGB rZ4EBesLTqk5rqwhbIOeCnOtjC/i2FoyaL1PfoqmmKcZ0VqMcxtWuUVqllDlnixA4/ n6j3+SMk5R2qAaFiJZzOXQw3FTMqqi163YXTdZclV7G8sNAmhYSRMCtYYgOoOPq3WJ yUnBv4+GTq4v8cKL2imud8tUjE2xnUW+tVrBQ6GHJREHwh5p6i2uD7d6vloujQUQ3s UhvRsNCC+hxMg== Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.20]) by opfedar06.francetelecom.fr (ESMTP service) with ESMTP id 48CprS3xpnz3wcm; Thu, 6 Feb 2020 07:47:04 +0100 (CET) Received: from OPEXCAUBMA2.corporate.adroot.infra.ftgroup ([fe80::e878:bd0:c89e:5b42]) by OPEXCAUBMA1.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0468.000; Thu, 6 Feb 2020 07:47:04 +0100 From: To: Benjamin Kaduk , The IESG CC: Roman Danyliw , "dots-chairs@ietf.org" , "valery@smyslov.net" , "dots@ietf.org" , "draft-ietf-dots-architecture@ietf.org" Thread-Topic: [Dots] Benjamin Kaduk's Yes on draft-ietf-dots-architecture-16: (with COMMENT) Thread-Index: AQHV3LCzo0iHvHy700Ka0kODdp03iqgNt3BQ Date: Thu, 6 Feb 2020 06:47:03 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93303142F675@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> References: <158096794633.30610.7698585491429934350.idtracker@ietfa.amsl.com> In-Reply-To: <158096794633.30610.7698585491429934350.idtracker@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] Benjamin Kaduk's Yes on draft-ietf-dots-architecture-16: (with COMMENT) 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, 06 Feb 2020 06:47:10 -0000 Hi Ben,=20 Please see one comment inline.=20 Cheers, Med > -----Message d'origine----- > De=A0: Dots [mailto:dots-bounces@ietf.org] De la part de Benjamin Kaduk > via Datatracker > Envoy=E9=A0: jeudi 6 f=E9vrier 2020 06:46 > =C0=A0: The IESG > Cc=A0: Roman Danyliw; dots-chairs@ietf.org; valery@smyslov.net; > dots@ietf.org; draft-ietf-dots-architecture@ietf.org > Objet=A0: [Dots] Benjamin Kaduk's Yes on draft-ietf-dots-architecture- > 16: (with COMMENT) >=20 > Benjamin Kaduk has entered the following ballot position for > draft-ietf-dots-architecture-16: Yes >=20 > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut > this > introductory paragraph, however.) >=20 >=20 > Please refer to https://www.ietf.org/iesg/statement/discuss- > criteria.html > for more information about IESG DISCUSS and COMMENT positions. >=20 >=20 > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-dots-architecture/ >=20 >=20 >=20 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > Thanks for this well-written document! It's a great high-level > summary of > DOTS and I just have some fairly minor comments. >=20 > There might be a bit of mismatch between describing the signal channel > session as associated with "an ephemeral security association" in > Section > 3.1 and as "expected to be long-lived" in Section 3.2.4.1. >=20 > Section 2.2.3 >=20 > The DOTS gateway MUST perform full stack DOTS session termination > and > reorigination between its client and server side. The details of > how > this is achieved are implementation specific. The DOTS protocol > does > not include any special features related to DOTS gateways, and > hence > from a DOTS perspective, whenever a DOTS gateway is present, the > DOTS > session simply terminates/originates there. >=20 > Does the 'cdid' count as a "special feature"? [Med] Good catch. I suggest to delete the last sentence of the above excerp= t.=20 (we don't specify how the client and server sides are glued but we do have = feature to avoid loops when GWs are involved, enforce policies on a per cli= ent or domain basis, etc.). >=20 > Section 2.3.1 >=20 > An example is a DOTS gateway at the network client's side, and > another one at the server side. The first gateway can be located > at > a CPE to aggregate requests from multiple DOTS clients enabled in > an >=20 > nit: "CPE" does not appear as "well known" at > https://www.rfc-editor.org/materials/abbrev.expansion.txt and should > be > expanded on first use. >=20 > Section 3.2.3 >=20 > We could mention that the recursing gateway (e.g., Cn in Figure 12) > must > still be authorized to request mitigation for the resources (also) > controlled by client Cc (though perhaps the closing discussion about > there > typically being a SLA among client, recursed, and recursing domain > suffices). >=20 > Section 3.2.4.1 >=20 > DOTS client to initialize a new DOTS session. This challenge might > in part be mitigated by use of resumption via a PSK in TLS 1.3 > [RFC8446] and DTLS 1.3 [I-D.ietf-tls-dtls13] (session resumption in > TLS 1.2 [RFC5246] and DTLS 1.2 [RFC6347]), but keying material must > be available to all DOTS servers sharing the anycast Service > Address > in that case. >=20 > "which has operational challenges of its own", perhaps. >=20 > session may involve diverting traffic to a scrubbing center. If > the > DOTS session flaps due to anycast changes as described above, > mitigation may also flap as the DOTS servers sharing the anycast > DOTS > service address toggles mitigation on detecting DOTS session loss, > depending on whether the client has configured mitigation on loss > of > signal. >=20 > I am not sure if we've mentioned configuring mitigation on loss of > signal, > yet. A forward reference to Section 3.3.3 might help. >=20 > Section 3.2.5 >=20 > Network address translators (NATs) are expected to be a common > feature of DOTS deployments. The Middlebox Traversal Guidelines in > [RFC8085] include general NAT considerations for DOTS deployments > when the signal channel is established over UDP. >=20 > nit: the guidelines in 8085 are not specifically about DOTS > deployments, so > probably we should say "that are applicable to" DOTS deployments. >=20 > Section 3.2.5.1 >=20 > request accurate mitigation scopes. To that aim, the DOTS client > can > rely on mechanisms, such as [RFC8512] to retrieve static explicit > mappings. This document does not prescribe the method by which >=20 > nit: no comma. >=20 > Section 3.3.3 >=20 > The impact of mitigating due to loss of signal in either direction > must be considered carefully before enabling it. Signal loss is > not > caused by links congested with attack traffic alone, and as such > mitigation requests triggered by signal channel degradation in > either >=20 > nit: I think this could be parsed as "links are congested by attack > traffic > and other traffic", whereas we intend to say that "attack traffic is > not the > only possible cause of link congestion". Perhaps "Attack traffic > congesting > links is not the only reason why signal could be lost" is more clear. >=20 > Section 5 >=20 > DOTS is at risk from three primary attack vectors: agent > impersonation, traffic injection and signal blocking. These > vectors >=20 > We seem to only partially discuss countermeasures for these attacks in > the > rest of the section; one piece that seems noteworthy in its absence is > the > requirement (already described in the body text) to authenticate the > peer > and perform authorization checks on client requests. Mitigating > against > signal blocking is in general hard, but we could consider mentioning > again > that the automated mitigation on loss of signal discussed in Section > 3.3.3 > is an option, albeit one with risks of its own. >=20 > Section 8.2 >=20 > One could perhaps argue that RFC 4033 and RFC 6887 should be normative > ("[RFC4033] must be used where [...]", "[RFC6887] may be used to > [...]"). >=20 > There's a stronger case that RFC 4786 should be normative, as we use a > BCP > 14 keyword allowing its deployment. >=20 >=20 > _______________________________________________ > Dots mailing list > Dots@ietf.org > https://www.ietf.org/mailman/listinfo/dots From nobody Thu Feb 6 00:48:32 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 2CF7B120024 for ; Thu, 6 Feb 2020 00:48:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, 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 (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 beana6Sojp7j for ; Thu, 6 Feb 2020 00:48:24 -0800 (PST) Received: from us-smtp-delivery-140.mimecast.com (us-smtp-delivery-140.mimecast.com [63.128.21.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 62ED31200CE for ; Thu, 6 Feb 2020 00:48:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mcafee.com; s=mimecast20190606; t=1580978903; h=from:from: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=+43jAdYuXk2XmCjtKlmc9hmrwUO4+Ic8ic9IFwMzoH4=; b=S3ca8kQyNmMo/fvfCK1FfLmtkc4oCurv/sWQn3M2a4cMU4y5j2YWpp6bkEHWjulEHHOVFs arm+JbIshrnCB0KQZB3GTgW5FCT5M3qkhNklEkv6XLlIBa2IXsk/7fCUeRFP1PE2ktzM0W DJftfZGeHl7hLVTknp154W/mvH/oHG0= 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-232-3Q-pJRhFMKCas3Jx0ZJXvQ-1; Thu, 06 Feb 2020 03:47:04 -0500 Received: from DM5PR1601MB1259.namprd16.prod.outlook.com (10.172.87.13) by DM5PR1601MB1225.namprd16.prod.outlook.com (10.172.89.141) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2707.21; Thu, 6 Feb 2020 08:47:00 +0000 Received: from DM5PR1601MB1259.namprd16.prod.outlook.com ([fe80::5465:6a91:941f:36e0]) by DM5PR1601MB1259.namprd16.prod.outlook.com ([fe80::5465:6a91:941f:36e0%10]) with mapi id 15.20.2707.023; Thu, 6 Feb 2020 08:47:00 +0000 From: "Konda, Tirumaleswar Reddy" To: Warren Kumari , The IESG CC: Roman Danyliw , "dots-chairs@ietf.org" , "valery@smyslov.net" , "dots@ietf.org" , "draft-ietf-dots-architecture@ietf.org" Thread-Topic: [Dots] Warren Kumari's No Objection on draft-ietf-dots-architecture-16: (with COMMENT) Thread-Index: AQHV3EoQeFJubEe7J0uSunHWCfz73KgNvs8Q Date: Thu, 6 Feb 2020 08:47:00 +0000 Message-ID: References: <158092386119.12787.6879612110839501695.idtracker@ietfa.amsl.com> In-Reply-To: <158092386119.12787.6879612110839501695.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-version: 11.4.0.45 dlp-reaction: no-action x-originating-ip: [103.245.47.20] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: fda6206b-921f-4062-071d-08d7aae121cd x-ms-traffictypediagnostic: DM5PR1601MB1225: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0305463112 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(376002)(346002)(136003)(366004)(396003)(39860400002)(189003)(32952001)(199004)(66574012)(54906003)(110136005)(7696005)(4326008)(9686003)(55016002)(966005)(478600001)(86362001)(52536014)(76116006)(5660300002)(66446008)(64756008)(66556008)(66476007)(66946007)(26005)(186003)(71200400001)(53546011)(6506007)(81156014)(8936002)(8676002)(81166006)(33656002)(316002)(2906002)(85282002); DIR:OUT; SFP:1101; SCL:1; SRVR:DM5PR1601MB1225; H:DM5PR1601MB1259.namprd16.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: V2a/PhWlA0BUdjV2KrNCfp5mIryKsHS+iMFdY6iygfEf8MgYK7riURshYd66ydn6vyUgNXH0My97NC20PKeDJoCxg/EVi8yeTknkRTeQVsOrlH4S8roB+dBzHDaMVu1UZCXXEx66W8u7A9jM4dtEzF5vzb5mXmgn6R0NeDqT3+tbbTy0xL9p0OtW30BXM1TW7Xm+gCk7tu0jIzcyki5Oo4gUyV55l2SRAT5O9XYddlQesgqgBJaU3813W60pfCNpRWumrGWYMkAxXhJXRRKfLMWZg5qO6GxTWy/tvr+ow9Nc9f+q+1ufqCzIEfa9Q2wtpoSH9XfpXBIDtdOde8Ukaonls5KztsbDSCfMYuLeL1myh6tlNTMXw0XubKo6o0IQXLh74SXWz/sFunR32+Yfz2LL0Rmhcp6R7EH99lWLFe2/d2QynNzR4HGdiVgA57qnTzioTW3EzX4ZkKZVjJN6g/9XH9ggLqHKBERQzSOmfea91LCNO1ci/YCsOPitGgOKD07V8eQExYFwqd9bq1FM6eqv26dbyBMM5kKoq60kj4tTpeMr6/G9BMPDbqCSF5BLP4RyDpnurnoFZrcXneBA7xuuwtN2fGaSCwR1MjV79Ho= x-ms-exchange-antispam-messagedata: R6pJl52s1Tg6875BKkBQkkSkFuDIS2lVf1sdkF5STYqQWzbu50zsnn/+uPsw/m1nL7O2gl2SDuR4pl6MAUe5o25Hc0YK3IsQ/dWzQNP9l0ryZfTA6nQ0bzNXZNgzN/znekXDRRtk6yqv1yWkiNinVw== x-ms-exchange-transport-forked: True MIME-Version: 1.0 X-OriginatorOrg: mcafee.com X-MS-Exchange-CrossTenant-Network-Message-Id: fda6206b-921f-4062-071d-08d7aae121cd X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Feb 2020 08:47:00.6223 (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: XY6Audu1+aMuleetjGDfAr6J2zemwgbzL7YIOmsYW81rVslxcRrQ3BYQ4+5W9k+S73moA1xcPdLXPb8S+bwrkbKDe1T7gHwyv95iyNdt+5yRXymoPYwsBYD+LZJ2LAAK X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR1601MB1225 X-MC-Unique: 3Q-pJRhFMKCas3Jx0ZJXvQ-1 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: mcafee.com Content-Type: text/plain; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Dots] Warren Kumari's No Objection on draft-ietf-dots-architecture-16: (with COMMENT) 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, 06 Feb 2020 08:48:27 -0000 > -----Original Message----- > From: Dots On Behalf Of Warren Kumari via > Datatracker > Sent: Wednesday, February 5, 2020 11:01 PM > To: The IESG > Cc: Roman Danyliw ; dots-chairs@ietf.org; > valery@smyslov.net; dots@ietf.org; draft-ietf-dots-architecture@ietf.org > Subject: [Dots] Warren Kumari's No Objection on draft-ietf-dots- > architecture-16: (with COMMENT) >=20 > CAUTION: External email. Do not click links or open attachments unless yo= u > recognize the sender and know the content is safe. >=20 > Warren Kumari has entered the following ballot position for > draft-ietf-dots-architecture-16: No Objection >=20 > When responding, please keep the subject line intact and reply to all ema= il > addresses included in the To and CC lines. (Feel free to cut this introdu= ctory > paragraph, however.) >=20 >=20 > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. >=20 >=20 > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-dots-architecture/ >=20 >=20 >=20 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > Firstly, thank you for a well written, and easy to understand document --= I > personally always find architecture type documents helpful... Thanks. >=20 > I do have a few non-blocking comments: > 1: "For example, if the DOTS client domain leverages the DDoS mitigation > service of its Internet Transit Provider (ITP), the ITP knows the prefixe= s > assigned to the DOTS client domain. However, if the DDoS Mitigation is > offered by a third party DDoS mitigation service provider, it does not kn= ow > the resources owned by the DOTS client domain." This is vastly > oversimplifying the real-world, to the point that it is harmful / propaga= tes > dangerous misconceptions. ISPs may or may not know the prefixes assigned > to their customers - they really *should* know the prefixes that the clie= nt is > choosing to announce to them, but the client may have other prefixes whic= h > they only announce through other transits (yes, in this case this ISP wou= ld > only be providing mitigations for prefixes announced to it, but this isn'= t clear). Agreed (the intent of the example is to discuss PA addresses). > In addition, if the DDoS mitigation is provides by a 3rd party, it could = know > what resources are owned by the client -- in fact, it kind of has to if i= t is going > to agree to mitigate for those prefixes.=20 The service level agreement may not include the prefixes used by the DOTS c= lient domain (e.g., Enterprise network may switch ISPs, add new uplinks for= multihoming, ISP renumbering etc.) > Note that I *almost* made this a > DISCUSS point - I really really think that this bit should be either care= fully > revised, or, better yet, just struck... The above text was recently added to address the comment from Gen-ART revie= w, will modify the example as follows: For example, if the DOTS client domain uses Provider-Aggregatable prefixes = for its resources and=20 leverages the DDoS mitigation service of the Internet Transit Provider (ITP= ), the ITP knows the prefixes assigned to the=20 DOTS client domain because they are assigned by the ITP itself. >=20 > 2: "Signal loss is not caused by links congested with attack traffic alon= e, and as > such mitigation requests triggered by signal channel degradation in eithe= r > direction may incur unnecessary costs, in network performance and > operational expense alike." The "operational expense" is vary vague - > enabling DDoS mitigations is almost definitely going to cause a user visi= ble > impact, especially in the case where the mitigator announces a BGP route= to > attract traffic.=20 It depends on the DDoS mitigator capability (for example, scrubbing centers= could be located across the world) or ISP could offer DDoS mitigation serv= ice and the user may not see any noticeable delay in the traffic when the m= itigation is in progress.=20 Further, content providers may use DDoS mitigation service all the time due= to the frequency of attacks. > Is this covered by 'operational expense'?=20 Yes >This section also > leaves out the fact that there is likely a financial impact. Updated line as follows for clarity: Signal loss is not caused by links congested with attack traffic alone, and= as such mitigation requests triggered by signal channel degradation in either direction may incur unnecessary cos= ts due to scrubbing traffic, adversely impact network performance and operational expense alike. >=20 > 3: "The signal and data channels are loosely coupled, and may not termina= te > on the same DOTS server." - s/may not/might not/. Every-time I'm sitting = on > a plane and the safety briefing says that oxygen mask will fall from the = ceiling > and that "the bag may not inflate" I have visions of IETFers (and similar > pedants!) sitting there and squeezing the bag to ensure that it doesn't..= . "the > bag *might* not inflate" is what is intended, and is also what you want := -P Barry raised the same comment, will fix in the next revision. Cheers, -Tiru >=20 >=20 > _______________________________________________ > Dots mailing list > Dots@ietf.org > https://www.ietf.org/mailman/listinfo/dots From nobody Thu Feb 6 01:12: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 AFDE1120013 for ; Thu, 6 Feb 2020 01:12:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, 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 (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 TWDBx4Z27XUP for ; Thu, 6 Feb 2020 01:12:53 -0800 (PST) Received: from us-smtp-delivery-140.mimecast.com (us-smtp-delivery-140.mimecast.com [63.128.21.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 678DF12011E for ; Thu, 6 Feb 2020 01:12:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mcafee.com; s=mimecast20190606; t=1580980372; h=from:from: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=KewdSESqLYdkgOR6Vf+07Z0sfy4oshjvf66DOH5U9ao=; b=gSbxgn/Rgp0EOmOrZLFeYYVYqdrbydBS+2muHaAwMjM+dPtN6MfuYgf7M39tIp26PYT6dH CTbu9jaGi9zagIOTa/zRPg4XGPvyYkgFeArXXBfoAd864QMD2AiSS7I4Aj4/JtjfRWRSHp Id4I29SdKKcwcQA7mw3FhD5eACcgRpc= Received: from NAM10-DM6-obe.outbound.protection.outlook.com (mail-dm6nam10lp2106.outbound.protection.outlook.com [104.47.58.106]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-306-IQShl4gDMmu7DJ92Cc7uBg-1; Thu, 06 Feb 2020 04:12:46 -0500 Received: from DM5PR1601MB1259.namprd16.prod.outlook.com (10.172.87.13) by DM5PR1601MB1273.namprd16.prod.outlook.com (10.172.86.140) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2686.27; Thu, 6 Feb 2020 09:12:44 +0000 Received: from DM5PR1601MB1259.namprd16.prod.outlook.com ([fe80::5465:6a91:941f:36e0]) by DM5PR1601MB1259.namprd16.prod.outlook.com ([fe80::5465:6a91:941f:36e0%10]) with mapi id 15.20.2707.023; Thu, 6 Feb 2020 09:12:44 +0000 From: "Konda, Tirumaleswar Reddy" To: "mohamed.boucadair@orange.com" , Benjamin Kaduk , The IESG CC: Roman Danyliw , "dots-chairs@ietf.org" , "valery@smyslov.net" , "dots@ietf.org" , "draft-ietf-dots-architecture@ietf.org" Thread-Topic: [Dots] Benjamin Kaduk's Yes on draft-ietf-dots-architecture-16: (with COMMENT) Thread-Index: AQHV3LC0tvXwmfcRCEKmrHAz1U5ZWKgNuRiAgAAnpVA= Date: Thu, 6 Feb 2020 09:12:44 +0000 Message-ID: References: <158096794633.30610.7698585491429934350.idtracker@ietfa.amsl.com> <787AE7BB302AE849A7480A190F8B93303142F675@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> In-Reply-To: <787AE7BB302AE849A7480A190F8B93303142F675@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-version: 11.4.0.45 dlp-reaction: no-action x-originating-ip: [103.245.47.20] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 922f160c-c4a6-4b10-f48e-08d7aae4b9ed x-ms-traffictypediagnostic: DM5PR1601MB1273: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0305463112 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(376002)(346002)(136003)(396003)(366004)(39860400002)(199004)(189003)(32952001)(4326008)(76116006)(7696005)(86362001)(8936002)(8676002)(81156014)(81166006)(9686003)(55016002)(478600001)(33656002)(66946007)(71200400001)(66574012)(54906003)(110136005)(316002)(66476007)(66446008)(2906002)(64756008)(66556008)(52536014)(5660300002)(966005)(6506007)(186003)(26005)(53546011)(85282002); DIR:OUT; SFP:1101; SCL:1; SRVR:DM5PR1601MB1273; H:DM5PR1601MB1259.namprd16.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: RTCS4kC9r6qXN0DCUD8NKaq0ChBEX5h4Vm5Zbzthd/X6v7skrdIs5WiQ64PpRU+k8Fz87OQplx7/FJkYucT7I+kDT0Cj+bVYkW1TC06IqK3nthhZqbRp332t9ogxVx4mjUL8EQmjwlfm7cLso3Dwvl+djKbu5hiZSheaUwfByymdFd3RMD3O/mqVQ0Eyc5PLARBJhM1j+EAf6to3pkBaJvkJ5CGvI7gvlfeX2Ipznn5RYTPa15RGKeJpSJOPYhE/lrdrIjJmw0lpdn33ZRDLtWuli7+AXiEpfoeceeyxcCOXx+CJPi4dMWi6y6A2yQnd3Ftisn3rLs388MJZgX0ygHSXqb4VzgKu7vA7vSuton+QNJTE0lauvxEbtP9ff4jiFw+Swv2XKprGp3M/3xgen7GQFzoVoGnhVZMG5railxGYQE4lCzkBLRUtUef5oCjSFqfJWeAJ2dD/Rd3vT2Tak2xHh0EJm8BSRte6jz4Ewmx8KLSJnfSUvkA5pgq1A9Crl3OONqY6KIFGDaYT6pjB9PhNUEVVXKTBW2LDlAUZcI+555HRe9mx3RErsEsEFhCUnvy0r+XjL9GOjbNXbdvkNEgOtYNJdeCcYc/3kU2K5rA= x-ms-exchange-antispam-messagedata: KwJDJjRDSuTPjHllJXj9HpkqQtuX5jE0hJJWGJTjrDKpozWIiNCjSMvTcap4Qr05cABSQ2/2c1E4Zh6TX2lbIwkIeXQbXQvP8Bdv5NCpK/iwQXUcoGiimw9ysbdw7tPEPdqryaDT58l5djl9Z9zLFw== x-ms-exchange-transport-forked: True MIME-Version: 1.0 X-OriginatorOrg: mcafee.com X-MS-Exchange-CrossTenant-Network-Message-Id: 922f160c-c4a6-4b10-f48e-08d7aae4b9ed X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Feb 2020 09:12:44.3660 (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: eBCg7Zg56xtyvZnYXv7oG5FZijaVuakDcl28mRsUevINP2vDrUXFXFx3+c0QBDBdlj333MyzkeEv0hEgVK2sYSScXGi/8DGTQRRV2H1RMuM45BVv7HhTR9M1C7HxKKQs X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR1601MB1273 X-MC-Unique: IQShl4gDMmu7DJ92Cc7uBg-1 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: mcafee.com Content-Type: text/plain; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Dots] Benjamin Kaduk's Yes on draft-ietf-dots-architecture-16: (with COMMENT) 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, 06 Feb 2020 09:12:58 -0000 > -----Original Message----- > From: Dots On Behalf Of > mohamed.boucadair@orange.com > Sent: Thursday, February 6, 2020 12:17 PM > To: Benjamin Kaduk ; The IESG > Cc: Roman Danyliw ; dots-chairs@ietf.org; > valery@smyslov.net; dots@ietf.org; draft-ietf-dots-architecture@ietf.org > Subject: Re: [Dots] Benjamin Kaduk's Yes on draft-ietf-dots-architecture-= 16: > (with COMMENT) >=20 > CAUTION: External email. Do not click links or open attachments unless yo= u > recognize the sender and know the content is safe. >=20 > Hi Ben, >=20 > Please see one comment inline. >=20 > Cheers, > Med >=20 > > -----Message d'origine----- > > De=A0: Dots [mailto:dots-bounces@ietf.org] De la part de Benjamin Kaduk > > via Datatracker Envoy=E9=A0: jeudi 6 f=E9vrier 2020 06:46 =C0=A0: The I= ESG Cc=A0: > > Roman Danyliw; dots-chairs@ietf.org; valery@smyslov.net; > > dots@ietf.org; draft-ietf-dots-architecture@ietf.org > > Objet=A0: [Dots] Benjamin Kaduk's Yes on draft-ietf-dots-architecture- > > 16: (with COMMENT) > > > > Benjamin Kaduk has entered the following ballot position for > > draft-ietf-dots-architecture-16: Yes > > > > When responding, please keep the subject line intact and reply to all > > email addresses included in the To and CC lines. (Feel free to cut > > this introductory paragraph, however.) > > > > > > Please refer to https://www.ietf.org/iesg/statement/discuss- > > criteria.html > > for more information about IESG DISCUSS and COMMENT positions. > > > > > > The document, along with other ballot positions, can be found here: > > https://datatracker.ietf.org/doc/draft-ietf-dots-architecture/ > > > > > > > > ---------------------------------------------------------------------- > > COMMENT: > > ---------------------------------------------------------------------- > > > > Thanks for this well-written document! It's a great high-level > > summary of DOTS and I just have some fairly minor comments. > > > > There might be a bit of mismatch between describing the signal channel > > session as associated with "an ephemeral security association" in > > Section > > 3.1 and as "expected to be long-lived" in Section 3.2.4.1. > > > > Section 2.2.3 > > > > The DOTS gateway MUST perform full stack DOTS session termination > > and > > reorigination between its client and server side. The details of > > how > > this is achieved are implementation specific. The DOTS protocol > > does > > not include any special features related to DOTS gateways, and > > hence > > from a DOTS perspective, whenever a DOTS gateway is present, the > > DOTS > > session simply terminates/originates there. > > > > Does the 'cdid' count as a "special feature"? >=20 > [Med] Good catch. I suggest to delete the last sentence of the above exce= rpt. Works for me. Cheers, -Tiru > (we don't specify how the client and server sides are glued but we do hav= e > feature to avoid loops when GWs are involved, enforce policies on a per > client or domain basis, etc.). >=20 > > > > Section 2.3.1 > > > > An example is a DOTS gateway at the network client's side, and > > another one at the server side. The first gateway can be located > > at > > a CPE to aggregate requests from multiple DOTS clients enabled in > > an > > > > nit: "CPE" does not appear as "well known" at > > https://www.rfc-editor.org/materials/abbrev.expansion.txt and should > > be expanded on first use. > > > > Section 3.2.3 > > > > We could mention that the recursing gateway (e.g., Cn in Figure 12) > > must still be authorized to request mitigation for the resources > > (also) controlled by client Cc (though perhaps the closing discussion > > about there typically being a SLA among client, recursed, and > > recursing domain suffices). > > > > Section 3.2.4.1 > > > > DOTS client to initialize a new DOTS session. This challenge might > > in part be mitigated by use of resumption via a PSK in TLS 1.3 > > [RFC8446] and DTLS 1.3 [I-D.ietf-tls-dtls13] (session resumption in > > TLS 1.2 [RFC5246] and DTLS 1.2 [RFC6347]), but keying material must > > be available to all DOTS servers sharing the anycast Service > > Address > > in that case. > > > > "which has operational challenges of its own", perhaps. > > > > session may involve diverting traffic to a scrubbing center. If > > the > > DOTS session flaps due to anycast changes as described above, > > mitigation may also flap as the DOTS servers sharing the anycast > > DOTS > > service address toggles mitigation on detecting DOTS session loss, > > depending on whether the client has configured mitigation on loss > > of > > signal. > > > > I am not sure if we've mentioned configuring mitigation on loss of > > signal, yet. A forward reference to Section 3.3.3 might help. > > > > Section 3.2.5 > > > > Network address translators (NATs) are expected to be a common > > feature of DOTS deployments. The Middlebox Traversal Guidelines in > > [RFC8085] include general NAT considerations for DOTS deployments > > when the signal channel is established over UDP. > > > > nit: the guidelines in 8085 are not specifically about DOTS > > deployments, so probably we should say "that are applicable to" DOTS > > deployments. > > > > Section 3.2.5.1 > > > > request accurate mitigation scopes. To that aim, the DOTS client > > can > > rely on mechanisms, such as [RFC8512] to retrieve static explicit > > mappings. This document does not prescribe the method by which > > > > nit: no comma. > > > > Section 3.3.3 > > > > The impact of mitigating due to loss of signal in either direction > > must be considered carefully before enabling it. Signal loss is > > not > > caused by links congested with attack traffic alone, and as such > > mitigation requests triggered by signal channel degradation in > > either > > > > nit: I think this could be parsed as "links are congested by attack > > traffic and other traffic", whereas we intend to say that "attack > > traffic is not the only possible cause of link congestion". Perhaps > > "Attack traffic congesting links is not the only reason why signal > > could be lost" is more clear. > > > > Section 5 > > > > DOTS is at risk from three primary attack vectors: agent > > impersonation, traffic injection and signal blocking. These > > vectors > > > > We seem to only partially discuss countermeasures for these attacks in > > the rest of the section; one piece that seems noteworthy in its > > absence is the requirement (already described in the body text) to > > authenticate the peer and perform authorization checks on client > > requests. Mitigating against signal blocking is in general hard, but > > we could consider mentioning again that the automated mitigation on > > loss of signal discussed in Section > > 3.3.3 > > is an option, albeit one with risks of its own. > > > > Section 8.2 > > > > One could perhaps argue that RFC 4033 and RFC 6887 should be normative > > ("[RFC4033] must be used where [...]", "[RFC6887] may be used to > > [...]"). > > > > There's a stronger case that RFC 4786 should be normative, as we use a > > BCP > > 14 keyword allowing its deployment. > > > > > > _______________________________________________ > > Dots mailing list > > Dots@ietf.org > > https://www.ietf.org/mailman/listinfo/dots >=20 > _______________________________________________ > Dots mailing list > Dots@ietf.org > https://www.ietf.org/mailman/listinfo/dots From nobody Thu Feb 6 03:08:57 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 73709120918 for ; Thu, 6 Feb 2020 03:08:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, 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 (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 xxGnrbYPyUZr for ; Thu, 6 Feb 2020 03:08:50 -0800 (PST) Received: from us-smtp-delivery-140.mimecast.com (us-smtp-delivery-140.mimecast.com [63.128.21.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 7DA17120905 for ; Thu, 6 Feb 2020 03:08:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mcafee.com; s=mimecast20190606; t=1580987329; h=from:from: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=xYAxRzpy7LQUhwk3neBTArVCvyGmf3RcnOdRx0V6eHc=; b=P3mdYyrBqW9478qNe2T+BRCt1N1clKyHkHKlIz7eDSHFbkcqszSOC74qWDXoEFPgmOI3Ah YNpwd1Lh7ZgLZr76nrlD3sdhqulMRSgVTjQZwp8w4DwT17/wUjd1JSJwb5ondF6pxlkRLD yekKpdIrr3yZ9+I+DrFkog5gEW7yka8= Received: from NAM02-SN1-obe.outbound.protection.outlook.com (mail-sn1nam02lp2059.outbound.protection.outlook.com [104.47.36.59]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-10-92qLifzEPeazT5-YoTYcbw-1; Thu, 06 Feb 2020 06:08:42 -0500 Received: from CY4PR1601MB1254.namprd16.prod.outlook.com (10.172.118.12) by CY4PR1601MB1285.namprd16.prod.outlook.com (10.172.118.137) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2707.21; Thu, 6 Feb 2020 11:08:40 +0000 Received: from CY4PR1601MB1254.namprd16.prod.outlook.com ([fe80::e851:20e8:57bd:fedd]) by CY4PR1601MB1254.namprd16.prod.outlook.com ([fe80::e851:20e8:57bd:fedd%12]) with mapi id 15.20.2707.024; Thu, 6 Feb 2020 11:08:40 +0000 From: "Konda, Tirumaleswar Reddy" To: Benjamin Kaduk , The IESG CC: Roman Danyliw , "dots-chairs@ietf.org" , "valery@smyslov.net" , "dots@ietf.org" , "draft-ietf-dots-architecture@ietf.org" Thread-Topic: [Dots] Benjamin Kaduk's Yes on draft-ietf-dots-architecture-16: (with COMMENT) Thread-Index: AQHV3LC0tvXwmfcRCEKmrHAz1U5ZWKgN4miw Date: Thu, 6 Feb 2020 11:08:40 +0000 Message-ID: References: <158096794633.30610.7698585491429934350.idtracker@ietfa.amsl.com> In-Reply-To: <158096794633.30610.7698585491429934350.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-version: 11.4.0.45 dlp-reaction: no-action x-originating-ip: [103.245.47.20] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 58fd6e02-d082-4455-fed4-08d7aaf4ebfa x-ms-traffictypediagnostic: CY4PR1601MB1285: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 0305463112 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(346002)(366004)(376002)(39860400002)(396003)(136003)(189003)(199004)(32952001)(66476007)(71200400001)(53546011)(33656002)(2906002)(5660300002)(6506007)(76116006)(966005)(478600001)(66556008)(86362001)(66946007)(66446008)(52536014)(26005)(64756008)(186003)(316002)(110136005)(54906003)(55016002)(9686003)(81166006)(7696005)(8676002)(81156014)(8936002)(4326008)(85282002); DIR:OUT; SFP:1101; SCL:1; SRVR:CY4PR1601MB1285; H:CY4PR1601MB1254.namprd16.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: ZjvjB5GXhWcG7F6MJzNasSOe4nMpFuw2HcCszV86Rmrg12loiItegipCV/F9xRNs+WXx01R9Jl6ZoqSNbEB6vWZhrB5Jag4lwQHCCxLMITsv0p6gwI2GvFN/VPG5KoKyKIQhQbTnxVy3IbpIKTucKQ5nYvd8h5x85cFRRhv9SXv8oMlgcShp9m+1l5GGRORbTIqfAPrF349AHwKSdzCuFEzvgdI/ZJWf1EgXptG0jnq6N3+uOaTyDM5p1y3O5y5ltaEleNKPOzPZ5wwDduVBhhaJVbyA4l4DZV1magHqFxbcIvlwsJ37qWOSUzcNY1e7kpjhW+qZ3OdyMS1z8jWQh6JnwT0n2yuurKEBoecLVbcLFEOpARd1EFDRuZzzN3SfopzjlHWVW9PwG64eVUM/CwDrYPRn3a2GuafD/4uDjSDGXvqXDOqjf8FgPlVKwwlT0rKucEmzuZrYIN1d29146zpYeVBMVMKy98RaodBFQZDyIy9OMSI68VQdjKAUwAMbpxMuwzdcOQLM8zG7CDUbrGy5UzMEYmeWXa49IJi6DgcGiuq3DdhxE/XSuf64EaWH5taqHE6nZGd/CKQ8Zu8rr4XIzDwyxtGSdlyVN+SPyj4= x-ms-exchange-antispam-messagedata: 8n1TAZ5tngEu8i57fZAX2iU9HPWDGRhggFGIrHmh9racwav9AW8gOqrAjP/jestCqBUhLuFX+sz+O6nhoG8LOT2jZ1ZuB4KeLA10hZN4zYNFIAIZZJTWZPpjnso/TX0gNu0BkVLGMcXYozYUsPFFvQ== x-ms-exchange-transport-forked: True MIME-Version: 1.0 X-OriginatorOrg: mcafee.com X-MS-Exchange-CrossTenant-Network-Message-Id: 58fd6e02-d082-4455-fed4-08d7aaf4ebfa X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Feb 2020 11:08:40.2522 (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: tHxEuwWxL+HfMFxfrlnqRebH6F/kpVj4jL/bjYa78mFv90HUQQq0R4qAEMjaHG9/tcTjZ0pn/9ZO6JNQRvvZSEep83eaAK2CvGLyAzH3V9xBc0uXbtnFVuhpDNCI1y0x X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR1601MB1285 X-MC-Unique: 92qLifzEPeazT5-YoTYcbw-1 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: mcafee.com Content-Type: text/plain; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Dots] Benjamin Kaduk's Yes on draft-ietf-dots-architecture-16: (with COMMENT) 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, 06 Feb 2020 11:08:55 -0000 Hi Ben, Please see inline > -----Original Message----- > From: Dots On Behalf Of Benjamin Kaduk via > Datatracker > Sent: Thursday, February 6, 2020 11:16 AM > To: The IESG > Cc: Roman Danyliw ; dots-chairs@ietf.org; > valery@smyslov.net; dots@ietf.org; draft-ietf-dots-architecture@ietf.org > Subject: [Dots] Benjamin Kaduk's Yes on draft-ietf-dots-architecture-16: > (with COMMENT) >=20 > CAUTION: External email. Do not click links or open attachments unless yo= u > recognize the sender and know the content is safe. >=20 > Benjamin Kaduk has entered the following ballot position for > draft-ietf-dots-architecture-16: Yes >=20 > When responding, please keep the subject line intact and reply to all ema= il > addresses included in the To and CC lines. (Feel free to cut this introdu= ctory > paragraph, however.) >=20 >=20 > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. >=20 >=20 > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-dots-architecture/ >=20 >=20 >=20 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > Thanks for this well-written document! It's a great high-level summary o= f > DOTS and I just have some fairly minor comments. >=20 > There might be a bit of mismatch between describing the signal channel > session as associated with "an ephemeral security association" in Section > 3.1 and as "expected to be long-lived" in Section 3.2.4.1. Good catch, removed "ephemeral".=20 >=20 > Section 2.2.3 >=20 > The DOTS gateway MUST perform full stack DOTS session termination and > reorigination between its client and server side. The details of how > this is achieved are implementation specific. The DOTS protocol does > not include any special features related to DOTS gateways, and hence > from a DOTS perspective, whenever a DOTS gateway is present, the DOTS > session simply terminates/originates there. >=20 > Does the 'cdid' count as a "special feature"? Yes, removed the last line.=20 >=20 > Section 2.3.1 >=20 > An example is a DOTS gateway at the network client's side, and > another one at the server side. The first gateway can be located at > a CPE to aggregate requests from multiple DOTS clients enabled in an >=20 > nit: "CPE" does not appear as "well known" at https://www.rfc- > editor.org/materials/abbrev.expansion.txt and should be expanded on first > use. Fixed.=20 >=20 > Section 3.2.3 >=20 > We could mention that the recursing gateway (e.g., Cn in Figure 12) must = still > be authorized to request mitigation for the resources (also) controlled b= y > client Cc (though perhaps the closing discussion about there typically be= ing a > SLA among client, recursed, and recursing domain suffices). Good point, updated text as follows: Typically there is a contractual Service Level Agreement (SLA) negotiated a= mong the DOTS client domain, the recursed domain and the recursing domain=20 to meet the privacy requirements of the DOTS client domain and authorizatio= n for the=20 recursing domain to request mitigation for the resources controlled by the = DOTS client domain. >=20 > Section 3.2.4.1 >=20 > DOTS client to initialize a new DOTS session. This challenge might > in part be mitigated by use of resumption via a PSK in TLS 1.3 > [RFC8446] and DTLS 1.3 [I-D.ietf-tls-dtls13] (session resumption in > TLS 1.2 [RFC5246] and DTLS 1.2 [RFC6347]), but keying material must > be available to all DOTS servers sharing the anycast Service Address > in that case. >=20 > "which has operational challenges of its own", perhaps. Sure, updated. >=20 > session may involve diverting traffic to a scrubbing center. If the > DOTS session flaps due to anycast changes as described above, > mitigation may also flap as the DOTS servers sharing the anycast DOTS > service address toggles mitigation on detecting DOTS session loss, > depending on whether the client has configured mitigation on loss of > signal. >=20 > I am not sure if we've mentioned configuring mitigation on loss of signal= , yet. > A forward reference to Section 3.3.3 might help. Done.=20 >=20 > Section 3.2.5 >=20 > Network address translators (NATs) are expected to be a common > feature of DOTS deployments. The Middlebox Traversal Guidelines in > [RFC8085] include general NAT considerations for DOTS deployments > when the signal channel is established over UDP. >=20 > nit: the guidelines in 8085 are not specifically about DOTS deployments, = so > probably we should say "that are applicable to" DOTS deployments. Fixed.=20 >=20 > Section 3.2.5.1 >=20 > request accurate mitigation scopes. To that aim, the DOTS client can > rely on mechanisms, such as [RFC8512] to retrieve static explicit > mappings. This document does not prescribe the method by which >=20 > nit: no comma. Okay. >=20 > Section 3.3.3 >=20 > The impact of mitigating due to loss of signal in either direction > must be considered carefully before enabling it. Signal loss is not > caused by links congested with attack traffic alone, and as such > mitigation requests triggered by signal channel degradation in either >=20 > nit: I think this could be parsed as "links are congested by attack traff= ic and > other traffic", whereas we intend to say that "attack traffic is not the = only > possible cause of link congestion". Perhaps "Attack traffic congesting l= inks is > not the only reason why signal could be lost" is more clear. Thanks, updated.=20 >=20 > Section 5 >=20 > DOTS is at risk from three primary attack vectors: agent > impersonation, traffic injection and signal blocking. These vectors >=20 > We seem to only partially discuss countermeasures for these attacks in th= e > rest of the section; one piece that seems noteworthy in its absence is th= e > requirement (already described in the body text) to authenticate the peer > and perform authorization checks on client requests. Mitigating against > signal blocking is in general hard, but we could consider mentioning agai= n that > the automated mitigation on loss of signal discussed in Section 3.3.3 is = an > option, albeit one with risks of its own. Added the following lines: DOTS agents MUST perform mutual authentication to ensure authenticity of each other and DOTS servers MUST verify that the requesting DOTS client is authorized to request mitigation for specific target resources (see Section 2.2.2). An MITM attacker can intercept and drop packets, preventing the DOTS peers from receiving some or all of the DOTS messages, automated mitigation on loss of signal can be used as a countermeasure but with risks discussed in Section 3.3.3. >=20 > Section 8.2 >=20 > One could perhaps argue that RFC 4033 and RFC 6887 should be normative > ("[RFC4033] must be used where [...]", "[RFC6887] may be used to [...]"). Moved.=20 >=20 > There's a stronger case that RFC 4786 should be normative, as we use a BC= P > 14 keyword allowing its deployment. Done. Cheers, -Tiru >=20 >=20 > _______________________________________________ > Dots mailing list > Dots@ietf.org > https://www.ietf.org/mailman/listinfo/dots From nobody Thu Feb 6 17:22:42 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 3F7B112011D; Thu, 6 Feb 2020 17:22:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, 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 R2tQNuqeAYKd; Thu, 6 Feb 2020 17:22:36 -0800 (PST) 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 DB1FD12013B; Thu, 6 Feb 2020 17:22:35 -0800 (PST) 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 0171MTZs024446 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 6 Feb 2020 20:22:31 -0500 Date: Thu, 6 Feb 2020 17:22:28 -0800 From: Benjamin Kaduk To: "Konda, Tirumaleswar Reddy" Cc: The IESG , Roman Danyliw , "dots-chairs@ietf.org" , "valery@smyslov.net" , "dots@ietf.org" , "draft-ietf-dots-architecture@ietf.org" Message-ID: <20200207012228.GK14382@kduck.mit.edu> References: <158096794633.30610.7698585491429934350.idtracker@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] Benjamin Kaduk's Yes on draft-ietf-dots-architecture-16: (with COMMENT) 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, 07 Feb 2020 01:22:40 -0000 Hi Tiru, Thanks for the updates; these all look good. -Ben On Thu, Feb 06, 2020 at 11:08:40AM +0000, Konda, Tirumaleswar Reddy wrote: > Hi Ben, > > Please see inline > > > -----Original Message----- > > From: Dots On Behalf Of Benjamin Kaduk via > > Datatracker > > Sent: Thursday, February 6, 2020 11:16 AM > > To: The IESG > > Cc: Roman Danyliw ; dots-chairs@ietf.org; > > valery@smyslov.net; dots@ietf.org; draft-ietf-dots-architecture@ietf.org > > Subject: [Dots] Benjamin Kaduk's Yes on draft-ietf-dots-architecture-16: > > (with COMMENT) > > > > CAUTION: External email. Do not click links or open attachments unless you > > recognize the sender and know the content is safe. > > > > Benjamin Kaduk has entered the following ballot position for > > draft-ietf-dots-architecture-16: Yes > > > > When responding, please keep the subject line intact and reply to all email > > addresses included in the To and CC lines. (Feel free to cut this introductory > > paragraph, however.) > > > > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > > for more information about IESG DISCUSS and COMMENT positions. > > > > > > The document, along with other ballot positions, can be found here: > > https://datatracker.ietf.org/doc/draft-ietf-dots-architecture/ > > > > > > > > ---------------------------------------------------------------------- > > COMMENT: > > ---------------------------------------------------------------------- > > > > Thanks for this well-written document! It's a great high-level summary of > > DOTS and I just have some fairly minor comments. > > > > There might be a bit of mismatch between describing the signal channel > > session as associated with "an ephemeral security association" in Section > > 3.1 and as "expected to be long-lived" in Section 3.2.4.1. > > Good catch, removed "ephemeral". > > > > > Section 2.2.3 > > > > The DOTS gateway MUST perform full stack DOTS session termination and > > reorigination between its client and server side. The details of how > > this is achieved are implementation specific. The DOTS protocol does > > not include any special features related to DOTS gateways, and hence > > from a DOTS perspective, whenever a DOTS gateway is present, the DOTS > > session simply terminates/originates there. > > > > Does the 'cdid' count as a "special feature"? > > Yes, removed the last line. > > > > > Section 2.3.1 > > > > An example is a DOTS gateway at the network client's side, and > > another one at the server side. The first gateway can be located at > > a CPE to aggregate requests from multiple DOTS clients enabled in an > > > > nit: "CPE" does not appear as "well known" at https://www.rfc- > > editor.org/materials/abbrev.expansion.txt and should be expanded on first > > use. > > Fixed. > > > > > Section 3.2.3 > > > > We could mention that the recursing gateway (e.g., Cn in Figure 12) must still > > be authorized to request mitigation for the resources (also) controlled by > > client Cc (though perhaps the closing discussion about there typically being a > > SLA among client, recursed, and recursing domain suffices). > > Good point, updated text as follows: > > Typically there is a contractual Service Level Agreement (SLA) negotiated among > the DOTS client domain, the recursed domain and the recursing domain > to meet the privacy requirements of the DOTS client domain and authorization for the > recursing domain to request mitigation for the resources controlled by the DOTS client domain. > > > > > Section 3.2.4.1 > > > > DOTS client to initialize a new DOTS session. This challenge might > > in part be mitigated by use of resumption via a PSK in TLS 1.3 > > [RFC8446] and DTLS 1.3 [I-D.ietf-tls-dtls13] (session resumption in > > TLS 1.2 [RFC5246] and DTLS 1.2 [RFC6347]), but keying material must > > be available to all DOTS servers sharing the anycast Service Address > > in that case. > > > > "which has operational challenges of its own", perhaps. > > Sure, updated. > > > > > session may involve diverting traffic to a scrubbing center. If the > > DOTS session flaps due to anycast changes as described above, > > mitigation may also flap as the DOTS servers sharing the anycast DOTS > > service address toggles mitigation on detecting DOTS session loss, > > depending on whether the client has configured mitigation on loss of > > signal. > > > > I am not sure if we've mentioned configuring mitigation on loss of signal, yet. > > A forward reference to Section 3.3.3 might help. > > Done. > > > > > Section 3.2.5 > > > > Network address translators (NATs) are expected to be a common > > feature of DOTS deployments. The Middlebox Traversal Guidelines in > > [RFC8085] include general NAT considerations for DOTS deployments > > when the signal channel is established over UDP. > > > > nit: the guidelines in 8085 are not specifically about DOTS deployments, so > > probably we should say "that are applicable to" DOTS deployments. > > Fixed. > > > > > Section 3.2.5.1 > > > > request accurate mitigation scopes. To that aim, the DOTS client can > > rely on mechanisms, such as [RFC8512] to retrieve static explicit > > mappings. This document does not prescribe the method by which > > > > nit: no comma. > > Okay. > > > > > Section 3.3.3 > > > > The impact of mitigating due to loss of signal in either direction > > must be considered carefully before enabling it. Signal loss is not > > caused by links congested with attack traffic alone, and as such > > mitigation requests triggered by signal channel degradation in either > > > > nit: I think this could be parsed as "links are congested by attack traffic and > > other traffic", whereas we intend to say that "attack traffic is not the only > > possible cause of link congestion". Perhaps "Attack traffic congesting links is > > not the only reason why signal could be lost" is more clear. > > Thanks, updated. > > > > > Section 5 > > > > DOTS is at risk from three primary attack vectors: agent > > impersonation, traffic injection and signal blocking. These vectors > > > > We seem to only partially discuss countermeasures for these attacks in the > > rest of the section; one piece that seems noteworthy in its absence is the > > requirement (already described in the body text) to authenticate the peer > > and perform authorization checks on client requests. Mitigating against > > signal blocking is in general hard, but we could consider mentioning again that > > the automated mitigation on loss of signal discussed in Section 3.3.3 is an > > option, albeit one with risks of its own. > > Added the following lines: > > DOTS agents MUST perform mutual authentication to ensure authenticity > of each other and DOTS servers MUST verify that the requesting DOTS > client is authorized to request mitigation for specific target > resources (see Section 2.2.2). > > An MITM attacker can intercept and drop packets, preventing the DOTS > peers from receiving some or all of the DOTS messages, automated > mitigation on loss of signal can be used as a countermeasure but with > risks discussed in Section 3.3.3. > > > > > Section 8.2 > > > > One could perhaps argue that RFC 4033 and RFC 6887 should be normative > > ("[RFC4033] must be used where [...]", "[RFC6887] may be used to [...]"). > > Moved. > > > > > There's a stronger case that RFC 4786 should be normative, as we use a BCP > > 14 keyword allowing its deployment. > > Done. > > Cheers, > -Tiru > > > > > > > _______________________________________________ > > Dots mailing list > > Dots@ietf.org > > https://www.ietf.org/mailman/listinfo/dots > From nobody Fri Feb 7 02:49:34 2020 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54EED12084D for ; Fri, 7 Feb 2020 02:49:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 QCtyKsHnKstq for ; Fri, 7 Feb 2020 02:49:29 -0800 (PST) Received: from us-smtp-delivery-140.mimecast.com (us-smtp-delivery-140.mimecast.com [63.128.21.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 691FF120838 for ; Fri, 7 Feb 2020 02:49:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mcafee.com; s=mimecast20190606; t=1581072568; 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=g4jG8FOKosu99IGvB21vIMu8cz2EG8DuCQevd7N0m4o=; b=ek1qtHqG5u/U47vwx5049YST9a8UFujqd+/eYaez70wRnWEpjfxSMbGIhCHyQHwh1jCV+5 IquLV1F6aoYQ1k3BLda6zYQTbNGOZ8SfQ+f/5RLxh22/7YErAupIqomf9Zr3jggk+2Kbah wy337MFt+ARpb8YOB0jnT7UnBcwPf58= Received: from NAM11-BN8-obe.outbound.protection.outlook.com (mail-bn8nam11lp2169.outbound.protection.outlook.com [104.47.58.169]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-18-DjkXwhBzMV68OBCErikxBQ-1; Fri, 07 Feb 2020 05:49:26 -0500 Received: from CY4PR1601MB1254.namprd16.prod.outlook.com (10.172.118.12) by CY4PR1601MB1141.namprd16.prod.outlook.com (10.172.117.15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2707.21; Fri, 7 Feb 2020 10:49:25 +0000 Received: from CY4PR1601MB1254.namprd16.prod.outlook.com ([fe80::e851:20e8:57bd:fedd]) by CY4PR1601MB1254.namprd16.prod.outlook.com ([fe80::e851:20e8:57bd:fedd%12]) with mapi id 15.20.2707.024; Fri, 7 Feb 2020 10:49:25 +0000 From: "Konda, Tirumaleswar Reddy" To: "mohamed.boucadair@orange.com" , Jon Shallow , "dots@ietf.org" Thread-Topic: [Dots] I-D Action: draft-ietf-dots-telemetry-01.txt Thread-Index: AQHV2EX1YQ9eUkWY2E+gQ7j9EgylIKgE4pYAgARXvICAAvfD0IAA4c4AgACrzQCAAdgt8A== Date: Fri, 7 Feb 2020 10:49:25 +0000 Message-ID: References: <158048229416.21195.16114328651657501634@ietfa.amsl.com> <787AE7BB302AE849A7480A190F8B93303141473A@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B933031414F55@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <0a3001d5dc62$37f49820$a7ddc860$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93303142D65C@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> In-Reply-To: <787AE7BB302AE849A7480A190F8B93303142D65C@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-version: 11.4.0.45 dlp-reaction: no-action x-originating-ip: [49.37.206.28] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 0d73fa0b-9028-45dc-5d9f-08d7abbb65eb x-ms-traffictypediagnostic: CY4PR1601MB1141: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 0306EE2ED4 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(39860400002)(396003)(346002)(376002)(136003)(366004)(199004)(189003)(32952001)(8676002)(81156014)(81166006)(66574012)(71200400001)(86362001)(52536014)(8936002)(33656002)(110136005)(316002)(66946007)(76116006)(9686003)(66476007)(64756008)(66446008)(26005)(66556008)(478600001)(5660300002)(186003)(6506007)(55016002)(53546011)(2906002)(7696005)(85282002); DIR:OUT; SFP:1101; SCL:1; SRVR:CY4PR1601MB1141; H:CY4PR1601MB1254.namprd16.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: Tuko8gvv50eQ48l1Bl+Ou7zPLvaEXLECOFnkor3iN+Glor0Mv3OeYY/BvXs96B8nY5Yl+Vl99mndIWo/uHd+y5/l4qePvxr0Y8kUAZHRS2MIivuf21xyMiUmWCY+KSfUyRrDfywtxsotbH2bTiRzVn0wabMOXPH74efokxryVSi41TtZFccWNld1ogjNfWzgNenS+81+mBgRy9o16b4ifykRG2VOo6V009aUsyFud5bqZBnUbyTI5SUfLigYihwnujNW7v55LwIGn7aykbGvmAExaqGfhO5KqUBw2PPNLgYBjA+7eNipP7ZBOA+BSXQeP2basBD65xVc+DUIv46c2FTyjHW+YubvFHXQfBzG03QHQIn9vonirDc3W/4Hw/bMDIkhuQQxn+IYeoo6yun2lv/5WJIMw/Jc9ZMw7eX11VdOB/wC/nPWuCeWG7VMwruWRw8jE4Uzh5OliAHgvZ2mracD3jm6+eGZiI4bWAeppml7ljayv9mv1BP8fU4s9vAUeoMMvS+onVJBi2qFGyxfPA== x-ms-exchange-antispam-messagedata: yj//R4BaM0QEDnfuF44sw+FEVTCdqF27WAXQE4tzzWQmJHTmh2hibuB8H4vIhS5S3rv0t4HZzTqsqZ0Vh5tlsCGLhdgjzkZWewUPMF3dpoWUnol4ZOxqpsjsyYcrnxqESMRcFhFknVXyt/xW8+N46w== x-ms-exchange-transport-forked: True MIME-Version: 1.0 X-OriginatorOrg: mcafee.com X-MS-Exchange-CrossTenant-Network-Message-Id: 0d73fa0b-9028-45dc-5d9f-08d7abbb65eb X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Feb 2020 10:49:25.2242 (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: RUjK5HTZafIJIP01VEncHE0BmnTK+CRGHmouDNXA57k3tN93m0hEbjKc0qfaDwD94rzX2O7dbuPz8qqz+cJrjHKGmRva5D+9GZnfbYGYQjjk9Bf1LV+1X3048wIzf4aN X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR1601MB1141 X-MC-Unique: DjkXwhBzMV68OBCErikxBQ-1 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: mcafee.com Content-Type: text/plain; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Dots] I-D Action: draft-ietf-dots-telemetry-01.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, 07 Feb 2020 10:49:32 -0000 > -----Original Message----- > From: mohamed.boucadair@orange.com > > Sent: Thursday, February 6, 2020 12:09 PM > To: Jon Shallow ; Konda, Tirumaleswar Reddy > ; dots@ietf.org > Subject: RE: [Dots] I-D Action: draft-ietf-dots-telemetry-01.txt >=20 > CAUTION: External email. Do not click links or open attachments unless yo= u > recognize the sender and know the content is safe. >=20 > Hi Jon, all, >=20 > Please see inline. >=20 > Cheers, > Med >=20 > > -----Message d'origine----- > > De=A0: Jon Shallow [mailto:supjps-ietf@jpshallow.com] > > Envoy=E9=A0: mercredi 5 f=E9vrier 2020 21:24 =C0=A0: 'Konda, Tirumalesw= ar > > Reddy'; BOUCADAIR Mohamed TGI/OLN; dots@ietf.org Objet=A0: RE: [Dots] > > I-D Action: draft-ietf-dots-telemetry-01.txt > > > > See inline > > > > Regards > > > > Jon > > > ... > > > > > > > > (1) key value range for telemetry: Jon raised this point "These > > keys > > > requires 3 > > > > bytes - and telemetry information is going to be difficult to fit > > into a > > > packet. I > > > > appreciate that comprehension-required Is for numbers less than > > 0x8000 - > > > > perhaps the comprehension-required range is reduced and also has a > > > section > > > > higher up so the total of 0x8000 still stands so less bytes can be > > used > > > here." > > > > > > > > +----------------------+-------+-------+------------+---------- > > -----+ > > > > | Parameter Name | CBOR | CBOR | Change | > > Specification | > > > > | | Key | Major | Controller | > > Document(s) | > > > > | | Value | Type | | > > | > > > > +----------------------+-------+-------+------------+---------- > > -----+ > > > > | ietf-dots-signal-cha | 32776 | 5 | IESG | > > [RFCXXXX] | > > > > | nnel:telemetry | | | | > > | > > > > > > > > Med: This is a major one. We need to assess the gain, but it is > > possible > > in > > > > theory to update our assignment policies and reassign, e.g., 128- > > 255 > > range > > > to > > > > be comprehension-optional (specific for telemetry). This would > > mean that > > > > the telemetry spec will be tagged as updating the base signal > > channel > > > spec. > > > > We need more discussion. > > > > > > Why not change the DOTS telemetry attributes to comprehension- > > required > > > ? >=20 > [Med] Telemetry attributes are not mandatory for the signal channel to > function. A signal channel message enriched with telemetry data should no= t > exacerbate message failure. >=20 > > > If the server does not understand the DOTS telemetry attributes, it > > will > > > respond with 4.00 error response, and the client can re-send the > > request > > > without the DOTS telemetry attributes. > > > > Jon> Telemetry is also gated by a different sets of Path-URIs. >=20 > [Med] Except when telemetry is also included in an update during a > mitigation (S-C or S-C). What I have for this one in my local copy is as = follows: >=20 > In order to make use of this feature, DOTS clients MUST establish a > telemetry setup session with the DOTS server in 'idle' time and MUST > set the 'server-originated-telemetry' attribute to 'true'. >=20 > DOTS servers MUST NOT include telemetry attributes in mitigation > status updates sent to DOTS clients for which 'server-originated- > telemetry' attribute is set to 'false'. >=20 > > However, > > source-prefix attribute comes from draft-ietf-dots-signal-call-home > > and also occupies 3 bytes - do we change the source-prefix CBOR Key > > type to comprehension-required? > > >=20 > [Med] Including a source prefix in a signal channel message while not > supported by the server must not lead to an error. That attribute cannot = be > set a comprehension-required. I suggest we don't touch that part. Works for me. -Tiru From nobody Fri Feb 7 03:03:39 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 CF4FE120241; Fri, 7 Feb 2020 03:03:36 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Meeting Session Request Tool To: Cc: dots-chairs@ietf.org, valery@smyslov.net, dots@ietf.org, kaduk@mit.edu X-Test-IDTracker: no X-IETF-IDTracker: 6.117.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <158107341684.11751.4682397207908451391.idtracker@ietfa.amsl.com> Date: Fri, 07 Feb 2020 03:03:36 -0800 Archived-At: Subject: [Dots] dots - Not having a session at IETF 107 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, 07 Feb 2020 11:03:37 -0000 Valery Smyslov, a chair of the dots working group, indicated that the dots working group does not plan to hold a session at IETF 107. This message was generated and sent by the IETF Meeting Session Request Tool. From nobody Fri Feb 7 04:01:20 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 DFC2F120822; Fri, 7 Feb 2020 04:01:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.2 X-Spam-Level: X-Spam-Status: No, score=-1.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_SORBS_WEB=1.5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no 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 uRYdTkuZDrkC; Fri, 7 Feb 2020 04:01:16 -0800 (PST) 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 51992120639; Fri, 7 Feb 2020 04:01:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=smyslov.net ; s=default; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Message-ID :Date:Subject:In-Reply-To:References:Cc:To:From:Sender:Reply-To: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=rgMQ1/RRRWT0siV3hl+xNGmiz2O3kQTsjwAkP6I6KSk=; b=xdhFDRpWwaH+UEGAdIOAoWlhjx 4U6T7aZ99EdsKDaCdvxPqL+tNenEXd6oXohCEUzaBsfPoL3AEUf/eFIi1yaaFfimZitaM062FlhjC q+EHfrfOVySVMY8eb+1ibnUBBGkVnYXZ1HyrQL9rz8DmwyCZSuvGcbBHxXATPJ18td4tZHX3twVvL fJE02p93g7ccM/I0RnKWGPOa8ydrejpf2gcq1fSO+qQhNkDYQpBnFjoqTIBY4HtsJD5fDyZKNXxyZ ZsGKdVfE/iy/smOFEL05uGwYTRU6p0vTKqibX4eZCGhX6e8/XsYGgX0dmMeXUF0511HW7JbvzMyLD 4JQexpYg==; Received: from [82.138.51.4] (port=65497 helo=buildpc) by direct.host-care.com with esmtpsa (TLSv1:ECDHE-RSA-AES256-SHA:256) (Exim 4.92) (envelope-from ) id 1j02Js-0003rM-DR; Fri, 07 Feb 2020 07:01:13 -0500 From: "Valery Smyslov" To: , Cc: "'Konda, Tirumaleswar Reddy'" , References: <158107341684.11751.4682397207908451391.idtracker@ietfa.amsl.com> <787AE7BB302AE849A7480A190F8B93303143256B@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> In-Reply-To: <787AE7BB302AE849A7480A190F8B93303143256B@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> Date: Fri, 7 Feb 2020 15:01:12 +0300 Message-ID: <033701d5ddae$4cb66ed0$e6234c70$@smyslov.net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQKEa0slrABeUwzhw3RWHt+Fm8EXjwHlND8gpqNYTQA= 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 X-Source: X-Source-Args: X-Source-Dir: Archived-At: Subject: Re: [Dots] dots - Not having a session at IETF 107 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, 07 Feb 2020 12:01:18 -0000 Hi Med, we think that there is currently only one WG draft (dots-telemetry) that = is under active development. We didn't see any discussion on dots-related individual drafts and on = dots-multihoming draft.=20 We think that one draft it is not enough to hold a full WG meeting. We = decided not to meet at IETF107=20 to concentrate on working in the WG mailing list, so that we have more = topics to discuss in Madrid. Regards, Frank & Valery. > Hi Valery, >=20 > Is there any reason why no session is requested? >=20 > Thank you. >=20 > Cheers, > Med >=20 > > -----Message d'origine----- > > De=A0: Dots [mailto:dots-bounces@ietf.org] De la part de IETF = Meeting > > Session Request Tool > > Envoy=E9=A0: vendredi 7 f=E9vrier 2020 12:04 > > =C0=A0: session-request@ietf.org > > Cc=A0: dots-chairs@ietf.org; valery@smyslov.net; dots@ietf.org; > > kaduk@mit.edu > > Objet=A0: [Dots] dots - Not having a session at IETF 107 > > > > > > > > Valery Smyslov, a chair of the dots working group, indicated that = the > > dots working group does not plan to hold a session at IETF 107. > > > > This message was generated and sent by the IETF Meeting Session > > Request Tool. > > > > > > _______________________________________________ > > Dots mailing list > > Dots@ietf.org > > https://www.ietf.org/mailman/listinfo/dots From nobody Fri Feb 7 04:25:41 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 AE75412025D; Fri, 7 Feb 2020 04:25:39 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: dots@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.117.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: dots@ietf.org Message-ID: <158107833962.11726.6724811945133845235@ietfa.amsl.com> Date: Fri, 07 Feb 2020 04:25:39 -0800 Archived-At: Subject: [Dots] I-D Action: draft-ietf-dots-telemetry-02.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, 07 Feb 2020 12:25:40 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DDoS Open Threat Signaling WG of the IETF. Title : Distributed Denial-of-Service Open Threat Signaling (DOTS) Telemetry Authors : Mohamed Boucadair Tirumaleswar Reddy Ehud Doron Meiling Chen Filename : draft-ietf-dots-telemetry-02.txt Pages : 74 Date : 2020-02-07 Abstract: This document aims to enrich DOTS signal channel protocol with various telemetry attributes allowing optimal DDoS attack mitigation. This document specifies the normal traffic baseline and attack traffic telemetry attributes a DOTS client can convey to its DOTS server in the mitigation request, the mitigation status telemetry attributes a DOTS server can communicate to a DOTS client, and the mitigation efficacy telemetry attributes a DOTS client can communicate to a DOTS server. The telemetry attributes can assist the mitigator to choose the DDoS mitigation techniques and perform optimal DDoS attack mitigation. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dots-telemetry/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-dots-telemetry-02 https://datatracker.ietf.org/doc/html/draft-ietf-dots-telemetry-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dots-telemetry-02 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 Feb 7 04:34:24 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 812CF120227 for ; Fri, 7 Feb 2020 04:34:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 7Vj3SKWBT1hG for ; Fri, 7 Feb 2020 04:34:21 -0800 (PST) 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 624371200F9 for ; Fri, 7 Feb 2020 04:34:21 -0800 (PST) Received: from opfednr07.francetelecom.fr (unknown [xx.xx.xx.71]) by opfednr24.francetelecom.fr (ESMTP service) with ESMTP id 48DZVg5ZmWz1yYg for ; Fri, 7 Feb 2020 13:34:19 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1581078859; bh=rXuXbWm4SYST4e55b+udBBSi2lpIn6/1pQLLWOK7lF4=; h=From:To:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=M2hZqeHOunZtLMCeqS8sfSO7t4SbpFcHiN8NKcYBD2FTbIjAFIQojOIVqjPNoGDts zuy2peT/W7zS/wJshk2ZZvQft4KwACvNgVYuyw2+9LIKnhkbA8X8pdh4/nNcrQZ+5X BH6gjKOm6W8joT8v1Jj+tADHDgmUOhgzSt8hvGjPGX2qLSY36fFim7qtRqKC+HBwy9 DAx/tlhVoVfj7KBQfy0tBhT11yvr2OK65IZKNeB/riFzJn4VKwz1ydrWGPN2T/DpgR atVdl9M0ruh+w6YuYMptODrHv5PjgiondB5CiBg8+lkMsTwfTB8FsE7g0x2/OW8zrT QYC/m+TBoqgkg== Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.54]) by opfednr07.francetelecom.fr (ESMTP service) with ESMTP id 48DZVg4WXCzFpYV for ; Fri, 7 Feb 2020 13:34:19 +0100 (CET) Received: from OPEXCAUBMA2.corporate.adroot.infra.ftgroup ([fe80::e878:bd0:c89e:5b42]) by OPEXCAUBM7D.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0468.000; Fri, 7 Feb 2020 13:34:19 +0100 From: To: "dots@ietf.org" Thread-Topic: [Dots] I-D Action: draft-ietf-dots-telemetry-02.txt Thread-Index: AQHV3bG6FpgywlTjR0O64/8c/zAJ+qgPqJcw Date: Fri, 7 Feb 2020 12:34:18 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B9330314325AD@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> References: <158107833962.11726.6724811945133845235@ietfa.amsl.com> In-Reply-To: <158107833962.11726.6724811945133845235@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-02.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, 07 Feb 2020 12:34:24 -0000 Hi all, As promised last week, this new version focuses on Sections 7 & 8. Also, th= is version integrates comments received from Jon. A diff is provided below = to track the changes. Now that we have all the pieces glued together, we will start tweaking the = behavior. The draft includes a set of open issues that we hope to solve in = the next iterations.=20 Please review and share your comments. Note for the implementers: we removed the cbor values from the draft we are= maintaining a table to be used for interops. The table can be seen at: htt= ps://github.com/boucadair/draft-dots-telemetry/blob/master/mapping-table.tx= t=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 7 f=E9vrier 2020 13:26 > =C0=A0: i-d-announce@ietf.org > Cc=A0: dots@ietf.org > Objet=A0: [Dots] I-D Action: draft-ietf-dots-telemetry-02.txt >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the DDoS Open Threat Signaling WG of the > IETF. >=20 > Title : Distributed Denial-of-Service Open Threat > Signaling (DOTS) Telemetry > Authors : Mohamed Boucadair > Tirumaleswar Reddy > Ehud Doron > Meiling Chen > Filename : draft-ietf-dots-telemetry-02.txt > Pages : 74 > Date : 2020-02-07 >=20 > Abstract: > This document aims to enrich DOTS signal channel protocol with > various telemetry attributes allowing optimal DDoS attack > mitigation. > This document specifies the normal traffic baseline and attack > traffic telemetry attributes a DOTS client can convey to its DOTS > server in the mitigation request, the mitigation status telemetry > attributes a DOTS server can communicate to a DOTS client, and the > mitigation efficacy telemetry attributes a DOTS client can > communicate to a DOTS server. The telemetry attributes can assist > the mitigator to choose the DDoS mitigation techniques and perform > optimal DDoS attack mitigation. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-dots-telemetry/ >=20 > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-dots-telemetry-02 > https://datatracker.ietf.org/doc/html/draft-ietf-dots-telemetry-02 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dots-telemetry-02 >=20 >=20 > Please note that it may take a couple of minutes from the time of > submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > Dots mailing list > Dots@ietf.org > https://www.ietf.org/mailman/listinfo/dots From nobody Fri Feb 7 04:38: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 3C842120091; Fri, 7 Feb 2020 04:38:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 1RYZJHp-SUJM; Fri, 7 Feb 2020 04:38:41 -0800 (PST) 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 550961200F9; Fri, 7 Feb 2020 04:38:41 -0800 (PST) Received: from opfedar00.francetelecom.fr (unknown [xx.xx.xx.11]) by opfedar27.francetelecom.fr (ESMTP service) with ESMTP id 48DZbg3TCCz2xWl; Fri, 7 Feb 2020 13:38:39 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1581079119; bh=MVUtBf0uIP9w9NgD7N2kWCmOwrbPbNOZtcEZtjehuuA=; h=From:To:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=RlovemviP9K99iF3dznNRmo+DpO/QTPKSJYw1fCGWkmgyxyqdJqBO8hfF1ZRy+lFL Ae/ZYB9QCcyFq2V86/W4DN2rxlP9Imuq4X/Z1UniYjcQ9KpAiKrFvGGSrAsYv1aaoG 1drDH9Wn2rkrCT2/iL2Lf91F1AjIalhXhQgq9K/GqK9uL+XWqWimVR1hEo50Z87mQ1 8nM53NgIy5UQZQENOjjGfa3UmjSg770rjL/YUVhgBwh+S72Wtimyy9ZI/+MRSvkibT JNG+uwiYSXuv3l1KuMijVwOyno5BPse+eUWi207LhtHa2ebPQZBoFcByssdxfdrKw7 0CzRCIaWJTbCg== Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.82]) by opfedar00.francetelecom.fr (ESMTP service) with ESMTP id 48DZbg2GvQzCqks; Fri, 7 Feb 2020 13:38:39 +0100 (CET) Received: from OPEXCAUBMA2.corporate.adroot.infra.ftgroup ([fe80::e878:bd0:c89e:5b42]) by OPEXCAUBM5E.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0468.000; Fri, 7 Feb 2020 13:38:39 +0100 From: To: Valery Smyslov , "dots-chairs@ietf.org" CC: "'Konda, Tirumaleswar Reddy'" , "dots@ietf.org" Thread-Topic: [Dots] dots - Not having a session at IETF 107 Thread-Index: AQKEa0slrABeUwzhw3RWHt+Fm8EXjwHlND8gpqNYTQCAAA2hEA== Date: Fri, 7 Feb 2020 12:38:38 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B9330314325C1@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> References: <158107341684.11751.4682397207908451391.idtracker@ietfa.amsl.com> <787AE7BB302AE849A7480A190F8B93303143256B@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <033701d5ddae$4cb66ed0$e6234c70$@smyslov.net> In-Reply-To: <033701d5ddae$4cb66ed0$e6234c70$@smyslov.net> 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] dots - Not having a session at IETF 107 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, 07 Feb 2020 12:38:43 -0000 Re-, That's fair.=20 We can have a side meeting among those of us who will attend the IETF#107 m= eeting.=20 Cheers, Med > -----Message d'origine----- > De=A0: Valery Smyslov [mailto:valery@smyslov.net] > Envoy=E9=A0: vendredi 7 f=E9vrier 2020 13:01 > =C0=A0: BOUCADAIR Mohamed TGI/OLN; dots-chairs@ietf.org > Cc=A0: 'Konda, Tirumaleswar Reddy'; dots@ietf.org > Objet=A0: RE: [Dots] dots - Not having a session at IETF 107 >=20 > Hi Med, >=20 > we think that there is currently only one WG draft (dots-telemetry) > that is under active development. > We didn't see any discussion on dots-related individual drafts and on > dots-multihoming draft. > We think that one draft it is not enough to hold a full WG meeting. We > decided not to meet at IETF107 > to concentrate on working in the WG mailing list, so that we have more > topics to discuss in Madrid. >=20 > Regards, > Frank & Valery. >=20 > > Hi Valery, > > > > Is there any reason why no session is requested? > > > > Thank you. > > > > Cheers, > > Med > > > > > -----Message d'origine----- > > > De=A0: Dots [mailto:dots-bounces@ietf.org] De la part de IETF > Meeting > > > Session Request Tool > > > Envoy=E9=A0: vendredi 7 f=E9vrier 2020 12:04 > > > =C0=A0: session-request@ietf.org > > > Cc=A0: dots-chairs@ietf.org; valery@smyslov.net; dots@ietf.org; > > > kaduk@mit.edu > > > Objet=A0: [Dots] dots - Not having a session at IETF 107 > > > > > > > > > > > > Valery Smyslov, a chair of the dots working group, indicated that > the > > > dots working group does not plan to hold a session at IETF 107. > > > > > > This message was generated and sent by the IETF Meeting Session > > > Request Tool. > > > > > > > > > _______________________________________________ > > > Dots mailing list > > > Dots@ietf.org > > > https://www.ietf.org/mailman/listinfo/dots From nobody Fri Feb 7 05:21:40 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 973B812083F; Fri, 7 Feb 2020 05:21:38 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: dots@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.117.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: dots@ietf.org Message-ID: <158108169855.11593.11339621036867180747@ietfa.amsl.com> Date: Fri, 07 Feb 2020 05:21:38 -0800 Archived-At: Subject: [Dots] I-D Action: draft-ietf-dots-server-discovery-10.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, 07 Feb 2020 13:21:38 -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) Agent Discovery Authors : Mohamed Boucadair Tirumaleswar Reddy Filename : draft-ietf-dots-server-discovery-10.txt Pages : 24 Date : 2020-02-07 Abstract: It may not be possible for a network to determine the cause for an attack, but instead just realize that some resources seem to be under attack. To fill that gap, Distributed-Denial-of-Service Open Threat Signaling (DOTS) allows a network to inform a DOTS server that it is under a potential attack so that appropriate mitigation actions are undertaken. This document specifies mechanisms to configure DOTS clients with their DOTS servers. The discovery procedure also covers the DOTS Signal Channel Call Home. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dots-server-discovery/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-dots-server-discovery-10 https://datatracker.ietf.org/doc/html/draft-ietf-dots-server-discovery-10 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dots-server-discovery-10 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Feb 7 05:30:01 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 21491120859 for ; Fri, 7 Feb 2020 05:29:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 U9coi7BSrFL9 for ; Fri, 7 Feb 2020 05:29:58 -0800 (PST) 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 A013F12002E for ; Fri, 7 Feb 2020 05:29:57 -0800 (PST) Received: from opfedar00.francetelecom.fr (unknown [xx.xx.xx.11]) by opfedar26.francetelecom.fr (ESMTP service) with ESMTP id 48Dbkr0KRDzFqCn; Fri, 7 Feb 2020 14:29:56 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1581082196; bh=uC/m8Hb1qIEzcm75DCFwoa/JaWYBA7a5vDSr3+4GEp4=; h=From:To:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=rc/mjDEqX6JAbwSs5ZsaZ2YmxphT12cEnZ16Cers4kY9o3aEz/lk/knhnYva1beKg fN67Ty7diz2PBmNc2BCrnvB1ds5OUhlC345oZhi5e1Jsgfo4kLpj+hVy7B64vL2ibG E5AK+WmjlsqrW4Zj1jv+QZtchD3HOiH2KZAsGJXK44QLlDnbgdZdTrS0cYwd/JvGUY 6JHXFCWbe6+Fe2shC+x7dqFORmw9yN9sLeh6dSrB8jsCDxHE5plPu0NI7aX1XNuFUH aRggy97bKwpp2eKxHfUuk2zpwicAGK+MIPrbp3nS1fWH1dQG1oCpU1wrEdOWpK+eJB rxt/BzknHu4lQ== Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.73]) by opfedar00.francetelecom.fr (ESMTP service) with ESMTP id 48Dbkq6P95zCqmS; Fri, 7 Feb 2020 14:29:55 +0100 (CET) Received: from OPEXCAUBMA2.corporate.adroot.infra.ftgroup ([fe80::e878:bd0:c89e:5b42]) by OPEXCAUBM23.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0468.000; Fri, 7 Feb 2020 14:29:55 +0100 From: To: "dots@ietf.org" CC: "Benjamin Kaduk (kaduk@mit.edu)" Thread-Topic: [Dots] I-D Action: draft-ietf-dots-server-discovery-10.txt Thread-Index: AQHV3bmLtBqj+KxRdUCsxXdvXaqBXagPt8Sg Date: Fri, 7 Feb 2020 13:29:55 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B933031432620@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> References: <158108169855.11593.11339621036867180747@ietfa.amsl.com> In-Reply-To: <158108169855.11593.11339621036867180747@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-server-discovery-10.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, 07 Feb 2020 13:29:59 -0000 Hi all,=20 We made some changes to take into account an implementation feedback we rec= eived. The mechanisms in the draft are implemented (thanks Jon!).=20 The changes are minor but they enhance the document. This is why we prefer = to submit this new version even if the I-D is waiting for Ben's review.=20 Cheers, Med > -----Message d'origine----- > De=A0: Dots [mailto:dots-bounces@ietf.org] De la part de internet- > drafts@ietf.org > Envoy=E9=A0: vendredi 7 f=E9vrier 2020 14:22 > =C0=A0: i-d-announce@ietf.org > Cc=A0: dots@ietf.org > Objet=A0: [Dots] I-D Action: draft-ietf-dots-server-discovery-10.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) Agent Discovery > Authors : Mohamed Boucadair > Tirumaleswar Reddy > Filename : draft-ietf-dots-server-discovery-10.txt > Pages : 24 > Date : 2020-02-07 >=20 > Abstract: > It may not be possible for a network to determine the cause for an > attack, but instead just realize that some resources seem to be > under > attack. To fill that gap, Distributed-Denial-of-Service Open > Threat > Signaling (DOTS) allows a network to inform a DOTS server that it > is > under a potential attack so that appropriate mitigation actions are > undertaken. >=20 > This document specifies mechanisms to configure DOTS clients with > their DOTS servers. The discovery procedure also covers the DOTS > Signal Channel Call Home. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-dots-server-discovery/ >=20 > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-dots-server-discovery-10 > https://datatracker.ietf.org/doc/html/draft-ietf-dots-server- > discovery-10 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dots-server-discovery-10 >=20 >=20 > Please note that it may take a couple of minutes from the time of > submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > Dots mailing list > Dots@ietf.org > https://www.ietf.org/mailman/listinfo/dots From nobody Fri Feb 7 05:56:39 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 C35ED120048; Fri, 7 Feb 2020 05:56:34 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: dots@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.117.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: dots@ietf.org Message-ID: <158108379475.11718.7476978745913546716@ietfa.amsl.com> Date: Fri, 07 Feb 2020 05:56:34 -0800 Archived-At: Subject: [Dots] I-D Action: draft-ietf-dots-architecture-17.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, 07 Feb 2020 13:56:35 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DDoS Open Threat Signaling WG of the IETF. Title : Distributed-Denial-of-Service Open Threat Signaling (DOTS) Architecture Authors : Andrew Mortensen Tirumaleswar Reddy Flemming Andreasen Nik Teague Rich Compton Filename : draft-ietf-dots-architecture-17.txt Pages : 36 Date : 2020-02-07 Abstract: This document describes an architecture for establishing and maintaining Distributed Denial of Service (DDoS) Open Threat Signaling (DOTS) within and between domains. The document does not specify protocols or protocol extensions, instead focusing on defining architectural relationships, components and concepts used in a DOTS deployment. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dots-architecture/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-dots-architecture-17 https://datatracker.ietf.org/doc/html/draft-ietf-dots-architecture-17 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dots-architecture-17 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Feb 7 06:06: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 2CD60120086 for ; Fri, 7 Feb 2020 06:06:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 QztFOhycz_nJ for ; Fri, 7 Feb 2020 06:06:42 -0800 (PST) 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 D5046120048 for ; Fri, 7 Feb 2020 06:06:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mcafee.com; s=mimecast20190606; t=1581084400; 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=f3M4zLAxFWe+7R0rkCSco7QTM+WKWfQ3ytsiT9wROg0=; b=fCcWe5kZYRbhwasCkBRfRQKCCz+ndS/gNgvjDG+mzFIFxzNYIRiTl273ZkQiS+LvoyzVhQ 3ztbP4aN6SwABK2oDUNtu9EBOwlXK+2mjM3mlop2CL+DHiyI+vxPRKcjey3AM1OnmdrHI3 b0irpW0pgqdcwLObxMu0V6OzJ+uopjs= Received: from NAM12-DM6-obe.outbound.protection.outlook.com (mail-dm6nam12lp2176.outbound.protection.outlook.com [104.47.59.176]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-47-G34T-61PPjKhSJ0bcyb-MA-1; Fri, 07 Feb 2020 09:06:24 -0500 Received: from CY4PR1601MB1254.namprd16.prod.outlook.com (10.172.118.12) by CY4PR1601MB1253.namprd16.prod.outlook.com (10.172.115.146) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2707.23; Fri, 7 Feb 2020 14:06:22 +0000 Received: from CY4PR1601MB1254.namprd16.prod.outlook.com ([fe80::e851:20e8:57bd:fedd]) by CY4PR1601MB1254.namprd16.prod.outlook.com ([fe80::e851:20e8:57bd:fedd%12]) with mapi id 15.20.2707.024; Fri, 7 Feb 2020 14:06:22 +0000 From: "Konda, Tirumaleswar Reddy" To: "dots@ietf.org" , Roman Danyliw , Benjamin Kaduk Thread-Topic: [Dots] I-D Action: draft-ietf-dots-architecture-17.txt Thread-Index: AQHV3b581a0EtdzNR06yIidlWFHHhqgPw7GA Date: Fri, 7 Feb 2020 14:06:22 +0000 Message-ID: References: <158108379475.11718.7476978745913546716@ietfa.amsl.com> In-Reply-To: <158108379475.11718.7476978745913546716@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-version: 11.4.0.45 dlp-reaction: no-action x-originating-ip: [49.37.206.28] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 1d09ebbb-f527-47b0-e0fe-08d7abd6e9be x-ms-traffictypediagnostic: CY4PR1601MB1253: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:6108; x-forefront-prvs: 0306EE2ED4 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(396003)(39860400002)(136003)(366004)(376002)(346002)(199004)(32952001)(189003)(52536014)(316002)(26005)(66946007)(64756008)(66446008)(66556008)(66476007)(186003)(8676002)(8936002)(7696005)(81166006)(81156014)(71200400001)(5660300002)(478600001)(966005)(33656002)(53546011)(66574012)(6506007)(110136005)(86362001)(9686003)(55016002)(2906002)(76116006)(85282002); DIR:OUT; SFP:1101; SCL:1; SRVR:CY4PR1601MB1253; H:CY4PR1601MB1254.namprd16.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: bxKf/2qNzeUgvbdyqcNmAgOLAQsd6D2Isv7FNNkaG6JOFEDJMfHuchTKQKxMPo+3ohrK4pDXscd2G1RofZXBhDiv2o4cBXbVMtkYfZW8bjFB/YrBbfETSu1sN/hbLQRMNzLCSHLcd4NkKfi30ockq3tKloCWCn3WYyBhqVx5F4VnplTT0u2Pa6/CoX2slFXlvWUU2HAM3fBsIk3lGDR1Xq0cGN9VER6QgJo1Zm2Hw/aGxwbmt0zqLX39JYR0u7ieedYWR4ilBlYJCgo/klA8F00A/h/ZdqjzUW2EoIQfC+1HfWO589vQIjmiwVqlxHIn3X+azLl4L0J0SE5gFs4x4IRvyPW0A6aSGa5wzT0VPFO13Lh14TATf5c0oc1CiuL1YhWrhx/d0IMyLcsnHNqTeiGBoL/GYxns5YXZMftq0hsUcYcVKMHekyb8Y59LxOM6dDHaSMNN07D0DXQ/B9/IJZUE5jzOQEazRrkvVDrjbWuZTT/fSFKF8eUhJqg0VqSf0KmoYXDYX7USlnmTxxWDXMkXc4tCzYMgCDz/2DCAqx2JKC+5X3PQ4UipvmWZHZx1Y3UQqoKaS7xWMQl+8C1GcdFj4HxGscl+IaJML6rGaRQ= x-ms-exchange-antispam-messagedata: SonPjrksTHwRRM+PqqC4m+XXuv8Mn8hYHl/ajU3iH9s8iDVV8VwGjRBWiPnhGcrLt7mHXrNc7BnbguCaoVgQ3Pw2xngTsLDCIsf3btYcq06hLIEkZfMSYwD6/keyBDTrtCNqrMdo/1ON1LsGcdH/3A== x-ms-exchange-transport-forked: True MIME-Version: 1.0 X-OriginatorOrg: mcafee.com X-MS-Exchange-CrossTenant-Network-Message-Id: 1d09ebbb-f527-47b0-e0fe-08d7abd6e9be X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Feb 2020 14:06:22.8556 (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: G9ZPEc1mZ9YpXcpzzJdwGRjAESgLB1AEb6iGzEMKl7LrRvGD2xnC1612l6Ja4MgzZobUjwbwQ/E9Znde81hvaTP/VeY1rw3dnlPfAtynZfA8oBauK7UWcuh4XQB82IYu X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR1601MB1253 X-MC-Unique: G34T-61PPjKhSJ0bcyb-MA-1 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: mcafee.com Content-Type: text/plain; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Dots] I-D Action: draft-ietf-dots-architecture-17.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, 07 Feb 2020 14:06:44 -0000 This revision addresses comments from ISEG review.=20 Cheers, -Tiru > -----Original Message----- > From: Dots On Behalf Of internet-drafts@ietf.org > Sent: Friday, February 7, 2020 7:27 PM > To: i-d-announce@ietf.org > Cc: dots@ietf.org > Subject: [Dots] I-D Action: draft-ietf-dots-architecture-17.txt >=20 > CAUTION: External email. Do not click links or open attachments unless yo= u > recognize the sender and know the content is safe. >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. > This draft is a work item of the DDoS Open Threat Signaling WG of the IET= F. >=20 > Title : Distributed-Denial-of-Service Open Threat Signa= ling (DOTS) > Architecture > Authors : Andrew Mortensen > Tirumaleswar Reddy > Flemming Andreasen > Nik Teague > Rich Compton > =09Filename : draft-ietf-dots-architecture-17.txt > =09Pages : 36 > =09Date : 2020-02-07 >=20 > Abstract: > This document describes an architecture for establishing and > maintaining Distributed Denial of Service (DDoS) Open Threat > Signaling (DOTS) within and between domains. The document does not > specify protocols or protocol extensions, instead focusing on > defining architectural relationships, components and concepts used in > a DOTS deployment. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-dots-architecture/ >=20 > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-dots-architecture-17 > https://datatracker.ietf.org/doc/html/draft-ietf-dots-architecture-17 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dots-architecture-17 >=20 >=20 > Please note that it may take a couple of minutes from the time of submiss= ion > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > Dots mailing list > Dots@ietf.org > https://www.ietf.org/mailman/listinfo/dots From nobody Thu Feb 13 17:47:48 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 A211E120046; Thu, 13 Feb 2020 17:47:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 gotFThEVCLK9; Thu, 13 Feb 2020 17:47:45 -0800 (PST) Received: from guri.nttv6.jp (guri.nttv6.jp [115.69.228.140]) by ietfa.amsl.com (Postfix) with ESMTP id 108A9120805; Thu, 13 Feb 2020 17:47:45 -0800 (PST) Received: from z.nttv6.jp (z.nttv6.jp [IPv6:2402:c800:ff06:6::f]) by guri.nttv6.jp (NTTv6MTA) with ESMTP id B4D6625F6B8; Fri, 14 Feb 2020 10:47:41 +0900 (JST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nttv6.jp; s=20180820; t=1581644861; 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=W7O+mTXdTr+tTpg9Ro9CVBnfdcRQ0EL8/Un7yd3wnZI=; b=TmmkYBzZoyyap6JNLykMdoEZgp/26m+p49nNapW3yR4zNlxEzgh2+QbeFKoUh0qTqBtvrN QCck+kBOj/ZQn7r6c6wFspze52/W5BmX9KJecgrYpkPRkeM6wxhwT52IFMcrn/sLqHJeUL AA/GyrQNluSX5URX63UF6DBKOtJER4c= Received: from MacBook-Pro-17.local (fujiko.nttv6.jp [IPv6:2402:c800:ff06:136::141]) by z.nttv6.jp (NTTv6MTA) with ESMTP id 8F5877634E4; Fri, 14 Feb 2020 10:47:41 +0900 (JST) To: mohamed.boucadair@orange.com, Valery Smyslov , "dots-chairs@ietf.org" Cc: "'Konda, Tirumaleswar Reddy'" , "dots@ietf.org" References: <158107341684.11751.4682397207908451391.idtracker@ietfa.amsl.com> <787AE7BB302AE849A7480A190F8B93303143256B@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <033701d5ddae$4cb66ed0$e6234c70$@smyslov.net> <787AE7BB302AE849A7480A190F8B9330314325C1@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> From: kaname nishizuka Message-ID: Date: Fri, 14 Feb 2020 10:47:41 +0900 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:68.0) Gecko/20100101 Thunderbird/68.4.2 MIME-Version: 1.0 In-Reply-To: <787AE7BB302AE849A7480A190F8B9330314325C1@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] dots - Not having a session at IETF 107 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, 14 Feb 2020 01:47:48 -0000 Yes, I'll join. regards, kaname On 2020/02/07 21:38, mohamed.boucadair@orange.com wrote: > Re-, > > That's fair. > > We can have a side meeting among those of us who will attend the IETF#107 meeting. > > Cheers, > Med > >> -----Message d'origine----- >> De : Valery Smyslov [mailto:valery@smyslov.net] >> Envoyé : vendredi 7 février 2020 13:01 >> À : BOUCADAIR Mohamed TGI/OLN; dots-chairs@ietf.org >> Cc : 'Konda, Tirumaleswar Reddy'; dots@ietf.org >> Objet : RE: [Dots] dots - Not having a session at IETF 107 >> >> Hi Med, >> >> we think that there is currently only one WG draft (dots-telemetry) >> that is under active development. >> We didn't see any discussion on dots-related individual drafts and on >> dots-multihoming draft. >> We think that one draft it is not enough to hold a full WG meeting. We >> decided not to meet at IETF107 >> to concentrate on working in the WG mailing list, so that we have more >> topics to discuss in Madrid. >> >> Regards, >> Frank & Valery. >> >>> Hi Valery, >>> >>> Is there any reason why no session is requested? >>> >>> Thank you. >>> >>> Cheers, >>> Med >>> >>>> -----Message d'origine----- >>>> De : Dots [mailto:dots-bounces@ietf.org] De la part de IETF >> Meeting >>>> Session Request Tool >>>> Envoyé : vendredi 7 février 2020 12:04 >>>> À : session-request@ietf.org >>>> Cc : dots-chairs@ietf.org; valery@smyslov.net; dots@ietf.org; >>>> kaduk@mit.edu >>>> Objet : [Dots] dots - Not having a session at IETF 107 >>>> >>>> >>>> >>>> Valery Smyslov, a chair of the dots working group, indicated that >> the >>>> dots working group does not plan to hold a session at IETF 107. >>>> >>>> This message was generated and sent by the IETF Meeting Session >>>> Request Tool. >>>> >>>> >>>> _______________________________________________ >>>> Dots mailing list >>>> Dots@ietf.org >>>> https://www.ietf.org/mailman/listinfo/dots > _______________________________________________ > Dots mailing list > Dots@ietf.org > https://www.ietf.org/mailman/listinfo/dots From nobody Thu Feb 20 23:00: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 DF9AC120033 for ; Thu, 20 Feb 2020 23:00:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 vBjle6d76Zn0 for ; Thu, 20 Feb 2020 23:00:11 -0800 (PST) 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 306081200FF for ; Thu, 20 Feb 2020 23:00:11 -0800 (PST) Received: from opfednr03.francetelecom.fr (unknown [xx.xx.xx.67]) by opfednr24.francetelecom.fr (ESMTP service) with ESMTP id 48P2Qc6rF3z1yVc; Fri, 21 Feb 2020 08:00:08 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1582268409; bh=ddUkHCqRAPyAyXphHoKzegfEQ2kweRX2C5N8l9bubzA=; h=From:To:Subject:Date:Message-ID:Content-Type:MIME-Version; b=TipHcVmxaUbnU5DGf4s3YlkJWmGAgsWWdISlhhsuLQcZo17iDh4J3/pPF68ZFFLCE Mrtz+hhOe0NltUoYjMbvmy/8i7FJfSNVB+kfqLqIaS6qnUPIb0BgS4rEcerazwPMMG VmC4t4dtOXgjVWXRKZJbZx1WDy6crm/+13MhrFuqHYwcpB4VPNsaYtDIAOaqG86vUi HLSgM9bN+F/EIwQC/0fGxM27e6Qbs1Dbumeys5FO2TutrzWcSiyiaE9bybIqkvY+sP iXW3PAQp7tVOJDC9hLlQDVPwb96CGYhLVLAKlKDHYVDP54NeHh6X5w2NS42qkW5USO ET3jsBgpXpwAw== Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.101]) by opfednr03.francetelecom.fr (ESMTP service) with ESMTP id 48P2Qc61dmzDq7v; Fri, 21 Feb 2020 08:00:08 +0100 (CET) Received: from OPEXCAUBMA2.corporate.adroot.infra.ftgroup ([fe80::e878:bd0:c89e:5b42]) by OPEXCAUBM6F.corporate.adroot.infra.ftgroup ([fe80::c489:b768:686a:545b%23]) with mapi id 14.03.0468.000; Fri, 21 Feb 2020 08:00:08 +0100 From: To: Jon Shallow , "Konda, Tirumaleswar Reddy" , kaname nishizuka CC: "dots@ietf.org" Thread-Topic: DOTS telemetry questions Thread-Index: AdXoMF1Myh1CUH9JQYWfs7E2CgsnOAATeuaw Date: Fri, 21 Feb 2020 07:00:07 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93303143DAF8@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> References: <188801d5e830$635d97d0$2a18c770$@jpshallow.com> In-Reply-To: <188801d5e830$635d97d0$2a18c770$@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: multipart/alternative; boundary="_000_787AE7BB302AE849A7480A190F8B93303143DAF8OPEXCAUBMA2corp_" MIME-Version: 1.0 Archived-At: Subject: Re: [Dots] DOTS telemetry questions X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Feb 2020 07:00:23 -0000 --_000_787AE7BB302AE849A7480A190F8B93303143DAF8OPEXCAUBMA2corp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Jon, (ccing the WG to track the changes). Please see inline. Cheers, Med De : Jon Shallow [mailto:supjps-ietf@jpshallow.com] Envoy=E9 : jeudi 20 f=E9vrier 2020 21:58 =C0 : BOUCADAIR Mohamed TGI/OLN; Konda, Tirumaleswar Reddy; kaname nishizuk= a Objet : DOTS telemetry questions Hi Guys, 1) For example CBOR mappings Header: PUT (Code=3D0.03) Uri-Path: ".well-known" Uri-Path: "dots" Uri-Path: "mitigate" Uri-Path: "cuid=3Ddz6pHjaADkaFTbjr0JGBpw" Uri-Path: "mid=3D123" If-Match: Content-Format: "application/dots+cbor" { "ietf-dots-signal-channel:mitigation-scope": { "scope": [ { "alias-name": [ "myserver" ], "attack-status": "under-attack", "ietf-dots-telemetry:total-attack-traffic": [ { "ietf-dots-telemetry:unit": "megabytes-ps", "ietf-dots-telemetry:mid-percentile-g": "900" } ] } ] } } Figure 33: An Example of Mitigation Efficacy Update with Telemetry Attributes And yet the mapping table only has (no ietf-dots-telemetry: prefix) | total-attack-traffic | list |32794 | 4 array | Array | I appreciate that ietf-dots-telemetry:total-attack-traffic and total-attack= traffic are the same CBOR value (or are they?) [Med] The same value is used but I didn't check if there are side effects. Please note that we have this note is section 10: =3D=3D o Some of these attributes should be prepended with "ietf-dots- telemetry:" =3D=3D but when mapping the CBOR back to JSON the variant of JSON parameter is con= text (Uri-Path: mitigate or tm) dependent. 2) why do we not have a "enum megabit-ps" in "typedef unit" in the YAN= G Module? [Med] This can be added to the list as 'units()' are negotiated. *-bytes a= re more used for aggregates, but let's be consistent and have both bit/byte= s in the units. 3) I think that I have worked out that server-originated-telemetry if = set allows telemetry included in the mitigation status rather than only ret= urned using Uri-path: tm - correct? [Med] I confirm. Note that including pre-mitigation returned using "Uri-pat= h:tm" is controlled by PUT/GET (Section 7.3). 4) I am confused by "pre-mitigation" which can be transmitted pre any = mitigation taking place, or actually during when mitigation is taking place= (or so I think) and would simply be better described as "attack-details" -= especially with a statement such as DOTS agents MUST bind pre-mitigation telemetry data with mitigation requests relying upon the target clause. [Med] That's an option but the current design allows to have the telemetry = in // in order to supply more data ** without impacting the placement of a = mitigation request ** hence the need to bind both (if any). If telemetry at= tributes are defined as mandatory (discussed in another thread), this would= mean that the server will reject a mitigation that includes such attribute= s. With the current design, we have a functionality that can be safely enab= led independently of the decision that we will make about whether telemetry= attributes are mandatory to be supported or not. Another point we can check to ease correlation between a mitigation request= and pre-mitigation telemetry is to signal the "mid" in the telemetry messa= ge. Regards Jon --_000_787AE7BB302AE849A7480A190F8B93303143DAF8OPEXCAUBMA2corp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Jon,

 

(ccing the WG to track the changes).

 

Please see inline.

 

Cheers,

Med

 

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

 

Hi Guys,

 

1= )   &= nbsp;  For example CBOR mappin= gs

 

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

     Uri-Path: ".we= ll-known"

     Uri-Path: "dot= s"

     Uri-Path: "mit= igate"

     Uri-Path: "cui= d=3Ddz6pHjaADkaFTbjr0JGBpw"

     Uri-Path: "mid= =3D123"

     If-Match:

     Content-Format: &qu= ot;application/dots+cbor"

 

     {=

      "ietf-do= ts-signal-channel:mitigation-scope": {

        &= quot;scope": [

       &n= bsp;  {

       &n= bsp;    "alias-name": [

       &n= bsp;       "myserver"

       &n= bsp;     ],

       &n= bsp;    "attack-status": "under-attack",=

       &n= bsp;    "ietf-dots-telemetry:total-attack-traffic= ": [

       &n= bsp;      {

       &n= bsp;        "ietf-dots-telemetry:un= it": "megabytes-ps",

       &n= bsp;        "ietf-dots-telemetry:mi= d-percentile-g": "900"

       &n= bsp;      }

       &n= bsp;    ]

       &n= bsp;  }

        ]=

      }<= /span>

     }=

 

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

       &n= bsp;            = ;            Attribu= tes

 

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

 

  &= nbsp; | total-attack-traffic | list      &nbs= p; |32794 | 4 array       | Array  |=

 

I appreciate that ietf-dots-tel= emetry:total-attack-traffic and total-attack traffic are the same CBOR valu= e (or are they?)

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

 

Please note that we have this note is se= ction 10:

 

=3D=3D

   o  Some of these attributes should be pr= epended with "ietf-dots-

      telemetry:"=

=3D=3D

 

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

 
2) &nb=
sp;    why do we not have a “enum megabit-ps” in “typedef =
unit” in the YANG Module?
[M=
ed]  This can be added to the list as ‘units()’ are negoti=
ated. *-bytes are more used for aggregates, but let’s be consistent a=
nd have both bit/bytes in the units.  
 
3) &nb=
sp;    I think that I have worked out that server-originated-telemetry if se=
t allows telemetry included in the mitigation status rather than only retur=
ned using Uri-path: tm – correct?
[M=
ed] I confirm. Note that including pre-mitigation returned using “Uri=
-path:tm” is controlled by PUT/GET (Section 7.3).=

 = 

4) &nb=
sp;    I am confused by “pre-mitigation” which can be transmitte=
d pre any mitigation taking place, or actually during when mitigation is ta=
king place (or so I think) and would simply be better described as “a=
ttack-details” – especially with a statement such as=

 = 

   =
DOTS agents MUST bind pre-mitigation telemetry data with mitigation
   =
requests relying upon the target clause.
 
[M=
ed] That’s an option but the current design allows to have the teleme=
try in // in order to supply more data ** without impacting the placement o=
f a mitigation request ** hence the need to bind both (if any). If telemetr=
y attributes are defined as mandatory (discussed in another thread), this w=
ould mean that the server will reject a mitigation that includes such attri=
butes. With the current design, we have a functionality that can be safely =
enabled independently of the decision that we will make about whether telem=
etry attributes are mandatory to be supported or not.=

 
An=
other point we can check to ease correlation between a mitigation request a=
nd pre-mitigation telemetry is to signal the “mid” in the telem=
etry message. 
 
Regards
 
Jon
--_000_787AE7BB302AE849A7480A190F8B93303143DAF8OPEXCAUBMA2corp_-- From nobody Fri Feb 21 03:18:16 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 91ACC120227 for ; Fri, 21 Feb 2020 03:18:13 -0800 (PST) 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 hV8_RvzT3leT for ; Fri, 21 Feb 2020 03:18:10 -0800 (PST) Received: from mail.jpshallow.com (mail.jpshallow.com [217.40.240.153]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7A885120096 for ; Fri, 21 Feb 2020 03:18:10 -0800 (PST) Received: from mail2.jpshallow.com ([192.168.0.3] helo=N01332) by mail.jpshallow.com with esmtp (Exim 4.92.3) (envelope-from ) id 1j56Jm-0000e8-Un; Fri, 21 Feb 2020 11:18:03 +0000 From: "Jon Shallow" To: , "Konda, Tirumaleswar Reddy" , "kaname nishizuka" , References: <188801d5e830$635d97d0$2a18c770$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93303143DAF8@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> In-Reply-To: <787AE7BB302AE849A7480A190F8B93303143DAF8@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> Date: Fri, 21 Feb 2020 11:17:41 -0000 Message-ID: <191b01d5e8a8$886d1e60$99475b20$@jpshallow.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_191C_01D5E8A8.886F4140" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJKlzn57Lqwhs92aHFaqw+Bow5bdAGC+KGepy/4z/A= Content-Language: en-gb Archived-At: Subject: Re: [Dots] DOTS telemetry questions X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Feb 2020 11:18:14 -0000 This is a multipart message in MIME format. ------=_NextPart_000_191C_01D5E8A8.886F4140 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Med et al, =20 See inline Jon> =20 Regards =20 Jon =20 From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of mohamed.boucadair@orange.com Sent: 21 February 2020 07:00 To: Jon Shallow; Konda, Tirumaleswar Reddy; kaname nishizuka Cc: dots@ietf.org Subject: Re: [Dots] DOTS telemetry questions =20 Hi Jon, =20 (ccing the WG to track the changes). =20 Please see inline. =20 Cheers, Med =20 De : Jon Shallow [mailto:supjps-ietf@jpshallow.com]=20 Envoy=E9 : jeudi 20 f=E9vrier 2020 21:58 =C0 : BOUCADAIR Mohamed TGI/OLN; Konda, Tirumaleswar Reddy; kaname = nishizuka Objet : DOTS telemetry questions =20 Hi Guys, =20 1) For example CBOR mappings =20 Header: PUT (Code=3D0.03) Uri-Path: ".well-known" Uri-Path: "dots" Uri-Path: "mitigate" Uri-Path: "cuid=3Ddz6pHjaADkaFTbjr0JGBpw" Uri-Path: "mid=3D123" If-Match: Content-Format: "application/dots+cbor" =20 { "ietf-dots-signal-channel:mitigation-scope": { "scope": [ { "alias-name": [ "myserver" ], "attack-status": "under-attack", "ietf-dots-telemetry:total-attack-traffic": [ { "ietf-dots-telemetry:unit": "megabytes-ps", "ietf-dots-telemetry:mid-percentile-g": "900" } ] } ] } } =20 Figure 33: An Example of Mitigation Efficacy Update with Telemetry Attributes =20 And yet the mapping table only has (no ietf-dots-telemetry: prefix) =20 | total-attack-traffic | list |32794 | 4 array | Array = | =20 I appreciate that ietf-dots-telemetry:total-attack-traffic and = total-attack traffic are the same CBOR value (or are they?) [Med] The same value is used but I didn=92t check if there are side = effects.=20 Jon> Need to think this through. My implementation maps the CBOR into = JSON and then works on the JSON to do what is necessary and then converts the JSON response back into CBOR. Jon> We have the same naming issues in draft-ietf-dots-signal-filter-control-00 where we do not have the ietf-dots-signal-control: prefix in the JSON examples (Fig 10) =20 Please note that we have this note is section 10: =20 =3D=3D o Some of these attributes should be prepended with "ietf-dots- telemetry:" =3D=3D =20 but when mapping the CBOR back to JSON the variant of JSON parameter is context (Uri-Path: mitigate or tm) dependent. =20 2) why do we not have a =93enum megabit-ps=94 in =93typedef unit=94 = in the YANG Module? [Med] This can be added to the list as =91units()=92 are negotiated. = *-bytes are more used for aggregates, but let=92s be consistent and have both bit/bytes in the units. Jon> Megabytes works with aggregates, megabits works with pipes. =20 =20 3) I think that I have worked out that server-originated-telemetry = if set allows telemetry included in the mitigation status rather than only returned using Uri-path: tm =96 correct? [Med] I confirm. Note that including pre-mitigation returned using =93Uri-path:tm=94 is controlled by PUT/GET (Section 7.3). Jon> Agreed. =20 =20 4) I am confused by =93pre-mitigation=94 which can be transmitted = pre any mitigation taking place, or actually during when mitigation is taking = place (or so I think) and would simply be better described as = =93attack-details=94 =96 especially with a statement such as =20 DOTS agents MUST bind pre-mitigation telemetry data with mitigation requests relying upon the target clause. =20 [Med] That=92s an option but the current design allows to have the = telemetry in // in order to supply more data ** without impacting the placement of = a mitigation request ** hence the need to bind both (if any). If telemetry attributes are defined as mandatory (discussed in another thread), this would mean that the server will reject a mitigation that includes such attributes. With the current design, we have a functionality that can be safely enabled independently of the decision that we will make about = whether telemetry attributes are mandatory to be supported or not. Jon> My primary point here was the use of the term =93pre-mitigation=94 = =96 this telemetry is also needs during a mitigation and the attack keeps on = morphing into something else. =20 Another point we can check to ease correlation between a mitigation = request and pre-mitigation telemetry is to signal the =93mid=94 in the telemetry message. Jon> could be =96 need to think this through =20 Regards =20 Jon ------=_NextPart_000_191C_01D5E8A8.886F4140 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Med et al,

 

See inline = Jon>

 

Regards

 

Jon

 

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

 

Hi Jon,

 

(ccing the WG to track the = changes).

 

Please see inline.

 

Cheers,

Med

 

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

 

Hi = Guys,

 

1)      = For example CBOR mappings

 

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

     Uri-Path: = ".well-known"

     Uri-Path: = "dots"

     Uri-Path: = "mitigate"

     Uri-Path: = "cuid=3Ddz6pHjaADkaFTbjr0JGBpw"

     Uri-Path: = "mid=3D123"

     If-Match:

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

 

     {

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

        = "scope": [

          = {

          = ;  "alias-name": [

          = ;     "myserver"

          = ;   ],

          = ;  "attack-status": = "under-attack",

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

          = ;    {

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

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

          = ;    }

          = ;  ]

          = }

        = ]

      }

     }

 

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

          = ;            =           = Attributes

 

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

 

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

 

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

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

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

Jon> We=A0 have the same naming issues in =
draft-ietf-dots-signal-filter-control-00 where we do not have the =
ietf-dots-signal-control: prefix in the JSON =
examples (Fig 10)

 

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

 

=3D=3D

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

      = telemetry:"

=3D=3D

 

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

 
2)      =
why do we not have a “enum =
megabit-ps” in “typedef unit” in the YANG =
Module?
[Med]  This can be added to the list as =
‘units()’ are negotiated. *-bytes are more used for =
aggregates, but let’s be consistent and have both bit/bytes in the =
units.
Jon> Megabytes works with aggregates, =
megabits works with pipes.
 =
 
 
3)      =
I think that I have worked out that =
server-originated-telemetry if set allows telemetry included in the =
mitigation status rather than only returned using Uri-path: tm – =
correct?
[Med] I confirm. Note that including =
pre-mitigation returned using “Uri-path:tm” is controlled by =
PUT/GET (Section 7.3).
Jon> Agreed.=A0

 

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

 

   DOTS agents MUST bind =
pre-mitigation telemetry data with mitigation
   requests relying upon the =
target clause.
 
[Med] That’s an option but the current =
design allows to have the telemetry in // in order to supply more data =
** without impacting the placement of a mitigation request ** hence the =
need to bind both (if any). If telemetry attributes are defined as =
mandatory (discussed in another thread), this would mean that the server =
will reject a mitigation that includes such attributes. With the current =
design, we have a functionality that can be safely enabled independently =
of the decision that we will make about whether telemetry attributes are =
mandatory to be supported or =
not.
Jon> My primary point here was the use of the =
term “pre-mitigation” – this telemetry is also needs =
during a mitigation and the attack keeps on morphing into something =
else.
 
Another point we can check to ease =
correlation between a mitigation request and pre-mitigation telemetry is =
to signal the “mid” in the telemetry =
message.
Jon> could =
be – need to think this through
 
Regards
 
Jon<=
span style=3D'font-size:10.0pt;font-family:"Courier =
New","serif";color:black'>
------=_NextPart_000_191C_01D5E8A8.886F4140-- From nobody Fri Feb 21 05:32: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 2F43B12004A for ; Fri, 21 Feb 2020 05:32:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.697 X-Spam-Level: X-Spam-Status: No, score=-2.697 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 69NF26Q8Ehcj for ; Fri, 21 Feb 2020 05:32:25 -0800 (PST) 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 043D512001A for ; Fri, 21 Feb 2020 05:32:25 -0800 (PST) Received: from opfedar00.francetelecom.fr (unknown [xx.xx.xx.11]) by opfedar20.francetelecom.fr (ESMTP service) with ESMTP id 48PC7C2PFWz8tJ5; Fri, 21 Feb 2020 14:32:23 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1582291943; bh=VurSbDmHwrunUZZKt/aG/gpyfQ55h5GYJWsGpmVykJI=; h=From:To:Subject:Date:Message-ID:Content-Type:MIME-Version; b=scqrHBesXFaAC1sq8t78JZZO/0MlrEPG501o2nds5BsbwReB+vSi+8vmdv+8FD7DB XMLuAQ8fwMbhaIGfCuC+1p+dB/pv8ehlwLHy025Bl+EBFwMmGZlAUynpIYjmFKDUGB FIlRqDEZx+ZLrDCVbiS1dsoOkigH747d7YuDx8uYDl6D6APLE81x4yHV7DqmDXk+eS bEeeZPLYxX+7QFRE0yx8DTGQM9gCak8oaGYOPihiXDHrlPyc4YH/TvxTesEtwpqtau JvJwMyd3TEDfElOXYejl2VHBuoD0i4SgmjC0XnjoQ0/Xw3JytkhZ3mXL1StUpfmTXa E5fUDlC3vkLVw== Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.82]) by opfedar00.francetelecom.fr (ESMTP service) with ESMTP id 48PC7C18MdzCqkM; Fri, 21 Feb 2020 14:32:23 +0100 (CET) Received: from OPEXCAUBMA2.corporate.adroot.infra.ftgroup ([fe80::e878:bd0:c89e:5b42]) by OPEXCAUBM5E.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0468.000; Fri, 21 Feb 2020 14:32:22 +0100 From: To: Jon Shallow , "Konda, Tirumaleswar Reddy" , kaname nishizuka , "dots@ietf.org" Thread-Topic: [Dots] DOTS telemetry questions Thread-Index: AQJKlzn57Lqwhs92aHFaqw+Bow5bdAGC+KGepy/4z/CAACh8IA== Date: Fri, 21 Feb 2020 13:32:22 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93303143DE2E@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> References: <188801d5e830$635d97d0$2a18c770$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93303143DAF8@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <191b01d5e8a8$886d1e60$99475b20$@jpshallow.com> In-Reply-To: <191b01d5e8a8$886d1e60$99475b20$@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: multipart/alternative; boundary="_000_787AE7BB302AE849A7480A190F8B93303143DE2EOPEXCAUBMA2corp_" MIME-Version: 1.0 Archived-At: Subject: Re: [Dots] DOTS telemetry questions X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Feb 2020 13:32:29 -0000 --_000_787AE7BB302AE849A7480A190F8B93303143DE2EOPEXCAUBMA2corp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re-, Please see inline. Cheers, Med De : Jon Shallow [mailto:supjps-ietf@jpshallow.com] Envoy=E9 : vendredi 21 f=E9vrier 2020 12:18 =C0 : BOUCADAIR Mohamed TGI/OLN; Konda, Tirumaleswar Reddy; kaname nishizuk= a; dots@ietf.org Objet : RE: [Dots] DOTS telemetry questions Hi Med et al, See inline Jon> Regards Jon From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of mohamed.boucadair@o= range.com Sent: 21 February 2020 07:00 To: Jon Shallow; Konda, Tirumaleswar Reddy; kaname nishizuka Cc: dots@ietf.org Subject: Re: [Dots] DOTS telemetry questions Hi Jon, (ccing the WG to track the changes). Please see inline. Cheers, Med De : Jon Shallow [mailto:supjps-ietf@jpshallow.com] Envoy=E9 : jeudi 20 f=E9vrier 2020 21:58 =C0 : BOUCADAIR Mohamed TGI/OLN; Konda, Tirumaleswar Reddy; kaname nishizuk= a Objet : DOTS telemetry questions Hi Guys, 1) For example CBOR mappings Header: PUT (Code=3D0.03) Uri-Path: ".well-known" Uri-Path: "dots" Uri-Path: "mitigate" Uri-Path: "cuid=3Ddz6pHjaADkaFTbjr0JGBpw" Uri-Path: "mid=3D123" If-Match: Content-Format: "application/dots+cbor" { "ietf-dots-signal-channel:mitigation-scope": { "scope": [ { "alias-name": [ "myserver" ], "attack-status": "under-attack", "ietf-dots-telemetry:total-attack-traffic": [ { "ietf-dots-telemetry:unit": "megabytes-ps", "ietf-dots-telemetry:mid-percentile-g": "900" } ] } ] } } Figure 33: An Example of Mitigation Efficacy Update with Telemetry Attributes And yet the mapping table only has (no ietf-dots-telemetry: prefix) | total-attack-traffic | list |32794 | 4 array | Array | I appreciate that ietf-dots-telemetry:total-attack-traffic and total-attack= traffic are the same CBOR value (or are they?) [Med] The same value is used but I didn't check if there are side effects. Jon> Need to think this through. My implementation maps the CBOR into JSON= and then works on the JSON to do what is necessary and then converts the J= SON response back into CBOR. [Med] An issue with namespaces will be the encountered if the conversion is= the same for the attribute when it is carried in a "pure" telemetry messag= e or in an existing signal channel message. Jon> We have the same naming issues in draft-ietf-dots-signal-filter-contr= ol-00 where we do not have the ietf-dots-signal-control: prefix in the JSON= examples (Fig 10) [Med] Fig 10 is a "normal" mitigation request. Why should it need to includ= e "ietf-dots-signal-control:" prefix? Please note that we have this note is section 10: =3D=3D o Some of these attributes should be prepended with "ietf-dots- telemetry:" =3D=3D but when mapping the CBOR back to JSON the variant of JSON parameter is con= text (Uri-Path: mitigate or tm) dependent. 2) why do we not have a "enum megabit-ps" in "typedef unit" in the YAN= G Module? [Med] This can be added to the list as 'units()' are negotiated. *-bytes a= re more used for aggregates, but let's be consistent and have both bit/byte= s in the units. Jon> Megabytes works with aggregates, megabits works with pipes. [Med] I added the unit to the module. BTW, in order to easily define new un= its, I updated the module so that units are defined as identities, not enum= erations. The updated mapping table is: https://github.com/boucadair/draft-= dots-telemetry/blob/master/mapping-table.txt (or https://github.com/boucada= ir/draft-dots-telemetry/blob/master/draft-ietf-dots-telemetry-03.txt) 3) I think that I have worked out that server-originated-telemetry if = set allows telemetry included in the mitigation status rather than only ret= urned using Uri-path: tm - correct? [Med] I confirm. Note that including pre-mitigation returned using "Uri-pat= h:tm" is controlled by PUT/GET (Section 7.3). Jon> Agreed. 4) I am confused by "pre-mitigation" which can be transmitted pre any = mitigation taking place, or actually during when mitigation is taking place= (or so I think) and would simply be better described as "attack-details" -= especially with a statement such as DOTS agents MUST bind pre-mitigation telemetry data with mitigation requests relying upon the target clause. [Med] That's an option but the current design allows to have the telemetry = in // in order to supply more data ** without impacting the placement of a = mitigation request ** hence the need to bind both (if any). If telemetry at= tributes are defined as mandatory (discussed in another thread), this would= mean that the server will reject a mitigation that includes such attribute= s. With the current design, we have a functionality that can be safely enab= led independently of the decision that we will make about whether telemetry= attributes are mandatory to be supported or not. Jon> My primary point here was the use of the term "pre-mitigation" - this = telemetry is also needs during a mitigation and the attack keeps on morphin= g into something else. [Med] I see your point. We will see if we can find a better term. Another point we can check to ease correlation between a mitigation request= and pre-mitigation telemetry is to signal the "mid" in the telemetry messa= ge. Jon> could be - need to think this through [Med] Let's think about this one further. Regards Jon --_000_787AE7BB302AE849A7480A190F8B93303143DE2EOPEXCAUBMA2corp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Re-,

 

Please see inline.

 

Cheers,

Med

 

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

 

Hi Med = et al,

&n= bsp;

See inl= ine Jon>

&n= bsp;

Regards=

&n= bsp;

Jon

&n= bsp;

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

 

Hi Jon,

 

(ccing the WG to track the changes).

 

Please see inline.

 

Cheers,

Med

 

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

 

Hi Guys,

 

1= )   &= nbsp;  For example CBOR mappin= gs

 

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

     Uri-Path: ".we= ll-known"

     Uri-Path: "dot= s"

     Uri-Path: "mit= igate"

     Uri-Path: "cui= d=3Ddz6pHjaADkaFTbjr0JGBpw"

     Uri-Path: "mid= =3D123"

     If-Match:

     Content-Format: &qu= ot;application/dots+cbor"

 

     {=

      "ietf-do= ts-signal-channel:mitigation-scope": {

        &= quot;scope": [

       &n= bsp;  {

       &n= bsp;    "alias-name": [

       &n= bsp;       "myserver"

       &n= bsp;     ],

       &n= bsp;    "attack-status": "under-attack",=

       &n= bsp;    "ietf-dots-telemetry:total-attack-traffic= ": [

       &n= bsp;      {

       &n= bsp;        "ietf-dots-telemetry:un= it": "megabytes-ps",

       &n= bsp;        "ietf-dots-telemetry:mi= d-percentile-g": "900"

       &n= bsp;      }

       &n= bsp;    ]

       &n= bsp;  }

        ]=

      }<= /span>

     }=

 

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

       &n= bsp;            = ;            Attribu= tes

 

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

 

  &= nbsp; | total-attack-traffic | list      &nbs= p; |32794 | 4 array       | Array  |=

 

I appreciate that ietf-dots-tel= emetry:total-attack-traffic and total-attack traffic are the same CBOR valu= e (or are they?)

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

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

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

 

Jon> We  have the same naming issues in draft-ietf-dots-s=
ignal-filter-control-00 where we do not have the [Med] Fig 10 is a ̶=
0;normal” mitigation request. Why should it need to include “ie=
tf-dots-signal-control:” prefix?

 

Please note that we have this note is se= ction 10:

 

=3D=3D

   o  Some of these attributes should be pr= epended with "ietf-dots-

      telemetry:"=

=3D=3D

 

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

 
2)  &nbs=
p;   why do w=
e not have a “enum megabit-ps” in “typedef unit” in=
 the YANG Module?
[Med]  This can be added to the list as ‘units(=
)’ are negotiated. *-bytes are more used for aggregates, but let̵=
7;s be consistent and have both bit/bytes in the units.
Jon> Megabytes works w=
ith aggregates, megabits works with pipes.
[Med] I added the unit to the module. BTW, in order to eas=
ily define new units, I updated the module so that units are defined as ide=
ntities, not enumerations. The updated mapping table is: h=
ttps://github.com/boucadair/draft-dots-telemetry/blob/master/mapping-table.=
txt (or https://github.com/boucadair/dr=
aft-dots-telemetry/blob/master/draft-ietf-dots-telemetry-03.txt) 
  
 
3)  &nbs=
p;   I think =
that I have worked out that server-originated-telemetry if set allows telem=
etry included in the mitigation status rather than only returned using Uri-=
path: tm – correct?
[Med] I confirm. Note that including pre-mitigation return=
ed using “Uri-path:tm” is controlled by PUT/GET (Section 7.3).<=
o:p>
Jon> Agreed. 

 = 

4)  &nbs=
p;   I am con=
fused by “pre-mitigation” which can be transmitted pre any miti=
gation taking place, or actually during when mitigation is taking place (or=
 so I think) and would simply be better described as “attack-details&=
#8221; – especially with a statement such as

 = 

   DOTS ag=
ents MUST bind pre-mitigation telemetry data with mitigation
   request=
s relying upon the target clause.
 
[Med] That’s an option but the current design allows=
 to have the telemetry in // in order to supply more data ** without impact=
ing the placement of a mitigation request ** hence the need to bind both (i=
f any). If telemetry attributes are defined as mandatory (discussed in anot=
her thread), this would mean that the server will reject a mitigation that =
includes such attributes. With the current design, we have a functionality =
that can be safely enabled independently of the decision that we will make =
about whether telemetry attributes are mandatory to be supported or not.
Jon> My primary point =
here was the use of the term “pre-mitigation” – this tele=
metry is also needs during a mitigation and the attack keeps on morphing in=
to something else.
[Med] I see your point. We will see if we can find a bette=
r term. 
 
Another point we can check to ease correlation between a m=
itigation request and pre-mitigation telemetry is to signal the “mid&=
#8221; in the telemetry message.
Jon> could be – need to think this through
[Med] Let’s think about this one further.=

 
Regards
 
Jon=
--_000_787AE7BB302AE849A7480A190F8B93303143DE2EOPEXCAUBMA2corp_-- From nobody Fri Feb 21 07:46: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 22DDA120876 for ; Fri, 21 Feb 2020 07:46:03 -0800 (PST) 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 8BW8oEr7XlcW for ; Fri, 21 Feb 2020 07:46:00 -0800 (PST) Received: from mail.jpshallow.com (mail.jpshallow.com [217.40.240.153]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DF20C120852 for ; Fri, 21 Feb 2020 07:45:59 -0800 (PST) Received: from mail2.jpshallow.com ([192.168.0.3] helo=N01332) by mail.jpshallow.com with esmtp (Exim 4.92.3) (envelope-from ) id 1j5AUz-0000o3-Dc; Fri, 21 Feb 2020 15:45:53 +0000 From: "Jon Shallow" To: , "Konda, Tirumaleswar Reddy" , "kaname nishizuka" , References: <188801d5e830$635d97d0$2a18c770$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93303143DAF8@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <191b01d5e8a8$886d1e60$99475b20$@jpshallow.com> <787AE7BB302AE849A7480A190F8B93303143DE2E@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> In-Reply-To: <787AE7BB302AE849A7480A190F8B93303143DE2E@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> Date: Fri, 21 Feb 2020 15:45:32 -0000 Message-ID: <197301d5e8cd$f31384a0$d93a8de0$@jpshallow.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_1974_01D5E8CD.F3188DB0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJKlzn57Lqwhs92aHFaqw+Bow5bdAGC+KGeAyZ69zoBnzSmg6cKH2gA Content-Language: en-gb Archived-At: Subject: Re: [Dots] DOTS telemetry questions X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Feb 2020 15:46:03 -0000 This is a multipart message in MIME format. ------=_NextPart_000_1974_01D5E8CD.F3188DB0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, =20 See inline Jon1> =20 Regards =20 Jon =20 From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of mohamed.boucadair@orange.com Sent: 21 February 2020 13:32 To: Jon Shallow; Konda, Tirumaleswar Reddy; kaname nishizuka; = dots@ietf.org Subject: Re: [Dots] DOTS telemetry questions =20 Re-, =20 Please see inline.=20 =20 Cheers, Med =20 De : Jon Shallow [mailto:supjps-ietf@jpshallow.com]=20 Envoy=E9 : vendredi 21 f=E9vrier 2020 12:18 =C0 : BOUCADAIR Mohamed TGI/OLN; Konda, Tirumaleswar Reddy; kaname = nishizuka; dots@ietf.org Objet : RE: [Dots] DOTS telemetry questions =20 Hi Med et al, =20 See inline Jon> =20 Regards =20 Jon =20 From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of mohamed.boucadair@orange.com Sent: 21 February 2020 07:00 To: Jon Shallow; Konda, Tirumaleswar Reddy; kaname nishizuka Cc: dots@ietf.org Subject: Re: [Dots] DOTS telemetry questions =20 Hi Jon, =20 (ccing the WG to track the changes). =20 Please see inline. =20 Cheers, Med =20 De : Jon Shallow [mailto:supjps-ietf@jpshallow.com]=20 Envoy=E9 : jeudi 20 f=E9vrier 2020 21:58 =C0 : BOUCADAIR Mohamed TGI/OLN; Konda, Tirumaleswar Reddy; kaname = nishizuka Objet : DOTS telemetry questions =20 Hi Guys, =20 1) For example CBOR mappings =20 Header: PUT (Code=3D0.03) Uri-Path: ".well-known" Uri-Path: "dots" Uri-Path: "mitigate" Uri-Path: "cuid=3Ddz6pHjaADkaFTbjr0JGBpw" Uri-Path: "mid=3D123" If-Match: Content-Format: "application/dots+cbor" =20 { "ietf-dots-signal-channel:mitigation-scope": { "scope": [ { "alias-name": [ "myserver" ], "attack-status": "under-attack", "ietf-dots-telemetry:total-attack-traffic": [ { "ietf-dots-telemetry:unit": "megabytes-ps", "ietf-dots-telemetry:mid-percentile-g": "900" } ] } ] } } =20 Figure 33: An Example of Mitigation Efficacy Update with Telemetry Attributes =20 And yet the mapping table only has (no ietf-dots-telemetry: prefix) =20 | total-attack-traffic | list |32794 | 4 array | Array = | =20 I appreciate that ietf-dots-telemetry:total-attack-traffic and = total-attack traffic are the same CBOR value (or are they?) [Med] The same value is used but I didn=92t check if there are side = effects.=20 Jon> Need to think this through. My implementation maps the CBOR into = JSON and then works on the JSON to do what is necessary and then converts the JSON response back into CBOR. [Med] An issue with namespaces will be the encountered if the conversion = is the same for the attribute when it is carried in a =93pure=94 telemetry = message or in an existing signal channel message. Jon1> Correct =96 I don=92t like the concept of having 2 mapping tables = for mapping the CBOR value back into JSON. =20 Jon> We have the same naming issues in draft-ietf-dots-signal-filter-control-00 where we do not have the ietf-dots-signal-control: prefix in the JSON examples (Fig 10) [Med] Fig 10 is a =93normal=94 mitigation request. Why should it need to = include =93ietf-dots-signal-control:=94 prefix? =20 Jon1> My bad =96 I was looking at = draft-ietf-dots-signal-filter-control-00, not draft-ietf-dots-signal-filter-control-02. However, https://tools.ietf.org/html/draft-ietf-dots-signal-filter-control-02#sect= ion -5.1 only defines =93activation-type=94 without the prefix, and acl-list = and acl-name have the incorrect prefix: added to, for example, Figure 1. =20 Please note that we have this note is section 10: =20 =3D=3D o Some of these attributes should be prepended with "ietf-dots- telemetry:" =3D=3D =20 but when mapping the CBOR back to JSON the variant of JSON parameter is context (Uri-Path: mitigate or tm) dependent. =20 2) why do we not have a =93enum megabit-ps=94 in =93typedef unit=94 = in the YANG Module? [Med] This can be added to the list as =91units()=92 are negotiated. = *-bytes are more used for aggregates, but let=92s be consistent and have both bit/bytes in the units. Jon> Megabytes works with aggregates, megabits works with pipes. [Med] I added the unit to the module. BTW, in order to easily define new units, I updated the module so that units are defined as identities, not enumerations. The updated mapping table is: https://github.com/boucadair/draft-dots-telemetry/blob/master/mapping-tab= le. txt (or https://github.com/boucadair/draft-dots-telemetry/blob/master/draft-ietf-= dot s-telemetry-03.txt)=20 Jon1> Typo in megabite-ps Jon1> I am not sure about the usage of identityref. https://tools.ietf.org/html/rfc7951#section-6.8 states that the value is represented as a string (currently the CBOR mapping entry says it is an integer), and furthermore it is likely that the namespace-qualified form = is required. This is a huge increase in the number of bytes needed whenever unit (and measurement-interval Etc.) are used. I think that this is a = bad change. =20 =20 3) I think that I have worked out that server-originated-telemetry = if set allows telemetry included in the mitigation status rather than only returned using Uri-path: tm =96 correct? [Med] I confirm. Note that including pre-mitigation returned using =93Uri-path:tm=94 is controlled by PUT/GET (Section 7.3). Jon> Agreed. =20 =20 4) I am confused by =93pre-mitigation=94 which can be transmitted = pre any mitigation taking place, or actually during when mitigation is taking = place (or so I think) and would simply be better described as = =93attack-details=94 =96 especially with a statement such as =20 DOTS agents MUST bind pre-mitigation telemetry data with mitigation requests relying upon the target clause. =20 [Med] That=92s an option but the current design allows to have the = telemetry in // in order to supply more data ** without impacting the placement of = a mitigation request ** hence the need to bind both (if any). If telemetry attributes are defined as mandatory (discussed in another thread), this would mean that the server will reject a mitigation that includes such attributes. With the current design, we have a functionality that can be safely enabled independently of the decision that we will make about = whether telemetry attributes are mandatory to be supported or not. Jon> My primary point here was the use of the term =93pre-mitigation=94 = =96 this telemetry is also needs during a mitigation and the attack keeps on = morphing into something else. [Med] I see your point. We will see if we can find a better term. Jon1> Agreed =96 it is the =93pre=94 that certainly does not work for = me. Something like =93attack information=94 ? =20 =20 Another point we can check to ease correlation between a mitigation = request and pre-mitigation telemetry is to signal the =93mid=94 in the telemetry message. Jon> could be =96 need to think this through [Med] Let=92s think about this one further. Jon1> Sure =96 this may come out in the wash as we try to implement this stuff. =20 Regards =20 Jon ------=_NextPart_000_1974_01D5E8CD.F3188DB0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi,

 

See inline = Jon1>

 

Regards

 

Jon

 

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

 

Re-,

 

Please see inline.

 

Cheers,

Med

 

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

 

Hi Med et al,

 

See inline = Jon>

 

Regards

 

Jon

 

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

 

Hi Jon,

 

(ccing the WG to track the = changes).

 

Please see inline.

 

Cheers,

Med

 

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

 

Hi = Guys,

 

1)      = For example CBOR mappings

 

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

     Uri-Path: = ".well-known"

     Uri-Path: = "dots"

     Uri-Path: = "mitigate"

     Uri-Path: = "cuid=3Ddz6pHjaADkaFTbjr0JGBpw"

     Uri-Path: = "mid=3D123"

     If-Match:

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

 

     {

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

        = "scope": [

          = {

          = ;  "alias-name": [

          = ;     "myserver"

          = ;   ],

          = ;  "attack-status": = "under-attack",

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

          = ;    {

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

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

          = ;    }

          = ;  ]

          = }

        = ]

      }

     }

 

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

          = ;            =           = Attributes

 

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

 

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

 

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

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

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

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

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

 

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

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

 

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

 

=3D=3D

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

      = telemetry:"

=3D=3D

 

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

 
2)      =
why do we not have a “enum =
megabit-ps” in “typedef unit” in the YANG =
Module?
[Med]  This can be added to the list as =
‘units()’ are negotiated. *-bytes are more used for =
aggregates, but let’s be consistent and have both bit/bytes in the =
units.
Jon> Megabytes works with aggregates, =
megabits works with pipes.
[Med] I added =
the unit to the module. BTW, in order to easily define new units, I =
updated the module so that units are defined as identities, not =
enumerations. The updated mapping table is: https://github.com/boucadair/draft-dots-telemetry/blob/ma=
ster/mapping-table.txt (or https://github.com/boucadair/draft-dots-te=
lemetry/blob/master/draft-ietf-dots-telemetry-03.txt) =

Jon1> Typo =
in megabite-ps
Jon1> I am =
not sure about the usage of identityref.=A0 https://tools.ie=
tf.org/html/rfc7951#section-6.8 states that the value is represented =
as a string (currently the CBOR mapping entry says it is an integer), =
and furthermore it is likely that the namespace-qualified form is =
required. This is a huge increase in the number of bytes needed whenever =
unit (and measurement-interval Etc.) are used.=A0 I think that this is a bad =
change.  
 
3)      =
I think that I have worked out that =
server-originated-telemetry if set allows telemetry included in the =
mitigation status rather than only returned using Uri-path: tm – =
correct?
[Med] I confirm. Note that including =
pre-mitigation returned using “Uri-path:tm” is controlled by =
PUT/GET (Section 7.3).
Jon> Agreed. 

 

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

 

   DOTS agents MUST bind =
pre-mitigation telemetry data with mitigation
   requests relying upon the =
target clause.
 
[Med] That’s an option but the current =
design allows to have the telemetry in // in order to supply more data =
** without impacting the placement of a mitigation request ** hence the =
need to bind both (if any). If telemetry attributes are defined as =
mandatory (discussed in another thread), this would mean that the server =
will reject a mitigation that includes such attributes. With the current =
design, we have a functionality that can be safely enabled independently =
of the decision that we will make about whether telemetry attributes are =
mandatory to be supported or =
not.
Jon> My primary point here was the use of the =
term “pre-mitigation” – this telemetry is also needs =
during a mitigation and the attack keeps on morphing into something =
else.
[Med] I see =
your point. We will see if we can find a better =
term.
Jon1> Agreed – it is the =
“pre” that certainly does not work for me.=A0 Something like =
“attack information” =
?
 
 
Another point we can check to ease =
correlation between a mitigation request and pre-mitigation telemetry is =
to signal the “mid” in the telemetry =
message.
Jon> could =
be – need to think this =
through
[Med] =
Let’s think about this one further.
Jon1> Sure – this may come out in the =
wash as we try to implement this =
stuff.
 
Regards
 
Jon
------=_NextPart_000_1974_01D5E8CD.F3188DB0-- From nobody Sat Feb 22 12:44:49 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 412093A03FB for ; Sat, 22 Feb 2020 12:44:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 6BrrukvI6vca for ; Sat, 22 Feb 2020 12:44:47 -0800 (PST) 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 319133A03FC for ; Sat, 22 Feb 2020 12:44:46 -0800 (PST) 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 01MKifUG013433 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sat, 22 Feb 2020 15:44:45 -0500 Date: Sat, 22 Feb 2020 12:44:41 -0800 From: Benjamin Kaduk To: mohamed.boucadair@orange.com Cc: "dots@ietf.org" Message-ID: <20200222204441.GU53538@kduck.mit.edu> References: <158108169855.11593.11339621036867180747@ietfa.amsl.com> <787AE7BB302AE849A7480A190F8B933031432620@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <787AE7BB302AE849A7480A190F8B933031432620@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> User-Agent: Mutt/1.12.1 (2019-06-15) Archived-At: Subject: Re: [Dots] I-D Action: draft-ietf-dots-server-discovery-10.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: Sat, 22 Feb 2020 20:44:48 -0000 On Fri, Feb 07, 2020 at 01:29:55PM +0000, mohamed.boucadair@orange.com wrote: > Hi all, > > We made some changes to take into account an implementation feedback we received. The mechanisms in the draft are implemented (thanks Jon!). > > The changes are minor but they enhance the document. This is why we prefer to submit this new version even if the I-D is waiting for Ben's review. Thanks; I agree that getting the updates in from the implementation feedback is the right thing to do. (There's a few documents ahead of this in my queue, unfortunately, and I was on vacation earlier this month.) -Ben From nobody Sun Feb 23 23:41: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 5477E3A07A2 for ; Sun, 23 Feb 2020 23:41:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=orange.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c6FBNO47Y0nL for ; Sun, 23 Feb 2020 23:41:27 -0800 (PST) Received: from relais-inet.orange.com (relais-inet.orange.com [80.12.66.41]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 96B993A07A0 for ; Sun, 23 Feb 2020 23:41:27 -0800 (PST) Received: from opfedar06.francetelecom.fr (unknown [xx.xx.xx.8]) by opfedar23.francetelecom.fr (ESMTP service) with ESMTP id 48QvBs583fzBrYY; Mon, 24 Feb 2020 08:41:25 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1582530085; bh=4dTT7PCWnzCwPEEXlzJlSZ7+H/kGWmX8VcQjXS4Mw+0=; h=From:To:Subject:Date:Message-ID:Content-Type:MIME-Version; b=lOJGbl9KjbnnAQ7hJ3P2vEflRzqgo6xeMkTLytB6OToM17SNcfYaFHl1BxeU95CEe S/mx3IZNeEaJ/u04wESWk2hZuwulpivvhg1VcJiVYuF5R0MRf6WXw9Ft+X/9E5y9ld E8CQ8D6vdu5KHm/EVELImMht+BTxHcjepAFwKisLBwZCeWx01AeTRcaZVVc04eW3Ws 9grNqaWHtmCEECpC0/EB85XuYUQQsLm/QVb1ZgqrbCc7PzaT7JLQ5+PkB514oj9p/l jguc4eekm521wAxsLXBhocQK3tsg9cqwdd0FsRsMovvNT8hAKqBBxWeKQj+n7K7l94 L7lSeWPuMGO/Q== Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.64]) by opfedar06.francetelecom.fr (ESMTP service) with ESMTP id 48QvBs3zzCz3wb8; Mon, 24 Feb 2020 08:41:25 +0100 (CET) Received: from OPEXCAUBMA2.corporate.adroot.infra.ftgroup ([fe80::e878:bd0:c89e:5b42]) by OPEXCAUBMA3.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0468.000; Mon, 24 Feb 2020 08:41:25 +0100 From: To: Jon Shallow , "Konda, Tirumaleswar Reddy" , kaname nishizuka , "dots@ietf.org" Thread-Topic: One or two key values (RE: [Dots] DOTS telemetry questions) Thread-Index: AdXq5c3HBzE8FwXRQOGd4+aeKXb8Qg== Date: Mon, 24 Feb 2020 07:41:23 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93303143E7C0@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.247] Content-Type: multipart/alternative; boundary="_000_787AE7BB302AE849A7480A190F8B93303143E7C0OPEXCAUBMA2corp_" MIME-Version: 1.0 Archived-At: Subject: [Dots] One or two key values (RE: DOTS telemetry questions) X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Feb 2020 07:41:29 -0000 --_000_787AE7BB302AE849A7480A190F8B93303143E7C0OPEXCAUBMA2corp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Jon, (separating the issues to ease tracking them) [Med] An issue with namespaces will be the encountered if the conversion is= the same for the attribute when it is carried in a "pure" telemetry messag= e or in an existing signal channel message. Jon1> Correct - I don't like the concept of having 2 mapping tables for map= ping the CBOR value back into JSON. An updated table is available at: https://github.com/boucadair/draft-dots-t= elemetry/blob/master/mapping-table.txt Cheers, Med De : Jon Shallow [mailto:supjps-ietf@jpshallow.com] Envoy=E9 : vendredi 21 f=E9vrier 2020 16:46 =C0 : BOUCADAIR Mohamed TGI/OLN; Konda, Tirumaleswar Reddy; kaname nishizuk= a; dots@ietf.org Objet : RE: [Dots] DOTS telemetry questions Hi, See inline Jon1> Regards Jon De : Jon Shallow [mailto:supjps-ietf@jpshallow.com] Envoy=E9 : jeudi 20 f=E9vrier 2020 21:58 =C0 : BOUCADAIR Mohamed TGI/OLN; Konda, Tirumaleswar Reddy; kaname nishizuk= a Objet : DOTS telemetry questions Hi Guys, 1) For example CBOR mappings Header: PUT (Code=3D0.03) Uri-Path: ".well-known" Uri-Path: "dots" Uri-Path: "mitigate" Uri-Path: "cuid=3Ddz6pHjaADkaFTbjr0JGBpw" Uri-Path: "mid=3D123" If-Match: Content-Format: "application/dots+cbor" { "ietf-dots-signal-channel:mitigation-scope": { "scope": [ { "alias-name": [ "myserver" ], "attack-status": "under-attack", "ietf-dots-telemetry:total-attack-traffic": [ { "ietf-dots-telemetry:unit": "megabytes-ps", "ietf-dots-telemetry:mid-percentile-g": "900" } ] } ] } } Figure 33: An Example of Mitigation Efficacy Update with Telemetry Attributes And yet the mapping table only has (no ietf-dots-telemetry: prefix) | total-attack-traffic | list |32794 | 4 array | Array | I appreciate that ietf-dots-telemetry:total-attack-traffic and total-attack= traffic are the same CBOR value (or are they?) [Med] The same value is used but I didn't check if there are side effects. Jon> Need to think this through. My implementation maps the CBOR into JSON= and then works on the JSON to do what is necessary and then converts the J= SON response back into CBOR. [Med] An issue with namespaces will be the encountered if the conversion is= the same for the attribute when it is carried in a "pure" telemetry messag= e or in an existing signal channel message. Jon1> Correct - I don't like the concept of having 2 mapping tables for map= ping the CBOR value back into JSON. --_000_787AE7BB302AE849A7480A190F8B93303143E7C0OPEXCAUBMA2corp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Jon,

 

(separating the issues to ease tracking them)

 

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

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

 

An updated table is available at: https://github.com/boucadair/draft-dots-telemetry/blob/maste= r/mapping-table.txt

 

Cheers,

Med

 

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

 

Hi,

&n= bsp;

See inl= ine Jon1>

&n= bsp;

Regards=

&n= bsp;

Jon

&n= bsp;

 

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

 

Hi Guys,

 

1= )   &= nbsp;  For example CBOR mappin= gs

 

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

     Uri-Path: ".we= ll-known"

     Uri-Path: "dot= s"

     Uri-Path: "mit= igate"

     Uri-Path: "cui= d=3Ddz6pHjaADkaFTbjr0JGBpw"

     Uri-Path: "mid= =3D123"

     If-Match:

     Content-Format: &qu= ot;application/dots+cbor"

 

     {=

      "ietf-do= ts-signal-channel:mitigation-scope": {

        &= quot;scope": [

       &n= bsp;  {

       &n= bsp;    "alias-name": [

       &n= bsp;       "myserver"

       &n= bsp;     ],

       &n= bsp;    "attack-status": "under-attack",=

       &n= bsp;    "ietf-dots-telemetry:total-attack-traffic= ": [

       &n= bsp;      {

       &n= bsp;        "ietf-dots-telemetry:un= it": "megabytes-ps",

       &n= bsp;        "ietf-dots-telemetry:mi= d-percentile-g": "900"

       &n= bsp;      }

       &n= bsp;    ]

       &n= bsp;  }

        ]=

      }<= /span>

     }=

 

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

       &n= bsp;            = ;            Attribu= tes

 

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

 

  &= nbsp; | total-attack-traffic | list      &nbs= p; |32794 | 4 array       | Array  |=

 

I appreciate that ietf-dots-tel= emetry:total-attack-traffic and total-attack traffic are the same CBOR valu= e (or are they?)

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

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

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

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

 

--_000_787AE7BB302AE849A7480A190F8B93303143E7C0OPEXCAUBMA2corp_-- From nobody Sun Feb 23 23:50:00 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 463C03A07CE for ; Sun, 23 Feb 2020 23:49:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=orange.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 22wpncuO_cMt for ; Sun, 23 Feb 2020 23:49:56 -0800 (PST) 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 675103A07CA for ; Sun, 23 Feb 2020 23:49:56 -0800 (PST) Received: from opfednr03.francetelecom.fr (unknown [xx.xx.xx.67]) by opfednr20.francetelecom.fr (ESMTP service) with ESMTP id 48QvNf3DLgz1y2h; Mon, 24 Feb 2020 08:49:54 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1582530594; bh=RT1sOseabOe00/vv7ru8oj9tpU+lTGU15mqFDxxh/BE=; h=From:To:Subject:Date:Message-ID:Content-Type:MIME-Version; b=o7EVAa/Pv+pS3/PaFcubGLXmU1miFAXlL9ASRkYFqqwR+YWlPMxmvtG831t7vU9ww H3pvS0GJvsQp0CSEq1nQptNTWHp8t6kfl/VQtBOrT7QcysiTuW4ps/vC7xT9wnEHfo AhREpQ1g/cofcLJap7vTSxjcIL641CvJjkoeWgiR7PgZzuTkDJg+SDdSQRFYXDa/7Z ZUO6rtOSqFCDDy1G2nP394LapS0CeGZC4r/BvnTTdPp+KbYdmALoXMq349JUK5/HwF vye7L+GG8VYvTadS1T8mXlT39oYGwek8aF464t6C7pqGylAu655Dy7SwarMduRUnHI 8oOXJE/lydCmA== Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.101]) by opfednr03.francetelecom.fr (ESMTP service) with ESMTP id 48QvNf2QxnzDq80; Mon, 24 Feb 2020 08:49:54 +0100 (CET) Received: from OPEXCAUBMA2.corporate.adroot.infra.ftgroup ([fe80::e878:bd0:c89e:5b42]) by OPEXCAUBM6F.corporate.adroot.infra.ftgroup ([fe80::c489:b768:686a:545b%23]) with mapi id 14.03.0468.000; Mon, 24 Feb 2020 08:49:54 +0100 From: To: Jon Shallow , "Konda, Tirumaleswar Reddy" , kaname nishizuka , "dots@ietf.org" Thread-Topic: "enumerations vs identities" RE: [Dots] DOTS telemetry questions Thread-Index: AdXq5v6omXtOrL+RTEyldBiItOrMEA== Date: Mon, 24 Feb 2020 07:49:53 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93303143E7DA@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.247] Content-Type: multipart/alternative; boundary="_000_787AE7BB302AE849A7480A190F8B93303143E7DAOPEXCAUBMA2corp_" MIME-Version: 1.0 Archived-At: Subject: [Dots] "enumerations vs identities" RE: DOTS telemetry questions X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Feb 2020 07:49:58 -0000 --_000_787AE7BB302AE849A7480A190F8B93303143E7DAOPEXCAUBMA2corp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re-, Fair. Identities are straightforward to extend the module in the future but it in= creases the size as we need to add the namespace prefix. I added a note to = discuss this tradeoff in Section 4.7: The DOTS telemetry module (Section 9) uses "enumerations" rather than "identities" to define units, samples, and intervals because otherwise the namespace identifier "ietf-dots-telemetry" must be included when a telemetry attribute is included (e.g., in a mitigation efficacy update). The use of "identities" is thus suboptimal from a message compactness standpoint. The updated draft is available at: https://github.com/boucadair/draft-dots-= telemetry/blob/master/draft-ietf-dots-telemetry-03.txt Cheers, Med De : Jon Shallow [mailto:supjps-ietf@jpshallow.com] Envoy=E9 : vendredi 21 f=E9vrier 2020 16:46 =C0 : BOUCADAIR Mohamed TGI/OLN; Konda, Tirumaleswar Reddy; kaname nishizuk= a; dots@ietf.org Objet : RE: [Dots] DOTS telemetry questions Hi, See inline Jon1> Regards Jon 1) why do we not have a "enum megabit-ps" in "typedef unit" in the YAN= G Module? [Med] This can be added to the list as 'units()' are negotiated. *-bytes a= re more used for aggregates, but let's be consistent and have both bit/byte= s in the units. Jon> Megabytes works with aggregates, megabits works with pipes. [Med] I added the unit to the module. BTW, in order to easily define new un= its, I updated the module so that units are defined as identities, not enum= erations. The updated mapping table is: https://github.com/boucadair/draft-= dots-telemetry/blob/master/mapping-table.txt (or https://github.com/boucada= ir/draft-dots-telemetry/blob/master/draft-ietf-dots-telemetry-03.txt) Jon1> Typo in megabite-ps Jon1> I am not sure about the usage of identityref. https://tools.ietf.org= /html/rfc7951#section-6.8 states that the value is represented as a string = (currently the CBOR mapping entry says it is an integer), and furthermore i= t is likely that the namespace-qualified form is required. This is a huge i= ncrease in the number of bytes needed whenever unit (and measurement-interv= al Etc.) are used. I think that this is a bad change. --_000_787AE7BB302AE849A7480A190F8B93303143E7DAOPEXCAUBMA2corp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Re-,

 

Fair.  

 

Identities are straightforward to extend the module in the fu= ture but it increases the size as we need to add the namespace prefix. I ad= ded a note to discuss this tradeoff in Section 4.7:

 

   The DOTS telemetry module (Section 9) uses &q= uot;enumerations" rather than

   "identities" to define units, sampl= es, and intervals because

   otherwise the namespace identifier "ietf= -dots-telemetry" must be

   included when a telemetry attribute is includ= ed (e.g., in a

   mitigation efficacy update).  The use of= "identities" is thus

   suboptimal from a message compactness standpo= int.

 

The updated draft is available at: https://github.com/bouca= dair/draft-dots-telemetry/blob/master/draft-ietf-dots-telemetry-03.txt

 

Cheers,

Med

 

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

 

Hi,

&n= bsp;

See inl= ine Jon1>

&n= bsp;

Regards=

&n= bsp;

Jon

&n= bsp;

 
1)  &nbs=
p;   why do w=
e not have a “enum megabit-ps” in “typedef unit” in=
 the YANG Module?
[Med]  This can be added to the list as ‘units(=
)’ are negotiated. *-bytes are more used for aggregates, but let̵=
7;s be consistent and have both bit/bytes in the units.
Jon> Megabytes works w=
ith aggregates, megabits works with pipes.
[Med] I added the unit to the module. BTW, in order to eas=
ily define new units, I updated the module so that units are defined as ide=
ntities, not enumerations. The updated mapping table is: h=
ttps://github.com/boucadair/draft-dots-telemetry/blob/master/mapping-table.=
txt (or https://github.com/boucadair/dr=
aft-dots-telemetry/blob/master/draft-ietf-dots-telemetry-03.txt) 
Jon1> Typo in megabite-ps
Jon1> I am not sure about the usage of identityref.  https://tools.ietf=
.org/html/rfc7951#section-6.8 states that the value is represented as a=
 string (currently the CBOR mapping entry says it is an integer), and furth=
ermore it is likely that the namespace-qualified form is required. This is =
a huge increase in the number of bytes needed whenever unit (and measurement-interval Etc.) are used.  I think tha=
t this is a bad change.  
 
--_000_787AE7BB302AE849A7480A190F8B93303143E7DAOPEXCAUBMA2corp_-- From nobody Mon Feb 24 00:17:17 2020 Return-Path: X-Original-To: dots@ietfa.amsl.com Delivered-To: dots@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E49AF3A086E for ; Mon, 24 Feb 2020 00:17:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.797 X-Spam-Level: X-Spam-Status: No, score=-2.797 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_DNSWL_LOW=-0.7, 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 o_jjC_-bQO2I for ; Mon, 24 Feb 2020 00:17:13 -0800 (PST) Received: from relais-inet.orange.com (relais-inet.orange.com [80.12.66.41]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 45C3E3A086D for ; Mon, 24 Feb 2020 00:17:13 -0800 (PST) Received: from opfedar01.francetelecom.fr (unknown [xx.xx.xx.2]) by opfedar21.francetelecom.fr (ESMTP service) with ESMTP id 48Qw072Nnwz7tZ9; Mon, 24 Feb 2020 09:17:11 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1582532231; bh=mItFNuxWeBK9YTYza3bl4VEFCVtxbE5AgiTIJvAQYak=; h=From:To:Subject:Date:Message-ID:Content-Type:MIME-Version; b=o8Wew1NM6vyFX7zDFYdBqoyITDekXyPbIzQTgwnGBIf8JiSkkPb7IPv3Vk70+OdBD 9gOFjgBYR4tFs9UEIx9MXQkHG34OTzg9e+ZLs0wXrNpBusgecBMhNkQBLXbHF3viE9 I28lyqLoLYaCAXhI2CleS6QSNTkdsFM679bXWYZScElotpJmtrN/CgTLMzSEyiTrNH Cu9Q+eMkxbIVAbscvj51BHy64TodhDkZC0lURIQpQGvJdPzMssU66XgOQ7pu+9DMe7 xS4UiZC80qWBsKT9lwR4jlu6R+aSJo8dUAu0aYwFA2BSqVzf3HA7iptkDgY9dCVAAU l+pAnfQ4FMPtQ== Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.35]) by opfedar01.francetelecom.fr (ESMTP service) with ESMTP id 48Qw071BrHzBrM6; Mon, 24 Feb 2020 09:17:11 +0100 (CET) Received: from OPEXCAUBMA2.corporate.adroot.infra.ftgroup ([fe80::e878:bd0:c89e:5b42]) by OPEXCAUBM6C.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0468.000; Mon, 24 Feb 2020 09:17:10 +0100 From: To: Jon Shallow , "Konda, Tirumaleswar Reddy" , kaname nishizuka , "dots@ietf.org" Thread-Topic: prefix with namespace identifier in draft-ietf-dots-signal-filter-control Thread-Index: AdXq6s5ptufAkTb0RYWD/FCAL3pHlw== Date: Mon, 24 Feb 2020 08:17:10 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93303143E803@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.247] Content-Type: multipart/alternative; boundary="_000_787AE7BB302AE849A7480A190F8B93303143E803OPEXCAUBMA2corp_" MIME-Version: 1.0 Archived-At: Subject: [Dots] prefix with namespace identifier in draft-ietf-dots-signal-filter-control 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, 24 Feb 2020 08:17:15 -0000 --_000_787AE7BB302AE849A7480A190F8B93303143E803OPEXCAUBMA2corp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re-, The prefix use in draft-ietf-dots-signal-filter-control-02#section-5.1 is c= orrect given that acl-* attributes are not defined in the base YANG module = as being part of a mitigation request. We assumed that the same key value is used for both (e.g., acl-name and iet= f-dots-signal-control:acl-name). Given that we revisited that design in the= telemetry I-D, I'm afraid that we will need to assign key values for ietf-= dots-signal-control:acl-list and ietf-dots-signal-control:acl-name. Cheers, Med De : Jon Shallow [mailto:supjps-ietf@jpshallow.com] Envoy=E9 : vendredi 21 f=E9vrier 2020 16:46 =C0 : BOUCADAIR Mohamed TGI/OLN; Konda, Tirumaleswar Reddy; kaname nishizuk= a; dots@ietf.org Objet : RE: [Dots] DOTS telemetry questions Hi, See inline Jon1> Regards Jon Jon> We have the same naming issues in draft-ietf-dots-signal-filter-contr= ol-00 where we do not have the ietf-dots-signal-control: prefix in the JSON= examples (Fig 10) [Med] Fig 10 is a "normal" mitigation request. Why should it need to includ= e "ietf-dots-signal-control:" prefix? Jon1> My bad - I was looking at draft-ietf-dots-signal-filter-control-00, n= ot draft-ietf-dots-signal-filter-control-02. However, https://tools.ietf.o= rg/html/draft-ietf-dots-signal-filter-control-02#section-5.1 only defines "= activation-type" without the prefix, and acl-list and acl-name have the inc= orrect prefix: added to, for example, Figure 1. --_000_787AE7BB302AE849A7480A190F8B93303143E803OPEXCAUBMA2corp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Re-,

 

The prefix use in draft-ietf-dots-signal-filter-control-02#se= ction-5.1 is correct given that acl-* attributes are not defined in the bas= e YANG module as being part of a mitigation request.

 

We assumed that the same key value is used for both (e.g., ac= l-name and ietf-dots-signal-control:acl-name). Given that we revisited that= design in the telemetry I-D, I’m afraid that we will need to assign key values for ietf-dots-signal-control:acl-list an= d ietf-dots-signal-control:acl-name.

Cheers,

Med

 

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

 

Hi,

&n= bsp;

See inl= ine Jon1>

&n= bsp;

Regards=

&n= bsp;

Jon

&n= bsp;

 

Jon> We  have the same naming issues in draft-ietf-dots-s=
ignal-filter-control-00 where we do not have the [Med] Fig 10 is a ̶=
0;normal” mitigation request. Why should it need to include “ie=
tf-dots-signal-control:” prefix?
 

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

&n= bsp;

--_000_787AE7BB302AE849A7480A190F8B93303143E803OPEXCAUBMA2corp_-- From nobody Mon Feb 24 01:18: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 5501F3A098A for ; Mon, 24 Feb 2020 01:18:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=orange.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ca1L8SLsn7er for ; Mon, 24 Feb 2020 01:18:19 -0800 (PST) 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 D12CA3A098B for ; Mon, 24 Feb 2020 01:18:18 -0800 (PST) Received: from opfednr04.francetelecom.fr (unknown [xx.xx.xx.68]) by opfednr21.francetelecom.fr (ESMTP service) with ESMTP id 48QxLd08NXz5vdj; Mon, 24 Feb 2020 10:18:17 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1582535897; bh=zt35kedxbu8Ur7Zr1p6eHveYOToSzrQ3706hZGmH96k=; h=From:To:Subject:Date:Message-ID:Content-Type:MIME-Version; b=bNIbEEURV7JQ8/l9JWvdsibmzmOkoolJupEzmYZia710sYSm+ewIHCxE/MV57LsE1 6OKonPVIes4o93gHx9c/bgmVSVtZUr3EYvnuBKifwzYE6mHHKUTDi6NWAGxUQLOs+T hZ1l/ot1gTehTK0c6ooFKtvj7Jw8EKS9Gq0L2gPrzgGXiSDpCGcHKUwBnG+PiLO5yt Jin8wjYEBnR/fB/+jR+EmDZBhr1fmqnP97J2wL41yDVx9VkArRZTeCaUK2jdPxNZGX LoHG3M990U44VbpTl4kr2siNBhLI7XMI8gZyir5UTLkTbzwYbpfnkbPrH3kTQjCFqm /OcwbV44F4uDg== Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.32]) by opfednr04.francetelecom.fr (ESMTP service) with ESMTP id 48QxLc6PPhz1xpp; Mon, 24 Feb 2020 10:18:16 +0100 (CET) Received: from OPEXCAUBMA2.corporate.adroot.infra.ftgroup ([fe80::e878:bd0:c89e:5b42]) by OPEXCAUBM7C.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0468.000; Mon, 24 Feb 2020 10:18:16 +0100 From: To: Jon Shallow , "Konda, Tirumaleswar Reddy" , kaname nishizuka , "dots@ietf.org" Thread-Topic: 'mid' reference to ease requests correlation (RE: [Dots] DOTS telemetry questions) Thread-Index: AdXq81iV+oyJapQRTzyH8Y7ZzOpvqw== Date: Mon, 24 Feb 2020 09:18:16 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93303143E83E@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.247] Content-Type: multipart/alternative; boundary="_000_787AE7BB302AE849A7480A190F8B93303143E83EOPEXCAUBMA2corp_" MIME-Version: 1.0 Archived-At: Subject: [Dots] 'mid' reference to ease requests correlation (RE: DOTS telemetry questions) X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Feb 2020 09:18:20 -0000 --_000_787AE7BB302AE849A7480A190F8B93303143E83EOPEXCAUBMA2corp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, No change so far. We need to assess this further. Cheers, Med 1) I am confused by "pre-mitigation" which can be transmitted pre any = mitigation taking place, or actually during when mitigation is taking place= (or so I think) and would simply be better described as "attack-details" -= especially with a statement such as DOTS agents MUST bind pre-mitigation telemetry data with mitigation requests relying upon the target clause. [Med] That's an option but the current design allows to have the telemetry = in // in order to supply more data ** without impacting the placement of a = mitigation request ** hence the need to bind both (if any). If telemetry at= tributes are defined as mandatory (discussed in another thread), this would= mean that the server will reject a mitigation that includes such attribute= s. With the current design, we have a functionality that can be safely enab= led independently of the decision that we will make about whether telemetry= attributes are mandatory to be supported or not. Jon> My primary point here was the use of the term "pre-mitigation" - this = telemetry is also needs during a mitigation and the attack keeps on morphin= g into something else. Another point we can check to ease correlation between a mitigation request= and pre-mitigation telemetry is to signal the "mid" in the telemetry messa= ge. Jon> could be - need to think this through Regards Jon --_000_787AE7BB302AE849A7480A190F8B93303143E83EOPEXCAUBMA2corp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi all,

 

No change so far. We need to assess this further.

 

Cheers,

Med

 

 = 

1)  &nbs=
p;   I am con=
fused by “pre-mitigation” which can be transmitted pre any miti=
gation taking place, or actually during when mitigation is taking place (or=
 so I think) and would simply be better described as “attack-details&=
#8221; – especially with a statement such as

 = 

   DOTS ag=
ents MUST bind pre-mitigation telemetry data with mitigation
   request=
s relying upon the target clause.
 
[Med] That’s an option but the current design allows=
 to have the telemetry in // in order to supply more data ** without impact=
ing the placement of a mitigation request ** hence the need to bind both (i=
f any). If telemetry attributes are defined as mandatory (discussed in anot=
her thread), this would mean that the server will reject a mitigation that =
includes such attributes. With the current design, we have a functionality =
that can be safely enabled independently of the decision that we will make =
about whether telemetry attributes are mandatory to be supported or not.
Jon> My primary point =
here was the use of the term “pre-mitigation” – this tele=
metry is also needs during a mitigation and the attack keeps on morphing in=
to something else.
 
Another point we can check to ease correlation between a m=
itigation request and pre-mitigation telemetry is to signal the “mid&=
#8221; in the telemetry message.
Jon> could be – need to think this through
 
Regards
 
Jon=
--_000_787AE7BB302AE849A7480A190F8B93303143E83EOPEXCAUBMA2corp_-- From nobody Tue Feb 25 02:07:48 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 2EFF33A0808 for ; Tue, 25 Feb 2020 02:07:47 -0800 (PST) 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, DKIMWL_WL_HIGH=-0.001, 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 (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 NeBxsHRFAJey for ; Tue, 25 Feb 2020 02:07:44 -0800 (PST) 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 47BB93A0806 for ; Tue, 25 Feb 2020 02:07:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mcafee.com; s=mimecast20190606; t=1582625263; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=mq05wiptkUi9beT5DZSgzB2GHv+XbQTTDSwDEJxbtM4=; b=CFus9ei0CBfi/MDZwfYG2FE6bFw9jF1wtNtbsCp8DPfV5z2UEqQJgZNaIqEg+srllMxSEL QsQwyBfU79aTxv1wg1swa1Knusr1e2D2/MKuVZO415kTaMOnniyYD9labFzzpEO5xz31YI UtKZ6BzbP2NHvQmDmCD7p9N+aohJ4UI= Received: from NAM10-MW2-obe.outbound.protection.outlook.com (mail-mw2nam10lp2104.outbound.protection.outlook.com [104.47.55.104]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-83-oYB9qPTMPvi9FziITN9HIw-1; Tue, 25 Feb 2020 05:07:41 -0500 X-MC-Unique: oYB9qPTMPvi9FziITN9HIw-1 Received: from CY4PR1601MB1254.namprd16.prod.outlook.com (2603:10b6:903:d4::12) by CY4PR1601MB1207.namprd16.prod.outlook.com (2603:10b6:903:d9::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2750.21; Tue, 25 Feb 2020 10:07:39 +0000 Received: from CY4PR1601MB1254.namprd16.prod.outlook.com ([fe80::a48c:a975:ccfa:8d29]) by CY4PR1601MB1254.namprd16.prod.outlook.com ([fe80::a48c:a975:ccfa:8d29%4]) with mapi id 15.20.2750.021; Tue, 25 Feb 2020 10:07:39 +0000 From: "Konda, Tirumaleswar Reddy" To: "mohamed.boucadair@orange.com" , Jon Shallow , kaname nishizuka , "dots@ietf.org" Thread-Topic: 'mid' reference to ease requests correlation (RE: [Dots] DOTS telemetry questions) Thread-Index: AdXq81iV+oyJapQRTzyH8Y7ZzOpvqwAzxXpg Date: Tue, 25 Feb 2020 10:07:39 +0000 Message-ID: References: <787AE7BB302AE849A7480A190F8B93303143E83E@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> In-Reply-To: <787AE7BB302AE849A7480A190F8B93303143E83E@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-version: 11.4.0.45 dlp-reaction: no-action x-originating-ip: [103.245.47.20] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: fc358b07-dfa2-43ac-06c3-08d7b9da8ba1 x-ms-traffictypediagnostic: CY4PR1601MB1207: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0324C2C0E2 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(136003)(396003)(39860400002)(376002)(346002)(366004)(32952001)(199004)(189003)(86362001)(52536014)(66476007)(33656002)(26005)(53546011)(66946007)(478600001)(71200400001)(966005)(8676002)(186003)(81166006)(76116006)(66556008)(9686003)(7696005)(316002)(64756008)(110136005)(66446008)(5660300002)(55016002)(2906002)(81156014)(8936002)(6506007)(85282002); DIR:OUT; SFP:1101; SCL:1; SRVR:CY4PR1601MB1207; H:CY4PR1601MB1254.namprd16.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: wE9LY+39G4AT7Z81kVvq9UY/v7ydPnCSICGkRQRXhLD/6JIXSJt0SIgYjy14qxPe3SaTTDFT9z/lXa0OwtiTLJ5Bw7DB7oVucPteX0I6gpuPU78ZWYavWuFpFJ+PQcffq3CKBSNbYmY9dbCdZo9Y6i1nQjaGM6cxGlT/tIyRg1agsfE4Va6DGB12VePtFTT6BeJl6KrO8M3x4fOgYe5vyh31CIZi7Ki60f384ZMj8pLYO9yq2u3gs9n5ScMMyyKLzux7pJF3eYwYil0En4rHb/N9qc+EjmWqdZ3G3fZe5Rn94Hg6r5U9qLtDGX94Zbi3B235NbVXdvV+flAcRIlSp73dP6T1I0Mot2maUt0myzb7By4WrAndVpV8QXGPapzls55bBbA2OsipzDBJ44633w5NK4dggyKzmy96eMctzfjxy2UjLeCmzhhZBk3SuX0L6zrcjPeglG25c5VpbdWKm9/0b++gahXNNen+nsmnnk5TJ8P5oa8m3lQnGZy3uglL+Jcln8yeaeqVNvY8HkfJtJQFghcSSqkkCkA/4VczASNIgTk/GoXoO/OajPLVcnSVTYtjHXKIgbGTtkUFJEbJAbDyH3OPu3uF0/LseFAxPIE= x-ms-exchange-antispam-messagedata: rGjdLH2kP6v963OXZiVfusFKTbNv/N5R1OKypB6nRj6AtDCtpLJSGxIVRJVkT6gv9Qy7MA3Tji13/BIeW2GAM9d7doMlKreJ59RlPDutZMx+YpWcuQjLShlXUi9Oc9otPesVEgP+g8Vt3IF3TZO6DQ== x-ms-exchange-transport-forked: True MIME-Version: 1.0 X-OriginatorOrg: mcafee.com X-MS-Exchange-CrossTenant-Network-Message-Id: fc358b07-dfa2-43ac-06c3-08d7b9da8ba1 X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Feb 2020 10:07:39.1150 (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: bjY3HE7yRiVQy01TfAVrYyGz5/t3eZnAdYwwAyeYxoMeFy9kyKr4grtAVcnUF1ghzEqCLyHoj8vYM0rJ6fvd2WBaJ3nN2cf7TXK2Qu63qc46ymUfI9JzUXQYhg0OYwRZ X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR1601MB1207 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: mcafee.com Content-Type: multipart/alternative; boundary="_000_CY4PR1601MB1254F7F2DBE503B09E9FDA77EAED0CY4PR1601MB1254_" Archived-At: Subject: Re: [Dots] 'mid' reference to ease requests correlation (RE: DOTS telemetry questions) X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Feb 2020 10:07:47 -0000 --_000_CY4PR1601MB1254F7F2DBE503B09E9FDA77EAED0CY4PR1601MB1254_ Content-Type: text/plain; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable DOTS can leverage https://tools.ietf.org/html/draft-ietf-core-comi-08#secti= on-6.1 to determine whether the telemetry attributes are supported by the D= OTS server or not. This will avoid rejection of mitigation request. Cheers, -Tiru From: mohamed.boucadair@orange.com Sent: Monday, February 24, 2020 2:48 PM To: Jon Shallow ; Konda, Tirumaleswar Reddy ; kaname nishizuka ; dots@= ietf.org Subject: 'mid' reference to ease requests correlation (RE: [Dots] DOTS tele= metry questions) CAUTION: External email. Do not click links or open attachments unless you = recognize the sender and know the content is safe. ________________________________ Hi all, No change so far. We need to assess this further. Cheers, Med 1) I am confused by "pre-mitigation" which can be transmitted pre any = mitigation taking place, or actually during when mitigation is taking place= (or so I think) and would simply be better described as "attack-details" -= especially with a statement such as DOTS agents MUST bind pre-mitigation telemetry data with mitigation requests relying upon the target clause. [Med] That's an option but the current design allows to have the telemetry = in // in order to supply more data ** without impacting the placement of a = mitigation request ** hence the need to bind both (if any). If telemetry at= tributes are defined as mandatory (discussed in another thread), this would= mean that the server will reject a mitigation that includes such attribute= s. With the current design, we have a functionality that can be safely enab= led independently of the decision that we will make about whether telemetry= attributes are mandatory to be supported or not. Jon> My primary point here was the use of the term "pre-mitigation" - this = telemetry is also needs during a mitigation and the attack keeps on morphin= g into something else. Another point we can check to ease correlation between a mitigation request= and pre-mitigation telemetry is to signal the "mid" in the telemetry messa= ge. Jon> could be - need to think this through Regards Jon --_000_CY4PR1601MB1254F7F2DBE503B09E9FDA77EAED0CY4PR1601MB1254_ Content-Type: text/html; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable

DOTS can leverage https://tools.ietf.org/html/draft-ietf-core-comi-08#section-6.1 to dete= rmine whether the telemetry attributes are supported by the DOTS server or = not. This will avoid rejection of mitigation request.

 

Cheers,

-Tiru

 

From: mohamed.boucadair@orange.com <mohame= d.boucadair@orange.com>
Sent: Monday, February 24, 2020 2:48 PM
To: Jon Shallow <supjps-ietf@jpshallow.com>; Konda, Tirumalesw= ar Reddy <TirumaleswarReddy_Konda@McAfee.com>; kaname nishizuka <k= aname@nttv6.jp>; dots@ietf.org
Subject: 'mid' reference to ease requests correlation (RE: [Dots] DO= TS telemetry questions)

 

CAUTION: External email. Do not click links or open attachments unless you recognize the sender and know the content is safe.<= /span><= /span>

 

Hi all,

 

No change so far. We need to assess this further.

 

Cheers,

Med

 

 = 

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

 = 

   DOTS age=
nts MUST bind pre-mitigation telemetry data with mitigation
   requests=
 relying upon the target clause.
 
[Med] That’s an option but the current design allows=
 to have the telemetry in // in order to supply more data ** without impact=
ing the placement of a mitigation request ** hence the need to bind both (i=
f any). If telemetry attributes are defined as mandatory (discussed in anot=
her thread), this would mean that the server will reject a mitigation that =
includes such attributes. With the current design, we have a functionality =
that can be safely enabled independently of the decision that we will make =
about whether telemetry attributes are mandatory to be supported or not.
Jon> My primary point =
here was the use of the term “pre-mitigation” – this tele=
metry is also needs during a mitigation and the attack keeps on morphing in=
to something else.
 
Another point we can check to ease correlation between a m=
itigation request and pre-mitigation telemetry is to signal the “mid&=
#8221; in the telemetry message.
Jon> could be – need to think this through
 
Regards
 
Jon=
--_000_CY4PR1601MB1254F7F2DBE503B09E9FDA77EAED0CY4PR1601MB1254_-- From nobody Wed Feb 26 04:21:10 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 205033A08C0 for ; Wed, 26 Feb 2020 04:21:08 -0800 (PST) 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 LvKPj14hDYTO for ; Wed, 26 Feb 2020 04:21:04 -0800 (PST) Received: from mail.jpshallow.com (mail.jpshallow.com [217.40.240.153]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C09613A0784 for ; Wed, 26 Feb 2020 04:21:03 -0800 (PST) Received: from mail2.jpshallow.com ([192.168.0.3] helo=N01332) by mail.jpshallow.com with esmtp (Exim 4.92.3) (envelope-from ) id 1j6vgO-0006YD-5j; Wed, 26 Feb 2020 12:20:56 +0000 From: "Jon Shallow" To: , "Konda, Tirumaleswar Reddy" , "kaname nishizuka" , References: <787AE7BB302AE849A7480A190F8B93303143E803@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> In-Reply-To: <787AE7BB302AE849A7480A190F8B93303143E803@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> Date: Wed, 26 Feb 2020 12:21:04 -0000 Message-ID: <00ab01d5ec9f$372c6830$a5853890$@jpshallow.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00AC_01D5EC9F.372DEED0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQKwyXYP4ly1xZD5xh2+JSnmkwkmIqZ3qYiA Content-Language: en-gb Archived-At: Subject: Re: [Dots] prefix with namespace identifier in draft-ietf-dots-signal-filter-control 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, 26 Feb 2020 12:21:08 -0000 This is a multipart message in MIME format. ------=_NextPart_000_00AC_01D5EC9F.372DEED0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi all, =20 Thinking out of the box, for Figure 8 we have =20 "ietf-dots-signal-channel:mitigation-scope": { "scope": [ { "target-prefix": [ "2001:db8:6401::2/127" ], "target-protocol": [ 17 ], "ietf-dots-signal-control:acl-list": [ { "ietf-dots-signal-control:acl-name": "my-accept-list", "ietf-dots-signal-control:activation-type": "immediate" } "lifetime": 3600 } ] } } =20 If this was to be replaced with =20 "ietf-dots-signal-control:mitigation-scope": { "scope": [ { "target-prefix": [ "2001:db8:6401::2/127" ], "target-protocol": [ 17 ], " acl-list": [ { " acl-name": "my-accept-list", " activation-type": "immediate" } "lifetime": 3600 } ] } } =20 As the module is ietf-dots-signal-control: which includes the augments - Would that not be valid (and a lot simpler)? =20 So we only need a CBOR definition for ietf-dots-signal-channel:mitigation-scope and separately for ietf-dots-signal-control:mitigation-scope as well as the augmented new entries. =20 Regards =20 Jon =20 From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of mohamed.boucadair@orange.com Sent: 24 February 2020 08:17 To: Jon Shallow; Konda, Tirumaleswar Reddy; kaname nishizuka; = dots@ietf.org Subject: [Dots] prefix with namespace identifier in draft-ietf-dots-signal-filter-control =20 Re-, =20 The prefix use in draft-ietf-dots-signal-filter-control-02#section-5.1 = is correct given that acl-* attributes are not defined in the base YANG = module as being part of a mitigation request.=20 =20 We assumed that the same key value is used for both (e.g., acl-name and ietf-dots-signal-control:acl-name). Given that we revisited that design = in the telemetry I-D, I=92m afraid that we will need to assign key values = for ietf-dots-signal-control:acl-list and ietf-dots-signal-control:acl-name. =20 Cheers, Med =20 De : Jon Shallow [mailto:supjps-ietf@jpshallow.com]=20 Envoy=E9 : vendredi 21 f=E9vrier 2020 16:46 =C0 : BOUCADAIR Mohamed TGI/OLN; Konda, Tirumaleswar Reddy; kaname = nishizuka; dots@ietf.org Objet : RE: [Dots] DOTS telemetry questions =20 Hi, =20 See inline Jon1> =20 Regards =20 Jon =20 =20 Jon> We have the same naming issues in draft-ietf-dots-signal-filter-control-00 where we do not have the ietf-dots-signal-control: prefix in the JSON examples (Fig 10) [Med] Fig 10 is a =93normal=94 mitigation request. Why should it need to = include =93ietf-dots-signal-control:=94 prefix? =20 Jon1> My bad =96 I was looking at = draft-ietf-dots-signal-filter-control-00, not draft-ietf-dots-signal-filter-control-02. However, https://tools.ietf.org/html/draft-ietf-dots-signal-filter-control-02#sect= ion -5.1 only defines =93activation-type=94 without the prefix, and acl-list = and acl-name have the incorrect prefix: added to, for example, Figure 1. =20 ------=_NextPart_000_00AC_01D5EC9F.372DEED0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi all,

 

Thinking out of the box, = for Figure 8 we have

 

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

=A0=A0=A0=A0=A0=A0=A0 "scope": = [

=A0=A0=A0=A0=A0=A0=A0=A0=A0 = {

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = "target-prefix": [

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = "2001:db8:6401::2/127"

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = ],

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = "target-protocol": [

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = 17

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = ],

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = "ietf-dots-signal-control:acl-list": [

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = {

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = "ietf-dots-signal-control:acl-name": = "my-accept-list",

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = "ietf-dots-signal-control:activation-type": = "immediate"

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = }

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = "lifetime": 3600

=A0=A0=A0=A0=A0=A0=A0=A0=A0 = }

=A0=A0=A0=A0=A0=A0=A0 ]

=A0=A0=A0=A0=A0 = }

=A0=A0=A0 }

 

If this was to be = replaced with

 

=A0=A0=A0=A0=A0 = "ietf-dots-signal-control:mitigation-scope": = {

=A0=A0=A0=A0=A0=A0=A0 "scope": = [

=A0=A0=A0=A0=A0=A0=A0=A0=A0 = {

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = "target-prefix": [

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = "2001:db8:6401::2/127"

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = ],

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = "target-protocol": [

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = 17

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = =A0],

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 " = acl-list": [

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = {

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = " acl-name": = "my-accept-list",

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = " activation-type": = "immediate"

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = }

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = "lifetime": 3600

=A0=A0=A0=A0=A0=A0=A0=A0=A0 = }

=A0=A0=A0=A0=A0=A0=A0 ]

=A0=A0=A0=A0=A0 = }

=A0=A0=A0 }

 

As the module is = ietf-dots-signal-control: which includes the augments - = Would that not be valid (and a lot simpler)?

 

So we only need a CBOR = definition for ietf-dots-signal-channel:mitigation-scope and separately = for ietf-dots-signal-control:mitigation-scope as well as the augmented = new entries.

 

Regards

 

Jon

 

From:= Dots = [mailto: dots-bounces@ietf.org] On Behalf Of = mohamed.boucadair@orange.com
Sent: 24 February 2020 = 08:17
To: Jon Shallow; Konda, Tirumaleswar Reddy; kaname = nishizuka; dots@ietf.org
Subject: [Dots] prefix with namespace = identifier in = draft-ietf-dots-signal-filter-control

 

Re-,

 

The prefix use in = draft-ietf-dots-signal-filter-control-02#section-5.1 is correct given = that acl-* attributes are not defined in the base YANG module as being = part of a mitigation request.

 

We assumed that the same key value is used for both = (e.g., acl-name and ietf-dots-signal-control:acl-name). Given that we = revisited that design in the telemetry I-D, I’m afraid that we = will need to assign key values for ietf-dots-signal-control:acl-list and = ietf-dots-signal-control:acl-name.

 

Cheers,

Med

 

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

 

Hi,

 

See inline = Jon1>

 

Regards

 

Jon

 

 

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

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

 

------=_NextPart_000_00AC_01D5EC9F.372DEED0-- From nobody Wed Feb 26 04:54:24 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 AC42D3A0852 for ; Wed, 26 Feb 2020 04:54:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=orange.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dhLeWWj8Sl1T for ; Wed, 26 Feb 2020 04:54:21 -0800 (PST) Received: from relais-inet.orange.com (relais-inet.orange.com [80.12.66.39]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B92B63A084E for ; Wed, 26 Feb 2020 04:54:20 -0800 (PST) Received: from opfedar05.francetelecom.fr (unknown [xx.xx.xx.7]) by opfedar21.francetelecom.fr (ESMTP service) with ESMTP id 48SG2z3SVpz7v6Y; Wed, 26 Feb 2020 13:54:19 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1582721659; bh=0G8RiNmYiUsm/kyLhU2sqAiE1qyV7T1g5J2gE+z4Zto=; h=From:To:Subject:Date:Message-ID:Content-Type:MIME-Version; b=AKZB3hDXX6qlHK0H0SYdOBe4CI6PGQUodnatiw8gxMZXKgQyna9vzU6cJbXkcw/yJ m37IiprGA4gfpOR8lyEucTNbdA0yQkmCe41Wq35/8MhZTwigFA9xogTbexJOeu1Gtp e+GbuXM3q52ZSUOK30wrdpRzrv8UMtOQLp6/fPNQGqq4N9ngZ58VkaomDn835sV289 zBrlcqIcSHh9vso7RjRL8gyK1UCV1QSEFK3AhuKXA77Gk79MVCrKvn+W0H2qQvIN5l ML2A7nISodPU1o+DlJ6Z8wiI37KmPRSTis8KAx1R5wLGouWC8C+EKs5bsfXXFe+GO/ efbhxQYyTWKxw== Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.82]) by opfedar05.francetelecom.fr (ESMTP service) with ESMTP id 48SG2z27GDz2xCn; Wed, 26 Feb 2020 13:54:19 +0100 (CET) Received: from OPEXCAUBMA2.corporate.adroot.infra.ftgroup ([fe80::e878:bd0:c89e:5b42]) by OPEXCAUBM5E.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0468.000; Wed, 26 Feb 2020 13:54:19 +0100 From: To: Jon Shallow , "Konda, Tirumaleswar Reddy" , kaname nishizuka , "dots@ietf.org" Thread-Topic: [Dots] prefix with namespace identifier in draft-ietf-dots-signal-filter-control Thread-Index: AQKwyXYP4ly1xZD5xh2+JSnmkwkmIqZ3qYiAgAAJwnA= Date: Wed, 26 Feb 2020 12:54:18 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B9330314400FA@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> References: <787AE7BB302AE849A7480A190F8B93303143E803@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <00ab01d5ec9f$372c6830$a5853890$@jpshallow.com> In-Reply-To: <00ab01d5ec9f$372c6830$a5853890$@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_787AE7BB302AE849A7480A190F8B9330314400FAOPEXCAUBMA2corp_" MIME-Version: 1.0 Archived-At: Subject: Re: [Dots] prefix with namespace identifier in draft-ietf-dots-signal-filter-control 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, 26 Feb 2020 12:54:24 -0000 --_000_787AE7BB302AE849A7480A190F8B9330314400FAOPEXCAUBMA2corp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Jon, We can't do that because "mitigation-scope" is not defined in ietf-dots-sig= nal-control. FWIW, draft-ietf-core-yang-cbor says the following (which cons= istent with 7951) =3D=3D o namespace qualified - the identifier of the YANG item is prefixed with the name of the module in which this item is defined, separated by the colon character (":"). The name of a module determines the namespace of all YANG items defined in that module. If an item is defined in a submodule, then the namespace qualified name uses the name of the main module to which the submodule belongs. =3D=3D Cheers, Med De : Jon Shallow [mailto:supjps-ietf@jpshallow.com] Envoy=E9 : mercredi 26 f=E9vrier 2020 13:21 =C0 : BOUCADAIR Mohamed TGI/OLN; Konda, Tirumaleswar Reddy; kaname nishizuk= a; dots@ietf.org Objet : RE: [Dots] prefix with namespace identifier in draft-ietf-dots-sign= al-filter-control Hi all, Thinking out of the box, for Figure 8 we have "ietf-dots-signal-channel:mitigation-scope": { "scope": [ { "target-prefix": [ "2001:db8:6401::2/127" ], "target-protocol": [ 17 ], "ietf-dots-signal-control:acl-list": [ { "ietf-dots-signal-control:acl-name": "my-accept-list", "ietf-dots-signal-control:activation-type": "immediate" } "lifetime": 3600 } ] } } If this was to be replaced with "ietf-dots-signal-control:mitigation-scope": { "scope": [ { "target-prefix": [ "2001:db8:6401::2/127" ], "target-protocol": [ 17 ], " acl-list": [ { " acl-name": "my-accept-list", " activation-type": "immediate" } "lifetime": 3600 } ] } } As the module is ietf-dots-signal-control: which includes the augments - Wo= uld that not be valid (and a lot simpler)? So we only need a CBOR definition for ietf-dots-signal-channel:mitigation-s= cope and separately for ietf-dots-signal-control:mitigation-scope as well a= s the augmented new entries. Regards Jon From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of mohamed.boucadair@o= range.com Sent: 24 February 2020 08:17 To: Jon Shallow; Konda, Tirumaleswar Reddy; kaname nishizuka; dots@ietf.org Subject: [Dots] prefix with namespace identifier in draft-ietf-dots-signal-= filter-control Re-, The prefix use in draft-ietf-dots-signal-filter-control-02#section-5.1 is c= orrect given that acl-* attributes are not defined in the base YANG module = as being part of a mitigation request. We assumed that the same key value is used for both (e.g., acl-name and iet= f-dots-signal-control:acl-name). Given that we revisited that design in the= telemetry I-D, I'm afraid that we will need to assign key values for ietf-= dots-signal-control:acl-list and ietf-dots-signal-control:acl-name. Cheers, Med De : Jon Shallow [mailto:supjps-ietf@jpshallow.com] Envoy=E9 : vendredi 21 f=E9vrier 2020 16:46 =C0 : BOUCADAIR Mohamed TGI/OLN; Konda, Tirumaleswar Reddy; kaname nishizuk= a; dots@ietf.org Objet : RE: [Dots] DOTS telemetry questions Hi, See inline Jon1> Regards Jon Jon> We have the same naming issues in draft-ietf-dots-signal-filter-contr= ol-00 where we do not have the ietf-dots-signal-control: prefix in the JSON= examples (Fig 10) [Med] Fig 10 is a "normal" mitigation request. Why should it need to includ= e "ietf-dots-signal-control:" prefix? Jon1> My bad - I was looking at draft-ietf-dots-signal-filter-control-00, n= ot draft-ietf-dots-signal-filter-control-02. However, https://tools.ietf.o= rg/html/draft-ietf-dots-signal-filter-control-02#section-5.1 only defines "= activation-type" without the prefix, and acl-list and acl-name have the inc= orrect prefix: added to, for example, Figure 1. --_000_787AE7BB302AE849A7480A190F8B9330314400FAOPEXCAUBMA2corp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Jon,

 

We can’t do that because “mitigation-scope” is not defined in ietf-d= ots-signal-control. FWIW, draft-ietf-core-yang-cbor says the following (which consistent with = 7951)

 

=3D=3D

   o  namespace qualified - the identifier = of the YANG item is prefixed

      with the name of the module= in which this item is defined,

      separated by the colon char= acter (":").

 

   The name of a module determines the namespace= of all YANG items

   defined in that module.  If an item is d= efined in a submodule, then

   the namespace qualified name uses the name of= the main module to

   which the submodule belongs.

 

=3D=3D

 

Cheers,

Med

 

De : Jon Shallow [mailto:supjps-ietf@jpshallow.com]
Envoy=E9 : mercredi 26 f=E9vrier 2020 13:21
=C0 : BOUCADAIR Mohamed TGI/OLN; Konda, Tirumaleswar Reddy; kan= ame nishizuka; dots@ietf.org
Objet : RE: [Dots] prefix with namespace identifier in draft-ie= tf-dots-signal-filter-control

 

Hi all,=

&n= bsp;

Thinkin= g out of the box, for Figure 8 we have

&n= bsp;

 &= nbsp;    "ietf-dots-signal-channel:mitigation-scope&quo= t;: {

 &= nbsp;      "scope": [<= /p>

 &= nbsp;        {

 &= nbsp;          "target-pr= efix": [

 &= nbsp;           &nbs= p; "2001:db8:6401::2/127"

 &= nbsp;           ],

 &= nbsp;           "tar= get-protocol": [

 &= nbsp;           &nbs= p; 17

 &= nbsp;           ],

 &= nbsp;           "iet= f-dots-signal-control:acl-list": [

 &= nbsp;           &nbs= p; {

 &= nbsp;           &nbs= p;   "ietf-dots-signal-control:acl-name": "my-acce= pt-list",

 &= nbsp;           &nbs= p;   "ietf-dots-signal-control:activation-type": "= immediate"

 &= nbsp;           &nbs= p; }

 &= nbsp;          "lifetime&= quot;: 3600

 &= nbsp;        }

 &= nbsp;      ]

 &= nbsp;    }

 &= nbsp;  }

&n= bsp;

If this= was to be replaced with

&n= bsp;

 &= nbsp;    "ietf-dots-signal-control:mitiga= tion-scope": {

 &= nbsp;      "scope": [<= /p>

 &= nbsp;        {

 &= nbsp;          "target-pr= efix": [

 &= nbsp;           &nbs= p; "2001:db8:6401::2/127"

 &= nbsp;           ],

 &= nbsp;           "tar= get-protocol": [

 &= nbsp;           &nbs= p; 17

 &= nbsp;           ],

 &= nbsp;           " ac= l-list": [

 &= nbsp;           &nbs= p; {

 &= nbsp;           &nbs= p;   " acl-name": "my-accept-list",

 &= nbsp;           &nbs= p;   " activation-type": "immediate"

 &= nbsp;           &nbs= p; }

 &= nbsp;          "lifetime&= quot;: 3600

 &= nbsp;        }

 &= nbsp;      ]

 &= nbsp;    }

 &= nbsp;  }

&n= bsp;

As the = module is ietf-dots-signal-control: which includes the augmen= ts - Would that not be valid (and a lot simpler)?

&n= bsp;

So we o= nly need a CBOR definition for ietf-dots-signal-channel:mitigation-scope an= d separately for ietf-dots-signal-control:mitigation-scope as well as the a= ugmented new entries.

&n= bsp;

Regards=

&n= bsp;

Jon

&n= bsp;

From: Dots [ma= ilto: dots-bounces@ietf.org] On Behalf Of mohamed.boucadair@orange.com
Sent: 24 February 2020 08:17
To: Jon Shallow; Konda, Tirumaleswar Reddy; kaname nishizuka; dots@i= etf.org
Subject: [Dots] prefix with namespace identifier in draft-ietf-dots-= signal-filter-control

 

Re-,

 

The prefix use in draft-ietf-dots-signal-filter-control-02#se= ction-5.1 is correct given that acl-* attributes are not defined in the bas= e YANG module as being part of a mitigation request.

 

We assumed that the same key value is used for both (e.g., ac= l-name and ietf-dots-signal-control:acl-name). Given that we revisited that= design in the telemetry I-D, I’m afraid that we will need to assign key values for ietf-dots-signal-control:acl-list an= d ietf-dots-signal-control:acl-name.

 

Cheers,

Med

 

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

 

Hi,

&n= bsp;

See inl= ine Jon1>

&n= bsp;

Regards=

&n= bsp;

Jon

&n= bsp;

 

Jon> We  have the same naming issues in draft-ietf-dots-s=
ignal-filter-control-00 where we do not have the [Med] Fig 10 is a ̶=
0;normal” mitigation request. Why should it need to include “ie=
tf-dots-signal-control:” prefix?
 

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

&n= bsp;

--_000_787AE7BB302AE849A7480A190F8B9330314400FAOPEXCAUBMA2corp_-- From nobody Wed Feb 26 05:53:32 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 4093D3A02BE for ; Wed, 26 Feb 2020 05:53:30 -0800 (PST) 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, DKIMWL_WL_HIGH=-0.001, 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 (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 0j3dn4aIKidx for ; Wed, 26 Feb 2020 05:53:22 -0800 (PST) Received: from us-smtp-delivery-140.mimecast.com (us-smtp-delivery-140.mimecast.com [63.128.21.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 7C0313A03F5 for ; Wed, 26 Feb 2020 05:53:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mcafee.com; s=mimecast20190606; t=1582725195; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=ak83S3U7yrCwhTuRh3VJflndZ0gFb9uZqpojnRmFR0c=; b=RrRDQg1ZeNNKXy7VDY/I4h5kCcQo3yt8uVM8hbJp3f7BWiEGCOkQLZBlxInACFfDahvM1G eIyQggaQohsSMvKDvTsR9pr2NZ0PYCF7B502d2AayXLl1j1bZiDr9kcQK0z1U+SgMpiKe1 uKm2l42wZ1sppQ2/b3Rj5jHm0gVgAoM= Received: from NAM10-MW2-obe.outbound.protection.outlook.com (mail-mw2nam10lp2106.outbound.protection.outlook.com [104.47.55.106]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-336-14vfHRzKOCS_cp1AOySpjw-1; Wed, 26 Feb 2020 08:51:40 -0500 X-MC-Unique: 14vfHRzKOCS_cp1AOySpjw-1 Received: from CY4PR1601MB1254.namprd16.prod.outlook.com (2603:10b6:903:d4::12) by CY4PR1601MB1143.namprd16.prod.outlook.com (2603:10b6:903:ce::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2750.21; Wed, 26 Feb 2020 13:51:37 +0000 Received: from CY4PR1601MB1254.namprd16.prod.outlook.com ([fe80::a48c:a975:ccfa:8d29]) by CY4PR1601MB1254.namprd16.prod.outlook.com ([fe80::a48c:a975:ccfa:8d29%4]) with mapi id 15.20.2772.012; Wed, 26 Feb 2020 13:51:37 +0000 From: "Konda, Tirumaleswar Reddy" To: "mohamed.boucadair@orange.com" , Jon Shallow , kaname nishizuka , "dots@ietf.org" Thread-Topic: [Dots] prefix with namespace identifier in draft-ietf-dots-signal-filter-control Thread-Index: AdXq6s5ptufAkTb0RYWD/FCAL3pHlwBtGhYAAAEpIQAAAfPHkA== Date: Wed, 26 Feb 2020 13:51:37 +0000 Message-ID: References: <787AE7BB302AE849A7480A190F8B93303143E803@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <00ab01d5ec9f$372c6830$a5853890$@jpshallow.com> <787AE7BB302AE849A7480A190F8B9330314400FA@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> In-Reply-To: <787AE7BB302AE849A7480A190F8B9330314400FA@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-version: 11.4.0.45 dlp-reaction: no-action x-originating-ip: [49.37.206.212] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 741729ae-b481-45fe-25d4-08d7bac30018 x-ms-traffictypediagnostic: CY4PR1601MB1143: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 0325F6C77B x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(136003)(396003)(346002)(39860400002)(376002)(366004)(32952001)(199004)(189003)(2906002)(26005)(81156014)(86362001)(81166006)(186003)(8936002)(53546011)(6506007)(110136005)(66476007)(966005)(478600001)(66946007)(8676002)(52536014)(66556008)(76116006)(33656002)(71200400001)(66574012)(66446008)(316002)(64756008)(55016002)(9686003)(5660300002)(7696005)(85282002); DIR:OUT; SFP:1101; SCL:1; SRVR:CY4PR1601MB1143; H:CY4PR1601MB1254.namprd16.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: gmhKZh4yO86DOjBhYGEu2UrYkdfPpJJgW/jGNA/+xCEzQmqUfDGb0sNyaEJDyBqv7GrEKIsuUbZ1pLR3mR0xvUtR4LB6SxBFxn6DR88E4wQyzFYs89dqWpn3hu77RwlUxYS9r+S2kyuBMTtz9FHNiQRW3PQSbyTIHBNHRG6P4R7qAhW8zFyBwSGv0k97V1H/JyiYH11XfhzIOHX7sTrPnMeMnNnnk/BtNaAfki0kRt7mJKZdTktwd9/XNo4OlNU4pFz8+oZaKL5Kc4NHl+gckwxF1XQGSGrIrbGFST8WhfmRiRElf3TzGAF5EjjHUuAaQRbagjobpOp0H5ek05CASYbGJWeKt737aMtnc9rqVHGBUrw3+IHpbhGGkECpvKB45Feolj0x4KX3XsVGeWChQnmcOY05Nb7J7XLnjQ9aZctJzxx47ToSd/BZGgpv0hJx2X7EOOUjcQZAfJM9stRglDQ/B9ehGxOEjOMSw3Fs6XUXLIsjXFiPVbwxBAu7hbz/cmTpyYUQniGiGPiK/HXC9IDT1ID1tFhic1IoYRc1YmYIO7JBwdtJYrp+sn54a5HfcNg9NoH7ekcMm/8WlvmFI/nWl8Q7H5Ypg8MkRnlFSeU= x-ms-exchange-antispam-messagedata: 5IytWTQK23jURSxib6sdZNgl9NFQQPD6w1WhRJ8mgjOFB/WhfKcdMFD/daRX4LACe4lghP3hu5DSOg5qbnL/Qr4BUSHCCG4spNYX7Zw3EiIMZE93DJv6XucQ1dPGjqsLXWiKPprGsnqCXVE8j0sMiw== x-ms-exchange-transport-forked: True MIME-Version: 1.0 X-OriginatorOrg: mcafee.com X-MS-Exchange-CrossTenant-Network-Message-Id: 741729ae-b481-45fe-25d4-08d7bac30018 X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Feb 2020 13:51:37.8586 (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: q4jMfKd00fmqPyuL9DOq8sjX6TF4E0isLHdbq3l0Lxb5YDERqCCZeNncxQdpOgrzwBWmIGOBY+UnGpzuJD4OhzP9xCk+90eWhqy1bgI1MM3pSL/2PP/avriEsBwHPgZk X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR1601MB1143 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: mcafee.com Content-Type: multipart/alternative; boundary="_000_CY4PR1601MB1254378577E23916A1A7BD47EAEA0CY4PR1601MB1254_" Archived-At: Subject: Re: [Dots] prefix with namespace identifier in draft-ietf-dots-signal-filter-control 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, 26 Feb 2020 13:53:30 -0000 --_000_CY4PR1601MB1254378577E23916A1A7BD47EAEA0CY4PR1601MB1254_ Content-Type: text/plain; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable Let's assign key values for ietf-dots-signal-control:acl-list and ietf-dots= -signal-control:acl-name. Cheers, -Tiru From: mohamed.boucadair@orange.com Sent: Wednesday, February 26, 2020 6:24 PM To: Jon Shallow ; Konda, Tirumaleswar Reddy ; kaname nishizuka ; dots@= ietf.org Subject: RE: [Dots] prefix with namespace identifier in draft-ietf-dots-sig= nal-filter-control CAUTION: External email. Do not click links or open attachments unless you = recognize the sender and know the content is safe. ________________________________ Hi Jon, We can't do that because "mitigation-scope" is not defined in ietf-dots-sig= nal-control. FWIW, draft-ietf-core-yang-cbor says the following (which cons= istent with 7951) =3D=3D o namespace qualified - the identifier of the YANG item is prefixed with the name of the module in which this item is defined, separated by the colon character (":"). The name of a module determines the namespace of all YANG items defined in that module. If an item is defined in a submodule, then the namespace qualified name uses the name of the main module to which the submodule belongs. =3D=3D Cheers, Med De : Jon Shallow [mailto:supjps-ietf@jpshallow.com] Envoy=E9 : mercredi 26 f=E9vrier 2020 13:21 =C0 : BOUCADAIR Mohamed TGI/OLN; Konda, Tirumaleswar Reddy; kaname nishizuk= a; dots@ietf.org Objet : RE: [Dots] prefix with namespace identifier in draft-ietf-dots-sign= al-filter-control Hi all, Thinking out of the box, for Figure 8 we have "ietf-dots-signal-channel:mitigation-scope": { "scope": [ { "target-prefix": [ "2001:db8:6401::2/127" ], "target-protocol": [ 17 ], "ietf-dots-signal-control:acl-list": [ { "ietf-dots-signal-control:acl-name": "my-accept-list", "ietf-dots-signal-control:activation-type": "immediate" } "lifetime": 3600 } ] } } If this was to be replaced with "ietf-dots-signal-control:mitigation-scope": { "scope": [ { "target-prefix": [ "2001:db8:6401::2/127" ], "target-protocol": [ 17 ], " acl-list": [ { " acl-name": "my-accept-list", " activation-type": "immediate" } "lifetime": 3600 } ] } } As the module is ietf-dots-signal-control: which includes the augments - Wo= uld that not be valid (and a lot simpler)? So we only need a CBOR definition for ietf-dots-signal-channel:mitigation-s= cope and separately for ietf-dots-signal-control:mitigation-scope as well a= s the augmented new entries. Regards Jon From: Dots [mailto: dots-bounces@ietf.org] On= Behalf Of mohamed.boucadair@orange.com Sent: 24 February 2020 08:17 To: Jon Shallow; Konda, Tirumaleswar Reddy; kaname nishizuka; dots@ietf.org= Subject: [Dots] prefix with namespace identifier in draft-ietf-dots-signal-= filter-control Re-, The prefix use in draft-ietf-dots-signal-filter-control-02#section-5.1 is c= orrect given that acl-* attributes are not defined in the base YANG module = as being part of a mitigation request. We assumed that the same key value is used for both (e.g., acl-name and iet= f-dots-signal-control:acl-name). Given that we revisited that design in the= telemetry I-D, I'm afraid that we will need to assign key values for ietf-= dots-signal-control:acl-list and ietf-dots-signal-control:acl-name. Cheers, Med De : Jon Shallow [mailto:supjps-ietf@jpshallow.com] Envoy=E9 : vendredi 21 f=E9vrier 2020 16:46 =C0 : BOUCADAIR Mohamed TGI/OLN; Konda, Tirumaleswar Reddy; kaname nishizuk= a; dots@ietf.org Objet : RE: [Dots] DOTS telemetry questions Hi, See inline Jon1> Regards Jon Jon> We have the same naming issues in draft-ietf-dots-signal-filter-contr= ol-00 where we do not have the ietf-dots-signal-control: prefix in the JSON= examples (Fig 10) [Med] Fig 10 is a "normal" mitigation request. Why should it need to includ= e "ietf-dots-signal-control:" prefix? Jon1> My bad - I was looking at draft-ietf-dots-signal-filter-control-00, n= ot draft-ietf-dots-signal-filter-control-02. However, https://tools.ietf.o= rg/html/draft-ietf-dots-signal-filter-control-02#section-5.1 only defines "= activation-type" without the prefix, and acl-list and acl-name have the inc= orrect prefix: added to, for example, Figure 1. --_000_CY4PR1601MB1254378577E23916A1A7BD47EAEA0CY4PR1601MB1254_ Content-Type: text/html; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable

Let’s assign key values for ietf-dots-signal-c= ontrol:acl-list and ietf-dots-signal-control:acl-name.

 

Cheers,

-Tiru

 

From: mohamed.boucadair@orange.com <mohame= d.boucadair@orange.com>
Sent: Wednesday, February 26, 2020 6:24 PM
To: Jon Shallow <supjps-ietf@jpshallow.com>; Konda, Tirumalesw= ar Reddy <TirumaleswarReddy_Konda@McAfee.com>; kaname nishizuka <k= aname@nttv6.jp>; dots@ietf.org
Subject: RE: [Dots] prefix with namespace identifier in draft-ietf-d= ots-signal-filter-control

 

CAUTION: External email. Do not click links or open attachments unless you recognize the sender and know the content is safe.<= /span><= /span>

 

Hi Jon,

 

We can’t do that because “mitigation-scope” is not defined in ietf-d= ots-signal-control. FWIW, draft-ietf-core-yang-cbor says the following (which consistent with = 7951)

 

=3D=3D

   o  namespace qualified - the identifier = of the YANG item is prefixed

      with the name of the module= in which this item is defined,

      separated by the colon char= acter (":").

 

   The name of a module determines the namespace= of all YANG items

   defined in that module.  If an item is d= efined in a submodule, then

   the namespace qualified name uses the name of= the main module to

   which the submodule belongs.

 

=3D=3D

 

Cheers,

Med

 

De : Jon = Shallow [mailto:supjps-ietf@jp= shallow.com]
Envoy=E9 : mercredi 26 f=E9vrier 2020 13:21
=C0 : BOUCADAIR Mohamed TGI/OLN; Konda, Tirumaleswar Reddy; kan= ame nishizuka; dots@ietf.org
Objet : RE: [Dots] prefix with namespace identifier in draft-ie= tf-dots-signal-filter-control

 

Hi all,=

&n= bsp;

Thinkin= g out of the box, for Figure 8 we have

&n= bsp;

 &= nbsp;    "ietf-dots-signal-channel:mitigation-scope&quo= t;: {

 &= nbsp;      "scope": [<= /p>

 &= nbsp;        {

 &= nbsp;          "target-pr= efix": [

 &= nbsp;           &nbs= p; "2001:db8:6401::2/127"

 &= nbsp;           ],

 &= nbsp;           "tar= get-protocol": [

 &= nbsp;           &nbs= p; 17

 &= nbsp;           ],

 &= nbsp;           "iet= f-dots-signal-control:acl-list": [

 &= nbsp;           &nbs= p; {

 &= nbsp;           &nbs= p;   "ietf-dots-signal-control:acl-name": "my-acce= pt-list",

 &= nbsp;           &nbs= p;   "ietf-dots-signal-control:activation-type": "= immediate"

 &= nbsp;           &nbs= p; }

 &= nbsp;          "lifetime&= quot;: 3600

 &= nbsp;        }

 &= nbsp;      ]

 &= nbsp;    }

 &= nbsp;  }

&n= bsp;

If this= was to be replaced with

&n= bsp;

 &= nbsp;    "ietf-dots-signal-control:mitiga= tion-scope": {

 &= nbsp;      "scope": [<= /p>

 &= nbsp;        {

 &= nbsp;          "target-pr= efix": [

 &= nbsp;           &nbs= p; "2001:db8:6401::2/127"

 &= nbsp;           ],

 &= nbsp;           "tar= get-protocol": [

 &= nbsp;           &nbs= p; 17

 &= nbsp;           ],

 &= nbsp;           " ac= l-list": [

 &= nbsp;           &nbs= p; {

 &= nbsp;           &nbs= p;   " acl-name": "my-accept-list",

 &= nbsp;           &nbs= p;   " activation-type": "immediate"

 &= nbsp;           &nbs= p; }

 &= nbsp;          "lifetime&= quot;: 3600

 &= nbsp;        }

 &= nbsp;      ]

 &= nbsp;    }

 &= nbsp;  }

&n= bsp;

As the = module is ietf-dots-signal-control: which includes the augmen= ts - Would that not be valid (and a lot simpler)?

&n= bsp;

So we o= nly need a CBOR definition for ietf-dots-signal-channel:mitigation-scope an= d separately for ietf-dots-signal-control:mitigation-scope as well as the a= ugmented new entries.

&n= bsp;

Regards=

&n= bsp;

Jon

&n= bsp;

From: Dots [mailto: dots-bounces@ietf.org] On B= ehalf Of mohamed.boucadair@orang= e.com
Sent: 24 February 2020 08:17
To: Jon Shallow; Konda, Tirumaleswar Reddy; kaname nishizuka; dots@ietf.org
Subject: [Dots] prefix with namespace identifier in draft-ietf-dots-= signal-filter-control

 

Re-,

 

The prefix use in draft-ietf-dots-signal-filter-control-02#se= ction-5.1 is correct given that acl-* attributes are not defined in the bas= e YANG module as being part of a mitigation request.

 

We assumed that the same key value is used for both (e.g., ac= l-name and ietf-dots-signal-control:acl-name). Given that we revisited that= design in the telemetry I-D, I’m afraid that we will need to assign key values for ietf-dots-signal-control:acl-list an= d ietf-dots-signal-control:acl-name.

 

Cheers,

Med

 

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

 

Hi,

&n= bsp;

See inl= ine Jon1>

&n= bsp;

Regards=

&n= bsp;

Jon

&n= bsp;

 

Jon> We  have the same naming issues in draft-ietf-dots-s=
ignal-filter-control-00 where we do not have the [Med] Fig 10 is a ̶=
0;normal” mitigation request. Why should it need to include “ie=
tf-dots-signal-control:” prefix?
 

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

&n= bsp;

--_000_CY4PR1601MB1254378577E23916A1A7BD47EAEA0CY4PR1601MB1254_-- From nobody Wed Feb 26 05:54:16 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 DF3353A03F4 for ; Wed, 26 Feb 2020 05:54:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.088 X-Spam-Level: X-Spam-Status: No, score=-2.088 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, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, T_SPF_TEMPERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mcafee.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bs_ym1EKUzZo for ; Wed, 26 Feb 2020 05:54:05 -0800 (PST) Received: from us-smtp-delivery-140.mimecast.com (us-smtp-delivery-140.mimecast.com [63.128.21.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 997343A0121 for ; Wed, 26 Feb 2020 05:54:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mcafee.com; s=mimecast20190606; t=1582725244; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=3EqQJptpxInpxOlSml9DYdYT6HPC3YnJwqRoY3OzIxE=; b=TqUCX2kwe3b3CbFPcfJZ25dkQBxJhZfjDMPFoSVszAJ4zebqp03YHGES2OvWSqDVtyIfiF VrWbbsyWnI1XoPEGzzTi8w2WfaP7J/PGdIUzAn9fuQcc+7Mw9QTF4kSqw/FFs6c7fZ3eX7 9X61q9aCjK3SJcetSEZFnQfgJTM65io= Received: from NAM11-CO1-obe.outbound.protection.outlook.com (mail-co1nam11lp2177.outbound.protection.outlook.com [104.47.56.177]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-304-1rlhpQ_vOMaTtSH7XTGnEg-1; Wed, 26 Feb 2020 08:54:02 -0500 X-MC-Unique: 1rlhpQ_vOMaTtSH7XTGnEg-1 Received: from CY4PR1601MB1254.namprd16.prod.outlook.com (2603:10b6:903:d4::12) by CY4PR1601MB1143.namprd16.prod.outlook.com (2603:10b6:903:ce::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2750.21; Wed, 26 Feb 2020 13:54:00 +0000 Received: from CY4PR1601MB1254.namprd16.prod.outlook.com ([fe80::a48c:a975:ccfa:8d29]) by CY4PR1601MB1254.namprd16.prod.outlook.com ([fe80::a48c:a975:ccfa:8d29%4]) with mapi id 15.20.2772.012; Wed, 26 Feb 2020 13:54:00 +0000 From: "Konda, Tirumaleswar Reddy" To: "mohamed.boucadair@orange.com" , Jon Shallow , kaname nishizuka , "dots@ietf.org" Thread-Topic: 'mid' reference to ease requests correlation (RE: [Dots] DOTS telemetry questions) Thread-Index: AdXq81iV+oyJapQRTzyH8Y7ZzOpvqwAzxXpgADpfbQA= Date: Wed, 26 Feb 2020 13:54:00 +0000 Message-ID: References: <787AE7BB302AE849A7480A190F8B93303143E83E@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-version: 11.4.0.45 dlp-reaction: no-action x-originating-ip: [49.37.206.212] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 7d2727bd-e9af-4d20-9e60-08d7bac35537 x-ms-traffictypediagnostic: CY4PR1601MB1143: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0325F6C77B x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(136003)(396003)(346002)(39860400002)(376002)(366004)(32952001)(199004)(189003)(2906002)(26005)(81156014)(86362001)(81166006)(186003)(8936002)(53546011)(6506007)(110136005)(66476007)(966005)(478600001)(66946007)(8676002)(52536014)(66556008)(76116006)(33656002)(71200400001)(66446008)(316002)(64756008)(55016002)(9686003)(5660300002)(7696005)(85282002); DIR:OUT; SFP:1101; SCL:1; SRVR:CY4PR1601MB1143; H:CY4PR1601MB1254.namprd16.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: iP6RXy4fqdb9DfYylEmAai6x9SNVMNyq6vN3fpo0JxBdGX+X9wFWPqARTVkJQgUYfRsPWEpF3Wg0P8jXNvJzV4liL9PAuOrRKA5zwq2VjkiZO2xbTKQtsUkAQYqUHUkP2gpG78H2DdP+RPSsoKVOs2vC8isTV7vGf6xMmS06Dhnwf0Aeg+ppmqaKcFkrIOq1ExLhRPjQ+4X3LO4am4E5RWhEh1715IeI6fzBwbWghW17ehD8RKUq7TOP8+N9dPlgw0i86K6OunGycnG5r2+Q18llaN7SE7w9RTFC1q7FqGi3toXuPEG2x4mc+cGej7Q7f4LCn3OqCghfgEIOMpInMoyw2QIdScQv8QR/5PPC84WkOHSbHkTezmG7w906aXAw26b2NmoFgptADQgBxDDj3X6ebflM2MCiSOg2bg+9JoJIl3KPFH9ADXiZoPy27WCij0yDArIWOSIphj4DZg7iApGENRkxECvYd/joiNULDNIgFAhyyHSs6/n2pMYlyKTWLTj4vgCkOJ6Lhlv9uEefoVTs6a5iDEaApjdN21bmpKInpaNkrJjRs2Fmip8OukYzMViAeIouAIDd4DiFddLZI9COV1cEoSwg9DyEOnr4484= x-ms-exchange-antispam-messagedata: Gv6XH4MQUl9+mBAPLAYMtabkv1F1S/FqEHKCM8FcrZCjqR3IqTfqvtFQf4E6TnH7MJCvro6pxvdEAI2/3qRRGIxF2Z5c2gwHarStBjGFV9OxkSYhxFA0wDk42H2KTgGnIh8o9Jyg7btQ3qWhrMP+ow== x-ms-exchange-transport-forked: True MIME-Version: 1.0 X-OriginatorOrg: mcafee.com X-MS-Exchange-CrossTenant-Network-Message-Id: 7d2727bd-e9af-4d20-9e60-08d7bac35537 X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Feb 2020 13:54:00.6412 (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: tjP+1mI3rVkF6LmeHNeCyVo8LtcgnJq09021CXxc0RpgfxH2/+DId7MmGZalC2+SttrrG63cu3gOd+Kng0pL3qP3+Z7scKqiBTjCRUwdY0ckASq8hwXG8Ok1Q0/0NIP5 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR1601MB1143 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: mcafee.com Content-Type: multipart/alternative; boundary="_000_CY4PR1601MB12543534D4D0AA30B11DC3A5EAEA0CY4PR1601MB1254_" Archived-At: Subject: Re: [Dots] 'mid' reference to ease requests correlation (RE: DOTS telemetry questions) X-BeenThere: dots@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Feb 2020 13:54:15 -0000 --_000_CY4PR1601MB12543534D4D0AA30B11DC3A5EAEA0CY4PR1601MB1254_ Content-Type: text/plain; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable On second thought, the current design looks better (no increase to the size= of mitigation request and avoids fragmentation). Cheers, -Tiru From: Konda, Tirumaleswar Reddy Sent: Tuesday, February 25, 2020 3:38 PM To: mohamed.boucadair@orange.com; Jon Shallow ; = kaname nishizuka ; dots@ietf.org Subject: RE: 'mid' reference to ease requests correlation (RE: [Dots] DOTS = telemetry questions) DOTS can leverage https://tools.ietf.org/html/draft-ietf-core-comi-08#secti= on-6.1 to determine whether the telemetry attributes are supported by the D= OTS server or not. This will avoid rejection of mitigation request. Cheers, -Tiru From: mohamed.boucadair@orange.com > Sent: Monday, February 24, 2020 2:48 PM To: Jon Shallow >; Konda, Tirumaleswar Reddy >; kaname nishizuka >; dots@ietf.org Subject: 'mid' reference to ease requests correlation (RE: [Dots] DOTS tele= metry questions) CAUTION: External email. Do not click links or open attachments unless you = recognize the sender and know the content is safe. ________________________________ Hi all, No change so far. We need to assess this further. Cheers, Med 1) I am confused by "pre-mitigation" which can be transmitted pre any = mitigation taking place, or actually during when mitigation is taking place= (or so I think) and would simply be better described as "attack-details" -= especially with a statement such as DOTS agents MUST bind pre-mitigation telemetry data with mitigation requests relying upon the target clause. [Med] That's an option but the current design allows to have the telemetry = in // in order to supply more data ** without impacting the placement of a = mitigation request ** hence the need to bind both (if any). If telemetry at= tributes are defined as mandatory (discussed in another thread), this would= mean that the server will reject a mitigation that includes such attribute= s. With the current design, we have a functionality that can be safely enab= led independently of the decision that we will make about whether telemetry= attributes are mandatory to be supported or not. Jon> My primary point here was the use of the term "pre-mitigation" - this = telemetry is also needs during a mitigation and the attack keeps on morphin= g into something else. Another point we can check to ease correlation between a mitigation request= and pre-mitigation telemetry is to signal the "mid" in the telemetry messa= ge. Jon> could be - need to think this through Regards Jon --_000_CY4PR1601MB12543534D4D0AA30B11DC3A5EAEA0CY4PR1601MB1254_ Content-Type: text/html; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable

On second thought, the current design looks better (= no increase to the size of mitigation request and avoids fragmentation).

 

Cheers,

-Tiru

 

From: Konda, Tirumaleswar Reddy
Sent: Tuesday, February 25, 2020 3:38 PM
To: mohamed.boucadair@orange.com; Jon Shallow <supjps-ietf@jpshal= low.com>; kaname nishizuka <kaname@nttv6.jp>; dots@ietf.org
Subject: RE: 'mid' reference to ease requests correlation (RE: [Dots= ] DOTS telemetry questions)

 

DOTS can leverage https://tools.ietf.org/html/draft-ietf-core-comi-08#section-6.1 to dete= rmine whether the telemetry attributes are supported by the DOTS server or = not. This will avoid rejection of mitigation request.

 

Cheers,

-Tiru

 

From: mohamed.boucadair@orange.com <mohamed.boucadair@orange.com>
Sent: Monday, February 24, 2020 2:48 PM
To: Jon Shallow <sup= jps-ietf@jpshallow.com>; Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@McAfee.com= >; kaname nishizuka <kaname@nt= tv6.jp>; dots@ietf.org
Subject: 'mid' reference to ease requests correlation (RE: [Dots] DO= TS telemetry questions)

 

CAUTION: External email. Do not click links or open attachments unless you recognize the sender and know the content is safe.<= /span><= /span>

 

Hi all,

 

No change so far. We need to assess this further.

 

Cheers,

Med

 

 = 

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

 = 

   DOTS age=
nts MUST bind pre-mitigation telemetry data with mitigation
   requests=
 relying upon the target clause.
 
[Med] That’s an option but the current design allows=
 to have the telemetry in // in order to supply more data ** without impact=
ing the placement of a mitigation request ** hence the need to bind both (i=
f any). If telemetry attributes are defined as mandatory (discussed in anot=
her thread), this would mean that the server will reject a mitigation that =
includes such attributes. With the current design, we have a functionality =
that can be safely enabled independently of the decision that we will make =
about whether telemetry attributes are mandatory to be supported or not.
Jon> My primary point =
here was the use of the term “pre-mitigation” – this tele=
metry is also needs during a mitigation and the attack keeps on morphing in=
to something else.
 
Another point we can check to ease correlation between a m=
itigation request and pre-mitigation telemetry is to signal the “mid&=
#8221; in the telemetry message.
Jon> could be – need to think this through
 
Regards
 
Jon=
--_000_CY4PR1601MB12543534D4D0AA30B11DC3A5EAEA0CY4PR1601MB1254_--