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

"Ulrich Windl" <Ulrich.Windl@rz.uni-regensburg.de> Wed, 29 May 2019 08:51 UTC

Return-Path: <Ulrich.Windl@rz.uni-regensburg.de>
X-Original-To: ntp@ietfa.amsl.com
Delivered-To: ntp@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id BFD9D12004A for <ntp@ietfa.amsl.com>; Wed, 29 May 2019 01:51:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
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 ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id aiGnjs_KZg0E for <ntp@ietfa.amsl.com>; Wed, 29 May 2019 01:51:02 -0700 (PDT)
Received: from mx2.uni-regensburg.de (mx2.uni-regensburg.de [IPv6:2001:638:a05:137:165:0:3:bdf8]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 28DA812004F for <ntp@ietf.org>; Wed, 29 May 2019 01:51:02 -0700 (PDT)
Received: from mx2.uni-regensburg.de (localhost []) by localhost (Postfix) with SMTP id 7E4CB6000052 for <ntp@ietf.org>; Wed, 29 May 2019 10:50:59 +0200 (CEST)
Received: from gwsmtp.uni-regensburg.de (gwsmtp1.uni-regensburg.de []) by mx2.uni-regensburg.de (Postfix) with ESMTP id 5D6E8600004E for <ntp@ietf.org>; Wed, 29 May 2019 10:50:59 +0200 (CEST)
Received: from uni-regensburg-smtp1-MTA by gwsmtp.uni-regensburg.de with Novell_GroupWise; Wed, 29 May 2019 10:50:59 +0200
Message-Id: <5CEE47F0020000A1000317ED@gwsmtp.uni-regensburg.de>
X-Mailer: Novell GroupWise Internet Agent 18.1.1
Date: Wed, 29 May 2019 10:50:56 +0200
From: "Ulrich Windl" <Ulrich.Windl@rz.uni-regensburg.de>
To: "Majdi S.Abbas" <msa@latt.net>, "Fernando Gont" <fgont@si6networks.com>
Cc: "ntp@ietf.org" <ntp@ietf.org>,"Gary E.Miller" <gem@rellim.com>
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>
In-Reply-To: <f03dbfbd-007a-fa81-f846-85079a59dddd@si6networks.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Content-Disposition: inline
Archived-At: <https://mailarchive.ietf.org/arch/msg/ntp/jYWYmThNrGewnqPNslkgUdqDjgU>
Subject: [Ntp] 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 08:51:05 -0000


I think in case of a DDoS attack the extra 14 bit of random port give little
extra protection: The attacker could send to any port (or from virtually any
port) on the attacked machine.

Ulrich Windl

>>> Fernando Gont <fgont@si6networks.com> schrieb am 29.05.2019 um 06:18 in
Nachricht <f03dbfbd-007a-fa81-f846-85079a59dddd@si6networks.com>om>:
> 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.
>> Per session randomization doesn't resolve these issues ‑‑ the stated
>> rationale for both the draft and filed CVE is hardening to off path
>> attacks, which we've just covered.
> If tomorrow a flaw were found in an NTP implementation, that happened
> e.g. prior to the validation of the origin timestamp, I guess you are
> going to argue that "that was out of scope"?
>> "Because it's best practice" isn't a reason ‑‑ it's a crutch to save
>> a draft that was filed due to an insufficient understanding of RFC
>> 5905  and current implementations of NTPv4. 
> Please enlighten me:
> Could you please explain why NTP needs a well‑known transport protocol
> number when operating in client/server mode?
>> The true best
> practice here is authentication, and it does not seem to be a worthwhile
> effort
>> to restructure existing implementations to add 16 bits to the
>> existing nonce with work like NTS pending to cover the client/server
>> use case.
> Of the implementations I've checked, there's only one that doesn't do it.
> Thanks,
> ‑‑ 
> Fernando Gont
> SI6 Networks
> e‑mail: fgont@si6networks.com 
> PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
> _______________________________________________
> ntp mailing list
> ntp@ietf.org 
> https://www.ietf.org/mailman/listinfo/ntp