Re: [IPsec] [Last-Call] Secdir last call review of draft-ietf-ipsecme-rfc8229bis-06
Valery Smyslov <svan@elvis.ru> Tue, 31 May 2022 11:14 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 119A7C14F74E; Tue, 31 May 2022 04:14:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.108
X-Spam-Level:
X-Spam-Status: No, score=-2.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, 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 x0n6P-QCDSy0; Tue, 31 May 2022 04:14:24 -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 01B42C14F747; Tue, 31 May 2022 04:14:23 -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=SFzspPgj1RuGP8tFAMtY4hWPXfSTEHByiB6BP94IpMI=; b=K8CQjkMYFQXQaSlddINagyrqOo 946uslWYvsisBxBqWJ1Sv8l0RVUqGp1bOkZF78/cjgWVkT9Iixkb0HnctaFhSa+Xrvbgktt1/7pjh 5OenY4665GA0Kx9kvKQ8rRMdw3rMO7jIogQ+Cul38VdmItNQX6++UNdkviFo+T6ktjs4=;
Received: from kmail.elvis.ru ([93.188.44.208]) by akmail.elvis.ru with esmtp (Exim 4.92) (envelope-from <svan@elvis.ru>) id 1nvzpK-0005uv-VO; Tue, 31 May 2022 14:14:19 +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 1nvzpK-0007gP-Od; Tue, 31 May 2022 14:14:18 +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; Tue, 31 May 2022 14:14:18 +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; Tue, 31 May 2022 14:14:18 +0300
From: Valery Smyslov <svan@elvis.ru>
To: touch@strayalpha.com, 'Tero Kivinen' <kivinen@iki.fi>
CC: 'Christian Huitema' <huitema@huitema.net>, secdir@ietf.org, draft-ietf-ipsecme-rfc8229bis.all@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> <80DC0FE1-6C58-4E0A-A9C4-795469B520B5@strayalpha.com>
In-Reply-To: <80DC0FE1-6C58-4E0A-A9C4-795469B520B5@strayalpha.com>
Date: Tue, 31 May 2022 14:14:19 +0300
Message-ID: <08f601d874df$92e94600$b8bbd200$@elvis.ru>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_08F7_01D874F8.B83804A0"
X-Mailer: Microsoft Outlook 14.0
Content-Language: ru
Thread-Index: AQKKl9px7X7eA1CQ6TUrJpeus4VMBQFqn8/DAb05IO0CeVcP8qungwmQ
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/05/31 10:19:00
X-KLMS-AntiVirus: Kaspersky Security for Linux Mail Server, version 8.0.3.30, bases: 2022/05/31 05:46:00 #19627614
X-KLMS-AntiVirus-Status: Clean, skipped
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipsec/oqP5Iq7GpU75wquwkhH8zMPEOeY>
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 11:14:29 -0000
Hi Joe, From: touch@strayalpha.com [mailto:touch@strayalpha.com] Sent: Monday, May 30, 2022 10:57 PM To: Tero Kivinen Cc: Valery Smyslov; Christian Huitema; secdir@ietf.org; draft-ietf-ipsecme-rfc8229bis.all@ietf.org; ipsec@ietf.org; last-call@ietf.org Subject: Re: [Last-Call] Secdir last call review of draft-ietf-ipsecme-rfc8229bis-06 On May 30, 2022, at 12:25 PM, Tero Kivinen <kivinen@iki.fi> wrote: I think we need to add text explaining how to detect when the TCP length framing gets messed up by attacks, and how to recover (i.e., close down the TCP channel and recreate the TCP channel). The impact of RSTs can be limited for this purpose by recommending RFC5961 for these connections. I’ve added a reference to RFC 5961. Currently the new text in the Security considerations looks like: TCP connections are also susceptible to RST and other spoofing attacks [RFC4953]. This specification makes IPsec tolerant of sudden TCP connection drops, but if an attacker is able to tear down TCP connections, IPsec connection's performance can suffer, effectively making this a DoS attack. TCP data injection attacks have no effect on application data since IPsec provides data integrity. However, they can have some effect, mostly as a DoS attack: o if an attacker alters the content of the Length field that separates packets, then the receiver will incorrectly identify the margins of the following packets and will drop all of them or even tear down the TCP connection if the content of the Length field happens to be 0 or 1 (see Section 3) o if the content of an IKE message is altered, then it will be dropped by the receiver; if the dropped message is the IKE request message, then the initiator will tear down the IKE SA after some timeout, since in most cases the request message will not be retransmitted (as advised in Section 6.2) and thus the response will never be received o if an attacker alters the non-ESP marker then IKE packets will be dispatched to ESP and sometimes visa versa, those packets will be dropped o if an attacker modifies TCP-Encapsulated stream prefix or unencrypted IKE messages before IKE SA is established, then in most cases this will result in failure to establish IKE SA, often with false "authentication failed" diagnostics [RFC5961] discusses how TCP injection attacks can be mitigated. Note, that data injection attacks are also possible on IP level (e.g. when IP fragmentation is used) resulting in DoS attack even if TCP encapsulation is not used. On the other hand, TCP injection attacks are easier to mount than the IP fragmentation injection attacks, because TCP keeps a long receive window open that's a sitting target for such attacks. An attacker capable of blocking UDP traffic can force peers to use TCP encapsulation, thus degrading the performance and making the connection more vulnerable to DoS attacks. Note, that attacker capable to modify packets on the wire or to block them can prevent peers to communicate regardless of the transport being used. But if even data injection has the same impact, it’d be much better to see if there’s a way to recover “sync” in the byte stream rather than expecting a new connection. TCP connections can be closed and re-open – I don’t think this is a big problem if IKE SA survives. The real problem is when IKE SA (and all Child SAs) is teared down as result of attack. This can happen when IKE message is corrupted or incorrectly parsed as a result of data injection attack. Currently the draft says that there is no need to retransmit the request message in case of TCP (with SHOULD NOT). We can add a note that implementations MAY retransmit messages to mitigate a possibility of data injection attacks. 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