RFC 8877

Guidelines for Defining Packet Timestamps

📅 published September 2020, from ietf

RFC 8877: Guidelines for Defining Packet Timestamps 💖

  • Number: RFC 8877
  • Category: Informational (published for information, not as a Standards Track spec 🤓)
  • ISSN: 2070-1721
  • Authors: T. Mizrahi (Huawei), J. Fabini (TU Wien), A. Morton (AT&T Labs)
  • Date: September 2020
  • Obsoletes / Updates: The title block doesn't list anything it obsoletes or updates ✨

Abstract

okay so, lots of network protocols stick a binary-encoded timestamp right into the packet format. this doc calls those "packet timestamps" for short 🦋 it gives guidelines for defining packet timestamp formats in protocols at all the different layers, and it presents three recommended timestamp formats 💅 the main audience is network protocol designers. a new protocol that needs a packet timestamp will, in most cases, just use one of the recommended formats. if none of them fit, the new protocol spec should define its own format by following the guidelines here 🌸

Status of This Memo

this doc is not an Internet Standards Track spec, it's published for informational purposes 🎀

it's a product of the Internet Engineering Task Force (IETF) and it reflects the consensus of the IETF community. it got public review and was approved for publication by the Internet Engineering Steering Group (IESG). not every IESG-approved doc is a candidate for any level of Internet Standard, so see Section 2 of RFC 7841 for that 🫶

for the current status, any errata, and how to send feedback, check https://www.rfc-editor.org/info/rfc8877 ✨

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

this doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) as they stand on the publication date. please actually read those, because they spell out your rights and restrictions for this doc 🧐 any Code Components pulled out of this doc must include the Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions, and they come with no warranty, as the Simplified BSD License says 💜

Table of Contents

1.  Introduction
  1.1.  Background
  1.2.  Scope of this Document
  1.3.  How to Use This Document
2.  Terminology
  2.1.  Requirements Language
  2.2.  Abbreviations
  2.3.  Terms Used in This Document
3.  Packet Timestamp Specification Template
4.  Recommended Timestamp Formats
  4.1.  Using a Recommended Timestamp Format
  4.2.  NTP Timestamp Formats
    4.2.1.  NTP 64-Bit Timestamp Format
    4.2.2.  NTP 32-Bit Timestamp Format
  4.3.  The PTP Truncated Timestamp Format
5.  Synchronization Aspects
6.  Timestamp Use Cases
  6.1.  Example 1
  6.2.  Example 2
7.  Packet Timestamp Control Field
  7.1.  High-Level Control Field Requirements
8.  IANA Considerations
9.  Security Considerations
10. References
  10.1.  Normative References
  10.2.  Informative References
Acknowledgments
Authors' Addresses

1. Introduction ✨

1.1. Background

timestamps are everywhere in network protocols 🕰️ they're used for logging or reporting when something happened, for messages in delay measurement and clock synchronization protocols, and as part of a value that's unlikely to repeat (a nonce) in security protocols 💖

in the RFC series, timestamps show up in one of two forms: text-based timestamps and packet timestamps 🎀 text-based timestamps [RFC3339] are user-friendly strings and they're all over the RFC series, like in information objects and data models, e.g., [RFC5646], [RFC6991], and [RFC7493]. packet timestamps are different: they're a compact binary field with a fixed size, and they aren't meant to be human-friendly 🤖 they're super common too, for measuring delay and syncing clocks, e.g., [RFC5905], [RFC4656], and [RFC7323] 🦋

1.2. Scope of this Document

this doc gives guidelines for defining a packet timestamp format in network protocols, and it presents three recommended timestamp formats 💅 a new protocol that needs a packet timestamp will, in most cases, use one of those recommended formats. sometimes a protocol might use more than one of them. but if none of the recommended formats fits the protocol's requirements, the new protocol spec should define the packet timestamp format following the guidelines in this doc 🌸

why only a small set of recommended formats? because it means big reuse 🔥 protocols can usually reuse the timestamp format of the Network Time Protocol (NTP) [RFC5905] or the Precision Time Protocol (PTP) [IEEE1588], which makes it easy to plug into an NTP- or PTP-based timer 🧚 and since accurate timestamping is often done in hardware, a new protocol that reuses an existing format can get deployed fast using the hardware timestamping that's already there ⭐

1.3. How to Use This Document

this doc is meant as a reference for network protocol designers 📖 when you're defining a protocol that uses a packet timestamp, check the recommended timestamp formats first (Section 4). if you use one of them, reference it along the lines of the examples in Sections 6.1 and 6.2. if none of the recommended formats does what you need, define a new timestamp format using the template in Section 3 👑

2. Terminology

2.1. Requirements Language

the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this doc are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here 🧠 so if you see them in lowercase, they're just regular words, no cap 💀

2.2. Abbreviations

NTP     Network Time Protocol [RFC5905]

PTP     Precision Time Protocol [IEEE1588]

TAI     International Atomic Time

UTC     Coordinated Universal Time

2.3. Terms Used in This Document

here are the terms, bestie 📚

Timestamp:             A value that represents a point in time,
                       corresponding to an event that occurred or is
                       scheduled to occur.

Timestamp error:       The difference between the timestamp value and
                       the value of a reference clock at the time of
                       the event that the timestamp was intended to
                       indicate.

Timestamp format:      The specification of a timestamp, which is
                       represented by a set of attributes that
                       unambiguously defines 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 section is basically the blueprint for writing your own timestamp format 📝 the doc recommends using the formats from Section 4. but if those don't cover your protocol's requirements, your timestamp spec should clearly say why you're defining a new one 🙈 it's also recommended to derive the new format from an existing one, either one from this doc or any other previously defined timestamp format 💜

your timestamp spec must unambiguously define the syntax and semantics of the timestamp, no vagueness allowed 🔍 this section sets out the minimum set of attributes, but heads up, in some cases you'll need to define extra attributes or aspects too 🎀

this section gives a template for specifying packet timestamps. a timestamp format spec MUST include at least the following aspects:

Timestamp syntax:

  • Size: the number of bits (or octets) used for the packet timestamp field. if the timestamp is made of more than one field, the size of each field is specified. network order (big endian) is assumed by default, and if that isn't the case, this section has to explicitly spell out the endianity 🌊

Timestamp semantics:

  • Units: the units used to represent the timestamp. if it's made of more than one field, each field's units are specified too. if a field is limited to a specific range of values, this section gives the permitted range 📏
  • Resolution: the timestamp resolution, which is equal to the timestamp field unit. if the timestamp has two or more fields using different time units, the resolution is the smallest time unit ⭐
  • Wraparound: the wraparound period of the timestamp. any other wraparound-related considerations should be described here too 🔄
  • Epoch: the origin of the timescale used for the timestamp, the moment in time used as the reference for the timestamp value 🕛 for example, the epoch may be based on a standard time scale, like UTC. another example is a relative timestamp, where the epoch could be the time the device using the timestamp was powered up, and that one is not affected by leap seconds (see the next attribute) 🔋
  • Leap seconds: this subsection says whether the timestamp is affected by leap seconds. if it is, the timestamp represents the time elapsed since the epoch minus the number of leap seconds that have occurred since the epoch 🧮

Synchronization aspects:

the spec for a network protocol that uses a packet timestamp is expected to cover the synchronization aspects of using that timestamp 🤝 these aren't strictly part of the timestamp format itself, but they give the context you need to use the timestamp within the protocol's scope ✨ sometimes timestamps get used without synchronization, like a timestamp that counts seconds since power-up. in those cases, the Synchronization Aspects section will say the timestamp doesn't correspond to a synchronized time reference, and it may discuss how that affects using the timestamp 🦋 more details on synchronization aspects are in Section 5 💖

that's the end of part 1, bestie! 🌈

okay so this section is literally the menu of timestamp formats the spec recommends 🫶 different protocols have different needs, so they might pick different formats, and there are a few things that help decide:

  • Timestamp size: some protocols have a big timestamp field, but sometimes there are limits on how big the timestamp can be, and that affects which format you pick 📏
  • Resolution: how fine-grained the time needs to be matters a lot 🔍 and it's extra cute if a format can be extended to a higher resolution by just making the field bigger. 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 💖
  • Wraparound period: this is how long the time interval is before the timestamp repeats and stops being unique ⏳ together with the resolution, this decides how many bits you need 🧮
  • Common format for multiple protocols: if two or more protocols get used together a lot, using a common timestamp format should be preferred if possible 🤝 like, if your protocol usually runs on a PC, an NTP-based format can make it easier to work with an NTP-synchronized timer ⏰. But a protocol that's usually deployed on a hardware-based platform might make better use of a PTP-based timestamp, which integrates more efficiently with a PTP-synchronized timer 🔧

okay, so if your spec uses one of these recommended formats, it should say explicitly that it's a recommended timestamp format 📣 and point to the right section of this document 🎀 no guessing for your reader, bestie 💅

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] 🌸 it's used in a bunch of protocols, including [RFC6374], [RFC4656], and [RFC5357] 👑 since it lives in NTP, it should be preferred in network protocols that usually get deployed alongside NTP 🫶

here's how the format is laid out, following the template from 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 64-Bit Timestamp Format

the timestamp field has two parts 🍓

  • Seconds: the integer portion of the number of seconds since the epoch.
    • Size: 32 bits.
    • Units: seconds.
  • Fraction: 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 🗓️

Note: as pointed out in [RFC5905], strictly speaking, UTC did not exist prior to 1 January 1972, but it is convenient to assume it has existed for all eternity 🙈 so the current epoch means the timestamp counts the seconds since 1 January 1972 at 00:00 UTC plus 2272060800, which is the number of seconds between 1 January 1900 and 1 January 1972 💜

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. so during and possibly before and/or after a leap second happens, the value of the timestamp may temporarily be ambiguous 😵‍💫 more on that in Section 5 🦋

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 🌈

4.2.2. NTP 32-Bit Timestamp Format

the NTP 32-bit timestamp format is also defined in [RFC5905] 🎀 it's used in [METRICS] and [NSHMD] 💅 this format should be preferred in network protocols that are typically deployed in concert with NTP. you'd use the 32-bit format either when space constraints don't allow the 64-bit format, or when the 32-bit format satisfies the resolution and wraparound requirements 🧁

here's the layout, following the Section 3 template 🧚

        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 32-Bit Timestamp Format

the timestamp field, again in two parts 🌸

  • Seconds: the integer portion of the number of seconds since the epoch.
    • Size: 16 bits.
    • Units: seconds.
  • Fraction: 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 🗓️

Note: as pointed out in [RFC5905], strictly speaking, UTC did not exist prior to 1 January 1972, but it is convenient to assume it has existed for all eternity 🙈 so the current epoch means the timestamp counts the seconds since 1 January 1972 at 00:00 UTC plus 2272060800, which is the number of seconds between 1 January 1900 and 1 January 1972 💜

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. so during and possibly before and/or after a leap second happens, the value of the timestamp may temporarily be ambiguous 😵‍💫 more on that in Section 5 🦋

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, made of the 64 least significant bits of the 80-bit PTP timestamp 💖 since it's similar to the one PTP uses, this timestamp format should be preferred in network protocols that are typically deployed in PTP-capable devices 🤖

the PTP truncated timestamp format was defined in [IEEE1588v1] and 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 Truncated Timestamp Format

the timestamp field, in two parts 👑

  • Seconds: the integer portion of the number of seconds since the epoch.
    • Size: 32 bits.
    • Units: seconds.
  • Nanoseconds: 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 🍭

Epoch: the PTP [IEEE1588] epoch is 1 January 1970 00:00:00 TAI 🧚

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 🕰️

okay so, any spec that invents a brand new timestamp format or borrows one of the recommended formats should have a Synchronization Aspects section 💅 this part is lowkey important. The recommended formats in this doc (Section 4) don't cover the syncing stuff themselves, but protocols that use them are expected to spell it out. For examples, peep Section 6 🦋

The Synchronization Aspects section should spell out every assumption and requirement about syncing 🫶 like, it can say whether the nodes filling in timestamps should be synced with each other, and whether the timestamp is measured against a central reference clock like an NTP server. If you're assuming time is synced to a standard like UTC or TAI, that goes here too. You can also talk about the required accuracy and precision of the timestamps ✨

Another thing this section should cover is leap second [RFC5905] considerations 🌈 The timestamp specification template (Section 3) tells you whether a timestamp is affected by leap seconds, and honestly you'll usually need to add more details about leap seconds in this section. So, a leap second is a one-second adjustment that's occasionally applied to UTC to keep it lined up with solar time. It can be positive or negative, meaning the clock might jump one second forward or backward. Every leap second so far (up to when this document was published) has been backward, and forward ones are theoretically possible, but the text here focuses on the common backward case 🙈 When a timekeeping system does account for leap seconds, the system clock can be affected in one of three ways:

  • The clock is turned backwards one second at the end of the leap second.
  • The clock is frozen during the duration of the leap second.
  • The clock is slowed down during the leap second and adjacent time intervals until the new time value catches up. The interval for this process, commonly referred to as "leap smear", can range from several seconds to several hours before, during, and/or after the occurrence of the leap second.

How leap seconds get handled depends on the synchronization protocol, so this document doesn't specify it 🤷‍♀️ BUT if a timestamp format is defined against a timescale that's affected by leap seconds, the Synchronization Aspects section should explain how leap seconds affect using that timestamp 💖

6. Timestamp Use Cases 🎀

okay the big picture: packet timestamps show up all over the place in network protocols. The usual gigs are delay measurement, clock synchronization, and a bunch of other stuff 😭 Here's a table (not a complete one, bestie) of protocols that use packet timestamps and the timestamp formats each one uses:

   +=================+======================================+=======+
   |                 |         Recommended Formats          | Other |
   +=================+============+============+============+=======+
   |     Protocol    | NTP 64-Bit | NTP 32-Bit | PTP Trunc. |       |
   +=================+============+============+============+=======+
   |  NTP [RFC5905]  |     +      |            |            |       |
   +-----------------+------------+------------+------------+-------+
   | OWAMP [RFC4656] |     +      |            |            |       |
   +-----------------+------------+------------+------------+-------+
   | TWAMP [RFC5357] |     +      |            |            |       |
   | TWAMP [RFC8186] |     +      |            |     +      |       |
   +-----------------+------------+------------+------------+-------+
   | TRILL [RFC7456] |            |            |     +      |       |
   +-----------------+------------+------------+------------+-------+
   |  MPLS [RFC6374] |            |            |     +      |       |
   +-----------------+------------+------------+------------+-------+
   |  TCP [RFC7323]  |            |            |            |   +   |
   +-----------------+------------+------------+------------+-------+
   |  RTP [RFC3550]  |     +      |            |            |   +   |
   +-----------------+------------+------------+------------+-------+
   | IPFIX [RFC7011] |            |            |            |   +   |
   +-----------------+------------+------------+------------+-------+
   |    BinaryTime   |            |            |            |   +   |
   |    [RFC6019]    |            |            |            |       |
   +-----------------+------------+------------+------------+-------+
   |    [METRICS]    |     +      |     +      |            |       |
   +-----------------+------------+------------+------------+-------+
   |     [NSHMD]     |            |     +      |     +      |       |
   +-----------------+------------+------------+------------+-------+

             Table 1: Protocols That Use Packet Timestamps

The rest of this section walks through two made-up (hypothetical) examples of network protocol specs that use one of the recommended timestamp formats 🧚 Each example includes the text that describes the timestamp format info.

6.1. Example 1 🌸

Here's the first one, verbatim:

   Timestamp:
      The timestamp format used in this specification is the NTP
      [RFC5905] 64-bit format, as described in Section 4.2.1 of RFC
      8877.

   Synchronization aspects:
      It is assumed that the 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 and
      possibly before and/or after a leap second may be temporarily
      inaccurate.

Basically, this example says the protocol uses the NTP 64-bit format and assumes nodes are synced to UTC by some mechanism outside this doc. Since NTP time is affected by leap seconds, timestamps can be a little off around a leap second 🙈

6.2. Example 2 🍓

And the second one:

   Timestamp:
      The timestamp format used in this specification is the PTP
      [IEEE1588] truncated format, as described in Section 4.3 of RFC
      8877.

   Synchronization aspects:
      It is assumed that the 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 a PTP grandmaster clock.

This one uses the PTP truncated format, and the nodes sync among themselves (maybe to a global reference time). If PTP is what's doing the syncing, the timestamp can be measured against a PTP grandmaster clock 👑

7. Packet Timestamp Control Field 💜

okay so sometimes it's really handy to have a control field that describes a timestamp's structure, format, content, and properties 😍 That control info can be carried in some protocols through a dedicated control plane protocol, or it can live in the management plane, for example using a YANG data model. An optional control field lets you attach some of that control info right to the timestamp.

One example is the Error Estimate field, defined in Section 4.1.2 of [RFC4656], which is used in the One-Way Active Measurement Protocol (OWAMP) [RFC4656] and Two-Way Active Measurement Protocol (TWAMP) [RFC5357]. The Root Dispersion and Root Delay fields in the NTP header [RFC5905] are two more examples of fields that tell you about timestamp precision 🎯 Then there's the Correction Field in the PTP header [IEEE1588]. Its value is used as a correction to the timestamp, and the sender of the PTP message can assign it, while transit nodes (Transparent Clocks) can update it to account for the delay along the path ✨

This section sets out high-level guidelines for defining packet timestamp control fields in network protocols that could benefit from that kind of timestamp info 💅 Heads up: the word "requirements" is used informally in this section, not as strict spec language 🫶

7.1. High-Level Control Field Requirements 🌈

A control field for packet timestamps must offer an adequate feature set and meet a bunch of requirements to be usable and accepted 😤 Here's the list of 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 size, encoding, accuracy, leap seconds, reference clock identifiers, etc. 🔥
  2. Size: Trading off supported features against control field size is essential for using timestamp control fields efficiently 🧠 Protocols and applications can pick the specific control field elements they need for their operation from the set of available elements.
  3. Composition: Applications may depend on specific control field elements being present in messages. Depending on the application and context, an element's status may be mandatory, conditional mandatory, or optional. A control field specification 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 describe either static timestamp info (e.g., timestamp size in bytes and timestamp semantics: NTP 64-bit format) or runtime timestamp info (e.g., estimated timestamp accuracy at the time of sampling: 20 microseconds to UTC) 💖 For efficiency, it can make sense to split these two concepts apart. The static info is typically valid for a whole protocol session, so it can be sent only once, at session establishment time. The runtime info goes along with every timestamp instance, which can add a lot of overhead for high-traffic protocols 😭

Proposals for timestamp control fields will be defined in separate documents and are out of scope of this document 🦋

8. IANA Considerations 🌸

This document has no IANA actions. 🫶

9. Security Considerations ✨

A network protocol that uses a packet timestamp MUST specify the security considerations that result from using the timestamp. okay so this section gives you an overview of the common security stuff that comes with timestamps 🔒💅

Any metadata that gets attached to control or data packets, and especially packet timestamps, can help with network reconnaissance 👀. If an attacker just passively eavesdrops on timestamped packets, they can figure out information about the network performance and how well the nodes are synchronized with each other. Not cute 😭

In some cases, timestamps could be spoofed or modified by on-path attackers, which means they're attacking the application that depends on those timestamps 💀. For example, if timestamps are used in a delay measurement protocol, an attacker can modify en route timestamps to mess with the measurement results. Integrity protection mechanisms, such as Message Authentication Codes (MACs), can help mitigate this kind of attack 🛡️. The specification of an integrity protection mechanism is outside the scope of this document, because integrity protection is typically defined per network protocol and not specifically for the timestamp field 🎀.

Another threat with a similar impact is the delay attack 🐢. An attacker can maliciously delay some or all of the en route messages, with the same harmful effects as in the previous paragraph. Mitigating delay attacks is a significant challenge, because unlike spoofing and modification attacks, cryptographic integrity protection mechanisms can't prevent a delay attack 😩. In some cases, delay attacks can be mitigated by sending the timestamped information through multiple paths, which allows detection of and resistance to an attacker who has access to one of the paths 🧚.

In many cases, timestamping relies on an underlying synchronization mechanism 🕰️. So 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. References 📚🎀

10.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>.

[RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
           2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
           May 2017, <https://www.rfc-editor.org/info/rfc8174>.

10.2. Informative References 🌸

[IEEE1588] IEEE, "IEEE Standard for a Precision Clock Synchronization
           Protocol for Networked Measurement and Control Systems",
           DOI 10.1109/IEEESTD.2008.4579760, IEEE Std. 1588-2008,
           July 2008, <https://doi.org/10.1109/IEEESTD.2008.4579760>.

[IEEE1588v1]
           IEEE, "IEEE Standard for a Precision Clock Synchronization
           Protocol for Networked Measurement and Control Systems",
           DOI 10.1109/IEEESTD.2002.94144, IEEE Std. 1588-2002,
           October 2002,
           <https://doi.org/10.1109/IEEESTD.2002.94144>.

[ITU-T-Y.1731]
           ITU-T, "Operations, administration and maintenance (OAM)
           functions and mechanisms for Ethernet-based networks",
           ITU-T Recommendation G.8013/Y.1731, August 2015.

[METRICS]  Morton, A., Bagnulo, M., Eardley, P., and K. D'Souza,
           "Initial Performance Metrics Registry Entries", Work in
           Progress, Internet-Draft, draft-ietf-ippm-initial-
           registry-16, 9 March 2020, <https://tools.ietf.org/html/
           draft-ietf-ippm-initial-registry-16>.

[NSHMD]    Guichard, J., Smith, M., Kumar, S., Majee, S., and T.
           Mizrahi, "Network Service Header (NSH) MD Type 1: Context
           Header Allocation (Data Center)", Work in Progress,
           Internet-Draft, draft-ietf-sfc-nsh-dc-allocation-02, 25
           September 2018, <https://tools.ietf.org/html/draft-ietf-
           sfc-nsh-dc-allocation-02>.

[RFC3339]  Klyne, G. and C. Newman, "Date and Time on the Internet:
           Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002,
           <https://www.rfc-editor.org/info/rfc3339>.

[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, <https://www.rfc-editor.org/info/rfc3550>.

[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,
           <https://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,
           <https://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, <https://www.rfc-editor.org/info/rfc5646>.

[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>.

[RFC6019]  Housley, R., "BinaryTime: An Alternate Format for
           Representing Date and Time in ASN.1", RFC 6019,
           DOI 10.17487/RFC6019, September 2010,
           <https://www.rfc-editor.org/info/rfc6019>.

[RFC6374]  Frost, D. and S. Bryant, "Packet Loss and Delay
           Measurement for MPLS Networks", RFC 6374,
           DOI 10.17487/RFC6374, September 2011,
           <https://www.rfc-editor.org/info/rfc6374>.

[RFC6991]  Schoenwaelder, J., Ed., "Common YANG Data Types",
           RFC 6991, DOI 10.17487/RFC6991, July 2013,
           <https://www.rfc-editor.org/info/rfc6991>.

[RFC7011]  Claise, B., Ed., Trammell, B., Ed., and P. Aitken,
           "Specification of the IP Flow Information Export (IPFIX)
           Protocol for the Exchange of Flow Information", STD 77,
           RFC 7011, DOI 10.17487/RFC7011, September 2013,
           <https://www.rfc-editor.org/info/rfc7011>.

[RFC7323]  Borman, D., Braden, B., Jacobson, V., and R.
           Scheffenegger, Ed., "TCP Extensions for High Performance",
           RFC 7323, DOI 10.17487/RFC7323, September 2014,
           <https://www.rfc-editor.org/info/rfc7323>.

[RFC7384]  Mizrahi, T., "Security Requirements of Time Protocols in
           Packet Switched Networks", RFC 7384, DOI 10.17487/RFC7384,
           October 2014, <https://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,
           <https://www.rfc-editor.org/info/rfc7456>.

[RFC7493]  Bray, T., Ed., "The I-JSON Message Format", RFC 7493,
           DOI 10.17487/RFC7493, March 2015,
           <https://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,
           <https://www.rfc-editor.org/info/rfc8186>.

Acknowledgments 🫶

The authors thank Russ Housley, Yaakov Stein, Greg Mirsky, Warner Losh, Rodney Cummings, Miroslav Lichvar, Denis Reilly, Daniel Franke, Éric Vyncke, Ben Kaduk, Ian Swett, Francesca Palombini, Watson Ladd, and other members of the NTP Working Group for their many helpful comments 💖. The authors also gratefully acknowledge Harlan Stenn and the people from the Network Time Foundation for sharing their thoughts and ideas 🌈.

Authors' Addresses 🦋

Tal Mizrahi
Huawei
8-2 Matam
Haifa 3190501
Israel

Email: tal.mizrahi.phd@gmail.com


Joachim Fabini
TU Wien
Gusshausstrasse 25/E389
1040 Vienna
Austria

Phone: +43 1 58801 38813
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
United States of America

Phone: +1 732 420 1571
Email: acmorton@att.com
📦 where this page comes from