-
Notifications
You must be signed in to change notification settings - Fork 0
/
mk.txt
129 lines (112 loc) · 6.09 KB
/
mk.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
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 at some
> 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.
> 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.
> ----------------------------------------------------------------------
> 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.