IETF Logo Mail Archive

Re: [IPsec] Cost-efficient quantum-resistant DoS protection

Michael Richardson <mcr+ietf@sandelman.ca> Wed, 10 November 2021 14:41 UTC

Return-Path: <mcr+ietf@sandelman.ca>
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 A01EB3A0FFB for <ipsec@ietfa.amsl.com>; Wed, 10 Nov 2021 06:41:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 kcoiT77t2r6I for <ipsec@ietfa.amsl.com>; Wed, 10 Nov 2021 06:41:37 -0800 (PST)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0DD333A0D78 for <ipsec@ietf.org>; Wed, 10 Nov 2021 06:41:36 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 696011801F; Wed, 10 Nov 2021 09:43:31 -0500 (EST)
Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id mkpH_jY-DPxj; Wed, 10 Nov 2021 09:43:28 -0500 (EST)
Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 1D56B1801E; Wed, 10 Nov 2021 09:43:28 -0500 (EST)
Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id D8C884A3; Wed, 10 Nov 2021 09:41:28 -0500 (EST)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: Yoav Nir <ynir.ietf@gmail.com>, Valery Smyslov <smyslov.ietf@gmail.com>, ipsec@ietf.org
In-Reply-To: <969A6112-B9E4-4D29-9077-094E56AEBD1D@gmail.com>
References: <935923623769463b80caf7b64bfe430a@genua.de> <07a701d7c500$5c3fdcc0$14bf9640$@gmail.com> <994547d5af7a47b2b4819136af4b29fd@EX13D01ANC003.ant.amazon.com> <CANs=h-XU98=XVZ-1YNsp3_W1_Y3p5UgHnOgH-DPXgAQP7GuBmw@mail.gmail.com> <4d3d0181b23048bb9b57f1c97672c1ea@genua.de> <24956.19843.441109.862288@fireball.acr.fi> <27139.1635707097@localhost> <06fe01d7cf10$b966d6f0$2c3484d0$@gmail.com> <969A6112-B9E4-4D29-9077-094E56AEBD1D@gmail.com>
X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m<nPbLgmtKK-5dC@#:k
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha512"; protocol="application/pgp-signature"
Date: Wed, 10 Nov 2021 09:41:28 -0500
Message-ID: <17699.1636555288@localhost>
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipsec/4tyaokeTXaE-SWT6WsOMKH4S_mM>
Subject: Re: [IPsec] Cost-efficient quantum-resistant DoS protection
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: Wed, 10 Nov 2021 14:41:42 -0000

Yoav Nir <ynir.ietf@gmail.com> wrote:
    >>> Tero Kivinen <kivinen@iki.fi> wrote:
    >>>>> Even without surpassing the 64KB limit, this must be a concern.
    >>>>> IKEv2's cookie mechanism and puzzles try to increase the cost of the
    >>>>> attacker per each connection. Now, an attacker must still accept
    >>>>> these costs but can use one connection to trigger several key
    >>>>> exchanges, all significantly larger than what we had with DH, making
    >>>>> the trade-off way better for them compared to non-pqc IKEv2.
    >>>
    >>>> No it cannot. Attacker can use cookie only once, and will only get one
    >>>> exchange created by each cookie exchange, thus it needs to do puzzles
    >>>> and cookies again for every single attack packet it wants to send.
    >>>
    >>> I wonder if anyone has any stats on how often cookie challenge is used, how
    >>> often puzzles are invoked.
    >>
    >> I've implemented puzzles, but I'm not aware of any other implementation.
    >>
    >> What about cookies - in stress tests they are used very intensively.
    >> But I don't have any real life stats for them.
    >>
    >> Regards,
    >> Valery.

    > I also implemented puzzles. So that makes two of us.

Did you ever interop?

What is your criteria for enabling them?  Do you do this automatically, or is
it an operator configuation to demand them?

--
Michael Richardson <mcr+IETF@sandelman.ca>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide

v2.23.0 | Report a Bug | By Email