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

From: Steven Sommars <[email-masked]>
Date: Sun, 1 Nov 2020 22:48:17 -0600

The NTP mode 7 monlist command has been used since 2013/2014 for DDoS
attacks.
As a countermeasure UDP port 123 traffic was/is filtered (dropped) on the
Internet by Zayo,
Telia, AT&T, CenturyLink and others.

NTP filtering interferes with NTS and the NTP pool on some paths.

Remote access to the monlist and other mode 6/7 commands has since been
reduced, removed, modified or
administratively disabled on many (probably most) public NTP servers.  I
have not found any current,
specific technical reasons why NTP filtering is still in place.  The ISPs I
contacted gave only vague
references to the monlist issue, if they responded at all.

   Miroslav: NTS doesn't prevent the port from reflecting traffic
Won't NTS simplify mitigation?   I thought crypto overhead would throttle
attacks in software
implementations.

   Ulrich: Rate limiting in case of NTP means "random packet dropping"?
Rate limiting is outside the scope of Miroslav's draft.  So I won't make a
proposal here.

   Miroslav: Is a 1:1 reflection property normally considered to be a
security issue?
I thought UDP reflection attacks were still an issue.   See this 2017
article: https://blog.cloudflare.com/reflections-on-reflections/

Since RFC8915(NTS) has been published and since popular NTP implementations
include NTS support
perhaps ISPs will see increasing end-user dissatisfaction and eliminate or
refine the port 123NTP
filtering.  I doubt it though.  The alternate port seems necessary for
widespread NTS deployment.

Will the Internet treat ALTPORT NTP/NTS nicely, without the type of
filtering seen on port 123?
I don't know.

Steve Sommars

---

From: Harlan Stenn <[email-masked]>
Date: Sun, 1 Nov 2020 22:01:12 -0800

On 11/1/2020 8:48 PM, Steven Sommars wrote:
> As a countermeasure UDP port 123 traffic was/is filtered (dropped) on
> the Internet by Zayo,

mode7 has been disabled by default starting with ntp-4.2.7p230, which
was released on 1 Nov 2011.  If one waited for ntp-4.2.8 to get this
patch, it was released on 19 December 2014.

Even before that, starting with 4.2.7p26, which was released on 24 April
2010, we required a nonce before replying to a monlist request.

These changes were all on the server, not the client, so as soon as one
upgraded a vulnerable server the monlist DDoS attack would be prevented.

I'd like to see real data on the number servers that are on the public
internet that are still vulnerable to this.

> NTP filtering interferes with NTS and the NTP pool on some paths.

I'd like to see real data on this, too.  NTP Pool monitoring can be done
with simple time queries, and does not require larger NTP packets.

> specific technical reasons why NTP filtering is still in place.  The
> ISPs I contacted gave only vague

Fair enough then.

> Won't NTS simplify mitigation?   I thought crypto overhead would
> throttle attacks in software
> implementations.

Any authentication on an NTP packet, be it legacy MAC, NTS, or other
mechanisms will mitigate this.

Crypto overhead means an attacker has to have valid creds before
attacking, right?

H
--
> Rate limiting is outside the scope of Miroslav's draft.  So I won't make
> a proposal here.
> 
> Since RFC8915(NTS) has been published and since popular NTP
> implementations include NTS support
> perhaps ISPs will see increasing end-user dissatisfaction and eliminate
> or refine the port 123NTP
> _______________________________________________
> ntp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ntp
> 

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

---

From: Miroslav Lichvar <[email-masked]>
Date: Mon, 2 Nov 2020 10:50:05 +0100

> patch, it was released on 19 December 2014.

It's good that mode 7 is now disabled by default, but there is still
the mode 6, which allows amplification and is enabled by default. It's
not just a single problematic command. For the attackers, even 2x
amplification could be useful, if they could find anything better at
the moment.

>From few brief exchanges I had with ISPs that block NTP, my impression
is that there is still a large number of devices that respond to mode
6 or mode 7 packets, and if they stopped blocking the port, it would
quickly lead to new attacks. They don't have time to deal with each
user individually.

> mechanisms will mitigate this.

Neither NTS nor legacy MAC prevent reflection. NTS servers could
include the address of the client in the cookie and not respond if the
address doesn't match the real address, but that's not required by the
specification and it would impact migrating clients.

> > article: https://blog.cloudflare.com/reflections-on-reflections/

This article seems to be talking about amplifying reflection attacks,
not 1:1 reflections. Reflection that doesn't amplify the traffic is
not very useful.

-- 
Miroslav Lichvar

---

From: Steven Sommars <[email-masked]>
Date: Mon, 2 Nov 2020 12:49:58 -0600

> internet that are still vulnerable to this.

There is this:
  https://scan.shadowserver.org/ntpmonitor/
  https://scan.shadowserver.org/ntpversion/
There are many servers that give small, unamplified responses.   My guess
is there are several thousand that respond with the nasty monlist
amplification.

> with simple time queries, and does not require larger NTP packets.
Here is some data:

https://weberblog.net/ntp-filtering-delay-blockage-in-the-internet/

http://www.leapsecond.com/ntp/NTP_Suitability_PTTI2020_Revised_Sommars.pdf

NTP Pool monitoring is done with normal mode 3 requests.  I have traced the
NTP packet loss to specific ISPs (they have not responded to my queries).
You can see frustration with "low score" reports at
https://community.ntppool.org/