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

From: Mirja Kühlewind via Datatracker <[email-masked]>
Date: Thu, 19 Mar 2020 06:10:13 -0700

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 at some
point) and further given some recommendation for an appropriate rate limit
(e.g. initial retry after 3 seconds...?).

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?

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

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?

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?

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?

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.

---

From: Harlan Stenn <[email-masked]>
Date: Thu, 19 Mar 2020 06:23:09 -0700

> https://datatracker.ietf.org/doc/draft-ietf-ntp-using-nts-for-ntp/

The NTP Project has sent its plans for TCP/123 to the working group, to
be used by "NTP TCP Services".  We intend this to be used for a variety
of NTP-related TCP services.  That is a work in progress.  Otherwise,
the NTP Project remains strongly opposed to using TCP/123 for NTS-KE
because of <good reasons we have stated before to the WG, and I want to
save everybody the drama so I won't go in to them now>.

H
--

> _______________________________________________
> ntp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ntp
> 

-- 
Harlan Stenn <[email-masked]>
http://networktimefoundation.org - be a member!

---

From: Mirja Kuehlewind <[email-masked]>
Date: Thu, 19 Mar 2020 14:24:45 +0100

Okay, thanks for the info!

> On 19. Mar 2020, at 14:23, Harlan Stenn <[email-masked]> wrote:
> 
> 
>

---

From: Marcus Dansarie <[email-masked]>
Date: Thu, 19 Mar 2020 18:41:10 +0100

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

> https://datatracker.ietf.org/doc/draft-ietf-ntp-using-nts-for-ntp/

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.

> on reception. Retry? Immediately? How often? Or wait for a while?

Same reply as above.

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.

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

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

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

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

---

From: Hal Murray <[email-masked]>
Date: Thu, 19 Mar 2020 21:47:43 -0700

[email-masked] said:
> The NTP Project has sent its plans for TCP/123 to the working group, to be
> used by "NTP TCP Services".  We intend this to be used for a variety of
> NTP-related TCP services.  That is a work in progress.  Otherwise, the NTP
> Project remains strongly opposed to using TCP/123 for NTS-KE because of <good
> reasons we have stated before to the WG, and I want to save everybody the
> drama so I won't go in to them now>. 

Your "good reasons" would carry more weight in my view if you would provide a 
reference to your ideas.

Google found 2 drafts from 2018.  The total useful content was 2 paragraphs 
with few details.  Maybe I didn't search for the right thing.  The first said 
TCP and STARTTLS.  The second said key exchange.  In my opinion, both have 
been superseded by NTS-KE.

Are there other ideas I didn't find?

I think it would be a good idea to move ntpq operations to a secure channel.  
NTS-KE uses ALPN.  Is there any reason not to take advantage of ALPN so we can 
share port 123 with future ideas?

-- 
These are my opinions.  I hate spam.

---

From: Harlan Stenn <[email-masked]>
Date: Thu, 19 Mar 2020 22:06:58 -0700

> Your "good reasons" would carry more weight in my view if you would provide a 

Hal, I'm pretty sure you at least virtually attended the meetings where
this was discussed.

I've also posted various emails about it.

> share port 123 with future ideas?

Please look at what I have said before.

---

From: "Ulrich Windl" <[email-masked]>
Date: Fri, 20 Mar 2020 08:13:10 +0100

Hi Harlan,

it's obvious that you want to keep port 123/TCP reserved for NTP. However
there were no projects in the last 20 years that would have wanted that port.
Aslo Dave Mills once said NTP over TCP does not make sense at all, and the
whole protocol design is incompatible with it. So at best the stil-to-be-done
NTP v5 could use that port.

Sorry I did not attend the meetings you are referring to, but still from time
to time you could repeat the facts instead of referring to them.

Regards,
Ulrich

>>> Harlan Stenn <[email-masked]> schrieb am 20.03.2020 um 06:06 in
Nachricht
<31041_1584680845_5E744F8D_31041_97_1_ced12651-75fb-d5ee-3ea6-95a1e1a6aaaf@nwtim

>>> The NTP Project has sent its plans for TCP/123 to the working group, to
be
>>> NTP‑related TCP services.  That is a work in progress.  Otherwise, the
NTP
>>> Project remains strongly opposed to using TCP/123 for NTS‑KE because of
<good
>> Your "good reasons" would carry more weight in my view if you would provide

> a 

>> been superseded by NTS‑KE.
>> 
>> NTS‑KE uses ALPN.  Is there any reason not to take advantage of ALPN so we

> can 
> ‑‑ 
> http://networktimefoundation.org ‑ be a member!
>

---

From: Harlan Stenn <[email-masked]>
Date: Fri, 20 Mar 2020 00:33:54 -0700

Hi Ulrich,

> there were no projects in the last 20 years that would have wanted that port.

Not true.  I put forth proposals almost 2 years ago, and the WG refused
to collaborate or consider them.

> NTP v5 could use that port.

Dave was right.  Nobody is going to be using TCP for time transport.

It is *very* useful for other purposes related to issue around "time
transport" and that what my proposal set out to enable.  NTS-KE is not that.

We will implement and document what we propose soon.

> to time you could repeat the facts instead of referring to them.

I think my efforts are much better spent making forward progress in our
current NTP-related affairs.

H

---

From: "Salz, Rich" <[email-masked]>
Date: Fri, 20 Mar 2020 13:29:46 +0000

Perhaps "did not want to work on them" might be a less emotionally-charged way to say it.  But I understand your frustration as you have been working on network time for a very long time.  (Believe me, I can relate -- wanna hear about my arguments with OpenSSL? :)

Because the WG hasn’t been interested, and because the WG really "owns" the port, its semantics, and the associated registries, you might need to find another way to convince the WG. One possibility might be to carve out a "private" numbering space and -- this is the key, I think, compared to previous efforts -- *not* try to take whole classes of numbering.  Go for it onesie-twosie as you've documented and/or implemented things.

>    We will implement and document what we propose soon.
  
Great.  Until then, there's nothing for the WG to do, right?  And you can't carve off large portions of "land" if the WG has already expressed lack of interest.

As for sharing 123/TCP with NTS-KE, your protocols can use TLS ALPN just like NTS-KE is doing.  The requirement to get an ALPN identifier is low: an internet-draft (even if individual) suffices. If you're doing plaintext over 123/TCP on the public Internet, then please think again.
 
	/r$

---

From: Ragnar Sundblad <[email-masked]>
Date: Sun, 22 Mar 2020 17:31:23 +0100

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 <[email-masked]> wrote:
> > need to define a maximum number of retries (to actually make it stop atsome

We have added some more recommendations in the latest version (third
paragraph from the end in Section 5.7).

> > 2) Sec 4.1.3: "      Error code 2 means "Internal Server Error".  The server MUST

---

From: Mirja Kuehlewind <[email-masked]>
Date: Sun, 22 Mar 2020 19:16:12 +0100

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 <[email-masked]> wrote:
> 
> 
> Hello Mirja,
> 

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?

>>> on reception. Retry? Immediately? How often? Or wait for a while?

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

---

From: Watson Ladd <[email-masked]>
Date: Sun, 22 Mar 2020 11:22:29 -0700

As the person responsible for the existence of Error Code 2 let me
suggest exponential randomized fallback starting at seconds until a
maximum of 1 hour.

---

From: Ragnar Sundblad <[email-masked]>
Date: Sun, 22 Mar 2020 20:33:45 +0100

Hi Mirja,

> On 22 Mar 2020, at 19:16, Mirja Kuehlewind <[email-masked]> wrote:
> 
> Hi Ragnar,
> 

Yes, and we still recommend exponential backoff.
We also changed “stop looping” to “avoid quickly looping”.

We believe that this is highly application dependent, and that
operational experience is needed.
It depends on the cost of communication (battery or other limited
resources), the importance of having reliable time, and probably a
number of other factors.
The requirements and reasonable values are extremely different
for for example:
- A desktop computer
- A cat tag with occasional e.g. zigbee connection
- A microwave oven with e.g. zigbee connection
- Anything with e.g. a slotted long range radio, with a few small every
now and then
- A financial transaction broker system
- An anti-missile missile

We just don’t know for sure what to recommend and for what, more than
that in many applications some exponential backoff is probably a good
thing, and similarly that in many applications (but probably not all!),
it is good if the client never actually gives up, sooner or later the
server may become reachable again.

We are absolutely open for good ideas, but if we are going to put them
in the specification, we do not want to guess more than absolutely
necessary.

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

Again, this is dependant on the application. In some applications
it should likely retry, in others not. The implementor is in a much
better position to understand the environment the server or client
is going to work in, and a knowledgeable user is probably the best.

And again, we are open to ideas, but really want to avoid guessing.

I don’t agree that the specification is not complete without this,
I have seen many protocol specifications without any such information,
and they seem to generally work in practice, since the implementors
generally think for themselves.

But I wish we had some recommendations to write, if they were based
on some actual knowledge and preferably experience.

Best regards,

Ragnar

---

From: Mirja Kuehlewind <[email-masked]>
Date: Tue, 24 Mar 2020 13:45:30 +0100

Hi Ragnar,

Please see low for further replies on the other comments.

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

>> or response per NTS-KE session, see the first paragraph of Section 4.

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. 

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

>> needed in the future is significantly simplified.

Still, why can’t you not just use an error instead?

>> protocols which use NTS-KE, but not the AEAD Algorithm Negotiation record.

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!

>> than the strict requirements of RFC 1122.

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!

Mirja

---

From: Marcus Dansarie <[email-masked]>
Date: Tue, 24 Mar 2020 14:55:26 +0100

Hi Mirja,

See responses inline.

Kind regards,
Marcus Dansarie

On 2020-03-24 13:45, Mirja Kuehlewind wrote:>>>>
----------------------------------------------------------------------
> 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…

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

> 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 bi…

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.

---

From: Mirja Kuehlewind <[email-masked]>
Date: Tue, 24 Mar 2020 17:35:48 +0100

See inline.

> On 24. Mar 2020, at 14:55, Marcus Dansarie <[email-masked]> wrote:
> 
> Hi Mirja,
> 
> See responses inline.
> 
> Kind regards,
> Marcus Dansarie
> 

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!

> with error code 0 ("Unrecognized Critical Record”).
> 
> 

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 is really on an application-to-application basis, which is why the

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.

> 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

---

From: Marcus Dansarie <[email-masked]>
Date: Tue, 24 Mar 2020 18:20:01 +0100

Responses inline.

Kind regards,
Marcus

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

I agree with you in principle here. We are reluctant to make technical
changes at this late point in the process. Also, it is better to keep
the record in the draft and not need it than to remove it and find out
we need it later.

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

If you only send ID 0, the setting of the critical bit doesn't really
matter. Provided the request is complete and syntactically correct, the
only difference is what message the server will respond with if it
doesn't support ID 0. Critical bit set will yield a "Unrecognized
Critical Record" Error in return. Critical bit cleared will yield an
empty "NTS Next Protocol Negotiation" in return.

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

Ok! Do you know of an RFC with guidance for this? If so, I'd be happy to
include it and I'm sure the other authors wouldn't mind either.

---

From: Ragnar Sundblad <[email-masked]>
Date: Tue, 24 Mar 2020 19:54:40 +0100

Hello Mirja,

I would like to thank you for your work, your input, your cooperation
and your patience!

I am very happy to see how the specification has improved during
the last days, thanks to you and several others.

Best regards,

Ragnar

---

From: Mirja Kuehlewind <[email-masked]>
Date: Tue, 24 Mar 2020 20:08:37 +0100

Thanks for your note!

> On 24. Mar 2020, at 19:54, Ragnar Sundblad <[email-masked]> wrote:
> 
> 	
> Hello Mirja,
> 
>

---

From: "Ulrich Windl" <[email-masked]>
Date: Wed, 25 Mar 2020 07:59:40 +0100

>>> Marcus Dansarie <[email-masked]> schrieb am 24.03.2020 um 18:20 in
Nachricht
<12104_1585070439_5E7A4166_12104_203_1_8f11bdb7-3526-279e-799e-42255928695c@dans
rie.se>:
>> 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.
> 
>> 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.
> 
>> 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.
> 

I'm absolutely no expert on this, but you might consider:
RFC 1063 (IP MTU Discovery Options) from 1988
RFC 1191 (Path MTU Discovery) from 1990, flagged as draft standard
All other documents I found refer to TCP (see attachmnent that was created
from my own little private database)

Regards,
Ulrich