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

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?

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

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

“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

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

Veto power for all?! You might worry: ISPs get a lever x o o o o o o o o o o o o x o o o x o o o o x o o o o o o o o o o x o o o x o o o o o o o o x o o 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 We didn’t create this tussle* and can’t end it today We can seek an outlet for it … *[Clark et al. SIGCOMM 2002]

The challenges in “all of the above”: x o o o o o o o o o o o o x o o o x o o o o x o o o o o o o o o o x o o o x o o o o o o o o x o o 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)

Requirements for a candidate mechanism x o o o o o o o o o o o o x o o o x o o o o x o o o o o o o o o o x o o o x o o o o o o o o x o 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

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

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 R0 R0 R1 R2 R3 R4 M C1 C2 C3 C4 R1 R0 R1 R2 R3 R4 M C1 C2 C3 C4   R0 R1 R2 R3 R4 M C1 C2 C3 C4 R2 R3 ? C2 ^ MAC(k0,2, 0||H(P,M)) ^ MAC(k1,2, 1||H(P,M)) R4

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, Ri verifies that all kj,i were applied For j>i, Ri proves 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?

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 R0 R1 R2 R3 R4 M 20 bytes (ECC) 16 bytes

Reflecting on ICING Communication needs approval from all parties consent server 1 CS 2 CS 3,4 D 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

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

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 x o o o o o o o o o o o o x o o o x o o o o x o o o o o o o o o o x o o o x o o o o o o o o x o o