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

From: [email-masked]
Date: Mon, 12 Oct 2020 07:59:12 -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           : Alternative NTP port
        Author          : Miroslav Lichvar
	Filename        : draft-ietf-ntp-alternative-port-00.txt
	Pages           : 6
	Date            : 2020-10-12

Abstract:
   This document updates RFC 5905 to specify an alternative port for the
   Network Time Protocol (NTP) which is restricted to NTP messages that
   do not allow traffic amplification in order to make NTP safe for the
   Internet.

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

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-ntp-alternative-port-00
https://datatracker.ietf.org/doc/html/draft-ietf-ntp-alternative-port-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: Steven Sommars <[email-masked]>
Date: Sat, 24 Oct 2020 11:40:56 -0500

My comments on

This draft is important since eliminating UDP port 123 filtering is
unlikely.   The parties responsible for NTP filtering seem reluctant to
even discuss the subject; I've tried.

This note provides some NTP filtering field experience:
https://weberblog.net/ntp-filtering-delay-blockage-in-the-internet/

(comment) The ALTPORT could be used for NTS only (my preference). However I
don't object to ALTPORT being used for both NTS and RFC5905 as described in
this draft.

Abstract:  "in order to make NTP safe for the Internet."
NTP behavior is improved, but since it is UDP based there is still
opportunity for abuse.

Section 1.  "Over time, network operators have been observed to implement
the following mitigations"
- The mitigations are undocumented, path/operator dependent and may change
over time.
- (comment) On some paths I've observed NTP-specific delay.  This may be a
side effect of rate limiting.

Section 1. "The number of public servers in the pool.ntp.org project has
dropped  in large part due to the mitigations (citation?)."
I am unaware of a good citation.  Several threads in
https://community.ntppool.org/ describe problems with NTP Pool monitoring,
i.e., unexpected low monitoring scores.
Some incidents resulted in machines being temporarily or permanently
removed from the NTP pool.
I doubt there is data to back up the "in large part" comment.

Section 2.
  "The client SHOULD be switching between the two ports until a valid
response is received."
to
   The client SHOULD alternate between the two ports until a valid response
is received.

Are there any issues with an NTP server keeping state information for both
clients at both (IP, port 123) and (IP,ALTPORT)?
E.g., Client sends queries on the two ports, server receives both.  Does
the server consider these to be two clients or one?

Steve Sommars

---

From: Miroslav Lichvar <[email-masked]>
Date: Mon, 26 Oct 2020 18:36:37 +0100

> don't object to ALTPORT being used for both NTS and RFC5905 as described in

As the problems with blocking and rate-limiting are not specific to
NTS-protected NTP packets, I think it would be nice to provide a
workaround for all servers and clients, not just those that are using
NTS. I don't think we can expect NTS to be instantly adopted
everywhere.

> NTP behavior is improved, but since it is UDP based there is still

Do you suggest to reword the abstract to mention only that it makes
NTP amplification-free?

> - The mitigations are undocumented, path/operator dependent and may change

Ok. I'll try to improve that section.

> I doubt there is data to back up the "in large part" comment.

Maybe we could at least say that the number of servers dropped due to
the attacks, no matter why exactly were the servers removed? The graph
at this page clearly shows when it started:

https://www.ntppool.org/zone

>    The client SHOULD alternate between the two ports until a valid response

Ok.

> clients at both (IP, port 123) and (IP,ALTPORT)?

I suspect it would be an unnecessary complication wasting memory.

> the server consider these to be two clients or one?

I think it should still count as one address, which can have multiple
clients. Servers usually don't care about the client's port, so I
don't see a reason why they would want to care about the server's
port. Before the server port, it would make more sense to consider the
server address on multihomed hosts. The server port should just limit
the responses to those that don't cause amplification.

Thanks,

-- 
Miroslav Lichvar

---

From: Steven Sommars <[email-masked]>
Date: Tue, 27 Oct 2020 15:18:16 -0500

As the problems with blocking and rate-limiting are not specific to
NTS-protected NTP packets, I think it would be nice to provide a
workaround for all servers and clients, not just those that are using
NTS. I don't think we can expect NTS to be instantly adopted everywhere.

Should blocking and rate limiting considerations be added to the NTP
specifications?  If so where?
Some hardware-based (e.g., FPGA) NTP implementations can handle 10Gbps of
traffic, yet lack rate limiting mechanism.

The immediate effect of the alternate port is to bypass the current NTP
filtering that can break NTS and that is currently causing problems for the
NTP pool.
I'm concerned that adding NTP(RFC5905) to ALTPORT may lead to ISP filtering
of those UDP packets as well.

Do you suggest to reword the abstract to mention only that it makes NTP
amplification-free?

That's the most it can do since with the current draft reflection attacks
are still possible.
[Using  ALTPORT=NTS-only would prevent reflection attacks.]

That's probably the best available reference.  For NTP WG email history
here are two consequences of excessive NTP drops of the NTP Pool monitoring
system probe packets.
1) Servers are deemed unreachable/poorly reachable and are temporarily
removed from the NTP Pool
2) The volunteers offering their hosts as NTP Pool servers receive many
email notifications of poor reachability and eventually drop out of the NTP
Pool.

---

From: Miroslav Lichvar <[email-masked]>
Date: Thu, 29 Oct 2020 14:28:03 +0100

> specifications?  If so where?

I wouldn't think so. Do other UDP-based protocols have this?

> of those UDP packets as well.

If they did that, why wouldn't they do that if the port was limited to
NTP packets using NTS?

NTS doesn't prevent the port from reflecting traffic. An FPGA
implementation (like Netnod is using) can still generate gigabits of
traffic. With classic software implementations, whose performance is
normally limited by the system's networking stack, NTS actually
increases the maximum traffic the server can generate as the packets
can be much longer. In a quick test with a server which can reflect
about 250 Mbit/s of plain NTP, it can reflect more than 850 Mbit/s of
NTS-enabled NTP.

> That's the most it can do since with the current draft reflection attacks

Is a 1:1 reflection property normally considered to be a security
issue? Any real-world examples of it being exploited? There are many
other protocols that have that, e.g. ICMP ECHO which is enabled almost
everywhere.

> [Using  ALTPORT=NTS-only would prevent reflection attacks.]

How exactly?

> That's probably the best available reference. 

Ok. Does anyone have a link that would show and maybe also describe
a snapshot of the graph? The Internet archive has this page, but it
doesn't show the graph. It just says "Error downloading graph data".

-- 
Miroslav Lichvar

---

From: "Ulrich Windl" <[email-masked]>
Date: Fri, 30 Oct 2020 08:14:53 +0100

>>> Steven Sommars <[email-masked]> schrieb am 27.10.2020 um 21:18 in
Nachricht
> specifications?  If so where?

Hi!

Rate limiting in case of NTP means "random packet dropping"? In case of UDP this can happen any time, but I think past design philosophy was that the endpoint does not randomly drop packets without warning (KoD codes). So what exactly is the proposal?

Regards,
Ulrich