secdir review for draft-ietf-ntp-checksum-trailer-04.txt

Sandra Murphy <> Thu, 03 March 2016 16:47 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 4A6D61A87EA; Thu, 3 Mar 2016 08:47:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.907
X-Spam-Status: No, score=-1.907 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id NJ6qq0RColpG; Thu, 3 Mar 2016 08:47:31 -0800 (PST)
Received: from ( []) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 0A2661A87E1; Thu, 3 Mar 2016 08:47:29 -0800 (PST)
Received: from (unknown []) by (Postfix) with ESMTP id 4470028B0041; Thu, 3 Mar 2016 11:47:28 -0500 (EST)
Received: from [IPv6:::1] (localhost.localdomain []) by (Postfix) with ESMTP id 3CDDA1F801E; Thu, 3 Mar 2016 11:47:28 -0500 (EST)
From: Sandra Murphy <>
X-Pgp-Agent: GPGMail 2.5.2
Content-Type: multipart/signed; boundary="Apple-Mail=_FDEEF1C7-7CB0-4270-9CCD-A792702A767C"; protocol="application/pgp-signature"; micalg="pgp-sha512"
Subject: secdir review for draft-ietf-ntp-checksum-trailer-04.txt
Date: Thu, 03 Mar 2016 11:47:27 -0500
Message-Id: <>
To:,, The IETF <>
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
X-Mailer: Apple Mail (2.1878.6)
Archived-At: <>
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF-Discussion <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 03 Mar 2016 16:47:36 -0000

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

I found the document adequate for the most part.


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.


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.


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:

  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.