Transcript PPT slides

I3 and Active Networks
Supplemental slides
Aditya Akella
03/23/2007
What is i3?
• A highly efficient name-based routing
implemented as an overlay network
IP router
i3 node
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
send(R, data)
send(id, data)
Sender
trigger
id
R
Receiver (R)
Service Model
• API
– sendPacket(p);
– insertTrigger(t);
– removeTrigger(t) // optional
• Best-effort service model (like IP)
• Triggers are periodically refreshed by endhosts
• Reliability, congestion control, and flowcontrol implemented at end-hosts
What Does i3 Support?
•
•
•
•
Mobility
Multicast
Anycast
Service composition
Mobility
• Host just needs to update its trigger as it
moves from one subnet to another
send(id,data)
Sender
send(R1, data)
id R1
Receiver
(R1)
Mobility
• Host just needs to update its trigger as moves
from one subnet to another
send(id,data)
send(R2, data)
Sender
id R2
Receiver
(R2)
Multicast
• Unifies multicast and unicast abstractions
– Multicast: receivers insert triggers with the same
identifier
• An application can dynamically switch
between multicast and unicast
send(id,data)
Sender
send(R1, data)
id R1
Receiver (R1)
id R2
send(R2, data) Receiver (R2)
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
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
send(R1,data)
si
Receiver (R1)
send(p|a,data)
Sender
p|s1 R1
p|s2 R2
p|s3 R3
Receiver (R2)
Receiver (R3)
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
send((id_MPEG/JPEG,id), data)
Sender
(MPEG)
send(R, data)
send(id, data)
id_MPEG/JPEG S_MPEG/JPEG
id
R
Receiver R
(JPEG)
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
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
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
send(id, data)
Sender
send(R, data)
trigger
id R
Receiver (R)
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
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)
Customer (C)
idATM
idWEB
S1
S
Web server
(S2)
Bank Company
Attacker (A)
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
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
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
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
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
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
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
Capsules
Active
Node
IP
Router
Capsule
IP Header
Version
Active
Node
Capsule
Type
Previous
Address
Type Dependent
Header Files
Data
ANTS-specific header
• Capsules are forwarded past normal IP routers
Capsules
Request for code
Active
Node 1
IP
Router
Capsule
Active
Node 2
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
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
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?
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
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
Performance
• User level Java implementation ok for T1
(1.5Mbps)
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)
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.
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?