[nsp] Securing OSPF

[Streiner, Justin]

On Wed, 23 Jun 2004, Matt Stockdale wrote:

> Greetings,
>
> I'm trying to clean up an OSPF mess I've inherited, and I was curious-
>
> What are you all doing to secure your OSPF (or igrp/rip/etc, I suppose)?
> Just setting md5 keys on everything and calling it a day? Or are you
> using default passive interfaces and only running ospf on the necessary
> links? Both?

Judicious use of both is what I use here, more of the latter than the
former.  Running OSPF on interfaces that don't need to be running it is
asking for trouble.  It's the same concept as not enabling services (or
disabling them if enabled by default) that aren't needed on a system.
Fewer things to break, and fewer ways for something to break your
network...

You can enable OSPF authentication per interface to minimize the pain if
rolling something like that onto your network.  It takes more time, but in
a large network, I think it's a more sane approach.  Just remember to do
it on both sides of the interface :-)

> I've basically got a single OSPF area where routing information for 3
> superblocks (2 /19's and an /18) is exchanged over routers all
> configured w/ an ospf network of a single class C, resulting in 95% of
> the routes being OSPF external type 2. I figure the solution is to add
> all of the network space to the 5 or 6 different OSPF speaking devices'
> ospf instances, and use ospf passive-interface default on our hybrid
> 6500s and CT3 T1 aggregator to avoid speaking/receiving OSPF to the 200
> or so connected subnets.

Keep in mind that the "network x.x.x.x m.m.m.m area N" statement does not
behave like a network statement in BGP.  In BGP-speak, a statement like
this would announce the network x.x.x.x/m.m.m.m to its neighbors.  In
OSPF, it enables OSPF on interfaces that match x.x.x.x/m.m.m.m address/
mask.  This behavior is overridden by specific passive-interface
statements, or passive-interface default.

I would recommend examining how those type-2 external LSAs get into your
OSPF network and whether or not you can break some devices off into their
own areas.

The two benefits here are minimizing the overall size of the OSPF
link-state database where possible by using summarization, and minimizing
the resources each OSPF-speaking router uses by keeping the number of
LSAs that get flooded into the area down to a minimum.

I'm guessing right now there are frequent occurrences of "redistribute
connected" on your network?  Type-2 externals aren't necessarily a bad
thing - routes that are redistributed from other sources (connected,
static, other protocols) are often done as type-2 externals.

jms