Re: [Ntp] NTS4UPTP Rev 03 - Formal request for WG adoption

Daniel Franke <> Wed, 26 May 2021 16:11 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D58073A07FA for <>; Wed, 26 May 2021 09:11:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.098
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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 5It0u2jcDSlX for <>; Wed, 26 May 2021 09:11:44 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::52b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 51A6D3A07F5 for <>; Wed, 26 May 2021 09:11:44 -0700 (PDT)
Received: by with SMTP id 27so1353572pgy.3 for <>; Wed, 26 May 2021 09:11:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=rbG3Z+0w0yf3W1sR9EQhX2YzoqiGAYyz2YriDgKfXS0=; b=RnL5i271+n+zLDqsDhJW41ESFcuvzWKr84Y7bd2kQjFTNd46tgWLzecxrB52SoEzBj B0gKDliwCxKSkYRZdzboQGoJp/fWkn24YNn4pF0mIQFEs1MqYBXTc3uFbGMfif9q+skF sv6LqNPaeWVeS9AtPhoEVZytFtsNCYTigQoUGzGCiCQOUgwVoYP8fDXK8X2Q8rGRBSfm urRIaA/wRwMGYyCOrUPJPaUO7wrU83gKiUZq8CpwRqjDBw2e/HBoM5vwEhkHdLePl6Ym o3Hdzm3dKELxw18/UZYNdPI7lV2cE7QW6bGziIIaNFvM0GFwcRxk7f+8kM8+AEXOYxfW 4SUw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=rbG3Z+0w0yf3W1sR9EQhX2YzoqiGAYyz2YriDgKfXS0=; b=Xc24DHNfQDjno4ZkW3qLPVsNv7h/18Hq3Gswoaz4a3YWLNMrFDQPW9fdPe3tdXm7e+ +SPBWvpg0HRocZnKDKxI+hh7wWmi4aNK7tCFih19iGIhdjC9AQ/O4zAciCL8VDG38DvG WkP4ofxFSgEZ5ByktTTg0sEV7HkriIQrBJXWAtVuL0jocM1adXXkWQWlnf+/eXTPsxki MPoWNFN7cn0DGmuygpZ2dKmeQszPMmzZXsdUBxJSfPirt+iiDgZx96QF5dZQNrwVa55Z 8iwZWhDCnuicEb9sq4hpCHApfV4v57ZRDfAdJvJg2UQ1jWTBaG/c9GrxUAd9YGvwsYns Yfdg==
X-Gm-Message-State: AOAM532QMDzs7t/f9RoM73ofR4ZlB+4QSGlHXMz/201M1oRuOOOV8MSn 9rmL+JF8CGyaTyW40mKoFhpYOnXS7mj7+UUW4T22z8chf+p5TQ==
X-Google-Smtp-Source: ABdhPJzbt4Cw6sl4QI5iM4785uSse8kbBz2BYDlNDTqWWFxHorcNrQrjz+85lMNZ7yMZ9z+/pWpAi2A7EFrdivxxipI=
X-Received: by 2002:a63:d710:: with SMTP id d16mr25326660pgg.214.1622045502689; Wed, 26 May 2021 09:11:42 -0700 (PDT)
MIME-Version: 1.0
References: <>
In-Reply-To: <>
From: Daniel Franke <>
Date: Wed, 26 May 2021 12:11:31 -0400
Message-ID: <>
To: Heiko Gerstung <>
Cc: "" <>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <>
Subject: Re: [Ntp] NTS4UPTP Rev 03 - Formal request for WG adoption
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, 26 May 2021 16:11:49 -0000

On Wed, May 26, 2021 at 10:36 AM Heiko Gerstung
<> wrote:
> The list of objectives as stated in RFC8915, Section 1.1 lists a number of objectives and yes, not all of them are met, but this is because they do not make sense or are not desired for unicast PTP. Objectives like Identity, Authentication, Replay prevention, Request-response consistency, Non-amplification and Scalability are covered in the proposed draft. This means that out of 9 stated goals, the draft addresses 6. Your statement that the draft does not appear to achieve *any* of NTS’s goals is therefore not correct IMHO.

Okay, yes, some of these goals are covered; certainly, identity is
covered just fine. I will rephrase to say only that some critically
important ones are not. The most critical miss is one that is perhaps
not adequately called out by the objective summary, but is discussed
in the security considerations, which is to achieve tight, known
bounds on the imprecision that can be introduced by jitter and
asymmetry (whether natural or malicious in origin).

> This is confusing, as you are an author of RFC8915 which correctly and clearly explains in Section 8..6 that delay attacks cannot be prevented by cryptographic means. The MAXDIST approach might work for some applications, but I do not think that this is applicable for  unicast PTP use cases.

The whole thrust of section 8.6 is that although a cryptographic
authenticator can't protect against network asymmetry or jitter, the
possible error introduced by this is bounded on both sides because
causality dictates that the response cannot have been sent sooner than
the request was sent, and cannot have been sent later than it was
received. Clients can define MAXDIST according to whatever error
bounds they consider acceptable. Your claim that this is not
applicable to unicast PTP is mysterious to me, because you can achieve
the same thing with DELAY_REQ/DELAY_RESP messages and the timestamps
therein. If you don't do this, then you can't establish any
trustworthy error bounds on your time signal and haven't achieved any
meaningful security.

> There is no exchange of time information or delay measurements etc. in phase 2, this phase is solely performed to establish contracts between the client and the server. A client typically requests  announce messages (carrying state information of the server) first. When it detects that the state of the server is acceptable, the client establishes two additional contracts, one for sync messages (time transfer from server to client) and one for delay responses (delay measurement from client to server), i.e. in a typical scenario, a client has 3 active contracts (for announce, sync and delay_responses). In phase 3 the server sends sync and announce messages and responds to delay_requests with delay_responses.
> [...]

> It is not uncommon that PTP clients will receive 128 sync messages per second and perform 128 delay  measurements (i.e. a delay_req and delay_resp exchange) per second.

Okay, I misunderstood a couple significant things here, namely:

* I mentally transposed the DELAY_REQ/DELAY_RESP exchange from phase 3
into the last part of phase 2, and thought that they only happened
during setup. I didn't realize they'd be reëxchanged with this kind of
* I was thinking that sequence numbers on DELAY_RESP packets are
independently assigned, rather than being copied from the DELAY_REQ.
This impacts my reasoning about request/response consistency, but I
think there are still problems here which I'll get to below.

If a client is going to be exchanging delay messages just as often as
it receives sync messages, then I don't understand the point of using
the sync messages at all. The DELAY_RESP message contains a receive
timestamp, so it contains all the information a client needs for time
synchronization. Does one for some reason obtain more accurate results
by using the delay message only for delay measurement, and the sync
messages for their timestamps, rather than just using the delay
messages for both purposes? I thought the whole point of having both
message types was that delay measurements didn't need to be sent
nearly this often because delays are expected to be stable over time,
and that sync messages can be broadcast.

Anyway, authenticated DELAY_REQ/DELAY_RESP message pairs can be used
to establish ±half-RTT error bounds. SYNC messages, whether
authenticated or not, can't, because they're one-way and therefore
susceptible to delay attacks of arbitrary duration, but even an
unauthenticated SYNC message can still be sanity-checked against
previously-established bounds.

So, I see three approaches that work here. The first two describe
possible changes to your draft. The third is how my hybrid NTP/PTP
proposal works:

1. Send DELAY_REQs at a modest interval. Use the error bounds
established by these volleys to sanity-check the timestamps in the
SYNC packets.
2. Send DELAY_REQs frequently, and don't bother requesting SYNC packets at all.
3. Get error bounds from altogether outside of PTP and use them to
sanity-check PTP SYNC packets.

Anyway, circling back to request/response consistency: the sequence
numbers in the DELAY_REQ/DELAY_RESP packets do work, but there's an
inadequately-addressed wrinkle wrt to the wraparound issue. Your draft
calls for rejecting a DELAY_RESP packet if its receive timestamp is
not within 8 minutes of the corresponding request's origin timestamp,
because the sequence number could have wrapped around by then. This
works iff the client is already at least loosely synchronized. What is
a client to do if its clock is not initially synchronized to within 8