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

From: Miroslav Lichvar <[email-masked]>
Date: Tue, 1 Jun 2021 11:47:24 +0200

On Wed, May 26, 2021 at 10:31:22AM +0200, Heiko Gerstung wrote:
> I just submitted the latest revision of our NTS for Unicast PTP draft (-02) which you can find here:
> 
> https://datatracker.ietf.org/doc/draft-gerstung-nts4uptp/

Here are my thoughts.

I'm missing some background of the draft. What is the issue of the
solutions described in IEEE1588, like authentication with manually
distributed symmetric keys and security mechanisms implemented at
lower layers like MACsec and IPsec, that this draft is supposed to
address?

In NTP, NTS is mainly about scaling to large numbers of clients and
privacy. None of that applies to the PTP unicast mode. Due to the
infinite amplification factor and susceptibility to DoS attacks
clients have to be authorized, so I think even the need of public-key
crypto should be explained. Is it supposed to make management of PTP
in a network easier or more secure by distributing certificates
instead of symmetric keys?

I'm missing some description on whether/how this is supposed to work
with transparent clocks. In the IEEE1588 terms, is the correction
field considered mutable?

As you already have to keep a client-specific state, I'd say an
obvious question is why not use an existing application payload
security protocol like DTLS? The draft would basically turn into
"Exchange PTP messages over DTLS on ports X and Y".

If you needed to support transparent clocks and/or keep compatibility
with some existing hardware than can timestamp only specific messages
on the standard PTP event port, you could use DTLS only for general
messages and add a single TLV to get the key needed for authentication
of event messages. I think that would still be easier to implement
(using an existing DTLS implementation) and have a much simpler
specification than what you are currently proposing.

As for that issue with detecting delay attacks that Daniel brought up,
I think that might be better to have its own draft as it applies to
all PTP modes and all security mechanisms, even those at lower layers,
if the existing documents (e.g. IEEE1588 and RFC 7384) are not
sufficient.

-- 
Miroslav Lichvar

---

From: Heiko Gerstung <[email-masked]>
Date: Tue, 1 Jun 2021 13:14:57 +0200

> Am 01.06.21, 11:47 schrieb "Miroslav Lichvar" <[email-masked]>:
> 

First of all: manually distributing symmetric keys is something that is already foreseen and possible with PTP, using the integrated security as described in IEEE1588. However, this does not address the potential amplification and replay attacks as described in the draft. Plus, a manual distribution of symmetric keys is only feasible until a certain number of clients. Keys have to be refreshed in a certain interval to avoid that someone not trustworthy found a way to obtain the keys, and distribution requires to establish a secure way of distributing the keys. 

Although there are already a number of key exchange protocols in use today, NTS4NTP introduced a new approach and had some good reason to do so (e.g. unlinkability). To me it is a reasonable approach to reuse that key exchange mechanism for PTP, simply because the two protocols are addressing the same type of service and can be found next to each other in a lot of networks. 

Second point: why not using IPsec or MACsec? Here the problem is the hardware timestamping mechanism. A PTP timestamping engine typically sits in the PHY or the MAC of the network chip or, in 2-step implementations, very often between those two. The timestamper looks out for PTP event messages passing by and it takes a timestamp when it detected a packet. It does so in wire speed, no matter whether we are looking at a 100Mbit/s or a 1Gbit/s or 10Gbit/s network interface. If you encapsulate PTP messages into an encrypted communication protocol, the hardware timestamper cannot see the PTP messages anymore and therefore you lost your hardware timestamping capability, the main feature that allows PTP to achieve sub microsecond accuracy. The only solution here would be to either timestamp every packet or use a flag in the lower layer protocol that indicates that this frame should be timestamped (and you need an ID to later identify the timestamp in the queue when you are looking for a matching hardware timestamp for the packet in layer 7). This requires long timestamping queues (timestamping all packets) and/or opens a new attack vector (sending a lot of dummy packets with the "timestamp me!" flag set to flood the queue). Just as an illustration: A commercially available 40Gbit/s network adapter from a famous manufacturer today has a timestamping queue size of 4 (in words: four) timestamps, and therefore can only be used in a client with low PTP message rates. It would be easy to flood and overrun the queue and therefore would require serious changes in the silicon of almost every PTP capable NIC. 

> instead of symmetric keys?

There are large scale unicast PTP applications, too. Think about tens of thousands of cellular basestations for mobile data communication (e.g. nationwide 4G and 5G mobile phone networks) or hyperscale datacenters with thousands of PTP unicast clients. Distributing symmetric keys manually in these scenarios would be an operational (and security) nightmare. Asymmetric cryptography eases the pain because you probably do not have to refresh the certificates as often as you have to refresh symmetric keys. 

> field considered mutable?

Transparent clocks are a nightmare from a security standpoint and they are typically not used in those networks that are using unicast PTP. Additionally, although the concept of transparent clocks has been introduced in IEEE1588-2008, I do not know any commercially available router or switch that supports acting as a unicast PTP transparent clock. 

Solving the problem of a number of switches changing a field in the packet at wirespeed while it travels from a node to another node without leaving a trace is complex. One solution would be to use the PTP security mechanism by adding a correction field (in a separate TLV) after the first AUTHENTICATION_TLV in the payload of the message and add another AUTHENTICATION_TLV whose ICV would then protect the initial message and the initial message + correction TLV, or, alternatively, just the correction TLV (I am not sure if this would be allowed in PTP).  This way, a TC could pass on the first part of the PTP message without modification, read out the correction value from that newly introduced correction TLV and add its own residence time value to it. Afterwards it has to recalculate the ICV of the trailing AUTHENTICATION_TLV. 

This is possible, but it would require all TCs to share a separate symmetric key with all clients, thus requiring some effort to ensure key freshness etc. Based on our experience regarding the lack of interest of switch vendors to add unicast TC capabilities to their products (low to zero demand at this point because of the security challenges of unicast PTP), I consider this a chicken-and-egg problem and would probably address this in the next revision. But I agree that we should add a short paragraph explaining the TC problem to users and recommend to not using them until there is a solution for it. 

> "Exchange PTP messages over DTLS on ports X and Y".

Same as using IPsec/MACsec, you would lose the hardware timestamping. 

> specification than what you are currently proposing.

It still would not address the amplification attack scenario and keeps the door wide open for abusing unicast PTP for replay based amplification DDoS scenarios. It would be simpler, but with our more complex approach we can address those security problems, too. 

> if the existing documents (e.g. IEEE1588 and RFC 7384) are not

I would say that it is more like a general concept (use an alternative secure way to establish error bounds of your unsecure primary time sync protocol) and I would agree that a description of it might be well placed in the NTS concept document that Kristof proposed.

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: Miroslav Lichvar <[email-masked]>
Date: Tue, 1 Jun 2021 14:00:57 +0200

> First of all: manually distributing symmetric keys is something that is already foreseen and possible with PTP, using the integrated security as described in IEEE1588. However, this does not addres…

Great. Please add that to the draft.

> Second point: why not using IPsec or MACsec? Here the problem is the hardware timestamping mechanism. A PTP timestamping engine typically sits in the PHY or the MAC of the network chip or, in 2-step implementations, very often between those two. The timestamper looks out for PTP event messages passing by and it takes a timestamp when it detected a packet

As you probably know, not all NICs do that. Some can provide a
timestamp with each received frame at no cost except that extra bit of
data that needs to be received over PCIe etc. My understanding is that
this is the trend for future as there are other applications, not
related to synchronization of clocks, that need accurately timestamped
packets.

> Transparent clocks are a nightmare from a security standpoint and they are typically not used in those networks that are using unicast PTP. Additionally, although the concept of transparent clocks…

The network devices don't need to have the keys if the correction
field is excluded from the ICV calculation (as allowed by the PTP
spec). The security impact is not that too different from a delay
attack. If you don't want to support that, that's ok, but it needs to
be explained in the draft.

> It still would not address the amplification attack scenario and keeps the door wide open for abusing unicast PTP for replay based amplification DDoS scenarios. It would be simpler, but with our mo…

Can you please elaborate? My (limited) understanding of DTLS is that
it would address the attacks. It has a 48-bit sequence number to
protect against replays and client authentication comes from TLS.

-- 
Miroslav Lichvar

---

From: Heiko Gerstung <[email-masked]>
Date: Tue, 1 Jun 2021 14:48:32 +0200

> 
> Am 01.06.21, 14:01 schrieb "Miroslav Lichvar" <[email-masked]>:
> 
>> First of all: manually distributing symmetric keys is something that is al
>> ready foreseen and possible with PTP, using the integrated security as described
>> in IEEE1588. However, this does not address the potential amplification and rep
>> lay attacks as described in the draft. Plus, a manual distribution of symmetric
>> keys is only feasible until a certain number of clients. Keys have to be refresh
>> ed in a certain interval to avoid that someone not trustworthy found a way to ob
>> tain the keys, and distribution requires to establish a secure way of distributi
>> ng the keys.
> 
I will. 

>> Second point: why not using IPsec or MACsec? Here the problem is the hardw
>> are timestamping mechanism. A PTP timestamping engine typically sits in the PHY
>> or the MAC of the network chip or, in 2-step implementations, very often between
>> those two. The timestamper looks out for PTP event messages passing by and it t
>> akes a timestamp when it detected a packet
> 

I agree that this is a trend. SO_TIMESTAMP showed us the way on a software level here. However, changing silicon takes time and requires a huge commitment from the NIC manufacturers. I know how long it took to get HW timestamping support for PTP into at least most of the more famous NIC silicon and I will not hold my breath regarding this. 

>> Transparent clocks are a nightmare from a security standpoint and they are
>> typically not used in those networks that are using unicast PTP. Additionally,
>> although the concept of transparent clocks has been introduced in IEEE1588-2008,
>> I do not know any commercially available router or switch that supports acting
>> as a unicast PTP transparent clock.
> 

Yes, as I said I would leave protecting the correction field (i.e. supporting TCs) out of the draft, except for a short paragraph documenting this and give a reason why. Happy to add that to the draft and re-submit.

>> It still would not address the amplification attack scenario and keeps the
>> door wide open for abusing unicast PTP for replay based amplification DDoS scen
>> arios. It would be simpler, but with our more complex approach we can address th
>> ose security problems, too.
> 

I understood that you want to use DTLS to exchange the symmetric keys used to calculate the ICV of the unencrypted event messages. This unfortunately does not address the replay/amplification vulnerability of the unicast negotiation protocol itself, it just protects against replaying the DTLS messages. I most probably know much less about DTLS than you, Miroslav. For example, I do not know whether this requires asymmetric cryptography in every message or just at the beginning in the handshake. However, I am pretty sure that DTLS can be used to securely exchange the symmetric keys instead of using TLS in the NTS-KE phase. 

As I tried to explain earlier, our intention with this draft was to stay close to NTS4NTP to enable implementors to re-use code and allow users to combine the required infrastructure for NTS4NTP and NTS4UPTP. I fully agree that other protocols and security mechanisms would do the trick as well, but I believe that the name "Network Time Security" indicates that it has a good chance of being a better fit for securing a network time sync protocol. And, according to our research and our experience regarding network time synchronization, we came to the conclusion that this is the case for unicast PTP. 

We believe that our draft provides a solution to most of the security challenges for unicast PTP. It protects against packet manipulation from on-path and off-path adversaries. It supports authentication, identification, integrity and consistency, does not affect performance at all and is fully compatible with IEEE1588-2019 and its defined integrated security protocol. I am very sure we overlooked something or missed a point or we might have a flaw in one or more of our concepts and I would really like the WG and its members with all the security-expertise-firepower to review the draft and find those points in order to address them properly. If someone wants to create a proposal based on DTLS instead of NTS, I am happy to review it and compare it against our document.  If it turns out to be more efficient to implement and operate or is somehow more beneficial to implementors and end users, I am more than happy to support WG adoption of it and work on it. 

Best Regards,
   Heiko

-- 
Heiko Gerstung 
Managing Director 

 
Email: 

Connect via LinkedIn:

---

From: Miroslav Lichvar <[email-masked]>
Date: Tue, 1 Jun 2021 15:34:55 +0200

On Tue, Jun 01, 2021 at 02:48:32PM +0200, Heiko Gerstung wrote:
> I understood that you want to use DTLS to exchange the symmetric keys used to calculate the ICV of the unencrypted event messages. This unfortunately does not address the replay/amplification vulnerability of the unicast negotiation protocol itself, it just protects against replaying the DTLS messages.

The idea is that DTLS protects everything except the sync and delay
request messages. The unicast negotiation would be protected, of
course.

> I most probably know much less about DTLS than you, Miroslav. For example, I do not know whether this requires asymmetric cryptography in every message or just at the beginning in the handshake. However, I am pretty sure that DTLS can be used to securely exchange the symmetric keys instead of using TLS in the NTS-KE phase. 

DTLS is just a datagram-based version of TLS. Asymmetric crypto is
needed only on start. Performance would certainly not be an issue. I
suspect you are already reinventing some of its wheels, like the
replay protection.

> As I tried to explain earlier, our intention with this draft was to stay close to NTS4NTP to enable implementors to re-use code and allow users to combine the required infrastructure for NTS4NTP an…

Ok, if you need as much of NTS4NTP as possible and at the same time
keep accuracy provided by hardware timestamping as is supported in
current hardware, I think the solution is simple: NTS4NTP over PTP.

You can wrap NTP messages in a PTP event message to get hardware
timestamps and keep all the benefits of NTS4NTP. It seems your plan is
to provide NTS4NTP in any case. Do you see any disadvantages?

This would be a very short draft and it would be useful even for
plain NTP without NTS. I think I'll give it a shot.

-- 
Miroslav Lichvar

---

From: Heiko Gerstung <[email-masked]>
Date: Tue, 1 Jun 2021 16:18:09 +0200

> Am 01.06.21, 15:35 schrieb "Miroslav Lichvar" <[email-masked]>:
> 
>> I understood that you want to use DTLS to exchange the symmetric keys used
>> to calculate the ICV of the unencrypted event messages. This unfortunately does
>> not address the replay/amplification vulnerability of the unicast negotiation p
>> rotocol itself, it just protects against replaying the DTLS messages.
> 

OK, that is something you have to describe in detail. 

>> I most probably know much less about DTLS than you, Miroslav. For example,
>> I do not know whether this requires asymmetric cryptography in every message or
>> just at the beginning in the handshake. However, I am pretty sure that DTLS can
>> be used to securely exchange the symmetric keys instead of using TLS in the NTS
>> -KE phase.
> 

OK, thanks for the explanation, I expected this to be the case but was not sure. And yes, we had to come up with solutions for replay protection etc. which most probably have been describe in a similar format. 

>> As I tried to explain earlier, our intention with this draft was to stay c
>> lose to NTS4NTP to enable implementors to re-use code and allow users to combine
>> the required infrastructure for NTS4NTP and NTS4UPTP. I fully agree that other
>> protocols and security mechanisms would do the trick as well, but I believe that
>> the name "Network Time Security" indicates that it has a good chance of being a
>> better fit for securing a network time sync protocol. And, according to our res
>> earch and our experience regarding network time synchronization, we came to the
>> conclusion that this is the case for unicast PTP.
> 
:-)

> to provide NTS4NTP in any case. Do you see any disadvantages?

Yes, because unicast PTP does not work in the same way as NTP. NTP is based on a request/response exchange while unicast PTP is not. I would certainly be possible to put NTP4NTS messages into PTP, but that would have the same drawback that I see with Daniel's proposal to use NTP4NTS to secure the time error of PTP: you need to setup an NTS4NTP infrastructure and basically run two sync protocols plus one security/key exchange protocol in parallel. NTS4UPTP only requires you to run one sync protocol and a key exchange protocol. 

I would also not be happy with the efficiency, because an NTS4NTP packet probably has some redundant or unnecessary information in it that is not required when I run unicast PTP. And, the other way around, adding a full "dummy" PTP packet header to enable using the hw timestamping engine to hardware timestamp my NTS4NTP packets is a waste of bandwidth and CPU cycles. 

Such a NTS4NTP protocol also does not address the other advantage that unicast PTP has over NTP: higher packet rates. You can change that too, of course. In the end you created a third time sync protocol which to me looks more like a Frankenstein monster version of NTP/PTP and is a completely different beast. It will be neither compliant to NTP, nor PTP. It may work and add more accuracy to NTP4NTS, but has nothing to do with PTP. And yes, you can argue that nobody needs PTP anymore in that case, but I am not sure it will be a pleasant discussion.

> plain NTP without NTS. I think I'll give it a shot.

Why not. But again, this is not solving the problem of securing unicast PTP and therefore can be a nice addition to NTP/NTS4NTP, but addresses a different topic than what we proposed. 

Regards,
   Heiko

-- 
Heiko Gerstung 
Managing Director 

 
Email: 

Connect via LinkedIn:

---

From: Miroslav Lichvar <[email-masked]>
Date: Tue, 1 Jun 2021 17:42:03 +0200

> OK, that is something you have to describe in detail. 

The PTP general port (320) would move to a new port, which would be
protected by DTLS. The client would open a DTLS session with the
server on that port and use it for all messages normally transmitted
on the general port. The key needed for authentication of event
messages could be generated by the client and provided to the server
in a new TLV together with the request-unicast-transmission TLV. The
server would use the key to authenticate sync messages for the client
and verify ICV in its delay requests. Just the first thing that came
to my mind. I'm sure it could be improved.

> Yes, because unicast PTP does not work in the same way as NTP. NTP is based on a request/response exchange while unicast PTP is not. I would certainly be possible to put NTP4NTS messages into PTP,…

If you used only NTP4NTS over PTP, you would still have only one sync
protocol. Just the transport is different. That's a couple lines of
code.

> I would also not be happy with the efficiency, because an NTS4NTP packet probably has some redundant or unnecessary information in it that is not required when I run unicast PTP. And, the other way…

If you compare the PTP header to the NTS uniq ID and cookie, I don't
think it's so bad.

> Such a NTS4NTP protocol also does not address the other advantage that unicast PTP has over NTP: higher packet rates. You can change that too, of course. In the end you created a third time sync protocol which to me looks more like a Frankenstein monster version of NTP/PTP and is a completely different beast. It will be neither compliant to NTP, nor PTP.

I'm not sure I follow here. You can send NTP requests at any rate you
like. That doesn't require a new protocol. The poll field is a signed
8-bit integer if you had a server that actually looked in the content
of the field.

Yes, server performance might be worse due to the need to decode and
encode a cookie with each request, but that's a price you need to pay
if you want all the benefits of NTS4NTP. I'd expect in most cases the
HW-timestamping to be the bottleneck. If not, you could use
AES-GCM-SIV instead of AES-SIV-CMAC for cookie encryption to get a
better performance.

> It may work and add more accuracy to NTP4NTS, but has nothing to do with PTP. And yes, you can argue that nobody needs PTP anymore in that case, but I am not sure it will be a pleasant discussion.

Right. :)

-- 
Miroslav Lichvar

---

From: Danny Mayer <[email-masked]>
Date: Tue, 1 Jun 2021 13:24:24 -0400

> 8-bit integer if you had a server that actually looked in the content

I hope not. How would you implement a negative poll interval? :)

It really should be unsigned. If not, then that's really an error.

Danny

---

From: Daniel Franke <[email-masked]>
Date: Tue, 1 Jun 2021 13:28:57 -0400

It's in units of log2(seconds) so a negative value makes fine sense. E.g.
-1 means half a second.

On Tue, Jun 1, 2021, 13:24 Danny Mayer <[email-masked]> wrote:

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

---

From: Daniel Franke <[email-masked]>
Date: Tue, 1 Jun 2021 13:37:21 -0400

Anyway, I believe I explained early last April how a negative polling
interval might be implemented :-P

---

From: Danny Mayer <[email-masked]>
Date: Tue, 1 Jun 2021 13:54:24 -0400

Noone should be using a polling interval that small. Oversampling is as 
bad as undersampling.

Danny

On 6/1/21 1:28 PM, Daniel Franke wrote:
> It's in units of log2(seconds) so a negative value makes fine sense. 
> E.g. -1 means half a second.
>
> On Tue, Jun 1, 2021, 13:24 Danny Mayer <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>
>     [email-masked] <mailto:[email-masked]>
>     <https://www.ietf.org/mailman/listinfo/ntp>
>
>

---

From: Daniel Franke <[email-masked]>
Date: Tue, 1 Jun 2021 14:03:06 -0400

Depends on your clock discipline algorithm. Yes, if you feed an excessive
number of samples into a underdamped PLL then your clock is just going to
bounce around a lot without ever getting more accurate. But e.g. a Kalman
filter should happily slurp up as many samples as you throw at it. Having
more information can't be bad unless you use it badly.

On Tue, Jun 1, 2021, 13:54 Danny Mayer <[email-masked]> wrote:

> ntp mailing [email-masked]://www.ietf.org/mailman/listinfo/ntp
>
>

---

From: Danny Mayer <[email-masked]>
Date: Tue, 1 Jun 2021 14:48:59 -0400

That ignores the fact that you are bombarding the servers with requests 
at a very high rate. There's a very good reason why we implemented KOD 
packets. You wouldn't want to put any of those responses through a filter.

Danny

On 6/1/21 2:03 PM, Daniel Franke wrote:
> Depends on your clock discipline algorithm. Yes, if you feed an 
> excessive number of samples into a underdamped PLL then your clock is 
> just going to bounce around a lot without ever getting more accurate. 
> But e.g. a Kalman filter should happily slurp up as many samples as 
> you throw at it. Having more information can't be bad unless you use 
> it badly.
>
> On Tue, Jun 1, 2021, 13:54 Danny Mayer <[email-masked] 
>     Noone should be using a polling interval that small. Oversampling
>     is as bad as undersampling.
>
>     Danny
>
>>     It's in units of log2(seconds) so a negative value makes fine
>>     sense. E.g. -1 means half a second.
>>
>>     https://www.ietf.org/mailman/listinfo/ntp  <https://www.ietf.org/mailman/listinfo/ntp>
>
>

---

From: Daniel Franke <[email-masked]>
Date: Tue, 1 Jun 2021 15:27:25 -0400

> to provide NTS4NTP in any case. Do you see any disadvantages?

All these long and similar initialisms for the various PTP security
proposals are getting unmanageable, so I'm going to create some new
ones:

* I'm going to start calling my proposal NSCoPE, for NTP Securely
Constraining PTP Errors.

* I'm going to call Miroslav's proposal PEN, for PTP-Encapsulated NTP.

* I'll keep using NTS4NTP for RFC 8915, NTS4UPTP for the
Gerstung-Rohde-Arnold draft, and NTS4PTP for the Langer-Bermbach
draft.

I agree with Miroslav that PEN likely requires a lot less development
effort than NTS4UPTP does, but it still requires changes to both the
server and the client, unlike NSCoPE which can be implemented
unilaterally on the client. There's a tremendous gulf between changing
one line of code on the server and changing zero. A one-line change
requires a full-blown standards-track effort involving multiple
standards bodies, interop testing between vendors, and lots of network
infrastructure that needs upgrading, even if the upgrade is just a
firmware patch. If only client-side changes are needed, none of this
coordination is required.

Maybe a better way to think of PEN is not as a security layer for PTP,
but rather as a way to improve the typical-case precision of NTP by
adding hardware timestamps. It strikes me as a better alternative to
interleaved mode, one which avoids the need for server state or for
sending follow-up packets. It's hardly PTP at all; the fact that
responses come back framed as PTP event messages is just a hack to get
existing hardware to cooperate. The fact that the NTP messages can use
NTS is pretty much incidental. You can do PEN with unauthenticated NTP
messages too and (as long as you're not under attack) get all the same
benefit to precision.

---

From: [email-masked]
Date: Tue, 1 Jun 2021 22:15:01 +0200

I think that is a helpful suggestion.

Thanks, Daniel!

I'll suggest to slightly modify the name of the Langer-Bermbach draft to something that more accurately represents a pretty important difference:
Most suggestions here seem to attempt to offer more or less complete solutions from zero to "full" security, while (AFAIK, I'm not very familiar with the 69 page document) this proposal seeks "only" to find a mechanism to do the key management for the PTP standard-defined security TLV solution.

So perhaps something like "NTS4PTP-KE" or "PTPsec/NTS", or even something with 1588 in the name that I can't come up with on the spot, because it is IMO most closely tied to the current 1588 standard document.

Also, apologies that I somehow thought the approach hadn't been suggested here.

I've heard a lot about it on channels other than this mailing list recently, and apparently got confused.

(I was also thinking that it might be helpful to somehow find and agree on suitable monikers for using the defined PTP security TLV with different key management schemes, such as "PTPsec/GDOI" and "PTPsec/TESLA"; but that is a discussion for another WG I guess.)

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

An: "Miroslav Lichvar" <[email-masked]>
Von: "Daniel Franke"
Gesendet von: "ntp"
Datum: 01.06.2021 21:28
Kopie: "[email-masked]" <[email-masked]>, "Heiko Gerstung" <[email-masked]>
Betreff: Re: [Ntp] NTS4UPTP Rev 03 - Formal request for WG adoption

---

From: [email-masked]
Date: Tue, 1 Jun 2021 22:42:16 +0200

I mean, you can call anything PTP if you get the 1588 WG to mention it in the next standard version, I guess.
Honestly, this whole idea has potential.

A low-effort (and low-complexity, in the spec) version would be one very good result.

P.S.:

A well-made Frankensteined construct would potentially be a breakthrough.

If we could come up with something that combines the following properties, that would be a dream come true:

- Can use hardware timestamping (with existing PTP hardware!)

- Uses two-way exchange with bounded error of RTT/2

- Has guaranteed authenticity/integrity and thus (because of bullet above) guaranteed correctness of synch except for a bounded error

- Uses two-step scheme on messages going from the time emitter to the time receiver, thus offering zero (!) performance detriment (on the individual exchange) from crypto

I am currently busy working on ways of defining and measuring the tradeoffs between accuracy, security and convenience that you have to make when choosing a time transfer mechanism.

It would be very nice to have something that circumvents at least one of the tradeoff dimensions.

Somewhere between making (a subset of) PTP behave like client/server NTP except with two-step responses, slapping NTS onto it and making it run on PTP hardware, there has to be a way of doing this, doesn't there?

An: "Heiko Gerstung" <heiko.gerstung=[email-masked]>
Von: "Miroslav Lichvar"
Gesendet von: "ntp"
Datum: 01.06.2021 17:42
Kopie: "[email-masked]" <[email-masked]>
Betreff: Re: [Ntp] NTS4UPTP Rev 03 - Formal request for WG adoption

Right. :)

--
Miroslav Lichvar

---

From: Daniel Franke <[email-masked]>
Date: Tue, 1 Jun 2021 16:59:35 -0400

> A well-made Frankensteined construct would potentially be a breakthrough.

Is there anyone on this list named Stein who'd like to work with me on this?

---

From: [email-masked]
Date: Tue, 1 Jun 2021 23:06:03 +0200

I know a few people with the name.
We're each happily married, though, so the formalities of taking their last name might make for a bad time.

An: [email-masked]
Von: "Daniel Franke"
Gesendet von: "ntp"
Datum: 01.06.2021 23:00
Kopie: "Heiko Gerstung" <heiko.gerstung=[email-masked]>, "Miroslav Lichvar" <[email-masked]>, "[email-masked]" <[email-masked]>
Betreff: Re: [Ntp] Antwort: Re: NTS4UPTP Rev 03 - Formal request for WG adoption

---

From: Doug Arnold <[email-masked]>
Date: Tue, 1 Jun 2021 23:43:38 +0000

I think that it is clumsy to bring in another protocol to add security to the one of interest.  Why not just add the same functionality to PTP?

Doug

From: ntp <[email-masked]> on behalf of Daniel Franke <[email-masked]>
Date: Tuesday, June 1, 2021 at 3:27 PM
To: Miroslav Lichvar <[email-masked]>
Cc: [email-masked] <[email-masked]>, Heiko Gerstung <[email-masked]>
Subject: Re: [Ntp] NTS4UPTP Rev 03 - Formal request for WG adoption

---

From: Doug Arnold <[email-masked]>
Date: Wed, 2 Jun 2021 00:15:12 +0000

Regarding delay attacks and PTP.

First, in most applications that include PTP, for example power substations, if a malicious agent takes over a switch or router in the network, then there might be 10 things they could do that are worse than manipulating the time.

That being said, PTP needs to have resistance to delay attacks, which won’t likely come from cryptography.  Approaches that are used or are being discussed are:

  *   Multiple PTP domains, and a voting algorithm.  In this case the PTP domains need to  have different network paths. An equivalent approach is measuring PTP clients using a reverse PTP mechanism through a different path than the time transfer path.
  *   Heuristic checks on incoming time compared to the stability of the local oscillator.  No sudden jumps, or ramps that are faster than the local oscillator drift rate.  This works best if the local oscillator is very stable or if physical layer syntonization is used.
  *   GNSS capable probes in the network to spot check the PTP accuracy, and report issues.
  *   Other means of verifying the time at the clients outside of PTP

What cryptography can do for PTP is prevent attacks by entities that have not taken over a switch or router, but have gained access to the network, such as impersonating a PTP server.

PTP is

From: ntp <[email-masked]> on behalf of Daniel Franke <[email-masked]>
Date: Wednesday, May 26, 2021 at 9:28 AM
To: Heiko Gerstung <heiko.gerstung=[email-masked]>, NTP WG <[email-masked]>
Subject: Re: [Ntp] NTS4UPTP Rev 03 - Formal request for WG adoption
(Resending to reply to the list)

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.

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.

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

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

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.

On Wed, May 26, 2021 at 4:31 AM Heiko Gerstung <heiko.gerstung=[email-masked]<mailto:[email-masked]>> wrote:
Dear fellow NTP working group members,

Based on our experience of more than 20 years (NTP) and 15 years of PTP based network time synchronization for quite a large number of different applications and industries, we believe that the proposed draft will increase the number of potential use cases for unicast PTP by adding serious and sound security mechanisms to this protocol. It will enable users in a large variety of areas to transport highly accurate and reliable time over wide area networks and hard to protect large-scale private networks.

Unicast PTP is a protocol that has been designed to be used in protected network environments and requires additional protection to allow using it in other types networks, i.e. the Internet or wide-area-networks where it is impossible to ensure that no malicious actor with access to the network can carry out various attacks. The proposed draft offers protection against most of the possible attacks.

The authors acknowledge that other variants of PTP, namely the multicast and hybrid (i.e. unicast and multicast) forms, need to be protected as well. However, those forms are rarely used over wide area networks and are much more common in local area networks and protected network environments. Securing multicast and hybrid PTP requires a more complex solution and our expectation is that the proposed standard for securing unicast PTP will be completed faster due to the fact that we built it on the work that already went into RFC8915. The similarities in the key exchange phase of the protocol also offer an efficient way to implement combined NTS4NTP and NTS4UPTP key exchange service daemons and therefore helps to simplify deploying secure time synchronization solutions that support NTP, PTP or both in parallel.

I therefore would like to formally request adoption of this draft by this working group and kindly ask you to review the draft, and send your questions, comments and general feedback to the WG and/or one of the authors of this draft.

Thank you and best regards,
  Heiko

--
Heiko Gerstung
Managing Director

Email:
[email-masked]<mailto:[email-masked]>
Web:
Deutsch https://www.meinberg.de
English https://www.meinbergglobal.com

Connect via LinkedIn:

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

---

From: Doug Arnold <[email-masked]>
Date: Wed, 2 Jun 2021 00:27:24 +0000

Sorry about the dangling PTP is at the end.  I hit send accidently,

I was going to say that PTP is … going to have a security mechanism, because industry is making it a requirement.  It would be easiest for implementers and network operators if it was as much like NTS as possible.  The NTP working group is the group in the best position to help solve this problem because you have just been through it for NTP, and because of the security expertise in the IETF.

Doug

From: ntp <[email-masked]> on behalf of Doug Arnold <doug.arnold=[email-masked]>
Date: Tuesday, June 1, 2021 at 8:15 PM
To: Daniel Franke <[email-masked]>, Heiko Gerstung <heiko.gerstung=[email-masked]>, NTP WG <[email-masked]>
Subject: Re: [Ntp] NTS4UPTP Rev 03 - Formal request for WG adoption
Regarding delay attacks and PTP.

PTP is

--
Heiko Gerstung
Managing Director

Email:

Connect via LinkedIn:

---

From: "Ulrich Windl" <[email-masked]>
Date: Wed, 02 Jun 2021 08:14:18 +0200

>>> Danny Mayer <[email-masked]> schrieb am 01.06.2021 um 19:24 in
Nachricht <[email-masked]>:

>> 8‑bit integer if you had a server that actually looked in the content
>> of the field.
> 

Well actually 2^x remains positive even if x is negative ;-)

---

From: Heiko Gerstung <[email-masked]>
Date: Wed, 2 Jun 2021 08:23:58 +0200

OMG that would be awesome :-D ... I am tempted to change my name for this ;-) ... I am sure my wife will understand (famous last words...)!

Regards,
  Heiko

-- 
Heiko Gerstung 
Managing Director 

 
Email: 

Connect via LinkedIn: 

Am 01.06.21, 23:00 schrieb "ntp im Auftrag von Daniel Franke" <[email-masked] im Auftrag von [email-masked]>:

---

From: Heiko Gerstung <[email-masked]>
Date: Wed, 2 Jun 2021 09:02:33 +0200

> Von: ntp <[email-masked]> im Auftrag von <[email-masked]>

> Datum: Dienstag, 1. Juni 2021 um 22:42

> An: Miroslav Lichvar <[email-masked]>

> Cc: Heiko Gerstung <heiko.gerstung=[email-masked]>, "[email-masked]"

> <[email-masked]>

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

> I mean, you can call anything PTP if you get the 1588 WG to mention it in the ne

> xt standard version, I guess.

Yes, maybe. But from experience I can say that it is not that easy to get something into the next standard ;-)

> A low-effort (and low-complexity, in the spec) version would be one very good re

> sult.

It would certainly be an improvement for NTP accuracy. You might be wrong on the “low-effort” and “low-complexity” part, though.

> If we could come up with something that combines the following properties, that

> would be a dream come true:

> - Can use hardware timestamping (with existing PTP hardware!)

I am still a bit sceptic here, because I know that there is no standardized way how a hardware timestamper operates. Each hardware implementation has its own self-defined interface how to read out the timestamps in userspace and there are a few different packet matcher implementations available which look at different fields / parts of an incoming/outgoing packet to determine whether they have to take a timestamp or not. For IPv4/IPv6 implementations there is most likely the UDP destination port number, but some hw timestamping implementations look at other header fields in addition to that. There are also different identifiers that such a timestamping engine stores in its queue (and expects as “search criteria” when someone is looking for a timestamp for a specific packet), most likely they expect you to ask for a sequenceId, messagetype and source IP address combination, but again there might be other fields (PTP clockId or portId for example). 

I believe you cannot use 1-step  (which would most probably remove the requirement to deal with the software interface of a hw timestamper, because the hardware timestamps are written directly into the packet) because the timestamps for transmitted packets would be carried in the PTP part of the packet, which is unprotected by NTS4NTP. You could come up with adding an AUTHENTICATION_TLV and an ICV that is calculated by the hardware timestamper, but there is no such thing on the market (at least not widely available in COTS hardware). That might change once we have a serious security standard for PTP (hint, hint ;-) ..) but it will take most probably years before it hits your standard Intel/Broadcom/Marvell/<InsertYourFavouriteNICvendorHere> network chip of a COTS server/PC. 

On a server your hardware timestamper has to be synchronized by an external source, e.g. a GNSS receiver providing at least a PPS. The interface to set the time of the timestamper with very high precision is, you guessed it, not standardized and therefore has to be implemented for each hardware you want to use. 

Bottom line is: you have to add support for each hardware timestamping engine implementation your users should be able to use. Of course there are some which are more popular than others, but it is not going to be simple.

Please do not forget: PTP runs on TAI, you could use UTC instead in the timestamps and then have to deal with the occasional leapsecond or you run the hw ts engine on TAI to find out the UTC to TAI offset via a leap second file.

> - Uses two-way exchange with bounded error of RTT/2

Yes.

> - Has guaranteed authenticity/integrity and thus (because of bullet above) guara

> nteed correctness of synch except for a bounded error

Yes.

> - Uses two-step scheme on messages going from the time emitter to the time recei

> ver, thus offering zero (!) performance detriment (on the individual exchange) f

> rom crypto

OK.

> I am currently busy working on ways of defining and measuring the tradeoffs betw

> een accuracy, security and convenience that you have to make when choosing a tim

> e transfer mechanism.

> It would be very nice to have something that circumvents at least one of the tra

> deoff dimensions.

> Somewhere between making (a subset of) PTP behave like client/server NTP except

> with two-step responses, slapping NTS onto it and making it run on PTP hardware,

> there has to be a way of doing this, doesn't there?

Everything is possible (tm). From a vendor perspective I can say that we already offer hardware timestamped NTP for our customers, i.e. the timestamp in the outgoing and incoming NTP packets is modified in-flight at wirespeed, allowing us to claim an accuracy of 10ns in such a packet coming from one of our hardware NTP capable ports. The hardware timestamping is not NTS4NTP capable and changing that would require a lot of effort. I believe that Netnod implemented NTS4NTP in an FPGA and therefore would expect they use hardware timestamping already in their implementation. And I believe that might be a more feasible and logical way of adding accuracy to NTP4NTS. Spoiler alert: Whatever I personally believe does not necessarily have to be true.

Regards,

   Heiko

-- 

Heiko Gerstung 

Managing Director 

Lange Wand 9 

Email: 

Web: 

Connect via LinkedIn:

---

From: Miroslav Lichvar <[email-masked]>
Date: Wed, 2 Jun 2021 09:38:41 +0200

On Tue, Jun 01, 2021 at 02:48:59PM -0400, Danny Mayer wrote:
> That ignores the fact that you are bombarding the servers with requests at a
> very high rate. There's a very good reason why we implemented KOD packets.
> You wouldn't want to put any of those responses through a filter.

We are not talking about public servers here. These are protected
networks designed for highly accurate synchronization, where each link
has hardware timestamping on its ends and the jitter is on the order
of nanoseconds. With a 1000x smaller jitter you need a 1000x shorter
polling interval to fully take advantage of it, assuming everything
else is the same.

The server doesn't care if it has 100 million clients polling once per
1000 seconds, or 1000 clients polling 100 times per second. The load
is the same.

Of course, there is always a possibility that someone misconfigures
the client and floods a public server. There are safety mechanisms
that can be implemented to make that less likely. For example, chrony
doesn't switch to a sub-second polling interval unless the measured
peer delay is smaller than 10 milliseconds.

-- 
Miroslav Lichvar

---

From: Miroslav Lichvar <[email-masked]>
Date: Wed, 2 Jun 2021 09:47:31 +0200

> I was going to say that PTP is … going to have a security mechanism, because industry is making it a requirement.  It would be easiest for implementers and network operators if it was as much like…

The trouble is that PTP is very different from NTP. It's more like the
NTP broadcast mode, which the WG tried to cover in NTP, but ultimately
gave up. If the PTP folks want all of the security of NTS4NTP, they
need to add an NTP-like mode to PTP. A stateless mode where an event
message has an event response. You know, something like the Sync
Monitor extension specified by Meinberg.

-- 
Miroslav Lichvar

---

From: Heiko Gerstung <[email-masked]>
Date: Wed, 2 Jun 2021 13:00:27 +0200

> Am 01.06.21, 17:42 schrieb "ntp im Auftrag von Miroslav Lichvar" <ntp-bounces@ie
> tf.org im Auftrag von [email-masked]>:
> 

Yes, it needs to be fleshed out in more detail in a draft. My point is that you could use a different approach than what we chose in our proposal, but you then have to put this down in writing and submit a draft if you are convinced it has enought benefits when compared to our approach. If you believe it would be a lot shorter, more compact document with less complexity and provides the same or a higher level of protection/efficiency, then please write it down so we can compare it in its entirety.

>> Yes, because unicast PTP does not work in the same way as NTP. NTP is base
>> d on a request/response exchange while unicast PTP is not. I would certainly be
>> possible to put NTP4NTS messages into PTP, but that would have the same drawback
>> that I see with Daniel's proposal to use NTP4NTS to secure the time error of PT
>> P: you need to setup an NTS4NTP infrastructure and basically run two sync protoc
>> ols plus one security/key exchange protocol in parallel. NTS4UPTP only requires
>> you to run one sync protocol and a key exchange protocol.
> 

A couple lines of code? OK, if you volunteer to modify chrony, I would volunteer to test this with our hardware time stamping engine. Just add a comment where you want to get the hw timestamp from our engine and we will add the necessary function call to actually get it from the hardware. Please ensure that you need to read out at least the sequenceId and MessageType from the PTP header as that is required to find the correct timestamp in the queue. See my comments to Kristof earlier today regarding the requirement to add support for different timestamping hardware, but a first test if this actually works would certainly be interesting, so why not give it a shot if it's only a couple lines of code!

>> I would also not be happy with the efficiency, because an NTS4NTP packet p
>> robably has some redundant or unnecessary information in it that is not required
>> when I run unicast PTP. And, the other way around, adding a full "dummy" PTP pa
>> cket header to enable using the hw timestamping engine to hardware timestamp my
>> NTS4NTP packets is a waste of bandwidth and CPU cycles.
> 
The NTS_TLV is not used for the actual sync / delay / announce messages in our draft, that means you have the authentication_TLV as an overhead compared to standard unicast PTP. This TLV has a size of 42 octets (if I assume a ICV size of 256 bit). The Common PTP message header is 34 octets in size, the size of the Sync and Delay_Req messages is another 10 octets, resulting in 44 octets in total, which proves your point. 

>> Such a NTS4NTP protocol also does not address the other advantage that uni
>> cast PTP has over NTP: higher packet rates. You can change that too, of course.
>> In the end you created a third time sync protocol which to me looks more like a
>> Frankenstein monster version of NTP/PTP and is a completely different beast. It
>> will be neither compliant to NTP, nor PTP.
> 
Yes, I agree.

> AES-GCM-SIV instead of AES-SIV-CMAC for cookie encryption to get a

It's a tradeoff, but you get almost all the benefits of NTS4NTP with NTS4UPTP and I am convinced that a lot of current PTP users would choose to use NTS4UPTP and users NTP in need for hardware timestamping might choose to go for "NTS4NTP over PTP".  

>> It may work and add more accuracy to NTP4NTS, but has nothing to do with P
>> TP. And yes, you can argue that nobody needs PTP anymore in that case, but I am
>> not sure it will be a pleasant discussion.
>> 
> Right. :)
:-)

Regards,
   Heiko

-- 
Heiko Gerstung 
Managing Director 

 
Email: 

Connect via LinkedIn:

---

From: Heiko Gerstung <[email-masked]>
Date: Wed, 2 Jun 2021 13:21:45 +0200

> 
> Am 02.06.21, 09:49 schrieb "ntp im Auftrag von Miroslav Lichvar" <ntp-bounces@ie
>> I was going to say that PTP is … going to have a security mechanism, becau
>> se industry is making it a requirement.  It would be easiest for implementers an
>> d network operators if it was as much like NTS as possible.  The NTP working gro
>> up is the group in the best position to help solve this problem because you have
>> just been through it for NTP, and because of the security expertise in the IETF
>> .
> 

I strongly disagree with this paragraph. Unicast PTP is unlike NTP in every aspect, even multicast PTP is also not like NTP broadcast mode. 
The PTP folks want security for PTP and our proposal delivers that for unicast PTP. Introducing a stateless mode for unicast PTP would certainly something to look at, but why should we do this if my draft protects unicast PTP as-is, without a requirement to change another standard? 

Today there is NTS4NTP and (unsecure) unicast PTP. Our draft tries to re-use the good work that went into the NTS4NTP draft as much as possible while retaining the unicast protocol and its mechanics as much as possible. Why do you think PTP users should switch to a different protocol or modify the protocol they use to a point where it is more or less a complete rewrite? This is a surprising request to make to entire industries and user communities that chose to use PTP as their time sync protocol instead of NTP in the 19 years of its existence. 

Regards,
   Heiko

-- 
Heiko Gerstung 
Managing Director 

 
Email: 

Connect via LinkedIn:

---

From: Miroslav Lichvar <[email-masked]>
Date: Wed, 2 Jun 2021 14:10:12 +0200

> The PTP folks want security for PTP and our proposal delivers that for unicast PTP. Introducing a stateless mode for unicast PTP would certainly something to look at, but why should we do this if m…

Well, some people seem to be asking for as much of NTS4NTP as
possible. I suggested a solution to get that and I understand it may
not be very practical.

Yes, your draft uses some elements from NTS4NTP, but it's still very
different and I'm not sure if it is worth the extra complexity if a
simpler solution using an already existing security protocol could
provide the same security.

I'm not against having an NTS4UPTP draft in general. I just don't want
it to reuse parts of NTS4NTP only to have an "NTS" stamp on it. There
should be some technical reasons behind it. Maybe there are. I think
it's up to the authors to defend it.

-- 
Miroslav Lichvar

---

From: "Salz, Rich" <[email-masked]>
Date: Wed, 2 Jun 2021 13:10:40 +0000

Well Franke-stenn is pretty close :)

---

From: Miroslav Lichvar <[email-masked]>
Date: Wed, 2 Jun 2021 15:21:14 +0200

> Yes, it needs to be fleshed out in more detail in a draft. My point is that you could use a different approach than what we chose in our proposal, but you then have to put this down in writing and…

I'm not interested in writing a new NTS4UPTP draft, at least not at
this time. I'm asking you to reconsider your design or at least
describe how it compares to possible alternatives.

> A couple lines of code? OK, if you volunteer to modify chrony, I would volunteer to test this with our hardware time stamping engine. Just add a comment where you want to get the hw timestamp from…

It is 7 lines for a quick hack that hardcodes a PTP prefix for all NTP
messages [1]. Both server and client ports need to be configured to
the PTP port. If your timestamper doesn't use the Linux timestamping
API, it will probably require significant changes. I'll leave that up
to you if you think it's worth the trouble.

I tested it on two NICs: Intel XL710 (40Gb) and Broadcom BCM5720
(1Gb). Both seem to work as expected. It seems their filter only
checks the message type and version, ignoring the length and other
fields. If all HW worked like that and it was acceptable to generate
invalid PTP messages, the messages could be only two octets longer.

> The NTS_TLV is not used for the actual sync / delay / announce messages in our draft, that means you have the authentication_TLV as an overhead compared to standard unicast PTP. This TLV has a size…

Another thing to consider is that PTP exchanges more messages per
measurement than NTP. In NTP it's 2 messages to get all 4 timestamps.
In PTP it's 4 or 5 to get the timestamps and there are also announce
messages and unicast-specific messages. NTP4NTS over PTP might
actually save some network bandwidth.

[1] https://fedorapeople.org/~mlichvar/chrony/chrony-ntpoverptp.patch

-- 
Miroslav Lichvar

---

From: Doug Arnold <[email-masked]>
Date: Wed, 2 Jun 2021 14:03:50 +0000

Would the proposals by Heiko and Martin for PTP security make more sense to people if we just called it TLS based Security for PTP, and left the NTS out?

Doug

From: ntp <[email-masked]> on behalf of Miroslav Lichvar <[email-masked]>
Date: Wednesday, June 2, 2021 at 9:21 AM
To: Heiko Gerstung <[email-masked]>
Cc: [email-masked] <[email-masked]>
Subject: Re: [Ntp] NTS4UPTP Rev 03 - Formal request for WG adoption

--
Miroslav Lichvar

---

From: Heiko Gerstung <[email-masked]>
Date: Wed, 2 Jun 2021 18:12:28 +0200

> 
> Am 02.06.21, 15:21 schrieb "Miroslav Lichvar" <[email-masked]>:
> 
>> Yes, it needs to be fleshed out in more detail in a draft. My point is tha
> t you could use a different approach than what we chose in our proposal, but you
> then have to put this down in writing and submit a draft if you are convinced i
> t has enought benefits when compared to our approach. If you believe it would be
> a lot shorter, more compact document with less complexity and provides the same
> or a higher level of protection/efficiency, then please write it down so we can
> compare it in its entirety.
> 

Well, I tried to describe how it compares to all the alternatives that you and others brought up. Please excuse my confusion, but I am not sure how to proceed from here. I was told numerous times in the past that if I wanted other people to discuss a proposal of mine, then I should come up with a draft. This is exactly what I did with NTS4UPTP. But instead of discussing my proposal, people start to propose alternative approaches (by mentioning them in a sentence or two, most of the time claim that this alternative is either already available or requires only a very short and compact document to describe it and matches or exceeds the security gain of our proposal). 

It is pretty hard to try and compare our proposal against a bunch of ideas that are thrown into the discussion. Most of the proposed alternatives seem simple and easy to describe with two or three sentences, but when we drafted our proposal, we found out (once again) that when you try to describe something in written form, a lot of details and corner cases come up that you have to deal with. In the end, you often end up with at least 10-20 pages, no matter how simple the idea sounds in the beginning.

Your last proposed alternative is to use NTP4NTS instead of securing PTP. This is not a request for reconsideration of my design, it is basically a rejection of the entire design. It is not doing the job of securing unicast PTP, instead it introduces a way to increase the accuracy of NTP (and/or NTS4NTP). Users already using or planning to use unicast PTP in their networks would have to completely redesign their sync architecture and infrastructure. They cannot use the security mechanism that is a part of the PTP standard, instead you suggest they should switch to a different protocol. 

The first question was why not using MACsec or IPsec. I explained that it will not work because of the loss of the hardware timestamping capabilities. 

After that, you proposed to use DTLS instead of NTS-KE. I do not know enough details to be able to compare it. From the few sentences you wrote, I would guess that it will work and would offer a way to secure PTP synchronization as well, but when I compare this idea with our draft, I see these following points:

* DTLS: Asymmetric cryptography would have to be required to be carried out by every PTP server separately for each client (even if this happens only once at the beginning to initialize the DTLS communication). This requires a major modification to the PTP software on the server side and is also requiring more processing power on each PTP instance
* NTS4UPTP: Asymmetric cryptography can be handled on a separate NTS-KE server and is not required by the PTP server to handle the clients. 

* DTLS: would require to protect delay responses and announce messages from the server (in the packet transmission phase)
* NTS4UPTP: only requires to use the integrated PTP security mechanism in phase 3 for all message types

* DTLS: would require to write a completely new draft, no volunteers yet
* NTS4UPTP: draft is already there and could be discussed right away, three authors committed to work on it 

Not sure if this is more like what you would like to see from me in regards to a comparison. 

At this point I would be open to change the name of the draft so that it does not contain "NTS" anymore, if that helps. It seems that quite a number of the authors do not like that we based our proposal on their work and would rather like unicast PTP to use something else as a key exchange protocol. I do not think that this is reasonable, it has been mentioned numerous times now that there are quite a number of users operating both NTP and PTP sync infrastructure in parallel and I am still convinced they appreciate to be able to set up one NTS-KE server infrastructure that handles both NTS4NTP and our proposal. And: ee wanted to use the latest and greatest key exchange protocol that has been designed by security experts and time sync specialists. 
 
>> A couple lines of code? OK, if you volunteer to modify chrony, I would vol
> unteer to test this with our hardware time stamping engine. Just add a comment w
> here you want to get the hw timestamp from our engine and we will add the necess
> ary function call to actually get it from the hardware. Please ensure that you n
> eed to read out at least the sequenceId and MessageType from the PTP header as t
> hat is required to find the correct timestamp in the queue. See my comments to K
> ristof earlier today regarding the requirement to add support for different time
> stamping hardware, but a first test if this actually works would certainly be in
> teresting, so why not give it a shot if it's only a couple lines of code!
> 

Thanks, I do not think it is worth the trouble. There would still be code missing to use the obtained hardware timestamps and replace/adjust the timestamps of NTS4NTP with it. But you brought it up and I believe it could fly and improve the accuracy of NTP/NTS4NTP. Still not sure how to get the time into the hardware timestamper for a server that supports this, but it might be worth working on it.

> invalid PTP messages, the messages could be only two octets longer.
Yes, the good thing about PTP messages is that they are not fixed length due to the TLV concept. 

>> The NTS_TLV is not used for the actual sync / delay / announce messages in
>> our draft, that means you have the authentication_TLV as an overhead compared t
>> o standard unicast PTP. This TLV has a size of 42 octets (if I assume a ICV size
>> of 256 bit). The Common PTP message header is 34 octets in size, the size of th
>> e Sync and Delay_Req messages is another 10 octets, resulting in 44 octets in to
>> tal, which proves your point.
 
> actually save some network bandwidth.

Yes, maybe 300kbit/s per client (~300 bytes less, 128 pkt/s). 

> [1] https://fedorapeople.org/~mlichvar/chrony/chrony-ntpoverptp.patch
Thanks a lot.

Best Regards,
   Heiko

-- 
Heiko Gerstung 
Managing Director 

 
Email: 

Connect via LinkedIn:

---

From: <[email-masked]>
Date: Wed, 2 Jun 2021 20:51:53 +0000

This sounds like a lively and interesting thread.   I'm sorry I have been missing out 😊  I think the NTS4UPTP makes a lot of sense from the position of having generic utility for implementing network timing protocols and has security optimized for the large number of small, ephemeral timing packets.  This is something that has come up in the past and it looks like this draft does a good job of covering the ground.  In the way back, when S/NTP (secure NTP) was being developed, the feedback was that unique implementations from protocol providers was not a good idea and we should leverage existing security protocols.  The same argument was applied to Autokey and the recently proposed new version of Autokey.  8915 looks to be the closest thing to a standardized timing protocol security model we have implemented today.  It seems like that is what this draft covers, extending the security model to support an alternate timing protocol which has many attributes in common with mode 3/4 NTP.  I don’t know that they actually need to be the same, but I wonder why they would instead need to be different?  8915 has the extensible message types that are designed to support extending the protocol, why not use them?  C/S, or L/F PTP and NTP are quite similar in actual use although the use of hardware acceleration is far more common in PTP (and its associated strengths and weaknesses).

Thanks...Greg

Greg Dowd  Microchip - Freq & Time Div.

Assoc. Technical Fellow – Engineering
3870 N First St, San Jose, CA 95134
Direct: 408-964-7643
[email-masked]

-----Original Message-----
From: ntp <[email-masked]> On Behalf Of Heiko Gerstung
Sent: Wednesday, June 2, 2021 9:12 AM
To: Miroslav Lichvar <[email-masked]>
Cc: [email-masked]
Subject: Re: [Ntp] NTS4UPTP Rev 03 - Formal request for WG adoption

EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe

> t you could use a different approach than what we chose in our 
> proposal, but you then have to put this down in writing and submit a 
> draft if you are convinced i t has enought benefits when compared to 
> our approach. If you believe it would be a lot shorter, more compact 
> document with less complexity and provides the same or a higher level 
> of protection/efficiency, then please write it down so we can compare it in its entirety.
>

>> > If you used only NTP4NTS over PTP, you would still have only one 
>> > sync protocol. Just the transport is different. That's a couple 
>> > lines of code.
>>
> unteer to test this with our hardware time stamping engine. Just add a 
> comment w here you want to get the hw timestamp from our engine and we 
> will add the necess ary function call to actually get it from the 
> hardware. Please ensure that you n eed to read out at least the 
> sequenceId and MessageType from the PTP header as t hat is required to 
> find the correct timestamp in the queue. See my comments to K ristof 
> earlier today regarding the requirement to add support for different 
> time stamping hardware, but a first test if this actually works would certainly be in teresting, so why not give it a shot if it's only a couple lines of code!
>

>> The NTS_TLV is not used for the actual sync / delay / announce 
>> messages in our draft, that means you have the authentication_TLV as 
>> an overhead compared t o standard unicast PTP. This TLV has a size of 
>> 42 octets (if I assume a ICV size of 256 bit). The Common PTP message 
>> header is 34 octets in size, the size of th e Sync and Delay_Req 
>> messages is another 10 octets, resulting in 44 octets in to tal, which proves your point.

Thanks a lot.

Best Regards,
   Heiko

--
Heiko Gerstung
Managing Director

Email:

Connect via LinkedIn:

---

From: Miroslav Lichvar <[email-masked]>
Date: Thu, 3 Jun 2021 09:31:41 +0200

On Wed, Jun 02, 2021 at 06:12:28PM +0200, Heiko Gerstung wrote:
> Well, I tried to describe how it compares to all the alternatives that you and others brought up. Please excuse my confusion, but I am not sure how to proceed from here. I was told numerous times in the past that if I wanted other people to discuss a proposal of mine, then I should come up with a draft. This is exactly what I did with NTS4UPTP.

I'm glad you wrote the draft and we can discuss it.

> But instead of discussing my proposal, people start to propose alternative approaches (by mentioning them in a sentence or two, most of the time claim that this alternative is either already available or requires only a very short and compact document to describe it and matches or exceeds the security gain of our proposal). 

I think that's expected. People try to convince you their ideas are
better and you try to convince them they are not, or accept their
suggestions and rework your draft.

NTS4NTP took many years to form. IIRC it was redesigned three times
from scratch. As we seem to agree, PTP is nothing like the
client/server NTP mode that NTS4NTP protects and cannot be reused as
a whole. I hope you didn't expect this would go smoothly right with
the first submitted proposal.

I think there are basically three different issues discussed:
- Does it make sense for PTP to have a public-key based
  authentication?
- Does it make sense for unicast PTP to have something different than
  the rest of PTP?
- Does it make sense to reuse something from NTS4NTP?

> The first question was why not using MACsec or IPsec. I explained that it will not work because of the loss of the hardware timestamping capabilities. 

That's ok, but it needs to be explained in the draft as those are
solutions mentioned in IEEE1588.

> * DTLS: Asymmetric cryptography would have to be required to be carried out by every PTP server separately for each client (even if this happens only once at the beginning to initialize the DTLS co…

I didn't realize this was a requirement. I think with (D)TLS you can
move the session between servers to avoid the slow crypto. I hope
someone who actually understands DTLS will correct me if I'm wrong. A
new TLV could be introduced to tell the client to move a different
server and the client would try to resume the session there. An
advantage over your proposal is that it could do that on each unicast
renewal and not only when the cookie expires, so it could be more
dynamic.

> * NTS4UPTP: only requires to use the integrated PTP security mechanism in phase 3 for all message types

I don't see that as a disadvantage.

> Not sure if this is more like what you would like to see from me in regards to a comparison. 

Yes, that's great and I'd like to see other people comment on those
points.

> At this point I would be open to change the name of the draft so that it does not contain "NTS" anymore, if that helps. It seems that quite a number of the authors do not like that we based our proposal on their work and would rather like unicast PTP to use something else as a key exchange protocol.

Having NTS in the name is not the main concern for me.

It's the use of NTS-KE and NTS cookies that doesn't make much sense to
me. It's possible I missed some important point. In NTS4NTP cookies
are meant to offload the server state to the client, so it can be
stateless, but in unicast PTP you already have to keep some
client-specific state, so why would you need to offload some part of
the state?

> I do not think that this is reasonable, it has been mentioned numerous times now that there are quite a number of users operating both NTP and PTP sync infrastructure in parallel and I am still convinced they appreciate to be able to set up one NTS-KE server infrastructure that handles both NTS4NTP and our proposal. And: ee wanted to use the latest and greatest key exchange protocol that has been designed by security experts and time sync specialists. 

The key exchange comes from TLS. You don't need NTS-KE for that.
Sharing one port with NTP and PTP might have some advantages, but I
suspect it's more likely that people will want to use two different
implementations that cannot share the port.

-- 
Miroslav Lichvar

---

From: [email-masked]
Date: Thu, 3 Jun 2021 09:38:56 +0200

>>At this point I would be open to change the name of the draft so that it does not contain "NTS" anymore, if that helps. It seems that quite a number of the authors do not like that we based our proposal on their work and would rather like unicast PTP to use something else as a key exchange protocol. [...]

As one of the editors, I do feel misrepresented here.

There are five of us, only three of whom have spoken about NTS4UPTP at all, with only one who spoke out in rejection.

I will get back to you (after studying the draft in more detail) on what I think about how you based your proposal on our work, but I am perfectly happy that you did.

@Daniel: would it change your stance if this draft were not named anything with "NTS" at all?

>> It is pretty hard to try and compare our proposal against a bunch of ideas that are thrown into the discussion. Most of the proposed alternatives seem simple and easy to describe with two or three…

Yes, absolutely agree.

And in those pages, you are pretty likely to stumble over the detail that will make your draft more controversial than you thought.

This is why I want to clarify that (unless I ever explicitly say so) none of my technical discussion, wishful thinking or even design sketching is to be taken against the NTS4UPTP draft (or other drafts).

---

From: Heiko Gerstung <[email-masked]>
Date: Thu, 3 Jun 2021 12:30:44 +0200

> Von: <[email-masked]>

> Datum: Donnerstag, 3. Juni 2021 um 09:39

> An: Heiko Gerstung <[email-masked]>

> Cc: "[email-masked]" <[email-masked]>

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

>>>At this point I would be open to change the name of the draft so that it does

> not contain "NTS" anymore, if that helps. It seems that quite a number of the au

> thors do not like that we based our proposal on their work and would rather like

> unicast PTP to use something else as a key exchange protocol. [...]

> There are five of us, only three of whom have spoken about NTS4UPTP at all, with

> only one who spoke out in rejection.

Apologies for that, I based that assumption on a feeling and not on factual data (which is never a good thing IMHO but happens quite frequently in real life :).

> I will get back to you (after studying the draft in more detail) on what I think

> about how you based your proposal on our work, but I am perfectly happy that yo

> u did.

Glad to hear that. 

> @Daniel: would it change your stance if this draft were not named anything with

> "NTS" at all?

>>> It is pretty hard to try and compare our proposal against a bunch of ideas th

>>> at are thrown into the discussion. Most of the proposed alternatives seem simple

>>> and easy to describe with two or three sentences, but when we drafted our propo

>>> sal, we found out (once again) that when you try to describe something in writte

>>> n form, a lot of details and corner cases come up that you have to deal with. In

>>> the end, you often end up with at least 10-20 pages, no matter how simple the i

>>> dea sounds in the beginning.

> And in those pages, you are pretty likely to stumble over the detail that will m

> ake your draft more controversial than you thought.

For sure, but up until now I cannot say that we actually discussed the draft so far.

> This is why I want to clarify that (unless I ever explicitly say so) none of my

> technical discussion, wishful thinking or even design sketching is to be taken a

> gainst the NTS4UPTP draft (or other drafts).

OK, thanks. It sometimes gets confusing if those ideas/new concepts are included in a response to a message that deals with the draft. 

Regards,

   Heiko

-- 

Heiko Gerstung 

Managing Director 

Lange Wand 9 

Email: 

Web: 

Connect via LinkedIn:

---

From: Doug Arnold <[email-masked]>
Date: Fri, 4 Jun 2021 17:08:24 +0000

Miroslav identified three issues that are under discussion:
- Does it make sense for PTP to have a public-key based
  authentication?

A big weakness of PTP is server impersonation.  So PTP needs a security mechanism that requires that a PTP node get authenticated before it can get keys.  Also the feedback I get from both equipment manufacturers and network operators is: no new key management mechanism.  So PTP security should be based on something already in common usage, such as TLS, or IPsec.

Unicast PTP is actually quite different from multicast PTP, or mixed multicast/unicast PTP.  Unicast PTP with negotiation (the usually way to do unicast PTP) has an additional message negotiation stage, intended to allow PTP servers to manage their capacity.  The negotiation mechanism turns PTP into a client-server paradigm, rather than a leader-follower paradigm like multicast or mixed multicast/unicast PTP.

All of the commercial time server companies make appliances that do both PTP and NTP.  So the more they can have in common the better.  Most customers that have PTP running, also have NTP running at the same time.  So it will be helpful for network operators to learn about the security if it is similar, even if it just the terminology, and concepts in the standard.

Doug

From: ntp <[email-masked]> on behalf of Miroslav Lichvar <[email-masked]>
Date: Thursday, June 3, 2021 at 3:32 AM
To: Heiko Gerstung <heiko.gerstung=[email-masked]>
Cc: [email-masked] <[email-masked]>
Subject: Re: [Ntp] NTS4UPTP Rev 03 - Formal request for WG adoption

--
Miroslav Lichvar

---

From: Miroslav Lichvar <[email-masked]>
Date: Mon, 7 Jun 2021 10:44:56 +0200

> A big weakness of PTP is server impersonation.  So PTP needs a security mechanism that requires that a PTP node get authenticated before it can get keys.  Also the feedback I get from both equipmen…

IPsec is mentioned in IEEE1588, so I guess it is already used to
secure PTP, at least on hardware that doesn't have timestamping
limited to PTP packets.

> All of the commercial time server companies make appliances that do both PTP and NTP.  So the more they can have in common the better.  Most customers that have PTP running, also have NTP running a…

For a vendor selling primary time servers it makes sense to support
everything there is to support, but their number is normally much
smaller than the number of secondary servers and clients. A network
operator might want to limit the number of protocols used. If the
network can support PTP (with boundary clocks or transparent clocks),
it makes sense to use secured PTP. If it cannot support PTP, it's
better to use NTP.

-- 
Miroslav Lichvar

---

From: Miroslav Lichvar <[email-masked]>
Date: Mon, 7 Jun 2021 11:05:19 +0200

On Wed, Jun 02, 2021 at 09:38:41AM +0200, Miroslav Lichvar wrote:
> With a 1000x smaller jitter you need a 1000x shorter

I'm sorry for posting nonsense like this. People who remember how a
typical ADEV plot looks like (with the -1 and +1/2 slopes) probably
knew this was wrong. It should be only 100x shorter polling interval
for 1000x smaller jitter (a slope of 2/3).

I think PTP using 128 sync messages per second is more about filtering
measurements (effectively decreasing the jitter), rather than
the instability of the clock.

-- 
Miroslav Lichvar

---

From: Heiko Gerstung <[email-masked]>
Date: Tue, 8 Jun 2021 08:33:50 +0200

Hi Kristof,

did my response answer your questions? Are there any new questions?

And: did my last submitted revision (-03) address your comments adequately?

Thanks a lot for the review so far, looking forward to more comments!

Regards, 

   Heiko

-- 

Heiko Gerstung 

Managing Director 

Lange Wand 9 

Email: 

Web: 

Connect via LinkedIn: 

 

Von: Heiko Gerstung <[email-masked]>
Datum: Donnerstag, 3. Juni 2021 um 16:21
An: "[email-masked]" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Betreff: Re: Antwort: Re: [Ntp] Antwort: Re: NTS4UPTP Rev 03 - Formal request for WG adoption

> Okay, I've given the draft a closer read now.

> Section 2.2 still loses me a bit, as I'm completely unfamiliar with this kind

> of negotiation, but I think I get the gist of it at least.

OK. We were not sure how much explanation regarding (unicast) PTP we should add to the draft. The main problem with PTP is that it is based on an IEEE standard which is not freely available. Maybe Doug knows a good explanation of the unicast negotiation phase (we have a post in our blog, maybe that helps: https://blog.meinbergglobal.com/2014/04/16/unicast-ptp/).

> I have a few concerns about the threat model (Section 7.1):

> - General point of order about all bullet points: I tend to ignore the threats

> that are of the same effectiveness as cutting the wire (client might drop the

> association, contract might be cancelled...). If you assume a MITM attacker,

> you won't prevent this overall issue.

I would say that attacking one service is from a threat perspective equivalent to “cutting the wire”. But I agree that there is nothing you can do if someone owns your switch/router. 

> - First bullet: yes, this is important, and yes, this is fulfilled to a large

> degree. The client can verify that the server said everything the ICV covers,

> and that the message belongs to the correct client-server association. Delay

> modifications are not really covered (with a small asterisk because of sequence

> numbers that we keep in mind), and this should perhaps be mentioned.

I will add a description of delay attacks and explain that this proposal does not offer protection against this kind of attack. I also will add a few sentences explaining how a client can at least defend itself to some degree by setting hard or soft limits for acceptable delay values. 

> - Second bullet: very similiar deal to the first bullet - except that it seems

> to me that the server doesn't even care about this protection.

Ultimately you could say that the server does not care about the clients, but the point does not specifically mention that such an attack is negatively affecting the server. It just refers to an attack that is carried out against the server, but it will negatively impact the client. I will try to rephrase it, maybe it is better to just combine the two first bullet points, as they are more or less describing the same thing.

> - Third bullet: Whenever you discuss replay attacks, I kind of miss a

> consideration about what happens if it's a delay attack instead (which is

> really a replay attack with an additional deletion of the original message, if

> you will). It seems dangerous to just ignore this. This is about phase 2, as

> well, and I'm generally unsure about the implications.

I would make the distinction between delay and replay attacks. I would understand a replay attack to be resending a packet that has been received already. In order to carry out a delay attack (or to drop / block packets in general) you need to be able to control the switch/router (MiTM). A replay attack can be carried out by any node that is capable of seeing traffic and sending arbitrary frames. Although from a practical standpoint with unicast communication there are not a lot of potential ways to see other nodes’ traffic without sitting as a MiTM in between sender  and receiver. 

> - Fourth bullet: same deal as above - but here I know for a fact that

> synchronization-wise, delay is about as dangerous (or more) as replay. All of

> the considerations about "consuming resources" seems a bit pointless, since an

> attacker would achieve about the same thing with just random messages where the

> authentication doesn't check out, wouldn't they?

I am not sure if this is the same. You can increase the damage if you maximize the number of checks a receiver has to carry out to ultimately find out that it should drop the packet. Regarding the “consuming resources” part: An attacker sending delay requests with invalid ICVs would cause the server to quickly drop the request. That is not as bad as tricking the server into responding (as long as setting up the response and sending it requires more effort than just dropping the invalid request, which I believe is the case here).

> - Fifth bullet: sure. The only comment I might have is that you might want to

> clarify that this only prevents problems if this authenticated variant is used.

Not sure if I understood this comment. All the bullet points describe threats/attacks and how the proposed document mitigates them. Can you please explain further?

> But this is a good example of something where replay would actually be harmful

> whereas delay wouldn't.

Yes. Although the question with a delay attack is always  to what extend you can delay a packet until a timeout on the receiver results in ignoring it when it finally arrives. Or, in this case, if you delay the request long enough, the client will most probably try to send another request after a timeout. 

> I'm missing a clear distinction between the one-way transfer aspect of PTP

> (Announce and Sync messsages) and the part that enables two-way-transfer-like

> behavior (Delay_Req and Delay_Resp messages).

> Section 5, second-to-last paragraph, goes to some lengths to make sure that the

> server never sends new cookies to the client.

Could be improved to leave out the reference to the cookie that it shall never send, I believe it is good enough to just focus on what it should do (sending random data).

> a) Is there a specific reason why you did not go for full-on NTS4NTP behavior

> for Delay_Req/Resp messages?

No sure what you mean with “full-on NTS4NTP behavior”, but I believe there is no gain in adding another layer of security on the delay req/resp exchange in addition to the ICV based protection that is used for all other message types of phase 3. Since this can happen 128 times per second per client, I believe it should be as lean as possible. 

> If this subset of behavior were kept stateless on the server side, I believe

> this would be a good candidate for the kind of frankensteined construct I was

> talking about in an earlier mail (do only Delay_Req/Resp exchanges, somehow

> force the client to timestamp reception of Delay_Resp, and you have all you

> need - three timestamps is really about as good as four).

“Somehow force the client to timestamp reception of Delay Resp” is the key sentence here. The timestamping is done in hardware, which you would have to change to make this work. 

> This would also allow you to preserve client unlinkability, if I'm not mistaken.

Yes. Would not be PTP anymore, but using the existing PTP hw timestamping engines out there is definitely possible. You could for example just send a delay request back. 

> b) Why does the server have an interest to be able to "force the client to

> re-start"? I might have missed it, but I see no motivation for this in the

> threat model (and you have no section about your Objectives, which brings me to

> my last point...)

This is related to key freshness. The server can send the client back to the NTS-KE in case the client presents a cookie with an outdated master key. 

> Between Sections 1 and 2, I would really encourage you to add a section about

> the objectives here.

> This would be nice so that they can be compared with NTS4NTP, and also to judge

> whether or not we actually see that you fulfill them.

Agreed, let me try to add a section listing the objectives. 

> That's what I have for now, I might come back to this later after I've had time

> to contemplate during a walk or slept over this.

Thanks a lot, this was exactly the type of comments I was hoping to receive. 

> Last point of order: none of these are showstoppers for me, they don't change

> my stance that I think we can adopt this and discuss further changes/additions

> that people would like to see.

Great, and thank you for encouraging the other members to express their support or rejection of a possible adoption of the draft by the WG, btw. 

Regards,

  Heiko

-- 

Heiko Gerstung 

Managing Director 

Lange Wand 9 

Email: 

Web: 

Connect via LinkedIn:

---

From: [email-masked]
Date: Fri, 11 Jun 2021 15:07:20 +0200

Hello,

sorry that I'm (perhaps frustratingly) slow to respond.
I'm afraid it is going to stay this way for at least the next two weeks or 
so.

I will have to read the draft closely (focusing on the changes and how 
they adress my comments) later.
This is the majority of issues, but there are a few things that haven't 
gone into the draft and are instead limited to this mail thread.
I'd like to adress these now.

> clarify that this only prevents problems if this authenticated variant 
is used.
Not sure if I understood this comment. All the bullet points describe 
threats/attacks and how the proposed document mitigates them. Can you 
please explain further?

I believe this was about amplification.
All I was trying to say was that your approach won't help if the server 
also still responds to unsecured messages.
That's fine in a way, but it feels like it's worth mentioning that you 
only get the benefits if you forgo backwards compatibility (unsure if I'm 
expressing this clearly still).

> for Delay_Req/Resp messages?
No sure what you mean with ?full-on NTS4NTP behavior?, but I believe there 
is no gain in adding another layer of security on the delay req/resp 
exchange in addition to the ICV based protection that is used for all 
other message types of phase 3. Since this can happen 128 times per second 
per client, I believe it should be as lean as possible.

What I meant was that it could have been done in a way that didn't involve 
keeping state on the server side (transmitting the state information on 
request, as in NTS4NTP).

> need - three timestamps is really about as good as four).
?Somehow force the client to timestamp reception of Delay Resp? is the key 
sentence here. The timestamping is done in hardware, which you would have 
to change to make this work. 
 
> This would also allow you to preserve client unlinkability, if I'm not 
mistaken.
Yes. Would not be PTP anymore, but using the existing PTP hw timestamping 
engines out there is definitely possible. You could for example just send 
a delay request back. 

What if you were to forgo regular Announce and Sync messages, and instead 
made it so that the server responds to a Delay_Req with a Sync (and 
perhaps Follow_Up) message?
You are already doing unicast, why not go full request-response scheme?
That would actually enable you to just carry most of NTS4NTP's way of 
working over, including the key scheme with the server-side statelessness.
I honestly kind of thought originally that this was going to be what your 
draft did.

> threat model (and you have no section about your Objectives, which 
brings me to
This is related to key freshness. The server can send the client back to 
the NTS-KE in case the client presents a cookie with an outdated master 
key. 

Yes, I see that it can do that, but why does it want to?
It still seems to me that the draft is deliberately getting rid of a 
mechanism to do on-the-go key refreshing (as NTS4NTP can do with each 
request-response exchange) just so it has a fallback in case someone uses 
an un-fresh key... which would never happen if keys were only used once.
Maybe I'm missing something obvious.

Best regards,
Kristof

P.S.: I can tell you already that I still have a few issues with the new 
draft version, particularly about the goals and how they carry over from 
NTP to PTP in some instances.
But I will go into this once I've given the whole thing another read.

Von:    "Heiko Gerstung" <heiko.gerstung=[email-masked]>
An:     "[email-masked]" <[email-masked]>, "[email-masked]" 
<[email-masked]>
Kopie:  "Doug Arnold" <[email-masked]>
Datum:  08.06.2021 08:34
Betreff:        Re: [Ntp] Antwort: Re: Antwort: Re: NTS4UPTP Rev 03 - 
Formal request for WG adoption
Gesendet von:   "ntp" <[email-masked]>

Hi Kristof,
 
did my response answer your questions? Are there any new questions?
And: did my last submitted revision (-03) address your comments 
adequately?

Regards, 
   Heiko

-- 
Heiko Gerstung 
Managing Director 

Amtsgericht Hannover 17HRA 100322 
Geschäftsführer/Management: Günter Meinberg, Werner Meinberg, Andre 
Hartmann, Heiko Gerstung 
 
Email: 

Connect via LinkedIn: 

Betreff: Re: Antwort: Re: [Ntp] Antwort: Re: NTS4UPTP Rev 03 - Formal 
request for WG adoption
 
> of negotiation, but I think I get the gist of it at least.
 
OK. We were not sure how much explanation regarding (unicast) PTP we 
should add to the draft. The main problem with PTP is that it is based on 
an IEEE standard which is not freely available. Maybe Doug knows a good 
explanation of the unicast negotiation phase (we have a post in our blog, 
maybe that helps: https://blog.meinbergglobal.com/2014/04/16/unicast-ptp/
).
> you won't prevent this overall issue.
I would say that attacking one service is from a threat perspective 
equivalent to ?cutting the wire?. But I agree that there is nothing you 
can do if someone owns your switch/router. 
 
> numbers that we keep in mind), and this should perhaps be mentioned.
I will add a description of delay attacks and explain that this proposal 
does not offer protection against this kind of attack. I also will add a 
few sentences explaining how a client can at least defend itself to some 
degree by setting hard or soft limits for acceptable delay values. 
 
> to me that the server doesn't even care about this protection.
Ultimately you could say that the server does not care about the clients, 
but the point does not specifically mention that such an attack is 
negatively affecting the server. It just refers to an attack that is 
carried out against the server, but it will negatively impact the client. 
I will try to rephrase it, maybe it is better to just combine the two 
first bullet points, as they are more or less describing the same thing.
 
> well, and I'm generally unsure about the implications.
I would make the distinction between delay and replay attacks. I would 
understand a replay attack to be resending a packet that has been received 
already. In order to carry out a delay attack (or to drop / block packets 
in general) you need to be able to control the switch/router (MiTM). A 
replay attack can be carried out by any node that is capable of seeing 
traffic and sending arbitrary frames. Although from a practical standpoint 
with unicast communication there are not a lot of potential ways to see 
other nodes? traffic without sitting as a MiTM in between sender  and 
receiver. 
 
> authentication doesn't check out, wouldn't they?
I am not sure if this is the same. You can increase the damage if you 
maximize the number of checks a receiver has to carry out to ultimately 
find out that it should drop the packet. Regarding the ?consuming 
resources? part: An attacker sending delay requests with invalid ICVs 
would cause the server to quickly drop the request. That is not as bad as 
tricking the server into responding (as long as setting up the response 
and sending it requires more effort than just dropping the invalid 
request, which I believe is the case here).
 
> clarify that this only prevents problems if this authenticated variant 
is used.
Not sure if I understood this comment. All the bullet points describe 
threats/attacks and how the proposed document mitigates them. Can you 
please explain further?
 
> But this is a good example of something where replay would actually be 
harmful
Yes. Although the question with a delay attack is always  to what extend 
you can delay a packet until a timeout on the receiver results in ignoring 
it when it finally arrives. Or, in this case, if you delay the request 
long enough, the client will most probably try to send another request 
after a timeout. 
 
> server never sends new cookies to the client.
Could be improved to leave out the reference to the cookie that it shall 
never send, I believe it is good enough to just focus on what it should do 
(sending random data).
 
> for Delay_Req/Resp messages?
No sure what you mean with ?full-on NTS4NTP behavior?, but I believe there 
is no gain in adding another layer of security on the delay req/resp 
exchange in addition to the ICV based protection that is used for all 
other message types of phase 3. Since this can happen 128 times per second 
per client, I believe it should be as lean as possible. 
 
> need - three timestamps is really about as good as four).
?Somehow force the client to timestamp reception of Delay Resp? is the key 
sentence here. The timestamping is done in hardware, which you would have 
to change to make this work. 
 
> This would also allow you to preserve client unlinkability, if I'm not 
mistaken.
Yes. Would not be PTP anymore, but using the existing PTP hw timestamping 
engines out there is definitely possible. You could for example just send 
a delay request back. 
 
> threat model (and you have no section about your Objectives, which 
brings me to
This is related to key freshness. The server can send the client back to 
the NTS-KE in case the client presents a cookie with an outdated master 
key. 

> to contemplate during a walk or slept over this.
Thanks a lot, this was exactly the type of comments I was hoping to 
receive. 
 
> that people would like to see.
Great, and thank you for encouraging the other members to express their 
support or rejection of a possible adoption of the draft by the WG, btw. 
 
Regards,
  Heiko

-- 
Heiko Gerstung 
Managing Director 

Amtsgericht Hannover 17HRA 100322 
Geschäftsführer/Management: Günter Meinberg, Werner Meinberg, Andre 
Hartmann, Heiko Gerstung 
 
Email: 

Connect via LinkedIn: 

 [Anhang "smime.p7s" gelöscht von Kristof Teichel/PTB] 
_______________________________________________
ntp mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ntp