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

["C. M. Heard" <[e-mail]>]

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 <[e-mail]> wrote:

> 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, [e-mail] wrote:
>
> 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 <
> [e-mail]> wrote:
>
> 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
>
>
> _______________________________________________
> Tsv-art mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tsv-art
>
>
>
> _______________________________________________
> ntp mailing [e-mail]://www.ietf.org/mailman/listinfo/ntp
>
>