The
IETF (Internet Engineering Task Force)
proposes to implement the Proof of Transit (PoT) - a “travel log” for network packets. More information about the initiative and the principles of PoT - under the cut.
/ Flickr / JonoTakesPhotos / CCWhy was needed Proof of Transit
According
to Cisco experts, Comcast and JP Morgan Chase virtualization does not allow to fully ensure that network packets have not been replaced or modified. This need may be justified, for example, by the organization’s internal policies or the requirements of the regulator.
Now this problem can be solved indirectly, but according
to the authors of the initiative, the evolution of networks and the emergence of technologies such as
NFV ,
LISP and
NSH make this process much more complicated. Therefore, a new approach called Proof of Transit was proposed. It is assumed that it allows you to keep something like a story or a log of a packet passing along a given route.
How does the proposed approach work?
The solution
presented in the document is based on adding a small amount of data to each packet. This data is used to compile the history and validate the path. Parameters of mandatory nodes are described using secret keys or
a secret sharing scheme .
Each node uses its own key or share secret to update the PoT data of the packets. When the verifier receives a packet, it authenticates the path.
/ Flickr / Ryan H. / CCTo ensure the safety of this approach, experts suggest using
Shamir’s secret sharing scheme at the stage of generating PoT data. To put it in simple terms, the principle of operation of this method of protection lies in the step-by-step division of the secret into conditional “coordinates” of points (nodes), followed by the subsequent interpolation of a given curve (packet path) - the calculation of the Lagrange interpolation polynomial.
The nodes use their secret shares to update the POT data of each packet, and the verification of the POT data correctness is done by constructing a curve. If one of the points is omitted or replaced, it will be impossible to construct a polynomial. This will mean that the package did not pass the specified path.
To enhance security, the authors propose to use 2 polynomials: POLY-1 (secret and permanent) and POLY-2 (public, arbitrary, and individual for each package). The algorithm is as follows: each node receives the secret value of a point on the POLY-1 curve. After that, the node generates a point on the POLY-2 curve, whenever a packet passes through it. Then each node adds the value of a point on the POLY-1 curve to a point on POLY-2 in order to get a point on POLY-3 and pass it to the verifying node along with the packet. At the end of the path, the verifier builds a POLY-3 curve on the basis of the obtained data and checks the compliance of POLY-3 = POLY-1 + POLY-2 (only the verifier knows the parameters of the POLY-1 polynomial).
/ Flickr / Culture Vannin / CCPoT Criticism
In the comments on The Register, the audience of the site
notes a number of imperfections of the proposed approach. Someone, for example, fears that the implementation of the idea will lead to the fact that the "weight" of the UDP packet will increase significantly, and PoT will not be able to get along with IPSec. In addition, it is not entirely clear how the PoT will work in the event of a failure on one of the specified nodes. It turns out that in the PoT-data will need to lay alternative routes. IETF hasn’t yet explained what to do in such cases.
Future document
It should be noted that the draft initiative is at the stage of discussion and finalization, and so far nothing is claimed. Within six months (until December 2, 2018), the IETF may change, replace, or declare it obsolete.
What you can read in the corporate blog on the VAS Experts website: