[IPsec] Secdir last call review of draft-ietf-ipsecme-iptfs-12

Shawn Emery via Datatracker <noreply@ietf.org> Tue, 10 May 2022 07:24 UTC

Return-Path: <noreply@ietf.org>
X-Original-To: ipsec@ietf.org
Delivered-To: ipsec@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 425E5C157B40; Tue, 10 May 2022 00:24:59 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Shawn Emery via Datatracker <noreply@ietf.org>
To: secdir@ietf.org
Cc: draft-ietf-ipsecme-iptfs.all@ietf.org, ipsec@ietf.org, last-call@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 8.1.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <165216749926.36909.8537062802254259970@ietfa.amsl.com>
Reply-To: Shawn Emery <shawn.emery@gmail.com>
Date: Tue, 10 May 2022 00:24:59 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipsec/52jK2ccjWp3MHOwRSx3HOWDzUaY>
Subject: [IPsec] Secdir last call review of draft-ietf-ipsecme-iptfs-12
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.34
List-Id: Discussion of IPsec protocols <ipsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipsec>, <mailto:ipsec-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ipsec/>
List-Post: <mailto:ipsec@ietf.org>
List-Help: <mailto:ipsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipsec>, <mailto:ipsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 10 May 2022 07:24:59 -0000

Reviewer: Shawn Emery
Review result: Has Nits

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.

This draft specifies a aggregation and fragmentation mechanism when using
Encapsulating Security Payload (ESP) for IP packets, in which the primary
purpose of the specification is to provide Traffic Flow Confidentiality (TFC)
for said packets.

The security considerations section does exist and describes that this
specification adds security through TFC.  The section goes on to state that the
underlying security of this mechanism, IP Traffic Flow Security (IP-TFS), is
also applicable (through RFC 4303 (ESP) and RFC 7296 (IKEv2)).  In addition,
the proposed mechanism supports Explicit Congestion Notification (ECN), which
may be used as a covert channel because it is not protected by IPsec.  Ergo,
this specification states that ECN SHOULD NOT be enabled by default.  The
section concludes in that TFC should not change network congestion in a
predictable way, but if it does then a non-congestion control mode should be
used instead.  I agree with the accuracy and scope of the aforementioned
assertions.

General comments:

Well written, just a couple of nits.

Editorial comments:

s/and it use/and its use/
s/apply to IP-TFS/apply to IP-TFC/

Shawn.
--