500 likes | 606 Views
15-849: Hot Topics in Networking Four Next Generation Architectures. Srinivasan Seshan. Key Questions. How do these proposals differ in addressing similar problems? Routing Addressing Service interface Security Economics/Policy Mobility Naming. Key Questions.
E N D
15-849: Hot Topics in NetworkingFour Next Generation Architectures Srinivasan Seshan
Key Questions • How do these proposals differ in addressing similar problems? • Routing • Addressing • Service interface • Security • Economics/Policy • Mobility • Naming
Key Questions • What are the key hurdles for each project? • Scalability • Difficult scenarios/usage models • Inherent complexity • Handling real-world incentives/economics • Evolution from current network
Key Questions • Do you believe in basic motivations of each project? • Do we really need a new Internet arch? • If so, how do we deploy this? • What about IPv6?
NSF Programs • Stagnation • 100x100 Clean Slate Design • PlanetLab • Overcoming the Internet Impasse through Virtualization GENI • FIND FIA (aka FIND phase 2) • Phase 1 – 50 “small” projects • Phase 2 – 4 large “integrative” projects • Named Data Networking • MobilityFirst • NEBULA • eXpressive Internet Architecture
Named Data Networking • In the beginning... • First applications strictly focused on host-to-host interprocess communication: • Remote login, file transfer, ... • Internet was built around this host-to-host model. • Architecture is well-suited for communication between pairs of stationary hosts. • ... while today • Vast majority of Internet usage is data retrieval and service access. • Users care about the content and are oblivious to location. They are often oblivious as to delivery time: • Fetching headlines from CNN, videos from YouTube, TV from Tivo • Accessing a bank account at www.bank.com.
To the beginning... • What if you could re-architect the way “bulk” data transfer applications worked • HTTP • FTP • Email • etc. • ... knowing what we know now?
Google… Biggest content source Third largest ISP Global Crossing Level(3) Google source: ‘ATLAS’ Internet Observatory 2009 Annual Report’, C. Labovitz et.al.
1995 - 2007:Textbook Internet 2009:Rise of the Hyper Giants source: ‘ATLAS’ Internet Observatory 2009 Annual Report’, C. Labovitz et.al.
What does the network look like… ISP ISP
CCN Model • Packets say ‘what’ not ‘who’ (no src or dst) • communication is to local peer(s) • upstream performance is measurable • memory makes loops impossible Data
Context Awareness? • Like IP, CCN imposes no semantics on names. • ‘Meaning’ comes from application, institution and global conventions: /parc.com/people/van/presentations/CCN /parc.com/people/van/calendar/freeTimeForMeeting /thisRoom/projector /thisMeeting/documents /nearBy/available/parking /thisHouse/demandReduction/2KW
Signed by nytimes.com/web/george Signed by nytimes.com/web Signed by nytimes.com CCN Names/Security ⎧⎪⎨⎪⎩ /nytimes.com/web/frontPage/v20100415/s0/0x3fdc96a4... • Per-packet signatures using public key • Packet also contain link to public key signature 0x1b048347 key nytimes.com/web/george/desktop public key ⎧⎪⎨⎪⎩ ⎧⎪⎨⎪⎩
Names Route Interests • FIB lookups are longest match (like IP prefix lookups) which helps guarantee log(n) state scaling for globally accessible data. • Although CCN names are longer than IP identifiers, their explicit structure allows lookups as efficient as IP’s. • Since nothing can loop, state can be approximate (e.g., bloom filters).
get /parc.com/videos/WidgetA.mpg/v3/s2 CCN node model P /parc.com/videos/WidgetA.mpg/v3/s2 0
Flow/Congestion Control • One Interest pkt one data packet • All xfers are done hop-by-hop – so no need for congestion control • Sequence numbers are part of the name space
What about connections/VoIP? • Key challenge - rendezvous • Need to support requesting ability to request content that has not yet been published • E.g., route request to potential publishers, and have them create the desired content in response
MobilityFirst • Fundamental change in design goals and assumptions • ~10B+ mobile/wireless end-points as “first-class” Internet devices • Mobility as the norm for end-points and access networks • Wireless access – varying link BW/quality, multiple radios, disconnections • Stronger security/trust requirements due to: • open radio medium • need for dynamic trust association for mobile devices/users • increased privacy concerns (e.g. location tracking) • greater potential for network failure • Mobile applications involve location/content/context and energy constraints • Technology has also changed a lot in the ~40 yrs since IP was designed • Moore’s law improvements in computing and storage (~5-6 orders-of- magnitude gain in cost performance since 1970) • Edge/core disparity, fast fiber but continuing shortage of radio spectrum
MobilityFirst • Clean-slate protocol design that directly addresses the problems of mobility at scale, while also strengthening the trust model • End-point and network mobility at scale • Intrinsic properties of wireless medium • More stringent security/trust requirements • Special needs of emerging mobile applications • Fixed internet access is treated as a special case of the more general design • Although the “sweet spot” of our protocol is wireless/mobile, we believe that our design provides important benefits to fixed network applications • Security/trust • Robustness • Fault tolerance • Context/content
Goals • Host + network mobility • No global root of trust • Intentional data receipt • Byzantine robustness • Content addressability • Evolvable network
Additional Design Principles • Visibility and choice • Usability • Manageability • Simplicity • Regulability • Commercializability • Technology-awareness
Security 1. Public keys global identifiers for hosts & networks; forms basis for: • Ensuring accountability of traffic • Ubiquitous access-control infrastructure • Robust routing protocols • Preventing address hijacking 2. Support deployment of policies that constrain the traffic that a network or node receives • In the limit, a “default-disconnected” posture 3. No single globally trusted root for naming or addressing • Opens naming to innovation to combat naming-related abuses • Removes obstacles to adoption of secure routing protocols 4. Systematically consider Trusted Computing Base of designs • Promote TCB reduction technologies (e.g., Byzantine fault tolerance)
NEBULA • NEBULA is an architecture for the cloud-based future Internet • More secure and reliable • Deployable and evolvable • Truly clean slate • Availability: At riskofnetworkoutages • Security: • Poorendpointauthentication • HIPAApolicyrestrictions notexpressiblewithexisting routing protocols • Consistency: • Communications end--‐point focused, notdatafocused • Cloudsystemshaveembracedweakconsistency (CAP Theorem)
Network Security • The “big I” InternetIs federated: • Policiesmustbeenforcedacrossrealms (e.g., DDoS) • NEBULAaddressesproblemsatrightplaces: • Extensibility+Policy: newcontrolplane • PolicyEnforcement: newdataplane • Availability: high-performance, redundant-pathcorewithhigh‐availability corerouters
XIA Vision We envision a future Internet that: • Is trustworthy • Security broadly defined is the biggest challenge • Supports long-term evolution of usage models • Including host-host, content retrieval, services, … • Supports long term technology evolution • Not just for link technologies, but also for storage and computing capabilities in the network and end-points • Allows all actors to operate effectively • Despite differences in roles, goals and incentives
Src: Client IP Dest: Server IP Today’s Internet • Client retrieves document from a specific web server • But client mostly cares about correctness of content, timeliness • Specific server, file name, etc. are not of interest • Transfer is between wrong principals • What if the server fails? • Optimizing transfer using local caches is hard • Need to use application-specific overlay or transparent proxy – bad! TCP Client IP Server IP
Src: Client ID Dest: Content ID eXpressive Internet Architecture • Client expresses communication intent for content explicitly • Network uses content identifier to retrieve content from appropriate location • How does client know the content is correct? • Intrinsic security! Verify content using self-certifying id: hash(content) = content id • How does source know it is talking to the right client? • Intrinsic security! Self-certifying host identifiers PDA Content
Flexible Trust Management Anywhere A Bit More Detail … Dest: Service ID Content Name? Dest: Client ID Diverse Communicating Entities Content ID Dest: Content ID Intrinsic Security Hash( ) = CID? XIA Transformational Ideas
P1: Evolvable Set of Principals • Identifying the intended communicating entities reduces complexity and overhead • No need to force all communication at a lower level (hosts), as in today’s Internet • Allows the network to evolve Content a581fe9 ... Services d9389fa … Future Entities Host 024e881 … 39c0348 …
P2: Security as Intrinsic as Possible • Security properties are a direct result of the design of the system • Do not rely on correctness of external configurations, actions, data bases • Malicious actions can be easily identified Content a581fe9 ... Services d9389fa … Future Entities Host 024e881 … 39c0348 …
043e49af3890dd327134389a90cd2199 P3: Narrow Waist for Trust Management • Ensure that the inputs to the intrinsically secure system match the trust assumptions and intensions of the user • Certificate authorities, reputation, personal, … • Narrow waist allows leveraging diverse mechanisms for trust management Trust Management Declaration of Independence
XIA adds evolvability at the waist: Applications Evolving set of principals Link technologies IP: Evolvability of: Applications Link technologies P4: Narrow Waist for All Principals • Extends today’s host-based narrow waist to all principals: hosts, services, content, … • Defines the API between the principals and the network protocol mechanisms
P5: All other Network Functions are Explicit Services • DNS, firewalls, … • Causes problems in IP • Covers all functions not part of the narrow waist • XIA provides a principal type for services • Keeps the architecture simple and easy to reason about
XIA: eXpressive Internet Architecture • Each communication operation expresses the intent of the operation • Also: explicit trust management, APIs among actors • XIA is a single inter-network in which all principals are connected • Not a collection of architectures implemented through, e.g., virtualization, overlays • Not based on a “preferred” principal (host, content), that has to support all communication
XIA Components and Interactions Users Applications Services Network-Network User-Network Trustworthy Network Operation Intrinsic Security Host Support Content Support Services Support … eXpressive Internet Protocol
What ApplicationsDoes XIA Support • Since XIA supports host-based communication, today’s applications continue to work • Will benefit from the intrinsic security properties • New applications can express the right principal • Can also specify other principals (host based) as fallbacks • Content-centric applications • Explicit reliance on network services • Mobile users • As yet unknown usage models