Reviewer: Catherine Meadows Review result: Not Ready 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. The summary of the review is Not Ready. This ID presents a variant of NTP that provides more accurate time measurements than basicNTP. In basic NTP, the origin timestamp of a message is placed in the message itself, so the time taken in processing the send after the message creation cannot be taken into account. In interleaved NTP, the timestamp is place in a later message, and a procedure is given for the determining which timestamps go with which messages. The procedure is relatively complex, and it introduces security vulnerabilities. These, and appropriate countermeasures, are described in the Security Considerations Section. This is well written and sets out the issues clearly, and I don’t see any problems with it. The ID also includes a new section, on protocol failures, which describes the various ways in which incorrect implementations can cause the protocol to fail. I have some problems with this section. First of all, it begins as follows: 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? Does the “can” means it can work reliably sometimes but not all of the time? 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. 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. 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. 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. 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? I also don’t think it is necessary to give a complete or even a very long list of things that can go wrong, just enough to give justification to your conclusions. -- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
