1 / 22

Policy and mechanism in the future Internet

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

gratia
Download Presentation

Policy and mechanism in the future Internet

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  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. Who should control communications?What should they control? • Many stakeholders:senders, receivers, transit providers, edge providers, middleboxes, … • Each has many policy- and security-related goals scrubbing service • Where do your sympathies lie?

  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. source routing xo o o o o Secure BGP NIRA Capabilities Platypus Filters - -- o x o - -o x o o - o x o o o ox o o o o x o o - -- -- - oo x o - - - -x xooo o o o --x- o o -x - - o ox - - - o o ---x o o --x- o o -x - - o ox - - - o Prior works: large union, small intersection • 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 xo o oo o o ooo o o o x ooox o o o o x oooo o o o ooox o o o xooo o o o ooxo o policy principle: • 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

  7. xo o oo o o ooo o o o x ooox o o o o x oooo o o o ooox o o o xooo o o o ooxo o • 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?

  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? • Policy decisions need to be prior to packet flow • So move policy from routers to evolvable servers • Servers can delegate or abdicate their control General-purpose servers path, info. stuff payload other stuff

  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 ki,j to transform verifiers • For j<i, Riverifies provenance using kj,i • For j>i, Riproves provenance 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?

  12. R0 R1 R2 R3 R4 M 18 bytes 24 bytes (ECC) 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

  13. xo o oo o o ooo o o o x ooox o o o o x oooo o o o ooox o o o xooo o o o ooxo o • 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)

  14. BGP’s choice of paths, enforced BGP BGP consent server 1 consent server 2 consent server 3 “dest” Data plane Data plane Data plane sender R3 R2 R1 dest. path = <sender R1 R2 R3 dest> use <PoC1 PoC2 PoC3 PoCdest> <R2 R3 dest>, <s2 s3 sdest >

  15. ICING permits “sink routing” <S R1 R2 R3 dest> < PoC2 PoC3 PoCdest > • 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 consent server 3 R2 S dest R1 R3

  16. Special case of sink routing:forcing flows through offsite scrubbing services consent server sender enterprise offsite scrubber 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. Future work • Defending against intelligent replay attacks • Detecting unsatisfactory service by providers • Preventing unauthorized subcontracting of transit • E.g., prevent ISP from redirecting through country X

  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 xo o oo o o ooo o o o x ooox o o o o x oooo o o o ooox o o o xooo o o o ooxo o

More Related