Re: [Ntp] Benjamin Kaduk's Yes on draft-ietf-ntp-port-randomization-06: (with COMMENT)

Benjamin Kaduk <kaduk@mit.edu> Thu, 03 June 2021 23:18 UTC

Return-Path: <kaduk@mit.edu>
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 837D63A1E7B; Thu, 3 Jun 2021 16:18:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.894
X-Spam-Level:
X-Spam-Status: No, score=-1.894 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_NONE=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 JubgZDBILSCw; Thu, 3 Jun 2021 16:18:03 -0700 (PDT)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (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 CA27D3A1E7A; Thu, 3 Jun 2021 16:18:02 -0700 (PDT)
Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 153NHnK2025176 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 3 Jun 2021 19:17:55 -0400
Date: Thu, 3 Jun 2021 16:17:49 -0700
From: Benjamin Kaduk <kaduk@mit.edu>
To: Fernando Gont <fernando@gont.com.ar>
Cc: The IESG <iesg@ietf.org>, draft-ietf-ntp-port-randomization@ietf.org, ntp-chairs@ietf.org, ntp@ietf.org, odonoghue@isoc.org, fernando.gont@edgeuno.com
Message-ID: <20210603231749.GP32395@kduck.mit.edu>
References: <162259349040.28011.12868490801222617531@ietfa.amsl.com> <b9ad367c-3415-4156-9557-711db5279915@gont.com.ar>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <b9ad367c-3415-4156-9557-711db5279915@gont.com.ar>
Archived-At: <https://mailarchive.ietf.org/arch/msg/ntp/ZwChHu1KU6-ubzAuWowJ0MDIRcM>
Subject: Re: [Ntp] Benjamin Kaduk's Yes 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: Thu, 03 Jun 2021 23:18:09 -0000

Hi Fernando!

On Wed, Jun 02, 2021 at 03:40:03AM -0300, Fernando Gont wrote:
> Hi, Ben,
> 
> Thanks a lot for your feedback!  In-line....
> 
> On 1/6/21 21:24, Benjamin Kaduk via Datatracker wrote:
> [....]
> > There's a few places where we say things like "the choice of whether to
> > randomize the ephemeral port number on a per-request or a
> > per-association basis is left to the implementation, and should consider
> > the possible effects on path selection along with its possible impact on
> > time measurement."  But the main specific consideration that we mention
> > is that in ECMP and similar situations, randomizing per-request can
> > cause problems; in particular, I don't remember seeing anything that
> > would be an argument in favor of randomizing on a per-request basis.  So
> > the current guidance (entirely up to the implementation) doesn't seem to
> > match up very well with what we say about the two choices.  I think I'm
> > missing (in the text, that is) some aspect about how randomizing the
> > port on a per-request basis provides more robust defence against
> > off-path attacks than only randomizing per-association.
> 
> How about:
> 
> Randomizing the ephemeral port number on a per-request basis will better 
> mitigate off-path/blind attacks, particularly if the socket/port is 
> closed after each request/response exchange, as recommended above. The 
> choice of whether to randomize the ephemeral port number on a 
> per-request or a per-association basis is left to the implementation, 
> and should consider the possible effects on path selection along with 
> its possible impact on time measurement.
> ?

Thanks, that puts some picture of both the "pro" and "con" sides into the
reader's mind.

> 
> > 
> > Section 3.3
> > 
> >     inspecting the source and destination port numbers.  Implementation
> >     of port randomization for non-symmetrical modes allows for simple
> >     differentiation of NTP requests and responses, and for the
> >     enforcement of security policies that may be valuable for the
> >     mitigation of DDoS attacks, when all NTP clients in a given network
> >     employ port randomization.
> > 
> > I guess the details of what those security policies might look like are
> > properly out of scope for this document ... but the potential
> > consequences of such policies on clients that don't employ port
> > randomization might be in scope for us.
> 
> The issue here is that it won be possible to easily tell request and 
> responses. SO if you meant to filter requests, then youĺl have to filter 
> both requests and responses, or nothing at all.

Makes sense.  I leave it to you as to whether it merits a mention in the
document.

The rest all looks good, and thanks for it,

Ben

> 
> 
> > Section 4
> > 
> > Just an observation (no need to change anything), but we seem to be
> > going from three lines of content in the original to 30 lines of content
> > in the new version.  If it was actually applied and viewed in context in
> > the manner of inline errata, the new text might feel a bit out of place.
> 
> FWIW, Section 4 clarifies which text from RFC5095 should be interpreted 
> differently. However, I don't think this text should be rendered with 
> inline errata, as that would miss most of the background/implications 
> that e.g. is expected to influence the decision on whether to randomize 
> on a per-request or per-association basis.
> 
> 
> 
> > NITS
> > 
> > Abstract
> > 
> >     number.  However, in the case of NTP modes where the use of a well-
> >     known port is not required, employing such well-known port
> >     unnecessarily increases the ability of attackers to perform blind/
> >     off-path attacks.  This document formally updates RFC5905,
> > 
> > "increases" has some implicit baseline, which is typically "the current
> > state prior to this document" (which is not the right baseline for this
> > case).  I'd suggest just "unnecessarily enables blind/off-path attacks",
> > or maybe a variant with "facilitates" rather than "enables".
> > (Similarly for the Introduction, twice.)
> 
> Good point!  -- I've used "facilitates"
> 
> 
> > 
> > Section 7
> > 
> >     known for a long time now.  However, the NTP specification has
> >     traditionally followed a pattern of employing common settings and
> >     code even when not strictly necessary, which at times has resulted in
> >     negative security and privacy implications (see e.g.
> > 
> > It seems unusual for the NTP *specification* to employ common *code*.
> 
> I guess "algorithm" might have been a better term -- but still the text 
> wouldn't add much. So I've just s/and code//.
> 
> 
> 
> 
> >     This issue has been tracked by US-CERT with VU#597821, and has been
> >     assigned CVE-2019-11331.
> > 
> > I failed to find anything under us-cert.gov that referenced "VU#597821"
> > or even just "597821".
> 
> Good grief! No idea what happened to it. -- So I've tweaked the text 
> such that we only keep the CVE reference:
> 
>     This issue has been assigned CVE-2019-11331 [VULN-REPORT].
> 
> where:
> 
>     [VULN-REPORT]
>                The MITRE Corporation, "CVE-2019-11331", April 2019,
>                <https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-
>                2019-11331>.
> 
> 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
> 
> 
>