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

[Danny Mayer <[e-mail]>]

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 <http://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 list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ntp