Nico and Danny,

It might help to explain the issues in the NTP white papers at the NTP project page www.eecis.udel.edu./ntp.html. Chapter 16 in the book shows the results of experiments using interleaved mode, which might be of interest in PTP broadcast issues. The paper on Simulation and Analysis of the NTP On-Wire protocol uses a two-step process similar to PTP. The paper on NTP Security Analysis may have lessons for PTP authentication. The NTP Autokey model needs help, as suggested in that paper.

Dave

Nico Williams wrote:

On Thu, Oct 13, 2011 at 7:07 PM, Danny Mayer <ma...@ntp.org> wrote:
On 10/13/2011 2:28 PM, Kevin Gross wrote:
Definitely important issues for some synchronization protocols but it
seems though two-step 1588 would work through such a connection. The
followup message will contain an accurate (and encrypted) timestamp.
Encryption delays would not result in significant loss of accuracy with
respect to an unencrypted connection also using two step.
Has anyone tested or measured that? I have not seen any information how
this will work without losing accuracy. Don't forget the followon
message will also have to be encrypted and decrypted when sent making
for additional uncertainties and errors. I have not reviewed how the
two-step IEEE 1588 protocol works so I don't have a good understanding
of the effects of IPsec encryption on such packets.

The cost of crypto can be measured, and performance generally
deterministic (particularly when there's no side channels in the
crypto) (assuming no mid-crypto context switches), so that it should
be possible to correct for the delays introduced by crypto (just as
it's possible to measure and estimate network latency).  Indeed,
crypto processing will likely be more deterministic than network
latency :)

However, I do agree that there's no point to encrypting time
synchronization signals unless they facilitate traffic analysis (say).
Nor do I see the point of using WESP for this.  Also, NTP has a
public key authentication facility nowadays -- why not use it?

Nico
--

_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Reply via email to