Internet Indirection Infrastructure

Transcription

1 Motivations Internet Indirection Infrastructure Modified version of Ion Stoica s talk at ODU Nov 14, 05 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 2 Why? Point-to-point communication implicitly assumes there is one sender and one receiver, and that they are placed at fied and well-known locations E.g., a host entified by the IP address is located in Berkeley IP Solutions Etend 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) equire community we consensus -- hard to achieve in practice 4 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 edundancy: each application implements the same functionality over and over again No synergy: each application implements usually only one service; services hard to combine Internet Indirection Infrastructure (i) Each packet is associated an entifier To receive a packet with entifier, receiver maintains a trigger (, ) into the overlay network trigger 5 6 1

2 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 Mobility Host just needs to update its trigger as it moves from one subnet to another 2 1 eceiver (1) eceiver (2) 8 Multicast eceivers insert triggers with same entifier Can dynamically switch between multicast and unicast Anycast Use longest prefi matching instead of eact matching Prefi p: anycast group entifier Suffi s i : encode application semantics, e.g., location eceiver (1) eceiver (2) p a 1 p s 1 1 p s 2 2 p s eceiver (1) eceiver (2) 9 eceiver () 10 Service Composition: Initiated Use a stack of IDs to encode sequence of operations to be performed on path Advantages Don t need to configure path Load balancing and robustness easy to achieve T, T, T T Transcoder (T) Service Composition: eceiver Initiated eceiver can also specify the operations to be performed on Firewall (F) F, F F F, F,

3 Quick Implementation Overview outing i is implemented on top of Chord But can easily use CAN, Pastry, Tapestry, etc Each trigger t = (, ) is stored on the node responsible for Use Chord recursive routing to find best matching trigger for packet p = (, ) 1 14 outing Table Chord uses an m bit circular entifier space where 0 follows (2**m) -1 Each entifier ID is mapped on the server with the closest entifier that follows ID on the entifier circle. This server is called successor of ID Each server maintains a routing table of size m. The ith entry in the routing table of server n contains the first server that follows n + 2**(i-1) A server sends the packet to the closest server (finger) in its routing table that precedes ID. It takes O(log N) hops to route a packet to the server storing the best matching trigger for the packet, where N is the number of i servers. 15 outing Eample inserts trigger t = (, ); S sends packet p = (, ) An end-host needs to know only one i node to use i E.g., S knows node, knows node 5 S 2 m -1 0 S 41 Chord circle 5 send(, ) [42..] 41 [6..41] [8..] 5 [21..5] trigger(,) send(, ) 16 Optimization #1: Path Length /receiver caches i node mapping a specific ID Subsequent packets are sent via one i node Optimization #2: Triangular outing Use well-known trigger for initial rendezvous Echange a pair of (private) triggers well-located Use private triggers to send traffic [8..] [8..] [42..] (S) cache node [6..41] [21..5] [2] 0 2 S (S) [42..] S [0] [6..41] [2] [21..5] 2 [0]

4 Eamples Heterogeneous multicast Scalable Multicast Load balancing Proimity Eample 1: Heterogeneous Multicast not aware of transformations S_MPEG/JPEG send(1, ) send(, ) (MPEG) _MPEG/JPEG S_MPEG/JPEG send((_mpeg/jpeg, 1), ) (_MPEG/JPEG, 1) eceiver 1 (JPEG) 2 send(2, ) 19 eceiver 2 (MPEG) Eample 2: Scalable Multicast i doesn t prove direct support for scalable multicast Triggers with same entifier are mapped onto the same i node Solution: have end-hosts build an hierarchy of trigger of bounded degree (, ) g 4 (g, ) g g Eample 2: Scalable Multicast (Discussion) Unlike IP multicast, i 1. Implement only small scale replication allow infrastructure to remain simple, robust, and scalable 2. Gives end-hosts control on routing enable endhosts to Achieve scalability, and Optimize tree construction to match their needs, e.g., delay, bandwth Eample : Load Balancing Servers insert triggers with IDs that have random suffies Clients send packets with IDs that have random suffies Eample 4: Proimity Suffies of trigger and packet IDs encode the server and client locations A send( ,) S S2 S1 S2 S S1 send( ,) S S2 S S send( ,) S S4 S B S

5 S Security: Some Attacks Eavesdropping A Confluence (A) Loop Dead-End Possible Defense Measures End-hosts can use the public triggers to choose a pair of private triggers, and then use these private triggers to echange the actual. To keep the private triggers secret, one can use public key cryptography to echange the private triggers. Instead of inserting the trigger (, S), the server can insert two triggers, (, ) and (, S), where is an entifier known only by S. An i server can easily verify the entity of a receiver S by sending a challenge to S the first time the trigger is inserted. The challenge consists of a random nonce that is epected to be returned by the receiver. If the receiver fails to answer the challenge the trigger is removed V 2 Victim (V) Each server can put a bound on the number of triggers that can be inserted by a particular end-host. When a trigger that doesn t point to an IP address is inserted, the server checks whether the new trigger doesn t create a loop 26 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 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 Legitimate client (C) ID1 V ID2 V Victim (V) Legitimate client (C) ID1 V Victim (V) (A) Web server 2 (A) Web server Traffic of of transaction server protected from from attack on on web web server 28 5