Download presentation
Presentation is loading. Please wait.
0
One Primitive to Diagnose Them All: Architectural Support for Internet Diagnostics
Ang Chen* Andreas Haeberlen* Wenchao Zhou+ Boon Thau Loo* University of Pennsylvania* Georgetown University+ EuroSys 2017
1
Problem: Internet diagnostics and forensics
Who dropped my packets? Who modified my webpage? C E A Who is attacking me? F D B Many things can go wrong in the Internet Verifying SLAs Detecting packet modifications Identifying attack sources … We need better support for diagnostics and forensics!
2
Many proposals have been made
Each proposal requires a different extension We cannot deploy all (!) extensions simultaneously
3
One ‘primitive’ for all?
Can we use one primitive to support many applications?
4
Key insight Many applications have common requirements
SPIE [SIGCOMM’01] Passport [NSDI’08] AudIt [ICNP’07] DRKey [SIGCOMM’14] ICING [CoNEXT’11] Common core Many applications have common requirements Tracking what happened in the network (provenance) Generating proofs about what happened (signatures) Efficiency
5
Approach Routers forward traffic as they would
B A C Evidence? Evidence? Evidence? Evidence? Routers forward traffic as they would But they also produce secure provenance about their actions And they exchange provenance data with their neighbors Traffic sender can collect the provenance retroactively And uses it for fault detection
6
Outline Motivation: Internet diagnostics and forensics
Can we achieve ‘one primitive for all’ ? Primitive: Secure packet provenance Starting point: Provenance Making it secure Making it efficient Evaluation Does SPP have reasonable overhead? Can SPP achieve ‘one primitive for all’? Summary
7
Starting point: Provenance
Server received packet at t1 Link Last-hop switch sent packet at t2 Routing rule match Link Another switch sent packet at t3 Routing rule match … … Provenance can track what happened in the network! Network topology Control-plane configurations Data-plane events Focus of this talk!
8
Strawman solution for providing security
COMMIT: Recv( ) A B AUDIT( ) RESPOND( ) B: Recv( ) B: Recv( ) B: Recv( ) B: Recv( ) Evidence generation: (1) Routers cryptographically sign each packet (2) Signatures are stored in local logs (3) Traffic senders can download packet signatures
9
Challenge #1: Computation overhead
B Problem: Cryptographic signatures are expensive 10Gbps link: requires 15M signatures/sec! RSA signature speed: on the order of 1K signatures/sec
10
Making it lightweight Reducing the expensive operations
Signature Reduced cost = Hash Two hashes per packet Hash Hash + One signature per batch Hash Hash Hash Hash p1 p2 p3 p4 Merkle hash tree with four packets Reducing the expensive operations Batch packets into epochs Compute Merkle Hash Trees (MHT) per batch Sign the MHT roots only
11
How to collect the provenance
Path to the root I’d like to audit p2 Hash Hash Hash Hash Hash Hash Hash Proof p1 p2 p3 p4 Proof that the second packet is p2 Reveals nothing about p1, p3, p4! We can collect the provenance about individual packets Without having to know about other packets Proof: Signature of the root + path to the packet
12
Challenge #2: Storage overhead
Freeze( ) B A Freeze( ) B: Recv( ) C: Recv( ) B: Recv( ) C: Recv( ) B: Recv( ) C: Recv( ) B: Recv( ) C: Recv( ) Idea: Routers gradually expire old provenance data Caveat: routers can destroy evidence to cover its tracks! Idea: Retroactive freezing protocol Within a certain time, auditors can ‘freeze’ their packets
13
Challenges addressed Cannot keep data forever Computation overhead
Control-plane diagnosis Privacy Handling packet loss Aggregate metrics
14
Putting it all together
B A C AUDIT( ) Traffic sender recursively collect + verify the provenance Until we identify a faulty node E.g., one that maliciously injects malware to packets
15
Outline Motivation: Internet diagnostics and forensics
Can we achieve ‘one primitive for all’ ? Primitive: Secure packet provenance Starting point: Provenance Making it secure Making it lightweight Evaluation Does SPP have reasonable overhead? Can SPP achieve ‘one primitive for all’? Summary
16
Evaluation: Overview Q1: How much is SPP’s computation overhead?
Q2: How much storage is needed to hold the evidence? Q3: How much extra traffic does SPP generate? Q4: How fast can SPP execute the audits? Q5: How well can SPP achieve ‘one primitive for all’?
17
Evaluation: Prototype
We have built software and hardware prototypes Software prototype: C/C++, Click mode, standalone mode Hardware prototype: Verilog, NetFPGA-10G platform Traffic traces Worst-case scenarios: synthesized traces with minimal packet sizes at different rates: 100Mbps, 1Gbps, 10Gbps. Real traffic traces: from CAIDA OC-192 link (10Gbps rate)
18
How much is the computation overhead?
# of Cores 10 1 0.1 18.6 Other Hashing 1.86 1.57 0.18 100Mb/s Gb/s Gbps OC-192 SW results: number of cores needed to perform commitment at a certain traffic rate
19
How much is the computation overhead?
Idea: Leverage hardware acceleration Hashing can be implemented efficiently in hardware Result: Expensive operations can be performed at line rate (10Gbps)
20
How much extra traffic does SPP send?
2.5% 2% 1.5% 1% 0.5% 0% Bandwidth Worst-case scenario: Minimal packet size 40B packets 300B packets 2% 1.9% 1.9% OC-192 More typical packet size: 300B 0.5% 0.4% 0.4% 0.15% 100M G G M G G OC-192 Overhead in the worst-case scenario is reasonable Significantly lower overhead for normal traffic
21
Can we achieve ‘one primitive for all’?
Existing systems SPP Built several existing applications on top of SPP! Tracing the forward/reverse path of packets Identifying packet loss/modification Attest to the transmission of packets Identify the link with the highest delay on a path Compute a link’s average throughput Direct support Postprocessing
22
Summary Goal: Internet diagnostics and forensics
Problem: Many (incompatible) point solutions Insight: Most systems share a common ‘core’ ! Secure packet provenance can support this core Tracks what happened in the network Provides security properties Low overhead Supports a wide range of diagnostic scenarios Validated with software and hardware prototypes Thank you!
Similar presentations
