Re: [Ntp] I-D Action: draft-ietf-ntp-port-randomization-00.txt

[Fernando Gont <[e-mail]>]

Hello, Miroslav,

On 13/11/19 08:21, Miroslav Lichvar wrote:
> On Fri, Nov 01, 2019 at 08:58:37AM -0700, [e-mail] wrote:
>> https://tools.ietf.org/html/draft-ietf-ntp-port-randomization-00
> 
> This document describes a per-association and per-request approach for
> randomizing the client's port number with some of their advantages and
> disadvantages. It currently strongly recommends the per-association
> approach for all clients.
> 
> For a typical client running on an OS it is about opening and closing
> sockets. Should it keep one socket open for the lifetime of the
> association, or should it open a new socket before each request?
> 
> I'd like to propose changing the recommendation to the per-request
> approach for the following reasons:
> 
> - It seems to be the current practice. From the implementations
>   that I'm familiar with and that use a random source port, each one
>   opens a new socket for each request, at least by default. On my
>   public servers I see that most clients do change their port over
>   time.

I agree.



> - It doesn't seem like a good idea to require a client to keep its
>   port open when it's not waiting for a response. If it received a
>   valid response, or didn't receive a valid response in few seconds
>   after sending the request, it should close the port.

Same here.



> - The port number may be discoverable by other means, so it should
>   change frequently. For example, the attacker could try sending
>   packets to all ports and observe which one changed a value reported
>   by the client in a monitoring protocol (e.g. mode 6). If the
>   attacker can determine the port number, which cannot be prevented in
>   the general case, the time for which it is useful for attacks should
>   be limited.

For client mode, I believe that responses should be limited to the
address employed for the association. i.e., why should a client respond
to a request from a random host?

If we did that, you could detect that a port is open (in cases where
you'd receive an ICMP port unreach for closed ports), but there would be
no other information leakages.

Thoughts?

Thanks!

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