Re: [Ntp] New I-D: NTP Port Randomization (draft-gont-ntp-port-randomization-00.txt)

[Miroslav Lichvar <[e-mail]>]

On Thu, Apr 25, 2019 at 02:17:18PM +0200, Fernando Gont wrote:
> On 24/4/19 10:34, Miroslav Lichvar wrote:
> > I think most, if not all, rely on the OS to do that. When there is no
> > OS, it seems it's common to use a fixed port, but different from 123.
> 
> Maybe we could make an explicit note that in order to comply with this
> spec, you can normally rely on the underlying OS for doing the
> randomization part?

That's a good idea.

> -- and then learn the selected port to store it in
> the NTP data structure.

NTP clients don't need to know their source port. They should just
use an unbound socket, like with most TCP/UDP-based protocols.

Another thing that might be good to include in the document is a
recommendation for minimum time that the socket should be open.
(Some?) public NTP servers receive large amounts of ICMP packets that
seem to be from implementations not waiting long enough for a
response, so when the response actually gets there, the port is
already closed, which triggers an ICMP response.

> > There are many peaks in the port distribution observed on servers.
> 
> That's interesting. -- any clues if that's an artifact of NATs rewriting
> the local port or something else?

I'm not sure. I think at least some part of it are extremely simple
clients using a fixed source port. There are implementations broken in
unique ways and they have a consistent use of the source port. Some
don't even use a random transmit timestamp, i.e. it's trivial to spoof
a response they will accept.

An NTP usage analysis by NIST has a nice graph showing the
distribution of the source port on page 7:
https://nvlpubs.nist.gov/nistpubs/jres/121/jres.121.003.pdf

> > It depends on the configuration. If a peer has the other peer
> > specified in the config, it's using the active mode.
> 
> So it would be active-mode on both sides, leading to a single association?

Yes.

> > In the general case yes, but it could be enabled in the configuration file.
> 
> Are you assuming symmetric-passive on one side, and symmetric-active on
> the other, with the later employing port randomization? -- that's the
> only case of symmetric mode where it'd seem to me one can randomize the
> port.

Yes.

> Side question: any clues regarding what's the normal deployed model for
> symmetric mode? -- i,.e., is the usual thing to configure one peer with
> passive mode, and the other in active mode? Or is the usual thing to
> configure both peers in active mode? (i.e., have both peers try to
> actively mobilize an association), instead of waiting for the other end
> to do it).

My guess is that it's more common for both peers to be configured in
the active mode. They could be configured as clients and it would work
almost exactly the same. I have not seen the passive mode used very
often. But it can be very useful when the server is behind NAT.

-- 
Miroslav Lichvar