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 <fgont@si6networks.com> Wed, 29 May 2019 19:01 UTC

Return-Path: <fgont@si6networks.com>
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 874AB120242 for <ntp@ietfa.amsl.com>; Wed, 29 May 2019 12:01:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, 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 s_qNL_vgKzxs for <ntp@ietfa.amsl.com>; Wed, 29 May 2019 12:01:00 -0700 (PDT)
Received: from fgont.go6lab.si (fgont.go6lab.si [91.239.96.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 17CBC120170 for <ntp@ietf.org>; Wed, 29 May 2019 12:00:50 -0700 (PDT)
Received: from [192.168.1.2] (unknown [212.133.201.30]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id C03D588C41; Wed, 29 May 2019 21:00:47 +0200 (CEST)
From: Fernando Gont <fgont@si6networks.com>
To: Harlan Stenn <stenn@nwtime.org>, 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> <5534f617-f15b-41f7-a89a-813afadb10f7@nwtime.org>
Openpgp: preference=signencrypt
Autocrypt: addr=fgont@si6networks.com; prefer-encrypt=mutual; keydata= mQINBE5so2gBEACzBQBLUy8nzgAzSZn6ViXT6TmZBFNYNqTpPRvTVtUqF6+tkI+IEd9N2E8p pXUXCd0W4dkxz6o7pagnK63m4QSueggvp881RVVHOF8oTSHOdnGxLfLeLNJFKE1FOutU3vod GK/wG/Fwzkv9MebdXpMlLV8nnJuAt66XGl/lU1JrNfrKO4SoYQi4TsB/waUQcygh7OR/PEO0 EttiU8kZUbZNv58WH+PAj/rdZCrgUSiGXiWUQQKShqKnJxLuAcTcg5YRwL8se/V6ciW0QR9i /sr52gSmLLbW5N3hAoO+nv1V/9SjJAUvzXu43k8sua/XlCXkqU7uLj41CRR72JeUZ4DQsYfP LfNPC98ZGTVxbWbFtLXxpzzDDT8i3uo7w1LJ2Ij/d5ezcARqw01HGljWWxnidUrjbTpxkJ9X EllcsH94mer728j/HKzC9OcTuz6WUBP3Crgl6Q47gY5ZIiF0lsmd9/wxbaq5NiJ+lGuBRZrD v0dQx9KmyI0/pH2AF8cW897/6ypvcyD/1/11CJcN+uAGIrklwJlVpRSbKbFtGC6In592lhu7 wnK8cgyP5cTU+vva9+g6P1wehi4bylXdlKc6mMphbtSA+T3WBNP557+mh3L62l4pGaEGidcZ DLYT2Ud18eAJmxU3HnM8P3iZZgeoK7oqgb53/eg96vkONXNIOwARAQABtCVGZXJuYW5kbyBH b250IDxmZ29udEBzaTZuZXR3b3Jrcy5jb20+iQJBBBMBAgArAhsjBQkSzAMABgsJCAcDAgYV CAIJCgsEFgIDAQIeAQIXgAUCTmylpQIZAQAKCRCuJQ1VHU50kv7wD/9fuNtTfxSLk3B3Hs3p ixTy8YXVjdkVwWlnJjFd7BOWmg7sI+LDhpjGfT6+ddOiwkumnvUZpObodj4ysH0i8c7P4C5t F9yu7WjklSlrB5Rth2CGChg5bKt541z2WHkFFxys9qBLmCSYDeKQkzLqhCjIUJizY2kOJ2GI MnSFDzJjhSFEh//oW830Y8fel1xnf/NVF+lBVtRMtMOfoWUqDjvP3sJ1G4zgkDCnF0CfncLx +hq2Mv26Uq9OTzvLH9aSQQ/f067BOkKAJKsfHdborX4E96ISTz57/4xECRSMr5dVsKVm4Y// uVIsb+L5z+a32FaiBZIAKDgnJO7Z8j6CV5e5yfuBTtX52Yi9HjYYqnYJGSDxYd6igD4bWu+7 xmJPHjkdqZgGV6dQIgiUfqkU+s5Cv350vK48CMaT/ZLo2BdsMhWsmaHmb+waePUMyq6E4E9x 9Js+EJb9ZiCfxS9exgieZQpet1L36IvhiwByvkQM009ywfa30JeMOltUtfLi5V06WQWsTzPL 5C+4cpkguSuAJVDTctjCA0moIeVDOpJ8WH9voQ4IeWapQnX35OIoj1jGJqqYdx65gc1ygbyx b8vw+pJ9E5GLse5TQnYifOWpXzX9053dtbwp/2OVhU4KLlzfCPCEsoTyfu9nIZxdI2PMwiL5 M85BfjX4NmwBLmPGoLkCDQRObKNoARAAqqXCkr250BchRDmi+05F5UQFgylUh10XTAJxBeaQ UNtdxZiZRm6jgomSrqeYtricM9t9K0qb4X2ZXmAMW8o8AYW3RrQHTjcBwMnAKzUIEXXWaLfG cid/ygmvWzIHgMDQKP+MUq1AGQrnvt/MRLvZLyczAV1RTXS58qNaxtaSpc3K/yrDozh/a4pu WcUsVvIkzyx43sqcwamDSBb6U8JFoZizuLXiARLLASgyHrrCedNIZdWSx0z0iHEpZIelA2ih AGLiSMtmtikVEyrJICgO81DkKNCbBbPg+7fi23V6M24+3syHk3IdQibTtBMxinIPyLFF0byJ aGm0fmjefhnmVJyCIl/FDkCHprVhTme57G2/WdoGnUvnT7mcwDRb8XY5nNRkOJsqqLPemKjz kx8mXdQbunXtX9bKyVgd1gIl+LLsxbdzRCch773UBVoortPdK3kMyLtZ4uMeDX3comjx+6VL bztUdJ1Zc9/njwVG8fgmQ+0Kj5+bzQfUY+MmX0HTXIx3B4R1I1a8QoOwi1N+iZNdewV5Zfq+ 29NlQLnVPjCRCKbaz9k6RJ2oIti55YUI6zSsL3lmlOXsRbXN5bRswFczkNSCJxJMlDiyAUIC WOay7ymzvgzPa+BY/mYn94vRaurDQ4/ljOfj6oqgfjts+dJev4Jj89vp8MQI3KJpZPEAEQEA AYkCJQQYAQIADwUCTmyjaAIbDAUJEswDAAAKCRCuJQ1VHU50km4xEACho45PZrUjY4Zl2opR DFNo5a6roTOPpgwO9PcBb3I5F8yX2Dnew+9OhgWXbBhAFq4DCx+9Gjs43Bn60qbZTDbLGJ/m 8N4PwEiq0e5MKceYcbetEdEUWhm5L6psU9ZZ82GR3UGxPXYe+oifEoJjOXQ39avf9S8p3yKP Diil0E79rn7LbJjMcgMLyjFg9SDoJ6pHLtniJoDhEAaSSgeV7Y745+gyMIdtQmrFHfqrFdjq D6G0HE+Z68ywc5KN67YxhvhBmSycs1ZSKAXv1zLDlXdmjHDHkU3xMcB+RkuiTba8yRFYwb/n j62CC4NhFTuIKOc4ta3dJsyXTGh/hO9UjWUnmAGfd0fnzTBZF8Qlnw/8ftx5lt4/O+eqY1EN RITScnPzXE/wMOlTtdkddQ+QN6xt6jyR2XtAIi7aAFHypIqA3lLI9hF9x+lj4UQ2yA9LqpoX 6URpPOd13JhAyDe47cwsP1u9Y+OBvQTVLSvw7Liu2b4KjqL4lx++VdBi7dXsjJ6kjIRjI6Lb WVpxe8LumMCuVDepTafBZ49gr7Fgc4F9ZSCo6ChgQNLn6WDzIkqFX+42KuHz90AHWhuW+KZR 1aJylERWeTcMCGUSBptd48KniWmD6kPKpzwoMkJtEXTuO2lVuborxzwuqOTNuYg9lWDl7zKt wPI9brGzquUHy4qRrA==
Message-ID: <6d531349-8904-0e4b-5f8e-41ce43a2aecc@si6networks.com>
Date: Wed, 29 May 2019 15:00:16 -0400
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1
MIME-Version: 1.0
In-Reply-To: <5534f617-f15b-41f7-a89a-813afadb10f7@nwtime.org>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/ntp/Ec72Q7cS0Mkel5qiH-TO2mSJlYo>
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 19:01:09 -0000

On 29/5/19 13:15, Harlan Stenn wrote:
> 
> 
> 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?

Appendix A (page 26) of RFC6056 contains a survey. Stacks were employing
the same code. In some cases, it was a counter. In other cases, a value
that was decremented. These algorithms are covered in "TCP/IP
Illustrated, Volume 2" by Rich Stevens, for example.

Nowadays, at least Linux and *BSD do port number randomization. OpenBSD
was first to do it. My co-author implemented the
code in Linux.




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

Exactly. Since the attacker doesn't know the randomized port, port
randomization increases the difficulty to successfully perform off-path
attacks.

As noted during today's call, there's plenty of IETF work in this area,
much of which I was involved in. see e.g. RFC5927,



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

The deeper the upper the layer, the deeper the mitigation is in the
code, and the more expensive it is to execute it.



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

Yes. That's the whole point of this document.



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

Actually, that reduces the ability of an ACL as a mitigation. Because if
the four-tuple employed for a transaction con be guess by the attacker,
he can always forge the correct values and bypass any kind of filtering.

Having clients use ephemeral ports also allows for easy identification
of NTP client vs server traffic -- if you wanted to distinguish that for
the purpose of packet filtering.

Thanks,
-- 
Fernando Gont
SI6 Networks
e-mail: fgont@si6networks.com
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492