Subject: [tsvwg] Tsvart early review of draft-ietf-ntp-alternative-port-02

From: Magnus Westerlund via Datatracker <[email-masked]>
Date: Fri, 03 Dec 2021 02:55:08 -0800

Reviewer: Magnus Westerlund
Review result: Ready with Issues

As TSVART reviewer I have included two additional mailing lists for this review
response, sorry for the cross posting but I think it is relevant to get more
opinions on this. The port experts, although they are not responsible for
system port assignments per RFC 6335. TSVWG is included as it is the WG that
have been responsible for developing the documents in BCP 165 and these rules.

The main question here is if this particular case warrants an exception in
regards to the principals documented by RFC 6335 and RFC 7605 (Together BCP
165)?

So this document wants an alternative port that is to be used with a subset of
NTPv4 that is deemed to be more operational safe and which has an packet
response amplification factor below 1, i.e. for each request, one and only one
response is generated and that packet is not larger than the request. For more
details see (it is a very short document):
https://datatracker.ietf.org/doc/draft-ietf-ntp-alternative-port/

So in regards to the basic principals this should be rejected as it is simply
an alternative. However, I think this one might be a case where the exception
is motivated. The service here is not identical and it has improved security
properties, especially in regards to how network intermediaries may interpret
the traffic. Where one might want to filter and/or block port 123 due to its
potential for DDoS with a reduced risk the alternative port would imply I think
this gets into the case which Section 7.1 of RFC 7605 discusses:

   o  Separate assigned port numbers are not intended for insecure
      versions of existing (or new) secure services.  A service that
      already requires security would be made more vulnerable by having
      the same capability accessible without security.

      Note that the converse is different, i.e., it can be useful to
      create a new, secure service that replicates an existing insecure
      service on a new port number assignment.  This can be necessary
      when the existing service is not backward-compatible with security
      enhancements, such as the use of TLS [RFC5246] or DTLS [RFC6347].

The important difference here is that although this is not an endpoint
incompatibility issue, it is an interpretation difference by the network itself.

So personally I would argue for this exception to the basic principles.
However, this is in the end going to be an IETF consensus decision if we allow
it or not. Thus, I think discussing any views now, and allow a bit more time
for discussion and also addressing any issue prior to IETF last call would be
good.

I also would like to ask the NTP experts if they really need a system port?
>From my perspective an NTP server should not need to run with increased
privileges on the host. The main purpose of NTP is after all to server the
requester an answer based on its access to a clock that is believed to provide
accurate time. So, could you please improve the motivation why "ntp-alt"
actually needs a system port. Even if NTP as a service when originally was
given port 123 a system ports it might have been considered a system services I
do wonder if that assessment still stands. I would note that this motivation is
required for any application for assigning a systems port.

 Cheers

Magnus Westerlund

---

From: "[email-masked]" <[email-masked]>
Date: Fri, 3 Dec 2021 09:54:17 -0800

FWIW, I don’t see this assignment as appropriate.

Speaking as a ports review team member, it opens the floodgates to “one more port for a more secure/safe version of X”, for all X. 

I see no reason why NTP should be an exception; EVERY service benefits from being more secure and safe. If you want a safe NTP port, run safe NTP on that port. That goes for all services.

Note that if a port is assigned by the IESG, IMO it should not be a system port, for the reasons stated in RFC7605, ESPECIALLY if this is about safety and security.

Joe
—
Joe Touch, temporal epistemologist
www.strayalpha.com

> On Dec 3, 2021, at 2:55 AM, Magnus Westerlund via Datatracker <[email-masked]> wrote:
> 
> _______________________________________________
> Tsv-art mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tsv-art

---

From: Danny Mayer <[email-masked]>
Date: Sat, 4 Dec 2021 15:04:47 -0500

I agree with you. I have already objected to this draft being accepted 
because of this and a few other reasons.

The underlying issue that prompted this was that servers were allowing 
NTP mode 6 and 7 packets to be responded to, leading to amplification 
DDOS attacks. To implement this draft requires that code needs to be 
added to the NTP servers to support this and then get admins to use it. 
Instead of which they could just turn off accepting mode 6 and 7 
packets. Disabling this is simple. In the NTP reference implementation 
this already exists as the noquery option in the configuration file. I 
cannot say what other implementations support but they can certainly 
change their code to do so. Since this can be done directly the draft is 
not needed.

Danny

On 12/3/21 12:54 PM, [email-masked] wrote:
> Speaking as a ports review team member, it opens the floodgates to 
> “one more port for a more secure/safe version of X”, for all X.
>
> I see no reason why NTP should be an exception; EVERY service benefits 
> from being more secure and safe. If you want a safe NTP port, run safe 
> NTP on that port. That goes for all services.
>
> Note that if a port is assigned by the IESG, IMO it should not be a 
> system port, for the reasons stated in RFC7605, ESPECIALLY if this is 
> about safety and security.
>
> Joe
> —
> www.strayalpha.com <http://www.strayalpha.com>
>
> ntp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ntp

---

From: "C. M. Heard" <[email-masked]>
Date: Sat, 4 Dec 2021 17:30:22 -0800

I read the document, and as a previously uninvolved member of the IETF
community, I am unconvinced that an alternative port for NTP is a good idea.

The purpose for an alternative port is to provide a workaround for
third-party filtering of port 123. That filtering in turn is motivated by
some NTP server installations not following BCP 223 / RFC 8633 with respect
to NTP mode 6 and mode 7 packets. Danny Mayer makes a very convincing case
that it would take much less effort to modify the errant server
installations to follow BCP 223 (which may only require configuration
changes) than to implement the alternative port on both servers and
clients. IMO the only way that the latter could be justified would be if
the filtering of port 123 is pervasive with little hope of correction once
errant servers are fixed. The draft in its present form does not make that
case.

Mike Heard

On Sat, Dec 4, 2021 at 12:05 PM Danny Mayer <[email-masked]> wrote:

> The underlying issue that prompted this was that servers were allowing NTP
> mode 6 and 7 packets to be responded to, leading to amplification DDOS
> attacks. To implement this draft requires that code needs to be added to
> the NTP servers to support this and then get admins to use it. Instead of
> which they could just turn off accepting mode 6 and 7 packets. Disabling
> this is simple. In the NTP reference implementation this already exists as
> the noquery option in the configuration file. I cannot say what other
> implementations support but they can certainly change their code to do so.
> Since this can be done directly the draft is not needed.
>
> Danny
> Speaking as a ports review team member, it opens the floodgates to “one
> more port for a more secure/safe version of X”, for all X.
>
> from being more secure and safe. If you want a safe NTP port, run safe NTP
> on that port. That goes for all services.
>
> Note that if a port is assigned by the IESG, IMO it should not be a system
> port, for the reasons stated in RFC7605, ESPECIALLY if this is about safety
> and security.
>
> Joe
> —
> ntp mailing [email-masked]://www.ietf.org/mailman/listinfo/ntp
>
>

---

From: Erik Kline <[email-masked]>
Date: Sun, 5 Dec 2021 15:45:04 -0800

> required for any application for assigning a systems port.
Magnus,

Thank you very much for the review and expanding this conversation (I think
it might also serve as good philosophical input to NTPv5 requirements).

-Erik

---

From: "[email-masked]" <[email-masked]>
Date: Mon, 6 Dec 2021 21:24:13 -0800

See below...
—

> On Dec 3, 2021, at 2:55 AM, Magnus Westerlund via Datatracker via IANA-Port-Experts <[email-masked]> wrote:
> 
> ...However, I think this one might be a case where the exception

I disagree; this is not a function of all networks, but rather of a network deliberately configured in regard to NTP in ways NOT specified by the protocol.

I.e., it is, in essence, a deliberate misconfiguration.

Speaking as author of 7605, the above case was intended only for cases where the *protocol spec* was not compatible with in-band negotiation of security. 

In the case here, NTP already supports in-band security negotiation - it is a non-protocol network configuration that is getting in the way. Using another port is a lazy (and unwarranted) way to resolve that problem.

Joe

---

From: "Salz, Rich" <[email-masked]>
Date: Tue, 7 Dec 2021 18:57:45 +0000

*   In the case here, NTP already supports in-band security negotiation - it is a non-protocol network configuration that is getting in the way. Using another port is a lazy (and unwarranted) way to resolve that problem.

I find this point of view compelling.  It’s a good example of an small focused group not necessarily seeing the larger picture.

---

From: Joe Touch <[email-masked]>
Date: Tue, 7 Dec 2021 11:41:23 -0800

Then please Help us understand a bigger picture that doesn’t end with endless “new port-to-fix-bad-deployments” assignments.

That’s the bigger picture here. 

Joe

> On Dec 7, 2021, at 10:58 AM, Salz, Rich <[email-masked]> wrote:
> 
>

---

From: "Salz, Rich" <[email-masked]>
Date: Tue, 7 Dec 2021 19:51:36 +0000

*   Then please Help us understand a bigger picture that doesn’t end with endless “new port-to-fix-bad-deployments” assignments.

  *   That’s the bigger picture here.

Sorry, I wasn’t clear.  I agree with you.  The NTP WG thought “let’s just get a new port”  And when it went to port review, you folks rightly raised valid concerns and issues with that approach.