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

From: [email-masked]
Date: Fri, 01 Nov 2019 08:58:37 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Network Time Protocol WG of the IETF.

        Title           : Port Randomization in the Network Time Protocol Version 4
        Authors         : Fernando Gont
                          Guillermo Gont
                          Miroslav Lichvar
	Filename        : draft-ietf-ntp-port-randomization-00.txt
	Pages           : 10
	Date            : 2019-10-22

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.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-ntp-port-randomization/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-ntp-port-randomization-00
https://datatracker.ietf.org/doc/html/draft-ietf-ntp-port-randomization-00

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.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Miroslav Lichvar <[email-masked]>
Date: Wed, 13 Nov 2019 12:21:26 +0100

> 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

---

From: "Ulrich Windl" <[email-masked]>
Date: Wed, 13 Nov 2019 12:49:32 +0100

>>> Miroslav Lichvar <[email-masked]> schrieb am 13.11.2019 um 12:21 in
Nachricht <20191113112126.GA2634@localhost>:
> On Fri, Nov 01, 2019 at 08:58:37AM ‑0700, internet‑[email-masked] wrote:
>> https://tools.ietf.org/html/draft‑ietf‑ntp‑port‑randomization‑00 
> 
> This document describes a per‑association and per‑request approach for
> disadvantages. It currently strongly recommends the per‑association
> I'd like to propose changing the recommendation to the per‑request
> ‑ It seems to be the current practice. From the implementations

>From remote you cannot know whether it's the same instance of the same client
sending the requests.
My guess is that the client does not specify the source port, so for each
socket a free (not "random") port will be chosen. The implementation rationale
most likely is that "it's easier", not because "it's better".

> 
> ‑ It doesn't seem like a good idea to require a client to keep its

Again: Keeping the port open seems (at least in classical, more static
programming languages) easier.

> 
> ‑ The port number may be discoverable by other means, so it should

That's the only real reason I could imagine using variable ports: You want to
hide who you are. Actually I think clients using public servers should not hide
who they are. Usually the evil ones do or try to.

>   the general case, the time for which it is useful for attacks should

Actually today any (well-known) port is attacked, even if it never sent any
packet.

> Does that make sense?

I think I said it before: The server SHOULD still work if the client changes
the port number (leaving it open to the server to assume that it's a different
client then), but I would NOT require the client to vary the source port
number.

Maybe the main part should be a discussion of privacy/security improvements
expected when using a variable port number. I think it does not improve the
overall reliability of the service.

Regards,
Ulrich Windl

---

From: Heiko Gerstung <[email-masked]>
Date: Wed, 13 Nov 2019 14:27:04 +0100

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: 
[email-masked]
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" <[email-masked] im Auftrag von [email-masked]>:

    

    

    Does that make sense?
    
    -- 
    Miroslav Lichvar
    
    _______________________________________________
    ntp mailing list
    [email-masked]
    https://www.ietf.org/mailman/listinfo/ntp

---

From: "Salz, Rich" <[email-masked]>
Date: Wed, 13 Nov 2019 13:41:59 +0000

>    I find the reasoning very convincing and very well explained. 

Agreed.  Perhaps it is worth looking to see what DNS client libraries do?

---

From: Miroslav Lichvar <[email-masked]>
Date: Wed, 13 Nov 2019 17:00:55 +0100

> >From remote you cannot know whether it's the same instance of the same client

Yes, there could be multiple clients (e.g. behind NAT), but I think we
can make a good guess whether any of them use a stable port by
counting how many requests are there per port. When I analyze 24-hour
captures from public servers in few different countries, for most
addresses there seem to be only one request per port. I'm ignoring
addresses that send only requests from some popular fixed ports like
123, 1024, 1490.

> most likely is that "it's easier", not because "it's better".

I'm not sure if it's really easier. The port assigned by the system
should be random. Do you have an example of a widely used
implementation keeping a socket open which is not also used for
different servers?

> client then), but I would NOT require the client to vary the source port

It's not meant to be a requirement, just a recommendation.

-- 
Miroslav Lichvar

---

From: "Salz, Rich" <[email-masked]>
Date: Wed, 13 Nov 2019 17:10:01 +0000

>From remote you cannot know whether it's the same instance of the same client
   
Yeah, you can if you're operating at a national-scale level targeting individuals.

As you say, it's a recommendation.

---

From: "Ulrich Windl" <[email-masked]>
Date: Thu, 14 Nov 2019 09:17:00 +0100

>>> Miroslav Lichvar <[email-masked]> schrieb am 13.11.2019 um 17:00 in
> addresses that send only requests from some popular fixed ports like

So your result is more or less biased: What if that fixed popular ports are
99% of all requests? Then you are csaling up the remaining 1% to support your
view. That's not serious argumenting.

> implementation keeping a socket open which is not also used for

I mean this: If the client specified a specific port, the client has to make
sure that the port isn't in use. If you specify 0 as port, the system picks a
free one for you. Thats easier.

---

From: Miroslav Lichvar <[email-masked]>
Date: Thu, 14 Nov 2019 10:13:02 +0100

> view. That's not serious argumenting.

The percentage of addresses using the fixed ports is about 10-25% in
my data. It varies between countries. But I don't think it matters
here. I'm comparing the per-association and per-request port
randomization. The fixed ports are not random.

A problem with my analysis is that it assumes most NATs preserve the
UDP port numbers at least for one client in the local network. I'm not
sure how common that really is. With NATs that always select the UDP
port randomly and clients using a polling interval longer that the NAT
timeout, it will look like the per-request randomization even if their
local port is stable. However, from the server's and Internet point of
view it doesn't matter if it's the client or NAT doing the
randomization.

> free one for you. Thats easier.

Even easier is to not bind the socket at all. It will be bound
automatically to a random port when the first request is sent.

-- 
Miroslav Lichvar

---

From: Fernando Gont <[email-masked]>
Date: Sun, 17 Nov 2019 21:31:35 -0300

Hello, Miroslav,

>   public servers I see that most clients do change their port over

I agree.

>   after sending the request, it should close the port.

Same here.

>   the general case, the time for which it is useful for attacks should

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: [email-masked]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492

---

From: Fernando Gont <[email-masked]>
Date: Mon, 18 Nov 2019 01:25:39 -0300

> most likely is that "it's easier", not because "it's better".

Most implementations randomize the ephemeral ports by default. So, if
the app doesn't bind a specific port, it relies on the OS, and most
popular OSes do ephemeral port randomization.

> who they are. Usually the evil ones do or try to.

This has changed, based on the evidence of pervasive monitoring. For
instance, please see RFC8064 and RFC4941.

Thanks,

---

From: Miroslav Lichvar <[email-masked]>
Date: Mon, 18 Nov 2019 11:34:51 +0100

> to a request from a random host?

Yes, the client's port should be "connected" to the server, so it is
closed for other hosts.

The point I'm trying to make is that the client may also operate as a
server listening on the port 123 and respond to mode 6 requests (e.g.
from hosts in the local network), allowing an attacker to observe some
of the client's state. It doesn't have to be the client leaking its
port number. It could be any host on the path between the server and
client, for example a firewall that has a monitoring access.

-- 
Miroslav Lichvar