OSPF

OSPF, or Open Shortest Path First, is a link-state, hierarchical Interior Gateway Protocol (IGP) routing algorithm. The well known Dijkstra's algorithm is used to calculate the shortest path tree. It uses cost as its routing metric. A link state database is constructed of the network topology which is identical on all routers in the area. (Intro courtesy Wikipedia)

Design Suggestions
Use loopbacks or manually configured router ID's; don't let OSPF choose the IP on a physical interface. It makes troubleshooting much more straightforward when you're looking at the adjacencies. Also, avoid using the RFC 1918 space for RID's; the RID is just an arbitrary 32-bit unsigned int, so have some fun with it.

OSPF Dijkstra calculations are expensive, and unlike IS-IS which treats IPv4 subnets as leaves (making the SPF tree unaffected by IPv4 edge reachibility), flapping subnets on edge routers will cause area-wide link state recalculations. Appropriate address aggregation is a must with OSPF. Plan a hierarchical addressing scheme before you start migrating. Use stubby/totally stubby areas wherever you can to limit the size of your link state database and the scope of your recalculations. For the record, totally stubby areas are not part of the IETF standard.

Don't forget that OSPF is effectively distance-vector for inter-area routing. Internal routes have no idea of the link state topology beyond their area. Use this principle to manipulate host path selection by adjusting metrics on Type 3 LSA's advertised by you ABR's.

OSPF specifies that all areas must be adjacent to area 0. If your network design doesn't allow for a strict two level hierarchy, then OSPF specifies the use of virtual links, which are to be avoided.

Security
OSPF was never designed to be deployed in a hostile environment. A determined attacker could easily perform routing protocol attacks against an unsecured AS. The IETF has a draft discussing possible attacks against OSPF.

OSPFv2 accepts unicast updates on any interface, which permits remote attacks against the IP routing table, even with MD5 authentication enabled. OSPFv2 sets a limit on the shortest interval between LSA update floods, which means periodic injection of faulty information at a rate higher than this threshold could corrupt routing information indefinately. Note that in many cases, the legitimate OSPF router that advertises the correct LSA will "fight back" against faulty information by detecting its own corrupt LSA's, flooding them with an age set to MaxAge to remove it from all topology tables, and reflooding the correct LSA.

Resource Starvation Attacks

 * Memory
 * Bogus LSA's with an arbitrary source take up space in the topology table until the LSA ages out


 * CPU
 * Bogus LSA's spoofing legitimate routers could cause a recalculation of the SPF tree, which can be processor intensive
 * LSA's with bogus MD5 passwords invoke the MD5 function


 * Bandwidth
 * Bogus LSA's and the associated legitimate response traffic could be disruptively high in large, densely populated areas
 * Bogus link state request packets can saturate a link with requests for nonexistent networks

Routing Table Compromise Attacks

 * Redirects
 * Subverting an ASBR or escalating any OSPF router to an ASBR allows an attacker to inject arbitrary routes with External LSA's. The obvious use of this is to redirect traffic destined for outside the AS to a particular, attacker-controlled host
 * Manipulation of advertised metrics (setting an attacker-controlled route to have a metric of one to 0.0.0.0/0)
 * Advertising new connectivity to existing stub networks causes SPF recalculation, possibly redirecting traffic along arbitrary routes
 * Loop generation
 * By crafting external LSA's that advertise reachibility through a given next hop, it is possible to create a loop between an ABR and any of its neighbors

Connectivity Attacks

 * Breaking OSPF adjacencies
 * A router that rolls over its sequence number space can have its updates replayed at will. Replays with significantly higher sequence numbers than the legitimate router is using will block all legitimate updates, which will clearly break the adjacency
 * Hello messages recived without a complete list of all routers on a data link destoys all adjacencies on a link, as OSPF fears unidirectional communications
 * Breaking transit networks
 * If a DR election can be forced to elect a non-existent DR, routers in that broadcast domain will never form a full adjacency, and advertise the affected network as a stub
 * Topology database manipulation
 * Sending LSA's with age set to MaxAge will cause all routers to remove the LSA from their topology tables until the legitimate router refloods its LSA's

RFC's

 * RFC 2328 - OSPFv2, the current IETF standard
 * RFC 3101 - Not-so-Stubby Areas, which permit redistibution of external routes in OSPF stubby areas

Vendor Information

 * Cisco's Design/Implementation Guide