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

Miroslav Lichvar <> Thu, 14 November 2019 09:13 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4E585120232 for <>; Thu, 14 Nov 2019 01:13:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.3
X-Spam-Status: No, score=-4.3 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] 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 rDmPvjrQ4rUm for <>; Thu, 14 Nov 2019 01:13:11 -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 9EFD51208A5 for <>; Thu, 14 Nov 2019 01:13:11 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=mimecast20190719; t=1573722790; 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=GFZwugHEyRi7EbpgY+uzWUBC7aQTkUvMSQaaMXbpfao=; b=evANAS/QJoUqbRUGAScHH1hWh2Xf6AG93ilPBUmGWd2ttoLLKIi3qs4wd4Gqyzpg4bAC6Z aeWvPO1K/+fj8sTvbBU6YnZCtylCT8nTI77fOgu5N8NStW+zi8LSAo6y3j2j1qhG8YUcZc PQUqDsoSY/oZLRf9AxSUxd6Aiw8JVpk=
Received: from ( []) (Using TLS) by with ESMTP id us-mta-409-doAnoVrBNnCs3KYKmBgGxA-1; Thu, 14 Nov 2019 04:13:06 -0500
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id DBFEA803621 for <>; Thu, 14 Nov 2019 09:13:04 +0000 (UTC)
Received: from localhost ( []) by (Postfix) with ESMTPS id 62B1F81C1D for <>; Thu, 14 Nov 2019 09:13:04 +0000 (UTC)
Date: Thu, 14 Nov 2019 10:13:02 +0100
From: Miroslav Lichvar <>
Message-ID: <20191114091302.GF2634@localhost>
References: <> <20191113112126.GA2634@localhost> <> <20191113160055.GC2634@localhost> <>
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: doAnoVrBNnCs3KYKmBgGxA-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] Antw: Re: 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: Thu, 14 Nov 2019 09:13:14 -0000

On Thu, Nov 14, 2019 at 09:17:00AM +0100, Ulrich Windl wrote:
> >>> Miroslav Lichvar <> schrieb am 13.11.2019 um 17:00 in
> > Yes, there could be multiple clients (e.g. behind NAT), but I think we
> > can make a good guess whether any of them use a stable port by
> > counting how many requests are there per port. When I analyze 24-hour
> > captures from public servers in few different countries, for most
> > addresses there seem to be only one request per port. I'm ignoring
> > addresses that send only requests from some popular fixed ports like
> > 123, 1024, 1490.
> So your result is more or less biased: What if that fixed popular ports are
> 99% of all requests? Then you are csaling up the remaining 1% to support your
> view. That's not serious argumenting.

The percentage of addresses using the fixed ports is about 10-25% in
my data. It varies between countries. But I don't think it matters
here. I'm comparing the per-association and per-request port
randomization. The fixed ports are not random.

A problem with my analysis is that it assumes most NATs preserve the
UDP port numbers at least for one client in the local network. I'm not
sure how common that really is. With NATs that always select the UDP
port randomly and clients using a polling interval longer that the NAT
timeout, it will look like the per-request randomization even if their
local port is stable. However, from the server's and Internet point of
view it doesn't matter if it's the client or NAT doing the

> I mean this: If the client specified a specific port, the client has to make
> sure that the port isn't in use. If you specify 0 as port, the system picks a
> free one for you. Thats easier.

Even easier is to not bind the socket at all. It will be bound
automatically to a random port when the first request is sent.

Miroslav Lichvar