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

[Steven Sommars <[e-mail]>]

On Tue, Apr 21, 2020 at 4:38 AM Miroslav Lichvar <[e-mail]>
wrote:

> 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?
>
Since modes 3&4 are by far the most common they should be listed.  [Mode 3
can be randomized, Mode 4 cannot.]


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



> > Comment:  Some older NTP server implementation tracked per-client usage
> > based on
> > client IP + source port.
>
> Which server implementation did that?
>
I see some per-port tracking in old scans, e.g., ntpd 4.1.2@1.892  [Build
date was December 2003]
Such old implementations don't warrant further consideration.


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



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



> > 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).
>
> NAT bugs can also cause the "one client doesn't work" symptom.



> --
> Miroslav Lichvar
>
>

Steve Sommars