 1/draftietfsfcproofoftransit02.txt 20190911 02:13:12.563637189 0700
+++ 2/draftietfsfcproofoftransit03.txt 20190911 02:13:12.615638675 0700
@@ 1,125 +1,117 @@
Network Working Group F. Brockners
InternetDraft S. Bhandari
+Network Working Group F. Brockners, Ed.
+InternetDraft S. Bhandari, Ed.
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
 C. Pignataro
 Cisco
 J. Leddy
 Comcast
S. Youell
JPMC
 D. Mozes

 T. Mizrahi
 Huawei Network.IO Innovation Lab
 A. Aguado
 Universidad Politecnica de Madrid
 D. Lopez
 Telefonica I+D
 March 11, 2019
+ September 11, 2019
Proof of Transit
 draftietfsfcproofoftransit02
+ draftietfsfcproofoftransit03
Abstract
Several technologies such as Traffic Engineering (TE), Service
Function Chaining (SFC), and policy based routing are used to steer
traffic through a specific, userdefined path. This document defines
mechanisms to securely prove that traffic transited said defined
path. These mechanisms allow to securely verify whether, within a
given path, all packets traversed all the nodes that they are
supposed to visit.
Status of This Memo
This InternetDraft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
InternetDrafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as InternetDrafts. The list of current Internet
 Drafts is at http://datatracker.ietf.org/drafts/current/.
+ Drafts is at https://datatracker.ietf.org/drafts/current/.
InternetDrafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use InternetDrafts as reference
material or to cite them other than as "work in progress."
 This InternetDraft will expire on September 12, 2019.
+ This InternetDraft will expire on March 14, 2020.
Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
 (http://trustee.ietf.org/licenseinfo) in effect on the date of
+ (https://trustee.ietf.org/licenseinfo) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Proof of Transit . . . . . . . . . . . . . . . . . . . . . . 5
 3.1. Basic Idea . . . . . . . . . . . . . . . . . . . . . . . 6
 3.2. Solution Approach . . . . . . . . . . . . . . . . . . . . 7
+ 3.1. Basic Idea . . . . . . . . . . . . . . . . . . . . . . . 5
+ 3.2. Solution Approach . . . . . . . . . . . . . . . . . . . . 6
3.2.1. Setup . . . . . . . . . . . . . . . . . . . . . . . . 7
3.2.2. In Transit . . . . . . . . . . . . . . . . . . . . . 7
3.2.3. Verification . . . . . . . . . . . . . . . . . . . . 8
3.3. Illustrative Example . . . . . . . . . . . . . . . . . . 8
3.3.1. Baseline . . . . . . . . . . . . . . . . . . . . . . 8
3.3.1.1. Secret Shares . . . . . . . . . . . . . . . . . . 8
3.3.1.2. Lagrange Polynomials . . . . . . . . . . . . . . 9
3.3.1.3. LPC Computation . . . . . . . . . . . . . . . . . 9
3.3.1.4. Reconstruction . . . . . . . . . . . . . . . . . 9
3.3.1.5. Verification . . . . . . . . . . . . . . . . . . 10
3.3.2. Complete Solution . . . . . . . . . . . . . . . . . . 10
3.3.2.1. Random Polynomial . . . . . . . . . . . . . . . . 10
3.3.2.2. Reconstruction . . . . . . . . . . . . . . . . . 10
3.3.2.3. Verification . . . . . . . . . . . . . . . . . . 11
3.3.3. Solution Deployment Considerations . . . . . . . . . 11
3.4. Operational Aspects . . . . . . . . . . . . . . . . . . . 12
3.5. Ordered POT (OPOT) . . . . . . . . . . . . . . . . . . . 12
4. Sizing the Data for Proof of Transit . . . . . . . . . . . . 13
5. Node Configuration . . . . . . . . . . . . . . . . . . . . . 14
5.1. Procedure . . . . . . . . . . . . . . . . . . . . . . . . 15
 5.2. YANG Model . . . . . . . . . . . . . . . . . . . . . . . 15

 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
 7. Manageability Considerations . . . . . . . . . . . . . . . . 18
 8. Security Considerations . . . . . . . . . . . . . . . . . . . 19
 8.1. Proof of Transit . . . . . . . . . . . . . . . . . . . . 19
 8.2. Cryptanalysis . . . . . . . . . . . . . . . . . . . . . . 20
 8.3. AntiReplay . . . . . . . . . . . . . . . . . . . . . . . 20
 8.4. AntiPreplay . . . . . . . . . . . . . . . . . . . . . . 21
 8.5. Tampering . . . . . . . . . . . . . . . . . . . . . . . . 21
 8.6. Recycling . . . . . . . . . . . . . . . . . . . . . . . . 21
 8.7. Redundant Nodes and Failover . . . . . . . . . . . . . . 22
 8.8. Controller Operation . . . . . . . . . . . . . . . . . . 22
 8.9. Verification Scope . . . . . . . . . . . . . . . . . . . 22
 8.9.1. Node Ordering . . . . . . . . . . . . . . . . . . . . 23
 8.9.2. Stealth Nodes . . . . . . . . . . . . . . . . . . . . 23
 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 23
 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 23
 10.1. Normative References . . . . . . . . . . . . . . . . . . 23
 10.2. Informative References . . . . . . . . . . . . . . . . . 24
 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24
+ 5.2. YANG Model for POT . . . . . . . . . . . . . . . . . . . 15
+ 5.2.1. Main Parameters . . . . . . . . . . . . . . . . . . . 16
+ 5.2.2. Tree Diagram . . . . . . . . . . . . . . . . . . . . 16
+ 5.2.3. YANG Model . . . . . . . . . . . . . . . . . . . . . 17
+ 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
+ 7. Security Considerations . . . . . . . . . . . . . . . . . . . 20
+ 7.1. Proof of Transit . . . . . . . . . . . . . . . . . . . . 21
+ 7.2. Cryptanalysis . . . . . . . . . . . . . . . . . . . . . . 21
+ 7.3. AntiReplay . . . . . . . . . . . . . . . . . . . . . . . 22
+ 7.4. AntiPreplay . . . . . . . . . . . . . . . . . . . . . . 23
+ 7.5. Tampering . . . . . . . . . . . . . . . . . . . . . . . . 23
+ 7.6. Recycling . . . . . . . . . . . . . . . . . . . . . . . . 23
+ 7.7. Redundant Nodes and Failover . . . . . . . . . . . . . . 24
+ 7.8. Controller Operation . . . . . . . . . . . . . . . . . . 24
+ 7.9. Verification Scope . . . . . . . . . . . . . . . . . . . 24
+ 7.9.1. Node Ordering . . . . . . . . . . . . . . . . . . . . 25
+ 7.9.2. Stealth Nodes . . . . . . . . . . . . . . . . . . . . 25
+ 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 25
+ 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 25
+ 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 26
+ 10.1. Normative References . . . . . . . . . . . . . . . . . . 26
+ 10.2. Informative References . . . . . . . . . . . . . . . . . 27
+ Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27
1. Introduction
Several deployments use Traffic Engineering, policy routing, Segment
Routing (SR), and Service Function Chaining (SFC) [RFC7665] to steer
packets through a specific set of nodes. In certain cases,
regulatory obligations or a compliance policy require operators to
prove that all packets that are supposed to follow a specific path
are indeed being forwarded across and exact set of predetermined
nodes.
@@ 183,23 +175,24 @@
LISP: Locator/ID Separation Protocol
LPC: Lagrange Polynomial Constants
MTU: Maximum Transmit Unit
NFV: Network Function Virtualization
NSH: Network Service Header
+
POT: Proof of Transit
 POTprofile: Proof of Transit Profile that has the necessary data
+ POTProfile: Proof of Transit Profile that has the necessary data
for nodes to participate in proof of transit
RND: Random Bits generated per packet. Packet fields that do
not change during the traversal are given as input to
HMAC256 algorithm. A minimum of 32 bits (left most) need
to be used from the output if RND is used to verify the
packet integrity. This is a standard recommendation by
NIST.
SEQ_NO: Sequence number initialized to a predefined constant.
@@ 306,28 +299,29 @@
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
A controller generates a first polynomial (POLY1) of degree k and
k+1 points on the polynomial, corresponding to the k+1 nodes along
the path. The constant coefficient of POLY1 is considered the
SECRET, which is per the definition of the SSSS algorithm [SSS]. The
 nonconstant coefficients are used to generate the Lagrange
 Polynomial Constants (LPC). Each of the k+1 nodes (including
 verifier) are assigned a point on the polynomial i.e., shares of the
 SECRET. The verifier is configured with the SECRET. The Controller
 also generates coefficients (except the constant coefficient, called
 "RND", which is changed on a per packet basis) of a second polynomial
 POLY2 of the same degree. Each node is configured with the LPC of
 POLY2. Note that POLY2 is public.
+ k+1 points are used to derive the Lagrange Basis Polynomials. The
+ Lagrange Polynomial Constants (LPC) are retrieved from the constant
+ coefficients of the Lagrange Basis Polynomials. Each of the k+1
+ nodes (including verifier) are assigned a point on the polynomial
+ i.e., shares of the SECRET. The verifier is configured with the
+ SECRET. The Controller also generates coefficients (except the
+ constant coefficient, called "RND", which is changed on a per packet
+ basis) of a second polynomial POLY2 of the same degree. Each node
+ is configured with the LPC of POLY2. Note that POLY2 is public.
3.2.2. In Transit
For each packet, the ingress node generates a random number (RND).
It is considered as the constant coefficient for POLY2. A
cumulative value (CML) is initialized to 0. Both RND, CML are
carried as within the packet POT data. As the packet visits each
node, the RND is retrieved from the packet and the respective share
of POLY2 is calculated. Each node calculates (Share(POLY1) +
Share(POLY2)) and CML is updated with this sum, specifically each
@@ 381,62 +376,65 @@
considered the shares of the secret. They are assigned by the
Controller to three nodes respectively and are kept secret.
3.3.1.2. Lagrange Polynomials
Lagrange basis polynomials (or Lagrange polynomials) are used for
polynomial interpolation. For a given set of points on the curve
Lagrange polynomials (as defined below) are used to reconstruct the
curve and thus reconstruct the complete secret.
 l0(x) = (((xx1) / (x0x1)) * ((xx2)/x0x2))) mod 53 =
 (((x4) / (24)) * ((x5)/25))) mod 53 =
 (10/3  3x/2 + (1/6)x^2) mod 53
+ l0(x) = (((xx1) / (x0x1)) * ((xx2)/x0x2))) mod 53
+ = (((x4) / (24)) * ((x5)/25))) mod 53
+ = (10/3  3x/2 + (1/6)x^2) mod 53
 l1(x) = (((xx0) / (x1x0)) * ((xx2)/x1x2))) mod 53 =
 (5 + 7x/2  (1/2)x^2) mod 53
+ l1(x) = (((xx0) / (x1x0)) * ((xx2)/x1x2))) mod 53
+ = (5 + 7x/2  (1/2)x^2) mod 53
 l2(x) = (((xx0) / (x2x0)) * ((xx1)/x2x1))) mod 53 =
 (8/3  2 + (1/3)x^2) mod 53
+ l2(x) = (((xx0) / (x2x0)) * ((xx1)/x2x1))) mod 53
+ = (8/3  2 + (1/3)x^2) mod 53
3.3.1.3. LPC Computation
Since x0=2, x1=4, x2=5 are chosen points. Given that computations
are done over a finite arithmetic field ("modulo a prime number"),
the Lagrange basis polynomial constants are computed modulo 53. The
 Lagrange Polynomial Constant (LPC) would be 10/3 , 5 , 8/3.LPC are
 computed by the Controller and communicated to the individual nodes.
+ Lagrange Polynomial Constants (LPC) would be mod(10/3, 53), mod(5,
+ 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(l1) = (5) mod 53 = 48
LPC(l2) = (8/3) mod 53 = 38
For a general way to compute the modular multiplicative inverse, see
e.g., the Euclidean algorithm.
3.3.1.4. Reconstruction
Reconstruction of the polynomial is welldefined as
POLY1(x) = l0(x) * y0 + l1(x) * y1 + l2(x) * y2
Subsequently, the SECRET, which is the constant coefficient of
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 yvalues and the
LPC:
 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
+ SECRET = (y0*LPC(l0) + y1*LPC(l1) + y2*LPC(l2)) mod 53
+ = (28 * 21 + 17 * 48 + 47 * 38) mod 53
+ = 3190 mod 53
+ = 10
One observes that the secret reconstruction can easily be performed
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
at each hop with the node's respective (yi*LPC(i)), where i is their
respective value.
3.3.1.5. Verification
Upon completion of the path, the resulting CML is retrieved by the
@@ 507,51 +505,51 @@
Since VERIFY = CML the packet is proven to have gone through nodes 1,
2, and 3.
3.3.3. Solution Deployment Considerations
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
the POT metadata for bypassing the verification. These threats can
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
To operationalize this scheme, a central controller is used to
generate the necessary polynomials, the secret share per node, the
prime number, etc. and distributing the data to the nodes
participating in proof of transit. The identified node that performs
the verification is provided with the verification key. The
information provided from the Controller to each of the nodes
participating in proof of transit is referred to as a proof of
 transit profile (POTprofile). Also note that the set of nodes for
+ transit profile (POTProfile). Also note that the set of nodes for
which the transit has to be proven are typically associated to a
different trust domain than the verifier. Note that building the
trust relationship between the Controller and the nodes is outside
the scope of this document. Techniques such as those described in
[ID.ietfanimaautonomiccontrolplane] might be applied.
To optimize the overall data amount of exchanged and the processing
at the nodes the following optimizations are performed:
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
match. This lends to the LPC values which are used to calculate
the cumulative value CML to be constant. Note that the LPC are
only depending on the x components. They can be computed at the
controller and communicated to the nodes. Otherwise, one would
need to distributed the x components to all the nodes.
2. A preevaluated portion of the public polynomial for each of the
 nodes is calculated and added to the POTprofile. Without this
+ nodes is calculated and added to the POTProfile. Without this
all the coefficients of the public polynomial had to be added to
the POT profile and each node had to evaluate them. As stated
before, the public portion is only the constant coefficient RND
value, the preevaluated portion for each node should be kept
secret as well.
3. To provide flexibility on the size of the cumulative and random
numbers carried in the POT data a field to indicate this is
shared and interpreted at the nodes.
@@ 652,81 +650,161 @@
(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.
5. Node Configuration
A POT system consists of a number of nodes that participate in POT
and a Controller, which serves as a control and configuration entity.
The Controller is to create the required parameters (polynomials,
prime number, etc.) and communicate the associated values (i.e. prime
number, secretshare, LPC, etc.) to the nodes. The sum of all
 parameters for a specific node is referred to as "POTprofile". For
+ parameters for a specific node is referred to as "POTProfile". For
details see the YANG model in Section 5.2.This document does not
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
 The Controller creates new POTprofiles at a constant rate and
 communicates the POTprofile to the nodes. The controller labels a
 POTprofile "even" or "odd" and the Controller cycles between "even"
+ The Controller creates new POTProfiles at a constant rate and
+ communicates the POTProfile to the nodes. The controller labels a
+ POTProfile "even" or "odd" and the Controller cycles between "even"
and "odd" labeled profiles. This means that the parameters for the
algorithms are continuously refreshed. Please refer to Section 4 for
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 POTprofile is "used up".
 Once the POTprofile has been successfully communicated to all nodes
+ Profiles are communicated to the nodes is configurable and MUST be
+ more frequent than the speed at which a POTProfile is "used up".
+ Once the POTProfile has been successfully communicated to all nodes
(e.g., all NETCONF transactions completed, in case NETCONF is used as
 a protocol), the controller sends an "enable POTprofile" request to
+ a protocol), the controller sends an "enable POTProfile" request to
the ingress node.
 All nodes maintain two POTprofiles (an even and an odd POTprofile):
 One POTprofile is currently active and in use; one profile is
+ All nodes maintain two POTProfiles (an even and an odd POTProfile):
+ One POTProfile is currently active and in use; one profile is
standby and about to get used. A flag in the packet is indicating
 whether the odd or even POTprofile is to be used by a node. This is
+ whether the odd or even POTProfile is to be used by a node. This is
to ensure that during profile change the service is not disrupted.
If the "odd" profile is active, the Controller can communicate the
"even" profile to all nodes. Only if all the nodes have received the
 POTprofile, the Controller will tell the ingress node to switch to
+ POTProfile, the Controller will tell the ingress node to switch to
the "even" profile. Given that the indicator travels within the
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
"odd" profile.
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
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
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
 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 potprofileindex: Section 5.1 details that two POTProfiles are
+ used. Only one of the POTProfiles is active at a given point in
+ time, allowing the Controller to refresh the nonactive one for
+ future use. potprofileindex defines which of the POTProfiles
+ (the "even" or "odd" POTProfile) is currently active. pot
+ profileindex will be set in the first hop of the path or chain.
+ Other nodes will not use this field.
+
+ o primenumber: Prime number used for module math computation.
+
+ o secretshare: Share of the secret of polynomial1 used in
+ computation for the node. If POLY1 is defined by points (x1_i,
+ y1_i) with i=0,..k, then for node i, the secretshare will be
+ y1_i.
+
+ o publicpolynomial: Public polynomial value for the node.. If
+ POLY2 is defined by points (x2_i, y2_i) with i=0,..k, then for
+ node i, the secretshare 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 ith Lagrange Basis
+ Polynomial.
+
+ o validator?: True if the node is a verifier node.
+
+ o validatorkey?: The validatorkey represents the SECRET as
+ described in the sections above. The SECRET is the constant
+ coefficient of POLY1(z). If POLY1(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. 32bits 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
+ (readwrite), and "ro" means state data (readonly).
+
+ o Symbols after data node names: "?" means an optional node, "!"
+ means a presence container, and "*" denotes a list and leaflist.
+
+ 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.
+
+
+ module: ietfpotprofile
+ +rw potprofiles
+ +rw potprofileset* [potprofilename]
+ +rw potprofilename string
+ +rw activeprofileindex? profileindexrange
+ +rw potprofilelist* [potprofileindex]
+ +rw potprofileindex profileindexrange
+ +rw primenumber uint64
+ +rw secretshare uint64
+ +rw publicpolynomial uint64
+ +rw lpc uint64
+ +rw validator? boolean
+ +rw validatorkey? uint64
+ +rw bitmask? uint64
+
+
+5.2.3. YANG Model
file "ietfpotprofile@20160615.yang"
module ietfpotprofile {
yangversion 1;
+
namespace "urn:ietf:params:xml:ns:yang:ietfpotprofile";
prefix ietfpotprofile;
 organization "IETF xxx Working Group";
+ organization "IETF SFC Working Group";
 contact "";
+ contact "WG Web:
+ WG List: ";
description "This module contains a collection of YANG
definitions for proof of transit configuration
parameters. The model is meant for proof of
transit and is targeted for communicating the
 POTprofile between a controller and nodes
+ POTProfile between a controller and nodes
participating in proof of transit.";
revision 20160615 {
description
"Initial revision.";
reference
"";
}
typedef profileindexrange {
@@ 756,59 +834,73 @@
type uint64;
mandatory true;
description
"Prime number used for module math computation";
}
leaf secretshare {
type uint64;
mandatory true;
description
 "Share of the secret of polynomial 1 used in computation";
+ "Share of the secret of polynomial1 used
+ in computation for the node. If POLY1
+ is defined by points (x1_i, y1_i) with
+ i=0,..k, then for node i, the secretshare
+ will be y1_i.";
}
leaf publicpolynomial {
type uint64;
mandatory true;
description
 "Pre evaluated Public polynomial";
+ "Public polynomial value for the node.
+ If POLY2 is defined by points (x2_i, y2_i)
+ with i=0,..k, then for node i,
+ the secretshare will be y2_i.";
}
leaf lpc {
type uint64;
mandatory true;
description
"Lagrange Polynomial Coefficient";
}
leaf validator {
type boolean;
default "false";
description
"True if the node is a verifier node";
}
leaf validatorkey {
type uint64;
description
 "Secret key for validating the path, constant of poly 1";
+ "The validatorkey represents the secret.
+ The secret is the constant coefficient of
+ POLY1(z). If POLY1(z) =
+ a_0 + a_1*z + a_2*z^2+..+a_k*z^k,
+ then the SECRET would be a_0.";
}
leaf bitmask {
type uint64;
default 4294967295;
description
 "Number of bits as mask used in controlling the size of the
 random value generation. 32bits of mask is default.";
+ "Number of bits as mask used in controlling
+ the size of the random value generation.
+ 32bits of mask is default.";
}
}
+
}
+
container potprofiles {
description "A group of proof of transit profiles.";
list potprofileset {
key "potprofilename";
orderedby user;
description
"Set of proof of transit profiles that group parameters
required to classify and compute proof of transit
metadata at a node";
@@ 816,58 +908,52 @@
leaf potprofilename {
type string;
mandatory true;
description
"Unique identifier for each proof of transit profile";
}
leaf activeprofileindex {
type profileindexrange;
description
 "Proof of transit profile index that is currently active.
+ "POTProfile index that is currently active.
Will be set in the first hop of the path or chain.
Other nodes will not use this field.";
}
uses potprofile;
}
/*** Container: end ***/
}
/*** module: end ***/
}
6. IANA Considerations
 IANA considerations will be added in a future version of this
 document.

7. Manageability Considerations

 Manageability considerations will be addressed in a later version of
 this document.
+ This document does not require any actions from IANA.
8. Security Considerations
+7. Security Considerations
POT is a mechanism that is used for verifying the path through which
a packet was forwarded. The security considerations of IOAM in
general are discussed in [ID.ietfippmioamdata]. 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
+7.1. Proof of Transit
Proof of correctness and security of the solution approach is per
Shamir's Secret Sharing Scheme [SSS]. Cryptographically speaking it
achieves informationtheoretic security i.e., it cannot be broken by
an attacker even with unlimited computing power. As long as the
below conditions are met it is impossible for an attacker to bypass
one or multiple nodes without getting caught.
o If there are k+1 nodes in the path, the polynomials (POLY1, POLY
2) should be of degree k. Also k+1 points of POLY1 are chosen
@@ 888,21 +974,21 @@
used as POLY1 across different paths, traffic profiles or service
chains.
If symmetric masking is used to assure OPOT (Section 3.5), the nodes
need to keep two additional secrets: the downstream and upstream
masks, that have to be managed under the same conditions as the
secrets mentioned above. And it is equally recommended to employ a
different set of mask pairs across different paths, traffic profiles
or service chains.
8.2. Cryptanalysis
+7.2. Cryptanalysis
A passive attacker could try to harvest the POT data (i.e., CML, RND
values) in order to determine the configured secrets. Subsequently
two types of differential analysis for guessing the secrets could be
done.
o InterNode: A passive attacker observing CML values across nodes
(i.e., as the packets entering and leaving), cannot perform
differential analysis to construct the points on POLY1. This is
because at each point there are four unknowns (i.e. Share(POLY
@@ 913,21 +999,21 @@
o InterPackets: A passive attacker could observe CML values across
packets (i.e., values of PKT1 and subsequent PKT2), in order to
predict the secrets. Differential analysis across packets could
be mitigated using a good PRNG for generating RND. Note that if
constant coefficient is a sequence number than CML values become
quite predictable and the scheme would be broken. If symmetric
masking is used for OPOT, interpacket analysis could be applied
to guess mask values, which requires a proper refresh rate for
masks, at least as high as the one used for LPCs.
8.3. AntiReplay
+7.3. AntiReplay
A passive attacker could reuse a set of older RND and the
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 POLY2 as a
(SEQ_NO + RND). For example, if 64 bits are being used for POLY2
then first 16 bits could be a sequence number SEQ_NO and next 48 bits
could be a random number.
@@ 939,21 +1025,21 @@
flagged legitimate. Packets arriving with a lower SEQ_NO than
current buffer could be flagged as suspicious.
For all practical purposes in the rest of the document RND means
SEQ_NO + RND to keep it simple.
The solution discussed in this memo does not currently mitigate
replay attacks. An antireplay mechanism may be included in future
versions of the solution.
8.4. AntiPreplay
+7.4. AntiPreplay
An active attacker could try to perform a maninthemiddle (MITM)
attack by extracting the POT of PKT1 and using it in PKT2.
Subsequently attacker drops the PKT1 in order to avoid duplicate POT
values reaching the verifier. If the PKT1 reaches the verifier,
then this attack is same as Replay attacks discussed before.
Preplay attacks are possible since the POT metadata is not dependent
on the packet fields. Below steps are recommended for remediation:
@@ 970,206 +1056,205 @@
compares with RND. To ensure the POT data is in fact that of the
packet.
If an HMAC is used, an active attacker lacks the knowledge of the
preshared key, and thus cannot launch preplay attacks.
The solution discussed in this memo does not currently mitigate
preplay attacks. A mitigation mechanism may be included in future
versions of the solution.
8.5. Tampering
+7.5. Tampering
An active attacker could not insert any arbitrary value for CML.
This would subsequently fail the reconstruction of the POLY3. Also
an attacker could not update the CML with a previously observed
value. This could subsequently be detected by using timestamps
within the RND value as discussed above.
8.6. Recycling
+7.6. Recycling
The solution approach is flexible for recycling long term secrets
like POLY1. All the nodes could be periodically updated with shares
of new SECRET as best practice. The table above could be consulted
for refresh cycles (see Section 4).
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
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
multiple physical entities. In case of multiple physical entities
(e.g., for loadbalancing, or business continuity situations 
consider for example a set of firewalls), all physical entities which
are implementing the same POT node are given that same share of the
secret. This makes multiple physical entities represent the same POT
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 secrets, as need to be the nodes. The communication between
Controller and the nodes also needs to be secured. As secure
communication protocol such as for example NETCONF over SSH should be
chosen for Controller to node communication.
The Controller only interacts with the nodes during the initial
configuration and thereafter at regular intervals at which the
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
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)
 see Section 4 above, thus even a "headless" operation without a
Controller can be considered feasible. In such a case, the
Controller would only be used for the initial configuration of the
 POTprofiles.
+ POTProfiles.
If OPOT (Section 3.5) is applied using symmetric masking, 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
required level of assurance through the Controller management
interface.
8.9. Verification Scope
+7.9. Verification Scope
The POT solution defined in this document verifies that a datapacket
traversed or transited a specific set of nodes. From an algorithm
perspective, a "node" is an abstract entity. It could be represented
by one or multiple physical or virtual network devices, or is could
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
be securely verified.
8.9.1. Node Ordering
+7.9.1. Node Ordering
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
visited by a data packet. It does not verify the order in which the
data packet visited the nodes.
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
to OPOT (Section 3.5) have to be considered. Since these schemes
introduce at least additional control requirements, the selection of
order verification SHOULD be configurable the Controller management
interface.
8.9.2. Stealth Nodes
+7.9.2. Stealth Nodes
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
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
"stealth" nodes which do not participate in proofoftransit have
been inserted into a path.
9. Acknowledgements
+8. Acknowledgements
The authors would like to thank Eric Vyncke, Nalini Elkins, Srihari
Raghavan, Ranganathan T S, Karthik Babu Harichandra Babu, Akshaya
Nadahalli, Erik Nordmark, and Andrew Yourtchenko for the comments and
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.
+ 720011 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 (1B)
+ Seville 41013
+ Spain
+ Phone: +34 913 129 041
+ Email: diego.r.lopez@telefonica.com
+
10. References
10.1. Normative References
[ID.ietfippmioamdata]
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 Insitu OAM", draftietfippmioam
 data04 (work in progress), October 2018.
+ data06 (work in progress), July 2019.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
 DOI 10.17487/RFC2119, March 1997, .
+ DOI 10.17487/RFC2119, March 1997,
+ .
[RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function
Chaining (SFC) Architecture", RFC 7665,
 DOI 10.17487/RFC7665, October 2015, .
+ DOI 10.17487/RFC7665, October 2015,
+ .
 [SSS] "Shamir's Secret Sharing", .
+ [SSS] "Shamir's Secret Sharing",
+ .
10.2. Informative References
[ID.ietfanimaautonomiccontrolplane]
Eckert, T., Behringer, M., and S. Bjarnason, "An Autonomic
Control Plane (ACP)", draftietfanimaautonomiccontrol
plane18 (work in progress), August 2018.
Authors' Addresses
 Frank Brockners
+ Frank Brockners (editor)
Cisco Systems, Inc.
Hansaallee 249, 3rd Floor
DUESSELDORF, NORDRHEINWESTFALEN 40549
Germany
Email: fbrockne@cisco.com
 Shwetha Bhandari
+ Shwetha Bhandari (editor)
Cisco Systems, Inc.
Cessna Business Park, Sarjapura Marathalli Outer Ring Road
Bangalore, KARNATAKA 560 087
India
Email: shwethab@cisco.com
+ Tal Mizrahi (editor)
+ Huawei Network.IO Innovation Lab
+ Israel
+
+ Email: tal.mizrahi.phd@gmail.com
+
Sashank Dara
Seconize
BANGALORE, Bangalore, KARNATAKA
INDIA
Email: sashank@seconize.co
 Carlos Pignataro
 Cisco Systems, Inc.
 720011 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
JP Morgan Chase
25 Bank Street
London E14 5JP
United Kingdom
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 (1B)
 Seville 41013
 Spain

 Phone: +34 913 129 041
 Email: diego.r.lopez@telefonica.com