Internet Indirection Infrastructure (i3) Status

1
Internet Indirection Infrastructure (i3) Status
Summer 03

• Ion Stoica
• UC Berkeley
• June 5, 2003

2
Collaborators

• Students
• Daniel Adkins
• Karthik Lakshminarayanan
• Ananth Rajagopala-Rao
• Sonesh Surana
• Shelley Zhuang
• Postdocs
• Kevin Lai

• Faculty
• Randy Katz
• Scott Shenker

3
What is i3?

• A highly efficient name-based routing implemented
  as an overlay network

IP router
i3 node
4
Communication Abstraction

• 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)
5
Service Model

• API
• sendPacket(p)
• insertTrigger(t)
• removeTrigger(t) // optional
• Best-effort service model (like IP)
• Triggers are periodically refreshed by end-hosts
• Reliability, congestion control, and flow-control
  implemented at end-hosts

6
What Does i3 Support?

• Mobility
• Multicast
• Anycast
• Service composition

7
Mobility

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

Receiver (R1)
Sender
id
R1
8
Mobility

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

send(R2, data)
Sender
id
R2
Receiver (R2)
9
Multicast

• Unifies multicast and unicast abstractions
• Multicast receivers insert triggers with the
  same identifier
• An application can dynamically switch between
  multicast and unicast

send(R1, data)
send(id,data)
Receiver (R1)
id
R1
Sender
id
R2
send(R2, data)
Receiver (R2)
10
Anycast

• Generalize the matching scheme used to forward a
  packet
• Until now we assumed exact matching
• Next, we assume
• Longest prefix matching (LPM) using a prefix
  larger than a predefined constant l to avoid
  collisions
• In the current implementation ID length, m
  256, l 128

11
Anycast (contd)

• Anycast is simply a byproduct of the new matching
  scheme, e.g.,
• Each receiver Ri in the anycast group inserts IDs
  with the same prefix p and a different suffix si

send(R1,data)
Receiver (R1)
ps1
R1
send(pa,data)
ps2
R2
Sender
Receiver (R2)
ps3
R3
Receiver (R3)
12
Service Composition

• Use a stack of IDs to encode the successions of
  operations to be performed on data
• Advantages
• Dont need to configure path
• Load balancing and robustness easy to achieve

S_MPEG/JPEG
Receiver R (JPEG)
Sender (MPEG)
id
R
id_MPEG/JPEG
S_MPEG/JPEG
13
What Weve Done Since Summer?

• Security (see Dans talk)
• Preliminary solution presented at last retreat
• Shared overlay infrastructure (see Karthiks
  talk)
• Robustness fast detection of i3 node failures
  (see Shelleys talk)
• Preliminary solution presented at last retreat

14
What Weve Done Since Summer?

• Security
• Shared overlay infrastructure
• Robustness

15
Security

• Develop a complete solution to protect against IP
  level denial of service attacks
• Show that a communication infrastructure can
  provide both more functionality and security than
  Internet

16
Design Principles

1. Hide IP address
2. Give end-hosts ability to stop the attack in the
   infrastructure
3. Make sure that proposed solution does not
   introduce new security vulnerabilities

17
1) Hide IP Address

• Enable end-hosts to communicate without revealing
  their IP address
• Otherwise, hosts are vulnerable to IP level
  flooding attacks
• i3 trivially implement this principle as data is
  exchanged via IDs not IP addresses

Sender
Receiver (R)
trigger
id
R
18
2) Enable End-hosts to Defend

• In general, end-hosts are in best position to
  detect when they are under attack
• E.g., flash-crowd vs. DoS, SYN attack
• Once an end-host detects an attack, it should be
  able to stop/redirect the offending traffic
  before it arrives at its inbound connection
• With i3 end-hosts can
• Stop traffic by removing the trigger under attack
• Route around a region of i3 under attack by
  moving triggers around
• Implement access control for multicast

19
Example Avoid Collateral Damage

• Two services shares the same connection to the
  Internet
• If one service is under attack, the user can save
  the other one (not possible in the Internet)

ATM server (S1)
idATM
S1
Customer (C)
Web server (S2)
idWEB
S
Bank Company
Attacker (A)
20
3) Avoid New Vulnerabilities

• Use light-weight techniques to
• Avoid cycles
• Confluences
• Eavesdropping
• Dead ends
• Properties
• Most of techniques involves only control plane ?
  no impact on data plane efficiency
• Minimal impact on i3 functionality

21
What Weve Done Since Summer?

• Security
• Shared overlay infrastructures
• Robustness

22
Shared Overlay Infrastructure

• Problem Todays overlay networks
• Mostly independent efforts
• Sharing happens mainly at the hardware level
  (e.g., Planetlab)
• Goal Propose a shared generic overlay
  infrastructure to support a variety of
  functionalities
• Solution Overlay architecture that exports only
  two primitives (implemented using i3)
• Path selection similar to source routing
• Packet replication

23
What Can We Do With These Primitives?

• Routing control
• Coarse grained data manipulation
• Measurements estimate performance between any
  two overlay nodes using only the two primitives
• RTT
• Unidirectional loss rate
• Available bandwidth
• Bottleneck capacity

24
Architecture
Client A
Network measurements
Query/reply routing info.
Setup routes
Client B
Client D
Client C
25
What Weve Done Since Summer?

• Security
• Shared overlay infrastructure
• Robustness

26
Robustness

• Use cooperative algorithms to reduce time to
  detect a node failure
• Same message overhead as a simple keep-alive alg.
• Can achieve recovery times on the order of a few
  RTTs
• Bottleneck in practice the time it takes to make
  sure that a node has failed with high probability

27
Conclusions

• Indirection, key primitive to support
• Basic communication abstractions, e.g.,
  multicast, anycast, mobility
• Improve end-host security
• This research advocates for
• Leaving IP do what is doing best point-to-point
  unicast communication
• Building an efficient Indirection Layer on top of
  IP
• Applications so far
• Mobility with support for legacy applications
• Large scale multicast
• Primitives for shared overlay infrastructure

28
Future Work

• Use i3 as a substrate for web services
• E.g., routing XML queries
• Multiple providers environment
• Economic model, policies