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

• Proposals generally choose particular concerns To the exclusion of other concerns

• Our community: lots of sympathy, little consensus

x o o o o o

source routing

BGP- - - o x o- - o x o o- o x o o oo x o o o o

x o o - - -- - - o o x

NIRAo - - - - x

TVA

o x o - - oo - - o x o

NUTSS

- - o - - xi3, DOA

LSRRo o o o x -o o o x - -o o x - - -o x - - - -

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?

• Overkill for any application, not for a framework

• Conjecture: nothing weaker meets all policy goals, nothing stronger needed

Allow a communication iff all participants approve

• Rough consensus only about who doesn’t get a say

x o o o o o oo o o o o o xo o o x o o oo x o o o o oo o o o o x oo o x o o o oo o o o x o o

policy principle

• We propose:

Veto power for all?!

You might worry:• ISPs get a lever• Which could threaten

Net neutrality Universal connectivity

x o o o o o oo o o o o o xo o o x o o oo x o o o o oo o o o o x oo o x o o o oo o o o x o o

On the other hand:• Endpoints empowered• Which could create

Competition Instead of monopoly

We didn’t create this tussle* and can’t end it todayWe can seek an outlet for it …

*[Clark et al. SIGCOMM 2002]

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)

The challenges in “all of the above”:

x o o o o o oo o o o o o xo o o x o o oo x o o o o oo o o o o x oo o x o o o oo o o o x o o

Requirements for a candidate mechanism

• 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

x o o o o o oo o o o o o xo o o x o o oo x o o o o oo o o o o x oo o x o o o oo o o o x o o

ICING from 30,000 feet

• 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

Ri = public keyP = {R0,R1,R2,R3,R4}Ci = MAC(si, P)

D

R0 R1 R2 R3

R4

consent server 1

CS 2 CS 3,4

s1

(knows s1)

s2

s2

s3

s3, s4

s4

C1 C2C3,C4

path server

“D” PC1

C2

C3

C4

Binding a packet to its path• Honest realms: 1. verify consent, provenance 2. prove to later realms

Ri = pubkeyP = {R0,R1,R2,R3,R4}Ci = MAC(si, P)

xi = privkey of Ri ki,j = H(gxixj, Ri, Rj)

R3

R4

R0R0 R1 R2 R3 R4 MC1 C2 C3 C4

R1R0 R1 R2 R3 R4 MC1 C2 C3 C4

?C2 ^ MAC(k0,2, 0||H(P,M)) ^ MAC(k1,2, 1||H(P,M))

R2R0 R1 R2 R3 R4 MC1 C2 C3 C4

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

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

D

consent

server 1

CS 2 CS 3,4

Reflecting on ICING

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