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)

On 5/29/2019 2:06 AM, Ulrich Windl wrote:
>>>> Danny Mayer <mayer@ntp.org> schrieb am 29.05.2019 um 10:42 in Nachricht
> <c4384ecc-2711-3479-df21-d6533f438418@ntp.org>:
> 
>> On 5/29/19 12:18 AM, Fernando Gont wrote:
>>> On 28/5/19 23:20, Majdi S. Abbas wrote:
>>>> Randomizing the source port is pointless.  As Danny has noted, t1
>>>> already acts as a 2^64 nonce on each client mode chime request.  This
>>>> sufficiently hardens the unauthenticated case to an off path
>>>> attacker.  If additional security is required, authentication (via
>>>> classic PSK, or NTS modes) should be used.
>>> Using predictable numeric identifiers is a bad habit. We have plenty of
>>> history in this area and, as noted, it's quite interesting to see folks
>>> pushing in this direction in 2019, when the tendency has been to
>>> actually move away from predictable numeric IDs (TCP ISNs, transport
>>> protocol numbers, DNS TxIDs, Frag IDs, etc.).
>>>
>>> Using predictable port numbers makes it easy for an attacker to infer
>>> the "session id". You are just considering one possible attack scenario.
>>>
>> 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)...

How did you come up with 30 bits?

And remember that:

- the window of time where an attack is possible starts when the client
  sends its request, and ends when a valid response is received.
- a competent client will log bogus responses, at least during this
  window, and if the client is NTP as opposed to SNTP, will log
  *any* bogus received packets.

Further note:

- 30 bits is over a billion choices
- average clients can process maybe 2k packets per second
- the window of time on this attack is likely under a quarter
  to half a second, so 500-1,000 packets out of a billion
- MAC protection adds a *lot* of protection on this
- bogus packets received during the window are likely logged,
  and if MAC protected will generate a CRYPTO-NAK back to the
  real server, which, if reasonably implemented, will also
  be logged.

> [...]
> 
> Regards,
> Ulrich Windl
> 
> _______________________________________________
> ntp mailing list
> ntp@ietf.org
> https://www.ietf.org/mailman/listinfo/ntp
> 

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