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

Hi!

I think in case of a DDoS attack the extra 14 bit of random port give little
extra protection: The attacker could send to any port (or from virtually any
port) on the attacked machine.

Regards,
Ulrich Windl

>>> Fernando Gont <fgont@si6networks.com> schrieb am 29.05.2019 um 06:18 in
Nachricht <f03dbfbd-007a-fa81-f846-85079a59dddd@si6networks.com>:
> 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: fgont@si6networks.com 
> PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
> 
> 
> 
> 
> _______________________________________________
> ntp mailing list
> ntp@ietf.org 
> https://www.ietf.org/mailman/listinfo/ntp 