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

Deprecation of the IPsec Authentication Header (AH) for OSPFv3 Authentication Arrcus, Inc

301 Midenhall Way Cary, NC 27513 UNITED STATES acee.ietf@gmail.com

Routing Link State Routing Working Group OSPFv3 IPsec AH ESP authentication 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.

Introduction specifies how IPsec is used to secure OSPFv3 protocol exchanges. It requires support for ESP and permits the use of AH . Since the publication of , AH has seen very limited adoption and is now an optional-to-implement protocol in the IPsec cryptographic requirements . The OSPFv3 Authentication Trailer 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.

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 when, and only when, they appear in all capitals, as shown here.

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

AH is optional to implement for IPsec , 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 . 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 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.

Deprecation of AH for OSPFv3 The use of the IPsec Authentication Header (AH) to authenticate OSPFv3 packets is deprecated. This document updates as follows:

All text in 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 , or the OSPFv3 Authentication Trailer, as specified in .

The requirements of pertaining to ESP are unchanged by this document.

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 , remains the only keying method specified for OSPFv3 use of IPsec.

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 and , and to rotate keys periodically.

IANA Considerations This document has no IANA actions.

References Normative References Informative References

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