NTS part 2

Part 1: Packet format of Network Time Security

I wanted to measure the overhead that NTS adds to NTP.

To give a rough estimate, I modified the benchmark program included in libaes_siv to use similar parameters as what NTS uses:

Decrypt, 256 bit key, 16 byte nonce, 16 byte input, 192 byte associated data: 1899.17 ns/call

This is 0.002ms.  The encrypt call was around the same amount of time.  These numbers are going to be hard to measure on a public service over the internet.  There's a lot of other things happening that will impact the latency 1000x more.

So I setup one client using NTP and another client using NTS.  RX and TX timestamps are from the kernel (SOF_TIMESTAMPING_*_SOFTWARE).

This was a poor result.  My two different clients were using two different source ports.  I assume I'm being hashed onto different physical servers with ECMP.  Let's try running this again with one source port, alternating NTP vs NTS packets:

It's hard to tell the difference between the two protocols at this scale.  Let's switch to a histogram.

These results are pretty close, but NTS is slightly slower.  And by slightly I mean:

NTP mean/min: 1.623ms/1.467ms

NTS mean/min: 1.633ms/1.488ms

NTS adds around 0.010ms to 0.020ms to the Round trip time.

Encryption & signing the associated data happens after the timestamps are put on the packet.  This should cause an offset of less than 0.020ms.  The VM I'm testing from gets its time sync from multiple GPS based stratum 1s, and was within +/-0.100ms of GPS's UTC during this test.

Here you can see NTS and NTP protocols agree closely on the offset, but Cloudflare's clock is wandering between +0.467ms and +0.829ms.  

Next, I'll remove the mean offset of 0.665ms to make it easier to see the frequency changes.  And I'll add the GPS stratum 1 I'm currently using as my time source.

Here you can see the clock on time.cloudflare.com swinging between slow and fast, overshooting the exact frequency by around +/-100 parts per billion.

Since looking at the offset directly isn't useful, I'll try and eliminate the clock differences by looking at the difference between the NTS and NTP offsets made within the same 2 minute window.

This is a much better result, and has a mean value of 0.009ms.  This shows the NTP and NTS protocols agree pretty closely on the time.

Summary

The NTS protocol is able to deliver time to a level that most people won't notice the difference from NTP, especially over the internet.  It brings security enhancements that are not a common problem that people are focused on, but it isn't an expensive change.