Re: [Ntp] I-D Action: draft-ietf-ntp-port-randomization-00.txt

Fernando Gont <> Mon, 18 November 2019 07:12 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id DB90C1208CD for <>; Sun, 17 Nov 2019 23:12:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.357
X-Spam-Status: No, score=-0.357 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_PAST_06_12=1.543, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id scgtkMxPR94o for <>; Sun, 17 Nov 2019 23:12:02 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 79E1A120088 for <>; Sun, 17 Nov 2019 23:12:02 -0800 (PST)
Received: from [] (unknown []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id 3443B865D0; Mon, 18 Nov 2019 08:11:56 +0100 (CET)
To: Miroslav Lichvar <>,
References: <> <20191113112126.GA2634@localhost>
From: Fernando Gont <>
Openpgp: preference=signencrypt
Message-ID: <>
Date: Sun, 17 Nov 2019 21:31:35 -0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0
MIME-Version: 1.0
In-Reply-To: <20191113112126.GA2634@localhost>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <>
Subject: Re: [Ntp] I-D Action: draft-ietf-ntp-port-randomization-00.txt
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 18 Nov 2019 07:12:04 -0000

Hello, Miroslav,

On 13/11/19 08:21, Miroslav Lichvar wrote:
> On Fri, Nov 01, 2019 at 08:58:37AM -0700, wrote:
> This document describes a per-association and per-request approach for
> randomizing the client's port number with some of their advantages and
> disadvantages. It currently strongly recommends the per-association
> approach for all clients.
> For a typical client running on an OS it is about opening and closing
> sockets. Should it keep one socket open for the lifetime of the
> association, or should it open a new socket before each request?
> I'd like to propose changing the recommendation to the per-request
> approach for the following reasons:
> - 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
>   time.

I agree.

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

Same here.

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

For client mode, I believe that responses should be limited to the
address employed for the association. i.e., why should a client respond
to a request from a random host?

If we did that, you could detect that a port is open (in cases where
you'd receive an ICMP port unreach for closed ports), but there would be
no other information leakages.



Fernando Gont
SI6 Networks
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492