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

Hi Miroslav,

I find the reasoning very convincing and very well explained. 

Best Regards,
   Heiko

-- 
Heiko Gerstung 
Managing Director 

MEINBERG® Funkuhren GmbH & Co. KG 
Lange Wand 9 
D-31812 Bad Pyrmont, Germany 
Phone: +49 (0)5281 9309-404 
Fax: +49 (0)5281 9309-9404 

Amtsgericht Hannover 17HRA 100322 
Geschäftsführer/Management: Günter Meinberg, Werner Meinberg, Andre Hartmann, Heiko Gerstung 

Email: 
heiko.gerstung@meinberg.de
Web: 
Deutsch https://www.meinberg.de
English https://www.meinbergglobal.com

Do not miss our Time Synchronization Blog: 
https://blog.meinbergglobal.com

Connect via LinkedIn: 
https://www.linkedin.com/in/heikogerstung

Am 13.11.19, 12:22 schrieb "ntp im Auftrag von Miroslav Lichvar" <ntp-bounces@ietf.org im Auftrag von mlichvar@redhat.com>:

    On Fri, Nov 01, 2019 at 08:58:37AM -0700, internet-drafts@ietf.org 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.

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

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

    Does that make sense?

    -- 
    Miroslav Lichvar

    _______________________________________________
    ntp mailing list
    ntp@ietf.org
    https://www.ietf.org/mailman/listinfo/ntp