On Thu, Aug 01, 2024 at 11:57:46AM -0700, Catherine Meadows via Datatracker wrote: > I have reviewed this document as part of the security directorate's > ongoing effort to review all IETF documents being processed by the > IESG. These comments were written primarily for the benefit of the > security area directors. Document editors and WG chairs should treat > these comments just like any other last call comments. Thank you for the review. > An incorrect client implementation of the basic mode (RFC 5905) can > work reliably with servers that implement only the basic mode, but > the protocol can fail intermittently with servers that implement the > interleaved mode. > > First of all, it’s not clear what “can work reliably” means here. Does “work > reliably” mean that the client and server get accurate time measurements? It means it gets (from its point of view) a valid response for each request it sends to the server, assuming no network drops etc, and all measurements are made from the expected set of server and client timestamps. It doesn't necessarily have to be more accurate than a corrupted measurement using an unexpected set of timestamps. > Does the “can” means it can work reliably sometimes but not all of the time? No, some clients not following RFC5905 could work reliably all the time with a server supporting only the basic mode. > Then the paragraph goes on to say “but the protocol can fail intermittently > with servers that implement the interleaved mode.” I assume we are not talking > about the protocol failing with client with an incorrect basic mode and a > server that is implementing interleaved mode. That is exactly the case. > Do we mean the client is > implementing interleaved mode incorrectly, and the server is implementing it > correct?, That seems to be the case given the examples that follow. But it > should be made clear in the first paragraph. The clients don't support interleaved mode, only basic mode - incorrectly. > What follows is a laundry list of incorrect client implementations and the > problems they cause. But I don’t have an idea of whether this is intended to > be complete or not. It should be the only issue that a client working reliably only with a basic-only-mode server can have (origin timestamp set incorrectly) with two examples showing the minimum and maximum impact. > I also don’t have much of a feel as to how interleaved > mode compares with basic mode in terms of reliability, which I think is the > point of this section. There should be no difference in reliability if correctly implemented. > In order to make this section useful the document should at very least 1) make > it clear what the tolerance of basic mode is to incorrect protocol > implementations, 2) give an idea of how much less tolerant interleaved mode is > of incorrect implementations than basic mode, and 3) give the reader some > indication of how this information should be used. With respect to 3) my > impression is that the takeaway should be that interleaved mode should be used > with great care, preferably in closed environments in which the quality of the > implementations can be controlled, and only in cases in which the accuracy of > the time measures is paramount. Is that the case? That wasn't the intention. The reason for adding this section was to address concerns raised in the previous round of IESG reviews, which blocked the document. It tries to explain that interleaved mode is safe for the Internet, that it doesn't break existing clients even if they don't implement the basic mode correctly. Then it also explains possible issues on the server side. Maybe that should be clearly separated. I'll try to improve the text to make this point more clear. I think the resilience has also been proved in the real world by now. Interleaved mode is widely supported on public servers. Possibly a majority of the NTP traffic is now handled by interleave-enabled servers, and there were no reports of any breakage. -- Miroslav Lichvar -- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
