Re: [Ntp] Antw: Re: 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 2E80212086B for <>; Sun, 17 Nov 2019 23:12:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id dzWO-EVfRI4D for <>; Sun, 17 Nov 2019 23:12:14 -0800 (PST)
Received: from ( [IPv6:2001:67c:27e4::14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 44BED1200B3 for <>; Sun, 17 Nov 2019 23:12:14 -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 2703D865D0; Mon, 18 Nov 2019 08:12:08 +0100 (CET)
From: Fernando Gont <>
To: Ulrich Windl <>, "" <>,
References: <> <20191113112126.GA2634@localhost> <>
Openpgp: preference=signencrypt
Message-ID: <>
Date: Mon, 18 Nov 2019 01:25:39 -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: <>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: <>
Subject: Re: [Ntp] Antw: Re: 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:17 -0000

On 13/11/19 08:49, Ulrich Windl wrote:
>>>> Miroslav Lichvar <> schrieb am 13.11.2019 um 12:21 in
> Nachricht <20191113112126.GA2634@localhost>:
>> On Fri, Nov 01, 2019 at 08:58:37AM ‑0700, internet‑ 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.
>>From remote you cannot know whether it's the same instance of the same client
> sending the requests.
> My guess is that the client does not specify the source port, so for each
> socket a free (not "random") port will be chosen. The implementation rationale
> most likely is that "it's easier", not because "it's better".

Most implementations randomize the ephemeral ports by default. So, if
the app doesn't bind a specific port, it relies on the OS, and most
popular OSes do ephemeral port randomization.

>> ‑ 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
> That's the only real reason I could imagine using variable ports: You want to
> hide who you are. Actually I think clients using public servers should not hide
> who they are. Usually the evil ones do or try to.

This has changed, based on the evidence of pervasive monitoring. For
instance, please see RFC8064 and RFC4941.

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