Re: [Ntp] NTP over PTP

[Heiko Gerstung <[e-mail]>]

If I follow your argument that unicast PTP is like the NTP control mode then yes, both mode 6 and unicast PTP are not secured against replay and amplification attacks. The NTS4UPTP draft is exactly addressing this for unicast PTP and provides the required protection. I outlined in the draft that the proposed approach achieves most of the stated objectives/goals of NTS4NTP, which is well secured (we certainly agree on that). 

In the interim meeting I believe there have been multiple participants that agreed that 
a) PTP should be secured (it is worth it)
b) the NTP WG is the right place for this

Arguing that the two drafts on the table might just need TLS instead of NTS-KE is something I cannot understand, too. PTP already has a security mechanism that is standardized and, with some extensions (provided by the submitted drafts), can be used to significantly enhance security of the protocol. What is needed is a key exchange mechanism and some additional features to close the security holes (i.e. no protection for the source IP address) - again, exactly what the two drafts provide. 

Regarding "NTP over PTP": trying to trick the hardware timestamping engines of a large variety of vendors into timestamping a PTP packet is bound to fail IMHO. There is no standard for how these timestamping engines work, some may even look at sizes of packets (they should not do that, as PTP messages can theoretically carry TLVs, but sometimes hardware vendors take shortcuts). Some implementations will forward packets to a management CPU when the forwarding plane detects a PTP frame. The CPU will not recognize that this is NTP and will probably throw away the packet. Again, most likely not the right way to do it, but alas ... 

Why did the telcos choose to go for unicast PTP instead of NTP? Well, one reason was that PTP already provided hardware timestamping capabilities at that time, to dramatically increase the accuracy to a sub-microsecond level that is required for modern telecommunication networks. I know of some hardware vendors in that application space that implemented hardware timestamping for NTP, but there are not a lot of them (Meinberg offers a NTP module which has hw timestamping for NTP, providing 10ns accuracy in the timestamp of the outgoing NTP packets). And, maybe the main reason: the first unicast PTP telco profile ITU-T G8265.1 was designed for frequency-only applications. Unicast PTP as a protocol allows that you do not measure the delay from the client to the server, something that is not required for frequnecy only mode. Using unicast PTP was a lot more efficient that NTP, because the PTP client only has to ask for packets once every minute for example, and gets a constant stream of highly accuracy and hardware timestamped packets from the server for that 60 seconds without having to send a request for each of the packets. 

Well, this is all history now. PTP is here to stay and unicast PTP is probably not going to take over the world, but will for sure be used in some new applications in the future. 

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 24.06.21, 13:33 schrieb "ntp im Auftrag von Miroslav Lichvar" <[e-mail] im Auftrag von [e-mail]>:

    The NTP WG was asked to secure the PTP unicast mode considering it has
    experience with securing NTP. The problem is that the PTP unicast mode
    is very different from the NTP client/server mode, the only mode which
    I think we can claim to be well secured (by symmetric key and NTS).
    The closest thing to the PTP unicast mode would be the NTP control
    mode (6), which is not secured (e.g. against replay attacks).

    I suspect there is nothing here to be reused to secure the unicast
    PTP. There might be some practical advantages of sharing NTS-KE with
    NTP, but I don't see any security benefits. The two drafts that were
    discussed here just need TLS and might actually be simpler if they
    used it directly.

    With this WG still having NTP in its name, there is the uncomfortable
    question that has to be asked. Why can't you just use the NTP
    client/server mode instead of the PTP unicast mode?

    A point was made that there is still a lot of hardware that supports
    only plain PTP. It doesn't support PTP secured by IPSec, MACSec, DTLS,
    etc, either. This was apparently one of the reasons for writing the
    NTS4UPTP draft.

    That has a simple solution. Use PTP as a transport for NTP messages.
    The hardware doesn't care what is inside as long as it can recognize
    the PTP header to trigger the timestamping.

    I submit this idea as a (very short) draft:
    https://datatracker.ietf.org/doc/html/draft-mlichvar-ntp-over-ptp-00

    I understand some people won't like this as an answer to the question
    of securing the unicast PTP. It would be useful in other cases too.

    But is it worth trying to invent a PTP-specific solution to secure its
    unicast mode, when the result cannot possibly be as good as what NTP
    already has?

    As I understand it, the unicast mode of PTP was invented mainly for
    some of the telco profiles, which for the most part seem to emulate
    NTP. What exactly was missing in NTP when those profiles were written?
    IIRC someone mentioned it was discussed with the NTP WG at the time,
    but I don't have any references.

    -- 
    Miroslav Lichvar

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