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
- [Ntp] Tsvart last call review of draft-ietf-ntp-p… Brian Trammell via Datatracker
- Re: [Ntp] Tsvart last call review of draft-ietf-n… Fernando Gont
- Re: [Ntp] Tsvart last call review of draft-ietf-n… Brian Trammell (IETF)
- Re: [Ntp] Tsvart last call review of draft-ietf-n… Hal Murray
- Re: [Ntp] Tsvart last call review of draft-ietf-n… Fernando Gont
- Re: [Ntp] Tsvart last call review of draft-ietf-n… Hal Murray