Re: [Dots] draft-ietf-dots-discovery: Valery's Comment in Montreal

<mohamed.boucadair@orange.com> Fri, 02 August 2019 11:53 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 974F91200A3 for <dots@ietfa.amsl.com>; Fri, 2 Aug 2019 04:53:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level:
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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
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 2N8mDqIs8xYk for <dots@ietfa.amsl.com>; Fri, 2 Aug 2019 04:53:24 -0700 (PDT)
Received: from relais-inet.orange.com (relais-inet.orange.com [80.12.66.41]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 774BE120033 for <dots@ietf.org>; Fri, 2 Aug 2019 04:53:24 -0700 (PDT)
Received: from opfedar04.francetelecom.fr (unknown [xx.xx.xx.6]) by opfedar26.francetelecom.fr (ESMTP service) with ESMTP id 460QXf56MczFqN1; Fri, 2 Aug 2019 13:53:22 +0200 (CEST)
Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.48]) by opfedar04.francetelecom.fr (ESMTP service) with ESMTP id 460QXf49Yxz1xpT; Fri, 2 Aug 2019 13:53:22 +0200 (CEST)
Received: from OPEXCAUBMA2.corporate.adroot.infra.ftgroup ([fe80::e878:bd0:c89e:5b42]) by OPEXCAUBM32.corporate.adroot.infra.ftgroup ([fe80::81c9:5f:b9c5:1241%21]) with mapi id 14.03.0468.000; Fri, 2 Aug 2019 13:53:22 +0200
From: <mohamed.boucadair@orange.com>
To: Valery Smyslov <valery@smyslov.net>
CC: "dots@ietf.org" <dots@ietf.org>
Thread-Topic: draft-ietf-dots-discovery: Valery's Comment in Montreal
Thread-Index: AdVHd+/qBP9FDa59QJaUSl01dbIpugBh0NGAAAlBWNA=
Date: Fri, 2 Aug 2019 11:53:21 +0000
Message-ID: <787AE7BB302AE849A7480A190F8B9330312FBBDE@OPEXCAUBMA2.corporate.adroot.infra.ftgroup>
References: <787AE7BB302AE849A7480A190F8B9330312EB910@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <019301d5490f$f8a57df0$e9f079d0$@smyslov.net>
In-Reply-To: <019301d5490f$f8a57df0$e9f079d0$@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.247]
Content-Type: multipart/alternative; boundary="_000_787AE7BB302AE849A7480A190F8B9330312FBBDEOPEXCAUBMA2corp_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/dots/3scgBsWMrqDF2LBRUgRTNjU3KvY>
Subject: Re: [Dots] draft-ietf-dots-discovery: Valery's Comment in Montreal
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, 02 Aug 2019 11:53:29 -0000

Hi Valery,

Please see in line.

Cheers,
Med

De : Valery Smyslov [mailto:valery@smyslov.net]
Envoyé : vendredi 2 août 2019 10:55
À : BOUCADAIR Mohamed TGI/OLN
Cc : dots@ietf.org
Objet : RE: draft-ietf-dots-discovery: Valery's Comment in Montreal

Hi Med,

Hi Valery,

You said during the meeting that you are not "happy" with the language used in section 4 (if I'm not mistaken). Are you referring to this text:

   All DOTS clients MUST support at least one of the three mechanisms
   below to determine a DOTS server list.  All DOTS clients SHOULD
   implement all three, or as many as are practical for any specific
   device, of these ways to discover DOTS servers, in order to
   facilitate the deployment of DOTS in large scale environments:

Can you please clarify your concern?

yes, I meant this very text, but it was just an example of my concerns.
in general, I found using normative language in the document
a bit chaotic and I think that sometimes it is used improperly. Note, that
the main purpose of using normative keywords is to help interoperability.

[Med] That's fair. Let's identify those and fix them.

More concretely.

   All DOTS clients MUST support at least one of the three mechanisms
   below to determine a DOTS server list.  All DOTS clients SHOULD
   implement all three, or as many as are practical for any specific
   device, of these ways to discover DOTS servers, in order to
   facilitate the deployment of DOTS in large scale environments:

Why normative language is ever used here? Obviously, clients
must somehow know server's address to establish a connection,
but is it essential for interoperability between DOTS implementations
how they got it?

[Med] It is for interoperability. Consider the example of a server provider which went with, e.g., provisioning S-NAPTR records while the client does only support DHCP options to discover a server. This client will never discover the IP address of its server.

I don't think so. Even if you persuade me that
it is essential, I still think that the language is used here
improperly, since SHOULD is almost equal to MUST and
you doesn't provide any excuses for not doing MUST.

[Med] We cannot go for a MUST because of the discussion in Section 3. For example, if we take into account how services are provisioned today to CPE, it does not make sense to mandate DNS-SD to be supported by a CPE.

If you use SHOULD, please describe when it's OK not to follow it.

[Med] Do you think text is still needed given the clarification above?

But I still think that normative language is not needed here.

Another point. I'd rather recommend always provide a means
for local/manual configuration, as it us the easiest and most reliable way
to configure server's address.

[Med] That's fine for some deployments but manual configuration is not helpful for large scale deployment.

All other mechanisms may fail if attack
is already in progress when the client is being configured...

[Med] Manual configuration will also fail if the client does not have the "explicit" address to provide or if it has a name which will need to be resolved first.

   On hosts with more than one interface or address family (IPv4/v6),
   the DOTS server discovery procedure has to be performed for each
   combination of interface and address family.  A client MAY choose to
   perform the discovery procedure only for a desired interface/address
   combination if the client does not wish to discover a DOTS server for
   all combinations of interface and address family.

The same question - why MAY is used here instead of "may"?
[Med] What is the issue with the use of "MAY" here?

   The above procedure MUST also be followed by a DOTS gateway.
   Likewise, this procedure MUST be followed by a DOTS server in the
   context of DOTS Signal Channel Call Home
   [I-D.ietf-dots-signal-call-home].

    The discovery method MUST be reiterated upon the following events:

The same question for MUST.
[Med] If this is not followed, the DOTS client may maintain a stale DOTS server...which is problematic.


   1.  A DNS domain name is retrieved for each combination of interface
       and address family.  A DOTS client has to determine the domain in
       which it is located relying on dynamic means such as DHCP
       (Section 5) . Implementations MAY allow the user to specify a
       default name that is used, if no specific name has been
       configured.

The same question about normative language - why MAY instead of "may"?
[Med] Agree this one can be changed to "may" as this is about a configuration knob.

And apart from using normative language: doesn't the text

   If the DHCP client receives more than one instance of
   OPTION_V6_DOTS_RI (or OPTION_V6_DOTS_ADDRESS) option, it MUST use
   only the first instance of that option.

contradicts to the previous one

   To return more than one DOTS agents to the requesting DHCPv6 client,
   the DHCPv6 server returns multiple instances of
   OPTION_V6_DOTS_ADDRESS.

In other words, why to return several instances if only the first is always used?
Am I missing something?

[Med] Good catch. Will be fixed. Thanks.

Regards,
Valery.




Thank you.

Cheers,
Med