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

From: Brian Trammell via Datatracker <[email-masked]>
Date: Tue, 23 Feb 2021 11:15:29 -0800

Reviewer: Brian Trammell
Review result: Ready with Nits

This document has been reviewed as part of the transport area review team's
ongoing effort to review key IETF documents. These comments were written
primarily for the transport area directors, but are copied to the document's
authors and WG to allow them to address any issues raised and also to the IETF
discussion list for information.

When done at the time of IETF Last Call, the authors should consider this
review as part of the last-call comments they receive. Please always CC
[email-masked] if you reply to or forward this review.

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.

---

From: Fernando Gont <[email-masked]>
Date: Thu, 25 Feb 2021 06:17:24 -0300

Hi, Brian,

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

On 23/2/21 16:15, Brian Trammell via Datatracker wrote:
[....]
> 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: [email-masked]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492

---

From: "Brian Trammell (IETF)" <[email-masked]>
Date: Fri, 26 Feb 2021 11:04:50 +0100

hi Fernando,

> On 25 Feb 2021, at 10:17, Fernando Gont <[email-masked]> wrote:
> 
> Hi, Brian,
> 
> 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,

Brian

---

From: Hal Murray <[email-masked]>
Date: Fri, 26 Feb 2021 04:35:03 -0800

[email-masked] said:
> 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)?

There is nothing in an NTP packet that needs tweaking by a NAT box other than 
the obvious return address.  So there is no reason to recognize it as an NTP 
packet.

More details than anybody wants to know...

There was/is(?) Autokey, RFC 5906, an early attempt at public key 
authentication.  It didn't work through NAT because the client IP Address was 
tangled up in the crypto.  I don't think anybody uses it.  We removed support 
from NETSec.  But who knows what unattended code is still running in some 
dusty corner.

Some of the mode 6/7 subcommands use a cookie to prevent DDoS amplification.  
The client doesn't know anything about the contents of the cookie.  The cookie 
includes a hash of the clients IP Address but that works through NAT as long 
as the client uses the same NAT box to both request and use the cookie.

NTS uses cookies, but there is nothing about the IP Address included in the 
cookie.  We discussed adding the IP Address.  I have forgotten exactly why.  
Probably to avoid reflection attacks.  We decided not to do that.

-- 
These are my opinions.  I hate spam.

---

From: Fernando Gont <[email-masked]>
Date: Fri, 26 Feb 2021 15:00:03 -0300

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

Thanks!

Regards,

---

From: Hal Murray <[email-masked]>
Date: Fri, 26 Feb 2021 12:30:03 -0800

>     such a rule would prevent all other implementations from working. 

One reason for doing that is to prevent 2 programs that adjust the clock from 
running at the same time.  If some other program is already using port 123, a 
second program will get an error when it tries to bind its socket to the 
already-in-use port.