Re: [Ntp] Antw: [EXT] Re: Robert Wilton's Discuss on draft‑ietf‑ntp‑interleaved‑modes‑05: (with DISCUSS and COMMENT)

Miroslav Lichvar <> Thu, 22 July 2021 08:52 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 64AAB3A3E67 for <>; Thu, 22 Jul 2021 01:52:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.25
X-Spam-Status: No, score=-3.25 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.452, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-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 Gt-T-wgia7Zz for <>; Thu, 22 Jul 2021 01:52:03 -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 5ACC83A3E66 for <>; Thu, 22 Jul 2021 01:52:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=mimecast20190719; t=1626943920; 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=GVkzxjHV2LjKDm3X4u8BK5I+GPXR1vkiAEYOmGjq8K4=; b=MnOti2ZJ/iftLIfy6dAJFPKnqtOZyIJhAGj7EZQtXO9ujy3B54dX5TnIUmcqA0mq0HQPcm dogL0NGGE7GoqHOP4bgk7/0No2g5hRZUKvASw1OWmp8oNMSJK4CxtSQx1c7ozhOMCvwyzv 6ERAlP6Ni7ikF+/DlL8anzdyk9UYVCU=
Received: from ( []) (Using TLS) by with ESMTP id us-mta-342-mTfNjrrTM2qqGHGK5o7StQ-1; Thu, 22 Jul 2021 04:51:59 -0400
X-MC-Unique: mTfNjrrTM2qqGHGK5o7StQ-1
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 37BC5804140; Thu, 22 Jul 2021 08:51:57 +0000 (UTC)
Received: from localhost ( []) by (Postfix) with ESMTPS id 344215D6D3; Thu, 22 Jul 2021 08:51:56 +0000 (UTC)
Date: Thu, 22 Jul 2021 10:51:54 +0200
From: Miroslav Lichvar <>
To: Erik Kline <>
Cc: Ulrich Windl <>, "" <>
Message-ID: <YPkxqtpgzD7g8Anz@localhost>
References: <YNw9fHMijDFIW9B4@localhost> <YNrbjCDF4/609dg/@localhost> <> <YN3ZzPN5LOsAjmz6@localhost> <> <YPaunrczI/inrtMP@localhost> <> <YPa9H7IV2wITWKrD@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] Antw: [EXT] Re: Robert Wilton's Discuss on draft‑ietf‑ntp‑interleaved‑modes‑05: (with DISCUSS and COMMENT)
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Network Time Protocol <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 22 Jul 2021 08:52:07 -0000

On Wed, Jul 21, 2021 at 12:07:47PM -0700, Erik Kline wrote:
> >
> > Of course, this doesn't change anything about compatibility with
> > existing NTPv4 implementations. There is no clean way to detect the
> > support.
> >
> <random bad idea>
> For client mode, could the client make use of the LI field to indicate it
> speaks interleaved?
> </>

No, there are clients that always set it to synchronized, other
clients set it always to unsynchronized, and other clients set it to
their actual status.

If we are considering unclean solutions abusing unrelated fields, the
best one would be the reference timestamp. It is 64 bits and it is
normally ignored by the server. The NTPv5 proposal uses this field to
detect whether an NTPv4 server supports NTPv5. Not a clean solution,
but I don't see a better one. What would IESG think about that?

For the interleaved mode, clients could be required to set it to a
specific value, maybe XORed with their RX and TX timestamps, to push
the false positive rate to the 1/2**128 territory. I think this would
truly make it the hack that same people already consider it.

My opinion still is that clients that set their origin timestamp to
anything else than zero or the transmit timestamp from the received
packet don't follow the NTP specification. It's not a subset of the

In case this argument doesn't hold, I also analyzed traffic on
multiple public servers to confirm that there were no implementations
unknowingly sending requests in interleaved mode. The only instance
was the ntpsec fork of ntp, which already supported interleaved mode,
but had the support only partially removed, and this is what I think
actually prompted the Daniel's objection to the proposal.

Now, with many public servers having the support, it would be
difficult to implement a new client with such a bug and not notice it.

Miroslav Lichvar