Transmit timestamp of the pool monitoring

At this moment the transmit timestamps of the monitoring queries are random values. The explanation is that it is for privacy (sic!) and prevent spoofing. Isn’t the UDP source port for the query is random enough for the same purpose? Or as a compromise, for the transmit timestamp use the local time minus a smaller random value ( 2 bytes long). Together with the UDP source port that would give about 31 bit randomness, which I believe would be sufficient protection against any packet spoofing attempt.

We should exclude the possibility, that certain packet drops are due to some router are checking for crazy transmit timestamps (for example way ahead in the future).

1 Like

Random source port makes spoofing attacks more difficult, but if the transmit timestamp is predictable (e.g. constant), the random port alone is not enough.

Some clients have been using fully randrom transmit timestamps for a long time. If it caused an issue with networking devices, I think we would know it by now.

The reason why we have these problems is that the devices that drop NTP packets don’t examine their content. When I asked a major ISP why they don’t just block the NTP modes that allow amplification (i.e. mode 6 and 7), they said the hardware they use cannot do that.

2 Likes