draft-ietf-ospf-rfc6506bis-05.txt   rfc7166.txt 
OSPF Working Group M. Bhatia Internet Engineering Task Force (IETF) M. Bhatia
Internet-Draft Alcatel-Lucent Request for Comments: 7166 Alcatel-Lucent
Obsoletes: 6506 (if approved) V. Manral Obsoletes: 6506 V. Manral
Intended status: Standards Track Hewlett Packard Category: Standards Track Ionos Corp.
Expires: June 16, 2014 A. Lindem ISSN: 2070-1721 A. Lindem
Ericsson Ericsson
December 13, 2013 March 2014
Supporting Authentication Trailer for OSPFv3 Supporting Authentication Trailer for OSPFv3
draft-ietf-ospf-rfc6506bis-05.txt
Abstract Abstract
Currently, OSPF for IPv6 (OSPFv3) uses IPsec as the only mechanism Currently, OSPF for IPv6 (OSPFv3) uses IPsec as the only mechanism
for authenticating protocol packets. This behavior is different from for authenticating protocol packets. This behavior is different from
authentication mechanisms present in other routing protocols (OSPFv2, authentication mechanisms present in other routing protocols (OSPFv2,
Intermediate System to Intermediate System (IS-IS), RIP, and Routing Intermediate System to Intermediate System (IS-IS), RIP, and Routing
Information Protocol Next Generation (RIPng)). In some environments, Information Protocol Next Generation (RIPng)). In some environments,
it has been found that IPsec is difficult to configure and maintain it has been found that IPsec is difficult to configure and maintain
and thus cannot be used. This document defines an alternative and thus cannot be used. This document defines an alternative
mechanism to authenticate OSPFv3 protocol packets so that OSPFv3 does mechanism to authenticate OSPFv3 protocol packets so that OSPFv3 does
not only depend upon IPsec for authentication. not depend only upon IPsec for authentication.
The OSPFv3 Authentication Trailer was originally defined in RFC 6506. The OSPFv3 Authentication Trailer was originally defined in RFC 6506.
This document obsoletes RFC 6506 by providing a revised definition This document obsoletes RFC 6506 by providing a revised definition,
including clarifications and refinements of the procedures. including clarifications and refinements of the procedures.
Status of this Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering This is an Internet Standards Track document.
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 5741.
This Internet-Draft will expire on June 16, 2014. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc7166.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction ....................................................3
1.1. Requirements . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Requirements ...............................................4
1.2. Summary of Changes from RFC 6506 . . . . . . . . . . . . . 4 1.2. Summary of Changes from RFC 6506 ...........................4
2. Proposed Solution . . . . . . . . . . . . . . . . . . . . . . 5 2. Proposed Solution ...............................................5
2.1. AT-Bit in Options Field . . . . . . . . . . . . . . . . . 5 2.1. AT-Bit in Options Field ....................................5
2.2. Basic Operation . . . . . . . . . . . . . . . . . . . . . 6 2.2. Basic Operation ............................................6
2.3. IPv6 Source Address Protection . . . . . . . . . . . . . . 6 2.3. IPv6 Source Address Protection .............................6
3. OSPFv3 Security Association . . . . . . . . . . . . . . . . . 8 3. OSPFv3 Security Association .....................................7
4. Authentication Procedure . . . . . . . . . . . . . . . . . . . 10 4. Authentication Procedure ........................................9
4.1. Authentication Trailer . . . . . . . . . . . . . . . . . . 10 4.1. Authentication Trailer .....................................9
4.1.1. Sequence Number Wrap . . . . . . . . . . . . . . . . . 11 4.1.1. Sequence Number Wrap ...............................11
4.2. OSPFv3 Header Checksum and LLS Data Block Checksum . . . . 12 4.2. OSPFv3 Header Checksum and LLS Data Block Checksum ........11
4.3. Cryptographic Authentication Procedure . . . . . . . . . . 12 4.3. Cryptographic Authentication Procedure ....................12
4.4. Cross-Protocol Attack Mitigation . . . . . . . . . . . . . 13 4.4. Cross-Protocol Attack Mitigation ..........................12
4.5. Cryptographic Aspects . . . . . . . . . . . . . . . . . . 13 4.5. Cryptographic Aspects .....................................12
4.6. Message Verification . . . . . . . . . . . . . . . . . . . 15 4.6. Message Verification ......................................15
5. Migration and Backward Compatibility . . . . . . . . . . . . . 18 5. Migration and Backward Compatibility ...........................16
6. Security Considerations . . . . . . . . . . . . . . . . . . . 19 6. Security Considerations ........................................17
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 7. IANA Considerations ............................................18
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21 8. References .....................................................19
8.1. Normative References . . . . . . . . . . . . . . . . . . . 21 8.1. Normative References ......................................19
8.2. Informative References . . . . . . . . . . . . . . . . . . 21 8.2. Informative References ....................................19
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 23 Appendix A. Acknowledgments .......................................22
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 25
1. Introduction 1. Introduction
Unlike Open Shortest Path First version 2 (OSPFv2) [RFC2328], OSPF Unlike Open Shortest Path First version 2 (OSPFv2) [RFC2328], OSPF
for IPv6 (OSPFv3) [RFC5340] does not include the AuType and for IPv6 (OSPFv3) [RFC5340] does not include the AuType and
Authentication fields in its headers for authenticating protocol Authentication fields in its headers for authenticating protocol
packets. Instead, OSPFv3 relies on the IPsec protocols packets. Instead, OSPFv3 relies on the IPsec protocols
Authentication Header (AH) [RFC4302] and Encapsulating Security Authentication Header (AH) [RFC4302] and Encapsulating Security
Payload (ESP) [RFC4303] to provide integrity, authentication, and/or Payload (ESP) [RFC4303] to provide integrity, authentication, and/or
confidentiality. confidentiality.
[RFC4552] describes how IPv6 AH and ESP extension headers can be used [RFC4552] describes how IPv6 AH and ESP extension headers can be used
to provide authentication and/or confidentiality to OSPFv3. to provide authentication and/or confidentiality to OSPFv3.
However, there are some environments, e.g., Mobile Ad Hoc Networks However, there are some environments, e.g., Mobile Ad Hoc Networks
(MANETs), where IPsec is difficult to configure and maintain, and (MANETs), where IPsec is difficult to configure and maintain; this
this mechanism cannot be used. mechanism cannot be used in such environments.
[RFC4552] discusses, at length, the reasoning behind using manually [RFC4552] discusses, at length, the reasoning behind using manually
configured keys, rather than some automated key management protocol configured keys, rather than some automated key management protocol
such as Internet Key Exchange version 2 (IKEv2) [RFC5996]. The such as Internet Key Exchange version 2 (IKEv2) [RFC5996]. The
primary problem is the lack of a suitable key management mechanism, primary problem is the lack of a suitable key management mechanism,
as OSPFv3 adjacencies are formed on a one-to-many basis and most key as OSPFv3 adjacencies are formed on a one-to-many basis and most key
management mechanisms are designed for a one-to-one communication management mechanisms are designed for a one-to-one communication
model. This forces the system administrator to use manually model. This forces the system administrator to use manually
configured security associations (SAs) and cryptographic keys to configured Security Associations (SAs) and cryptographic keys to
provide the authentication and, if desired, confidentiality services. provide the authentication and, if desired, confidentiality services.
Regarding replay protection, [RFC4552] states that: Regarding replay protection, [RFC4552] states that:
Since it is not possible using the current standards to provide Since it is not possible using the current standards to provide
complete replay protection while using manual keying, the proposed complete replay protection while using manual keying, the proposed
solution will not provide protection against replay attacks. solution will not provide protection against replay attacks.
Since there is no replay protection provided there are a number of Since there is no replay protection provided, there are a number of
vulnerabilities in OSPFv3 that have been discussed in [RFC6039]. vulnerabilities in OSPFv3 that have been discussed in [RFC6039].
While techniques exist to identify ESP Null packets [RFC5879], these While techniques exist to identify ESP-NULL packets [RFC5879], these
techniques are generally not implemented in the data planes of OSPFv3 techniques are generally not implemented in the data planes of OSPFv3
routers. This makes it very difficult for implementations to examine routers. This makes it very difficult for implementations to examine
OSPFv3 packet and prioritize certain OSPFv3 packet types, e.g., Hello OSPFv3 packets and prioritize certain OSPFv3 packet types, e.g.,
packets, over the other types. Hello packets, over the other types.
This document defines a new mechanism that works similarly to OSPFv2 This document defines a mechanism that works similarly to OSPFv2
[RFC5709] to provide authentication to the OSPFv3 packets and [RFC5709] to provide authentication to OSPFv3 packets and solves the
attempts to solve the problems related to replay protection and problems related to replay protection and deterministically
deterministically disambiguating different OSPFv3 packets as disambiguating different OSPFv3 packets as described above.
described above.
This document adds support for the Secure Hash Algorithms (SHAs) This document adds support for the Secure Hash Algorithms (SHAs)
defined in the US NIST Secure Hash Standard (SHS), which is specified defined in the US NIST Secure Hash Standard (SHS), which is specified
by NIST FIPS 180-3. [FIPS-180-3] includes SHA-1, SHA-224, SHA-256, by NIST FIPS 180-4. [FIPS-180-4] includes SHA-1, SHA-224, SHA-256,
SHA-384, and SHA-512. The Hashed Message Authentication Code (HMAC) SHA-384, and SHA-512. The Hashed Message Authentication Code (HMAC)
authentication mode defined in NIST FIPS 198-1 [FIPS-198-1] is used. authentication mode defined in NIST FIPS 198-1 [FIPS-198-1] is used.
1.1. Requirements 1.1. Requirements
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
1.2. Summary of Changes from RFC 6506 1.2. Summary of Changes from RFC 6506
This document includes the following changes from RFC 6506 [RFC6506]: This document includes the following changes from RFC 6506 [RFC6506]:
1. Sections 2.2 and 4.2 explicitly state that the Link-Local 1. Sections 2.2 and 4.2 explicitly state that the Link-Local
Signaling (LLS) block checksum calculation is omitted when an Signaling (LLS) block checksum calculation is omitted when an
OSPFv3 authentication trailer is used for OSPFv3 authentication. OSPFv3 Authentication Trailer is used for OSPFv3 authentication.
The LLS block is included in the authentication digest The LLS data block is included in the authentication digest
calculation and computation of a checksum is unnecessary. calculation, and computation of a checksum is unnecessary.
Clarification of this issue was documented in an erratum. Clarification of this issue was documented in an erratum.
2. Section 3 previously recommended usage of an expired key for 2. Section 3 previously recommended usage of an expired key for
transmitted OSPFv3 packets when no valid keys existed. This transmitted OSPFv3 packets when no valid keys existed. This
statement has been removed. statement has been removed.
3. Section 4.5 includes a correction to the key preparation to use 3. Section 4.5 includes a correction to the key preparation to use
the protocol specific key (Ks) rather than the key (K) as the the Protocol-Specific Authentication Key (Ks) rather than the
initial key (Ko). This problem was also documented in an Authentication Key (K) as the initial key (Ko). This problem was
erratum. also documented in an erratum.
4. Section 4.5 also includes a discussion of the choice of key 4. Section 4.5 also includes a discussion of the choice of key length
length to be the hash length (L) rather than the block size (B). to be the hash length (L) rather than the block size (B). The
The discussion of this choice was included to clarify an issue discussion of this choice was included to clarify an issue raised
raised in a rejected erratum. in a rejected erratum.
5. Section 4.1 and 4.6 indicate that sequence number checking is 5. Sections 4.1 and 4.6 indicate that sequence number checking is
dependent on OSPFv3 packet type in order to account for packet dependent on OSPFv3 packet type in order to account for packet
prioritization as specified in [RFC4222]. This was an omission prioritization as specified in [RFC4222]. This was an omission
from RFC 6506 [RFC6506]. from RFC 6506 [RFC6506].
6. Section 4.6 explicitly states that OSPFv3 packets with a non- 6. Section 4.6 explicitly states that OSPFv3 packets with a
existent or expired Security Association (SA) will be dropped. nonexistent or expired Security Association (SA) will be dropped.
7. Section 5 includes guidance on precisely the actions required for 7. Section 5 includes guidance on the precise actions required for an
an OSPFv3 router providing a backward compatible transition mode. OSPFv3 router providing a backward-compatible transition mode.
2. Proposed Solution 2. Proposed Solution
To perform non-IPsec Cryptographic Authentication, OSPFv3 routers To perform non-IPsec Cryptographic Authentication, OSPFv3 routers
append a special data block, henceforth referred to as the append a special data block, henceforth referred to as the
Authentication Trailer, to the end of the OSPFv3 packets. The length Authentication Trailer, to the end of the OSPFv3 packets. The length
of the Authentication Trailer is not included in the length of the of the Authentication Trailer is not included in the length of the
OSPFv3 packet but is included in the IPv6 payload length, as shown in OSPFv3 packet but is included in the IPv6 payload length, as shown in
Figure 1. Figure 1.
skipping to change at page 5, line 29 skipping to change at page 5, line 29
| OSPFv3 Header | ^ ^ | OSPFv3 Header | | OSPFv3 Header | ^ ^ | OSPFv3 Header |
| Length = OL | | | | Length = OL | | Length = OL | | | | Length = OL |
| | | OSPFv3 | | | | | | OSPFv3 | | |
|.....................| | Packet | |......................| |.....................| | Packet | |......................|
| | | Length | | | | | | Length | | |
| OSPFv3 Packet | | | | OSPFv3 Packet | | OSPFv3 Packet | | | | OSPFv3 Packet |
| | v v | | | | v v | |
+---------------------+ -- -- +----------------------+ +---------------------+ -- -- +----------------------+
| | ^ ^ | | | | ^ ^ | |
| Optional LLS | | LLS Data | | Optional LLS | | Optional LLS | | LLS Data | | Optional LLS |
| LLS Block Len = LL | | Block | | LLS Block Len = LL | | LL = LLS Data | | Block | | LL = LLS Data |
| | v Length v | | | Block Length | v Length v | Block Length |
+---------------------+ -- -- +----------------------+ +---------------------+ -- -- +----------------------+
^ | | ^ | |
AL = PL - (OL + LL) | | Authentication | AL = PL - (OL + LL) | | Authentication |
| | AL = Fixed Trailer + | | | AL = Fixed Trailer + |
v | Digest Length | v | Digest Length |
-- +----------------------+ -- +----------------------+
Figure 1: Authentication Trailer in OSPFv3 Figure 1: Authentication Trailer in OSPFv3
The presence of the Link-Local Signaling (LLS) [RFC5613] block is The presence of the Link-Local Signaling (LLS) [RFC5613] block is
determined by the L-bit setting in the OSPFv3 Options field in OSPFv3 determined by the L-bit setting in the OSPFv3 Options field in OSPFv3
Hello and Database Description packets. If present, the LLS data Hello and Database Description packets. If present, the LLS data
block is included along with the OSPFv3 packet in the Cryptographic block is included along with the OSPFv3 packet in the Cryptographic
Authentication computation. Authentication computation.
2.1. AT-Bit in Options Field 2.1. AT-Bit in Options Field
A new AT-bit (AT stands for Authentication Trailer) is introduced RFC 6506 introduced the AT-bit ("AT" stands for "Authentication
into the OSPFv3 Options field. OSPFv3 routers MUST set the AT-bit in Trailer") into the OSPFv3 Options field. OSPFv3 routers MUST set the
OSPFv3 Hello and Database Description packets to indicate that all AT-bit in OSPFv3 Hello and Database Description packets to indicate
the packets on this link will include an Authentication Trailer. For that all the packets on this link will include an Authentication
OSPFv3 Hello and Database Description packets, the AT-bit indicates Trailer. For OSPFv3 Hello and Database Description packets, the
the AT is present. For other OSPFv3 packet types, the OSPFv3 AT-bit AT-bit indicates that the AT is present. For other OSPFv3 packet
setting from the OSPFv3 Hello/Database Description setting is types, the OSPFv3 AT-bit setting from the OSPFv3 Hello/Database
preserved in the OSPFv3 neighbor data structure. OSPFv3 packet types Description setting is preserved in the OSPFv3 neighbor data
that don't include an OSPFv3 Options field will use the setting from structure. OSPFv3 packet types that don't include an OSPFv3 Options
the neighbor data structure to determine whether or not the AT is field will use the setting from the neighbor data structure to
expected. determine whether or not the AT is expected.
0 1 2 0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+--+-+--+-+-+--+-+-+--+-+--+ +-+-+-+-+-+-+-+-+-+-+-+-+-+--+-+--+-+-+--+-+-+--+-+--+
| | | | | | | | | | | | | |AT|L|AF|*|*|DC|R|N|MC|E|V6| | | | | | | | | | | | | | |AT|L|AF|*|*|DC|R|N|MC|E|V6|
+-+-+-+-+-+-+-+-+-+-+-+-+-+--+-+--+-+-+--+-+-+--+-+--+ +-+-+-+-+-+-+-+-+-+-+-+-+-+--+-+--+-+-+--+-+-+--+-+--+
Figure 2: OSPFv3 Options Field Figure 2: OSPFv3 Options Field
The AT-bit, as shown in the figure above, MUST be set in all OSPFv3 The AT-bit, as shown in the figure above, MUST be set in all OSPFv3
Hello and Database Description packets that contain an Authentication Hello and Database Description packets that contain an Authentication
Trailer. Trailer.
2.2. Basic Operation 2.2. Basic Operation
The procedure followed for computing the Authentication Trailer is The procedure followed for computing the Authentication Trailer is
much the same as described in [RFC5709] and [RFC2328]. One much the same as those described in [RFC5709] and [RFC2328]. One
difference is that the LLS data block, if present, is included in the difference is that the LLS data block, if present, is included in the
Cryptographic Authentication computation. Cryptographic Authentication computation.
The way the authentication data is carried in the Authentication The way the authentication data is carried in the Authentication
Trailer is very similar to how it is done in case of [RFC2328]. The Trailer is very similar to how it is done in the case of [RFC2328].
only difference between the OSPFv2 Authentication Trailer and the The only difference between the OSPFv2 Authentication Trailer and the
OSPFv3 Authentication Trailer is that information in addition to the OSPFv3 Authentication Trailer is that information in addition to the
message digest is included. The additional information in the OSPFv3 message digest is included. The additional information in the OSPFv3
Authentication Trailer is included in the message digest computation Authentication Trailer is included in the message digest computation
and is therefore protected by OSPFv3 Cryptographic Authentication as and is therefore protected by OSPFv3 Cryptographic Authentication as
described herein. described herein.
Consistent with OSPFv2 Cryptographic Authentication [RFC2328] and Consistent with OSPFv2 Cryptographic Authentication [RFC2328] and
Link-Local Signaling Cryptographic Authentication [RFC5613], checksum Link-Local Signaling Cryptographic Authentication [RFC5613], checksum
calculation and verification are omitted for both the OSPFv3 header calculation and verification are omitted for both the OSPFv3 header
checksum and the LLS Data Block when the OSPFv3 authentication checksum and the LLS data block when the OSPFv3 authentication
mechanism described in this specification is used. mechanism described in this specification is used.
2.3. IPv6 Source Address Protection 2.3. IPv6 Source Address Protection
While OSPFv3 always uses the Router ID to identify OSPFv3 neighbors, While OSPFv3 always uses the Router ID to identify OSPFv3 neighbors,
the IPv6 source address is learned from OSPFv3 Hello packets and the IPv6 source address is learned from OSPFv3 Hello packets and
copied into the neighbor data structure [RFC5340]. Hence, OSPFv3 is copied into the neighbor data structure [RFC5340]. Hence, OSPFv3 is
susceptible to Man-in-the-Middle attacks where the IPv6 source susceptible to Man-in-the-Middle attacks where the IPv6 source
address is modified. To thwart such attacks, the IPv6 source address address is modified. To thwart such attacks, the IPv6 source address
will be included in the message digest calculation and protected by will be included in the message digest calculation and protected by
skipping to change at page 8, line 27 skipping to change at page 7, line 31
The receiver determines the active SA by looking at the SA ID The receiver determines the active SA by looking at the SA ID
field in the incoming protocol packet. field in the incoming protocol packet.
The sender, based on the active configuration, selects an SA to The sender, based on the active configuration, selects an SA to
use and puts the correct Key ID value associated with the SA in use and puts the correct Key ID value associated with the SA in
the OSPFv3 protocol packet. If multiple valid and active OSPFv3 the OSPFv3 protocol packet. If multiple valid and active OSPFv3
SAs exist for a given interface, the sender may use any of those SAs exist for a given interface, the sender may use any of those
SAs to protect the packet. SAs to protect the packet.
Using SA IDs makes changing keys while maintaining protocol Using SA IDs makes changing keys while maintaining protocol
operation convenient. Each SA ID specifies two independent parts, operation convenient. Each SA ID specifies two independent parts:
the authentication algorithm and the Authentication Key, as the authentication algorithm and the Authentication Key, as
explained below. explained below.
Normally, an implementation would allow the network operator to Normally, an implementation would allow the network operator to
configure a set of keys in a key chain, with each key in the chain configure a set of keys in a key chain, with each key in the chain
having a fixed lifetime. The actual operation of these mechanisms having a fixed lifetime. The actual operation of these mechanisms
is outside the scope of this document. is outside the scope of this document.
Note that each SA ID can indicate a key with a different Note that each SA ID can indicate a key with a different
authentication algorithm. This allows the introduction of new authentication algorithm. This allows the introduction of new
skipping to change at page 9, line 14 skipping to change at page 8, line 19
* HMAC-SHA-256, * HMAC-SHA-256,
* HMAC-SHA-384, and * HMAC-SHA-384, and
* HMAC-SHA-512. * HMAC-SHA-512.
o Authentication Key o Authentication Key
This value denotes the Cryptographic Authentication Key associated This value denotes the Cryptographic Authentication Key associated
with this OSPFv3 SA. The length of this key is variable and with this OSPFv3 SA. The length of this key is variable and
depends upon the authentication algorithm specified by the OSPFv3 depends upon the authentication algorithm specified by the
SA. OSPFv3 SA.
o KeyStartAccept o KeyStartAccept
The time that this OSPFv3 router will accept packets that have This value indicates the time that this OSPFv3 router will accept
been created with this OSPFv3 SA. packets that have been created with this OSPFv3 SA.
o KeyStartGenerate o KeyStartGenerate
The time that this OSPFv3 router will begin using this OSPFv3 SA This value indicates the time that this OSPFv3 router will begin
for OSPFv3 packet generation. using this OSPFv3 SA for OSPFv3 packet generation.
o KeyStopGenerate o KeyStopGenerate
The time that this OSPFv3 router will stop using this OSPFv3 SA This value indicates the time that this OSPFv3 router will stop
for OSPFv3 packet generation. using this OSPFv3 SA for OSPFv3 packet generation.
o KeyStopAccept o KeyStopAccept
The time that this OSPFv3 router will stop accepting packets This value indicates the time that this OSPFv3 router will stop
generated with this OSPFv3 SA. accepting packets generated with this OSPFv3 SA.
In order to achieve smooth key transition, KeyStartAccept SHOULD be In order to achieve smooth key transition, KeyStartAccept SHOULD
less than KeyStartGenerate, and KeyStopGenerate SHOULD be less than be less than KeyStartGenerate, and KeyStopGenerate SHOULD be less
KeyStopAccept. If KeyStartGenerate or KeyStartAccept are left than KeyStopAccept. If KeyStartGenerate or KeyStartAccept is left
unspecified, the time will default to 0, and the key will be used unspecified, the time will default to 0, and the key will be used
immediately. If KeyStopGenerate or KeyStopAccept are left immediately. If KeyStopGenerate or KeyStopAccept is left
unspecified, the time will default to infinity, and the key's unspecified, the time will default to infinity, and the key's
lifetime will be infinite. When a new key replaces an old, the lifetime will be infinite. When a new key replaces an old key,
KeyStartGenerate time for the new key MUST be less than or equal to the KeyStartGenerate time for the new key MUST be less than or
the KeyStopGenerate time of the old key. equal to the KeyStopGenerate time of the old key.
Key storage SHOULD persist across a system restart, warm or cold, to Key storage SHOULD persist across a system restart, warm or cold,
avoid operational issues. In the event that the last key associated to avoid operational issues. In the event that the last key
with an interface expires, the network operator SHOULD be notified associated with an interface expires, the network operator SHOULD
and the OSPFv3 packet MUST NOT be transmitted unauthenticated. be notified, and the OSPFv3 packet MUST NOT be transmitted
unauthenticated.
4. Authentication Procedure 4. Authentication Procedure
4.1. Authentication Trailer 4.1. Authentication Trailer
The Authentication Trailer that is appended to the OSPFv3 protocol The Authentication Trailer that is appended to the OSPFv3 protocol
packet is described below: packet is described below:
0 1 2 3 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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Authentication Type | Auth Data Len | | Authentication Type | Auth Data Len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Security Association ID | | Reserved | Security Association ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cryptographic Sequence Number (High-Order 32 Bits) | | Cryptographic Sequence Number (High-Order 32 Bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cryptographic Sequence Number (Low-Order 32 Bits) | | Cryptographic Sequence Number (Low-Order 32 Bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| Authentication Data (Variable) | | Authentication Data (Variable) |
~ ~ ~ ~
| | | |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: Authentication Trailer Format Figure 3: Authentication Trailer Format
The various fields in the Authentication Trailer are: The various fields in the Authentication Trailer are as follows:
o Authentication Type o Authentication Type
16-bit field identifying the type of authentication. The This 16-bit field identifies the type of authentication. The
following values are defined in this specification: following values are defined in this specification:
0 - Reserved. 0 - Reserved.
1 - HMAC Cryptographic Authentication as described herein. 1 - HMAC Cryptographic Authentication as described herein.
o Auth Data Len o Auth Data Len
The length in octets of the Authentication Trailer (AT) including This is the length in octets of the Authentication Trailer (AT),
both the 16-octet fixed header and the variable length message including both the 16-octet fixed header and the variable-length
digest. message digest.
o Reserved o Reserved
This field is reserved. It SHOULD be set to 0 when sending This field is reserved. It SHOULD be set to 0 when sending
protocol packets and MUST be ignored when receiving protocol protocol packets and MUST be ignored when receiving protocol
packets. packets.
o Security Association Identifier (SA ID) o Security Association Identifier (SA ID)
16-bit field that maps to the authentication algorithm and the This 16-bit field maps to the authentication algorithm and the
secret key used to create the message digest appended to the secret key used to create the message digest appended to the
OSPFv3 protocol packet. OSPFv3 protocol packet.
Though the SA ID implicitly implies the algorithm, the HMAC output Though the SA ID implies the algorithm, the HMAC output size
size should not be used by implementers as an implicit hint should not be used by implementers as an implicit hint, because
because additional algorithms may be defined in the future that additional algorithms may be defined in the future that have the
have the same output size. same output size.
o Cryptographic Sequence Number o Cryptographic Sequence Number
64-bit strictly increasing sequence number that is used to guard This is a 64-bit strictly increasing sequence number that is used
against replay attacks. The 64-bit sequence number MUST be to guard against replay attacks. The 64-bit sequence number MUST
incremented for every OSPFv3 packet sent by the OSPFv3 router. be incremented for every OSPFv3 packet sent by the OSPFv3 router.
Upon reception, the sequence number MUST be greater than the Upon reception, the sequence number MUST be greater than the
sequence number in the last accepted OSPFv3 packet of the same sequence number in the last accepted OSPFv3 packet of the same
OSPFv3 packet type from the sending OSPFv3 neighbor. Otherwise, OSPFv3 packet type from the sending OSPFv3 neighbor. Otherwise,
the OSPFv3 packet is considered a replayed packet and dropped. the OSPFv3 packet is considered a replayed packet and dropped.
OSPFv3 packets of different types may arrive out of order if they OSPFv3 packets of different types may arrive out of order if they
are prioritized as recommended in [RFC4222]. are prioritized as recommended in [RFC4222].
OSPFv3 routers implementing this specification MUST use available OSPFv3 routers implementing this specification MUST use available
mechanisms to preserve the sequence number's strictly increasing mechanisms to preserve the sequence number's strictly increasing
property for the deployed life of the OSPFv3 router (including property for the deployed life of the OSPFv3 router (including
cold restarts). One mechanism for accomplishing this would be to cold restarts). One mechanism for accomplishing this would be to
use the high-order 32 bits of the sequence number as a wrap/boot use the high-order 32 bits of the sequence number as a wrap/boot
count that is incremented anytime the OSPFv3 router loses its count that is incremented anytime the OSPFv3 router loses its
sequence number state. Sequence number wrap is described in sequence number state. Sequence number wrap is described in
Section 4.1.1. Section 4.1.1.
o Authentication Data o Authentication Data
Variable data that is carrying the digest for the protocol packet This field contains variable data that is carrying the digest for
and optional LLS data block. the protocol packet and optional LLS data block.
4.1.1. Sequence Number Wrap 4.1.1. Sequence Number Wrap
When incrementing the sequence number for each transmitted OSPFv3 When incrementing the sequence number for each transmitted OSPFv3
packet, the sequence number should be treated as an unsigned 64-bit packet, the sequence number should be treated as an unsigned 64-bit
value. If the lower-order 32-bit value wraps, the higher-order value. If the lower-order 32-bit value wraps, the higher-order
32-bit value should be incremented and saved in non-volatile storage. 32-bit value should be incremented and saved in non-volatile storage.
If by some chance the OSPFv3 router is deployed long enough that If by some chance the OSPFv3 router is deployed long enough that
there is a possibility that the 64-bit sequence number may wrap, all there is a possibility that the 64-bit sequence number may wrap, all
keys, independent of their key distribution mechanism, MUST be reset keys, independent of their key distribution mechanism, MUST be reset
to avoid the possibility of replay attacks. Once the keys have been to avoid the possibility of replay attacks. Once the keys have been
changed, the higher-order sequence number can be reset to 0 and saved changed, the higher-order sequence number can be reset to 0 and saved
to non-volatile storage. to non-volatile storage.
4.2. OSPFv3 Header Checksum and LLS Data Block Checksum 4.2. OSPFv3 Header Checksum and LLS Data Block Checksum
Both the checksum calculation and verification are omitted for the Both the checksum calculation and verification are omitted for the
OSPFv3 header checksum and the LLS Data Block checksum [RFC5613] when OSPFv3 header checksum and the LLS data block checksum [RFC5613] when
the OSPFv3 authentication mechanism described in this specification the OSPFv3 authentication mechanism described in this specification
is used. This implies: is used. This implies the following:
o For OSPFv3 packets to be transmitted, the OSPFv3 header checksum o For OSPFv3 packets to be transmitted, the OSPFv3 header checksum
computation is omitted, and the OSPFv3 header checksum SHOULD be computation is omitted, and the OSPFv3 header checksum SHOULD be
set to 0 prior to computation of the OSPFv3 Authentication Trailer set to 0 prior to computation of the OSPFv3 Authentication Trailer
message digest. message digest.
o For OSPFv3 packets including an LLS Data Block to be transmitted, o For OSPFv3 packets including an LLS data block to be transmitted,
the OSPFv3 LLS Data Block checksum computation is omitted, and the the OSPFv3 LLS data block checksum computation is omitted, and the
OSPFv3 LLS Data Block checksum SHOULD be set to 0 prior to OSPFv3 LLS data block checksum SHOULD be set to 0 prior to
computation of the OSPFv3 Authentication Trailer message digest. computation of the OSPFv3 Authentication Trailer message digest.
o For received OSPFv3 packets including an OSPFv3 Authentication o For received OSPFv3 packets including an OSPFv3 Authentication
Trailer, OSPFv3 header checksum verification MUST be omitted. Trailer, OSPFv3 header checksum verification MUST be omitted.
However, if the OSPFv3 packet does include a non-zero OSPFv3 However, if the OSPFv3 packet does include a non-zero OSPFv3
header checksum, it will not be modified by the receiver and will header checksum, it will not be modified by the receiver and will
simply be included in the OSPFv3 Authentication Trailer message simply be included in the OSPFv3 Authentication Trailer message
digest verification. digest verification.
o For received OSPFv3 packets including an LLS Data Block and OSPFv3 o For received OSPFv3 packets including an LLS data block and OSPFv3
Authentication Trailer, LLS Data Block checksum verification MUST Authentication Trailer, LLS data block checksum verification MUST
be omitted. However, if the OSPFv3 packet does include an LLS be omitted. However, if the OSPFv3 packet does include an LLS
Block with a non-zero checksum, it will not be modified by the data block with a non-zero checksum, it will not be modified by
receiver and will simply be included in the OSPFv3 Authentication the receiver and will simply be included in the OSPFv3
Trailer message digest verification. Authentication Trailer message digest verification.
4.3. Cryptographic Authentication Procedure 4.3. Cryptographic Authentication Procedure
As noted earlier, the SA ID maps to the authentication algorithm and As noted earlier, the SA ID maps to the authentication algorithm and
the secret key used to generate and verify the message digest. This the secret key used to generate and verify the message digest. This
specification discusses the computation of OSPFv3 Cryptographic specification discusses the computation of OSPFv3 Cryptographic
Authentication data when any of the NIST SHS family of algorithms is Authentication data when any of the NIST SHS family of algorithms is
used in the Hashed Message Authentication Code (HMAC) mode. used in the Hashed Message Authentication Code (HMAC) mode.
The currently valid algorithms (including mode) for OSPFv3 The currently valid algorithms (including mode) for OSPFv3
skipping to change at page 14, line 12 skipping to change at page 13, line 27
Opad is the hexadecimal value 0x5c repeated B times. Opad is the hexadecimal value 0x5c repeated B times.
Ipad is the hexadecimal value 0x36 repeated B times. Ipad is the hexadecimal value 0x36 repeated B times.
Apad is a value that is the same length as the hash output or message Apad is a value that is the same length as the hash output or message
digest. The first 16 octets contain the IPv6 source address followed digest. The first 16 octets contain the IPv6 source address followed
by the hexadecimal value 0x878FE1F3 repeated (L-16)/4 times. This by the hexadecimal value 0x878FE1F3 repeated (L-16)/4 times. This
implies that hash output is always a length of at least 16 octets. implies that hash output is always a length of at least 16 octets.
1. Preparation of the Key 1. Preparation of the Key
The OSPFv3 Cryptographic Protocol ID is appended to the The OSPFv3 Cryptographic Protocol ID is appended to the
Authentication Key (K) yielding a Protocol-Specific Authentication Key (K), yielding a Protocol-Specific
Authentication Key (Ks). In this application, Ko is always L Authentication Key (Ks). In this application, Ko is always
octets long. While [RFC2104] supports a key that is up to B L octets long. While [RFC2104] supports a key that is up to
octets long, this application uses L as the Ks length consistent B octets long, this application uses L as the Ks length consistent
with [RFC4822], [RFC5310], and [RFC5709]. According to with [RFC4822], [RFC5310], and [RFC5709]. According to
[FIPS-198-1], Section 3, keys greater than L octets do not [FIPS-198-1], Section 3, keys greater than L octets do not
significantly increase the function strength. Ks is computed as significantly increase the function strength. Ks is computed as
follows: follows:
If the Protocol-Specific Authentication Key (Ks) is L octets If Ks is L octets long, then Ko is equal to Ks. If Ks is more
long, then Ko is equal to Ks. If the Protocol-Specific than L octets long, then Ko is set to H(Ks). If Ks is less
Authentication Key (Ks) is more than L octets long, then Ko is than L octets long, then Ko is set to the value of Ks, with
set to H(Ks). If the Protocol-Specific Authentication Key zeros appended to the end of Ks such that Ko is L octets long.
(Ks) is less than L octets long, then Ko is set to the
Protocol-Specific Authentication Key (Ks) with zeros appended
to the end of the Protocol-Specific Authentication Key (Ks)
such that Ko is L octets long.
2. First-Hash 2. First-Hash
First, the OSPFv3 packet's Authentication Data field in the First, the OSPFv3 packet's Authentication Data field in the
Authentication Trailer is filled with the value Apad. This is Authentication Trailer is filled with the value Apad. This is
very similar to the appendage described in [RFC2328], Section very similar to the appendage described in [RFC2328],
D.4.3, Items (6)(a) and (6)(d)). Appendix D.4.3, Items (6)(a) and (6)(d)).
Then, a First-Hash, also known as the inner hash, is computed as Then, a First-Hash, also known as the inner hash, is computed as
follows: follows:
First-Hash = H(Ko XOR Ipad || (OSPFv3 Packet)) First-Hash = H(Ko XOR Ipad || (OSPFv3 Packet))
When XORing Ko and Ipad, Ko will be padded with zeros to the When XORing Ko and Ipad, Ko will be padded with zeros to the
length of Ipad. length of Ipad.
Implementation Note: The First-Hash above includes the Implementation Note: The First-Hash above includes the
Authentication Trailer, as well as the OSPFv3 packet, as per Authentication Trailer as well as the OSPFv3 packet as per
[RFC2328], Section D.4.3, and, if present, the LLS data block [RFC2328], Appendix D.4.3, and the LLS data block, if present
[RFC5613]. [RFC5613].
The definition of Apad (above) ensures it is always the same The definition of Apad (above) ensures that it is always the same
length as the hash output. This is consistent with RFC 2328. length as the hash output. This is consistent with RFC 2328.
Note that the "(OSPFv3 Packet)" referenced in the First-Hash Note that the "(OSPFv3 Packet)" referenced in the First-Hash
function above includes both the optional LLS data block and the function above includes both the optional LLS data block and the
OSPFv3 Authentication Trailer. OSPFv3 Authentication Trailer.
The digest length for SHA-1 is 20 octets; for SHA-256, 32 octets; The digest length for SHA-1 is 20 octets; for SHA-256, 32 octets;
for SHA-384, 48 octets; and for SHA-512, 64 octets. for SHA-384, 48 octets; and for SHA-512, 64 octets.
3. Second-Hash 3. Second-Hash
Then a Second-Hash, also known as the outer hash, is computed as Then a Second-Hash, also known as the outer hash, is computed as
follows: follows:
Second-Hash = H(Ko XOR Opad || First-Hash) Second-Hash = H(Ko XOR Opad || First-Hash)
When XORing Ko and Opad, Ko will be padded with zeros to the When XORing Ko and Opad, Ko will be padded with zeros to the
length of Ipad. length of Opad.
4. Result 4. Result
The resulting Second-Hash becomes the authentication data that is The resulting Second-Hash becomes the authentication data that is
sent in the Authentication Trailer of the OSPFv3 packet. The sent in the Authentication Trailer of the OSPFv3 packet. The
length of the authentication data is always identical to the length of the authentication data is always identical to the
message digest size of the specific hash function H that is being message digest size of the specific hash function H that is
used. being used.
This also means that the use of hash functions with larger output This also means that the use of hash functions with larger output
sizes will also increase the size of the OSPFv3 packet as sizes will also increase the size of the OSPFv3 packet as
transmitted on the wire. transmitted on the wire.
Implementation Note: [RFC2328], Appendix D specifies that the Implementation Note: [RFC2328], Appendix D specifies that the
Authentication Trailer is not counted in the OSPF packet's own Authentication Trailer is not counted in the OSPF packet's own
Length field but is included in the packet's IP Length field. Length field but is included in the packet's IP Length field.
Similar to this, the Authentication Trailer is not included in Similar to this, the Authentication Trailer is not included in
the OSPFv3 header length but is included in the IPv6 header the OSPFv3 header length but is included in the IPv6 header
payload length. payload length.
4.6. Message Verification 4.6. Message Verification
A router would determine that OSPFv3 is using an Authentication A router would determine that OSPFv3 is using an Authentication
trailer by examining the AT-bit in the Options field in the OSPFv3 Trailer (AT) by examining the AT-bit in the Options field in the
header for Hello and Database Description packets. The specification OSPFv3 header for Hello and Database Description packets. The
in the Hello and Database Description options indicates that other specification in the Hello and Database Description options indicates
OSPFv3 packets will include the Authentication Trailer. that other OSPFv3 packets will include the Authentication Trailer.
The Authentication Trailer (AT) is accessed using the OSPFv3 packet The AT is accessed using the OSPFv3 packet header length to access
header length to access the data after the OSPFv3 packet and, if an the data after the OSPFv3 packet and, if an LLS data block [RFC5613]
LLS data block [RFC5613] is present, using the LLS data block length is present, using the LLS data block length to access the data after
to access the data after the LLS data block. The L-bit in the OSPFv3 the LLS data block. The L-bit in the OSPFv3 options in Hello and
options in Hello and Database Description packets is examined to Database Description packets is examined to determine if an LLS data
determine if an LLS data block is present. If an LLS data block is block is present. If an LLS data block is present (as specified by
present (as specified by the L-bit), it is included along with the the L-bit), it is included along with the OSPFv3 Hello or Database
OSPFv3 Hello or Database Description packet in the cryptographic Description packet in the Cryptographic Authentication computation.
authentication computation.
Due to the placement of the AT following the LLS data block and the Due to the placement of the AT following the LLS data block and the
fact that the LLS data block is included in the Cryptographic fact that the LLS data block is included in the Cryptographic
Authentication computation, OSPFv3 routers supporting this Authentication computation, OSPFv3 routers supporting this
specification MUST minimally support examining the L-bit in the specification MUST minimally support examining the L-bit in the
OSPFv3 options and using the length in the LLS data block to access OSPFv3 options and using the length in the LLS data block to access
the AT. It is RECOMMENDED that OSPFv3 routers supporting this the AT. It is RECOMMENDED that OSPFv3 routers supporting this
specification fully support OSPFv3 Link-Local Signaling [RFC5613]. specification fully support OSPFv3 Link-Local Signaling [RFC5613].
If usage of the Authentication Trailer (AT), as specified herein, is If usage of the AT, as specified herein, is configured for an OSPFv3
configured for an OSPFv3 link, OSPFv3 Hello and Database Description link, OSPFv3 Hello and Database Description packets with the AT-bit
packets with the AT-bit clear in the options will be dropped. All clear in the options will be dropped. All OSPFv3 packet types will
OSPFv3 packet types will be dropped if AT is configured for the link be dropped if the AT is configured for the link and the IPv6 header
and the IPv6 header length is less than the amount necessary to length is less than the amount necessary to include an Authentication
include an Authentication Trailer. Trailer.
Locate the receiving interface's OSPFv3 SA using the SA ID in the The receiving interface's OSPFv3 SA is located using the SA ID in the
received AT. If the SA is not found, or if the SA is not valid for received AT. If the SA is not found, or if the SA is not valid for
reception (i.e., current time < KeyStartAccept or current time >= reception (i.e., current time < KeyStartAccept or
KeyStopAccept), the OSPFv3 packet is dropped. current time >= KeyStopAccept), the OSPFv3 packet is dropped.
If the cryptographic sequence number in the AT is less than or equal If the cryptographic sequence number in the AT is less than or equal
to the last sequence number in the last OSPFv3 packet of the same to the last sequence number in the last OSPFv3 packet of the same
OSPFv3 type successfully received from the neighbor, the OSPFv3 OSPFv3 type successfully received from the neighbor, the OSPFv3
packet MUST be dropped, and an error event SHOULD be logged. OSPFv3 packet MUST be dropped, and an error event SHOULD be logged. OSPFv3
packets of different types may arrive out of order if they are packets of different types may arrive out of order if they are
prioritized as recommended in [RFC4222]. prioritized as recommended in [RFC4222].
Authentication-algorithm-dependent processing needs to be performed, Authentication-algorithm-dependent processing needs to be performed,
using the algorithm specified by the appropriate OSPFv3 SA for the using the algorithm specified by the appropriate OSPFv3 SA for the
received packet. received packet.
Before an implementation performs any processing, it needs to save Before an implementation performs any processing, it needs to save
the values of the Authentication Data field from the Authentication the values of the Authentication Data field from the Authentication
Trailer appended to the OSPFv3 packet. Trailer appended to the OSPFv3 packet.
It should then set the Authentication Data field with Apad before the It should then set the Authentication Data field with Apad before the
authentication data is computed (as described in Section 4.5). The authentication data is computed (as described in Section 4.5). The
calculated data is compared with the received authentication data in calculated data is compared with the received authentication data in
the Authentication Trailer. If the two do not match, the packet MUST the Authentication Trailer. If the two do not match, the packet MUST
be discarded and an error event SHOULD be logged. be discarded, and an error event SHOULD be logged.
After the OSPFv3 packet has been successfully authenticated, After the OSPFv3 packet has been successfully authenticated,
implementations MUST store the 64-bit cryptographic sequence number implementations MUST store the 64-bit cryptographic sequence number
for each OSPFv3 packet type received from the neighbor. The saved for each OSPFv3 packet type received from the neighbor. The saved
cryptographic sequence numbers will be used for replay checking for cryptographic sequence numbers will be used for replay checking for
subsequent packets received from the neighbor. subsequent packets received from the neighbor.
5. Migration and Backward Compatibility 5. Migration and Backward Compatibility
All OSPFv3 routers participating on a link SHOULD be migrated to All OSPFv3 routers participating on a link SHOULD be migrated to
OSPFv3 Authentication at the same time. As with OSPFv2 OSPFv3 authentication at the same time. As with OSPFv2
authentication, a mismatch in the SA ID, Authentication Type, or authentication, a mismatch in the SA ID, Authentication Type, or
message digest will result in failure to form an adjacency. For message digest will result in failure to form an adjacency. For
multi-access links, communities of OSPFv3 routers could be migrated multi-access links, communities of OSPFv3 routers could be migrated
using different Interface Instance IDs. However, at least one router using different Interface Instance IDs. However, at least one router
would need to form adjacencies between both the OSPFv3 routers would need to form adjacencies between both the OSPFv3 routers
including and not including the Authentication Trailer. This would including and not including the Authentication Trailer. This would
result in sub-optimal routing as well as added complexity and is only result in sub-optimal routing as well as added complexity and is only
recommended in cases where authentication is desired on the link and recommended in cases where authentication is desired on the link and
migrating all the routers on the link at the same time isn't migrating all the routers on the link at the same time isn't
feasible. feasible.
In support of uninterrupted deployment, an OSPFv3 router implementing In support of uninterrupted deployment, an OSPFv3 router implementing
this specification MAY implement a transition mode where it includes this specification MAY implement a transition mode where it includes
the Authentication Trailer in transmitted packets but does not verify the Authentication Trailer in transmitted packets but does not verify
this information in received packets. This is provided as a this information in received packets. This is provided as a
transition aid for networks in the process of migrating to the transition aid for networks in the process of migrating to the
authentication mechanism described in this specification. More authentication mechanism described in this specification. More
specifically: specifically:
1. OSPFv3 routers in transition mode will include the OSPFv3 1. OSPFv3 routers in transition mode will include the OSPFv3
authentication trailer in transmitted packets and set the AT-Bit Authentication Trailer in transmitted packets and set the AT-bit
in the options field of transmitted Hello and Database in the Options field of transmitted Hello and Database Description
Description packets. OSPFv3 routers receiving these packets and packets. OSPFv3 routers receiving these packets and not having
not having authentication configured will ignore the authentication configured will ignore the Authentication Trailer
authentication trailer and AT-bit. and AT-bit.
2. OSPFv3 routers in transition mode will also calculate and set the 2. OSPFv3 routers in transition mode will also calculate and set the
OSPFv3 header checksum and the LLS block checksum in transmitted OSPFv3 header checksum and the LLS data block checksum in
packets so that they will not be dropped by OSPFv3 routers transmitted packets so that they will not be dropped by OSPFv3
without authentication configured. routers without authentication configured.
3. OSPFv3 routers in transition mode will authenticate received 3. OSPFv3 routers in transition mode will authenticate received
packets that either have the AT-Bit set in the options field for packets that either have the AT-bit set in the Options field for
Hello or Database Description packets or are from a neighbor that Hello or Database Description packets or are from a neighbor that
previously set the AT-Bit in the options field of successfully previously set the AT-bit in the Options field of successfully
authenticated Hello and Database Description packets. authenticated Hello and Database Description packets.
4. OSPFv3 routers in transition mode will also accept packets 4. OSPFv3 routers in transition mode will also accept packets without
without the options field AT-Bit set in Hello and Database the Options field AT-bit set in Hello and Database Description
Description packets. These packets will be assumed to be from packets. These packets will be assumed to be from OSPFv3 routers
OSPFv3 routers without authentication configured and they will without authentication configured, and they will not be
not be authenticated. Additionally, the OSPFv3 header checksum authenticated. Additionally, the OSPFv3 header checksum and LLS
and LLS block checksum will be validated. data block checksum will be validated.
6. Security Considerations 6. Security Considerations
The document proposes extensions to OSPFv3 that would make it more This document proposes extensions to OSPFv3 that would make it more
secure than [RFC5340]. It does not provide confidentiality as a secure than OSPFv3 as defined in [RFC5340]. It does not provide
routing protocol contains information that does not need to be kept confidentiality, as a routing protocol contains information that does
secret. It does, however, provide means to authenticate the sender not need to be kept secret. It does, however, provide means to
of the packets that are of interest. It addresses all the security authenticate the sender of packets that are of interest. It
issues that have been identified in [RFC6039] and [RFC6506]. addresses all the security issues that have been identified in
[RFC6039] and [RFC6506].
It should be noted that the authentication method described in this It should be noted that the authentication method described in this
document is not being used to authenticate the specific originator of document is not being used to authenticate the specific originator of
a packet but is rather being used to confirm that the packet has a packet but rather is being used to confirm that the packet has
indeed been issued by a router that has access to the Authentication indeed been issued by a router that has access to the
Key. Authentication Key.
Deployments SHOULD use sufficiently long and random values for the Deployments SHOULD use sufficiently long and random values for the
Authentication Key so that guessing and other cryptographic attacks Authentication Key so that guessing and other cryptographic attacks
on the key are not feasible in their environments. Furthermore, it on the key are not feasible in their environments. Furthermore, it
is RECOMMENDED that Authentication Keys incorporate at least 128 is RECOMMENDED that Authentication Keys incorporate at least 128
pseudo-random bits to minimize the risk of such attacks. In support pseudorandom bits to minimize the risk of such attacks. In support
of these recommendations, management systems SHOULD support of these recommendations, management systems SHOULD support
hexadecimal input of Authentication Keys. hexadecimal input of Authentication Keys.
Deployments supporting a transitionary state which interoperate with Deployments that support a transitionary state but interoperate with
routers that do not support this authentication method may be exposed routers that do not support this authentication method may be exposed
to unauthenticated data during the transition period. to unauthenticated data during the transition period.
The mechanism described herein is not perfect and does not need to be The mechanism described herein is not perfect and does not need to be
perfect. Instead, this mechanism represents a significant increase perfect. Instead, this mechanism represents a significant increase
in the effort required for an adversary to successfully attack the in the effort required for an adversary to successfully attack the
OSPFv3 protocol while not causing undue implementation, deployment, OSPFv3 protocol, while not causing undue implementation, deployment,
or operational complexity. or operational complexity.
Refer to [RFC4552] for additional considerations on manual keying. Refer to [RFC4552] for additional considerations on manual keying.
7. IANA Considerations 7. IANA Considerations
This document obsoletes RFC 6506 and thus IANA is requested to update This document obsoletes RFC 6506; thus, IANA has updated the
the reference for the existing registries previously created by RFC references in existing registries that pointed to RFC 6506 to point
6506 to this document. This is the only IANA action requested by to this document. This is the only IANA action requested by this
this document. document.
IANA has allocated the AT-bit (0x000400) in the "OSPFv3 Options (24 IANA previously allocated the AT-bit (0x000400) in the "OSPFv3
bits)" registry as described in Section 2.1. Options (24 bits)" registry as described in Section 2.1.
IANA has created the "OSPFv3 Authentication Trailer Options" IANA previously created the "Open Shortest Path First v3 (OSPFv3)
registry. This new registry initially includes the "OSPFv3 Authentication Trailer Options" registry. This registry includes the
Authentication Types" registry, which defines valid values for the "OSPFv3 Authentication Types" registry, which defines valid values
Authentication Type field in the OSPFv3 Authentication Trailer. The for the Authentication Type field in the OSPFv3 Authentication
registration procedure is Standards Action. Trailer. The registration procedure is Standards Action [RFC5226].
+-------------+-----------------------------------+ +-------------+-----------------------------------+
| Value/Range | Designation | |Value | Designation |
+-------------+-----------------------------------+ +-------------+-----------------------------------+
| 0 | Reserved | | 0 | Reserved |
| | | | | |
| 1 | HMAC Cryptographic Authentication | | 1 | HMAC Cryptographic Authentication |
| | | | | |
| 2-65535 | Unassigned | | 2-65535 | Unassigned |
+-------------+-----------------------------------+ +-------------+-----------------------------------+
OSPFv3 Authentication Types OSPFv3 Authentication Types
Finally, IANA has created the "Keying and Authentication for Routing Finally, IANA previously created the "Keying and Authentication for
Protocols (KARP) Parameters" category. This new category initially Routing Protocols (KARP) Parameters" registry. This registry
includes the "Authentication Cryptographic Protocol ID" registry, includes the "Cryptographic Protocol ID" registry, which provides
which provides unique protocol-specific values for cryptographic unique protocol-specific values for cryptographic applications,
applications, such as but not limited to, prevention of cross- including but not limited to prevention of cross-protocol replay
protocol replay attacks. Values can be assigned for both native attacks. Values can be assigned for both native IPv4/IPv6 protocols
IPv4/IPv6 protocols and UDP/TCP protocols. The registration and UDP/TCP protocols. The registration procedure is Standards
procedure is Standards Action. Action.
+-------------+----------------------+ +-------------+----------------------+
| Value/Range | Designation | | Value/Range | Designation |
+-------------+----------------------+ +-------------+----------------------+
| 0 | Reserved | | 0 | Reserved |
| | | | | |
| 1 | OSPFv3 | | 1 | OSPFv3 |
| | | | | |
| 2-65535 | Unassigned | | 2-65535 | Unassigned |
+-------------+----------------------+ +-------------+----------------------+
Cryptographic Protocol ID Cryptographic Protocol ID
8. References 8. References
8.1. Normative References 8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998. [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.
[RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF
for IPv6", RFC 5340, July 2008. for IPv6", RFC 5340, July 2008.
[RFC5709] Bhatia, M., Manral, V., Fanto, M., White, R., Barnes, M., [RFC5709] Bhatia, M., Manral, V., Fanto, M., White, R., Barnes, M.,
Li, T., and R. Atkinson, "OSPFv2 HMAC-SHA Cryptographic Li, T., and R. Atkinson, "OSPFv2 HMAC-SHA Cryptographic
Authentication", RFC 5709, October 2009. Authentication", RFC 5709, October 2009.
[RFC6506] Bhatia, M., Manral, V., and A. Lindem, "Supporting
Authentication Trailer for OSPFv3", RFC 6506,
February 2012.
8.2. Informative References 8.2. Informative References
[FIPS-180-3] [FIPS-180-4]
US National Institute of Standards and Technology, "Secure US National Institute of Standards and Technology, "Secure
Hash Standard (SHS)", FIPS PUB 180-3, October 2008. Hash Standard (SHS)", FIPS PUB 180-4, March 2012.
[FIPS-198-1] [FIPS-198-1]
US National Institute of Standards and Technology, "The US National Institute of Standards and Technology, "The
Keyed-Hash Message Authentication Code (HMAC)", FIPS Keyed-Hash Message Authentication Code (HMAC)", FIPS
PUB 198, July 2008. PUB 198-1, July 2008.
[MANUAL-KEY] [MANUAL-KEY]
Bhatia, M., Hartman, S., Zhang, D., and A. Lindem, Bhatia, M., Hartman, S., and D. Zhang, "Security Extension
"Security Extension for OSPFv2 when using Manual Key for OSPFv2 when using Manual Key Management", Work in
Management", Work in Progress, October 2011. Progress, February 2011.
[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
Hashing for Message Authentication", RFC 2104, Hashing for Message Authentication", RFC 2104,
February 1997. February 1997.
[RFC4222] Choudhury, G., "Prioritized Treatment of Specific OSPF [RFC4222] Choudhury, G., Ed., "Prioritized Treatment of Specific
Version 2 Packets and Congestion Avoidance", BCP 112, OSPF Version 2 Packets and Congestion Avoidance", BCP 112,
RFC 4222, October 2005. RFC 4222, October 2005.
[RFC4302] Kent, S., "IP Authentication Header", RFC 4302, [RFC4302] Kent, S., "IP Authentication Header", RFC 4302,
December 2005. December 2005.
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)",
RFC 4303, December 2005. RFC 4303, December 2005.
[RFC4552] Gupta, M. and N. Melam, "Authentication/Confidentiality [RFC4552] Gupta, M. and N. Melam, "Authentication/Confidentiality
for OSPFv3", RFC 4552, June 2006. for OSPFv3", RFC 4552, June 2006.
[RFC4822] Atkinson, R. and M. Fanto, "RIPv2 Cryptographic [RFC4822] Atkinson, R. and M. Fanto, "RIPv2 Cryptographic
Authentication", RFC 4822, February 2007. Authentication", RFC 4822, February 2007.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008.
[RFC5310] Bhatia, M., Manral, V., Li, T., Atkinson, R., White, R., [RFC5310] Bhatia, M., Manral, V., Li, T., Atkinson, R., White, R.,
and M. Fanto, "IS-IS Generic Cryptographic and M. Fanto, "IS-IS Generic Cryptographic
Authentication", RFC 5310, February 2009. Authentication", RFC 5310, February 2009.
[RFC5613] Zinin, A., Roy, A., Nguyen, L., Friedman, B., and D. [RFC5613] Zinin, A., Roy, A., Nguyen, L., Friedman, B., and D.
Yeung, "OSPF Link-Local Signaling", RFC 5613, August 2009. Yeung, "OSPF Link-Local Signaling", RFC 5613, August 2009.
[RFC5879] Kivinen, T. and D. McDonald, "Heuristics for Detecting [RFC5879] Kivinen, T. and D. McDonald, "Heuristics for Detecting
ESP-NULL Packets", RFC 5879, May 2010. ESP-NULL Packets", RFC 5879, May 2010.
[RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, [RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen,
"Internet Key Exchange Protocol Version 2 (IKEv2)", "Internet Key Exchange Protocol Version 2 (IKEv2)",
RFC 5996, September 2010. RFC 5996, September 2010.
[RFC6039] Manral, V., Bhatia, M., Jaeggli, J., and R. White, "Issues [RFC6039] Manral, V., Bhatia, M., Jaeggli, J., and R. White, "Issues
with Existing Cryptographic Protection Methods for Routing with Existing Cryptographic Protection Methods for Routing
Protocols", RFC 6039, October 2010. Protocols", RFC 6039, October 2010.
[RFC6506] Bhatia, M., Manral, V., and A. Lindem, "Supporting
Authentication Trailer for OSPFv3", RFC 6506,
February 2012.
Appendix A. Acknowledgments Appendix A. Acknowledgments
First and foremost, thanks to the US National Institute of Standards First and foremost, thanks to the US National Institute of Standards
and Technology for their work on the SHA [FIPS-180-3] and HMAC and Technology for their work on the SHA [FIPS-180-4] and HMAC
[FIPS-198-1]. [FIPS-198-1].
Thanks also need to go to the authors of the HMAC-SHA authentication Thanks also need to go to the authors of the HMAC-SHA authentication
RFCs including [RFC4822], [RFC5310], and [RFC5709]. The basic HMAC- RFCs, including [RFC4822], [RFC5310], and [RFC5709]. The basic
SHA procedures were originally described by Ran Atkinson and Tony Li HMAC-SHA procedures were originally described by Ran Atkinson in
in [RFC4822]. [RFC4822].
Also, thanks to Ran Atkinson for help in the analysis of RFC 6506 Also, thanks to Ran Atkinson for help in the analysis of RFC 6506
errata. errata.
Thanks to Srinivasan K L and Marek Karasek for their identification Thanks to Srinivasan K L and Marek Karasek for their identification
and submission of RFC 6506 errata. and submission of RFC 6506 errata.
Thanks to Sam Hartman for discussions on replay mitigation and the Thanks to Sam Hartman for discussions on replay mitigation and the
use of a 64-bit strictly increasing sequence number. Also, thanks to use of a 64-bit strictly increasing sequence number. Also, thanks to
Sam for comments during IETF last call with respect to the OSPFv3 SA Sam for comments during IETF last call with respect to the OSPFv3 SA
and sharing of key between protocols. and the sharing of keys between protocols.
Thanks to Michael Barnes for numerous comments and strong input on Thanks to Michael Barnes for numerous comments and strong input on
the coverage of LLS by the Authentication Trailer (AT). the coverage of LLS by the Authentication Trailer (AT).
Thanks to Marek Karasek for providing the specifics with respect to Thanks to Marek Karasek for providing the specifics with respect to
backward compatible transition mode. backward-compatible transition mode.
Thanks to Michael Dubrovskiy and Anton Smirnov for comments on draft Thanks to Michael Dubrovskiy and Anton Smirnov for comments on
revisions. document revisions.
Thanks to Rajesh Shetty for numerous comments, including the Thanks to Rajesh Shetty for numerous comments, including the
suggestion to include an Authentication Type field in the suggestion to include an Authentication Type field in the
Authentication Trailer for extendibility. Authentication Trailer for extendibility.
Thanks to Uma Chunduri for suggesting that we may want to protect the Thanks to Uma Chunduri for suggesting that we may want to protect the
IPv6 source address even though OSPFv3 uses the Router ID for IPv6 source address even though OSPFv3 uses the Router ID for
neighbor identification. neighbor identification.
Thanks to Srinivasan KL, Shraddha H, Alan Davey, Russ White, Stan Thanks to Srinivasan K L, Shraddha H, Alan Davey, Russ White, Stan
Ratliff, and Glen Kent for their support and review comments. Ratliff, and Glen Kent for their support and review comments.
Thanks to Alia Atlas for comments made under the purview of the Thanks to Alia Atlas for comments made under the purview of the
Routing Directorate review. Routing Directorate review.
Thanks to Stephen Farrell for comments during the IESG review. Thanks to Stephen Farrell for comments during the IESG review.
Stephen was also involved in the discussion of cross-protocol Stephen was also involved in the discussion of cross-protocol
attacks. attacks.
Thanks to Brian Carpenter for comments made during Gen-ART review. Thanks to Brian Carpenter for comments made during the Gen-ART
review.
Thanks to Victor Kuarsingh for the OPS-DIR review. Thanks to Victor Kuarsingh for the OPS-DIR review.
Thanks to Brian Weis for the SEC-DIR review. Thanks to Brian Weis for the SEC-DIR review.
Authors' Addresses Authors' Addresses
Manav Bhatia Manav Bhatia
Alcatel-Lucent Alcatel-Lucent
Bangalore Bangalore
India India
Email: manav.bhatia@alcatel-lucent.com EMail: manav.bhatia@alcatel-lucent.com
Vishwas Manral Vishwas Manral
Hewlett Packard Ionos Corp.
4100 Moorpark Ave.
San Jose, CA 95117
USA USA
Email: vishwas.manral@hp.com EMail: vishwas@ionosnetworks.com
Acee Lindem Acee Lindem
Ericsson Ericsson
301 Midenhall Way 301 Midenhall Way
Cary, NC 27513 Cary, NC 27513
USA USA
Email: acee.lindem@ericsson.com EMail: acee.lindem@ericsson.com
 End of changes. 112 change blocks. 
348 lines changed or deleted 346 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/