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

From: Benjamin Kaduk via Datatracker <[email-masked]>
Date: Tue, 01 Jun 2021 17:24:50 -0700

Benjamin Kaduk has entered the following ballot position for
draft-ietf-ntp-port-randomization-06: Yes

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 DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-ntp-port-randomization/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

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.

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.

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.

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.)

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*.

   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".

---

From: Fernando Gont <[email-masked]>
Date: Wed, 2 Jun 2021 03:40:03 -0300

Hi, Ben,

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

On 1/6/21 21:24, Benjamin Kaduk via Datatracker wrote:
[....]
> 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.
?

> 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.

> 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.

> (Similarly for the Introduction, twice.)

Good point!  -- I've used "facilitates"

> 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//.

> I failed to find anything under us-cert.gov that referenced "VU#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: [email-masked] || [email-masked]
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1

---

From: Benjamin Kaduk <[email-masked]>
Date: Thu, 3 Jun 2021 16:17:49 -0700

Hi Fernando!

> its possible impact on time measurement.

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

> 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