Upload
others
View
3
Download
0
Embed Size (px)
Citation preview
NEBULA Future Internet Architecture
1
• E.g., food, exercise, meds for managing personal health – Interact w/cloud for recommendaAons & reminders
• Research ques+ons: resilience, adversary models, policies, economics, etc.
“Long tail” of apps not on Internet…
2
The BIG quesAon:
Given the conAnuing shiM to cloud services and modularizable routers, for traffic where resilience maQers: What architectural solu/ons are needed for a highly resilient Internet?
3
NEBULA research approach
• Goal of resilience in Future Internet to: HW/ SW failures, operator error, malicious behavior by ISPs, end hosts, governments – If a path exists, should find it and use it
• To do this, we need progress on a set of topics – Each topic is hard and has mulAple efforts
• NEBULA is prototyping and validaAng a set of architectural ideas
4
Threat Model • ISPs don’t provide agreed service • ISPs disrupt traffic, ISP-‐ISP or endpoint-‐ISP • Compromised routers/parts of routers in ISPs • Packet-‐flooding DoS aQacks from botnets or compromised ISPs, against endpoints, internal links and control traffic
• Even with no malice, components and groups of components can and will fail – Nebula must minimize such faults and if they occur, quickly idenAfy, locate and recover
5
UlAmate NEBULA threat model: ByzanAne, no trust
• Assume that an arbitrary subset of the nodes and networks is fully controlled by a ByzanAne adversary
6
Alice
important.com
A
CB
Compromised router
Adversarial network
Future Internet requirements
1. Route Control 2. DoS resilient 3. ByzanAne resilient to ISPs & users 4. Highly reliable 5. Flexible; upgradable w/o disrupAng traffic 6. Supports cloud and ”big data”; consistent with
mobility, sensors 7. No economic or policy barriers to deployment
7
Subteams versus requirements Requirement Subteam 1. Route Control Berkeley, Penn, UT AusAn, Stanford,
Stevens, Princeton 2. DoS Resilient UT AusAn, Stanford, Stevens, U.
Washington 3. ByzanAne resilient Cornell, Penn, U. Washington
4. Highly reliable Cornell, U. Del., Purdue, Illinois, Penn, Cisco
5. Flexible and upgradable
Princeton, Penn, Cornell, Cisco
6. Cloud/big data, sensors and mobility
Purdue, Penn, Princeton, Stanford, Cornell, U. Washington
7. Deployable MIT, Penn 8
Resilience: how do we get there?
• Routers: new fault-‐tolerant control soMware • Paths: exploiAng path diversity for resilience • Failures/malice: new ways to detect/resist • Domains: resilient inter-‐domain protocols • Policy and economics: implicaAons of (and for) resilience soluAons
• Security and privacy: resilient approaches
9
Algorithms + redundancy = resilience
10
Interconnected Data Centers Router
Reliability MulAple Paths
End-‐user and ApplicaAon Control
policy
Policy Enforcement
Network Provenance, DetecAon & Debugging
11
• Q1, P1, Q6 or P3 fail. Access is preserved via P1, Q1, P3 and Q6 respecAvely.
• Q3 or Q4’s policy is incompaAble with Host 1 or Host 2. Either Q4 or Q3 can be used, or the green path can be exploited if it is compliant.
• P2’s reliability is several orders of magnitude greater than either Q3 or Q4. Does the green path reliability dominate that of the red path with mulAple transit links?
Network
ApplicaAon
OS
Hypervisor
Network
SPY
SPY
SPY
Pidgin
Client
host failures network failures
Pidgin – failure detecAon
13
TorIP: Capability-‐Based Mailboxes
• Receivers should only receive packets they request
• Mailboxes support a put/get interface
• Data follows reverse path of get request
Tier 2 ISP
Tier 3 ISP
Tier 1 ISPs
NEBULA InteracAon with Cisco • Up to 6 FTEs (peak) working on R3/NEBULA
– Cisco Ludd interests centered on resilience, reliability and versioning in core routers, e.g., CRS-‐1
– R3 / NEBULA split largely along NDA lines • AcAve parAcipant in calls and meeAngs
– Admin services, e.g., Cisco Webex and travel support – Access to Cisco proprietary info on core network designs (under NDA)
• Sponsoring three research interns Summer ’12 – CompeAAvely selected from pool of applicants – Will intern at Cisco HQ in San Jose, CA
14
Impacts: Cisco Ludd, with R3 and NEBULA, have yielded proofs-‐of-‐concept. Current planning on evolving and acceleraAng results into deployable prototypes.
The NEBULA Team Tom Anderson
Ken Birman
Robert Broberg
MaQhew Caesar
Douglas Comer
Chase CoQon
Michael Freedman
Andreas Haeberlen
Zack Ives
Arvind Krishnamurthy
William Lehr
Boon Thau Loo
David Mazieres
Antonio Nicolosi
Jonathan Smith
Ion Stoica
Robbert van Renesse
Michael Walfish
Hakim Weatherspoon
Christopher Yoo 15
16
Backup slides aMer here
QuesAons, vs. NEBULA work Ins+tu+on Resilient
Routers Resilient Paths
Failure detect & debug
Protocols Policy & Econ.
Security & privacy
Berkeley * *
Cornell * *
Delaware * *
Illinois * *
MIT *
Penn * * * *
Princeton * *
Purdue * * *
Stevens * *
Stanford *
UT AusAn * *
U. Wash. * * * 17
Resilient routers
• TCP-‐R reliable TCP for fault tolerant BGP • System SIS-‐IS redundant registry • Replicated applicaAon processes in router • Key-‐value store for CRS-‐1 • Network debugging
18
Resilient paths
• Serval exploits available paths • DeclaraAve networking constructs a rich graph • Data center aQachment to router is path-‐rich • Icing protects paths • Data center interconnect is a path-‐rich graph • New algorithms and interconnect for data centers
19
Failure detect and debug
• BGP Highjack prevenAon • Pidgin System • Secure Network Provenance • Network debugging
20
Protocols
• Serval • DeclaraAve Networking • TorIP • SoNIC
21
Policy and Economics
• EvoluAon of ISPs in response to architecture – E.g., incenAves (or lack thereof) to use TorIP – Policy compliant ISPs in response to Icing
• Regulators for, or against, privacy • How does more resilience change costs:
– For infrastructure such as routers? – For interconnect? – For total cost of operaAon (TCO)?
22
Security and Privacy
• Icing • Secure Network Provenance • BGP Highjack PrevenAon • TorIP
23
Resilience!
• Router soMware architectures for resilience • Resilient router interconnecAon schemes • Redundant policy-‐compliant paths thru net • DetecAng failures via network provenance, debugging networks, restoring networks
• Reliability over Ame, through evolvable edge, core, control plane and policies
24
A Comprehensive Architecture • NEBULA is an architecture for the cloud-‐based future Internet – Cloud is 1960s compu/ng u/lity – Requires a new kind of net
• Key goals – More secure and reliable – Deployable and evolvable – Co-‐design tech/economics/policy – Truly clean slate!
IMP
Front and Back, CRS-‐1 25
Architecture versus soluAon
• Architecture allows mulAple implementaAons • Have addressed resilience comprehensively • As few moving parts as we can have • Result: a resilient, secure, evolvable future internet architecture
26