Subject: [Ntp] port-randomization: per-request vs. per-association

From: Fernando Gont <[email-masked]>
Date: Mon, 6 Apr 2020 14:43:52 -0300

Folks,

Based on recent feedback and group discussion it would seem to be best 
if draft-ietf-ntp-port-randomization recommends port randomization, 
discusses the trade-offs between per-request and per-association port 
randomization, but leaves the choice of per-request vs per-association 
randomization up to the implementation.

As a result, we plan to apply such change to the document.

Any objections?

Thanks!

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

---

From: Hal Murray <[email-masked]>
Date: Mon, 06 Apr 2020 13:27:53 -0700

[email-masked] said:
> Based on recent feedback and group discussion it would seem to be best  if
> draft-ietf-ntp-port-randomization recommends port randomization,  discusses
> the trade-offs between per-request and per-association port  randomization,
> but leaves the choice of per-request vs per-association  randomization up to
> the implementation.

> Any objections? 

Thanks.  If you hadn't said that, I would have had to type in something 
similar.

There is a 3rd case, a socket with a random port number shared by all 
associations.  It might be worth pointing out that that way is not recommended.

--------

>From the virtual meeting notes:
> Danny: the cost of doing it for each request is very high.

How high is the cost?  Is it significant?

We are talking about the client side which is generally considered to be low 
on resource consumption.

-- 
These are my opinions.  I hate spam.

---

From: Fernando Gont <[email-masked]>
Date: Mon, 6 Apr 2020 17:34:15 -0300

> associations.  It might be worth pointing out that that way is not recommended.

Agreed.

> We are talking about the client side which is generally considered to be low

While this doesn't really respond the question in terms of magnitudes 
(numbers/units), I'd point out that a number of deployed implementations 
such as chrony already do this.

Miroslav will probably be able to add more on this topic.

Thanks a lot!

Cheers,

---

From: Hal Murray <[email-masked]>
Date: Mon, 06 Apr 2020 14:05:43 -0700

Another point that may be worth mentioning...  

Having ntpdate use port 123 provides a layer of protection against running it 
when ntpd is already running.

What is the cleanest way to do something to prevent 2 programs from updating 
the system clock at the same time?

---

From: Fernando Gont <[email-masked]>
Date: Mon, 6 Apr 2020 18:17:06 -0300

> the system clock at the same time?

I guess it depends on implementation. Lock-files, etc. LOts of programs 
do that for different purposes and reasons.

---

From: Danny Mayer <[email-masked]>
Date: Mon, 6 Apr 2020 22:16:01 -0400

> the system clock at the same time?
There really is no reliable way to do that. If you could have a modify
clock privilege (Microsoft Windows does) how would you monitor that to
prevent another application or account getting that privilege?

Consider what happens when you are running a VM. What really controls
the clock?

Danny

---

From: Miroslav Lichvar <[email-masked]>
Date: Tue, 7 Apr 2020 09:21:28 +0200

> We are talking about the client side which is generally considered to be low 

It depends on the polling rate and the OS. The cost of opening a new
socket several times per hour should be negligible, but at very high
rates (e.g. 64 times per second) it will probably make a measurable
difference. I guess this is another thing to be considered when
choosing the approach.

> the system clock at the same time?

I'm not sure if that can be prevented in the general case. You could
detect that a clock was adjusted by monitoring the timex frequency and
log a warning message or abort.

You could still bind a socket to the port 123 (discarding all messages)
to prevent ntpdate from adjusting the clock when an NTP server like
ntpd is already running on the machine.

-- 
Miroslav Lichvar