[Ntp] Secdir last call review of draft-ietf-ntp-interleaved-modes-06

[Catherine Meadows via Datatracker <[e-mail]>]

Reviewer: Catherine Meadows
Review result: Has Nits

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.