Download ppt - Computer Science Division - University of California, Berkeley

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)
• Design comparison
–
–
–
–
Host Identity Protocol
i3
Semantic Free References (SFR)
Delegation Oriented Architecture (DOA)
• Another view of indirection/delegation
2
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)
…
3
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
4
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
5
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
6
Key Observation
• Virtually all previous proposals use indirection!
“Any problem in computer science can
be solved by adding a layer of indirection”
7
Indirection is Everywhere!
DNS Server
“foo.org”
Home Agent
(IPhome,data)
foo.org IPfoo
IPhome IPmobile
IPfoo
(IPmobile,data)
(IPfoot,data)
DNS
IPfoo
Mobile IP
NAT Box
(IPnat:Pnat,data)
(IPM,data)
IPnat:Pnat IPdst:Pdst
Internet
(IPMIPR1)
(IPMIPR2)
(IPdst:Pdst,data)
IPdst
NAT
IPmofile
(IPR2,data)
(IPR1,data)
IPR1
IP Multicast
IPR2
8
Internet Indirection Infrastructure (i3)
Build an efficient indirection layer
on top of IP
• Use an overlay network to implement this layer
– Incrementally deployable; don’t need to change IP
Application
Indir.
TCP/UDP
layer
IP
9
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
data id
Sender
Receiver (R)
data R
id R
trigger
10
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
11
Mobility
• Host just needs to update its trigger as it moves
from one subnet to another
Sender
id R2
R1
Receiver
(R1)
Receiver
(R2)
12
Multicast
• Receivers insert triggers with same identifier
• Can dynamically switch between multicast and
unicast
data id
Sender
data R1
id R1
Receiver (R1)
id R2
data R2
Receiver (R2)
13
Anycast
• Use longest prefix matching instead of exact
matching
– Prefix p: anycast group identifier
– Suffix si: encode application semantics, e.g., location
data p|a
Sender
data R1
p|s1 R1
p|s2 R2
Receiver (R1)
Receiver (R2)
p|s3 R3
Receiver (R3)
14
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)
data idT,id
Sender
data id
data T,id
idT T
data R
id R
Receiver (R)
15
Service Composition: Receiver
Initiated
• Receiver can also specify the operations to be
performed on data
data id
Sender
Firewall (F)
data R
data F,R
idF F
Receiver (R)
data idF,R
id idF,R
16
Outline
 Implementation
• Examples
• Security
• Architecture Optimizations
• Applications
17
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)
18
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
2m-1 0
S
3
send(37, data)
20
7
7
Chord circle
3
35
41
41
20
37 R
37 R
trigger(37,R)
35
send(R, data)
R
R
19
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]
data 37
[42..3]
Sender (S)
cache node
[21..35]
[36..41]
data R
37 R
Receiver (R)
20
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]
37
data
[2] 30
2 S
Sender (S)
[42..3]
S
[30]
[21..35]
[36..41]
[2] R
37 R
data
R
2
[30]
30 R
Receiver (R)
21
Outline
• Implementation
 Examples
–
–
–
–
Heterogeneous multicast
Scalable Multicast
Load balancing
Proximity
22
Example 1: Heterogeneous
Multicast
• Sender not aware of transformations
S_MPEG/JPEG
send(R1, data)
send(id, data)
id_MPEG/JPEG S_MPEG/JPEG
Sender
(MPEG)
Receiver R1
(JPEG)
send((id_MPEG/JPEG, R1), data)
id
(id_MPEG/JPEG, R1)
id
R2
send(R2, data)
Receiver R2
(MPEG)
23
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
(g, data)
g
x
g g
R1 R2
R2
(x, data)
x
R3
R3
x
R4
R1
R4
24
Example 2: Scalable Multicast
(Discussion)
Unlike IP multicast, i3
1. Implement only small scale replication  allow
infrastructure to remain simple, robust, and
scalable
2. Gives end-hosts control on routing  enable endhosts to
– Achieve scalability, and
– Optimize tree construction to match their needs, e.g.,
delay, bandwidth
25
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)
B
1010 1101 S4
S4
26
Example 4: Proximity
• Suffixes of trigger and packet IDs encode the
server and client locations
S2
S3
S1
send(1000 0011,data)
1000 0010
1000 1010 S2
1000 1101 S3
S1
27
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
28
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
29
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)
30
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
IDR
data
[ID
P
S] ID
IDS S
Sender (S)
S
[IDR]
[IDS] R
IDP R
IDP – public trigger
data
R
IDS [IDR]
IDR R
Receiver (R)
IDS, IDR – private triggers
31
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
Legitimate client
(C)
ID1 V
ID2 V
Victim (V)
Web server
Attacker
(A)
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
Transaction server
Legitimate client
(C)
ID1 V
Victim (V)
Web server
Attacker
(A)
Traffic of transaction server
protected from attack on web server
33
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
Gatekeeper (A)
IDC C
Client (C)
X S
Server (S)
IDP A
34
Outline
• Internet Indirection Infrastructure (i3)
 Design comparison
 Host Identity Protocol
– i3
– Semantic Free References (SFR)
– Delegation Oriented Architecture (DOA)
• Another view of indirection/delegation
35
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
36
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
37
Protocol Stack
Process
Process
Transport
<IPaddr, port>
Transport
IP Layer
<IPaddr>
HIP Layer
IP Layer
<HIT, port>
<HIT>
<IPaddr>
38
How It Works?
HIT
Client app
DNS
library
DNS
Client app
send(HIT)
HIT=hash(P)
IPaddr
4-way authentication
Transport
HIP
daemon
send(HIT)
HIT
HIP layer
Transport
HIP
daemon
HIP Layer
IPaddr, P
send(IPaddr)
IPsec
send(IPaddr)
IPsec
39
Outline
• Internet Indirection Infrastructure (i3)
 Design comparison
– Host Identity Protocol
 i3
– Semantic Free References (SFR)
– Delegation Oriented Architecture (DOA)
• Another view of indirection/delegation
40
i3 Identifiers
• 256-bit IDs
• ID maps to another ID or to an (IPaddr:Port)
– (IPaddr:Port) points to an application layer demultiplexer
• ID can represent
– A host, flow, service, etc
ID can identify any entity
41
Protocol Stack
Process
local scope
Process
Transport
Transport
IP Layer
ID/<IPlocal, port>
<IPaddr, port>
<IPaddr>
i3 layer
(IPlocal->ID)
IP Layer
<ID>
<IPi3>
Sender specific
42
How It Works?
Receiver R
DNS
Client app
Client app
send(id)
Transport
Transport
i3
daemon
send(id)
i3 layer
i3 layer
send(IPi3)
IP
IPi3
id R
send(id)
IP
43
Outline
• Internet Indirection Infrastructure (i3)
 Design comparison
– Host Identity Protocol
– i3
 Semantic Free References (SFR)
– Delegation Oriented Architecture (DOA)
• Another view of indirection/delegation
44
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
45
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)
46
Outline
• Internet Indirection Infrastructure (i3)
 Design comparison
– Host Identity Protocol
– i3
– Semantic Free References (SFR)
 Delegation Oriented Architecture (DOA)
• Another view of indirection/delegation
47
Delegation Oriented Architecture
(DOA)
• Supports:
– Mobility
– Multi-homing
• Integrate middle-boxes
• Security (through middle-boxes)
– Anonymity
– DoS
–…
48
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
49
Protocol Stack
Process
Process
Transport
<IPaddr, port>
IP Layer
<IPaddr>
SID↔EID
<SID>
Transport
<EID, port>
EID↔IP
<EID>
IP Layer
<IPaddr>
50
How It Works?
“DNS”
Client app
Client app
send(sid)
SID↔EID
eim = get(sid)
DHT
put(sid, eim)
put(eid, IP)
send(eim)
DOA
daemon
SID↔EID
Transport
Transport
put(eim, IPm)
send(eim)
EID↔IP
send(IPm)
IP
Middlebox (IPm)
EID↔IP
IP
51
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
52
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
53
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
54
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
55
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
56
Outline
• Internet Indirection Infrastructure (i3)
• Design comparison
–
–
–
–
Host Identity Protocol
i3
Semantic Free References (SFR)
Delegation Oriented Architecture (DOA)
 Another view of indirection/delegation
57
Another View of Indirection/Delegation
• Indirection point  point where control is
transferred from sender to receiver
– Translation/forwarding entry usually controlled by
receiver
58
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
59
Realization: i3 vs DOA
M2
M1
([idS1,idR], data)
i3
idM1 M1
idR [idM2,R]
idM2 S2
R
Internet
i3
Name resolution infrastructure (e.g., OpenDHT)
idS1
S1
idM1 M1
idR R
idS2
R
S2
([idS1,idS2], data)
idM2 M2
idR
idM2 idR
R
M1
DOA
Internet
M2
60