[Ntp] An RFC6921-compliant NTP implementation

Daniel Franke <dfoxfranke@gmail.com> Thu, 01 April 2021 00:01 UTC

Return-Path: <dfoxfranke@gmail.com>
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 1ACD23A3C30 for <ntp@ietfa.amsl.com>; Wed, 31 Mar 2021 17:01:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 LLJ49oFpFQxT for <ntp@ietfa.amsl.com>; Wed, 31 Mar 2021 17:01:42 -0700 (PDT)
Received: from mail-pj1-x102d.google.com (mail-pj1-x102d.google.com [IPv6:2607:f8b0:4864:20::102d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6EB993A3C2D for <ntp@ietf.org>; Wed, 31 Mar 2021 17:01:23 -0700 (PDT)
Received: by mail-pj1-x102d.google.com with SMTP id q6-20020a17090a4306b02900c42a012202so2133639pjg.5 for <ntp@ietf.org>; Wed, 31 Mar 2021 17:01:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to:cc; bh=QT3kdeaSzUnrFSFCeKvy+Tt8BbL+I85q+EDHhFYIbMM=; b=m+oC41i0h/Y3V0svAgJJBb2pVZf2JmoKvBDtcFTFLFhhrhBiDBwEvClgpjwL27+a6P 1v3tEWTy+jfSnS5qAZ1qI3yf4W3cQc3rI7wkZA3TCTm55Y12o9RDrDtlpuQY3rpmSmzR GN4Cs3rXKbfGEGjZIQEW6MVAQBolLQmO6lpJRxB39OqRI2khK1vlKNbFCR4/NzECFdx+ /lNFBTpOMCObin0hh2KPOnUpQJAPW07bpx65YZcZdC4kSPzEW2NytFvf1+cd5FSq1QR9 XVOV1D9cqjcJZ7hhqByde3f4ozq65/ZP/3k4fEl4XLJ4aH0tGefThAwebqNcOevW3idl JpoA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=QT3kdeaSzUnrFSFCeKvy+Tt8BbL+I85q+EDHhFYIbMM=; b=LxroPt2K4n4JxwPE0TKi3wfrzIeQUaYWu75US3Efk1REQzuD0dugiYhR+26XY1ubjX XesrFOilFRrWn8MFF+jEJi0D7ZSg1aYTm5tcil5HMk7tBCc16zBcAC3DbhFj5vGL8xJJ Mm5lyDKMg3Z5txpuGmchfAnKaBclH3s7o22VrP+TyDTrFesaEoA0Ruh/lUGbKIDrNMwU z+ZsSh7kXZjO4leKR1gU1S209PkUL2vS1CfzQ2PD+hk4I6Zm/RvNKkP2jmDkrMgEU9qP EwvEe8qtn05I/dfqyjynToB2EovcbkcQwco6vzxNNWjvScFkFTydXnQsuoewNN2tVLh6 ib9w==
X-Gm-Message-State: AOAM53324OWZnCsDSJFdsfUWL3eVGnji5OmTBtqZKup8J+SEgey2JUVq gA9G7nVLcMLCmwOncchEzfmxL1GV8Iv19jTh6Qt1a6jMhkfBMQ==
X-Google-Smtp-Source: ABdhPJzksaZbNJdNOzJw6AHADuJIdJLeOqJretzbaBtW6pCNInhSxX45dTl78G/8M0zNzdQKKGi0edEEDyE9EQVGrxg=
X-Received: by 2002:a17:90b:344c:: with SMTP id lj12mr6070886pjb.208.1617235281738; Wed, 31 Mar 2021 17:01:21 -0700 (PDT)
MIME-Version: 1.0
From: Daniel Franke <dfoxfranke@gmail.com>
Date: Wed, 31 Mar 2021 20:00:00 -0400
Message-ID: <CAJm83bAQgRKNEdaOcNvSkL1OF-xOd8T_5AYfwJCXtpZifUAVSQ@mail.gmail.com>
To: NTP WG <ntp@ietf.org>
Cc: bob.hinden@gmail.com
Content-Type: multipart/alternative; boundary="0000000000007c7f9a05beddeef4"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ntp/ofZp5bwlS2mEV9N3_-ptbzznY-U>
Subject: [Ntp] An RFC6921-compliant NTP implementation
X-BeenThere: ntp@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <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, 01 Apr 2021 00:01:45 -0000

Building on the groundbreaking results from CERN's OPERA experiment showing
that neutrinos can be accelerated to superluminal speeds merely by
loosening the contacts on a transmission cable, I'm pleased to report a
mostly-successful experiment building an RFC6921 ("Design Considerations
for Faster-Than-Light (FTL) Communication") compliant implementation of NTP.

As a preliminary test intended simply to verify the correct functioning of
the experiment hardware, I positioned two hosts, both running unmodified
NTP software, 25 light-milliseconds apart, and networked them
point-to-point via a superluminal neutrino transceiver. I measured a ping
time of 49.998ms, confirming FTL communication. As expected, NTP was able
to operate normally in this rather unchallenging configuration.

FTL communication can lead to backward causality only when the
communicating parties are in relative motion, and since the speed of our
communication is only slightly greater than c, the communicating parties'
speed of travel needs to be only slightly less than c. Even in the
subluminal case, this already causes some problems for NTP. NTP is a clock
synchronization protocol, but as soon as relativistic effects become
non-negligible the whole notion of synchronicity needs to be abandoned;
thus it needs to be carefully stated what NTP is even trying to accomplish.
I decided on the following problem statement: given a client on a long
journey through space, in continuous communication with a server located on
Earth, allow the client to maintain a clock that will be synchronized with
the server's clock at such point as the client ever rejoins the server's
reference frame. The effects of time dilation mean that such a clock may
run at a rate quite different from the proper time experienced by the
client, but here we nonetheless have a well-defined goal, free of paradox.
Note the necessity of restricting ourselves to discussing client/server
mode; symmetric mode makes no sense in this setting.

The client will at all times need a priori knowledge of its velocity
relative to the server, and must make the following adjustments to the
usual NTP algorithms:

1. It must scale its clock frequency according to the time dilation
formula, 1/sqrt(1-v^2/c^2).
2. It must apply a Lorenz transformation to the receive and transmit
timestamps, to bring these from the server's reference frame into the
client's (the origin and destination timestamps are already in the client's
reference frame).
3. It must adjust for the fact that its distance from the server may be
different on one leg of a round-trip communication than it was on the
other. This would be necessary even in a Newtonian universe, whenever the
client and server are in relative motion.

These modifications are sufficient when only subluminal communication is
involved, but in the FTL setting, backward causality creates an additional
wrinkle, since a response mayan arrivan fore-when its corresponding request
on-sent. As far as our basic formula for clock offset, ((t_2 - t_1) + (t_3
- t_4))/2, goes, this is just fine: it has no special behavior for negative
values and needs no modification to accommodate them. The issue, rather, is
that it mayant be immediately possible to validate the origin timestamp.
Rather than discarding a packet with an unrecognized origin timestamp, the
client must retain it until its next request on-generates, and check the
match at that time.

I deployed an NTP client with the aforementioned modifications, again
equipped with an FTL neutrino transceiver, out to a distance of roughly a
light-hour, and then accelerated it back toward Earth, beginning tests once
it reached 0.99999c (I won't bore with the details of the propulsion system
because, since time flies, they're straightforward). For the duration of
its trip, it reported nominal results consistent with successful
synchronization, thus experimentally confirming the correctness of these
algorithm modifications.

I will not be releasing the code from this experiment, for two reasons:

1. The aforementioned requirement to store an unbounded number of
unauthenticated server packets until the client can determine whether it
willan on-generate a matching origin timestamp constitutes an unfixable DoS
vulnerability, and releasing known-vulnerable code would be irresponsible.

2. I no longer have it available, because when the returning client struck
Earth's atmosphere at relativistic speed, the fireball destroyed the
experimental apparatus, the server hosting my git repo, and most of
Antarctica. Sorry about that.