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

[Benjamin Kaduk via Datatracker <[e-mail]>]

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