Page Comparison

Usecase:

Validate that all nodes in a slice forward traffic along the correct path.

Background:

A problem in networks and distributed systems concerned with security are related to malicious nodes behaving in ways to subvert traffic flows, either encrypted or not.  A common path attack seen in the wild uses bgp hijacks to force traffic through an adversarial entity.  Most path validation techniques require an entire path to be known to all participants on the path.  The approach that Sabres implements, uses Non Interactive Zero Knowledge (NIZK) proofs and nexthop neighbors to prohibit path leak while still validating the entire path.

The paper is currently under submission.

Algorithm:

Each node in the path (slice), will receive keying material from a centralized service (slice orchestrator).  The key material is used to then provide a secure channel with which to send NIZK proofs, validations, and unique identifiers for each node.

The path validation process begins with each node (lets call it i ) communicating with its successor node in the path (i+1 ).  The successor node computes a proof with the identifiers for i and i+1 .  The proof is then sent to the predecessor ( i-1 ) to verify the proof. The proof is then sent back to the slice orchestrator, to validate that all proofs are correct and therefore the path is valid.

Integration:

There are two portions of code that will exist for ONAP.  The first is the orchestrator code, which will live in DCAEGEN2 services (https://gerrit.onap.org/r/admin/repos/dcaegen2/collectors) either as a collector or platform.  The other portion of code will live on the nodes in the slice, or the VNFs in the context of ONAP.

Server

We believe the server code will live in the DCAEGEN2's service repository.  The code will handle:

1. SSL Keying material to create a secure channel
2. Unique ID/Secret generation securely
3. Distribution of Secrets to each VNF in the Slice
4. Distribution of Path neighbors (i-1, i+1) to each VNF (i)
5. Retrieval of Proof Verifications
6. Communication with some ONAP feedback mechanism to alert of success or failure of path validation in a slice.  On failure, presumably, the slice must be recreated as it can no longer be trusted.

Client

We are unsure of where the client code will live in ONAP.  We suspect that somehow it will be integrated with VNFSDK (https://docs.onap.org/projects/onap-vnfsdk-model/en/latest/files/pkgtool.html), but we are unsure about how the vnfsdk code (e.g., ves-agent) is deployed onto the VM/VNF.

1. Receives SSL key material from server
2. Receives ID/Secret and Neighbors from server
3. Sends its ID to successor i+1 , who then runs NIZK code to generate proof based on i,i+1
4. Receives Proof from i+1 , Sends to i-1 . Who then runs NIZK to validate proof
5. Sends validate proof to server