idnits 2.17.1 draft-brockners-ippm-ioam-data-integrity-02.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 (July 7, 2021) is 1024 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == 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 (-12) exists of draft-ietf-ippm-ioam-ipv6-options-05 == Outdated reference: A later version (-13) exists of draft-ietf-sfc-ioam-nsh-05 Summary: 0 errors (**), 0 flaws (~~), 5 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: Informational S. Bhandari 5 Expires: January 8, 2022 Thoughtspot 6 T. Mizrahi 7 Huawei 8 July 7, 2021 10 Integrity of In-situ OAM Data Fields 11 draft-brockners-ippm-ioam-data-integrity-02 13 Abstract 15 In-situ Operations, Administration, and Maintenance (IOAM) records 16 operational and telemetry information in the packet while the packet 17 traverses a path between two points in the network. This document is 18 to assist the IPPM WG in designing a solution for those deployments 19 where the integrity of IOAM data fields is a concern. This document 20 proposes several methods to ensure the integrity of IOAM data fields. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at https://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on January 8, 2022. 39 Copyright Notice 41 Copyright (c) 2021 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (https://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 57 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 4 58 3. Threat Analysis . . . . . . . . . . . . . . . . . . . . . . . 5 59 3.1. Modification: IOAM Data Fields . . . . . . . . . . . . . 5 60 3.2. Modification: IOAM Option-Type Headers . . . . . . . . . 6 61 3.3. Injection: IOAM Data Fields . . . . . . . . . . . . . . . 6 62 3.4. Injection: IOAM Option-Type Headers . . . . . . . . . . . 6 63 3.5. Replay . . . . . . . . . . . . . . . . . . . . . . . . . 7 64 3.6. Management and Exporting . . . . . . . . . . . . . . . . 7 65 3.7. Delay . . . . . . . . . . . . . . . . . . . . . . . . . . 7 66 3.8. Threat Summary . . . . . . . . . . . . . . . . . . . . . 8 67 4. Methods of providing integrity to IOAM data fields . . . . . 8 68 4.1. Integrity Protected IOAM Options . . . . . . . . . . . . 9 69 4.2. Integrity Protected IOAM Options sub-header . . . . . . . 9 70 4.3. Space optimized symmetric key based signing of trace data 11 71 4.3.1. Overhead consideration . . . . . . . . . . . . . . . 12 72 4.4. Space optimized asymmetric key based signing of trace 73 data . . . . . . . . . . . . . . . . . . . . . . . . . . 12 74 4.4.1. Overhead consideration . . . . . . . . . . . . . . . 12 75 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 76 5.1. IOAM Option-Type Registry . . . . . . . . . . . . . . . . 13 77 5.2. IOAM Integrity Protection Algorithm Suite Registry . . . 13 78 6. Security Considerations . . . . . . . . . . . . . . . . . . . 14 79 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 80 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 81 8.1. Normative References . . . . . . . . . . . . . . . . . . 14 82 8.2. Informative References . . . . . . . . . . . . . . . . . 14 83 Appendix A. Appendix - Alternate methods for integrity 84 protection and validation . . . . . . . . . . . . . 17 85 A.1. Method 1: Using asymmetric keys for signing node trace 86 data . . . . . . . . . . . . . . . . . . . . . . . . . . 18 87 A.1.1. Overhead consideration for Method 1 . . . . . . . . . 19 88 A.2. Method 2: Using symmetric keys for signing node trace 89 data . . . . . . . . . . . . . . . . . . . . . . . . . . 19 90 A.2.1. Overhead consideration for Method 2 . . . . . . . . . 19 91 A.3. Method 4: Dynamic symmetric keys based signing of trace 92 data . . . . . . . . . . . . . . . . . . . . . . . . . . 20 93 A.3.1. Overhead consideration for Method 4 . . . . . . . . . 22 94 A.4. Method 5: Leverage IP Authentication Header . . . . . . . 22 95 A.4.1. Overhead consideration for Method 5 . . . . . . . . . 23 96 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23 98 1. Introduction 100 "In-situ" Operations, Administration, and Maintenance (IOAM) records 101 OAM information within the packet while the packet traverses a 102 particular network domain. The term "in-situ" refers to the fact 103 that the OAM data is added to the data packets rather than is being 104 sent within packets specifically dedicated to OAM. IOAM is to 105 complement mechanisms such as Ping, Traceroute, or other active 106 probing mechanisms. In terms of "active" or "passive" OAM, "in-situ" 107 OAM can be considered a hybrid OAM type. "In-situ" mechanisms do not 108 require extra packets to be sent. IOAM adds information to the 109 already available data packets and therefore cannot be considered 110 passive. In terms of the classification given in [RFC7799] IOAM 111 could be portrayed as Hybrid Type 1. IOAM mechanisms can be 112 leveraged where mechanisms using e.g. ICMP do not apply or do not 113 offer the desired results, such as proving that a certain traffic 114 flow takes a pre-defined path, SLA verification for the live data 115 traffic, detailed statistics on traffic distribution paths in 116 networks that distribute traffic across multiple paths, or scenarios 117 in which probe traffic is potentially handled differently from 118 regular data traffic by the network devices. 120 The current [I-D.ietf-ippm-ioam-data] assumes that IOAM is deployed 121 in specific network domains, where an operator has means to select, 122 monitor, and control the access to all the networking devices, making 123 the domain a trusted network. As such, IOAM tracing data is carried 124 in the packets in clear and there are no protections against any node 125 or middlebox tampering with the data. As a consequence, IOAM tracing 126 data collected in an untrusted or semi-trusted environments cannot be 127 trusted for critical operational decisions. Any rogue or 128 unauthorized change to IOAM data fields in a user packet cannot be 129 detected. 131 Recent discussions following the IETF last call on 132 [I-D.ietf-ippm-ioam-data] revealed that there might be uses of IOAM 133 where integrity protection of IOAM data fields is at least desirable, 134 knowing that IOAM data fields integrity protection would incur extra 135 effort in the data path of a device processing IOAM data fields. As 136 such, the following additional considerations and requirements are to 137 be taken into account in addition to addressing the problem of 138 detectability of any integrity breach of the IOAM trace data 139 collected: 141 1. IOAM trace data is processed by the data plane, hence viability 142 of any method to prove integrity of the IOAM trace data must be 143 feasible at data plane processing/forwarding rates (IOAM data 144 might be applied to all traffic a router forwards). 146 2. IOAM trace data is carried within data packets. Additional space 147 required to prove integrity of the data needs to be optimal, i.e. 148 should not exceed the MTU or have adverse affect on packet 149 processing. 151 3. Replay protection of older IOAM trace data should be possible. 152 Without replay protection a rogue node can present the old IOAM 153 trace data masking any ongoing network issues/activity making the 154 IOAM trace data collection useless. 156 This document is to assist the IPPM working group in designing and 157 specifying a solution for those deployments where the integrity of 158 IOAM data fields is a concern. This document proposes several 159 methods to achieve integrity protection for IOAM data fields. 161 The discussion of the different methods to protect the integrity of 162 IOAM data fields focuses mostly on protecting the integrity of IOAM 163 trace data fields, though the outlined methods are not limited to 164 protecting IOAM trace data fields only. The methods could be applied 165 to other IOAM Option-Types, such as the E2E Option-Type or the DEX 166 Option-Type. If methods only apply to a specific set of IOAM Option- 167 Types, like e.g. the method 5 discussed below, those limits are 168 discussed and explained explicitly. 170 2. Conventions 172 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 173 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 174 document are to be interpreted as described in [RFC2119]. 176 Abbreviations used in this document: 178 Geneve: Generic Network Virtualization Encapsulation 179 [I-D.ietf-nvo3-geneve] 181 GRE Generic Routing Encapsulation 183 IOAM: In-situ Operations, Administration, and Maintenance 185 MTU: Maximum Transmit Unit 187 NSH: Network Service Header [RFC8300] 189 OAM: Operations, Administration, and Maintenance 191 POT: Proof of Transit 193 SFC: Service Function Chain 195 3. Threat Analysis 197 This section presents a threat analysis of integrity-related threats 198 in the context of IOAM. The threats that are discussed are assumed 199 to be independent of the lower layer protocols; it is assumed that 200 threats at other layers are handled by security mechanisms that are 201 deployed at these layers. 203 This document is focused on integrity protection for IOAM data 204 fields. Thus the threat analysis includes threats that are related 205 to or result from compromising the integrity of IOAM data fields. 206 Other security aspects such as confidentiality are not within the 207 scope of this document. 209 Throughout the analysis there is a distinction between on-path and 210 off-path attackers. As discussed in [I-D.ietf-detnet-security], on- 211 path attackers are located in a position that allows interception and 212 modification of in-flight protocol packets, whereas off-path 213 attackers can only attack by generating protocol packets. 215 The analysis also includes the impact of each of the threats. 216 Generally speaking, the impact of a successful attack on an OAM 217 protocol [RFC7276] is a false illusion of nonexistent failures or 218 preventing the detection of actual ones; in both cases, the attack 219 may result in denial of service (DoS). Furthermore, creating the 220 false illusion of a nonexistent issue may trigger unnecessary 221 processing in some of the IOAM nodes along the path, and may cause 222 more IOAM-related data to be exported to the management plane than is 223 conventionally necessary. Beyond these general impacts, threat- 224 specific impacts are discussed in each of the subsections below. 226 3.1. Modification: IOAM Data Fields 228 Threat 230 An attacker can maliciously modify the IOAM data fields of in- 231 transit packets. The modification can either be applied to all 232 packets or selectively applied to a subset of the en route 233 packets. This threat is applicable to on-path attackers. 235 Impact 237 By systematically modifying the IOAM data fields of some or all of 238 the in-transit packets an attacker can create a false picture of 239 the paths in the network, the existence of faulty nodes and their 240 location, and the network performance. 242 3.2. Modification: IOAM Option-Type Headers 244 Threat 246 An on-path attacker can modify IOAM data fields in one or more of 247 the IOAM Option-Type headers in order to change or disrupt the 248 behavior of nodes processing IOAM data fields along the path. 250 Impact 252 Changing the header of IOAM Option-Types may have several 253 implications. An attacker can maliciously increase the processing 254 overhead in nodes that process IOAM data fields and increase the 255 on-the-wire overhead of IOAM data fields, for example by modifying 256 the IOAM-Trace-Type field in the IOAM Trace-option header. An 257 attacker can also prevent some of the nodes that process IOAM data 258 fields from incorporating IOAM data fields by modifying the 259 RemainingLen field. 261 3.3. Injection: IOAM Data Fields 263 Threat 265 An attacker can inject packets with IOAM Option-Types and IOAM 266 data fields. This threat is applicable to both on-path and off- 267 path attackers. 269 Impact 271 This attack and it impacts are similar to Section 3.1. 273 3.4. Injection: IOAM Option-Type Headers 275 Threat 277 An attacker can inject packets with IOAM Option-Type headers, thus 278 manipulating other nodes that process IOAM data fields in the 279 network. This threat is applicable to both on-path and off-path 280 attackers. 282 Impact 284 This attack and it impacts are similar to Section 3.2. 286 3.5. Replay 288 Threat 290 An attacker can replay packets with IOAM data fields. 291 Specifically, an attacker may replay a previously transmitted IOAM 292 Option-Type with a new data packet, thus attaching old IOAM data 293 fields to a fresh user packet. This threat is applicable to both 294 on-path and off-path attackers. 296 Impact 298 As with previous threats, this threat may create a false image of 299 a nonexistent failure, or may overload nodes which process IOAM 300 data fields with unnecessary processing. 302 3.6. Management and Exporting 304 Threat 306 Attacks that compromise the integrity of IOAM data fields can be 307 applied at the management plane, e.g., by manipulating network 308 management packets. Furthermore, the integrity of IOAM data 309 fields that are exported to a receiving entity can also be 310 compromised. Management plane attacks are not within the scope of 311 this document; the network management protocol is expected to 312 include inherent security capabilities. The integrity of exported 313 data is also not within the scope of this document. It is 314 expected that the specification of the export format will discuss 315 the relevant security aspects. 317 Impact 319 Malicious manipulation of the management protocol can cause nodes 320 that process IOAM data fields to malfunction, to be overloaded, or 321 to incorporate unnecessary IOAM data fields into user packets. 322 The impact of compromising the integrity of exported IOAM data 323 fields is similar to the impacts of previous threats that were 324 described in this section. 326 3.7. Delay 328 Threat 330 An on-path attacker may delay some or all of the in-transit 331 packets that include IOAM data fields in order to create the false 332 illusion of congestion. Delay attacks are well known in the 333 context of deterministic networks [I-D.ietf-detnet-security] and 334 synchronization [RFC7384], and may be somewhat mitigated in these 335 environments by using redundant paths in a way that is resilient 336 to an attack along one of the paths. This approach does not 337 address the threat in the context of IOAM, as it does not meet the 338 requirement to measure a specific path or to detect a problem 339 along the path. It is noted that this threat is not within the 340 scope of the threats that are mitigated in the scope of this 341 document. 343 Impact 345 Since IOAM can be applied to a fraction of the traffic, an 346 attacker can detect and delay only the packets that include IOAM 347 data fields, thus preventing the authenticity of delay and load 348 measurements. 350 3.8. Threat Summary 352 +-------------------------------------------+--------+------------+ 353 | Threat |In scope|Out of scope| 354 +-------------------------------------------+--------+------------+ 355 |Modification: IOAM Data Fields | + | | 356 +-------------------------------------------+--------+------------+ 357 |Modification: IOAM Option-Type Headers | + | | 358 +-------------------------------------------+--------+------------+ 359 |Injection: IOAM Data Fields | + | | 360 +-------------------------------------------+--------+------------+ 361 |Injection: IOAM Option-Type Headers | + | | 362 +-------------------------------------------+--------+------------+ 363 |Replay | + | | 364 +-------------------------------------------+--------+------------+ 365 |Management and Exporting | | + | 366 +-------------------------------------------+--------+------------+ 367 |Delay | | + | 368 +-------------------------------------------+--------+------------+ 370 Figure 1: Threat Analysis Summary 372 4. Methods of providing integrity to IOAM data fields 374 This section describes enhancements to IOAM Options to carry an 375 intergrity data fields. This can be achieved using symmetric or 376 asymetric key based signatures as described below sub-sections. 378 4.1. Integrity Protected IOAM Options 380 Each of the IOAM Options defined in [I-D.ietf-ippm-ioam-data] are 381 extended to include Integrity Protected (IP) options by allocating 382 the following IOAM Option-Types in the IOAM Option-Type registry. 384 64 IOAM Pre-allocated Trace Intergrity Protected Option-Type 385 corresponds to IOAM Pre-allocated Trace Option-Type with integrity 386 protection. 388 65 IOAM Incremental Trace Intergrity Protected Option-Type 389 corresponds to IOAM Incremental Trace Option-Type with integrity 390 protection. 392 66 IOAM POT Intergrity Protected Option-Type corresponds to IOAM POT 393 Option-Type with integrity protection. 395 67 IOAM E2E Intergrity Protected Option-Type corresponds to IOAM E2E 396 Option-Type with integrity protection. 398 4.2. Integrity Protected IOAM Options sub-header 400 The integrity data sub-header is included in IOAM Integrity Protected 401 Options is defined as follows: 403 0 1 2 3 404 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 405 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 406 |Signature-suite| Nonce length | Reserved. | 407 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 408 | Nonce ~ 409 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 410 | Signature ~ 411 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 413 Signature-suite: 8-bit unsigned integer. This field defines the 414 algorithms used to compute digest and signature over the Option 415 header and data excluding the Signature field. 417 Nonce length: 8-bit unsigned integer. This field specifies the 418 length of the Nonce field in octets. 420 Reserved: 16-bit Reserved field MUST be set to zero upon 421 transmission and ignored upon receipt. 423 Nonce: Variable length field with length specified in Nonce length. 425 Signature: is the digital signature value generated by the method 426 and algorithm specified by Signature-suite. 428 The Integrity sub-header will follow the IOAM Option header when the 429 IOAM Option Type is Intergrity Protected Option. Pre-allocated and 430 incremental Trace option headers are as defined in 431 [I-D.ietf-ippm-ioam-data]. When IOAM Option Type is set to IOAM Pre- 432 allocated Trace Intergrity Protected Option-Type or IOAM Incremental 433 Trace Intergrity Protected Option-Type then Integrity Protection 434 subheader follows the original IOAM Option Type header: : 436 0 1 2 3 437 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 438 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 439 | Namespace-ID |NodeLen | Flags | RemainingLen| 440 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 441 | IOAM-Trace-Type | Reserved | 442 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 443 |Signature-suite| Nonce length | Reserved. | 444 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 445 | Nonce ~ 446 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 447 | Signature ~ 448 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 450 IOAM POT option header as defined in [I-D.ietf-ippm-ioam-data] is 451 followed by Integrity Protection subheader when IOAM Option Type is 452 set to IOAM POT Intergrity Protected Option-Type: 454 0 1 2 3 455 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 456 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 457 | Namespace-ID |IOAM POT Type | IOAM POT flags| 458 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 459 |Signature-suite| Nonce length | Reserved. | 460 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 461 | Nonce ~ 462 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 463 | Signature ~ 464 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 466 IOAM E2E option header as defined in [I-D.ietf-ippm-ioam-data] is 467 followed by Integrity Protection subheader when IOAM Option Type is 468 set to IOAM E2E Intergrity Protected Option-Type: 470 0 1 2 3 471 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 472 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 473 | Namespace-ID | IOAM-E2E-Type | 474 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 475 |Signature-suite| Nonce length | Reserved. | 476 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 477 | Nonce ~ 478 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 479 | Signature ~ 480 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 482 4.3. Space optimized symmetric key based signing of trace data 484 This method assumes that symmetric keys have been distributed to the 485 respective nodes as well as the Validator (the Validator receives all 486 the keys). The details of the mechanisms of how keys are distributed 487 are outside the scope of this document. The "Trace Signature" field 488 is populated as follows: 490 1. The first node creates a nonce and signature over the hash of 491 IOAM Option excluding the Signature field, the nonce and its 492 symmetric key. The nonce is included as a field in Integrity 493 Protection sub-header of the corresponding IOAM Option. The 494 resulting signature is included in the corresponding Signature 495 field. 497 2. Intermediate nodes will update the Signature field by creating a 498 signature of data where the data is [Signature || 499 hash(node_data_list[x])] with its symmetric key in case of IOAM 500 Trace Integrity Protected Options. Intermediate nodes updating 501 IOAM POT Option will update the Signature field by creating a 502 signature of data where the data is [Signature || hash(IOAM POT 503 OPTION excluding Signature field)] with its symmetric key in case 504 of IOAM POT Integrity Protected Option. 506 3. The Validator will iteratively recreate the Signature over the 507 IOAM Option fields collected and matches the Signature field to 508 validate the data integrity. 510 This method recommends use of the following algorithms: 512 1. The algorithm to calculate the signature using symmetric key MUST 513 be Advanced Encryption Standard (AES) AES-256. [AES] 514 [NIST.800-38D]. 516 2. The digest/hash algorithm used MUST be SHA-256 [SHS]. 518 4.3.1. Overhead consideration 520 The Signature would consume 32 bytes with AES-256 - though with this 521 method the Signature is only carried once for the entire packet. As 522 there are dedicated options for carrying IOAM data with integrity 523 protection, in case of performance concerns in calculating signature 524 and validating it, these options can be used for a subset of the 525 packets by using sampling of data to enable IOAM with integrity 526 protection. 528 4.4. Space optimized asymmetric key based signing of trace data 530 This method assumes that asymmetric keys have been generated per IOAM 531 node and the respective nodes can access their keys. The Validator 532 receives all the public keys. The details of the mechanisms of how 533 keys are generated and shared are outside the scope of this document. 534 The " Signature" field is populated as follows: 536 1. The first node creates a nonce and signs over the hash of IOAM 537 Option it populates excluding the Signature field in the option, 538 the nonce and its private key. The resulting signature is 539 included in the Signature field. 541 2. Intermediate nodes will update the Signature field by creating a 542 signature of data where the data is [Signature || 543 hash(node_data_list[x])] with its private key in case of IOAM 544 Trace Integrity Protected Options. Intermediate nodes updating 545 IOAM POT Option will update the Signature field by creating a 546 signature of data where the data is [Signature || hash(IOAM POT 547 OPTION excluding Signature field)] with its private key in case 548 of IOAM POT Integrity Protected Option. 550 3. The Validator will iteratively recreate the Signature over the 551 IOAM Option fields collected and matches the Signature field to 552 validate the data integrity using public keys of the IOAM nodes. 554 This method recommend use of the following algorithms: 556 1. The signature algorithm used MUST be the Elliptic Curve Digital 557 Signature Algorithm (ECDSA) with curve P-256 [RFC6090] [DSS]. 559 2. The digest/hash algorithm used MUST be SHA-256 [SHS]. 561 4.4.1. Overhead consideration 563 The Signature would consume 32 bytes based on the SHA-256 ECDSA P-256 564 algorithm employed - though with this method the Signature is only 565 carried once for the entire packet. As there are dedicated options 566 for carrying IOAM data with integrity protection, in case of 567 performance concerns in calculating signature and validating it, 568 these options can be used for a subset of the packets by using 569 sampling of data to enable IOAM with integrity protection. 571 5. IANA Considerations 573 5.1. IOAM Option-Type Registry 575 The following code points are defined in this draft in "IOAM Option- 576 Type Registry" : 578 64 IOAM Pre-allocated Trace Intergrity Protected Option-Type 580 65 IOAM Incremental Trace Intergrity Protected Option-Type 582 66 IOAM POT Intergrity Protected Option-Type 584 67 IOAM E2E Intergrity Protected Option-Type 586 5.2. IOAM Integrity Protection Algorithm Suite Registry 588 "IOAM Integrity Protection Algorithm Suite Registry" in the "In-Situ 589 OAM (IOAM) Protocol Parameters" group. The one-octet "IOAM Integrity 590 Protection Algorithm Suite Registry" identifiers assigned by IANA 591 identify the digest algorithm and signature algorithm used in the 592 Signature Suite Identifier field. IANA has registered the following 593 algorithm suite identifiers for the digest algorithm and for the 594 signature algorithm. 596 IOAM Integrity Protection Algorithm Suite Registry 598 Algorithm Digest Signature Specification 599 Suite Algorithm Algorithm Pointer 600 Identifier 601 +------------+------------+-------------+-----------------------+ 602 | 0x0 | Reserved | Reserved | This document | 603 +------------+------------+-------------+-----------------------+ 604 | 0x1 | SHA-256 | ECDSA P-256 | [SHS] [DSS] [RFC6090] | 605 | | | | This document | 606 +------------+------------+-------------+-----------------------+ 607 | 0x2 | SHA-256 | AES-256 | [AES] [NIST.800-38D] | 608 | | | | This document | 609 +------------+------------+-------------+-----------------------+ 610 | 0xEF-0xFF | Unassigned | Unassigned | | 611 +------------+------------+-------------+-----------------------+ 613 Future assignments are to be made using the Standards Action process 614 defined in [RFC8126]. Assignments consist of the one-octet algorithm 615 suite identifier value and the associated digest algorithm name and 616 signature algorithm name. 618 6. Security Considerations 620 This section will be completed in a future revision of this document. 622 7. Acknowledgements 624 The authors would like to thank Santhosh N, Rakesh Kandula, Saiprasad 625 Muchala, Greg Mirsky, Benjamin Kaduk and Martin Duke for their 626 comments and advice. 628 8. References 630 8.1. Normative References 632 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 633 Requirement Levels", BCP 14, RFC 2119, 634 DOI 10.17487/RFC2119, March 1997, 635 . 637 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 638 Writing an IANA Considerations Section in RFCs", BCP 26, 639 RFC 8126, DOI 10.17487/RFC8126, June 2017, 640 . 642 8.2. Informative References 644 [AES] National Institute of Standards and Technology, "Advanced 645 Encryption Standard (AES)", FIPS PUB 197, 2001, 646 . 649 [BLS] Wikipedia, "BLS (Boneh-Lynn-Shacham) digital signature", 650 2021, 651 . 653 [DSS] National Institute of Standards and Technology, "Digital 654 Signature Standard (DSS)", NIST FIPS Publication 186-4, 655 DOI 10.6028/NIST.FIPS.186-4, 2013, 656 . 659 [EdDSA25519] 660 Wikipedia, "Edwards-curve Digital Signature Algorithm 661 (EdDSA)", 2021, 662 . 664 [I-D.brockners-ippm-ioam-geneve] 665 Brockners, F., Bhandari, S., Govindan, V. P., Pignataro, 666 C., Nainar, N. K., Gredler, H., Leddy, J., Youell, S., 667 Mizrahi, T., Lapukhov, P., Gafni, B., Kfir, A., and M. 668 Spiegel, "Geneve encapsulation for In-situ OAM Data", 669 draft-brockners-ippm-ioam-geneve-05 (work in progress), 670 November 2020. 672 [I-D.ietf-detnet-security] 673 Grossman, E., Mizrahi, T., and A. J. Hacker, 674 "Deterministic Networking (DetNet) Security 675 Considerations", draft-ietf-detnet-security-16 (work in 676 progress), March 2021. 678 [I-D.ietf-ippm-ioam-data] 679 Brockners, F., Bhandari, S., and T. Mizrahi, "Data Fields 680 for In-situ OAM", draft-ietf-ippm-ioam-data-12 (work in 681 progress), February 2021. 683 [I-D.ietf-ippm-ioam-direct-export] 684 Song, H., Gafni, B., Zhou, T., Li, Z., Brockners, F., 685 Bhandari, S., Sivakolundu, R., and T. Mizrahi, "In-situ 686 OAM Direct Exporting", draft-ietf-ippm-ioam-direct- 687 export-03 (work in progress), February 2021. 689 [I-D.ietf-ippm-ioam-ipv6-options] 690 Bhandari, S., Brockners, F., Pignataro, C., Gredler, H., 691 Leddy, J., Youell, S., Mizrahi, T., Kfir, A., Gafni, B., 692 Lapukhov, P., Spiegel, M., Krishnan, S., Asati, R., and M. 693 Smith, "In-situ OAM IPv6 Options", draft-ietf-ippm-ioam- 694 ipv6-options-05 (work in progress), February 2021. 696 [I-D.ietf-nvo3-geneve] 697 Gross, J., Ganga, I., and T. Sridhar, "Geneve: Generic 698 Network Virtualization Encapsulation", draft-ietf- 699 nvo3-geneve-16 (work in progress), March 2020. 701 [I-D.ietf-sfc-ioam-nsh] 702 Brockners, F. and S. Bhandari, "Network Service Header 703 (NSH) Encapsulation for In-situ OAM (IOAM) Data", draft- 704 ietf-sfc-ioam-nsh-05 (work in progress), December 2020. 706 [I-D.ietf-sfc-proof-of-transit] 707 Brockners, F., Bhandari, S., Mizrahi, T., Dara, S., and S. 708 Youell, "Proof of Transit", draft-ietf-sfc-proof-of- 709 transit-08 (work in progress), November 2020. 711 [McEliece] 712 McEliece, R., "A Public-Key Cryptosystem Based on 713 Algebraic Coding Theory", 1978, 714 . 717 [NIST.800-38D] 718 National Institute of Standards and Technology, 719 "Recommendation for Block Cipher Modes of Operation: 720 Galois/Counter Mode (GCM) and GMAC", NIST Special 721 Publication 800-38D, 2001, 722 . 725 [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, 726 DOI 10.17487/RFC4302, December 2005, 727 . 729 [RFC6090] McGrew, D., Igoe, K., and M. Salter, "Fundamental Elliptic 730 Curve Cryptography Algorithms", RFC 6090, 731 DOI 10.17487/RFC6090, February 2011, 732 . 734 [RFC7276] Mizrahi, T., Sprecher, N., Bellagamba, E., and Y. 735 Weingarten, "An Overview of Operations, Administration, 736 and Maintenance (OAM) Tools", RFC 7276, 737 DOI 10.17487/RFC7276, June 2014, 738 . 740 [RFC7384] Mizrahi, T., "Security Requirements of Time Protocols in 741 Packet Switched Networks", RFC 7384, DOI 10.17487/RFC7384, 742 October 2014, . 744 [RFC7799] Morton, A., "Active and Passive Metrics and Methods (with 745 Hybrid Types In-Between)", RFC 7799, DOI 10.17487/RFC7799, 746 May 2016, . 748 [RFC8300] Quinn, P., Ed., Elzur, U., Ed., and C. Pignataro, Ed., 749 "Network Service Header (NSH)", RFC 8300, 750 DOI 10.17487/RFC8300, January 2018, 751 . 753 [SHS] National Institute of Standards and Technology, "Secure 754 Hash Standard (SHS)", NIST FIPS Publication 180-4, DOI 755 10.6028/NIST.FIPS.180-4, 2015, 756 . 759 Appendix A. Appendix - Alternate methods for integrity protection and 760 validation 762 This section outlines three different methods that are to provide 763 integrity protection of IOAM data fields. As noted earlier, this 764 document is to support the IPPM working group in designing and 765 specifying a method for protecting the integrity of IOAM data fields. 766 It isn't expected that all four methods would be chosen for a 767 solution specification. 769 As already stated in the introduction, the discussion of the 770 different methods focuses mostly on protecting the integrity of IOAM 771 trace data fields, though the outlined methods are not limited to 772 protecting IOAM trace data fields only. The methods could be applied 773 to other IOAM Option-Types, such as the E2E Option-Type or the DEX 774 Option-Type. 776 IOAM trace data can be embedded in a variety of protocols. There are 777 specific drafts that cover the encapsulation of IOAM data into 778 different protocols, like IPv6 [I-D.ietf-ippm-ioam-ipv6-options], NSH 779 [I-D.ietf-sfc-ioam-nsh], Geneve [I-D.brockners-ippm-ioam-geneve], 780 etc. 782 The IOAM Option-Types for tracing (Pre-allocated Trace-Option and 783 Incremental Trace-Option) organize the collected data in an array, 784 the "node data list". See [I-D.ietf-ippm-ioam-data] for further 785 details). 787 The basic idea is to introduce a new "signed node-data hash field" 788 added by each node along with the node data to prove the integrity of 789 the node data inserted. 791 The following sections describe different methods of how such a 792 "signed node-data field" could be used and populated. The methods 793 assume an IOAM-Domain containing IOAM-encapsulating nodes, IOAM- 794 decapsulating nodes and IOAM-transit nodes. In addition, it is 795 assumed that traffic also traverses a Validator node, which verifies 796 the integrity of the IOAM data fields. In a typical deployment, the 797 IOAM-decapsulating node would also serve as the Validator. The setup 798 also includes a network management entity/controller which handles 799 key distributions to the network nodes and also serves as a receiver 800 for validation results provided by the Validator. Protocols and 801 procedures for the exchange of keys and validation results between 802 the network management entity/controller and the nodes are outside 803 the scope of this document. 805 A.1. Method 1: Using asymmetric keys for signing node trace data 807 Method 1 uses asymmetric keys for signing node trace data. This is 808 the procedure to be followed by each node: 810 1. Each IOAM capable node creates a key pair and shares the public 811 key with the controller, the Validator and the network management 812 system responsible for using the IOAM trace information in the 813 network domain. The detailed mechanisms how keys are exchanged 814 between nodes are outside the scope of this document. For 815 optimal performance, use of algorithms like BLS [BLS] or ED25519 816 [EdDSA25519] are suggested, resulting in fast signing for small 817 keys and limited overhead (see below for an overhead 818 calculation). 820 2. Each node data list [x] field is extended with an additional 821 "signed node-data" field: node_data_sign[x]. Node_data_sign 822 includes a signature using the private key of the node over the 823 hash of node data list[x] of the node and the previous node's 824 node data sign node_data_sign[x-1]. This couples the signature 825 of the current field to the earlier field and creates a chain of 826 trust. This way of chaining the node data signatures provides 827 protection against replay of a previous node trace of a specific 828 node. 830 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 831 | node_data_sign [x] | 832 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 833 | | 834 | node data list [x] | 835 | | 836 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 838 3. The IOAM encapsulating node (the node that inserts IOAM data 839 fields into the packet) will add a seed in its node data list 840 that is used in its node_data_sign. So the first IOAM node 841 inserting the IOAM trace data will add node_data_sign over a 842 "seed" || [hash of node data of first node]. The seed can be 843 included as a field in first node data or the seed can be the 844 trailer of the IOAM Trace-Option. 846 4. The validating node - will use the public key of each node to 847 validate the signed node data elements in the same way the node 848 Trace signatures were created, i.e. it'll repeat the individual 849 operations of the IOAM nodes traversed and will compare the 850 result to the last node's node_data-sign value. If the two 851 values match, the IOAM data was not tampered with. 853 A.1.1. Overhead consideration for Method 1 855 Assuming e.g Ed25519, the public keys would have a size of 256 bits / 856 32 bytes, and as such signatures would be 512 bits / 64 bytes wide. 857 node_data_sign[x] would consume 64 bytes per hop. Note that 858 depending on the deployment, weaker keys might well apply, given that 859 the provided integrity check is an online method, i.e. packets are 860 verified as they arrive. This allows an attacker only a short time- 861 window. 863 A.2. Method 2: Using symmetric keys for signing node trace data 865 The same procedure as Method 1 can be followed by using a MAC 866 (Message Authentication Code) algorithm for node signature. This 867 involves distributing a secret key to the individual IOAM nodes and 868 the Validator. Steps 1 to 4 of Method 1 apply in a similar way, the 869 only difference is that symmetric keys are used. As such, each node 870 data list [x] field is extended with an additional "signed node-data" 871 field: node_data_sign[x]. The size of the node_data_sign[x] field 872 depends on the cryptographic message authentication code used. 874 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 875 | node_data_sign [x] | 876 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 877 | | 878 | node data list [x] | 879 | | 880 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 882 A.2.1. Overhead consideration for Method 2 884 Different types of cryptographic message authentication codes could 885 be chosen, such as HMAC-SHA256 or Poly1305-AES. 887 HMAC-SHA256 would take a secret key of any size and provide a 32 byte 888 authenticator. Consequently, node_data_sign[x] would consume 32 889 bytes per hop. 891 Poly1305-AES would use a 32 bytes secret key and provide a 16 byte 892 authenticator. Consequently, node_data_sign[x] would consume 16 893 bytes per hop. 895 Methods 1 and 2 add a node_data_sign field at every IOAM node the 896 packet traverses. While feasible for network domains with only a few 897 IOAM enabled hops, the number of bytes consumed in case of larger 898 networks might not be acceptable. 900 A.3. Method 4: Dynamic symmetric keys based signing of trace data 902 This method builds on top of Method 3 leverages Post-quantum Secure 903 Pre-shared key distribution for deriving a dynamic symmetric key for 904 every packet or a set of packets. The method utilizes the dynamic 905 keys to provide for replay protection and does not require a seed to 906 be added to the trace data to protect from replays because a private 907 key is derived for each packet. The method relies on a local service 908 that generates common Key/KeyID pairs for the participating Node and 909 Validator (see the figure below). This common key generator uses 910 ratcheting cryptography to generate the next secret while forgetting 911 about the previous one. A unique ID is paired with each secret 912 generated. Given the same seed secret as input parameter, two 913 implementations of the common key generator will generate the exact 914 same key and associated ID. The common key generator can be queried 915 for the next key or for a specific key ID. 917 The figure below illustrates the concept: 919 Validator Node 920 | | 921 | | 922 Generate McEliece | 923 public/private key-pair | 924 | | 925 |<---Establ. classic secure connection---------| 926 | (e.g. TLS) | 927 |---Send public key over secure connection---->| 928 | | 929 | Generate random secret nonce 930 | and encrypt w/ Validator 931 | public key 932 | | 933 |<--Send encrypted seed over secure connection-| 934 | | 935 Decrypt secret nonce sent from Node | 936 using Validator's private key | 937 | | 938 (-- Common secret nonce established between --) 939 (-- Node and Validator --) 940 | | 941 | Generate Node's KeyID pair 942 | based on common secret nonce 943 | | 944 | Use Node's key to update Signature field 945 | in Integrity protection option header. Include Node's 946 | KeyID in the extended node data. 947 | | 948 (-- Packet reaches Validator --) 949 | | 950 Get Node's key using Node's KeyID | 951 present in extended node data. | 952 Validate Signature using Node's key. | 954 The main steps of method 4 are: 956 1. Each node will establish a common secret seed establishment using 957 McEliece [McEliece] with the Validator. 959 2. Each node will then use the seed to generate a symmetric key per 960 packet and use it in updating the Signature field in the IOAM 961 Trace-Option header over its node data hash. The node data is 962 extended to include the KeyID of the dynamic key generated. 964 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 965 | KeyID [x] | 966 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 967 | | 968 | node data list [x] | 969 | | 970 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 972 3. The Validator will validate the Signature by deducing the key for 973 each node using the KeyID. 975 The detailed mechanisms how keys and seeds are exchanged between 976 nodes are outside the scope of this document. 978 A.3.1. Overhead consideration for Method 4 980 Like with method 3, the Signature is only carried once for the entire 981 packet and could be 32 bytes total. In addition, the KeyID needs to 982 be added on a per hop basis. For sizing the Key ID, similar 983 considerations like those for proof-of-transit packet random numbers 984 apply - i.e. it depends on the packet rates of quickly keys are 985 consumed. E.g. assuming a packet rate of 100Gbps and a KeyID space 986 of 64 bits / 8 bytes, the system would need to be re-keyed after 3100 987 years (see also [I-D.ietf-sfc-proof-of-transit]). If frequent re- 988 keying is feasible, 32 bits for KeyID might well be feasible. 990 A.4. Method 5: Leverage IP Authentication Header 992 The IP Authentication Header (AH) is used to provide connectionless 993 integrity and data origin authentication for IP datagrams and to 994 provide protection against replays as defined in RFC4302 [RFC4302]. 995 The AH provides authentication for as much of the IP header as 996 possible, by classifying and including the immutable fields in the 997 integrity calculation. To protect the IOAM data in the IP header, 998 the AH may be employed in transport mode by setting up an IP AH 999 Security Association (SA) with supported integrity algorithms between 1000 IOAM encapsulating nodes, IOAM decapsulating nodes and IOAM transit 1001 nodes. Method 5 utilizes the IP AH for integrity protection of IOAM 1002 options that are immutable enroute between IOAM entities that are 1003 required to validate the integrity of the IOAM data. It is 1004 applicable to IOAM Option-Types as follows: 1006 1. IOAM Edge-to-Edge Option-Type: The data for this IOAM Option-Type 1007 is immutable enroute and can be integrity checked using an IP AH 1008 between IOAM-encapsulating nodes and IOAM-decapsulating nodes. 1010 2. The Direct Exporting (DEX) IOAM Option-Type 1011 ([I-D.ietf-ippm-ioam-direct-export]): The data for this IOAM 1012 Option-Type is immutable enroute and can be integrity checked 1013 using an IP AH between IOAM-encapsulating nodes and IOAM- 1014 decapsulating nodes. IOAM-transit nodes, that use the IOAM DEX 1015 Option-Type as a trigger to export IOAM data fields, and which 1016 are to validate the IOAM DEX Option-Type data fields may have to 1017 be configured with shared secrets, in case the AH negotiated 1018 integrity algorithm relies on shared secrets. These shared 1019 secrets correspond to those secrets that result from the IP AH 1020 integrity algorithm negotiated during SA setup. 1022 3. IOAM Proof of Transit Option-Type: This IOAM Option-Type is 1023 mutable by IOAM-transit nodes enroute that participate in proof 1024 of transit operation. Hence the IP AH based integrity protection 1025 method does not apply. 1027 4. IOAM Pre-allocated and Incremental Trace Option-Types: These IOAM 1028 Option-Types are mutable by IOAM-transit nodes encroute that 1029 process IOAM tracing Option-Types. Hence the IP AH based 1030 integrity protection method does not apply. 1032 A.4.1. Overhead consideration for Method 5 1034 This method involves overhead of setting up and maintaining SA for 1035 the AH IOAM-encapsulating nodes and IOAM-decapsulating nodes. The 1036 anti-replay mechanism supported by IP AH must be enabled for this 1037 method to effectively protect IOAM data fields whose integrity and 1038 freshness needs to be guarenteed. The anti-replay mechanism of IP AH 1039 has the overhead of maintaining and validating sequence numbers as 1040 part of the IP AH validation. In cases where IOAM-transit nodes have 1041 to validate IOAM Option-Types e.g. the DEX Option-Type, then there 1042 will be additional overhead to distribute shared secrets to the 1043 transit nodes when the integrity algorithm is based on shared 1044 secrets. 1046 Authors' Addresses 1048 Frank Brockners 1049 Cisco Systems, Inc. 1050 Hansaallee 249, 3rd Floor 1051 DUESSELDORF, NORDRHEIN-WESTFALEN 40549 1052 Germany 1054 Email: fbrockne@cisco.com 1055 Shwetha Bhandari 1056 Thoughtspot 1057 3rd Floor, Indiqube Orion, 24th Main Rd, Garden Layout, HSR Layout 1058 Bangalore, KARNATAKA 560 102 1059 India 1061 Email: shwetha.bhandari@thoughtspot.com 1063 Tal Mizrahi 1064 Huawei 1065 8-2 Matam 1066 Haifa 3190501 1067 Israel 1069 Email: tal.mizrahi.phd@gmail.com