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

Miroslav Lichvar <mlichvar@redhat.com> Wed, 13 November 2019 16:01 UTC

Return-Path: <mlichvar@redhat.com>
X-Original-To: ntp@ietfa.amsl.com
Delivered-To: ntp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3183D120817 for <ntp@ietfa.amsl.com>; Wed, 13 Nov 2019 08:01:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.3
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=redhat.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dk0nFIbUjJ_a for <ntp@ietfa.amsl.com>; Wed, 13 Nov 2019 08:01:03 -0800 (PST)
Received: from us-smtp-delivery-1.mimecast.com (us-smtp-2.mimecast.com [205.139.110.61]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 58FDB120073 for <ntp@ietf.org>; Wed, 13 Nov 2019 08:01:03 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1573660862; 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=BcnUACVWh24Tqh42XVtQdq0Gdkzt753P9MfCW9gp6Ig=; b=f+t51L3+qyl4r8e3Yq5kqNxIL98XMI+KuSxB9SeKkH0p2YkxyjySA3ZWa/9ckgic6DVvkn gS12ThhRCc6Mmt4brY0l5bzdjs1entfNRNjVrv1fx9HvczTNKLVL+zVid+ob/l0V2rDw2y ZXJDSfvxNij4zuY3uBBVDjuXjTNQnvU=
Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-136-6RB5-hGhPliabbYNFgOJ8g-1; Wed, 13 Nov 2019 11:00:58 -0500
Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 8C64C800686 for <ntp@ietf.org>; Wed, 13 Nov 2019 16:00:57 +0000 (UTC)
Received: from localhost (holly.tpb.lab.eng.brq.redhat.com [10.43.134.11]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 13B8A60471 for <ntp@ietf.org>; Wed, 13 Nov 2019 16:00:56 +0000 (UTC)
Date: Wed, 13 Nov 2019 17:00:55 +0100
From: Miroslav Lichvar <mlichvar@redhat.com>
To: ntp@ietf.org
Message-ID: <20191113160055.GC2634@localhost>
References: <157262391705.31923.311801865037196489@ietfa.amsl.com> <20191113112126.GA2634@localhost> <5DCBEDCC020000A1000352C1@gwsmtp.uni-regensburg.de>
MIME-Version: 1.0
In-Reply-To: <5DCBEDCC020000A1000352C1@gwsmtp.uni-regensburg.de>
User-Agent: Mutt/1.12.1 (2019-06-15)
X-Scanned-By: MIMEDefang 2.79 on 10.5.11.11
X-MC-Unique: 6RB5-hGhPliabbYNFgOJ8g-1
X-Mimecast-Spam-Score: 0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
Archived-At: <https://mailarchive.ietf.org/arch/msg/ntp/-oPU2Y1BoRp7_p18FkPQEMzF34I>
Subject: Re: [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 16:01:06 -0000

On Wed, Nov 13, 2019 at 12:49:32PM +0100, Ulrich Windl wrote:
> >>> Miroslav Lichvar <mlichvar@redhat.com>; schrieb am 13.11.2019 um 12:21 in
> > ‑ 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.

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.

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

I'm not sure if it's really easier. The port assigned by the system
should be random. Do you have an example of a widely used
implementation keeping a socket open which is not also used for
different servers?

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

It's not meant to be a requirement, just a recommendation.

-- 
Miroslav Lichvar