15-849: Hot Topics in Networking

Four Next Generation Architectures

Srinivasan Seshan

1

Key Questions

• How do these proposals differ in addressing similar problems?• Routing• Addressing• Service interface• Security• Economics/Policy• Mobility• Naming 2

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

3

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?

4

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

5

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

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?

7

Biggest content source

Third largest ISP

source: ‘ATLAS’ Internet Observatory 2009 Annual Report’, C. Labovitz et.al.

Level(3) GoogleGlobalCrossing

Google…

8

1995 - 2007:Textbook Internet

2009:Rise of theHyper Giants

source: ‘ATLAS’ Internet Observatory 2009 Annual Report’, C. Labovitz et.al.

9

ISP

ISP

What does the network look like…

10

ISP

ISP

What should the network look like…

11

Communication vs. Distribution

12

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

13

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

14

Signed by nytimes.com/web/george

⎧ ⎪ ⎨ ⎪ ⎩

CCN Names/Security/nytimes.com/web/frontPage/v20100415/s0/0x3fdc96a4...

⎧ ⎪ ⎨ ⎪ ⎩Signed by nytimes.com/web

0x1b048347signature

key

nytimes.com/web/george/desktop public key

⎧ ⎪ ⎨ ⎪ ⎩Signed by nytimes.com

• Per-packet signatures using public key• Packet also contain link to public key

15

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

CCN node model

17

CCN node model

get /parc.com/videos/WidgetA.mpg/v3/s2

/parc.com/videos/WidgetA.mpg/v3/s2 0P

18

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

19

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

20

21

Trust in NDN

22

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 23

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

24

Goals

1. Host + network mobility2. No global root of trust 3. Intentional data receipt 4. Byzantine robustness 5. Content addressability 6. Evolvable network

25

Additional Design Principles

1. Visibility and choice2. Usability3. Manageability4. Simplicity5. Regulability6. Commercializability7. Technology-awareness

26

MobilityFirst Architecture

27

Protocol Stack

28

Name-Address Separation

29

Name Resolution

30

Storage Aware Routing

31

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

32

NEBULA

• NEBULA is an architecture for the cloud-based future Internet• More secure and reliable• Deployable and evolvable• Truly clean slate

• Availability: At risk of network outages• Security:

• Poor endpoint authentication• HIPAA policy restrictions not expressible with existing routing

protocols• Consistency:

• Communications end-- point focused, not data focused‐• Cloud systems have embraced weak consistency (CAP Theorem)

33

Architecture

34

Network Security

• The “big I” Internet Is federated:• Policies must be enforced across realms (e.g.,

DDoS)

• NEBULA addresses problems at right places:• Extensibility+Policy: new control plane• Policy Enforcement: new data plane• Availability: high-performance, redundant-path

core with high availability core routers‐ 35

NDP

36

NEBULA Virtual and Extensible Network Techniques (NVENT)

37

NEBULA Core (NCore)

38

XIA VisionWe 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

39

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!

Src: Client IP

Dest: Server IP

Client IPServer IP

TCP

40

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

Src: Client ID

Dest: Content ID

PDA

Content

41

A Bit More Detail …

Hash( ) = CID?

Anywhere

Dest: Client ID

Content ID

Dest: Service ID

Content Name?

Dest: Content ID

Flexible TrustManagement

DiverseCommunicating

Entities

IntrinsicSecurity

XIA Transformational Ideas

42

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

43Host

Content

Services

FutureEntities

a581fe9 ...

d9389fa …

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

44Host

Content

Services

FutureEntities

a581fe9 ...

d9389fa …

024e881 …39c0348 …

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

45

Declaration of Independence

TrustManagement

043e49af3890dd327134389a90cd2199

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

46

IP: Evolvability of:

Applications

Link technologies

XIA adds evolvabilityat the waist:

Applications

Evolvingset of principals

Link technologies

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

47

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

48

Net

wor

k-N

etw

ork

Use

r-Net

wor

k

XIA Components and Interactions

eXpressive Internet Protocol

HostSupport

ContentSupport

ServicesSupport

…

Applications

Users

Services

IntrinsicSecurity

49

Trus

twor

thy

Net

wor

k O

pera

tion

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 50