Outline The eXpressive Internet Architecture a proposal Example - - PDF document

outline
SMART_READER_LITE
LIVE PREVIEW

Outline The eXpressive Internet Architecture a proposal Example - - PDF document

6/29/2011 XIA: An Architecture for a Trustworthy and Evolvable Internet Peter Steenkiste Dave Andersen, David Eckhardt, Sara Kiesler, Jon Peha, Adrian Perrig, Srini Seshan, Marvin Sirbu, Hui Zhang Carnegie Mellon University Aditya Akella, University


slide-1
SLIDE 1

6/29/2011 1

XIA: An Architecture for a Trustworthy and Evolvable Internet

Peter Steenkiste Dave Andersen, David Eckhardt, Sara Kiesler, Jon Peha, Adrian Perrig, Srini Seshan, Marvin Sirbu, Hui Zhang Carnegie Mellon University Aditya Akella, University of Wisconsin John Byers Boston University

1

John Byers, Boston University

NGI Kaiserslautern, June 29, 2011

Outline

  • The eXpressive Internet Architecture – a proposal

E l d t – Example and concepts – Research thrusts

  • Tapa: supporting mobile users

– Concepts – Applications Tapa as an XIA transport – Tapa as an XIA transport

2

slide-2
SLIDE 2

6/29/2011 2

Network Architecture*

3

* As defined by Google

The Internet Architecture

host host

router router router

–Minimum functionality a network needs to implement to connect to the Internet

host

router router router email WWW phone... SMTP HTTP RTP... TCP UDP…

4

to implement to connect to the Internet

  • Forward packets across multiple networks

–Effectively the IP narrow waist

  • Minimalistic definition of architecture
  • All other functions needed are built on top

IP ethernet PPP… CSMA async sonet... copper fiber radio...

slide-3
SLIDE 3

6/29/2011 3

NSF Future Internet Architecture

  • Program focused on fundamental changes to the

Internet architecture

– Long‐term, multi‐phase effort

  • Four teams were selected in the second phase:

– Named Internet Architecture: content centric networking ‐ data is a first class entity – Mobility First: Mobility as the norm rather than the exception – generalizes delay tolerant networking – Nebula: Internet centered around cloud computing data centers that are well connected – eXpressive Internet Architecture: Focus on trustworthiness, evolvability

5

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 computing capabilities in the network and end‐points

  • Allows all actors to operate effectively

– Despite differences in roles, goals and incentives

6

slide-4
SLIDE 4

6/29/2011 4

Today’s Internet

Src: Client IP Dest: Server IP

  • Client retrieves document from a specific web server

– But client mostly cares about correctness of content timeliness

Client IP Server IP

TCP

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!

7

eXpressive Internet Architecture

Src: Client ID Dest: Content ID

  • Client expresses communication intent for content explicitly

– Network uses content identifier to retrieve content from appropriate

Dest: Content ID PDA Content

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

8

slide-5
SLIDE 5

6/29/2011 5

A Bit More Detail …

Dest: Service ID Content Name?

Flexible Trust Management

Dest: Client ID Content ID Dest: Content ID

Diverse Communicating Entities

Hash( ) = CID? Anywhere

Intrinsic Security

9

P1: Evolvable Set of Principals

  • Identifying the intended communicating

entities reduces complexity and overhead 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 ...

10

Host Services Future Entities

d9389fa … 024e881 … 39c0348 …

slide-6
SLIDE 6

6/29/2011 6

P2: Security as Intrinsic as Possible

  • Security properties are a direct result of the

design of the system g y

– Do not rely on correctness of external configurations, actions, data bases – Malicious actions can be easily identified

Content

a581fe9 ...

11

Host Services Future Entities

d9389fa … 024e881 … 39c0348 …

Other XIA Principles

  • Narrow waist for all principals

Defines the API between the principals and the network – Defines the API between the principals and the network protocol mechanisms

  • Narrow waist for trust management

– Ensure that the inputs to the intrinsically secure system match the trust assumptions and intensions of the user – Narrow waist allows leveraging diverse mechanisms for trust management: CAs, reputation, personal, …

  • All other network functions are explicit services

– XIA provides a principal type for services (visible) – Keeps the architecture simple and easy to reason about

12

slide-7
SLIDE 7

6/29/2011 7

XIA: eXpressive Internet Architecture

  • Each communication operation expresses the

intent of the operation 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 – Not a collection of architectures implemented through, e.g., virtualization or overlays – Not based on a “preferred” principal (host or content), that has to support all communication

13

What Applications Does XIA Support?

  • Since XIA supports host‐based communication,

today’s applications continue to work 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 – Explicit reliance on network services – Mobile users – As yet unknown usage models

14

slide-8
SLIDE 8

6/29/2011 8

What Do We Mean by Evolvability?

  • Narrow waist of the Internet has allowed the

network to evolve significantly network to evolve significantly

  • But need to evolve the waist as well!

– Can make the waist smarter

IP: Evolvability of: XIA adds evolvability at the waist: Applications

15 15

Applications Link technologies Applications Evolving set of principals Link technologies

XIA Components and Interactions

‐Network User‐Network Applications Users Services

Intrinsic Security

rthy Network Operation Network‐ eXpressive Internet Protocol Host Support Content Support Services Support …

y

16

Trustwor

slide-9
SLIDE 9

6/29/2011 9

How about the Real World?

Users User trust Policy and Economics Trust Management Network Operations Transparency Control Privacy Incentives Provider Relationships

17

Core Network Verifiable Actions Forwarding Trust Policy Control Points

Outline

  • Background

Th X i I t t A hit t l

  • The eXpressive Internet Architecture – a proposal

– Example and concepts – Research thrusts

  • XIA building blocks:

– AIP – Tapa

18

slide-10
SLIDE 10

6/29/2011 10

Developing XIA v0.1

  • Principles do not make a network!
  • Meet the core XIA team:

Fahad Dogar Ashok Anand Dongsu Han Hyeontaek Lim

Meet the core XIA team:

19

Boyan Li Michel Machadoy Wenfei Wu

  • Next: quick look at multiple principals,

intrinsic security, and evolvability

Five happy professors cheering: John Byers, Aditya Akella, Dave Anderson, Srini Seshan, Peter Steenkiste

Multiple Principal Types

  • Hosts XIDs support host‐based communication

similar to IP – who?

  • Service XIDs allow the network to route to

possibly replicated services – what does it do?

– LAN services access, WAN replication, …

  • Content XIDs allow network to retrieve content

from “anywhere” – what is it?

– Opportunistic caches, CDNs, …

  • Autonomous domains allow scoping, hierarchy
  • What are conditions for adding principal types?

20

slide-11
SLIDE 11

6/29/2011 11

Multiple Principal Types

Host HID SID CID Content Service Host HID SID Host HID

Choice involves tradeoffs:

  • Control
  • Efficiency
  • Trust
  • Privacy

CID Content CID Content CID Content CID Content CID SID

y y

21

Service SID CID Content CID CID CID Content CID Content CID Service SID

Intrinsic Security in XIA

  • XIA uses self‐certifying identifiers that guarantee

security properties for communication operation y p p p

– Host ID is a hash of its public key – accountability (AIP) – Content ID is a hash of the content – correctness – Does not rely on external configurations

  • Intrinsic security is specific to the principal type
  • Example: retrieve content using …

Example: retrieve content using …

– Content XID: content is correct – Service XID: the right service provided content – Host XID: content was delivered from right host

22

slide-12
SLIDE 12

6/29/2011 12

Example of Secure Mobile Service Access

Server S2: HIDS2 SIDBoF Register “bof.com”

  • > ADBOF:SIDBOF

ADBoF:HIDS:SIDBoF ADC:HIDC:SIDC XIA Internet ADBoF Server S: HIDS SIDBoF SIDBoF ADBoF:SIDBoF SIDBOF  S

X

2 ADBoF:HIDS2:SIDBoF ADC:HIDC:SIDC ADBoF:HIDS2:SIDBoF ADC2:HIDC:SIDC

23

SIDResolv ADC Name Resolution Service Client C: HIDC SIDC ADC2 Client C: HIDC SIDC bof.com  ADBOF:SIDBOF

Evolvability

  • Introduction of a new principal type will be

incremental – no “flag day”!

– Not all routers and ISPs will provide support from day one – No universal connectivity – Some ISPs may never support certain principal types

CID ….

  • Solution is to provide an

intent and fallback address

dd ll

AD:HID

24

– Intent address allows in‐ network optimizations based

  • n user intent

– Fallback address is guaranteed to be reachable

AD:HID …. Payload

slide-13
SLIDE 13

6/29/2011 13

Generalizing Evolvable Address Format

  • Use a directed acyclic graph to represent address

– Router traverses the DAG Router traverses the DAG – Priority among edges

f dd l

CID Intent

AD1 AD2 Fallback

  • DAG format supports many addressing styles

– Shortcut routing, binding, source routing, infrastructure evolution, .. – Common case: small dag, most routers look at one XID

25

Prototype Implementation

  • Click implementation of XIA router
  • Python API for sending/receiving packets
  • Python API for sending/receiving packets
  • Implemented a web service using XIA
  • User‐level version runs over ProtoGeni

Browser Browser XIA Proxy Host0 Router0 Router1 Host1 XIA Server

slide-14
SLIDE 14

6/29/2011 14

Simple Web Example

  • Web page with one

embedded image g

  • Three‐hop path hops

– 5ms/hop; gigabit links

300 350

http XIP - no cache XIP - cache

27

50 100 150 200 250 No Caching Caching No Fallback index.html CID only

  • Caching clearly helps
  • Sending initial page helps

(fast network)

  • Fallback avoids timeouts

Packet Processing

  • PP has principal dependent

and independent element

  • Processing costs seem

bl l ti t IP

28

manageable relative to IP

  • Fallbacks, source

processing add time

  • In software on desktop
slide-15
SLIDE 15

6/29/2011 15

Outline

  • Background

Th X i I t t A hit t l

  • The eXpressive Internet Architecture – a proposal

– Example and concepts – Research thrusts

  • XIA building blocks:

– AIP – Tapa

29

XIA Building Blocks

Tapa T t CA Perplexion R t ti Reduced synchr. Buffering/caching Tapa Trust Management Self-certifying Self-certifying content ids Redundancy Reputation Cell phones Physical g g Services E-E Semantics AIP DOT RE Self certifying host identifiers Intrinsic security Self certifying content ids Separate ctl, data access Appl-ind. content opt Redundancy Elimination Appl-ind. pervasive

30

slide-16
SLIDE 16

6/29/2011 16

The IP Abstraction Today

Fahad Dogar R R R R R

Can no longer hide differences!

31

R R

Wireless and Mobile Challenges

  • Increasing network heterogeneity

Decouple

Fahad Dogar

– Paths are no longer homogeneous

  • Heterogeneous devices, usage

– Relaxed end‐point synchronization

  • Diverse network services

C t t t i l bilit i

Leverage i k Decouple Heterogeneous Network Segments

– Content retrieval, mobility services

  • Topology control

– Handoff, multi‐path

32

in‐network functionality

slide-17
SLIDE 17

6/29/2011 17

Transfer Access Points

  • Tapa supports visible middleboxes (TAPs) that break

up end‐end connections in homogeneous segments

Segment Segment Segment Segment

up end end connections in homogeneous segments

  • Segments support best effort delivery of “chunks”

– Each segment can use custom solutions for congestion, flow, and error control – Chunks are self‐certifying (ADUs)

33

Unbundling the Transport Layer

Transfer Transport Transport

  • Transfer layer glues segments into e‐e path

– Kind of like IP but across segments not hops

Transfer Transfer Segment Segment Segment Segment

– Kind of like IP, but across segments, not hops – Naturally supports insertion of network services

  • Thin end‐to‐end transport supports e‐e semantics

– Also flow, error, congestion control across segment path – Must account for failures of TAPs, segment breaks, etc.

34

slide-18
SLIDE 18

6/29/2011 18

Tapa Prototype

  • Leverages Data‐Oriented Transport (DOT)

U lf tif i h k f d t – Uses self‐certifying chunks of data – Supports application‐independent caching

  • Uses diverse protocols for wireless segment

– TCP is convenient solution for wired backbone

  • End‐end transport intelligence is implemented

End end transport intelligence is implemented

  • n mobile host and TAP

– Vehicular communication – Catnap battery savings

35

Vehicular Example

Wired

  • Vehicle‐infrastructure suffers from frequent

interruptions, short periods of connectivity

  • Vehicle optimizes transfers by explicitly managing

server‐TAP and TAP‐vehicle transfers

– Leverages self‐certifying content identifiers

36

slide-19
SLIDE 19

6/29/2011 19

BW Discrepancy in typical end‐to‐end transfers

40 Mbps 3 Mbps

Wireless AP Client Server

3-5 Mbps 54 Mbps 40 Mbps

Idle period = 3.7ms – too small for PSM  0.3ms

3 Mbps

Packet Transmission Time = 4ms

Catnap leverages this opportunity to provide

37

p g pp y p up to 2‐5x energy savings during data transfers

Catnap Design Overview

Catnap Proxy Client Server

  • 1. Request
  • 2. Request
  • 1. Decoupling of Wired and Wireless Segments
  • 3. Response

HINT Data Data Scheduler

  • 5. Burst

Data

  • 4. Buffering

38

  • 2. ADU Hint ‐‐ Length of ADU
  • 3. Scheduler – Decides when to send data to client
slide-20
SLIDE 20

6/29/2011 20

How much can the NIC sleep?

TCP transfers remain in active state Transfer times do not increase with

Time (Sec)

Sleep time with Catnap increases as transfer size increases Catnap

39

Transfer Size

128kB 1MB 5MB

Tapa and XIA

  • Content‐centric optimizations in Tapa can be

h d “i t th t k” pushed “into the network”

– Tapa can use content XIDs rather than host XIDs – Old APs can be listed as hints (rather than server)

  • Tapa needs support from services on/near APs

– Simple “decoupling services” content Simple decoupling services , content

  • ptimization, Catnap, higher level services
  • Tapa benefits from intrinsic security properties

40

slide-21
SLIDE 21

6/29/2011 21

Conclusion

  • XIA supports evolution,

expressiveness, and trustworthy operation trustworthy operation.

– Multiple principal types and intrinsic security

  • But research has just started!

– Protocols that take advantage of in‐network caches and services – Trustworthy protocols that fully utilizes intrinsic security of XIA

  • More information on

http://www.cs.cmu.edu/~xia

41