[time-nuts] Time security musing - attacking the clock itself

Hal Murray hmurray at megapathdsl.net
Tue Dec 4 03:44:50 UTC 2012

xe1xus at amsat.org said:
> On the other hand PTP is evolving to be a future protocol for time transfer.
> Nowadays it is superior than NTP in the LAN environment.

"Superior" is an interesting word.

I'm not familiar with the details of current PTP implementations.  I am 
reasonably familiar with the NTP reference package which is shipped with most 
Linux/*BSD distributions and also runs on Windows.  (The Windows default is 
to use SNTP, S for Simple or maybe Stupid.  You have to go out of your way to 
install ntpd on Windows.)

NTP is intended for use in the big bad Internet.  Much of the logic/code in 
ntpd is trying to dance around broken clocks or broken servers or crazy 
networks.  It has a crypto option, but it's not used very often.  (There are 
plenty of problems before you get to one that needs crypto.)

After the classic ntp client-server/request-response exchange, the client has 
4 time stamps.
  When the request left the client.
  When the request arrived at the server.
  When the response left the server.
  When the response arrived back at the client.
The middle two are using the server's clock.  The first and last use the 
clients clock.

The reason that you need 2 server times is that the server may be busy (for 
example doing crypto crunching) or whatever.  Normally both server time 
stamps are very close together.

If you assume that both clocks are accurate, that lets you measure network 
timings in both directions.

NTP assumes the network transit times are symmetrical.  That lets you 
calculate the clock offset.

I have a slow DSL line.  If I start a big download, the queuing delay on my 
DSL line jumps up to a second or so on average.  (lots of noise)  If I go web 
browsing and hit a page with lots of graphics, the queuing delays can almost 
get to 4 seconds.

That basically screws up the symmetrical assumption.  If you are interested 
in this area, you should study and understand this web page:

Clients using NIST servers sometimes see this problem with the other sign.  
They have queuing delays at the input to the server because zillions of 
clients are pounding on the server.  The input (to-server) link sometimes 
gets overloaded, even with 100 megabit Ethernet connections.  (maybe 
faster...)  That's the top edge of the wedge diagram rather than my bottom 


PTP is basically making the network transit times more accurate than 
"symmetrical" by measuring them.  Each box that processes a packet updates 
the packet with the processing/queuing delays.

I think the PTP geeks are working on crypto.  I'm not tracking the details.

These are my opinions.  I hate spam.

More information about the time-nuts mailing list