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

[Heiko Gerstung <[e-mail]>]

> Am 26.05.21, 18:11 schrieb "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 ma
> ke sense or are not desired for unicast PTP. Objectives like Identity, Authentic
> ation, Replay prevention, Request-response consistency, Non-amplification and Sc
> alability are covered in the proposed draft. This means that out of 9 stated goa
> ls, the draft addresses 6. Your statement that the draft does not appear to achi
> eve *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. 
Who defines which of the goals are more critical than the others? I do not see that the objectives listed in 1.1 are in any kind of sort order that represents a priority or criticality. 
As explained in my last email, the three objectives I do not see covered are:

* Confidentiality (I do not see a use case for sending encrypted data over PTP, it certainly is not a requirement I ever heard of from one of our users)
* Unlinkability (not applicable to unicast PTP, which requires the server to maintain a client state)
* Scalability (again, not applicable as phrased in RFC8915, as unicast PTP requires the server to maintain a client state)

If those goals are critical to someone, I agree that unicast PTP is not the right protocol and would recommend using NTS4NTP, especially if the accuracy requirements allow it. All other goals outlined in the NTS4NTP RFC are achieved by the draft.

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

It is strange that RFC8915 bothers to list the objectives of NTS right at the beginning and does not mention the - according to you - most critical one in that list. Anyway, I do not understand why you think that this goal is not covered by our draft. I am open to discuss how we can add text to the draft that clarifies this - but I do not understand why for you that would be a reason to not vote for not adopting the draft and start that discussion in the WG. 

>> This is confusing, as you are an author of RFC8915 which correctly and cle
> arly explains in Section 8..6 that delay attacks cannot be prevented by cryptogr
> aphic 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. 

I agree that a client can define its own limits for a maximum delay, I just tried to point out that the definition of MAXDIST is a part of NTP and therefore does not exist in PTP - sorry if that did not come across. MAXDIST includes not only the delay between client and server, "but the whole distance back to the reference clock as reported in the Root Delay field" (RFC8915, Section 8.6). I agree that a client, depending on its own requirements, can define a limit for the delay between itself and the PTP server, but MAXDIST is not a term we can use for PTP. 

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

Well, sort of. You do seem to misunderstand how PTP is measuring the round trip delay, but we will come to that a little bit further down this mail (and Miroslav already provided an explanation in the meantime).

>> There is no exchange of time information or delay measurements etc. in pha
>> se 2, this phase is solely performed to establish contracts between the client a
>> nd the server. A client typically requests  announce messages (carrying state in
>> formation of the server) first. When it detects that the state of the server is
>> acceptable, the client establishes two additional contracts, one for sync messag
>> es (time transfer from server to client) and one for delay responses (delay meas
>> urement from client to server), i.e. in a typical scenario, a client has 3 activ
>> e contracts (for announce, sync and delay_responses). In phase 3 the server send
>> s 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 sec
>> ond and perform 128 delay  measurements (i.e. a delay_req and delay_resp exchang
>> e) 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.

Yes, that is plain wrong. 

> * 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.
Well, there are more misunderstandings here. See 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 point is that it is not mandatory for a client to do the delay measurements at the same rate that is used for the sync messages. It can choose to do so, but if the network conditions (especially network congestion) are very stable, it is not required to measure the delay at a high rate. And: some applications only require a frequency transfer and do not need to establish a round trip delay at all. The telecom profile standardized as ITU-T G.8265.1 for example specifies a frequency-only mode which does not require any delay req/resp messages to be sent. 

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

Unlike NTP, which measures the round trip delay in one request/response message exchange, a PTP client measures the Server-To-Client* delay (S2C* Delay) with the Sync messages, and the Client-to-Server* delay (C2S* Delay) is measured using the delay req/resp exchange. The main reason for this AFAIK is that PTP initially was a multicast-only protocol and therefore separated the two steps. As Miroslav already explained, hardware timestamping is used only for event messages, which includes sync and delay req messages. The delay response message is not timestamped at all, it is just used by the server to tell the client when the delay req arrived. (*=please note that a lot of the literature still uses the "Master-to-Slave/M2S" and "Slave-to-Master/S2M" terminology which I try to avoid both in the draft and in my emails here)

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

Yes, and it is still possible and a common practice to have lower message rates for delay req/resp than for sync messages. But for some highly dynamic network environments - or when the accuracy requirements command that you detect even small fluctuations of delay variation - you need to run delay req/resp exchanges at a higher rate.

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

As outlined the RTT is determined with both the sync and delay req messages, therefore the above description is not correct, but in general you can establish error bounds based on the RTT of course. Not sure if this should be included in the draft, as it is more a best practice than a standard and can be very application specific. 

> 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.
That can be done, but it does not require to change the draft - this is standard PTP practice and very implementation/application specific and out of scope for our proposal, as far as I can see. 

> 2. Send DELAY_REQs frequently, and don't bother requesting SYNC packets at a
> ll.
This will not work and violates the basic concepts of PTP. 

> 3. Get error bounds from altogether outside of PTP and use them to
> sanity-check PTP SYNC packets.
This may be a good additional check, but will ultimately reduce the level of accuracy to the accuracy level of the outside method. PTP applications, as already explained, very often require sub-microsecond accuracy and therefore in most cases it is not useful to set up error bounds which are exceeding the minimum accuracy level required for an application to continue to work. An attacker could still bring down the application itself while staying "below the radar", i.e within the error bounds. 

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

It can just use the Sync messages to roughly initialize its time. Even without a two way delay measurement, a client will be able to synchronize its time to the server time in a good enough way to avoid a 8 minute offset. Only if the RTT is >= 16 minutes, you are in trouble. That means our approach is not usable for space ships that do not carry a solar/battery backed up RTC, which is a limitation I can accept. 

Please let me know if you are willing to agree that the WG starts the adoption process for the draft. We are happy to discuss additions and changes, of course. But I hope that the explanation and responses I provided reduce or even remove your concerns and reasons for opposing an adoption. 

I believe, btw, that this draft and the additional application of the NTS-KE protocol  is going to increase visibility and will be helpful for promoting NTS4NTP as well, simply because users will see the benefit of having to deploy and maintain only one key exchange infrastructure for both their NTP and PTP use-cases. It is going to be good marketing for NTS4NTP in that respect. 

Best Regards,
  Heiko


-- 
Heiko Gerstung 
Managing Director 
 
MEINBERG® Funkuhren GmbH & Co. KG 
Lange Wand 9 
D-31812 Bad Pyrmont, Germany 
Phone: [phone] 
Fax: [phone] 
 
Amtsgericht Hannover 17HRA 100322 
Geschäftsführer/Management: Günter Meinberg, Werner Meinberg, Andre Hartmann, Heiko Gerstung 
 
Email: 
[e-mail]
Web: 
Deutsch https://www.meinberg.de
English https://www.meinbergglobal.com
 
Do not miss our Time Synchronization Blog: 
https://blog.meinbergglobal.com
 
Connect via LinkedIn: 
https://www.linkedin.com/in/heikogerstung