]>
Vector Commitmentbased Proof of Transit
Huawei
China
liuchunchi@huawei.com
Proof of Transit
Inclusion Proof
This document describes an ordered Proof of Transit mechanism.
Introduction
Proof of Transit (POT) is a secure log or evidence that proves traffic transited certain elements of a network path, in a specified order. The "elements" could be either virtual network functions or physical network devices, per the definition of .
POT mechanism can be used to prove the actual forwarding of a packet follows a predetermined path, in order to satisfy certain compliance or performance requirements. As a result, POT is important for several technologies that explicitly appoints traffic path, such as Service Function Chaining (SFC), Segment Routing (SR), Traffic Engineering (TE), etc it can help prove a packet's forwarding compliance to a path, or at least, confirm its deviation. Other use cases are discussed in .
POT is a critical building block for routing security assurance, but a secure yet efficient POT mechanism is still under standardization. presented a Shamir Secret Sharingbased POT solution, but has not become a proposed standard until now.
This document describes a secure, efficient ordered Proof of Transit mechanism using a cryptographic primitive called Vector Commitment. We select efficient cryptographic constructions of Vector Commitment, which is KZG polynomial commitment, for high computation efficiency and succinct proof size. We also define the efficiency benchmark and security definitions of Proof of Transit mechanisms. Since we believe ordercompliance is a must, we omit "ordered" from now.
Terminology
The terminology and definition of key concepts in this document, such as path, node and link was defined in . Others:

POT: Proof of Transit

VC: Vector Commitment

KZG: Kate, Zaverucha and Goldberg Polynomial Commitment

SFC: Service Function Chaining

SR: Segment Routing
Background
The absence of a secure POT mechanism (along with lack of control to Internet devices) causes a gap between routing integrity and forwarding integrity. This means the routing information could be propagated correctly (with efforts like BGPSEC), but it is each router who makes the actual forwarding decision, which can be negatively affected by faulty configurations or malicious attacks . POT mechanisms, if designed secure and efficient enough, can be a trustworthy mark or evidence reflecting the actual path a packet has taken in the forwarding plane.
Basic Idea
The proposed method uses Vector Commitment (VC). A regular cryptographic Commitment scheme allows Alice to commit to a single secret value and reveal it later; while a Vector Commitment scheme allows Alice to commit to a vector of secrets, and reveal it onebyone or all at once. This allows our solutions to do the following:
For a network controller, she can orchestrate a routing path, where each value represents a network element's identity (or attributes), and the vector represents the whole path. She can compute a ciphertextlike commitment C that reflects the full vector information, in this way committing to this path, and this path only. Also, no adversary can interpret any information about the values just by observing the commitment C. These are the binding and hiding properties provided by the original cryptographic VC primitive. Detailed security analysis are provided in the Security Considerations. Also the commitment C is always constant size regardless of the length of the path or information committed.
For a network element, he can compute an opening proof for himself, functions as a proofoftransit, which proves who he is, the path he is on, his index on this path, all at the same time. The opening proof p_i is also always constant size and is aggregateable with other opening proofs p_J.
For any public verifier, he can verify the opening proof p_i against commitment C. Only when the threetuple information of opening proof p_i aligns with controller's threetuple information of commitment C, will the transit proof p_i pass verification against commitment C. The verifier does not need any preshared secrets or auxiliary data, meaning the verification is stateless. The verification time is also constant time.
Vector Commitment has many low level constructions obviously Merkle Tree is one of many possible constructions. But the advantage of our proposed solution is the efficiency of the lowlevel construction we use KZG Polynomial Commitment. By comparison, when verifying an opening proof p_i, we only need constant O(1) size of p_i and commitment C as compared with O(logN) size of auxiliary data in Merkle Trees. The opening proof p_i can also be directly verified against commitment C, requiring O(1) constant verification time as compared with O(logN) computation in Merkle Trees. The number N is the total number of committed elements (and its information) in a vector. Such efficiency advantage is critical when assessing the usability to apply advanced crypto to the routing area.
Solution
Algorithm
We avoid cryptographic deepdive. Consider VC as a blackbox with the following functions:

Setup: On input a security parameter k, generate a set of public parameters pp for following functions.

Commit: On input parameter pp, a vector V=(v_1, v_2, ..., v_N), output a commitment value C to the vector V.

Open: On input parameter pp, element i's identity information and auxiliary information, output an opening proof p_i.

Verify: On input parameter pp, commitment C, opening proof p_i and i's identity information, output either pass or fail.
This abstraction is given in this SoK The function Commit is used by network controllers to orchestrate a network path. The function Open is used by a network element to compute a transit proof. The function Verify is used by a public verifier to verify a transit proof.
Approach
In our approach, there is one network controller (Alice) and many network elements. We use controller and elements from now on.
Setup

Controller chooses a pairingfriendly curve to use. She uses a unique ciphersuite identifier to represent the selection. Reference ciphersuite format of pairingfriendly curve is defined in Section 7.1 .

Controller chooses maximum number of element t in the vector. Here t is the maximum number of elements N on the path.

Controller chooses a random positive integer secret a.

Controller computes a t+1 tuple public parameter pp=(g, g^a, g^a+1, ..., g^a^t), where g is the group generator of the selected curve, part of public parameters of the curve.
Commit to a Path
The Commit function introduced above is a high level abstraction. In KZG's actual construction, in the Commit step, there is another step of conversion from the vector V to an interpolated polynomial phi(x). The commitment, opening and verification all requires this polynomial phi(x).

Controller decides a routing path V=(v_1, v_2, ..., v_N), where v_i is the unique identifier (or the profile containing list of attributes) of the network element i.

Controller transform the vector V into N number of twodimensional points (x_i, y_i), where x_i equals integer 1,2,3... and y_i equals the hash of v_i, y_i=hash(v_i).

Controller uses Lagrange interpolation to compute a polynomial phi(x) using above N twodimensional points (x_i, y_i). The polynomial phi(x) is represented by the coefficients of it.

Given polynomial phi(x) and public parameters pp, controller computes a commitment C using the Commit() from KZG mechanism.
Since the polynomial phi(x) is needed when computing any opening proof, if x_i is 1,2,3... then all participating network elements would have access to any (i, v_i) pair, hence trust among the network elements are required. To achieve transit proof unforgeability, the securityenhanced step 2 is:

[*] Controller randomly generates a secret s_i and share with the element i through a private secure channel. x_i=s_i, y_i=hash(v_is_i).
and the rest remains same.
Configure

Controller sends the following data to each network element: ciphersuite (curve, hash function), public parameter pp, polynomial phi(x).

Controller broadcasts public parameter pp and commitment C for any public verifier (could be an external verifier or also any participating network element).
For enhanced security option:
1. [*] Controller sends the following data to each network element i: ciphersuite (curve, hash function), public parameter pp, polynomial phi(x), and secret s_i.
Create Transit Proof

Upon receiving a request to compute a transit proof, the network element i compute an opening proof p_i using Open(), with input of his (x_i, y_i), polynomial phi(x) and public parameter pp.

Network element i attaches p_i to the packet header, or send them outofband.
Because the verification of p_i requires also (x_i, y_i), for normal procedures, (x_i, y_i) is public information and does not require sending. For enhanced security option, since x_i and y_i is secret, do the following:

[*] Network element i attaches p_i and (x_i, y_i) to the packet header, or send them outofband.
Verify Transit Proof

The verifier takes public parameter pp, commitment C, index x_i, element's identity y_i, opening proof p_i, uses Verify() to accept or reject a transit proof. If the p_i is sent outofband, then the verifier is the external party. If p_i is attached to the packet payload or header, the following network element can also be verifiers.
Sizing the Data for VCPOT
The major data in our proposed solution is the Commitment C and transit proof p_i, which represents pathlevel information and individuallevel information. We compare the size of Commitment C and transit proof p_i. C and p_i is a group element of G1, where e: G1 x G1 > GT is a symmetric (type 1) bilinear pairing. As a result, it is relevant to different pairingfriendly curves we use:
Data sizes in Bytes
Curve 
Public Parameters pp 
Commitment C 
Transit Proof p_i 
Has Implementation 
BLS12381 
(N+1)*48 
48 
48 
Y 
BLS48 
(N+1)*36 
36 
36 
N 
BW19P286 
(N+1)*36 
36 
36 
N 
KZG polynomial commitment utilizes pairingfriendly curves. Common implementations uses BLS12381 elliptic curves defined in Section 4.2.1 of . With a field modulus q of 381 bits in length, we receive 126bits of security (close enough to 128 bits). To achieve same bits of security, BNcurves requires 462 bits and increases overhead so we don't use them.
The reason why size of field modulus is important is because it is the exact size of a group element in G1, therefore both the size of a commitment and opening proof to be attached to the packet header and transmitted. Although BLS12381 is the most popular curve, there are also curves with a smaller 286bit G1 BW19P286 and BLS48 . They decrease the packet overhead from 48B to 36B.
A complete YANG model is TBD.
Running Implementation
A working ProofofConcept demo implementation is published here:
Runnable in MacOS environment.
Security Considerations
Biding and Hiding
The hiding and binding property is offered by the original KZG Polynomial Commitment cryptographic scheme, not by our design. Informally:
The commitment C is cryptographically hiding, meaning without x_i and polynomial phi(x), simply by observing commitment C, no adversary can interpret y_i hence compute an opening proof p_i.
The commitment C is cryptographically binding, meaning computing an opening proof using any (x_i, y'_i) different than (x_i, y_i) cannot pass verification against commitment C.
For complete cryptographic details, please refer to the original paper .
Unforgeability of Transit Proof
A transit proof p_i should be unforgeable.
With the cryptographic hiding property, for our normal option, no malicious adversary outside of participating network elements can forge a transit proof. But this requires a security assumption of trusting the network elements being benign.
The enhanced security option eliminates this trust assumption. With (x_i, y_i) being secret plus the hiding property, no adversary can guess (x_i, y_i) and forge a p_i before element i's revelation. This means even a participating element j is malicious, it still cannot forge the transit proof of element i.
Need Trusted Setup (A Centralized Controller)
The Setup step requires a centralized trusted authority to generate and distribute the public parameters. This is not very problematic since a network controller that orchestrates a path can (and also should) serve as a setup center.
Nomods, Nosweat
The POT approach described in this document did not make modifications to the KZG polynomial commitment itself we are merely using it. Therefore, the approach does not introduce additional potential security vulnerabilities compared to the original scheme.
No PostQuantum Resistance
The approach described in this document uses bilinear pairing, which assumes (Elliptic Curve) Discrete Log Problem (DL) is hard. This also means this approach is not quantumresistant. We have two arguments for that:

If PQsafe is a must, latticebased or hashbased VC is also available. For instance, Fast ReedSolomon Interactive Oracle Proof (FRI) is another alternative vector commitment construction to KZG. FRI commitment is constructed using merkle trees and is hence quantum resistant, but the proof size is much bigger, slower to verify, dependent to the number of elements in the vector (both O(log\^2N)).

Considering general elliptic curve cryptography is still in wide use, it is fair to say forging a transit proof is less severe than forging an ECDSA signature to Bitcoin.
Other Possible Constructions
Vector Commitment can be seen as a special type of Cryptographic Accumulators, which can prove the membership of one or many elements in a set, by computing an inclusion proof. What is special about VC is it can also prove the order/position of the element inside the set. In use cases where the order is not important, or cryptographic capability is limited, other simplified Cryptographic Accumulators can be used to construct POT mechanisms, such as simple Merkle Tree, aggregate signatures.
IANA Considerations
This document has no IANA actions.
Informative References
A Vocabulary of Path Properties
Path properties express information about paths across a network and the services provided via such paths. In a pathaware network, path properties may be fully or partially available to entities such as endpoints. This document defines and categorizes path properties. Furthermore, the document identifies several path properties that might be useful to endpoints or other entities, e.g., for selecting between paths or for invoking some of the provided services. This document is a product of the Path Aware Networking Research Group (PANRG).
Proof of Transit
Cisco Systems, Inc.
Thoughtspot
Huawei Network.IO Innovation Lab
Seconize
JP Morgan Chase
Several technologies such as Traffic Engineering (TE), Service
Function Chaining (SFC), and policy based routing are used to steer
traffic through a specific, userdefined path. This document defines
mechanisms to securely prove that traffic transited a defined path.
These mechanisms allow to securely verify whether, within a given
path, all packets traversed all the nodes that they are supposed to
visit. This document specifies a data model to enable these
mechanisms using YANG.
Path Validation Problem Statement, History, Gap Analysis and Use Cases
Huawei
Huawei
Huawei
This document provides a problem statement, history revisiting, gap
analysis and use cases for path validation techniques.
PairingFriendly Curves
GMO Cybersecurity by Ierae, Inc.
NTT
NTT
Stanford University
Pairingbased cryptography, a subfield of elliptic curve
cryptography, has received attention due to its flexible and
practical functionality. Pairings are special maps defined using
elliptic curves and it can be applied to construct several
cryptographic protocols such as identitybased encryption, attribute
based encryption, and so on. At CRYPTO 2016, Kim and Barbulescu
proposed an efficient number field sieve algorithm named exTNFS for
the discrete logarithm problem in a finite field. Several types of
pairingfriendly curves such as BarretoNaehrig curves are affected
by the attack. In particular, a BarretoNaehrig curve with a 254bit
characteristic was adopted by a lot of cryptographic libraries as a
parameter of 128bit security, however, it ensures no more than the
100bit security level due to the effect of the attack. In this
memo, we list the security levels of certain pairingfriendly curves,
and motivate our choices of curves. First, we summarize the adoption
status of pairingfriendly curves in standards, libraries and
applications, and classify them in the 128bit, 192bit, and 256bit
security levels. Then, from the viewpoints of "security" and "widely
used", we select the recommended pairingfriendly curves considering
exTNFS.
Opinion":" Is secured routing a market failure?
ConstantSize Commitments to Polynomials and Their Applications
n.d.
Go implementation of KZG proofs
n.d.
RUST implementation of KZG proofs
n.d.
PAIRINGFRIENDLY CURVES, Aurore Guillevic
n.d.