1 / 60

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

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)

kirti
Download Presentation

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

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  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 • 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. “Any problem in computer science can be solved by adding a layer of indirection” Key Observation • Virtually all previous proposals use indirection!

  8. DNS Server Home Agent “foo.org” (IPhome,data) foo.org IPfoo IPhome IPmobile IPfoo (IPmobile,data) (IPdst:Pdst,data) (IPfoot,data) IPfoo IPmofile DNS Mobile IP NAT Box (IPM,data) (IPnat:Pnat,data) IPnat:Pnat IPdst:Pdst Internet (IPMIPR1) (IPMIPR2) (IPR2,data) (IPR1,data) IPdst IPR2 IPR1 NAT IP Multicast Indirection is Everywhere!

  9. Application Build an efficient indirection layer on top of IP Indir. layer TCP/UDP IP Internet Indirection Infrastructure (i3) • Use an overlay network to implement this layer • Incrementally deployable; don’t need to change IP

  10. trigger data data data id id R id R 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. Receiver (R1) id id R1 R2 Receiver (R2) Mobility • Host just needs to update its trigger as it moves from one subnet to another Sender

  13. data data data data R2 R1 id id Multicast • Receivers insert triggers with same identifier • Can dynamically switch between multicast and unicast id R1 Receiver (R1) Sender id R2 Receiver (R2)

  14. p|a data p|a data data R1 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 p|s1 R2 p|s2 Sender Receiver (R2) R3 p|s3 Receiver (R3)

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

  16. id data idF,R F,R id data data data data R Service Composition: Receiver Initiated • Receiver can also specify the operations to be performed on data Firewall (F) Receiver (R) F Sender idF 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. send(37, data) 37 R trigger(37,R) send(R, data) 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. 37 R data data 37 R cache node 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. 37 30 R R data data [2] [2] 2 30 37 R R S S 2 [30] [30] 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. send(R2, data) id R2 Receiver R2 (MPEG) Example 1: Heterogeneous Multicast • Sender not aware of transformations S_MPEG/JPEG send(R1, data) send(id, data) Receiver R1 (JPEG) Sender (MPEG) S_MPEG/JPEG id_MPEG/JPEG send((id_MPEG/JPEG, R1), data) id (id_MPEG/JPEG, R1)

  24. (g, data) g x g R1 g R2 R2 (x, data) x R3 x R4 R1 R3 R4 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

  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. IDR R R [IDS] data data IDP [IDS] IDS IDP IDR S R R IDS S [IDR] [IDR] 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. ID1 V Legitimate client (C) ID2 V Web server Attacker (A) 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. ID1 V Legitimate client (C) Web server Attacker (A) 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. Gatekeeper (A) puzzle Server (S) Client (C) puzzle’s solution 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 <HIT, port> <IPaddr, port> HIP Layer IP Layer <IPaddr> <HIT> <IPaddr> IP Layer

  39. HIT DNS request DNS reply = pubkey (P) send(HIT) HIT=hash(P) IPaddr 4-way authentication send(HIT) HIT IPaddr, P send(IPaddr) send(IPaddr) 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 (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. Protocol Stack Process local scope Process Transport ID/<IPlocal, port> Transport <IPaddr, port> i3 layer (IPlocal->ID) <ID> IP Layer <IPaddr> <IPi3> IP Layer Sender specific

  43. DNS request DNS reply = id 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 <SID> Transport Transport <EID, port> <IPaddr, port> EID↔IP IP Layer <IPaddr> <EID> <IPaddr> IP Layer

More Related