Origin Timestamp as Transaction ID

[davidv1992]

reported by jsha

The origin timestamp in outbound packets is used to identify reply packets. This is a good measure against off-path attackers, similar to how DNS uses source port randomization in addition to query id to make it hard for spoofed packets to interfere with operations.

In ntp-proto/src/peer.rs, the next_expected_origin is kept live until either (a) a packet with that timestamp is accepted, or (b) the next poll interval arrives. Since the poll interval can be quite long at the maximum (many hours), this gives a long window for attackers to send packets guessing origin timestamp values. I recommend having a maximum time (on the order of seconds) past which reply packets won't be accepted, independent of the poll interval.

I recommend adding a small random delay to the poll time to make it harder for an attacker to guess when a poll request is inflight. This also has the happy operational effect of preventing a situation where a fleet of clients all make their poll requests at the same time.

Handle_incoming checks for a match with next_expected_origin before checking whether a packet is a Kiss-O'-Death (KoD) packet. The RFC says:

The Receive Timestamp and the Transmit Timestamp (set by the server)
are undefined when in a KoD packet and MUST NOT be relied upon to
have valid values and MUST be discarded.

This suggests KISS checks should come before the next_expected_origin checks and should not be able to redeem next_expected origin. The MUST discard suggests these fields should be cleared during packet parsing.

The downside of following the spec here is that KISS packets can be easily forged by off-path attackers if they are not validated against next_expected_origin. In practice, do common NTP deployments copy the transmit timestamp? I suspect there may be some deployments where KISS packets are generated by a firewall without copying data from the inbound packet.

[davidv1992]

On checking for next_expected_origin before handling KoD packets, the RFC specifically states that the receive and transmit timestamps cannot be trusted. Since the next_expected_origin is matched against the origin timestamp, this should still be within spec, although it is a bit unclear if this is really the case. Given the ease with which KISS packets could otherwise be forged, I suggest we keep our current aproach for that.

[davidv1992]

Tracking for delay and validity reductions:

• Make next_expected_origin valid for limited amount of time. #199
• Add random delay to poll interval. #200

[jsha]

he RFC specifically states that the receive and transmit timestamps cannot be trusted. Since the next_expected_origin is matched against the origin timestamp, this should still be within spec, although it is a bit unclear if this is really the case.

I made an error in reading the spec - I was confusing the Transmit Timestamp with the Origin Timestamp and believed the spec was saying that the Origin Timestamp comparison could not be used for KoD packets. But on re-reading it I see that's not the case, and Origin Timestamp is still expected to be set even in KoD packets. So I believe the current approach is good.

[davidv1992]

With the changes made, this should now be fixed.