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

[Fernando Gont <[e-mail]>]

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.



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

If tomorrow a flaw were found in an NTP implementation, that happened
e.g. prior to the validation of the origin timestamp, I guess you are
going to argue that "that was out of scope"?



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

Please enlighten me:
Could you please explain why NTP needs a well-known transport protocol
number when operating in client/server mode?



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

Of the implementations I've checked, there's only one that doesn't do it.

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