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

[Mirja Kuehlewind <[e-mail]>]

Hi Ragnar,

Sorry it seems I missed you initial reply. Just quickly some replies on my discuss comments. I will have another look tomorrow at the rest. Please see below.

> On 22. Mar 2020, at 17:31, Ragnar Sundblad <[e-mail]> wrote:
> 
> 
> Hello Mirja,
> 
> Thank you again for your work on reviewing the draft.
> Here is an update from the latest draft.
> 
> Best regards,
> Ragnar
> 
> On 19 Mar 2020, at 18:41, Marcus Dansarie <[e-mail]> wrote:
>> Hi Mirja!
>> 
>> Thank you for your work in reviewing the draft. We have carefully gone
>> over all your comments and DISCUSS points. Each of them is addressed below.
>> 
>> Kind regards,
>> Marcus Dansarie
>> 
>> On 2020-03-19 14:10, Mirja Kühlewind via Datatracker wrote:
>>> Mirja Kühlewind has entered the following ballot position for
>>> draft-ietf-ntp-using-nts-for-ntp-24: Discuss
>>> 
>>> When responding, please keep the subject line intact and reply to all
>>> email addresses included in the To and CC lines. (Feel free to cut this
>>> introductory paragraph, however.)
>>> 
>>> 
>>> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
>>> for more information about IESG DISCUSS and COMMENT positions.
>>> 
>>> 
>>> The document, along with other ballot positions, can be found here:
>>> https://datatracker.ietf.org/doc/draft-ietf-ntp-using-nts-for-ntp/
>>> 
>>> 
>>> 
>>> ----------------------------------------------------------------------
>>> DISCUSS:
>>> ----------------------------------------------------------------------
>>> 
>>> Two rather small and hopefully quick-to-address points that I think must be
>>> clarified before publication of this spec:
>>> 
>>> 1) Sec 5.7: "In that
>>>   case, it MUST be able to detect and stop looping between the NTS-KE
>>>   and NTP servers by rate limiting the retries using e.g. exponential
>>>   retry intervals."
>>> Yes, rate limiting and exponential back-off is good here. However, you anyway
>>> need to define a maximum number of retries (to actually make it stop atsome
>>> point) and further given some recommendation for an appropriate rate limit
>>> (e.g. initial retry after 3 seconds...?).
>> 
>> The exact values of this are implementation and application dependent.
>> What would be considered an acceptable value in one application may be
>> unacceptable in another. Furthermore, specifying good and safe values
>> for this would require operational experience that does not currently
>> exist and probably will not exist until NTS has been in use for a long time.
> 
> We have added some more recommendations in the latest version (third
> paragraph from the end in Section 5.7).

I sae that you added a maximum value recommendation. It would better/easier to implement if you provide an initial value and a number of retries. Can you make a proposal for that?

> 
>>> 2) Sec 4.1.3: "      Error code 2 means "Internal Server Error".  The server MUST
>>>      respond with this error if it is unable to respond properly due to
>>>      an internal condition."
>>> At least for this error, I think you need to specify what the client should do
>>> on reception. Retry? Immediately? How often? Or wait for a while?
>> 
>> Same reply as above.

Similar as above it’s important to be more specific to avoid a situation where a “stupid” implementation just retries immediately and does that forever. The specification is incomplete if you don’t say anything here. Please add a recommendation!

Mirja


>> 
>>> ----------------------------------------------------------------------
>>> 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.
>> 
>>> A couple more small questions:
>>> 1) Sec 4.1.3:
>>> "The Critical Bit MUST be set."
>>> If you set the Critical Bit for error records, that would only mean that a
>>> receiver could send another error in response to that error which again has the
>>> critical bit set which then could cause another error, and it would go on
>>> forever. Yes, this case should never happen as all its-ke implementations must
>>> support error records but maybe it's safer to just not set the critical bit?
>> 
>> An error record loop between client and server is impossible in NTS-KE
>> for two reasons: First, error records are only allowed to be sent from
>> server to client. Second, client and server only send a single request
>> or response per NTS-KE session, see the first paragraph of Section 4.
>> 
>>> 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.
>> 
>>> 3) Sec 4.1.5: "   If the NTS Next Protocol Negotiation record offers Protocol
>>> ID 0 (for
>>>   NTPv4), then this record MUST be included exactly once. "
>>> In this case, I guess the critical bit should/MUST be also set to 1?
>> 
>> The reason for why the AEAD Algorithm Negotiation critical bit MAY be
>> set, instead of SHOULD/MUST, is to ensure compatibility with future
>> protocols which use NTS-KE, but not the AEAD Algorithm Negotiation record.
>> 
>> As an example, consider a hypothetical future Hyper Rocket Toaster Time
>> Transfer Protocol (HRTTTP) which uses NTS-KE, but utilizes some
>> different (and currently undefined records). A client that performs a
>> handshake with an NTS-KE server which only supports HRTTTP may send
>> multiple protocol IDs in the NTS Next Protocol Negotiation record. If
>> the client, for example, sends protocol ID 0 (NTPv4) and the protocol ID
>> for HRTTTP, it must include the required other records for both
>> protocols. If the client sets the Critical Bit of the AEAD Algorithm
>> Negotiation record in this case, the server MUST respond with error code
>> 0 and the negotiation will fail, even though it is semantically correct
>> and it would have been entirely possible for the server to successfully
>> respond with HRTTTP cookies.
>> 
>>> 4) Sec 5.7:
>>> "1280 octets is
>>>   the minimum prescribed MTU for IPv6 and is in practice also safe for
>>>   avoiding IPv4 fragmentation.  Nonetheless, senders SHOULD include
>>>   fewer cookies and placeholders than otherwise indicated if doing so
>>>   is necessary to prevent fragmentation."
>>> RFC8085 says "For IPv4, EMTU_S is the smaller of 576 bytes and the
>>>   first-hop MTU [RFC1122]."
>>> Maybe it would be appropriate to note that.
>> 
>> This issue was brought up by Suresh in his AD review. We then elected to
>> keep the current text as is, since it refers to the general case, rather
>> than the strict requirements of RFC 1122.
> 
>