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/