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

[Mirja Kuehlewind <[e-mail]>]

See inline.

> On 24. Mar 2020, at 14:55, Marcus Dansarie <[e-mail]> wrote:
> 
> 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.

This was only a comment from my review. Yes, it’s editorial but given I overlooked that, it might worth considering to mention it explicitly. However, the editor’s call!

> 
> 
> 
>> 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.

Given you didn’t define what “treated as an error means” I don’t see a difference. If you received an error you can either abort the connection, or you can e.g. log the error and go on knowing that a certain function might not be available. I don’t see what additional value a warning gives you and most other protocols I know are usually fine with only having errors (and no warning). Without further guidance about what warnings should be used for, I’m afraid this function will not be very useful (and it could be added later in needed). However, this is not a problem and again just a comment, you may or may not consider in the final version.

> 
>> 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.

So if you only send the ID 0 and don’t set the critical bit, you may just never get a reply…? Not sure if I can imagine a scenario where that is useful but I guess it’s also not a problem.

> 
> 
>> 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.

Not sure what you mean, the MTU should be a function of the path, no? But maybe I lost track here. All I was proposing is to add a reference to some other RFC to provide more information about the actual limits for IPv4.

Mirja



> 
>