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

[Heiko Gerstung <[e-mail]>]

> Am 01.06.21, 11:47 schrieb "Miroslav Lichvar" <[e-mail]>:
> 
> 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?

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. 

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

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. 

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

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. 

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

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

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

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. 

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

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: [phone] 
Fax: [phone] 
 
Amtsgericht Hannover 17HRA 100322 
Geschäftsführer/Management: Günter Meinberg, Werner Meinberg, Andre Hartmann, Heiko Gerstung 
 
Email: 
[e-mail]
Web: 
Deutsch https://www.meinberg.de
English https://www.meinbergglobal.com
 
Do not miss our Time Synchronization Blog: 
https://blog.meinbergglobal.com
 
Connect via LinkedIn: 
https://www.linkedin.com/in/heikogerstung