Appendix E. Algorithm for Assigning Link State IDs

0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0 | Key ID | Auth Data Len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Cryptographic sequence number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 18: Usage of the Authentication field in the OSPF packet header when Cryptographic Authentication is employed

whenever the neighbor's state transitions to "Down". Whenever an OSPF packet is accepted as authentic, the cryptographic sequence number is set to the received packet's sequence number.

This specification does not provide a rollover procedure for the cryptographic sequence number. When the cryptographic sequence number that the router is sending hits the maximum value, the router should reset the cryptographic sequence number that it is sending back to 0. After this is done, the router's neighbors will reject the router's OSPF packets for a period of RouterDeadInterval, and then the router will be forced to reestablish all adjacencies over the interface. However, it is expected that many implementations will use "seconds since reboot" (or "seconds since 1960", etc.) as the cryptographic sequence number. Such a choice will essentially prevent rollover, since the cryptographic sequence number field is 32 bits in length.

The OSPF Cryptographic authentication option does not provide confidentiality.

When cryptographic authentication is used, the 64-bit Authentication field in the standard OSPF packet header is redefined as shown in Figure 18. The new field definitions are as follows:

Key ID This field identifies the algorithm and secret key used to create the message digest appended to the OSPF packet. Key Identifiers are unique per-interface (or equivalently, per- subnet).

Auth Data Len The length in bytes of the message digest appended to the OSPF packet.

Cryptographic sequence number An unsigned 32-bit non-decreasing sequence number. Used to guard against replay attacks.

The message digest appended to the OSPF packet is not actually considered part of the OSPF protocol packet: the message digest is not included in the OSPF header's packet length, although it is included in the packet's IP header length field.

Each key is identified by the combination of interface and Key ID. An interface may have multiple keys active at any one time. This enables smooth transition from one key to another. Each key has four time constants associated with it. These time constants can be expressed in terms of a time-of-day clock, or in terms of a router's local clock (e.g., number of seconds since last reboot):

KeyStartAccept The time that the router will start accepting packets that have been created with the given key.

KeyStartGenerate The time that the router will start using the key for packet generation.

KeyStopGenerate The time that the router will stop using the key for packet generation.

KeyStopAccept The time that the router will stop accepting packets that have been created with the given key.

In order to achieve smooth key transition, KeyStartAccept should be less than KeyStartGenerate and KeyStopGenerate should be less than KeyStopAccept. If KeyStopGenerate and KeyStopAccept are left unspecified, the key's lifetime is infinite. When a new key replaces an old, the KeyStartGenerate time for the new key must be less than or equal to the KeyStopGenerate time of the old key.

Key storage should persist across a system restart, warm or cold, to avoid operational issues. In the event that the last key associated with an interface expires, it is unacceptable to revert to an unauthenticated condition, and not advisable to disrupt routing. Therefore, the router should send a "last authentication key expiration" notification to the network manager and treat the key as having an infinite lifetime until the lifetime is extended, the key is deleted by network management, or a new key is configured.

D.4 Message generation

After building the contents of an OSPF packet, the authentication procedure indicated by the sending interface's Autype value is called before the packet is sent. The authentication procedure modifies the OSPF packet as follows.

D.4.1 Generating Null authentication

When using Null authentication, the packet is modified as follows:

(1) The Autype field in the standard OSPF header is set to 0.

(2) The checksum field in the standard OSPF header is set to the standard IP checksum of the entire contents of the packet, starting with the OSPF packet header but excluding the 64-bit authentication field. This checksum is calculated as 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.4.2 Generating Simple password authentication

When using Simple password authentication, the packet is modified as follows:

(1) The Autype field in the standard OSPF header is set to 1.

(3) The 64-bit authentication field in the OSPF packet header is set to the 64-bit password (i.e., authentication key) that has been configured for the interface.

D.4.3 Generating Cryptographic authentication

When using Cryptographic authentication, there may be multiple keys configured for the interface. In this case, among the keys that are valid for message generation (i.e, that have KeyStartGenerate <= current time < KeyStopGenerate) choose the one with the most recent KeyStartGenerate time. Using this key, modify the packet as follows:

(1) The Autype field in the standard OSPF header is set to 2.