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

Fernando Gont <> Fri, 26 February 2021 18:07 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2328D3A1418; Fri, 26 Feb 2021 10:07:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 1F_jCOYVWKD1; Fri, 26 Feb 2021 10:07:07 -0800 (PST)
Received: from ( [IPv6:2001:67c:27e4::14]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 4C8A43A1415; Fri, 26 Feb 2021 10:06:54 -0800 (PST)
Received: from [IPv6:2800:810:464:2b9:84c6:af27:bf82:3974] (unknown [IPv6:2800:810:464:2b9:84c6:af27:bf82:3974]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id B334C280155; Fri, 26 Feb 2021 18:06:48 +0000 (UTC)
To: "Brian Trammell (IETF)" <>
References: <> <> <>
From: Fernando Gont <>
Message-ID: <>
Date: Fri, 26 Feb 2021 15:00:03 -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: <>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 7bit
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 18:07:10 -0000

On 26/2/21 07:04, Brian Trammell (IETF) wrote:
>> 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? 

I don't know of any.  And it would be *very* surprising to find those, 
for the following reasons:

1) There's only one implementation that I know of that uses the service
    port as the source port of client requests. As a ressult, enforcing
    such a rule would prevent all other implementations from working.

2) Even in the case f an implementation that employs 123 for the source
    port, in a very large number of cases, for the IPv4 case,the packets
    will go through one or more NATs (CPE NAT and possibly CGN), so in
    the most common client deployment cases, the source port will not be
    prevented anyway.

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

I would argue that there's nothing special to do here.


Fernando Gont
SI6 Networks
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492