idnits 2.17.1 draft-brockners-ippm-ioam-data-integrity-01.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 doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (February 21, 2021) is 1160 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC8126' is defined on line 717, but no explicit reference was found in the text == Outdated reference: A later version (-16) exists of draft-ietf-detnet-security-13 == 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 (-12) exists of draft-ietf-ippm-ioam-ipv6-options-04 == Outdated reference: A later version (-13) exists of draft-ietf-sfc-ioam-nsh-05 Summary: 0 errors (**), 0 flaws (~~), 8 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: August 25, 2021 Thoughtspot 6 T. Mizrahi 7 Huawei 8 February 21, 2021 10 Integrity of In-situ OAM Data Fields 11 draft-brockners-ippm-ioam-data-integrity-01 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 August 25, 2021. 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 57 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 4 58 3. Threat Analysis . . . . . . . . . . . . . . . . . . . . . . . 4 59 3.1. Modification: IOAM Data Fields . . . . . . . . . . . . . 5 60 3.2. Modification: IOAM Option-Type Headers . . . . . . . . . 5 61 3.3. Injection: IOAM Data Fields . . . . . . . . . . . . . . . 6 62 3.4. Injection: IOAM Option-Type Headers . . . . . . . . . . . 6 63 3.5. Replay . . . . . . . . . . . . . . . . . . . . . . . . . 6 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. Method 1: Using asymmetric keys for signing node trace 69 data . . . . . . . . . . . . . . . . . . . . . . . . . . 9 70 4.1.1. Overhead consideration for Method 1 . . . . . . . . . 10 71 4.2. Method 2: Using symmetric keys for signing node trace 72 data . . . . . . . . . . . . . . . . . . . . . . . . . . 10 73 4.2.1. Overhead consideration for Method 2 . . . . . . . . . 11 74 4.3. Method 3: Space optimized symmetric key based signing of 75 trace data . . . . . . . . . . . . . . . . . . . . . . . 11 76 4.3.1. Overhead consideration for Method 3 . . . . . . . . . 12 77 4.4. Method 4: Dynamic symmetric keys based signing of trace 78 data . . . . . . . . . . . . . . . . . . . . . . . . . . 12 79 4.4.1. Overhead consideration for Method 4 . . . . . . . . . 14 80 4.5. Method 5: Leverage IP Authentication Header . . . . . . . 14 81 4.5.1. Overhead consideration for Method 5 . . . . . . . . . 15 82 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 83 6. Security Considerations . . . . . . . . . . . . . . . . . . . 16 84 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16 85 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 86 8.1. Normative References . . . . . . . . . . . . . . . . . . 16 87 8.2. Informative References . . . . . . . . . . . . . . . . . 16 88 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 90 1. Introduction 92 "In-situ" Operations, Administration, and Maintenance (IOAM) records 93 OAM information within the packet while the packet traverses a 94 particular network domain. The term "in-situ" refers to the fact 95 that the OAM data is added to the data packets rather than is being 96 sent within packets specifically dedicated to OAM. IOAM is to 97 complement mechanisms such as Ping, Traceroute, or other active 98 probing mechanisms. In terms of "active" or "passive" OAM, "in-situ" 99 OAM can be considered a hybrid OAM type. "In-situ" mechanisms do not 100 require extra packets to be sent. IOAM adds information to the 101 already available data packets and therefore cannot be considered 102 passive. In terms of the classification given in [RFC7799] IOAM 103 could be portrayed as Hybrid Type 1. IOAM mechanisms can be 104 leveraged where mechanisms using e.g. ICMP do not apply or do not 105 offer the desired results, such as proving that a certain traffic 106 flow takes a pre-defined path, SLA verification for the live data 107 traffic, detailed statistics on traffic distribution paths in 108 networks that distribute traffic across multiple paths, or scenarios 109 in which probe traffic is potentially handled differently from 110 regular data traffic by the network devices. 112 The current [I-D.ietf-ippm-ioam-data] assumes that IOAM is deployed 113 in specific network domains, where an operator has means to select, 114 monitor, and control the access to all the networking devices, making 115 the domain a trusted network. As such, IOAM tracing data is carried 116 in the packets in clear and there are no protections against any node 117 or middlebox tampering with the data. As a consequence, IOAM tracing 118 data collected in an untrusted or semi-trusted environments cannot be 119 trusted for critical operational decisions. Any rogue or 120 unauthorized change to IOAM data fields in a user packet cannot be 121 detected. 123 Recent discussions following the IETF last call on 124 [I-D.ietf-ippm-ioam-data] revealed that there might be uses of IOAM 125 where integrity protection of IOAM data fields is at least desirable, 126 knowing that IOAM data fields integrity protection would incur extra 127 effort in the data path of a device processing IOAM data fields. As 128 such, the following additional considerations and requirements are to 129 be taken into account in addition to addressing the problem of 130 detectability of any integrity breach of the IOAM trace data 131 collected: 133 1. IOAM trace data is processed by the data plane, hence viability 134 of any method to prove integrity of the IOAM trace data must be 135 feasible at data plane processing/forwarding rates (IOAM data 136 might be applied to all traffic a router forwards). 138 2. IOAM trace data is carried within data packets. Additional space 139 required to prove integrity of the data needs to be optimal, i.e. 140 should not exceed the MTU or have adverse affect on packet 141 processing. 143 3. Replay protection of older IOAM trace data should be possible. 144 Without replay protection a rogue node can present the old IOAM 145 trace data masking any ongoing network issues/activity making the 146 IOAM trace data collection useless. 148 This document is to assist the IPPM working group in designing and 149 specifying a solution for those deployments where the integrity of 150 IOAM data fields is a concern. This document proposes several 151 methods to achieve integrity protection for IOAM data fields. 153 The discussion of the different methods to protect the integrity of 154 IOAM data fields focuses mostly on protecting the integrity of IOAM 155 trace data fields, though the outlined methods are not limited to 156 protecting IOAM trace data fields only. The methods could be applied 157 to other IOAM Option-Types, such as the E2E Option-Type or the DEX 158 Option-Type. If methods only apply to a specific set of IOAM Option- 159 Types, like e.g. the method 5 discussed below, those limits are 160 discussed and explained explicitly. 162 2. Conventions 164 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 165 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 166 document are to be interpreted as described in [RFC2119]. 168 Abbreviations used in this document: 170 Geneve: Generic Network Virtualization Encapsulation 171 [I-D.ietf-nvo3-geneve] 173 GRE Generic Routing Encapsulation 175 IOAM: In-situ Operations, Administration, and Maintenance 177 MTU: Maximum Transmit Unit 179 NSH: Network Service Header [RFC8300] 181 OAM: Operations, Administration, and Maintenance 183 POT: Proof of Transit 185 SFC: Service Function Chain 187 3. Threat Analysis 189 This section presents a threat analysis of integrity-related threats 190 in the context of IOAM. The threats that are discussed are assumed 191 to be independent of the lower layer protocols; it is assumed that 192 threats at other layers are handled by security mechanisms that are 193 deployed at these layers. 195 This document is focused on integrity protection for IOAM data 196 fields. Thus the threat analysis includes threats that are related 197 to or result from compromising the integrity of IOAM data fields. 198 Other security aspects such as confidentiality are not within the 199 scope of this document. 201 Throughout the analysis there is a distinction between on-path and 202 off-path attackers. As discussed in [I-D.ietf-detnet-security], on- 203 path attackers are located in a position that allows interception and 204 modification of in-flight protocol packets, whereas off-path 205 attackers can only attack by generating protocol packets. 207 The analysis also includes the impact of each of the threats. 208 Generally speaking, the impact of a successful attack on an OAM 209 protocol [RFC7276] is a false illusion of nonexistent failures or 210 preventing the detection of actual ones; in both cases, the attack 211 may result in denial of service (DoS). Furthermore, creating the 212 false illusion of a nonexistent issue may trigger unnecessary 213 processing in some of the IOAM nodes along the path, and may cause 214 more IOAM-related data to be exported to the management plane than is 215 conventionally necessary. Beyond these general impacts, threat- 216 specific impacts are discussed in each of the subsections below. 218 3.1. Modification: IOAM Data Fields 220 Threat 222 An attacker can maliciously modify the IOAM data fields of in- 223 transit packets. The modification can either be applied to all 224 packets or selectively applied to a subset of the en route 225 packets. This threat is applicable to on-path attackers. 227 Impact 229 By systematically modifying the IOAM data fields of some or all of 230 the in-transit packets an attacker can create a false picture of 231 the paths in the network, the existence of faulty nodes and their 232 location, and the network performance. 234 3.2. Modification: IOAM Option-Type Headers 236 Threat 237 An on-path attacker can modify IOAM data fields in one or more of 238 the IOAM Option-Type headers in order to change or disrupt the 239 behavior of nodes processing IOAM data fields along the path. 241 Impact 243 Changing the header of IOAM Option-Types may have several 244 implications. An attacker can maliciously increase the processing 245 overhead in nodes that process IOAM data fields and increase the 246 on-the-wire overhead of IOAM data fields, for example by modifying 247 the IOAM-Trace-Type field in the IOAM Trace-option header. An 248 attacker can also prevent some of the nodes that process IOAM data 249 fields from incorporating IOAM data fields by modifying the 250 RemainingLen field. 252 3.3. Injection: IOAM Data Fields 254 Threat 256 An attacker can inject packets with IOAM Option-Types and IOAM 257 data fields. This threat is applicable to both on-path and off- 258 path attackers. 260 Impact 262 This attack and it impacts are similar to Section 3.1. 264 3.4. Injection: IOAM Option-Type Headers 266 Threat 268 An attacker can inject packets with IOAM Option-Type headers, thus 269 manipulating other nodes that process IOAM data fields in the 270 network. This threat is applicable to both on-path and off-path 271 attackers. 273 Impact 275 This attack and it impacts are similar to Section 3.2. 277 3.5. Replay 279 Threat 281 An attacker can replay packets with IOAM data fields. 282 Specifically, an attacker may replay a previously transmitted IOAM 283 Option-Type with a new data packet, thus attaching old IOAM data 284 fields to a fresh user packet. This threat is applicable to both 285 on-path and off-path attackers. 287 Impact 289 As with previous threats, this threat may create a false image of 290 a nonexistent failure, or may overload nodes which process IOAM 291 data fields with unnecessary processing. 293 3.6. Management and Exporting 295 Threat 297 Attacks that compromise the integrity of IOAM data fields can be 298 applied at the management plane, e.g., by manipulating network 299 management packets. Furthermore, the integrity of IOAM data 300 fields that are exported to a receiving entity can also be 301 compromised. Management plane attacks are not within the scope of 302 this document; the network management protocol is expected to 303 include inherent security capabilities. The integrity of exported 304 data is also not within the scope of this document. It is 305 expected that the specification of the export format will discuss 306 the relevant security aspects. 308 Impact 310 Malicious manipulation of the management protocol can cause nodes 311 that process IOAM data fields to malfunction, to be overloaded, or 312 to incorporate unnecessary IOAM data fields into user packets. 313 The impact of compromising the integrity of exported IOAM data 314 fields is similar to the impacts of previous threats that were 315 described in this section. 317 3.7. Delay 319 Threat 321 An on-path attacker may delay some or all of the in-transit 322 packets that include IOAM data fields in order to create the false 323 illusion of congestion. Delay attacks are well known in the 324 context of deterministic networks [I-D.ietf-detnet-security] and 325 synchronization [RFC7384], and may be somewhat mitigated in these 326 environments by using redundant paths in a way that is resilient 327 to an attack along one of the paths. This approach does not 328 address the threat in the context of IOAM, as it does not meet the 329 requirement to measure a specific path or to detect a problem 330 along the path. It is noted that this threat is not within the 331 scope of the threats that are mitigated in the scope of this 332 document. 334 Impact 336 Since IOAM can be applied to a fraction of the traffic, an 337 attacker can detect and delay only the packets that include IOAM 338 data fields, thus preventing the authenticity of delay and load 339 measurements. 341 3.8. Threat Summary 343 +-------------------------------------------+--------+------------+ 344 | Threat |In scope|Out of scope| 345 +-------------------------------------------+--------+------------+ 346 |Modification: IOAM Data Fields | + | | 347 +-------------------------------------------+--------+------------+ 348 |Modification: IOAM Option-Type Headers | + | | 349 +-------------------------------------------+--------+------------+ 350 |Injection: IOAM Data Fields | + | | 351 +-------------------------------------------+--------+------------+ 352 |Injection: IOAM Option-Type Headers | + | | 353 +-------------------------------------------+--------+------------+ 354 |Replay | + | | 355 +-------------------------------------------+--------+------------+ 356 |Management and Exporting | | + | 357 +-------------------------------------------+--------+------------+ 358 |Delay | | + | 359 +-------------------------------------------+--------+------------+ 361 Figure 1: Threat Analysis Summary 363 4. Methods of providing integrity to IOAM data fields 365 This section outlines four different methods that are to provide 366 integrity protection of IOAM data fields. As noted earlier, this 367 document is to support the IPPM working group in designing and 368 specifying a method for protecting the integrity of IOAM data fields. 369 It isn't expected that all four methods would be chosen for a 370 solution specification. 372 As already stated in the introduction, the discussion of the 373 different methods focuses mostly on protecting the integrity of IOAM 374 trace data fields, though the outlined methods are not limited to 375 protecting IOAM trace data fields only. The methods could be applied 376 to other IOAM Option-Types, such as the E2E Option-Type or the DEX 377 Option-Type. 379 IOAM trace data can be embedded in a variety of protocols. There are 380 specific drafts that cover the encapsulation of IOAM data into 381 different protocols, like IPv6 [I-D.ietf-ippm-ioam-ipv6-options], NSH 382 [I-D.ietf-sfc-ioam-nsh], Geneve [I-D.brockners-ippm-ioam-geneve], 383 etc. 385 The IOAM Option-Types for tracing (Pre-allocated Trace-Option and 386 Incremental Trace-Option) organize the collected data in an array, 387 the "node data list". See [I-D.ietf-ippm-ioam-data] for further 388 details). 390 The basic idea is to introduce a new "signed node-data hash field" 391 added by each node along with the node data to prove the integrity of 392 the node data inserted. 394 The following sections describe different methods of how such a 395 "signed node-data field" could be used and populated. The methods 396 assume an IOAM-Domain containing IOAM-encapsulating nodes, IOAM- 397 decapsulating nodes and IOAM-transit nodes. In addition, it is 398 assumed that traffic also traverses a Validator node, which verifies 399 the integrity of the IOAM data fields. In a typical deployment, the 400 IOAM-decapsulating node would also serve as the Validator. The setup 401 also includes a network management entity/controller which handles 402 key distributions to the network nodes and also serves as a receiver 403 for validation results provided by the Validator. Protocols and 404 procedures for the exchange of keys and validation results between 405 the network management entity/controller and the nodes are outside 406 the scope of this document. 408 4.1. Method 1: Using asymmetric keys for signing node trace data 410 Method 1 uses asymmetric keys for signing node trace data. This is 411 the procedure to be followed by each node: 413 1. Each IOAM capable node creates a key pair and shares the public 414 key with the controller, the Validator and the network management 415 system responsible for using the IOAM trace information in the 416 network domain. The detailed mechanisms how keys are exchanged 417 between nodes are outside the scope of this document. For 418 optimal performance, use of algorithms like BLS [BLS] or ED25519 419 [EdDSA25519] are suggested, resulting in fast signing for small 420 keys and limited overhead (see below for an overhead 421 calculation). 423 2. Each node data list [x] field is extended with an additional 424 "signed node-data" field: node_data_sign[x]. Node_data_sign 425 includes a signature using the private key of the node over the 426 hash of node data list[x] of the node and the previous node's 427 node data sign node_data_sign[x-1]. This couples the signature 428 of the current field to the earlier field and creates a chain of 429 trust. This way of chaining the node data signatures provides 430 protection against replay of a previous node trace of a specific 431 node. 433 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 434 | node_data_sign [x] | 435 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 436 | | 437 | node data list [x] | 438 | | 439 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 441 3. The IOAM encapsulating node (the node that inserts IOAM data 442 fields into the packet) will add a seed in its node data list 443 that is used in its node_data_sign. So the first IOAM node 444 inserting the IOAM trace data will add node_data_sign over a 445 "seed" || [hash of node data of first node]. The seed can be 446 included as a field in first node data or the seed can be the 447 trailer of the IOAM Trace-Option. 449 4. The validating node - will use the public key of each node to 450 validate the signed node data elements in the same way the node 451 Trace signatures were created, i.e. it'll repeat the individual 452 operations of the IOAM nodes traversed and will compare the 453 result to the last node's node_data-sign value. If the two 454 values match, the IOAM data was not tampered with. 456 4.1.1. Overhead consideration for Method 1 458 Assuming e.g Ed25519, the public keys would have a size of 256 bits / 459 32 bytes, and as such signatures would be 512 bits / 64 bytes wide. 460 node_data_sign[x] would consume 64 bytes per hop. Note that 461 depending on the deployment, weaker keys might well apply, given that 462 the provided integrity check is an online method, i.e. packets are 463 verified as they arrive. This allows an attacker only a short time- 464 window. 466 4.2. Method 2: Using symmetric keys for signing node trace data 468 The same procedure as Method 1 can be followed by using a MAC 469 (Message Authentication Code) algorithm for node signature. This 470 involves distributing a secret key to the individual IOAM nodes and 471 the Validator. Steps 1 to 4 of Method 1 apply in a similar way, the 472 only difference is that symmetric keys are used. As such, each node 473 data list [x] field is extended with an additional "signed node-data" 474 field: node_data_sign[x]. The size of the node_data_sign[x] field 475 depends on the cryptographic message authentication code used. 477 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 478 | node_data_sign [x] | 479 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 480 | | 481 | node data list [x] | 482 | | 483 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 485 4.2.1. Overhead consideration for Method 2 487 Different types of cryptographic message authentication codes could 488 be chosen, such as HMAC-SHA256 or Poly1305-AES. 490 HMAC-SHA256 would take a secret key of any size and provide a 32 byte 491 authenticator. Consequently, node_data_sign[x] would consume 32 492 bytes per hop. 494 Poly1305-AES would use a 32 bytes secret key and provide a 16 byte 495 authenticator. Consequently, node_data_sign[x] would consume 16 496 bytes per hop. 498 4.3. Method 3: Space optimized symmetric key based signing of trace 499 data 501 Methods 1 and 2 add a node_data_sign field at every IOAM node the 502 packet traverses. While feasible for network domains with only a few 503 IOAM enabled hops, the number of bytes consumed in case of larger 504 networks might not be acceptable. For those deployments, an approach 505 with a single fixed sized signature field could apply. 507 Method 3 enhances the IOAM Trace-Option header to carry a "Trace 508 Signature" field. 510 0 1 2 3 511 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 512 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 513 | Namespace-ID |NodeLen | Flags | RemainingLen| 514 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 515 | IOAM-Trace-Type | Reserved | 516 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 517 | Trace Signature ~ 518 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 520 Method 3 assumes that symmetric keys have been distributed to the 521 respective nodes as well as the Validator (the Validator receives all 522 the keys). The details of the mechanisms of how keys are distributed 523 are outside the scope of this document. The "Trace Signature" field 524 is populated as follows: 526 1. The first node creates a seed and sign/HMAC over the hash of its 527 node_data_list[x], the seed and its symmetric key. The seed can 528 be included as a field in first node data or the seed can be the 529 trailer to the trace option. The resulting HMAC/signature is 530 included in the Trace Signature field. 532 2. Subsequent nodes will update the Trace Signature field by 533 creating a signature/HMAC of data where the data is [Trace 534 Signature || its node_data_list[x] hash] with its symmetric key. 536 3. The Validator will iteratively recreate the Trace Signature over 537 the node data trace fields collected and matches the Trace 538 Signature field to validate the trace data integrity. 540 4.3.1. Overhead consideration for Method 3 542 Much like method 2, the Trace Signature would consume 16 or 32 bytes 543 - though with method 3, the Trace Signature is only carried once for 544 the entire packet. 546 4.4. Method 4: Dynamic symmetric keys based signing of trace data 548 This method builds on top of Method 3 leverages Post-quantum Secure 549 Pre-shared key distribution for deriving a dynamic symmetric key for 550 every packet or a set of packets. The method utilizes the dynamic 551 keys to provide for replay protection and does not require a seed to 552 be added to the trace data to protect from replays because a private 553 key is derived for each packet. The method relies on a local service 554 that generates common Key/KeyID pairs for the participating Node and 555 Validator (see the figure below). This common key generator uses 556 ratcheting cryptography to generate the next secret while forgetting 557 about the previous one. A unique ID is paired with each secret 558 generated. Given the same seed secret as input parameter, two 559 implementations of the common key generator will generate the exact 560 same key and associated ID. The common key generator can be queried 561 for the next key or for a specific key ID. 563 The figure below illustrates the concept: 565 Validator Node 566 | | 567 | | 568 Generate McEliece | 569 public/private key-pair | 570 | | 571 |<---Establ. classic secure connection---------| 572 | (e.g. TLS) | 573 |---Send public key over secure connection---->| 574 | | 575 | Generate random secret seed 576 | and encrypt w/ Validator 577 | public key 578 | | 579 |<--Send encrypted seed over secure connection-| 580 | | 581 Decrypt secret seed sent from Node | 582 using Validator's private key | 583 | | 584 (-- Common secret seed established between --) 585 (-- Node and Validator --) 586 | | 587 | Generate Node's KeyID pair 588 | based on common secret seed 589 | | 590 | Use Node's key to update Trace Signature field 591 | in trace option header. Include Node's KeyID 592 | in the extended node data. 593 | | 594 (-- Packet reaches Validator --) 595 | | 596 Get Node's key using Node's KeyID | 597 present in extended node data. | 598 Validate Trace Signature using Node's key. | 600 The main steps of method 4 are: 602 1. Each node will establish a common secret seed establishment using 603 McEliece [McEliece] with the Validator. 605 2. Each node will then use the seed to generate a symmetric key per 606 packet and use it in updating the Trace Signature field in the 607 IOAM Trace-Option header over its node data hash. The node data 608 is extended to include the KeyID of the dynamic key generated. 610 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 611 | KeyID [x] | 612 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 613 | | 614 | node data list [x] | 615 | | 616 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 618 3. The Validator will validate the Trace Signature by deducing the 619 key for each node using the KeyID. 621 The detailed mechanisms how keys and seeds are exchanged between 622 nodes are outside the scope of this document. 624 4.4.1. Overhead consideration for Method 4 626 Like with method 3, the Trace Signature is only carried once for the 627 entire packet and could be 32 bytes total. In addition, the KeyID 628 needs to be added on a per hop basis. For sizing the Key ID, similar 629 considerations like those for proof-of-transit packet random numbers 630 apply - i.e. it depends on the packet rates of quickly keys are 631 consumed. E.g. assuming a packet rate of 100Gbps and a KeyID space 632 of 64 bits / 8 bytes, the system would need to be re-keyed after 3100 633 years (see also [I-D.ietf-sfc-proof-of-transit]). If frequent re- 634 keying is feasible, 32 bits for KeyID might well be feasible. 636 4.5. Method 5: Leverage IP Authentication Header 638 The IP Authentication Header (AH) is used to provide connectionless 639 integrity and data origin authentication for IP datagrams and to 640 provide protection against replays as defined in RFC4302 [RFC4302]. 641 The AH provides authentication for as much of the IP header as 642 possible, by classifying and including the immutable fields in the 643 integrity calculation. To protect the IOAM data in the IP header, 644 the AH may be employed in transport mode by setting up an IP AH 645 Security Association (SA) with supported integrity algorithms between 646 IOAM encapsulating nodes, IOAM decapsulating nodes and IOAM transit 647 nodes. Method 5 utilizes the IP AH for integrity protection of IOAM 648 options that are immutable enroute between IOAM entities that are 649 required to validate the integrity of the IOAM data. It is 650 applicable to IOAM Option-Types as follows: 652 1. IOAM Edge-to-Edge Option-Type: The data for this IOAM Option-Type 653 is immutable enroute and can be integrity checked using an IP AH 654 between IOAM-encapsulating nodes and IOAM-decapsulating nodes. 656 2. The Direct Exporting (DEX) IOAM Option-Type 657 ([I-D.ietf-ippm-ioam-direct-export]): The data for this IOAM 658 Option-Type is immutable enroute and can be integrity checked 659 using an IP AH between IOAM-encapsulating nodes and IOAM- 660 decapsulating nodes. IOAM-transit nodes, that use the IOAM DEX 661 Option-Type as a trigger to export IOAM data fields, and which 662 are to validate the IOAM DEX Option-Type data fields may have to 663 be configured with shared secrets, in case the AH negotiated 664 integrity algorithm relies on shared secrets. These shared 665 secrets correspond to those secrets that result from the IP AH 666 integrity algorithm negotiated during SA setup. 668 3. IOAM Proof of Transit Option-Type: This IOAM Option-Type is 669 mutable by IOAM-transit nodes enroute that participate in proof 670 of transit operation. Hence the IP AH based integrity protection 671 method does not apply. 673 4. IOAM Pre-allocated and Incremental Trace Option-Types: These IOAM 674 Option-Types are mutable by IOAM-transit nodes encroute that 675 process IOAM tracing Option-Types. Hence the IP AH based 676 integrity protection method does not apply. 678 4.5.1. Overhead consideration for Method 5 680 This method involves overhead of setting up and maintaining SA for 681 the AH IOAM-encapsulating nodes and IOAM-decapsulating nodes. The 682 anti-replay mechanism supported by IP AH must be enabled for this 683 method to effectively protect IOAM data fields whose integrity and 684 freshness needs to be guarenteed. The anti-replay mechanism of IP AH 685 has the overhead of maintaining and validating sequence numbers as 686 part of the IP AH validation. In cases where IOAM-transit nodes have 687 to validate IOAM Option-Types e.g. the DEX Option-Type, then there 688 will be additional overhead to distribute shared secrets to the 689 transit nodes when the integrity algorithm is based on shared 690 secrets. 692 5. IANA Considerations 694 This document is to support the IPPM working group to design and 695 specify a solution for protecting the integrity of IOAM data fields. 696 It does not include any requests to IANA. 698 6. Security Considerations 700 This section will be completed in a future revision of this document. 702 7. Acknowledgements 704 The authors would like to thank Santhosh N, Rakesh Kandula, Saiprasad 705 Muchala, Greg Mirsky, Benjamin Kaduk and Martin Duke for their 706 comments and advice. 708 8. References 710 8.1. Normative References 712 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 713 Requirement Levels", BCP 14, RFC 2119, 714 DOI 10.17487/RFC2119, March 1997, 715 . 717 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 718 Writing an IANA Considerations Section in RFCs", BCP 26, 719 RFC 8126, DOI 10.17487/RFC8126, June 2017, 720 . 722 8.2. Informative References 724 [BLS] "BLS (Boneh-Lynn-Shacham) digital signature", 2021, 725 . 727 [EdDSA25519] 728 "Edwards-curve Digital Signature Algorithm (EdDSA)", 2021, 729 . 731 [I-D.brockners-ippm-ioam-geneve] 732 Brockners, F., Bhandari, S., Govindan, V., Pignataro, C., 733 Nainar, N., Gredler, H., Leddy, J., Youell, S., Mizrahi, 734 T., Lapukhov, P., Gafni, B., Kfir, A., and M. Spiegel, 735 "Geneve encapsulation for In-situ OAM Data", draft- 736 brockners-ippm-ioam-geneve-05 (work in progress), November 737 2020. 739 [I-D.ietf-detnet-security] 740 Grossman, E., Mizrahi, T., and A. Hacker, "Deterministic 741 Networking (DetNet) Security Considerations", draft-ietf- 742 detnet-security-13 (work in progress), December 2020. 744 [I-D.ietf-ippm-ioam-data] 745 Brockners, F., Bhandari, S., and T. Mizrahi, "Data Fields 746 for In-situ OAM", draft-ietf-ippm-ioam-data-11 (work in 747 progress), November 2020. 749 [I-D.ietf-ippm-ioam-direct-export] 750 Song, H., Gafni, B., Zhou, T., Li, Z., Brockners, F., 751 Bhandari, S., Sivakolundu, R., and T. Mizrahi, "In-situ 752 OAM Direct Exporting", draft-ietf-ippm-ioam-direct- 753 export-02 (work in progress), November 2020. 755 [I-D.ietf-ippm-ioam-ipv6-options] 756 Bhandari, S., Brockners, F., Pignataro, C., Gredler, H., 757 Leddy, J., Youell, S., Mizrahi, T., Kfir, A., Gafni, B., 758 Lapukhov, P., Spiegel, M., Krishnan, S., Asati, R., and M. 759 Smith, "In-situ OAM IPv6 Options", draft-ietf-ippm-ioam- 760 ipv6-options-04 (work in progress), November 2020. 762 [I-D.ietf-nvo3-geneve] 763 Gross, J., Ganga, I., and T. Sridhar, "Geneve: Generic 764 Network Virtualization Encapsulation", draft-ietf- 765 nvo3-geneve-16 (work in progress), March 2020. 767 [I-D.ietf-sfc-ioam-nsh] 768 Brockners, F. and S. Bhandari, "Network Service Header 769 (NSH) Encapsulation for In-situ OAM (IOAM) Data", draft- 770 ietf-sfc-ioam-nsh-05 (work in progress), December 2020. 772 [I-D.ietf-sfc-proof-of-transit] 773 Brockners, F., Bhandari, S., Mizrahi, T., Dara, S., and S. 774 Youell, "Proof of Transit", draft-ietf-sfc-proof-of- 775 transit-08 (work in progress), November 2020. 777 [McEliece] 778 McEliece, R., "A Public-Key Cryptosystem Based on 779 Algebraic Coding Theory", 1978, 780 . 783 [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, 784 DOI 10.17487/RFC4302, December 2005, 785 . 787 [RFC7276] Mizrahi, T., Sprecher, N., Bellagamba, E., and Y. 788 Weingarten, "An Overview of Operations, Administration, 789 and Maintenance (OAM) Tools", RFC 7276, 790 DOI 10.17487/RFC7276, June 2014, 791 . 793 [RFC7384] Mizrahi, T., "Security Requirements of Time Protocols in 794 Packet Switched Networks", RFC 7384, DOI 10.17487/RFC7384, 795 October 2014, . 797 [RFC7799] Morton, A., "Active and Passive Metrics and Methods (with 798 Hybrid Types In-Between)", RFC 7799, DOI 10.17487/RFC7799, 799 May 2016, . 801 [RFC8300] Quinn, P., Ed., Elzur, U., Ed., and C. Pignataro, Ed., 802 "Network Service Header (NSH)", RFC 8300, 803 DOI 10.17487/RFC8300, January 2018, 804 . 806 Authors' Addresses 808 Frank Brockners 809 Cisco Systems, Inc. 810 Hansaallee 249, 3rd Floor 811 DUESSELDORF, NORDRHEIN-WESTFALEN 40549 812 Germany 814 Email: fbrockne@cisco.com 816 Shwetha Bhandari 817 Thoughtspot 818 3rd Floor, Indiqube Orion, 24th Main Rd, Garden Layout, HSR Layout 819 Bangalore, KARNATAKA 560 102 820 India 822 Email: shwetha.bhandari@thoughtspot.com 824 Tal Mizrahi 825 Huawei 826 8-2 Matam 827 Haifa 3190501 828 Israel 830 Email: tal.mizrahi.phd@gmail.com