idnits 2.17.1 draft-ietf-ntp-packet-timestamps-09.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 11, 2020) is 1501 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-09) exists of draft-ietf-ntp-packet-timestamps-08 Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 NTP Working Group T. Mizrahi 3 Internet-Draft Huawei Smart Platforms iLab 4 Intended status: Informational J. Fabini 5 Expires: September 12, 2020 TU Wien 6 A. Morton 7 AT&T Labs 8 March 11, 2020 10 Guidelines for Defining Packet Timestamps 11 draft-ietf-ntp-packet-timestamps-09 13 Abstract 15 Various network protocols make use of binary-encoded timestamps that 16 are incorporated in the protocol packet format, referred to as packet 17 timestamps for short. This document specifies guidelines for 18 defining packet timestamp formats in networking protocols at various 19 layers. It also presents three recommended timestamp formats. The 20 target audience of this document includes network protocol designers. 21 It is expected that a new network protocol that requires a packet 22 timestamp will, in most cases, use one of the recommended timestamp 23 formats. If none of the recommended formats fits the protocol 24 requirements, the new protocol specification should specify the 25 format of the packet timestamp according to the guidelines in this 26 document. 28 Status of This Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at https://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on September 12, 2020. 45 Copyright Notice 47 Copyright (c) 2020 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (https://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 63 1.1. Background . . . . . . . . . . . . . . . . . . . . . . . 3 64 1.2. Scope of this Document . . . . . . . . . . . . . . . . . 3 65 1.3. How to Use This Document . . . . . . . . . . . . . . . . 3 66 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 67 2.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 68 2.2. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 4 69 2.3. Terms used in this Document . . . . . . . . . . . . . . . 4 70 3. Packet Timestamp Specification Template . . . . . . . . . . . 5 71 4. Recommended Timestamp Formats . . . . . . . . . . . . . . . . 6 72 4.1. Using a Recommended Timestamp Format . . . . . . . . . . 7 73 4.2. NTP Timestamp Formats . . . . . . . . . . . . . . . . . . 7 74 4.2.1. NTP 64-bit Timestamp Format . . . . . . . . . . . . . 7 75 4.2.2. NTP 32-bit Timestamp Format . . . . . . . . . . . . . 9 76 4.3. The PTP Truncated Timestamp Format . . . . . . . . . . . 10 77 5. Synchronization Aspects . . . . . . . . . . . . . . . . . . . 11 78 6. Timestamp Use Cases . . . . . . . . . . . . . . . . . . . . . 12 79 6.1. Example 1 . . . . . . . . . . . . . . . . . . . . . . . . 13 80 6.2. Example 2 . . . . . . . . . . . . . . . . . . . . . . . . 14 81 7. Packet Timestamp Control Field . . . . . . . . . . . . . . . 14 82 7.1. High-level Control Field Requirements . . . . . . . . . . 15 83 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 84 9. Security Considerations . . . . . . . . . . . . . . . . . . . 16 85 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17 86 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 87 11.1. Normative References . . . . . . . . . . . . . . . . . . 17 88 11.2. Informative References . . . . . . . . . . . . . . . . . 17 89 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 91 1. Introduction 93 1.1. Background 95 Timestamps are widely used in network protocols for various purposes: 96 timestamps are used for logging or reporting the time of an event, 97 delay measurement and clock synchronization protocols both make use 98 of timestamped messages, and in security protocols a timestamp is 99 often used as part of a value that is unlikely to repeat (nonce). 101 Timestamps are represented in the RFC series in one of two forms: 102 text-based timestamps, and packet timestamps. Text-based timestamps 103 [RFC3339] are represented as user-friendly strings, and are widely 104 used in the RFC series, for example in information objects and data 105 models, e.g., [RFC5646], [RFC6991], and [RFC7493]. Packet 106 timestamps, on the other hand, are represented by a compact binary 107 field that has a fixed size, and are not intended to have a human- 108 friendly format. Packet timestamps are also very common in the RFC 109 series, and are used for example for measuring delay and for 110 synchronizing clocks, e.g., [RFC5905], [RFC4656], and [RFC7323]. 112 1.2. Scope of this Document 114 This document presents guidelines for defining a packet timestamp 115 format in network protocols. Three recommended timestamp formats are 116 presented. It is expected that a new network protocol that requires 117 a packet timestamp will, in most cases, use one of these recommended 118 timestamp formats. In some cases a network protocol may use more 119 than one of the recommended timestamp formats. However, if none of 120 the recommended formats fits the protocol requirements, the new 121 protocol specification should specify the format of the packet 122 timestamp according to the guidelines in this document. 124 The rationale behind defining a relatively small set of recommended 125 formats is that it enables significant reuse; network protocols can 126 typically reuse the timestamp format of the Network Time Protocol 127 (NTP) or the Precision Time Protocol (PTP), allowing a 128 straightforward integration with an NTP or a PTP-based timer. 129 Moreover, since accurate timestamping mechanisms are often 130 implemented in hardware, a new network protocol that reuses an 131 existing timestamp format can be quickly deployed using existing 132 hardware timestamping capabilities. 134 1.3. How to Use This Document 136 This document is intended as a reference for network protocol 137 designers. When defining a network protocol that uses a packet 138 timestamp, the recommended timestamp formats should be considered 139 first (Section 4). If one of these formats is used, it should be 140 referenced along the lines of the examples in Section 6.1 and 141 Section 6.2. If none of the recommended formats fits the required 142 functionality, then a new timestamp format should be defined using 143 the template of Section 3. 145 2. Terminology 147 2.1. Requirements Language 149 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 150 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 151 "OPTIONAL" in this document are to be interpreted as described in BCP 152 14 [RFC2119] [RFC8174] when, and only when, they appear in all 153 capitals, as shown here. 155 2.2. Abbreviations 157 NTP Network Time Protocol [RFC5905] 159 PTP Precision Time Protocol [IEEE1588] 161 TAI International Atomic Time 163 UTC Coordinated Universal Time 165 2.3. Terms used in this Document 167 Timestamp: A value that represents a point in time, 168 corresponding to an event that occurred or is 169 scheduled to occur. 171 Timestamp error: The difference between the timestamp value and 172 the value of a reference clock at the time of 173 the event that the timestamp was intended to 174 indicate. 176 Timestamp format: The specification of a timestamp, which is 177 represented by a set of attributes that 178 unambiguously define the syntax and semantics 179 of a timestamp. 181 Timestamp accuracy: The mean over an ensemble of measurements of 182 the timestamp error. 184 Timestamp precision: The variation over an ensemble of measurements 185 of the timestamp error. 187 Timestamp resolution: The minimal time unit used for representing 188 the timestamp. 190 3. Packet Timestamp Specification Template 192 This document recommends to use the timestamp formats defined in 193 Section 4. In cases where these timestamp formats do not satisfy the 194 protocol requirements, the timestamp specification should clearly 195 state the reasons for defining a new format. Moreover, it is 196 recommended to derive the new timestamp format from an existing 197 timestamp format, either a timestamp format from this document, or 198 any other previously defined timestamp format. 200 The timestamp specification must unambiguously define the syntax and 201 the semantics of the timestamp. The current section defines the 202 minimum set of attributes, but it should be noted that in some cases 203 additional attributes or aspects will need to be defined in the 204 timestamp specification. 206 This section defines a template for specifying packet timestamps. A 207 timestamp format specification MUST include at least the following 208 aspects: 210 Timestamp syntax: 212 - Size: The number of bits (or octets) used to represent the 213 packet timestamp field. If the timestamp is comprised of more 214 than one field, the size of each field is specified. Network 215 order (big endian) is assumed by default; if this is not the case 216 then this section explicitly specifies the endianity. 218 Timestamp semantics: 220 - Units: The units used to represent the timestamp. If the 221 timestamp is comprised of more than one field, the units of each 222 field are specified. If a field is limited to a specific range of 223 values, this section specifies the permitted range of values. 225 - Resolution: The timestamp resolution; the resolution is equal to 226 the timestamp field unit. If the timestamp consists of two or 227 more fields using different time units, then the resolution is the 228 smallest time unit. 230 - Wraparound: The wraparound period of the timestamp; any further 231 wraparound-related considerations should be described here. 233 - Epoch: The origin of the timescale used for the timestamp; the 234 moment in time used as a reference for the timestamp value. For 235 example, the epoch may be based on a standard time scale, such as 236 UTC. Another example is a relative timestamp, in which the epoch 237 could be the time at which the device using the timestamp was 238 powered up, and is not affected by leap seconds (see the next 239 attribute). 241 - Leap seconds: This subsection specifies whether the timestamp is 242 affected by leap seconds. If the timestamp is affected by leap 243 seconds, then it represents the time elapsed since the epoch minus 244 the number of leap seconds that have occurred since the epoch. 246 Synchronization aspects: 248 The specification of a network protocol that makes use of a packet 249 timestamp is expected to include the synchronization aspects of 250 using the timestamp. While the synchronization aspects are not 251 strictly part of the timestamp format specification, these aspects 252 provide the necessary context for using the timestamp within the 253 scope of the protocol. In some cases timestamps are used without 254 synchronization, e.g., a timestamp that indicates the number of 255 seconds since power up. In such cases the Synchronization Aspects 256 section will specify that the timestamp does not correspond to a 257 synchronized time reference, and may discuss how this affects the 258 usage of the timestamp. Further details about synchronization 259 aspects are discussed in Section 5. 261 4. Recommended Timestamp Formats 263 This document defines a set of recommended timestamp formats. 264 Clearly, different network protocols may have different requirements 265 and constraints, and consequently may use different timestamp 266 formats. The choice of the specific timestamp format for a given 267 protocol may depend on a various factors. A few examples of factors 268 that may affect the choice of the timestamp format: 270 o Timestamp size: while some network protocols use a large timestamp 271 field, in some cases there may be constraints with respect to the 272 timestamp size, affecting the choice of the timestamp format. 274 o Resolution: the time resolution is another factor that may 275 directly affect the selected timestamp format. A potentially 276 important factor in this context is extensibility; it may be 277 desirable to allow a timestamp format to be extensible to a higher 278 resolution by extending the field. For example, the resolution of 279 the NTP 32-bit timestamp format can be improved by extending it to 280 the NTP 64-bit timestamp format in a straightforward way. 282 o Wraparound period: the length of the time interval in which the 283 timestamp is unique may also be an important factor in choosing 284 the timestamp format. Along with the timestamp resolution, these 285 two factors determine the required number of bits in the 286 timestamp. 288 o Common format for multiple protocols: if there are two or more 289 network protocols that use timestamps and are often used together 290 in typical systems, using a common timestamp format should be 291 preferred if possible. For example, if the network protocol that 292 is being defined typically runs on a PC, then an NTP-based 293 timestamp format may allow easier integration with an NTP- 294 synchronized timer. In contrast, a protocol that is typically 295 deployed on a hardware-based platform, may make better use of a 296 PTP-based timestamp, allowing more efficient integration with a 297 PTP-synchronized timer. 299 4.1. Using a Recommended Timestamp Format 301 A specification that uses one of the recommended timestamp formats 302 should specify explicitly that this is a recommended timestamp 303 format, and point to the relevant section in the current document. 305 4.2. NTP Timestamp Formats 307 4.2.1. NTP 64-bit Timestamp Format 309 The Network Time Protocol (NTP) 64-bit timestamp format is defined in 310 [RFC5905]. This timestamp format is used in several network 311 protocols, including [RFC6374], [RFC4656], and [RFC5357]. Since this 312 timestamp format is used in NTP, this timestamp format should be 313 preferred in network protocols that are typically deployed in concert 314 with NTP. 316 The format is presented in this section according to the template 317 defined in Section 3. 319 0 1 2 3 320 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 321 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 322 | Seconds | 323 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 324 | Fraction | 325 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 327 Figure 1: NTP [RFC5905] 64-bit Timestamp Format 329 Timestamp field format: 331 Seconds: specifies the integer portion of the number of seconds 332 since the epoch. 334 - Size: 32 bits. 336 - Units: seconds. 338 Fraction: specifies the fractional portion of the number of 339 seconds since the epoch. 341 - Size: 32 bits. 343 - Units: the unit is 2^(-32) seconds, which is roughly equal to 344 233 picoseconds. 346 Epoch: 348 The epoch is 1 January 1900 at 00:00 UTC. 350 Note: As pointed out in [RFC5905], strictly speaking, UTC did not 351 exist prior to 1 January 1972, but it is convenient to assume it 352 has existed for all eternity. The current epoch implies that the 353 timestamp specifies the number of seconds since 1 January 1972 at 354 00:00 UTC plus 2272060800 (which is the number of seconds between 355 1 January 1900 and 1 January 1972). 357 Leap seconds: 359 This timestamp format is affected by leap seconds. The timestamp 360 represents the number of seconds elapsed since the epoch minus the 361 number of leap seconds. Thus, during and possibly before and/or 362 after the occurrence of a leap second, the value of the timestamp 363 may temporarily be ambiguous, as further discussed in Section 5. 365 Resolution: 367 The resolution is 2^(-32) seconds. 369 Wraparound: 371 This time format wraps around every 2^32 seconds, which is roughly 372 136 years. The next wraparound will occur in the year 2036. 374 4.2.2. NTP 32-bit Timestamp Format 376 The Network Time Protocol (NTP) 32-bit timestamp format is defined in 377 [RFC5905]. This timestamp format is used in 378 [I-D.ietf-ippm-initial-registry] and 379 [I-D.ietf-sfc-nsh-dc-allocation]. This timestamp format should be 380 preferred in network protocols that are typically deployed in concert 381 with NTP. The 32-bit format can be used either when space 382 constraints do not allow the use of the 64-bit format, or when the 383 32-bit format satisfies the resolution and wraparound requirements. 385 The format is presented in this section according to the template 386 defined in Section 3. 388 0 1 2 3 389 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 390 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 391 | Seconds | Fraction | 392 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 394 Figure 2: NTP [RFC5905] 32-bit Timestamp Format 396 Timestamp field format: 398 Seconds: specifies the integer portion of the number of seconds 399 since the epoch. 401 - Size: 16 bits. 403 - Units: seconds. 405 Fraction: specifies the fractional portion of the number of 406 seconds since the epoch. 408 - Size: 16 bits. 410 - Units: the unit is 2^(-16) seconds, which is roughly equal to 411 15.3 microseconds. 413 Epoch: 415 The epoch is 1 January 1900 at 00:00 UTC. 417 Note: As pointed out in [RFC5905], strictly speaking, UTC did not 418 exist prior to 1 January 1972, but it is convenient to assume it 419 has existed for all eternity. The current epoch implies that the 420 timestamp specifies the number of seconds since 1 January 1972 at 421 00:00 UTC plus 2272060800 (which is the number of seconds between 422 1 January 1900 and 1 January 1972). 424 Leap seconds: 426 This timestamp format is affected by leap seconds. The timestamp 427 represents the number of seconds elapsed since the epoch minus the 428 number of leap seconds. Thus, during and possibly after the 429 occurrence of a leap second, the value of the timestamp may 430 temporarily be ambiguous, as further discussed in Section 5. 432 Resolution: 434 The resolution is 2^(-16) seconds. 436 Wraparound: 438 This time format wraps around every 2^16 seconds, which is roughly 439 18 hours. 441 4.3. The PTP Truncated Timestamp Format 443 The Precision Time Protocol (PTP) [IEEE1588] uses an 80-bit timestamp 444 format. The truncated timestamp format is a 64-bit field, which is 445 the 64 least significant bits of the 80-bit PTP timestamp. Since 446 this timestamp format is similar to the one used in PTP, this 447 timestamp format should be preferred in network protocols that are 448 typically deployed in PTP-capable devices. 450 The PTP truncated timestamp format was defined in [IEEE1588v1] and is 451 used in several protocols, such as [RFC6374], [RFC7456], [RFC8186] 452 and [ITU-T-Y.1731]. 454 0 1 2 3 455 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 456 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 457 | Seconds | 458 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 459 | Nanoseconds | 460 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 462 Figure 3: PTP [IEEE1588] Truncated Timestamp Format 464 Timestamp field format: 466 Seconds: specifies the integer portion of the number of seconds 467 since the epoch. 469 - Size: 32 bits. 471 - Units: seconds. 473 Nanoseconds: specifies the fractional portion of the number of 474 seconds since the epoch. 476 - Size: 32 bits. 478 - Units: nanoseconds. The value of this field is in the range 0 479 to (10^9)-1. 481 Epoch: 483 The PTP [IEEE1588] epoch is 1 January 1970 00:00:00 TAI. 485 Leap seconds: 487 This timestamp format is not affected by leap seconds. 489 Resolution: 491 The resolution is 1 nanosecond. 493 Wraparound: 495 This time format wraps around every 2^32 seconds, which is roughly 496 136 years. The next wraparound will occur in the year 2106. 498 5. Synchronization Aspects 500 A specification that defines a new timestamp format or uses one of 501 the recommended timestamp formats should include a section on 502 Synchronization Aspects. Note that the recommended timestamp formats 503 defined in this document (Section 4) do not include the 504 synchronization aspects of these timestamp formats, but it is 505 expected that specifications of network protocols that make use of 506 these formats should include the synchronization aspects. Examples 507 of a Synchronization Aspects section can be found in Section 6. 509 The Synchronization Aspects section should specify all the 510 assumptions and requirements related to synchronization. For 511 example, the synchronization aspects may specify whether nodes 512 populating the timestamps should be synchronized among themselves, 513 and whether the timestamp is measured with respect to a central 514 reference clock such as an NTP server. If time is assumed to be 515 synchronized to a time standard such as UTC or TAI, it should be 516 specified in this section. Further considerations may be discussed 517 in this section, such as the required timestamp accuracy and 518 precision. 520 Another aspect that should be discussed in this section is leap 521 second [RFC5905] considerations. The timestamp specification 522 template (Section 3) specifies whether the timestamp is affected by 523 leap seconds. It is often the case that further details about leap 524 seconds will need to be defined in the Synchronization Aspects 525 section. Generally speaking, a leap second is a one-second 526 adjustment that is occasionally applied to UTC in order to keep it 527 aligned to the solar time. A leap second may be either positive or 528 negative, i.e., the clock may either be shifted one second forwards 529 or backwards. All leap seconds that have occurred up to the 530 publication of this document have been in the backwards direction, 531 and although forward leap seconds are theoretically possible, the 532 text throughout this document focuses on the common case, which is 533 the backward leap second. In a timekeeping system that considers 534 leap seconds, the system clock may be affected by a leap second in 535 one of three possible ways: 537 o The clock is turned backwards one second at the end of the leap 538 second. 540 o The clock is frozen during the duration of the leap second. 542 o The clock is slowed down during the leap second and adjacent time 543 intervals until the new time value catches up. The interval for 544 this process, commonly referred to as leap smear, can range from 545 several seconds to several hours before, during, and/or after the 546 occurrence of the leap second. 548 The way leap seconds are handled depends on the synchronization 549 protocol, and is thus not specified in this document. However, if a 550 timestamp format is defined with respect to a timescale that is 551 affected by leap seconds, the Synchronization Aspects section should 552 specify how the use of leap seconds affects the timestamp usage. 554 6. Timestamp Use Cases 556 Packet timestamps are used in various network protocols. Typical 557 applications of packet timestamps include delay measurement, clock 558 synchronization, and others. The following table presents a (non- 559 exhaustive) list of protocols that use packet timestamps, and the 560 timestamp formats used in each of these protocols. 562 +----------------------+-----------------------------------+-----------+ 563 | | Recommended formats | Other | 564 +----------------------+-----------+-----------+-----------+-----------+ 565 | Protocol |NTP 64-bit |NTP 32-bit |PTP Trunc. | | 566 +----------------------+-----------+-----------+-----------+-----------+ 567 | NTP [RFC5905] | + | | | | 568 +----------------------+-----------+-----------+-----------+-----------+ 569 | OWAMP [RFC4656] | + | | | | 570 +----------------------+-----------+-----------+-----------+-----------+ 571 | TWAMP [RFC5357] | + | | | | 572 | TWAMP [RFC8186] | + | | + | | 573 +----------------------+-----------+-----------+-----------+-----------+ 574 | TRILL [RFC7456] | | | + | | 575 +----------------------+-----------+-----------+-----------+-----------+ 576 | MPLS [RFC6374] | | | + | | 577 +----------------------+-----------+-----------+-----------+-----------+ 578 | TCP [RFC7323] | | | | + | 579 +----------------------+-----------+-----------+-----------+-----------+ 580 | RTP [RFC3550] | + | | | + | 581 +----------------------+-----------+-----------+-----------+-----------+ 582 | IPFIX [RFC7011] | | | | + | 583 +----------------------+-----------+-----------+-----------+-----------+ 584 | BinaryTime [RFC6019] | | | | + | 585 +----------------------+-----------+-----------+-----------+-----------+ 586 | [I-D.ietf-ippm- | + | + | | | 587 | initial-registry] | | | | | 588 +----------------------+-----------+-----------+-----------+-----------+ 589 | [I-D.ietf-sfc-nsh | | + | + | | 590 | -dc-allocation] | | | | | 591 +----------------------+-----------+-----------+-----------+-----------+ 593 Figure 4: Protocols that use Packet Timestamps 595 The rest of this section presents two hypothetic examples of network 596 protocol specifications that use one of the recommended timestamp 597 formats. The examples include the text that specifies the 598 information related to the timestamp format. 600 6.1. Example 1 602 Timestamp: 604 The timestamp format used in this specification is the NTP 605 [RFC5905] 64-bit format, as specified in Section 4.2.1 of 606 [I-D.ietf-ntp-packet-timestamps]. 608 Synchronization aspects: 610 It is assumed that nodes that run this protocol are synchronized 611 to UTC using a synchronization mechanism that is outside the scope 612 of this document. In typical deployments this protocol will run 613 on a machine that uses NTP [RFC5905] for synchronization. Thus, 614 the timestamp may be derived from the NTP-synchronized clock, 615 allowing the timestamp to be measured with respect to the clock of 616 an NTP server. Since the NTP time format is affected by leap 617 seconds, the current timestamp format is similarly affected. 618 Thus, the value of a timestamp during or slightly after a leap 619 second may be temporarily inaccurate. 621 6.2. Example 2 623 Timestamp: 625 The timestamp format used in this specification is the PTP 626 [IEEE1588] Truncated format, as specified in Section 4.3 of 627 [I-D.ietf-ntp-packet-timestamps]. 629 Synchronization aspects: 631 It is assumed that nodes that run this protocol are synchronized 632 among themselves. Nodes may be synchronized to a global reference 633 time. Note that if PTP [IEEE1588] is used for synchronization, 634 the timestamp may be derived from the PTP-synchronized clock, 635 allowing the timestamp to be measured with respect to the clock of 636 an PTP Grandmaster clock. 638 7. Packet Timestamp Control Field 640 In some cases it is desirable to have a control field that describes 641 structure, format, content, and properties of timestamps. Control 642 information about the timestamp format can be conveyed in some 643 protocols using a dedicated control plane protocol, or may be made 644 available at the management plane, for example using a YANG data 645 model. An optional control field allows some of the control 646 information to be attached to the timestamp. 648 An example of a packet timestamp control field is the Error Estimate 649 field, defined by Section 4.1.2 in [RFC4656], which is used in OWAMP 650 [RFC4656] and TWAMP [RFC5357]. The Root Dispersion and Root Delay 651 fields in the NTP header [RFC5905] are two examples of fields that 652 provide information about the timestamp precision. Another example 653 of an auxiliary field is the Correction Field in the PTP header 654 [IEEE1588]; its value is used as a correction to the timestamp, and 655 may be assigned by the sender of the PTP message and updated by 656 transit nodes (Transparent Clocks) in order to account for the delay 657 along the path. 659 This section defines high-level guidelines for defining packet 660 timestamp control fields in network protocols that can benefit from 661 such timestamp-related control information. The word 'requirements' 662 is used in its informal context in this section. 664 7.1. High-level Control Field Requirements 666 A control field for packet timestamps must offer an adequate feature 667 set and fulfill a series of requirements to be usable and accepted. 668 The following list captures the main high-level requirements for 669 timestamp fields. 671 1. Extensible Feature Set: protocols and applications depend on 672 various timestamp characteristics. A timestamp control field 673 must support a variable number of elements (components) that 674 either describe or quantify timestamp-specific characteristics or 675 parameters. Examples of potential elements include timestamp 676 size, encoding, accuracy, leap seconds, reference clock 677 identifiers, etc. 679 2. Size: Essential for an efficient use of timestamp control fields 680 is the trade-off between supported features and control field 681 size. Protocols and applications may select the specific control 682 field elements that are needed for their operation from the set 683 of available elements. 685 3. Composition: Applications may depend on specific control field 686 elements being present in messages. The status of these elements 687 may be either mandatory, conditional mandatory, or optional, 688 depending on the specific application and context. A control 689 field specification must support applications in conveying or 690 negotiating (a) the set of control field elements along with (b) 691 the status of any element (i.e., mandatory, conditional 692 mandatory, or optional) by defining appropriate data structures 693 and identity codes. 695 4. Category: Control field elements can characterize either static 696 timestamp information (like, e.g., timestamp size in bytes and 697 timestamp semantics: NTP 64 bit format) or runtime timestamp 698 information (like, e.g., estimated timestamp accuracy at the time 699 of sampling: 20 microseconds to UTC). For efficiency reason it 700 may be meaningful to support separation of these two concepts: 701 while the former (static) information is typically valid 702 throughout a protocol session and may be conveyed only once, at 703 session establishment time, the latter (runtime) information 704 augments any timestamp instance and may cause substantial 705 overhead for high-traffic protocols. 707 Proposals for timestamp control fields will be defined in separate 708 documents and are out of scope of this document. 710 8. IANA Considerations 712 This document includes no request to IANA. 714 9. Security Considerations 716 A network protocol that uses a packet timestamp MUST specify the 717 security considerations that result from using the timestamp. This 718 section provides an overview of some of the common security 719 considerations of using timestamps. 721 Any metadata that is attached to control or data packets, and 722 specifically packet timestamps, can facilitate network 723 reconnaissance; by passively eavesdropping to timestamped packets an 724 attacker can gather information about the network performance, and 725 about the level of synchronization between nodes. 727 In some cases timestamps could be spoofed or modified by on-path 728 attackers, thus attacking the application that uses the timestamps. 729 For example, if timestamps are used in a delay measurement protocol, 730 an attacker can modify en route timestamps in a way that manipulates 731 the measurement results. Integrity protection mechanisms, such as 732 Message Authentication Codes (MAC), can mitigate such attacks. The 733 specification of an integrity protection mechanism is outside the 734 scope of this document, as typically integrity protection will be 735 defined on a per-network-protocol basis, and not specifically for the 736 timestamp field. 738 Another potential threat that can have a similar impact is delay 739 attacks. An attacker can maliciously delay some or all of the en 740 route messages, with the same harmful implications as described in 741 the previous paragraph. Mitigating delay attacks is a significant 742 challenge; in contrast to spoofing and modification attacks, the 743 delay attack cannot be prevented by cryptographic integrity 744 protection mechanisms. In some cases delay attacks can be mitigated 745 by sending the timestamped information through multiple paths, 746 allowing to detect and to be resilient to an attacker that has access 747 to one of the paths. 749 In many cases timestamping relies on an underlying synchronization 750 mechanism. Thus, any attack that compromises the synchronization 751 mechanism can also compromise protocols that use timestamping. 752 Attacks on time protocols are discussed in detail in [RFC7384]. 754 10. Acknowledgments 756 The authors thank Russ Housley, Yaakov Stein, Greg Mirsky, Warner 757 Losh, Rodney Cummings, Miroslav Lichvar, Denis Reilly, Daniel Franke, 758 Eric Vyncke, Ben Kaduk, Ian Swett, Francesca Palombini, Watson Ladd, 759 and other members of the NTP working group for many helpful comments. 760 The authors gratefully acknowledge Harlan Stenn and the people from 761 the Network Time Foundation for sharing their thoughts and ideas. 763 11. References 765 11.1. Normative References 767 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 768 Requirement Levels", BCP 14, RFC 2119, 769 DOI 10.17487/RFC2119, March 1997, 770 . 772 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 773 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 774 May 2017, . 776 11.2. Informative References 778 [I-D.ietf-ippm-initial-registry] 779 Morton, A., Bagnulo, M., Eardley, P., and K. D'Souza, 780 "Initial Performance Metrics Registry Entries", draft- 781 ietf-ippm-initial-registry-16 (work in progress), March 782 2020. 784 [I-D.ietf-ntp-packet-timestamps] 785 Mizrahi, T., Fabini, J., and A. Morton, "Guidelines for 786 Defining Packet Timestamps", draft-ietf-ntp-packet- 787 timestamps-08 (work in progress), February 2020. 789 [I-D.ietf-sfc-nsh-dc-allocation] 790 Guichard, J., Smith, M., Kumar, S., Majee, S., and T. 791 Mizrahi, "Network Service Header (NSH) MD Type 1: Context 792 Header Allocation (Data Center)", draft-ietf-sfc-nsh-dc- 793 allocation-02 (work in progress), September 2018. 795 [IEEE1588] 796 IEEE, "IEEE 1588 Standard for a Precision Clock 797 Synchronization Protocol for Networked Measurement and 798 Control Systems Version 2", 2008. 800 [IEEE1588v1] 801 IEEE, "IEEE 1588 Standard for a Precision Clock 802 Synchronization Protocol for Networked Measurement and 803 Control Systems", 2002. 805 [ITU-T-Y.1731] 806 ITU-T, "OAM functions and mechanisms for Ethernet based 807 Networks", 2013. 809 [RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet: 810 Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002, 811 . 813 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 814 Jacobson, "RTP: A Transport Protocol for Real-Time 815 Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, 816 July 2003, . 818 [RFC4656] Shalunov, S., Teitelbaum, B., Karp, A., Boote, J., and M. 819 Zekauskas, "A One-way Active Measurement Protocol 820 (OWAMP)", RFC 4656, DOI 10.17487/RFC4656, September 2006, 821 . 823 [RFC5357] Hedayat, K., Krzanowski, R., Morton, A., Yum, K., and J. 824 Babiarz, "A Two-Way Active Measurement Protocol (TWAMP)", 825 RFC 5357, DOI 10.17487/RFC5357, October 2008, 826 . 828 [RFC5646] Phillips, A., Ed. and M. Davis, Ed., "Tags for Identifying 829 Languages", BCP 47, RFC 5646, DOI 10.17487/RFC5646, 830 September 2009, . 832 [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, 833 "Network Time Protocol Version 4: Protocol and Algorithms 834 Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010, 835 . 837 [RFC6019] Housley, R., "BinaryTime: An Alternate Format for 838 Representing Date and Time in ASN.1", RFC 6019, 839 DOI 10.17487/RFC6019, September 2010, 840 . 842 [RFC6374] Frost, D. and S. Bryant, "Packet Loss and Delay 843 Measurement for MPLS Networks", RFC 6374, 844 DOI 10.17487/RFC6374, September 2011, 845 . 847 [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", 848 RFC 6991, DOI 10.17487/RFC6991, July 2013, 849 . 851 [RFC7011] Claise, B., Ed., Trammell, B., Ed., and P. Aitken, 852 "Specification of the IP Flow Information Export (IPFIX) 853 Protocol for the Exchange of Flow Information", STD 77, 854 RFC 7011, DOI 10.17487/RFC7011, September 2013, 855 . 857 [RFC7323] Borman, D., Braden, B., Jacobson, V., and R. 858 Scheffenegger, Ed., "TCP Extensions for High Performance", 859 RFC 7323, DOI 10.17487/RFC7323, September 2014, 860 . 862 [RFC7384] Mizrahi, T., "Security Requirements of Time Protocols in 863 Packet Switched Networks", RFC 7384, DOI 10.17487/RFC7384, 864 October 2014, . 866 [RFC7456] Mizrahi, T., Senevirathne, T., Salam, S., Kumar, D., and 867 D. Eastlake 3rd, "Loss and Delay Measurement in 868 Transparent Interconnection of Lots of Links (TRILL)", 869 RFC 7456, DOI 10.17487/RFC7456, March 2015, 870 . 872 [RFC7493] Bray, T., Ed., "The I-JSON Message Format", RFC 7493, 873 DOI 10.17487/RFC7493, March 2015, 874 . 876 [RFC8186] Mirsky, G. and I. Meilik, "Support of the IEEE 1588 877 Timestamp Format in a Two-Way Active Measurement Protocol 878 (TWAMP)", RFC 8186, DOI 10.17487/RFC8186, June 2017, 879 . 881 Authors' Addresses 883 Tal Mizrahi 884 Huawei Smart Platforms iLab 885 8-2 Matam 886 Haifa 3190501 887 Israel 889 Email: tal.mizrahi.phd@gmail.com 890 Joachim Fabini 891 TU Wien 892 Gusshausstrasse 25/E389 893 Vienna 1040 894 Austria 896 Phone: +43 1 58801 38813 897 Fax: +43 1 58801 38898 898 Email: Joachim.Fabini@tuwien.ac.at 899 URI: http://www.tc.tuwien.ac.at/about-us/staff/joachim-fabini/ 901 Al Morton 902 AT&T Labs 903 200 Laurel Avenue South 904 Middletown,, NJ 07748 905 USA 907 Phone: +1 732 420 1571 908 Fax: +1 732 368 1192 909 Email: acmorton@att.com