I3 and Active Networks

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. send(R, data) send(id, data) trigger id R 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 Sender Receiver (R)

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

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

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

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 Ri in the anycast group inserts IDs with the same prefix p and a different suffix si send(R1,data) Receiver (R1) p|s1 R1 send(p|a,data) p|s2 R2 Sender Receiver (R2) p|s3 R3 Receiver (R3)

11. send((id_MPEG/JPEG,id), data) send(R, data) send(id, data) 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 S_MPEG/JPEG Receiver R (JPEG) Sender (MPEG) id R S_MPEG/JPEG id_MPEG/JPEG

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 • Hide IP address • Give end-hosts ability to stop the attack in the infrastructure • Make sure that proposed solution does not introduce new security vulnerabilities

14. send(R, data) send(id, data) 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 Sender Receiver (R) trigger id R

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) ATM server (S1) idATM S1 Customer (C) Web server (S2) idWEB S Bank Company Attacker (A)

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 Capsule IP Header Version Type Previous Address Type Dependent Header Files Data ANTS-specific header • Capsules are forwarded past normal IP routers

25. Capsules Request for code Active Node 1 IP Router Active Node 2 Capsule 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 Code Sent Active Node 1 IP Router Active Node 2 Capsule Capsule • 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?