Internet Indirection Infrastructure

1. Internet Indirection Infrastructure Presented in 294-4 by Jayanthkumar Kannan On 09/17/03

2. Motivation • Current Internet based on point-to-point abstraction: routing built around it. • Good for unicast, but not for multicast, anycast, mobility etc. • IP based solutions have made it nowhere. • Overlay based solutions: each overlay has attempted to provide one of these services

3. Indirection • Indirection: the only primitive needed to provide these services. • Move away from end-point to name-based communication: exactly the thing DHTs do efficiently. • Soln: Add an indirection layer on top of IP, implemented using overlay networks.

4. send(R, data) send(ID, data) trigger ID R Rendevzous Communication • Packets addressed to identifiers (“names”). • Trigger: (Identifier, IP address): inserted by receiver and then used by sender. • Triggers basically mappings set up by end-hosts, and stored in DHTs (can point to other triggers too). 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. Public and Private Triggers • The discovery problem • Servers publish their public ids: dns etc. • Clients contact server using public ids, and negotiate private ids used thereafter. • Works well for efficiency: private ids chosen on “close-by” i3-servers. • Private ids are shared-secrets, and comm. cannot be disrupted by other end-hosts.

7. Mobility and Multicast • Mobility supported naturally • End-host inserts trigger with new IP address, and everything transparent to sender • Robust, and supports location privacy • Multicast • Simplest case: All receivers insert triggers under same ID, and sender uses that ID for sending. • Infrastructure can optimize tree construction (optionally) (pursued in later work).

8. Anycast • ID of server now includes some location hint as well (say, pincode) • Generalized matching: First k-bits have to match, longest prefix match among rest. • Client sends data address to (id-server,his location) • Requirement: All such triggers have to reside on same I3-server. • Used for load-balancing as well: second part of trigger is randomized.

9. Identifiers Stack • Stack of identifiers: source routing-like • Trigger inserter can specify source-routing: RHS of trigger contains a stack • I3 routes packet through these identifiers • Sender can specify id-stack in packet: first id used to match trigger: rest added to the RHS of trigger and processed as before.

10. send((ID_MPEG/JPEG,ID), data) send(R, data) send(ID, data) Service Composition • Transcoding example. • Receiver mediated: R sets up chain and passed id_mpeg/jpeg to sender: sender oblivious • Sender-mediated: S can include (id_mpeg/jpeg, ID) in his packet: receiver oblivious S_MPEG/JPEG Receiver R (JPEG) Sender (MPEG) ID R S_MPEG/JPEG ID_MPEG/JPEG

11. Large Scale Multicast • Replication possible at any i3-server in the infrastructure. • Tree construction can be done internally (g, data) g x g R1 g R2 R2 x R3 x R4 R1 R3 R4

12. Requirements for substrate • Robustness, Scalability, Efficiency, Stability. • Chord chosen for implementation, CAN, Tapestry, Pastry also possible. • Robustness: soft-state, back-up triggers, trigger replication • Efficiency: • When first packet is sent, ip address of responsible i3-server cached. • Suggested method to alleviate triangle routing: choose private triggers by experimentation

13. Other refinements • Avoiding hot spots: Some triggers transferred to predeccessor: caching. • Scalability: O ( n = # of flows + # of end-hosts):each server load=O(n/N). Acceptable? • Incremental deployment possible. • Legacy applications can be supported by proxy which inserts triggers on behalf of client.

14. Security Properties • Eavesdropping by inserting (id,E) • Private triggers are secret anyway, not possible to eavesdrop • Comm. on public keys encrypted by public key of server: not so feasible? • Dos Attacks possible • Simple attack: A tree of triggers whose leaves point to the victim end-host • Challenges issued to ensure RHS of trigger is infact the inserter • Fair Queuing suggested to ensure other triggers are not affected • Anonymity: IP address unknown to end-hosts, precludes IP-level flooding attacks. • Flooding attacks: Drop public triggers in face of attack.

15. Security Enhancement • A more complete solution proposed in later work to fix loopholes in I3. • Basic idea: constrain RHS = hash(LHS) for id-id triggers • Cannot setup loops within i3-servers: involves inverting a hash function • Cannot create confluences: requires finding collisions.

16. Latency • Topology (INET, GT-ITM), delays assigned and 16384 i3-servers allocated(randomly,stub nodes). • Latency per packet = sender to i3 server+i3 server to receiver (assuming ip addr is cached) • K = number of samples probed to find closeby server

17. Performance Numbers • Latency suffered by first packet = time taken to route through Chord • Two heuristics: • Closest finger replica: use r successors of each finger for routing • Closest finger set: choose closest log(N)/log(2) fingers out of log(N)/log(b) (b<2) fingers • Other per-machine benchmarks: • Handle 2.4 x 10^6 triggers. • 25 micro-secs for 1 Kb pkt • Throughput: 200 Mbps (1Kb pkt)

18. Winding up …. • I3 is a toned-down version of active networks that allows packet replication,re-direction, and a few other operations. • Indirection used as a simple abstraction to provide variety of services. • Indirection can be implemented efficiently using today’s DHTs (note: environment is relatively static). • Efficiency: Not fully addressed.