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

"Valery Smyslov" <valery@smyslov.net> Fri, 02 August 2019 12:30 UTC

Return-Path: <valery@smyslov.net>
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 455C612003F for <dots@ietfa.amsl.com>; Fri, 2 Aug 2019 05:30:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.499
X-Spam-Level:
X-Spam-Status: No, score=-0.499 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_NONE=-0.0001, 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 fWmb9NZxRz5n for <dots@ietfa.amsl.com>; Fri, 2 Aug 2019 05:30:55 -0700 (PDT)
Received: from direct.host-care.com (direct.host-care.com [198.136.54.115]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E615F120033 for <dots@ietf.org>; Fri, 2 Aug 2019 05:30:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=smyslov.net ; s=default; h=Content-Type:MIME-Version:Message-ID:Date:Subject:In-Reply-To: References:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=/++kiNyy4683xH2wMRtGVwsagOr/XxEBEdD1eDLZ2dc=; b=PrGUxqZHxXRJN5Sw07le1mMsBP lQvN/po4oCoeUOLkf7WqoJfV6hKtXi/kjjUiCK1RVgPpU6kvR412MGtWJcA0FDAVUAgHV+R8wJT6f VyAZn7eJtvAjoso42ZDg1vtHElJCtzfLG6MoADiNStj4o16QDugu4DK7Z8pmcs49n2yht4ohpAmfn 6a+Np3hTnO3vgDDk9aE2CIQSuzrpYwuQYxqn61+Uiq6jtIRlb75dnt9qRggJ5CWdf5IGkDvDVDBHG bQYghDMGaN9KjJMzkxidjXpQMAgbavUMLduPYgkcUZbFIqrm36XxGaWrPGb1Kbdq5SgkeUCyw4wI7 yMTVdZuA==;
Received: from [82.138.51.4] (port=59377 helo=buildpc) by direct.host-care.com with esmtpsa (TLSv1:ECDHE-RSA-AES256-SHA:256) (Exim 4.92) (envelope-from <valery@smyslov.net>) id 1htWhw-0005fS-2k; Fri, 02 Aug 2019 08:30:52 -0400
From: "Valery Smyslov" <valery@smyslov.net>
To: <mohamed.boucadair@orange.com>
Cc: <dots@ietf.org>
References: <787AE7BB302AE849A7480A190F8B9330312EB910@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <019301d5490f$f8a57df0$e9f079d0$@smyslov.net> <787AE7BB302AE849A7480A190F8B9330312FBBDE@OPEXCAUBMA2.corporate.adroot.infra.ftgroup>
In-Reply-To: <787AE7BB302AE849A7480A190F8B9330312FBBDE@OPEXCAUBMA2.corporate.adroot.infra.ftgroup>
Date: Fri, 2 Aug 2019 15:30:44 +0300
Message-ID: <01ad01d5492e$1c2e5760$548b0620$@smyslov.net>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_01AE_01D54947.4181A9E0"
X-Mailer: Microsoft Outlook 14.0
Content-Language: ru
Thread-Index: AQLgkaoOo1Vlc6htpCqkNtP2imU+ogLuPNxFAYscRLSkrWcIEA==
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: <https://mailarchive.ietf.org/arch/msg/dots/NwGurjEyz2K_1mR_8xQlBH3_ZQ8>
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 12:30:57 -0000

Hi Med,

 

Hi Valery, 

 

Please see in line. 

 

Cheers,

Med

 

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. 

 

         OK, but you don't impose any requirement on how DOTS servers provision addresses, 

         so either clients must support all the methods or you still have

         the abovementioned situation to happen.

 

         And in this case manual configuration can help. Another reason to make it mandatory, no?

 

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.   

 

         Well, then can you be more concrete and clarify when it's OK for clients not to support all three methods.

         Without concrete excuses SHOULD is almost equal to MUST.

 

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? 

 

         Yes. The phrase "as are practical for any specific device" is too vague.

         Provide at least a couple examples.

 

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. 

 

         Sure. But from my understanding of DOTS use cases usually one company will 

         have few dots clients (unless it's a multinational corporation) and will

         be serviced by one (or few) ISP providing DOTS service.

         Not a big deal for IT department to configure them.

 

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. 

 

         Yes. But at least it can be used to directly configure server address, without any network activity.

 

   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?   

 

     I don't see a need for MAY here. "If the client doesn't wish..."

     is clearly a local policy decision, so why uppercase MAY?

         

   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. 

 

         I think that lowercase must is OK here, since what you're actually saying 

         is that other kinds of DOTS clients (in fact client side of gateway

         and call home server) need to follow the case logic for discovering their

         respected servers.

 

         Regards,

         Valery.

 

 

 

Thank you. 

 

Cheers,

Med