NTP Correction Field
draft-mlichvar-ntp-correction-field-00
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Expired".
|
|
|---|---|---|---|
| Author | Miroslav Lichvar | ||
| Last updated | 2017-10-30 | ||
| RFC stream | (None) | ||
| Formats | |||
| Additional resources | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-mlichvar-ntp-correction-field-00
Internet Engineering Task Force M. Lichvar
Internet-Draft Red Hat
Intended status: Experimental October 30, 2017
Expires: May 3, 2018
NTP Correction Field
draft-mlichvar-ntp-correction-field-00
Abstract
This document specifies an extension field for the Network Time
Protocol (NTP) which allows network devices such as switches and
routers to modify NTP packets with corrections to improve accuracy of
the synchronization in the network.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
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."
This Internet-Draft will expire on May 3, 2018.
Copyright Notice
Copyright (c) 2017 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
(https://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.
Lichvar Expires May 3, 2018 [Page 1]
Internet-Draft NTP Correction Field October 2017
1. Introduction
Processing and queueing delays in network switches and routers may be
a significant source of jitter and asymmetry in network delay, which
has a negative impact on accuracy and stability of synchronization of
clocks in local networks using NTP [RFC5905].
If all network devices on the paths between NTP clients and servers
implemented NTP and supported an operation as a server and client,
the impact of the delays could be avoided by configuring NTP to make
measurements only between devices and hosts that are directly
connected to one another. In the Precision Time Protocol (PTP)
[IEEE1588], which is a different protocol for synchronization of
clocks in networks, such devices would be called Boundary Clocks
(BC).
A different approach supported by PTP to improve the accuracy uses
Transparent Clocks (TC). Instead of fully implementing PTP in order
to support an operation as a BC, the devices only modify a correction
field in forwarded PTP packets with the time that the packets had to
wait for transmission. The final value of the correction is included
in the calculation of the delay and offset, which may significantly
improve the accuracy and stability of the synchronization.
This document describes an NTP extension field which allows the
devices to make similar correction in forwarded NTP packets.
1.1. Requirements Language
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 RFC 2119 [RFC2119].
2. Format of Correction Field
The Correction Field is an NTP extension field following RFC 7822
[RFC7822]. The format of the extension field is shown in Figure 1.
Lichvar Expires May 3, 2018 [Page 2]
Internet-Draft NTP Correction Field October 2017
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) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Receive Correction | Transmit Correction |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Origin Correction |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Delay Correction |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Origin ID | Path ID | Checksum complement |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: Format of Correction Field
The extension field has the following fields:
Field Type
The type which identifies the Correction extension field.
TBD
Length
The length of the extension field, which is 28 octets.
Receive Correction
A 16-bit extension of the receive timestamp in the NTP
header.
Transmit Correction
A 16-bit extension of the transmit timestamp in the NTP
header.
Origin Correction
A field which contains a copy of the final delay correction
from the previous packet in the NTP exchange.
Delay Correction
A fixed point number with 16 unsigned integer bits and 48
fractional bits, which represents the current correction of
the network delay that has accumulated for this packet on the
path from the source to the destination.
Origin ID
Lichvar Expires May 3, 2018 [Page 3]
Internet-Draft NTP Correction Field October 2017
A field which contains a copy of the final path ID from the
previous packet in the NTP exchange.
Path ID
An 8-bit identification number of the path where the delay
correction was updated.
Checksum Complement
A field which can be modified to not change the UDP checksum
after updating the other fields. The same field is described
in RFC 7821 [RFC7821].
3. Network devices
A network device which is forwarding a packet and supports the
Correction Field MUST NOT modify the packet unless all of the
following applies:
1. The packet is an IPv4 or IPv6 UDP packet.
2. The source port or destination port is 123.
3. The NTP version is 4.
4. The NTP mode is 1, 2, 3, 4, or 5.
5. The format of the packet is valid per RFC 7822.
6. The packet contains an extension field which has a type of TBD
and length of 28 octets.
The device SHOULD add to the delay correction field of the extension
field the time difference between the following points:
1. The end of the reception (trailer timestamp).
2. The beginning of the transmission (preamble timestamp).
If the device updates the delay correction, it SHOULD also add the
identification numbers of the incoming and outgoing port to the path
ID.
The device MAY update the checksum complement field in order to keep
the UDP checksum valid.
TBD: Requirements on frequency accuracy of the clock.
Lichvar Expires May 3, 2018 [Page 4]
Internet-Draft NTP Correction Field October 2017
4. NTP hosts
When an NTP client sends a request to a server and the association is
configured to use the Correction Field, it SHOULD add the extension
field to the packet. All fields of the extension field except type
and length SHOULD be set to zero.
When the server receives a packet which includes the extension field,
the response SHOULD also include the extension field.
If the server's clock has a better precision than resolution of the
64-bit NTP timestamp format, the server SHOULD save the additional
bits in the receive and transmit correction fields and set the
precision field to the corresponding number, which is smaller than
-32. Otherwise, the receive and transmit correction fields SHOULD be
zero.
The origin correction and origin path ID SHOULD be set to the delay
correction and path ID from the request. The other fields of the
Correction Field SHOULD be zero.
When the client receives a response which contains the extension
field, it SHOULD check the value of both the origin and delay
correction fields. If a correction is larger than a specified
maximum (e.g. 1 second), the extension field SHOULD be ignored.
The client MAY log a warning if the origin ID and path ID are not
equal, which indicates the network path between the server and client
is not symmetric.
If the client's clock has a better precision than resolution of the
64-bit NTP format and the precision field in the response contains a
number smaller than -32, the client SHOULD extend the receive and
transmit timestamps with the additional bits in the receive and
transmit correction fields.
When the client computes the offset and delay using the formulas from
RFC 5905, the origin correction is substracted from the receive
timestamp and the delay correction is added to the transmit
timestamp.
TBD: Other modes.
5. Acknowledgements
The Correction Field extension is based on the PTP correction field
specified in IEEE 1588-2008.
Lichvar Expires May 3, 2018 [Page 5]
Internet-Draft NTP Correction Field October 2017
6. IANA Considerations
IANA is requested to allocate an Extension Field Type for the
Correction Field.
7. Security Considerations
Packets using the Correction Field cannot be authenticated by legacy
MACs, because network devices which are supposed to update the field
do not have access to the key.
Packets can be partially protected if the Correction Field is placed
in the packet after an authentication extension field, e.g. the NTS
Authenticator and Encrypted Extensions extension field
[I-D.ietf-ntp-using-nts-for-ntp].
A man-in-the-middle attacker can delay packets in the network in
order to increase the measured delay and shift the measured offset by
up to half of the extra delay. If the packets contain the Correction
Field, the attacker can reduce the delay calculated by the client or
peer and shift the offset even more. The maximum correction should
be limited (e.g. to 1 second) to prevent the attacker from injecting
a larger offset to the measurements.
8. References
8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch,
"Network Time Protocol Version 4: Protocol and Algorithms
Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010,
<https://www.rfc-editor.org/info/rfc5905>.
[RFC7822] Mizrahi, T. and D. Mayer, "Network Time Protocol Version 4
(NTPv4) Extension Fields", RFC 7822, DOI 10.17487/RFC7822,
March 2016, <https://www.rfc-editor.org/info/rfc7822>.
8.2. Informative References
[I-D.ietf-ntp-using-nts-for-ntp]
Franke, D., Sibold, D., and K. Teichel, "Network Time
Security for the Network Time Protocol", draft-ietf-ntp-
using-nts-for-ntp-09 (work in progress), June 2017.
Lichvar Expires May 3, 2018 [Page 6]
Internet-Draft NTP Correction Field October 2017
[IEEE1588]
IEEE std. 1588-2008, "IEEE Standard for a Precision Clock
Synchronization Protocol for Networked Measurement and
Control Systems", 2008.
[RFC7821] Mizrahi, T., "UDP Checksum Complement in the Network Time
Protocol (NTP)", RFC 7821, DOI 10.17487/RFC7821, March
2016, <https://www.rfc-editor.org/info/rfc7821>.
Author's Address
Miroslav Lichvar
Red Hat
Purkynova 115
Brno 612 00
Czech Republic
Email: mlichvar@redhat.com
Lichvar Expires May 3, 2018 [Page 7]