Re: [IPsec] [Last-Call] [secdir] Secdir last call review of draft-ietf-ipsecme-rfc8229bis-06

Valery Smyslov <svan@elvis.ru> Thu, 02 June 2022 15:03 UTC

Return-Path: <svan@elvis.ru>
X-Original-To: ipsec@ietfa.amsl.com
Delivered-To: ipsec@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EEF03C157B35; Thu, 2 Jun 2022 08:03:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.108
X-Spam-Level:
X-Spam-Status: No, score=-7.108 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=elvis.ru
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kQPyiF5A6ghL; Thu, 2 Jun 2022 08:03:46 -0700 (PDT)
Received: from akmail.elvis.ru (akmail.elvis.ru [82.138.51.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 57823C14F73F; Thu, 2 Jun 2022 08:03:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=elvis.ru; s=mail; h=Content-Type:MIME-Version:Message-ID:Date:Subject:In-Reply-To: References:CC:To:From:Sender:Reply-To:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=MlbVXzUcMLDoeAPS3bO1lMBL56dFk7+PJ674KXdQUwo=; b=ec56sT3zXT6RZPd7IfB/W9cqv6 +j4y9R267TPfAPe4kkLG0uJxsfomKVEosk5T91JAH5IxTN08u+FD97+W1xWanWSdpjbo9gXuuJNj5 tqFDh3OqGjcpvg5JO/CK4PG7umVzbY9aBiOK+GeLekfMznWC0zI7L7gTl8JBVaTUP//g=;
Received: from kmail.elvis.ru ([93.188.44.208]) by akmail.elvis.ru with esmtp (Exim 4.92) (envelope-from <svan@elvis.ru>) id 1nwmMN-0004eb-NU; Thu, 02 Jun 2022 18:03:39 +0300
Received: from mail16.office.elvis.ru ([10.111.1.29] helo=mail.office.elvis.ru) by kmail.elvis.ru with esmtp (Exim 4.92) (envelope-from <svan@elvis.ru>) id 1nwmMN-0005y4-Gt; Thu, 02 Jun 2022 18:03:39 +0300
Received: from MAIL16.office.elvis.ru (10.111.1.29) by MAIL16.office.elvis.ru (10.111.1.29) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1779.2; Thu, 2 Jun 2022 18:03:39 +0300
Received: from buildpc (10.111.10.33) by MAIL16.office.elvis.ru (10.111.1.29) with Microsoft SMTP Server id 15.1.1779.2 via Frontend Transport; Thu, 2 Jun 2022 18:03:39 +0300
From: Valery Smyslov <svan@elvis.ru>
To: touch@strayalpha.com
CC: draft-ietf-ipsecme-rfc8229bis.all@ietf.org, secdir@ietf.org, ipsec@ietf.org, last-call@ietf.org
References: <165377251630.6282.16767658545384357479@ietfa.amsl.com> <077301d8741b$c0fe9b40$42fbd1c0$@elvis.ru> <25237.6715.619617.181961@fireball.acr.fi> <08f501d874df$90e95750$b2bc05f0$@elvis.ru> <25238.13419.293263.562580@fireball.acr.fi> <0a1601d8750e$051083f0$0f318bd0$@elvis.ru> <25239.24036.317688.539399@fireball.acr.fi> <0b4301d875b9$ae525320$0af6f960$@elvis.ru> <C215CCAA-62D6-4C8D-88A1-248D17AB7E54@strayalpha.com> <0ba801d875d8$2c7a7c00$856f7400$@elvis.ru> <0c4501d87656$30543680$90fca380$@elvis.ru> <FBE7881A-92AB-47F3-9465-5DC97B0E2BBC@strayalpha.com>
In-Reply-To: <FBE7881A-92AB-47F3-9465-5DC97B0E2BBC@strayalpha.com>
Date: Thu, 02 Jun 2022 18:03:32 +0300
Message-ID: <005301d87691$ecb1f250$c615d6f0$@elvis.ru>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0054_01D876AB.1200B0F0"
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQKKl9px7X7eA1CQ6TUrJpeus4VMBQFqn8/DAb05IO0BpRHmcAMg7P2lAmkFNCsB/67htgKpxPc/AlUKDVUCIGbikQGuFbunAcEIWAKrIMcrgA==
Content-Language: ru
X-CrossPremisesHeadersFilteredBySendConnector: MAIL16.office.elvis.ru
X-OrganizationHeadersPreserved: MAIL16.office.elvis.ru
X-KLMS-AntiSpam-Interceptor-Info: not scanned
X-KLMS-Rule-ID: 1
X-KLMS-Message-Action: clean
X-KLMS-AntiSpam-Status: not scanned, disabled by settings
X-KLMS-AntiPhishing: Clean, bases: 2022/06/02 12:30:00
X-KLMS-AntiVirus: Kaspersky Security for Linux Mail Server, version 8.0.3.30, bases: 2022/06/02 12:19:00 #19650230
X-KLMS-AntiVirus-Status: Clean, skipped
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipsec/eliLRJgNXLVq1jviwKij6iQkUiY>
Subject: Re: [IPsec] [Last-Call] [secdir] Secdir last call review of draft-ietf-ipsecme-rfc8229bis-06
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
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: Thu, 02 Jun 2022 15:03:51 -0000

HI Joe,

 

On Jun 2, 2022, at 12:55 AM, Valery Smyslov < <mailto:svan@elvis.ru> svan@elvis.ru> wrote:

 

HI Joe,

 

one more question:

 

          You can also note that there are ways to mitigate the cost of resync when

          this implementation is tightly coupled with TCP, e.g., by ensuring every Nth

          IPsec packet starts at the beginning of a new TCP packet.

 

         How would this help? Can you please elaborate?

 

If every 4th IPsec packet is always aligned to the TCP segment data start, then resync checks could be simple and rapid - check only
the first bytes for a known pattern.

 

That makes resync happen with lower overhead, i.e., rather than searching the whole payload.

 

          Interesting idea, but how the receiving node would know that sending node employs this method?

          And, in my understanding some middleboxes can re-arrange TCP segments, merging and splitting them,

          so the beginning of IPsec packet may still appear in the middle of TCP segment (the same can happen

          with retransmissions, but I guess you assume that sending TCP/IP stack would take care in this case, but it adds
complexity).

 

         So, I think that the idea is interesting, but the additional complexity and unreliability makes it not so attractive.

 

          Regards,

          Valery.

 

Joe