IETF Logo Mail Archive

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

Christian Huitema <huitema@huitema.net> Tue, 31 May 2022 17:29 UTC

Return-Path: <huitema@huitema.net>
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 41F9EC15AAD8 for <ipsec@ietfa.amsl.com>; Tue, 31 May 2022 10:29:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.784
X-Spam-Level:
X-Spam-Status: No, score=-3.784 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, NICE_REPLY_A=-1.876, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01] autolearn=unavailable autolearn_force=no
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 VbiBt70AdyQt for <ipsec@ietfa.amsl.com>; Tue, 31 May 2022 10:29:51 -0700 (PDT)
Received: from mx43-out1.antispamcloud.com (mx43-out1.antispamcloud.com [138.201.61.189]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B4AC7C15AADA for <ipsec@ietf.org>; Tue, 31 May 2022 10:29:51 -0700 (PDT)
Received: from xse471.mail2web.com ([66.113.197.217] helo=xse.mail2web.com) by mx256.antispamcloud.com with esmtp (Exim 4.92) (envelope-from <huitema@huitema.net>) id 1nw5ge-0001Oj-Om for ipsec@ietf.org; Tue, 31 May 2022 19:29:48 +0200
Received: from xsmtp21.mail2web.com (unknown [10.100.68.60]) by xse.mail2web.com (Postfix) with ESMTPS id 4LCK5J0dFGzBJg for <ipsec@ietf.org>; Tue, 31 May 2022 10:29:08 -0700 (PDT)
Received: from [10.5.2.16] (helo=xmail06.myhosting.com) by xsmtp21.mail2web.com with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.92) (envelope-from <huitema@huitema.net>) id 1nw5g3-0002k3-Ur for ipsec@ietf.org; Tue, 31 May 2022 10:29:07 -0700
Received: (qmail 23560 invoked from network); 31 May 2022 17:29:03 -0000
Received: from unknown (HELO [192.168.1.106]) (Authenticated-user:_huitema@huitema.net@[172.58.43.86]) (envelope-sender <huitema@huitema.net>) by xmail06.myhosting.com (qmail-ldap-1.03) with ESMTPA for <touch@strayalpha.com>; 31 May 2022 17:29:00 -0000
Content-Type: multipart/alternative; boundary="------------ky6Q7pu4N0qVYswV0N206DwM"
Message-ID: <1243c5d9-58bd-642f-41dd-da2916b7e887@huitema.net>
Date: Tue, 31 May 2022 10:28:57 -0700
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.9.1
Content-Language: en-US
To: "touch@strayalpha.com" <touch@strayalpha.com>
Cc: Valery Smyslov <svan@elvis.ru>, 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> <9d37d517-b6ff-6965-40a2-67f5c2a3e476@huitema.net> <183D552C-A06A-4DD4-92B9-6FEF7B9DCED1@strayalpha.com>
From: Christian Huitema <huitema@huitema.net>
In-Reply-To: <183D552C-A06A-4DD4-92B9-6FEF7B9DCED1@strayalpha.com>
X-Originating-IP: 66.113.197.217
X-Spampanel-Domain: xsmtpout.mail2web.com
X-Spampanel-Username: 66.113.197.0/24
Authentication-Results: antispamcloud.com; auth=pass smtp.auth=66.113.197.0/24@xsmtpout.mail2web.com
X-Spampanel-Outgoing-Class: unsure
X-Spampanel-Outgoing-Evidence: Combined (0.14)
X-Recommended-Action: accept
X-Filter-ID: Pt3MvcO5N4iKaDQ5O6lkdGlMVN6RH8bjRMzItlySaT8IUmZZqJKbfxI271DZPtQrPUtbdvnXkggZ 3YnVId/Y5jcf0yeVQAvfjHznO7+bT5wNj0mh/9XNV5vOU8k7GpYKfYzfQXcfqmra3dmoHS4ygjDb 14kUlQe1c/6R4zUcUfxWuRWrkPihq53YqAd1ENNqBHtNXu1E6L4+KyOXc4QYanQOD0r6/AaHZiEt dTMtMlia0Lmg/jgHfCNZd+W+PXf6nDRKJHFvGlCEARldZytfpSue9TLOhN8AYRsvkjfngQC9MbDP yUBukWuaYaUwIAw1zDkBvlIN1pUDU5DU5DggD98cjIN3reG9z0FKKQ5m2Qpw7sOVVcM1Xk+Tdz6g /UMvfWqyN3veeFIMJz/vumcqAwMU9kjfE7EFo+kP5riIEUmxU01QhuxnshSbl6nxbLZ35/xY0uvo WBEOfzq3RG28wI7w4vcwqZanLHsZM8r4s5ZjlHoGly8aneNxj+pRyx6DAzHPcWsnfqGSaNoXhWPo OpFVgpT1b21uZVckGp0ccOZtuBWXiK6eoWgQZnNLL6SbpUc7peFeo3eDQNYbhOKhzzgqmaDn5SlD Y9mmtv6e91aWBLor1oCWetcUjeG94V2XFI2/q+CmJa7dgoCzutvTTPnVruzyKlLb7RhrqzoCfHn4 PEsQ/Q06o8s3Xk9KNcTPDRojSVizNl0ce/s7u0P9b7Oijoc3SCZfWp1RjkjWCw/vIUzTXkDAiiJi mGhLUFuS2lhaIetXfCg1JdAVrOwKfA3RoY4YTfoOnbkpzVpjNWxUoFIvD3sIcP1fhJPM6B/8hZVb l3FH7GHsCJjKlYcgZD57N39f4IjPDLvOPPXUJwyJ+dym1L8cD17Js0v4cp1M17WZotO7/6vUs6fn fC4r6zcKVNeVJ9BXyu9+ceCqThTYg2px1fSoqxQCCHnLMo/m9VKh99btUAanjnMCAH2co+fBoeG+ Hs0afhsY/5zhNYWRVYKU9W9tbmVXJBqdHHDmZEKhyNAv1N35kYWaEdgLurFV5oTvAcwA4rM3FkfW 8/1kE/e7sUnsVpINvARNxpFO
X-Report-Abuse-To: spam@quarantine11.antispamcloud.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipsec/Vbb2iCfdM4ceNSs60Pn9u4m48aE>
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 17:29:52 -0000

On 5/30/2022 8:20 AM, touch@strayalpha.com wrote:
>> On May 30, 2022, at 8:00 AM, Christian Huitema<huitema@huitema.net>  wrote:
>>
>> The bar against TCP injection attacks might be lower than you think. An attacker that sees the traffic can easily inject TCP packet with sequence number that fit in the flow control window and are ahead of what the actual sender produced.
> It might be useful to be more specific about the issue. Data injection attacks on TCP connections interfere with the IPsec stream in a similar way to IP or UDP fragment attacks on IP or UDP tunnels that use fragmentation.
>
> In all three cases, attackers can corrupt in-transit packets via IP packet attacks, which is not possible with an unfragmented IPsec message.
>
> In all three cases, this happens when an injection can overwrite a portion of an IPsec message.
>
> Data isn’t injected to the user, though.

The attacker could also inject packets that are just full of zeroes. 
This will insert a zero-valued "message length", causing the receiver to 
detect an error per section 4.2, "The receiver MUST treat these values 
as fatal errors and MUST close TCP connection." This attack is not 
possible with IPSEC over IP or UDP.

-- Christian Huitema

v2.23.0 | Report a Bug | By Email