cs 268 lecture 24 internet architectures i3 doa hip n.
Download
Skip this Video
Loading SlideShow in 5 Seconds..
CS 268: Lecture 24 Internet Architectures: i3, DOA, HIP,… PowerPoint Presentation
Download Presentation
CS 268: Lecture 24 Internet Architectures: i3, DOA, HIP,…

Loading in 2 Seconds...

play fullscreen
1 / 60

CS 268: Lecture 24 Internet Architectures: i3, DOA, HIP,… - PowerPoint PPT Presentation


  • 124 Views
  • Uploaded on

CS 268: Lecture 24 Internet Architectures: i3, DOA, HIP,…. Scott Shenker and Ion Stoica Computer Science Division Department of Electrical Engineering and Computer Sciences University of California, Berkeley Berkeley, CA 94720-1776. Outline. Internet Indirection Infrastructure (i3)

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'CS 268: Lecture 24 Internet Architectures: i3, DOA, HIP,…' - kirti


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
cs 268 lecture 24 internet architectures i3 doa hip

CS 268: Lecture 24Internet Architectures: i3, DOA, HIP,…

Scott Shenker and Ion Stoica

Computer Science Division

Department of Electrical Engineering and Computer Sciences

University of California, Berkeley

Berkeley, CA 94720-1776

outline
Outline
  • Internet Indirection Infrastructure (i3)
  • Design comparison
    • Host Identity Protocol
    • i3
    • Semantic Free References (SFR)
    • Delegation Oriented Architecture (DOA)
  • Another view of indirection/delegation
motivations
Motivations
  • Today’s Internet is built around a unicast point-to-point communication abstraction:
    • Send packet “p” from host “A” to host “B”
  • This abstraction allows Internet to be highly scalable and efficient, but…
  • … not appropriate for applications that require other communications primitives:
    • Multicast
    • Anycast
    • Mobility
    • Service composition (Middleboxes)
slide4
Why?
  • Point-to-point communication  implicitly assumes there is one sender and one receiver, and that they are placed at fixed and well-known locations
    • E.g., a host identified by the IP address 128.32.xxx.xxx is located in Berkeley
ip solutions
IP Solutions
  • Extend IP to support new communication primitives, e.g.,
    • Mobile IP
    • IP multicast
    • IP anycast
  • Disadvantages:
    • Difficult to implement while maintaining Internet’s scalability (e.g., multicast)
    • Require community wide consensus -- hard to achieve in practice
application level solutions
Application Level Solutions
  • Implement the required functionality at the application level, e.g.,
    • Application level multicast (e.g., Fastforward, Narada, Overcast, Scattercast…)
    • Application level mobility
  • Disadvantages:
    • Efficiency hard to achieve
    • Redundancy: each application implements the same functionality over and over again
    • No synergy: each application implements usually only one service; services hard to combine
key observation

“Any problem in computer science can

be solved by adding a layer of indirection”

Key Observation
  • Virtually all previous proposals use indirection!
indirection is everywhere

DNS Server

Home Agent

“foo.org”

(IPhome,data)

foo.org IPfoo

IPhome IPmobile

IPfoo

(IPmobile,data)

(IPdst:Pdst,data)

(IPfoot,data)

IPfoo

IPmofile

DNS

Mobile IP

NAT Box

(IPM,data)

(IPnat:Pnat,data)

IPnat:Pnat IPdst:Pdst

Internet

(IPMIPR1)

(IPMIPR2)

(IPR2,data)

(IPR1,data)

IPdst

IPR2

IPR1

NAT

IP Multicast

Indirection is Everywhere!
internet indirection infrastructure i3

Application

Build an efficient indirection layer

on top of IP

Indir.

layer

TCP/UDP

IP

Internet Indirection Infrastructure (i3)
  • Use an overlay network to implement this layer
    • Incrementally deployable; don’t need to change IP
internet indirection infrastructure i31

trigger

data

data

data

id

id

R

id

R

Internet Indirection Infrastructure (i3)
  • Each packet is associated an identifier id
  • To receive a packet with identifier id, receiver R maintains a trigger (id, R) into the overlay network

Sender

Receiver (R)

service model
Service Model
  • API
    • sendPacket(p);
    • insertTrigger(t);
    • removeTrigger(t) // optional
  • Best-effort service model (like IP)
  • Triggers periodically refreshed by end-hosts
  • ID length: 256 bits
mobility

Receiver

(R1)

id

id

R1

R2

Receiver

(R2)

Mobility
  • Host just needs to update its trigger as it moves from one subnet to another

Sender

multicast

data

data

data

data

R2

R1

id

id

Multicast
  • Receivers insert triggers with same identifier
  • Can dynamically switch between multicast and unicast

id

R1

Receiver (R1)

Sender

id

R2

Receiver (R2)

anycast

p|a

data

p|a

data

data

R1

Anycast
  • Use longest prefix matching instead of exact matching
    • Prefix p: anycast group identifier
    • Suffix si: encode application semantics, e.g., location

Receiver (R1)

R1

p|s1

R2

p|s2

Sender

Receiver (R2)

R3

p|s3

Receiver (R3)

service composition sender initiated

idT,id

T,id

data

data

data

data

id

R

idT,id

data

Service Composition: Sender Initiated
  • Use a stack of IDs to encode sequence of operations to be performed on data path
  • Advantages
    • Don’t need to configure path
    • Load balancing and robustness easy to achieve

Transcoder (T)

Receiver (R)

Sender

id

R

T

idT

service composition receiver initiated

id

data

idF,R

F,R

id

data

data

data

data

R

Service Composition: Receiver Initiated
  • Receiver can also specify the operations to be performed on data

Firewall (F)

Receiver (R)

F

Sender

idF

id

idF,R

outline1
Outline
  • Implementation
  • Examples
  • Security
  • Architecture Optimizations
  • Applications
quick implementation overview
Quick Implementation Overview
  • i3 is implemented on top of Chord
  • Each trigger t =(id, R) is stored on the node responsible for id
  • Use Chord recursive routing to find best matching trigger for packet p = (id, data)
routing example

send(37, data)

37

R

trigger(37,R)

send(R, data)

Routing Example
  • R inserts trigger t = (37, R); S sends packet p = (37, data)
  • An end-host needs to know only one i3 node to use i3
    • E.g., S knows node 3, R knows node 35

S

0

2m-1

S

3

20

7

7

Chord circle

3

35

41

41

20

37

R

35

R

R

optimization 1 path length

37

R

data

data

37

R

cache node

Optimization #1: Path Length
  • Sender/receiver caches i3 node mapping a specific ID
  • Subsequent packets are sent via one i3 node

[8..20]

[4..7]

[42..3]

[21..35]

Sender (S)

[36..41]

Receiver (R)

optimization 2 triangular routing

37

30

R

R

data

data

[2]

[2]

2

30

37

R

R

S

S

2

[30]

[30]

Optimization #2: Triangular Routing
  • Use well-known trigger for initial rendezvous
  • Exchange a pair of (private) triggers well-located
  • Use private triggers to send data traffic

[8..20]

[4..7]

[42..3]

[21..35]

Sender (S)

[36..41]

Receiver (R)

outline2
Outline
  • Implementation
  • Examples
    • Heterogeneous multicast
    • Scalable Multicast
    • Load balancing
    • Proximity
example 1 heterogeneous multicast

send(R2, data)

id

R2

Receiver R2

(MPEG)

Example 1: Heterogeneous Multicast
  • Sender not aware of transformations

S_MPEG/JPEG

send(R1, data)

send(id, data)

Receiver R1

(JPEG)

Sender

(MPEG)

S_MPEG/JPEG

id_MPEG/JPEG

send((id_MPEG/JPEG, R1), data)

id

(id_MPEG/JPEG, R1)

example 2 scalable multicast

(g, data)

g

x

g

R1

g

R2

R2

(x, data)

x

R3

x

R4

R1

R3

R4

Example 2: Scalable Multicast
  • i3 doesn’t provide direct support for scalable multicast
    • Triggers with same identifier are mapped onto the same i3 node
  • Solution: have end-hosts build an hierarchy of trigger of bounded degree
example 2 scalable multicast discussion
Example 2: Scalable Multicast (Discussion)

Unlike IP multicast, i3

  • Implement only small scale replication  allow infrastructure to remain simple, robust, and scalable
  • Gives end-hosts control on routing  enable end-hosts to
    • Achieve scalability, and
    • Optimize tree construction to match their needs, e.g., delay, bandwidth
example 3 load balancing
Example 3: Load Balancing
  • Servers insert triggers with IDs that have random suffixes
  • Clients send packets with IDs that have random suffixes

send(1010 0110,data)

S1

1010 0010

S1

A

S2

1010 0101

S2

1010 1010

S3

S3

send(1010 1110,data)

1010 1101

S4

S4

B

example 4 proximity
Example 4: Proximity
  • Suffixes of trigger and packet IDs encode the server and client locations

S2

S3

S1

send(1000 0011,data)

1000 1010

S2

S3

1000 1101

1000 0010

S1

example 5 protection against dos attacks
Example 5: Protection against DOS Attacks
  • Problem scenario: attacker floods the incoming link of the victim
  • Solution: stop attacking traffic before it arrives at the incoming link
    • Today: call the ISP to stop the traffic, and hope for the best!
  • Approach: give end-host control on what packets they receive
    • Enable end-hosts to stop the attacks in the network
example 5 why end hosts and not network
Example 5: Why End-Hosts (and not Network)?
  • End-hosts can better react to an attack
    • Aware of semantics of traffic they receive
    • Know what traffic they want to protect
  • End-hosts may be in a better position to detect an attack
    • Flash-crowd vs. DoS
example 5 some useful defenses
Example 5: Some Useful Defenses
  • White-listing: avoid receiving packets on arbitrary ports
  • Traffic isolation:
    • Contain the traffic of an application under attack
    • Protect the traffic of established connections
  • Throttling new connections: control the rate at which new connections are opened (per sender)
example 5 1 white listing

IDR

R

R

[IDS]

data

data

IDP

[IDS]

IDS

IDP

IDR

S

R

R

IDS

S

[IDR]

[IDR]

Example 5: (1) White-listing
  • Packets not addressed to open ports are dropped in the network
    • Create a public trigger for each port in the white list
    • Allocate a private trigger for each new connection

Sender (S)

Receiver (R)

IDP – public trigger IDS, IDR – private triggers

example 5 2 traffic isolation

ID1

V

Legitimate client

(C)

ID2

V

Web server

Attacker

(A)

Example 5: (2) Traffic Isolation
  • Drop triggers being flooded without affecting other triggers
    • Protect ongoing connections from new connection requests
    • Protect a service from an attack on another services

Transaction server

Victim (V)

example 5 2 traffic isolation1

ID1

V

Legitimate client

(C)

Web server

Attacker

(A)

Example 5: (2) Traffic Isolation
  • Drop triggers being flooded without affecting other triggers
    • Protect ongoing connections from new connection requests
    • Protect a service from an attack on another services

Transaction server

Victim (V)

Traffic of transaction server

protected from attack on web server

example 5 3 throttling new connections

Gatekeeper (A)

puzzle

Server (S)

Client (C)

puzzle’s solution

Example 5: (3) Throttling New Connections
  • Redirect new connection requests to a gatekeeper
    • Gatekeeper has more resources than victim
    • Can be provided as a 3rd party service

IDC

C

X

S

A

IDP

outline3
Outline
  • Internet Indirection Infrastructure (i3)
  • Design comparison
    • Host Identity Protocol
    • i3
    • Semantic Free References (SFR)
    • Delegation Oriented Architecture (DOA)
  • Another view of indirection/delegation
host identity protocol hip
Host Identity Protocol (HIP)
  • Provides:
    • Fast mobility
    • Multi-homing
    • Support for different addressing schemes
      • Transparent IPv4 to IPv6 migration
    • Security
      • Anonymity
      • Secure and authenticate datagrams
slide37
HIP
  • A public key used to identify an end-host
  • A 128-bit host identity tag (HIT) used for system calls
    • HIT is a hash on public key
    • Global scope
  • A 32-bit local scope identifier (LSI) for IPv4 compatibility

HIT replaces IP address as a name

of a system

protocol stack
Protocol Stack

Process

Process

Transport

Transport

<HIT, port>

<IPaddr, port>

HIP Layer

IP Layer

<IPaddr>

<HIT>

<IPaddr>

IP Layer

how it works

HIT

DNS request

DNS reply = pubkey (P)

send(HIT)

HIT=hash(P)

IPaddr

4-way authentication

send(HIT)

HIT

IPaddr, P

send(IPaddr)

send(IPaddr)

How It Works?

Client app

Client app

DNS

library

DNS

Transport

Transport

HIP

daemon

HIP

daemon

HIP Layer

HIP layer

IPsec

IPsec

outline4
Outline
  • Internet Indirection Infrastructure (i3)
  • Design comparison
    • Host Identity Protocol
    • i3
    • Semantic Free References (SFR)
    • Delegation Oriented Architecture (DOA)
  • Another view of indirection/delegation
i3 identifiers
i3 Identifiers
  • 256-bit IDs
  • ID maps to another ID or to an (IPaddr:Port)
    • (IPaddr:Port) points to an application layer de-multiplexer
  • ID can represent
    • A host, flow, service, etc

ID can identify any entity

protocol stack1
Protocol Stack

Process

local scope

Process

Transport

ID/<IPlocal, port>

Transport

<IPaddr, port>

i3 layer

(IPlocal->ID)

<ID>

IP Layer

<IPaddr>

<IPi3>

IP Layer

Sender specific

how it works1

DNS request

DNS reply = id

How It Works?

Receiver R

DNS

Client app

Client app

send(id)

Transport

Transport

i3

daemon

send(id)

i3 layer

i3 layer

send(IPi3)

send(id)

id

R

IPi3

IP

IP

outline5
Outline
  • Internet Indirection Infrastructure (i3)
  • Design comparison
    • Host Identity Protocol
    • i3
    • Semantic Free References (SFR)
    • Delegation Oriented Architecture (DOA)
  • Another view of indirection/delegation
goal address dns limitations
Goal: Address DNS Limitations
  • DNS names identify machines and organizations not data
    • Data cannot be easily moved
    • Data cannot be easily replicated
  • DNS names are brand names
    • Political fighting
sfr solution
SFR Solution
  • Use IDs instead of DNS name
  • ID space is flat and IDs have no semantics
  • A generalization of DNS
    • Returns metadata instead of an IP address
  • How to implement it?
    • Use distributed hash-tables (DHTs)
outline6
Outline
  • Internet Indirection Infrastructure (i3)
  • Design comparison
    • Host Identity Protocol
    • i3
    • Semantic Free References (SFR)
    • Delegation Oriented Architecture (DOA)
  • Another view of indirection/delegation
delegation oriented architecture doa
Delegation Oriented Architecture (DOA)
  • Supports:
    • Mobility
    • Multi-homing
  • Integrate middle-boxes
  • Security (through middle-boxes)
    • Anonymity
    • DoS
an old naming taxonomy
An Old Naming Taxonomy
  • Four kinds of network entities (Saltzer):
    • Services (and data)
    • Hosts (endpoints)
    • Network attachment points
    • Paths
  • Should name each individually:
    • Ignore paths (router involvement)
    • IP addresses name attachment points
    • Endpoint identifiers (EIDs) name hosts
    • Service identifiers (SIDs) name services/data
protocol stack2
Protocol Stack

Process

Process

SID↔EID

<SID>

Transport

Transport

<EID, port>

<IPaddr, port>

EID↔IP

IP Layer

<IPaddr>

<EID>

<IPaddr>

IP Layer

how it works2

DNS request

DNS reply = sid

send(sid)

eim = get(sid)

put(sid, eim)

put(eid, IP)

send(eim)

IP = get(eim)

How It Works?

“DNS”

Client app

Client app

SID↔EID

SID↔EID

DOA

daemon

DHT

Transport

Transport

put(eim, IPm)

send(eim)

EID↔IP

EID↔IP

Middlebox (IPm)

send(IPm)

IP

IP

principles
Principles
  • Don’t bind to lower-level IDs prematurely
    • Host mobility and renumbering (HIP)
    • Service and data migration
  • Resolution of name need not point to object itself, but can point to its delegate
    • Resolution can point to intermediaries who process packets on behalf of the named target
naming indirection architecture requirements
Naming (Indirection) Architecture Requirements
  • There should be a layer in the protocol stack that uses IDs not IP addresses
    • Mobility, multi-homing, replications, …
  • IDs should be able to name arbitrary objects
  • IDs should encode as little semantics as possible
  • End-points should be able to use indirection at the ID level
    • Integrate middle boxes
how many id layers
How Many ID Layers?
  • HIP: one layer; IDs identify machines
  • SFR: one layer; IDs identify data
  • i3: one layer; IDs identify arbitrary objects
  • DOA: two layers
    • EIDs identify machines
    • SIDs identify everything else
where is the resolution id ip done
Where is the Resolution IDIP Done?
  • SFR: above transport
  • HIP: below transport, at HIP layer
  • i3: in the infrastructure
  • DOA: above & below transport
    • But IP address can be an intermediate point
security support
Security Support?
  • HIP:
    • Authentication, data integrity
    • Anonymity at transport layer
    • Transport layer resistance to DoS attacks
  • i3
    • Anonymity at IP layer
    • Some DoS defense at IP layer
    • Everything else can be done though middle-boxes
  • DOA
    • Everything can be done through middle-boxes
outline7
Outline
  • Internet Indirection Infrastructure (i3)
  • Design comparison
    • Host Identity Protocol
    • i3
    • Semantic Free References (SFR)
    • Delegation Oriented Architecture (DOA)
  • Another view of indirection/delegation
another view of indirection delegation
Another View of Indirection/Delegation
  • Indirection point point wherecontrol is transferred from sender to receiver
    • Translation/forwarding entry usually controlled by receiver
end host empowerment
End-host Empowerment
  • Both the sender and receiver are able to explicitly control the service-path
    • Note: multiple indirection points possible

Internet

Middlebox 1

(M1)

M2

M3

M4

Receiver

Indirection point

(tussle boundary)

Sender

sender control

receiver control

realization i3 vs doa

M2

M1

([idS1,idR], data)

i3

idM2 S2

idM1 M1

R

Internet

i3

Name resolution infrastructure (e.g., OpenDHT)

idM2 M2

idS1

idM1 M1

idR R

S1

idS2

R

idR

S2

([idS1,idS2], data)

idM2 idR

R

idR [idM2,R]

M1

M2

Internet

DOA

Realization: i3 vs DOA