draft-ietf-sfc-proof-of-transit-07.txt   draft-ietf-sfc-proof-of-transit-08.txt 
Network Working Group F. Brockners, Ed. Network Working Group F. Brockners, Ed.
Internet-Draft Cisco Internet-Draft Cisco
Intended status: Experimental S. Bhandari, Ed. Intended status: Experimental S. Bhandari, Ed.
Expires: April 28, 2021 Thoughtspot Expires: 4 May 2021 Thoughtspot
T. Mizrahi, Ed. 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
October 25, 2020 31 October 2020
Proof of Transit Proof of Transit
draft-ietf-sfc-proof-of-transit-07 draft-ietf-sfc-proof-of-transit-08
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. The document defines the data model through Unified Modeling visit. This document specifies a data model to enable these
Language (UML) class diagrams and formally specifies it using an mechanisms using YANG.
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 April 28, 2021. This Internet-Draft will expire on 4 May 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/
(https://trustee.ietf.org/license-info) in effect on the date of license-info) in effect on the date of publication of this document.
publication of this document. Please review these documents Please review these documents carefully, as they describe your rights
carefully, as they describe your rights and restrictions with respect and restrictions with respect to this document. Code Components
to this document. Code Components extracted from this document must extracted from this document must include Simplified BSD License text
include Simplified BSD License text as described in Section 4.e of as described in Section 4.e of the Trust Legal Provisions and are
the Trust Legal Provisions and are provided without warranty as 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. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Proof of Transit . . . . . . . . . . . . . . . . . . . . . . 5 3. Proof of Transit . . . . . . . . . . . . . . . . . . . . . . 6
3.1. Basic Idea . . . . . . . . . . . . . . . . . . . . . . . 6 3.1. Basic Idea . . . . . . . . . . . . . . . . . . . . . . . 6
3.2. Solution Approach . . . . . . . . . . . . . . . . . . . . 7 3.2. Solution Approach . . . . . . . . . . . . . . . . . . . . 7
3.2.1. Setup . . . . . . . . . . . . . . . . . . . . . . . . 7 3.2.1. Setup . . . . . . . . . . . . . . . . . . . . . . . . 8
3.2.2. In Transit . . . . . . . . . . . . . . . . . . . . . 8 3.2.2. In Transit . . . . . . . . . . . . . . . . . . . . . 8
3.2.3. Verification . . . . . . . . . . . . . . . . . . . . 8 3.2.3. Verification . . . . . . . . . . . . . . . . . . . . 9
3.3. Illustrative Example . . . . . . . . . . . . . . . . . . 8 3.3. Illustrative Example . . . . . . . . . . . . . . . . . . 9
3.3.1. Baseline . . . . . . . . . . . . . . . . . . . . . . 8 3.3.1. Baseline . . . . . . . . . . . . . . . . . . . . . . 9
3.3.1.1. Secret Shares . . . . . . . . . . . . . . . . . . 9 3.3.1.1. Secret Shares . . . . . . . . . . . . . . . . . . 9
3.3.1.2. Lagrange Polynomials . . . . . . . . . . . . . . 9 3.3.1.2. Lagrange Polynomials . . . . . . . . . . . . . . 10
3.3.1.3. LPC Computation . . . . . . . . . . . . . . . . . 9 3.3.1.3. LPC Computation . . . . . . . . . . . . . . . . . 10
3.3.1.4. Reconstruction . . . . . . . . . . . . . . . . . 10 3.3.1.4. Reconstruction . . . . . . . . . . . . . . . . . 10
3.3.1.5. Verification . . . . . . . . . . . . . . . . . . 10 3.3.1.5. Verification . . . . . . . . . . . . . . . . . . 11
3.3.2. Complete Solution . . . . . . . . . . . . . . . . . . 10 3.3.2. Complete Solution . . . . . . . . . . . . . . . . . . 11
3.3.2.1. Random Polynomial . . . . . . . . . . . . . . . . 11 3.3.2.1. Random Polynomial . . . . . . . . . . . . . . . . 11
3.3.2.2. Reconstruction . . . . . . . . . . . . . . . . . 11 3.3.2.2. Reconstruction . . . . . . . . . . . . . . . . . 11
3.3.2.3. Verification . . . . . . . . . . . . . . . . . . 12 3.3.2.3. Verification . . . . . . . . . . . . . . . . . . 12
3.3.3. Solution Deployment Considerations . . . . . . . . . 12 3.3.3. Solution Deployment Considerations . . . . . . . . . 12
3.4. Operational Aspects . . . . . . . . . . . . . . . . . . . 12 3.4. Operational Aspects . . . . . . . . . . . . . . . . . . . 13
3.5. Ordered POT (OPOT) . . . . . . . . . . . . . . . . . . . 13 3.5. Ordered POT (OPOT) . . . . . . . . . . . . . . . . . . . 13
4. Sizing the Data for Proof of Transit . . . . . . . . . . . . 14 4. Sizing the Data for Proof of Transit . . . . . . . . . . . . 14
5. Node Configuration . . . . . . . . . . . . . . . . . . . . . 15 5. Node Configuration . . . . . . . . . . . . . . . . . . . . . 16
5.1. Procedure . . . . . . . . . . . . . . . . . . . . . . . . 15 5.1. Procedure . . . . . . . . . . . . . . . . . . . . . . . . 16
5.2. YANG Model for POT . . . . . . . . . . . . . . . . . . . 16 5.2. YANG Model for POT . . . . . . . . . . . . . . . . . . . 17
5.2.1. Main Parameters . . . . . . . . . . . . . . . . . . . 16 5.2.1. Main Parameters . . . . . . . . . . . . . . . . . . . 17
5.2.2. Tree Diagram . . . . . . . . . . . . . . . . . . . . 17 5.2.2. Tree Diagram . . . . . . . . . . . . . . . . . . . . 18
5.2.3. YANG Model . . . . . . . . . . . . . . . . . . . . . 18 5.2.3. YANG Model . . . . . . . . . . . . . . . . . . . . . 18
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23
7. Security Considerations . . . . . . . . . . . . . . . . . . . 23 7. Security Considerations . . . . . . . . . . . . . . . . . . . 23
7.1. Proof of Transit . . . . . . . . . . . . . . . . . . . . 23 7.1. Proof of Transit . . . . . . . . . . . . . . . . . . . . 24
7.2. Cryptanalysis . . . . . . . . . . . . . . . . . . . . . . 24 7.2. Cryptanalysis . . . . . . . . . . . . . . . . . . . . . . 24
7.3. Anti-Replay . . . . . . . . . . . . . . . . . . . . . . . 24 7.3. Anti-Replay . . . . . . . . . . . . . . . . . . . . . . . 25
7.4. Anti-Preplay . . . . . . . . . . . . . . . . . . . . . . 25 7.4. Anti-Preplay . . . . . . . . . . . . . . . . . . . . . . 26
7.5. Tampering . . . . . . . . . . . . . . . . . . . . . . . . 26 7.5. Tampering . . . . . . . . . . . . . . . . . . . . . . . . 26
7.6. Recycling . . . . . . . . . . . . . . . . . . . . . . . . 26 7.6. Recycling . . . . . . . . . . . . . . . . . . . . . . . . 26
7.7. Redundant Nodes and Failover . . . . . . . . . . . . . . 26 7.7. Redundant Nodes and Failover . . . . . . . . . . . . . . 27
7.8. Controller Operation . . . . . . . . . . . . . . . . . . 26 7.8. Controller Operation . . . . . . . . . . . . . . . . . . 27
7.9. Verification Scope . . . . . . . . . . . . . . . . . . . 27 7.9. Verification Scope . . . . . . . . . . . . . . . . . . . 27
7.9.1. Node Ordering . . . . . . . . . . . . . . . . . . . . 27 7.9.1. Node Ordering . . . . . . . . . . . . . . . . . . . . 28
7.9.2. Stealth Nodes . . . . . . . . . . . . . . . . . . . . 27 7.9.2. Stealth Nodes . . . . . . . . . . . . . . . . . . . . 28
7.10. POT Yang module . . . . . . . . . . . . . . . . . . . . . 27 7.10. POT Yang module . . . . . . . . . . . . . . . . . . . . . 28
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 28 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 29
9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 28 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 29
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 29 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 29
10.1. Normative References . . . . . . . . . . . . . . . . . . 29 10.1. Normative References . . . . . . . . . . . . . . . . . . 29
10.2. Informative References . . . . . . . . . . . . . . . . . 30 10.2. Informative References . . . . . . . . . . . . . . . . . 30
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 30 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 31
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,
compliance policies require operators to prove that all packets that compliance policies require operators to prove that all packets that
are supposed to follow a specific path are indeed being forwarded are supposed to follow a specific path are indeed being forwarded
across an exact set of pre-determined nodes. across an exact set of pre-determined nodes.
skipping to change at page 4, line 29 skipping to change at page 4, line 50
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. This validate whether the packet traversed the path correctly. This
document defines a data model and specifies it formally using the document defines a data model and specifies it formally using the
YANG 1.1 [RFC7950] data modeling language to support enabling the POT YANG 1.1 [RFC7950] data modeling language to support enabling the POT
solution. solution. The YANG data model defined in this document conforms to
the Network Management Datastore Architecture (NMDA) defined in
[RFC8342].
Note to RFC Editor: Please replace the date 2020-09-09 in Section 5.2 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. 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- Also, replace reference to RFC XXXX, and draft-ietf-sfc-proof-of-
transit with the RFC numbers assigned to the drafts. transit with the RFC numbers assigned to the drafts.
2. Terminology 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", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
skipping to change at page 15, line 5 skipping to change at page 15, line 20
The size of the data fields determines how often a new set of The size of the data fields determines how often a new set of
polynomials would need to be created. At maximum, the largest RND polynomials would need to be created. At maximum, the largest RND
number that can be represented with a given number of bits determines number that can be represented with a given number of bits determines
the number of unique polynomials POLY-2 that can be created. The the number of unique polynomials POLY-2 that can be created. The
table below shows the maximum interval for how long a single set of table below shows the maximum interval for how long a single set of
polynomials could last for a variety of bit rates and RND sizes: When polynomials could last for a variety of bit rates and RND sizes: When
choosing 64 bits for RND and CML data fields, the time between a choosing 64 bits for RND and CML data fields, the time between a
renewal of secrets could be as long as 3,100 years, even when running renewal of secrets could be as long as 3,100 years, even when running
at 100 Gbps. at 100 Gbps.
+-------------+--------------+------------------+-------------------+ +===============+=================+================+===============+
| Transfer | Secret/RND | Max # of packets | Time RND lasts | | Transfer rate | Secret/RND size | Max # of | Time RND |
| rate | size | | | | | | packets | lasts |
+-------------+--------------+------------------+-------------------+ +===============+=================+================+===============+
| 1 Gbps | 64 | 2^64 = approx. | approx. 310,000 | | 1 Gbps | 64 | 2^64 = approx. | approx. |
| | | 2*10^19 | years | | | | 2*10^19 | 310,000 years |
| 10 Gbps | 64 | 2^64 = approx. | approx. 31,000 | +---------------+-----------------+----------------+---------------+
| | | 2*10^19 | years | | 10 Gbps | 64 | 2^64 = approx. | approx. |
| 100 Gbps | 64 | 2^64 = approx. | approx. 3,100 | | | | 2*10^19 | 31,000 years |
| | | 2*10^19 | years | +---------------+-----------------+----------------+---------------+
| 1 Gbps | 32 | 2^32 = approx. | 2,200 seconds | | 100 Gbps | 64 | 2^64 = approx. | approx. 3,100 |
| | | 4*10^9 | | | | | 2*10^19 | years |
| 10 Gbps | 32 | 2^32 = approx. | 220 seconds | +---------------+-----------------+----------------+---------------+
| | | 4*10^9 | | | 1 Gbps | 32 | 2^32 = approx. | 2,200 seconds |
| 100 Gbps | 32 | 2^32 = approx. | 22 seconds | | | | 4*10^9 | |
| | | 4*10^9 | | +---------------+-----------------+----------------+---------------+
+-------------+--------------+------------------+-------------------+ | 10 Gbps | 32 | 2^32 = approx. | 220 seconds |
| | | 4*10^9 | |
+---------------+-----------------+----------------+---------------+
| 100 Gbps | 32 | 2^32 = approx. | 22 seconds |
| | | 4*10^9 | |
+---------------+-----------------+----------------+---------------+
Table assumes 64 octet packets Table 1: Proof of transit data sizing
Table 1: Proof of transit data sizing Table assumes 64 octet packets
If the symmetric masking method for ordered POT is used If the symmetric masking method for ordered POT is used
(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,
skipping to change at page 16, line 37 skipping to change at page 17, line 15
5.2. YANG Model for POT 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 node. exchange between the Controller and the node.
5.2.1. Main Parameters 5.2.1. Main Parameters
The main parameters for the information exchange between the The main parameters for the information exchange between the
Controller and the node used in the YANG model are as follows: 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 * 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 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 time, allowing the Controller to refresh the non-active one for
future use. pot-profile-index defines which of the POT-Profiles future use. pot-profile-index defines which of the POT-Profiles
(the "even" or "odd" POT-Profile) is currently active. pot- (the "even" or "odd" POT-Profile) is currently active. pot-
profile-index will be set in the first hop of the path or chain. profile-index 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.
o prime-number: Prime number used for module math computation. * prime-number: Prime number used for module math computation.
o secret-share: Share of the secret of polynomial-1 used in * secret-share: Share of the secret of polynomial-1 used in
computation for the node. If POLY-1 is defined by points (x1_i, 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) with i=0,..k, then for node i, the secret-share will be
y1_i. y1_i.
o public-polynomial: Public polynomial value for the node.. If * 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 * 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. * validator: True if the node is a verifier node.
o validator-key: The validator-key represents the SECRET as * 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 * 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 YANG tree diagrams data model for POT. The meaning of the symbols in YANG tree diagrams
is defined in [RFC8340]. is defined in [RFC8340].
module: ietf-pot-profile module: ietf-pot-profile
skipping to change at page 18, line 9 skipping to change at page 18, line 33
+--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
5.2.3. YANG Model 5.2.3. YANG Model
<CODE BEGINS> file "ietf-pot-profile@2020-09-08.yang" <CODE BEGINS> file "ietf-pot-profile@2020-09-08.yang"
module ietf-pot-profile { module ietf-pot-profile {
yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-pot-profile"; namespace "urn:ietf:params:xml:ns:yang:ietf-pot-profile";
prefix "pot"; prefix "pot";
import ietf-netconf-acm { import ietf-netconf-acm {
prefix nacm; prefix nacm;
reference
"RFC 8341: Network Configuration Access Control Model";
} }
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 : Frank Brockners <fbrockne@cisco.com>
Author : Shwetha Bhandari <shwethab@cisco.com> Author : Shwetha Bhandari <shwethab@cisco.com>
Author : Tal Mizrahi <tal.mizrahi.phd@gmail.com>"; Author : Tal Mizrahi <tal.mizrahi.phd@gmail.com>";
skipping to change at page 19, line 4 skipping to change at page 19, line 31
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 to without modification, is permitted pursuant to, and subject to
the license terms contained in, the Simplified BSD License set the license terms contained in, the Simplified BSD License 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
(https://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
(https://www.rfc-editor.org/info/rfcXXXX); see the RFC (https://www.rfc-editor.org/info/rfcXXXX); see the RFC
itself for full legal notices. itself for full legal notices.
The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL',
'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED',
'NOT RECOMMENDED', 'MAY', and 'OPTIONAL' in this document 'NOT RECOMMENDED', 'MAY', and 'OPTIONAL' in this document
are to be interpreted as described in BCP 14 (RFC 2119) are to be interpreted as described in BCP 14 (RFC 2119)
(RFC 8174) when, and only when, they appear in all (RFC 8174) when, and only when, they appear in all
capitals, as shown here."; capitals, as shown here.";
revision "2020-09-08" { revision "2020-09-08" {
description description
"Addressing WGLC comments"; "Initial revision.";
reference reference
"draft-ietf-sfc-proof-of-transit"; "RFC XXXX: Proof of Transit";
} }
revision 2016-06-15 {
description
"Initial revision.";
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.";
} }
grouping pot-profile { grouping pot-profile {
description "A grouping for proof of transit profiles."; description "A grouping for proof of transit profiles.";
list pot-profile-list { list pot-profile-list {
key "pot-profile-index"; key "pot-profile-index";
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;
skipping to change at page 23, line 38 skipping to change at page 24, line 14
7.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- * 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
and assigned to each node respectively. The verifier can re- and assigned to each node respectively. The verifier can re-
construct the k degree polynomial (POLY-3) only when all the construct the k degree polynomial (POLY-3) only when all the
points are correctly retrieved. points are correctly retrieved.
o Precisely three values are kept secret by individual nodes. Share * Precisely three values are kept secret by individual nodes. Share
of SECRET (i.e. points on POLY-1), Share of POLY-2, LPC, P. Note of SECRET (i.e. points on POLY-1), Share of POLY-2, LPC, P. Note
that only constant coefficient, RND, of POLY-2 is public. x values that only constant coefficient, RND, of POLY-2 is public. x values
and non-constant coefficient of POLY-2 are secret and non-constant coefficient of POLY-2 are secret
An attacker bypassing a few nodes will miss adding a respective point An attacker bypassing a few nodes will miss adding a respective point
on POLY-1 to corresponding point on POLY-2 , thus the verifier cannot on POLY-1 to corresponding point on POLY-2 , thus the verifier cannot
construct POLY-3 for cross verification. construct POLY-3 for cross verification.
Also it is highly recommended that different polynomials should be Also it is highly recommended that different polynomials should be
used as POLY-1 across different paths, traffic profiles or service used as POLY-1 across different paths, traffic profiles or service
skipping to change at page 24, line 23 skipping to change at page 25, line 5
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.
7.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 * 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-
1), Share(Poly-2) LPC and prime number P) and three known values 1), Share(Poly-2) LPC and prime number P) and three known values
(i.e. RND, CML-before, CML-after). The application of symmetric (i.e. RND, CML-before, CML-after). The application of symmetric
masking for OPOT makes inter-node analysis less feasible. masking for OPOT makes inter-node analysis less feasible.
o Inter-Packets: A passive attacker could observe CML values across * 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.
7.3. Anti-Replay 7.3. Anti-Replay
skipping to change at page 25, line 30 skipping to change at page 26, line 16
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:
o Ingress node and Verifier are configured with common pre shared * Ingress node and Verifier are configured with common pre shared
key key
o Ingress node generates a Message Authentication Code (MAC) from * Ingress node generates a Message Authentication Code (MAC) from
packet fields using standard HMAC algorithm. packet fields using standard HMAC algorithm.
o The left most bits of the output are truncated to desired length * The left most bits of the output are truncated to desired length
to generate RND. It is recommended to use a minimum of 32 bits. to generate RND. It is recommended to use a minimum of 32 bits.
o The verifier regenerates the HMAC from the packet fields and * The verifier regenerates the HMAC from the packet fields and
compares with RND. To ensure the POT data is in fact that of the compares with RND. To ensure the POT data is in fact that of the
packet. packet.
If an HMAC is used, an active attacker lacks the knowledge of the If an HMAC is used, an active attacker lacks the knowledge of the
pre-shared key, and thus cannot launch preplay attacks. pre-shared key, and thus cannot launch preplay attacks.
The solution discussed in this memo does not currently mitigate The solution discussed in this memo does not currently mitigate
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.
skipping to change at page 28, line 8 skipping to change at page 28, line 41
schema for data that is designed to be accessed via network schema for data that is designed to be accessed via network
management protocols such as NETCONF [RFC6241] or RESTCONF [RFC8040]. management protocols such as NETCONF [RFC6241] or RESTCONF [RFC8040].
The lowest NETCONF [RFC6241] layer is the secure transport layer, and The lowest NETCONF [RFC6241] layer is the secure transport layer, and
the mandatory-to-implement secure transport is Secure Shell (SSH) the mandatory-to-implement secure transport is Secure Shell (SSH)
[RFC6242]. The lowest RESTCONF layer is HTTPS, and the mandatory-to- [RFC6242]. The lowest RESTCONF layer is HTTPS, and the mandatory-to-
implement secure transport is TLS [RFC5246]. implement secure transport is TLS [RFC5246].
The NETCONF Access Control Module (NACM) [RFC8341] provides the means The NETCONF Access Control Module (NACM) [RFC8341] provides the means
to restrict access for particular NETCONF or RESTCONF users to a to restrict access for particular NETCONF or RESTCONF users to a
preconfigured subset of all available NETCONF or RESTCONF protocol preconfigured subset of all available NETCONF or RESTCONF protocol
operations and content. There are a number of nodes defined in this operations and content. The nodes defined in this YANG module to
YANG module which are read/writeable. These data nodes may be specify secret-share, prime-number, and validator-key are read/
considered sensitive and vulnerable to attacks in some network writeable. These data nodes are considered sensitive and vulnerable
environments. Ability to read from or write into these nodes without to attacks in some network environments. Ability to read from or
proper protection can have a negative effect on the devices that write into these nodes without proper protection can have a negative
support this feature. 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, Andrew Yourtchenko, Tom Petch, Mohamed Nadahalli, Erik Nordmark, Andrew Yourtchenko, Tom Petch, Mohamed
Boucadair and Dhruv Dhody for the comments and advice. Boucadair and Dhruv Dhody for the comments and advice.
9. Contributors 9. Contributors
skipping to change at page 29, line 18 skipping to change at page 30, line 7
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., and T. Mizrahi, "Data Fields Brockners, F., Bhandari, S., and T. Mizrahi, "Data Fields
for In-situ OAM", draft-ietf-ippm-ioam-data-10 (work in for In-situ OAM", Work in Progress, Internet-Draft, draft-
progress), July 2020. ietf-ippm-ioam-data-10, 13 July 2020,
<http://www.ietf.org/internet-drafts/draft-ietf-ippm-ioam-
data-10.txt>.
[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", Work in
ietf-sfc-ioam-nsh-04 (work in progress), June 2020. Progress, Internet-Draft, draft-ietf-sfc-ioam-nsh-04, 16
June 2020, <http://www.ietf.org/internet-drafts/draft-
ietf-sfc-ioam-nsh-04.txt>.
[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, [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
DOI 10.17487/RFC3688, January 2004, DOI 10.17487/RFC3688, January 2004,
<https://www.rfc-editor.org/info/rfc3688>. <https://www.rfc-editor.org/info/rfc3688>.
skipping to change at page 30, line 10 skipping to change at page 30, line 46
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/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] "How to share a secret", Communications of the ACM (22): [SSS] A., S., "How to share a secret", Communications of the
612-613, 1979. ACM (22): 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)", Work in Progress, Internet-Draft,
plane-18 (work in progress), August 2018. draft-ietf-anima-autonomic-control-plane-18, 7 August
2018, <http://www.ietf.org/internet-drafts/draft-ietf-
anima-autonomic-control-plane-18.txt>.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, (TLS) Protocol Version 1.2", RFC 5246,
DOI 10.17487/RFC5246, August 2008, DOI 10.17487/RFC5246, August 2008,
<https://www.rfc-editor.org/info/rfc5246>. <https://www.rfc-editor.org/info/rfc5246>.
[RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
and A. Bierman, Ed., "Network Configuration Protocol and A. Bierman, Ed., "Network Configuration Protocol
(NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011,
<https://www.rfc-editor.org/info/rfc6241>. <https://www.rfc-editor.org/info/rfc6241>.
skipping to change at page 30, line 47 skipping to change at page 31, line 39
[RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams",
BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018,
<https://www.rfc-editor.org/info/rfc8340>. <https://www.rfc-editor.org/info/rfc8340>.
[RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration [RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration
Access Control Model", STD 91, RFC 8341, Access Control Model", STD 91, RFC 8341,
DOI 10.17487/RFC8341, March 2018, DOI 10.17487/RFC8341, March 2018,
<https://www.rfc-editor.org/info/rfc8341>. <https://www.rfc-editor.org/info/rfc8341>.
[RFC8342] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K.,
and R. Wilton, "Network Management Datastore Architecture
(NMDA)", RFC 8342, DOI 10.17487/RFC8342, March 2018,
<https://www.rfc-editor.org/info/rfc8342>.
Authors' Addresses 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 40549 DUESSELDORF
Germany Germany
Email: fbrockne@cisco.com Email: fbrockne@cisco.com
Shwetha Bhandari (editor) Shwetha Bhandari (editor)
Thoughtspot Thoughtspot
3rd Floor, Indiqube Orion, 24th Main Rd, Garden Layout, HSR Layout 3rd Floor, Indiqube Orion, 24th Main Rd, Garden Layout, HSR Layout
Bangalore, KARNATAKA 560 102 Bangalore, KARNATAKA 560 102
India India
Email: shwetha.bhandari@thoughtspot.com Email: shwetha.bhandari@thoughtspot.com
Tal Mizrahi (editor) Tal Mizrahi (editor)
Huawei Network.IO Innovation Lab Huawei Network.IO Innovation Lab
skipping to change at page 31, line 28 skipping to change at page 32, line 20
Email: shwetha.bhandari@thoughtspot.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
INDIA Bangalore, KARNATAKA
India
Email: sashank@seconize.co Email: sashank@seconize.co
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
 End of changes. 55 change blocks. 
112 lines changed or deleted 123 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/