draft-ietf-sfc-proof-of-transit-06.txt   draft-ietf-sfc-proof-of-transit-07.txt 
Network Working Group F. Brockners, Ed. Network Working Group F. Brockners, Ed.
Internet-Draft S. Bhandari, Ed. Internet-Draft Cisco
Intended status: Experimental Cisco Intended status: Experimental S. Bhandari, Ed.
Expires: December 18, 2020 T. Mizrahi, Ed. Expires: April 28, 2021 Thoughtspot
T. Mizrahi, Ed.
Huawei Network.IO Innovation Lab Huawei Network.IO Innovation Lab
S. Dara S. Dara
Seconize Seconize
S. Youell S. Youell
JPMC JPMC
June 16, 2020 October 25, 2020
Proof of Transit Proof of Transit
draft-ietf-sfc-proof-of-transit-06 draft-ietf-sfc-proof-of-transit-07
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 a defined path. mechanisms to securely prove that traffic transited a defined path.
These mechanisms allow to securely verify whether, within a given These mechanisms allow to securely verify whether, within a given
path, all packets traversed all the nodes that they are supposed to path, all packets traversed all the nodes that they are supposed to
visit. visit. The document defines the data model through Unified Modeling
Language (UML) class diagrams and formally specifies it using an
NDMA- compliant YANG model to enable these mechanisms.
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 https://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 December 18, 2020. This Internet-Draft will expire on April 28, 2021.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2020 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
(https://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. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Proof of Transit . . . . . . . . . . . . . . . . . . . . . . 5 3. Proof of Transit . . . . . . . . . . . . . . . . . . . . . . 5
3.1. Basic Idea . . . . . . . . . . . . . . . . . . . . . . . 5 3.1. Basic Idea . . . . . . . . . . . . . . . . . . . . . . . 6
3.2. Solution Approach . . . . . . . . . . . . . . . . . . . . 6 3.2. Solution Approach . . . . . . . . . . . . . . . . . . . . 7
3.2.1. Setup . . . . . . . . . . . . . . . . . . . . . . . . 7 3.2.1. Setup . . . . . . . . . . . . . . . . . . . . . . . . 7
3.2.2. In Transit . . . . . . . . . . . . . . . . . . . . . 7 3.2.2. In Transit . . . . . . . . . . . . . . . . . . . . . 8
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 . . . . . . . . . . . . . . . . . . 9
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 . . . . . . . . . . . . . . . . . 10
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 . . . . . . . . . . . . . . . . 11
3.3.2.2. Reconstruction . . . . . . . . . . . . . . . . . 10 3.3.2.2. Reconstruction . . . . . . . . . . . . . . . . . 11
3.3.2.3. Verification . . . . . . . . . . . . . . . . . . 11 3.3.2.3. Verification . . . . . . . . . . . . . . . . . . 12
3.3.3. Solution Deployment Considerations . . . . . . . . . 11 3.3.3. Solution Deployment Considerations . . . . . . . . . 12
3.4. Operational Aspects . . . . . . . . . . . . . . . . . . . 12 3.4. Operational Aspects . . . . . . . . . . . . . . . . . . . 12
3.5. Ordered POT (OPOT) . . . . . . . . . . . . . . . . . . . 12 3.5. Ordered POT (OPOT) . . . . . . . . . . . . . . . . . . . 13
4. Sizing the Data for Proof of Transit . . . . . . . . . . . . 13 4. Sizing the Data for Proof of Transit . . . . . . . . . . . . 14
5. Node Configuration . . . . . . . . . . . . . . . . . . . . . 14 5. Node Configuration . . . . . . . . . . . . . . . . . . . . . 15
5.1. Procedure . . . . . . . . . . . . . . . . . . . . . . . . 15 5.1. Procedure . . . . . . . . . . . . . . . . . . . . . . . . 15
5.2. YANG Model for POT . . . . . . . . . . . . . . . . . . . 15 5.2. YANG Model for POT . . . . . . . . . . . . . . . . . . . 16
5.2.1. Main Parameters . . . . . . . . . . . . . . . . . . . 16 5.2.1. Main Parameters . . . . . . . . . . . . . . . . . . . 16
5.2.2. Tree Diagram . . . . . . . . . . . . . . . . . . . . 16 5.2.2. Tree Diagram . . . . . . . . . . . . . . . . . . . . 17
5.2.3. YANG Model . . . . . . . . . . . . . . . . . . . . . 17 5.2.3. YANG Model . . . . . . . . . . . . . . . . . . . . . 18
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22
7. Security Considerations . . . . . . . . . . . . . . . . . . . 22 7. Security Considerations . . . . . . . . . . . . . . . . . . . 23
7.1. Proof of Transit . . . . . . . . . . . . . . . . . . . . 22 7.1. Proof of Transit . . . . . . . . . . . . . . . . . . . . 23
7.2. Cryptanalysis . . . . . . . . . . . . . . . . . . . . . . 23 7.2. Cryptanalysis . . . . . . . . . . . . . . . . . . . . . . 24
7.3. Anti-Replay . . . . . . . . . . . . . . . . . . . . . . . 23 7.3. Anti-Replay . . . . . . . . . . . . . . . . . . . . . . . 24
7.4. Anti-Preplay . . . . . . . . . . . . . . . . . . . . . . 24 7.4. Anti-Preplay . . . . . . . . . . . . . . . . . . . . . . 25
7.5. Tampering . . . . . . . . . . . . . . . . . . . . . . . . 24 7.5. Tampering . . . . . . . . . . . . . . . . . . . . . . . . 26
7.6. Recycling . . . . . . . . . . . . . . . . . . . . . . . . 25 7.6. Recycling . . . . . . . . . . . . . . . . . . . . . . . . 26
7.7. Redundant Nodes and Failover . . . . . . . . . . . . . . 25 7.7. Redundant Nodes and Failover . . . . . . . . . . . . . . 26
7.8. Controller Operation . . . . . . . . . . . . . . . . . . 25 7.8. Controller Operation . . . . . . . . . . . . . . . . . . 26
7.9. Verification Scope . . . . . . . . . . . . . . . . . . . 26 7.9. Verification Scope . . . . . . . . . . . . . . . . . . . 27
7.9.1. Node Ordering . . . . . . . . . . . . . . . . . . . . 26 7.9.1. Node Ordering . . . . . . . . . . . . . . . . . . . . 27
7.9.2. Stealth Nodes . . . . . . . . . . . . . . . . . . . . 26 7.9.2. Stealth Nodes . . . . . . . . . . . . . . . . . . . . 27
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 26 7.10. POT Yang module . . . . . . . . . . . . . . . . . . . . . 27
9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 26 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 28
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 27 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 28
10.1. Normative References . . . . . . . . . . . . . . . . . . 27 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 29
10.2. Informative References . . . . . . . . . . . . . . . . . 28 10.1. Normative References . . . . . . . . . . . . . . . . . . 29
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28 10.2. Informative References . . . . . . . . . . . . . . . . . 30
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 30
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 compliance policies require operators to prove that all packets that
prove that all packets that are supposed to follow a specific path are supposed to follow a specific path are indeed being forwarded
are indeed being forwarded across and exact set of pre-determined across an exact set of pre-determined nodes.
nodes.
If a packet flow is supposed to go through a series of service If a packet flow is supposed to go through a series of service
functions or network nodes, it has to be proven that indeed all functions or network nodes, it has to be proven that indeed all
packets of the flow followed the path or service chain or collection packets of the flow followed the path or service chain or collection
of nodes specified by the policy. In case some packets of a flow of nodes specified by the policy. In case some packets of a flow
weren't appropriately processed, a verification device should weren't appropriately processed, a verification device should
determine the policy violation and take corresponding actions determine the policy violation and take corresponding actions
corresponding to the policy (e.g., drop or redirect the packet, send corresponding to the policy (e.g., drop or redirect the packet, send
an alert etc.) In today's deployments, the proof that a packet an alert etc.) In today's deployments, the proof that a packet
traversed a particular path or service chain is typically delivered traversed a particular path or service chain is typically delivered
skipping to change at page 4, line 21 skipping to change at page 4, line 26
to verify whether a packet traversed all required nodes. A to verify whether a packet traversed all required nodes. A
particular set of nodes "to be verified" is either described by a set particular set of nodes "to be verified" is either described by a set
of shares of a single secret. Nodes on the path retrieve their of shares of a single secret. Nodes on the path retrieve their
individual shares of the secret using Shamir's Secret Sharing scheme individual shares of the secret using Shamir's Secret Sharing scheme
from a central controller. The complete secret set is only known to from a central controller. The complete secret set is only known to
the controller and a verifier node, which is typically the ultimate the controller and a verifier node, which is typically the ultimate
node on a path that performs verification. Each node in the path node on a path that performs verification. Each node in the path
uses its share of the secret to update the POT data of the packets as uses its share of the secret to update the POT data of the packets as
the packets pass through the node. When the verifier receives a the packets pass through the node. When the verifier receives a
packet, it uses its key along with data found in the packet to packet, it uses its key along with data found in the packet to
validate whether the packet traversed the path correctly. validate whether the packet traversed the path correctly. This
document defines a data model and specifies it formally using the
YANG 1.1 [RFC7950] data modeling language to support enabling the POT
solution.
2. Conventions Note to RFC Editor: Please replace the date 2020-09-09 in Section 5.2
of the draft with the date of publication of this draft as a RFC.
Also, replace reference to RFC XXXX, and draft-ietf-sfc-proof-of-
transit with the RFC numbers assigned to the drafts.
2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
document are to be interpreted as described in [RFC2119]. "OPTIONAL" in this document are to be interpreted as described in
BCP[RFC2119] [RFC8174]
Abbreviations used in this document: Abbreviations used in this document:
HMAC: Hash based Message Authentication Code. For example, HMAC: Hashed Message Authentication Code. For example, HMAC-
HMAC-SHA256 generates 256 bits of MAC SHA256 generates 256 bits of MAC
IOAM: In-situ Operations, Administration, and Maintenance IOAM: In-situ Operations, Administration, and Maintenance
LISP: Locator/ID Separation Protocol LISP: Locator/ID Separation Protocol
LPC: Lagrange Polynomial Constants LPC: Lagrange Polynomial Constants
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
skipping to change at page 6, line 9 skipping to change at page 6, line 21
3.1. Basic Idea 3.1. Basic Idea
The method relies on adding POT data to all packets that traverse a The method relies on adding POT data to all packets that traverse a
path. The added POT data allows a verifying node (egress node) to path. The added POT data allows a verifying node (egress node) to
check whether a packet traversed the identified set of nodes on a check whether a packet traversed the identified set of nodes on a
path correctly or not. Security mechanisms are natively built into path correctly or not. Security mechanisms are natively built into
the generation of the POT data to protect against misuse (e.g., the generation of the POT data to protect against misuse (e.g.,
configuration mistakes). The mechanism for POT leverages "Shamir's configuration mistakes). The mechanism for POT leverages "Shamir's
Secret Sharing" scheme [SSS]. Secret Sharing" scheme [SSS].
Shamir's secret sharing base idea: A polynomial (represented by its Shamir's Secret Sharing base idea: A polynomial (represented by its
coefficients) of degree k is chosen as a secret by the controller. A coefficients) of degree k is chosen as a secret by the controller. A
polynomial represents a curve. A set of k+1 points on the curve polynomial represents a curve. A set of k+1 points on the curve
define the polynomial and are thus needed to (re-)construct the define the polynomial and are thus needed to (re-)construct the
polynomial. Each of these k+1 points of the polynomial is called a polynomial. Each of these k+1 points of the polynomial is called a
"share" of the secret. A single secret is associated with a "share" of the secret. A single secret is associated with a
particular set of k+1 nodes, which typically represent the path to be particular set of k+1 nodes, which typically represent the path to be
verified. k+1 shares of the single secret (i.e., k+1 points on the verified. k+1 shares of the single secret (i.e., k+1 points on the
curve) are securely distributed from a Controller to the network curve) are securely distributed from a Controller to the network
nodes. Nodes use their respective share to update a cumulative value nodes. Nodes use their respective share to update a cumulative value
in the POT data of each packet. Only a verifying node has access to in the POT data of each packet. Only a verifying node has access to
skipping to change at page 7, line 28 skipping to change at page 7, line 41
deployment of the algorithms will always need to define appropriate deployment of the algorithms will always need to define appropriate
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 Shamir's Secret Sharing
k+1 points are used to derive the Lagrange Basis Polynomials. The algorithm [SSS]. The k+1 points are used to derive the Lagrange
Lagrange Polynomial Constants (LPC) are retrieved from the constant Basis Polynomials. The Lagrange Polynomial Constants (LPC) are
coefficients of the Lagrange Basis Polynomials. Each of the k+1 retrieved from the constant coefficients of the Lagrange Basis
nodes (including verifier) are assigned a point on the polynomial Polynomials. Each of the k+1 nodes (including verifier) are assigned
i.e., shares of the SECRET. The verifier is configured with the a point on the polynomial i.e., shares of the SECRET. The verifier
SECRET. The Controller also generates coefficients (except the is configured with the SECRET. The Controller also generates
constant coefficient, called "RND", which is changed on a per packet coefficients (except the constant coefficient, called "RND", which is
basis) of a second polynomial POLY-2 of the same degree. Each node changed on a per packet basis) of a second polynomial POLY-2 of the
is configured with the LPC of POLY-2. Note that POLY-2 is public. 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 15, line 5 skipping to change at page 15, line 39
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 defines the
define a specific protocol to be used between Controller and nodes. 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
skipping to change at page 16, line 33 skipping to change at page 17, line 13
y1_i. y1_i.
o public-polynomial: Public polynomial value for the node.. If 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 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. node i, the secret-share will be y2_i.
o lpc: Lagrange Polynomial Coefficient for the node, i.e. for node 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 i, this would be LPC(l_i), with l_i being the i-th Lagrange Basis
Polynomial. Polynomial.
o validator?: True if the node is a verifier node. o validator: True if the node is a verifier node.
o validator-key?: The validator-key represents the SECRET as o validator-key: The validator-key represents the SECRET as
described in the sections above. The SECRET is the constant described in the sections above. The SECRET is the constant
coefficient of POLY-1(z). If POLY-1(z) = a_0 + a_1*z + 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. 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 o bitmask: Number of bits as mask used in controlling the size of
the random value generation. 32-bits of mask is default. See the random value generation. 32-bits of mask is default. See
Section 4 for details. Section 4 for details.
5.2.2. Tree Diagram 5.2.2. Tree Diagram
This section shows a simplified graphical representation of the YANG This section shows a simplified graphical representation of the YANG
data model for POT. The meaning of the symbols in these diagrams is data model for POT. The meaning of the symbols in YANG tree diagrams
as follows: is defined in [RFC8340].
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 module: ietf-pot-profile
+--rw pot-profiles +--rw pot-profiles
+--rw pot-profile-set* [pot-profile-name] +--rw pot-profile-set* [pot-profile-name]
+--rw pot-profile-name string +--rw pot-profile-name string
+--rw active-profile-index? profile-index-range
+--rw pot-profile-list* [pot-profile-index] +--rw pot-profile-list* [pot-profile-index]
+--rw pot-profile-index profile-index-range +--rw pot-profile-index profile-index-range
+--rw status? boolean
+--rw prime-number uint64 +--rw prime-number uint64
+--rw secret-share uint64 +--rw secret-share uint64
+--rw public-polynomial uint64 +--rw public-polynomial uint64
+--rw lpc uint64 +--rw lpc uint64
+--rw validator? boolean +--rw validator? boolean
+--rw validator-key? uint64 +--rw validator-key? uint64
+--rw bitmask? uint64 +--rw bitmask? uint64
+--rw opot-masks +--rw opot-masks
+--rw downstream-mask* uint64 +--rw downstream-mask* uint64
+--rw upstream-mask* uint64 +--rw upstream-mask* uint64
<CODE ENDS>
5.2.3. YANG Model 5.2.3. YANG Model
<CODE BEGINS> file "ietf-pot-profile@2016-06-15.yang" <CODE BEGINS> file "ietf-pot-profile@2020-09-08.yang"
module ietf-pot-profile { module ietf-pot-profile {
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 "pot";
import ietf-netconf-acm {
prefix nacm;
}
organization "IETF SFC Working Group"; organization "IETF SFC Working Group";
contact "WG Web: <https://tools.ietf.org/wg/sfc/> contact "WG Web: <https://tools.ietf.org/wg/sfc/>
WG List: <mailto:sfc@ietf.org>"; WG List: <mailto:sfc@ietf.org>
Author : Frank Brockners <fbrockne@cisco.com>
Author : Shwetha Bhandari <shwethab@cisco.com>
Author : Tal Mizrahi <tal.mizrahi.phd@gmail.com>";
description description
"This module contains a collection of YANG "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.
Copyright (c) 2018 IETF Trust and the persons identified as Copyright (c) 2020 IETF Trust and the persons identified
authors of the code. All rights reserved. as authors of the code. All rights reserved.
Redistribution and use in source and binary forms, with
or without modification, is permitted pursuant to, and
subject to the license terms contained in, the Simplified
BSD License set forth in Section 4.c of the IETF Trust's
Legal Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info).
Redistribution and use in source and binary forms, with or Redistribution and use in source and binary forms, with or
without modification, is permitted pursuant to, and subject without modification, is permitted pursuant to, and subject to
to the license terms contained in, the Simplified BSD License the license terms contained in, the Simplified BSD License set
set forth in Section 4.c of the IETF Trust's Legal Provisions forth in Section 4.c of the IETF Trust's Legal Provisions
Relating to IETF Documents Relating to IETF Documents
(http://trustee.ietf.org/license-info). (https://trustee.ietf.org/license-info).
This version of this YANG module is part of RFC XXXX
This version of this YANG module is part of RFC XXXX; see (https://www.rfc-editor.org/info/rfcXXXX); see the RFC
the RFC itself for full legal notices. itself for full legal notices.
Copyright (c) 2018 IETF Trust and the persons identified as The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL',
authors of the code. All rights reserved. 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED',
'NOT RECOMMENDED', 'MAY', and 'OPTIONAL' in this document
are to be interpreted as described in BCP 14 (RFC 2119)
(RFC 8174) when, and only when, they appear in all
capitals, as shown here.";
The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL revision "2020-09-08" {
NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT RECOMMENDED', description
'MAY', and 'OPTIONAL' in this document are to be interpreted as "Addressing WGLC comments";
described in BCP 14 (RFC 2119) (RFC 8174) when, and only when, reference
they appear in all capitals, as shown here."; "draft-ietf-sfc-proof-of-transit";
}
revision 2016-06-15 { revision 2016-06-15 {
description description
"Initial revision."; "Initial revision.";
reference reference
""; "draft-ietf-sfc-proof-of-transit";
} }
typedef profile-index-range { typedef profile-index-range {
type int32 { type int32 {
range "0 .. 1"; range "0 .. 1";
} }
description description
"Range used for the profile index. Currently restricted to "Range used for the profile index. Currently restricted to
0 or 1 to identify the odd or even profiles."; 0 or 1 to identify the odd or even profiles.";
} }
skipping to change at page 19, line 16 skipping to change at page 19, line 49
ordered-by user; ordered-by user;
description "A set of pot profiles."; description "A set of pot profiles.";
leaf pot-profile-index { leaf pot-profile-index {
type profile-index-range; type profile-index-range;
mandatory true; mandatory true;
description description
"Proof of transit profile index."; "Proof of transit profile index.";
} }
leaf status {
type boolean;
default "false";
description
"True if this profile is currently active.
Will be used by the first hop of the path or chain.
Other nodes will not use this field.";
}
leaf prime-number { leaf prime-number {
type uint64; type uint64;
nacm:default-deny-all;
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;
nacm:default-deny-all;
mandatory true; mandatory true;
description description
"Share of the secret of polynomial-1 used "Share of the secret of polynomial-1 used
in computation for the node. If POLY-1 in computation for the node. If POLY-1
is defined by points (x1_i, y1_i) with is defined by points (x1_i, y1_i) with
i=0,..k, then for node i, the secret-share i=0,..k, then for node i, the secret-share
will be y1_i."; will be y1_i.";
} }
leaf public-polynomial { leaf public-polynomial {
skipping to change at page 20, line 8 skipping to change at page 21, line 4
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;
nacm:default-deny-all;
description description
"The validator-key represents the secret. "The validator-key represents the secret.
The secret is the constant coefficient of The secret is the constant coefficient of
POLY-1(z). If POLY-1(z) = POLY-1(z). If POLY-1(z) =
a_0 + a_1*z + a_2*z^2+..+a_k*z^k, a_0 + a_1*z + a_2*z^2+..+a_k*z^k,
then the SECRET would be a_0."; then the SECRET would be a_0.";
} }
leaf bitmask { leaf bitmask {
type uint64; type uint64;
skipping to change at page 21, line 32 skipping to change at page 22, line 30
required to classify and compute proof of transit required to classify and compute proof of transit
metadata at a node"; metadata at a node";
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 {
type profile-index-range;
description
"POT-Profile 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 pot-profile; uses pot-profile;
} }
/*** Container: end ***/ /*** Container: end ***/
} }
/*** module: end ***/ /*** module: end ***/
} }
<CODE ENDS> <CODE ENDS>
6. IANA Considerations 6. IANA Considerations
This document does not require any actions from IANA. This document registers a URI in the IETF XML registry [RFC3688].
Following the format in IETF XML Registry [RFC3688], the following
registration is requested to be made.
URI: urn:ietf:params:xml:ns:yang:ietf-pot-profile
Registrant Contact: The IESG.
XML: N/A, the requested URI is an XML namespace.
IANA is requested to register the following YANG module in the "YANG
Module Names" subregistry [RFC7950] within the "YANG Parameters"
registry.
Name: ietf-pot-profile
Maintained by IANA: N
Namespace: urn:ietf:params:xml:ns:yang:ietf-pot-profile
Prefix: pot
Reference: RFC XXXX
7. 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
skipping to change at page 26, line 17 skipping to change at page 27, line 23
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.
7.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.
7.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.
7.10. POT Yang module
The YANG module specified in Section 5.2 of this document defines a
schema for data that is designed to be accessed via network
management protocols such as NETCONF [RFC6241] or RESTCONF [RFC8040].
The lowest NETCONF [RFC6241] layer is the secure transport layer, and
the mandatory-to-implement secure transport is Secure Shell (SSH)
[RFC6242]. The lowest RESTCONF layer is HTTPS, and the mandatory-to-
implement secure transport is TLS [RFC5246].
The NETCONF Access Control Module (NACM) [RFC8341] provides the means
to restrict access for particular NETCONF or RESTCONF users to a
preconfigured subset of all available NETCONF or RESTCONF protocol
operations and content. There are a number of nodes defined in this
YANG module which are read/writeable. These data nodes may be
considered sensitive and vulnerable to attacks in some network
environments. Ability to read from or write into these nodes without
proper protection can have a negative effect on the devices that
support this feature.
8. 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, Andrew Yourtchenko, Tom Petch, Mohamed
advice. Boucadair and Dhruv Dhody for the comments and advice.
9. Contributors 9. Contributors
In addition to editors and authors listed on the title page, the In addition to editors and authors listed on the title page, the
following people have contributed substantially to this document and following people have contributed substantially to this document and
should be considered coauthors: should be considered coauthors:
Carlos Pignataro Carlos Pignataro
Cisco Systems, Inc. Cisco Systems, Inc.
7200-11 Kit Creek Road 7200-11 Kit Creek Road
skipping to change at page 27, line 39 skipping to change at page 29, line 17
Seville 41013 Seville 41013
Spain Spain
Phone: +34 913 129 041 Phone: +34 913 129 041
Email: diego.r.lopez@telefonica.com Email: diego.r.lopez@telefonica.com
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., and T. Mizrahi, "Data Fields
Leddy, J., Youell, S., Mizrahi, T., Mozes, D., Lapukhov, for In-situ OAM", draft-ietf-ippm-ioam-data-10 (work in
P., remy@barefootnetworks.com, r., daniel.bernier@bell.ca, progress), July 2020.
d., and J. Lemon, "Data Fields for In-situ OAM", draft-
ietf-ippm-ioam-data-09 (work in progress), March 2020.
[I-D.ietf-sfc-ioam-nsh] [I-D.ietf-sfc-ioam-nsh]
Brockners, F. and S. Bhandari, "Network Service Header Brockners, F. and S. Bhandari, "Network Service Header
(NSH) Encapsulation for In-situ OAM (IOAM) Data", draft- (NSH) Encapsulation for In-situ OAM (IOAM) Data", draft-
ietf-sfc-ioam-nsh-03 (work in progress), March 2020. ietf-sfc-ioam-nsh-04 (work in progress), June 2020.
[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, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
DOI 10.17487/RFC3688, January 2004,
<https://www.rfc-editor.org/info/rfc3688>.
[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, DOI 10.17487/RFC7665, October 2015,
<https://www.rfc-editor.org/info/rfc7665>. <https://www.rfc-editor.org/info/rfc7665>.
[RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language",
RFC 7950, DOI 10.17487/RFC7950, August 2016,
<https://www.rfc-editor.org/info/rfc7950>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8300] Quinn, P., Ed., Elzur, U., Ed., and C. Pignataro, Ed., [RFC8300] Quinn, P., Ed., Elzur, U., Ed., and C. Pignataro, Ed.,
"Network Service Header (NSH)", RFC 8300, "Network Service Header (NSH)", RFC 8300,
DOI 10.17487/RFC8300, January 2018, DOI 10.17487/RFC8300, January 2018,
<https://www.rfc-editor.org/info/rfc8300>. <https://www.rfc-editor.org/info/rfc8300>.
[SSS] "Shamir's Secret Sharing", [SSS] "How to share a secret", Communications of the ACM (22):
<https://en.wikipedia.org/wiki/Shamir%27s_Secret_Sharing>. 612-613, 1979.
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 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246,
DOI 10.17487/RFC5246, August 2008,
<https://www.rfc-editor.org/info/rfc5246>.
[RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
and A. Bierman, Ed., "Network Configuration Protocol
(NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011,
<https://www.rfc-editor.org/info/rfc6241>.
[RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure
Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011,
<https://www.rfc-editor.org/info/rfc6242>.
[RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF
Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017,
<https://www.rfc-editor.org/info/rfc8040>.
[RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams",
BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018,
<https://www.rfc-editor.org/info/rfc8340>.
[RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration
Access Control Model", STD 91, RFC 8341,
DOI 10.17487/RFC8341, March 2018,
<https://www.rfc-editor.org/info/rfc8341>.
Authors' Addresses
Frank Brockners (editor) 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 (editor) Shwetha Bhandari (editor)
Cisco Systems, Inc. Thoughtspot
Cessna Business Park, Sarjapura Marathalli Outer Ring Road 3rd Floor, Indiqube Orion, 24th Main Rd, Garden Layout, HSR Layout
Bangalore, KARNATAKA 560 087 Bangalore, KARNATAKA 560 102
India India
Email: shwethab@cisco.com Email: shwetha.bhandari@thoughtspot.com
Tal Mizrahi (editor) Tal Mizrahi (editor)
Huawei Network.IO Innovation Lab Huawei Network.IO Innovation Lab
Israel Israel
Email: tal.mizrahi.phd@gmail.com Email: tal.mizrahi.phd@gmail.com
Sashank Dara Sashank Dara
Seconize Seconize
BANGALORE, Bangalore, KARNATAKA BANGALORE, Bangalore, KARNATAKA
INDIA INDIA
 End of changes. 62 change blocks. 
138 lines changed or deleted 232 lines changed or added

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