Verifying and enforcing network paths with ICING Jad Naous , Michael Walfish, Antonio Nicolosi, David Mazières, Michael Miller, and Arun Seehra 1
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
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? Complexity, Incompatibility, Ossification 3
Example: enterprise outsourcing deep-packet inspection Anonymous Middlebox Provider Destination A M P D Employee Packets from Internet go through M E Packets from employees don’t 4
Example: service provider verifies business relationship Anonymous Middlebox Provider Destination A M P D Employee E Only check packets from customers 5
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
Path Consent and Path Verification in action Anonymous Middlebox Provider Destination A M P D Employee Approve paths according to policies Approve paths according to policies E Drop packets with unapproved paths Drop packets with unapproved paths 7
Why are Path Consent and Path verification sufficient? Other protocols give one entity more control over the other entities on the path. 8
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
This talk will answer • How can we provide Path Consent and Path verification? • At what cost? 10
Outline • Design in three iterations • Prototype implementation and results • Related work and conclusion 11
Operational constraints Adversarial Decentralized High performance 12
Architecture: Control plane/Data plane split Consent Consent Consent Server 1 Server 2 Server 3 Sender R 1 R 2 R 3 13
Communication starts by contacting consent servers R i Path= <…, R i , …> Consent Server Proof i Sender ICING Header: Path = <Sender, R1, R2, R3> Payload Verif = < V1 , V2 , V3 > 14
Forwarder uses its verifier to implement Path Verification Forwarder ICING Header: Path = <Sender, R1, R2, R3> Payload Verif = <V1, V2, V3> 15
Strawman 1: Public key crypto Name entities by self-minted public keys (PK/SK) Use signatures for Path Consent and Path Verification 16
Operational constraints Adversarial Decentralized High performance 17
Strawman 2: Symmetric Key Crypto 1 PK/SK R pair-wise shared keys 1 Sig n MACs R = number of realms on Internet n = number of realms on a path O(R) symmetric keys for configuration O(n 2 ) overhead in the packet 18
Strawman 2: Sender inserts proofs of consent in the packet Created using symmetric shared keys between consent server Path Proofs Verifiers forwarder. R0 Uses R1’s consent key s 1 R1 Uses R2’s consent key s 2 R2 Uses R3’s consent key s 3 R3 19
Strawman 2: Sender proves to later realms it has passed the packet using O(R) preconfigured keys Path Proofs Verifiers R0 Uses k 01 shared between R0, R1 R1 Uses k 02 shared between R0, R2 R2 Uses k 03 shared between R0, R3 R3 20
Strawman 2: Forwarders use O(R) symmetric keys for verification Path Proofs Verifiers R0 R1 R1 R2 Consent server, R1: s 1 R3 R0, R1: k 01 21
Strawman 2: Forwarder adds proof for later realms Path Proofs Verifiers Path Proofs Verifiers R0 R0 R1 R1 R1 R2 R2 R1, R2: k 12 R3 R3 R1, R3: k 13 22
Operational constraints Adversarial Decentralized High performance 23
ICING: Decrease overhead by XORing MACs and Proofs Path Proofs Verifiers Path Verifiers R0 PK0 XOR R1 PK1 R2 PK2 R3 PK3 24
ICING: public keys as names and pairwise keys non-interactive key exchange Path Verifiers Path Verifiers PK0 PK0 R2 PK1 PK1 PK2 PK2 PK3 PK3 Uses s 2 : consent server, R2 Uses k 02 = KEY-EXCH(SK0, PK2) = KEY-EXCH(SK2, PK0) Uses k 12 = KEY-EXCH(SK1, PK2) = KEY-EXCH(SK2, PK1) Uses k 23 = KEY-EXCH(SK2, PK3) = KEY-EXCH(SK3, PK2) 25
Missing functionality: Realm-specific services and delegation • Indicate entity-specific meaning: QoS, billing, DPI, etc. • Delegate ability to create proofs 26
Extend hop specification with tag • Path <(PK 1 , tag 1 ), (PK 2 , tag 2 ), …, ( PK n , tag n )> • Each (PK, tag) has a unique consent key (s i ) • Keys generated from master keys, can be delegated by prefix. 27
Outline • Design in three iterations • Prototype implementation and results • Related work and conclusion 28
Hardware implementation uses three main pipeline stages path verifiers tag Consent Key PMAC Lookup Drop or = path + Pair-wise Forward Key Lookup New + CBC-MAC payload Verifiers Hash (CHI) 29
Slow path in software does key exchange Calculate Software Shared Keys Insert calculated keys Packet missing keys into cache Hardware 30
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
Throughput: Connect all forwarder ports to NetFPGA packet generators NetFPGA Packet 2Gbps Generator R? ICING Forwarder 2Gbps NetFPGA Packet R? Generator 32
Throughput vs. Payload Size (Path Length=7) 4000 100% 3500 3000 Throughput 2500 (Mbps) 2000 50% 1500 1000 500 0 0% 0 500 1000 Payload Size (bytes) 33
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
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
Outline • Design in three iterations • Prototype implementation and results • Related work and conclusion 36
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
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
Recommend
More recommend
