Re: [IPsec] Update and WGLC request [Re: I-D Action: draft-ietf-ipsecme-iptfs-02.txt]

Tero Kivinen <kivinen@iki.fi> Tue, 13 October 2020 21:01 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 098B23A08C1 for <ipsec@ietfa.amsl.com>; Tue, 13 Oct 2020 14:01:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.312
X-Spam-Level:
X-Spam-Status: No, score=-2.312 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.213, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 IHREVSAFMi_7 for <ipsec@ietfa.amsl.com>; Tue, 13 Oct 2020 14:00:57 -0700 (PDT)
Received: from lahtoruutu.iki.fi (lahtoruutu.iki.fi [185.185.170.37]) (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 E92AA3A08E3 for <ipsec@ietf.org>; Tue, 13 Oct 2020 14:00:54 -0700 (PDT)
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) by lahtoruutu.iki.fi (Postfix) with ESMTPSA id 32D531B00258; Wed, 14 Oct 2020 00:00:51 +0300 (EEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=iki.fi; s=lahtoruutu; t=1602622851; 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=5qTHhlqEqOCzS9A+gxY7jFp2eWilq1SM6GMeHUe5/UY=; b=qjC0eQ19IzOn/MeammJ8jsM5oYz/JBm+TKGsGJD8nFZd+s7WoC2z5yWt7JvbAnDGjYrJBD +F8Ic2qCdelZeO/Riop7W3NQHeLkKRhhkjycabOq00J1Iu94Pt8Uvum7B6NFAZPHXE5bDi ILUHO1Xk8EKo8mHFdVK6EcwN4a3NTQSdGYlFXSiDaBBAu8xPktwjXeco+Qp0fxX7E4t8zx yPcKYyBBOIZo5MoGJ90XDvVp5r3nG9tSbhgkM21bNE8j6bHneRVf5oxGfG0teM57wQJtoa unoE0wlQ79yYjrhack5vfVkCvisLOnigosfhRAdo+NIO0TGxOQiMfMUhSLofeQ==
Received: by fireball.acr.fi (Postfix, from userid 15204) id E57A725C123C; Wed, 14 Oct 2020 00:00:50 +0300 (EEST)
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Message-ID: <24454.5506.450515.501200@fireball.acr.fi>
Date: Wed, 14 Oct 2020 00:00:50 +0300
From: Tero Kivinen <kivinen@iki.fi>
To: Lou Berger <lberger@labn.net>
Cc: ipsec@ietf.org, Valery Smyslov <smyslov.ietf@gmail.com>, 'Christian Hopps' <chopps@chopps.org>
In-Reply-To: <0b080379-48c0-b4ac-c213-f8cdfefc514a@labn.net>
References: <160148315262.3746.2680691950315422865@ietfa.amsl.com> <27659521-C1B0-4F0E-A6CC-C6F4B8938FFE@chopps.org> <1ab401d6a131$ae279f30$0a76dd90$@gmail.com> <ab981da9-9735-b6a9-851d-736330748ce6@labn.net> <1b0b01d6a163$15ddcce0$419966a0$@gmail.com> <47f569bf-de43-3aa4-ad4f-5149b82b35f6@labn.net> <1b2401d6a16a$12110940$36331bc0$@gmail.com> <86bb0855-927d-defb-374c-d6f6be13eb50@labn.net> <24453.58544.114398.668064@fireball.acr.fi> <0b080379-48c0-b4ac-c213-f8cdfefc514a@labn.net>
X-Mailer: VM 8.2.0b under 26.3 (x86_64--netbsd)
X-Edit-Time: 10 min
X-Total-Time: 17 min
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=iki.fi; s=lahtoruutu; t=1602622851; 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=5qTHhlqEqOCzS9A+gxY7jFp2eWilq1SM6GMeHUe5/UY=; b=fiFVa3Bhb3MKhV3xW3/3RAOmMMbJiho8rHgoECvd6EixhghAuPts2Ocamws11kixc1T/X2 Fbqxhg4JO5HEci0K/MMsq6xRd46+s9v2pseD/3e7qJjCz1TVZADkocZO7uAhlfGYsc6IQW Szt5hH2YTP6F1oguqdEyGL/rNVUcshr+vg0LHx5wSwH7gVds1ZWo1xWPxkv2GeX6MT9ttI LgyldBgHT42ltGjBS04WiZRvzi9kJ7zU/Yz0M5YFdfscImRuatQZKsKPK1Bj6zNL0hZX0u CDag2Z+kojqHGZ0ipwZTs9lDGSkE3ViLsBCXom/6yraWq9oSMrrXbBMYBlE3XA==
ARC-Seal: i=1; s=lahtoruutu; d=iki.fi; t=1602622851; a=rsa-sha256; cv=none; b=lEglGmEwZ5l6foMVP6iw/63qTLMJcPsCfbwYNzrhRAK4QDmOLfOyU0DFfEQrBYK2XBMoTU CVXTzJ+gTCOkatv38EnAfA9Q+VLpTT5spQ2sPy+MkUYXjoGgQOH9atZrs1ZGaJFlhSTFaD ky+mEhZxoZw9X0PC5Lt5qYJ+UCWgkvUA5QkwH+nGwm3BFRNAYtbELE3T4v27hPqtLvcbKJ 6Y9IU2nFbvObBgSWo7mNs1NtF8Jl4K1C6XElKQ7hy/nn+l7j/EkyxiQ94ls+fHxvGTVU0g nZm3tuKblyJeestIMUKLTWtfaQrYLPMiYBOuUE1rttieCtRnx17w+K1JNUWhwQ==
ARC-Authentication-Results: i=1; ORIGINATING; auth=pass smtp.auth=kivinen smtp.mailfrom=kivinen@iki.fi
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipsec/O3lThG534uhVgTxLYzm5UpTyGeg>
Subject: Re: [IPsec] Update and WGLC request [Re: I-D Action: draft-ietf-ipsecme-iptfs-02.txt]
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, 13 Oct 2020 21:01:00 -0000

Lou Berger writes:
> > I have to admit that I have not read this draft, but noting, that most
> > of the cipher we use do require automated key management like IKE, I
> > just wonder are you really going to be limited to 3DES, or what
> > automated key management you are going to be using instead of IKE, and
> > how can you guarantee that it actually does its job correctly for
> > securing the key management over reboots etc.
> 
> I'm not advocating ike vs ike-less, just trying to have a comprehensive 
> solution.  One example ikeless usecase is captured by the YANG model in 
> last call: 
> https://tools.ietf.org/html/draft-ietf-i2nsf-sdn-ipsec-flow-protection-09

Which will require similar behavior from the IPsec part than IKE,
meaning you can't really change any parameters on the fly for existing
SAs. You can't change for example the ciphers of the existing SA, and
expect that to work.

My understanding for that is that ike-less will not change any
parameters of the existing SAs in the SAD, as that would definitely
break everything, but instead they will allocate new SPI, install new
SAD entry, and then remove the old SAD entry which causes the traffic
move to use the newly created SAD entry.

So for that use, there is no point of having a way to turn on IPTFS in
the middle of SA use time, exactly as there is no need to try to
change algorithms of the existing SAs. If you do that kind of things,
you just create new SA, and delete old one. I am not sure whether this
should be reflected on the draft-ietf-i2nsf-sdn-ipsec-flow-protection
somehow, i.e., indicating that most (if not all) of the items in the
sad-entry are write once type of things, i.e., you can write them
once, but you can't modify them once they have been set, and only way
to change them is to delete the whole sad-entry and recreate it with
new values (most likely doing it other way round, i.e., first create
new and delete old). 
-- 
kivinen@iki.fi