Re: [IPsec] Review of draft-ietf-ipsecme-rfc8229bis

Tero Kivinen <kivinen@iki.fi> Mon, 10 January 2022 22:59 UTC

Return-Path: <kivinen@iki.fi>
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 4297C3A14F8 for <ipsec@ietfa.amsl.com>; Mon, 10 Jan 2022 14:59:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.814
X-Spam-Level:
X-Spam-Status: No, score=-2.814 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, NICE_REPLY_A=-0.714, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=iki.fi
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KIM64m0iYGp7 for <ipsec@ietfa.amsl.com>; Mon, 10 Jan 2022 14:59:47 -0800 (PST)
Received: from lahtoruutu.iki.fi (lahtoruutu.iki.fi [185.185.170.37]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 71C3D3A14F5 for <ipsec@ietf.org>; Mon, 10 Jan 2022 14:59:47 -0800 (PST)
Received: from fireball.acr.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) (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) (Authenticated sender: kivinen@iki.fi) by lahtoruutu.iki.fi (Postfix) with ESMTPSA id 525361B0024D; Tue, 11 Jan 2022 00:59:43 +0200 (EET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=iki.fi; s=lahtoruutu; t=1641855583; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=/l2P/JjOB7aL4FtMtNRsN8Vip6VDWJGAewopuYJ9j3k=; b=WG2cFuDl/tWCEyRii6mIVc4KgKYdoKcC/4nu7uU95ja+BoF6WOTzevBDR6x/gDo5BOpQUE Vn29Ji6x4newAlIycQNmVjmQRSbkfk0r6GWcfeKPRh112yd45mBRQeOx5heiz4vGkV7dK0 vOS014IQpKuGvQ7dTWD+SpzbTYSFdfJLkw76+3eEw3ceucE5YY2KEYlMJxBHebZBF2zsiD 8WKmdntf8gKz0D4ZOXYIdl6XKAph8obNvEDdHiDB/B+6tvQYbU9McwrN0fp2C6qJ8a5VE0 pv68SkdvtypQmcUYkHUzd4qtDAsLsZyBVH09AF2l4vCDhSXGZOpkhfbVzRDfEQ==
Received: by fireball.acr.fi (Postfix, from userid 15204) id 31D2B25C12E1; Tue, 11 Jan 2022 00:59:42 +0200 (EET)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Message-ID: <25052.47710.148277.213677@fireball.acr.fi>
Date: Tue, 11 Jan 2022 00:59:42 +0200
From: Tero Kivinen <kivinen@iki.fi>
To: Valery Smyslov <smyslov.ietf@gmail.com>
Cc: 'Paul Wouters' <paul.wouters=40aiven.io@dmarc.ietf.org>, ipsec@ietf.org, tpauly@apple.com
In-Reply-To: <026601d80627$55c05970$01410c50$@gmail.com>
References: <acea85f6-1c72-3b79-a7f6-d4c234b9e7c@nohats.ca> <026601d80627$55c05970$01410c50$@gmail.com>
X-Mailer: VM 8.2.0b under 26.3 (x86_64--netbsd)
X-Edit-Time: 7 min
X-Total-Time: 8 min
ARC-Seal: i=1; s=lahtoruutu; d=iki.fi; t=1641855583; a=rsa-sha256; cv=none; b=YYNf48rhOs01K0VlpaMA+KLxA5awHcwf+Kaihm5Y1a0MQmFtaoj2yNHuLjSjeLz9gafnGT u3xqkytHa4C0ITvKMdK5RFlqnbPnEOBUDsHfZXCNVwNg7ejJAERW44YVcP1wzDY9mmdOIW yWrkDKeDARQ7jbgP0q+UqAibIO/3veU2oLiM+kfgclDW3Yf08HB/ErUEkkTr1ujWHIvC+p JFZdWu8rtMjkqwv/dRxz3Ucg5kW6JjZoSZY/adKjfvtwnz4xsjv2jDREZqfXP+b/JcAii5 rwbpRT0edzPPx1weGBu+UOZmqDFcDWDEa1P3BKKHq3mmdNNlqVvKXxVFUKAeEA==
ARC-Authentication-Results: i=1; ORIGINATING; auth=pass smtp.auth=kivinen@iki.fi smtp.mailfrom=kivinen@iki.fi
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=iki.fi; s=lahtoruutu; t=1641855583; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=/l2P/JjOB7aL4FtMtNRsN8Vip6VDWJGAewopuYJ9j3k=; b=O+UX8EMYmuRqJbPRMJYKJ2KbS1DOwMH/8RYMX5EquZXOR2KPGK1oWI5MjM/oRqLV8ifGxp WQfUMGgSf3qiBCDXqVAVufMdAkyQfkUNA4ToXlCtRT0D53361Qcb06LABZVO92z5T4ydbq Cvxwuf19VTYIVujI0d9dNxFIhcJ6iv76Fu+g4Dkx11UG85361O06A7aSVDB6BNYDTvyzrG vPFfCz5Na4JGq6RIXtiniunYSNlTFmhBh951643pFypZ3T29f9DhcLcqCRbTQ9O4o5JS9T /Du5BuUK0LHaboNFn/KcbRlFMbnKo/8muq0PWPn7XPKrW/TvBiPA8aG1vt5+vg==
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipsec/d5Fwv69V_FQvXtji31rvgBHPDhE>
Subject: Re: [IPsec] Review of draft-ietf-ipsecme-rfc8229bis
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.29
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: Mon, 10 Jan 2022 22:59:53 -0000

Valery Smyslov writes:
> The responder does use an existing TCP connection to reply, but once
> it replies with cookie request, it should close this connection. If
> it keeps this connection, then it keeps TCP state until the client
> resends IKE_SA_INIT request (if ever) and thus thwarts the idea of
> being stateless.
> 
> This is probably not so important for cookies, because the client
> has already proved during TCP handshake, that its IP is a real IP
> address, but it is more important in case of puzzles. But in both
> cases I think that keeping responder stateless is a good idea.

I think it is important not to close the TCP immediately after the
sending out cookie request, as proper initiator will most likely
respond it in one round trip, thus forcing initiator to restart TCP
handshake wastes lots of resources. On the other hand it might be
useful for puzzles, depending on the expected solving time.

Note, that when the responder closes the TCP connection the connection
goes to the TCP TIME_WAIT state, where it will still waste resources
for a minute or so, thus closing TCP session will NOT free resources
immediately, thus closing TCP session too quickly will waste much more
resources than keeping it open for 10 seconds or so.

If responder keeps the TCP session open for 10 seconds, and initiator
comes back during that time with cookie or solved puzzle it can save 6
packets between the peers, and one set of buffers used for TCP
send/receive windows. If initiator does not come back after 10 second
wait, then it only extends the resource use from 60 seconds to 70
seconds or so...
-- 
kivinen@iki.fi