Appendix D. Authentication
C. Configurable Constants
The OSPF protocol has quite a few configurable parameters. These
parameters are listed below. They are grouped into general
functional categories (area parameters, interface parameters, etc.).
Sample values are given for some of the parameters.
Some parameter settings need to be consistent among groups of
routers. For example, all routers in an area must agree on that
area's parameters, and all routers attached to a network must agree
on that network's IP network number and mask.
Some parameters may be determined by router algorithms outside of
this specification (e.g., the address of a host connected to the
router via a SLIP line). From OSPF's point of view, these items are
still configurable.
C.1 Global parameters
In general, a separate copy of the OSPF protocol is run for each
area. Because of this, most configuration parameters are
defined on a per-area basis. The few global configuration
parameters are listed below.
Router ID
This is a 32-bit number that uniquely identifies the router
in the Autonomous System. One algorithm for Router ID
assignment is to choose the largest or smallest IP address
assigned to the router. If a router's OSPF Router ID is
changed, the router's OSPF software should be restarted
before the new Router ID takes effect. Before restarting in
order to change its Router ID, the router should flush its
self-originated LSAs from the routing domain (see Section
14.1), or they will persist for up to MaxAge minutes.
RFC1583Compatibility
Controls the preference rules used in Section 16.4 when
choosing among multiple AS-external-LSAs advertising the
same destination. When set to "enabled", the preference
rules remain those specified by RFC 1583 ([Ref9]). When set
to "disabled", the preference rules are those stated in
Section 16.4.1, which prevent routing loops when AS-
external-LSAs for the same destination have been originated
from different areas. Set to "enabled" by default.
In order to minimize the chance of routing loops, all OSPF
routers in an OSPF routing domain should have
RFC1583Compatibility set identically. When there are routers
present that have not been updated with the functionality
specified in Section 16.4.1 of this memo, all routers should
have RFC1583Compatibility set to "enabled". Otherwise, all
routers should have RFC1583Compatibility set to "disabled",
preventing all routing loops.
C.2 Area parameters
All routers belonging to an area must agree on that area's
configuration. Disagreements between two routers will lead to
an inability for adjacencies to form between them, with a
resulting hindrance to the flow of routing protocol and data
traffic. The following items must be configured for an area:
Area ID
This is a 32-bit number that identifies the area. The Area
ID of 0.0.0.0 is reserved for the backbone. If the area
represents a subnetted network, the IP network number of the
subnetted network may be used for the Area ID.
List of address ranges
An OSPF area is defined as a list of address ranges. Each
address range consists of the following items:
[IP address, mask]
Describes the collection of IP addresses contained
in the address range. Networks and hosts are
assigned to an area depending on whether their
addresses fall into one of the area's defining
address ranges. Routers are viewed as belonging to
multiple areas, depending on their attached
networks' area membership.
Status Set to either Advertise or DoNotAdvertise. Routing
information is condensed at area boundaries.
External to the area, at most a single route is
advertised (via a summary-LSA) for each address
range. The route is advertised if and only if the
address range's Status is set to Advertise.
Unadvertised ranges allow the existence of certain
networks to be intentionally hidden from other
areas. Status is set to Advertise by default.
As an example, suppose an IP subnetted network is to be its
own OSPF area. The area would be configured as a single
address range, whose IP address is the address of the
subnetted network, and whose mask is the natural class A, B,
or C address mask. A single route would be advertised
external to the area, describing the entire subnetted
network.
ExternalRoutingCapability
Whether AS-external-LSAs will be flooded into/throughout the
area. If AS-external-LSAs are excluded from the area, the
area is called a "stub". Internal to stub areas, routing to
external destinations will be based solely on a default
summary route. The backbone cannot be configured as a stub
area. Also, virtual links cannot be configured through stub
areas. For more information, see Section 3.6.
StubDefaultCost
If the area has been configured as a stub area, and the
router itself is an area border router, then the
StubDefaultCost indicates the cost of the default summary-
LSA that the router should advertise into the area.
C.3 Router interface parameters
Some of the configurable router interface parameters (such as IP
interface address and subnet mask) actually imply properties of
the attached networks, and therefore must be consistent across
all the routers attached to that network. The parameters that
must be configured for a router interface are:
IP interface address
The IP protocol address for this interface. This uniquely
identifies the router over the entire internet. An IP
address is not required on point-to-point networks. Such a
point-to-point network is called "unnumbered".
IP interface mask
Also referred to as the subnet/network mask, this indicates
the portion of the IP interface address that identifies the
attached network. Masking the IP interface address with the
IP interface mask yields the IP network number of the
attached network. On point-to-point networks and virtual
links, the IP interface mask is not defined. On these
networks, the link itself is not assigned an IP network
number, and so the addresses of each side of the link are
assigned independently, if they are assigned at all.
Area ID
The OSPF area to which the attached network belongs.
Interface output cost
The cost of sending a packet on the interface, expressed in
the link state metric. This is advertised as the link cost
for this interface in the router's router-LSA. The interface
output cost must always be greater than 0.
RxmtInterval
The number of seconds between LSA retransmissions, for
adjacencies belonging to this interface. Also used when
retransmitting Database Description and Link State Request
Packets. This should be well over the expected round-trip
delay between any two routers on the attached network. The
setting of this value should be conservative or needless
retransmissions will result. Sample value for a local area
network: 5 seconds.
InfTransDelay
The estimated number of seconds it takes to transmit a Link
State Update Packet over this interface. LSAs contained in
the update packet must have their age incremented by this
amount before transmission. This value should take into
account the transmission and propagation delays of the
interface. It must be greater than 0. Sample value for a
local area network: 1 second.
Router Priority
An 8-bit unsigned integer. When two routers attached to a
network both attempt to become Designated Router, the one
with the highest Router Priority takes precedence. If there
is still a tie, the router with the highest Router ID takes
precedence. A router whose Router Priority is set to 0 is
ineligible to become Designated Router on the attached
network. Router Priority is only configured for interfaces
to broadcast and NBMA networks.
HelloInterval
The length of time, in seconds, between the Hello Packets
that the router sends on the interface. This value is
advertised in the router's Hello Packets. It must be the
same for all routers attached to a common network. The
smaller the HelloInterval, the faster topological changes
will be detected; however, more OSPF routing protocol
traffic will ensue. Sample value for a X.25 PDN network: 30
seconds. Sample value for a local area network: 10 seconds.
RouterDeadInterval
After ceasing to hear a router's Hello Packets, the number
of seconds before its neighbors declare the router down.
This is also advertised in the router's Hello Packets in
their RouterDeadInterval field. This should be some
multiple of the HelloInterval (say 4). This value again
must be the same for all routers attached to a common
network.
AuType
Identifies the authentication procedure to be used on the
attached network. This value must be the same for all
routers attached to the network. See Appendix D for a
discussion of the defined authentication types.
Authentication key
This configured data allows the authentication procedure to
verify OSPF protocol packets received over the interface.
For example, if the AuType indicates simple password, the
Authentication key would be a clear 64-bit password.
Authentication keys associated with the other OSPF
authentication types are discussed in Appendix D.
C.4 Virtual link parameters
Virtual links are used to restore/increase connectivity of the
backbone. Virtual links may be configured between any pair of
area border routers having interfaces to a common (non-backbone)
area. The virtual link appears as an unnumbered point-to-point
link in the graph for the backbone. The virtual link must be
configured in both of the area border routers.
A virtual link appears in router-LSAs (for the backbone) as if
it were a separate router interface to the backbone. As such,
it has all of the parameters associated with a router interface
(see Section C.3). Although a virtual link acts like an
unnumbered point-to-point link, it does have an associated IP
interface address. This address is used as the IP source in
OSPF protocol packets it sends along the virtual link, and is
set dynamically during the routing table build process.
Interface output cost is also set dynamically on virtual links
to be the cost of the intra-area path between the two routers.
The parameter RxmtInterval must be configured, and should be
well over the expected round-trip delay between the two routers.
This may be hard to estimate for a virtual link; it is better to
err on the side of making it too large. Router Priority is not
used on virtual links.
A virtual link is defined by the following two configurable
parameters: the Router ID of the virtual link's other endpoint,
and the (non-backbone) area through which the virtual link runs
(referred to as the virtual link's Transit area). Virtual links
cannot be configured through stub areas.
C.5 NBMA network parameters
OSPF treats an NBMA network much like it treats a broadcast
network. Since there may be many routers attached to the
network, a Designated Router is selected for the network. This
Designated Router then originates a network-LSA, which lists all
routers attached to the NBMA network.
However, due to the lack of broadcast capabilities, it may be
necessary to use configuration parameters in the Designated
Router selection. These parameters will only need to be
configured in those routers that are themselves eligible to
become Designated Router (i.e., those router's whose Router
Priority for the network is non-zero), and then only if no
automatic procedure for discovering neighbors exists:
List of all other attached routers
The list of all other routers attached to the NBMA network.
Each router is listed by its IP interface address on the
network. Also, for each router listed, that router's
eligibility to become Designated Router must be defined.
When an interface to a NBMA network comes up, the router
sends Hello Packets only to those neighbors eligible to
become Designated Router, until the identity of the
Designated Router is discovered.
PollInterval
If a neighboring router has become inactive (Hello Packets
have not been seen for RouterDeadInterval seconds), it may
still be necessary to send Hello Packets to the dead
neighbor. These Hello Packets will be sent at the reduced
rate PollInterval, which should be much larger than
HelloInterval. Sample value for a PDN X.25 network: 2
minutes.
C.6 Point-to-MultiPoint network parameters
On Point-to-MultiPoint networks, it may be necessary to
configure the set of neighbors that are directly reachable over
the Point-to-MultiPoint network. Each neighbor is identified by
its IP address on the Point-to-MultiPoint network. Designated
Routers are not elected on Point-to-MultiPoint networks, so the
Designated Router eligibility of configured neighbors is
undefined.
Alternatively, neighbors on Point-to-MultiPoint networks may be
dynamically discovered by lower-level protocols such as Inverse
ARP ([Ref14]).
C.7 Host route parameters
Host routes are advertised in router-LSAs as stub networks with
mask 0xffffffff. They indicate either router interfaces to
point-to-point networks, looped router interfaces, or IP hosts
that are directly connected to the router (e.g., via a SLIP
line). For each host directly connected to the router, the
following items must be configured:
Host IP address
The IP address of the host.
Cost of link to host
The cost of sending a packet to the host, in terms of the
link state metric. However, since the host probably has
only a single connection to the internet, the actual
configured cost in many cases is unimportant (i.e., will
have no effect on routing).
Area ID
The OSPF area to which the host belongs.
D. Authentication
All OSPF protocol exchanges are authenticated. The OSPF packet
header (see Section A.3.1) includes an authentication type field,
and 64-bits of data for use by the appropriate authentication scheme
(determined by the type field).
The authentication type is configurable on a per-interface (or
equivalently, on a per-network/subnet) basis. Additional
authentication data is also configurable on a per-interface basis.
Authentication types 0, 1 and 2 are defined by this specification.
All other authentication types are reserved for definition by the
IANA ([email protected]). The current list of authentication types is
described below in Table 20.
AuType Description
___________________________________________
0 Null authentication
1 Simple password
2 Cryptographic authentication
All others Reserved for assignment by the
IANA ([email protected])
Table 20: OSPF authentication types.
D.1 Null authentication
Use of this authentication type means that routing exchanges
over the network/subnet are not authenticated. The 64-bit
authentication field in the OSPF header can contain anything; it
is not examined on packet reception. When employing Null
authentication, the entire contents of each OSPF packet (other
than the 64-bit authentication field) are checksummed in order
to detect data corruption.
D.2 Simple password authentication
Using this authentication type, a 64-bit field is configured on
a per-network basis. All packets sent on a particular network
must have this configured value in their OSPF header 64-bit
authentication field. This essentially serves as a "clear" 64-
bit password. In addition, the entire contents of each OSPF
packet (other than the 64-bit authentication field) are
checksummed in order to detect data corruption.
Simple password authentication guards against routers
inadvertently joining the routing domain; each router must first
be configured with its attached networks' passwords before it
can participate in routing. However, simple password
authentication is vulnerable to passive attacks currently
widespread in the Internet (see [Ref16]). Anyone with physical
access to the network can learn the password and compromise the
security of the OSPF routing domain.
D.3 Cryptographic authentication
Using this authentication type, a shared secret key is
configured in all routers attached to a common network/subnet.
For each OSPF protocol packet, the key is used to
generate/verify a "message digest" that is appended to the end
of the OSPF packet. The message digest is a one-way function of
the OSPF protocol packet and the secret key. Since the secret
key is never sent over the network in the clear, protection is
provided against passive attacks.
The algorithms used to generate and verify the message digest
are specified implicitly by the secret key. This specification
completely defines the use of OSPF Cryptographic authentication
when the MD5 algorithm is used.
In addition, a non-decreasing sequence number is included in
each OSPF protocol packet to protect against replay attacks.
This provides long term protection; however, it is still
possible to replay an OSPF packet until the sequence number
changes. To implement this feature, each neighbor data structure
contains a new field called the "cryptographic sequence number".
This field is initialized to zero, and is also set to zero