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

[Erik Kline <[e-mail]>]

On Fri, 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
>
>
>
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