idnits 2.17.1 draft-ietf-sfc-proof-of-transit-04.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 == Line 770 has weird spacing: '...e-index pro...' == Line 773 has weird spacing: '...ynomial uin...' == The document seems to use 'NOT RECOMMENDED' as an RFC 2119 keyword, but does not include the phrase in its RFC 2119 key words list. -- The document date (November 21, 2019) is 1617 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Outdated reference: A later version (-17) exists of draft-ietf-ippm-ioam-data-08 == Outdated reference: A later version (-30) exists of draft-ietf-anima-autonomic-control-plane-18 Summary: 0 errors (**), 0 flaws (~~), 6 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group F. Brockners, Ed. 3 Internet-Draft S. Bhandari, Ed. 4 Intended status: Experimental Cisco 5 Expires: May 24, 2020 T. Mizrahi, Ed. 6 Huawei Network.IO Innovation Lab 7 S. Dara 8 Seconize 9 S. Youell 10 JPMC 11 November 21, 2019 13 Proof of Transit 14 draft-ietf-sfc-proof-of-transit-04 16 Abstract 18 Several technologies such as Traffic Engineering (TE), Service 19 Function Chaining (SFC), and policy based routing are used to steer 20 traffic through a specific, user-defined path. This document defines 21 mechanisms to securely prove that traffic transited said defined 22 path. These mechanisms allow to securely verify whether, within a 23 given path, all packets traversed all the nodes that they are 24 supposed to visit. 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at https://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on May 24, 2020. 43 Copyright Notice 45 Copyright (c) 2019 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (https://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 61 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 4 62 3. Proof of Transit . . . . . . . . . . . . . . . . . . . . . . 5 63 3.1. Basic Idea . . . . . . . . . . . . . . . . . . . . . . . 5 64 3.2. Solution Approach . . . . . . . . . . . . . . . . . . . . 6 65 3.2.1. Setup . . . . . . . . . . . . . . . . . . . . . . . . 7 66 3.2.2. In Transit . . . . . . . . . . . . . . . . . . . . . 7 67 3.2.3. Verification . . . . . . . . . . . . . . . . . . . . 8 68 3.3. Illustrative Example . . . . . . . . . . . . . . . . . . 8 69 3.3.1. Baseline . . . . . . . . . . . . . . . . . . . . . . 8 70 3.3.1.1. Secret Shares . . . . . . . . . . . . . . . . . . 8 71 3.3.1.2. Lagrange Polynomials . . . . . . . . . . . . . . 9 72 3.3.1.3. LPC Computation . . . . . . . . . . . . . . . . . 9 73 3.3.1.4. Reconstruction . . . . . . . . . . . . . . . . . 9 74 3.3.1.5. Verification . . . . . . . . . . . . . . . . . . 10 75 3.3.2. Complete Solution . . . . . . . . . . . . . . . . . . 10 76 3.3.2.1. Random Polynomial . . . . . . . . . . . . . . . . 10 77 3.3.2.2. Reconstruction . . . . . . . . . . . . . . . . . 10 78 3.3.2.3. Verification . . . . . . . . . . . . . . . . . . 11 79 3.3.3. Solution Deployment Considerations . . . . . . . . . 11 80 3.4. Operational Aspects . . . . . . . . . . . . . . . . . . . 12 81 3.5. Ordered POT (OPOT) . . . . . . . . . . . . . . . . . . . 12 82 4. Sizing the Data for Proof of Transit . . . . . . . . . . . . 13 83 5. Node Configuration . . . . . . . . . . . . . . . . . . . . . 14 84 5.1. Procedure . . . . . . . . . . . . . . . . . . . . . . . . 15 85 5.2. YANG Model for POT . . . . . . . . . . . . . . . . . . . 15 86 5.2.1. Main Parameters . . . . . . . . . . . . . . . . . . . 16 87 5.2.2. Tree Diagram . . . . . . . . . . . . . . . . . . . . 16 88 5.2.3. YANG Model . . . . . . . . . . . . . . . . . . . . . 17 89 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 90 7. Security Considerations . . . . . . . . . . . . . . . . . . . 22 91 7.1. Proof of Transit . . . . . . . . . . . . . . . . . . . . 22 92 7.2. Cryptanalysis . . . . . . . . . . . . . . . . . . . . . . 23 93 7.3. Anti-Replay . . . . . . . . . . . . . . . . . . . . . . . 23 94 7.4. Anti-Preplay . . . . . . . . . . . . . . . . . . . . . . 24 95 7.5. Tampering . . . . . . . . . . . . . . . . . . . . . . . . 24 96 7.6. Recycling . . . . . . . . . . . . . . . . . . . . . . . . 25 97 7.7. Redundant Nodes and Failover . . . . . . . . . . . . . . 25 98 7.8. Controller Operation . . . . . . . . . . . . . . . . . . 25 99 7.9. Verification Scope . . . . . . . . . . . . . . . . . . . 26 100 7.9.1. Node Ordering . . . . . . . . . . . . . . . . . . . . 26 101 7.9.2. Stealth Nodes . . . . . . . . . . . . . . . . . . . . 26 102 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 26 103 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 26 104 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 27 105 10.1. Normative References . . . . . . . . . . . . . . . . . . 27 106 10.2. Informative References . . . . . . . . . . . . . . . . . 28 107 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28 109 1. Introduction 111 Several deployments use Traffic Engineering, policy routing, Segment 112 Routing (SR), and Service Function Chaining (SFC) [RFC7665] to steer 113 packets through a specific set of nodes. In certain cases, 114 regulatory obligations or a compliance policy require operators to 115 prove that all packets that are supposed to follow a specific path 116 are indeed being forwarded across and exact set of pre-determined 117 nodes. 119 If a packet flow is supposed to go through a series of service 120 functions or network nodes, it has to be proven that indeed all 121 packets of the flow followed the path or service chain or collection 122 of nodes specified by the policy. In case some packets of a flow 123 weren't appropriately processed, a verification device should 124 determine the policy violation and take corresponding actions 125 corresponding to the policy (e.g., drop or redirect the packet, send 126 an alert etc.) In today's deployments, the proof that a packet 127 traversed a particular path or service chain is typically delivered 128 in an indirect way: Service appliances and network forwarding are in 129 different trust domains. Physical hand-off-points are defined 130 between these trust domains (i.e. physical interfaces). Or in other 131 terms, in the "network forwarding domain" things are wired up in a 132 way that traffic is delivered to the ingress interface of a service 133 appliance and received back from an egress interface of a service 134 appliance. This "wiring" is verified and then trusted upon. The 135 evolution to Network Function Virtualization (NFV) and modern service 136 chaining concepts (using technologies such as Locator/ID Separation 137 Protocol (LISP), Network Service Header (NSH), Segment Routing (SR), 138 etc.) blurs the line between the different trust domains, because the 139 hand-off-points are no longer clearly defined physical interfaces, 140 but are virtual interfaces. As a consequence, different trust layers 141 should not to be mixed in the same device. For an NFV scenario a 142 different type of proof is required. Offering a proof that a packet 143 indeed traversed a specific set of service functions or nodes allows 144 operators to evolve from the above described indirect methods of 145 proving that packets visit a predetermined set of nodes. 147 The solution approach presented in this document is based on a small 148 portion of operational data added to every packet. This "in-situ" 149 operational data is also referred to as "proof of transit data", or 150 POT data. The POT data is updated at every required node and is used 151 to verify whether a packet traversed all required nodes. A 152 particular set of nodes "to be verified" is either described by a set 153 of shares of a single secret. Nodes on the path retrieve their 154 individual shares of the secret using Shamir's Secret Sharing scheme 155 from a central controller. The complete secret set is only known to 156 the controller and a verifier node, which is typically the ultimate 157 node on a path that performs verification. Each node in the path 158 uses its share of the secret to update the POT data of the packets as 159 the packets pass through the node. When the verifier receives a 160 packet, it uses its key along with data found in the packet to 161 validate whether the packet traversed the path correctly. 163 2. Conventions 165 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 166 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 167 document are to be interpreted as described in [RFC2119]. 169 Abbreviations used in this document: 171 HMAC: Hash based Message Authentication Code. For example, 172 HMAC-SHA256 generates 256 bits of MAC 174 IOAM: In-situ Operations, Administration, and Maintenance 176 LISP: Locator/ID Separation Protocol 178 LPC: Lagrange Polynomial Constants 180 MTU: Maximum Transmit Unit 182 NFV: Network Function Virtualization 184 NSH: Network Service Header 186 POT: Proof of Transit 188 POT-Profile: Proof of Transit Profile that has the necessary data 189 for nodes to participate in proof of transit 191 RND: Random Bits generated per packet. Packet fields that do 192 not change during the traversal are given as input to 193 HMAC-256 algorithm. A minimum of 32 bits (left most) need 194 to be used from the output if RND is used to verify the 195 packet integrity. This is a standard recommendation by 196 NIST. 198 SEQ_NO: Sequence number initialized to a predefined constant. 199 This is used in concatenation with RND bits to mitigate 200 different attacks discussed later. 202 SFC: Service Function Chain 204 SSSS: Shamir's Secret Sharing Scheme 206 SR: Segment Routing 208 3. Proof of Transit 210 This section discusses methods and algorithms to provide for a "proof 211 of transit" for packets traversing a specific path. A path which is 212 to be verified consists of a set of nodes. Transit of the data 213 packets through those nodes is to be proven. Besides the nodes, the 214 setup also includes a Controller that creates secrets and secrets 215 shares and configures the nodes for POT operations. 217 The methods how traffic is identified and associated to a specific 218 path is outside the scope of this document. Identification could be 219 done using a filter (e.g., 5-tuple classifier), or an identifier 220 which is already present in the packet (e.g., path or service 221 identifier, NSH Service Path Identifier (SPI), flow-label, etc.) 223 The POT information is encapsulated in packets as an IOAM Proof Of 224 Transit Option. The details and format of the encapsulation and the 225 POT Option format are specified in [I-D.ietf-ippm-ioam-data]. 227 The solution approach is detailed in two steps. Initially the 228 concept of the approach is explained. This concept is then further 229 refined to make it operationally feasible. 231 3.1. Basic Idea 233 The method relies on adding POT data to all packets that traverse a 234 path. The added POT data allows a verifying node (egress node) to 235 check whether a packet traversed the identified set of nodes on a 236 path correctly or not. Security mechanisms are natively built into 237 the generation of the POT data to protect against misuse (e.g., 238 configuration mistakes). The mechanism for POT leverages "Shamir's 239 Secret Sharing" scheme [SSS]. 241 Shamir's secret sharing base idea: A polynomial (represented by its 242 coefficients) of degree k is chosen as a secret by the controller. A 243 polynomial represents a curve. A set of k+1 points on the curve 244 define the polynomial and are thus needed to (re-)construct the 245 polynomial. Each of these k+1 points of the polynomial is called a 246 "share" of the secret. A single secret is associated with a 247 particular set of k+1 nodes, which typically represent the path to be 248 verified. k+1 shares of the single secret (i.e., k+1 points on the 249 curve) are securely distributed from a Controller to the network 250 nodes. Nodes use their respective share to update a cumulative value 251 in the POT data of each packet. Only a verifying node has access to 252 the complete secret. The verifying node validates the correctness of 253 the received POT data by reconstructing the curve. 255 The polynomial cannot be reconstructed if any of the points are 256 missed or tampered. Per Shamir's Secret Sharing Scheme, any lesser 257 points means one or more nodes are missed. Details of the precise 258 configuration needed for achieving security are discussed further 259 below. 261 While applicable in theory, a vanilla approach based on Shamir's 262 Secret Sharing Scheme could be easily attacked. If the same 263 polynomial is reused for every packet for a path a passive attacker 264 could reuse the value. As a consequence, one could consider creating 265 a different polynomial per packet. Such an approach would be 266 operationally complex. It would be complex to configure and recycle 267 so many curves and their respective points for each node. Rather 268 than using a single polynomial, two polynomials are used for the 269 solution approach: A secret polynomial as described above which is 270 kept constant, and a per-packet polynomial which is public and 271 generated by the ingress node (the first node along the path). 272 Operations are performed on the sum of those two polynomials - 273 creating a third polynomial which is secret and per packet. 275 3.2. Solution Approach 277 Solution approach: The overall algorithm uses two polynomials: POLY-1 278 and POLY-2. POLY-1 is secret and constant. A different POLY-1 is 279 used for each path, and its value is known to the controller and to 280 the verifier of the respective path. Each node gets a point on 281 POLY-1 at setup-time and keeps it secret. POLY-2 is public, random 282 and per packet. Each node generates a point on POLY-2 each time a 283 packet crosses it. Each node then calculates (point on POLY-1 + 284 point on POLY-2) to get a (point on POLY-3) and passes it to verifier 285 by adding it to each packet. The verifier constructs POLY-3 from the 286 points given by all the nodes and cross checks whether POLY-3 = 287 POLY-1 + POLY-2. Only the verifier knows POLY-1. 289 The solution leverages finite field arithmetic in a field of size 290 "prime number", i.e. all operations are performed "modulo prime 291 number". 293 Detailed algorithms are discussed next. A simple example that 294 describes how the algorithms work is discussed in Section 3.3. 296 The algorithms themselves do not constrain the ranges of possible 297 values for the different parameters and coefficients used. A 298 deployment of the algorithms will always need to define appropriate 299 ranges. Please refer to the YANG model in Section 5.2 for details on 300 the units and ranges of possible values of the different parameters 301 and coefficients. 303 3.2.1. Setup 305 A controller generates a first polynomial (POLY-1) of degree k and 306 k+1 points on the polynomial, corresponding to the k+1 nodes along 307 the path. The constant coefficient of POLY-1 is considered the 308 SECRET, which is per the definition of the SSSS algorithm [SSS]. The 309 k+1 points are used to derive the Lagrange Basis Polynomials. The 310 Lagrange Polynomial Constants (LPC) are retrieved from the constant 311 coefficients of the Lagrange Basis Polynomials. Each of the k+1 312 nodes (including verifier) are assigned a point on the polynomial 313 i.e., shares of the SECRET. The verifier is configured with the 314 SECRET. The Controller also generates coefficients (except the 315 constant coefficient, called "RND", which is changed on a per packet 316 basis) of a second polynomial POLY-2 of the same degree. Each node 317 is configured with the LPC of POLY-2. Note that POLY-2 is public. 319 3.2.2. In Transit 321 For each packet, the ingress node generates a random number (RND). 322 It is considered as the constant coefficient for POLY-2. A 323 cumulative value (CML) is initialized to 0. Both RND, CML are 324 carried as within the packet POT data. As the packet visits each 325 node, the RND is retrieved from the packet and the respective share 326 of POLY-2 is calculated. Each node calculates (Share(POLY-1) + 327 Share(POLY-2)) and CML is updated with this sum, specifically each 328 node performs 330 CML = CML+(((Share(POLY-1)+ Share(POLY-2)) * LPC) mod Prime, with 331 "LPC" being the Lagrange Polynomial Constant and "Prime" being the 332 prime number which defines the finite field arithmetic that all 333 operations are done over. Please also refer to Section 3.3.2 below 334 for further details how the operations are performed. 336 This step is performed by each node until the packet completes the 337 path. The verifier also performs the step with its respective share. 339 3.2.3. Verification 341 The verifier cross checks whether CML = SECRET + RND. If this 342 matches then the packet traversed the specified set of nodes in the 343 path. This is due to the additive homomorphic property of Shamir's 344 Secret Sharing scheme. 346 3.3. Illustrative Example 348 This section shows a simple example to illustrate step by step the 349 approach described above. The example assumes a network with 3 350 nodes. The last node that packets traverse also serves as the 351 verifier. A Controller communicates the required parameters to the 352 individual nodes. 354 3.3.1. Baseline 356 Assumption: It is to be verified whether packets passed through the 3 357 nodes. A polynomial of degree 2 is chosen for verification. 359 Choices: Prime = 53. POLY-1(x) = (3x^2 + 3x + 10) mod 53. The 360 secret to be re-constructed is the constant coefficient of POLY-1, 361 i.e., SECRET=10. It is important to note that all operations are 362 done over a finite field (i.e., modulo Prime = 53). 364 3.3.1.1. Secret Shares 366 The shares of the secret are the points on POLY-1 chosen for the 3 367 nodes. For example, let x0=2, x1=4, x2=5. 369 POLY-1(2) = 28 => (x0, y0) = (2, 28) 371 POLY-1(4) = 17 => (x1, y1) = (4, 17) 373 POLY-1(5) = 47 => (x2, y2) = (5, 47) 375 The three points above are the points on the curve which are 376 considered the shares of the secret. They are assigned by the 377 Controller to three nodes respectively and are kept secret. 379 3.3.1.2. Lagrange Polynomials 381 Lagrange basis polynomials (or Lagrange polynomials) are used for 382 polynomial interpolation. For a given set of points on the curve 383 Lagrange polynomials (as defined below) are used to reconstruct the 384 curve and thus reconstruct the complete secret. 386 l0(x) = (((x-x1) / (x0-x1)) * ((x-x2)/x0-x2))) mod 53 387 = (((x-4) / (2-4)) * ((x-5)/2-5))) mod 53 388 = (10/3 - 3x/2 + (1/6)x^2) mod 53 390 l1(x) = (((x-x0) / (x1-x0)) * ((x-x2)/x1-x2))) mod 53 391 = (-5 + 7x/2 - (1/2)x^2) mod 53 393 l2(x) = (((x-x0) / (x2-x0)) * ((x-x1)/x2-x1))) mod 53 394 = (8/3 - 2 + (1/3)x^2) mod 53 396 3.3.1.3. LPC Computation 398 Since x0=2, x1=4, x2=5 are chosen points. Given that computations 399 are done over a finite arithmetic field ("modulo a prime number"), 400 the Lagrange basis polynomial constants are computed modulo 53. The 401 Lagrange Polynomial Constants (LPC) would be mod(10/3, 53), mod(-5, 402 53), mod(8/3, 53).LPC are computed by the Controller and communicated 403 to the individual nodes. 405 LPC(l0) = (10/3) mod 53 = 21 407 LPC(l1) = (-5) mod 53 = 48 409 LPC(l2) = (8/3) mod 53 = 38 411 For a general way to compute the modular multiplicative inverse, see 412 e.g., the Euclidean algorithm. 414 3.3.1.4. Reconstruction 416 Reconstruction of the polynomial is well-defined as 418 POLY1(x) = l0(x) * y0 + l1(x) * y1 + l2(x) * y2 420 Subsequently, the SECRET, which is the constant coefficient of 421 POLY1(x) can be computed as below 423 SECRET = (y0*LPC(l0)+y1*LPC(l1)+y2*LPC(l2)) mod 53 424 The secret can be easily reconstructed using the y-values and the 425 LPC: 427 SECRET = (y0*LPC(l0) + y1*LPC(l1) + y2*LPC(l2)) mod 53 428 = (28 * 21 + 17 * 48 + 47 * 38) mod 53 429 = 3190 mod 53 430 = 10 432 One observes that the secret reconstruction can easily be performed 433 cumulatively hop by hop, i.e. by every node. CML represents the 434 cumulative value. It is the POT data in the packet that is updated 435 at each hop with the node's respective (yi*LPC(i)), where i is their 436 respective value. 438 3.3.1.5. Verification 440 Upon completion of the path, the resulting CML is retrieved by the 441 verifier from the packet POT data. Recall that the verifier is 442 preconfigured with the original SECRET. It is cross checked with the 443 CML by the verifier. Subsequent actions based on the verification 444 failing or succeeding could be taken as per the configured policies. 446 3.3.2. Complete Solution 448 As observed previously, the baseline algorithm that involves a single 449 secret polynomial is not secure. The complete solution leverages a 450 random second polynomial, which is chosen per packet. 452 3.3.2.1. Random Polynomial 454 Let the second polynomial POLY-2 be (RND + 7x + 10 x^2). RND is a 455 random number and is generated for each packet. Note that POLY-2 is 456 public and need not be kept secret. The nodes can be pre-configured 457 with the non-constant coefficients (for example, 7 and 10 in this 458 case could be configured through the Controller on each node). So 459 precisely only the RND value changes per packet and is public and the 460 rest of the non-constant coefficients of POLY-2 is kept secret. 462 3.3.2.2. Reconstruction 464 Recall that each node is preconfigured with their respective 465 Share(POLY-1). Each node calculates its respective Share(POLY-2) 466 using the RND value retrieved from the packet. The CML 467 reconstruction is enhanced as below. At every node, CML is updated 468 as 470 CML = CML+(((Share(POLY-1)+ Share(POLY-2)) * LPC) mod Prime 471 Let us observe the packet level transformations in detail. For the 472 example packet here, let the value RND be 45. Thus POLY-2 would be 473 (45 + 7x + 10x^2). 475 The shares that could be generated are (2, 46), (4, 21), (5, 12). 477 At ingress: The fields RND = 45. CML = 0. 479 At node-1 (x0): Respective share of POLY-2 is generated i.e., (2, 480 46) because share index of node-1 is 2. 482 CML = 0 + ((28 + 46)* 21) mod 53 = 17 484 At node-2 (x1): Respective share of POLY-2 is generated i.e., (4, 485 21) because share index of node-2 is 4. 487 CML = 17 + ((17 + 21)*48) mod 53 = 17 + 22 = 39 489 At node-3 (x2), which is also the verifier: The respective share 490 of POLY-2 is generated i.e., (5, 12) because the share index of 491 the verifier is 12. 493 CML = 39 + ((47 + 12)*38) mod 53 = 39 + 16 = 55 mod 53 = 2 495 The verification using CML is discussed in next section. 497 3.3.2.3. Verification 499 As shown in the above example, for final verification, the verifier 500 compares: 502 VERIFY = (SECRET + RND) mod Prime, with Prime = 53 here 504 VERIFY = (RND-1 + RND-2) mod Prime = ( 10 + 45 ) mod 53 = 2 506 Since VERIFY = CML the packet is proven to have gone through nodes 1, 507 2, and 3. 509 3.3.3. Solution Deployment Considerations 511 The "complete solution" described above in Section 3.3.2 could still 512 be prone to replay or preplay attacks. An attacker could e.g. reuse 513 the POT metadata for bypassing the verification. These threats can 514 be mitigated by appropriate parameterization of the algorithm. 515 Please refer to Section 7 for details. 517 3.4. Operational Aspects 519 To operationalize this scheme, a central controller is used to 520 generate the necessary polynomials, the secret share per node, the 521 prime number, etc. and distributing the data to the nodes 522 participating in proof of transit. The identified node that performs 523 the verification is provided with the verification key. The 524 information provided from the Controller to each of the nodes 525 participating in proof of transit is referred to as a proof of 526 transit profile (POT-Profile). Also note that the set of nodes for 527 which the transit has to be proven are typically associated to a 528 different trust domain than the verifier. Note that building the 529 trust relationship between the Controller and the nodes is outside 530 the scope of this document. Techniques such as those described in 531 [I-D.ietf-anima-autonomic-control-plane] might be applied. 533 To optimize the overall data amount of exchanged and the processing 534 at the nodes the following optimizations are performed: 536 1. The points (x, y) for each of the nodes on the public and private 537 polynomials are picked such that the x component of the points 538 match. This lends to the LPC values which are used to calculate 539 the cumulative value CML to be constant. Note that the LPC are 540 only depending on the x components. They can be computed at the 541 controller and communicated to the nodes. Otherwise, one would 542 need to distributed the x components to all the nodes. 544 2. A pre-evaluated portion of the public polynomial for each of the 545 nodes is calculated and added to the POT-Profile. Without this 546 all the coefficients of the public polynomial had to be added to 547 the POT profile and each node had to evaluate them. As stated 548 before, the public portion is only the constant coefficient RND 549 value, the pre-evaluated portion for each node should be kept 550 secret as well. 552 3. To provide flexibility on the size of the cumulative and random 553 numbers carried in the POT data a field to indicate this is 554 shared and interpreted at the nodes. 556 3.5. Ordered POT (OPOT) 558 POT as discussed in this document so far only verifies that a defined 559 set of nodes have been traversed by a packet. The order in which 560 nodes where traversed is not verified. "Ordered Proof of Transit 561 (OPOT)" addresses the need of deployments, that require to verify the 562 order in which nodes were traversed. OPOT extends the POT scheme 563 with symmetric masking between the nodes. 565 1. For each path the controller provisions all the nodes with (or 566 asks them to agree on) two secrets per node, that we will refer 567 to as masks, one for the connection from the upstream node(s), 568 another for the connection to the downstream node(s). For 569 obvious reasons, the ingress and egress (verifier) nodes only 570 receive one, for downstream and upstream, respectively. 572 2. Any two contiguous nodes in the OPOT stream share the mask for 573 the connection between them, in the shape of symmetric keys. 574 Masks can be refreshed as per-policy, defined at each hop or 575 globally by the controller. 577 3. Each mask has the same size in bits as the length assigned to CML 578 plus RND, as described in the above sections. 580 4. Whenever a packet is received at an intermediate node, the 581 CML+RND sequence is deciphered (by XORing, though other ciphering 582 schemas MAY be possible) with the upstream mask before applying 583 the procedures described in Section 3.3.2. 585 5. Once the new values of CML+RND are produced, they are ciphered 586 (by XORing, though other ciphering schemas MAY be possible) with 587 the downstream mask before transmitting the packet to the next 588 node downstream. 590 6. The ingress node only applies step 5 above, while the verifier 591 only applies step 4 before running the verification procedure. 593 The described process allows the verifier to check if the packet has 594 followed the correct order while traversing the path. In particular, 595 the reconstruction process will fail if the order is not respected, 596 as the deciphering process will produce invalid CML and RND values, 597 and the interpolation (secret reconstruction) will finally generate a 598 wrong verification value. 600 This procedure does not impose a high computational burden, does not 601 require additional packet overhead, can be deployed on chains of any 602 length, does not require any node to be aware of any additional 603 information than the upstream and downstream masks, and can be 604 integrated with the other operational mechanisms applied by the 605 controller to distribute shares and other secret material. 607 4. Sizing the Data for Proof of Transit 609 Proof of transit requires transport of two data fields in every 610 packet that should be verified: 612 1. RND: Random number (the constant coefficient of public 613 polynomial) 615 2. CML: Cumulative 617 The size of the data fields determines how often a new set of 618 polynomials would need to be created. At maximum, the largest RND 619 number that can be represented with a given number of bits determines 620 the number of unique polynomials POLY-2 that can be created. The 621 table below shows the maximum interval for how long a single set of 622 polynomials could last for a variety of bit rates and RND sizes: When 623 choosing 64 bits for RND and CML data fields, the time between a 624 renewal of secrets could be as long as 3,100 years, even when running 625 at 100 Gbps. 627 +-------------+--------------+------------------+-------------------+ 628 | Transfer | Secret/RND | Max # of packets | Time RND lasts | 629 | rate | size | | | 630 +-------------+--------------+------------------+-------------------+ 631 | 1 Gbps | 64 | 2^64 = approx. | approx. 310,000 | 632 | | | 2*10^19 | years | 633 | 10 Gbps | 64 | 2^64 = approx. | approx. 31,000 | 634 | | | 2*10^19 | years | 635 | 100 Gbps | 64 | 2^64 = approx. | approx. 3,100 | 636 | | | 2*10^19 | years | 637 | 1 Gbps | 32 | 2^32 = approx. | 2,200 seconds | 638 | | | 4*10^9 | | 639 | 10 Gbps | 32 | 2^32 = approx. | 220 seconds | 640 | | | 4*10^9 | | 641 | 100 Gbps | 32 | 2^32 = approx. | 22 seconds | 642 | | | 4*10^9 | | 643 +-------------+--------------+------------------+-------------------+ 645 Table assumes 64 octet packets 647 Table 1: Proof of transit data sizing 649 If the symmetric masking method for ordered POT is used 650 (Section 3.5), the masks used between nodes adjacent in the path MUST 651 have a length equal to the sum of the ones of RND and CML. 653 5. Node Configuration 655 A POT system consists of a number of nodes that participate in POT 656 and a Controller, which serves as a control and configuration entity. 657 The Controller is to create the required parameters (polynomials, 658 prime number, etc.) and communicate the associated values (i.e. prime 659 number, secret-share, LPC, etc.) to the nodes. The sum of all 660 parameters for a specific node is referred to as "POT-Profile". For 661 details see the YANG model in Section 5.2.This document does not 662 define a specific protocol to be used between Controller and nodes. 663 It only defines the procedures and the associated YANG data model. 665 5.1. Procedure 667 The Controller creates new POT-Profiles at a constant rate and 668 communicates the POT-Profile to the nodes. The controller labels a 669 POT-Profile "even" or "odd" and the Controller cycles between "even" 670 and "odd" labeled profiles. This means that the parameters for the 671 algorithms are continuously refreshed. Please refer to Section 4 for 672 choosing an appropriate refresh rate: The rate at which the POT- 673 Profiles are communicated to the nodes is configurable and MUST be 674 more frequent than the speed at which a POT-Profile is "used up". 675 Once the POT-Profile has been successfully communicated to all nodes 676 (e.g., all NETCONF transactions completed, in case NETCONF is used as 677 a protocol), the controller sends an "enable POT-Profile" request to 678 the ingress node. 680 All nodes maintain two POT-Profiles (an even and an odd POT-Profile): 681 One POT-Profile is currently active and in use; one profile is 682 standby and about to get used. A flag in the packet is indicating 683 whether the odd or even POT-Profile is to be used by a node. This is 684 to ensure that during profile change the service is not disrupted. 685 If the "odd" profile is active, the Controller can communicate the 686 "even" profile to all nodes. Only if all the nodes have received the 687 POT-Profile, the Controller will tell the ingress node to switch to 688 the "even" profile. Given that the indicator travels within the 689 packet, all nodes will switch to the "even" profile. The "even" 690 profile gets active on all nodes and nodes are ready to receive a new 691 "odd" profile. 693 Unless the ingress node receives a request to switch profiles, it'll 694 continue to use the active profile. If a profile is "used up" the 695 ingress node will recycle the active profile and start over (this 696 could give rise to replay attacks in theory - but with 2^32 or 2^64 697 packets this isn't really likely in reality). 699 5.2. YANG Model for POT 701 This section defines that YANG data model for the information 702 exchange between the Controller and the node. 704 5.2.1. Main Parameters 706 The main parameters for the information exchange between the 707 Controller and the node used in the YANG model are as follows: 709 o pot-profile-index: Section 5.1 details that two POT-Profiles are 710 used. Only one of the POT-Profiles is active at a given point in 711 time, allowing the Controller to refresh the non-active one for 712 future use. pot-profile-index defines which of the POT-Profiles 713 (the "even" or "odd" POT-Profile) is currently active. pot- 714 profile-index will be set in the first hop of the path or chain. 715 Other nodes will not use this field. 717 o prime-number: Prime number used for module math computation. 719 o secret-share: Share of the secret of polynomial-1 used in 720 computation for the node. If POLY-1 is defined by points (x1_i, 721 y1_i) with i=0,..k, then for node i, the secret-share will be 722 y1_i. 724 o public-polynomial: Public polynomial value for the node.. If 725 POLY-2 is defined by points (x2_i, y2_i) with i=0,..k, then for 726 node i, the secret-share will be y2_i. 728 o lpc: Lagrange Polynomial Coefficient for the node, i.e. for node 729 i, this would be LPC(l_i), with l_i being the i-th Lagrange Basis 730 Polynomial. 732 o validator?: True if the node is a verifier node. 734 o validator-key?: The validator-key represents the SECRET as 735 described in the sections above. The SECRET is the constant 736 coefficient of POLY-1(z). If POLY-1(z) = a_0 + a_1*z + 737 a_2*z^2+..+a_k*z^k, then the SECRET would be a_0. 739 o bitmask?: Number of bits as mask used in controlling the size of 740 the random value generation. 32-bits of mask is default. See 741 Section 4 for details. 743 5.2.2. Tree Diagram 745 This section shows a simplified graphical representation of the YANG 746 data model for POT. The meaning of the symbols in these diagrams is 747 as follows: 749 o Brackets "[" and "]" enclose list keys. 751 o Abbreviations before data node names: "rw" means configuration 752 (read-write), and "ro" means state data (read-only). 754 o Symbols after data node names: "?" means an optional node, "!" 755 means a presence container, and "*" denotes a list and leaf-list. 757 o Parentheses enclose choice and case nodes, and case nodes are also 758 marked with a colon (":"). 760 o Ellipsis ("...") stands for contents of subtrees that are not 761 shown. 763 764 module: ietf-pot-profile 765 +--rw pot-profiles 766 +--rw pot-profile-set* [pot-profile-name] 767 +--rw pot-profile-name string 768 +--rw active-profile-index? profile-index-range 769 +--rw pot-profile-list* [pot-profile-index] 770 +--rw pot-profile-index profile-index-range 771 +--rw prime-number uint64 772 +--rw secret-share uint64 773 +--rw public-polynomial uint64 774 +--rw lpc uint64 775 +--rw validator? boolean 776 +--rw validator-key? uint64 777 +--rw bitmask? uint64 778 +--rw opot-masks 779 +--rw downstream-mask* uint64 780 +--rw upstream-mask* uint64 781 783 5.2.3. YANG Model 785 file "ietf-pot-profile@2016-06-15.yang" 786 module ietf-pot-profile { 788 yang-version 1; 790 namespace "urn:ietf:params:xml:ns:yang:ietf-pot-profile"; 792 prefix ietf-pot-profile; 794 organization "IETF SFC Working Group"; 796 contact "WG Web: 797 WG List: "; 799 description 800 "This module contains a collection of YANG 801 definitions for proof of transit configuration 802 parameters. The model is meant for proof of 803 transit and is targeted for communicating the 804 POT-Profile between a controller and nodes 805 participating in proof of transit. 807 Copyright (c) 2018 IETF Trust and the persons identified as 808 authors of the code. All rights reserved. 809 Redistribution and use in source and binary forms, with or 810 without modification, is permitted pursuant to, and subject 811 to the license terms contained in, the Simplified BSD License 812 set forth in Section 4.c of the IETF Trust's Legal Provisions 813 Relating to IETF Documents 814 (http://trustee.ietf.org/license-info). 816 This version of this YANG module is part of RFC XXXX; see 817 the RFC itself for full legal notices. 819 Copyright (c) 2018 IETF Trust and the persons identified as 820 authors of the code. All rights reserved. 822 The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL 823 NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT RECOMMENDED', 824 'MAY', and 'OPTIONAL' in this document are to be interpreted as 825 described in BCP 14 (RFC 2119) (RFC 8174) when, and only when, 826 they appear in all capitals, as shown here."; 828 revision 2016-06-15 { 829 description 830 "Initial revision."; 831 reference 832 ""; 833 } 835 typedef profile-index-range { 836 type int32 { 837 range "0 .. 1"; 838 } 839 description 840 "Range used for the profile index. Currently restricted to 841 0 or 1 to identify the odd or even profiles."; 842 } 844 grouping pot-profile { 845 description "A grouping for proof of transit profiles."; 846 list pot-profile-list { 847 key "pot-profile-index"; 848 ordered-by user; 849 description "A set of pot profiles."; 851 leaf pot-profile-index { 852 type profile-index-range; 853 mandatory true; 854 description 855 "Proof of transit profile index."; 856 } 858 leaf prime-number { 859 type uint64; 860 mandatory true; 861 description 862 "Prime number used for module math computation"; 863 } 865 leaf secret-share { 866 type uint64; 867 mandatory true; 868 description 869 "Share of the secret of polynomial-1 used 870 in computation for the node. If POLY-1 871 is defined by points (x1_i, y1_i) with 872 i=0,..k, then for node i, the secret-share 873 will be y1_i."; 874 } 876 leaf public-polynomial { 877 type uint64; 878 mandatory true; 879 description 880 "Public polynomial value for the node. 881 If POLY-2 is defined by points (x2_i, y2_i) 882 with i=0,..k, then for node i, 883 the secret-share will be y2_i."; 884 } 886 leaf lpc { 887 type uint64; 888 mandatory true; 889 description 890 "Lagrange Polynomial Coefficient"; 891 } 893 leaf validator { 894 type boolean; 895 default "false"; 896 description 897 "True if the node is a verifier node"; 898 } 900 leaf validator-key { 901 type uint64; 902 description 903 "The validator-key represents the secret. 904 The secret is the constant coefficient of 905 POLY-1(z). If POLY-1(z) = 906 a_0 + a_1*z + a_2*z^2+..+a_k*z^k, 907 then the SECRET would be a_0."; 908 } 910 leaf bitmask { 911 type uint64; 912 default 4294967295; 913 description 914 "Number of bits as mask used in controlling 915 the size of the random value generation. 916 32-bits of mask is default."; 917 } 919 uses opot-profile; 921 } 922 } 924 grouping opot-profile { 925 description "Grouping containing OPoT related data."; 927 container opot-masks { 928 must "count(downstream-mask) = count(upstream-mask)"; 929 description "Masking information for OPoT support."; 931 leaf-list downstream-mask { 932 type uint64; 933 max-elements 2; 934 description "Secret stream used to demask the PoT metadata. 935 The mask is used between nodes adjacent in the path 936 and MUST have a length equal to the sum of the ones 937 of RND and CML."; 938 } 940 leaf-list upstream-mask { 941 type uint64; 942 max-elements 2; 943 description "Secret stream used to mask the PoT metadata. 944 The mask is used between nodes adjacent in the path 945 and MUST have a length equal to the sum of the ones 946 of RND and CML."; 947 } 948 } 949 } 951 container pot-profiles { 952 description "A group of proof of transit profiles."; 954 list pot-profile-set { 955 key "pot-profile-name"; 956 ordered-by user; 957 description 958 "Set of proof of transit profiles that group parameters 959 required to classify and compute proof of transit 960 metadata at a node"; 962 leaf pot-profile-name { 963 type string; 964 mandatory true; 965 description 966 "Unique identifier for each proof of transit profile"; 967 } 969 leaf active-profile-index { 970 type profile-index-range; 971 description 972 "POT-Profile index that is currently active. 973 Will be set in the first hop of the path or chain. 974 Other nodes will not use this field."; 975 } 977 uses pot-profile; 978 } 979 /*** Container: end ***/ 980 } 981 /*** module: end ***/ 982 } 983 985 6. IANA Considerations 987 This document does not require any actions from IANA. 989 7. Security Considerations 991 POT is a mechanism that is used for verifying the path through which 992 a packet was forwarded. The security considerations of IOAM in 993 general are discussed in [I-D.ietf-ippm-ioam-data]. Specifically, it 994 is assumed that POT is used in a confined network domain, and 995 therefore the potential threats that POT is intended to mitigate 996 should be viewed accordingly. POT prevents spoofing and tampering; 997 an attacker cannot maliciously create a bogus POT or modify a 998 legitimate one. Furthermore, a legitimate node that takes part in 999 the POT protocol cannot masquerade as another node along the path. 1000 These considerations are discussed in detail in the rest of this 1001 section. 1003 7.1. Proof of Transit 1005 Proof of correctness and security of the solution approach is per 1006 Shamir's Secret Sharing Scheme [SSS]. Cryptographically speaking it 1007 achieves information-theoretic security i.e., it cannot be broken by 1008 an attacker even with unlimited computing power. As long as the 1009 below conditions are met it is impossible for an attacker to bypass 1010 one or multiple nodes without getting caught. 1012 o If there are k+1 nodes in the path, the polynomials (POLY-1, POLY- 1013 2) should be of degree k. Also k+1 points of POLY-1 are chosen 1014 and assigned to each node respectively. The verifier can re- 1015 construct the k degree polynomial (POLY-3) only when all the 1016 points are correctly retrieved. 1018 o Precisely three values are kept secret by individual nodes. Share 1019 of SECRET (i.e. points on POLY-1), Share of POLY-2, LPC, P. Note 1020 that only constant coefficient, RND, of POLY-2 is public. x values 1021 and non-constant coefficient of POLY-2 are secret 1023 An attacker bypassing a few nodes will miss adding a respective point 1024 on POLY-1 to corresponding point on POLY-2 , thus the verifier cannot 1025 construct POLY-3 for cross verification. 1027 Also it is highly recommended that different polynomials should be 1028 used as POLY-1 across different paths, traffic profiles or service 1029 chains. 1031 If symmetric masking is used to assure OPOT (Section 3.5), the nodes 1032 need to keep two additional secrets: the downstream and upstream 1033 masks, that have to be managed under the same conditions as the 1034 secrets mentioned above. And it is equally recommended to employ a 1035 different set of mask pairs across different paths, traffic profiles 1036 or service chains. 1038 7.2. Cryptanalysis 1040 A passive attacker could try to harvest the POT data (i.e., CML, RND 1041 values) in order to determine the configured secrets. Subsequently 1042 two types of differential analysis for guessing the secrets could be 1043 done. 1045 o Inter-Node: A passive attacker observing CML values across nodes 1046 (i.e., as the packets entering and leaving), cannot perform 1047 differential analysis to construct the points on POLY-1. This is 1048 because at each point there are four unknowns (i.e. Share(POLY- 1049 1), Share(Poly-2) LPC and prime number P) and three known values 1050 (i.e. RND, CML-before, CML-after). The application of symmetric 1051 masking for OPOT makes inter-node analysis less feasible. 1053 o Inter-Packets: A passive attacker could observe CML values across 1054 packets (i.e., values of PKT-1 and subsequent PKT-2), in order to 1055 predict the secrets. Differential analysis across packets could 1056 be mitigated using a good PRNG for generating RND. Note that if 1057 constant coefficient is a sequence number than CML values become 1058 quite predictable and the scheme would be broken. If symmetric 1059 masking is used for OPOT, inter-packet analysis could be applied 1060 to guess mask values, which requires a proper refresh rate for 1061 masks, at least as high as the one used for LPCs. 1063 7.3. Anti-Replay 1065 A passive attacker could reuse a set of older RND and the 1066 intermediate CML values. Thus, an attacker can attack an old 1067 (replayed) RND and CML with a new packet in order to bypass some of 1068 the nodes along the path. 1070 Such attacks could be avoided by carefully choosing POLY-2 as a 1071 (SEQ_NO + RND). For example, if 64 bits are being used for POLY-2 1072 then first 16 bits could be a sequence number SEQ_NO and next 48 bits 1073 could be a random number. 1075 Subsequently, the verifier could use the SEQ_NO bits to run classic 1076 anti-replay techniques like sliding window used in IPSEC. The 1077 verifier could buffer up to 2^16 packets as a sliding window. 1078 Packets arriving with a higher SEQ_NO than current buffer could be 1079 flagged legitimate. Packets arriving with a lower SEQ_NO than 1080 current buffer could be flagged as suspicious. 1082 For all practical purposes in the rest of the document RND means 1083 SEQ_NO + RND to keep it simple. 1085 The solution discussed in this memo does not currently mitigate 1086 replay attacks. An anti-replay mechanism may be included in future 1087 versions of the solution. 1089 7.4. Anti-Preplay 1091 An active attacker could try to perform a man-in-the-middle (MITM) 1092 attack by extracting the POT of PKT-1 and using it in PKT-2. 1093 Subsequently attacker drops the PKT-1 in order to avoid duplicate POT 1094 values reaching the verifier. If the PKT-1 reaches the verifier, 1095 then this attack is same as Replay attacks discussed before. 1097 Preplay attacks are possible since the POT metadata is not dependent 1098 on the packet fields. Below steps are recommended for remediation: 1100 o Ingress node and Verifier are configured with common pre shared 1101 key 1103 o Ingress node generates a Message Authentication Code (MAC) from 1104 packet fields using standard HMAC algorithm. 1106 o The left most bits of the output are truncated to desired length 1107 to generate RND. It is recommended to use a minimum of 32 bits. 1109 o The verifier regenerates the HMAC from the packet fields and 1110 compares with RND. To ensure the POT data is in fact that of the 1111 packet. 1113 If an HMAC is used, an active attacker lacks the knowledge of the 1114 pre-shared key, and thus cannot launch preplay attacks. 1116 The solution discussed in this memo does not currently mitigate 1117 preplay attacks. A mitigation mechanism may be included in future 1118 versions of the solution. 1120 7.5. Tampering 1122 An active attacker could not insert any arbitrary value for CML. 1123 This would subsequently fail the reconstruction of the POLY-3. Also 1124 an attacker could not update the CML with a previously observed 1125 value. This could subsequently be detected by using timestamps 1126 within the RND value as discussed above. 1128 7.6. Recycling 1130 The solution approach is flexible for recycling long term secrets 1131 like POLY-1. All the nodes could be periodically updated with shares 1132 of new SECRET as best practice. The table above could be consulted 1133 for refresh cycles (see Section 4). 1135 If symmetric masking is used for OPOT (Section 3.5), mask values must 1136 be periodically updated as well, at least as frequently as the other 1137 secrets are. 1139 7.7. Redundant Nodes and Failover 1141 A "node" or "service" in terms of POT can be implemented by one or 1142 multiple physical entities. In case of multiple physical entities 1143 (e.g., for load-balancing, or business continuity situations - 1144 consider for example a set of firewalls), all physical entities which 1145 are implementing the same POT node are given that same share of the 1146 secret. This makes multiple physical entities represent the same POT 1147 node from an algorithm perspective. 1149 7.8. Controller Operation 1151 The Controller needs to be secured given that it creates and holds 1152 the secrets, as need to be the nodes. The communication between 1153 Controller and the nodes also needs to be secured. As secure 1154 communication protocol such as for example NETCONF over SSH should be 1155 chosen for Controller to node communication. 1157 The Controller only interacts with the nodes during the initial 1158 configuration and thereafter at regular intervals at which the 1159 operator chooses to switch to a new set of secrets. In case 64 bits 1160 are used for the data fields "CML" and "RND" which are carried within 1161 the data packet, the regular intervals are expected to be quite long 1162 (e.g., at 100 Gbps, a profile would only be used up after 3100 years) 1163 - see Section 4 above, thus even a "headless" operation without a 1164 Controller can be considered feasible. In such a case, the 1165 Controller would only be used for the initial configuration of the 1166 POT-Profiles. 1168 If OPOT (Section 3.5) is applied using symmetric masking, the 1169 Controller will be required to perform a a periodic refresh of the 1170 mask pairs. The use of OPOT SHOULD be configurable as part of the 1171 required level of assurance through the Controller management 1172 interface. 1174 7.9. Verification Scope 1176 The POT solution defined in this document verifies that a data-packet 1177 traversed or transited a specific set of nodes. From an algorithm 1178 perspective, a "node" is an abstract entity. It could be represented 1179 by one or multiple physical or virtual network devices, or is could 1180 be a component within a networking device or system. The latter 1181 would be the case if a forwarding path within a device would need to 1182 be securely verified. 1184 7.9.1. Node Ordering 1186 POT using Shamir's secret sharing scheme as discussed in this 1187 document provides for a means to verify that a set of nodes has been 1188 visited by a data packet. It does not verify the order in which the 1189 data packet visited the nodes. 1191 In case the order in which a data packet traversed a particular set 1192 of nodes needs to be verified as well, the alternate schemes related 1193 to OPOT (Section 3.5) have to be considered. Since these schemes 1194 introduce at least additional control requirements, the selection of 1195 order verification SHOULD be configurable the Controller management 1196 interface. 1198 7.9.2. Stealth Nodes 1200 The POT approach discussed in this document is to prove that a data 1201 packet traversed a specific set of "nodes". This set could be all 1202 nodes within a path, but could also be a subset of nodes in a path. 1203 Consequently, the POT approach isn't suited to detect whether 1204 "stealth" nodes which do not participate in proof-of-transit have 1205 been inserted into a path. 1207 8. Acknowledgements 1209 The authors would like to thank Eric Vyncke, Nalini Elkins, Srihari 1210 Raghavan, Ranganathan T S, Karthik Babu Harichandra Babu, Akshaya 1211 Nadahalli, Erik Nordmark, and Andrew Yourtchenko for the comments and 1212 advice. 1214 9. Contributors 1216 In addition to editors and authors listed on the title page, the 1217 following people have contributed substantially to this document and 1218 should be considered coauthors: 1220 Carlos Pignataro 1221 Cisco Systems, Inc. 1222 7200-11 Kit Creek Road 1223 Research Triangle Park, NC 27709 1224 United States 1225 Email: cpignata@cisco.com 1227 John Leddy 1228 Email: john@leddy.net 1230 David Mozes 1231 Email: mosesster@gmail.com 1233 Alejandro Aguado 1234 Universidad Politecnica de Madrid 1235 Campus Montegancedo, Boadilla del Monte 1236 Madrid 28660 1237 Spain 1238 Phone: +34 910 673 086 1239 Email: a.aguadom@fi.upm.es 1241 Diego R. Lopez 1242 Telefonica I+D 1243 Editor Jose Manuel Lara, 9 (1-B) 1244 Seville 41013 1245 Spain 1246 Phone: +34 913 129 041 1247 Email: diego.r.lopez@telefonica.com 1249 10. References 1251 10.1. Normative References 1253 [I-D.ietf-ippm-ioam-data] 1254 Brockners, F., Bhandari, S., Pignataro, C., Gredler, H., 1255 Leddy, J., Youell, S., Mizrahi, T., Mozes, D., Lapukhov, 1256 P., remy@barefootnetworks.com, r., daniel.bernier@bell.ca, 1257 d., and J. Lemon, "Data Fields for In-situ OAM", draft- 1258 ietf-ippm-ioam-data-08 (work in progress), October 2019. 1260 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1261 Requirement Levels", BCP 14, RFC 2119, 1262 DOI 10.17487/RFC2119, March 1997, 1263 . 1265 [RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function 1266 Chaining (SFC) Architecture", RFC 7665, 1267 DOI 10.17487/RFC7665, October 2015, 1268 . 1270 [SSS] "Shamir's Secret Sharing", 1271 . 1273 10.2. Informative References 1275 [I-D.ietf-anima-autonomic-control-plane] 1276 Eckert, T., Behringer, M., and S. Bjarnason, "An Autonomic 1277 Control Plane (ACP)", draft-ietf-anima-autonomic-control- 1278 plane-18 (work in progress), August 2018. 1280 Authors' Addresses 1282 Frank Brockners (editor) 1283 Cisco Systems, Inc. 1284 Hansaallee 249, 3rd Floor 1285 DUESSELDORF, NORDRHEIN-WESTFALEN 40549 1286 Germany 1288 Email: fbrockne@cisco.com 1290 Shwetha Bhandari (editor) 1291 Cisco Systems, Inc. 1292 Cessna Business Park, Sarjapura Marathalli Outer Ring Road 1293 Bangalore, KARNATAKA 560 087 1294 India 1296 Email: shwethab@cisco.com 1298 Tal Mizrahi (editor) 1299 Huawei Network.IO Innovation Lab 1300 Israel 1302 Email: tal.mizrahi.phd@gmail.com 1303 Sashank Dara 1304 Seconize 1305 BANGALORE, Bangalore, KARNATAKA 1306 INDIA 1308 Email: sashank@seconize.co 1310 Stephen Youell 1311 JP Morgan Chase 1312 25 Bank Street 1313 London E14 5JP 1314 United Kingdom 1316 Email: stephen.youell@jpmorgan.com