Subject: [Ntp] Antw: Re: New rev of the NTP port randomization I-D (Fwd: New Version Notification for draft-gont-ntp-port-randomization-01.txt)

From: "Ulrich Windl" <[email-masked]>
Date: Mon, 03 Jun 2019 07:56:03 +0200

>>> Harlan Stenn <[email-masked]> schrieb am 29.05.2019 um 19:15 in Nachricht
<[email-masked]>:

[...]
> If your point is to change the last sentence of RFC590 9.1 where it says:
> 
>    srcport: UDP port number of the server or reference clock.  This
>    becomes the destination port number in packets sent from this
>    association.  When operating in symmetric modes (1 and 2), this field
>    must contain the NTP port number PORT (123) assigned by the IANA.  In
>    other modes, it can contain any number consistent with local policy.
> 
> to:
> 
>    ... In other modes, it SHOULD contain any number consistent with
>    local policy.

As "local policy" is quit unspecific, I see no gain in using SHOULD. I'd even prefer MAY (to point out the level of uncertainty regarding port numers in this case).

> I'm fine with that.
[...]

Regards,
Ulrich

---

From: Miroslav Lichvar <[email-masked]>
Date: Tue, 4 Jun 2019 10:17:40 +0200

On Thu, May 30, 2019 at 02:19:59PM -0400, Fernando Gont wrote:
> > If you had two clients in your network and they were synchronized to
> > the same server, there could be a significant offset between their
> > clocks if they used a fixed port. If they randomized their ports with
> > each request, the offset should be smaller and not change randomly
> > when the clients are restarted, etc.
> 
> Agreed. My question is: should one aim at the individual measurements to
> be dropped, or at the server to be un-preferred over other (possibly
> better) ones? -- I realize that in some scenarios this might happen with
> all servers, in which case the former option (have individual
> measurements dropped) might be a better option.

I think both. The client should use only the best measurements from
each server and then select the best servers for synchronization. A
server with a highly unstable delay may still be prefered over a
server with stable but larger delay, or if it better fits a cluster
of other servers.

-- 
Miroslav Lichvar

---

From: Fernando Gont <[email-masked]>
Date: Tue, 4 Jun 2019 09:37:00 +0300

On 29/5/19 21:58, Fernando Gont wrote:
> Harlan,
> 
> Responding this one in a separate email, since it seems we're converging
> on something...
> 
> On 29/5/19 13:15, Harlan Stenn wrote:
>>
> [....]>> Using randomized port numbers requires yet additional effort on
> the side
>>> of the attacker. And means that the attacker now needs to guess the
>>> client port, or otherwise his packets will not even make it to the ntp
>>> process.
>>
>> I'm fine with that.>
> Yes. That's the whole point of this document.

Sorry. THe point of the document is to change that to "SHOULD randomize
the port number". THat's the BCP of the transport area.

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

---

From: Harlan Stenn <[email-masked]>
Date: Tue, 4 Jun 2019 02:47:42 -0700

> the port number". THat's the BCP of the transport area.

If your local policy is randomization, that's fine.

I'm happy with what I wrote.

What I think is needed here is robust mechanism, not single-perspective
policy.

-- 
Harlan Stenn, Network Time Foundation
http://nwtime.org - be a Member!

---

From: Fernando Gont <[email-masked]>
Date: Fri, 7 Jun 2019 13:08:16 +0300

> If your local policy is randomization, that's fine.

The transport area has produced a BCP recommending that ephemeral port
numbers should be randomized.

Are we just implicitly saying that we don't care about the advice of the
transport area?

---

From: Aanchal Malhotra <[email-masked]>
Date: Sun, 9 Jun 2019 00:23:49 -0400

Hi All,

For those curious about the success probability of off-path attacks with
randomized transmit timestamps, I would suggest refering to Section 7 of
the paper "Security of NTP's datagram protocol
<https://eprint.iacr.org/2016/1006/20161026:151159>".  It has detailed
analysis of off-path attacks on NTP where attacker tries to predict the
transmit timestamp.

Best,
Aanchal Malhotra.

On Fri, Jun 7, 2019 at 7:05 AM Fernando Gont <[email-masked]> wrote:

> _______________________________________________
> ntp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ntp
>