FIRE: Flexible Intra-AS Routing Environment

1
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

2
Route Traffic Diversity
A
B
Pick every one!
Pick only one?
3
Mainstream Internet Routing

• Todays 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

4
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

5
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

6
FIRE Router Architecture
Flooding Mechanism
SA Generation
Property Applets
Virtual Machine
Property Repository
Routing Algorithms
Data Path
Packet Filters
Forwarding Tables
überfilter
7
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

8
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

9
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

10
Data Path Flow Diagram
IP Packet Header
VPN 1
VPN 2
Default
überfilter
11
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

12
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

13
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

14
Configuration

• The AS is managed by an Operator
• Any person or agent who has the appropriate
  digital certificates to sign an OCM
• Has authority to administer routing in the entire
  AS
• Operator Configuration Message (OCM)
• Injected by the operator from any node
• Flooded throughout the AS like a State Message
• Specifies relevant (OCFs) and where to get them
• Distribution nodes contain all supporting files

15
The Foundation OCF 0

• OCF 0 is always Running
• Provides fail-safe routing functionality
• Used by all multi-hop FIRE traffic (LDTP)
• OCF 0 contains one algorithm
• SPF over Fire-Metric
• OCF 0 contains defines four properties
• Fire-Up whether or not an entity is up
• Fire-Metric functionally equivalent to OSPF
  metric
• IP-Addresses for mapping an address to an entity
• OCFs-Loaded for operator monitoring

16
Neighbor Discovery

• Peering protocol
• Similar to OSPF Hello protocol
• Secured with IPsec to prevent DoS attacks
• Discovers neighbors determines DR
• Designated Routers
• Elected by mutual consensus
• Responsible for adjacent broadcast subnets
• Limit peering relationships on broadcast subnets

17
State Distribution

• FIRE Entities
• Routers, Networks, and Links all have properties
• Links are advertised by adjacent router
• Designated Routers advertise for Networks
• State Advertisements (SAs)
• Properties, certificates, OCMs, and external
  routes
• OSPF-Like Reliable Flooding
• Uses FLINT, a non-reliable transport protocol
• Multicast over broadcast media
• Reliable unicast retransmission

18
Property Applet Interface

• public class
• SA_update
• public static native void
• report_data(Object value)
• public static native void
• value_changed()
• public static native void
• force_SA()

• Applets control SA update frequency
• FIRE doesnt know how to interpret properties
• Applets interpret the significance of property
  value changes
• Rate-limiting to prevent flapping
• AutoNet (DEC SRC 91) skeptics limit long-term
  and instantaneous rates

19
Security Mechanisms

• X.509 Certificate Hierarchy
• Used for end-to-end authentication and integrity
• Authorization certificates allow subversion
  detection and containment
• IPsec
• used for hop-by-hop authentication and integrity
• Local Group Keying Protocol (LGKP)
• multicast symmetric key distribution
• keys are needed before OCF 0 routing is in place
• Denial-of-service / anti-replay protections

20
Downloadable Code

• All downloaded modules are sandboxed
• Code is cryptographically signed for integrity
• Implementation uses Java in separate JVMs
• Property Applets
• Access to built-in functions through FIRE
• May access files, directly connected networks
• Communicate updates back to FIRE
• Routing Algorithms
• Perform forwarding table updates
• May maintain internal state across invocations

21
FIRE Implementation
22
Operator Configuration File

• OCFs define routing behavior in the AS
• Algorithms - how to create forwarding tables (and
  what properties to use for each table)
• Properties- what to advertise (and how to obtain
  it)
• Filters - Map traffic classes to forwarding
  tables
• OCM specifies the state of each OCF
• Load Fetch any necessary support files
• Advertise Issuing State Advertisements
• Run Install filters and forwarding tables

23
What FIRE Does Not Do

• FIRE does not manage paths to provide quality of
  service
• FIRE can send different traffic down different
  links, but it does nothing to ensure that the
  available bandwidth on a link is sufficient to
  meet demand.
• FIRE is complementary to QoS
• FIRE makes the job of RSVP and similar protocols
  much easier
• Could be linked to Layer 2 technologies (MPLS)

24
Routing Algorithm Interface

• public interface
• Algorithm
• public void
• init(FID me, String args)
• public void
• run(Repository repo)
• public void
• cleanup()

• OCF specifies when to invoke applets
• Periodic or event-driven
• Simple interface
• Configured with a specified argv-style argument
  list
• When invoked, run to completion
• Purged when OCF is removed from advertised state

25
Forwarding Table Interface

• public class
• ForwardingTable
• public static native void
• add_entry( Byte destination,
  int mask_length, FID nhop)
• public static native void
• delete_entry( Byte destination,
  int mask_length)
• public static native void
• purge_table()
• public static native void
• do_updates()

• Routing Algorithms update Forwarding Tables
• Interface is batched for performance
• Dynamic updates are not required, but supported
• Internal state is retained
• Forwarding tables are unique to algorithm
  instance