From nobody Fri Jun 4 08:48:01 2021 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 BF6243A1710 for ; Fri, 4 Jun 2021 08:47:59 -0700 (PDT) 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_DNSWL_BLOCKED=0.001, 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 ksXiJTCK6GaG for ; Fri, 4 Jun 2021 08:47:57 -0700 (PDT) Received: from smtp.chopps.org (smtp.chopps.org [54.88.81.56]) by ietfa.amsl.com (Postfix) with ESMTP id 1D0DD3A1708 for ; Fri, 4 Jun 2021 08:47:57 -0700 (PDT) Received: from ja.int.chopps.org.chopps.org (047-026-251-217.res.spectrum.com [47.26.251.217]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (2048 bits) server-digest SHA256) (Client did not present a certificate) by smtp.chopps.org (Postfix) with ESMTPSA id 7C16780F45; Fri, 4 Jun 2021 15:47:56 +0000 (UTC) User-agent: mu4e 1.5.13; emacs 27.2 From: Christian Hopps To: ipsec@ietf.org Cc: chopps@chopps.org Date: Fri, 04 Jun 2021 11:46:03 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; format=flowed Archived-At: Subject: [IPsec] iptfs publication request 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: Fri, 04 Jun 2021 15:48:00 -0000 Hi Tero, I understand you have some additional post-WGLC technical comments on the draft. I'm sending this message to start a discussion thread so that the issue can be resolved and we can move forward on the publication request. Thanks, Chris. From nobody Wed Jun 9 05:01:28 2021 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 94BC53A1264 for ; Wed, 9 Jun 2021 05:01:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c6P1ga8o6vdT for ; Wed, 9 Jun 2021 05:01:22 -0700 (PDT) Received: from mailout2.secunet.com (mailout2.secunet.com [62.96.220.49]) (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 1BEAC3A1262 for ; Wed, 9 Jun 2021 05:01:21 -0700 (PDT) Received: from cas-essen-02.secunet.de (unknown [10.53.40.202]) by mailout2.secunet.com (Postfix) with ESMTP id 6DCA580004A; Wed, 9 Jun 2021 14:01:18 +0200 (CEST) Received: from mbx-essen-01.secunet.de (10.53.40.197) by cas-essen-02.secunet.de (10.53.40.202) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2176.2; Wed, 9 Jun 2021 14:01:18 +0200 Received: from moon.secunet.de (172.18.26.122) by mbx-essen-01.secunet.de (10.53.40.197) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2176.2; Wed, 9 Jun 2021 14:01:17 +0200 Date: Wed, 9 Jun 2021 14:01:12 +0200 From: Antony Antony To: "Panwei (William)" CC: "ipsec@ietf.org" Message-ID: <20210609115351.GA24893@moon.secunet.de> Reply-To: References: <32fea92125a040a3831695fa7f1510df@huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: <32fea92125a040a3831695fa7f1510df@huawei.com> Precedence: first-class Priority: normal Organization: secunet User-Agent: Mutt/1.10.1 (2018-07-13) X-ClientProxiedBy: cas-essen-01.secunet.de (10.53.40.201) To mbx-essen-01.secunet.de (10.53.40.197) X-EXCLAIMER-MD-CONFIG: 2c86f778-e09b-4440-8b15-867914633a10 Archived-At: Subject: Re: [IPsec] FW: I-D Action: draft-kampati-ipsecme-ikev2-sa-ts-payloads-opt-04.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: Wed, 09 Jun 2021 12:01:27 -0000 Hi, I am happy to see this draft progressing. I am wonder why allow changes once both sides agreed to minimal rekey? The draft currently allow changes to cryptographic suite and TS even when MINIMAL_REKEY_SUPPORTED is negotiated. While this is a more inclusive and flexible approach, I feel it increase chance of interruption when the responder send NO_PROPOSAL_CHOSEN response and initiator does not support changing parameters. Also if the initiator send a rekey with changes and the responder only support MINIMAL_REKEY_SUPPORTED rekey will not be smooth. Such issues are hard to debug because, it only show up when rekeying not when establishing IKE or Child SA. I prefer decide at the beginning to allow changes during rekey or not. My proposal is once both sides negotiated MINIMAL_REKEY_SUPPORTED no changes should be allowed during a rekey, in case of both the IKE SA and the Child SA. Rekey should be a simple refreshing the keying materials and nothing else. If you make this change, you can remove the notifiers *UNCHANGED and also remove section. '3.2.2. Rekeying IKE SAs When Responder's Cryptographic Suites Changed' regards, -antony On Wed, Apr 21, 2021 at 08:11:14 +0000, Panwei (William) wrote: > Hi Chairs, folks, > > I've updated a new version of draft-kampati-ipsecme-ikev2-sa-ts-payloads-opt. It's not a big update. I've received many good comments online/offline before. I tried to address some of them, and there are still several comments under consideration. > > This draft tries to optimize the unnecessary payloads at the time of rekeying IKE SAs and Child SAs. If there is no changes of configuration on the peers, they usually reuse the same crypto suites when rekeying the IKE SAs and Child SAs, so the SA and TS payloads will remain the same as the ones of last rekeying. Therefore, the SA and TS payloads can be omitted at such condition. This optimization can save the bandwidth and power consumption. > > This draft was presented at IETF105 and IETF106, and received many good comments and supports. Paul also presented this topic at IETF110 (many thanks to Paul) and mentioned that he wanted to implement it. After IETF110, Meiling Chen from China Mobile contacted to me privately, she believes this draft is valuable and can be used by them, thanks to her support and help of editing the draft. > > To chairs: I feel many people are interested in this work and I wonder whether I can ask for an adoption call for this draft? > To folks: any comments or feedbacks are very welcome. > > Regards & Thanks! > Wei Pan > > > -----Original Message----- > > From: I-D-Announce [mailto:i-d-announce-bounces@ietf.org] On Behalf > > Of internet-drafts@ietf.org > > Sent: Wednesday, April 21, 2021 2:34 PM > > To: i-d-announce@ietf.org > > Subject: I-D Action: draft-kampati-ipsecme-ikev2-sa-ts-payloads-opt-04.txt > > > > > > A New Internet-Draft is available from the on-line Internet-Drafts > > directories. > > > > > > Title : IKEv2 Optional SA&TS Payloads in Child > > Exchange > > Authors : Sandeep Kampati > > Wei Pan > > Meduri S S Bharath > > Meiling Chen > > Filename : > > draft-kampati-ipsecme-ikev2-sa-ts-payloads-opt-04.txt > > Pages : 13 > > Date : 2021-04-20 > > > > Abstract: > > This document describes a method for reducing the size of the > > Internet Key Exchange version 2 (IKEv2) exchanges at time of rekeying > > IKE SAs and Child SAs by removing or making optional of SA & TS > > payloads. Reducing size of IKEv2 exchanges is desirable for low > > power consumption battery powered devices. It also helps to avoid IP > > fragmentation of IKEv2 messages. > > > > > > The IETF datatracker status page for this draft is: > > https://datatracker.ietf.org/doc/draft-kampati-ipsecme-ikev2-sa-ts-payloa > > ds-opt/ > > > > There are also htmlized versions available at: > > https://tools.ietf.org/html/draft-kampati-ipsecme-ikev2-sa-ts-payloads-opt > > -04 > > https://datatracker.ietf.org/doc/html/draft-kampati-ipsecme-ikev2-sa-ts-p > > ayloads-opt-04 > > > > A diff from the previous version is available at: > > https://www.ietf.org/rfcdiff?url2=draft-kampati-ipsecme-ikev2-sa-ts-paylo > > ads-opt-04 > > > > > > 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/ > > > > > > _______________________________________________ > > I-D-Announce mailing list > > I-D-Announce@ietf.org > > https://www.ietf.org/mailman/listinfo/i-d-announce > > Internet-Draft directories: http://www.ietf.org/shadow.html or > > ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From nobody Wed Jun 9 06:10:25 2021 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 ECFED3A15C1 for ; Wed, 9 Jun 2021 06:10:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-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 7lXtdEln_rM2 for ; Wed, 9 Jun 2021 06:10:13 -0700 (PDT) Received: from frasgout.his.huawei.com (frasgout.his.huawei.com [185.176.79.56]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2BA683A15AF for ; Wed, 9 Jun 2021 06:10:13 -0700 (PDT) Received: from fraeml703-chm.china.huawei.com (unknown [172.18.147.226]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4G0Rw34xtCz6J9YX for ; Wed, 9 Jun 2021 20:57:23 +0800 (CST) Received: from nkgeml706-chm.china.huawei.com (10.98.57.153) by fraeml703-chm.china.huawei.com (10.206.15.52) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.2176.2; Wed, 9 Jun 2021 15:10:09 +0200 Received: from nkgeml705-chm.china.huawei.com (10.98.57.154) by nkgeml706-chm.china.huawei.com (10.98.57.153) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2176.2; Wed, 9 Jun 2021 21:10:07 +0800 Received: from nkgeml705-chm.china.huawei.com ([10.98.57.154]) by nkgeml705-chm.china.huawei.com ([10.98.57.154]) with mapi id 15.01.2176.012; Wed, 9 Jun 2021 21:10:07 +0800 From: "Panwei (William)" To: "antony.antony@secunet.com" CC: "ipsec@ietf.org" Thread-Topic: [IPsec] FW: I-D Action: draft-kampati-ipsecme-ikev2-sa-ts-payloads-opt-04.txt Thread-Index: AQHXXSckvPounrwPRTGrF0dTz3t3LKsLpzBg Date: Wed, 9 Jun 2021 13:10:07 +0000 Message-ID: References: <32fea92125a040a3831695fa7f1510df@huawei.com> <20210609115351.GA24893@moon.secunet.de> In-Reply-To: <20210609115351.GA24893@moon.secunet.de> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.136.125.35] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [IPsec] FW: I-D Action: draft-kampati-ipsecme-ikev2-sa-ts-payloads-opt-04.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: Wed, 09 Jun 2021 13:10:18 -0000 Hi Antony, Thanks for your comment, it's a good proposal and I'm happy to see it. The changes may be caused by the administrator modifying the configuration = of the IPSec devices. For example, if the device has been patched with an u= pdate of supporting a new algorithm, then the administrator might change th= e configuration to use this new algorithm. There is always the possibility of changes. So we need to consider how to p= rocess.=20 I agree with you that the current process defined in the draft is complicat= ed, and I have no objection to your proposal. And I have some more consider= ations, so combined with your proposal, I think there are three ways of han= dling: 1) Changes are allowed, and the rekeying needs to consider this situation. = This is the idea of the current draft, and I agree with you that it's compl= icated. 2) Changes are allowed, but they won't be applied to the existing IKE SAs a= nd Child SAs, i.e., the rekeying of existing SAs won't be affected, and the= newly established IKE SAs and Child SAs will apply for the new configurati= on. 3) Changes are not allowed, this may be reflected at the user perception le= vel, e.g., administrator configuration modifications failure, patch loading= failure, etc. I think all the above three approaches are viable, and actually I don't hav= e a special preference. I'm happy to see your and others' opinions. Regards & Thanks! Wei Pan > -----Original Message----- > From: Antony Antony [mailto:antony.antony@secunet.com] > Sent: Wednesday, June 9, 2021 8:01 PM > To: Panwei (William) > Cc: ipsec@ietf.org > Subject: Re: [IPsec] FW: I-D Action: > draft-kampati-ipsecme-ikev2-sa-ts-payloads-opt-04.txt >=20 > Hi, > I am happy to see this draft progressing. I am wonder why allow changes > once both sides agreed to minimal rekey? >=20 > The draft currently allow changes to cryptographic suite and TS even when > MINIMAL_REKEY_SUPPORTED is negotiated. While this is a more inclusive > and flexible approach, I feel it increase chance of interruption when the > responder send NO_PROPOSAL_CHOSEN response and initiator does not > support changing parameters. Also if the initiator send a rekey with > changes and the responder only support MINIMAL_REKEY_SUPPORTED > rekey will not be smooth. Such issues are hard to debug because, it only > show up when rekeying not when establishing IKE or Child SA. >=20 > I prefer decide at the beginning to allow changes during rekey or not. >=20 > My proposal is once both sides negotiated MINIMAL_REKEY_SUPPORTED > no changes should be allowed during a rekey, in case of both the IKE SA > and the Child SA. Rekey should be a simple refreshing the keying material= s > and nothing else. >=20 > If you make this change, you can remove the notifiers *UNCHANGED and > also remove section. > '3.2.2. Rekeying IKE SAs When Responder's Cryptographic Suites Changed' >=20 > regards, > -antony >=20 >=20 > On Wed, Apr 21, 2021 at 08:11:14 +0000, Panwei (William) wrote: > > Hi Chairs, folks, > > > > I've updated a new version of > draft-kampati-ipsecme-ikev2-sa-ts-payloads-opt. It's not a big update. I'= ve > received many good comments online/offline before. I tried to address > some of them, and there are still several comments under consideration. > > > > This draft tries to optimize the unnecessary payloads at the time of > rekeying IKE SAs and Child SAs. If there is no changes of configuration o= n > the peers, they usually reuse the same crypto suites when rekeying the IK= E > SAs and Child SAs, so the SA and TS payloads will remain the same as the > ones of last rekeying. Therefore, the SA and TS payloads can be omitted a= t > such condition. This optimization can save the bandwidth and power > consumption. > > > > This draft was presented at IETF105 and IETF106, and received many good > comments and supports. Paul also presented this topic at IETF110 (many > thanks to Paul) and mentioned that he wanted to implement it. After > IETF110, Meiling Chen from China Mobile contacted to me privately, she > believes this draft is valuable and can be used by them, thanks to her > support and help of editing the draft. > > > > To chairs: I feel many people are interested in this work and I wonder > whether I can ask for an adoption call for this draft? > > To folks: any comments or feedbacks are very welcome. > > > > Regards & Thanks! > > Wei Pan > > > > > -----Original Message----- > > > From: I-D-Announce [mailto:i-d-announce-bounces@ietf.org] On > Behalf > > > Of internet-drafts@ietf.org > > > Sent: Wednesday, April 21, 2021 2:34 PM > > > To: i-d-announce@ietf.org > > > Subject: I-D Action: > > > draft-kampati-ipsecme-ikev2-sa-ts-payloads-opt-04.txt > > > > > > > > > A New Internet-Draft is available from the on-line Internet-Drafts > > > directories. > > > > > > > > > Title : IKEv2 Optional SA&TS Payloads in Child > > > Exchange > > > Authors : Sandeep Kampati > > > Wei Pan > > > Meduri S S Bharath > > > Meiling Chen > > > Filename : > > > draft-kampati-ipsecme-ikev2-sa-ts-payloads-opt-04.txt > > > Pages : 13 > > > Date : 2021-04-20 > > > > > > Abstract: > > > This document describes a method for reducing the size of the > > > Internet Key Exchange version 2 (IKEv2) exchanges at time of > rekeying > > > IKE SAs and Child SAs by removing or making optional of SA & TS > > > payloads. Reducing size of IKEv2 exchanges is desirable for low > > > power consumption battery powered devices. It also helps to > avoid IP > > > fragmentation of IKEv2 messages. > > > > > > > > > The IETF datatracker status page for this draft is: > > > https://datatracker.ietf.org/doc/draft-kampati-ipsecme-ikev2-sa-ts-p > > > ayloa > > > ds-opt/ > > > > > > There are also htmlized versions available at: > > > https://tools.ietf.org/html/draft-kampati-ipsecme-ikev2-sa-ts-payloa > > > ds-opt > > > -04 > > > https://datatracker.ietf.org/doc/html/draft-kampati-ipsecme-ikev2-sa > > > -ts-p > > > ayloads-opt-04 > > > > > > A diff from the previous version is available at: > > > https://www.ietf.org/rfcdiff?url2=3Ddraft-kampati-ipsecme-ikev2-sa-ts= - > > > paylo > > > ads-opt-04 > > > > > > > > > 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/ > > > > > > > > > _______________________________________________ > > > I-D-Announce mailing list > > > I-D-Announce@ietf.org > > > https://www.ietf.org/mailman/listinfo/i-d-announce > > > Internet-Draft directories: http://www.ietf.org/shadow.html or > > > ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > > _______________________________________________ > > IPsec mailing list > > IPsec@ietf.org > > https://www.ietf.org/mailman/listinfo/ipsec From nobody Thu Jun 10 04:13:44 2021 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 A5DFB3A3E41 for ; Thu, 10 Jun 2021 04:13:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H2=-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 5AY26bkdr1dl for ; Thu, 10 Jun 2021 04:13:38 -0700 (PDT) Received: from frasgout.his.huawei.com (frasgout.his.huawei.com [185.176.79.56]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C9E033A3E3E for ; Thu, 10 Jun 2021 04:13:37 -0700 (PDT) Received: from fraeml705-chm.china.huawei.com (unknown [172.18.147.226]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4G11Pz23NVz6N6P1 for ; Thu, 10 Jun 2021 19:06:47 +0800 (CST) Received: from nkgeml707-chm.china.huawei.com (10.98.57.157) by fraeml705-chm.china.huawei.com (10.206.15.54) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.2176.2; Thu, 10 Jun 2021 13:13:29 +0200 Received: from nkgeml705-chm.china.huawei.com (10.98.57.154) by nkgeml707-chm.china.huawei.com (10.98.57.157) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2176.2; Thu, 10 Jun 2021 19:13:27 +0800 Received: from nkgeml705-chm.china.huawei.com ([10.98.57.154]) by nkgeml705-chm.china.huawei.com ([10.98.57.154]) with mapi id 15.01.2176.012; Thu, 10 Jun 2021 19:13:27 +0800 From: "Panwei (William)" To: Paul Wouters CC: "antony.antony@secunet.com" , "ipsec@ietf.org" Thread-Topic: [IPsec] FW: I-D Action: draft-kampati-ipsecme-ikev2-sa-ts-payloads-opt-04.txt Thread-Index: AQHXXSckvPounrwPRTGrF0dTz3t3LKsLpzBg//+geoCAAZAnMA== Date: Thu, 10 Jun 2021 11:13:27 +0000 Message-ID: <70842dfc08534a85ba5541ad0fb2241b@huawei.com> References: <32fea92125a040a3831695fa7f1510df@huawei.com> <20210609115351.GA24893@moon.secunet.de> <572891ba-ce81-a325-3317-f5bbbb605597@aiven.io> In-Reply-To: <572891ba-ce81-a325-3317-f5bbbb605597@aiven.io> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.136.125.35] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [IPsec] FW: I-D Action: draft-kampati-ipsecme-ikev2-sa-ts-payloads-opt-04.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, 10 Jun 2021 11:13:43 -0000 Hi Paul, Thanks for sharing your opinion. I agree with you that the configuration changes should not apply to the exi= sting SAs. I can explicitly add some text to elaborate this in the draft an= d remove the related sections to keep the solution simple. Regards & Thanks! Wei Pan Sent from Paul Wouters On Wednesday, June 9, 2021: > To: Panwei (William) > Cc: antony.antony@secunet.com; ipsec@ietf.org > Subject: Re: [IPsec] FW: I-D Action: > draft-kampati-ipsecme-ikev2-sa-ts-payloads-opt-04.txt >=20 > On Wed, 9 Jun 2021, Panwei (William) wrote: >=20 >=20 > > The changes may be caused by the administrator modifying the > configuration of the IPSec devices. >=20 > You can find this exact discussion in the list archive two years back I t= hink :) >=20 > Like Antony, I would like to see this feature removed. IKEv2 does not rea= lly > allow you to change the algorithms on rekey anyway, and if you want that > you must start a new IKE SA from scratch. I do think that allowing all th= ese > parameters in IKEv2 was a mistake, which is why I like the concept of the > draft so much. But simpler is better. >=20 > > There is always the possibility of changes. So we need to consider how = to > process. >=20 > As I said in the past, you start a new IKE SA in those cases. You cannot > guarantee that the peer will accept your new algorithm, so you must also > always offer the existing one, but then you are not performing your > "configuration change". And logically, I think this configuration change > would be part of re-authenticating the connection more than it would be > part of re-keying the existing crypto key material. And re-authentication= is > the same as starting a new IKE SA. >=20 > Do you really have a use case where it is prohibitively expensive an > operation to upgrade the IKE or ESP algorithm without doing a restart of > the entire IKE connection? And how do you know the remote peers are > ready for this change? When do you start refusing the old/current > algorithm if your configuration is updated? >=20 > I think keeping this proposal super simple with only doing rekey and > getting new SPI's and keys and possibly new KE for DH would be best. > Anything else, just fallback to restarting IKE from scratch. >=20 > Paul From nobody Sat Jun 26 01:38:20 2021 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 BB3BF3A2578 for ; Sat, 26 Jun 2021 01:38:18 -0700 (PDT) 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 deytiSKfRf-c for ; Sat, 26 Jun 2021 01:38:17 -0700 (PDT) Received: from mail-wm1-x334.google.com (mail-wm1-x334.google.com [IPv6:2a00:1450:4864:20::334]) (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 201453A2577 for ; Sat, 26 Jun 2021 01:38:17 -0700 (PDT) Received: by mail-wm1-x334.google.com with SMTP id l18-20020a1ced120000b029014c1adff1edso9919416wmh.4 for ; Sat, 26 Jun 2021 01:38:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:content-transfer-encoding:mime-version:subject:message-id:date :to; bh=f+fZx3oxdlb4I9KNbj3g8G9NX8poOk1IccKaT4w6vwQ=; b=WUd/XBqUvrjOxO9MnEOzAda5kkoM6JuT06RIi2/0DYKB1tJxivez2eSw85JTGGaqKH qTPJ7JeP3K/0wmhFP1Ui5+QBiPUew0hFJh4dor+O99r3Z8RD4Xl4PC3dqtPe4fgmdzmd MkZSQEd7f2LeiSCHRXjL7CzMl1CITwyk8zzHLo5EgU79AOhnbeMQ/bFLaLwTHZSoN3ov ESB2aayBgQjfBpMYFHRGlBsQRI6CePAB/KBUVOz5nhKzQ0BTCTm4ven1naBiBWNOoCg2 ppQSyYU1dR4xPhtyO32BqFTRc0cD7BLh7FDqUaV/h0TqwB9SfYpWjqghny/ZW5HR4lyY mMTQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:message-id:date:to; bh=f+fZx3oxdlb4I9KNbj3g8G9NX8poOk1IccKaT4w6vwQ=; b=QdFQH0duVpyant+VJsfg00JRTsdQkwxGQ64iTFne6cFn/vPBbjvtBUWWDslMrxmcX2 n+TCP03bZpmPNqSzkSOsafeusMfi1NIOJACzD/+QYLsNc+Y3yDPzg/74bEPLYSTSh3SX dgTcQ4H2LC8Ky2LdXbrqurj54RFd9nei+ydqMQ86cX6XOu7QFgF+e2xPtxKOMN+6hhTZ NRyCKtFxs6sz+8U3T9pXjLZDAEoheF3P8kJpDgbKQ8oMInQ3urVvDGzJUBkrf4C7n2ke h1r4yY5N1YaSGi8U8bWu5Kepvf1/i10Xb1e6Imt+ND4dRmoxJTCI9aE12dfomVfHIAzW km4g== X-Gm-Message-State: AOAM533venMFc/W45b4sxWCH/A1m9cocs2MjJ9m3tUpkU+NrH2rsCciO QKO1B+FA0sroBsEa/KosCujcnHsVKnA= X-Google-Smtp-Source: ABdhPJyXq/wyRknNn0km2VltFzZsmlYyPII6SQts1wrdbtKr32Jv6vRC3LkqvxRRc0W/NkiSH8UqVg== X-Received: by 2002:a05:600c:19d3:: with SMTP id u19mr1096698wmq.139.1624696694350; Sat, 26 Jun 2021 01:38:14 -0700 (PDT) Received: from smtpclient.apple ([46.120.57.183]) by smtp.gmail.com with ESMTPSA id h206sm13153897wmh.33.2021.06.26.01.38.13 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sat, 26 Jun 2021 01:38:13 -0700 (PDT) From: Yoav Nir Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.80.0.2.43\)) Message-Id: <315BBB8D-B55E-43C8-A988-ADC8780AD62E@gmail.com> Date: Sat, 26 Jun 2021 11:38:12 +0300 To: "ipsec@ietf.org WG" X-Mailer: Apple Mail (2.3654.80.0.2.43) Archived-At: Subject: [IPsec] WGLC for draft-ietf-ipsecme-ikev1-algo-to-historic 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, 26 Jun 2021 08:38:19 -0000 Hi, all. Although this draft is really new, having been submitted in April of = this year, its predecessor draft has been under discussion since March = of 2019. This begins a 2-week WGLC. Please read the draft and post comments to = the list. Since this is rather new, short messages in the vein of = =E2=80=9CYeah, this is good. Ship it=E2=80=9D, but substantive comments = are, of course, even more welcome. The WGLC ends at EOD (for me) July 12th, just a week before the IETF = meeting. Thanks From nobody Sat Jun 26 01:42:07 2021 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 280663A25C3 for ; Sat, 26 Jun 2021 01:42:06 -0700 (PDT) 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 I-_dutkvqcXT for ; Sat, 26 Jun 2021 01:42:03 -0700 (PDT) Received: from mail-wr1-x430.google.com (mail-wr1-x430.google.com [IPv6:2a00:1450:4864:20::430]) (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 6915F3A25C1 for ; Sat, 26 Jun 2021 01:42:03 -0700 (PDT) Received: by mail-wr1-x430.google.com with SMTP id j1so13392984wrn.9 for ; Sat, 26 Jun 2021 01:42:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:mime-version:subject:date:references:to:in-reply-to:message-id; bh=wPddfKV0865oiAeImtqQgLQ+w2EJIGsjC8Kaa+FyG9U=; b=Kh6ApF3ImJk2yOPNPxOz7IbYXj4aOR5SQh0U62mgKmzMOSfZ4SGZJXhFbDxfp4XNCi AWEeawjvkNyyiW4Z5g/6rrPzdf02CjKEFsfzbUaAwtc8iiXBTzVBPROSntv5Odk5/uK0 CvsHuJnj3HO9KT0n1BODdbOlAx1b2z7B2+RYAFFgxmo/JisuNBLXhGs962QVVKMXBLjq IZrFpoXsYdAtV2HryhBrcwHONM8BbeQ+TQRwvTEv9dED6s/DtQuj+ghYL3jioa/dV4uV Kd26pS3YXuAIXusmzApRqsJmuyUc4Lcx3SHSWXqj6KLCaK+cqV1lTE5uF+so3VFfzSdk wEEw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:subject:date:references:to :in-reply-to:message-id; bh=wPddfKV0865oiAeImtqQgLQ+w2EJIGsjC8Kaa+FyG9U=; b=pW79OpUPtM86+UlNhMybKLJ41Zi3iw3n4gs1089KVQFuOwWN0CcPJfBaQALDOmmDSs S921vtme7GGdemjRQjvek0M9hs/WWRy9z16aTK11mSlSY/HYjNn0nkOfyu8cPAQuOSL1 WKk/dwGzDfzVWl07TI9AwMmTzllHxB8vkFLDHlM7UeLL+T+vVPBBmAImHTyiducnCLG+ LZYOC4+xybxpKd3YRdpAJds0MpzP0R/0DtaXCqyUDI/q+RefFZhXAJrj8YSD7C91os5/ 6W5/Qbn4rxVe/gUOF+mmtrWxGcvGt0NhVQN+H0XkRhxxlYJUrNMhQC2E9i5icin9ZlM4 51Pw== X-Gm-Message-State: AOAM533a2X5TIwBKY6rseOgMt1qxFKqRnIz3veWerVCncrX6slXBSWWz YRkjSdiiaeREsCtWin3YjmWqF/uB8HA= X-Google-Smtp-Source: ABdhPJzq7dMSMQByZotvuKeB/W3c2VI3eaXVmuqxz+ruyC6WDt5qNFmA3LoO040pFA+WZCJlqHITUA== X-Received: by 2002:adf:e489:: with SMTP id i9mr16076887wrm.293.1624696920881; Sat, 26 Jun 2021 01:42:00 -0700 (PDT) Received: from smtpclient.apple ([46.120.57.183]) by smtp.gmail.com with ESMTPSA id j11sm7331250wms.6.2021.06.26.01.41.59 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sat, 26 Jun 2021 01:42:00 -0700 (PDT) From: Yoav Nir Content-Type: multipart/alternative; boundary="Apple-Mail=_93F72A7C-F55C-43E2-B107-D93220FFA14C" Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.80.0.2.43\)) Date: Sat, 26 Jun 2021 11:41:59 +0300 References: <315BBB8D-B55E-43C8-A988-ADC8780AD62E@gmail.com> To: "ipsec@ietf.org WG" In-Reply-To: <315BBB8D-B55E-43C8-A988-ADC8780AD62E@gmail.com> Message-Id: <7E3201D7-35E4-4BDA-88A9-52EC2B6C1485@gmail.com> X-Mailer: Apple Mail (2.3654.80.0.2.43) Archived-At: Subject: Re: [IPsec] WGLC for draft-ietf-ipsecme-ikev1-algo-to-historic 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, 26 Jun 2021 08:42:07 -0000 --Apple-Mail=_93F72A7C-F55C-43E2-B107-D93220FFA14C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Forgot to add a link to the draft: = https://datatracker.ietf.org/doc/draft-ietf-ipsecme-ikev1-algo-to-historic= / = > On 26 Jun 2021, at 11:38, Yoav Nir wrote: >=20 > Hi, all. >=20 > Although this draft is really new, having been submitted in April of = this year, its predecessor draft has been under discussion since March = of 2019. >=20 > This begins a 2-week WGLC. Please read the draft and post comments to = the list. Since this is rather new, short messages in the vein of = =E2=80=9CYeah, this is good. Ship it=E2=80=9D, but substantive comments = are, of course, even more welcome. >=20 > The WGLC ends at EOD (for me) July 12th, just a week before the IETF = meeting. >=20 > Thanks >=20 --Apple-Mail=_93F72A7C-F55C-43E2-B107-D93220FFA14C Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Forgot to add a link to the draft:
https://datatracker.ietf.org/doc/draft-ietf-ipsecme-ikev1-algo-= to-historic/


On 26 = Jun 2021, at 11:38, Yoav Nir <ynir.ietf@gmail.com> wrote:

Hi, = all.

Although this draft is really new, = having been submitted in April of this year, its predecessor draft has = been under discussion since March of 2019.

This begins a 2-week WGLC. Please read the draft and post = comments to the list. Since this is rather new, short messages in the = vein of =E2=80=9CYeah, this is good. Ship it=E2=80=9D, but substantive = comments are, of course, even more welcome.

The WGLC ends at EOD (for me) July 12th, just a week before = the IETF meeting.

Thanks


= --Apple-Mail=_93F72A7C-F55C-43E2-B107-D93220FFA14C-- From nobody Sun Jun 27 00:27:19 2021 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 596763A1EE3 for ; Sun, 27 Jun 2021 00:27:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.238 X-Spam-Level: X-Spam-Status: No, score=-2.238 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.338, 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 lwTMmAlrTbOk for ; Sun, 27 Jun 2021 00:27:13 -0700 (PDT) Received: from www.goatley.com (www.goatley.com [198.137.202.94]) (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 39F233A1EE1 for ; Sun, 27 Jun 2021 00:27:13 -0700 (PDT) Received: from trixy.bergandi.net (cpe-76-176-14-122.san.res.rr.com [76.176.14.122]) by wwwlocal.goatley.com (PMDF V6.8 #2433) with ESMTP id <0QVC04G3FNDCRA@wwwlocal.goatley.com> for ipsec@ietf.org; Sun, 27 Jun 2021 02:27:12 -0500 (CDT) Received: from blockhead.local ([69.12.173.8]) by trixy.bergandi.net (PMDF V6.7-x01 #2433) with ESMTPSA id <0QVC00E3JNCOLJ@trixy.bergandi.net> for ipsec@ietf.org; Sun, 27 Jun 2021 00:26:49 -0700 (PDT) Received: from 69-12-173-8.static.dsltransport.net ([69.12.173.8] EXTERNAL) (EHLO blockhead.local) with TLS/SSL by trixy.bergandi.net ([10.0.42.18]) (PreciseMail V3.3); Sun, 27 Jun 2021 00:26:49 -0700 Date: Sun, 27 Jun 2021 00:27:10 -0700 From: Dan Harkins In-reply-to: <315BBB8D-B55E-43C8-A988-ADC8780AD62E@gmail.com> To: ipsec@ietf.org Message-id: <27e3a518-664e-2326-bc72-b53569b089ee@lounge.org> MIME-version: 1.0 Content-type: text/plain; charset=utf-8; format=flowed Content-language: en-US Content-transfer-encoding: 8BIT User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.7.1 X-PMAS-SPF: SPF check skipped for authenticated session (recv=trixy.bergandi.net, send-ip=69.12.173.8) X-PMAS-External-Auth: 69-12-173-8.static.dsltransport.net [69.12.173.8] (EHLO blockhead.local) References: <315BBB8D-B55E-43C8-A988-ADC8780AD62E@gmail.com> X-PMAS-Software: PreciseMail V3.3 [210625] (trixy.bergandi.net) X-PMAS-Allowed: system rule (rule allow header:X-PMAS-External noexists) Archived-At: Subject: Re: [IPsec] WGLC for draft-ietf-ipsecme-ikev1-algo-to-historic 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, 27 Jun 2021 07:27:17 -0000   I sent substantive comments on this draft to the list on May 6th of this year. They were not addressed so they apply to this WGLC.   Dan. On 6/26/21 1:38 AM, Yoav Nir wrote: > Hi, all. > > Although this draft is really new, having been submitted in April of this year, its predecessor draft has been under discussion since March of 2019. > > This begins a 2-week WGLC. Please read the draft and post comments to the list. Since this is rather new, short messages in the vein of “Yeah, this is good. Ship it”, but substantive comments are, of course, even more welcome. > > The WGLC ends at EOD (for me) July 12th, just a week before the IETF meeting. > > Thanks > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec -- "The object of life is not to be on the side of the majority, but to escape finding oneself in the ranks of the insane." -- Marcus Aurelius From nobody Sun Jun 27 02:04:45 2021 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 099FC3A21CB; Sun, 27 Jun 2021 02:04:43 -0700 (PDT) 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 Hf_1MnB6p6Vy; Sun, 27 Jun 2021 02:04:40 -0700 (PDT) Received: from smtp.chopps.org (smtp.chopps.org [54.88.81.56]) by ietfa.amsl.com (Postfix) with ESMTP id 61A9C3A21C9; Sun, 27 Jun 2021 02:04:40 -0700 (PDT) Received: from smtpclient.apple (066-227-211-029.res.spectrum.com [66.227.211.29]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by smtp.chopps.org (Postfix) with ESMTPSA id 9FA188117B; Sun, 27 Jun 2021 09:04:39 +0000 (UTC) From: Christian Hopps Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.100.0.2.22\)) Message-Id: <6CC0C346-9230-4F21-91B5-06D601A81BC7@chopps.org> Date: Sun, 27 Jun 2021 05:04:38 -0400 Cc: ipsecme-chairs@ietf.org To: IPsecME WG X-Mailer: Apple Mail (2.3654.100.0.2.22) Archived-At: Subject: [IPsec] ipsecme not meeting @ IETF 111? 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, 27 Jun 2021 09:04:43 -0000 I don=E2=80=99t see ipsecme scheduled at IETF 111, is there no meeting? Thanks, Chris.= From nobody Sun Jun 27 07:31:17 2021 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 2F7A83A0E47; Sun, 27 Jun 2021 07:31:16 -0700 (PDT) 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 4GOsinUu7YiR; Sun, 27 Jun 2021 07:31:11 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.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 CAD0D3A0E43; Sun, 27 Jun 2021 07:31:10 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 4GCY7t4JkJz3Pv; Sun, 27 Jun 2021 16:31:06 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1624804266; bh=kBrc2wkByJwYhqHx7Qom96h3ymT0/81UvPoV5zVf1Q4=; h=From:Subject:Date:References:Cc:In-Reply-To:To; b=fLwP/+Q35q1gtcgGPRTWycEjlrgLp2GIkcN+HXRjvcF6bA37QI6e/6+dX1AardrTJ EkhTEt9RtKRVNfohibLFvqoeYLz5i6J9tXNZDeAzlUqQCMqGmrfBCsmfASU/oWR+wi 2TdHA46SrhegsTvtSmlpFPmPbYae52s7C4OeJlV8= 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 ZEMlPON_dExr; Sun, 27 Jun 2021 16:31:05 +0200 (CEST) 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; Sun, 27 Jun 2021 16:31:05 +0200 (CEST) Received: from smtpclient.apple (unknown [24.114.61.62]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by bofh.nohats.ca (Postfix) with ESMTPSA id 3D9AF9AD25; Sun, 27 Jun 2021 10:31:02 -0400 (EDT) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable From: Paul Wouters Mime-Version: 1.0 (1.0) Date: Sun, 27 Jun 2021 10:30:56 -0400 Message-Id: References: <6CC0C346-9230-4F21-91B5-06D601A81BC7@chopps.org> Cc: IPsecME WG , ipsecme-chairs@ietf.org In-Reply-To: <6CC0C346-9230-4F21-91B5-06D601A81BC7@chopps.org> To: Christian Hopps X-Mailer: iPhone Mail (18F72) Archived-At: Subject: Re: [IPsec] ipsecme not meeting @ IETF 111? 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, 27 Jun 2021 14:31:16 -0000 >=20 > On Jun 27, 2021, at 05:04, Christian Hopps wrote: >=20 > =EF=BB=BFI don=E2=80=99t see ipsecme scheduled at IETF 111, is there no me= eting? I hope that is a mistake that can be fixed= From nobody Sun Jun 27 07:33:56 2021 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 A3EBA3A0E5B; Sun, 27 Jun 2021 07:33:54 -0700 (PDT) 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, SPF_HELO_NONE=0.001, SPF_NONE=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 Ymd15CK2L4dy; Sun, 27 Jun 2021 07:33:50 -0700 (PDT) Received: from smtp.chopps.org (smtp.chopps.org [54.88.81.56]) by ietfa.amsl.com (Postfix) with ESMTP id E6E863A0E58; Sun, 27 Jun 2021 07:33:49 -0700 (PDT) Received: from smtpclient.apple (066-227-211-029.res.spectrum.com [66.227.211.29]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by smtp.chopps.org (Postfix) with ESMTPSA id 2F6C1803D6; Sun, 27 Jun 2021 14:33:48 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.100.0.2.22\)) From: Christian Hopps In-Reply-To: Date: Sun, 27 Jun 2021 10:33:48 -0400 Cc: IPsecME WG , ipsecme-chairs@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <6CC0C346-9230-4F21-91B5-06D601A81BC7@chopps.org> To: Paul Wouters X-Mailer: Apple Mail (2.3654.100.0.2.22) Archived-At: Subject: Re: [IPsec] ipsecme not meeting @ IETF 111? 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, 27 Jun 2021 14:33:55 -0000 > On Jun 27, 2021, at 10:30 AM, Paul Wouters wrote: >=20 >> On Jun 27, 2021, at 05:04, Christian Hopps wrote: >>=20 >> =EF=BB=BFI don=E2=80=99t see ipsecme scheduled at IETF 111, is there = no meeting? >=20 > I hope that is a mistake that can be fixed I suspect it still can, but time is probably very limited. I believe = this is the preliminary agenda. Thanks, Chris. From nobody Sun Jun 27 08:23:47 2021 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 7F0E53A111E for ; Sun, 27 Jun 2021 08:23:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aTc1lssX4Hsz for ; Sun, 27 Jun 2021 08:23:41 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2260B3A1122 for ; Sun, 27 Jun 2021 08:23:40 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 05CE338A1F; Sun, 27 Jun 2021 11:25:35 -0400 (EDT) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id sLQ_6XXvyMzL; Sun, 27 Jun 2021 11:25:33 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 757D338A1E; Sun, 27 Jun 2021 11:25:33 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 678EF904; Sun, 27 Jun 2021 11:23:38 -0400 (EDT) From: Michael Richardson To: Yoav Nir , "ipsec\@ietf.org WG" In-Reply-To: <315BBB8D-B55E-43C8-A988-ADC8780AD62E@gmail.com> References: <315BBB8D-B55E-43C8-A988-ADC8780AD62E@gmail.com> X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [IPsec] WGLC for draft-ietf-ipsecme-ikev1-algo-to-historic 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, 27 Jun 2021 15:23:46 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Yoav Nir wrote: > Although this draft is really new, having been submitted in April of > this year, its predecessor draft has been under discussion since March > of 2019. Agreed. > This begins a 2-week WGLC. Please read the draft and post comments to > the list. Since this is rather new, short messages in the vein of > =E2=80=9CYeah, this is good. Ship it=E2=80=9D, but substantive commen= ts are, of course, > even more welcome. Re-read to be sure. Ship it. =2D- Michael Richardson . o O ( IPv6 I=C3=B8T consulti= ng ) Sandelman Software Works Inc, Ottawa and Worldwide --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAmDYl/oACgkQgItw+93Q 3WUmHAf/RvDxahz4z5NFPaI/uMGa5WyGkdLgCEiOMGyxDebsEpjWzWB5oi3dPFfs SfyyvytR151939FSffm7eSf8NuiSiwH5uTXkkPZoWXOGrwJjd/ce3uOV5o7GJtzL zQsfvk0kw4yiYbOxtk7H4xFmXKb7D2bQQjkQhlcs9XxSEclPnVgLR46gQzJEQ571 AmMS2Cbz7f0diUR05rcZtA3gEcgdbYrk22arBVz6YdtdQaXWvMYIJrqa720Td6hk jW1UbVSN+aHQQ/WDaUgrGGi9Mr8Eb5N8WryLj6mgFmqhIPHIDK/rq8fEpxojZyPY wKhcOq7OXqUw5WyRCbypFJVa9Y9xcg== =4V4k -----END PGP SIGNATURE----- --=-=-=-- From nobody Sun Jun 27 11:32:28 2021 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 76E213A12E1 for ; Sun, 27 Jun 2021 11:32:27 -0700 (PDT) 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, RCVD_IN_DNSWL_NONE=-0.0001, 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 qbd2-ZJcPBN3 for ; Sun, 27 Jun 2021 11:32:22 -0700 (PDT) Received: from mail-wm1-x32e.google.com (mail-wm1-x32e.google.com [IPv6:2a00:1450:4864:20::32e]) (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 944BA3A12DA for ; Sun, 27 Jun 2021 11:32:22 -0700 (PDT) Received: by mail-wm1-x32e.google.com with SMTP id n23so9739153wms.2 for ; Sun, 27 Jun 2021 11:32:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=KvYSZHcH6Klh92eS0CTB5CHO1EwHxk0UPKAzLmJS1QI=; b=vDC7y1tSfTolXYfCJfxk7cKukYyDGRYXsIen4O+gCa3+OO3dE9AS/BP2bTx7v6wfSR y935QHK13cdvBjBEjBp/zbRB9wWpU0X0UP17GNedMDuzbcKJA+WQ65GBNJx8+uHczv1Q jr2HYgfLH5MtQUWbKFy/w3TUbpuGSlPBN/96sCmeoaxtHwJC3ETz09ICPpBRe15qogsf qNgMVVtPTMaDdOzY9m4TxIxFBNd1ot+l53qSgk6aQ2isLil8HUpFK9MuG37kNklco/r5 uhxnLFEl2EPUldIoCea+oUB8MCflaH/Ol4tBk6ys99muBziNJQNemL8BAy2zIABuyRzI mmng== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=KvYSZHcH6Klh92eS0CTB5CHO1EwHxk0UPKAzLmJS1QI=; b=omoHH7E18zslIEHQgbCXlQlVCzSQhWSNo2ZxMPEpnNbZ+YFOEEnEs5h5TzoH3AJwlH L4XraTBTkB2mLpVHoxweQMdDUDbNZO0CF4RQy9X/fAqbH0UEAcZxRP90xqlbVV6o5qyQ kAtKMPJ183Wq+EFe+cZ8ozOjFSrWeSr4KkCuHst9BEQslw03uEz5okjcqI3GQmDEGbyU VPH4WrfN//7RbBuswqay8An9HHBOotG17VFLFvkYqAI7i7UDPGKxPZLM/wvxiZAyH+aY bdPiUrOUNQA1Mywzc70+JmP0VzGl5XhS5FKWgaiSQdZsh/8Isc+b4Z5w06L+t0Fhk/QM cHgQ== X-Gm-Message-State: AOAM532809F80zhsM2c2RLMuWTwDax1loiQcE/u8QWST7kpF6nZlTwQB mNnAkpd9bj4LoWPNk41IKf2RIqXu5AjKWg== X-Google-Smtp-Source: ABdhPJzfkjgX1pq8CKBZDZmTSNOjZXCU3zyv70HJBAlLc2Ydmx3vQlJ0dXo+a9U/FrpjwZ5kw7K2kQ== X-Received: by 2002:a1c:4b05:: with SMTP id y5mr22531748wma.5.1624818735721; Sun, 27 Jun 2021 11:32:15 -0700 (PDT) Received: from smtpclient.apple ([46.120.57.183]) by smtp.gmail.com with ESMTPSA id v17sm4648791wrt.74.2021.06.27.11.32.14 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sun, 27 Jun 2021 11:32:15 -0700 (PDT) From: Yoav Nir Message-Id: <16AF9CB0-8F04-456F-AE89-2461504E6740@gmail.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_DC65D0B2-2221-486F-B0DB-A576721C7AB1" Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.80.0.2.43\)) Date: Sun, 27 Jun 2021 21:32:13 +0300 In-Reply-To: <27e3a518-664e-2326-bc72-b53569b089ee@lounge.org> Cc: ipsec@ietf.org To: Dan Harkins References: <315BBB8D-B55E-43C8-A988-ADC8780AD62E@gmail.com> <27e3a518-664e-2326-bc72-b53569b089ee@lounge.org> X-Mailer: Apple Mail (2.3654.80.0.2.43) Archived-At: Subject: Re: [IPsec] WGLC for draft-ietf-ipsecme-ikev1-algo-to-historic 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, 27 Jun 2021 18:32:28 -0000 --Apple-Mail=_DC65D0B2-2221-486F-B0DB-A576721C7AB1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 To facilitate this discussion: The comments are in this message: = https://mailarchive.ietf.org/arch/msg/ipsec/oO5Gcb6vwFVRK9mhQSrmSu75Ou4/ = = Paul repled with this: = https://mailarchive.ietf.org/arch/msg/ipsec/crENax8kcWhoY8aIH__FflP8s2w/ = = Dan replied with this: = https://mailarchive.ietf.org/arch/msg/ipsec/bCVFtBLCbNgI4_2OalYkiD3cEYY/ = = Tero: = https://mailarchive.ietf.org/arch/msg/ipsec/ke9Xesu8gcV0zBHxsXKHBILxIM4/ = = And finally, Dan: = https://mailarchive.ietf.org/arch/msg/ipsec/QsR0qMNBo2s35dDgwIE-AcKaqxQ/ = = If I read this correctly, the last two messages are about some of = decision-making process in IKEv2 drafts, so it=E2=80=99s not relevant to = the draft now in WGLC. Can I assume the unaddressed points are those in the third message? Yoav > On 27 Jun 2021, at 10:27, Dan Harkins wrote: >=20 >=20 > I sent substantive comments on this draft to the list on May 6th of = this > year. They were not addressed so they apply to this WGLC. >=20 > Dan. >=20 > On 6/26/21 1:38 AM, Yoav Nir wrote: >> Hi, all. >>=20 >> Although this draft is really new, having been submitted in April of = this year, its predecessor draft has been under discussion since March = of 2019. >>=20 >> This begins a 2-week WGLC. Please read the draft and post comments to = the list. Since this is rather new, short messages in the vein of = =E2=80=9CYeah, this is good. Ship it=E2=80=9D, but substantive comments = are, of course, even more welcome. >>=20 >> The WGLC ends at EOD (for me) July 12th, just a week before the IETF = meeting. >>=20 >> Thanks >>=20 >> _______________________________________________ >> IPsec mailing list >> IPsec@ietf.org >> https://www.ietf.org/mailman/listinfo/ipsec >=20 > --=20 > "The object of life is not to be on the side of the majority, but to > escape finding oneself in the ranks of the insane." -- Marcus Aurelius >=20 > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec --Apple-Mail=_DC65D0B2-2221-486F-B0DB-A576721C7AB1 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 To = facilitate this discussion:

The comments are in this message: https://mailarchive.ietf.org/arch/msg/ipsec/oO5Gcb6vwFVRK9mhQSr= mSu75Ou4/

Paul repled with this: https://mailarchive.ietf.org/arch/msg/ipsec/crENax8kcWhoY8aIH__= FflP8s2w/

Dan replied with this: https://mailarchive.ietf.org/arch/msg/ipsec/bCVFtBLCbNgI4_2OalY= kiD3cEYY/

Tero: https://mailarchive.ietf.org/arch/msg/ipsec/ke9Xesu8gcV0zBHxsXK= HBILxIM4/

And finally, Dan: https://mailarchive.ietf.org/arch/msg/ipsec/QsR0qMNBo2s35dDgwIE= -AcKaqxQ/

If= I read this correctly, the last two messages are about some of = decision-making process in IKEv2 drafts, so it=E2=80=99s not relevant to = the draft now in WGLC.

Can I assume the unaddressed points are those in the third = message?

Yoav

On 27 Jun 2021, at 10:27, Dan Harkins <dharkins@lounge.org>= wrote:


  I sent substantive comments on this = draft to the list on May 6th of this
year. They were not = addressed so they apply to this WGLC.

  = Dan.

On 6/26/21 1:38 AM, Yoav Nir wrote:
Hi, all.
Although this draft is really new, having been submitted in = April of this year, its predecessor draft has been under discussion = since March of 2019.

This begins a 2-week = WGLC. Please read the draft and post comments to the list. Since this is = rather new, short messages in the vein of =E2=80=9CYeah, this is good. = Ship it=E2=80=9D, but substantive comments are, of course, even more = welcome.

The WGLC ends at EOD (for me) July = 12th, just a week before the IETF meeting.

Thanks

_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

--
"The object of = life is not to be on the side of the majority, but to
escape= finding oneself in the ranks of the insane." -- Marcus Aurelius

_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

= --Apple-Mail=_DC65D0B2-2221-486F-B0DB-A576721C7AB1-- From nobody Sun Jun 27 12:25:00 2021 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 528493A1556 for ; Sun, 27 Jun 2021 12:24:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.237 X-Spam-Level: X-Spam-Status: No, score=-2.237 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.338, 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 w0U7ttrz4Fj5 for ; Sun, 27 Jun 2021 12:24:54 -0700 (PDT) Received: from www.goatley.com (www.goatley.com [198.137.202.94]) (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 8EF2B3A1555 for ; Sun, 27 Jun 2021 12:24:54 -0700 (PDT) Received: from trixy.bergandi.net (cpe-76-176-14-122.san.res.rr.com [76.176.14.122]) by wwwlocal.goatley.com (PMDF V6.8 #2433) with ESMTP id <0QVD04GIVKLHRA@wwwlocal.goatley.com> for ipsec@ietf.org; Sun, 27 Jun 2021 14:24:53 -0500 (CDT) Received: from thinny.local ([69.12.173.8]) by trixy.bergandi.net (PMDF V6.7-x01 #2433) with ESMTPSA id <0QVD00A47KKQDQ@trixy.bergandi.net> for ipsec@ietf.org; Sun, 27 Jun 2021 12:24:28 -0700 (PDT) Received: from 69-12-173-8.static.dsltransport.net ([69.12.173.8] EXTERNAL) (EHLO thinny.local) with TLS/SSL by trixy.bergandi.net ([10.0.42.18]) (PreciseMail V3.3); Sun, 27 Jun 2021 12:24:27 -0700 Date: Sun, 27 Jun 2021 12:24:50 -0700 From: Dan Harkins In-reply-to: <16AF9CB0-8F04-456F-AE89-2461504E6740@gmail.com> To: Yoav Nir Cc: ipsec@ietf.org Message-id: <993ebb6f-b04d-24cb-882a-d26eda62c044@lounge.org> MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_82NREIyjz/AzzTxKA2iYCA)" Content-language: en-US User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 X-PMAS-SPF: SPF check skipped for authenticated session (recv=trixy.bergandi.net, send-ip=69.12.173.8) X-PMAS-External-Auth: 69-12-173-8.static.dsltransport.net [69.12.173.8] (EHLO thinny.local) References: <315BBB8D-B55E-43C8-A988-ADC8780AD62E@gmail.com> <27e3a518-664e-2326-bc72-b53569b089ee@lounge.org> <16AF9CB0-8F04-456F-AE89-2461504E6740@gmail.com> X-PMAS-Software: PreciseMail V3.3 [210625] (trixy.bergandi.net) X-PMAS-Allowed: system rule (rule allow header:X-PMAS-External noexists) Archived-At: Subject: Re: [IPsec] WGLC for draft-ietf-ipsecme-ikev1-algo-to-historic 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, 27 Jun 2021 19:24:59 -0000 This is a multi-part message in MIME format. --Boundary_(ID_82NREIyjz/AzzTxKA2iYCA) Content-type: text/plain; charset=utf-8; format=flowed Content-transfer-encoding: 8BIT   Hi Yoav,   Thanks for facilitating this discussion (especially given the editor's issues with interacting with me). Yes, the unaddressed points are in the 3rd email. Everything above the "there is another IKEv1 feature not available in IKEv2" line are my unresolved comments, everything below that is further discussed in the final 2 emails and is not relevant to the comments I made on the draft.   Basically, I want to get rid of the speculative language and the guesswork language which is  not really even necessary to make the case. I also provided 2 reworded paragraphs which I think improve the draft and are more clear. Of course, that's my opinion, it's open to debate and disagreement, but if others agree with me then I think these changes should be adopted by the editor.   regards,   Dan. On 6/27/21 11:32 AM, Yoav Nir wrote: > To facilitate this discussion: > > The comments are in this message: > https://mailarchive.ietf.org/arch/msg/ipsec/oO5Gcb6vwFVRK9mhQSrmSu75Ou4/ > > Paul repled with this: > https://mailarchive.ietf.org/arch/msg/ipsec/crENax8kcWhoY8aIH__FflP8s2w/ > > Dan replied with this: > https://mailarchive.ietf.org/arch/msg/ipsec/bCVFtBLCbNgI4_2OalYkiD3cEYY/ > > Tero: > https://mailarchive.ietf.org/arch/msg/ipsec/ke9Xesu8gcV0zBHxsXKHBILxIM4/ > > And finally, Dan: > https://mailarchive.ietf.org/arch/msg/ipsec/QsR0qMNBo2s35dDgwIE-AcKaqxQ/ > > If I read this correctly, the last two messages are about some of > decision-making process in IKEv2 drafts, so it’s not relevant to the > draft now in WGLC. > > Can I assume the unaddressed points are those in the third message? > > Yoav > >> On 27 Jun 2021, at 10:27, Dan Harkins > > wrote: >> >> >>   I sent substantive comments on this draft to the list on May 6th of >> this >> year. They were not addressed so they apply to this WGLC. >> >>   Dan. >> >> On 6/26/21 1:38 AM, Yoav Nir wrote: >>> Hi, all. >>> >>> Although this draft is really new, having been submitted in April of >>> this year, its predecessor draft has been under discussion since >>> March of 2019. >>> >>> This begins a 2-week WGLC. Please read the draft and post comments >>> to the list. Since this is rather new, short messages in the vein of >>> “Yeah, this is good. Ship it”, but substantive comments are, of >>> course, even more welcome. >>> >>> The WGLC ends at EOD (for me) July 12th, just a week before the IETF >>> meeting. >>> >>> Thanks >>> >>> _______________________________________________ >>> IPsec mailing list >>> IPsec@ietf.org >>> https://www.ietf.org/mailman/listinfo/ipsec >> >> -- >> "The object of life is not to be on the side of the majority, but to >> escape finding oneself in the ranks of the insane." -- Marcus Aurelius >> >> _______________________________________________ >> IPsec mailing list >> IPsec@ietf.org >> https://www.ietf.org/mailman/listinfo/ipsec > --Boundary_(ID_82NREIyjz/AzzTxKA2iYCA) Content-type: text/html; charset=utf-8 Content-transfer-encoding: 8BIT
  Hi Yoav,

  Thanks for facilitating this discussion (especially given the editor's issues with
interacting with me). Yes, the unaddressed points are in the 3rd email. Everything
above the "there is another IKEv1 feature not available in IKEv2" line are my
unresolved comments, everything below that is further discussed in the final 2 emails
and is not relevant to the comments I made on the draft.

  Basically, I want to get rid of the speculative language and the guesswork language
which is  not really even necessary to make the case. I also provided 2 reworded
paragraphs which I think improve the draft and are more clear. Of course, that's my
opinion, it's open to debate and disagreement, but if others agree with me then I
think these changes should be adopted by the editor.

  regards,

  Dan.

On 6/27/21 11:32 AM, Yoav Nir wrote:
To facilitate this discussion:






If I read this correctly, the last two messages are about some of decision-making process in IKEv2 drafts, so it’s not relevant to the draft now in WGLC.

Can I assume the unaddressed points are those in the third message?

Yoav

On 27 Jun 2021, at 10:27, Dan Harkins <dharkins@lounge.org> wrote:


  I sent substantive comments on this draft to the list on May 6th of this
year. They were not addressed so they apply to this WGLC.

  Dan.

On 6/26/21 1:38 AM, Yoav Nir wrote:
Hi, all.

Although this draft is really new, having been submitted in April of this year, its predecessor draft has been under discussion since March of 2019.

This begins a 2-week WGLC. Please read the draft and post comments to the list. Since this is rather new, short messages in the vein of “Yeah, this is good. Ship it”, but substantive comments are, of course, even more welcome.

The WGLC ends at EOD (for me) July 12th, just a week before the IETF meeting.

Thanks

_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

--
"The object of life is not to be on the side of the majority, but to
escape finding oneself in the ranks of the insane." -- Marcus Aurelius

_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec


--Boundary_(ID_82NREIyjz/AzzTxKA2iYCA)-- From nobody Sun Jun 27 18:54:39 2021 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 D612C3A2568; Sun, 27 Jun 2021 18:54:37 -0700 (PDT) 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.33.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: ipsec@ietf.org Message-ID: <162484527780.11181.3307206349486382969@ietfa.amsl.com> Date: Sun, 27 Jun 2021 18:54:37 -0700 Archived-At: Subject: [IPsec] I-D Action: draft-ietf-ipsecme-ikev1-algo-to-historic-01.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: Mon, 28 Jun 2021 01:54:38 -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 : Deprecation of IKEv1 and obsoleted algorithms Author : Paul Wouters Filename : draft-ietf-ipsecme-ikev1-algo-to-historic-01.txt Pages : 8 Date : 2021-06-27 Abstract: Internet Key Exchange version 1 (IKEv1) is deprecated. Accordingly, IKEv1 has been moved to Historic status. A number of old algorithms that are associated with IKEv1, and not widely implemented for IKEv2 are deprecated as well. This document adds a Status column to the IANA IKEv2 Transform Type registries. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ipsecme-ikev1-algo-to-historic/ There is also an htmlized version available at: https://datatracker.ietf.org/doc/html/draft-ietf-ipsecme-ikev1-algo-to-historic-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ipsecme-ikev1-algo-to-historic-01 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sun Jun 27 19:02:34 2021 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 BD6473A25C3 for ; Sun, 27 Jun 2021 19:02:32 -0700 (PDT) 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 5CXhItnHeVaE for ; Sun, 27 Jun 2021 19:02:28 -0700 (PDT) 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 E749E3A25BC for ; Sun, 27 Jun 2021 19:02:27 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 4GCrTY2pSXz24T for ; Mon, 28 Jun 2021 04:02:25 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1624845745; bh=8F/pZ87eenIJRZiW2YzRk/21hTgC/jy8sxfHBCpLMk0=; h=Date:From:To:Subject:In-Reply-To:References; b=KJNdajBt/oUdHrgz+eC0rkIkBOPg0VBNIg9MRp4Pzzmv7Van4b5vx0T3crr/+FNuM iZfcQXSdNlv3WckYKv93wHU1A9vrjgLGknYbopndO/pTMyxrqzdurGC2fRdsrZj4Jy bLSG5UCYzuL87X3nBiSDU1f5wNRpozPtKnJivOBc= 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 AS0D0gNmk6Op for ; Mon, 28 Jun 2021 04:02:24 +0200 (CEST) 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 ; Mon, 28 Jun 2021 04:02:23 +0200 (CEST) Received: by bofh.nohats.ca (Postfix, from userid 1000) id A8EFF9B78D; Sun, 27 Jun 2021 22:02:22 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 9D2A79B78C for ; Sun, 27 Jun 2021 22:02:22 -0400 (EDT) Date: Sun, 27 Jun 2021 22:02:22 -0400 (EDT) From: Paul Wouters To: "ipsec@ietf.org WG" In-Reply-To: <993ebb6f-b04d-24cb-882a-d26eda62c044@lounge.org> Message-ID: <43b26ca5-2922-edcc-6eeb-1dafc61a1ba@nohats.ca> References: <315BBB8D-B55E-43C8-A988-ADC8780AD62E@gmail.com> <27e3a518-664e-2326-bc72-b53569b089ee@lounge.org> <16AF9CB0-8F04-456F-AE89-2461504E6740@gmail.com> <993ebb6f-b04d-24cb-882a-d26eda62c044@lounge.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8BIT Archived-At: Subject: Re: [IPsec] WGLC for draft-ietf-ipsecme-ikev1-algo-to-historic 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, 28 Jun 2021 02:02:33 -0000 On Sun, 27 Jun 2021, Dan Harkins wrote: >   Thanks for facilitating this discussion (especially given the editor's issues with > interacting with me). I don't want to keep focussing on this, but again I need to defense myself. I have no issues with interacting with you on public mailing lists. I have a personal opinion that your behaviour has been inappropriate enough towards me and other groups of people that I wish no longer interact with you via non-public emails. I believe that is within my rights. This does not interfere with me responding to on topic discussion where I am acting in an official IETF capacity, such as Document Author or Working Group Chair. > Yes, the unaddressed points are in the 3rd email. Everything > above the "there is another IKEv1 feature not available in IKEv2" line are my > unresolved comments, everything below that is further discussed in the final 2 emails > and is not relevant to the comments I made on the draft. > >   Basically, I want to get rid of the speculative language and the guesswork language > which is  not really even necessary to make the case. I also provided 2 reworded > paragraphs which I think improve the draft and are more clear. Of course, that's my > opinion, it's open to debate and disagreement, but if others agree with me then I > think these changes should be adopted by the editor. At the time, I was waiting for more comments before updating the document. I have now pushed these changes. I've taken in some text of Dan, although I did not remove everything he suggested removing because I deem those bits have value to bring across. If other people wish to chime in, that would be useful to determine consensus. The changes to the document are minor, so I think this can be evaluated as part of this WGLC, but the final decision on that rests with the chairs. https://www.ietf.org/rfcdiff?url2=draft-ietf-ipsecme-ikev1-algo-to-historic-01 Paul From nobody Sun Jun 27 20:33:33 2021 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 3F3F23A287A for ; Sun, 27 Jun 2021 20:33:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.237 X-Spam-Level: X-Spam-Status: No, score=-2.237 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.338, RCVD_IN_DNSWL_BLOCKED=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 2m7NYDmrRGwo for ; Sun, 27 Jun 2021 20:33:27 -0700 (PDT) Received: from www.goatley.com (www.goatley.com [198.137.202.94]) (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 EED413A2881 for ; Sun, 27 Jun 2021 20:33:26 -0700 (PDT) Received: from trixy.bergandi.net (cpe-76-176-14-122.san.res.rr.com [76.176.14.122]) by wwwlocal.goatley.com (PMDF V6.8 #2433) with ESMTP id <0QVE04GRG77PRA@wwwlocal.goatley.com> for ipsec@ietf.org; Sun, 27 Jun 2021 22:33:25 -0500 (CDT) Received: from blockhead.local ([69.12.173.8]) by trixy.bergandi.net (PMDF V6.7-x01 #2433) with ESMTPSA id <0QVE00A0N76X8L@trixy.bergandi.net> for ipsec@ietf.org; Sun, 27 Jun 2021 20:32:57 -0700 (PDT) Received: from 69-12-173-8.static.dsltransport.net ([69.12.173.8] EXTERNAL) (EHLO blockhead.local) with TLS/SSL by trixy.bergandi.net ([10.0.42.18]) (PreciseMail V3.3); Sun, 27 Jun 2021 20:32:57 -0700 Date: Sun, 27 Jun 2021 20:33:23 -0700 From: Dan Harkins In-reply-to: <43b26ca5-2922-edcc-6eeb-1dafc61a1ba@nohats.ca> To: ipsec@ietf.org Message-id: <5d8e78bf-37c0-61e4-6829-bd634593a23d@lounge.org> MIME-version: 1.0 Content-type: text/plain; charset=utf-8; format=flowed Content-language: en-US Content-transfer-encoding: 8BIT User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.7.1 X-PMAS-SPF: SPF check skipped for authenticated session (recv=trixy.bergandi.net, send-ip=69.12.173.8) X-PMAS-External-Auth: 69-12-173-8.static.dsltransport.net [69.12.173.8] (EHLO blockhead.local) References: <315BBB8D-B55E-43C8-A988-ADC8780AD62E@gmail.com> <27e3a518-664e-2326-bc72-b53569b089ee@lounge.org> <16AF9CB0-8F04-456F-AE89-2461504E6740@gmail.com> <993ebb6f-b04d-24cb-882a-d26eda62c044@lounge.org> <43b26ca5-2922-edcc-6eeb-1dafc61a1ba@nohats.ca> X-PMAS-Software: PreciseMail V3.3 [210625] (trixy.bergandi.net) X-PMAS-Allowed: system rule (rule allow header:X-PMAS-External noexists) Archived-At: Subject: Re: [IPsec] WGLC for draft-ietf-ipsecme-ikev1-algo-to-historic 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, 28 Jun 2021 03:33:31 -0000 On 6/27/21 7:02 PM, Paul Wouters wrote: > On Sun, 27 Jun 2021, Dan Harkins wrote: > >>   Thanks for facilitating this discussion (especially given the >> editor's issues with >> interacting with me). > > I don't want to keep focussing on this, but again I need to > defense myself. I have no issues with interacting with you on public > mailing lists. I have a personal opinion that your behaviour has been > inappropriate enough towards me and other groups of people that I wish > no longer interact with you via non-public emails.   Yet all these problematic non-public email interactions seem to have been initiated by you! (I have the receipts). > I believe that is within my rights.   If only you would give that accommodation ("my rights") to me.   But whatever, it's not really an IPsecme issue. > This does not interfere with me responding to on topic > discussion where I am acting in an official IETF capacity, such as > Document Author or Working Group Chair.   Or document *editor*, as is the case here. >> Yes, the unaddressed points are in the 3rd email. Everything >> above the "there is another IKEv1 feature not available in IKEv2" >> line are my >> unresolved comments, everything below that is further discussed in >> the final 2 emails >> and is not relevant to the comments I made on the draft. >> >>   Basically, I want to get rid of the speculative language and the >> guesswork language >> which is  not really even necessary to make the case. I also provided >> 2 reworded >> paragraphs which I think improve the draft and are more clear. Of >> course, that's my >> opinion, it's open to debate and disagreement, but if others agree >> with me then I >> think these changes should be adopted by the editor. > > At the time, I was waiting for more comments before updating the > document. I have now pushed these changes. I've taken in some text of > Dan, > although I did not remove everything he suggested removing because I deem > those bits have value to bring across. If other people wish to chime in, > that would be useful to determine consensus.   I still think there is a problem in providing speculative text about some vendors and their potentially "unmaintained code". Unless you're prepared to state which vendors are not maintaining their code to the detriment of their customers I don't think you should allude to such a situation. And I really don't think an RFC is the appropriate vehicle to describe such vendor behavior even if you were gonna describe it.   The draft does not need to engage in such speculation. There are plenty of other concrete, definitive reasons to send IKEv1 to historic. This coulda/shoulda/woulda stuff is not necessary and actually detracts from the draft. > The changes to the document are minor, so I think this can be > evaluated as > part of this WGLC, but the final decision on that rests with the chairs.   Actually it rests with the group. This is a document of the working group.   Dan. > https://www.ietf.org/rfcdiff?url2=draft-ietf-ipsecme-ikev1-algo-to-historic-01 > > > Paul > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec -- "The object of life is not to be on the side of the majority, but to escape finding oneself in the ranks of the insane." -- Marcus Aurelius From nobody Mon Jun 28 01:23:53 2021 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 8372C3A30AA for ; Mon, 28 Jun 2021 01:23:42 -0700 (PDT) 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, 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 TgPS6TJaQV-s for ; Mon, 28 Jun 2021 01:23:40 -0700 (PDT) Received: from mail-lj1-x231.google.com (mail-lj1-x231.google.com [IPv6:2a00:1450:4864:20::231]) (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 B2D103A30AD for ; Mon, 28 Jun 2021 01:23:40 -0700 (PDT) Received: by mail-lj1-x231.google.com with SMTP id c11so24399521ljd.6 for ; Mon, 28 Jun 2021 01:23:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-transfer-encoding:thread-index:content-language; bh=WGtJzU/kQzqjmOP8991of8gYzJcG5b119PK7oaYqhmI=; b=lX6MiDhYrxWjCKIQ85E13FlIDKGzgn3ka1KkJTshMw0GFKcP8gowc3qr6ei7i1uBXF 4XHhHsq0A/7mu0uZJW5OV24Yj+014cNYJvw5RO2s4WYegoM8dqoVq1He6dRemHBepJ9H +0MMHHxRjouuVwAaE1vnCIxhPX4tCjrqbN3WD2l8RbviiKB6gUAGOw9WGe0P+m3UuF/I 0Mg0x8Lvr+KTOUpOTpGtifMoFQZwsQ1wtE/2GW8Q2x/PyJ6SlC4CgYgpjlgljbqn9RTb pxKvVJp8LI4k1z1tWTo9fFoeR9wnSotvX4Mue6Zh58JdrpMlImNPal69FeUMI2his1Td TlZw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:references:in-reply-to:subject:date :message-id:mime-version:content-transfer-encoding:thread-index :content-language; bh=WGtJzU/kQzqjmOP8991of8gYzJcG5b119PK7oaYqhmI=; b=cyy4fJPyaR8+XxiT2TWxQC21xcAnUbokj/7b1RNUPdADSw53oiczmsNquMP8WL3+KE CktbbBP/q2Bx/ZCw9/M0BDvr3t/tW6KXV6cB4qjNIf7j2Hg04Q64nA8/0zvsXHwPpots UZLzPFVx7KSmSq+/r1WW3VSmmkgW+creD/r2RO679Kkkyszi6A4inqZAqN+UgxOB/y00 l9a8TIjLsC/M/eNS7aRLvCX7LOEXnREYeN5jqnayuqJXlXjGUuXQCI0QRQOpBvrPl/sj 5zFffRtkY9gxDs70Khb7LEfqDi66XE5P9yxbIiVmuOG9t0PHs6UeRtqb08P2aEOVWuTE ehkA== X-Gm-Message-State: AOAM532eEMP0z1U+oUYJL51EFzfbVXSSZbuzfTJinDZMYn428DMKnxKz ui8Ps+QQCXjh1TZYgRjvngyumghAAKY= X-Google-Smtp-Source: ABdhPJz4g6bYPd1MspRsJNbTHYNYE+V3wHzila6KwvBk0TJFcKk9JGFoEVYjU51CrFShfy9ohL9zUw== X-Received: by 2002:a2e:a546:: with SMTP id e6mr19275411ljn.255.1624868613447; Mon, 28 Jun 2021 01:23:33 -0700 (PDT) Received: from buildpc ([93.188.44.204]) by smtp.gmail.com with ESMTPSA id p18sm986926ljj.56.2021.06.28.01.23.32 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 28 Jun 2021 01:23:32 -0700 (PDT) From: "Valery Smyslov" To: "'Yoav Nir'" , References: <315BBB8D-B55E-43C8-A988-ADC8780AD62E@gmail.com> In-Reply-To: <315BBB8D-B55E-43C8-A988-ADC8780AD62E@gmail.com> Date: Mon, 28 Jun 2021 11:23:32 +0300 Message-ID: <059201d76bf6$e29680c0$a7c38240$@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: AQHxuVp+cPQG1Jn/fU0fR8b5jHKxCar0a7Ew Content-Language: ru Archived-At: Subject: Re: [IPsec] WGLC for draft-ietf-ipsecme-ikev1-algo-to-historic 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, 28 Jun 2021 08:23:51 -0000 Hi, I think document is mostly ready. Few observations: - FWIW I think that Dan's efforts to make draft's language less = speculative and more concrete=20 are valid and should be reflected in the document.=20 - Is it OK that the intended status is Standards Track? Shouldn't it be = BCP? - The draft states that it updates RFC 7296, 8221, 8247. What in = particular is being updated? I believe the recent IESG directives require a short explanation of = what is being updated to be present in Abstract. In any case, it should be clearly = indicated in the body of the document. Have I missed it? - Section3: I think that phrase "IKEv2 is a more secure protocol than = IKEv1 in every aspect." is a bit too vague. I believe it's better to list security aspects where we believe IKEv2 = is superior: * IKEv2 supports modern cryptographic primitives, including AEAD = ciphers * IKEv2 provides real defense against DoS (cookies, core spec) and = DDoS (puzzles, RFC 8019) attacks * support for post-quantum crypto in IKEv2 is being developed = (draft-ietf-ipsecme-ikev2-multiple-ke) * IKEv2 supports various authentication methods via integration with = EAP (core spec) * an extension that allows build PAKE methods in IKEv2 exists (RFC = 6467) * did I forget something? =20 - Section 4.3. Formally RFC 6407 is not directly concerned with IKEv1. This is an independent protocol developed by msec WG that was based = on IKEv1. I think more accurate language should be used to make this clear. For = example: Group Domain of Interpretation (GDOI, RFC 6407) protocol based on = IKEv1 defines the support for Multicast Group SAs. I also think that reference to RFC 3740 should be remove (it doesn't = even mention IKE in any substantial way). I'm not so sure about RFC 5374, but I'm = inclining=20 to remove it too - it's mostly concerned with MCAS architecture and = doesn't define any concrete IKEv1 changes to support it. So, leave only RFC = 6407. - Section 5 lists deprecated algorithms. In my reading this list is inconsistent with Section 7 (IANA Considerations) which lists many more deprecated algorithms... So, I'm a bit puzzled how to read this section. - The draft currently has all its references as Normative. I have no problems with this (except that RFC 3740 is Informational, so should not be referenced as Normative in Standards Track and BCP = documents, but I suggested to remove it anyway). My concern is that=20 referencing active drafts as Normative will lead to slow down publication of this document until those drafts are published. I don't think it's a major problem (we will have an incentive=20 to work harder on these drafts :-)), just should be noted. Regards, Valery. > Hi, all. >=20 > Although this draft is really new, having been submitted in April of = this year, its predecessor draft has been > under discussion since March of 2019. >=20 > This begins a 2-week WGLC. Please read the draft and post comments to = the list. Since this is rather new, > short messages in the vein of =E2=80=9CYeah, this is good. Ship = it=E2=80=9D, but substantive comments are, of course, even > more welcome. >=20 > The WGLC ends at EOD (for me) July 12th, just a week before the IETF = meeting. >=20 > Thanks >=20 > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From nobody Mon Jun 28 07:56:15 2021 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 4A9A73A0BD6 for ; Mon, 28 Jun 2021 07:56:14 -0700 (PDT) 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 dglQR_wKZCyS for ; Mon, 28 Jun 2021 07:56:09 -0700 (PDT) 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 1F8F23A0BCF for ; Mon, 28 Jun 2021 07:56:09 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 4GD9fG0jTrz5B9; Mon, 28 Jun 2021 16:56:06 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1624892166; bh=RUDDvOcPQzsD9XnPV3+dOqml0a+Uh0JHeT7dCGI3DuE=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=p3JmbzErtCiagSmHH5IgoVTfS3/pqW6JCOxDspCcP68PWWBAfYJ72YBgQoTln0hb3 uAW+UDDUaJ3ud468+XskSc+qZvwrkVq9aCJA+0UsOQq5BWuu/ue7sYZNVqaywUgBdR Tg/vy0hmCBhlyIa6yX5kw44uo71NC8XPmZ3EVTxw= 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 0j28AC_4hEXD; Mon, 28 Jun 2021 16:56:04 +0200 (CEST) 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, 28 Jun 2021 16:56:04 +0200 (CEST) Received: by bofh.nohats.ca (Postfix, from userid 1000) id 72076BDA5B; Mon, 28 Jun 2021 10:56:03 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 6E773BDA5A; Mon, 28 Jun 2021 10:56:03 -0400 (EDT) Date: Mon, 28 Jun 2021 10:56:03 -0400 (EDT) From: Paul Wouters To: Valery Smyslov cc: 'Yoav Nir' , ipsec@ietf.org In-Reply-To: <059201d76bf6$e29680c0$a7c38240$@gmail.com> Message-ID: <138a506a-12c2-37c5-f6cf-a391e528611e@nohats.ca> References: <315BBB8D-B55E-43C8-A988-ADC8780AD62E@gmail.com> <059201d76bf6$e29680c0$a7c38240$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [IPsec] WGLC for draft-ietf-ipsecme-ikev1-algo-to-historic 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, 28 Jun 2021 14:56:14 -0000 On Mon, 28 Jun 2021, Valery Smyslov wrote: > I think document is mostly ready. Few observations: > > - FWIW I think that Dan's efforts to make draft's language less speculative and more concrete > are valid and should be reflected in the document. I did change the wording to remove the quantifiers, eg from "a number of vendors" to "There are vendors that". > - Is it OK that the intended status is Standards Track? Shouldn't it be BCP? We are deprecating a few algorithms and adding an IANA column. That is not really BCP work. > - The draft states that it updates RFC 7296, 8221, 8247. What in particular is being updated? > I believe the recent IESG directives require a short explanation of what is being updated > to be present in Abstract. In any case, it should be clearly indicated in the body of the document. > Have I missed it? It updates the IANA registries and deprecates a number of algorithms defined. It is really updating RFC 4306 section 6 IANA Considerations, but 4306 is obsoleted by 5996 which is obsoleted by 7296. https://datatracker.ietf.org/doc/html/rfc4306#section-6 The 8221/8247 RFC's state non-mentioned algorithms remain in their MAY state, and this draft updates some of those "unmentioned therefor MAY" to DEPRECATED. > - Section3: I think that phrase "IKEv2 is a more secure protocol than IKEv1 in every aspect." is a bit too vague. > I believe it's better to list security aspects where we believe IKEv2 is superior: > > * IKEv2 supports modern cryptographic primitives, including AEAD ciphers > * IKEv2 provides real defense against DoS (cookies, core spec) and DDoS (puzzles, RFC 8019) attacks > * support for post-quantum crypto in IKEv2 is being developed (draft-ietf-ipsecme-ikev2-multiple-ke) > * IKEv2 supports various authentication methods via integration with EAP (core spec) > * an extension that allows build PAKE methods in IKEv2 exists (RFC 6467) > * did I forget something? I'm okay either way. Originally, I didn't want to go into too much detail, but if the WG wants to add these, we can do that. > - Section 4.3. Formally RFC 6407 is not directly concerned with IKEv1. > This is an independent protocol developed by msec WG that was based on IKEv1. > I think more accurate language should be used to make this clear. For example: > > Group Domain of Interpretation (GDOI, RFC 6407) protocol based on IKEv1 > defines the support for Multicast Group SAs. > > I also think that reference to RFC 3740 should be remove (it doesn't even mention IKE > in any substantial way). I'm not so sure about RFC 5374, but I'm inclining > to remove it too - it's mostly concerned with MCAS architecture and doesn't > define any concrete IKEv1 changes to support it. So, leave only RFC 6407. I'm fine with this change. Queued up for next version. > - Section 5 lists deprecated algorithms. In my reading this list > is inconsistent with Section 7 (IANA Considerations) which lists > many more deprecated algorithms... So, I'm a bit puzzled > how to read this section. There was one error. AUTH_HMAC_SHA1_160 should be added to 4.3. The other "additional" entries are those that have been deprecated already by RFC 8247, but are listed here so that IANA will add the deprecated keyword in the new column. > - The draft currently has all its references as Normative. > I have no problems with this (except that RFC 3740 is Informational, > so should not be referenced as Normative in Standards Track and BCP documents, > but I suggested to remove it anyway). My concern is that > referencing active drafts as Normative will lead to slow down > publication of this document until those drafts are published. > I don't think it's a major problem (we will have an incentive > to work harder on these drafts :-)), just should be noted. You are right, they should be changed to Informative. I'll wait another day or so for further feedback, then push another update. Thanks, Paul From nobody Mon Jun 28 15:26:16 2021 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 793363A1778; Mon, 28 Jun 2021 15:26:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.436 X-Spam-Level: X-Spam-Status: No, score=-2.436 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.338, RCVD_IN_DNSWL_BLOCKED=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 (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 NIhb99gKnt5C; Mon, 28 Jun 2021 15:26:08 -0700 (PDT) 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 394723A1768; Mon, 28 Jun 2021 15:26:08 -0700 (PDT) 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 D94DE20305; Tue, 29 Jun 2021 01:26:00 +0300 (EEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=iki.fi; s=meesny; t=1624919161; 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=dgfm5em4kvpXcULfJKtv6fgxi3d/2/7YohXZVWLF94I=; b=Dq/GvkPUXW+AFicfuaWaCSZDfEa2INCb1qRXvO0niLNgurbJWN/06bjr/n2qr5PS7f8boi b2HxWM/AmYLkuMIGCvn4ybSxz/3q73ODJm7ZitZvHMExTLcmW27XccYGJsBBYnRvlatmHu ScVO2ktwRdoWdbhHbO/LiVopZOTK87g= Received: by fireball.acr.fi (Postfix, from userid 15204) id 95BE025C12BC; Tue, 29 Jun 2021 01:26:00 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-ID: <24794.19576.563279.476957@fireball.acr.fi> Date: Tue, 29 Jun 2021 01:26:00 +0300 From: Tero Kivinen To: Christian Hopps Cc: Paul Wouters , IPsecME WG , ipsecme-chairs@ietf.org In-Reply-To: References: <6CC0C346-9230-4F21-91B5-06D601A81BC7@chopps.org> X-Mailer: VM 8.2.0b under 26.3 (x86_64--netbsd) X-Edit-Time: 2 min X-Total-Time: 1 min 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=1624919161; a=rsa-sha256; cv=none; b=zUGlb9mK94KNh1odIBfzyUt5vKzY5iH9HDcHcJnSpoxZzBLCR+S9h6E54hpQPHnytMgsnZ O5aAOwV8GB54FAob+TE6L0bnCV8gm3mXNTTCpuMe6lAE/ZA2q35VMqiW+gXC9qvwSX7WAy WwHYylJSco5XVQ8NUBrtZnoVNDjdIlU= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=iki.fi; s=meesny; t=1624919161; 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=dgfm5em4kvpXcULfJKtv6fgxi3d/2/7YohXZVWLF94I=; b=i7b4hwge+n5YNvOqDsJ4D3VLNtbTvYPoP+6mAOfk2rB45k7hLALXjzSj4AykwVDSv4KOUF hRAJh6Bs9eknGCGeYfLUlywtSJvlw/afBkhMrgmwDynuMe1Tq2H2uV1I6zcJl0B7x7MErN SoaR7JUuGAYZ1TNoylD3UG4bcGKovgU= Archived-At: Subject: Re: [IPsec] ipsecme not meeting @ IETF 111? 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, 28 Jun 2021 22:26:14 -0000 Christian Hopps writes: > > On Jun 27, 2021, at 10:30 AM, Paul Wouters wrote: > >> On Jun 27, 2021, at 05:04, Christian Hopps wro= te: > >> =EF=BB=BFI don=E2=80=99t see ipsecme scheduled at IETF 111, is the= re no meeting=3F I was too busy before my vacation and forgot to do it before I left sailing. > > I hope that is a mistake that can be fixed > I suspect it still can, but time is probably very limited. I believe > this is the preliminary agenda.=20 I sent email today to ask whether it can be still be fixed, we will see whether they can allocate some time for us. --=20 kivinen@iki.fi From nobody Mon Jun 28 15:31:21 2021 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 021FA3A18F9; Mon, 28 Jun 2021 15:31:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.195 X-Spam-Level: X-Spam-Status: No, score=-4.195 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_NONE=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 Y1KL8wd-VokL; Mon, 28 Jun 2021 15:31:15 -0700 (PDT) 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 8C8FC3A1901; Mon, 28 Jun 2021 15:31:14 -0700 (PDT) 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 15SMV5fj026657 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 28 Jun 2021 18:31:10 -0400 Date: Mon, 28 Jun 2021 15:31:05 -0700 From: Benjamin Kaduk To: Tero Kivinen Cc: Christian Hopps , IPsecME WG , ipsecme-chairs@ietf.org, Paul Wouters Message-ID: <20210628223105.GB17170@kduck.mit.edu> References: <6CC0C346-9230-4F21-91B5-06D601A81BC7@chopps.org> <24794.19576.563279.476957@fireball.acr.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <24794.19576.563279.476957@fireball.acr.fi> Archived-At: Subject: Re: [IPsec] ipsecme not meeting @ IETF 111? 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, 28 Jun 2021 22:31:20 -0000 On Tue, Jun 29, 2021 at 01:26:00AM +0300, Tero Kivinen wrote: > Christian Hopps writes: > > > On Jun 27, 2021, at 10:30 AM, Paul Wouters wrote: > > >> On Jun 27, 2021, at 05:04, Christian Hopps wrote: > > >> I don’t see ipsecme scheduled at IETF 111, is there no meeting? > > I was too busy before my vacation and forgot to do it before I left > sailing. > > > > I hope that is a mistake that can be fixed > > I suspect it still can, but time is probably very limited. I believe > > this is the preliminary agenda. > > I sent email today to ask whether it can be still be fixed, we will > see whether they can allocate some time for us. The security area has a presence in every slot already, so we would need to accept some conflicts (and probably the absence of an AD). My apologies for not reviewing the session (non-)requests before the deadline; I had some external commitments that took priority. -Ben From nobody Mon Jun 28 16:17:20 2021 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 B0F973A1ADD for ; Mon, 28 Jun 2021 16:17:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.238 X-Spam-Level: X-Spam-Status: No, score=-2.238 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.338, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_PASS=-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 n610HTmR0GAR for ; Mon, 28 Jun 2021 16:17:15 -0700 (PDT) Received: from www.goatley.com (www.goatley.com [198.137.202.94]) (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 AC2113A1ADB for ; Mon, 28 Jun 2021 16:17:15 -0700 (PDT) Received: from trixy.bergandi.net (cpe-76-176-14-122.san.res.rr.com [76.176.14.122]) by wwwlocal.goatley.com (PMDF V6.8 #2433) with ESMTP id <0QVF03ZYAQ0R8O@wwwlocal.goatley.com> for ipsec@ietf.org; Mon, 28 Jun 2021 18:17:15 -0500 (CDT) Received: from blockhead.local ([69.12.173.8]) by trixy.bergandi.net (PMDF V6.7-x01 #2433) with ESMTPSA id <0QVF00IBOPZVBF@trixy.bergandi.net> for ipsec@ietf.org; Mon, 28 Jun 2021 16:16:43 -0700 (PDT) Received: from 69-12-173-8.static.dsltransport.net ([69.12.173.8] EXTERNAL) (EHLO blockhead.local) with TLS/SSL by trixy.bergandi.net ([10.0.42.18]) (PreciseMail V3.3); Mon, 28 Jun 2021 16:16:43 -0700 Date: Mon, 28 Jun 2021 16:17:13 -0700 From: Dan Harkins In-reply-to: <059201d76bf6$e29680c0$a7c38240$@gmail.com> To: ipsec@ietf.org Message-id: <8ea212cf-ee37-ceed-f905-4fde94173c1d@lounge.org> MIME-version: 1.0 Content-type: text/plain; charset=utf-8; format=flowed Content-language: en-US Content-transfer-encoding: 8BIT User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.7.1 X-PMAS-SPF: SPF check skipped for authenticated session (recv=trixy.bergandi.net, send-ip=69.12.173.8) X-PMAS-External-Auth: 69-12-173-8.static.dsltransport.net [69.12.173.8] (EHLO blockhead.local) References: <315BBB8D-B55E-43C8-A988-ADC8780AD62E@gmail.com> <059201d76bf6$e29680c0$a7c38240$@gmail.com> X-PMAS-Software: PreciseMail V3.3 [210625] (trixy.bergandi.net) X-PMAS-Allowed: system rule (rule allow header:X-PMAS-External noexists) Archived-At: Subject: Re: [IPsec] WGLC for draft-ietf-ipsecme-ikev1-algo-to-historic 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, 28 Jun 2021 23:17:19 -0000   Hi, On 6/28/21 1:23 AM, Valery Smyslov wrote: > Hi, > > I think document is mostly ready. Few observations: > > - FWIW I think that Dan's efforts to make draft's language less speculative and more concrete > are valid and should be reflected in the document. > > - Is it OK that the intended status is Standards Track? Shouldn't it be BCP? > > - The draft states that it updates RFC 7296, 8221, 8247. What in particular is being updated? > I believe the recent IESG directives require a short explanation of what is being updated > to be present in Abstract. In any case, it should be clearly indicated in the body of the document. > Have I missed it? > > - Section3: I think that phrase "IKEv2 is a more secure protocol than IKEv1 in every aspect." is a bit too vague.   You know, that was bugging me too. "in every aspect" is laying it on a bit thick. IKEv1 has a security proof. The much maligned PSK mode authenticates the key as well as the exchange which is better than what IKEv2 does (and why IKEv1 did not need an update to do PQC). So saying it's less secure "in every aspect" just isn't true. But I couldn't figure out a better way to say it.... > I believe it's better to list security aspects where we believe IKEv2 is superior: > > * IKEv2 supports modern cryptographic primitives, including AEAD ciphers > * IKEv2 provides real defense against DoS (cookies, core spec) and DDoS (puzzles, RFC 8019) attacks > * support for post-quantum crypto in IKEv2 is being developed (draft-ietf-ipsecme-ikev2-multiple-ke) > * IKEv2 supports various authentication methods via integration with EAP (core spec) > * an extension that allows build PAKE methods in IKEv2 exists (RFC 6467) > * did I forget something?   But this is great! I agree that such a brief summary of the superior features would be better than a factually challenged "in every aspect" statement.   regards,   Dan. -- "The object of life is not to be on the side of the majority, but to escape finding oneself in the ranks of the insane." -- Marcus Aurelius From nobody Mon Jun 28 16:20:45 2021 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 3F3003A1AF1; Mon, 28 Jun 2021 16:20:44 -0700 (PDT) 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, SPF_HELO_NONE=0.001, SPF_NONE=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 qT068o6dCj6s; Mon, 28 Jun 2021 16:20:39 -0700 (PDT) Received: from smtp.chopps.org (smtp.chopps.org [54.88.81.56]) by ietfa.amsl.com (Postfix) with ESMTP id D3FEE3A1AF3; Mon, 28 Jun 2021 16:20:38 -0700 (PDT) Received: from ja.int.chopps.org.chopps.org (047-026-251-217.res.spectrum.com [47.26.251.217]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (2048 bits) server-digest SHA256) (Client did not present a certificate) by smtp.chopps.org (Postfix) with ESMTPSA id E39E580F39; Mon, 28 Jun 2021 23:20:37 +0000 (UTC) References: <6CC0C346-9230-4F21-91B5-06D601A81BC7@chopps.org> <24794.19576.563279.476957@fireball.acr.fi> <20210628223105.GB17170@kduck.mit.edu> User-agent: mu4e 1.5.13; emacs 27.2 From: Christian Hopps To: Benjamin Kaduk Cc: Tero Kivinen , Christian Hopps , IPsecME WG , ipsecme-chairs@ietf.org, Paul Wouters Date: Mon, 28 Jun 2021 19:19:58 -0400 In-reply-to: <20210628223105.GB17170@kduck.mit.edu> Message-ID: MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" Archived-At: Subject: Re: [IPsec] ipsecme not meeting @ IETF 111? 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, 28 Jun 2021 23:20:44 -0000 --=-=-= Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Benjamin Kaduk writes: > On Tue, Jun 29, 2021 at 01:26:00AM +0300, Tero Kivinen wrote: >> Christian Hopps writes: >> > > On Jun 27, 2021, at 10:30 AM, Paul Wouters wrote: >> > >> On Jun 27, 2021, at 05:04, Christian Hopps wrot= e: >> > >> =EF=BB=BFI don=E2=80=99t see ipsecme scheduled at IETF 111, is ther= e no meeting? >> >> I was too busy before my vacation and forgot to do it before I left >> sailing. >> >> > > I hope that is a mistake that can be fixed >> > I suspect it still can, but time is probably very limited. I believe >> > this is the preliminary agenda. >> >> I sent email today to ask whether it can be still be fixed, we will >> see whether they can allocate some time for us. > > The security area has a presence in every slot already, so we would need = to > accept some conflicts (and probably the absence of an AD). Something is better than nothing, applies here I think. Thanks, Chris. > My apologies for not reviewing the session (non-)requests before the > deadline; I had some external commitments that took priority. > > -Ben --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEm56yH/NF+m1FHa6lLh2DDte4MCUFAmDaWUIACgkQLh2DDte4 MCUqnBAAmAQ97Y1OxL88lWK/5i+Ku+5KCuDG9hXYMKzJFHUQ8IyOFidi2Uxksfai Ac/q3FK8pPQcwBoPWJBc8USAO5E9a88kvHhI4ctBHtGJ2pUMz28DtPXXB1PLCQTF 2oOh2Whp2Vsqk9ejEkVj+hxkL637X+1ZC8dAzlkWt7UidBafFx1K5EmuGTe5hMgU d7Vt/Mx8ixds2tixXJPAO1QjooMi1ZbCqEkSICjNToKK9C7LXoR4PXLJis/e0B8U hXjn2j01ZO39qwg5fuO3pTKNywCmNwr7L0X9SA09Q2HNxKne6NCqsQeenU3vkRtO e0jZtPwgY/H1wvON4i38S58/WIFZ/7Mz1WvBC1nnpu2F+TICWt50obzhcEUkH8VJ K02OzGRGKX/Xdi8VIXyyLdGq/3fpzCrn9t0thxL6pZoBSjCScNbHjaFCiKpP4H26 mGERyIyMTqXQPlv1phcrc7WGyaDacGPgT77Dfd2US97BpxYoOKVY7o3TxBmNaHzB k+keeq7uL/G4zEeWIz0bVnf+CHVB6CUFzWX2ACd0ImV3Ly2DAwFJEU1RiSL8PGZp 48nr4H15ZwSRTC3XmjG92JH3YgQWSk3rLIx5opvQZ+BSxpUCWM2LVSaF9UzSGP+P ymyIIADDVo16xbXqFQsq9nhfBU4AJYqx5d7lupd+y+q4zGsCCMk= =GBN1 -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon Jun 28 18:10:07 2021 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 288273A1E61 for ; Mon, 28 Jun 2021 18:10:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pkcAwKG4IS87 for ; Mon, 28 Jun 2021 18:10:01 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A600F3A1E5B for ; Mon, 28 Jun 2021 18:10:01 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 1B78E3897F; Mon, 28 Jun 2021 21:12:00 -0400 (EDT) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id qxmp-zCmOhwm; Mon, 28 Jun 2021 21:11:58 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id AB6573897E; Mon, 28 Jun 2021 21:11:58 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 7C50C264; Mon, 28 Jun 2021 21:09:58 -0400 (EDT) From: Michael Richardson To: Christian Hopps , IPsecME WG In-Reply-To: References: <6CC0C346-9230-4F21-91B5-06D601A81BC7@chopps.org> <24794.19576.563279.476957@fireball.acr.fi> <20210628223105.GB17170@kduck.mit.edu> X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [IPsec] ipsecme not meeting @ IETF 111? 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, 29 Jun 2021 01:10:06 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable I think you'll all be happier with a virtual interim meeting with no confli= cts. We can now use meetecho even. =2D- Michael Richardson . o O ( IPv6 I=C3=B8T consulti= ng ) Sandelman Software Works Inc, Ottawa and Worldwide --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAmDacuYACgkQgItw+93Q 3WUU+wgAt0xdKYAIKf1HdGctAN5rF8ED1dzgpDFoB1Wk0qAzW+2V2UAmz5HmN5L6 QkmWiR9S9Q2/JGWQl1He8911BXJel5ERyR4yzDYm5Ni7Iso1TdHk6Dz6uz3jNwKH SkA9rIZKF4sKwjld7kC9ZGC+EtjDwLr8OU9MXCSK6EmSlVCVweFT/0ZGTw27JG2M mHTJl4Kqfh7QNpWv5sB7iruCjvQZ2f5dlZ4GQpgMKg2ZsaM2ePXnhwmDnQ8HVvNw bNi70gEec8Jq4MioWZmKPst5woi9FJfcdAJs5Aoe8waFHGm5naOVVEuH5NgpLYvo 3bq5W0Oa4gPKPUbJguPeqgGqWia9qQ== =uweQ -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon Jun 28 19:11:44 2021 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 6E8E33A2037 for ; Mon, 28 Jun 2021 19:11:42 -0700 (PDT) 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, SPF_HELO_NONE=0.001, SPF_NONE=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 ixM6_ff19tqJ for ; Mon, 28 Jun 2021 19:11:38 -0700 (PDT) Received: from smtp.chopps.org (smtp.chopps.org [54.88.81.56]) by ietfa.amsl.com (Postfix) with ESMTP id 0B3D53A2036 for ; Mon, 28 Jun 2021 19:11:37 -0700 (PDT) Received: from ja.int.chopps.org.chopps.org (047-026-251-217.res.spectrum.com [47.26.251.217]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (2048 bits) server-digest SHA256) (Client did not present a certificate) by smtp.chopps.org (Postfix) with ESMTPSA id 4E0F480CBD; Tue, 29 Jun 2021 02:11:37 +0000 (UTC) References: <6CC0C346-9230-4F21-91B5-06D601A81BC7@chopps.org> <24794.19576.563279.476957@fireball.acr.fi> <20210628223105.GB17170@kduck.mit.edu> <12573.1624928998@localhost> User-agent: mu4e 1.5.13; emacs 27.2 From: Christian Hopps To: Michael Richardson Cc: Christian Hopps , IPsecME WG Date: Mon, 28 Jun 2021 22:09:30 -0400 In-reply-to: <12573.1624928998@localhost> Message-ID: MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" Archived-At: Subject: Re: [IPsec] ipsecme not meeting @ IETF 111? 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, 29 Jun 2021 02:11:42 -0000 --=-=-= Content-Type: text/plain; format=flowed Michael Richardson writes: > [[PGP Signed Part:Signature made by expired key 808B70FBDDD0DD65 Michael Richardson ]] > > I think you'll all be happier with a virtual interim meeting with no conflicts. > We can now use meetecho even. It has been my (admittedly limited) experience that the IETF meeting is the driver of things "getting done" in ipsecme. Will an interim have the same result? Thanks, Chris. --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEm56yH/NF+m1FHa6lLh2DDte4MCUFAmDagVgACgkQLh2DDte4 MCV/kQ/+Pc4P4PzyXFnCrrIO7Jf+bHwT8OPpFhZEiU3OQQgabUlo+h+5A24gQ7J5 173MRhjlmaWgrwtRl4HVNtBNonulEx8kM9KyShx6PlN9oD1w8ECGtEFTyMqEZ63H tpXkMqqGPGGTybG16Lrl4B3p8y6e2fQM/WQdX2H5/xG4HpOQa3CzMrPt6McOxgcR CBA55VrPG3LUZJFTKrfqbN3gWzuTn4K2gOK2BgxZOKxB4YnZKZXdf6QVEkgS63Pb iVI5+HAQau6v/ZntHDjh6fDESTiHbAJT0PW+JjRTv5NjcE/wylAYd0mc5tfzGcty P9fDLQvjo6xeJ1/iY9PSyP4qn0T75xC+QWm88Mxw+w+FO1J9dQgoHnLQAF0xGjIn GxSQ1tdrFjnkf6zjaWX9jOv6Tz4DGNCwbGwCxnrP4uzU5tJhcmWqfNtiSP4RrygG NMfpNrBTPQlIrphxmKCNVMB0CrikdsaVYCN7EPH3MNnyAIOFFQ8TTMQfn5HDMzaB o7Nf6YwLr1K5ZIfIHwqzBi4WaHIXulEJl/5lLgshmbc2en6jLXPRGzPd7GqJToC0 NpbgK9awBhvveUmTcbJtHUycF14IUq3dbPaHteeO/MdSPkigwc6MUZLcrmPNIC/B tXtStLcQl4n/cjq0WZF/fCk+VwxsqYHs0KNDoeSPGhw0TvDW9ZA= =sCor -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue Jun 29 07:21:58 2021 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 7F28D3A35DC for ; Tue, 29 Jun 2021 07:21:56 -0700 (PDT) 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, RCVD_IN_DNSWL_NONE=-0.0001, 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 9dgzm7rp6cFs for ; Tue, 29 Jun 2021 07:21:51 -0700 (PDT) Received: from mail-qk1-x72b.google.com (mail-qk1-x72b.google.com [IPv6:2607:f8b0:4864:20::72b]) (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 9689B3A35DA for ; Tue, 29 Jun 2021 07:21:51 -0700 (PDT) Received: by mail-qk1-x72b.google.com with SMTP id 19so20885387qky.13 for ; Tue, 29 Jun 2021 07:21:51 -0700 (PDT) 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=+NYSlOQhgTLGlkm8DuPTdsCJ7RmCn+wz3IkItVLc/kQ=; b=tGgQKC7uCqCLjZJomk6rKSeO0TLD9nlB8U/0q/QDDqSKaAyJr/p4fmkFoR6MzQddzF bT26B9QVhsOO5YAO3fQNg+i7l2/00Jf/0Q6EMz8EblQzdf/8D7TfdbAiDqnY5zzP7e9o FMFeCBH7wSRNdq47irmOukgIww9teD2RemFdOConX5rHlIk2mz7my4XaWvtYpa7NW3I1 GVlP8V9jse6/FIfFdrNAOKEOP6TJcu+cPCvSGsSR8Mk+BIUjKxdRFVGzAhPdCmhStxRV B3qsPpdQzUpIfdrVJaNBDZbeptNGxwlf9etIwRlMuBS8oOAymnuli9jIsldnnwLwiYxO 2gtg== 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=+NYSlOQhgTLGlkm8DuPTdsCJ7RmCn+wz3IkItVLc/kQ=; b=FuI5pJPrKm9JRm5V+TSG4NKQMuf1b0bBca3raQaW5vboxbh8EdnnA7n6HYDl8+0r+l azW2UnL/qcHNl3l1SyWim7sCcwc0aqWRqOHO5KJ+ETOyYFlR1ScqXgbeQg3IOWHnUzUF 5+91SGgJ5HauTctp2j/yVbN3t8cT1oYBqdTXkkwdeAqlWyQSILYg6eNvcZA7LjTyfte3 2yqhGZi2q6d9acW0RAsGf1QHAXc1ArKI+LzToqNIIHTI3NlLjfAC8gyeCQuYfgrnZBrl QgeP0ND3o0bPBVaGSWK1ixqA4fvAjtuiEIBzdWmu6rYcJ0D7dwg+FkRHnK+swTHH/foY FN+A== X-Gm-Message-State: AOAM533rM0Fgf1PrtdVVR7GfVZLKwnoRfozrjwhdKSTZjaimOBOxPULl Mwu4btL5VlRJnkuXgMSEL0eSl1G2wiATcmn+ZHqPoB7t5s8= X-Google-Smtp-Source: ABdhPJyzOcNGJHaNNxYmML7dAENhLF8jcXXowMyhTMTsfsGaXikF/RT7bm1TByA27MiekD4RFOAYC3qKVZU8xs0VC0M= X-Received: by 2002:a37:7046:: with SMTP id l67mr31222522qkc.69.1624976509474; Tue, 29 Jun 2021 07:21:49 -0700 (PDT) MIME-Version: 1.0 References: <315BBB8D-B55E-43C8-A988-ADC8780AD62E@gmail.com> <059201d76bf6$e29680c0$a7c38240$@gmail.com> <8ea212cf-ee37-ceed-f905-4fde94173c1d@lounge.org> In-Reply-To: <8ea212cf-ee37-ceed-f905-4fde94173c1d@lounge.org> From: Daniel Migault Date: Tue, 29 Jun 2021 10:21:38 -0400 Message-ID: To: Dan Harkins Cc: IPsecME WG Content-Type: multipart/alternative; boundary="0000000000009d9d0305c5e8531c" Archived-At: Subject: Re: [IPsec] WGLC for draft-ietf-ipsecme-ikev1-algo-to-historic 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, 29 Jun 2021 14:21:57 -0000 --0000000000009d9d0305c5e8531c Content-Type: text/plain; charset="UTF-8" I believe that the first sentence of section 3 says it all. ship it! I still have some minor comments, though these may have already been discussed. There are no normative MUST to upgrade ( and in general very little normative language). Shouldn't we have for example: Systems running IKEv1 should be upgraded and reconfigured to run IKEv2. moved to : Systems running IKEv1 MUST be upgraded and reconfigured to run IKEv2. There are overall very little number of SHOULD/MUST but maybe that is an editorial choice. Yours, Daniel Yours, Daniel On Mon, Jun 28, 2021 at 7:17 PM Dan Harkins wrote: > > Hi, > > On 6/28/21 1:23 AM, Valery Smyslov wrote: > > Hi, > > > > I think document is mostly ready. Few observations: > > > > - FWIW I think that Dan's efforts to make draft's language less > speculative and more concrete > > are valid and should be reflected in the document. > > > > - Is it OK that the intended status is Standards Track? Shouldn't it be > BCP? > > > > - The draft states that it updates RFC 7296, 8221, 8247. What in > particular is being updated? > > I believe the recent IESG directives require a short explanation of > what is being updated > > to be present in Abstract. In any case, it should be clearly > indicated in the body of the document. > > Have I missed it? > > > > - Section3: I think that phrase "IKEv2 is a more secure protocol than > IKEv1 in every aspect." is a bit too vague. > > You know, that was bugging me too. "in every aspect" is laying it on > a bit thick. IKEv1 > has a security proof. The much maligned PSK mode authenticates the key > as well as the > exchange which is better than what IKEv2 does (and why IKEv1 did not > need an update to do > PQC). So saying it's less secure "in every aspect" just isn't true. But > I couldn't figure > out a better way to say it.... > > > I believe it's better to list security aspects where we believe IKEv2 > is superior: > > > > * IKEv2 supports modern cryptographic primitives, including AEAD > ciphers > > * IKEv2 provides real defense against DoS (cookies, core spec) and > DDoS (puzzles, RFC 8019) attacks > > * support for post-quantum crypto in IKEv2 is being developed > (draft-ietf-ipsecme-ikev2-multiple-ke) > > * IKEv2 supports various authentication methods via integration with > EAP (core spec) > > * an extension that allows build PAKE methods in IKEv2 exists (RFC > 6467) > > * did I forget something? > > But this is great! I agree that such a brief summary of the superior > features > would be better than a factually challenged "in every aspect" statement. > > regards, > > Dan. > > -- > "The object of life is not to be on the side of the majority, but to > escape finding oneself in the ranks of the insane." -- Marcus Aurelius > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > -- Daniel Migault Ericsson --0000000000009d9d0305c5e8531c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I believe that the first sentence of section=C2=A03 says i= t all. ship it!

I still have some minor comments, though= these may have already been discussed. There are no normative MUST to upgr= ade ( and in general very little normative language).=C2=A0
Shoul= dn't we have for example:
Systems running IKEv1 should be upgraded and=C2=A0reconfi= gured to run IKEv2.

moved to :
Systems running IKEv1 MUST be upgraded and reconfigured =
to run IKEv2.

There are overall very little number of SHOULD/MUST but maybe that is an = editorial choice.=C2=A0

Yours,=C2=A0
Daniel=C2=A0

=
=C2=A0
=C2=A0

<= /div>
Yours,=C2=A0
Daniel

On Mon, Jun 28, 2021 at 7:17 P= M Dan Harkins <dharkins@lounge.or= g> wrote:

=C2=A0=C2=A0 Hi,

On 6/28/21 1:23 AM, Valery Smyslov wrote:
> Hi,
>
> I think document is mostly ready. Few observations:
>
> - FWIW I think that Dan's efforts to make draft's language les= s speculative and more concrete
>=C2=A0 =C2=A0 =C2=A0are valid and should be reflected in the document.<= br> >
> - Is it OK that the intended status is Standards Track? Shouldn't = it be BCP?
>
> - The draft states that it updates RFC 7296, 8221, 8247. What in parti= cular is being updated?
>=C2=A0 =C2=A0 =C2=A0I believe the recent IESG directives require a shor= t explanation of what is being updated
>=C2=A0 =C2=A0 =C2=A0to be present in Abstract. In any case, it should b= e clearly indicated in the body of the document.
>=C2=A0 =C2=A0 =C2=A0Have I missed it?
>
> - Section3: I think that phrase "IKEv2 is a more secure protocol = than IKEv1 in every aspect." is a bit too vague.

=C2=A0=C2=A0 You know, that was bugging me too. "in every aspect"= is laying it on
a bit thick. IKEv1
has a security proof. The much maligned PSK mode authenticates the key
as well as the
exchange which is better than what IKEv2 does (and why IKEv1 did not
need an update to do
PQC). So saying it's less secure "in every aspect" just isn&#= 39;t true. But
I couldn't figure
out a better way to say it....

>=C2=A0 =C2=A0 I believe it's better to list security aspects where = we believe IKEv2 is superior:
>
>=C2=A0 =C2=A0 * IKEv2 supports modern cryptographic primitives, includi= ng AEAD ciphers
>=C2=A0 =C2=A0 * IKEv2 provides real defense against DoS (cookies, core = spec) and DDoS (puzzles, RFC 8019) attacks
>=C2=A0 =C2=A0 * support for post-quantum crypto in IKEv2 is being devel= oped (draft-ietf-ipsecme-ikev2-multiple-ke)
>=C2=A0 =C2=A0 * IKEv2 supports various authentication methods via integ= ration with EAP (core spec)
>=C2=A0 =C2=A0 * an extension that allows build PAKE methods in IKEv2 ex= ists (RFC 6467)
>=C2=A0 =C2=A0 * did I forget something?

=C2=A0=C2=A0 But this is great! I agree that such a brief summary of the su= perior
features
would be better than a factually challenged "in every aspect" sta= tement.

=C2=A0=C2=A0 regards,

=C2=A0=C2=A0 Dan.

--
"The object of life is not to be on the side of the majority, but to escape finding oneself in the ranks of the insane." -- Marcus Aurelius=

_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec


--
Daniel Migault
Ericsson
--0000000000009d9d0305c5e8531c-- From nobody Tue Jun 29 11:00:42 2021 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 EF3233A3C42 for ; Tue, 29 Jun 2021 11:00:40 -0700 (PDT) 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 4eSDNimSH8KF for ; Tue, 29 Jun 2021 11:00:36 -0700 (PDT) Received: from mail-wr1-x430.google.com (mail-wr1-x430.google.com [IPv6:2a00:1450:4864:20::430]) (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 BE7A43A3C41 for ; Tue, 29 Jun 2021 11:00:35 -0700 (PDT) Received: by mail-wr1-x430.google.com with SMTP id u8so214385wrq.8 for ; Tue, 29 Jun 2021 11:00:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=UlDBlhyyS4NAkslN8+bzSMmMCuI0YM9uhnBHJFjlrvo=; b=oWBdUNbwlJk6itDh4Cc8K4MybuX02S3oRRVHFp9kqx90/rR5dbJUwkt9VHmdDNNhhB e+2lprYlE9GSSdZaXSw1wnEGldDBMPxgZAoUZ7CEIUwOzR4fDj6jy/wc9Yo3AycKS0TG hn/3rayC66KYtwozAAD/TvPW9SVuHOxTHxhJT/JIZPryfGnRUevuQUIS3oWaIiaaL91s 2I1SeUSj9QMb618aZxett60jHVThW1NgVzKdIaLsybq6vlRPvuyODNj206em9bv1DHCu GmTtMttAOipaymeePDWioFSk4TJX9NZfTUHzc3drhGxKRPNMjmgn/IatxObVz59STYB1 B4lw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=UlDBlhyyS4NAkslN8+bzSMmMCuI0YM9uhnBHJFjlrvo=; b=a7OljJBjPSj5gr5xV73Kx0N582Z88Kgno6WVNNHTX7IV17NY/YqWTLVhUMmrW66WXI LJ75c4tfgvNpRKGQTlHP2VH5z+uqgXy4ytJ/TWHt84d+rXIpypAPvY4bs9yUFjl3BpVC GZ0RZohSF3TON1yMVfrXTnDkuEVAgbg36KuNU2MQkJNy1kxiVUHdJS3swBjdMUFvUftE CMWZyHeErYcKxe8LTVzDpqVNHINEqJBnmEKuqPBcsZZJ3GJ5IuSceh4s2iwFiLMLiAlZ kN7Rxz3rRI/ZOnRCpqW8nKJE3lvuXfExQt6Us1p8rmsXwhZGQex7PV3P789i3VMmPa1v Q66g== X-Gm-Message-State: AOAM530iATFPMiLL59XZKkTiAi7Ne31nPonhcfT0QGbJ7pKytldsjRv7 k8KwySt+bxJncDtS9Y/XGr0= X-Google-Smtp-Source: ABdhPJwmm0/ld3mjAOMgpSl7tuXcbGV+b/JxZXpSvHwsEsGuEnbDrdXjUnbu91f7vox8MojL8wRhlQ== X-Received: by 2002:a05:6000:152:: with SMTP id r18mr35067347wrx.203.1624989632834; Tue, 29 Jun 2021 11:00:32 -0700 (PDT) Received: from smtpclient.apple ([46.120.57.183]) by smtp.gmail.com with ESMTPSA id o11sm17096770wmq.1.2021.06.29.11.00.31 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 29 Jun 2021 11:00:32 -0700 (PDT) From: Yoav Nir Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_6B482C66-AB72-44C2-8649-0D201AE3CDF9" Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.80.0.2.43\)) Date: Tue, 29 Jun 2021 21:00:30 +0300 In-Reply-To: Cc: Dan Harkins , IPsecME WG To: Daniel Migault References: <315BBB8D-B55E-43C8-A988-ADC8780AD62E@gmail.com> <059201d76bf6$e29680c0$a7c38240$@gmail.com> <8ea212cf-ee37-ceed-f905-4fde94173c1d@lounge.org> X-Mailer: Apple Mail (2.3654.80.0.2.43) Archived-At: Subject: Re: [IPsec] WGLC for draft-ietf-ipsecme-ikev1-algo-to-historic 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, 29 Jun 2021 18:00:41 -0000 --Apple-Mail=_6B482C66-AB72-44C2-8649-0D201AE3CDF9 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 [no hats] I don=E2=80=99t want to start (or resume) a religious holy war about = uppercase MUSTs, but they=E2=80=99re usually about protocol compliance. = What people should (not SHOULD) do with their systems is not subject to = requirements language, because the IETF does not engineer = administrators. What? You are not compliant with RFC xxxx if you = didn=E2=80=99t upgrade your systems already? I could understand a statement that Product yyyy is not compliant with = RFC xxxx because it still offers IKEv1, but I don=E2=80=99t like = non-compliant administrators. Not that I=E2=80=99m advocating to add = that statement to the draft. I think it=E2=80=99s fine as it is: just = offering advice that systems should be upgraded. Yoav > On 29 Jun 2021, at 17:21, Daniel Migault wrote: >=20 > I believe that the first sentence of section 3 says it all. ship it! >=20 > I still have some minor comments, though these may have already been = discussed. There are no normative MUST to upgrade ( and in general very = little normative language).=20 > Shouldn't we have for example: > Systems running IKEv1 should be upgraded and reconfigured to run = IKEv2. >=20 > moved to : > Systems running IKEv1 MUST be upgraded and reconfigured to run IKEv2. >=20 > There are overall very little number of SHOULD/MUST but maybe that is = an editorial choice.=20 >=20 > Yours,=20 > Daniel=20 >=20 >=20 > =20 > =20 >=20 > Yours,=20 > Daniel >=20 > On Mon, Jun 28, 2021 at 7:17 PM Dan Harkins > wrote: >=20 > Hi, >=20 > On 6/28/21 1:23 AM, Valery Smyslov wrote: > > Hi, > > > > I think document is mostly ready. Few observations: > > > > - FWIW I think that Dan's efforts to make draft's language less = speculative and more concrete > > are valid and should be reflected in the document. > > > > - Is it OK that the intended status is Standards Track? Shouldn't it = be BCP? > > > > - The draft states that it updates RFC 7296, 8221, 8247. What in = particular is being updated? > > I believe the recent IESG directives require a short explanation = of what is being updated > > to be present in Abstract. In any case, it should be clearly = indicated in the body of the document. > > Have I missed it? > > > > - Section3: I think that phrase "IKEv2 is a more secure protocol = than IKEv1 in every aspect." is a bit too vague. >=20 > You know, that was bugging me too. "in every aspect" is laying it = on=20 > a bit thick. IKEv1 > has a security proof. The much maligned PSK mode authenticates the key=20= > as well as the > exchange which is better than what IKEv2 does (and why IKEv1 did not=20= > need an update to do > PQC). So saying it's less secure "in every aspect" just isn't true. = But=20 > I couldn't figure > out a better way to say it.... >=20 > > I believe it's better to list security aspects where we believe = IKEv2 is superior: > > > > * IKEv2 supports modern cryptographic primitives, including AEAD = ciphers > > * IKEv2 provides real defense against DoS (cookies, core spec) = and DDoS (puzzles, RFC 8019) attacks > > * support for post-quantum crypto in IKEv2 is being developed = (draft-ietf-ipsecme-ikev2-multiple-ke) > > * IKEv2 supports various authentication methods via integration = with EAP (core spec) > > * an extension that allows build PAKE methods in IKEv2 exists = (RFC 6467) > > * did I forget something? >=20 > But this is great! I agree that such a brief summary of the = superior=20 > features > would be better than a factually challenged "in every aspect" = statement. >=20 > regards, >=20 > Dan. >=20 > --=20 > "The object of life is not to be on the side of the majority, but to > escape finding oneself in the ranks of the insane." -- Marcus Aurelius >=20 > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec = >=20 >=20 > --=20 > Daniel Migault > Ericsson > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec --Apple-Mail=_6B482C66-AB72-44C2-8649-0D201AE3CDF9 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 [no = hats]
I don=E2=80=99t want to start (or resume) a = religious holy war about uppercase MUSTs, but they=E2=80=99re usually = about protocol compliance. What people should (not SHOULD) do with their = systems is not subject to requirements language, because the IETF does = not engineer administrators. What? You are not compliant with RFC xxxx = if you didn=E2=80=99t upgrade your systems already?

I could understand a statement that = Product yyyy is not compliant with RFC xxxx because it still offers = IKEv1, but I don=E2=80=99t like non-compliant administrators. Not that = I=E2=80=99m advocating to add that statement to the draft. I think = it=E2=80=99s fine as it is: just offering advice that systems should be = upgraded.

Yoav

On 29 Jun 2021, at 17:21, = Daniel Migault <mglt.ietf@gmail.com> wrote:

I believe that the first sentence of section 3 says it = all. ship it!

I = still have some minor comments, though these may have already been = discussed. There are no normative MUST to upgrade ( and in general very = little normative language). 
Shouldn't we have = for example:
Systems running IKEv1 should be upgraded = and reconfigured to run IKEv2.

moved to :
Systems running IKEv1 MUST be upgraded and =
reconfigured to run IKEv2.

There are overall very little = number of SHOULD/MUST but maybe that is an editorial = choice. 

Yours, 
Daniel 


 
 

Yours, 
Daniel

On Mon, Jun = 28, 2021 at 7:17 PM Dan Harkins <dharkins@lounge.org> wrote:

   Hi,

On 6/28/21 1:23 AM, Valery Smyslov wrote:
> Hi,
>
> I think document is mostly ready. Few observations:
>
> - FWIW I think that Dan's efforts to make draft's language less = speculative and more concrete
>     are valid and should be reflected in the = document.
>
> - Is it OK that the intended status is Standards Track? Shouldn't = it be BCP?
>
> - The draft states that it updates RFC 7296, 8221, 8247. What in = particular is being updated?
>     I believe the recent IESG directives require a = short explanation of what is being updated
>     to be present in Abstract. In any case, it = should be clearly indicated in the body of the document.
>     Have I missed it?
>
> - Section3: I think that phrase "IKEv2 is a more secure protocol = than IKEv1 in every aspect." is a bit too vague.

   You know, that was bugging me too. "in every aspect" is = laying it on
a bit thick. IKEv1
has a security proof. The much maligned PSK mode authenticates the key =
as well as the
exchange which is better than what IKEv2 does (and why IKEv1 did not
need an update to do
PQC). So saying it's less secure "in every aspect" just isn't true. But =
I couldn't figure
out a better way to say it....

>    I believe it's better to list security aspects where = we believe IKEv2 is superior:
>
>    * IKEv2 supports modern cryptographic primitives, = including AEAD ciphers
>    * IKEv2 provides real defense against DoS (cookies, = core spec) and DDoS (puzzles, RFC 8019) attacks
>    * support for post-quantum crypto in IKEv2 is being = developed (draft-ietf-ipsecme-ikev2-multiple-ke)
>    * IKEv2 supports various authentication methods via = integration with EAP (core spec)
>    * an extension that allows build PAKE methods in IKEv2 = exists (RFC 6467)
>    * did I forget something?

   But this is great! I agree that such a brief summary of the = superior
features
would be better than a factually challenged "in every aspect" = statement.

   regards,

   Dan.

--
"The object of life is not to be on the side of the majority, but to
escape finding oneself in the ranks of the insane." -- Marcus = Aurelius

_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec


--
Daniel Migault
Ericsson
_______________________________________________
IPsec = mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

= --Apple-Mail=_6B482C66-AB72-44C2-8649-0D201AE3CDF9-- From nobody Tue Jun 29 11:17:20 2021 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 D1EDB3A3CB6 for ; Tue, 29 Jun 2021 11:17:18 -0700 (PDT) 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, RCVD_IN_DNSWL_NONE=-0.0001, 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 TjNvWyVQvB_N for ; Tue, 29 Jun 2021 11:17:14 -0700 (PDT) Received: from mail-qv1-xf2a.google.com (mail-qv1-xf2a.google.com [IPv6:2607:f8b0:4864:20::f2a]) (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 7B9313A3CB9 for ; Tue, 29 Jun 2021 11:17:14 -0700 (PDT) Received: by mail-qv1-xf2a.google.com with SMTP id m15so11539928qvc.9 for ; Tue, 29 Jun 2021 11:17:14 -0700 (PDT) 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=VjE3oxhSEiTcFrB5FOfTy15vLsgiDMkkOZTGTPIILZg=; b=d6kcw2lwGfQV8OgpHp8fShPR0X+c1TgOoYzJfn9Sgpd+lXm+h9Kxlx6jbyPOyJ3PNm QiDpSLQXrxFrOtm27+7FjSOiAPdsGkhbc2BX/jhGQJL8H0q/DlLnTqMLX/fgKEsE+Oii i1RyZa4kBkdOkahYat0fLBZZt+naXw/CY2ViUUeBpsgrJN+Hj4pNkldvwJdE9SIOdfd7 ZBBrxNx2eLghynBbwKdtz1us8wsUyKFH3RZXYVuv3VgGP4ufja1tHjYL0Ld4+MfGvTAb A4A/0gR/OI+qp29KI6E8e34WdFy6afpCZzHmZCUJ9Tn0kLa0QutJESWZCTmWLjrPfOIQ Tmrw== 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=VjE3oxhSEiTcFrB5FOfTy15vLsgiDMkkOZTGTPIILZg=; b=eNfErI6jBHl1PdM2rigwBCrVtS0jC9e7domd9tIGPJfZYSBI0tdv2upJwkZ6RgV/bs kAwifIRUzpR83DQzRJ/BUjs0ZDMjFqKTMIA03jZJpmNDp6DASDZTSdL1LeIhrXMBjOOq GwoEDfR4tItDK2ztZFzr+wj9gX9PKaXHNnIIsirIZoSzz0JMfLUsS+Xx4dctCInFdghA LQUlBl8Qw69tKb7HalPElG4n7q7y9VPZvx6A28Ef9IkCFPBBkoriVXBG9YZTCQ6tI2ZG 2RH/d8DEQBh1P7GcsyS6gRb58/zZ/uUhvjmEsJyOZdV4AsBgbOlOxQYJR1TrbGdoPUL7 BAuw== X-Gm-Message-State: AOAM532T4N8Cb1Z2vgvGkaX/HhIRBh0DLiD8IGSPqhQR1G91yPVTwPeU R6KMSdzer7py/7Czt8IeuUyYokQ7bfBl9hYdXJ8= X-Google-Smtp-Source: ABdhPJyHe/LCkbP/wlfpi8yQvg3f0gyfpwDBgzP/dXnYZfNe+VltAWX3LPDb4OH4rBmkDjX2jj9g6upzLXuFPXeG5c4= X-Received: by 2002:a05:6214:804:: with SMTP id df4mr31700233qvb.16.1624990632961; Tue, 29 Jun 2021 11:17:12 -0700 (PDT) MIME-Version: 1.0 References: <315BBB8D-B55E-43C8-A988-ADC8780AD62E@gmail.com> <059201d76bf6$e29680c0$a7c38240$@gmail.com> <8ea212cf-ee37-ceed-f905-4fde94173c1d@lounge.org> In-Reply-To: From: Daniel Migault Date: Tue, 29 Jun 2021 14:17:02 -0400 Message-ID: To: Yoav Nir Cc: Dan Harkins , IPsecME WG Content-Type: multipart/alternative; boundary="00000000000070e95305c5eb9d5c" Archived-At: Subject: Re: [IPsec] WGLC for draft-ietf-ipsecme-ikev1-algo-to-historic 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, 29 Jun 2021 18:17:19 -0000 --00000000000070e95305c5eb9d5c Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I thought the purpose of the draft was to be able to say "look at this document it says you MUST switch to IKEv2 if you want to remain IPsec interoperable. I am suprised I do not see the MUST in question. I am fine whatever chair/co-authors are fine with. Yours, Daniel On Tue, Jun 29, 2021 at 2:00 PM Yoav Nir wrote: > [no hats] > I don=E2=80=99t want to start (or resume) a religious holy war about uppe= rcase > MUSTs, but they=E2=80=99re usually about protocol compliance. What people= should > (not SHOULD) do with their systems is not subject to requirements languag= e, > because the IETF does not engineer administrators. What? You are not > compliant with RFC xxxx if you didn=E2=80=99t upgrade your systems alread= y? > > I could understand a statement that Product yyyy is not compliant with RF= C > xxxx because it still offers IKEv1, but I don=E2=80=99t like non-complian= t > administrators. Not that I=E2=80=99m advocating to add that statement to = the draft. > I think it=E2=80=99s fine as it is: just offering advice that systems sho= uld be > upgraded. > > Yoav > > On 29 Jun 2021, at 17:21, Daniel Migault wrote: > > I believe that the first sentence of section 3 says it all. ship it! > > I still have some minor comments, though these may have already been > discussed. There are no normative MUST to upgrade ( and in general very > little normative language). > Shouldn't we have for example: > Systems running IKEv1 should be upgraded and reconfigured to run IKEv2. > > moved to : > > Systems running IKEv1 MUST be upgraded and reconfigured to run IKEv2. > > > There are overall very little number of SHOULD/MUST but maybe that is an > editorial choice. > > Yours, > Daniel > > > > > > Yours, > Daniel > > On Mon, Jun 28, 2021 at 7:17 PM Dan Harkins wrote: > >> >> Hi, >> >> On 6/28/21 1:23 AM, Valery Smyslov wrote: >> > Hi, >> > >> > I think document is mostly ready. Few observations: >> > >> > - FWIW I think that Dan's efforts to make draft's language less >> speculative and more concrete >> > are valid and should be reflected in the document. >> > >> > - Is it OK that the intended status is Standards Track? Shouldn't it b= e >> BCP? >> > >> > - The draft states that it updates RFC 7296, 8221, 8247. What in >> particular is being updated? >> > I believe the recent IESG directives require a short explanation o= f >> what is being updated >> > to be present in Abstract. In any case, it should be clearly >> indicated in the body of the document. >> > Have I missed it? >> > >> > - Section3: I think that phrase "IKEv2 is a more secure protocol than >> IKEv1 in every aspect." is a bit too vague. >> >> You know, that was bugging me too. "in every aspect" is laying it on >> a bit thick. IKEv1 >> has a security proof. The much maligned PSK mode authenticates the key >> as well as the >> exchange which is better than what IKEv2 does (and why IKEv1 did not >> need an update to do >> PQC). So saying it's less secure "in every aspect" just isn't true. But >> I couldn't figure >> out a better way to say it.... >> >> > I believe it's better to list security aspects where we believe >> IKEv2 is superior: >> > >> > * IKEv2 supports modern cryptographic primitives, including AEAD >> ciphers >> > * IKEv2 provides real defense against DoS (cookies, core spec) and >> DDoS (puzzles, RFC 8019) attacks >> > * support for post-quantum crypto in IKEv2 is being developed >> (draft-ietf-ipsecme-ikev2-multiple-ke) >> > * IKEv2 supports various authentication methods via integration wit= h >> EAP (core spec) >> > * an extension that allows build PAKE methods in IKEv2 exists (RFC >> 6467) >> > * did I forget something? >> >> But this is great! I agree that such a brief summary of the superior >> features >> would be better than a factually challenged "in every aspect" statement. >> >> regards, >> >> Dan. >> >> -- >> "The object of life is not to be on the side of the majority, but to >> escape finding oneself in the ranks of the insane." -- Marcus Aurelius >> >> _______________________________________________ >> IPsec mailing list >> IPsec@ietf.org >> https://www.ietf.org/mailman/listinfo/ipsec >> > > > -- > Daniel Migault > Ericsson > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > > > --=20 Daniel Migault Ericsson --00000000000070e95305c5eb9d5c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I thought the purpose of the draft was to be able to say &= quot;look at this document it says you MUST switch to IKEv2 if you want to = remain IPsec interoperable. I am suprised I do not see the MUST in question= . I am fine whatever chair/co-authors are fine with.=C2=A0

Yours,=C2=A0
Daniel

On Tue, Jun 29, 2021 at 2:00 PM Yoav Nir <= ;ynir.ietf@gmail.com> wrote:<= br>
[no hats]
I don=E2=80=99t want to start (or r= esume) a religious holy war about uppercase MUSTs, but they=E2=80=99re usua= lly about protocol compliance. What people should (not SHOULD) do with thei= r systems is not subject to requirements language, because the IETF does no= t engineer administrators. What? You are not compliant with RFC xxxx if you= didn=E2=80=99t upgrade your systems already?

I could un= derstand a statement that Product yyyy is not compliant with RFC xxxx becau= se it still offers IKEv1, but I don=E2=80=99t like non-compliant administra= tors. Not that I=E2=80=99m advocating to add that statement to the draft. I= think it=E2=80=99s fine as it is: just offering advice that systems should= be upgraded.

Yoav

On 29 Jun 2021, at 17:21, Daniel Migault <mglt.ietf@gmail.com> wrote:
I believe that the first sentence of section= =C2=A03 says it all. ship it!

I still have some minor co= mments, though these may have already been discussed. There are no normativ= e MUST to upgrade ( and in general very little normative language).=C2=A0
Shouldn't we have for example:
Systems running IKEv1 should be upgraded and=C2=A0reconfigur= ed to run IKEv2.
<= br>
moved to :<= /div>
Systems running IKEv1 MUST be upgraded and reconfigured to =
run IKEv2.

<= div>There are overall very little numbe= r of SHOULD/MUST but maybe that is an editorial choice.=C2=A0
<= div>
Yours,=C2=A0
Daniel=C2=A0

=

=C2=A0
= =C2=A0

Yours,=C2=A0
Daniel
On Mon, = Jun 28, 2021 at 7:17 PM Dan Harkins <dharkins@lounge.org> wrote:

=C2=A0=C2=A0 Hi,

On 6/28/21 1:23 AM, Valery Smyslov wrote:
> Hi,
>
> I think document is mostly ready. Few observations:
>
> - FWIW I think that Dan's efforts to make draft's language les= s speculative and more concrete
>=C2=A0 =C2=A0 =C2=A0are valid and should be reflected in the document.<= br> >
> - Is it OK that the intended status is Standards Track? Shouldn't = it be BCP?
>
> - The draft states that it updates RFC 7296, 8221, 8247. What in parti= cular is being updated?
>=C2=A0 =C2=A0 =C2=A0I believe the recent IESG directives require a shor= t explanation of what is being updated
>=C2=A0 =C2=A0 =C2=A0to be present in Abstract. In any case, it should b= e clearly indicated in the body of the document.
>=C2=A0 =C2=A0 =C2=A0Have I missed it?
>
> - Section3: I think that phrase "IKEv2 is a more secure protocol = than IKEv1 in every aspect." is a bit too vague.

=C2=A0=C2=A0 You know, that was bugging me too. "in every aspect"= is laying it on
a bit thick. IKEv1
has a security proof. The much maligned PSK mode authenticates the key
as well as the
exchange which is better than what IKEv2 does (and why IKEv1 did not
need an update to do
PQC). So saying it's less secure "in every aspect" just isn&#= 39;t true. But
I couldn't figure
out a better way to say it....

>=C2=A0 =C2=A0 I believe it's better to list security aspects where = we believe IKEv2 is superior:
>
>=C2=A0 =C2=A0 * IKEv2 supports modern cryptographic primitives, includi= ng AEAD ciphers
>=C2=A0 =C2=A0 * IKEv2 provides real defense against DoS (cookies, core = spec) and DDoS (puzzles, RFC 8019) attacks
>=C2=A0 =C2=A0 * support for post-quantum crypto in IKEv2 is being devel= oped (draft-ietf-ipsecme-ikev2-multiple-ke)
>=C2=A0 =C2=A0 * IKEv2 supports various authentication methods via integ= ration with EAP (core spec)
>=C2=A0 =C2=A0 * an extension that allows build PAKE methods in IKEv2 ex= ists (RFC 6467)
>=C2=A0 =C2=A0 * did I forget something?

=C2=A0=C2=A0 But this is great! I agree that such a brief summary of the su= perior
features
would be better than a factually challenged "in every aspect" sta= tement.

=C2=A0=C2=A0 regards,

=C2=A0=C2=A0 Dan.

--
"The object of life is not to be on the side of the majority, but to escape finding oneself in the ranks of the insane." -- Marcus Aurelius=

_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec


--
Daniel Migault
Ericsson
_______________________________________________
IPsec mailing list
IPsec@ietf.org
http= s://www.ietf.org/mailman/listinfo/ipsec


-- <= br>
Daniel = Migault
Ericsson
--00000000000070e95305c5eb9d5c-- From nobody Tue Jun 29 12:19:39 2021 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 00F533A3E49 for ; Tue, 29 Jun 2021 12:19:38 -0700 (PDT) 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 ux-RuryiH_IX for ; Tue, 29 Jun 2021 12:19:33 -0700 (PDT) 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 64ACA3A3E46 for ; Tue, 29 Jun 2021 12:19:33 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 4GDvRh6jXwzFKx; Tue, 29 Jun 2021 21:19:28 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1624994368; bh=K3+KWRIN6QiZX+V70LdIYEUWt4uHc2SrvUR05AYBni8=; h=From:Subject:Date:References:Cc:In-Reply-To:To; b=lW6Yh6V8ilQiUTLmHowsSJ4pPQ9OlhoOKL5GZMSqda0hl3Gsr3S+CWHZREjSJebC5 rVrSrcDhzJ/uznS1yABhfv15m9JrJulyuj2BTIAfaqF0StCwkhYHMMWcYoMgzb5e2F NE54WvRqxowuZp0WkQp2JEf4tVdHpkeGVO/5tMZk= 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 6tKLODNRccO9; Tue, 29 Jun 2021 21:19:27 +0200 (CEST) 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; Tue, 29 Jun 2021 21:19:27 +0200 (CEST) Received: from smtpclient.apple (unknown [193.110.157.209]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by bofh.nohats.ca (Postfix) with ESMTPSA id 40D57BEAA5; Tue, 29 Jun 2021 15:19:26 -0400 (EDT) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable From: Paul Wouters Mime-Version: 1.0 (1.0) Date: Tue, 29 Jun 2021 15:19:25 -0400 Message-Id: <75EAB964-8599-4798-8911-F62D7FF72DA5@nohats.ca> References: Cc: Yoav Nir , IPsecME WG , Dan Harkins In-Reply-To: To: Daniel Migault X-Mailer: iPhone Mail (18F72) Archived-At: Subject: Re: [IPsec] WGLC for draft-ietf-ipsecme-ikev1-algo-to-historic 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, 29 Jun 2021 19:19:38 -0000 On Jun 29, 2021, at 14:17, Daniel Migault wrote: >=20 > =EF=BB=BF > I thought the purpose of the draft was to be able to say "look at this doc= ument it says you MUST switch to IKEv2 if you want to remain IPsec interoper= able. I am suprised I do not see the MUST in question. I am fine whatever ch= air/co-authors are fine with.=20 I agree with Yoav, the RFC 2119 language is for code implementations, not hu= mans. People outside the IETF may see the whole document as a MUST for compliance,= which is good for us :) Paul= From nobody Tue Jun 29 12:25:27 2021 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 03E2B3A011D for ; Tue, 29 Jun 2021 12:25:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.237 X-Spam-Level: X-Spam-Status: No, score=-2.237 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.338, 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 R7UtqmA-Ny0j for ; Tue, 29 Jun 2021 12:25:21 -0700 (PDT) Received: from www.goatley.com (www.goatley.com [198.137.202.94]) (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 628E43A0113 for ; Tue, 29 Jun 2021 12:25:21 -0700 (PDT) Received: from trixy.bergandi.net (cpe-76-176-14-122.san.res.rr.com [76.176.14.122]) by wwwlocal.goatley.com (PMDF V6.8 #2433) with ESMTP id <0QVH04GI09Y8R9@wwwlocal.goatley.com> for ipsec@ietf.org; Tue, 29 Jun 2021 14:25:20 -0500 (CDT) Received: from blockhead.local ([69.12.173.8]) by trixy.bergandi.net (PMDF V6.7-x01 #2433) with ESMTPSA id <0QVH004DK9X8H7@trixy.bergandi.net> for ipsec@ietf.org; Tue, 29 Jun 2021 12:24:45 -0700 (PDT) Received: from 69-12-173-8.static.dsltransport.net ([69.12.173.8] EXTERNAL) (EHLO blockhead.local) with TLS/SSL by trixy.bergandi.net ([10.0.42.18]) (PreciseMail V3.3); Tue, 29 Jun 2021 12:24:44 -0700 Date: Tue, 29 Jun 2021 12:25:19 -0700 From: Dan Harkins In-reply-to: To: Daniel Migault Cc: IPsecME WG Message-id: <73e6e489-bc1b-765b-5442-05220b463fd3@lounge.org> MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_gRm57FIQrn2cqBqMRFzf2g)" Content-language: en-US User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.7.1 X-PMAS-SPF: SPF check skipped for authenticated session (recv=trixy.bergandi.net, send-ip=69.12.173.8) X-PMAS-External-Auth: 69-12-173-8.static.dsltransport.net [69.12.173.8] (EHLO blockhead.local) References: <315BBB8D-B55E-43C8-A988-ADC8780AD62E@gmail.com> <059201d76bf6$e29680c0$a7c38240$@gmail.com> <8ea212cf-ee37-ceed-f905-4fde94173c1d@lounge.org> X-PMAS-Software: PreciseMail V3.3 [210625] (trixy.bergandi.net) X-PMAS-Allowed: system rule (rule allow header:X-PMAS-External noexists) Archived-At: Subject: Re: [IPsec] WGLC for draft-ietf-ipsecme-ikev1-algo-to-historic 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, 29 Jun 2021 19:25:26 -0000 This is a multi-part message in MIME format. --Boundary_(ID_gRm57FIQrn2cqBqMRFzf2g) Content-type: text/plain; charset=utf-8; format=flowed Content-transfer-encoding: 8BIT   Hi Daniel,   That seems to be part of the problem. The IETF isn't in the business of dictating administrative behavior through normative language. Protocols comply. People can use compliant protocols or not, and if they decide to use protocols which are non-compliant, or if they use proprietary protocols, it doesn't make them somehow "non-compliant".   This effort seems to have gained steam due to developers being told by their project management co-workers to do things to their IKEv1 code which they did not think was appropriate given the state of IKEv2. I can certainly relate to such difficult interactions. That said, the give-and-take of engineering and project/product management is not really in the IETF's bailiwick. If people want to take an RFC to the project/product management team and say, "look, the IETF has spoken!" then good luck, but that is a misuse of the imprimatur of the IETF and don't try and standardize _that_ behavior.   We can move a standard to historic. We can decide not to do any more development on it. We can't force people to do anything and we can't declare they are "non-compliant" if they decide to use a protocol we don't approve of.   It's interesting how SCEP has survived and actually thrived despite its restricted use and it's well-known security problems when EST, an IETF standard, exists. People strung the SCEP draft through multiple dozens of versions, dragging it out, it was made historic as a sop to this effort yet people still want to use it. I don't understand but a very large vendor of tablet and phone hardware/software (who ironically stole their OS name from the company that developed SCEP) decided to use it in their BYOD offering and so product/project management teams all say we must continue to use SCEP and update our SCEP code in order to work with these products that we can't avoid due to their massive market share. Sure, continued use of IKEv1 is a problem but it's a molehill compared to the mountain of today's use of SCEP. Yet here we are.   Dan. On 6/29/21 11:17 AM, Daniel Migault wrote: > I thought the purpose of the draft was to be able to say "look at this > document it says you MUST switch to IKEv2 if you want to remain IPsec > interoperable. I am suprised I do not see the MUST in question. I am > fine whatever chair/co-authors are fine with. > > Yours, > Daniel > > On Tue, Jun 29, 2021 at 2:00 PM Yoav Nir > wrote: > > [no hats] > I don’t want to start (or resume) a religious holy war about > uppercase MUSTs, but they’re usually about protocol compliance. > What people should (not SHOULD) do with their systems is not > subject to requirements language, because the IETF does not > engineer administrators. What? You are not compliant with RFC xxxx > if you didn’t upgrade your systems already? > > I could understand a statement that Product yyyy is not compliant > with RFC xxxx because it still offers IKEv1, but I don’t like > non-compliant administrators. Not that I’m advocating to add that > statement to the draft. I think it’s fine as it is: just offering > advice that systems should be upgraded. > > Yoav > >> On 29 Jun 2021, at 17:21, Daniel Migault > > wrote: >> >> I believe that the first sentence of section 3 says it all. ship it! >> >> I still have some minor comments, though these may have already >> been discussed. There are no normative MUST to upgrade ( and in >> general very little normative language). >> Shouldn't we have for example: >> Systems running IKEv1 should be upgraded and reconfigured to run >> IKEv2. >> >> moved to : >> Systems running IKEv1 MUST be upgraded and reconfigured to run IKEv2. >> >> There are overall very little number of SHOULD/MUST but maybe >> that is an editorial choice. >> >> Yours, >> Daniel >> >> >> >> Yours, >> Daniel >> >> On Mon, Jun 28, 2021 at 7:17 PM Dan Harkins > > wrote: >> >> >>    Hi, >> >> On 6/28/21 1:23 AM, Valery Smyslov wrote: >> > Hi, >> > >> > I think document is mostly ready. Few observations: >> > >> > - FWIW I think that Dan's efforts to make draft's language >> less speculative and more concrete >> >     are valid and should be reflected in the document. >> > >> > - Is it OK that the intended status is Standards Track? >> Shouldn't it be BCP? >> > >> > - The draft states that it updates RFC 7296, 8221, 8247. >> What in particular is being updated? >> >     I believe the recent IESG directives require a short >> explanation of what is being updated >> >     to be present in Abstract. In any case, it should be >> clearly indicated in the body of the document. >> >     Have I missed it? >> > >> > - Section3: I think that phrase "IKEv2 is a more secure >> protocol than IKEv1 in every aspect." is a bit too vague. >> >>    You know, that was bugging me too. "in every aspect" is >> laying it on >> a bit thick. IKEv1 >> has a security proof. The much maligned PSK mode >> authenticates the key >> as well as the >> exchange which is better than what IKEv2 does (and why IKEv1 >> did not >> need an update to do >> PQC). So saying it's less secure "in every aspect" just isn't >> true. But >> I couldn't figure >> out a better way to say it.... >> >> >    I believe it's better to list security aspects where we >> believe IKEv2 is superior: >> > >> >    * IKEv2 supports modern cryptographic primitives, >> including AEAD ciphers >> >    * IKEv2 provides real defense against DoS (cookies, core >> spec) and DDoS (puzzles, RFC 8019) attacks >> >    * support for post-quantum crypto in IKEv2 is being >> developed (draft-ietf-ipsecme-ikev2-multiple-ke) >> >    * IKEv2 supports various authentication methods via >> integration with EAP (core spec) >> >    * an extension that allows build PAKE methods in IKEv2 >> exists (RFC 6467) >> >    * did I forget something? >> >>    But this is great! I agree that such a brief summary of >> the superior >> features >> would be better than a factually challenged "in every aspect" >> statement. >> >>    regards, >> >>    Dan. >> >> -- >> "The object of life is not to be on the side of the majority, >> but to >> escape finding oneself in the ranks of the insane." -- Marcus >> Aurelius >> >> _______________________________________________ >> IPsec mailing list >> IPsec@ietf.org >> https://www.ietf.org/mailman/listinfo/ipsec >> >> >> >> >> -- >> Daniel Migault >> Ericsson >> _______________________________________________ >> IPsec mailing list >> IPsec@ietf.org >> https://www.ietf.org/mailman/listinfo/ipsec >> > > > > -- > Daniel Migault > Ericsson -- "The object of life is not to be on the side of the majority, but to escape finding oneself in the ranks of the insane." -- Marcus Aurelius --Boundary_(ID_gRm57FIQrn2cqBqMRFzf2g) Content-type: text/html; charset=utf-8 Content-transfer-encoding: 8BIT
  Hi Daniel,

  That seems to be part of the problem. The IETF isn't in the business of dictating
administrative behavior through normative language. Protocols comply. People can use
compliant protocols or not, and if they decide to use protocols which are non-compliant,
or if they use proprietary protocols, it doesn't make them somehow "non-compliant".

  This effort seems to have gained steam due to developers being told by their project
management co-workers to do things to their IKEv1 code which they did not think was
appropriate given the state of IKEv2. I can certainly relate to such difficult interactions.
That said, the give-and-take of engineering and project/product management is not really in
the IETF's bailiwick. If people want to take an RFC to the project/product management
team and say, "look, the IETF has spoken!" then good luck, but that is a misuse of the
imprimatur of the IETF and don't try and standardize _that_ behavior.

  We can move a standard to historic. We can decide not to do any more development on it.
We can't force people to do anything and we can't declare they are "non-compliant" if
they decide to use a protocol we don't approve of.

  It's interesting how SCEP has survived and actually thrived despite its restricted
use and it's well-known security problems when EST, an IETF standard, exists. People
strung the SCEP draft through multiple dozens of versions, dragging it out, it was made
historic as a sop to this effort yet people still want to use it. I don't understand but
a very large vendor of tablet and phone hardware/software (who ironically stole their OS
name from the company that developed SCEP) decided to use it in their BYOD offering
and so product/project management teams all say we must continue to use SCEP and update
our SCEP code in order to work with these products that we can't avoid due to their
massive market share. Sure, continued use of IKEv1 is a problem but it's a molehill
compared to the mountain of today's use of SCEP. Yet here we are.

  Dan.

On 6/29/21 11:17 AM, Daniel Migault wrote:
I thought the purpose of the draft was to be able to say "look at this document it says you MUST switch to IKEv2 if you want to remain IPsec interoperable. I am suprised I do not see the MUST in question. I am fine whatever chair/co-authors are fine with. 

Yours, 
Daniel

On Tue, Jun 29, 2021 at 2:00 PM Yoav Nir <ynir.ietf@gmail.com> wrote:
[no hats]
I don’t want to start (or resume) a religious holy war about uppercase MUSTs, but they’re usually about protocol compliance. What people should (not SHOULD) do with their systems is not subject to requirements language, because the IETF does not engineer administrators. What? You are not compliant with RFC xxxx if you didn’t upgrade your systems already?

I could understand a statement that Product yyyy is not compliant with RFC xxxx because it still offers IKEv1, but I don’t like non-compliant administrators. Not that I’m advocating to add that statement to the draft. I think it’s fine as it is: just offering advice that systems should be upgraded.

Yoav

On 29 Jun 2021, at 17:21, Daniel Migault <mglt.ietf@gmail.com> wrote:

I believe that the first sentence of section 3 says it all. ship it!

I still have some minor comments, though these may have already been discussed. There are no normative MUST to upgrade ( and in general very little normative language). 
Shouldn't we have for example:
Systems running IKEv1 should be upgraded and reconfigured to run IKEv2.

moved to :
Systems running IKEv1 MUST be upgraded and reconfigured to run IKEv2.

There are overall very little number of SHOULD/MUST but maybe that is an editorial choice. 

Yours, 
Daniel 


 
 

Yours, 
Daniel

On Mon, Jun 28, 2021 at 7:17 PM Dan Harkins <dharkins@lounge.org> wrote:

   Hi,

On 6/28/21 1:23 AM, Valery Smyslov wrote:
> Hi,
>
> I think document is mostly ready. Few observations:
>
> - FWIW I think that Dan's efforts to make draft's language less speculative and more concrete
>     are valid and should be reflected in the document.
>
> - Is it OK that the intended status is Standards Track? Shouldn't it be BCP?
>
> - The draft states that it updates RFC 7296, 8221, 8247. What in particular is being updated?
>     I believe the recent IESG directives require a short explanation of what is being updated
>     to be present in Abstract. In any case, it should be clearly indicated in the body of the document.
>     Have I missed it?
>
> - Section3: I think that phrase "IKEv2 is a more secure protocol than IKEv1 in every aspect." is a bit too vague.

   You know, that was bugging me too. "in every aspect" is laying it on
a bit thick. IKEv1
has a security proof. The much maligned PSK mode authenticates the key
as well as the
exchange which is better than what IKEv2 does (and why IKEv1 did not
need an update to do
PQC). So saying it's less secure "in every aspect" just isn't true. But
I couldn't figure
out a better way to say it....

>    I believe it's better to list security aspects where we believe IKEv2 is superior:
>
>    * IKEv2 supports modern cryptographic primitives, including AEAD ciphers
>    * IKEv2 provides real defense against DoS (cookies, core spec) and DDoS (puzzles, RFC 8019) attacks
>    * support for post-quantum crypto in IKEv2 is being developed (draft-ietf-ipsecme-ikev2-multiple-ke)
>    * IKEv2 supports various authentication methods via integration with EAP (core spec)
>    * an extension that allows build PAKE methods in IKEv2 exists (RFC 6467)
>    * did I forget something?

   But this is great! I agree that such a brief summary of the superior
features
would be better than a factually challenged "in every aspect" statement.

   regards,

   Dan.

--
"The object of life is not to be on the side of the majority, but to
escape finding oneself in the ranks of the insane." -- Marcus Aurelius

_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec


--
Daniel Migault
Ericsson
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec



--
Daniel Migault
Ericsson

-- 
"The object of life is not to be on the side of the majority, but to
escape finding oneself in the ranks of the insane." -- Marcus Aurelius
--Boundary_(ID_gRm57FIQrn2cqBqMRFzf2g)--