Upload
sonel
View
20
Download
0
Embed Size (px)
DESCRIPTION
Internet Indirection Infrastructure. Ion Stoica UC Berkeley Nov 14, 2005. 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… - PowerPoint PPT Presentation
Citation preview
Internet Indirection Infrastructure
Ion StoicaUC BerkeleyNov 14, 2005
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– …
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., 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, e.g., – Physical indirection point mobile IP– Logical indirection point IP multicast
“Any problem in computer science can be solved by adding a layer of indirection”
7
Our Solution
• 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
8
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
9
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
10
Mobility
• Host just needs to update its trigger as it moves from one subnet to another
Sender
Receiver(R1)
Receiver(R2)
id R1id R2
11
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
12
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
13
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
14
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
15
Outline
Implementation• Examples• Security• Applications • Legacy application support
16
Quick Implementation Overview
• i3 is implemented on top of Chord– But can easily use CAN, Pastry, Tapestry,
etc
• 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)
17
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
37
20
35
41
37 R
S
R
trigger(37,R)
send(37, data)
send(R, data)
Chord circle
S
R
02m-1
[8..20]
[4..7]
[21..35]
[36..41]
[40..3]
18
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)
19
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)
20
Outline
• ImplementationExamples
– Heterogeneous multicast– Scalable Multicast– Load balancing– Proximity
• Security• Applications • Legacy application support
21
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)
22
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)
23
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
24
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
25
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)
26
Outline
• Implementation• ExamplesSecurity• Applications • Legacy applications support
27
Some Attacks
SRid R
Attacker (A)
id A
Eavesdropping
Attacker
id2 id3id1 id2
id4id3
id1id4
Loop
Victim(V)
id3
id3
id3
V Attacker id2 id2
id2
id2
id1 id3
Confluence
Attacker id2id1 id3id2
Dead-End
28
Constrained Triggers
• hl(), hr(): well-known one-way hash functions
• Use hl(), hr() to constrain trigger (x, y)
prefixprefix keykey
64 128 64
must match
ID: suffixsuffix
x y
x.key = hl(y)
x y
x.key = hl(y.key)
end-host address
Left constrained
x y
y.key = hr(x)
Right constrained
29
Attacks & Defenses
Triggerconstraints
Pushback Triggerchallenges
Public IDconstraints
Eavesdropping&Impersonation
Loops &Confluences
Dead-ends
Reflection &Malicious trigger-removal
Confluenceson i3 public nodes
AttackDefense
30
Outline
• Implementation• Examples• SecurityApplications
Protection against DoS attacks– Service composition platform
• Legacy application support
31
In a Nutshell
• 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!
• Our approach: give end-host control on what packets to receive– Enable end-hosts to stop the attacks in the
network
32
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
33
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)
34
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
35
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
36
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
37
Server (S)Client (C)
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
38
Outline
• Implementation• Examples• Security• Architecture OptimizationsApplications
– Protection against DoS attacksService composition platform
• Legacy application support
39
Service Composition
• Goal: allow third-parties and end-hosts to easily insert new functionality on data path– E.g., firewalls, NATs, caching, transcoding,
spam filtering, intrusion detection, etc..
• Why i3? – Make middle-boxes part of the architecture– Allow end-hosts/third-parties to explicitly route
through middle-boxes
40
Example
• Use Bro system to provide intrusion detection for end-hosts that desire so
M
client Aserver B
i3
Bro (middle-box)
idM MidBA B
idAB A
(idM:idBA, data)(idBA, data)
(idM:idAB, data)(idAB, data)
41
Outline
• Implementation• Examples• Security• Applications Legacy Application Support
42
The Problem
• New network architectures & overlays provide new features– RON : resilience to path failures– i3 : mobility, NAT traversal, anycast, multicast– …
• But still no widespread deployment
• How take advantage of new functionality?
• Enable popular applications (ssh, Firefox, IE) to benefit from new features
43
Solutions
• Approach 1: rewrite/port apps for each new overlay– time-consuming, tedious, impossible for
closed source apps
• Approach 2: enable support for legacy applications over multiple overlays
• We chose approach 2!
44
Overlay Convergence Architecture for Legacy Applications (OCALA)
Legacy Applications(ssh, firefox, explorer, …)
Legacy Applications(ssh, firefox, explorer, …)
Transport Layer(TCP, UDP, …)Transport Layer(TCP, UDP, …)
IP LayerIP Layer
Interpose an Overlay Convergence Layer between transport layer and overlay networks
Interpose an Overlay Convergence Layer between transport layer and overlay networks
45
Overlay Convergence Architecture for Legacy Applications (OCALA)
Overlay Convergence (OC) LayerOverlay Convergence (OC) Layer
Overlay(DOA, DTN, HIP, i3, RON, …)
Overlay(DOA, DTN, HIP, i3, RON, …)
Legacy Applications(ssh, firefox, explorer, …)
Legacy Applications(ssh, firefox, explorer, …)
Transport Layer(TCP, UDP, …)Transport Layer(TCP, UDP, …)
OC Independent (OC-I) Sublayer
OC Dependent (OC-D) Sublayer
Interpose an Overlay Convergence Layer between transport layer and overlay networks
Interpose an Overlay Convergence Layer between transport layer and overlay networks
46
Simultaneous access to multiple overlays
OC-IOC-I
i3
FirefoxFirefox
OC-IOC-I
RON
sshssh
www.cnn.comRON
IRCIRC sshssh
…
OC
-D
i3RON
Internet
…OC-IOC-I
i3
IRCIRC
…
Host A
Host B
Host C
IP
47
Which overlay to use?
• IP address and port number : – E.g.: Forward all packets sent to 128.32.132.223 port 22 over i3
• DNS name: – E.g.: Forward all packets sent to odu.edu.ron over RON (Resilient Overlay Networks)
– E.g.: Forward all packets sent to odu.edu.i3 over i3
48
Bridging Multiple Overlays
• Communication across overlays• Stitch together functionality
OC-I
Host A
Appl.
OC-I
Host C (foo.ron)
Appl.
OC-I
Host B (bar.i3)
i3
OC
-D
i3 RONi3 RON
RON
tunnel tunnel
path
49
Legacy Client Gateways – Demo
• Clients need not run OCALA locally• Gateway has special Legacy Client IP (LCIP)
module
OC-I
Appl.
OC-I
LCIP OV
Legacy gateway
i3Internet
Legacy Client
OV
Overlay server (dilip.i3)
DNSreq(ionhome.pli3.ocalaproxy.net)
50
Legacy Client Gateways – Demo
Access the following URL using your web browser:
http://ionhome.pli3.ocalaproxy.net:8000/ifconfig.html
51
Status
• i3 available as a service on Planetlab• OCALA available on Linux, Window/XP; enable
legacy applications to take advantage of– i3– RON– HIP (Host Identity Protocol) – …
• Current applications– Mobility – Transparent access to machines behind NATs– Secure and transparent access to services behind
firewalls
52
Conclusions
• Indirection – key technique to implement basic communication abstractions– Multicast, Anycast, Mobility, …
• Internet Indirection Infrastructure– Platform to deploy new services in the Internet– Highly flexible forwarding infrastructure: allows
end-hosts and third-parties to choose their own routes!
i3: http://i3.cs.berkeley.eduOCALA:
http://ocala.cs.berkeley.edu
i3: http://i3.cs.berkeley.eduOCALA:
http://ocala.cs.berkeley.edu
53
Other Architecture Optimizations
• Shortcuts: – Sender can cache receiver instead of an i3
server– Send subsequent packets directly to the
receiver
• Private trigger aggregation– Have all private triggers share the same
prefix– Insert only an anycast trigger with that
prefix in i3
54
Conclusions
• i3: tremendously flexible infrastructure– Allow end-hosts to control forwarding and
replication points in the infrastructure – Abstract away the behavior of hosts (e.g.,
mask mobility) form each other– Provide a global and flexible identifier space
• IDs can identify virtually anything, end-hosts, services, sessions, humans, devices, etc..
55
Enable Many Applications
• Access to machines behind NATs• Transparent access to
services/machines behind firewalls– Like VPNs but more secure and flexible
• Protection against DoS attacks• Anycast• Transparent switching between two
interfaces • …
56
Status
• Code publicly available: http://i3.cs.berkeley.edu– Supports Linux & Windows XP/2000 legacy
applications– Includes a light weight Chord
implementation
57
Private Trigger Aggregation (Problem)
• Each host maintains a private trigger in i3 for each other host it communicate with
• Too many private triggers – E.g., can reach 100 after browsing for 5 min!
• Every packet goes through an i3 server even if users don’t want this
A
B
C
D
idAB A
idAC A
idAD A
(idAB,data)
(idAC,data)
(idAD,data)
58
Private Trigger Aggregation (Solution)
• Chose all private triggers to have the same prefix A
• Keep only an anycast trigger with prefix A in infrastructure
A
B
C
D
idA*A
(idAC,data)
(idAD,data)
(idAB,data)
59
Private i3 Nodes (Problem)
• The resilience and truthworthiness of i3 infrastructure may not be good enough for various users– E.g., a company using i3 to provide
transparent and secure access for remote workers
60
Private i3 Nodes (Solution)
• Allow customers to add their i3 nodes to infrastructure using anycast and shortcuts
ACME Inc
idA* A
S
idAS A
(idAS, data)
cache
ACME i3 server
61
Service Composition: Research Questions
• How to locate and compose services?• How to distribute state across hosts and
middle-boxes?• How to transparently recover when a
middle-box fails? How is the state recovered?
62
Shortcuts (Problem)
• Each packet is traversing an i3 server no matter whether the user wants/needs to or not
63
Shortcuts (Solution)• Associate an “allow-caching” bit with both
packets and triggers• If both the packet and trigger have the bit set
sender can cache receiver’s address
LA LBidBA A1
Host A (IPB)Host B
3
1(idBA,data)
cache=IPB 2
64
Shortcuts: Discussion
• Shortcuts are allowed only if both the sender and receiver agree
• i3 used as a lookup infrastructure• Indirection still needed for
– Mobility– Symmetric NAT & Firewall traversal– Anonymity