Re: [Ntp] NTP over PTP

[Heiko Gerstung <[e-mail]>]

> On Mon, Jun 28, 2021 at 05:02:43PM +0200, Heiko Gerstung wrote:
>> > The unicast mode seems to be intended for networks with partial
>> > on-path hardware support, where requirements on accuracy are less
>> > strict, and I think this might already be better supported by NTP.
>> They might be less strict but that does not mean they are worse/equal
>> compared to NTP.
> 
> How so?
Because of the removal of jitter/delay variation in the network stack and OS layer (kernel) of the server and the client. 

> You said unicast transparent clocks don't really exist. That would be
> the only advantage of unicast PTP. Boundary clocks could fully support
> hardware-timestamped NTP if someone was actually interested in
> implementing that.
I was wrong, or better: my knowledge was outdated. Arista for example supports unicast in their switches now.

> Without full on-path support NTP should generally perform better than
> PTP as it doesn't assume network has a constant delay.
Why do you think PTP assumes a constant network delay? PTP is measuring the delay constantly in both directions and calculates the round trip. Its delay measurement mechanism is definitely inferior to the one NTP uses (in regards to the concept) but it is good enough to allow (unicast) PTP to reliably achieve sub microsecond accuracy when used in networks with partial or full on-path support. That would not be possible in a packet switched network without proper delay compensation.

> In the context of the drafts we are discussing here, I think it might
> be easier for an existing PTP implementation to add support for
> NTP+NTS than add NTS4UPTP.

We are maintaining three different PTP implementations here at Meinberg and I can tell you that this is not true. 

>> > If there is some hardware that can timestamp only fixed-length PTP
>> > messages with no TLVs, then that will not work with any form of
>> > NTS4UPTP either, right? There has to be some TLV to authenticate the
>> > message and the hardware needs to accept that.
>>
>> No, that's not correct. The hardware timestamping is only required during
>> phase 3 (packet transmission), which does not require an NTS TLV as it relies
>> completely on the AUTHENTICATION_TLV and the integrated PTP security. See 3.3
>> of my draft. The NTS TLV is required in phase 2 where client and server only
>> exchange messages to negotiate the transmission, and those are not hw
>> timestamped.
> 
> I don't see how that is relevant to hardware not timestamping PTP
> messages with TLVs. If a TLV present in an event message breaks the
> timestamping, the hardware is unusable for any security mechanism
> discussed here, except the Daniel's idea to protect unauthenticated
> PTP by authenticated NTP.

I did not say that hardware is not timestamping PTP event messages that carry a TLV. I just pointed out that some of the hardware timestampers might look at the length of a packet and do not timestamp anything that is longer then X bytes. A sync message is 44 bytes plus maybe 26 bytes for the AUTENTICATION_TLV.  If you remove the requirement for the AUTHENTICATION_TLV because you want to run NTS over PTP, your PTP "header" is 44 bytes + 48 bytes for the NTP header + anything that NTS adds (Unique Identifier EF, NTS Authentication and Encrypted Extension Fields EF, at least one NTS Cookie EF). It is a bit complicated (for me) to calculate the total maximum size of such an NTS over PTP packet, but I am guessing that you will end up with more than 128 bytes, which might be a limit packet matching algorithms have for quickly identifying if this can be a PTP event message. 

The idea might still be worth to discuss and investigate. But it is not the answer to the question how we can secure unicast PTP IMHO. 

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
 
 

Am 29.06.21, 08:52 schrieb "Miroslav Lichvar" <[e-mail]>:

    On Mon, Jun 28, 2021 at 05:02:43PM +0200, Heiko Gerstung wrote:
    > > The unicast mode seems to be intended for networks with partial
    > > on-path hardware support, where requirements on accuracy are less
    > > strict, and I think this might already be better supported by NTP.
    > They might be less strict but that does not mean they are worse/equal compared to NTP.

    How so?

    You said unicast transparent clocks don't really exist. That would be
    the only advantage of unicast PTP. Boundary clocks could fully support
    hardware-timestamped NTP if someone was actually interested in
    implementing that.

    Without full on-path support NTP should generally perform better than
    PTP as it doesn't assume network has a constant delay.

    In the context of the drafts we are discussing here, I think it might
    be easier for an existing PTP implementation to add support for
    NTP+NTS than add NTS4UPTP.

    > > If there is some hardware that can timestamp only fixed-length PTP
    > > messages with no TLVs, then that will not work with any form of
    > > NTS4UPTP either, right? There has to be some TLV to authenticate the
    > > message and the hardware needs to accept that.
    > 
    > No, that's not correct. The hardware timestamping is only required during phase 3 (packet transmission), which does not require an NTS TLV as it relies completely on the AUTHENTICATION_TLV and the integrated PTP security. See 3.3 of my draft. The NTS TLV is required in phase 2 where client and server only exchange messages to negotiate the transmission, and those are not hw timestamped. 

    I don't see how that is relevant to hardware not timestamping PTP
    messages with TLVs. If a TLV present in an event message breaks the
    timestamping, the hardware is unusable for any security mechanism
    discussed here, except the Daniel's idea to protect unauthenticated
    PTP by authenticated NTP.

    -- 
    Miroslav Lichvar