Subject: [Ntp] Fwd: New Version Notification for draft-ietf-ntp-port-randomization-02.txt

From: Fernando Gont <[email-masked]>
Date: Thu, 16 Apr 2020 15:22:08 -0300

Folks,

FWIW, we have posted a revision according to the recent feedback and the 
discussion at the interim meeting.

We believe this version is ready for WGLC.

Thanks,
Fernando

-------- Forwarded Message --------
Subject: New Version Notification for 
draft-ietf-ntp-port-randomization-02.txt
Date: Thu, 16 Apr 2020 11:18:59 -0700
From: [email-masked]
To: Miroslav Lichvar <[email-masked]>, Guillermo Gont 
<[email-masked]>, Fernando Gont <[email-masked]>

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

Name:		draft-ietf-ntp-port-randomization
Revision:	02
Title:		Port Randomization in the Network Time Protocol Version 4
Document date:	2020-04-16
Group:		ntp
Pages:		10
URL: 
https://www.ietf.org/internet-drafts/draft-ietf-ntp-port-randomization-02.txt
Status: 
https://datatracker.ietf.org/doc/draft-ietf-ntp-port-randomization/
Htmlized: 
https://tools.ietf.org/html/draft-ietf-ntp-port-randomization-02
Htmlized: 
https://datatracker.ietf.org/doc/html/draft-ietf-ntp-port-randomization
Diff: 
https://www.ietf.org/rfcdiff?url2=draft-ietf-ntp-port-randomization-02

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.

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: Steven Sommars <[email-masked]>
Date: Thu, 16 Apr 2020 19:06:33 -0500

Question: The draft doesn't enumerate the NTP modes of concern.  Is Mode 3
specifically covered?
Off-path attacks for Mode 3/Mode 4 exchanges are already difficult since
the Mode 3 (request) transmit time stamp must
be returned in the Mode 4 (response) message.  If predictable transmit time
stamps are a concern then a random transmit time stamp
(a la Chrony) can be used.

Comment:  Some older NTP server implementation tracked per-client usage
based on
client IP + source port.   Port randomization will increase the apparent
number of clients tracked.
I don't know if this is a server performance issue, just wanted to mention
it.

3.2. Effects on Path Selection

"If the clients changed their source port with each request, packets in
different exchanges would take different paths."

    s/would/could/

"The measured delay and offset would be less stable..."

    The measured delay is the RTT; sum of request delay and response
delay.  Occasionally the request and response delays
    on different client UDP ports differ by +delay and -delta respectively.
There is no "best" sample to choose since the RTT is
    nearly constant.

    Suggest changing this paragraph to:
        When clients change their source ports with each request the RTT
may be more variable.  Whether this improves or worsens
        time and frequency transfer is unpredictable.

3.3 Filtering of NTP traffic

"Implementation of port randomization for non-symmetrical modes allows for
simple differentiation of NTP requests and responses"

    Such differentiation is only possible if the the use of port
randomization is universal.

On Thu, Apr 16, 2020 at 1:22 PM Fernando Gont <[email-masked]> wrote:

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

---

From: Miroslav Lichvar <[email-masked]>
Date: Tue, 21 Apr 2020 11:37:59 +0200

> Question: The draft doesn't enumerate the NTP modes of concern.  Is Mode 3

In the section "4.  Update to RFC5905" the updated text says in which
modes randomization shouldn't be applied (modes 1, 2, 5) and that it
should be applied in the other cases (i.e. modes 3, 4). Do you
think the "other" modes need to be listed?

> be returned in the Mode 4 (response) message.

That depends on the implementation. For instance, a vulnerability was
recently published for the "reference" implementation that it has
highly predictable transmit timestamps, which makes an off-path attack
taking control over the client's clock practical, even when the client
is using multiple servers. If it randomized the port, the attack
wouldn't be practical.

> If predictable transmit time

Yes, that would prevent the attack, but as the draft explains port
randomization is a mitigation at a different layer than the
application protocol and is recommended by BCP 156.

> client IP + source port.

Which server implementation did that?

> Port randomization will increase the apparent

As NAT is widely used and the typical timeout for UDP connection
tracking seems shorter than typical polling interval, I don't think
the port randomization will make it significantly worse.

> different exchanges would take different paths."

Ok, makes sense.

> There is no "best" sample to choose since the RTT is

I'm not sure I follow here. If for example between the server and
client there were four paths A, B, C, D with delays 10, 20, 30, 40 ms
respectively, it's possible that the request and response would go
only over A+D or B+C?

> randomization is universal.

Right, but some ISPs didn't care and blocked all incoming packets with
destination port 123. It was a common issue reported by users, e.g.
one client in local network oddly not working (the one that doesn't
have port remapped in NAT to a different port) or ntpdate working only
with the -q option (which enables on port randomization).

-- 
Miroslav Lichvar

---

From: Steven Sommars <[email-masked]>
Date: Tue, 21 Apr 2020 10:44:02 -0500

> think the "other" modes need to be listed?
Since modes 3&4 are by far the most common they should be listed.  [Mode 3
can be randomized, Mode 4 cannot.]

> application protocol and is recommended by BCP 156.
OK.

> Which server implementation did that?
I see some per-port tracking in old scans, e.g., ntpd [email-masked]  [Build
date was December 2003]
Such old implementations don't warrant further consideration.

> OK

> This can happen
     Client    Request   Response     RTT      Request-Response
       port      path      path                    delta
      30000       A          D         50           -30
      40000       D          A         50           +30
      50000       B          C         50           -10
as could other combinations.    Here the port 5000 path is most symmetric,
but the filter algorithm won't know that.

We shouldn't imply that port randomization helps time & frequency
transfer.

> NAT bugs can also cause the "one client doesn't work" symptom.

Steve Sommars

---

From: Miroslav Lichvar <[email-masked]>
Date: Tue, 21 Apr 2020 18:04:31 +0200

> can be randomized, Mode 4 cannot.]

The paragraph is about the "dstport" variable of the peer association.
A packet in mode 4 has a random destination port (randomized by the
client).

> but the filter algorithm won't know that.

Ok, but is there a reason why the request and response couldn't go
over A+A, which would have the shortest delay and would be preferred
by the filter?

-- 
Miroslav Lichvar