Scott Shenker and Ion Stoica Computer Science Division Department of Electrical Engineering and Computer Sciences University of California, Berkeley Berkeley, CA CS 268: Lecture 24 Internet 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 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” IP foo DNS Server foo.org IP foo IP foo DNS (IP home,data) Home Agent IP home IP mobile (IP mobile,data) IP mofile Mobile IP (IP nat :P nat,data) NAT Box IP nat :P nat IP dst :P dst (IP dst :P dst,data) IP dst NAT Internet (IP M  IP R1 ) (IP M  IP R2 ) (IP M,data) (IP R1,data) (IP R2,data) IP R1 IP R2 IP Multicast (IP foot,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 idR trigger iddata Receiver (R) iddata 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 Receiver (R1) Receiver (R2) idR1 idR2

13 iddata Multicast Receivers insert triggers with same identifier Can dynamically switch between multicast and unicast Receiver (R1) idR1 Receiver (R2) idR2 Sender R1data R2data iddata

14 Anycast Use longest prefix matching instead of exact matching –Prefix p: anycast group identifier –Suffix s i : encode application semantics, e.g., location Sender Receiver (R1) p|s 1 R1 Receiver (R2) p|s 2 R2 p|s 3 R3 Receiver (R3) R1 data p|a data p|a data

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 Sender Receiver (R) id T T id R Transcoder (T) T,id data iddata R id T,id data id T,id data

16 Service Composition: Receiver Initiated Receiver can also specify the operations to be performed on data Receiver (R) id id F,R Firewall (F) Sender id F F id F,R data R F,R data id data id data

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 R R S R trigger(37,R) send(37, data) send(R, data) Chord circle S R 0 2 m-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] 37R data R cache 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] 37R R [2] 2S 37 [2] 2 [30] 30R S [30] 30 data R Receiver (R) Sender (S)

22 Outline Implementation  Examples –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 R2R2 R1R1 R4R4 R3R3 g R 2 g R 1 gxgx x R 4 x R 3 (g, data) (x, data)

25 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 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 S S S S4 S1 S2 S3 S4 A B send( ,data) send( ,data)

27 Example 4: Proximity Suffixes of trigger and packet IDs encode the server and client locations S S S3 S1 S2 S3 send( ,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 ID S S Sender (S) Receiver (R) S [ID R ] ID S [ID R ] ID R R R data ID P R R [ID S ] ID P [ID S ] ID R data ID P – public trigger ID S, ID R – 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) ID 2 V ID 1 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) ID 1 V Transaction server Web server Traffic of transaction server protected from attack on web server Traffic of transaction server protected 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 3 rd party service ID C C XS puzzle puzzle’s solution Gatekeeper (A) ID P A

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 Process Transport HIP Layer IP Layer

39 HIT How It Works? Client app HIP layer IPsec HIP daemon DNS library DNS DNS requestDNS reply = pubkey (P) HIT=hash(P) IPaddr Client app HIP Layer IPsec HIP daemon 4-way authentication Transport HIT IPaddr, Psend(HIT) 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 entity

42 Sender specific Protocol Stack Process Transport IP Layer Process Transport i3 layer (IPlocal->ID) IP Layer ID/ local scope

43 How It Works? Client app i3 layer DNS DNS requestDNS reply = id send(IPi3) Client app i3 layer IP Transport idR IPi3 Receiver R send(id) Transport send(id) i3 daemon

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 Transport IP Layer Process Transport EID ↔ IP IP Layer SID ↔ EID

51 How It Works? Client app “DNS” DNS requestDNS reply = sid send(IPm) Client app DOA daemon IP Transport send(sid) DHT eim = get(sid) SID ↔ EID send(eim) EID↔IP send(eim) IP = get(eim) put(sid, eim) put(eid, IP) IP Transport SID ↔ EID EID↔IP Middlebox (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 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 Receiver Indirection point (tussle boundary) Sender Middlebox 1 (M1) M2 M3M4 sender control receiver control

60 Realization: i3 vs DOA Internet i3 M1 M2 R ([id S1,id R ], data) id R [id M2,R] id M1 M1 id M2 S2 i3 Internet M1 R ([id S1,id S2 ], data) id M2 id R id M1 M1 id M2 M2 id S1 S1 M2 id S2 S2 id R R id R R Name resolution infrastructure (e.g., OpenDHT) DOA