Deprecation of the IPsec Authentication Header (AH) for OSPFv3 Authentication
draft-acee-lsr-ospfv3-deprecate-ah-01
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Authors | Acee Lindem , Baalajee Surendran | ||
| Last updated | 2026-10-02 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-acee-lsr-ospfv3-deprecate-ah-01
Link State Routing Working Group A. Lindem
Internet-Draft Arrcus, Inc
Updates: 4552 (if approved) B. Surendran
Intended status: Standards Track Cisco Systems
Expires: 5 April 2027 2 October 2026
Deprecation of the IPsec Authentication Header (AH) for OSPFv3
Authentication
draft-acee-lsr-ospfv3-deprecate-ah-01
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 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
Lindem & Surendran Expires 5 April 2027 [Page 1]
Internet-Draft Deprecating AH for OSPFv3 October 2026
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 . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
2. Rationale . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Deprecation of AH for OSPFv3 . . . . . . . . . . . . . . . . 3
4. Migration Considerations . . . . . . . . . . . . . . . . . . 4
5. Security Considerations . . . . . . . . . . . . . . . . . . . 4
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 5
7.1. Normative References . . . . . . . . . . . . . . . . . . 5
7.2. Informative References . . . . . . . . . . . . . . . . . 5
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 6
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6
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.
Lindem & Surendran Expires 5 April 2027 [Page 2]
Internet-Draft Deprecating AH for OSPFv3 October 2026
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. 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.
Lindem & Surendran Expires 5 April 2027 [Page 3]
Internet-Draft Deprecating AH for OSPFv3 October 2026
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.
Lindem & Surendran Expires 5 April 2027 [Page 4]
Internet-Draft Deprecating AH for OSPFv3 October 2026
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.
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
[I-D.herbert-deprecate-auth-header]
Herbert, T., "Deprecate IP Authentication Header", Work in
Progress, Internet-Draft, draft-herbert-deprecate-auth-
header-01, 2 January 2026,
<https://datatracker.ietf.org/doc/html/draft-herbert-
deprecate-auth-header-01>.
[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>.
Lindem & Surendran Expires 5 April 2027 [Page 5]
Internet-Draft Deprecating AH for OSPFv3 October 2026
[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>.
Acknowledgements
Claude Sonnet 5.5 was used to assist in the preparation and editing
of this document.
Authors' Addresses
Acee Lindem
Arrcus, Inc
301 Midenhall Way
Cary, NC 27513
United States
Email: acee.ietf@gmail.com
Baalajee Surendran
Cisco Systems
Bengaluru, Karnataka
India
Email: basurend@cisco.com
Lindem & Surendran Expires 5 April 2027 [Page 6]