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

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 <noreply@ietf.org> 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
> Tsv-art@ietf.org
> https://www.ietf.org/mailman/listinfo/tsv-art