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. 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

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. 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

7. 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]

8. 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)

9. 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

10. 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

11. 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

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, 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?

13. 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

14. 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

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