Appendix F. Multiple Interfaces to Same Network
(2) The checksum field in the standard OSPF header is not
calculated, but is instead set to 0.
(3) The Key ID (see Figure 18) is set to the chosen key's
Key ID.
(4) The Auth Data Len field is set to the length in bytes of
the message digest that will be appended to the OSPF
packet. When using MD5 as the authentication algorithm,
Auth Data Len will be 16.
(5) The 32-bit Cryptographic sequence number (see Figure 18)
is set to a non-decreasing value (i.e., a value at least
as large as the last value sent out the interface). The
precise values to use in the cryptographic sequence
number field are implementation-specific. For example,
it may be based on a simple counter, or be based on the
system's clock.
(6) The message digest is then calculated and appended to
the OSPF packet. The authentication algorithm to be
used in calculating the digest is indicated by the key
itself. Input to the authentication algorithm consists
of the OSPF packet and the secret key. When using MD5 as
the authentication algorithm, the message digest
calculation proceeds as follows:
(a) The 16 byte MD5 key is appended to the OSPF packet.
(b) Trailing pad and length fields are added, as
specified in [Ref17].
(c) The MD5 authentication algorithm is run over the
concatenation of the OSPF packet, secret key, pad
and length fields, producing a 16 byte message
digest (see [Ref17]).
(d) The MD5 digest is written over the OSPF key (i.e.,
appended to the original OSPF packet). The digest is
not counted in the OSPF packet's length field, but
is included in the packet's IP length field. Any
trailing pad or length fields beyond the digest are
not counted or transmitted.
D.5 Message verification
When an OSPF packet has been received on an interface, it must
be authenticated. The authentication procedure is indicated by
the setting of Autype in the standard OSPF packet header, which
matches the setting of Autype for the receiving OSPF interface.
If an OSPF protocol packet is accepted as authentic, processing
of the packet continues as specified in Section 8.2. Packets
which fail authentication are discarded.
D.5.1 Verifying Null authentication
When using Null authentication, the checksum field in the
OSPF header must be verified. It must be set to the 16-bit
one's complement of the one's complement sum of all the 16-
bit words in the packet, excepting the authentication field.
(If the packet's length is not an integral number of 16-bit
words, the packet is padded with a byte of zero before
checksumming.)
D.5.2 Verifying Simple password authentication
When using Simple password authentication, the received OSPF
packet is authenticated as follows:
(1) The checksum field in the OSPF header must be verified.
It must be set to the 16-bit one's complement of the
one's complement sum of all the 16-bit words in the
packet, excepting the authentication field. (If the
packet's length is not an integral number of 16-bit
words, the packet is padded with a byte of zero before
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 RFC 1583.
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,