A policy framework for the future Internet Arun

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 §Stevens Institute of Technology †Stanford ¶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 source routing xooooo BGP ---oxoo -oxoooo NIRA xoo-----oox NUTSS oxo--oxo i 3, DOA --o--x TVA o----x LSRR oooox-oox---- • 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

What is the right union? • Rough consensus only about who doesn’t get a say policy principle • We propose: xoooooox oooxooooo oooooxoooo ooooxoo 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 • Which could threaten § Net neutrality § Universal connectivity xoooooox oooxooooo oooooxoooo ooooxoo 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”: 1. Can we identify a coherent union? xoooooox oooxooooo oooooxoooo ooooxoo 2. Can we build a mechanism to support it? (My goal is to convince you it’s feasible)

Requirements for a candidate mechanism xoooooox oooxooooo oooooxoooo ooooxoo • 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 path server “D” C 1 C 2 C 3 C 4 P 30, 000 feet consent C 1 server 1 (knows s 1) CS 2 C 2 s 2 CS 3, 4 C 3, C 4 s 3, s 4 s 3 s 2 s 1 R 0 Ri = public key P = {R 0, R 1, R 2, R 3, R 4} Ci = MAC(si, P) R 1 R 2 R 3 D s 4 R 4 • CS applies policy; can also abdicate, delegate • Not covering how R 0 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 • Honest realms: 1. verify consent, provenance 2. prove to later realms Ri = pubkey P = {R 0, R 1, R 2, R 3, R 4} Ci = MAC(si, P) xi = privkey of Ri ki, j = H(gxixj, Ri, Rj) R 0 R 1 R 2 R 3 R 4 C 1 C 2 C 3 C 4 M R 1 R 0 R 1 R 2 R 3 R 4 C 1 C 2 C 3 C 4 M R 2 R 0 R 1 R 2 R 3 R 4 C 3 C 4 M R 3 R 4 C 1 C 2 ? C 2 ^ MAC(k 0, 2, 0||H(P, M)) ^ MAC(k 1, 2, 1||H(P, M))

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 ji, 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? R 0 R 1 R 2 R 3 R 4 20 bytes (ECC) M 16 bytes § 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 Net. FPGA, 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

Reflecting on ICING 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 xoooooox oooxooooo oooooxoooo ooooxoo • 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