nav search
Data Center Software Security Transformation DevOps Business Personal Tech Science Emergent Tech Bootnotes BOFH

Network Time Protocol updated to spook-harden user comms

Network time lords decide we don't need IP address swaps

By Richard Chirgwin, 29 May 2017

The Internet Engineering Task Force has taken another small step in protecting everybody's privacy – this time, in making the Network Time Protocol a bit less spaffy.

This Internet Draft, published last week, calls for changes in Network Time Protocol (NTP) clients – and devs will be pleased to hear it won't be that difficult to implement.

As the draft explains, the RFCs that define NTP have what amounts to a convenience feature: packets going from client to server have the same set of fields as packets sent from servers to clients.

A lot of that information is specific to packets that originate from the server (mode 4, server-to-client responses; mode 5, broadcast packets; and modes 1/2, packets between peers).

The same fields appear in client-to-server packets (mode 3), they're not necessary, and the draft says they're a privacy risk to users.

“Populating these fields with accurate information is harmful to privacy of clients because it allows a passive observer to fingerprint clients and track them as they move across networks”.

The header fields in question are “Stratum, Root Delay, Root Dispersion, Reference ID, Reference Timestamp, Origin Timestamp, and Receive Timestamp”.

The Origin Timestamp and Receive Timestamp offer a handy example or a “particularly severe information leak”. Under NTP's spec (RFC 5905), clients copy the server's most recent timestamp into their next request to a server – and that's a boon to a snoop-level watcher.

“Therefore, when a client moves between networks, a passive observer of both network paths can determine with high confidence that the old and new IP addresses belong to the same system by noticing that the transmit timestamp of a response sent to the old IP matches the origin timestamp of a request sent from the new one.”

Because the fields are there, clients populate them with accurate information; the draft says client developers should, instead, set the fields to zero – and it shouldn't break anything, because as the draft states, “Server implementations never need to inspect them, and they can achieve nothing by doing so”. ®

The Register - Independent news and views for the tech community. Part of Situation Publishing