proof of transit: securely verifying a path or service chain

Proof of Transit:Securely Verifying a Path or Service Chain

Frank Brockners, Shwetha Bhandari

© 2016 Cisco and/or its affiliates. All rights reserved. Cisco Public

Prolog

Consider TE, Service Chaining, Policy Based Routing, etc...:

“How do you prove that traffic follows the suggested path?”

2


“… Willis says the first issue is connecting VNFs to the infrastructure. OpenStack does this in a sequential manner, with the sequence serially numbered in the VNF, but the difficulty comes when trying to verify that the LAN has been connected to the correct LAN port, the WAN has been connected to the correct WAN port and so on. "If we get this wrong for a firewall function it could be the end of a CIO's career," says Willis.”

http://www.lightreading.com/nfv/nfv-specs-open-source/bt-threatens-to-ditch-openstack/d/d-id/718735October 14, 2015Light reading citing Peter Willis, Chief researcher for data networks, British Telecom

3

http://www.lightreading.com/nfv/nfv-specs-open-source/bt-threatens-to-ditch-openstack/d/d-id/718735

© 2016 Cisco and/or its affiliates. All rights reserved. Cisco Public 4

Implementationand DemoApproach The

MathProtocolAspects


Ensuring Service Chain and Path Integrity

Service A Service B Service C

In policy

Out of policy

Service Chain: A B C

5


Ensuring Service Chain and Path Integrity

Service A Service B Service C

vSwitch

In policy

Out of policy

Service Chain: A B C

6


Service Chain Integrity Validation: Approach• Add meta-data to all packets that traverse a path or

service chain

• The added meta-data allows a verifying node (egress node) to check whether a packet traversed the service chain correctly or not

• Security mechanisms are used on the meta-data to protect against incorrect or misuse (i.e. configuration mistakes, people playing tricks with routing, capturing, spoofing and replaying packets).

• The meta-data is secured through the use of keys. Service functions retrieve the keys from a controller over a secure channel.

Controller

verifier

7


Service Chain Integrity Validation Concept

8


Idea: Combine multiple secrets“Compose the Onion”• Approach

• A service is described by a set of secrets, where each secret is associated with a service function. Service functions encrypt portions of the meta-data as part of their packet processing.

• Only the verifying node has access to all secrets. The verifying nodes re-encrypts the meta-data to validate whether the packet correctly traversed the service chain.

• Notes • To be used only when hardware assisted encryption

is available. i.e. AES-NI instructions or equivalent. Otherwise this could be very costly operation to verify at line speed.

“S1”“S2”

“S3”

Service-Secrets are nested like layers of an onion

9


“Compose the Onion”

• Each packet is inserted with two additional fields RND (rand number) and SEQ (could be sequence or time stamp). An additional field VERIFY is initialized to NULL initially.

• Each time a packet passes through each service, then VERIFY = Enc(SEQ,K1) is XOR'ed with RND.

• When the packet passed through the second service, then VERIFY = VERIFY XOR Enc(SEQ,k2). This is done in such cumulative XOR until service n, i.e. VERIFY = VERIFY XOR Enc(SEQ,kn).

• Since the verifier knows all the keys, it could do the same as above (NOT decryption), i.e. VERIFY XOR Enc(SEQ, k1) XOR Enc(SEQ, k2) .....XOR Enc (SEQ, kn).

• The above would result in RND only when all the services give their respective encryption of SEQ else the packet could be flagged.

S1 S2 S3 S4 S5

10


Solution Approach: Leveraging Shamir’s Secret Sharing Polynomials 101

- Line: Min 2 points

- Parabola: Min 3 points

- Cubic function: Min 4 points

General: It takes k+1 points to defines a polynomial of degree k.

11


Solution Approach: Leveraging Shamir’s Secret SharingIdea Concept

(3,46)

(2,28)

(1,16)

“Secret”:

S1 S2 S3 Verifier

12


Solution Approach: Leveraging Shamir’s Secret Sharing• Outline :

• Each service is given a point on the curve • When the packet travels through each service it collects these points• A verifier can reconstruct the curve using the collected points• If there are k+1 services and k+1 points chosen, then the verifier can construct

k degree polynomial and verify. • The polynomial cannot be constructed if a few points are missed. Any lesser points

means few services are missed!

• Concern: Operationally complex to configure and recycle so many curves and their respective points for each service function

13


Solution Approach: Leveraging Shamir’s Secret SharingComplete Solution• Leverage two polynomials:

• POLY-1 secret, constant.Each service gets a point on POLY-1 at set up time and kept secret

• POLY-2 public, random and per packet.Each service generates a point on POLY-2 each time a packet crosses it.

• Each service function then calculates a (Point on POLY-1 + Point on POLY-2) to get a (Point on POLY-3) and passes it to verifier by adding it to each packet.

• The verifier constructs POLY-3 from the points given by all the services and cross checks whether POLY-3 = POLY-1 + POLY-2.• Here only the verifier knows POLY-1

• Operations are done in modulo prime

See http://wikicentral.cisco.com/display/PROJECT/Split+Verification+Examples for a detailed example

POLY-1Secret - Constant

POLY-2Public – Per Packet

+

=POLY-3

Secret – Per Packet

http://wikicentral.cisco.com/display/PROJECT/Split+Verification+Examples


Security Considerations• An attacker by passing few services, will miss adding a respective point on POLY-1 to

corresponding point on POLY-2 , thus the verifier cannot construct POLY-3 for cross verification

• An attacker watching values, doing differential analysis across service functions (i.e. as the packets entering and leaving), cannot construct a point on POLY-1 as the operations are done over a finite field (i.e. modulo prime).

• Replay attacks could be avoided by carefully choosing POLY-2. It could be a timestamp concatenated with a random string.

• The proofs of correctness and security are based on Shamir’s Secret Sharing Scheme .

15

http://en.wikipedia.org/wiki/Shamir's_Secret_Sharing


A peek at the math

16


Service Chain Verification using Shamir’s Secret Sharing Scheme

A single secret is associated with a particular service chain. Shares of the single secret are distributed from the controller to the service functions. Service functions use their share to update a cumulative value in the meta-data. Only a verifying node has access to the complete secret that it can use to validate the correctness of the received meta-data.

• A polynomial is the secret• Each point of the polynomial is called “share” of the secret. • Proof of correctness and security is per Shamir’s Secret Sharing Scheme. • Use finite field arithmetic over a field of size “prime number”

LagrangePolynomials

Shamir’sSecretSharingScheme

Primenumber

FiniteFieldArithmetic

17

http://en.wikipedia.org/wiki/Shamir's_Secret_Sharing


Example: The Secret – and its shares

(2,28)

(4,17)

(5,47)

18


Example: The Secret – and its shares

(2,28)

(4,17)

(5,47)

19


Let’s reconstruct the secret...

Let’s assume all we know is:

20


Calculating the Lagrange Basis Polynomials

21


Reconstructing The Secret

Const.

22


Lagrange coefficients

For a general way to compute the modular multiplicative inverse, see e.g. Euclidean algorithm

23

? ?

? ?

???

https://en.wikipedia.org/wiki/Euclidean_algorithm#Linear_Diophantine_equations


Reconstruction

Secret reconstruction can easily be performed interatively hop by hop

24


Operation

S1

S2

S3

Verifier

25


Making the solution operationally simple•

26


Polynomial 2

(2,46)

(4,21)

(5,12)

27


Combining the Polynomials

“Secret” and constant “Public” and per packet

“Secret” and per packet

28


Operation

S1

S2

S3

Verifier

provisioned retrieved from packet meta-data29


Protocol aspects

30


• 16* Bytes of Meta-Data for POT• Random – Unique random number

(e.g. Timestamp or combination of Timestamp and Sequence number)

• Cumulative (algorithm dependent)

• Transport options for different protocols• Segment Routing: New TLV in SRH header• Network Service Header: Type-2 Meta-Data• In-band OAM for IPv6:

Proof-of-transit extension header• VXLAN-GPE

Proof-of-transit embedded-telemetry header• ... more to be added (incl. IPv4)

Proof of Transit: Meta-Data Transport Options

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Random | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Random (contd) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Cumulative | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Cumulative (contd) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

*Note: Smaller numbers are feasible, but require a more frequent renewal of the polynomials/secrets.

2nd Polynomial

Interative computation of secret

31


Sizing the Meta-Data for SCV• Transfer

RateRND/SecretSize

Max # of packets(assuming 64 byte packets)

Time that RND lasts at maximum

1 Gbps 64

10 Gbps 64

100 Gbps 64

10 Gbps 56

10 Gbps 48

10 Gbps 40

1 Gbps 32 2200 seconds, 36 minutes

10 Gbps 32 220 seconds, 3.5 minutes

100 GBps 32 22 seconds

32


Meta-Data Provisioning• Meta-Data for Service Chain Verification

(POT) provisioned through a controller (OpenDaylight App)

• Netconf/YANG based protocol

• Provisioned information from Controller to Service Function / Verifier• Service-Chain-Identifier

(to be mapped to service chaining technology specific identifier by network element)

• Service count (number of services in the chain)• 2 x POT-key-set (even and odd set)

• Secret (in case of communication to the verifier)• Share of a secret, service index• 2nd polynomial coefficients• Prime number

Service Chain Verification App

S3 VerifierS2S1

POT-key-sets:Prime

secret sharepoly-2

POT-key-sets:Prime

secret sharepoly-2

POT-key-sets:Prime

secret sharepoly-2

POT-key-sets:SecretPrime

secret sharepoly-2

Verification request for a particular service chain


Implementation and Demo: Path Verification

34


Implementation• Dataplane (iOAM Header):

• Software Dataplane• VPP• IOS (ISR-G2)• IOSv/VIRL

• Results export• IPFIX, Kafka

• Hardware Dataplane: Doppler ASIC

• Controller• OpenDaylight

• SCV App (generic – for all types of service chains)

• Tracing Control App (for iOAM)

35


Introducing Vector Packet Processor - VPP• VPP is a rapid packet processing development

platform for highly performing network applications.

• It runs on commodity CPUs and leverages DPDK

• It creates a vector of packet indices and processes them using a directed graph of nodes – resulting in a highly performant solution.

• Runs as a Linux user-space application

• Ships as part of both embedded & server products, in volume; Active development since 2002

• Base iOAM code already available in fd.io open repositories (more coming soon)

• See also: FD.IO (The Fast Data Project)36

Network IO

Packet Processing: VPP

Management AgentNC/Y REST ...

Some initial iOAM already in FD.IO:https://gerrit.fd.io/r/gitweb?p=vpp.git;a=blob_plain;f=vnet/vnet/ip/ip6_hop_by_hop.c;hb=HEAD

https://fd.io/

https://fd.io/

https://gerrit.fd.io/r/gitweb?p=vpp.git;a=blob_plain;f=vnet/vnet/ip/ip6_hop_by_hop.c;hb=HEAD


iOAM in VPP

37

DPDK

eth-input

VPP

Ip6-input

Ip6-lookup

Ip6-hop-by-hop

Ip6-add-hop-by-

hop

Ip6-pop-hop-by-

hop

Ip6-rewrite

error-drop

int-output

Tengigabitethernet

Tengigabitethernet

Tengigabitethernet

Tengigabitethernet

Management Agent

dpdk-input

`

Packet Vector

AP

IiOAM data Collector

` `

Shared memory bus


Example Network: Setup

Service A

Service B

Service CVerifier

Node Z

Host 1

Host 3

Host 2

iOAM6 Domain

Service chain: Service A – Service B – Service C

Routing configured so that:• Traffic from Host1 is forwarded to Service

B as next hop• Traffic from Host2 is forwarded to Node Z

as next hop

VPP

VPP

VPP

VPP


Example Network: Components

Service A

Service B

Service CVerifier

Node Z

Host 1

Host 3

Host 2

iOAM6 Domain

VPP

VPP

VPP

VPP

Netflow Collector(pmacctd)Service Chain Verification App

Database(mysql)

iOAM6 GUI(NeXT based)

Netconf/YANG IPFIX

“OSS”(App or simulated by Postman)

Restconf/YANG


Create service chain with verificationRESTconf call to OpenDaylight – “OSS” simulated


RESTconf call to OpenDaylight“OSS” simulated by Postman


Rendered instructions for VPP nodes


SCV profiles configured on VPP


Example Network: Operation

Node Z

Host 1

Host 3

Host 2

Netflow Collector(pmacctd)

Database(mysql)

iOAM6 GUI(NeXT based)

Service A

Service B

Service CVerifier

SCV passes:packet is in policy

SCV fails:packet is out of policy

VPP

VPP

VPP

VPP


Verification Counters


IPFIX Data Export


Verification Counters: GUI


Host 1

Host 3

Host 2

Triggered iOAMException Triggers additional OAM features to be enabled

Service A

Service B

Service C / Verifier

Control & Analytics

1. Configure SCV1. Configure SCV

4. Configure iOAM6 path tracing for packets that look like packet “x”

(recording node and incoming/outgoing

interface information)

3. Verifier sends trigger/notification to controller with information

about failure condition (i.e. details of failed packet “x”)

Node Z

2. SCV fails:packet “x” out of policy

1. Continuous monitoring - Service chain validation

PaNDA

49


Host 1

Host 3

Host 2

Triggered iOAMNext failure shows detailed flow info to controller

Service A

Service B

Service C / Verifier

3. Verifier sends trigger/notification to controller with information

about failure condition (i.e. details of failed packet “x”)

4. Verifier sends notification with packet trace data for packet:Path info is (A-Z-C).

Node Z

5. Visualization of the path of the packets which

failed verification.

2. SCV fails:packet out of policy

1 . Continuous monitoring - Service chain validation

Control & AnalyticsPaNDA

50


Summary

51


Summary• Consider TE, Service Chaining, Policy Based Routing, etc...:

“Now you can prove that traffic follows the suggested path”

• Approach• Shamir’s Secret Sharing Scheme applied

• Implementation• Dataplane: VPP, IOS (as proof of concept)• Controller: OpenDaylight

52


More Information• Proof of Transit Internet Draft:

https://tools.ietf.org/html/draft-brockners-inband-oam-transport-01

• Supporting Information on In-Band OAM and POT on Github(scripts to generate secrets etc.):https://github.com/CiscoDevNet/iOAM

• FD.io/VPP Implementation:https://docs.fd.io/vpp/16.12/plugins_ioam-plugin_ioam_lib-pot.html

• IOS Implementation:http://www.cisco.com/c/en/us/td/docs/ios-xml/ios/ipv6_nman/configuration/15-mt/ip6n-15-mt-book/ioam-ipv6.html

53




https://github.com/CiscoDevNet/iOAM

https://github.com/CiscoDevNet/iOAM

https://docs.fd.io/vpp/16.12/plugins_ioam-plugin_ioam_lib-pot.html

https://docs.fd.io/vpp/16.12/plugins_ioam-plugin_ioam_lib-pot.html

http://www.cisco.com/c/en/us/td/docs/ios-xml/ios/ipv6_nman/configuration/15-mt/ip6n-15-mt-book/ioam-ipv6.html

