Deprecation of the IPsec Authentication Header (AH) for OSPFv3 Authentication

Internet-Draft	Deprecating AH for OSPFv3	September 2026
Lindem	Expires 3 April 2027	[Page]

Abstract

RFC 4552 specifies the use of the IPsec Authentication Header (AH) and the Encapsulating Security Payload (ESP) to provide authentication and confidentiality for OSPFv3. This document deprecates the use of AH for OSPFv3 and updates RFC 4552 accordingly. Operators are encouraged to use either ESP with NULL encryption, as specified in RFC 4552, or the OSPFv3 Authentication Trailer, as specified in RFC 7166.¶

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 Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶

This Internet-Draft will expire on 3 April 2027.¶

Copyright Notice

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶

1. Introduction

[RFC4552] specifies how IPsec [RFC4301] is used to secure OSPFv3 protocol exchanges. It requires support for ESP [RFC4303] and permits the use of AH [RFC4302].¶

Since the publication of [RFC4552], AH has seen very limited adoption and is now an optional-to-implement protocol in the IPsec cryptographic requirements [RFC8221]. The OSPFv3 Authentication Trailer [RFC7166] provides an IPsec-independent alternative that has been widely implemented. This document deprecates the use of AH for OSPFv3 in order to reduce implementation and operational complexity and to consolidate on the mechanisms that are actually deployed.¶

1.1. Requirements Language

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶

2. Rationale

The following factors motivate the deprecation of AH for OSPFv3:¶

AH is optional to implement for IPsec [RFC8221], and many IPsec implementations no longer support it.¶
ESP with NULL encryption provides integrity and authentication of the OSPFv3 packet, and this combination is already mandated by [RFC4552]. Supporting AH in addition to ESP adds little value for OSPFv3.¶
OSPFv3 packets are sent on a single link using link-local addresses with a hop limit of 1, which limits the additional protection afforded by AH coverage of immutable IPv6 header fields. The OSPFv3 Authentication Trailer [RFC7166] additionally covers the IPv6 source address of the packet.¶
Maintaining separate AH and ESP code paths, key management configuration, and operational procedures for OSPFv3 increases complexity without a corresponding benefit.¶

3. Deprecation of AH for OSPFv3

The use of the IPsec Authentication Header (AH) to authenticate OSPFv3 packets is deprecated. This document updates [RFC4552] as follows:¶

All text in [RFC4552] that permits or describes the use of AH for OSPFv3 is deprecated. This includes the use of AH as the authentication mechanism for OSPFv3 packets and the AH-specific requirements for Security Associations (SAs) used by OSPFv3.¶
New OSPFv3 implementations SHOULD NOT implement AH for OSPFv3 authentication.¶
Existing implementations that support AH for OSPFv3 MAY continue to do so for backward compatibility but SHOULD indicate to the operator that the configuration is deprecated.¶
Operators SHOULD migrate OSPFv3 deployments that use AH to either ESP with NULL encryption, as specified in [RFC4552], or the OSPFv3 Authentication Trailer, as specified in [RFC7166].¶

The requirements of [RFC4552] pertaining to ESP are unchanged by this document.¶

4. Migration Considerations

An OSPFv3 interface or virtual link is configured with a single authentication mechanism, and all routers on the link must agree on it. Migration from AH therefore requires coordinated changes on all routers attached to the link. Operators can minimize disruption by first configuring the new authentication mechanism and keys on all routers in a maintenance window, or by using a staged approach on implementations that support accepting more than one mechanism during a transition period. Manual keying, as required by [RFC4552], remains the only keying method specified for OSPFv3 use of IPsec.¶

5. Security Considerations

This document does not introduce new protocol mechanisms. It reduces the set of authentication options for OSPFv3 and directs operators to mechanisms that remain in active use and maintenance. ESP with NULL encryption and the OSPFv3 Authentication Trailer both provide authentication and integrity protection of OSPFv3 packets. Neither protects against a compromised router that holds valid keys. Operators are reminded to use strong cryptographic algorithms as described in [RFC8221] and [RFC7166], and to rotate keys periodically.¶

7. References

7.1. Normative References

[RFC2119]: Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC4552]: Gupta, M. and N. Melam, "Authentication/Confidentiality for OSPFv3", RFC 4552, DOI 10.17487/RFC4552, June 2006, <https://www.rfc-editor.org/info/rfc4552>.
[RFC8174]: Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.

7.2. Informative References

[RFC4301]: Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, December 2005, <https://www.rfc-editor.org/info/rfc4301>.
[RFC4302]: Kent, S., "IP Authentication Header", RFC 4302, DOI 10.17487/RFC4302, December 2005, <https://www.rfc-editor.org/info/rfc4302>.
[RFC4303]: Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, DOI 10.17487/RFC4303, December 2005, <https://www.rfc-editor.org/info/rfc4303>.
[RFC7166]: Bhatia, M., Manral, V., and A. Lindem, "Supporting Authentication Trailer for OSPFv3", RFC 7166, DOI 10.17487/RFC7166, March 2014, <https://www.rfc-editor.org/info/rfc7166>.
[RFC8221]: Wouters, P., Migault, D., Mattsson, J., Nir, Y., and T. Kivinen, "Cryptographic Algorithm Implementation Requirements and Usage Guidance for Encapsulating Security Payload (ESP) and Authentication Header (AH)", RFC 8221, DOI 10.17487/RFC8221, October 2017, <https://www.rfc-editor.org/info/rfc8221>.