Re: [Ntp] New rev of the NTP port randomization I-D (Fwd: New Version Notification for draft-gont-ntp-port-randomization-01.txt)

Danny Mayer <> Wed, 29 May 2019 08:42 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3983212017D for <>; Wed, 29 May 2019 01:42:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.89
X-Spam-Status: No, score=-1.89 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id wqyAUXks1Tq4 for <>; Wed, 29 May 2019 01:42:15 -0700 (PDT)
Received: from ( [IPv6:2001:470:1:205::234]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 0253F120199 for <>; Wed, 29 May 2019 01:42:14 -0700 (PDT)
Received: from [] ( []) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id 45DPN51XYwzL7T for <>; Wed, 29 May 2019 08:42:13 +0000 (UTC)
References: <> <> <> <> <> <> <> <>
From: Danny Mayer <>
Message-ID: <>
Date: Wed, 29 May 2019 04:42:11 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:60.0) Gecko/20100101 Thunderbird/60.6.1
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Content-Language: en-US
Archived-At: <>
Subject: Re: [Ntp] New rev of the NTP port randomization I-D (Fwd: New Version Notification for draft-gont-ntp-port-randomization-01.txt)
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, 29 May 2019 08:42:28 -0000

On 5/29/19 12:18 AM, Fernando Gont wrote:
> On 28/5/19 23:20, Majdi S. Abbas wrote:
>> Randomizing the source port is pointless.  As Danny has noted, t1
>> already acts as a 2^64 nonce on each client mode chime request.  This
>> sufficiently hardens the unauthenticated case to an off path
>> attacker.  If additional security is required, authentication (via
>> classic PSK, or NTS modes) should be used.
> Using predictable numeric identifiers is a bad habit. We have plenty of
> history in this area and, as noted, it's quite interesting to see folks
> pushing in this direction in 2019, when the tendency has been to
> actually move away from predictable numeric IDs (TCP ISNs, transport
> protocol numbers, DNS TxIDs, Frag IDs, etc.).
> Using predictable port numbers makes it easy for an attacker to infer
> the "session id". You are just considering one possible attack scenario.
You are totally missing the point. The port numbers don't make NTP
vulnerable. The "session id" does not exist here. Instead NTP has an
origin timestamp that an off-path attacker does not have access to. Even
if it did, then the origin timestamp is wildly different each time it's
sent and is not predictable. This is a 64-bit nonce.

RFC6056 was probably developed as a result of the Kaminsky attack on DNS
and the way we fixed that. I noticed a number of people mentioned in
that RFC who were involved in those changes. It doesn't say so but that
RFC addresses shortcomings in those protocols that have small or
non-existent nonces which is not the case for NTP. Since you were one of
the authors I presume you know that. I discussed NTP with Paul Vixie at
the time and we agreed that because of the nonce it would not be
vulnerable like DNS was.

Since you claim that having well-known source ports is a vulnerability,
how does an off-path attacker know the server IP addresses that it is
using to get the timestamps? Accepting that, please provide in detail
how the off-path attacker is able to set up the origin timestamp so that
the client will accept it. You MUST be able to do this for the attack to
succeed. Remember that 64-bit timestamps are wildly different each time
a request goes out. If you cannot do this you have no case. Note that
replay attacks fail too since the client has already processed a given
origin timestamp.

>> Per session randomization doesn't resolve these issues -- the stated
>> rationale for both the draft and filed CVE is hardening to off path
>> attacks, which we've just covered.
> If tomorrow a flaw were found in an NTP implementation, that happened
> e.g. prior to the validation of the origin timestamp, I guess you are
> going to argue that "that was out of scope"?
There is no session validation since this is UDP not TCP. A flaw in an
NTP implementation that did not check that the timestamp matched would
be a bug in that implementation and randomizing the source port is not
going to change that. Furthermore the client needs the origin timestamp
to find the match in its local memory in order to process the incoming
packet. if it cannot find it, it will ignore the packet.