Verifying and enforcing network paths with ICING Jad Naous , Michael - - PowerPoint PPT Presentation

▶
verifying and enforcing network paths with icing
SMART_READER_LITE
LIVE PREVIEW

Verifying and enforcing network paths with ICING Jad Naous , Michael - - PowerPoint PPT Presentation

Jul 06, 2023 197 likes •582 views

Verifying and enforcing network paths with ICING Jad Naous , Michael Walfish, Antonio Nicolosi, David Mazires, Michael Miller, and Arun Seehra 1 Today: New protocol for every feature Remote VPN, Private WANs, Specifying QoS, Firewalls,

slide-1
SLIDE 1

Verifying and enforcing network paths with ICING

Jad Naous, Michael Walfish, Antonio Nicolosi, David Mazières, Michael Miller, and Arun Seehra

1

slide-2
SLIDE 2

Today: New protocol for every feature

  • Remote VPN, Private WANs, Specifying QoS,

Firewalls, Filters, DoS protection, ACLs, Secure routing, …

  • Tomorrow: security outsourcing, access

delegation, better DoS protection, source routing?

2

slide-3
SLIDE 3

Today: New protocol for every feature

  • Remote VPN, Private WANs, Specifying QoS,

Firewalls, Filters, DoS protection, ACLs, Secure routing, …

  • Tomorrow: security outsourcing, access

delegation, better DoS protection, source routing?

3

Complexity, Incompatibility, Ossification

slide-4
SLIDE 4

Example: enterprise outsourcing deep-packet inspection

4

Anonymous A Destination D Middlebox M Provider P Employee E

Packets from Internet go through M Packets from employees don’t

slide-5
SLIDE 5

Example: service provider verifies business relationship

5

Anonymous A Destination D Middlebox M Provider P Employee E

Only check packets from customers

slide-6
SLIDE 6

One primitive to rule them all?

Path Consent:

Every entity on the path (or a delegate) has to approve the whole path.

Path Verification:

Upon receiving a packet, every entity on the path can verify that the packet has followed an approved path

Difficult Challenge

6

slide-7
SLIDE 7

Path Consent and Path Verification in action

7

Anonymous A Destination D Middlebox M Provider P Employee E

Approve paths according to policies Drop packets with unapproved paths Approve paths according to policies Drop packets with unapproved paths

slide-8
SLIDE 8

Why are Path Consent and Path verification sufficient?

Other protocols give one entity more control

  • ver the other entities on the path.

8

slide-9
SLIDE 9

What are the guarantees?

  • Granularity: Domain level guarantees.
  • Role of honest nodes: Honest nodes drop

non-compliant packets.

  • No skipping: Cannot skip an uncompromised

honest hop, even with collusion.

  • No negative policies: Cannot prove a packet

did not pass through a certain entity.

  • Does not prove trustworthiness: “Trusted”

does not mean “Trustworthy”.

9

slide-10
SLIDE 10

This talk will answer

  • How can we provide Path Consent and Path

verification?

  • At what cost?

10

slide-11
SLIDE 11

Outline

  • Design in three iterations
  • Prototype implementation and results
  • Related work and conclusion

11

slide-12
SLIDE 12

Operational constraints

Adversarial Decentralized High performance

12

slide-13
SLIDE 13

Consent Server 3

Architecture: Control plane/Data plane split

Consent Server 1 Consent Server 2 Sender R3 R1 R2

13

slide-14
SLIDE 14

Communication starts by contacting consent servers

Consent Server

Sender

14

Ri

Path= <…, Ri, …> Proofi

Payload

ICING Header: Path = <Sender, R1, R2, R3> Verif = <V1, V2, V3>

slide-15
SLIDE 15

15

Payload

ICING Header: Path = <Sender, R1, R2, R3> Verif = <V1, V2, V3>

Forwarder

Forwarder uses its verifier to implement Path Verification

slide-16
SLIDE 16

Strawman 1: Public key crypto

Name entities by self-minted public keys (PK/SK) Use signatures for Path Consent and Path Verification

16

slide-17
SLIDE 17

Operational constraints

Adversarial Decentralized High performance

17

slide-18
SLIDE 18

Strawman 2: Symmetric Key Crypto

R = number of realms on Internet n = number of realms on a path O(R) symmetric keys for configuration O(n2) overhead in the packet

18

1 PK/SK 1 Sig R pair-wise shared keys n MACs

slide-19
SLIDE 19

Strawman 2: Sender inserts proofs of consent in the packet

19

Path Verifiers R0 R1 R2 R3 Proofs

Created using symmetric shared keys between consent server forwarder. Uses R1’s consent key s1 Uses R2’s consent key s2 Uses R3’s consent key s3

slide-20
SLIDE 20

Strawman 2: Sender proves to later realms it has passed the packet using O(R) preconfigured keys

20

Path Verifiers R0 R1 R2 R3 Proofs

Uses k01 shared between R0, R1 Uses k02 shared between R0, R2 Uses k03 shared between R0, R3

slide-21
SLIDE 21

Strawman 2: Forwarders use O(R) symmetric keys for verification

21

Path Verifiers R0 R1 R2 R3

R1

Proofs

Consent server, R1: s1 R0, R1: k01

slide-22
SLIDE 22

Strawman 2: Forwarder adds proof for later realms

22

R1, R2: k12 R1, R3: k13

Path Verifiers R0 R1 R2 R3

R1

Proofs Path Verifiers R0 R1 R2 R3 Proofs

slide-23
SLIDE 23

Operational constraints

Adversarial Decentralized High performance

23

slide-24
SLIDE 24

ICING: Decrease overhead by XORing MACs and Proofs

24

Path Verifiers R0 R1 R2 R3 Proofs Path PK0 PK1 PK2 PK3 Verifiers

XOR

slide-25
SLIDE 25

ICING: public keys as names and pairwise keys non-interactive key exchange

25

Uses s2: consent server, R2

R2

Path PK0 PK1 PK2 PK3 Verifiers

Uses k02 = KEY-EXCH(SK0, PK2) = KEY-EXCH(SK2, PK0) Uses k12 = KEY-EXCH(SK1, PK2) = KEY-EXCH(SK2, PK1)

Path PK0 PK1 PK2 PK3 Verifiers

Uses k23 = KEY-EXCH(SK2, PK3) = KEY-EXCH(SK3, PK2)

slide-26
SLIDE 26

Missing functionality: Realm-specific services and delegation

  • Indicate entity-specific meaning: QoS, billing,

DPI, etc.

  • Delegate ability to create proofs

26

slide-27
SLIDE 27

Extend hop specification with tag

  • Path

<(PK1, tag1), (PK2, tag2), …, (PKn, tagn)>

  • Each (PK, tag) has a unique consent key (si)
  • Keys generated from master keys, can be

delegated by prefix.

27

slide-28
SLIDE 28

Outline

  • Design in three iterations
  • Prototype implementation and results
  • Related work and conclusion

28

slide-29
SLIDE 29

Hardware implementation uses three main pipeline stages

29

Hash (CHI) Pair-wise Key Lookup PMAC CBC-MAC Consent Key Lookup

tag path payload

+ =

verifiers Drop

  • r

Forward path

+

New Verifiers

slide-30
SLIDE 30

Slow path in software does key exchange

30

Calculate Shared Keys Packet missing keys Insert calculated keys into cache Software Hardware

slide-31
SLIDE 31

Evaluation questions

  • What is throughput of the forwarder? Can it

handle whatever packets are thrown at it?

– Bottleneck at the hash function

  • What is the hardware cost of an ICING

forwarder?

  • How much packet overhead does ICING add?

31

slide-32
SLIDE 32

Throughput: Connect all forwarder ports to NetFPGA packet generators

32

ICING Forwarder NetFPGA Packet Generator NetFPGA Packet Generator 2Gbps 2Gbps R? R?

slide-33
SLIDE 33

Throughput vs. Payload Size (Path Length=7)

33

100% 50% 0% 500 1000 1500 2000 2500 3000 3500 4000 500 1000

Payload Size (bytes) Throughput (Mbps)

slide-34
SLIDE 34

Hardware Cost

  • Measure cost as equivalent gate count

generated by Xilinx ISE 10.1i

  • Our implementation costs 54% more than

NetFPGA IP router and is 20% slower.

  • Normalized cost (for the same throughput) is

93% more than NetFPGA IP router.

34

slide-35
SLIDE 35

Packet overhead increase: Estimate from backbone trace

  • 15-minute trace from Trans-Pacific 150Mbps

line

  • Assuming average path length of 5
  • ICING would add < 25% more overhead
  • 187.5Mbps ICING line = 150Mbps IP line

35

slide-36
SLIDE 36

Outline

  • Design in three iterations
  • Prototype implementation and results
  • Related work and conclusion

36

slide-37
SLIDE 37

Selected related work

  • Enriching control and policy:

– [Calvert et al, Broadnets ‘07] PoMo – [Popa et al, OSDI ‘10] RBF – [Yang et al, ACM/IEEE Trans. on networking ‘04] NIRA

  • Related mechanisms:

– [Liu et al, NSDI ‘08] Passport – [Andersen et al, SIGCOMM ‘08] AIP – [Raghavan and Snoeren, SIGCOMM ‘04] Platypus

37

slide-38
SLIDE 38

Conclusion

Single primitive with two simple properties can provide functions of many other protocols. Solving hard problems using scalable per-packet cryptography Line-rate enforcement and verification at an additional hardware cost of 93% and <25% average packet overhead

38