[Last-Call] Secdir last call review of draft-ietf-ipsecme-multi-sa-performance-06

Rich Salz via Datatracker <noreply@ietf.org> Thu, 18 April 2024 16:32 UTC

Return-Path: <noreply@ietf.org>
X-Original-To: last-call@ietf.org
Delivered-To: last-call@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 546E7C1654EC; Thu, 18 Apr 2024 09:32:37 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Rich Salz via Datatracker <noreply@ietf.org>
To: secdir@ietf.org
Cc: draft-ietf-ipsecme-multi-sa-performance.all@ietf.org, ipsec@ietf.org, last-call@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 12.10.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <171345795733.61503.13030438006311756622@ietfa.amsl.com>
Reply-To: Rich Salz <rsalz@akamai.com>
Date: Thu, 18 Apr 2024 09:32:37 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/last-call/zgo_vY5kH0Bqs-xCqBOx5x8BhI8>
Subject: [Last-Call] Secdir last call review of draft-ietf-ipsecme-multi-sa-performance-06
X-BeenThere: last-call@ietf.org
X-Mailman-Version: 2.1.39
List-Id: IETF Last Calls <last-call.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/last-call>, <mailto:last-call-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/last-call/>
List-Post: <mailto:last-call@ietf.org>
List-Help: <mailto:last-call-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/last-call>, <mailto:last-call-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 18 Apr 2024 16:32:37 -0000

Reviewer: Rich Salz
Review result: Ready

I have reviewed this document as part of the security directorate's ongoing
effort to review all IETF documents being processed by the IESG. These comments
were written primarily for the benefit of the security area directors. Document
editors and WG chairs should treat these comments just like any other last call
comments.

My knowledge of IPsec is limited: I think of it as "TLS for IP"

This draft documents a way for peers to negotiate and use additional security
associations for processing the cryptography associated with the traffic. The
security considerations section is good, pointing out the concerns about
allowing "just anyone" to request a reservation, particular a CPU-tied one, for
that work.

This document assumes all readers know what acronyms like "SA" stand for.  This
probably makes sense, it's only the occasional newcomer reader (like Your
Humble Reviewer) who have to search to find out what they mean. Perhaps other
long-term activities should follow the DNS example of periodically creating a
glossary RFC. But that issue does not affect this document.