Skip to main content

Network Time Protocol Version 4: Port Randomization


Erik Kline
John Scudder

No Objection

Murray Kucherawy
(Alvaro Retana)

Note: This ballot was opened for revision 06 and is now closed.

Erik Kline
John Scudder
Roman Danyliw
Comment (2021-06-02 for -06) Sent
Thank you to Sean Turner for the SECDIR review.

** Section 3.5.  Editorial. No issues with the text here.  However, it seems to duplicate what was already said in Section 3.1.

** Section 7.  Consider adding informal references for CVE-2019-11331 (
Warren Kumari
Comment (2021-06-02 for -06) Not sent
Nothing to add...
Francesca Palombini
No Objection
Comment (2021-06-01 for -06) Sent
Thank you for the work on this document, short and to the point.

I only have one nit comment and a non-blocking comment.


1. -----

   some off-path attacks (see e.g.  [NTP-FRAG].  This document aligns

FP: missing ")"

2. -----

   This issue has been tracked by US-CERT with VU#597821, and has been
   assigned CVE-2019-11331.

FP: I am just not sure that this sentence adds anything without some reference...
Murray Kucherawy
No Objection
Zaheduzzaman Sarker
No Objection
Comment (2021-06-02 for -06) Sent
Thanks for this document. Thanks to all the reviewers, specially Brian Trammell for his TSVART review. 

I have two observations,

    *   it says "This issue has been tracked by US-CERT with VU#597821, and has been
   assigned CVE-2019-11331." Please provide proper reference to the mentioned terminologies and assignment. 

    *   removal of section 5: I don't think implementation status is a bad idea to be included in the memo. If not in a section, may be as appendix.
Éric Vyncke
No Objection
Comment (2021-05-31 for -06) Sent
Thank you for the work put into this document. 

Please find below some non-blocking COMMENT points (but replies would be appreciated), and some nits.

Thanks to Karen O'Donoghue for her shepherd's write-up.

I hope that this helps to improve the document,




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

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

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

Some rationale for "The randomized port number SHOULD NOT be shared with other associations." would be welcome. Also, is it OK to share this port number with other applications ?

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

== NITS ==

Please address all nits detected by:

-- Section 8 --
Unusual last paragraph in the acknowledgements ;-)
Benjamin Kaduk Former IESG member
Yes (2021-06-01 for -06) Sent
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.



   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 that referenced "VU#597821"
or even just "597821".
Alvaro Retana Former IESG member
No Objection
No Objection (for -06) Not sent

Lars Eggert Former IESG member
No Objection
No Objection (2021-05-26 for -06) Sent
All comments below are about very minor potential issues that you may choose to
address in some way - or ignore - as you see fit. Some were flagged by
automated tools (via, so there
will likely be some false positives. There is no need to let me know what you
did with these suggestions.

Document references draft-irtf-pearg-numeric-ids-generation-03, but -07 is the
latest available revision.

These URLs in the document can probably be converted to HTTPS:
Martin Duke Former IESG member
No Objection
No Objection (2021-05-26 for -06) Not sent
Thanks to Brian Trammell for the TSVART review.
Robert Wilton Former IESG member
No Objection
No Objection (2021-06-02 for -06) Sent

Thanks for this document.

Like Ben's comment, I was wondering why the document doesn't give a stronger recommendation as to which of the two approaches to follow.  It looks like all the implementations that the document lists already take the per-association approach, and that approach seems to be sufficient.   Hence, would it not be simpler to make that the RECOMMENDED approach, and then say that implementations MAY do per request randomization, but need to be aware that individual requests are more likely to take different paths with different latencies?