idnits 2.17.1 draft-ietf-ntp-packet-timestamps-05.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 (December 9, 2018) is 1955 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-16) exists of draft-ietf-ippm-initial-registry-08 == Outdated reference: A later version (-09) exists of draft-ietf-ntp-packet-timestamps-04 -- Obsolete informational reference (is this intentional?): RFC 1323 (Obsoleted by RFC 7323) Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 NTP Working Group T. Mizrahi 3 Internet-Draft Huawei Network.IO Innovation Lab 4 Intended status: Informational J. Fabini 5 Expires: June 12, 2019 TU Wien 6 A. Morton 7 AT&T Labs 8 December 9, 2018 10 Guidelines for Defining Packet Timestamps 11 draft-ietf-ntp-packet-timestamps-05 13 Abstract 15 This document specifies guidelines for defining binary packet 16 timestamp formats in networking protocols at various layers. It also 17 presents three recommended timestamp formats. The target audience of 18 this memo includes network protocol designers. It is expected that a 19 new network protocol that requires a packet timestamp will, in most 20 cases, use one of the recommended timestamp formats. If none of the 21 recommended formats fits the protocol requirements, the new protocol 22 specification should specify the format of the packet timestamp 23 according to the guidelines in this document. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at https://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on June 12, 2019. 42 Copyright Notice 44 Copyright (c) 2018 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (https://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 60 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 2.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 62 2.2. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 3 63 2.3. Terms used in this Document . . . . . . . . . . . . . . . 3 64 3. Packet Timestamp Specification Template . . . . . . . . . . . 4 65 4. Recommended Timestamp Formats . . . . . . . . . . . . . . . . 5 66 4.1. Using a Recommended Timestamp Format . . . . . . . . . . 6 67 4.2. NTP Timestamp Formats . . . . . . . . . . . . . . . . . . 6 68 4.2.1. NTP 64-bit Timestamp Format . . . . . . . . . . . . . 6 69 4.2.2. NTP 32-bit Timestamp Format . . . . . . . . . . . . . 7 70 4.3. The PTP Truncated Timestamp Format . . . . . . . . . . . 9 71 5. Synchronization Aspects . . . . . . . . . . . . . . . . . . . 10 72 6. Timestamp Use Cases . . . . . . . . . . . . . . . . . . . . . 11 73 6.1. Example 1 . . . . . . . . . . . . . . . . . . . . . . . . 12 74 6.2. Example 2 . . . . . . . . . . . . . . . . . . . . . . . . 13 75 7. Packet Timestamp Control Field . . . . . . . . . . . . . . . 13 76 7.1. High-level Control Field Requirements . . . . . . . . . . 14 77 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 78 9. Security Considerations . . . . . . . . . . . . . . . . . . . 15 79 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16 80 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 81 11.1. Normative References . . . . . . . . . . . . . . . . . . 16 82 11.2. Informative References . . . . . . . . . . . . . . . . . 16 83 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 85 1. Introduction 87 Timestamps are widely used in network protocols for various purposes, 88 including delay measurement, clock synchronization, and logging or 89 reporting the time of an event. 91 Timestamps are represented in the RFC series in one of two forms: 92 text-based timestamps, and packet timestamps. Text-based timestamps 93 [RFC3339] are represented as user-friendly strings, and are widely 94 used in the RFC series, for example in information objects and data 95 models, e.g., [RFC5646], [RFC6991], and [RFC7493]. Packet 96 timestamps, on the other hand, are represented by a compact binary 97 field that has a fixed size, and are not intended to have a human- 98 friendly format. Packet timestamps are also very common in the RFC 99 series, and are used for example for measuring delay and for 100 synchronizing clocks, e.g., [RFC5905], [RFC4656], and [RFC1323]. 102 This memo presents guidelines for defining a packet timestamp format 103 in network protocols. Three recommended timestamp formats are 104 presented. It is expected that a new network protocol that requires 105 a packet timestamp will, in most cases, use one of the recommended 106 timestamp formats. If none of the recommended formats fits the 107 protocol requirements, the new protocol specification should specify 108 the format of the packet timestamp according to the guidelines in 109 this document. 111 2. Terminology 113 2.1. Requirements Language 115 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 116 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 117 document are to be interpreted as described in RFC 2119 [RFC2119]. 119 2.2. Abbreviations 121 NTP Network Time Protocol [RFC5905] 123 PTP Precision Time Protocol [IEEE1588] 125 TAI International Atomic Time 127 UTC Coordinated Universal Time 129 2.3. Terms used in this Document 131 Timestamp error: The difference between the timestamp value at 132 the device under test and the value of a 133 reference clock at the same time instant. 135 Timestamp format: The specification of a timestamp, which is 136 represented by a set of attributes that 137 unambiguously define the syntax and semantics 138 of a timestamp. 140 Timestamp accuracy: The mean over an ensemble of measurements of 141 the timestamp error. 143 Timestamp precision: The variation over an ensemble of measurements 144 of the timestamp error. 146 Timestamp resolution: The minimal time unit used for representing 147 the timestamp. 149 3. Packet Timestamp Specification Template 151 This memo recommends to use the timestamp formats defined in 152 Section 4. In cases where these timestamp formats do not satisfy the 153 protocol requirements, the timestamp specification should clearly 154 state the reasons for defining a new format. Moreover, it is 155 recommended to derive the new timestamp format from an existing 156 timestamp format, either a timestamp format from this memo, or any 157 other previously defined timestamp format. 159 The timestamp specification must unambiguously define the syntax and 160 the semantics of the timestamp. The current section defines the 161 minimum set of attributes, but it should be noted that in some cases 162 additional attributes or aspects will need to be defined in the 163 timestamp specification. 165 This section defines a template for specifying packet timestamps. A 166 timestamp format specification MUST include at least the following 167 aspects: 169 Timestamp syntax: 171 The structure of the timestamp field consists of: 173 + Size: The number of bits (or octets) used to represent the 174 packet timestamp field. If the timestamp is comprised of more 175 than one field, the size of each field is specified. 177 Timestamp semantics: 179 + Units: The units used to represent the timestamp. If the 180 timestamp is comprised of more than one field, the units of each 181 field are specified. 183 + Resolution: The timestamp resolution; the resolution is equal to 184 the timestamp field unit. If the timestamp consists of two or 185 more fields using different time units, then the resolution is the 186 smallest time unit. 188 + Wraparound: The wraparound period of the timestamp; any further 189 wraparound-related considerations should be described here. 191 + Epoch: The origin of the timescale used for the timestamp; the 192 moment in time used as a reference for the timestamp value. For 193 example, the epoch may be based on a standard time scale, such as 194 UTC. Another example is a relative timestamp, in which the epoch 195 is the time at which the device using the timestamp was powered 196 up, and is not affected by leap seconds (see the next attribute). 198 + Leap seconds: This subsection specifies whether the timestamp is 199 affected by leap seconds. If the timestamp is affected by leap 200 seconds, then it represents the time elapsed since the epoch minus 201 the number of leap seconds that have occurred since the epoch. 203 4. Recommended Timestamp Formats 205 This memo defines a set of recommended timestamp formats. Defining a 206 relatively small set of recommended formats enables significant 207 reuse; for example, a network protocol may reuse the NTP or PTP 208 timestamp format, allowing a straightforward integration with an NTP 209 or a PTP-based timer. Moreover, since accurate timestamping 210 mechanisms are often implemented in hardware, a new network protocol 211 that reuses an existing timestamp format can be quickly deployed 212 using existing hardware timestamping capabilities. This memo 213 recommends to use one of the timestamp formats specified below. 215 Clearly, different network protocols may have different requirements 216 and constraints, and consequently may use different timestamp 217 formats. The choice of the specific timestamp format for a given 218 protocol may depend on a various factors. A few examples of factors 219 that may affect the choice of the timestamp format: 221 o Timestamp size: while some network protocols use a large timestamp 222 field, in some cases there may be constraints with respect to the 223 timestamp size, affecting the choice of the timestamp format. 225 o Resolution: the time resolution is another factor that may 226 directly affect the selected timestamp format. A potentially 227 important factor in this context is extensibility; it may be 228 desirable to allow a timestamp format to be extensible to a higher 229 resolution by extending the field. For example, the resolution of 230 the NTP 32-bit timestamp format can be improved by extending it to 231 the NTP 64-bit timestamp format in a straightforward way. 233 o Wraparound period: the length of the time interval in which the 234 timestamp is unique may also be an important factor in choosing 235 the timestamp format. Along with the timestamp resolution, these 236 two factors determine the required number of bits in the 237 timestamp. 239 o Common format for multiple protocols: if there are two or more 240 network protocols that use timestamps and are often used together 241 in typical systems, using a common timestamp format should be 242 preferred if possible. Specifically, if the network protocol that 243 is being defined typically runs on a PC, then an NTP-based 244 timestamp format may allow easier integration with an NTP- 245 synchronized timer. In contrast, a protocol that is typically 246 deployed on a hardware-based platform, may make better use of a 247 PTP-based timestamp, allowing more efficient integration with a 248 PTP-synchronized timer. 250 4.1. Using a Recommended Timestamp Format 252 A specification that uses one of the recommended timestamp formats 253 should specify explicitly that this is a recommended timestamp 254 format, and point to the relevant section in the current memo. 256 4.2. NTP Timestamp Formats 258 4.2.1. NTP 64-bit Timestamp Format 260 The Network Time Protocol (NTP) 64-bit timestamp format is defined in 261 [RFC5905]. This timestamp format is used in several network 262 protocols, including [RFC6374], [RFC4656], and [RFC5357]. Since this 263 timestamp format is used in NTP, this timestamp format should be 264 preferred in network protocols that are typically deployed in concert 265 with NTP. 267 The format is presented in this section according to the template 268 defined in Section 3. 270 0 1 2 3 271 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 272 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 273 | Seconds | 274 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 275 | Fraction | 276 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 278 Figure 1: NTP [RFC5905] 64-bit Timestamp Format 280 Timestamp field format: 282 Seconds: specifies the integer portion of the number of seconds 283 since the epoch. 285 + Size: 32 bits. 287 + Units: seconds. 289 Fraction: specifies the fractional portion of the number of 290 seconds since the epoch. 292 + Size: 32 bits. 294 + Units: the unit is 2^(-32) seconds, which is roughly equal to 295 233 picoseconds. 297 Epoch: 299 The epoch is 1 January 1900 at 00:00 UTC. 301 Note: As pointed out in [RFC5905], strictly speaking, UTC did not 302 exist prior to 1 January 1972, but it is convenient to assume it 303 has existed for all eternity. The current epoch implies that the 304 timestamp specifies the number of seconds since 1 January 1972 at 305 00:00 UTC plus 2272060800 (which is the number of seconds between 306 1 January 1900 and 1 January 1972). 308 Leap seconds: 310 This timestamp format is affected by leap seconds. The timestamp 311 represents the number of seconds elapsed since the epoch minus the 312 number of leap seconds. Thus, during and possibly after the 313 occurrence of a leap second, the value of the timestamp may 314 temporarily be ambiguous, as further discussed in Section 5. 316 Resolution: 318 The resolution is 2^(-32) seconds. 320 Wraparound: 322 This time format wraps around every 2^32 seconds, which is roughly 323 136 years. The next wraparound will occur in the year 2036. 325 4.2.2. NTP 32-bit Timestamp Format 327 The Network Time Protocol (NTP) 32-bit timestamp format is defined in 328 [RFC5905]. This timestamp format is used in 329 [I-D.ietf-ippm-initial-registry] and 330 [I-D.ietf-sfc-nsh-dc-allocation]. This timestamp format should be 331 preferred in network protocols that are typically deployed in concert 332 with NTP. The 32-bit format can be used either when space 333 constraints do not allow the use of the 64-bit format, or when the 334 32-bit format satisfies the resolution and wraparound requirements. 336 The format is presented in this section according to the template 337 defined in Section 3. 339 0 1 2 3 340 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 341 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 342 | Seconds | Fraction | 343 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 345 Figure 2: NTP [RFC5905] 32-bit Timestamp Format 347 Timestamp field format: 349 Seconds: specifies the integer portion of the number of seconds 350 since the epoch. 352 + Size: 16 bits. 354 + Units: seconds. 356 Fraction: specifies the fractional portion of the number of 357 seconds since the epoch. 359 + Size: 16 bits. 361 + Units: the unit is 2^(-16) seconds, which is roughly equal to 362 15.3 microseconds. 364 Epoch: 366 The epoch is 1 January 1900 at 00:00 UTC. 368 Note: As pointed out in [RFC5905], strictly speaking, UTC did not 369 exist prior to 1 January 1972, but it is convenient to assume it 370 has existed for all eternity. The current epoch implies that the 371 timestamp specifies the number of seconds since 1 January 1972 at 372 00:00 UTC plus 2272060800 (which is the number of seconds between 373 1 January 1900 and 1 January 1972). 375 Leap seconds: 377 This timestamp format is affected by leap seconds. The timestamp 378 represents the number of seconds elapsed since the epoch minus the 379 number of leap seconds. Thus, during and possibly after the 380 occurrence of a leap second, the value of the timestamp may 381 temporarily be ambiguous, as further discussed in Section 5. 383 Resolution: 385 The resolution is 2^(-16) seconds. 387 Wraparound: 389 This time format wraps around every 2^16 seconds, which is roughly 390 18 hours. 392 4.3. The PTP Truncated Timestamp Format 394 The Precision Time Protocol (PTP) [IEEE1588] uses an 80-bit timestamp 395 format. The truncated timestamp format is a 64-bit field, which is 396 the 64 least significant bits of the 80-bit PTP timestamp. Since 397 this timestamp format is similar to the one used in PTP, this 398 timestamp format should be preferred in network protocols that are 399 typically deployed in PTP-capable devices. 401 The PTP truncated timestamp format was defined in [IEEE1588v1] and is 402 used in several protocols, such as [RFC6374], [RFC7456], [RFC8186] 403 and [ITU-T-Y.1731]. 405 0 1 2 3 406 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 407 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 408 | Seconds | 409 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 410 | Nanoseconds | 411 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 413 Figure 3: PTP [IEEE1588] Truncated Timestamp Format 415 Timestamp field format: 417 Seconds: specifies the integer portion of the number of seconds 418 since the epoch. 420 + Size: 32 bits. 422 + Units: seconds. 424 Nanoseconds: specifies the fractional portion of the number of 425 seconds since the epoch. 427 + Size: 32 bits. 429 + Units: nanoseconds. The value of this field is in the range 0 430 to (10^9)-1. 432 Epoch: 434 The PTP [IEEE1588] epoch is 1 January 1970 00:00:00 TAI. 436 Leap seconds: 438 This timestamp format is not affected by leap seconds. 440 Resolution: 442 The resolution is 1 nanosecond. 444 Wraparound: 446 This time format wraps around every 2^32 seconds, which is roughly 447 136 years. The next wraparound will occur in the year 2106. 449 5. Synchronization Aspects 451 A specification that defines a new timestamp format or uses one of 452 the recommended timestamp formats should include a section on 453 Synchronization Aspects. Examples of such a section can be found in 454 Section 6). 456 The Synchronization Aspects section should specify all the 457 assumptions and requirements related to synchronization. For 458 example, the synchronization aspects may specify whether nodes 459 populating the timestamps should be synchronized among themselves, 460 and whether the timestamp is measured with respect to a central 461 reference clock such as an NTP server. If time is assumed to be 462 synchronized to a time standard such as UTC or TAI, it should be 463 specified in this section. Further considerations may be discussed 464 in this section, such as the required timestamp accuracy. 466 Another aspect that should be discussed in this section is leap 467 second [RFC5905] considerations. The timestamp specification 468 template (Section 3) specifies whether the timestamp is affected by 469 leap seconds. It is often the case that further details about leap 470 seconds will need to be defined in the Synchronization Aspects 471 section. Generally speaking, a leap second is a one-second 472 adjustment that is occasionally applied to UTC in order to keep it 473 aligned to the solar time. A leap second may be either positive or 474 negative, i.e., the clock may either be shifted one second forwards 475 or backwards. All leap seconds that have occurred up to the 476 publication of this document have been in the backwards direction, 477 and although forward leap seconds are theoretically possible, the 478 text throughout this document focuses on the common case, which is 479 the backward leap second. In a timekeeping system that considers 480 leap seconds, the system clock may be affected by a leap second in 481 one of three possible ways: 483 o The clock is turned backwards one second at the end of the leap 484 second. 486 o The clock is frozen during the duration of the leap second. 488 o The clock is slowed down during the leap second and adjacent time 489 intervals until the new time value catches up. The interval for 490 this process, commonly referred to as leap smear, can range from 491 several seconds to several hours before, during, and/or after the 492 occurrence of the leap second. 494 The way leap seconds are handled depends on the synchronization 495 protocol, and is thus not specified in this document. However, if a 496 timestamp format is defined with respect to a timescale that is 497 affected by leap seconds, the Synchronization Aspects section should 498 specify how the use of leap seconds affects the timestamp usage. 500 6. Timestamp Use Cases 502 Packet timestamps are used in various network protocols. Typical 503 applications of packet timestamps include delay measurement, clock 504 synchronization, and others. The following table presents a (non- 505 exhaustive) list of protocols that use packet timestamps, and the 506 timestamp formats used in each of these protocols. 508 +------------------+-----------------------------------+-----------+ 509 | | Recommended formats | Other | 510 +------------------+-----------+-----------+-----------+ format | 511 | Protocol |NTP 64-bit |NTP 32-bit |PTP Trunc. | | 512 +------------------+-----------+-----------+-----------+-----------+ 513 | NTP [RFC5905] | + | | | | 514 +------------------+-----------+-----------+-----------+-----------+ 515 | OWAMP [RFC4656] | + | | | | 516 +------------------+-----------+-----------+-----------+-----------+ 517 | TWAMP [RFC5357] | + | | | | 518 | TWAMP [RFC8186] | | | + | | 519 +------------------+-----------+-----------+-----------+-----------+ 520 | TRILL [RFC7456] | | | + | | 521 +------------------+-----------+-----------+-----------+-----------+ 522 | MPLS [RFC6374] | | | + | | 523 +------------------+-----------+-----------+-----------+-----------+ 524 | TCP [RFC1323] | | | | + | 525 +------------------+-----------+-----------+-----------+-----------+ 526 | RTP [RFC3550] | + | | | + | 527 +------------------+-----------+-----------+-----------+-----------+ 528 | IPFIX [RFC7011] | | | | + | 529 +------------------+-----------+-----------+-----------+-----------+ 530 | [I-D.ietf-ippm- | + | + | | | 531 | initial-registry]| | | | | 532 +------------------+-----------+-----------+-----------+-----------+ 533 | [I-D.ietf-sfc-nsh| | + | + | | 534 | -dc-allocation] | | | | | 535 +------------------+-----------+-----------+-----------+-----------+ 537 Figure 4: Protocols that use Packet Timestamps 539 The rest of this section presents two hypothetic examples of network 540 protocol specifications that use one of the recommended timestamp 541 formats. The examples include the text that specifies the 542 information related to the timestamp format. 544 6.1. Example 1 546 Timestamp: 548 The timestamp format used in this specification is the NTP 549 [RFC5905] 64-bit format, as specified in Section 4.2.1 of 550 [I-D.ietf-ntp-packet-timestamps]. 552 Synchronization aspects: 554 It is assumed that nodes that run this protocol are synchronized 555 to UTC using a synchronization mechanism that is outside the scope 556 of this document. In typical deployments this protocol will run 557 on a machine that uses NTP [RFC5905] for synchronization. Thus, 558 the timestamp may be derived from the NTP-synchronized clock, 559 allowing the timestamp to be measured with respect to the clock of 560 an NTP server. Since the NTP time format is affected by leap 561 seconds, the current timestamp format is similarly affected. 562 Thus, the value of a timestamp during or slightly after a leap 563 second may be temporarily inaccurate. 565 6.2. Example 2 567 Timestamp: 569 The timestamp format used in this specification is the PTP 570 [IEEE1588] Truncated format, as specified in Section 4.3 of 571 [I-D.ietf-ntp-packet-timestamps]. 573 Synchronization aspects: 575 It is assumed that nodes that run this protocol are synchronized 576 among themselves. Nodes may be synchronized to a global reference 577 time. Note that if PTP [IEEE1588] is used for synchronization, 578 the timestamp may be derived from the PTP-synchronized clock, 579 allowing the timestamp to be measured with respect to the clock of 580 an PTP Grandmaster clock. 582 7. Packet Timestamp Control Field 584 In some cases it is desirable to have a control field that describes 585 structure, format, content, and properties of timestamps. Control 586 information about the timestamp format can be conveyed in some 587 protocols using a dedicated control plane protocol, or may be made 588 available at the management plane, for example using a YANG data 589 model. An optional control field allows some of the control 590 information to be attached to the timestamp. 592 An example of a packet timestamp control field is the Error Estimate 593 field, defined by Section 4.1.2 in [RFC4656], which is used in OWAMP 594 [RFC4656] and TWAMP [RFC5357]. 596 This section defines high-level guidelines for defining packet 597 timestamp control fields in network protocols that can benefit from 598 such timestamp-related control information. The word 'requirements' 599 is used in its informal context in this section. 601 7.1. High-level Control Field Requirements 603 A control field for packet timestamps must offer an adequate feature 604 set and fulfill a series of requirements to be usable and accepted. 605 The following list captures the main high-level requirements for 606 timestamp fields. 608 1. Extensible Feature Set: protocols and applications depend on 609 various timestamp characteristics. A timestamp control field 610 must support a variable number of elements (components) that 611 either describe or quantify timestamp-specific characteristics or 612 parameters. Examples of potential elements include timestamp 613 size, encoding, accuracy, leap seconds, reference clock 614 identifiers, etc. 616 2. Size: Essential for an efficient use of timestamp control fields 617 is the trade-off between supported features and control field 618 size. Protocols and applications may select the specific control 619 field elements that are needed for their operation from the set 620 of available elements. 622 3. Composition: Applications may depend on specific control field 623 elements being present in messages. The status of these elements 624 may be either mandatory, conditional mandatory, or optional, 625 depending on the specific application and context. A control 626 field specification must support applications in conveying or 627 negotiating (a) the set of control field elements along with (b) 628 the status of any element (i.e., mandatory, conditional 629 mandatory, or optional) by defining appropriate data structures 630 and identity codes. 632 4. Category: Control field elements can characterize either static 633 timestamp information (like, e.g., timestamp size in bytes and 634 timestamp semantics: NTP 64 bit format) or runtime timestamp 635 information (like, e.g., estimated timestamp accuracy at the time 636 of sampling: 20 microseconds to UTC). For efficiency reason it 637 may be meaningful to support separation of these two concepts: 638 while the former (static) information is typically valid 639 throughout a protocol session and may be conveyed only once, at 640 session establishment time, the latter (runtime) information 641 augments any timestamp instance and may cause substantial 642 overhead for high-traffic protocols. 644 Proposals for timestamp control fields will be defined in separate 645 documents and are out of scope of this memo. 647 8. IANA Considerations 649 This memo includes no request to IANA. 651 9. Security Considerations 653 A network protocol that uses a packet timestamp MUST specify the 654 security considerations that result from using the timestamp. This 655 section provides an overview of some of the common security 656 considerations of using timestamps. 658 Any metadata that is attached to control or data packets, and 659 specifically packet timestamps, can facilitate network 660 reconnaissance; by passively eavesdropping to timestamped packets an 661 attacker can gather information about the network performance, and 662 about the level of synchronization between nodes. 664 Timestamps can be spoofed or modified by on-path attackers, thus 665 attacking the application that uses the timestamps. For example, if 666 timestamps are used in a delay measurement protocol, an attacker can 667 modify en route timestamps in a way that manipulates the measurement 668 results. Integrity protection mechanisms, such as Hashed Message 669 Authentication Codes (HMAC), can mitigate such attacks. The 670 specification of an integrity protection mechanism is outside the 671 scope of this document, as typically integrity protection will be 672 defined on a per-network-protocol basis, and not specifically for the 673 timestamp field. 675 Another potential threat that can have a similar impact is delay 676 attacks. An attacker can maliciously delay some or all of the en 677 route messages, with the same harmful implications as described in 678 the previous paragraph. Mitigating delay attacks is a significant 679 challenge; in contrast to spoofing and modification attacks, the 680 delay attack cannot be prevented by cryptographic integrity 681 protection mechanisms. In some cases delay attacks can be mitigated 682 by sending the timestamped information through multiple paths, 683 allowing to detect and to be resilient to an attacker that has access 684 to one of the paths. 686 In many cases timestamping relies on an underlying synchronization 687 mechanism. Thus, any attack that compromises the synchronization 688 mechanism can also compromise protocols that use timestamping. 689 Attacks on time protocols are discussed in detail in [RFC7384]. 691 10. Acknowledgments 693 The authors thank Yaakov Stein, Greg Mirsky, Warner Losh, Rodney 694 Cummings, Miroslav Lichvar, Denis Reilly, and other members of the 695 NTP working group for many helpful comments. The authors gratefully 696 acknowledge Harlan Stenn and the people from the Network Time 697 Foundation for sharing their thoughts and ideas. 699 11. References 701 11.1. Normative References 703 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 704 Requirement Levels", BCP 14, RFC 2119, 705 DOI 10.17487/RFC2119, March 1997, 706 . 708 11.2. Informative References 710 [I-D.ietf-ippm-initial-registry] 711 Morton, A., Bagnulo, M., Eardley, P., and K. D'Souza, 712 "Initial Performance Metric Registry Entries", draft-ietf- 713 ippm-initial-registry-08 (work in progress), October 2018. 715 [I-D.ietf-ntp-packet-timestamps] 716 Mizrahi, T., Fabini, J., and A. Morton, "Guidelines for 717 Defining Packet Timestamps", draft-ietf-ntp-packet- 718 timestamps-04 (work in progress), October 2018. 720 [I-D.ietf-sfc-nsh-dc-allocation] 721 Guichard, J., Smith, M., Kumar, S., Majee, S., and T. 722 Mizrahi, "Network Service Header (NSH) MD Type 1: Context 723 Header Allocation (Data Center)", draft-ietf-sfc-nsh-dc- 724 allocation-02 (work in progress), September 2018. 726 [IEEE1588] 727 IEEE, "IEEE 1588 Standard for a Precision Clock 728 Synchronization Protocol for Networked Measurement and 729 Control Systems Version 2", 2008. 731 [IEEE1588v1] 732 IEEE, "IEEE 1588 Standard for a Precision Clock 733 Synchronization Protocol for Networked Measurement and 734 Control Systems", 2002. 736 [ITU-T-Y.1731] 737 ITU-T, "OAM functions and mechanisms for Ethernet based 738 Networks", 2013. 740 [RFC1323] Jacobson, V., Braden, R., and D. Borman, "TCP Extensions 741 for High Performance", RFC 1323, DOI 10.17487/RFC1323, May 742 1992, . 744 [RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet: 745 Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002, 746 . 748 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 749 Jacobson, "RTP: A Transport Protocol for Real-Time 750 Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, 751 July 2003, . 753 [RFC4656] Shalunov, S., Teitelbaum, B., Karp, A., Boote, J., and M. 754 Zekauskas, "A One-way Active Measurement Protocol 755 (OWAMP)", RFC 4656, DOI 10.17487/RFC4656, September 2006, 756 . 758 [RFC5357] Hedayat, K., Krzanowski, R., Morton, A., Yum, K., and J. 759 Babiarz, "A Two-Way Active Measurement Protocol (TWAMP)", 760 RFC 5357, DOI 10.17487/RFC5357, October 2008, 761 . 763 [RFC5646] Phillips, A., Ed. and M. Davis, Ed., "Tags for Identifying 764 Languages", BCP 47, RFC 5646, DOI 10.17487/RFC5646, 765 September 2009, . 767 [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, 768 "Network Time Protocol Version 4: Protocol and Algorithms 769 Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010, 770 . 772 [RFC6374] Frost, D. and S. Bryant, "Packet Loss and Delay 773 Measurement for MPLS Networks", RFC 6374, 774 DOI 10.17487/RFC6374, September 2011, 775 . 777 [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", 778 RFC 6991, DOI 10.17487/RFC6991, July 2013, 779 . 781 [RFC7011] Claise, B., Ed., Trammell, B., Ed., and P. Aitken, 782 "Specification of the IP Flow Information Export (IPFIX) 783 Protocol for the Exchange of Flow Information", STD 77, 784 RFC 7011, DOI 10.17487/RFC7011, September 2013, 785 . 787 [RFC7384] Mizrahi, T., "Security Requirements of Time Protocols in 788 Packet Switched Networks", RFC 7384, DOI 10.17487/RFC7384, 789 October 2014, . 791 [RFC7456] Mizrahi, T., Senevirathne, T., Salam, S., Kumar, D., and 792 D. Eastlake 3rd, "Loss and Delay Measurement in 793 Transparent Interconnection of Lots of Links (TRILL)", 794 RFC 7456, DOI 10.17487/RFC7456, March 2015, 795 . 797 [RFC7493] Bray, T., Ed., "The I-JSON Message Format", RFC 7493, 798 DOI 10.17487/RFC7493, March 2015, 799 . 801 [RFC8186] Mirsky, G. and I. Meilik, "Support of the IEEE 1588 802 Timestamp Format in a Two-Way Active Measurement Protocol 803 (TWAMP)", RFC 8186, DOI 10.17487/RFC8186, June 2017, 804 . 806 Authors' Addresses 808 Tal Mizrahi 809 Huawei Network.IO Innovation Lab 810 Israel 812 Email: tal.mizrahi.phd@gmail.com 814 Joachim Fabini 815 TU Wien 816 Gusshausstrasse 25/E389 817 Vienna 1040 818 Austria 820 Phone: +43 1 58801 38813 821 Fax: +43 1 58801 38898 822 Email: Joachim.Fabini@tuwien.ac.at 823 URI: http://www.tc.tuwien.ac.at/about-us/staff/joachim-fabini/ 824 Al Morton 825 AT&T Labs 826 200 Laurel Avenue South 827 Middletown,, NJ 07748 828 USA 830 Phone: +1 732 420 1571 831 Fax: +1 732 368 1192 832 Email: acmorton@att.com 833 URI: http://home.comcast.net/~acmacm/