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

Miroslav Lichvar <> Wed, 13 November 2019 11:21 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id CC56B120025 for <>; Wed, 13 Nov 2019 03:21:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.299
X-Spam-Status: No, score=-4.299 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 5UUPzyse-IeK for <>; Wed, 13 Nov 2019 03:21:32 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id D9AC8120013 for <>; Wed, 13 Nov 2019 03:21:31 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=mimecast20190719; t=1573644090; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=+tLZsRkIDuW1BDxpGg6R0zh5kse8sDRVP63a7uCWV38=; b=AUJSWodCPrYxbUTuF3hgdWGtmfum17YXd2bvgXuuXa+e3DAs0WDOD/dmDm2YQpjp7xIjGb QCWJUjRRt8wCOERk2HkN7D6Qu94WdYQ7k4piyWHTjJ8qhMGTYIpDcESUOMIHwpmWduZvZ9 oo0c9WB12iXD/okF5JSd8L2aIQkhwig=
Received: from ( []) (Using TLS) by with ESMTP id us-mta-376-ZHN_govzPr2MMXiPFGLe-Q-1; Wed, 13 Nov 2019 06:21:29 -0500
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 4DEEB107ACC6 for <>; Wed, 13 Nov 2019 11:21:28 +0000 (UTC)
Received: from localhost ( []) by (Postfix) with ESMTPS id CB156BEA66 for <>; Wed, 13 Nov 2019 11:21:27 +0000 (UTC)
Date: Wed, 13 Nov 2019 12:21:26 +0100
From: Miroslav Lichvar <>
Message-ID: <20191113112126.GA2634@localhost>
References: <>
MIME-Version: 1.0
In-Reply-To: <>
User-Agent: Mutt/1.12.1 (2019-06-15)
X-Scanned-By: MIMEDefang 2.79 on
X-MC-Unique: ZHN_govzPr2MMXiPFGLe-Q-1
X-Mimecast-Spam-Score: 0
Content-Type: text/plain; charset=WINDOWS-1252
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
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: Wed, 13 Nov 2019 11:21:35 -0000

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

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

Does that make sense?

Miroslav Lichvar