A policy framework for the future Internet

1. A policy framework for the future Internet Arun Seehra*, Jad Naous†, Michael Walfish*, David Mazières†, Antonio Nicolosi§, and Scott Shenker¶ *The University of Texas at Austin †Stanford §Stevens Institute of Technology ¶UC Berkeley and ICSI

2. Who should control communications?What should they control? • Many Internet stakeholders:senders, receivers, transit providers, edge providers, middleboxes, … • Each has many valid policy goals • Where do your sympathies lie?

3. source routing NIRA x o o - - - --- oo x xo o o o o BGP NUTSS TVA LSRR - -- o x o - -o x o o - o x o o o ox o o o o o x o - - o o - - ox o o - - - -x ooo o x- oo o x- - o o x - - - ox - - - - i3, DOA - - o - -x Prior proposals: large union, small intersection • Proposals generally choose particular concerns • To the exclusion of other concerns • Our community: lots of sympathy, little consensus

4. So what options does our community have? • Embrace the status quo: do nothing • This is architectural abdication • Make a hard choice: select the “right” subset • This would be a gamble • On a choice that must last another 30 years • By a community not known for accurate predictions • Choose “all of the above”:take the union of controls • This preserves our options; no picking winners/losers • The late binding avoids guesses about unknowables

5. “All of the above” brings challenges 1. Can we identify a coherent union? 2. Can we build a mechanism to support it? Rest of this talk

6. policy principle xo o oo o o ooo o o o x ooox o o o o x oooo o o o ooox o o o xooo o o o ooxo o What is the right union? • Rough consensus only about who doesn’t get a say • Overkill for any application, not for a framework • Conjecture: nothing weaker meets all policy goals, nothing stronger needed • We propose: Allow a communication iff all participants approve

7. You might worry: ISPs get a lever Which could threaten Net neutrality Universal connectivity On the other hand: Endpoints empowered Which could create Competition Instead of monopoly Veto power for all?! xo o oo o o ooo o o o x ooox o o o o x oooo o o o ooox o o o xooo o o o ooxo o We didn’t create this tussle* and can’t end it today We can seek an outlet for it … *[Clark et al. SIGCOMM 2002]

8. The challenges in “all of the above”: 1. Can we identify a coherent union? 2. Can we build a mechanism to support it? (My goal is to convince you it’s feasible) xo o oo o o ooo o o o x ooox o o o o x oooo o o o ooox o o o xooo o o o ooxo o

9. Requirements for a candidate mechanism xo o oo o o ooo o o o x ooox o o o o x oooo o o o ooox o o o xooo o o o ooxo o • Communication needs approval from all parties • Communication follows the approved path • Adversarial environment • No centralization or trusted entities • Data plane is feasible, even at backbone speeds

10. path server consent server 1 CS 2 CS 3,4 C1 s3, s4 s2 “D” P C3,C4 C2 (knows s1) s4 s3 s2 s1 ICING from 30,000 feet Ri = public key P = {R0,R1,R2,R3,R4} Ci = MAC(si, P) C1 C2 C3 C4 D R4 R0 R3 R1 R2 • CS applies policy; can also abdicate, delegate • Not covering how R0gets approval to reach CSi, PS • Packets must be bound to paths efficiently • With no key distribution or pairwise coordination • While resisting attacks

11. R0 R0 R1 R2 R3 R4 R0 R1 R2 R3 R4 R0 R1 R2 R3 R4 C3 C4 M M M C1 C2  C3 C4 C1 C2 R1 Binding a packet to its path Ri = pubkey P = {R0,R1,R2,R3,R4} Ci = MAC(si, P) xi = privkey of Ri ki,j = H(gxixj, Ri, Rj) • Honest realms: 1. verify consent, provenance 2. prove to later realms  C3 C4 C1 C2 R2 ? R3 C2 ^ MAC(k0,2, 0||H(P,M)) ^ MAC(k1,2, 1||H(P,M)) R4

12. ICING’s data plane in a nutshell • Binds a packet to its path (required by “union”) • Packet carries path (list of public keys), auth tokens • Realms use ki,j to transform auth tokens • For j<i, Riverifies that all kj,iwere applied • For j>i, Riproves to Rj using ki,j • No key distribution: Ri derives ki,j from Rj’s name • Resists attack: forgery, injection, short-circuiting, … • Feasibility:is required space, computation tolerable?

13. R0 R1 R2 R3 R4 M 16 bytes 20 bytes (ECC) ICING’s data plane is feasible • Space overhead? • Average ICING header: ~250 bytes • Average packet size: ~1300 bytes [CAIDA] • So, total overhead from ICING: ~20% more space • Can forwarding happen at backbone speeds? • On NetFPGA, ICING speed is ~80% of IP speed • At what hardware cost? • Equiv. gate count: 13.4 M for ICING vs. 8.7 M for IP • Total logic area: ICING costs 78% more than IP

14. Reflecting on ICING ICING meets its requirements: • Communication needs approval from all parties • Communication follows the approved path • Adversarial environment • No trusted entities • Data plane is feasible, even at backbone speeds consent server 1 CS 2 CS 3,4 D

15. Aspects of ICING that this talk punted • The control plane (which is pluggable) • Handles configuration, path selection, getting Ci, … • Runs in commodity servers, unseen by data plane • Ensures unapproved communications blocked early • Lots about the data plane • Expiration and revocation: Ci, keys, secrets • Handling network failure, defending against attack • Deployment

16. Recap • Many good policies; no consensus on “best” • So try to uphold “all of the above” • Brings technical challenges • ICING addresses those challenges • Today: not implausible. Tomorrow: not impractical. • 100,000-foot view: bandwidth and computation keep increasing, so use them to buy new properties • We think ICING’s properties are worth its price xo o oo o o ooo o o o x ooox o o o o x oooo o o o ooox o o o xooo o o o ooxo o