Upload
kirti
View
34
Download
0
Embed Size (px)
DESCRIPTION
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) - PowerPoint PPT Presentation
Citation preview
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