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

"Ulrich Windl" <Ulrich.Windl@rz.uni-regensburg.de> Wed, 13 November 2019 11:49 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 3524B120271 for <ntp@ietfa.amsl.com>; Wed, 13 Nov 2019 03:49:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, 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 7oNoxDd358FT for <ntp@ietfa.amsl.com>; Wed, 13 Nov 2019 03:49:39 -0800 (PST)
Received: from mx1.uni-regensburg.de (mx1.uni-regensburg.de [IPv6:2001:638:a05:137:165:0:3:bdf7]) (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 26BEF12001A for <ntp@ietf.org>; Wed, 13 Nov 2019 03:49:39 -0800 (PST)
Received: from mx1.uni-regensburg.de (localhost []) by localhost (Postfix) with SMTP id 051916000051 for <ntp@ietf.org>; Wed, 13 Nov 2019 12:49:35 +0100 (CET)
Received: from gwsmtp.uni-regensburg.de (gwsmtp1.uni-regensburg.de []) by mx1.uni-regensburg.de (Postfix) with ESMTP id CDE926000050 for <ntp@ietf.org>; Wed, 13 Nov 2019 12:49:34 +0100 (CET)
Received: from uni-regensburg-smtp1-MTA by gwsmtp.uni-regensburg.de with Novell_GroupWise; Wed, 13 Nov 2019 12:49:34 +0100
Message-Id: <5DCBEDCC020000A1000352C1@gwsmtp.uni-regensburg.de>
X-Mailer: Novell GroupWise Internet Agent 18.2.0
Date: Wed, 13 Nov 2019 12:49:32 +0100
From: "Ulrich Windl" <Ulrich.Windl@rz.uni-regensburg.de>
To: "ntp@ietf.org" <ntp@ietf.org>,<mlichvar@redhat.com>
References: <157262391705.31923.311801865037196489@ietfa.amsl.com> <20191113112126.GA2634@localhost>
In-Reply-To: <20191113112126.GA2634@localhost>
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/WbrkeacDdpkaA414Ghic91NN9X8>
Subject: [Ntp] Antw: Re: I-D Action: draft-ietf-ntp-port-randomization-00.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, 13 Nov 2019 11:49:42 -0000

>>> Miroslav Lichvar <mlichvar@redhat.com> schrieb am 13.11.2019 um 12:21 in
Nachricht <20191113112126.GA2634@localhost>:
> On Fri, Nov 01, 2019 at 08:58:37AM ‑0700, internet‑drafts@ietf.org wrote:
>> https://tools.ietf.org/html/draft‑ietf‑ntp‑port‑randomization‑00 
> 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".

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

Again: Keeping the port open seems (at least in classical, more static
programming languages) easier.

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

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

Actually today any (well-known) port is attacked, even if it never sent any

> Does that make sense?

I think I said it before: The server SHOULD still work if the client changes
the port number (leaving it open to the server to assume that it's a different
client then), but I would NOT require the client to vary the source port

Maybe the main part should be a discussion of privacy/security improvements
expected when using a variable port number. I think it does not improve the
overall reliability of the service.

Ulrich Windl