checksumming.)
(2) The 64-bit authentication field in the OSPF packet
header must be equal to the 64-bit password (i.e.,
authentication key) that has been configured for the
interface.
D.5.3 Verifying Cryptographic authentication
When using Cryptographic authentication, the received OSPF
packet is authenticated as follows:
(1) Locate the receiving interface's configured key having
Key ID equal to that specified in the received OSPF
packet (see Figure 18). If the key is not found, or if
the key is not valid for reception (i.e., current time <
KeyStartAccept or current time >= KeyStopAccept), the
OSPF packet is discarded.
(2) If the cryptographic sequence number found in the OSPF
header (see Figure 18) is less than the cryptographic
sequence number recorded in the sending neighbor's data
structure, the OSPF packet is discarded.
(3) Verify the appended message digest in the following
steps:
(a) The received digest is set aside.
(b) A new digest is calculated, as specified in Step 6
of Section D.4.3.
(c) The calculated and received digests are compared. If
they do not match, the OSPF packet is discarded. If
they do match, the OSPF protocol packet is accepted
as authentic, and the "cryptographic sequence
number" in the neighbor's data structure is set to
the sequence number found in the packet's OSPF
header.
E. An algorithm for assigning Link State IDs
The Link State ID in AS-external-LSAs and summary-LSAs is usually
set to the described network's IP address. However, if necessary one
or more of the network's host bits may be set in the Link State ID.
This allows the router to originate separate LSAs for networks
having the same address, yet different masks. Such networks can
occur in the presence of supernetting and subnet 0s (see [Ref10]).
This appendix gives one possible algorithm for setting the host bits
in Link State IDs. The choice of such an algorithm is a local
decision. Separate routers are free to use different algorithms,
since the only LSAs affected are the ones that the router itself
originates. The only requirement on the algorithms used is that the
network's IP address should be used as the Link State ID whenever
possible; this maximizes interoperability with OSPF implementations
predating RFC1583.
The algorithm below is stated for AS-external-LSAs. This is only
for clarity; the exact same algorithm can be used for summary-LSAs.
Suppose that the router wishes to originate an AS-external-LSA for a
network having address NA and mask NM1. The following steps are then
used to determine the LSA's Link State ID:
(1) Determine whether the router is already originating an AS-
external-LSA with Link State ID equal to NA (in such an LSA the
router itself will be listed as the LSA's Advertising Router).
If not, the Link State ID is set equal to NA and the algorithm
terminates. Otherwise,
(2) Obtain the network mask from the body of the already existing
AS-external-LSA. Call this mask NM2. There are then two cases:
o NM1 is longer (i.e., more specific) than NM2. In this case,
set the Link State ID in the new LSA to be the network
[NA,NM1] with all the host bits set (i.e., equal to NA or'ed
together with all the bits that are not set in NM1, which is
network [NA,NM1]'s broadcast address).
o NM2 is longer than NM1. In this case, change the existing
LSA (having Link State ID of NA) to reference the new
network [NA,NM1] by incrementing the sequence number,
changing the mask in the body to NM1 and inserting the cost
of the new network. Then originate a new LSA for the old
network [NA,NM2], with Link State ID equal to NA or'ed
together with the bits that are not set in NM2 (i.e.,
network [NA,NM2]'s broadcast address).
The above algorithm assumes that all masks are contiguous; this
ensures that when two networks have the same address, one mask is
more specific than the other. The algorithm also assumes that no
network exists having an address equal to another network's
broadcast address. Given these two assumptions, the above algorithm
always produces unique Link State IDs. The above algorithm can also
be reworded as follows: When originating an AS-external-LSA, try to
use the network number as the Link State ID. If that produces a
conflict, examine the two networks in conflict. One will be a subset
of the other. For the less specific network, use the network number
as the Link State ID and for the more specific use the network's
broadcast address instead (i.e., flip all the "host" bits to 1). If
the most specific network was originated first, this will cause you
to originate two LSAs at once.
As an example of the algorithm, consider its operation when the
following sequence of events occurs in a single router (Router A).
(1) Router A wants to originate an AS-external-LSA for
[10.0.0.0,255.255.255.0]:
(a) A Link State ID of 10.0.0.0 is used.
(2) Router A then wants to originate an AS-external-LSA for
[10.0.0.0,255.255.0.0]:
(a) The LSA for [10.0.0,0,255.255.255.0] is reoriginated using a
new Link State ID of 10.0.0.255.
(b) A Link State ID of 10.0.0.0 is used for
[10.0.0.0,255.255.0.0].
(3) Router A then wants to originate an AS-external-LSA for
[10.0.0.0,255.0.0.0]:
(a) The LSA for [10.0.0.0,255.255.0.0] is reoriginated using a
new Link State ID of 10.0.255.255.
(b) A Link State ID of 10.0.0.0 is used for
[10.0.0.0,255.0.0.0].
(c) The network [10.0.0.0,255.255.255.0] keeps its Link State ID
of 10.0.0.255.
F. Multiple interfaces to the same network/subnet
There are at least two ways to support multiple physical interfaces
to the same IP subnet. Both methods will interoperate with
implementations of RFC1583 (and of course this memo). The two
methods are sketched briefly below. An assumption has been made that
each interface has been assigned a separate IP address (otherwise,
support for multiple interfaces is more of a link-level or ARP issue
than an OSPF issue).
Method 1:
Run the entire OSPF functionality over both interfaces, sending
and receiving hellos, flooding, supporting separate interface
and neighbor FSMs for each interface, etc. When doing this all
other routers on the subnet will treat the two interfaces as
separate neighbors, since neighbors are identified (on broadcast
and NBMA networks) by their IP address.
Method 1 has the following disadvantages:
(1) You increase the total number of neighbors and adjacencies.
(2) You lose the bidirectionality test on both interfaces, since
bidirectionality is based on Router ID.
(3) You have to consider both interfaces together during the
Designated Router election, since if you declare both to be
DR simultaneously you can confuse the tie-breaker (which is
Router ID).
Method 2:
Run OSPF over only one interface (call it the primary
interface), but include both the primary and secondary
interfaces in your Router-LSA.
Method 2 has the following disadvantages:
(1) You lose the bidirectionality test on the secondary
interface.
(2) When the primary interface fails, you need to promote the
secondary interface to primary status.
G. Differences from RFC2178
This section documents the differences between this memo and RFC
2178. All differences are backward-compatible. Implementations of
this memo and of RFCs 2178, 1583, and 1247 will interoperate.
G.1 Flooding modifications
Three changes have been made to the flooding procedure in
Section 13.
The first change is to step 4 in Section 13. Now MaxAge LSAs are
acknowledged and then discarded only when both a) there is no
database copy of the LSA and b) none of router's neighbors are
in states Exchange or Loading. In all other cases, the MaxAge
LSA is processed like any other LSA, installing the LSA in the
database and flooding it out the appropriate interfaces when the
LSA is more recent than the database copy (Step 5 of Section
13). This change also affects the contents of Table 19.
The second change is to step 5a in Section 13. The MinLSArrival
check is meant only for LSAs received during flooding, and
should not be performed on those LSAs that the router itself
originates.
The third change is to step 8 in Section 13. Confusion between
routers as to which LSA instance is more recent can cause a
disastrous amount of flooding in a link-state protocol (see
[Ref26]). OSPF guards against this problem in two ways: a) the
LS age field is used like a TTL field in flooding, to eventually
remove looping LSAs from the network (see Section 13.3), and b)
routers refuse to accept LSA updates more frequently than once
every MinLSArrival seconds (see Section 13). However, there is
still one case in RFC2178 where disagreements regarding which
LSA is more recent can cause a lot of flooding traffic:
responding to old LSAs by reflooding the database copy. For
this reason, Step 8 of Section 13 has been amended to only
respond with the database copy when that copy has not been sent
in any Link State Update within the last MinLSArrival seconds.
G.2 Changes to external path preferences
There is still the possibility of a routing loop in RFC2178
when both a) virtual links are in use and b) the same external
route is being imported by multiple ASBRs, each of which is in a
separate area. To fix this problem, Section 16.4.1 has been
revised. To choose the correct ASBR/forwarding address, intra-
area paths through non-backbone areas are always preferred.
However, intra-area paths through the backbone area (Area 0) and
inter-area paths are now of equal preference, and must be
compared solely based on cost.
The reasoning behind this change is as follows. When virtual
links are in use, an intra-area backbone path for one router can
turn into an inter-area path in a router several hops closer to
the destination. Hence, intra-area backbone paths and inter-area
paths must be of equal preference. We can safely compare their
costs, preferring the path with the smallest cost, due to the
calculations in Section 16.3.
Thanks to Michael Briggs and Jeremy McCooey of the UNH
InterOperability Lab for pointing out this problem.
G.3 Incomplete resolution of virtual next hops
One of the functions of the calculation in Section 16.3 is to
determine the actual next hop(s) for those destinations whose
next hop was calculated as a virtual link in Sections 16.1 and
16.2. After completion of the calculation in Section 16.3, any
paths calculated in Sections 16.1 and 16.2 that still have
unresolved virtual next hops should be discarded.
G.4 Routing table lookup
The routing table lookup algorithm in Section 11.1 has been
modified to reflect current practice. The "best match" routing
table entry is now always selected to be the one providing the
most specific (longest) match. Suppose for example a router is
forwarding packets to the destination 192.9.1.1. A routing table
entry for 192.9.1/24 will always be a better match than the
routing table entry for 192.9/16, regardless of the routing
table entries' path-types. Note however that when multiple paths
are available for a given routing table entry, the calculations
in Sections 16.1, 16.2, and 16.4 always yield the paths having
the most preferential path-type. (Intra-area paths are the most
preferred, followed in order by inter-area, type 1 external and
type 2 external paths; see Section 11).
Security Considerations
All OSPF protocol exchanges are authenticated. OSPF supports
multiple types of authentication; the type of authentication in use
can be configured on a per network segment basis. One of OSPF's
authentication types, namely the Cryptographic authentication
option, is believed to be secure against passive attacks and provide
significant protection against active attacks. When using the
Cryptographic authentication option, each router appends a "message
digest" to its transmitted OSPF packets. Receivers then use the
shared secret key and received digest to verify that each received
OSPF packet is authentic.
The quality of the security provided by the Cryptographic
authentication option depends completely on the strength of the
message digest algorithm (MD5 is currently the only message digest
algorithm specified), the strength of the key being used, and the
correct implementation of the security mechanism in all
communicating OSPF implementations. It also requires that all
parties maintain the secrecy of the shared secret key.
None of the OSPF authentication types provide confidentiality. Nor
do they protect against traffic analysis. Key management is also not
addressed by this memo.
For more information, see Sections 8.1, 8.2, and Appendix D.
Author's Address
John Moy
Ascend Communications, Inc.
1 Robbins Road
Westford, MA 01886
Phone: 978-952-1367
Fax: 978-392-2075
EMail: jmoy@casc.com
Full Copyright Statement
Copyright (C) The Internet Society (1998). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph
are included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.