[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.
- [secdir] Secdir telechat review of draft-ietf-ips… Rifaat Shekh-Yusef via Datatracker
- Re: [secdir] Secdir telechat review of draft-ietf… Valery Smyslov
- Re: [secdir] Secdir telechat review of draft-ietf… Rifaat Shekh-Yusef