Skip to main content

UDP Checksum Complement in the Network Time Protocol (NTP)

The information below is for an old version of the document that is already published as an RFC.
Document Type
This is an older version of an Internet-Draft that was ultimately published as RFC 7821.
Author Tal Mizrahi
Last updated 2016-03-30 (Latest revision 2016-03-10)
Replaces draft-mizrahi-ntp-checksum-trailer
RFC stream Internet Engineering Task Force (IETF)
Intended RFC status Experimental
Additional resources Mailing list discussion
Stream WG state Submitted to IESG for Publication
Document shepherd Karen O'Donoghue
Shepherd write-up Show Last changed 2016-03-02
IESG IESG state Became RFC 7821 (Experimental)
Action Holders
Consensus boilerplate Yes
Telechat date (None)
Responsible AD Brian Haberman
Send notices to "Karen O'Donoghue" <>
IANA IANA review state Version Changed - Review Needed
IANA action state RFC-Ed-Ack
NTP Working Group                                             T. Mizrahi
Internet Draft                                                   Marvell
Intended status: Experimental
Expires: September 2016                                   March 10, 2016

        UDP Checksum Complement in the Network Time Protocol (NTP)


   The Network Time Protocol (NTP) allows clients to synchronize to a
   time server using timestamped protocol messages. To facilitate
   accurate timestamping, some implementations use hardware-based
   timestamping engines that integrate the accurate transmission time
   into every outgoing NTP packet during transmission. Since these
   packets are transported over UDP, the UDP checksum field is then
   updated to reflect this modification. This document proposes an
   extension field that includes a 2-octet Checksum Complement, allowing
   timestamping engines to reflect the checksum modification in the last
   2 octets of the packet rather than in the UDP checksum field. The
   behavior defined in this document is interoperable with existing NTP

Status of this Memo

   This Internet-Draft is submitted to IETF in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at

   The list of Internet-Draft Shadow Directories can be accessed at

   This Internet-Draft will expire on September 10, 2016.

Mizrahi, T.           Expires September 10, 2016               [Page 1]
Internet-Draft         NTP Checksum Complement               March 2016

Copyright Notice

   Copyright (c) 2016 IETF Trust and the persons identified as the
   document authors. All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   ( in effect on the date of
   publication of this document. Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document. Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1. Introduction...................................................2
      1.1. Intermediate Entities.....................................3
      1.2. Updating the UDP Checksum.................................5
   2. Conventions used in this document..............................6
      2.1. Terminology...............................................6
      2.2. Abbreviations.............................................6
   3. Using UDP Checksum Complements in NTP..........................6
      3.1. Overview..................................................6
      3.2. Checksum Complement in NTP Packets........................7
         3.2.1. Transmission of NTP with Checksum Complement.........9
         3.2.2. Updates of NTP with Checksum Complement..............9
         3.2.3. Reception of NTP with Checksum Complement............9
      3.3. Interoperability with Existing Implementations............9
      3.4. The Checksum Complement and Authentication................9
   4. Security Considerations.......................................10
   5. IANA Considerations...........................................10
   6. Acknowledgments...............................................11
   7. References....................................................11
      7.1. Normative References.....................................11
      7.2. Informative References...................................11
   Appendix A. Checksum Complement Usage Example....................12

1. Introduction

   The Network Time Protocol [NTPv4] allows clients to synchronize their
   clocks to a time server by exchanging NTP packets. The increasing
   demand for highly accurate clock synchronization motivates
   implementations that provide accurate timestamping.

Mizrahi, T.           Expires September 10, 2016               [Page 2]
Internet-Draft         NTP Checksum Complement               March 2016

1.1. Intermediate Entities

   In this document we use the term 'intermediate entity', referring to
   an entity that resides on the path between the sender and the
   receiver of an NTP packet, that modifies this NTP packet en-route.
   Two examples of intermediate entities are presented below.

   In order to facilitate accurate timestamping, an implementation can
   use a hardware based timestamping engine, as shown in Figure 1. In
   such cases, NTP packets are sent and received by a software layer,
   whereas a timestamping engine modifies every outgoing NTP packet by
   incorporating its accurate transmission time into the <Transmit
   Timestamp> field in the packet.

Mizrahi, T.           Expires September 10, 2016               [Page 3]
Internet-Draft         NTP Checksum Complement               March 2016

                      NTP client/server
                    |                   |
                    |   +-----------+   |
     Software       |   |    NTP    |   |
                    |   | protocol  |   |
                    |   +-----+-----+   |
                    |         |         |     +---------------------+
                    |   +-----+-----+   |    / Intermediate entity  |
                    |   | Accurate  |   |   /  in charge of:        |
     ASIC/FPGA      |   | Timestamp |   |  /__ -Timestamping        |
                    |   |  engine   |   |     |-Updating checksum or|
                    |   +-----------+   |     | Checksum Complement |
                    |         |         |     +---------------------+
                              |NTP packets
                          ___ v _
                         /   \_/ \__
                        /           \_
                       /     IP      /
                       \_  Network  /
                        /           \
                        \__/\_   ___/

                   Figure 1 Accurate Timestamping in NTP

   The accuracy of clock synchronization over packet networks is highly
   sensitive to delay jitters in the underlying network, which
   dramatically affects the clock accuracy. To address this challenge
   the Precision Time Protocol (PTP) [IEEE1588] defines Transparent
   Clocks (TCs), switches and routers that improve the end-to-end
   accuracy by updating a "Correction Field" in the PTP packet by adding
   the latency caused by the current TC. In NTP no equivalent entity is
   currently defined, but future versions of NTP may define an
   intermediate node that modifies en-route NTP packets using a
   "Correction Field".

Mizrahi, T.           Expires September 10, 2016               [Page 4]
Internet-Draft         NTP Checksum Complement               March 2016

1.2. Updating the UDP Checksum

   When the UDP payload is modified by an intermediate entity, the UDP
   Checksum field needs to be updated to maintain its correctness. When
   using UDP over IPv4 ([UDP]), an intermediate entity that cannot
   update the value of the UDP checksum has no choice except to assign a
   value of zero to the checksum field, causing the receiver to ignore
   the checksum field and potentially accept corrupted packets. UDP over
   IPv6, as defined in [IPv6], does not allow a zero checksum, except in
   specific cases [ZeroChecksum]. As discussed in [ZeroChecksum], the
   use of a zero checksum is generally not recommended, and should be
   avoided to the extent possible.

   Since an intermediate entity only modifies a specific field in the
   packet, i.e. the timestamp field, the UDP checksum update can be
   performed incrementally, using the concepts presented in [Checksum].

   This document defines the Checksum Complement in [NTPv4]. The
   Checksum Complement is a 2-octet field that resides at the end of the
   UDP payload. It allows intermediate entities to update NTP packets
   and maintain the correctness of the UDP checksum by modifying the
   last 2 octets of the packet, instead of updating the UDP checksum
   field. This is performed by adding an NTP extension field at the end
   of the packet, in which the last two bytes are used as a Checksum

   The usage of the Checksum Complement can in some cases simplify the
   implementation, since if the packet data is processed in a serial
   order, it is simpler to first update the timestamp field, and then
   update the Checksum Complement rather than to update the timestamp
   and then update the UDP checksum, residing at the UDP header. Note
   that while it is not impossible to implement a hardware timestamper
   that updates the UDP checksum, using the Checksum Complement instead
   can significantly simplify the implementation.

   Note that the software layer and the intermediate entity (see Figure
   1) are two modules in a single NTP clock. It is assumed that these
   two modules are in agreement regarding whether transmitted NTP
   packets include the Checksum Complement or not.

   The Checksum Complement mechanism is also defined for the One-Way
   Active Measurement Protocol (OWAMP) and the Two-Way Active
   Measurement Protocol (TWAMP) in [IPPMComp]. A similar mechanism is
   presented in Annex E of [IEEE1588].

Mizrahi, T.           Expires September 10, 2016               [Page 5]
Internet-Draft         NTP Checksum Complement               March 2016

2. Conventions used in this document

2.1. Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   document are to be interpreted as described in [KEYWORDS].

2.2. Abbreviations

   MAC      Message Authentication Code

   NTP      Network Time Protocol

   PTP      Precision Time Protocol

   UDP      User Datagram Protocol

3. Using UDP Checksum Complements in NTP

3.1. Overview

   The UDP Checksum Complement is a two-octet field that is appended at
   the end of the UDP payload using an NTP extension field. Figure 2
   illustrates the packet format of an NTP packet with a Checksum
   Complement extension.

Mizrahi, T.           Expires September 10, 2016               [Page 6]
Internet-Draft         NTP Checksum Complement               March 2016

                    |      IPv4 / IPv6 Header        |
                    |           UDP Header           |
            ^       |                                |
            |       |           NTP packet           |
            |       |                                |
            |       +--------------------------------+
           UDP      | Optional NTP Extension Fields  |
         Payload    +--------------------------------+
            |       |    UDP Checksum Complement     |
            |       |   Extension Field (28 octets)  |
            v       +--------------------------------+

                Figure 2 Checksum Complement in NTP Packets

   The Checksum Complement is used to compensate for changes performed
   in the NTP packet by intermediate entities, as described in the
   introduction. An example of the usage of the Checksum Complement is
   provided in Appendix A.

3.2. Checksum Complement in NTP Packets

   NTP is transported over UDP, either over IPv4 or over IPv6. This
   document applies to both NTP over IPv4, and NTP over IPv6.

   NTP packets may include one or more extension fields, as defined in
   [NTPv4]. The Checksum Complement in NTP packets resides in a
   dedicated NTP extension field, as shown in Figure 3.

   If the NTP packet includes more than one extension field, the
   Checksum Complement extension is always the last extension field.
   Thus, the Checksum Complement is the last 2 octets in the UDP
   payload, and thus the Checksum Complement is located at (UDP Length -
   2 octets) after the beginning of the UDP header. Note that the
   Checksum Complement is not used in authenticated NTP packets, as
   further discussed in Section 3.4.

   Using the Checksum Complement

     As described in Section 1, an intermediate entity that updates the
     timestamp in the NTP packet can use the Checksum Complement in
     order to maintain the correctness of the UDP checksum field.
     Specifically, if the value of the timestamp is updated from T to

Mizrahi, T.           Expires September 10, 2016               [Page 7]
Internet-Draft         NTP Checksum Complement               March 2016

     T', this update yields a change in the UDP checksum value; thus,
     the intermediate entity assigns a new value in the Checksum
     Complement that cancels this change, leaving the current value of
     the UDP checksum correct. An example of the usage of the Checksum
     Complement is provided in Appendix A.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   |          Field Type           |      Length = 28 octets       |
   |                                                               |
   |                              MBZ                              |
   |                                                               |
   |                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                               |      Checksum Complement      |
             Figure 3 NTP Checksum Complement Extension Field

   Field Type

     A dedicated Field Type value is used to identify the Checksum
     Complement extension. See Section 5. for further details.


     The Checksum Complement extension field length is 28 octets.

     This length guarantees that the host that receives the packet
     parses it correctly, whether the packet includes a MAC or not.
     [NTP-Ext] provides further details about the length of an
     extension field in the absence of a MAC.


     The extension field includes a 22-octet MBZ (MUST be zero) field.
     This field MUST be set to 0, and MUST be ignored by the recipient.
     The MBZ field is used for padding the extension field to 28

   Checksum Complement

     Includes the UDP Checksum Complement field.

Mizrahi, T.           Expires September 10, 2016               [Page 8]
Internet-Draft         NTP Checksum Complement               March 2016

3.2.1. Transmission of NTP with Checksum Complement

   The transmitter of an NTP packet MAY include a Checksum Complement
   extension field.

3.2.2. Updates of NTP with Checksum Complement

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

3.2.3. Reception of NTP with Checksum Complement

   This document does not impose new requirements on the receiving end
   of an NTP packet.

   The UDP layer at the receiving end verifies the UDP Checksum of
   received NTP packets, and the NTP layer SHOULD ignore the Checksum
   Complement extension field.

3.3. Interoperability with Existing Implementations

   The behavior defined in this document does not impose new
   requirements on the reception of NTP packets beyond the requirements
   defined in [NTP-Ext]. Note that, as defined in [NTP-Ext], a host that
   receives an NTP message with an unknown extension field SHOULD ignore
   the extension field and MAY drop the packet if policy requires it.
   Thus, transmitters and intermediate entities that support the
   Checksum Complement can transparently interoperate with receivers
   that are not Checksum-Complement-compliant, as long as these
   receivers ignore unknown extension fields. It is noted that existing
   implementations that discard packets with unknown extension fields
   cannot interoperate with transmitters that use the Checksum

   It should be noted that when hardware-based timestamping is used, it
   will likely be used at both ends, and thus both hosts that take part
   in the protocol will support the functionality described in this
   memo. If only one of the hosts uses hardware-based timestamping, then
   the Checksum Complement can only be used if it is known that the peer
   host can accept the Checksum Complement.

3.4. The Checksum Complement and Authentication

   A Checksum Complement MUST NOT be used when authentication is
   enabled. The Checksum Complement is useful in unauthenticated mode,

Mizrahi, T.           Expires September 10, 2016               [Page 9]
Internet-Draft         NTP Checksum Complement               March 2016

   allowing the intermediate entity to perform serial processing of the
   packet without storing-and-forwarding it.

   On the other hand, when message authentication is used, an
   intermediate entity that alters NTP packets must also re-compute the
   Message Authentication Code (MAC) accordingly. In this case it is not
   possible to update the Checksum Complement; updating the Checksum
   Complement would result in having to recalculate the MAC, and there
   would be a cyclic dependency between the MAC and the Checksum
   Complement. Hence, when updating the MAC it is necessary to update
   the UDP Checksum field, making the Checksum Complement field
   unnecessary in the presence of authentication.

4. Security Considerations

   This document describes how a Checksum Complement extension can be
   used for maintaining the correctness of the UDP checksum. The
   security considerations of time protocols in general are discussed in
   [SecTime], and the security considerations of NTP are discussed in

   The purpose of this extension is to ease the implementation of
   accurate timestamping engines, as described in Figure 1. The
   extension is intended to be used internally in an NTP client or
   server. This extension is not intended to be used by switches and
   routers that reside between the client and the server. As opposed to
   PTP [IEEE1588], NTP does not require intermediate switches or routers
   to modify the content of NTP messages, and thus any such modification
   should be considered as a malicious MITM attack.

   It is important to emphasize that the scheme described in this
   document does not increase the protocol's vulnerability to MITM
   attacks; a MITM who maliciously modifies a packet and its Checksum
   Complement is logically equivalent to a MITM attacker who modifies a
   packet and its UDP Checksum field.

   The concept described in this document is intended to be used only in
   unauthenticated mode. As discussed in Section 3.4. , if a
   cryptographic security mechanism is used, then the Checksum
   Complement does not simplify the implementation compared to using the
   conventional Checksum, and therefore the Checksum Complement is not

5. IANA Considerations

   IANA is requested to allocate a new value in the "NTP Extension
   Field Types" registry. The requested value is:

Mizrahi, T.           Expires September 10, 2016              [Page 10]
Internet-Draft         NTP Checksum Complement               March 2016

   0x2005 Checksum Complement

6. Acknowledgments

   The author gratefully thanks Danny Mayer, Miroslav Lichvar, Paul
   Kyzivat, Suresh Krishnan, and Brian Haberman for their review and
   helpful comments.

   This document was prepared using

7. References

7.1. Normative References

   [KEYWORDS]    Bradner, S., "Key words for use in RFCs to Indicate
                 Requirement Levels", BCP 14, RFC 2119, March 1997.

   [IPv6]        Deering, S., Hinden, R., "Internet Protocol, Version 6
                 (IPv6) Specification", RFC 2460, December 1998.

   [Checksum]    Rijsinghani, A., "Computation of the Internet Checksum
                 via Incremental Update", RFC 1624, May 1994.

   [UDP]         Postel, J., "User Datagram Protocol", RFC 768, August

   [NTPv4]       Mills, D., Martin, J., Burbank, J., Kasch, W.,
                 "Network Time Protocol Version 4: Protocol and
                 Algorithms Specification", RFC 5905, June 2010.

   [NTP-Ext]     Mizrahi, T., Mayer, D., "The Network Time Protocol
                 Version 4 (NTPv4) Extension Fields", draft-ietf-ntp-
                 extension-field (work in progress), February 2016.

7.2. Informative References

   [IEEE1588]    IEEE TC 9 Instrumentation and Measurement Society
                 2000, "1588 IEEE Standard for a Precision Clock
                 Synchronization Protocol for Networked Measurement and
                 Control Systems Version 2", IEEE Standard, 2008.

   [IPPMComp]    Mizrahi, T., "UDP Checksum Complement in OWAMP and
                 TWAMP", draft-ietf-ippm-checksum-trailer (work in
                 progress), February 2016.

   [SecTime]     Mizrahi, T., "Security Requirements of Time Protocols
                 in Packet Switched Networks", RFC 7384, October 2014.

Mizrahi, T.           Expires September 10, 2016              [Page 11]
Internet-Draft         NTP Checksum Complement               March 2016

   [ZeroChecksum] Fairhurst, G., Westerlund, M., "Applicability
                 Statement for the Use of IPv6 UDP Datagrams with Zero
                 Checksums", RFC 6936, April 2013.

Appendix A.                 Checksum Complement Usage Example

   Consider an NTP packet sent by an NTP client to an NTP server.

   The client's software layer (see Figure 1) generates an NTP packet
   with an Origin Timestamp T, and a UDP checksum value U. The value of
   U is the checksum of the UDP header, UDP payload, and pseudo-header.
   Thus, U is equal to:

                        U = Const + checksum(T)                    (1)

   Where 'Const' is the checksum of all the fields that are covered by
   the checksum except the Origin Timestamp T.

   Recall that the client's software emits the NTP packet with a
   Checksum Complement extension field, which resides at the end of the
   PTP packet. It is assumed that the client initially assigns zero to
   the value of the Checksum Complement.

   The client's timestamping engine updates the Origin Timestamp field
   to the accurate time, changing its value from T to T'. The engine
   also updates the Checksum Complement field from zero to a new value
   C, such that:

                  checksum(C) = checksum(T) - checksum(T')         (2)

   When the NTP packet is transmitted by the client's timestamping
   engine, the value of the checksum remains U as before:

   U = Const + checksum(T) = Const + checksum(T)+ checksum(T')-
   checksum(T') = Const + checksum(T') + checksum(C)               (3)

   Thus, after the timestamping engine has updated the timestamp, U
   remains the correct checksum of the packet.

   When the NTP packet reaches the NTP server, the server performs a
   conventional UDP checksum computation, and the computed value is U.
   Since the Checksum Complement is part of the extension field, its
   value (C) is transparently included in the computation, as per
   Equation (3), without requiring special treatment by the server.

Mizrahi, T.           Expires September 10, 2016              [Page 12]
Internet-Draft         NTP Checksum Complement               March 2016

Authors' Addresses

   Tal Mizrahi
   6 Hamada St.
   Yokneam, 20692 Israel


Mizrahi, T.           Expires September 10, 2016              [Page 13]