CS 268: Lecture 24 Internet Architectures: i3, DOA, HIP,

1
CS 268 Lecture 24Internet 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
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

• Todays 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
  Internets 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!

8
Indirection is Everywhere!
9
Internet Indirection Infrastructure (i3)

• Use an overlay network to implement this layer
• Incrementally deployable dont need to change IP

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
Receiver (R)
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
13
Multicast

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

id
R1
Receiver (R1)
Sender
id
R2
Receiver (R2)
14
Anycast

• Use longest prefix matching instead of exact
  matching
• Prefix p anycast group identifier
• Suffix si encode application semantics, e.g.,
  location

Receiver (R1)
R1
ps1
R2
ps2
Sender
Receiver (R2)
R3
ps3
Receiver (R3)
15
Service Composition Sender Initiated

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

Transcoder (T)
Receiver (R)
Sender
id
R
idT
T
16
Service Composition Receiver Initiated

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

Firewall (F)
Receiver (R)
Sender
idF
F
id
idF,R
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

S
0
2m-1
S
3
20
7
7
Chord circle
3
35
41
41
20
37
R
35
R
R
20
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
42..3
21..35
Sender (S)
36..41
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

8..20
4..7
42..3
21..35
Sender (S)
36..41
Receiver (R)
22
Outline

• Implementation
• Examples
• Heterogeneous multicast
• Scalable Multicast
• Load balancing
• Proximity

23
Example 1 Heterogeneous Multicast

• Sender not aware of transformations

S_MPEG/JPEG
send(R1, data)
send(id, data)
Receiver R1 (JPEG)
Sender (MPEG)
id_MPEG/JPEG
S_MPEG/JPEG
send((id_MPEG/JPEG, R1), data)
id
(id_MPEG/JPEG, R1)
24
Example 2 Scalable Multicast

• i3 doesnt 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

25
Example 2 Scalable Multicast (Discussion)

• Unlike IP multicast, i3
• Implement only small scale replication ? allow
  infrastructure to remain simple, robust, and
  scalable
• 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

send(1010 0110,data)
S1
1010 0010
S1
A
S2
1010 0101
S2
1010 1010
S3
S3
send(1010 1110,data)
1010 1101
S4
S4
B
27
Example 4 Proximity

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

S2
S3
S1
send(1000 0011,data)
1000 1010
S2
S3
1000 1101
1000 0010
S1
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

• White-listing avoid receiving packets on
  arbitrary ports
• Traffic isolation
• Contain the traffic of an application under
  attack
• Protect the traffic of established connections
• 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

Sender (S)
Receiver (R)
IDP 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

Transaction server
Victim (V)
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

Transaction server
Victim (V)
Traffic of transaction server protected from
attack on web server
34
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
A
IDP
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
38
Protocol Stack
Process
Process
Transport
Transport
ltHIT, portgt
ltIPaddr, portgt
HIP Layer
IP Layer
ltIPaddrgt
ltHITgt
ltIPaddrgt
IP Layer
39
How It Works?
Client app
Client app
DNS library
DNS
Transport
Transport
HIP daemon
HIP daemon
HIP Layer
HIP layer
IPsec
IPsec
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 (IPaddrPort)
• (IPaddrPort) points to an application layer
  de-multiplexer
• ID can represent
• A host, flow, service, etc

ID can identify any entity
42
Protocol Stack
Process
local scope
Process
Transport
ID/ltIPlocal, portgt
Transport
ltIPaddr, portgt
i3 layer (IPlocal-gtID)
ltIDgt
IP Layer
ltIPaddrgt
ltIPi3gt
IP Layer
Sender specific
43
How It Works?
Receiver R
DNS
Client app
Client app
send(id)
Transport
Transport
i3 daemon
send(id)
i3 layer
i3 layer
send(IPi3)
send(id)
id
R
IPi3
IP
IP
44
Outline

• Internet Indirection Infrastructure (i3)
• Design comparison
• Host Identity Protocol
• i3
• Semantic 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
Process
SID?EID
ltSIDgt
Transport
Transport
ltEID, portgt
ltIPaddr, portgt
EID?IP
IP Layer
ltIPaddrgt
ltEIDgt
ltIPaddrgt
IP Layer
51
How It Works?
DNS
Client app
Client app
SID?EID
SID?EID
DOA daemon
DHT
Transport
Transport
put(eim, IPm)
send(eim)
EID?IP
EID?IP
Middlebox (IPm)
send(IPm)
IP
IP
52
Principles

• Dont 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

• There should be a layer in the protocol stack
  that uses IDs not IP addresses
• Mobility, multi-homing, replications,
• IDs should be able to name arbitrary objects
• IDs should encode as little semantics as possible
• 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 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

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
Middlebox 1 (M1)
M2
M3
M4
Receiver
Indirection point (tussle boundary)
Sender
sender control
receiver control
60
Realization i3 vs DOA