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.

This document extends the Network Time Protocol (NTP) in RFC 5905 with modes called “NTP interleaved modes” that allow principals to delay submitting timestamps.  This allows more accurate timestamps to be computed.   However, it also introduces  certain security risks.  In particular, the origin timestamp is repurposed as a cookie that is used to identify a received packet is a response to the last packet sent in the other direction of the association: it is either 0 if the packet is not a response, or if it is a response, it is a copy of either the receive or transmit timestamp, depending on the type of packet.  This means that an attacker, even if it is off-path and has no access to the packets themselves, would be able to forge a response if it is able to guess a receive or transmit  response.    For this reason, it is recommended  in  the Security Considerations Section that the receive (respectively transmit) timestamps be randomized.  It is also pointed out that the NTP interleaved modes  are subject to DoS attacks, so that clients SHOULD NOT rely on servers to be able to respond in the interleaved mode.  In addition, since zeroing out origin timestamps in order to protect observers from tracking clients moving between networks is  not possible, NTP interleaved modes are more vulnerable to such tracking.

I think that the authors have done a good job of identifying the security issues that arise with NTP interleaved modes and means for dealing with them.  In some places though,  the Security Considerations section could be a little bit clearer.  I consider the following comments slightly about the nit level, but close enough so I’m marking this as Ready With Nits.

1. The paragraph about security implications of using origin timestamps as cookies has two subjects: off-line attackers guessing origin timestamps in order to spoof responses, and attackers using origin timestamps to track clients.  However, I found the presentation a little unclear on this point: the last sentence, that discusses the tracking threat, does not explicitly say that it is introducing a new topic.  I would suggest something like:

The use of timestamps in NTP interleaved modes also  makes clients more vulnerable to tracking as they move between networks, since it is not possible to zero out origin timestamps to protect against such exploitation.

You might also want to think about giving this sentence its own paragraph.

2.  I had trouble interpreting the following sentence:

The
   NTP state needs to be protected not only between the reception and
   transmission in order to send the peer a packet with a valid origin
   timestamp, but all the time to not lose the timestamps which will be
   needed to complete a measurement when the following packet in the
   interleaved mode is received.

It took me a while to see that what you were saying was NRP state needs to be protected not only between the reception and transmission … , but all the time … .
The sentence is so long and carries so much information that I lost the sense of the structure halfway through.  It would be better to break it down into shorter sentences, e.g. start with
“NRP state needs to be protected not only between the reception and transmission, but all the time.”, and then go into the reasons.