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

From: Fernando Gont <[email-masked]>
Date: Tue, 16 Apr 2019 23:19:27 +0200

Folks,

We have published a new I-D (draft-gont-ntp-port-randomization),
entitled "Port Randomization in the Network Time Protocol Version 4".

The I-D is available at:
https://www.ietf.org/internet-drafts/draft-gont-ntp-port-randomization-00.txt

Your comments will be very appreciated.

Thanks,
Fernando

-------- Forwarded Message --------
Subject: New Version Notification for
draft-gont-ntp-port-randomization-00.txt
Date: Tue, 16 Apr 2019 14:16:14 -0700
From: [email-masked]
To: Fernando Gont <[email-masked]>, Guillermo Gont
<[email-masked]>

A new version of I-D, draft-gont-ntp-port-randomization-00.txt
has been successfully submitted by Fernando Gont and posted to the
IETF repository.

Name:		draft-gont-ntp-port-randomization
Revision:	00
Title:		Port Randomization in the Network Time Protocol Version 4
Document date:	2019-04-16
Group:		Individual Submission
Pages:		5
URL:
https://www.ietf.org/internet-drafts/draft-gont-ntp-port-randomization-00.txt
Status:
https://datatracker.ietf.org/doc/draft-gont-ntp-port-randomization/
Htmlized:
https://tools.ietf.org/html/draft-gont-ntp-port-randomization-00
Htmlized:
https://datatracker.ietf.org/doc/html/draft-gont-ntp-port-randomization

Abstract:
   The Network Time Protocol can operate in several modes.  Some of
   these modes are based on the receipt of unsolicited packets, and
   therefore require the use of a service/well-known port as the local
   port number.  However, in the case of NTP modes where the use of a
   service/well-known port is not required, employing such well-known/
   service port unnecessarily increases the ability of attackers to
   perform blind/off-path attacks, since knowledge of such port number
   is typically required for such attacks.  This document formally
   updates RFC5905, recommending the use of port randomization for those
   modes where use of the NTP service port is not required.

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

---

From: Miroslav Lichvar <[email-masked]>
Date: Thu, 18 Apr 2019 14:36:48 +0200

> https://www.ietf.org/internet-drafts/draft-gont-ntp-port-randomization-00.txt

Thanks for writing the draft. Just a few quick comments.

The source port in client mode packets can be random and it can also
change with each request, which might be recommended in the document.
Most NTP clients do that.

The source port in active mode packets doesn't necessarily have to be
123. It can be random if the other peer is not expected to have a
permanent association with the peer, but it must not change between
requests as that would create new assocations.

In the NTS draft there is a port negotiation record, so proper NTP
servers will be able to run on other ports than 123.

-- 
Miroslav Lichvar

---

From: Fernando Gont <[email-masked]>
Date: Fri, 19 Apr 2019 00:56:04 +0200

Hello, Miroslav,

Thanks so much for your feedback! In-line...

> Most NTP clients do that.

FWIW, I'm running ntpd [email-masked] on Ubuntu, and all packets use
src port 123.

> requests as that would create new assocations.

Are you referring to to symmetric mode? My understanding is that if one
of the peers employs a port other than 123, then symmetric mode would
result in two different associations, rather than a single one. Am I
missing something?

> servers will be able to run on other ports than 123.

Thanks for the note!

Cheers,
-- 
Fernando Gont
SI6 Networks
e-mail: [email-masked]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492

---

From: Miroslav Lichvar <[email-masked]>
Date: Tue, 23 Apr 2019 10:48:53 +0200

> FWIW, I'm running ntpd [email-masked] on Ubuntu, and all packets use

Yes, ntpd and ntpdate (without -q or -d) seem to be in the minority of
clients using source port 123.

> result in two different associations, rather than a single one. Am I

Yes, symmetric mode.

If both peers are using the active mode (i.e. permanent association),
they need to use the same port numbers in order to avoid creating more
associations. If one of them is expected to be using passive mode
(i.e. ephemeral association or stateless), I think the active peer can
use any source port as long as it doesn't change (frequently).

-- 
Miroslav Lichvar

---

From: Fernando Gont <[email-masked]>
Date: Wed, 24 Apr 2019 01:17:43 +0200

> clients using source port 123.

Any clues whether in other cases they explicitly randomize the source
port, or rely on the kernel doing port randomization?

> use any source port as long as it doesn't change (frequently). 

Stupid question: Can the peer doing active mode assume that the other
peer will be using passive mode? I don't recall of the top of my head:
is symmetric mode where both peers employ active mode supported? (as in
e.g. TCP simultaneous open)

If use of symmetric mode always means that one peer does passive mode,
and the other does active mode, then it would be safe to randomize the
port on the peer doing active mode.

OTOH, if symmetric mode where both endpoints do active mode is
supported, then it would seem to me it wouldn't be possible to randomize
the port on symmetric mode -- since otherwise you wouldn't know which
port to connect to.

Thanks!

Cheers,

---

From: "Ulrich Windl" <[email-masked]>
Date: Wed, 24 Apr 2019 08:12:40 +0200

>>> Fernando Gont <[email-masked]> schrieb am 24.04.2019 um 01:17 in
Nachricht <[email-masked]>:
>>> FWIW, I'm running ntpd [email-masked]‑o on Ubuntu, and all packets use
>>> src port 123.
>> 
>> Yes, ntpd and ntpdate (without ‑q or ‑d) seem to be in the minority of

Basically I think there are only two cases:
1) You care and pick a port number like 123
2) You don't care and use 0 as port number, causing the OS to pick one for
you

I see no point of explicitly selecting a random post, specifically when you
can't be sure whether another process has picked that already, too.

[...]

Regards,
Ulrich Windl

---

From: Fernando Gont <[email-masked]>
Date: Wed, 24 Apr 2019 08:36:58 +0200

> can't be sure whether another process has picked that already, too.

Well, if you care about doing port randomization, but the OS does not
implement it, maybe that's your only option?

-- yes, you don't know if the port has been picked already, so you'd
have to consider the case where bind() fails, and you need to pick a
different random port and try again...

---

From: Miroslav Lichvar <[email-masked]>
Date: Wed, 24 Apr 2019 10:34:40 +0200

> port, or rely on the kernel doing port randomization?

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.
There are many peaks in the port distribution observed on servers.

> e.g. TCP simultaneous open)

It depends on the configuration. If a peer has the other peer
specified in the config, it's using the active mode. There could be an
option to enable random source port for the case when I know the other
peer doesn't have this one specified in the config (e.g. because it's
behind NAT).

> the port on symmetric mode -- since otherwise you wouldn't know which

In the general case yes, but it could be enabled in the configuration file.

-- 
Miroslav Lichvar

---

From: Fernando Gont <[email-masked]>
Date: Thu, 25 Apr 2019 14:17:18 +0200

> 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? -- and then learn the selected port to store it in
the NTP data structure.

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

(We worked on RFC6056 years ago, and I would have expected that the port
distribution was mostly normal...)

> specified in the config, it's using the active mode.

So it would be active-mode on both sides, leading to a single association?

> There could be an

I may be confused: how do you connect to the other endpoint if it has
randomized the local port?

> 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.

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

Thanks!

Cheers,

---

From: Miroslav Lichvar <[email-masked]>
Date: Thu, 25 Apr 2019 16:25:37 +0200

On Thu, Apr 25, 2019 at 02:17:18PM +0200, Fernando Gont wrote:
> 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.

> 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

> So it would be active-mode on both sides, leading to a single association?

Yes.

> only case of symmetric mode where it'd seem to me one can randomize the

Yes.

> actively mobilize an association), instead of waiting for the other end

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