Re: [Ntp] Éric Vyncke's No Objection on draft-ietf-ntp-port-randomization-06: (with COMMENT)

Fernando Gont <fernando@gont.com.ar> Wed, 02 June 2021 18:45 UTC

Return-Path: <fernando@gont.com.ar>
X-Original-To: ntp@ietfa.amsl.com
Delivered-To: ntp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A837D3A168F; Wed, 2 Jun 2021 11:45:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.851
X-Spam-Level:
X-Spam-Status: No, score=-0.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_PAST_12_24=1.049, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 TH3-97HDiKeU; Wed, 2 Jun 2021 11:45:44 -0700 (PDT)
Received: from fgont.go6lab.si (fgont.go6lab.si [91.239.96.14]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E4B533A1693; Wed, 2 Jun 2021 11:45:43 -0700 (PDT)
Received: from [10.0.0.133] (unknown [186.19.8.47]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id 2A94F2800DD; Wed, 2 Jun 2021 18:45:38 +0000 (UTC)
To: Éric Vyncke <evyncke@cisco.com>, The IESG <iesg@ietf.org>
Cc: draft-ietf-ntp-port-randomization@ietf.org, ntp-chairs@ietf.org, ntp@ietf.org, odonoghue@isoc.org
References: <162244828999.14013.2000840672019389758@ietfa.amsl.com>
From: Fernando Gont <fernando@gont.com.ar>
Message-ID: <c314d56a-8f92-632e-fa3c-4a35d1624271@gont.com.ar>
Date: Wed, 02 Jun 2021 02:41:12 -0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1
MIME-Version: 1.0
In-Reply-To: <162244828999.14013.2000840672019389758@ietfa.amsl.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/ntp/SNWi-7dh-RbjiWLZjZxF62FFo58>
Subject: Re: [Ntp] Éric Vyncke's No Objection on draft-ietf-ntp-port-randomization-06: (with COMMENT)
X-BeenThere: ntp@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <ntp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ntp>, <mailto:ntp-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ntp/>
List-Post: <mailto:ntp@ietf.org>
List-Help: <mailto:ntp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ntp>, <mailto:ntp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 02 Jun 2021 18:45:49 -0000

Hi, Eric,

Thanks a lot for your feedback! In-line....

On 31/5/21 05:04, Éric Vyncke via Datatracker wrote:

> == COMMENTS ==
> 
> -- Section 3.4 -- A reference for "Some NAT devices" would be welcome
> even if this behavior is to be expected.

Will try to find one.



> The last § is convoluted and requires several read to understand it, 
> paraphrasing would be good even if I have no suggestion.

Changed to:

     In the case of NAT devices that will translate the source port even
     when a privileged port is employed, packets reaching the external
     realm of the NAT will not employ the NTP well-known port as the
     source port, as a result of the port translation function performed
     by the NAT device.



> -- Section 4 -- I wonder the added value of "The value in this
> variable becomes the source port number of packets sent from this
> association." Especially as 'variable' is not bound in the text to
> any value (OK we can guess that it is dstport).

Not sure I follow. Could you elaborate?



> Some rationale for "The randomized port number SHOULD NOT be shared
> with other associations."

How about:

The randomized port number SHOULD NOT be shared with other associations,
to avoid revealing the randomized port to other associations.

?


> would be welcome. Also, is it OK to share this port number with other
> applications ?

This would be a different case: i.e., it's not that you'd be
systematically leaking the randomized port to other peer processes, as
in the case above.



> -- Section 5 -- Interesting to read that many existing
> implementations have always implemented this specification

Glad this Section was of use ;-)



> == NITS ==
> 
> Please address all nits detected by: 
> https://www6.ietf.org/tools/idnits?url=https://www.ietf.org/archive/id/draft-ietf-ntp-port-randomization-06.txt

Is this:
   -- The document seems to lack a disclaimer for pre-RFC5378 work, but
      may have content which was first submitted before 10 November 2008.
      If you have contacted all the original authors and they are all
      willing to grant the BCP78 rights to the IETF Trust, then this is
      fine, and you can ignore this comment.  If not, you may need to add
      the pre-RFC5378 disclaimer.
      (See the Legal Provisions document at
      https://trustee.ietf.org/license-info for more information.)

a false positive?

Thanks!

Regards,
-- 
Fernando Gont
e-mail: fernando@gont.com.ar || fgont@si6networks.com
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1