]> Arrcus, Inc

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

Cisco Systems

Bengaluru, Karnataka India basurend@cisco.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. A separate effort, , 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.

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. The general arguments for deprecating AH given in , 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 . 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:

1. 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.
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 , 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. 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 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 authenticates the OSPFv3 packet and the IPv6 source address, but 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 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.

IANA Considerations This document has no IANA actions.

References Normative References Informative References XDPnet

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