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)

[Harlan Stenn <[e-mail]>]

On 5/29/2019 3:06 AM, Miroslav Lichvar wrote:
> 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).

And this may also be a terrible idea.  It prevents the server from
having any idea how accurate the client may be.

> 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.

You're seeing different numbers than I am.  I'm seeing typical NTP
clients handle the numbers I quoted, and low-end embedded clients
handling at least an order of magnitude fewer.  I'm talking about
packets that do *not* have MAC protection.  The thruput rate would drop
for MAC protected packets.

> 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.

This may be true for an NTP client.  I would like to see numbers for an
SNTP client where the clock free-runs for hours to days at a time.

> 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.

How is an off-path attacker going to see this information?

Why is a stratum 2 server in a hostile environment not using MAC
protection, or using enough upstream servers?

-- 
Harlan Stenn, Network Time Foundation
http://nwtime.org - be a Member!