idnits 2.17.1 draft-brockners-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 doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (January 25, 2021) is 1180 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC8126' is defined on line 647, 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 (-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 (~~), 7 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: July 29, 2021 Thoughtspot 6 T. Mizrahi 7 Huawei 8 January 25, 2021 10 Integrity of In-situ OAM Data Fields 11 draft-brockners-ippm-ioam-data-integrity-00 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 July 29, 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 . . . . . . . . . . . . . . . . 6 65 3.7. Delay . . . . . . . . . . . . . . . . . . . . . . . . . . 7 66 3.8. Threat Summary . . . . . . . . . . . . . . . . . . . . . 7 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 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 81 6. Security Considerations . . . . . . . . . . . . . . . . . . . 14 82 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 83 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 84 8.1. Normative References . . . . . . . . . . . . . . . . . . 15 85 8.2. Informative References . . . . . . . . . . . . . . . . . 15 86 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 88 1. Introduction 90 "In-situ" Operations, Administration, and Maintenance (IOAM) records 91 OAM information within the packet while the packet traverses a 92 particular network domain. The term "in-situ" refers to the fact 93 that the OAM data is added to the data packets rather than is being 94 sent within packets specifically dedicated to OAM. IOAM is to 95 complement mechanisms such as Ping, Traceroute, or other active 96 probing mechanisms. In terms of "active" or "passive" OAM, "in-situ" 97 OAM can be considered a hybrid OAM type. "In-situ" mechanisms do not 98 require extra packets to be sent. IOAM adds information to the 99 already available data packets and therefore cannot be considered 100 passive. In terms of the classification given in [RFC7799] IOAM 101 could be portrayed as Hybrid Type 1. IOAM mechanisms can be 102 leveraged where mechanisms using e.g. ICMP do not apply or do not 103 offer the desired results, such as proving that a certain traffic 104 flow takes a pre-defined path, SLA verification for the live data 105 traffic, detailed statistics on traffic distribution paths in 106 networks that distribute traffic across multiple paths, or scenarios 107 in which probe traffic is potentially handled differently from 108 regular data traffic by the network devices. 110 The current [I-D.ietf-ippm-ioam-data] assumes that IOAM is deployed 111 in specific network domains, where an operator has means to select, 112 monitor, and control the access to all the networking devices, making 113 the domain a trusted network. As such, IOAM tracing data is carried 114 in the packets in clear and there are no protections against any node 115 or middlebox tampering with the data. As a consequence, IOAM tracing 116 data collected in an untrusted or semi-trusted environments cannot be 117 trusted for critical operational decisions. Any rogue or 118 unauthorized change to IOAM data fields in a user packet cannot be 119 detected. 121 Recent discussions following the IETF last call on 122 [I-D.ietf-ippm-ioam-data] revealed that there might be uses of IOAM 123 where integrity protection of IOAM data fields is at least desirable, 124 knowing that IOAM data fields integrity protection would incur extra 125 effort in the data path of a device processing IOAM data fields. As 126 such, the following additional considerations and requirements are to 127 be taken into account in addition to addressing the problem of 128 detectability of any integrity breach of the IOAM trace data 129 collected: 131 1. IOAM trace data is processed by the data plane, hence viability 132 of any method to prove integrity of the IOAM trace data must be 133 feasible at data plane processing/forwarding rates (IOAM data 134 might be applied to all traffic a router forwards). 136 2. IOAM trace data is carried within data packets. Additional space 137 required to prove integrity of the data needs to be optimal, i.e. 138 should not exceed the MTU or have adverse affect on packet 139 processing. 141 3. Replay protection of older IOAM trace data should be possible. 142 Without replay protection a rogue node can present the old IOAM 143 trace data masking any ongoing network issues/activity making the 144 IOAM trace data collection useless. 146 This document is to assist the IPPM working group in designing and 147 specifying a solution for those deployments where the integrity of 148 IOAM data fields is a concern. This document proposes several 149 methods to achieve integrity protection for IOAM data fields. 151 2. Conventions 153 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 154 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 155 document are to be interpreted as described in [RFC2119]. 157 Abbreviations used in this document: 159 Geneve: Generic Network Virtualization Encapsulation 160 [I-D.ietf-nvo3-geneve] 162 GRE Generic Routing Encapsulation 164 IOAM: In-situ Operations, Administration, and Maintenance 166 MTU: Maximum Transmit Unit 168 NSH: Network Service Header [RFC8300] 170 OAM: Operations, Administration, and Maintenance 172 POT: Proof of Transit 174 SFC: Service Function Chain 176 3. Threat Analysis 178 This section presents a threat analysis of integrity-related threats 179 in the context of IOAM. The threats that are discussed are assumed 180 to be independent of the lower layer protocols; it is assumed that 181 threats at other layers are handled by security mechanisms that are 182 deployed at these layers. 184 This document is focused on integrity protection for IOAM data 185 fields. Thus the threat analysis includes threats that are related 186 to or result from compromising the integrity of IOAM data fields. 187 Other security aspects such as confidentiality are not within the 188 scope of this document. 190 Throughout the analysis there is a distinction between on-path and 191 off-path attackers. As discussed in [I-D.ietf-detnet-security], on- 192 path attackers are located in a position that allows interception and 193 modification of in-flight protocol packets, whereas off-path 194 attackers can only attack by generating protocol packets. 196 The analysis also includes the impact of each of the threats. 197 Generally speaking, the impact of a successful attack on an OAM 198 protocol [RFC7276] is a false illusion of nonexistent failures or 199 preventing the detection of actual ones; in both cases, the attack 200 may result in denial of service (DoS). Furthermore, creating the 201 false illusion of a nonexistent issue may trigger unnecessary 202 processing in some of the IOAM nodes along the path, and may cause 203 more IOAM-related data to be exported to the management plane than is 204 conventionally necessary. Beyond these general impacts, threat- 205 specific impacts are discussed in each of the subsections below. 207 3.1. Modification: IOAM Data Fields 209 Threat 211 An attacker can maliciously modify the IOAM data fields of in- 212 transit packets. The modification can either be applied to all 213 packets or selectively applied to a subset of the en route 214 packets. This threat is applicable to on-path attackers. 216 Impact 218 By systematically modifying the IOAM data fields of some or all of 219 the in-transit packets an attacker can create a false picture of 220 the paths in the network, the existence of faulty nodes and their 221 location, and the network performance. 223 3.2. Modification: IOAM Option-Type Headers 225 Threat 227 An on-path attacker can modify IOAM data fields in one or more of 228 the IOAM Option-Type headers in order to change or disrupt the 229 behavior of nodes processing IOAM data fields along the path. 231 Impact 233 Changing the header of IOAM Option-Types may have several 234 implications. An attacker can maliciously increase the processing 235 overhead in nodes that process IOAM data fields and increase the 236 on-the-wire overhead of IOAM data fields, for example by modifying 237 the IOAM-Trace-Type field in the IOAM Trace-option header. An 238 attacker can also prevent some of the nodes that process IOAM data 239 fields from incorporating IOAM data fields by modifying the 240 RemainingLen field. 242 3.3. Injection: IOAM Data Fields 244 Threat 246 An attacker can inject packets with IOAM Option-Types and IOAM 247 data fields. This threat is applicable to both on-path and off- 248 path attackers. 250 Impact 252 This attack and it impacts are similar to Section 3.1. 254 3.4. Injection: IOAM Option-Type Headers 256 Threat 258 An attacker can inject packets with IOAM Option-Type headers, thus 259 manipulating other nodes that process IOAM data fields in the 260 network. This threat is applicable to both on-path and off-path 261 attackers. 263 Impact 265 This attack and it impacts are similar to Section 3.2. 267 3.5. Replay 269 Threat 271 An attacker can replay packets with IOAM data fields. 272 Specifically, an attacker may replay a previously transmitted IOAM 273 Option-Type with a new data packet, thus attaching old IOAM data 274 fields to a fresh user packet. This threat is applicable to both 275 on-path and off-path attackers. 277 Impact 279 As with previous threats, this threat may create a false image of 280 a nonexistent failure, or may overload nodes which process IOAM 281 data fields with unnecessary processing. 283 3.6. Management and Exporting 285 Threat 287 Attacks that compromise the integrity of IOAM data fields can be 288 applied at the management plane, e.g., by manipulating network 289 management packets. Furthermore, the integrity of IOAM data 290 fields that are exported to a receiving entity can also be 291 compromised. Management plane attacks are not within the scope of 292 this document; the network management protocol is expected to 293 include inherent security capabilities. The integrity of exported 294 data is also not within the scope of this document. It is 295 expected that the specification of the export format will discuss 296 the relevant security aspects. 298 Impact 300 Malicious manipulation of the management protocol can cause nodes 301 that process IOAM data fields to malfunction, to be overloaded, or 302 to incorporate unnecessary IOAM data fields into user packets. 303 The impact of compromising the integrity of exported IOAM data 304 fields is similar to the impacts of previous threats that were 305 described in this section. 307 3.7. Delay 309 Threat 311 An on-path attacker may delay some or all of the in-transit 312 packets that include IOAM data fields in order to create the false 313 illusion of congestion. Delay attacks are well known in the 314 context of deterministic networks [I-D.ietf-detnet-security] and 315 synchronization [RFC7384], and may be somewhat mitigated in these 316 environments by using redundant paths in a way that is resilient 317 to an attack along one of the paths. This approach does not 318 address the threat in the context of IOAM, as it does not meet the 319 requirement to measure a specific path or to detect a problem 320 along the path. It is noted that this threat is not within the 321 scope of the threats that are mitigated in the scope of this 322 document. 324 Impact 326 Since IOAM can be applied to a fraction of the traffic, an 327 attacker can detect and delay only the packets that include IOAM 328 data fields, thus preventing the authenticity of delay and load 329 measurements. 331 3.8. Threat Summary 332 +-------------------------------------------+--------+------------+ 333 | Threat |In scope|Out of scope| 334 +-------------------------------------------+--------+------------+ 335 |Modification: IOAM Data Fields | + | | 336 +-------------------------------------------+--------+------------+ 337 |Modification: IOAM Option-Type Headers | + | | 338 +-------------------------------------------+--------+------------+ 339 |Injection: IOAM Data Fields | + | | 340 +-------------------------------------------+--------+------------+ 341 |Injection: IOAM Option-Type Headers | + | | 342 +-------------------------------------------+--------+------------+ 343 |Replay | + | | 344 +-------------------------------------------+--------+------------+ 345 |Management and Exporting | | + | 346 +-------------------------------------------+--------+------------+ 347 |Delay | | + | 348 +-------------------------------------------+--------+------------+ 350 Figure 1: Threat Analysis Summary 352 4. Methods of providing integrity to IOAM data fields 354 This section outlines four different methods that are to provide 355 integrity protection of IOAM data fields. As noted earlier, this 356 document is to support the IPPM working group in designing and 357 specifying a method for protecting the integrity of IOAM data fields. 358 It isn't expected that all four methods would be chosen for a 359 solution specification. 361 The discussion of the different methods focuses on protecting the 362 integrity of IOAM trace data fields, though the outlined methods are 363 not limited to protecting IOAM trace data fields only. The methods 364 could be applied to other IOAM Option-Types, such as the E2E Option- 365 Type. 367 IOAM trace data can be embedded in a variety of protocols. There are 368 specific drafts that cover the encapsulation of IOAM data into 369 different protocols, like IPv6 [I-D.ietf-ippm-ioam-ipv6-options], NSH 370 [I-D.ietf-sfc-ioam-nsh], Geneve [I-D.brockners-ippm-ioam-geneve], 371 etc. 373 The IOAM Option-Types for tracing (Pre-allocated Trace-Option and 374 Incremental Trace-Option) organize the collected data in an array, 375 the "node data list". See [I-D.ietf-ippm-ioam-data] for further 376 details). 378 The basic idea is to introduce a new "signed node-data hash field" 379 added by each node along with the node data to prove the integrity of 380 the node data inserted. 382 The following sections describe different methods of how such a 383 "signed node-data field" could be used and populated. The methods 384 assume an IOAM-Domain containing IOAM-encapsulating nodes, IOAM- 385 decapsulating nodes and IOAM-transit nodes. In addition, it is 386 assumed that traffic also traverses a Validator node, which verifies 387 the integrity of the IOAM data fields. In a typical deployment, the 388 IOAM-decapsulating node would also serve as the Validator. The setup 389 also includes a network management entity/controller which handles 390 key distributions to the network nodes and also serves as a receiver 391 for validation results provided by the Validator. Protocols and 392 procedures for the exchange of keys and validation results between 393 the network management entity/controller and the nodes are outside 394 the scope of this document. 396 4.1. Method 1: Using asymmetric keys for signing node trace data 398 Method 1 uses asymmetric keys for signing node trace data. This is 399 the procedure to be followed by each node: 401 1. Each IOAM capable node creates a key pair and shares the public 402 key with the controller, the Validator and the network management 403 system responsible for using the IOAM trace information in the 404 network domain. The detailed mechanisms how keys are exchanged 405 between nodes are outside the scope of this document. For 406 optimal performance, use of algorithms like BLS [BLS] or ED25519 407 [EdDSA25519] are suggested, resulting in fast signing for small 408 keys and limited overhead (see below for an overhead 409 calculation). 411 2. Each node data list [x] field is extended with an additional 412 "signed node-data" field: node_data_sign[x]. Node_data_sign 413 includes a signature using the private key of the node over the 414 hash of node data list[x] of the node and the previous node's 415 node data sign node_data_sign[x-1]. This couples the signature 416 of the current field to the earlier field and creates a chain of 417 trust. This way of chaining the node data signatures provides 418 protection against replay of a previous node trace of a specific 419 node. 421 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 422 | node_data_sign [x] | 423 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 424 | | 425 | node data list [x] | 426 | | 427 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 429 3. The IOAM encapsulating node (the node that inserts IOAM data 430 fields into the packet) will add a seed in its node data list 431 that is used in its node_data_sign. So the first IOAM node 432 inserting the IOAM trace data will add node_data_sign over a 433 "seed" || [hash of node data of first node]. The seed can be 434 included as a field in first node data or the seed can be the 435 trailer of the IOAM Trace-Option. 437 4. The validating node - will use the public key of each node to 438 validate the signed node data elements in the same way the node 439 Trace signatures were created, i.e. it'll repeat the individual 440 operations of the IOAM nodes traversed and will compare the 441 result to the last node's node_data-sign value. If the two 442 values match, the IOAM data was not tampered with. 444 4.1.1. Overhead consideration for Method 1 446 Assuming e.g Ed25519, the public keys would have a size of 256 bits / 447 32 bytes, and as such signatures would be 512 bits / 64 bytes wide. 448 node_data_sign[x] would consume 64 bytes per hop. Note that 449 depending on the deployment, weaker keys might well apply, given that 450 the provided integrity check is an online method, i.e. packets are 451 verified as they arrive. This allows an attacker only a short time- 452 window. 454 4.2. Method 2: Using symmetric keys for signing node trace data 456 The same procedure as Method 1 can be followed by using a MAC 457 (Message Authentication Code) algorithm for node signature. This 458 involves distributing a secret key to the individual IOAM nodes and 459 the Validator. Steps 1 to 4 of Method 1 apply in a similar way, the 460 only difference is that symmetric keys are used. As such, each node 461 data list [x] field is extended with an additional "signed node-data" 462 field: node_data_sign[x]. The size of the node_data_sign[x] field 463 depends on the cryptographic message authentication code used. 465 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 466 | node_data_sign [x] | 467 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 468 | | 469 | node data list [x] | 470 | | 471 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 473 4.2.1. Overhead consideration for Method 2 475 Different types of cryptographic message authentication codes could 476 be chosen, such as HMAC-SHA256 or Poly1305-AES. 478 HMAC-SHA256 would take a secret key of any size and provide a 32 byte 479 authenticator. Consequently, node_data_sign[x] would consume 32 480 bytes per hop. 482 Poly1305-AES would use a 32 bytes secret key and provide a 16 byte 483 authenticator. Consequently, node_data_sign[x] would consume 16 484 bytes per hop. 486 4.3. Method 3: Space optimized symmetric key based signing of trace 487 data 489 Methods 1 and 2 add a node_data_sign field at every IOAM node the 490 packet traverses. While feasible for network domains with only a few 491 IOAM enabled hops, the number of bytes consumed in case of larger 492 networks might not be acceptable. For those deployments, an approach 493 with a single fixed sized signature field could apply. 495 Method 3 enhances the IOAM Trace-Option header to carry a "Trace 496 Signature" field. 498 0 1 2 3 499 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 500 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 501 | Namespace-ID |NodeLen | Flags | RemainingLen| 502 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 503 | IOAM-Trace-Type | Reserved | 504 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 505 | Trace Signature ~ 506 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 507 Method 3 assumes that symmetric keys have been distributed to the 508 respective nodes as well as the Validator (the Validator receives all 509 the keys). The details of the mechanisms of how keys are distributed 510 are outside the scope of this document. The "Trace Signature" field 511 is populated as follows: 513 1. The first node creates a seed and sign/HMAC over the hash of its 514 node_data_list[x], the seed and its symmetric key. The seed can 515 be included as a field in first node data or the seed can be the 516 trailer to the trace option. The resulting HMAC/signature is 517 included in the Trace Signature field. 519 2. Subsequent nodes will update the Trace Signature field by 520 creating a signature/HMAC of data where the data is [Trace 521 Signature || its node_data_list[x] hash] with its symmetric key. 523 3. The Validator will iteratively recreate the Trace Signature over 524 the node data trace fields collected and matches the Trace 525 Signature field to validate the trace data integrity. 527 4.3.1. Overhead consideration for Method 3 529 Much like method 2, the Trace Signature would consume 16 or 32 bytes 530 - though with method 3, the Trace Signature is only carried once for 531 the entire packet. 533 4.4. Method 4: Dynamic symmetric keys based signing of trace data 535 This method builds on top of Method 3 leverages Post-quantum Secure 536 Pre-shared key distribution for deriving a dynamic symmetric key for 537 every packet or a set of packets. The method utilizes the dynamic 538 keys to provide for replay protection and does not require a seed to 539 be added to the trace data to protect from replays because a private 540 key is derived for each packet. The method relies on a local service 541 that generates common Key/KeyID pairs for the participating Node and 542 Validator (see the figure below). This common key generator uses 543 ratcheting cryptography to generate the next secret while forgetting 544 about the previous one. A unique ID is paired with each secret 545 generated. Given the same seed secret as input parameter, two 546 implementations of the common key generator will generate the exact 547 same key and associated ID. The common key generator can be queried 548 for the next key or for a specific key ID. 550 The figure below illustrates the concept: 552 Validator Node 553 | | 554 | | 555 Generate McEliece | 556 public/private key-pair | 557 | | 558 |<---Establ. classic secure connection---------| 559 | (e.g. TLS) | 560 |---Send public key over secure connection---->| 561 | | 562 | Generate random secret seed 563 | and encrypt w/ Validator 564 | public key 565 | | 566 |<--Send encrypted seed over secure connection-| 567 | | 568 Decrypt secret seed sent from Node | 569 using Validator's private key | 570 | | 571 (-- Common secret seed established between --) 572 (-- Node and Validator --) 573 | | 574 | Generate Node's KeyID pair 575 | based on common secret seed 576 | | 577 | Use Node's key to update Trace Signature field 578 | in trace option header. Include Node's KeyID 579 | in the extended node data. 580 | | 581 (-- Packet reaches Validator --) 582 | | 583 Get Node's key using Node's KeyID | 584 present in extended node data. | 585 Validate Trace Signature using Node's key. | 587 The main steps of method 4 are: 589 1. Each node will establish a common secret seed establishment using 590 McEliece [McEliece] with the Validator. 592 2. Each node will then use the seed to generate a symmetric key per 593 packet and use it in updating the Trace Signature field in the 594 IOAM Trace-Option header over its node data hash. The node data 595 is extended to include the KeyID of the dynamic key generated. 597 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 598 | KeyID [x] | 599 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 600 | | 601 | node data list [x] | 602 | | 603 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 605 3. The Validator will validate the Trace Signature by deducing the 606 key for each node using the KeyID. 608 The detailed mechanisms how keys and seeds are exchanged between 609 nodes are outside the scope of this document. 611 4.4.1. Overhead consideration for Method 4 613 Like with method 3, the Trace Signature is only carried once for the 614 entire packet and could be 32 bytes total. In addition, the KeyID 615 needs to be added on a per hop basis. For sizing the Key ID, similar 616 considerations like those for proof-of-transit packet random numbers 617 apply - i.e. it depends on the packet rates of quickly keys are 618 consumed. E.g. assuming a packet rate of 100Gbps and a KeyID space 619 of 64 bits / 8 bytes, the system would need to be re-keyed after 3100 620 years (see also [I-D.ietf-sfc-proof-of-transit]). If frequent re- 621 keying is feasible, 32 bits for KeyID might well be feasible. 623 5. IANA Considerations 625 This document is to support the IPPM working group to design and 626 specify a solution for protecting the integrity of IOAM data fields. 627 It does not include any requests to IANA. 629 6. Security Considerations 631 This section will be completed in a future revision of this document. 633 7. Acknowledgements 635 The authors would like to thank Santhosh N, Rakesh Kandula, Saiprasad 636 Muchala, Greg Mirsky, Benjamin Kaduk and Martin Duke for their 637 comments and advice. 639 8. References 640 8.1. Normative References 642 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 643 Requirement Levels", BCP 14, RFC 2119, 644 DOI 10.17487/RFC2119, March 1997, 645 . 647 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 648 Writing an IANA Considerations Section in RFCs", BCP 26, 649 RFC 8126, DOI 10.17487/RFC8126, June 2017, 650 . 652 8.2. Informative References 654 [BLS] "BLS (Boneh-Lynn-Shacham) digital signature", 2021, 655 . 657 [EdDSA25519] 658 "Edwards-curve Digital Signature Algorithm (EdDSA)", 2021, 659 . 661 [I-D.brockners-ippm-ioam-geneve] 662 Brockners, F., Bhandari, S., Govindan, V., Pignataro, C., 663 Nainar, N., Gredler, H., Leddy, J., Youell, S., Mizrahi, 664 T., Lapukhov, P., Gafni, B., Kfir, A., and M. Spiegel, 665 "Geneve encapsulation for In-situ OAM Data", draft- 666 brockners-ippm-ioam-geneve-05 (work in progress), November 667 2020. 669 [I-D.ietf-detnet-security] 670 Grossman, E., Mizrahi, T., and A. Hacker, "Deterministic 671 Networking (DetNet) Security Considerations", draft-ietf- 672 detnet-security-13 (work in progress), December 2020. 674 [I-D.ietf-ippm-ioam-data] 675 Brockners, F., Bhandari, S., and T. Mizrahi, "Data Fields 676 for In-situ OAM", draft-ietf-ippm-ioam-data-11 (work in 677 progress), November 2020. 679 [I-D.ietf-ippm-ioam-ipv6-options] 680 Bhandari, S., Brockners, F., Pignataro, C., Gredler, H., 681 Leddy, J., Youell, S., Mizrahi, T., Kfir, A., Gafni, B., 682 Lapukhov, P., Spiegel, M., Krishnan, S., Asati, R., and M. 683 Smith, "In-situ OAM IPv6 Options", draft-ietf-ippm-ioam- 684 ipv6-options-04 (work in progress), November 2020. 686 [I-D.ietf-nvo3-geneve] 687 Gross, J., Ganga, I., and T. Sridhar, "Geneve: Generic 688 Network Virtualization Encapsulation", draft-ietf- 689 nvo3-geneve-16 (work in progress), March 2020. 691 [I-D.ietf-sfc-ioam-nsh] 692 Brockners, F. and S. Bhandari, "Network Service Header 693 (NSH) Encapsulation for In-situ OAM (IOAM) Data", draft- 694 ietf-sfc-ioam-nsh-05 (work in progress), December 2020. 696 [I-D.ietf-sfc-proof-of-transit] 697 Brockners, F., Bhandari, S., Mizrahi, T., Dara, S., and S. 698 Youell, "Proof of Transit", draft-ietf-sfc-proof-of- 699 transit-08 (work in progress), November 2020. 701 [McEliece] 702 McEliece, R., "A Public-Key Cryptosystem Based on 703 Algebraic Coding Theory", 1978, 704 . 707 [RFC7276] Mizrahi, T., Sprecher, N., Bellagamba, E., and Y. 708 Weingarten, "An Overview of Operations, Administration, 709 and Maintenance (OAM) Tools", RFC 7276, 710 DOI 10.17487/RFC7276, June 2014, 711 . 713 [RFC7384] Mizrahi, T., "Security Requirements of Time Protocols in 714 Packet Switched Networks", RFC 7384, DOI 10.17487/RFC7384, 715 October 2014, . 717 [RFC7799] Morton, A., "Active and Passive Metrics and Methods (with 718 Hybrid Types In-Between)", RFC 7799, DOI 10.17487/RFC7799, 719 May 2016, . 721 [RFC8300] Quinn, P., Ed., Elzur, U., Ed., and C. Pignataro, Ed., 722 "Network Service Header (NSH)", RFC 8300, 723 DOI 10.17487/RFC8300, January 2018, 724 . 726 Authors' Addresses 727 Frank Brockners 728 Cisco Systems, Inc. 729 Hansaallee 249, 3rd Floor 730 DUESSELDORF, NORDRHEIN-WESTFALEN 40549 731 Germany 733 Email: fbrockne@cisco.com 735 Shwetha Bhandari 736 Thoughtspot 737 3rd Floor, Indiqube Orion, 24th Main Rd, Garden Layout, HSR Layout 738 Bangalore, KARNATAKA 560 102 739 India 741 Email: shwetha.bhandari@thoughtspot.com 743 Tal Mizrahi 744 Huawei 745 8-2 Matam 746 Haifa 3190501 747 Israel 749 Email: tal.mizrahi.phd@gmail.com