Re: NAT devices not translating privileged ports

[Fernando Gont via NANOG <nanog () nanog org>]

Hi, Jean,

On Thu, 2021-06-10 at 08:23 -0400, Jean St-Laurent wrote:
> Let's start with this example. When I click sync my clock in windows,
> this happened. 
>
> On the inside or Private side
> 08:15:07.434344 IP 192.168.254.205.123 > 13.86.101.172.123: NTPv3,
> Client, length 48
> 08:15:07.473681 IP 13.86.101.172.123 > 192.168.254.205.123: NTPv3,
> Server, length 48
>
> You are indeed right that the client must use UDP port 123. Is the
> RFC saying must or should on the client SRC port? I'm not sure.

Section 9.1 ("Peer Process Variables") of [RFC5905] SAYS:

      dstport: UDP port number of the client, ordinarily the NTP port
      number PORT (123) assigned by the IANA.  This becomes the source
      port number in packets sent from this association.


That said, as noted in 
https://datatracker.ietf.org/doc/html/draft-ietf-ntp-port-randomization-06#section-5
 , other client implementations don't bind the local port to 123, and
hence assign an ephemeral port.



> But, on the Public, this happened.
> 08:15:07.434381 IP 192.2XX.XXX.58291 > 13.86.101.172.123: NTPv3,
> Client, length 48
> 08:15:07.473656 IP 13.86.101.172.123 > 192.2XX.XXX.58291: NTPv3,
> Server, length 48
>
> // Public ip obfuscated. I know, it indeed starts with 192.2. It's
> EBOX in Canada.
>
> What we see on the public side, is that a network device did a NAT
> translation of the SRC UDP port to 58921. My clock synced perfectly.
>
> So your goal is to find the devices that don't follow this behaviour,
> right?

> No. The goal of our I-D is that NTP clients randomize their source
> port -- there's no need for clients to use port 123, and using that
> port on the client side has negative security implications.

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