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

Tero Kivinen <kivinen@iki.fi> Tue, 11 January 2022 12:43 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 6C4913A084D for <ipsec@ietfa.amsl.com>; Tue, 11 Jan 2022 04:43:04 -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 (1024-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 xjqGAyGvf8iW for <ipsec@ietfa.amsl.com>; Tue, 11 Jan 2022 04:42:59 -0800 (PST)
Received: from meesny.iki.fi (meesny.iki.fi [195.140.195.201]) (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 9F2713A083B for <ipsec@ietf.org>; Tue, 11 Jan 2022 04:42:59 -0800 (PST)
Received: from fireball.acr.fi (fireball.acr.fi [83.145.195.1]) (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 meesny.iki.fi (Postfix) with ESMTPSA id CCD362004E; Tue, 11 Jan 2022 14:42:56 +0200 (EET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=iki.fi; s=meesny; t=1641904976; 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=Oek0FlUpe4Hy4UHZkT0xGUQZLo5oBqtsiy/3f2cVlpE=; b=RnMhC87xn0QWOYSseIuzhkE8jiPwrt1TnFmi16XVHX0pKS7wdg0b39SDI9Zss/WO0sXgym JRpDP3+KtHxitb+OptOvCIqjPNjGPRcqOSMYsFu9FMYmImWhah+DTiB8ArcXdZKI1IOfaH FJA186NU1kmZ+/RCR0Dy5ck9ERaoric=
Received: by fireball.acr.fi (Postfix, from userid 15204) id 85FD225C12E1; Tue, 11 Jan 2022 14:42:26 +0200 (EET)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Message-ID: <25053.31538.461435.873239@fireball.acr.fi>
Date: Tue, 11 Jan 2022 14:42:26 +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: <02f301d806e2$83b74030$8b25c090$@gmail.com>
References: <acea85f6-1c72-3b79-a7f6-d4c234b9e7c@nohats.ca> <026601d80627$55c05970$01410c50$@gmail.com> <25052.47710.148277.213677@fireball.acr.fi> <02f301d806e2$83b74030$8b25c090$@gmail.com>
X-Mailer: VM 8.2.0b under 26.3 (x86_64--netbsd)
X-Edit-Time: 3 min
X-Total-Time: 2 min
ARC-Authentication-Results: i=1; ORIGINATING; auth=pass smtp.auth=kivinen@iki.fi smtp.mailfrom=kivinen@iki.fi
ARC-Seal: i=1; s=meesny; d=iki.fi; t=1641904976; a=rsa-sha256; cv=none; b=LaSfleYZIWU9Lo6pGsBXJBQRNdlKLtm2/hbiCc6xL+ddicnaxPJCF8EHIiHqPeK5A82e7i eeHyxpy85xIIa1bmXm2WtHmy7phSNdNuanS1fg/ptcFhauoEJRJ+nGJa5XasurH9xeuY5u 59Oa+W5+O34gHlHArRPorqqA8UxryBA=
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=iki.fi; s=meesny; t=1641904976; 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=Oek0FlUpe4Hy4UHZkT0xGUQZLo5oBqtsiy/3f2cVlpE=; b=gbvP759rurZjkO1n7XJ/uEUPEZ4Z83uHSnm5tcmnr6EVIIKUWVcEek+FWSd/8STGXISaX0 hmfNgVClkob6jRija7t7Hh1CL7eu8N49XllkPyTbVszV6IeX9cVI6PmmAOwx/DiTFrqsJt t1j5q4Fgn05gxOxrGEHBnecEFEpWyUc=
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipsec/8xnAzDU162mzTR2RO3_DCoUGUSc>
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: Tue, 11 Jan 2022 12:43:05 -0000

Valery Smyslov writes:
> The latest text I proposed in reply to Paul's comments incorporates
> this strategy: 
> 
>   o  if the Responder chooses to send Cookie request (possibly along
>       with Puzzle request), then the TCP connection that the IKE_SA_INIT
>       request message was received over SHOULD be closed after the Responder sends its reply
>       and no repeated requests are received within some short period of time, so that the
>       Responder remains stateless. Note that if this TCP connection is
>       closed, the Responder MUST NOT include the Initiator's TCP port
>       into the Cookie calculation (*), since the Cookie will be returned
>       over a new TCP connection with a different port.
> 
> The text doesn't specify what "some short period of time" is.
> I don't think we should do it (it may be 10 sec as you suggested
> or 5 sec or 20 sec).
> 
> Is it OK? Or should we probably change SHOULD to MAY here?

I think it would be best to explain that valid clients usually return
back almost immediately, so responders should keep tcp connection open
for at least 10 seconds to receive the cookie responses, and after
that SHOULD close the connection after some timeout.

And perhaps add some words that depending on the puzzle difficulty
level the timers might be modified (i.e., if you give puzzle that will
require several minutes to solve, there is no point of waiting any
more than the few seconds, but if you expect initiator to solve the
puzzle in 5 seconds, then waiting 20 seconds is good thing).
-- 
kivinen@iki.fi