Subject: Re: [Tsv-art] [Ntp] Tsvart early review of draft-ietf-ntp-alternative-port-02

From: "[email-masked]" <[email-masked]>
Date: Sat, 4 Dec 2021 18:08:13 -0800

HI, Hal,

Again, with ports team review hat on:

Everything that happened below is equivalent to finding a zero-day or other kind of protocol error in any service.

The fact that the current ’solution’ is to block that port isn’t new either.

We don’t have resources to continually assign ‘fresh’ ports for services and I see no reason this one warrants an exception.

There are other solutions here; if your own recommendations caused packets smaller than 48 to be dropped, then find a way to fragment and reassemble authenticated packets until you find out that larger ones get through.

This is a protocol design problem, not a port assignment problem.

Joe

—
Joe Touch, temporal epistemologist
www.strayalpha.com

> On Dec 4, 2021, at 3:12 PM, Hal Murray <[email-masked]> wrote:
> 
> 
> [email-masked] said:
>> FWIW, I don't see this assignment as appropriate. 
> 
> Without a new port, it will be close to impossible to widely deploy NTP 
> security.
> 
> 
> Years ago (2013), NTP was used in a giant DDoS attack.  That was due to a 
> bug/oversight that had been around since the early NTP work.  (I've tracked it 
> back to 1989.)
>  https://www.spamhaus.org/news/article/695/answers-about-recent-ddos
>  https://en.wikipedia.org/wiki/Denial-of-service_attack#Amplification
> The Wikipedia chart could use another column -- the number of sites available. 
> Almost all Linux or *BSD sites were running ntpd.
> 
> The fix was trivial, but there are many essentially unattended sites running 
> old versions of ntpd that will never get fixed.
> 
> Many many many sites have quietly installed filters in their routers.  Set and 
> forget.
> 
> A typical filter drops UDP traffic to port 123 with a length other than 48.  
> That lets old unauthenticated NTP through but authenticated packets are longer 
> and get dropped.
> 
> To use authentication on the existing port would require removing those 
> filters.  Even if you could track down the right people, they would probably 
> drag their feet until most of the sites running old unattended ntpd were fixed.
> 
> An alternative would be to implement BCP 38.  How long has that been in 
> progress?
> 
> -- 
> These are my opinions.  I hate spam.
> 
> 
>

---

From: Steven Sommars <[email-masked]>
Date: Sat, 4 Dec 2021 23:00:10 -0600

NTP got a bad reputation as an amplification attack vector circa 2014.  The
offending NTP servers have largely been fixed; today few public servers
will blindly amplify the Mode 7/monlist command (the major problem
source).  The organizations doing the filtering aren't receptive to
suggestions that they alter/remove their filtering schemes.

Those finding the alternate port distasteful could help by reaching out to
the organizations doing the filtering and convincing them that changes are
needed.

I don't like the alternative port idea either, but see no other simple
solution.  Short of designing yet another time transfer protocol what would
you suggest?

On Sat, Dec 4, 2021 at 8:08 PM [email-masked] <[email-masked]>
wrote:

> Everything that happened below is equivalent to finding a zero-day or
> other kind of protocol error in any service.
>
> We don’t have resources to continually assign ‘fresh’ ports for services
> and I see no reason this one warrants an exception.
>
> There are other solutions here; if your own recommendations caused packets
> smaller than 48 to be dropped, then find a way to fragment and reassemble
> authenticated packets until you find out that larger ones get through.
>
> _______________________________________________
> ntp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ntp
>

---

From: "[email-masked]" <[email-masked]>
Date: Sat, 4 Dec 2021 22:10:10 -0800

It’s not the rest of the community’s job to make sure your port is useful - it is yours (the NTP community’s). 

I.e., you gave one viable way forward: fix the filtering.
I gave another - find a way around/through the filtering.

Redundant port assignments are not a “simple” solution - they are an expensive one that you should not have not, IMO, earned access to, if for no other reason than “poor stewardship of what you already have”.

Joe

—

> On Dec 4, 2021, at 9:00 PM, Steven Sommars <[email-masked]> wrote:
> 
> NTP got a bad reputation as an amplification attack vector circa 2014.  The offending NTP servers have largely been fixed; today few public servers will blindly amplify the Mode 7/monlist command (the major problem source).  The organizations doing the filtering aren't receptive to suggestions that they alter/remove their filtering schemes.  
> 
> Those finding the alternate port distasteful could help by reaching out to the organizations doing the filtering and convincing them that changes are needed.
> 
> I don't like the alternative port idea either, but see no other simple solution.  Short of designing yet another time transfer protocol what would you suggest?
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> On Sat, Dec 4, 2021 at 8:08 PM [email-masked] <mailto:[email-masked]> <[email-masked] <mailto:[email-masked]>> wrote:
> HI, Hal,
> 
> www.strayalpha.com <http://www.strayalpha.com/>
> 
>> On Dec 4, 2021, at 3:12 PM, Hal Murray <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> 
>> [email-masked] <mailto:[email-masked]> said:
>>  https://www.spamhaus.org/news/article/695/answers-about-recent-ddos <https://www.spamhaus.org/news/article/695/answers-about-recent-ddos>
>>  https://en.wikipedia.org/wiki/Denial-of-service_attack#Amplification <https://en.wikipedia.org/wiki/Denial-of-service_attack#Amplification>
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/ntp <https://www.ietf.org/mailman/listinfo/ntp>
> Tsv-art mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tsv-art

---

From: Danny Mayer <[email-masked]>
Date: Sun, 5 Dec 2021 12:11:22 -0500

> Without a new port, it will be close to impossible to widely deploy NTP
Why would that be? NTP has a port that is widely deployed.
> old versions of ntpd that will never get fixed.

Yes so how is the alternative port going to magically fix this?

> That lets old unauthenticated NTP through but authenticated packets are longer
The same happened with EDNS0. Firewall administrators had to go in and 
adjust their filtering. The same thing needs to  be done for NTP. It's 
EXACTLY what would be needed for an alternate port. You're just adding 
complexity for no real benefit.
> drag their feet until most of the sites running old unattended ntpd were fixed.

They don't need to remove filters as much they need to change them. Are 
you saying that the alternate port would not be filtered?

Dragging feet is the norm. The same happened with EDNS0. This is just 
moving the problem without solving it.

> An alternative would be to implement BCP 38.  How long has that been in
We cannot help people who don't implement best practices. We can only 
point them to the documentation.

Danny

---

From: "C. M. Heard" <[email-masked]>
Date: Sun, 5 Dec 2021 15:20:12 -0800

One the one hand I see:

> Years ago (2013), NTP was used in a giant DDoS attack. That was due to a
bug/oversight
> that had been around since the early NTP work.  (I've tracked it  back to
1989.)
> old versions of ntpd that will never get fixed.

And  on the other hand I see:

On Sat, Dec 4, 2021 at 9:00 PM Steven Sommars wrote:
> NTP got a bad reputation as an amplification attack vector circa 2014.
> The offending NTP servers have largely been fixed; today few public
> servers will blindly amplify the Mode 7/monlist command (the major
> problem source). The organizations doing the filtering aren't receptive
> to suggestions that they alter/remove their filtering schemes.

We have two contradictory assertions by proponents of the alternate port.
Which, if either, is correct?

Are the servers largely fixed but the filters still in place out of
inertia, as Mr. Sommers says?

Or do the filters remain because of servers that have not been fixed, as
Mr. Murray says?

And I have another question, which I though had been asked, but which I now
cannot find:

What assurance is there that the alternate port won't be blocked by default?

Mike Heard

---

From: "Ulrich Windl" <[email-masked]>
Date: Mon, 06 Dec 2021 08:59:34 +0100

>>> Hal Murray <[email-masked]> schrieb am 05.12.2021 um 00:12 in Nachricht
<[email-masked]>:

...
> Many many many sites have quietly installed filters in their routers.  Set 
...

Can any RFC do something against that "set and forget" mentality? I guess not.

> That lets old unauthenticated NTP through but authenticated packets are 

Still no RFC can fix this. Anybody having read the NTPv3/NTPv4 RFCs should know better.

...

Regards,
Ulrich

---

From: Eliot Lear <[email-masked]>
Date: Mon, 6 Dec 2021 11:15:55 +0100

I have a question:

Had neither NTP nor NTS existed, and you were requesting a new port for 
a secure time protocol, would you have designed it identically?

Eliot

---

From: Eliot Lear <[email-masked]>
Date: Thu, 9 Dec 2021 08:51:41 +0100

Hi Joe

On 08.12.21 18:23, [email-masked] wrote:
> Hi, Eliot,
>
> Packets ARE getting to endpoints.
>
> If the issue is that packets of certain *sizes* aren’t getting there, 
> then NTP should find a way around that using the current port. The 
> fact that the existing port is being filtered is on them. Moving to 
> another port simply invites firewall managers to add that number to 
> their current NTP filters.

I'm not sold either way.

Yes, as a rule we do not allocate new ports for existing services.  
There are two reasons for that rule: first, it encourages sloppy design 
of the form ("I'll fix it later") and second and more importantly, we 
simply don't have so many ports to go around.

But this is a fundamental service, and the default behavior for clients 
will simply be to not authenticate.  And that would make NTP an 
attractive nuisance if those port filters are likely to stay.  That's a 
big if.

It is simply not reasonable, however, to require that NTP packets 
comport to a particular size in order to evade a combination of broken 
firewall policies and unbending IANA policies

Miroslav, one question I would like to understand is whether those drops 
involve typical packets used to sync clocks or if those are control 
packets.  In other words, are clocks not syncing because of the drops?

Eliot

---

From: Miroslav Lichvar <[email-masked]>
Date: Thu, 9 Dec 2021 09:26:55 +0100

On Thu, Dec 09, 2021 at 08:51:41AM +0100, Eliot Lear wrote:
> Yes, as a rule we do not allocate new ports for existing services.  There
> are two reasons for that rule: first, it encourages sloppy design of the
> form ("I'll fix it later") and second and more importantly, we simply don't
> have so many ports to go around.

That's fair enough. I wonder if exceptions could be allowed for old
services. It seems the problematic NTP modes were introduced in
RFC1119 from 1989. Could a protocol be pardoned for its mistakes after
30 years?

> It is simply not reasonable, however, to require that NTP packets comport to
> a particular size in order to evade a combination of broken firewall
> policies and unbending IANA policies

I think we could make the most common case of an NTPv4+NTS packet
shorter to get below that length where the observed filtering starts
and add padding to packets that don't fit there. That would make NTS
more reliable (which is what the WG is now most interested in), but it
would not change anything in those cases where NTP is completely
blocked or rate limited.

> packets.  In other words, are clocks not syncing because of the drops?

The intention is to drop the control packets (NTP modes 6 and 7),
which amplify traffic, but it impacts also the time-synchronization
modes (1, 2, 3, 4), which don't amplify traffic (except when Autokey
is enabled, but that is rarely used).

-- 
Miroslav Lichvar