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

From: Heiko Gerstung <[email-masked]>
Date: Wed, 26 May 2021 16:36:49 +0200

[resent to the list, I had a 50% chance to reply to the correct message – thank you for nothing, Murphy ;-)]

Daniel,

> From: Daniel Franke <[email-masked]>
> Date: Wednesday, 26. May 2021 15:12

> I finally gave this draft a close read this morning. I have to oppose
> adoption, on the grounds that it doesn't appear to achieve any of
> NTS's goals.

Thank you very much for taking the time, much appreciated. I am not 100% sure where I can find the stated list of goals of NTS.

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. 

> It clearly doesn't attempt to achieve server statelessness. It doesn't
> achieve client unlinkability either, since only one cookie is provided
> and there's no mechanism for refreshing it without a new NTS-KE. The
> case possibly could be made (but hasn't been) that these goals aren't
> as important for PTP as they are for NTP, but after this I would still
> object that calling a protocol "NTS" when it doesn't provide these
> things is bad marketing for NTS4NTP.

You are correct, these goals are not important for PTP. The protocol itself prevents server statelessness, unlike NTP it is a subscription based protocol which means that a client has to establish contracts with a server and the server must keep a state for each contract. A requirement for client unlinkability could definitely come up. It may be satisfied by the fact that if a client changes its IP address, it has to re-establish a new contract with the server. In order to do so after an IP address change, the client has to re-run phase 1 and get a new cookie. As IP address changes typically do not happen very often, this might be acceptable for some applications. 

> The killer, though, is that the protocol fails to provide time
> authentication to within any reasonable error bounds. The only secure
> time exchange is the one that happens in phase 2 during the
> DELAY_REQ/DELAY_RESP exchange. 

This statement seems to indicate that you did not yet understand how unicast PTP works. 

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. 

All those message are secured using the keys established in phase 1, I therefore do not understand why you claim that the protocol fails to provide time authentication. 

> Transmissions during phase 3 are
> vulnerable to delay attacks. Checking sequence numbers is not
> sufficient mitigation against these. A MitM could forward packet N
> when (and only when) the server sends packet 2N. All sequence number
> checks would pass, but absent any other sanity checks the client's
> clock would be slowed by a factor of two.

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 NTS TLV is missing any field that corresponds to the Unique
> Identifier EF from NTS4NTP. Without this, an attacker can drop or
> reorder the server's messages and confuse the client as to what
> request a response corresponds to. 

> This is easy to fix, but absent a
> fix, clients would have to mitigate this by making sure they only ever
> have one request in flight at a time. 

An attacker that is capable of dropping messages can always drop them, the Unique Identifier EF from NTS4NTP cannot prevent that. 

As the NTS TLV is only used in phase 2, it is not a problem and the expected behavior for the client to negotiate one contract after the other, and depending on the requested duration, this is only required once every couple of minutes for example. The mechanism of the server including a nonce in the message that the client has to use in its next message ensures that a reordering of messages in any direction will not be successful.  

> Failure to promptly obtain a
> response to any time-sensitive request such as DELAY_REQ would require
> rerunning NTS-KE. Non-time-sensitive requests could simply be
> retransmitted.

See above for an explanation of the phases (delay_req only happens in phase 3, the NTS_TLV is only used in phase 2) and please see the explanation in our draft how we avoid replay attacks. 

In Section 7.1 we outline that the sequenceId has to be increasing in two consecutive messages of the same type, i.e. two delay responses. If a message arrives with a lower sequenceId than in the previous message, it will be ignored and does not trigger a phase 1 rerun. That means a retransmission of a packet in phase 3 will simply be ignored by the client. 

> To salvage the security of this protocol, you could first fix the
> Unique Identifier issue and then have the client send DELAY_REQ
> messages at NTP-like intervals, rather than just once per handshake,
> in order to regularly reëstablish tight error bounds that can be used
> to sanity-check the phase 3 packets. This would achieve time security
> about equal to what you get from the NTP/PTP hybrid I proposed last
> month, but without privacy, without server statelessness, and with an
> added requirement for support from the server rather than being able
> to unilaterally implement it on the client side.

Again, Daniel you seem to have misunderstood how PTP and the proposed draft is working. 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. 

Best Regards,

  Heiko

---

From: Daniel Franke <[email-masked]>
Date: Wed, 26 May 2021 12:11:31 -0400

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

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

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.

> [...]

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

---

From: Miroslav Lichvar <[email-masked]>
Date: Thu, 27 May 2021 09:36:46 +0200

On Wed, May 26, 2021 at 12:11:31PM -0400, Daniel Franke wrote:
> synchronization.

The delay response doesn't have a transmit timestamp and it's not an
event message, i.e. it is not timestamped on the receiving side. In
PTP there are event messages and general messages, exchanged on two
different UDP ports.

I think the reason for that is that PTP originated in time when
hardware timestamping was difficult and expensive, so the protocol
minimizes their rate and tries to distribute them evenly over time.
Even on modern hardware, transmit timestamps can be typically captured
only one at a time, so they need to be limited to the sync messages.

> I thought the whole point of having both

That is a reason but not the only one, I think.

The calculation of the offset in the PTP specification uses only two
timestamps assuming the delay is constant. Implementations can use an
out-of-spec approach similar to NTP using four timestamps
corresponding to the latest sync message and latest delay request, but
the T3-T2 interval is not as tight as in the NTP client/server mode.
It's more like the NTP symmetric mode, but with a random interval.

-- 
Miroslav Lichvar

---

From: Heiko Gerstung <[email-masked]>
Date: Thu, 27 May 2021 12:15:38 +0200

> Am 26.05.21, 18:11 schrieb "Daniel Franke" <[email-masked]>:
> 
>> 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.
> 
> 
> 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

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

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

Yes, that is plain wrong. 

> think there are still problems here which I'll get to below.
Well, there are more misunderstandings here. See below. 
 
> 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
> 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)

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

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

> established by these volleys to sanity-check the timestamps in the
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
This will not work and violates the basic concepts of PTP. 

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

> a client to do if its clock is not initially synchronized to within 8

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: +49 (0)5281 9309-404 
Fax: +49 (0)5281 9309-9404 
 
Amtsgericht Hannover 17HRA 100322 
Geschäftsführer/Management: Günter Meinberg, Werner Meinberg, Andre Hartmann, Heiko Gerstung 
 
Email: 
[email-masked]
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

---

From: Daniel Franke <[email-masked]>
Date: Thu, 27 May 2021 09:19:32 -0400

On Thu, May 27, 2021 at 6:15 AM Heiko Gerstung
<[email-masked]> wrote:
> Who defines which of the goals are more critical than the others?

The text of the draft speaks for itself authoritatively; anything
further I have to say is just my opinions about it.

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

So, I think there's an approach that'll work here, and you're close to
it. The key thing is that it's possible to dispense with the 8-minute
check if the client has not yet wrapped its sequence numbers for the
first time since running NTS-KE. At that point there's no risk of
confusing which request a response with a particular sequence number
is replying to, because there's only one possibility. By the time
wrapping begins, the client should be synchronized and therefore able
to apply the 8-minute check. In the unusual case that it isn't
synchronized yet, it needs to re-run NTS-KE.

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

Okay, I don't think we're disagreeing on anything of substance
surrounding this point. Yes, PTP will require different terminology.
And yes, NTP also includes the server's self-reported maximum error
due to upstream hops into its "error budget" when deciding whether a
packet is suitable for synchronization, while PTP can't/wouldn't do
this. But otherwise, the fundamental concept is the same.

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

It doesn't require any *on-wire* change. But the necessary client
behavior of using the delay messages to establish a range of plausible
times that are used to clamp SYNC messages is not described anywhere
in the current draft. And, as you've already taken pains to point out,
using delay messages to obtain the round-trip measurements that are
needed to compute these bounds is definitely not standard PTP
practice.

> This will not work and violates the basic concepts of PTP.

On the basis of Miroslav's explanation, I agree.

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

Here's what I think you're missing. We need to distinguish between the
precision afforded by PTP under normal network conditions, versus
under adversarial conditions. Under normal network conditions, the
precision afforded by either of our approaches is in the
sub-microsecond range that your customers have come to expect from
PTP. My approach will have literally no impact at all on PTP's usual
precision, because the PTP messages and the way they're processed are
untouched Your draft's approach will have some non-zero impact because
of the time spent computing the MAC tag, but I expect that with some
careful tuning this impact would be too small to measure. So for all
intents and purposes we're equivalent on this score.

Under adversarial conditions, the potential error of my approach is
±half-RTT, ± some other miscellaneous error terms that don't amount to
much by comparison. Without the fixes I've suggested, the potential
error of your approach is unbounded. With these fixes, it again
becomes the same as mine. Doing better than this through cryptographic
means *IS IMPOSSIBLE*. If you want secure sub-microsecond precision,
you must get it by physically securing your network segment. If you
tell your customers otherwise, you will be selling them snake oil.

So, a fixed version of your draft would provide time precision
equivalent to what hybrid NTP/PTP provides, both under normal network
conditions and under adversarial ones. Unlike hybrid NTP/PTP, it would
not provide for client unlinkability or server statelessness, but
perhaps we don't care much, and I wouldn't base my opposition to
adoption on this alone.

My principal objection to adopting NTS4UPTP is that it will be a lot
of work for a lot of people over many years before any end-user has
access to interoperating implementations of it. In contrast, hybrid
NTP/PTP can be had *TODAY*, using linux-ptp and chrony in the
configuration that Miroslav suggested a few weeks ago. All the work
that's needed is for Miroslav to double-check that chrony enforces the
correct the error bounds, and for somebody to write an accessible
HOWTO plus *maybe* an Informational RFC. You've not argued any
marginal benefit to NTS4UPTP that I think comes close to justifying
the development and rollout effort.

If you want to change my mind about this, I suggest you try convincing
me that PTP has functions that are auxiliary to time synchronization
that still need securing. Can an attacker do harm to an unsecured PTP
deployment in ways other than just desynchronizing clocks? DDoS
amplification is one example, but that can be solved in a much
lighter-weight fashion requiring little or no cryptography. What other
examples are there? How about the management functions in section 15 —
what sort of mischief can be done with those? Is there demand for the
ability to use a PKI to secure access to them?

If you do convince me via this avenue that there's worthwhile work to
be done here, I'll still advocate hybrid NTP/PTP for the long interim
before that work is usable.

---

From: Heiko Gerstung <[email-masked]>
Date: Thu, 27 May 2021 17:13:29 +0200

> Am 27.05.21, 15:19 schrieb "Daniel Franke" <[email-masked]>:
> 
Ok, thanks. 

>> It can just use the Sync messages to roughly initialize its time. Even wit
>> hout 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 limi
>> tation I can accept.
> 

>> I agree that a client can define its own limits for a maximum delay, I jus
>> t tried to point out that the definition of MAXDIST is a part of NTP and therefo
>> re does not exist in PTP - sorry if that did not come across. MAXDIST includes n
>> ot 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 t
>> he delay between itself and the PTP server, but MAXDIST is not a term we can use
>> for PTP.

>> That can be done, but it does not require to change the draft - this is st
>> andard PTP practice and very implementation/application specific and out of scop
>> e for our proposal, as far as I can see.
> 

I tried to explain that there is a RTT computation taking place, the client simply uses both sync and delay_req/resp messages for this. Maybe Doug can explain this to you in a better way.
There is a RTT calculation, and a PTP client uses RTT/2 as a correction for the incoming sync messages. 

>> > 2. Send DELAY_REQs frequently, and don't bother requesting SYNC packets
> at a
>> > ll.

>> 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 al
>> ready explained, very often require sub-microsecond accuracy and therefore in mo
>> st 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 cou
>> ld still bring down the application itself while staying "below the radar", i.e
>> within the error bounds.
> 

I try again to explain what I believe you are missing here. Any application that requires sync has a minimum requirement for synchronization, i.e. any time error greater than this limit is going to affect the application, in most cases it completely avoids that the application can be used anymore. In some cases it degrades the application to a point where financial damages are negatively impacting the owner/operator of that application. And in some cases it can cause physical harm to human beings (think of a power grid protection system which cannot continue to work without very tight synchronization and therefore might trip a circuit breaker as a precaution, creating a blackout for hundreds or thousands of households in the process). For those applications, there is no reduced sync performance under "adversarial conditions", the synchronization solution either delivers the required minimum accuracy or not. Most if not all applications that use PTP require a sync performance of a microsecond or less, that is the reason why they deployed PTP and not NTP.  NTP accuracy is not good enough for these people and therefore it does not help at all to introduce a concept which considers a degraded sync performance under adversarial conditions. 

I do not object to add some text to the draft that explains how to apply error boundaries which rely on half-RTT, but using NTP for establishing the RTT which is readily available from PTP itself and is based on hardware timestamps simply does not make any sense to me.

> perhaps we don't care much, and I wouldn't base my opposition to
Great, I am open for suggestions how to phrase that and add some explanation to the readers how a PTP implementation can establish error bounds based on RTT. I personally do not think that this is required for a security protocol, because it is more a topic of implementing a time synchronization protocol correctly for a given implementation, but I am happy to add some advice to implementors how they can improve robustness and resilience of their implementations. 

> access to interoperating implementations of it. 

OK, you just changed your principal reason why you object to adopting the draft after it seems I convinced you that the initial reasons why you object adoption of the draft do not exist. I am a little bit at a loss here, because I do not know if I can convince you *at all* to support adoption. But anyway, this is too important and I will keep trying ;-) ... 

I am puzzled that your main reason is that you believe this is a lot of work for a lot of people. Three people with a lot of experience in both NTP and PTP already put a lot of work into this draft and tried to reuse as many parts as possible from NTS4NTP to minimize the required work. These three people are willing to continue to work on this draft, and I am sure that others will join. If you personally do not think it is worthwhile, I fully accept that. But I believe you should not speak for others. In addition to that, your new principal reason to object the adoption can be applied to every new standard, especially when it is timing related. For example, you could ahve applied the same reason to NTS4NTP when it first came up as a topic.

> In contrast, hybrid

Nope. There is nothing available *TODAY* that comes even close. You are comparing apples and oranges. The draft offers the same level of protection against cybersecurity threats that are covered by NTS4NTP. It does so by maintaining the full accuracy level of PTP, i.e. sub microsecond time synchronization. An NTP/PTP combo can only protect your time to the accuracy level of NTP. It is not an alternative to what we propose with this draft. 

> lighter-weight fashion requiring little or no cryptography. 

I doubt that this is possible with unicast PTP. I kindly ask you to explain how you want to achieve that without a major redesign of the protocol, at which point it would not be PTP anymore. 

> What other

The main thing that PTP provides is orders of magnitudes higher accuracy performance. Your approach of combining NTP and PTP does not protect the time synchronization function of PTP without rendering it unusable for a lot of existing PTP applications. I do not understand why you want me to look at auxiliary functions of PTP when protecting its main purpose and reason d'etre is enough of a reason for the draft. 

> before that work is usable.

Unicast PTP without NTS is very vulnerable and offers an attacker multiple venues for causing harm to a network (see Section 7 of the draft). The draft provides all the protection that is required to allow using the higher accuracy protocol in a lot of additional applications and hybrid NTP/PTP is not doing the job in most of the current and future use case scenarios for unicast PTP. 

Regards,
   Heiko

-- 
Heiko Gerstung 
Managing Director 

 
Email: 

Connect via LinkedIn:

---

From: Miroslav Lichvar <[email-masked]>
Date: Thu, 27 May 2021 17:15:45 +0200

On Thu, May 27, 2021 at 09:19:32AM -0400, Daniel Franke wrote:
> becomes the same as mine.

In a network that has a full hardware PTP support, but not NTP
support, the delay measured by PTP would be smaller than NTP. Whether
that allows a MITM attacker to do more interesting things, I'm not
sure. I think they can always simply stop forwarding the traffic and
let the clocks drift away on their own, even if they don't bother to
mess with their frequency by shifting delays in opposite directions.

> deployment in ways other than just desynchronizing clocks?

There is quite a lot of data in the announce message used for various
purposes, which might have an impact further down the synchronization
chain. For example a wrong TAI-UTC offset wouldn't do anything to a
boundary clock keeping time in TAI, but it would have an impact on
leaf clients converting to UTC.

-- 
Miroslav Lichvar

---

From: Heiko Gerstung <[email-masked]>
Date: Thu, 27 May 2021 17:31:39 +0200

> sure. 

It will most probably allow an attacker to disrupt or degrade the sync service required for a critical application that relies on PTP and its accuracy. 

> I think they can always simply stop forwarding the traffic and

I agree, there is nothing you can put into a protocol that can protect against a MITM dropping traffic or delaying it to a point where the delay(-asymmetry) has a negative impact on the application. That did not stop the WG to work on NTS4NTP. It is an attack scenario that cannot be mitigated on this level, but at least clients would notice that sync packets are not coming through, and as Daniel explained, they can also spot an increased RTT and could send alarms etc. 

> leaf clients converting to UTC.

That is correct, this is why the draft protects announce messages just like it protects sync and delay req/resp messsages. Any modification of a PTP packet in transmit by an attacker has the potential to cause harm and could degrade the sync service that is vital for a critical application like a power grid, a telecommunications network or an air traffic radar system. 

I therefore kindly ask you and the other WG members to support adoption of the draft. The team of authors is willing to put all the resources into finalizing the draft in the shortest possible timeframe. 

Best Regards,
   Heiko

-- 
Heiko Gerstung 
Managing Director 

 
Email: 

Connect via LinkedIn:

---

From: Daniel Franke <[email-masked]>
Date: Thu, 27 May 2021 12:43:45 -0400

> There is a RTT calculation, and a PTP client uses RTT/2 as a correction for the incoming sync messages.

I'm pretty sure I already understand. In the case of both NTP and PTP,
you have a calculation like

theta = ((t2-t1) + (t3-t4))/2

In NTP, there's just one exchange that gives you all four timestamps.
In PTP, you use DELAY_REQ/DELAY_RESP just for t2 and t1, and then you
get t3 and t4 from the SYNC message.
Trying to do without the SYNC message would give you bad results,
because there's no hardware timestamp on DELAY_RESP to give you t3, so
you'd be forced to treat t3 as equal to t2 or t2 plus some assumed
processing delay.

And then your maximum error bounds are ±((t4-t1) - (t3-t2))/2. Err,
okay, I guess that still works out when you do it with separate
messages? (t4-t1) will be big, but so will (t3-t2) so they'll cancel
each other. But by "works out" I still mean "works out to ±half-RTT".
It is not possible to improve on this.

> I try again to explain what I believe you are missing here. Any application that requires sync has a minimum requirement for synchronization, i.e. any time error greater than this limit is going to…

People who have these kinds of requirements *must* physically secure
the network links they use for time synchronization. NTS cannot
provide anything that will help them. My proposal won't do what they
need, and neither will yours. I know you have customers clamouring for
a solution and that you want to give them one, but it is simply. not.
possible.

> OK, you just changed your principal reason why you object to adopting the draft after it seems I convinced you that the initial reasons why you object adoption of the draft do not exist. I am a lit…

Yes, at first my biggest objection was "this won't work". You've now
offered some clarifications and accepted some corrections that would
allow it to work about as well as my alternative, but still not nearly
as well as you claim it will and not nearly well enough to satisfy the
use cases you've described in the previous quote. And so different
objections rise to the top.

> I am puzzled that your main reason is that you believe this is a lot of work for a lot of people. Three people with a lot of experience in both NTP and PTP already put a lot of work into this draft…

Your proposal reuses some parts of NTS4NTP but still involves a lot of
new work, probably including building new silicon. Mine reuses all of
them. NTS4NTP was a lot of work for a lot of benefit, and part of that
benefit is that it gives us a nearly-trivial way to also secure PTP.
Sure, "this is a lot of work for little benefit" is an argument that
can be deployed against any new standard, but sometimes it's true and
sometimes it isn't!

> Nope. There is nothing available *TODAY* that comes even close. You are comparing apples and oranges. The draft offers the same level of protection against cybersecurity threats that are covered by…

NTS4UPTP does *not* maintain sub-microsecond precision under
adversarial conditions. You are making an impossible claim. I can't
yet tell you exactly where your error in reasoning is, because you
haven't specified the client behavior in enough detail to give me a
stationary target to pick apart. If you'd care to explain exhaustively
what checks and calculations you expect the client to perform, and
what better-than-half-RTT bounds you claim to be achieving, I'll
happily reciprocate with an equally detailed protocol trace that
illustrates how an adversary can mount a delay attack in order to feed
the client time that passes your checks but falls outside your
asserted bounds.

> I doubt that this is possible with unicast PTP. I kindly ask you to explain how you want to achieve that without a major redesign of the protocol, at which point it would not be PTP anymore.

That's easy. You just need to require the client to prove that it's
actually able to receive traffic at its claimed address before you
send any significant traffic in that direction. You can do this by
sending the client a random or pseudorandom token that it's required
to echo back before you'll send it anything else, and periodically
repeating this challenge to prove that it's still there. You can do
this with no cryptography at all, or with just a little bit by having
the token be a MAC over the client's network address and a timestamp,
computing using a key known only to the server. The advantage of
constructing it this way is that the server doesn't have to hold any
state related to the client until it has already passed the challenge,
because it can recompute the challenge token rather than having to
store it.

---

From: Heiko Gerstung <[email-masked]>
Date: Fri, 28 May 2021 09:33:55 +0200

Hi Daniel,

sorry for top-posting, I try to summarize your arguments in this discussion (and please correct me if I misunderstood something):

You object adopting the draft that my colleagues and I submitted because:
1) you expect that working on this will require a lot of work for a lot of people
2) you think that using NTS4NTP in combination with Unicast PTP can provide a solution to the problems we want to solve with NTS4UPTP
3) you think that 2) is true because PTP could not guarantee a higher level of time accuracy in any network, mainly due to the fact that you consider RTT as the limiting factor and because there is no way to defend RTT against a MITM that is capable of delaying packets
4) you assume that because of 3) any user with a requirement that can only be fulfilled with PTP has to physically secure their network anyway to be protected against delay attacks and therefore there is no point in securing unicast PTP against any other security threats and types of attacks

Is that correct? Did I miss something?

Best Regards,
  Heiko

-- 
Heiko Gerstung 
Managing Director 

 
Email: 

Connect via LinkedIn: 

Am 27.05.21, 18:44 schrieb "ntp im Auftrag von Daniel Franke" <[email-masked] im Auftrag von [email-masked]>:

    _______________________________________________
    ntp mailing list
    [email-masked]
    https://www.ietf.org/mailman/listinfo/ntp

---

From: Kai Heine <[email-masked]>
Date: Fri, 28 May 2021 15:10:36 +0200

Hi all,

I think that there is definitely a need for security in PTP, so I am 
generally in favor of the WG adopting some kind of NTS-for-PTP.
I've seen that there are already multiple proposed solutions that have 
been presented here, each with their own discussions.

What are the principal objectives a draft would have to fulfill in order 
to be adopted?

Best regards,
Kai

-- 

Kai Heine, M.Eng.
Wissenschaftlicher Mitarbeiter
Fakultät Elektrotechnik

Ostfalia Hochschule für angewandte Wissenschaften
- Hochschule Braunschweig/Wolfenbüttel
Salzdahlumer Straße 46/48
38302 Wolfenbüttel

Tel.:     +49 5331 939 43650
Fax:      +49 5331 939 43652
E-Mail:   [email-masked]
Internet: https://www.ostfalia.de/cms/de/pws/heine

---

From: Daniel Franke <[email-masked]>
Date: Fri, 28 May 2021 09:25:55 -0400

> Is that correct? Did I miss something?

You have the gist of it, but there's a nit about (2) and an important
bit of nuance about (4).

On (2), the hybrid NTS4NTP/PTP solution isn't limited to unicast PTP.
It works just as well with broadcast/multicast. Of course the NTS4NTP
part still has to be unicast NTP.

On (4): "security threats and types of attacks" is kind of vague. I'd
rather think of this in terms of goals and adversary powers, and this
leads to two questions that I'm open to being persuaded on:

1. Are there goals beyond protecting the integrity of time
synchronization that NTS4UPTP can serve but hybrid NTS4NTP/PTP can't?

2. Are there any interesting classes of adversary weaker than the
standard MitM adversary, from whom NTP4UPTP can provide stronger
protection than hybrid NTS4NTP /PTP can?

Question 1 is what I already raised upthread when I mentioned
anti-amplification, protecting management functions, etc.

Question 2 is something I raised in the original thread about hybrid
NTS4NTP/PTP. Any attacker who is on-path or adjacent to one of the
endpoints can set itself up as a MitM and therefore conduct delay
attacks. Off-path attackers, on the other hand, can't read or modify
legitimate traffic but may be able to inject packets with spoofed
source addresses. With hybrid NTS4NTP/PTP, such an adversary can
potentially do just as much damage as a MitM can, injecting SYNC
messages that fall just inside the window of plausibility and inducing
a half-RTT error. With NTS4UPTP, such packets could be rejected
because the attacker wouldn't be able to forge the MAC tag; an
off-path attacker isn't capable of moving us from the "normal" case of
sub-microsecond precision to the "adversarial" case of half-RTT
precision. However, I don't find this argument compelling enough,
because in realistic PTP deployments. the problem of off-path
attackers should already be adequately mitigated by firewalls. Your
network is very broken if an outside attacker can spoof your PTP
server's network address and have that spoofed packet make it all the
way to clients rather than being dropped at your router. You couldn't
rely on firewalls this way if you were running PTP over the open
internet, but that's not how people use PTP.

---

From: [email-masked]
Date: Mon, 31 May 2021 17:28:05 +0200

Hello all,

I have a very similar stance to that of Kai here.

The WG should (to my mind) definitely discuss some security solution for PTP that is based on NTS.

As someone who is also involved in the security subcommittee of the 1588 WG, I feel that it might be important to clarify the following:

PTP has a method of transporting authentication tags in a TLV field, specified in the current standard version.

What is "missing" is a key management scheme that enables the use of those security TLVs (there are some, but I feel that one based on NTS' methods would be really nice to have).

So far, AFAIK, Heiko's draft is the only document that has actually been proposed here.

I'm sorry, but I haven't read it closely enough to judge its technical merits.

But (especially in light of recent discussions), I'm wondering what the alternative to adoption is, process-wise.

@daniel: you talk about a proposal of yours that is in competition with Heiko's draft, I believe.

Now  this might be a dumb question, but where can I find that?

There is also work from folks at Ostfalia, that also has to do with using parts of NTS to do the key management for PTP security.

Once they are ready to propose it as a document here, this effort also definitely deserves consideration.

Until then, I believe I support adoption of Heiko's draft (except if there is a good argument to be made that we need to look at all candidates first and then choose one?).

The approach certainly seems to have enough merit for at least a WG-wide discussion.

I also feel that I would like to hear more people's opinions, especially more who don't have a candidate of their own in this race.

Best regards,

Kristof

-----"ntp" <[email-masked]> schrieb: -----

An: <[email-masked]>
Von: "Kai Heine"
Gesendet von: "ntp"
Datum: 28.05.2021 15:11
Betreff: Re: [Ntp] NTS4UPTP Rev 03 - Formal request for WG adoption

Hi all,

I think that there is definitely a need for security in PTP, so I
 am generally in favor of the WG adopting some kind of NTS-for-PTP.
I've seen that there are already multiple proposed solutions that
 have been presented here, each with their own discussions.

What are the principal objectives a draft would have to fulfill in
 order to be adopted?

Best regards,
Kai

--

Kai Heine, M.Eng.

Tel.:     +49 5331 939 43650
Fax:      +49 5331 939 43652

---

From: Daniel Franke <[email-masked]>
Date: Mon, 31 May 2021 13:21:25 -0400

> Now  this might be a dumb question, but where can I find that?

My proposal is what's described here; I believe you were on the
thread: https://mailarchive.ietf.org/arch/msg/ntp/-gQcQH915bf7NFTCjJ8LfVe8aa4/

There's no associated I-D right now. I'd be happy to turn it into one
(with Informational intended status) if the WG thinks that would be
useful. If I do, I'd like to have a coauthor (someone who's worked
with IEEE1588 more closely than I have) to write the section on how to
process PTP packets once a plausible interval has been computed.