idnits 2.17.1 draft-ietf-ippm-ioam-data-integrity-00.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 seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (October 19, 2021) is 919 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) == Outdated reference: A later version (-17) exists of draft-ietf-ippm-ioam-data-15 == Outdated reference: A later version (-11) exists of draft-ietf-ippm-ioam-direct-export-07 Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ippm F. Brockners 3 Internet-Draft Cisco 4 Intended status: Standards Track S. Bhandari 5 Expires: April 22, 2022 Thoughtspot 6 T. Mizrahi 7 Huawei 8 October 19, 2021 10 Integrity of In-situ OAM Data Fields 11 draft-ietf-ippm-ioam-data-integrity-00 13 Abstract 15 In-situ Operations, Administration, and Maintenance (IOAM) collects 16 operational and telemetry information in the packet while the packet 17 traverses a path between two points in the network. IETF protocols 18 require features to ensure their security. This document describes 19 the integrity protection of IOAM data fields. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at https://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on April 22, 2022. 38 Copyright Notice 40 Copyright (c) 2021 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (https://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 56 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 3. Threat Analysis . . . . . . . . . . . . . . . . . . . . . . . 4 58 3.1. Modification: IOAM Data Fields . . . . . . . . . . . . . 5 59 3.2. Modification: IOAM Option-Type Headers . . . . . . . . . 5 60 3.3. Injection: IOAM Data Fields . . . . . . . . . . . . . . . 5 61 3.4. Injection: IOAM Option-Type Headers . . . . . . . . . . . 6 62 3.5. Replay . . . . . . . . . . . . . . . . . . . . . . . . . 6 63 3.6. Management and Exporting . . . . . . . . . . . . . . . . 6 64 3.7. Delay . . . . . . . . . . . . . . . . . . . . . . . . . . 7 65 3.8. Threat Summary . . . . . . . . . . . . . . . . . . . . . 7 66 4. Methods of providing integrity to IOAM data fields . . . . . 8 67 4.1. Integrity Protected IOAM Option-Types . . . . . . . . . . 8 68 4.2. Subheader for Integrity Protected IOAM Option-Types . . . 9 69 4.3. Space optimized symmetric key based signing of IOAM data 11 70 4.3.1. Overhead consideration . . . . . . . . . . . . . . . 11 71 4.4. Space optimized asymmetric key based signing of trace 72 data . . . . . . . . . . . . . . . . . . . . . . . . . . 12 73 4.4.1. Overhead consideration . . . . . . . . . . . . . . . 12 74 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 75 5.1. IOAM Option-Type Registry . . . . . . . . . . . . . . . . 13 76 5.2. IOAM Integrity Protection Algorithm Suite Registry . . . 13 77 6. Security Considerations . . . . . . . . . . . . . . . . . . . 14 78 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 79 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 80 8.1. Normative References . . . . . . . . . . . . . . . . . . 14 81 8.2. Informative References . . . . . . . . . . . . . . . . . 14 82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 84 1. Introduction 86 "In-situ" Operations, Administration, and Maintenance (IOAM) collects 87 OAM information within the packet while the packet traverses a 88 particular network domain. The term "in-situ" refers to the fact 89 that the OAM data is added to the data packets rather than is being 90 sent within packets specifically dedicated to OAM. IOAM is to 91 complement mechanisms such as Ping, Traceroute, or other active 92 probing mechanisms. In terms of "active" or "passive" OAM, "in-situ" 93 OAM can be considered a hybrid OAM type. "In-situ" mechanisms do not 94 require extra packets to be sent. IOAM adds information to the 95 already available data packets and therefore cannot be considered 96 passive. In terms of the classification given in [RFC7799] IOAM 97 could be portrayed as Hybrid Type I. IOAM mechanisms can be 98 leveraged where mechanisms using e.g., ICMP do not apply or do not 99 offer the desired results, such as proving that a certain traffic 100 flow takes a pre-defined path, SLA verification for the live data 101 traffic, detailed statistics on traffic distribution paths in 102 networks that distribute traffic across multiple paths, or scenarios 103 in which probe traffic is potentially handled differently from 104 regular data traffic by the network devices. 106 The current [I-D.ietf-ippm-ioam-data] assumes that IOAM is deployed 107 in limited domains, where an operator has means to select, monitor, 108 and control the access to all the networking devices, making the 109 domain a trusted network. As such, IOAM tracing data is carried in 110 the packets in clear and there are no protections against any node or 111 middlebox tampering with the data. IOAM tracing data collected in an 112 untrusted or semi-trusted environments requires integrity protection 113 to support critical operational decisions. 115 The following considerations and requirements are to be taken into 116 account in addition to addressing the problem of detectability of any 117 integrity breach of the IOAM trace data collected: 119 1. IOAM trace data is processed by the data plane, hence viability 120 of any method to prove integrity of the IOAM trace data must be 121 feasible at data plane processing/forwarding rates (IOAM data 122 might be applied to all traffic a router forwards). 124 2. IOAM trace data is carried within data packets. Additional space 125 required to prove integrity of the data needs to be optimal, i.e. 126 should not exceed the MTU or have adverse affect on packet 127 processing. 129 3. Replay protection of older IOAM trace data should be possible. 130 Without replay protection a rogue node can present the old IOAM 131 trace data masking any ongoing network issues/activity making the 132 IOAM trace data collection useless. 134 This document defines the methods to protect the integrity of IOAM 135 data fields, using the IOAM Trace Option-Types specified in 136 [I-D.ietf-ippm-ioam-data] as example. The methods similarily apply 137 to other IOAM Option-Types such as the DEX Option-Type 138 [I-D.ietf-ippm-ioam-direct-export]. 140 2. Conventions 142 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 143 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 144 "OPTIONAL" in this document are to be interpreted as described in BCP 145 14 [RFC2119] [RFC8174]. 147 Abbreviations used in this document: 149 IOAM: In-situ Operations, Administration, and Maintenance 151 MTU: Maximum Transmit Unit 153 OAM: Operations, Administration, and Maintenance 155 POT: Proof of Transit 157 SFC: Service Function Chain 159 3. Threat Analysis 161 This section presents a threat analysis of integrity-related threats 162 in the context of IOAM. The threats that are discussed are assumed 163 to be independent of the lower layer protocols; it is assumed that 164 threats at other layers are handled by security mechanisms that are 165 deployed at these layers. 167 This document is focused on integrity protection for IOAM data 168 fields. Thus the threat analysis includes threats that are related 169 to or result from compromising the integrity of IOAM data fields. 170 Other security aspects such as confidentiality are not within the 171 scope of this document. 173 Throughout the analysis there is a distinction between on-path and 174 off-path attackers. As discussed in [I-D.ietf-detnet-security], on- 175 path attackers are located in a position that allows interception and 176 modification of in-flight protocol packets, whereas off-path 177 attackers can only attack by generating protocol packets. 179 The analysis also includes the impact of each of the threats. 180 Generally speaking, the impact of a successful attack on an OAM 181 protocol [RFC7276] is a false illusion of nonexistent failures or 182 preventing the detection of actual ones; in both cases, the attack 183 may result in denial of service (DoS). Furthermore, creating the 184 false illusion of a nonexistent issue may trigger unnecessary 185 processing in some of the IOAM nodes along the path, and may cause 186 more IOAM-related data to be exported to the management plane than is 187 conventionally necessary. Beyond these general impacts, threat- 188 specific impacts are discussed in each of the subsections below. 190 3.1. Modification: IOAM Data Fields 192 Threat 194 An attacker can maliciously modify the IOAM data fields of in- 195 transit packets. The modification can either be applied to all 196 packets or selectively applied to a subset of the en route 197 packets. This threat is applicable to on-path attackers. 199 Impact 201 By systematically modifying the IOAM data fields of some or all of 202 the in-transit packets an attacker can create a false picture of 203 the paths in the network, the existence of faulty nodes and their 204 location, and the network performance. 206 3.2. Modification: IOAM Option-Type Headers 208 Threat 210 An on-path attacker can modify IOAM data fields in one or more of 211 the IOAM Option-Type headers in order to change or disrupt the 212 behavior of nodes processing IOAM data fields along the path. 214 Impact 216 Changing the header of IOAM Option-Types may have several 217 implications. An attacker can maliciously increase the processing 218 overhead in nodes that process IOAM data fields and increase the 219 on-the-wire overhead of IOAM data fields, for example by modifying 220 the IOAM-Trace-Type field in the IOAM Trace-option header. An 221 attacker can also prevent some of the nodes that process IOAM data 222 fields from incorporating IOAM data fields by modifying the 223 RemainingLen field. 225 3.3. Injection: IOAM Data Fields 227 Threat 229 An attacker can inject packets with IOAM Option-Types and IOAM 230 data fields. This threat is applicable to both on-path and off- 231 path attackers. 233 Impact 235 This attack and it impacts are similar to Section 3.1. 237 3.4. Injection: IOAM Option-Type Headers 239 Threat 241 An attacker can inject packets with IOAM Option-Type headers, thus 242 manipulating other nodes that process IOAM data fields in the 243 network. This threat is applicable to both on-path and off-path 244 attackers. 246 Impact 248 This attack and it impacts are similar to Section 3.2. 250 3.5. Replay 252 Threat 254 An attacker can replay packets with IOAM data fields. 255 Specifically, an attacker may replay a previously transmitted IOAM 256 Option-Type with a new data packet, thus attaching old IOAM data 257 fields to a fresh user packet. This threat is applicable to both 258 on-path and off-path attackers. 260 Impact 262 As with previous threats, this threat may create a false image of 263 a nonexistent failure, or may overload nodes which process IOAM 264 data fields with unnecessary processing. 266 3.6. Management and Exporting 268 Threat 270 Attacks that compromise the integrity of IOAM data fields can be 271 applied at the management plane, e.g., by manipulating network 272 management packets. Furthermore, the integrity of IOAM data 273 fields that are exported to a receiving entity can also be 274 compromised. Management plane attacks are not within the scope of 275 this document; the network management protocol is expected to 276 include inherent security capabilities. The integrity of exported 277 data is also not within the scope of this document. It is 278 expected that the specification of the export format will discuss 279 the relevant security aspects. 281 Impact 283 Malicious manipulation of the management protocol can cause nodes 284 that process IOAM data fields to malfunction, to be overloaded, or 285 to incorporate unnecessary IOAM data fields into user packets. 286 The impact of compromising the integrity of exported IOAM data 287 fields is similar to the impacts of previous threats that were 288 described in this section. 290 3.7. Delay 292 Threat 294 An on-path attacker may delay some or all of the in-transit 295 packets that include IOAM data fields in order to create the false 296 illusion of congestion. Delay attacks are well known in the 297 context of deterministic networks [I-D.ietf-detnet-security] and 298 synchronization [RFC7384], and may be somewhat mitigated in these 299 environments by using redundant paths in a way that is resilient 300 to an attack along one of the paths. This approach does not 301 address the threat in the context of IOAM, as it does not meet the 302 requirement to measure a specific path or to detect a problem 303 along the path. It is noted that this threat is not within the 304 scope of the threats that are mitigated in the scope of this 305 document. 307 Impact 309 Since IOAM can be applied to a fraction of the traffic, an 310 attacker can detect and delay only the packets that include IOAM 311 data fields, thus preventing the authenticity of delay and load 312 measurements. 314 3.8. Threat Summary 315 +-------------------------------------------+--------+------------+ 316 | Threat |In scope|Out of scope| 317 +-------------------------------------------+--------+------------+ 318 |Modification: IOAM Data Fields | + | | 319 +-------------------------------------------+--------+------------+ 320 |Modification: IOAM Option-Type Headers | + | | 321 +-------------------------------------------+--------+------------+ 322 |Injection: IOAM Data Fields | + | | 323 +-------------------------------------------+--------+------------+ 324 |Injection: IOAM Option-Type Headers | + | | 325 +-------------------------------------------+--------+------------+ 326 |Replay | + | | 327 +-------------------------------------------+--------+------------+ 328 |Management and Exporting | | + | 329 +-------------------------------------------+--------+------------+ 330 |Delay | | + | 331 +-------------------------------------------+--------+------------+ 333 Figure 1: Threat Analysis Summary 335 4. Methods of providing integrity to IOAM data fields 337 This section specifies additional IOAM Option-Types to carry data 338 fields to provide for integrity protection. Methods for integrity 339 protection can leverage symmetric or asymmetric key based signatures 340 as described in the sub-sections below. 342 4.1. Integrity Protected IOAM Option-Types 344 Each of the IOAM Options defined in [I-D.ietf-ippm-ioam-data] are 345 extended to include Integrity Protected (IP) IOAM Option-Types by 346 allocating the following IOAM Option-Types in the IOAM Option-Type 347 registry. 349 64 IOAM Pre-allocated Trace Integrity Protected Option-Type 350 corresponds to IOAM Pre-allocated Trace Option-Type with integrity 351 protection. 353 65 IOAM Incremental Trace Integrity Protected Option-Type corresponds 354 to IOAM Incremental Trace Option-Type with integrity protection. 356 66 IOAM POT Integrity Protected Option-Type corresponds to IOAM POT 357 Option-Type with integrity protection. 359 67 IOAM E2E Integrity Protected Option-Type corresponds to IOAM E2E 360 Option-Type with integrity protection. 362 4.2. Subheader for Integrity Protected IOAM Option-Types 364 An integrity data sub-header is used in IOAM Integrity Protected 365 Options. It is defined as follows: 367 0 1 2 3 368 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 369 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 370 |Signature-suite| Nonce length | Reserved. | 371 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 372 | Nonce ~ 373 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 374 | Signature ~ 375 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 377 Signature-suite: 8-bit unsigned integer. This field defines the 378 algorithms used to compute the digest and the signature over the 379 Option-Type header and data fields excluding the Signature field. 381 Nonce length: 8-bit unsigned integer. This field specifies the 382 length of the Nonce field in octets. 384 Reserved: 16-bit Reserved field. MUST be set to zero upon 385 transmission and ignored upon receipt. 387 Nonce: Nonce is a variable length field with length specified in 388 Nonce length. 390 Signature: Signature is the digital signature value generated by the 391 method and algorithm specified by Signature-suite. 393 The Integrity sub-header follows the IOAM Option-Type header when the 394 IOAM Option-Type is Integrity Protected Option. Pre-allocated and 395 incremental Trace option headers are as defined in 396 [I-D.ietf-ippm-ioam-data]. When the IOAM Option-Type is set to the 397 IOAM Pre-allocated Trace Integrity Protected Option-Type or IOAM 398 Incremental Trace Integrity Protected Option-Type then the Integrity 399 Protection subheader follows the original IOAM Option Type header: : 401 0 1 2 3 402 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 403 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 404 | Namespace-ID |NodeLen | Flags | RemainingLen| 405 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 406 | IOAM-Trace-Type | Reserved | 407 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 408 |Signature-suite| Nonce length | Reserved. | 409 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 410 | Nonce ~ 411 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 412 | Signature ~ 413 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 415 IOAM POT option header as defined in [I-D.ietf-ippm-ioam-data] is 416 followed by Integrity Protection subheader when IOAM Option Type is 417 set to IOAM POT Integrity Protected Option-Type: 419 0 1 2 3 420 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 421 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 422 | Namespace-ID |IOAM POT Type | IOAM POT flags| 423 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 424 |Signature-suite| Nonce length | Reserved. | 425 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 426 | Nonce ~ 427 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 428 | Signature ~ 429 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 431 IOAM E2E option header as defined in [I-D.ietf-ippm-ioam-data] is 432 followed by Integrity Protection subheader when IOAM Option Type is 433 set to IOAM E2E Integrity Protected Option-Type: 435 0 1 2 3 436 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 437 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 438 | Namespace-ID | IOAM-E2E-Type | 439 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 440 |Signature-suite| Nonce length | Reserved. | 441 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 442 | Nonce ~ 443 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 444 | Signature ~ 445 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 447 4.3. Space optimized symmetric key based signing of IOAM data 449 This method assumes that symmetric keys have been distributed to the 450 respective nodes as well as the Validator (the Validator receives all 451 the keys). The details of the mechanisms of how keys are distributed 452 are outside the scope of this document. The "Signature" field is 453 populated as follows: 455 1. The first node creates a nonce and signature over the hash of 456 IOAM Option excluding the Signature field, the nonce and its 457 symmetric key. The nonce is included as a field in Integrity 458 Protection sub-header of the corresponding IOAM Option. The 459 resulting signature is included in the corresponding Signature 460 field. 462 2. Transit nodes will update the Signature field by creating a 463 signature of data where the data is [Signature || 464 hash(node_data_list[x])] with its symmetric key in case of IOAM 465 Trace Integrity Protected Options. Transit nodes updating IOAM 466 POT Option will update the Signature field by creating a 467 signature of data where the data is [Signature || hash(IOAM POT 468 OPTION excluding Signature field)] with its symmetric key in case 469 of IOAM POT Integrity Protected Option. 471 3. The Validator will iteratively recreate the Signature over the 472 IOAM Option fields collected and matches the Signature field to 473 validate the data integrity. 475 This method uses the following algorithms: 477 1. The algorithm to calculate the signature using symmetric key MUST 478 be Advanced Encryption Standard (AES) AES-256. [AES] 479 [NIST.800-38D]. 481 2. The digest/hash algorithm used MUST be SHA-256 [SHS]. 483 4.3.1. Overhead consideration 485 The Signature would consume 32 bytes with AES-256. With this method 486 the Signature is carried only once for the entire packet. As there 487 are dedicated options for carrying IOAM data with integrity 488 protection, in case of performance concerns in calculating signature 489 and validating it, these options can be used for a subset of the 490 packets by using sampling of data to enable IOAM with integrity 491 protection. 493 4.4. Space optimized asymmetric key based signing of trace data 495 This method assumes that asymmetric keys have been generated per IOAM 496 node and the respective nodes can access their keys. The Validator 497 receives all the public keys. The details of the mechanisms of how 498 keys are generated and shared are outside the scope of this document. 499 The " Signature" field is populated as follows: 501 1. The first node creates a nonce and signs over the hash of IOAM 502 Option it populates excluding the Signature field in the option, 503 the nonce and its private key. The resulting signature is 504 included in the Signature field. 506 2. Transit nodes will update the Signature field by creating a 507 signature of data where the data is [Signature || 508 hash(node_data_list[x])] with its private key in case of IOAM 509 Trace Integrity Protected Options. Transit nodes updating IOAM 510 POT Option will update the Signature field by creating a 511 signature of data where the data is [Signature || hash(IOAM POT 512 OPTION excluding Signature field)] with its private key in case 513 of IOAM POT Integrity Protected Option. 515 3. The Validator will iteratively recreate the Signature over the 516 IOAM Option fields collected and matches the Signature field to 517 validate the data integrity using public keys of the IOAM nodes. 519 This method uses the following algorithms: 521 1. The signature algorithm used MUST be the Elliptic Curve Digital 522 Signature Algorithm (ECDSA) with curve P-256 [RFC6090] [DSS]. 524 2. The digest/hash algorithm used MUST be SHA-256 [SHS]. 526 4.4.1. Overhead consideration 528 The Signature consumes 32 bytes based on the SHA-256 ECDSA P-256 529 algorithm employed. With this method the Signature is only carried 530 once for the entire packet. As there are dedicated options for 531 carrying IOAM data with integrity protection, in case of performance 532 concerns in calculating signature and validating it, these options 533 can be used for a subset of the packets by using sampling of data to 534 enable IOAM with integrity protection. 536 5. IANA Considerations 537 5.1. IOAM Option-Type Registry 539 The following code points are defined in this draft in "IOAM Option- 540 Type Registry" : 542 64 IOAM Pre-allocated Trace Integrity Protected Option-Type 544 65 IOAM Incremental Trace Integrity Protected Option-Type 546 66 IOAM POT Integrity Protected Option-Type 548 67 IOAM E2E Integrity Protected Option-Type 550 5.2. IOAM Integrity Protection Algorithm Suite Registry 552 "IOAM Integrity Protection Algorithm Suite Registry" in the "In-Situ 553 OAM (IOAM) Protocol Parameters" group. The one-octet "IOAM Integrity 554 Protection Algorithm Suite Registry" identifiers assigned by IANA 555 identify the digest algorithm and signature algorithm used in the 556 Signature Suite Identifier field. IANA has registered the following 557 algorithm suite identifiers for the digest algorithm and for the 558 signature algorithm. 560 IOAM Integrity Protection Algorithm Suite Registry 562 Algorithm Digest Signature Specification 563 Suite Algorithm Algorithm Pointer 564 Identifier 565 +------------+------------+-------------+-----------------------+ 566 | 0x0 | Reserved | Reserved | This document | 567 +------------+------------+-------------+-----------------------+ 568 | 0x1 | SHA-256 | ECDSA P-256 | [SHS] [DSS] [RFC6090] | 569 | | | | This document | 570 +------------+------------+-------------+-----------------------+ 571 | 0x2 | SHA-256 | AES-256 | [AES] [NIST.800-38D] | 572 | | | | This document | 573 +------------+------------+-------------+-----------------------+ 574 | 0xEF-0xFF | Unassigned | Unassigned | | 575 +------------+------------+-------------+-----------------------+ 577 Future assignments are to be made using the Standards Action process 578 defined in [RFC8126]. Assignments consist of the one-octet algorithm 579 suite identifier value and the associated digest algorithm name and 580 signature algorithm name. 582 6. Security Considerations 584 This section will be completed in a future revision of this document. 586 7. Acknowledgements 588 The authors would like to thank Santhosh N, Rakesh Kandula, Saiprasad 589 Muchala, Al Morton, Greg Mirsky, Benjamin Kaduk and Martin Duke for 590 their comments and advice. 592 8. References 594 8.1. Normative References 596 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 597 Requirement Levels", BCP 14, RFC 2119, 598 DOI 10.17487/RFC2119, March 1997, 599 . 601 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 602 Writing an IANA Considerations Section in RFCs", BCP 26, 603 RFC 8126, DOI 10.17487/RFC8126, June 2017, 604 . 606 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 607 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 608 May 2017, . 610 8.2. Informative References 612 [AES] National Institute of Standards and Technology, "Advanced 613 Encryption Standard (AES)", FIPS PUB 197, 2001, 614 . 617 [DSS] National Institute of Standards and Technology, "Digital 618 Signature Standard (DSS)", NIST FIPS Publication 186-4, 619 DOI 10.6028/NIST.FIPS.186-4, 2013, 620 . 623 [I-D.ietf-detnet-security] 624 Grossman, E., Mizrahi, T., and A. J. Hacker, 625 "Deterministic Networking (DetNet) Security 626 Considerations", draft-ietf-detnet-security-16 (work in 627 progress), March 2021. 629 [I-D.ietf-ippm-ioam-data] 630 Brockners, F., Bhandari, S., and T. Mizrahi, "Data Fields 631 for In-situ OAM", draft-ietf-ippm-ioam-data-15 (work in 632 progress), October 2021. 634 [I-D.ietf-ippm-ioam-direct-export] 635 Song, H., Gafni, B., Zhou, T., Li, Z., Brockners, F., 636 Bhandari, S., Sivakolundu, R., and T. Mizrahi, "In-situ 637 OAM Direct Exporting", draft-ietf-ippm-ioam-direct- 638 export-07 (work in progress), October 2021. 640 [NIST.800-38D] 641 National Institute of Standards and Technology, 642 "Recommendation for Block Cipher Modes of Operation: 643 Galois/Counter Mode (GCM) and GMAC", NIST Special 644 Publication 800-38D, 2001, 645 . 648 [RFC6090] McGrew, D., Igoe, K., and M. Salter, "Fundamental Elliptic 649 Curve Cryptography Algorithms", RFC 6090, 650 DOI 10.17487/RFC6090, February 2011, 651 . 653 [RFC7276] Mizrahi, T., Sprecher, N., Bellagamba, E., and Y. 654 Weingarten, "An Overview of Operations, Administration, 655 and Maintenance (OAM) Tools", RFC 7276, 656 DOI 10.17487/RFC7276, June 2014, 657 . 659 [RFC7384] Mizrahi, T., "Security Requirements of Time Protocols in 660 Packet Switched Networks", RFC 7384, DOI 10.17487/RFC7384, 661 October 2014, . 663 [RFC7799] Morton, A., "Active and Passive Metrics and Methods (with 664 Hybrid Types In-Between)", RFC 7799, DOI 10.17487/RFC7799, 665 May 2016, . 667 [SHS] National Institute of Standards and Technology, "Secure 668 Hash Standard (SHS)", NIST FIPS Publication 180-4, DOI 669 10.6028/NIST.FIPS.180-4, 2015, 670 . 673 Authors' Addresses 675 Frank Brockners 676 Cisco Systems, Inc. 677 Hansaallee 249, 3rd Floor 678 DUESSELDORF, NORDRHEIN-WESTFALEN 40549 679 Germany 681 Email: fbrockne@cisco.com 683 Shwetha Bhandari 684 Thoughtspot 685 3rd Floor, Indiqube Orion, 24th Main Rd, Garden Layout, HSR Layout 686 Bangalore, KARNATAKA 560 102 687 India 689 Email: shwetha.bhandari@thoughtspot.com 691 Tal Mizrahi 692 Huawei 693 8-2 Matam 694 Haifa 3190501 695 Israel 697 Email: tal.mizrahi.phd@gmail.com