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 29/5/19 05:18, Harlan Stenn wrote:
> 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:
[....]
>>
>> 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.

I understand that your implementation employs port 123 as the source
port. You mentioned that makes the code simpler. That's probably also
the case when using predictable IDs (e.g. resulting from a counter) vs.
randomized ones.

Protocol-wise: could you state what are the drawbacks of employing
randomized port numbers?



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

The point I was trying to make is that if it was so vital protocol-wise
that a specific port were used as the source port, then NTP would not
work across NATs. Of course it does work, because the client port can be
anything.




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

Difficulty in hitting the four-tuple being employed for NTP?




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

Yes, my bad. This is open, without a recommendation on what to do. The
implementation I was running was indeed using port 123.




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

Not much like that. Actually, I was analyzing traffic, and then going
through the spec, and surprised the client port used by the
implementation I was running was employing port 123. Tried to track why
that was the case.

Having worked on predictable numeric ids for a number of protocols, I
expected this to be an historical artifact, in the area of "yeah,
sure... we should have been randomizing it", do the recommendation and
move on.



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

I'm still trying to figure out e.g. what your implementation does or
expects to do when you e.g. receive NTP packets with right four-tuple
and, say, invalid org timer. Anything else other than toss the offending
packets out? And, if that's the case, why are you interested in
processing them instead rather than have them tossed before they get to
the NTP process?


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

FWIW, I'm interested in your feedback.


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