idnits 2.17.1 draft-mirsky-ippm-hybrid-two-step-13.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 (25 April 2022) is 732 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Downref: Normative reference to an Informational RFC: RFC 2104 == Outdated reference: A later version (-11) exists of draft-ietf-ippm-ioam-direct-export-07 == Outdated reference: A later version (-11) exists of draft-ietf-raw-use-cases-05 == Outdated reference: A later version (-16) exists of draft-song-ippm-postcard-based-telemetry-11 -- Obsolete informational reference (is this intentional?): RFC 8321 (Obsoleted by RFC 9341) -- Obsolete informational reference (is this intentional?): RFC 8889 (Obsoleted by RFC 9342) Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IPPM Working Group G. Mirsky 3 Internet-Draft Ericsson 4 Intended status: Standards Track W. Lingqiang 5 Expires: 27 October 2022 G. Zhui 6 ZTE Corporation 7 H. Song 8 Futurewei Technologies 9 P. Thubert 10 Cisco Systems, Inc 11 25 April 2022 13 Hybrid Two-Step Performance Measurement Method 14 draft-mirsky-ippm-hybrid-two-step-13 16 Abstract 18 Development of, and advancements in, automation of network operations 19 brought new requirements for measurement methodology. Among them is 20 the ability to collect instant network state as the packet being 21 processed by the networking elements along its path through the 22 domain. This document introduces a new hybrid measurement method, 23 referred to as hybrid two-step, as it separates the act of measuring 24 and/or calculating the performance metric from the act of collecting 25 and transporting network state. 27 Status of This Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at https://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on 27 October 2022. 44 Copyright Notice 46 Copyright (c) 2022 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 51 license-info) in effect on the date of publication of this document. 52 Please review these documents carefully, as they describe your rights 53 and restrictions with respect to this document. Code Components 54 extracted from this document must include Revised BSD License text as 55 described in Section 4.e of the Trust Legal Provisions and are 56 provided without warranty as described in the Revised BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 61 2. Conventions used in this document . . . . . . . . . . . . . . 3 62 2.1. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . 3 63 2.2. Requirements Language . . . . . . . . . . . . . . . . . . 4 64 3. Problem Overview . . . . . . . . . . . . . . . . . . . . . . 4 65 4. Theory of Operation . . . . . . . . . . . . . . . . . . . . . 5 66 4.1. Operation of the HTS Ingress Node . . . . . . . . . . . . 7 67 4.2. Operation of the HTS Intermediate Node . . . . . . . . . 9 68 4.3. Operation of the HTS Egress Node . . . . . . . . . . . . 10 69 4.4. Considerations for HTS Timers . . . . . . . . . . . . . . 11 70 4.5. Deploying HTS in a Multicast Network . . . . . . . . . . 11 71 5. Authentication in HTS . . . . . . . . . . . . . . . . . . . . 12 72 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 73 6.1. IOAM Option-Type for HTS . . . . . . . . . . . . . . . . 13 74 6.2. HTS TLV Registry . . . . . . . . . . . . . . . . . . . . 13 75 6.3. HTS Sub-TLV Type Sub-registry . . . . . . . . . . . . . . 14 76 6.4. HMAC Type Sub-registry . . . . . . . . . . . . . . . . . 15 77 7. Security Considerations . . . . . . . . . . . . . . . . . . . 16 78 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16 79 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 80 9.1. Normative References . . . . . . . . . . . . . . . . . . 16 81 9.2. Informative References . . . . . . . . . . . . . . . . . 17 82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 84 1. Introduction 86 Successful resolution of challenges of automated network operation, 87 as part of, for example, overall service orchestration or data center 88 operation, relies on a timely collection of accurate information that 89 reflects the state of network elements on an unprecedented scale. 90 Because performing the analysis and act upon the collected 91 information requires considerable computing and storage resources, 92 the network state information is unlikely to be processed by the 93 network elements themselves but will be relayed into the data storage 94 facilities, e.g., data lakes. The process of producing, collecting 95 network state information also referred to in this document as 96 network telemetry, and transporting it for post-processing should 97 work equally well with data flows or injected in the network test 98 packets. RFC 7799 [RFC7799] describes a combination of elements of 99 passive and active measurement as a hybrid measurement. 101 Several technical methods have been proposed to enable the collection 102 of network state information instantaneous to the packet processing, 103 among them [P4.INT] and [I-D.ietf-ippm-ioam-data]. The 104 instantaneous, i.e., in the data packet itself, collection of 105 telemetry information simplifies the process of attribution of 106 telemetry information to the particular monitored flow. On the other 107 hand, this collection method impacts the data packets, potentially 108 changing their treatment by the networking nodes. Also, the amount 109 of information the instantaneous method collects might be incomplete 110 because of the limited space it can be allotted. Other proposals 111 defined methods to collect telemetry information in a separate packet 112 from each node traversed by the monitored data flow. Examples of 113 this approach to collecting telemetry information are 114 [I-D.ietf-ippm-ioam-direct-export] and 115 [I-D.song-ippm-postcard-based-telemetry]. These methods allow data 116 collection from any arbitrary path and avoid directly impacting data 117 packets. On the other hand, the correlation of data and the 118 monitored flow requires that each packet with telemetry information 119 also includes characteristic information about the monitored flow. 121 This document introduces Hybrid Two-Step (HTS) as a new method of 122 telemetry collection that improvers accuracy of a measurement by 123 separating the act of measuring or calculating the performance metric 124 from the collecting and transporting this information while 125 minimizing the overhead of the generated load in a network. HTS 126 method extends the two-step mode of Residence Time Measurement (RTM) 127 defined in [RFC8169] to on-path network state collection and 128 transport. HTS allows the collection of telemetry information from 129 any arbitrary path, does not change data packets of the monitored 130 flow and makes the process of attribution of telemetry to the data 131 flow simple. 133 2. Conventions used in this document 135 2.1. Acronyms 137 RTM Residence Time Measurement 139 ECMP Equal Cost Multipath 141 MTU Maximum Transmission Unit 143 HTS Hybrid Two-Step 144 HMAC Hashed Message Authentication Code 146 Network telemetry - the process of collecting and reporting of 147 network state 149 2.2. Requirements Language 151 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 152 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 153 "OPTIONAL" in this document are to be interpreted as described in BCP 154 14 [RFC2119] [RFC8174] when, and only when, they appear in all 155 capitals, as shown here. 157 3. Problem Overview 159 Performance measurements are meant to provide data that characterize 160 conditions experienced by traffic flows in the network and possibly 161 trigger operational changes (e.g., re-route of flows, or changes in 162 resource allocations). Modifications to a network are determined 163 based on the performance metric information available when a change 164 is to be made. The correctness of this determination is based on the 165 quality of the collected metrics data. The quality of collected 166 measurement data is defined by: 168 * the resolution and accuracy of each measurement; 170 * predictability of both the time at which each measurement is made 171 and the timeliness of measurement collection data delivery for 172 use. 174 Consider the case of delay measurement that relies on collecting time 175 of packet arrival at the ingress interface and time of the packet 176 transmission at the egress interface. The method includes recording 177 a local clock value on receiving the first octet of an affected 178 message at the device ingress, and again recording the clock value on 179 transmitting the first byte of the same message at the device egress. 180 In this ideal case, the difference between the two recorded clock 181 times corresponds to the time that the message spent in traversing 182 the device. In practice, the time recorded can differ from the ideal 183 case by any fixed amount. A correction can be applied to compute the 184 same time difference taking into account the known fixed time 185 associated with the actual measurement. In this way, the resulting 186 time difference reflects any variable delay associated with queuing. 188 Depending on the implementation, it may be a challenge to compute the 189 difference between message arrival and departure times and - on the 190 fly - add the necessary residence time information to the same 191 message. And that task may become even more challenging if the 192 packet is encrypted. Recording the departure of a packet time in the 193 same packet may be decremental to the accuracy of the measurement 194 because the departure time includes the variable time component (such 195 as that associated with buffering and queuing of the packet). A 196 similar problem may lower the quality of, for example, information 197 that characterizes utilization of the egress interface. If unable to 198 obtain the data consistently, without variable delays for additional 199 processing, information may not accurately reflect the egress 200 interface state. To mitigate this problem [RFC8169] defined an RTM 201 two-step mode. 203 Another challenge associated with methods that collect network state 204 information into the actual data packet is the risk to exceed the 205 Maximum Transmission Unit (MTU) size on the path, especially if the 206 packet traverses overlay domains or VPNs. Since the fragmentation is 207 not available at the transport network, operators may have to reduce 208 MTU size advertised to the client layer or risk missing network state 209 data for the part, most probably the latter part, of the path. 211 In some networks, for example, wireless that are in the scope of 212 [I-D.ietf-raw-use-cases], it is beneficial to collect the telemetry, 213 including the calculated performance metrics, that reflects 214 conditions experienced by the monitored flow at a node, other than 215 the egress. For example, a head-end can optimize path selection 216 based on the compounded information that reflects network conditions, 217 resource utilization. This mode is referred to as the upstream 218 collection and the other - downstream collection to differentiate 219 between two modes of telemetry collection. 221 4. Theory of Operation 223 The HTS method consists of two phases: 225 * performing a measurement and/or obtaining network state 226 information on a node; 228 * collecting and transporting the measurement and/or the telemetry 229 information. 231 HTS may use an HTS Trigger carried in a data packet or a specially 232 constructed test packet. For example, an HTS Trigger could be a 233 packet that has IOAM Option-Type set to the "IOAM Hybrid Two-Step 234 Option-Type" value (TBA1) allocated by IANA (see Section 6.1). The 235 HTS Trigger also includes IOAM Namespace-ID and IOAM-Trace-Type 236 information s defined in Section 5.3 and Section 5.4.1 237 [I-D.ietf-ippm-ioam-data] respectively (shown in Figure 1). A packet 238 in the flow to which the Alternate-Marking method, defined in 239 [RFC8321] and [RFC8889], is applied can be used as an HTS Trigger. 241 The nature of the HTS Trigger is a transport network layer-specific, 242 and its description is outside the scope of this document. The 243 packet that includes the HTS Trigger in this document is also 244 referred to as the trigger packet. 246 0 1 2 3 247 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 248 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 249 | Namespace-ID | Reserved | 250 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 251 | IOAM-Trace-Type | Reserved | 252 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 254 Figure 1: Hybrid Two-Step Trace IOAM Header 256 The HTS method uses the HTS Follow-up packet, referred to as the 257 follow-up packet, to collect measurement and network state data from 258 the nodes. The node that creates the HTS Trigger also generates the 259 HTS Follow-up packet. In some use cases, e.g., when HTS is used to 260 collect the telemetry, including performance metrics, calculated 261 based on a series of measurements, an HTS follow-up packet can be 262 originated without using the HTS Trigger. The follow-up packet 263 contains characteristic information sufficient for participating HTS 264 nodes to associate it with the monitored data flow. The 265 characteristic information can be obtained using the information of 266 the trigger packet or constructed by a node that originates the 267 follow-up packet. As the follow-up packet is expected to traverse 268 the same sequence of nodes, one element of the characteristic 269 information is the information that determines the path in the data 270 plane. For example, in a segment routing domain [RFC8402], a list of 271 segment identifiers of the trigger packet is applied to the follow-up 272 packet. And in the case of the service function chain based on the 273 Network Service Header [RFC8300], the Base Header and Service Path 274 Header of the trigger packet will be applied to the follow-up packet. 275 Also, when HTS is used to collect the telemetry information in an 276 IOAM domain, the IOAM trace option header [I-D.ietf-ippm-ioam-data] 277 of the trigger packet is applied in the follow-up packet. The 278 follow-up packet also uses the same network information used to load- 279 balance flows in equal-cost multipath (ECMP) as the trigger packet, 280 e.g., IPv6 Flow Label [RFC6437] or an entropy label [RFC6790]. The 281 exact composition of the characteristic information is specific for 282 each transport network, and its definition is outside the scope of 283 this document. 285 Only one outstanding follow-up packet MUST be on the node for the 286 given path. That means that if the node receives an HTS Trigger for 287 the flow on which it still waits for the follow-up packet to the 288 previous HTS Trigger, the node will originate the follow-up packet to 289 transport the former set of the network state data and transmit it 290 before it sends the follow-up packet with the latest collection of 291 network state information. 293 The following sections describe the operation of HTS nodes in the 294 downstream mode of collecting the telemetry information. In the 295 upstream mode, the bahavior of HTS nodes, in general, identical with 296 the exception that the HTS Trigger packet does not precede the HTS 297 Follow-up packet. 299 4.1. Operation of the HTS Ingress Node 301 A node that originates the HTS Trigger is referred to as the HTS 302 ingress node. As stated, the ingress node originates the follow-up 303 packet. The follow-up packet has the transport network encapsulation 304 identical with the trigger packet followed by the HTS shim and one or 305 more telemetry information elements encoded as Type-Length-Value 306 {TLV}. Figure 2 displays an example of the follow-up packet format. 308 0 1 2 3 309 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 310 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 311 | | 312 ~ Transport Network ~ 313 | Encapsulation | 314 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 315 |Ver|HTS Shim L | Flags |Sequence Number| Reserved | 316 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 317 | HTS Max Length | 318 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 319 | Telemetry Data Profile | 320 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 321 | | 322 ~ Telemetry Data TLVs ~ 323 | | 324 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 326 Figure 2: Follow-up Packet Format 328 Fields of the HTS shim are as follows: 330 Version (Ver) is the two-bits long field. It specifies the 331 version of the HTS shim format. This document defines the format 332 for the 0b00 value of the field. 334 HTS Shim Length is the six bits-long field. It defines the length 335 of the HTS shim in octets. The minimal value of the field is 336 eight octets. 338 0 339 0 1 2 3 4 5 6 7 340 +-+-+-+-+-+-+-+-+ 341 |F| Reserved | 342 +-+-+-+-+-+-+-+-+ 344 Figure 3: Flags Field Format 346 Flags is eight-bits long. The format of the Flags field displayed 347 in Figure 3. 349 - Full (F) flag MUST be set to zero by the node originating the 350 HTS follow-up packet and MUST be set to one by the node that 351 does not add its telemetry data to avoid exceeding MTU size. 353 - The node originating the follow-up packet MUST zero the 354 Reserved field and ignore it on the receipt. 356 Sequence Number is one octet-long field. The zero-based value of 357 the field reflects the place of the HTS follow-up packet in the 358 sequence of the HTS follow-up packets that originated in response 359 to the same HTS trigger. The ingress node MUST set the value of 360 the field to zero. 362 Reserved is one octet-long field. It MUST be zeroed on 363 transmission and ignored on recepit. 365 HTS Max Length is four octet-long field. The value of th HTS Max 366 Length field indicates the maximum length of the HTS Follow-up 367 packet in octets. An operator MUST be able to configure the HTS 368 Max Length field's value. The value SHOULD be set equal to the 369 path MTU. 371 Telemetry Data Profile is the optional variable-length field of 372 bit-size flags. Each flag indicates the requested type of 373 telemetry data to be collected at each HTS node. The increment of 374 the field is four bytes with a minimum length of zero. For 375 example, IOAM-Trace-Type information defined in 376 [I-D.ietf-ippm-ioam-data] can be used in the Telemetry Data 377 Profile field. 379 0 1 2 3 380 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 381 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 382 | Type | Reserved | Length | 383 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 384 ~ Value ~ 385 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 387 Figure 4: Telemetry Data TLV Format 389 Telemetry Data TLV is a variable-length field. Multiple TLVs MAY 390 be placed in an HTS packet. Additional TLVs may be enclosed 391 within a given TLV, subject to the semantics of the (outer) TLV in 392 question. Figure 4 presents the format of a Telemetry Data TLV, 393 where fields are defined as the following: 395 - Type - a one-octet-long field that characterizes the 396 interpretation of the Value field. 398 - Reserved - one-octet-long field. 400 - Length - two-octet-long field equal to the length of the Value 401 field in octets. 403 - Value - a variable-length field. The value of the Type field 404 determines its interpretation and encoding. IOAM data fields, 405 defined in [I-D.ietf-ippm-ioam-data], MAY be carried in the 406 Value field. 408 All multibyte fields defined in this specification are in network 409 byte order. 411 4.2. Operation of the HTS Intermediate Node 413 Upon receiving the trigger packet, the HTS intermediate node MUST: 415 * copy the transport information; 417 * start the HTS Follow-up Timer for the obtained flow; 419 * transmit the trigger packet. 421 Upon receiving the follow-up packet, the HTS intermediate node MUST: 423 1. verify that the matching transport information exists and the 424 Full flag is cleared, then stop the associated HTS Follow-up 425 Timer; 427 2. otherwise, transmit the received packet. Proceed to Step 8; 429 3. collect telemetry data requested in the Telemetry Data Profile 430 field or defined by the local HTS policy; 432 4. if adding the collected telemetry would not exceed HTS Max Length 433 field's value, then append data as a new Telemetry Data TLV and 434 transmit the follow-up packet. Proceed to Step 8; 436 5. otherwise, set the value of the Full flag to one, copy the 437 transport information from the received follow-up packet and 438 transmit it accordingly. Proceed to Step 8; 440 6. originate the new follow-up packet using the transport 441 information copied from the received follow-up packet. The value 442 of the Sequence Number field in the HTS shim MUST be set to the 443 value of the field in the received follow-up packet incremented 444 by one; 446 7. copy collected telemetry data into the first Telemetry Data TLV's 447 Value field and then transmit the packet; 449 8. processing completed. 451 If the HTS Follow-up Timer expires, the intermediate node MUST: 453 * originate the follow-up packet using transport information 454 associated with the expired timer; 456 * initialize the HTS shim by setting the Version field's value to 457 0b00 and Sequence Number field to 0. Values of HTS Shim Length 458 and Telemetry Data Profile fields MAY be set according to the 459 local policy. 461 * copy telemetry information into Telemetry Data TLV's Value field 462 and transmit the packet. 464 If the intermediate node receives a "late" follow-up packet, i.e., a 465 packet to which the node has no associated HTS Follow-up timer, the 466 node MUST forward the "late" packet. 468 4.3. Operation of the HTS Egress Node 470 Upon receiving the trigger packet, the HTS egress node MUST: 472 * copy the transport information; 474 * start the HTS Collection timer for the obtained flow. 476 When the egress node receives the follow-up packet for the known 477 flow, i.e., the flow to which the Collection timer is running, the 478 node for each of Telemetry Data TLVs MUST: 480 * if HTS is used in the authenticated mode, verify the 481 authentication of the Telemetry Data TLV using the Authentication 482 sub-TLV (see Section 5); 484 * copy telemetry information from the Value field; 486 * restart the corresponding Collection timer. 488 When the Collection timer expires, the egress relays the collected 489 telemetry information for processing and analysis to a local or 490 remote agent. 492 4.4. Considerations for HTS Timers 494 This specification defines two timers - HTS Follow-up and HTS 495 Collection. For the particular flow, there MUST be no more than one 496 HTS Trigger, values of HTS timers bounded by the rate of the trigger 497 generation for that flow. 499 4.5. Deploying HTS in a Multicast Network 501 Previous sections discussed the operation of HTS in a unicast 502 network. Multicast services are important, and the ability to 503 collect telemetry information is invaluable in delivering a high 504 quality of experience. While the replication of data packets is 505 necessary, replication of HTS follow-up packets is not. Replication 506 of multicast data packets down a multicast tree may be set based on 507 multicast routing information or explicit information included in the 508 special header, as, for example, in Bit-Indexed Explicit Replication 509 [RFC8296]. A replicating node processes the HTS packet as defined 510 below: 512 * the first transmitted multicast packet MUST be followed by the 513 received corresponding HTS packet as described in Section 4.2; 515 * each consecutively transmitted copy of the original multicast 516 packet MUST be followed by the new HTS packet originated by the 517 replicating node that acts as an intermediate HTS node when the 518 HTS Follow-up timer expired. 520 As a result, there are no duplicate copies of Telemetry Data TLV for 521 the same pair of ingress and egress interfaces. At the same time, 522 all ingress/egress pairs traversed by the given multicast packet 523 reflected in their respective Telemetry Data TLV. Consequently, a 524 centralized controller would reconstruct and analyze the state of the 525 particular multicast distribution tree based on HTS packets collected 526 from egress nodes. 528 5. Authentication in HTS 530 Telemetry information may be used to drive network operation, closing 531 the control loop for self-driving, self-healing networks. Thus it is 532 critical to provide a mechanism to protect the telemetry information 533 collected using the HTS method. This document defines an optional 534 authentication of a Telemetry Data TLV that protects the collected 535 information's integrity. 537 The format of the Authentication sub-TLV is displayed in Figure 5. 539 0 1 2 3 540 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 541 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 542 |Authentic. Type| HMAC Type | Length | 543 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 544 | | 545 | Digest | 546 | | 547 | | 548 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 550 Figure 5: HMAC sub-TLV 552 where fields are defined as follows: 554 * Authentication Type - is a one-octet-long field, value TBA2 555 allocated by IANA Section 6.2. 557 * Length - two-octet-long field, set equal to the length of the 558 Digest field in octets. 560 * HMAC Type - is a one-octet-long field that identifies the type of 561 the HMAC and the length of the digest and the length of the digest 562 according to the HTS HMAC Type sub-registry (see Section 6.4). 564 * Digest - is a variable-length field that carries HMAC digest of 565 the text that includes the encompassing TLV. 567 This specification defines the use of HMAC-SHA-256 truncated to 128 568 bits ([RFC4868]) in HTS. Future specifications may define the use in 569 HTS of more advanced cryptographic algorithms or the use of digest of 570 a different length. HMAC is calculated as defined in [RFC2104] over 571 text as the concatenation of the Sequence Number field of the follow- 572 up packet (see Figure 2) and the preceding data collected in the 573 Telemetry Data TLV. The digest then MUST be truncated to 128 bits 574 and written into the Digest field. Distribution and management of 575 shared keys are outside the scope of this document. In the HTS 576 authenticated mode, the Authentication sub-TLV MUST be present in 577 each Telemetry Data TLV. HMAC MUST be verified before using any data 578 in the included Telemetry Data TLV. If HMAC verification fails, the 579 system MUST stop processing corresponding Telemetry Data TLV and 580 notify an operator. Specification of the notification mechanism is 581 outside the scope of this document. 583 6. IANA Considerations 585 6.1. IOAM Option-Type for HTS 587 The IOAM Option-Type registry is requested in 588 [I-D.ietf-ippm-ioam-data]. IANA is requested to allocate a new code 589 point as listed in Table 1. 591 +=======+==================================+===============+ 592 | Value | Description | Reference | 593 +=======+==================================+===============+ 594 | TBA1 | IOAM Hybrid Two-Step Option-Type | This document | 595 +-------+----------------------------------+---------------+ 597 Table 1: IOAM Option-Type for HTS 599 6.2. HTS TLV Registry 601 IANA is requested to create the HTS TLV Type registry. All code 602 points in the range 1 through 175 in this registry shall be allocated 603 according to the "IETF Review" procedure specified in [RFC8126]. 604 Code points in the range 176 through 239 in this registry shall be 605 allocated according to the "First Come First Served" procedure 606 specified in [RFC8126]. The remaining code points are allocated 607 according to Table 2: 609 +===========+==============+===============+ 610 | Value | Description | Reference | 611 +===========+==============+===============+ 612 | 0 | Reserved | This document | 613 +-----------+--------------+---------------+ 614 | 1- 175 | Unassigned | This document | 615 +-----------+--------------+---------------+ 616 | 176 - 239 | Unassigned | This document | 617 +-----------+--------------+---------------+ 618 | 240 - 251 | Experimental | This document | 619 +-----------+--------------+---------------+ 620 | 252 - 254 | Private Use | This document | 621 +-----------+--------------+---------------+ 622 | 255 | Reserved | This document | 623 +-----------+--------------+---------------+ 625 Table 2: HTS TLV Type Registry 627 6.3. HTS Sub-TLV Type Sub-registry 629 IANA is requested to create the HTS sub-TLV Type sub-registry as part 630 of the HTS TLV Type registry. All code points in the range 1 through 631 175 in this registry shall be allocated according to the "IETF 632 Review" procedure specified in [RFC8126]. Code points in the range 633 176 through 239 in this registry shall be allocated according to the 634 "First Come First Served" procedure specified in [RFC8126]. The 635 remaining code points are allocated according to Table 3: 637 +===========+==============+===============+ 638 | Value | Description | Reference | 639 +===========+==============+===============+ 640 | 0 | Reserved | This document | 641 +-----------+--------------+---------------+ 642 | 1- 175 | Unassigned | This document | 643 +-----------+--------------+---------------+ 644 | 176 - 239 | Unassigned | This document | 645 +-----------+--------------+---------------+ 646 | 240 - 251 | Experimental | This document | 647 +-----------+--------------+---------------+ 648 | 252 - 254 | Private Use | This document | 649 +-----------+--------------+---------------+ 650 | 255 | Reserved | This document | 651 +-----------+--------------+---------------+ 653 Table 3: HTS Sub-TLV Type Sub-registry 655 This document defines the following new values in the IETF Review 656 range of the HTS sub-TLV Type sub-registry: 658 +=======+=============+==========+===============+ 659 | Value | Description | TLV Used | Reference | 660 +=======+=============+==========+===============+ 661 | TBA2 | HMAC | Any | This document | 662 +-------+-------------+----------+---------------+ 664 Table 4: HTS sub-TLV Types 666 6.4. HMAC Type Sub-registry 668 IANA is requested to create the HMAC Type sub-registry as part of the 669 HTS TLV Type registry. All code points in the range 1 through 127 in 670 this registry shall be allocated according to the "IETF Review" 671 procedure specified in [RFC8126]. Code points in the range 128 672 through 239 in this registry shall be allocated according to the 673 "First Come First Served" procedure specified in [RFC8126]. The 674 remaining code points are allocated according to Table 5: 676 +===========+==============+===============+ 677 | Value | Description | Reference | 678 +===========+==============+===============+ 679 | 0 | Reserved | This document | 680 +-----------+--------------+---------------+ 681 | 1- 127 | Unassigned | This document | 682 +-----------+--------------+---------------+ 683 | 128 - 239 | Unassigned | This document | 684 +-----------+--------------+---------------+ 685 | 240 - 249 | Experimental | This document | 686 +-----------+--------------+---------------+ 687 | 250 - 254 | Private Use | This document | 688 +-----------+--------------+---------------+ 689 | 255 | Reserved | This document | 690 +-----------+--------------+---------------+ 692 Table 5: HMAC Type Sub-registry 694 This document defines the following new values in the HMAC Type sub- 695 registry: 697 +=======+=============================+===============+ 698 | Value | Description | Reference | 699 +=======+=============================+===============+ 700 | 1 | HMAC-SHA-256 16 octets long | This document | 701 +-------+-----------------------------+---------------+ 703 Table 6: HMAC Types 705 7. Security Considerations 707 Nodes that practice the HTS method are presumed to share a trust 708 model that depends on the existence of a trusted relationship among 709 nodes. This is necessary as these nodes are expected to correctly 710 modify the specific content of the data in the follow-up packet, and 711 the degree to which HTS measurement is useful for network operation 712 depends on this ability. In practice, this means either 713 confidentiality or integrity protection cannot cover those portions 714 of messages that contain the network state data. Though there are 715 methods that make it possible in theory to provide either or both 716 such protections and still allow for intermediate nodes to make 717 detectable yet authenticated modifications, such methods do not seem 718 practical at present, particularly for protocols that used to measure 719 latency and/or jitter. 721 This document defines the use of authentication (Section 5) to 722 protect the integrity of the telemetry information collected using 723 the HTS method. Privacy protection can be achieved by, for example, 724 sharing the IPsec tunnel with a data flow that generates information 725 that is collected using HTS. 727 While it is possible for a supposed compromised node to intercept and 728 modify the network state information in the follow-up packet; this is 729 an issue that exists for nodes in general - for all data that to be 730 carried over the particular networking technology - and is therefore 731 the basis for an additional presumed trust model associated with an 732 existing network. 734 8. Acknowledgments 736 Authors express their gratitude and appreciation to Joel Halpern for 737 the most helpful and insightful discussion on the applicability of 738 HTS in a Service Function Chaining domain. 740 9. References 742 9.1. Normative References 744 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 745 Hashing for Message Authentication", RFC 2104, 746 DOI 10.17487/RFC2104, February 1997, 747 . 749 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 750 Requirement Levels", BCP 14, RFC 2119, 751 DOI 10.17487/RFC2119, March 1997, 752 . 754 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 755 Writing an IANA Considerations Section in RFCs", BCP 26, 756 RFC 8126, DOI 10.17487/RFC8126, June 2017, 757 . 759 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 760 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 761 May 2017, . 763 9.2. Informative References 765 [I-D.ietf-ippm-ioam-data] 766 Brockners, F., Bhandari, S., and T. Mizrahi, "Data Fields 767 for In-situ OAM", Work in Progress, Internet-Draft, draft- 768 ietf-ippm-ioam-data-17, 13 December 2021, 769 . 772 [I-D.ietf-ippm-ioam-direct-export] 773 Song, H., Gafni, B., Zhou, T., Li, Z., Brockners, F., 774 Bhandari, S., Sivakolundu, R., and T. Mizrahi, "In-situ 775 OAM Direct Exporting", Work in Progress, Internet-Draft, 776 draft-ietf-ippm-ioam-direct-export-07, 13 October 2021, 777 . 780 [I-D.ietf-raw-use-cases] 781 Bernardos, C. J., Papadopoulos, G. Z., Thubert, P., and F. 782 Theoleyre, "RAW use-cases", Work in Progress, Internet- 783 Draft, draft-ietf-raw-use-cases-05, 23 February 2022, 784 . 787 [I-D.song-ippm-postcard-based-telemetry] 788 Song, H., Mirsky, G., Filsfils, C., Abdelsalam, A., Zhou, 789 T., Li, Z., Shin, J., and K. Lee, "In-Situ OAM Marking- 790 based Direct Export", Work in Progress, Internet-Draft, 791 draft-song-ippm-postcard-based-telemetry-11, 15 November 792 2021, . 795 [P4.INT] "In-band Network Telemetry (INT)", P4.org Specification, 796 October 2017. 798 [RFC4868] Kelly, S. and S. Frankel, "Using HMAC-SHA-256, HMAC-SHA- 799 384, and HMAC-SHA-512 with IPsec", RFC 4868, 800 DOI 10.17487/RFC4868, May 2007, 801 . 803 [RFC6437] Amante, S., Carpenter, B., Jiang, S., and J. Rajahalme, 804 "IPv6 Flow Label Specification", RFC 6437, 805 DOI 10.17487/RFC6437, November 2011, 806 . 808 [RFC6790] Kompella, K., Drake, J., Amante, S., Henderickx, W., and 809 L. Yong, "The Use of Entropy Labels in MPLS Forwarding", 810 RFC 6790, DOI 10.17487/RFC6790, November 2012, 811 . 813 [RFC7799] Morton, A., "Active and Passive Metrics and Methods (with 814 Hybrid Types In-Between)", RFC 7799, DOI 10.17487/RFC7799, 815 May 2016, . 817 [RFC8169] Mirsky, G., Ruffini, S., Gray, E., Drake, J., Bryant, S., 818 and A. Vainshtein, "Residence Time Measurement in MPLS 819 Networks", RFC 8169, DOI 10.17487/RFC8169, May 2017, 820 . 822 [RFC8296] Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A., 823 Tantsura, J., Aldrin, S., and I. Meilik, "Encapsulation 824 for Bit Index Explicit Replication (BIER) in MPLS and Non- 825 MPLS Networks", RFC 8296, DOI 10.17487/RFC8296, January 826 2018, . 828 [RFC8300] Quinn, P., Ed., Elzur, U., Ed., and C. Pignataro, Ed., 829 "Network Service Header (NSH)", RFC 8300, 830 DOI 10.17487/RFC8300, January 2018, 831 . 833 [RFC8321] Fioccola, G., Ed., Capello, A., Cociglio, M., Castaldelli, 834 L., Chen, M., Zheng, L., Mirsky, G., and T. Mizrahi, 835 "Alternate-Marking Method for Passive and Hybrid 836 Performance Monitoring", RFC 8321, DOI 10.17487/RFC8321, 837 January 2018, . 839 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 840 Decraene, B., Litkowski, S., and R. Shakir, "Segment 841 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 842 July 2018, . 844 [RFC8889] Fioccola, G., Ed., Cociglio, M., Sapio, A., and R. Sisto, 845 "Multipoint Alternate-Marking Method for Passive and 846 Hybrid Performance Monitoring", RFC 8889, 847 DOI 10.17487/RFC8889, August 2020, 848 . 850 Authors' Addresses 852 Greg Mirsky 853 Ericsson 854 Email: gregimirsky@gmail.com 856 Wang Lingqiang 857 ZTE Corporation 858 No 19 ,East Huayuan Road 859 Beijing 860 Phone: +86 10 82963945 861 Email: wang.lingqiang@zte.com.cn 863 Guo Zhui 864 ZTE Corporation 865 No 19 ,East Huayuan Road 866 Beijing 867 Phone: +86 10 82963945 868 Email: guo.zhui@zte.com.cn 870 Haoyu Song 871 Futurewei Technologies 872 2330 Central Expressway 873 Santa Clara, 874 United States of America 875 Email: hsong@futurewei.com 877 Pascal Thubert 878 Cisco Systems, Inc 879 Building D 880 45 Allee des Ormes - BP1200 881 06254 MOUGINS - Sophia Antipolis 882 France 883 Phone: +33 497 23 26 34 884 Email: pthubert@cisco.com