Subject: [Ntp] I-D Action: draft-ietf-ntp-port-randomization-01.txt

From: [email-masked]
Date: Mon, 09 Mar 2020 16:58:43 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Network Time Protocol WG of the IETF.

        Title           : Port Randomization in the Network Time Protocol Version 4
        Authors         : Fernando Gont
                          Guillermo Gont
                          Miroslav Lichvar
	Filename        : draft-ietf-ntp-port-randomization-01.txt
	Pages           : 10
	Date            : 2020-03-09

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.  This document formally updates
   RFC5905, recommending the use of port randomization for those modes
   where use of the NTP service port is not required.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-ntp-port-randomization/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-ntp-port-randomization-01
https://datatracker.ietf.org/doc/html/draft-ietf-ntp-port-randomization-01

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-ntp-port-randomization-01

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.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Fernando Gont <[email-masked]>
Date: Tue, 10 Mar 2020 04:57:55 -0300

Folks,

FWIW, this version should be ready for WGLC.

Thanks!

Cheers,
Fernando

On 9/3/20 20:58, [email-masked] wrote:
> _______________________________________________
> ntp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ntp
> 

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

---

From: Tomoyuki Sahara <[email-masked]>
Date: Wed, 11 Mar 2020 19:28:15 +0900

Hi,

Thanks for this well-written document.  I have read the document and
have one comment.

>         When port randomization is employed, the port number SHOULD be
>         randomized on a per-association basis.  That is, a random port

I feel "SHOULD" is a bit too strong.  Per-association randomization
may be better for delay estimation and stability, but it also has
some drawbacks as is said on the list (implementation complexity
to block unwelcomed incoming packets is compelling reason for me).

and a few nits:

>         of "any port". connect()ing the docket will make the port

docket -> socket

>              "OpenNTPD Project", <https://www.openntpd.org>.

www.openntpd.org does not support HTTPS.
(though, this reference will be removed by RFC Editor)

Thanks,
Tomoyuki

---

From: Fernando Gont <[email-masked]>
Date: Wed, 11 Mar 2020 11:08:10 -0300

Hello, Tomoyuki,

Thanks a lot for your comments! -- In-line....

> to block unwelcomed incoming packets is compelling reason for me).

So are you arguing against "port randomization" in general, or are you 
arguing that it should be up to the implementation to decide whether to 
randomize on a per-association or per-request basis?

> (though, this reference will be removed by RFC Editor)

Will fix both in the next rev.

Thanks!

Cheers,

---

From: Tomoyuki Sahara <[email-masked]>
Date: Thu, 12 Mar 2020 09:56:01 +0900 (JST)

Hi, Fernando:

>So are you arguing against "port randomization" in general, or are
>you arguing that it should be up to the implementation to decide
>whether to randomize on a per-association or per-request basis?

I mean the latter.  I'm in favor of "port randomization" in general
but I think the decision whether a client supports per-association
randomization, per-request randomization, or both can be up to
implementer.  Sorry for my lack of words.

Thanks,
Tomoyuki

---

From: Fernando Gont <[email-masked]>
Date: Thu, 12 Mar 2020 11:36:07 -0300

> implementer.  Sorry for my lack of words.

I agree with you.

What do other think about this?

Thanks!

Cheers,