Re: [Ntp] Mirja Kühlewind's Discuss on draft-ietf-ntp-using-nts-for-ntp-24: (with DISCUSS and COMMENT)

[Marcus Dansarie <[e-mail]>]

Hi Mirja,

See responses inline.

Kind regards,
Marcus Dansarie

On 2020-03-24 13:45, Mirja Kuehlewind wrote:>>>>
----------------------------------------------------------------------
>>>> COMMENT:
>>>> ----------------------------------------------------------------------
>>>>
>>>> In addition to Ben's discuss point on ports which I would also like to see the
>>>> answer to, one more question: My understanding is that the TCP port (123) for
>>>> NTP is not used and will likely never be used in future. Why are you not using
>>>> that port for NTS-KE, as NTS-KE is using TCP?
>>>
>>> As Harlan's reply to this comment indicates, there is WG consensus that
>>> NTS-KE should not use the TCP port reserved for NTP. It should also be
>>> noted that NTS-KE is not a protocol exclusively meant for NTP.
> 
> I leave this decision to the wg but from the mails that I saw recently it doesn’t seem to be clear that there is a better/another use for the already reserved port. Please consider that adequately. 


The WG reached rough consensus to use a different port for NTS-KE a
while ago and revisiting that issue now will require restarting a quite
long and hard debate. Furthermore, I think the argument that NTS-KE is a
general key establishment protocol, rather than an extension to NTP, is
valid.


> Okay, I missed that errors can only be sent from the server to the client. Would probably be good to state that again explicitly in section 4.1.3. 

This is mostly a style issue. As authors, we have to weigh referencing
relevant information at other places in the document against general
readability. With the section on "Retry Intervals" in the same section
as the definition of the error record, I don't think this is necessary.



> However, I still don’t really understand why the critical bit should be set for errors. I think if you set the critical bit for errors you must also specify the reaction better that a client should perform based on reception of an error message. However, as the error type is part of the base spec that must be implemented, its probably doesn’t matter that much...

Indeed, the critical bit really doesn't matter very much for records
defined in the base spec. The semantic of the critical bit is that it
only says what an implementation which doesn't recognize the record type
should do: If it is not set, the implementation MUST ignore it. If it is
set, the implementation MUST treat is as an error. Servers then respond
with error code 0 ("Unrecognized Critical Record").


>>>> 2) Sec 4.1.4: I don't really understand the idea of the Warning record. There
>>>> are no code points defined and there is no explanation given what this could be
>>>> used for. Especially what should a client do that received a warning? Why is
>>>> the error record not sufficient?
>>>
>>> According to Section 4.1.4, a client which receives a warning code it
>>> does not recognize MUST treat it as an error. The warning record type is
>>> envisaged for future applications and experimental use. By creating a
>>> "Network Time Security Warning Codes" registry, adding warning codes as
>>> needed in the future is significantly simplified.
> 
> Still, why can’t you not just use an error instead?

Warning codes enable the server to convey information (warnings) to the
clients without it being treated as an error. Currently, with no error
codes defined, all warnings would be interpreted as errors. With warning
codes defined, or in experimental implementations, this will not be the
case.

> It understood that it’s a MAY in the general case. However, my point was rather that in case the ID is set to 0, the critical bit MUST be set, no? Can you please specify which value the critical bit has to have _when_ the ID is set to 0!

This is what I was trying to convey with my example: The "NTS Next
Protocol Negotiation" does not contain a single ID, but a sequence of
IDs. A client can include, for example, IDs 0, 1, 2, and 3 in that
record. It would then have to send any other records that are needed for
the negotiation of those next protocols. For ID 0, this would include
the "AEAD Algorithm Negotiation" record. In this case, setting the
critical bit could force the server to return the "Unrecognized Critical
Record", if it does not support protocol ID 0. In other cases (such as
when only sending ID 0), setting the critical bit could be advantageous.
It is really on an application-to-application basis, which is why the
draft says MAY.


> It’s fine to not restrict this but I’m requesting to at least note that there could be cases where this does not apply!

Those cases are when using IPv4 over low-MTU paths, which is exactly
what we are saying. The exact MTU when this happens is not possible to
state, since the cookie format is implementation dependent.