IPsec and IKE anti-replay sequence number subspaces for traffic-engineered paths and multi-core processing
draft-ponchon-ipsecme-anti-replay-subspaces-03
| Document | Type |
Expired Internet-Draft
(individual)
Expired & archived
|
|
|---|---|---|---|
| Authors | Paul Ponchon , Mohsin Shaikh , Hadi Dernaika , Pierre Pfister , Guillaume Solignac | ||
| Last updated | 2024-04-25 (Latest revision 2023-10-23) | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | Expired | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
This Internet-Draft is no longer active. A copy of the expired Internet-Draft is available in these formats:
Abstract
This document discusses the challenges of running IPsec with anti- replay in multi-core environments where packets may be re-ordered (e.g., when sent over multiple IP paths, traffic-engineered paths and/or using different QoS classes). 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.
Authors
Paul Ponchon
Mohsin Shaikh
Hadi Dernaika
Pierre Pfister
Guillaume Solignac
(Note: The e-mail addresses provided for the authors of this Internet-Draft may no longer be valid.)