Scott Shenker and Ion StoicaComputer Science Division

Department of Electrical Engineering and Computer SciencesUniversity of California, Berkeley

Berkeley, CA 94720-1776

CS 268: Lecture 24Internet

Architectures: i3, DOA, HIP,…

2

Outline

Internet Indirection Infrastructure (i3)• Design comparison

– Host Identity Protocol– i3– Semantic Free References (SFR)– Delegation Oriented Architecture (DOA)

• Another view of indirection/delegation

3

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)– …

4

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

5

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

6

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

7

Key Observation

• Virtually all previous proposals use indirection!

“Any problem in computer science can be solved by adding a layer of indirection”

8

Indirection is Everywhere!

“foo.org”

IPfoo

DNS Server

foo.org IPfoo

IPfooDNS

(IPhome,data)

Home Agent

IPhome IPmobile

(IPmobile,data)

IPmofileMobile IP

(IPnat:Pnat,data)NAT Box

IPnat:Pnat IPdst:Pdst

(IPdst:Pdst,data)

IPdst

NAT

Internet(IPMIPR1)(IPMIPR2)

(IPM,data)

(IPR1,data)(IPR2,data)

IPR1IPR2

IP Multicast

(IPfoot,data)

9

Internet Indirection Infrastructure (i3)

• Use an overlay network to implement this layer– Incrementally deployable; don’t need to change IP

Build an efficient indirection layer

on top of IP

IP

TCP/UDP

Application

Indir.layer

10

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

id Rtrigger

iddata

Receiver (R)

iddata

Rdata

11

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

12

Mobility

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

Sender

Receiver(R1)

Receiver(R2)

id R1id R2

13

iddata

Multicast

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

and unicast

Receiver (R1)id R1

Receiver (R2)

id R2

Sender

R1data

R2data

iddata

14

Anycast

• Use longest prefix matching instead of exact matching– Prefix p: anycast group identifier

– Suffix si: encode application semantics, e.g., location

Sender

Receiver (R1)p|s1 R1

Receiver (R2)p|s2 R2

p|s3 R3

Receiver (R3)

R1datap|adata p|adata

15

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

SenderReceiver (R)

idT Tid R

Transcoder (T)

T,iddata

iddata

Rdata

idT,iddata idT,iddata

16

Service Composition: Receiver Initiated

• Receiver can also specify the operations to be performed on data

Receiver (R)

id idF,R

Firewall (F)

Sender idF F

idF,Rdata

Rdata

F,Rdata

iddata iddata

17

Outline

Implementation• Examples• Security• Architecture Optimizations• Applications

18

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)

19

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

3

7

20

35

41

37 R

3

7

20

3541

37 R

S

R

trigger(37,R)

send(37, data)

send(R, data)

Chord circle

S

R

02m-1

20

Sender (S)

Optimization #1: Path Length

• Sender/receiver caches i3 node mapping a specific ID

• Subsequent packets are sent via one i3 node

[42..3]

[4..7]

[8..20]

[21..35][36..41]

37 R

37data

Rdatacache node Receiver (R)

21

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

[42..3]

[4..7]

[8..20]

[21..35][36..41]

37 RR[2]

2 S37[2]

2 [30]30 R

S [30]30data

Rdata

Receiver (R)

Sender (S)

22

Outline

• ImplementationExamples

– Heterogeneous multicast– Scalable Multicast– Load balancing– Proximity

23

Example 1: Heterogeneous Multicast

• Sender not aware of transformations

Receiver R1(JPEG)

id_MPEG/JPEG S_MPEG/JPEG

id (id_MPEG/JPEG, R1)

send(id, data)

S_MPEG/JPEG

Sender(MPEG)

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

send(R1, data)

id R2

Receiver R2(MPEG)

send(R2, data)

24

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

R2

R1

R4R3

g R2

g R1

gx

x R4

x R3

(g, data)

(x, data)

25

Example 2: Scalable Multicast (Discussion)

Unlike IP multicast, i31. Implement only small scale replication

allow infrastructure to remain simple, robust, and scalable

2. Gives end-hosts control on routing enable end-hosts to – Achieve scalability, and– Optimize tree construction to match their needs,

e.g., delay, bandwidth

26

Example 3: Load Balancing

• Servers insert triggers with IDs that have random suffixes• Clients send packets with IDs that have random suffixes

S1

1010 0101 S2

1010 1010 S3

1010 1101 S4

S1

S2

S3

S4

A

B

send(1010 0110,data)

send(1010 1110,data)

1010 0010

27

Example 4: Proximity

• Suffixes of trigger and packet IDs encode the server and client locations

1000 0010 S1

1000 1010 S21000 1101 S3

S1

S2S3

send(1000 0011,data)

28

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

29

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

30

Example 5: Some Useful Defenses

1. White-listing: avoid receiving packets on arbitrary ports

2. Traffic isolation:– Contain the traffic of an application under

attack– Protect the traffic of established connections

3. Throttling new connections: control the rate at which new connections are opened (per sender)

31

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

IDS S

Sender (S)

Receiver (R)

S [IDR]

IDS [IDR]IDR

RRdata

IDPR

R[IDS]

IDP[IDS] IDR data

IDP – public trigger IDS, IDR – private triggersIDP – public trigger IDS, IDR – private triggers

32

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

Victim (V)

Attacker(A)

Legitimate client(C)

ID2V

ID1 V

Transaction server

Web server

33

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

Victim (V)

Attacker(A)

Legitimate client(C)

ID1 V

Transaction server

Web server

Traffic of transaction serverprotected from attack on web server

Traffic of transaction serverprotected from attack on web server

34

Server (S)Client (C)

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

puzzle

puzzle’s solution

Gatekeeper (A)

IDPA

35

Outline

• Internet Indirection Infrastructure (i3)Design comparison

Host Identity Protocol– i3– Semantic Free References (SFR)– Delegation Oriented Architecture (DOA)

• Another view of indirection/delegation

36

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

37

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

HIT replaces IP address as a name of a system

38

Protocol Stack

Process

Transport

IP Layer

<IPaddr, port>

<IPaddr>

Process

Transport

HIP Layer

IP Layer

<HIT, port>

<IPaddr>

<HIT>

39

HIT

How It Works?

Client app

HIP layer

IPsec

HIPdaemon

DNSlibrary

DNSDNS request

DNS reply =

pubkey (P)

HIT=hash(P)IPaddr

Client app

HIP Layer

IPsec

HIPdaemon

4-way authenticationTransport

HIT

IPaddr, P

send(HIT)

send(HIT)

send(IPaddr)

send(IPaddr)

Transport

40

Outline

• Internet Indirection Infrastructure (i3)Design comparison

– Host Identity Protocol i3– Semantic Free References (SFR)– Delegation Oriented Architecture (DOA)

• Another view of indirection/delegation

41

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 entityID can identify any entity

42

Sender specific

Protocol Stack

Process

Transport

IP Layer

<IPaddr, port>

<IPaddr>

Process

Transport

i3 layer(IPlocal->ID)

IP Layer

ID/<IPlocal, port>

<IPi3>

<ID>

local scope

43

How It Works?

Client app

i3 layer

DNSDNS request

DNS reply = id

send(IPi3)

Client app

i3 layer

IPIP

Transport

id RIPi3

Receiver R

send(id)

Transportsend(id)

send(id)

i3daemon

44

Outline

• Internet Indirection Infrastructure (i3)Design comparison

– Host Identity Protocol– i3Semantic Free References (SFR)– Delegation Oriented Architecture (DOA)

• Another view of indirection/delegation

45

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

46

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)

47

Outline

• Internet Indirection Infrastructure (i3)Design comparison

– Host Identity Protocol– i3– Semantic Free References (SFR)Delegation Oriented Architecture (DOA)

• Another view of indirection/delegation

48

Delegation Oriented Architecture (DOA)

• Supports:– Mobility– Multi-homing

• Integrate middle-boxes• Security (through middle-boxes)

– Anonymity– DoS– …

49

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

50

Protocol Stack

Process

Transport

IP Layer

<IPaddr, port>

<IPaddr>

Process

Transport

EID↔IP

IP Layer

<EID, port>

<IPaddr>

<EID>

SID↔EID <SID>

51

How It Works?

Client app “DNS”DNS request

DNS reply = sid

send(IPm)

Client app

DOAdaemon

IP

Transport

send(sid)

DHTeim = get(sid)

SID↔EID

send(eim)

EID↔IP

send(eim) IP = get(eim)

put(sid, eim)put(eid, IP)

IP

Transport

SID↔EID

EID↔IPMiddlebox (IPm)

put(eim, IPm)

52

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

53

Naming (Indirection) Architecture Requirements

1) There should be a layer in the protocol stack that uses IDs not IP addresses• Mobility, multi-homing, replications, …

2) IDs should be able to name arbitrary objects

3) IDs should encode as little semantics as possible

4) End-points should be able to use indirection at the ID level• Integrate middle boxes

54

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

55

Where is the Resolution IDIP 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

56

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

57

Outline

• Internet Indirection Infrastructure (i3)• Design comparison

– Host Identity Protocol– i3– Semantic Free References (SFR)– Delegation Oriented Architecture (DOA)

Another view of indirection/delegation

58

Another View of Indirection/Delegation

• Indirection point point where control is transferred from sender to receiver – Translation/forwarding entry usually

controlled by receiver

59

End-host Empowerment

• Both the sender and receiver are able to explicitly control the service-path – Note: multiple indirection points possible

Internet

ReceiverIndirection point(tussle boundary)Sender

Middlebox 1 (M1)

M2 M3 M4

sender control receiver control

60

Realization: i3 vs DOA

Internet

i3

M1 M2

R

([idS1,idR], data)

idR [idM2,R]idM1 M1 idM2 S2

i3

Internet M1

R([idS1,idS2], data) idM2 idR

idM1 M1idM2 M2idS1

S1

M2

idS2

S2

idR R

idR

R

Name resolution infrastructure (e.g., OpenDHT)

DOA