Subject: [Ntp] NAT devices not translating privileged ports

From: Fernando Gont <[email-masked]>
Date: Fri, 4 Jun 2021 07:02:29 +0000

Folks,

As part of the IESG review of the ntp port randomization draft 
(
https://www.ietf.org/archive/id/draft-ietf-ntp-port-randomization-06.txt
), we were asked if we could provide a reference for the NAT devices do
not translate the source port if the source port is a privileged port
(<1024).

Any clues/examples of this type of NATs?

Thanks!

Regards,
-- 
Fernando Gont
Director of Information Security
EdgeUno, Inc.
PGP Fingerprint: DFBD 63E3 B248 AE79 C598 AF23 EBAE DA03 0644 1531

---

From: Hal Murray <[email-masked]>
Date: Fri, 04 Jun 2021 01:07:16 -0700

[email-masked] said:
> we were asked if we could provide a reference for the NAT devices do not
> translate the source port if the source port is a privileged port (<1024).

> Any clues/examples of this type of NATs?

Does that make sense?  What happens if 3 systems inside the NAT box all send 
using the same privileged source port?  ntpd without port randomization would 
do that.

There is the special case where you want to run a server (on a privileged 
port) located inside the NAT box.  I think Port forwarding is the usual term.  
In that case, you have to tell the NAT box the (internal) IP Address of the 
server.  Some/most implementations allow you to change the port number.

-- 
These are my opinions.  I hate spam.

---

From: Miroslav Lichvar <[email-masked]>
Date: Mon, 7 Jun 2021 10:30:03 +0200

> Any clues/examples of this type of NATs?

I don't remember seeing something like that.

An issue specific to NAT and the anti-DDoS mitigations is that when
multiple clients are using the same server, only one can have the
publicly visible port 123 at a time. If that port is blocked in a
firewall elsewhere in the network, it causes weird behavior, when NTP
sometimes work and sometime does not.

-- 
Miroslav Lichvar

---

From: Fernando Gont <[email-masked]>
Date: Mon, 7 Jun 2021 16:55:49 +0000

Hello, Hal,

On Fri, 2021-06-04 at 01:07 -0700, Hal Murray wrote:
> Does that make sense?

FWIW, we're not discussing whether that makes sense, but rather wether
there are devices that do that. :-)

>   What happens if 3 systems inside the NAT box all send 

Indeed, such behavior would break these deployments.

FWIW, this case was raised on this mailing-list -- hence I-m asknig for
references here...

Thanks!

Regards,

---

From: Fernando Gont <[email-masked]>
Date: Thu, 10 Jun 2021 09:37:43 +0000

Hi, Miro,

> sometimes work and sometime does not.

I'm now considering whether we'd be better off removing the whole
Section 3.4.? i.e., remove this:

---- cut here ----
 3.4.  Effect on NAT devices

  Some NAT devices will not translate the source port of a packet when
  a privileged port number is employed.  In networks where such NAT
  devices are employed, use of the NTP well-known port for the client
  port will essentially limit the number of hosts that may successfully
  employ NTP client implementations.

  In the case of NAT devices that will translate the source port even
  when a privileged port is employed, packets reaching the external
  realm of the NAT will not employ the NTP well-known port as the local
  port, since the local port will normally be translated by the NAT
  device possibly, but not necessarily, with a random port.
---- cut here ----

Thoughts?

Thanks!

Regards,

---

From: Miroslav Lichvar <[email-masked]>
Date: Thu, 10 Jun 2021 16:44:48 +0200

> Section 3.4.? i.e., remove this:

That would work for me.

There is an effect of NAT that could be mentioned if you are
considering some replacement for the text. NATs typically have a
shorter timeout for UDP sessions that the client polling interval, so
if there are multiple clients using the same server behind NAT, their
source port from the server's point of view will be randomized even if
their local port is the same.

-- 
Miroslav Lichvar

---

From: Hal Murray <[email-masked]>
Date: Thu, 10 Jun 2021 10:46:24 -0700

fernando.gont=[email-masked] said:
> I'm now considering whether we'd be better off removing the whole Section
> 3.4.? i.e., remove this: 

I agree that we could drop it, but it I didn't know about that quirk and it 
seems a shame to discard information that isn't otherwise documented or well 
known.

Maybe move it to an appendix?

Does any NTP code depend on the source port being 123?  I think NTPsec has an 
option to require it but I've never used it.  It might be useful to filter out 
broken software but won't help with security.

---

From: Fernando Gont <[email-masked]>
Date: Fri, 11 Jun 2021 01:56:59 +0000

Hi, Miro,

> their local port is the same.

Are you assuming that if there's a "collision" at the NAT, the NAT will
change the service port to some other port?

In any case,

1) noting this would b tricky: it has been noted that in some of those
cases, the NAT may randomize the port, but from the same pool
(privileged vs non-privileged ports).

2) Since the behavior probably varies from one implementation to
another, and since I'm not sure it would be easy to reference such
behavior, I wonder if we'd be better off simply removing the text....

Thanks!

Regards,

---

From: Fernando Gont <[email-masked]>
Date: Fri, 11 Jun 2021 02:10:10 +0000

> seems a shame to discard information that isn't otherwise documented

The behavior that we describe in our document seems similar to the one
for 500/udp: https://datatracker.ietf.org/doc/html/rfc3715#section-2.3

However, I haven;'t been able to find a similar reference for UDP/123..
  :-(

> broken software but won't help with security.

I guess it all depends on whether they apply the robustness principle ("be liberal in what you accept..."). HOwever, in the current NAPT-dominated world, a server that were to enforce that check would essentially prevent service to a large number of NTP clients:  both because some clients already perform port randomization, but also because in the event of collisions, NAPTs will rewrite the ports....

Thanks!

Regards,

---

From: Miroslav Lichvar <[email-masked]>
Date: Mon, 14 Jun 2021 11:51:27 +0200

> change the service port to some other port?

Yes. If there are multiple connections to a server, they cannot share
the same port of the NAT. If the source port 123 is blocked as a
mitigation against the mode-6 amplification attacks, this can cause
weird issues with NTP clients sometimes working and not working due to
the randomness of the connection that gets the port 123.

-- 
Miroslav Lichvar