Policy and mechanism in the future Internet
Michael WalfishThe 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)
• 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?
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, …
Prior works: large union, small intersection
x o o o o o source routing
o - - - - xCapabilities
x o o - - -- - - o o x
NIRA
Platypusx o o o o oo - - x - oo - x - - oo x - - - o
Secure BGP- - - o x o- - o x o o- o x o o oo x o o o o
Filterso - - - x oo - - x - oo - x - - oo x - - - o
• Proposals generally choose particular concerns To the exclusion of other concerns
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)
We propose a unified policy framework
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
• 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:
• 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 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
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
What should be the control/data plane interface?
General-purpose serverspath, 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
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.
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, Ri verifies provenance using kj,i
For j>i, Ri proves 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?
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
R0 R1 R2 R3 R4
M
24 bytes (ECC) 18 bytes
• 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 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
BGP’s choice of paths, enforced
Data plane
sender
dest.
R1 R2
Data plane
Data plane
consent
server 1
consent
server 2
consent
server 3
R3
path = <sender R1 R2 R3 dest>
use <PoC1 PoC2 PoC3 PoCdest>
BGP BGP
<R2 R3 dest>,<s2 s3 sdest >
“dest”
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
<S R1 R2 R3 dest>
< PoC2 PoC3 PoCdest
>
dest
Special case of sink routing:forcing flows through offsite
scrubbing servicesconsent server
enterprise
offsite scrubber
sender
dest.
ICING provides flexible access controlconsen
t server
• Can delegate consent-granting to specialist• Or let some clients (employees) mint PoCs• And restrict which servers employees can
reach
employee
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
Limitations, future work, and recap
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
• 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
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 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
