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

Miroslav Lichvar <mlichvar@redhat.com> Mon, 18 November 2019 10:34 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 E2F8212086E for <ntp@ietfa.amsl.com>; Mon, 18 Nov 2019 02:34:59 -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 gnF5isiL2iq5 for <ntp@ietfa.amsl.com>; Mon, 18 Nov 2019 02:34:58 -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 71E501200DF for <ntp@ietf.org>; Mon, 18 Nov 2019 02:34:58 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1574073296; 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=C+1E6So+TWe3+5lGOBC7NWIkT2QnZn12H9gfA5AivGs=; b=HKHyQ34tz2+Pk3224iuxezps6wGWuelBH1lmY6Ve5lwAmtpvZl1etM1cZLC46V5GSutQQO hE31oVIUL2oAGCHLMJ2CY2W0Y9DNohvI7+aYrICtxMqSNUQRvekSQ0+4B2jas3nkaOjVXK dvQWr690Od3p8nyYR87JjxDoo1loBoc=
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-352-yP944WtkOZ-2-76NQ-gsSw-1; Mon, 18 Nov 2019 05:34:54 -0500
Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.phx2.redhat.com [10.5.11.15]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id C60091005514 for <ntp@ietf.org>; Mon, 18 Nov 2019 10:34:53 +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 4E40F627D7 for <ntp@ietf.org>; Mon, 18 Nov 2019 10:34:53 +0000 (UTC)
Date: Mon, 18 Nov 2019 11:34:51 +0100
From: Miroslav Lichvar <mlichvar@redhat.com>
To: ntp@ietf.org
Message-ID: <20191118103451.GI2634@localhost>
References: <157262391705.31923.311801865037196489@ietfa.amsl.com> <20191113112126.GA2634@localhost> <cb05b415-4170-7ff9-2adb-f280906551ae@si6networks.com>
MIME-Version: 1.0
In-Reply-To: <cb05b415-4170-7ff9-2adb-f280906551ae@si6networks.com>
User-Agent: Mutt/1.12.1 (2019-06-15)
X-Scanned-By: MIMEDefang 2.79 on 10.5.11.15
X-MC-Unique: yP944WtkOZ-2-76NQ-gsSw-1
X-Mimecast-Spam-Score: 0
Content-Type: text/plain; charset=WINDOWS-1252
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
Archived-At: <https://mailarchive.ietf.org/arch/msg/ntp/df_CHpmM9urshNZysJcSjBgHyWc>
Subject: Re: [Ntp] 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: Mon, 18 Nov 2019 10:35:00 -0000

On Sun, Nov 17, 2019 at 09:31:35PM -0300, Fernando Gont wrote:
> On 13/11/19 08:21, Miroslav Lichvar wrote:
> > - 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.
> 
> For client mode, I believe that responses should be limited to the
> address employed for the association. i.e., why should a client respond
> to a request from a random host?

Yes, the client's port should be "connected" to the server, so it is
closed for other hosts.

The point I'm trying to make is that the client may also operate as a
server listening on the port 123 and respond to mode 6 requests (e.g.
from hosts in the local network), allowing an attacker to observe some
of the client's state. It doesn't have to be the client leaking its
port number. It could be any host on the path between the server and
client, for example a firewall that has a monitoring access.

-- 
Miroslav Lichvar