IETF Logo Mail Archive

Re: [IPsec] Proposed method to achieve quantum resistant IKEv2

Michael Richardson <mcr+ietf@sandelman.ca> Thu, 28 September 2017 16:18 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 C626513421F for <ipsec@ietfa.amsl.com>; Thu, 28 Sep 2017 09:18:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 dzM0oZ7RgYH6 for <ipsec@ietfa.amsl.com>; Thu, 28 Sep 2017 09:18:28 -0700 (PDT)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C976B13300C for <ipsec@ietf.org>; Thu, 28 Sep 2017 09:18:25 -0700 (PDT)
Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 1D846200A3; Thu, 28 Sep 2017 12:23:29 -0400 (EDT)
Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 5AD7C806A8; Thu, 28 Sep 2017 12:18:24 -0400 (EDT)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: "Graham Bartlett (grbartle)" <grbartle@cisco.com>
cc: "ipsec@ietf.org" <ipsec@ietf.org>
In-Reply-To: <04B7D970-30B0-4AE8-BAF9-210746B56FFF@cisco.com>
References: <BBEB2C9C-9B96-4C6C-BB9B-4415F096FAE1@cisco.com> <041b01d30d21$8d33f230$a79bd690$@gmail.com> <1501968567726.89885@post-quantum.com> <22922.57101.227283.113155@fireball.acr.fi> <7769.1502301632@obiwan.sandelman.ca> <04B7D970-30B0-4AE8-BAF9-210746B56FFF@cisco.com>
X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.5.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-sha256"; protocol="application/pgp-signature"
Date: Thu, 28 Sep 2017 12:18:24 -0400
Message-ID: <14600.1506615504@obiwan.sandelman.ca>
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipsec/M_h42eFFL7nfUNqQu7Ghj6htmy8>
Subject: Re: [IPsec] Proposed method to achieve quantum resistant IKEv2
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.22
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: Thu, 28 Sep 2017 16:18:30 -0000

Graham Bartlett (grbartle) <grbartle@cisco.com> wrote:
    > Is the main rational for not having fragmentation in IKE_SA_INIT that
    > it could break the features of IKE that you list below?

1) we are currently working on IKE over TCP because we already know that
   IKE packets (and UDP encapsulated IPsec) are not get through.  Adding
   IP fragmentation to the process will just make it worse.

   Adding IP-level fragmentation to the process adds additional state to the
   gateway, often hidden to the IKE daemon itself.

   Adding IKE-level fragmentation to the process adds an additional place
   that DDoS attacks can hit.

   So, one would have to have some mechanism to know what would get through,
   and if to switch to TCP, etc. before even trying.

    > The reason I ask, we’re working on the current draft and looking to
    > implement optional fragmentation in the IKE_SA_INIT, but this would be
    > friendly to cookies, TCP encaps, NAT-T etc

2) I think it's not possible to do fragmentation on IKE_SA_INIT (and any
   level) without opening up gateways up for DDoS attacks.
   So, don't do it in IKE_SA_INIT in my opinion.

If you you want to do something, then it needs to be a new state between
IKE_SA_INIT and IKE_AUTH.

    > I agree.  All of the DoS (cookie, etc.) defense and switch to TCP, and
    > detection of NAT-T, etc. is in the IKE_SA_INIT, and so doing any kind of
    > framentation in IKE_SA_INIT is a bad idea.

--
Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works
 -= IPv6 IoT consulting =-

v2.23.0 | Report a Bug | By Email