1. I3 and Active Networks Supplemental slides Aditya Akella 03/23/2007

2. What is i3? A highly efficient name-based routing implemented as an overlay network IP router i3 node

3. Communication Abstraction 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 SenderReceiver (R) idR trigger send(id, data) send(R, data)

4. 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

5. What Does i3 Support? Mobility Multicast Anycast Service composition

6. Mobility Host just needs to update its trigger as it moves from one subnet to another Sender Receiver (R1) idR1 send(id,data) send(R1, data)

7. Mobility Host just needs to update its trigger as moves from one subnet to another Sender Receiver (R2) idR2 send(id,data) send(R2, data)

8. Multicast Unifies multicast and unicast abstractions –Multicast: receivers insert triggers with the same identifier An application can dynamically switch between multicast and unicast Sender Receiver (R1)idR1 send(id,data) send(R1, data) Receiver (R2) idR2 send(R2, data)

9. Anycast Generalize the matching scheme used to forward a packet –Until now we assumed exact matching Next, we assume: –Longest prefix matching (LPM) using a prefix larger than a predefined constant l to avoid collisions In the current implementation: ID length, m = 256, l = 128

10. Anycast (cont’d) Anycast is simply a byproduct of the new matching scheme, e.g., –Each receiver R i in the anycast group inserts IDs with the same prefix p and a different suffix s i Sender Receiver (R1) p|s 1 R1 send(p|a,data) Receiver (R2) p|s 2 R2 p|s 3 R3 Receiver (R3) send(R1,data)

11. Service Composition Use a stack of IDs to encode the successions of operations to be performed on data Advantages –Don’t need to configure path –Load balancing and robustness easy to achieve Sender (MPEG) Receiver R (JPEG) id_ MPEG/JPEG S_ MPEG/JPEG id R send((id_ MPEG/JPEG,id), data) S_ MPEG/JPEG send(id, data) send(R, data)

12. Security Develop a complete solution to protect against IP level denial of service attacks Show that a communication infrastructure can provide both more functionality and security than Internet

13. Design Principles 1)Hide IP address 2)Give end-hosts ability to stop the attack in the infrastructure 3)Make sure that proposed solution does not introduce new security vulnerabilities

14. 1) Hide IP Address Enable end-hosts to communicate without revealing their IP address –Otherwise, hosts are vulnerable to IP level flooding attacks i3 trivially implement this principle as data is exchanged via IDs not IP addresses SenderReceiver (R) idR trigger send(id, data) send(R, data)

15. 2) Enable End-hosts to Defend In general, end-hosts are in best position to detect when they are under attack –E.g., flash-crowd vs. DoS, SYN attack Once an end-host detects an attack, it should be able to stop/redirect the offending traffic before it arrives at its inbound connection With i3 end-hosts can –Stop traffic by removing the trigger under attack –Route around a region of i3 under attack by moving triggers around –Implement access control for multicast

16. Example: Avoid Collateral Damage Two services shares the same connection to the Internet If one service is under attack, the user can save the other one (not possible in the Internet) id ATM S1 Web server (S2) Customer (C) id WEB S Attacker (A) ATM server (S1) Bank Company

17. Why Active Networks? Traditional networks route packets looking only at destination –Also, maybe source fields (e.g. multicast) Problem –Rate of deployment of new protocols and applications is too slow Solution –Allow computation in routers to support new protocol deployment

18. Active Networks Nodes (routers) receive packets: –Perform computation based on their internal state and control information carried in packet –Forward zero or more packets to end points depending on result of the computation Users and apps can control behavior of the routers End result: network services richer than those by the simple IP service model

19. Why not IP? Applications that do more than IP forwarding –Firewalls –Web proxies and caches –Transcoding services –Nomadic routers (mobile IP) –Transport gateways (snoop) –Reliable multicast (lightweight multicast, PGM) –Online auctions –Sensor data mixing and fusion Active networks makes such applications easy to develop and deploy

20. Variations on Active Networks Programmable routers –More flexible than current configuration mechanism –For use by administrators or privileged users Active control –Forwarding code remains the same –Useful for management/signaling/measurement of traffic “Active networks” –Computation occurring at the network (IP) layer of the protocol stack  capsule based approach –Programming can be done by any user –Source of most active debate

21. Case Study: MIT ANTS System Conventional Networks: –All routers perform same computation Active Networks: –Routers have same runtime system Tradeoffs between functionality, performance and security

22. System Components Capsules Active Nodes: –Execute capsules of protocol and maintain protocol state –Provide capsule execution API and safety using OS/language techniques Code Distribution Mechanism –Ensure capsule processing routines automatically/dynamically transfer to node as needed

23. Capsules Each user/flow programs router to handle its own packets –Code sent along with packets –Code sent by reference Protocol: –Capsules that share the same processing code May share state in the network Capsule ID is MD5 of code

24. Capsules Active Node IP Router Active Node Capsule IP HeaderVersionDataType Previous Address Type Dependent Header Files ANTS-specific header Capsules are forwarded past normal IP routers

25. Capsules Active Node 1 IP Router Active Node 2 Capsule Request for code Capsule When node receives capsule uses “type” to determine code to run If no code at node requests code from “previous address” node Likely to have code since it was recently used

26. Capsules Active Node 1 IP Router Active Node 2 Capsule Code Sent Code is transferred from previous node Size limited to 16KB Code is signed by trusted authority (e.g. IETF) to guarantee reasonable global resource use

27. Research Questions Execution environments –What can capsule code access/do? Safety, security & resource sharing –How isolate capsules from other flows, resources? Performance –Will active code slow the network? Applications –What type of applications/protocols does this enable?

28. Functions Provided by Capsule Environment Access –Querying node address, time, routing tables Capsule Manipulation –Access header and payload Control Operations –Create, forward and suppress capsules –How to control creation of new capsules? Storage –Soft-state cache of app-defined objects

29. Safety, Resource Mgt, Support Safety: –Provided by mobile code technology (e.g. Java) Resource Management: –Node OS monitors capsule resource consumption Support: –If node doesn’t have capsule code, retrieve from somewhere on path

30. Performance User level Java implementation ok for T1 (1.5Mbps)

31. Performance Based on profile of code  Java specific overheads and user level send/receive are bulk of extra overhead Safe evaluation and type demultiplexing only add 30% overhead –Other more efficient technologies available Software fault isolation (SFI) Proof carrying code (PCC)

32. Applications/Protocols Limitations –Expressible  limited by execution environment –Compact  less than 16KB –Fast  aborted if slower than forwarding rate –Incremental  not all nodes will be active Proof by example –Host mobility, multicast, path MTU, Web cache routing, etc.

33. Discussion Active nodes present lots of applications with a desirable architecture Key questions –Is all this necessary at the forwarding level of the network? –Is ease of deploying new apps/services and protocols a reality?