[Ntp] NTP port randomization: per-association vs. per-request basis?

Fernando Gont <fgont@si6networks.com> Tue, 28 January 2020 02:32 UTC

Return-Path: <fgont@si6networks.com>
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 602983A0997 for <ntp@ietfa.amsl.com>; Mon, 27 Jan 2020 18:32:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.888
X-Spam-Status: No, score=-1.888 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, T_SPF_TEMPERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id 89bpgxFMXiZL for <ntp@ietfa.amsl.com>; Mon, 27 Jan 2020 18:32:45 -0800 (PST)
Received: from fgont.go6lab.si (fgont.go6lab.si []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8062B3A0991 for <ntp@ietf.org>; Mon, 27 Jan 2020 18:32:45 -0800 (PST)
Received: from [] (unknown []) (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 6067B867A3; Tue, 28 Jan 2020 03:25:38 +0100 (CET)
To: "ntp@ietf.org" <ntp@ietf.org>, Miroslav Lichvar <mlichvar@redhat.com>
Cc: Guillermo Gont <ggont@si6networks.com>
From: Fernando Gont <fgont@si6networks.com>
Message-ID: <07a6ac74-44bb-0e2f-fdd0-ee80df45468b@si6networks.com>
Date: Mon, 27 Jan 2020 23:25:18 -0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/ntp/Abcr94i-3D9JiBdmZG0M7kDKN9c>
Subject: [Ntp] NTP port randomization: per-association vs. per-request basis?
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: Tue, 28 Jan 2020 02:32:52 -0000


A while ago Miroslav raised a few questions 
on this list. In order to get a better idea of what's the wg's feeling 
about them, I'm re-raising them in separate emails.

The current version of the I-D recommends the (more conservative) port 
randomization on a per-association basis. However, he raised the 
question regarding whether it would make sense to recommend per-request 
port randomization, based on these arguments:

- It seems to be the current practice. From the implementations
   that I'm familiar with and that use a random source port, each one
   opens a new socket for each request, at least by default. On my
   public servers I see that most clients do change their port over

- It doesn't seem like a good idea to require a client to keep its
   port open when it's not waiting for a response. If it received a
   valid response, or didn't receive a valid response in few seconds
   after sending the request, it should close the port.

- The port number may be discoverable by other means, so it should
   change frequently. For example, the attacker could try sending
   packets to all ports and observe which one changed a value reported
   by the client in a monitoring protocol (e.g. mode 6). If the
   attacker can determine the port number, which cannot be prevented in
   the general case, the time for which it is useful for attacks should
   be limited.



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