draft-ietf-sfc-proof-of-transit-00.txt   draft-ietf-sfc-proof-of-transit-01.txt 
Network Working Group F. Brockners Network Working Group F. Brockners
Internet-Draft S. Bhandari Internet-Draft S. Bhandari
Intended status: Experimental S. Dara Intended status: Experimental S. Dara
Expires: December 2, 2018 C. Pignataro Expires: April 4, 2019 C. Pignataro
Cisco Cisco
J. Leddy J. Leddy
Comcast Comcast
S. Youell S. Youell
JPMC JPMC
D. Mozes D. Mozes
T. Mizrahi T. Mizrahi
Marvell Marvell
May 31, 2018 A. Aguado
Universidad Politecnica de Madrid
D. Lopez
Telefonica I+D
October 1, 2018
Proof of Transit Proof of Transit
draft-ietf-sfc-proof-of-transit-00 draft-ietf-sfc-proof-of-transit-01
Abstract Abstract
Several technologies such as Traffic Engineering (TE), Service Several technologies such as Traffic Engineering (TE), Service
Function Chaining (SFC), and policy based routing are used to steer Function Chaining (SFC), and policy based routing are used to steer
traffic through a specific, user-defined path. This document defines traffic through a specific, user-defined path. This document defines
mechanisms to securely prove that traffic transited said defined mechanisms to securely prove that traffic transited said defined
path. These mechanisms allow to securely verify whether, within a path. These mechanisms allow to securely verify whether, within a
given path, all packets traversed all the nodes that they are given path, all packets traversed all the nodes that they are
supposed to visit. supposed to visit.
skipping to change at page 1, line 45 skipping to change at page 2, line 4
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 4, 2019.
This Internet-Draft will expire on December 2, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2018 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 43 skipping to change at page 2, line 44
3.3.1.2. Lagrange Polynomials . . . . . . . . . . . . . . 8 3.3.1.2. Lagrange Polynomials . . . . . . . . . . . . . . 8
3.3.1.3. LPC Computation . . . . . . . . . . . . . . . . . 8 3.3.1.3. LPC Computation . . . . . . . . . . . . . . . . . 8
3.3.1.4. Reconstruction . . . . . . . . . . . . . . . . . 9 3.3.1.4. Reconstruction . . . . . . . . . . . . . . . . . 9
3.3.1.5. Verification . . . . . . . . . . . . . . . . . . 9 3.3.1.5. Verification . . . . . . . . . . . . . . . . . . 9
3.3.2. Enhanced Version . . . . . . . . . . . . . . . . . . 9 3.3.2. Enhanced Version . . . . . . . . . . . . . . . . . . 9
3.3.2.1. Random Polynomial . . . . . . . . . . . . . . . . 9 3.3.2.1. Random Polynomial . . . . . . . . . . . . . . . . 9
3.3.2.2. Reconstruction . . . . . . . . . . . . . . . . . 10 3.3.2.2. Reconstruction . . . . . . . . . . . . . . . . . 10
3.3.2.3. Verification . . . . . . . . . . . . . . . . . . 10 3.3.2.3. Verification . . . . . . . . . . . . . . . . . . 10
3.3.3. Final Version . . . . . . . . . . . . . . . . . . . . 11 3.3.3. Final Version . . . . . . . . . . . . . . . . . . . . 11
3.4. Operational Aspects . . . . . . . . . . . . . . . . . . . 11 3.4. Operational Aspects . . . . . . . . . . . . . . . . . . . 11
3.5. Alternative Approach . . . . . . . . . . . . . . . . . . 12 3.5. Ordered POT (OPOT) . . . . . . . . . . . . . . . . . . . 12
3.5.1. Basic Idea . . . . . . . . . . . . . . . . . . . . . 12 3.5.1. Nested Encryption . . . . . . . . . . . . . . . . . . 12
3.5.2. Pros . . . . . . . . . . . . . . . . . . . . . . . . 12 3.5.2. Symmetric Masking Between Nodes . . . . . . . . . . . 12
3.5.3. Cons . . . . . . . . . . . . . . . . . . . . . . . . 12 4. Sizing the Data for Proof of Transit . . . . . . . . . . . . 13
4. Sizing the Data for Proof of Transit . . . . . . . . . . . . 12 5. Node Configuration . . . . . . . . . . . . . . . . . . . . . 14
5. Node Configuration . . . . . . . . . . . . . . . . . . . . . 13
5.1. Procedure . . . . . . . . . . . . . . . . . . . . . . . . 14 5.1. Procedure . . . . . . . . . . . . . . . . . . . . . . . . 14
5.2. YANG Model . . . . . . . . . . . . . . . . . . . . . . . 14 5.2. YANG Model . . . . . . . . . . . . . . . . . . . . . . . 15
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
7. Manageability Considerations . . . . . . . . . . . . . . . . 17 7. Manageability Considerations . . . . . . . . . . . . . . . . 18
8. Security Considerations . . . . . . . . . . . . . . . . . . . 17 8. Security Considerations . . . . . . . . . . . . . . . . . . . 18
8.1. Proof of Transit . . . . . . . . . . . . . . . . . . . . 18 8.1. Proof of Transit . . . . . . . . . . . . . . . . . . . . 18
8.2. Cryptanalysis . . . . . . . . . . . . . . . . . . . . . . 18 8.2. Cryptanalysis . . . . . . . . . . . . . . . . . . . . . . 19
8.3. Anti-Replay . . . . . . . . . . . . . . . . . . . . . . . 19 8.3. Anti-Replay . . . . . . . . . . . . . . . . . . . . . . . 20
8.4. Anti-Preplay . . . . . . . . . . . . . . . . . . . . . . 19 8.4. Anti-Preplay . . . . . . . . . . . . . . . . . . . . . . 20
8.5. Anti-Tampering . . . . . . . . . . . . . . . . . . . . . 20 8.5. Anti-Tampering . . . . . . . . . . . . . . . . . . . . . 21
8.6. Recycling . . . . . . . . . . . . . . . . . . . . . . . . 20 8.6. Recycling . . . . . . . . . . . . . . . . . . . . . . . . 21
8.7. Redundant Nodes and Failover . . . . . . . . . . . . . . 20 8.7. Redundant Nodes and Failover . . . . . . . . . . . . . . 21
8.8. Controller Operation . . . . . . . . . . . . . . . . . . 20 8.8. Controller Operation . . . . . . . . . . . . . . . . . . 21
8.9. Verification Scope . . . . . . . . . . . . . . . . . . . 21 8.9. Verification Scope . . . . . . . . . . . . . . . . . . . 22
8.9.1. Node Ordering . . . . . . . . . . . . . . . . . . . . 21 8.9.1. Node Ordering . . . . . . . . . . . . . . . . . . . . 22
8.9.2. Stealth Nodes . . . . . . . . . . . . . . . . . . . . 21 8.9.2. Stealth Nodes . . . . . . . . . . . . . . . . . . . . 22
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 21 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 23
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 21 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 23
10.1. Normative References . . . . . . . . . . . . . . . . . . 21 10.1. Normative References . . . . . . . . . . . . . . . . . . 23
10.2. Informative References . . . . . . . . . . . . . . . . . 22 10.2. Informative References . . . . . . . . . . . . . . . . . 23
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23
1. Introduction 1. Introduction
Several deployments use Traffic Engineering, policy routing, Segment Several deployments use Traffic Engineering, policy routing, Segment
Routing (SR), and Service Function Chaining (SFC) [RFC7665] to steer Routing (SR), and Service Function Chaining (SFC) [RFC7665] to steer
packets through a specific set of nodes. In certain cases, packets through a specific set of nodes. In certain cases,
regulatory obligations or a compliance policy require operators to regulatory obligations or a compliance policy require operators to
prove that all packets that are supposed to follow a specific path prove that all packets that are supposed to follow a specific path
are indeed being forwarded across and exact set of pre-determined are indeed being forwarded across and exact set of pre-determined
nodes. nodes.
skipping to change at page 4, line 31 skipping to change at page 4, line 32
complete key set is only known to the controller and a verifier node, complete key set is only known to the controller and a verifier node,
which is typically the ultimate node on a path that performs which is typically the ultimate node on a path that performs
verification. Each node in the path uses its secret or share of the verification. Each node in the path uses its secret or share of the
secret to update the POT data of the packets as the packets pass secret to update the POT data of the packets as the packets pass
through the node. When the verifier receives a packet, it uses its through the node. When the verifier receives a packet, it uses its
key(s) along with data found in the packet to validate whether the key(s) along with data found in the packet to validate whether the
packet traversed the path correctly. packet traversed the path correctly.
2. Conventions 2. Conventions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
Abbreviations used in this document: Abbreviations used in this document:
HMAC: Hash based Message Authentication Code. For example, HMAC: Hash based Message Authentication Code. For example,
HMAC-SHA256 generates 256 bits of MAC HMAC-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
skipping to change at page 12, line 5 skipping to change at page 12, line 5
all the coefficients of the public polynomial had to be added to all the coefficients of the public polynomial had to be added to
the POT profile and each node had to evaluate them. As stated the POT profile and each node had to evaluate them. As stated
before, the public portion is only the constant coefficient RND before, the public portion is only the constant coefficient RND
value, the pre-evaluated portion for each node should be kept value, the pre-evaluated portion for each node should be kept
secret as well. secret as well.
3. To provide flexibility on the size of the cumulative and random 3. To provide flexibility on the size of the cumulative and random
numbers carried in the POT data a field to indicate this is numbers carried in the POT data a field to indicate this is
shared and interpreted at the nodes. shared and interpreted at the nodes.
3.5. Alternative Approach 3.5. Ordered POT (OPOT)
In certain scenarios preserving the order of the nodes traversed by In certain scenarios preserving the order of the nodes traversed by
the packet may be needed. An alternative, "nested encryption" based the packet may be needed. Two alternatives, one based on "nested
approach is described here for preserving the order encryption", and another based on "symmetric masking between nodes"
are described here for preserving the order
3.5.1. Basic Idea 3.5.1. Nested Encryption
1. The controller provisions all the nodes with their respective 1. The controller provisions all the nodes with their respective
secret keys. secret keys.
2. The controller provisions the verifier with all the secret keys 2. The controller provisions the verifier with all the secret keys
of the nodes. of the nodes.
3. For each packet, the ingress node generates a random number RND 3. For each packet, the ingress node generates a random number RND
and encrypts it with its secret key to generate CML value and encrypts it with its secret key to generate CML value
4. Each subsequent node on the path encrypts CML with their 4. Each subsequent node on the path encrypts CML with their
respective secret key and passes it along respective secret key and passes it along
5. The verifier is also provisioned with the expected sequence of 5. The verifier is also provisioned with the expected sequence of
nodes in order to verify the order nodes in order to verify the order
6. The verifier receives the CML, RND values, re-encrypts the RND 6. The verifier receives the CML, RND values, re-encrypts the RND
with keys in the same order as expected sequence to verify. with keys in the same order as expected sequence to verify.
3.5.2. Pros With this nested encryption approach it is possible to retain the
order in which the nodes are traversed, at the cost of:
Nested encryption approach retains the order in which the nodes are
traversed.
3.5.3. Cons
1. Standard AES encryption would need 128 bits of RND, CML. This 1. Standard AES encryption would need 128 bits of RND, CML. This
results in a 256 bits of additional overhead is added per packet results in a 256 bits of additional overhead is added per packet
2. In hardware platforms that do not support native encryption 2. In hardware platforms that do not support native encryption
capabilities like (AES-NI). This approach would have capabilities like (AES-NI). This approach would have
considerable impact on the computational latency considerable impact on the computational latency
3.5.2. Symmetric Masking Between Nodes
1. The controller provisions all the nodes with (or asks them to
agree on) a couple of secrets, that we will refer as masks, one
for the connection from the upstream node(s), another for the
connection to the downstream node(s). For obvious reasons, the
ingress and egress (verifier) nodes only receive one, for
downstream and upstream, respectively.
2. Any two contiguous nodes in the OPOT stream share the mask for
the connection between them, in the shape of symmetric keys.
Masks can be refreshed as per-policy, defined at each hop or
globally by the controller.
3. Each mask has the same size in bits as the length assigned to CML
plus RND, as described in the above sections.
4. Whenever a packet is received at an intermediate node, the
CML+RND sequence is deciphered (by XORing, though other ciphering
schemas MAY be possible) with the upstream mask before applying
the procedures described in Section 3.3.2.
5. Once the new values of CML+RND are produced, they are ciphered
(by XORing, though other ciphering schemas MAY be possible) with
the downstream mask before transmitting the packet to the next
node downstream.
6. The ingress node only applies step 5 above, while the verifier
only applies step 4 before running the verification procedure.
The described process allows the verifier to check if the packet has
followed the correct order while traversing the path. In particular,
the reconstruction process will fail if the order is not respected,
as the deciphering process will produce invalid CML and RND values,
and the interpolation (secret reconstruction) will finally generate a
wrong verification value.
This procedure does not impose a high computational burden, does not
require additional packet overhead, can be deployed on chains of any
length, does not require any node to be aware of any additional
information than the upstream and downstream masks, and can be
integrated with the other operational mechanisms applied by the
controller to distribute shares and other secret material.
4. Sizing the Data for Proof of Transit 4. Sizing the Data for Proof of Transit
Proof of transit requires transport of two data fields in every Proof of transit requires transport of two data fields in every
packet that should be verified: packet that should be verified:
1. RND: Random number (the constant coefficient of public 1. RND: Random number (the constant coefficient of public
polynomial) polynomial)
2. CML: Cumulative 2. CML: Cumulative
skipping to change at page 13, line 39 skipping to change at page 14, line 31
| 10 Gbps | 32 | 2^32 = approx. | 220 seconds | | 10 Gbps | 32 | 2^32 = approx. | 220 seconds |
| | | 4*10^9 | | | | | 4*10^9 | |
| 100 Gbps | 32 | 2^32 = approx. | 22 seconds | | 100 Gbps | 32 | 2^32 = approx. | 22 seconds |
| | | 4*10^9 | | | | | 4*10^9 | |
+-------------+--------------+------------------+-------------------+ +-------------+--------------+------------------+-------------------+
Table assumes 64 octet packets Table assumes 64 octet packets
Table 1: Proof of transit data sizing Table 1: Proof of transit data sizing
If the symmetric masking method for ordered POT is used
(Section 3.5.2), 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 5. Node Configuration
A POT system consists of a number of nodes that participate in POT A POT system consists of a number of nodes that participate in POT
and a Controller, which serves as a control and configuration entity. and a Controller, which serves as a control and configuration entity.
The Controller is to create the required parameters (polynomials, The Controller is to create the required parameters (polynomials,
prime number, etc.) and communicate those to the nodes. The sum of prime number, etc.) and communicate those to the nodes. The sum of
all parameters for a specific node is referred to as "POT-profile". all parameters for a specific node is referred to as "POT-profile".
This document does not define a specific protocol to be used between This document does not define a specific protocol to be used between
Controller and nodes. It only defines the procedures and the Controller and nodes. It only defines the procedures and the
associated YANG data model. associated YANG data model.
skipping to change at page 18, line 33 skipping to change at page 19, line 24
and non-constant coefficient of POLY-2 are secret and non-constant coefficient of POLY-2 are secret
An attacker bypassing a few nodes will miss adding a respective point An attacker bypassing a few nodes will miss adding a respective point
on POLY-1 to corresponding point on POLY-2 , thus the verifier cannot on POLY-1 to corresponding point on POLY-2 , thus the verifier cannot
construct POLY-3 for cross verification. construct POLY-3 for cross verification.
Also it is highly recommended that different polynomials should be Also it is highly recommended that different polynomials should be
used as POLY-1 across different paths, traffic profiles or service used as POLY-1 across different paths, traffic profiles or service
chains. chains.
If symmetric masking is used to assure OPOT (Section 3.5.2), the
nodes need to keep two additional secrets: the upstream 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 8.2. Cryptanalysis
A passive attacker could try to harvest the POT data (i.e., CML, RND A passive attacker could try to harvest the POT data (i.e., CML, RND
values) in order to determine the configured secrets. Subsequently values) in order to determine the configured secrets. Subsequently
two types of differential analysis for guessing the secrets could be two types of differential analysis for guessing the secrets could be
done. done.
o Inter-Node: A passive attacker observing CML values across nodes o Inter-Node: A passive attacker observing CML values across nodes
(i.e., as the packets entering and leaving), cannot perform (i.e., as the packets entering and leaving), cannot perform
differential analysis to construct the points on POLY-1. This is differential analysis to construct the points on POLY-1. This is
because at each point there are four unknowns (i.e. Share(POLY- because at each point there are four unknowns (i.e. Share(POLY-
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). (i.e. RND, CML-before, CML-after). The application of symmetric
masking for OPOT makes inter-node analysis less feasible.
o Inter-Packets: A passive attacker could observe CML values across o Inter-Packets: A passive attacker could observe CML values across
packets (i.e., values of PKT-1 and subsequent PKT-2), in order to packets (i.e., values of PKT-1 and subsequent PKT-2), in order to
predict the secrets. Differential analysis across packets could predict the secrets. Differential analysis across packets could
be mitigated using a good PRNG for generating RND. Note that if be mitigated using a good PRNG for generating RND. Note that if
constant coefficient is a sequence number than CML values become constant coefficient is a sequence number than CML values become
quite predictable and the scheme would be broken. quite predictable and the scheme would be broken. If symmetric
masking is used for OPOT, inter-packet analysis could be applied
to guess mask values, what requires a proper refresh rate for
masks, at least as high as the one used for LPCs.
8.3. Anti-Replay 8.3. Anti-Replay
A passive attacker could reuse a set of older RND and the A passive attacker could reuse a set of older RND and the
intermediate CML values to bypass certain nodes in later packets. intermediate CML values to bypass certain nodes in later packets.
Such attacks could be avoided by carefully choosing POLY-2 as a Such attacks could be avoided by carefully choosing POLY-2 as a
(SEQ_NO + RND). For example, if 64 bits are being used for POLY-2 (SEQ_NO + RND). For example, if 64 bits are being used for POLY-2
then first 16 bits could be a sequence number SEQ_NO and next 48 bits then first 16 bits could be a sequence number SEQ_NO and next 48 bits
could be a random number. could be a random number.
skipping to change at page 20, line 27 skipping to change at page 21, line 31
value. This could subsequently be detected by using timestamps value. This could subsequently be detected by using timestamps
within the RND value as discussed above. within the RND value as discussed above.
8.6. Recycling 8.6. Recycling
The solution approach is flexible for recycling long term secrets The solution approach is flexible for recycling long term secrets
like POLY-1. All the nodes could be periodically updated with shares like POLY-1. All the nodes could be periodically updated with shares
of new SECRET as best practice. The table above could be consulted of new SECRET as best practice. The table above could be consulted
for refresh cycles (see Section 4). for refresh cycles (see Section 4).
If symmetric masking is used for OPOT (Section 3.5.2), mask values
must be periodically updated as well, at least as frequently as the
other secrets are.
8.7. Redundant Nodes and Failover 8.7. Redundant Nodes and Failover
A "node" or "service" in terms of POT can be implemented by one or A "node" or "service" in terms of POT can be implemented by one or
multiple physical entities. In case of multiple physical entities multiple physical entities. In case of multiple physical entities
(e.g., for load-balancing, or business continuity situations - (e.g., for load-balancing, or business continuity situations -
consider for example a set of firewalls), all physical entities which consider for example a set of firewalls), all physical entities which
are implementing the same POT node are given that same share of the are implementing the same POT node are given that same share of the
secret. This makes multiple physical entities represent the same POT secret. This makes multiple physical entities represent the same POT
node from an algorithm perspective. node from an algorithm perspective.
skipping to change at page 21, line 7 skipping to change at page 22, line 16
configuration and thereafter at regular intervals at which the configuration and thereafter at regular intervals at which the
operator chooses to switch to a new set of secrets. In case 64 bits operator chooses to switch to a new set of secrets. In case 64 bits
are used for the data fields "CML" and "RND" which are carried within are used for the data fields "CML" and "RND" which are carried within
the data packet, the regular intervals are expected to be quite long the data packet, the regular intervals are expected to be quite long
(e.g., at 100 Gbps, a profile would only be used up after 3100 years) (e.g., at 100 Gbps, a profile would only be used up after 3100 years)
- see Section 4 above, thus even a "headless" operation without a - see Section 4 above, thus even a "headless" operation without a
Controller can be considered feasible. In such a case, the Controller can be considered feasible. In such a case, the
Controller would only be used for the initial configuration of the Controller would only be used for the initial configuration of the
POT-profiles. POT-profiles.
If OPOT (Section 3.5.2) is applied using symmetric masking, the
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 8.9. Verification Scope
The POT solution defined in this document verifies that a data-packet The POT solution defined in this document verifies that a data-packet
traversed or transited a specific set of nodes. From an algorithm traversed or transited a specific set of nodes. From an algorithm
perspective, a "node" is an abstract entity. It could be represented perspective, a "node" is an abstract entity. It could be represented
by one or multiple physical or virtual network devices, or is could by one or multiple physical or virtual network devices, or is could
be a component within a networking device or system. The latter be a component within a networking device or system. The latter
would be the case if a forwarding path within a device would need to would be the case if a forwarding path within a device would need to
be securely verified. be securely verified.
8.9.1. Node Ordering 8.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. In case the order in which a data data packet visited the nodes.
packet traversed a particular set of nodes needs to be verified as
well, alternate schemes that e.g., rely on "nested encryption" could In case the order in which a data packet traversed a particular set
to be considered. 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 8.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.
skipping to change at page 21, line 47 skipping to change at page 23, line 18
The authors would like to thank Eric Vyncke, Nalini Elkins, Srihari The authors would like to thank Eric Vyncke, Nalini Elkins, Srihari
Raghavan, Ranganathan T S, Karthik Babu Harichandra Babu, Akshaya Raghavan, Ranganathan T S, Karthik Babu Harichandra Babu, Akshaya
Nadahalli, Erik Nordmark, and Andrew Yourtchenko for the comments and Nadahalli, Erik Nordmark, and Andrew Yourtchenko for the comments and
advice. advice.
10. References 10. References
10.1. Normative References 10.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/
RFC2119, March 1997, <https://www.rfc-editor.org/info/
rfc2119>.
[RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function [RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function
Chaining (SFC) Architecture", RFC 7665, Chaining (SFC) Architecture", RFC 7665, DOI 10.17487/
DOI 10.17487/RFC7665, October 2015, <https://www.rfc- RFC7665, October 2015, <https://www.rfc-editor.org/info/
editor.org/info/rfc7665>. rfc7665>.
[SSS] "Shamir's Secret Sharing", <https://en.wikipedia.org/wiki/ [SSS] "Shamir's Secret Sharing", <https://en.wikipedia.org/wiki/
Shamir%27s_Secret_Sharing>. Shamir%27s_Secret_Sharing>.
10.2. Informative References 10.2. Informative References
[I-D.ietf-anima-autonomic-control-plane] [I-D.ietf-anima-autonomic-control-plane]
Behringer, M., Eckert, T., and S. Bjarnason, "An Autonomic Eckert, T., Behringer, M., and S. Bjarnason, "An Autonomic
Control Plane", draft-ietf-anima-autonomic-control- Control Plane (ACP)", draft-ietf-anima-autonomic-control-
plane-03 (work in progress), July 2016. plane-18 (work in progress), August 2018.
Authors' Addresses Authors' Addresses
Frank Brockners Frank Brockners
Cisco Systems, Inc. Cisco Systems, Inc.
Hansaallee 249, 3rd Floor Hansaallee 249, 3rd Floor
DUESSELDORF, NORDRHEIN-WESTFALEN 40549 DUESSELDORF, NORDRHEIN-WESTFALEN 40549
Germany Germany
Email: fbrockne@cisco.com Email: fbrockne@cisco.com
skipping to change at page 23, line 20 skipping to change at page 25, line 4
JP Morgan Chase JP Morgan Chase
25 Bank Street 25 Bank Street
London E14 5JP London E14 5JP
United Kingdom United Kingdom
Email: stephen.youell@jpmorgan.com Email: stephen.youell@jpmorgan.com
David Mozes David Mozes
Email: mosesster@gmail.com Email: mosesster@gmail.com
Tal Mizrahi Tal Mizrahi
Marvell Marvell
6 Hamada St. 6 Hamada St.
Yokneam 20692 Yokneam 20692
Israel Israel
Email: talmi@marvell.com Email: talmi@marvell.com
Alejandro Aguado
Universidad Politecnica de Madrid
Campus Montegancedo, Boadilla del Monte
Madrid 28660
Spain
Phone: +34 910 673 086
Email: a.aguadom@fi.upm.es
Diego R. Lopez
Telefonica I+D
Editor Jose Manuel Lara, 9 (1-B)
Seville 41013
Spain
Phone: +34 913 129 041
Email: diego.r.lopez@telefonica.com
 End of changes. 25 change blocks. 
53 lines changed or deleted 134 lines changed or added

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