[Tsv-art] Tsvart early review of draft-ietf-ntp-alternative-port-02

[Magnus Westerlund via Datatracker <[e-mail]>]

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