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

Network Working Group F. Brockners | Network Working Group F. Brockners | |||

Internet-Draft S. Bhandari | Internet-Draft S. Bhandari | |||

Intended status: Experimental S. Dara | Intended status: Experimental Cisco | |||

Expires: April 4, 2019 C. Pignataro | Expires: September 12, 2019 S. Dara | |||

Seconize | ||||

C. Pignataro | ||||

Cisco | Cisco | |||

J. Leddy | J. Leddy | |||

Comcast | Comcast | |||

S. Youell | S. Youell | |||

JPMC | JPMC | |||

D. Mozes | D. Mozes | |||

T. Mizrahi | T. Mizrahi | |||

Marvell | Huawei Network.IO Innovation Lab | |||

A. Aguado | A. Aguado | |||

Universidad Politecnica de Madrid | Universidad Politecnica de Madrid | |||

D. Lopez | D. Lopez | |||

Telefonica I+D | Telefonica I+D | |||

October 1, 2018 | March 11, 2019 | |||

Proof of Transit | Proof of Transit | |||

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

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. | |||

skipping to change at page 2, line 4 ¶ | skipping to change at page 2, line 6 ¶ | |||

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 http://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 April 4, 2019. | ||||

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

Copyright Notice | Copyright Notice | |||

Copyright (c) 2018 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 | (http://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 . . . . . . . . . . . . . . . . . . . . . . . 5 | 3.1. Basic Idea . . . . . . . . . . . . . . . . . . . . . . . 6 | |||

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

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 . . . . . . . . . . . . . . . . . . . . 7 | 3.2.3. Verification . . . . . . . . . . . . . . . . . . . . 8 | |||

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

3.3.1. Basic Version . . . . . . . . . . . . . . . . . . . . 7 | 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 . . . . . . . . . . . . . . 8 | 3.3.1.2. Lagrange Polynomials . . . . . . . . . . . . . . 9 | |||

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

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

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

3.3.2. Enhanced Version . . . . . . . . . . . . . . . . . . 9 | 3.3.2. Complete Solution . . . . . . . . . . . . . . . . . . 10 | |||

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

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

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

3.3.3. Final Version . . . . . . . . . . . . . . . . . . . . 11 | 3.3.3. Solution Deployment Considerations . . . . . . . . . 11 | |||

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

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

3.5.1. Nested Encryption . . . . . . . . . . . . . . . . . . 12 | ||||

3.5.2. Symmetric Masking Between Nodes . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . . . . . . . . . 14 | 5.1. Procedure . . . . . . . . . . . . . . . . . . . . . . . . 15 | |||

5.2. YANG Model . . . . . . . . . . . . . . . . . . . . . . . 15 | 5.2. YANG Model . . . . . . . . . . . . . . . . . . . . . . . 15 | |||

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

7. Manageability Considerations . . . . . . . . . . . . . . . . 18 | 7. Manageability Considerations . . . . . . . . . . . . . . . . 18 | |||

8. Security Considerations . . . . . . . . . . . . . . . . . . . 18 | 8. Security Considerations . . . . . . . . . . . . . . . . . . . 19 | |||

8.1. Proof of Transit . . . . . . . . . . . . . . . . . . . . 18 | 8.1. Proof of Transit . . . . . . . . . . . . . . . . . . . . 19 | |||

8.2. Cryptanalysis . . . . . . . . . . . . . . . . . . . . . . 19 | 8.2. Cryptanalysis . . . . . . . . . . . . . . . . . . . . . . 20 | |||

8.3. Anti-Replay . . . . . . . . . . . . . . . . . . . . . . . 20 | 8.3. Anti-Replay . . . . . . . . . . . . . . . . . . . . . . . 20 | |||

8.4. Anti-Preplay . . . . . . . . . . . . . . . . . . . . . . 20 | 8.4. Anti-Preplay . . . . . . . . . . . . . . . . . . . . . . 21 | |||

8.5. Anti-Tampering . . . . . . . . . . . . . . . . . . . . . 21 | 8.5. Tampering . . . . . . . . . . . . . . . . . . . . . . . . 21 | |||

8.6. Recycling . . . . . . . . . . . . . . . . . . . . . . . . 21 | 8.6. Recycling . . . . . . . . . . . . . . . . . . . . . . . . 21 | |||

8.7. Redundant Nodes and Failover . . . . . . . . . . . . . . 21 | 8.7. Redundant Nodes and Failover . . . . . . . . . . . . . . 22 | |||

8.8. Controller Operation . . . . . . . . . . . . . . . . . . 21 | 8.8. Controller Operation . . . . . . . . . . . . . . . . . . 22 | |||

8.9. Verification Scope . . . . . . . . . . . . . . . . . . . 22 | 8.9. Verification Scope . . . . . . . . . . . . . . . . . . . 22 | |||

8.9.1. Node Ordering . . . . . . . . . . . . . . . . . . . . 22 | 8.9.1. Node Ordering . . . . . . . . . . . . . . . . . . . . 23 | |||

8.9.2. Stealth Nodes . . . . . . . . . . . . . . . . . . . . 22 | 8.9.2. Stealth Nodes . . . . . . . . . . . . . . . . . . . . 23 | |||

9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 23 | 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 23 | |||

10. References . . . . . . . . . . . . . . . . . . . . . . . . . 23 | 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 23 | |||

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

10.2. Informative References . . . . . . . . . . . . . . . . . 23 | 10.2. Informative References . . . . . . . . . . . . . . . . . 24 | |||

Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23 | Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24 | |||

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 4, line 19 ¶ | skipping to change at page 4, line 20 ¶ | |||

indeed traversed a specific set of service functions or nodes allows | indeed traversed a specific set of service functions or nodes allows | |||

operators to evolve from the above described indirect methods of | operators to evolve from the above described indirect methods of | |||

proving that packets visit a predetermined set of nodes. | proving that packets visit a predetermined set of nodes. | |||

The solution approach presented in this document is based on a small | The solution approach presented in this document is based on a small | |||

portion of operational data added to every packet. This "in-situ" | portion of operational data added to every packet. This "in-situ" | |||

operational data is also referred to as "proof of transit data", or | operational data is also referred to as "proof of transit data", or | |||

POT data. The POT data is updated at every required node and is used | POT data. The POT data is updated at every required node and is used | |||

to verify whether a packet traversed all required nodes. A | to verify whether a packet traversed all required nodes. A | |||

particular set of nodes "to be verified" is either described by a set | particular set of nodes "to be verified" is either described by a set | |||

of secret keys, or a set of shares of a single secret. Nodes on the | of shares of a single secret. Nodes on the path retrieve their | |||

path retrieve their individual keys or shares of a key (using for | individual shares of the secret using Shamir's Secret Sharing scheme | |||

e.g., Shamir's Secret Sharing scheme) from a central controller. The | from a central controller. The complete secret set is only known to | |||

complete key set is only known to the controller and a verifier node, | the controller and a verifier node, which is typically the ultimate | |||

which is typically the ultimate node on a path that performs | node on a path that performs verification. Each node in the path | |||

verification. Each node in the path uses its secret or share of the | uses its share of the secret to update the POT data of the packets as | |||

secret to update the POT data of the packets as the packets pass | the packets pass through the node. When the verifier receives a | |||

through the node. When the verifier receives a packet, it uses its | packet, it uses its key along with data found in the packet to | |||

key(s) along with data found in the packet to validate whether the | validate whether the packet traversed the path correctly. | |||

packet traversed the path correctly. | ||||

2. Conventions | 2. Conventions | |||

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | |||

"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this | "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this | |||

document are to be interpreted as described in [RFC2119]. | document are to be interpreted as described in [RFC2119]. | |||

Abbreviations used in this document: | Abbreviations used in this document: | |||

HMAC: Hash based Message Authentication Code. For example, | HMAC: Hash based Message Authentication Code. For example, | |||

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

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 | RND: Random Bits generated per packet. Packet fields that do | |||

donot 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. | |||

This is used in concatenation with RND bits to mitigate | This is used in concatenation with RND bits to mitigate | |||

different attacks discussed later. | different attacks discussed later. | |||

SFC: Service Function Chain | SFC: Service Function Chain | |||

SSSS: Shamir's Secret Sharing Scheme | ||||

SR: Segment Routing | SR: Segment Routing | |||

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

This section discusses methods and algorithms to provide for a "proof | This section discusses methods and algorithms to provide for a "proof | |||

of transit" for packets traversing a specific path. A path which is | of transit" for packets traversing a specific path. A path which is | |||

to be verified consists of a set of nodes. Transit of the data | to be verified consists of a set of nodes. Transit of the data | |||

packets through those nodes is to be proven. Besides the nodes, the | packets through those nodes is to be proven. Besides the nodes, the | |||

setup also includes a Controller that creates secrets and secrets | setup also includes a Controller that creates secrets and secrets | |||

shares and configures the nodes for POT operations. | shares and configures the nodes for POT operations. | |||

The methods how traffic is identified and associated to a specific | The methods how traffic is identified and associated to a specific | |||

path is outside the scope of this document. Identification could be | path is outside the scope of this document. Identification could be | |||

done using a filter (e.g., 5-tuple classifier), or an identifier | done using a filter (e.g., 5-tuple classifier), or an identifier | |||

which is already present in the packet (e.g., path or service | which is already present in the packet (e.g., path or service | |||

identifier, NSH Service Path Identifier (SPI), flow-label, etc.) | identifier, NSH Service Path Identifier (SPI), flow-label, etc.) | |||

The POT information is encapsulated in packets as an IOAM Proof Of | ||||

Transit Option. The details and format of the encapsulation and the | ||||

POT Option format are specified in [I-D.ietf-ippm-ioam-data]. | ||||

The solution approach is detailed in two steps. Initially the | The solution approach is detailed in two steps. Initially the | |||

concept of the approach is explained. This concept is then further | concept of the approach is explained. This concept is then further | |||

refined to make it operationally feasible. | refined to make it operationally feasible. | |||

3.1. Basic Idea | 3.1. Basic Idea | |||

The method relies on adding POT data to all packets that traverse a | The method relies on adding POT data to all packets that traverse a | |||

path. The added POT data allows a verifying node (egress node) to | path. The added POT data allows a verifying node (egress node) to | |||

check whether a packet traversed the identified set of nodes on a | check whether a packet traversed the identified set of nodes on a | |||

path correctly or not. Security mechanisms are natively built into | path correctly or not. Security mechanisms are natively built into | |||

the generation of the POT data to protect against misuse (i.e. | the generation of the POT data to protect against misuse (e.g., | |||

configuration mistakes, malicious administrators playing tricks with | configuration mistakes). The mechanism for POT leverages "Shamir's | |||

routing, capturing, spoofing and replaying packets). The mechanism | Secret Sharing" scheme [SSS]. | |||

for POT leverages "Shamir's Secret Sharing" scheme [SSS]. | ||||

Shamir's secret sharing base idea: A polynomial (represented by its | Shamir's secret sharing base idea: A polynomial (represented by its | |||

coefficients) is chosen as a secret by the controller. A polynomial | coefficients) of degree k is chosen as a secret by the controller. A | |||

represents a curve. A set of well-defined points on the curve are | polynomial represents a curve. A set of k+1 points on the curve | |||

needed to construct the polynomial. Each point of the polynomial is | define the polynomial and are thus needed to (re-)construct the | |||

called "share" of the secret. A single secret is associated with a | polynomial. Each of these k+1 points of the polynomial is called a | |||

particular set of nodes, which typically represent the path, to be | "share" of the secret. A single secret is associated with a | |||

verified. Shares of the single secret (i.e., points on the curve) | particular set of k+1 nodes, which typically represent the path to be | |||

are securely distributed from a Controller to the network nodes. | verified. k+1 shares of the single secret (i.e., k+1 points on the | |||

Nodes use their respective share to update a cumulative value in the | curve) are securely distributed from a Controller to the network | |||

POT data of each packet. Only a verifying node has access to the | nodes. Nodes use their respective share to update a cumulative value | |||

complete secret. The verifying node validates the correctness of the | in the POT data of each packet. Only a verifying node has access to | |||

received POT data by reconstructing the curve. | the complete secret. The verifying node validates the correctness of | |||

the received POT data by reconstructing the curve. | ||||

The polynomial cannot be constructed if any of the points are missed | The polynomial cannot be reconstructed if any of the points are | |||

or tampered. Per Shamir's Secret Sharing Scheme, any lesser points | missed or tampered. Per Shamir's Secret Sharing Scheme, any lesser | |||

means one or more nodes are missed. Details of the precise | points means one or more nodes are missed. Details of the precise | |||

configuration needed for achieving security are discussed further | configuration needed for achieving security are discussed further | |||

below. | below. | |||

While applicable in theory, a vanilla approach based on Shamir's | While applicable in theory, a vanilla approach based on Shamir's | |||

secret sharing could be easily attacked. If the same polynomial is | Secret Sharing Scheme could be easily attacked. If the same | |||

reused for every packet for a path a passive attacker could reuse the | polynomial is reused for every packet for a path a passive attacker | |||

value. As a consequence, one could consider creating a different | could reuse the value. As a consequence, one could consider creating | |||

polynomial per packet. Such an approach would be operationally | a different polynomial per packet. Such an approach would be | |||

complex. It would be complex to configure and recycle so many curves | operationally complex. It would be complex to configure and recycle | |||

and their respective points for each node. Rather than using a | so many curves and their respective points for each node. Rather | |||

single polynomial, two polynomials are used for the solution | than using a single polynomial, two polynomials are used for the | |||

approach: A secret polynomial which is kept constant, and a per- | solution approach: A secret polynomial as described above which is | |||

packet polynomial which is public. Operations are performed on the | kept constant, and a per-packet polynomial which is public and | |||

sum of those two polynomials - creating a third polynomial which is | generated by the ingress node (the first node along the path). | |||

secret and per packet. | Operations are performed on the sum of those two polynomials - | |||

creating a third polynomial which is secret and per packet. | ||||

3.2. Solution Approach | 3.2. Solution Approach | |||

Solution approach: The overall algorithm uses two polynomials: POLY-1 | Solution approach: The overall algorithm uses two polynomials: POLY-1 | |||

and POLY-2. POLY-1 is secret and constant. Each node gets a point | and POLY-2. POLY-1 is secret and constant. A different POLY-1 is | |||

on POLY-1 at setup-time and keeps it secret. POLY-2 is public, | used for each path, and its value is known to the controller and to | |||

random and per packet. Each node generates a point on POLY-2 each | the verifier of the respective path. Each node gets a point on | |||

time a packet crosses it. Each node then calculates (point on POLY-1 | POLY-1 at setup-time and keeps it secret. POLY-2 is public, random | |||

+ point on POLY-2) to get a (point on POLY-3) and passes it to | and per packet. Each node generates a point on POLY-2 each time a | |||

verifier by adding it to each packet. The verifier constructs POLY-3 | packet crosses it. Each node then calculates (point on POLY-1 + | |||

from the points given by all the nodes and cross checks whether | point on POLY-2) to get a (point on POLY-3) and passes it to verifier | |||

POLY-3 = POLY-1 + POLY-2. Only the verifier knows POLY-1. The | by adding it to each packet. The verifier constructs POLY-3 from the | |||

solution leverages finite field arithmetic in a field of size "prime | points given by all the nodes and cross checks whether POLY-3 = | |||

POLY-1 + POLY-2. Only the verifier knows POLY-1. | ||||

The solution leverages finite field arithmetic in a field of size | ||||

"prime number", i.e. all operations are performed "modulo prime | ||||

number". | number". | |||

Detailed algorithms are discussed next. A simple example is | Detailed algorithms are discussed next. A simple example that | |||

discussed in Section 3.3. | describes how the algorithms work is discussed in Section 3.3. | |||

The algorithms themselves do not constrain the ranges of possible | ||||

values for the different parameters and coefficients used. A | ||||

deployment of the algorithms will always need to define appropriate | ||||

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 | ||||

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. The constant coefficient of POLY-1 is | k+1 points on the polynomial, corresponding to the k+1 nodes along | |||

considered the SECRET. The non-constant coefficients are used to | the path. The constant coefficient of POLY-1 is considered the | |||

generate the Lagrange Polynomial Constants (LPC). Each of the k | SECRET, which is per the definition of the SSSS algorithm [SSS]. The | |||

nodes (including verifier) are assigned a point on the polynomial | non-constant coefficients are used to generate the Lagrange | |||

i.e., shares of the SECRET. The verifier is configured with the | Polynomial Constants (LPC). Each of the k+1 nodes (including | |||

SECRET. The Controller also generates coefficients (except the | verifier) are assigned a point on the polynomial i.e., shares of the | |||

constant coefficient, called "RND", which is changed on a per packet | SECRET. The verifier is configured with the SECRET. The Controller | |||

basis) of a second polynomial POLY-2 of the same degree. Each node | also generates coefficients (except the constant coefficient, called | |||

is configured with the LPC of POLY-2. Note that POLY-2 is public. | "RND", which is changed on a per packet 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. This step is | Share(POLY-2)) and CML is updated with this sum, specifically each | |||

performed by each node until the packet completes the path. The | node performs | |||

verifier also performs the step with its respective share. | ||||

CML = CML+(((Share(POLY-1)+ Share(POLY-2)) * LPC) mod Prime, with | ||||

"LPC" being the Lagrange Polynomial Constant and "Prime" being the | ||||

prime number which defines the finite field arithmetic that all | ||||

operations are done over. Please also refer to Section 3.3.2 below | ||||

for further details how the operations are performed. | ||||

This step is performed by each node until the packet completes the | ||||

path. The verifier also performs the step with its respective share. | ||||

3.2.3. Verification | 3.2.3. Verification | |||

The verifier cross checks whether CML = SECRET + RND. If this | The verifier cross checks whether CML = SECRET + RND. If this | |||

matches then the packet traversed the specified set of nodes in the | matches then the packet traversed the specified set of nodes in the | |||

path. This is due to the additive homomorphic property of Shamir's | path. This is due to the additive homomorphic property of Shamir's | |||

Secret Sharing scheme. | Secret Sharing scheme. | |||

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

This section shows a simple example to illustrate step by step the | This section shows a simple example to illustrate step by step the | |||

approach described above. | approach described above. The example assumes a network with 3 | |||

nodes. The last node that packets traverse also serves as the | ||||

verifier. A Controller communicates the required parameters to the | ||||

individual nodes. | ||||

3.3.1. Basic Version | 3.3.1. Baseline | |||

Assumption: It is to be verified whether packets passed through 3 | Assumption: It is to be verified whether packets passed through the 3 | |||

nodes. A polynomial of degree 2 is chosen for verification. | nodes. A polynomial of degree 2 is chosen for verification. | |||

Choices: Prime = 53. POLY-1(x) = (3x^2 + 3x + 10) mod 53. The | Choices: Prime = 53. POLY-1(x) = (3x^2 + 3x + 10) mod 53. The | |||

secret to be re-constructed is the constant coefficient of POLY-1, | secret to be re-constructed is the constant coefficient of POLY-1, | |||

i.e., SECRET=10. It is important to note that all operations are | i.e., SECRET=10. It is important to note that all operations are | |||

done over a finite field (i.e., modulo prime). | done over a finite field (i.e., modulo Prime = 53). | |||

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

The shares of the secret are the points on POLY-1 chosen for the 3 | The shares of the secret are the points on POLY-1 chosen for the 3 | |||

nodes. For example, let x0=2, x1=4, x2=5. | nodes. For example, let x0=2, x1=4, x2=5. | |||

POLY-1(2) = 28 => (x0, y0) = (2, 28) | POLY-1(2) = 28 => (x0, y0) = (2, 28) | |||

POLY-1(4) = 17 => (x1, y1) = (4, 17) | POLY-1(4) = 17 => (x1, y1) = (4, 17) | |||

POLY-1(5) = 47 => (x2, y2) = (5, 47) | POLY-1(5) = 47 => (x2, y2) = (5, 47) | |||

The three points above are the points on the curve which are | The three points above are the points on the curve which are | |||

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

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 = | |||

skipping to change at page 8, line 44 ¶ | skipping to change at page 9, line 32 ¶ | |||

(-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. | Lagrange Polynomial Constant (LPC) would be 10/3 , -5 , 8/3.LPC are | |||

computed by the Controller and communicated to the individual nodes. | ||||

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

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

LPC(x2) = (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 | |||

skipping to change at page 9, line 16 ¶ | skipping to change at page 10, line 4 ¶ | |||

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 = mod (28 * 21 | |||

+ 17 * 48 + 47 * 38) mod 53 = 3190 mod 53 = 10 | + 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. CML represents the cumulative value. It is | cumulatively hop by hop, i.e. by every node. CML represents the | |||

the POT data in the packet that is updated at each hop with the | cumulative value. It is the POT data in the packet that is updated | |||

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

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 | |||

verifier from the packet POT data. Recall that verifier is | verifier from the packet POT data. Recall that the verifier is | |||

preconfigured with the original SECRET. It is cross checked with the | preconfigured with the original SECRET. It is cross checked with the | |||

CML by the verifier. Subsequent actions based on the verification | CML by the verifier. Subsequent actions based on the verification | |||

failing or succeeding could be taken as per the configured policies. | failing or succeeding could be taken as per the configured policies. | |||

3.3.2. Enhanced Version | 3.3.2. Complete Solution | |||

As observed previously, the vanilla algorithm that involves a single | As observed previously, the baseline algorithm that involves a single | |||

secret polynomial is not secure. Therefore, the solution is further | secret polynomial is not secure. The complete solution leverages a | |||

enhanced with usage of a random second polynomial chosen per packet. | random second polynomial, which is chosen per packet. | |||

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

Let the second polynomial POLY-2 be (RND + 7x + 10 x^2). RND is a | Let the second polynomial POLY-2 be (RND + 7x + 10 x^2). RND is a | |||

random number and is generated for each packet. Note that POLY-2 is | random number and is generated for each packet. Note that POLY-2 is | |||

public and need not be kept secret. The nodes can be pre-configured | public and need not be kept secret. The nodes can be pre-configured | |||

with the non-constant coefficients (for example, 7 and 10 in this | with the non-constant coefficients (for example, 7 and 10 in this | |||

case could be configured through the Controller on each node). So | case could be configured through the Controller on each node). So | |||

precisely only RND value changes per packet and is public and the | precisely only the RND value changes per packet and is public and the | |||

rest of the non-constant coefficients of POLY-2 kept secret. | rest of the non-constant coefficients of POLY-2 is kept secret. | |||

3.3.2.2. Reconstruction | 3.3.2.2. Reconstruction | |||

Recall that each node is preconfigured with their respective | Recall that each node is preconfigured with their respective | |||

Share(POLY-1). Each node calculates its respective Share(POLY-2) | Share(POLY-1). Each node calculates its respective Share(POLY-2) | |||

using the RND value retrieved from the packet. The CML | using the RND value retrieved from the packet. The CML | |||

reconstruction is enhanced as below. At every node, CML is updated | reconstruction is enhanced as below. At every node, CML is updated | |||

as | as | |||

CML = CML+(((Share(POLY-1)+ Share(POLY-2)) * LPC) mod Prime | CML = CML+(((Share(POLY-1)+ Share(POLY-2)) * LPC) mod Prime | |||

skipping to change at page 11, line 5 ¶ | skipping to change at page 11, line 42 ¶ | |||

As shown in the above example, for final verification, the verifier | As shown in the above example, for final verification, the verifier | |||

compares: | compares: | |||

VERIFY = (SECRET + RND) mod Prime, with Prime = 53 here | VERIFY = (SECRET + RND) mod Prime, with Prime = 53 here | |||

VERIFY = (RND-1 + RND-2) mod Prime = ( 10 + 45 ) mod 53 = 2 | VERIFY = (RND-1 + RND-2) mod Prime = ( 10 + 45 ) mod 53 = 2 | |||

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. Final Version | 3.3.3. Solution Deployment Considerations | |||

The enhanced version of the protocol is still prone to replay and | The "complete solution" described above in Section 3.3.2 could still | |||

preplay attacks. An attacker could reuse the POT metadata for | be prone to replay or preplay attacks. An attacker could e.g. reuse | |||

bypassing the verification. So additional measures using packet | the POT metadata for bypassing the verification. These threats can | |||

integrity checks (HMAC) and sequence numbers (SEQ_NO) are discussed | be mitigated by appropriate parameterization of the algorithm. | |||

later "Security Considerations" section. | Please refer to Section 8 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 | |||

skipping to change at page 12, line 7 ¶ | skipping to change at page 12, line 46 ¶ | |||

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. | |||

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

In certain scenarios preserving the order of the nodes traversed by | POT as discussed in this document so far only verifies that a defined | |||

the packet may be needed. Two alternatives, one based on "nested | set of nodes have been traversed by a packet. The order in which | |||

encryption", and another based on "symmetric masking between nodes" | nodes where traversed is not verified. "Ordered Proof of Transit | |||

are described here for preserving the order | (OPOT)" addresses the need of deployments, that require to verify the | |||

order in which nodes were traversed. OPOT extends the POT scheme | ||||

3.5.1. Nested Encryption | with symmetric masking between the nodes. | |||

1. The controller provisions all the nodes with their respective | ||||

secret keys. | ||||

2. The controller provisions the verifier with all the secret keys | ||||

of the nodes. | ||||

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

and encrypts it with its secret key to generate CML value | ||||

4. Each subsequent node on the path encrypts CML with their | ||||

respective secret key and passes it along | ||||

5. The verifier is also provisioned with the expected sequence of | ||||

nodes in order to verify the order | ||||

6. The verifier receives the CML, RND values, re-encrypts the RND | ||||

with keys in the same order as expected sequence to verify. | ||||

With this nested encryption approach it is possible to retain the | ||||

order in which the nodes are traversed, at the cost of: | ||||

1. Standard AES encryption would need 128 bits of RND, CML. This | ||||

results in a 256 bits of additional overhead is added per packet | ||||

2. In hardware platforms that do not support native encryption | ||||

capabilities like (AES-NI). This approach would have | ||||

considerable impact on the computational latency | ||||

3.5.2. Symmetric Masking Between Nodes | ||||

1. The controller provisions all the nodes with (or asks them to | 1. For each path the controller provisions all the nodes with (or | |||

agree on) a couple of secrets, that we will refer as masks, one | asks them to agree on) two secrets per node, that we will refer | |||

for the connection from the upstream node(s), another for the | to as masks, one for the connection from the upstream node(s), | |||

connection to the downstream node(s). For obvious reasons, the | another for the connection to the downstream node(s). For | |||

ingress and egress (verifier) nodes only receive one, for | obvious reasons, the ingress and egress (verifier) nodes only | |||

downstream and upstream, respectively. | receive one, for downstream and upstream, respectively. | |||

2. Any two contiguous nodes in the OPOT stream share the mask for | 2. Any two contiguous nodes in the OPOT stream share the mask for | |||

the connection between them, in the shape of symmetric keys. | the connection between them, in the shape of symmetric keys. | |||

Masks can be refreshed as per-policy, defined at each hop or | Masks can be refreshed as per-policy, defined at each hop or | |||

globally by the controller. | globally by the controller. | |||

3. Each mask has the same size in bits as the length assigned to CML | 3. Each mask has the same size in bits as the length assigned to CML | |||

plus RND, as described in the above sections. | plus RND, as described in the above sections. | |||

4. Whenever a packet is received at an intermediate node, the | 4. Whenever a packet is received at an intermediate node, the | |||

CML+RND sequence is deciphered (by XORing, though other ciphering | CML+RND sequence is deciphered (by XORing, though other ciphering | |||

schemas MAY be possible) with the upstream mask before applying | schemas MAY be possible) with the upstream mask before applying | |||

the procedures described in Section 3.3.2. | the procedures described in Section 3.3.2. | |||

skipping to change at page 14, line 32 ¶ | skipping to change at page 14, line 43 ¶ | |||

| | | 4*10^9 | | | | | | 4*10^9 | | | |||

| 100 Gbps | 32 | 2^32 = approx. | 22 seconds | | | 100 Gbps | 32 | 2^32 = approx. | 22 seconds | | |||

| | | 4*10^9 | | | | | | 4*10^9 | | | |||

+-------------+--------------+------------------+-------------------+ | +-------------+--------------+------------------+-------------------+ | |||

Table assumes 64 octet packets | Table assumes 64 octet packets | |||

Table 1: Proof of transit data sizing | Table 1: Proof of transit data sizing | |||

If the symmetric masking method for ordered POT is used | If the symmetric masking method for ordered POT is used | |||

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

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 those to the nodes. The sum of | prime number, etc.) and communicate the associated values (i.e. prime | |||

all parameters for a specific node is referred to as "POT-profile". | number, secret-share, LPC, etc.) to the nodes. The sum of all | |||

This document does not define a specific protocol to be used between | parameters for a specific node is referred to as "POT-profile". For | |||

Controller and nodes. It only defines the procedures and the | details see the YANG model in Section 5.2.This document does not | |||

associated YANG data model. | define a specific protocol to be used between Controller and nodes. | |||

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. The rate at which the POT-profiles are | and "odd" labeled profiles. This means that the parameters for the | |||

communicated to the nodes is configurable and is more frequent than | algorithms are continuously refreshed. Please refer to Section 4 for | |||

the speed at which a POT-profile is "used up" (see table above). | choosing an appropriate refresh rate: The rate at which the POT- | |||

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

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. | |||

skipping to change at page 18, line 40 ¶ | skipping to change at page 19, line 7 ¶ | |||

IANA considerations will be added in a future version of this | IANA considerations will be added in a future version of this | |||

document. | document. | |||

7. Manageability Considerations | 7. Manageability Considerations | |||

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

this document. | this document. | |||

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

Different security requirements achieved by the solution approach are | POT is a mechanism that is used for verifying the path through which | |||

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

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

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

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

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

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

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

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

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

section. | ||||

8.1. Proof of Transit | 8.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. | |||

skipping to change at page 19, line 24 ¶ | skipping to change at page 19, line 47 ¶ | |||

and non-constant coefficient of POLY-2 are secret | and non-constant coefficient of POLY-2 are secret | |||

An attacker bypassing a few nodes will miss adding a respective point | An attacker bypassing a few nodes will miss adding a respective point | |||

on POLY-1 to corresponding point on POLY-2 , thus the verifier cannot | on POLY-1 to corresponding point on POLY-2 , thus the verifier cannot | |||

construct POLY-3 for cross verification. | construct POLY-3 for cross verification. | |||

Also it is highly recommended that different polynomials should be | Also it is highly recommended that different polynomials should be | |||

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.2), the | If symmetric masking is used to assure OPOT (Section 3.5), the nodes | |||

nodes need to keep two additional secrets: the upstream 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 | 8.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 | |||

skipping to change at page 20, line 4 ¶ | skipping to change at page 20, line 27 ¶ | |||

(i.e. RND, CML-before, CML-after). The application of symmetric | (i.e. RND, CML-before, CML-after). The application of symmetric | |||

masking for OPOT makes inter-node analysis less feasible. | masking for OPOT makes inter-node analysis less feasible. | |||

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, what 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 | 8.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 to bypass certain nodes in later packets. | intermediate CML values. Thus, an attacker can attack an old | |||

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

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. | |||

Subsequently, the verifier could use the SEQ_NO bits to run classic | Subsequently, the verifier could use the SEQ_NO bits to run classic | |||

anti-replay techniques like sliding window used in IPSEC. The | anti-replay techniques like sliding window used in IPSEC. The | |||

verifier could buffer up to 2^16 packets as a sliding window. | verifier could buffer up to 2^16 packets as a sliding window. | |||

Packets arriving with a higher SEQ_NO than current buffer could be | Packets arriving with a higher SEQ_NO than current buffer could be | |||

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

skipping to change at page 21, line 13 ¶ | skipping to change at page 21, line 37 ¶ | |||

to generate RND. It is recommended to use a minimum of 32 bits. | to generate RND. It is recommended to use a minimum of 32 bits. | |||

o The verifier regenerates the HMAC from the packet fields and | o The verifier regenerates the HMAC from the packet fields and | |||

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 | |||

prereplay 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. Anti-Tampering | 8.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 | 8.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.2), mask values | If symmetric masking is used for OPOT (Section 3.5), mask values must | |||

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

other secrets are. | secrets are. | |||

8.7. Redundant Nodes and Failover | 8.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. | |||

skipping to change at page 22, line 16 ¶ | skipping to change at page 22, line 40 ¶ | |||

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.2) 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 | 8.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 | |||

skipping to change at page 23, line 18 ¶ | skipping to change at page 23, line 42 ¶ | |||

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. | |||

10. References | 10. References | |||

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

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

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

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

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

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

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

[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, DOI 10.17487/ | Requirement Levels", BCP 14, RFC 2119, | |||

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

rfc2119>. | 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, DOI 10.17487/ | Chaining (SFC) Architecture", RFC 7665, | |||

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

rfc7665>. | editor.org/info/rfc7665>. | |||

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

Shamir%27s_Secret_Sharing>. | 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. | |||

skipping to change at page 24, line 4 ¶ | skipping to change at page 24, line 34 ¶ | |||

Authors' Addresses | Authors' Addresses | |||

Frank Brockners | Frank Brockners | |||

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 | |||

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 | |||

Sashank Dara | Sashank Dara | |||

Cisco Systems, Inc. | Seconize | |||

Cessna Business Park, Sarjapura Marathalli Outer Ring Road | BANGALORE, Bangalore, KARNATAKA | |||

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

INDIA | INDIA | |||

Email: sadara@cisco.com | Email: sashank@seconize.co | |||

Carlos Pignataro | Carlos Pignataro | |||

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

7200-11 Kit Creek Road | 7200-11 Kit Creek Road | |||

Research Triangle Park, NC 27709 | Research Triangle Park, NC 27709 | |||

United States | United States | |||

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

John Leddy | John Leddy | |||

Comcast | Comcast | |||

skipping to change at page 25, line 4 ¶ | skipping to change at page 25, line 28 ¶ | |||

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 | David Mozes | |||

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

Tal Mizrahi | Tal Mizrahi | |||

Marvell | Huawei Network.IO Innovation Lab | |||

6 Hamada St. | ||||

Yokneam 20692 | ||||

Israel | Israel | |||

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

Alejandro Aguado | Alejandro Aguado | |||

Universidad Politecnica de Madrid | Universidad Politecnica de Madrid | |||

Campus Montegancedo, Boadilla del Monte | Campus Montegancedo, Boadilla del Monte | |||

Madrid 28660 | Madrid 28660 | |||

Spain | Spain | |||

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

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

Diego R. Lopez | Diego R. Lopez | |||

Telefonica I+D | Telefonica I+D | |||

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

Seville 41013 | Seville 41013 | |||

Spain | Spain | |||

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

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

End of changes. 73 change blocks. | ||||

207 lines changed or deleted | | 227 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/ |