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 9:31 AM, Fernando Gont wrote:
> 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

I'm not seeing that ephemeral UDP ports are predictable in general.  Got
a reference?

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

So what?  An off-path attacker won't know these ports, an on-path
attacker won't(?) see them either, and a MITM won't care because the
MITM will see the port selected by the victim.

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

If the implementation is so poor that it would be victim to this attack
then this specific attack is very late to the party.

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

I'm not sure about this argument.

Stuff should be addressed at the appropriate API layer.

There are good reasons why one doesn't only put the smallest grain
filter at the entrance point.

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

Sorry, I'm still not seeing/buying this point.

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

If your point is to change the last sentence of RFC590 9.1 where it 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.

to:

   ... In other modes, it SHOULD contain any number consistent with
   local policy.

I'm fine with that.

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

Deep packet inspection firewalls are Expensive, especially at higher
bandwidths.  Having these packets go out with known port number can be a
significant cost and performance savings.

That's just one point.

> Thanks,
> 

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