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

From: "[email-masked]" <[email-masked]>
Date: Wed, 29 May 2019 08:56:22 +0300

Port randomization is used to block port spoofing mitm attacks as part of a larger audit framework. 

It is part of a delivery based assurance process not an informatioin integrity process like a whopping nonce is. 

Keeping the components of the trust model separate has value. The real issue is how big the port smash threat is. 

//tsg

Sent from my HTC, so please excuse any typos.

----- Reply message -----
From: "Majdi S. Abbas" <[email-masked]>
To: "Fernando Gont" <[email-masked]>
Cc: <[email-masked]>, "Gary E. Miller" <[email-masked]>
Subject: [Ntp] New rev of the NTP port randomization I-D (Fwd: New Version Notification for draft-gont-ntp-port-randomization-01.txt)
Date: Wed, May 29, 2019 06:20

Fernando,

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.

Per session randomization doesn't resolve these issues -- the stated rationale for both the draft and filed CVE is hardening to off path attacks, which we've just covered.

"Because it's best practice" isn't a reason -- it's a crutch to save a draft that was filed due to an insufficient understanding of RFC 5905 and current implementations of NTPv4.  The true best practice here is authentication, and it does not seem to be a worthwhile effort
to restructure existing implementations to add 16 bits to
the existing nonce with work like NTS
pending to cover the client/server use case.

Cheers,

--msa

_______________________________________________
ntp mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ntp

---

From: Harlan Stenn <[email-masked]>
Date: Tue, 28 May 2019 22:59:02 -0700

> of a larger audit framework. 

MITM attacks don't really count here.  A MITM can see the packets, so
the choice of port number doesn't make any difference there.

H
--
> It is part of a delivery based assurance process not an informatioin
> integrity process like a whopping nonce is. 
> 
> Keeping the components of the trust model separate has value. The real
> issue is how big the port smash threat is. 
> 
> //tsg
> 
> Subject: [Ntp] New rev of the NTP port randomization I-D (Fwd: New
> Version Notification for draft-gont-ntp-port-randomization-01.txt)

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

---

From: Fernando Gont <[email-masked]>
Date: Wed, 29 May 2019 02:57:39 -0400

On 29/5/19 01:56, [email-masked] wrote:
> Keeping the components of the trust model separate has value. 

As noted elsewhere, it also allows for other things such as filtering
attack packets in the network (stateful filtering).

Thanks,
-- 
Fernando Gont
SI6 Networks
e-mail: [email-masked]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492