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

[Danny Mayer <[e-mail]>]

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.

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

Danny