From nobody Sun Nov 1 12:40:44 2020 Return-Path: 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 843183A0E82; Sun, 1 Nov 2020 12:40:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 KcMJNdfqMd60; Sun, 1 Nov 2020 12:40:36 -0800 (PST) Received: from mail-ua1-x92c.google.com (mail-ua1-x92c.google.com [IPv6:2607:f8b0:4864:20::92c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3B0B33A0E81; Sun, 1 Nov 2020 12:40:36 -0800 (PST) Received: by mail-ua1-x92c.google.com with SMTP id q20so3366780uar.7; Sun, 01 Nov 2020 12:40:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=b3JfN9GxneGFVjQZWVYq3/OgYnXhqc6VmSx5ec/GFf8=; b=b6jKrfEHS7eS1Uvjp1DWARgwJ55zlqFPedXL7W0MKhfq8gQfzzy8hJt06EMtycMHqr wo+IEY7LAixdI6j3V5KC2xbPivD0153jAluQl1Uf+atJbetfeqhjcjPOKuRM94RVv24U rXL1zI7QxCfCETShEeQ//ZYMjRQ5VC6t3uEoMM0uxwET1B1d3ZctPqZIi721UlqoKaIS GUxpwdXoWA7H1foRSBszhg2Vv+uD6PeB+b4pg5UVgz/WBc2wOjoKmKzS8goIykp73zyw UuteqbvoZX/bo31Krzz2RTN3+Fg32ksE6tk2C9ftEyPmZQCRJC8cb48k2VYoVZ0KglQC Gthg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=b3JfN9GxneGFVjQZWVYq3/OgYnXhqc6VmSx5ec/GFf8=; b=LhBsmDpaWa6dXCowT4hqA8K13Tifk8oTtWl7eowHz5YihZaikIvVBSmUtVySa0gVts USBavlcmtNmpSvkoReXfcAy57qPqIOt5k7LEedkGH4w2fNYO/ubESeNepoX3iY+8D7e+ OMMVg7q7x8DearBpGY8Zz/z7MCMXV+6+oLeE5u6cwXxEmg1Z9rZydr+6wJhETStdEWMA +iNmWoSoqoJhLIkfum34nmpbtunOIOYlzcnuXOmGgfjo084norFMn6QDbdVmu/QHg1Yn /spTinx02qcF3U55KQ12lRETDevok9PRM9kFWNLS2ExGtnN415dnLN1laUpVOxGhqRGW hoEg== X-Gm-Message-State: AOAM531CLoj6ivz4Nqb3VQ9n71UUbUVlqFb/aY/0dHA6c7h5mesz/Kj4 BDBX1Vo+fF07bp4AoM+q72Q6v53ON/QUA704Kgo= X-Google-Smtp-Source: ABdhPJyBE/MrRXEvWk1ZrRDH8bRkqOtHsT9Yl0bp8JLALb18Mjp26lsSxda+hKQaepIHQEW0NpobW57ulKufbxWDjtA= X-Received: by 2002:ab0:48ab:: with SMTP id x40mr6380938uac.68.1604263235280; Sun, 01 Nov 2020 12:40:35 -0800 (PST) MIME-Version: 1.0 References: <060501d5a9da$b8552490$28ff6db0$@gmail.com> <24476.26850.591422.567867@fireball.acr.fi> In-Reply-To: <24476.26850.591422.567867@fireball.acr.fi> From: Daniel Migault Date: Sun, 1 Nov 2020 15:40:24 -0500 Message-ID: To: Tero Kivinen Cc: Valery Smyslov , IPsecME WG , lwip@ietf.org, Tobias Guggemos Content-Type: multipart/alternative; boundary="00000000000043e49005b311a4a1" Archived-At: Subject: Re: [IPsec] [Lwip] Review of draft-ietf-lwig-minimal-esp-00 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Nov 2020 20:40:38 -0000 --00000000000043e49005b311a4a1 Content-Type: text/plain; charset="UTF-8" Hi Tero, Thanks for the comments. Please find below how I updated the text on my local copy and let me know if that addresses your concerns. Yours, Daniel On Fri, Oct 30, 2020 at 3:26 PM Tero Kivinen wrote: > Daniel Migault writes: > > value SN needs to be considered instead. Note that the limit of > > messages being sent is primary determined by the security associated > > to the key rather than the SN. The security of the key used to > > encrypt decreases with the each message being sent and a node MUST > > ensure the limit is not reached - even though the SN would permit it. > > In a constrained environment, it is likely that the implementation of > a > > rekey mechanism is preferred over the use of ESN. > > No. The security of the key does not decrease, but the ability for the > attacker to attack the key might incrase, and the value of attacking > that one key also increases when more data is encrypted with it. Also > with short block length algorithms there were stricter limits of data > that can be encrypted with one key. > Thanks. Here is the text I propose. The security of all data protected under a given key decreases slightly with each message and a node MUST ensure the limit is not reached - even though the SN would permit it. > -- > kivinen@iki.fi > -- Daniel Migault Ericsson --00000000000043e49005b311a4a1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Tero,=C2=A0

Thanks for th= e comments. Please find=C2=A0below how I updated the text on my local copy = and let me know if that addresses your concerns.=C2=A0

=
Yours,=C2=A0
Daniel

On Fri, Oct 30, 2020 at 3:26 PM Tero Kivinen <= ;kivinen@iki.fi> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft:1px solid rgb(204,204,204);padding-left:1ex">Daniel Migault writes:
> =C2=A0 =C2=A0value SN needs to be considered instead.=C2=A0 Note that = the limit of
> =C2=A0 =C2=A0messages being sent is primary determined by the security= associated
> =C2=A0 =C2=A0to the key rather than the SN.=C2=A0 The security of the = key used to
> =C2=A0 =C2=A0encrypt decreases with the each message being sent and a = node MUST
> =C2=A0 =C2=A0ensure the limit is not reached - even though the SN woul= d permit it.
> =C2=A0 =C2=A0In a constrained environment, it is likely that the imple= mentation of a
> =C2=A0 =C2=A0rekey mechanism is preferred over the use of ESN.

No. The security of the key does not decrease, but the ability for the
attacker to attack the key might incrase, and the value of attacking
that one key also increases when more data is encrypted with it. Also
with short block length algorithms there were stricter limits of data
that can be encrypted with one key.
<mglt>
=
Thanks. Here is the text I propose.=C2=A0
The security of al= l data protected under a given key decreases slightly with each message and= a node MUST ensure the limit is not reached - even though the SN would per= mit it.=C2=A0
</mglt>=C2=A0
--
kivinen@iki.fi


--
Daniel Migault
Ericsson
--00000000000043e49005b311a4a1-- From nobody Sun Nov 1 12:41:40 2020 Return-Path: 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 7E8FE3A0E84; Sun, 1 Nov 2020 12:41:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 ml3r0ZpfVy83; Sun, 1 Nov 2020 12:41:35 -0800 (PST) Received: from mail-vs1-xe34.google.com (mail-vs1-xe34.google.com [IPv6:2607:f8b0:4864:20::e34]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DB75B3A0E81; Sun, 1 Nov 2020 12:41:34 -0800 (PST) Received: by mail-vs1-xe34.google.com with SMTP id b4so6391822vsd.4; Sun, 01 Nov 2020 12:41:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=RNSSlcnu5Ch1ViUKBT17OZlENvR65puCirbYRj85sBQ=; b=jJczrSTcM07BnrahwE86iHNtRIBRXRcBwtV5x59umhXR0ia+9IOV86Ycq2zC/W2q2A 7++z+vPs6o6xSwhoYtfTi6YU4pG0gQgBey4BA9Tasb0A/fIvBFb2B8QiGk0R7HBmDdHl 5d8MX6u6y/SedhbyKezI4DV+iOIQ6v0huN1IAEoUJVMCr+rzv71W0SeYqiarKmzSrWUJ 1wWfgZte4qwOs2378+tAYwtqoX0yE7JaBcZAoo3KCK32XZMQo11FD6RzN7y1KvcbXv36 EH8wZIZElSjnKwplG7cOSGS0b/kBKqHm4wozLz2opna+dfTkHkdpQudpFuMqnWO7H17K /HLQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=RNSSlcnu5Ch1ViUKBT17OZlENvR65puCirbYRj85sBQ=; b=t/Bb7YsIZBHiPIt/w3qRTsQ+ZqhZIs9gtXam2blB4vrGq4PuoH5O5+khGQvsM42pRk cqUAWa5kOF78YICyhPIjVhRQtDptKRwEgWwtPKZKjS5mOgzi7VPLnufMCVW4xdWrXzuC 81XLGsnNWtJKKTWXYgti6c4sHuakY8hOD9ZqEHZVq8qajVdi0Dj4CAodmyilZFkC+pE6 tIaLC2uGgWDhCqEICSAwXoUZC4Yj6+nSqr5SMXTiHDOXNaCQ5VVavsS/5FEtbi2NW7Uy hJtfADnnw78GHCSZa+Tqw3+r1cHDzEIikBMOn0iJeyEctKlJ+E7jnCM1VWrTdUWs8Da+ bLVg== X-Gm-Message-State: AOAM531zICIFiLX8wu18iUmG3eXSGVRpEVJpYYaFu9Vyk/b3EZBGcsSS BNBALPjY0b4Cqpn+sQavFmmU0r4Jdz+rjOwLpyo= X-Google-Smtp-Source: ABdhPJy6vP3+s8Vm2ofjVB2ztH4ORoBlMld3hDrENBYsKe8OJC9quyLC+IcwTtpfGnVtwnYng0VOE/8+K7JpD3O/U4A= X-Received: by 2002:a05:6102:309a:: with SMTP id l26mr243186vsb.4.1604263293988; Sun, 01 Nov 2020 12:41:33 -0800 (PST) MIME-Version: 1.0 References: <24476.26053.16496.150596@fireball.acr.fi> In-Reply-To: <24476.26053.16496.150596@fireball.acr.fi> From: Daniel Migault Date: Sun, 1 Nov 2020 15:41:23 -0500 Message-ID: To: Tero Kivinen Cc: "Scott Fluhrer (sfluhrer)" , "ipsec@ietf.org" , lwip@ietf.org Content-Type: multipart/alternative; boundary="000000000000c3b2bb05b311a7f4" Archived-At: Subject: Re: [IPsec] Comments on draft-ietf-lwig-minimal-esp-00 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Nov 2020 20:41:37 -0000 --000000000000c3b2bb05b311a7f4 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Tero, Thanks for the comments. Please find below how I updated the text on my local copy and let me know if that addresses your concerns. Yours, Daniel On Fri, Oct 30, 2020 at 3:13 PM Tero Kivinen wrote: > Daniel Migault writes: > > The security consideration has been updated as follows: > > > > """ > > The security of a communication provided by ESP is closely related to > > the security associated to the management of that key. This usually > > include mechanisms to prevent a nonce to repeat for example. When a > > node is provisioned with a session key that is used across reboot, > > the implementer MUST ensure that the mechanisms put in place remain > > valid across reboot as well. > > > > It is RECOMMENDED to use ESP in conjunction of key management > > protocols such as for example IKEv2 [RFC7296] or minimal IKEv2 > > [RFC7815]. Such mechanisms are responsible to negotiate fresh > > session keys as well as prevent a session key being use beyond its > > life time. When such mechanisms cannot be implemented and the > > session key is, for example, provisioned, the nodes SHOULD ensure > > that keys are not used beyond their life time and that the > > appropriated use of the key remains across reboots. > > Why the last sentence has SHOULD and not MUST? If device reuses the > key across reboots and the algorithm is counter mode based, this will > cause serious security issues. Also same thing happens if the counters > are allowed to roll over. I would suggest changing that "MUST ensure". > Correct. it must be a MUST. I also explicitly added that condition on nonce and counter needs to remain valid. The new text is as follows: When such mechanisms cannot be implemented and the session key is, for example, provisioned, the nodes MUST ensure that keys are not used beyond their life time and that the appropriate use of the key remains across reboots - e.g. conditions on counters and nonces remains valid. > > > The use of fix SPI MUST NOT be considered as a way to avoid strong > random > > generators. Such generator will be required in order to provide > strong > > cryptographic protection=E2=80=9D; actually, if the IPsec implement= ation > doesn=E2=80=99t > > actually generate its own keys (that is, it relies on an external > service > > to provide them), and the transform itself doesn=E2=80=99t require = random > data > > (CBC can be implemented securely without one), then the IPsec > > implementation doesn=E2=80=99t actually need an CSPRNG. > > > > > > The current text presented it in another way. The former text seems to > explain > > that random was necessary for the generation of SPI. The current text > has been > > updated to explain that we may have nodes without random generators. > > > > I am wondering how the IV is generated with CBC without random > generator. > > Normally you use just counter, and encrypt it with secret key. The IV > in CBC does not be random, it needs to be unpredictable and it should > not be direct counter or other source with low Hamming distance > between successive IVs. > > Actually the problem with old way of CBC mode was that the IV was > random, but predictable as implementations used last block of previous > packet. If attacker does not know the key you are using to encrypt the > counter to generate IVs, the IVs will be unpredictable and random. > Thanks for the information. What I was wondering then, is for which reason can't we consider this as a random generator - of a limited lifetime. > -- > kivinen@iki.fi > --=20 Daniel Migault Ericsson --000000000000c3b2bb05b311a7f4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Tero,=C2=A0

<= div>Thanks for the comments. Please find=C2=A0below how I updated the text = on my local copy and let me know if that addresses your concerns.=C2=A0

Yours,=C2=A0
Daniel

On Fri, Oct 30, 2020 at 3= :13 PM Tero Kivinen <kivinen@iki.fi> wrote:
Daniel Migault writes:
> The security consideration has been updated as follows:
>
> """
> =C2=A0 The security of a communication provided by ESP is closely rela= ted to
> =C2=A0 =C2=A0the security associated to the management of that key.=C2= =A0 This usually
> =C2=A0 =C2=A0include mechanisms to prevent a nonce to repeat for examp= le.=C2=A0 When a
> =C2=A0 =C2=A0node is provisioned with a session key that is used acros= s reboot,
> =C2=A0 =C2=A0the implementer MUST ensure that the mechanisms put in pl= ace remain
> =C2=A0 =C2=A0valid across reboot as well.
>
> =C2=A0 =C2=A0It is RECOMMENDED to use ESP in conjunction of key manage= ment
> =C2=A0 =C2=A0protocols such as for example IKEv2 [RFC7296] or minimal = IKEv2
> =C2=A0 =C2=A0[RFC7815].=C2=A0 Such mechanisms are responsible to negot= iate fresh
> =C2=A0 =C2=A0session keys as well as prevent a session key being use b= eyond its
> =C2=A0 =C2=A0life time.=C2=A0 When such mechanisms cannot be implement= ed and the
> =C2=A0 =C2=A0session key is, for example, provisioned, the nodes SHOUL= D ensure
> =C2=A0 =C2=A0that keys are not used beyond their life time and that th= e
> =C2=A0 =C2=A0appropriated use of the key remains across reboots.

Why the last sentence has SHOULD and not MUST? If device reuses the
key across reboots and the algorithm is counter mode based, this will
cause serious security issues. Also same thing happens if the counters
are allowed to roll over. I would suggest changing that "MUST ensure&q= uot;.
<mglt>
Correct. it must be a=C2= =A0 MUST. I also explicitly added that condition on nonce and counter needs= to remain valid. The new text is as follows:

When= such mechanisms cannot be implemented and the session key is, for example,= provisioned, the nodes MUST ensure that keys are not used beyond their lif= e time and that the appropriate use of the key remains across reboots - e.g= . conditions on counters and nonces remains valid.

=
</mglt>=C2=A0

>=C2=A0 =C2=A0 =C2=A0The use of fix SPI MUST NOT be considered as a way = to avoid strong random
>=C2=A0 =C2=A0 =C2=A0generators.=C2=A0 Such generator will be required i= n order to provide strong
>=C2=A0 =C2=A0 =C2=A0cryptographic protection=E2=80=9D; actually, if the= IPsec implementation doesn=E2=80=99t
>=C2=A0 =C2=A0 =C2=A0actually generate its own keys (that is, it relies = on an external service
>=C2=A0 =C2=A0 =C2=A0to provide them), and the transform itself doesn=E2= =80=99t require random data
>=C2=A0 =C2=A0 =C2=A0(CBC can be implemented securely without one), then= the IPsec
>=C2=A0 =C2=A0 =C2=A0implementation doesn=E2=80=99t actually need an CSP= RNG.
>=C2=A0 =C2=A0
> <mglt>
> The current text presented it in another way. The former text seems to= explain
> that random was necessary for the generation of SPI. The current text = has been
> updated to explain that we may have nodes without random generators.= =C2=A0
>
> I am wondering how the IV is generated with CBC without random generat= or.=C2=A0

Normally you use just counter, and encrypt it with secret key. The IV
in CBC does not be random, it needs to be unpredictable and it should
not be direct counter or other source with low Hamming distance
between successive IVs.

Actually the problem with old way of CBC mode was that the IV was
random, but predictable as implementations used last block of previous
packet. If attacker does not know the key you are using to encrypt the
counter to generate IVs, the IVs will be unpredictable and random.
<mglt>
Thanks for the information. What I was = wondering then, is for which reason can't we consider this as a random = generator - of a limited lifetime.=C2=A0
</mglt>=C2=A0
--
kivinen@iki.fi


--
Daniel Migault
Ericsson
--000000000000c3b2bb05b311a7f4-- From nobody Mon Nov 2 06:00:25 2020 Return-Path: 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 D496F3A104D; Mon, 2 Nov 2020 06:00:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.346 X-Spam-Level: X-Spam-Status: No, score=-2.346 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.247, 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 KKgDmJwe8Y54; Mon, 2 Nov 2020 06:00:21 -0800 (PST) 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 739EF3A1043; Mon, 2 Nov 2020 06:00:20 -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) by lahtoruutu.iki.fi (Postfix) with ESMTPSA id 625871B00436; Mon, 2 Nov 2020 16:00:16 +0200 (EET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=iki.fi; s=lahtoruutu; t=1604325616; 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=Lq/Tef95HcyYd4M0uRjuEfNR8qm4oEbq3byN1NiTE7Q=; b=t/zuzX7lMOWQO1+JQtsd0uncExwkLoDf5KWw3K94LfzyEW57OzYTWvcuq5faF/IfWqzpSL BT1juCeBMYhQp5fhgPcT0es5zbIDsGOC6OuJN49HQOSQBWIW1RTeudZ6et7J82T4gQJfXS 5R2LkI9Pr4vctXIQ076pq2YtLa10J13J3O95DJCztjTYEHvVtxu+F8YTUCCuy2xCGfnLkC iHWUO7tox70WZVAm2C/skFoAmV8bqyni+nESUYvhbyzjo8GO8NWkWvbARor+reth4roAVH b060XUntfZ81DbHKSoSwQbb14PcNF/VY/PP+NViOyG2aFkOxiSAcAbgOGpPOxQ== Received: by fireball.acr.fi (Postfix, from userid 15204) id 087E925C11F3; Mon, 2 Nov 2020 16:00:16 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Message-ID: <24480.4335.981375.920639@fireball.acr.fi> Date: Mon, 2 Nov 2020 16:00:15 +0200 From: Tero Kivinen To: Daniel Migault Cc: "Scott Fluhrer \(sfluhrer\)" , "ipsec\@ietf.org" , lwip@ietf.org In-Reply-To: References: <24476.26053.16496.150596@fireball.acr.fi> X-Mailer: VM 8.2.0b under 26.3 (x86_64--netbsd) X-Edit-Time: 4 min X-Total-Time: 3 min ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=iki.fi; s=lahtoruutu; t=1604325616; 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=Lq/Tef95HcyYd4M0uRjuEfNR8qm4oEbq3byN1NiTE7Q=; b=YoOqaY3ZAm8J+T3TcLxUL9vVZZsfQ8Nru2eWNWQ2DsRtmNNzLM0FSISq8BIoOrhY4eP95J XZ5OFz/SDqITDLzltbnBrQZ+AGGKEVNzQDQoz1wD5dZcJ/SH5QpKTogKYUKveTO4Pjrzr7 xY6Ah2/Af0KtSGB9fWSWGSqvpl5TkOZkVzY3hW7HDYbAuoR5O3N98PIKkGk3kMXvagcKtR RvAFwxapvm24ZD3wSYc++es0Au0pTs+iojm3rehtY5NPAkBVJcVpVVDsmCwmEHLlAhKmhZ BG74sAm+9oMaZaVelK2+MV177THOUZjaiI7LPmBgpvxwpi0KyvKzDro+2WkdsQ== ARC-Authentication-Results: i=1; ORIGINATING; auth=pass smtp.auth=kivinen smtp.mailfrom=kivinen@iki.fi ARC-Seal: i=1; s=lahtoruutu; d=iki.fi; t=1604325616; a=rsa-sha256; cv=none; b=lyJ7lYdoQQU1RnOlAgIlSZ6oVRAknUVMe3H11ebZKkOAguXm0csiqUXvvE1qMWd3HWmUsR YG0eTBTqgi0TNdS73li6QWXZhgczQ08sUxQNWlfGW3cu+9/I94b987+NBHn8BMiLQmDkq/ VZNsGtYZQhdyXEdt/jt4yeOFKdxWvfb9snQuPeAB9QYwdsViHT9HhXdZiQNrHe3rbJiZP+ gl+2E/7SgsUzF/e7PCw6muXVEnmFolYwB29GtHvdZPvQppYY/g09kZR+GjiM7kin8TRsCs 2V0iCVLM71TAgLwKoaJy2VqP5P6DloNiMeL8Ty2fOypiPgFSXTO5O2SO54duiA== Archived-At: Subject: Re: [IPsec] Comments on draft-ietf-lwig-minimal-esp-00 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Nov 2020 14:00:24 -0000 Daniel Migault writes: > > Correct. it must be a=A0 MUST. I also explicitly added that condition= on nonce > and counter needs to remain valid. The new text is as follows: >=20 > When such mechanisms cannot be implemented and the session key is, fo= r > example, provisioned, the nodes MUST ensure that keys are not used be= yond > their life time and that the appropriate use of the key remains acros= s reboots > - e.g. conditions on counters and nonces remains valid. >=20 > =A0 Looks ok.=20 > Normally you use just counter, and encrypt it with secret key. Th= e IV > in CBC does not be random, it needs to be unpredictable and it sh= ould > not be direct counter or other source with low Hamming distance > between successive IVs. > =20 > Actually the problem with old way of CBC mode was that the IV was= > random, but predictable as implementations used last block of pre= vious > packet. If attacker does not know the key you are using to encryp= t the > counter to generate IVs, the IVs will be unpredictable and random= =2E >=20 > > Thanks for the information. What I was wondering then, is for which r= eason > can't we consider this as a random generator - of a limited lifetime.= =A0 > =A0 That method is very common piece used when you are making random number generator. It is for example part of the NIST AES Counter mode based generator, but to properly make random number generator out of that need bit more stuff around it. For example you need to make sure it is rekeyed before the counter rolls over, and of course it is only as secure as the random secret key you are using to seed it etc. See NIST SP 800-90A REv 1 [1] CTR=5FDRBG description for more information. [1] https://csrc.nist.gov/publications/detail/sp/800-90a/rev-1/final --=20 kivinen@iki.fi From nobody Mon Nov 2 06:22:29 2020 Return-Path: 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 AE92C3A0E27; Mon, 2 Nov 2020 06:22:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 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, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca 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 9jDNF_RkVmBF; Mon, 2 Nov 2020 06:22:18 -0800 (PST) Received: from mx.nohats.ca (mx.nohats.ca [IPv6:2a03:6000:1004:1::68]) (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 F0D963A0E55; Mon, 2 Nov 2020 06:22:17 -0800 (PST) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 4CPw931yjYzFK8; Mon, 2 Nov 2020 15:22:15 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1604326935; bh=SHmcHK+HLa/o/YCrPvFC/NHzBbfL0M9r4i0PRUMncPc=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=rvfQAAzfYKUzeUdQy2yBCTf3RxQhMlNarygNg+qBYrRpSNyrV7ATTO5C09Ovjb3er Arou3nhQntITchrepbEYU4nwtDzq2zu61tM+TO3KJqL+/p3MD2u16j3A+LP/4fmnbk FguvAHdBF6KoZgHyzQqYz9XBoqYGqSqZIMOB9sPA= X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id luImvGvWKGEH; Mon, 2 Nov 2020 15:22:13 +0100 (CET) Received: from bofh.nohats.ca (bofh.nohats.ca [193.110.157.194]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Mon, 2 Nov 2020 15:22:13 +0100 (CET) Received: by bofh.nohats.ca (Postfix, from userid 1000) id 8EFD760298AC; Mon, 2 Nov 2020 09:22:12 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 8677A350721; Mon, 2 Nov 2020 09:22:12 -0500 (EST) Date: Mon, 2 Nov 2020 09:22:12 -0500 (EST) From: Paul Wouters To: Yoav Nir cc: tom petch , Roman Danyliw , Fernando Pereniguez-Garcia , "i2nsf@ietf.org" , Gabriel Lopez , Tero Kivinen , "ipsec@ietf.org" , "last-call@ietf.org" , Rafa Marin-Lopez In-Reply-To: <10736BF3-4833-4129-A3E2-B680696A80B5@gmail.com> Message-ID: References: <160337357077.29083.9236626834026808055@ietfa.amsl.com> <5F9815D1.9010303@btconnect.com> <5F99B221.3040504@btconnect.com> <56155C91-BFE8-4BA9-A55C-46B12E59CD94@um.es> <5F9AEFD3.90903@btconnect.com> <059aaae84a354411ad1023afa2a837ba@cert.org> <5F9BF578.6000101@btconnect.com> <834a668ac559460a9f356bbb6c16b8fd@cert.org> <24476.38596.868667.906930@fireball.acr.fi> <5F9D62C0.5030908@btconnect.com> <10736BF3-4833-4129-A3E2-B680696A80B5@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8BIT Archived-At: Subject: Re: [IPsec] [I2nsf] [Last-Call] New Version Notification for draft-ietf-i2nsf-sdn-ipsec-flow-protection-11.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Nov 2020 14:22:20 -0000 On Sat, 31 Oct 2020, Yoav Nir wrote: >> Thanks for getting back to me. What is missing from the IANA registry is the guidance as to the status of the algorithm, how highly it is recommended or not. This I-D tells people to go to RFC8247 and the IANA Registry for advice; RFC8247 gives that advice; the IANA web page does not. > > It’s possible to add a column in the IANA registry, but it is not possible to capture the information from 8247 in such a table. > > RFC 8247 has “MAY” and “SHOULD+” labels, but it also has comments and a bunch of explanation, such as that some algorithm is a SHOULD for IoT, but not otherwise. I think it’s better to point people at the RFC where the information is, rather than post very partial information in an IANA table. We do have a draft that is suggesting we add some tables :P https://tools.ietf.org/html/draft-pwouters-ikev1-ipsec-graveyard Paul From nobody Mon Nov 2 09:12:23 2020 Return-Path: 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 13CE33A0D37; Mon, 2 Nov 2020 09:12:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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=gmail.com 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 DtWT2lvw8lM6; Mon, 2 Nov 2020 09:12:15 -0800 (PST) Received: from mail-vs1-xe34.google.com (mail-vs1-xe34.google.com [IPv6:2607:f8b0:4864:20::e34]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7286D3A0D2E; Mon, 2 Nov 2020 09:12:15 -0800 (PST) Received: by mail-vs1-xe34.google.com with SMTP id e3so7866703vsr.8; Mon, 02 Nov 2020 09:12:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=6+8tfa3DLnRVU0Gz16644OBsn0norlE1LPN6kQE8BdM=; b=obUI73ANyV1s9xkzzDq/HjZM3F5aQiTrsLVUCBEsktzjeb2PPeWvYgLR8zf5cunO4N BoRaKT18iyI53Lb6Q+VjWAITzZsKuctuUfal3OC28xEXbsituvUAFzO9pwkSIPKyDsUx ohpjVS2lEWBKDfMYz+OGBXMW/CgooLKGUZTKh2YfxlGkOQJ8OT2NHhhfoDMkMMbRgVPH p17A5rgnZu5j+8SJ6X/Rj+fmBkWWPpBtKUp9/sdMoKyxM4Zs8dE8mHjndI4OBk/M3orm 2qW7TbipzmLmkRkd2TI9DYqnt/KyU4wq8rqlQoZF4Zcs2cDCuRfuyLAhhE8Qm53gQoIb eKlQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=6+8tfa3DLnRVU0Gz16644OBsn0norlE1LPN6kQE8BdM=; b=uMXzeZ0yWmNwF4qsl+PKwDLloEwsOcES0Y3jz/cB119K7mvWnjXYhAFH5n0W8/uvx9 h6ToKmwh432eRda1nCr4zxduWw5JuUWCyEdzeV8nOHys6LB3o5NrqCUJswseCDog6Ody yLlkRD/o+AGYRoPID/MbzQrzwrZLvobUGACBuktjvmZZatkXWCrS9vXTNNEGYuBLoOBn +MbJ9Ug/Zx9R50REBZvEaJkNIBJBc1zTASMT5YpazLd1STUzoRCe03GnBGg41X0yzNsA Q6uAin9dNNvwE/TKocjoB5WFMlR4ssR6I+GIsIRJrm7qZQfvyJk9ulsU1F7lsTvvB6f5 zFnQ== X-Gm-Message-State: AOAM531ckVAkzT/oxJEKrp+0LamKYvbke1Ky0pHUelYsmZk3iJyw0Wcx NaAAX0auO+mX6Aw9PQh0HQ8TPdTwijCr4bx8/c4= X-Google-Smtp-Source: ABdhPJze8XigyrVX9XOuW66zUVKpCtI1bgyRuPvkiwLHJownkRTyIlpoEZrdY1Iv/1CIG2eKtTuESIU0S+fGj2VQhxg= X-Received: by 2002:a05:6102:309a:: with SMTP id l26mr2604563vsb.4.1604337134578; Mon, 02 Nov 2020 09:12:14 -0800 (PST) MIME-Version: 1.0 References: <24476.26053.16496.150596@fireball.acr.fi> <24480.4335.981375.920639@fireball.acr.fi> In-Reply-To: <24480.4335.981375.920639@fireball.acr.fi> From: Daniel Migault Date: Mon, 2 Nov 2020 12:12:03 -0500 Message-ID: To: Tero Kivinen Cc: "Scott Fluhrer (sfluhrer)" , "ipsec@ietf.org" , lwip@ietf.org Content-Type: multipart/alternative; boundary="00000000000001af7805b322d970" Archived-At: Subject: Re: [IPsec] Comments on draft-ietf-lwig-minimal-esp-00 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Nov 2020 17:12:17 -0000 --00000000000001af7805b322d970 Content-Type: text/plain; charset="UTF-8" Thanks for the response and the reference. The Security Considerations referred to 4086, but I thought that it would be useful to add the reference from the nist. I have added the following sentence. """ In addition [SP-800-90A-Rev-1] provides appropriated guidances to build random generators based on deterministic random functions. """ I believe that we do not necessarily need to go into more details that are related to specific transforms, but I am happy to hear otherwise. Yours, Daniel On Mon, Nov 2, 2020 at 9:00 AM Tero Kivinen wrote: > Daniel Migault writes: > > > > Correct. it must be a MUST. I also explicitly added that condition on > nonce > > and counter needs to remain valid. The new text is as follows: > > > > When such mechanisms cannot be implemented and the session key is, for > > example, provisioned, the nodes MUST ensure that keys are not used beyond > > their life time and that the appropriate use of the key remains across > reboots > > - e.g. conditions on counters and nonces remains valid. > > > > > > Looks ok. > > > Normally you use just counter, and encrypt it with secret key. The IV > > in CBC does not be random, it needs to be unpredictable and it should > > not be direct counter or other source with low Hamming distance > > between successive IVs. > > > > Actually the problem with old way of CBC mode was that the IV was > > random, but predictable as implementations used last block of > previous > > packet. If attacker does not know the key you are using to encrypt > the > > counter to generate IVs, the IVs will be unpredictable and random. > > > > > > Thanks for the information. What I was wondering then, is for which > reason > > can't we consider this as a random generator - of a limited lifetime. > > > > That method is very common piece used when you are making random > number generator. It is for example part of the NIST AES Counter mode > based generator, but to properly make random number generator out of > that need bit more stuff around it. For example you need to make sure > it is rekeyed before the counter rolls over, and of course it is only > as secure as the random secret key you are using to seed it etc. > > See NIST SP 800-90A REv 1 [1] CTR_DRBG description for more > information. > > [1] https://csrc.nist.gov/publications/detail/sp/800-90a/rev-1/final > -- > kivinen@iki.fi > -- Daniel Migault Ericsson --00000000000001af7805b322d970 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks for the response and the reference. The Security Co= nsiderations referred to 4086, but I thought that it would=C2=A0be useful= =C2=A0to add the reference from the nist. I have added the following senten= ce.

"""
In addition [SP-800-90A= -Rev-1] provides appropriated guidances to build random generators based on= deterministic random functions.
"""
I believe that we do not necessarily need to go into more details that are= related to specific transforms, but I am happy to hear=C2=A0otherwise.
=

Yours,=C2=A0
Daniel

On Mon, Nov 2,= 2020 at 9:00 AM Tero Kivinen <kivinen= @iki.fi> wrote:
Daniel Migault writes:
> <mglt>
> Correct. it must be a=C2=A0 MUST. I also explicitly added that conditi= on on nonce
> and counter needs to remain valid. The new text is as follows:
>
> When such mechanisms cannot be implemented and the session key is, for=
> example, provisioned, the nodes MUST ensure that keys are not used bey= ond
> their life time and that the appropriate use of the key remains across= reboots
> - e.g. conditions on counters and nonces remains valid.
>
> </mglt>=C2=A0

Looks ok.

>=C2=A0 =C2=A0 =C2=A0Normally you use just counter, and encrypt it with = secret key. The IV
>=C2=A0 =C2=A0 =C2=A0in CBC does not be random, it needs to be unpredict= able and it should
>=C2=A0 =C2=A0 =C2=A0not be direct counter or other source with low Hamm= ing distance
>=C2=A0 =C2=A0 =C2=A0between successive IVs.
>=C2=A0 =C2=A0
>=C2=A0 =C2=A0 =C2=A0Actually the problem with old way of CBC mode was t= hat the IV was
>=C2=A0 =C2=A0 =C2=A0random, but predictable as implementations used las= t block of previous
>=C2=A0 =C2=A0 =C2=A0packet. If attacker does not know the key you are u= sing to encrypt the
>=C2=A0 =C2=A0 =C2=A0counter to generate IVs, the IVs will be unpredicta= ble and random.
>
> <mglt>
> Thanks for the information. What I was wondering then, is for which re= ason
> can't we consider this as a random generator - of a limited lifeti= me.=C2=A0
> </mglt>=C2=A0

That method is very common piece used when you are making random
number generator. It is for example part of the NIST AES Counter mode
based generator, but to properly make random number generator out of
that need bit more stuff around it. For example you need to make sure
it is rekeyed before the counter rolls over, and of course it is only
as secure as the random secret key you are using to seed it etc.

See NIST SP 800-90A REv 1 [1] CTR_DRBG description for more
information.

[1] https://csrc.nist.gov/publicatio= ns/detail/sp/800-90a/rev-1/final
--
kivinen@iki.fi


--
Daniel Migault
Ericsson
--00000000000001af7805b322d970-- From nobody Mon Nov 2 09:24:57 2020 Return-Path: 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 206193A1221; Mon, 2 Nov 2020 09:24:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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=gmail.com 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 eIdfrmbtIrwH; Mon, 2 Nov 2020 09:24:43 -0800 (PST) Received: from mail-vs1-xe2a.google.com (mail-vs1-xe2a.google.com [IPv6:2607:f8b0:4864:20::e2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 67D1E3A115A; Mon, 2 Nov 2020 09:24:38 -0800 (PST) Received: by mail-vs1-xe2a.google.com with SMTP id z123so3165171vsb.0; Mon, 02 Nov 2020 09:24:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=mQiXqQQuNMmoF7O4yA46x/e6nQVcwswxWkOVV1ZJoxc=; b=EQjNPF/Qjk9KEaoYbajJWImFStNmTHJIfNko3h81wow8gRve5Z9zoBSCjwnqITpV1F V15t5QhDAS4MAw85FX+/9qYONm/qD+7fW9+eLENjZUuQcwzzwWTeRf6uShH9iVZFYfbD YmnLltr8QyCQ+vb27vF2d1Tj5IEmyMsJPuSpQvfsbkdYo4GxQ3VF+beBn/bPqS9AHvjr eXaOzqKKXV1OFLyOoResmTauw7QP44l1rXL0+3A2iKYy+4vPiYfLEQW4+Lk77PVkNI1E 19QzEBsfwYcH30K4ixlkgXorysd/fzXlZCCqe+29zAqmXcJN9+ZM2uk4XPL5Nde74ou7 7wmg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=mQiXqQQuNMmoF7O4yA46x/e6nQVcwswxWkOVV1ZJoxc=; b=SEmRrmwEPOlfNSv5cOuKHEhmDKYY8h1EcGyzeEF0gUl22+U/zVt9IY+Jjahe/slfk7 AGLGjeQyK+BVmxtQ2wcZLC8LLrQjTcXpI4AzDXHHjQNJZn1SJxjKPxQpgbsPaXcTXJZv j4Nr4RJUUcMMap5o+Iix1Wyaca+3ySMgam7nJlny90wdwN4oEeH+gcYaLZ16iimdZE1h ZNCqsis8Ezdtl3ZsomlZbD/jKM9dbaKhJxTDsfp4B+SYkTdNtoY/qV0bjRZfa1ZbmyhT xYu7t7tQKW14JEVkz3bqGBXr7zhNBIPA+idgdzUzzlJBzu6Yk9PPzQCXyVJdKFukN19T ADew== X-Gm-Message-State: AOAM532MhXFOOjEPtBKaZIy8AS6yqFoHcXEJ1aK1Zh9Kgd4zE+Ppa9na sJJFa3HU750C4mK2c9zvoIVE2uQpMcf8D/Akb4v86yJFDzQ= X-Google-Smtp-Source: ABdhPJwpD0K+bB6bgXkc3/EyHlSf7GYaumDFzcCzFU3UPw1KxbDRC64vgWyRkY/V8VcnuQhpBYMffVa826sFyk0mCZ8= X-Received: by 2002:a67:1e02:: with SMTP id e2mr16377002vse.40.1604337877269; Mon, 02 Nov 2020 09:24:37 -0800 (PST) MIME-Version: 1.0 References: <160433745200.16997.11365491104089001144@ietfa.amsl.com> In-Reply-To: <160433745200.16997.11365491104089001144@ietfa.amsl.com> From: Daniel Migault Date: Mon, 2 Nov 2020 12:24:26 -0500 Message-ID: To: lwip@ietf.org, IPsecME WG Content-Type: multipart/alternative; boundary="00000000000046417c05b3230518" Archived-At: Subject: [IPsec] Fwd: [Lwip] I-D Action: draft-ietf-lwig-minimal-esp-02.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Nov 2020 17:24:53 -0000 --00000000000046417c05b3230518 Content-Type: text/plain; charset="UTF-8" Hi, Please find the updated version considering Tero's comments. Yours, Daniel ---------- Forwarded message --------- From: Date: Mon, Nov 2, 2020 at 12:18 PM Subject: [Lwip] I-D Action: draft-ietf-lwig-minimal-esp-02.txt To: Cc: A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Light-Weight Implementation Guidance WG of the IETF. Title : Minimal ESP Authors : Daniel Migault Tobias Guggemos Filename : draft-ietf-lwig-minimal-esp-02.txt Pages : 14 Date : 2020-11-02 Abstract: This document describes a minimal implementation of the IP Encapsulation Security Payload (ESP) defined in RFC 4303. Its purpose is to enable implementation of ESP with a minimal set of options to remain compatible with ESP as described in RFC 4303. A minimal version of ESP is not intended to become a replacement of the RFC 4303 ESP, but instead to enable a limited implementation to interoperate with implementations of RFC 4303 ESP. This document describes what is required from RFC 4303 ESP as well as various ways to optimize compliance with RFC 4303 ESP. This document does not update or modify RFC 4303, but provides a compact description of how to implement the minimal version of the protocol. If this document and RFC 4303 conflicts then RFC 4303 is the authoritative description. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-lwig-minimal-esp/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-lwig-minimal-esp-02 https://datatracker.ietf.org/doc/html/draft-ietf-lwig-minimal-esp-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-lwig-minimal-esp-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ Lwip mailing list Lwip@ietf.org https://www.ietf.org/mailman/listinfo/lwip -- Daniel Migault Ericsson --00000000000046417c05b3230518 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,=C2=A0

Please find the updated versi= on considering Tero's comments.=C2=A0

Yours,= =C2=A0
Daniel

---------- Forwarded message ---------
From: <internet-drafts@i= etf.org>
Date: Mon, Nov 2, 2020 at 12:18 PM
Subject: [L= wip] I-D Action: draft-ietf-lwig-minimal-esp-02.txt
To: <i-d-announce@ietf.org>
Cc: <lwip@ietf.org>



A New Internet-Draft is available from the on-line Internet-Drafts director= ies.
This draft is a work item of the Light-Weight Implementation Guidance WG of= the IETF.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= Minimal ESP
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Authors=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: Dani= el Migault
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Tobias Guggemos
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-iet= f-lwig-minimal-esp-02.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 14
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 := 2020-11-02

Abstract:
=C2=A0 =C2=A0This document describes a minimal implementation of the IP
=C2=A0 =C2=A0Encapsulation Security Payload (ESP) defined in RFC 4303.=C2= =A0 Its
=C2=A0 =C2=A0purpose is to enable implementation of ESP with a minimal set = of
=C2=A0 =C2=A0options to remain compatible with ESP as described in RFC 4303= .=C2=A0 A
=C2=A0 =C2=A0minimal version of ESP is not intended to become a replacement= of the
=C2=A0 =C2=A0RFC 4303 ESP, but instead to enable a limited implementation t= o
=C2=A0 =C2=A0interoperate with implementations of RFC 4303 ESP.

=C2=A0 =C2=A0This document describes what is required from RFC 4303 ESP as = well as
=C2=A0 =C2=A0various ways to optimize compliance with RFC 4303 ESP.

=C2=A0 =C2=A0This document does not update or modify RFC 4303, but provides= a
=C2=A0 =C2=A0compact description of how to implement the minimal version of= the
=C2=A0 =C2=A0protocol.=C2=A0 If this document and RFC 4303 conflicts then R= FC 4303 is
=C2=A0 =C2=A0the authoritative description.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-= ietf-lwig-minimal-esp/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-lw= ig-minimal-esp-02
https://datatracker.ietf.org/doc= /html/draft-ietf-lwig-minimal-esp-02

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2= =3Ddraft-ietf-lwig-minimal-esp-02


Please note that it may take a couple of minutes from the time of submissio= n
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


_______________________________________________
Lwip mailing list
Lwip@ietf.org
https://www.ietf.org/mailman/listinfo/lwip


--
Dani= el Migault
Ericsson
--00000000000046417c05b3230518-- From nobody Mon Nov 2 10:34:35 2020 Return-Path: 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 7FC5D3A0A93; Mon, 2 Nov 2020 10:34:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.346 X-Spam-Level: X-Spam-Status: No, score=-2.346 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.247, 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 (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 y0mtZeSGVevv; Mon, 2 Nov 2020 10:34:24 -0800 (PST) Received: from meesny.iki.fi (meesny.iki.fi [IPv6:2001:67c:2b0:1c1::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 229913A0A8D; Mon, 2 Nov 2020 10:34:22 -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) by meesny.iki.fi (Postfix) with ESMTPSA id 1363C20A2E; Mon, 2 Nov 2020 20:34:19 +0200 (EET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=iki.fi; s=meesny; t=1604342059; 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=1UPsgwmObMclOhlJEZrKI9LqYxqQXTbWOQJgQxrkPqU=; b=f6f+PNqmief9SIQ5NIcmn2rgVczHKilQdQLCieNpgDnRslp9PKMWvAEWxfWaIM8A+amFJk OFvHxyZyIe1HO1rI/VVun6/D9lDZ4ZNN6Pn8haLk8mnG8JNTxRe4cOgLVuPxC8pYLEpezV TEnVDUIvPi72wIGizwNEaDbgSs6tEt0= Received: by fireball.acr.fi (Postfix, from userid 15204) id AEE0425C121D; Mon, 2 Nov 2020 20:34:18 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <24480.20778.648771.190786@fireball.acr.fi> Date: Mon, 2 Nov 2020 20:34:18 +0200 From: Tero Kivinen To: tom petch Cc: Roman Danyliw , "ipsec\@ietf.org" , "i2nsf\@ietf.org" , Gabriel Lopez , "ynir.ietf\@gmail.com" , Fernando Pereniguez-Garcia , "last-call\@ietf.org" , Rafa Marin-Lopez In-Reply-To: <5F9D62C0.5030908@btconnect.com> References: <160337357077.29083.9236626834026808055@ietfa.amsl.com> <5F9815D1.9010303@btconnect.com> <5F99B221.3040504@btconnect.com> <56155C91-BFE8-4BA9-A55C-46B12E59CD94@um.es> <5F9AEFD3.90903@btconnect.com> <059aaae84a354411ad1023afa2a837ba@cert.org> <5F9BF578.6000101@btconnect.com> <834a668ac559460a9f356bbb6c16b8fd@cert.org> <24476.38596.868667.906930@fireball.acr.fi> <5F9D62C0.5030908@btconnect.com> X-Mailer: VM 8.2.0b under 26.3 (x86_64--netbsd) X-Edit-Time: 43 min X-Total-Time: 74 min ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=iki.fi; s=meesny; t=1604342059; 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=1UPsgwmObMclOhlJEZrKI9LqYxqQXTbWOQJgQxrkPqU=; b=j5+qr5EnhfnWwxB/dGQJuRXsq5GiCdBBk9RWUwsjvIIxblXzoorKh9knHfUYf2638khWCS o0whCJD/wnrE4Q7BpaG9U64wDsWPHKTBwNTc/cbX2ejdK3V5NM2YQWIO+rbaSZecLZGqyZ TJM/5ptVno5tyUpEcMARCPFk0zGY+lU= ARC-Authentication-Results: i=1; ORIGINATING; auth=pass smtp.auth=kivinen smtp.mailfrom=kivinen@iki.fi ARC-Seal: i=1; s=meesny; d=iki.fi; t=1604342059; a=rsa-sha256; cv=none; b=zG5PHcLtUc2cQiBDAJc23pYgQ+efsMKsAgGXHsjuP2gyj/D93eqcFpNUv1svY7+NEeAdTq 5u7YEUNrzEp7ZISwLr3ac/mfb/dmV+hNakcZJz/2juxYMeFbSy2v+fngPvtGjfL8+dtnQX tAdGj1bvA69v83gAuzZxr9O2I+BRnMY= Archived-At: Subject: Re: [IPsec] [Last-Call] New Version Notification for draft-ietf-i2nsf-sdn-ipsec-flow-protection-11.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Nov 2020 18:34:33 -0000 tom petch writes: > And RFC8247 specifies which algorithm are AEAD, the web page does not. Actually RFC8247 does not specify which algorithms are AEAD. It only specifies that information for those algorithms it lists. For example it does not mention ENCR_AES_CCM_16 at all, thus it does not list whether it is AEAD algorithm or not. > The YANG module behaves differently depending on whether or not the > algorithm is AEAD; YANG implementors need to know, having this > information on the web page would make it easier for YANG implementors. I can see some benefits for having the "AEAD?" column added to the IANA registry, as there are differences how things are processed depending whether the algorithm is AEAD or not. Currently the only way to find whether the algorithm is AEAD is to read the RFC describing the algorithm. Also as that information is static, meaning it will not change over time (compared to the recommendation levels which do change every time we make new version of Algorithm Implementation Requirements and Usage Guidance document), there is no problem for not having history available, or having conflicting information in different places (RFC vs IANA page). On the other other hand we would problably need three values for that column, one would be AEAD, another would non-AEAD and one would be MAC-only. The ENCR_NULL_AUTH_AES_GMAC, ENCR_KUZNYECHIK_MGM_MAC_KTREE and ENCR_MAGMA_MGM_MAC_KTREE are not really an AEAD algorithms as they do not encrypt anything but just put everything in the AAD of AEAD structure. > As I said to Roman, the TLS WG found that they needed to add extra > columns to their web pages of algorithms. Different columns (e.g. DTLS > not AEAD) but I think that the situation is otherwise identical so I am > anticipating that in a year or two you will see what I mean:-). In TLS do have bit more entries in its registry, mostly because they combine everything to one suite, meaning instead of adding separate algorithms, they usually add multiple combinations of algorithms as different suites, and when there started to be hundreds of those, maintaining that list got bit annoying and especially to know which one of them are something that implementations should implement. I think our a la carte method is better as it limits the the number of algorithms we are going to have, although the number of combinations that can be negotiated is much higher... > I take your point about duplicating data - no relational databases here! > - but the answer is to specify which is authoritative and for me that > should be the IANA pages as it is for many assignments in the context of > YANG and before that SMI going back decades. I would always consider the published RFC as more authorative than IANA pages, as IANA pages are updated by writing RFCs, and there have been mistakes and there will be mistakes when extracting that data from RFCs to IANA registry. RFCs (or other published standard documents) do have some kind of process to verify that the information is approved by the SDO, meaning lots of people do check them. IANA registries are then extracted by hand by people from those documents and only checked by handful of people before published. Usually IANA do want us to make an RFC to modify the registry, like we did add RFC8247 where we renamed 6 old algorithms so that the naming is more consistent (rename AES-GCM with a 8 octet ICV to ENCR_AES_GCM_8 etc). But not always. For example RFC4309 asks IANA to add "AES CCM with an {8,12,16}-octet ICV" and what I think IANA did was to add ENCR_AES-CCM_8 (underline, dash, underline), ENCR-AES-CCM_12 (dash, dash, underline), ENCR-AES-CCM_16 (dash, dash, underline) to registry, without consulting anybody, and which we then noticed 4 years later [1]. I think we managed to fix that dash -> underline error, by just going to the IANA desk in IETF and they did the change immediately, but for the more substanial changes they wanted us to make an RFC that did those changes. Thats why the RFC8247 has those quite unrelated renaming things in it... [1] https://mailarchive.ietf.org/arch/msg/ipsec/VmlenjxLKjWhldztreN5p9I3yP0/ -- kivinen@iki.fi From nobody Mon Nov 2 15:03:35 2020 Return-Path: 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 567443A1282 for ; Mon, 2 Nov 2020 15:03:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 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, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca 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 pLFqgQUjglZp for ; Mon, 2 Nov 2020 15:03:30 -0800 (PST) Received: from mx.nohats.ca (mx.nohats.ca [IPv6:2a03:6000:1004:1::68]) (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 22EB43A126E for ; Mon, 2 Nov 2020 15:03:17 -0800 (PST) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 4CQ7kC2lj5zKRB for ; Tue, 3 Nov 2020 00:03:15 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1604358195; bh=M9YNkuOaaY8S6K2QNb6zav7l7sFlsZr0eJPlpvVzfhc=; h=Date:From:To:Subject; b=Y07Kyd3YI/jGzvdrSDAG1nMjyYyPwfuWItMgtmPuN3/NH9BQWw6J4l/Otc8NWT5zh Bkbratz0LFkcPq0XGdiaM0E6l9qg1fImypnRzDPjhMOjp6qG1XeNoQM56E8ju7Zyzs q6sgRMVvpW7eota/nCi7NiLmGyIuUH9s9tuF0W84= X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id 9qNSmHn1jlHL for ; Tue, 3 Nov 2020 00:03:13 +0100 (CET) Received: from bofh.nohats.ca (bofh.nohats.ca [193.110.157.194]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS for ; Tue, 3 Nov 2020 00:03:13 +0100 (CET) Received: by bofh.nohats.ca (Postfix, from userid 1000) id 594036020F63; Mon, 2 Nov 2020 18:03:12 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 51524769 for ; Mon, 2 Nov 2020 18:03:12 -0500 (EST) Date: Mon, 2 Nov 2020 18:03:12 -0500 (EST) From: Paul Wouters To: "ipsec@ietf.org WG" Message-ID: MIME-Version: 1.0 Content-Type: text/plain; CHARSET=UTF-8; format=flowed Content-Transfer-Encoding: 8BIT Archived-At: Subject: [IPsec] Fwd: New Version Notification for draft-pwouters-multi-sa-performance-00.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Nov 2020 23:03:34 -0000 Hi all, Antony, Steffen and I wrote a draft on increasing IPsec performance. This is the method we are envisioning for the Linux kernel. There is an experimental implementation in the kernel and libreswan/strongswan IKE daemons. It supports per-CPU and per-QoS Child SA's. Paul From: internet-drafts@ietf.org Date: November 2, 2020 at 14:09:16 EST To: Steffen Klassert , Paul Wouters , Antony Antony Subject: New Version Notification for draft-pwouters-multi-sa-performance-00.txt A new version of I-D, draft-pwouters-multi-sa-performance-00.txt has been successfully submitted by Paul Wouters and posted to the IETF repository. Name:        draft-pwouters-multi-sa-performance Revision:    00 Title:        IKEv2 support for per-queue Child SAs Document date:    2020-11-02 Group:        Individual Submission Pages:        10 URL:            https://www.ietf.org/archive/id/draft-pwouters-multi-sa-performance-00.txt Status:         https://datatracker.ietf.org/doc/draft-pwouters-multi-sa-performance/ Htmlized:       https://datatracker.ietf.org/doc/html/draft-pwouters-multi-sa-performance Htmlized:       https://tools.ietf.org/html/draft-pwouters-multi-sa-performance-00 Abstract:   This document defines two Notification Payload (NUM_QUEUES and   QUEUE_INFO) for the Internet Key Exchange Protocol Version 2 (IKEv2).   These payloads add support for negotiating multiple identical Child   SAs that can be used to to optimize performance based on the number   of queues or CPUs, orcw to create multiple Child SAs for different   Quality of Service (QoS) levels.   Using multiple identical Child Sa's has the additional benefit that   multiple streams have their own Sequence Number, ensuring that CPU's   don't have to synchronize their crypto state or disable their replay   window detection. From nobody Tue Nov 3 04:04:14 2020 Return-Path: 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 BA9173A08F6; Tue, 3 Nov 2020 04:04:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.148 X-Spam-Level: X-Spam-Status: No, score=-2.148 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, MSGID_FROM_MTA_HEADER=0.001, NICE_REPLY_A=-0.247, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=btconnect.onmicrosoft.com 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 asLvhtCfmXj0; Tue, 3 Nov 2020 04:04:12 -0800 (PST) Received: from EUR05-DB8-obe.outbound.protection.outlook.com (mail-db8eur05on2134.outbound.protection.outlook.com [40.107.20.134]) (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 68B6E3A08E7; Tue, 3 Nov 2020 04:03:28 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=I/L09wXI6yjRHxbgcqJRZQh7aMLXHwRLTj7cTJllFK8tL62WCYp2CZ4oXN+Jl/gFq2axDeF0hKoEPg7cwOmvSXgiT12gVDlOzBoQBJYAign4sRgSaacXpbTky/YNPHQJU1Jp86/7CYzcPa5aXbpC8q1ugqdulKpxp8o/xxjU6FTwIdDu1W3qM2z4P3IICJe7r1TSNhTz/FD1cEYyUkp9UkgkKjlW2xbMOHROBsPStdQhV/IFtcz14IHQb8cp/xoP7qfPBIoz5psz5H2VQd46DCuh6IzdFRvii9aq3xf6/4aKVsLyQNtZQHxy/WJRDxtd4ZhcfSfPIIYMZXZIJtgCVA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=yU+243sWsVjlvTpyC+n/blcCohvYRQq/uL9Dv9Z5A7I=; b=Voba3GzPpG8UqYvFv7u0xTkyGQRmr/xf+h1zUl4Q17AjhBTf3cpSQx7Gw/Jk9OTraCl0xZ4MQd5J+TWssHSFeevbj8xP5i7IHocMlByg4QyQKSqzt76Q9yhivNx6GYCNinSD8zTohkbkq133fc0mCHI6uUVSzUH57MGJT/359eqStr6GNLIBRIlL8JZjUDCbYEdGkQQ4B+KH1v8lrQ77YLJk70R6ylMiMAs+XOoZQxHRDSUItYOAzkKwMcwL0/ub9mCyE3lLmuKeh0ZDDSvBUeEWoCgvT/R4Ek62lClK3WyPk/Wnz6OPoVXqbbB4jg6BljBCGs33asoDaKCBx6qa1g== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=btconnect.com; dmarc=pass action=none header.from=btconnect.com; dkim=pass header.d=btconnect.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btconnect.onmicrosoft.com; s=selector2-btconnect-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=yU+243sWsVjlvTpyC+n/blcCohvYRQq/uL9Dv9Z5A7I=; b=AtY84deyx96QcCEh40cNO92SXHUkUC85Il5vyEvdclYfa1R1Zit5Z9f8aummrCXx5R6MrDuK7HFVB3lIXM3ZD5fVBrgvE5WVTAHCSK8lM22P8NIOJQrFpV9PfGBkpIAlQZ2kzWbORRPFJXga9Ef7tWyxKKLVDqBITe7eVyJUC4U= Authentication-Results: um.es; dkim=none (message not signed) header.d=none;um.es; dmarc=none action=none header.from=btconnect.com; Received: from VI1PR07MB6704.eurprd07.prod.outlook.com (2603:10a6:800:18b::8) by VI1PR07MB6335.eurprd07.prod.outlook.com (2603:10a6:800:136::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3541.10; Tue, 3 Nov 2020 12:03:23 +0000 Received: from VI1PR07MB6704.eurprd07.prod.outlook.com ([fe80::6407:6ea2:f517:eeae]) by VI1PR07MB6704.eurprd07.prod.outlook.com ([fe80::6407:6ea2:f517:eeae%7]) with mapi id 15.20.3541.015; Tue, 3 Nov 2020 12:03:23 +0000 To: Valery Smyslov , 'Tero Kivinen' , 'Roman Danyliw' References: <160337357077.29083.9236626834026808055@ietfa.amsl.com> <5F9815D1.9010303@btconnect.com> <5F99B221.3040504@btconnect.com> <56155C91-BFE8-4BA9-A55C-46B12E59CD94@um.es> <5F9AEFD3.90903@btconnect.com> <059aaae84a354411ad1023afa2a837ba@cert.org> <5F9BF578.6000101@btconnect.com> <834a668ac559460a9f356bbb6c16b8fd@cert.org> <24476.38596.868667.906930@fireball.acr.fi> <5F9D62C0.5030908@btconnect.com> <000001d6af8e$43baa2d0$cb2fe870$@gmail.com> Cc: 'Fernando Pereniguez-Garcia' , i2nsf@ietf.org, 'Gabriel Lopez' , ynir.ietf@gmail.com, ipsec@ietf.org, last-call@ietf.org, 'Rafa Marin-Lopez' From: tom petch Message-ID: <5FA14709.6080903@btconnect.com> Date: Tue, 3 Nov 2020 12:03:21 +0000 User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 In-Reply-To: <000001d6af8e$43baa2d0$cb2fe870$@gmail.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [86.146.121.140] X-ClientProxiedBy: LNXP265CA0033.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:5c::21) To VI1PR07MB6704.eurprd07.prod.outlook.com (2603:10a6:800:18b::8) MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from [192.168.1.65] (86.146.121.140) by LNXP265CA0033.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:5c::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.20.3499.18 via Frontend Transport; Tue, 3 Nov 2020 12:03:22 +0000 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: bc1d44c2-b899-4930-bf52-08d87ff076d3 X-MS-TrafficTypeDiagnostic: VI1PR07MB6335: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:10000; X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: 5xu97lQzWoS/Lvpn0dhgq3P8OG92IJOtO6x4evJjnSwruypJhpKR8D/ND7bfC+z8qMBTFE40pTX24LWIVFCV4d/tcRGgcOrh0N8b4ENGi93L1whymRbEacEVx/KkCIBNr1bqOTEzXmz3W3fV5sZhHpKewpRffavujxH3fvTgj24VREqPEmjy0TDqV95kfnMx/HDFiIn/nXPIqaMFY1IYafod8Dv3G012to7geS5ympb+Ig0qsfCAATwGRyveNJ0HlzMVmYAK/IV+W//4hGL76rmmzG4LO1YYYc6lx2z3DEfRuJ6dNgrzVvx4Krs9kQq2WXCjmsSFKvtpCo0QvpvWmA== X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:VI1PR07MB6704.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFS:(366004)(54906003)(110136005)(33656002)(83380400001)(53546011)(66946007)(8936002)(16576012)(186003)(8676002)(66476007)(66556008)(15650500001)(4326008)(26005)(16526019)(498600001)(7416002)(956004)(87266011)(86362001)(2906002)(36756003)(6486002)(52116002)(2616005)(5660300002); DIR:OUT; SFP:1102; X-MS-Exchange-AntiSpam-MessageData: ZpcijTR1a/0EMbQNlBKxYSq9MkT+oKMnxf18hKxTKG1TtFFr8N65rTDq9743/o+o4U1GRBbRKXHukOYA2NN+XpPWI6Nuz0XymxdnkHCeWw6yqy8aui7rCSFEAoHdFZttgEalQqf+ckD6lmL9Op2S90nJ1UGpxbMB6s9V1JFXh65euXpJ/aK5W/6nUDFsP6XZPYb8xbE0d2saQRyMry163yaIQFVVfZeROpWuUjSfy8PU31VOCTsXhvJCntHzNQFvD81sJR6nvs5A78A+xggupU1w4SeexwahlzohteDlFXfeMnOfb7ax0307Yb1ILNL9H0/UxxKQpKbl5r8+eALMUFIfwHhiAgQMYfZa2MkOGuI/lrCTSkbEz4KNcFV1Hc9JQIvYFB7RD6twR6fDMcSbpk4xSHbUextz6KVA1YidpxOGUpQxVa6ozW3q977EIrBqNgrdFmfdEEiCSZx4KYKhhJ5+mBrkYao6S60AXpULbFAuahFMhXEOCPRvatDOPLen3+JkI913jdXetE0lG6ywxoNfdh7GRyiB6PFEXsO1nlTPtRt8PV3gAN9BBBGoEsVDZhH9KixP3YT6DCx8kHPMPHoxppkOgfxOSCNmbY1TfdtdZKqLZfgfQ9GrxgQ/0QIoq9OQ0MLfT9Bg+PC0+ae4bA== X-OriginatorOrg: btconnect.com X-MS-Exchange-CrossTenant-Network-Message-Id: bc1d44c2-b899-4930-bf52-08d87ff076d3 X-MS-Exchange-CrossTenant-AuthSource: VI1PR07MB6704.eurprd07.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 03 Nov 2020 12:03:23.7194 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: cf8853ed-96e5-465b-9185-806bfe185e30 X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: 8ZxRiuOLRqOE+ompzBu4FoUvuKMEjUep/kp5L3+1wG+biSpzHJqsh9PDFpeoNSu1J4k+ug5pXG+sBEHUHytnmg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR07MB6335 Archived-At: Subject: Re: [IPsec] [I2nsf] [Last-Call] New Version Notification for draft-ietf-i2nsf-sdn-ipsec-flow-protection-11.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Nov 2020 12:04:14 -0000 On 31/10/2020 14:01, Valery Smyslov wrote: > Hi Tom, > > we discussed with the chairs the usefulness of adding "Recommended/Not > recommended" column > (as TLS WG did) into the IKEv2 algorithm registries back in 2018 in Bangkok > and I was one who > of those who initially suggested this. However, Tero made a very good point > that > IANA doesn't have any public history. So, in the ipsecme WG another approach > was taken - we have RFCs that say which algorithms are recommended/not > recommended > for ESP and for IKEv2 and these RFCs are updated periodically. > >> Thanks for getting back to me. What is missing from the IANA registry >> is the guidance as to the status of the algorithm, how highly it is >> recommended or not. This I-D tells people to go to RFC8247 and the IANA >> Registry for advice; RFC8247 gives that advice; the IANA web page does > not. > > As Tero said, the IANA web page references current RFCs (8221 & 8247 at the > moment) > that list recommended algorithms. Just one more level of indirection. All > algorithms that are not listed > in these RFC are treated as "not recommended" by default, including newly > added algorithms. > >> And RFC8247 specifies which algorithm are AEAD, the web page does not. >> The YANG module behaves differently depending on whether or not the >> algorithm is AEAD; YANG implementors need to know, having this >> information on the web page would make it easier for YANG implementors. > > Is is a problem to open corresponding RFC or I-D? Or do you want to say that > > YANG implementers don't need any other information about algorithms > except whether it's AEAD and whether it's recommended? Valery The problem I see is where to direct readers of the i2nsf-sdn to for more information, about which algorithms are recommended, or not, and, a secondary consideration, whether they are AEAD or not, since the latter affects the YANG module. The I-D has lots of references to RFC7296 and that RFC is very clear - for up-to-date information go to IANA. The RFC that update RFC7296 do not appear to update that advice. And the i2nsf I-D also contains references to IANA often alongside a reference to an RFC. You seem to be saying that IANA is only a good reference if it points to an RFC that says so which may not match the expectations of users (particularly those who are familiar with the approach of the TLS WG). If they are pointed to IANA they may well expect IANA to be the best source of information but you seem to be saying that the WG decided not to support that, rather expecting people to read the RFC. If IANA said 'use this to find the RFC but do not otherwise trust this information' that would be fine, well in a manner of speaking:-) So, question. What references should draft i2nsf-sdn point readers to for up-to-date information on algorithms (assuming that they do not track the IETF WG that updates information on IKEv2 ie like me)? Currently that is both a reference to the IANA registry and to an RFC; is that your best advice? Were I an author of this I-D, as opposed to a reader thereof, then based on what you say I would remove references to the IANA website or at least qualify them with some statement that they need to check the RFC for current information! What would you advise? Tom Petch > > Regards, > Valery Smyslov. > >> And RFC8247 specifies IoT, which I do not think is yet a consideration > here. >> >> As I said, we are currently ok but as new algorithms get added, by >> Expert Review, then that information is needed and may not be available >> as there is no requirement for the Expert Reviewer to make it available. >> >> As I said to Roman, the TLS WG found that they needed to add extra >> columns to their web pages of algorithms. Different columns (e.g. DTLS >> not AEAD) but I think that the situation is otherwise identical so I am >> anticipating that in a year or two you will see what I mean:-). In >> passing, the TLS WG determine by consensus what the status is for a new >> algorithm but the Expert Reviewer makes it available via the web site >> whether or not it is in an RFC. >> >> I take your point about duplicating data - no relational databases here! >> - but the answer is to specify which is authoritative and for me that >> should be the IANA pages as it is for many assignments in the context of >> YANG and before that SMI going back decades. >> >> Tom Petch >> From nobody Tue Nov 3 12:07:52 2020 Return-Path: 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 DC6303A1115; Tue, 3 Nov 2020 12:07:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.347 X-Spam-Level: X-Spam-Status: No, score=-2.347 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.247, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham 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 1Kc8JmWbwgLK; Tue, 3 Nov 2020 12:07:48 -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 542063A0DEC; Tue, 3 Nov 2020 12:07:46 -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) by meesny.iki.fi (Postfix) with ESMTPSA id 62002205BB; Tue, 3 Nov 2020 22:07:43 +0200 (EET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=iki.fi; s=meesny; t=1604434063; 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=ZyBSGUJkYO/DxJ8kCNiY4JOCI+Aj5j6KROQd9EYQtSo=; b=MXfdR2VaHddR5IDMlsWUCUq+3wNTY1DQ3pvpu7qxHrqEUsP1Ig0qIeEZZIz2DncPLH2Moa 0HdN8Zu6Q36Ajp0es1aqf0r7DZl9+V5m9olHh1wIq5K3QnQ6ahiQNWdtd8n4a+9f6Th0xH Hzg8u/EcfuBvl+yZSI4SZ7XmeZ7YawQ= Received: by fireball.acr.fi (Postfix, from userid 15204) id 09F8B25C0FFA; Tue, 3 Nov 2020 22:07:43 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <24481.47246.986256.641311@fireball.acr.fi> Date: Tue, 3 Nov 2020 22:07:42 +0200 From: Tero Kivinen To: tom petch Cc: Valery Smyslov , 'Roman Danyliw' , 'Fernando Pereniguez-Garcia' , i2nsf@ietf.org, 'Gabriel Lopez' , ynir.ietf@gmail.com, ipsec@ietf.org, last-call@ietf.org, 'Rafa Marin-Lopez' In-Reply-To: <5FA14709.6080903@btconnect.com> References: <160337357077.29083.9236626834026808055@ietfa.amsl.com> <5F9815D1.9010303@btconnect.com> <5F99B221.3040504@btconnect.com> <56155C91-BFE8-4BA9-A55C-46B12E59CD94@um.es> <5F9AEFD3.90903@btconnect.com> <059aaae84a354411ad1023afa2a837ba@cert.org> <5F9BF578.6000101@btconnect.com> <834a668ac559460a9f356bbb6c16b8fd@cert.org> <24476.38596.868667.906930@fireball.acr.fi> <5F9D62C0.5030908@btconnect.com> <000001d6af8e$43baa2d0$cb2fe870$@gmail.com> <5FA14709.6080903@btconnect.com> X-Mailer: VM 8.2.0b under 26.3 (x86_64--netbsd) X-Edit-Time: 16 min X-Total-Time: 16 min ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=iki.fi; s=meesny; t=1604434063; 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=ZyBSGUJkYO/DxJ8kCNiY4JOCI+Aj5j6KROQd9EYQtSo=; b=f8wBgc/GqvvhcJ/HvkAqHzREB9IpipRFSJg0o48O12KqiyiBalFG+KTtlM2RJy0+7q7iX5 //+EeIvtc87MNbevtx409/mXuLpQQHTtvNCF5jfXweQ8NnrA+GSxAJInG0LArTqkoBzfMf 2biHtTudWO/woKqPzVLhm5WQjWrqU0c= ARC-Authentication-Results: i=1; ORIGINATING; auth=pass smtp.auth=kivinen smtp.mailfrom=kivinen@iki.fi ARC-Seal: i=1; s=meesny; d=iki.fi; t=1604434063; a=rsa-sha256; cv=none; b=bR5eq7Vvhh71ieerrgTXH0UH4V0GUy5rtL1yjIqb0oLvwj3oaQfNWG8fH+9V35aB+byjdR FU880BB31lG7090ePDeKspelOMIMX2L2kCj/JYWsXCnSFutd3elBQE+FqB/5AaeleKNLIC OAOiyacWyAWwyvQrP3x/nLFg14JNgBI= Archived-At: Subject: Re: [IPsec] [I2nsf] [Last-Call] New Version Notification for draft-ietf-i2nsf-sdn-ipsec-flow-protection-11.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Nov 2020 20:07:51 -0000 tom petch writes: > The problem I see is where to direct readers of the i2nsf-sdn to for > more information, about which algorithms are recommended, or not, and, a > secondary consideration, whether they are AEAD or not, since the latter > affects the YANG module. The I-D has lots of references to RFC7296 and > that RFC is very clear - for up-to-date information go to IANA. Not exactly. RFC7296 says: ---------------------------------------------------------------------- .... Readers should refer to [IKEV2IANA] for the latest values. ---------------------------------------------------------------------- meaning it says that the tables in RFC7296 might not be complete, as there are more values allocated by IANA than what is in there, and to get complete list of values in each table, you need to go to the IANA registry. Then in section "3.3.4. Mandatory Transform IDs" it says: ---------------------------------------------------------------------- The specification of suites that MUST and SHOULD be supported for interoperability has been removed from this document because they are likely to change more rapidly than this document evolves. At the time of publication of this document, [RFC4307] specifies these suites, but note that it might be updated in the future, and other RFCs might specify different sets of suites. ---------------------------------------------------------------------- Which points us to RFC4307 which was obsoleted by the RFC 8247 which is the latest version of that document. So RFC7296 is quite clear that you go in different places to find the list of numbers (IANA) and to find which algorithms are mandatory to implement. > The RFC that update RFC7296 do not appear to update that advice. RFC 8247 was actually marked as Updating 7296, so anybody reading 7296 will find that version too, even without going through RFC4307. > And the i2nsf I-D also contains references to IANA often alongside a > reference to an RFC. You seem to be saying that IANA is only a good > reference if it points to an RFC that says so which may not match > the expectations of users (particularly those who are familiar with > the approach of the TLS WG). If they are pointed to IANA they may > well expect IANA to be the best source of information but you seem > to be saying that the WG decided not to support that, rather > expecting people to read the RFC. If IANA said 'use this to find the > RFC but do not otherwise trust this information' that would be fine, > well in a manner of speaking:-) The IANA contains the tables that maps the numbers used in the IKEv2 to the names and references where they are specified. As others have pointed out, some of those algorithms are not recommended all the time, but only for specific use cases and or for specific key lengths, like ENCR_AES_CBC, where RFC8247 has text like this: ENCR_AES_CBC is raised from SHOULD+ for 128-bit keys and MAY for 256-bit keys in [RFC4307] to MUST. 192-bit keys remain at the MAY level. ENCR_AES_CBC is the only shared mandatory-to-implement algorithm with RFC 4307 and as a result, it is necessary for interoperability with IKEv2 implementation compatible with RFC 4307. or ENCR_AES_CCM_8: ENCR_AES_CCM_8 was not considered in RFC 4307. This document considers it as SHOULD be implemented in order to be able to interact with IoT devices. As this case is not a general use case for non-IoT VPNs, its status is expected to remain as SHOULD. The 8-octet size of the ICV is expected to be sufficient for most use cases of IKEv2, as far less packets are exchanged in those cases, and IoT devices want to make packets as small as possible. The SHOULD level is for 128-bit keys, 256-bit keys remains at MAY level. To explain this kind of things in the IANA registry would get quite a lot of more columns.... > So, question. What references should draft i2nsf-sdn point readers to > for up-to-date information on algorithms (assuming that they do not > track the IETF WG that updates information on IKEv2 ie like me)? It should use IANA registry for the mapping between numbers, algorithms and references; and then for algoritm implementation requirements and usage guidance it should point to RFC8247 for IKEv2, and to RFC8221 for ESP. > Currently that is both a reference to the IANA registry and to an RFC; > is that your best advice? Yes. > Were I an author of this I-D, as opposed to a reader thereof, then based > on what you say I would remove references to the IANA website or at > least qualify them with some statement that they need to check the RFC > for current information! You always need to check the RFC of the current information if you are planning to implement any of the algorithms. -- kivinen@iki.fi From nobody Thu Nov 5 07:33:56 2020 Return-Path: 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 0F0C93A131A; Thu, 5 Nov 2020 07:33:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 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, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 EqnIPx0aElNO; Thu, 5 Nov 2020 07:33:43 -0800 (PST) Received: from mail-wr1-x436.google.com (mail-wr1-x436.google.com [IPv6:2a00:1450:4864:20::436]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B1E203A13EF; Thu, 5 Nov 2020 07:33:30 -0800 (PST) Received: by mail-wr1-x436.google.com with SMTP id y12so2256700wrp.6; Thu, 05 Nov 2020 07:33:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:content-language :thread-index; bh=T1yO4i6PtXUsoWe+qfhS9zXAIN4qRyFMx0tlUc+qWLE=; b=h47u278Mvay6oHljts3iBe0hsvgR4irAOM4TTTSeChssjlDzX+87QW01rBhanqks2n cHH3O9I9qhhfsNAGTtWfKIxIaPK2QZ5B3/Fgm5x4jg7rrFNy7xJGmC//7Xtf0poU08gP lvcerAU4H3Gn1E1ufLIJ26AyQjicXJTemkaiDpi3gJ7wKXulYORrDDqCzK43EO7Et26r 0oO1tYyRf7tQjzPIyB5ueDzf0GuYP4Hc1UxZ/0FWNcz7l0twCtQcCaoX7ZZ4ze0wJ8ma 8t3MSgFt+1t1KZExt9NRhwIAbftSQZxy/HOZ86E/+GrbBMqdgJP4OLIXZjTe9vpwQTz8 CSoQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:content-transfer-encoding:content-language :thread-index; bh=T1yO4i6PtXUsoWe+qfhS9zXAIN4qRyFMx0tlUc+qWLE=; b=E3f9e477OBV/WIip0Un3CRnNzbBwZe6dSwOtd1zmTxkiRYCwoVtVqRo/y0XsXeWpnL 3eYEqtNAy2yFgIJNmDNjS0dX5Hz66dYbn53lKtBWf6zLyJh2yekJit+xoxAJlA60/4/m XidIOvz789fBEcXW357a2m8akxx6WzJDuQGaNaMHc26/a0ofvuxhHL39Kql3mt6C929r uHP6n59KBkX0mpevqmYxPdvLlgcMN177yl5NeTqJnEpErZNCnNGmQVUrL4fBvMTcuuCa k729Ax5nDMfxLjisZurLZmBDSGbDnwW+2G+VDalE3JtaEGxG2YXZ9DkOkNzOs90/4RWu OO7w== X-Gm-Message-State: AOAM532c/Z8uA+cM1XbsVAKGK0iDF8kxKLvB5Q+yoZUqmCTuEkH7bwFi eXGIYh3HzZAKvgU8SZHODBA= X-Google-Smtp-Source: ABdhPJyIj3P6fpF/0qmAUfawf0o0XsfWLzD5JKOpdAuOCrzjMgk8YxK3MYQEhlUfVlIguSIAJNAP7w== X-Received: by 2002:adf:ce0b:: with SMTP id p11mr3615781wrn.318.1604590409101; Thu, 05 Nov 2020 07:33:29 -0800 (PST) Received: from buildpc ([93.188.44.203]) by smtp.gmail.com with ESMTPSA id g14sm3128880wrx.22.2020.11.05.07.33.26 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 05 Nov 2020 07:33:27 -0800 (PST) From: "Valery Smyslov" To: "'tom petch'" , "'Tero Kivinen'" , "'Roman Danyliw'" Cc: "'Fernando Pereniguez-Garcia'" , , "'Gabriel Lopez'" , , , , "'Rafa Marin-Lopez'" References: <160337357077.29083.9236626834026808055@ietfa.amsl.com> <5F9815D1.9010303@btconnect.com> <5F99B221.3040504@btconnect.com> <56155C91-BFE8-4BA9-A55C-46B12E59CD94@um.es> <5F9AEFD3.90903@btconnect.com> <059aaae84a354411ad1023afa2a837ba@cert.org> <5F9BF578.6000101@btconnect.com> <834a668ac559460a9f356bbb6c16b8fd@cert.org> <24476.38596.868667.906930@fireball.acr.fi> <5F9D62C0.5030908@btconnect.com> <000001d6af8e$43baa2d0$cb2fe870$@gmail.com> <5FA14709.6080903@btconnect.com> In-Reply-To: <5FA14709.6080903@btconnect.com> Date: Thu, 5 Nov 2020 18:33:19 +0300 Message-ID: <009901d6b388$fdb303a0$f9190ae0$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Content-Language: ru Thread-Index: AQIoWC6Ry6044q/zCrCUKcB+KBw60wJiaB/IAqnvI9sBjCP/TgJL0fDJAoEYK+kB00mNbgLfgwdiAuAT4rcCA2fXuQGCTHRUAkPcMRwB9tjBpQID2bNrqC/q+fA= Archived-At: Subject: Re: [IPsec] [I2nsf] [Last-Call] New Version Notification for draft-ietf-i2nsf-sdn-ipsec-flow-protection-11.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Nov 2020 15:33:48 -0000 Hi Tom, > > we discussed with the chairs the usefulness of adding "Recommended/Not > > recommended" column > > (as TLS WG did) into the IKEv2 algorithm registries back in 2018 in Bangkok > > and I was one who > > of those who initially suggested this. However, Tero made a very good point > > that > > IANA doesn't have any public history. So, in the ipsecme WG another approach > > was taken - we have RFCs that say which algorithms are recommended/not > > recommended > > for ESP and for IKEv2 and these RFCs are updated periodically. > > > >> Thanks for getting back to me. What is missing from the IANA registry > >> is the guidance as to the status of the algorithm, how highly it is > >> recommended or not. This I-D tells people to go to RFC8247 and the IANA > >> Registry for advice; RFC8247 gives that advice; the IANA web page does > > not. > > > > As Tero said, the IANA web page references current RFCs (8221 & 8247 at the > > moment) > > that list recommended algorithms. Just one more level of indirection. All > > algorithms that are not listed > > in these RFC are treated as "not recommended" by default, including newly > > added algorithms. > > > >> And RFC8247 specifies which algorithm are AEAD, the web page does not. > >> The YANG module behaves differently depending on whether or not the > >> algorithm is AEAD; YANG implementors need to know, having this > >> information on the web page would make it easier for YANG implementors. > > > > Is is a problem to open corresponding RFC or I-D? Or do you want to say that > > > > YANG implementers don't need any other information about algorithms > > except whether it's AEAD and whether it's recommended? > > Valery > > The problem I see is where to direct readers of the i2nsf-sdn to for > more information, about which algorithms are recommended, or not, and, a > secondary consideration, whether they are AEAD or not, since the latter > affects the YANG module. The I-D has lots of references to RFC7296 and > that RFC is very clear - for up-to-date information go to IANA. The RFC > that update RFC7296 do not appear to update that advice. And the i2nsf > I-D also contains references to IANA often alongside a reference to an > RFC. You seem to be saying that IANA is only a good reference if it > points to an RFC that says so which may not match the expectations of > users (particularly those who are familiar with the approach of the TLS > WG). If they are pointed to IANA they may well expect IANA to be the > best source of information but you seem to be saying that the WG decided > not to support that, rather expecting people to read the RFC. If IANA > said 'use this to find the RFC but do not otherwise trust this > information' that would be fine, well in a manner of speaking:-) > > So, question. What references should draft i2nsf-sdn point readers to > for up-to-date information on algorithms (assuming that they do not > track the IETF WG that updates information on IKEv2 ie like me)? > Currently that is both a reference to the IANA registry and to an RFC; > is that your best advice? I believe a reference to IANA suffices. Note, that IANA algorithms registries have notes referencing RFCs with up-to-date information about algorithms status. E.g. for encryption algorithms the following note appears in the registry: Note To find out requirement levels for encryption algorithms for ESP, see [RFC8221]. For IKEv2, see [RFC8247]. > Were I an author of this I-D, as opposed to a reader thereof, then based > on what you say I would remove references to the IANA website or at > least qualify them with some statement that they need to check the RFC > for current information! IANA website has already contained this statement and references the most recent RFCs for IKEv2 and for ESP containing algorithms requirement levels. > What would you advise? As I've already said, I believe sole reference to IANA webpage is enough for careful reader, because IANA has notes mentioned above with references to up-to-date RFCs describing current algorithms status. However, I think that referencing both RFCs and IANA in the I-D won't hurt anyway. Whether algorithms are AEAD or not is different thing. Currently this information is missing on the IANA webpage, so one must look into the each algorithm specification to learn it... Regards, Valery. > Tom Petch > > > > > Regards, > > Valery Smyslov. > > > >> And RFC8247 specifies IoT, which I do not think is yet a consideration > > here. > >> > >> As I said, we are currently ok but as new algorithms get added, by > >> Expert Review, then that information is needed and may not be available > >> as there is no requirement for the Expert Reviewer to make it available. > >> > >> As I said to Roman, the TLS WG found that they needed to add extra > >> columns to their web pages of algorithms. Different columns (e.g. DTLS > >> not AEAD) but I think that the situation is otherwise identical so I am > >> anticipating that in a year or two you will see what I mean:-). In > >> passing, the TLS WG determine by consensus what the status is for a new > >> algorithm but the Expert Reviewer makes it available via the web site > >> whether or not it is in an RFC. > >> > >> I take your point about duplicating data - no relational databases here! > >> - but the answer is to specify which is authoritative and for me that > >> should be the IANA pages as it is for many assignments in the context of > >> YANG and before that SMI going back decades. > >> > >> Tom Petch > >> From nobody Sat Nov 7 04:16:32 2020 Return-Path: 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 9BCC03A00D8; Sat, 7 Nov 2020 04:16:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, MSGID_FROM_MTA_HEADER=0.001, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=btconnect.onmicrosoft.com 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 3uORm1IqESYq; Sat, 7 Nov 2020 04:16:24 -0800 (PST) Received: from EUR05-AM6-obe.outbound.protection.outlook.com (mail-am6eur05on2132.outbound.protection.outlook.com [40.107.22.132]) (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 4CD613A00D2; Sat, 7 Nov 2020 04:16:22 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=XF4HBIGvoPbKAkrWmqQo3uElNPbhpPiH5IAzCGAokPl90em62OyDSv69/bNODWT9dHzlu0Lp1OcAu2ipG58W2AVFOeHWvM/45v58VPl6EVsxRhbr4jX4wkz50A+3RoYSAS/xPPWyMDPoNmn3P56o3D/gTbjcr1ajSrfF/v0XQ+ateh9LEYX0qQODXJ324ombIICWS1h6IyOhzQAKQ7IyZl+CYv82wXzL44OZ6GGBzgYClRLLGZ4NGjjIcPaflLvzPFWbeeCLpb9g5lCWDXC1XWc+NWBjPrcSBLK4A+5LYpDAzm+M5CZbuw9BI0XTKLjLwZuYbwZ5XwfNL0X0Zy+Hqw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=OYgRHXcVK5vBmFvb24Lnv7uNWkDp1ibHw53XQxR5S3o=; b=MX4cldf2AVSSjQ7++6OuszPfPj1kOGVC+0J53mTvR1+r1Np3cWjw7/x8FOcGcJ8kS6HBAjboWgEGmoA6nUavFK25+BMDr8b8Z5uKXIBjWIn2ERm3sDYAqe2lN0FjHbN0dDyBE6c1N7KHDSaSKKlvXCbHNW6NnCnWM2e8AbPzhXvnXNoV8H6RNgjWb8e3kGL6/aLpeOYykgyH80hemwdwWZ1wimbiWQtc0/3NC7NGzznCx+gjIDwpt8hdj9W08yIPBPRtCohRWQMOlMY8VXYdEozPL0qHNbcrURk27IrUAwlO0wp6FwsYypbd4psGpwTunEZJhD+ga5YOblnvIAYuMQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=btconnect.com; dmarc=pass action=none header.from=btconnect.com; dkim=pass header.d=btconnect.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btconnect.onmicrosoft.com; s=selector2-btconnect-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=OYgRHXcVK5vBmFvb24Lnv7uNWkDp1ibHw53XQxR5S3o=; b=lUkWu6CQsIQV5Byd6GWNVll4bk0YLlPMtLmAFoVsDvMLYtQdd6D+Nk1J7dtr3l8VQDLejaBppe5sk2D/2zbE7mXhqs0nsrWewubw46BOzkckcOlrR6MCkMINJQ/+BPXfVBdd6RO91iziCYoEakZ5dKAumWKVDYcapiYVcK00Jd8= Authentication-Results: um.es; dkim=none (message not signed) header.d=none;um.es; dmarc=none action=none header.from=btconnect.com; Received: from VI1PR07MB6704.eurprd07.prod.outlook.com (2603:10a6:800:18b::8) by VI1PR07MB6382.eurprd07.prod.outlook.com (2603:10a6:800:137::24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3541.10; Sat, 7 Nov 2020 12:16:20 +0000 Received: from VI1PR07MB6704.eurprd07.prod.outlook.com ([fe80::6407:6ea2:f517:eeae]) by VI1PR07MB6704.eurprd07.prod.outlook.com ([fe80::6407:6ea2:f517:eeae%7]) with mapi id 15.20.3564.013; Sat, 7 Nov 2020 12:16:20 +0000 To: Valery Smyslov References: <160337357077.29083.9236626834026808055@ietfa.amsl.com> <5F9815D1.9010303@btconnect.com> <5F99B221.3040504@btconnect.com> <56155C91-BFE8-4BA9-A55C-46B12E59CD94@um.es> <5F9AEFD3.90903@btconnect.com> <059aaae84a354411ad1023afa2a837ba@cert.org> <5F9BF578.6000101@btconnect.com> <834a668ac559460a9f356bbb6c16b8fd@cert.org> <24476.38596.868667.906930@fireball.acr.fi> <5F9D62C0.5030908@btconnect.com> <000001d6af8e$43baa2d0$cb2fe870$@gmail.com> <5FA14709.6080903@btconnect.com> <009901d6b388$fdb303a0$f9190ae0$@gmail.com> Cc: 'Fernando Pereniguez-Garcia' , i2nsf@ietf.org, 'Gabriel Lopez' , ipsec@ietf.org, last-call@ietf.org, 'Rafa Marin-Lopez' From: tom petch Message-ID: <5FA6900F.7060702@btconnect.com> Date: Sat, 7 Nov 2020 12:16:15 +0000 User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 In-Reply-To: <009901d6b388$fdb303a0$f9190ae0$@gmail.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [86.146.121.140] X-ClientProxiedBy: LNXP123CA0006.GBRP123.PROD.OUTLOOK.COM (2603:10a6:600:d2::18) To VI1PR07MB6704.eurprd07.prod.outlook.com (2603:10a6:800:18b::8) MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from [192.168.1.65] (86.146.121.140) by LNXP123CA0006.GBRP123.PROD.OUTLOOK.COM (2603:10a6:600:d2::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.20.3541.21 via Frontend Transport; Sat, 7 Nov 2020 12:16:19 +0000 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: e5882f4c-be03-49b0-99f7-08d88316ef21 X-MS-TrafficTypeDiagnostic: VI1PR07MB6382: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:10000; X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: 3KQmrTE7DXrzfmG7WMUk0dQp9jipPSS9lfr4nMlSVvYlSbf1z24gcMtG2Zt5QNmm6FztcaTqwda+/nKXjDBbnH7TJCQvsyTikXRIPz76fDLpFjz+dhquK9eGAHkQLq6K8RMCNqLjjtbxYQC9NudMa5wXu8XS83jbNC7LE7OMwdhP+YCbXrjHXH3OzVMBS++JgK6LnRDsUZ0esm7bNzxLdWjqKopofMRXQ51NSBXQPnDxZSqfDISRjrwCExr5mXLLkidR7x5JPAaUY6iRv+/hiFT7TERWpblvtaUYjfNxzxcxB54Merm/as7N6Q8G6cWKJsP+Vzyt8caH4AGKoSfANg== X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:VI1PR07MB6704.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFS:(376002)(136003)(39860400002)(366004)(346002)(396003)(16576012)(26005)(66476007)(86362001)(53546011)(2906002)(6916009)(6666004)(316002)(8676002)(186003)(36756003)(956004)(54906003)(66556008)(15650500001)(4326008)(2616005)(83380400001)(52116002)(33656002)(478600001)(8936002)(5660300002)(6486002)(87266011)(16526019)(66946007); DIR:OUT; SFP:1102; X-MS-Exchange-AntiSpam-MessageData: 9AIPkIFOeU2DBWXfN9Y0zSic+8OaStEXmkParJBGSegq9K3bXi+Idtse79hs6/OrfeUWOKd6a8HFOdSat7hfqYcV0r7u5p3aVI0rTA33aK5Hpm1u8LvdRXb9RvwQLqUFgqVjq9/KudqtRPUqV/GmP8HRsq+rkXhwSJ6Q7epGAFmF8cNlVMRlWJbqNJ0VArDIpJ1CqmW96AJ3V07TocwKIj6+N/lIhu3kFstxveYxH0uX0fqXgoABfvG/S+q0SV3WfvSHpP1sNKfA5BwSBHCFoWipJYRImfTQndRv/IfiN571cCJQBzVzOZWBJpP42Hifv22z+zWbEpm4GPd/z26hDSHPzcpu3dc98egMOTDESqH917QgvmxCYYmsYTqp/1/t9IXQW2aVmiAgfDO1F+Yc5+bXbLmyv1IlDNLarYaBK1xUqPZ1CY/m/tBalMYqLs5botEnbGrXSgxqgGDh9dfVPDQvrm6WX+O4BlpIQaPPlOlTZe92xAZLim3IRe7ihH81S7QFiIuSxzpo8e39M5JCHp5e59hqxU/6Ucq2V44Mnyx4Kc6FcjpLlZz64Nhw7qXjeEk99wF53KuTz52Bm8q1WuFNb42/gRp+URa/h6WQOXod/4LV+aDcxwRJjIMNZmJ0V+QC7KL1MYygmmeHuxgtVA== X-OriginatorOrg: btconnect.com X-MS-Exchange-CrossTenant-Network-Message-Id: e5882f4c-be03-49b0-99f7-08d88316ef21 X-MS-Exchange-CrossTenant-AuthSource: VI1PR07MB6704.eurprd07.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 07 Nov 2020 12:16:20.2976 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: cf8853ed-96e5-465b-9185-806bfe185e30 X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: 9ITD49qMt0rKSNAi+38mQHZqxU4zq5B4SokSDd+7ciCCQUoV7uFbB68O0tRcAjpMKnFd9ZnPPH1u917VIUdMZg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR07MB6382 Archived-At: Subject: Re: [IPsec] [I2nsf] [Last-Call] New Version Notification for draft-ietf-i2nsf-sdn-ipsec-flow-protection-11.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Nov 2020 12:16:27 -0000 On 05/11/2020 15:33, Valery Smyslov wrote: > Hi Tom, > >>> we discussed with the chairs the usefulness of adding "Recommended/Not >>> recommended" column >>> (as TLS WG did) into the IKEv2 algorithm registries back in 2018 in Bangkok >>> and I was one who >>> of those who initially suggested this. However, Tero made a very good point >>> that >>> IANA doesn't have any public history. So, in the ipsecme WG another approach >>> was taken - we have RFCs that say which algorithms are recommended/not >>> recommended >>> for ESP and for IKEv2 and these RFCs are updated periodically. >>> >>>> Thanks for getting back to me. What is missing from the IANA registry >>>> is the guidance as to the status of the algorithm, how highly it is >>>> recommended or not. This I-D tells people to go to RFC8247 and the IANA >>>> Registry for advice; RFC8247 gives that advice; the IANA web page does >>> not. >>> >>> As Tero said, the IANA web page references current RFCs (8221 & 8247 at the >>> moment) >>> that list recommended algorithms. Just one more level of indirection. All >>> algorithms that are not listed >>> in these RFC are treated as "not recommended" by default, including newly >>> added algorithms. >>> >>>> And RFC8247 specifies which algorithm are AEAD, the web page does not. >>>> The YANG module behaves differently depending on whether or not the >>>> algorithm is AEAD; YANG implementors need to know, having this >>>> information on the web page would make it easier for YANG implementors. >>> >>> Is is a problem to open corresponding RFC or I-D? Or do you want to say that >>> >>> YANG implementers don't need any other information about algorithms >>> except whether it's AEAD and whether it's recommended? >> >> Valery >> >> The problem I see is where to direct readers of the i2nsf-sdn to for >> more information, about which algorithms are recommended, or not, and, a >> secondary consideration, whether they are AEAD or not, since the latter >> affects the YANG module. The I-D has lots of references to RFC7296 and >> that RFC is very clear - for up-to-date information go to IANA. The RFC >> that update RFC7296 do not appear to update that advice. And the i2nsf >> I-D also contains references to IANA often alongside a reference to an >> RFC. You seem to be saying that IANA is only a good reference if it >> points to an RFC that says so which may not match the expectations of >> users (particularly those who are familiar with the approach of the TLS >> WG). If they are pointed to IANA they may well expect IANA to be the >> best source of information but you seem to be saying that the WG decided >> not to support that, rather expecting people to read the RFC. If IANA >> said 'use this to find the RFC but do not otherwise trust this >> information' that would be fine, well in a manner of speaking:-) >> >> So, question. What references should draft i2nsf-sdn point readers to >> for up-to-date information on algorithms (assuming that they do not >> track the IETF WG that updates information on IKEv2 ie like me)? >> Currently that is both a reference to the IANA registry and to an RFC; >> is that your best advice? > > I believe a reference to IANA suffices. Note, that IANA algorithms registries have > notes referencing RFCs with up-to-date information about algorithms status. > E.g. for encryption algorithms the following note appears in the registry: > > Note > To find out requirement levels for encryption algorithms for > ESP, see [RFC8221]. For IKEv2, see [RFC8247]. > >> Were I an author of this I-D, as opposed to a reader thereof, then based >> on what you say I would remove references to the IANA website or at >> least qualify them with some statement that they need to check the RFC >> for current information! > > IANA website has already contained this statement and references the most recent > RFCs for IKEv2 and for ESP containing algorithms requirement levels. > >> What would you advise? > > As I've already said, I believe sole reference to IANA webpage is enough > for careful reader, because IANA has notes mentioned above with > references to up-to-date RFCs describing current algorithms status. > However, I think that referencing both RFCs and IANA in the I-D won't hurt anyway. > > Whether algorithms are AEAD or not is different thing. Currently this information > is missing on the IANA webpage, so one must look into the each algorithm > specification to learn it... Valery Thank you for your thoughts on this. As you will know, the IESG are now commenting on this I-D and my experience is that, once that has started, then that takes over the discussion so having got the topic aired, albeit not necessarily to a conclusion incorporated in the I-D, I will leave it up to the IESG to decide what should or should not be included in the YANG module. I will keep the outcome of this discussion in my mind as and when the topic comes up again. As you may gather, I follow the TLS WG and so am familiar with the approach that it has taken (likewise that of SSH) but do not track the work on IKEv2 - I did not even know which WG was responsible for it:-( Tom Petch > Regards, > Valery. > >> Tom Petch >> >>> >>> Regards, >>> Valery Smyslov. >>> >>>> And RFC8247 specifies IoT, which I do not think is yet a consideration >>> here. >>>> >>>> As I said, we are currently ok but as new algorithms get added, by >>>> Expert Review, then that information is needed and may not be available >>>> as there is no requirement for the Expert Reviewer to make it available. >>>> >>>> As I said to Roman, the TLS WG found that they needed to add extra >>>> columns to their web pages of algorithms. Different columns (e.g. DTLS >>>> not AEAD) but I think that the situation is otherwise identical so I am >>>> anticipating that in a year or two you will see what I mean:-). In >>>> passing, the TLS WG determine by consensus what the status is for a new >>>> algorithm but the Expert Reviewer makes it available via the web site >>>> whether or not it is in an RFC. >>>> >>>> I take your point about duplicating data - no relational databases here! >>>> - but the answer is to specify which is authoritative and for me that >>>> should be the IANA pages as it is for many assignments in the context of >>>> YANG and before that SMI going back decades. >>>> >>>> Tom Petch >>>> > > . > From nobody Tue Nov 10 10:01:16 2020 Return-Path: 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 5975F3A0DEA; Tue, 10 Nov 2020 10:01:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, 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 BnPf5av5Q6hK; Tue, 10 Nov 2020 10:01:12 -0800 (PST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (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 AA3F93A1391; Tue, 10 Nov 2020 09:59:48 -0800 (PST) Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 0AAHxdQW026602 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 10 Nov 2020 12:59:45 -0500 Date: Tue, 10 Nov 2020 09:59:39 -0800 From: Benjamin Kaduk To: mohamed.boucadair@orange.com Cc: "draft-ietf-ipsecme-ipv6-ipv4-codes.all@ietf.org" , "ipsec@ietf.org" Message-ID: <20201110175939.GK39170@kduck.mit.edu> References: <20201020195628.GP39170@kduck.mit.edu> <29839_1603269065_5F8FF1C9_29839_37_11_787AE7BB302AE849A7480A190F8B9330315642A2@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <29839_1603269065_5F8FF1C9_29839_37_11_787AE7BB302AE849A7480A190F8B9330315642A2@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> Archived-At: Subject: Re: [IPsec] AD review of draft-ietf-ipsecme-ipv6-ipv4-codes-04 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Nov 2020 18:01:15 -0000 Thanks, Med. I requested the IETF LC. -Ben On Wed, Oct 21, 2020 at 08:31:04AM +0000, mohamed.boucadair@orange.com wrote: > Hi Ben, > > Thank you for the review. > > An updated version is available at: https://tools.ietf.org/html/draft-ietf-ipsecme-ipv6-ipv4-codes-05. > > Please see inline. > > Cheers, > Med > > > -----Message d'origine----- > > De: Benjamin Kaduk [mailto:kaduk@mit.edu] > > Envoy: mardi 20 octobre 2020 21:56 > > : draft-ietf-ipsecme-ipv6-ipv4-codes.all@ietf.org > > Cc: ipsec@ietf.org > > Objet: AD review of draft-ietf-ipsecme-ipv6-ipv4-codes-04 > > > > Hi Med, > > > > Not a whole lot to comment on here, but probably we should publish a > > new revisionn to tidy things up before asking for IETF LC. > > > > Thanks, > > > > Ben > > > > %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% > > % > > > > We use the term "dual-stack" several times but it is not defined > > explicitly. While this is certainly a common and fairly well-known > > concept, perhaps we should drop an "IPv6/IPv4" in somewhere (or add > > a reference? I'm not sure what reference would be good, offhand). > > [Med] Added text to explain this. > > > > > There seem to be a few places where we use the phrase "status type" > > without preceding "notification"; would it make sense to normalize > > the language around "notification status type"? > > [Med] Agree. Fixed. > > > > > Section 3 > > > > Section 3.15.4 of [RFC7296] defines a generic notification error > > type > > that is related to a failure to handle an address assignment > > request. > > That error type does not explicitly allow an initiator to > > determine > > why a given address family is not assigned, nor whether it should > > try > > using another address family. INTERNAL_ADDRESS_FAILURE is a > > catch- > > all error type when an address-related issue is encountered by an > > IKEv2 responder. > > > > INTERNAL_ADDRESS_FAILURE does not provide sufficient hints to the > > IKEv2 initiator to adjust its behavior. > > > > I feel like we might also want to mention that (per 7296), "[t]he > > responder sends INTERNAL_ADDRESS_FAILURE only if no addresses can be > > assigned", and in many of the indicated use cases, the responder can > > successfully assign *one* address, just not the full requested set, > > so INTERNAL_ADDRESS_FAILURE is explicitly not useful. > > > > [Med] Tweaked that part to include the text you quoted. The explanation text covers this case as well. > > > Section 5 > > > > If the initiator is dual-stack, it MUST include both address > > families > > in its request (absent explicit policy/configuration otherwise). > > > > By "both address families" we mean "both the IP6_ALLOWED and > > IP4_ALLOWED notification status types"? Or are we talking about > > something else, like a configuration payload? > > [Med] This is typically INTERNAL_IP4_ADDRESS and INTERNAL_IP6_ADDRESS attributes. The attributes are not listed as I would like to cover (the experimental attribute) INTERNAL_IP6_PREFIX (or future attributes to achieve the same functionality). > > Updated the text to point to Section 3.15 of 7296. > > > > > It is perhaps surprising that we only impose the requirement for the > > initiator to send these notifications specifically on dual-stack > > initiators; a generic protocol update might typically impose a > > requirement to always send your capabilities, whether dual-stack or > > single-stack. > > [Med] These notifications are not sent by the initiator. The default behaviour for a dual-stack initiator is to request both IPv4 and IPv6 connectivity. This behaviour can be restricted by policy. In such case, the initiator will only request the connectivity that adheres to its local policy (e.g., IPv6-only). > > In particular, the table seems to imply that the > > initiator will still send something to indicate the requested AF in > > the single-requested-AF case (which need not be dual-stack); is this > > something other than IP_ALLOWED? > > [Med] Yes. This is inferred from the INTERNAL_* attributes listed above. Added NEW text to make this clear. > > > > > If the initiator only receives one single notification > > IP4_ALLOWED or > > IP6_ALLOWED from the responder, the initiator MUST NOT send a > > request > > for an alternate address family not supported by the responder. > > > > What is the scope of this "MUST NOT"? Other CREATE_CHILD_SA on the > > same parent IKE SA? > > [Med] Yes. Made this change: s/request/subsequent request. > > Ever to the same responder? > > > > If a dual-stack initiator requests only an IPv6 prefix (or an > > IPv4 > > address) but only receives IP4_ALLOWED (or IP6_ALLOWED) > > notification > > status type from the responder, the initiator MUST send a request > > for > > IPv4 address(es) (or IPv6 prefix(es)). > > > > [related to the earlier comment about only requiring dual-stack > > initiators to send, at the start of the section we said that a dual- > > stack initiator MUST include both address families...] > > [Med] This is about covering the case where a policy is provided and the default behaviour is not followed. > > > > > Section 6 > > > > I think a phrasing like "since the IPv4/IPv6 capabilities of a node > > are readily determined from the traffic it generates, this document > > does not introduce any new security considerations compared to the > > ones described in [RFC7296], which continue to apply" might be more > > conventional. (I don't object to the current phrasing, though.) > > [Med] I prefer yours. Fixed. Thanks. > > > _________________________________________________________________________________________________________________________ > > Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. > > This message and its attachments may contain confidential or privileged information that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and delete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. > Thank you. > From nobody Tue Nov 10 10:45:26 2020 Return-Path: X-Original-To: ipsec@ietf.org Delivered-To: ipsec@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B4B63A0E3A; Tue, 10 Nov 2020 10:45:20 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 7.22.0 Auto-Submitted: auto-generated Precedence: bulk CC: draft-ietf-ipsecme-ipv6-ipv4-codes@ietf.org, Yoav Nir , David Waltermire , kaduk@mit.edu, ynir.ietf@gmail.com, ipsec@ietf.org, ipsecme-chairs@ietf.org Reply-To: last-call@ietf.org Sender: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-ID: <160503392041.25492.3053265355753598319@ietfa.amsl.com> Date: Tue, 10 Nov 2020 10:45:20 -0800 Archived-At: Subject: [IPsec] Last Call: (IKEv2 Notification Status Types for IPv4/IPv6 Coexistence) to Proposed Standard X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Nov 2020 18:45:21 -0000 The IESG has received a request from the IP Security Maintenance and Extensions WG (ipsecme) to consider the following document: - 'IKEv2 Notification Status Types for IPv4/IPv6 Coexistence' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the last-call@ietf.org mailing lists by 2020-12-01. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document specifies new IKEv2 notification status types to better manage IPv4 and IPv6 co-existence. This document updates RFC7296. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-ipsecme-ipv6-ipv4-codes/ No IPR declarations have been submitted directly on this I-D. From nobody Tue Nov 10 11:30:12 2020 Return-Path: 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 B1B663A0E9F for ; Tue, 10 Nov 2020 11:30:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham 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 MCYJIE8pDZAa for ; Tue, 10 Nov 2020 11:30:09 -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 39BC23A0E9D for ; Tue, 10 Nov 2020 11:30:08 -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) by meesny.iki.fi (Postfix) with ESMTPSA id 5AB0A2054E for ; Tue, 10 Nov 2020 21:30:04 +0200 (EET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=iki.fi; s=meesny; t=1605036604; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=6Pgq79sCmxuyYOBPgFPN2roBCF/RePpR1Yhnl77mAZE=; b=EVVr+4S81NLLiUjisVMjzbhEcnNf6GTzSUrjU0eQq6voGyPXOKTF0IajfspUBG+nrp2fyK Q1TGyolQ8SCG5Dpt5Jf8L/vNwncR7+dkOR170s2RMMVhED6cRuggFWLDdCgxg9fg1GVRab walLdXv9QuFAcfpYNgIh8QmlZzBpGQM= Received: by fireball.acr.fi (Postfix, from userid 15204) id A25E425C10E7; Tue, 10 Nov 2020 21:30:03 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-ID: <24490.59963.611371.225173@fireball.acr.fi> Date: Tue, 10 Nov 2020 21:30:03 +0200 From: Tero Kivinen To: ipsec@ietf.org X-Mailer: VM 8.2.0b under 26.3 (x86_64--netbsd) X-Edit-Time: 4 min X-Total-Time: 5 min ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=iki.fi; s=meesny; t=1605036604; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=6Pgq79sCmxuyYOBPgFPN2roBCF/RePpR1Yhnl77mAZE=; b=F+aB8hOh7Hp1lFiXSYXbAuBMYiOPjDa6YQf25qFRcu/mjepIXomidGr53/rXwhB4lmHkao XAvem0Jq0W9p4tntZTNAWPwDf8UBB6p8FdGT3cD2cIEay1PXZYU2fNanuRzwFw6/USEj13 9MW0byjChUQZOgzlPtXUaECpn8ACHS0= ARC-Authentication-Results: i=1; ORIGINATING; auth=pass smtp.auth=kivinen smtp.mailfrom=kivinen@iki.fi ARC-Seal: i=1; s=meesny; d=iki.fi; t=1605036604; a=rsa-sha256; cv=none; b=IX8QQa2nhatQVxBGHhkbj4V+tyLCs1rHGaen6Xkg9s5n7963EQnnAtEjMZc+VytdDzfTKy XhqocHW/PaECUhVA2Unp2wDIuVmqHDiOliAAVXlHm6iRCtFDYoe1vqsHubLRxfMz+BIOx4 9YNdp9DIyX4JTxF+a8J9jtP5J01gdog= Archived-At: Subject: [IPsec] Agenda for IETF 109 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Nov 2020 19:30:12 -0000 I have received three presentation requests for the IETF 109, so the agenda for the IPsecME meeting currently looks like this: ---------------------------------------------------------------------- - Note Well, technical difficulties and agenda bashing =E2=80=93=20 Chairs (5 min) - Document Status =E2=80=93 Chairs (5 min) - New Items - Beyond 64KB limit of IKEv2 Payload =E2=80=93 =20 Valery Smyslov - IKEv2 Configuration for Encrypted DNS =E2=80=93 =20 Valery Smyslov - Revised Cookie Processing in IKEv2 =E2=80=93 =20 Valery Smyslov - AOB + Open Mic ---------------------------------------------------------------------- If anybody has any other presentations they want to present during the IETF 109 IPsecME meeting, send note to chairs as soon as possible.=20 --=20 kivinen@iki.fi From nobody Sat Nov 14 13:33:06 2020 Return-Path: X-Original-To: ipsec@ietf.org Delivered-To: ipsec@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A8F63A1347; Sat, 14 Nov 2020 13:32:59 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Robert Sparks via Datatracker To: Cc: draft-ietf-ipsecme-ipv6-ipv4-codes.all@ietf.org, last-call@ietf.org, ipsec@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.22.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <160538957906.19443.17896302093639658374@ietfa.amsl.com> Reply-To: Robert Sparks Date: Sat, 14 Nov 2020 13:32:59 -0800 Archived-At: Subject: [IPsec] Genart last call review of draft-ietf-ipsecme-ipv6-ipv4-codes-05 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Nov 2020 21:32:59 -0000 Reviewer: Robert Sparks Review result: Ready I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at . Document: draft-ietf-ipsecme-ipv6-ipv4-codes-05 Reviewer: Robert Sparks Review Date: 2020-11-14 IETF LC End Date: 2020-12-01 IESG Telechat date: Not scheduled for a telechat Summary: Ready for publication as a Proposed Standard RFC From nobody Sun Nov 15 11:56:36 2020 Return-Path: X-Original-To: ipsec@ietf.org Delivered-To: ipsec@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D21243A09B5; Sun, 15 Nov 2020 11:56:34 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: ipsec@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.22.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: ipsec@ietf.org Message-ID: <160547019481.27927.17405680714876309494@ietfa.amsl.com> Date: Sun, 15 Nov 2020 11:56:34 -0800 Archived-At: Subject: [IPsec] I-D Action: draft-ietf-ipsecme-iptfs-03.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Nov 2020 19:56:35 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Maintenance and Extensions WG of the IETF. Title : IP Traffic Flow Security Author : Christian Hopps Filename : draft-ietf-ipsecme-iptfs-03.txt Pages : 27 Date : 2020-11-15 Abstract: This document describes a mechanism to enhance IPsec traffic flow security by adding traffic flow confidentiality to encrypted IP encapsulated traffic. Traffic flow confidentiality is provided by obscuring the size and frequency of IP traffic using a fixed-sized, constant-send-rate IPsec tunnel. The solution allows for congestion control as well as non-constant send-rate usage. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ipsecme-iptfs/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-ipsecme-iptfs-03 https://datatracker.ietf.org/doc/html/draft-ietf-ipsecme-iptfs-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ipsecme-iptfs-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Nov 17 10:46:35 2020 Return-Path: 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 BBF4F3A1540 for ; Tue, 17 Nov 2020 10:46:33 -0800 (PST) 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, 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 bwClgPSWskME for ; Tue, 17 Nov 2020 10:46:32 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5AB5D3A153F for ; Tue, 17 Nov 2020 10:46:32 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 11715F40741; Tue, 17 Nov 2020 10:46:21 -0800 (PST) To: ynir.ietf@gmail.com, simon@josefsson.org, rdd@cert.org, kaduk@mit.edu, kivinen@iki.fi, ynir.ietf@gmail.com X-PHP-Originating-Script: 30:errata_mail_lib.php From: RFC Errata System Cc: christian.tschudin@unibas.ch, ipsec@ietf.org, rfc-editor@rfc-editor.org Content-Type: text/plain; charset=UTF-8 Message-Id: <20201117184621.11715F40741@rfc-editor.org> Date: Tue, 17 Nov 2020 10:46:21 -0800 (PST) Archived-At: Subject: [IPsec] [Technical Errata Reported] RFC8031 (6339) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Nov 2020 18:46:34 -0000 The following errata report has been submitted for RFC8031, "Curve25519 and Curve448 for the Internet Key Exchange Protocol Version 2 (IKEv2) Key Agreement". -------------------------------------- You may review the report below and at: https://www.rfc-editor.org/errata/eid6339 -------------------------------------- Type: Technical Reported by: Christian Tschudin Section: Appendix A Original Text ------------- The public keys are generated from this using the formula in Section 2: pub_i = X25519(d_i, G) = 48 d5 dd d4 06 12 57 ba 16 6f a3 f9 bb db 74 f1 a4 e8 1c 08 93 84 fa 77 f7 90 70 9f 0d fb c7 66 pub_r = X25519(d_r, G) = 0b e7 c1 f5 aa d8 7d 7e 44 86 62 67 32 98 a4 43 47 8b 85 97 45 17 9e af 56 4c 79 c0 ef 6e ee 25 And this is the value of the Key Exchange Data field in the Key Exchange payload described in Section 3.1. The shared value is calculated as in Section 2: SHARED_SECRET = X25519(d_i, pub_r) = X25519(d_r, pub_i) = c7 49 50 60 7a 12 32 7f-32 04 d9 4b 68 25 bf b0 68 b7 f8 31 9a 9e 37 08-ed 3d 43 ce 81 30 c9 50 Corrected Text -------------- The public keys are generated from this using the formula in Section 2: pub_i = X25519(d_i, G) = a7 07 b3 bc 0f 37 56 fc 0a cf 33 55 85 c5 f7 7b 9f 29 ff a4 24 70 14 af 84 70 5b eb 50 46 26 29 pub_r = X25519(d_r, G) = 0e 57 7e 11 5d 6c 08 59 b8 51 36 d2 1b 1c fd 74 67 9f 91 14 61 1d 79 c6 81 ba d0 8a 7e 1f 0a 04 And this is the value of the Key Exchange Data field in the Key Exchange payload described in Section 3.1. The shared value is calculated as in Section 2: SHARED_SECRET = X25519(d_i, pub_r) = X25519(d_r, pub_i) = d6 8d 8c ea fd 2c d3 ce 25 34 43 33 c8 9e 35 54 9e 0f c6 1a 98 87 39 34 b1 8a 18 70 f0 3a 17 0c Notes ----- The test vector values given both for the public keys and for the shared secret are wrong. It turns out that they were derived from the unchanged random input, instead of d_X. An explanation could be that a first text version did not include the fixing of the random bits and that after inserting the respective paragraph (introducing fixed_X and d_X), it was forgotten to update pub_X and SHARED_SECRET. This discrepancy came to my attention when testing the Yubikey 5 hardware and comparing it with the NaCl library and RFC8031. While the NaCl library works as expected, it is disturbing to see that the Yubikey can only be made to produce the desired (above and corrected) shared secret if you let it compute X25519(fixed_i,pub_r). That is, the secret must be presented to the Yubikey in big-endian format which could be "inspired" by the (not very detailed) Smartcard spec 3.4.1 that refers to ANSI X9.62 where curve parameters, prefixed with 0x04, are encoded in big-endian order - clearly the ANSI encoding is not useful here as we only need one parameter u. I wonder whether RFC8031 should spell out that input parameters (d_X and pub_X) SHOULD be presented in encoded form (and thus little-endian), hence putting manufacturers in charge of documenting any deviation. Instructions: ------------- This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party can log in to change the status and edit the report, if necessary. -------------------------------------- RFC8031 (draft-ietf-ipsecme-safecurves-05) -------------------------------------- Title : Curve25519 and Curve448 for the Internet Key Exchange Protocol Version 2 (IKEv2) Key Agreement Publication Date : December 2016 Author(s) : Y. Nir, S. Josefsson Category : PROPOSED STANDARD Source : IP Security Maintenance and Extensions Area : Security Stream : IETF Verifying Party : IESG From nobody Fri Nov 20 00:40:59 2020 Return-Path: X-Original-To: ipsec@ietf.org Delivered-To: ipsec@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 024803A1A97; Fri, 20 Nov 2020 00:40:59 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Sean Turner via Datatracker To: Cc: last-call@ietf.org, draft-ietf-ipsecme-ipv6-ipv4-codes.all@ietf.org, ipsec@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.23.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <160586165897.15805.9482261922121041926@ietfa.amsl.com> Reply-To: Sean Turner Date: Fri, 20 Nov 2020 00:40:59 -0800 Archived-At: Subject: [IPsec] Secdir last call review of draft-ietf-ipsecme-ipv6-ipv4-codes-05 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Nov 2020 08:40:59 -0000 Reviewer: Sean Turner Review result: Ready looks good to me From nobody Wed Nov 25 05:35:26 2020 Return-Path: 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 A54303A12C6 for ; Wed, 25 Nov 2020 05:35:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=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 01wOIt0ZFfSS for ; Wed, 25 Nov 2020 05:35:24 -0800 (PST) Received: from smtp.chopps.org (smtp.chopps.org [54.88.81.56]) by ietfa.amsl.com (Postfix) with ESMTP id A63AF3A12BE for ; Wed, 25 Nov 2020 05:35:24 -0800 (PST) Received: from [192.168.2.5] (047-050-069-038.biz.spectrum.com [47.50.69.38]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by smtp.chopps.org (Postfix) with ESMTPSA id 1C46261699; Wed, 25 Nov 2020 13:35:23 +0000 (UTC) From: Christian Hopps Content-Type: multipart/signed; boundary="Apple-Mail=_1CDA8F4D-6F10-4D49-A2EF-70F77AB6ACA0"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) Message-Id: Date: Wed, 25 Nov 2020 08:35:23 -0500 Cc: Christian Hopps To: ipsec@ietf.org X-Mailer: Apple Mail (2.3608.120.23.2.4) Archived-At: Subject: [IPsec] Some cosmetic cleanup to IPTFS draft. X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Nov 2020 13:35:26 -0000 --Apple-Mail=_1CDA8F4D-6F10-4D49-A2EF-70F77AB6ACA0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Folks, Valery has indicated in private thread as a pre-WGLC comment, that as = the IP-TFS encapsulation can be used for purposes other than IP-TFS we = should mention that, and rename a couple items so that future derivative = work doesn't seem "hackish". These changes don't change the draft or functionality. Here are the following cosmetic changes Valery and I agreed on: Title would change to: "IP Traffic Flow Security using Aggregation and Fragmentation" ESP type name "IPTFS_PROTOCOL" would change to "AGGFRAG_PROTOCOL" IKEv2 notification name would change from "USE_IPTFS" to "USE_AGGFRAG" An additional short section would be added: ** Non-TFS Uses Other non-TFS uses of the aggregation and fragmentation = encapsulation have been identified, such as increased performance = through packet aggregation, as well as handling MTU issues using = fragmentation. These uses are not defined here, but are also not = restricted by this document. Does anyone have any objections to these changes? Thanks, Chris. --Apple-Mail=_1CDA8F4D-6F10-4D49-A2EF-70F77AB6ACA0 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEm56yH/NF+m1FHa6lLh2DDte4MCUFAl++XZsACgkQLh2DDte4 MCXMow//YF4RLM09ZXSCadxM0rsPDESPidD/GDsKyyJ9XUlCFdOJUjyob1w8VV3k I811soLSWwdrVPvXQwPZHtkbxoAW55i+9YJXjQ2Yf2dmOWjMSp4ZhZ3BABx1CYbt H55r440cF2rjnR8mAz5r5RxA/4B0mRi6dIOyXP36oTaUtMmrUmT4ifnU1tOCsPxo mltSMOdymRMqu6fn38zIJqF/+3T5qjdIQflqkrGL40/rrxHY3KWEX5hGbQFU6RMn RPx8DRfHa5EqatAEROq2fTydGYgGHljskP5DbJG2vZb3S7+UnyWxXUDwaBHyklU9 qySSYuPK4TCSOtAc36PM+W492jx1K3F1UVOJVIBhvpmdK747HYlDLiGtOwjWdkkm ak4GSuu8HUO/mjhT91dMhMeXmK+kzZunbTVyxQE8d87zDUpNeSKKtyHNxabZz2O3 pwcHo/FuQqlPC+19gSYTLJ/v70QCA7lgA6Ou45cbhBFK5yzMv+T8fwlhpek1n+pN 3I5vXI8lP9w49hFcRCZrnK7EtXoGlTc9XWhncBA2n7v6Jnr6BPjhms/LDgzspJwK gRFuvR2vohylJ3+u3QZdXtvk35w4Nh/Y8sm3g8Z2VyX4FZ/iD67PsY9gtD9+EjLf X3d5wJRXyD5pg9+SEyFcMbslh9ageyxF6hgYN8WfHuYpGZp6yJI= =HghJ -----END PGP SIGNATURE----- --Apple-Mail=_1CDA8F4D-6F10-4D49-A2EF-70F77AB6ACA0-- From nobody Wed Nov 25 06:21:47 2020 Return-Path: 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 7BD4F3A0E67 for ; Wed, 25 Nov 2020 06:21:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 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, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca 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 YCikmVL1pTfy for ; Wed, 25 Nov 2020 06:21:42 -0800 (PST) Received: from mx.nohats.ca (mx.nohats.ca [IPv6:2a03:6000:1004:1::68]) (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 D3F3E3A0E3F for ; Wed, 25 Nov 2020 06:21:41 -0800 (PST) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 4Ch33j0dK8zCgW; Wed, 25 Nov 2020 15:21:37 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1606314097; bh=z9kG0JLeWY7+Tj3cvNhNQD88jklAcWIkB0Prp1BJVZs=; h=From:Subject:Date:References:Cc:In-Reply-To:To; b=bOqMgFq/sbkKU2xBlHajmaw1aHN14+gO8snIuZwQOs2hyc9pxBCE5MTzdSQubr5x0 BJ1hpFgLDOpEAT/WWsOWw4xH2V/MNCAFkZQbnefknX9ihxkQlEdx+MKvy6g95qcaWN wCj9KOFvp5exVzOmeJjU9JhIpJH0OcwVyQ7ZlvDQ= X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id Xr6jAG361cpB; Wed, 25 Nov 2020 15:21:36 +0100 (CET) Received: from bofh.nohats.ca (unknown [193.110.157.194]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Wed, 25 Nov 2020 15:21:36 +0100 (CET) Received: from [193.110.157.220] (unknown [193.110.157.220]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)) (No client certificate requested) by bofh.nohats.ca (Postfix) with ESMTPSA id 099986020F26; Wed, 25 Nov 2020 09:21:35 -0500 (EST) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable From: Paul Wouters Mime-Version: 1.0 (1.0) Date: Wed, 25 Nov 2020 09:21:32 -0500 Message-Id: References: Cc: ipsec@ietf.org In-Reply-To: To: Christian Hopps X-Mailer: iPhone Mail (18A8395) Archived-At: Subject: Re: [IPsec] Some cosmetic cleanup to IPTFS draft. X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Nov 2020 14:21:47 -0000 No objection from me although not a great fan of =E2=80=9CAGGFRAG=E2=80=9D := ) Paul Sent from my iPhone > On Nov 25, 2020, at 08:35, Christian Hopps wrote: >=20 > AGGFRAG From nobody Wed Nov 25 06:29:19 2020 Return-Path: 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 CEF423A1449 for ; Wed, 25 Nov 2020 06:29:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.199 X-Spam-Level: X-Spam-Status: No, score=-0.199 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, 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=gmail.com 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 phMZL0BLoYDZ for ; Wed, 25 Nov 2020 06:29:13 -0800 (PST) Received: from mail-lj1-x22c.google.com (mail-lj1-x22c.google.com [IPv6:2a00:1450:4864:20::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 17ADF3A144E for ; Wed, 25 Nov 2020 06:29:13 -0800 (PST) Received: by mail-lj1-x22c.google.com with SMTP id 142so2473112ljj.10 for ; Wed, 25 Nov 2020 06:29:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:thread-index :content-language; bh=zMMS+PvbbMeZB+Mlc82AU6yj71VQiH3Gv78+n0Nk1s4=; b=TUDXd41oRri67p9DRbfhsDyI3o+OL3jZT7N03dXICAqU54PiU2pzq7v3xppIycvLGQ 2mIFj674t4CnH7MZgDgCxU8ZAyZwEDBguwMVbGIR0IOToq/WufIfSPvCX0YfcvcbzLe+ mq7C1kQbEtruB7UrMDq/4B+SuI2crD+H4t88STFsL/kizNnEcNmM6mUQA401+EnAWbvs 6rnCeMidhy4JVziMIaglqd+EUS01up+XnKWGFznOqMsJXKXrvrBjA9y8g1J0Lu2OfRjY OXtY84Ztdb9msizNnfHe0cwa6X16zDAa5jlhhexfWq2ucfw7uaWMl2IzbTLd4zGNgnAT 9CdA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:content-transfer-encoding:thread-index :content-language; bh=zMMS+PvbbMeZB+Mlc82AU6yj71VQiH3Gv78+n0Nk1s4=; b=jrJbYQSIcjpONvcAoR+UXUXbnSb7ZKe86dikGjFT0J8OZbnz/yl+jzPjY2doVi5YES INvE2NxUg70Dudreqb2IHtFomjVT6LZxmAVoOkm5lfJgZJhIrUCD0ekht8vKq8Oaomdf aJmKvl5CJo1ML7ik3SqaffvdbiVhn3YFnIbThktynlcMF9u7p8Pk7jf5NVFHo79xkxiB 66TwAyMf9VJm6lVS8VjdEJHb4BD8z/snvQzVFuq7loMJfYf951EQxtTH2qe3+bt2u4Wd F0zAoizcyWvx1e2wgtoFGpjjj7a/4rHwPYRETFMhi+OCnBktjqK5/mVZO+tw/nIK2UAq 80cw== X-Gm-Message-State: AOAM53119fAAoSTF+VWduf130rWVTJro8cYIGQQesE2374Ai8Jbeh10y g3ZCdJLsB+3aHQiu6h8Wh+0= X-Google-Smtp-Source: ABdhPJzcigbZugFqDcOasM3/4tnWEYPMAZk4o3b4GeaLS8TcYS6/qMOQo709HpSEis4qE6rzo3KtQw== X-Received: by 2002:a2e:3a02:: with SMTP id h2mr1418639lja.137.1606314551043; Wed, 25 Nov 2020 06:29:11 -0800 (PST) Received: from buildpc ([93.188.44.203]) by smtp.gmail.com with ESMTPSA id v1sm276218lfg.252.2020.11.25.06.29.10 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 25 Nov 2020 06:29:10 -0800 (PST) From: "Valery Smyslov" To: "'Paul Wouters'" , "'Christian Hopps'" Cc: References: In-Reply-To: Date: Wed, 25 Nov 2020 17:29:12 +0300 Message-ID: <0e5501d6c337$585b3bc0$0911b340$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHAAovyYH+iFZYCYr3fsu0o/KDX0wJwG3pAqfLnXrA= Content-Language: ru Archived-At: Subject: Re: [IPsec] Some cosmetic cleanup to IPTFS draft. X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Nov 2020 14:29:18 -0000 Hi Paul, > No objection from me although not a great fan of = =E2=80=9CAGGFRAG=E2=80=9D :) Just for clarification: me too. But it serves its purpose :-) Can you suggest better variant? Regards, Valery. > Paul >=20 > Sent from my iPhone >=20 > > On Nov 25, 2020, at 08:35, Christian Hopps = wrote: > > > > AGGFRAG >=20 > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec