Re: [Dots] DOTS telemetry questions
"Jon Shallow" <supjps-ietf@jpshallow.com> Fri, 21 February 2020 11:18 UTC
Return-Path: <supjps-ietf@jpshallow.com>
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 <dots@ietfa.amsl.com>; 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 <dots@ietfa.amsl.com>; 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 <dots@ietf.org>; 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 <jon.shallow@jpshallow.com>) id 1j56Jm-0000e8-Un; Fri, 21 Feb 2020 11:18:03 +0000
From: Jon Shallow <supjps-ietf@jpshallow.com>
To: mohamed.boucadair@orange.com, "Konda, Tirumaleswar Reddy" <TirumaleswarReddy_Konda@mcafee.com>, kaname nishizuka <kaname@nttv6.jp>, dots@ietf.org
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: <https://mailarchive.ietf.org/arch/msg/dots/9K2pS6AZzAUclZ_HPuwAKWme9sA>
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." <dots.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dots>, <mailto:dots-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dots/>
List-Post: <mailto:dots@ietf.org>
List-Help: <mailto:dots-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dots>, <mailto:dots-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 21 Feb 2020 11:18:14 -0000
Hi Med et al, See inline Jon> Regards Jon From: Dots [mailto: dots-bounces@ietf.org] On Behalf Of mohamed.boucadair@orange.com Sent: 21 February 2020 07:00 To: Jon Shallow; Konda, Tirumaleswar Reddy; kaname nishizuka Cc: dots@ietf.org Subject: Re: [Dots] DOTS telemetry questions Hi Jon, (ccing the WG to track the changes). Please see inline. Cheers, Med De : Jon Shallow [mailto:supjps-ietf@jpshallow.com] Envoyé : jeudi 20 février 2020 21:58 À : BOUCADAIR Mohamed TGI/OLN; Konda, Tirumaleswar Reddy; kaname nishizuka Objet : DOTS telemetry questions Hi Guys, 1) For example CBOR mappings Header: PUT (Code=0.03) Uri-Path: ".well-known" Uri-Path: "dots" Uri-Path: "mitigate" Uri-Path: "cuid=dz6pHjaADkaFTbjr0JGBpw" Uri-Path: "mid=123" If-Match: Content-Format: "application/dots+cbor" { "ietf-dots-signal-channel:mitigation-scope": { "scope": [ { "alias-name": [ "myserver" ], "attack-status": "under-attack", "ietf-dots-telemetry:total-attack-traffic": [ { "ietf-dots-telemetry:unit": "megabytes-ps", "ietf-dots-telemetry:mid-percentile-g": "900" } ] } ] } } Figure 33: An Example of Mitigation Efficacy Update with Telemetry Attributes And yet the mapping table only has (no ietf-dots-telemetry: prefix) | total-attack-traffic | list |32794 | 4 array | Array | I appreciate that ietf-dots-telemetry:total-attack-traffic and total-attack traffic are the same CBOR value (or are they?) [Med] The same value is used but I didnt 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. 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) Please note that we have this note is section 10: == o Some of these attributes should be prepended with "ietf-dots- telemetry:" == but when mapping the CBOR back to JSON the variant of JSON parameter is context (Uri-Path: mitigate or tm) dependent. 2) why do we not have a enum megabit-ps in typedef unit in the YANG Module? [Med] This can be added to the list as units() are negotiated. *-bytes are more used for aggregates, but lets 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. 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] Thats 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
- Re: [Dots] DOTS telemetry questions mohamed.boucadair
- Re: [Dots] DOTS telemetry questions Jon Shallow
- Re: [Dots] DOTS telemetry questions mohamed.boucadair
- Re: [Dots] DOTS telemetry questions Jon Shallow
- Re: [Dots] DOTS telemetry questions kaname nishizuka
- Re: [Dots] DOTS telemetry questions mohamed.boucadair