Negotiation of multiple Child Security Association with the Internet Key Exchange Protocol Version 2 (IKEv2)
draft-mglt-ipsecme-multiple-child-sa-00
|
Document |
Type |
|
Active Internet-Draft (individual)
|
|
Last updated |
|
2019-11-17
|
|
Stream |
|
(None)
|
|
Intended RFC status |
|
(None)
|
|
Formats |
|
plain text
xml
pdf
htmlized
bibtex
|
Stream |
Stream state |
|
(No stream defined) |
|
Consensus Boilerplate |
|
Unknown
|
|
RFC Editor Note |
|
(None)
|
IESG |
IESG state |
|
I-D Exists
|
|
Telechat date |
|
|
|
Responsible AD |
|
(None)
|
|
Send notices to |
|
(None)
|
ipsecme D. Migault
Internet-Draft Ericsson
Intended status: Standards Track S. Klassert
Expires: May 20, 2020 Secunet
November 17, 2019
Negotiation of multiple Child Security Association with the Internet Key
Exchange Protocol Version 2 (IKEv2)
draft-mglt-ipsecme-multiple-child-sa-00
Abstract
IPsec packet processing with one Security Association (SA) per core
is more efficient than having a SA shared by the multiple cores.
This document optimizes the negotiation of multiple unidirectional
SAs in order to minimize the impact SAs being shared by multiple
cores.
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 May 20, 2020.
Copyright Notice
Copyright (c) 2019 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
Migault & Klassert Expires May 20, 2020 [Page 1]
Internet-Draft Multiple Child SA November 2019
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Requirements Notation . . . . . . . . . . . . . . . . . . . . 2
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
3. Protocol Exchange . . . . . . . . . . . . . . . . . . . . . . 3
4. Error Handling . . . . . . . . . . . . . . . . . . . . . . . 4
5. Payload Description . . . . . . . . . . . . . . . . . . . . . 5
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
7. Security Consideration . . . . . . . . . . . . . . . . . . . 6
8. Normative References . . . . . . . . . . . . . . . . . . . . 6
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7
1. Requirements Notation
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 BCP 14
[RFC2119] [RFC8174] when, and only when, they appear in all capitals,
as shown here.
2. Introduction
IPsec processing (on Linux) is more efficient with SA attached to a
given core as opposed to a SA shared by multiple cores. Suppose an
initiator and a responder respectively with n and p cores establish
an IPsec protected communication defined by Traffic Selectors (TSi,
TSr). IPsec processing performance may be increased if the initiator
(resp. the responder) processes IPsec packets via n (resp. p)
distinct unidirectional SAs rather than having a SA shared by the n
(resp p) cores.
Optimally the number of SAs is expected to be equal to the number of
cores which can be different for each peer. When peers have a
different number of cores, the number of SA is expected to be equal
to the highest number of cores to minimize context switching and the
minimum number of cores to optimize memory space. In fact, having
fewer SAs than the number of cores may result in switching the SA
context to unused cores. On the other hand, having a greater number
of SAs results in a core sharing multiple SAs for the same purpose,
which does not improve performances at the cost of an additional SA
stored in the kernel.
Currently Child SA are agreed with IKEv2 [RFC7296] CREATE_CHILD_SA
exchange. Additional Child SAs (in our case n or p) would require n
Migault & Klassert Expires May 20, 2020 [Page 2]
Internet-Draft Multiple Child SA November 2019
or p CREATE_CHILD_SA exchanges that add multiple round trips carrying
similar payloads (TSi, TSr, SA) which is not necessary.
Show full document text