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,