idnits 2.17.1 draft-ietf-sfc-proof-of-transit-08.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: '...le-name str...' == Line 772 has weird spacing: '...e-index pro...' == Line 776 has weird spacing: '...ynomial uin...' == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (31 October 2020) is 1265 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-10 == Outdated reference: A later version (-13) exists of draft-ietf-sfc-ioam-nsh-04 == Outdated reference: A later version (-30) exists of draft-ietf-anima-autonomic-control-plane-18 -- Obsolete informational reference (is this intentional?): RFC 5246 (Obsoleted by RFC 8446) Summary: 0 errors (**), 0 flaws (~~), 8 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group F. Brockners, Ed. 3 Internet-Draft Cisco 4 Intended status: Experimental S. Bhandari, Ed. 5 Expires: 4 May 2021 Thoughtspot 6 T. Mizrahi, Ed. 7 Huawei Network.IO Innovation Lab 8 S. Dara 9 Seconize 10 S. Youell 11 JPMC 12 31 October 2020 14 Proof of Transit 15 draft-ietf-sfc-proof-of-transit-08 17 Abstract 19 Several technologies such as Traffic Engineering (TE), Service 20 Function Chaining (SFC), and policy based routing are used to steer 21 traffic through a specific, user-defined path. This document defines 22 mechanisms to securely prove that traffic transited a defined path. 23 These mechanisms allow to securely verify whether, within a given 24 path, all packets traversed all the nodes that they are supposed to 25 visit. This document specifies a data model to enable these 26 mechanisms using YANG. 28 Status of This Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at https://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on 4 May 2021. 45 Copyright Notice 47 Copyright (c) 2020 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 52 license-info) in effect on the date of publication of this document. 53 Please review these documents carefully, as they describe your rights 54 and restrictions with respect to this document. Code Components 55 extracted from this document must include Simplified BSD License text 56 as described in Section 4.e of the Trust Legal Provisions and are 57 provided without warranty as described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 62 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 63 3. Proof of Transit . . . . . . . . . . . . . . . . . . . . . . 6 64 3.1. Basic Idea . . . . . . . . . . . . . . . . . . . . . . . 6 65 3.2. Solution Approach . . . . . . . . . . . . . . . . . . . . 7 66 3.2.1. Setup . . . . . . . . . . . . . . . . . . . . . . . . 8 67 3.2.2. In Transit . . . . . . . . . . . . . . . . . . . . . 8 68 3.2.3. Verification . . . . . . . . . . . . . . . . . . . . 9 69 3.3. Illustrative Example . . . . . . . . . . . . . . . . . . 9 70 3.3.1. Baseline . . . . . . . . . . . . . . . . . . . . . . 9 71 3.3.1.1. Secret Shares . . . . . . . . . . . . . . . . . . 9 72 3.3.1.2. Lagrange Polynomials . . . . . . . . . . . . . . 10 73 3.3.1.3. LPC Computation . . . . . . . . . . . . . . . . . 10 74 3.3.1.4. Reconstruction . . . . . . . . . . . . . . . . . 10 75 3.3.1.5. Verification . . . . . . . . . . . . . . . . . . 11 76 3.3.2. Complete Solution . . . . . . . . . . . . . . . . . . 11 77 3.3.2.1. Random Polynomial . . . . . . . . . . . . . . . . 11 78 3.3.2.2. Reconstruction . . . . . . . . . . . . . . . . . 11 79 3.3.2.3. Verification . . . . . . . . . . . . . . . . . . 12 80 3.3.3. Solution Deployment Considerations . . . . . . . . . 12 81 3.4. Operational Aspects . . . . . . . . . . . . . . . . . . . 13 82 3.5. Ordered POT (OPOT) . . . . . . . . . . . . . . . . . . . 13 83 4. Sizing the Data for Proof of Transit . . . . . . . . . . . . 14 84 5. Node Configuration . . . . . . . . . . . . . . . . . . . . . 16 85 5.1. Procedure . . . . . . . . . . . . . . . . . . . . . . . . 16 86 5.2. YANG Model for POT . . . . . . . . . . . . . . . . . . . 17 87 5.2.1. Main Parameters . . . . . . . . . . . . . . . . . . . 17 88 5.2.2. Tree Diagram . . . . . . . . . . . . . . . . . . . . 18 89 5.2.3. YANG Model . . . . . . . . . . . . . . . . . . . . . 18 90 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 91 7. Security Considerations . . . . . . . . . . . . . . . . . . . 23 92 7.1. Proof of Transit . . . . . . . . . . . . . . . . . . . . 24 93 7.2. Cryptanalysis . . . . . . . . . . . . . . . . . . . . . . 24 94 7.3. Anti-Replay . . . . . . . . . . . . . . . . . . . . . . . 25 95 7.4. Anti-Preplay . . . . . . . . . . . . . . . . . . . . . . 26 96 7.5. Tampering . . . . . . . . . . . . . . . . . . . . . . . . 26 97 7.6. Recycling . . . . . . . . . . . . . . . . . . . . . . . . 26 98 7.7. Redundant Nodes and Failover . . . . . . . . . . . . . . 27 99 7.8. Controller Operation . . . . . . . . . . . . . . . . . . 27 100 7.9. Verification Scope . . . . . . . . . . . . . . . . . . . 27 101 7.9.1. Node Ordering . . . . . . . . . . . . . . . . . . . . 28 102 7.9.2. Stealth Nodes . . . . . . . . . . . . . . . . . . . . 28 103 7.10. POT Yang module . . . . . . . . . . . . . . . . . . . . . 28 104 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 29 105 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 29 106 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 29 107 10.1. Normative References . . . . . . . . . . . . . . . . . . 29 108 10.2. Informative References . . . . . . . . . . . . . . . . . 30 109 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 31 111 1. Introduction 113 Several deployments use Traffic Engineering, policy routing, Segment 114 Routing (SR), and Service Function Chaining (SFC) [RFC7665] to steer 115 packets through a specific set of nodes. In certain cases, 116 compliance policies require operators to prove that all packets that 117 are supposed to follow a specific path are indeed being forwarded 118 across an exact set of pre-determined nodes. 120 If a packet flow is supposed to go through a series of service 121 functions or network nodes, it has to be proven that indeed all 122 packets of the flow followed the path or service chain or collection 123 of nodes specified by the policy. In case some packets of a flow 124 weren't appropriately processed, a verification device should 125 determine the policy violation and take corresponding actions 126 corresponding to the policy (e.g., drop or redirect the packet, send 127 an alert etc.) In today's deployments, the proof that a packet 128 traversed a particular path or service chain is typically delivered 129 in an indirect way: Service appliances and network forwarding are in 130 different trust domains. Physical hand-off-points are defined 131 between these trust domains (i.e. physical interfaces). Or in other 132 terms, in the "network forwarding domain" things are wired up in a 133 way that traffic is delivered to the ingress interface of a service 134 appliance and received back from an egress interface of a service 135 appliance. This "wiring" is verified and then trusted upon. The 136 evolution to Network Function Virtualization (NFV) and modern service 137 chaining concepts (using technologies such as Locator/ID Separation 138 Protocol (LISP), Network Service Header (NSH), Segment Routing (SR), 139 etc.) blurs the line between the different trust domains, because the 140 hand-off-points are no longer clearly defined physical interfaces, 141 but are virtual interfaces. As a consequence, different trust layers 142 should not to be mixed in the same device. For an NFV scenario a 143 different type of proof is required. Offering a proof that a packet 144 indeed traversed a specific set of service functions or nodes allows 145 operators to evolve from the above described indirect methods of 146 proving that packets visit a predetermined set of nodes. 148 The solution approach presented in this document is based on a small 149 portion of operational data added to every packet. This "in-situ" 150 operational data is also referred to as "proof of transit data", or 151 POT data. The POT data is updated at every required node and is used 152 to verify whether a packet traversed all required nodes. A 153 particular set of nodes "to be verified" is either described by a set 154 of shares of a single secret. Nodes on the path retrieve their 155 individual shares of the secret using Shamir's Secret Sharing scheme 156 from a central controller. The complete secret set is only known to 157 the controller and a verifier node, which is typically the ultimate 158 node on a path that performs verification. Each node in the path 159 uses its share of the secret to update the POT data of the packets as 160 the packets pass through the node. When the verifier receives a 161 packet, it uses its key along with data found in the packet to 162 validate whether the packet traversed the path correctly. This 163 document defines a data model and specifies it formally using the 164 YANG 1.1 [RFC7950] data modeling language to support enabling the POT 165 solution. The YANG data model defined in this document conforms to 166 the Network Management Datastore Architecture (NMDA) defined in 167 [RFC8342]. 169 Note to RFC Editor: Please replace the date 2020-09-09 in Section 5.2 170 of the draft with the date of publication of this draft as a RFC. 171 Also, replace reference to RFC XXXX, and draft-ietf-sfc-proof-of- 172 transit with the RFC numbers assigned to the drafts. 174 2. Terminology 176 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 177 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 178 "OPTIONAL" in this document are to be interpreted as described in 179 BCP[RFC2119] [RFC8174] 181 Abbreviations used in this document: 183 HMAC: Hashed Message Authentication Code. For example, HMAC- 184 SHA256 generates 256 bits of MAC 186 IOAM: In-situ Operations, Administration, and Maintenance 188 LISP: Locator/ID Separation Protocol 190 LPC: Lagrange Polynomial Constants 192 NFV: Network Function Virtualization 194 NSH: Network Service Header 196 POT: Proof of Transit 198 POT-Profile: Proof of Transit Profile that has the necessary data 199 for nodes to participate in proof of transit 201 RND: Random Bits generated per packet. Packet fields that do 202 not change during the traversal are given as input to 203 HMAC-256 algorithm. A minimum of 32 bits (left most) need 204 to be used from the output if RND is used to verify the 205 packet integrity. This is a standard recommendation by 206 NIST. 208 SEQ_NO: Sequence number initialized to a predefined constant. 209 This is used in concatenation with RND bits to mitigate 210 different attacks discussed later. 212 SFC: Service Function Chain 214 SSSS: Shamir's Secret Sharing Scheme 216 SR: Segment Routing 218 3. Proof of Transit 220 This section discusses methods and algorithms to provide for a "proof 221 of transit" (POT) for packets traversing a specific path. A path 222 which is to be verified consists of a set of nodes. Transit of the 223 data packets through those nodes is to be proven. Besides the nodes, 224 the setup also includes a Controller that creates secrets and secrets 225 shares and configures the nodes for POT operations. 227 The methods how traffic is identified and associated to a specific 228 path is outside the scope of this document. Identification could be 229 done using a filter (e.g., 5-tuple classifier), or an identifier 230 which is already present in the packet (e.g., path or service 231 identifier, NSH Service Path Identifier (SPI), flow-label, etc.) 233 When used in the context of IOAM, the POT information MUST be 234 encapsulated in packets as an IOAM Proof of Transit Option-Type. The 235 details and format of the encapsulation and the IOAM POT Option-Type 236 format are specified in [I-D.ietf-ippm-ioam-data]. When used in 237 conjunction with NSH [RFC8300], the POT Option-Type MUST be carried 238 as specified in [I-D.ietf-sfc-ioam-nsh]. 240 The solution approach is detailed in two steps. Initially the 241 concept of the approach is explained. This concept is then further 242 refined to make it operationally feasible. 244 3.1. Basic Idea 246 The method relies on adding POT data to all packets that traverse a 247 path. The added POT data allows a verifying node (egress node) to 248 check whether a packet traversed the identified set of nodes on a 249 path correctly or not. Security mechanisms are natively built into 250 the generation of the POT data to protect against misuse (e.g., 251 configuration mistakes). The mechanism for POT leverages "Shamir's 252 Secret Sharing" scheme [SSS]. 254 Shamir's Secret Sharing base idea: A polynomial (represented by its 255 coefficients) of degree k is chosen as a secret by the controller. A 256 polynomial represents a curve. A set of k+1 points on the curve 257 define the polynomial and are thus needed to (re-)construct the 258 polynomial. Each of these k+1 points of the polynomial is called a 259 "share" of the secret. A single secret is associated with a 260 particular set of k+1 nodes, which typically represent the path to be 261 verified. k+1 shares of the single secret (i.e., k+1 points on the 262 curve) are securely distributed from a Controller to the network 263 nodes. Nodes use their respective share to update a cumulative value 264 in the POT data of each packet. Only a verifying node has access to 265 the complete secret. The verifying node validates the correctness of 266 the received POT data by reconstructing the curve. 268 The polynomial cannot be reconstructed if any of the points are 269 missed or tampered. Per Shamir's Secret Sharing Scheme, any lesser 270 points means one or more nodes are missed. Details of the precise 271 configuration needed for achieving security are discussed further 272 below. 274 While applicable in theory, a vanilla approach based on Shamir's 275 Secret Sharing Scheme could be easily attacked. If the same 276 polynomial is reused for every packet for a path a passive attacker 277 could reuse the value. As a consequence, one could consider creating 278 a different polynomial per packet. Such an approach would be 279 operationally complex. It would be complex to configure and recycle 280 so many curves and their respective points for each node. Rather 281 than using a single polynomial, two polynomials are used for the 282 solution approach: A secret polynomial as described above which is 283 kept constant, and a per-packet polynomial which is public and 284 generated by the ingress node (the first node along the path). 285 Operations are performed on the sum of those two polynomials - 286 creating a third polynomial which is secret and per packet. 288 3.2. Solution Approach 290 Solution approach: The overall algorithm uses two polynomials: POLY-1 291 and POLY-2. POLY-1 is secret and constant. A different POLY-1 is 292 used for each path, and its value is known to the controller and to 293 the verifier of the respective path. Each node gets a point on 294 POLY-1 at setup-time and keeps it secret. POLY-2 is public, random 295 and per packet. Each node generates a point on POLY-2 each time a 296 packet crosses it. Each node then calculates (point on POLY-1 + 297 point on POLY-2) to get a (point on POLY-3) and passes it to verifier 298 by adding it to each packet. The verifier constructs POLY-3 from the 299 points given by all the nodes and cross checks whether POLY-3 = 300 POLY-1 + POLY-2. Only the verifier knows POLY-1. 302 The solution leverages finite field arithmetic in a field of size 303 "prime number", i.e. all operations are performed "modulo prime 304 number". 306 Detailed algorithms are discussed next. A simple example that 307 describes how the algorithms work is discussed in Section 3.3. 309 The algorithms themselves do not constrain the ranges of possible 310 values for the different parameters and coefficients used. A 311 deployment of the algorithms will always need to define appropriate 312 ranges. Please refer to the YANG model in Section 5.2 for details on 313 the units and ranges of possible values of the different parameters 314 and coefficients. 316 3.2.1. Setup 318 A controller generates a first polynomial (POLY-1) of degree k and 319 k+1 points on the polynomial, corresponding to the k+1 nodes along 320 the path. The constant coefficient of POLY-1 is considered the 321 SECRET, which is per the definition of the Shamir's Secret Sharing 322 algorithm [SSS]. The k+1 points are used to derive the Lagrange 323 Basis Polynomials. The Lagrange Polynomial Constants (LPC) are 324 retrieved from the constant coefficients of the Lagrange Basis 325 Polynomials. Each of the k+1 nodes (including verifier) are assigned 326 a point on the polynomial i.e., shares of the SECRET. The verifier 327 is configured with the SECRET. The Controller also generates 328 coefficients (except the constant coefficient, called "RND", which is 329 changed on a per packet basis) of a second polynomial POLY-2 of the 330 same degree. Each node is configured with the LPC of POLY-2. Note 331 that POLY-2 is public. 333 3.2.2. In Transit 335 For each packet, the ingress node generates a random number (RND). 336 It is considered as the constant coefficient for POLY-2. A 337 cumulative value (CML) is initialized to 0. Both RND, CML are 338 carried as within the packet POT data. As the packet visits each 339 node, the RND is retrieved from the packet and the respective share 340 of POLY-2 is calculated. Each node calculates (Share(POLY-1) + 341 Share(POLY-2)) and CML is updated with this sum, specifically each 342 node performs 344 CML = CML+(((Share(POLY-1)+ Share(POLY-2)) * LPC) mod Prime, with 345 "LPC" being the Lagrange Polynomial Constant and "Prime" being the 346 prime number which defines the finite field arithmetic that all 347 operations are done over. Please also refer to Section 3.3.2 below 348 for further details how the operations are performed. 350 This step is performed by each node until the packet completes the 351 path. The verifier also performs the step with its respective share. 353 3.2.3. Verification 355 The verifier cross checks whether CML = SECRET + RND. If this 356 matches then the packet traversed the specified set of nodes in the 357 path. This is due to the additive homomorphic property of Shamir's 358 Secret Sharing scheme. 360 3.3. Illustrative Example 362 This section shows a simple example to illustrate step by step the 363 approach described above. The example assumes a network with 3 364 nodes. The last node that packets traverse also serves as the 365 verifier. A Controller communicates the required parameters to the 366 individual nodes. 368 3.3.1. Baseline 370 Assumption: It is to be verified whether packets passed through the 3 371 nodes. A polynomial of degree 2 is chosen for verification. 373 Choices: Prime = 53. POLY-1(x) = (3x^2 + 3x + 10) mod 53. The 374 secret to be re-constructed is the constant coefficient of POLY-1, 375 i.e., SECRET=10. It is important to note that all operations are 376 done over a finite field (i.e., modulo Prime = 53). 378 3.3.1.1. Secret Shares 380 The shares of the secret are the points on POLY-1 chosen for the 3 381 nodes. For example, let x0=2, x1=4, x2=5. 383 POLY-1(2) = 28 => (x0, y0) = (2, 28) 385 POLY-1(4) = 17 => (x1, y1) = (4, 17) 387 POLY-1(5) = 47 => (x2, y2) = (5, 47) 389 The three points above are the points on the curve which are 390 considered the shares of the secret. They are assigned by the 391 Controller to three nodes respectively and are kept secret. 393 3.3.1.2. Lagrange Polynomials 395 Lagrange basis polynomials (or Lagrange polynomials) are used for 396 polynomial interpolation. For a given set of points on the curve 397 Lagrange polynomials (as defined below) are used to reconstruct the 398 curve and thus reconstruct the complete secret. 400 l0(x) = (((x-x1) / (x0-x1)) * ((x-x2)/x0-x2))) mod 53 401 = (((x-4) / (2-4)) * ((x-5)/2-5))) mod 53 402 = (10/3 - 3x/2 + (1/6)x^2) mod 53 404 l1(x) = (((x-x0) / (x1-x0)) * ((x-x2)/x1-x2))) mod 53 405 = (-5 + 7x/2 - (1/2)x^2) mod 53 407 l2(x) = (((x-x0) / (x2-x0)) * ((x-x1)/x2-x1))) mod 53 408 = (8/3 - 2 + (1/3)x^2) mod 53 410 3.3.1.3. LPC Computation 412 Since x0=2, x1=4, x2=5 are chosen points. Given that computations 413 are done over a finite arithmetic field ("modulo a prime number"), 414 the Lagrange basis polynomial constants are computed modulo 53. The 415 Lagrange Polynomial Constants (LPC) would be mod(10/3, 53), mod(-5, 416 53), mod(8/3, 53).LPC are computed by the Controller and communicated 417 to the individual nodes. 419 LPC(l0) = (10/3) mod 53 = 21 421 LPC(l1) = (-5) mod 53 = 48 423 LPC(l2) = (8/3) mod 53 = 38 425 For a general way to compute the modular multiplicative inverse, see 426 e.g., the Euclidean algorithm. 428 3.3.1.4. Reconstruction 430 Reconstruction of the polynomial is well-defined as 432 POLY1(x) = l0(x) * y0 + l1(x) * y1 + l2(x) * y2 434 Subsequently, the SECRET, which is the constant coefficient of 435 POLY1(x) can be computed as below 437 SECRET = (y0*LPC(l0)+y1*LPC(l1)+y2*LPC(l2)) mod 53 438 The secret can be easily reconstructed using the y-values and the 439 LPC: 441 SECRET = (y0*LPC(l0) + y1*LPC(l1) + y2*LPC(l2)) mod 53 442 = (28 * 21 + 17 * 48 + 47 * 38) mod 53 443 = 3190 mod 53 444 = 10 446 One observes that the secret reconstruction can easily be performed 447 cumulatively hop by hop, i.e. by every node. CML represents the 448 cumulative value. It is the POT data in the packet that is updated 449 at each hop with the node's respective (yi*LPC(i)), where i is their 450 respective value. 452 3.3.1.5. Verification 454 Upon completion of the path, the resulting CML is retrieved by the 455 verifier from the packet POT data. Recall that the verifier is 456 preconfigured with the original SECRET. It is cross checked with the 457 CML by the verifier. Subsequent actions based on the verification 458 failing or succeeding could be taken as per the configured policies. 460 3.3.2. Complete Solution 462 As observed previously, the baseline algorithm that involves a single 463 secret polynomial is not secure. The complete solution leverages a 464 random second polynomial, which is chosen per packet. 466 3.3.2.1. Random Polynomial 468 Let the second polynomial POLY-2 be (RND + 7x + 10 x^2). RND is a 469 random number and is generated for each packet. Note that POLY-2 is 470 public and need not be kept secret. The nodes can be pre-configured 471 with the non-constant coefficients (for example, 7 and 10 in this 472 case could be configured through the Controller on each node). So 473 precisely only the RND value changes per packet and is public and the 474 rest of the non-constant coefficients of POLY-2 is kept secret. 476 3.3.2.2. Reconstruction 478 Recall that each node is preconfigured with their respective 479 Share(POLY-1). Each node calculates its respective Share(POLY-2) 480 using the RND value retrieved from the packet. The CML 481 reconstruction is enhanced as below. At every node, CML is updated 482 as 484 CML = CML+(((Share(POLY-1)+ Share(POLY-2)) * LPC) mod Prime 485 Let us observe the packet level transformations in detail. For the 486 example packet here, let the value RND be 45. Thus POLY-2 would be 487 (45 + 7x + 10x^2). 489 The shares that could be generated are (2, 46), (4, 21), (5, 12). 491 At ingress: The fields RND = 45. CML = 0. 493 At node-1 (x0): Respective share of POLY-2 is generated i.e., (2, 494 46) because share index of node-1 is 2. 496 CML = 0 + ((28 + 46)* 21) mod 53 = 17 498 At node-2 (x1): Respective share of POLY-2 is generated i.e., (4, 499 21) because share index of node-2 is 4. 501 CML = 17 + ((17 + 21)*48) mod 53 = 17 + 22 = 39 503 At node-3 (x2), which is also the verifier: The respective share 504 of POLY-2 is generated i.e., (5, 12) because the share index of 505 the verifier is 12. 507 CML = 39 + ((47 + 12)*38) mod 53 = 39 + 16 = 55 mod 53 = 2 509 The verification using CML is discussed in next section. 511 3.3.2.3. Verification 513 As shown in the above example, for final verification, the verifier 514 compares: 516 VERIFY = (SECRET + RND) mod Prime, with Prime = 53 here 518 VERIFY = (RND-1 + RND-2) mod Prime = ( 10 + 45 ) mod 53 = 2 520 Since VERIFY = CML the packet is proven to have gone through nodes 1, 521 2, and 3. 523 3.3.3. Solution Deployment Considerations 525 The "complete solution" described above in Section 3.3.2 could still 526 be prone to replay or preplay attacks. An attacker could e.g. reuse 527 the POT metadata for bypassing the verification. These threats can 528 be mitigated by appropriate parameterization of the algorithm. 529 Please refer to Section 7 for details. 531 3.4. Operational Aspects 533 To operationalize this scheme, a central controller is used to 534 generate the necessary polynomials, the secret share per node, the 535 prime number, etc. and distributing the data to the nodes 536 participating in proof of transit. The identified node that performs 537 the verification is provided with the verification key. The 538 information provided from the Controller to each of the nodes 539 participating in proof of transit is referred to as a proof of 540 transit profile (POT-Profile). Also note that the set of nodes for 541 which the transit has to be proven are typically associated to a 542 different trust domain than the verifier. Note that building the 543 trust relationship between the Controller and the nodes is outside 544 the scope of this document. Techniques such as those described in 545 [I-D.ietf-anima-autonomic-control-plane] might be applied. 547 To optimize the overall data amount of exchanged and the processing 548 at the nodes the following optimizations are performed: 550 1. The points (x, y) for each of the nodes on the public and private 551 polynomials are picked such that the x component of the points 552 match. This lends to the LPC values which are used to calculate 553 the cumulative value CML to be constant. Note that the LPC are 554 only depending on the x components. They can be computed at the 555 controller and communicated to the nodes. Otherwise, one would 556 need to distributed the x components to all the nodes. 558 2. A pre-evaluated portion of the public polynomial for each of the 559 nodes is calculated and added to the POT-Profile. Without this 560 all the coefficients of the public polynomial had to be added to 561 the POT profile and each node had to evaluate them. As stated 562 before, the public portion is only the constant coefficient RND 563 value, the pre-evaluated portion for each node should be kept 564 secret as well. 566 3. To provide flexibility on the size of the cumulative and random 567 numbers carried in the POT data a field to indicate this is 568 shared and interpreted at the nodes. 570 3.5. Ordered POT (OPOT) 572 POT as discussed in this document so far only verifies that a defined 573 set of nodes have been traversed by a packet. The order in which 574 nodes where traversed is not verified. "Ordered Proof of Transit 575 (OPOT)" addresses the need of deployments, that require to verify the 576 order in which nodes were traversed. OPOT extends the POT scheme 577 with symmetric masking between the nodes. 579 1. For each path the controller provisions all the nodes with (or 580 asks them to agree on) two secrets per node, that we will refer 581 to as masks, one for the connection from the upstream node(s), 582 another for the connection to the downstream node(s). For 583 obvious reasons, the ingress and egress (verifier) nodes only 584 receive one, for downstream and upstream, respectively. 586 2. Any two contiguous nodes in the OPOT stream share the mask for 587 the connection between them, in the shape of symmetric keys. 588 Masks can be refreshed as per-policy, defined at each hop or 589 globally by the controller. 591 3. Each mask has the same size in bits as the length assigned to CML 592 plus RND, as described in the above sections. 594 4. Whenever a packet is received at an intermediate node, the 595 CML+RND sequence is deciphered (by XORing, though other ciphering 596 schemas MAY be possible) with the upstream mask before applying 597 the procedures described in Section 3.3.2. 599 5. Once the new values of CML+RND are produced, they are ciphered 600 (by XORing, though other ciphering schemas MAY be possible) with 601 the downstream mask before transmitting the packet to the next 602 node downstream. 604 6. The ingress node only applies step 5 above, while the verifier 605 only applies step 4 before running the verification procedure. 607 The described process allows the verifier to check if the packet has 608 followed the correct order while traversing the path. In particular, 609 the reconstruction process will fail if the order is not respected, 610 as the deciphering process will produce invalid CML and RND values, 611 and the interpolation (secret reconstruction) will finally generate a 612 wrong verification value. 614 This procedure does not impose a high computational burden, does not 615 require additional packet overhead, can be deployed on chains of any 616 length, does not require any node to be aware of any additional 617 information than the upstream and downstream masks, and can be 618 integrated with the other operational mechanisms applied by the 619 controller to distribute shares and other secret material. 621 4. Sizing the Data for Proof of Transit 623 Proof of transit requires transport of two data fields in every 624 packet that should be verified: 626 1. RND: Random number (the constant coefficient of public 627 polynomial) 629 2. CML: Cumulative 631 The size of the data fields determines how often a new set of 632 polynomials would need to be created. At maximum, the largest RND 633 number that can be represented with a given number of bits determines 634 the number of unique polynomials POLY-2 that can be created. The 635 table below shows the maximum interval for how long a single set of 636 polynomials could last for a variety of bit rates and RND sizes: When 637 choosing 64 bits for RND and CML data fields, the time between a 638 renewal of secrets could be as long as 3,100 years, even when running 639 at 100 Gbps. 641 +===============+=================+================+===============+ 642 | Transfer rate | Secret/RND size | Max # of | Time RND | 643 | | | packets | lasts | 644 +===============+=================+================+===============+ 645 | 1 Gbps | 64 | 2^64 = approx. | approx. | 646 | | | 2*10^19 | 310,000 years | 647 +---------------+-----------------+----------------+---------------+ 648 | 10 Gbps | 64 | 2^64 = approx. | approx. | 649 | | | 2*10^19 | 31,000 years | 650 +---------------+-----------------+----------------+---------------+ 651 | 100 Gbps | 64 | 2^64 = approx. | approx. 3,100 | 652 | | | 2*10^19 | years | 653 +---------------+-----------------+----------------+---------------+ 654 | 1 Gbps | 32 | 2^32 = approx. | 2,200 seconds | 655 | | | 4*10^9 | | 656 +---------------+-----------------+----------------+---------------+ 657 | 10 Gbps | 32 | 2^32 = approx. | 220 seconds | 658 | | | 4*10^9 | | 659 +---------------+-----------------+----------------+---------------+ 660 | 100 Gbps | 32 | 2^32 = approx. | 22 seconds | 661 | | | 4*10^9 | | 662 +---------------+-----------------+----------------+---------------+ 664 Table 1: Proof of transit data sizing 666 Table assumes 64 octet packets 668 If the symmetric masking method for ordered POT is used 669 (Section 3.5), the masks used between nodes adjacent in the path MUST 670 have a length equal to the sum of the ones of RND and CML. 672 5. Node Configuration 674 A POT system consists of a number of nodes that participate in POT 675 and a Controller, which serves as a control and configuration entity. 676 The Controller is to create the required parameters (polynomials, 677 prime number, etc.) and communicate the associated values (i.e. prime 678 number, secret-share, LPC, etc.) to the nodes. The sum of all 679 parameters for a specific node is referred to as "POT-Profile". For 680 details see the YANG model in Section 5.2. This document defines the 681 procedures and the associated YANG data model. 683 5.1. Procedure 685 The Controller creates new POT-Profiles at a constant rate and 686 communicates the POT-Profile to the nodes. The controller labels a 687 POT-Profile "even" or "odd" and the Controller cycles between "even" 688 and "odd" labeled profiles. This means that the parameters for the 689 algorithms are continuously refreshed. Please refer to Section 4 for 690 choosing an appropriate refresh rate: The rate at which the POT- 691 Profiles are communicated to the nodes is configurable and MUST be 692 more frequent than the speed at which a POT-Profile is "used up". 693 Once the POT-Profile has been successfully communicated to all nodes 694 (e.g., all NETCONF transactions completed, in case NETCONF is used as 695 a protocol), the controller sends an "enable POT-Profile" request to 696 the ingress node. 698 All nodes maintain two POT-Profiles (an even and an odd POT-Profile): 699 One POT-Profile is currently active and in use; one profile is 700 standby and about to get used. A flag in the packet is indicating 701 whether the odd or even POT-Profile is to be used by a node. This is 702 to ensure that during profile change the service is not disrupted. 703 If the "odd" profile is active, the Controller can communicate the 704 "even" profile to all nodes. Only if all the nodes have received the 705 POT-Profile, the Controller will tell the ingress node to switch to 706 the "even" profile. Given that the indicator travels within the 707 packet, all nodes will switch to the "even" profile. The "even" 708 profile gets active on all nodes and nodes are ready to receive a new 709 "odd" profile. 711 Unless the ingress node receives a request to switch profiles, it'll 712 continue to use the active profile. If a profile is "used up" the 713 ingress node will recycle the active profile and start over (this 714 could give rise to replay attacks in theory - but with 2^32 or 2^64 715 packets this isn't really likely in reality). 717 5.2. YANG Model for POT 719 This section defines that YANG data model for the information 720 exchange between the Controller and the node. 722 5.2.1. Main Parameters 724 The main parameters for the information exchange between the 725 Controller and the node used in the YANG model are as follows: 727 * pot-profile-index: Section 5.1 details that two POT-Profiles are 728 used. Only one of the POT-Profiles is active at a given point in 729 time, allowing the Controller to refresh the non-active one for 730 future use. pot-profile-index defines which of the POT-Profiles 731 (the "even" or "odd" POT-Profile) is currently active. pot- 732 profile-index will be set in the first hop of the path or chain. 733 Other nodes will not use this field. 735 * prime-number: Prime number used for module math computation. 737 * secret-share: Share of the secret of polynomial-1 used in 738 computation for the node. If POLY-1 is defined by points (x1_i, 739 y1_i) with i=0,..k, then for node i, the secret-share will be 740 y1_i. 742 * public-polynomial: Public polynomial value for the node.. If 743 POLY-2 is defined by points (x2_i, y2_i) with i=0,..k, then for 744 node i, the secret-share will be y2_i. 746 * lpc: Lagrange Polynomial Coefficient for the node, i.e. for node 747 i, this would be LPC(l_i), with l_i being the i-th Lagrange Basis 748 Polynomial. 750 * validator: True if the node is a verifier node. 752 * validator-key: The validator-key represents the SECRET as 753 described in the sections above. The SECRET is the constant 754 coefficient of POLY-1(z). If POLY-1(z) = a_0 + a_1*z + 755 a_2*z^2+..+a_k*z^k, then the SECRET would be a_0. 757 * bitmask: Number of bits as mask used in controlling the size of 758 the random value generation. 32-bits of mask is default. See 759 Section 4 for details. 761 5.2.2. Tree Diagram 763 This section shows a simplified graphical representation of the YANG 764 data model for POT. The meaning of the symbols in YANG tree diagrams 765 is defined in [RFC8340]. 767 module: ietf-pot-profile 768 +--rw pot-profiles 769 +--rw pot-profile-set* [pot-profile-name] 770 +--rw pot-profile-name string 771 +--rw pot-profile-list* [pot-profile-index] 772 +--rw pot-profile-index profile-index-range 773 +--rw status? boolean 774 +--rw prime-number uint64 775 +--rw secret-share uint64 776 +--rw public-polynomial uint64 777 +--rw lpc uint64 778 +--rw validator? boolean 779 +--rw validator-key? uint64 780 +--rw bitmask? uint64 781 +--rw opot-masks 782 +--rw downstream-mask* uint64 783 +--rw upstream-mask* uint64 785 5.2.3. YANG Model 787 file "ietf-pot-profile@2020-09-08.yang" 788 module ietf-pot-profile { 789 yang-version 1.1; 790 namespace "urn:ietf:params:xml:ns:yang:ietf-pot-profile"; 792 prefix "pot"; 794 import ietf-netconf-acm { 795 prefix nacm; 796 reference 797 "RFC 8341: Network Configuration Access Control Model"; 798 } 800 organization "IETF SFC Working Group"; 802 contact "WG Web: 803 WG List: 804 Author : Frank Brockners 805 Author : Shwetha Bhandari 806 Author : Tal Mizrahi "; 808 description 809 "This module contains a collection of YANG 810 definitions for proof of transit configuration 811 parameters. The model is meant for proof of 812 transit and is targeted for communicating the 813 POT-Profile between a controller and nodes 814 participating in proof of transit. 816 Copyright (c) 2020 IETF Trust and the persons identified 817 as authors of the code. All rights reserved. 818 Redistribution and use in source and binary forms, with 819 or without modification, is permitted pursuant to, and 820 subject to the license terms contained in, the Simplified 821 BSD License set forth in Section 4.c of the IETF Trust's 822 Legal Provisions Relating to IETF Documents 823 (https://trustee.ietf.org/license-info). 825 Redistribution and use in source and binary forms, with or 826 without modification, is permitted pursuant to, and subject to 827 the license terms contained in, the Simplified BSD License set 828 forth in Section 4.c of the IETF Trust's Legal Provisions 829 Relating to IETF Documents 830 (https://trustee.ietf.org/license-info). 831 This version of this YANG module is part of RFC XXXX 832 (https://www.rfc-editor.org/info/rfcXXXX); see the RFC 833 itself for full legal notices. 834 The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 835 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 836 'NOT RECOMMENDED', 'MAY', and 'OPTIONAL' in this document 837 are to be interpreted as described in BCP 14 (RFC 2119) 838 (RFC 8174) when, and only when, they appear in all 839 capitals, as shown here."; 841 revision "2020-09-08" { 842 description 843 "Initial revision."; 844 reference 845 "RFC XXXX: Proof of Transit"; 846 } 848 typedef profile-index-range { 849 type int32 { 850 range "0 .. 1"; 851 } 852 description 853 "Range used for the profile index. Currently restricted to 854 0 or 1 to identify the odd or even profiles."; 855 } 856 grouping pot-profile { 857 description "A grouping for proof of transit profiles."; 858 list pot-profile-list { 859 key "pot-profile-index"; 860 ordered-by user; 861 description "A set of pot profiles."; 863 leaf pot-profile-index { 864 type profile-index-range; 865 mandatory true; 866 description 867 "Proof of transit profile index."; 868 } 870 leaf status { 871 type boolean; 872 default "false"; 873 description 874 "True if this profile is currently active. 875 Will be used by the first hop of the path or chain. 876 Other nodes will not use this field."; 877 } 879 leaf prime-number { 880 type uint64; 881 nacm:default-deny-all; 882 mandatory true; 883 description 884 "Prime number used for module math computation"; 885 } 887 leaf secret-share { 888 type uint64; 889 nacm:default-deny-all; 890 mandatory true; 891 description 892 "Share of the secret of polynomial-1 used 893 in computation for the node. If POLY-1 894 is defined by points (x1_i, y1_i) with 895 i=0,..k, then for node i, the secret-share 896 will be y1_i."; 897 } 899 leaf public-polynomial { 900 type uint64; 901 mandatory true; 902 description 903 "Public polynomial value for the node. 905 If POLY-2 is defined by points (x2_i, y2_i) 906 with i=0,..k, then for node i, 907 the secret-share will be y2_i."; 908 } 910 leaf lpc { 911 type uint64; 912 mandatory true; 913 description 914 "Lagrange Polynomial Coefficient"; 915 } 917 leaf validator { 918 type boolean; 919 default "false"; 920 description 921 "True if the node is a verifier node"; 922 } 924 leaf validator-key { 925 type uint64; 926 nacm:default-deny-all; 927 description 928 "The validator-key represents the secret. 929 The secret is the constant coefficient of 930 POLY-1(z). If POLY-1(z) = 931 a_0 + a_1*z + a_2*z^2+..+a_k*z^k, 932 then the SECRET would be a_0."; 933 } 935 leaf bitmask { 936 type uint64; 937 default 4294967295; 938 description 939 "Number of bits as mask used in controlling 940 the size of the random value generation. 941 32-bits of mask is default."; 942 } 944 uses opot-profile; 946 } 947 } 949 grouping opot-profile { 950 description "Grouping containing OPoT related data."; 951 container opot-masks { 952 must "count(downstream-mask) = count(upstream-mask)"; 953 description "Masking information for OPoT support."; 955 leaf-list downstream-mask { 956 type uint64; 957 max-elements 2; 958 description "Secret stream used to demask the PoT metadata. 959 The mask is used between nodes adjacent in the path 960 and MUST have a length equal to the sum of the ones 961 of RND and CML."; 962 } 964 leaf-list upstream-mask { 965 type uint64; 966 max-elements 2; 967 description "Secret stream used to mask the PoT metadata. 968 The mask is used between nodes adjacent in the path 969 and MUST have a length equal to the sum of the ones 970 of RND and CML."; 971 } 972 } 973 } 975 container pot-profiles { 976 description "A group of proof of transit profiles."; 978 list pot-profile-set { 979 key "pot-profile-name"; 980 ordered-by user; 981 description 982 "Set of proof of transit profiles that group parameters 983 required to classify and compute proof of transit 984 metadata at a node"; 986 leaf pot-profile-name { 987 type string; 988 mandatory true; 989 description 990 "Unique identifier for each proof of transit profile"; 991 } 993 uses pot-profile; 994 } 995 /*** Container: end ***/ 996 } 997 /*** module: end ***/ 998 } 999 1001 6. IANA Considerations 1003 This document registers a URI in the IETF XML registry [RFC3688]. 1004 Following the format in IETF XML Registry [RFC3688], the following 1005 registration is requested to be made. 1007 URI: urn:ietf:params:xml:ns:yang:ietf-pot-profile 1009 Registrant Contact: The IESG. 1011 XML: N/A, the requested URI is an XML namespace. 1013 IANA is requested to register the following YANG module in the "YANG 1014 Module Names" subregistry [RFC7950] within the "YANG Parameters" 1015 registry. 1017 Name: ietf-pot-profile 1019 Maintained by IANA: N 1021 Namespace: urn:ietf:params:xml:ns:yang:ietf-pot-profile 1023 Prefix: pot 1025 Reference: RFC XXXX 1027 7. Security Considerations 1029 POT is a mechanism that is used for verifying the path through which 1030 a packet was forwarded. The security considerations of IOAM in 1031 general are discussed in [I-D.ietf-ippm-ioam-data]. Specifically, it 1032 is assumed that POT is used in a confined network domain, and 1033 therefore the potential threats that POT is intended to mitigate 1034 should be viewed accordingly. POT prevents spoofing and tampering; 1035 an attacker cannot maliciously create a bogus POT or modify a 1036 legitimate one. Furthermore, a legitimate node that takes part in 1037 the POT protocol cannot masquerade as another node along the path. 1038 These considerations are discussed in detail in the rest of this 1039 section. 1041 7.1. Proof of Transit 1043 Proof of correctness and security of the solution approach is per 1044 Shamir's Secret Sharing Scheme [SSS]. Cryptographically speaking it 1045 achieves information-theoretic security i.e., it cannot be broken by 1046 an attacker even with unlimited computing power. As long as the 1047 below conditions are met it is impossible for an attacker to bypass 1048 one or multiple nodes without getting caught. 1050 * If there are k+1 nodes in the path, the polynomials (POLY-1, POLY- 1051 2) should be of degree k. Also k+1 points of POLY-1 are chosen 1052 and assigned to each node respectively. The verifier can re- 1053 construct the k degree polynomial (POLY-3) only when all the 1054 points are correctly retrieved. 1056 * Precisely three values are kept secret by individual nodes. Share 1057 of SECRET (i.e. points on POLY-1), Share of POLY-2, LPC, P. Note 1058 that only constant coefficient, RND, of POLY-2 is public. x values 1059 and non-constant coefficient of POLY-2 are secret 1061 An attacker bypassing a few nodes will miss adding a respective point 1062 on POLY-1 to corresponding point on POLY-2 , thus the verifier cannot 1063 construct POLY-3 for cross verification. 1065 Also it is highly recommended that different polynomials should be 1066 used as POLY-1 across different paths, traffic profiles or service 1067 chains. 1069 If symmetric masking is used to assure OPOT (Section 3.5), the nodes 1070 need to keep two additional secrets: the downstream and upstream 1071 masks, that have to be managed under the same conditions as the 1072 secrets mentioned above. And it is equally recommended to employ a 1073 different set of mask pairs across different paths, traffic profiles 1074 or service chains. 1076 7.2. Cryptanalysis 1078 A passive attacker could try to harvest the POT data (i.e., CML, RND 1079 values) in order to determine the configured secrets. Subsequently 1080 two types of differential analysis for guessing the secrets could be 1081 done. 1083 * Inter-Node: A passive attacker observing CML values across nodes 1084 (i.e., as the packets entering and leaving), cannot perform 1085 differential analysis to construct the points on POLY-1. This is 1086 because at each point there are four unknowns (i.e. Share(POLY- 1087 1), Share(Poly-2) LPC and prime number P) and three known values 1088 (i.e. RND, CML-before, CML-after). The application of symmetric 1089 masking for OPOT makes inter-node analysis less feasible. 1091 * Inter-Packets: A passive attacker could observe CML values across 1092 packets (i.e., values of PKT-1 and subsequent PKT-2), in order to 1093 predict the secrets. Differential analysis across packets could 1094 be mitigated using a good PRNG for generating RND. Note that if 1095 constant coefficient is a sequence number than CML values become 1096 quite predictable and the scheme would be broken. If symmetric 1097 masking is used for OPOT, inter-packet analysis could be applied 1098 to guess mask values, which requires a proper refresh rate for 1099 masks, at least as high as the one used for LPCs. 1101 7.3. Anti-Replay 1103 A passive attacker could reuse a set of older RND and the 1104 intermediate CML values. Thus, an attacker can attack an old 1105 (replayed) RND and CML with a new packet in order to bypass some of 1106 the nodes along the path. 1108 Such attacks could be avoided by carefully choosing POLY-2 as a 1109 (SEQ_NO + RND). For example, if 64 bits are being used for POLY-2 1110 then first 16 bits could be a sequence number SEQ_NO and next 48 bits 1111 could be a random number. 1113 Subsequently, the verifier could use the SEQ_NO bits to run classic 1114 anti-replay techniques like sliding window used in IPSEC. The 1115 verifier could buffer up to 2^16 packets as a sliding window. 1116 Packets arriving with a higher SEQ_NO than current buffer could be 1117 flagged legitimate. Packets arriving with a lower SEQ_NO than 1118 current buffer could be flagged as suspicious. 1120 For all practical purposes in the rest of the document RND means 1121 SEQ_NO + RND to keep it simple. 1123 The solution discussed in this memo does not currently mitigate 1124 replay attacks. An anti-replay mechanism may be included in future 1125 versions of the solution. 1127 7.4. Anti-Preplay 1129 An active attacker could try to perform a man-in-the-middle (MITM) 1130 attack by extracting the POT of PKT-1 and using it in PKT-2. 1131 Subsequently attacker drops the PKT-1 in order to avoid duplicate POT 1132 values reaching the verifier. If the PKT-1 reaches the verifier, 1133 then this attack is same as Replay attacks discussed before. 1135 Preplay attacks are possible since the POT metadata is not dependent 1136 on the packet fields. Below steps are recommended for remediation: 1138 * Ingress node and Verifier are configured with common pre shared 1139 key 1141 * Ingress node generates a Message Authentication Code (MAC) from 1142 packet fields using standard HMAC algorithm. 1144 * The left most bits of the output are truncated to desired length 1145 to generate RND. It is recommended to use a minimum of 32 bits. 1147 * The verifier regenerates the HMAC from the packet fields and 1148 compares with RND. To ensure the POT data is in fact that of the 1149 packet. 1151 If an HMAC is used, an active attacker lacks the knowledge of the 1152 pre-shared key, and thus cannot launch preplay attacks. 1154 The solution discussed in this memo does not currently mitigate 1155 preplay attacks. A mitigation mechanism may be included in future 1156 versions of the solution. 1158 7.5. Tampering 1160 An active attacker could not insert any arbitrary value for CML. 1161 This would subsequently fail the reconstruction of the POLY-3. Also 1162 an attacker could not update the CML with a previously observed 1163 value. This could subsequently be detected by using timestamps 1164 within the RND value as discussed above. 1166 7.6. Recycling 1168 The solution approach is flexible for recycling long term secrets 1169 like POLY-1. All the nodes could be periodically updated with shares 1170 of new SECRET as best practice. The table above could be consulted 1171 for refresh cycles (see Section 4). 1173 If symmetric masking is used for OPOT (Section 3.5), mask values must 1174 be periodically updated as well, at least as frequently as the other 1175 secrets are. 1177 7.7. Redundant Nodes and Failover 1179 A "node" or "service" in terms of POT can be implemented by one or 1180 multiple physical entities. In case of multiple physical entities 1181 (e.g., for load-balancing, or business continuity situations - 1182 consider for example a set of firewalls), all physical entities which 1183 are implementing the same POT node are given that same share of the 1184 secret. This makes multiple physical entities represent the same POT 1185 node from an algorithm perspective. 1187 7.8. Controller Operation 1189 The Controller needs to be secured given that it creates and holds 1190 the secrets, as need to be the nodes. The communication between 1191 Controller and the nodes also needs to be secured. As secure 1192 communication protocol such as for example NETCONF over SSH should be 1193 chosen for Controller to node communication. 1195 The Controller only interacts with the nodes during the initial 1196 configuration and thereafter at regular intervals at which the 1197 operator chooses to switch to a new set of secrets. In case 64 bits 1198 are used for the data fields "CML" and "RND" which are carried within 1199 the data packet, the regular intervals are expected to be quite long 1200 (e.g., at 100 Gbps, a profile would only be used up after 3100 years) 1201 - see Section 4 above, thus even a "headless" operation without a 1202 Controller can be considered feasible. In such a case, the 1203 Controller would only be used for the initial configuration of the 1204 POT-Profiles. 1206 If OPOT (Section 3.5) is applied using symmetric masking, the 1207 Controller will be required to perform a a periodic refresh of the 1208 mask pairs. The use of OPOT SHOULD be configurable as part of the 1209 required level of assurance through the Controller management 1210 interface. 1212 7.9. Verification Scope 1214 The POT solution defined in this document verifies that a data-packet 1215 traversed or transited a specific set of nodes. From an algorithm 1216 perspective, a "node" is an abstract entity. It could be represented 1217 by one or multiple physical or virtual network devices, or is could 1218 be a component within a networking device or system. The latter 1219 would be the case if a forwarding path within a device would need to 1220 be securely verified. 1222 7.9.1. Node Ordering 1224 POT using Shamir's Secret Sharing scheme as discussed in this 1225 document provides for a means to verify that a set of nodes has been 1226 visited by a data packet. It does not verify the order in which the 1227 data packet visited the nodes. 1229 In case the order in which a data packet traversed a particular set 1230 of nodes needs to be verified as well, the alternate schemes related 1231 to OPOT (Section 3.5) have to be considered. Since these schemes 1232 introduce at least additional control requirements, the selection of 1233 order verification SHOULD be configurable the Controller management 1234 interface. 1236 7.9.2. Stealth Nodes 1238 The POT approach discussed in this document is to prove that a data 1239 packet traversed a specific set of "nodes". This set could be all 1240 nodes within a path, but could also be a subset of nodes in a path. 1241 Consequently, the POT approach isn't suited to detect whether 1242 "stealth" nodes which do not participate in proof-of-transit have 1243 been inserted into a path. 1245 7.10. POT Yang module 1247 The YANG module specified in Section 5.2 of this document defines a 1248 schema for data that is designed to be accessed via network 1249 management protocols such as NETCONF [RFC6241] or RESTCONF [RFC8040]. 1250 The lowest NETCONF [RFC6241] layer is the secure transport layer, and 1251 the mandatory-to-implement secure transport is Secure Shell (SSH) 1252 [RFC6242]. The lowest RESTCONF layer is HTTPS, and the mandatory-to- 1253 implement secure transport is TLS [RFC5246]. 1255 The NETCONF Access Control Module (NACM) [RFC8341] provides the means 1256 to restrict access for particular NETCONF or RESTCONF users to a 1257 preconfigured subset of all available NETCONF or RESTCONF protocol 1258 operations and content. The nodes defined in this YANG module to 1259 specify secret-share, prime-number, and validator-key are read/ 1260 writeable. These data nodes are considered sensitive and vulnerable 1261 to attacks in some network environments. Ability to read from or 1262 write into these nodes without proper protection can have a negative 1263 effect on the devices that support this feature. 1265 8. Acknowledgements 1267 The authors would like to thank Eric Vyncke, Nalini Elkins, Srihari 1268 Raghavan, Ranganathan T S, Karthik Babu Harichandra Babu, Akshaya 1269 Nadahalli, Erik Nordmark, Andrew Yourtchenko, Tom Petch, Mohamed 1270 Boucadair and Dhruv Dhody for the comments and advice. 1272 9. Contributors 1274 In addition to editors and authors listed on the title page, the 1275 following people have contributed substantially to this document and 1276 should be considered coauthors: 1278 Carlos Pignataro 1279 Cisco Systems, Inc. 1280 7200-11 Kit Creek Road 1281 Research Triangle Park, NC 27709 1282 United States 1283 Email: cpignata@cisco.com 1285 John Leddy 1286 Email: john@leddy.net 1288 David Mozes 1289 Email: mosesster@gmail.com 1291 Alejandro Aguado 1292 Universidad Politecnica de Madrid 1293 Campus Montegancedo, Boadilla del Monte 1294 Madrid 28660 1295 Spain 1296 Phone: +34 910 673 086 1297 Email: a.aguadom@fi.upm.es 1299 Diego R. Lopez 1300 Telefonica I+D 1301 Editor Jose Manuel Lara, 9 (1-B) 1302 Seville 41013 1303 Spain 1304 Phone: +34 913 129 041 1305 Email: diego.r.lopez@telefonica.com 1307 10. References 1309 10.1. Normative References 1311 [I-D.ietf-ippm-ioam-data] 1312 Brockners, F., Bhandari, S., and T. Mizrahi, "Data Fields 1313 for In-situ OAM", Work in Progress, Internet-Draft, draft- 1314 ietf-ippm-ioam-data-10, 13 July 2020, 1315 . 1318 [I-D.ietf-sfc-ioam-nsh] 1319 Brockners, F. and S. Bhandari, "Network Service Header 1320 (NSH) Encapsulation for In-situ OAM (IOAM) Data", Work in 1321 Progress, Internet-Draft, draft-ietf-sfc-ioam-nsh-04, 16 1322 June 2020, . 1325 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1326 Requirement Levels", BCP 14, RFC 2119, 1327 DOI 10.17487/RFC2119, March 1997, 1328 . 1330 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 1331 DOI 10.17487/RFC3688, January 2004, 1332 . 1334 [RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function 1335 Chaining (SFC) Architecture", RFC 7665, 1336 DOI 10.17487/RFC7665, October 2015, 1337 . 1339 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 1340 RFC 7950, DOI 10.17487/RFC7950, August 2016, 1341 . 1343 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1344 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1345 May 2017, . 1347 [RFC8300] Quinn, P., Ed., Elzur, U., Ed., and C. Pignataro, Ed., 1348 "Network Service Header (NSH)", RFC 8300, 1349 DOI 10.17487/RFC8300, January 2018, 1350 . 1352 [SSS] A., S., "How to share a secret", Communications of the 1353 ACM (22): 612-613, 1979. 1355 10.2. Informative References 1357 [I-D.ietf-anima-autonomic-control-plane] 1358 Eckert, T., Behringer, M., and S. Bjarnason, "An Autonomic 1359 Control Plane (ACP)", Work in Progress, Internet-Draft, 1360 draft-ietf-anima-autonomic-control-plane-18, 7 August 1361 2018, . 1364 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 1365 (TLS) Protocol Version 1.2", RFC 5246, 1366 DOI 10.17487/RFC5246, August 2008, 1367 . 1369 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 1370 and A. Bierman, Ed., "Network Configuration Protocol 1371 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 1372 . 1374 [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure 1375 Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011, 1376 . 1378 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 1379 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, 1380 . 1382 [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", 1383 BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, 1384 . 1386 [RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration 1387 Access Control Model", STD 91, RFC 8341, 1388 DOI 10.17487/RFC8341, March 2018, 1389 . 1391 [RFC8342] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K., 1392 and R. Wilton, "Network Management Datastore Architecture 1393 (NMDA)", RFC 8342, DOI 10.17487/RFC8342, March 2018, 1394 . 1396 Authors' Addresses 1398 Frank Brockners (editor) 1399 Cisco Systems, Inc. 1400 Hansaallee 249, 3rd Floor 1401 40549 DUESSELDORF 1402 Germany 1404 Email: fbrockne@cisco.com 1405 Shwetha Bhandari (editor) 1406 Thoughtspot 1407 3rd Floor, Indiqube Orion, 24th Main Rd, Garden Layout, HSR Layout 1408 Bangalore, KARNATAKA 560 102 1409 India 1411 Email: shwetha.bhandari@thoughtspot.com 1413 Tal Mizrahi (editor) 1414 Huawei Network.IO Innovation Lab 1415 Israel 1417 Email: tal.mizrahi.phd@gmail.com 1419 Sashank Dara 1420 Seconize 1421 BANGALORE 1422 Bangalore, KARNATAKA 1423 India 1425 Email: sashank@seconize.co 1427 Stephen Youell 1428 JP Morgan Chase 1429 25 Bank Street 1430 London 1431 E14 5JP 1432 United Kingdom 1434 Email: stephen.youell@jpmorgan.com