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

Fernando Gont <> Wed, 02 June 2021 06:40 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 60D983A379A; Tue, 1 Jun 2021 23:40:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id qEI-znm5c8w1; Tue, 1 Jun 2021 23:40:18 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id A94163A3797; Tue, 1 Jun 2021 23:40:17 -0700 (PDT)
Received: from [] (unknown []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id 678252802A7; Wed, 2 Jun 2021 06:40:08 +0000 (UTC)
To: Benjamin Kaduk <>, The IESG <>
References: <>
From: Fernando Gont <>
Message-ID: <>
Date: Wed, 2 Jun 2021 03:40:03 -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: <>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: <>
Subject: Re: [Ntp] Benjamin Kaduk's Yes on draft-ietf-ntp-port-randomization-06: (with COMMENT)
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 02 Jun 2021 06:40:24 -0000

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.

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

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

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


               The MITRE Corporation, "CVE-2019-11331", April 2019,


Fernando Gont
e-mail: ||
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1