Re: [Ntp] Tsvart last call review of draft-ietf-ntp-port-randomization-06

Fernando Gont <fgont@si6networks.com> Thu, 25 February 2021 09:20 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 D08BD3A163E; Thu, 25 Feb 2021 01:20:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.889
X-Spam-Level:
X-Spam-Status: No, score=-1.889 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, T_SPF_TEMPERROR=0.01, URIBL_BLOCKED=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 0pFeGtLrp2J1; Thu, 25 Feb 2021 01:20:22 -0800 (PST)
Received: from fgont.go6lab.si (fgont.go6lab.si [IPv6:2001:67c:27e4::14]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7E3FF3A163B; Thu, 25 Feb 2021 01:19:49 -0800 (PST)
Received: from [IPv6:2800:810:464:2b9:f0e0:52b6:fa0e:8799] (unknown [IPv6:2800:810:464:2b9:f0e0:52b6:fa0e:8799]) (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 63C88280615; Thu, 25 Feb 2021 09:19:45 +0000 (UTC)
To: Brian Trammell <ietf@trammell.ch>, tsv-art@ietf.org
Cc: draft-ietf-ntp-port-randomization.all@ietf.org, last-call@ietf.org, ntp@ietf.org
References: <161410772927.11488.2925276656781805208@ietfa.amsl.com>
From: Fernando Gont <fgont@si6networks.com>
Message-ID: <e053bd24-6750-db84-fa81-1b688d47ce2e@si6networks.com>
Date: Thu, 25 Feb 2021 06:17:24 -0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1
MIME-Version: 1.0
In-Reply-To: <161410772927.11488.2925276656781805208@ietfa.amsl.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/ntp/EG8RhT9Zhj_od5I5m5qPvWVL6A0>
Subject: Re: [Ntp] Tsvart last call review of draft-ietf-ntp-port-randomization-06
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: Thu, 25 Feb 2021 09:20:26 -0000

Hi, Brian,

Thanks so much for you comments! In-line...

On 23/2/21 16:15, Brian Trammell via Datatracker wrote:
[....]
> 
> This document is ready from a transport standpoint. It describes an
> already-implemented, relatively-straightforward application of an existing BCP
> to a well-understood protocol, and is clearly written. I especially appreciated
> the complete set of considerations, covering situations in which NTP port
> randomization could cause issues with certain deployment scenarios. The effect
> of routing on NTP is well studied (one such study is cited in the draft), and
> sections 3.3 and 3.4 discuss how this draft could interact with on-path
> modification of NTP traffic. Herein lies my only nit with the draft: it would
> be nice if 3.3 and 3.4 discussed how an NTP-speaking endpoint could detect and
> react to issues caused by misconfigured filtering or NAT.

You mean issues caused by packet filtering meant to mitigate DoS 
attacks? If the service port is used (src=dst=123), it'd be impossible 
(from the layer-4 header) to tell client or server traffic. So one would 
resort to dropping all traffic, or no traffic. BUt if port randomization 
is employed, client traffic will employ an ephemeral port and thus it 
becomes possible to distinguish client/server traffic by looking at the 
transport protocol port numbers -- i.e., port randomization helps in 
this scenario.

Similarly, in the case of mis-configured NATs (I'm assuming that you're 
referring to NATs not translating service ports) doing port 
randomization would actually allow for multiple clients to work across 
NATs, since there wouldn't be conflicting uses of the service port on 
the NAT internal realm.

i.e., in both cases, port randomization actually helps in these two 
scenarios.

Please do let me know if I've misinterpreted your comment.

Thanks!

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