fire: flexible intra-as routing environment craig partridge, alex c. snoeren † tim strayer,...
TRANSCRIPT
FIRE: FlexibleIntra-AS Routing Environment
Craig Partridge, Alex C. Snoeren†
Tim Strayer, Beverly Schwartz, Matthew Condell
Isidro Castiñeyra
BBN Technologies† MIT Lab for Computer Science
Route & Traffic Diversity
Secure
Pick every one!
Low latency, but expensive
High bandwidth, low cost
Pick only one?
A B
Mainstream Internet Routing
• Today’s IP routing protocols are closed Algorithms are fixed and hard to change Metrics are fixed and hard to change
• Limited support for traffic engineering Layer 3 may provide different queuing
disciplines for each traffic class (QoS) But specialized class-based “routing” is
implemented at Layer 2
Towards Active Networking
• The Goal: Greater control of packet routing Traffic engineering for quality of service, policy-
based routing, differentiated services… Without the need for pervasive level 2
technologies such as MPLS or ATM VCs
• An approach: Allow individual packets to control routing behavior in data path Imposes greater router performance requirements Creates new security and stability concerns
FIRE Innovations
• Open routing interface – on control path Operator controlled, maintains consistency
• Separate routing protocol components Property Advertisement
• Support vectors of dynamic metrics Path calculation
• Different algorithms for each traffic class State distribution
• Built-in reliable flooding mechanism
FIRE Router Architecture
PacketFilters
FloodingMechanism
PropertyRepository
SAGeneration
RoutingAlgorithms
PropertyApplets
ForwardingTables
überfilter
Data Path
VirtualMachine
Properties
• Each entity advertises sets of properties e.g. cost, utilization, ownership, security level… For nodes, networks, and unidirectional links
• Values can be obtained in three ways: Statically configured Obtained from MIBs Generated by downloadable property applets
• Applets generate dynamic values Cryptographically-secured downloadable applets Invoked occasionally at each router
Routing Algorithms
• Operator specifies which algorithm(s) to run A native SPF implementation is built in; other algorithms may be downloaded, like multi-objective optimization… … or something completely different!
• Multiple algorithms for multiple classes e.g. SPF/cost, SPF/delay, maximum bandwidth Each produces a separate forwarding table
• Invoked upon property advertisement arrival Precautions are taken to prevent thrashing
FIRE Class-Based Forwarding
• Multiple, independent forwarding tables Each algorithm constructs its own forwarding
tables based upon distributed link-state database Traffic classes are assigned to forwarding tables
by operator-specified packet filters FreeBSD prototype performance similar to
standard kernel forwarding
• Multiple, independent FIRE Instances Several FIRE instances may run simultaneously Each instance is managed independently (VPNs) Data traffic is separated by an überfilter
Data Path Flow Diagram
VPN 1
Default
überfilter
IP Packet Header ForwardingTable 1
DefaultForwarding
ForwardingTable 2
ForwardingTable 3
Filter 1
Filter 2
Filter 3
Filter 4
Filter 6
Filter 7
Filter 8
Filter 5
Operator-specifiedfilters
SPF (hop count)
Bottleneck (bandwidth)
SPF (delay)
SPF (cost)
VPN 2VPN 2
Maintaining Stability
• Ensure reliable basic infrastructure Provides robust, OSPF-like link state distribution Pervasive hop-count based SPF routing tables
• Always used for applet and algorithm downloads Enforce global configuration synchronization
• Operator injects configuration updates
• Limit control traffic and route flapping Prevent thrashing of forwarding tables Fine-grained update frequency control
Security through Containment
• Internal X.509 Certificate Hierarchy All control messages are digitally signed Authorization certificates allow subversion
detection and containment
• Denial-of-service / anti-replay protections IPsec provides hop-by-hop authentication Repository and file transfer protocol precautions
• Applet / Algorithm sandboxing Limited privileges for applets, less for algorithms A more secure language would be nice…
Summary
• FIRE provides extensible, remotely configurable, class-based, link-state, intra-AS routing Operator-specified metrics and algorithms Enhanced flexibility compared to traditional
routing protocols Enhanced security and performance
compared to active packet techniques