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

"touch@strayalpha.com" <touch@strayalpha.com> Tue, 31 May 2022 16:12 UTC

Return-Path: <touch@strayalpha.com>
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 A5824C157B43; Tue, 31 May 2022 09:12:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.328
X-Spam-Level:
X-Spam-Status: No, score=-1.328 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, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=strayalpha.com
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 BRxZqh2kErzV; Tue, 31 May 2022 09:11:56 -0700 (PDT)
Received: from server217-1.web-hosting.com (server217-1.web-hosting.com [198.54.114.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A1BA3C157B48; Tue, 31 May 2022 09:11:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=To:References:Message-Id:Cc:Date:In-Reply-To: From:Subject:Mime-Version:Content-Type: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=22zHRCkASHV5EIDPBp0C8wKgK6D5OLLRzSpFOGoAFYM=; b=CdGgs4eBmVwkpaNMvxJuKHEh9Z l3brrZ1lwz7QlojsO+1jF8i5M/ByVMxK3NBFk87UZrsXK2okLmKQkMcMo6NbxLrH+uyNn1QKjwmA8 0nJeH2IwJfibTKl2gGcscNzHyXGZwwFmZ65XvhXzfs6floI6/vTe1/GUF3arjyfv+N/ZHdY7UZtXj VCjLz8wLSAAnxMrPrljIpz8oM7A5Q8teVevVCjhPAJ1sNzi94te9AVvQDwRnhJsLNPSiTFHD4oAI0 b4GS8LEn6L0TyGyaR1vmcABq2ejoXvDcAItLiHOJKIN1BxIRUFs0Gv+tDxafxssNSyDySdookVjaB 2e7GUdiA==;
Received: from cpe-172-114-237-88.socal.res.rr.com ([172.114.237.88]:55048 helo=smtpclient.apple) by server217.web-hosting.com with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.95) (envelope-from <touch@strayalpha.com>) id 1nw4TH-003uyQ-DS; Tue, 31 May 2022 12:11:55 -0400
Content-Type: multipart/alternative; boundary="Apple-Mail=_B991737F-EF35-43E0-AE43-79F733BFA4B1"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.100.31\))
From: "touch@strayalpha.com" <touch@strayalpha.com>
In-Reply-To: <25238.13419.293263.562580@fireball.acr.fi>
Date: Tue, 31 May 2022 09:11:43 -0700
Cc: Valery Smyslov <svan@elvis.ru>, Christian Huitema <huitema@huitema.net>, secdir@ietf.org, draft-ietf-ipsecme-rfc8229bis.all@ietf.org, ipsec@ietf.org, last-call@ietf.org
Message-Id: <DA2ECB10-11A9-4781-80E2-ADFEED2181F4@strayalpha.com>
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>
To: Tero Kivinen <kivinen@iki.fi>
X-Mailer: Apple Mail (2.3696.100.31)
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - server217.web-hosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - strayalpha.com
X-Get-Message-Sender-Via: server217.web-hosting.com: authenticated_id: touch@strayalpha.com
X-Authenticated-Sender: server217.web-hosting.com: touch@strayalpha.com
X-Source:
X-Source-Args:
X-Source-Dir:
X-From-Rewrite: unmodified, already matched
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipsec/hSo4Af8aYP6owJFPbMwV_Y2gHcI>
Subject: Re: [IPsec] [Last-Call] Secdir last call review of draft-ietf-ipsecme-rfc8229bis-06
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.34
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: Tue, 31 May 2022 16:12:00 -0000

On May 31, 2022, at 8:29 AM, Tero Kivinen <kivinen@iki.fi> wrote:
> 
> I think we should tear down the TCP stream immediately if we detect
> that length bytes can't be correct.

If that’s the case, then you’re opening up this approach to a much lower bar to attacks.

It would be significantly more useful to find a way to resync. I don’t have any particular suggestions there, except maybe when sync is lost to scan for a known byte pattern and try to resync there. If the IPsec then starts to work again, you’re set. If not, you keep scanning.

This is the approach ATM used to find cell boundaries.

Is there a reason not to include that as a fallback when such attacks are seen as a mitigation to avoid the restart overhead??

Joe