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

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 5 April 2027.¶

Copyright Notice

Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.¶

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

Table of Contents

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

A separate effort, [I-D.herbert-deprecate-auth-header], proposes to deprecate AH for IP in general. Its motivations are that authentication without confidentiality is not compelling, that AH is incompatible with commonly deployed mechanisms such as Network Address Translation (NAT) and checksum offload, and that AH is likely not deployed. This document has a narrower scope. It addresses only the use of AH to authenticate OSPFv3 and does not depend on the progress of that work.¶

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. The general arguments for deprecating AH given in [I-D.herbert-deprecate-auth-header], including the marginal value of its additional header coverage relative to ESP, apply equally to OSPFv3.¶
• 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:¶

1. 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.¶
2. New OSPFv3 implementations SHOULD NOT implement AH for OSPFv3 authentication.¶
3. 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.¶
4. 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.¶

In addition to the OSPFv3 packet, AH authenticates the immutable fields of the IPv6 header and any IPv6 extension headers that precede it. Neither of the alternatives retained by this document provides equivalent coverage. ESP [RFC4303] authenticates only the ESP header and the payload that follows it, so the IPv6 header and any preceding extension headers are not covered. The OSPFv3 Authentication Trailer [RFC7166] authenticates the OSPFv3 packet and the IPv6 source address, but [RFC7166] does not cover the remainder of the IPv6 header or any IPv6 extension headers and does not define a mechanism to do so. Operators migrating from AH to either alternative will therefore lose authentication of these headers.¶

This loss is of little practical consequence for OSPFv3. OSPFv3 packets are sent on a single link using link-local addresses with a hop limit of 1, and OSPFv3 does not require any IPv6 extension headers for its operation. This is consistent with the observation in [I-D.herbert-deprecate-auth-header] that the additional coverage afforded by AH over ESP is marginal. The difference is nonetheless noted here so that it is an explicit part of the migration decision.¶

6. IANA Considerations

This document has no IANA actions.¶

Acknowledgements

Claude Sonnet 5.5 was used to assist in the preparation and editing of this document.¶

Authors' Addresses