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

From: [email-masked]
Date: Wed, 10 Jun 2020 02:49:08 -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-04.txt
	Pages           : 10
	Date            : 2020-06-10

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-04
https://datatracker.ietf.org/doc/html/draft-ietf-ntp-port-randomization-04

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-ntp-port-randomization-04

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: Tomoyuki Sahara <[email-masked]>
Date: Thu, 11 Jun 2020 15:51:36 +0900 (JST)

Thank you for updating the draft.

One comment on a new text:

>      If a client implementation performs port randomization on a per-
>      request basis, it SHOULD close the corresponding socket/port after
>      each request/response exchange.  The client SHOULD wait for
>      response packets from the server for at least 3 seconds before
>      closing the UDP socket/port, even if a successful response is
>      received.  This will prevent duplicate or delayed server packets
>      from eliciting ICMP port unreachable error messages at the client.

This concern is common to many UDP-based request/response protocols
but most protocols (if not all) do not try to deal with it.  I do not
think it is necessary to mention and recommend (by "SHOULD" word) it
in this document.

Thanks,
Tomoyuki

---

From: "Ulrich Windl" <[email-masked]>
Date: Fri, 12 Jun 2020 09:45:28 +0200

>>> Tomoyuki Sahara <[email-masked]> schrieb am 11.06.2020 um 08:51 in
Nachricht
<27326_1591858318_5EE1D48E_27326_38_1_20200611.155136.1977732866371143955.tsahar
@iij.ad.jp>:
>>      If a client implementation performs port randomization on a per‑
> This concern is common to many UDP‑based request/response protocols

I think if not mentioned explicitly, it should be mentioned by reference to a
document describing that.
The assumption is that the reader of the RFC does _not_ know all existing
recommendations...

> 
> 
> Thanks,
> Tomoyuki
> 
> _______________________________________________
> ntp mailing list
> [email-masked] 
> https://www.ietf.org/mailman/listinfo/ntp

---

From: Steven Sommars <[email-masked]>
Date: Mon, 15 Jun 2020 17:27:13 -0500

I suggested off-list that the authors add such text in order to reduce the
number of pointless server-directed ICMP port unreachables when per-request
randomization is used.  Two cases come to mind:  responses that arrive
slightly after the client decides to stop waiting and when multiple
responses arrive at the client.

Debugging sessions can be confused by seeing these ICMPs messages.

NTP has some differences compared to other UDP protocols.  Many NTP clients
have historically used fixed client ports; moving to per-request
randomization would increase ICMP frequency.  NTP is subject to middlebox
meddling: network delays are sometimes artificially increased.

This is a minor point.  If it is objectionable, then omit the text.

Steve Sommars

---

From: Harlan Stenn <[email-masked]>
Date: Sat, 20 Jun 2020 03:39:23 -0700

If an ntp instance uses these port randomizations, what is the effect of
this on firewalls for both the client and the sender?

What sort of additional resource load does this place on servers that
are interested in implementing rate limiting of incoming client requests?

-- 
Harlan Stenn <[email-masked]>
http://networktimefoundation.org - be a member!

---

From: Miroslav Lichvar <[email-masked]>
Date: Mon, 22 Jun 2020 10:59:14 +0200

> this on firewalls for both the client and the sender?

It depends on the UDP connection tracking timeout and the client's
polling interval. A typical polling interval is longer than a typical
tracking timeout, so the effect shouldn't be significant on average.

A public server should have connection tracking disabled for NTP in
any case.

Please don't forget that the randomization of the client source port
is already happening on a large scale due to NAT.

> are interested in implementing rate limiting of incoming client requests?

Rate limiting of NTP doesn't (or at least shouldn't) use the client
source port, so I'd say none.

-- 
Miroslav Lichvar

---

From: Harlan Stenn <[email-masked]>
Date: Mon, 22 Jun 2020 02:08:55 -0700

Hi Miroslav,

> tracking timeout, so the effect shouldn't be significant on average.

I'm not sure exactly what you mean by "the UDP connection tracking timeout".

What effect(s) are you talking about?

What are your assumptions for the filtering done by the NTP server's
firewall?

What are your assumptions for the filtering done by the NTP client's
firewall?

> A public server should have connection tracking disabled for NTP in

I'm not sure exactly what you mean by "connection tracking" that it
would be disabled for servers.  Servers may well decide to do rate
limiting, for example.

> is already happening on a large scale due to NAT.

Yes, and that's not the issue.  In the NAT issue, it is expected that
the NAT gateway will have a separate firewall.

> source port, so I'd say none.

I'm curious why you believe an NTP server shouldn't use the client
source port as part of the rate limiting calculation.

---

From: Miroslav Lichvar <[email-masked]>
Date: Mon, 22 Jun 2020 11:39:54 +0200

> I'm not sure exactly what you mean by "the UDP connection tracking timeout".

A stateful firewall is tracking connections. That includes NTP
requests and responses. As it doesn't have an infinite amount of
memory, it needs to drop the connections after some time. For UDP
connections that timeout tends to be very short, e.g. two minutes.

I thought you implied with your question that port randomization will
significantly increase the number of connections that the firewall
will need to track.

What problem do you see with firewalls and port randomization?

> would be disabled for servers.  Servers may well decide to do rate

Connection tracking in firewall is not related to rate limiting in NTP
server. The tracking needs to be disabled to avoid losing connections
due to a very large number of NTP clients. It also has an impact on
performance. It's a common issue on public NTP servers.

> source port as part of the rate limiting calculation.

Because many clients don't have a stable source port, e.g. due to NAT.

Why doesn't ntpd use the port in rate limiting?

-- 
Miroslav Lichvar

---

From: Harlan Stenn <[email-masked]>
Date: Mon, 22 Jun 2020 04:00:20 -0700

> What problem do you see with firewalls and port randomization?

I'm just digging in to a possible issue somebody brought up to me.
Before I go in to details I want to understand it better.

> performance. It's a common issue on public NTP servers.

Of course firewall tracking is independent of NTP rate limiting.

As to whether or not a server would disable tracking, that's a local
policy choice.

> Because many clients don't have a stable source port, e.g. due to NAT.

Implementation detail.

> Why doesn't ntpd use the port in rate limiting?

Implementation detail.  Tradeoffs with space requirements, performance, ...

---

From: "Ulrich Windl" <[email-masked]>
Date: Tue, 23 Jun 2020 13:36:44 +0200

>>> Miroslav Lichvar <[email-masked]> schrieb am 22.06.2020 um 11:39 in
Nachricht
<3679_1592818872_5EF07CB7_3679_252_1_20200622093954.GF22085@localhost>:
> On Mon, Jun 22, 2020 at 02:08:55AM ‑0700, Harlan Stenn wrote:

Actually, especially because of NAT the port number IS important.

> ‑‑

---

From: Miroslav Lichvar <[email-masked]>
Date: Tue, 23 Jun 2020 13:51:58 +0200

> Actually, especially because of NAT the port number IS important.

If you receive two requests from the same port, how do you know it is
the same client behind NAT?

If you receive two requests from different ports, how do you know it
is not the same client behind NAT?

You would need to know how is the NAT implemented and configured.

Even if we ignore NAT, the port may change because the client doesn't
bind the socket to a port, like most clients do and this draft
recommends to do. If someone ran ntpdate in a loop like this

while true; do ntpdate -u $YOUR_SERVER; done

you would want to limit the rate for this address, ignoring the port,
right?

-- 
Miroslav Lichvar

---

From: "Ulrich Windl" <[email-masked]>
Date: Tue, 23 Jun 2020 15:00:42 +0200

>>> Miroslav Lichvar <[email-masked]> schrieb am 23.06.2020 um 13:51 in
> you would want to limit the rate for this address, ignoring the port,

I guess it's like a rotten tree: You start to cut off some leaves, then some
branches, and finally the trunc ;-)

---

From: Hal Murray <[email-masked]>
Date: Tue, 23 Jun 2020 21:30:24 -0700

> Actually, especially because of NAT the port number IS important.

How much traffic is reasonable from a single system?

Does it matter if the server is just a volunteer in the pool or an official 
national service?  (NIST, NPL, PTB, ...)

How many types of systems are there?

If somebody has many systems behind a NAT box, should they setup a couple of 
NTP servers and advertise them via DHCP?  How many is "many"?

-- 
These are my opinions.  I hate spam.

---

From: Harlan Stenn <[email-masked]>
Date: Fri, 26 Jun 2020 17:55:28 -0700

On 6/22/2020 2:39 AM, Miroslav Lichvar wrote:
> ...

My primary concern about this document is that it seems to come from a
specific and limited point of view, and to me its tenor is one of
dictating an over-reaching "policy" instead of providing "mechanism".  I
think the draft should offer information and direction, from a wider
perspective.

Specifically, when I asked a network wizard about why he disagrees with
this proposal he tells me:

> Because on-host is a relatively unusual place for a firewall to be
> run, and most enterprises run firewalls elsewhere, and don't run
> them on-host because it is "so hard".  Enterprises are SO resistant
> to doing this that new technologies such as "microsegemntation" and
> "{smart, artificial intelligent, etc} firewall" that use other
> capabilities, such as a hypervisor's virtual networking subsystem
> (see VMware NSX) to force network security upon a VM.  This has the
> upside of being something that the VM itself cannot modify or drop.
> Unfortunately, it is mostly only for VM's, as a bare metal host
> does not have a virtual netwoork stack sitting on its network
> port anxiously filtering its packets.
>
> In more conventional designs, you will tend to have a dedicated
> firewall at network edge (to your upstream), and/or maybe at the
> router interface/default gateway for a host.
>
> Stateful filtering is mostly a game for software firewalls and
> software routers.  You need to maintain state; the silicon to do
> this is horribly pricey.
>
> However, I can do 10G line rate filtering on a switch with just a
> few commands (8.8.x is just example public IP space):
>
> ip access-list storage1-out
> 1000 permit ip 10.249.2.0 0.0.0.255 any
> ...
> 1190 permit tcp 8.8.64.72 0.0.0.3 eq smtp any
> 1200 permit udp 8.8.64.76 0.0.0.3 eq ntp any
> ...
> 1310 permit icmp any any
> 1320 deny every
> exit
>
> Now this configuration would happen to allow source port
> randomization, because within my network with the source
> "8.8.64.76/30:123" is guaranteed to be the NTP servers, but in a
> less-controlled environment such as where you are using pool,
> you would omit the source IP range and do something like
>
> 1200 permit udp any eq ntp any eq ntp
>
> which permits ntpd to work but doesn't allow scanning of random UDP
> services by an external site using a source port of :123.

and his last sentence carries the kicker.  This proposal effectively
cost-shifts filtering to hosts, and prevents efficient use of filtering
technologies on edge switches.  His line works to offer time service to
others, as allowed packets are only to port 123.  This draft RFC would
require the external firewall to open all incoming udp traffic from port
123, and would require a stateful firewall on all machines receiving
that traffic.

He believes that as currently written, if people implement this by
default they will not be able to block unwanted traffic at the least
expensive place and could easily allow a bad guy to port scan you, if
the bad guy launched his port-scanning from UDP 123.  Therefore as
written, this proposal will *decrease* overall security because of how
it cost-shifts.

---

From: Watson Ladd <[email-masked]>
Date: Fri, 26 Jun 2020 21:47:31 -0400

On Fri, Jun 26, 2020 at 8:55 PM Harlan Stenn <[email-masked]> wrote:
<snip>
> written, this proposal will *decrease* overall security because of how

Your friend shouldn't have services on ephemeral ports, which are the
ones allocated as sources of UDP packets.

Sincerely,
Watson Ladd