1. Policy and mechanism in the future Internet Michael Walfish The University of Texas at Austin in collaboration with: Arun Seehra (UT Austin), Jad Naous (Stanford), David Mazières (Stanford), Antonio Nicolosi (Stevens), and Scott Shenker (UC Berkeley/ICSI)

2. Many stakeholders: senders, receivers, transit providers, edge providers, middleboxes, … Each has many policy- and security-related goals scrubbing service Where do your sympathies lie? Who should control communications? What should they control?

3. Many network-layer proposals and defenses ACLs, NATs, VPNs, Platypus, TVA, NUTSS, i3, DOA, NIRA, LSRR, firewalls, source routing, whitelisting, blacklisting, securing BGP, provider filtering based on sender, provider filtering based on receiver, signature matching, network capabilities, telephoning your ISP, telephoning your attacker ’ s ISP, …

4. Prior works: large union, small intersection x o o o o o source routing o - - - - x Capabilities x o o - - - - - - o o x NIRA Platypus x o o o o o o - - x - o o - x - - o o x - - - o Secure BGP - - - o x o - - o x o o - o x o o o o x o o o o Filters o - - - x o o - - x - o o - x - - o o x - - - o Proposals generally choose particular concerns  To the exclusion of other concerns

5. What are our options? Embrace the status quo: do nothing  This is unsatisfactory Make a hard choice: select the “ right ” subset  This would be a gamble …  … on a choice that might last another 30 years …  … by a community not known for accurate predictions Choose “ all of the above ” : take a principled union  This is the most future-proof strategy possible  And it empowers all stakeholders (at least potentially)

6. We propose a unified policy framework 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 Let every participant formulate policies based on:  Packets ’ end-to-end paths at the domain level  Intra-domain handling (links, router queues, …)  Arbitrary other information (billing, time of day, …) Subsumes goals of prior network-layer proposals  Obvious in hindsight policy principle:

7. What policy considerations should a future Internet support? Can we build a supporting mechanism?  There are many challenges here  My goal is to convince you it ’ s feasible …  … with ICING, which we implemented in hardware What are the uses of ICING? 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

8. What are the technical challenges? Letting the control plane specify arbitrary policies  Requires new interface between control/data planes Enforcing policy decisions in the data plane  Requires new packet authentication techniques Delegating policy decisions Bootstrapping

9. What should be the control/data plane interface? General-purpose servers path, info. stuff other stuff Policy decisions need to be prior to packet flow So move policy from routers to evolvable servers Servers can delegate or abdicate their control payload

10. What is needed to enforce policy at high speed? Data plane must check that path is authorized Data plane must check that path was followed  This is a hard technical problem Status quo not even close (BGP only advisory) Target environment rules out previous techniques  Backbone speeds preclude digital signatures  Federated nature of Internet precludes central root of trust, pre-configured shared secrets, etc.

11. ICING ’s data plane in a nutshell Binds a packet to its path  Packet carries path (list of public keys), verifiers  Realms use k i,j to transform verifiers  For j<i, R i verifies provenance using k j,i  For j>i, R i proves provenance to R j using k i,j No key distribution: R i derives k i,j from R j ’ s name Resists attack: forgery, injection, short-circuiting, … Feasibility: is required space, computation tolerable?

12. ICING is feasible Space overhead?  Average ICING header: ~250 bytes  Average packet size: ~1300 bytes [CAIDA]  So, total overhead from ICING : ~20% more space What is the hardware cost?  NetFPGA gate counts: ICING is 13.4 M, IP is 8.7 M  NetFPGA forwarding speed: ICING is ~80% of IP  ICING vs. simple IP in gates/(Gbits/sec): ~2x R 0 R 1 R 2 R 3 R 4 M 24 bytes (ECC) 18 bytes

13. What policy considerations should a future Internet support? (A: Those given by the policy principle) Can we build a supporting mechanism? (A: Yes. ICING is an existence proof.) What are the uses of ICING? (Quick preview:  New kinds of routing,  Flexible network access control,  New provider business models, and more) 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

14. BGP’s choice of paths, enforced Data plane sender dest. R1 R2 Data plane consent server 1 consent server 2 consent server 3 R3 path = use BGP, “dest”

15. ICING permits “sink routing” consent server 3 Analogous to source routing Lets receivers choose paths to minimize latency, cost  (As CDNs do today using crude DNS tricks) Lets receivers choose trustworthy providers to carry sensitive data to them S R1 R2 R3 dest

16. Special case of sink routing: forcing flows through offsite scrubbing services consent server enterprise offsite scrubber sender dest.

17. ICING provides flexible access control consent server Can delegate consent-granting to specialist Or let some clients (employees) mint PoCs And restrict which servers employees can reach employee

18. Other uses of ICING Many control planes work with ICING ’ s data plane  ICING can emulate TVA, NIRA, Pathlets, LSRR, etc. New provider business models  Sell transit to anyone, not just direct neighbors  (Not a new vision, but ICING ’ s enforcement is key) Fine-grained intra-domain packet disposition  Senders, providers can negotiate over this  Key mechanism: per-realm vnodes in packets

19. Limitations, future work, and recap

20. Limitations…. … of this talk Didn ’ t talk about network failure Didn ’ t talk about expiration and revocation Didn ’ t talk about deployment … of ICING Does not prevent transparent outsourcing of transit  But lets senders choose whom to trust Cannot forward packets differently based on payload Cannot modify packet payload during transit

21. Defending against intelligent replay attacks Detecting unsatisfactory service by providers Preventing unauthorized subcontracting of transit  E.g., prevent ISP from redirecting through country X Future work

22. Recap Many good policies; no consensus on “ best ” So try to uphold “ all of the above ” : ICING is our candidate mechanism  Binds data plane to dictates of control plane  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