fire: flexible intra-as routing environment craig partridge, alex c. snoeren † tim strayer,...

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