Re: [Ntp] New I-D: NTP Port Randomization (draft-gont-ntp-port-randomization-00.txt)

Miroslav Lichvar <mlichvar@redhat.com> Tue, 23 April 2019 08:49 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 7CE9C1200FA for <ntp@ietfa.amsl.com>; Tue, 23 Apr 2019 01:49:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.901
X-Spam-Level:
X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 hWyJipYrxuGa for <ntp@ietfa.amsl.com>; Tue, 23 Apr 2019 01:49:09 -0700 (PDT)
Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AF7431200A2 for <ntp@ietf.org>; Tue, 23 Apr 2019 01:49:09 -0700 (PDT)
Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.phx2.redhat.com [10.5.11.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 55A4130BC670; Tue, 23 Apr 2019 08:49:09 +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 A80875D9C8; Tue, 23 Apr 2019 08:49:08 +0000 (UTC)
Date: Tue, 23 Apr 2019 10:48:53 +0200
From: Miroslav Lichvar <mlichvar@redhat.com>
To: Fernando Gont <fgont@si6networks.com>
Cc: ntp@ietf.org
Message-ID: <20190423084853.GB5188@localhost>
References: <155544937440.24990.5297599214551671091.idtracker@ietfa.amsl.com> <d0be2bea-0e57-022f-16f1-4e682dcc66ad@si6networks.com> <20190418123648.GF5984@localhost> <ceea9343-496f-2842-8255-158b515106b6@si6networks.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <ceea9343-496f-2842-8255-158b515106b6@si6networks.com>
User-Agent: Mutt/1.10.1 (2018-07-13)
X-Scanned-By: MIMEDefang 2.79 on 10.5.11.14
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.46]); Tue, 23 Apr 2019 08:49:09 +0000 (UTC)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ntp/vnfGFTpfF8tC_ex3DH-KYEyWA6Y>
Subject: Re: [Ntp] New I-D: NTP Port Randomization (draft-gont-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: Tue, 23 Apr 2019 08:49:12 -0000

On Fri, Apr 19, 2019 at 12:56:04AM +0200, Fernando Gont wrote:
> On 18/4/19 14:36, Miroslav Lichvar wrote:
> > The source port in client mode packets can be random and it can also
> > change with each request, which might be recommended in the document.
> > Most NTP clients do that.
> 
> FWIW, I'm running ntpd 4.2.8p11@1.3728-o on Ubuntu, and all packets use
> src port 123.

Yes, ntpd and ntpdate (without -q or -d) seem to be in the minority of
clients using source port 123.

> > The source port in active mode packets doesn't necessarily have to be
> > 123. It can be random if the other peer is not expected to have a
> > permanent association with the peer, but it must not change between
> > requests as that would create new assocations.
> 
> Are you referring to to symmetric mode? My understanding is that if one
> of the peers employs a port other than 123, then symmetric mode would
> result in two different associations, rather than a single one. Am I
> missing something?

Yes, symmetric mode.

If both peers are using the active mode (i.e. permanent association),
they need to use the same port numbers in order to avoid creating more
associations. If one of them is expected to be using passive mode
(i.e. ephemeral association or stateless), I think the active peer can
use any source port as long as it doesn't change (frequently).

-- 
Miroslav Lichvar