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 <stenn@nwtime.org> Wed, 29 May 2019 17:15 UTC

Return-Path: <stenn@nwtime.org>
X-Original-To: ntp@ietfa.amsl.com
Delivered-To: ntp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E737612019F for <ntp@ietfa.amsl.com>; Wed, 29 May 2019 10:15:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jnyiu-xN0Ks7 for <ntp@ietfa.amsl.com>; Wed, 29 May 2019 10:15:05 -0700 (PDT)
Received: from chessie.everett.org (chessie.everett.org [66.220.13.234]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DCC47120198 for <ntp@ietf.org>; Wed, 29 May 2019 10:15:05 -0700 (PDT)
Received: from [10.208.75.157] (75-139-194-196.dhcp.knwc.wa.charter.com [75.139.194.196]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by chessie.everett.org (Postfix) with ESMTPSA id 45Dcls3PrmzL7T; Wed, 29 May 2019 17:15:05 +0000 (UTC)
To: ntp@ietf.org
References: <155841904754.12856.3727925672753047210.idtracker@ietfa.amsl.com> <9d21f083-4cba-1dd1-f5bb-c95984d3127b@si6networks.com> <9d74c6e3-244e-fdd7-184a-0572f4f144cd@ntp.org> <25275d68-8c18-1616-f226-dffe7e21091e@si6networks.com> <20190528174208.11253a67@rellim.com> <1a133133-5d6a-ca96-6c15-73e6933baffc@si6networks.com> <2794A95B-B118-40BD-AD60-DCB50CC32717@latt.net> <2107d74d-02da-cbd7-7a12-2837cb2e47a2@si6networks.com> <ced4c6d4-c34d-3460-eccc-b5608fbd340e@nwtime.org> <b4faacdf-3d9b-5e47-2415-276ef3d7f3af@si6networks.com> <69295233-497e-fa31-3270-691407fb6f30@nwtime.org> <15a5c387-8a44-5d7e-404b-e953a7a81737@si6networks.com> <f1b43a93-83cb-4a8a-1cbb-dcfda1e12943@pdmconsulting.net> <3ac96dec-e1ca-c0d0-1cda-7bb55c641a4c@si6networks.com>
From: Harlan Stenn <stenn@nwtime.org>
Openpgp: preference=signencrypt
Autocrypt: addr=stenn@nwtime.org; prefer-encrypt=mutual; keydata= mQGNBFI2xmQBDACrPayw18eU4pIwCvKh7k0iMkAV9cvzs49kBppM+xoH+KKj4QWmkKELD39H ngQnT3RkKsTLlwxyLqPdUmeQNAY2M5fsOK+OF6EvwLPK9hbmE3Wx2moX+sbEUxJ2VzFhKSKb OPZALXwk1XxL0qBedz0xHYcDwaSAZZkEFXURv2pDIdrmnoUnq2gdC8GpoFJiXoUaCLSYzzaY ac4Njw7Mue8IqfzRQb70aMjXl/qmsmfmEVAyGXywDdc/ler4XSgiuYOV7Kf69bj9PFZZSMdJ MWgEyZH6lJ0TU5ccR2zp5ZRmWzQQkxJMyH2th7q0Nmz3aX4A0K4yE0Ba9/5Dr7ctpF15BrMF aEo4s5lwI6tUnkgMWo265mMzCz4mAPV/ac0w0OXQg7r9E2r0+dRapnzUlG43D0JLDqDr9uRR L6IrRQqoCWUC75lfmPYQYSlaTJaK68r3lXd0z1cXJUgVtEL5H3/Z71R2B20twcQVAnw2iIH6 L5vdrsIjHrMmkqRVbs9nNyEAEQEAAbQ5SGFybGFuIFN0ZW5uIChOZXR3b3JrIFRpbWUgRm91 bmRhdGlvbikgPHN0ZW5uQG53dGltZS5vcmc+iQG5BBMBAgAjBQJSNsblAhsvBwsJCAcDAgEG FQgCCQoLBBYCAwECHgECF4AACgkQyIwAt1pH+kBlzgv/QOg70vdj8wU/z97UPdlbxtN4THAB gfSX4N0VPKT5fjX1tFhuXZQAOv7wedR3Trh7TGteyg33TBAFf9A42mXZKi1IxAiQG118Hd8I 51rXwnugURIYQaIyQI+vbchRbwVyz+mVLTI/h6FdbsVzT4UFmir+ZMkb/XeZPu0HItk4OZHE 6hk+TuTiCnlqlCPLq371fXV54VOb91WZYD8EQFtK02QHGHsQqWvapdphiDVpYehmsPyiTESq NMKLVtjtyPkQ6S7QF3slSg+2q3j8lyxEA78Yl0MSFNU8B/BtKgzWP2itBOfi+rtUKg+jOY1V /s2uVk2kq2QmHJ/s5k5ldy3qVvoTpxvwBe0+EoBocTHYt+xxp0mTM6YY1xLiQpLznzluqg9z qtejX1gZOF4mgLiBIrhXzed3zsAazhTp5rNb1kn0brZFh6JC5Wk941eilnA4LqX8AWo0lmwo eb+mpwZK/5lNdage/anpVqft9wJ/8EcvST9TLUO4fPrmT3d/0LpWuQGNBFI2xmQBDADXLsBk I7CSa5UXlrNVFJQHER1VxRBKqjWWCh/8Qv9v3p3NrIc2UnhoZ1uWQ2voBGty5Xfy9k4afV5k WwDyRDUIb7PX+Tj4HjVVr7qvnOVe/0KzZpNq0Azd0ggFbsM+8mydktHIwJykW0NUsGwPRYuD OA0Lro0ohb5IiCt3sSQi1X1hYjo7O1Vmn8Gy/XYOnhnMux+5zDPO2yTkCNX5PocYi9IJJy6p Mq1yQV4Y2Dl8KtQzvtq55vCUxx6n0MMzFViGwNW6F4ge9ItO4tDScsgowDrHa208ehwOpv/i wjf93lCClQ6vaKmOBX872K/tdY/hwhxPPjgl1bcrOwMRYVemOPPehwnXH5bwclk1hvDQdkJQ 5pJOkE4VCryTF/iDAt4g2QnHocUwt3b6/ChUUWmj2GZ22OR12rbnCtLedwp0DpViKPUCQHBO vpgXdzE/L9zWar9fqM0EREMgfWbsJc9028qluCcFLIN1gYsq4cC+YGAcOu7HOI5orBBV4m9j XfsAEQEAAYkDPgQYAQIACQUCUjbGZAIbLgGpCRDIjAC3Wkf6QMDdIAQZAQIABgUCUjbGZAAK CRDfCQ/G52/8P/uWDACe7OEM+VETDRqjQgAwzX+RjCVPvtgrqc1SExS0fV7i1mUUxr/B8io3 Y1cRHFoFKmedxf8prHZq316Md5u4egjFdTT6ZqEqkK0hvv+i0pRpCa5EX9VIStcJStomZp8F cY34grA+EOWITaLQ4qNZUP7rf2e7gq1ubQTj7uLr6HZZvMZ5em+IvrOWEuWDI6yOiI6px04w RDfkoR2h6kgdw4V0PT4NjK9WYYKrVCf1bjLlVImNBEcXfvlUTrIYO8y6ptvoUsBQky5pQRvP 99Pn42WfyLy50aII6+vyudD4T0yLjXAz4KteUttxtIte64m/F9/7GEIZAxTUcLyOq/7bP4le h39jBckwc62iYzeK/VkU/bMMh2D68Z3QylMnhhcW27BcgQHPKsHhmFa2SNytYcuQiSdf9+pj 4i32ETz1nJAvYAAqgTF/0PL+8ZNQoEpe/n9woMKrlZrqD4EgFmhQ3bNVhlaXz1nuTZDrwPt1 yMxBuUNbCF4jFnaruwrSiGTRoIfUZQwAjQglahrV4/mcjfnvbNoseHX0PKd9q+wjg7MIjWqr f2CI8Fa6MdanqwYphz43I2yXANKFZuMWsWqyQYlvGuPUlUUcAL3stp24RkzDB1Q+JS0IZJST T2JSu0aTfUdWVNqr2UI19eX+zxbOTckSi3Ng14ezG8ZX194ZH10b8JzntQOwmA20pd5JDhug zQfASER+CZDiPPcQ4mvC4y7rMrfV6XGQbDynC3ekDxo8SC5SvjaczXMwXg6SZ8iFtEWmEwW9 r7zPjjIPDrX8w5LXBgxArM5o/HbERpc2EdAvMh1D7LC0SvmoE7fBKxsicVBe4h6vXjEZ+LLr /wuZiBld9OnxAUIpwptbBspO6WKTQYvgFH2OeDG27hiE5P4Xs4WSp5j9ez8OVB1iZnA2nCQ+ tNTjO8c+C/P92vPLx5+bpGRXTXMNaLh34PS3ZsYoUDkKZNhczRZUWJ7nynSbeeyF+QW7SLwA qY7O7dyk9LFTsfJqRQJ7tWnIAjJPCwmSgQ8Kl0UJ
Message-ID: <5534f617-f15b-41f7-a89a-813afadb10f7@nwtime.org>
Date: Wed, 29 May 2019 10:15:04 -0700
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.7.0
MIME-Version: 1.0
In-Reply-To: <3ac96dec-e1ca-c0d0-1cda-7bb55c641a4c@si6networks.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/ntp/DkPkpdJ705u4GTr2hzqjS3SVH2Q>
Subject: Re: [Ntp] New rev of the NTP port randomization I-D (Fwd: New Version Notification for draft-gont-ntp-port-randomization-01.txt)
X-BeenThere: ntp@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <ntp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ntp>, <mailto:ntp-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ntp/>
List-Post: <mailto:ntp@ietf.org>
List-Help: <mailto:ntp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ntp>, <mailto:ntp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 29 May 2019 17:15:08 -0000


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!