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

[Miroslav Lichvar <[e-mail]>]

On Thu, Apr 16, 2020 at 07:06:33PM -0500, Steven Sommars wrote:
> Question: The draft doesn't enumerate the NTP modes of concern.  Is Mode 3
> specifically covered?

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?

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

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
> stamps are a concern then a random transmit time stamp
> (a la Chrony) can be used.

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.

> Comment:  Some older NTP server implementation tracked per-client usage
> based on
> client IP + source port.

Which server implementation did that?

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

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.

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

Ok, makes sense.

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

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?

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

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