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

Ulrich Windl <Ulrich.Windl@rz.uni-regensburg.de> Thu, 22 July 2021 09:19 UTC

Return-Path: <Ulrich.Windl@rz.uni-regensburg.de>
X-Original-To: ntp@ietfa.amsl.com
Delivered-To: ntp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F83C3A3F24 for <ntp@ietfa.amsl.com>; Thu, 22 Jul 2021 02:19:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ecwGW2r8s7I7 for <ntp@ietfa.amsl.com>; Thu, 22 Jul 2021 02:19:33 -0700 (PDT)
Received: from mx3.uni-regensburg.de (mx3.uni-regensburg.de [IPv6:2001:638:a05:137:165:0:4:4e79]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7024A3A3F23 for <ntp@ietf.org>; Thu, 22 Jul 2021 02:19:33 -0700 (PDT)
Received: from mx3.uni-regensburg.de (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id CEBEE6000057 for <ntp@ietf.org>; Thu, 22 Jul 2021 11:19:27 +0200 (CEST)
Received: from gwsmtp.uni-regensburg.de (gwsmtp1.uni-regensburg.de [132.199.5.51]) by mx3.uni-regensburg.de (Postfix) with ESMTP id AD7EB6000051 for <ntp@ietf.org>; Thu, 22 Jul 2021 11:19:27 +0200 (CEST)
Received: from uni-regensburg-smtp1-MTA by gwsmtp.uni-regensburg.de with Novell_GroupWise; Thu, 22 Jul 2021 11:19:27 +0200
Message-Id: <60F9381E020000A1000429B7@gwsmtp.uni-regensburg.de>
X-Mailer: Novell GroupWise Internet Agent 18.3.1
Date: Thu, 22 Jul 2021 11:19:26 +0200
From: Ulrich Windl <Ulrich.Windl@rz.uni-regensburg.de>
To: ek.ietf@gmail.com, mlichvar@redhat.com
Cc: "ntp@ietf.org" <ntp@ietf.org>
References: <YNw9fHMijDFIW9B4@localhost> <YNrbjCDF4/609dg/@localhost> <D999D237-5A25-4E84-99D0-EE5DB2B13411@cisco.com> <YN3ZzPN5LOsAjmz6@localhost> <DM4PR11MB5438D8450E7B90D363929640B5119@DM4PR11MB5438.namprd11.prod.outlook.com> <YPaunrczI/inrtMP@localhost> <60F6B70A020000A100042803@gwsmtp.uni-regensburg.de> <YPa9H7IV2wITWKrD@localhost> <CAMGpriWzV4--_Nw9hsNC01U7f1FzjZQ8sNdJz+25dxhFtuDUvg@mail.gmail.com> <YPkxqtpgzD7g8Anz@localhost>
In-Reply-To: <YPkxqtpgzD7g8Anz@localhost>
Mime-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
Content-Disposition: inline
Archived-At: <https://mailarchive.ietf.org/arch/msg/ntp/M9wtpU52J-Om7EGX3GQG4gcGH0k>
Subject: [Ntp] Antw: Re: Antw: [EXT] Re: Robert Wilton's Discuss on draft‑ietf‑ntp‑interleaved‑modes‑05: (with DISCUSS and COMMENT)
X-BeenThere: ntp@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Network Time Protocol <ntp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ntp>, <mailto:ntp-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ntp/>
List-Post: <mailto:ntp@ietf.org>
List-Help: <mailto:ntp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ntp>, <mailto:ntp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 22 Jul 2021 09:19:37 -0000

>>> Miroslav Lichvar <mlichvar@redhat.com> schrieb am 22.07.2021 um 10:51 in
Nachricht <YPkxqtpgzD7g8Anz@localhost>:
> 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
> protocol.

Your opinion is different from the RFC 5905:
"Origin Timestamp (org): Time at the client when the request departed
for the server, in NTP timestamp format." (page 23)

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