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.
(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.
(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.