idnits 2.17.1 draft-mirsky-ippm-hybrid-two-step-10.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 (17 May 2021) is 1074 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 (-17) exists of draft-ietf-ippm-ioam-data-12 == Outdated reference: A later version (-11) exists of draft-ietf-ippm-ioam-direct-export-03 == Outdated reference: A later version (-16) exists of draft-song-ippm-postcard-based-telemetry-09 -- Obsolete informational reference (is this intentional?): RFC 8321 (Obsoleted by RFC 9341) Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IPPM Working Group G. Mirsky 3 Internet-Draft ZTE Corp. 4 Intended status: Standards Track W. Lingqiang 5 Expires: 18 November 2021 G. Zhui 6 ZTE Corporation 7 H. Song 8 Futurewei Technologies 9 17 May 2021 11 Hybrid Two-Step Performance Measurement Method 12 draft-mirsky-ippm-hybrid-two-step-10 14 Abstract 16 Development of, and advancements in, automation of network operations 17 brought new requirements for measurement methodology. Among them is 18 the ability to collect instant network state as the packet being 19 processed by the networking elements along its path through the 20 domain. This document introduces a new hybrid measurement method, 21 referred to as hybrid two-step, as it separates the act of measuring 22 and/or calculating the performance metric from the act of collecting 23 and transporting network state. 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 18 November 2021. 42 Copyright Notice 44 Copyright (c) 2021 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 (https://trustee.ietf.org/ 49 license-info) in effect on the date of publication of this document. 50 Please review these documents carefully, as they describe your rights 51 and restrictions with respect to this document. Code Components 52 extracted from this document must include Simplified BSD License text 53 as described in Section 4.e of the Trust Legal Provisions and are 54 provided without warranty as described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 59 2. Conventions used in this document . . . . . . . . . . . . . . 3 60 2.1. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . 3 61 2.2. Requirements Language . . . . . . . . . . . . . . . . . . 4 62 3. Problem Overview . . . . . . . . . . . . . . . . . . . . . . 4 63 4. Theory of Operation . . . . . . . . . . . . . . . . . . . . . 5 64 4.1. Operation of the HTS Ingress Node . . . . . . . . . . . . 6 65 4.2. Operation of the HTS Intermediate Node . . . . . . . . . 8 66 4.3. Operation of the HTS Egress Node . . . . . . . . . . . . 9 67 4.4. Considerations for HTS Timers . . . . . . . . . . . . . . 10 68 4.5. Deploying HTS in a Multicast Network . . . . . . . . . . 10 69 5. Authentication in HTS . . . . . . . . . . . . . . . . . . . . 11 70 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 71 6.1. IOAM Option-Type for HTS . . . . . . . . . . . . . . . . 12 72 6.2. HTS TLV Registry . . . . . . . . . . . . . . . . . . . . 12 73 6.3. HTS Sub-TLV Type Sub-registry . . . . . . . . . . . . . . 13 74 6.4. HMAC Type Sub-registry . . . . . . . . . . . . . . . . . 14 75 7. Security Considerations . . . . . . . . . . . . . . . . . . . 15 76 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15 77 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 78 9.1. Normative References . . . . . . . . . . . . . . . . . . 15 79 9.2. Informative References . . . . . . . . . . . . . . . . . 16 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 82 1. Introduction 84 Successful resolution of challenges of automated network operation, 85 as part of, for example, overall service orchestration or data center 86 operation, relies on a timely collection of accurate information that 87 reflects the state of network elements on an unprecedented scale. 88 Because performing the analysis and act upon the collected 89 information requires considerable computing and storage resources, 90 the network state information is unlikely to be processed by the 91 network elements themselves but will be relayed into the data storage 92 facilities, e.g., data lakes. The process of producing, collecting 93 network state information also referred to in this document as 94 network telemetry, and transporting it for post-processing should 95 work equally well with data flows or injected in the network test 96 packets. RFC 7799 [RFC7799] describes a combination of elements of 97 passive and active measurement as a hybrid measurement. 99 Several technical methods have been proposed to enable the collection 100 of network state information instantaneous to the packet processing, 101 among them [P4.INT] and [I-D.ietf-ippm-ioam-data]. The 102 instantaneous, i.e., in the data packet itself, collection of 103 telemetry information simplifies the process of attribution of 104 telemetry information to the particular monitored flow. On the other 105 hand, this collection method impacts the data packets, potentially 106 changing their treatment by the networking nodes. Also, the amount 107 of information the instantaneous method collects might be incomplete 108 because of the limited space it can be allotted. Other proposals 109 defined methods to collect telemetry information in a separate packet 110 from each node traversed by the monitored data flow. Examples of 111 this approach to collecting telemetry information are 112 [I-D.ietf-ippm-ioam-direct-export] and 113 [I-D.song-ippm-postcard-based-telemetry]. These methods allow data 114 collection from any arbitrary path and avoid directly impacting data 115 packets. On the other hand, the correlation of data and the 116 monitored flow requires that each packet with telemetry information 117 also includes characteristic information about the monitored flow. 119 This document introduces Hybrid Two-Step (HTS) as a new method of 120 telemetry collection that improvers accuracy of a measurement by 121 separating the act of measuring or calculating the performance metric 122 from the collecting and transporting this information while 123 minimizing the overhead of the generated load in a network. HTS 124 method extends the two-step mode of Residence Time Measurement (RTM) 125 defined in [RFC8169] to on-path network state collection and 126 transport. HTS allows the collection of telemetry information from 127 any arbitrary path, does not change data packets of the monitored 128 flow and makes the process of attribution of telemetry to the data 129 flow simple. 131 2. Conventions used in this document 133 2.1. Acronyms 135 RTM Residence Time Measurement 137 ECMP Equal Cost Multipath 139 MTU Maximum Transmission Unit 141 HTS Hybrid Two-Step 142 HMAC Hashed Message Authentication Code 144 Network telemetry - the process of collecting and reporting of 145 network state 147 2.2. 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 3. Problem Overview 157 Performance measurements are meant to provide data that characterize 158 conditions experienced by traffic flows in the network and possibly 159 trigger operational changes (e.g., re-route of flows, or changes in 160 resource allocations). Modifications to a network are determined 161 based on the performance metric information available when a change 162 is to be made. The correctness of this determination is based on the 163 quality of the collected metrics data. The quality of collected 164 measurement data is defined by: 166 * the resolution and accuracy of each measurement; 168 * predictability of both the time at which each measurement is made 169 and the timeliness of measurement collection data delivery for 170 use. 172 Consider the case of delay measurement that relies on collecting time 173 of packet arrival at the ingress interface and time of the packet 174 transmission at the egress interface. The method includes recording 175 a local clock value on receiving the first octet of an affected 176 message at the device ingress, and again recording the clock value on 177 transmitting the first byte of the same message at the device egress. 178 In this ideal case, the difference between the two recorded clock 179 times corresponds to the time that the message spent in traversing 180 the device. In practice, the time recorded can differ from the ideal 181 case by any fixed amount. A correction can be applied to compute the 182 same time difference taking into account the known fixed time 183 associated with the actual measurement. In this way, the resulting 184 time difference reflects any variable delay associated with queuing. 186 Depending on the implementation, it may be a challenge to compute the 187 difference between message arrival and departure times and - on the 188 fly - add the necessary residence time information to the same 189 message. And that task may become even more challenging if the 190 packet is encrypted. Recording the departure of a packet time in the 191 same packet may be decremental to the accuracy of the measurement 192 because the departure time includes the variable time component (such 193 as that associated with buffering and queuing of the packet). A 194 similar problem may lower the quality of, for example, information 195 that characterizes utilization of the egress interface. If unable to 196 obtain the data consistently, without variable delays for additional 197 processing, information may not accurately reflect the egress 198 interface state. To mitigate this problem [RFC8169] defined an RTM 199 two-step mode. 201 Another challenge associated with methods that collect network state 202 information into the actual data packet is the risk to exceed the 203 Maximum Transmission Unit (MTU) size, especially if the packet 204 traverses overlay domains or VPNs. Since the fragmentation is not 205 available at the transport network, operators may have to reduce MTU 206 size advertised to the client layer or risk missing network state 207 data for the part, most probably the latter part, of the path. 209 4. Theory of Operation 211 The HTS method consists of two phases: 213 * performing a measurement or obtaining network state information, 214 one or more than one type, on a node; 216 * collecting and transporting the measurement. 218 HTS uses HTS Trigger carried in a data packet or a specially 219 constructed test packet. For example, an HTS Trigger could be a 220 packet that has IOAM Option-Type set to the "IOAM Hybrid Two-Step 221 Option-Type" value (TBA1) allocated by IANA (see Section 6.1). The 222 HTS Trigger also includes IOAM Namespace-ID and IOAM-Trace-Type 223 information [I-D.ietf-ippm-ioam-data]. A packet in the flow to which 224 the Alternate-Marking method [RFC8321] is applied can be used as an 225 HTS Trigger. The nature of the HTS Trigger is a transport network 226 layer-specific, and its description is outside the scope of this 227 document. The packet that includes the HTS Trigger in this document 228 is also referred to as the trigger packet. 230 The HTS method uses the HTS Follow-up packet, referred to as the 231 follow-up packet, to collect measurement and network state data from 232 the nodes. The node that creates the HTS Trigger also generates the 233 HTS Follow-up packet. The follow-up packet contains characteristic 234 information, copied from the trigger packet, sufficient for 235 participating HTS nodes to associate it with the original packet. As 236 the follow-up packet is expected to traverse the same sequence of 237 nodes, one element of the characteristic information is the 238 information that determines the path in the data plane. For example, 239 in a segment routing domain [RFC8402], a list of segment identifiers 240 of the trigger packet is applied to the follow-up packet. And in the 241 case of the service function chain based on the Network Service 242 Header [RFC8300], the Base Header and Service Path Header of the 243 trigger packet will be applied to the follow-up packet. Also, when 244 HTS is used to collect the telemetry information in an IOAM domain, 245 the IOAM trace option header [I-D.ietf-ippm-ioam-data] of the trigger 246 packet is applied in the follow-up packet. The follow-up packet also 247 uses the same network information used to load-balance flows in 248 equal-cost multipath (ECMP) as the trigger packet, e.g., IPv6 Flow 249 Label [RFC6437] or an entropy label [RFC6790]. The exact composition 250 of the characteristic information is specific for each transport 251 network, and its definition is outside the scope of this document. 253 Only one outstanding follow-up packet MUST be on the node for the 254 given path. That means that if the node receives an HTS Trigger for 255 the flow on which it still waits for the follow-up packet to the 256 previous HTS Trigger, the node will originate the follow-up packet to 257 transport the former set of the network state data and transmit it 258 before it sends the follow-up packet with the latest collection of 259 network state information. 261 4.1. Operation of the HTS Ingress Node 263 A node that originates the HTS Trigger is referred to as the HTS 264 ingress node. As stated, the ingress node originates the follow-up 265 packet. The follow-up packet has the transport network encapsulation 266 identical with the trigger packet followed by the HTS shim and one or 267 more telemetry information elements encoded as Type-Length-Value 268 {TLV}. Figure 1 displays an example of the follow-up packet format. 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 | | 274 ~ Transport Network ~ 275 | Encapsulation | 276 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 277 |Ver|HTS Shim Len| Flags | Sequence Number | 278 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 279 | Telemetry Data Profile | 280 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 281 | | 282 ~ Telemetry Data TLVs ~ 283 | | 284 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 285 Figure 1: Follow-up Packet Format 287 Fields of the HTS shim are as follows: 289 Version (Ver) is the two-bits long field. It specifies the 290 version of the HTS shim format. This document defines the format 291 for the 0b00 value of the field. 293 HTS Shim Length is the six bits-long field. It defines the length 294 of the HTS shim in bytes. The minimal value of the field is four 295 bytes. 297 0 298 0 1 2 3 4 5 6 7 299 +-+-+-+-+-+-+-+-+ 300 |F| Reserved | 301 +-+-+-+-+-+-+-+-+ 303 Figure 2: Flags Field Format 305 Flags is eight-bits long. The format of the Flags field displayed 306 in Figure 2. 308 - Full (F) flag MUST be set to zero by the node originating the 309 HTS follow-up packet and MUST be set to one by the node that 310 does not add its telemetry data to avoid exceeding MTU size. 312 - The node originating the follow-up packet MUST zero the 313 Reserved field and ignore it on the receipt. 315 Sequence Number is 16 bits-long field. The zero-based value of 316 the field reflects the place of the HTS follow-up packet in the 317 sequence of the HTS follow-up packets that originated in response 318 to the same HTS trigger. The ingress node MUST set the value of 319 the field to zero. 321 Telemetry Data Profile is the optional variable-length field of 322 bit-size flags. Each flag indicates the requested type of 323 telemetry data to be collected at each HTS node. The increment of 324 the field is four bytes with a minimum length of zero. For 325 example, IOAM-Trace-Type information defined in 326 [I-D.ietf-ippm-ioam-data] can be used in the Telemetry Data 327 Profile field. 329 0 1 2 3 330 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 331 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 332 | Type | Reserved | Length | 333 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 334 ~ Value ~ 335 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 337 Figure 3: Telemetry Data TLV Format 339 Telemetry Data TLV is a variable-length field. Multiple TLVs MAY 340 be placed in an HTS packet. Additional TLVs may be enclosed 341 within a given TLV, subject to the semantics of the (outer) TLV in 342 question. Figure 3 presents the format of a Telemetry Data TLV, 343 where fields are defined as the following: 345 - Type - a one-octet-long field that characterizes the 346 interpretation of the Value field. 348 - Reserved - one-octet-long field. 350 - Length - two-octet-long field equal to the length of the Value 351 field in octets. 353 - Value - a variable-length field. The value of the Type field 354 determines its interpretation and encoding. IOAM data fields, 355 defined in [I-D.ietf-ippm-ioam-data], MAY be carried in the 356 Value field. 358 All multibyte fields defined in this specification are in network 359 byte order. 361 4.2. Operation of the HTS Intermediate Node 363 Upon receiving the trigger packet, the HTS intermediate node MUST: 365 * copy the transport information; 367 * start the HTS Follow-up Timer for the obtained flow; 369 * transmit the trigger packet. 371 Upon receiving the follow-up packet, the HTS intermediate node MUST: 373 1. verify that the matching transport information exists and the 374 Full flag is cleared, then stop the associated HTS Follow-up 375 Timer; 377 2. otherwise, transmit the received packet. Proceed to Step 8; 379 3. collect telemetry data requested in the Telemetry Data Profile 380 field or defined by the local HTS policy; 382 4. if adding the collected telemetry would not exceed MTU, then 383 append data as a new Telemetry Data TLV and transmit the follow- 384 up packet. Proceed to Step 8; 386 5. otherwise, set the value of the Full flag to one, copy the 387 transport information from the received follow-up packet and 388 transmit it accordingly. Proceed to Step 8; 390 6. originate the new follow-up packet using the transport 391 information copied from the received follow-up packet. The value 392 of the Sequence Number field in the HTS shim MUST be set to the 393 value of the field in the received follow-up packet incremented 394 by one; 396 7. copy collected telemetry data into the first Telemetry Data TLV's 397 Value field and then transmit the packet; 399 8. processing completed. 401 If the HTS Follow-up Timer expires, the intermediate node MUST: 403 * originate the follow-up packet using transport information 404 associated with the expired timer; 406 * initialize the HTS shim by setting the Version field's value to 407 0b00 and Sequence Number field to 0. Values of HTS Shim Length 408 and Telemetry Data Profile fields MAY be set according to the 409 local policy. 411 * copy telemetry information into Telemetry Data TLV's Value field 412 and transmit the packet. 414 If the intermediate node receives a "late" follow-up packet, i.e., a 415 packet to which the node has no associated HTS Follow-up timer, the 416 node MUST forward the "late" packet. 418 4.3. Operation of the HTS Egress Node 420 Upon receiving the trigger packet, the HTS egress node MUST: 422 * copy the transport information; 424 * start the HTS Collection timer for the obtained flow. 426 When the egress node receives the follow-up packet for the known 427 flow, i.e., the flow to which the Collection timer is running, the 428 node for each of Telemetry Data TLVs MUST: 430 * if HTS is used in the authenticated mode, verify the 431 authentication of the Telemetry Data TLV using the Authentication 432 sub-TLV (see Section 5); 434 * copy telemetry information from the Value field; 436 * restart the corresponding Collection timer. 438 When the Collection timer expires, the egress relays the collected 439 telemetry information for processing and analysis to a local or 440 remote agent. 442 4.4. Considerations for HTS Timers 444 This specification defines two timers - HTS Follow-up and HTS 445 Collection. For the particular flow, there MUST be no more than one 446 HTS Trigger, values of HTS timers bounded by the rate of the trigger 447 generation for that flow. 449 4.5. Deploying HTS in a Multicast Network 451 Previous sections discussed the operation of HTS in a unicast 452 network. Multicast services are important, and the ability to 453 collect telemetry information is invaluable in delivering a high 454 quality of experience. While the replication of data packets is 455 necessary, replication of HTS follow-up packets is not. Replication 456 of multicast data packets down a multicast tree may be set based on 457 multicast routing information or explicit information included in the 458 special header, as, for example, in Bit-Indexed Explicit Replication 459 [RFC8296]. A replicating node processes the HTS packet as defined 460 below: 462 * the first transmitted multicast packet MUST be followed by the 463 received corresponding HTS packet as described in Section 4.2; 465 * each consecutively transmitted copy of the original multicast 466 packet MUST be followed by the new HTS packet originated by the 467 replicating node that acts as an intermediate HTS node when the 468 HTS Follow-up timer expired. 470 As a result, there are no duplicate copies of Telemetry Data TLV for 471 the same pair of ingress and egress interfaces. At the same time, 472 all ingress/egress pairs traversed by the given multicast packet 473 reflected in their respective Telemetry Data TLV. Consequently, a 474 centralized controller would reconstruct and analyze the state of the 475 particular multicast distribution tree based on HTS packets collected 476 from egress nodes. 478 5. Authentication in HTS 480 Telemetry information may be used to drive network operation, closing 481 the control loop for self-driving, self-healing networks. Thus it is 482 critical to provide a mechanism to protect the telemetry information 483 collected using the HTS method. This document defines an optional 484 authentication of a Telemetry Data TLV that protects the collected 485 information's integrity. 487 The format of the Authentication sub-TLV is displayed in Figure 4. 489 0 1 2 3 490 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 491 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 492 |Authentic. Type| HMAC Type | Length | 493 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 494 | | 495 | Digest | 496 | | 497 | | 498 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 500 Figure 4: HMAC sub-TLV 502 where fields are defined as follows: 504 * Authentication Type - is a one-octet-long field, value TBA2 505 allocated by IANA Section 6.2. 507 * Length - two-octet-long field, set equal to the length of the 508 Digest field in octets. 510 * HMAC Type - is a one-octet-long field that identifies the type of 511 the HMAC and the length of the digest and the length of the digest 512 according to the HTS HMAC Type sub-registry (see Section 6.4). 514 * Digest - is a variable-length field that carries HMAC digest of 515 the text that includes the encompassing TLV. 517 This specification defines the use of HMAC-SHA-256 truncated to 128 518 bits ([RFC4868]) in HTS. Future specifications may define the use in 519 HTS of more advanced cryptographic algorithms or the use of digest of 520 a different length. HMAC is calculated as defined in [RFC2104] over 521 text as the concatenation of the Sequence Number field of the follow- 522 up packet (see Figure 1) and the preceding data collected in the 523 Telemetry Data TLV. The digest then MUST be truncated to 128 bits 524 and written into the Digest field. Distribution and management of 525 shared keys are outside the scope of this document. In the HTS 526 authenticated mode, the Authentication sub-TLV MUST be present in 527 each Telemetry Data TLV. HMAC MUST be verified before using any data 528 in the included Telemetry Data TLV. If HMAC verification fails, the 529 system MUST stop processing corresponding Telemetry Data TLV and 530 notify an operator. Specification of the notification mechanism is 531 outside the scope of this document. 533 6. IANA Considerations 535 6.1. IOAM Option-Type for HTS 537 The IOAM Option-Type registry is requested in 538 [I-D.ietf-ippm-ioam-data]. IANA is requested to allocate a new code 539 point as listed in Table 1. 541 +=======+==================================+===============+ 542 | Value | Description | Reference | 543 +=======+==================================+===============+ 544 | TBA1 | IOAM Hybrid Two-Step Option-Type | This document | 545 +-------+----------------------------------+---------------+ 547 Table 1: IOAM Option-Type for HTS 549 6.2. HTS TLV Registry 551 IANA is requested to create the HTS TLV Type registry. All code 552 points in the range 1 through 175 in this registry shall be allocated 553 according to the "IETF Review" procedure specified in [RFC8126]. 554 Code points in the range 176 through 239 in this registry shall be 555 allocated according to the "First Come First Served" procedure 556 specified in [RFC8126]. The remaining code points are allocated 557 according to Table 2: 559 +===========+==============+===============+ 560 | Value | Description | Reference | 561 +===========+==============+===============+ 562 | 0 | Reserved | This document | 563 +-----------+--------------+---------------+ 564 | 1- 175 | Unassigned | This document | 565 +-----------+--------------+---------------+ 566 | 176 - 239 | Unassigned | This document | 567 +-----------+--------------+---------------+ 568 | 240 - 251 | Experimental | This document | 569 +-----------+--------------+---------------+ 570 | 252 - 254 | Private Use | This document | 571 +-----------+--------------+---------------+ 572 | 255 | Reserved | This document | 573 +-----------+--------------+---------------+ 575 Table 2: HTS TLV Type Registry 577 6.3. HTS Sub-TLV Type Sub-registry 579 IANA is requested to create the HTS sub-TLV Type sub-registry as part 580 of the HTS TLV Type registry. All code points in the range 1 through 581 175 in this registry shall be allocated according to the "IETF 582 Review" procedure specified in [RFC8126]. Code points in the range 583 176 through 239 in this registry shall be allocated according to the 584 "First Come First Served" procedure specified in [RFC8126]. The 585 remaining code points are allocated according to Table 3: 587 +===========+==============+===============+ 588 | Value | Description | Reference | 589 +===========+==============+===============+ 590 | 0 | Reserved | This document | 591 +-----------+--------------+---------------+ 592 | 1- 175 | Unassigned | This document | 593 +-----------+--------------+---------------+ 594 | 176 - 239 | Unassigned | This document | 595 +-----------+--------------+---------------+ 596 | 240 - 251 | Experimental | This document | 597 +-----------+--------------+---------------+ 598 | 252 - 254 | Private Use | This document | 599 +-----------+--------------+---------------+ 600 | 255 | Reserved | This document | 601 +-----------+--------------+---------------+ 603 Table 3: HTS Sub-TLV Type Sub-registry 605 This document defines the following new values in the IETF Review 606 range of the HTS sub-TLV Type sub-registry: 608 +=======+=============+==========+===============+ 609 | Value | Description | TLV Used | Reference | 610 +=======+=============+==========+===============+ 611 | TBA2 | HMAC | Any | This document | 612 +-------+-------------+----------+---------------+ 614 Table 4: HTS sub-TLV Types 616 6.4. HMAC Type Sub-registry 618 IANA is requested to create the HMAC Type sub-registry as part of the 619 HTS TLV Type registry. All code points in the range 1 through 127 in 620 this registry shall be allocated according to the "IETF Review" 621 procedure specified in [RFC8126]. Code points in the range 128 622 through 239 in this registry shall be allocated according to the 623 "First Come First Served" procedure specified in [RFC8126]. The 624 remaining code points are allocated according to Table 5: 626 +===========+==============+===============+ 627 | Value | Description | Reference | 628 +===========+==============+===============+ 629 | 0 | Reserved | This document | 630 +-----------+--------------+---------------+ 631 | 1- 127 | Unassigned | This document | 632 +-----------+--------------+---------------+ 633 | 128 - 239 | Unassigned | This document | 634 +-----------+--------------+---------------+ 635 | 240 - 249 | Experimental | This document | 636 +-----------+--------------+---------------+ 637 | 250 - 254 | Private Use | This document | 638 +-----------+--------------+---------------+ 639 | 255 | Reserved | This document | 640 +-----------+--------------+---------------+ 642 Table 5: HMAC Type Sub-registry 644 This document defines the following new values in the HMAC Type sub- 645 registry: 647 +=======+=============================+===============+ 648 | Value | Description | Reference | 649 +=======+=============================+===============+ 650 | 1 | HMAC-SHA-256 16 octets long | This document | 651 +-------+-----------------------------+---------------+ 653 Table 6: HMAC Types 655 7. Security Considerations 657 Nodes that practice the HTS method are presumed to share a trust 658 model that depends on the existence of a trusted relationship among 659 nodes. This is necessary as these nodes are expected to correctly 660 modify the specific content of the data in the follow-up packet, and 661 the degree to which HTS measurement is useful for network operation 662 depends on this ability. In practice, this means either 663 confidentiality or integrity protection cannot cover those portions 664 of messages that contain the network state data. Though there are 665 methods that make it possible in theory to provide either or both 666 such protections and still allow for intermediate nodes to make 667 detectable yet authenticated modifications, such methods do not seem 668 practical at present, particularly for protocols that used to measure 669 latency and/or jitter. 671 This document defines the use of authentication (Section 5) to 672 protect the integrity of the telemetry information collected using 673 the HTS method. Privacy protection can be achieved by, for example, 674 sharing the IPsec tunnel with a data flow that generates information 675 that is collected using HTS. 677 While it is possible for a supposed compromised node to intercept and 678 modify the network state information in the follow-up packet; this is 679 an issue that exists for nodes in general - for all data that to be 680 carried over the particular networking technology - and is therefore 681 the basis for an additional presumed trust model associated with an 682 existing network. 684 8. Acknowledgments 686 Authors express their gratitude and appreciation to Joel Halpern for 687 the most helpful and insightful discussion on the applicability of 688 HTS in a Service Function Chaining domain. 690 9. References 692 9.1. Normative References 694 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 695 Hashing for Message Authentication", RFC 2104, 696 DOI 10.17487/RFC2104, February 1997, 697 . 699 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 700 Requirement Levels", BCP 14, RFC 2119, 701 DOI 10.17487/RFC2119, March 1997, 702 . 704 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 705 Writing an IANA Considerations Section in RFCs", BCP 26, 706 RFC 8126, DOI 10.17487/RFC8126, June 2017, 707 . 709 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 710 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 711 May 2017, . 713 9.2. Informative References 715 [I-D.ietf-ippm-ioam-data] 716 Brockners, F., Bhandari, S., and T. Mizrahi, "Data Fields 717 for In-situ OAM", Work in Progress, Internet-Draft, draft- 718 ietf-ippm-ioam-data-12, 21 February 2021, 719 . 722 [I-D.ietf-ippm-ioam-direct-export] 723 Song, H., Gafni, B., Zhou, T., Li, Z., Brockners, F., 724 Bhandari, S., Sivakolundu, R., and T. Mizrahi, "In-situ 725 OAM Direct Exporting", Work in Progress, Internet-Draft, 726 draft-ietf-ippm-ioam-direct-export-03, 17 February 2021, 727 . 730 [I-D.song-ippm-postcard-based-telemetry] 731 Song, H., Mirsky, G., Filsfils, C., Abdelsalam, A., Zhou, 732 T., Li, Z., Shin, J., and K. Lee, "Postcard-based On-Path 733 Flow Data Telemetry using Packet Marking", Work in 734 Progress, Internet-Draft, draft-song-ippm-postcard-based- 735 telemetry-09, 19 February 2021, 736 . 739 [P4.INT] "In-band Network Telemetry (INT)", P4.org Specification, 740 October 2017. 742 [RFC4868] Kelly, S. and S. Frankel, "Using HMAC-SHA-256, HMAC-SHA- 743 384, and HMAC-SHA-512 with IPsec", RFC 4868, 744 DOI 10.17487/RFC4868, May 2007, 745 . 747 [RFC6437] Amante, S., Carpenter, B., Jiang, S., and J. Rajahalme, 748 "IPv6 Flow Label Specification", RFC 6437, 749 DOI 10.17487/RFC6437, November 2011, 750 . 752 [RFC6790] Kompella, K., Drake, J., Amante, S., Henderickx, W., and 753 L. Yong, "The Use of Entropy Labels in MPLS Forwarding", 754 RFC 6790, DOI 10.17487/RFC6790, November 2012, 755 . 757 [RFC7799] Morton, A., "Active and Passive Metrics and Methods (with 758 Hybrid Types In-Between)", RFC 7799, DOI 10.17487/RFC7799, 759 May 2016, . 761 [RFC8169] Mirsky, G., Ruffini, S., Gray, E., Drake, J., Bryant, S., 762 and A. Vainshtein, "Residence Time Measurement in MPLS 763 Networks", RFC 8169, DOI 10.17487/RFC8169, May 2017, 764 . 766 [RFC8296] Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A., 767 Tantsura, J., Aldrin, S., and I. Meilik, "Encapsulation 768 for Bit Index Explicit Replication (BIER) in MPLS and Non- 769 MPLS Networks", RFC 8296, DOI 10.17487/RFC8296, January 770 2018, . 772 [RFC8300] Quinn, P., Ed., Elzur, U., Ed., and C. Pignataro, Ed., 773 "Network Service Header (NSH)", RFC 8300, 774 DOI 10.17487/RFC8300, January 2018, 775 . 777 [RFC8321] Fioccola, G., Ed., Capello, A., Cociglio, M., Castaldelli, 778 L., Chen, M., Zheng, L., Mirsky, G., and T. Mizrahi, 779 "Alternate-Marking Method for Passive and Hybrid 780 Performance Monitoring", RFC 8321, DOI 10.17487/RFC8321, 781 January 2018, . 783 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 784 Decraene, B., Litkowski, S., and R. Shakir, "Segment 785 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 786 July 2018, . 788 Authors' Addresses 790 Greg Mirsky 791 ZTE Corp. 793 Email: gregimirsky@gmail.com, gregory.mirsky@ztetx.com 794 Wang Lingqiang 795 ZTE Corporation 796 No 19 ,East Huayuan Road 797 Beijing 799 Phone: +86 10 82963945 800 Email: wang.lingqiang@zte.com.cn 802 Guo Zhui 803 ZTE Corporation 804 No 19 ,East Huayuan Road 805 Beijing 807 Phone: +86 10 82963945 808 Email: guo.zhui@zte.com.cn 810 Haoyu Song 811 Futurewei Technologies 812 2330 Central Expressway 813 Santa Clara, 814 United States of America 816 Email: hsong@futurewei.com