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 11:23, Danny Mayer wrote:
> 
> On 5/29/19 6:03 AM, Fernando Gont wrote:
>> 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.
>>
> what predictable ID's? NTP doesn't have a counter.

The client port is a numeric identifier. So the NTP does use a numerical
identifier. As noted, you essentially have three options:

1) Use a fixed value (123)
2) Use an ephemeral port resulting in a predictable port
3) Use a randomized source port


So.. there's one implementation that does #1, and folks seem to argue to
stick with it. #2 would require even more work, because most modern
kernel just don't generate predictable port numbers. And we are arguing
in favour of #3.


(#2 could be implemented as a counter. In fact, that's how most stacks
selected ephemeral port numbers prior to the port randomization work).



> attackers can send any packets that they want to a port, that's at the
> UDP layer. Whether or not the packet is valid is something that the
> receiving client is supposed to be checking. 

The four-tuple {src addr, src port, dst addr, dst port} is layer-4
stuff. If you conceal this info, you reduce the chances of an attacker
of sneaking a packet into the association/"connection".

Any checks you perform in NTP are app layer stuff. The two are orthogonal.



> Malformed packets are
> instantly discarded and invalid origin timestamps are similarly tossed.
> 
> Your draft should be stating a useful purpose and the contents needs to
> actually fulfill that purpose. All we have so far is some claim about
> what port to use without showing how that is better than all of the
> other safeguards already built into the NTP protocol.

That's the point: the two don't compete with each other. They are
orthogonal.

I'm not arguing that we should remove the others. Rather, I'm arguing
that using predictable client port numbers eases the task of an
attacker, unnecessarily.

Using randomized port numbers requires yet additional effort on the side
of the attacker. And means that the attacker now needs to guess the
client port, or otherwise his packets will not even make it to the ntp
process.


The transport area produced a BCP over the course of about 7 years, when
discussing similar topics. The BCP is RFC6056.

I would expect that an implementation that means to select a port
number, and does not want to follow, should make a technical argument
against that.

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