Skip to main content

IKEv2 support for per-resource Child SAs
draft-ietf-ipsecme-multi-sa-performance-08

Approval announcement
Draft of message to be sent after approval:

Announcement

From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
Cc: The IESG <iesg@ietf.org>, draft-ietf-ipsecme-multi-sa-performance@ietf.org, ipsec@ietf.org, ipsecme-chairs@ietf.org, kivinen@iki.fi, rdd@cert.org, rfc-editor@rfc-editor.org
Subject: Protocol Action: 'IKEv2 support for per-resource Child SAs' to Proposed Standard (draft-ietf-ipsecme-multi-sa-performance-06.txt)

The IESG has approved the following document:
- 'IKEv2 support for per-resource Child SAs'
  (draft-ietf-ipsecme-multi-sa-performance-06.txt) as Proposed Standard

This document is the product of the IP Security Maintenance and Extensions
Working Group.

The IESG contact persons are Paul Wouters and Roman Danyliw.

A URL of this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-ietf-ipsecme-multi-sa-performance/


Ballot Text

Technical Summary

   This document defines two Notify Message Type Payloads for the
   Internet Key Exchange Protocol Version 2 (IKEv2) to support the
   negotiation of multiple Child SAs with the same Traffic Selectors
   used on different resources, such as CPUs, to increase bandwidth of
   IPsec traffic between peers.

   The SA_RESOURCE_INFO notification is used to convey information that
   the negotiated Child SA and subsequent new Child SAs with the same
   Traffic Selectors are a logical group of Child SAs where most or all
   of the Child SAs are bound to a specific resource, such as a specific
   CPU.  The TS_MAX_QUEUE notify conveys that the peer is unwilling to
   create more additional Child SAs for this particular negotiated
   Traffic Selector combination.

   Using multiple Child SAs with the same Traffic Selectors has the
   benefit that each resource holding the Child SA has its own Sequence
   Number Counter, ensuring that CPUs don't have to synchronize their
   cryptographic state or disable their packet replay protection.

Working Group Summary

    It reached broad agreement as a valid and useful solution, although some
    raised concerns that accepting this document might mean similar related
    drafts might not see adoption. This mostly related to the "sequence number
    subspaces" draft, which is being worked on as part of a new ESPv4.

    There was a long discussion about whether or not to negotiate the number of
    multiple SAs, but it became obvious that no agreement made sense, and thus to
    leave this open with only a local policy maximum safety.

Document Quality

Implementations: 

** XFRM-PCPU-v3
   https://git.kernel.org/pub/scm/linux/kernel/git/klassert/linux-stk.git/log/?h=xfrm-pcpu-v3

** Libreswan Project, pcpu-3
   https://libreswan.org/wiki/XFRM_pCPU

** StrongSwan Project
   https://github.com/strongswan/strongswan/tree/per-cpu-sas-poc/

** iproute2 Project
   https://github.com/antonyantony/iproute2/tree/pcpu-v1

Personnel

   The Document Shepherd for this document is Tero Kivinen. The Responsible
   Area Director is Roman Danyliw.

RFC Editor Note