Network Working Group T. Mizrahi Internet-Draft Marvell Intended status: Informational J. Fabini Expires: September 6, 2018 Vienna University of Technology A. Morton AT&T Labs March 5, 2018 Guidelines for Defining Packet Timestamps draft-ietf-ntp-packet-timestamps-01 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 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 September 6, 2018. Copyright Notice Copyright (c) 2018 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 September 6, 2018 [Page 1] Internet-Draft Packet Timestamps March 2018 (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. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 2.2. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 3 2.3. Terms used in this Document . . . . . . . . . . . . . . . 4 3. Packet Timestamp Specification Template . . . . . . . . . . . 4 4. Recommended Timestamp Formats . . . . . . . . . . . . . . . . 5 4.1. Using a Recommended Timestamp Format . . . . . . . . . . 6 4.2. NTP Timestamp Formats . . . . . . . . . . . . . . . . . . 6 4.2.1. NTP 64-bit Timestamp Format . . . . . . . . . . . . . 6 4.2.2. NTP 32-bit Timestamp Format . . . . . . . . . . . . . 8 4.3. The PTP Truncated Timestamp Format . . . . . . . . . . . 9 5. Synchronization Aspects . . . . . . . . . . . . . . . . . . . 10 6. Timestamp Use Cases . . . . . . . . . . . . . . . . . . . . . 11 6.1. Example 1 . . . . . . . . . . . . . . . . . . . . . . . . 12 6.2. Example 2 . . . . . . . . . . . . . . . . . . . . . . . . 12 7. Packet Timestamp Control Field . . . . . . . . . . . . . . . 12 7.1. High-level Control Field Requirements . . . . . . . . . . 13 7.2. Control Field Categories . . . . . . . . . . . . . . . . 14 7.3. Control Field Features and Elements . . . . . . . . . . . 15 7.3.1. Timestamp Format . . . . . . . . . . . . . . . . . . 16 7.3.2. Timestamp Format Specification . . . . . . . . . . . 16 7.3.3. Timestamp Precision . . . . . . . . . . . . . . . . . 17 7.3.4. Timestamp Timescale . . . . . . . . . . . . . . . . . 17 7.3.5. Timestamp Leap Second . . . . . . . . . . . . . . . . 17 7.3.6. Reference Clock . . . . . . . . . . . . . . . . . . . 18 7.3.7. Provable Signature . . . . . . . . . . . . . . . . . 18 7.3.8. Custom Extension . . . . . . . . . . . . . . . . . . 18 7.4. Control Field Payload Definition . . . . . . . . . . . . 19 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 9. Security Considerations . . . . . . . . . . . . . . . . . . . 19 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 20 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 11.1. Normative References . . . . . . . . . . . . . . . . . . 20 11.2. Informative References . . . . . . . . . . . . . . . . . 20 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 Mizrahi, et al. Expires September 6, 2018 [Page 2] Internet-Draft Packet Timestamps March 2018 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 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] TAI International Atomic Time UTC Coordinated Universal Time Mizrahi, et al. Expires September 6, 2018 [Page 3] Internet-Draft Packet Timestamps March 2018 2.3. Terms used in this Document Timestamp error: The difference between the timestamp value at the device under test and the value of a reference clock at the same time instant. Timestamp format: The specification of a timestamp, which is represented by a set of attributes that unambiguously define the syntax and semantics of a timestamp. Timestamp accuracy: The mean over an ensemble of measurements of the timestamp error. Timestamp precision: The variation over an ensemble of measurements of the timestamp error. Timestamp resolution: The minimal time unit used for representing the timestamp. 3. Packet Timestamp Specification Template This memo recommends to use the timestamp formats defined in Section 4. In cases where these timestamp formats do not satisfy the protocol requirements, the timestamp specification should clearly state the reasons for defining a new format. Moreover, it is recommended to derive the new timestamp format from an existing timestamp format, either a timestamp format from this memo, or any other previously defined timestamp format. The timestamp specification must unambiguously define the syntax and the semantics of the timestamp. The current section defines the minimum set of attributes, but it should be noted that in some cases additional attributes or aspects will need to be defined in the timestamp specification. This section defines a template for specifying packet timestamps. A timestamp format specification MUST include at least the following aspects: Timestamp syntax: The structure of the timestamp field consists of: + Size: The number of bits (or octets) used to represent the packet timestamp field. If the timestamp is comprised of more than one field, the size of each field is specified. Mizrahi, et al. Expires September 6, 2018 [Page 4] Internet-Draft Packet Timestamps March 2018 Timestamp semantics: + Units: The units used to represent the timestamp. If the timestamp is comprised of more than one field, the units of each field are specified. + Resolution: The timestamp resolution; the resolution is equal to the timestamp field unit. If the timestamp consists of two or more fields using different time units, then the resolution is the smallest time unit. + Wraparound: The wraparound period of the timestamp; any further wraparound-related considerations should be described here. + Epoch: The origin of the timescale used for the timestamp; the moment in time used as a reference for the timestamp value. For example, the epoch may be based on a standard time scale, such as UTC. Another example is a relative timestamp, in which the epoch is the time at which the device using the timestamp was powered up, and is not affected by leap seconds (see the next attribute). + Leap seconds: This subsection specifies whether the timestamp is affected by leap seconds. If the timestamp is affected by leap seconds, then it represents the time elapsed since the epoch minus the number of leap seconds that have occurred since the epoch. 4. Recommended Timestamp Formats This memo defines a set of recommended timestamp formats. Defining a relatively small set of recommended formats enables significant reuse; for example, a network protocol may reuse the NTP or PTP timestamp format, allowing a straightforward integration with an NTP or a PTP-based timer. Moreover, since accurate timestamping mechanisms are often implemented in hardware, a new network protocol that reuses an existing timestamp format can be quickly deployed using existing hardware timestamping capabilities. This memo recommends to use one of the timestamp formats specified below. Clearly, different network protocols 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 use a large timestamp field, in some cases there may be constraints with respect to the timestamp size, affecting the choice of the timestamp format. Mizrahi, et al. Expires September 6, 2018 [Page 5] Internet-Draft Packet Timestamps March 2018 o Resolution: the time resolution is another factor that may directly affect the selected timestamp format. A potentially important factor in this context is extensibility; it may be desirable to allow a timestamp format to be extensible to a higher resolution by extending the field. For example, the resolution of the NTP 32-bit timestamp format can be improved by extending it to the NTP 64-bit timestamp format in a straightforward way. o Wraparound period: the length of the time interval in which the timestamp is unique may also be an important factor in choosing the timestamp format. Along with the timestamp resolution, these two factors determine the required number of bits in the timestamp. 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. Specifically, if the network protocol that is being defined typically runs on a PC, then an NTP-based timestamp format may allow easier integration with an NTP- synchronized timer. In contrast, a protocol that is typically deployed on a hardware-based platform, may make better use of a PTP-based timestamp, allowing more efficient integration with a PTP-synchronized timer. 4.1. Using a Recommended Timestamp Format A specification that uses one of the recommended timestamp formats should specify explicitly that this is a recommended timestamp format, and point to the relevant section in the current memo. 4.2. NTP Timestamp Formats 4.2.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. The format is presented in this section according to the template defined in Section 3. Mizrahi, et al. Expires September 6, 2018 [Page 6] Internet-Draft Packet Timestamps March 2018 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. Leap seconds: This timestamp format is affected by leap seconds. The timestamp represents the number of seconds elapsed since the epoch minus the number of leap seconds. Resolution: The resolution is 2^(-32) seconds. Wraparound: This time format wraps around every 2^32 seconds, which is roughly 136 years. The next wraparound will occur in the year 2036. Mizrahi, et al. Expires September 6, 2018 [Page 7] Internet-Draft Packet Timestamps March 2018 4.2.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.ietf-ippm-initial-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. Leap seconds: This timestamp format is affected by leap seconds. The timestamp represents the number of seconds elapsed since the epoch minus the number of leap seconds. Mizrahi, et al. Expires September 6, 2018 [Page 8] Internet-Draft Packet Timestamps March 2018 Resolution: The resolution is 2^(-16) seconds. Wraparound: This time format wraps around every 2^16 seconds, which is roughly 18 hours. 4.3. The PTP Truncated Timestamp Format The Precision Time Protocol (PTP) [IEEE1588] uses an 80-bit timestamp format. The truncated 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 truncated 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] Truncated 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. + Size: 32 bits. + Units: nanoseconds. The value of this field is in the range 0 to (10^9)-1. Mizrahi, et al. Expires September 6, 2018 [Page 9] Internet-Draft Packet Timestamps March 2018 Epoch: The PTP [IEEE1588] epoch is 1 January 1970 00:00:00 TAI, which is 31 December 1969 23:59:51.999918 UTC. Leap seconds: This timestamp format is not affected by leap seconds. Resolution: The resolution is 1 nanosecond. Wraparound: This time format wraps around every 2^32 seconds, which is roughly 136 years. The next wraparound will occur in the year 2106. 5. Synchronization Aspects A specification that defines a new timestamp format or uses one of the recommended timestamp formats should include a section on Synchronization Aspects. Examples of such a section can be found in Section 6). The Synchronization Aspects section should specify all the assumptions and requirements related to synchronization. For example, the synchronization aspects may specify whether nodes populating the timestamps should be synchronized among themselves, and whether the timestamp is measured with respect to a central reference clock such as an NTP server. If time is assumed to be synchronized to a time standard such as UTC or TAI, it should be specified in this section. Further considerations may be discussed in this section, such as the required timestamp accuracy. Another aspect that should be discussed in this section is leap second [RFC5905] considerations. The timestamp specification template (Section 3) specifies whether the timestamp is affected by leap seconds. It is often the case that further details about leap seconds will need to be defined in the Synchronization Aspects section. Generally speaking, in a timekeeping system that considers leap seconds, the system clock may be affected by a leap second in one of three possible ways: o The clock is turned backwards one second at the end of the leap second. o The clock is frozen during the duration of the leap second. Mizrahi, et al. Expires September 6, 2018 [Page 10] Internet-Draft Packet Timestamps March 2018 o The clock is slowed down during and slightly after the duration of the leap second, until the new time value catches up. The way leap seconds are handled depends on the synchronization protocol, and is thus not specified in this document. However, if a timestamp format is defined with respect to a timescale that is affected by leap seconds, the Synchronization Aspects section should specify how the use of leap seconds affects the timestamp usage. 6. Timestamp Use Cases Packet timestamps are used in various network protocols. Typical applications of packet timestamps include delay measurement, clock synchronization, and others. The following table presents a (non- exhaustive) list of protocols that use packet timestamps, and the timestamp formats used in each of these protocols. +------------------+-----------------------------------+-----------+ | | Recommended formats | Other | +------------------+-----------+-----------+-----------+ format | | Protocol |NTP 64-bit |NTP 32-bit |PTP Trunc. | | +------------------+-----------+-----------+-----------+-----------+ | NTP [RFC5905] | + | | | | +------------------+-----------+-----------+-----------+-----------+ | OWAMP [RFC4656] | + | | | | +------------------+-----------+-----------+-----------+-----------+ | TWAMP [RFC5357] | + | | | | | TWAMP [RFC8186] | | | + | | +------------------+-----------+-----------+-----------+-----------+ | TRILL [RFC7456] | | | + | | +------------------+-----------+-----------+-----------+-----------+ | MPLS [RFC6374] | | | + | | +------------------+-----------+-----------+-----------+-----------+ | TCP [RFC1323] | | | | + | +------------------+-----------+-----------+-----------+-----------+ | RTP [RFC3550] | + | | | + | +------------------+-----------+-----------+-----------+-----------+ | [I-D.ietf-ippm- | + | + | | | | initial-registry]| | | | | +------------------+-----------+-----------+-----------+-----------+ Figure 4: Protocols that use Packet Timestamps The rest of this section presents two hypothetic examples of network protocol specifications that use one of the recommended timestamp formats. The examples include the text that specifies the information related to the timestamp format. Mizrahi, et al. Expires September 6, 2018 [Page 11] Internet-Draft Packet Timestamps March 2018 6.1. Example 1 Timestamp: The timestamp format used in this specification is the NTP [RFC5905] 64-bit format, as specified in Section 4.2.1 of [I-D.ietf-ntp-packet-timestamps]. Synchronization aspects: It is assumed that nodes that run this protocol are synchronized to UTC using a synchronization mechanism that is outside the scope of this document. In typical deployments this protocol will run on a machine that uses NTP [RFC5905] for synchronization. Thus, 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. Since the NTP time format is affected by leap seconds, the current timestamp format is similarly affected. Thus, the value of a timestamp during or slightly after a leap second may be temporarily inaccurate. 6.2. Example 2 Timestamp: The timestamp format used in this specification is the PTP [IEEE1588] Truncated format, as specified in Section 4.2.3 of [I-D.ietf-ntp-packet-timestamps]. Synchronization aspects: It is assumed that nodes that run this protocol are synchronized among themselves. Nodes may be synchronized to a global reference time. Note that if PTP [IEEE1588] is used for 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. 7. Packet Timestamp Control Field In some cases it is desirable to have a control field that includes information about the timestamp format. Control information about the timestamp format can be conveyed in some protocols using a dedicated control plane protocol, or may be made available at the management plane, for example using a YANG data model. The optional control field that is defined in this section allows some of the control information to be attached to the timestamp. This section defines requirements and a recommended format of a timestamp-related Mizrahi, et al. Expires September 6, 2018 [Page 12] Internet-Draft Packet Timestamps March 2018 control field that is intended for network protocols that can benefit from such timestamp-related control information. 7.1. High-level Control Field Requirements A control field for packet timestamps must offer an adequate feature set and fulfill a series of requirements to be usable and accepted. The following list captures the main high-level requirements for timestamp fields. 1. Extensible Feature Set: protocols and applications depend on various timestamp characteristics. A timestamp control field must support a variable number of elements (components) that either describe or quantify timestamp-specific characteristics or parameters. Examples of potential elements include timestamp accuracy, leap seconds, reference clock identifiers, etc. 2. Size: Essential for an efficient use of timestamp control fields is the trade-off between supported features and control field size. Protocols and applications may select the specific control field elements that are needed for their operation from the set of available elements. 3. Composition: Applications may depend on specific control field elements being present in messages. The status of these elements may be either mandatory, conditional mandatory, or optional, depending on the specific application and context. This memo must support applications in conveying or negotiating (a) the set of control field elements along with (b) the status of any element (i.e., mandatory, conditional mandatory, or optional) by defining appropriate data structures and identity codes. 4. Category: Control field elements can characterize either static timestamp information (like, e.g., timestamp size in bytes and timestamp semantics: NTP 64 bit format) or runtime timestamp information (like, e.g., estimated timestamp accuracy at the time of sampling: 20 microseconds to UTC). For efficiency reason it is meaningful to support separation of these two concepts: while the former (static) information is typically valid throughout a protocol session and may be conveyed only once, at session establishment time, the latter (runtime) information augments any timestamp instance and may cause substantial overhead for high- traffic protocols. Mizrahi, et al. Expires September 6, 2018 [Page 13] Internet-Draft Packet Timestamps March 2018 7.2. Control Field Categories Depending on their characteristics, the elements or components of a timestamp control field can be assigned to one of two categories: Structure (static) or Instance (runtime). Aim of this categorization is to support minimum overhead of timestamp control fields in practice. Protocols may use structural elements once, at connection setup time to define or negotiate the timestamp structure and instace elements (repeatedly) to identify the quality of timestamp instances at runtime. 1. : static timestamp control field. The static control field identifies information like timestamp structure, type, size, or features, that characterize and are common to a set of related timestamps. Typical use of such a control field is at connection establishment time when protocols negotiate available and preferred timestamp types and features to be used for the lifetime of an association. For instance endpoints can specify the type, structure and size of the timestamp representation within protocol messages that will be exchanged as part of a following protocol session. These can be either standard timestamp formats like NTP 64 bit as specified by this memo or specific vendor-defined timestamp formats. 2. : runtime timestamp control field. Besides static information, dynamic (runtime) timestamp information is commonly available at the sender when sampling a specific timestamp instance. Typical examples include the ID of a clock that originated a specific timestamp, the estimated time synchronization accuracy of the local reference clock when sampling a specific timestamp, or the correction to apply due to an ongoing leap smear for a leap second. Moreover, with today's critical infrastructures depending increasingly on accurate time, provable signatures may become an essential runtime parameter to protect the integrity of timestamp and control field values. The accurate and reliable operation of timestamp receivers can benefit from this detailed runtime control field information that augments any single timestamp. Drawing analogies to programming languages, the static timestamp control field maps best to concepts like "type", "structure", or "template", whereas the runtime timestamp control field corresponds to "variables", i.e., runtime-instantiations of types. Main consequence is that static timestamp control fields may be exchanged only once during an ongoing association, saving substantial link capacity, whereas a runtime timestamp control field accompanies any single message or timestamp instance. Still, some protocols may prefer to augment any single timestamp instance with both, a static Mizrahi, et al. Expires September 6, 2018 [Page 14] Internet-Draft Packet Timestamps March 2018 and a runtime control field. Example use cases for the latter variant include potential support for heterogeneity in terms of timestamps - various clients can decide dynamically which timestamp format they send as part of the protocol - or to include a maximum of timestamp context for receivers in the case of sporadic messages. 7.3. Control Field Features and Elements The timestamp control field is composed of elements that can be selected from the following set: o Timestamp format o Timestamp format specification o Precision o Timescale o Leap second o Reference clock(s) o Probable signature o Custom extension o ... (tbd) The following subsections detail on the role of the elements, their structure and related constraints. Any element is characterized by the following parameters: o ID: o Type: Either : element defines static timestamp structure that can subsequently be used to describe several instances of timestamps - typically used once during connection setup, or : parameter characteristic to a specific timestamp instance. o Status: , , or . Note: interpretation of the status field depends on the value of the type field. If type is , then status means that this element must be part of any -type timestamp control field. However, it may be part of - type timestamp control field, too. Mizrahi, et al. Expires September 6, 2018 [Page 15] Internet-Draft Packet Timestamps March 2018 o Size: o Value: the value or subfields of this element o Comments: Additions and considerations for this element 7.3.1. Timestamp Format The timestamp format field defines the size and semantics of the timestamp that follows this timestamp control field by referencing appropriate IANA IDs. o ID: tbd o Type: o Status: o Size: tbd o Value: IANA identifier, referencing either a standard format defined by this memo or an alternate timestamp format (e.g. vendor-specific extension). In the latter case, a Timestamp Format Specification field is conditional mandatory. o Comments: 7.3.2. Timestamp Format Specification The timestamp format specification field defines the structure and size of custom timestamps and is needed whenever the use of standard timestamp formats is inappropriate. o ID: tbd o Type: o Status: . This field must be included whenever the "timestamp format" element references non-standard timestamp formats and must not be included into the control field otherwise. o Size: tbd o Value: Subfields: 1. Timestamp size; 2. User- or vendor-specific id and 3. Sub-id that allow to uniquely identify this timestamp type; Mizrahi, et al. Expires September 6, 2018 [Page 16] Internet-Draft Packet Timestamps March 2018 o Comments: 7.3.3. Timestamp Precision The precision field value stores the precision of the clock that originated the timestamp at the time when the timestamp was sampled along with attributes that characterize the timestamp quality (like absolute or relative synchronization, reference clock identifiers, etc.) o ID: tbd o Type: (optionally: when the clock originating the timestamps has maximum limits for precision)? o Status: . The local system may or may not know the precision (or accuracy) of its clock and sampled timestamps. o Size: tbd o Value: Subfields: 1. Estimated Precision (in terms of 10^(-x)), 2. Maximum Error, 3. Reference (Absolute: UTC, TAI ..., Relative: to specific clock, needs reference to clock ID) o Comments: NTF calls this "error". 7.3.4. Timestamp Timescale The timescale field denotes Epoch and Era of the timestamp o ID: tbd o Type: o Status: o Size: tbd o Value: Subfields: 1. epoch 2. era o Comments: 7.3.5. Timestamp Leap Second o ID: tbd o Type: Mizrahi, et al. Expires September 6, 2018 [Page 17] Internet-Draft Packet Timestamps March 2018 o Status: o Size: tbd o Value: Subfields: 1. Leap second ongoing 2. Considered leap second fraction (during leap smear) o Comments: 7.3.6. Reference Clock o ID: tbd o Type: (perhaps , too) o Status: o Size: tbd o Value: Subfields: 1. Reference clock type 2. Unique reference clock ID o Comments: 7.3.7. Provable Signature o ID: tbd o Type: o Status: o Size: tbd o Value: Signature covering the entire timstamp control field and the timestamp field, masking out the provable signature field with 0. o Comments: 7.3.8. Custom Extension o ID: tbd o Type: or o Status: Mizrahi, et al. Expires September 6, 2018 [Page 18] Internet-Draft Packet Timestamps March 2018 o Size: tbd o Value: tbd o Comments: For future extensions 7.4. Control Field Payload Definition This section defines the binding format of timestamp control (sub)fields to be used by protocols. (tbd) 8. IANA Considerations This memo includes no request to IANA. 9. 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, Mizrahi, et al. Expires September 6, 2018 [Page 19] Internet-Draft Packet Timestamps March 2018 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]. 10. Acknowledgments The authors thank Yaakov Stein, Greg Mirsky, Warner Losh, Rodney Cummings and other members of the NTP working group for many helpful comments. The authors gratefully acknowlege Harlan Stenn and the people from the Network Time Foundation for sharing their thoughts and ideas. 11. References 11.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, . 11.2. Informative References [I-D.ietf-ippm-initial-registry] Morton, A., Bagnulo, M., Eardley, P., and K. D'Souza, "Initial Performance Metric Registry Entries", draft-ietf- ippm-initial-registry-06 (work in progress), March 2018. [I-D.ietf-ntp-packet-timestamps] Mizrahi, T., Fabini, J., and A. Morton, "Guidelines for Defining Packet Timestamps", draft-ietf-ntp-packet- timestamps-00 (work in progress), October 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. Mizrahi, et al. Expires September 6, 2018 [Page 20] Internet-Draft Packet Timestamps March 2018 [RFC1323] Jacobson, V., Braden, R., and D. Borman, "TCP Extensions for High Performance", RFC 1323, DOI 10.17487/RFC1323, May 1992, . [RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet: Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002, . [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, July 2003, . [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, . [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, . [RFC5646] Phillips, A., Ed. and M. Davis, Ed., "Tags for Identifying Languages", BCP 47, RFC 5646, DOI 10.17487/RFC5646, September 2009, . [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, . [RFC6374] Frost, D. and S. Bryant, "Packet Loss and Delay Measurement for MPLS Networks", RFC 6374, DOI 10.17487/RFC6374, September 2011, . [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", RFC 6991, DOI 10.17487/RFC6991, July 2013, . [RFC7384] Mizrahi, T., "Security Requirements of Time Protocols in Packet Switched Networks", RFC 7384, DOI 10.17487/RFC7384, October 2014, . Mizrahi, et al. Expires September 6, 2018 [Page 21] Internet-Draft Packet Timestamps March 2018 [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, . [RFC7493] Bray, T., Ed., "The I-JSON Message Format", RFC 7493, DOI 10.17487/RFC7493, March 2015, . [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, . Authors' Addresses Tal Mizrahi Marvell 6 Hamada st. Yokneam Israel Email: talmi@marvell.com 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 September 6, 2018 [Page 22]