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

"Brian Trammell (IETF)" <> Fri, 26 February 2021 10:04 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9DCA53A1024 for <>; Fri, 26 Feb 2021 02:04:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 5ZDfqFL1Yebo for <>; Fri, 26 Feb 2021 02:04:55 -0800 (PST)
Received: from ( [IPv6:2001:1600:3:17::bc0f]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 085FF3A103A for <>; Fri, 26 Feb 2021 02:04:54 -0800 (PST)
Received: from (unknown []) by (Postfix) with ESMTPS id 4Dn4yW5sB4zMqlT0; Fri, 26 Feb 2021 11:04:51 +0100 (CET)
Received: from [IPv6:2a02:169:17b2::fc8d:b6c8:ded4:4181] (unknown [IPV6:2a02:169:17b2:0:fc8d:b6c8:ded4:4181]) by (Postfix) with ESMTPA id 4Dn4yW2wwkzlh8T9; Fri, 26 Feb 2021 11:04:50 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;; s=20191114; t=1614333891; bh=UedAYzX6D+mPPtNKy36j04JcNmDWUaeAbMDZszEYDW0=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From; b=bWRu9d6hY8Z3OcwMdVldZsVmHXC+TjPQHm1Ha+QR5tHyUGyMwJPLdYTR/kOZRcIQG x+tXj2lVTy7nt9m8xwIb7Gt8sM4v7gqMZFrOLbsAleRx4lFk3nBOKDRqs9YrxCq1Ja 3zqYVyNtgGmdzyWMtrXbQt4emQ3/6csJs3Du7M8o=
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.7\))
From: "Brian Trammell (IETF)" <>
In-Reply-To: <>
Date: Fri, 26 Feb 2021 11:04:50 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <>
To: Fernando Gont <>
X-Mailer: Apple Mail (2.3445.9.7)
Archived-At: <>
Subject: Re: [Ntp] Tsvart last call review of draft-ietf-ntp-port-randomization-06
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 26 Feb 2021 10:04:59 -0000

hi Fernando,

> On 25 Feb 2021, at 10:17, Fernando Gont <> wrote:
> 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.

Yep, I get that. My comment is a little more subtle. There is a tradeoff, however small, that an endpoint deployed *without* cooperation or knowledge of a NAT or firewall on path might risk connectivity by randomizing ports. Are there any known firewall/NAT deployments that require 123/123 on both src and dst to recognize NTP? Is there anything a port-randomizing NTP speaker can/must do to detect and react to this situation (even if that's throwing up an error message and asking the kind human looking after the thing to please unbreak their firewall)?

(That said, this is really a tiny nit. I'm perfectly fine with you considering this and deciding it doesn't warrant text in the doc)

Thanks, cheers,


> Please do let me know if I've misinterpreted your comment.
> Thanks!
> Regards,
> -- 
> Fernando Gont
> SI6 Networks
> e-mail:
> PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492