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
- [IPsec] Secdir last call review of draft-ietf-ips… Christian Huitema via Datatracker
- Re: [IPsec] Secdir last call review of draft-ietf… Valery Smyslov
- Re: [IPsec] [Last-Call] Secdir last call review o… Christian Huitema
- Re: [IPsec] [Last-Call] Secdir last call review o… touch@strayalpha.com
- Re: [IPsec] [Last-Call] Secdir last call review o… Valery Smyslov
- Re: [IPsec] [Last-Call] Secdir last call review o… touch@strayalpha.com
- Re: [IPsec] [Last-Call] Secdir last call review o… Valery Smyslov
- Re: [IPsec] [Last-Call] Secdir last call review o… touch@strayalpha.com
- Re: [IPsec] Secdir last call review of draft-ietf… Tero Kivinen
- Re: [IPsec] [Last-Call] Secdir last call review o… touch@strayalpha.com
- Re: [IPsec] Secdir last call review of draft-ietf… Valery Smyslov
- Re: [IPsec] [Last-Call] Secdir last call review o… Valery Smyslov
- Re: [IPsec] Secdir last call review of draft-ietf… Tero Kivinen
- Re: [IPsec] [Last-Call] Secdir last call review o… touch@strayalpha.com
- Re: [IPsec] [Last-Call] Secdir last call review o… touch@strayalpha.com
- Re: [IPsec] Secdir last call review of draft-ietf… Valery Smyslov
- Re: [IPsec] [Last-Call] Secdir last call review o… Valery Smyslov
- Re: [IPsec] [Last-Call] Secdir last call review o… Christian Huitema
- Re: [IPsec] [Last-Call] Secdir last call review o… Christian Huitema
- Re: [IPsec] Secdir last call review of draft-ietf… Tero Kivinen
- Re: [IPsec] Secdir last call review of draft-ietf… Valery Smyslov
- Re: [IPsec] [Last-Call] Secdir last call review o… touch@strayalpha.com
- Re: [IPsec] [secdir] [Last-Call] Secdir last call… Valery Smyslov
- Re: [IPsec] [secdir] [Last-Call] Secdir last call… Valery Smyslov
- Re: [IPsec] [Last-Call] [secdir] Secdir last call… touch@strayalpha.com
- Re: [IPsec] [secdir] [Last-Call] Secdir last call… touch@strayalpha.com
- Re: [IPsec] [Last-Call] [secdir] Secdir last call… Valery Smyslov
- Re: [IPsec] [secdir] [Last-Call] Secdir last call… Valery Smyslov
- Re: [IPsec] [Last-Call] [secdir] Secdir last call… touch@strayalpha.com
- Re: [IPsec] Secdir last call review of draft-ietf… Tero Kivinen