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 document draft-ietf-ntp-checksum-trailer-04.txt defines a new
extension header for NTP that will allow a hardware based timestamping
engine to modify the timestamp in the NTP packet and then add a
correction to the packet's UDP checksum to account for the modified
timestamp.  Putting the correction in an extension header allows for
serial processing of the packet - no need to backtrack from the
timestamp to the UDP checksum preceding in the packet and correct that
field.

I found the document adequate for the most part.

(1)

It seems there's an impossibility of protecting the NTP packet with
this extension.  This extension header MUST NOT be used with an NTP
MAC, and so is usable only in those situations where NTP is used in an
"unauthenticated mode".  One might imagine that NTP running in an
unauthenticated mode could be run in an ipsec tunnel for protection.
However, the description of the timestamping engine makes it seem that
the engine modifies the packet directly before transmission.  I.e.,
the packet would be modified after the ipsec protections were applied.
Certainly the "intermediate nodes" mentioned in 3.2.2 would be adding
the extension header after the source applied the ipsec protection.
If my suppositions are correct, then using this extension header means
neither an authenticated NTP nor a protected tunnel could be used.
All the intruder attacks mentioned in RFC5905 security considerations
section would be possible.

(2)

RFC5905 and draft-ietf-ntp-extension-field-07.txt both define the
general extension header format with the padding following the value.
This draft defines this extension header as the value following the
padding.  That conflict should be addressed.

(3)

Section 1 describes intermediate entities (like the timestamping
engine), and section 3.2.2 says:

  An intermediate node that receives and alters an NTP packet
  containing a Checksum Complement extension MAY use the Checksum
  Complement to maintain a correct UDP checksum value.

However, section 4 says:

                                                              The
  extension is intended to be used internally in an NTP client or
  server, and not intended to be used by intermediate switches and
  routers that reside between the client and the server.

That seems to contradict the earlier statements, particularly section
3.2.2.  Are the intermediate nodes of section 3.2.2 not "switches and
routers"?  This is probably just a wording issue, but it should be
more clear.

--Sandy


Attachment:


signature.asc




Description:

 Message signed with OpenPGP using GPGMail