-
Notifications
You must be signed in to change notification settings - Fork 0
/
mk2.txt
142 lines (136 loc) · 6.64 KB
/
mk2.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
130
131
132
133
134
135
136
137
138
139
140
141
142
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 protected]> 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).
> > 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.