Re: [Ntp] Antw: Re: New rev of the NTP port randomization I-D (Fwd: New Version Notification for draft-gont-ntp-port-randomization-01.txt)

[Miroslav Lichvar <[e-mail]>]

On Wed, May 29, 2019 at 11:06:24AM +0200, Ulrich Windl wrote:
> >>> Danny Mayer <[e-mail]> schrieb am 29.05.2019 um 10:42 in Nachricht
> > You are totally missing the point. The port numbers don't make NTP
> > vulnerable. The "session id" does not exist here. Instead NTP has an
> > origin timestamp that an off‑path attacker does not have access to. Even
> > if it did, then the origin timestamp is wildly different each time it's
> > sent and is not predictable. This is a 64‑bit nonce.
> 
> ...of which about 30 bits are random (assuming the attacker knows what time it
> is and packets take less than one second to travel)...

I assume this whole discussion is about clients not using fully random
transmit timestamps (as specified in the data minimization draft).

30 bits is not that much. A typical NTP client running on a modern
computer can receive and process few hundred thousands packets per
second. This means it would accept a spoofed response in less than an
hour (assuming most of genuine responses from the server are dropped
in the network or socket). With 14 extra bits of entropy from the
source port it would be a year. That's a significant improvement.

In reality, I think it's quite a bit less than 30 bits. If we assume
the clock is accurate to 1 millisecond, it's only about 22 bits worth
of guessing. Then there are other things that may make this even
easier.

The client may be using a fixed 1-second timer to schedule its
transmissions and it may also be running as a stratum-2 server,
leaking the receive timestamp as the reference timestamp and leaking
the delay as root delay, which make the transmit/origin timestamp even
more predictable.

-- 
Miroslav Lichvar