draft-ietf-sfc-proof-of-transit-02.txt | draft-ietf-sfc-proof-of-transit-03.txt | |||
---|---|---|---|---|

Network Working Group F. Brockners | Network Working Group F. Brockners, Ed. | |||

Internet-Draft S. Bhandari | Internet-Draft S. Bhandari, Ed. | |||

Intended status: Experimental Cisco | Intended status: Experimental Cisco | |||

Expires: September 12, 2019 S. Dara | Expires: March 14, 2020 T. Mizrahi, Ed. | |||

Huawei Network.IO Innovation Lab | ||||

S. Dara | ||||

Seconize | Seconize | |||

C. Pignataro | ||||

Cisco | ||||

J. Leddy | ||||

Comcast | ||||

S. Youell | S. Youell | |||

JPMC | JPMC | |||

D. Mozes | September 11, 2019 | |||

T. Mizrahi | ||||

Huawei Network.IO Innovation Lab | ||||

A. Aguado | ||||

Universidad Politecnica de Madrid | ||||

D. Lopez | ||||

Telefonica I+D | ||||

March 11, 2019 | ||||

Proof of Transit | Proof of Transit | |||

draft-ietf-sfc-proof-of-transit-02 | draft-ietf-sfc-proof-of-transit-03 | |||

Abstract | Abstract | |||

Several technologies such as Traffic Engineering (TE), Service | Several technologies such as Traffic Engineering (TE), Service | |||

Function Chaining (SFC), and policy based routing are used to steer | Function Chaining (SFC), and policy based routing are used to steer | |||

traffic through a specific, user-defined path. This document defines | traffic through a specific, user-defined path. This document defines | |||

mechanisms to securely prove that traffic transited said defined | mechanisms to securely prove that traffic transited said defined | |||

path. These mechanisms allow to securely verify whether, within a | path. These mechanisms allow to securely verify whether, within a | |||

given path, all packets traversed all the nodes that they are | given path, all packets traversed all the nodes that they are | |||

supposed to visit. | supposed to visit. | |||

Status of This Memo | Status of This Memo | |||

This Internet-Draft is submitted in full conformance with the | This Internet-Draft is submitted in full conformance with the | |||

provisions of BCP 78 and BCP 79. | provisions of BCP 78 and BCP 79. | |||

Internet-Drafts are working documents of the Internet Engineering | Internet-Drafts are working documents of the Internet Engineering | |||

Task Force (IETF). Note that other groups may also distribute | Task Force (IETF). Note that other groups may also distribute | |||

working documents as Internet-Drafts. The list of current Internet- | working documents as Internet-Drafts. The list of current Internet- | |||

Drafts is at http://datatracker.ietf.org/drafts/current/. | Drafts is at https://datatracker.ietf.org/drafts/current/. | |||

Internet-Drafts are draft documents valid for a maximum of six months | Internet-Drafts are draft documents valid for a maximum of six months | |||

and may be updated, replaced, or obsoleted by other documents at any | and may be updated, replaced, or obsoleted by other documents at any | |||

time. It is inappropriate to use Internet-Drafts as reference | time. It is inappropriate to use Internet-Drafts as reference | |||

material or to cite them other than as "work in progress." | material or to cite them other than as "work in progress." | |||

This Internet-Draft will expire on September 12, 2019. | This Internet-Draft will expire on March 14, 2020. | |||

Copyright Notice | Copyright Notice | |||

Copyright (c) 2019 IETF Trust and the persons identified as the | Copyright (c) 2019 IETF Trust and the persons identified as the | |||

document authors. All rights reserved. | document authors. All rights reserved. | |||

This document is subject to BCP 78 and the IETF Trust's Legal | This document is subject to BCP 78 and the IETF Trust's Legal | |||

Provisions Relating to IETF Documents | Provisions Relating to IETF Documents | |||

(http://trustee.ietf.org/license-info) in effect on the date of | (https://trustee.ietf.org/license-info) in effect on the date of | |||

publication of this document. Please review these documents | publication of this document. Please review these documents | |||

carefully, as they describe your rights and restrictions with respect | carefully, as they describe your rights and restrictions with respect | |||

to this document. Code Components extracted from this document must | to this document. Code Components extracted from this document must | |||

include Simplified BSD License text as described in Section 4.e of | include Simplified BSD License text as described in Section 4.e of | |||

the Trust Legal Provisions and are provided without warranty as | the Trust Legal Provisions and are provided without warranty as | |||

described in the Simplified BSD License. | described in the Simplified BSD License. | |||

Table of Contents | Table of Contents | |||

1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 | 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 | |||

2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 4 | 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 4 | |||

3. Proof of Transit . . . . . . . . . . . . . . . . . . . . . . 5 | 3. Proof of Transit . . . . . . . . . . . . . . . . . . . . . . 5 | |||

3.1. Basic Idea . . . . . . . . . . . . . . . . . . . . . . . 6 | 3.1. Basic Idea . . . . . . . . . . . . . . . . . . . . . . . 5 | |||

3.2. Solution Approach . . . . . . . . . . . . . . . . . . . . 7 | 3.2. Solution Approach . . . . . . . . . . . . . . . . . . . . 6 | |||

3.2.1. Setup . . . . . . . . . . . . . . . . . . . . . . . . 7 | 3.2.1. Setup . . . . . . . . . . . . . . . . . . . . . . . . 7 | |||

3.2.2. In Transit . . . . . . . . . . . . . . . . . . . . . 7 | 3.2.2. In Transit . . . . . . . . . . . . . . . . . . . . . 7 | |||

3.2.3. Verification . . . . . . . . . . . . . . . . . . . . 8 | 3.2.3. Verification . . . . . . . . . . . . . . . . . . . . 8 | |||

3.3. Illustrative Example . . . . . . . . . . . . . . . . . . 8 | 3.3. Illustrative Example . . . . . . . . . . . . . . . . . . 8 | |||

3.3.1. Baseline . . . . . . . . . . . . . . . . . . . . . . 8 | 3.3.1. Baseline . . . . . . . . . . . . . . . . . . . . . . 8 | |||

3.3.1.1. Secret Shares . . . . . . . . . . . . . . . . . . 8 | 3.3.1.1. Secret Shares . . . . . . . . . . . . . . . . . . 8 | |||

3.3.1.2. Lagrange Polynomials . . . . . . . . . . . . . . 9 | 3.3.1.2. Lagrange Polynomials . . . . . . . . . . . . . . 9 | |||

3.3.1.3. LPC Computation . . . . . . . . . . . . . . . . . 9 | 3.3.1.3. LPC Computation . . . . . . . . . . . . . . . . . 9 | |||

3.3.1.4. Reconstruction . . . . . . . . . . . . . . . . . 9 | 3.3.1.4. Reconstruction . . . . . . . . . . . . . . . . . 9 | |||

3.3.1.5. Verification . . . . . . . . . . . . . . . . . . 10 | 3.3.1.5. Verification . . . . . . . . . . . . . . . . . . 10 | |||

3.3.2. Complete Solution . . . . . . . . . . . . . . . . . . 10 | 3.3.2. Complete Solution . . . . . . . . . . . . . . . . . . 10 | |||

3.3.2.1. Random Polynomial . . . . . . . . . . . . . . . . 10 | 3.3.2.1. Random Polynomial . . . . . . . . . . . . . . . . 10 | |||

3.3.2.2. Reconstruction . . . . . . . . . . . . . . . . . 10 | 3.3.2.2. Reconstruction . . . . . . . . . . . . . . . . . 10 | |||

3.3.2.3. Verification . . . . . . . . . . . . . . . . . . 11 | 3.3.2.3. Verification . . . . . . . . . . . . . . . . . . 11 | |||

3.3.3. Solution Deployment Considerations . . . . . . . . . 11 | 3.3.3. Solution Deployment Considerations . . . . . . . . . 11 | |||

3.4. Operational Aspects . . . . . . . . . . . . . . . . . . . 12 | 3.4. Operational Aspects . . . . . . . . . . . . . . . . . . . 12 | |||

3.5. Ordered POT (OPOT) . . . . . . . . . . . . . . . . . . . 12 | 3.5. Ordered POT (OPOT) . . . . . . . . . . . . . . . . . . . 12 | |||

4. Sizing the Data for Proof of Transit . . . . . . . . . . . . 13 | 4. Sizing the Data for Proof of Transit . . . . . . . . . . . . 13 | |||

5. Node Configuration . . . . . . . . . . . . . . . . . . . . . 14 | 5. Node Configuration . . . . . . . . . . . . . . . . . . . . . 14 | |||

5.1. Procedure . . . . . . . . . . . . . . . . . . . . . . . . 15 | 5.1. Procedure . . . . . . . . . . . . . . . . . . . . . . . . 15 | |||

5.2. YANG Model . . . . . . . . . . . . . . . . . . . . . . . 15 | 5.2. YANG Model for POT . . . . . . . . . . . . . . . . . . . 15 | |||

5.2.1. Main Parameters . . . . . . . . . . . . . . . . . . . 16 | ||||

6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 | 5.2.2. Tree Diagram . . . . . . . . . . . . . . . . . . . . 16 | |||

7. Manageability Considerations . . . . . . . . . . . . . . . . 18 | 5.2.3. YANG Model . . . . . . . . . . . . . . . . . . . . . 17 | |||

8. Security Considerations . . . . . . . . . . . . . . . . . . . 19 | 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 | |||

8.1. Proof of Transit . . . . . . . . . . . . . . . . . . . . 19 | 7. Security Considerations . . . . . . . . . . . . . . . . . . . 20 | |||

8.2. Cryptanalysis . . . . . . . . . . . . . . . . . . . . . . 20 | 7.1. Proof of Transit . . . . . . . . . . . . . . . . . . . . 21 | |||

8.3. Anti-Replay . . . . . . . . . . . . . . . . . . . . . . . 20 | 7.2. Cryptanalysis . . . . . . . . . . . . . . . . . . . . . . 21 | |||

8.4. Anti-Preplay . . . . . . . . . . . . . . . . . . . . . . 21 | 7.3. Anti-Replay . . . . . . . . . . . . . . . . . . . . . . . 22 | |||

8.5. Tampering . . . . . . . . . . . . . . . . . . . . . . . . 21 | 7.4. Anti-Preplay . . . . . . . . . . . . . . . . . . . . . . 23 | |||

8.6. Recycling . . . . . . . . . . . . . . . . . . . . . . . . 21 | 7.5. Tampering . . . . . . . . . . . . . . . . . . . . . . . . 23 | |||

8.7. Redundant Nodes and Failover . . . . . . . . . . . . . . 22 | 7.6. Recycling . . . . . . . . . . . . . . . . . . . . . . . . 23 | |||

8.8. Controller Operation . . . . . . . . . . . . . . . . . . 22 | 7.7. Redundant Nodes and Failover . . . . . . . . . . . . . . 24 | |||

8.9. Verification Scope . . . . . . . . . . . . . . . . . . . 22 | 7.8. Controller Operation . . . . . . . . . . . . . . . . . . 24 | |||

8.9.1. Node Ordering . . . . . . . . . . . . . . . . . . . . 23 | 7.9. Verification Scope . . . . . . . . . . . . . . . . . . . 24 | |||

8.9.2. Stealth Nodes . . . . . . . . . . . . . . . . . . . . 23 | 7.9.1. Node Ordering . . . . . . . . . . . . . . . . . . . . 25 | |||

9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 23 | 7.9.2. Stealth Nodes . . . . . . . . . . . . . . . . . . . . 25 | |||

10. References . . . . . . . . . . . . . . . . . . . . . . . . . 23 | 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 25 | |||

10.1. Normative References . . . . . . . . . . . . . . . . . . 23 | 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 25 | |||

10.2. Informative References . . . . . . . . . . . . . . . . . 24 | 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 26 | |||

Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24 | 10.1. Normative References . . . . . . . . . . . . . . . . . . 26 | |||

10.2. Informative References . . . . . . . . . . . . . . . . . 27 | ||||

Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27 | ||||

1. Introduction | 1. Introduction | |||

Several deployments use Traffic Engineering, policy routing, Segment | Several deployments use Traffic Engineering, policy routing, Segment | |||

Routing (SR), and Service Function Chaining (SFC) [RFC7665] to steer | Routing (SR), and Service Function Chaining (SFC) [RFC7665] to steer | |||

packets through a specific set of nodes. In certain cases, | packets through a specific set of nodes. In certain cases, | |||

regulatory obligations or a compliance policy require operators to | regulatory obligations or a compliance policy require operators to | |||

prove that all packets that are supposed to follow a specific path | prove that all packets that are supposed to follow a specific path | |||

are indeed being forwarded across and exact set of pre-determined | are indeed being forwarded across and exact set of pre-determined | |||

nodes. | nodes. | |||

skipping to change at page 5, line 4 ¶ | skipping to change at page 4, line 45 ¶ | |||

LISP: Locator/ID Separation Protocol | LISP: Locator/ID Separation Protocol | |||

LPC: Lagrange Polynomial Constants | LPC: Lagrange Polynomial Constants | |||

MTU: Maximum Transmit Unit | MTU: Maximum Transmit Unit | |||

NFV: Network Function Virtualization | NFV: Network Function Virtualization | |||

NSH: Network Service Header | NSH: Network Service Header | |||

POT: Proof of Transit | POT: Proof of Transit | |||

POT-profile: Proof of Transit Profile that has the necessary data | POT-Profile: Proof of Transit Profile that has the necessary data | |||

for nodes to participate in proof of transit | for nodes to participate in proof of transit | |||

RND: Random Bits generated per packet. Packet fields that do | RND: Random Bits generated per packet. Packet fields that do | |||

not change during the traversal are given as input to | not change during the traversal are given as input to | |||

HMAC-256 algorithm. A minimum of 32 bits (left most) need | HMAC-256 algorithm. A minimum of 32 bits (left most) need | |||

to be used from the output if RND is used to verify the | to be used from the output if RND is used to verify the | |||

packet integrity. This is a standard recommendation by | packet integrity. This is a standard recommendation by | |||

NIST. | NIST. | |||

SEQ_NO: Sequence number initialized to a predefined constant. | SEQ_NO: Sequence number initialized to a predefined constant. | |||

skipping to change at page 7, line 39 ¶ | skipping to change at page 7, line 27 ¶ | |||

ranges. Please refer to the YANG model in Section 5.2 for details on | ranges. Please refer to the YANG model in Section 5.2 for details on | |||

the units and ranges of possible values of the different parameters | the units and ranges of possible values of the different parameters | |||

and coefficients. | and coefficients. | |||

3.2.1. Setup | 3.2.1. Setup | |||

A controller generates a first polynomial (POLY-1) of degree k and | A controller generates a first polynomial (POLY-1) of degree k and | |||

k+1 points on the polynomial, corresponding to the k+1 nodes along | k+1 points on the polynomial, corresponding to the k+1 nodes along | |||

the path. The constant coefficient of POLY-1 is considered the | the path. The constant coefficient of POLY-1 is considered the | |||

SECRET, which is per the definition of the SSSS algorithm [SSS]. The | SECRET, which is per the definition of the SSSS algorithm [SSS]. The | |||

non-constant coefficients are used to generate the Lagrange | k+1 points are used to derive the Lagrange Basis Polynomials. The | |||

Polynomial Constants (LPC). Each of the k+1 nodes (including | Lagrange Polynomial Constants (LPC) are retrieved from the constant | |||

verifier) are assigned a point on the polynomial i.e., shares of the | coefficients of the Lagrange Basis Polynomials. Each of the k+1 | |||

SECRET. The verifier is configured with the SECRET. The Controller | nodes (including verifier) are assigned a point on the polynomial | |||

also generates coefficients (except the constant coefficient, called | i.e., shares of the SECRET. The verifier is configured with the | |||

"RND", which is changed on a per packet basis) of a second polynomial | SECRET. The Controller also generates coefficients (except the | |||

POLY-2 of the same degree. Each node is configured with the LPC of | constant coefficient, called "RND", which is changed on a per packet | |||

POLY-2. Note that POLY-2 is public. | basis) of a second polynomial POLY-2 of the same degree. Each node | |||

is configured with the LPC of POLY-2. Note that POLY-2 is public. | ||||

3.2.2. In Transit | 3.2.2. In Transit | |||

For each packet, the ingress node generates a random number (RND). | For each packet, the ingress node generates a random number (RND). | |||

It is considered as the constant coefficient for POLY-2. A | It is considered as the constant coefficient for POLY-2. A | |||

cumulative value (CML) is initialized to 0. Both RND, CML are | cumulative value (CML) is initialized to 0. Both RND, CML are | |||

carried as within the packet POT data. As the packet visits each | carried as within the packet POT data. As the packet visits each | |||

node, the RND is retrieved from the packet and the respective share | node, the RND is retrieved from the packet and the respective share | |||

of POLY-2 is calculated. Each node calculates (Share(POLY-1) + | of POLY-2 is calculated. Each node calculates (Share(POLY-1) + | |||

Share(POLY-2)) and CML is updated with this sum, specifically each | Share(POLY-2)) and CML is updated with this sum, specifically each | |||

skipping to change at page 9, line 17 ¶ | skipping to change at page 9, line 12 ¶ | |||

considered the shares of the secret. They are assigned by the | considered the shares of the secret. They are assigned by the | |||

Controller to three nodes respectively and are kept secret. | Controller to three nodes respectively and are kept secret. | |||

3.3.1.2. Lagrange Polynomials | 3.3.1.2. Lagrange Polynomials | |||

Lagrange basis polynomials (or Lagrange polynomials) are used for | Lagrange basis polynomials (or Lagrange polynomials) are used for | |||

polynomial interpolation. For a given set of points on the curve | polynomial interpolation. For a given set of points on the curve | |||

Lagrange polynomials (as defined below) are used to reconstruct the | Lagrange polynomials (as defined below) are used to reconstruct the | |||

curve and thus reconstruct the complete secret. | curve and thus reconstruct the complete secret. | |||

l0(x) = (((x-x1) / (x0-x1)) * ((x-x2)/x0-x2))) mod 53 = | l0(x) = (((x-x1) / (x0-x1)) * ((x-x2)/x0-x2))) mod 53 | |||

(((x-4) / (2-4)) * ((x-5)/2-5))) mod 53 = | = (((x-4) / (2-4)) * ((x-5)/2-5))) mod 53 | |||

(10/3 - 3x/2 + (1/6)x^2) mod 53 | = (10/3 - 3x/2 + (1/6)x^2) mod 53 | |||

l1(x) = (((x-x0) / (x1-x0)) * ((x-x2)/x1-x2))) mod 53 = | l1(x) = (((x-x0) / (x1-x0)) * ((x-x2)/x1-x2))) mod 53 | |||

(-5 + 7x/2 - (1/2)x^2) mod 53 | = (-5 + 7x/2 - (1/2)x^2) mod 53 | |||

l2(x) = (((x-x0) / (x2-x0)) * ((x-x1)/x2-x1))) mod 53 = | l2(x) = (((x-x0) / (x2-x0)) * ((x-x1)/x2-x1))) mod 53 | |||

(8/3 - 2 + (1/3)x^2) mod 53 | = (8/3 - 2 + (1/3)x^2) mod 53 | |||

3.3.1.3. LPC Computation | 3.3.1.3. LPC Computation | |||

Since x0=2, x1=4, x2=5 are chosen points. Given that computations | Since x0=2, x1=4, x2=5 are chosen points. Given that computations | |||

are done over a finite arithmetic field ("modulo a prime number"), | are done over a finite arithmetic field ("modulo a prime number"), | |||

the Lagrange basis polynomial constants are computed modulo 53. The | the Lagrange basis polynomial constants are computed modulo 53. The | |||

Lagrange Polynomial Constant (LPC) would be 10/3 , -5 , 8/3.LPC are | Lagrange Polynomial Constants (LPC) would be mod(10/3, 53), mod(-5, | |||

computed by the Controller and communicated to the individual nodes. | 53), mod(8/3, 53).LPC are computed by the Controller and communicated | |||

to the individual nodes. | ||||

LPC(l0) = (10/3) mod 53 = 21 | LPC(l0) = (10/3) mod 53 = 21 | |||

LPC(l1) = (-5) mod 53 = 48 | LPC(l1) = (-5) mod 53 = 48 | |||

LPC(l2) = (8/3) mod 53 = 38 | LPC(l2) = (8/3) mod 53 = 38 | |||

For a general way to compute the modular multiplicative inverse, see | For a general way to compute the modular multiplicative inverse, see | |||

e.g., the Euclidean algorithm. | e.g., the Euclidean algorithm. | |||

3.3.1.4. Reconstruction | 3.3.1.4. Reconstruction | |||

Reconstruction of the polynomial is well-defined as | Reconstruction of the polynomial is well-defined as | |||

POLY1(x) = l0(x) * y0 + l1(x) * y1 + l2(x) * y2 | POLY1(x) = l0(x) * y0 + l1(x) * y1 + l2(x) * y2 | |||

Subsequently, the SECRET, which is the constant coefficient of | Subsequently, the SECRET, which is the constant coefficient of | |||

POLY1(x) can be computed as below | POLY1(x) can be computed as below | |||

SECRET = (y0*LPC(l0)+y1*LPC(l1)+y2*LPC(l2)) mod 53 | ||||

SECRET = (y0*LPC(l0)+y1*LPC(l1)+y2*LPC(l2)) mod 53 | ||||

The secret can be easily reconstructed using the y-values and the | The secret can be easily reconstructed using the y-values and the | |||

LPC: | LPC: | |||

SECRET = (y0*LPC(l0) + y1*LPC(l1) + y2*LPC(l2)) mod 53 = mod (28 * 21 | SECRET = (y0*LPC(l0) + y1*LPC(l1) + y2*LPC(l2)) mod 53 | |||

+ 17 * 48 + 47 * 38) mod 53 = 3190 mod 53 = 10 | = (28 * 21 + 17 * 48 + 47 * 38) mod 53 | |||

= 3190 mod 53 | ||||

= 10 | ||||

One observes that the secret reconstruction can easily be performed | One observes that the secret reconstruction can easily be performed | |||

cumulatively hop by hop, i.e. by every node. CML represents the | cumulatively hop by hop, i.e. by every node. CML represents the | |||

cumulative value. It is the POT data in the packet that is updated | cumulative value. It is the POT data in the packet that is updated | |||

at each hop with the node's respective (yi*LPC(i)), where i is their | at each hop with the node's respective (yi*LPC(i)), where i is their | |||

respective value. | respective value. | |||

3.3.1.5. Verification | 3.3.1.5. Verification | |||

Upon completion of the path, the resulting CML is retrieved by the | Upon completion of the path, the resulting CML is retrieved by the | |||

skipping to change at page 11, line 48 ¶ | skipping to change at page 11, line 48 ¶ | |||

Since VERIFY = CML the packet is proven to have gone through nodes 1, | Since VERIFY = CML the packet is proven to have gone through nodes 1, | |||

2, and 3. | 2, and 3. | |||

3.3.3. Solution Deployment Considerations | 3.3.3. Solution Deployment Considerations | |||

The "complete solution" described above in Section 3.3.2 could still | The "complete solution" described above in Section 3.3.2 could still | |||

be prone to replay or preplay attacks. An attacker could e.g. reuse | be prone to replay or preplay attacks. An attacker could e.g. reuse | |||

the POT metadata for bypassing the verification. These threats can | the POT metadata for bypassing the verification. These threats can | |||

be mitigated by appropriate parameterization of the algorithm. | be mitigated by appropriate parameterization of the algorithm. | |||

Please refer to Section 8 for details. | Please refer to Section 7 for details. | |||

3.4. Operational Aspects | 3.4. Operational Aspects | |||

To operationalize this scheme, a central controller is used to | To operationalize this scheme, a central controller is used to | |||

generate the necessary polynomials, the secret share per node, the | generate the necessary polynomials, the secret share per node, the | |||

prime number, etc. and distributing the data to the nodes | prime number, etc. and distributing the data to the nodes | |||

participating in proof of transit. The identified node that performs | participating in proof of transit. The identified node that performs | |||

the verification is provided with the verification key. The | the verification is provided with the verification key. The | |||

information provided from the Controller to each of the nodes | information provided from the Controller to each of the nodes | |||

participating in proof of transit is referred to as a proof of | participating in proof of transit is referred to as a proof of | |||

transit profile (POT-profile). Also note that the set of nodes for | transit profile (POT-Profile). Also note that the set of nodes for | |||

which the transit has to be proven are typically associated to a | which the transit has to be proven are typically associated to a | |||

different trust domain than the verifier. Note that building the | different trust domain than the verifier. Note that building the | |||

trust relationship between the Controller and the nodes is outside | trust relationship between the Controller and the nodes is outside | |||

the scope of this document. Techniques such as those described in | the scope of this document. Techniques such as those described in | |||

[I-D.ietf-anima-autonomic-control-plane] might be applied. | [I-D.ietf-anima-autonomic-control-plane] might be applied. | |||

To optimize the overall data amount of exchanged and the processing | To optimize the overall data amount of exchanged and the processing | |||

at the nodes the following optimizations are performed: | at the nodes the following optimizations are performed: | |||

1. The points (x, y) for each of the nodes on the public and private | 1. The points (x, y) for each of the nodes on the public and private | |||

polynomials are picked such that the x component of the points | polynomials are picked such that the x component of the points | |||

match. This lends to the LPC values which are used to calculate | match. This lends to the LPC values which are used to calculate | |||

the cumulative value CML to be constant. Note that the LPC are | the cumulative value CML to be constant. Note that the LPC are | |||

only depending on the x components. They can be computed at the | only depending on the x components. They can be computed at the | |||

controller and communicated to the nodes. Otherwise, one would | controller and communicated to the nodes. Otherwise, one would | |||

need to distributed the x components to all the nodes. | need to distributed the x components to all the nodes. | |||

2. A pre-evaluated portion of the public polynomial for each of the | 2. A pre-evaluated portion of the public polynomial for each of the | |||

nodes is calculated and added to the POT-profile. Without this | nodes is calculated and added to the POT-Profile. Without this | |||

all the coefficients of the public polynomial had to be added to | all the coefficients of the public polynomial had to be added to | |||

the POT profile and each node had to evaluate them. As stated | the POT profile and each node had to evaluate them. As stated | |||

before, the public portion is only the constant coefficient RND | before, the public portion is only the constant coefficient RND | |||

value, the pre-evaluated portion for each node should be kept | value, the pre-evaluated portion for each node should be kept | |||

secret as well. | secret as well. | |||

3. To provide flexibility on the size of the cumulative and random | 3. To provide flexibility on the size of the cumulative and random | |||

numbers carried in the POT data a field to indicate this is | numbers carried in the POT data a field to indicate this is | |||

shared and interpreted at the nodes. | shared and interpreted at the nodes. | |||

skipping to change at page 15, line 4 ¶ | skipping to change at page 15, line 4 ¶ | |||

(Section 3.5), the masks used between nodes adjacent in the path MUST | (Section 3.5), the masks used between nodes adjacent in the path MUST | |||

have a length equal to the sum of the ones of RND and CML. | have a length equal to the sum of the ones of RND and CML. | |||

5. Node Configuration | 5. Node Configuration | |||

A POT system consists of a number of nodes that participate in POT | A POT system consists of a number of nodes that participate in POT | |||

and a Controller, which serves as a control and configuration entity. | and a Controller, which serves as a control and configuration entity. | |||

The Controller is to create the required parameters (polynomials, | The Controller is to create the required parameters (polynomials, | |||

prime number, etc.) and communicate the associated values (i.e. prime | prime number, etc.) and communicate the associated values (i.e. prime | |||

number, secret-share, LPC, etc.) to the nodes. The sum of all | number, secret-share, LPC, etc.) to the nodes. The sum of all | |||

parameters for a specific node is referred to as "POT-profile". For | parameters for a specific node is referred to as "POT-Profile". For | |||

details see the YANG model in Section 5.2.This document does not | details see the YANG model in Section 5.2.This document does not | |||

define a specific protocol to be used between Controller and nodes. | define a specific protocol to be used between Controller and nodes. | |||

It only defines the procedures and the associated YANG data model. | It only defines the procedures and the associated YANG data model. | |||

5.1. Procedure | 5.1. Procedure | |||

The Controller creates new POT-profiles at a constant rate and | The Controller creates new POT-Profiles at a constant rate and | |||

communicates the POT-profile to the nodes. The controller labels a | communicates the POT-Profile to the nodes. The controller labels a | |||

POT-profile "even" or "odd" and the Controller cycles between "even" | POT-Profile "even" or "odd" and the Controller cycles between "even" | |||

and "odd" labeled profiles. This means that the parameters for the | and "odd" labeled profiles. This means that the parameters for the | |||

algorithms are continuously refreshed. Please refer to Section 4 for | algorithms are continuously refreshed. Please refer to Section 4 for | |||

choosing an appropriate refresh rate: The rate at which the POT- | choosing an appropriate refresh rate: The rate at which the POT- | |||

profiles are communicated to the nodes is configurable and MUST be | Profiles are communicated to the nodes is configurable and MUST be | |||

more frequent than the speed at which a POT-profile is "used up". | more frequent than the speed at which a POT-Profile is "used up". | |||

Once the POT-profile has been successfully communicated to all nodes | Once the POT-Profile has been successfully communicated to all nodes | |||

(e.g., all NETCONF transactions completed, in case NETCONF is used as | (e.g., all NETCONF transactions completed, in case NETCONF is used as | |||

a protocol), the controller sends an "enable POT-profile" request to | a protocol), the controller sends an "enable POT-Profile" request to | |||

the ingress node. | the ingress node. | |||

All nodes maintain two POT-profiles (an even and an odd POT-profile): | All nodes maintain two POT-Profiles (an even and an odd POT-Profile): | |||

One POT-profile is currently active and in use; one profile is | One POT-Profile is currently active and in use; one profile is | |||

standby and about to get used. A flag in the packet is indicating | standby and about to get used. A flag in the packet is indicating | |||

whether the odd or even POT-profile is to be used by a node. This is | whether the odd or even POT-Profile is to be used by a node. This is | |||

to ensure that during profile change the service is not disrupted. | to ensure that during profile change the service is not disrupted. | |||

If the "odd" profile is active, the Controller can communicate the | If the "odd" profile is active, the Controller can communicate the | |||

"even" profile to all nodes. Only if all the nodes have received the | "even" profile to all nodes. Only if all the nodes have received the | |||

POT-profile, the Controller will tell the ingress node to switch to | POT-Profile, the Controller will tell the ingress node to switch to | |||

the "even" profile. Given that the indicator travels within the | the "even" profile. Given that the indicator travels within the | |||

packet, all nodes will switch to the "even" profile. The "even" | packet, all nodes will switch to the "even" profile. The "even" | |||

profile gets active on all nodes and nodes are ready to receive a new | profile gets active on all nodes and nodes are ready to receive a new | |||

"odd" profile. | "odd" profile. | |||

Unless the ingress node receives a request to switch profiles, it'll | Unless the ingress node receives a request to switch profiles, it'll | |||

continue to use the active profile. If a profile is "used up" the | continue to use the active profile. If a profile is "used up" the | |||

ingress node will recycle the active profile and start over (this | ingress node will recycle the active profile and start over (this | |||

could give rise to replay attacks in theory - but with 2^32 or 2^64 | could give rise to replay attacks in theory - but with 2^32 or 2^64 | |||

packets this isn't really likely in reality). | packets this isn't really likely in reality). | |||

5.2. YANG Model | 5.2. YANG Model for POT | |||

This section defines that YANG data model for the information | This section defines that YANG data model for the information | |||

exchange between the Controller and the nodes. | exchange between the Controller and the node. | |||

5.2.1. Main Parameters | ||||

The main parameters for the information exchange between the | ||||

Controller and the node used in the YANG model are as follows: | ||||

o pot-profile-index: Section 5.1 details that two POT-Profiles are | ||||

used. Only one of the POT-Profiles is active at a given point in | ||||

time, allowing the Controller to refresh the non-active one for | ||||

future use. pot-profile-index defines which of the POT-Profiles | ||||

(the "even" or "odd" POT-Profile) is currently active. pot- | ||||

profile-index will be set in the first hop of the path or chain. | ||||

Other nodes will not use this field. | ||||

o prime-number: Prime number used for module math computation. | ||||

o secret-share: Share of the secret of polynomial-1 used in | ||||

computation for the node. If POLY-1 is defined by points (x1_i, | ||||

y1_i) with i=0,..k, then for node i, the secret-share will be | ||||

y1_i. | ||||

o public-polynomial: Public polynomial value for the node.. If | ||||

POLY-2 is defined by points (x2_i, y2_i) with i=0,..k, then for | ||||

node i, the secret-share will be y2_i. | ||||

o lpc: Lagrange Polynomial Coefficient for the node, i.e. for node | ||||

i, this would be LPC(l_i), with l_i being the i-th Lagrange Basis | ||||

Polynomial. | ||||

o validator?: True if the node is a verifier node. | ||||

o validator-key?: The validator-key represents the SECRET as | ||||

described in the sections above. The SECRET is the constant | ||||

coefficient of POLY-1(z). If POLY-1(z) = a_0 + a_1*z + | ||||

a_2*z^2+..+a_k*z^k, then the SECRET would be a_0. | ||||

o bitmask?: Number of bits as mask used in controlling the size of | ||||

the random value generation. 32-bits of mask is default. See | ||||

Section 4 for details. | ||||

5.2.2. Tree Diagram | ||||

This section shows a simplified graphical representation of the YANG | ||||

data model for POT. The meaning of the symbols in these diagrams is | ||||

as follows: | ||||

o Brackets "[" and "]" enclose list keys. | ||||

o Abbreviations before data node names: "rw" means configuration | ||||

(read-write), and "ro" means state data (read-only). | ||||

o Symbols after data node names: "?" means an optional node, "!" | ||||

means a presence container, and "*" denotes a list and leaf-list. | ||||

o Parentheses enclose choice and case nodes, and case nodes are also | ||||

marked with a colon (":"). | ||||

o Ellipsis ("...") stands for contents of subtrees that are not | ||||

shown. | ||||

<CODE BEGINS> | ||||

module: ietf-pot-profile | ||||

+--rw pot-profiles | ||||

+--rw pot-profile-set* [pot-profile-name] | ||||

+--rw pot-profile-name string | ||||

+--rw active-profile-index? profile-index-range | ||||

+--rw pot-profile-list* [pot-profile-index] | ||||

+--rw pot-profile-index profile-index-range | ||||

+--rw prime-number uint64 | ||||

+--rw secret-share uint64 | ||||

+--rw public-polynomial uint64 | ||||

+--rw lpc uint64 | ||||

+--rw validator? boolean | ||||

+--rw validator-key? uint64 | ||||

+--rw bitmask? uint64 | ||||

<CODE ENDS> | ||||

5.2.3. YANG Model | ||||

<CODE BEGINS> file "ietf-pot-profile@2016-06-15.yang" | <CODE BEGINS> file "ietf-pot-profile@2016-06-15.yang" | |||

module ietf-pot-profile { | module ietf-pot-profile { | |||

yang-version 1; | yang-version 1; | |||

namespace "urn:ietf:params:xml:ns:yang:ietf-pot-profile"; | namespace "urn:ietf:params:xml:ns:yang:ietf-pot-profile"; | |||

prefix ietf-pot-profile; | prefix ietf-pot-profile; | |||

organization "IETF xxx Working Group"; | organization "IETF SFC Working Group"; | |||

contact ""; | contact "WG Web: <https://tools.ietf.org/wg/sfc/> | |||

WG List: <mailto:sfc@ietf.org>"; | ||||

description "This module contains a collection of YANG | description "This module contains a collection of YANG | |||

definitions for proof of transit configuration | definitions for proof of transit configuration | |||

parameters. The model is meant for proof of | parameters. The model is meant for proof of | |||

transit and is targeted for communicating the | transit and is targeted for communicating the | |||

POT-profile between a controller and nodes | POT-Profile between a controller and nodes | |||

participating in proof of transit."; | participating in proof of transit."; | |||

revision 2016-06-15 { | revision 2016-06-15 { | |||

description | description | |||

"Initial revision."; | "Initial revision."; | |||

reference | reference | |||

""; | ""; | |||

} | } | |||

typedef profile-index-range { | typedef profile-index-range { | |||

skipping to change at page 17, line 13 ¶ | skipping to change at page 18, line 49 ¶ | |||

type uint64; | type uint64; | |||

mandatory true; | mandatory true; | |||

description | description | |||

"Prime number used for module math computation"; | "Prime number used for module math computation"; | |||

} | } | |||

leaf secret-share { | leaf secret-share { | |||

type uint64; | type uint64; | |||

mandatory true; | mandatory true; | |||

description | description | |||

"Share of the secret of polynomial 1 used in computation"; | "Share of the secret of polynomial-1 used | |||

in computation for the node. If POLY-1 | ||||

is defined by points (x1_i, y1_i) with | ||||

i=0,..k, then for node i, the secret-share | ||||

will be y1_i."; | ||||

} | } | |||

leaf public-polynomial { | leaf public-polynomial { | |||

type uint64; | type uint64; | |||

mandatory true; | mandatory true; | |||

description | description | |||

"Pre evaluated Public polynomial"; | "Public polynomial value for the node. | |||

If POLY-2 is defined by points (x2_i, y2_i) | ||||

with i=0,..k, then for node i, | ||||

the secret-share will be y2_i."; | ||||

} | } | |||

leaf lpc { | leaf lpc { | |||

type uint64; | type uint64; | |||

mandatory true; | mandatory true; | |||

description | description | |||

"Lagrange Polynomial Coefficient"; | "Lagrange Polynomial Coefficient"; | |||

} | } | |||

leaf validator { | leaf validator { | |||

type boolean; | type boolean; | |||

default "false"; | default "false"; | |||

description | description | |||

"True if the node is a verifier node"; | "True if the node is a verifier node"; | |||

} | } | |||

leaf validator-key { | leaf validator-key { | |||

type uint64; | type uint64; | |||

description | description | |||

"Secret key for validating the path, constant of poly 1"; | "The validator-key represents the secret. | |||

The secret is the constant coefficient of | ||||

POLY-1(z). If POLY-1(z) = | ||||

a_0 + a_1*z + a_2*z^2+..+a_k*z^k, | ||||

then the SECRET would be a_0."; | ||||

} | } | |||

leaf bitmask { | leaf bitmask { | |||

type uint64; | type uint64; | |||

default 4294967295; | default 4294967295; | |||

description | description | |||

"Number of bits as mask used in controlling the size of the | "Number of bits as mask used in controlling | |||

random value generation. 32-bits of mask is default."; | the size of the random value generation. | |||

32-bits of mask is default."; | ||||

} | } | |||

} | } | |||

} | } | |||

container pot-profiles { | container pot-profiles { | |||

description "A group of proof of transit profiles."; | description "A group of proof of transit profiles."; | |||

list pot-profile-set { | list pot-profile-set { | |||

key "pot-profile-name"; | key "pot-profile-name"; | |||

ordered-by user; | ordered-by user; | |||

description | description | |||

"Set of proof of transit profiles that group parameters | "Set of proof of transit profiles that group parameters | |||

required to classify and compute proof of transit | required to classify and compute proof of transit | |||

metadata at a node"; | metadata at a node"; | |||

skipping to change at page 18, line 25 ¶ | skipping to change at page 20, line 28 ¶ | |||

leaf pot-profile-name { | leaf pot-profile-name { | |||

type string; | type string; | |||

mandatory true; | mandatory true; | |||

description | description | |||

"Unique identifier for each proof of transit profile"; | "Unique identifier for each proof of transit profile"; | |||

} | } | |||

leaf active-profile-index { | leaf active-profile-index { | |||

type profile-index-range; | type profile-index-range; | |||

description | description | |||

"Proof of transit profile index that is currently active. | "POT-Profile index that is currently active. | |||

Will be set in the first hop of the path or chain. | Will be set in the first hop of the path or chain. | |||

Other nodes will not use this field."; | Other nodes will not use this field."; | |||

} | } | |||

uses pot-profile; | uses pot-profile; | |||

} | } | |||

/*** Container: end ***/ | /*** Container: end ***/ | |||

} | } | |||

/*** module: end ***/ | /*** module: end ***/ | |||

} | } | |||

<CODE ENDS> | <CODE ENDS> | |||

6. IANA Considerations | 6. IANA Considerations | |||

IANA considerations will be added in a future version of this | This document does not require any actions from IANA. | |||

document. | ||||

7. Manageability Considerations | ||||

Manageability considerations will be addressed in a later version of | ||||

this document. | ||||

8. Security Considerations | 7. Security Considerations | |||

POT is a mechanism that is used for verifying the path through which | POT is a mechanism that is used for verifying the path through which | |||

a packet was forwarded. The security considerations of IOAM in | a packet was forwarded. The security considerations of IOAM in | |||

general are discussed in [I-D.ietf-ippm-ioam-data]. Specifically, it | general are discussed in [I-D.ietf-ippm-ioam-data]. Specifically, it | |||

is assumed that POT is used in a confined network domain, and | is assumed that POT is used in a confined network domain, and | |||

therefore the potential threats that POT is intended to mitigate | therefore the potential threats that POT is intended to mitigate | |||

should be viewed accordingly. POT prevents spoofing and tampering; | should be viewed accordingly. POT prevents spoofing and tampering; | |||

an attacker cannot maliciously create a bogus POT or modify a | an attacker cannot maliciously create a bogus POT or modify a | |||

legitimate one. Furthermore, a legitimate node that takes part in | legitimate one. Furthermore, a legitimate node that takes part in | |||

the POT protocol cannot masquerade as another node along the path. | the POT protocol cannot masquerade as another node along the path. | |||

These considerations are discussed in detail in the rest of this | These considerations are discussed in detail in the rest of this | |||

section. | section. | |||

8.1. Proof of Transit | 7.1. Proof of Transit | |||

Proof of correctness and security of the solution approach is per | Proof of correctness and security of the solution approach is per | |||

Shamir's Secret Sharing Scheme [SSS]. Cryptographically speaking it | Shamir's Secret Sharing Scheme [SSS]. Cryptographically speaking it | |||

achieves information-theoretic security i.e., it cannot be broken by | achieves information-theoretic security i.e., it cannot be broken by | |||

an attacker even with unlimited computing power. As long as the | an attacker even with unlimited computing power. As long as the | |||

below conditions are met it is impossible for an attacker to bypass | below conditions are met it is impossible for an attacker to bypass | |||

one or multiple nodes without getting caught. | one or multiple nodes without getting caught. | |||

o If there are k+1 nodes in the path, the polynomials (POLY-1, POLY- | o If there are k+1 nodes in the path, the polynomials (POLY-1, POLY- | |||

2) should be of degree k. Also k+1 points of POLY-1 are chosen | 2) should be of degree k. Also k+1 points of POLY-1 are chosen | |||

skipping to change at page 20, line 5 ¶ | skipping to change at page 21, line 45 ¶ | |||

used as POLY-1 across different paths, traffic profiles or service | used as POLY-1 across different paths, traffic profiles or service | |||

chains. | chains. | |||

If symmetric masking is used to assure OPOT (Section 3.5), the nodes | If symmetric masking is used to assure OPOT (Section 3.5), the nodes | |||

need to keep two additional secrets: the downstream and upstream | need to keep two additional secrets: the downstream and upstream | |||

masks, that have to be managed under the same conditions as the | masks, that have to be managed under the same conditions as the | |||

secrets mentioned above. And it is equally recommended to employ a | secrets mentioned above. And it is equally recommended to employ a | |||

different set of mask pairs across different paths, traffic profiles | different set of mask pairs across different paths, traffic profiles | |||

or service chains. | or service chains. | |||

8.2. Cryptanalysis | 7.2. Cryptanalysis | |||

A passive attacker could try to harvest the POT data (i.e., CML, RND | A passive attacker could try to harvest the POT data (i.e., CML, RND | |||

values) in order to determine the configured secrets. Subsequently | values) in order to determine the configured secrets. Subsequently | |||

two types of differential analysis for guessing the secrets could be | two types of differential analysis for guessing the secrets could be | |||

done. | done. | |||

o Inter-Node: A passive attacker observing CML values across nodes | o Inter-Node: A passive attacker observing CML values across nodes | |||

(i.e., as the packets entering and leaving), cannot perform | (i.e., as the packets entering and leaving), cannot perform | |||

differential analysis to construct the points on POLY-1. This is | differential analysis to construct the points on POLY-1. This is | |||

because at each point there are four unknowns (i.e. Share(POLY- | because at each point there are four unknowns (i.e. Share(POLY- | |||

skipping to change at page 20, line 30 ¶ | skipping to change at page 22, line 23 ¶ | |||

o Inter-Packets: A passive attacker could observe CML values across | o Inter-Packets: A passive attacker could observe CML values across | |||

packets (i.e., values of PKT-1 and subsequent PKT-2), in order to | packets (i.e., values of PKT-1 and subsequent PKT-2), in order to | |||

predict the secrets. Differential analysis across packets could | predict the secrets. Differential analysis across packets could | |||

be mitigated using a good PRNG for generating RND. Note that if | be mitigated using a good PRNG for generating RND. Note that if | |||

constant coefficient is a sequence number than CML values become | constant coefficient is a sequence number than CML values become | |||

quite predictable and the scheme would be broken. If symmetric | quite predictable and the scheme would be broken. If symmetric | |||

masking is used for OPOT, inter-packet analysis could be applied | masking is used for OPOT, inter-packet analysis could be applied | |||

to guess mask values, which requires a proper refresh rate for | to guess mask values, which requires a proper refresh rate for | |||

masks, at least as high as the one used for LPCs. | masks, at least as high as the one used for LPCs. | |||

8.3. Anti-Replay | 7.3. Anti-Replay | |||

A passive attacker could reuse a set of older RND and the | A passive attacker could reuse a set of older RND and the | |||

intermediate CML values. Thus, an attacker can attack an old | intermediate CML values. Thus, an attacker can attack an old | |||

(replayed) RND and CML with a new packet in order to bypass some of | (replayed) RND and CML with a new packet in order to bypass some of | |||

the nodes along the path. | the nodes along the path. | |||

Such attacks could be avoided by carefully choosing POLY-2 as a | Such attacks could be avoided by carefully choosing POLY-2 as a | |||

(SEQ_NO + RND). For example, if 64 bits are being used for POLY-2 | (SEQ_NO + RND). For example, if 64 bits are being used for POLY-2 | |||

then first 16 bits could be a sequence number SEQ_NO and next 48 bits | then first 16 bits could be a sequence number SEQ_NO and next 48 bits | |||

could be a random number. | could be a random number. | |||

skipping to change at page 21, line 9 ¶ | skipping to change at page 23, line 5 ¶ | |||

flagged legitimate. Packets arriving with a lower SEQ_NO than | flagged legitimate. Packets arriving with a lower SEQ_NO than | |||

current buffer could be flagged as suspicious. | current buffer could be flagged as suspicious. | |||

For all practical purposes in the rest of the document RND means | For all practical purposes in the rest of the document RND means | |||

SEQ_NO + RND to keep it simple. | SEQ_NO + RND to keep it simple. | |||

The solution discussed in this memo does not currently mitigate | The solution discussed in this memo does not currently mitigate | |||

replay attacks. An anti-replay mechanism may be included in future | replay attacks. An anti-replay mechanism may be included in future | |||

versions of the solution. | versions of the solution. | |||

8.4. Anti-Preplay | 7.4. Anti-Preplay | |||

An active attacker could try to perform a man-in-the-middle (MITM) | An active attacker could try to perform a man-in-the-middle (MITM) | |||

attack by extracting the POT of PKT-1 and using it in PKT-2. | attack by extracting the POT of PKT-1 and using it in PKT-2. | |||

Subsequently attacker drops the PKT-1 in order to avoid duplicate POT | Subsequently attacker drops the PKT-1 in order to avoid duplicate POT | |||

values reaching the verifier. If the PKT-1 reaches the verifier, | values reaching the verifier. If the PKT-1 reaches the verifier, | |||

then this attack is same as Replay attacks discussed before. | then this attack is same as Replay attacks discussed before. | |||

Preplay attacks are possible since the POT metadata is not dependent | Preplay attacks are possible since the POT metadata is not dependent | |||

on the packet fields. Below steps are recommended for remediation: | on the packet fields. Below steps are recommended for remediation: | |||

skipping to change at page 21, line 40 ¶ | skipping to change at page 23, line 36 ¶ | |||

compares with RND. To ensure the POT data is in fact that of the | compares with RND. To ensure the POT data is in fact that of the | |||

packet. | packet. | |||

If an HMAC is used, an active attacker lacks the knowledge of the | If an HMAC is used, an active attacker lacks the knowledge of the | |||

pre-shared key, and thus cannot launch preplay attacks. | pre-shared key, and thus cannot launch preplay attacks. | |||

The solution discussed in this memo does not currently mitigate | The solution discussed in this memo does not currently mitigate | |||

preplay attacks. A mitigation mechanism may be included in future | preplay attacks. A mitigation mechanism may be included in future | |||

versions of the solution. | versions of the solution. | |||

8.5. Tampering | 7.5. Tampering | |||

An active attacker could not insert any arbitrary value for CML. | An active attacker could not insert any arbitrary value for CML. | |||

This would subsequently fail the reconstruction of the POLY-3. Also | This would subsequently fail the reconstruction of the POLY-3. Also | |||

an attacker could not update the CML with a previously observed | an attacker could not update the CML with a previously observed | |||

value. This could subsequently be detected by using timestamps | value. This could subsequently be detected by using timestamps | |||

within the RND value as discussed above. | within the RND value as discussed above. | |||

8.6. Recycling | 7.6. Recycling | |||

The solution approach is flexible for recycling long term secrets | The solution approach is flexible for recycling long term secrets | |||

like POLY-1. All the nodes could be periodically updated with shares | like POLY-1. All the nodes could be periodically updated with shares | |||

of new SECRET as best practice. The table above could be consulted | of new SECRET as best practice. The table above could be consulted | |||

for refresh cycles (see Section 4). | for refresh cycles (see Section 4). | |||

If symmetric masking is used for OPOT (Section 3.5), mask values must | If symmetric masking is used for OPOT (Section 3.5), mask values must | |||

be periodically updated as well, at least as frequently as the other | be periodically updated as well, at least as frequently as the other | |||

secrets are. | secrets are. | |||

8.7. Redundant Nodes and Failover | 7.7. Redundant Nodes and Failover | |||

A "node" or "service" in terms of POT can be implemented by one or | A "node" or "service" in terms of POT can be implemented by one or | |||

multiple physical entities. In case of multiple physical entities | multiple physical entities. In case of multiple physical entities | |||

(e.g., for load-balancing, or business continuity situations - | (e.g., for load-balancing, or business continuity situations - | |||

consider for example a set of firewalls), all physical entities which | consider for example a set of firewalls), all physical entities which | |||

are implementing the same POT node are given that same share of the | are implementing the same POT node are given that same share of the | |||

secret. This makes multiple physical entities represent the same POT | secret. This makes multiple physical entities represent the same POT | |||

node from an algorithm perspective. | node from an algorithm perspective. | |||

8.8. Controller Operation | 7.8. Controller Operation | |||

The Controller needs to be secured given that it creates and holds | The Controller needs to be secured given that it creates and holds | |||

the secrets, as need to be the nodes. The communication between | the secrets, as need to be the nodes. The communication between | |||

Controller and the nodes also needs to be secured. As secure | Controller and the nodes also needs to be secured. As secure | |||

communication protocol such as for example NETCONF over SSH should be | communication protocol such as for example NETCONF over SSH should be | |||

chosen for Controller to node communication. | chosen for Controller to node communication. | |||

The Controller only interacts with the nodes during the initial | The Controller only interacts with the nodes during the initial | |||

configuration and thereafter at regular intervals at which the | configuration and thereafter at regular intervals at which the | |||

operator chooses to switch to a new set of secrets. In case 64 bits | operator chooses to switch to a new set of secrets. In case 64 bits | |||

are used for the data fields "CML" and "RND" which are carried within | are used for the data fields "CML" and "RND" which are carried within | |||

the data packet, the regular intervals are expected to be quite long | the data packet, the regular intervals are expected to be quite long | |||

(e.g., at 100 Gbps, a profile would only be used up after 3100 years) | (e.g., at 100 Gbps, a profile would only be used up after 3100 years) | |||

- see Section 4 above, thus even a "headless" operation without a | - see Section 4 above, thus even a "headless" operation without a | |||

Controller can be considered feasible. In such a case, the | Controller can be considered feasible. In such a case, the | |||

Controller would only be used for the initial configuration of the | Controller would only be used for the initial configuration of the | |||

POT-profiles. | POT-Profiles. | |||

If OPOT (Section 3.5) is applied using symmetric masking, the | If OPOT (Section 3.5) is applied using symmetric masking, the | |||

Controller will be required to perform a a periodic refresh of the | Controller will be required to perform a a periodic refresh of the | |||

mask pairs. The use of OPOT SHOULD be configurable as part of the | mask pairs. The use of OPOT SHOULD be configurable as part of the | |||

required level of assurance through the Controller management | required level of assurance through the Controller management | |||

interface. | interface. | |||

8.9. Verification Scope | 7.9. Verification Scope | |||

The POT solution defined in this document verifies that a data-packet | The POT solution defined in this document verifies that a data-packet | |||

traversed or transited a specific set of nodes. From an algorithm | traversed or transited a specific set of nodes. From an algorithm | |||

perspective, a "node" is an abstract entity. It could be represented | perspective, a "node" is an abstract entity. It could be represented | |||

by one or multiple physical or virtual network devices, or is could | by one or multiple physical or virtual network devices, or is could | |||

be a component within a networking device or system. The latter | be a component within a networking device or system. The latter | |||

would be the case if a forwarding path within a device would need to | would be the case if a forwarding path within a device would need to | |||

be securely verified. | be securely verified. | |||

8.9.1. Node Ordering | 7.9.1. Node Ordering | |||

POT using Shamir's secret sharing scheme as discussed in this | POT using Shamir's secret sharing scheme as discussed in this | |||

document provides for a means to verify that a set of nodes has been | document provides for a means to verify that a set of nodes has been | |||

visited by a data packet. It does not verify the order in which the | visited by a data packet. It does not verify the order in which the | |||

data packet visited the nodes. | data packet visited the nodes. | |||

In case the order in which a data packet traversed a particular set | In case the order in which a data packet traversed a particular set | |||

of nodes needs to be verified as well, the alternate schemes related | of nodes needs to be verified as well, the alternate schemes related | |||

to OPOT (Section 3.5) have to be considered. Since these schemes | to OPOT (Section 3.5) have to be considered. Since these schemes | |||

introduce at least additional control requirements, the selection of | introduce at least additional control requirements, the selection of | |||

order verification SHOULD be configurable the Controller management | order verification SHOULD be configurable the Controller management | |||

interface. | interface. | |||

8.9.2. Stealth Nodes | 7.9.2. Stealth Nodes | |||

The POT approach discussed in this document is to prove that a data | The POT approach discussed in this document is to prove that a data | |||

packet traversed a specific set of "nodes". This set could be all | packet traversed a specific set of "nodes". This set could be all | |||

nodes within a path, but could also be a subset of nodes in a path. | nodes within a path, but could also be a subset of nodes in a path. | |||

Consequently, the POT approach isn't suited to detect whether | Consequently, the POT approach isn't suited to detect whether | |||

"stealth" nodes which do not participate in proof-of-transit have | "stealth" nodes which do not participate in proof-of-transit have | |||

been inserted into a path. | been inserted into a path. | |||

9. Acknowledgements | 8. Acknowledgements | |||

The authors would like to thank Eric Vyncke, Nalini Elkins, Srihari | The authors would like to thank Eric Vyncke, Nalini Elkins, Srihari | |||

Raghavan, Ranganathan T S, Karthik Babu Harichandra Babu, Akshaya | Raghavan, Ranganathan T S, Karthik Babu Harichandra Babu, Akshaya | |||

Nadahalli, Erik Nordmark, and Andrew Yourtchenko for the comments and | Nadahalli, Erik Nordmark, and Andrew Yourtchenko for the comments and | |||

advice. | advice. | |||

9. Contributors | ||||

In addition to editors and authors listed on the title page, the | ||||

following people have contributed to this document: | ||||

Carlos Pignataro | ||||

Cisco Systems, Inc. | ||||

7200-11 Kit Creek Road | ||||

Research Triangle Park, NC 27709 | ||||

United States | ||||

Email: cpignata@cisco.com | ||||

John Leddy | ||||

Email: john@leddy.net | ||||

David Mozes | ||||

Email: mosesster@gmail.com | ||||

Alejandro Aguado | ||||

Universidad Politecnica de Madrid | ||||

Campus Montegancedo, Boadilla del Monte | ||||

Madrid 28660 | ||||

Spain | ||||

Phone: +34 910 673 086 | ||||

Email: a.aguadom@fi.upm.es | ||||

Diego R. Lopez | ||||

Telefonica I+D | ||||

Editor Jose Manuel Lara, 9 (1-B) | ||||

Seville 41013 | ||||

Spain | ||||

Phone: +34 913 129 041 | ||||

Email: diego.r.lopez@telefonica.com | ||||

10. References | 10. References | |||

10.1. Normative References | 10.1. Normative References | |||

[I-D.ietf-ippm-ioam-data] | [I-D.ietf-ippm-ioam-data] | |||

Brockners, F., Bhandari, S., Pignataro, C., Gredler, H., | Brockners, F., Bhandari, S., Pignataro, C., Gredler, H., | |||

Leddy, J., Youell, S., Mizrahi, T., Mozes, D., Lapukhov, | Leddy, J., Youell, S., Mizrahi, T., Mozes, D., Lapukhov, | |||

P., Chang, R., daniel.bernier@bell.ca, d., and J. Lemon, | P., Chang, R., daniel.bernier@bell.ca, d., and J. Lemon, | |||

"Data Fields for In-situ OAM", draft-ietf-ippm-ioam- | "Data Fields for In-situ OAM", draft-ietf-ippm-ioam- | |||

data-04 (work in progress), October 2018. | data-06 (work in progress), July 2019. | |||

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | |||

Requirement Levels", BCP 14, RFC 2119, | Requirement Levels", BCP 14, RFC 2119, | |||

DOI 10.17487/RFC2119, March 1997, <https://www.rfc- | DOI 10.17487/RFC2119, March 1997, | |||

editor.org/info/rfc2119>. | <https://www.rfc-editor.org/info/rfc2119>. | |||

[RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function | [RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function | |||

Chaining (SFC) Architecture", RFC 7665, | Chaining (SFC) Architecture", RFC 7665, | |||

DOI 10.17487/RFC7665, October 2015, <https://www.rfc- | DOI 10.17487/RFC7665, October 2015, | |||

editor.org/info/rfc7665>. | <https://www.rfc-editor.org/info/rfc7665>. | |||

[SSS] "Shamir's Secret Sharing", <https://en.wikipedia.org/wiki/ | [SSS] "Shamir's Secret Sharing", | |||

Shamir%27s_Secret_Sharing>. | <https://en.wikipedia.org/wiki/Shamir%27s_Secret_Sharing>. | |||

10.2. Informative References | 10.2. Informative References | |||

[I-D.ietf-anima-autonomic-control-plane] | [I-D.ietf-anima-autonomic-control-plane] | |||

Eckert, T., Behringer, M., and S. Bjarnason, "An Autonomic | Eckert, T., Behringer, M., and S. Bjarnason, "An Autonomic | |||

Control Plane (ACP)", draft-ietf-anima-autonomic-control- | Control Plane (ACP)", draft-ietf-anima-autonomic-control- | |||

plane-18 (work in progress), August 2018. | plane-18 (work in progress), August 2018. | |||

Authors' Addresses | Authors' Addresses | |||

Frank Brockners | Frank Brockners (editor) | |||

Cisco Systems, Inc. | Cisco Systems, Inc. | |||

Hansaallee 249, 3rd Floor | Hansaallee 249, 3rd Floor | |||

DUESSELDORF, NORDRHEIN-WESTFALEN 40549 | DUESSELDORF, NORDRHEIN-WESTFALEN 40549 | |||

Germany | Germany | |||

Email: fbrockne@cisco.com | Email: fbrockne@cisco.com | |||

Shwetha Bhandari | Shwetha Bhandari (editor) | |||

Cisco Systems, Inc. | Cisco Systems, Inc. | |||

Cessna Business Park, Sarjapura Marathalli Outer Ring Road | Cessna Business Park, Sarjapura Marathalli Outer Ring Road | |||

Bangalore, KARNATAKA 560 087 | Bangalore, KARNATAKA 560 087 | |||

India | India | |||

Email: shwethab@cisco.com | Email: shwethab@cisco.com | |||

Tal Mizrahi (editor) | ||||

Huawei Network.IO Innovation Lab | ||||

Israel | ||||

Email: tal.mizrahi.phd@gmail.com | ||||

Sashank Dara | Sashank Dara | |||

Seconize | Seconize | |||

BANGALORE, Bangalore, KARNATAKA | BANGALORE, Bangalore, KARNATAKA | |||

INDIA | INDIA | |||

Email: sashank@seconize.co | Email: sashank@seconize.co | |||

Carlos Pignataro | ||||

Cisco Systems, Inc. | ||||

7200-11 Kit Creek Road | ||||

Research Triangle Park, NC 27709 | ||||

United States | ||||

Email: cpignata@cisco.com | ||||

John Leddy | ||||

Comcast | ||||

Email: John_Leddy@cable.comcast.com | ||||

Stephen Youell | Stephen Youell | |||

JP Morgan Chase | JP Morgan Chase | |||

25 Bank Street | 25 Bank Street | |||

London E14 5JP | London E14 5JP | |||

United Kingdom | United Kingdom | |||

Email: stephen.youell@jpmorgan.com | Email: stephen.youell@jpmorgan.com | |||

David Mozes | ||||

Email: mosesster@gmail.com | ||||

Tal Mizrahi | ||||

Huawei Network.IO Innovation Lab | ||||

Israel | ||||

Email: tal.mizrahi.phd@gmail.com | ||||

Alejandro Aguado | ||||

Universidad Politecnica de Madrid | ||||

Campus Montegancedo, Boadilla del Monte | ||||

Madrid 28660 | ||||

Spain | ||||

Phone: +34 910 673 086 | ||||

Email: a.aguadom@fi.upm.es | ||||

Diego R. Lopez | ||||

Telefonica I+D | ||||

Editor Jose Manuel Lara, 9 (1-B) | ||||

Seville 41013 | ||||

Spain | ||||

Phone: +34 913 129 041 | ||||

Email: diego.r.lopez@telefonica.com | ||||

End of changes. 68 change blocks. | ||||

133 lines changed or deleted | | 244 lines changed or added | ||

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ |