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

[Daniel Franke <[e-mail]>]

On Wed, May 26, 2021 at 10:36 AM Heiko Gerstung
<[e-mail]> 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
frequency.
* 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
minutes?