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

Fernando Gont <fgont@si6networks.com> Mon, 18 November 2019 07:12 UTC

Return-Path: <fgont@si6networks.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 DB90C1208CD for <ntp@ietfa.amsl.com>; Sun, 17 Nov 2019 23:12:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.357
X-Spam-Level:
X-Spam-Status: No, score=-0.357 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_PAST_06_12=1.543, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no 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 scgtkMxPR94o for <ntp@ietfa.amsl.com>; Sun, 17 Nov 2019 23:12:02 -0800 (PST)
Received: from fgont.go6lab.si (fgont.go6lab.si [91.239.96.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 79E1A120088 for <ntp@ietf.org>; Sun, 17 Nov 2019 23:12:02 -0800 (PST)
Received: from [192.168.3.69] (unknown [186.137.78.253]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id 3443B865D0; Mon, 18 Nov 2019 08:11:56 +0100 (CET)
To: Miroslav Lichvar <mlichvar@redhat.com>, ntp@ietf.org
References: <157262391705.31923.311801865037196489@ietfa.amsl.com> <20191113112126.GA2634@localhost>
From: Fernando Gont <fgont@si6networks.com>
Openpgp: preference=signencrypt
Message-ID: <cb05b415-4170-7ff9-2adb-f280906551ae@si6networks.com>
Date: Sun, 17 Nov 2019 21:31:35 -0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0
MIME-Version: 1.0
In-Reply-To: <20191113112126.GA2634@localhost>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/ntp/TEuoQMlBsF3S6Qe2FgkhZTVqDKM>
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 07:12:04 -0000

Hello, Miroslav,

On 13/11/19 08:21, Miroslav Lichvar wrote:
> On Fri, Nov 01, 2019 at 08:58:37AM -0700, internet-drafts@ietf.org wrote:
>> https://tools.ietf.org/html/draft-ietf-ntp-port-randomization-00
> 
> 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
>   time.

I agree.



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

Same here.



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

If we did that, you could detect that a port is open (in cases where
you'd receive an ICMP port unreach for closed ports), but there would be
no other information leakages.

Thoughts?

Thanks!

Cheers,
-- 
Fernando Gont
SI6 Networks
e-mail: fgont@si6networks.com
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492