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

[Harlan Stenn <[e-mail]>]

On 5/29/2019 12:17 AM, Fernando Gont wrote:
> 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.

By the same token, generally applying rules without fully understanding
the costs/benefits and other trade-offs is bad practice.

The NAT case you mention is a red herring.  That case effectively
randomizes the port already, at least outside the LAN.

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

I'll re-read the proposal, and if the proposal doesn't go in to the
pros/cons of the choices then the proposal is, IMO, fatally deficient.

I'm pretty comfortable in my belief that I think I have a good awareness
of these issues.

You believe you have a similar awareness.

But I submit the vast majority of folks who will read this will not have
the level of awareness to make an informed decision.

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

When would a packet with an invalid org timer *not* be tossed?  This
sounds like another straw-man to me.

> There might also be implementation bugs (e.g., buffer overflows, or
> whatever) that happen before that.

So what?  Really - what difference would the port number make if there
are implementation bugs of the type you now hypothesize?

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

RFC5905 section 9.1 says:

   srcport: UDP port number of the server or reference clock.  This
   becomes the destination port number in packets sent from this
   association.  When operating in symmetric modes (1 and 2), this field
   must contain the NTP port number PORT (123) assigned by the IANA.  In
   other modes, it can contain any number consistent with local policy.

Where is the "current requirement in the spec", and who is proposing a
"mandate"?  Your points seem to be at least red-herrings, and could be
full-on straw man fallacies.

You are very certain of the number and scope of your use-cases.  I
believe the problem scope and use-cases are more diverse than what you
describe, and your solution, while appropriate for some of these,
*prevents* detection/remediation in other scenarios.

If you know these things, then you're trolling and wasting people's time
and energy.  If you don't know it, then ... I'll stop there.  But maybe
I'm missing something.

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

I'd be a lot more receptive to your points if you showed more awareness
of the tradeoffs and identification of the various problem scenarios and
use-cases, and made proposals that were better rooted in reality.

But I'm not sure anybody besides me cares about my opinion/position on
your proposal.

> Thanks,

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