Subject: [Ntp] Alternative NTP port

From: Miroslav Lichvar <[email-masked]>
Date: Mon, 6 Apr 2020 14:07:05 +0200

I submitted a draft for the alternative NTP port. It is meant to be a
workaround for rate limiting and blocking of NTP packets which was
implemented in some networks as a mitigation for amplification
attacks.

https://datatracker.ietf.org/doc/draft-mlichvar-ntp-alternative-port/

Comments and suggestions are welcome.

-- 
Miroslav Lichvar

---

From: Ragnar Sundblad <[email-masked]>
Date: Mon, 6 Apr 2020 19:08:15 +0200

Hi Miroslav,

Thanks for your work!
( I had started to write one too. :-) )

I agree to what Daniel said on the WG meeting today, that the most
important aspect of this port should be that it can not be used for
traffic amplification.
I think that is the right way to get back some trust from the ISP:s.

Also, it should allow for newer versions of NTP, and they may not
have the “mode” field at all. I still think the “mode” paragraph
is good as an explanation for NTP version 1-4 though.

I also want to raise the idea to add that implementations that allows
for use of this port must make sure that they can not amplify
traffic, even if they would be badly configured.
The reason would again be to gain trust from the ISP:s.

Best,

Ragnar

> On 6 Apr 2020, at 14:07, Miroslav Lichvar <[email-masked]> wrote:
> 
> _______________________________________________
> ntp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ntp

---

From: Miroslav Lichvar <[email-masked]>
Date: Tue, 7 Apr 2020 09:04:58 +0200

> I think that is the right way to get back some trust from the ISP:s.

Yes, that makes perfect sense. I didn't realize Autokey allowed
traffic amplification and other extension fields may also be
problematic.

> is good as an explanation for NTP version 1-4 though.

Good idea.

> The reason would again be to gain trust from the ISP:s.

Hardcoding the behavior would be good. I suspect a bigger issue might
be with admins of machines with old NTP software that could make a
quick "fix" to support the new port by adding a redirect in their
firewall.

Thanks,

-- 
Miroslav Lichvar

---

From: "Dieter Sibold" <[email-masked]>
Date: Tue, 07 Apr 2020 19:34:09 +0200

I also would like to ask to consider Daniel’s suggestion to adopt the 
NTS-KE for port negotiation. This would allow for a clean approach.

Dieter

---

From: Miroslav Lichvar <[email-masked]>
Date: Wed, 8 Apr 2020 14:01:30 +0200

On Tue, Apr 07, 2020 at 07:34:09PM +0200, Dieter Sibold wrote:
> I also would like to ask to consider Daniel’s suggestion to adopt the NTS-KE
> for port negotiation. This would allow for a clean approach.

Meaning only clients that support TLS and NTS-KE can use the
alternative port? The draft currently says NTS servers should use the
Port Negotiation record with the alternative port.

I think non-NTS clients should be able to use it too. The question is
if they should start with the alternative port, or only try it when
they don't get a response from the original port.

All four combinations of the two ports working and not working are
possible. The original port is blocked or rate-limited by ISPs. The
alternative port would likely be blocked in local/corporate networks
where UDP ports are whitelisted. 

-- 
Miroslav Lichvar