draft-ietf-sfc-proof-of-transit-02.txt   draft-ietf-sfc-proof-of-transit-03.txt 
Network Working Group F. Brockners Network Working Group F. Brockners, Ed.
Internet-Draft S. Bhandari Internet-Draft S. Bhandari, Ed.
Intended status: Experimental Cisco Intended status: Experimental Cisco
Expires: September 12, 2019 S. Dara Expires: March 14, 2020 T. Mizrahi, Ed.
Huawei Network.IO Innovation Lab
S. Dara
Seconize Seconize
C. Pignataro
Cisco
J. Leddy
Comcast
S. Youell S. Youell
JPMC JPMC
D. Mozes September 11, 2019
T. Mizrahi
Huawei Network.IO Innovation Lab
A. Aguado
Universidad Politecnica de Madrid
D. Lopez
Telefonica I+D
March 11, 2019
Proof of Transit Proof of Transit
draft-ietf-sfc-proof-of-transit-02 draft-ietf-sfc-proof-of-transit-03
Abstract Abstract
Several technologies such as Traffic Engineering (TE), Service Several technologies such as Traffic Engineering (TE), Service
Function Chaining (SFC), and policy based routing are used to steer Function Chaining (SFC), and policy based routing are used to steer
traffic through a specific, user-defined path. This document defines traffic through a specific, user-defined path. This document defines
mechanisms to securely prove that traffic transited said defined mechanisms to securely prove that traffic transited said defined
path. These mechanisms allow to securely verify whether, within a path. These mechanisms allow to securely verify whether, within a
given path, all packets traversed all the nodes that they are given path, all packets traversed all the nodes that they are
supposed to visit. supposed to visit.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 12, 2019. This Internet-Draft will expire on March 14, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Proof of Transit . . . . . . . . . . . . . . . . . . . . . . 5 3. Proof of Transit . . . . . . . . . . . . . . . . . . . . . . 5
3.1. Basic Idea . . . . . . . . . . . . . . . . . . . . . . . 6 3.1. Basic Idea . . . . . . . . . . . . . . . . . . . . . . . 5
3.2. Solution Approach . . . . . . . . . . . . . . . . . . . . 7 3.2. Solution Approach . . . . . . . . . . . . . . . . . . . . 6
3.2.1. Setup . . . . . . . . . . . . . . . . . . . . . . . . 7 3.2.1. Setup . . . . . . . . . . . . . . . . . . . . . . . . 7
3.2.2. In Transit . . . . . . . . . . . . . . . . . . . . . 7 3.2.2. In Transit . . . . . . . . . . . . . . . . . . . . . 7
3.2.3. Verification . . . . . . . . . . . . . . . . . . . . 8 3.2.3. Verification . . . . . . . . . . . . . . . . . . . . 8
3.3. Illustrative Example . . . . . . . . . . . . . . . . . . 8 3.3. Illustrative Example . . . . . . . . . . . . . . . . . . 8
3.3.1. Baseline . . . . . . . . . . . . . . . . . . . . . . 8 3.3.1. Baseline . . . . . . . . . . . . . . . . . . . . . . 8
3.3.1.1. Secret Shares . . . . . . . . . . . . . . . . . . 8 3.3.1.1. Secret Shares . . . . . . . . . . . . . . . . . . 8
3.3.1.2. Lagrange Polynomials . . . . . . . . . . . . . . 9 3.3.1.2. Lagrange Polynomials . . . . . . . . . . . . . . 9
3.3.1.3. LPC Computation . . . . . . . . . . . . . . . . . 9 3.3.1.3. LPC Computation . . . . . . . . . . . . . . . . . 9
3.3.1.4. Reconstruction . . . . . . . . . . . . . . . . . 9 3.3.1.4. Reconstruction . . . . . . . . . . . . . . . . . 9
3.3.1.5. Verification . . . . . . . . . . . . . . . . . . 10 3.3.1.5. Verification . . . . . . . . . . . . . . . . . . 10
3.3.2. Complete Solution . . . . . . . . . . . . . . . . . . 10 3.3.2. Complete Solution . . . . . . . . . . . . . . . . . . 10
3.3.2.1. Random Polynomial . . . . . . . . . . . . . . . . 10 3.3.2.1. Random Polynomial . . . . . . . . . . . . . . . . 10
3.3.2.2. Reconstruction . . . . . . . . . . . . . . . . . 10 3.3.2.2. Reconstruction . . . . . . . . . . . . . . . . . 10
3.3.2.3. Verification . . . . . . . . . . . . . . . . . . 11 3.3.2.3. Verification . . . . . . . . . . . . . . . . . . 11
3.3.3. Solution Deployment Considerations . . . . . . . . . 11 3.3.3. Solution Deployment Considerations . . . . . . . . . 11
3.4. Operational Aspects . . . . . . . . . . . . . . . . . . . 12 3.4. Operational Aspects . . . . . . . . . . . . . . . . . . . 12
3.5. Ordered POT (OPOT) . . . . . . . . . . . . . . . . . . . 12 3.5. Ordered POT (OPOT) . . . . . . . . . . . . . . . . . . . 12
4. Sizing the Data for Proof of Transit . . . . . . . . . . . . 13 4. Sizing the Data for Proof of Transit . . . . . . . . . . . . 13
5. Node Configuration . . . . . . . . . . . . . . . . . . . . . 14 5. Node Configuration . . . . . . . . . . . . . . . . . . . . . 14
5.1. Procedure . . . . . . . . . . . . . . . . . . . . . . . . 15 5.1. Procedure . . . . . . . . . . . . . . . . . . . . . . . . 15
5.2. YANG Model . . . . . . . . . . . . . . . . . . . . . . . 15 5.2. YANG Model for POT . . . . . . . . . . . . . . . . . . . 15
5.2.1. Main Parameters . . . . . . . . . . . . . . . . . . . 16
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 5.2.2. Tree Diagram . . . . . . . . . . . . . . . . . . . . 16
7. Manageability Considerations . . . . . . . . . . . . . . . . 18 5.2.3. YANG Model . . . . . . . . . . . . . . . . . . . . . 17
8. Security Considerations . . . . . . . . . . . . . . . . . . . 19 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
8.1. Proof of Transit . . . . . . . . . . . . . . . . . . . . 19 7. Security Considerations . . . . . . . . . . . . . . . . . . . 20
8.2. Cryptanalysis . . . . . . . . . . . . . . . . . . . . . . 20 7.1. Proof of Transit . . . . . . . . . . . . . . . . . . . . 21
8.3. Anti-Replay . . . . . . . . . . . . . . . . . . . . . . . 20 7.2. Cryptanalysis . . . . . . . . . . . . . . . . . . . . . . 21
8.4. Anti-Preplay . . . . . . . . . . . . . . . . . . . . . . 21 7.3. Anti-Replay . . . . . . . . . . . . . . . . . . . . . . . 22
8.5. Tampering . . . . . . . . . . . . . . . . . . . . . . . . 21 7.4. Anti-Preplay . . . . . . . . . . . . . . . . . . . . . . 23
8.6. Recycling . . . . . . . . . . . . . . . . . . . . . . . . 21 7.5. Tampering . . . . . . . . . . . . . . . . . . . . . . . . 23
8.7. Redundant Nodes and Failover . . . . . . . . . . . . . . 22 7.6. Recycling . . . . . . . . . . . . . . . . . . . . . . . . 23
8.8. Controller Operation . . . . . . . . . . . . . . . . . . 22 7.7. Redundant Nodes and Failover . . . . . . . . . . . . . . 24
8.9. Verification Scope . . . . . . . . . . . . . . . . . . . 22 7.8. Controller Operation . . . . . . . . . . . . . . . . . . 24
8.9.1. Node Ordering . . . . . . . . . . . . . . . . . . . . 23 7.9. Verification Scope . . . . . . . . . . . . . . . . . . . 24
8.9.2. Stealth Nodes . . . . . . . . . . . . . . . . . . . . 23 7.9.1. Node Ordering . . . . . . . . . . . . . . . . . . . . 25
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 23 7.9.2. Stealth Nodes . . . . . . . . . . . . . . . . . . . . 25
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 23 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 25
10.1. Normative References . . . . . . . . . . . . . . . . . . 23 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 25
10.2. Informative References . . . . . . . . . . . . . . . . . 24 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 26
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24 10.1. Normative References . . . . . . . . . . . . . . . . . . 26
10.2. Informative References . . . . . . . . . . . . . . . . . 27
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27
1. Introduction 1. Introduction
Several deployments use Traffic Engineering, policy routing, Segment Several deployments use Traffic Engineering, policy routing, Segment
Routing (SR), and Service Function Chaining (SFC) [RFC7665] to steer Routing (SR), and Service Function Chaining (SFC) [RFC7665] to steer
packets through a specific set of nodes. In certain cases, packets through a specific set of nodes. In certain cases,
regulatory obligations or a compliance policy require operators to regulatory obligations or a compliance policy require operators to
prove that all packets that are supposed to follow a specific path prove that all packets that are supposed to follow a specific path
are indeed being forwarded across and exact set of pre-determined are indeed being forwarded across and exact set of pre-determined
nodes. nodes.
skipping to change at page 5, line 4 skipping to change at page 4, line 45
LISP: Locator/ID Separation Protocol LISP: Locator/ID Separation Protocol
LPC: Lagrange Polynomial Constants LPC: Lagrange Polynomial Constants
MTU: Maximum Transmit Unit MTU: Maximum Transmit Unit
NFV: Network Function Virtualization NFV: Network Function Virtualization
NSH: Network Service Header NSH: Network Service Header
POT: Proof of Transit POT: Proof of Transit
POT-profile: Proof of Transit Profile that has the necessary data POT-Profile: Proof of Transit Profile that has the necessary data
for nodes to participate in proof of transit for nodes to participate in proof of transit
RND: Random Bits generated per packet. Packet fields that do RND: Random Bits generated per packet. Packet fields that do
not change during the traversal are given as input to not change during the traversal are given as input to
HMAC-256 algorithm. A minimum of 32 bits (left most) need HMAC-256 algorithm. A minimum of 32 bits (left most) need
to be used from the output if RND is used to verify the to be used from the output if RND is used to verify the
packet integrity. This is a standard recommendation by packet integrity. This is a standard recommendation by
NIST. NIST.
SEQ_NO: Sequence number initialized to a predefined constant. SEQ_NO: Sequence number initialized to a predefined constant.
skipping to change at page 7, line 39 skipping to change at page 7, line 27
ranges. Please refer to the YANG model in Section 5.2 for details on ranges. Please refer to the YANG model in Section 5.2 for details on
the units and ranges of possible values of the different parameters the units and ranges of possible values of the different parameters
and coefficients. and coefficients.
3.2.1. Setup 3.2.1. Setup
A controller generates a first polynomial (POLY-1) of degree k and A controller generates a first polynomial (POLY-1) of degree k and
k+1 points on the polynomial, corresponding to the k+1 nodes along k+1 points on the polynomial, corresponding to the k+1 nodes along
the path. The constant coefficient of POLY-1 is considered the the path. The constant coefficient of POLY-1 is considered the
SECRET, which is per the definition of the SSSS algorithm [SSS]. The SECRET, which is per the definition of the SSSS algorithm [SSS]. The
non-constant coefficients are used to generate the Lagrange k+1 points are used to derive the Lagrange Basis Polynomials. The
Polynomial Constants (LPC). Each of the k+1 nodes (including Lagrange Polynomial Constants (LPC) are retrieved from the constant
verifier) are assigned a point on the polynomial i.e., shares of the coefficients of the Lagrange Basis Polynomials. Each of the k+1
SECRET. The verifier is configured with the SECRET. The Controller nodes (including verifier) are assigned a point on the polynomial
also generates coefficients (except the constant coefficient, called i.e., shares of the SECRET. The verifier is configured with the
"RND", which is changed on a per packet basis) of a second polynomial SECRET. The Controller also generates coefficients (except the
POLY-2 of the same degree. Each node is configured with the LPC of constant coefficient, called "RND", which is changed on a per packet
POLY-2. Note that POLY-2 is public. basis) of a second polynomial POLY-2 of the same degree. Each node
is configured with the LPC of POLY-2. Note that POLY-2 is public.
3.2.2. In Transit 3.2.2. In Transit
For each packet, the ingress node generates a random number (RND). For each packet, the ingress node generates a random number (RND).
It is considered as the constant coefficient for POLY-2. A It is considered as the constant coefficient for POLY-2. A
cumulative value (CML) is initialized to 0. Both RND, CML are cumulative value (CML) is initialized to 0. Both RND, CML are
carried as within the packet POT data. As the packet visits each carried as within the packet POT data. As the packet visits each
node, the RND is retrieved from the packet and the respective share node, the RND is retrieved from the packet and the respective share
of POLY-2 is calculated. Each node calculates (Share(POLY-1) + of POLY-2 is calculated. Each node calculates (Share(POLY-1) +
Share(POLY-2)) and CML is updated with this sum, specifically each Share(POLY-2)) and CML is updated with this sum, specifically each
skipping to change at page 9, line 17 skipping to change at page 9, line 12
considered the shares of the secret. They are assigned by the considered the shares of the secret. They are assigned by the
Controller to three nodes respectively and are kept secret. Controller to three nodes respectively and are kept secret.
3.3.1.2. Lagrange Polynomials 3.3.1.2. Lagrange Polynomials
Lagrange basis polynomials (or Lagrange polynomials) are used for Lagrange basis polynomials (or Lagrange polynomials) are used for
polynomial interpolation. For a given set of points on the curve polynomial interpolation. For a given set of points on the curve
Lagrange polynomials (as defined below) are used to reconstruct the Lagrange polynomials (as defined below) are used to reconstruct the
curve and thus reconstruct the complete secret. curve and thus reconstruct the complete secret.
l0(x) = (((x-x1) / (x0-x1)) * ((x-x2)/x0-x2))) mod 53 = l0(x) = (((x-x1) / (x0-x1)) * ((x-x2)/x0-x2))) mod 53
(((x-4) / (2-4)) * ((x-5)/2-5))) mod 53 = = (((x-4) / (2-4)) * ((x-5)/2-5))) mod 53
(10/3 - 3x/2 + (1/6)x^2) mod 53 = (10/3 - 3x/2 + (1/6)x^2) mod 53
l1(x) = (((x-x0) / (x1-x0)) * ((x-x2)/x1-x2))) mod 53 = l1(x) = (((x-x0) / (x1-x0)) * ((x-x2)/x1-x2))) mod 53
(-5 + 7x/2 - (1/2)x^2) mod 53 = (-5 + 7x/2 - (1/2)x^2) mod 53
l2(x) = (((x-x0) / (x2-x0)) * ((x-x1)/x2-x1))) mod 53 = l2(x) = (((x-x0) / (x2-x0)) * ((x-x1)/x2-x1))) mod 53
(8/3 - 2 + (1/3)x^2) mod 53 = (8/3 - 2 + (1/3)x^2) mod 53
3.3.1.3. LPC Computation 3.3.1.3. LPC Computation
Since x0=2, x1=4, x2=5 are chosen points. Given that computations Since x0=2, x1=4, x2=5 are chosen points. Given that computations
are done over a finite arithmetic field ("modulo a prime number"), are done over a finite arithmetic field ("modulo a prime number"),
the Lagrange basis polynomial constants are computed modulo 53. The the Lagrange basis polynomial constants are computed modulo 53. The
Lagrange Polynomial Constant (LPC) would be 10/3 , -5 , 8/3.LPC are Lagrange Polynomial Constants (LPC) would be mod(10/3, 53), mod(-5,
computed by the Controller and communicated to the individual nodes. 53), mod(8/3, 53).LPC are computed by the Controller and communicated
to the individual nodes.
LPC(l0) = (10/3) mod 53 = 21 LPC(l0) = (10/3) mod 53 = 21
LPC(l1) = (-5) mod 53 = 48 LPC(l1) = (-5) mod 53 = 48
LPC(l2) = (8/3) mod 53 = 38 LPC(l2) = (8/3) mod 53 = 38
For a general way to compute the modular multiplicative inverse, see For a general way to compute the modular multiplicative inverse, see
e.g., the Euclidean algorithm. e.g., the Euclidean algorithm.
3.3.1.4. Reconstruction 3.3.1.4. Reconstruction
Reconstruction of the polynomial is well-defined as Reconstruction of the polynomial is well-defined as
POLY1(x) = l0(x) * y0 + l1(x) * y1 + l2(x) * y2 POLY1(x) = l0(x) * y0 + l1(x) * y1 + l2(x) * y2
Subsequently, the SECRET, which is the constant coefficient of Subsequently, the SECRET, which is the constant coefficient of
POLY1(x) can be computed as below POLY1(x) can be computed as below
SECRET = (y0*LPC(l0)+y1*LPC(l1)+y2*LPC(l2)) mod 53
SECRET = (y0*LPC(l0)+y1*LPC(l1)+y2*LPC(l2)) mod 53
The secret can be easily reconstructed using the y-values and the The secret can be easily reconstructed using the y-values and the
LPC: LPC:
SECRET = (y0*LPC(l0) + y1*LPC(l1) + y2*LPC(l2)) mod 53 = mod (28 * 21 SECRET = (y0*LPC(l0) + y1*LPC(l1) + y2*LPC(l2)) mod 53
+ 17 * 48 + 47 * 38) mod 53 = 3190 mod 53 = 10 = (28 * 21 + 17 * 48 + 47 * 38) mod 53
= 3190 mod 53
= 10
One observes that the secret reconstruction can easily be performed One observes that the secret reconstruction can easily be performed
cumulatively hop by hop, i.e. by every node. CML represents the cumulatively hop by hop, i.e. by every node. CML represents the
cumulative value. It is the POT data in the packet that is updated cumulative value. It is the POT data in the packet that is updated
at each hop with the node's respective (yi*LPC(i)), where i is their at each hop with the node's respective (yi*LPC(i)), where i is their
respective value. respective value.
3.3.1.5. Verification 3.3.1.5. Verification
Upon completion of the path, the resulting CML is retrieved by the Upon completion of the path, the resulting CML is retrieved by the
skipping to change at page 11, line 48 skipping to change at page 11, line 48
Since VERIFY = CML the packet is proven to have gone through nodes 1, Since VERIFY = CML the packet is proven to have gone through nodes 1,
2, and 3. 2, and 3.
3.3.3. Solution Deployment Considerations 3.3.3. Solution Deployment Considerations
The "complete solution" described above in Section 3.3.2 could still The "complete solution" described above in Section 3.3.2 could still
be prone to replay or preplay attacks. An attacker could e.g. reuse be prone to replay or preplay attacks. An attacker could e.g. reuse
the POT metadata for bypassing the verification. These threats can the POT metadata for bypassing the verification. These threats can
be mitigated by appropriate parameterization of the algorithm. be mitigated by appropriate parameterization of the algorithm.
Please refer to Section 8 for details. Please refer to Section 7 for details.
3.4. Operational Aspects 3.4. Operational Aspects
To operationalize this scheme, a central controller is used to To operationalize this scheme, a central controller is used to
generate the necessary polynomials, the secret share per node, the generate the necessary polynomials, the secret share per node, the
prime number, etc. and distributing the data to the nodes prime number, etc. and distributing the data to the nodes
participating in proof of transit. The identified node that performs participating in proof of transit. The identified node that performs
the verification is provided with the verification key. The the verification is provided with the verification key. The
information provided from the Controller to each of the nodes information provided from the Controller to each of the nodes
participating in proof of transit is referred to as a proof of participating in proof of transit is referred to as a proof of
transit profile (POT-profile). Also note that the set of nodes for transit profile (POT-Profile). Also note that the set of nodes for
which the transit has to be proven are typically associated to a which the transit has to be proven are typically associated to a
different trust domain than the verifier. Note that building the different trust domain than the verifier. Note that building the
trust relationship between the Controller and the nodes is outside trust relationship between the Controller and the nodes is outside
the scope of this document. Techniques such as those described in the scope of this document. Techniques such as those described in
[I-D.ietf-anima-autonomic-control-plane] might be applied. [I-D.ietf-anima-autonomic-control-plane] might be applied.
To optimize the overall data amount of exchanged and the processing To optimize the overall data amount of exchanged and the processing
at the nodes the following optimizations are performed: at the nodes the following optimizations are performed:
1. The points (x, y) for each of the nodes on the public and private 1. The points (x, y) for each of the nodes on the public and private
polynomials are picked such that the x component of the points polynomials are picked such that the x component of the points
match. This lends to the LPC values which are used to calculate match. This lends to the LPC values which are used to calculate
the cumulative value CML to be constant. Note that the LPC are the cumulative value CML to be constant. Note that the LPC are
only depending on the x components. They can be computed at the only depending on the x components. They can be computed at the
controller and communicated to the nodes. Otherwise, one would controller and communicated to the nodes. Otherwise, one would
need to distributed the x components to all the nodes. need to distributed the x components to all the nodes.
2. A pre-evaluated portion of the public polynomial for each of the 2. A pre-evaluated portion of the public polynomial for each of the
nodes is calculated and added to the POT-profile. Without this nodes is calculated and added to the POT-Profile. Without this
all the coefficients of the public polynomial had to be added to all the coefficients of the public polynomial had to be added to
the POT profile and each node had to evaluate them. As stated the POT profile and each node had to evaluate them. As stated
before, the public portion is only the constant coefficient RND before, the public portion is only the constant coefficient RND
value, the pre-evaluated portion for each node should be kept value, the pre-evaluated portion for each node should be kept
secret as well. secret as well.
3. To provide flexibility on the size of the cumulative and random 3. To provide flexibility on the size of the cumulative and random
numbers carried in the POT data a field to indicate this is numbers carried in the POT data a field to indicate this is
shared and interpreted at the nodes. shared and interpreted at the nodes.
skipping to change at page 15, line 4 skipping to change at page 15, line 4
(Section 3.5), the masks used between nodes adjacent in the path MUST (Section 3.5), the masks used between nodes adjacent in the path MUST
have a length equal to the sum of the ones of RND and CML. have a length equal to the sum of the ones of RND and CML.
5. Node Configuration 5. Node Configuration
A POT system consists of a number of nodes that participate in POT A POT system consists of a number of nodes that participate in POT
and a Controller, which serves as a control and configuration entity. and a Controller, which serves as a control and configuration entity.
The Controller is to create the required parameters (polynomials, The Controller is to create the required parameters (polynomials,
prime number, etc.) and communicate the associated values (i.e. prime prime number, etc.) and communicate the associated values (i.e. prime
number, secret-share, LPC, etc.) to the nodes. The sum of all number, secret-share, LPC, etc.) to the nodes. The sum of all
parameters for a specific node is referred to as "POT-profile". For parameters for a specific node is referred to as "POT-Profile". For
details see the YANG model in Section 5.2.This document does not details see the YANG model in Section 5.2.This document does not
define a specific protocol to be used between Controller and nodes. define a specific protocol to be used between Controller and nodes.
It only defines the procedures and the associated YANG data model. It only defines the procedures and the associated YANG data model.
5.1. Procedure 5.1. Procedure
The Controller creates new POT-profiles at a constant rate and The Controller creates new POT-Profiles at a constant rate and
communicates the POT-profile to the nodes. The controller labels a communicates the POT-Profile to the nodes. The controller labels a
POT-profile "even" or "odd" and the Controller cycles between "even" POT-Profile "even" or "odd" and the Controller cycles between "even"
and "odd" labeled profiles. This means that the parameters for the and "odd" labeled profiles. This means that the parameters for the
algorithms are continuously refreshed. Please refer to Section 4 for algorithms are continuously refreshed. Please refer to Section 4 for
choosing an appropriate refresh rate: The rate at which the POT- choosing an appropriate refresh rate: The rate at which the POT-
profiles are communicated to the nodes is configurable and MUST be Profiles are communicated to the nodes is configurable and MUST be
more frequent than the speed at which a POT-profile is "used up". more frequent than the speed at which a POT-Profile is "used up".
Once the POT-profile has been successfully communicated to all nodes Once the POT-Profile has been successfully communicated to all nodes
(e.g., all NETCONF transactions completed, in case NETCONF is used as (e.g., all NETCONF transactions completed, in case NETCONF is used as
a protocol), the controller sends an "enable POT-profile" request to a protocol), the controller sends an "enable POT-Profile" request to
the ingress node. the ingress node.
All nodes maintain two POT-profiles (an even and an odd POT-profile): All nodes maintain two POT-Profiles (an even and an odd POT-Profile):
One POT-profile is currently active and in use; one profile is One POT-Profile is currently active and in use; one profile is
standby and about to get used. A flag in the packet is indicating standby and about to get used. A flag in the packet is indicating
whether the odd or even POT-profile is to be used by a node. This is whether the odd or even POT-Profile is to be used by a node. This is
to ensure that during profile change the service is not disrupted. to ensure that during profile change the service is not disrupted.
If the "odd" profile is active, the Controller can communicate the If the "odd" profile is active, the Controller can communicate the
"even" profile to all nodes. Only if all the nodes have received the "even" profile to all nodes. Only if all the nodes have received the
POT-profile, the Controller will tell the ingress node to switch to POT-Profile, the Controller will tell the ingress node to switch to
the "even" profile. Given that the indicator travels within the the "even" profile. Given that the indicator travels within the
packet, all nodes will switch to the "even" profile. The "even" packet, all nodes will switch to the "even" profile. The "even"
profile gets active on all nodes and nodes are ready to receive a new profile gets active on all nodes and nodes are ready to receive a new
"odd" profile. "odd" profile.
Unless the ingress node receives a request to switch profiles, it'll Unless the ingress node receives a request to switch profiles, it'll
continue to use the active profile. If a profile is "used up" the continue to use the active profile. If a profile is "used up" the
ingress node will recycle the active profile and start over (this ingress node will recycle the active profile and start over (this
could give rise to replay attacks in theory - but with 2^32 or 2^64 could give rise to replay attacks in theory - but with 2^32 or 2^64
packets this isn't really likely in reality). packets this isn't really likely in reality).
5.2. YANG Model 5.2. YANG Model for POT
This section defines that YANG data model for the information This section defines that YANG data model for the information
exchange between the Controller and the nodes. exchange between the Controller and the node.
5.2.1. Main Parameters
The main parameters for the information exchange between the
Controller and the node used in the YANG model are as follows:
o pot-profile-index: Section 5.1 details that two POT-Profiles are
used. Only one of the POT-Profiles is active at a given point in
time, allowing the Controller to refresh the non-active one for
future use. pot-profile-index defines which of the POT-Profiles
(the "even" or "odd" POT-Profile) is currently active. pot-
profile-index will be set in the first hop of the path or chain.
Other nodes will not use this field.
o prime-number: Prime number used for module math computation.
o secret-share: Share of the secret of polynomial-1 used in
computation for the node. If POLY-1 is defined by points (x1_i,
y1_i) with i=0,..k, then for node i, the secret-share will be
y1_i.
o public-polynomial: Public polynomial value for the node.. If
POLY-2 is defined by points (x2_i, y2_i) with i=0,..k, then for
node i, the secret-share will be y2_i.
o lpc: Lagrange Polynomial Coefficient for the node, i.e. for node
i, this would be LPC(l_i), with l_i being the i-th Lagrange Basis
Polynomial.
o validator?: True if the node is a verifier node.
o validator-key?: The validator-key represents the SECRET as
described in the sections above. The SECRET is the constant
coefficient of POLY-1(z). If POLY-1(z) = a_0 + a_1*z +
a_2*z^2+..+a_k*z^k, then the SECRET would be a_0.
o bitmask?: Number of bits as mask used in controlling the size of
the random value generation. 32-bits of mask is default. See
Section 4 for details.
5.2.2. Tree Diagram
This section shows a simplified graphical representation of the YANG
data model for POT. The meaning of the symbols in these diagrams is
as follows:
o Brackets "[" and "]" enclose list keys.
o Abbreviations before data node names: "rw" means configuration
(read-write), and "ro" means state data (read-only).
o Symbols after data node names: "?" means an optional node, "!"
means a presence container, and "*" denotes a list and leaf-list.
o Parentheses enclose choice and case nodes, and case nodes are also
marked with a colon (":").
o Ellipsis ("...") stands for contents of subtrees that are not
shown.
<CODE BEGINS>
module: ietf-pot-profile
+--rw pot-profiles
+--rw pot-profile-set* [pot-profile-name]
+--rw pot-profile-name string
+--rw active-profile-index? profile-index-range
+--rw pot-profile-list* [pot-profile-index]
+--rw pot-profile-index profile-index-range
+--rw prime-number uint64
+--rw secret-share uint64
+--rw public-polynomial uint64
+--rw lpc uint64
+--rw validator? boolean
+--rw validator-key? uint64
+--rw bitmask? uint64
<CODE ENDS>
5.2.3. YANG Model
<CODE BEGINS> file "ietf-pot-profile@2016-06-15.yang" <CODE BEGINS> file "ietf-pot-profile@2016-06-15.yang"
module ietf-pot-profile { module ietf-pot-profile {
yang-version 1; yang-version 1;
namespace "urn:ietf:params:xml:ns:yang:ietf-pot-profile"; namespace "urn:ietf:params:xml:ns:yang:ietf-pot-profile";
prefix ietf-pot-profile; prefix ietf-pot-profile;
organization "IETF xxx Working Group"; organization "IETF SFC Working Group";
contact ""; contact "WG Web: <https://tools.ietf.org/wg/sfc/>
WG List: <mailto:sfc@ietf.org>";
description "This module contains a collection of YANG description "This module contains a collection of YANG
definitions for proof of transit configuration definitions for proof of transit configuration
parameters. The model is meant for proof of parameters. The model is meant for proof of
transit and is targeted for communicating the transit and is targeted for communicating the
POT-profile between a controller and nodes POT-Profile between a controller and nodes
participating in proof of transit."; participating in proof of transit.";
revision 2016-06-15 { revision 2016-06-15 {
description description
"Initial revision."; "Initial revision.";
reference reference
""; "";
} }
typedef profile-index-range { typedef profile-index-range {
skipping to change at page 17, line 13 skipping to change at page 18, line 49
type uint64; type uint64;
mandatory true; mandatory true;
description description
"Prime number used for module math computation"; "Prime number used for module math computation";
} }
leaf secret-share { leaf secret-share {
type uint64; type uint64;
mandatory true; mandatory true;
description description
"Share of the secret of polynomial 1 used in computation"; "Share of the secret of polynomial-1 used
in computation for the node. If POLY-1
is defined by points (x1_i, y1_i) with
i=0,..k, then for node i, the secret-share
will be y1_i.";
} }
leaf public-polynomial { leaf public-polynomial {
type uint64; type uint64;
mandatory true; mandatory true;
description description
"Pre evaluated Public polynomial"; "Public polynomial value for the node.
If POLY-2 is defined by points (x2_i, y2_i)
with i=0,..k, then for node i,
the secret-share will be y2_i.";
} }
leaf lpc { leaf lpc {
type uint64; type uint64;
mandatory true; mandatory true;
description description
"Lagrange Polynomial Coefficient"; "Lagrange Polynomial Coefficient";
} }
leaf validator { leaf validator {
type boolean; type boolean;
default "false"; default "false";
description description
"True if the node is a verifier node"; "True if the node is a verifier node";
} }
leaf validator-key { leaf validator-key {
type uint64; type uint64;
description description
"Secret key for validating the path, constant of poly 1"; "The validator-key represents the secret.
The secret is the constant coefficient of
POLY-1(z). If POLY-1(z) =
a_0 + a_1*z + a_2*z^2+..+a_k*z^k,
then the SECRET would be a_0.";
} }
leaf bitmask { leaf bitmask {
type uint64; type uint64;
default 4294967295; default 4294967295;
description description
"Number of bits as mask used in controlling the size of the "Number of bits as mask used in controlling
random value generation. 32-bits of mask is default."; the size of the random value generation.
32-bits of mask is default.";
} }
} }
} }
container pot-profiles { container pot-profiles {
description "A group of proof of transit profiles."; description "A group of proof of transit profiles.";
list pot-profile-set { list pot-profile-set {
key "pot-profile-name"; key "pot-profile-name";
ordered-by user; ordered-by user;
description description
"Set of proof of transit profiles that group parameters "Set of proof of transit profiles that group parameters
required to classify and compute proof of transit required to classify and compute proof of transit
metadata at a node"; metadata at a node";
skipping to change at page 18, line 25 skipping to change at page 20, line 28
leaf pot-profile-name { leaf pot-profile-name {
type string; type string;
mandatory true; mandatory true;
description description
"Unique identifier for each proof of transit profile"; "Unique identifier for each proof of transit profile";
} }
leaf active-profile-index { leaf active-profile-index {
type profile-index-range; type profile-index-range;
description description
"Proof of transit profile index that is currently active. "POT-Profile index that is currently active.
Will be set in the first hop of the path or chain. Will be set in the first hop of the path or chain.
Other nodes will not use this field."; Other nodes will not use this field.";
} }
uses pot-profile; uses pot-profile;
} }
/*** Container: end ***/ /*** Container: end ***/
} }
/*** module: end ***/ /*** module: end ***/
} }
<CODE ENDS> <CODE ENDS>
6. IANA Considerations 6. IANA Considerations
IANA considerations will be added in a future version of this This document does not require any actions from IANA.
document.
7. Manageability Considerations
Manageability considerations will be addressed in a later version of
this document.
8. Security Considerations 7. Security Considerations
POT is a mechanism that is used for verifying the path through which POT is a mechanism that is used for verifying the path through which
a packet was forwarded. The security considerations of IOAM in a packet was forwarded. The security considerations of IOAM in
general are discussed in [I-D.ietf-ippm-ioam-data]. Specifically, it general are discussed in [I-D.ietf-ippm-ioam-data]. Specifically, it
is assumed that POT is used in a confined network domain, and is assumed that POT is used in a confined network domain, and
therefore the potential threats that POT is intended to mitigate therefore the potential threats that POT is intended to mitigate
should be viewed accordingly. POT prevents spoofing and tampering; should be viewed accordingly. POT prevents spoofing and tampering;
an attacker cannot maliciously create a bogus POT or modify a an attacker cannot maliciously create a bogus POT or modify a
legitimate one. Furthermore, a legitimate node that takes part in legitimate one. Furthermore, a legitimate node that takes part in
the POT protocol cannot masquerade as another node along the path. the POT protocol cannot masquerade as another node along the path.
These considerations are discussed in detail in the rest of this These considerations are discussed in detail in the rest of this
section. section.
8.1. Proof of Transit 7.1. Proof of Transit
Proof of correctness and security of the solution approach is per Proof of correctness and security of the solution approach is per
Shamir's Secret Sharing Scheme [SSS]. Cryptographically speaking it Shamir's Secret Sharing Scheme [SSS]. Cryptographically speaking it
achieves information-theoretic security i.e., it cannot be broken by achieves information-theoretic security i.e., it cannot be broken by
an attacker even with unlimited computing power. As long as the an attacker even with unlimited computing power. As long as the
below conditions are met it is impossible for an attacker to bypass below conditions are met it is impossible for an attacker to bypass
one or multiple nodes without getting caught. one or multiple nodes without getting caught.
o If there are k+1 nodes in the path, the polynomials (POLY-1, POLY- o If there are k+1 nodes in the path, the polynomials (POLY-1, POLY-
2) should be of degree k. Also k+1 points of POLY-1 are chosen 2) should be of degree k. Also k+1 points of POLY-1 are chosen
skipping to change at page 20, line 5 skipping to change at page 21, line 45
used as POLY-1 across different paths, traffic profiles or service used as POLY-1 across different paths, traffic profiles or service
chains. chains.
If symmetric masking is used to assure OPOT (Section 3.5), the nodes If symmetric masking is used to assure OPOT (Section 3.5), the nodes
need to keep two additional secrets: the downstream and upstream need to keep two additional secrets: the downstream and upstream
masks, that have to be managed under the same conditions as the masks, that have to be managed under the same conditions as the
secrets mentioned above. And it is equally recommended to employ a secrets mentioned above. And it is equally recommended to employ a
different set of mask pairs across different paths, traffic profiles different set of mask pairs across different paths, traffic profiles
or service chains. or service chains.
8.2. Cryptanalysis 7.2. Cryptanalysis
A passive attacker could try to harvest the POT data (i.e., CML, RND A passive attacker could try to harvest the POT data (i.e., CML, RND
values) in order to determine the configured secrets. Subsequently values) in order to determine the configured secrets. Subsequently
two types of differential analysis for guessing the secrets could be two types of differential analysis for guessing the secrets could be
done. done.
o Inter-Node: A passive attacker observing CML values across nodes o Inter-Node: A passive attacker observing CML values across nodes
(i.e., as the packets entering and leaving), cannot perform (i.e., as the packets entering and leaving), cannot perform
differential analysis to construct the points on POLY-1. This is differential analysis to construct the points on POLY-1. This is
because at each point there are four unknowns (i.e. Share(POLY- because at each point there are four unknowns (i.e. Share(POLY-
skipping to change at page 20, line 30 skipping to change at page 22, line 23
o Inter-Packets: A passive attacker could observe CML values across o Inter-Packets: A passive attacker could observe CML values across
packets (i.e., values of PKT-1 and subsequent PKT-2), in order to packets (i.e., values of PKT-1 and subsequent PKT-2), in order to
predict the secrets. Differential analysis across packets could predict the secrets. Differential analysis across packets could
be mitigated using a good PRNG for generating RND. Note that if be mitigated using a good PRNG for generating RND. Note that if
constant coefficient is a sequence number than CML values become constant coefficient is a sequence number than CML values become
quite predictable and the scheme would be broken. If symmetric quite predictable and the scheme would be broken. If symmetric
masking is used for OPOT, inter-packet analysis could be applied masking is used for OPOT, inter-packet analysis could be applied
to guess mask values, which requires a proper refresh rate for to guess mask values, which requires a proper refresh rate for
masks, at least as high as the one used for LPCs. masks, at least as high as the one used for LPCs.
8.3. Anti-Replay 7.3. Anti-Replay
A passive attacker could reuse a set of older RND and the A passive attacker could reuse a set of older RND and the
intermediate CML values. Thus, an attacker can attack an old intermediate CML values. Thus, an attacker can attack an old
(replayed) RND and CML with a new packet in order to bypass some of (replayed) RND and CML with a new packet in order to bypass some of
the nodes along the path. the nodes along the path.
Such attacks could be avoided by carefully choosing POLY-2 as a Such attacks could be avoided by carefully choosing POLY-2 as a
(SEQ_NO + RND). For example, if 64 bits are being used for POLY-2 (SEQ_NO + RND). For example, if 64 bits are being used for POLY-2
then first 16 bits could be a sequence number SEQ_NO and next 48 bits then first 16 bits could be a sequence number SEQ_NO and next 48 bits
could be a random number. could be a random number.
skipping to change at page 21, line 9 skipping to change at page 23, line 5
flagged legitimate. Packets arriving with a lower SEQ_NO than flagged legitimate. Packets arriving with a lower SEQ_NO than
current buffer could be flagged as suspicious. current buffer could be flagged as suspicious.
For all practical purposes in the rest of the document RND means For all practical purposes in the rest of the document RND means
SEQ_NO + RND to keep it simple. SEQ_NO + RND to keep it simple.
The solution discussed in this memo does not currently mitigate The solution discussed in this memo does not currently mitigate
replay attacks. An anti-replay mechanism may be included in future replay attacks. An anti-replay mechanism may be included in future
versions of the solution. versions of the solution.
8.4. Anti-Preplay 7.4. Anti-Preplay
An active attacker could try to perform a man-in-the-middle (MITM) An active attacker could try to perform a man-in-the-middle (MITM)
attack by extracting the POT of PKT-1 and using it in PKT-2. attack by extracting the POT of PKT-1 and using it in PKT-2.
Subsequently attacker drops the PKT-1 in order to avoid duplicate POT Subsequently attacker drops the PKT-1 in order to avoid duplicate POT
values reaching the verifier. If the PKT-1 reaches the verifier, values reaching the verifier. If the PKT-1 reaches the verifier,
then this attack is same as Replay attacks discussed before. then this attack is same as Replay attacks discussed before.
Preplay attacks are possible since the POT metadata is not dependent Preplay attacks are possible since the POT metadata is not dependent
on the packet fields. Below steps are recommended for remediation: on the packet fields. Below steps are recommended for remediation:
skipping to change at page 21, line 40 skipping to change at page 23, line 36
compares with RND. To ensure the POT data is in fact that of the compares with RND. To ensure the POT data is in fact that of the
packet. packet.
If an HMAC is used, an active attacker lacks the knowledge of the If an HMAC is used, an active attacker lacks the knowledge of the
pre-shared key, and thus cannot launch preplay attacks. pre-shared key, and thus cannot launch preplay attacks.
The solution discussed in this memo does not currently mitigate The solution discussed in this memo does not currently mitigate
preplay attacks. A mitigation mechanism may be included in future preplay attacks. A mitigation mechanism may be included in future
versions of the solution. versions of the solution.
8.5. Tampering 7.5. Tampering
An active attacker could not insert any arbitrary value for CML. An active attacker could not insert any arbitrary value for CML.
This would subsequently fail the reconstruction of the POLY-3. Also This would subsequently fail the reconstruction of the POLY-3. Also
an attacker could not update the CML with a previously observed an attacker could not update the CML with a previously observed
value. This could subsequently be detected by using timestamps value. This could subsequently be detected by using timestamps
within the RND value as discussed above. within the RND value as discussed above.
8.6. Recycling 7.6. Recycling
The solution approach is flexible for recycling long term secrets The solution approach is flexible for recycling long term secrets
like POLY-1. All the nodes could be periodically updated with shares like POLY-1. All the nodes could be periodically updated with shares
of new SECRET as best practice. The table above could be consulted of new SECRET as best practice. The table above could be consulted
for refresh cycles (see Section 4). for refresh cycles (see Section 4).
If symmetric masking is used for OPOT (Section 3.5), mask values must If symmetric masking is used for OPOT (Section 3.5), mask values must
be periodically updated as well, at least as frequently as the other be periodically updated as well, at least as frequently as the other
secrets are. secrets are.
8.7. Redundant Nodes and Failover 7.7. Redundant Nodes and Failover
A "node" or "service" in terms of POT can be implemented by one or A "node" or "service" in terms of POT can be implemented by one or
multiple physical entities. In case of multiple physical entities multiple physical entities. In case of multiple physical entities
(e.g., for load-balancing, or business continuity situations - (e.g., for load-balancing, or business continuity situations -
consider for example a set of firewalls), all physical entities which consider for example a set of firewalls), all physical entities which
are implementing the same POT node are given that same share of the are implementing the same POT node are given that same share of the
secret. This makes multiple physical entities represent the same POT secret. This makes multiple physical entities represent the same POT
node from an algorithm perspective. node from an algorithm perspective.
8.8. Controller Operation 7.8. Controller Operation
The Controller needs to be secured given that it creates and holds The Controller needs to be secured given that it creates and holds
the secrets, as need to be the nodes. The communication between the secrets, as need to be the nodes. The communication between
Controller and the nodes also needs to be secured. As secure Controller and the nodes also needs to be secured. As secure
communication protocol such as for example NETCONF over SSH should be communication protocol such as for example NETCONF over SSH should be
chosen for Controller to node communication. chosen for Controller to node communication.
The Controller only interacts with the nodes during the initial The Controller only interacts with the nodes during the initial
configuration and thereafter at regular intervals at which the configuration and thereafter at regular intervals at which the
operator chooses to switch to a new set of secrets. In case 64 bits operator chooses to switch to a new set of secrets. In case 64 bits
are used for the data fields "CML" and "RND" which are carried within are used for the data fields "CML" and "RND" which are carried within
the data packet, the regular intervals are expected to be quite long the data packet, the regular intervals are expected to be quite long
(e.g., at 100 Gbps, a profile would only be used up after 3100 years) (e.g., at 100 Gbps, a profile would only be used up after 3100 years)
- see Section 4 above, thus even a "headless" operation without a - see Section 4 above, thus even a "headless" operation without a
Controller can be considered feasible. In such a case, the Controller can be considered feasible. In such a case, the
Controller would only be used for the initial configuration of the Controller would only be used for the initial configuration of the
POT-profiles. POT-Profiles.
If OPOT (Section 3.5) is applied using symmetric masking, the If OPOT (Section 3.5) is applied using symmetric masking, the
Controller will be required to perform a a periodic refresh of the Controller will be required to perform a a periodic refresh of the
mask pairs. The use of OPOT SHOULD be configurable as part of the mask pairs. The use of OPOT SHOULD be configurable as part of the
required level of assurance through the Controller management required level of assurance through the Controller management
interface. interface.
8.9. Verification Scope 7.9. Verification Scope
The POT solution defined in this document verifies that a data-packet The POT solution defined in this document verifies that a data-packet
traversed or transited a specific set of nodes. From an algorithm traversed or transited a specific set of nodes. From an algorithm
perspective, a "node" is an abstract entity. It could be represented perspective, a "node" is an abstract entity. It could be represented
by one or multiple physical or virtual network devices, or is could by one or multiple physical or virtual network devices, or is could
be a component within a networking device or system. The latter be a component within a networking device or system. The latter
would be the case if a forwarding path within a device would need to would be the case if a forwarding path within a device would need to
be securely verified. be securely verified.
8.9.1. Node Ordering 7.9.1. Node Ordering
POT using Shamir's secret sharing scheme as discussed in this POT using Shamir's secret sharing scheme as discussed in this
document provides for a means to verify that a set of nodes has been document provides for a means to verify that a set of nodes has been
visited by a data packet. It does not verify the order in which the visited by a data packet. It does not verify the order in which the
data packet visited the nodes. data packet visited the nodes.
In case the order in which a data packet traversed a particular set In case the order in which a data packet traversed a particular set
of nodes needs to be verified as well, the alternate schemes related of nodes needs to be verified as well, the alternate schemes related
to OPOT (Section 3.5) have to be considered. Since these schemes to OPOT (Section 3.5) have to be considered. Since these schemes
introduce at least additional control requirements, the selection of introduce at least additional control requirements, the selection of
order verification SHOULD be configurable the Controller management order verification SHOULD be configurable the Controller management
interface. interface.
8.9.2. Stealth Nodes 7.9.2. Stealth Nodes
The POT approach discussed in this document is to prove that a data The POT approach discussed in this document is to prove that a data
packet traversed a specific set of "nodes". This set could be all packet traversed a specific set of "nodes". This set could be all
nodes within a path, but could also be a subset of nodes in a path. nodes within a path, but could also be a subset of nodes in a path.
Consequently, the POT approach isn't suited to detect whether Consequently, the POT approach isn't suited to detect whether
"stealth" nodes which do not participate in proof-of-transit have "stealth" nodes which do not participate in proof-of-transit have
been inserted into a path. been inserted into a path.
9. Acknowledgements 8. Acknowledgements
The authors would like to thank Eric Vyncke, Nalini Elkins, Srihari The authors would like to thank Eric Vyncke, Nalini Elkins, Srihari
Raghavan, Ranganathan T S, Karthik Babu Harichandra Babu, Akshaya Raghavan, Ranganathan T S, Karthik Babu Harichandra Babu, Akshaya
Nadahalli, Erik Nordmark, and Andrew Yourtchenko for the comments and Nadahalli, Erik Nordmark, and Andrew Yourtchenko for the comments and
advice. advice.
9. Contributors
In addition to editors and authors listed on the title page, the
following people have contributed to this document:
Carlos Pignataro
Cisco Systems, Inc.
7200-11 Kit Creek Road
Research Triangle Park, NC 27709
United States
Email: cpignata@cisco.com
John Leddy
Email: john@leddy.net
David Mozes
Email: mosesster@gmail.com
Alejandro Aguado
Universidad Politecnica de Madrid
Campus Montegancedo, Boadilla del Monte
Madrid 28660
Spain
Phone: +34 910 673 086
Email: a.aguadom@fi.upm.es
Diego R. Lopez
Telefonica I+D
Editor Jose Manuel Lara, 9 (1-B)
Seville 41013
Spain
Phone: +34 913 129 041
Email: diego.r.lopez@telefonica.com
10. References 10. References
10.1. Normative References 10.1. Normative References
[I-D.ietf-ippm-ioam-data] [I-D.ietf-ippm-ioam-data]
Brockners, F., Bhandari, S., Pignataro, C., Gredler, H., Brockners, F., Bhandari, S., Pignataro, C., Gredler, H.,
Leddy, J., Youell, S., Mizrahi, T., Mozes, D., Lapukhov, Leddy, J., Youell, S., Mizrahi, T., Mozes, D., Lapukhov,
P., Chang, R., daniel.bernier@bell.ca, d., and J. Lemon, P., Chang, R., daniel.bernier@bell.ca, d., and J. Lemon,
"Data Fields for In-situ OAM", draft-ietf-ippm-ioam- "Data Fields for In-situ OAM", draft-ietf-ippm-ioam-
data-04 (work in progress), October 2018. data-06 (work in progress), July 2019.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, <https://www.rfc- DOI 10.17487/RFC2119, March 1997,
editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function [RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function
Chaining (SFC) Architecture", RFC 7665, Chaining (SFC) Architecture", RFC 7665,
DOI 10.17487/RFC7665, October 2015, <https://www.rfc- DOI 10.17487/RFC7665, October 2015,
editor.org/info/rfc7665>. <https://www.rfc-editor.org/info/rfc7665>.
[SSS] "Shamir's Secret Sharing", <https://en.wikipedia.org/wiki/ [SSS] "Shamir's Secret Sharing",
Shamir%27s_Secret_Sharing>. <https://en.wikipedia.org/wiki/Shamir%27s_Secret_Sharing>.
10.2. Informative References 10.2. Informative References
[I-D.ietf-anima-autonomic-control-plane] [I-D.ietf-anima-autonomic-control-plane]
Eckert, T., Behringer, M., and S. Bjarnason, "An Autonomic Eckert, T., Behringer, M., and S. Bjarnason, "An Autonomic
Control Plane (ACP)", draft-ietf-anima-autonomic-control- Control Plane (ACP)", draft-ietf-anima-autonomic-control-
plane-18 (work in progress), August 2018. plane-18 (work in progress), August 2018.
Authors' Addresses Authors' Addresses
Frank Brockners Frank Brockners (editor)
Cisco Systems, Inc. Cisco Systems, Inc.
Hansaallee 249, 3rd Floor Hansaallee 249, 3rd Floor
DUESSELDORF, NORDRHEIN-WESTFALEN 40549 DUESSELDORF, NORDRHEIN-WESTFALEN 40549
Germany Germany
Email: fbrockne@cisco.com Email: fbrockne@cisco.com
Shwetha Bhandari Shwetha Bhandari (editor)
Cisco Systems, Inc. Cisco Systems, Inc.
Cessna Business Park, Sarjapura Marathalli Outer Ring Road Cessna Business Park, Sarjapura Marathalli Outer Ring Road
Bangalore, KARNATAKA 560 087 Bangalore, KARNATAKA 560 087
India India
Email: shwethab@cisco.com Email: shwethab@cisco.com
Tal Mizrahi (editor)
Huawei Network.IO Innovation Lab
Israel
Email: tal.mizrahi.phd@gmail.com
Sashank Dara Sashank Dara
Seconize Seconize
BANGALORE, Bangalore, KARNATAKA BANGALORE, Bangalore, KARNATAKA
INDIA INDIA
Email: sashank@seconize.co Email: sashank@seconize.co
Carlos Pignataro
Cisco Systems, Inc.
7200-11 Kit Creek Road
Research Triangle Park, NC 27709
United States
Email: cpignata@cisco.com
John Leddy
Comcast
Email: John_Leddy@cable.comcast.com
Stephen Youell Stephen Youell
JP Morgan Chase JP Morgan Chase
25 Bank Street 25 Bank Street
London E14 5JP London E14 5JP
United Kingdom United Kingdom
Email: stephen.youell@jpmorgan.com Email: stephen.youell@jpmorgan.com
David Mozes
Email: mosesster@gmail.com
Tal Mizrahi
Huawei Network.IO Innovation Lab
Israel
Email: tal.mizrahi.phd@gmail.com
Alejandro Aguado
Universidad Politecnica de Madrid
Campus Montegancedo, Boadilla del Monte
Madrid 28660
Spain
Phone: +34 910 673 086
Email: a.aguadom@fi.upm.es
Diego R. Lopez
Telefonica I+D
Editor Jose Manuel Lara, 9 (1-B)
Seville 41013
Spain
Phone: +34 913 129 041
Email: diego.r.lopez@telefonica.com
 End of changes. 68 change blocks. 
133 lines changed or deleted 244 lines changed or added

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