Re: [Ntp] Protocol and Security Enhancements for the Network Time Protocol (NTP)

Miroslav Lichvar <> Mon, 19 April 2021 11:09 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 33E723A2D3F for <>; Mon, 19 Apr 2021 04:09:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.22
X-Spam-Status: No, score=-0.22 tagged_above=-999 required=5 tests=[DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id KdllKoyQlikX for <>; Mon, 19 Apr 2021 04:09:33 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 7399E3A2D3E for <>; Mon, 19 Apr 2021 04:09:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=mimecast20190719; t=1618830571; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=2wOnc7991nKNHX1aN8IXq+2PpFfCAnMTdKK48grSynw=; b=XUQofalfHG3tzT//7n2QtxdjMhwrZkA1fBcjlz6f3bsJ90r8MFSvXBMEC/ULYexa4TiYG/ GGMjE8QX31FkR+5lfuyH6/yUgOLejG/Y3omAuxderrUeZTeZ7t5rzdsyqU8vpt9/JkkCHj iAc7HQegJlxtDvksFYjkCTjX5IvXOds=
Received: from ( []) (Using TLS) by with ESMTP id us-mta-362-u5w8-vPhNUuVDNLDVFiRBA-1; Mon, 19 Apr 2021 07:09:24 -0400
X-MC-Unique: u5w8-vPhNUuVDNLDVFiRBA-1
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 4513F6D241; Mon, 19 Apr 2021 11:09:23 +0000 (UTC)
Received: from localhost ( []) by (Postfix) with ESMTPS id C170B5D71D; Mon, 19 Apr 2021 11:09:21 +0000 (UTC)
Date: Mon, 19 Apr 2021 13:09:20 +0200
From: Miroslav Lichvar <>
To: "David L. Mills" <>
Cc: NTP WG <>
Message-ID: <YH1k4ETzrUB0tVQt@localhost>
References: <> <YHRr1IhY7Xg8+uo2@localhost> <>
MIME-Version: 1.0
In-Reply-To: <>
X-Scanned-By: MIMEDefang 2.79 on
Authentication-Results:; auth=pass smtp.auth=CUSA124A263
X-Mimecast-Spam-Score: 0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Archived-At: <>
Subject: Re: [Ntp] Protocol and Security Enhancements for the Network Time Protocol (NTP)
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 19 Apr 2021 11:09:38 -0000

On Fri, Apr 16, 2021 at 03:32:20PM -0400, David L. Mills wrote:
> Miroslav Lichvar wrote:
> > The protocol doesn't prevent amplification attacks using the cookie
> > response. The document claims that rate limiting prevents such
> > attacks, but I don't think that is true. Rate limiting is not a
> > security mechanism. It actually creates other security issues. The
> > server has a limited amount of memory. Attackers can avoid rate
> > limiting by using more addresses than the server can remember. That's
> > easy if the victim is using IPv6.
> > 
> Rate limiting in itself is not the issue.  See the DDoS section .
> The effect is to delete packets with a headway less than two seconds.
> The LRU list includes up to 700 distinct IP addresses, so the goal is to
> amputate those enemy attacks before generating a response packet.
> This scheme has been used at NIST for several years.

If the server's LRU list is limited to 700 addresses, the attackers
will simply use 701 or more addresses to prevent any address from
accumulating requests and effectively disable the rate limiting.
Generally, it cannot prevent an amplification attack.

What is worse, it can be exploited for a DoS attack on real NTP
clients if it doesn't randomly let some packets through. An attacker
can send requests to the server with spoofed source address frequently
enough to keep the rate limiting constantly enabled in order to
prevent the real client from getting any responses to its own
requests. This was reported years ago, but it is still not fixed in
the implementation.

It is a widespread issue. A third of public servers included in the project seems to be affected.

> > It doesn't have a fully random nonce in addition to the transmit
> > timestamp. It claims that transmit timestamps are not predictable
> > while it recommends to not use the data minimization.
> > 
> I submit that in this context, the transmit timestamp can be an adequate
> nonce.  It would be possible
> to replace this function by an explicit nonce, but this means to be
> overkill.  The data minimization
> issue is not relevant.

The data minimization draft requires clients to use fully random
transmit timestamps. That's a good nonce, but it can be used only in
the client-server mode, not the symmetric mode.

> > In the broadcast mode the transmit timestamp is used as a sequence
> > number, which means the server cannot have a backward step. It doesn't
> > have a mechanism to protect against delay attacks. (That was a goal
> > in earlier NTS designs.)
> > 
> The hazzard is mitigated by the rules explained in section 4.3.  An old
> duplicate
> is recognized by a check on the apparent  poll interval.

That is not always sufficient. An attacker who can prevent packets
sent by the genuine server from reaching the client, can replay old
packets at a consistent rate with a constant delay (arbitrarily
large). The client will not see anything suspicious, except that the
time is in past. If it accepts the backward step, it will be
susceptible to the attack.

> > The described parser detects legacy MACs by checking whether the
> > length field of an extension field is zero. I guess that was meant to
> > be the type of the field? That would work only with key IDs below
> > 65536.
> > 
> The proposed scheme does not work with legecy autokey.  Fancy that .

The trouble is that it will fail to parse messages of implementations
implementing RFC 5905 but not RFC 5906, using MACs with key IDs larger
than 65535.

> > It claims that NTS doesn't support interleaved mode. How could it, are
> > those two not at different layers? NTS+xleave definitely works for me.
> > 
> The proposed onwire protocol combines basic and interleave modes in a single
> protocol where
> the transmit devstamp is used  for all protocol rounds.  The detailed design
> is described in section 4.3.

The document doesn't have enough details for me to fully understand
the new combined protocol.

Is a server or peer supposed to send responses with transmit timestamp
of a previous response whenever it has this timestamp saved, meaning
interleaved mode constantly enabled, except it is not indicated by the
origin timestamp as it used to?

How would an older client or peer not implementing this new protocol
be able to process received responses? I suspect it would be
dropping all measurements due to a large delay.

Another issue is that the symmetric mode cannot always work in
interleaved mode. When the polling intervals of the peers don't match,
there are multiple responses per request, using the same origin
timestamp. This means there is an ambiguity for the interleaved
transmit timestamp. The peer doesn't know if it actually received the
response to which the transmit timestamp corresponds to. In such a
case the symmetric mode needs to switch to basic mode. This is how it
works in the ntp-interleaved-modes draft.

Miroslav Lichvar