Re: [Dots] Éric Vyncke's No Objection on draft-ietf-dots-signal-call-home-11: (with COMMENT)

mohamed.boucadair@orange.com Mon, 14 December 2020 14:12 UTC

Return-Path: <mohamed.boucadair@orange.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 694EC3A0D9B; Mon, 14 Dec 2020 06:12:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.195
X-Spam-Level:
X-Spam-Status: No, score=-0.195 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=orange.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eTdukF-HgbNS; Mon, 14 Dec 2020 06:12:45 -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 79A683A0D94; Mon, 14 Dec 2020 06:12:45 -0800 (PST)
Received: from opfedar02.francetelecom.fr (unknown [xx.xx.xx.4]) by opfedar25.francetelecom.fr (ESMTP service) with ESMTP id 4Cvjyh1Yx3z8sxK; Mon, 14 Dec 2020 15:12:44 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1607955164; bh=poDmQgKMyX6hjjMx453TF23/phvXt65BquxE8LYIVSM=; h=From:To:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=TIdyvcCmvhX/ACKEK+vpVTrDRKtmcLWm8Txchdd16MUX6rLXWlApT4mjXphfa3foc 2d5Y1DOQ2KsUHSMf+eSgg8PhcXRMuh0Rthb6mu9ZsNj3Lk9M3O6GDsY6lEpng98VH8 IcuR0Vg68Tn1u1WOfg8R8lJv2DOlzsOFVEdPuovmI7I8MvM9kHOhcxcnrPFv01YJyR coRBdwIcyGh7awJ9a4E98ZOy6OEk8hpZB1gSMyTpsjx7YE3/V48Z+HmX0lE9r4xc59 t0oXvzwMOKDrTqJd33GKBCbLcLrPxKOkPPt4jsZxBa1lLQGJPFmoN3uW9eGUmD599r Wnl+DKJf/pmBw==
Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.82]) by opfedar02.francetelecom.fr (ESMTP service) with ESMTP id 4Cvjyg4c0DzCqkg; Mon, 14 Dec 2020 15:12:43 +0100 (CET)
From: <mohamed.boucadair@orange.com>
To: =?utf-8?B?w4lyaWMgVnluY2tl?= <evyncke@cisco.com>, The IESG <iesg@ietf.org>
CC: "draft-ietf-dots-signal-call-home@ietf.org" <draft-ietf-dots-signal-call-home@ietf.org>, "dots-chairs@ietf.org" <dots-chairs@ietf.org>, "dots@ietf.org" <dots@ietf.org>, Valery Smyslov <valery@smyslov.net>
Thread-Topic: =?utf-8?B?w4lyaWMgVnluY2tlJ3MgTm8gT2JqZWN0aW9uIG9uIGRyYWZ0LWlldGYtZG90?= =?utf-8?Q?s-signal-call-home-11:_(with_COMMENT)?=
Thread-Index: AQHW0gb2F2CsS7KuKEauwPnuMJJUj6n2lc/Q
Date: Mon, 14 Dec 2020 14:11:21 +0000
Message-ID: <18281_1607955163_5FD772DB_18281_56_1_787AE7BB302AE849A7480A190F8B93303159CF56@OPEXCAUBMA2.corporate.adroot.infra.ftgroup>
References: <160794244713.23722.10716414184806475697@ietfa.amsl.com>
In-Reply-To: <160794244713.23722.10716414184806475697@ietfa.amsl.com>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.114.13.247]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/dots/XNn8T5CJzqZo8VP3TxQhvXt1MWM>
Subject: Re: [Dots] =?utf-8?q?=C3=89ric_Vyncke=27s_No_Objection_on_draft-ietf?= =?utf-8?q?-dots-signal-call-home-11=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." <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: Mon, 14 Dec 2020 14:12:47 -0000

Re-bonjour Eric, 

Thank you for the review. 

Please see inline.

Cheers,
Med

> -----Message d'origine-----
> De : Éric Vyncke via Datatracker [mailto:noreply@ietf.org]
> Envoyé : lundi 14 décembre 2020 11:41
> À : The IESG <iesg@ietf.org>
> Cc : draft-ietf-dots-signal-call-home@ietf.org; dots-
> chairs@ietf.org; dots@ietf.org; Valery Smyslov <valery@smyslov.net>et>;
> valery@smyslov.net
> Objet : Éric Vyncke's No Objection on draft-ietf-dots-signal-call-
> home-11: (with COMMENT)
> 
> Éric Vyncke has entered the following ballot position for
> draft-ietf-dots-signal-call-home-11: 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-signal-call-home/
> 
> 
> 
> --------------------------------------------------------------------
> --
> COMMENT:
> --------------------------------------------------------------------
> --
> 
> Thank you for the work put into this document. Congratulations for
> the many nice ASCII artworks ;-) Using the SVG alternate artwork
> could have even been nicer ;-)
> 
> Please find below  some non-blocking COMMENT points (but replies
> would be appreciated), and some nits.
> 
> I will let the transport AD to decide on the IANA point.

[Med] FWIW, the rationale for the request can be found at: https://mailarchive.ietf.org/arch/msg/dots/GQP-QCmC-4XtJHPmsPR_quuyO0c/ 

> 
> I hope that this helps to improve the document,
> 
> Regards,
> 
> -éric
> 
> == COMMENTS ==
> -- Abstract --
> I wonder whether the 2nd paragraph is really useful.

[Med] We added that text to address a comment we received in the past: the "call home" was misinterpreted as if this is specific to home networks. I suggest to maintain this sentence. Thanks.

> 
> -- Section 1.1 --
> Should the DOTS acronym be expanded before first use ?

[Med] Done. Please see https://tinyurl.com/dots-call-home-latest 

> 
> Please add a reference to "Slowloris"

[Med] Sure. Please see the diff.   

> 
> Did the authors/WG consider mentioning MUD in this lengthy
> discussion about IoT @ Home ?

[Med] We do cite RFC8576, which discusses MUD. Not sure there is a value in citing it here.   

> 
> -- Section 5.2.1 --
> "When an outgoing attack that saturates the outgoing link", but,
> what about an "incoming attack" ?

[Med] That one is covered by the following two paragraphs. The fact that the loss is due to an incoming attack is not used for session management purposes. The DOTS Call Home Server does not have the visibility on the incoming attacks (see the reference architecture); that is visible to a DOTS client (base signal channel), if any. 

> 
> -- Section 5.2.2 --
> Thank you for using an IPv6-only example !
> 
> -- Section 5.3.1 --
> Can source-prefix be a link-local address (normally not forwarded by
> a router but what if the CPE is a layer-2 node) ?

[Med] Private (for IPv4), link-local, or ULAs are not forbidden. Only loopback, broadcast, and multicast addresses are not allowed.

> 
> In figure 9, while "2001:db8:123::/128" is a valid node address but
> it looks like a prefix, may I suggest to use "2001:db8:123::1/128"
> that better suggest a host address ?

[Med] No problem. See the diff. 

> 
> -- Section 5.3.2 --
> Congratulations to the authors for describing the NAT64/MAP
> behaviors.
> 
> -- Section 8 --
> "The DOTS Call Home can be misused " should probably include
> "server".
> 

[Med] As you can see in the diff, changed to "The DOTS Call Home signal channel can be misused".

> -- Section 9 --
> How is the privacy among DOTS servers enforced ? E.g., how can the
> DOTS client only send mitigation information about subscriber A
> prefix(es) and not subscriber B prefix(es)? There could obviously be
> a link to RADIUS and DHCP servers but I did not read anything about
> this. Or is 'common sense' / implicit ?

[Med] We focus on the external behavior: 

      the Call Home DOTS client MUST validate that attacker
      prefixes are within the scope of the Call Home DOTS server domain
      (e.g., prefixes assigned to the Call Home DOTS server domain or
      networks it services).

How this is enforced is deployment-specific. 

Do you prefer to see DHCP/RADIUS cited? 

> 
> == NITS ==
> 
> s/Figure 10 depictes/Figure 10 depicts/

[Med] Fixed. Thanks.


_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.