Re: [Ntp] Antw: Re: Antw: Re: 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 10:02 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 6EE951201C9 for <ntp@ietfa.amsl.com>; Wed, 29 May 2019 03:02:54 -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 cwvsP1p9EF_S for <ntp@ietfa.amsl.com>; Wed, 29 May 2019 03:02:51 -0700 (PDT)
Received: from chessie.everett.org (chessie.everett.org [IPv6:2001:470:1:205::234]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2F4FD12018C for <ntp@ietf.org>; Wed, 29 May 2019 03:02:51 -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 45DR96461NzL7V; Wed, 29 May 2019 10:02:50 +0000 (UTC)
To: Ulrich Windl <Ulrich.Windl@rz.uni-regensburg.de>, "ntp@ietf.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> <f03dbfbd-007a-fa81-f846-85079a59dddd@si6networks.com> <c4384ecc-2711-3479-df21-d6533f438418@ntp.org> <5CEE4B90020000A1000317F4@gwsmtp.uni-regensburg.de> <5CEE4B90020000A1000317F4@gwsmtp.uni�regensburg.de> <9418bd6d-a830-311f-2392-02999df3c153@nwtime.org> <5CEE5344020000A1000317F9@gwsmtp.uni-regensburg.de>
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: <92e2c1f9-a745-c182-6194-c7ce819c8a3c@nwtime.org>
Date: Wed, 29 May 2019 03:02:49 -0700
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.7.0
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/ntp/LP4R7fKSwyb1JFohx0g8HijyThk>
Subject: Re: [Ntp] Antw: Re: Antw: Re: 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 10:02:56 -0000


On 5/29/2019 2:39 AM, Ulrich Windl wrote:
>>>> Harlan Stenn <stenn@nwtime.org> schrieb am 29.05.2019 um 11:31 in
> Nachricht
> <9418bd6d-a830-311f-2392-02999df3c153@nwtime.org>:
> 
>>
>> On 5/29/2019 2:06 AM, Ulrich Windl wrote:
>>>>>> Danny Mayer <mayer@ntp.org> schrieb am 29.05.2019 um 10:42 in Nachricht
>>> <c4384ecc-2711-3479-df21-d6533f438418@ntp.org>:
>>>
>>>> On 5/29/19 12:18 AM, Fernando Gont wrote:
>>>>> On 28/5/19 23:20, Majdi S. Abbas wrote:
>>>>>> Randomizing the source port is pointless.  As Danny has noted, t1
>>>>>> already acts as a 2^64 nonce on each client mode chime request.  This
>>>>>> sufficiently hardens the unauthenticated case to an off path
>>>>>> attacker.  If additional security is required, authentication (via
>>>>>> classic PSK, or NTS modes) should be used.
>>>>> Using predictable numeric identifiers is a bad habit. We have plenty of
>>>>> history in this area and, as noted, it's quite interesting to see folks
>>>>> pushing in this direction in 2019, when the tendency has been to
>>>>> actually move away from predictable numeric IDs (TCP ISNs, transport
>>>>> protocol numbers, DNS TxIDs, Frag IDs, etc.).
>>>>>
>>>>> Using predictable port numbers makes it easy for an attacker to infer
>>>>> the "session id". You are just considering one possible attack scenario.
>>>>>
>>>> You are totally missing the point. The port numbers don't make NTP
>>>> vulnerable. The "session id" does not exist here. Instead NTP has an
>>>> origin timestamp that an off‑path attacker does not have access to. Even
>>>> if it did, then the origin timestamp is wildly different each time it's
>>>> sent and is not predictable. This is a 64‑bit nonce.
>>>
>>> ...of which about 30 bits are random (assuming the attacker knows what time
> 
>> it
>>> is and packets take less than one second to travel)...
>>
>> How did you come up with 30 bits?
> 
> I assumed: 32 bits integral seconds, and 32 bits fractional seconds. Assume
> the packets arrive within 250ms, your at 30 bits uncertainty ("random")

That's fine, and assuming the attacker is blind then I think we're
really talking about 32 and possibly 33 bits, because there is a
significant chance the window will span the boundary between seconds.

That also assumes the client has the correct time.  If somebody is using
SNTP, this assumption may be wrong, and the client's time could well be
off by much more.  At 33 bits, we're talking about 2 seconds.  If the
client might be off by 4-8 minutes then we're talking about 41 bits.

>>
>> And remember that:
>>
>> - the window of time where an attack is possible starts when the client
>>   sends its request, and ends when a valid response is received.
> 
> An attacker will probably "spray" attacking packets.

OK, so what?  Low end normal machines might handle 2k packets/second,
and low end slow machines are lucky to be able to handle 200 packets per
second.

>> - a competent client will log bogus responses, at least during this
>>   window, and if the client is NTP as opposed to SNTP, will log
>>   *any* bogus received packets.
> 
> The point is whether logging unexpected packets actually opens a DoS windows.

That's something logging systems can reasonably be expected to handle,
and it's also reasonable to assume that if somebody goes to the trouble
to log these events they're also alerting on them.

>> Further note:
>>
>> - 30 bits is over a billion choices
>> - average clients can process maybe 2k packets per second
>> - the window of time on this attack is likely under a quarter
>>   to half a second, so 500-1,000 packets out of a billion
> 
> I agree, but please don't treat it as 64-bit random value that is to be
> guessed.

Not a problem.  Also note that even 30 bits is huge if you're attacking
a slow processor that can only handle 200 packets/second.  In this case,
the attacker might be able to send back 50-100 packets out of a billion,
so if no MAC protection is used that's still 5-10 chances in 100
million.  I read the odds of drowning while taking a bath are 1 in
840,000, so this would be about 50-100 times more rare.

>> - MAC protection adds a *lot* of protection on this
>> - bogus packets received during the window are likely logged,
>>   and if MAC protected will generate a CRYPTO-NAK back to the
>>   real server, which, if reasonably implemented, will also
>>   be logged.
> 
> My remark was solely on "64-bit" random...

No worries.

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