Guidelines for Defining Packet Timestamps
draft-mizrahi-intarea-packet-timestamps-00
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
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 "Replaced".
|
|
---|---|---|---|
Authors | Tal Mizrahi , Joachim Fabini , Al Morton | ||
Last updated | 2017-06-27 | ||
Replaced by | draft-ietf-ntp-packet-timestamps, RFC 8877 | ||
RFC stream | (None) | ||
Formats | |||
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-mizrahi-intarea-packet-timestamps-00
Network Working Group T. Mizrahi Internet-Draft Marvell Intended status: Informational J. Fabini Expires: December 29, 2017 Vienna University of Technology A. Morton AT&T Labs June 27, 2017 Guidelines for Defining Packet Timestamps draft-mizrahi-intarea-packet-timestamps-00 Abstract This document specifies guidelines for defining binary packet timestamp formats in networking protocols at various layers. It also presents three recommended timestamp formats. The target audience of this memo includes network protocol designers. It is expected that a new network protocol that requires a packet timestamp will, in most cases, use one of the recommended timestamp formats. If none of the recommended formats fits the protocol requirements, the new protocol specification should specify the format of the packet timestamp according to the guidelines in this document. 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 http://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 December 29, 2017. 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 Mizrahi, et al. Expires December 29, 2017 [Page 1] Internet-Draft Packet Timestamps June 2017 (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 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 2.2. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 3 3. Packet Timestamp Format Specification . . . . . . . . . . . . 3 4. Recommended Timestamp Formats . . . . . . . . . . . . . . . . 4 4.1. NTP Timestamp Formats . . . . . . . . . . . . . . . . . . 4 4.1.1. NTP 64-bit Timestamp Format . . . . . . . . . . . . . 4 4.1.2. NTP 32-bit Timestamp Format . . . . . . . . . . . . . 6 4.2. The PTP Concatenated Timestamp Format . . . . . . . . . . 7 5. Packet Timestamp Control Field . . . . . . . . . . . . . . . 8 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 7. Security Considerations . . . . . . . . . . . . . . . . . . . 9 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 8.1. Normative References . . . . . . . . . . . . . . . . . . 10 8.2. Informative References . . . . . . . . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 1. Introduction Timestamps are widely used in network protocols for various purposes, including delay measurement, clock synchronization, and logging or reporting the time of an event. Timestamps are represented in the RFC series in one of two forms: text-based timestamps, and packet timestamps. Text-based timestamps [RFC3339] are represented as user-friendly strings, and are widely used in the RFC series, for example in information objects and data models, e.g., [RFC5646], [RFC6991], and [RFC7493]. Packet timestamps, on the other hand, are represented by a compact binary field that has a fixed size, and are not intended to have a human- friendly format. Packet timestamps are also very common in the RFC series, and are used for example for measuring delay and for synchronizing clocks, e.g., [RFC5905], [RFC4656], and [RFC1323]. This memo presents guidelines for defining a packet timestamp format in network protocols. Three recommended timestamp formats are presented. It is expected that a new network protocol that requires Mizrahi, et al. Expires December 29, 2017 [Page 2] Internet-Draft Packet Timestamps June 2017 a packet timestamp will, in most cases, use one of the recommended timestamp formats. If none of the recommended formats fits the protocol requirements, the new protocol specification should specify the format of the packet timestamp according to the guidelines in this document. 2. Terminology 2.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.2. Abbreviations NTP Network Time Protocol [RFC5905] PTP Precision Time Protocol [IEEE1588] 3. Packet Timestamp Format Specification This section defines a template for specifying packet timestamp formats. A timestamp format specification MUST include the following aspects: Timestamp field format: The format of the timestamp field consists of: + Size: The number of bits (or octets) used to represent the packet timestamp field. + Units: The units used to represent the timestamp. If the timestamp is comprised of more than one field, the format of each field is specified. Epoch: The origin of the timescale used for the timestamp; the moment in time used as a reference for the timestamp value. Wraparound: The wraparound period of the timestamp. Any further wraparound- related considerations should be described here. Mizrahi, et al. Expires December 29, 2017 [Page 3] Internet-Draft Packet Timestamps June 2017 Synchronization aspects: Any assumptions or requirements related to synchronization should be specified, for example, whether it is assumed that nodes populating the timestamps should be synchronized, and whether the timestamp is measured with respect to a central reference clock such as a stratum 1 NTP server. 4. Recommended Timestamp Formats This memo recommends to use one of the three timestamp formats specified below. In cases where the three timestamp formats below do not satisfy the protocol requirements, the timestamp specification should clearly state the reasons for defining a new format. Clearly, different network protocols (and the use cases they serve) may have different requirements and constraints, and consequently may use different timestamp formats. The choice of the specific timestamp format for a given protocol may depend on a various factors. A few examples of factors that may affect the choice of the timestamp format: o Timestamp size: while some network protocols may allow a large timestamp fields, in other cases there may be constraints with respect to the timestamp size, affecting the choice of the timestamp format. o Resolution: the time resolution is another factor that may directly affect the selected timestamp format. Similarly, the wraparound periodicity of the timestamp may also affect the selected format. o Common format for multiple protocols: if there are two or more network protocols that use timestamps and are often used together in typical systems, using a common timestamp format should be preferred if possible. 4.1. NTP Timestamp Formats 4.1.1. NTP 64-bit Timestamp Format The Network Time Protocol (NTP) 64-bit timestamp format is defined in [RFC5905]. This timestamp format is used in several network protocols, including [RFC6374], [RFC4656], and [RFC5357]. Since this timestamp format is used in NTP, this timestamp format should be preferred in network protocols that are typically deployed in concert with NTP. Mizrahi, et al. Expires December 29, 2017 [Page 4] Internet-Draft Packet Timestamps June 2017 The format is presented in this section according to the template defined in Section 3. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Seconds | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Fraction | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1: NTP [RFC5905] 64-bit Timestamp Format Timestamp field format: Seconds: specifies the integer portion of the number of seconds since the epoch. + Size: 32 bits. + Units: seconds. Fraction: specifies the fractional portion of the number of seconds since the epoch. + Size: 32 bits. + Units: the unit is 2^(-32) seconds, which is roughly equal to 233 picoseconds. Epoch: The epoch is 1 January 1900 at 00:00 UTC. Wraparound: This time format wraps around every 2^32 seconds, which is roughly 136 years. The next wraparound will occur in the year 2036. Synchronization aspects: The timestamp format itself does not place a requirement on the degree of synchronization between nodes; such requirements emerge from the protocol and use cases served. Note that if the nodes that use this timestamp format use NTP-based synchronization, the timestamp may be derived from the NTP-synchronized clock, allowing Mizrahi, et al. Expires December 29, 2017 [Page 5] Internet-Draft Packet Timestamps June 2017 the timestamp to be measured with respect to the clock of an NTP server. 4.1.2. NTP 32-bit Timestamp Format The Network Time Protocol (NTP) 32-bit timestamp format is defined in [RFC5905]. This timestamp format is used in [I-D.morton-ippm-mbm-registry]. This timestamp format should be preferred in network protocols that are typically deployed in concert with NTP. The 32-bit format can be used either when space constraints do not allow the use of the 64-bit format, or when the 32-bit format satisfies the resolution and wraparound requirements. The format is presented in this section according to the template defined in Section 3. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Seconds | Fraction | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2: NTP [RFC5905] 32-bit Timestamp Format Timestamp field format: Seconds: specifies the integer portion of the number of seconds since the epoch. + Size: 16 bits. + Units: seconds. Fraction: specifies the fractional portion of the number of seconds since the epoch. + Size: 16 bits. + Units: the unit is 2^(-16) seconds, which is roughly equal to 15.3 microseconds. Epoch: The epoch is 1 January 1900 at 00:00 UTC. Wraparound: Mizrahi, et al. Expires December 29, 2017 [Page 6] Internet-Draft Packet Timestamps June 2017 This time format wraps around every 2^16 seconds, which is roughly 18 hours. Synchronization aspects: The timestamp format itself does not place a requirement on the degree of synchronization between nodes; such requirements emerge from the protocol and use cases served. Note that if the nodes that use this timestamp format use NTP-based synchronization, the timestamp may be derived from the NTP-synchronized clock, allowing the timestamp to be measured with respect to the clock of an NTP server. 4.2. The PTP Concatenated Timestamp Format The Precision Time Protocol (PTP) [IEEE1588] uses an 80-bit timestamp format. The concatenated timestamp format is a 64-bit field, which is the 64 least significant bits of the 80-bit PTP timestamp. Since this timestamp format is similar to the one used in PTP, this timestamp format should be preferred in network protocols that are typically deployed in PTP-capable devices. The PTP concatenated timestamp format is used in several protocols, such as [RFC6374], [RFC7456], [RFC8186] and [ITU-T-Y.1731]. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Seconds | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Nanoseconds | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 3: PTP [IEEE1588] Concatenated Timestamp Format Timestamp field format: Seconds: specifies the integer portion of the number of seconds since the epoch. + Size: 32 bits. + Units: seconds. Nanoseconds: specifies the fractional portion of the number of seconds since the epoch. Mizrahi, et al. Expires December 29, 2017 [Page 7] Internet-Draft Packet Timestamps June 2017 + Size: 32 bits. + Units: nanoseconds. The value of this field is in the range 0 to (10^9)-1. Epoch: The PTP [IEEE1588] epoch is 1 January 1970 00:00:00 TAI, which is 31 December 1969 23:59:51.999918 UTC. Wraparound: This time format wraps around every 2^32 seconds, which is roughly 136 years. The next wraparound will occur in the year 2106. Synchronization aspects: The timestamp format itself does not place a requirement on the degree of synchronization between nodes; such requirements emerge from the protocol and use cases served. Note that if the nodes that use this timestamp format use PTP-based synchronization, the timestamp may be derived from the PTP-synchronized clock, allowing the timestamp to be measured with respect to the clock of an PTP Grandmaster clock. 5. Packet Timestamp Control Field In some cases it is desirable to have a control field that includes information about the timestamp format. This section defines a recommended format of a timestamp-related control field that is intended for network protocols that require such timestamp-related control information. The recommended control field includes the following sub-fields: o Timestamp format. o Precision - the resolution or granularity of the system clock. o Epoch. o Era - the number of times the time has wrapped around since the epoch. Mizrahi, et al. Expires December 29, 2017 [Page 8] Internet-Draft Packet Timestamps June 2017 6. IANA Considerations This memo includes no request to IANA. 7. Security Considerations A network protocol that uses a packet timestamp MUST specify the security considerations that result from using the timestamp. This section provides an overview of some of the common security considerations of using timestamps. Any metadata that is attached to control or data packets, and specifically packet timestamps, can facilitate network reconnaissance; by passively eavesdropping to timestamped packets an attacker can gather information about the network performance, and about the level of synchronization between nodes. Timestamps can be spoofed or modified by on-path attackers, thus attacking the application that uses the timestamps. For example, if timestamps are used in a delay measurement protocol, an attacker can modify en route timestamps in a way that manipulates the measurement results. Integrity protection mechanisms, such as Hashed Message Authentication Codes (HMAC), can mitigate such attacks. The specification of an integrity protection mechanism is outside the scope of this document, as typically integrity protection will be defined on a per-network-protocol basis, and not specifically for the timestamp field. Another potential threat that can have a similar impact is delay attacks. An attacker can maliciously delay some or all of the en route messages, with the same harmful implications as described in the previous paragraph. Mitigating delay attacks is a significant challenge; in contrast to spoofing and modification attacks, the delay attack cannot be prevented by cryptographic integrity protection mechanisms. In some cases delay attacks can be mitigated by sending the timestamped information through multiple paths, allowing to detect and to be resilient to an attacker that has access to one of the paths. In many cases timestamping relies on an underlying synchronization mechanism. Thus, any attack that compromises the synchronization mechanism can also compromise protocols that use timestamping. Attacks on time protocols are discussed in detail in [RFC7384]. Mizrahi, et al. Expires December 29, 2017 [Page 9] Internet-Draft Packet Timestamps June 2017 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, <http://www.rfc-editor.org/info/rfc2119>. 8.2. Informative References [I-D.morton-ippm-mbm-registry] Morton, A. and M. Mathis, "Initial Performance Metric Registry Entries Part 2: MBM", draft-morton-ippm-mbm- registry-01 (work in progress), March 2017. [IEEE1588] IEEE, "IEEE 1588 Standard for a Precision Clock Synchronization Protocol for Networked Measurement and Control Systems Version 2", 2008. [ITU-T-Y.1731] ITU-T, "OAM functions and mechanisms for Ethernet based Networks", 2013. [RFC1323] Jacobson, V., Braden, R., and D. Borman, "TCP Extensions for High Performance", RFC 1323, DOI 10.17487/RFC1323, May 1992, <http://www.rfc-editor.org/info/rfc1323>. [RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet: Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002, <http://www.rfc-editor.org/info/rfc3339>. [RFC4656] Shalunov, S., Teitelbaum, B., Karp, A., Boote, J., and M. Zekauskas, "A One-way Active Measurement Protocol (OWAMP)", RFC 4656, DOI 10.17487/RFC4656, September 2006, <http://www.rfc-editor.org/info/rfc4656>. [RFC5357] Hedayat, K., Krzanowski, R., Morton, A., Yum, K., and J. Babiarz, "A Two-Way Active Measurement Protocol (TWAMP)", RFC 5357, DOI 10.17487/RFC5357, October 2008, <http://www.rfc-editor.org/info/rfc5357>. [RFC5646] Phillips, A., Ed. and M. Davis, Ed., "Tags for Identifying Languages", BCP 47, RFC 5646, DOI 10.17487/RFC5646, September 2009, <http://www.rfc-editor.org/info/rfc5646>. Mizrahi, et al. Expires December 29, 2017 [Page 10] Internet-Draft Packet Timestamps June 2017 [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, <http://www.rfc-editor.org/info/rfc5905>. [RFC6374] Frost, D. and S. Bryant, "Packet Loss and Delay Measurement for MPLS Networks", RFC 6374, DOI 10.17487/RFC6374, September 2011, <http://www.rfc-editor.org/info/rfc6374>. [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", RFC 6991, DOI 10.17487/RFC6991, July 2013, <http://www.rfc-editor.org/info/rfc6991>. [RFC7384] Mizrahi, T., "Security Requirements of Time Protocols in Packet Switched Networks", RFC 7384, DOI 10.17487/RFC7384, October 2014, <http://www.rfc-editor.org/info/rfc7384>. [RFC7456] Mizrahi, T., Senevirathne, T., Salam, S., Kumar, D., and D. Eastlake 3rd, "Loss and Delay Measurement in Transparent Interconnection of Lots of Links (TRILL)", RFC 7456, DOI 10.17487/RFC7456, March 2015, <http://www.rfc-editor.org/info/rfc7456>. [RFC7493] Bray, T., Ed., "The I-JSON Message Format", RFC 7493, DOI 10.17487/RFC7493, March 2015, <http://www.rfc-editor.org/info/rfc7493>. [RFC8186] Mirsky, G. and I. Meilik, "Support of the IEEE 1588 Timestamp Format in a Two-Way Active Measurement Protocol (TWAMP)", RFC 8186, DOI 10.17487/RFC8186, June 2017, <http://www.rfc-editor.org/info/rfc8186>. Authors' Addresses Tal Mizrahi Marvell 6 Hamada st. Yokneam Israel Email: talmi@marvell.com Mizrahi, et al. Expires December 29, 2017 [Page 11] Internet-Draft Packet Timestamps June 2017 Joachim Fabini Vienna University of Technology Gusshausstrasse 25/E389 Vienna 1040 Austria Phone: +43 1 58801 38813 Fax: +43 1 58801 38898 Email: Joachim.Fabini@tuwien.ac.at URI: http://www.tc.tuwien.ac.at/about-us/staff/joachim-fabini/ Al Morton AT&T Labs 200 Laurel Avenue South Middletown,, NJ 07748 USA Phone: +1 732 420 1571 Fax: +1 732 368 1192 Email: acmorton@att.com URI: http://home.comcast.net/~acmacm/ Mizrahi, et al. Expires December 29, 2017 [Page 12]