| Internet-Draft | IPsec anti-replay subspaces | October 2022 |
| Ponchon, et al. | Expires 27 April 2023 | [Page] |
This document discusses the challenges of running IPsec with anti-replay in environments where packets may be re-ordered (e.g., when sent over multiple IP paths, traffic-engineered paths and/or using different QoS classes) as well as when processed on multiple cores. Different approaches to solving this problem are discussed, and a new solution based on splitting the anti-replay sequence number space into multiple different sequencing subspaces is proposed. Since this solution requires support on both parties, an IKE extension is proposed in order to negotiate the use of the Anti-Replay sequence number subspaces.¶
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 27 April 2023.¶
Copyright (c) 2022 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.¶
The IPsec and IKE protocol suite is very commonly used in secure overlay networks, often interconnecting thousands or tens of thousands of sites. Each of these sites often have two or more ways to connect to the internet (e.g., multiple fiber/cable, cellular or MPLS uplinks), with the promise that leveraging the different paths between nodes could bring greater throughput, availability and quality of service.¶
Such scale and multi-paths requirements conflict with how anti-replay currently works. This document first describes the problems related to running IPsec with anti-replay in multi-core and multi-paths environments, as well as their existing solutions. A new solution where the IPsec sequence number sequencing space is divided into multiple subspaces is then specified. Finally, implementation, security and operational considerations are discussed.¶
A common approach to leverage multiple paths between IPsec peers is to allocate one Child SA per path, but given the quadratic number of paths that may exist between peers ('number of uplinks of peer 1' x 'number of uplinks of peer 2'), this shows scalability issues in both IKE and IPsec implementations:¶
On the other hand, using a single Child SA per peer on multiple paths comes with challenges related to the anti-replay mechanism. Packets traveling on different paths may arrive out-of-order. A packet could travel on a slower network path, compared to another faster path, and arrive too late for the anti-replay window to be able to check whether the packet is a replay or not, causing the packet to be dropped.¶
The same problem may also be observed when multiple QoS policies are used: Packets may be re-ordered, and a lower priority queue could have its packets arrive too late compared to others for the anti-replay mechanism to function properly.¶
Finally, anti-replay implementations also suffer from performance issues when multiple threads are involved in sending or receiving encrypted packets for the same Child SA. This is discussed in [I-D.pwouters-ipsecme-multi-sa-performance], which mainly focuses on high-throughput IPsec tunnels, but the problem also arises with small tunnels since multiple inner flows processed by multiple threads often need to be transmitted on the same tunnel (causing multiple threads to need to access shared resources).¶
The solution detailed in [I-D.pwouters-ipsecme-multi-sa-performance] proposes to use one Child SA per core, and could be extended to provide a solution involving one SA per path as well. But allocating one SA per path, as well as per core, would further multiply the number of Child SAs. For example, with 6 paths between two peers (one peer has 2 uplinks, the other has 3), and 4 cores to process the IPsec packets, the number of Child SAs would be multiplied by 24. This will divide by 24 the number of peers that an IPsec concentrator supports.¶
Alternatively, a single Child SA per peer could be used with a very large anti-replay window (e.g., 128k bits), in order to mitigate the risk of packets being dropped when packets are sent on multiple paths. But this solution has some serious drawbacks:¶
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 BCP14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶
The problems of using a single Child SA on multiple paths and processing the packets associated with a single Child SA on multiple cores both suffer from limitations due to the anti-replay mechanism.¶
As a result, this section describes a solution which modifies the anti-replay mechanism by allowing the 32 bits or 64 bits (with ESN) anti-replay sequence number space into multiple subspaces. Each path, or core, or combination of both, can then use their own unique anti-replay sequence number subspace. The changes needed to the ESP header and IPsec protocol are described in Section 4.1, Section 4.2 and Section 4.3.¶
Since this specification requires both IPsec peers to implement this specification, an IKE extension is presented in Section 4.5, allowing peers to coordinate on the use, or not, of this specification.¶
The 32-bit sequence number field of the ESP header is split into two sub-fields:¶
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Security Parameters Index (SPI) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Subspace ID | Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Rest of the ESP payload¶
The sender MAY set the sequence number subspace ID to any value. For example, the sender would use different values per path or per processing core.¶
The sender MUST maintain one sequence number counter per sequence number subspace that it makes use of. But the sender MAY use only some (and as few as a single one) of the available 256 subspaces.¶
When transmitting a packet, the sender MUST use the sequence number counter associated with the sequence number subspace in use for that packet. The lower-order 24 bits of the sequence number counter are placed in the sequence number field, as specified in [RFC4303].¶
The receiver MUST maintain one anti-replay window and counter for each sequence number subspace being used.¶
When receiving a packet, the receiver MUST use the anti-replay window and counter associated with the sequence number subspace identified with the subspace ID field.¶
Note: Since the sender may decide to only use a subset of the available subspace values, receivers SHOULD NOT allocate 256 anti-replay windows per peer by default. Two mitigation mechanisms may be used to reduce the number of anti-replay windows:¶
When using Extended Sequence Numbers (ESNs), the sender and receiver MUST consider the 8 bits at indices 24 to 31 of the sequence number 64 bits long counter to be implicit.¶
Note that the reduction of the sequence number space to 24 bits specified in this document has some implications over the speed at which the explicit part of the sequence number will loop. At a 10Gbps rate, with 1500B ethernet frames, the 24 bits sequence number space will loop every 20 seconds.¶
As a result:¶
Note: A peer may unilaterally enforce the use of ESN by specifying the IKE ESN transform with the value "1" (implying that the peer suggests to use ESN) in its CHILD_SA proposal, while ommitting to include the IKE ESN transform with the value "0" (implying that disabling ESN is not accepted).¶
Authors' note: Is it too much of a problem ? Should we consider adding a new 32 bits field in the ESP header to contain the subspace ID, as well as future ESP extensions ?¶
A mechanism will be needed to:¶
This document will specify such negotiation.¶
The authors would like to request the ipsecme working group for input on how to best implement the negotiation of this new functionality in IKEv2 [RFC5996].¶
As described in Section 2, anti-replay comes with implementation and scalability challenges when running in environments where IPsec peers may leverage multiple paths to send packets or multiple cores to process them.¶
Since the anti-replay mechanism seems to be the source cause of these observed challenges, this document provides a solution which relies on a small and optional change at the anti-replay level.¶
By using sequence number subspaces, IPsec peers may:¶
The sequence number is used by the anti-replay mechanism to ensure a packet could not be accepted twice by the receiver. This prevents an attacker from trying to replay one or multiple packets from an IPsec tunnel.¶
In this proposal, a single Child SA is associated with multiple anti-replay windows and counters. When trying to replay a packet, the sequence number subspace ID must remain the same since the Subspace ID field is authenticated. As a result the receiver will use the same anti-replay state when processing the replayed packet as the one used when the first packet was first received. This ensures that a replayed packet will be detected and dropped by the receiver.¶
When a single sequence number space is used within a given Child SA, encryption and decryption operations must always happen on the same core (locking anti-replay structures or using contended atomic operations has a dramatic performance hit).¶
To avoid the performance degradation caused by packet handoffs, each thread may use its own sequence number subspace:¶
Similarly, when multiple paths are used:¶
If a combination of both multi-path and multi-core load-balancing is needed, the subspace field could be used partly to encode a path ID, partly to encode a core ID. But this is purely implementation specific and does not require coordination between the peers.¶
Depending on the cryptographic mode of operations, the Initialization Vector (IV) comes with specific requirements.¶
Some modes (e.g., CBC) make use of random IV values. When implementing this specification, each thread independently generates its independent stream of random values, ensuring the IV randomness property. Care must be taken as to limit the global number of transmitted packets using the same Child SA in order to avoid birthday paradox attacks. A lockless counter, or batched token bucket mechanism, may be used to efficiently implement this process without performance degradation.¶
Other cryptographic modes (e.g., GCM) do not have randomness requirements over the IV, but the IV values must only be used once. RFC4106 Section 3.1 states that "The most natural way to implement this is with a counter, but anything that guarantees uniqueness can be used, such as a linear feedback shift register (LFSR). Note that the encrypter can use any IV generation method that meets the uniqueness requirement, without coordinating with the decrypter." . One simple way to implement this specification is to divide the IV into a subspace field, which reuses the ESP sequence number subspace value, and a variable IV part, which is simply incremented for each encrypted packet.¶
Author's note: Are there other cryptographic modes with different requirements over the IV ?¶