UDP Checksum Complement in the Network Time Protocol (NTP)
draft-ietf-ntp-checksum-trailer-03
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft that was ultimately published as RFC 7821.
|
|
|---|---|---|---|
| Author | Tal Mizrahi | ||
| Last updated | 2016-02-10 (Latest revision 2015-10-06) | ||
| Replaces | draft-mizrahi-ntp-checksum-trailer | ||
| RFC stream | Internet Engineering Task Force (IETF) | ||
| Formats | |||
| Reviews |
GENART Last Call review
(of
-04)
by Paul Kyzivat
Ready w/issues
|
||
| 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-02-03 | ||
| IESG | IESG state | Became RFC 7821 (Experimental) | |
| Consensus boilerplate | Unknown | ||
| Telechat date | (None) | ||
| Responsible AD | Brian Haberman | ||
| Send notices to | "Karen O'Donoghue" <odonoghue@isoc.org> |
draft-ietf-ntp-checksum-trailer-03
NTP Working Group T. Mizrahi
Internet Draft Marvell
Intended status: Experimental
Expires: April 2016 October 6, 2015
UDP Checksum Complement in the Network Time Protocol (NTP)
draft-ietf-ntp-checksum-trailer-03.txt
Abstract
The Network Time Protocol (NTP) allows clients to synchronize to a
time server using timestamped protocol messages. To faciliate
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
implementations.
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-
Drafts.
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
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on April 6, 2016.
Mizrahi, T. Expires April 6, 2016 [Page 1]
Internet-Draft NTP Checksum Complement October 2015
Copyright Notice
Copyright (c) 2015 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
(http://trustee.ietf.org/license-info) 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.........8
3.2.2. Intermediate 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. Using the Checksum Complement with or without Authentication
...............................................................9
4. Security Considerations........................................9
5. IANA Considerations...........................................10
6. Acknowledgments...............................................10
7. References....................................................10
7.1. Normative References.....................................10
7.2. Informative References...................................11
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 April 6, 2016 [Page 2]
Internet-Draft NTP Checksum Complement October 2015
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 April 6, 2016 [Page 3]
Internet-Draft NTP Checksum Complement October 2015
NTP client/server
+-------------------+
| |
| +-----------+ |
Software | | NTP | |
| | protocol | |
| +-----+-----+ |
| | |
| +-----+-----+ |
| | Accurate | |
ASIC/FPGA | | Timestamp | |
| | engine | |
| +-----------+ |
| | |
+---------+---------+
|
|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), intermediate 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 April 6, 2016 [Page 4]
Internet-Draft NTP Checksum Complement October 2015
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].
A similar problem is addressed in Annex E of [IEEE1588]. When the
Precision Time Protocol (PTP) is transported over IPv6, two octets
are appended to the end of the PTP payload for UDP checksum updates.
The value of these two octets can be updated by an intermediate
entity, causing the value of the UDP checksum field to remain
correct.
This document defines a similar concept for [NTP], allowing
intermediate entities to update NTP packets and maintain the
correctness of the UDP checksum by modifying the last 2 octets of the
packet. 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
complement.
The term Checksum Complement is used throughout this document and
refers to the 2 octets at the end of the UDP payload, used for
updating the UDP checksum by intermediate entities.
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.
Mizrahi, T. Expires April 6, 2016 [Page 5]
Internet-Draft NTP Checksum Complement October 2015
2. Conventions used in this document
2.1. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
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. The figure illustrates an unauthenticated NTP
packet. Section 3.4. provides further details about using the
Checksum Complement in authenticated packets.
Mizrahi, T. Expires April 6, 2016 [Page 6]
Internet-Draft NTP Checksum Complement October 2015
+--------------------------------+
| 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 Unauthenticated Packets
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 2.
In unauthenticated mode, if the NTP packet includes more than one
extension field, the Checksum Complement extension is always the last
extension field. Thus, when NTP authentication is disabled, 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.
When NTP authentication is enabled, the Checksum Complement is the
last 2 octets before the Message Authentication Code (MAC).
Mizrahi, T. Expires April 6, 2016 [Page 7]
Internet-Draft NTP Checksum Complement October 2015
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Padding |
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | 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 6 for further details.
Length
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.
Padding
The extension field includes 22 octets of padding. This field
SHOULD be set to 0, and SHOULD be ignored by the recipient.
Checksum Complement
Includes the UDP Checksum Complement field.
3.2.1. Transmission of NTP with Checksum Complement
The transmitter of an NTP packet MAY include a Checksum Complement
extension field.
Mizrahi, T. Expires April 6, 2016 [Page 8]
Internet-Draft NTP Checksum Complement October 2015
3.2.2. Intermediate Updates of NTP with Checksum Complement
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.
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. Thus, transmitters and
intermediate nodes that support the Checksum Complement can
transparently interoperate with existing implementations.
3.4. Using the Checksum Complement with or without Authentication
A Checksum Complement SHOULD NOT be used when authentication is
enabled. The Checksum Complement is useful in unauthenticated mode,
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 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
Mizrahi, T. Expires April 6, 2016 [Page 9]
Internet-Draft NTP Checksum Complement October 2015
server, and not intended to be used by intermediate 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 vulnerabitliy 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 described in Section 3.4. , in authenticated
mode using the Checksum Complement does not simplify the
implementation compared to using the conventional Checksum, and
therefore the Checksum Complement should not be used.
5. IANA Considerations
IANA is requested to allocate an NTP extension Field Type value for
the Checksum Complement extension.
6. Acknowledgments
This document was prepared using 2-Word-v2.0.template.dot.
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
1980.
[NTPv4] Mills, D., Martin, J., Burbank, J., Kasch, W.,
"Network Time Protocol Version 4: Protocol and
Algorithms Specification", RFC 5905, June 2010.
Mizrahi, T. Expires April 6, 2016 [Page 10]
Internet-Draft NTP Checksum Complement October 2015
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.
[NTP-Ext] Mizrahi, T., Mayer, D., "The Network Time Protocol
Version 4 (NTPv4) Extension Fields", draft-ietf-ntp-
extension-field (work in progress), August 2015.
[ZeroChecksum] Fairhurst, G., Westerlund, M., "Applicability
Statement for the Use of IPv6 UDP Datagrams with Zero
Checksums", RFC 6936, April 2013.
Authors' Addresses
Tal Mizrahi
Marvell
6 Hamada St.
Yokneam, 20692 Israel
Email: talmi@marvell.com
Mizrahi, T. Expires April 6, 2016 [Page 11]