[secdir] Secdir telechat review of draft-ietf-ipsecme-rfc8229bis-07

Rifaat Shekh-Yusef via Datatracker <noreply@ietf.org> Thu, 04 August 2022 13:00 UTC

Return-Path: <noreply@ietf.org>
X-Original-To: secdir@ietf.org
Delivered-To: secdir@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 390FEC13C516; Thu, 4 Aug 2022 06:00:13 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Rifaat Shekh-Yusef via Datatracker <noreply@ietf.org>
To: secdir@ietf.org
Cc: draft-ietf-ipsecme-rfc8229bis.all@ietf.org, ipsec@ietf.org, last-call@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 8.12.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <165961801322.55199.12307045998936736017@ietfa.amsl.com>
Reply-To: Rifaat Shekh-Yusef <rifaat.s.ietf@gmail.com>
Date: Thu, 04 Aug 2022 06:00:13 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/m1AkuGIH0xoi-BV4Cp1Vl_wBJoo>
Subject: [secdir] Secdir telechat review of draft-ietf-ipsecme-rfc8229bis-07
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.39
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/secdir/>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 04 Aug 2022 13:00:13 -0000

Reviewer: Rifaat Shekh-Yusef
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.

The summary of the review is: Ready with one comment

The security considerations section describes two potential recovery mechanisms
to an injection attack. The first option is to close the TCP connection and let
the originator recreate it. The second option is a re-sync mechanism. The way I
read the document, it seems that the first option is the recommended one, but
it is not clear to me when should the second option be used, if at all. It
would be great if some text be added to clarify this.