Internet DRAFT - draft-mrossberg-ipsecme-multiple-sequence-counters
draft-mrossberg-ipsecme-multiple-sequence-counters
Network M. Rossberg
Internet-Draft TU Ilmenau
Intended status: Informational S. Klassert
Expires: 31 August 2023 secunet
M. Pfeiffer
TU Ilmenau
27 February 2023
Problem statements and uses cases for lightweight Child Security
Associations
draft-mrossberg-ipsecme-multiple-sequence-counters-00
Abstract
IKE SAs may have one or more child SAs that are used for traffic
protection. This document collects arguments for (and against)
having more fine-grained sub-child-SAs. They can be used to separate
data streams for various technical reasons but share the same
security properties and traffic selectors. This shall allow for a
more flexible use of IPsec in multiple scenarios.
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 31 August 2023.
Copyright Notice
Copyright (c) 2023 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
Rossberg, et al. Expires 31 August 2023 [Page 1]
Internet-Draft Case for Sub-Child SAs February 2023
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 . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 2
2. Envisioned Scenarios . . . . . . . . . . . . . . . . . . . . 3
2.1. Multicore Software Processing . . . . . . . . . . . . . . 3
2.2. Implementing QoS mechanisms . . . . . . . . . . . . . . . 4
2.3. Multipath . . . . . . . . . . . . . . . . . . . . . . . . 4
2.4. Multicast . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Discussion of possible approaches . . . . . . . . . . . . . . 4
4.1. Disabling Replay Protection . . . . . . . . . . . . . . . 5
4.2. Using multiple IKE SAs . . . . . . . . . . . . . . . . . 6
4.3. Using multiple (per-CPU) child SAs . . . . . . . . . . . 7
4.4. Increasing anti-replay window sizes . . . . . . . . . . . 8
4.5. Using Sub-Child SAs . . . . . . . . . . . . . . . . . . . 10
5. Remark on steering . . . . . . . . . . . . . . . . . . . . . 13
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
7. Security Considerations . . . . . . . . . . . . . . . . . . . 13
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 13
8.1. Normative References . . . . . . . . . . . . . . . . . . 13
8.2. Informative References . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14
1. Introduction
This document does not (yet) describe an addition to IPsec. Rather,
it attempts to describe scenarios which do not fit to the concept of
a Security Association (SA) protecting a single stream of packets.
Afterwards, possible solutions for those scenarios are discussed and
evaluated.
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.
Rossberg, et al. Expires 31 August 2023 [Page 2]
Internet-Draft Case for Sub-Child SAs February 2023
2. Envisioned Scenarios
Especially, but not limited, to intra-data-center traffic there are
several challenges, when deploying coarse-grained IPsec child SAs.
In particular, these challenges originate in implementing one of the
following techniques, or a combination thereof:
1. Multicore Software Processing
2. QoS support
3. Multipath
4. Multicast
As these challenges are due to the same root cause, they are commonly
addressed in this document. This root cause is the idea of an SA
forming a single stream of packets that is generally in-order. In
practice, the common implementation of replay protection using anti-
replay windows sets an upper limit for packets that may arrive late.
Before discussing possible solutions, the following sections will
elaborate how the techniques above collide with the idea of a single
packet stream.
2.1. Multicore Software Processing
Due to IPsec being often processed in software, small-packet
throughputs of significantly above 10Gbit/s are currently only
achievable when scaling to multiple CPU cores. However, this scaling
only works if cores do not have to synchronize tightly. In
particular, it is impossible to synchronize anti-replay windows and
sequence counters efficiently, even when using atomic CPU
instructions. Detailed explanations may be found in
[I-D.pwouters-ipsecme-multi-sa-performance]. Consequently, scaling
over multiple cores leads to multiple packet streams, one per
processing core. These streams may advance independently, and thus
introduce packet reordering. This reordering contradicts to the
concept of an anti-replay window which does not allow for packets
being too far out of order. Consequently, packets might be dropped
unpredictably.
Rossberg, et al. Expires 31 August 2023 [Page 3]
Internet-Draft Case for Sub-Child SAs February 2023
2.2. Implementing QoS mechanisms
Similarly, traffic may be categorized into different classes to
provide quality of service. QoS classes do not belong to the traffic
selector of a Child SA. So using different QoS classes for the same
traffic selector will introduce reordering of packets within a child
SA. In contrast to multicore software processing, this type of
packet reordering is intentional and not accidental. The
consequences, however, are comparable.
2.3. Multipath
A sender may also decide to send packets to single receiver via
multiple paths, e.g., by using multiple uplinks in an SD-WAN
scenario. Depending on the characteristics of the uplinks, this
shows similarities to the multicore scenario (uplinks with relatively
similar characteristics) or the QoS scenario (uplinks with rather
different characteristics).
2.4. Multicast
A multicast scenario with only a single sender does not pose an
issue, as the sender can simply increment its sequence counter. Each
receiver has a complete view of the traffic and can thus maintain its
replay window as usual. But as soon as there are multiple senders,
they would need to coordinate their sequence number usage, which is
even less efficiently implementable than in the multicore case.
Therefore, replay protection is usually disabled in multicast
scenarios.
3. Requirements
Besides the obvious requirement of not impairing security the
following shall be considered:
1. Deterministic performance
2. Scalability
3. Robustness
4. Simple implementation
4. Discussion of possible approaches
There are several approaches to deal with the presence of multiple
independent packet streams introduced by the scenarios in Section 2:
Rossberg, et al. Expires 31 August 2023 [Page 4]
Internet-Draft Case for Sub-Child SAs February 2023
1. Disabling replay protection
2. Using multiple IKE SAs
3. Using multiple child SAs
4. Increasing anti-replay window sizes
5. Using sub-child SAs
4.1. Disabling Replay Protection
A straightforward solution would be to simply disable replay
protection.
Advantages:
* Trivially solves all the reordering and synchronization issues
discussed previously. Note: This may still violate existing RFCs,
which require sequence numbers to be generated in order, but this
violation should not have an impact.
Disadvantages:
* The approach significantly lowers the level of security. Although
most upper layer protocols (e.g., TCP) provide protection from
duplicated data, this cannot be assumed for the general case.
Even if the duplicates are never delivered to a user application,
they usually do trigger responses from the receivers' network
stack, e.g., TCP RSTs or ICMP errors. This in turn enables an
attacker to trigger ciphertext generation, possibly facilitating
subsequent attacks. Such attacks have practically been used
against WiFi encryption in the early 2000s.
* It is unclear how an SA protecting multiple plaintext flows can be
distributed to multiple cores on the receiver. Receive-Side
Scaling (RSS) or explicit steering rules need some indication
which packets carry the same plaintext flow and thus need to be
sent to the same core. Otherwise, intra-flow reordering is
introduced, which may severely disturb higher level protocols,
e.g., TCP's congestion control or VoIP audio streams. Thus,
efficient multicore processing is not possible for the receiver.
This approach may be acceptable for specific scenarios (e.g.,
multicast), but not for the general case. It is especially
problematic for any multicore scenarios, as the status quo without
parallelization provides replay protection. This approach is
therefore not discussed any further.
Rossberg, et al. Expires 31 August 2023 [Page 5]
Internet-Draft Case for Sub-Child SAs February 2023
4.2. Using multiple IKE SAs
For some scenarios, it might be reasonable to set up multiple,
separate IKE SAs.
Advantages:
* As there are independent sequence numbers and anti-replay windows,
there is no need to synchronize between multiple CPU cores or
senders.
* Distinct SPIs allow RSS or explicit steering, and thus enable
processing without reordering.
* No changes to existing standards required.
Disadvantages:
* There is a time and communication overhead due to the negotiation
of every IKE SA requiring network round trips, packet processing,
asymmetric cryptography, etc. The initial setup could be
accelerated by a reactive instead of a proactive SA negotiation,
i.e., delaying the setup of the SA for a specific core or QoS
class until the first packet arrives on the core or with the
respective QoS tag. However, this is a highly debatable strategy,
as it induces either drops or large delays for the initial packets
of these flows.
* There is a state/memory overhead due to completely separate state
of every SA, e.g., traffic selectors, keys, lifetimes. To a large
extent, these states will hold identical information.
* During operation, there is overhead due to the regular rekeying of
each SA and, if enabled, dead peer detection.
* Additional effort to configure the required number of SAs must be
made. Furthermore, monitoring larger networks becomes more
complex due to the fact that multiple SAs now mapping to identical
connections.
* The failure model is unspecified if a subset of the IKE SAs cannot
be established. For example, in the multicore scenario, this
leads to packet loss or at least performance fluctuations on some
plaintext flows, depending on the core they are processed on.
Such situations historically have a bad track record, e.g.,
partially loading websites with (non-persistent) HTTP; SIP-
working-but-RTP-failing conditions in VoIP, etc.
Rossberg, et al. Expires 31 August 2023 [Page 6]
Internet-Draft Case for Sub-Child SAs February 2023
In summary, the main issue of this approach is scalability. It may
be appropriate for certain scenarios, where the total number of
additional IKE SAs is low. It is not suited for general usage in
large deployments. In particular, deploying multiple of the
techniques described in Section 2 leads to a combinatorial explosion
of the number of required SAs. For example, if one intends to
transport traffic with 8 QoS classes between two gateways with 32
cores, there would be already 256 SAs solely between these two
gateways. Even if the data plane and IKE daemon can support such a
setup, there may be too much complexity pushed into the operational
domain. Therefore, this approach is not generally applicable.
4.3. Using multiple (per-CPU) child SAs
This approach has been proposed recently as a draft
[I-D.pwouters-ipsecme-multi-sa-performance]. The draft is restricted
to the multicore scenario outlined in Section 2.1. It is similar to
establishing multiple IKE SAs, but avoids a significant portion of
their overhead by restricting the multiple instantiations to child
SAs.
Advantages:
* There is significantly less overhead compared to setting up
independent IKE SAs.
* As there are independent sequence numbers and anti-replay windows,
there is no need to synchronize between multiple CPU cores or
senders.
* Distinct SPIs allow RSS or explicit steering, and thus enable
processing without reordering.
* The draft incurs only a small change in standards and existing
source code, as multiple child SAs are already possible in IKEv2
[RFC7296], and the draft simply adds a mechanism to negotiate them
explicitly.
Disadvantages:
* Due to the setup of child SAs via separate CREATE_CHILD_SA
exchanges, there is still communications overhead, especially for
larger numbers of SAs. As for multiple IKE SAs, both a proactive
setup or a reactive setup are possible, i.e., resulting in a
longer establishment time or a less predictable runtime behavior,
respectively.
Rossberg, et al. Expires 31 August 2023 [Page 7]
Internet-Draft Case for Sub-Child SAs February 2023
* There is still some per-child-SA state overhead in the data plane.
However, as the IKE daemon knows about those SAs being child per-
Queue children of the same IKE SA, an optimized implementation
might be able to reduce that overhead to a minimum.
* During operation, there is overhead traffic due to the regular
rekeying.
* Similar to separate IKE SAs, there is the possibility of a
partially working SA if some the child SAs fail to set up. It is
not immediately clear what the correct reaction should be,
especially in the scope of a large VPN deployment, compared to the
all-or-nothing failure model when parallel child SAs are not used.
Using multiple child SAs is a significant step forward for the
multicore scenario. It is a simple (in the positive sense),
straightforward solution harvesting low-hanging fruits. But this
simplicity inherits some drawbacks from the multiple-IKE-SAs approach
caused by the independence of the child SAs regarding setup, state,
rekeying and failure. These disadvantages get worse the more child
SAs are required. Therefore, the per-CPU child SAs approach is not
an ideal fit to the other scenarios described in Section 2, or a
combination of the scenarios.
4.4. Increasing anti-replay window sizes
This approach differs from the previous two as it does not attempt to
create multiple replay windows, but to accommodate the traffic within
a single anti-replay window. This fits to the QoS scenario depicted
in Section 2.2 if any higher-prioritized traffic does not advance the
anti-replay window too far for the lower-prioritized traffic. The
idea is not applicable to the multicore or multicast scenarios, as
larger windows can only solve the problem of packets being reordered
by the network, but do not allow unsynchronized sequence counters
(as, e.g., [RFC4303] requires strict monotonicity).
Advantages:
* No changes to standards are required, as the anti-replay window
size is a local matter.
* The approach inherits the advantages of a single child SA, e.g.,
there is no setup overhead, less state overhead than with multiple
child SAs (only the larger replay windows) and no complex failure
model.
Disadvantages:
Rossberg, et al. Expires 31 August 2023 [Page 8]
Internet-Draft Case for Sub-Child SAs February 2023
* Even in software implementations, the anti-replay windows cannot
grow indefinitely large. Especially in latency-sensitive
deployments, i.e., where one would use QoS, achieving throughput
above 10 Gbit/s depends on the ability to keep state in the CPU
caches, even for a larger number of peers.
* Complex configuration: Choosing a correct value of for window size
depends not on only the number of QoS classes, but also on the
maximum divergence of sequence numbers, which in turn depends on
the QoS configuration, the possible throughput and the traffic
mix.
As discussed previously, this approach is only suitable for the QoS
and multipath scenarios. A comparison with other mechanisms requires
an estimation of the required window sizes. The time low-priority
packets may be delayed by shapers and queues depends on many
parameters, e.g., the actual and admitted traffic rates, the sizes of
admissible burst, strict-priority scheduling, etc.
An attempt to simplify the problem is to make windows large enough to
admit packets that are delayed up to a certain time threshold T.
Consider a packet being "stuck" in the network due to other packets
being prioritized. Those packets advance the replay window. Let
their Ethernet size be S and their throughput TP. It makes sense for
TP to be an interface speed, otherwise, the delayed packet would not
be stuck. We therefore end up with the following packets rates R:
+==========+=============+==========+
| S [byte] | TP [Gbit/s] | R [Mp/s] |
+==========+=============+==========+
| 64 | 10 | 14.881 |
+----------+-------------+----------+
| 1518 | 10 | 0.813 |
+----------+-------------+----------+
| 64 | 100 | 148.810 |
+----------+-------------+----------+
| 1518 | 100 | 8.127 |
+----------+-------------+----------+
Table 1: Packet rates
For T = 100 ms, this would mean that the windows must, in the worst
case, accommodate between 80,000 and 14.8 million packets. It might
be argued that the higher boundary is currently unrealistic, as it
would require a 100 Gbit/s link to be saturated with small,
prioritized packets. On the other hand, 100 ms is the acceptable
delay for VoIP, whereas for applications with low priority demands,
it might make sense to deliver even older packets.
Rossberg, et al. Expires 31 August 2023 [Page 9]
Internet-Draft Case for Sub-Child SAs February 2023
4.5. Using Sub-Child SAs
The final possibility is standardizing a new approach that tries to
combine the advantages of the approaches discussed previously. In
essence, it is the idea of allowing multiple sequence counters (and
thus use multiple anti-replay windows) per child SA. These sequence
counters must allow incrementing independently of each other, making
the approach applicable to all outlined scenarios. It is also
possible to think of the individual counter/windows pairs as _sub-
SAs_ within a child SA.
First of all, receivers must be able to distinguish those sub-SAs.
There are multiple possibilities to achieve this:
* Using the SPI: The SPI would be allocated per sub-SA, i.e., a
range of SPIs would belong to a single child SA. Therefore, it is
possible to embed, e.g., the ID of the sending core in some bits
of the SPI.
* Using the sequence number: Some bits of the sequence number would
be used to indicate the sub-SA, as proposed in
[I-D.ponchon-ipsecme-anti-replay-subspaces]. This approach
reduces the available sequence numbers. Note that the
consequences depend on whether the traffic is distributed evenly
among the individual sub-SAs (e.g., multicore scenario) or not
(e.g., QoS scenario).
* Using an additional field: Of course, it is also possible to
introduce a new field to the ESP header. This can lead to a
simpler design, but also constitutes the largest change to
existing standards.
In any case, the approach necessitates some additional
clarifications:
* The receiver may use the steering capabilities of its NIC to map
ingress packets to its sub-SAs, e.g., to different queues, to
allow for efficient multicore utilization. This is especially
important for the multicore scenario, as software redirects to
other cores must be avoided for performance reasons. The simplest
case is the sub-SA being encoded in the SPI, as many NICs already
provide features for matching on SPIs. For the other two
distinguishing mechanisms, flexible or raw matchers may be used.
Rossberg, et al. Expires 31 August 2023 [Page 10]
Internet-Draft Case for Sub-Child SAs February 2023
* The setup and renewal of sub-SAs should happen in bulk, i.e.,
there is only one exchange to set up the child SA. This leads to
reliable performance characteristics, as there is no on-demand
sub-SA creation. Furthermore, the failure model is very simple:
The child SA with all its sub-SAs exists, or it does not.
* Only the sequence counters and anti-replay windows would be
allocated per sub-SA.
* All other properties of the SA are per child SA i.e., traffic
selectors, mode, but also the key material. Using the same key
for all sub-SAs needs to be done with care to avoid effects on
security (details will follow shortly). However, if there were
different keys, neither the scalability (bulk setup and rekeying)
nor the predictable failure model would be possible.
Using a single key for multiple sub-SAs has implications on security:
* It must be ensured that this approach cannot lead to reused IVs
for counter modes. For example, in the case of AES-GCM [RFC4106],
this means either the salt must be different for each sub-SA, or
the IV space must be partitioned accordingly. Note that
partitioning the IV space is not possible with implicit IV modes
([RFC8750]), as [RFC4303] requires sequence numbers to be
initialized to zero.
* Hard limits for packet and byte counters must be scaled
accordingly. For example, if no more than 2^64 packets should be
transmitted using a given key, and the child SA consists of 2^8
sub-SAs, then every sub-SA must not be allowed to send more than
2^56 packets, in case no fine-grained synchronization is possible.
In case transmission happens on the same CPU core, overcommitting
may be possible as long as the total number of packets or bytes is
ensured to be never exceeded.
* Rekey limits must apply to all sub-SAs combined. For example, if
a child SA is configured to be rekeyed after transmission of X
bytes or Y packets, then the rekey must be triggered if the sum of
bytes or packets on all sub-SAs reaches X or Y. For situations
where overcommitting is not possible, we suggest to reference the
sub-SA with the maximum number of bytes/packets already sent, say
X'_max and Y'_max. X'_max and Y'_max are multiplied with number
of sub-SAs and if that value exceeds X or Y, a rekeying is
initiated.
Rossberg, et al. Expires 31 August 2023 [Page 11]
Internet-Draft Case for Sub-Child SAs February 2023
* In case SPIs or an explicit header field are used to encode sub-
SAs it may (theoretically) be possible to send more than 2^64
packets using a single key. This may form a problem for ciphers,
such as AES-GCM. In this case a hard limit of at most 2^64
packets MUST be enforced.
Advantages:
* Independent sequence numbers and anti-replay windows are
available.
* The approach allows for RSS or explicit steering, especially if
the SPI-encoding is used.
* Most scalable approach: The child SA setup requires exchanging,
e.g., an SPI range but does not depend on the number of sub-SAs
allocated. Similarly, there is only an ID, sequence counters, and
an anti-replay window to store per sub-SA. The remainder of state
can be shared.
* There is no rekeying overhead, as just a single Child SA needs to
be rekeyed.
* Predictable performance characteristics due to the batched,
proactive establishment.
* Clean failure model due to the all-or-nothing setup.
Disadvantages:
* There are potential security implications, which must be discussed
thoroughly, to avoid weakening security at any point.
* The change in the data plane may seem be a bit more complex change
compared to per-CPU child SAs. Nevertheless, fallback SAs like
mentioned in [I-D.pwouters-ipsecme-multi-sa-performance] are
avoided.
Compared to setting up separate IKE or child SAs, it might be argued
that the idea of sub-SAs keeps the complexity and overhead away from
the VPN's operation. Furthermore, storing an SPI, a 64-bit sequence
number, and a replay window for 64 packets for 64 different QoS
classes requires a total of 10240 bit. This is significantly less
than even the lower boundary established for the approach described
in Section 4.4. However, of the discussed alternatives, it is the
most complex change to existing standard and implementation
semantics.
Rossberg, et al. Expires 31 August 2023 [Page 12]
Internet-Draft Case for Sub-Child SAs February 2023
5. Remark on steering
Please note: For any of the approaches it is essential for the
receiver to steer traffic being generated by a CPU core of the sender
to a determined CPU core that handles the incoming traffic. For
example, if a two CPU cores at the sender generate large amounts of
traffic in one QoS class, it is not only sufficient to perform RSS on
the child SAs or sub-child SAs, as this would not avoid the two
streams being mapped to the same receiver CPU.
6. IANA Considerations
This memo includes no request to IANA.
7. Security Considerations
*TODO:* In its current state, this draft discusses multiple
alternatives. Please refer to Section 4 for a discussion including
remarks on security.
8. References
8.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>.
[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>.
[RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T.
Kivinen, "Internet Key Exchange Protocol Version 2
(IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October
2014, <https://www.rfc-editor.org/info/rfc7296>.
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)",
RFC 4303, DOI 10.17487/RFC4303, December 2005,
<https://www.rfc-editor.org/info/rfc4303>.
[RFC4106] Viega, J. and D. McGrew, "The Use of Galois/Counter Mode
(GCM) in IPsec Encapsulating Security Payload (ESP)",
RFC 4106, DOI 10.17487/RFC4106, June 2005,
<https://www.rfc-editor.org/info/rfc4106>.
Rossberg, et al. Expires 31 August 2023 [Page 13]
Internet-Draft Case for Sub-Child SAs February 2023
[RFC8750] Migault, D., Guggemos, T., and Y. Nir, "Implicit
Initialization Vector (IV) for Counter-Based Ciphers in
Encapsulating Security Payload (ESP)", RFC 8750,
DOI 10.17487/RFC8750, March 2020,
<https://www.rfc-editor.org/info/rfc8750>.
8.2. Informative References
[I-D.pwouters-ipsecme-multi-sa-performance]
Antony, A., Brunner, T., Klassert, S., and P. Wouters,
"IKEv2 support for per-queue Child SAs", Work in Progress,
Internet-Draft, draft-pwouters-ipsecme-multi-sa-
performance-05, 8 November 2022,
<https://datatracker.ietf.org/doc/html/draft-pwouters-
ipsecme-multi-sa-performance-05>.
[I-D.ponchon-ipsecme-anti-replay-subspaces]
Ponchon, P., Shaikh, M., Pfister, P., and G. Solignac,
"IPsec and IKE anti-replay sequence number subspaces for
multi-path tunnels and multi-core processing", Work in
Progress, Internet-Draft, draft-ponchon-ipsecme-anti-
replay-subspaces-00, 24 October 2022,
<https://datatracker.ietf.org/doc/html/draft-ponchon-
ipsecme-anti-replay-subspaces-00>.
Authors' Addresses
Michael Rossberg
Technische Universität Ilmenau
Helmholtzplatz 5
98693 Ilmenau
Germany
Email: michael.rossberg@tu-ilmenau.de
Steffen Klassert
secunet Security Networks AG
Ammonstrasse 74
01067 Dresden
Germany
Email: steffen.klassert@secunet.com
Michael Pfeiffer
Technische Universität Ilmenau
Helmholtzplatz 5
98693 Ilmenau
Germany
Rossberg, et al. Expires 31 August 2023 [Page 14]
Internet-Draft Case for Sub-Child SAs February 2023
Email: michael.pfeiffer@tu-ilmenau.de
Rossberg, et al. Expires 31 August 2023 [Page 15]
