idnits 2.17.1 draft-mirsky-ippm-hybrid-two-step-08.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 (February 15, 2021) is 1166 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-11 == Outdated reference: A later version (-11) exists of draft-ietf-ippm-ioam-direct-export-02 == Outdated reference: A later version (-16) exists of draft-song-ippm-postcard-based-telemetry-08 -- 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: August 19, 2021 G. Zhui 6 ZTE Corporation 7 H. Song 8 Futurewei Technologies 9 February 15, 2021 11 Hybrid Two-Step Performance Measurement Method 12 draft-mirsky-ippm-hybrid-two-step-08 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 August 19, 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 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. Conventions used in this document . . . . . . . . . . . . . . 3 61 2.1. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . 3 62 2.2. Requirements Language . . . . . . . . . . . . . . . . . . 4 63 3. Problem Overview . . . . . . . . . . . . . . . . . . . . . . 4 64 4. Theory of Operation . . . . . . . . . . . . . . . . . . . . . 5 65 4.1. Operation of the HTS Ingress Node . . . . . . . . . . . . 6 66 4.2. Operation of the HTS Intermediate Node . . . . . . . . . 8 67 4.3. Operation of the HTS Egress Node . . . . . . . . . . . . 9 68 4.4. Considerations for HTS Timers . . . . . . . . . . . . . . 10 69 4.5. Deploying HTS in a Multicast Network . . . . . . . . . . 10 70 5. Authentication in HTS . . . . . . . . . . . . . . . . . . . . 10 71 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 72 6.1. IOAM Option-Type for HTS . . . . . . . . . . . . . . . . 12 73 6.2. HTS TLV Registry . . . . . . . . . . . . . . . . . . . . 12 74 6.3. HTS Sub-TLV Type Sub-registry . . . . . . . . . . . . . . 12 75 6.4. HMAC Type Sub-registry . . . . . . . . . . . . . . . . . 13 76 7. Security Considerations . . . . . . . . . . . . . . . . . . . 14 77 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14 78 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 79 9.1. Normative References . . . . . . . . . . . . . . . . . . 15 80 9.2. Informative References . . . . . . . . . . . . . . . . . 15 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 83 1. Introduction 85 Successful resolution of challenges of automated network operation, 86 as part of, for example, overall service orchestration or data center 87 operation, relies on a timely collection of accurate information that 88 reflects the state of network elements on an unprecedented scale. 89 Because performing the analysis and act upon the collected 90 information requires considerable computing and storage resources, 91 the network state information is unlikely to be processed by the 92 network elements themselves but will be relayed into the data storage 93 facilities, e.g., data lakes. The process of producing, collecting 94 network state information also referred to in this document as 95 network telemetry, and transporting it for post-processing should 96 work equally well with data flows or injected in the network test 97 packets. RFC 7799 [RFC7799] describes a combination of elements of 98 passive and active measurement as a hybrid measurement. 100 Several technical methods have been proposed to enable the collection 101 of network state information instantaneous to the packet processing, 102 among them [P4.INT] and [I-D.ietf-ippm-ioam-data]. The 103 instantaneous, i.e., in the data packet itself, collection of 104 telemetry information simplifies the process of attribution of 105 telemetry information to the particular monitored flow. On the other 106 hand, this collection method impacts the data packets, potentially 107 changing their treatment by the networking nodes. Also, the amount 108 of information the instantaneous method collects might be incomplete 109 because of the limited space it can be allotted. Other proposals 110 defined methods to collect telemetry information in a separate packet 111 from each node traversed by the monitored data flow. Examples of 112 this approach to collecting telemetry information are 113 [I-D.ietf-ippm-ioam-direct-export] and 114 [I-D.song-ippm-postcard-based-telemetry]. These methods allow data 115 collection from any arbitrary path and avoid directly impacting data 116 packets. On the other hand, the correlation of data and the 117 monitored flow requires that each packet with telemetry information 118 also includes characteristic information about the monitored flow. 120 This document introduces Hybrid Two-Step (HTS) as a new method of 121 telemetry collection that improvers accuracy of a measurement by 122 separating the act of measuring or calculating the performance metric 123 from the collecting and transporting this information while 124 minimizing the overhead of the generated load in a network. HTS 125 method extends the two-step mode of Residence Time Measurement (RTM) 126 defined in [RFC8169] to on-path network state collection and 127 transport. HTS allows the collection of telemetry information from 128 any arbitrary path, does not change data packets of the monitored 129 flow and makes the process of attribution of telemetry to the data 130 flow simple. 132 2. Conventions used in this document 134 2.1. Acronyms 136 RTM Residence Time Measurement 138 ECMP Equal Cost Multipath 140 MTU Maximum Transmission Unit 142 HTS Hybrid Two-Step 144 HMAC Hashed Message Authentication Code 145 Network telemetry - the process of collecting and reporting of 146 network state 148 2.2. Requirements Language 150 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 151 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 152 "OPTIONAL" in this document are to be interpreted as described in BCP 153 14 [RFC2119] [RFC8174] when, and only when, they appear in all 154 capitals, as shown here. 156 3. Problem Overview 158 Performance measurements are meant to provide data that characterize 159 conditions experienced by traffic flows in the network and possibly 160 trigger operational changes (e.g., re-route of flows, or changes in 161 resource allocations). Modifications to a network are determined 162 based on the performance metric information available when a change 163 is to be made. The correctness of this determination is based on the 164 quality of the collected metrics data. The quality of collected 165 measurement data is defined by: 167 o the resolution and accuracy of each measurement; 169 o predictability of both the time at which each measurement is made 170 and the timeliness of measurement collection data delivery for 171 use. 173 Consider the case of delay measurement that relies on collecting time 174 of packet arrival at the ingress interface and time of the packet 175 transmission at the egress interface. The method includes recording 176 a local clock value on receiving the first octet of an affected 177 message at the device ingress, and again recording the clock value on 178 transmitting the first byte of the same message at the device egress. 179 In this ideal case, the difference between the two recorded clock 180 times corresponds to the time that the message spent in traversing 181 the device. In practice, the time recorded can differ from the ideal 182 case by any fixed amount. A correction can be applied to compute the 183 same time difference taking into account the known fixed time 184 associated with the actual measurement. In this way, the resulting 185 time difference reflects any variable delay associated with queuing. 187 Depending on the implementation, it may be a challenge to compute the 188 difference between message arrival and departure times and - on the 189 fly - add the necessary residence time information to the same 190 message. And that task may become even more challenging if the 191 packet is encrypted. Recording the departure of a packet time in the 192 same packet may be decremental to the accuracy of the measurement 193 because the departure time includes the variable time component (such 194 as that associated with buffering and queuing of the packet). A 195 similar problem may lower the quality of, for example, information 196 that characterizes utilization of the egress interface. If unable to 197 obtain the data consistently, without variable delays for additional 198 processing, information may not accurately reflect the egress 199 interface state. To mitigate this problem [RFC8169] defined an RTM 200 two-step mode. 202 Another challenge associated with methods that collect network state 203 information into the actual data packet is the risk to exceed the 204 Maximum Transmission Unit (MTU) size, especially if the packet 205 traverses overlay domains or VPNs. Since the fragmentation is not 206 available at the transport network, operators may have to reduce MTU 207 size advertised to the client layer or risk missing network state 208 data for the part, most probably the latter part, of the path. 210 4. Theory of Operation 212 The HTS method consists of two phases: 214 o performing a measurement or obtaining network state information, 215 one or more than one type, on a node; 217 o collecting and transporting the measurement. 219 HTS uses HTS Trigger carried in a data packet or a specially 220 constructed test packet. For example, an HTS Trigger could be a 221 packet that has IOAM Option-Type set to the "IOAM Hybrid Two-Step 222 Option-Type" value (TBA1) allocated by IANA (see Section 6.1). The 223 HTS Trigger also includes IOAM Namespace-ID and IOAM-Trace-Type 224 information [I-D.ietf-ippm-ioam-data]. A packet in the flow to which 225 the Alternate-Marking method [RFC8321] is applied can be used as an 226 HTS Trigger. The nature of the HTS Trigger is a transport network 227 layer-specific, and its description is outside the scope of this 228 document. The packet that includes the HTS Trigger in this document 229 is also referred to as the trigger packet. 231 The HTS method uses the HTS Follow-up packet, referred to as the 232 follow-up packet, to collect measurement and network state data from 233 the nodes. The node that creates the HTS Trigger also generates the 234 HTS Follow-up packet. The follow-up packet contains characteristic 235 information, copied from the trigger packet, sufficient for 236 participating HTS nodes to associate it with the original packet. 237 The exact composition of the characteristic information is specific 238 for each transport network, and its definition is outside the scope 239 of this document. The follow-up packet also uses the same 240 encapsulation as the data packet. If not payload but only network 241 information used to load-balance flows in equal cost multipath 242 (ECMP), use of the network encapsulation identical to the trigger 243 packet should guarantee that the follow-up packet remains in-band, 244 i.e., traverses the same set of network elements, with the original 245 data packet with the HTS Trigger. Only one outstanding follow-up 246 packet MUST be on the node for the given path. That means that if 247 the node receives an HTS Trigger for the flow on which it still waits 248 for the follow-up packet to the previous HTS Trigger, the node will 249 originate the follow-up packet to transport the former set of the 250 network state data and transmit it before it sends the follow-up 251 packet with the latest collection of network state information. 253 4.1. Operation of the HTS Ingress Node 255 A node that originates the HTS Trigger is referred to as the HTS 256 ingress node. As stated, the ingress node originates the follow-up 257 packet. The follow-up packet has the transport network encapsulation 258 identical with the trigger packet followed by the HTS shim and one or 259 more telemetry information elements encoded as Type-Length-Value 260 {TLV}. Figure 1 displays an example of the follow-up packet format. 262 0 1 2 3 263 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 264 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 265 | | 266 ~ Transport Network ~ 267 | Encapsulation | 268 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 269 |Ver|HTS Shim Len| Flags | Sequence Number | 270 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 271 | Telemetry Data Profile | 272 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 273 | | 274 ~ Telemetry Data TLVs ~ 275 | | 276 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 278 Figure 1: Follow-up Packet Format 280 Fields of the HTS shim are as follows: 282 Version (Ver) is the two-bits long field. It specifies the 283 version of the HTS shim format. This document defines the format 284 for the 0b00 value of the field. 286 HTS Shim Length is the six bits-long field. It defines the length 287 of the HTS shim in bytes. The minimal value of the field is four 288 bytes. 290 0 291 0 1 2 3 4 5 6 7 292 +-+-+-+-+-+-+-+-+ 293 |F| Reserved | 294 +-+-+-+-+-+-+-+-+ 296 Figure 2: Flags Field Format 298 Flags is eight-bits long. The format of the Flags field displayed 299 in Figure 2. 301 Full (F) flag MUST be set to zero by the node originating the 302 HTS follow-up packet and MUST be set to one by the node that 303 does not add its telemetry data to avoid exceeding MTU size. 305 The node originating the follow-up packet MUST zero the 306 Reserved field and ignore it on the receipt. 308 Sequence Number is 16 bits-long field. The zero-based value of 309 the field reflects the place of the HTS follow-up packet in the 310 sequence of the HTS follow-up packets that originated in response 311 to the same HTS trigger. The ingress node MUST set the value of 312 the field to zero. 314 Telemetry Data Profile is the optional variable-length field of 315 bit-size flags. Each flag indicates the requested type of 316 telemetry data to be collected at each HTS node. The increment of 317 the field is four bytes with a minimum length of zero. For 318 example, IOAM-Trace-Type information defined in 319 [I-D.ietf-ippm-ioam-data] can be used in the Telemetry Data 320 Profile field. 322 0 1 2 3 323 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 324 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 325 | Type | Reserved | Length | 326 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 327 ~ Value ~ 328 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 330 Figure 3: Telemetry Data TLV Format 332 Telemetry Data TLV is a variable-length field. Multiple TLVs MAY 333 be placed in an HTS packet. Additional TLVs may be enclosed 334 within a given TLV, subject to the semantics of the (outer) TLV in 335 question. Figure 3 presents the format of a Telemetry Data TLV, 336 where fields are defined as the following: 338 Type - a one-octet-long field that characterizes the 339 interpretation of the Value field. 341 Reserved - one-octet-long field. 343 Length - two-octet-long field equal to the length of the Value 344 field in octets. 346 Value - a variable-length field. The value of the Type field 347 determines its interpretation and encoding. IOAM data fields, 348 defined in [I-D.ietf-ippm-ioam-data], MAY be carried in the 349 Value field. 351 All multibyte fields defined in this specification are in network 352 byte order. 354 4.2. Operation of the HTS Intermediate Node 356 Upon receiving the trigger packet, the HTS intermediate node MUST: 358 o copy the transport information; 360 o start the HTS Follow-up Timer for the obtained flow; 362 o transmit the trigger packet. 364 Upon receiving the follow-up packet, the HTS intermediate node MUST: 366 1. verify that the matching transport information exists and the 367 Full flag is cleared, then stop the associated HTS Follow-up 368 Timer; 370 2. otherwise, transmit the received packet. Proceed to Step 8; 372 3. collect telemetry data requested in the Telemetry Data Profile 373 field or defined by the local HTS policy; 375 4. if adding the collected telemetry would not exceed MTU, then 376 append data as a new Telemetry Data TLV and transmit the follow- 377 up packet. Proceed to Step 8; 379 5. otherwise, set the value of the Full flag to one, copy the 380 transport information from the received follow-up packet and 381 transmit it accordingly. Proceed to Step 8; 383 6. originate the new follow-up packet using the transport 384 information copied from the received follow-up packet. The value 385 of the Sequence Number field in the HTS shim MUST be set to the 386 value of the field in the received follow-up packet incremented 387 by one; 389 7. copy collected telemetry data into the first Telemetry Data TLV's 390 Value field and then transmit the packet; 392 8. processing completed. 394 If the HTS Follow-up Timer expires, the intermediate node MUST: 396 o originate the follow-up packet using transport information 397 associated with the expired timer; 399 o initialize the HTS shim by setting the Version field's value to 400 0b00 and Sequence Number field to 0. Values of HTS Shim Length 401 and Telemetry Data Profile fields MAY be set according to the 402 local policy. 404 o copy telemetry information into Telemetry Data TLV's Value field 405 and transmit the packet. 407 If the intermediate node receives a "late" follow-up packet, i.e., a 408 packet to which the node has no associated HTS Follow-up timer, the 409 node MUST forward the "late" packet. 411 4.3. Operation of the HTS Egress Node 413 Upon receiving the trigger packet, the HTS egress node MUST: 415 o copy the transport information; 417 o start the HTS Collection timer for the obtained flow. 419 When the egress node receives the follow-up packet for the known 420 flow, i.e., the flow to which the Collection timer is running, the 421 node for each of Telemetry Data TLVs MUST: 423 o if HTS is used in the authenticated mode, verify the 424 authentication of the Telemetry Data TLV using the Authentication 425 sub-TLV (see Section 5); 427 o copy telemetry information from the Value field; 429 o restart the corresponding Collection timer. 431 When the Collection timer expires, the egress relays the collected 432 telemetry information for processing and analysis to a local or 433 remote agent. 435 4.4. Considerations for HTS Timers 437 This specification defines two timers - HTS Follow-up and HTS 438 Collection. For the particular flow, there MUST be no more than one 439 HTS Trigger, values of HTS timers bounded by the rate of the trigger 440 generation for that flow. 442 4.5. Deploying HTS in a Multicast Network 444 Previous sections discussed the operation of HTS in a unicast 445 network. Multicast services are important, and the ability to 446 collect telemetry information is invaluable in delivering a high 447 quality of experience. While the replication of data packets is 448 necessary, replication of HTS follow-up packets is not. Replication 449 of multicast data packets down a multicast tree may be set based on 450 multicast routing information or explicit information included in the 451 special header, as, for example, in Bit-Indexed Explicit Replication 452 [RFC8296]. A replicating node processes the HTS packet as defined 453 below: 455 o the first transmitted multicast packet MUST be followed by the 456 received corresponding HTS packet as described in Section 4.2; 458 o each consecutively transmitted copy of the original multicast 459 packet MUST be followed by the new HTS packet originated by the 460 replicating node that acts as an intermediate HTS node when the 461 HTS Follow-up timer expired. 463 As a result, there are no duplicate copies of Telemetry Data TLV for 464 the same pair of ingress and egress interfaces. At the same time, 465 all ingress/egress pairs traversed by the given multicast packet 466 reflected in their respective Telemetry Data TLV. Consequently, a 467 centralized controller would reconstruct and analyze the state of the 468 particular multicast distribution tree based on HTS packets collected 469 from egress nodes. 471 5. Authentication in HTS 473 Telemetry information may be used to drive network operation, closing 474 the control loop for self-driving, self-healing networks. Thus it is 475 critical to provide a mechanism to protect the telemetry information 476 collected using the HTS method. This document defines an optional 477 authentication of a Telemetry Data TLV that protects the collected 478 information's integrity. 480 The format of the Authentication sub-TLV is displayed in Figure 4. 482 0 1 2 3 483 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 484 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 485 |Authentic. Type| HMAC Type | Length | 486 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 487 | | 488 | Digest | 489 | | 490 | | 491 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 493 Figure 4: HMAC sub-TLV 495 where fields are defined as follows: 497 o Authentication Type - is a one-octet-long field, value TBA2 498 allocated by IANA Section 6.2. 500 o Length - two-octet-long field, set equal to the length of the 501 Digest field in octets. 503 o HMAC Type - is a one-octet-long field that identifies the type of 504 the HMAC and the length of the digest and the length of the digest 505 according to the HTS HMAC Type sub-registry (see Section 6.4). 507 o Digest - is a variable-length field that carries HMAC digest of 508 the text that includes the encompassing TLV. 510 This specification defines the use of HMAC-SHA-256 truncated to 128 511 bits ([RFC4868]) in HTS. Future specifications may define the use in 512 HTS of more advanced cryptographic algorithms or the use of digest of 513 a different length. HMAC is calculated as defined in [RFC2104] over 514 text as the concatenation of the Sequence Number field of the follow- 515 up packet (see Figure 1) and the preceding data collected in the 516 Telemetry Data TLV. The digest then MUST be truncated to 128 bits 517 and written into the Digest field. Distribution and management of 518 shared keys are outside the scope of this document. In the HTS 519 authenticated mode, the Authentication sub-TLV MUST be present in 520 each Telemetry Data TLV. HMAC MUST be verified before using any data 521 in the included Telemetry Data TLV. If HMAC verification fails, the 522 system MUST stop processing corresponding Telemetry Data TLV and 523 notify an operator. Specification of the notification mechanism is 524 outside the scope of this document. 526 6. IANA Considerations 528 6.1. IOAM Option-Type for HTS 530 The IOAM Option-Type registry is requested in 531 [I-D.ietf-ippm-ioam-data]. IANA is requested to allocate a new code 532 point as listed in Table 1. 534 +-------+----------------------------------+---------------+ 535 | Value | Description | Reference | 536 +-------+----------------------------------+---------------+ 537 | TBA1 | IOAM Hybrid Two-Step Option-Type | This document | 538 +-------+----------------------------------+---------------+ 540 Table 1: IOAM Option-Type for HTS 542 6.2. HTS TLV Registry 544 IANA is requested to create the HTS TLV Type registry. All code 545 points in the range 1 through 175 in this registry shall be allocated 546 according to the "IETF Review" procedure specified in [RFC8126]. 547 Code points in the range 176 through 239 in this registry shall be 548 allocated according to the "First Come First Served" procedure 549 specified in [RFC8126]. The remaining code points are allocated 550 according to Table 2: 552 +-----------+--------------+---------------+ 553 | Value | Description | Reference | 554 +-----------+--------------+---------------+ 555 | 0 | Reserved | This document | 556 | 1- 175 | Unassigned | This document | 557 | 176 - 239 | Unassigned | This document | 558 | 240 - 251 | Experimental | This document | 559 | 252 - 254 | Private Use | This document | 560 | 255 | Reserved | This document | 561 +-----------+--------------+---------------+ 563 Table 2: HTS TLV Type Registry 565 6.3. HTS Sub-TLV Type Sub-registry 567 IANA is requested to create the HTS sub-TLV Type sub-registry as part 568 of the HTS TLV Type registry. All code points in the range 1 through 569 175 in this registry shall be allocated according to the "IETF 570 Review" procedure specified in [RFC8126]. Code points in the range 571 176 through 239 in this registry shall be allocated according to the 572 "First Come First Served" procedure specified in [RFC8126]. The 573 remaining code points are allocated according to Table 3: 575 +-----------+--------------+---------------+ 576 | Value | Description | Reference | 577 +-----------+--------------+---------------+ 578 | 0 | Reserved | This document | 579 | 1- 175 | Unassigned | This document | 580 | 176 - 239 | Unassigned | This document | 581 | 240 - 251 | Experimental | This document | 582 | 252 - 254 | Private Use | This document | 583 | 255 | Reserved | This document | 584 +-----------+--------------+---------------+ 586 Table 3: HTS Sub-TLV Type Sub-registry 588 This document defines the following new values in the IETF Review 589 range of the HTS sub-TLV Type sub-registry: 591 +-------+-------------+----------+---------------+ 592 | Value | Description | TLV Used | Reference | 593 +-------+-------------+----------+---------------+ 594 | TBA2 | HMAC | Any | This document | 595 +-------+-------------+----------+---------------+ 597 Table 4: HTS sub-TLV Types 599 6.4. HMAC Type Sub-registry 601 IANA is requested to create the HMAC Type sub-registry as part of the 602 HTS TLV Type registry. All code points in the range 1 through 127 in 603 this registry shall be allocated according to the "IETF Review" 604 procedure specified in [RFC8126]. Code points in the range 128 605 through 239 in this registry shall be allocated according to the 606 "First Come First Served" procedure specified in [RFC8126]. The 607 remaining code points are allocated according to Table 5: 609 +-----------+--------------+---------------+ 610 | Value | Description | Reference | 611 +-----------+--------------+---------------+ 612 | 0 | Reserved | This document | 613 | 1- 127 | Unassigned | This document | 614 | 128 - 239 | Unassigned | This document | 615 | 240 - 249 | Experimental | This document | 616 | 250 - 254 | Private Use | This document | 617 | 255 | Reserved | This document | 618 +-----------+--------------+---------------+ 620 Table 5: HMAC Type Sub-registry 622 This document defines the following new values in the HMAC Type sub- 623 registry: 625 +-------+-----------------------------+---------------+ 626 | Value | Description | Reference | 627 +-------+-----------------------------+---------------+ 628 | 1 | HMAC-SHA-256 16 octets long | This document | 629 +-------+-----------------------------+---------------+ 631 Table 6: HMAC Types 633 7. Security Considerations 635 Nodes that practice the HTS method are presumed to share a trust 636 model that depends on the existence of a trusted relationship among 637 nodes. This is necessary as these nodes are expected to correctly 638 modify the specific content of the data in the follow-up packet, and 639 the degree to which HTS measurement is useful for network operation 640 depends on this ability. In practice, this means either 641 confidentiality or integrity protection cannot cover those portions 642 of messages that contain the network state data. Though there are 643 methods that make it possible in theory to provide either or both 644 such protections and still allow for intermediate nodes to make 645 detectable yet authenticated modifications, such methods do not seem 646 practical at present, particularly for protocols that used to measure 647 latency and/or jitter. 649 This document defines the use of authentication (Section 5) to 650 protect the integrity of the telemetry information collected using 651 the HTS method. Privacy protection can be achieved by, for example, 652 sharing the IPsec tunnel with a data flow that generates information 653 that is collected using HTS. 655 While it is possible for a supposed compromised node to intercept and 656 modify the network state information in the follow-up packet; this is 657 an issue that exists for nodes in general - for all data that to be 658 carried over the particular networking technology - and is therefore 659 the basis for an additional presumed trust model associated with an 660 existing network. 662 8. Acknowledgments 664 Authors express their gratitude and appreciation to Joel Halpern for 665 the most helpful and insightful discussion on the applicability of 666 HTS in a Service Function Chaining domain. 668 9. References 670 9.1. Normative References 672 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 673 Hashing for Message Authentication", RFC 2104, 674 DOI 10.17487/RFC2104, February 1997, 675 . 677 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 678 Requirement Levels", BCP 14, RFC 2119, 679 DOI 10.17487/RFC2119, March 1997, 680 . 682 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 683 Writing an IANA Considerations Section in RFCs", BCP 26, 684 RFC 8126, DOI 10.17487/RFC8126, June 2017, 685 . 687 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 688 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 689 May 2017, . 691 9.2. Informative References 693 [I-D.ietf-ippm-ioam-data] 694 Brockners, F., Bhandari, S., and T. Mizrahi, "Data Fields 695 for In-situ OAM", draft-ietf-ippm-ioam-data-11 (work in 696 progress), November 2020. 698 [I-D.ietf-ippm-ioam-direct-export] 699 Song, H., Gafni, B., Zhou, T., Li, Z., Brockners, F., 700 Bhandari, S., Sivakolundu, R., and T. Mizrahi, "In-situ 701 OAM Direct Exporting", draft-ietf-ippm-ioam-direct- 702 export-02 (work in progress), November 2020. 704 [I-D.song-ippm-postcard-based-telemetry] 705 Song, H., Zhou, T., Li, Z., Mirsky, G., Shin, J., and K. 706 Lee, "Postcard-based On-Path Flow Data Telemetry using 707 Packet Marking", draft-song-ippm-postcard-based- 708 telemetry-08 (work in progress), October 2020. 710 [P4.INT] "In-band Network Telemetry (INT)", P4.org Specification, 711 October 2017. 713 [RFC4868] Kelly, S. and S. Frankel, "Using HMAC-SHA-256, HMAC-SHA- 714 384, and HMAC-SHA-512 with IPsec", RFC 4868, 715 DOI 10.17487/RFC4868, May 2007, 716 . 718 [RFC7799] Morton, A., "Active and Passive Metrics and Methods (with 719 Hybrid Types In-Between)", RFC 7799, DOI 10.17487/RFC7799, 720 May 2016, . 722 [RFC8169] Mirsky, G., Ruffini, S., Gray, E., Drake, J., Bryant, S., 723 and A. Vainshtein, "Residence Time Measurement in MPLS 724 Networks", RFC 8169, DOI 10.17487/RFC8169, May 2017, 725 . 727 [RFC8296] Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A., 728 Tantsura, J., Aldrin, S., and I. Meilik, "Encapsulation 729 for Bit Index Explicit Replication (BIER) in MPLS and Non- 730 MPLS Networks", RFC 8296, DOI 10.17487/RFC8296, January 731 2018, . 733 [RFC8321] Fioccola, G., Ed., Capello, A., Cociglio, M., Castaldelli, 734 L., Chen, M., Zheng, L., Mirsky, G., and T. Mizrahi, 735 "Alternate-Marking Method for Passive and Hybrid 736 Performance Monitoring", RFC 8321, DOI 10.17487/RFC8321, 737 January 2018, . 739 Authors' Addresses 741 Greg Mirsky 742 ZTE Corp. 744 Email: gregimirsky@gmail.com 746 Wang Lingqiang 747 ZTE Corporation 748 No 19 ,East Huayuan Road 749 Beijing 100191 750 P.R.China 752 Phone: +86 10 82963945 753 Email: wang.lingqiang@zte.com.cn 754 Guo Zhui 755 ZTE Corporation 756 No 19 ,East Huayuan Road 757 Beijing 100191 758 P.R.China 760 Phone: +86 10 82963945 761 Email: guo.zhui@zte.com.cn 763 Haoyu Song 764 Futurewei Technologies 765 2330 Central Expressway 766 Santa Clara 767 USA 769 Email: hsong@futurewei.com