Re: [Ntp] A simpler way to secure PTP

[Heiko Gerstung <[e-mail]>]

 

Am 11.05.21, 10:24 schrieb "Miroslav Lichvar" <[e-mail]>:

    On Tue, May 11, 2021 at 09:14:55AM +0200, Heiko Gerstung wrote:
   > >PTP is different from NTP on multiple levels and offers a number of features that you do not find in NTP, for example higher packet rates to increase the number of samples you feed into your statistics.

>    Isn't this the other way around? The maximum rate of delay requests is
>    limited by the TX HW timestamping rate. The few PTP appliances I saw
>    supported only a very small number of clients. This can exploited for
>    a DoS attack. The same applies to NTP using HW timestamps+xleave, but
>    at least it can fall back to SW timestamps and clients should handle
>    that well.

Our products can support 2,048 unicast PTP clients at 128 pkts/s for both sync and delay responses, i.e. you end up with roughly 500k TX timestamps on each of the Gigabit Ethernet ports of our devices (up to 10 ports in a 3U chassis). I'd say you did not see the most powerful appliances out there ;-)  ..

   > > It also offers hardware timestamping in the network infrastructure components, i.e. switches and routers, which can improve your sync performance dramatically.

>    Would you expect the network devices to gain support for the new
>    security protocol quickly, or is it more likely the leaf clocks would
>    need to bypass them and send their secured requests to new designated
>    clocks (avoiding the benefits of the hardware support)?

Well, it will take some time for sure, but if there is no standard, no hardware vendor would be willing to add this to their feature list. 

>    > However, especially unicast PTP is a great traffic amplification tool, maybe one of the biggest traffic amplification machines of all times. And I also believe that it would be great to (re)use the general concepts of NTS to secure the other popular time transfer protocol out there. 

  >  Yes, the near infinite amplification factor of the unicast PTP mode is
  >  a major concern, but I don't see what can be reused from NTS to fix
  >  that. NTS in NTP avoids amplification by the protocol design, not by a
  >  security mechanism.

Our draft reuses the NTS-KE phase of NTS4NTP for the key exchange. It uses the integrated PTP security mechanism and adds multiple protection mechanisms to PTP. See the "Security Considerations" part of the draft.

Regards,
   Heiko


    -- 
    Miroslav Lichvar