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: Fernando Gont <[email-masked]>
To: Harlan Stenn <[email-masked]>, [email-masked]
Date: Wed, 29 May 2019 03:17:46 -0400
List-Id: <ntp.ietf.org>

On 29/5/19 01:20, Harlan Stenn wrote:
> 
> 
> On 5/28/2019 9:37 PM, Fernando Gont wrote:
>> On 28/5/19 23:20, Majdi S. Abbas wrote:
>>> 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.  
>>
>> Oh, by the way. While you enlighten me why you need a fixed well-known
>> port number for the client, and how necessary this is, please also
>> elaborate on how I'm running multiple NTP clients behind a NAT box.
> 
> Nobody seems to be saying there is benefit to *only* using the
> well-known port number when sending a client request.  People are saying
> that requiring this in all cases doesn't buy any significant benefit.

Employing predictable numeric IDs is bad practice. The current
requirement (which cannot even be complied to in IPv4-NATed networks),
requires a fixed well-known port for clients. i.e., the spec mandates
against a BCP (port randomization) and on the well-known concept that
employing predictable IDs is asking for trouble.

Our document reverses that: It recommends what's is known to be a good
practice, and gives you room (it's a "SHOULD", not a "MUST") if you have
a really good reason not to randomize the client port.

As noted in some other message, the analysis so far has focused on
attack packets that might get tossed if the org timer is not valid.
There might also be implementation bugs (e.g., buffer overflows, or
whatever) that happen before that.

> Of course it's fine if NTP client goes thru a NAT gateway.

That's an indication that the current requirement in the spec is bogus.
In fact, if you actually mandated it (e.g., the server were to require
that the client port be 123), deployed clients would break.

> So here's a related question for you:
> 
> Is there benefit to knowing if you are being attacked?

That's orthogonal to this. You don't need to leak the session ID in
order to run a NIDS. -- and, no matter what you have in mind, I'll
repeat the above: the requirement is in "SHOULD" level -- you can go
against it if you have a really good reason to.

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